JPH09120405A

JPH09120405A - 情報センタにおけるサービス可変方式

Info

Publication number: JPH09120405A
Application number: JP27550795A
Authority: JP
Inventors: Kazuo Sato; 和夫佐藤
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1995-10-24
Filing date: 1995-10-24
Publication date: 1997-05-06
Anticipated expiration: 2015-10-24
Also published as: JP3192358B2; US5774671A

Abstract

(57)【要約】【課題】情報センタにおけるサービス可変方式に関
し、情報センタ側から利用者が関心を持つと思われるサ
ービスを選別して利用者に紹介することを目的とする。【解決手段】プロフィールデータ登録手段１２には利
用者自身のプロフィールデータをあらかじめ登録してお
き、サービスメニュー管理手段１６では情報センタ１０
が提供・仲介するサービスのメニューを管理している。
サービスメニュー配信手段１４はプロフィールデータ登
録手段１２に登録されているプロフィールデータから利
用者の嗜好特徴を抽出し、これをサービスメニュー管理
手段１６で管理しているサービスメニューデータと比較
して利用者の嗜好に合致したサービスメニューを選別
し、利用者端末３０に配信する。これにより、情報セン
タから紹介されるサービスメニューは利用者毎に変更さ
れて配信され、膨大な数のサービスの中から利用者自ら
が自分に合ったサービスを捜し出す手間はなくなる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は情報センタにおける
サービス可変方式に関し、特にネットワーク上で各種サ
ービスを提供する情報センタから利用者端末に対して利
用者が関心があると思われるサービスを選別して紹介す
る情報センタにおけるサービス可変方式に関する。

【０００２】近年、ネットワークを通じて情報などの提
供を受けることができるようなサービス形態が進んでき
ている。このようなネットワークシステムでは、情報を
提供する複数のインフォメーションプロバイダが情報セ
ンタに接続されており、この情報センタがネットワーク
を介して通信機能を有する端末に接続された構成になっ
ている。利用者は、端末を使って情報センタにアクセス
し、必要な情報やサービスの提供を受けることになる。

【０００３】

【従来の技術】従来、ネットワークを通じてインフォメ
ーションプロバイダなどが提供しているサービスを利用
しようとするときには、利用者が端末を操作して利用可
能なサービスを探し、希望するサービスがあったなら
ば、利用者自身で端末機能を変更したり、サービスの申
込みなどを行って、そのサービスを受けることができる
環境を整える必要がある。例えば、端末機能を変更する
ような場合は、通常、外部の記憶媒体に入ったサービス
プログラムを入手したり、或いは通信回線を介して情報
センタより入手して、それを端末にインストールするこ
とが行われる。サービスの申込みおよび解除について
も、情報センタとオンライン状態で手続きをしたり、郵
送等の方法が採られている。

【０００４】

【発明が解決しようとする課題】しかし、従来のシステ
ムでは、情報センタから何かしらサービスを受けようと
するときには、利用者自身が端末機能を変更する必要が
あり、新たにサービスを受けようとするとき、または既
に受けているサービスを止めたいときには、別途にサー
ビスの申込みまたは解除を行う必要があり、さらに、何
らかのサービスの提供を受けたいとするときには、沢山
あるサービスの中から自分に合ったものを利用者自身で
捜し出す必要があり、利用者自身が煩わしい手間と手順
をかけて、サービスを受けるための準備をしなければな
らないという問題点があった。

【０００５】本発明はこのような点に鑑みてなされたも
のであり、情報センタ側から利用者が興味のありそうな
サービスを選別して利用者に紹介し、利用者が紹介され
たサービスを利用するときには、端末からそのサービス
を申し込むことで、サービスプログラムが配信される、
情報センタにおけるサービス可変方式を提供することを
目的とする。

【０００６】

【課題を解決するための手段】図１は上記目的を達成す
る本発明の原理図である。本発明の情報センタにおける
サービス可変方式は、プロフィールデータ登録手段１２
と、サービスメニュー配信手段１４と、サービスメニュ
ー管理手段１６と、サービスプログラム配信手段１８と
から構成されている。プロフィールデータ登録手段１２
により利用者端末３０から登録要求を受付けて利用者自
身のプロフィールデータをあらかじめ登録しておく。サ
ービスメニュー管理手段１６においては、情報センタ１
０が扱うサービスのメニューに関するサービスメニュー
データを管理し、サービスの発生・終了に応じてメニュ
ーデータを追加・削除する。サービスメニュー配信手段
１４では、登録されているプロフィールデータおよびサ
ービスメニューデータを検索して利用者の嗜好に合致し
たサービスメニューを選別して利用者端末３０に配信す
るようにしている。利用者は配信されたサービスメニュ
ーを見て、希望するサービスがあったならば、利用者端
末３０からサービスの申込みをするが、サービスプログ
ラム配信手段１８は、その申込みを受付けて対応するサ
ービスプログラムを配信する。これにより、情報センタ
から通信回線を通じて受けるサービスの紹介内容、すな
わち、サービスメニューは利用者毎に変更されて配信さ
れることになり、膨大な数のサービスの中から利用者自
らが自分に合ったサービスを捜し出す手間はなくなる。

【０００７】

【発明の実施の形態】まず、本発明の概略について図面
を参照して説明する。図１は情報センタにおけるサービ
ス可変方式の原理構成を示す図である。

【０００８】情報センタ１０は通信回線のネットワーク
２０を通じて利用者端末３０が接続されている。情報セ
ンタ１０には、利用者のプロフィールデータを登録する
プロフィールデータ登録手段１２と、そのプロフィール
データから利用者が興味があると思われるサービスを探
して利用者端末３０に配信するサービスメニュー配信手
段１４と、情報センタ１０が提供する、または情報セン
タ１０が仲介するサービスを管理するサービスメニュー
管理手段１６と、利用者端末３０からのサービスの申込
みに対して利用者端末３０へ申込みのあったサービスプ
ログラムを配信するサービスプログラム配信手段１８と
が備えられている。また、プロフィールデータ登録手段
１２には利用者自身のプロフィールデータをあらかじめ
登録しておくプロフィールデータデータベース１３を、
サービスメニュー管理手段１６にはサービスメニューデ
ータを登録しておくサービスメニューデータベース１５
を、そして、サービスプログラム配信手段１８にはサー
ビスプログラムを管理しているサービスプログラムデー
タベース１７をそれぞれ有しており、各データおよびサ
ービスプログラムを管理している。

【０００９】上記構成において、まず、利用者が利用者
端末３０を使って事前に利用者自身のプロフィールデー
タを情報センタ１０のプロフィールデータ登録手段１２
に登録しておく。ここで、サービスメニューを配信する
場合には、サービスメニュー配信手段１４は、プロフィ
ールデータデータベース１３およびサービスメニューデ
ータベース１５に登録しておいたプロフィールデータと
サービスメニューデータとを比較して、どの利用者がど
のサービスに関心あるのかを選別し、選別したサービス
メニューのデータを利用者端末３０に配信する。利用者
は、利用者端末３０にて、配信されたサービスメニュー
のデータを見て、本当に自分が受けたいサービスである
かどうかを判断し、もし、それが受けたいサービスであ
れば申込みを行う。すると、情報センタ１０では、サー
ビスプログラム配信手段１８がサービスの申込みを受け
付けて、申込みのあったメニューに対応するプログラム
を利用者端末３０に配信する。そのプログラムは利用者
の端末に自動的にインストールされ、その時から利用者
はサービスを受けられることになる。

【００１０】次に、本発明の実施の形態を、複数のイン
フォメーションプロバイダと利用者端末との仲介をする
情報センタに適用した場合を例にして説明する。図２は
プロフィールデータの一例を示す図である。

【００１１】利用者端末３０を通じて入力されたプロフ
ィールデータ１３０は情報センタ１０のプロフィールデ
ータ登録手段１２にて受け、プロフィールデータデータ
ベース（以下、嗜好特徴会員対応データベースという）
１３に登録される。このプロフィールデータ１３０は、
「本人確認用データ」および「嗜好特徴抽出用データ」
より構成される。

