(57)【特許請求の範囲】
【請求項１】
エージェント機能によって所定のコンテキストの中で決定を判定するためのデジタルテレビジョン等におけるエージェント機能を用いた判定方法であって、
少なくともユーザについての属性情報、ユーザの行った決定に関する情報、出現頻度を含む複数のユーザ挙動パターンを蓄積したデータベースより、複数のユーザ挙動パターンの情報を受信する受信工程と、
前記コンテキストの属性と、前記受信工程において前記データベースより受信した前記複数のユーザ挙動パターンの属性情報を演算手段に入力し、比較して一致する属性の数を判定する判定工程と、
前記判定工程において判定された一致する属性の数に基づいて前記複数のユーザ挙動パターンを分類しグループを形成するグループ形成工程と、
前記一致する属性を最も多く有するグループに対して決定選択プロセスを実行することにより前記複数のユーザ挙動パターンから前記コンテキストに最も適した決定を選択する選択工程と、
前記選択工程によって選択された決定に従って受信或いは再生動作を制御する制御工程とを有することを特徴とする判定方法。
【請求項２】
前記複数のグループの各々に対して複数のサブグループの各々が固有の属性を有する前記複数のユーザ挙動パターンのサブグループを形成する工程を更に有し、
前記決定選択プロセスは、前記一致する属性を最も多く有するグループに対して各サブグループにおける出現頻度が最も高い前記挙動パターンから決定を選択することを特徴とする請求項１記載の判定方法。
【請求項３】
前記ユーザ決定の各々に決定値が割り当てられ、前記決定選択プロセスは、各サブグループにおける出現頻度が最も高い前記挙動パターンの前記決定値の平均値を計算する計算プロセスを含み、前記挙動パターンから前記平均値に最も近い決定を選択することを特徴とする請求項２記載の判定方法。
【請求項４】
前記決定選択プロセスは、複数の決定区間の定義済みグループから前記平均値に最も近い決定区間を判定する判定プロセスを含み、前記判定区間は前記決定値によって定義され、前記判定された決定区間の範囲内にある前記サブグループから出現頻度が最も高い決定を選択することを特徴とする請求項３記載の判定方法。
【請求項５】
前記決定選択プロセスは、複数の決定区間の定義済みグループから前記平均値に最も近い決定区間を判定する判定プロセスを含み、前記判定区間は前記決定値によって定義され、前記判定された決定区間の範囲内にある前記サブグループから特定の決定を選択することを特徴とする請求項３記載の判定方法。
【請求項６】
前記決定選択プロセスで特定の決定を選択できない場合、前記決定選択プロセスは出現頻度が最も高い決定を選択することを特徴とする請求項５記載の判定方法。
【請求項７】
前記決定選択プロセスは、各サブグループにおける出現頻度が最も高い前記挙動パターンから固有の決定を選択できない場合、決定リストの中の対応するエントリの数がより多い決定のうちの１つを選択する工程を更に有することを特徴とする請求項３記載の判定方法。
【請求項８】
前記決定選択プロセスは、
前記決定リストの中の対応するエントリの数がより多い固有の決定を選択できない場合、前記最も多数の一致する属性に関連付けられた前記サブグループの全てのエントリを前記決定リストに加える工程と、
一致する属性を次に多く有するグループに関連付けられたサブグループと共に前記決定選択プロセスを反復する工程とを更に有することを特徴とする請求項７記載の判定方法。
【請求項９】
前記決定選択プロセスは、
前記反復工程の実行後に固有の決定を選択できない場合、前記決定リストの中の挙動パターンの前記決定値の平均値を計算する工程と、
複数の決定区間からなる前記定義済のグループからのどの決定区間が前記決定リストに対して計算された前記平均値に最も近いかを判定する工程と、
前記決定リストから前記決定区間の範囲内にあり且つ出現率が最高である決定を選択する工程とを更に有することを特徴とする請求項８記載の判定方法。
【請求項１０】
エージェント機能によって所定のコンテキストの中で決定を判定するためのデジタルテレビジョン等におけるエージェント機能を用いた判定方法であって、
割り当てられた決定値及び出現頻度を有するユーザ決定を含む複数のユーザ挙動パターンを蓄積したデータベースより、複数のユーザ挙動パターンの情報を受信する受信工程と、
前記コンテキストを、前記受信工程において前記データベースより受信した前記複数のユーザ挙動パターンの各々と比較して、前記複数のユーザ挙動パターンの各々に対する前記コンテキストの共通部分の数を判定する判定工程と、
前記判定工程において判定された前記共通部分の数に基づいて前記複数のユーザ挙動パターンを分類し同数の前記共通部分を有するグループを形成するグループ形成工程と、
前記グループ形成工程において形成された複数のグループの各々に対して、複数の固有の共通部分を備える前記複数のユーザ挙動パターンを抽出して複数のサブグループを形成するサブグループ形成工程と、
前記共通部分を最も多く有するグループに対して、対応する複数のサブグループにおける出現頻度が最高であるユーザ挙動パターンに対応する前記決定値の平均値を計算する平均計算工程と、
複数の決定区間の定義済みグループから前記平均値に最も近い決定区間を判定する決定区間判定工程と、
前記サブグループから前記判定された決定区間の範囲内で且つ出現頻度が最高である決定を選択する選択工程と、
前記選択工程によって選択された決定に従って受信或いは再生動作を制御する制御工程とを有することを特徴とする判定方法。
【請求項１１】
前記選択工程で固有の決定を選択できない場合、前記選択工程で選択された決定のうちの、決定リストの中の対応するエントリの数がより多い１つを選択する第２の選択工程を更に有することを特徴とする請求項１０記載の判定方法。
【請求項１２】
前記第２の選択工程で固有の決定を選択できない場合、最も多くの共通部分を有するグループに関連付けられた前記サブグループの全てのエントリを前記決定リストに加える工程と、
共通部分を次に多く有するグループに関連付けられたサブグループと共に前記平均計算工程から前記第２の選択工程を反復する反復工程とを更に有すること特徴とする請求項１１記載の判定方法。
【請求項１３】
前記反復工程で固有の決定を選択できない場合、前記決定リストの中の挙動パターンの前記決定値の平均値を計算する計算工程と、
複数の決定区間から成る前記定義済みのグループからのどの決定区間が、前記計算工程で計算された前記平均値に最も近いかを判定する工程と、
前記決定リストから前記決定区間の範囲内で且つ出現率が最高である決定を選択する工程とを更に有することを特徴とする請求項１２記載の判定方法。
【請求項１４】
前記複数のユーザ挙動パターンの各々は、前記ユーザ決定が下されたときにコンテキストに共通するコンテキストデータを含むことを特徴とする請求項１０記載の判定方法。
【請求項１５】
エージェント機能によって所定のコンテキストの中で決定を判定するためのデジタルテレビジョン等におけるエージェント機能を用いた判定装置であって、
少なくともユーザについての属性情報、ユーザの行った決定に関する情報、出現頻度を含む複数のユーザ挙動パターンを蓄積したデータベースより、複数のユーザ挙動パターンの情報を受信する受信手段と、
前記コンテキストの属性と、前記受信手段によって前記データベースより受信した前記複数のユーザ挙動パターンの属性情報を演算手段に入力し、比較して一致する属性の数を判定する判定手段と、
前記判定手段で判定された一致する属性の数に基づいて前記複数のユーザ挙動パターンを分類しグループを形成するグループ形成手段と、
前記一致する属性を最も多く有するグループに対して決定選択プロセスを実行することにより前記複数のユーザ挙動パターンから前記コンテキストに最も適した決定を選択する選択手段と、
前記選択手段によって選択された決定に従って受信或いは再生動作を制御する制御手段とを有することを特徴とする判定装置。
【請求項１６】
前記複数のグループの各々に対して複数のサブグループの各々が固有の属性を有する前記複数のユーザ挙動パターンのサブグループを形成する手段を更に有し、
前記決定選択プロセスは、前記一致する属性を最も多く有するグループに対して各サブグループにおける出現頻度が最も高い前記挙動パターンから決定を選択することを特徴とする請求項１５記載の判定装置。
【請求項１７】
前記ユーザ決定の各々に決定値が割り当てられ、前記決定選択プロセスは、各サブグループにおいて出現頻度が最も高い前記挙動パターンの前記決定値の平均値を計算する計算プロセスを含み、前記挙動パターンから前記平均値に最も近い決定を選択することを特徴とする請求項１６記載の判定装置。
【請求項１８】
前記決定選択プロセスは、複数の決定区間の定義済みグループから前記平均値に最も近い決定区間を判定する判定プロセスを含み、前記判定区間は前記決定値によって定義され、前記判定された決定区間の範囲内にある前記サブグループから出現頻度が最も高い決定を選択することを特徴とする請求項１７記載の判定装置。
【請求項１９】
前記決定選択プロセスは、複数の決定区間の定義済みグループから前記平均値に最も近い決定区間を判定する判定プロセスを含み、前記判定区間は前記決定値によって定義され、前記判定された決定区間の範囲内にある前記サブグループから特定の決定を選択することを特徴とする請求項１７記載の判定装置。
【請求項２０】
前記決定選択プロセスで特定の決定を選択できない場合、前記決定選択プロセスは出現頻度が最も高い決定を選択することを特徴とする請求項１９記載の判定装置。
【請求項２１】
前記決定選択プロセスは、各サブグループにおける出現頻度が最も高い前記挙動パターンから固有の決定を選択できない場合、決定リストの中の対応するエントリの数がより多い決定のうちの１つを選択する工程を更に有することを特徴とする請求項１７記載の判定装置。
【請求項２２】
前記決定選択プロセスは、
前記決定リストの中の対応するエントリの数がより多い固有の決定を選択できない場合、前記最も多数の一致する属性に関連付けられた前記サブグループの全てのエントリを前記決定リストに加える工程と、
一致する属性を次に多く有するグループに関連付けられたサブグループと共に前記決定選択プロセスを反復する工程とを更に有することを特徴とする請求項２１記載の判定装置。
【請求項２３】
前記決定選択プロセスは、
前記反復工程の実行後に固有の決定を選択できない場合、前記決定リストの中の挙動パターンの前記決定値の平均値を計算する工程と、
複数の決定区間からなる前記定義済のグループからのどの決定区間が前記決定リストに対して計算された前記平均値に最も近いかを判定する工程と、
前記決定リストから前記決定区間の範囲内にあり且つ出現率が最高である決定を選択する工程とを更に有することを特徴とする請求項２２記載の判定装置。
【請求項２４】
エージェント機能によって所定のコンテキストの中で決定を判定するためのデジタルテレビジョン等におけるエージェント機能を用いた判定装置であって、
割り当てられた決定値及び出現頻度を有するユーザ決定を含む複数のユーザ挙動パターンを蓄積したデータベースより、複数のユーザ挙動パターンの情報を受信する受信手段と、
前記コンテキストを、前記受信手段において前記データベースより受信した前記複数のユーザ挙動パターンの各々と比較して、前記複数のユーザ挙動パターンの各々に対する前記コンテキストの共通部分の数を判定するプロセッサによって構成された判定手段と、
前記判定手段において判定された前記共通部分の数に基づいて前記複数のユーザ挙動パターンを分類し同数の前記共通部分を有するグループを形成する前記プロセッサによって構成されたグループ形成手段と、
前記グループ形成手段において形成された複数のグループの各々に対して、複数の固有の共通部分を備える前記複数のユーザ挙動パターンを抽出して複数のサブグループを形成する前記プロセッサによって構成されたサブグループ形成手段と、
前記共通部分を最も多く有するグループに対して、対応する複数のサブグループにおける出現頻度が最高であるユーザ挙動パターンに対応する前記決定値の平均値を計算する前記プロセッサによって構成された平均計算手段と、
複数の決定区間の定義済みグループから前記平均値に最も近い決定区間を判定する前記プロセッサによって構成された決定区間判定手段と、
前記サブグループから前記判定された決定区間の範囲内で且つ出現頻度が最高である決定を選択する前記プロセッサによって構成された選択手段と、
前記選択手段によって選択された決定に従って受信或いは再生動作を制御する制御手段とを有することを特徴とする判定装置。
【請求項２５】
前記複数のユーザ挙動パターンの各々は、前記ユーザ決定が下されたときにコンテキストに共通するコンテキストデータを含むことを特徴とする請求項２４記載の判定装置。
【請求項２６】
エージェント機能によって所定のコンテキストの中で決定を判定するためのデジタルテレビジョン等におけるエージェント機能を用いた判定方法を実現するためのメモリ媒体に記憶されたプログラムであって、
少なくともユーザについての属性情報、ユーザの行った決定に関する情報、出現頻度を含む複数のユーザ挙動パターンを蓄積したデータベースより、複数のユーザ挙動パターンの情報を受信する受信工程を実行するためのコードと、
前記コンテキストの属性と、前記受信工程において前記データベースより受信した前記複数のユーザ挙動パターンの属性情報を演算手段に入力し、比較して一致する属性の数を判定する判定工程を実行するためのコードと、
前記判定工程において判定された一致する属性の数に基づいて前記複数のユーザ挙動パターンを分類しグループを形成するグループ形成工程を実行するためのコードと、
前記一致する属性を最も多く有するグループに対して決定選択プロセスを実行することにより前記複数のユーザ挙動パターンから前記コンテキストに最も適した決定を選択する選択工程を実行するためのコードと、
前記選択工程によって選択された決定に従って受信或いは再生動作を制御する制御工程を実行するためのコードとを有することを特徴とする判定方法を実行するためのプログラム。
【請求項２７】
前記複数のグループの各々に対して複数のサブグループの各々が固有の属性を有する前記複数のユーザ挙動パターンのサブグループを形成する工程を実行するためのコードを更に含み、
前記決定選択プロセスは、前記一致する属性を最も多く有するグループに対して各サブグループにおける出現頻度が最も高い前記挙動パターンから決定を選択することを特徴とする請求項２６記載のプログラム。
【請求項２８】
前記ユーザ決定の各々に決定値が割り当てられ、前記決定選択プロセスは、各サブグループにおける出現頻度が最も高い前記挙動パターンの前記決定値の平均値を計算する計算プロセスを含み、前記挙動パターンから前記平均値に最も近い決定を選択することを特徴とする請求項２７記載のプログラム。
【請求項２９】
前記決定選択プロセスは、複数の決定区間の定義済みグループから前記平均値に最も近い決定区間を判定する判定プロセスを含み、前記判定区間は前記決定値によって定義され、前記判定された決定区間の範囲内にある前記サブグループから出現頻度が最も高い決定を選択することを特徴とする請求項２８記載のプログラム。
【請求項３０】
前記決定選択プロセスは、複数の決定区間の定義済みグループから前記平均値に最も近い決定区間を判定する判定プロセスを含み、前記判定区間は前記決定値によって定義され、前記判定された決定区間の範囲内にある前記サブグループから特定の決定を選択することを特徴とする請求項２８記載のプログラム。
【請求項３１】
前記決定選択プロセスで特定の決定を選択できない場合、前記決定選択プロセスは出現頻度が最も高い決定を選択することを特徴とする請求項３０記載のプログラム。
【請求項３２】
前記決定選択プロセスは、各サブグループにおける出現頻度が最も高い前記挙動パターンから固有の決定を選択できない場合、決定リストの中の対応するエントリの数がより多い決定のうちの１つを選択する工程を実行するためのコードを更に有することを特徴とする請求項２８記載のプログラム。
【請求項３３】
前記決定選択プロセスは、
前記決定リストの中の対応するエントリの数がより多い固有の決定を選択できない場合、前記最も多数の一致する属性に関連付けられた前記サブグループの全てのエントリを前記決定リストに加える工程を実行するためのコードと、
一致する属性を次に多く有するグループに関連付けられたサブグループと共に前記決定選択プロセスを反復する工程を実行するためのコードとを更に有することを特徴とする請求項３２記載のプログラム。
【請求項３４】
前記決定選択プロセスは、
前記反復工程の実行後に固有の決定を選択できない場合、前記決定リストの中の挙動パターンの前記決定値の平均値を計算する工程を実行するためのコードと、
複数の決定区間からなる前記定義済のグループからのどの決定区間が前記決定リストに対して計算された前記平均値に最も近いかを判定する工程を実行するためのコードと、
前記決定リストから前記決定区間の範囲内にあり且つ出現率が最高である決定を選択する工程を実行するためのコードとを更に有することを特徴とする請求項３３記載のプログラム。
【請求項３５】
エージェント機能によって所定のコンテキストの中で決定を判定するためのデジタルテレビジョン等におけるエージェント機能を用いた判定方法を実行するためのメモリ媒体に記憶されたプログラムであって、
割り当てられた決定値及び出現頻度を有するユーザ決定を含む複数のユーザ挙動パターンを蓄積したデータベースより、複数のユーザ挙動パターンの情報を受信する受信工程を実行するためのコードと、
前記コンテキストを、前記受信工程において前記データベースより受信した前記複数のユーザ挙動パターンの各々と比較して、前記複数のユーザ挙動パターンの各々に対する前記コンテキストの共通部分の数を判定する判定工程を実行するためのコードと、
前記判定工程において判定された前記共通部分の数に基づいて前記複数のユーザ挙動パターンを分類し同数の前記共通部分を有するグループを形成するグループ形成工程を実行するためのコードと、
前記グループ形成工程において形成された複数のグループの各々に対して、複数の固有の共通部分を備える前記複数のユーザ挙動パターンを抽出して複数のサブグループを形成するサブグループ形成工程を実行するためのコードと、
前記共通部分を最も多く有するグループに対して、対応する複数のサブグループにおける出現頻度が最高であるユーザ挙動パターンに対応する前記決定値の平均値を計算する平均計算工程を実行するためのコードと、
複数の決定区間の定義済みグループから前記平均値に最も近い決定区間を判定する決定区間判定工程を実行するためのコードと、
前記サブグループから前記判定された決定区間の範囲内で且つ出現頻度が最高である決定を選択する選択工程を実行するためのコードと、
前記選択工程によって選択された決定に従って受信或いは再生動作を制御する制御工程を実行するためのコードとを有することを特徴とする判定方法を実行するためのプログラム。
【請求項３６】
前記複数のユーザ挙動パターンの各々は、前記ユーザ決定が下されたときにコンテキストに共通するコンテキストデータを含むことを特徴とする請求項３５記載のプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、人工知能を有するシステムに関し、特にコンテキストベースの意思決定を行なうシステムに関する。
【０００２】
【従来の技術】
テレビの視聴は、多くの世帯において日常的な活動であり、ニュース及び事実に基づくプログラム（ドキュメンタリー及び生活様式など）のみならずスポーツ及び映画などの一定範囲のプログラムコンテンツより娯楽の源を提供する。デジタルテレビ（ＤＴＶ）の出現により、テレビを使用してインターネットを閲覧したり、オンラインショッピングを行なったり、テレビを介して電子メッセージ（電子メール）を受信したりすることもできる。このため、ホームテレビが外界との主な接点となってきている。
【０００３】
従来、ユーザ／視聴者は、ＤＴＶにコンテンツの表示方法を指図する多数の「ユーザプリファレンス」を設定する。例えば、この設定には、電子メールの到着時の通知をユーザが希望するか否かに関する設定が含まれる。更に、ユーザは、補助ウィンドウにメッセージを自動的に表示することを希望することもできる。しかし、このようなユーザプリファレンスは、固定的なものではなく、種々の要素に左右される可能性がある。この要素には、例えば電子メールが到着したときにユーザが見ているプログラムの性質、メッセージの優先度などが含まれる。ユーザは、「ユーザプリファレンス」を設定するときに、最も起こる可能性が高いシナリオを予測するか、或いは最も保守的な選択を行なう必要があるので、これは望ましくない。
【０００４】
本発明の目的は、既存の構成の１つ以上の問題点をほぼ克服するか、少なくとも改善することである。
【０００５】
【課題を解決するための手段】
本発明の第１の態様によると、エージェント機能によって所定のコンテキストの中で決定を判定するためのデジタルテレビジョン等におけるエージェント機能を用いた判定方法であって、
少なくともユーザについての属性情報、ユーザの行った決定に関する情報、出現頻度等を含む複数のユーザ挙動パターンを蓄積したデータベースより、複数のユーザ挙動パターンの情報を受信する受信工程と、
前記コンテキストの属性と、前記受信工程において前記データベースより受信した前記複数のユーザ挙動パターンの属性情報を演算手段に入力し、比較して一致する属性の数を判定する判定工程と、
前記判定工程において判定された一致する属性の数に基づいて前記複数のユーザ挙動パターンを分類しグループを形成するグループ形成工程と、
前記一致する属性を最も多く有するグループに対して決定選択プロセスを実行することにより前記複数のユーザ挙動パターンから前記コンテキストに最も適した決定を選択する選択工程と、
前記選択工程によって選択された決定に従って受信或いは再生動作を制御する制御工程とを有することを特徴とする判定方法が提供される。
【０００６】
本発明の別の態様によると、エージェント機能によって所定のコンテキストの中で決定を判定するためのデジタルテレビジョン等におけるエージェント機能を用いた判定方法であって、
割り当てられた決定値及び出現頻度を有するユーザ決定を含む複数のユーザ挙動パターンを蓄積したデータベースより、複数のユーザ挙動パターンの情報を受信する受信工程と、
前記コンテキストを、前記受信工程において前記データベースより受信した前記複数のユーザ挙動パターンの各々と比較して、前記複数のユーザ挙動パターンの各々に対する前記コンテキストの共通部分の数を判定する判定工程と、
前記判定工程において判定された前記共通部分の数に基づいて前記複数のユーザ挙動パターンを分類し同数の前記共通部分を有するグループを形成するグループ形成工程と、
前記グループ形成工程において形成された複数のグループの各々に対して、複数の固有の共通部分を備える前記複数のユーザ挙動パターンを抽出して複数のサブグループを形成するサブグループ形成工程と、
前記共通部分を最も多く有するグループに対して、対応する複数のサブグループにおける出現頻度が最高であるユーザ挙動パターンに対応する前記決定値の平均値を計算する平均計算工程と、
複数の決定区間の定義済みグループから前記平均値に最も近い決定区間を判定する決定区間判定工程と、
前記サブグループから前記判定された決定区間の範囲内で且つ出現頻度が最高である決定を選択する選択工程と、
前記選択工程によって選択された決定に従って受信或いは再生動作を制御する制御工程とを有することを特徴とする判定方法が提供される。
【０００７】
本発明の別の態様によると、上述の方法のいずれか１つを実行する装置が提供される。
【０００８】
本発明の更に別の態様によると、上述の方法のいずれか１つを実行するための、コンピュータ媒体に記憶されたプログラムが提供される。
【０００９】
本発明は、決定のコンテキスト及び過去のユーザの挙動、即ち、過去のコンテスト中に行なわれた過去の決定を考慮に入れて決定を判定する方法にある。
【００１０】
【発明の実施の形態】
以下の説明の一部は、アルゴリズムとコンピュータメモリ内のデータに対する動作の記号表現との観点から明示的又は黙示的に提示される。これらのアルゴリズムの記述及び表現は、データ処理分野の当業者が作業内容を他の当業者に最も効果的に伝達するために使用する手段である。ここで示すアルゴリズムは、通常、所望の結果に至る一貫したステップのシーケンスと見なされる。
【００１１】
本明細書は、上述の方法の動作を実行する装置も開示する。このような装置は所望の目的のために特別に構成されても良いし、汎用コンピュータ又はこのコンピュータに格納されたコンピュータプログラムにより選択的に起動又は再構成されるその他の装置を備えても良い。ここで提示されるアルゴリズム及び表示は、特定のコンピュータ又はその他の装置にのみ関するものではない。本明細書での教示に従ったプログラムと共に、種々の汎用装置を使用しても良い。或いは、より専門的な装置に所望の方法ステップを実行させる構成も適切であろう。以下の説明では、従来の汎用コンピュータの構造が記載される。
【００１２】
添付の何れか１つ以上の図面において、同じ符号を有するステップ及び／又は特徴に言及する場合、特に明記されていない限り、以下の記述においては、これらのステップ及び／又は特徴は、同じ機能又は動作を有するものとする。
【００１３】
図１Ａに、ユーザの機能的な利用パターンを学習し、特定のコンテキストにおける特定のユーザに適した最善のイベントシーケンスを計画するためのシステム５０の概略的な表現を示す。システム５０は、「セットトップ」ボックス２０への相互接続２５を介して接続されるデジタルＴＶ（ＤＴＶ）１０を具備する。ＤＴＶエージェントシステム２１は、「セットトップ」ボックス２０内に形成されるのが好ましい。使用の際に、ユーザは、リモートコントロール装置３０を使用してＤＴＶエージェントシステム２１と対話する。また、ＤＴＶエージェントシステム２１は、ＤＴＶ１０に統合されても良く、或いは、図８に示すようにパソコン１００に組み込まれてＤＴＶ１０と適切にインタフェースをとるようにしても良い。
【００１４】
図８に示すコンピュータシステム１００は、コンピュータモジュール１０２と、キーボード１１０及びマウス１１２などの入力装置と、プリンタ１０８及び表示装置１０４を含む出力装置とを具備する。コンピュータモジュール１０２は、通常、少なくとも１つのプロセッサ部１１４と、半導体のランダムアクセスメモリ（ＲＡＭ）及び読出し専用メモリ（ＲＯＭ）などで形成されたメモリ部１１８と、ビデオインタフェース１２２及びキーボード１１０並びにマウス１１２用のＩ／Ｏインタフェース１１６を含む入出力（Ｉ／Ｏ）インタフェースとを含む。記憶装置１２４が設けられ、この記憶装置は、通常、ハードディスクドライブ１２６及びフロッピー（登録商標）ディスクドライブ１２８を含む。磁気テープドライブ（不図示）を使用しても良い。一般的に、ＣＤ−ＲＯＭドライブ１２０が、不揮発性のデータソースとして設けられる。コンピュータモジュール１０２の構成要素１１４から１２８は、通常、相互接続バス１３０を介してコンピュータシステム１００の動作モードが当業者には既知の従来の動作モードになるように通信を行なう。
【００１５】
一般的に、ハードディスクドライブ１２６には、アプリケーションプログラムが常駐し、実行時にはプロセッサ１１４によって読み出し／制御が行なわれる。プログラムの中間記憶装置は、半導体メモリ１１８を使用して、場合によってはハードディスクドライブ１２６と協働して達成されても良い。アプリケーションプログラムは、ＣＤ−ＲＯＭ又はフロッピー（登録商標）ディスク上に符号化された形で視聴者に供給され、対応するドライブ１２０又は１２８を介して読み取られる場合もあれば、ネットワークからモデム装置（不図示）を介して視聴者が読み取る場合もある。更に、このソフトウェアは、磁気テープ、ＲＯＭ又は集積回路、光磁気ディスク、コンピュータモジュール１０２と別の装置との間の無線又は赤外線の伝送チャネル、ＰＣＭＣＩＡカードなどのコンピュータ読み取り可能なカード、及び電子メール送受信並びにウェブサイトなどに記録された情報を含むインターネット並びにイントラネットを含むその他のコンピュータ読み取り可能な媒体からコンピュータシステム１００にロードすることもできる。以上の媒体は、関連するコンピュータ読み取り可能な媒体のほんの一例である。本発明の趣旨から逸脱することなくその他のコンピュータ読み取り可能な媒体を用いて実施することもできる。
【００１６】
図１Ａを再度参照すると、好適な実施形態において、ＤＴＶエージェントシステム２１は、ＤＴＶ１０を制御するためのＤＴＶエージェント３６、電子記憶装置２６、ユニファイドメッセージ通信モジュール（ＵＭＭ）２７及び複数のアバターエージェント３７を含む。これに関して「エージェント」は、通常、所望の機能を実行し又は所望の効果をあげるように構成されたコンピュータプログラムモジュールにより実現される。エージェント間サーバ（ＩＡＳ）３５が、ＤＴＶエージェント３６、電子記憶装置２６、ＵＭＭ２７及び複数のアバターエージェント３７の相互の通信を管理する。また、ＩＡＳ３５はゲートウェイ４５を介して「セットトップ」ボックス２０を外部ネットワーク４２に接続する。その外部ネットワーク４２には複数のコンテンツサーバ４３及び電子プログラムガイド（ＥＰＧ）データベース２２が接続される。
【００１７】
ＤＴＶエージェント３６の機能には、以下のものが含まれる：
−ＤＴＶ１０の表示画面１１を介してのグラフィカルユーザインタフェースの提供、
−視聴するマルチメディアコンテンツを選択するためのコンテンツサーバ４３との対話、ＵＭＭ２７からのメッセージの閲覧及び電子記憶装置２６に記録されたコンテンツの視聴を含むＤＴＶ１０の機能の制御、及び
−ユーザが選択したプログラム及びＤＴＶ１０との対話の収集及び複数のアバターエージェント３７へのそれらの出力。
【００１８】
各々のアバターエージェント３７は１人のユーザに関連付けられており、少なくとも１つの視聴者事例データベース２４を使用して、以降の使用のために関連付けられたユーザに関する情報を格納する。ここで使用されるデータベースという用語は、一般的に、データレコードを指し、何ら特定のデータ構造を意味しない。図１Ｂに示すように、各アバターエージェント３７は、その特定のアバターエージェント３７の制御を維持するアバターマネージャ３８を含む。また、アバターマネージャ３８は、ＩＡＳ３５を介したＤＴＶエージェント３６、電子記憶装置２６及びＵＭＭ２７の相互のメッセージの送受信を行なう役割も担う。アバターエージェント３７の内部において、アバターマネージャ３８は、学習モジュール３９及び計画モジュール４１の各々とインタフェースする役割も担う。アバターエージェント３７は、視聴可能なプログラムをユーザに推薦するための推薦モジュール（不図示）を更に含んでも良い。
【００１９】
電子メール（Ｅメール）、ＦＡＸ及びボイスメールを含む幾つかの異なる方法で電子メッセージを送信することができる。ＵＭＭ２７は、単一のレセプタクルからこれらの電子メッセージに対するアクセスを可能にするモジュールである。ユーザは、ＤＴＶ１０を介して電子メッセージをアクセスしても良く、これらのメッセージを随時検索することができる。ＵＭＭ２７は、以下の特徴を有することが好ましい：
−Ｅメールの添付ファイルの処理、
−ボイスメールからＥメールへの変換：ＤＴＶスピーカ（不図示）により再生可能なデジタル音声ファイルとして到着したメッセージは、ＤＴＶ表示装置１１に表示したり、接続されたプリンタ（不図示）で印刷したり、他のユーザにＥメールで送信したり、外部ネットワーク４２に接続されたＦＡＸ装置（不図示）に転送したりすることができるテキスト形式に変換される、
−ＦＡＸからＥメールへの変換：元の形式のままで到着したＦＡＸも、ＤＴＶ表示装置１１に表示したり、接続されたプリンタで印刷したり、他のユーザにＥメールで送信したり、外部ネットワーク４２に接続されたＦＡＸ装置に転送したりすることができる、及び
−電子メールからボイスメールへの変換：電子メッセージはコンピュータ音声により読み上げられる。
【００２０】
ＵＭＭ２７は、ユーザがログオンしているか否か、或いは、ＤＴＶ１０のスイッチが切られているか否かにかかわらず、入力メッセージを受信し、アバターエージェント３７と連係してこれを処理する。例えば、検出されたメッセージは適切なデジタル形式（音声、画像、テキスト）で格納され、ユーザの要求に応じてアクセスされる。
【００２１】
電子記憶装置２６は、コンテンツの記録及び再生を行なうことができる。コンテンツは、通常、コンテンツサーバ４３から受信される。電子記憶装置２６は、ユーザからの通常の方法による要求に応じて記録を行なっても良い。更に、電子記憶装置２６は、ユーザが取り込み中の間、現在視聴中のプログラムのフラグメントを自動的に記録し、要求に応じてＤＴＶ表示装置１１上に小さいウィンドウを開いて再生しても良い。
【００２２】
電子記憶装置２６には、以下のような特徴が組み込まれる：
−基本機能の自動動作：再生、停止、早送り、巻戻し、
−副次的な機能の自動動作：一時停止、コマ送り再生（順方向及び逆方向）、スロー再生（順方向及び逆方向）、
−計画モジュール４１などの他のモジュールからの要求と現在の状態との矛盾の検出、及び
−所望のフラグメントの位置を捜し出すのに便利なように、エンドポインタによりフラグメントを記録するための自動検索／アクセス。
【００２３】
コンテンツサーバ４３は、通常、コンテンツプロバイダにより提供され、映画プログラム及びテレビプログラムなどのマルチメディアコンテンツを含む。利用可能なプログラムは、ＥＰＧデータベース２２に記載されている。各コンテンツプロバイダは、関連するＥＰＧデータベース２２を保持しても良い。ＥＰＧデータベース２２に記載された利用可能なプログラムは、プログラム識別子によりコンテンツサーバ４３中の対応するマルチメディアコンテンツにリンクされても良い。典型的なＥＰＧデータベース２２の抜粋を図２に示す。ＥＰＧデータベース２２は、複数のプログラムエントリ６０を有する。各々のプログラムエントリ６０は、値６２を伴う複数の属性６１を含む。属性６１には、以下のようなものが含まれる：
−エントリごとに一意的な数であるＥＰＧ識別子（ＩＤ）、
−プログラムごとに一意的であり、再放送の場合は同じプログラムＩＤを有するプログラムＩＤ、
−カテゴリＩＤ、例えば「０１」は芸術、「１６」はドラマ、「５０」は映画及びシリーズ物、「７５」はスポーツなど、
−サブカテゴリＩＤ、例えば映画カテゴリ「５０」において、サブカテゴリ「００１」はアクション物／冒険物、「０６４」はコメディー、「０７４」は犯罪物など、
−タイトル、
−このプログラムエントリに関する汎用のテキストフィールドである備考、
−キーワード、
−視聴率、
−ＥＰＧチャンネル、
−開始曜日、
−開始年月日、
−開始時刻、
−放送時間、及び
−製作年。
【００２４】
使用の際に、ユーザはリモコン３０を使用してＤＴＶ１０を「ＯＮ」にする。次に、ユーザはＤＴＶエージェントシステム２１に対して本人確認を行なわせることによりユーザＩＤを確立する。図３を参照して、これはＤＴＶエージェント３６により作成され、表示画面１１に表示された１組のキャラクターからアニメーションキャラクター１２を選択することによって行なわれても良い。選択は、リモコン３０を使用して行なわれる。
【００２５】
識別されたユーザに関連付けられたアバターエージェント３７のみを起動するメッセージが複数のアバターエージェント３７に向けて送信される。ユーザは、通常、リモコン３０を使用してＤＴＶ画面１１上に電子プログラムガイドを表示させ、視聴するプログラムを選択したり、ＵＭＭ２７からメッセージを読み出したり、或いは過去に電子記憶装置２６に記憶させたコンテンツを見ることを選択したりする。
【００２６】
ユーザがＤＴＶ画面１１上でコンテンツサーバ４３からのコンテンツを見ている最中に、そのユーザに対するメッセージがＵＭＭ２７により受信されることがよくある。アバターエージェント３７は通知されると、ＤＴＶ画面１１にアイコンを表示する。ユーザは、メッセージを見るか否か、見るとすればＤＴＶ画面１１上にどの程度の大きさで表示するかを決定する。
【００２７】
決定が行なわれる間のコンテキストなどのユーザ決定に関する情報及び実際のユーザ決定がＤＴＶエージェント３６によって収集され、アバターエージェント３７に引渡される。アバターエージェント３７は、視聴者事例データベース２４にこの情報を格納する。ユーザの決定は、指定されたコンテキストの中での特別のユーザの決定を表す各事例と共に、視聴者事例データベース２４に事例として格納される。
【００２８】
特定の実施形態では、２つの型の事例が識別される。以降、この型をＢＰ型（挙動パターン型）と呼ぶ。指定のＢＰ型及びユーザの全ての事例は、指定のＢＰ型及びユーザのユーザＩＤに関連付けられた事例ファイルに格納されるのが好ましい。特別のユーザを考慮し、事例ファイルのフィールドをより詳細に説明する。
【００２９】
第１の事例ファイルは、ＢＰ型０に対応し、これは、ＵＭＭコンテンツ表示に関連付けられる。この型の事例は、ユーザがコンテンツサーバ４３からのコンテンツを見ているときに、電子メール（Ｅメール）、ＦＡＸ又はボイスメールが到着した場合に起こる。ユーザは、通常、メッセージの性質又は現在視聴中のコンテンツの他にメッセージの優先度に基づいて決定を行なう。全てが数値を値とする第１の事例ファイルのフィールドは、以下の通りである：
0003768914.tif 000002
【００３０】
ユーザの決定は以下のようなものであろう：
・0     無視
・11    小さい補助ウィンドウを開く
・12    中位の補助ウィンドウを開く
・13    大きい補助ウィンドウを開く
・-10   中断なし。
【００３１】
第２の事例ファイルは、ＢＰ型１に対応し、これは、ハードディスクドライブ（ＨＤＤ）部分的コンテンツ再生に関連付けられる。この型の事例は、ユーザがコンテンツサーバ４３からのコンテンツを視聴しているときに起こり、ユーザがＵＭＭメッセージを読み込んでいる間に、ユーザの視聴が中断される。ユーザがメッセージウィンドウを閉じると、記録された部分を見るための選択肢が提供される。ユーザは、通常、現在視聴中のコンテンツの性質のみならず、電子記憶装置２６の録画したコンテンツの性質及びコンテンツの録画時間に基づいて決定を行なう。全てが数値を値とする第２の事例ファイルのフィールドは、以下の通りである：
0003768914.tif 000003
【００３２】
決定は、補助ウィンドウの大きさを特定の大きさに変更し、ＨＤＤコンテンツの記録されたフラグメントを再生するか否かに関するユーザの決定である。特に、ユーザの決定は以下のようなものである：
・0     無視
・11    小さい補助ウィンドウを開く
・12    中位の補助ウィンドウを開く
・13    大きい補助ウィンドウを開く
・-10   中断なし
これらの事例は、アバターエージェント３７、特に学習モジュール３９によって機能的な使用パターン及び依存関係を学習するために使用される。この機能的な使用パターン及び依存関係から、アバターエージェント３７の計画モジュール４１はＤＴＶエージェント３６、電子記憶装置２６及びＵＭＭ２７の活動を計画／調整する。
【００３３】
視聴者事例データベース２４に格納された各事例は、１組の特徴（fi）に関連付けられる。各特徴は固有の属性及び属性値の対を表す。各属性は複数の予想値を有する。属性−値の対の一例はDTV_Content_Category＝１６である。ここで、DTV_Content_Categoryが属性であり、「１６」が属性値である。
【００３４】
例えば、ＵＭＭコンテンツ表示（ＢＰ型＝０）の事例は、
DTV_Content_Category  ＝７５、
UMM_Content_Category  ＝３２、
UMM_Content_Priority  ＝５４、
Day                   ＝３、
Time_of_Day           ＝２、
Decision              ＝１２、
Frequency             ＝１、
であり、この事例はユーザがスポーツを視聴し、中位の優先度のＦＡＸが到着し、それが木曜の午後のことであり、ユーザは、中位の補助ウィンドウを開くことを決定したという意味に解釈される。事例に対する頻度は常に１である。
【００３５】
学習モジュール３９は、複数の事例から全ての一般化パターンを識別するように動作する。一般化パターンは、事例内の共有パターンを表す。学習モジュール３９は、事例ファイルを入力として用いて、全ての一般化パターンを含む一般化パターンリスト（GPList）を生成する。GPListの各一般化パターンは以下のように表しても良い：
（[共通部分]，出現）、
ここで、共通部分は複数の異なる事例が共有するパターンを示し、出現はこのような共通部分を共有する事例の数を示す。例えば、以下の事例：
C1 = (f1, f2, f3, f4, f7)、
C2 = (f1, f2, f5, f6, f7)、及び
C3 = (f3, f5, f6, f8)では、
生成されたGPListは以下の３つの項目を有する：
([f1, f2, f7], 2)、
([f3], 2)、及び
([f5, f6], 2)。
【００３６】
第１のGPListのエントリは、事例Ｃ１及びＣ２の双方において出現する属性及び属性値の対ｆ１、ｆ２及びｆ７から得られる。その他のエントリも同様にして導き出される。
【００３７】
例えば、事例ファイルは図９Ａ及び９Ｂに示す事例を含むものとする。これらの事例から学習モジュール３９によりGPListが生成される。
【００３８】
学習モジュール３９は、更に挙動パターンを識別するために、GPListの一般化パターンのうちの適切なものを選択する。各GPListのエントリが調べられ、少なくとも１つの別の指定値と共に、「Decision」フィールドに値を有するか否かが判定される。「Decision」フィールドに値を有すると判定される場合、GPListのエントリは挙動パターンと見なされ、BPListのエントリとして入力される。従って、BPListはＤＴＶの一機能（ＢＰ型によりカプセル化）、即ち、ＵＭＭコンテンツ表示及びＨＤＤ部分的コンテンツ再生に対して、ユーザの挙動のパターンをカプセル化する。
【００３９】
上述の例において、学習モジュール３９により生成されたBPListは、図１０Ａから図１０Ｃに示すエントリを含む。エントリ７０は、ユーザがスポーツ（DTV_Content_Category＝７５）を見ている最中に「小さい補助ウィンドウを開く」（Decision＝１１）の決定を下した場合の事例が、１６個あったことを示す。その他の属性及び属性値の対は様々であるので値−１で表される。これは「不問」と解釈されるであろう。１６個の事例は、図９Ａ及び９Ｂにおいて７１ａから７１ｐで示される。
【００４０】
計画モジュール４１の機能は、過去のユーザ挙動パターンを考慮してどの決定が最も適切であるかを決定のコンテキストに基づいて見出すことである。通常、過去の事例は、現在の状態には部分的にしか適合しない。これにより、どの決定が最も適切であるかを判定する際に不確実性が生じる。あるパターンでは、ユーザが「小さい補助ウィンドウを開く」決定を選択するように見え、別のパターンでは「中位の補助ウィンドウ」の決定が好まれるように見える。あるパターンによっては、「確認を求める」ことが望ましいことを示すであろう。
【００４１】
ＵＭＭコンテンツ表示（ＢＰ型＝０）及びＨＤＤ部分的コンテンツ再生（ＢＰ型＝１）に対して計画モジュール４１により決定するための決定空間を考慮する。決定は、ユーザ決定と一致する。「無視」の決定は、「確認を求める」と解釈されても良く、適切に決定できないときに計画モジュール４１により使用される。これは、典型的には、特定のコンテキストにおけるユーザ決定のパターンが不十分である場合である。従って、決定及びその決定値は、以下のようであっても良い：
・0     無視
・11    小さい補助ウィンドウを開く
・12    中位の補助ウィンドウを開く
・13    大きい補助ウィンドウを開く
・-10   中断なし
BPListにおけるパターンの一部として格納された過去の決定頻度は、決定空間の粒度が原因で相対的な表示でしかない。例えば、類似性が、BPListエントリと現在のコンテキストのエントリとの間で一致する属性及び属性値の対の数により判定される場合での同様の状況間で集積された以下の決定の頻度を考慮する：
・無視                        ７
・小さい補助ウィンドウを開く  ４
・中位の補助ウィンドウを開く  ６
・大きい補助ウィンドウを開く  ２
・小さい補助ウィンドウを開く  ２
この例では、「無視」の決定が最高の頻度である。しかし、全体として、ユーザは何らかのウィンドウ（小、中又は大）を１４回選択している。これは、この状況下でウィンドウがより良い選択肢であることを示す。計画モジュール４１は、実際に、これがより良い決定であることを判定すると共に、どのウィンドウがより良い決定であるかを判定することを意図する。
【００４２】
規則ベースの意思決定プロセスは、意思決定が複数の規則へと分割され、決定樹がアプリケーションプログラム中にハードコード化されることを必要とする。例えば、ある規則は、全ての「ウィンドウを開く」決定に対する頻度の合計が「無視」決定の頻度よりも大きい場合、「ウィンドウを開く」決定のみを考慮すると規定する。別の規則は、「ウィンドウを開く」決定のみが考慮される場合、「ウィンドウを開く」決定の中で最も頻度の高い決定を選択すると規定する。
【００４３】
この手法の最も明確な問題点は、新規の決定の型が導入される場合に、特定の決定樹に対するアルゴリズムを再プログラミング／再コンパイルする必要が生じることである。
【００４４】
好適な実施形態では、決定空間に対する数値離散領域（ＮＤＤ）が使用される。これは以下のものを必要とする：
・決定の型（ウィンドウ関連の決定など）がＮＤＤ区間により表される。各区間は右側に開いており、粒度は小数点以下の何桁までが重要であるのかを表す
・同様の決定（ウィンドウ関連の決定など）が、同じ数値区間からより近い数値に割り当てられる
有限数の決定要素（ウィンドウの大きさ、音量など）が、有限数のＮＤＤ区間に提供される。
【００４５】
例えば、以下に示すような決定値の場合を考慮する：
・0     無視
・11    小さい補助ウィンドウを開く
・12    中位の補助ウィンドウを開く
・13    大きい補助ウィンドウを開く
・-10   中断なし
ここにＮＤＤ区間により表された３つの決定の型を示す：
[-10,0[（中断なし）、
[0,10[（無視）、及び
[10,20[（ウィンドウ関連の決定）。
【００４６】
表記[α,β[は、α≦値＜β、即ち、αを含むがβを含まない場合の値の範囲を示す。全てのウィンドウ関連の決定は、非常に近い値（１０、１１及び１２）を有し、「無視」の決定は、離れた値０を有する。
【００４７】
図４に、それまでのユーザの挙動パターン及び決定のコンテキストを考慮してどの決定が最も適切であるかを判定する方法５００の流れ図を示す。図４の方法は、従来の汎用コンピュータシステム１００（図８）を使用して実施されても良い。このシステムでは、図４のプロセスはコンピュータシステム１００内で実行するアプリケーションプログラムなどのソフトウェアとして実現される。特に、ステップはコンピュータにより実行されるソフトウェア中の命令である。ソフトウェアはコンピュータ読み取り可能な媒体に記憶されても良い。ソフトウェアはそのコンピュータ読み取り可能な媒体からコンピュータにロードされて実行される。このようなソフトウェア又はコンピュータプログラムを記録したコンピュータ読み取り可能な媒体はコンピュータプログラム製品である。方法５００に入力されるのが、学習モジュール３９により作成されたBPListからのユーザ挙動パターン、現在の属性及び属性値の対により表される決定のコンテキスト、及び定義済のＮＤＤである。
【００４８】
方法５００は、ステップ５０２で開始し、ステップ５０４で入力を受け取る。ステップ５０６において、現在の属性及び属性値の対をBPListのレコードの各々と比較し、パターンレコードごとの一致する属性及び属性値の対の数を判定する。
【００４９】
ステップ５０８において、BPListからコンテキスト化されたレコードのリスト（c-list）を作成する。このリストでは、一致しない属性値は値「−１」に置き換えられ、一致する属性及び属性値の対の数が各エントリに対する重み付けパラメータとして加えられる。そのc-listのレコードは、ステップ５１０において、各重み付けパラメータに従って降順に整列される。
【００５０】
ステップ５１２において、c-listのレコード群からなるｎ個のクラスタを構成する。各クラスタ内の全てのエントリは、同じ重み付けパラメータを有するので、同数の一致する属性及び属性値の対を有する。ステップ５１４において、各クラスタ内で、ｍ個のサブクラスタのレコード群を構成する。各クラスタは、同じ正の関連する属性及び属性値の対を有する。
【００５１】
図１１Ａに、不図示のBPListから作成されたc-listの例を示す。このc-listの例は、５つの属性、即ち、ＤＴＶコンテンツカテゴリ、ＵＭＭコンテンツカテゴリ、ＵＭＭコンテンツ優先度、日及び曜日を含む。各エントリの下には、属性値が示される。各エントリに対応する決定値及びその出現頻度も示される。この例での決定値の意味は、以下の通りである：
・0   無視
・11  小さい補助ウィンドウを開く
・12  中位の補助ウィンドウを開く
・13  大きい補助ウィンドウを開く
この例に対するＮＤＤ区間は、以下のように示される：
[-10,0[、
[0,10[、及び
[10,20[。
【００５２】
この例では、ステップ５１２において２つのクラスタが構成された。クラスタ１のエントリは、各々が４つの一致する属性及び属性値の対を有するので、重み付けパラメータは４である。同様に、クラスタ２のエントリの重み付けパラメータは３である。クラスタ１は、５つのサブクラスタを有し、各サブクラスタは、同じ正の関連する属性及び属性値の対を有する。クラスタ２は、このようなサブクラスタは２つしかない。
【００５３】
図４に戻ると、ステップ５１６において、空の決定リストＸを作成する。このリストＸは、単に後述する最頻の決定ｄjkを保持するための一時的なデータ構造である。ステップ５１８において、変数ｊを０に等しく設定する。これにより、初期化を終了する。
【００５４】
ステップ５１９において、変数ｊを増分する。クラスタｊ（1 ≦ j ≦ n）内で、ステップ５２０において、サブクラスタｋ（1 ≦ k ≦ m）ごとに最頻の決定ｄjkを頻度に基づいて検索する。再度図１１Ａを参照すると、各クラスタ内での頻度に基づく最頻の決定ｄjkも示されている。
【００５５】
次に、クラスタｊ内での全ての最頻の決定ｄjkがステップ５２２（図４）において平均される。クラスタ１内の最頻の決定ｄ11、ｄ12、ｄ13、ｄ14及びｄ15の平均は、９．４である。
【００５６】
ステップ５２４において、寄与する区間のうちのどのＮＤＤ区間が左の境界値の観点から見てステップ５２２で計算された平均に最も近いかを見出す。この例では、左の境界値の観点から見て平均値９．４に最も近い寄与ＮＤＤ区間は、ＮＤＤ区間[10,20[である。それは、９．４が左の境界値である１０に最も近いからである。
【００５７】
ステップ５２６において、最も近いＮＤＤ区間中の値を伴う全ての最頻の決定ｄjkの中から、サブクラスタ間で最頻の決定を頻度に基づいて選択する。この例では、最頻の決定ｄ12、ｄ13、ｄ14及びｄ15は、区間[10,20[の範囲内であり、頻度６の決定ｄ13が最も頻度が高い。最頻の決定ｄ13は、決定１２（中位の補助ウィンドウを開く）に関連する。
【００５８】
しかし、最も近いＮＤＤ区間が、異なる数の決定要素を有する決定の型を含むとき（例えば、最も近いＮＤＤ区間が「ウィンドウ関連」並びに「音量関連」の双方を有する決定の型、及び、後述するように「ウィンドウ関連」の決定のみを有する決定の型を含むとき）、より多くの数の決定要素を有する決定が選択される。言い換えると、最も近いＮＤＤ区間が、異なる粒度の決定値を有する決定を含むとき、より粒度の高い（即ち、より特殊な）決定が選択される。
【００５９】
再度、図４を参照すると、選択が可能であったので、ステップ５２８において、方法５００はステップ５６０に進み、この決定が戻される。
【００６０】
ステップ５２８において、このような選択が可能であったか否かを判定する。２つ以上の決定が最高の頻度を有するならば、ステップ５２６では、このような選択が妨げられる可能性がある。
【００６１】
図１１Ｂは、図１１Ａに示すのと同様のc-listの別の例を示すが、決定値及び頻度は異なっている。
【００６２】
ステップ５２２で計算されたクラスタ１内の最頻の決定ｄ11、ｄ12、ｄ13、ｄ14及びｄ15の平均は、６．８である。寄与区間のうちの、左の境界値の観点から最も平均値６．８に近いＮＤＤ区間は、区間[10,20[であるが、これは、６．８が左の境界値１０に最も近いからである。
【００６３】
最頻の決定ｄ11、ｄ12及びｄ14は、区間[10,20[の範囲内である。しかし、頻度７の決定ｄ11及びｄ14の双方が、決定値の中で最も頻度が高い。選択は、この２つの決定ｄ11及びｄ14間で行なうことはできないが、それは、双方の頻度が同一値だからである。
【００６４】
再度図４を参照すると、ステップ５２８において、選択が可能であったと判定される場合、方法５００はステップ５６０において選択を戻し、ステップ５６１で終了する。選択が可能であったと判定されない場合、方法５００は、ステップ５３０へと続き、ここで、同一値の決定のうちの何れかが決定リストＸにおける出現回数の観点においてリストＸのエントリとより一致するか否かを判定する。同一値の決定のうちの１つが決定リストＸのエントリとより一致する場合、その決定が選択され、方法５００はその選択をステップ５６０において戻す。決定リストＸのエントリとより一致しない場合、それぞれ対応する頻度を伴ったクラスタｊからの全ての最頻の決定ｄjkがステップ５３２において決定リストＸに加えられる。方法５００は、ステップ５３３において全てのクラスタの考慮が終了していないと判定される場合、ステップ５１９に戻る。
【００６５】
図１１Ｂの例に戻ると、決定ｄ11及びｄ14は同一値であるので、ステップ５２８において、選択が可能でなかったと判定され、方法５００はステップ５３０へと続く。ここで、同一値の決定ｄ11及びｄ14の何れかが決定リストＸにおける出現回数の観点においてリストＸのエントリとより一致するか否かを判定する。リストＸは依然として空であるので、同一値の決定ｄ11及びｄ14の何れも決定リストＸのエントリとより一致しない。ステップ５３２において、クラスタ１からの全ての最頻の決定ｄjkをＸリストに加えると、リストは、｛11, 11, 0, 12, 0｝を含むようになる。
【００６６】
より多くのクラスタが残るので、方法５００はステップ５１９に戻り、ｊは２に増分される。最頻の決定ｄ21及びｄ22は、ステップ５２０において１１及び１３であると判定され、ステップ５２２において、平均が１２であると判定される。寄与区間のうちの、左の境界値の観点から平均値１２に最も近いＮＤＤ区間は、またもＮＤＤ区間[10,20[である。
【００６７】
最頻の決定ｄ21及びｄ22の双方は、区間[10,20[の範囲内にあるが、これもまた同一値である。決定ｄ11及びｄ14は同一値であるので、ステップ５２８において、選択が不可能であると判定され、ステップ５３０において、同一値の決定ｄ21及びｄ22の何れかが｛11, 11, 0, 12, 0｝を含む決定リストＸのエントリとより一致するか否かが判定される。決定ｄ21は、決定値１１に関連し、リストＸ中に２回出現する。これに対し、決定ｄ22は、決定値１３に関連し、リストＸ中には出現しない。従って、決定１１が選択される。
【００６８】
全てのクラスタを処理した後、選択が行なわれていない場合、ステップ５３４において、リストＸ上の全ての決定を平均する。ステップ５３６において、寄与区間のうちのどのＮＤＤ区間が左の境界値の観点からステップ５３４で計算された平均値に最も近いかを見出す。最も近いＮＤＤ区間中の値を伴うリストＸ中の決定の中から、ステップ５３８において、最も頻度の高い決定を頻度に基づいて選択する。ステップ５４０において、このような選択が可能であったか否かを判定し、可能であった場合、方法５００はステップ５６０においてこの選択を戻す。可能でなかった場合、決定＝０（無視）がステップ５５０において戻される。
【００６９】
「ウィンドウ関連」及び「音量関連」の決定の双方を有する別の例を考慮する。決定値は、以下のように割り当てられる：
・0     無視
・11    小さい補助ウィンドウを開く
・11.1  小さい補助ウィンドウを開き、音量を下げる
・11.2  小さい補助ウィンドウを開き、音を消す
・12    中位の補助ウィンドウを開く
・12.1  中位の補助ウィンドウを開き、音量を下げる
・12.2  中位の補助ウィンドウを開き、音を消す
・13    大きい補助ウィンドウを開く
・13.1  大きい補助ウィンドウを開き、音量を下げる
・13.2  大きい補助ウィンドウを開き、音を消す
・21    フルスクリーンの補助ウィンドウを開く
・21.1  フルスクリーンの補助ウィンドウを開き、音量を下げる
・21.2  フルスクリーンの補助ウィンドウを開き、音を消す
・-10   中断なし。
【００７０】
以上から、補助ウィンドウの決定の型は類似していると見なされ、同じ大きさの補助ウィンドウで音量が様々である場合は、非常に類似していると見なされて一層近い数値が割り当てられることが明らかである。
【００７１】
ＮＤＤ区間は、以下の通りである：
[-10,0[、
[0,10[、
[11,12[、
[12,13[、
[13,14[、及び
[21,22[。
【００７２】
同じクラスタ内の各サブクラスタから、以下の最頻の決定ｄjkを考慮すると、その解釈及び頻度は以下の通りである：
・0     無視                                    ７  （サブクラスタ１）
・11.1  小さい補助ウィンドウを開き音量を下げる  ４  （サブクラスタ２）
・12    中位の補助ウィンドウを開く              ６  （サブクラスタ３）
・13.2  大きい補助ウィンドウを開き、音を消す    ２  （サブクラスタ４）
・21    フルスクリーンのウィンドウを開く        ２  （サブクラスタ５）
ステップ５２２において再度開始すると、このクラスタ内の全ての最頻の決定ｄjkは平均され、平均値１１．４６が求められる。ステップ５２４において、寄与区間のうちのどのＮＤＤ区間が左の境界値の観点から平均値１１．４６に最も近いかを見出す。最も近い寄与区間は、区間[11,12[である。ステップ５２６において、区間[11,12[内で最頻の決定を選択する。この区間には１つの決定、即ち、決定１１．１（小さい補助ウィンドウを開き音量を下げる）しかない。選択が可能であったので、ステップ５２８において、方法５００はステップ５６０に進み、ここで、この決定が戻される。
【００７３】
更に、同じクラスタ内の各サブクラスタから、以下の最頻の決定ｄjkを考慮すると、その解釈及び頻度は以下の通りである：
・0     確認を求める                            ７  （サブクラスタ１）
・11    小さい補助ウィンドウを開く              ６  （サブクラスタ２）
・11.1  小さい補助ウィンドウを開き音量を下げる  ４  （サブクラスタ３）
・13.2  大きい補助ウィンドウを開き音を消す      ２  （サブクラスタ４）
・21    フルスクリーンのウィンドウを開く        ２  （サブクラスタ５）
ステップ５２２において再度開始すると、このクラスタ内の全ての最頻の決定ｄjkは平均され、平均値１１．２６が求められる。ステップ５２４において、寄与区間のうちのどのＮＤＤ区間が左の境界値の観点から平均値１１．２６に最も近いかを見出す。最も近い寄与区間は、区間[11,12[である。ステップ５２６において、区間[11,12[内で最頻の決定を選択する。この区間には２つの決定、即ち、決定１１（小さい補助ウィンドウを開く）及び決定１１．１（小さい補助ウィンドウを開き音量を下げる）があり、結果として、「小さい補助ウィンドウを開き音量を下げる」決定が選択される。尚、この決定は、頻度が低いにもかかわらず、「小さい補助ウィンドウを開き音量を下げる」決定の方が選ばれている。この方がより特殊であるからである。
【００７４】
選択が可能となったので、ステップ５２８において、方法５００はステップ５６０に進み、ここで、この決定が戻される。
【００７５】
計画モジュール４１内部の動作を一例として更に説明する。ユーザは、ＤＴＶでサッカーの試合を観戦する。木曜日の午後である。このユーザ宛ての高優先度の電子メールメッセージが到着し、以下の変数を設定する：
UMM.Status = NewMessage、
UMM_Content_Category = 56（電子メール）、及び
UMM_Content_Priority = 99（高優先度）。
【００７６】
ＵＭＭ２７は、定期的に（ｋ分ごと）変数UMM.Statusをチェックすることにより、この新規のメッセージの到着を認識する。変数UMM.Statusは、値「NewMessage」を有するので、ＵＭＭ２７は対応するユーザのアバターエージェント３７に変数UMM_Content_Category及びUMM_Content_Priorityの値を通知する。
【００７７】
計画モジュール４１は、上述の方法５００を使用することにより、過去のユーザ挙動パターン及び決定のコンテキストを考慮してどの決定が最も適切であるかを判定する。計画モジュール４１は、ＢＰ型０と一致する事例ファイルから学習モジュール３９により生成されたBPList、定義済のＮＤＤ、及び、ＤＴＶエージェント３６からの要求コンテキスト情報を読み出す。その後、応答を待つ。ＤＴＶエージェント３６は、以下の変数を伴って応答する：
DTV.Status = ON、
DTV_Content_Category = 75（スポーツ）、
Day = 2(火曜日)、及び
Time_of_Day = 2（午後）。
【００７８】
決定がユーザの中断なしであれば、更なる処置はとらない。決定が「無視」であれば、アバターエージェント３７はＤＴＶエージェント３６に対してユーザの説明を取得するように要求し、ユーザの応答を待つ。ＤＴＶエージェント３６がユーザの確認を受信すると、アバターエージェント３７に対してユーザの決定を通知する。
【００７９】
決定が補助ウィンドウの型の決定のうちの１つであるならば、計画モジュール４１は、ＤＴＶエージェント３６に対して補助ウィンドウを配置してＵＭＭコンテンツを表示するように要求する。これは直接的なアクションである。また計画モジュール４１は、電子記憶装置２６に対して現在のＤＴＶコンテンツ、即ち、サッカーの試合の録画を開始するように要求する。これは分岐である。
【００８０】
ＤＴＶエージェント３６は、サッカーの試合のウィンドウのサイズを変更し、Ｅメールのウィンドウを開く。
【００８１】
アバターエージェント３７がＤＴＶエージェント３６からユーザの確認を受信すると、新規の事例が作成される。また、計画モジュール４１による決定に基づいてアクションがとられる場合、即ち、自動的に補助ウィンドウを開く場合であり、且つこの決定がウィンドウを即座に閉じることによってユーザにより上書きされない場合、新規の事例がこの決定と共に作成される。学習モジュール３９は、新規に作成された事例を含む事例群から新規のGPListを学習し、新規のBPListを作成するように通知される。
【００８２】
しばらくして、ユーザは、Ｅメールのメッセージを読み終え、Ｅメールのオプションを閉じることを選択する。ＤＴＶエージェント３６は、電子記憶装置２６に対して記録を停止するように通知する。
【００８３】
計画モジュール４１は、続いて、上述の方法５００を使用して過去のユーザ挙動パターン及び決定のコンテキストを考慮して録画したフラグメントを表示するのにどの決定が最も適切であるかを判定する。計画モジュール４１は、ＢＰ型１と一致する事例ファイルから学習モジュール３９により生成されたBPList、定義済のＮＤＤ、及び、ＤＴＶエージェント３６からの要求コンテキスト情報を読み出す。この例において、コンテキストは、以下の通りである：
DTV_Content_Category = 75、
HDD_Content_Category = 75、
Duration = 34(３分以下の短時間の録画)、
Day = 2、及び
Time_of_Day = 2。
【００８４】
決定がユーザの中断なしであれば、更なる処置はとらない。決定が「無視」であれば、アバターエージェント３７は、ＤＴＶエージェント３６に対してユーザの説明を取得するように要求し、ユーザの応答を待つ。ＤＴＶエージェント３６がユーザの確認を受信すると、アバターエージェント３７に対してユーザの決定を通知する。
【００８５】
決定が補助ウィンドウの型の決定のうちの１つであるならば、計画モジュール４１は、ＤＴＶエージェント３６に対して補助ウィンドウを配置してＵＭＭコンテンツを表示するように要求する。
【００８６】
ＤＴＶエージェント３６は、この例ではサッカーの試合のままである、現在のＤＴＶコンテンツの大きさを変更し、レコーダーフラグメントが表示される補助ウィンドウを開く。
【００８７】
アバターエージェント３７がＤＴＶエージェント３６からユーザの確認を受信すると、新規の事例が作成される。また、計画モジュール４１による決定に基づいてアクションがとられ、この決定がウィンドウを即座に閉じることによってユーザにより上書きされない場合、新規の事例がこの決定と共に作成される。学習モジュール３９は、新規のGPListを学習し、新規のBPListを作成するように通知される。
【００８８】
上述の例で説明したようなシステム５０において実行される様々なタスクは、以下に示すように分類される：
・定期型−指定の間隔で反復的に実行される、即ち、実行時に周期に従って後続の再実行の予定が組まれるもの。ＵＭＭ２７が変数UMM.Statusをｋ分ごとにチェックするために実行するタスクなど、
・トリガ式−ＵＭＭ２７からメッセージの到着の通知を受信したときにＤＴＶエージェント３６により実行されるタスクなどの外部のイベントに応じて（時には反復的に）実行されるもの。この通知は、変数UMM_Content_Category及びUMM_Content_Priorityの値も含む、及び
・知識生成型−現在のコンテキストについての情報を含むメッセージをＤＴＶエージェント３６から受信したときにＤＴＶエージェント３６により実行されるタスクなどの感知又は情報収集のために実行されるもの。このタスクは、過去のユーザ挙動パターン及び決定のコンテキストを考慮して最も適切な決定を判断する。
【００８９】
これらのカテゴリは、相互に排他的ではない。例えば、知識生成型のタスクは、外部のイベントに応じてトリガされても良い。
【００９０】
より好適な実施形態では、これらのタスクは、タスクネットワークにより実現される。タスクネットワークにおける全てのタスクは、他のタスク（サブタスク）をトリガする、又は、これらのタスクにメッセージを送信する、或いは、その双方によって情報の流れを柔軟に制御することができる。コンテキスト的なタスクネットワークにおける制御の流れは、特定の状態、コンテキスト的なユーザ挙動パターン、及び、機能的な依存関係に応じて各タスクにより生成された計画（小計画）により導き出される。ユーザの挙動パターンが学習モジュール３９により更新される場合、制御の流れは動的に変化するであろう。
【００９１】
図５において、タスクＴkはそのＩＤであるｉk、呼出しの型（トリガ又はメッセージ）ｔk、条件付きの計画（小計画）ｐk、及び、タスク（サブタスク）ｍkのマップにより表される。タスクＴkがトリガにより呼び出されると、入力データの読出し及び解釈を行い、計画（小計画）ｐkを起動し、これを実行する。タスクＴkは、メッセージと共に呼び出されると、入力データの読出し及び解釈のみを行なう。計画（小計画）ｐkは、計画ノードｐkjのベクタとして表される。計画（小計画）ｐkを起動すると、計画ノードｐkjのシーケンスが構成される。各ノードｐkjは、マップｍkjにより表される別のタスク（サブタスク）ｉjにマッピングされる。言い換えると、各計画ノードは、その時点でどのタスク（サブタスク）をどのように（トリガによって又はメッセージと共に）呼び出すべきかを判定する。
【００９２】
図６は、タスクネットワーク６００上で、このプロセスを例証する図である。この例において、タスクＴ5は、タスク（サブタスク）Ｔ6及びタスク（サブタスク）Ｔ8のいずれかへの制御の流れと、タスク（サブタスク）Ｔ7への情報の流れを伴う条件付き計画（小計画）を有する。
【００９３】
時には、タスク（サブタスク）Ｔiをトリガする又はこれに情報を渡すために、計画ノードは、図４を参照して説明したようなコンテキスト的なユーザプリファレンスを判定する必要がある。例えば、タスクＴ9は、このようなコンテキスト化を行なう役割を担うタスク（サブタスク）ともなり得る。タスクＴ6がタスク（サブタスク）Ｔ8をトリガできるようになる前に、最新のユーザ挙動パターンが分析されるべきであるので、タスク（サブタスク）Ｔ9がまずトリガされる。
【００９４】
タスクＴ7が学習モジュール３９で実行される学習アルゴリズムを使用して、メッセージｉ7がタスクＴ8から受信されたときに、ユーザ挙動パターンBPListを更新するものと想定する。このユーザ挙動パターンは動的に変化し、タスクＴ9及びＴ8が次にトリガされるときには異なるものとなっている。従って、Ｔ9からＴ8へのメッセージは、新規のコンテキストを考慮して動的に変化する可能性がある。
【００９５】
通常、コンテキスト的なタスクネットワークのリンクの部分集合が起動されるときに、特定のシナリオが展開される。ＤＴＶシステム５０の現在の状態及び現在のユーザ挙動パターンを考慮して、計画モジュール４１により軌道が計画され、シナリオは実行中に進展する。言い換えると、ネットワークにおけるタスクの流れの全ての可能な組み合わせが、種々の予想シナリオを包含する。
【００９６】
しかし、コンテキスト的であるか否かにかかわらず、いずれのタスクネットワークでも、全ての予想軌道が予め規定される。従って、タスクネットワークによりサポートされる予想シナリオの数には制限がある。この数は、タスクネットワークの組み合わせの性質を考慮すれば、十分に意義のあるものであるが、コンテキスト的なタスクネットワークの柔軟性を制限する。
【００９７】
このコンテキスト的なタスクネットワークの柔軟性は、タスクネットワークに対するシナリオ独立型テンプレート（ＳＩＴ−ＴＮ）の導入により改善される。この特徴により、システム設計者は、他のモジュール及び／又はタスクに影響を及ぼすことなく、容易に新規のシナリオを作成することができる。
【００９８】
上述のように、タスクネットワークは、全ての予想軌道を予め規定し、可能なシナリオの数を制限する。従って、新規のシナリオを導入する必要がある場合、タスクネットワークは更新され、再プログラミング／再コンパイルされなければならない。
【００９９】
好適な実施例では、ＳＩＴ−ＴＮは、以下に示すように構成される：
【０１００】
【表１】
0003768914.tif 000004
ここで、Task Name及びTask Linkは、タスクＩＤに相当する。Task Nameは、現在のタスクであり、Task Linkは、呼出し可能なサブタスクである。Conditionは、呼出しに際しての必要条件を獲得する論理式であり、Link Typeは、現在のタスクとサブタスクとの間の呼出しの型（TRIGGER又はMESSAGE）であり、Argumentsは、サブタスクに渡されるパラメータ一式である。
【０１０１】
例えば、タスク名がOnHDDResponseであり、計画モジュール４１により実行される例示のタスクを考慮する。このタスクは、HDD_Content_Categoryの値を求める計画モジュール４１からのそれ以前の要求に対して、電子記憶装置２６がこの情報を伴って応答するときにトリガされる。このタスクのコードは、以下のように示される：
0003768914.tif 000005
従って、タスクOnHDDResponseは、変数の応答、即ち、HDD_Content_Categoryを含む応答によりトリガされる。有効なHDD_Content_Categoryが受信された場合、値は正である。変数subjectはＢＰ型に従って設定される。電子記憶装置２６に記憶されたコンテンツのフラグメントの場合にはＢＰ型は１であるので、変数subjectには、値HDDPartialContentPlayBackが与えられる。それに続く３コードラインにおいて、現在のコンテキストの全ての変数を含むsubject_listが用意される。これらの変数は、適切な決定を判定するために別のタスクによって使用される。最後に、ＤＴＶエージェント３６のタスクOnContentQueryに対して通知が送信され、このタスクに対するトリガとして作用し、変数sourceの値をタスクに渡す。
【０１０２】
変数subject及びsubject_listを設定することにより、最も適切な決定を判定するタスクOnDTVContentResponseにとって情報が利用可能なものとなる。タスクネットワーク環境においては、これはメッセージである。
【０１０３】
これに対し、受信された応答が０に等しい場合、HDD_Content_Categoryは有効ではないので、タスクはユーザの挙動パターンを監視する処理に進む。
【０１０４】
同じタスクは、ＳＩＴ−ＴＮにおいて以下のように記述しても良い：
【０１０５】
【表２】
0003768914.tif 000006
この表は以下のように解釈しても良い：
タスクOnHDDRResponseにおいて、条件response＞0が受信されるとき、トリガがＤＴＶエージェント３６のタスクOnContentQueryに送信され、引数source = avatarが渡される。また、メッセージがタスクOnDTVContentResponseに送信され、変数subject及びsubject_listの値が渡される。
【０１０６】
しかし、条件response = 0が受信される場合、変数monitoringの値を含むメッセージが、タスクMatchEPGUserProfileに送信されると共に、タスクOnRecordedRecommendationRequestにもrecorded_epg_idの値を含むメッセージが送信される。
【０１０７】
通常、ＳＩＴ−ＩＮ表現には、同じTask Nameを有するレコードが少数存在し、各レコードは計画ノードに対応してそれぞれ特定のリンクを指定する。例示のタスクOnHDDResponseは、４つのリンクを有する。
【０１０８】
学習モジュール３９の動作をより詳細に説明する。図７Ａから７Ｆに関連して説明される学習モジュール３９により実行されるプロセスは、従来の汎用のコンピュータシステム１００（図８）を使用して実施されても良い。このコンピュータシステム１００では、プロセスは、内部で実行するアプリケーションプログラムなどのソフトウェアとして実現される。
【０１０９】
学習モジュール３９のコア関数を実行するためのプロシージャLEARNを図７Ａに示す。このプロシージャでは、４つのデータ構造、即ち、複数の事例（Ｃj）を含む事例ファイル、全ての一般化パターンを保有するGPList、全ての挙動パターンを保有するBPList、及び、既に処理が終わった事例を含む検査済事例リストが使用される。まず、プロシージャLEARNの初期化に際して、LEARN、GPList、BPList、及び、検査済事例リストは空になる。
【０１１０】
プロシージャLEARNは、ステップ２００において開始し、まずステップ２０１において指定のＢＰ型に基づいて新規の事例のリストを取得し、ステップ２０２において、視聴者事例データベース２４からＢＰ型の事例ファイルを取得する。ステップ２０３において、新規の事例を加えることにより事例ファイルを更新する。
【０１１１】
事例ファイルの各事例の現在のGPListとの共通部分が、残るステップ２０４から２１１において取得される。ステップ２０４において、事例ファイルから第１のエントリが取り出され、ステップ２０５において、サブルーチンGEN-INSTANCE-GPLISTを呼び出すときの入力事例として使用される。サブルーチンGEN-INSTANCE-GPLISTは、入力事例とGPListの各項目との間の一般化パターンを見出し、図７Ｂのステップ２２０において開始する。ステップ２０６において、入力事例と検査済事例リストの各事例との間の一般化パターンを見出すために、サブルーチンGEN-INSTANCE-EXAMINED-INSTANCESが呼び出される。サブルーチンGEN-INSTANCE-EXAMINED-INSTANCESは、図７Ｅのステップ３１０において開始する。ステップ２０７において、入力事例は検査済事例リストに加えられる。従って、事例（Ｃj）は、事例ファイルが空になるまで、事例ファイルから検査済事例リストへと徐々に移動される。ステップ２０８において、事例ファイルが更にエントリを有するか否かを判定する。事例ファイルにエントリが残っている場合、プロシージャLEARNは、ステップ２０９に進む。ここで、事例ファイルからの次のエントリが入力事例として使用され、プロシージャLEARNは続けてステップ２０５に進む。
【０１１２】
ステップ２０８において、事例ファイルが空であると判定された後、ステップ２１０において、GPListの一般化パターンをフィルタリングし、部分集合を作成する。各GPListのエントリが調べられ、少なくとも１つの別の指定値と共に、「Decision」フィールドの値を有するか否かが判定される。「Decision」フィールドの値を有すると判定される場合、各GPListのエントリは、挙動パターンと見なされ、BPListのエントリとして入力される。BPListは、挙動パターンであり、ステップ２１１において出力として生成される。プロシージャLEARNは、ステップ２１２において終了する。
【０１１３】
図７Ｂにおいて、サブルーチンGEN-INSTANCE-GPLISTは、入力事例とGPListの全ての項目との間の全ての一般化パターンを見出すためのものである。このサブルーチンは、更に入力事例と現在のGPListとの間の全ての新規の一般化パターンを伴ってGPListを更新する。
【０１１４】
GEN-INSTANCE-GPLISTは、ステップ２２０において開始し、ステップ２２１において、入力事例及び現在のGPListを入力として受け取る。ステップ２２２において、現在のGPListが空のままであるか否かを判定する。現在のGPListが空の場合、入力事例とGPListとの間の一般化パターンは存在せず、サブルーチンはステップ２３６においてリターンする。
【０１１５】
GPListに項目がある場合、サブルーチンはステップ２２３へと続く。ここで、入力事例とGPListの全ての項目との間の全ての一般化パターンは、サブルーチンG_List_GENを呼ぶことにより見出される。この一般化パターンは、G_Listに入力され、G_Listは入力事例とGPListとの間の可能な一般化パターンを含むことになる。サブルーチンG_List_GENは図７Ｃのステップ２４０において開始する。
【０１１６】
ステップ２２４において、G_Listが空であるか否かを判定する。G_Listが空の場合、入力事例とGPListとの間の一般化パターンはサブルーチンG_List_GENにより見出されず、サブルーチンGEN-INSTANCE-GPLISTはステップ２３６においてリターンする。
【０１１７】
G_Listに項目がある場合、サブルーチンGEN-INSTANCE-GPLISTは、ステップ２２５へと進む。ここで、サブルーチンUG_List_GENが呼び出される。サブルーチンUG_List_GENは、図７Ｄのステップ２６０において開始し、G_Listから固有の一般化パターンリストUG_Listを形成する。
【０１１８】
ステップ２２６において、UG_Listから第１の項目UG_Itemが取り出され、共通部分であるFirst_IntersectionがUG_Itemから抽出される。ステップ２２７において、GPListから第１の項目GPList_Itemが取り出され、共通部分Second_IntersectionがGPList_Itemから抽出される。
【０１１９】
ステップ２２８において、First_Intersection及びSecond_Intersectionが一致するか否かを判定する。ステップ２２８において、First_Intersection及びSecond_Intersectionが一致することが見出される場合、ステップ２２９において、GPList_Itemの出現は、UG_Itemの出現に等しく設定される。サブルーチンは、ステップ２３３へと続く。
【０１２０】
ステップ２２８において、First_Intersection及びSecond_Intersectionが一致しないことが見出される場合、ステップ２３０において、GPListの全ての項目の考慮が終了したか否かを判定する。項目が残っている場合、ステップ２２８において再びFirst_Intersection及びSecond_Intersectionが一致するか否かを判定する前に、ステップ２３１において、GPListの次の項目が、Second_Intersectionとしての共通部分と共に取り出される。ステップ２３０において、GPListの全ての項目の考慮が終了していると判定された場合、ステップ２３２において、UG_ItemがGPListに加えられ、サブルーチンは、ステップ２３３へと続く。
【０１２１】
ステップ２３３において、UG_Listの全ての項目の考慮が終了していないと判定される場合、ステップ２３４においてUG_Listの次の項目が、First_  Intersectionとしての共通部分と共に取り出され、ステップ２２７へと続く。これに対し、ステップ２３３において、UG_Listの全ての項目の考慮が終了していると判定される場合、ステップ２３５において、サブルーチンGEN-INSTANCE-GPLISTは、GPListを出力し、ステップ２３６においてリターンする。
【０１２２】
図７Ｃを参照して、サブルーチンG_List_GENを説明する。このサブルーチンは、入力事例とGPListの全ての項目との間の全ての一般化パターンを判定する。サブルーチンG_List_GENは、ステップ２４０において開始し、入力事例及びGPListを入力として受け取る。入力はステップ２４１において受け取られる。ステップ２４２において、第１の一般化パターンGPList_ItemがGPListから取得され、ステップ２４３において、入力事例から第１の特徴が取り出され、ステップ２４４において、GPList_Itemの共通部分から第１の特徴が取り出される。ステップ２４５において、入力事例から取り出された特徴は、GPList_Itemから取り出された特徴と同じであるか否かを判定する。ステップ２４５において、一致が見出されない場合、ステップ２４６において、GPList_Itemからの全ての項目を処理し終えたか否かを判定する。GPList_Itemに更に特徴が残っている場合、ステップ２５５において、GPList_  Itemから次の特徴を取り出し、ステップ２４５へと続く。GPList_Itemの全ての特徴の考慮が終了した場合、サブルーチンはステップ２４７へと続く。
【０１２３】
ステップ２４５において一致が見出される場合、ステップ２５２において、新規の一般化パターンが作成されたか否かを判定し、ステップ２５３において、必要に応じて１つの一般化パターンを作成する。既に作成されている場合は、ステップ２５４へと続き、ここで共有の特徴が新規の一般化パターンに加えられる。サブルーチンは、ステップ２４７へと続き、入力事例からの全ての特徴の処理が終了したか否かを判定する。入力事例に特徴が残っている場合、ステップ２５６において、入力事例から次の特徴を取り出す。
【０１２４】
ステップ２４７において、入力事例からの全ての特徴の考慮が終了したと判定された場合、ステップ２４８において、ステップ２５２で新規の一般化パターンが作成されたか否かを判定する。GPListの共通部分に一般化パターンが既に存在する場合、サブルーチンは、ステップ２４９へと続き、ここで新規の一般化パターンの出現に対して、同じ共通部分を有するGPList_Itemの値＋１が付与される。ステップ２５０において、新規の一般化パターンがG_Listに加えられる。
【０１２５】
ステップ２４８において、新規の一般化パターンがGPListにまだ存在しないと判定された場合、サブルーチンはステップ２５１へと続く。
【０１２６】
ステップ２５１において、GPListからの全ての項目の考慮が終了したか否かを判定する。項目がGPListに残っている場合、サブルーチンは、ステップ２５７へと続き、ここでGPListの次の項目が取り出され、ステップ２４３が実行される。これに対して、GPListの全ての項目の考慮が終了している場合、サブルーチンG_List_GENは、ステップ２５８において出力として新規のG_Listを生成した後で、ステップ２５９においてリターンする。
【０１２７】
図７Ｄにおいて、サブルーチンUG_List_GENが示される。このサブルーチンは、固有の一般化パターンリストUG_Listを形成する。ステップ２６０において開始すると、サブルーチンは、ステップ２６１において、G_Listを入力として受け取る。ステップ２６２において、第１の一般化パターンがG_ListからUG_Listにコピーされる。ステップ２６３において、G_Listからの第１の項目であるG_List_Itemが取り出され、共通部分First_IntersectionがG_List_Itemから取り出される。ステップ２６４において、UG_Listからの第１の項目UGList_Itemが取り出され、共通部分Second_IntersectionがUGList_Itemから取り出される。
【０１２８】
ステップ２６５において、First_Intersection及びSecond_Intersectionが一致するか否かを判定する。First_Intersection及びSecond_Inter  sectionが一致する場合、ステップ２６９及び２７０において、２つの項目G_List_Item及びUGList_Itemのうちの高い方の出現が判定され、UGList_  Itemの出現として保存される。サブルーチンはステップ２６８へと続く。
【０１２９】
First_Intersection及びSecond_Intersectionが一致しない場合、ステップ２６６において、UG_Listの全ての項目の考慮が終了したか否かを判定する。項目が残っている場合、ステップ２６５で再度First_Intersection及びSecond_Intersectionが一致するか否かを判定する前に、ステップ２７１において、UG_Listの次の項目がSecond_Intersectionとしての共通部分と共に取り出される。ステップ２６６において、UG_Listの全ての項目の考慮が終了したと判定された場合、ステップ２６７において、G_List_ItemがUG_Listに加えられ、サブルーチンはステップ２６８へと続く。
【０１３０】
ステップ２６８において、GPListの全ての項目の考慮が終了していないと判定される場合、ステップ２６３において、G_Listの次の項目がFirst_  Intersectionとしての共通部分と共に取り出され、ステップ２６４へと続く。これに対して、ステップ２６８において、G_Listの全ての項目の考慮が終了していないと判定される場合、ステップ２７３において、サブルーチンUG_List_GENは、UG_Listを出力し、ステップ２７４においてリターンする。
【０１３１】
サブルーチンGEN-INSTANCE-EXAMINED-INSTANCESは、図７Ｅのステップ３１０において開始する。このサブルーチンは、検査済ケースリスト、事例ファイルからの入力事例、及び、検査済事例リストの事例間での一般化パターンを見出す。サブルーチンGEN-INSTANCE-EXAMINED-INSTANCESは、ステップ３１１において、これらを入力として受け取る。
【０１３２】
ステップ３１２において、検査済事例リストが空か否かを判定し、空の場合、ステップ３１３においてリターンする。検査済事例リストが項目を有する場合、サブルーチンはステップ３１４へと進む。ここで、第１の検査済事例リストが、検査済事例リストから取り出される。ステップ３１５において、サブルーチンGET-GEN-PATTERNを呼び出し、入力事例と検査済事例リストからの事例との間の一般化パターンGen-patternを計算する。サブルーチンGET-GEN-PATTERNは、図７Ｆのステップ３３０において開始する。
【０１３３】
ステップ３１６において、Gen-patternが見出されたか否かを判定する。Gen-patternが見出された場合、ステップ３１７において、サブルーチンは、Gen-patternがGPListのいずれかの項目と一致するか否かを判定する。Gen-patternがGPListのいずれの項目とも一致しない場合、ステップ３１８において、Gen-patternを新規の項目としてGPListに加え、ステップ３１９へと続く。ステップ３１７において、Gen-patternがGPListの項目と一致することを見出す場合、サブルーチンは、ステップ３１９へと続き、ここで検査済事例リストの全ての事例の考慮が終了したか否かを判定する。
【０１３４】
ステップ３１９において、考慮すべき検査済事例リストの事例が残っている場合、ステップ３２０において、検査済事例リストから次の事例を取り出し、ステップ３１５へと続く。これに対して、事例が残っていない場合、ステップ３２１において、GPListを出力し、サブルーチンGEN-INSTANCE-EXAMINED-INSTANCESは、ステップ３２２においてリターンする。
【０１３５】
図７Ｆにおいて、事例ファイルからの入力事例と検査済事例リストからの１つの事例との間の一般化パターンGen-patternを識別するためのサブルーチンGET-GEN-PATTERNが示される。サブルーチンは、ステップ３３０において開始し、ステップ３３１において、入力事例及び検査済事例リストからの事例を入力として取得する。サブルーチンは、これらの２つの事例を入力としてとり、それぞれの特徴を比較する。２つの事例が特徴の一部を共有する場合、それらの共有の特徴は、Gen-patternの共通部分に含まれることになる。Gen-patternにおける出現は２となる。これに対し、双方の事例間で特徴が共有されない場合、空のGen-patternが出力として生成される。
【０１３６】
ステップ３３２において、入力事例からFirst-featureという名称の第１の特徴を取り出す。これに続くステップ３３３において、検査済事例リストの事例からSecond-featureという名称の第１の特徴が取り出される。ステップ３３４において、First-featureがSecond-featureと同じであるか否かを判定する。同じである場合、ステップ３３５において、この特徴をGen-patternの共通部分に保有することになり、ステップ３３８へと続く。ステップ３３４において、特徴が同じでないと判定された場合、ステップ３３６において、検査済事例リストからの事例の全ての特徴の考慮が終了したか否かを判定する。全ての特徴の考慮が終了した場合、サブルーチンはステップ３３８へと続く。終了していない場合、ステップ３３７において、検査済ケースリストの次の特徴、即ち、検査済事例リストからの事例を取り出し、それをSecond-featureと名づけ、ステップ３３４へと続く。ステップ３３８において、入力事例の全ての特徴の考慮が終了したか否かを判定する。全ての特徴の考慮が終了したと判定される場合、サブルーチンはステップ３４０へと続く。しかし、ステップ３３８において、入力事例の全ての特徴の考慮が終了していないと判定された場合、ステップ３３９において、入力事例の次の特徴を取り出し、それをFirst-featureと名づけ、ステップ３３３へと続く。
【０１３７】
ステップ３４０において、Gen-patternが空であるか否かを判定する。Gen-patternが空でない場合、Gen-patternの出現は２とされ、サブルーチンGET-GEN-PATTERNは、ステップ３４２においてGen-patternを出力として生成した後に、ステップ３４３においてリターンする。ステップ３４０において、Gen-patternが空であると判定される場合、サブルーチンGET-GEN-PATTERNもステップ３４３においてリターンする。
【０１３８】
図４及び図７Ａから図７Ｆの方法は、これらの図面の関数及び下位関数を実行する１つ以上の集積回路などの専用のハードウェアで実現されても良い。このような専用のハードウェアは、グラフィックプロセッサ、デジタル信号プロセッサ、又は１つ以上のマイクロプロセッサ及び関連メモリを含んでも良い。
【０１３９】
以上、本発明の実施形態のいくつかのみを説明したが、本発明の趣旨から逸脱することなく、変形及び／又は変更を行なっても良い。実施形態は、例示のためのものであり、本発明を限定するものではない。
【図面の簡単な説明】
【図１Ａ】機能的なユーザの挙動パターンを学習し、且つ特定のコンテキストにおける特定のユーザに適した最適なイベントシーケンスを計画するためのシステムを概略的に表現する図。
【図１Ｂ】図１Ａのシステムのアバターエージェントを詳細に表現する図。
【図２】典型的な電子プログラムガイドからの抜粋を示す図。
【図３】図１Ａのシステムの表示画面に表示されたアニメのキャラクターを示す図。
【図４（ａ）】、
【図４（ｂ）】、
【図４（ｃ）】図１Ｂに示すアバターエージェントの計画モジュールにより実行される、過去のユーザ挙動パターン及び決定のコンテキストを考慮してどの決定が最も適切であるかを判定する方法の流れ図。
【図５】タスクネットワーク内のタスクの概略図。
【図６】コンテキスト的なタスクネットワークの一例の概略図。
【図７Ａ】、
【図７Ｂ（ａ）】、
【図７Ｂ（ｂ）】、
【図７Ｃ（ａ）】、
【図７Ｃ（ｂ）】、
【図７Ｄ】、
【図７Ｅ】、
【図７Ｆ】図１Ａに示すアバターエージェントの学習モジュールにより実行される、ユーザが下した決定からコンテキスト的な挙動パターンを学習する方法の流れ図。
【図８】本発明の実施例を実施可能な汎用コンピュータの概略ブロック図。
【図９Ａ】、
【図９Ｂ（ａ）】
【図９Ｂ（ｂ）】事例のエントリの一例を含む表を示す図。
【図１０Ａ】、
【図１０Ｂ】、
【図１０Ｃ】図９Ａ及び９Ｂに示す事例から作成される挙動パターンを含む表を示す図。
【図１１Ａ】、
【図１１Ｂ】コンテキスト化されたレコードのリストの一例を示す図。
【図１Ａ】
0003768914.tif 000007
【図１Ｂ】
0003768914.tif 000008
【図２】
0003768914.tif 000009
【図３】
0003768914.tif 000010
【図４（ａ）】
0003768914.tif 000011
【図４（ｂ）】
0003768914.tif 000012
【図４（ｃ）】
0003768914.tif 000013
【図５】
0003768914.tif 000014
【図６】
0003768914.tif 000015
【図７Ａ】
0003768914.tif 000016
【図７Ｂ（ａ）】
0003768914.tif 000017
【図７Ｂ（ｂ）】
0003768914.tif 000018
【図７Ｃ（ａ）】
0003768914.tif 000019
【図７Ｃ（ｂ）】
0003768914.tif 000020
【図７Ｄ】
0003768914.tif 000021
【図７Ｅ】
0003768914.tif 000022
【図７Ｆ】
0003768914.tif 000023
【図８】
0003768914.tif 000024
【図９Ａ】
0003768914.tif 000025
【図９Ｂ（ａ）】
0003768914.tif 000026
【図９Ｂ（ｂ）】
0003768914.tif 000027
【図１０Ａ】
0003768914.tif 000028
【図１０Ｂ】
0003768914.tif 000029
【図１０Ｃ】
0003768914.tif 000030
【図１１Ａ】
0003768914.tif 000031
【図１１Ｂ】
0003768914.tif 000032