JP2006309744A - 情報サービス提供方法及び情報サービス提供システム - Google Patents

Abstract

【課題】情報・サービスの集中管理をせず、状況などの変化に対応でき、ダウンした場合でも情報・サービスの提供を継続して行うことができる情報サービス提供方法及び情報サービス提供システムを提供する。
【解決手段】ネットワーク上の情報・サービスを用いてユーザに適した情報・サービスを提供する情報サービス提供方法であって、ユーザのリクエストに応じて、リクエストを実現するために必要な処理フローを生成するステップと、処理フローを実行するために必要な情報サービスをネットワークから取得し、情報・サービスの集合を生成するステップと、ユーザに適した情報・サービスを提供するために、生成された情報・サービスの集合に基づいて処理フローを実行するステップとを有する。
【選択図】図４

Description

本発明は、ネットワーク上に分散された情報やサービスからユーザに適した情報・サービスを生成し、提供する情報サービス提供方法及び情報サービス提供システムに関する。

従来から、ユーザに有用な情報やサービスを提供するサービス連携装置が提案されている。このような装置が下記の特許文献１に開示されている。特許文献１に開示されている装置は、提供する情報やサービスを集中して管理しており、ユーザの要求に応じたサービスを提供するものである。また、特許文献１に開示された装置と違い、サービス間の連携関係を一局管理する連携サーバを用いずに、サービス提供サーバ間の相互信頼関係に基づいてサービスを提供するものが特許文献２に開示されている。また、これらの他に、ユーザの好みを反映したプログラム間のリレーションシップ（関係）を利用しサービスを選択し提供する方法が下記の特許文献３の中で提案されている。
特開２００４−１６４３１３号公報（要約） 特開２００５−４４１５８号公報（要約） 特開２００２−１７５４０５号公報（要約）

しかしながら、特許文献１に開示された技術では、一局で情報やサービスを管理しているため、サービス提供の処理が集中した場合に装置がダウンする可能性がある。また、膨大な情報を管理するため、大規模なシステムが必要になる。また、特許文献２に開示された技術では、サービス提供サーバ間の相互信頼関係に基づいてサービスを連携（提供）するため、ユーザの好みやコンテキスト（状況）を反映したサービスを提供することができない。また、特許文献３に開示された技術では、無線ネットワークで接続されているノードが何らかの原因によりダウンした場合にサービスを継続して提供することができない。また、サービスごとのリレーションシップ（関係）情報を定義する必要があるため、プログラム間で膨大なリレーションシップ（関係）が構築される可能性もある。

本発明は、上記問題を解決するためのものであり、情報・サービスの集中管理をせず、状況などの変化に対応でき、ダウンした場合でも情報・サービスの提供を継続して行うことができる情報サービス提供方法及び情報サービス提供システムを提供することを目的とする。

上記目的を達成するために、本発明によれば、ネットワーク上の情報・サービスを用いてユーザに適した情報・サービスを提供する情報サービス提供方法であって、前記ユーザのリクエストに応じて、前記リクエストを実現するために必要な処理フローを生成するステップと、前記処理フローを実行するために必要な情報・サービスを前記ネットワークから取得し、前記情報・サービスの集合を生成するステップと、前記ユーザに適した情報・サービスを提供するために、生成された前記情報・サービスの集合に基づいて前記処理フローを実行するステップとを有する情報サービス提供方法が提供される。この構成により、情報・サービスの集中管理をせず、状況などの変化に対応でき、ダウンした場合でも情報・サービスの提供を継続して行うことができる。ここで、「ネットワーク上の情報・サービスを用いて」とは、「ネットワークを介して得られる情報・サービスを用いて」という意味である。また、「情報・サービス」のサービスとは、例えばあるサービスを実行するための一連の命令を示すプログラムなどを言う。また、「情報・サービスの集合」とは、情報及び／又はサービスの集合を意味する。すなわち、情報のみの集合、サービスのみの集合、情報とサービスの集合の３つの態様が考えられる。

また、本発明において、前記処理フローを生成するステップで、前記リクエストに応じた、あらかじめ用意された基準データを読み出し、前記基準データと、あらかじめ構成された、前記リクエストを実現するためのサービスを示すノードのリレーションシップとに基づいて前記処理フローを生成することは、本発明の好ましい態様である。この構成により、容易に処理フローを生成することができる。

また、本発明において、前記リレーションシップが、前記ユーザの周囲の環境の状況、前記リレーションシップが成り立つ理由、前記ユーザの嗜好、前記リレーションシップの前記ノード同士の親和度及び信頼度の少なくとも１つによって構築、修正、破棄されることは、本発明の好ましい態様である。この構成により、それぞれのリレーションシップの強さを強度として表現することができる。

