ハンドセット端末を介してリソースを共有する方法、及び装置
モバイル端末を介してユーザのグループ間でのリソースの共用を可能にするメカニズム及びサポート装置を提供する。提供されるシステムは、キャリアインフラストラクチャーを強化して端末における要求を単純にし、異種デバイスに対してランタイムでカスタマイズできる汎用的なグラフィックユーザインターフェイスの開発を可能にするグラフィックユーザインターフェイスバインディング機構を記述する。
【発明の詳細な説明】
【優先権】
【0001】
[0001] 本特許出願は、2003年6月25日に出願された「Method and Apparatus for Media Sharing Over Handset Terminals」と題する対応の仮出願第60/482,669号の優先権を請求する。
【発明の分野】
【0002】
[0002] 本発明は、移動通信の分野に関するものである。より詳細には、本発明は、モバイルデバイスを介したリソースの共有に関する。
【発明の背景】
【0003】
[0003] ワイヤレスウェブの将来の成功は、パーソナルコンテンツの配信に左右されるであろう。パーソナルコンテンツとは、本明細書では、個人によってリアルタイムに作成されるコンテンツを指すものであって、個人的性質のものである。パーソナルコンテンツの作成及び配信の原始的な形態は、カメラを搭載した携帯電話と、マルチメディアメッセージ、即ちMMSをサポートするキャリアとをベースにして、今日存在している。この形式のコンテンツの配信が原始的であるのは、ポイント・ツー・ポイントのメディアの配信のみ、即ちユーザは、画像を撮影してそれを別のユーザに直接送信することだけが可能であるからである。しかしながら、有線ウェブ(wired web)は、コンテンツの作成及び配信のための非常に精巧なエコシステムを生み出している。但し、有線ウェブは主に会社や企業をターゲットにしている。無線ウェブ(wireless web)は、パーソナルコンテンツ作成のための同様のエコシステムを可能にすべく進化するであろう。しかしながら、この将来展望は、グループマネージメント、メディア配信、及び異種デバイスのための動的なグラフィックユーザインターフェイスマッピングを含む、関連の課題に対処することのできるサポートインフラストラクチャーを必要とする。
【0004】
[0004] インターネットは、歴史的にラジオやテレビにすら先行して最も早く採用されたマスメディアのメカニズムになっている。この成功に対する一つの鍵は、世界的規模でアクセスが可能な情報の公開を、いかなるユーザにも認める共有モデルにある。更に、データのページへのグループ化、及びデータ連結グラフを定義するハイパーリンクの使用によって、データの配布セットを関連付ける簡潔且つ単純なメカニズムが提供されている。インターネットの共有モデルは、四つのプロセス、即ちメディア生成、メディア編成、メディア可視化、及びメディアアクセス、に分割することができる。最初の三つのプロセスは、メディアの公開者に関するものである。一方、最後の一つのプロセスは、エンドユーザ又はメディアビューアに関するものである。メディア生成は、公開者がエクスポートすることを望むデータの収集に関するものである。このデータは、オーディオ、ビデオ及びピクチャーのような取り込まれたメディアと、ドキュメント、アノテーション、及びデータベースからのレコード等の生成されたメディアと、を含んでいる。メディア編成は、メディアの論理的構造化、及び、メディアをいかにユーザに提供するかに関するものである。メディア可視化は、異なるユーザがアクセス可能なデータを管理するためのポリシーを定義する。最後に、メディアアクセスは、ユーザ(メディアビューア)が公開されたデータにアクセスするプロセスである。
【0005】
[0005] 上述した四つのプロセスは、汎用的なものであり、異なるドメインに対応づけることができる。有線ウェブの場合、伝統的なワールドワイドウェブモデルは、有線通信手段を介してインターネットに接続され、且つ、商業的及び個人的なウェブサイトをホスティングするサーバーによって特徴付けられる。無線ウェブは、パーソナル化グループワイドウェブ(Personalized Group Wide Web)と称される共有モデルであり、このウェブは、無線接続されるパーソナルハンドデバイスであって個人情報をホスティングするパーソナルハンドヘルドデバイスの集合を仮定している。この個人情報は、上記デバイスから直接的に、ユーザのグループによって共有されるものである。両モデルは、メディア生成、編成、可視化、及びアクセスに関する相違を有している。本明細書では、この相違を明確にし、無線ウェブモデルに関連した課題を説明し、これらの課題に対応するソフトウェアインフラストラクチャーを提供する。
【0006】
[0006] ヤフーグループは、メッセージ、ピクチャー、及びカレンダーの交換、並びにデータベースへのエントリーを可能にしている。なお、ヤフーグループhttp://groups.yahoo.comを参照されたい。しかしながら、このモデルは、全てのメディアをハンドセットから中央サーバーへアップロードすることが要求されているハンドヘルドユーザ用にカスタマイズされていない。代わりに、PGWWモデルは、メディアがハンドセットから直接エクスポートされており、当該メディアが多数のプロパティに基づいて自動的に移動され得るという仮定に基づいている。
【0007】
[0007] ブロギング(Blogging)は、ダイアリー及びガイドサイトの組合せであり、人々がメディアを公開し、リアルタイムにウェブサイトへリンクすることを可能にしている。なお、ブロッガー・コム(Blogger.com)のhttp://www.blogger.comを参照されたい。しかしながら、ブロギングは、グループの概念を有しておらず、個人がウェブサイトにログインすると、その個人が生成したメディアは誰にでも閲覧可能になる。更に、ブロギングは、ブログをホスティングする中央サーバーへの接続を仮定している。ハンドセットユーザは、データを前処理することによって自分のデバイスを強化することを可能にするツールをもっていない。更に、ブログに投稿された新たなメディアに関してユーザに通知するメカニズムがない。その結果、ユーザは、新規の追加を定期的にチェックしなければならない。
【0008】
[0008] インスタントメッセージ(Instant messaging)は、ユーザがメッセージをリアルタイムに交換することを可能にしており、世界的規模で広く使用されている。詳細な情報については、AOLインスタントメッセンジャーhttp://www.aim.com/index.adp、及びマイクロソフトメッセンジャーhttp://messenger.msn.com/を参照されたい。スマートフォンの登場に伴い、インスタントメッセージングプログラムがこれらデバイスへ移植されており、その結果、ユーザはメッセージをいつでも交換することが可能になっている。パーソナル化グループワイドウェブ用の(即ち、パーソナルコンテンツをグループで共有するための)ミドルウェアインフラストラクチャーは、インスタントメッセージをサポートするように拡張できるが、その元来のアプローチは、関係者がアクセス可能なメディアをユーザが投稿することを可能にすることを目的としている。
【0009】
[0009] モバイル端末間でリソースを共有するメカニズムには、二つの標準的なメカニズムがある。その一つは、全ての機能及びリソースがサーバー側にあるというクライアント−サーバーアプローチを仮定している。クライアントは、サーバーにリソースをプッシュし、また、サーバーからリソースを取得する。二つ目のアプローチは、サーバーインフラストラクチャーがないことを仮定している。その結果、共有インフラストラクチャーは、ピア・ツー・ピアのアプローチに準拠するハンドセット間で分割されている。
【発明の概要】
【0010】
[0010] 本明細書には、ユーザのグループ間でモバイル端末を介してリソースを共有可能にする方法、及び装置が開示されている。一実施形態においては、この装置は、多数のモバイルデバイスの一つとしてキャリアのネットワークデバイスと共に使用するためのモバイルデバイスを備えている。このモバイルデバイスは、一つ以上のメディアリソースを記憶するためのメモリと、リソースマネージャーとを備えている。このリソースマネージャーは、メモリに記憶された一つ以上のメディアリソースを、キャリアのリソースコーディネーターとの協働によって制御して、メディアリソース又は当該メディアリソースへのリンクをリソースコーディネーターに提供すべきかどうかを動的に決定し、モバイルデバイスのグループのうちの他のモバイルデバイスへ一つ以上のメディアリソースを配信可能にする。
【0011】
[0011] 本発明は、種々の実施形態の以下の詳細な説明及び添付の図面から充分に理解されるであろう。しかしながら、これらは、本発明を特定の実施形態に限定するものではなく、本発明の説明及び理解のためのものに過ぎない。
【本発明の詳細な説明】
【0012】
[0024] 本明細書に説明する技術は、上記の二つの標準的なメカニズムの中間的なアプローチをベースにして、モバイルデバイス(例えば、ハンドセット、端末等)間でリソースを共有しようとするものである。より詳細には、サーバーインフラストラクチャーは、グループを調整(coordinate)しており、また、モバイルデバイスがグループマネージメントプロトコルに参加すること、そして、リソースがモバイルデバイスから直接共有されることを仮定している。このアプローチによれば、サーバーが、グループマネージメント要求を調整し、また、双方向プロトコルを実行してモバイルデバイスを最新の状態に維持する。これによって、クライアント−サーバーモデルが強化される。一実施形態においては、モバイル端末がプロトコルに参加する。その結果、モバイル端末は、単一要求ごとにサーバー側のインフラストラクチャーに接続する必要がなくなる。即ち、このプロトコルは、モバイル端末が自身のメモリに最新の情報を保持することを可能にする。純粋なクライアント−サーバーアプローチとは異なり、このモデルは、モバイルデバイスから直接的にリソースを共有している。結果として、モバイル端末が、ローカルリソースをエクスポートし、リモートデバイスからの要求を受け入れるサービスを提供する。
【0013】
[0025] 本明細書に記載されたハイブリッドモデルは、モバイル端末側の切断及び故障に、容易に対処することができる。モバイルデバイスは、自身が切断していること、又はクラッシュしたことを検出すると、サーバーのグループコーディネーター(以下に述べる)に接続して最新のグループ情報を取得することができる。この情報によって、モバイルデバイスは、グループの他のメンバーと同期することが可能になる。
【0014】
[0026] 以下、ハンドセットのグループにおいて動的なメディアの共有を可能にするメカニズム、及びサポート装置について説明する。本明細書に説明する技術は、動的且つ適応的なリソースの投稿及び配布をも実現しており、効率的なハンドセットリソースホスティングのためのメカニズムを含んでいる。一実施形態においては、実行されるハンドセットリソースホスティングが、動的プロトコルに従っており、当該プロトコルによれば、ある状態、即ちスレッシュホールドに到達したときに、ハンドセットがリソースをキャリアのネットワークサーバーへハンドオーバーする。かかるハンドセットの状態は、例えば、過剰帯域幅消費状態、低バッテリ状態、又はストレージ割当状態を含んでいる。過剰帯域幅消費状態にあるときには、多量の帯域幅の使用を回避するために、ハンドセットがメディアリソースを他のハンドセットに提供することを望まないことがある。低バッテリ状態とは、リソースをホスティングしているハンドセットが、望んで低電力状態になってバッテリの電力を節約しており、当該ハンドセットがホスティングしているリソースに対するリソース要求に応答し続けるための電力を維持しなくてもよい状態である。ストレージ割当状態とは、ハンドセットが制限容量(数又はサイズ)を有してリソースをホスティングしており、その制限に達したときに、ハンドセットがそれに代わってホスティングするネットワークにリソースを提供する状態である。
【0015】
[0027] 以下、多くの細部を説明し、本発明をより完全に説明する。しかしながら、当業者であれば、これら特定の細部が無くとも、本発明を実施することができることは明らかであろう。他の例では、本発明を不明瞭にしないために、公知の構造及び装置は、詳細に示さずに、ブロック図で示す。
【0016】
[0028] 以下の詳細な説明の幾つかの部分は、コンピュータメモリ内のデータビットに対するオペレーションのアルゴリズム及び記号表示で表わされている。これらアルゴリズムの記述及び表示は、データ処理技術の当業者がその仕事の実体を他の当業者に最も効率的に伝えるために使用される手段である。アルゴリズムは、本明細書においても、及び一般的にも、希望の結果を導くステップの首尾一貫したシーケンスであると考えられる。これらのステップは、物理量の物理的な操作を要求するものである。必ずしもそうではないが、通常、これらの量は、記憶、転送、合成、比較、及びその他操作することのできる電気的又は磁気的信号の形態をとる。時には、主として共通に使用する理由で、これら信号をビット、値、エレメント、記号、キャラクタ、用語、番号等として参照するのが便利であると分かっている。
【0017】
[0029] しかしながら、これら及び同様の用語は、全て、適当な物理量に関連付けられると共に、これらの量に適用される単なる便利な標号に過ぎないことに注意されたい。以下の説明から明らかなように特に指示のない限り、この説明全体にわたり、「処理」又は「計算」又は「算出」又は「決定」又は「表示」等の用語を使用した議論は、コンピュータシステムのレジスタ及びメモリ内の物理的(電子的)量として表わされたデータを、コンピュータシステムメモリ又はレジスタ或いは他のこのような情報記憶、送信又はディスプレイデバイス内の物理的量として同様に表わされる他のデータへ操作及び変換するコンピュータシステム又は同様の電子計算デバイスのアクション及びプロセスを指すことが明らかであろう。
【0018】
[0030] また、本発明は、これらオペレーションを遂行するための装置にも係る。この装置は、要求された目的に対して特別に構成されてもよいし、或いは記憶されたコンピュータプログラムにより選択的に起動され、又は再構成される汎用コンピュータを備えてもよい。このようなコンピュータプログラムは、コンピュータ読み取り可能な記憶メディアに記憶されてもよく、この記憶メディアは、フロッピーディスク、光学ディスク、CD−ROM、及び磁気−光学ディスクを含む任意の形式のディスク、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、EPROM、EEPROM、磁気又は光学カード、或いはコンピュータシステムバスに各々接続されて電子的命令を記憶するのに適した任意の形式のメディアであるが、これらに限定されない。
【0019】
[0031] また、本明細書に示すアルゴリズム及びディスプレイは、特定のコンピュータや他の装置に固有に関係したものではない。種々の汎用システムを、本明細書の教示に基づくプログラムと共に使用してもよいし、必要な方法ステップを遂行する更に特殊な装置を構成することが便利であることがわかるであろう。これらの種々のシステムに必要な構造は、以下の説明から明らかとなろう。更に、本発明は、特定のプログラミング言語を参照して説明するものではない。ここに述べる本発明の教示を実施するのに種々のプログラミング言語を使用してもよいことが明らかであろう。
【0020】
[0032] マシン読み取り可能なメディアは、マシン(例えば、コンピュータ)により読み取りできる形態で情報を記憶又は送信するためのメカニズムを含む。例えば、マシン読み取り可能なメディアは、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、磁気ディスク記憶メディア、光学記憶メディア、フラッシュメモリデバイス、電気、光学、音響又は他の形態の伝播信号(例えば、搬送波、赤外線信号、デジタル信号等)、等を含んでもよい。
【0021】
[0033] 図1Aは、本明細書に説明する効率的なリソース共有を実行するためのシステムコンポーネントを示している。図1Aを参照すれば、ハンドセット100は、キャリアのネットワークサーバー110に通信可能に結合されて示されている。ハンドセット100は、キャリアによって取り扱われるハンドセットのグループの一部である。ハンドセット100は、如何なるモバイルデバイス(例えば、携帯電話、コンピュータシステム等)であってもよい。キャリアのネットワークサーバー110は、一つ以上のサーバーを含んでもよく、グループ内のハンドセット(及びハンドセットの他のグループ)と協働してキャリアによって実行されるリソース共有を調整する。ネットワークサーバー110は、ハンドセットの多数のグループに対してリソースを調整してもよいことに注意されたい。一つのグループは、一つ以上のメンバー、及び、これらメンバーによって提供される0以上のリソースから構成されている。一実施形態においては、一つのグループが、少なくとも一つのメンバーを有している。但し、グループは、リソースを有していなくてもよい。各リソースは、厳密には一つのメンバーに属しており、各メンバーは、0以上のリソースをグループにエクスポートすることができる。リソースは、本明細書では、基本クラスとして定義されており、そのサブクラスが本明細書ではメディアと称されている。メンバーは、基本クラスである。個人は当該基本クラスからのサブクラスであってもよい。リソース及びメンバーに対する新たなサブクラスは、新たな形式のリソース(例えば、サーバー)及びメンバー(例えば、偏在する計算環境)の組込みといった拡張を可能にする。
【0022】
[0034] 一実施形態において、ハンドセット100は、ブラウザ101と、リソースマネージャー102と、ローカルキャッシュ103と、通知マネージャー104とを備えている。リソースマネージャー102は、リソースを他のハンドセットに供給し、他のグループメンバーのハンドセットによって追加されたリソースを追跡する。通知マネージャー104は、リソースに関する外部からの通知を受信し、それらを処理のために適切な記憶位置へ転送する。ブラウザ101は、ハンドセットのグループが使用可能なリソースのセットにリソースを追加し、リソースを検索し、リソースマネージャー102によって提供されたリソースのリストを得るための要求を指示する。
【0023】
[0035] ネットワークサーバー110は、グループコーディネーター111と、リソースコーディネーター112と、グループキャッシュメモリ113と、通知ディストリビューター114とを備えている。グループコーディネーター111は、ハンドセットグループの調整を取り扱う。この調整はハンドセットグループメンバーシップを管理することを含んでいる。リソースコーディネーター102は、ハンドセットグループに対するリソースの配布及び管理を調整する。通知ディストリビューター114は、リソース並びに当該リソースの配布及び利用可能性に関する通知を伝達可能にする。
【0024】
[0036] 以下、図1Aを参照する。ブラウザ101、又はハンドセット100の別のアプリケーションプログラムは、要求をリソースマネージャー102へ送信する。リソースマネージャーはその要求に対するサービスを実行する。これらの要求は、リソース追加要求、リソース検索要求、及びリソースリスト要求を含んでもよい。リソース追加要求に応答して、リソースマネージャー102は、ハンドセットグループ番号が使用可能なリソースのグループに追加されるべくハンドセット100がホスティングしているリソースを要求する。この要求は、リソースコーディネーター112に対してなされ、リソースコーディネーターは、リソースをキャッシュメモリ113に記憶し及び/又はリソースをグループ内の他のハンドセットへ送信する。リソース検索要求に応答して、リソースマネージャー102は、グループキャッシュメモリ113からリソースを提供するリソースコーディネーター112にリソースを要求するか、又は他のハンドセットがリソースをホスティングしている場合にグループ内の別のハンドセットにリソースを要求する。リソースが得られると、リソースマネージャー102は、リソースをローカルキャッシュメモリ103に記憶させる。リソースリスト要求に応答して、リソースマネージャー102は、ブラウザ101又は別のアプリケーションプロセスに、ローカルキャッシュメモリ103に記憶されたリソースのリストを提供する。
【0025】
全般的プロトコル
【0026】
[0037] 一実施形態においては、動的且つ適応的なメディア処理及び配布によって、ハンドセットとキャリアとの間におけるリソースの動的な取り扱いが実現されている。一実施形態においては、動的且つ適応的なメディアホスティング及び配布によって、四つのメディアホスティング及び配布技術を一組の基準に基づいて切り替えるプロトコルが使用されている。一実施形態においては、この基準には、メディアの人気、及び、メディアによって消費される帯域幅の量が含まれている。一実施形態においては、コンポーネントが、ネットワークの使用状態と、メディアに対する要求の数とを監視する。このコンポーネントは、適応的なスレッシュホールドを使用して、人気のレベルを決定してもよい。
【0027】
[0038] 一実施形態においては、四つのメディアホスティング及び配布形式がある。これらは、リンク投稿/リンク配布、リンク投稿/コンテンツ配布、コンテンツ投稿/リンク配布、コンテンツ投稿/コンテンツ配布と称される。一実施形態においては、メディアの人気が高く且つ使用可能な帯域幅が広い場合には、動的且つ適応的メディア投稿配布モデルのユーザコンテンツ配布/コンテンツ配信がなされる。人気が中程度であり且つ使用可能な帯域幅が中程度である場合には、動的且つ適応的なメディア投稿配布モデルがコンテンツ投稿及びリンク配布のモードに切り換わる。メディアの人気が低く且つ使用可能な帯域幅が狭い場合には、動的且つ適応的メディア投稿及び配布モデルがリンク投稿及びリンク配布モードに切り換えられる。最後に、メディア人気は低いが、使用可能な帯域幅が広い場合には、動的且つ適応メディア投稿及び配布モデルがリンク投稿及びコンテンツ配布モードに切り換えられる。なお、高い(広い)及び低い(狭い)の程度は、互いに相対的なものでよいことに注意されたい。各モデルについて、以下に詳細に説明する。
【0028】
[0039] 上述したインフラストラクチャーは、キャリアのネットワークとハンドセットとの間においてミドルウェアインフラストラクチャーを分割することによって、ハンドセット間でのメディア共有を可能にする。このインフラストラクチャーは、グループ生成及び削除、メンバーシップ管理、並びに通知のための多数のプロトコルを有しており、これらはリソースの共有をサポートするために使用される。一実施形態においては、ハンドセットとキャリアとの間でリソースを動的に取り扱うためのプロトコルが、主として、ハンドセットのリソースマネージャー及びキャリアのサーバー装置のリソースコーディネーターによって調整される。
【0029】
リソース追加プロトコル
【0030】
[0040] このプロトコルによって、ハンドセットユーザは、ローカルリソースを選択して当該ローカルリソースを残りのハンドセットグループに対して使用可能にすることができる。エクスポートされたリソースは、中央サーバーへ転送されるのではなく、ハンドセットに保持される。結果として、ハンドセットは、共有メディアに対する要求にサービスする役割も果たす。
【0031】
[0041] 一実施形態においては、自分のハンドセットのメディアを共有しようとするハンドセットのユーザによってプロトコルが開始される。ユーザは、ハンドセットで作動しているアプリケーションを使用して、リソースを選択し、要求を送信して当該リソースをグループで共有する。ハンドセットで作動しているリソースマネージャーは、キャリアにおいてホスティングされているグループオブジェクトへ要求を送信し、共有されているリソースのURLを提供する。グループオブジェクトは、前もって生成された通知チャンネルを使用して、登録された全てのハンドセットへ通知を送信する。一実施形態においては、この通知は、メッセージ形式「ResourceAdded」と、リソースのURLとを含む。通知チャンネルは、この通知を、登録されているハンドセットの通知マネージャーへ転送する。この通知は、グループにより与えられるオリジナルパラメータと、二つの新たなフィールド、即ちチャンネルの形式及び名前とを含む。通知マネージャーは、この通知を受信して、当該通知を、特定チャンネルに登録されておりハンドセットで実行されている全てのリスナーへ転送する。
【0032】
[0042] 図2は、ハンドセットとキャリアのネットワークとの間におけるリンク投稿及びリンク配布モードを示すデータフロー図である。各々のオペレーションは、ハードウェア(例えば、回路、専用ロジック等)、ソフトウェア(汎用コンピュータシステム又は専用マシンで実行されるような)或いはその両方の組合せで構成されるネットワークサーバー及びハンドセットの処理ロジックによって実行されるものとして説明する。
【0033】
[0043] 以下、図2を参照する。まず、リソースマネージャー102の処理ロジックが、要求を受信して、キャリアによって調整されるグループ内のハンドセットが使用可能なリソースのプールにリソースを追加する。この要求は、ハンドセット100のブラウザ101又は別のアプリケーションから到来してもよい。次に、このリソース追加要求に応答して、リソースマネージャー102の処理ロジックが、ネットワークサーバー110のリソースコーディネーター112へリンクを送信する。次に、リソースハンドラー112の処理ロジックが、このリンクを受信して、グループキャッシュメモリ113に記憶する。また、リソースハンドラー112の処理ロジックが、通知コーディネーター114へも通知を送信する。次に、受信した通知に応答して、通知コーディネーター114の処理ロジックは、グループのメンバーである他のハンドセットへリンクを送信する。通知マネージャー104といったハンドセットの通知マネージャーの処理ロジックは、リンクを受信して記憶する。
【0034】
[0044] 図3は、グループ内のハンドセットが使用可能なリソースへリソースを追加するためのコンテンツ投稿及びリンク配布モードを示すデータフロー図である。オペレーションは、ハードウェア(例えば、回路、専用ロジック等)、ソフトウェア(汎用コンピュータシステム又は専用マシンで実行されるような)或いはその両方の組合せから構成され得るネットワークサーバー及びハンドセットの処理ロジックによって実行される。
【0035】
[0045] 以下、図3を参照する。まず、リソースマネージャー102の処理ロジックが、リソース追加要求を受信する。このリソース追加要求は、ハンドセット100のブラウザ101又は別のアプリケーションから到来してもよい。次に、これに応答して、リソースマネージャー102の処理ロジックが、リソースハンドラー112へコンテンツを送信する。次に、リソースハンドラー112の処理ロジックが、このコンテンツをハンドセット100から受信し、当該コンテンツをグループキャッシュメモリ113に記憶する。また、リソースハンドラー112の処理ロジックが、通知コーディネーター114へも通知を送信する。次に、通知コーディネーター114の処理ロジックが、この通知を受信し、グループのハンドセットへリンクを送信する。通知マネージャー104といったハンドセットの通知マネージャーの処理ロジックは、通知コーディネーター114からリンクを受信する。
【0036】
[0046] 図4は、グループ内のハンドセットが使用可能なリソースへリソースを追加するためのリンク投稿及びコンテンツ配布モードの一実施形態を示すデータフロー図である。このリンク投稿及びコンテンツ配布のオペレーションはキャリアのネットワークサーバー及びハンドセットの処理ロジックによって実行され、ハードウェア(例えば、回路、専用ロジック等)、ソフトウェア(汎用コンピュータシステム又は専用マシンで実行されるような)或いはその両方の組合せから構成される。
【0037】
[0047] 以下、図4を参照する。まず、リソースマネージャー102の処理ロジックが、リソース追加要求を受信する。このリソース追加要求は、ハンドセット100のブラウザ101又は別のアプリケーションから受信されてもよい。次に、このリソース追加要求に応答して、リソースマネージャー102の処理ロジックが、リソースハンドラー112へリソースに対するリンクを送信する。次に、リソースハンドラー112の処理ロジックが、このリンクを受信して、コンテンツをリソースマネージャー102から検索する。コンテンツを受け取った後に、リソースハンドラー112の処理ロジックが、コンテンツをグループキャッシュメモリ113に記憶する。また、リソースハンドラー112の処理ロジックは、リソースが、ハンドセットのグループが使用可能なリソースに追加されたことを示す通知を通知コーディネーター114へも送信する。次に、この通知に応答して、通知コーディネーター114の処理ロジックが、これらの通知を受信し、グループのハンドセットへコンテンツを送信する。そして、通知マネージャー104といったハンドセットの通知マネージャーの処理ロジックは、コンテンツを受信し、当該コンテンツをキャッシュメモリ103といったハンドセットのキャッシュメモリに記憶する。
【0038】
[0048] 図5は、ハンドセットのグループが使用可能なリソースのセットにリソースを追加するためのコンテンツ投稿及びコンテンツ配布モードを示すプロセスの一実施形態のフロー図である。図5のオペレーションは、キャリアのネットワークサーバー110及びハンドセット100の処理ロジックにより実行され、ハードウェア(例えば、回路、専用ロジック等)、ソフトウェア(汎用コンピュータシステム又は専用マシンで実行されるような)或いはその両方の組合せから構成される。
【0039】
[0049] 以下、図5を参照する。まず、このプロセスは、リソースマネージャー102の処理ロジックがリソース追加要求を受信することによって開始される。このリソース追加要求は、ハンドセット100のブラウザ101又は別のアプリケーションから到来してもよい。次に、このリソース追加要求に応答して、リソースマネージャー102の処理ロジックが、ネットワークサーバー110へコンテンツを送信する。次に、ネットワークサーバー110のリソースハンドラー112の処理ロジックが、そのコンテンツを受け取り、グループキャッシュ113に記憶する。また、リソースハンドラー112の処理ロジックは、通知コーディネーター114にも通知を送信する。次に、通知コーディネーター114の処理ロジックが、この通知を受信して、グループのハンドセットへコンテンツを送信する。そして、通知マネージャー104といったハンドセットのグループの通知マネージャーの処理ロジックが、コンテンツを受信して、当該コンテンツをキャッシュメモリ103といったメモリに記憶する。
【0040】
リソースを取得するためのリソースプロトコル
【0041】
[0050] リソース検索プロトコルは、効率的なハンドセットリソースホスティングを実行すると共に、ハンドセットユーザがグループに追加されたリソースを取得することを可能にする。グループにより送信されるメッセージのタイプと、リスナーアダプタにより呼び出されるメソッドについては相違している。グループオブジェクトは、リソース追加(resource added)ではなく検索リソース(retrieve resource)の形式のメッセージを送信し、リスナーアダプタは、以下に詳細に述べるように、ResourceAddedではなく、ResourceRemovedを呼び出す。
【0042】
[0051] 図6及び7は、リソース検索プロトコルの二つの実施形態のデータフロー図である。図6は、リソースがコンテンツとして配布される場合におけるコンテンツからのリソース検索プロトコルを示し、一方、図7は、リソースがリンクとして配布される場合におけるリソース検索プロトコルを示す。
【0043】
[0052] 以下、図6を参照する。リソースを検索するオペレーションは、ハンドアウト及びネットワークサーバーの処理ロジックにより実行され、ハードウェア(例えば、回路、専用ロジック等)、ソフトウェア(汎用コンピュータシステム又は専用マシンで実行されるような)或いはその両方の組合せで構成されてもよい。
【0044】
[0053] 図6を参照すると、まず、リソースマネージャー102の処理ロジックが、ハンドセット100のブラウザ101又は別のアプリケーションからリソース検索要求を受信する。次に、この要求に応答して、リソースマネージャー102が、キャッシュメモリ103をチェックして、ハンドセット100がローカルキャッシュに記憶したリソースを有するかどうかを決定する。もしそうであれば、リソースマネージャー102の処理ロジックは、要求されたリソースを供給する。もしそうでなければ、リソースマネージャー102の処理ロジックは、キャリアのネットワークサーバー110へリソース検索要求を送信する。そして、リソースハンドラー112の処理ロジックが、リソース検索要求を受信し、キャッシュメモリ113にアクセスしてリソースを検索する。次に、それに応答して、リソースハンドラー112の処理ロジックが、リソースを受信して、ハンドセット100へ送信する。次に、リソースマネージャー102の処理ロジックが、リソースハンドラー112からコンテンツを受信して、当該コンテンツをキャッシュメモリ103に記憶する。また、リソースマネージャー102の処理ロジックは、要求を発しているアプリケーションへもリソースを提供する。
【0045】
[0054] 図7によれば、図6を参照して説明したものと同様のリソース検索が実行される。しかしながら、リソースハンドラー112の処理ロジックが、検索要求を受け取って、ローカルキャッシュメモリ113がリソースを有していないと決定すると、リソースハンドラー112の処理ロジックは、リソースを投稿するハンドセット、この場合にはハンドセット200に、リソース検索要求を送信する。次に、リソースマネージャー202の処理ロジックが、この要求を受け取って、キャッシュメモリ203にアクセスする。次に、リソースマネージャーの処理ロジックが、コンテンツを受信して、当該コンテンツをリソースハンドラー112へ送信する。次に、リソースハンドラー112の処理ロジックが、コンテンツを受信して、リソースのコピーをキャッシュメモリ113に記憶すると共に、コンテンツをハンドセット110へ転送する。そして、リソースマネージャー102の処理ロジックが、コンテンツを受信して、キャッシュメモリ103に記憶する。また、リソースマネージャー102の処理ロジックが、リソースを最初に要求したアプリケーション、例えば、ハンドセット110のブラウザ101にもコンテンツを提供する。
【0046】
実装例
【0047】
[0055] 図1Bは、システムアーキテクチャーの全体図である。このアプローチは、ネットワークとハンドセットとの間で分割された非対称的なクライアント−サーバーミドルウェアインフラストラクチャーに基づいて、グループのメディア共有を可能にしている。ネットワークにおけるミドルウェアは、グループ調整(coordination)、メンバーシップ調整、メディア調整、通知調整、及び動的ユーザインターフェイス(UI)バインディング調整のための機能を提供する。ハンドセットにおけるミドルウェアインフラストラクチャーは、グループにメディアを追加しグループからメディアを除去する機能、通知を受け取ってそれをハンドセットに登録された適当なサービスへルーティングする機能、及びデバイスに対してカスタマイズされたユーザインターフェイスを生成する機能を提供する。通知によって、ハンドセットに、グループ、メンバーシップ、及びグループ内のメディア変更が知らされる。
【0048】
[0056] 一実施形態においては、グループコーディネーターは、リモートアクセス可能なオブジェクトであり、グループ生成、削除、保留及び再開を含む全体的なグループ調整の役割を果たす。また、グループコーディネーターは、グループメンバーシップの管理も行なうが、クラス・グループ(Group)のリモートアクセス可能なオブジェクトに機能を委譲する。図8は、両オブジェクトに対するインターフェイスを含むグループコーディネーターの一実施形態のUML図である。
【0049】
[0057] 一実施形態において、各グループは、誰がメディアを公開することができ誰がメディアにアクセスできるかを暗示的に特定するセキュリティドメインを定義する。各グループのセキュリティの振る舞い(behavior)に特有のものが、ポリシー(アクセスポリシー)にカプセル化される。これは、異なるグループ及びコンテクストに対してカスタマイズすることができる。また、グループは、リモートオブジェクトでもあり、グループコーディネーター(group coordinator)によってインスタンス化されたグループサーバー((group server)に登録される。一実施形態においては、各グループは、ピア(ハンドセット)がこれと通信することを可能にする関連リモートリファレンスを有する。グループオブジェクトは、メンバー及びリソースを追加し、除去し、列挙し、獲得するための基本的機能を提供する。更に、一実施形態においては、グループオブジェクトは、他の二つの特定のオブジェクト、即ち通知チャンネル及びリソースハンドラーと対話する。メディア共有モデルは、クライアントに通知を送信し、これらクライアントのグループの状態が変化するときに当該クライアントを最新の状態に保持する。グループオブジェクトのメソッドが呼び出されるたびに、このオブジェクトは、自動的に通知チャンネルを使用して全メンバーに通知する。第2のオブジェクトであるリソースハンドラーは、グループオブジェクトに登録されていて、メンバー及びリソースがグループに追加されたりグループから除去されたりする度に通知を受信する。リソースハンドラーは、全グループのアクティビティへのアクセスを伴う信頼性の高い集中サービスを提供することを目的にしている。リソースハンドラーは、グループ内で送信された通知を記憶することができ、これをクライアント(ハンドセット)が使用して、切断周期後にそれらの状態を同期させることができる。リソースハンドラーは、多数のグループに特有のタスクに使用できるので、特定の機能を提供するためにサブクラス化することができる抽象クラスが提供されている。例えば、WEB/WAP/cHTML/XMLページの形態でグループにエクスポートされる全メディアの概要を生成するDigestMediaHandlerを生成することができる。このページは、グループに追加されておりクライアントデバイスに記憶されているメディアへのリンクを含んでいる。このDigestMediaHandlerは、通知メカニズムに参加しようとしないクライアントが、グループにエクスポートされた全メディアに容易にアクセスすることを可能にする。更に、異なる会社が、既存の会社のテンプレート及びオーサリングツールを用いてダイジェストのレイアウトをカスタマイズし、カスタマイズされた視覚アスペクトをグループに提供することができる。別のリソースハンドラーの例は、自動的にメディアをネットワークにおいてローカルにキャッシュすることができ、それ故、メディアをエクスポートするハンドセットが使用できなくても、そのメディアにアクセスすることを可能にする。グループ共有のデフォールトの振る舞い(behavior)は、ハンドセットにメディアを残すことである。リソースハンドラーの汎用性は、グループの全状態へのアクセスを伴う処理要素を提供する。これは、伝統的なワールドワイドウェブモデルにおけるCGIに匹敵する。
【0050】
[0058] 通知コーディネーター(NC)は、配布されたオブジェクト間に通知を伝達可能にする機能を提供する。一実施形態においては、NCは、通知チャンネル(Notification Channel)と本明細書で称されているオブジェクトに伝達機能を委譲し、通知チャンネルを形成、削除、リスト、及び取得するためのインターフェイスを提供する。一実施形態においては、異なるネットワーク接続、ひいては、異なる通信特性をもつメンバーからグループが構成される。通知チャンネルクラスをサブクラス化して、クライアントが使用しているリンクの形式に関わらず整合性を確保するために、異なる伝達セマンティックスの提供が可能な実装部を提供する。一実施形態においては、各通知チャンネルは、形式(type)及び名前(name)で特徴付けられており、リスナーのリストを有している。更に、通知チャンネルは、リモートオブジェクトとして実装されている。一実施形態においては、三つの基本メソッドであるリスナー追加(add listener)、リスナー除去(remove listener)、及び通知送信(send notification)が通知チャンネルに実装されている。通知送信(SendNotification)のデフォールトの実装部は、チャンネルの形式及び名前と、メソッドの呼出元によって指定されたパラメータとを含む非同期メッセージを、リスナーのリストに対して繰り返して、各リスナーへ送信する。一実施形態では、全てのリスナーが図9に示すインターフェイスを実装しており、このインターフェイスはNotifyと称されるメソッドを定義しており、このNotifyは通知チャンネルによって呼び出される。また、リスナーは、通知チャンネルがリモート呼出しできるようにリモートオブジェクトとして実装されている。
【0051】
[0059] 動的UIバインディングコーディネーター(DUIBC)は、ユーザインターフェイスの生成の間にモバイルデバイスをアシストすることを目的としている。このDUIBCは、特定のUIライブラリーの実装部を登録する機能と、デバイスの能力に基づいてUIライブラリーの実装部を問合せする機能と、ライブラリーの実装部をターゲットデバイスの動的UIバインディングマネージャーにアップロードする機能とを提供する。更に、限定されたリソースをもつデバイス用に、DUIBCは、UIバインディングプロセスを実装して、カスタマイズされたインターフェイスをモバイルデバイスへ送信することができる。なお、非リソース限定デバイスについては、実際のバインディングがデバイスにおいて発生する。
【0052】
[0060] 通知マネージャー(Notification Manager)は、外部通知を受信し、それらを、ローカルデバイスで作動している適切なオブジェクトへリダイレクトする役割を果たす。一実施形態において、通知マネージャーの一つの目的は、二つの面を有しており、(i)イベント配布に対する帯域幅の利用を減少して潜在的には最小にすること、(ii)通知を、登録されているオブジェクトに対して意味のある高レベルのメソッドの呼出しへと変換することである。
【0053】
[0061] 帯域幅を最小化することで、無線(又は無線通信)装置がアクティブである時間を短縮することによって、モバイルデバイスのバッテリ寿命を保持する。通知を取り扱う場合に、一つの実装部は、モバイルデバイスの異なるオブジェクトをリモートチャンネルに登録する。しかしながら、二つ以上のローカルオブジェクトが同じチャンネルに登録される場合には、リモートチャンネルが情報を何回もデバイスへ送信する。代わりに、通知マネージャーは、リモートチャンネルから通知を一度受信し、その通知を、ローカルのプロセス間通信メカニズムを使用してモバイルデバイスにおいてローカルに再配布する。それ故、デバイスによって受信されるデータの量が効果的に削減される。通知マネージャーの第2の目的である通知変換は、高レベルのオブジェクトが、通知に含まれている生のデータを取り扱わねばならないことを回避する。通知マネージャーは、通知を標準的なメソッド呼出しへ変換するアダプタ(リスナーアダプタ)を使用する。それ故、既存のオブジェクトを、実装部に変更を伴わずに、通知マネージャーに登録することが可能になる。
【0054】
[0062] 通知マネージャーは、通知を受信して、当該通知を、特定のチャンネルに登録されておりハンドセットで作動している全てのリスナーへ転送する。リスナーには、リスナーアダプタ及び汎用リスナーの二つの形式がある。リスナーアダプタは、通知を受信して、当該通知をメソッドの要求へと変換する。リソースマネージャーは、リスナーアダプタに登録されている。それ故、通知を受信すると、リスナーアダプタは、三つのパラメータ、チャンネル形式(channel type)、チャンネル名(channel name)及びリソースのURLを用いて、リソースマナージャーの「ResourceAdded」メソッドを呼び出す。リスナーアダプタに登録されていないリスナーは、オリジナル要求を処理する役割を果たす。
【0055】
[0063] 一実施形態においては、通知マネージャーが、リスナーを追加及び除去し、リスナーアダプタを追加及び除去するインターフェイスを提供しており、通知リスナー(Notification Listener)クラスから「notify」メソッドを継承している。リスナーアダプタは、「notify」要求を受信して、その通知の内容に基づいてそれを特定のメソッド要求に変換する。一実施形態において、各リスナーアダプタは、オブジェクトのクラスに割当てられており、自身を通知マネージャーに登録している。通知マネージャーは、リスナーを追加する要求を受信すると、そのクラスを得て、適切なリスナーアダプタを探し、それにリスナーを登録する。リスナーアダプタが見つからない場合には、通知マネージャーは、自身のリスナーリストにオブジェクトを記憶し、チャンネルの形式及び名前が一致するときにオブジェクトの通知メソッドを呼び出す。リスナーアダプタに登録されたオブジェクトに対して、リスナーアダプタは、「notify」の呼出しを獲得して、通知を分析し、登録されたリスナーにおける適切なメソッドを呼び出す。図10は、通知マネージャー及びリスナーアダプタの一実施形態のブロック図である。
【0056】
[0064] リソースマネージャーは、ローカルリソースをグループへエクスポートする機能を提供しており、他のメンバーによってグループに追加されたリソースに関するグローバル情報も保持している。一実施形態において、リソースマネージャーは、通知マネージャーに登録され、通知マネージャーは、リソースがグループに追加されたり除去されたりするときにリソース追加(AddResource)及びリソース除去(RemoveResource)を呼び出す。全グループのリソースに関する情報を維持することは任意であるが、ネットワーク側で作動しているグループコーディネーターへの頻繁な要求を回避することが有用である。
【0057】
[0065] リソースマネージャーは、リソースをリモートピアに供給する役割を果たしており、かかる機能をリソースサーバー(ResourceServer)クラスのオブジェクトへ委譲している。リソースマネージャーは、任意であるが、グループの状態に関するローカル情報を維持するために同期機能を提供することができる。異なる形式のモバイルデバイス及びネットワーク接続は、異なる同期メカニズムを必要とする。このような機能は、同期ポリシーインターフェイスに合致しなければならない外部オブジェクトにカプセル化されている。最終的に、リソースマネージャーは、グループコーディネーターのリソースハンドラーと調整してキャッシュ機構を実装することもできる。キャッシングによって、モバイルデバイスは、リソースをネットワークサイズにプッシュし、到来する全てのトラフィックをリソースハンドラーにリダイレクトすることが可能になる。それ故、到来する要求の数を削減することができる。また、キャッシングは、キャッシングポリシーインターフェイスを実装する外部オブジェクトにより実装されてもよい。
【0058】
[0066] リソースは、グループ及びアプリケーションの形式によって要求されたときに特化することができる基本クラスである。メディアは、リソースのサブクラスとして定義されるが、現在システムの将来例におけるサービスのような他の形式のリソースも考えられる。リソースマネージャーは、異なる形式のリソースの特定の要求に対処するように特化することができる。図11は、リソースマネージャー、同期ポリシー及びキャッシングポリシーに対するUMLクラスダイアグラムである。
【0059】
動的UIバインディングマネージャー(DUIBM)
【0060】
[0067] DUIBMは、特定のデバイスに対して動的にカスタマイズされるユーザインターフェイスを生成するための機能を提供する。一実施形態において、DUIBMは、JSPカスタムタグと同様のメカニズムを使用するが、インターフェイスと共にタグのコードを埋め込むのではなく、DUIBCから適切なコードを動的に得る。一実施形態において、DUIBMは、二つの重要なコンポーネント、即ち、UIライブラリーインターフェイス、及びUIライブラリーの実装部を定義する。
【0061】
[0068] UIライブラリーインターフェイスは、例えば、デバイスに関するリストを提供するコンポーネントといった特定のUIコンポーネント(例えば、小型装置)に対するUIレンダリング又は操作のセマンティックスを定義する。UIライブラリーインターフェイスは、関連のUIインターフェイスコンポーネントの集合である。UIライブラリーインターフェイスは、ライフサイクルコールバックを定義するJavaインターフェイスと、コンポーネント及びその属性を定義するインターフェイス指定子とを用いて定義される。Javaインターフェイスは、JSPカスタムタグインターフェイスと厳密に同じであり、インターフェイス指定子は、JSPカスタムタグを指定するのに使用されるTLD(タグライブラリー指定子)と同様であるが、クラス名のような具体的な実装の細部をもたない。
【0062】
[0069] UIライブラリー実装部は、ライブラリーインターフェイスを実装している。典型的なUIライブラリーパッケージは、インターフェイス指定子、インターフェイスの実装部、及び能力指定子を含むUIライブラリーインターフェイスを備えている。ライブラリーインターフェイス定義部は、そのTLDファイルに指定された実装クラスを有する。能力指定子は、ネームとバリューの対を使用して能力を列挙する。DUIBMは、DUIBCと対話して、適切なUIライブラリー実装部を取得し、更なる参照のためにローカルにキャッシュする。
【0063】
[0070] 開発段階において、UIインターフェイスの開発者は、UIライブラリーインターフェイスについて合意し、これらのインターフェイスをアプリケーションの開発者及びUIライブラリーの実装者に提供する。アプリケーションの開発者は、これらのインターフェイスに対してユーザインターフェイスをコード化し、UIライブラリーの実装者は、具体的な実装部を提供する。開発段階において、JSP及びカスタムタグと同様に、MSPは、開発段階中に潜在的に予めコンパイルされなければならない。しかしながら、JSPとは異なり、生成されたコードは、具体的なUIライブラリー実装部に結び付けられず、代わりに、プロキシ実装部(DUIBC)に結び付けられる。最終的に、ランタイムでは、生成されたインターフェイスが、UIコンポーネントを呼び出す必要があるときに、UIライブラリーインターフェイス名、UIコンポーネント、及びデバイスの能力を用いてDUIBCを呼び出す。DUIBCは、デバイスの能力に適した指定のライブラリーインターフェイス用の実装部を提供するために、UIコントローラのディスカバリーサービスを求める。
【0064】
動的なオンデバイスUIバインディング
【0065】
[0071] このプロトコルは、モバイルデバイスにおいてUIを動的に生成するのに必要なステップを記述している。このプロトコルは、図13に示されている。ハンドセットで作動しているアプリケーションは、UIを要求するときに、ハンドセットで作動している動的UIバインディングマネージャー(DUIBM)に要求を送信し、UIライブラリーインターフェイスの集合を使用するUIテンプレートをそれに提供する。DUIBMは、このUIテンプレートを分析し、UIライブラリーインターフェイスに基づいて、現在のデバイスに適したUIライブラリー実装部を探す。DUIBMは、その内部キャッシュにおいて探索を開始し、適合するものが見つからない場合には、動的UIバインディングコーディネーター(DUIBC)に接続し、モバイルデバイス及び特定のUIライブラリーインターフェイスのプロパティの説明を提供する。DUIBCは、与えられたパラメータを使用して、適切なUIライブラリー実装部を探索し、それをDUIBMへ返送する。全てのUIライブラリー実装部を用いて、DUIBMはUIを生成してそれをアプリケーションへ返送する。
【0066】
[0072] 以上の説明を読めば、本発明の多数の変更や修正が疑いなく当業者に明らかであろうから、一例として図示して説明した特定の実施形態は、本発明を何らこれに限定するものではないことを理解されたい。それ故、種々の実施形態の細部は、本発明の本質とみなされる特徴のみを記載した特許請求の範囲を何ら限定するものではない。
【図面の簡単な説明】
【0067】
【図1A】効率的なリソース共有を実行するためのシステムコンポーネントを示す図である。
【図1B】システムアーキテクチャーの全体的概要を示す図である。
【図2】ハンドセットとキャリアのネットワークサーバーとの間のリンク投稿及びリンク配布モードを示すデータフロー図である。
【図3】グループ内のハンドセットが使用可能なリソースにリソースを追加するためのコンテンツ投稿及びリンク配布モードを示すデータフロー構成図である。
【図4】グループ内のハンドセットが使用可能なリソースにリソースを追加するためのリンク投稿及びリンク配布モードの一実施形態を示すフロー図である。
【図5】ハンドセットのグループが使用可能なリソースのセットにリソースを追加するためのコンテンツ投稿及びコンテンツ配布モードを示すプロセスの一実施形態のフロー構成図である。
【図6】リソースがコンテンツとして配布されるときにコンテンツからのリソース検索プロトコルを示す図である。
【図7】リンクとして配布されるリソースに対するリソース検索プロトコルを示す図である。
【図8】両オブジェクトに対するインターフェイスを含むグループコーディネーターの一実施形態のUMLダイアグラムである。
【図9】通知コーディネーター、通知チャンネル及び通知リスナーの一実施形態のUMLクラスダイアグラムである。
【図10】通知マネージャー及びリスナーアダプタの一実施形態のUMLクラスダイアグラムである。
【図11】リソースマネージャー、同期ポリシー及びキャッシングポリシーのUMLクラスダイアグラムである。
【優先権】
【0001】
[0001] 本特許出願は、2003年6月25日に出願された「Method and Apparatus for Media Sharing Over Handset Terminals」と題する対応の仮出願第60/482,669号の優先権を請求する。
【発明の分野】
【0002】
[0002] 本発明は、移動通信の分野に関するものである。より詳細には、本発明は、モバイルデバイスを介したリソースの共有に関する。
【発明の背景】
【0003】
[0003] ワイヤレスウェブの将来の成功は、パーソナルコンテンツの配信に左右されるであろう。パーソナルコンテンツとは、本明細書では、個人によってリアルタイムに作成されるコンテンツを指すものであって、個人的性質のものである。パーソナルコンテンツの作成及び配信の原始的な形態は、カメラを搭載した携帯電話と、マルチメディアメッセージ、即ちMMSをサポートするキャリアとをベースにして、今日存在している。この形式のコンテンツの配信が原始的であるのは、ポイント・ツー・ポイントのメディアの配信のみ、即ちユーザは、画像を撮影してそれを別のユーザに直接送信することだけが可能であるからである。しかしながら、有線ウェブ(wired web)は、コンテンツの作成及び配信のための非常に精巧なエコシステムを生み出している。但し、有線ウェブは主に会社や企業をターゲットにしている。無線ウェブ(wireless web)は、パーソナルコンテンツ作成のための同様のエコシステムを可能にすべく進化するであろう。しかしながら、この将来展望は、グループマネージメント、メディア配信、及び異種デバイスのための動的なグラフィックユーザインターフェイスマッピングを含む、関連の課題に対処することのできるサポートインフラストラクチャーを必要とする。
【0004】
[0004] インターネットは、歴史的にラジオやテレビにすら先行して最も早く採用されたマスメディアのメカニズムになっている。この成功に対する一つの鍵は、世界的規模でアクセスが可能な情報の公開を、いかなるユーザにも認める共有モデルにある。更に、データのページへのグループ化、及びデータ連結グラフを定義するハイパーリンクの使用によって、データの配布セットを関連付ける簡潔且つ単純なメカニズムが提供されている。インターネットの共有モデルは、四つのプロセス、即ちメディア生成、メディア編成、メディア可視化、及びメディアアクセス、に分割することができる。最初の三つのプロセスは、メディアの公開者に関するものである。一方、最後の一つのプロセスは、エンドユーザ又はメディアビューアに関するものである。メディア生成は、公開者がエクスポートすることを望むデータの収集に関するものである。このデータは、オーディオ、ビデオ及びピクチャーのような取り込まれたメディアと、ドキュメント、アノテーション、及びデータベースからのレコード等の生成されたメディアと、を含んでいる。メディア編成は、メディアの論理的構造化、及び、メディアをいかにユーザに提供するかに関するものである。メディア可視化は、異なるユーザがアクセス可能なデータを管理するためのポリシーを定義する。最後に、メディアアクセスは、ユーザ(メディアビューア)が公開されたデータにアクセスするプロセスである。
【0005】
[0005] 上述した四つのプロセスは、汎用的なものであり、異なるドメインに対応づけることができる。有線ウェブの場合、伝統的なワールドワイドウェブモデルは、有線通信手段を介してインターネットに接続され、且つ、商業的及び個人的なウェブサイトをホスティングするサーバーによって特徴付けられる。無線ウェブは、パーソナル化グループワイドウェブ(Personalized Group Wide Web)と称される共有モデルであり、このウェブは、無線接続されるパーソナルハンドデバイスであって個人情報をホスティングするパーソナルハンドヘルドデバイスの集合を仮定している。この個人情報は、上記デバイスから直接的に、ユーザのグループによって共有されるものである。両モデルは、メディア生成、編成、可視化、及びアクセスに関する相違を有している。本明細書では、この相違を明確にし、無線ウェブモデルに関連した課題を説明し、これらの課題に対応するソフトウェアインフラストラクチャーを提供する。
【0006】
[0006] ヤフーグループは、メッセージ、ピクチャー、及びカレンダーの交換、並びにデータベースへのエントリーを可能にしている。なお、ヤフーグループhttp://groups.yahoo.comを参照されたい。しかしながら、このモデルは、全てのメディアをハンドセットから中央サーバーへアップロードすることが要求されているハンドヘルドユーザ用にカスタマイズされていない。代わりに、PGWWモデルは、メディアがハンドセットから直接エクスポートされており、当該メディアが多数のプロパティに基づいて自動的に移動され得るという仮定に基づいている。
【0007】
[0007] ブロギング(Blogging)は、ダイアリー及びガイドサイトの組合せであり、人々がメディアを公開し、リアルタイムにウェブサイトへリンクすることを可能にしている。なお、ブロッガー・コム(Blogger.com)のhttp://www.blogger.comを参照されたい。しかしながら、ブロギングは、グループの概念を有しておらず、個人がウェブサイトにログインすると、その個人が生成したメディアは誰にでも閲覧可能になる。更に、ブロギングは、ブログをホスティングする中央サーバーへの接続を仮定している。ハンドセットユーザは、データを前処理することによって自分のデバイスを強化することを可能にするツールをもっていない。更に、ブログに投稿された新たなメディアに関してユーザに通知するメカニズムがない。その結果、ユーザは、新規の追加を定期的にチェックしなければならない。
【0008】
[0008] インスタントメッセージ(Instant messaging)は、ユーザがメッセージをリアルタイムに交換することを可能にしており、世界的規模で広く使用されている。詳細な情報については、AOLインスタントメッセンジャーhttp://www.aim.com/index.adp、及びマイクロソフトメッセンジャーhttp://messenger.msn.com/を参照されたい。スマートフォンの登場に伴い、インスタントメッセージングプログラムがこれらデバイスへ移植されており、その結果、ユーザはメッセージをいつでも交換することが可能になっている。パーソナル化グループワイドウェブ用の(即ち、パーソナルコンテンツをグループで共有するための)ミドルウェアインフラストラクチャーは、インスタントメッセージをサポートするように拡張できるが、その元来のアプローチは、関係者がアクセス可能なメディアをユーザが投稿することを可能にすることを目的としている。
【0009】
[0009] モバイル端末間でリソースを共有するメカニズムには、二つの標準的なメカニズムがある。その一つは、全ての機能及びリソースがサーバー側にあるというクライアント−サーバーアプローチを仮定している。クライアントは、サーバーにリソースをプッシュし、また、サーバーからリソースを取得する。二つ目のアプローチは、サーバーインフラストラクチャーがないことを仮定している。その結果、共有インフラストラクチャーは、ピア・ツー・ピアのアプローチに準拠するハンドセット間で分割されている。
【発明の概要】
【0010】
[0010] 本明細書には、ユーザのグループ間でモバイル端末を介してリソースを共有可能にする方法、及び装置が開示されている。一実施形態においては、この装置は、多数のモバイルデバイスの一つとしてキャリアのネットワークデバイスと共に使用するためのモバイルデバイスを備えている。このモバイルデバイスは、一つ以上のメディアリソースを記憶するためのメモリと、リソースマネージャーとを備えている。このリソースマネージャーは、メモリに記憶された一つ以上のメディアリソースを、キャリアのリソースコーディネーターとの協働によって制御して、メディアリソース又は当該メディアリソースへのリンクをリソースコーディネーターに提供すべきかどうかを動的に決定し、モバイルデバイスのグループのうちの他のモバイルデバイスへ一つ以上のメディアリソースを配信可能にする。
【0011】
[0011] 本発明は、種々の実施形態の以下の詳細な説明及び添付の図面から充分に理解されるであろう。しかしながら、これらは、本発明を特定の実施形態に限定するものではなく、本発明の説明及び理解のためのものに過ぎない。
【本発明の詳細な説明】
【0012】
[0024] 本明細書に説明する技術は、上記の二つの標準的なメカニズムの中間的なアプローチをベースにして、モバイルデバイス(例えば、ハンドセット、端末等)間でリソースを共有しようとするものである。より詳細には、サーバーインフラストラクチャーは、グループを調整(coordinate)しており、また、モバイルデバイスがグループマネージメントプロトコルに参加すること、そして、リソースがモバイルデバイスから直接共有されることを仮定している。このアプローチによれば、サーバーが、グループマネージメント要求を調整し、また、双方向プロトコルを実行してモバイルデバイスを最新の状態に維持する。これによって、クライアント−サーバーモデルが強化される。一実施形態においては、モバイル端末がプロトコルに参加する。その結果、モバイル端末は、単一要求ごとにサーバー側のインフラストラクチャーに接続する必要がなくなる。即ち、このプロトコルは、モバイル端末が自身のメモリに最新の情報を保持することを可能にする。純粋なクライアント−サーバーアプローチとは異なり、このモデルは、モバイルデバイスから直接的にリソースを共有している。結果として、モバイル端末が、ローカルリソースをエクスポートし、リモートデバイスからの要求を受け入れるサービスを提供する。
【0013】
[0025] 本明細書に記載されたハイブリッドモデルは、モバイル端末側の切断及び故障に、容易に対処することができる。モバイルデバイスは、自身が切断していること、又はクラッシュしたことを検出すると、サーバーのグループコーディネーター(以下に述べる)に接続して最新のグループ情報を取得することができる。この情報によって、モバイルデバイスは、グループの他のメンバーと同期することが可能になる。
【0014】
[0026] 以下、ハンドセットのグループにおいて動的なメディアの共有を可能にするメカニズム、及びサポート装置について説明する。本明細書に説明する技術は、動的且つ適応的なリソースの投稿及び配布をも実現しており、効率的なハンドセットリソースホスティングのためのメカニズムを含んでいる。一実施形態においては、実行されるハンドセットリソースホスティングが、動的プロトコルに従っており、当該プロトコルによれば、ある状態、即ちスレッシュホールドに到達したときに、ハンドセットがリソースをキャリアのネットワークサーバーへハンドオーバーする。かかるハンドセットの状態は、例えば、過剰帯域幅消費状態、低バッテリ状態、又はストレージ割当状態を含んでいる。過剰帯域幅消費状態にあるときには、多量の帯域幅の使用を回避するために、ハンドセットがメディアリソースを他のハンドセットに提供することを望まないことがある。低バッテリ状態とは、リソースをホスティングしているハンドセットが、望んで低電力状態になってバッテリの電力を節約しており、当該ハンドセットがホスティングしているリソースに対するリソース要求に応答し続けるための電力を維持しなくてもよい状態である。ストレージ割当状態とは、ハンドセットが制限容量(数又はサイズ)を有してリソースをホスティングしており、その制限に達したときに、ハンドセットがそれに代わってホスティングするネットワークにリソースを提供する状態である。
【0015】
[0027] 以下、多くの細部を説明し、本発明をより完全に説明する。しかしながら、当業者であれば、これら特定の細部が無くとも、本発明を実施することができることは明らかであろう。他の例では、本発明を不明瞭にしないために、公知の構造及び装置は、詳細に示さずに、ブロック図で示す。
【0016】
[0028] 以下の詳細な説明の幾つかの部分は、コンピュータメモリ内のデータビットに対するオペレーションのアルゴリズム及び記号表示で表わされている。これらアルゴリズムの記述及び表示は、データ処理技術の当業者がその仕事の実体を他の当業者に最も効率的に伝えるために使用される手段である。アルゴリズムは、本明細書においても、及び一般的にも、希望の結果を導くステップの首尾一貫したシーケンスであると考えられる。これらのステップは、物理量の物理的な操作を要求するものである。必ずしもそうではないが、通常、これらの量は、記憶、転送、合成、比較、及びその他操作することのできる電気的又は磁気的信号の形態をとる。時には、主として共通に使用する理由で、これら信号をビット、値、エレメント、記号、キャラクタ、用語、番号等として参照するのが便利であると分かっている。
【0017】
[0029] しかしながら、これら及び同様の用語は、全て、適当な物理量に関連付けられると共に、これらの量に適用される単なる便利な標号に過ぎないことに注意されたい。以下の説明から明らかなように特に指示のない限り、この説明全体にわたり、「処理」又は「計算」又は「算出」又は「決定」又は「表示」等の用語を使用した議論は、コンピュータシステムのレジスタ及びメモリ内の物理的(電子的)量として表わされたデータを、コンピュータシステムメモリ又はレジスタ或いは他のこのような情報記憶、送信又はディスプレイデバイス内の物理的量として同様に表わされる他のデータへ操作及び変換するコンピュータシステム又は同様の電子計算デバイスのアクション及びプロセスを指すことが明らかであろう。
【0018】
[0030] また、本発明は、これらオペレーションを遂行するための装置にも係る。この装置は、要求された目的に対して特別に構成されてもよいし、或いは記憶されたコンピュータプログラムにより選択的に起動され、又は再構成される汎用コンピュータを備えてもよい。このようなコンピュータプログラムは、コンピュータ読み取り可能な記憶メディアに記憶されてもよく、この記憶メディアは、フロッピーディスク、光学ディスク、CD−ROM、及び磁気−光学ディスクを含む任意の形式のディスク、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、EPROM、EEPROM、磁気又は光学カード、或いはコンピュータシステムバスに各々接続されて電子的命令を記憶するのに適した任意の形式のメディアであるが、これらに限定されない。
【0019】
[0031] また、本明細書に示すアルゴリズム及びディスプレイは、特定のコンピュータや他の装置に固有に関係したものではない。種々の汎用システムを、本明細書の教示に基づくプログラムと共に使用してもよいし、必要な方法ステップを遂行する更に特殊な装置を構成することが便利であることがわかるであろう。これらの種々のシステムに必要な構造は、以下の説明から明らかとなろう。更に、本発明は、特定のプログラミング言語を参照して説明するものではない。ここに述べる本発明の教示を実施するのに種々のプログラミング言語を使用してもよいことが明らかであろう。
【0020】
[0032] マシン読み取り可能なメディアは、マシン(例えば、コンピュータ)により読み取りできる形態で情報を記憶又は送信するためのメカニズムを含む。例えば、マシン読み取り可能なメディアは、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、磁気ディスク記憶メディア、光学記憶メディア、フラッシュメモリデバイス、電気、光学、音響又は他の形態の伝播信号(例えば、搬送波、赤外線信号、デジタル信号等)、等を含んでもよい。
【0021】
[0033] 図1Aは、本明細書に説明する効率的なリソース共有を実行するためのシステムコンポーネントを示している。図1Aを参照すれば、ハンドセット100は、キャリアのネットワークサーバー110に通信可能に結合されて示されている。ハンドセット100は、キャリアによって取り扱われるハンドセットのグループの一部である。ハンドセット100は、如何なるモバイルデバイス(例えば、携帯電話、コンピュータシステム等)であってもよい。キャリアのネットワークサーバー110は、一つ以上のサーバーを含んでもよく、グループ内のハンドセット(及びハンドセットの他のグループ)と協働してキャリアによって実行されるリソース共有を調整する。ネットワークサーバー110は、ハンドセットの多数のグループに対してリソースを調整してもよいことに注意されたい。一つのグループは、一つ以上のメンバー、及び、これらメンバーによって提供される0以上のリソースから構成されている。一実施形態においては、一つのグループが、少なくとも一つのメンバーを有している。但し、グループは、リソースを有していなくてもよい。各リソースは、厳密には一つのメンバーに属しており、各メンバーは、0以上のリソースをグループにエクスポートすることができる。リソースは、本明細書では、基本クラスとして定義されており、そのサブクラスが本明細書ではメディアと称されている。メンバーは、基本クラスである。個人は当該基本クラスからのサブクラスであってもよい。リソース及びメンバーに対する新たなサブクラスは、新たな形式のリソース(例えば、サーバー)及びメンバー(例えば、偏在する計算環境)の組込みといった拡張を可能にする。
【0022】
[0034] 一実施形態において、ハンドセット100は、ブラウザ101と、リソースマネージャー102と、ローカルキャッシュ103と、通知マネージャー104とを備えている。リソースマネージャー102は、リソースを他のハンドセットに供給し、他のグループメンバーのハンドセットによって追加されたリソースを追跡する。通知マネージャー104は、リソースに関する外部からの通知を受信し、それらを処理のために適切な記憶位置へ転送する。ブラウザ101は、ハンドセットのグループが使用可能なリソースのセットにリソースを追加し、リソースを検索し、リソースマネージャー102によって提供されたリソースのリストを得るための要求を指示する。
【0023】
[0035] ネットワークサーバー110は、グループコーディネーター111と、リソースコーディネーター112と、グループキャッシュメモリ113と、通知ディストリビューター114とを備えている。グループコーディネーター111は、ハンドセットグループの調整を取り扱う。この調整はハンドセットグループメンバーシップを管理することを含んでいる。リソースコーディネーター102は、ハンドセットグループに対するリソースの配布及び管理を調整する。通知ディストリビューター114は、リソース並びに当該リソースの配布及び利用可能性に関する通知を伝達可能にする。
【0024】
[0036] 以下、図1Aを参照する。ブラウザ101、又はハンドセット100の別のアプリケーションプログラムは、要求をリソースマネージャー102へ送信する。リソースマネージャーはその要求に対するサービスを実行する。これらの要求は、リソース追加要求、リソース検索要求、及びリソースリスト要求を含んでもよい。リソース追加要求に応答して、リソースマネージャー102は、ハンドセットグループ番号が使用可能なリソースのグループに追加されるべくハンドセット100がホスティングしているリソースを要求する。この要求は、リソースコーディネーター112に対してなされ、リソースコーディネーターは、リソースをキャッシュメモリ113に記憶し及び/又はリソースをグループ内の他のハンドセットへ送信する。リソース検索要求に応答して、リソースマネージャー102は、グループキャッシュメモリ113からリソースを提供するリソースコーディネーター112にリソースを要求するか、又は他のハンドセットがリソースをホスティングしている場合にグループ内の別のハンドセットにリソースを要求する。リソースが得られると、リソースマネージャー102は、リソースをローカルキャッシュメモリ103に記憶させる。リソースリスト要求に応答して、リソースマネージャー102は、ブラウザ101又は別のアプリケーションプロセスに、ローカルキャッシュメモリ103に記憶されたリソースのリストを提供する。
【0025】
全般的プロトコル
【0026】
[0037] 一実施形態においては、動的且つ適応的なメディア処理及び配布によって、ハンドセットとキャリアとの間におけるリソースの動的な取り扱いが実現されている。一実施形態においては、動的且つ適応的なメディアホスティング及び配布によって、四つのメディアホスティング及び配布技術を一組の基準に基づいて切り替えるプロトコルが使用されている。一実施形態においては、この基準には、メディアの人気、及び、メディアによって消費される帯域幅の量が含まれている。一実施形態においては、コンポーネントが、ネットワークの使用状態と、メディアに対する要求の数とを監視する。このコンポーネントは、適応的なスレッシュホールドを使用して、人気のレベルを決定してもよい。
【0027】
[0038] 一実施形態においては、四つのメディアホスティング及び配布形式がある。これらは、リンク投稿/リンク配布、リンク投稿/コンテンツ配布、コンテンツ投稿/リンク配布、コンテンツ投稿/コンテンツ配布と称される。一実施形態においては、メディアの人気が高く且つ使用可能な帯域幅が広い場合には、動的且つ適応的メディア投稿配布モデルのユーザコンテンツ配布/コンテンツ配信がなされる。人気が中程度であり且つ使用可能な帯域幅が中程度である場合には、動的且つ適応的なメディア投稿配布モデルがコンテンツ投稿及びリンク配布のモードに切り換わる。メディアの人気が低く且つ使用可能な帯域幅が狭い場合には、動的且つ適応的メディア投稿及び配布モデルがリンク投稿及びリンク配布モードに切り換えられる。最後に、メディア人気は低いが、使用可能な帯域幅が広い場合には、動的且つ適応メディア投稿及び配布モデルがリンク投稿及びコンテンツ配布モードに切り換えられる。なお、高い(広い)及び低い(狭い)の程度は、互いに相対的なものでよいことに注意されたい。各モデルについて、以下に詳細に説明する。
【0028】
[0039] 上述したインフラストラクチャーは、キャリアのネットワークとハンドセットとの間においてミドルウェアインフラストラクチャーを分割することによって、ハンドセット間でのメディア共有を可能にする。このインフラストラクチャーは、グループ生成及び削除、メンバーシップ管理、並びに通知のための多数のプロトコルを有しており、これらはリソースの共有をサポートするために使用される。一実施形態においては、ハンドセットとキャリアとの間でリソースを動的に取り扱うためのプロトコルが、主として、ハンドセットのリソースマネージャー及びキャリアのサーバー装置のリソースコーディネーターによって調整される。
【0029】
リソース追加プロトコル
【0030】
[0040] このプロトコルによって、ハンドセットユーザは、ローカルリソースを選択して当該ローカルリソースを残りのハンドセットグループに対して使用可能にすることができる。エクスポートされたリソースは、中央サーバーへ転送されるのではなく、ハンドセットに保持される。結果として、ハンドセットは、共有メディアに対する要求にサービスする役割も果たす。
【0031】
[0041] 一実施形態においては、自分のハンドセットのメディアを共有しようとするハンドセットのユーザによってプロトコルが開始される。ユーザは、ハンドセットで作動しているアプリケーションを使用して、リソースを選択し、要求を送信して当該リソースをグループで共有する。ハンドセットで作動しているリソースマネージャーは、キャリアにおいてホスティングされているグループオブジェクトへ要求を送信し、共有されているリソースのURLを提供する。グループオブジェクトは、前もって生成された通知チャンネルを使用して、登録された全てのハンドセットへ通知を送信する。一実施形態においては、この通知は、メッセージ形式「ResourceAdded」と、リソースのURLとを含む。通知チャンネルは、この通知を、登録されているハンドセットの通知マネージャーへ転送する。この通知は、グループにより与えられるオリジナルパラメータと、二つの新たなフィールド、即ちチャンネルの形式及び名前とを含む。通知マネージャーは、この通知を受信して、当該通知を、特定チャンネルに登録されておりハンドセットで実行されている全てのリスナーへ転送する。
【0032】
[0042] 図2は、ハンドセットとキャリアのネットワークとの間におけるリンク投稿及びリンク配布モードを示すデータフロー図である。各々のオペレーションは、ハードウェア(例えば、回路、専用ロジック等)、ソフトウェア(汎用コンピュータシステム又は専用マシンで実行されるような)或いはその両方の組合せで構成されるネットワークサーバー及びハンドセットの処理ロジックによって実行されるものとして説明する。
【0033】
[0043] 以下、図2を参照する。まず、リソースマネージャー102の処理ロジックが、要求を受信して、キャリアによって調整されるグループ内のハンドセットが使用可能なリソースのプールにリソースを追加する。この要求は、ハンドセット100のブラウザ101又は別のアプリケーションから到来してもよい。次に、このリソース追加要求に応答して、リソースマネージャー102の処理ロジックが、ネットワークサーバー110のリソースコーディネーター112へリンクを送信する。次に、リソースハンドラー112の処理ロジックが、このリンクを受信して、グループキャッシュメモリ113に記憶する。また、リソースハンドラー112の処理ロジックが、通知コーディネーター114へも通知を送信する。次に、受信した通知に応答して、通知コーディネーター114の処理ロジックは、グループのメンバーである他のハンドセットへリンクを送信する。通知マネージャー104といったハンドセットの通知マネージャーの処理ロジックは、リンクを受信して記憶する。
【0034】
[0044] 図3は、グループ内のハンドセットが使用可能なリソースへリソースを追加するためのコンテンツ投稿及びリンク配布モードを示すデータフロー図である。オペレーションは、ハードウェア(例えば、回路、専用ロジック等)、ソフトウェア(汎用コンピュータシステム又は専用マシンで実行されるような)或いはその両方の組合せから構成され得るネットワークサーバー及びハンドセットの処理ロジックによって実行される。
【0035】
[0045] 以下、図3を参照する。まず、リソースマネージャー102の処理ロジックが、リソース追加要求を受信する。このリソース追加要求は、ハンドセット100のブラウザ101又は別のアプリケーションから到来してもよい。次に、これに応答して、リソースマネージャー102の処理ロジックが、リソースハンドラー112へコンテンツを送信する。次に、リソースハンドラー112の処理ロジックが、このコンテンツをハンドセット100から受信し、当該コンテンツをグループキャッシュメモリ113に記憶する。また、リソースハンドラー112の処理ロジックが、通知コーディネーター114へも通知を送信する。次に、通知コーディネーター114の処理ロジックが、この通知を受信し、グループのハンドセットへリンクを送信する。通知マネージャー104といったハンドセットの通知マネージャーの処理ロジックは、通知コーディネーター114からリンクを受信する。
【0036】
[0046] 図4は、グループ内のハンドセットが使用可能なリソースへリソースを追加するためのリンク投稿及びコンテンツ配布モードの一実施形態を示すデータフロー図である。このリンク投稿及びコンテンツ配布のオペレーションはキャリアのネットワークサーバー及びハンドセットの処理ロジックによって実行され、ハードウェア(例えば、回路、専用ロジック等)、ソフトウェア(汎用コンピュータシステム又は専用マシンで実行されるような)或いはその両方の組合せから構成される。
【0037】
[0047] 以下、図4を参照する。まず、リソースマネージャー102の処理ロジックが、リソース追加要求を受信する。このリソース追加要求は、ハンドセット100のブラウザ101又は別のアプリケーションから受信されてもよい。次に、このリソース追加要求に応答して、リソースマネージャー102の処理ロジックが、リソースハンドラー112へリソースに対するリンクを送信する。次に、リソースハンドラー112の処理ロジックが、このリンクを受信して、コンテンツをリソースマネージャー102から検索する。コンテンツを受け取った後に、リソースハンドラー112の処理ロジックが、コンテンツをグループキャッシュメモリ113に記憶する。また、リソースハンドラー112の処理ロジックは、リソースが、ハンドセットのグループが使用可能なリソースに追加されたことを示す通知を通知コーディネーター114へも送信する。次に、この通知に応答して、通知コーディネーター114の処理ロジックが、これらの通知を受信し、グループのハンドセットへコンテンツを送信する。そして、通知マネージャー104といったハンドセットの通知マネージャーの処理ロジックは、コンテンツを受信し、当該コンテンツをキャッシュメモリ103といったハンドセットのキャッシュメモリに記憶する。
【0038】
[0048] 図5は、ハンドセットのグループが使用可能なリソースのセットにリソースを追加するためのコンテンツ投稿及びコンテンツ配布モードを示すプロセスの一実施形態のフロー図である。図5のオペレーションは、キャリアのネットワークサーバー110及びハンドセット100の処理ロジックにより実行され、ハードウェア(例えば、回路、専用ロジック等)、ソフトウェア(汎用コンピュータシステム又は専用マシンで実行されるような)或いはその両方の組合せから構成される。
【0039】
[0049] 以下、図5を参照する。まず、このプロセスは、リソースマネージャー102の処理ロジックがリソース追加要求を受信することによって開始される。このリソース追加要求は、ハンドセット100のブラウザ101又は別のアプリケーションから到来してもよい。次に、このリソース追加要求に応答して、リソースマネージャー102の処理ロジックが、ネットワークサーバー110へコンテンツを送信する。次に、ネットワークサーバー110のリソースハンドラー112の処理ロジックが、そのコンテンツを受け取り、グループキャッシュ113に記憶する。また、リソースハンドラー112の処理ロジックは、通知コーディネーター114にも通知を送信する。次に、通知コーディネーター114の処理ロジックが、この通知を受信して、グループのハンドセットへコンテンツを送信する。そして、通知マネージャー104といったハンドセットのグループの通知マネージャーの処理ロジックが、コンテンツを受信して、当該コンテンツをキャッシュメモリ103といったメモリに記憶する。
【0040】
リソースを取得するためのリソースプロトコル
【0041】
[0050] リソース検索プロトコルは、効率的なハンドセットリソースホスティングを実行すると共に、ハンドセットユーザがグループに追加されたリソースを取得することを可能にする。グループにより送信されるメッセージのタイプと、リスナーアダプタにより呼び出されるメソッドについては相違している。グループオブジェクトは、リソース追加(resource added)ではなく検索リソース(retrieve resource)の形式のメッセージを送信し、リスナーアダプタは、以下に詳細に述べるように、ResourceAddedではなく、ResourceRemovedを呼び出す。
【0042】
[0051] 図6及び7は、リソース検索プロトコルの二つの実施形態のデータフロー図である。図6は、リソースがコンテンツとして配布される場合におけるコンテンツからのリソース検索プロトコルを示し、一方、図7は、リソースがリンクとして配布される場合におけるリソース検索プロトコルを示す。
【0043】
[0052] 以下、図6を参照する。リソースを検索するオペレーションは、ハンドアウト及びネットワークサーバーの処理ロジックにより実行され、ハードウェア(例えば、回路、専用ロジック等)、ソフトウェア(汎用コンピュータシステム又は専用マシンで実行されるような)或いはその両方の組合せで構成されてもよい。
【0044】
[0053] 図6を参照すると、まず、リソースマネージャー102の処理ロジックが、ハンドセット100のブラウザ101又は別のアプリケーションからリソース検索要求を受信する。次に、この要求に応答して、リソースマネージャー102が、キャッシュメモリ103をチェックして、ハンドセット100がローカルキャッシュに記憶したリソースを有するかどうかを決定する。もしそうであれば、リソースマネージャー102の処理ロジックは、要求されたリソースを供給する。もしそうでなければ、リソースマネージャー102の処理ロジックは、キャリアのネットワークサーバー110へリソース検索要求を送信する。そして、リソースハンドラー112の処理ロジックが、リソース検索要求を受信し、キャッシュメモリ113にアクセスしてリソースを検索する。次に、それに応答して、リソースハンドラー112の処理ロジックが、リソースを受信して、ハンドセット100へ送信する。次に、リソースマネージャー102の処理ロジックが、リソースハンドラー112からコンテンツを受信して、当該コンテンツをキャッシュメモリ103に記憶する。また、リソースマネージャー102の処理ロジックは、要求を発しているアプリケーションへもリソースを提供する。
【0045】
[0054] 図7によれば、図6を参照して説明したものと同様のリソース検索が実行される。しかしながら、リソースハンドラー112の処理ロジックが、検索要求を受け取って、ローカルキャッシュメモリ113がリソースを有していないと決定すると、リソースハンドラー112の処理ロジックは、リソースを投稿するハンドセット、この場合にはハンドセット200に、リソース検索要求を送信する。次に、リソースマネージャー202の処理ロジックが、この要求を受け取って、キャッシュメモリ203にアクセスする。次に、リソースマネージャーの処理ロジックが、コンテンツを受信して、当該コンテンツをリソースハンドラー112へ送信する。次に、リソースハンドラー112の処理ロジックが、コンテンツを受信して、リソースのコピーをキャッシュメモリ113に記憶すると共に、コンテンツをハンドセット110へ転送する。そして、リソースマネージャー102の処理ロジックが、コンテンツを受信して、キャッシュメモリ103に記憶する。また、リソースマネージャー102の処理ロジックが、リソースを最初に要求したアプリケーション、例えば、ハンドセット110のブラウザ101にもコンテンツを提供する。
【0046】
実装例
【0047】
[0055] 図1Bは、システムアーキテクチャーの全体図である。このアプローチは、ネットワークとハンドセットとの間で分割された非対称的なクライアント−サーバーミドルウェアインフラストラクチャーに基づいて、グループのメディア共有を可能にしている。ネットワークにおけるミドルウェアは、グループ調整(coordination)、メンバーシップ調整、メディア調整、通知調整、及び動的ユーザインターフェイス(UI)バインディング調整のための機能を提供する。ハンドセットにおけるミドルウェアインフラストラクチャーは、グループにメディアを追加しグループからメディアを除去する機能、通知を受け取ってそれをハンドセットに登録された適当なサービスへルーティングする機能、及びデバイスに対してカスタマイズされたユーザインターフェイスを生成する機能を提供する。通知によって、ハンドセットに、グループ、メンバーシップ、及びグループ内のメディア変更が知らされる。
【0048】
[0056] 一実施形態においては、グループコーディネーターは、リモートアクセス可能なオブジェクトであり、グループ生成、削除、保留及び再開を含む全体的なグループ調整の役割を果たす。また、グループコーディネーターは、グループメンバーシップの管理も行なうが、クラス・グループ(Group)のリモートアクセス可能なオブジェクトに機能を委譲する。図8は、両オブジェクトに対するインターフェイスを含むグループコーディネーターの一実施形態のUML図である。
【0049】
[0057] 一実施形態において、各グループは、誰がメディアを公開することができ誰がメディアにアクセスできるかを暗示的に特定するセキュリティドメインを定義する。各グループのセキュリティの振る舞い(behavior)に特有のものが、ポリシー(アクセスポリシー)にカプセル化される。これは、異なるグループ及びコンテクストに対してカスタマイズすることができる。また、グループは、リモートオブジェクトでもあり、グループコーディネーター(group coordinator)によってインスタンス化されたグループサーバー((group server)に登録される。一実施形態においては、各グループは、ピア(ハンドセット)がこれと通信することを可能にする関連リモートリファレンスを有する。グループオブジェクトは、メンバー及びリソースを追加し、除去し、列挙し、獲得するための基本的機能を提供する。更に、一実施形態においては、グループオブジェクトは、他の二つの特定のオブジェクト、即ち通知チャンネル及びリソースハンドラーと対話する。メディア共有モデルは、クライアントに通知を送信し、これらクライアントのグループの状態が変化するときに当該クライアントを最新の状態に保持する。グループオブジェクトのメソッドが呼び出されるたびに、このオブジェクトは、自動的に通知チャンネルを使用して全メンバーに通知する。第2のオブジェクトであるリソースハンドラーは、グループオブジェクトに登録されていて、メンバー及びリソースがグループに追加されたりグループから除去されたりする度に通知を受信する。リソースハンドラーは、全グループのアクティビティへのアクセスを伴う信頼性の高い集中サービスを提供することを目的にしている。リソースハンドラーは、グループ内で送信された通知を記憶することができ、これをクライアント(ハンドセット)が使用して、切断周期後にそれらの状態を同期させることができる。リソースハンドラーは、多数のグループに特有のタスクに使用できるので、特定の機能を提供するためにサブクラス化することができる抽象クラスが提供されている。例えば、WEB/WAP/cHTML/XMLページの形態でグループにエクスポートされる全メディアの概要を生成するDigestMediaHandlerを生成することができる。このページは、グループに追加されておりクライアントデバイスに記憶されているメディアへのリンクを含んでいる。このDigestMediaHandlerは、通知メカニズムに参加しようとしないクライアントが、グループにエクスポートされた全メディアに容易にアクセスすることを可能にする。更に、異なる会社が、既存の会社のテンプレート及びオーサリングツールを用いてダイジェストのレイアウトをカスタマイズし、カスタマイズされた視覚アスペクトをグループに提供することができる。別のリソースハンドラーの例は、自動的にメディアをネットワークにおいてローカルにキャッシュすることができ、それ故、メディアをエクスポートするハンドセットが使用できなくても、そのメディアにアクセスすることを可能にする。グループ共有のデフォールトの振る舞い(behavior)は、ハンドセットにメディアを残すことである。リソースハンドラーの汎用性は、グループの全状態へのアクセスを伴う処理要素を提供する。これは、伝統的なワールドワイドウェブモデルにおけるCGIに匹敵する。
【0050】
[0058] 通知コーディネーター(NC)は、配布されたオブジェクト間に通知を伝達可能にする機能を提供する。一実施形態においては、NCは、通知チャンネル(Notification Channel)と本明細書で称されているオブジェクトに伝達機能を委譲し、通知チャンネルを形成、削除、リスト、及び取得するためのインターフェイスを提供する。一実施形態においては、異なるネットワーク接続、ひいては、異なる通信特性をもつメンバーからグループが構成される。通知チャンネルクラスをサブクラス化して、クライアントが使用しているリンクの形式に関わらず整合性を確保するために、異なる伝達セマンティックスの提供が可能な実装部を提供する。一実施形態においては、各通知チャンネルは、形式(type)及び名前(name)で特徴付けられており、リスナーのリストを有している。更に、通知チャンネルは、リモートオブジェクトとして実装されている。一実施形態においては、三つの基本メソッドであるリスナー追加(add listener)、リスナー除去(remove listener)、及び通知送信(send notification)が通知チャンネルに実装されている。通知送信(SendNotification)のデフォールトの実装部は、チャンネルの形式及び名前と、メソッドの呼出元によって指定されたパラメータとを含む非同期メッセージを、リスナーのリストに対して繰り返して、各リスナーへ送信する。一実施形態では、全てのリスナーが図9に示すインターフェイスを実装しており、このインターフェイスはNotifyと称されるメソッドを定義しており、このNotifyは通知チャンネルによって呼び出される。また、リスナーは、通知チャンネルがリモート呼出しできるようにリモートオブジェクトとして実装されている。
【0051】
[0059] 動的UIバインディングコーディネーター(DUIBC)は、ユーザインターフェイスの生成の間にモバイルデバイスをアシストすることを目的としている。このDUIBCは、特定のUIライブラリーの実装部を登録する機能と、デバイスの能力に基づいてUIライブラリーの実装部を問合せする機能と、ライブラリーの実装部をターゲットデバイスの動的UIバインディングマネージャーにアップロードする機能とを提供する。更に、限定されたリソースをもつデバイス用に、DUIBCは、UIバインディングプロセスを実装して、カスタマイズされたインターフェイスをモバイルデバイスへ送信することができる。なお、非リソース限定デバイスについては、実際のバインディングがデバイスにおいて発生する。
【0052】
[0060] 通知マネージャー(Notification Manager)は、外部通知を受信し、それらを、ローカルデバイスで作動している適切なオブジェクトへリダイレクトする役割を果たす。一実施形態において、通知マネージャーの一つの目的は、二つの面を有しており、(i)イベント配布に対する帯域幅の利用を減少して潜在的には最小にすること、(ii)通知を、登録されているオブジェクトに対して意味のある高レベルのメソッドの呼出しへと変換することである。
【0053】
[0061] 帯域幅を最小化することで、無線(又は無線通信)装置がアクティブである時間を短縮することによって、モバイルデバイスのバッテリ寿命を保持する。通知を取り扱う場合に、一つの実装部は、モバイルデバイスの異なるオブジェクトをリモートチャンネルに登録する。しかしながら、二つ以上のローカルオブジェクトが同じチャンネルに登録される場合には、リモートチャンネルが情報を何回もデバイスへ送信する。代わりに、通知マネージャーは、リモートチャンネルから通知を一度受信し、その通知を、ローカルのプロセス間通信メカニズムを使用してモバイルデバイスにおいてローカルに再配布する。それ故、デバイスによって受信されるデータの量が効果的に削減される。通知マネージャーの第2の目的である通知変換は、高レベルのオブジェクトが、通知に含まれている生のデータを取り扱わねばならないことを回避する。通知マネージャーは、通知を標準的なメソッド呼出しへ変換するアダプタ(リスナーアダプタ)を使用する。それ故、既存のオブジェクトを、実装部に変更を伴わずに、通知マネージャーに登録することが可能になる。
【0054】
[0062] 通知マネージャーは、通知を受信して、当該通知を、特定のチャンネルに登録されておりハンドセットで作動している全てのリスナーへ転送する。リスナーには、リスナーアダプタ及び汎用リスナーの二つの形式がある。リスナーアダプタは、通知を受信して、当該通知をメソッドの要求へと変換する。リソースマネージャーは、リスナーアダプタに登録されている。それ故、通知を受信すると、リスナーアダプタは、三つのパラメータ、チャンネル形式(channel type)、チャンネル名(channel name)及びリソースのURLを用いて、リソースマナージャーの「ResourceAdded」メソッドを呼び出す。リスナーアダプタに登録されていないリスナーは、オリジナル要求を処理する役割を果たす。
【0055】
[0063] 一実施形態においては、通知マネージャーが、リスナーを追加及び除去し、リスナーアダプタを追加及び除去するインターフェイスを提供しており、通知リスナー(Notification Listener)クラスから「notify」メソッドを継承している。リスナーアダプタは、「notify」要求を受信して、その通知の内容に基づいてそれを特定のメソッド要求に変換する。一実施形態において、各リスナーアダプタは、オブジェクトのクラスに割当てられており、自身を通知マネージャーに登録している。通知マネージャーは、リスナーを追加する要求を受信すると、そのクラスを得て、適切なリスナーアダプタを探し、それにリスナーを登録する。リスナーアダプタが見つからない場合には、通知マネージャーは、自身のリスナーリストにオブジェクトを記憶し、チャンネルの形式及び名前が一致するときにオブジェクトの通知メソッドを呼び出す。リスナーアダプタに登録されたオブジェクトに対して、リスナーアダプタは、「notify」の呼出しを獲得して、通知を分析し、登録されたリスナーにおける適切なメソッドを呼び出す。図10は、通知マネージャー及びリスナーアダプタの一実施形態のブロック図である。
【0056】
[0064] リソースマネージャーは、ローカルリソースをグループへエクスポートする機能を提供しており、他のメンバーによってグループに追加されたリソースに関するグローバル情報も保持している。一実施形態において、リソースマネージャーは、通知マネージャーに登録され、通知マネージャーは、リソースがグループに追加されたり除去されたりするときにリソース追加(AddResource)及びリソース除去(RemoveResource)を呼び出す。全グループのリソースに関する情報を維持することは任意であるが、ネットワーク側で作動しているグループコーディネーターへの頻繁な要求を回避することが有用である。
【0057】
[0065] リソースマネージャーは、リソースをリモートピアに供給する役割を果たしており、かかる機能をリソースサーバー(ResourceServer)クラスのオブジェクトへ委譲している。リソースマネージャーは、任意であるが、グループの状態に関するローカル情報を維持するために同期機能を提供することができる。異なる形式のモバイルデバイス及びネットワーク接続は、異なる同期メカニズムを必要とする。このような機能は、同期ポリシーインターフェイスに合致しなければならない外部オブジェクトにカプセル化されている。最終的に、リソースマネージャーは、グループコーディネーターのリソースハンドラーと調整してキャッシュ機構を実装することもできる。キャッシングによって、モバイルデバイスは、リソースをネットワークサイズにプッシュし、到来する全てのトラフィックをリソースハンドラーにリダイレクトすることが可能になる。それ故、到来する要求の数を削減することができる。また、キャッシングは、キャッシングポリシーインターフェイスを実装する外部オブジェクトにより実装されてもよい。
【0058】
[0066] リソースは、グループ及びアプリケーションの形式によって要求されたときに特化することができる基本クラスである。メディアは、リソースのサブクラスとして定義されるが、現在システムの将来例におけるサービスのような他の形式のリソースも考えられる。リソースマネージャーは、異なる形式のリソースの特定の要求に対処するように特化することができる。図11は、リソースマネージャー、同期ポリシー及びキャッシングポリシーに対するUMLクラスダイアグラムである。
【0059】
動的UIバインディングマネージャー(DUIBM)
【0060】
[0067] DUIBMは、特定のデバイスに対して動的にカスタマイズされるユーザインターフェイスを生成するための機能を提供する。一実施形態において、DUIBMは、JSPカスタムタグと同様のメカニズムを使用するが、インターフェイスと共にタグのコードを埋め込むのではなく、DUIBCから適切なコードを動的に得る。一実施形態において、DUIBMは、二つの重要なコンポーネント、即ち、UIライブラリーインターフェイス、及びUIライブラリーの実装部を定義する。
【0061】
[0068] UIライブラリーインターフェイスは、例えば、デバイスに関するリストを提供するコンポーネントといった特定のUIコンポーネント(例えば、小型装置)に対するUIレンダリング又は操作のセマンティックスを定義する。UIライブラリーインターフェイスは、関連のUIインターフェイスコンポーネントの集合である。UIライブラリーインターフェイスは、ライフサイクルコールバックを定義するJavaインターフェイスと、コンポーネント及びその属性を定義するインターフェイス指定子とを用いて定義される。Javaインターフェイスは、JSPカスタムタグインターフェイスと厳密に同じであり、インターフェイス指定子は、JSPカスタムタグを指定するのに使用されるTLD(タグライブラリー指定子)と同様であるが、クラス名のような具体的な実装の細部をもたない。
【0062】
[0069] UIライブラリー実装部は、ライブラリーインターフェイスを実装している。典型的なUIライブラリーパッケージは、インターフェイス指定子、インターフェイスの実装部、及び能力指定子を含むUIライブラリーインターフェイスを備えている。ライブラリーインターフェイス定義部は、そのTLDファイルに指定された実装クラスを有する。能力指定子は、ネームとバリューの対を使用して能力を列挙する。DUIBMは、DUIBCと対話して、適切なUIライブラリー実装部を取得し、更なる参照のためにローカルにキャッシュする。
【0063】
[0070] 開発段階において、UIインターフェイスの開発者は、UIライブラリーインターフェイスについて合意し、これらのインターフェイスをアプリケーションの開発者及びUIライブラリーの実装者に提供する。アプリケーションの開発者は、これらのインターフェイスに対してユーザインターフェイスをコード化し、UIライブラリーの実装者は、具体的な実装部を提供する。開発段階において、JSP及びカスタムタグと同様に、MSPは、開発段階中に潜在的に予めコンパイルされなければならない。しかしながら、JSPとは異なり、生成されたコードは、具体的なUIライブラリー実装部に結び付けられず、代わりに、プロキシ実装部(DUIBC)に結び付けられる。最終的に、ランタイムでは、生成されたインターフェイスが、UIコンポーネントを呼び出す必要があるときに、UIライブラリーインターフェイス名、UIコンポーネント、及びデバイスの能力を用いてDUIBCを呼び出す。DUIBCは、デバイスの能力に適した指定のライブラリーインターフェイス用の実装部を提供するために、UIコントローラのディスカバリーサービスを求める。
【0064】
動的なオンデバイスUIバインディング
【0065】
[0071] このプロトコルは、モバイルデバイスにおいてUIを動的に生成するのに必要なステップを記述している。このプロトコルは、図13に示されている。ハンドセットで作動しているアプリケーションは、UIを要求するときに、ハンドセットで作動している動的UIバインディングマネージャー(DUIBM)に要求を送信し、UIライブラリーインターフェイスの集合を使用するUIテンプレートをそれに提供する。DUIBMは、このUIテンプレートを分析し、UIライブラリーインターフェイスに基づいて、現在のデバイスに適したUIライブラリー実装部を探す。DUIBMは、その内部キャッシュにおいて探索を開始し、適合するものが見つからない場合には、動的UIバインディングコーディネーター(DUIBC)に接続し、モバイルデバイス及び特定のUIライブラリーインターフェイスのプロパティの説明を提供する。DUIBCは、与えられたパラメータを使用して、適切なUIライブラリー実装部を探索し、それをDUIBMへ返送する。全てのUIライブラリー実装部を用いて、DUIBMはUIを生成してそれをアプリケーションへ返送する。
【0066】
[0072] 以上の説明を読めば、本発明の多数の変更や修正が疑いなく当業者に明らかであろうから、一例として図示して説明した特定の実施形態は、本発明を何らこれに限定するものではないことを理解されたい。それ故、種々の実施形態の細部は、本発明の本質とみなされる特徴のみを記載した特許請求の範囲を何ら限定するものではない。
【図面の簡単な説明】
【0067】
【図1A】効率的なリソース共有を実行するためのシステムコンポーネントを示す図である。
【図1B】システムアーキテクチャーの全体的概要を示す図である。
【図2】ハンドセットとキャリアのネットワークサーバーとの間のリンク投稿及びリンク配布モードを示すデータフロー図である。
【図3】グループ内のハンドセットが使用可能なリソースにリソースを追加するためのコンテンツ投稿及びリンク配布モードを示すデータフロー構成図である。
【図4】グループ内のハンドセットが使用可能なリソースにリソースを追加するためのリンク投稿及びリンク配布モードの一実施形態を示すフロー図である。
【図5】ハンドセットのグループが使用可能なリソースのセットにリソースを追加するためのコンテンツ投稿及びコンテンツ配布モードを示すプロセスの一実施形態のフロー構成図である。
【図6】リソースがコンテンツとして配布されるときにコンテンツからのリソース検索プロトコルを示す図である。
【図7】リンクとして配布されるリソースに対するリソース検索プロトコルを示す図である。
【図8】両オブジェクトに対するインターフェイスを含むグループコーディネーターの一実施形態のUMLダイアグラムである。
【図9】通知コーディネーター、通知チャンネル及び通知リスナーの一実施形態のUMLクラスダイアグラムである。
【図10】通知マネージャー及びリスナーアダプタの一実施形態のUMLクラスダイアグラムである。
【図11】リソースマネージャー、同期ポリシー及びキャッシングポリシーのUMLクラスダイアグラムである。
【特許請求の範囲】
【請求項1】
複数のモバイルデバイスの一部としてキャリアのネットワークデバイスと共に使用するためのモバイルデバイスであって、
一つ以上のメディアリソースを記憶するためのメモリと、
前記メモリに記憶された前記一つ以上のメディアリソースを、前記ネットワークデバイスのリソースコーディネーターと協働することによって制御し、メディアリソース又は当該メディアリソースへのリンクを前記リソースコーディネーターに提供すべきか否かを動的に決定し、前記複数のモバイルデバイスのうちの他のモバイルデバイスへ前記一つ以上のメディアリソースを配布可能にするためのリソースマネージャーと、
を備えるモバイルデバイス。
【請求項2】
前記リソースマネージャーと前記ネットワークデバイスのリソースコーディネーターとが協働し、前記モバイルデバイスがリソースへのリンク又はリソースのいずれかを当該モバイルデバイスの状態に基づいて前記リソースコーディネーターに送信することを含むプロトコルを使用して、リソースを動的且つ適応的にハンドオーバーする、請求項1に記載のモバイルデバイス。
【請求項3】
前記リソースマネージャーは、前記ネットワークデバイスの前記リソースコーディネーターへリンクを送信し、更に、前記リソースコーディネーターは、前記リンクを記憶し、当該リンクを前記複数のモバイルデバイスのメンバーのグループへ送信させる、請求項2に記載のモバイルデバイス。
【請求項4】
前記複数のモバイルデバイスは、前記ネットワークデバイスと通信するモバイルデバイスのサブセットである、請求項3に記載のモバイルデバイス。
【請求項5】
前記リソースマネージャーは、前記メディアリソースを前記ネットワークデバイスへ送信し、更に、前記リソースコーディネーターは、前記メディアリソースを記憶して前記メディアリソースへのリンクを前記複数のモバイルデバイスへ送信させ、前記リンクは、前記ネットワークデバイスがアクセス可能なメモリにおける前記メディアリソースの位置を特定する、請求項2に記載のモバイルデバイス。
【請求項6】
前記リソースマネージャーは、前記モバイルデバイスにおけるコンテンツストレージへのリンクを前記リソースコーディネーターへ送信し、それに応答して、前記リソースコーディネーターは、前記モバイルデバイスからコンテンツを検索して当該コンテンツをローカルに記憶し、前記リソースコーディネーターは、前記コンテンツが前記複数のモバイルデバイスへ送信されるようにする、請求項2に記載のモバイルデバイス。
【請求項7】
前記リソースマネージャーは、前記コンテンツを前記リソースコーディネーターへ送信し、前記リソースコーディネーターは、前記コンテンツをローカルに記憶して通知コーディネーターに前記コンテンツを前記複数のモバイルデバイスへ送信させる、請求項6に記載のモバイルデバイス。
【請求項8】
前記リソースマネージャーは、リンク又はコンテンツの投稿、及びリンク又はコンテンツの配布を含む適応リソース配布プロトコルを使用し、前記リンク又はコンテンツを投稿し且つリンク又はコンテンツを配布するための判断が基準に基づいている、請求項1に記載のモバイルデバイス。
【請求項9】
前記配布プロトコルの変更が、リソースの人気に基づく、請求項8に記載のモバイルデバイス。
【請求項10】
前記配布プロトコルの変更が、帯域幅の消費量に基づく、請求項8に記載のモバイルデバイス。
【請求項11】
前記リソースマネージャーと対話してリソースを追加し且つリソースを検索するためのブラウザを更に備える、請求項1に記載のモバイルデバイス。
【請求項12】
通知マネージャーを更に備える、請求項1に記載のモバイルデバイス。
【請求項13】
モバイルデバイスが一つ以上のメディアリソースを記憶するステップと、
前記モバイルデバイスが、メモリに記憶された前記一つ以上のメディアリソースを、ネットワークデバイスのリソースコーディネーターと協働することによって制御し、メディアリソース又は当該メディアリソースへのリンクを前記リソースコーディネーターに提供すべきか否かを動的に決定し、ネットワークにおける複数のモバイルデバイスのうちの他のモバイルデバイスへ前記一つ以上のメディアリソースを配布可能にするステップと、
を含む方法。
【請求項14】
前記モバイルデバイスがリソースへのリンク又はリソースのいずれかを当該モバイルデバイスの状態に基づいて前記リソースコーディネーターに送信することを含むプロトコルを使用して、リソースを動的且つ適応的にハンドオーバーするステップを更に含む、請求項13に記載の方法。
【請求項15】
前記ネットワークデバイスの前記リソースコーディネーターへリンクを送信するステップであって、更に前記リソースコーディネーターが前記リンクを記憶するステップと、
前記リンクを前記複数のモバイルデバイスのメンバーのグループへ送信させるステップと、
を更に含む請求項14に記載の方法。
【請求項16】
前記複数のモバイルデバイスは、前記ネットワークデバイスと通信するモバイルデバイスのサブセットである、請求項15に記載の方法。
【請求項17】
前記メディアリソースを前記ネットワークデバイスへ送信するステップと、
前記ネットワークデバイスが前記メディアリソースを記憶し、前記メディアリソースへのリンクを前記複数のモバイルデバイスへ送信させるステップであって、前記リンクが、前記ネットワークデバイスがアクセス可能なメモリにおける前記メディアリソースの位置を特定するステップと、
を更に含む請求項14に記載のモバイルデバイス。
【請求項18】
前記モバイルデバイスにおけるコンテンツストレージへのリンクを前記ネットワークデバイスの前記リソースコーディネーターへ送信するステップと、
それに応答して、前記ネットワークデバイスの前記リソースコーディネーターが、前記モバイルデバイスからコンテンツを検索し、当該コンテンツをローカルに記憶し、更に、当該コンテンツを前記複数のモバイルデバイスへ送信させるステップと、
を更に含む、請求項14に記載のモバイルデバイス。
【請求項19】
前記コンテンツを前記リソースコーディネーターへ送信し、前記リソースコーディネーターが前記コンテンツをローカルに記憶するステップと、
前記ネットワークデバイスの通知コーディネーターに、前記コンテンツを前記複数のモバイルデバイスへ送信させるステップと、
を更に含む請求項18に記載の方法。
【請求項20】
前記リソースマネージャーが、リンク又はコンテンツの投稿、及びリンク又はコンテンツの配布を含む適応リソース配布プロトコルを使用するステップを更に含み、
当該ステップにおいて、前記リンク又はコンテンツを投稿し且つリンク又はコンテンツを配布するための判断が基準に基づいている、
請求項13に記載の方法。
【請求項21】
前記配布プロトコルの変更が、リソース人気に基づく、請求項20に記載の方法。
【請求項22】
前記配布プロトコルの変更が、帯域幅の消費量に基づく、請求項20に記載の方法。
【請求項23】
モバイルデバイスのグループのうちの第1のモバイルデバイスから第1の通知を受信するステップであって、前記第1の通知が、リソース識別子を含むと共に、前記第1のモバイルデバイスによってホスティングされているリソースを、前記グループに使用可能にするように指示するステップと、
前記リソースが使用可能であることを指示する第2の通知を前記グループ内の他のモバイルデバイスへ送信するステップであって、前記第2通知が前記リソース識別子を含むステップと、
前記他のモバイルデバイスの一つから前記リソースに対する要求を受信するステップと、
前記第1モバイルデバイスから前記リソースを取得するステップと、
前記リソースを前記一つの他のモバイルデバイスに提供するステップと、
を含む方法。
【請求項24】
前記リソース識別子は、URLを含む、請求項23に記載の方法。
【請求項25】
前記第2の通知は、チャンネルの形式及び名前を含む、請求項23に記載の方法。
【請求項26】
複数のモバイルデバイスと、
前記複数のモバイルデバイスに通信可能に結合されたネットワークデバイスと、
を備え、
前記ネットワークデバイスは、
前記複数のモバイルデバイスを調整するためのグループコーディネーターと、
前記複数のモバイルデバイスに対するメディアリソースを取得するためのリソースコーディネーターと、
前記複数のモバイルデバイスのうちのモバイルデバイスが使用可能なメディアリソースを通知するための通知ディストリビューターと
を有しており、
前記複数のモバイルデバイスの各々は、一つ以上のメディアリソースをホスティングし、且つ個々のモバイルデバイスがある状態にあるときに前記ネットワークと協働して、前記個々のモバイルデバイスが前記ネットワークへリソースをハンドオーバーする、
システム。
【請求項27】
前記個々のモバイルデバイスのリソースマネージャーと、前記ネットワークデバイスのリソースコーディネーターとが協働し、前記モバイルデバイスがリソースへのリンク又はリソースのいずれかを当該モバイルデバイスの状態に基づいて前記リソースコーディネーターに送信することを含むプロトコルを使用して、リソースを動的に且つ適応的にハンドオーバーする、請求項26に記載のシステム。
【請求項28】
前記状態は、過剰帯域幅消費状態、低バッテリ電力状態、及びストレージ割当状態から成るグループから選択されたものである、請求項27に記載のシステム。
【請求項29】
前記リソースマネージャーは、前記ネットワークデバイスの前記リソースコーディネーターへリンクを送信し、更に、前記リソースコーディネーターは、当該リンクを記憶して、前記通知コーディネーターに前記リンクを前記複数のモバイルデバイスのメンバーのグループへ送信させる、請求項26に記載のシステム。
【請求項30】
前記複数のモバイルデバイスは、前記ネットワークデバイスと通信するモバイルデバイスのサブセットである、請求項26に記載のシステム。
【請求項31】
前記リソースマネージャーは、前記メディアリソースを前記ネットワークデバイスへ送信し、更に、前記リソースコーディネーターは、前記メディアリソースを記憶して、前記通知コーディネーターに前記メディアリソースへのリンクを前記複数のモバイルデバイスへ送信させ、前記リンクは、前記ネットワークデバイスがアクセス可能なメモリにおける前記メディアリソースを特定する、請求項26に記載のシステム。
【請求項32】
前記リソースマネージャーは、前記モバイルデバイスにおけるコンテンツストレージへのリンクを前記リソースコーディネーターへ送信し、更に、それに応答して、前記リソースコーディネーターが、前記個々のモバイルデバイスからコンテンツを検索して当該コンテンツをローカル記憶し、更に、前記リソースコーディネーターは、前記通知コーディネーターに前記コンテンツを前記複数のモバイルデバイスへ送信させる、請求項31に記載のシステム。
【請求項33】
前記リソースマネージャーは、前記コンテンツを前記リソースコーディネーターへ送信し、前記リソースコーディネーターは、前記コンテンツをローカルに記憶して、前記通知コーディネーターに前記コンテンツを前記複数のモバイルデバイスへ送信させる、請求項32に記載のシステム。
【請求項34】
前記リソースコーディネーターは、リンク又はコンテンツの投稿、及びリンク又はコンテンツの配布を含む適応リソース配布プロトコルを使用し、リンク又はコンテンツを投稿し且つリンク又はコンテンツを配布するための判断が基準に基づいている、請求項26に記載のシステム。
【請求項35】
前記基準は、リソースの人気を含む、請求項34に記載のシステム。
【請求項36】
前記配布プロトコルの変更は、帯域幅の消費量に基づく、請求項34に記載のシステム。
【請求項37】
グループコーディネーターと、
複数のモバイルデバイスに対するメディアを取得するためのリソースコーディネーターと、
前記複数のモバイルデバイスのうちのモバイルデバイスに、受信されたメディアリソースを通知するための通知ディストリビューターと、
を備え、
前記リソースコーディネーターと前記通知ディストリビューターとが、前記複数のモバイルデバイスと協働して、前記モバイルデバイスがリソースへのリンク又はリソースのいずれかを当該モバイルデバイスの状態に基づいて前記リソースコーディネーターに送信することを含むプロトコルを使用して、リソースへの動的且つ適応的なアクセスを可能にする、
キャリア。
【請求項1】
複数のモバイルデバイスの一部としてキャリアのネットワークデバイスと共に使用するためのモバイルデバイスであって、
一つ以上のメディアリソースを記憶するためのメモリと、
前記メモリに記憶された前記一つ以上のメディアリソースを、前記ネットワークデバイスのリソースコーディネーターと協働することによって制御し、メディアリソース又は当該メディアリソースへのリンクを前記リソースコーディネーターに提供すべきか否かを動的に決定し、前記複数のモバイルデバイスのうちの他のモバイルデバイスへ前記一つ以上のメディアリソースを配布可能にするためのリソースマネージャーと、
を備えるモバイルデバイス。
【請求項2】
前記リソースマネージャーと前記ネットワークデバイスのリソースコーディネーターとが協働し、前記モバイルデバイスがリソースへのリンク又はリソースのいずれかを当該モバイルデバイスの状態に基づいて前記リソースコーディネーターに送信することを含むプロトコルを使用して、リソースを動的且つ適応的にハンドオーバーする、請求項1に記載のモバイルデバイス。
【請求項3】
前記リソースマネージャーは、前記ネットワークデバイスの前記リソースコーディネーターへリンクを送信し、更に、前記リソースコーディネーターは、前記リンクを記憶し、当該リンクを前記複数のモバイルデバイスのメンバーのグループへ送信させる、請求項2に記載のモバイルデバイス。
【請求項4】
前記複数のモバイルデバイスは、前記ネットワークデバイスと通信するモバイルデバイスのサブセットである、請求項3に記載のモバイルデバイス。
【請求項5】
前記リソースマネージャーは、前記メディアリソースを前記ネットワークデバイスへ送信し、更に、前記リソースコーディネーターは、前記メディアリソースを記憶して前記メディアリソースへのリンクを前記複数のモバイルデバイスへ送信させ、前記リンクは、前記ネットワークデバイスがアクセス可能なメモリにおける前記メディアリソースの位置を特定する、請求項2に記載のモバイルデバイス。
【請求項6】
前記リソースマネージャーは、前記モバイルデバイスにおけるコンテンツストレージへのリンクを前記リソースコーディネーターへ送信し、それに応答して、前記リソースコーディネーターは、前記モバイルデバイスからコンテンツを検索して当該コンテンツをローカルに記憶し、前記リソースコーディネーターは、前記コンテンツが前記複数のモバイルデバイスへ送信されるようにする、請求項2に記載のモバイルデバイス。
【請求項7】
前記リソースマネージャーは、前記コンテンツを前記リソースコーディネーターへ送信し、前記リソースコーディネーターは、前記コンテンツをローカルに記憶して通知コーディネーターに前記コンテンツを前記複数のモバイルデバイスへ送信させる、請求項6に記載のモバイルデバイス。
【請求項8】
前記リソースマネージャーは、リンク又はコンテンツの投稿、及びリンク又はコンテンツの配布を含む適応リソース配布プロトコルを使用し、前記リンク又はコンテンツを投稿し且つリンク又はコンテンツを配布するための判断が基準に基づいている、請求項1に記載のモバイルデバイス。
【請求項9】
前記配布プロトコルの変更が、リソースの人気に基づく、請求項8に記載のモバイルデバイス。
【請求項10】
前記配布プロトコルの変更が、帯域幅の消費量に基づく、請求項8に記載のモバイルデバイス。
【請求項11】
前記リソースマネージャーと対話してリソースを追加し且つリソースを検索するためのブラウザを更に備える、請求項1に記載のモバイルデバイス。
【請求項12】
通知マネージャーを更に備える、請求項1に記載のモバイルデバイス。
【請求項13】
モバイルデバイスが一つ以上のメディアリソースを記憶するステップと、
前記モバイルデバイスが、メモリに記憶された前記一つ以上のメディアリソースを、ネットワークデバイスのリソースコーディネーターと協働することによって制御し、メディアリソース又は当該メディアリソースへのリンクを前記リソースコーディネーターに提供すべきか否かを動的に決定し、ネットワークにおける複数のモバイルデバイスのうちの他のモバイルデバイスへ前記一つ以上のメディアリソースを配布可能にするステップと、
を含む方法。
【請求項14】
前記モバイルデバイスがリソースへのリンク又はリソースのいずれかを当該モバイルデバイスの状態に基づいて前記リソースコーディネーターに送信することを含むプロトコルを使用して、リソースを動的且つ適応的にハンドオーバーするステップを更に含む、請求項13に記載の方法。
【請求項15】
前記ネットワークデバイスの前記リソースコーディネーターへリンクを送信するステップであって、更に前記リソースコーディネーターが前記リンクを記憶するステップと、
前記リンクを前記複数のモバイルデバイスのメンバーのグループへ送信させるステップと、
を更に含む請求項14に記載の方法。
【請求項16】
前記複数のモバイルデバイスは、前記ネットワークデバイスと通信するモバイルデバイスのサブセットである、請求項15に記載の方法。
【請求項17】
前記メディアリソースを前記ネットワークデバイスへ送信するステップと、
前記ネットワークデバイスが前記メディアリソースを記憶し、前記メディアリソースへのリンクを前記複数のモバイルデバイスへ送信させるステップであって、前記リンクが、前記ネットワークデバイスがアクセス可能なメモリにおける前記メディアリソースの位置を特定するステップと、
を更に含む請求項14に記載のモバイルデバイス。
【請求項18】
前記モバイルデバイスにおけるコンテンツストレージへのリンクを前記ネットワークデバイスの前記リソースコーディネーターへ送信するステップと、
それに応答して、前記ネットワークデバイスの前記リソースコーディネーターが、前記モバイルデバイスからコンテンツを検索し、当該コンテンツをローカルに記憶し、更に、当該コンテンツを前記複数のモバイルデバイスへ送信させるステップと、
を更に含む、請求項14に記載のモバイルデバイス。
【請求項19】
前記コンテンツを前記リソースコーディネーターへ送信し、前記リソースコーディネーターが前記コンテンツをローカルに記憶するステップと、
前記ネットワークデバイスの通知コーディネーターに、前記コンテンツを前記複数のモバイルデバイスへ送信させるステップと、
を更に含む請求項18に記載の方法。
【請求項20】
前記リソースマネージャーが、リンク又はコンテンツの投稿、及びリンク又はコンテンツの配布を含む適応リソース配布プロトコルを使用するステップを更に含み、
当該ステップにおいて、前記リンク又はコンテンツを投稿し且つリンク又はコンテンツを配布するための判断が基準に基づいている、
請求項13に記載の方法。
【請求項21】
前記配布プロトコルの変更が、リソース人気に基づく、請求項20に記載の方法。
【請求項22】
前記配布プロトコルの変更が、帯域幅の消費量に基づく、請求項20に記載の方法。
【請求項23】
モバイルデバイスのグループのうちの第1のモバイルデバイスから第1の通知を受信するステップであって、前記第1の通知が、リソース識別子を含むと共に、前記第1のモバイルデバイスによってホスティングされているリソースを、前記グループに使用可能にするように指示するステップと、
前記リソースが使用可能であることを指示する第2の通知を前記グループ内の他のモバイルデバイスへ送信するステップであって、前記第2通知が前記リソース識別子を含むステップと、
前記他のモバイルデバイスの一つから前記リソースに対する要求を受信するステップと、
前記第1モバイルデバイスから前記リソースを取得するステップと、
前記リソースを前記一つの他のモバイルデバイスに提供するステップと、
を含む方法。
【請求項24】
前記リソース識別子は、URLを含む、請求項23に記載の方法。
【請求項25】
前記第2の通知は、チャンネルの形式及び名前を含む、請求項23に記載の方法。
【請求項26】
複数のモバイルデバイスと、
前記複数のモバイルデバイスに通信可能に結合されたネットワークデバイスと、
を備え、
前記ネットワークデバイスは、
前記複数のモバイルデバイスを調整するためのグループコーディネーターと、
前記複数のモバイルデバイスに対するメディアリソースを取得するためのリソースコーディネーターと、
前記複数のモバイルデバイスのうちのモバイルデバイスが使用可能なメディアリソースを通知するための通知ディストリビューターと
を有しており、
前記複数のモバイルデバイスの各々は、一つ以上のメディアリソースをホスティングし、且つ個々のモバイルデバイスがある状態にあるときに前記ネットワークと協働して、前記個々のモバイルデバイスが前記ネットワークへリソースをハンドオーバーする、
システム。
【請求項27】
前記個々のモバイルデバイスのリソースマネージャーと、前記ネットワークデバイスのリソースコーディネーターとが協働し、前記モバイルデバイスがリソースへのリンク又はリソースのいずれかを当該モバイルデバイスの状態に基づいて前記リソースコーディネーターに送信することを含むプロトコルを使用して、リソースを動的に且つ適応的にハンドオーバーする、請求項26に記載のシステム。
【請求項28】
前記状態は、過剰帯域幅消費状態、低バッテリ電力状態、及びストレージ割当状態から成るグループから選択されたものである、請求項27に記載のシステム。
【請求項29】
前記リソースマネージャーは、前記ネットワークデバイスの前記リソースコーディネーターへリンクを送信し、更に、前記リソースコーディネーターは、当該リンクを記憶して、前記通知コーディネーターに前記リンクを前記複数のモバイルデバイスのメンバーのグループへ送信させる、請求項26に記載のシステム。
【請求項30】
前記複数のモバイルデバイスは、前記ネットワークデバイスと通信するモバイルデバイスのサブセットである、請求項26に記載のシステム。
【請求項31】
前記リソースマネージャーは、前記メディアリソースを前記ネットワークデバイスへ送信し、更に、前記リソースコーディネーターは、前記メディアリソースを記憶して、前記通知コーディネーターに前記メディアリソースへのリンクを前記複数のモバイルデバイスへ送信させ、前記リンクは、前記ネットワークデバイスがアクセス可能なメモリにおける前記メディアリソースを特定する、請求項26に記載のシステム。
【請求項32】
前記リソースマネージャーは、前記モバイルデバイスにおけるコンテンツストレージへのリンクを前記リソースコーディネーターへ送信し、更に、それに応答して、前記リソースコーディネーターが、前記個々のモバイルデバイスからコンテンツを検索して当該コンテンツをローカル記憶し、更に、前記リソースコーディネーターは、前記通知コーディネーターに前記コンテンツを前記複数のモバイルデバイスへ送信させる、請求項31に記載のシステム。
【請求項33】
前記リソースマネージャーは、前記コンテンツを前記リソースコーディネーターへ送信し、前記リソースコーディネーターは、前記コンテンツをローカルに記憶して、前記通知コーディネーターに前記コンテンツを前記複数のモバイルデバイスへ送信させる、請求項32に記載のシステム。
【請求項34】
前記リソースコーディネーターは、リンク又はコンテンツの投稿、及びリンク又はコンテンツの配布を含む適応リソース配布プロトコルを使用し、リンク又はコンテンツを投稿し且つリンク又はコンテンツを配布するための判断が基準に基づいている、請求項26に記載のシステム。
【請求項35】
前記基準は、リソースの人気を含む、請求項34に記載のシステム。
【請求項36】
前記配布プロトコルの変更は、帯域幅の消費量に基づく、請求項34に記載のシステム。
【請求項37】
グループコーディネーターと、
複数のモバイルデバイスに対するメディアを取得するためのリソースコーディネーターと、
前記複数のモバイルデバイスのうちのモバイルデバイスに、受信されたメディアリソースを通知するための通知ディストリビューターと、
を備え、
前記リソースコーディネーターと前記通知ディストリビューターとが、前記複数のモバイルデバイスと協働して、前記モバイルデバイスがリソースへのリンク又はリソースのいずれかを当該モバイルデバイスの状態に基づいて前記リソースコーディネーターに送信することを含むプロトコルを使用して、リソースへの動的且つ適応的なアクセスを可能にする、
キャリア。
【図1A】
【図1B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図1B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【公表番号】特表2007−525079(P2007−525079A)
【公表日】平成19年8月30日(2007.8.30)
【国際特許分類】
【出願番号】特願2006−517629(P2006−517629)
【出願日】平成16年6月23日(2004.6.23)
【国際出願番号】PCT/US2004/020320
【国際公開番号】WO2005/002179
【国際公開日】平成17年1月6日(2005.1.6)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.フロッピー
2.JAVA
【出願人】(392026693)株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Fターム(参考)】
【公表日】平成19年8月30日(2007.8.30)
【国際特許分類】
【出願日】平成16年6月23日(2004.6.23)
【国際出願番号】PCT/US2004/020320
【国際公開番号】WO2005/002179
【国際公開日】平成17年1月6日(2005.1.6)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.フロッピー
2.JAVA
【出願人】(392026693)株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Fターム(参考)】
[ Back to top ]