【００１２】「本人確認用データ」は利用者本人を情報
センタ側にて確認するためのデータであり、データの総
てか若しくは一部を入力させることで本人かどうかを確
認するのに使用される。この「本人確認用データ」は、
既にセンタ側で会員管理情報として持っているデータな
ので、入力されたデータと比較すれば本人であるかどう
かが分かる。この「本人確認用データ」の項目として
は、例えば、「氏名」、「識別番号（ＩＤ番号）」、
「性別」、「住所」、「電話番号」、「生年月日」など
がある。

【００１３】また「嗜好特徴抽出用データ」は、例え
ば、「職業」、「資格」、「趣味」、「興味対象」など
での項目からなる。このデータは各項目に入力されたデ
ータから利用者の嗜好を抽出するためのもので、特に
「趣味」と「興味対象」の項目から嗜好特徴が強く得ら
れる。

【００１４】図３はプロフィールデータを入力する際の
処理の流れを示すフローチャートである。プロフィール
データを入力する際、まず、データ入力のモードを選択
し（ステップＳ１）、その入力が新規か前のデータを更
新するのかの分岐がある（ステップＳ２）。前データが
存在する場合には、更新が自動判別され、前のデータを
出力して入力画面を表示する（ステップＳ３）。新規の
場合は、入力画面表示になる（ステップＳ４）。次い
で、入力画面の中から、利用者は入力したい項目を選択
する（ステップＳ５）。ある項目が選択されると、その
項目の中の選択肢が表示される（ステップＳ６）。ここ
で、該当選択肢があるかどうかが判断され（ステップＳ
７）、該当選択肢があれば、表示されている選択肢から
該当選択肢を選択することで（ステップＳ８）、選択さ
れたデータが取込まれる（ステップＳ９）。もし選択肢
の中に該当するものが無い場合は、ソフトキーボードを
表示し（ステップＳ１０）、ソフトキーボードを使用し
てデータを入力することで（ステップＳ１１）、入力デ
ータの取込みが行われる（ステップＳ１２）。総ての項
目について入力が終了したかどうかが判断され（ステッ
プＳ１３）、終わっていなければ、ステップＳ４の入力
画面表示に戻り、終了ならば、最終入力画面表示を行い
（ステップＳ１４）、ここで、入力した内容の確認が終
わったら（ステップＳ１５）、入力データを記憶して作
業を終了する（ステップＳ１６）。

【００１５】図４、図５および図６はプロフィールデー
タの入力画面の例を示す図である。プロフィールデータ
を入力する時、前データが存在していなく、新規入力の
場合は図４（Ａ）に示したような入力画面３１ａが表示
される。ここで、項目「職業」の入力をする場合には、
入力画面３１ａにて「職業」の項目を選択する。する
と、図４（Ｂ）に示したように、その項目に対する選択
肢を表示した選択画面３１ｂが表示される。この例で
は、まず、職業の分類のうち、大分類が列挙される。こ
の大分類の中で、例えば、「経済・産業」を選択する
と、図４（Ｃ）に示したように、この項目に対する中分
類の選択肢の選択画面３１ｃが表示される。ここで、例
えば、「個人サービス業」の項目を選択すると、図５
（Ａ）に示したように、具体的な職業名を列挙した選択
画面３１ｄが表示され、ここで、例えば、「会計士」を
選択することによって、図５（Ｂ）に示したように、図
４（Ａ）と同じような入力画面３１ｅに戻る。ここで
は、「職業」の項目に、選択肢の中から選択された「会
計士」の選択データが入力された状態で表示される。こ
のようにして、各項目の入力が終了すると、図５（Ｃ）
に示したように、すべての項目が入力された最終確認用
の画面３１ｆになる。この画面３１ｆでよければ、「Ｙ
ＥＳ」を選択することにより、データとして情報センタ
に送られ、記憶される。尚、選択画面３１ｂ，３１ｃ，
３１ｄにおいて、選択肢の中に該当するものが無い場合
は、図６に示したように、自由入力画面３１ｇになり、
表示されているソフトキーボードを使うことによって項
目の入力が行われる。

【００１６】このようにすれば、殆どの入力は用意した
選択肢の中から利用者が選ぶだけで入力が可能なので、
普段キーボードなどに慣れていない利用者でも簡単にデ
ータの入力が可能になる。そればかりでなく、情報セン
タ側にデータを送信（登録）する際に、選択肢番号だけ
を送信すればよいので、記憶メモリの節約や通信時間の
節約にもなる。

【００１７】図７はプロフィールデータの送信時のデー
タ構成を示した図である。プロフィールデータを情報セ
ンタに登録する際の送信データ１３１は、プロフィール
データにその版数と、送信元の端末識別番号とが結合さ
れた構成を有している。プロフィールデータは、本人確
認用データ１３１ａと思考特徴抽出用データ１３１ｂと
から構成される。データ版数１３１ｃはこの送信したプ
ロフィールデータの版数である。端末識別番号１３１ｄ
は、送信元の端末がサービスを受ける正規の端末である
かどうかを確認するためと、本人確認用データと照らし
合わせて、利用者本人の端末であるかどうかを確認する
ためのものである。したがって、他人の端末を使用して
プロフィールデータを登録しようとしても、データの内
容が正しくとも情報センタでは受付をしない。これは利
用者の携帯端末が紛失した場合などに対応するためであ
る。尚、データ識別コード１３１ｅは、このデータがプ
ロフィールデータであることを示すものである。

【００１８】図８はプロフィールデータの登録処理の流
れを示すフローチャートである。このフローチャートに
おいて、太い実線の箱は利用者端末側での処理であり、
細い実線の箱は情報センタ側での処理である。プロフィ
ールデータを情報センタへ登録する際には、利用者端末
にてデータの登録をし、このデータを送信するためのモ
ード選択を行う（ステップＳ２１）。次いで、通信回線
を接続し（ステップＳ２２）、利用者端末に記憶された
プロフィールデータを送信する（ステップＳ２３）。情
報センタでは、送信されてきたプロフィールデータを受
信し（ステップＳ２４）、そのデータが利用者本人のも
のかどうかの確認処理が行われる（ステップＳ２５）。
ここで、利用者本人であると確認された場合には、情報
センタの嗜好特徴会員対応データベース（ＤＢ）に格納
する（ステップＳ２６）。もし入力データに異常があれ
ばその旨のコメントデータを利用者端末へ送信する（ス
テップＳ２７）。利用者端末では、そのコメントデータ
を受け（ステップＳ２８）、通信回線を切断して（ステ
ップＳ２９）、終了する。

【００１９】図９は嗜好特徴パターン化処理の流れを示
すフローチャートである。ここでは、情報センタが受け
取ったプロフィールデータから、利用者は何に興味があ
るのかという嗜好特徴を抽出する。情報センタでは、ま
ず、利用者がプロフィールデータとして入力したデータ
を抽出する（ステップＳ３１）。次いで、この入力デー
タを独自に体系化した辞書と比較して（ステップＳ３
２）、該当語があるかどうかを判断する（ステップＳ３
３）。ここで、該当語があった場合（ヒットした場合）
には、その該当語を含む辞書のパターンを抽出し（ステ
ップＳ３４）、それを、利用者各々と対応させた嗜好特
徴会員対応ＤＢに登録する（ステップＳ３５）。ここ
で、入力データが終了かどうかを判断し、まだ入力デー
タがあれば、ステップＳ３２に戻り、入力データが無け
れば、終了する（ステップＳ３６）。ステップＳ３３の
判断にて、該当語が無かった場合には、一旦、そのデー
タを保留とし（ステップＳ３７）、センタ側で辞書の組
み替えおよびデータの追加など、辞書内容（パターン）
の変更を行い（ステップＳ３８）、その後に、ステップ
Ｓ３２に戻って、再度比較を行いパターンを抽出する。
このとき、入力データと比較される辞書の形態を以下に
示す。