また、本発明において、前記処理フローを生成するステップで、前記基準データが存在しない又は利用しない場合には、前記リレーションシップの経路を探査し、前記リレーションシップの強度、親和度及び信頼度に基づいて前記処理フローを生成することは、本発明の好ましい態様である。この構成により、基準データを使用できなくても処理フローを生成することができる。

また、本発明において、前記処理フローを生成するステップで、前記処理フローは前記ユーザの周囲の環境の状況又は前記リクエストを実現するための情報・サービスを示すノードに対応する前記情報・サービスの提供状況に基づいて生成されることは、本発明の好ましい態様である。この構成により、周囲の状況を反映することができる。

また、本発明において、前記処理フローを生成するステップで、前記処理フローが前記リレーションシップの強度に基づいて生成されることは、本発明の好ましい態様である。この構成により、リレーションシップの強度を反映することができる。

また、本発明において、前記リレーションシップの強度が前記ユーザの周囲の環境の状況又は前記ノードに対応する前記情報・サービスの提供状況に応じて変化することは、本発明の好ましい態様である。この構成により、周囲の状況を反映することができる。

また、本発明において、前記リレーションシップを構成する情報・サービスを示すノードを前記情報・サービスの上位概念で抽象化して表現することは、本発明の好ましい態様である。この構成により、適用範囲を広げることが可能となる。

また、本発明において、前記リレーションシップが特有の意味に基づいて張られていることは、本発明の好ましい態様である。この構成により、より適した情報・サービスを提供することが可能となる。

また、本発明において、生成された前記情報・サービスの集合に基づいて前記処理フローを実行し、該当の処理をしている際に情報・サービスの提供を受けられなくなった場合に、前記処理フローで用いられる前記情報・サービスの集合のうちのいずれかから情報・サービスの提供を継続して受けられることは、本発明の好ましい態様である。この構成により、継続して情報・サービスの提供を受けることができる。

また、本発明において、前記情報・サービスを示すノードが、一定の目的で一連の結果を得るためのプログラム、オブジェクト、機器を示すノードのうちいずれか１つであることは、本発明の好ましい態様である。この構成により、適用範囲を広げることができる。

また、本発明において、少なくとも前記リレーションシップを管理するレイヤと前記処理フローの生成を管理するレイヤとから構成されるシステムによって前記情報・サービスの提供をすることは、本発明の好ましい態様である。この構成により、それぞれレイヤで特徴ある処理を管理することができる。

また、本発明において、前記処理フローを実行するステップで、前記情報・サービスの提供を受ける前記ユーザの周囲の環境の変化に基づいて、生成された前記処理フローの実行の継続が可能であるか否かを判断し、前記処理フローの実行が継続できない場合には前記処理フローを再度生成することは、本発明の好ましい態様である。この構成により、環境の変化に応じた適切なサービスを提供することができる。なお、ユーザの周囲の環境の変化とは、例えばリクエストが実行される場所（目的地など）の天気や温度などの変化を言う。

また、本発明によれば、ネットワーク上の情報・サービスを用いてユーザに適した情報・サービスを提供する情報サービス提供システムであって、前記ユーザのリクエストに応じて、前記リクエストを実現するために必要な処理フローを生成し、前記処理フローを実行するために必要な情報・サービスを前記ネットワークから取得し、前記情報・サービスの集合を生成するサービス生成部と、前記ユーザに適した情報・サービスを提供するために、生成された前記情報・サービスの集合に基づいて前記処理フローを実行するサービス実行部とを備える情報サービス提供システムが提供される。この構成により、情報・サービスの集中管理をせず、状況などの変化に対応でき、ダウンした場合でも情報・サービスの提供を継続して行うことができる。

また、本発明において、前記情報・サービスの提供を受ける前記ユーザの周囲の環境の変化に基づいて、生成された前記処理フローの実行の継続が可能であるか否かを判断する判断手段をさらに備えることは、本発明の好ましい態様である。この構成により、環境の変化に応じた適切なサービスを提供することができる。なお、ユーザの周囲の環境の変化とは、例えばリクエストが実行される場所（目的地など）の天気や温度などの変化を言う。

本発明の情報サービス提供方法及び情報サービス提供システムは、上記構成を有し、情報・サービスの集中管理をせず、状況などの変化に対応でき、ダウンした場合でも情報・サービスの提供を継続して行うことができる。

