JP2008511049A5

JP2008511049A5 -

Info

Publication number: JP2008511049A5
Application number: JP2007526602A
Authority: JP
Filing date: 2005-08-18
Publication date: 2010-01-14
Anticipated expiration: 2025-08-18

Description

移動通信装置の管理をウェブブラウジングに統合する方法および装置

本発明は一般に、移動通信装置および方法に関し、特に詳しくは、無線通信端末や機器を用いて、コンテント・デリバリ、ウェブ・ブラウザおよびデバイスソフトウェアを無線で配信することに関する。

移動通信装置内のソフトウェアの量が増え、複雑さが増すにつれて、製造業者、サービスプロバイダおよびソフトウェア開発業者にとって、製造後にモバイル装置の構成やそのソフトウェアの構成要素を保守管理する必要がますます高くなっている。例えば、アドオン・アプリケーションまたは商用コンテンツをモバイル装置のユーザに販売するには、理想的には、ソフトウェア・モジュールの互換性を検証することと、相互に関連する従属性を管理することとが必要である。比較的簡単なコンテンツ・デリバリ（例えば、音楽のダウンロード等）については、装置の汎用プロファイルまたは型式情報を提供することで十分であるが、アプリケーションのインストールや、特にファームウェアの更新については、配信するバージョンおよびダウンロードパッケージを正確に選択するためには、詳細なモバイル装置情報を得ることが不可欠である。しかしながら、多くの場合、これらの重要な詳細についてユーザが知らなかったり、ユーザが、ユーザ・インターフェースを介して見ることはできなかったり、その両方であったりする。

オープン・モバイル・アライアンス（Open Mobile Alliance（ＯＭＡ））は、サービス・イネーブラのセットを標準化して、デジタル製品に関する装置の管理およびダウンロードの必要性を満たすようにした。しかしながら、規格の多くは、モバイル領域について高い関心が置かれているので、アーキテクチャ構成要素として、より汎用のデジタル配信システムエンティティに統合することを、直接行えるものではない。

多くの場合、モバイル装置に対してデジタル配信を行うには、電子商取引が重視されている。従って、技術レベルでの装置管理タスクに加えて、需要の創出、メニューの閲覧、選択、ユーザの要求および支払いといった、ユーザレベルの側面がいくつかある。当然の技術選択およびユーザ・インターフェースを実行する現在の事実上の方法とは、ウェブ技術、特にＨＴＴＰブラウジングおよびウェブ・アプリケーションを介して行うことである。従って、前述の問題に対処する試みとしてすべてのものが、理想的には、ウェブ・ブラウザを含む、既存のそして将来のウェブ関連技術と互換性があり、かつ相互運用が可能である必要がある。

ユーザ側を更新する汎用インターフェースとして、次の米国特許が挙げられる。すべてリチャード・Ｒ・レイズマン（Richard R. Reisman）による。米国特許第5,694,546号、"マニフェスト・リストを用いたベンダ提供トランスポート・ソフトウェアによるサーバとクライアントとの間での自動無人化電子情報伝送システム（System for Automatic Unattended Electronic Information Transport Between a Server and a Client by a Vendor Provided Transport Software with a Manifest List）"、米国特許第6,125,388号、"ユーザ局に記憶したユーザ変更可能マニフェストに基づくユーザ局と複数のリモート・ソースとの間で情報オブジェクトを送信するシステム（System for Transporting Information Objects Between a User Station and Multiple Remote Sources Based upon User Modifiable Object Manifest Stored in the User Station）"、米国特許第6,594,692号、"電子商取引処理方法（Methods for Transacting Electronic Commerce）"、米国特許第6,658,464号、"リモート・ソースから送信、記憶、コンテンツ提示を制御するユーザ局ソフトウェア（User Station Software that Controls Transport, Storage, and Presentation of Content from a Remote Source）"。
米国特許第5,694,546号公報米国特許第6,125,388号公報米国特許第6,594,692号公報米国特許第6,658,464号公報

好適な実施形態のまとめ

これらの教示の現在の好適な実施の形態により、前述の問題と他の問題とを克服し、他の利点を実現する。

一側面では、本発明は、ユーザがサーバと相互作用することを組み合わせて、装置セッションを自動化する方法およびシステムを提供する。方法は、ブラウジング・セッション中に特定のタイプのＨＴＴＰリクエスト・メッセージを装置から受信したことに応答して、ＨＴＴＰ応答メッセージを装置に送信することを含む。ＨＴＴＰ応答メッセージは、装置管理セッションが起動されたことを示す専用ＭＩＭＥタイプを含み、ＨＴＴＰ応答メッセージの一部を構成する識別子により、装置管理セッションが識別される。装置は、装置の詳細および識別子を含む装置管理セッション返答により、ＨＴＴＰ応答メッセージに返答する。装置の詳細を用いて、システムは、装置と互換性のある少なくとも１つのダウンロード・オプションを含むリストを生成して、リストをユーザに送信する。ユーザが少なくとも１つのダウンロード・オプションをリストから選択したことに応答して、装置管理セッション中に、システムは、選択した少なくとも１つのダウンロード・オプションを装置に配信する。

別の側面では、本発明は、無線ネットワークを介して、方法に基づいて動作するコントローラを有する装置に、情報をダウンロードさせる方法を提供する。方法は、無線ＨＴＴＰセッション中に、ダウンロード可能な情報について、装置で問い合わせを行うステップと、問い合わせに応答して、装置とのセキュアな装置管理無線ダイアローグを開始して、装置の少なくともある機能を記述する装置に特有のパラメータを得るステップと、装置の機能と互換性のあるダウンロード可能な情報を記述する、少なくとも１つのエントリを含むリストを生成して、リストを装置に送信するステップと、無線ＨＴＴＰセッション中に、少なくとも１つのエントリをリストから選択して、装置にダウンロードするステップとを含む。

