(57)【要約】先行技術の問題を解決するために、本発明は、簡単に使用され、実装され、拡張されるであろうユーザ・デバイス間の資源共用のための新しい方式を提供している。また、本発明は、資源共用のためのユーザ入力を減らすことを目指す。具体的には、本発明は、ＩＭプロトコル、共用イニシエータ、およびＩＭメッセージを介する委託されるべきタスクの重要情報に関するそのコオペレータに基づく。次に、好ましくは、イニシエータが、コオペレータとの追加の通信後に、委託されるべきタスクのそれぞれについて１つまたは複数のコオペレータを選択する。各タスクについて選択されたコオペレータは、その指名コオペレータと称されることになる。最後に、各コオペレータは、それに委託された１つまたは複数のタスクを処理し、もしあれば、その結果をイニシエータに送り返すことになる。
2011529587.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ・ネットワークにおいて、インスタント・メッセージング・プロトコルに基づいてユーザ・デバイス間で資源を共用する方法であって、共用イニシエータは複数のコオペレータを有し、前記方法が、
ｂ．委託されるべき各タスクについて、共用イニシエータがＩＭメッセージを介してそのタスクに関する１つまたは複数の指名コオペレータに前記タスクを委託するステップと、
ｃ．前記タスクに関する指名コオペレータが前記タスクを処理するステップと、
ｄ．前記タスクに関する指名コオペレータがその結果を前記共用イニシエータに送り返すステップとを備える、方法。
【請求項２】
前記ステップｂの前に、さらに、
ａ．前記共用イニシエータが前記タスクについての１つまたは複数の指名コオペレータを判定するステップを備え、
前記ステップｂがさらに、
前記共用イニシエータが、ＩＭメッセージを介して前記タスクに関する１つまたは複数の指名コオペレータに前記タスクを委託するステップを備える、請求項１に記載の方法。
【請求項３】
前記ステップａがさらに、
ａ１．前記共用イニシエータが各コオペレータの資源情報を取得するステップと、
ａ２．各コオペレータの取得された前記資源情報に従って、前記共用イニシエータが前記タスクについての１つまたは複数の指名コオペレータを判定するステップとを備える、請求項２に記載の方法。
【請求項４】
前記ステップａ１がさらに、
ａ１１．前記共用イニシエータがコオペレータに委託されることになるタスクの重要情報を知らせるステップと、
ａ１２．コオペレータが、各タスクの重要情報に基づいてそれらの資源情報を共用イニシエータに知らせるステップとを備える、請求項３に記載の方法。
【請求項５】
前記ステップａがさらに、
コオペレータが互いに交渉しあい、各タスクについての１つまたは複数の指名コオペレータを判定するステップを備える、請求項１に記載の方法。
【請求項６】
前記ステップｂの前にさらに、
その現在の資源情報に従って、前記共用イニシエータが、その能力を超える１つまたは複数のタスクを判定し、前記１つまたは複数のタスクを委託されるべきタスクと見なすステップを備える、請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
コンピュータ・ネットワークのユーザ・デバイスにおける、ＩＭプロトコルに基づいて他のユーザ・デバイスの資源を共用する第１の共用装置であって、前記ユーザ・デバイスは複数のコオペレータを有し、前記装置が、
委託されるべき各タスクに関して、前記タスクに関する１つまたは複数の指名コオペレータに前記タスクを委託するタスク委託手段と、
前記タスクに関するコオペレータからその結果を受信する結果受信手段とを備える、第１の共用装置。
【請求項８】
前記タスクについての複数のコオペレータの中から１つまたは複数の指名コオペレータを判定する指名コオペレータ判定手段をさらに備え、
前記タスク委託手段がさらに、前記タスクをＩＭメッセージを介して前記タスクに関する判定された１つまたは複数の指名コオペレータに委託する、請求項７に記載の第１の共用装置。
【請求項９】
前記指名コオペレータ判定手段がさらに
委託されるべきタスクの重要情報をコオペレータに知らせる重要情報提供手段と、
コオペレータの資源情報を取得する資源情報取得手段と、
前記タスクの重要情報に従って、前記タスクについての１つまたは複数の指名コオペレータを判定する２次判定手段とを備える、請求項８に記載の第１の共用装置。
【請求項１０】
ローカル・ユーザ・デバイスの現在の資源情報に従って、その能力を超える１つまたは複数のタスクを判定し、判定された前記１つまたは複数のタスクを１つまたは複数の委託されるべきタスクと見なすタスク判定手段をさらに備える、請求項７乃至９のいずれか１項に記載の第１の共用装置。
【請求項１１】
コンピュータ・ネットワークのユーザ・デバイスにおける、ＩＭプロトコルに基づいてローカル・ユーザ・デバイスの資源を別のユーザ・デバイスが共用することを支援する第２の共用装置であって、前記装置が、
ローカル・ユーザ・デバイスが、前記別のユーザ・デバイスの１つまたは複数の委託されるべきタスクに関するコオペレータであり、そして、対応するタスクを処理する責任を負うということを示す委託を、ＩＭプロトコルの対話型メッセージを介して前記別のユーザ・デバイスから受信する委託受信手段と、
前記委託されるべきタスクの各々について１つまたは複数の指名コオペレータを前記別のユーザ・デバイスが判定するのを支援する判定支援手段と、
対応する結果を得るために、委託によって命じられた１つまたは複数のタスクを処理する２次処理手段と、
その結果を前記別のユーザ・デバイスに戻す結果戻し手段とを備える、第２の共用装置装置。
【請求項１２】
前記判定支援手段が、
もう１つのユーザ・デバイスの委託されるべきタスクの重要情報を取得する重要情報取得手段と、
取得された前記重要情報に従って、ローカル・ユーザ・デバイスの資源情報を前記別のユーザ・デバイスに知らせる資源情報報告手段とを備える、請求項１１に記載の第２の共用装置。
【請求項１３】
前記判定支援手段がさらに、
前記重要情報に従って、前記ローカル・ユーザ・デバイスが可能な１つまたは複数のタスクがあるかどうかを判断する判断手段を備え、
前記資源情報報告手段はさらに、前記ローカル・ユーザ・デバイスが可能な１つまたは複数のタスクがある場合に、前記別のユーザ・デバイスに前記ローカル・ユーザ・デバイスの資源情報を報告する、請求項１２に記載の第２の共用装置。
【請求項１４】
前記判定支援手段がさらに、前記タスクについての１つまたは複数の指名コオペレータを判定するために、前記ローカル・ユーザ・デバイスと前記別のユーザ・デバイス以外の他のユーザ・デバイスと交渉する、請求項１２に記載の第２の共用装置。
【請求項１５】
請求項７乃至１０のいずれか１項に記載の、ＩＭプロトコルに基づいて他のユーザ・デバイスの資源を共用する第１の共用装置、および／または、請求項１１乃至１４のいずれか１項に記載の、ＩＭプロトコルに基づいてローカル・ユーザ・デバイスの資源を別のユーザ・デバイスが共用するのを支援する第２の共用装置を備える、コンピュータ・ネットワークにおけるユーザ・デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ・ネットワークにおける資源共用に関し、特に、コンピュータ・ネットワーク内の複数のユーザ・デバイス間のインスタント・メッセージング（ＩＭ）プロトコルに基づく資源共用のための方法および装置に関する。
【背景技術】
【０００２】
インターネットの急速な発展は、人々により多くの資源共用の機会を提供した。異なるユーザ・デバイス（たとえば、パーソナル・コンピュータおよびノートブック・コンピュータ）間の資源共用のための既存の技術は以下のとおりである。
【０００３】
・従来のＲＰＣプロトコルおよびＣＯＲＢＡプロトコル
ＲＰＣ（リモート・プログラム・コール）は、それによりユーザが遠隔のコンピュータ資源にアクセスすることができ、下層ネットワーク技術のプロトコルを知る必要がない、一種の技法である。一方、ＣＯＲＢＡは、ＣＯＭ、ＪＡＶＡと同等の分散技法である。ＣＯＲＢＡは位置に基づく分散枠組みおよびプロトコルを提供する、即ち、ユーザは、ＩＩＯＰを用いて通信のために、予めそのサービスの位置に束縛され、関連ＯＲＢデータベースを所有しなければならない。さらに詳しくは、ウェブサイト：ｈｔｔｐ：／／ｗｗｗ．ｃｏｒｂａ．ｏｒｇを参照されたい。
【０００４】
ＲＰＣおよびＣＯＲＢＡは、ユーザに遠隔コンピュータ資源にアクセスする方法を提供する。しかし、これらのプロトコルは、ユーザがプログラマ（たとえば、ｊａｖａプログラミング）のレベルであることを必要とし、そのプログラマがプログラムする前に詳細なプログラミング・インタフェース、資源容量情報などを知っている必要がある。したがって、これらのプロトコルはあまり一般的ではない。
【０００５】
・モバイル・エージェント（ＭＡ）
ＭＡは、それ自体で決定し、ノード間を移動してある特定のタスクを請け負うことができるプログラムである。実際には、それは、その走行場所および時間を選択し、特定の状況に従ってその実行を中断し、回復のために別のコンピュータへと移動し、単独で時間内に関連結果を送り返すことができる、ネットワーク計算である。
【０００６】
残念ながら、ＭＡは異なるコンピュータ間のコードの移動に依存し、必然的に深刻なセキュリティ問題を引き起こすことがある。その理由は以下のとおりである。１）コードが、あるコンピュータから別のコンピュータに移動するときに傍受されることがある、２）移動の処理中に、コードが改ざんされ、別のコンピュータのソフトウェアおよびオペレーション・システムに損害をもたらすことがある。
【０００７】
詳しくは、ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｍｏｂｉｌｅ＿ａｇｅｎｔを参照されたい。
【０００８】
・グリッド・コンピューティング
グリッド・コンピューティングは、その中で分散計算および資源共用が異種システム間で行われる、枠組みを設定する。しかし、この枠組みは、資源を結合し管理するために仮想スーパコンピュータを必要とし、下層グリッド・システムが非常に複雑で、ユーザはそのプログラム設計の特定の命令に従わなければならない。
【０００９】
グリッド・コンピューティングについて詳しくは、ｈｔｔｐ：／／ｗｗｗ．ｇｌｏｂｕｓ．ｏｒｇ／ｔｏｏｋｉｔ／ｄｒａｆｔ−ｇｇｆ−ｏｇｓｉ−ｇｒｉｄｓｅｒｖｉｃｅ−３３＿２００３−０６−２７．ｐｄｆを参照されたい。
【００１０】
・ウェブベースの委託サービス
現在、インターネット上にいくつかのウェブベースの委託サービスが存在する。たとえば、様々なタイプの元のファイルをＰＤＦ形式のファイルに変換するサービスが、ウェブサイト（ｈｔｔｐ：／／ｗｗｗ．ｅｘｐｒｅｓｓｐｄｆ．ｃｏｍ）上で提供されている。図１は．ＤＯＣ文書を．ＰＤＦ文書に変換するサービスについてのウェブページを示す。そこでは、ユーザはボタンＢ１「ブラウズ」をクリックしてダイアログ・ボックスを起動することができ、そこで、彼または彼女はローカル・メモライザまたはアクセス可能なネットワーク・メモライザに保存された．ＤＯＣ文書を選択することができる。さらに、対応する．ＰＤＦ文書をユーザに送り返すために、このウェブページは入力ボックスＢ２も備え、そこでユーザは彼／彼女が．ＰＤＦ文書を受信するのに使用したい電子メール・アドレスを入力する必要がある。前述の操作を完了した後、ユーザはボタンＢ３「ＰＤＦに変換！」をクリックする。それにより、選択された．ＤＯＣ文書がそのウェブサイトのサーバに提出され、ある特定のソフトウェア、たとえばＡｄｏｂｅ  ＰＤＦ、によって．ＰＤＦ形式に変換されることになる。最後に、．ＰＤＦ文書が、ユーザによって選択された電子メール・アドレス、たとえばａｂｃｄｅｆ＠ｙａｈｏｏ．ｃｏｍ．ｃｎ  に送信されることになる。
【００１１】
しかし、この解決策はウェブ・ブラウザ（たとえば、ＭＳ  Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ）のみに基づく。ユーザはまた、入力操作を何度も行わなければならない。さらに、それは単一サーバと単一ユーザ・デバイスの間の資源共用のみを実現し、複数のユーザ・デバイス間の資源共用はまだ実現されることができない。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】ｈｔｔｐ：／／ｗｗｗ．ｃｏｒｂａ．ｏｒｇ
【非特許文献２】ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｍｏｂｉｌｅ＿ａｇｅｎｔ
【非特許文献３】ｈｔｔｐ：／／ｗｗｗ．ｇｌｏｂｕｓ．ｏｒｇ／ｔｏｏｋｉｔ／ｄｒａｆｔ−ｇｇｆ−ｏｇｓｉ−ｇｒｉｄｓｅｒｖｉｃｅ−３３＿２００３−０６−２７．ｐｄｆ
【非特許文献４】ｈｔｔｐ：／／ｗｗｗ．ｅｘｐｒｅｓｓｐｄｆ．ｃｏｍ
【発明の概要】
【００１３】
前述の問題を解決するために、本発明の目的は、コンピュータ・システム内の複数のユーザ・デバイス間の資源共用のための新しい方式を提供することである。この方式は、簡単に使用されることができ、ユーザの入力を低減してさらに大幅に自動化を実現する利点をもつはずである。特に本発明は、ＩＭプロトコルに基づく。
【００１４】
以下、他のユーザ・デバイスの資源を使用することになるローカル・ユーザのユーザ・デバイスを共用イニシエータ（「イニシエータ」）という。そして、このローカル・ユーザの仲間のユーザ・デバイスをそのイニシエータのコオペレータ（ｃｏｏｐｅｒａｔｏｒ）という。
【００１５】
本発明によれば、イニシエータは、ＩＭメッセージを介して委託される用意ができているタスクの重要情報をそのコオペレータに知らせる。次に、好ましくは、イニシエータが、マルチユーザ・デバイス対話を用いて委託されるべきタスクのそれぞれについて１つまたは複数のコオペレータを選択する。各タスクについて、選択された１つまたは複数のコオペレータを、対象タスクに関する１つまたは複数の指名コオペレータ（「１つまたは複数の指名コオペレータ」）という。最後に、各コオペレータがそれに委託された１つまたは複数のタスクを処理し、もしあれば、その結果をイニシエータに送り返すことになる。
【００１６】
前述の目的を達成するために、本発明の第１の態様によれば、コンピュータ・ネットワーク内に、インスタント・メッセージング・プロトコルに基づくユーザ・デバイス間の資源共用の方法が提供される。そこでは、共用イニシエータはいくつかのコオペレータをもち、その方法は、ｂ．委託されるべき各タスクについて、共用イニシエータがそのタスクをＩＭプロトコルの対話型情報を介して前記タスクに関する１つまたは複数の指名コオペレータに委託するステップ、ｃ．そのタスクに関する各指名コオペレータがタスクをそれぞれ処理するステップ、ｄ．そのタスクに関する指名コオペレータが結果を前記共用イニシエータに送り返すステップ、を備える。
【００１７】
本発明の第２の態様によれば、コンピュータ・ネットワークの複数のコオペレータをもつユーザ・デバイス内に、ＩＭプロトコルに基づく他のユーザ・デバイスの資源を共用するための第１の共用装置が提供される。第１の共用装置は、１）委託される各タスクに関する、タスクを前記タスクに関連する１つまたは複数の指名コオペレータに委託する、タスク委託手段と、２）そのタスクに関するコオペレータから結果を受信するための結果受信手段とを備える。
【００１８】
本発明の第３の態様によれば、コンピュータ・ネットワークのユーザ・デバイス内に、別のユーザ・デバイスがＩＭプロトコルに基づいてローカル・ユーザ・デバイスの資源を共用するのを支援するための、以下を備えることを特徴とする、資源共用のための第２のデバイスが提供される：そのローカル・ユーザ・デバイスが前記別のユーザ・デバイスの１つまたは複数の委託されるべきタスクに関するコオペレータであり、対応するタスクを処理する責任を負うことを示す委託をＩＭプロトコルの対話型メッセージを介して別のユーザ・デバイスから受信するための委託受信手段と、別のユーザ・デバイスがその委託されるべきタスクのそれぞれについて１つまたは複数の指名コオペレータを判定するのを支援するための判定支援手段と、対応する帰結を得るためにその委託によって順序付けられた１つまたは複数のタスクを処理するための２次処理手段と、前記別のユーザ・デバイスに結果を戻すための結果戻し手段。
【００１９】
本文中のコンピュータ・ネットワーク内のユーザ・デバイスは、デスクトップ・パーソナル・コンピュータ（ＰＣ）、ノートブックＰＣ、ポータブル・デジタル・アシスタント（ＰＤＡ）、インテリジェント携帯電話、ネットワーク・サーバ、および他の端末機器を含むがこれらに限定されない、他のデバイスと通信するためにＩＭプロトコルをサポートすることができるすべての種類のデバイスを包含することが当業者には明らかである。
【００２０】
本発明によって提供される技術的解決策が、サーバ／クライアント・モード（Ｓ／Ｃ）またはピア・トゥ・ピア（Ｐ２Ｐ）に基づくネットワークに適用できることも、当業者には明らかである。
【００２１】
前述の方法および装置は、ユーザ・デバイスがＩＭプロトコルに基づいて資源を共用することを可能にする。それらは簡単に実装および拡張され、したがって、プロのユーザは、より強力なアプリケーション手順またはサービスを開発するときに、従来の方法またはアーキテクチャによって制限されないことになる。
【００２２】
本発明の他の特徴、態様、および利点は、図面を助けとして以下の記述を読むことによってさらに明らかとなろう。
【図面の簡単な説明】
【００２３】
【図１】．ＤＯＣ文書を．ＰＤＦ文書に変換するサービスを提供するｈｔｔｐ：／／ｗｗｗ．ｅｘｐｒｅｓｓｐｄｆ．ｃｏｍ／のウェブページを示す図である。
【図２】本発明の好ましい一例による、ＩＭプロトコルに基づくコンピュータ・ネットワークを示す図である。
【図３】本発明の好ましい一例による、コンピュータ・ネットワーク内のＩＭプロトコルに基づくユーザ・デバイス間の資源共用のための系統的方法の流れ図である。
【図４】本発明の好ましい一例による、ＩＭプロトコルに基づく他のユーザ・デバイスの資源を共用するための、コンピュータ・ネットワークのユーザ・デバイス内の、第１の共用装置の構成図である。
【図５】本発明の好ましい一例による、別のユーザ・デバイスがＩＭプロトコルに基づいてローカル・ユーザ・デバイスの資源を共用するのを支援するための、コンピュータ・ネットワークのユーザ・デバイス内の、第２の共用装置の構成図である。
【図６】本発明を実装するアプリケーション手順を示す図である。
【発明を実施するための形態】
【００２４】
これらの図において、同一のまたは同様の参照番号は同一のまたは同様のステップ機能または手段機能を参照する。
【００２５】
図２は、本発明の好ましい一例による、ＩＭプロトコルに基づくコンピュータ・ネットワークを示す。そこでは、ネットワークは、ユーザ・デバイス１（ＰＤＡ）、ユーザ・デバイス２（デスクトップＰＣ）、ユーザ・デバイス３（ノートブックＰＣ）、ユーザ・デバイス４（アクセス可能なネットワーク・サーバ）、およびユーザ・デバイス５（ＰＤＡ）を備え、それらのすべてはインターネットまたはイントラネットを介した通信を目的とする。本発明を実装するために、ＭＳＮメッセンジャ（商標、以下同）、ＱＱ（商標、以下同）、Ｓｋｙｐｅ（商標、以下同）などのある種のＩＭソフトウェアが示された図の中のあらゆるユーザ・デバイスにインストールされている。これらの種類のソフトウェアは共通の特徴をもち、ユーザ・デバイス上にまたはサービス・プロバイダによって提供されるネットワーク・デバイス上に仲間のリストがある。
【００２６】
この例によれば、Ｓｈａｎｅはユーザ・デバイス１をもち、Ａｒｔｈａｓはユーザ・デバイス２をもち、Ｋｙｌｅはユーザ・デバイス３をもち、Ａｌｕｃａｒｄはユーザ・デバイス４をもち、Ｊｅｎｎｉｆｅｒはユーザ・デバイス５をもつ。そこでは、Ｓｈａｎｅはイニシエータ、すなわちユーザ・デバイス１、のローカル・ユーザであり、Ａｒｔｈａｓ、Ｋｙｌｅ、Ａｌｕｃａｒｄ、およびＪｅｎｎｉｆｅｒはすべてＭＳＮメッセンジャ（以下「ＭＳＮ」（商標、以下同）という）上でＳｈａｎｅの仲間である。したがって、ユーザ・デバイス２から５はすべてユーザ・デバイス１のコオペレータである。
【００２７】
好ましくは、各ユーザ・デバイスはそれぞれその資源リストを保持する。概して言えば、このリストは以下の情報を備える：ＣＰＵ、揮発性メモリ、オペレーション・システム、インストールされたソフトウェア、およびそのインストールされたソフトウェアの主要な機能。任意選択で、前述の情報の１つまたは複数の項目が中央のまたはいくつかの分散されたデータベース様のネットワーク・サーバに格納されることができ、他のユーザ・デバイスのアクセスを目的として対応するユーザ・デバイスによって更新されることができる。本発明の特別な一例によれば、ＣＰＵ、揮発性メモリ、ＯＳ、インストールされたソフトウェア、およびそれらの機能などの情報はすべてかかるデータベース様のネットワーク・サーバに格納されることができる。格納された情報は確実にアクセス可能でなければならず、各ユーザ・デバイスはその情報を更新するおよび他のユーザをそれにアクセスさせ読ませる責任を負う。資源情報の前述のリストの機能については以下の文脈で詳しく説明する。
【００２８】
ＣＰＵの計算能力および揮発性メモリのバッファリング能力が通常はユーザ・デバイスの計算速度において重要な役割を果たすことが、当業者には明らかである。これらの資源（ＣＰＵ、揮発性メモリなど）が１つまたは複数のタスクの要件に比べて非常に限られている場合、それらは使い尽くされてしまうことがある。ユーザ・デバイスの記憶能力が、特にそのソフトウェアがより多くの記憶空間を占有するとき、ユーザ・デバイスにインストールされることができるソフトウェアの数およびサイズを制限し得ることもまた、当業者には明らかである。
【００２９】
異なるユーザ・デバイスは異なる資源状況をもち得る。ユーザ・デバイス１（ＰＤＡ）を例に取る。その次元の制約により、そのＣＰＵの周波数は４００ＭＨＺから６００ＭＨＺに及ぶことがあり、揮発性メモリは、優れたＰＣまたはノートブックＰＣと比べてごく僅かな、６４ＭＢまたは１２８ＭＢであることがある。一方で、ＰＤＡ不揮発性メモリに関する記憶能力の不利は受け入れ可能となり得る。しかし、大量の強力なソフトウェアが莫大な記憶空間を要求し、したがって、それは、ＳＤ、ＣＦ、ＭＳ−ＰＲＯ、ＭＳ−ＤＵＯなどのメモリ・カードに主に依存するＰＤＡを圧迫することになる。
【００３０】
前述の分析に基づいて、本発明の好ましい一例が、流れ図と組み合わせて、説明される。図３を参照すると、本発明の好ましい一例によるコンピュータ・ネットワーク内のＩＭプロトコルに基づくユーザ・デバイス間の資源共用の方法の系統的な流れ図がある。その好ましい例が、図２とあわせて図３を参照して説明される。
【００３１】
Ｓｈａｎｅが、Ｈ．２６４規格によってコード化された、ユーザ・デバイス１によるＡＶＩ形式の映画をダウンロードする。しかし、ユーザ・デバイス１はＭＰＥＧ４形式でのみビデオを再生することができ、Ｈ．２６４に基づくビデオを再生することができない。したがって、この映画は、ユーザ・デバイス１で再生される前にＭＰＥＧ４形式に変換されなければならない。本発明の一例によれば、ユーザ・デバイス１は、Ｈ．２６４をＭＰＥＧ４に変換するためのインストールされたソフトウェアをもたない。そのとき、Ｓｈａｎｅは、タッチ画面上のボタンをクリックして、彼がこのビデオを見たいことを示す。その形式はユーザ・デバイス１のプレーヤによってサポートされることができないので、以下の状況が存在する。
【００３２】
−ユーザ・デバイス１のプレーヤが起動されるが、ＡＶＩビデオのファイル・タイプの識別に失敗する、
−ユーザ・デバイス１上のプレーヤが起動されず、Ｓｈａｎｅは別のソフトウェアを選択して開くように促される。
【００３３】
実際の構成によれば、たとえばプレーヤが起動され、ファイル・タイプを認識できないとき、またはそれがＳｈａｎｅに他のソフトウェアを選択するように促すときなどの、ある特定の瞬間に、本方法は図に示すようにＳ１０に柔軟に入ることができる。
【００３４】
ここで、ビデオをＡＶＩ形式で見るために形式変換が必要である。次にＳ１０で、ユーザ・デバイス１はファイルの多数のビデオ・フレームがＨ．２６４からＭＰＥＧ４に変換される必要があると判定する。もちろん、タスクの数は柔軟に判定されることができる。たとえば、ＡＶＩファイル全体の変換が単一のタスクとして定義されることができ、または、あらゆる単一フレームの変換が１個のタスクとして定義されることができ、または、１組のフレームの変換がそのようなタスクであることができる。この例では、ユーザ・デバイス１はＡＶＩファイルを１０個の同等の部分に分割する。その結果として、１０個のタスクがあり、そのそれぞれが複数のフレームの変換に対応する。特に、それらのうちの１つは、ユーザ・デバイス１にあるプレーヤが変換ファイルを再生するときに確実に機能できるようにするために、ＡＶＩヘッダのＭＰＥＧ４ヘッダへの変換にも対応する。
【００３５】
１０個のタスクが判定されたとき、本方法はＳ１１に入る。
【００３６】
Ｓ１１で、ユーザ・デバイス１は、ＭＳＮメッセージを介して、１０個のタスクの重要情報をそのコオペレータ、すなわちＪｅｎｎｉｆｅｒ、Ａｌｕｃａｒｄ、Ｋｙｌｅ、およびＡｒｔｈａｓのユーザ・デバイス、に送信することになる。その重要情報は、たとえば以下のようなＸＭＬの形態でもよい。
<task type>File Conversion</task type>
<input>H.264</input>
<output><MPEG4></output>
<input data>... </input data>
【００３７】
ここで、第１行はタスクのタイプがファイル変換であることを示し、第２行はファイルの元の形式がＨ．２６４であることを示し、第３行は所望の形式がＭＰＥＧ４であることを示す。そして、第４行は変換されるべき元データを表す。変換のために委託されるデータのサイズが大きくない場合、元データは、重要情報が送信されるときに、前述のようにコオペレータに直接送信されることができることが、当業者には明らかである。この例では、変換データは１０Ｍ或いは１００Ｍのサイズをもち、好ましくは、第４行の「＜ｉｎｐｕｔ  ｄａｔａ＞．．．＜／ｉｎｐｕｔ  ｄａｔａ＞」は、各タスクに対応するデータのサイズのみを表すことができる。各タスクに関する１つまたは複数の指名コオペレータが判定された後に、特定のデータがコオペレータに送信されることができる。もちろん、ネットワーク伝送資源が完全に十分である場合、ユーザ・デバイス１は、１つまたは複数の変換されるべきファイルをその重要情報を提供するときにあらゆるコオペレータに送信することができる。かかるシナリオでは、その後１つまたは複数のタスクを委託するとき、ユーザ・デバイス１は各指名コオペレータにどの１つまたは複数のタスクをそれが委託されたかを伝えさえすればよい。
【００３８】
ここで、ＭＳＮがユーザ・デバイス１上で走っていない場合、このソフトウェアが最初に起動され、次に、ロギングインまたはそれと同様のことを行う。これは本発明の好ましい一例を表し、そこでは、ＭＳＮはオフラインのメッセージの送信も同様にサポートすることができるが、Ｓ１１で、ユーザ・デバイス１がＳｈａｎｅのオンラインの仲間のユーザ・デバイスのみにタスクの重要情報を送信する。もちろん、そのタスクが至急でない場合、ユーザ・デバイス１はその重要情報をＳｈａｎｅのすべてのＭＳＮ仲間のユーザ・デバイスに送信することができ、Ｓ１１を実行するときにすべてのＳｈａｎｅの仲間のユーザ・デバイス（オンラインのものもオフラインのものも含む）の資源情報をユーザ・デバイス１が取得した後に、各タスクの指名コオペレータが判定されることができる。簡潔に、ユーザ・デバイス２および３のみがユーザ・デバイス１のコオペレータとして図３に示されている。
【００３９】
次に、本方法は、ユーザ・デバイス２および３のそれぞれで任意選択のおよび好ましいステップＳ２０／Ｓ３０に入る。そこでは、ユーザ・デバイス１の委託されるべき１０個のタスクの重要情報を取得した後に、ユーザ・デバイス２および３は、それら自体の資源情報をそれぞれ確認する。詳しくは、それらは、それら自体またはネットワーク・サーバによって保持される資源情報リストにアクセスすることによって、それらがＨ．２６４ファイルをＭＰＥＧ４に変換することができるかかるソフトウェアをもっているかどうかを知り、ＯＳ、ＣＰＵ周波数、揮発性メモリの容量などの情報を取得することができる。前述の情報に基づいて、ユーザ・デバイス２および３はそれぞれ、それらが１０個のタスクのうちの１つまたは複数のタスクを処理する能力があるかどうかを判定することになる。
【００４０】
この例では、変換のための前記ソフトウェアは、ユーザ・デバイス２と３の両方にインストールされている。さらに、ユーザ・デバイス２および３のそれぞれは、過去の経験に基づいてそれがそのタスクのうちの少なくとも１つについて受け入れることができると判断する。たとえば、かかるデバイスが以前に同様のビデオ変換を実行したとき、占有されたＣＰＵ、揮発性メモリの情報が保管されていた。より高いＣＰＵ周波数およびより大きな揮発性メモリをもつデバイスのＣＰＵおよび揮発性メモリがひどく占有されている場合、そのデバイスがより低いＣＰＵ周波数およびより小さい揮発性メモリをもつデバイスよりも低いパフォーマンスをもつことがあるため、好ましくは、ユーザ・デバイス２と３の両方がそれらの現在の資源占有の状況に基づいてこの判断を下す。
【００４１】
ユーザ・デバイス２と３の両方がそれぞれＳ２０およびＳ３０で「イエス」の判断を得た場合、それらはそれらの資源情報を別個にユーザ・デバイス１に知らせることになる。好ましくは、報告される資源情報は、ＯＳのバージョン、ＣＰＵ周波数、揮発性メモリの容量、報告するデバイスのソフトウェア・バージョンに関連する。
【００４２】
そこで、ユーザ・デバイス２からの資源情報は以下でもよい。
<cpu>2.0G AMD Atholon</cpu> 
<Volatile Memory>512M</Volatile Memory> 
<operation system>Windows XP Home Edition</operation system> 
<application>MPEG4 Convertor</application> 
<version>1.0</version>
【００４３】
そして、ユーザ・デバイス３からの資源情報は以下でもよい。
<cpu>3.0G Pentium 4</cpu> 
<Volatile Memory>1.0G</Volatile Memory> 
<operation system>Windows XP Home Edition</operation system> 
<application>MPEG4 Convertor</application> 
<version>1.0</version>
【００４４】
好ましくは、コオペレータから共用イニシエータに送信される資源情報は、たとえばＣＰＵ周波数、揮発性メモリの容量などの資源の総数だけではなく、たとえばＣＰＵ、揮発性メモリの占有率などの占有状況も含む。この好ましい例で提供される資源情報は、以下でもよい。
<cpu>3.0G Pentium 4</cpu> 
<cpu occupied> 33% </cpu occupied> 
<Volatile Memory>1.0G</Volatile Memory> 
<Volatile Memory occupied> 33% </cpu occupied> 
<operation system>Windows XP Home Edition</operation system> 
<application>MPEG4 Convertor</application> 
<version>1.0</version>
【００４５】
簡潔さを目的として、ユーザ・デバイス４、５からのかかるタスクのフィードバックは流れ図には示されていない。そして、この例では、ユーザ・デバイス５は変換ソフトウェアをインストールしない。或いは、ユーザ・デバイス５は、１個のタスクを処理するためにあまりに多くの資源が占有されるまたは非常に長い時間がかかるという理由で、かかる変換がその資源の消耗につながることになると推定する。故に、ユーザ・デバイス５は任意のタスクを処理することを断念し、ユーザ・デバイス１に応答しないことがある。さらに、そのときユーザ・デバイス４、サーバは、重い負担を受けており、そのＣＰＵおよび揮発性メモリは大きく占有されていて（おそらく９０％以上）、故に、ユーザ・デバイス４もまた任意のタスクを処理することを断念する。
【００４６】
したがって、Ｓ２１および３１の後に、ユーザ・デバイス１によって収集された資源情報は、ユーザ・デバイス２、３のＣＰＵ、揮発性メモリ、ＯＳ、およびビデオ変換ソフトウェアの関連情報のみを備えることになる。
【００４７】
次に、Ｓ１２で、ユーザ・デバイス１が１０個のタスクのそれぞれについて１つまたは複数の指名コオペレータを判定する。簡単な方法は、コオペレータのＣＰＵ周波数に従って、ユーザ・デバイス１が１０個のタスクを分散する。この規則によれば、１０個のうちの６個のタスクがユーザ・デバイス３に割り当てられることになり、他の４個のタスクがユーザ・デバイス２に割り当てられることになる。より複雑な状況では、各コオペレータのＣＰＵ周波数、揮発性メモリの容量、およびＯＳの各項目が、所定のパラメータによって重みを付けられ、その結果は完全に１つまたは複数のコオペレータの能力を表すことができる。そして、かかる結果に基づいて指名コオペレータが判定されることになる。
【００４８】
したがって、Ｓ１３で、ユーザ・デバイス１が指名コオペレータに委託された１つまたは複数のタスクを知らせることになる。具体的には、ユーザ・デバイス１がＡＶＩファイル全体をＭＳＮを介してユーザ・デバイス２および３に送り、それらにそのファイルの異なる瞬間のある特定の部分を変換するように命令する。別法として、ユーザ・デバイス１は予めＡＶＩファイルを分割する、すなわち、６個のタスクに対応する一方と４個のタスクに対応する他方の２つの部分にファイルを分割することができる。その２つの部分は適宜に宛先に送られることになる。
【００４９】
詳細なタスクの委託方法は以下を含み得る。
解１：新しい形式の命令を追加し、その新しい命令をサポートするために既存のＩＭソフトウェアを拡張すること。
解２：新しい命令を既存のＩＭメッセージに追加すること。
【００５０】
次に、Ｓ２２およびＳ３２で、ユーザ・デバイス２および３がインストールされたＭＰＥＧ４コンバータを走らせ、Ｓ１３でユーザ・デバイス１によって指示されたタスクを遂行する。
【００５１】
Ｓ２３、Ｓ３３で、ユーザ・デバイス２および３が変換されたＭＰＥＧ４データをユーザ・デバイス１に送り返す。そのデータは以下の形態でもよい。
<task type> File Conversion </task type> 
<input> AVI </input> 
<output> MPEG4 </output> 
<output data>...</output data>
【００５２】
当然、ユーザ・デバイス２および３によって送り返されるＭＰＥＧ４データは、以下を含むがこれに限定されない任意のネットワーク伝送方式によって伝送されることができる：ＭＳＮによって提供されるパッキング・ツールを使用してＭＰＥＧ４データをカプセル化し、そのパッケージをＭＳＮメッセージを介して送信すること。そのとき、ユーザ・デバイス１は自動的にそのハードディスク上の事前設定された位置にそのデータを格納することができる。
【００５３】
もちろん、ユーザ・デバイス１がＭＰＥＧ４データの２つの部分を結合して再生可能なＭＰＥＧ４ファイルを得ることができない場合には、ユーザ・デバイス２および３によって送り返された２つのＭＰＥＧ４セグメントがユーザ・デバイス１で読取り可能であり且つ再生可能でもあるべきことが必須である。したがって、ユーザ・デバイス２および３はそれらの変換データにファイル・ヘッダをそれぞれ生成しなくてはならない。結果として、ＡＶＩファイルは、ユーザ・デバイス１に送り返されるとき、２つの別個のＭＰＥＧ４ファイルになる。別法として、Ｓ１２で、ユーザ・デバイス１が２つのＭＰＥＧ４セグメントを結合できないとき、ユーザ・デバイス１は、最大の能力をもつ１つのユーザ・デバイス、すなわちユーザ・デバイス３、を選択だけして１０個のタスクを処理することができる。
【００５４】
前項では、ユーザ・デバイス１が変換（ＡＶＩ→ＭＰＥＧ４）のソフトウェアをインストールしない状況について論じた。本発明のもう１つの例によれば、かかる種類のソフトウェアがユーザ・デバイス１にインストールされている。ＳｈａｎｅがＡＶＩファイルを楽しもうとして失敗するとき、ユーザ・デバイス１は変換が必要であることを認識することになる。それは、そのＣＰＵ、揮発性メモリ、ＯＳなどに照らして、それ自体が単独でその変換を行う場合、変換がその能力を超えるかどうかを判断する。たとえば、ユーザ・デバイス１は、ユーザ・デバイス１が単独でその変換を処理する場合にそのＣＰＵ、揮発性メモリがどの程度占有されることになるかおよびどのくらいの時間がかかるかをそれが知るのに役立ち得る過去のデータを読取る。前述の情報に基づいて、ユーザ・デバイス１は、推定される占有率および時間の長さが受入れ可能かどうかを識別することができる。一般に、その判断は、ＣＰＵ占有率閾値、揮発性メモリ占有率閾値、時間の長さの閾値などを用いて行われることができる。前述の指標のうちの１つが対応する閾値を超えた後は、ユーザ・デバイス１はＡＶＩファイル全体またはその一部の変換をそのコオペレータに委託することになる。
【００５５】
別法として、ユーザ・デバイス１は、ＡＶＩファイルの予備変換を行うことができる。すなわち、ユーザ・デバイス１が、ＡＶＩファイルの極めて小さいセグメントの瞬間変換を実行する。この瞬間変換の目的は、対応するＭＰＥＧ４セグメントを得ることではなく、以下のような情報を取得することである：ＣＰＵおよび揮発性メモリの占有率、ならびにユーザ・デバイス１がその変換を単独で行う場合に必要とされる時間。次に、その変換が全体としてまたは部分的に委託されるべきかどうかを判定するために、その情報が対応する閾値と比較されることになる。
【００５６】
この例では、ユーザ・デバイス１は、そのコオペレータの資源状況をそれらからの報告に基づいて知る。本発明の一例によれば、ユーザ・デバイス１は、使用可能な資源よりはむしろユーザ・デバイス２から５の全部の資源に従って、各タスクの１つまたは複数の指名コオペレータを判定した。ユーザ・デバイスの資源（たとえば、ＣＰＵ周波数、揮発性メモリの容量）の総数の変更は多くない可能性があるので、Ｓ１１、Ｓ２０、Ｓ３０、Ｓ２１およびＳ３１はすべて任意選択である。次に、ユーザ・デバイス１によって以前に取得された他のユーザ・デバイスの関連資源情報が、今回は指名コオペレータを判定するのに役立つことができる。ユーザ・デバイス１が委託されるべき各タスクの１つまたは複数の指名コオペレータをそのコオペレータの使用可能な資源（たとえば、ＣＰＵの残り、揮発性メモリの空き）に基づいて選択する場合、ユーザ・デバイス１が時宜を得てそのコオペレータの資源情報を知るようにさせるために、この方法は前述の任意選択のステップＳ１１、Ｓ２０、Ｓ３０、Ｓ２１およびＳ３１を備えることが、当業者には明らかである。
【００５７】
前の例の変形形態によれば、各タスクの１つまたは複数の指名コオペレータは、ユーザ・デバイス１のコオペレータ間の交換を介して判定されることもできる。図２を参照すると、ユーザ・デバイス１がユーザ・デバイス２から５にタスクの重要情報について伝えるとき、ユーザ・デバイス２から５のそれぞれは、ユーザ・デバイス１の助けにより、その資源情報を他の３つのデバイスに知らせる。次に、ユーザ・デバイス２から５のいずれかが、各タスクについての１つまたは複数の指名コオペレータを判定することができ、その結果を他に知らせる。
【００５８】
前述の項では、本発明は、ビデオ変換を例にとって説明されている。本発明はこの特定の例に限定されず、コンピュータ・ネットワークのデバイスが資源共用を必要とする任意のシナリオに適用されることができることが、当業者には明らかである。共用される資源は、たとえば．ＤＯＣから．ＰＤＦへの変換、複雑な行列計算、またはＭａｔｌａｂでの画像処理など、アプリケーション、ソフトウェア走行環境、ハードウェアの能力などを含むがこれらに限定されない。
【００５９】
本発明の特別な一例によれば、イニシエータのすべてのコオペレータは委託される各タスクのデフォルト指名コオペレータである。したがって、ステップＳ１１、Ｓ２０、Ｓ３０、Ｓ２１、Ｓ３１およびＳ１２はすべて任意選択である。１０個のタスクがＳ１０で判定されるとき、本方法はＳ１３に入り、ここで、ユーザ・デバイス１は１０個のタスクのすべてをあらゆるコオペレータ（ユーザ・デバイス２から５）に委託する。次にあらゆる前記コオペレータは、前述のタスクを処理しようと試み、その結果をユーザ・デバイス１に送り返す。
【００６０】
出願人は本発明を前述の方法に基づいて説明する。下記において、本発明は構成図を参照して説明される。そこでは、図４は、本発明の好ましい一例による、ＩＭプロトコルに基づいて他のユーザ・デバイスの資源を共用するための、コンピュータ・ネットワークのユーザ・デバイス内の、第１の共用装置の構成図である。図５は、本発明の好ましい一例による、別のユーザ・デバイスがＩＭプロトコルに基づいてローカル・ユーザ・デバイスの資源を共用するのを支援するための、コンピュータ・ネットワークのユーザ・デバイス内の、第２の共用装置の構成図である。
【００６１】
実際には、ユーザ・デバイスは、第１の共用装置１０および第２の共用装置２０を備えることができる、またはそれらのうちの１つだけを備えることができることが、当業者には明らかである。ある特定の状況では、たとえば、あるユーザ・デバイスの資源が常に不足しているため、そのデバイスが常に支援を求めている（共用イニシエータの役割をする）ことがあり、または、あるユーザ・デバイスの資源は十分であって他からの支援を全く必要とせず、そのデバイスが常にその資源を与える（コオペレータの役割をする）ことがある。前述の特定の状況では、ユーザ・デバイスは、前述のデバイスのうちの１つだけを備えることができる。一般に、ユーザ・デバイスはその２つの両方で構成される。
【００６２】
さらに詳細には、第１の共用装置１０は以下を備える。タスク委託手段１００、タスク結果受信手段１０１、指名コオペレータ判定手段１０２、およびタスク判定手段１０３。さらに、指名コオペレータ判定手段１０２は、重要情報提供手段１０２０、資源情報取得手段１０２１、および２次判定手段１０２２を備える。
【００６３】
第２の共用装置２０は以下を備える。委託受信手段２００、判定支援手段２０１、２次処理手段２０２、および結果戻し手段２０３。さらに、判定支援手段２０１は、重要情報取得手段２０１０、資源情報報告手段２０１１、および判断手段２０１２を備える。
【００６４】
たとえば、図２のユーザ・デバイス１がそのコオペレータに支援を求める。Ｓｈａｎｅが、Ｈ．２６４規格によってコード化された、ユーザ・デバイス１によるＡＶＩ形式の映画をダウンロードする。しかし、ユーザ・デバイス１はＭＰＥＧ４ビデオしか再生することができず、Ｈ．２６４に基づくビデオ・ファイルを再生することができない。したがって、この映画は、ユーザ・デバイス１で再生される前に、ＭＰＥＧ４形式に変換されなければならない。本発明の一例では、ユーザ・デバイス１は、Ｈ．２６４からＭＰＥＧ４への変換のためのインストールされたソフトウェアをもたない。そのとき、Ｓｈａｎｅは、タッチ画面上のボタンをクリックして彼がこのビデオを見たいということを示す。その形式はユーザ・デバイス１のプレーヤによってサポートされることができないため、以下の状況が存在する。
【００６５】
−ユーザ・デバイス１のプレーヤが起動されるが、ＡＶＩビデオのファイル・タイプを識別することができない、
−ユーザ・デバイス１のプレーヤが起動されず、Ｓｈａｎｅはそれを開くために別のソフトウェアを選択するように促される。
【００６６】
実際の構成によれば、第１の共用装置１０内のタスク判定手段１０３は、特定の瞬間に、たとえば、プレーヤが起動され、ファイルのタイプを識別することができないとき、またはそれがＳｈａｎｅに他のソフトウェアの選択を促すときなどに、作業を開始することができる。
【００６７】
ここで、ＡＶＩ形式のビデオを見るためには、形式変換が必要である。次に、ユーザ・デバイス１のタスク判定手段１０３が、そのファイルの多数のビデオ・フレームがＨ．２６４からＭＰＥＧ４に変換される必要があると判定する。もちろん、タスクの数は柔軟に判定されることができる。たとえば、ＡＶＩファイル全体としての変換が１個のタスクとして定義されることができ、または、１つ１つのフレームの変換が１個のタスクとして定義されることができ、または、１組のフレームの変換をそのようなタスクとすることができる。この例では、ユーザ・デバイス１がＡＶＩファイルを１０個の同等の部分に分ける。その結果として、それぞれが複数のフレームの変換に対応する、１０個のタスクが存在する。特に、それらのタスクのうちの１つは、ユーザ・デバイス１のプレーヤが変換ファイルを再生するときに確実に作動できるようにするために、ＡＶＩヘッダのＭＰＥＧ４ヘッダへの変換にも対応する。次に、タスク判定手段１０３が、重要情報提供手段１０２０に判定された１０個のタスクを知らせる。
【００６８】
次に、重要情報提供手段１０２０が、ＭＳＮメッセージを介して、その１０個のタスクの重要情報をユーザ・デバイス１のコオペレータに送る。その重要情報は、たとえば以下のような、ＸＭＬの形態でもよい。
<task type>File Conversion</task type>
<input>H.264</input> 
<output><MPEG4></output> 
<input data>... </input data>
【００６９】
ここでは、第１行はタスクのタイプがファイル変換であることを示し、第２行はファイルの元の形式がＨ．２６４であることを示し、第３行は所望の形式がＭＰＥＧ４であることを示す。そして、第４行は、変換されるべき元データを表す。変換のために委託されるデータのサイズが大きくない場合、元データは、重要情報が送信されるときに、前述のようにコオペレータに直接送信されることができることが、当業者には明らかである。この例では、変換されるデータは１０Ｍ或いは１００Ｍのサイズをもつので、好ましくは、第４行の「＜ｉｎｐｕｔ  ｄａｔａ＞．．．＜／ｉｎｐｕｔ  ｄａｔａ＞」は、各タスクに対応するデータのサイズを表すのみでもよい。各タスクに関する１つまたは複数の指名コオペレータが判定された後に、特定のデータがコオペレータに送信されることができる。もちろん、ネットワーク伝送資源が完全に十分である場合、ユーザ・デバイス１は１つまたは複数の変換されるべきファイルをあらゆる仲間に送信することができる。かかるシナリオの下では、後でタスクを委託するとき、ユーザ・デバイス１は各指名コオペレータにそれがどの１つまたは複数のタスクを委託されたかを伝えるだけでよい。
【００７０】
ここで、ＭＳＮがユーザ・デバイス１上で走っていない場合、重要情報提供手段１０２０が先ずこのソフトウェアを走らせ、次にロギングインまたはそれと同様のものを行う。これは、ＭＳＮはオフライン・メッセージをサポートすることができるが、ユーザ・デバイス１の重要情報提供手段がＳｈａｎｅのオンラインの仲間のユーザ・デバイスのみにタスクの重要情報を送信する、本発明の好ましい一例を表す。もちろん、タスクが至急でない場合、ユーザ・デバイス１はＭＳＮ上のＳｈａｎｅのすべての仲間のユーザ・デバイスに重要情報を送信することができ、ユーザ・デバイス１がＳｈａｎｅのすべての仲間のユーザ・デバイス（オンラインのものとオフラインのものを含む）の資源情報を取得した後に、各タスクの指名コオペレータが判定されることができる。図３には、簡潔に、ユーザ・デバイス１のコオペレータとしてユーザ・デバイス２および３のみが示されている。
【００７１】
次に、ユーザ・デバイス２および３の重要情報取得手段２０１０がそれぞれ重要情報を受信し、その後それを判断手段２０１２に与えることになる。そこでは、ユーザ・デバイス２および３の各判断手段２０１２がユーザ・デバイス１の１０個の委託されることになるタスクの重要情報を学習した後、それはローカル・ユーザ・デバイスの資源情報を確認する。具体的には、ユーザ・デバイス２および３のそれぞれにある判断手段２０１２は、ユーザ・デバイス自体によってまたはネットワーク・サーバによって保持される資源情報リストにアクセスすることによって、ユーザ・デバイスがＨ．２６４  ファイルをＭＰＥＧ４に変換することができるかかるソフトウェアをもつかどうかを知ることができ、また、ローカル・ユーザ・デバイスのＯＳ、ＣＰＵ周波数、揮発性メモリの容量などの情報を取得することもできる。前記の情報に基づいて、ユーザ・デバイス２および３のそれぞれにある判断手段２０１２は、そのローカル・ユーザ・デバイスが１０個のタスクのうちの１つまたは複数を処理する能力をもつかどうかをそれぞれ判定することができる。
【００７２】
この例では、ユーザ・デバイス２および３の判断手段２０１２は、変換のための前記ソフトウェアがユーザ・デバイス２と３の両方にインストールされていると判断する。さらに、ユーザ・デバイス２、３の判断手段２０１２は、過去の経験に基づいてローカル・ユーザ・デバイスがそのタスクのうちの少なくとも１つについて受け入れることができると判断する。たとえば、かかるデバイスが同様のビデオ変換を以前に実行したときに占有されたＣＰＵ、揮発性メモリの情報が保持されていた。より高いＣＰＵ周波数およびより大きな揮発性メモリをもつデバイスのＣＰＵおよび揮発性メモリがひどく占有される場合に、そのデバイスがより低いＣＰＵ周波数およびより小さい揮発性メモリをもつデバイスよりも低いパフォーマンスをもつことがあるため、好ましくは、ユーザ・デバイス２および３の判断手段２０１２はローカル・ユーザ・デバイスの現在の資源占有状況に基づいてこの判断を下す。
【００７３】
ユーザ・デバイス２およびユーザ・デバイス３の判断手段２０１２がどちらも「イエス」の判断を得た場合、各判断手段２０１２は、対応するコオペレータの資源情報２０１１にこのコオペレータの資源情報をユーザ・デバイス１に知らせるように命令することになる。もちろん、資源情報２０１１は、判断手段２０１２がどんな判断を下してもユーザ・デバイス１に資源情報を知らせることができる。好ましくは、報告される資源情報は、対応するコオペレータのＯＳのバージョン、ＣＰＵ周波数、揮発性メモリの容量、ソフトウェアのバージョンに関連する。
【００７４】
そこでは、ユーザ・デバイス２からの資源情報は以下でもよい。
<cpu>2.0G AMD Atholon</cpu> 
<Volatile Memory>512M</Volatile Memory>
<operation system>Windows XP Home Edition</operation system> 
<application>MPEG4 Convertor</application> 
<version>1.0</version>
【００７５】
そして、ユーザ・デバイス３からの資源情報は以下でもよい。
<cpu>3.0G Pentium 4</cpu> 
<Volatile Memory>1.0G</Volatile Memory> 
<operation system>Windows XP Home Edition</operation system> 
<application>MPEG4 Convertor</application> 
<version>1.0</version>
【００７６】
好ましくは、コオペレータから共用イニシエータに送信される資源情報は、たとえばＣＰＵ周波数、揮発性メモリの容量などの資源の総数だけでなく、たとえばＣＰＵ、揮発性メモリの占有率などのそれらの占有状況も備える。この好ましい例で提供される資源情報は以下でもよい。
<cpu> 3.0G Pentium 4</cpu> 
<cpu occupied> 33% </cpu occupied> 
<Volatile Memory>1.0G</Volatile Memory> 
<Volatile Memory occupied> 33% </cpu occupied> 
<operation system>Windows XP Home Edition</operation system> 
<application>MPEG4 Convertor</application> 
<version>1.0</version>
【００７７】
簡潔さを目的として、ユーザ・デバイス４、５からのフィードバックは流れ図には示されていない。そして、この例では、ユーザ・デバイス５は変換ソフトウェアをインストールしていない。或いは、ユーザ・デバイス５は、１個のタスクを処理するためにあまりに多くの資源が占有されるまたは非常に長い時間がかかるため、かかる変換がその資源の消耗をもたらすと推定する。したがって、ユーザ・デバイス５は任意のタスクを処理することを断念し、ユーザ・デバイス１に応答しないことがある。さらに、ユーザ・デバイス４、サーバは、重い負担を受けており、そのＣＰＵおよび揮発性メモリは大きく占有されていて（おそらく９０％以上）、故に、ユーザ・デバイス４もまた任意のタスクを断念する。
【００７８】
したがって、ユーザ・デバイス１の資源情報取得手段１０２１によって収集される資源情報は、ユーザ・デバイス２および３のＣＰＵ、揮発性メモリ、ＯＳ、およびビデオ変換ソフトウェアの関連情報のみを備えることになる。
【００７９】
次に、ユーザ・デバイス１の２次判定手段１０２２が、１０個のタスクのそれぞれについて１つまたは複数の指名コオペレータを判定する。単純な方法は、ユーザ・デバイス１の２次判定手段１０２２が、コオペレータのＣＰＵ周波数に従って、１０個のタスクを分散する。この規則によれば、１０個のうちの６個のタスクがユーザ・デバイス３に割り当てられ、他の４個のタスクがユーザ・デバイス２に割り当てられることになる。より複雑な状況では、各コオペレータのＣＰＵ周波数、揮発性メモリの容量、およびＯＳの各項目が所定のパラメータによって重みを付けられることになり、その結果は完全に１つまたは複数のコオペレータの能力を表すことができる。そして、かかる結果に基づいて、指名コオペレータが判定されることになる。
【００８０】
したがって、ユーザ・デバイス１の２次判定手段１０２２は、その結果をタスク委託手段１００に伝えることになり、次に、委託手段１００が指名コオペレータに委託された１つまたは複数のタスクを知らせることになる。その１つまたは複数のタスクは、ユーザ・デバイス２および３のそれぞれにある委託受信手段２００によって受信されることになる。具体的には、ユーザ・デバイス１のタスク委託手段１００は、ＭＳＮを介してＡＶＩファイル全体をユーザ・デバイス２および３に送信し、それらにそのある特定の部分を変換するように命じる。別法として、ユーザ・デバイス１は、予めＡＶＩファイルを分割することもできる、すなわち、ファイルを６個のタスクに対応する一方と４個のタスクに対応するもう一方の２つの部分に分割することができる。その２つの部分はその宛先に適宜に送信されることになる。
【００８１】
詳細なタスクの委託方法は以下を含み得る。
解１：新しい形式の命令を追加し、既存のＩＭソフトウェアを拡張してその新しい命令をサポートすること。
解２：新しい命令を既存のメッセージに追加すること。
【００８２】
次に、ユーザ・デバイス２および３のそれぞれの２次処理手段２０２が、ローカル・ユーザ・デバイスにインストールされたＭＰＥＧ４コンバータを走らせ、Ｓ１３でユーザ・デバイス１によって指示されたタスクを遂行する。
【００８３】
次に、ユーザ・デバイス２および３のそれぞれの結果戻し手段２０３が、変換されたＭＰＥＧ４データをユーザ・デバイス１に送り返す。そのデータは以下の形態でもよい。
<task type> File Conversion </task type> 
<input>AVI </input>
<output> MPEG4 </output>
<output data> ... </output data>
【００８４】
当然、ユーザ・デバイス２および３のそれぞれの結果戻し手段２０３によって送り返されたＭＰＥＧ４データは、以下を含むがこれに限定されない任意のネットワーク伝送方式によって伝送されることができる：ＭＳＮによって提供されるパッキング・ツールを使用してＭＰＥＧ４データをカプセル化し、そのパッケージをＭＳＮメッセージを介して送信すること。そのとき、ユーザ・デバイス１は自動的にそのハードディク上の事前設定された位置にそのデータを格納することができる。
【００８５】
もちろん、ユーザ・デバイス１がＭＰＥＧ４データの２つの部分を結合して再生可能なＭＰＥＧ４ファイルを得ることができない場合には、ユーザ・デバイス２および３によって送り返された２つのＭＰＥＧ４セグメントがユーザ・デバイス１で読取り可能であり且つ再生可能でもあるべきことが必須である。故に、ユーザ・デバイス２および３は、それらの変換されたデータについてファイル・ヘッダをそれぞれ生成しなければならない。その結果として、ＡＶＩファイルは、ユーザ・デバイス１に送り返されるとき、２つの別個のＭＰＥＧ４ファイルになる。別法として、ユーザ・デバイス１が２つのＭＰＥＧ４セグメントを結合することができないとき、ユーザ・デバイス１の２次判定手段１０２２は、最大の能力をもつ１つのユーザ・デバイス、すなわちユーザ・デバイス３、を選択だけして１０個のタスクをすべて処理することができる。
【００８６】
前項では、ユーザ・デバイス１が変換（ＡＶＩからＭＰＥＧ４）のためのソフトウェアをインストールしない状況について論じた。本発明のもう１つの例によれば、ユーザ・デバイス１にインストールされたかかる種類のソフトウェアが存在する。故に、ＳｈａｎｅがＡＶＩファイルを楽しもうと試みて失敗するとき、次にユーザ・デバイス１は変換が必要であることを認識することになる。ユーザ・デバイス１のタスク判定手段１０３が、そのＣＰＵ、揮発性メモリ、ＯＳなどに従って、変換がユーザ・デバイス１のみによって実行される場合、その変換がユーザ・デバイス１の能力を超えるかどうかを判断する。たとえば、ユーザ・デバイス１がすべて単独でその変換を処理する場合に、そのＣＰＵ、揮発性メモリがどの程度占有されることになるかおよびどのくらい時間がかかるかをユーザ・デバイス１が知るのに役立つことができる過去のデータをタスク判定手段１０３が読取る。前述の情報に基づいて、ユーザ・デバイス１は、推定される占有率および時間の長さが受入れ可能かどうかを識別することができる。一般に、この判断は、ＣＰＵ占有率閾値、揮発性メモリ占有率閾値、時間の長さの閾値などを用いて行われることができる。前述の指標のうちの１つが対応する閾値を超えた後は、ユーザ・デバイス１はＡＶＩファイル全体またはその一部の変換をそのコオペレータに委託することになる。
【００８７】
別法として、ユーザ・デバイス１のタスク判定手段１０３は、ＡＶＩファイルの予備変換を行うことができる。すなわち、ユーザ・デバイス１が、ＡＶＩファイルの極めて小さいセグメントの瞬間変換を実行する。この瞬間変換の目的は、対応するＭＰＥＧ４セグメントを得ることではなく、以下のような情報を取得することである。ＣＰＵおよび揮発性メモリの占有率、ならびにユーザ・デバイス１がその変換を単独で行う場合に必要とされる時間。次に、その変換が全体としてまたは部分的に委託されるべきかどうかを判定するために、その情報が対応する閾値と比較されることになる。
【００８８】
この例では、ユーザ・デバイス１の資源情報取得手段１０２１が、そのコオペレータの資源状況を彼らからの報告に基づいて知る。本発明の一例によれば、ユーザ・デバイス１は、使用可能な資源よりはむしろユーザ・デバイス２から５の全部の資源に従って、各タスクの１つまたは複数の指名コオペレータを判定した。ユーザ・デバイスの資源（たとえば、ＣＰＵ周波数、揮発性メモリの容量）の総数の変更は多くない可能性があるので、重要情報提供手段１０２０および判定支援手段２０１は任意選択である。次に、ユーザ・デバイス１の２次判定手段１０２２によって以前に取得された他のユーザ・デバイスの資源情報が、今回は指名コオペレータを判定するのに役立つことができる。ユーザ・デバイス１の２次判定手段１０２２が委託される各タスクの１つまたは複数の指名コオペレータをそのコオペレータの使用可能な資源（たとえば、ＣＰＵの残り、揮発性メモリの空き）に基づいて選択する場合、ユーザ・デバイス１に時宜を得てそのコオペレータの資源情報を知らせるために、好ましくは、重要情報提供手段１０２０および判定支援手段２０１が必要となることが、当業者には明らかである。
【００８９】
前の例の変形形態によれば、その１つまたは複数の指名コオペレータは、ユーザ・デバイス１のコオペレータ間の交換を介して判定されることもできる。図２を参照すると、ユーザ・デバイス１がユーザ・デバイス２から５にタスクの重要情報について伝えるとき、ユーザ・デバイス２から５のそれぞれは、ユーザ・デバイス１の助けにより、その資源情報を他の３つのデバイスに知らせる。次に、ユーザ・デバイス２から５のいずれかが、各タスクについての１つまたは複数の指名コオペレータを判定することができ、その結果を他に知らせる。
【００９０】
本発明の特別な一例によれば、すべてのオンラインのコオペレータはあらゆる委託されるタスクのデフォルト指名コオペレータである。次に、１０個のタスクがユーザ・デバイス１の２次判定手段１０３によって判定されるとき、それらはユーザ・デバイス１のタスク委託手段１００によって各コオペレータ（ユーザ・デバイス２から５）に委託されることになる。次に、各コオペレータの２次処理手段２０２が前述のタスクを処理しようと試み、その結果を各コオペレータの結果戻し手段２０２を介してユーザ・デバイス１に送り返す。
【００９１】
図６は、本発明を実装するためのソフトウェアの図である。図中のモジュールの機能は以下のとおりである。
【００９２】
通信モジュール
従来のＩＭ機能を目的とする、仲間の間でのタスクおよび結果の移送。
【００９３】
アクセス制御モジュール
ローカル・アプリケーションおよび資源アクセス制御を目的とする、ポリシーに対応、どの種類の仲間がどの時間にまたはどの程度ローカル・ユーザ・デバイスの資源にアクセスすることができるかを定義することができる。
【００９４】
タスク・アナライザ
ローカル・アプリケーションまたは資源が資源情報アナライザを介して仲間の要求をサポートすることができるかどうか、または、ユーザの要求を１個のタスクにまとめ、通信モジュールを介してそれらを仲間に送信することができるかどうかを分析することを目的とする。
【００９５】
資源情報アナライザ
ローカル・システムから取得された情報を資源情報リストから取得されたものと結合してローカル環境が仲間の要求をサポートすることができるかどうかをチェックする。
【００９６】
ローカル・アプリケーション・ランチャ
ローカル・アプリケーションおよびアプリケーション・データ転送を開始することを目的とする。
【００９７】
外部アプリケーション・コンテナおよびランチャ
仲間からの外部アプリケーションの格納および起動、ならびにアプリケーション・データ転送のために使用される。自動的にまたはＸＭＬ形式の命令を介した仲間の動作開始信号を受信したときに、仲間のアプリケーションを起動することができる。
【００９８】
さらに、図６はまた、本発明に関連する、ローカル・アプリケーション手順、システム資源、資源情報リスト、および仲間リストを示す。
【図１】
2011529587.tif 000003
【図２】
2011529587.tif 000004
【図３】
2011529587.tif 000005
【図４】
2011529587.tif 000006
【図５】
2011529587.tif 000007
【図６】
2011529587.tif 000008
【国際調査報告】
2011529587.tif 000009
2011529587.tif 000010