【００２０】図１０は辞書の形態の例を示す図である。
プロフィールデータと比較される辞書は情報センタ側に
て予め作っておくものであり、自動的に生成されるもの
ではない。語の繋がりを分類第１語から分類第ｎ語まで
のパターンとし、大きい分類から小さい分類へとツリー
状に繋がるようにする。すなわち、最も大きい分類第１
語１−１の下には、これより小さな分類第２語２−１，
２−２，・・が繋がり、この下には、これより小さな分
類第３語３−１，３−２，３−３，・・が繋がってい
き、この繋がりが分類第ｎ語まで続く。尚、語の繋がり
の関係において、大きい分類の方を上位、小さい方の分
類を下位と表現することとする。

【００２１】図１１は嗜好特徴のパターン形式を示す図
である。プロフィールデータと辞書との比較において、
該当語がどの分類でヒットしたかによって抽出されるパ
ターンを以下の４つの例で説明する。

【００２２】図１１（Ａ）に示したように、データが分
類第１語１−１にてヒットした場合には、これに繋がる
すべての語が取り込まれて、パターン化される。図１１
（Ｂ）に示したように、分類第２語２−１にてヒットし
た場合には、上位の分類第１語１−１と、この分類第２
語２−１に繋がる下位のすべての語が取り込まれて、パ
ターン化される。図１１（Ｃ）に示したように、分類第
３語３−１にてヒットした場合には、上位の２つの分類
第２語２−１および分類第１語１−１と、この分類第３
語３−１に繋がる下位のすべての語が取り込まれる。そ
して、図１１（Ｄ）に示したように、分類第ｎ語ｎ−１
にてヒットした場合には、上位のすべての語が取り込ま
れることになる。このように、下位の分類になるに従っ
て直系の単純なパターンとなる。この際、あまり上位の
分類語でヒットすると、抽出される語の数が多くなって
パターンが大きくなるので、あらかじめパターン化する
範囲を設定して、その範囲でパターン化するようにする
とよい。

【００２３】図１２は抽出した嗜好特徴の具体的なパタ
ーン例を示す図である。この例は分類第２語の「映画」
という語がヒットして抽出された場合を示しており、直
系の上位の語「文化」と、下位には「映画」に属する語
「映画一般」、「映画会社」および「映画祭」と、これ
らにそれぞれ属する語とを含むパターンが抽出される。
ここでは、パターン範囲は分類第４語までとしている。
このようにして嗜好特徴をパターン化することによっ
て、データが単語である場合に比べて、サービスメニュ
ーと比較した際のヒット率が高くなり、利用者に紹介す
る数が多くなる。例えば、図１２に示した例で言えば、
利用者の嗜好特徴データが「映画」である時、単語の場
合は「映画」そのものにヒットしなければ紹介されない
が、パターン化すれば、「文化」から「映画一般」、
「映画会社」、「映画祭」等々、「映画」に関連するも
のが紹介されることになる。

【００２４】図１３〜図１６は嗜好特徴会員対応ＤＢの
構成例を示す図である。これは、どの利用者がどんな嗜
好特徴を持っているのかをデータベース化したものであ
り、４つの構成が考えられる。この各々のデータベース
を用いて、利用者が関心を持っているサービスメニュー
を検索し、それを利用者に紹介するわけである。

【００２５】図１３の嗜好特徴会員対応ＤＢ１３ａで
は、パターン化した嗜好特徴を利用者と対応させた構成
を示している。パターン毎に利用者の識別番号を対応さ
せるようにした構成によれば、各パターン毎にすぐに配
信数が把握できることや、各パターン毎にどんな会員が
いるのかを把握しやすいという特徴を有している。

【００２６】図１４の嗜好特徴会員対応ＤＢ１３ｂは、
利用者毎にパターン化した嗜好特徴を対応させた構成を
示している。この利用者の識別番号毎にパターン化した
嗜好特徴を対応させるようにした構成は、特定の利用者
について、どんな嗜好特徴があるのか知りたい場合など
に便利である。

【００２７】図１５の嗜好特徴会員対応ＤＢ１３ｃは、
嗜好特徴をパターン化していない場合であり、その嗜好
特徴毎に利用者を対応させた構成を示している。この構
成は、図１３の場合と同様にすぐに配信数が把握できる
ことや、各嗜好特徴毎にどんな会員がいるのか、例えば
「映画」という嗜好特徴を持つ会員の名前を把握しやす
いという特徴がある。

【００２８】図１６の嗜好特徴会員対応ＤＢ１３ｄも嗜
好特徴をパターン化していない場合であって、利用者毎
に嗜好特徴を対応させた構成である。この構成は、図１
４の場合と同様に特定の利用者について、どんな嗜好特
徴があるのか知りたい場合などに便利である。

【００２９】図１３〜図１６の嗜好特徴会員対応ＤＢ１
３ａ〜１３ｄのうち、どの構成を用いるのかは情報セン
タの運用方法や必要性に係わる。但し、利用者側から考
えると、紹介してもらえるサービスメニューを沢山欲し
い場合は嗜好特徴をパターン化してある嗜好特徴会員対
応ＤＢ１３ａ，１３ｂを用いる方が良く、絞ったものだ
け紹介してもらう場合はパターン化していない嗜好特徴
会員対応ＤＢ１３ｃ，１３ｄを用いる方が良い。

【００３０】また、図では「パターン」や「特徴」、
「会員」と示してあるが、実際のデータとしては辞書上
の語番号や会員番号を用いる。図１７はサービスメニュ
ーをパターン化する処理の流れを示すフローチャートで
ある。

【００３１】サービスメニューはサービスメニューＤＢ
に保存されているが、これに新たなサービスメニューが
加わったような場合に、サービスメニューのパターン化
がなされる。そのときには、サービスメニューの題名
（特徴）を図１０に示した辞書と比較して（ステップＳ
４１）、該当語があった場合（ヒットした場合）には、
その該当語を含む辞書のパターンを抽出する（ステップ
Ｓ４２）。

【００３２】このサービスメニューの題名（特徴）のパ
ターン化されたパターン形式は図１１の嗜好特徴のパタ
ーン形式と同じである。サービスメニューのパターン化
において、図９に示した嗜好特徴のパターン化と異なる
のは、サービスメニューの場合は題名の付け方が辞書に
存在する単語を使用するというルールを用いているた
め、必ず辞書と比較した際にヒットすることである。も
し、辞書に無い単語をどうしても用いたい場合は辞書に
追加すれば良い。また、基本的にサービスメニューの紹
介の時だけパターン化すれば良いので、データベースと
して保存する必要もない。したがって、数が嗜好特徴に
比べて少ないので、特にパターン化の範囲を決めていな
い。つまり、どの分類の位でヒットしてもパターンとし
ては最後まで取り込むこととする。

【００３３】図１８はサービスメニューの特徴を範囲拡
張したパターン化の一例を示す図である。例えば、図１
８（Ａ）に示したように、利用者の「映画会社」なる嗜
好特徴データをパターン化した嗜好特徴パターンがある
とする。ここで、一例として、映画祭をいろいろ見るこ
とが出来る、題名が「映画祭紹介ソフト」なるサービス
メニューが新しく付け加わったとする。このサービスメ
ニューの特徴（題名）は辞書に追加されるが、このと
き、辞書には、「映画」の１つ下の下位語として追加さ
れるとする。この場合、「映画会社」でヒットした人に
対しては「映画祭紹介ソフト」は当然紹介されないこと
になる。しかし、映画会社に興味のある人ならば、映画
祭にも興味がある可能性も高いので、このような特徴ま
で紹介する範囲を拡張することも有用である。