本発明のさらに別の側面では、無線ネットワークを介して装置に情報をダウンロードする装置と動作可能な装置管理サーバを提供する。装置管理サーバは、装置と接続する第１のインターフェースと、ワークフロー・マネージャと接続する第２のインターフェースと、装置が、無線ＨＴＴＰセッション中に、ダウンロード可能な情報について問い合わせを行なうことに応答して起動する動作を行うプログラムで動作するコントローラとを備える。装置管理サーバではさらに、ワークフロー・マネージャが装置とのセキュアな装置管理無線セッションを開始して、装置の少なくともある機能を記述する装置に特有のパラメータを得て、第２のインターフェースを介して、ワークフロー・マネージャと協働して、装置の機能と互換性のあるダウンロード可能な情報を記述する、少なくとも１つのエントリを含むリストを生成して、前記第１のインターフェースを介してリストを装置に送信して、無線ＨＴＴＰセッション中に、装置のユーザが選択したリストからの少なくとも１つのエントリに対応する情報を装置にダウンロードする。

本発明のさらに別の側面では、装置と、無線ネットワークを介して装置に情報をダウンロードする装置管理サーバと動作可能なワークフロー・マネージャを提供する。ワークフロー・マネージャは、ウェブ・サイトを介して装置と接続し、装置管理サーバに接続する第１のインターフェースと、少なくとも１つのバック・エンド・システムと接続する第２のインターフェースと、装置が、無線ＨＴＴＰセッション中に、ダウンロード可能な情報についてウェブ・サイトに問い合わせを行なうことに応答して起動する動作を行うプログラムで動作するコントローラとを備える。ワークフロー・マネージャは、装置とのセキュアな装置管理無線セッションを開始して、装置の少なくともある機能を記述する装置に特有のパラメータを得て、第１のインターフェースを介して装置管理サーバと、第２のインターフェースを介して少なくとも１つのバック・エンド・システムと協働して、装置の機能と互換性のあるダウンロード可能な情報を記述する、少なくとも１つのエントリを含むリストを生成する。ワークフロー・マネージャはさらに、第１のインターフェースとウェブ・サーバとを介して、リストを装置に送信する。

好適な実施形態の詳細な説明

添付の図面を参照して、本発明による教示に関する前述の側面および他の側面について、以下の好適な実施の形態に関する詳細な説明からさらに明らかになるであろう。

現在の本発明の好適な実施の形態に対し, 現在の前記当するウェブ関連技術を記載している文献例として、次のものが挙げられる。
RFC2616：ハイパーテキスト転送プロトコル-HTTP/1.1, IETF, 1999年6月
RFC2109：HTTP状態管理メカニズム, IETF, 1997年2月
SyncML装置管理プロトコル, バージョン1.1.2（OMA-SyncML-DMProtocol-Vl_1_2-20030612-C）, オープン・モバイル・アライアンス, 2003年6月

デジタル配信トランザクションをユーザが快適に行えるようにするために、発明者は、詳細なレベルの装置情報収集手順および管理手順を自動化して、シームレスでデジタル配信トランザクションと統合することを実現している。本発明の好適な実施の形態では、ウェブブラウジングベースのデジタル配信トランザクションに統合したサブコンポーネントとして、ＯＭＡサービス・イネーブラ（OMA service enablers）、好ましくはＯＭＡ装置管理（OMA Device Management）およびＯＭＡダウンロード（OMA Download）を利用するモデルを用いる。現在の本発明の好適な実施の形態を用いると、ファームウェア・アップデートを使用する場合に特に利点があるが、これを他のデジタル配信アプリケーションに適用して、利点を得ることもできる。

本発明の目的において、"ファームウェア"を、装置１０一部を構成するデータ・プロセッサで、直接または間接的に（例えば、コンパイラまたはインタープリタを介して実行した後で）実行可能な比較的下位レベルの言語で記述したコンピュータ・コードを含むものであると考えることが可能である。ファームウェア、またはファームウェアのアップグレードは非限定的な例として、オペレーティング・システム・モジュール、ＨＴＴＰプロトコル・スタック・インプリメンテーションの変更、基礎となる通信規格の変更により必要な、無線ネットワークアクセスおよび／または走査手順およびその改良が挙げられる。これに対して、"アプリケーション"は、改良されたインターネットブラウザ、別のインターネットブラウザ、メディア・プレーヤ、ネットワークに備えられた画像データベースに取り込んだ画像を記憶するための画像取込プログラム（装置１０がデジタルカメラを含むと仮定する場合）等、装置１０に、選択可能な新たな機能を付与する上位のレベルのプログラムと考えることができる。理解できるように、そのオペレーティング・システムソフトウェアの変更レベル、インストールしたメモリの量、そのデジタルカメラの型式（例えば、モデル番号）および他の形式のパラメータ等の装置１０の構成および動作の詳細は、装置１０にダウンロードするファームウェアまたはアプリケーション・ソフトウェアの型式および／または変更レベルに大きな影響を与えることがある。一例であるが、装置１０のハードウェアと互換性のないファームウェアまたはアプリケーション、または装置１０にインストールされたメモリより多くメモリを必要とするもの、またはオペレーティング・システムのバージョンが装置１０の製造日より後でリリースしたものと考えられるものを、ユーザがダウンロードしたい場合がある。これらのいずれの場合も、ユーザがリクエストしたファームウェアまたはアプリケーションをダウンロードするだけで、ユーザに重大な問題を引き起こし、ウェブ・サイト３０で、ユーザがあまり快適とは言えない経験をする場合もある。このことは、装置１０の製造業者、またはユーザ１が加入しているネットワークのオペレータに関連する場合もある。本発明の動機の１つは、このような問題を回避して、ユーザに与える影響を最小限にすることである。好ましくは、ユーザが、ユーザ相互作用型および非ユーザ相互作用型（例えばバックグラウンド型）の動作を最適な形で行えるようにすることである。