＜第１の実施の形態＞
以下、本発明の第１の実施の形態に係る情報サービス提供方法が用いられるネットワーク環境について図１を用いて説明する。図１に示すように、ネットワーク１００には、情報やサービスを提供するプロバイダ１０１ａ、１０１ｂ、車両に搭載された車載情報機器１０２ａ、１０２ｂ、１０２ｃ（以下、単に車載情報機器１０２とも言う）、センタサーバ１０３、端末１０４などが接続されている。ここで、本発明の第１の実施の形態に係る情報サービス提供方法を実現するためのシステム論理構成について図２を用いて説明する。図２に示すように４つのレイヤから構成されている。４つのレイヤは、広域網、狭域網、車車間通信をつかさどる物理レイヤ、情報・サービスエージェントのリレーションシップの導入をつかさどる論理レイヤ、サービス（発見、サービス生成、情報配布）の定義をつかさどるサービスレイヤ、個別アプリケーション（ナビゲーション、エンターテイメント・各種情報提供、セーフティ・セキュリティ・メンテナンス、パソコン・携帯端末と車載情報機器のシームレス化）をつかさどるアプリケーションレイヤである。本発明は、論理レイヤのリレーションシップに基づくサービスレイヤのサービス生成を１つの特徴としている。ここで、エージェントとは自律分散型のプログラムを言う。

以下では、説明を分かりやすくするため、車両に搭載された車載情報機器１０２を中心とした情報提供方法について説明する。図３には車両に搭載された車載情報機器１０２と車両内の構成要素との物理構成が示されている。ここで、プログラム、オブジェクト、サービス及び機器をエージェントと表現している。この意味で上述したリレーションシップ（リレーションとも言う）とはエージェント間の関係（つながり）を言う。車載情報機器１０２、車内に持ち込まれた携帯電話などの持込情報機器３００、ライト３０１、オーディオなどの車載情報機器３０２、窓３０３のエージェントはそれぞれ有線又は無線でつながっており、Ｐ２Ｐが採用されている。また、車載情報機器１０２のエージェントは他車や情報家電などの外部機器３０４のエージェントと無線によってつながっている。

次に、エージェントの内部構成について図４を用いて説明する。図４に示すように、エージェント４００は、リレーション管理部４０１、制御部４０２、プロファイル保持領域４０３、サービス発見部４０４、サービス生成部４０５、サービスメタデータ保持領域４０６、サービス実行部４０７から構成されている。リレーション管理部４０１は、エージェント間のリレーション（論理レイヤ）を管理するものである。また、リレーション管理部４０１は属性部を有しており、この属性部は後述するサービス生成のためのリレーションの属性（コンテキスト、プリファレンスなど）とリレーションの強度とを管理するものである。このリレーションの強度とは、例えば経験的に学習された実績の頻度などを言い、ユーザの嗜好、リレーションの親和度や信頼度に基づくものである。

制御部４０２はエージェントの基本的な動作の制御を行うものである。プロファイル保持領域４０３はユーザ、オブジェクト、サービス、機器などに関する情報を保持するものである。サービス発見部４０４は、例えば車内外で利用可能なサービスを発見するものである。サービス生成部４０５は、サービス発見部４０４で発見されたサービスの合成（処理フローの生成）を行うエンジンである。サービスメタデータ保持領域４０６は、後述する処理フローを生成するための抽象化されたテンプレートデータ（以下、メタデータとも言う）を保持するものである。サービス実行部４０７は、生成された処理フローに基づいて処理を行うものである。

ここで、ユーザからリクエストが出され、そのリクエストを実現するためのサービスを実行するフローの概略を図５に示す。図５に示すように、ユーザ又は外部システムから車載情報機器１０２にリクエストが出されると、適切なエージェントが動作（適切なエージェントを実行）し、そのエージェントは処理フローを生成し、生成された処理フローのサービスリストをユーザなどに提示し、ユーザなどからの実行許可が出されると、処理フローを実行することになる。ユーザがあらかじめサービス実行許可を与えている場合は生成された処理フローのサービスリストをユーザなどに提示せず、処理フローを実行してもよい。

次に、エージェントに関するクラス図について図６を用いて説明する。エージェントはそれぞれ制御部４０２、リレーション管理部４０１、サービス生成部４０５、サービス実行部４０７、サービス発見部４０４に分けられる（クラス化される）。制御部４０２はプロファイル保持領域（プロファイル）４０３を管理している。このプロファイル４０３は、例えば保持する情報の種類やタイプ、保持する情報（データ）、情報の履歴などから構成されている。また、リレーション管理部４０１はリレーションの始点（From）と終点（To）、リレーションの強度、属性を管理している。そして、リレーション管理部４０１の属性部では、リレーションの属性である、例えば意味（抽象）、コンテキスト（状況）、所有者などを管理している。また、サービス生成部４０５は処理フローを生成するためのメタデータを管理している。

ここで、リクエストから処理フローが生成されるまでを具体的な例を用いて説明する。今、車両に乗っているユーザから食事をしたいというリクエストが出されたとする。このとき、上述したサービスメタデータ保持領域４０６から「車→レストランへナビゲート」という処理フローを生成するためのメタデータが取得される。そして、図７に示すようなあらかじめ構成されたリレーション図から図８に示すような処理フローを生成する。図７に示すように、それぞれのサービスを示すノード間にはリレーションシップが張られている。ノード間が太い線でつながれているのは上述したリレーションシップの強度が大きいということを示している。図８に示す処理フローから、車に乗っているときに食事をしたいということであれば、まず、駐車場を発見し、駐車場の予約をしなければならない。そして、次にレストランを発見し、予約しなければならない。そして、予約ができた段階でそのレストランへナビゲートしなければならない。このような一連の処理を示す処理フローでの実行許可がユーザから下されると処理フローが実行される。なお、この処理フローを生成する際、リレーションの強さやユーザの嗜好などに基づいて生成されるようにしてもよい。