【００３４】サービスメニューの特徴「映画祭紹介ソフ
ト」によって、サービスメニューの特徴をパターン化す
ると、図１８（Ｂ）に示したようになる。このようにパ
ターン化しておいたサービスメニュー特徴パターンを嗜
好特徴パターンと比較（検索）してパターン化すること
により、図１８（Ｃ）に示したように、嗜好特徴パター
ンには含まれていない特徴が新たに含まれるようにな
る。これにより、利用者に紹介されるサービスメニュー
の数が増え、もともとプロフィールデータからだけでは
ヒットしない人にも、多くのメニューを紹介できるよう
になる。

【００３５】次に、プロフィールデータから作られた嗜
好特徴会員対応ＤＢをどのように検索するかについて、
サービスメニューがパターン形式で、データベースが図
１３に示した嗜好特徴会員対応ＤＢ１３ａである場合を
例にして説明する。

【００３６】図１９は嗜好特徴会員対応ＤＢの検索の基
本処理の流れを示すフローチャートである。嗜好特徴会
員対応ＤＢを検索するには、まず、最初のパターンを用
意し（ステップＳ５１）、そのパターンについてパター
ン検索処理を行う（ステップＳ５２）。このパターン検
索処理の詳細は図２０で説明する。パターン検索処理が
終了すると、データベースのパターンが最後かどうかを
判断し（ステップＳ５３）、最後であれば、この基本処
理は終了となり、最後でなければ、次のパターンを用意
して（ステップＳ５４）、ステップＳ５２に戻る。この
検索処理は、一定期間を置いて、例えば、１か月置きに
実施される。

【００３７】図２０は嗜好特徴会員対応ＤＢのパターン
検索処理の流れを示すフローチャートである。パターン
検索の処理において、まず、メニューパターンのどの分
類語数（階層）から検索するかの初期設定をする（ステ
ップＳ６１）。通常は、最上位の分類第１語から始める
よう、「Ｙ＝１」が設定される。同様に、その分類語数
の何番目の語から検索するかの初期設定をする（ステッ
プＳ６２）。通常は、最初から始めるよう、「ｍ＝１」
が設定される。次に、メニューパターン分類第Ｙ語のｍ
番目の語を抽出する（ステップＳ６３）。ここで、嗜好
パターンのどの分類語数から検索するかの初期設定をす
る（ステップＳ６４）。通常は、最上位の分類第１語か
ら始めるよう、「Ｘ＝１」が設定される。同様に、その
分類語数の何番目の語から検索するかの初期設定をする
（ステップＳ６５）。通常は、最初から始めるよう、
「ｐ＝１」が設定される。そして抽出した語と嗜好パタ
ーン分類第Ｘ語のｐ番目の語と比較する（ステップＳ６
６）。ここで、比較の結果、一致すれば、すなわち、ヒ
ットすれば、配信関連処理を行い（ステップＳ６７）、
終了する。配信関連処理については、図２１にて後述す
る。

【００３８】ステップＳ６６において、ヒットしなけれ
ば、ｐがパターンの最後かどうかを判断し（ステップＳ
６８）、最後でなければ、次の語との比較を行うために
ｐを１つインクリメントして（ステップＳ６９）、ステ
ップＳ６６に戻る。ステップＳ６８において、ｐがパタ
ーンの最後であれば、Ｘがパターンの最後かどうかを判
断し（ステップＳ７０）、最後でなければ、次の語との
比較を行うためにＸを１つインクリメントして（ステッ
プＳ７１）、ステップＳ６５に戻る。ステップＳ７０に
おいて、Ｘがパターンの最後であれば、ｍがパターンの
最後かどうかを判断し（ステップＳ７２）、最後でなけ
れば、次の語との比較を行うためにｍを１つインクリメ
ントして（ステップＳ７３）、ステップＳ６３に戻る。
ステップＳ７２において、ｍがパターンの最後であれ
ば、Ｙがパターン範囲ｎかどうかを判断し（ステップＳ
７４）、Ｙ＝ｎでなければ、次の語との比較を行うため
にＹを１つインクリメントして（ステップＳ７５）、ス
テップＳ６２に戻る。ステップＳ７４において、Ｙ＝ｎ
であれば、その語についてはヒットが無い旨の記録を残
して終了する（ステップＳ７６）。

【００３９】図２１は嗜好特徴会員対応ＤＢの配信関連
処理の流れを示すフローチャートである。各パターン毎
に嗜好特徴会員対応ＤＢの検索を行って、ヒットがあれ
ば対応する会員の番号（配信ＩＤという）を用意する
（ステップＳ８１）。その配信ＩＤは配信済みかどうか
をチェックし（ステップＳ８２）、配信済みでなけれ
ば、配信処理をし（ステップＳ８３）、一度配信した配
信ＩＤは二重に配信しないようにするために記録される
（ステップＳ８４）。ここで、配信処理とは、利用者毎
に用意されたメモリ（ＢＯＸ）に配信ＩＤを格納する処
理を言い、配信ＩＤのＢＯＸへの格納を配信と呼ぶ。次
に、配信ＩＤは最後かどうかを判断し（ステップＳ８
５）、最後でなければ、次の配信ＩＤを用意して（ステ
ップＳ８６）、ステップＳ８２に戻る。ステップＳ８５
の判断において、配信ＩＤが最後であれば、この配信処
理は終了となる。

【００４０】上述のように、サービスメニューがパター
ン形式で、データベースが嗜好特徴会員対応ＤＢ１３ａ
である場合、各パターン毎に検索を行い、ヒットがあれ
ば、対応するＩＤに配信を行う。同様にして、サービス
メニューがパターン形式で、データベースが図１４に示
した形式の嗜好特徴会員対応ＤＢ１３ｂである場合に
は、各ＩＤ毎に対応するパターンをそれぞれ検索し、ヒ
ットがあれば、その時点でそのＩＤに配信を行い、次の
ＩＤに対応したパターン検索に移るようにしている。サ
ービスメニューがパターン形式で、データベースが図１
５に示した形式の嗜好特徴会員対応ＤＢ１３ｃである場
合には、各特徴毎に検索を行い、ヒットがあれば対応す
るＩＤに配信を行うようにしている。サービスメニュー
がパターン形式で、図１６に示した形式のデータベース
が嗜好特徴会員対応ＤＢ１３ｄである場合には、各ＩＤ
毎に対応する特徴語をそれぞれ検索し、ヒットがあれ
ば、その時点でそのＩＤに配信を行い、次のＩＤに対応
した特徴語の検索に移るようにしている。サービスメニ
ューが言葉だけによる単語の形式で、データベースが図
１３に示した形式の嗜好特徴会員対応ＤＢ１３ａである
場合には、各パターン毎に検索を行い、ヒットがあれ
ば、対応するＩＤに配信を行う。そして、サービスメニ
ューが単語の形式で、データベースが図１４に示した形
式の嗜好特徴会員対応ＤＢ１３ｂである場合には、各Ｉ
Ｄ毎に対応するパターンをそれぞれ検索し、ヒットがあ
れば、その時点でそのＩＤに配信を行い、次のＩＤに対
応したパターン検索に移るようにしている。

【００４１】データベースが嗜好特徴会員対応ＤＢにお
いては、サービスメニューも嗜好特徴もパターン化され
ている方が当然、ヒット率は高くなるが、特定のものだ
けを紹介して欲しい場合には、ヒットするものが多くな
りすぎる嫌いはある。どの方法を使用するのが良いのか
は、情報センタ側と利用者の双方で決めることが望まし
い。

【００４２】次に、プロフィールデータから作られたサ
ービスメニューによって利用者に色々なサービスを紹介
することになるが、紹介されるサービスの中には、利用
者が利用できるサービスと利用できないサービスとが含
まれている。利用者が利用できないサービスについて
は、紹介しても無駄であるので、サービスメニューを配
信する前にサービス利用資格をチェックして紹介できな
いようにすることもできる。