はじめに、以下に述べる本発明の好適な一例としての実施の形態は、ＯＭＡフレームワークにあるが、本発明は、ＯＭＡベースのイネーブラおよび技術に限定して用いられるものではないことを理解されたい。

はじめに、論理レベルシーケンス図の型式で、電子商取引向けのユースケースの一部として、デジタル配信の典型的なシーケンスを図１に示す。図１は、移動局（ＭＳ）１０に対応付けられたエンド・ユーザ１と、ＤＭサーバ２０と、ウェブ・サーバ３０とを示す。ユーザセッションは、エンド・ユーザ１とウェブ・サーバ３０との間で行われるとし、装置セッションは、ＭＳ１０とＤＭサーバ２０との間で行われるとする。図１は、ＭＳ１０に対する従来のデジタル配信セッションに発生する問題を説明するのに便利であるので、本発明の好適な実施の形態による改良をよく理解することに役立つだろう。

本発明の教示は、多くのユーザ・インターフェース技術に適用することができ、ウェブ・インターフェース技術に限定されるものではないことに留意されたい。非限定的な例として、本発明の教示はまた、無線アプリケーションプロトコル（ＷＡＰ）技術およびＪＡＶＡ（登録商標）ベースのアプリケーションに適用することもできる。

図１を参照する。順調なマーケティングが正常に行われた結果と、ウェブリンク情報とにより、ユーザ１が、移動局で購入できるダウンロード可能なアイテムを有するウェブ・サイト３０にたどり着いたと仮定する。このやりとりを、一般的なブラウジング４０として示す。ユーザ１に示す選択肢が、ユーザのＭＳ１０と実際に互換性があって確実に動作するようにするために、サーバ側のシステムは、ＭＳ１０の機能をわかっている必要がある。このことを行うための従来のマニュアルの手順では、ＭＳ１０モデルの範囲の多様なデジタル製品範囲に限定されていて、ユーザ相互作用の開始点として、ユーザ１にＭＳ１０型式情報の入力を要求するものである。しかしながら、従来のアプローチには固有の欠点が多数ある。いくつかの例として、まずはじめに、このアプローチでは、ユーザ１はつまらないデータ・エントリ・タスクを実行することを要求されるという、不快な経験をすることになる。さらに、ユーザに対する命令を完璧に行わない限り、ユーザ１は、ウェブ・サーバ３０を見限って、所望のデジタル配信を求めて別のところへ行ってしまうこともある。第２に、ユーザ１に情報の入力を要求することにより、情報信頼性を脅かすことになる。正常に配信するために（そして、特に、配信したアプリケーションまたはファームウェアを正常に起動させるために）、装置情報の正確さが非常に重要な場合もある。第３に、そして第１の２つの問題に関連して、要求される情報の複雑さは、ユーザ１が情報を知らず、ＭＳ１０の従来のユーザ・インターフェースを用いて検索することができないというようなものである。

ユーザセッション４０の他に、別の装置セッション４２を用いて、十分な装置情報を収集して、ユーザ１に別のダウンロード可能なアイテムのメニューを生成する。このメニューを、ウェブ・ベースのユーザセッション４４で提示することもできる。ユーザ１がメニューを介して閲覧し、別の情報を読み取り、選択して配信を行うことが可能である。最後に、ユーザ１が選択を行うことにより、第２の装置セッション４６を介して、配信および関連装置管理タスクを完了する。

発明者は、図１に示す一例のシナリオで発生する問題とは、２つの異なるセッション（ユーザセッションおよび装置セッション）を組み合わせて、それらセッションの間でデータを送信する最も良い方法は何かというものであると認識した。例えば、ユーザ１がウェブ・ブラウザを用いてウェブ・サーバ３０にたどり着いて、適切なアイテムのリストを要求した後で、ＯＭＡ装置管理セッションを開始して、装置（ＭＳ１０）機能および互換性情報を得るのに最も良い方法は何か？そして、この自動情報収集を完了したとすると、ウェブセッションの結果をユーザのブラウザに返信する最も良い技術は何か、と言うことである。換言すれば、ユーザのウェブブラウジング・セッションとＯＭＡＤＭセッションを統合する、あるいは起動する最もタイミングのよい方法は何かと言うことである。

ユーザブラウザとＯＭＡＤＭセッションとを統合する際に固有の、基礎となる問題をさらに深く理解するために、ウェブ技術（ＨＴＴＰの場合）およびＯＭＡ装置管理（OMA Device Management）の重要な基本原理について、いくつか簡単に説明する。

ＨＴＴＰは、簡単で強力な、ウェブのネットワーク・プロトコルである。通常、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）ソケットの最上部で実行され、リソース（ファイル、アプリケーション出力）をＨＴＴＰサーバ（通常はウェブサーバ）からＨＴＴＰクライアント（ウェブ・ブラウザ等）へ伝送する。

ＨＴＴＰはステートレスプロトコルなので、元々は、ウェブセッションの概念はＨＴＴＰには存在しない。すなわち、リクエストおよび応答という２つのメッセージを有し、別の方法として、ＧＥＴ、ＰＯＳＴおよびＨＥＡＤを含んでいる。元々の意味では、リクエスト・メッセージが送信された時にＨＴＴＰ"セッション"が開始し、応答・メッセージを受信した時にそのＨＴＴＰセッションが終了する。

