(57)【要約】  ＭＴＰ上でホストアプリケーションまたはホストプロセスにクライアントデバイス上の自己記述型のデバイスによってホストされるサービスを公開するための構成が提供され、それによって、新たなＭＴＰコマンドを備えるＭＴＰ（メディア転送プロトコル）拡張により、デバイスによってホストされるサービスが既存のＭＴＰ実施形態に対して後方互換性および前方互換性を有することが可能になる。この拡張における新たなＭＴＰコマンドは、ホストによる、接続されたクライアントデバイスによって提供されるデバイスによってホストされるサービスの発見を可能にする。【選択図】図６
2010541043.tif 000002
【特許請求の範囲】
【請求項１】
ホスト（１０２）からデバイス（１１０）上でホストされるサービス（６１０）にアクセスするための方法において、
前記サービス（６１０）をホストする前記デバイス（１１０）と通信するステップであって、前記デバイスによってホストされるサービス（６１０）は、１つまたは複数のオブジェクトストア（６２０）に関連付けられ、さらに前記ホスト（１０２）によってサポートされるプログラミングインターフェース（１１２６）を介して行われるコマンドに応答して前記ストア（６２０）の中のオブジェクト（６２６、６２９）を公開するようにさらに構成される、ステップと、
前記プログラミングインターフェース（１１２６）を介して前記ホスト（１０２）に前記デバイスによってホストされるサービス（６１０）をブリッジするステップと、
前記デバイスによってホストされるサービス（６１０）を使用して前記オブジェクト（６２６、６２９）にアクセスするステップとを備える方法。
【請求項２】
前記サービスは、ストレージサービス、機能デバイスサービス、または情報サービスの１つである請求項１に記載の方法。
【請求項３】
前記ストレージサービスは、連絡先サービス、カレンダーサービス、ＳＭＳサービス、着信音サービス、壁紙サービス、またはデータストレージサービスから成るグループから選択される請求項２に記載の方法。
【請求項４】
前記機能デバイスサービスは、電話サービス、デバイス設定サービス、またはデバイスステータスサービスから成るグループから選択される請求項２に記載の方法。
【請求項５】
前記ホストは、シンクライアントまたはシッククライアントのいずれかによってサポートされるウェブ体験を備えるサービス指向アーキテクチャーをサポートする請求項１に記載の方法。
【請求項６】
ストレージサービスまたは機能デバイスサービスが、サードパーティによって定義され、前記サードパーティは、前記デバイスの製造業者でも、ホストの製造業者でもないパーティである請求項２に記載の方法。
【請求項７】
前記デバイスと前記通信するステップは、ＭＴＰプロトコル上で実行される請求項１に記載の方法。
【請求項８】
クエリーに応答して前記デバイスによってホストされるサービスの記述を受信するさらなるステップを含む請求項１に記載の方法。
【請求項９】
前記プログラミングインターフェースを介して前記記述の中で識別される型のオブジェクトの作成を可能にするさらなるステップを含む請求項８に記載の方法。
【請求項１０】
前記プログラミングインターフェースを介して前記オブジェクトに関連するプロパティを公開するさらなるステップを含む請求項９に記載の方法。
【請求項１１】
前記プログラミングインターフェースを介して前記オブジェクトに関連するメソッドを公開するさらなるステップを含む請求項１に記載の方法。
【請求項１２】
前記プログラミングインターフェースは、Ｗｉｎｄｏｗｓ環境における１つまたは複数のＣＯＭコンポーネントによって実施されるＩＤｉｓｐａｔｃｈを備える請求項１に記載の方法。
【請求項１３】
外部ホストからプログラマティックコントロールも前記デバイスによってホストされる、を公開するようにスクリプティング環境またはプログラミング環境に前記デバイスによってホストされるサービスをバインドするさらなるステップを含む請求項１に記載の方法。
【請求項１４】
プログラマティックコントロールに前記デバイスによってホストされるサービスを公開し、前記プログラマティックコントロールは、スクリプティング環境またはプログラミング環境を使用して実施されるさらなるステップを含む請求項１に記載の方法。
【請求項１５】
前記プログラミング環境は、ＷｉｎｄｏｗｓベースのＡＰＩおよびプログラミングのモデルまたはＪａｖａプログラミングモデルを備える請求項１４に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
マイクロソフトコーポレーションは、ストレージを有する任意のポータブルデバイス上のコンテンツを管理するメディア転送プロトコル（「ＭＴＰ」）を開発した。ＭＴＰは、既存のプロトコル、ピクチャー転送プロトコル（「ＰＴＰ」）に基づき、さらにそのプロトコルに完全と適合するように実施されることが可能である。ＭＴＰは、パーソナルコンピューター（「ＰＣ」）または他のホストに接続され、データを交換し、さらにその後、スタンドアロン使用のために切断されるデバイス間の通信を円滑にするのに通常、使用される。ＭＴＰの二次的な目的は、接続されたデバイスのコマンドおよび制御を可能にすることである。このことには、デバイス機能の遠隔制御、デバイスによって開始されるイベントの監視、ならびにデバイスプロパティの読み取りおよび設定が含まれる。
【０００２】
簡単なデバイスは、デバイスベンダーが、ファームウェアおよびドライバーへの最小限の投資しかせずに製品を開発することを可能にするＭＴＰ機能の最小セットを実施することが可能である。より高度なデバイスは、完全なＭＴＰフィーチャーセットを活用すること、またはそのようなセットを、ベンダー固有のプラグインで拡張することができる。例えば、ＭＴＰは、イメージ、オーディオ、ビデオ、再生リスト、または他の任意のメディアオブジェクトを転送するのに使用されることが可能である。また、ＭＴＰは、オペレーティングシステムを介してアプリケーションに公開されるトランスポート制御を含む、デバイス動作に対する直接の制御も提供する。デバイスがアクセスすることができる形態でオブジェクトにメタデータを付加することによって、ＭＴＰは、アーティスト、アルバム、ジャンル、およびトラックなどのプロパティを一般的な仕方で関連付けてデバイスユーザーインターフェースを円滑にすることができる。
【０００３】
ＭＴＰは、デバイスコンテンツとＰＣ上のライブラリの間で共有されるファイルをマッチングして、連絡先リストまたはタスクリストなどのデータの動機を可能にするのに使用されることが可能である。また、ＭＴＰは、大きいストレージおよび数千のアイテムを有するデバイスに非常に迅速にインデックス付けして、その結果、大容量ストレージデバイスに関する動作を初期設定することができる最適化されたコンテンツ記述のためのツールを提供することもできる。また、１つのファイルを別のファイルに関連付けるのにリファレンスが使用されることも可能であり、このことは、再生リストを作成するため、およびＤＲＭ（デジタル権利管理）ライセンスをコンテンツに関連付けるために役立つ。
【０００４】
デバイス製造業者は、独自のデバイス接続ソリューションを設計し、開発し、さらにサポートする必要性を減らすのに役立つようにＭＴＰクラスドライバーサポートを活用することができる。ＭＴＰは、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）デバイスアーキテクチャーに緊密に、予測できるように統合され、このことは、サードパーティアプリケーションを開発することの費用を低減するのに役立ち、さらにＷｉｎｄｏｗｓの将来のバージョンとの互換性を確実にするのに役立つ。また、ＭＴＰは、製造業者が、単純なスケーリングを介して複数のデバイスおよびクラスに関して共通のソリューションを実施することができるように一般化されるとともに、拡張可能であり、このことは、ファームウェア開発費用を低減するのに役立ち、さらに安定性を向上させるのに役立つ。
【０００５】
ＭＴＰの導入以来、マイクロソフトコーポレーションは、Ｗｉｎｄｏｗｓ  Ｐｏｒｔａｂｌｅ  Ｄｅｖｉｃｅ（「ＷＰＤ」）プラットフォームも開発してきた。ＷＰＤ  ＡＰＩ（アプリケーションプログラミングインターフェース）は、デバイスのより豊かなエコシステムを促進するようにＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓアプリケーションからのデバイス接続プロトコルの抽象化を提供する。ＭＴＰが、最も優れたＷＰＤデバイス接続プロトコルである一方で、独自のプロトコル、または他の標準ベースのプロトコルを有するデバイスベンダーも、ＷＰＤの枠組み内でデバイス接続モデルとして登録して、ベンダーのデバイスも、変更されていないＷＤＰ認識のアプリケーションで機能することを可能にすることができる。ＷＰＤにおける概念の多くは、ＭＴＰの振舞いを直接に継承し、したがって、ＷＰＤアプリケーションに利用可能な機能の多くは、ＭＴＰを接続プロトコルとして使用するデバイスから利用可能な機能と直接の相互関係を有する。
【０００６】
ＭＴＰは、ファイルシステムオブジェクト、および関連するメタデータを豊かで、役立つ仕方で表すタスクによく適していることが証明されている。しかし、ＭＰＴは多くのアプリケーションにおいて完全に満足の行くように機能するが、依然として一般的には、このプロトコルを利用するとともに、このプロトコルとの互換性を維持するさらなるフィーチャーおよび機能が望ましい。
【０００７】
この「背景技術」は、後段の「発明の概要」および詳細な説明のための簡単な文脈を導入するために与えられる。この「背景技術」は、主張される主題の範囲を特定する助けとなることも、前段で提示される欠点または問題のいずれか、またはすべてを解決する実施形態に主張される主題を限定するものと見なされることも意図していない。
【発明の概要】
【０００８】
ＭＴＰプロトコル上でホストアプリケーションまたはホストプロセスにクライアントデバイス上の自己記述型のデバイスによってホストされるサービスを公開するための構成が提供され、それによって、新たなＭＴＰコマンドを備えるＭＴＰ拡張により、デバイスによってホストされるサービスが既存のＭＴＰ実施形態に対して後方互換性および前方互換性を有することが可能になる。この拡張における新たなＭＴＰコマンドは、ＰＣ上で実行されているホストアプリケーションなどのホストアプリケーションによる、接続されたクライアントデバイスによって提供されるデバイスによってホストされるサービスの発見を可能にする。例示的な実施例において、デバイスによってホストされるサービスには、従来のＭＴＰストレージをサービスフィーチャーで補足するストレージサービス、ホストとクライアントデバイスの間のメッセージに基づく対話をサポートする機能デバイスサービス、および追加のストレージ能力または機能上の能力をもたらすのではなく、ホストに情報の豊かな、静的なデータセットを単に提示することが可能な情報サービスが含まれる。これらのデバイスによってホストされるサービスは、有利には、ホストとクライアントデバイスの間の、より豊かな通信を可能にする。スクリプト化可能な環境、または他のプログラミング環境の利用を介して、デバイス上に存在し、例えば、ウェブベースのクライアントアプリケーション、ならびに他のシンクライアントソリューションに機能を公開する任意のそのようなデバイスによってホストされるサービスを取り入れるための方法のセットが、さらに提供される。
【０００９】
この「発明の概要」は、詳細な説明において後段でさらに説明される選定された概念を、簡略化された形態で紹介するために与えられる。この「発明の概要」は、主張される主題の重要な特徴、または不可欠な特徴を特定することは意図しておらず、主張される主題の範囲を確定する助けとして使用されることも意図していない。
【図面の簡単な説明】
【００１０】
【図１】ＭＴＰを使用してホストとクライアントデバイスが通信する例示的なＭＴＰ環境を示す図である。
【図２】図１に示されるクライアントデバイスによってサポートされる例示的なサービスアーキテクチャーを示す図である。
【図３】ＭＴＰの既存の実施形態によって利用されることが可能である例示的な一般化されたオブジェクト階層を示す図である。
【図４】既存のＭＴＰストレージモデルの下におけるストレージの或る特定の実施例に関連する例示的なオブジェクト階層を示す図である。
【図５】デバイスによってホストされるサービスクエリーに関連するイニシエーターとレスポンダーの間の例示的なコマンド−応答メッセージフローを示す図である。
【図６】デバイスによってホストされるサービスの利用を介して変更された例示的な一般化されたオブジェクト階層を示す図である。
【図７】ストレージサービス、機能デバイスサービス、および情報サービスを含む例示的なデバイスによってホストされるサービスのセットを示す図である。
【図８】機能デバイスサービスに関連して実施されるオブジェクト転送を示す例示的なメッセージフローチャートである。
【図９】デバイスによってホストされるサービスを追加すること／除去することに関連するイニシエーターとレスポンダーの間の例示的なコマンド−応答メッセージフローを示す図である。
【図１０】サービスの振舞いが１つのデバイスによってホストされるサービスから別のデバイスによってホストされるサービスに継承されることが可能である例示的なモデルを示す図である。
【図１１】スクリプティング環境または他のプログラミング環境において自動化クライアントにデバイスによってホストされるサービスを公開するための例示的な構成を示す図である。
【発明を実施するための形態】
【００１１】
図面において同様の符号は、同様の要素を示す。
【００１２】
従来、ＰＣは、デバイスを、ケース内部のスロットに入り、果たすべく構築された特定の機能をもたらす固定機能のハードウェアと見なす。例えば、ビデオカードは、コンピューターメモリーの中のイメージをディスプレイデバイスに対して常に翻訳し、モデムは、別のモデムを相手に通信リンクを作成する方法を常にもたらし、あるいはハードディスクコントローラは、データが、より永久的な格納のためにコンピューターメモリーから磁気ストレージ表面に移されることを常に可能にする。一部の事例において、これらのデバイスは、コンピューターに物理的にインストールされず、つまり、コンピューターに単に接続される可能性がある。プリンタは、ビデオカードと同様に、メモリーの中のいくらかのデータを、用紙上の物理的表現に常に変換するに過ぎない。
【００１３】
この単純な「単一機能」モデルに準拠しないますます多くの新たなデバイスが、消費者によって購入されている。移動電話機、ポータブルメディアプレーヤー、パーソナルナビゲーションデバイス、パーソナル情報マネージャ、およびその他の「ポータブル」コンピューティングデバイスなどの電子機器によって代表されるこれらのデバイスは、ますます多くの機能を有して、ますます複雑になり、さらにカスタムアプリケーションの追加を介して、ますます、豊かな消費者カスタマイゼーションをサポートすることができるようになっている。しかし、今日まで、これらのデバイスのほとんどは、依然として、固定機能の仕方でＰＣと対話する。例えば、移動電話機は、３つの固定機能デバイス、すなわち、モデム、ファイル共有デバイス、およびオーディオ出力デバイスとして接続されることが可能である。このことは、多くのデスクトッププラットフォームが、同一のデバイスが複数の異なる機能を公開しているという事実を堅牢な仕方で扱わないため、しばしば、問題となる。
【００１４】
多くの点で、この振舞いは、デバイスがＰＣに接続するのに使用する技術の直接的な結果である。ほとんどのデバイスは、ＵＳＢ、Ｂｌｕｅｔｏｏｔｈ、ＩＤＥ（統合／インテリジェントドライブエレクトロニクス）、ＳＡＴＡ（Ｓｅｒｉａｌ  Ａｄｖａｎｃｅｄ  Ｔｅｃｈｎｏｌｏｇｙ  Ａｔｔａｃｈｍｅｎｔ）などのピアツーピアケーブルベースの接続モデル上、またはその他のポイントツーポイントモデル上で接続される。これらの通信リンクを介して実行されるプロトコルは、的を絞っているとともに、タスク固有であり、新たな機能の余地はほとんど有さない。新たな機能が使用可能にされる場合、その機能は、通常、豊かな、一般的な拡張性モデルではなく、機能固有の拡張性の形態でもたらされる。さらに、プロトコルまたはデバイスに、さらなる機能を追加するプロセスは、パイプの両端において新たなドライバーが書かれ、インストールされることを要求する。このことは、今や、その機能を活用するのに、所望されるすべてのホストプラットフォーム上で、デバイスのためのファームウェアだけでなく、適切なドライバーも作成しなければならないため、デバイス製造業者に負担をかける。
【００１５】
ＴＣＰ／ＩＰ（トランスポート制御プロトコル／インターネットプロトコル）ネットワーキング世界内で、接続の豊かな構造が、より豊かなデータ交換モデルの開発を可能にしてきた。（例えば、「ＳＭＴＰ」、すなわち、簡易メール転送プロトコル上で）電子メールを配信するためのプロトコル、（例えば、「ＦＴＰ」、すなわち、ファイル転送プロトコル上で）ファイルおよび（例えば、「ＨＴＴＰ」、すなわち、ハイパーテキスト転送プロトコル上で）データストリームを取り出すためのプロトコル、または（「ＬＰＲ」、すなわち、ラインプリンタリモートを使用して）ファイルを印刷するためのプロトコルを含む、ピアツーピアケーブル世界におけるプロトコルのような非常にタスク固有のプロトコルが、依然として非常によく使用されているが、これらのプロトコルは、より高位の層の「プロトコル」の振舞いによって補強されてきた。ＯＳＩ（オープンシステムズインターコネクト）モデル用語において、最上位層のスタック（すなわち、アプリケーション）においてかつて考慮されていたプロトコル自体が、さらに豊かなデータ交換のためのプレゼンテーション手段として使用されている。例えば、ＨＴＭＬ（ハイパーテキストマークアップ言語）が、どのようにＨＴＴＰの上にあるプロトコルとなっているかを考慮されたい。コアにおいて、ＨＴＭＬは、実際には、ページ上の要素のセットのレイアウトについての情報を交換するためのプロトコルである。
【００１６】
しかし、拡張およびスクリプティングモデルを介して、ＨＴＭＬ  ｏｖｅｒ  ＨＴＴＰは、完全なアプリケーションを配信する方法となっており、カスタムの振舞いおよび豊かな拡張性を完備した、新たな豊かなウェブクライアントが開発されることを可能にしている。ＨＴＴＰがどのようにアプリケーションプロトコルからプレゼンテーションプロトコルに移行したかの別の例が、ウェブサービスである。この環境において、動作のリモート実行を求める要求は、リモートホストに対するＨＴＴＰプレゼンテーション上で実行される。ウェブサービスおよびサービス指向アーキテクチャーの導入は、分散コンピューティング問題に対処が行われる仕方を劇的に変化させ、よりサービスに的を絞ったアーキテクチャーを促進してきた。実際、ウェブによってホストされるＨＴＭＬベースのクライアントアプリケーション内でウェブサービスを使用することにより、プレゼンテーション層におけるＨＴＴＰプロトコルの価値は高まるばかりである。
【００１７】
これらのソリューションの成長の鍵は、ＨＴＭＬとウェブサービスがともに、シンクライアント開発者が、これらの技術を活用して豊かな分散型ソリューションをもたらす新たな、豊かな方法を提供したという事実である。また、ウェブサービスは、サービス指向アーキテクチャーが構築され得る基礎の強力なソリューションを作成することによって、シンクライアントと同一の仕方で、より厚いクライアントにも役に立つ。最新の最も好評なウェブサイトの多くは、高度のＨＴＭＬプロトコル様のフィーチャーおよびウェブサービス様のフィーチャーを広範に利用して、ウェブサイトの機能を届ける。
【００１８】
ピアツーピアケーブル接続環境において、デバイス能力および接続されたデータ交換を同様のレベルに保つ目的で、従来、「アプリケーション」層プロトコルと考えられてきたものを、「プレゼンテーション」層プロトコルに同様に「リファクタリング」することを求める要望が、存在する。しかし、ＴＣＰ／ＩＰ世界とは異なり、同一の基礎をなすトランスポートプロトコル上ですべてが既に実行されているわけではない。
【００１９】
そのような欠点には、ＭＴＰプロトコルへの拡張が、ＭＴＰホストとＭＴＰクライアントの間で、より豊かなデータ交換を可能にするようにデバイスによってホストされるサービスが開発され、利用され得る環境を可能にする、デバイスによってホストされるサービスに関する本構成によって対処が行われる。そのようなデバイスによってホストされるサービスの能力は、これらの環境においてデバイスによってホストされるサービスが公開されるスクリプティングインターフェースを介して、ウェブ体験および他のシンクライアントソリューションにさらに拡張可能である。
【００２０】
ＭＴＰにおける「メディア」という用語は、任意のバイナリーデータを特定するのに使用され、したがって、この用語が一般に適用されるオーディオ／ビデオフォーマットに限定されないことが強調される。非オーディオ／ビデオオブジェクトのいくつかの典型的な例には、連絡先、プログラム、スケジュールされたイベント、およびテキストファイルが含まれる。メディアオブジェクトは、ＭＴＰセッションにおける転送中、原始バイナリーオブジェクトとして表されることが要求されるが、デバイス上に同一のフォーマット、または同一の構造で格納されることは要求されない。メディアオブジェクトは、コンテンツ列挙中に正確に表される限り、オンデマンドで作成されてもよい。ＭＴＰオブジェクトは、ファイルのバイナリーコンテンツだけからではなく、記述メタデータおよびリファレンスからも構成される。ＭＴＰは、ファイルのバイナリーフォーマット自体の理解を要求することなしに、プロトコルにおいて提供される機構を介してオブジェクトが認識され得るように設計される。このため、ＭＴＰにおいて、「オブジェクト」は、バイナリーファイル、そのファイルの記述メタデータ、および任意のオブジェクト内リファレンスの組合せである。
【００２１】
また、ＭＴＰによって規定されるデバイスの振舞いは、ＷＰＤを使用してＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓプラットフォーム内で表されることも理解されよう。本明細書の題材は、ＭＴＰ実施形態に関して説明されるが、類似した実施形態は、ＷＰＤの枠組み内でも存在し、したがって、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓアプリケーションは、これらの欠点に対処するのにＭＴＰに行われた拡張を活用することができる。さらに、抽象化のためのエージェントとしてのＷＰＤの性質のため、ＭＴＰプロトコル自体を使用することなしに、本明細書で説明される形態および実施形態と類似した形態および実施形態を直接に、または間接的に使用することによって、類似または同一の機能をＭＴＰに提供する、本明細書で説明される題材の代替の実施形態を構築することが可能である。
【００２２】
次に図面を参照すると、図１は、ホスト１０２とクライアントデバイス１１０がＭＴＰを使用して通信する例示的なＭＴＰ環境１００を示す。ＭＴＰは、デバイス能力、オブジェクト、およびオブジェクトプロパティを抽象化して、デバイス能力、オブジェクト、およびオブジェクトプロパティが、デバイス実施形態とは無関係にホストを相手に交換され得るようにするオブジェクトベースのプロトコルである。マイクロソフトコーポレーションは、少なくとも部分的には、メディアプレーヤーなどのユーザーのポータブルデバイスをＷｉｎｄｏｗｓベースのＰＣに接続する際にユーザーが経験する困難に応えて、ＭＴＰを開発した。ハードウェアベンダーが、第１のポータブルデバイスを導入した際、各ベンダーからのデバイスは、コンピューターと通信するために独自のプロトコルを使用した。各ベンダーが、そのベンダーのデバイスと通信するのにＷｉｎｄｏｗｓベースのＰＣ上で実行されるドライバーを供給した。ユーザーは、ユーザーのデバイスのために適切なドライバーを探し出して、インストールするまで、これらのポータブルデバイスを使用することができなかった。
【００２３】
ユーザー体験を向上させ、さらにハードウェアベンダーを、ドライバーを書く作業から解放するのに、マイクロソフトは、ＭＴＰを、ポータブルメディアプレーヤーとＷｉｎｄｏｗｓコンピューターの間の通信のための標準化されたプロトコルとして定義した。独自のドライバーの代わりに、マイクロソフトは、Ｗｉｎｄｏｗｓベースのコンピューター上で実行される汎用のＭＴＰドライバーを供給する。ＭＴＰドライバーは、すべてのＭＴＰ対応のデバイスと通信し、さらに、一般に、Ｗｉｎｄｏｗｓオペレーティングシステムの一部として提供される。ユーザーは、デバイスを単にＷｉｎｄｏｗｓコンピューターに接続して、デバイスとＰＣが、さらなるセットアップを要求することなしに通信することを可能にすることができる。
【００２４】
マイクロソフトは、ＭＴＰプロトコルを、デジタルスチルカメラのためのＰＴＰのクライアント拡張として定義した。ＰＴＰについての情報に関しては、以前はＰｈｏｔｏｇｒａｐｈｉｃ  ａｎｄ  Ｉｍａｇｉｎｇ  Ｍａｎｕｆａｃｔｕｒｅｓ  Ａｓｓｏｃｉａｔｉｏｎ（写真および映像製造業者協会）（「ＰＩＭＡ」）として知られていたＩｎｔｅｒｎａｔｉｏｎａｌ  Ｉｍａｇｉｎｇ  Ｉｎｄｕｓｔｒｙ  Ａｓｓｏｃｉａｔｉｏｎ（国際映像産業協会）（「Ｉ３Ａ」）（ｈｔｔｐ：／／ｗｗｗ．ｉ３ａ．ｏｒｇ／を参照）によってサポートされるＰＩＭＡ  １５７４０（ＰＴＰ）仕様書、「Ｐｉｃｔｕｒｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＰＴＰ）  ｆｏｒ  Ｄｉｇｉｔａｌ  Ｓｔｉｌｌ  Ｐｈｏｔｏｇｒａｐｈｙ  Ｄｅｖｉｃｅｓ（デジタルスチル写真デバイスのためのピクチャー転送プロトコル）」、バージョン１．０を参照されたい。ＭＴＰ仕様書は、例えば、ｈｔｔｐ：／／ｄｏｗｎｌｏａｄ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍにおいて入手可能である。また、ＭＴＰは、現在、ＵＳＢ  Ｉｍｐｌｅｍｅｎｔｅｒｓ  Ｆｏｒｕｍ（ＵＳＢインプリメンターズフォーラム）に提出されて、評価中であり、さらに将来、ＵＳＢ−ＩＦ  ＭＴＰ  ｖ１．０に組み込まれる可能性がある。
【００２５】
図１に示され、本明細書で説明される例示的な実施例は、Ｗｉｎｄｏｗｓオペレーティングシステム環境において実施されるが、ＭＴＰ上のデバイスによってホストされるサービスに関する本構成は、Ｗｉｎｄｏｗｓ実施形態またはＷｉｎｄｏｗｓベースのサービスに限定されないことが強調される。特定のアプリケーションの要件に応じて、他の一般的に利用されるオペレーティングシステム環境が、ＭＴＰプロトコル上でデバイスによってホストされるサービスをサポートするのに利用されてもよい。例えば、Ａｐｐｌｅ（登録商標）オペレーティングシステム、ＵＮＩＸ(登録商標)オペレーティングシステム、およびＬｉｎｕｘオペレーティングシステムのための現在のＭＴＰ実施形態が、存在する。
【００２６】
ＭＴＰ交換は、１回に２つのデバイス間でだけ行われることが可能であり、さらに各通信において、一方のデバイスは、「イニシエーター」の役割をし、他方のデバイスは、「レスポンダー」の役割をする。イニシエーターは、レスポンダーに操作を送信することによって、レスポンダーを相手にアクションを開始するデバイスである。レスポンダーは、全くアクションを直接には開始しないことが可能であり（レスポンダーが、ホストに対して保守を求める要求を「イベントとして生じて」、その結果、アクションを開始することは可能であり得るが）、さらにイニシエーターによって送信された操作に対する応答を送信するだけである、またはイベントを送信するだけであることが可能である。デバイスは、イニシエーター、レスポンダー、またはその両方の役割をすることが可能である。デバイスが、ＭＴＰセッションにおいてイニシエーターの役割をするか、レスポンダーの役割をするかをどのように最初に決定するかは、発見プロセスの一環としてトランスポート固有の仕方で定義される。
【００２７】
図１に示される例示的なＭＴＰ環境１００において、ホスト１０２が、通常、イニシエーターであり、クライアントデバイス１１０が、レスポンダーである。図１に示されるとおり、ホスト１０２は、デスクトップＰＣとして構成され、クライアントデバイス１１０は、移動電話機として構成される。しかし、ＭＴＰ上のデバイスによってホストされるサービスに関する本構成は、様々なＭＴＰ対応のデバイスのいずれにも柔軟に適用されることが可能であり、さらにいずれのデバイスも、特定の使用シナリオに応じて、イニシエーターまたはレスポンダー（またはその両方）の役割をすることができるので、これらの特定のデバイス、およびイニシエーターおよびレスポンダーとしてのデバイスの役割は、単に例示的であることが強調される。
【００２８】
そのようなＭＴＰ対応のデバイスは、他のデバイスと断続的な切断を有し、さらに別のデバイスに接続されていない間にデバイスの主要な目的を果たす、バイナリーフォーマットのメディアオブジェクトを消費する、または生成する、いくらかのストレージを有する電子デバイスとして、一般に、定義されることが可能である。ＭＴＰ対応のデバイスは、一般に、主としてメディア消費者またはメディア製作者の役割をするが、この区別は、ますます曖昧になっている。さらに、メディアオブジェクトは、一般に、ＭＴＰ環境１００において利用されるが、ＭＴＰは、最新のファイルシステムによって表されることが可能な実質的に任意のタイプのファイルの転送も可能にし、このため、このデバイスによってホストされるサービスは、メディアオブジェクトを扱うことだけに限定されない。
【００２９】
ＭＴＰ対応のデバイスのいくつかの実施例（すなわち、ＭＴＰを現在、使用している、またはＭＴＰを使用する能力を有するデバイス）には、デジタルカメラ（スチルとビデオの両方）、オーディオプレーヤーおよび／またはメディアプレーヤー、移動電話機、ＰＤＡ（パーソナルデジタルアシスタント）、ポケットＰＣ、スマートフォン、ハンドヘルドゲームプレーヤー、ＧＰＳ（グローバルポジショニングシステム）デバイスおよび他のナビゲーションデバイス、ならびにそのような機能のうちの１つまたは複数の組合せを提供するデバイスが含まれる。そのようなデバイスは、一般に、ポータブルである。ホストタイプのデバイスには、通常、例えば、デスクトップＰＣ、ラップトップＰＣおよびノートブックＰＣ、ゲームコンソール、ならびにＭＴＰ能力をサポートするように構成された他のタイプの家庭用電子デバイスが含まれる。しかし、一部のホストタイプのデバイスは、クライアントデバイスとして使用されることが可能であり、一部のクライアントタイプのデバイスは、ホストとして使用されることが可能であるので、ホストおよびデバイスの特定の役割は、必ずしも常に厳格に規定されているとは限らない。さらに、前述したとおり、クライアントまたはホストのいずれのデバイスが、イニシエーターとレスポンダーのそれぞれの役割を担うかも、変わることが可能である。
【００３０】
図１に示されるとおり、ホスト１０２とクライアントデバイス１１０は、ＭＴＰプロトコルスタックを対称的に有するように構成されて、ＭＴＰセッション上の双方向通信を可能にする。したがって、ホスト１０２は、イニシエーターＭＴＰプロトコルスタック１１６を有し、クライアントデバイスは、レスポンダーＭＴＰプロトコルスタック１２１を有する。これらのそれぞれのＭＴＰプロトコルスタックは、類似した機能をもたらすが、各スタックは、そのスタックが動作するそれぞれのデバイスの能力によって課される制約の範囲内で機能するように、通常、構成される。
【００３１】
ホスト１０２およびクライアントデバイス１１０は、例えば、ＵＳＢ（ユニバーサルシリアルバス）などのドライバー、または、例えば、デバイス間でＩＰ（インターネットプロトコル）接続またはＢｌｕｅｔｏｏｔｈ接続を実施する他のネットワークドライバーを介して実施されることが可能な、それぞれのホストハードウェアおよびクライアントハードウェアに対する基本インターフェースを提供する、それぞれの物理層１２７および１３０を有するようにさらに構成される。ＭＴＰは、トランスポートにこだわらないことが意図されており、さらに複数の基礎をなすトランスポート機構上で機能することができる。このフィーチャーは、異なるモデルにおける異なるトランスポート上で接続する際、デバイス実施形態における最適化を可能にし、あるいは同一のデバイスにおいて使用可能にされた複数のトランスポートさえ可能にする。しかし、ＭＴＰは、ＭＴＰ仕様書に従って効率的に機能するために、基礎をなすトランスポートにおいていくつかの性質を要求する。この例示的な実施例において、トランスポートは、ＵＳＢを使用して実施され、さらにホスト１０２およびクライアントデバイス１１０は、ＵＳＢケーブル１３４を使用して結合される。しかし、本構成の他の実施形態において、例えば、ＩＰ（有線または無線の）を介して、またはＢｌｕｅｔｏｏｔｈを介して接続を提供することが望ましい可能性がある。
【００３２】
前述したとおり、ＭＴＰドライバー１３８は、通常、Ｗｉｎｄｏｗｓオペレーティングシステムにおいて、さらに具体的には、ユーザーモードドライバーとして実施される。ＭＴＰドライバー１３８は、様々なホストアプリケーション１４６が、クライアントデバイス１１０上のリソースを相手にＭＴＰ通信セッションを行うことを可能にするように、Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ（「ＣＯＭ」）ベースのＷｉｎｄｏｗｓ  Ｐｏｒｔａｂｌｅ  Ｄｅｖｉｃｅ（「ＷＰＤ」）層１４０を介してインターフェースをとる。そのようなリソースには、例えば、クライアントデバイスアプリケーション１５３、ストレージ、メディアオブジェクト、およびデバイスによってホストされるサービス１５８が含まれることが可能である。ＷＰＤについてのさらなる情報は、ｈｔｔｐ：／／ｄｏｗｎｌｏａｄ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍにおいて利用可能である。
【００３３】
デバイスによってホストされるサービスは、図２に詳細に示される。この例示的な実施例において、デバイスによってホストされるサービスには、ストレージデバイス２０５、機能デバイスサービス２１３、情報サービス２１５、ホスト１０２（図１）上で動作するスクリプティング環境および他のプログラミング環境からデバイスサービスへのアクセシビリティを実施するのに利用されるスクリプト化されたデバイスサービス２１８が含まれる。これらのサービスのそれぞれが、以下に順に説明される。
【００３４】
ストレージサービス２０５に関して、ＳＣＳＩ（Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ）、ＡＴＡ（Ａｄｖａｎｃｅｄ  Ｔｅｃｈｎｏｌｏｇｙ  Ａｔｔａｃｈｍｅｎｔ）、またはＵＳＢ大容量ストレージなどの、他のファイルシステムベースのトランスポートプロトコルとは異なり、ＭＴＰは、特定のファイルシステム意味論に依存していないことに留意されたい。トランザクションは、ファイルシステムにおけるセクタ、トラック、またはファイルに対してではなく、デバイスのオブジェクトストアの中のオブジェクトに対して作用する。各オブジェクトは、データストリーム（ファイルのコンテンツ）、およびオブジェクトに関連するプロパティのセット（ファイル情報、メタデータなど）を含む。フォルダーおよび他の関連付け（メディアアルバム）を表す特殊なオブジェクトも、定義される。これらの事例のそれぞれにおいて、データストリームは、通常、空であり、プロパティだけがオブジェクトを定義する。
【００３５】
また、オブジェクトは、オブジェクトが格納された物理的メディアまたは論理的メディアを表すストレージにも関連付けられる。これらのストレージは、オブジェクトと同様に、これらのストレージが、タイプ（固定またはリムーバブル）または構造（フラットまたは階層型）などの情報を表現することを許す、関連付けられたプロパティの限られたセットを有する。さらに、ストレージは、デバイスオブジェクトにバインドされる。これらのオブジェクトは、デバイス全体を表し、デバイスの能力の全世界を記述するとともに、サポートされるコマンドの名前、製造業者、数、およびタイプ、ならびにサポートされるオブジェクトフォーマットの数およびタイプを記述する。
【００３６】
また、様々なデバイスの振舞い（例えば、カメラの現在のシャッター速度）に関してデフォルトのプロパティ値を与えるさらなるデバイスプロパティが存在することも可能である。この種のシステムに関して適切なように、すべてのＭＴＰプロパティ、ＭＴＰオブジェクト、ＭＴＰフォーマット、およびＭＴＰコマンドは、明確に定義された機構を介して拡張されることが可能である。多数のベンダーからのＭＴＰデバイスオブジェクトストアの多数の異なる実施形態が、今日、存在する。しかし、ＭＴＰは、動作中に明らかになる、いくつかの非効率を有する。
【００３７】
ＭＴＰは、オブジェクトがどこにどのように格納されるかについてこだわらないように定義されるが、一般的な使用の際、ＭＴＰは、ほとんど、１つのメディアストアから別のメディアストアにオブジェクトをレプリケートすることに限って使用されてきた。しかし、このプロセスにおけるエージェントとして、ＭＴＰは、オブジェクトが宛先デバイス上にどのように格納されるべきかを規定することに関して限られたサポートしか有さない。つまり、或る特定の文書ファイルが、デバイス上で或る特定のロケーションに格納されるべき場合、ＭＴＰを介してデバイスによって提供される、このロケーションについてのヒントは、全く存在しない。また、デバイスは、写真が、或る特定のロケーションに格納されるべきであるのに対して、音楽が別のロケーションに格納されるべきであることを指定することもできない。ＭＴＰのユーザーは、ファイルがどこにどのように編成されるかを決定するのに慣習を使用する他にない。例えば、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ  Ｍｅｄｉａ  Ｐｌａｙｅｒは、メディアコンテンツが、ＭＴＰによって公開されるストレージ上でどこに格納されるかに関して、今日、事実上の標準である階層を、メディアオブジェクトに課した。しかし、連絡先オブジェクト（すなわち、名前、アドレス、肩書き、会社、電話、電子メールアドレスなど）などの新たな形態のＭＴＰオブジェクトが使用されるようになるにつれ、これらのオブジェクトがどのように、またはどこに格納されるべきかについても、デバイスが、これらのオブジェクトがどこに格納されることを所望するかを示す仕方についても、規定する既存の事実上の標準は、全く存在しない。
【００３８】
デバイス上のオブジェクトは、通常、正規のオブジェクトと見なされるのではなく、「ファイル」と見なされる。ＭＴＰは、オブジェクトストアモデルを中心として設計されたが、ほとんどのユーザーは、それでも、ＭＴＰを、１つの場所から別の場所にファイルを移動する方法と考える。このことは、データストリームを全く有さないオブジェクトは、プロパティを基にしたオブジェクトではなく、ファイルとして扱われることを意味する。さらに、ファイルストレージの今日の主要なＭＴＰ使用モデルを所与として、ほとんどのＭＴＰ実施形態は、ファイルシステムのコンテンツを表すようにオブジェクトストアを最適化している。このことは、バイナリーデータストリームが存在しない状況を含め、オブジェクト固有の振舞いが持ち込まれる場合、問題となる。
【００３９】
ＭＴＰは、オブジェクトの格納についてであるが、ＭＴＰのオブジェクトストアが、通常、ファイルシステムの豊かなビューであるという事実は、特定のデバイス上の異なるファイルストレージボリュームに直接に関連付ける格納の概念を制限した。ＭＴＰストレージは、デバイス上の物理的ファイルストレージまたは論理的ファイルストレージに対して、通常、１：１でマップされる。このことは、ＭＴＰが、或る特定の物理的ストレージボリューム、またはそのようなボリュームの何らかの論理的パーティションではなく、ファイルシステム（例えば、データベース）の中のファイルであることが可能な「オブジェクトストア」の豊かな概念を有さないことを暗示する。
【００４０】
ストレージは、物理的メディアを表すので、ストレージは、通常、ホストユーザーインターフェースにおいて、ファイルが格納され得る様々な物理的ロケーションとして、通常、提示される。例えば、内部フラッシュストレージ上、およびリムーバブルストレージデバイス（フラッシュカードなどの）上にストレージスペース（ファイルシステム）を有するＭＴＰクライアントデバイスは、通常、ＭＴＰホストユーザー体験が、同一のデスクトップＰＣに接続されたハードドライブに関して提示される仕方と同様に、デバイス上で２つのストレージロケーション（「デバイス」および「フラッシュカード」）を示すようにさせる。クライアントデバイス実施者が、１つの特定のタイプのコンテンツを含む別の「仮想」ストレージを公開することを決定した場合、このストレージも、他の物理的ストアと一緒に標準ストレージユーザー体験の一環として現れる。このことは、ＭＴＰが、オブジェクトストアの中のオブジェクトが、ファイルシステム対応のオブジェクトであることを厳密には要求しないため、適切でない可能性がある。
【００４１】
現在のフォーマットおよび能力は、デバイスにバインドされ、それらのフォーマットおよび能力が存在するストレージにはバインドされない。ホスト実施形態は、デバイス上のすべてのストレージが、リストアップされたすべてのフォーマットをサポートすることができるものと想定する。しかし、或る特定のストレージが、１つの特定のタイプのデータのために確保される場合、ユーザーは、その特定のストレージに関して無効なタイプのデータを格納しようとする試みが行われた場合、望ましくない体験に直面する可能性がある。
【００４２】
これらの問題の多くを克服するのに、ＭＴＰは、現在、一括列挙の概念を頼りにする。基本的に、デバイスのコンテンツ全体が、パフォーマンスを大幅に犠牲にして、フォーマット別に、またはロケーション別に列挙され、さらに「より強力な」ホストが、ホスト独自の望ましい振舞い（例えば、Ｗｉｎｄｏｗｓ  Ｍｅｄｉａ  Ｐｌａｙｅｒにおけるメディアライブラリビュー）に従ってオブジェクトの豊かな集約および提示を実行する。このモデルは、デスクトップＰＣベースのホストに関してうまく行くが、利用可能なメモリーの範囲内でビューを管理するのに限られたリソースを有する、より多くの家庭用電子ホストが、出現しつつある。ＭＴＰクライアント実施者の見地から、このことは、列挙が、この場合、ファイルシステムの内容だけにもはや制限されないので、さらなる課題をもたらす。
【００４３】
連絡先オブジェクトの例を再び使用すると、現在のＭＴＰアーキテクチャーを使用してデバイス間で連絡先オブジェクトを転送しようと試みる際にもたらされる、いくつかの派生的問題が存在する。ＭＴＰは、現在、連絡先が格納されるべきデバイス上のロケーションを定義していない。１つのデバイスベンダーが、「連絡先」と呼ばれるルートから離れたフォルダーの中に連絡先を格納することを選択することが可能である一方で、別のデバイスベンダーは、デバイスのルートにある「個人情報」と呼ばれる別のフォルダー内部に「連絡先」フォルダーを格納することを選択することが可能である。両方の方法は、等しく有効であるが、そうすることが、これらのロケーションの意図される用法であることをホストアプリケーションに通知する既存の方法は、全く存在しない。例えば、Ｏｕｔｌｏｏｋが、ＭＴＰに従って第３のロケーション（ルートの下の「Ｏｕｔｌｏｏｋ」の下の「連絡先」フォルダー）に連絡先を格納することを選択することが可能である。しかし、デバイスは、この連絡先フォルダーを認識しないため、これらの連絡先を、デバイス連絡先ユーザー体験の一部として提示することができない可能性がある。
【００４４】
ＭＴＰは、現在、すべてのオブジェクトをファイルと見なす。このため、連絡先は、ファイルシステムオブジェクト、つまり、基本的に、プロパティのすべてが、オブジェクトを完全に記述するため、データストリームが空であるオブジェクトと見なされることが可能である。今日、デバイス製造業者によってなされる想定は、オブジェクトがファイルを表すため、通常、空のファイルが作成されることをもたらす。したがって、ユーザーは、これらのファイルを見ると、これらのファイルに対して必然的に何もすることができず、これらのファイルがそもそも、なぜ出現するのかを問う可能性が高い。
【００４５】
ＭＴＰは、現在、すべてのストレージが物理的であるものと想定する。このため、例えば、連絡先が、フォルダーの中のファイルとしてではなく、連絡先データベースの中に格納されるものと想定されたい。連絡先データベースが、ファイルストアの中の連絡先としてではなく、そのストアの中のアイテムとして表される場合、データベースは、標準のＭＴＰ列挙モデルを介して、或る特定のストレージデバイス上の単一のファイルシステムオブジェクトとして列挙される。連絡先を実際に公開するのに、ＭＴＰクライアント実施形態は、連絡先ファイルの特殊ケース処理を必要とし、連絡先ファイルを、個々の連絡先を発見するようにさらに列挙されることが可能な「仮想」フォルダーとして扱う。
【００４６】
ＭＴＰホスト実施形態は、通常、すべての利用可能なストレージを、デバイス上の異なる物理的ストレージとして扱う。例えば、連絡先を「仮想」フォルダーとして扱うのではなく、連絡先が格納される別個のストレージを作成するように選択するＭＴＰクライアントデバイス実施者を考慮されたい。このことは、この別個のストレージを、デバイス上の新たな物理的ストレージとして公開するという残念な結果を有する。このことは、連絡先に関して許容できる可能性があるが、新たなストアが、同じ仕方で公開されるにつれ（カレンダー、メール、資格証明書、クレジットカード／ウォレットなど）、このことは、特定のオブジェクトがどこに格納されている可能性があるかと比べて、ファイルがどこに格納されている可能性があるかをユーザーが見分けることを、より困難にする。
【００４７】
ＭＴＰオブジェクトフォーマットは、デバイスにバインドされる。連絡先データベースを別個のＭＴＰストレージとして公開する例示的な実施例を続けると、クライアント実施者およびホスト実施者は、デバイスが、デバイス上の異なるストレージの中で異なるタイプのフォーマットをサポートするという事実に対処しなければならない。このことは、ユーザーが、どのようなタイプのデータが各ストレージ上に格納され得るかを知らなければならないだけでなく、データが属するとユーザーが考える場所にデータを置こうと試みて、結局、そのようなロケーションがサポートされていないと告げられることになる残念な体験を有する可能性があるため、デバイスに対するユーザーの体験をさらにこじらせる可能性がある
ＭＴＰは、一括列挙に依拠して、これらの問題の多くを回避する。通常、ＭＴＰクライアントデバイスが、通常、メディアストアである、１つのタイプのオブジェクトストアだけしか表さない今日の世界において、このことは、ユーザーからデバイスの物理的実施形態を隠すことの妥当なソリューションである。しかし、連絡先データストアが追加された場合、ホスト実施形態とクライアントデバイス実施形態に関する列挙の複雑さは、増加する。ホスト上で、メディアエントリーとは別に連絡先エントリーを収集し、管理するために、さらなるコードおよびメモリーが、ほとんどの設定において追加されなければならない。このことは、ホストが、それほど強力でない家庭用電子デバイス上で実行される場合、妥当でない可能性がある。クライアントデバイス側で、列挙は、複数のソースからの異なるタイプのデータが、列挙要求を満たすのに一緒に結び付けられなければならないという事実によって、今度は、複雑にされる。
【００４８】
以上の非効率に鑑みて、ファイルにバインドされていないデータ型を扱う際のＭＴＰの有効性を広げるのに、前述したとおり、ストレージサービス２０５を含む、「デバイスによってホストされるサービス」と呼ばれる新たな列挙モデルが、提供される。このモデルは、前述した制限の多くを修正する一方で、同時に、今日、存在するＭＴＰにおける他の拡張性の課題に対処する。
【００４９】
図３は、ＭＴＰの既存の実施形態によって利用されることが可能である例示的な一般化されたオブジェクト階層３００を示す。符号３１０および３２０によってそれぞれ示される、クライアントデバイスおよびストレージという、オブジェクト階層の上位２つのレベルは、階層３００における、より深い層と比べて、より厳格に定義される。標準のＭＴＰ列挙はまず、ＭＴＰコマンド、ＧｅｔＤｅｖｉｃｅＩｎｆｏを使用して、デバイスを識別して、デバイスについての情報を抽出し、さらにコマンド、ＧｅｔＳｔｏｒａｇｅＩＤおよびＧｅｔＳｔｏｒａｇｅＩｎｆｏを使用して、接続されたストレージを識別して、このストレージについての情報を抽出する。この時点を過ぎると、列挙は、特定のタイプのファイルを探し出す（例えば、拡張子によって検索する）ため、階層を表現するため（例えば、ディレクトリを見つける）、およびそれぞれについての情報を獲得する（例えば、ファイルを開く、またはファイルシステムカタログ情報を取得する）ために標準のＷｉｎｄｏｗｓ  Ｗｉｎ３２ファイルシステムＡＰＩと同様に動作する、任意の数の一括操作によって行われる。
【００５０】
図４は、既存のＭＴＰストレージモデルの下でストレージの或る特定の実施例に関連する例示的なオブジェクト階層４００を示す。この実施例では、「ストア０」と名付けられたストレージ４１１が、クライアントデバイス４２２上で音楽フォルダー４１３およびテキストフォルダー４１５を公開する。音楽フォルダー４１１は、それぞれのアーティスト、「アーティスト１」および「アーティスト２」に関する２つのアーティストフォルダー４３０および４３５を含む。アーティストフォルダー４３０は、示されるとおり、複数の曲４３８１、２．．．Ｎを含む。
【００５１】
図３および図４に示され、さらに付随する本文において説明される既存のＭＴＰストレージモデルと比べて、本デバイスによってホストされるサービスモデルにおいては、クライアントデバイスが列挙される仕方が変更され、その一方で、それでも、現在のＭＴＰ実施形態に対する後方互換性が保たれている。この変更は、デバイスによってホストされるサービスを介して公開されるレスポンダー上のいくつかのタイプのコンテンツをイニシエーターが見つけて、これらのコンテンツにアクセスすることを可能にするように構成された新たな操作を含むＭＴＰ拡張の作成を介して、実施される。ＭＴＰは、現在、フォーマット別の列挙をサポートするが、これらの新たなコマンドは、特定のコンテンツタイプに限って扱うアプリケーションに関して、より大きい柔軟性を可能にする。これらの新たなＭＴＰコマンドが、以下に表１に示される。
【００５２】
【表１】
2010541043.tif 000003
【００５３】
ＧｅｔＳｅｒｖｉｃｅＩＤｓコマンドは、ＭＴＰ拡張における別の新たなコマンド、ＧｅｔＳｅｒｖｉｃｅＩｎｆｏに関連して使用されることが可能なサービス識別子のアレイ（すなわち、リスト）を戻すように動作する。ＧｅｔＳｅｒｖｉｃｅＩｎｆｏコマンドは、ＳｅｒｖｉｃｅＩＤをパラメータとしてとり、ＳｅｒｖｉｃｅＩＤパラメータによって識別される特定のデバイスによってホストされるサービスに関する、「ＳｅｒｖｉｃｅＩｎｆｏ」と名付けられた静的サービス定義データセットを戻すように動作する。
【００５４】
ＳｅｒｖｉｃｅＩｎｆｏデータセットは、一般に、デバイスによってホストされるサービスのコアプロパティおよび対話要素を定義するように構成される。データセットは、例えば、機能およびフィーチャーの所望されるセットを実施するのに要求される移動電話機製造業者などのメディアデバイスクライアントベンダーによって定義されることが可能である。ＳｅｒｖｉｃｅＩｎｆｏデータセットは、デバイスによってホストされるサービスを機能オブジェクトとして公開するのにさらに利用される。この例示的な実施例において、機能オブジェクトは、ＭＴＰドライバー１３８（図１）と通信するのにインプロセスＣＯＭサーバーを使用して実施されるオブジェクトベースのＷＰＤインフラストラクチャにおいて使用される。したがって、ＭＴＰドライバー１３８が、ＳｅｒｖｉｃｅＩｎｆｏデータセットを読み取って、対応するＷＰＤ機能オブジェクトを作成する。ＳｅｒｖｉｃｅＩｎｆｏデータセットは、以下に表２−１〜表２−３に示される。
【００５５】
【表２−１】
2010541043.tif 000004
【００５６】
【表２−２】
2010541043.tif 000005
【００５７】
【表２−３】
2010541043.tif 000006
【００５８】
ＳｅｒｖｉｃｅＩｎｆｏデータセットは、図示されるとおり、いくつかのエントリーを含むように構成される一方で、列挙の目的に重要なエントリーは、ＭＴＰ  ＳｔｏｒａｇｅＩＤを含むことである。ＳｔｏｒａｇｅＩＤは、物理的ストレージを必ずしも表す必要はない、所与のサービスに関するコンテンツを保持するストレージを識別する。ＳｔｏｒａｇｅＩＤは、存在する場合、例えば、既存のＧｅｔＳｔｏｒａｇｅＩｎｆｏ  ＭＴＰコマンドを介するレガシー列挙を使用して取り出されたＳｔｏｒａｇｅＩＤを受け付ける任意の操作において使用されることが可能である。従来のストレージ実施形態と同様に、デバイス上で型、ＳｅｒｖｉｃｅＧＵＩＤ（ここで、「ＧＵＩＤ」は、Ｇｌｏｂａｌｌｙ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｉｅｒの頭字語である）の或る特定のサービスの複数のインスタンスを同時に有することが可能である。例えば、デバイスメモリーの中、ならびにＳＩＭ（加入者ＩＤモジュール）カード上に連絡先を格納することができる移動電話機上の連絡先サービス実施形態を考慮されたい。これらのストレージロケーションのそれぞれは、ＳＩＭカードが、例えば、各エントリーに関する名前および電話番号に制限されて、異なる能力を有するように構成され、さらにそれぞれが、サービスインフラストラクチャを使用して適切にモデル化される。これらのサービスが互いに区別されることを可能にするのに、各サービスに、永続的一意識別子（「ＰＵＩＤ」）を介して、異なるコンピューター可読グローバル一意識別子が割り当てられる。このＳｅｒｖｉｃｅＰＵＩＤが、次に、ホスト１０２に対してデバイス１１０の複数の接続を介してサービスの特定のインスタンスを表すのに使用されることが可能である。
【００５９】
本デバイスによってホストされるサービスにおいて利用される他のデータセットには、サービスプロパティおよびサービス能力が含まれる。「ＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙＬｉｓｔ」と名付けられたサービスプロパティデータセットは、デバイスによってホストされるサービスのプロパティを設定する変更可能な機構を提供し、さらに現在のＭＴＰプロトコルにおける既存のＯｂｊｅｃｔＰｒｏｐＬｉｓｔデータセットと同様である。ＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙＬｉｓｔデータセットは、以下に表３に示される。
【００６０】
【表３】
2010541043.tif 000007
【００６１】
ＧｅｔＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙＬｉｓｔコマンドは、ＳｅｒｖｉｃｅＩＤをパラメータとしてとり、ＳｅｒｖｉｃｅＩＤパラメータによって識別される特定のデバイスによってホストされるサービスに関するＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙＬｉｓｔデータセットを戻す。また、オプションのＳｅｒｖｉｃｅＰｒｏｐＣｏｄｅパラメータが使用されることも可能である。使用される場合、クライアントデバイス１１０（図１）は、指定された単一のプロパティ値だけを有するＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙＬｉｓｔデータセットを戻す。オプションのパラメータが使用されない場合、クライアントデバイス１１０は、ＳｅｒｖｉｃｅＩＤパラメータによって指定されたデバイスによってホストされるサービスに関するすべてのＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙ値を戻す。ＧｅｔＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙＬｉｓｔコマンドは、現在のＭＴＰプロトコルにおけるＧｅｔＯｂｊｅｃｔＰｒｏｐＬｉｓｔコマンドと同様の仕方で動作する。同様に、ＳｅｔＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙＬｉｓｔコマンドは、ＳｅｔＯｂｊｅｃｔＰｒｏｐＬｉｓｔと同様の仕方でデバイスにサービスプロパティ情報を送信するのに使用される。
【００６２】
「ＳｅｒｖｉｃｅＣａｐａｂｉｌｉｔｙＬｉｓｔ」と名付けられたサービス能力データセットは、所与のオブジェクトに関するサポートを制約するのに使用されることが可能なプロパティのセットを含む。例には、ＭＰ３ファイル（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅｓ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ、「ＭＰＥＧ」、Ａｕｄｉｏ  Ｌａｙｅｒ−３）においてサポートされるビットレート、または連絡先に関する読み取り／書き込み能力を制限することが含まれる。能力は、通常、デバイスによってホストされるサービスごとに定義され、さらにデバイス全体にわたる能力（既存のＭＴＰ  ＤｅｖｉｃｅＩｎｆｏデータセットにおいて定義される能力などの）には、サービス固有の能力が優先されることが可能である。ＳｅｒｖｉｃｅＣａｐａｂｉｌｉｔｙＬｉｓｔデータセットが、以下に表４に示される。
【００６３】
【表４】
2010541043.tif 000008
【００６４】
ＧｅｔＳｅｒｖｉｃｅＣａｐａｂｉｌｉｔｉｅｓコマンドは、パラメータとしてＳｅｒｖｉｃｅＩＤをとって、ＳｅｒｖｉｃｅＩＤパラメータによって識別される特定のデバイスによってホストされるサービスに関するＳｅｒｖｉｃｅＣａｐａｂｉｌｉｔｙＬｉｓｔデータセットを戻す。また、オプションのＦｏｒｍａｔＣｏｄｅパラメータが、使用されることも可能である。使用される場合、クライアントデバイス１１０は、そのデバイスによってホストされるサービスに関する指定されたフォーマットに関する能力だけを戻す。このオプションのパラメータが使用されない場合、クライアントデバイスは、サポートされるすべてのフォーマットに関するデバイスによってホストされるサービス固有の能力を戻す。
【００６５】
デバイスサービスに追加されるさらなるフィーチャーは、サービス固有のイベントを定義する能力である。他のサービス要素と同様に、これらのイベントは、名前およびグローバル一意ＩＤ（「ＧＵＩＤ」）によって識別される。現在、ＭＴＰイベントは、３つの３２ビット値を戻すように定義されている。同様に、サービスイベントは、この同一の構造を使用し、さらにサービスが、各イベントに関して戻される３つの３２ビット値がどのように解釈されるべきかを定義することを可能にする。
【００６６】
図５は、デバイスによってホストされるサービスクエリーに関連するイニシエーター５０２（例えば、図１におけるホスト１０２）とレスポンダー５１０（例えば、クライアントデバイス１１０）の間の例示的なコマンド−応答メッセージフロー５００を示す。メッセージフロー５００は、イニシエーター５０２によって実行される表１におけるＭＴＰコマンド、およびレスポンダー５１０からの応答の使用を示す。図示されるとおり、コマンド−応答メッセージ交換５２０は、ＧｅｔＳｅｒｖｉｃｅＩＤコマンドと、サービス識別子のリストを含む応答とを含む。メッセージ交換５２６は、ＧｅｔＳｅｒｖｉｃｅＩｎｆｏコマンドと、応答としてのＳｅｒｖｉｃｅＩｎｆｏデータセットとを含む。メッセージ交換５３０は、ＧｅｔＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙコマンドと、応答としてのＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙＬｉｓｔデータセットとを含む。メッセージ交換５３５は、ＧｅｔＳｅｒｖｉｃｅＣａｐａｂｉｌｉｔｉｅｓコマンドと、応答としてのＳｅｒｖｉｃｅＣａｐａｂｉｌｉｔｉｅｓＬｉｓｔデータセットとを含む。メッセージ交換５４２は、ＳｅｔＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙＬｉｓｔコマンドと、関連するデータ、すなわち、ＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙ値もしくはＳｅｒｖｉｃｅＰｒｏｐｅｒｔｙデータセットとを含む。レスポンダー５１０からの応答は、現在のＭＴＰ  ＳｅｔＯｂｊｅｃｔＰｒｏｐＬｉｓｔコマンド／応答と同一の仕方で、肯定応答（例えば、図示される「ＯＫ」）、または適切なステータスメッセージもしくはエラーメッセージを示す。
【００６７】
図６は、本デバイスによってホストされるサービス列挙によって提供される変更に鑑みて、例示的な一般化されたオブジェクト階層６００を、ＭＴＰの見地から示す。図示される実施例において、２つのデバイスによってホストされるサービス、すなわち、サービスＩ（符号６１０によって識別される）およびサービスＩＩ（符号６１６によって識別される）が列挙される。図示されるとおり、サービスＩ  ６１０は、ストレージに関連付けられていない一方で、サービスＩＩ  ６１６は、符号６２６および６２９によってそれぞれ示されるメディアオブジェクト６および７を保持するストレージＣ  ６２０に関連付けられている。
【００６８】
デバイスによってホストされるサービスの導入は、デバイス上に格納されたオブジェクトを列挙するために現在のＭＴＰ実施形態によって提供されるレガシーアクセスモデルにいくつかの含意をもたらす。サービスに接続されたストレージが、サービスモデルを認識していないレガシーホストによって見られないことを確実にするのに、サービスに関連付けられたストレージは、ＧｅｔＳｔｏｒａｇｅＩＤへの応答として全く戻されないものとされる。サービスベースの列挙の見地から、レガシーストレージは、デフォルトの「レガシーサービス」の一部であるものと想定され、レガシーＧｅｔＳｔｏｒａｇｅＩＤ操作を介して、引き続き列挙されなければならない。このようにして、より古いクライアントデバイスは、デバイスによってホストされるサービスのモデルを使用するホストデバイスに依然として接続することができ、そのようなデバイスと協働することができる。
【００６９】
後方互換性を維持するのに、サービス作成者は、既存のＭＴＰ一括操作コマンドのサポートが、サービスデータオブジェクトに関して指定されたＭＴＰフォーマットコードを要求することを認識していなければならず、さらにメソッドオブジェクトは、デバイスのドメイン内で一意でなければならない。しかし、異なる２つのデバイス上の同一のオブジェクトに関して同一のフォーマットコードが使用されなければならないという制約は、全く課されていない。例えば、ＭＴＰフォーマットコード０ｘ３００９が、フォーマットＡのオブジェクトのストレージを暗示するように或る特定のデバイス上の１つのサービスによって使用されるとした場合、このコードは、フォーマットＢのオブジェクトのストレージを暗示するように同一のデバイス上の第２のサービスによって使用され得ない。しかし、同一の製造業者または異なる製造業者からの別のデバイス上で、サービス作成者は、任意のサービス上のフォーマットＢのオブジェクトのストレージを表すのに、設計上の選択の問題として、ＭＴＰフォーマットコード０ｘ３００９を使用することを選択することができる。
【００７０】
サービスは、レガシーＭＴＰの振舞いに加えられたものであるので、サービス内で定義されるフォーマットが、標準のＭＴＰ「ＤｅｖｉｃｅＩｎｆｏ」データセットの一部としてリストアップされてはならないことも重要である。サービスを認識するホスト１０２だけが、ＧｅｔＳｅｒｖｉｃｅＩＤｓ／ＧｅｔＳｅｒｖｉｃｅＩｎｆｏモデルを介してサービスフォーマットを発見することを可能にされなければならない。また、このことは、サービスを認識する実施形態上でデバイスレベルにおいて行われる一括列挙要求が、サービスを認識しない実施形態との互換性を維持するようにデバイスレベルにおいて引き続き機能しなければならないことも暗示する。
【００７１】
図７は、デバイスによってホストされるサービスのいくつかの特定の例示的な実施例に関するＭＴＰオブジェクト階層７００を示す。これらのサービスには、クライアントデバイス１１０上で提供されるストレージサービス２０５、機能サービス２１３、および情報サービス２１５が含まれる。ストレージサービス２０５は、連絡先サービス７１０１、カレンダーサービス７１０２、および着信音サービス７１０３を含む。機能サービス２１３は、電話サービス７１０４、ステータスサービス７１０５、および設定サービス７１０Ｎ−１を含む。ヒントサービス７１０Ｎが、情報サービス２１５の例である。これらのサービス７１０（ストレージ、機能、および情報）は、単に例示的であり、さらに或る特定のメディアデバイスクライアント上で提供されるサービスの特定の数、種類、および配合は、一般に、応用先の要件に依存し、さらに図７に示されるものとは異なることが可能であることが強調される。例えば、図示されていないものの、ＳＭＳ（ショートメッセージシステム）データおよび／または壁紙が、本デバイスによってホストされるサービス構成を介して公開されることも可能である。図示されるとおり、ストレージ７２０１，２，．．．Ｎ−１が、それぞれのデバイスによってホストされるサービス７１０１，２，．．．Ｎ−１に接続される。
【００７２】
連絡先サービス７１０１、カレンダーサービス７１０２、および着信音サービス７１０３は、それぞれ、クライアントデバイス１１０におけるそれぞれの接続されたストレージ７２０から連絡先、カレンダーデータ、および着信音を公開する。ストレージサービス２０５は、既存のＭＴＰストレージと同様の振舞いをする。しかし、本デバイスによってホストされるサービス機構は、どのようなタイプのデータがストレージの中に格納されるか、およびそのデータがどのように使用されるかに関する強化されたレベルの記述を提供する。さらに、すべてのストレージサービスは、クライアントデバイス上のいくらかのストレージロケーションによって裏打ちされる（さらに、このため、この例示的な実施例において従来のＭＴＰストレージと均等であると考えられることが可能である）が、このストレージが、物理的ストレージデバイスで、１：１で表されなければならないという要件は、存在しない。このストレージは、ファイルシステム、データベース、またはデータの任意のコレクションであってもよい。
【００７３】
有利には、デバイスによってホストされるサービスの重要な特徴は、デバイスによってホストされるサービスが、ＭＴＰ内の既存の拡張性モデルに限定されないように、自己記述型であるように構成されるということである。この特徴は、デバイスによってホストされるサービスのコンシューマーが、単に、サービスを発見して、サービス記述を読み取るだけで、サービスを適切に利用することを可能にする。これと比べて、既存のＭＴＰの振舞い、フォーマット、およびオブジェクトはすべて、標準化機構または拡張作成者によって保持される原本の仕様書において説明される。そのような仕様は、ＭＴＰにおける「知られている」フォーマットおよびプロパティの全部のリストを含む。そのようなフォーマットおよびプロパティは、１６ビット値であり、制約されたビットパターンがタイプを識別する。この構成のため、ＭＴＰは、新たな振舞い、フォーマット、およびオブジェクトが使用されることを可能にする、ホストＭＴＰスタックへの変更を要求する傾向にある。ほとんどのＭＴＰホスト実施形態は、ＭＴＰフォーマット世界もしくはＭＴＰ機能世界と、何らかのネイティブの、プラットフォーム固有のモデルとの間でデバイスファームウェアにおいて確立されるマッピングを実行する。このため、これらのマッピングテーブルまたは機能スタブは、定義された新たなフォーマット、プロパティ、または機能に対処するように更新されなければならない。したがって、ＳｅｒｖｉｃｅＩｎｆｏデータセットの目標の１つは、ホストＭＴＰプロトコルスタック（例えば、図１におけるイニシエーターＭＴＰプロトコルスタック１１６）が、変更される必要なしに、ホスト上で実行される未知のソフトウェアと、クライアントデバイスとの間の対話をプロキシ化することができるだけ十分な情報を担持することである。
【００７４】
さらに、ＭＴＰは、現在、新たなフォーマット、プロパティ、および機能が定義されることを許す拡張機構をサポートするものの、前述したとおり、一意性および互換性を保証するような仕方ではサポートしない。このモデルが、ほとんどの実際的な使用をサポートするのに数学的に十分であると論じる向きもある可能性があるが、このモデルは、２つのベンダーが、非常に異なる２つのことを意味するように同一の値を容易に、合法的に使用する可能性があるため、互換性を保証しない。競合解決のための現在のモデルは、いずれの１つのデバイスも、競合する拡張の両方を使用する可能性がないよう、これらの拡張が互いに排他的であることを要求する。したがって、これらのアイテムを一意であると考えることは困難である。デバイスによってホストされるサービスの自己記述の性質は、フォーマット、プロパティ、および機能を、ＧＵＩＤに関して表される、より広い名前空間に高めることによって、この問題を解決するように働く。このことは、デバイス製造業者が、製造業者のデバイス上で任意の適切なＭＴＰ値を指定することを、製造業者にかかわらず、同一のサービスのすべての実施形態との互換性を依然として保ちながら、可能にする。
【００７５】
自己記述型であることにより、デバイスによってホストされるサービスは、サービスが公開するオブジェクトの型に対する制限を記述する能力を指定する能力を有する。このことは、或る特定のサービスが、オブジェクトのサポートを或る特定のフォーマット、またはそのフォーマットの或る特定のサブセットに制限する必要がある場合、貴重である。着信音サービス７１０３の例を使用すると、サービスは、サービス上のすべてのファイルをＭＰ３フォーマット、１２８ｋｂｐｓビットレート以下、および持続時間３０秒未満に制限するデバイス上で利用可能であり得る。この例示的な実施例において、そのような制限は、ＳｅｒｖｉｃｅＣａｐａｂｉｌｉｔｙＬｉｓｔデータセットによって与えられる。現在のＭＴＰプロトコルの下における既存の方法は、このことをデバイスレベルで扱うことができるが、これらの制限をストレージレベルで表現する方法は、存在せず、したがって、デバイスは、ファイルが着信音ロケーションにコピーされた場合、それらの要件を満たすようにホストコンピューターにそのコンテンツをトランスコードさせるのではなく、それらのファイルを「無効」として拒否しなければならない（ユーザーが、「サポートされていません」エラーのようなものを受け取って）。
【００７６】
さらに、デバイスによってホストされるサービスが、ＳｅｒｖｉｃｅＩｎｆｏデータセットの中で利用可能な情報だけに制限されなければならないという要件は、存在しない。サービスをオブジェクトそのものと考え、必要に応じて、プロパティをサービスから外すことを要求することができることが妥当である。
【００７７】
次に、機能デバイスサービス２１３を参照すると、機能サービスに関する一般的なモデルは、機能要求を、既存のＭＴＰプロトコルの範囲内のオブジェクト転送として扱うことである。単純化された扱いが、図８に示される例示的な流れ図８００に示される。イニシエーター８０２（例えば、図１のホスト１０２）およびレスポンダー８１０（例えば、図１のクライアントデバイス１１０）が、機能サービスを実施する「メソッド」を利用する。この場合のメソッドは、従来のウェブサービスにおける呼び出しと同様であり、つまり、メソッドは、実行可能なコマンドと関係する情報を送るのにイニシエーター８０２とレスポンダー８１０の間で交換されるオブジェクトである。
【００７８】
イニシエーター８０２が、メソッドオブジェクトプロパティ８１６をレスポンダー８１０に送り、レスポンダー８１０は、イニシエーター８０２に応答８２０を送り返す。次に、イニシエーター８０２は、符号８２５によって示されるとおり、完了イベントがレスポンダー８１０から戻されるのを待つ。本デバイスによってホストされるサービスの多くの応用例において、メソッドオブジェクトは、バイナリーペイロードを有さない。代わりに、メソッドオブジェクトは、プロパティのリストを有する０バイトのオブジェクトである。しかし、代替の応用例において、メソッドオブジェクトは、符号８２２によって示されるとおり、オプションとして、バイナリーで実施されてもよい。
【００７９】
レスポンダー８１０は、符号８３２によって示されるとおり、メソッドオブジェクトプロパティ８１６を処理して、その結果、機能サービス２１３によってもたらされる機能を実行する。符号８３５によって示される処理の完了後、メソッド完了イベント８４０が、レスポンダー８１０からイニシエーター８０２に送られる。メソッド完了イベント８４０を受信すると、イニシエーター８０２は、メソッドオブジェクトプロパティ要求８４２を使用して、レスポンダー８１０からプロパティまたは情報を取り出すことができる。この場合も、本デバイスによってホストされるサービスの多くの応用例は、プロパティの取り出しだけしか要求しないが、代替の応用例は、メソッドオブジェクトから結果８４６を取り出すことになることが可能である。もたらされた情報が取り出されると、イニシエーター８０２は、符号８４３によって示されるとおり、メソッドオブジェクトを削除して、次のメソッドオブジェクトのために道を開く。イニシエーター８０２は、削除メソッドオブジェクト８５０をレスポンダー８１０に送信する。符号８５４によって示されるとおり、メソッドオブジェクトは、レスポンダー８１０において削除され、後に取り出すためにレスポンダー８１０によって格納されることはない。説明の簡明のため、単一の代表的な呼び出しシーケンスが、図８に示されることが理解されよう。レスポンダー８１０は、一度に複数のメソッド呼び出し、つまり、同一のメソッドの呼び出し、または同一のデバイスサービス上、または別のサービス上の異なるメソッドの呼び出しをサポートすることができる。
【００８０】
図７を再び参照すると、機能サービス２１３の例が、電話サービス７１０４である。この実施例において、或る電話番号をダイヤルし、着信オーディオストリームおよび送信オーディオストリームをホスト１０２にリモートするようにというクライアントデバイス１１０への図１のホスト１０２による機能要求を考慮されたい。電話機の振舞いを表す機能電話サービス７１０４が、電話番号というパラメータをとり、結果を戻す「ダイヤルする」という動詞を有するサービスとして定義される。ダイヤル動作を開始するのに、ホスト１０２は、既存のＭＴＰコマンド、ＳｅｎｄＯｂｊｅｃｔＰｒｏｐＬｉｓｔを使用して、図８に付随する本文において前述したとおり、電話サービスにメソッドオブジェクトを送信し、フォーマットは、ダイヤルする動詞、および電話番号の関連するプロパティとして指定される。
【００８１】
クライアントデバイス１１０は、電話をダイヤルするのに要求される作業を実行し、さらに、接続またはエラー条件が生じると、動詞オブジェクトが変化したことをホストに通知する。次に、クライアントデバイス１１０は、既存のＭＴＰコマンド、ＧｅｔＯｂｊｅｃｔＰｒｏｐＬｉｓｔを介して、動作の結果を要求する。動作の結果は、動詞オブジェクト上のプロパティとして現れる。結果が成功であった場合、これらのプロパティは、要求されるコールを表すコールオブジェクトのオブジェクトＩＤ、およびコールの符号化されたオーディオを送信／受信するのに使用されるべきストリームのＩＤを含むことが可能である。
【００８２】
「ＳｅｒｖｉｃｅＩｎｆｏ」データセットは、特定のメソッドオブジェクトのフォーマットおよび名前についての情報を含む一方で、サービスメソッド動作のプロパティ（またはメソッド用語で引数）についての詳細は含まない。メソッドオブジェクトは、ＭＴＰ内の標準のデータオブジェクトのように現れるので、既存の操作、すなわち、ＧｅｔＯｂｊｅｃｔＳｕｐｐｏｒｔｅｄおよびＧｅｔＯｂｊｅｃｔＰｒｏｐＤｅｓｃが、この情報を発見するように再使用されることが可能である。サービスの振舞いおよび名付け規則を円滑にするため、名前、グローバル一意識別子（すなわち、ＧＵＩＤ）、パラメータ順序、および引数用法（イン、アウト、イン／アウト）を含む詳細な引数情報が供給されることを可能にする追加が、ＧｅｔＯｂｊｅｃｔＰｒｏｐＤｅｓｃプロパティ形態に加えられた。さらに、或る特定のフォーマットのオブジェクトを表すオブジェクトＩＤとして引数を定義する能力を含む、より豊かなオブジェクト指向の振舞いをサポートする新たな形態が、導入される。
【００８３】
ストレージと同様に、サービスも動的であり、つまり、サービスは、図９の例示的なメッセージフロー９００において示されるとおり、クライアントデバイス１１０によって、必要に応じて追加される、または取り除かれることが可能である。サービス追加イベント９２０が、レスポンダー９１０上で新たなサービスが利用可能であることを示すのに、イニシエーター９０２（例えば、図１のホスト１０２）とレスポンダー９１０（例えば、クライアントデバイス１１０）の間で交換される。図９におけるその他のメッセージ（符号９２６、９３０、および９３５によってそれぞれ示される）は、図５に示されるパターンと同様のパターンに従う。従来のストレージ世界において、そのような動的な振舞いは、デバイスに対して物理的メディアが追加される、または取り外される際に意味をなす。サービス世界において、このことは、サービスが、クライアントデバイス１１０にインストールされた新たなプログラムによって追加されることが可能であることを暗示する。例えば、サードパーティが、カレンダーアプリケーションを書いた場合、このアプリケーションが、既に公開されている可能性がある連絡先サービス７１０１に加えて実行された際、カレンダーサービス７１０２（図７）が、公開されることが可能である。
【００８４】
図７を再び参照すると、ステータスサービス７１０５が、クライアントデバイス１１０（すなわち、レスポンダー）についての様々なステータスプロパティをホスト１０２（すなわち、イニシエーター）に公開する。そのようなプロパティの値は、この例示的な実施例において、オンライン／オフライン、バッテリー寿命、信号強度、ネットワーク名、およびＢｌｕｅｔｏｏｔｈ対応を含むことが可能である。ステータスプロパティの更新の頻度は、通常、利用されている特定のクライアントデバイスによって選択され、さらにデバイスプロパティが更新された際に、ＳｅｒｖｉｃｅＰｒｏｐＣｈａｎｇｅｄイベントが、イニシエーターに送信されなければならない。本デバイスによってホストされるサービスのほとんどの応用例において、更新頻度は、相対的なクライアントおよびホストＰＣのパフォーマンス能力を考慮に入れ、さらに、例えば、ポータブルデバイスバッテリー寿命を考慮して設計される。
【００８５】
設定サービス７１０Ｎ−１は、ホスト１０２（すなわち、イニシエーター）によってリモートで操作されるべきクライアントデバイス１１０（すなわち、レスポンダー）に関する様々な設定を公開する。そのような設定は、通常、クライアントデバイス固有であり、したがって、設定サービス７１０Ｎ−１によって公開される特定の設定フィーチャーおよび設定機能は、デバイスによって異なり、サービス開発者（例えば、デバイス製造業者）には設計上の選択の問題である。
【００８６】
ヒントサービス７１０Ｎは、レガシーストレージサービス内、または特定のサービス内で特定のオブジェクト型を格納すべきデバイスロケーションを識別することに関する、既存のＭＴＰ実施形態の限界を克服する情報をホスト１０２に提供する。図示されるとおり、ＳｅｒｖｉｃｅＩｎｆｏ７２０Ｎが、サービスの適切な動作のために必要である可能性があるサービス固有のデータを搬送することが可能にされる。ヒントサービス７１０Ｎなどの一部のサービスは、さらなるストレージ能力もしくは機能上の能力を提供するのではなく、単に、情報の豊かな、静的データセットをホスト１０２に提示するだけでよい可能性がある。情報サービス２１５と呼ばれる、そのようなサービスは、さもなければ提供されることが可能でない、或る特定のデバイスについてのさらなる情報を提供する。ヒントサービス７１０Ｎの場合、例示的なデータセットは、通常、ＭＴＰフォーマットコード、ストレージＩＤ，および親オブジェクトＩＤを含み、指定されたフォーマットのオブジェクトを格納すべき好ましいロケーションをホストに一意に識別する。
【００８７】
いくつかのオブジェクト指向のパラダイムが、デバイスによってホストされるサービスのアーキテクチャーを構築する際に利益をもたらすように利用されることが可能である。そのようなパラダイムのうち最も有用なパラダイムの１つが、１つのサービスから別のサービスへ、または或る特定のサービス内で１つのオブジェクトから別のオブジェクトへのサービスの振舞いの継承をモデル化する能力である。表２−１〜表２−３に示され、さらに図１０に示されるとおり、「ＳｅｒｖｉｃｅＩｎｆｏ」データセット１００２が、サービスの中の様々なオブジェクトの間の階層関係についての情報を提供する。サービスレベルで、２つのフィールドが、サービスの継承プロパティを定義する。第１のフィールド、ＢａｓｅＳｅｒｖｉｃｅＰＵＩＤ（符号１００６によって示される）は、サービス実施者が、Ｓｅｒｖｉｃｅ  ＰＵＩＤを指定することによって、サービスの１つのインスタンスが基本サービスの別のサービスの振舞いを直接に含むことを示すことを許す。このことは、継承関係１００８を「含み」、したがって、基本サービス１０１５上で定義されるすべてのフォーマットおよびメソッドに関して、派生したサービス１０２１上で定義されたフォーマットおよびメソッドが、基本実施形態を含む拡張された実施形態を表すことを暗示する。つまり、その基本サービス１０１５上で基本サービス１０１５によって指定された或る特定のフォーマットのオブジェクトが作成されることにより、派生したサービス１０２１上で派生した型のオブジェクトも作成されることになる。継承関係の使用は、或る特定のサービスが、基本サービスによって指定された何らかの事前定義された振舞いに参加することを要求されるが、より豊かな対話のための所望される機能のすべてを欠く場合に、有益である可能性がある。
【００８８】
第２のフィールド、ＵｓｅｓＳｅｒｖｉｃｅＧＵＩＤ（符号１０１２によって示される）は、現在のサービスの実施を定義するのに使用される０または１つ以上のサービスタイプＧＵＩＤのアレイである。従来のオブジェクト指向プログラミングパラダイムにおいて、このことは、「実施する」関係である。「含む」関係と同様に、「使用する」継承関係（符号１０２５によって示される）に関するすべての情報も、派生したサービス１０２１の定義の一部として利用可能である。しかし、派生したサービス１０２１上でオブジェクトを作成することによって、ユーザーサービス上でもオブジェクトが作成されるようになることはない。使用する継承関係は、サービス指向パラダイムにおける集約的な振舞いを定義するのに特に役立つ可能性がある。例えば、使用する継承関係は、或る特定のサービス、使用するサービスに関する１つの一般的なパターンを指定することを可能にし、次に、複数のサービスが、すべてのサービス上で同一の情報をレプリケートしなければならないのではなく、使用するサービスから継承することを可能にする。ＵｓｅｓＳｅｒｖｉｃｅＧＵＩＤとして使用するためのコントラクトをもたらすためだけに存在する或る特定のデバイス上のデバイスによってホストされるサービスは、抽象サービスと呼ばれ、さらにＳｔｏｒａｇｅ  ＩＤを指定せず、オブジェクトの永続、またはメソッドの呼び出しを防止する。
【００８９】
サービスレベル継承に加えて、「ＳｅｒｖｉｃｅＩｎｆｏ」データセットの定義は、データオブジェクトレベルおよびメソッドオブジェクトレベルにおける詳細な関係を定義する。データオブジェクトの場合、「含む」関係のサポートは、一般に、派生したサービス１０２１におけるデータオブジェクトが、そのオブジェクトが含む基本サービス１０１５におけるデータオブジェクトを指定できることを一般に要求する。この関係は、定義されるデータフォーマットのそれぞれに関するＦｏｒｍａｔＢａｓｅＩＤフィールドを使用して定義される。
【００９０】
メソッドオブジェクトの場合、関連付けは、一般に、メソッドオブジェクトが関連付けられるデータオブジェクトを定義することを一般に要求される。一部の事例において、メソッドオブジェクトは、サービス全体に適用されることが可能である。連絡先の例に戻ると、標準のｖＣａｒｄ（元は「Ｖｅｒｓｉｔｃａｒｄ」と呼ばれていた）などの或る特定のデータセットから連絡先が作成されることを可能にするサービスメソッドオブジェクトが、定義されることが可能である。この場合、メソッドは、個別のデータオブジェクトではなく、サービスオブジェクトに関連付けられる。
【００９１】
さらに、いくつかのデータオブジェクトフォーマットは、それら自体が、メソッドをサポートすることが可能である。例えば、ｖＣａｒｄストリームからオブジェクトを翻訳するサービスメソッドによって作成される連絡先オブジェクトは、その連絡先から電話呼が受信された際に再生されるべき特定の着信音に連絡先オブジェクトを関連付けるメソッドを有することが可能である。
【００９２】
次に、スクリプティング環境、または他のプログラミング環境を実施するのに使用されるスクリプト化されたデバイスサービス２１８（図２）を参照すると、図１１は、イニシエーター（例えば、ホスト１０２）上の自動化クライアントにデバイスによってホストされるサービスを公開するための例示的な構成１１００を示す。符号１１０５および１１１２によってそれぞれ示されるそのような自動化クライアントは、ホストアプリケーション１４６における機能要素として構成されることが可能であり、さらに／またはホスト１０２上で実行される他の何らかのコンポーネント１１２２の一部として構成されることが可能である。そのようなコンポーネント１１２２は、例えば、プロセス、メソッド、スレッドなどによって提供されることが可能な、様々なホストベースの機能のいずれかを表す。
【００９３】
Ｗｉｎｄｏｗｓインプリメンテーションにおいて、ＩＤｉｓｐａｔｃｈインターフェース１１２６が、自動化クライアント１１０５および１１１２にクライアントデバイス１１０上のデバイスによってホストされるサービスを公開するように提供される。ＣＯＭコンポーネント１０２は、例えば、通常、Ｃ＋＋またはＶｉｓｕａｌ  Ｂａｓｉｃを使用して、ＡｃｔｉｖｅＸ、または他の自動化サーバーツールもしくは自動化プログラミングツールを介して実施されることが可能な自動化クライアント１１０５および１１１２によるアクセスを可能にするＩＤｉｓｐａｔｃｈ  １１２６を実施する。しかし、デバイスによってホストされるサービスに関する本構成は、Ｗｉｎｄｏｗｓ  ＡＰＩモデルおよびＷｉｎｄｏｗｓプログラミングモデルに限定されず、類似した知られている自動化インターフェースが、或る特定の実施形態の要件に従って非Ｗｉｎｄｏｗｓ環境において実施されてもよいことが強調される。
【００９４】
例えば、オペレーティングシステムの特定のニーズに基づいて、Ｊａｖａ(登録商標)などの、異なるスクリプティング環境において使用するために提案されるソリューションを適合させることが可能である。本スクリプティングモデルおよび本プログラミングモデルにおける最も豊かな機会の１つは、新たなサービスを作成し、さらに関連付けられたサービス要求を扱う能力をデバイス側アプリケーション開発者に公開することである。例えば、移動電話機環境において、サードパーティアプリケーション開発者が、デバイス上に新たなサービスを作成して、インストールするようにＪａｖａ(登録商標)環境におけるサポートを活用することができる。デバイスが、Ｗｉｎｄｏｗｓ、または別のプラットフォームに接続される場合、デバイス側Ｊａｖａ(登録商標)アプリケーションは、ＭＴＰホストからのサービス要求に応答して、デバイスアプリケーション開発者が、同一のアプリケーションのＰＣバージョンを相手にした、より豊かなデータ交換モデルを作成することを可能にすることができる。自動化を実施するのに、スクリプト化が、しばしば、好んで利用されることが可能であるが、類似した機能は、通常、手続き型または宣言型、あるいはその両方のコンテキストにおけるネイティブコードを使用して提供されることも可能であることが理解されよう。
【００９５】
本明細書に記載されるデバイスによってホストされるサービスを所与として、Ｗｉｎｄｏｗｓ  ＰＣに接続されたクライアントデバイス上に存在する任意のＭＴＰデバイスによってホストされるサービスが、スクリプト化可能なＩＤｉｓｐａｔｃｈコンポーネントとして公開されることを可能にする、コンピューターによって実施される方法のセットが、定義されることが可能である。このことは、ＩＤｉｓｐａｔｃｈ世界とデバイスによってホストされるサービス世界の間をバインドする２つの基本クラスを活用することによって達せられる。
【００９６】
ＩＷＰＤＤｉｓｐａｔｃｈａｂｌｅＳｅｒｖｉｃｅと本明細書で呼ばれる第１の基本クラスは、サービス自体を表す。第１の基本クラスは、サービスにおいて識別された型の各型のオブジェクトを作成するためのメソッド、およびサービスに関連するプロパティへの直接のアクセスを提供するためのメソッドを公開する。このサービスの実施形態は、既存のＷＰＤ  Ｄｅｖｉｃｅ  ＡＰＩに基づき、さらにデバイスによってホストされるサービスが、使用される情報に到達するのに、このＡＰＩに提供される拡張を使用する。サービスオブジェクトおよびサービスプロパティへのアクセスを公開することに加えて、サービスにバインドされた任意のデバイスによってホストされるサービスメソッドが、公開されることも可能である。
【００９７】
オブジェクトは、本明細書でＩＷＰＤＤｉｓｐａｔｃｈａｂｌｅＯｂｊｅｃｔと呼ばれる類似したインターフェース上に構築される。この型のオブジェクトは、オブジェクトを変更する、削除する、あるいはオブジェクト上の変更をコミットするための基本機能に加えて、デバイス上に存在するサービスによって定義された、オブジェクトに関連するプロパティとメソッドの両方を公開する。
【００９８】
両方の事例において、ＳｅｒｖｉｃｅＩｎｆｏデータセットの一部としてデバイス上で担持される情報は、公開される様々なプロパティおよびメソッドに名前および意味を与える。フォーマット（オブジェクト／メソッド）とプロパティの両方についての詳細な情報を与える既存のＭＴＰプロトコルの能力を所与として、その情報をクライアントデバイスにサブミットすることに先立って、ホストＰＣ基本オブジェクト内で妥当なエラー処理を実行することも可能である。ＩＷＰＤＤｉｓｐａｔｃｈａｂｌｅＳｅｒｖｉｃｅとＩＷＰＤＤｉｓｐａｔｃｈａｂｌｅＯｂｊｅｃｔの両方が、クライアントデバイスへの往復の回数を最小限に抑えて、その結果、パフォーマンスを向上させるような仕方で、新たなオブジェクトを初期設定することなどの一般的なシナリオに従って、プロパティおよび要求をキャッシュする能力も有することが理解されよう。
【００９９】
スクリプト化可能な環境の一部として、設定サービス７１０Ｎが、単独で、またはステータスサービス７１０５と組合せで、診断およびトラブルシューティング、デバイスセットアップおよびデバイス構成、ならびに新たなデバイスアプリケーションおよびデバイス機能のインストールおよび管理などのサービスを円滑にするのに使用されることが可能であることが予期される。例えば、問題を診断し、修復しようとしている際、クライアントデバイスユーザーが、デバイスをユーザーのＰＣに接続し、次に、ＰＣのウェブブラウザをデバイス製造業者のウェブサイトに向わせることができる。ステータスサービスおよび設定サービスは、それぞれ、デバイスステータスおよびリモートコントロール機能を公開し、その結果、より効果的なトラブルシューティングおよび修復が、デバイス製造業者からのウェブによってホストされたアプリケーションとして実施されることを可能にする。もちろん、そのようなサービスは、単に例示的であり、特定の応用例によって要求される可能性がある、様々な異なるウェブ体験が、本デバイスによってホストされるサービスを使用して実施されることが可能であることが、当業者には理解されよう。
【０１００】
ウェブページのようなシンクライアント環境から直接に任意のデバイス上で利用可能である豊かなサービスにアクセスする能力は、デバイスに相当のセキュリティ上の脅威となる可能性がある。例えば、ユーザーは、或るウェブページをクリックするようにソーシャルエンジニアリングされる可能性があり、クリックすることにより、ユーザーのデバイスの内容が読み取られる、または消去されることになる。したがって、そのような不適切な使用を防止するのに役立つ様々なセキュリティ方法が、実施されることが可能である。一事例において、デバイスによってホストされるサービス自体が、互いに共有される秘密に基づいて或るレベルの信頼を確立した後に、セキュリティで保護された通信を獲得し、使用するためのモデルを定義することが可能である。代替として、クライアントデバイスへのアクセスが、デバイスにアクセスすることを承認されたウェブページ、例えば、クライアントデバイス製造業者のサイトだけに制限されることが可能である（前述の例において説明されるとおり）。さらに、すべてのウェブページが検証されて、許可されることを可能にするセキュリティで保護されたプライベートウェブ環境を作成するための従来の方法が実施されることが可能であり、このことは、これらの要件をサポートすることを所望する誰でも、クライアントデバイスへのアクセスを許可されることを可能にする。
【０１０１】
セキュリティで保護されたコンテキストが整えられると、このコンテキストにおける許可されたすべての参加者は、或る特定のデバイスによってホストされるサービスに接続し、使用する能力を有すると想定することが妥当となり得る。そのようなモデルをサポートするため、そのコンテキスト内でサポートされるデバイスの数およびタイプを発見するためのメソッドを公開すること、ならびにそれらのメソッドが提供するサービスのそれぞれを発見することも必要となる。
【０１０２】
この場合に定義されるメソッドは、デバイスにアクセスするためのウェブコンテキストを作成することに固有である。或る特定のクライアントデバイス上のデバイスによってホストされるサービスにアクセスすることができることから、やはり利益を得ることが可能な、他の開発モデルも存在することを理解されたい。これらのモデル内の開発を円滑にするのに、サービスは、これらの非スクリプティング環境に公開されることも可能であることが理解されよう。このバインドが行われることを許すことは、ターゲット環境の必要な要件が満たされたことを暗示する。
【０１０３】
主題は、構造上の特徴、および／または方法上の動作に固有の言い回しで説明されてきたものの、添付の特許請求の範囲において規定される主題は、それらの特定の特徴または動作に必ずしも限定されないことを理解されたい。むしろ、前述した特定の特徴および動作は、特許請求の範囲を実施する例示的な形態として開示される。
【図１】
2010541043.tif 000009
【図２】
2010541043.tif 000010
【図３】
2010541043.tif 000011
【図４】
2010541043.tif 000012
【図５】
2010541043.tif 000013
【図６】
2010541043.tif 000014
【図７】
2010541043.tif 000015
【図８】
2010541043.tif 000016
【図９】
2010541043.tif 000017
【図１０】
2010541043.tif 000018
【図１１】
2010541043.tif 000019
【国際調査報告】
2010541043.tif 000020
2010541043.tif 000021