【００４３】図２２はサービス利用資格の確認処理の流
れを示すフローチャートである。サービス利用資格の確
認では、まず、ヒットしたサービスメニューデータを用
意し（ステップＳ９１）、サービスに決められている利
用資格とプロフィールデータとを比較し、合致するもの
があるかどうかを判断する（ステップＳ９２）。ここ
で、合致した場合のみ、配信処理を行うことになる（ス
テップＳ９３）。

【００４４】サービスメニューには、サービス題名、デ
ータ番号などがあるが、これらに利用資格が決められて
いる場合には、たとえ検索によってサービスメニューが
ヒットしたとしても、この利用資格に合わない利用者に
は上記の確認処理によって紹介はされない。利用資格と
しては、職業や特定の団体加入者などが考えられる。ま
た会員のレベル（ランク分けがあれば）によっても資格
を与えることも可能である。例として、Ａ大学の情報提
供サービスがあった場合、そのサービスはＡ大学生とそ
の関係者に限定することができ、利用資格はＡ大学生と
その関係者とに与えられる。

【００４５】図２３はサービスメニューの構成形式の一
例を示す図である。サービスメニュー１５０にはその項
目として、サービス題名、データ番号、サービス内容な
どがあるが、これに加えて、「利用資格」とその「確認
方法」とを明記しておくことで、上記の図２２の利用資
格確認処理とは別に、利用者側で申込みの際に確認する
ことも可能である。例えば「２０〜３０歳まで」という
利用資格があるとすると、これは図２２の処理によって
情報センタ側でプロフィールデータから利用資格有無の
確認が可能であるが、プロフィールデータには無いよう
な、例えば「今年○○ホテルを利用した方」といった利
用資格は利用者でなければ分からない。このような場合
には、サービスメニュー１５０を利用者に配信した後
に、利用者の判断に任せることになる。

【００４６】次に、嗜好特徴会員対応ＤＢの検索の結
果、ヒットするものが無かった場合の別の処理例につい
て説明する。図２４はヒット無しの時の配信処理の流れ
を示すフローチャートである。

【００４７】嗜好特徴会員対応ＤＢを検索した結果、そ
のサービスメニューの特徴にヒットするものが無かった
場合、図２０の処理では、記録処理をして終了するが、
それでも何らかのデータを配信（紹介）したい場合もあ
る。このような場合に対処するため、まず、記録処理を
行い（ステップＳ１０１）、その後、コメントデータを
結合して（ステップＳ１０２）、全利用者に対して配信
関連処理を行う（ステップＳ１０３）。配信関連処理は
図２１のフローチャートを用いて行う。また、コメント
としては、全員に紹介しているものである旨、または、
各々の利用者に対して嗜好に合わないけれども特別に紹
介するものである旨を用意する。

【００４８】図２５は通常のサービスメニューの配信処
理の流れを示すフローチャートである。これまでは、利
用者ＢＯＸ、つまり利用者毎に情報センタに用意された
メモリにデータ格納を行うことを配信と呼んできたが、
ここからはその利用者ＢＯＸから利用者端末へデータを
送信することを正式に配信と呼ぶ。尚、このフローチャ
ートにおいて、太い実線の箱は利用者端末側での処理で
あり、細い実線の箱は情報センタ側での処理である。

【００４９】まず、利用者端末において、サービスメニ
ューを受信するモードを選択し（ステップＳ１１１）、
通信回線を接続し（ステップＳ１１２）、情報センタへ
モードデータを送信する（ステップＳ１１３）。情報セ
ンタでは、利用者端末からサービスメニューを受けるモ
ードデータを受信し、利用者確認処理を行うと（ステッ
プＳ１１４）、情報センタ側より紹介するメニューデー
タがあるのかどうかを判断する（ステップＳ１１５）。
紹介するメニューデータがあれば、利用者端末の空き容
量は充分かどうかを確認し（ステップＳ１１６）、ＯＫ
であれば利用者ＢＯＸに格納されているサービスメニュ
ーデータを送信する（ステップＳ１１７）。利用者端末
では、サービスメニューデータの受信を確認し（ステッ
プＳ１１８）、確認ＯＫならば、利用者端末にサービス
メニューデータを格納し（ステップＳ１１９）、確認が
取れなければ、その旨を情報センタへ通知する（ステッ
プＳ１２０）。ステップＳ１１５において紹介するサー
ビスメニューが無い場合、またはステップＳ１１６にお
いて利用者端末の空き容量が充分でないと判断された場
合、情報センタはそれぞれの場合に応じたコメントデー
タを送信し（ステップＳ１２１）、利用者端末にて、そ
のコメントデータを受信する（ステップＳ１２２）。最
後に、通信回線を切断して（ステップＳ１２３）、この
処理を終了する。

【００５０】図２６はサービスメニュー受信モードのデ
ータ構成を示す図である。利用者端末から情報センタへ
送信されるサービスメニュー受信モードのデータ３００
は、サービスメニュー格納可能空き容量３００ａと、利
用者確認データ３００ｂと、端末識別番号３００ｃと、
データ識別コード３００ｄとから構成される。端末識別
番号３００ｃやＩＤ番号等の利用者確認データ３００ｂ
は、利用者を確認するのに使用される。また、サービス
メニュー格納可能空き容量３００ａは、端末の空き容量
を知るデータである。データ識別コード３００ｄは、こ
のデータがサービスメニュー受信モードのデータである
ことを示すものである。尚、端末に格納されたサービス
メニューデータは、利用者が閲覧して自分が欲しいもの
かどうかを判断処理（マーキング）した時点で、不要な
ものは削除される。また、必要と判断処理されたもの
は、申し込んだサービスプログラムが配信された時に削
除される。

【００５１】図２７はサービスメニュー配信時のデータ
構成を示す図である。情報センタから利用者端末へ送信
されるサービスメニュー配信時のデータ１５１は、日付
を含むサービスメニューデータ１５１ａと、データ送信
数１５１ｂと、端末識別番号１５１ｃと、宛て先コード
１５１ｄと、データ識別コード１５１ｅとによって構成
されている。情報センタは宛て先コード１５１ｄに従っ
た利用者端末へデータを送信し、端末側では端末識別番
号１５１ｃで、自分に送られたものかどうかを判断す
る。図２５のステップＳ１２０に示したように、自分宛
のものでない場合や受信時に異状になった場合などは、
その旨を情報センタ側に通知する。受信が確認できれ
ば、受信したメニューデータが格納される。データ送信
数１５１ｂは端末側でいくつのメニューが送られたのか
を知るためのものである。

【００５２】このようにして配信されたサービスメニュ
ーの中から利用者が申込みたいサービスを選択する際の
利用者端末での処理について以下に説明する。図２８は
利用者端末にて申込みたいサービスの選択処理の流れを
示すフローチャートである。

【００５３】利用者が利用者端末にて、配信されたサー
ビスメニューの中から申込みたいサービスを選択すると
き、まず、サービスメニューを一覧表示する（ステップ
Ｓ１３１）。ここで、一覧表示されたサービスメニュー
の中から内容表示を選択するかまたは終了を選択するか
を判断する（ステップＳ１３２）。終了が選択される
と、この選択処理は終了し、内容表示が選択されると、
選択したメニューが表示され（ステップＳ１３３）、利
用者は表示されたメニューを見て、申込みを行うかどう
かの判断をする（ステップＳ１３４）。申込みを行う場
合は、利用したいサービスを選択してそのメニューにマ
ークを付ける、すなわち、申込みのためのデータを投入
する（ステップＳ１３５）。メニューデータにマークが
付けられることで、申込みの無かったものと区別され
る。マーク終了後、またはステップＳ１３４の判断で申
込みを行わない場合は、ステップＳ１３１のサービスメ
ニュー一覧表示に戻る。