はじめは、各対のリクエスト・応答・メッセージの後、基礎となるＴＣＰ／ＩＰセッションはクローズした。しかしながら、ウェブ技術が進歩して、より広範囲にわたって用いられるようになると、ウェブ・ページ大きさと複雑さとが劇的に増加して、数十または数百の異なるＨＴＴＰリソース（点滅するＧＩＦアイコン、明滅するバナーおよび動画サムネイル広告等）を有する、典型的な現在のようなウェブ・ページとなっている。ＨＴＴＰウェブ・ページの複雑さが増加した結果、クライアントおよびサーバの両方で、各ＨＴＴＰリクエスト用専用ＴＣＰ／ＩＰソケットの開始および閉止を行うリソース算出費用が膨大になっている。それに応じて、プロトコルの専門家が、継続するＴＣＰ／ＩＰ接続を用いる技術を規格化した（ＨＴＴＰ１．１）。しかしながら、適した継続するＴＣＰ／ＩＰソケット用いたとしても、予めＨＴＴＰリクエスト・メッセージを用いないと、サーバが応答メッセージをクライアントに送信することはできない。換言すれば、ウェブ・サーバが情報をブラウザに送ることができない（RPC2616：ハイパーテキスト転送プロトコルHTTP/1.1, IETF, 1999年6月を参照）。

ＨＴＴＰがステートレス指向であるにもかかわらず、さらにウェブ・アプリケーションが現れるようになると、ウェブセッションの必要性が早くも明らかになった。ＨＴＴＰ状態管理メカニズム（RFC2109：HTTP状態管理メカニズム, IETF, 1997年2月参照）は、ＨＴＴＰの上位において、いくつかのＨＴＴＰ・メッセージをある特定のユーザセッションと組み合わせる機能を、ウェブ・アプリケーション開発者に提供している。インプリメンテーションとして、全メッセージ内のユーザおよびセッション関連情報をクライアントからサーバに送信するクッキーを含んでいる。典型的には、サーバがクッキーを暗号化して、不正なクライアントがそのコンテンツを改ざんすることを防止する。

次にＯＭＡＤＭの説明に移る。ＯＭＡＤＭの省略されていない名称は、ＳｙｎｃＭＬ装置管理プロトコル（SyncML Device Management Protocol）が、装置管理ドメインにＳｙｎｃＭＬを用いていることを示している。これは、ＤＭクライアントおよびＤＭサーバで実行するクライアントサーバプロトコルである。

ＤＭクライアントは、扱いやすいオブジェクトを含むツリー形式のデータ構造の管理ツリーを含んでいる。要求される装置管理タスクを実行するために、ＤＭサーバは、管理ツリー内のオブジェクトをターゲットとしたGet，Replace，Exec等のコマンドを用いる。

ＯＭＡＤＭにより、サーバと、図１のＭＳ１０等の装置との間のやりとりを最適化する。ユーザとのやりとりに対して、通知およびユーザ選択等の機能を実行する簡単なコマンドがあるが、一般に、ＯＭＡＤＭのユーザ・インターフェース機能は非常に制限されている。

ＯＭＡ装置管理セッションを設定する前に、装置は、"ブートストラップされる（立ち上げられる）"必要がある。ＳｙｎｃＭＬ装置管理プロトコル規格により、２つの立ち上げ方法が規定されている。

（ａ）製造する際に、装置にＳｙｎｃＭＬＤＭブートストラップ情報をロードするカスタマイズブートストラップ（工場ブートストラップとも呼ぶ）。

（ｂ）例えばＷＡＰＰｕｓｈまたはＯＢＥＸといったあるプッシュメカニズムを介してサーバがブートストラップ情報を送信する、サーバ起動ブートストラップ。この方法では、サーバは、装置のアドレス／電話番号を事前に通知される必要がある。

ブートストラップ手順を行う間、サーバアドレスやＩＤ，クライアントおよびサーバ関連認証情報を含む、多数のパラメータが、装置に設定される。現在の本発明の好適な実施の形態では工場ブートストラップ手順を用いるようになっているが、サーバ起動ブートストラップ手順を用いてもよい。

本発明の現在の好適な（非限定的な）実施の形態に最も密接に関係する、ＨＴＴＰおよびＯＭＡＤＭ環境について説明したので、本発明による方法および装置の現在の好適な実施の形態について説明する。

本発明の注目すべき側面は、ＯＭＡＤＭセッションを開始し、ブートストラップパラメータを装置に送信するＨＴＴＰ応答メッセージに、専用のＭＩＭＥタイプを用いることと、クライアントプロビジョニングメッセージ（client provisioning message）のブートストラップ情報を秘密鍵で暗号化すること（ブートストラップ情報の代わりに通知を用いることもできる）と、上位層のデジタル配信セッションおよびそのＩＤを用いて、ウェブセッションおよび装置セッションを１つの全体的な論理トランザクションにまとめることと、を含む。本発明の別の側面は、待機ＨＴＴＰリクエスト（queued HTTP request）を用いることにより、装置セッション後のウェブセッションに制御を戻す手順と、定義済みのＵＲＬを有するウェブ・ブラウザオブジェクトに対するＯＭＡＤＭＥｘｅｃコマンドと、前に送信した起動プロンプトに対するユーザ・応答とに関する。

特に、この本発明の別の側面が意味することは、次のことである。