次に、上述したサービスメタデータの他の態様について図９Ａ及び図９Ｂを用いて説明する。図９Ａに示すように、「イタリアンで食事をする」というリクエストから「レストランへナビゲートする」というメタデータに、「レストランを予約する」や「駐車場を予約する」というサブゴールを付加したメタデータも考えられる。これは、処理フローを生成するときに必ず用いてもらいたいものを示したものである。すなわち、レストランへナビゲートする際、必ずレストランの予約と駐車場の予約を行うような処理フローが生成される。そのときのアルゴリズムの記述例が図９Ｂに示されている。なお、このサブゴールが別のメタデータとして再利用されるようにしてもよい。

次に、上述した処理フローを生成すると同時に処理フローを実行する際に利用されるクラスタリング（エージェントの集合）を生成する必要がある。例えば、上述した例で言えば、図１０に示すように駐車場を発見する際に、現状で該当する駐車場のサービスをグループ化してサービスクラスタとして生成する。なお、処理フローを実行する際、個々の駐車場サービス（エージェント）ではなくサービスクラスタにマッピングする。これにより、ある処理フローを実行している最中にあるサービスが落ちても他のサービスを利用することが可能となり、継続してサービスの提供を受けることができる。

次に、ユーザのリクエストからそのリクエストが実行されるまでのフローについて図１１Ａ及び図１１Ｂを用いて説明する。図１１Ａに示すように、まず、ユーザからのリクエストがあると、サービス生成部４０５はリクエスト分析を行う（ステップＳ１１０１）。すなわち、そのリクエストがどのようなリクエストであるかを判断する。次に、サービス生成部４０５は、リクエストに応じたメタデータをサービスメタデータ保持領域４０６から取得する（ステップＳ１１０２）。そして、サービス生成部４０５は、取得されたメタデータ及びあらかじめ構成されたリレーションに基づいて処理フローを生成（意味マッチング）する（ステップＳ１１０３）。そして、サービス生成部４０５は処理フローを実行するために必要な上述したサービスクラスタを生成（サービス合成）する（ステップＳ１１０４）。

処理フロー及びサービスクラスタが生成された後に処理フローの実行ステップに移行する。サービス実行部４０７は、処理フローに基づいてサービスクラスタから適当なサービス（エージェント）を選択（インスタンスマッピング）する（ステップＳ１１０５）。そして、サービス実行部４０７は処理フローを実行する（ステップＳ１１０６）。その後、サービス実行部４０７は、処理フローを実行している最中にコンテキスト（状況）が変化したか否かを判断する（ステップＳ１１０７）。このようにコンテキストの変化を監視するのは、処理フローを実行している最中にコンテキストが変化（例えば、目的としている駐車場サービスの営業時間が終了してしまうような場合）したら、別のサービスクラスタのサービスを受けられるようにするためである。

そして、コンテキストが変化し、サービスクラスタに別のサービスが存在しなくなった場合には、サービス実行部４０７は、再度リクエストに応じたサービスクラスタなどを生成するためにバックトラック（後戻り）させる（ステップＳ１１０８）。バックトラックされると、サービス実行部４０７は、再度リクエストに対処できるようなリクエストを生成し（ステップＳ１１０９）、サービス生成部４０５へ送られる。一方、ステップＳ１１０７において、コンテキストが変化していない場合には、処理フローの実行が終了したか否かを判断する（ステップＳ１１１０）。そして、終了していなければ、ステップＳ１１０５に戻り、終了していれば終了する。図１１Ｂには、上述したフローの概略を示す図が示されており、ステップＤにおいては、コンテキストが変化し、かつサービスクラスタに別のサービスが存在しないとバックトラックされることが示されている。

次に、実際に上述した情報提供方法を適用したアプリケーションについて説明する。まず、１つのアプリケーションとしてビデオフォンサービスアプリケーションについて図１２を用いて説明する。これは、モバイルフォン（携帯電話など）のユーザが、例えば車両Ａの搭乗者とビデオフォンをする場合を想定している。このときメタデータとしては、例えば「車→ビデオフォン」であり、このメタデータに基づいて車両Ａの車載情報機器（エージェント）が図１２に示すような処理フローを生成する。これにより、モバイルフォンのユーザと車両Ａの搭乗者は電話会社やセンタサーバなどを介してビデオフォンをすることができる。このとき、ユーザが運転者であり運転中の場合は、モバイルフォンのユーザの状況に適したキーワードで自動応答（例えば、運転中のため通話のみ若しくは運転中のためサービスの利用ができませんなどの応答を）しサービスの実行を制御することもある。