【００５４】図２９はサービス申込みの画面表示例を示
す図である。利用者端末において、配信されたサービス
メニューは、最初、画面３０１ａのように、一覧の形で
表示される。このサービスメニュー一覧の中から、興味
のあるサービスを選択すると、より詳細なサービス内容
を表示する画面３０１ｂが表示される。利用者はこの画
面３０１ｂの内容を確認し、申込みをするかしないかの
判断をして該当箇所にマークを付けることによってサー
ビスメニュー一覧の画面３０１ａに戻る。ここで、他の
サービスに興味のあるものがあれば、同じような操作で
サービスの選択を行い、興味のあるサービスがなけれ
ば、終了の箇所にマークを付けることによって、利用者
端末側でのサービス申込みの処理が終了する。

【００５５】図３０は選択されたサービスの申込みを情
報センタに行う処理の流れを示すフローチャートであ
る。このフローチャートにおいて、太い実線の箱は利用
者端末側での処理であり、細い実線の箱は情報センタ側
での処理である。

【００５６】サービスの申込みを情報センタに行うとき
には、まず、利用者端末において、サービス申込みを行
うモードを選択し（ステップＳ１４１）、通信回線を接
続して（ステップＳ１４２）、サービス申込みデータを
送信する（ステップＳ１４３）。情報センタでは、送信
されてきたサービス申込みデータを受信し（ステップＳ
１４４）、サービス申込みデータに基づいて利用者確認
処理が行われる（ステップＳ１４５）。ここで、利用者
確認処理で問題がなければ、サービスプログラム配信受
付処理が行われ（ステップＳ１４６）、サービス利用の
登録処理が行われる（ステップＳ１４７）。ステップＳ
１４５の判断処理において、利用者の確認が取れなけれ
ば、その旨のコメントデータを利用者端末に送信し（ス
テップＳ１４８）、利用者端末ではそのコメントデータ
を受けて端末の画面に表示する（ステップＳ１４９）。
以上の処理が終了すると、通信回線を切断して（ステッ
プＳ１５０）、申込み処理が終了する。

【００５７】図３１はサービス申込みのデータ構成を示
す図である。利用者端末から情報センタへサービス申込
みをする際のデータは、サービス申込みデータ３０２ａ
と、利用者確認データ３０２ｂと、端末識別番号３０２
ｃと、データ識別コード３０２ｄとから構成される。サ
ービス申込みデータ３０２ａは、サービス申込み処理に
てマークされた、サービスメニューのデータ番号のみを
使用する。また、利用者確認データ３０２ｂと、端末識
別番号３０２ｃと、データ識別コード３０２ｄについて
は、今までと同様、利用者の確認に使用されるデータで
ある。

【００５８】次に、情報センタから紹介するデータに対
して利用者からの申込みがどれ位あったかをモニタし、
その数が多いときに紹介するデータ量を増やしてサービ
スの向上を図るという処理の例を以下に説明する。

【００５９】図３２は嗜好特徴の範囲を拡張する処理の
流れを示すフローチャートである。この例は、嗜好パタ
ーンを拡張する場合であり、まず、嗜好パターン毎に配
信したサービスメニューが申し込まれたかどうかを比較
し（ステップＳ１６１）、配信した数に対する申込みの
あった数の割合がある設定値を越えたかどうかを判断す
る（ステップＳ１６２）。その割合が設定値を越えてい
ない場合はそのまま終了し、割合が設定値以上になった
場合には、嗜好パターンの範囲を拡張する処理が行われ
る（ステップＳ１６３）。このように、配信数に対して
申込みのあった数が設定した値以上であった時には、利
用者の欲求が強いと見て、嗜好パターンの範囲を拡張
し、紹介するサービスメニューが広くなるようにする。
この範囲拡張処理は図３３で詳述する。

【００６０】図３３は嗜好パターン範囲拡張処理の流れ
を示すフローチャートである。嗜好パターンの範囲を拡
張するには、まず、利用者のプロフィールデータの該当
語のヒットした位置が辞書の分類第Ｘ語であるかを識別
し（ステップＳ１７１）、嗜好パターンの分類語数Ｘが
１であるかどうかを判断する（ステップＳ１７２）。こ
こで、ヒットした語が分類第１語ならば、これ以上範囲
の拡張はできないので、その旨の記録処理をして（ステ
ップＳ１７３）、終了する。ステップＳ１７２の判断に
おいて、ヒットした語が分類第１語でなければ、同パタ
ーン上のＸをＸ−１にして、すなわち、Ｘよりも一つ上
位の位置でパターン抽出を行い（ステップＳ１７４）、
そして、嗜好特徴会員対応ＤＢのパターンを入れ替える
（ステップＳ１７５）。

【００６１】図３４は嗜好特徴の範囲を拡張する別の処
理の流れを示すフローチャートである。この例は、嗜好
特徴語をパターン化して拡張する場合であり、まず、嗜
好特徴語毎に配信したサービスメニューが申し込まれた
かどうかを比較し（ステップＳ１８１）、配信した数に
対する申込みのあった数の割合がある設定値を越えたか
どうかを判断する（ステップＳ１８２）。その割合が設
定値を越えていない場合はそのまま終了し、割合が設定
値以上になった場合には、嗜好特徴語をパターン化する
（ステップＳ１８３）。このように、配信数に対して申
込みのあった数が設定した値以上であった時には、利用
者の欲求が強いと見て、嗜好特徴語をパターン化して範
囲を拡張し、紹介するサービスメニューを広くする。こ
の嗜好特徴語パターン化処理については、以下の図３５
に示す。

【００６２】図３５は嗜好特徴語のパターン化処理の流
れを示すフローチャートである。嗜好特徴語をパターン
化して範囲を拡張するには、まず、嗜好特徴語を辞書と
比較し（ステップＳ１９１）、該当語を含む辞書パター
ンを抽出し（ステップＳ１９２）、そして、嗜好特徴会
員対応ＤＢに登録する（ステップＳ１９３）。

【００６３】次に、利用者によって申込みされたときの
サービスの配信を行う場合の処理について説明する。図
３６はサービスプログラムの配信処理の流れを示すフロ
ーチャートである。

【００６４】このフローチャートにおいて、太い実線の
箱は利用者端末側での処理であり、細い実線の箱は情報
センタ側での処理である。まず、利用者端末において、
サービスプログラムを受信するモードを選択し（ステッ
プＳ２０１）、通信回線を接続し（ステップＳ２０
２）、情報センタへ利用者端末側がサービスプログラム
を受けるモードデータを送信する（ステップＳ２０
３）。情報センタでは、利用者端末からサービスプログ
ラムを受けるモードデータを受信し、利用者確認処理を
行うと（ステップＳ２０４）、利用者端末の空き容量は
充分かどうかを確認し（ステップＳ２０５）、ＯＫであ
れば配信受付をしたサービスプログラムを送信し、管理
データを更新する（ステップＳ２０６）。利用者端末で
は、サービスプログラムの受信を確認し（ステップＳ２
０７）、確認ＯＫならば、利用者端末にサービスプログ
ラムを自動インストールする処理を行い（ステップＳ２
０８）、確認が取れなければ、その旨を情報センタへ通
知する（ステップＳ２０９）。ステップＳ２０５におい
て利用者端末の空き容量が充分でないと判断された場
合、情報センタはその旨のコメントデータを送信し（ス
テップＳ２１０）、利用者端末では、そのコメントデー
タを受信して表示する（ステップＳ２１１）。最後に、
通信回線を切断して（ステップＳ２１２）、このサービ
スプログラムの配信処理を終了する。

【００６５】図３７はサービスプログラム受信モードの
データ構成を示す図である。利用者端末から情報センタ
へ送信されるサービスプログラム受信モードのデータ３
０３は、サービスプログラム格納可能空き容量３０３ａ
と、利用者確認データ３０３ｂと、端末識別番号３０３
ｃと、データ識別コード３０３ｄとから構成される。端
末識別番号３０３ｃおよび利用者確認データ３０３ｂ
は、利用者を確認するのに使用される。また、サービス
プログラム格納可能空き容量３０３ａは、端末の空き容
量を知るデータである。データ識別コード３０３ｄは、
このデータがサービスプログラム受信モードのデータで
あることを示すものである。