１．待機ＨＴＴＰリクエスト（queued HTTP request）
ＨＴＴＰ応答（以下に述べる図２のメッセージ（ｇ））に対する応答として、ＤＭセッション確立（DM session establishment）（以下に述べる図２のメッセージ（ｈ））の他に、装置１０は、ウェブ・サーバ３０に対するＨＴＴＰリクエストを生成する。ウェブ・サーバ３０は、ユーザオプション・メッセージ（以下に述べる図２のメッセージ（ｏ））を受信するまでリクエストをキューに入れて、応答をブラウザ１０Ｂに送信する（以下に述べる図２のメッセージ（ｐ））。

２．ＯＭＡＤＭＥｘｅｃ
メニューを生成した後で（以下に述べる図２のアクティビティ（ｎ））、ワークフロー・マネージャ５０が、ＤＭサーバ２０に、装置１０のＤＭクライアント１０ＡにＥｘｅｃコマンドを送信するように要求する。それによって、装置のウェブ・ブラウザ１０Ｂを起動して、ＨＴＴＰリクエストをウェブ・サーバ３０に送信するように要求する。選択肢（以下に述べる図２のメッセージ（ｏ））をＨＴＴＰ応答（以下に述べる図２のメッセージ（ｐ））でウェブ・ブラウザ１０Ｂに送信することにより、ウェブ・サーバ３０はこのＨＴＴＰリクエストに応答する。

３．起動プロンプトに対するユーザ・応答
ＨＴＴＰ応答（以下に述べる図２のメッセージ（ｇ））の一部として、ウェブ・ブラウザ１０Ｂに存在させるユーザ・インターフェース情報がある。このユーザ・インターフェースアクティビティは、ユーザにプロンプト（例えば"お待ちください。装置情報を収集しています。"）および発信（例えば、"ｏｋ"）ボタンを提示することを含む。ユーザが情報（例えば、"ｏｋ"ボタンを押すこと）を確定すると、ウェブ・ブラウザ１０ＢがＨＴＴＰリクエストをウェブ・ブラウザ３０に送信する。次に、このリクエストを選択肢１（待機中のＨＴＴＰリクエスト）として処理する。

一般に、ＭＩＭＥは、元々、インターネット・メールの拡張フォーマットであり、非ＵＳ-ＡＳＣＩＩテキスト・メッセージ、非テキスト・メッセージ、マルチ・パート・メッセージ・ボディ、メッセージヘッダ内に非ＵＳ-ＡＳＣＩＩ情報を含めることが可能となるように作られたものである。次のＲＦＣは、ＭＩＭＥを定義している。ＲＦＣ２０４５：ＭＩＭＥ第１部：インターネット・メッセージ・ボディのフォーマット、ＲＦＣ２０４６：ＭＩＭＥ第２部：メディアタイプ、ＲＦＣ２０４７：ＭＩＭＥ第３部：非ＡＳＣＩＩテキスト用メッセージヘッダ拡張、ＲＦＣ２０４８：ＭＩＭＥ第４部：登録手続き、およびＲＦＣ２０４９：ＭＩＭＥ第５部：準拠基準および例である。インターフェースにもＲＦＣ１３４１（１９９２年６月）が合ったが、ＲＦＣ１５２１により廃止されている。ＭＩＭＥ（汎用インターネット・メール拡張）第１部：インターネット・メッセージ・ボディのフォーマットを指定し手記述するメカニズム（１９９３年９月）、およびＲＦＣ１３４２：ＭＩＭＥ（汎用インターネット・メール拡張）第２部：非ＡＳＣＩＩテキスト用メッセージヘッダ拡張（１９９３年９月）である。

図２の実施の形態を参照して、システムについて詳述する。これは、ユーザ１、図１のＭＳ１０等の装置、ウェブ・サイト（またはウェブ・サーバ）３０、ＤＭサーバ２０、上述のワークフロー・マネージャ５０および１つ以上のバック・エンド・システム６０の間の信号およびメッセージ・フローを示している。まず、ここで作用主体（actor）とも呼ぶ、これら各種の構成要素の機能および役割について以下に説明し、その後、図２に示す使用シーケンスについて説明する。

本発明の現在の好適な実施の形態では、本発明の手法をまったく限定するものではないが、装置１０とウェブ・サイト３０との間のリンクは、少なくとも部分的に、セルラー式ＲＦリンク、またはBluetooth（登録商標）リンク等の、または無線ローカル・エリア・ネットワーク（ＷＬＡＮ）リンク、または光リンク等の無線リンクを介して行われ、おそらくは、装置１０のネットワークプロバイダ（例えば、セルラー式ネットワーク・オペレータ、またはＷＬＡＮホット・スポットオペレータ）を介して行われることに留意されたい。

本発明を限定しないが、現在の本発明の好適な実施の形態を説明するために、ユーザ１は、装置１０を使用する人間である。ユーザ１は、コンテンツ、アプリケーションおよび／またはファームウェアの更新等の、ネットワークで入手可能な（おそらくは商用）デジタル製品に興味を持つ場合がある。ウェブ・ブラウザは、デジタル製品を見つけ、選択して配信を行うのに好適なアプリケーションである。ユーザ１は、装置１０を所有する必要はない。