次に、他のアプリケーションとして、車内におけるハンズフリーアプリケーションについて図１３を用いて説明する。これは、携帯電話の機能（スピーカ、マイク、カメラなど）を車載情報機器と連携させてハンズフリーを実現するものである。この場合、リクエストとしてはハンズフリーを実現したいというものであり、実際に処理を始めるトリガーとなるものは、例えば車内への人の入室である。車内に人が入ると、例えばメタデータ「車→ハンズフリー」に基づいて、車載情報機器（エージェント：ＶＡ）は図１３に示すような処理フローを生成する。このとき、車内に一人、すなわち携帯電話が１台しかない場合にはクラスタリングはされない。このように携帯電話と車内のマイクやスピーカなどをつなげてあげることによってハンズフリーを実現することができる。

なお、このような構成において、例えばスケジュールにない上司からの電話や交差点などを曲がっている最中の電話ならば、ＶＡがそれを感知して「運転中です」と自動応答させることも可能である。また、打ち合わせに向かっている最中に上司から電話があった場合にはＶＡがそれを感知して「あと５分で到着します」と自動応答させることも可能である。また、恋人や家族などの親しい者からの電話ならば、ＶＡがそれを感知して電話をつなげたり、車載カメラと連動させ周辺画像を送信してＴＶ電話とさせることも可能である。

次に、他のアプリケーションとして、車内におけるエンターテイメントサービスアプリケーションについて図１４を用いて説明する。これは、車内に持ち込まれた情報機器（携帯電話、ＰＣ、ＰＤＡなど）からコンテキスト（周辺状況、車内状況）に合った音楽データや動画ファイルを発見し車内で再生するものである。この場合も上述したアプリケーション例と同様に、実際に処理を始めるトリガーとなるものは、例えば車内への人の入室である。車内に人が入ると、例えばメタデータ「車→音楽、ビデオの再生」に基づいて、車載情報機器は図１４に示すような処理フローを生成する。このとき、処理フローを実行するために必要な音楽データや動画ファイルのクラスタリングをするが、クラスタリングをする際、周辺の状況が昼間ならば昼間に合う音楽データや動画ファイルをクラスタリングするようにしてもよい。

次に、他のアプリケーションとして、車内におけるカラオケサービスアプリケーションについて図１５を用いて説明する。これは、周辺物に関連したイントロを流し、車内でカラオケを楽しむものであり、規定部分まで歌いきったらクーポン券などのサービスを受けられるようにしてもよい。この場合、リクエストとしては車内でカラオケをしたいというものであり、実際に処理を始めるトリガーとなるものは、例えば車外カメラの車両周辺物の画像の取得である。車外カメラによって車両周辺物の画像が取得されると、例えばメタデータ「車→カラオケ」に基づいて、車載情報機器は図１５に示すような処理フローを生成する。このとき、処理フローの生成と同時にカラオケコンテンツを配信する装置（エージェント）をクラスタリングする。このように構成することによって、車外カメラから取得される車両周辺の風景に合ったカラオケコンテンツを流すことも可能となる。

次に、他のアプリケーションとして、車内におけるゲームサービスアプリケーションについて説明する。これは、既に処理フローが生成された状態において、落下するブロックを積み上げ、所定量積み上げた場合に積み上げたブロックが消滅して、消滅させたブロックの数で得点を競うゲームをしている場合に、車外カメラから取得された画像にトラックなどが写っていれば、あらかじめ構成されたリレーション（例えば、トラック、バス、建物などとブロックとに張られているリレーション）に基づいてトラックをブロックに変換し、ゲーム上にブロックとして落下させて車外の情報をゲームに当てはめるものである。なお、ゲームは上述したゲームに限られるものではなく、自車が走行する走行路をレーシングコースと見立ててバーチャルレースをするゲームであってもよい。この場合、周辺物（例えば、走行路上に置かれている物）を岩としてリレーションに基づいて変換させ、その岩をコース上に置くようにしてもよい。

次に、他のアプリケーションとして、ドライブスルーサービスアプリケーションについて図１６を用いて説明する。これは、車両の搭乗者がハンバーガーなどのファーストフードを食べたいときに車両を降りずに購入できるドライブスルーを実現する場合のものである。この場合、リクエストとしては車両を降りずにファーストフードを食べたいというものであり、このときメタデータとしては、例えば「車→ファーストフードにナビゲート」であり、このメタデータに基づいて車両の車載情報機器が図１６に示すような処理フローを生成する。このとき、処理フローの生成と同時にファーストフード店（エージェント）をクラスタリングする。このように構成することによって、ファーストフード店からのメニューを車載情報機器に表示し、メニューに基づいて注文し、その際の決済をクレジットサービスで自動的に行い、商品を受け取ることが可能となる。