【００６６】図３８はサービスプログラム配信時のデー
タ構成を示す図である。情報センタから利用者端末へ送
信されるサービスプログラム配信時のデータ１７０は、
版数を含むサービスプログラム１７０ａと、圧縮情報
（プログラム）１７０ｂと、端末識別番号１７０ｃと、
宛て先コード１７０ｄと、データ識別コード１７０ｅと
によって構成されている。情報センタは宛て先コード１
７０ｄに従った利用者端末へプログラムを送信し、端末
側では端末識別番号１７０ｃで、自分に送られたものか
どうかを判断する。図３６のステップＳ２０７に示した
ように、自分宛のものでない場合や受信時に異状になっ
た場合などは情報センタ側に通知する。それが確認でき
れば、プログラムを受信し、圧縮情報（プログラム）１
７０ｂに指示されたインストール方法に従って自動イン
ストール処理が行われる。尚、圧縮情報（プログラム）
とは、サービスプログラムが圧縮されているかどうかの
情報であり、圧縮されている場合には圧縮方法を示す情
報か、または自己解凍プログラムを示す情報である。

【００６７】次に、図３６のステップＳ２０８に示した
サービスプログラムの自動インストール時の処理につい
て説明する。図３９はサービスプログラムの自動インス
トール処理の流れを示すフローチャートである。

【００６８】サービスプログラムの自動インストール処
理では、まず、利用者端末側にて受信したサービスプロ
グラムは圧縮されているかどうかを判断し（ステップＳ
２２１）、圧縮がかかっている場合は、それを利用者端
末のソフトウェアによって、または配信された自己解凍
プログラムを実行することによって解凍し（ステップＳ
２２２）、解凍されたサービスプログラムをメモリに格
納する（ステップＳ２２３）。その後、利用者端末のメ
ニューデータを更新する（ステップＳ２２４）。これは
メニュー表示用のデータの追加、アイコン等の図形の追
加等を行う処理である。そして利用者端末内の管理デー
タも更新する（ステップＳ２２５）。これは利用者端末
の持つ機能によって異なるが、端末内のメモリ容量（空
き容量）、プログラムの受信記録、履歴データ等を書き
換えることである。最後に、保管されていたサービスメ
ニューデータからサービスプログラムに対応するサービ
スメニューデータを削除し（ステップＳ２２６）、この
サービスプログラムの自動インストール処理を終了す
る。

【００６９】次に、今まで受けていたサービスの提供を
止めるときのサービス解除処理について説明する。図４
０はサービス解除処理の流れを示すフローチャートであ
る。

【００７０】このフローチャートにおいて、太い実線の
箱は利用者端末側での処理であり、細い実線の箱は情報
センタ側での処理である。サービス提供が不要になった
場合にサービス解除を情報センタに通知するが、これ
は、情報センタがサービス提供側に、例えば定期サービ
スを受けている場合には次回以降のサービスの中止を、
料金が定額制になっている場合には料金発生の中止を、
サービス利用者数に応じて情報センタが仲介料を貰う契
約の場合には利用者数の変更を通知するため等である。

【００７１】サービスを解除するときには、まず、利用
者端末側で、サービス解除モードを選択し（ステップＳ
２３１）、現在利用中のサービス一覧を表示する（ステ
ップＳ２３２）。利用者はそのサービス一覧を見て、そ
の中から解除するサービスを選択する（ステップＳ２３
３）。次いで、利用者端末は通信回線接続処理を行い
（ステップＳ２３４）、サービス解除データを情報セン
タに送信する（ステップＳ２３５）。情報センタでは、
サービス解除データを受け（ステップＳ２３６）、利用
者確認処理を行う（ステップＳ２３７）。利用者確認が
取れると、サービス利用登録の削除処理が行われる（ス
テップＳ２３８）。利用者確認が取れなければ、その旨
のコメントを利用者端末へ送信し（ステップＳ２３
９）、利用者端末ではそのコメントを受信して表示する
（ステップＳ２４０）。その後、利用者端末では通信回
線の切断処理を行い（ステップＳ２４１）、サービスプ
ログラムの削除（ステップＳ２４２）と、端末メニュー
データの更新（ステップＳ２４３）と、端末内の管理デ
ータの更新を行う（ステップＳ２４４）。このメニュー
データの更新は図３９の場合とは逆に、サービスプログ
ラム削除に伴ってメニュー表示用のデータや、アイコン
等の図形の削除を行う等の処理である。

【００７２】図４１はサービス解除データの構成を示す
図である。サービス解除の際に用いる解除データ３０４
は、サービス解除データ３０４ａと、利用者確認データ
３０４ｂと、端末識別番号３０４ｃと、データ識別コー
ド３０４ｄとから構成される。サービス解除データ３０
４ａは、図４０のステップＳ２３３にて選択されたサー
ビスの識別番号が使用される。また、利用者確認データ
３０４ｂ、端末識別番号３０４ｃおよびデータ識別コー
ド３０４ｄは、今までと同様、利用者の確認に使用され
る。

【００７３】最後に、サービスメニューデータとは別に
配信された情報が利用者端末にて画面表示される場合の
一例を示す。図４２は提供情報の画面表示例を示す図で
ある。

【００７４】利用者端末では、サービスメニューデー
タ、サービスプログラムの代わりに情報を配信すること
もできる。ここで情報と呼んでいるものは、例えば広告
（ＤＭ）、お知らせ、案内等である。配信された情報
は、例えば、図示の画面３０５のように表示される。

【００７５】情報を配信する場合にも、プロフィールデ
ータの登録からサービスメニューの配信までは同様の処
理となる。但し、配信するのはサービスメニューではな
くて情報であるという点だけが異なる。また情報配信の
場合は、それ以降の申込み等の処理は無く、配信された
ところでサービスが終了する。配信される情報によって
は、申込みが必要なものもあると考えられるが、それは
このサービス以外の処理（電話等）とする。配信された
情報には、例えば、保存しておくのか不要なので削除す
るのかを制御するボタンが用意されており、それらのマ
ーク状態に応じて情報は保存または削除される。情報は
削除されるまで保存される。

【００７６】

【発明の効果】以上説明したように本発明では、利用者
が自分のプロフィールデータを情報センタに登録するこ
とで、サービスメニュー配信手段がプロフィールデータ
に合致したサービスメニューを選別して利用者端末に配
信するように構成した。このため、利用者自身が沢山の
サービスの中から自分に合ったものを探す必要がなくな
る。また、利用者は配信されたサービスメニューを見て
希望するサービスを申込みをすると、サービスプログラ
ム配信手段は該当するサービスプログラムとともに利用
者端末でのインストール方法を指示するようにしたの
で、サービスプログラムを自動インストールでき、利用
者自身が端末機能を変更する必要がなくなる。

【図面の簡単な説明】

【図１】情報センタにおけるサービス可変方式の原理構
成を示す図である。

【図２】プロフィールデータの一例を示す図である。

【図３】プロフィールデータを入力する際の処理の流れ
を示すフローチャートである。

【図４】プロフィールデータの入力画面の例を示す図
（その１）である。

【図５】プロフィールデータの入力画面の例を示す図
（その２）である。

【図６】プロフィールデータの入力画面の例を示す図
（その３）である。

【図７】プロフィールデータの送信時のデータ構成を示
した図である。

【図８】プロフィールデータの登録処理の流れを示すフ
ローチャートである。

【図９】嗜好特徴パターン化処理の流れを示すフローチ
ャートである。

【図１０】辞書の形態の例を示す図である。

【図１１】嗜好特徴のパターン形式を示す図である。

【図１２】抽出した嗜好特徴の具体的なパターン例を示
す図である。

【図１３】嗜好特徴会員対応ＤＢの構成例（その１）を
示す図である。

【図１４】嗜好特徴会員対応ＤＢの構成例（その２）を
示す図である。