本発明を限定しないが、現在の本発明の好適な実施の形態を説明するために、装置１０は、ＯＭＡＤＭクライアント・アプリケーション・インプリメンテーション１０Ａのインスタンスと、ＨＴＴＰ１．１準拠ウェブ・ブラウザ１０Ｂとを有するモバイル構成要素であるか、モバイル構成要素を含んでいる。ファームウェアを更新するために、一例の非限定的な例として、装置１０は、ＯＭＡファームウェアオーバー・ザ・エア（OMA Firmware Over the Air；ＦＯＴＡ）機能を有していてもよい。一例の非限定的な実施の形態として、装置１０は、携帯電話または非携帯電話、またはローカルおよび／またはワイド・エリア・ネットワーク（ＬＡＮおよび／またはＷＡＮ）の無線インターフェース（ＲＦおよび／またはＩＲ）を有するコンピュータ、またはＬＡＮおよび／またはＷＡＮの無線インターフェース（ＲＦおよび／またはＩＲ）を有するパーソナル・デジタル・アシスタント（ＰＤＡ）、またはユーザ１がブラウザを操作して、ウェブ・サーバまたはサイト３０に接続することが可能な任意の適したインターネット機器とすることもできる。この場合は、装置１０は典型的には、無線（ＲＦまたは光）送受信機を備える。

図３を参照して、図２のメッセージ・フロー・シーケンスに用いるのに適した、非限定的な例としての装置１０のブロック図を示す。装置１０は、メモリ１２に接続され、オペレーティング・システムおよび他の典型的なソフトウェアの他に、本発明によるＯＭＡ-ＤＭクライアント１０Ａを実行するソフトウェアを記憶するメモリに接続された、マイクロプロセッサ等のコントローラ１１とともにウェブ・ブラウザ１０Ｂを含むと考えられる。また、メモリ１２には、装置の詳細（例えば、ハードウェア機能、オペレーティング・システムバージョン、メモリ容量）を記憶する装置テーブル１０Ｃがあり、これは、製造時、または装置を初めて起動した際にロードされたものである。また、ユーザ・インターフェース（ＵＩ）１３、または適したＵＩのインターフェースが備えられている。ある非限定的な実施の形態では、ＵＩ１３は、ユーザ・ディスプレイ（例えば、ＬＣＤディスプレイ）１３Ａおよびキーボードまたはキーパッド１３Ｂのユーザデータエントリ装置を含んでいる。また、コントローラ１１は、典型的には携帯電話ネットワーク・オペレータ、または無線ＬＡＮネットワーク等の無線ネットワーク／オペレータを介して、ウェブ・サイト３０およびＤＭサーバ２０と通信を行う、適したＲＦまたは光送受信機１４に接続している。実施の形態の装置１０が有線の場合は、送受信機１４を、電気または光ケーブルまたは他の配線に接続してもよいことに留意されたい。

本発明を限定しないが、現在の本発明の好適な実施の形態を説明するために、ウェブ・サイト３０は、ユーザ１に対して、ユーザ・インターフェース（ＨＴＭＬページ）を実行するＨＴＴＰ１．１準拠ウェブ・サーバを含んでいたり、これにリンクしたりしている。ウェブ・サイト３０は好ましくは、他のサーバ側の構成要素（例えば、２０、５０、６０）に対して、ウェブ・アプリケーションおよびインターフェースを実行するアプリケーション・プログラム・インターフェース（ＡＰＩ）を有している。

本発明を限定しないが、現在の本発明の好適な実施の形態を説明するために、ＤＭサーバ２０は、ＯＭＡＳｙｎｃＭＬＤＭプロトコルスタックを実行し、装置１０のＤＭクライアント１０Ａと通信を行い、他のサーバ側の構成要素（３０、５０、６０）とのインターフェースを有している。ＳｙｎｃＭＬのインターフェースは、例として、ＳｙｎｃＭＬ装置管理プロトコル、バージョン1.1.2（OMA-SyncML-DMプロトコル-Vl_1_2-20030612-C, オープン・モバイル・アライアンス, 2003年6月）とともにＳｙｎｃＭＬ装置情報ＤＴＤ（バージョン1.1, 2002年2月）を備える必要がある。（ＤＴＤは文書種類定義を表す。）

図４を参照すると、図２のメッセージ・フロー・シーケンスに用いるのに適したＤＭサーバ２０の、非限定的な例としてのブロック図が示されている。ＤＭサーバ２０は、オペレーティング・システムおよび他の典型的なソフトウェア（ＳＷ）の他に、ＯＭＡＳｙｎｃＭＬＤＭプロトコルスタックを実行するソフトウェアと、装置１０のＯＭＡ-ＤＭクライアント１０Ａと通信を行うソフトウェアを記憶するメモリ２１に接続された、マイクロプロセッサ等のコントローラ２１を含むと考えられる。ＤＭサーバ２０は、装置１０およびワークフロー・マネージャ５０と通信を行う、入出力インターフェース（Ｉ／Ｏ）２２Ａおよび２２Ｂ（論理および／または物理Ｉ／Ｏであってもよい）を含んでいる。Ｉ／Ｏインターフェース２２Ａ、２２Ｂの２つを、インターネットでＴＣＰ／ＩＰを介して通信を行う論理インターフェースとして実施することもできることに留意されたい。

本発明を限定しないが、現在の本発明の好適な実施の形態を説明するために、ワークフロー・マネージャ５０は、全体的なデジタル配信処理、例えば、ファームウェア・アップデート・トランザクションを追跡する。ワークフロー・マネージャ５０は、一意のトランザクションＩＤ（ＴＩＤ）を生成して、ユーザ１や装置１０とのインターフェースとしてウェブ・サーバ３０およびＤＭサーバ２０を用い、個々の下位レベルのセッションを１つの論理トランザクションにまとめる。ワークフロー・マネージャ５０は、好ましくは、バック・エンド・システム６０のサービスを用いて、装置１０とのトランザクション中に、ある特定のタスクを完了する。