次に、他のアプリケーションとして、他のケースのレストラン予約サービスアプリケーションについて説明する。これは、コンテキスト（天気や同乗者など）に合ったレストランを発見し、メニューとお店の雰囲気を取得し、気に入れば駐車場とお店の予約後に経路案内を行うものである。この場合、処理を始めるトリガーとなるものは、例えばコンテキストである。すなわち、天気、同乗者、時間（お昼）などのコンテキストをトリガーとして、レストランへナビゲートをするために処理フローなどを生成する。なお、このとき生成される処理フローは上述したレストラン予約の場合と同じであるため説明を省略する。処理フローと同時に生成される、例えばレストラン（エージェント）のサービスクラスタは、天気がよく、恋人同士で、お昼時に合うオープンテラスレストランなどによって構成される。

次に、他のアプリケーションとして、観光案内サービスアプリケーションについて図１７を用いて説明する。これは、旅行先で新鮮なイベント情報を取得し、観光地をガイドするものである。この場合、処理を始めるトリガーとなるものは、例えば車外カメラによる画像の取得である。画像が取得されると、例えばメタデータ「車→観光案内を聞く」に基づいて図１７に示すような処理フローが生成される。このとき処理フローと同時に生成されるサービスクラスタは、観光案内情報を有する旅行会社などによって構成される。このように構成されることにより、取得された画像に伴った観光案内を受けることが可能となる。なお、車両から外に出た場合には、携帯電話などにサービスを移動させてガイドするようにしてもよい。

次に、他のアプリケーションとして、思い出サービスアプリケーションについて図１８を用いて説明する。これは、昔に来たことがある場所での風景やレストラン（思い出の味）を提供するものである。この場合、例えば、昔食べたあの食事をしたいというリクエストに基づいて、例えばメタデータ「車→昔食べた食事」が取得され、このメタデータに基づいて、例えば「思い出」という意味で張られたリレーションから図１８に示すような処理フローを生成する。このとき同時に生成されるある１つのサービスクラスタは、例えばレストラン（エージェント）についてのものであるが、このレストランは昔なつかしいレストラン（エージェント）で構成される。このように構成されることにより、昔食べておいしかった食事を出すレストランなどを提供することが可能となる。なお、このアプリケーションはレストランに限られるものではない。

＜第２の実施の形態＞
以下に本発明の第２の実施の形態について説明する。第２の実施の形態ではエージェントの構成が第１の実施の形態と相違する。第２の実施の形態でのエージェントの構成について図１９を用いて説明する。図１９に示すように、第２の実施の形態でのエージェント１９００には、第１の実施の形態のエージェントの構成要素にコンテキスト監視部１９０８と推論実行部１９０９が付加されている。また、コンテキスト監視部１９０８と通信可能であってエージェント１９００の構成要素ではないセンサー１９１０が第２の実施の形態では存在する。なお、第１の実施の形態のエージェントの構成要素と同じ名称のエージェント１９００の構成要素の機能は、第１の実施の形態のエージェントの対応する構成要素と基本的に同じであり、エージェント１９００は処理フローの生成などの基本的な処理も行う。

まず、センサー１９１０は、設定された目的地の天気、気温、湿度などの情報を有している。コンテキスト監視部１９０８は、センサー１９１０が有する情報に変化があるか否かを監視しているものである。推論実行部１９０９は、コンテキスト監視部１９０８によって監視されている情報に変化が生じた場合に、コンテキスト監視部１９０８から制御部１９０２を介して受けた変化の内容を示す変化情報（例えば、目的地が晴れから雨に変わったという情報）に基づいて設定されたサービスを変更すべきか否かを判断するものである。

次に、本発明の第２の実施の形態におけるコンテキストの変化による処理フローの作成フローについて図２０を用いて説明する。ユーザから「イタリアンレストランで食事をしたい」というリクエストが出されて処理フローの作成フローが開始される。まず、エージェントはリクエスト分析を行い、メタデータを取得する（ステップＳ２００１）。そして、エージェントはコンテキスト情報（天気：晴れ、現在地：横浜、目的地：青山、目的地温度：２４度など）をセンサー１９１０から取得する（ステップＳ２００２）。そして、エージェントは、取得されたコンテキスト情報の天気や温度などからオープンテラスのあるイタリアンレストランで食事すると推定し処理フローを生成する条件推定（ステップＳ２００３）、第１の実施の形態と同様の処理であるサービス合成（ステップＳ２００４）やインスタンスマッピング（ステップＳ２００５）やサービスフロー実行（ステップＳ２００６）を行う。すなわち、エージェントは青山周辺のオープンテラスがあるイタリアンレストランを見つけ、オープンテラス席と周辺の駐車場の予約を行い、予約した駐車場へ誘導する。