【図１５】嗜好特徴会員対応ＤＢの構成例（その３）を
示す図である。

【図１６】嗜好特徴会員対応ＤＢの構成例（その４）を
示す図である。

【図１７】サービスメニューをパターン化する処理の流
れを示すフローチャートである。

【図１８】サービスメニューの特徴を範囲拡張したパタ
ーン化の一例を示す図である。

【図１９】嗜好特徴会員対応ＤＢの検索の基本処理の流
れを示すフローチャートである。

【図２０】嗜好特徴会員対応ＤＢのパターン検索処理の
流れを示すフローチャートである。

【図２１】嗜好特徴会員対応ＤＢの配信関連処理の流れ
を示すフローチャートである。

【図２２】サービス利用資格の確認処理の流れを示すフ
ローチャートである。

【図２３】サービスメニューの構成形式の一例を示す図
である。

【図２４】ヒット無しの時の配信処理の流れを示すフロ
ーチャートである。

【図２５】通常のサービスメニューの配信処理の流れを
示すフローチャートである。

【図２６】サービスメニュー受信モードのデータ構成を
示す図である。

【図２７】サービスメニュー配信時のデータ構成を示す
図である。

【図２８】利用者端末にて申込みたいサービスの選択処
理の流れを示すフローチャートである。

【図２９】サービス申込みの画面表示例を示す図であ
る。

【図３０】選択されたサービスの申込みを情報センタに
行う処理の流れを示すフローチャートである。

【図３１】サービス申込みのデータ構成を示す図であ
る。

【図３２】嗜好特徴の範囲を拡張する別の処理の流れを
示すフローチャートである。

【図３３】嗜好パターン範囲拡張処理の流れを示すフロ
ーチャートである。

【図３４】嗜好特徴の範囲を拡張する別の処理の流れを
示すフローチャートである。

【図３５】嗜好特徴語のパターン化処理の流れを示すフ
ローチャートである。

【図３６】サービスプログラムの配信処理の流れを示す
フローチャートである。

【図３７】サービスプログラム受信モードのデータ構成
を示す図である。

【図３８】サービスプログラム配信時のデータ構成を示
す図である。

【図３９】サービスプログラムの自動インストール処理
の流れを示すフローチャートである。

【図４０】サービス解除処理の流れを示すフローチャー
トである。

【図４１】サービス解除データの構成を示す図である。

【図４２】提供情報の画面表示例を示す図である。

【符号の説明】

１０情報センタ１２プロフィールデータ登録手段１４サービスメニュー配信手段１６サービスメニュー管理手段１８サービスプログラム配信手段２０ネットワーク３０利用者端末

Claims

【特許請求の範囲】

【請求項１】情報センタから通信回線を通じて受ける
サービスの紹介内容を利用者に応じて変更する情報セン
タにおけるサービス可変方式において、利用者端末から利用者自身のプロフィールデータの登録
要求を受付けて登録処理を行うプロフィールデータ登録
手段と、前記情報センタが扱うサービスのメニューに関するサー
ビスメニューデータを管理するサービスメニュー管理手
段と、登録されているプロフィールデータおよびサービスメニ
ューデータを検索して利用者の嗜好に合致したサービス
メニューを選別して前記利用者端末に配信するサービス
メニュー配信手段と、前記利用者端末からサービスの申込みを受付けて対応す
るサービスプログラムを配信するサービスプログラム配
信手段と、を備えていることを特徴とする情報センタにおけるサー
ビス可変方式。
【請求項２】前記プロフィールデータは利用者本人の
確認用データを含むことを特徴とする請求項１記載の情
報センタにおけるサービス可変方式。
【請求項３】前記プロフィールデータ登録手段は利用
者によるプロフィールデータの入力に先立って入力すべ
き項目の選択肢のデータを前記利用者端末に配信するよ
うに構成したことを特徴とする請求項１記載の情報セン
タにおけるサービス可変方式。
【請求項４】前記サービスメニュー配信手段は、前記
プロフィールデータから利用者の嗜好特徴を抽出する嗜
好特徴抽出手段と、サービスメニューの特徴を体系化し
た辞書と、抽出された嗜好特徴を前記辞書と比較してパ
ターン化し、パターン化した嗜好特徴を前記プロフィー
ルデータ登録手段が持つ嗜好特徴データベース手段に保
存する嗜好特徴パターン化手段とを有することを特徴と
する請求項１記載の情報センタにおけるサービス可変方
式。
【請求項５】前記嗜好特徴データベース手段はパター
ン毎に利用者の識別番号を対応させるように構成したこ
とを特徴とする請求項４記載の情報センタにおけるサー
ビス可変方式。
【請求項６】前記嗜好特徴データベース手段は利用者
の識別番号毎にパターン化した嗜好特徴を対応させるよ
うに構成したことを特徴とする請求項４記載の情報セン
タにおけるサービス可変方式。
【請求項７】前記サービスメニュー配信手段は、前記
プロフィールデータから利用者の嗜好特徴を抽出する嗜
好特徴抽出手段と、サービスメニューの特徴を体系化し
た辞書と、抽出された嗜好特徴を前記辞書と比較し、意
味を持つものかどうかを確認して確認された嗜好特徴毎
に利用者の識別番号を対応させて前記プロフィールデー
タ登録手段が持つ嗜好特徴データベース手段に保存する
嗜好特徴確認手段とを有することを特徴とする請求項１
記載の情報センタにおけるサービス可変方式。
【請求項８】前記サービスメニュー配信手段は、前記
プロフィールデータから利用者の嗜好特徴を抽出する嗜
好特徴抽出手段と、サービスメニューの特徴を体系化し
た辞書と、抽出された嗜好特徴を前記辞書と比較し、意
味を持つものかどうかを確認して利用者の識別番号毎に
前記嗜好特徴確認手段によって確認された嗜好特徴を対
応させて前記プロフィールデータ登録手段が持つ嗜好特
徴データベース手段に保存する嗜好特徴確認手段とを有
することを特徴とする請求項１記載の情報センタにおけ
るサービス可変方式。
【請求項９】前記サービスメニュー配信手段は、前記
サービスメニュー管理手段のサービスメニューデータを
前記辞書と比較してパターン化するサービスメニューパ
ターン化手段をさらに有することを特徴とする請求項
４、７または８のいずれかに記載の情報センタにおける
サービス可変方式。
【請求項１０】前記サービスメニュー配信手段は、前
記サービスメニューパターン化手段によってパターン化
された特徴と前記嗜好特徴データベース手段に格納され
た嗜好特徴とを比較しサービスメニューデータを選別し
て配信する選別手段をさらに有することを特徴とする請
求項９記載の情報センタにおけるサービス可変方式。
【請求項１１】前記サービスメニュー配信手段は、前
記サービスメニュー管理手段のサービスメニューデータ
と前記嗜好特徴データベース手段に格納された嗜好特徴
とを比較しサービスメニューデータを選別して配信する
選別手段をさらに有することを特徴とする請求項４記載
の情報センタにおけるサービス可変方式。
【請求項１２】前記サービスメニュー配信手段は、利
用者に紹介資格があるかどうかを確認する資格確認手段
をさらに有することを特徴とする請求項１０または１１
のいずれかに記載の情報センタにおけるサービス可変方
式。
【請求項１３】前記選別手段は、選別対象のデータ以
外の情報を、紹介すべき情報に結合する情報結合手段を
有することを特徴とする請求項１０または１１のいずれ
かに記載の情報センタにおけるサービス可変方式。
【請求項１４】前記サービスメニュー配信手段は、一
定期間を置いて利用端末にサービスメニューデータを配
信するよう構成したことを特徴とする請求項１記載の情
報センタにおけるサービス可変方式。
【請求項１５】前記サービスプログラム配信手段は、
申込みのあったサービスプログラムを利用者端末へのイ
ンストール方法の情報とともに配信するように構成した
ことを特徴とする請求項１記載の情報センタにおけるサ
ービス可変方式。