図５を参照すると、図２のメッセージ・フロー・シーケンスに用いるのに適した、ワークフロー・マネージャ５０の非限定的な例としてのブロック図が示されている。ワークフロー・マネージャ５０は、オペレーティング・システムおよび他の典型的なソフトウェア（ＳＷ）の他に、ＴＩＤを生成して、各種のトランザクションを管理して、装置１０および他のシステム構成要素と関係させるソフトウェアを記憶するメモリ５１Ａに接続した、マイクロプロセッサ等のコントローラ５１を含むと考えてよい。ワークフロー・マネージャ５０は、ウェブ・サイト３０、ＤＭサーバ２０およびバックエンド・サーバおよびシステム６０と通信を行うＩ／Ｏ５２Ａおよび５２Ｂ（論理および／または物理Ｉ／Ｏであってもよい）を含んでいる。ＤＭサーバ２０のように、Ｉ／Ｏインターフェース５２Ａ、５２Ｂは、インターネットでＴＣＰ／ＩＰを介して通信を行う論理インターフェースとして具現化されてもよい。

本発明を限定しないが、現在の本発明の好適な実施の形態を説明するために、バックエンド・サーバおよびシステム６０は、ワークフロー・マネージャ５０のサービスを提供する。これらに限定するものではないが、サービスは、認証、暗号化および署名のセキュリティサービス、法的および保証ステータス情報等の装置１０関連サービスとともに、製品データ管理（ＰＤＭ）情報等の詳細な製品管理サービスを含んでもよい。

本発明を限定しないが、現在の本発明の好適な実施の形態を説明するために、ウェブ・サイト３０およびＤＭサーバ２０を制御する同じエンティティにより、ワークフロー・マネージャ５０およびバック・エンド・システム６０も制御される。しかしながら、これは、本発明の手法を限定するものではなく、これら構成要素の一方または両方が、サード・パーティの制御下にあってもよい。例えば、バック・エンド・システム６０の一方が、サード・パーティのデジタル署名認証システム、またはサード・パーティのデジタル支払いシステムであってもよい。

図２の一例のシーケンス図に戻る。本発明の実施形態に従う、次のステップが実行される。

（ａ）で、ユーザ１は、競合するウェブ・サイトを閲覧して、所望のベンダのファームウェア（ＦＷ）アップデートページを検索する。

（ｂ）で、ユーザ１はＦＷアップデートページのリンクをクリックして、装置１０に利用可能な新規のＦＷアップデート選択肢（もしあれば）を確定する。

（ｃ）で、ウェブ・サイト３０は、装置１０を介してページをユーザ１に送信して、装置１０を介してＨＴＴＰ応答を用いて、自動装置情報収集処理をまもなく開始することをユーザ１に通知する。次のものが適したメッセージの例として考えられる。

"お待ちください。閲覧者の電話機用の要求されたファームウェアを検索中です。"

（ｄ）で、ユーザ１は、装置１０のユーザ・インターフェースを介して、自動装置セッションが確立したことを承認すると、ＨＴＴＰリクエストを生成して、ブラウザ１０Ｂからウェブ・サーバ３０に送信する。

（ｅ）で、ウェブ・サーバ３０は、ファームウェア・アップデート・トランザクション（ＦＷｕｐｄトランザクション）を開始して、ＯＭＡＤＭセッションを確立するユーザリクエストがあることを、ワークフロー・マネージャ５０に通知する。その応答として、ワークフロー・マネージャ５０は、一意のＴＩＤを用いて新規のトランザクションを生成する。

（ｆ）でバックエンドサービス６０を用いて、ワークフロー・マネージャ５０は、適切なＯＭＡクライアントプロビジョニング（Client Provisioning；ＣＰ）メッセージを生成して、秘密鍵で署名を行う。ＩＮＩＴＤＭメッセージを、暗号化したＣＰでウェブ・サイト３０に送信する。

（ｇ）で、ＨＴＴＰ応答の一部として、ウェブ・サイト３０は、ＯＭＡ装置管理専用のＭＩＭＥタイプと共に、署名されたＣＰメッセージを装置１０に送信する。また、ＨＴＴＰ応答メッセージにはＴＩＤが埋め込まれる。ＭＩＭＥタイプ情報および署名されたＣＰメッセージに基づいて、ステップ（ｈ）で、装置１０は、ＤＭブートストラップ情報の有効性を検証し、それに従ってパラメータを設定して、ＯＭＡＤＭクライアントアプリケーション１０Ａを開始する。

（ｉ）で、ＯＭＡＤＭクライアント１０Ａは、ＯＭＡＤＭセッションを確立して、装置１０の情報の詳細をＤＭサーバ２０に送信する。これら装置の詳細は、装置１０のメモリ１２のテーブル１０Ｃに記憶されていてもよいし、製造時、または装置を初めて起動した際に、ロードされたものであってもよい。このステップ（ｉ）は好ましくは、ユーザ１が介在することなく、自動的に行われるので、いずれの場合も、ユーザ１は、装置１０の情報を知っている必要はない。好ましくは、ＴＩＤも、ＤＭサーバ２０に返送する情報の一部として含まれる。

（ｊ）で、ＤＭサーバは、ＴＩＤと受信した装置情報とをワークフロー・マネージャ５０に送信する。（ｋ）で、ワークフロー・マネージャ５０は、バックエンドサービス６０と通信を行って、装置１０の情報の詳細の量とレベルとが選択肢リスト（ファームウェア・ダウンロード・オプション・メニュー）を生成するのに十分であるかどうか、判定する。装置１０について、詳細且つ特定の情報がさらに必要な場合は、（ｌ）で、ワークフロー・マネージャ５０が、ＤＭサーバ２０に適切なデータを装置１０から取得するように要求する。この場合は、（ｍ）において、ＤＭサーバ２０は、ＯＭＡＤＭプロトコルを用いることにより、装置１０の情報をさらに取得して、ワークフロー・マネージャ５０に返送する。