そして、エージェントはコンテキスト情報を取得する（ステップＳ２００７）。このとき取得されるコンテキスト情報は、例えば「天気：雨、現在地：横浜、目的地：青山、目的地温度：２０度」という情報である。すなわち、天気が晴れから雨に変わり、温度も２４度から２０度に変化している。ここで、エージェントは取得したコンテキストが変化したか否かを判断する（ステップＳ２００８）。コンテキストが変化したと判断した場合、エージェントは設定されているサービスが継続可能か否かを判断する（ステップＳ２００９）。サービス継続が不可能である場合には、第１の実施の形態の場合と同様にバックトラック（ステップＳ２０１０）及びリクエスト生成(ステップＳ２０１１)、すなわち「青山のイタリアンレストランの店内で食事をする」というリクエストの生成を行い、ステップＳ２００１に戻る。

一方、ステップＳ２００８でコンテキストが変化していないと判断された場合、及びステップＳ２００９でサービス継続が可能であると判断された場合には、エージェントはサービスフロー実行が終了したか否かを判断する（ステップＳ２０１２）。終了していない場合にはステップＳ２００５に戻り、終了している場合には終了する。なお、ステップＳ２００２及びステップＳ２００７で取得されるコンテキスト情報は、コンテキスト監視部１９０８によって常時監視され保持された情報である。

本発明に係る情報サービス提供方法及び情報サービス提供システムは、情報・サービスの集中管理をせず、状況などの変化に対応でき、ダウンした場合でも情報・サービスの提供を継続して行うことができるため、ネットワーク上に分散された情報やサービスからユーザに適した情報・サービスを提供する情報サービス提供方法及び情報サービス提供システムなどに有用である。

本発明の第１の実施の形態に係る情報提供方法が用いられるネットワーク環境について説明するための概略図である。 本発明の第１の実施の形態に係る情報提供方法を実現するためのシステム論理構成を示す図である。 本発明の第１の実施の形態に係る情報提供方法を実現する車両に搭載された車載情報機器と車両内の構成要素との物理構成を示す図である。 本発明の第１の実施の形態に係る情報提供方法を実現するエージェントの内部構成を示す図である。 本発明の第１の実施の形態に係る情報提供方法において、ユーザからリクエストが出され、そのリクエストを実現するためのサービスを実行するフローの概略を示す図である。 本発明の第１の実施の形態に係る情報提供方法を実現するエージェントに関するクラス図を示す図である。 本発明の第１の実施の形態に係る情報提供方法におけるリレーションを示す図である。 本発明の第１の実施の形態に係る情報提供方法における処理フローを示す図である。 本発明の第１の実施の形態に係る情報提供方法におけるサービスメタデータの他の態様について説明するための図である。 本発明の第１の実施の形態に係る情報提供方法におけるサービスメタデータのアルゴリズムの記述例を示す図である。 本発明の第１の実施の形態に係る情報提供方法におけるサービスクラスタを示す図である。 本発明の第１の実施の形態に係る情報提供方法におけるユーザのリクエストからそのリクエストが実行されるまでのフローを示すフローチャートである。 本発明の第１の実施の形態に係る情報提供方法におけるユーザのリクエストからそのリクエストが実行されるまでのフローの概略を示す図である。 本発明の第１の実施の形態に係る情報提供方法において、ビデオフォンサービスアプリケーションについて説明するための図である。 本発明の第１の実施の形態に係る情報提供方法において、車内におけるハンズフリーアプリケーションでの処理フローを示す図である。 本発明の第１の実施の形態に係る情報提供方法において、車内におけるビデオサービスアプリケーションでの処理フローを示す図である。 本発明の第１の実施の形態に係る情報提供方法において、車内におけるカラオケサービスアプリケーションでの処理フローを示す図である。 本発明の第１の実施の形態に係る情報提供方法において、ドライブスルーサービスアプリケーションについて説明するための図である。 本発明の第１の実施の形態に係る情報提供方法において、観光案内サービスアプリケーションでの処理フローを示す図である。 本発明の第１の実施の形態に係る情報提供方法において、思い出サービスアプリケーションでの処理フローを示す図である。 本発明の第２の実施の形態に係る情報提供方法を実現するエージェントの内部構成を示す図である。 本発明の第２の実施の形態に係る情報提供方法におけるコンテキストの変化による処理フローの作成フローについて説明するためのフローチャートである。

符号の説明

１００ ネットワーク
１０１ａ、１０１ｂ プロバイダ
１０２、１０２ａ、１０２ｂ、１０２ｃ 車載情報機器
１０３ センタサーバ
１０４ 端末
３００ 持込情報機器
３０１ ライト
３０２ 車載情報機器（オーディオなど）
３０３ 窓
３０４ 外部機器
４００、１９００ エージェント
４０１、１９０１ リレーション管理部
４０２、１９０２ 制御部
４０３、１９０３ プロファイル保持領域
４０４、１９０４ サービス発見部
４０５、１９０５ サービス生成部
４０６、１９０６ サービスメタデータ保持領域
４０７、１９０７ サービス実行部
１９０８ コンテキスト監視部
１９０９ 推論実行部（判断手段）
１９１０ センサー

