(57)【要約】 【課題】  複雑なユーザ希望又はタスクに、より柔軟で、より信頼できる方法で応えることができるネットワークデバイスに対するユーザリクエスト供給方法を提供することである。【課題を解決するための手段】  各デバイスについて、少なくとも１つの理論的機能モデルが生成されるユーザリクエスト供給方法を提案する。与えられたユーザリクエストは、その理論的タスクモデルを生成することにより、理論的な方法で、モデル化及び表現される。更に、別個のデバイスの複数の理論的機能モデルは、組み合わせられ、１組の配列された外部モデルによって形式的に合体され、モデル化される。これによって、組み合わせられた単一のデバイスの機能をモデル化する理論的な仮想デバイスのモデルを生成する。【選択図】  図８
2004342113.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークデバイス及び該ネットワークデバイスの制御に関するユーザリクエストを供給するユーザリクエスト供給方法であって、
前記ネットワークの各デバイス及び各デバイスクラスのために理論的な方法で各々の機能をモデル化するために、前記ネットワークのデバイス及び各デバイスクラスに対し、少なくとも１つの理論的な個別の機能モデルを生成し、提供し、使用し、
与えられたユーザリクエストは、その理論的なタスクモデルを生成し、提供し、使用することによって、各場合について理論的な方法でモデル化及び表現し、
各個別の単一のデバイスにおける複数の理論的な個別の機能モデルが、
外部モデルを用いて組み合わされ、
形式的に結合され、
外部モデルの指定された組合せを介してモデル化され、
これにより、理論的な方法で、それぞれの別個、又は組み合わせた単一のデバイスの組合せモデルの機能をモデル化する理論的な仮想デバイスのモデルが作成されることを特徴とするユーザリクエスト供給方法。
【請求項２】
少なくとも単一の個別デバイス、又はその一部の１つの組合せのためのものであり、前記単一の個別デバイスの１つの機能ではない１つの機能を推定する１つのステップ又は１つの副プロセスが実行されることを特徴とする請求項１記載のユーザリクエスト供給方法。
【請求項３】
前記機能モデルは、ネットワーク中の各デバイスに対して、グローバルな形で、デバイス情報データ、アクション情報データ等を導出、格納及び使用するステップで採用されることを特徴とする請求項１記載のユーザリクエスト供給方法。
【請求項４】
各々の前記機能モデルは、少なくとも１つの外部モデルを含むように選択されて組み立てられ、該１つの外部モデルは、それぞれのデバイス又はデバイスクラスに送信されるデータ、又は入力データ、それぞれのデバイス又はデバイスクラスから送信されるデータ又は出力データをモデル化し、適当なデバイスを見つけ出すために使用される特別の機能に依存していることを特徴とする請求項１乃至３のいずれか１項記載のユーザリクエスト供給方法。
【請求項５】
各々の前記機能モデルは、内部モデルにより組み立てられるか、内部モデルを含むように選択され、特に有限状態機械、有限状態オートマトン等をして取り得る状態、状態間の取り得る遷移、更にはそれぞれのデバイス、デバイスクラス等の前記状態遷移を初期化するための取り得るアクションについての記述としてであり、それぞれのデバイス、デバイスクラスを制御する計画を生成することについての記述であることを特徴とする請求項１乃至４のいずれか１項記載のユーザリクエスト供給方法。
【請求項６】
前記内部モデルが、少なくとも１つのデバイス、デバイスクラスに対して、少なくとも１つの追加のデバイス、１つの追加のデバイスクラスの必要性について記述のある事前条件、及び事後条件を伴った状態を有することを特徴とする請求項５記載のユーザリクエスト供給方法。
【請求項７】
前記入力データ及び出力データに従って、内部モデルと外部モデル間で、接続、割当等が確立されることを特徴とする請求項４乃至６のいずれか１項記載のユーザリクエスト供給方法。
【請求項８】
前記各機能モデルは、関連するデバイス間の可能ある接続を表す接続モデルを含むように選択されることを特徴とする請求項１乃至７のいずれか１項記載のユーザリクエスト供給方法。
【請求項９】
各デバイスに対して、複数の外部モデルが生成され、提供され、使用されることを特徴とする請求項１乃至８のいずれか１項記載のユーザリクエスト供給方法。
【請求項１０】
基本の外部モデルは、入力データ及び出力データについて、少なくとも１つの基本プロセス又は前記出力データに前記入力データを接続するサービスについての情報を少なくとも含む前記外部モデルとして使用されることを特徴とする請求項９記載のユーザリクエスト供給方法。
【請求項１１】
受信ユーザリクエストから取り出され、与えられたタスクのそれぞれについて、前記与えられたタスクの１組のモデルとして、与えられたタスクの入力データを、与えられたタスクの出力データに接続して、基本のタスクの１つの列を生成し、提供し、使用することを特徴とする請求項１乃至１０のいずれか１項記載のユーザリクエスト供給方法。
【請求項１２】
与えられたタスクに属する基本のタスクの複数列から、与えられた複雑な要求、信頼度の要求を満たす部分を、前記与えられたタスクモデルとして選択することを特徴とする請求項１１記載のユーザリクエスト供給方法。
【請求項１３】
ユーザリクエストを受信し、処理することにより、前記ユーザリクエストを表現しているリクエスト情報データを生成し、格納し、使用するステップと、
少なくともユニットやデバイスについての情報を含んでおり、前記ユーザリクエストに関し必要で適切なマンマシンインタフェースユニットに利用可能である、前記ユニットや、デバイスの取り得る状態についての情報を含んでいるデバイス情報データを提供し、生成し、格納し、使用するステップと、
前記ユーザリクエストに関し適切であるアクション列について、前記リクエスト情報データ、前記デバイス情報データ等に従った情報を含むアクション情報データを提供し、生成し、格納するステップと、
適切に前記ユーザリクエストに応答するように前記アクション情報データに従うアクションの前記列の少なくとも１つを実行することを特徴とする請求項１乃至１２のいずれか１項記載のユーザリクエスト供給方法。
【請求項１４】
ユーザの希望を表す複雑なユーザリクエスト、所望のタスク、サービス、デバイス、又はその列若しくは組が、前記ネットワークの必要なデバイスを幾つか含む形で前記ユーザリクエストとして受信されることを特徴とする請求項１乃至１３のいずれか１項記載のユーザリクエスト供給方法。
【請求項１５】
ユーザ発声が入力として、特に多モード形式で受信されることを特徴とする請求項１乃至４のいずれか１項記載のユーザリクエスト供給方法。
【請求項１６】
発声入力が、ユーザ発声、入力、又はユーザリクエストとして受信されることを特徴とする請求項１乃至１５のいずれか１項記載のユーザリクエスト供給方法。
【請求項１７】
前記ユーザリクエストを処理するステップは、前記ユーザリクエストを認識するステップ、特に音声認識ステップを含むことを特徴とする請求項１３乃至１６のいずれか１項記載のユーザリクエスト供給方法。
【請求項１８】
前記リクエスト情報データは、主要なデータソース情報、主要なデータターゲット情報、及び又は、主要なアクション情報を含むように生成されることを特徴とする請求項１３乃至１７のいずれか１項記載のユーザリクエスト供給方法。
【請求項１９】
前記主要なデータソース情報は、リクエストされたデータやサービスの可能な又は潜在的なソースを示す情報を含み、
前記の主要なデータターゲット情報は、リクエストされ、導出されたデータやサービスの可能な又は潜在的なターゲットを示す情報を含み、
前記主要アクション情報は、リクエストされ、導出されたデータや可能なサービスを実行される可能な潜在的なアクションを示す情報を含むように生成されることを特徴とする請求項１８記載のユーザリクエスト供給方法。
【請求項２０】
前記デバイス情報データは、各デバイスの可能な機能を注釈し、表現するデバイス機能データ、及び、必要かつ適当であるデバイスの初期状態、現在状態、最終状態又は状況を注釈し、表現するデバイス状況データを含むように生成されることを特徴とする請求項１３乃至１９のいずれか１項記載のユーザリクエスト供給方法。
【請求項２１】
前記デバイス情報データ、前記アクション情報データ等を導出し、格納し、使用するステップ中で、対話システム、セクション、アルゴリズム等を使用することを特徴とする請求項１３乃至２０のいずれか１項記載のユーザリクエスト供給方法。
【請求項２２】
立案モジュール、セクション、アルゴリズム等を使用し、前記対話システム、セクション、アルゴリズム等の一部として機能モデル、状態モデル、推論コンポーネントを含んでいることを特徴とする請求項１乃至２１のいずれか１項記載のユーザリクエスト供給方法。
【請求項２３】
前記立案モジュール、セクション、アルゴリズム等は、単一で個別のデバイス、デバイスクラスの理論モデルについて推論することにより、別個の、又は組み合わせられた単一のデバイスのための理論的な仮想デバイスのモデルについても同様に推論することにより計画を生成することを特徴とする請求項２２記載のユーザリクエスト供給方法。
【請求項２４】
前記デバイス情報データを導出するステップにおいて、前記外部モデルを用いてデバイス探索アルゴリズムが使用されることを特徴とする請求項１３乃至２３のいずれか１項記載のユーザリクエスト供給方法。
【請求項２５】
前記デバイス情報データを導出するステップにおいて、デバイス探索アルゴリズムは前記内部モデル、前記状態モデルを使用することを特徴とする請求項１３乃至２４のいずれか１項記載のユーザリクエスト供給方法。
【請求項２６】
前記デバイス探索アルゴリズム、前記状態探索アルゴリズムが、ネットワーク中の組み合わせた単一のデバイスの機能を推定し、前記仮想デバイスモデルを生成するプロセスに参加することを特徴とする請求項２４又は２５記載のユーザリクエスト供給方法。
【請求項２７】
前記アクション情報データを導出するステップにおいて、アクション探索アルゴリズムは、前記内部モデル、前記推論コンポーネントを使用することを特徴とする請求項１３乃至２６のいずれか１項記載のユーザリクエスト供給方法。
【請求項２８】
前記アクション列の１つを実行するステップにおいて、アクション実行アルゴリズムが使用されることを特徴とする請求項１３乃至２７のいずれか１項記載のユーザリクエスト供給方法。
【請求項２９】
請求項１乃至２８のいずれか１項記載のユーザリクエスト供給方法、そのステップを実行し、実現するデバイス、マンマシンインタフェースユニット及びシステムのネットワーク。
【請求項３０】
コンピュータ、ディジタル処理手段等上で実行され、請求項１乃至２８のいずれか１項記載のユーザリクエスト供給方法、そのステップを実行し、実現するコンピュータプログラム手段を含むコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークデバイスについてのユーザリクエストを供給するユーザリクエスト供給方法に関し、より詳細には、複雑なユーザの要求又はタスクが実現できるマンマシンインタフェースユニットを操作する方法に関する。
【背景技術】
【０００２】
最近、非常に様々のデバイスや装置に、マンマシンインタフェース技術、マンマシン対話システム等が使用され、デバイスを容易かつ確実に使用できるようになされてきている。特に、接続された様々なデバイスを使用し、様々なサービスをユーザに提供するネットワーク又はホームネットワーク設備の分野において、これらの技術を利用してユーザの利便性を図ることが行われている。
【０００３】
先行技術におけるユーザリクエストの供給、マンマシンインタフェースユニット操作方法及びそれらのシステム、特に、ホームネットワークの分野においては、デバイスのアクションをユーザが直接発声し、それを受信してコマンドとして割り当てるために、直接的な、かつある程度正確なコマンドが、マンマシンインタフェースユニットの対話マネージャから期待されている。したがって、先行技術の方法及びシステムにおいては、ユーザは、ネットワークデバイスの種類とかその機能を知る必要があり、具体的なデバイス及びアクションを考慮する必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、複雑なユーザの要求やタスクにより柔軟で信頼できる方法で対応できるネットワークデバイスにおけるユーザリクエストを供給するユーザリクエスト供給方法を提供することである。
【課題を解決するための手段】
【０００５】
この目的は、ネットワークデバイスに関し、特許請求の範囲に記載されるような特徴を備えたユーザリクエスト供給方法によって達成される。ネットワークデバイスに関する本発明のユーザリクエスト供給方法の好ましい実施形態に関しても、同じく複数ある特許請求の範囲のいずれかに記載されている。更に、この目的は、ネットワークデバイス、マンマシンインタフェースユニット又は本発明のユーザリクエスト供給方法を制御するためのシステム、更には、本発明のユーザリクエスト供給方法の手順が記述されたコンピュータプログラム製品によっても達成される。
【０００６】
ネットワークデバイスに関する本発明のユーザリクエスト供給方法、特に、ネットワークにおける各デバイス、デバイスクラス、ネットワークデバイスを制御する方法においては、理論的な方法で各々のデバイス、各デバイスクラス等の機能をモデル化するために、少なくとも１つの理論的な個別の機能モデルが生成され、提供され、使用される。
【０００７】
更に、与えられたユーザリクエストは、その理論的タスクモデルを生成し、提供し、使用することにより、それぞれの場合について理論的な方法でモデル化され、表現される。更に、各個別の単一のデバイスの複数の理論的な個別の機能モデルが、特に、外部モデルを用いて組み合わされ、形式的に結合され、外部モデルの整理された１組を介してモデル化される。これによって、理論的な方法で、それぞれの別個の、又は組み合わせられた単一のデバイスの組合せモデルの機能をモデル化する理論的な仮想デバイスのモデルが作成される。
【０００８】
したがって、本発明の第１の基本概念は、理論的な方法でネットワーク中の個別デバイス、デバイスクラスをモデル化し表現するだけでなく、それぞれの場合に、理論的タスクモデル内での受信され、与えられたユーザリクエストをモデル化し表現することである。このような理論的モデル化や表現によって、ネットワークに含まれるデバイスとデバイスクラスを基準に、特定の柔軟で信頼できる方法でユーザリクエストを供給する計画又は方法を見つけ出すことが可能になる。
【０００９】
本発明の第２の基本概念は、その機能をモデル化するための理論的な個別の機能モデルによってネットワークに含まれる与えられた個別の単一のデバイス、デバイスクラスをモデル化及び表現するだけでなく、単一のデバイスの組合せの機能を表現し記述するために、組合せ、又はシステム全体、又は単一のデバイスのネットワーク、又はその部分の理論的な記述を作成することである。この対策によって、与えられたユーザリクエストを供給する、特別かつ信頼できる方法を見出すことが可能となり、独立しているデバイスを見つけ出すことが可能になる。
【００１０】
本発明の基本的な部分は互いに組み合わせることができるが、最終的には、与えられたユーザリクエストが、各場合に理論的な方法でモデル化されて表現され、かつネットワークにおいて存在する別個の単一のデバイスの組合せの新しい機能が、導出されて理論的な方法で表現できるユーザリクエスト供給方法となる。
【００１１】
本発明のユーザリクエスト供給方法の好ましい実施形態によれば、単一の個別デバイス又はその部分の少なくとも１つの組合せの少なくとも１つの機能を推定する少なくとも１ステップ又は１つの副プロセスが行われるが、これは、特に、前記単一の個別デバイスのうちの１つの機能ではない。したがって、それらの機能を備えた複数の単一の個別デバイスからは明らかでない新しい機能を得ることができ、単一の個別デバイスの前記の組合せとして一種の仮想デバイスを作る。
【００１２】
機能モデルは、全体的な形又は、デバイス情報データ、アクション情報データ等を導出し、格納し、使用するステップで、ネットワーク中の各デバイスに特に使用されるのが好ましい。
【００１３】
更に、少なくとも１つの外部モデルにより構築されて含むように、本発明のユーザリクエスト供給方法では、各々の前記機能モデルを選択するのが好ましい。この少なくとも１つの外部モデルは、特に、それぞれのデバイス又はデバイスクラスに送信されるデータをモデル化し、記述するか、或いは、入力データをモデル化し、記述する。また更に、各々の前記機能モデルは、少なくとも１つの外部モデルによって構築され、これを含むように選択することができる。この少なくとも１つの外部モデルは、特に、それぞれのデバイス又はデバイスクラスから送信されるデータをモデル化し、記述するか、或いは、出力データをモデル化し、記述する。これは、特に使用される特別の機能に依存しており、特に与えられたユーザリクエスト供給するのに、適切なデバイスを見つけ出すために行われ得る。
【００１４】
更に、各々の前記機能モデルは、有限状態オートマトン（finite state automaton）等として内部モデルを含むように選択され得るが、取り得る状態、状態間の取り得る遷移、更には、それぞれのデバイス等の前記状態遷移を初期化するための取り得るアクションについての記述であり、特に、それぞれのデバイス、デバイスクラスを制御する計画を生成することの記述である。
【００１５】
また、少なくとも１つのデバイス、デバイスクラスについて、前記内部モデルが、事前条件、及び事後条件を持った状態を有し、これらは少なくとも１つの追加のデバイス、１つの追加のデバイスクラスの必要性について特に記述するものであることが好ましい。
【００１６】
前記入力データ、前記出力データによって、内部と外部モデル間で、接続、割当等がなされるのも更なる利点である。
【００１７】
前記機能モデルは、関連するデバイス間の取り得る接続を表す、接続モデルを含むように選択される。
【００１８】
各デバイス、デバイスクラスについて、本発明のユーザリクエスト供給方法の他の実施形態によれば、複数の外部モデルが生成され、提供され、使用されることが好ましい。
【００１９】
更に、好ましくは、基本の外部モデルは、入力データ、出力データ、少なくとも１つの基本プロセス、又は前記出力データに前記入力データを接続するサービスについての情報を含む前記外部モデルとして使用される。
【００２０】
受信ユーザリクエストから導出された、与えられた各タスクについて、特に、前記与えられたタスクの１組のモデルとして、特に、与えられたタスクの入力データを、与えられたタスクの出力データに接続して、基本のタスクの少なくとも１つの列を生成し、提供し、使用することは更なる利点である。
【００２１】
更に、提供され、生成され、そして与えられたタスクに属する基本のタスクの複数の列より、ある部分が、与えられた複雑な要求、信頼度の高い要求を満たす前記の与えられたタスクモデルとして選択される。
【００２２】
最後に記述された対策により、複雑なタスク又は複雑なユーザリクエストが、様々な基本のタスクの列に分かれ得るが、これに従って、ユーザリクエストの入力データ又は与えられたタスク及びその出力データが接続される。したがって、ユーザリクエストに属する前記入力データ及び出力データは、基本のタスクの異なる列によって接続され得る。例えば、ユーザリクエスト「マドンナの最近のシングルヒットを聞く」は、テレビ受像機から得られた動画ストリーム、インターネットから得られた動画ストリーム、ＤＶＤ又はＣＤ−ＲＯＭから得られた動画ストリーム、又はＣＤ、オーディオテープから、放送受信機から、ミニディスクから得られたオーディオストリームから前記シングルヒットを受信することにより満たされ得る。したがって、基本のタスクの異なる列は、与えられたユーザリクエストを満たしかつこれにサービスするように、組み合わせることができ、どの配列が最適であるかは、信頼性、複雑度、及びコストの問題となる。
【００２３】
デバイス等のネットワークに関するユーザリクエスト供給方法、特に、前記ネットワークデバイスの制御方法では、ユーザリクエストが、受信され、処理されることによって、前記ユーザリクエストを表現するリクエスト情報データを生成し、格納し、そして使用することが更に好ましい。更に、デバイス情報データは生成され、格納されており、少なくともユニット、デバイスについての情報を含んでおり、前記ユーザリクエストに関して必要で、適当なものであり、前記マンマシンインタフェースユニットに利用可能であり、前記ユニットや、デバイスの取り得る状態についての情報を含んでいる。更に、前記デバイス情報データ等に関して、前記ユーザリクエストに関して適切なアクション列について、前記リクエスト情報データに従う情報を含んでいるアクション情報データは、生成され、格納される。したがって、デバイス情報データが格納され、これは、利用可能な全てのユニット、デバイス、例えばマンマシンインタフェースの機能及び現在の状態についての情報を含んでいる。前記リクエスト情報データ及び前記デバイス情報データが与えられると、前記ユーザリクエストに関して適切なアクション列についてのアクション情報データは、生成され、格納される。
【００２４】
最後に、前記アクション情報データに従うアクションの前記列の少なくとも１つが、適切に前記ユーザリクエストに応答するように実行される。
【００２５】
したがって、先ずユーザリクエストを受信し分析して、これから、ユーザリクエストを記述し特徴づけるリクエスト情報データを導出することは、本発明のユーザリクエスト供給方法の基本概念である。受信ユーザリクエスト及び導出したリクエスト情報データから、どのデバイスがリクエストを供給するのに適切かつ必要かが決定される。そのため、デバイス情報データが導出される。すなわち、受信したユーザリクエスト及び導出したリクエスト情報データが与えられると、格納されているデバイス情報データは、どのデバイスがリクエストを供給するために適切かつ必要かが決定するために使用されることを意味する。
【００２６】
その後、ユーザリクエストに関して適切であるアクション列としての計画が、リクエストを供給するために適切かつ必要なデバイスのデバイス情報データを使用して構築される。したがって、アクション情報データが生成され、格納され、これに基づいて、少なくとも１つの前記アクション列が、適切な形で前記ユーザリクエストに応答するために、実施又は実行される、
【００２７】
本発明は、音声又は発声認識ユニット、解釈ユニット、対話マネージャ、及び本発明のユーザリクエスト供給方法を実現する部分からなる対話システムに搭載することができる。
【００２８】
本発明によれば、それが単純なデバイス命令でない場合とか、幾つかのデバイスがリクエストを供給するのが必要な場合、ユーザリクエストは複雑であると言える。
【００２９】
先行技術の方法とは対照的に、ネットワークデバイスに関する本発明のユーザリクエスト供給方法は、特にユーザが発声した命令の直接マッピングが可能でない場合に複雑なユーザの希望又は複雑な所望のタスクを供給することができる。例えば、命令「ＣＤ再生開始」は、ＣＤプレイヤの入力端子に開始信号を供給することにより、直接マッピングし実行することができる。対照的に、タスク「私はマドンナの最近のシングルヒットを聞きたい」は、直接な方法ではマッピングし実行することができない。というのは、デバイスも、デバイス上で実行されないアクションも、データソースも、タスクの言語表現内では与えることができないからである。これらの項目は、実行ステップの前に導出しなければならない。また、マンマシンインタフェースユニットを操作する本発明のユーザリクエスト供給方法は、特に、そのような複雑なユーザの希望又はタスクに対処することができる。
【００３０】
したがって、本発明の好ましい実施形態によれば、特に前記ネットワークの必要なデバイスを含んだ、ユーザの希望を表す複雑なユーザリクエスト、所望のタスク、サービス、デバイス等、又はその列若しくは組が、前記ユーザリクエストとして受信する。
【００３１】
他の概念としては、特に多モードの形で、入力としてユーザ発声を一般的に受信することで、例えば、聴覚のコンポーネント、身振り、顔の表情等を含む。発声としての多モード形式のユーザ入力は、幾つかの側面を備えたコンポーネントを含む。
【００３２】
ネットワークデバイスに関する本発明のユーザリクエスト供給方法の好ましい実施形態によれば、ユーザ発声又は入力、例えば音声入力は、前記ユーザリクエストとして受信される。既に上述のように、音声は、ユーザが希望のタスクを発する最も容易な方法である。
【００３３】
前記ユーザリクエストを処理するステップは、前記ユーザリクエストを認識し、理解するステップを含み、そして発話されたユーザリクエストの場合には、特にユーザ確認のステップと組み合わせて、音声認識ステップを含む。
【００３４】
前記ユーザリクエストについての理論的な表現を生成することは、本発明の利点である。
【００３５】
ネットワークデバイスに関する本発明のユーザリクエスト供給方法の別の好ましい実施形態に従って、前記リクエスト情報データは、主要なデータソース情報、主要なデータターゲット情報、主要なアクション情報を含むように生成される。
【００３６】
前記の主要なデータソース情報は、受信され又は生成される主要なデータのための可能なデータソースについての情報を含んでいる。前述のタスク「マドンナの最近のシングルヒットを聞く」の場合の主要なデータソース情報は、主要なデータ、すなわち、前記マドンナの最近のシングルヒットのそれぞれの音声データを提供するための、ＣＤプレイヤ、テープレコーダ、放送システム等に関する情報を含み得る。前記主要データターゲット情報は、前述の場合、各歌の音響出力用の前記データが送られるネットワークの増幅ユニット及びスピーカユニットに関する情報を含むことができる。主要アクション情報は、タスクコンポーネント「を聞く」から導出され、それぞれのデバイスの再生モード又はプレイモードに関する情報を含む。
【００３７】
前述の場合及び同様の場合は、主要なデータソースは、データ例えば音、動画ストリーム等を提供することができるデバイスである。したがって、データターゲットとは、データソースからの情報又はサービスを受信するデバイスであり、例えば、スピーカユニット、記録デバイス、表示デバイス等である。最後に、アクション情報は、データソースとデータ目標の間のデータ送信及び遷移を実現するために、データソース及びデータターゲットで実行されるアクションについて記述する。
【００３８】
以上述べたように、本発明による方法の好ましい実施形態によれば、前記主要なデータソース情報は、リクエストされたデータ、サービスの可能な又は潜在的なソースを少なくとも示す情報を含むように生成される。更に、前記の主要なデータターゲット情報は、リクエストされ、導出されたデータ、サービスのために、少なくとも可能な又は潜在的な目標を示す情報を含むように生成される。更に、前記主要アクション情報は、リクエストされ、導出されたデータ、可能なサービスについて、実行される可能な潜在的なアクションを少なくとも示す情報を含むように生成される。
【００３９】
特に、本発明のユーザリクエスト供給方法の有利な実施形態では、前記デバイス情報データは、デバイス機能データ（特に各デバイスの可能な機能を記述し、表現する）、デバイス状況データ（少なくとも前記必要な、前記適切なデバイスの初期、現在、最終状況又は状態を記述し、表現する）を含むように生成される。
【００４０】
特に、このようなデバイス情報データ、前記アクション情報データ等を導出し、格納し、使用するステップ中で、対話システム、セクション、アルゴリズム等を使用するのが好ましい。
【００４１】
更に好ましくは、立案モジュール、セクション、アルゴリズム等を使用し、特に、前記対話システム、セクション、アルゴリズム等の一部として、特に、機能モデル、状態モデル、推論コンポーネントを含むのが好ましい。立案モジュール、セクション、アルゴリズム等は、別個の、又は組み合わせられた単一のデバイスのための理論的な仮想デバイスのモデルについてのみならず、単一個別のデバイス、デバイスクラスの理論モデルについても同様に推論することにより、計画、方針を生み出すことができる。
【００４２】
本発明のユーザリクエスト供給方法の他の好ましい実施形態によれば、前記デバイス情報データを導出するステップで、特に前記外部モデルを用いてデバイス探索アルゴリズムが使用される。
【００４３】
本発明の別の実施形態に従って、前記デバイス情報データを導出するステップで、状態探索アルゴリズムを使用することは、特に前記内部モデル、前記状態モデルを使用する場合に有利である。
【００４４】
好ましくは、前記デバイス探索アルゴリズム、前記状態探索アルゴリズムが、ネットワーク中の組み合わせた単一のデバイスの機能を推定し、前記仮想デバイスモデルを生成するプロセスに参加することが可能であり、そのために使用される。
【００４５】
更に、前記アクション情報データを導出するステップで、アクション探索アルゴリズムは、特に前記内部モデル、前記推論コンポーネントを用いて使用することができる。
【００４６】
見出された計画の実行のため、ユーザリクエストに応答するため、アルゴリズムを実行するアクションは、特に、前記アクション列の１つを実行するステップで使用することができる。
【００４７】
本発明の他の側面は、それぞれの場合に、ネットワークデバイス、又はそれのステップに関する本発明のユーザリクエスト供給方法を実行、実現可能なようなネットワークデバイス、マンマシンインタフェースユニット、システム、デバイス、デバイス等を提供し、操作することである。
【００４８】
また、本発明の更なる側面は、コンピュータ、ディジタル処理手段等上で実行される場合に、ネットワークデバイス、又はそれのステップに関する本発明のユーザリクエスト供給方法を実行、実現するようになされるコンピュータプログラム手段を含むコンピュータプログラム製品を提供することである。
【００４９】
本発明の更なる側面は、以下の点を考慮に入れてより明らかにされるであろう。本発明で取り組む課題は、マンマシンインタフェースユニット、特に対話システムの操作のための方法、又はシステムが可能になるようにし、複雑なユーザの希望、リクエスト、タスクを供給することである。
【００５０】
デバイスを直接制御する代わりに、ユーザは、幾つかのデバイスの使用が含まれ得る複雑なタスクの供給が受けられるように、システムに依頼することが認められている。
【００５１】
理論的な方法で各単一の個別デバイスの機能について記述し、モデル化することは、本発明の１つの側面である。本発明の更なる側面によれば、ユーザリクエストは、複雑なタスクとしてモデル化され、理論的な方法で記述される。この理論的な記述を使用すれば、この方法と、この方法を使用するシステムは、幾つかのデバイスの組合せにより存在する、各単一の個別デバイス、システム全体の組合せの機能を推定することが可能になる。この推定された機能は、１つの各単一の個別デバイスの機能ではない。
【００５２】
本発明の更なる側面によれば、単一のデバイスによって提供される機能に加えて、システム全体は、更に、幾つかの個別のデバイスの組合せにより機能を提供する。複雑なユーザの希望又はユーザのリクエストを実現するために、これらの機能も、特に、個別及び単一のデバイスについて、形式的に個別及び単一のモデルを合体することによって、モデル化される。したがって、仮想デバイスモデルは、各単一の個別デバイスの組合せに関して、又はシステム全体に関して作り出される。
【００５３】
各デバイスの機能は、有限状態オートマトンによって記述され得る。複雑なユーザリクエストが与えられると、次のステップがリクエストを供給するために自動的に行われることになっている。すなわち。適切で必要なデバイスを探索すること、各関連デバイスの現在及び要求された状態を探索すること、各デバイスを現在の状態から要求された状態にするための計画又は一連のアクション列を探索すること、計画を実行すること等が含まれる。
【００５４】
デバイス又はネットワークデバイスを制御するために使用されるマンマシンインタフェースユニットでの従来の対話システムは、通常、入力認識ユニット、入力理解ユニット、対話マネージャ及び制御されるデバイスからなる。単純なユーザリクエストは、適切な制御コマンドに、ユーザ入力をユニーク（固有）に直接マッピングすることにより行うことができる。
【００５５】
例えば、音声入力「ＣＤ再生」が与えられると、従来のシステムは、ユニークにＣＤプレイヤの再生コマンドに、このユーザリクエストをマッピングすることができる。
【００５６】
従来の対話システムの最も既知のユーザインタフェースの主な欠陥は、ユーザが、デバイス、サービス及びアプリケーション等を考える必要があることである。
【００５７】
例として、タスク「映画ＸＹＺを録画する」を考えてみよう。この場合、ユーザは、最初に適切なチャンネル、開始時間及び長さを見つけ出すためにＥＰＧ（すなわち電子番組ガイド）を使用することができる。その後、ユーザ自身が、ＶＣＲをプログラムする必要がある。
【００５８】
本発明によれば、ユーザが、人間の助手か相手方とのコミュニケーションをするかのようにして、ユーザは、１つの（マルチ様式）リクエストを、タスクの点からシステムに提出することができる。これは、ユーザが、「映画ＸＹＺを録画する」ように、システムに依頼することを意味する。そして、本発明そのものによるシステムは、適切なチャンネル、開始時間及び長さを見つける方法、例えばＥＰＧを用いて、そして次にＶＣＲを自動的にプログラムする方法に関する情報を持っているか、又は導出する。
【００５９】
デバイスとアプリケーションのネットワークでは、単一の個別のデバイスによって提供される機能がある。更に、単一の個別のデバイスの組合せによって、及び全てのデバイスの組合せによるシステム全体によって提供される機能もある。例えば、新しい機能「あるビデオレコーダから別のビデオレコーダに複写する」又は「ミニディスクに動画ストリームの音声信号を複写する」ことが構築され得る。これらの機能の少なくとも１つを含むそれぞれの複雑なユーザの希望では、ユーザ自身は、通常タスクを完了するために、所与の個別の幾つかのデバイスを組み合わせる方法について知っている必要がある。ユーザは、１つのデバイスから別のデバイスに動画ストリームを複写するために、第１と第２ビデオレコーダを制御する方法を先ず知っている必要がある。代わりに、ユーザは、全体のタスクを完了してくれるようにシステムに依頼し、ユーザは、「この動画を複写する」ように、システムに依頼する。
【００６０】
したがって、本発明によって取り組まれる１つの課題は、前記単一の個別のデバイス、及びアプリケーションの理論モデルが与えられる場合、システムと方法によって、単一の個別のデバイス、又は総合システムの組合せの機能を推定することができるように、理論的な方法で、複雑なタスク及び機能をモデル化することである。デバイス全体によって提供される機能は、特定のデバイスと厳密に関係はないが、デバイスの機能と関係があるので、方法とシステムはより柔軟になり得る。
【００６１】
本発明によって取り組まれる更なる課題は、幾つかのデバイスを含んでいる複雑なタスクを完了することである。この目的のために、単一の個別デバイスの個別理論モデルを使用するだけでなく、これに加えて、形式的にデバイスの個別モデルを合体するように提案されている。これは、幾つかのデバイスの組合せによる機能をモデル化する仮想デバイスモデルを作り出す。
【００６２】
本発明によって取り組まれる更なる課題は、ユーザが、複雑なタスクを求めて、単一のデバイスを制御する代わりに複雑な希望を発声することができるようして、柔軟で直感的なデバイスの制御及び操作、アプリケーション並びにサービスが可能になるプロセスである。複雑なリクエストが与えられると、ネットワークデバイスに関する本発明のユーザリクエスト供給方法は、自動的にリクエスト又は希望の意味を認識し、必要なデバイスに関する必要な情報を導出し、リクエスト又は希望に応えるために適切なアクションを取る。
【発明を実施するための最良の形態】
【００６３】
本発明のユーザリクエスト供給方法の好ましい実施形態には、次のステップが含まれる。
【００６４】
１．複雑なユーザ希望にサービスを提供する適切で必要なデバイスを探索すること。
【００６５】
２．各々の関連デバイスの現在及び要求された状態を探索すること。
【００６６】
３．各デバイスを現在の状態から要求された状態にするために、計画又は一連のアクション列を探索すること。
【００６７】
４．計画を実行するか、又は一連のアクション列を実行すること。
【００６８】
このアルゴリズムは、本発明を適用した適切なシステムによって自動的に行い得る。異なるデバイスを使用するための、更なるユーザ入力の必要はない。
【００６９】
続いて、ホームネットワークを具体例として説明する。このホームネットワーク、例えば、テレビ、ビデオカセットレコーダ（ＶＣＲ）、セットトップボックス（ＳＴＢ）、ＥＰＧ（電子番組ガイド）及びミニディスクレコーダ（ＭＤＲｅｃ、商標）からなっている。マンマシンインタフェースユニット（ＭＭＩ）は対話システムを含んでいる。先行技術における対話システムでは、与えられたデバイスは、対話マネージャによって直接かつ別々に制御される。
【００７０】
この目的のために、従来は、単一の個別デバイスの機能の個別モデルで十分である。ユーザの希望は、デバイスの点から、モデル化することができるが、これは、例えば、ユーザの音声入力「録画」等を、ビデオレコーダの制御コマンド「録画」に直接マッピングすることにより行うことができる。
【００７１】
対照的に、本発明の概念は、システムが、デバイスの与えられた理論モデルから、システム全体の機能を推定することができるように、理論的な方法で、デバイスの複雑なタスク及び機能の双方をモデル化することである。これは、特にデバイス、又はアプリケーションの組合せによって生じる機能を含んでいる。したがって、システム全体は、幾つかのデバイス、アプリケーションばかりでなく、新しい機能を提供する仮想デバイスを含むと見ることができる。更に、機能は、厳密にはデバイスと関係がない。
【００７２】
本発明の更なる概念は、理論的な方法で、個別の単一のデバイスの組合せにより生じる機能をモデル化することである。単一の個別デバイスの理論モデルが与えられると、組み合わせたデバイスの理論モデルを形式的に合体することによりなされ得る。これを行うことによって、仮想デバイスモデルが得られ、これはモデルが合体されたデバイスのそれぞれの組合せによって提供される機能をモデル化する。
【００７３】
本発明による更なる概念は、対話システムへ新しいモジュールを導入することである。この新しいモジュールは、立案モジュールと呼ばれる。立案モジュールは、各デバイスの機能の取り得る機能の理論モデル（いわゆる機能モデル）（及び特にネットワーク中の各デバイスについての）からなり得る。更に、立案モジュールは、機能モデルに基づいて、各デバイスの、及び推論コンポーネントの現在の状態の管理からなる。この新しく導入されたモデルは、ユーザに、明示的にデバイスを使用し、かつそれらを組み合わせることを強いる代わりに、システム又はマンマシンインタフェースユニットを操作する方法によって、複雑なユーザの希望に対してサービスができる。
【００７４】
デバイスの機能モデルは、２つの部分からなる。第１の部分は、デバイスに関しての入出力データを記述する外部モデルである。第２の部分は、状態遷移へ導き得るデバイス及びそれらのアクションの可能な状態について記述する内部モデル（例えば、有限状態機械（finite state machine）、有限状態オートマトン等）である。更に、状態は、入出力データに記述される。
【００７５】
例えば、「映画ＸＹＺを録画する」のような複雑なユーザのリクエストを供給するために、立案モジュールは、次のステップを行う必要がある。
【００７６】
どのデバイスがリクエストを供給するのに必要か見つけ出すこと（前述の場合、ＥＰＧとＶＣＲ）。
【００７７】
デバイスがどのように制御され得るか見つけ出すこと。
【００７８】
本発明の立案モジュールの推論コンポーネントは次のものからなる。
１．適切で必要なデバイス（デバイス探索アルゴリズム）の探索用のアルゴリズム。これは外部モデルを使用して行われる。
【００７９】
２．リクエスト（状態探索アルゴリズム）にサービスするために特定される必要がある関連デバイスの各々の状態の探索用のアルゴリズム。これは、内部モデル（すなわち有限状態オートマトン）を用いて行われる。
【００８０】
３．各々の関連デバイスを現在の状態から要求された状態にする計画、一連のアクション列を探索する立案アルゴリズム。これは、各関連デバイスの内部モデルを使用して行われる。
【００８１】
４．計画を実行するか又は一連のアクション列を実行するアルゴリズム（アルゴリズムの実行）。
【００８２】
本発明のユーザリクエスト供給方法は、次の側面の使用を少なくとも一部分含んでいる。
【００８３】
−ネットワーク中の各単一のデバイスの機能の理論モデル
−複雑なタスクについて記述する理論モデル
−単一の個別デバイスの個別モデルに合体する方法についての形式(formalism)
−デバイス／アプリケーションの組合せによって提供される、個別で単一のデバイス、又はシステム全体の組合せの機能を推定するための探索アルゴリズム
−仮想モデルと同様に個々のモデルの双方について推論することにより、計画、方法を生成するための立案アルゴリズム
−どのデバイスが複雑なユーザリクエストを供給するのに必要か見つけるためのデバイス探索アルゴリズム
−状態探索アルゴリズム及びデバイスの制御方法を見つけるための立案アルゴリズム
−生成された計画が要求に従ってデバイスを制御するための実行アルゴリズム
【００８４】
なお、複雑なタスクの理論モデルの使用によるシステム全体の機能及びデバイスの機能を推定する方法は、最終的な機会の形式と同様に外部及び内部モデルの形式に必ずしも依存しない。更に、本発明は、家電製品に制限されないばかりか、電話、電子メールサービス等のような他のデバイス等に適用され得る。使用されるマンマシンインタフェースユニットは、必ずしも対話システムである必要はない。更に本発明のユーザリクエスト供給方法によって、システムは、ネットワークへ新しく統合されたデバイスによるシステム全体の機能を推定することができる。本発明のユーザリクエスト供給方法が、旅行情報データベース等のサービスに適用できることは更に強調される。
【００８５】
マンマシンインタフェースユニット又は先行技術の対話システムにおけるような対話マネージャによって、単一の個別デバイスを直接かつ別々に制御する代わりに、本発明によれば、理論的な方法で、個別デバイスの機能と同様に複雑なタスクもモデル化することができる。更に、本発明によれば、単一の個別デバイスの組合せによって提供される機能をモデル化することができる。
【００８６】
更に、本発明によれば、極めて理論的なレベルで対話マネージャから与えられたリクエストを公式化することができる。リクエストの実行は、立案モジュールによって最後に行われる。先行技術の対話システムと比較して、本発明は次のような長所を有する。
【００８７】
−ユーザは、複雑なタスクの解決を求めることができる。
【００８８】
−ユーザは、デバイス及び制御の点から、複雑なタスクを完了するために各デバイスを別々に考える必要がない。
【００８９】
−システムは、どの機能がシステム全体によって提供されるか推定する。特に、これは、デバイスの組合せによってのみ提供される機能を含んでいる。そのために、仮想デバイスが提供される。
【００９０】
−特定の複雑なタスクの解決は、デバイスのユニークな組合せと関係がない。その代わり、機能モデルと同様にタスクモデルも理論的であるので、システムはそれらの機能と利用可能性に応じてデバイスを組み合わせる。
【００９１】
−システムがシステム全体の機能を推定することができ、本発明は、プラグアンドプレイの機能をサポートする。
【００９２】
−個別モデルの合体に関する公式化状態によって合体されることと同様に個々にも、個別モデルを使用することができる。これによって、システムが、ユーザ入力の点から、より柔軟になる。ユーザ入力に応じて、システムは、タスクを完了するために、１つ又は幾つかのデバイスを使用してもよい。
【００９３】
−システムそのものが、与えられたユーザリクエストを実行するのに必要なデバイスを探索する。すなわち、ユーザは、デバイスの点から考える必要はないが、タスク及び希望の点から考えることができる。
【００９４】
−対話マネージャは、実際のデバイスから独立しているので、これらの変化に対して強い。
【００９５】
−ユーザリクエストを供給するデバイスの配置には、幾つかの可能性がある。デバイス探索アルゴリズムによって、システムは、それらを検知することができる。すなわち、ユーザリクエストは、デバイスの特定の配置に固定されない。
【００９６】
−与えられたデバイスの全面的な機能を、対話マネージャが認識している必要はないが、それは機能モデル又は与えられたデバイスから推定される。
【００９７】
−システムは、デバイスの追加及び移動に対して柔軟かつ強い。
【００９８】
基本原理及び概念も、次の特徴から得られる。
【００９９】
タスクモデル
タスクモデルは、立案モジュールの一部であり、理論的な方法でタスクをモデル化するが、これは、やや複雑でもあり得る。タスクモデルは、独立したデバイスである。すなわち、各タスクモデルは、システムに対して、タスクを完了するための特定のデバイスの使用強制はしないが、特定の機能を提供するデバイスを使用する。
【０１００】
本発明のユーザリクエスト供給方法のアルゴリズムにおいて、第１のステップでは、複雑なタスクが、２組の入出力データにマッピングされる。
【０１０１】
複雑なタスクの例はとしては、例えば「映画ＸＹＺを見たい」又は「グリーン氏へ電子メールでスキャンした書類を送る。」である。
【０１０２】
「映画ＸＹＺを見たい」というタスクモデルは、映画ＸＹＺの見える画像の情報を含む。立案コンポーネントは、タスクを完了するには、様々な可能性があると推定する。映画はテレビで見ることができ、すなわち、チューナとディスプレイが必要とされる。又は、映画は、ＶＣＲに録画することができ、すなわち、テープ、テープ駆動装置及びディスプレイが必要とされる。又は、映画はハードディスク等に記録することができる。
【０１０３】
「グリーン氏へ電子メールでこのスキャンした書類を送る」というタスクモデルは、電子メールサービスにスキャンした書類（すなわちファイル）を渡す必要があるという情報、及び受取人はグリーン氏であるという情報を含む。立案コンポーネントは、利用可能な電子メールサービスによっては、フォーマット変換が必要であることを推定する。更に、グリーン氏のアドレスを得るために、送り手のアドレス帳にアクセスする必要がある。アドレス帳へのアクセスのためには、認証が必要なこともある。
【０１０４】
機能モデルの合体
課題：デバイスが与えられると、別のデバイスの機能に依存するデバイスの状態があり得る。例えば、記録することができる何等かの信号を提供する別のデバイスがある場合、ＶＣＲのテープ駆動装置の「録画」状態に到達することのみが意味をなす。これは、チューナでもあり得るが、テープを再生する別のＶＣＲでもあり得る。課題は、特定のデバイスと無関係に、これらの依存性をどのようにモデル化するかである。
【０１０５】
解決策：デバイスの内部モデルが与えられると、別のデバイス（この例においては、これは「録音」状態にある）の機能に依存する特定の状態は、事前条件又は事後条件で記述される。（図６を参照）。この注釈は、別のデバイスの外部モデル（図６の例において、それは別のテープ駆動装置の外部モデルである）のフォーマットに、又は単に２組の入出力データの中にあり、この先で実行される複雑なタスクのように扱われる。なお、事前条件（事後条件）は、選択肢として更に形式化され得る。デバイスの外部モデルは、単一のデバイスを必ずしも指さないばかりか、代替外部モデル、指令された組の外部モデル（すなわちデバイス）を指してもよいので、この外部モデルは、依然として理論的で柔軟性がある。すなわち、事前条件及び事後条件は、外部モデルが注釈された状態の事前条件、事後条件に等しいデバイスの全ての機能モデルを参照し、又は、指令された全ての組の外部モデル（注釈された状態の事前条件、事後条件が、一連の最初の入力データ及び一連の最後の出力データと等しい）を参照する。その意味で、幾つかの機能モデル（すなわち事前条件、事後条件を介して参照された全ての内部モデルを備えた主な内部モデル）は形式的に合体される。
【０１０６】
デバイスの組合せの機能の推定：入出力データを介してモデル化された複雑なタスクが与えられると、必要なデバイスは、外部モデル（これらは指定された入出力データを扱うことができる）によって表される一続きのデバイスを探索することによって、探索される。これは、外部モデルを介して探索することにより行われる。デバイスのそのような組合せは、仮想デバイスと見なされる。外部モデルから構築された仮想モデルは、デバイスの利用可能性に依存してデバイスを組み合わせたモデルである。すなわち、ネットワークに新しく導入されたデバイス（複雑なタスクを完了するために必要で、機能を提供する）がある場合、システムは、外部モデルから、新しく導入されたデバイスがこの複雑なタスクに使用できると推定する。これは、指令された一連の外部モデル（すなわち仮想デバイス）が与えられると、アルゴリズムは仮想モデルによって提供される機能を推定することができる。
【０１０７】
デバイスの追加及び削除：機能モデル（推論コンポーネント及びタスクモデルではない）が、デバイスそのものの一部であるべきであるので、デバイスは、プラグインをすることにより、その機能に関する必要な情報を提供する。デバイスが削除された場合、デバイスの機能モデルも削除される。
【０１０８】
一般的な特徴
本発明は、デバイスの組合せによって提供される機能をモデル化する、１つ又は異なる方法の組合せを含む。次の３つの方法がある。（１）モデルを組み合わせる、特に外部モデルを用いてモデルを組み合わせる方法、（２）モデルを合体する方法、（３）指令された組の外部モデルによってモデル化する方法。
【０１０９】
更に、１つの複雑なユーザ希望を解決するために、これらの方法は組み合わせることができるということは重要である。コンポーネントのうちの１つが、他のデバイスによって提供される機能に更に依存する仮想デバイスが考慮されるか、又はあるデバイスが仮想デバイスの機能に依存する場合はそうである。
【０１１０】
１．モデルの合体：この概念により、１つのデバイスの特定の状態と仮想デバイスの機能の間の依存性をモデル化することができる。
【０１１１】
２．デバイス探索アルゴリズムは、指令された組の外部モデルを返す。外部モデルのこの指令された組は、１組のデバイスを含む仮想デバイスのモデルを確立するが、デバイスの１つのユニークな組には制限されない。すなわち、１つの複雑なタスクに必要とされる同一機能を提供するデバイスがネットワーク中に幾つかある場合、代替の組合せがタスクを完了し得る。その意味で、システムは、デバイスの組合せの機能を推論することができる。それは仮想デバイスとしてモデル化される。図１２では、２台の仮想デバイスが描かれており、それらの各々は、あるデバイスから別のデバイスに動画を複写することができる。第１の仮想デバイスは２つのＶＣＲを有し、一方、第２の仮想デバイスは、ハードディスクとＶＣＲからなる。ネットワークに新しいデバイスが追加された場合、新しい仮想デバイスが存在するようになる。
【０１１２】
本発明のユーザリクエスト供給方法は、以下の１つ以上のステップを含み得る。
１．外部モデルを組み合わせること、
２．モデルの合体、
３．指令された組の外部モデルによるモデル化、
これにより、仮想デバイスの機能を推定することができる。
【０１１３】
本発明の前述した及び更なる特徴及び利点を、図面を参照して、以下に説明する。
【０１１４】
図１は、ホームネットワーク内のマンマシンインタフェースユニット（ＭＭＩ）２０を用いて、ユーザリクエストにサービスする本発明のユーザリクエスト供給方法を実施するアプリケーションの構成を示すブロック図である。マンマシンインタフェースユニット（ＭＭＩ）２０に、配置されたデバイス２５−１〜２５−５は、適切な接続手段２６及び２７によって接続される。具体的には、ビデオカセットレコーダ（ＶＣＲ）２５−１、テレビ受像機（ＴＶ）２５−２、セットトップボックス（ＳＴＢ）２５−３、電子番組ガイド（ＥＰＧ）２５−４及びミニディスクレコーダ（ＭＤＲｅｃ）２５−５が、ホームネットワークシステムに含まれている。ＳＴＢ２５−３とＥＰＧ２５−４間の接続手段２７は、インターネット接続によって構築され得る。接続手段２６は、バスシステム又はｉＬｉｎｋ、ブルートゥースシステムとして構築され得る。
【０１１５】
図９で説明する機能モデル３３−１〜３３−４の構造を、電子番組ガイド（ＥＰＧ）の場合について、図２及び図３を参照して説明する。
【０１１６】
各々の機能モデル３３−１〜３３−４は、外部モデル及び内部モデルを含んでいる。
【０１１７】
図２は、図１のＥＰＧ２５−４の外部モデルの構成を示すブロックである。ＥＰＧのための外部モデルは、注釈されたリクエスト情報構造４１[request(Parameter):dbOut]及びレスポンス情報構造４５からなる。リクエスト情報構造４１は、ＥＰＧ４３の入力データ４２であり、レスポンス情報構造４５は、ＥＰＧ４３の出力データ４４である。
【０１１８】
図１又は図２のＥＰＧデバイスの第１の内部モデルは、図３の中で示される状態「リクエスト受信」(receiveRequest)、「探索」(search)、「結果取得」(getResults)及び「結果報告」(reportResults)に対応する４つの異なる状態５２、５４、５６及び５８によって記述することができる。これらの異なる状態又はモードは、それぞれの遷移５０によって、循環的な配置で接続される。状態「リクエスト受信」(receiveRequest)５２及び「結果報告」(reportResults)５８は、それぞれリクエスト情報構造５１及びレスポンス情報構造５９で注釈される。最初の３つの遷移は、アクション「リクエスト取得」(getRequest)５３、「結果発見」(findResults)５５及び「結果送信」(sendResults)５７で注釈される。これらは、状態を変更するために行われる。
【０１１９】
図４は、図１及び図２で示した電子番組ガイド（ＥＰＧ）の第２の内部モデルの構成を示すブロックである。ＥＰＧのための第２の内部モデルは、「準備完了」(ready)、「処理中」(processing)及び「結果受信」(receiveResults)と称する３つの状態８２、８４、８６を含む。これらの３つの状態は、循環的な方法で配され、遷移８０によって接続される。状態「処理中」は、入出力パラメータ構造８１、８９[[request(Parameter) : dbIn], no]で注釈される。状態「結果受信」は、入出力パラメータ構造８１、８９[no, [request(Parameter) : dbOut]]で注釈される。
【０１２０】
図５は、図１に示すビデオカセットレコーダ(ＶＣＲ)９３の外部モデルの構成を示すブロック図である。データ入力処理９２によって、入力データ構造９１[VideoSignal : medium, Parameter]がＶＣＲ９３へ入力される。データ出力処理９４によって、データ構造９５[noVideoSignalOut : medium]を有する出力データが、ＶＣＲ９３から出力される。
【０１２１】
図６は、ビデオレコーダ（ＶＣＲ）９３について、可能性のある内部モデルの構成を示すブロック図である。この図６の内部モデルでは、「停止」、「録画」、「録画一時停止」、「再生一時停止」、「再生」、「巻取」と称する異なる６つの状態又はモード１０２、１０４、１０６、１０８、１１０及び１１２がある。全ての状態が他の状態に接続されているとは限らず、これらは、遷移１００による更に複雑な様式にて並べられる。例えば、録画モード１０４及び再生モード１１０は、互いに直接接続されない。その代わりに、録画モード１０４又は再生モード１１０から開始する場合、再生モード１１０又は録画モード１０４に入る前に、先ず停止モード１０２にそれぞれ入らなければならない。
【０１２２】
概念モード及び状態は同じくここで使用される。
【０１２３】
停止モード１０２は、録画モード１０４、再生モード１１０及び巻取モード１１２に直接双方向に接続されており、「録画一時停止」(recordingPause)モード１０６及び「再生一時停止」(playbackPause)モード１０８から一方向に入ることができる。更に、停止モード１０２は、入出力パラメータ構造１０１[noVideoSignalIn : tapedrive, noVideoSignalOut : tapedrive]を注釈している。
【０１２４】
録画モード１０４は、停止モード１０２及び録画一時停止モード１０６に双方向に接続され、入出力パラメータ構造１０３[VideoSignalIn : medium, noVideoSignalOut : medium]を注釈しており、更に事前条件／事後条件構造１１３[request(Parameter) : dbIn], [request(Parameter) : dbOut]を有している。
【０１２５】
録画一時停止モード１０６は、録画モード１０４に双方向に接続され、停止モード１０２に向かって出ることができる。録画一時停止モード１０６は、入出力パラメータ構造１０５（[VideoSignalInterruptIn : vcr, VideosignalInterruptOut : vcr]）を有する。
【０１２６】
再生一時停止モード１０８は、再生モード１１０に双方向に接続され、停止モード１０２に向かって出ることができる。再生一時停止モード１０８は、入出力パラメータ構造１０７（[VideoSignalInterruptIn : display, VideoSignalInterruptOut : display]）を有する。
【０１２７】
再生モード１１０は、停止モード１０２及び再生一時停止モード１０８に双方向に接続され、入出力パラメータ構造１０９（[noVideoSignalIn : medium, VideoSignalOut : medium]）を有する。
【０１２８】
巻取モード１１２は、停止モード１０２に双方向に接続され、自己を参照する遷移１００ａを有する。更に、巻取モード１１２は、入出力パラメータ構造１１１[VideoSignalInerruptIn : P, VideoSignalInterruptOut : P]を有する。
【０１２９】
図６のＶＣＲの内部モデルと、図４のＥＰＧの第２の内部モデルとを組み合わせることによって、仮想デバイスは、前記ＥＰＧを備えた前記ＶＣＲの組合せとして構築することができる。この内部モデルは、図４及び図６で示される内部モデルを形式的に結合した構造である。
【０１３０】
この形式的に合体された構造は、仮想デバイスＶＣＲ／ＥＰＧのための内部モデルについて記述しており、図７のブロック図によって示される。明らかに、図４及び図６の内部モデルの構造がみられるこれらのモデルについては、この時点では、再び詳細に説明はしない。更に、仮想デバイスＶＣＲ／ＥＰＧの組合せ、又は形式的に合体した内部モデルは、単一の個別デバイスであるＶＣＲ及びＥＰＧについて、それぞれの内部モデルを接続するための他の遷移１５０及び１６０を含む。
【０１３１】
遷移１６０は、停止モード１０２を準備完了モード８２に一方向に接続する。
【０１３２】
更に、結果受信モード８６は、遷移１６０によって録画モード１０４に一方向に接続される。
【０１３３】
図２乃至図７において、ＶＣＲとＥＰＧについての理論モデルが示されている。各単一の個別デバイスの各理論モデルは、内部モデル及び少なくとも１つの外部モデルへ分類される。
【０１３４】
外部モデルは、個別の単一のデバイスの入力及び出力データをモデル化する。外部モデルは、ユーザリクエストにサービスするための適切なデバイスを見つけるために使用される。個別の単一のデバイスに関する入力及び出力データのモデル化は、前記個別の単一のデバイスに関して使用される機能に依存する。内部モデルは、それぞれの場合に、特に有限状態機械（ＦＳＭ：finite state machine）の形式で、個別の単一のデバイスについてより詳細に記述する。内部モデルは、個別の単一のデバイスの制御のために、計画、方法の生成に使用される。
【０１３５】
内部モデル中の幾つかの状態が前記入出力データとともに注釈されるように、外部モデル中の入力及び出力データは、内部及び外部モデル間の接続を確立することを強調しなければならない。
【０１３６】
更に、録画モード１０４の事前条件、事後条件構造１１３が図６の中で示されるように、ＶＣＲの内部モデルの幾つかの状態は、事前条件、事後条件で記述され得る。映画を録画するために、システムは、少なくともチャンネルと開始時間を認識している必要がある。この認識は、ＥＰＧの外部モデルのフォーマット、すなわち入出力データを備えた事前条件に記述されるような電子番組ガイドＥＰＧの要求により得ることができる。しかしながら、チャンネルと開始時間に関する認識が、システムにおいて既に利用可能となっている場合、ＥＰＧを使用する必要はない。この場合は、追加の記述によってモデル化され得るが、これは、図中で示されていない理由を明らかにするためである。
【０１３７】
図７は、ＶＣＲとＥＰＧの個別モデルの合体により得られた仮想デバイスモデルの構成を示すブロック図である。ＶＣＲの内部モデルに録画する状態又は録画モード１０４の事前条件は、ＥＰＧの外部モデルの形式で形式化され得る。このように、事前条件は、ＥＰＧの内部モデル全体と置き換えることができ、ＶＣＲとＥＰＧからなる仮想デバイスの内部モデルが得られるようになる。
【０１３８】
この仮想デバイス（その内部モデルが図７に示されている）は、複雑なタスク「映画ＸＹＺを録画する」の全体を完了するために、計画又は方法を生成することに使用される。
【０１３９】
タスク「ビデオ映画を複写する」のための理論モデルは、以下の構造を持ち得る。
ModelFunction(copyVideo, [VideoSignalOnMedium(Para1)],
[VideoSignalOnMedium(Para2)]).
【０１４０】
このモデルが与えられると、システムは、与えられたデバイスの外部モデルを介して、探索し、ＶＣＲの外部及び内部モデルを用いて、次のように推定する。すなわち、状態「再生」１１０中の入力データが、VideoSignalOnMedium(Para1)であり、状態「再生」１１０中の出力データが、VideoSignalOnMedium(Para2)であるので、全体のシステムは、２つのＶＣＲの使用による機能「ビデオ映画を複写する」を提供する。ビデオレコーダ（ＶＣＲ）の一方は、状態「録画」１０４になる必要があり、他方は、状態「再生」１１０になる必要がある。１つの単一のデバイスが、同時に異なる状態ではありえないので、前述の例では、２つのビデオカセットレコーダ（ＶＣＲ）が必要であることは容易に推論される。しかしながら、タスクの理論モデルは、タスクを完了するために、必ずしもシステムにＶＣＲを使用するように強制はしない。代わりに、システムは、例えば機能「メディアＸからの動画ストリームを再生」を提供するデバイスを探索することができる。これは、任意のデバイスであり得る。したがって、ネットワーク又はシステムにおいて利用可能なデバイスの異なる組合せを使用しても、複雑なタスクの完了が実現され得るという意味で、システムは柔軟になされている。
【０１４１】
図８は、ネットワークデバイスに関する本発明のユーザリクエスト供給方法の他の実施形態、特にマンマシンインタフェースユニット（ＭＭＩ）を操作する方法を示すフローチャートである。
【０１４２】
予備ステップＳ０において、方法又はシステムが開始し、初期化される。
【０１４３】
第１のステップＳ１において、音声入力（ＳＩ）は、複雑なユーザリクエスト（ＵＲ）として受信される。
【０１４４】
次のステップＳ２において、発声又はユーザリクエストを認識するプロセスは、ユーザリクエスト（ＵＲ）を評価するユーザ入力（ＳＩ）に適用され、解釈した結果、リクエスト情報データ（ＲＩＤ）、特に、主要なデータソース情報（ＰＤＳＩ）、主要なデータ目標情報（ＰＤＴＩ）及び主要なアクション情報（ＰＡＩ）を導出する工程が続く。このプロセスは、データベース（ＤＢ）へのリンクＳ２ａによって対応され得る。
【０１４５】
次の第３のステップＳ３において、リクエスト情報データ（ＲＩＤ）から、デバイス情報データ（ＤＩＤ）及びアクション情報データ（ＡＩＤ）が導出されるが、これは、ステップＳ３ａによってデータベース（ＤＢ）を参照することで対応され得る。
【０１４６】
次の第４のステップＳ４において、適切なアクション列が導出されるが、これは、ユーザリクエスト（ＵＲ）に対する１つの適切な応答の役目をする。
【０１４７】
次の第５のステップＳ５において、導出したアクション列についての評価を行い、最も適切な特定のアクション列を選択するが、このプロセスは、ステップＳ５ａによるデータベース（ＤＢ）を再度参照することによって行い得る。
【０１４８】
その後、選択された一連のアクション列は、動作されるか、実行されるか、実施される。
【０１４９】
最終のステップＳ７において、方法は、第１のステップＳ０に戻るか、又は待機モードになる。
【０１５０】
図９は、接続手段３６及び３７によって接続されたＶＣＲ３５−１、ＴＶ３５−２、ＳＴＢ３５−３及びＥＰＧ３５−４で構築されたホームネットワークと、マンマシンインタフェースユニット（ＭＭＩ）３０との接続を、より詳細に示すブロック図である。
【０１５１】
図９の実施形態のＭＭＩ３０は、立案モジュール３２と組み合わせた対話マネージャ３１を含む。立案モジュール３２そのものは、デバイス３５−１〜３５−４の各々用に、機能モデル３３−１〜３３−４を含むモデルコンポーネント３３及び推論コンポーネント３４によって構築される。
【０１５２】
図１０は、本発明による、特に図９によるマンマシンインタフェースユニットＭＭＩにおける立案モジュール３２の推論コンポーネント３４の構成を示すブロック図である。そのような推論コンポーネント３４は、デバイス探索アルゴリズム（ＤＳＡ）６１、状態探索アルゴリズム（ＳＳＡ）６２、アクション探索又は立案アルゴリズム（ＡＳＡ）６３、及びアクション実行アルゴリズム（ＡＰＡ）６４からなる。
【０１５３】
対照的に、図１１で示されるような先行技術におけるＭＭＩ７０は、一般的に単一の対話マネージャ７１を含み、また、立案（プランニング）モジュール又は推論コンポーネントを含まずに、それぞれの接続手段７６及び７７によってそれぞれのデバイス３５−１〜３５−４にそれぞれ接続される。
【図面の簡単な説明】
【０１５４】
【図１】ホームネットワーク内の本発明のアプリケーションの構成を示すブロック図である。
【図２】電子番組ガイド（ＥＰＧ）の外部モデルの構成を示すブロック図である。
【図３】電子番組ガイド（ＥＰＧ）の第１の内部モデルの構成を示すブロック図である。
【図４】電子番組ガイド（ＥＰＧ）の第２の内部モデルの構成を示すブロック図である。
【図５】ビデオレコーダ（ＶＣＲ）の外部モデルの構成を示すブロック図である。
【図６】ビデオレコーダ（ＶＣＲ）の内部モデルの構成を示すブロック図である。
【図７】図４の電子番組ガイド（ＥＰＧ）と図６のビデオレコーダ（ＶＣＲ）を組み合わせた仮想デバイスの内部モデルの構成を示すブロック図である。
【図８】複雑なユーザリクエストにサービスする本発明のユーザリクエスト供給方法の好ましい実施形態を説明するためのフローチャートである。
【図９】本発明の実施形態を実現する対話システムの構成を示すブロック図である。
【図１０】本発明のユーザリクエスト供給方法の実施形態に含まれる立案モジュールの推論コンポーネントの構成を示すブロック図である。
【図１１】ホームネットワークを制御するための先行技術における対話システムの構成を示すブロック図である。
【図１２】複写プロセス用の仮想デバイスの構成を示すブロック図である。
【符号の説明】
【０１５５】
２０  マンマシンインタフェースユニット、２５−１  ビデオカセットレコーダ、２５−２  テレビ受像機、２５−３  セットトップボックス、２５−４  電子番組ガイド、２５−５  ミニディスクレコーダ、２６  接続手段、２７  接続手段、３０  マンマシンインタフェースユニット、３５−１  ビデオカセットレコーダ、３５−２  テレビ受像機、３５−３  セットトップボックス、３５−４  電子番組ガイド、３６  接続手段、３７  接続手段、４３  電子番組ガイド、５０  遷移、７０  マンマシンインタフェースユニット、７６  接続手段、７７  接続手段、８０  遷移、９３  ビデオレコーダ、１００  遷移、１００ａ  遷移
【図１】
2004342113.tif 000003
【図２】
2004342113.tif 000004
【図３】
2004342113.tif 000005
【図４】
2004342113.tif 000006
【図５】
2004342113.tif 000007
【図６】
2004342113.tif 000008
【図７】
2004342113.tif 000009
【図８】
2004342113.tif 000010
【図９】
2004342113.tif 000011
【図１０】
2004342113.tif 000012
【図１１】
2004342113.tif 000013
【図１２】
2004342113.tif 000014