（ｎ）で、ワークフロー・マネージャ５０は、入手可能な選択肢のリスト、すなわち、エンド・ユーザ１に対するファームウェア・ダウンロード・オプション・メニューを生成する（あるいは、１つ以上のバックエンドサービス６０を用いて生成する）。

（ｏ）で、ワークフロー・マネージャ５０は、ファームウェア・ダウンロード・オプション・メニューをウェブ・サイト３０に送信して、（ｐ）で、ウェブ・サイト３０は、メニューをユーザ１のブラウザ１０Ｂに返送して、製品を選択させたり、（ウェブに適した形の）更なる情報を要求したりする。このことは、（ｐ）で、少なくとも３つの技術を介して行うことができる。その３つの技術とは、予めキューに入れておいたＨＴＴＰリクエストと、ウェブオブジェクトに対するＯＭＡＤＭＥｘｅｃと、前に送信したウェブ・ページ内でのユーザ・アクションである。

（ｐ）でどの技術を用いるとしても、さらにウェブブラウジングが行われ、ＨＴＴＰリクエストおよび応答（ユーザ１がウェブ・サイト３０と装置１０を介して行う）が行われて、結果として、要求されたファームウェアの配信および装置管理処理（装置１０およびＤＭサーバ２０）が、ステップ（ｑ）および（ｒ）でそれぞれ行われる。任意の適した技術およびメカニズムを用いて、ファームウェアを装置１０に実際にダウンロードできることに留意されたい。

本発明の実施形態における、ウェブセッションを自動ＤＭセッションと組み合わせるという側面には、ＨＴＴＰ応答メッセージ内でＯＭＡＤＭ通知メッセージを送信することが含まれる（図２のメッセージ（ｇ））。図６を参照すると、ＨＴＴＰ応答メッセージは一般に、Status Lineフィールド１０２，General Headersフィールド１０４，Response Headersフィールド１０６，Entity Headersフィールド１０８，キャリッジ・リターン・ライン・フィード（ＣＲＬＦ）１０９として示されるデリミタまたはセパレータ，Message Bodyフィールド１１０を含んでいる。非限定的な本発明の実施の形態で最も興味深いものは、Entity Headersフィールド１０８で、Content-Typeフィールド１０８Ａと、Content-Lengthフィールド１０８と、Last- Modifiedフィールド１０８Ｃとを含んでいる。特に興味深いものは、上述の所定のＭＩＭＥタイプを伝達するContent-Typeフィールド１０８である。非限定的な例として、一般通知起動セッションアラート・メッセージ（General Notification Initiated Session Alert message）用の所定のＭＩＭＥタイプは、Content-Type 108A："application/vnd.syncml.information"であってもよいし、Content-Typeコードは、0x44であってもよい。

図６に示すHTTP応答メッセージの構造の現在の好適な、非限定的な実施の形態では、ＯＭＡＤＭ通知を、Message Bodyフィールド１１０で送信する。

HTTP応答メッセージのコンテンツの一例として、次のようなものが挙げられる。

ＯＭＡＤＭ通知メッセージ１２０の一例の実施の形態のフィールドについて、図７に示す。ただし次のようである。

ＤＭ装置詳細メッセージ（DM Device Details message）（図２のメッセージ（ｉ））の非限定的な一例を以下に示す（インターフェースにはやはり次のものが必要である。ＳｙｎｃＭＬ装置管理プロトコル、バージョン1.1.2（SyncML Device Management Protocol, Version 1.1.2（OMA-SyncML-DM Protocol-Vl_l_2-20030612-C）, オープン・モバイル・アライアンス, 2003年6月）

前述の一例のおよび非限定的な例により、本発明を実施するために、発明者らが現在考える最も良い方法および装置について、十分に有益な説明を行ってきた。しかしながら、添付の図面および添付の請求の範囲を読むことにより、前述の記述から、各種の変更例および適用例当業者にとって明らかになるであろう。いくつかの例として、他の類似のまたは同等のダウンロードシナリオ、アプリケーション・プログラムおよびファームウェア・ダウンロード技術（例えば、ファームウェア・ダウンロードにＯＭＡＦＯＴＡ技術以外を用いることもできる）、メッセージング・タイプおよび装置管理プロトコルおよび方法を用いることにより、当業者が試みることも可能である。しかしながら、本発明の教示によるこのような類似の変更例については、やはり本発明の範囲に前記当するものである。

さらに、他の機能を対応して用いることなく、本発明のいくつかの機能を有利に用いることができる。従って、前述の記述は、本発明の原理を単に説明するものであって、これを制限するものではないと考える必要がある。

電子商取引向けのユースケースの部分的なデジタル配信の典型的なシーケンスを示す論理レベルシーケンス図である。本発明の好適な実施の形態による、装置を用いて発生する、一例のファームウェアのメッセージ・フロー・シーケンス図を示す。図２のメッセージ・フロー・シーケンスに用いるのに適した装置のブロック図を示す。図２のメッセージ・フロー・シーケンス用いるのに適したＤＭサーバのブロック図を示す。図２のメッセージ・フロー・シーケンスに用いるのに適したワークフロー・マネージャのブロック図を示す。本発明の教示の一側面による、装置管理通知メッセージが有するＨＴＴＰメッセージの非限定的な例としての構造を示す。図６のＨＴＴＰ応答メッセージが有する装置管理通知メッセージの非限定的な例としての構造を示す。