Claims (15)

1. ネットワーク上の情報・サービスを用いてユーザに適した情報・サービスを提供する情報サービス提供方法であって、
   前記ユーザのリクエストに応じて、前記リクエストを実現するために必要な処理フローを生成するステップと、
   前記処理フローを実行するために必要な情報・サービスを前記ネットワークから取得し、前記情報・サービスの集合を生成するステップと、
   前記ユーザに適した情報・サービスを提供するために、生成された前記情報・サービスの集合に基づいて前記処理フローを実行するステップとを、
   有する情報サービス提供方法。
2. 前記処理フローを生成するステップにおいて、前記リクエストに応じた、あらかじめ用意された基準データを読み出し、前記基準データと、あらかじめ構成された、前記リクエストを実現するための情報・サービスを示すノードのリレーションシップとに基づいて前記処理フローを生成する請求項１に記載の情報サービス提供方法。
3. 前記リレーションシップは、前記ユーザの周囲の環境の状況、前記リレーションシップが成り立つ理由、前記ユーザの嗜好、前記リレーションシップの前記ノード同士の親和度及び信頼度の少なくとも１つによって構築、修正、破棄される請求項２に記載の情報サービス提供方法。
4. 前記処理フローを生成するステップにおいて、前記基準データが存在しない又は利用しない場合には、前記リレーションシップの経路を探査し、前記リレーションシップの強度、親和度及び信頼度に基づいて前記処理フローを生成する請求項２又は３に記載の情報サービス提供方法。
5. 前記処理フローを生成するステップにおいて、前記処理フローは前記ユーザの周囲の環境の状況又は前記リクエストを実現するための情報・サービスを示すノードに対応する前記情報・サービスの提供状況に基づいて生成される請求項１に記載の情報サービス提供方法。
6. 前記処理フローを生成するステップにおいて、前記処理フローは前記リレーションシップの強度に基づいて生成される請求項２から４のいずれか１つに記載の情報サービス提供方法。
7. 前記リレーションシップの強度は、前記ユーザの周囲の環境の状況又は前記ノードに対応する前記情報・サービスの提供状況に応じて変化する請求項４又は６に記載の情報サービス提供方法。
8. 前記リレーションシップを構成する情報・サービスを示すノードを前記情報・サービスの上位概念で抽象化して表現する請求項２から４、６、７のいずれか１つに記載の情報サービス提供方法。
9. 前記リレーションシップが特有の意味に基づいて張られている請求項２から４、６から８のいずれか１つに記載の情報サービス提供方法。
10. 生成された前記情報・サービスの集合に基づいて前記処理フローを実行し、該当の処理をしている際に情報・サービスの提供を受けられなくなった場合に、前記処理フローで用いられる前記情報・サービスの集合のうちのいずれかから情報・サービスの提供を継続して受けられる請求項１から９のいずれか１つに記載の情報サービス提供方法。
11. 前記情報・サービスを示すノードは、一定の目的で一連の結果を得るためのプログラム、オブジェクト、機器を示すノードのうちいずれか１つである請求項２から４、６から１０のいずれか１つに記載の情報サービス提供方法。
12. 少なくとも前記リレーションシップを管理するレイヤと前記処理フローの生成を管理するレイヤとから構成されるシステムによって前記情報・サービスの提供をする請求項２から４、６から１１のいずれか１つに記載の情報サービス提供方法。
13. 前記処理フローを実行するステップにおいて、前記情報・サービスの提供を受ける前記ユーザの周囲の環境の変化に基づいて、生成された前記処理フローの実行の継続が可能であるか否かを判断し、前記処理フローの実行が継続できない場合には前記処理フローを再度生成する請求項１から１２のいずれか１つに記載の情報サービス提供方法。
14. ネットワーク上の情報・サービスを用いてユーザに適した情報・サービスを提供する情報サービス提供システムであって、
    前記ユーザのリクエストに応じて、前記リクエストを実現するために必要な処理フローを生成し、前記処理フローを実行するために必要な情報・サービスを前記ネットワークから取得し、前記情報・サービスの集合を生成するサービス生成部と、
    前記ユーザに適した情報・サービスを提供するために、生成された前記情報・サービスの集合に基づいて前記処理フローを実行するサービス実行部とを、
    備える情報サービス提供システム。
15. 前記情報・サービスの提供を受ける前記ユーザの周囲の環境の変化に基づいて、生成された前記処理フローの実行の継続が可能であるか否かを判断する判断手段をさらに備える請求項１４に記載の情報サービス提供システム。
    

Images