デジタルネットワークにおける利用上のコンフリクトに対処する方法
【課題】 家庭内デジタルネットワークといったデジタルネットワークにおける利用上のコンフリクトを柔軟に且つ効率よく解決することのできる方法及びデバイスを提供する。
【解決手段】 コンフリクトは、第１の目的のために第１のアプリケーション２により既に利用されているリソースを、第２のアプリケーション２’が第２の目的のためにアクセスすることを望むときに発生する。このような場合、本発明の方法は、第１の目的及び第２の目的を同時に達成する、ネットワーク構成要素への実際の要求に対する変更を探索する。つまり、第２のアプリケーション２’によるリソースの実際の要求は延期することによって変更されるが、要求の根底にある目的は同じままである。
【解決手段】 コンフリクトは、第１の目的のために第１のアプリケーション２により既に利用されているリソースを、第２のアプリケーション２’が第２の目的のためにアクセスすることを望むときに発生する。このような場合、本発明の方法は、第１の目的及び第２の目的を同時に達成する、ネットワーク構成要素への実際の要求に対する変更を探索する。つまり、第２のアプリケーション２’によるリソースの実際の要求は延期することによって変更されるが、要求の根底にある目的は同じままである。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、特に、家庭内デジタルネットワークといったデジタルネットワークにおける利用上のコンフリクトの対処方法に関連する。利用上のコンフリクトとは、第１の目的のために第１のアプリケーションによって使用されるリソースが、第２の目的のために第２のアプリケーションによって要求されることである。本発明は更に、本発明の方法が実施される、特に家庭内デジタルネットワークといったデジタルネットワークに関連する。
【０００２】
【従来の技術】情報処理はますますデジタル化され、且つ、処理媒体のネットワーク化が進んでいる。このことが家庭の領域に関連すると、関連付けられるネットワークは、家庭内デジタルネットワーク（in-home digital network：ＩＨＤＮ）と称される。このようなＩＨＤＮには、テレビジョン、ラジオ、モニタ、スピーカ、カメラ、プリンタ、スキャナ、ＰＣ、電話サービス、音声認識、家庭用電化製品制御装置、セキュリティ装置等が含まれる。オーディオ及びビデオ媒体の場合は特に、一般的に１００Ｍｂｉｔ／ｓの高速のデータ転送速度を持つので、様々な電化製品がリソース（ユニット及びネットワークリソースの両方）を獲得しようと競い合うとき、利用上のコンフリクトがもたらされてしまう。
【０００３】最新技術において、ネットワークにおけるリソース管理方法は多数既知ではあるが、これらは以下に示す前提のうちの少なくとも１つを常に予想する。
【０００４】−要求は、その明らかなパラメータによって完全に記述されるものと見なされる。つまり、システムには、要求の評価の役割を担う追加の、最初に考慮されなかった情報はないと想定されている。
【０００５】−仮に、サービス品質に関するネゴシエーションがあったとしても、これは、例えば、１つのアプリケーションと管理ユニットとの間で行われるが、ユーザレベルでは行われない。
【０００６】−特定のパラメータ軸に沿っての縮小は時として意味があるが、完全に異なるパラメータ値に要求を根本的に変更することは意味がない点で要求は明白であると想定される。
【０００７】−要求の縮小には要求しているエージェンシの明らかな同意が必要である。特定のパラメータに関しての好み及び承諾可能性の「知識」は存在しない。
【０００８】−ネゴシエーションの過程における代替のオファーは、追加の情報に支援されてアプリケーションに適合されるのではなく、単に利用可能なリソースから一般的に推測される。
【０００９】−要求は、完全に、且つ、代替のオファーなく拒絶されることが可能である。
【００１０】−新しく届く要求は分離して考慮される。つまり、古い要求の再ネゴシエーションはない（プリエンプションはなく、必要である場合は古い要求の完全なキャンセルにより行われる）以下は、リソース管理システムの一部の実際の例にあてはまるものである。
【００１１】−ＨＡＶｉ１．０におけるリソース管理はプリエンプションを可能にする（ユーザにクエリーしてでも可能にする）が、これは、使用するユニットの完全な解放に関連する。即ち、古い要求は完全に上書きされる。既存の要求はいずれも代替案を見つけるべく試験されない。即ち、ユーザは、真の支援を受けることはない。
【００１２】−オペレーティング・システム及びインターネット・ディフェレンシエーテッド・サービス・アーキテクチャ（Internet Differentiated Services Architecture）におけるプロセッサスケジューリングメカニズムはともに、要求の優先順位を決め、これは、少ないリソースの（幾分）公平な割当てとなるよう意図されたものである。ここでは、しっかりとした確実さという点で、任意の種類のリザベーションは行われない。
【００１３】−インターネット・インテグレーテッド・サービス・アーキテクチャ（リソース・リザベーション・プロトコル−ＲＳＶＰ）は、実現することのできない要求を単に拒絶する。
【００１４】
【発明が解決しようとする課題】このような背景に対し、本発明は、特に、家庭内デジタルネットワークといったデジタルネットワークにおける利用上のコンフリクトを柔軟に且つ効率よく解決することのできる方法及びデバイスを提供することを目的とする。
【００１５】
【課題を解決するための手段】この目的は、請求項１に記載される特徴を有する方法と、請求項１０に記載する特徴を有するデジタルネットワークによって達成される。有利な展開例は、従属項に含まれる。
【００１６】提案する方法は、特に、家庭内デジタルネットワークといったデジタルネットワークにおける利用上のコンフリクトに対処するよう機能する。コンフリクトは、第１のアプリケーションが第１の目的のためにリソースを使用している際に、同一のリソースが、第２のアプリケーションによって第２の目的のために要求される状況で発生する。本発明の方法では、第１のアプリケーションによるリソースの要求、及び／又は、第２のアプリケーションによるリソースの要求に対する変更が捜し求められ、捜し求められる変更は、第１の目的及び第２の目的の両方を同時に達成可能にすることを目的とする。
【００１７】従って、提案する方法では、リソースの実際の要求と、根底にある目的とが識別される。これにより、要求を変更することにより利用上のコンフリクトが解決され、また、目的が同時に実現される。このことは、ネットワークのユーザに実際に関連する基準を構成する。実際のリソースの実際の要求と、より抽象的な根底にある目的とを区別することにより、ソリューションの探索にかなりの柔軟性が与えられる。更に、変更は、後からの第２のアプリケーションによる要求と、先立っての第１のアプリケーションによる要求の両方に対し捜し求められることが重要である。従って、他の多くの方法とは異なり、第１のアプリケーションはタブーではないので、それに相当してソリューションの可能性が大きくなる。
【００１８】リソースの要求を実際に変更することを可能にする方法は多数ある。例えば、変更には、特に、要求の完全な又は部分的な延期、特に、帯域幅及び／又はアクセスのデータ転送速度といったアクセスパラメータに対する変更、及び／又は、別の等価のリソースへの切替えが含まれ得る。リソースの要求は更に、例えば、中間局として機能するリソースに切替えることにより、根本的に再構成されてもよい。
【００１９】それぞれの要求の根底にある目的は、特に、データフローチャートによって表されることが可能であり、これは、要求されたデータ及びこのデータの所望の目的に関する情報を含むことが好適である。要求されたデータは例えば、特定のスポーツニュース、特定の映画、特定の音楽等である。これらのデータの所望の目的は、例えば、表現方法（オーディオ／ビデオ）及び表現パラメータ（画像寸法、分解能、音量等）によって定義づけられる。
【００２０】本発明の方法の１つの展開例としては、リソースの要求に対する変更を探索する際に、ユーザのプロファイルが考慮に入れられる。ユーザプロファイルは、ネットワークのユーザに関連する既知で且つ直接的に与えられるデータであってよい。しかし、同時に、ユーザプロファイルのデータは、ユーザの動作を観察することにより適応されて獲得されることも可能である。従って、例えば、ユーザがインターネットを頻繁に利用するか否か又は特定のテレビ番組を選ぶ傾向があるか否かによって、特定のユーザが、ネットワーク上で利用可能なサービスに対しどのような好みがあるかを決定することができる。更に、ユーザプロファイルにはユーザのダイアリからのデータを含んでもよく、これにより、リソースへのアクセスの延期を決定することができる。
【００２１】更に、ネットワークのコンフリクトの解決策を探索する際に、ネットワークの一人以上のユーザとやり取りがなされることが好適である。このために、ユーザは、必要である場合には、システムにもともとない追加の情報が求められる場合がある。更に、やり取りがなされることにより、リソースアクセスに対し提案された変更に対し、それが実行される前に、ユーザの同意を得ることが可能である。提案される変更が、ビデオアクセスの帯域幅を小さくすることである場合、ユーザは、変更の結果としての劣化したピクチャ品質に同意しない場合もあるので、同意するか否かの機会が与えられる。
【００２２】本発明のもう１つの展開例では、特定されるコンフリクト解決策に対し、提案される変更が有利に実施される順序も決定される。このような順序を予め決定することにより、アプリケーションがアクセスの制御されていない変更を実施することを回避する。アクセスの制御されていない変更は、アクセスを繰り返し遮断してしまったり、１つのアプリケーションを望ましくなく中断させてしまったりする場合がある。
【００２３】更に、目的を変更することなく、有限のリソースの実際の要求への好適な変更が見つからない場合は、少なくとも１つの目的を変更することが提案される。ここでは、目的の変更に対する提案には、存在する又は学習した情報、特に、ユーザプロファイルを使用することができる。従って、例えば、もし、当初希望されるニュース番組がリソースコンフリクトにより記録できない場合、類似するニュース番組の記録が提案される。帯域幅が小さくされてオーディオ又はビデオ伝送を行うというシステムによる提案も、伝送の品質が当初の目的の一部である場合は、根底にある目的の変更の例として挙げられる。
【００２４】更に、将来の利用上のコンフリクトを最小限にするために、ネットワーク及び／又はそのリソースの変更又は拡張に対する提案を考え出すことも可能である。このような提案は、例えば、特定の種類の利用上のコンフリクトが繰り返し観察され、このコンフリクトは更なるリソースを追加するか又はネットワークを再構成することによって回避されるという事実に基づいている。
【００２５】更に、本発明の方法は、利用上のコンフリクトを予想することにより対処する方法も展開することができる。特に、この場合、第２のアプリケーションによるリソースの要求は単に予測される要求であり、この予測は、例えば、学習されたユーザプロファイルに基づいている。その場合、第２の要求の結果予想されるコンフリクト状況は、第１のリソースの要求を実行する際に既に考慮に入れられ、可能な限り解決されるか又は事前に回避される。
【００２６】本発明は更に、デジタルネットワーク、特に、家庭内デジタルネットワークに関連する。このネットワークは、アプリケーション、リソース管理システム、メディエータモジュールがその上で実行される少なくとも１つのデータ処理ユニットを含む。メディエータモジュールは、上述したような種類の方法を行うことができるよう設定される。ネットワークは更に、データ処理ユニットに接続されるデータベースを含み、ネットワークのトポロジー、リソース、及び、接続に関する情報、ネットワークにおけるデータストック、及び、サービスプロバイダ及び放送局から利用可能なサービスに関する情報、及び、デフォルトの及び／又は学習したユーザプロファイル及びユーザデータに関する情報を含むことが好適である。最後に、ネットワークは、データ処理ユニットに接続され、且つ、ユーザとのやり取りを可能にする少なくとも１つのユーザインタフェースを含む。
【００２７】
【発明の実施の形態】本発明を、図面に示される実施例を参照しながら更に詳細に説明するが、本発明は以下に制限されないものである。
【００２８】図１にその例を示す家庭内デジタルネットワーク（ＩＨＤＮ）では、様々なアプリケーションがリソース（ユニット及びネットワークリソースの両方）を獲得するために競い合う。時として特定の動作を行うためのユーザからの要求は、既存のリソースを使用して実現できない場合がある。システムは、ユーザに拒絶を単に伝えるのではなく、現在の要求をあれこれと変更することによって妥協のソリューションを提案し、その提案を実行する。このようなタイプのユーザサポートの動機は、アナログＡ／Ｖシステム又は個々のＰＣと比較した際のＩＨＤＮの複雑さにある。これらのシステムとは対照的に、アプリケーションとリソース間の相関関係はユーザにとって不明瞭な場合があるので、ユーザは自分自身でソリューションに到ることができない。アナログＡ／Ｖ分野からの例を挙げるに、ビデオレコーダＶＣＲが既に何かを記録していて、ユーザが他の記録を望む場合は、ＶＣＲデックに対するリソースコンフリクトは明らかであり、ユーザが妥協することにより（記録を延期にするか、又は、記録しない）解決可能である。ＩＨＤＮでは、同様のコンフリクトはより微妙でユーザが把握することができない場合がある。従って、例えば、幾分「動作がたくさん詰まった」ビデオシーケンスのＭＰＥＧ符号化の結果もたらされる異なるデータ転送速度により、２つのカレントの同時捕捉が可能であるか否かに影響が及ぼされる。可能なソリューションもむしろより複雑で、例えば、ビデオ帯域幅を減少するよう記録するといったことが挙げられる。
【００２９】更に、家庭における全てのデバイスをネットワークで接続することにより、全ての占有者のアプリケーションが、リソース（例えば、ネットワーク負荷）を獲得するべく互いと直接競い合うことが可能にされる。これまでは、コンフリクトするアプリケーションは、同一のデバイス上で実行するもの（例えば、記録とビデオの再生）のみであったが、ここでは、コンフリクトは完全に異なるアプリケーション間（例えば、ウェブダウンロードとビデオ記録）でも起きるようになり、従って、異なるユーザからの要求間のコンフリクトの頻度は非常に高くなる。ここでは、ユーザは、時としてＩＨＤＮからのサポートを必要とするが、これは単に、自分の要求と競合している要求を出している別のユーザが不在なので、システムは、アドバイザリ的な役割も果たさなければならないからである。例えば、理想的なソリューションは、不在のユーザのダイアリから、そのユーザはいずれにしても、現在ウェブからダウンロードされているビデオは翌日にしか見ることができないことを認識し、認識した後、ダウンロードを数時間延期することを提案することである。従って、本発明のシステムは、不在のユーザの要求を絶対に拒否せず、全てのユーザが承諾できるソリューションが見つかるまで可能な代替案を捜し求めることを目的とする。
【００３０】この目的は、いわゆるメディエータシステムを有するネットワークによって達成される。このメディエータシステムは、図１を参照するに以下の構成要素を含む。
−既存のリソース（バスライン、ネットワークノード、データ処理ユニット、入力／出力ユニット、電話サービス等）を管理するリソース管理システム３と、−メディエータ１と、−コンテンツ代替案、アプリケーションカタログ、ユーザの好み及び情報等を有するデータベース４と、−ユーザと情報交換するためのユーザインタフェース６と、−学習的（ヒューリスティック）に、また、適切な場合には人工知能の方法を使用してコンパイルされることが好適である中央メディエーションアルゴリズム５と、−様々なアプリケーション２、２´を含む。
【００３１】列挙し図１に示す構成要素は少なくとも論理的な形式で存在するが、実際の実施では様々に組み合わされていてよい。
【００３２】メディエータシステムは、他の場所でも使用される既存のユニット（ＳＴＢ、若しくはＰＣ）上のソフトウェアとして存在し得、その場合、連続的に入手可能である、又は、単一のユニットとしてネットワークに組み込まれる必要がある。単一のユニットとしてネットワークに組み込まれるという後者の場合、メディエータシステムはデータベース４を別のユニット（ホームアーカイブ等）に格納し得る。
【００３３】メディエーションの機能的な手順は以下の通りである。
【００３４】−アプリケーション２は、リソース管理システム３に対し要求を行うが、この要求は実現することができない。その場合、アプリケーション２は、メディエータ１に問合せをする。問合せをすることによって、アプリケーション２はメディエータ１に、実際のリソース要求だけでなく、所望のデータフローチャートの形式（即ち、例えば、コンテンツ「ＣＮＮ」を有する情報源が、位置、寸法、ビデオ品質等といった特定の特徴を有するシンク（ディスプレイ）に接続されることを記述するデータ構造）である根底にある目的の一般的な記述も与える。
【００３５】−メディエータ１は、リソース管理システム３、影響を受けている別のアプリケーション２´、データベース４、及び、ユーザインタフェース６から存在するコンフリクトに関する更なる情報を得る。メディエータ１は、例えば、リソース管理システム３からは、関心のリソースを現在使用しているアプリケーションに関する情報を、このアプリケーションからは、このリソースに支援されて現在実行されているデータフローチャートを、データベース４からは、影響を受けている両方のユーザのユーザプロファイルを、そして、ユーザインタフェース６からは、プロファイルにはまだ設定されていない調節値を得る。メディエータ１は次にこれらの情報を中央メディエーションアルゴリズム５に渡す。
【００３６】−メディエーションアルゴリズム５は、代替のソリューションに達するよう試みる。このためにメディエータ１は更なる情報を取出しする場合もある。これは最初に供給されたものではなく、また、上述した他のエンティティから再度抽出することができる。これは、情報を走査するために一般的に決められる記述言語によって実行されることが好適である。特に、メディエータ１に向けられる１つの可能なクエリーとしては、提案したソリューションに対するユーザの承諾に関するものであり、これは、ユーザインタフェース６によって試験される。
【００３７】−メディエーションアルゴリズム５が全ての要求一式を満足するソリューションを見つけた場合、アルゴリズム５はそのことをメディエータ１に伝える。この通信は、例えば、影響を受けている各アプリケーションに対するデータフローチャートの形式をとり、「コンテンツＣＮＮを有する情報源」という一般的な要求は、実際の名前が付けられたリソースによって置換される。同時に、どの順序でアプリケーション２、２´が、閉塞されることなく現在使用されているリソースから新しいリソースへ切替えることができるか（マイグレーション・パス）も記載される。（閉塞がある場合は、アプリケーション２は、ソリューションに応じて、リソースＡを獲得するが、このことは、ソリューションによるリソースがアプリケーション２´から解放される前に試みられる。）単純なマイグレーション・パスがない場合、アルゴリズムは更に「迂回路（diversion）」を指定することができる。即ち、「アプリケーション２は、最初に少しの間全てのリソースを解放しなければならない。なぜなら、解放しなければ、多数のアプリケーション間で循環する依存性が存在してしまうからである」に従って指定することができる。このようなマイグレーション時における迂回路の必要性は明らかに、必要である場合には、ソリューションを評価する際にはアルゴリズムによって考慮に入れられなければならない。というのは、例えば、このような迂回路は、例えば、放送番組の記録が関連する場合、中断を引き起こす場合があり、このことをユーザが承諾できない場合があるからである。
【００３８】−次にメディエータ１は、特定のマイグレーション・パスに従ってそれらのリソースの使用を変更するようアプリケーション２、２´に呼び掛けする責任がある。
【００３９】以下に示す要求に対する変更は、原則的に、好適な妥協策に達するために実現可能である：−全体の動作又は動作の一部を延期（一旦、競合する要求が現れると、際立った部分を特に）する。
【００４０】−データ転送速度を遅くする、減少する。より長い時間が必要となることを考慮に入れる。
【００４１】−サービス品質、例えば、ビデオ帯域幅を減少する。
【００４２】−この要求に対して依然として好適である他のリソースに変更する（例えば、他の記憶媒体又はネットワーク経路に切替える）。
【００４３】−アプリケーションを再構成する。例えば、運搬可能な記録媒体への書込みという要求であるにも関わらず、最初にハードディスクに記憶し、次に所望の媒体に転送する。
【００４４】−データ源の種類を変更する。例えば、コンフリクトがある場合、ＤＶＢチューナでコンフリクトがある場合、インターネット放送に切替える。
【００４５】−ユーザにとって重要でない状況において要求を制限する（例えば、スポーツ放送における広告スロット、及び、中断時間の間は記録を行わない。例えば、ニュース番組の「ニュースキャスタ」のシーケンスにおけるデータ転送速度を遅くする）。
【００４６】−代替のコンテンツ又は別のアプリケーションに変更する（例えば、ホームアーカイブが他の機能により使用されているので、ホームアーカイブの記録物が再生できず、同一の試合番組における後続のシーケンスが現在テレビジョンで生中継されている場合、これが、代替として提供される）。
【００４７】−上述した全ての手段及び他の手段を組合わせたもの上述した変更のうちどの変更が実現可能であるかを決定するには、メディエーションアルゴリズムは以下を使用する。
【００４８】−ＩＨＤＮを介するトポロジー及びリソース情報とネットワークにアクセスするためのＩＨＤＮの接続（情報源：リソース管理システム３／データベース４）；
−ＩＨＤＮにおけるデータストック、及び、サービスプロバイダ／放送局から入手可能なサービス（例えば、テレビ番組）に関する情報（情報源：データベース４）；
−直接入力されたユーザの好み及び間接的に生成されるユーザの好み（例えば、特定の俳優、特定のグループなどに対するユーザの好みが、ＴｉＶｏのような機能によって確立される。即ち、「ＴｉＶｏ」は、遠隔制御装置上の「サム・アップ」／「サム・ダウン」キーによる格付け、及び、これらの格付けと、俳優、主題等といった放送局によって送信される番組の特徴に関するメタ情報間の相関関係の評価である。この機能は拡張されて、ウェブページといった他のコンテンツを含み、１つのウェブサイトで経過した時間を評価基準として組み込むことが可能である）（情報源：データベース４）；
−ユーザとのやり取り。これはローカル的に実現可能であるだけでなく、ＳＭＳ等を介した質問によっても可能である（情報源：ユーザインタフェース６）；−ユーザに関する他の情報。例えば、ダイアリ。（情報源：データベース４）；
−占有されるリソースの現在の使用状況に関する情報。（情報源：他のアプリケーション２、２´）；最適なコンフリクト解決を識別する可能な方法は以下の通りに実行されうる。
【００４９】１．既存のデータフローチャートオペレーションが決定され、それにより、コンフリクトは改善され得る。この例としては、１つのノードをもう１つのノードに置換すること（例えば、もう１つのノードに切替えること）、ノードにおけるパラメータを変更すること（例えば、サービス品質の引き下げ）、又は、チャート全体を変更すること（例えば、後の時間まで延期する）、又は、追加部をチャートに挿入すること（例えば、別のデータ担体にデータを暫定的に記憶する）が挙げられる。
【００５０】２．データフローチャートのどの部分がコンフリクトしているのかが正確に決められる。つまり、例えば、２つの要求がユニットＸに時間間隔Ｙに亘って関連することが正確に決められる。
【００５１】３．基本的に実現可能な動作から、選択は、コンフリクトに関連のある動作を中心に行われる。
【００５２】４．これらの動作のそれぞれは特定のカテゴリに分類され、カテゴリは、この動作によって良好な妥協案を見つけ出す可能性、別の質問をユーザにしなければならないか否か等を記述する。従って、例えば、多くの動作は更に他の要求によって新しいコンフリクトに導くが、その場合、より厳密な試験が必要となる。この段階において、アルゴリズムに対し既に利用可能な情報のみを使用する（これは、例えば、その動作に必要なリソースが使用されていることは知られておらず、従って、この動作は、「更なる情報を必要とするが、その場合、良好なソリューションとなりうる」というカテゴリに分類されることを意味し得る）。
【００５３】５．所定の手順において（好ましくは、ユーザのプロファイルに依存して）、より厳密な試験が、暫定的なソリューションのカテゴリ毎に行われ、最終的には良好な提案が見つけ出される。この為に、各カテゴリにおいて次々と提案されるソリューションはより厳密に試験される。これは、例えば、メディエータから更なる情報を要求することにより厳密に試験される。この情報に基づいて、最終的な評価が可能であるか、又は、提案されるソリューションが別のソリューションのカテゴリにマイグレートする。「最も満たされる」カテゴリからのソリューションが処理され、最後には、提案は「問題解決」のカテゴリにシフトする。
【００５４】６．必要に応じて、承諾可能な提案を見つけた後も検索を続けることが可能である。これは、例えば、ユーザが１つのソリューションのためにどれくらい待つことができるかに依存する。最適なソリューションを「落ち着いて」検索することができるよう１つの妥協案が最初に実施されることもある。
【００５５】既存のリソース管理及びスケジューリングシステムとは対照的に、上述した方法は、ＩＨＤＮへのリソース要求は、ユーザ側の実際の（より抽象的な）要望の不明確なイメージしか表さないという事実を考慮に入れる。ユーザ側の実際の要望とは、例えば、ユーザが夜遅く帰ってきたときに、スポーツニュースが包括的に伝えられることであるとする。このことは最初に、ユーザインタフェース６を介して要求をプロンプトさせ、対応するアプリケーション２´（及び、任意のコインシデンス、及び、システム及びユーザ側の専決）に、チャンネルＸからのスポーツニュースを、２０：００にマシーンＡのハードディスク上に記憶させる。このマッピングは決して明確ではないが、その不明確さはコンフリクトがある場合に考慮されるべきである。あるユーザは、スポーツニュースが２１：００にチャンネルＹから記録され、地元のスポーツフェスティバルからの特別の放送が２１：３０に地元の放送局から記録され、また、マシーンＡではなくマシーンＢに記録され、また、全体のデータ量を少なくするために、その特別放送のうち画面に「ニュースキャスタ」が現れている部分のみが顕著にピクチャ品質が下げられて記憶されても満足のゆくときもある。
【００５６】上述した本発明は、代替のソリューションを識別し、そのようなソリューションを使用することが可能なシステムを可能にする。
【００５７】システムのもう１つの利点は、リソースコンフリクトがある場合に、「古い」アプリケーションが単に原則的に優先されているわけではない点である。リソース管理用の一般的な既存のアルゴリズムでは、リソース障害を解決するために、新しい追加の要求の変更しか考慮しない。一方で、上述した取組み方法では、コンフリクトが発生した場合、全ての存在している要求及び新しい要求を同じように考慮に入れるので、可能なソリューションの範囲をかなり広げ、良好な結果へと導く。
【００５８】以下に、上述した方法の可能な拡張例を示す。
【００５９】−メディエータ１は、解決されたコンフリクトから学習することができる。例えば、過去に良好な結果を与えたソリューションカテゴリはより高く格付けされ、典型的なコンフリクトは分類されて「見本ソリューション」等が与えられる。
【００６０】−メディエータ１は、結果としてのコンフリクトを処理することにより、例えば、ユーザに入手すべき新しいハードウェア、ユーザのＩＨＤＮの再構成方法、又は、サービスプロバイダにより提供される加入すべき追加のサービスに関する提案を提供する。
【００６１】−ＴｉＶｏのような機能によってメディエータ１は、想定される将来の要求を予想するために、自分自身で任意のアプリケーションをスタートすることが可能である。
【００６２】−メディエータ１は、コンフリクトが発生する前にコンフリクトを予見しようと試み、コンフリクトを回避するか又は必要な追加の情報を収集することが可能である（例えば、「この番組を記録することをお望みになる時間帯には、Ｘの好きなチームのサッカーの試合があります。Ｘはこの試合を確実に観戦することを望むでしょう。あなたの希望の番組を翌日の再放送で記録してもよいでしょうか」とユーザに聞く）。このためには、メディエータ１は、可能である場合は、例えば、予防策として所望のリソースをフリーにしておくために自発的にアルゴリズム５を始動することができる。このために、メディエータ１は影響を受けているアプリケーションに対するデータフローチャートと、単に所望のリソースの要求のみから構成されるアーティフィシャルのデータフローチャートとを、このチャートに対し任意の種類の変更は問題ないという情報とともに、アルゴリズム５に提示する。
【００６３】−メディエータ１は、例えば、コンフリクトが発生したときに不在であったユーザに対し、サービス品質が低くされて記録が行われたことを謝罪する「お詫びの手紙」を「知らせ（ポスティングし）」、メディエータ１の決定に不満であったユーザを留意することにより次回の決定の際にはそのことをより考慮に入れる等を行うことにより「スケープゴート」的な役割を担う。
【図面の簡単な説明】
【図１】本発明の家庭内ネットワークの構成要素を示す図である。
【符号の説明】
１ メディエータ
２、２´ アプリケーション
３ リソース管理システム
４ データベース
５ 中央メディエーションアルゴリズム
６ ユーザインタフェース
【０００１】
【発明の属する技術分野】本発明は、特に、家庭内デジタルネットワークといったデジタルネットワークにおける利用上のコンフリクトの対処方法に関連する。利用上のコンフリクトとは、第１の目的のために第１のアプリケーションによって使用されるリソースが、第２の目的のために第２のアプリケーションによって要求されることである。本発明は更に、本発明の方法が実施される、特に家庭内デジタルネットワークといったデジタルネットワークに関連する。
【０００２】
【従来の技術】情報処理はますますデジタル化され、且つ、処理媒体のネットワーク化が進んでいる。このことが家庭の領域に関連すると、関連付けられるネットワークは、家庭内デジタルネットワーク（in-home digital network：ＩＨＤＮ）と称される。このようなＩＨＤＮには、テレビジョン、ラジオ、モニタ、スピーカ、カメラ、プリンタ、スキャナ、ＰＣ、電話サービス、音声認識、家庭用電化製品制御装置、セキュリティ装置等が含まれる。オーディオ及びビデオ媒体の場合は特に、一般的に１００Ｍｂｉｔ／ｓの高速のデータ転送速度を持つので、様々な電化製品がリソース（ユニット及びネットワークリソースの両方）を獲得しようと競い合うとき、利用上のコンフリクトがもたらされてしまう。
【０００３】最新技術において、ネットワークにおけるリソース管理方法は多数既知ではあるが、これらは以下に示す前提のうちの少なくとも１つを常に予想する。
【０００４】−要求は、その明らかなパラメータによって完全に記述されるものと見なされる。つまり、システムには、要求の評価の役割を担う追加の、最初に考慮されなかった情報はないと想定されている。
【０００５】−仮に、サービス品質に関するネゴシエーションがあったとしても、これは、例えば、１つのアプリケーションと管理ユニットとの間で行われるが、ユーザレベルでは行われない。
【０００６】−特定のパラメータ軸に沿っての縮小は時として意味があるが、完全に異なるパラメータ値に要求を根本的に変更することは意味がない点で要求は明白であると想定される。
【０００７】−要求の縮小には要求しているエージェンシの明らかな同意が必要である。特定のパラメータに関しての好み及び承諾可能性の「知識」は存在しない。
【０００８】−ネゴシエーションの過程における代替のオファーは、追加の情報に支援されてアプリケーションに適合されるのではなく、単に利用可能なリソースから一般的に推測される。
【０００９】−要求は、完全に、且つ、代替のオファーなく拒絶されることが可能である。
【００１０】−新しく届く要求は分離して考慮される。つまり、古い要求の再ネゴシエーションはない（プリエンプションはなく、必要である場合は古い要求の完全なキャンセルにより行われる）以下は、リソース管理システムの一部の実際の例にあてはまるものである。
【００１１】−ＨＡＶｉ１．０におけるリソース管理はプリエンプションを可能にする（ユーザにクエリーしてでも可能にする）が、これは、使用するユニットの完全な解放に関連する。即ち、古い要求は完全に上書きされる。既存の要求はいずれも代替案を見つけるべく試験されない。即ち、ユーザは、真の支援を受けることはない。
【００１２】−オペレーティング・システム及びインターネット・ディフェレンシエーテッド・サービス・アーキテクチャ（Internet Differentiated Services Architecture）におけるプロセッサスケジューリングメカニズムはともに、要求の優先順位を決め、これは、少ないリソースの（幾分）公平な割当てとなるよう意図されたものである。ここでは、しっかりとした確実さという点で、任意の種類のリザベーションは行われない。
【００１３】−インターネット・インテグレーテッド・サービス・アーキテクチャ（リソース・リザベーション・プロトコル−ＲＳＶＰ）は、実現することのできない要求を単に拒絶する。
【００１４】
【発明が解決しようとする課題】このような背景に対し、本発明は、特に、家庭内デジタルネットワークといったデジタルネットワークにおける利用上のコンフリクトを柔軟に且つ効率よく解決することのできる方法及びデバイスを提供することを目的とする。
【００１５】
【課題を解決するための手段】この目的は、請求項１に記載される特徴を有する方法と、請求項１０に記載する特徴を有するデジタルネットワークによって達成される。有利な展開例は、従属項に含まれる。
【００１６】提案する方法は、特に、家庭内デジタルネットワークといったデジタルネットワークにおける利用上のコンフリクトに対処するよう機能する。コンフリクトは、第１のアプリケーションが第１の目的のためにリソースを使用している際に、同一のリソースが、第２のアプリケーションによって第２の目的のために要求される状況で発生する。本発明の方法では、第１のアプリケーションによるリソースの要求、及び／又は、第２のアプリケーションによるリソースの要求に対する変更が捜し求められ、捜し求められる変更は、第１の目的及び第２の目的の両方を同時に達成可能にすることを目的とする。
【００１７】従って、提案する方法では、リソースの実際の要求と、根底にある目的とが識別される。これにより、要求を変更することにより利用上のコンフリクトが解決され、また、目的が同時に実現される。このことは、ネットワークのユーザに実際に関連する基準を構成する。実際のリソースの実際の要求と、より抽象的な根底にある目的とを区別することにより、ソリューションの探索にかなりの柔軟性が与えられる。更に、変更は、後からの第２のアプリケーションによる要求と、先立っての第１のアプリケーションによる要求の両方に対し捜し求められることが重要である。従って、他の多くの方法とは異なり、第１のアプリケーションはタブーではないので、それに相当してソリューションの可能性が大きくなる。
【００１８】リソースの要求を実際に変更することを可能にする方法は多数ある。例えば、変更には、特に、要求の完全な又は部分的な延期、特に、帯域幅及び／又はアクセスのデータ転送速度といったアクセスパラメータに対する変更、及び／又は、別の等価のリソースへの切替えが含まれ得る。リソースの要求は更に、例えば、中間局として機能するリソースに切替えることにより、根本的に再構成されてもよい。
【００１９】それぞれの要求の根底にある目的は、特に、データフローチャートによって表されることが可能であり、これは、要求されたデータ及びこのデータの所望の目的に関する情報を含むことが好適である。要求されたデータは例えば、特定のスポーツニュース、特定の映画、特定の音楽等である。これらのデータの所望の目的は、例えば、表現方法（オーディオ／ビデオ）及び表現パラメータ（画像寸法、分解能、音量等）によって定義づけられる。
【００２０】本発明の方法の１つの展開例としては、リソースの要求に対する変更を探索する際に、ユーザのプロファイルが考慮に入れられる。ユーザプロファイルは、ネットワークのユーザに関連する既知で且つ直接的に与えられるデータであってよい。しかし、同時に、ユーザプロファイルのデータは、ユーザの動作を観察することにより適応されて獲得されることも可能である。従って、例えば、ユーザがインターネットを頻繁に利用するか否か又は特定のテレビ番組を選ぶ傾向があるか否かによって、特定のユーザが、ネットワーク上で利用可能なサービスに対しどのような好みがあるかを決定することができる。更に、ユーザプロファイルにはユーザのダイアリからのデータを含んでもよく、これにより、リソースへのアクセスの延期を決定することができる。
【００２１】更に、ネットワークのコンフリクトの解決策を探索する際に、ネットワークの一人以上のユーザとやり取りがなされることが好適である。このために、ユーザは、必要である場合には、システムにもともとない追加の情報が求められる場合がある。更に、やり取りがなされることにより、リソースアクセスに対し提案された変更に対し、それが実行される前に、ユーザの同意を得ることが可能である。提案される変更が、ビデオアクセスの帯域幅を小さくすることである場合、ユーザは、変更の結果としての劣化したピクチャ品質に同意しない場合もあるので、同意するか否かの機会が与えられる。
【００２２】本発明のもう１つの展開例では、特定されるコンフリクト解決策に対し、提案される変更が有利に実施される順序も決定される。このような順序を予め決定することにより、アプリケーションがアクセスの制御されていない変更を実施することを回避する。アクセスの制御されていない変更は、アクセスを繰り返し遮断してしまったり、１つのアプリケーションを望ましくなく中断させてしまったりする場合がある。
【００２３】更に、目的を変更することなく、有限のリソースの実際の要求への好適な変更が見つからない場合は、少なくとも１つの目的を変更することが提案される。ここでは、目的の変更に対する提案には、存在する又は学習した情報、特に、ユーザプロファイルを使用することができる。従って、例えば、もし、当初希望されるニュース番組がリソースコンフリクトにより記録できない場合、類似するニュース番組の記録が提案される。帯域幅が小さくされてオーディオ又はビデオ伝送を行うというシステムによる提案も、伝送の品質が当初の目的の一部である場合は、根底にある目的の変更の例として挙げられる。
【００２４】更に、将来の利用上のコンフリクトを最小限にするために、ネットワーク及び／又はそのリソースの変更又は拡張に対する提案を考え出すことも可能である。このような提案は、例えば、特定の種類の利用上のコンフリクトが繰り返し観察され、このコンフリクトは更なるリソースを追加するか又はネットワークを再構成することによって回避されるという事実に基づいている。
【００２５】更に、本発明の方法は、利用上のコンフリクトを予想することにより対処する方法も展開することができる。特に、この場合、第２のアプリケーションによるリソースの要求は単に予測される要求であり、この予測は、例えば、学習されたユーザプロファイルに基づいている。その場合、第２の要求の結果予想されるコンフリクト状況は、第１のリソースの要求を実行する際に既に考慮に入れられ、可能な限り解決されるか又は事前に回避される。
【００２６】本発明は更に、デジタルネットワーク、特に、家庭内デジタルネットワークに関連する。このネットワークは、アプリケーション、リソース管理システム、メディエータモジュールがその上で実行される少なくとも１つのデータ処理ユニットを含む。メディエータモジュールは、上述したような種類の方法を行うことができるよう設定される。ネットワークは更に、データ処理ユニットに接続されるデータベースを含み、ネットワークのトポロジー、リソース、及び、接続に関する情報、ネットワークにおけるデータストック、及び、サービスプロバイダ及び放送局から利用可能なサービスに関する情報、及び、デフォルトの及び／又は学習したユーザプロファイル及びユーザデータに関する情報を含むことが好適である。最後に、ネットワークは、データ処理ユニットに接続され、且つ、ユーザとのやり取りを可能にする少なくとも１つのユーザインタフェースを含む。
【００２７】
【発明の実施の形態】本発明を、図面に示される実施例を参照しながら更に詳細に説明するが、本発明は以下に制限されないものである。
【００２８】図１にその例を示す家庭内デジタルネットワーク（ＩＨＤＮ）では、様々なアプリケーションがリソース（ユニット及びネットワークリソースの両方）を獲得するために競い合う。時として特定の動作を行うためのユーザからの要求は、既存のリソースを使用して実現できない場合がある。システムは、ユーザに拒絶を単に伝えるのではなく、現在の要求をあれこれと変更することによって妥協のソリューションを提案し、その提案を実行する。このようなタイプのユーザサポートの動機は、アナログＡ／Ｖシステム又は個々のＰＣと比較した際のＩＨＤＮの複雑さにある。これらのシステムとは対照的に、アプリケーションとリソース間の相関関係はユーザにとって不明瞭な場合があるので、ユーザは自分自身でソリューションに到ることができない。アナログＡ／Ｖ分野からの例を挙げるに、ビデオレコーダＶＣＲが既に何かを記録していて、ユーザが他の記録を望む場合は、ＶＣＲデックに対するリソースコンフリクトは明らかであり、ユーザが妥協することにより（記録を延期にするか、又は、記録しない）解決可能である。ＩＨＤＮでは、同様のコンフリクトはより微妙でユーザが把握することができない場合がある。従って、例えば、幾分「動作がたくさん詰まった」ビデオシーケンスのＭＰＥＧ符号化の結果もたらされる異なるデータ転送速度により、２つのカレントの同時捕捉が可能であるか否かに影響が及ぼされる。可能なソリューションもむしろより複雑で、例えば、ビデオ帯域幅を減少するよう記録するといったことが挙げられる。
【００２９】更に、家庭における全てのデバイスをネットワークで接続することにより、全ての占有者のアプリケーションが、リソース（例えば、ネットワーク負荷）を獲得するべく互いと直接競い合うことが可能にされる。これまでは、コンフリクトするアプリケーションは、同一のデバイス上で実行するもの（例えば、記録とビデオの再生）のみであったが、ここでは、コンフリクトは完全に異なるアプリケーション間（例えば、ウェブダウンロードとビデオ記録）でも起きるようになり、従って、異なるユーザからの要求間のコンフリクトの頻度は非常に高くなる。ここでは、ユーザは、時としてＩＨＤＮからのサポートを必要とするが、これは単に、自分の要求と競合している要求を出している別のユーザが不在なので、システムは、アドバイザリ的な役割も果たさなければならないからである。例えば、理想的なソリューションは、不在のユーザのダイアリから、そのユーザはいずれにしても、現在ウェブからダウンロードされているビデオは翌日にしか見ることができないことを認識し、認識した後、ダウンロードを数時間延期することを提案することである。従って、本発明のシステムは、不在のユーザの要求を絶対に拒否せず、全てのユーザが承諾できるソリューションが見つかるまで可能な代替案を捜し求めることを目的とする。
【００３０】この目的は、いわゆるメディエータシステムを有するネットワークによって達成される。このメディエータシステムは、図１を参照するに以下の構成要素を含む。
−既存のリソース（バスライン、ネットワークノード、データ処理ユニット、入力／出力ユニット、電話サービス等）を管理するリソース管理システム３と、−メディエータ１と、−コンテンツ代替案、アプリケーションカタログ、ユーザの好み及び情報等を有するデータベース４と、−ユーザと情報交換するためのユーザインタフェース６と、−学習的（ヒューリスティック）に、また、適切な場合には人工知能の方法を使用してコンパイルされることが好適である中央メディエーションアルゴリズム５と、−様々なアプリケーション２、２´を含む。
【００３１】列挙し図１に示す構成要素は少なくとも論理的な形式で存在するが、実際の実施では様々に組み合わされていてよい。
【００３２】メディエータシステムは、他の場所でも使用される既存のユニット（ＳＴＢ、若しくはＰＣ）上のソフトウェアとして存在し得、その場合、連続的に入手可能である、又は、単一のユニットとしてネットワークに組み込まれる必要がある。単一のユニットとしてネットワークに組み込まれるという後者の場合、メディエータシステムはデータベース４を別のユニット（ホームアーカイブ等）に格納し得る。
【００３３】メディエーションの機能的な手順は以下の通りである。
【００３４】−アプリケーション２は、リソース管理システム３に対し要求を行うが、この要求は実現することができない。その場合、アプリケーション２は、メディエータ１に問合せをする。問合せをすることによって、アプリケーション２はメディエータ１に、実際のリソース要求だけでなく、所望のデータフローチャートの形式（即ち、例えば、コンテンツ「ＣＮＮ」を有する情報源が、位置、寸法、ビデオ品質等といった特定の特徴を有するシンク（ディスプレイ）に接続されることを記述するデータ構造）である根底にある目的の一般的な記述も与える。
【００３５】−メディエータ１は、リソース管理システム３、影響を受けている別のアプリケーション２´、データベース４、及び、ユーザインタフェース６から存在するコンフリクトに関する更なる情報を得る。メディエータ１は、例えば、リソース管理システム３からは、関心のリソースを現在使用しているアプリケーションに関する情報を、このアプリケーションからは、このリソースに支援されて現在実行されているデータフローチャートを、データベース４からは、影響を受けている両方のユーザのユーザプロファイルを、そして、ユーザインタフェース６からは、プロファイルにはまだ設定されていない調節値を得る。メディエータ１は次にこれらの情報を中央メディエーションアルゴリズム５に渡す。
【００３６】−メディエーションアルゴリズム５は、代替のソリューションに達するよう試みる。このためにメディエータ１は更なる情報を取出しする場合もある。これは最初に供給されたものではなく、また、上述した他のエンティティから再度抽出することができる。これは、情報を走査するために一般的に決められる記述言語によって実行されることが好適である。特に、メディエータ１に向けられる１つの可能なクエリーとしては、提案したソリューションに対するユーザの承諾に関するものであり、これは、ユーザインタフェース６によって試験される。
【００３７】−メディエーションアルゴリズム５が全ての要求一式を満足するソリューションを見つけた場合、アルゴリズム５はそのことをメディエータ１に伝える。この通信は、例えば、影響を受けている各アプリケーションに対するデータフローチャートの形式をとり、「コンテンツＣＮＮを有する情報源」という一般的な要求は、実際の名前が付けられたリソースによって置換される。同時に、どの順序でアプリケーション２、２´が、閉塞されることなく現在使用されているリソースから新しいリソースへ切替えることができるか（マイグレーション・パス）も記載される。（閉塞がある場合は、アプリケーション２は、ソリューションに応じて、リソースＡを獲得するが、このことは、ソリューションによるリソースがアプリケーション２´から解放される前に試みられる。）単純なマイグレーション・パスがない場合、アルゴリズムは更に「迂回路（diversion）」を指定することができる。即ち、「アプリケーション２は、最初に少しの間全てのリソースを解放しなければならない。なぜなら、解放しなければ、多数のアプリケーション間で循環する依存性が存在してしまうからである」に従って指定することができる。このようなマイグレーション時における迂回路の必要性は明らかに、必要である場合には、ソリューションを評価する際にはアルゴリズムによって考慮に入れられなければならない。というのは、例えば、このような迂回路は、例えば、放送番組の記録が関連する場合、中断を引き起こす場合があり、このことをユーザが承諾できない場合があるからである。
【００３８】−次にメディエータ１は、特定のマイグレーション・パスに従ってそれらのリソースの使用を変更するようアプリケーション２、２´に呼び掛けする責任がある。
【００３９】以下に示す要求に対する変更は、原則的に、好適な妥協策に達するために実現可能である：−全体の動作又は動作の一部を延期（一旦、競合する要求が現れると、際立った部分を特に）する。
【００４０】−データ転送速度を遅くする、減少する。より長い時間が必要となることを考慮に入れる。
【００４１】−サービス品質、例えば、ビデオ帯域幅を減少する。
【００４２】−この要求に対して依然として好適である他のリソースに変更する（例えば、他の記憶媒体又はネットワーク経路に切替える）。
【００４３】−アプリケーションを再構成する。例えば、運搬可能な記録媒体への書込みという要求であるにも関わらず、最初にハードディスクに記憶し、次に所望の媒体に転送する。
【００４４】−データ源の種類を変更する。例えば、コンフリクトがある場合、ＤＶＢチューナでコンフリクトがある場合、インターネット放送に切替える。
【００４５】−ユーザにとって重要でない状況において要求を制限する（例えば、スポーツ放送における広告スロット、及び、中断時間の間は記録を行わない。例えば、ニュース番組の「ニュースキャスタ」のシーケンスにおけるデータ転送速度を遅くする）。
【００４６】−代替のコンテンツ又は別のアプリケーションに変更する（例えば、ホームアーカイブが他の機能により使用されているので、ホームアーカイブの記録物が再生できず、同一の試合番組における後続のシーケンスが現在テレビジョンで生中継されている場合、これが、代替として提供される）。
【００４７】−上述した全ての手段及び他の手段を組合わせたもの上述した変更のうちどの変更が実現可能であるかを決定するには、メディエーションアルゴリズムは以下を使用する。
【００４８】−ＩＨＤＮを介するトポロジー及びリソース情報とネットワークにアクセスするためのＩＨＤＮの接続（情報源：リソース管理システム３／データベース４）；
−ＩＨＤＮにおけるデータストック、及び、サービスプロバイダ／放送局から入手可能なサービス（例えば、テレビ番組）に関する情報（情報源：データベース４）；
−直接入力されたユーザの好み及び間接的に生成されるユーザの好み（例えば、特定の俳優、特定のグループなどに対するユーザの好みが、ＴｉＶｏのような機能によって確立される。即ち、「ＴｉＶｏ」は、遠隔制御装置上の「サム・アップ」／「サム・ダウン」キーによる格付け、及び、これらの格付けと、俳優、主題等といった放送局によって送信される番組の特徴に関するメタ情報間の相関関係の評価である。この機能は拡張されて、ウェブページといった他のコンテンツを含み、１つのウェブサイトで経過した時間を評価基準として組み込むことが可能である）（情報源：データベース４）；
−ユーザとのやり取り。これはローカル的に実現可能であるだけでなく、ＳＭＳ等を介した質問によっても可能である（情報源：ユーザインタフェース６）；−ユーザに関する他の情報。例えば、ダイアリ。（情報源：データベース４）；
−占有されるリソースの現在の使用状況に関する情報。（情報源：他のアプリケーション２、２´）；最適なコンフリクト解決を識別する可能な方法は以下の通りに実行されうる。
【００４９】１．既存のデータフローチャートオペレーションが決定され、それにより、コンフリクトは改善され得る。この例としては、１つのノードをもう１つのノードに置換すること（例えば、もう１つのノードに切替えること）、ノードにおけるパラメータを変更すること（例えば、サービス品質の引き下げ）、又は、チャート全体を変更すること（例えば、後の時間まで延期する）、又は、追加部をチャートに挿入すること（例えば、別のデータ担体にデータを暫定的に記憶する）が挙げられる。
【００５０】２．データフローチャートのどの部分がコンフリクトしているのかが正確に決められる。つまり、例えば、２つの要求がユニットＸに時間間隔Ｙに亘って関連することが正確に決められる。
【００５１】３．基本的に実現可能な動作から、選択は、コンフリクトに関連のある動作を中心に行われる。
【００５２】４．これらの動作のそれぞれは特定のカテゴリに分類され、カテゴリは、この動作によって良好な妥協案を見つけ出す可能性、別の質問をユーザにしなければならないか否か等を記述する。従って、例えば、多くの動作は更に他の要求によって新しいコンフリクトに導くが、その場合、より厳密な試験が必要となる。この段階において、アルゴリズムに対し既に利用可能な情報のみを使用する（これは、例えば、その動作に必要なリソースが使用されていることは知られておらず、従って、この動作は、「更なる情報を必要とするが、その場合、良好なソリューションとなりうる」というカテゴリに分類されることを意味し得る）。
【００５３】５．所定の手順において（好ましくは、ユーザのプロファイルに依存して）、より厳密な試験が、暫定的なソリューションのカテゴリ毎に行われ、最終的には良好な提案が見つけ出される。この為に、各カテゴリにおいて次々と提案されるソリューションはより厳密に試験される。これは、例えば、メディエータから更なる情報を要求することにより厳密に試験される。この情報に基づいて、最終的な評価が可能であるか、又は、提案されるソリューションが別のソリューションのカテゴリにマイグレートする。「最も満たされる」カテゴリからのソリューションが処理され、最後には、提案は「問題解決」のカテゴリにシフトする。
【００５４】６．必要に応じて、承諾可能な提案を見つけた後も検索を続けることが可能である。これは、例えば、ユーザが１つのソリューションのためにどれくらい待つことができるかに依存する。最適なソリューションを「落ち着いて」検索することができるよう１つの妥協案が最初に実施されることもある。
【００５５】既存のリソース管理及びスケジューリングシステムとは対照的に、上述した方法は、ＩＨＤＮへのリソース要求は、ユーザ側の実際の（より抽象的な）要望の不明確なイメージしか表さないという事実を考慮に入れる。ユーザ側の実際の要望とは、例えば、ユーザが夜遅く帰ってきたときに、スポーツニュースが包括的に伝えられることであるとする。このことは最初に、ユーザインタフェース６を介して要求をプロンプトさせ、対応するアプリケーション２´（及び、任意のコインシデンス、及び、システム及びユーザ側の専決）に、チャンネルＸからのスポーツニュースを、２０：００にマシーンＡのハードディスク上に記憶させる。このマッピングは決して明確ではないが、その不明確さはコンフリクトがある場合に考慮されるべきである。あるユーザは、スポーツニュースが２１：００にチャンネルＹから記録され、地元のスポーツフェスティバルからの特別の放送が２１：３０に地元の放送局から記録され、また、マシーンＡではなくマシーンＢに記録され、また、全体のデータ量を少なくするために、その特別放送のうち画面に「ニュースキャスタ」が現れている部分のみが顕著にピクチャ品質が下げられて記憶されても満足のゆくときもある。
【００５６】上述した本発明は、代替のソリューションを識別し、そのようなソリューションを使用することが可能なシステムを可能にする。
【００５７】システムのもう１つの利点は、リソースコンフリクトがある場合に、「古い」アプリケーションが単に原則的に優先されているわけではない点である。リソース管理用の一般的な既存のアルゴリズムでは、リソース障害を解決するために、新しい追加の要求の変更しか考慮しない。一方で、上述した取組み方法では、コンフリクトが発生した場合、全ての存在している要求及び新しい要求を同じように考慮に入れるので、可能なソリューションの範囲をかなり広げ、良好な結果へと導く。
【００５８】以下に、上述した方法の可能な拡張例を示す。
【００５９】−メディエータ１は、解決されたコンフリクトから学習することができる。例えば、過去に良好な結果を与えたソリューションカテゴリはより高く格付けされ、典型的なコンフリクトは分類されて「見本ソリューション」等が与えられる。
【００６０】−メディエータ１は、結果としてのコンフリクトを処理することにより、例えば、ユーザに入手すべき新しいハードウェア、ユーザのＩＨＤＮの再構成方法、又は、サービスプロバイダにより提供される加入すべき追加のサービスに関する提案を提供する。
【００６１】−ＴｉＶｏのような機能によってメディエータ１は、想定される将来の要求を予想するために、自分自身で任意のアプリケーションをスタートすることが可能である。
【００６２】−メディエータ１は、コンフリクトが発生する前にコンフリクトを予見しようと試み、コンフリクトを回避するか又は必要な追加の情報を収集することが可能である（例えば、「この番組を記録することをお望みになる時間帯には、Ｘの好きなチームのサッカーの試合があります。Ｘはこの試合を確実に観戦することを望むでしょう。あなたの希望の番組を翌日の再放送で記録してもよいでしょうか」とユーザに聞く）。このためには、メディエータ１は、可能である場合は、例えば、予防策として所望のリソースをフリーにしておくために自発的にアルゴリズム５を始動することができる。このために、メディエータ１は影響を受けているアプリケーションに対するデータフローチャートと、単に所望のリソースの要求のみから構成されるアーティフィシャルのデータフローチャートとを、このチャートに対し任意の種類の変更は問題ないという情報とともに、アルゴリズム５に提示する。
【００６３】−メディエータ１は、例えば、コンフリクトが発生したときに不在であったユーザに対し、サービス品質が低くされて記録が行われたことを謝罪する「お詫びの手紙」を「知らせ（ポスティングし）」、メディエータ１の決定に不満であったユーザを留意することにより次回の決定の際にはそのことをより考慮に入れる等を行うことにより「スケープゴート」的な役割を担う。
【図面の簡単な説明】
【図１】本発明の家庭内ネットワークの構成要素を示す図である。
【符号の説明】
１ メディエータ
２、２´ アプリケーション
３ リソース管理システム
４ データベース
５ 中央メディエーションアルゴリズム
６ ユーザインタフェース
【特許請求の範囲】
【請求項１】 第１の目的のために第１のアプリケーションにより使用されるリソースが、第２の目的のために第２のアプリケーションによって要求されるといったデジタルネットワーク、特に家庭用デジタルネットワークにおける利用上のコンフリクトに対処する方法であって、上記第１のアプリケーション及び／又は上記第２のアプリケーションによる上記リソースの要求に対する変更が捜し求められ、上記変更は、上記第１の目的及び上記第２の目的を達成可能にすることを特徴とする方法。
【請求項２】 上記リソースの要求に対する上記変更は、上記要求の完全な又は部分的な延期と、帯域幅及び／又はアクセスのデータ転送速度といったアクセスパラメータの変更と、別の等価のリソースへのシフトと、中間局として機能するリソースへのシフトとを含むことを特徴とする請求項１記載の方法。
【請求項３】 上記目的はデータフローチャートとして表され、上記データフローチャートは好適には、要求されるデータ及びこれらのデータの所望の目的に関する情報を含むことを特徴とする請求項１又は２記載の方法。
【請求項４】 上記要求に対する変更を探索する際に、既知のユーザプロファイル及び／又は適応により学習されるユーザプロファイルが使用され、上記ユーザプロファイルは、上記ユーザのダイアリ、及び／又は、ネットワーク上で利用可能な特定のサービスに対する上記ユーザの好みに関する情報を特に含むことを特徴とする請求項１乃至３のうちいずれか一項記載の方法。
【請求項５】 ユーザは、追加の情報、及び／又は、見つけ出された上記変更の承認又は拒絶が求められることを特徴とする請求項１乃至４のうちいずれか一項記載の方法。
【請求項６】 上記見つけ出された変更を実行する順序も決定されることを特徴とする請求項１乃至５のうちいずれか一項記載の方法。
【請求項７】 上記目的を変更することなく上記要求に対する変更が見つからない場合は、少なくとも１つの目的の変更が提案されることを特徴とする請求項１乃至６のうちいずれか一項記載の方法。
【請求項８】 将来の利用上のコンフリクトを最小限にするために、上記ネットワーク、及び／又は、上記ネットワークのリソースの変更に対する提案はまとめられることを特徴とする請求項１乃至７のうちいずれか一項記載の方法。
【請求項９】 上記第２のアプリケーションによる要求は、単に予測される要求に過ぎないことを特徴とする請求項１乃至８のうちいずれか一項記載の方法。
【請求項１０】 アプリケーション、リソース管理システム、及び、メディエータモジュールがその上で実行される少なくとも１つのデータ処理ユニットと、上記データ処理ユニットに接続されるデータベースと、上記データ処理ユニットに接続される少なくとも１つのユーザインタフェースとを含み、上記メディエータモジュールは、請求項１乃至９のうちいずれか一項記載の方法を実行することができるよう設定される、特に家庭用ネットワークであるデジタルネットワーク。
【請求項１】 第１の目的のために第１のアプリケーションにより使用されるリソースが、第２の目的のために第２のアプリケーションによって要求されるといったデジタルネットワーク、特に家庭用デジタルネットワークにおける利用上のコンフリクトに対処する方法であって、上記第１のアプリケーション及び／又は上記第２のアプリケーションによる上記リソースの要求に対する変更が捜し求められ、上記変更は、上記第１の目的及び上記第２の目的を達成可能にすることを特徴とする方法。
【請求項２】 上記リソースの要求に対する上記変更は、上記要求の完全な又は部分的な延期と、帯域幅及び／又はアクセスのデータ転送速度といったアクセスパラメータの変更と、別の等価のリソースへのシフトと、中間局として機能するリソースへのシフトとを含むことを特徴とする請求項１記載の方法。
【請求項３】 上記目的はデータフローチャートとして表され、上記データフローチャートは好適には、要求されるデータ及びこれらのデータの所望の目的に関する情報を含むことを特徴とする請求項１又は２記載の方法。
【請求項４】 上記要求に対する変更を探索する際に、既知のユーザプロファイル及び／又は適応により学習されるユーザプロファイルが使用され、上記ユーザプロファイルは、上記ユーザのダイアリ、及び／又は、ネットワーク上で利用可能な特定のサービスに対する上記ユーザの好みに関する情報を特に含むことを特徴とする請求項１乃至３のうちいずれか一項記載の方法。
【請求項５】 ユーザは、追加の情報、及び／又は、見つけ出された上記変更の承認又は拒絶が求められることを特徴とする請求項１乃至４のうちいずれか一項記載の方法。
【請求項６】 上記見つけ出された変更を実行する順序も決定されることを特徴とする請求項１乃至５のうちいずれか一項記載の方法。
【請求項７】 上記目的を変更することなく上記要求に対する変更が見つからない場合は、少なくとも１つの目的の変更が提案されることを特徴とする請求項１乃至６のうちいずれか一項記載の方法。
【請求項８】 将来の利用上のコンフリクトを最小限にするために、上記ネットワーク、及び／又は、上記ネットワークのリソースの変更に対する提案はまとめられることを特徴とする請求項１乃至７のうちいずれか一項記載の方法。
【請求項９】 上記第２のアプリケーションによる要求は、単に予測される要求に過ぎないことを特徴とする請求項１乃至８のうちいずれか一項記載の方法。
【請求項１０】 アプリケーション、リソース管理システム、及び、メディエータモジュールがその上で実行される少なくとも１つのデータ処理ユニットと、上記データ処理ユニットに接続されるデータベースと、上記データ処理ユニットに接続される少なくとも１つのユーザインタフェースとを含み、上記メディエータモジュールは、請求項１乃至９のうちいずれか一項記載の方法を実行することができるよう設定される、特に家庭用ネットワークであるデジタルネットワーク。
【図１】
【公開番号】特開２００３−２０３０２６（Ｐ２００３−２０３０２６Ａ）
【公開日】平成１５年７月１８日（２００３．７．１８）
【国際特許分類】
【出願番号】特願２００２−２３７０２８（Ｐ２００２−２３７０２８）
【出願日】平成１４年８月１５日（２００２．８．１５）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｅｌｅｃｔｒｏｎｉｃｓ Ｎ．Ｖ．
【住所又は居所原語表記】Ｇｒｏｅｎｅｗｏｕｄｓｅｗｅｇ １，５６２１ ＢＡ Ｅｉｎｄｈｏｖｅｎ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ
【Ｆターム（参考）】
【公開日】平成１５年７月１８日（２００３．７．１８）
【国際特許分類】
【出願日】平成１４年８月１５日（２００２．８．１５）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｅｌｅｃｔｒｏｎｉｃｓ Ｎ．Ｖ．
【住所又は居所原語表記】Ｇｒｏｅｎｅｗｏｕｄｓｅｗｅｇ １，５６２１ ＢＡ Ｅｉｎｄｈｏｖｅｎ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ
【Ｆターム（参考）】
[ Back to top ]