ユーザ装置をプロビジョニングするシステム及び方法
【課題】通信ネットワーク内で１つ以上のユーザ装置を接続するための複数のエントリーポイントを与えるシステム及び方法を提供する。
【解決手段】本発明の方法は、１つ以上のユーザ装置と通信するサーバーを用意するステップであって、サーバーが接続データセットを含み、且つ１つ以上のユーザ装置が接続データセットの部分を共有するようにしたステップと、複数のエントリーポイントの１つから接続データセットにアクセスする要求をユーザ装置から受け取るステップと、ユーザ装置の属性を自動的に決定するステップと、ユーザ装置の属性を使用して所定のクライアント装置のデータベースから通信メソッドを選択するステップと、この通信メソッドに基づいてユーザ装置をプロビジョニングするステップと、を備えている。
【解決手段】本発明の方法は、１つ以上のユーザ装置と通信するサーバーを用意するステップであって、サーバーが接続データセットを含み、且つ１つ以上のユーザ装置が接続データセットの部分を共有するようにしたステップと、複数のエントリーポイントの１つから接続データセットにアクセスする要求をユーザ装置から受け取るステップと、ユーザ装置の属性を自動的に決定するステップと、ユーザ装置の属性を使用して所定のクライアント装置のデータベースから通信メソッドを選択するステップと、この通信メソッドに基づいてユーザ装置をプロビジョニングするステップと、を備えている。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、通信ネットワークにおいて１つ以上のユーザ装置にサービスを提供するための分野に係る。より詳細には、本発明は、ユーザ装置をプロビジョニングするためのシステム及び方法に係る。
【０００２】
関連出願へのクロスリファレンス：本願は、次の特許出願に関連している。Matthias Breuer氏等の“System and Method for Servicing a User Device”と題する米国特許出願第１１／１８２，３４８号（代理人整理番号３２４２１−２００１７００号）；Torsten Schulz氏等の“System and Method for Synchronizing between a User Divice and a Server in a Communication Network”と題する米国特許出願第１１／１８２，２０３号（代理人整理番号３２４２１−２００１８００号）；Venkatachary Srinivasan氏等の“An Alert Mechanism for Notifying Multiple User Devices Sharing a Connected-Data-Set”と題する米国特許出願第１１／１８３，１３７号（代理人整理番号３２４２１−２００２２００号）；Marco Boerris氏等の“Methods and Systems for Data Transfer and Notification Mechanisms”と題する米国特許出願第１１／１８２，６１４号（代理人整理番号３２４２１−２００２１．００号）；及びTorsten Schulz氏等の“Content Router”と題する米国特許出願第１１／１８２，２８７号（代理人整理番号３２４２１−２０００９００号）。これらは、参考としてここに全体を援用するものである。
【背景技術】
【０００３】
通信、情報管理及び再生成のための電子装置の近年の急増で、デスクに縛られたパーソナルコンピュータとはかけ離れた日常の計算力が得られるようになった。ユーザは、セルラー電話、カメラ電話、パーソナルデジタルアシスタント（ＰＤＡ）及びナビゲーションシステムのような装置を、オフィスや家庭だけではなく、田畑や道路でも使用している。このような装置には、通信、ビジネス、ナビゲーション、娯楽、及び毎日の基本的活動の管理を含む様々な範囲の用途が考えられる。多くのユーザは、今日、１つのタスクに１つの装置を使用するだけであり、例えば、セルラー電話を使用して電話コールを発信し受信する。しかしながら、これら装置は、もはや、単一機能の装置ではない。それらは、種々の形式のデータ、例えば、電子メール、音声メッセージ、写真、ビデオ、等を生成することができる。装置の機能数が増すにつれて、ユーザに対する個人化のレベルも高くなる。ユーザがどこにいようと、どんな装置を使用しようと、又、どんなサービスに接続しようと、それらのデータに接続しアクセスするための接続サービスをユーザに提供することが要望される。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
このような接続サービスをユーザに提供する課題の１つは、ユーザが移動装置を購入した後にその製品をプロビジョニングする必要性である。慣習的に、ユーザは、パーソナルコンピュータに接続されたクレードルを通して装置をプロビジョニングしなければならない。これは、通常、家庭やオフィスで行なわれる。プロビジョニング段階が終了するまで、ユーザは、移動装置を使用することができない。それ故、いつでもどこでも移動装置をプロビジョニングすることが要望される。
【０００５】
このような接続サービスをユーザに提供する別の課題は、ユーザが既に自分のＰＣ、ＰＤＡ、セルラー電話、又は他の装置に確立している設定及びデータのセットに１つ以上のユーザ装置を接続する必要性である。例えば、ユーザは、新たな装置を取得したときに、設定及びデータのセットを既存の装置から新たな装置へコピーする必要がある。又、ユーザは、既存の装置を修理し、又は設定及びデータのセットを置き換える必要もある。又、ユーザは、ユーザ装置を紛失したり、盗難にあったり又は一時的に置き忘れたりした場合に、ユーザ装置のサービスを終了させる必要もある。
【０００６】
このような接続サービスをユーザに提供する更に別の課題は、設定及びデータの共通セットを共有する１つ以上のユーザ装置に対する通信の状態をユーザに通知する必要性である。例えば、１つ以上のユーザ装置においてｅメール、タスク、カレンダー事象又はアドレスブックエントリーの記憶装置にオーバーフロー状態が生じたときにユーザに通知する必要がある。
【０００７】
このような接続サービスをユーザに提供する更に別の課題は、設定及びデータの共通セットを共有するサーバー及び１つ以上のユーザ装置間でデータの一貫性を維持する必要性である。例えば、サービスがサーバーにおいて、ある時間周期中、中断されたときには、サーバー及び１つ以上のユーザ装置間でデータの変更を同期させる必要がある。
【課題を解決するための手段】
【０００８】
一実施形態において、通信ネットワーク内で１つ以上のユーザ装置を接続するための複数のエントリーポイントを与えるシステムは、１つ以上のユーザ装置と通信するサーバーであって、このサーバーが接続データセットを含み、且つ１つ以上のユーザ装置が接続データセットの一部分を共有するようにしたサーバーを備えている。このシステムは、更に、複数のエントリーポイントの１つから接続データセットにアクセスする要求をユーザ装置から受け取るためのロジックと、ユーザ装置の属性を自動的に決定するためのロジックと、ユーザ装置の属性を使用して所定のクライアント装置のデータベースから通信メソッドを選択するためのロジックと、その通信メソッドに基づいてユーザ装置をプロビジョニングするためのロジックとを備えている。
【０００９】
別の実施形態において、通信ネットワーク内で１つ以上のユーザ装置を接続するための複数のエントリーポイントを与える方法は、１つ以上のユーザ装置と通信するサーバーを用意するステップであって、このサーバーが接続データセットを含み、且つ１つ以上のユーザ装置が接続データセットの一部分を共有するようにしたステップと、複数のエントリーポイントの１つから接続データセットにアクセスする要求をユーザ装置から受け取るステップと、ユーザ装置の属性を自動的に決定するステップと、ユーザ装置の属性を使用して所定のクライアント装置のデータベースから通信メソッドを選択するステップと、その通信メソッドに基づいてユーザ装置をプロビジョニングするステップとを備えている。
【００１０】
本発明の前記特徴及び効果、並びにその付加的な特徴及び効果は、添付図面を参照した本発明の実施形態の以下の詳細な説明読んだ後に更に明確に理解されよう。
【図面の簡単な説明】
【００１１】
【図１ａ】本発明の一実施形態による接続寿命サービスを示す図である。
【図１ｂ】本発明の一実施形態による図１ａの接続寿命サービスをサポートする接続寿命サーバーを示す図である。
【図２】本発明の一実施形態による接続寿命サーバーの装置マネージャーの実施例を示す図である。
【図３】本発明の一実施形態により未構成のアカウントグループをプロビジョニングするためのワークフローを示す図である。
【図４】本発明の一実施形態により前構成されたアカウントグループをプロビジョニングするためのワークフローを示す図である。
【図５】本発明の一実施形態により「マイクロソフトアウトルック」をプロビジョニングするワークフローを示す図である。
【図６】本発明の一実施形態により前インストールされたローダーを経て装置をプロビジョニングするワークフローを示す図である。
【図７】本発明の一実施形態によりウェブサイトを経て装置をプロビジョニングするワークフローを示す図である。
【図８】本発明の一実施形態により検証された電話番号でウェブサイトを経て装置をプロビジョニングするワークフローを示す図である。
【図９】本発明の一実施形態により検証された電話番号なしにウェブサイトを経て装置をプロビジョニングするワークフローを示す図である。
【図１０】本発明の一実施形態によりＡｃｔｉｖｅＸ装置に対してウェブサイトを経て装置をプロビジョニングするワークフローを示す図である。
【図１１】本発明の一実施形態によりクライアントソフトウェアを使用してウェブサイトを経て装置をプロビジョニングするワークフローを示す図である。
【図１２】本発明の一実施形態により装置の既存の同期スタックを使用してウェブサイトを経て装置をプロビジョニングするワークフローを示す図である。
【図１３】本発明の一実施形態によりＳＭＳを経て装置をプロビジョニングするワークフローを示す図である。
【図１４】本発明の一実施形態によりオンラインショップを経て装置をプロビジョニングするワークフローを示す図である。
【図１５】ＲＥｘプロトコルフローの概要を示す図である。
【図１６】異なるＲＥｘメソッドを使用してユーザ装置とサーバーとの間の対話を示すフローチャートである。
【図１７】本発明の一実施形態による問合せプロセスのシーケンス図である。
【図１８】本発明の一実施形態によりクライアント装置とサーバーとの間で同期をとるための同期アンカープロトコルを示す図である。
【図１９】本発明の一実施形態により装置が装置タイプ識別設定を交換するときのプロセスフロー図である。
【図２０】本発明の一実施形態によりゾンビ状態において装置タイプ識別以外の設定を装置が交換しようと試みるときのプロセスフロー図である。
【図２１】本発明の一実施形態による通常の設定交換のためのシーケンス図である。
【図２２】本発明の一実施形態によるダンプ設定のためのシーケンス図である。
【図２３】本発明の一実施形態による装置とサーバーとの間のアプリケーション交換プロセスフローを示すシーケンス図である。
【図２４】本発明の一実施形態によるアプリケーション交換状態遷移図である。
【発明を実施するための形態】
【００１２】
ユーザ装置をプロビジョニングするための方法及びシステムが提供される。以下の説明は、当業者が本発明を実施し利用できるようにするためのものである。特定の実施形態及び応用は、一例に過ぎない。当業者であれば、ここに述べる実施例の種々の変更及び組み合せが容易に明らかであり、又、ここに述べる一般的な原理は、本発明の精神及び範囲から逸脱せずに、他の実施例及び応用に適用することができよう。従って、本発明は、ここに図示して説明する実施例に限定されず、ここに開示する原理及び特徴との最も広い一貫性が与えられるべきである。
【００１３】
以下の詳細な説明の幾つかの部分は、コンピュータメモリ上で遂行できるデータビットに対するオペレーションの手順、ステップ、論理ブロック、処理、及び他の象徴的表現に関して表わされる。手順、コンピュータ実行ステップ、論理ブロック、プロセス、等は、ここでは、希望の結果を導くステップ又はインストラクションの自己一貫性シーケンスであると考えられる。ステップは、物理量の物理的操作を利用するものである。これらの量は、コンピュータシステムにおいて記憶、転送、合成、比較、その他、操作することのできる電気、磁気又は無線信号の形態をとることができる。これら信号は、しばしば、ビット、値、エレメント、記号、キャラクタ、項、数字、等と称される。各ステップは、ハードウェア、ソフトウェア、ファームウェア、又はその組み合せによって遂行することができる。
【００１４】
図１ａは、本発明の一実施形態による接続寿命サービス(connected-life service)を示す。この接続寿命サービスは、ユーザがそれらの接続データセット(connected-data-set)を任意の装置と共有していつどこからでもアクセスできるようにする。ユーザ装置（装置又はクライアントとも称される）は、セルラー電話、ワイヤレスパーソナルデジタルアシスタント、ナビゲーション装置、パーソナルコンピュータ、ゲームコンソール、インターネットターミナル、及びキオスクを含む。接続データセットは、ｅメール、連絡先、カレンダー、タスク、ノート、ピクチャー、ドキュメント、音楽、ビデオ、ブックマーク及びリンクを含む。
【００１５】
異なる実施形態において、接続寿命サービスは、次の機能を提供する。１）ユーザ装置を修理し、２）第１ユーザ装置を第２ユーザ装置へ複写し、３）第１ユーザ装置を第２ユーザ装置に置き換え、及び４）ユーザ装置のサービスを終了する。ユーザ装置を修理するサービスは、１つ以上のユーザ装置の状態をリセットし、１つ以上のユーザ装置の構成及び設定を回復し、そして接続データセットを１つ以上のユーザ装置へ回復させることを含む。
【００１６】
第１ユーザ装置を第２ユーザ装置へ複写するサービスは、第１ユーザ装置の構成及び設定を第２ユーザ装置へ転送し、そして接続データセットの一部分を第１ユーザ装置の設定に基づいて第２ユーザ装置へ転送することを含む。
【００１７】
第１ユーザ装置を第２ユーザ装置と置き換えるサービスは、所定の構成及び設定のセットを構成データベースから第２ユーザ装置へ転送し、ここで、第２ユーザ装置は、第１装置と同じモデル、メーク及びタイプを有するものであり、そして接続データセットの部分を第２ユーザ装置の設定に基づいて第２ユーザ装置へ転送することを含む。第１ユーザ装置を第２ユーザ装置と置き換えるサービスは、更に、所定の構成及び設定のセットを構成データベースから第２ユーザ装置へ転送し、ここで、第２ユーザ装置は、第１装置と異なるモデル、メーク及びタイプを有するものであり、そして接続データセットの部分を第２ユーザ装置の設定に基づいて第２ユーザ装置へ転送することを含む。
【００１８】
ユーザ装置のサービスを終了させるサービスは、ユーザ装置の構成及び設定を削除し、ユーザ装置への通信を終了し、そして他のユーザ装置へ終了状態を送信することを含む。装置の終了サービスは、装置からサービスを取り除くために適用されるだけでなく、「装置紛失」又は「装置盗難」の場合にも利用できることに注意されたい。このような場合には、ソフトウェア及び設定だけでなく、ユーザデータ（メール、アタッチメント、ＰＩＭ、写真、等）も、取り除くことができる。
【００１９】
更に、装置終了サービスの別の特徴は、装置の阻止である。この場合、ユーザは、装置を見つけられないが、装置を見つける機会がまだあると仮定すれば、それを紛失したか、単にどこかに置き忘れたか確実に分らない。この場合、このサービスは、ユーザから更に命令があるまで装置を阻止するか又は少なくとも装置へのデータサービスを一時的に阻止する能力をユーザに提供する。
【００２０】
図１ｂは、本発明の一実施形態による図１ａの接続寿命サービスをサポートする接続寿命サーバーを示す。接続寿命サーバー１００は、異なる地理的位置にある１つ以上のコンピュータ／サーバーにより実施される。接続寿命サーバーは、ユーザがデータを生成し又は記憶する異なるコンピューティング装置（パーソナルコンピュータ１０２及び１０４、移動装置１０６、サーバー１０８、並びにウェブポータル１１０及び１１２を含む）の間で接続データセットを管理する。
【００２１】
図２は、本発明の一実施形態による接続寿命サーバーの装置マネージャーの実施例を示す。装置マネージャー２００は、ウェブフロントエンド２０２と、装置コントローラ２０４と、装置記述記憶装置２０６と、１セットのプロトコルアダプタ２０８とを備えている。装置マネージャーは、プロトコルアダプタ２０８を通してユーザ装置２１０と通信し、それを管理する。更に、装置マネージャーは、ユーザマネージメントユニット２１２及びスマートコンテンツルーティングユニット２１４を通して接続寿命サーバーの他の部分と通信する。ユーザマネージメントユニットは、異なるサービスからユーザ装置を管理するのに使用されることに注意されたい。このユニットは、全てのユーザが、ＳＢＣ−Ｙａｈｏｏ ＤＳＬサービスのような同じインターネットサービスプロバイダーからのものである場合には、任意である。
【００２２】
装置コントローラ２０４は、更に、ソフトウェアマネージメントユニット２１６、サービスマネージャー２１８、設定変更ディスパッチャー２２０、及び装置状態記憶装置２２２を備えている。ソフトウェアマネージメントユニット２１６は、ユーザ装置に対するレコード、設定及びアプリケーションをインストールし、更新し、そしてデインストールする。サービスマネージャー２１８は、ユーザ装置に対してサポートされるサービスのタイプを管理する。サービスマネージャーは、ユーザ装置及び接続寿命サーバーの間で接続データセットを転送するためにスマートコンテンツルーティングユニット２１４へ情報を与える。設定変更ディスパッチャー２２０は、装置設定の変更を装置マネージャーからユーザ装置へ与える。装置状態記憶装置２２２は、ユーザ装置のオペレーティング状態に関する情報を記憶する。
【００２３】
装置記述記憶装置２０６は、接続寿命サービスによりサポートされるユーザ装置２１０のタイプ記述２２４、トランスコーディング２２６、アカウントテンプレート２２８、及びサービス記述２３０を記憶する。装置マネージャーは、このような装置情報を装置記述記憶装置２０６とファイルサーバー２３０との間で転送する。装置マネージャーは、ユーザ装置を、タイプ記述、トランスコーディング、アカウントテンプレート、及びサービス記述の異なる組み合せに関連付けて、ユーザ装置の所定のグループに対して各組み合せをテストし検証できるようにする。その結果、異なるサービスラインがそれに対応する装置特徴を含み、そしてサービスを、異なるユーザグループに提供することができる。
【００２４】
プロトコルアダプタ２０８は、プロビジョニングユニット２３２、レコード交換ユニット２３４、設定交換ユニット２３６、アプリケーション交換ユニット２３８、ＳｙｎｃＭＬユニット２４０、及び他のアダプタユニット２４２を備えている。上述した機能的ユニット（即ち、論理的ブロック２００−２４４）は、ソフトウェア、ハードウェア、或いはソフトウェアとハードウェアの組み合せで実施できることに注意されたい。機能的ユニット間の相互作用については、次の章で詳細に述べる。
【００２５】
ユーザ装置のプロビジョニング
一般的に、消費者が接続寿命サービスに契約できる方法は２つある。１）アカウントを登録し、その後、装置のプロビジョニングを行なう。２）装置を登録し、従って、接続寿命サービスアカウントの登録が手順に含まれる（まだアクティブでない場合）。
【００２６】
２つの選択肢のうち、ユーザが接続寿命サービスに契約したときには、最初に、アカウントを登録する。接続寿命サービスは、顧客のアカウントを維持するサービスプロバイダーを通して提供される。これは、ｅメールアカウント、ＰＩＭ記憶及び管理ファシリティ、並びに「ブリーフケース」機能、即ち写真や音楽やドキュメントや他のデータのようなユーザの他のファイルの記憶、を含むが、これらに限定されない。
【００２７】
ユーザは、接続寿命サービスにより提供されるサービスについて登録するときに、それらを提供するサービスプロバイダーの既に登録された顧客としてこれを行なう。従って、接続寿命サービスの利用に対して可能となるアカウントを既に有する。アカウントのプロビジョニングの実施については、以下で述べる。次の章が含まれる。
−アカウントグループ
この章は、異なるアカウントグループ又はアカウントタイプについて述べる。異なるアカウントプロビジョニング利用ケースを理解するためには、このグループを知る必要がある。
−利用ケース
３つのアカウントプロビジョニング利用ケースがある。その各々を次の章で述べる。
【００２８】
又、ユーザは、最初にそれらの装置を登録することによりアカウントを登録するオプションを有する。ここでは、装置プロビジョニングプロセスの一部分として、アカウントが自動的に生成される。
【００２９】
アカウントグループ
ユーザアカウントは、グループ編成することができる。各アカウントグループは、２つ以上の方法を使用してプロビジョニングすることができる。テーブル１は、接続寿命サービスによりサポートされるサンプルアカウントグループを示す。
テーブル１
【００３０】
利用ケース
アカウントグループは、接続寿命サービスに対して３つの異なる仕方でプロビジョニングすることができる。これらの利用ケースは、次の章で説明する。
１）未構成のアカウントグループをプロビジョニングする
ここでは、ユーザが登録するアカウントの詳細は、そのほとんどの部分について、接続寿命サーバー（ＣＬＳ）には分らない。それ故、ユーザは、これらの詳細を手動で入力し、従って、経験のあるユーザについてのみ意図される。
２）前構成されたアカウントグループをプロビジョニングする
アカウントグループの技術的仕様がＣＬＳに予め分るときには、アカウントのプロビジョニングは、最小限のユーザ努力しか必要としない容易な形態で行うことができる。
３）マイクロソフトアウトルックをプロビジョニングする
自分のＰＣに位置されたアカウントをもつことを希望するユーザについては、マイクロソフトアウトルックアプリケーションを使用する。
【００３１】
未構成のアカウントグループをプロビジョニングするための必須条件は、ユーザがアウトルックリディレクタ以外のアカウントグループからのアカウントを既に有していることである。適用可能なアカウントグループは、交換、ＷｅｂＤＡＶ、ＩＭＡＰ及びＰＯＰ３である。この利用ケースにおいて、ユーザは、アカウント／データソースを登録するために、ＣＬＳにより要求される全ての情報を特定する。これは、アカウントユーザ名及びパスワードのような通常のパラメータと、サーバーの名前及びそれらの各々のポート番号とを含む。
【００３２】
これは、全部で３つの利用ケースの中で最も複雑であり、それ故、経験のあるユーザにしか推奨されない。これは、サービスプロバイダーがこれらデータソースパラメータを知らないとき、例えば、サービスプロバイダー以外のデータソースに接続することをユーザに提示する場合だけ、実施される。
【００３３】
図３は、本発明の一実施形態により未構成のアカウントグループをプロビジョニングするためのワークフローを示す。ユーザは、１）サービスプロバイダーのウェブサイトにログオンし、２）適当なアカウントグループを選択し、３）アカウントのための全ての必要なパラメータを入力する。これらのステップが完了すると、ＣＬＳは、アカウントを生成する。
【００３４】
図４は、本発明の一実施形態により前構成されたアカウントグループをプロビジョニングするためのワークフローを示す。前構成されたアカウントグループをプロビジョニングするための必須条件は、ユーザがアウトルックリディレクタ以外のアカウントグループからのアカウントを既に有していることである。適用可能なアカウントグループは、サービスプロバイダーにより提供されるものである。この利用ケースは、ユーザが登録を選択する前にアカウント仕様のほとんどを知ることに基づく。第１の利用ケースとは対照的に、これは、前構成されたアカウントグループのプロビジョニングを含む。即ち、アカウントの仕様のほとんどが接続寿命サーバーに既に知られており、ユーザは、アカウントを登録するためにサービスプロバイダーに対する証明書を単に入力するだけである。サーバー名、ポート番号、等の仕様は、タイプインする必要がない。
【００３５】
これは、アカウントをプロビジョニングする簡単な仕方である。ユーザは、「はい、このサービスへの契約を希望します」と簡単に答えるだけでよく、その他は、接続寿命サービスにより取り扱われる。ユーザは、それらのサービスプロバイダーでログオンした後、接続寿命サービスに登録したいアカウントを選択する。
【００３６】
図５は、本発明の一実施形態により「マイクロソフトアウトルック」をプロビジョニングするワークフローを示す。マイクロソフトアウトルックをプロビジョニングするための必須条件は、ユーザが自分のＰＣにマイクロソフトアウトルックをインストールすることである。適用可能なアカウントグループは、アウトルックリディレクタである。
【００３７】
このオプションでは、ユーザは、自分のパーソナルコンピュータにデータソースとしてマイクロソフトアウトルックアプリケーションをもつよう選択できる。アカウントがサービスプロバイダーのサーバーに位置された利用ケースＩ及びIIとは対照的に、マイクロソフトアウトルックアカウントのプロビジョニングは、それがユーザ自身のＰＣにローカル配置されることを意味する。
【００３８】
この方法を使用して、ユーザは、それらの交換、ＩＭＡＰ、又はＰＯＰアカウントを、接続寿命サービスアカウントとして依然もつことができるが、ＣＬＳは、マイクロソフトアウトルックに接続され、プロバイダーサーバー（１つ又は複数）には接続されない。これは、アウトルックの“．ｐｓｔ”ファイルのローカル記憶データに接続されるか、或いは交換アカウントに接続するのにアウトルックが使用される場合には、交換プロフィールに接続され、そしてそれを通して、交換サーバーに接続される。後者のシナリオは、ＣＬＳと交換サーバーとの間のファイアウオールの問題を克服するのに使用できる。
【００３９】
マイクロソフトアウトルックのプロビジョニングは、ユーザのＰＣにアウトルックリディレクタをインストールすることを意味する。リディレクタは、アウトルックの“．ｐｓｔ”ファイル／交換プロフィールと、接続寿命サーバーとの間の仲介手段として働く。アウトルックは、アカウントからデータが供給される装置としてプロビジョニングできることにも注意されたい。装置をどのようにプロビジョニングするかの詳細は、以下の章で述べる。
【００４０】
図５は、本発明の一実施形態によりアウトルックをデータソースとして登録するためのワークフローを示す。アウトルックをデータソースとして登録するためのワークフローは、次の通りである。
１．ユーザは、サービスプロバイダーのウェブサイトにログオンする。
２．ユーザは、アウトルックリディレクタアカウントグループを選択する。
３．ローダーがＰＣにインストールされる。
４．ユーザは、ＰＣに対するユーザ名及びパスワードを入力する。
５．アカウントがアクチベートされ、そしてクライアントソフトウェアがインストールされる。
【００４１】
ユーザは、それらのアカウントの登録を完了した後に装置をプロビジョニングすることができる。或いは又、接続寿命サービスは、それらの装置及びアカウントを同時に登録する（ユーザの観点から）可能性をユーザに与える。その目的は、プロビジョニングプロセスをできるだけ容易に且つ簡単にすることである。プロビジョニングの終りに、ユーザは、アカウントのデータがそれらの装置に接続された状態で去る。装置プロビジョニングプロセスには少なくとも４つのエントリーポイントがある。
１．ユーザは、ローダーソフトウェアを受け取る。
２．ユーザは、ウェブサイトを経てエントリーする。ユーザがサービスプロバイダーのウェブサイトにログオンするか、或いはセールスアシスタント又は顧客サービス代表者（ＣＳＲ）がユーザに代わってユーザを登録する（電話により店に）。
３．ユーザは、サービスプロバイダーにより指定された番号へＳＭＳを送信する。
４．ユーザは、プロバイダーのオンラインショップにログオンする。
【００４２】
更に、ユーザは、装置がそのデータの全部又は一部分を失うか、又はユーザが装置を紛失し、同じタイプの別の装置と交換する場合には、それらの装置を回復させるよう選択することができる。これらのシナリオは、全て、顧客が、接続寿命サービスを提供するサービスプロバイダーに既に登録されたユーザであると仮定している。又、ユーザが接続寿命サービスにまだ登録していない場合には、前構成されたアカウントグループをプロビジョニングするための利用ケースIIに基づいて登録される。
【００４３】
図６は、本発明の一実施形態により前インストールされたローダーを経て装置をプロビジョニングするワークフローを示す。ユーザが接続寿命サービスに対して自分の装置を登録する１つの仕方は、自分の装置にローダーアプリケーションをインストールすることによるものである。ローダーは、装置のプロビジョニング及びクライアントソフトウェアのインストールを容易にするアプリケーションである。
【００４４】
ローダーは、種々の仕方、即ちダウンロード、ＣＤ−ＲＯＭ、ＳＤ又は他のメモリカードを経て、或いはローダーを装置に送信する他の方法で、ユーザに利用できるようにされる。ローダーは、特定の装置タイプに対して表示される（バージョン番号で）。従って、装置が登録のためにＣＬＳに接続されるときには、サーバーは、装置のタイプや、クライアントソフトウェアをインストールする必要があるかどうかが自動的に分る。予めインストールされたローダーを経て装置をプロビジョニングするためのステップは、次の通りである。
１．ローダーが装置においてスタートする。
２．ローダーがサービスプロバイダーログオンスクリーンを表示する。
３．ユーザは、それらのアカウントのユーザ名、パスワード、及びそれらの装置の名前（例えば、Ｍｙ Ｐｈｏｎｅ）を入力する。
４．ユーザがまだサービスプロバイダーの顧客ではない場合には、プロバイダーに連絡するようユーザに求めるメッセージが表示される。
５．ユーザがまだ接続寿命サービスに契約しない場合には、それらのアカウントが自動的にアクチベートされる。
６．ユーザがそれらのアカウント証明書を与えると、ローダーは、予め決定されたサービス（交換されるデータタイプのような）及びデフォールトフィルタで構成されたクライアントソフトウェアをダウンロードする。ダウンロードは、オーバー・ジ・エア(over-the-air)でもよいし、ＰＣ接続によるものでもよいし、或いは単にローカルメモリカードから転送されてもよい。
７．ＣＬＳが装置においてサービスをアクチベートする。装置から既存のデータをインポートし（デフォールトオペレーション）、そして装置をアカウントへ接続する。アカウントにおけるレコードに必要な複写処理を遂行した後に、そこから装置へレコードを送信する。
これで、装置は、プロビジョニングされ、データを交換する準備ができる。
【００４５】
図７は、本発明の一実施形態によりウェブサイトを経て装置をプロビジョニングするワークフローを示す。このシナリオでは、ユーザは、ウェブブラウザを使用して、接続寿命サービスに対してそれらの装置を登録する。これは、次のいずれかである。
−顧客に利用可能なサービスプロバイダーのウェブサイトを経て直接的に。ユーザは、ログインする。
−ＣＳＲを経て。典型的なシナリオは、ユーザがサービス／セールスホットラインにコールし、又はユーザがサービスプロバイダーの店の１つを訪問することを含み、ここで、セールスアシスタントが顧客に代わって顧客を登録するように進行する。
【００４６】
ウェブブラウザを使用して装置をプロビジョニングする段階は、次の２つがある。１）装置を前プロビジョニングし、２）装置をプロビジョニングする。プロビジョニングプロセスを開始する前に、ＣＬＳは、どんな種類の装置がプロビジョニングされ、そしてそれが現在どのように（ＰＣを経て、ワイヤレスで）接続されるか決定する。又、プロビジョニングが新しいものであるかどうか、又はユーザが装置の回復を希望するかどうかも分る。装置の回復が必要であるのは、それを紛失し新しいものに置き換えるとき、ハードリセットされてそのプログラム及びデータを失ったとき、又は別の仕方でデータを失ったときである。
【００４７】
装置がＣＬＳとで交換するタイプのデータを失った場合も、装置が以前の構成へバックアップされた場合も、装置の回復は必要でない。前者のケースでは、通常のデータ交換が行なわれ、失われたデータは、アカウントから検索される。後者のケースでは、装置をアカウントの現在状態へ戻すために低速同期が開始される。換言すれば、クライアントソフトウェアが削除された場合には、復帰が要求される。サーバーは、当該装置から全てのデータを要求し、全てのレコードをインベントリと比較して不一致を識別し、インベントリからのレコードで装置を更新する。装置の復帰は、プッシュ装置には適用されないことに注意されたい。
【００４８】
サーバーがユーザ装置と同期せず且つサーバー側インベントリのバックアップが回復された場合には、サーバー側インベントリのバックアップが行われるたびに装置にチェックポイントマーカー（例えば、タイムスタンプ）を保持することにより低速同期プロセスを最適化することができる。これは、サーバーが、チェックポイントマーカーの後に変化したレコードを比較するだけでよくする。この方法は、ユーザ装置へ転送する必要のあるデータの量を減少させる。従って、低速同期プロセスの時間巾を短縮し且つその送信帯域巾の使用を軽減する。
【００４９】
プロビジョニングプロセスそれ自体は、登録される装置のタイプに依存する。この点に関して、これは、次の５つのカテゴリーに入る。
１．検証された電話番号をもつプッシュ装置
２．検証された電話番号をもたないプッシュ装置
３．ＡｃｔｉｖｅＸ−イネーブル装置
４．クライアントソフトウェアを使用する装置
５．自身の同期スタックを使用する装置
これらのプロセスは、以下の章で詳細に説明する。
【００５０】
ウェブサイトを経て装置を前プロビジョニングするステップは、次の通りである。
１．ユーザがウェブサイトを通してそれらの装置のプロビジョニングをスタートできる仕方は、多数ある。ユーザは、サービスプロバイダーのコールセンターをコールするか、それらの店の１つを訪問するか、又はそれらのウェブサイトを直接的にブラウズすることができる。全てのケースにおいて、プロビジョニングは、ウェブを経て遂行される。
２．ユーザがローダーをインストールする第１の利用ケースと同様に、ユーザがまだ接続寿命サービスアカウントを有していない場合には、これが自動的に生成される。
３．装置が回復される（例えば、ハードリセットにより）場合には、装置は、装置カテゴリーに基づいてプロビジョニングされる。
４．前プロビジョニングプロセスの残り部分は、装置がＣＬＳによりどのように検出されるかに依存し、これは、装置が現在どのように接続されるかに多くの仕方で関係している。図７は、次の３つの可能性を示している。
ａ．ユーザが装置を使用してブラウジングする
このケースでは、ＣＬＳは、装置のタイプを検出し、そしてユーザをローダーダウンロードページへ向けることができる。次いで、ローダーは、ユーザによりスタートされ、プロビジョニングプロセスが、図４に示すように続けられる。
ｂ．装置のタイプがＰＣ接続を経て検出される（又は装置がＰＣである）
ここでは、装置がＰＣに接続されるか、又はプロビジョニングされている装置がＰＣそれ自体である。アドミニストレーションアプリケーションは、ＡｃｔｉｖｅＸ制御を使用して、この接続を経て装置のタイプを検出することができる。ＰＣを経て接続された装置については、それを経てプロビジョニングが行なわれる。
ｉ．アカウント、サービス及びフィルタが構成される（ユーザにより一部分行なわれるか又は完全自動である）。
ii．サービスプロバイダーがキャリアでない場合には、装置の電話番号が入力される。プロバイダー及びキャリアが同じである場合には、番号が既に知られている。
ｃ．ユーザがメニューから装置のタイプを手動で選択する
装置は、ワイヤレスで接続されるか、又はＰＣに接続された場合は、何らかの理由でそれを検出できないと仮定する。プロビジョニングプロセスは、空中を経て行うこともできるし、装置のメモリカードを経て行うこともできるし、或いは他の方法を介して行うこともできる。
装置は自動的に検出できないので、ユーザは、装置のタイプをリストから手動で選択する。これが行なわれると、アカウント、サービス及びフィルタの前構成が行われ（前記４．ｂ．ｉを参照）、そしてそこからプロセスが続く。
５．これで、前プロビジョニングプロセスが完了となる。次いで、プロビジョニングそれ自体が装置のタイプに基づいて開始され、これは、次の章で説明する。
【００５１】
別の例では、前プロビジョニングを使用して装置を回復させる。接続寿命サービスは、次の場合に装置を回復させる可能性を与える。
−装置が同じタイプの別のものに置き換えられる（盗み、ダメージ、等により）
−装置がリセットされるか、又は何らかの他の仕方で、その接続寿命サービス構成を失った。
【００５２】
これらのケースでは、装置（又は交換装置）を回復させることができる。前プロビジョニングプロセスは、ユーザ、装置及びその以前の構成がサーバーに既に知られている状態で、ステップを経て勧められる。プロビジョニングプロセスは、装置のカテゴリーに基づいて開始することができる。
【００５３】
図８は、本発明の一実施形態により検証された電話番号でウェブサイトを経て装置をプロビジョニングするワークフローを示す。ここに述べ且つ次の章でも述べるワークフロー「ワークフロー−検証された電話番号をもたないプッシュ装置」は、いわゆる「プッシュ」装置、換言すれば、ＭＭＳ装置、に適用される。これは、データ交換の最も基本的なレベルを与え、一方向性である。本質的に、データは、ＣＬＳにより装置へプッシュされる。データは、ユーザにより装置において変更されるように意図されておらず、変更してもＣＬＳには返送されない。ｅメールは、装置にプッシュされる１つのデータタイプの例である。
【００５４】
これらの装置は、接続寿命サービスに使用するためにインストールされるべきソフトウェアを必要としない。図ＤＰ６に示されたプロビジョニングプロセスでは、前プロビジョニングプロセスが完了すると、装置の対するサービスをアクチベートし、それにデータを送信するだけである。この利用ケースでは、装置の電話番号は、ＣＬＳにより既に検証されている。電話番号の検証は、データが正しい装置に送られるよう確保するために、セキュリティの理由で行なわれる。
【００５５】
図９は、本発明の一実施形態により検証された電話番号なしにウェブサイトを経て装置をプロビジョニングするワークフローを示す。この利用ケースでは、装置は、プッシュ装置（上述したような）であるが、その電話番号を、依然、検証できる。このプロセスは、そのプロビジョニングの主要部分を形成し、これが行なわれてそのサービスがアクチベートされると、装置の動作準備ができる。電話番号の検証プロセスは、次の通りである。
１．ユーザは、電話番号を入力し、ＯＫをクリックして、ＳＭＳをそこに送る。
２．ＳＭＳが装置へ送信される。装置は、４桁の検証番号を表示する。
３．同時に、ブラウザは、ユーザがこの検証番号を入力するためにページをオープンする。
４．ユーザが検証番号を入力する。
５．確認されると、ＣＬＳは、装置に対するサービスをアクチベートするように進み、プロビジョニングプロセスが完了となる。
【００５６】
図１０は、本発明の一実施形態によりＡｃｔｉｖｅＸ装置に対してウェブサイトを経て装置をプロビジョニングするワークフローを示す。このプロビジョニングワークフローは、次の装置に適用される。
−ＡｃｔｉｖｅＸ−イネーブルウェブブラウザをもつＰＣ
−このようなＰＣに接続されたハンドヘルド装置
【００５７】
ローダーは、ＣＬＳが装置のタイプを検出しそしてクライアントソフトウェアをインストールできるようにするＡｃｔｉｖｅＸ制御を備えている。又、ＣＬＳで装置を認証し、クライアントソフトウェアのダウンロードを行えるようにする。
【００５８】
図１１は、本発明の一実施形態によりクライアントソフトウェアを使用してウェブサイトを経て装置をプロビジョニングするワークフローを示す。このワークフローは、クライアントソフトウェアのインストールを必要とする装置に適用される。その手順は、次の通りである。
１．ブラウザは、ローダーのＵＲＬと、ユーザに対する独特のＰＩＮとを表示する。更に、
ａ．ＣＳＲに対して、ブラウザは、使用可能な他のバイナリーのＵＲＬも表示する。
ｂ．開発者に対して、ブラウザは、ＣＬＳインストール及びローダーのＵＲＬ、並びにインストールする必要のない他のバイナリーのＵＲＬを入力するオプションを彼等に与える。
２．普通のユーザは、ローダーのインストールへまっすぐにジャンプする。
ａ．空気中を経てインストールされるべき場合には、ＣＬＳは、ローダーのためのＵＲＬを含む装置へ構成ＳＭＳを送信する。それをオープンすることで、ダウンロードがスタートする。
ｂ．装置がＰＣに接続されている場合には、ローダーは、自動的にダウンロードを行ってスタートする。
これらのステップは、両方とも、ユーザが既に表示されたＰＩＮを認証の目的で入力することを要求する。
３．ローダーは、それがスタートした後に、クライアントソフトウェアをダウンロードし、インストールし、そしてスタートさせる。
４．装置のサービスがアクチベートされ、データが装置からインポートされ（選択されていれば）、レコードの複写がＣＬＳにより取り扱われ、そしてアカウントからのレコードが装置へ送られる。これで、プロビジョニングプロセスが完了となる。
【００５９】
図１２は、本発明の一実施形態により装置の既存の同期スタックを使用してウェブサイトを経て装置をプロビジョニングするワークフローを示す。このワークフローは、それ自身の同期スタックを有する装置、例えば、ＳｙｎｃＭＬ装置に適用される。この場合に、クライアントソフトウェアをインストールする必要がない。ほとんどの装置のワークフローは、極めて簡単である。サーバー名、ポート番号、等々を指定する構成ＳＭＳが装置に送られるだけでよい。プロビジョニングは、実行されると、サービスをアクチベートし、データの交換をスタートさせることにより、通常の仕方で続けられる。
【００６０】
装置が付加的なソフトウェアのインストールを必要とする場合には、その後の手順は、図９に示されたローダーのインストールの場合と基本的に同じである。即ち、
１．ブラウザは、バイナリーのＵＲＬと、ユーザに対する独特のＰＩＮとを表示する。
更に、
ａ．ＣＳＲに対して、ブラウザは、使用可能な他のバイナリーのＵＲＬも表示する。
ｂ．開発者に対して、ブラウザは、ＣＬＳインストール及びローダーのＵＲＬ、並びにインストールする必要のない他のバイナリーのＵＲＬを入力するオプションを彼等に与える。
２．普通のユーザは、バイナリーのインストールへまっすぐにジャンプする。
ａ．空気中を経てインストールされるべき場合には、ＣＬＳは、バイナリーのためのＵＲＬを含む装置へ構成ＳＭＳを送信する。それをオープンすることで、ダウンロードがスタートする。
ｂ．装置がＰＣに接続されている場合には、バイナリーは、自動的にダウンロードを行ってスタートする。
これらのステップは、両方とも、ユーザが既に表示されたＰＩＮを認証の目的で入力することを要求する。
３．装置のサービスがアクチベートされ、データが装置からインポートされ（選択されていれば）、レコードの複写がＣＬＳにより取り扱われ、そしてアカウントからのレコードが装置へ送られる。これで、プロビジョニングプロセスが完了となる。
【００６１】
図１３は、本発明の一実施形態によりＳＭＳを経て装置をプロビジョニングするワークフローを示す。この利用ケースは、ユーザの経験に関して簡単なプロビジョニングプロセスを与える。ここでは、サービスプロバイダーは、特定の装置タイプに対して接続寿命サービスを提供し、そしてユーザが指定の番号へＳＭＳを単に送信するのを許し、その際に、それらのアカウントは、それがまだない場合には接続寿命使用に対してアクチベートされ、そして装置が自動的にプロビジョニングされ、最小限のユーザ相互作用しか必要としない。（特定の分岐のもとで）図１３に示されたこのワークフローは、プロビジョニングされる装置のタイプ（１つ又は複数）及びサービスプロバイダーの要求を満足するように調整されてもよい。或いは又、一般的な分岐のもとで示されるように、ＳＭＳを送信するときには、ＣＬＳは、「ウェブサイトを経て(Via Website)」の利用ケースで述べるように、ユーザがブラウズすべきＵＲＬを返送し、そして装置をプロビジョニングすることができる。
【００６２】
図１４は、本発明の一実施形態によりオンラインショップを経て装置をプロビジョニングするワークフローを示す。このプロビジョニングシナリオでは、装置は、接続寿命サービスに使用するための技術的な要件を既に満足している。ユーザは、サービスプロバイダーとのアカウントを有する（しかし、必ずしも、接続寿命サービスではない）。ユーザが行なうのは、プロバイダーのウェブサイトにログオンし、接続寿命サービスをアクチベートするのが全てである。プロビジョニングは、自動的に行なわれる。
【００６３】
レコード交換（ＲＥｘ）アプリケーションプログラムインターフェイス
レコード交換ＡＰＩは、ＳｙｎｃＭＬ（セッションベースの）プロトコルに使用される機能を発揮するように設計される。これを達成するために、必要なステップの数及びそれらステップの遂行に使用するコマンドが減少される。ＳｙｎｃＭＬモデルにおいて、プロセスの流れを以下に述べる。
−認証
−セッションをスタート
−同期セッションを初期化（データベースタイプごとに同期タイプをネゴシエーションする）
−クライアントがレコードをサーバーへ送信する（多数のメッセージを必要とすることがある）
−サーバーがクライアントのデータとそれ自身との間の同期を遂行する
−サーバーがクライアントのレコードを確認し、そしてクライアントへレコードを送信する（多数のメッセージを必要とすることがある）
−クライアントがサーバーのレコードを確認する
−セッションを終了する
【００６４】
上述したように、全セッションは、同期オペレーションを成功とみなすために首尾良く完了する。これは、主としてネットワークの接続性及び装置安定性の問題のために、全プロセスを、エラーの生じ易いものにする。
【００６５】
レコード交換ＡＰＩは、プロセスを、ほとんどの部分について互いに独立して遂行できる個別のオペレーションへと分割することにより、ＳｙｎｃＭＬ（セッションベースの）同期の完全性の問題に対処する。同期化の概念は、２つの構成部分、即ちクライアントの観点からアイテムをプット(putting)し及びゲット(getting)すること、に分割され、そして初期化の概念を、これらアクションのいずれかに結合することができる。従って、カスケード依存性を伴うプロセスにおいてアクションを使用するのではなく、レコード交換ＡＰＩを使用する典型的な同期は、次のように説明される。
−クライアントは、使用を希望するデータタイプを初期化し、アイテムを送信する。サーバーは、この要求に対して即座に応答を送信する。サーバーは、その応答において、クライアントに対して保留中のアイテムがあるかどうか指示することができる。このステップは、クライアントが必要と思われるほど何回も繰り返すことができる。
−クライアントは、使用を希望するデータタイプを初期化し、サーバーからアイテムを要求する。サーバーは、保留中のアイテムをクライアントに返送し、まだ保留があるかどうか指示する。クライアントは、このステップを繰り返し、確認情報を含ませることができる。
【００６６】
前記では２つのステップだけを示したが、レコード交換ＡＰＩは、これらステップの異なる部分を実行するための異なる機能も備えている。クライアント装置は、プット／ゲットプロセスを使用することもできるし、又は必要に応じて個別のｉｎｉｔ及び確認ステップを含む更に詳細なプロセスを使用することもできる。これらステップの各々を以下に詳細に説明する。
【００６７】
図１５は、ＲＥｘプロトコルフローの概要を示す図である。プロトコルの変更をサポートし、そしてより古い装置との後方互換性を与えるために、装置は、現在プロトコルバージョンをＵＲＬパラメータとして各要求と共に送信する。
【００６８】
レコードの交換
ＲＥｘ ＡＰＩにより交換される各アイテムがアドレスされる。これを達成するために、ＲＥｘ ＡＰＩは、アイテムに対する独特の参照を含む多数のコンポーネントを定義する。各状態に全てのコンポーネントが使用されるのではなく、所与のアイテムに対して、供給されるアドレス情報は、そのアイテムを独特に識別するに充分なものでなければならない。ＲＥｘ ＡＰＩで定義されたアドレスコンポーネントは、データソース、データタイプ、及びレコードＩＤである。
【００６９】
これらのコンポーネントの中で、レコードＩＤだけが必須である。他の２つについては、遂行されているオペレーションにおいてそれらの値が暗示されることが考えられ、このケースでは、それらを無視することができる。クライアントが、有効データソースを決定する能力を有し、且つおそらく、ユーザがどちらを使用するか選択するのを許すこともできる場合には、データソースコンポーネントを使用して、クライアントが異なるデータソースで新たなアイテムを生成できるようにする。
【００７０】
これらのコンポーネントの名前は、ＲＥｘ ＡＰＩのオリジナルドメインから発生するが、それらをアドレス要求に使用することができる。レコードＩＤは、例えば、設定経路ファンクションである。あるデータタイプについては、レコードＩＤが任意であることに注意されたい。これらのケースでは、レコードＩＤを省くことができる。サーバーからの各応答内では、レコードＩＤごとに１つのアイテムがある。
【００７１】
クライアントは、ｐｕｔＩｔｅｍｓコールを使用してサーバーにレコードを送信する。この機能は、ＥｘｃｈａｎｇｅＩｔｅｍｓのアレーをパラメータとしてとる。サーバーは、各ｐｕｔＩｔｅｍｓコールに対してＥｘｃｈａｎｇｅＲｅｓｕｌｔ構造で応答し、これは、保留中の変更を有するデータタイプのアレーと、受け取ったアイテムに対する確認とを含む。１つの要件は、クライアントが、ｐｕｔＩｔｅｍｓをコールする前にサーバーから受け取った全アイテムを確認することである。
【００７２】
いつでも、クライアントは、ｇｅｔＩｔｅｍｓ要求を送信することにより、保留中アイテムについてサーバーに問合せすることができる。このコールは、アイテムキャッシュのコンテンツを調査し、そしてクライアントに対して保留中のレコードを返送する。アイテム及び状態の最適な交換を容易にするために、クライアントは、ａｃｋＡｎｄＧｅｔＩｔｅｍｓコールを使用することにより新たなアイテムをゲットするときに確認情報を含ませることができる。確認情報のフォーマットは、以下で説明する。
【００７３】
各ｇｅｔＩｔｅｍｓコールに応答して、サーバーは、ＥｘｃｈａｎｇｅＲｅｓｕｌｔを返送し、これは、とりわけ、保留中アイテムのコンテンツを含むＥｘｃｈａｎｇｅＩｔｅｍｓのアレーと、どのデータタイプが、検索されるべきアイテムをより多く有するか指示するＤａｔａＴｙｐｅのアレーとを含む。
【００７４】
サーバーからクライアントへのアイテムの流れを最適化するために、サーバーは、常に、アイテムの追加及び置き換えの前に、削除アイテムを送信する。ｇｅｔＩｔｅｍｓ要求は、次の要件を含む。
−クライアントは、ｇｅｔＩｔｅｍｓをコールする前に、全ての保留中変更を、ｐｕｔＩｔｅｍｓを経てサーバーへ送信し、
−クライアントは、各ｇｅｔＩｔｅｍｓコールに応答してどれほど多くの情報を返送すべきか決定するためにサーバーが使用する限界値を含み、及び
−クライアントは、ｇｅｔＩｔｅｍｓコールの直後にａｃｋＩｔｅｍｓをコールする。
【００７５】
アイテムは、両方向に確認され、クライアント及びサーバーは、いつアイテムが首尾良く処理されたか分る。ａｃｋ及び確認という語は、本明細書全体にわたり交換可能に使用されることに注意されたい。ｇｅｔＩｔｅｍｓによりアイテムの受信を確認する仕方は、２つあり、即ち個々のａｃｋ ＥｘｃｈａｎｇｅＩｔｅｍによるものか、又はａｃｋ 全ＥｘｃｈａｎｇｅＩｔｅｍｓによるものである。欠陥ａｃｋは、常に、個々のａｃｋ ＥｘｃｈａｎｇｅＩｔｅｍを必要とし、従って、厳密なアイテム及び欠陥の原因を識別することができる。ａｃｋ 全ＥｘｃｈａｎｇｅＩｔｅｍｓは、アイテムを確認する前に受け取った全てのアイテムが、首尾良く処理されたとして解釈されるように取り扱われる。Ａｃｋ全アイテムメソッドは、有効データタイプ名を含む。これは、交換に含まれるデータタイプごとに個別のａｃｋ全アイテムが必要とされることを意味する。
【００７６】
サーバーは、ｐｕｔＩｔｅｍｓコールに応答してａｃｋアイテムを返送しない。むしろ、全ｐｕｔＩｔｅｍｓコールに対する全結果応答を返送する。換言すれば、ｐｕｔＩｔｅｍｓコールにおけるアイテムの処理は、全てか無かの(all-or-nothing)オペレーションである。この理由で、クライアントから送信されたアイテムを確認するときには、アイテムｒｅｆ値が使用されない。クライアントは、彼らがサーバーへ送信するＥｘｃｈａｎｇｅＩｔｅｍｓからこの値を省く。クライアントは、できるだけ早くａｃｋ全アイテムを送信し、サーバーがクライアントの最も正確な状態表示をもつことが推奨される。
【００７７】
提案されたレコードＩＤを記憶できないか又は記憶しないことを選択するクライアントは、サーバーにより提案された（一時的）ロケートユニットＩＤ（ＬＵＩＤ）と、クライアントにおけるレコードを表わすＬＵＩＤとを含むマップコマンドを返送することができる。クライアントは、ａｃｋＩｔｅｍｓコールにおいてＥｘｃｈａｎｇｅＩｔｅｍｓを通すことによりサーバーへマップコマンドを送信する。マップコマンドは、いつでも送信でき、又、何回でも送信でき（通信欠陥の場合に）、更に、アイテムの暗示的受信確認として解釈されない。クライアントは、ＩＤマップされたアイテムについても、依然、ａｃｋアイテムを明確に通せることに注意されたい。クライアントは、マップコマンドをサーバーへ送信するまで、サーバーのレコードＩＤを使用することができる。
【００７８】
ＩＤをマップするために、クライアントは、サーバーから受け取ったＥｘｃｈａｎｇｅＩｔｅｍｓを、アイテムのタイプを変更して、データメンバーをクライアントのＬＵＩＤに置き換えた後に、エコーバックする。一実施形態において、サーバーから送られるＥｘｃｈａｎｇｅＩｔｅｍの一例を以下に示す。
クライアントは、次のようなマップコマンドを返送することができる。
【００７９】
レコード交換データ構造
一実施形態において、ＲＥｘのデータ構造の例を以下に示す。
【００８０】
ＩｔｅｍＲｅｆは、クライアントへ送信するアイテムを参照するためにサーバーが使用する独特の識別子である。クライアントは、この値を使用して、サーバーから受け取ったアイテムを確認する。ＩｔｅｍＲｅｆは、整数値の単調に増加するシーケンスである。データタイプごとにシーケンスを維持する。
【００８１】
又、装置は、ＩｔｅｍＲｅｆ値の単調に増加するシーケンスと共にサーバーへ送信するコマンドをマークすることができる。サーバーと装置との間の接続が中断されたときには、サーバーは、ｉｔｅｍＲｅｆ値を調査しそして既に受け取られたコマンドを無視することにより、再送信コマンドを検出する。装置は、ｉｔｅｍＲｅｆ値を伴うコマンドをサポートするところのデータタイプごとにｉｔｅｍＲｅｆシーケンスを維持する。装置は、全コマンド又は非コマンドに対するデータタイプに基づいてｉｔｅｍＲｅｆ値を送信するように保証する。
【００８２】
１つの解決策において、有効なアイテムタイプを以下に列挙する。
−Add(追加) １
−Replace(置き換え) ２
−Delete(削除) ３
−AddOrReplace ４ 装置からサーバーへのみ有効
−Map(マップ) ５ 永続的に記憶されず
−Get(ゲット) ６
−Ack ７ 永続的に記憶されず
−AckAll ８ 永続的に記憶されず
−Query(問合せ) ９
−QueryResult １０
−QueryEnd １１
−Clear(クリア) １２
−GetResult １５
データコンテンツ：
−データのレコードコンテンツ − 追加及び置き換えのため
−ＮＵＬＬ − 削除オペレーションを遂行するのに付加的な情報が要求されない限り削除のため（ある好ましい管理のケースと同様）
−レコードＬＵＩＤ − マップのため
−任意のフィルタ − 問合せコマンドのため
【００８３】
ＲＥｘ ＡＰＩは、レコード又はデータを交換するための柔軟性のあるプロトコルである。しかしながら、ＲＥｘ ＡＰＩに組み入れられた柔軟性にも関らず、コアタイプ定義で全ての必要な情報が与えられない情況が生じる。この問題を解消する１つの仕方は、ＡＰＩが与えるコアタイプ定義に基づいて顧客タイプを定義することである。これは、ＲＥｘがＸＭＬ−ＲＰＣに基づくものであることから取り扱われる。ＲＥｘ ＡＰＩで定義された全ての構造は、ＸＭＬ−ＲＰＣフォーマットの構造として転送される。ＸＭＬ−ＲＰＣ構造は、名前／値の対の集合としてみなすことができる。構造を拡張するために、新たな名前／値の対が追加される。
【００８４】
ＲＥｘ ＡＰＩパーサは、一般的なＸＭＬ−ＲＰＣオブジェクトを構築し、そしてそれらを、プロトコルハンドラークラスに常駐するマーシャラーファンクションへ通す。コアＲＥｘ ＡＰＩファンクションは、単一のプロトコルハンドラーに常駐するが、全コアＲＥｘ ＡＰＩファンクションを受け継ぎながらそれら自身の目的で特殊なファンクションを与える顧客プロトコルハンドラーを定義することができる。これらの特殊なファンクションは、それらが受け取るパラメータをマーシャルし、そして拡張タイプを適宜に取り扱うことができる。拡張タイプの一例を以下に示す。
【００８５】
前記構造は、ＥｘｃｈａｎｇｅＩｔｅｍが予想されるところであれば、どこでも通されるが、ＤＭＥｘｃｈａｎｇｅＩｔｅｍタイプを理解するファンクションは、ｄａｔａＴｙｐｅＩＤ情報をサーチして使用することもできる。
【００８６】
レコード交換状態及び結果コード
テーブル２は、有効な交換状態及び結果コードを定義する。列挙された全ての値が全てのケースに適用できるのではないことに注意されたい。各ファンクションに適用する厳密な値に対する個々のファンクションを協議する。
テーブル２
【００８７】
１つの解決策において、ＣＬＳにエラー状態を通知するのに使用される要求、それに対応する構造、及び応答について、以下に述べる。又、構造は、エラー状態がもはや存在しないときにエラーをクリアするのにも使用される。
【００８８】
ＥｒｒｏｒＭｅｓｓａｇｅ構造は、ｒａｉｓｅＥｒｒｏｒ及びｃｌｏｓｅＥｒｒｏｒ要求に対するパラメータとして送信される。全てのメンバーが全てのエラー及び全ての要求メソッドに対して設定されるのではない。各エラー及び要求メソッドに対して、メンバーは、未使用、任意、及び必須として定義される。メンバーの後のかっこ内の数字は、メンバーの最大長さを定義することに注意されたい。
【００８９】
全ての要求に対する応答として、ＥｒｒｏｒＲｅｓｐｏｎｓｅ構造が発呼側装置へ返送される。
【００９０】
各要求に対する応答として、ＣＬＳは、応答構造において状態メンバーを設定することにより要求の結果を返送する。状態メンバーに対する値は、次の通りである。
テーブル３
【００９１】
ｒａｉｓｅＥｒｒｏｒコールは、装置にエラーが生じたことをＣＬＳに通知するのに使用される。ＥｒｒｏｒＲｅｓｐｏｎｓｅ要求は、エラー形式に基づいて異なるメンバーが設定される場合にＥｒｒｏｒＭｅｓｓａｇｅ構造をアーギュメントとみなす。その結果、ＥｒｒｏｒＲｅｓｐｏｎｓｅ構造が返送される。
ErrorResponse raiseError (ErrorMessage)
【００９２】
ｃｌｏｓｅＥｒｒｏｒ要求は、以前のｒａｉｓｅＥｒｒｏｒ要求により報告されたエラーをクリアする。ｃｌｏｓｅＥｒｒｏｒ要求に対して、ＥｒｒｏｒＭｅｓｓａｇｅ構造のｍｅｓｓａｇｅＩＤメンバーのみが使用される。ＣＬＳは、要求を受け取ると、同じｍｅｓｓａｇｅＩＤをもつ以前に報告されたエラーをクリアする。
ErrorResponse closeError (ErrorMessage)
【００９３】
レコード交換ファンクション
この章は、レコード交換ＡＰＩにおけるファンクションについて述べる。通されたパラメータを変更するファンクションについては、次の規定を使用する。
→ 右を向いた矢印は、値がクライアントにより設定され、サーバーにより変更されないことを指示する。
← 左を向いた矢印は、サーバーが、クライアントにより送られた値を読み取らず、値を返送することを指示する。
←→ 両方向矢印は、サーバーが、クライアントの値の読み取りと、おそらく更新された値の返送との両方を行うことを指示する。
【００９４】
レコード交換ＡＰＩの前交換ファンクションは、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒ、ｉｎｉｔＲｅｆｒｅｓｈ、及びｑｕｅｒｙＣｈａｎｇｅｓを含む。前交換ファンクション、それに対応するフォーマット及びパラメータについて、以下に述べる。
ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒ：クライアントは、ＤａｔａＴｙｐｅ構造内のデータタイプに対して両方のアンカーでこのファンクションをコールし、２つの同期アンカーの一方がサーバーアンカーに一致することを検証する。同期アンカーチェックが所与のデータタイプに対してフェイルした場合には、サーバーがリフレッシュ要求結果を返送する。サーバーに記憶された同期アンカー値は、変更されない。
ExchangeResult checkSyncAnchors (DataType[] dataType)
パラメータ：
ｄａｔａＴｙｐｅ−どのデータタイプをチェックに使用すべきか指示するアレー：
→ ｄａｔａＴｙｐｅＮａｍｅ
→ ｓｙｎｃＡｎｃｈｏｒ−このデータタイプに対する現在の装置同期アンカー
→ ｐｅｎｄｉｎｇＳｙｎｃＡｎｃｈｏｒ−このデータタイプに対する保留中アンカー リターン：各ＤａｔａＴｙｐｅに対して指定された適当なｅｘｃｈａｎｇｅＳｔａｔｕｓと共にＤａｔａＴｙｐｅを含むＥｘｃｈａｎｇｅＲｅｓｕｌｔ。
← 結果−サーバーが要求を首尾良く処理したときには、２００（ＯＫ）、又は定義されたエラーコード
← ｄａｔａＴｙｐｅは、データタイプに対してｅｘｃｈａｎｇｅＳｔａｔｕｓを保持する−２００（ＯＫ）、２０１、又は定義されたエラーコード
ｉｎｉｔＲｅｆｒｅｓｈ：リフレッシュが必要であることをクライアントが決定するか又はサーバーにより通知された場合には、ｉｎｉｔＲｅｆｒｅｓｈをコールして、リフレッシュプロセスを開始する。
ExchangeResult initRefresh (DataType[] dataType)
パラメータ：
ｄａｔａＴｙｐｅ−どのデータタイプを初期化に使用すべきか指示するアレー：
→ ｄａｔａＴｙｐｅＮａｍｅ
→ ｅｘｃｈａｎｇｅＳｔａｔｕｓ−２５０（交換リフレッシュ）
→ ＳｙｎｃＡｎｃｈｏｒ−このデータタイプに対する新たなアンカー
リターン：次のようにポピュレートされたＥｘｃｈａｎｇｅＲｅｓｕｌｔ：
← 結果−サーバーが要求を首尾良く処理したときには、２００（ＯＫ）、又は定義されたエラーコード
← ｄａｔａＴｙｐｅは、オリジナルコールで指定された各データタイプに対してｉｎｉｔ状態を指示する：２００（ＯＫ）、２０１、又は定義されたエラーコード
ｑｕｅｒｙＣｈａｎｇｅｓ：このファンクションは、クライアントが保留中の変更に対してサーバーをポーリングして、おそらく、交換の実行の前にユーザフィードバックを与えることを希望する場合に使用される。
ExchangeResult queryChanges (DataType[] dataType)
パラメータ：
ｄａｔａＴｙｐｅ−どのデータタイプを変更問合せに使用すべきか定義するアレー。空のデータタイプアレーを送信することで、全てのデータタイプに対する変更を問合せる。
→ ｄａｔａＴｙｐｅＮａｍｅ
リターン：次のようにポピュレートされたＥｘｃｈａｎｇｅＲｅｓｕｌｔ：
← 結果−サーバーが要求を首尾良く処理したときには、２００（ＯＫ）、又は定義されたエラーコード
← ｄａｔａＴｙｐｅは、どのＤａｔａＴｙｐｅがサーバーに保留中の変更を有するか指示する。発呼者が空のｄａｔａＴｙｐｅパラメータを通す場合には、データタイプのアレー結果が、サーバーに変更が存在するデータタイプしか含まない。発呼者が空でないｄａｔａＴｙｐｅパラメータを通す場合には、同じアレーが、各データタイプに対して指定された２００（変更なし）、２０１（レコード保留中）、又は４１７交換状態と共に返送される。
【００９５】
レコード交換ＡＰＩの後交換ファンクションは、ａｃｋＩｔｅｍｓ、ｐｕｔＩｔｅｍｓ及びａｃｋＡｎｄＰｕｔＩｔｅｍｓを含む。後交換ファンクション、それに対応するフォーマット及びパラメータについて、以下に述べる。
【００９６】
ａｃｋＩｔｅｍｓ：サーバーからアイテムを受け取った後に、クライアントは、サーバーへ確認を返送する。これは、各レコードの到着状態をサーバーに通知し、サーバーがクライアントデータのキャッシュを効率的に管理できるようにする。一実施形態において、このファンクションは、種々のｇｅｔＩｔｅｍｓコールにおいてサーバーがクライアントに何を返送するかであるＥｘｃｈａｎｇｅＩｔｅｍｓのアレーを使用する。クライアントは、各ＥｘｃｈａｎｇｅＩｔｅｍのｉｔｅｍＲｅｆ及び結果メンバーを指定するだけでよい。このファンクションを使用する別の仕方は、Ａｃｋ Ａｌｌに設定されたｉｔｅｍＴｙｐｅ、確認されているアイテムのグループに基づいて設定されたｄａｔａＴｙｐｅ、及びそのｄａｔａＴｙｐｅに対して首尾良く処理された最後のアイテムに設定されたｉｔｅｍＲｅｆと共にＥｘｃｈａｎｇｅＩｔｅｍを送信することである。サーバーは、ｉｔｅｍＲｅｆが指定のｉｔｅｍＲｅｆ値以下であるようなｄａｔａＴｙｐｅの全てのアイテムに対してこれを首尾良い確認として解釈する。多数のＥｘｃｈａｎｇｅＩｔｅｍｓをこのように送信できることに注意されたい。全ての個々のａｃｋアイテムは、ｉｔｅｍＡｃｋパラメータにおいてａｃｋ全アイテム(ack-all-items)の前に含まれる。
ExchangeResult ackItems (ExchangeItem[] itemAcks)
パラメータ：
ｉｔｅｍＡｃｋｓ−確認されているアイテムに関する情報を含むＥｘｃｈａｎｇｅＩｔｅｍｓのアレー。ｉｔｅｍＡｃｋｓの要件は、次の通りである。
テーブル４
リターン：次のようにポピュレートされたＥｘｃｈａｎｇｅＲｅｓｕｌｔ：
← 結果−サーバーが要求を首尾良く処理したときには、２００（ＯＫ）、又は定義されたエラーコード
← ｄａｔａＴｙｐｅｓ−ｄａｔａＴｙｐｅ構造アレー；各エレメントは、ｅｘｃｈａｎｇｅＳｔａｔｕｓを保持する：２００）又は定義されたエラーコード
ｐｕｔＩｔｅｍｓ：このファンクションは、クライアントが多数のアイテムをサーバーへ送信するのを許す。
ExchangeResult putItems (DataType[] dataTypes, ExchangeItem[] items):
パラメータ：
ｄａｔａＴｙｐｅ−装置は、この要求からのアイテムアレーに使用される全てのｄａｔａＴｙｐｅに対し、新たな同期アンカーを送信する。
→ ｄａｔａＴｙｐｅＮａｍｅ
→ ＳｙｎｃＡｎｃｈｏｒ−このデータタイプに対する新たなアンカー
ｉｔｅｍｓ−サーバーへ送信されるべきレコードを含むＥｘｃｈａｎｇｅＩｔｅｍｓのアレー
リターン：次のようにポピュレートされたＥｘｃｈａｎｇｅＲｅｓｕｌｔ：
← 結果−サーバーが要求を首尾良く処理したときには、２００（ＯＫ）、又は定義されたエラーコード
← ｄａｔａＴｙｐｅｓ−要求におけるデータタイプに対するｄａｔａＴｙｐｅ構造；各エレメントは、ｅｘｃｈａｎｇｅＳｔａｔｕｓを保持する：２００、２０１、又は定義されたエラーコード
ａｃｋＡｎｄＰｕｔＩｔｅｍｓ：このファンクションは、ｐｕｔＩｔｅｍｓと同様であるが、クライアントが、新たなアイテムをプットする前に、受け取ったアイテムを確認できるようにするパラメータが追加されている。
ExchangeResult ackAndPutItems (ExchangeItem[] acks, DataType[] dataTypes,
ExchangeItem[] items)
パラメータ−ｐｕｔＩｔｅｍｓと同様であるが、次のものが追加されている。
ａｃｋ−特定のＥｘｃｈａｎｇｅＩｔｅｍｓに対する確認情報を含む。サーバーは、クライアントからのレコードを受け容れる前にこれらのａｃｋを処理する。より多くの情報についてはａｃｋＩｔｅｍｓファンクションの説明を参照されたい。
リターン：ｐｕｔＩｔｅｍｓと同じ
ｇｅｔＩｔｅｍｓ：クライアントは、１つ以上のデータタイプについて保留中のレコードを検索するためにこのファンクションをコールする。これは、サーバーからレコードを検索する通常の方法である。各データタイプに対するｉｔｅｍＲｅｆ値は、サーバーが、アイテムキャッシュのどのレコードをクライアントが既に受け取ったかそしてどのレコードをまだ送信する必要があるか決定できるようにする。クライアントは、このフィールドにおいて、最後に処理したｉｔｅｍＲｅｆを送信することができる。
ExchangeResult getItems (DataType[] dataTypes, int limit)
パラメータ：
ｄａｔａＴｙｐｅｓ−どのデータタイプに同期すべきかそしてアイテムキャッシュのどのポイントでレコードの送信を開始すべきかサーバーに通知するＤａｔａＴｙｐｅのアレー。ＤａｔａＴｙｐｅアイテムは、次のように通される。
→ ｄａｔａＴｙｐｅＮａｍｅ−データタイプの名前
→ ｓｙｎｃＡｎｃｈｒ−このデータタイプに対する新たなアンカー
サーバーは、ＤａｔａＴｙｐｅアレーがエレメントを含まないときにｇｅｔＩｔｅｍｓに対する要求を無視する。
ｌｉｍｉｔ−これは、非圧縮の応答ＸＭＬ−ＲＰＣメッセージの最大サイズを指定する任意のパラメータである。この値が省かれる場合には、サーバーは、妥当と思われる限界値を使用する。
リターン：次のようにポピュレートされたＥｘｃｈａｎｇｅＲｅｓｕｌｔ：
← 結果−サーバーが要求を首尾良く処理したときには、２００（ＯＫ）、又は定義されたエラーコード
← ｄａｔａＴｙｐｅｓ−検索される準備のできたアイテムを有する要求から各データタイプに対するＤａｔａＴｙｐｅ構造を含む。これは、次のようにポピュレートされる。
← ｄａｔａＴｙｐｅＮａｍｅ
← ｅｘｃｈａｎｇｅＳｔａｔｕｓ−２００（ＯＫ）、２０１、又は定義されたエラーコード
← ｉｔｅｍｓ−次のようにポピュレートされた保留中のレコードを含む
← ｉｔｅｍＲｅｆ
← ｉｔｅｍＴｙｐｅ
← ｒｅｃｏｒｄＩＤ−追加アイテムに対して一時的ＬＵＩＤ、他の全てのアイテムタイプに対してクライアントＬＵＩＤ
← ｄａｔａＴｙｐｅＮａｍｅ
← ｄａｔａ−削除アイテムの場合は省かれる
ａｃｋＡｎｄＧｅｔＩｔｅｍｓ：このファンクションは、ｇｅｔＩｔｅｍｓと同様であるが、クライアントが、新たなアイテムをゲットしながら、受け取ったアイテムを確認できるようにするパラメータが追加される。
ExchangeResult ackAndGetItems (ExchangeItem[] ack, DataType[] dataType, int
limit)
パラメータ：
ａｃｋ−特定のＥｘｃｈａｎｇｅＩｔｅｍｓに対する確認情報を含む。サーバーは、アイテムキャッシュからレコードを検索する前にこれらのａｃｋを処理する。更なる情報については、ａｃｋＩｔｅｍｓファンクションの説明を参照されたい。
【００９７】
図１６は、異なるＲＥｘメソッドを使用してユーザ装置とサーバーとの間の対話を示すフローチャートである。
【００９８】
レコード交換アイテムタイプ
ｇｅｔＩｔｅｍｓ又はａｃｋＡｎｄＧｅｔＩｔｅｍｓ要求に対する応答として、サーバーは、Ｃｌｅａｒコマンドを返送する。このコマンドは、データコンテンツをもたず、装置が所与のデータタイプ名に対して全てのアイテムを除去するよう強制する。
【００９９】
初期同期の一部分としてクライアント装置のＰＩＭデータをインポートするか又はｄａｔａＳｏｕｒｃｅからシャドーデータをフェッチするようなある状況において、サーバーは、Ｑｕｅｒｙコマンドを装置へ返送し、装置が、所与のデータタイプに対するデータをサーバーへアップロードするように強制することができる。
【０１００】
図１７は、本発明の一実施形態による問合せプロセスのシーケンス図である。ステップ１において、装置は、サーバーから情報を要求するためにｇｅｔＩｔｅｍｓメソッドをコールする。ｇｅｔＩｔｅｍｓ又はａｃｋＡｎｄＧｅｔＩｔｅｍｓ要求に応答して、サーバーは、Ｑｕｅｒｙコマンドを返送する。コマンドのＥｘｃｈａｎｇｅＩｔｅｍにおいて、ｊｏｂＩＤフィールドが設定され、この問合せをマークする。任意のデータフィールドが問合せを制限するためのフィルタを含んでもよい。フィルタが与えられないときは、装置は、所与のデータタイプに対して全てのアイテムを返送する。Ｑｕｅｒｙコマンドに対するＥｘｃｈａｎｇｅＩｔｅｍの一例を以下に示す。
【０１０１】
ステップ２において、装置は、ａｃｋＩｔｅｍｓをコールし、Ｑｕｅｒｙコマンドを受け取ったことを確認する。ステップ３において、装置は、問合せされたデータを収集する。ステップ４において、装置は、ｐｕｔＩｔｅｍｓを使用してサーバーへデータを送信する。各々の問合せされたアイテムは、１つのＱｕｅｒｙＲｅｓｕｌｔとして送信される。全てのＱｕｅｒｙＲｅｓｕｌｔアイテムが送信された後に、問合せに対するデータアップロードが行なわれることをマークする１つのＱｕｅｒｙＥｎｄアイテムが送信される。全てのＱｕｅｒｙＲｅｓｕｌｔ及びＱｕｅｒｙＥｎｄアイテムは、問合せからのジョブＩＤに設定されたｊｏｂＩＤフィールドを有し、これらアイテムがこのｊｏｂＩＤをもつ問合せに関係していることを指示する。ＱｕｅｒｙＲｅｓｕｌｔ及び最終的なＱｕｅｒｙＥｎｄＥｘｃｈａｎｇｅＩｔｅｍの一例を以下に示す。
【０１０２】
問合せに対する結果が１つのｐｕｔＩｔｅｍｓコールに対して大き過ぎるときに、装置は、複数のｐｕｔＩｔｅｍｓを使用して、アイテムをサーバーにアップロードすることができる。最終的なＱｕｅｒｙＥｎｄコマンドは、最後のｐｕｔＩｔｅｍｓコールにおいてのみ送信される。
【０１０３】
装置は、ステップ２の後、例えば、装置クラッシュの後、ユーザが装置をターンオフした後、又は死んだバッテリを交換した後、再スタートするときに、問合せを続ける。装置は、Ｑｕｅｒｙコマンドを既に確認しているので、サーバーは、このコマンドを再送信しない。それ故、装置は、このコマンドを再スタートに生き残るように持続させる。この状況を回避するために、装置は、ステップ４において、ａｃｋＡｎｄＰｕｔＩｔｅｍｓをコールすることによりＱｕｅｒｙコマンドを確認することができる。
【０１０４】
サーバーは、データフィールドを使用して、フィルタを、Ｑｕｅｒｙコマンドの一部分として設定できることに注意されたい。一実施形態では、サーバーは、ｄａｔａＳｏｕｒｃｅのためのフィルタとしてストリング｛ｐａｒｔｉａｌ｝を使用するだけである。このフィルタは、問合せされたアイテムに対してシャドー情報のみを返送するようにｄａｔａＳｏｕｒｃｅに通知する。これは、アップロードされるデータの量を減少する。サーバーが完全なアイテムを必要とするときには、それをフェッチするためにＧｅｔコマンドを送信する。
【０１０５】
サーバーが（部分フィルタを通して）シャドー情報を要求するときには、ｄａｔａＳｏｕｒｃｅが、メール、連絡先、タスク、及び事象アイテムのような異なるタイプのデータに対してこの情報を返送する。
【０１０６】
Ｇｅｔコマンドは、ｐｕｔＩｔｅｍｓを使用してサーバーへ指定のアイテムをアップロードするために、ＬＵＩＤを指定することにより、装置に要求する。Ｇｅｔコマンドに対するＥｘｃｈａｎｇｅＩｔｅｍの一例を以下に示す。
【０１０７】
装置は、ＧｅｔＲｅｓｕｌｔを使用してアイテムを返送する。ジョブＩＤを使用して、ＧｅｔとＧｅｔＲｅｓｕｌｔを接続する。
【０１０８】
問合せのケースと同様に、装置は、ａｃｋＡｎｄＰｕｔＩｔｅｍｓを使用して、Ｇｅｔコマンドを確認すると共に、要求されたアイテムを１つのコールにおいてサーバーへ送信するか、又は装置は、Ｇｅｔコマンドの結果を永続的なものにすることに注意されたい。装置は、不存在アイテムに対してＧｅｔを受け取ると、４２２状態コードでアイテムを確認する。
【０１０９】
ＱｕｅｒｙＲｅｓｕｌｔコマンドは、問合せの結果において且つＧｅｔコマンドの応答として装置により使用される。ｄａｔａＳｏｕｒｃｅは、新たなアイテムを検出すると、Ａｄｄコマンドをサーバーへ送信する。ｄａｔａＳｏｕｒｃｅは、膨大な量の新たなアイテム（例えば、数千のｅメールがｄａｔａＳｏｕｒｃｅにコピーされた新たなｅメールフォルダ）を検出すると、シャドー情報のみを含む新たなアイテムごとにＱｕｅｒｙＲｅｓｕｌｔコマンドを送信する。ＱｕｅｒｙＲｅｓｕｌｔコマンドの最後の情報断片を送信すると、アップロードが終了したことをサーバーに通知するためのＱｕｅｒｙＥｎｄコマンドが送信される。サーバーは、１つのアイテムの完全な情報を必要とするときに、Ｇｅｔコマンドを送信する。これは、このようなケースのデータ送信量を減少する。
【０１１０】
サーバー及び装置の同期
接続寿命サーバー（ＣＬＳ）は、サーバーと１つ以上のユーザ装置との間のデータの同期を最適化する。より詳細には、ＣＬＳは、所定のバックアップインターバルに基づいてサーバーにおいて接続データセット(connected-data-set)のバックアップを生成する。次いで、接続データセットのバックアップが生成されたときに時間インターバルを追跡するためのチェックポイントマーカーを発生し、そしてそのチェックポイントマーカーを１つ以上のユーザ装置へ送信し、接続データセットに対する変更の第１レコードを維持する。
【０１１１】
サーバー及び１つ以上のユーザ装置が同期ずれしているかどうか決定するために、ＣＬＳは、サーバーの交換又はサーバーのクラッシュを検出する。或いは又、ＣＬＳは、セッションベースのｓｙｎｃＭＬプロトコル又は同期アンカープロトコル（以下に述べる）を実行して、サーバー及びユーザ装置が同期ずれしているかどうか決定してもよい。サーバー及び１つ以上のユーザ装置が同期ずれしていると決定されると、ＣＬＳは、サーバーにおいて接続データセットのバックアップデータを回復させる。次いで、チェックポイントマーカーを使用して１つ以上のユーザ装置から接続データセットの第１の変更レコードを要求する。又、１つ以上のユーザ装置からの接続データセットの第１の変更レコードに基づいてチェックポイントマーカーの後に変更を有する接続データセットの第１部分を決定する。これは、１つ以上のユーザ装置とサーバーとの間でチェックポイントマーカーの後に新しいタイムスタンプを有する接続データセットの部分を比較することによって行われる。次いで、サーバーにおいて第１の変更レコードのトランザクションを実行することにより変更を有する接続データセットの第１部分を更新する。
【０１１２】
同様に、サーバー及び後端データベースが同期ずれしていると決定すると、ＣＬＳは、サーバーにおいて接続データセットのバックアップデータを回復する。次いで、チェックポイントマーカーを使用して後端データベースから接続データセットの第２の変更レコードを要求する。又、後端データベースからの接続データセットの第２の変更レコードに基づいてチェックポイントマーカーの後に変更を有する接続データセットの第２部分を決定する。これは、後端データベースとサーバーとの間でチェックポイントマーカーの後に新しいタイムスタンプを有する接続データセットの部分を比較することによって行われる。次いで、サーバーにおいて第２の変更レコードのトランザクションを実行することにより変更を有する接続データセットの第２部分を更新する。
【０１１３】
同期アンカープロトコルの主な目的は、装置及びサーバーが交換アイテムに対して同期ずれして動作することを検出することである。クライアント装置は、サーバーと同期する責任を有する。しかしながら、クライアントだけでは検出できないシナリオが少なくとも１つある。次の事項シーケンスについて考える。
−クライアント及びサーバーは、ポイントＡにおいて同期している。
−クラインと及びサーバーは、その後、ポイントＢにおいて同期しており、実際のデータセットは、ポイントＡとは異なる。
−ユーザは、全てのデータ、構成ファイル、等を含む全装置映像のシステム回復を行なう。
−クライアントは、スタートするが、そのローカルデータをチェックするときに、ポイントＢにいるので、一貫性を調べる。しかしながら、装置がポイントＢにあると仮定すれば、サーバーとの一貫性がない（同期していない）。
【０１１４】
この問題は、ＲＥｘ同期アンカープロトコルにより対処される。同期アンカーに基づき、サーバーは、もはや同期していないことを検証してクライアントに通知することができる。これは、各データベースに対して、リフレッシュすることが必要なデータを転送するためのトラフィックを最小にするように行なわれる。交換アイテムの各タイプに対して、装置は、２つのアンカーを維持する。１つは、交換アイテムのタイプに対する現在アンカーである。装置は、サーバーからデータを要求し又はサーバーへデータを送信するときに、新たなアンカーを発生し、このデータを要求において送信する。要求がエラーなく終了すると、装置は、サーバーが新たなアンカーを首尾良く受け取ったことを知る。このケースでは、装置は、新たなアンカーを現在アンカーとして記憶する。
【０１１５】
クライアントは、サーバーとの通信を開始すると、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓメソッドをコールし、装置及びサーバーのアンカーが一致するかどうかチェックする。もしそうでなければ、装置及びサーバーは、このタイプの交換アイテムに対して同期ずれして動作している。
【０１１６】
図１８は、本発明の一実施形態によりクライアント装置とサーバーとの間で同期をとるための同期アンカープロトコルを示す。図１８に示すように、装置は、各データタイプの名前に対して２つの同期アンカーを維持する。１つは、現在アンカーであり、装置は、データを送信又は要求するメソッドをコールするときに、サーバーへの要求のデータタイプごとに新たな同期アンカー（保留中アンカー）を発生して送信する。首尾良い全体的応答は、サーバーが、これらデータタイプの名前に対して新たなアンカーを得て記憶したことを意味する（たとえ特定データタイプに対する交換状態が首尾良くなくても）。この場合には、装置は、各データタイプに対する新たなアンカーを現在アンカーとして記憶する。装置は、応答を得ないか、又は不首尾な全体的結果コードを伴う応答を得る場合、保留中アンカーを記憶し、それを次の新たなアンカーとして再送信する。
【０１１７】
装置は、現在アンカーで、そして任意であるが、保留中アンカーが存在する場合は保留中アンカーで、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓをコールする。１つのアンカーがサーバーアンカーに一致するときには、装置及びサーバーが同期状態にある。この場合及び保留中アンカーがあるときには、装置は、サーバーが保留中アンカーを受け取ったかどうか分らないので、以前に送られた現在アンカーを、現在アンカーとして使用し、そして保留中アンカーを次の新たなアンカーとして送信する。
【０１１８】
アンカーチェックが失敗すると、サーバーは、エラー状態コード４１７を返送する。装置は、アンカーを初期アンカーに戻すように設定し、新たなアンカー（初期アンカーではない）でｉｎｉｔＲｅｆｒｅｓｈをコールする。次いで、ｇｅｔＩｔｅｍｓをコールして、サーバーが装置に対してＣｌｅａｒコマンドを有するかＱｕｅｒｙコマンドを有するか決定する。次いで、装置は、ｐｕｔＩｔｅｍｓを経てサーバーへ装置管理アイテムを送信するのも任意である。最終的に、装置は、ｇｅｔＩｔｅｍｓをコールし、更新されたアイテムをサーバーから検索する。
【０１１９】
装置（又は１つのデータタイプ名に対して責任をもつ装置の一部分）は、それがスタートすると、先ず、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓをコールして、装置及びサーバーがまだ同期しているかどうかチェックする。又、ｇｅｔＩｔｅｍｓ又はａｃｋＡｎｄＰｕｔＩｔｅｍｓのようなメソッドも、要求からのデータタイプに対して４１７交換コードを返送できることに注意されたい。この場合、装置は、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓに対するコールがフェイルしたかのように働く。
【０１２０】
装置は、インストールの後、又は未知のデータタイプ４０４状態の後に、データタイプに対する初期同期をスタートすると、初期同期アンカーとしての０でｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓをコールする。装置が０を保留中アンカーとしても送信するかどうかは任意である。サーバー及び装置は、初期同期に対して同期状態にあることが要求される。
【０１２１】
装置は、初期のｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓコールの後にｇｅｔＩｔｅｍｓをコールし、そしてｇｅｔＩｔｅｍｓコールの結果として、Ｃｌｅａｒ又はＱｕｅｒｙコマンドが返送される。装置は、この初期コマンドが処理されたときに変更検出をアクチベートする。
【０１２２】
通信のユーザ装置状態の通知
ＣＬＳは、サーバーとユーザとの間の通信のユーザ状態を通知する。ユーザは、ＣＬＳによって維持された接続データセットの部分を共有する１つ以上のユーザ装置を有する。一実施形態において、ＣＬＳは、サーバーと１つ以上のユーザ装置との間の通信を、通知条件の所定セットに対して監視する。所定の通知条件のセットは、製造者により提供される情報に基づき且つ１つ以上のユーザ装置の実際の使用を通して収集される情報に基づき形成される。更に、所定の通知条件のセットは、接続データセットのエレメントの送信欠陥を含む。
【０１２３】
例えば、通知メッセージは、通知条件が検出される通信のタイトルを含む。又、通知メッセージは、通知条件が検出される通信のアブストラクトも含む。更に、サーバーにより装置へ送信される通知メッセージは、ハイパーリンクを含んでもよい。このハイパーリンクは、通知の性質についてより精巧であるウェブページを指してもよいし、又は問題を解決できるウェブページへユーザを導いてもよい（例えば、後端にアクセスするための新たなパスワードを入力する）。このメソッドが有益であるのは、通常、若干の情報アイテムしかクライアント装置へ搬送されず、且つ通知の性質を説明するのに多数のワードを必要とすることが多いためである。又、ハイパーリンクは、拡張手段も与える。通知メッセージ（又は通知スクリーン又はアプリケーションのメニュー）においては、このハイパーリンクの背後でウェブページをロードするためにブラウザをスタートするというオプションがある。
【０１２４】
通知条件が検出されると、ＣＬＳは、通知メッセージを１つ以上のユーザ装置へ送信する。一実施形態では、通知メッセージは、通知条件の所定セットが検出されたユーザ装置へ送信されることに注意されたい。別の実施形態では、通知メッセージは、通知条件の所定セットが検出されないユーザ装置へ送信されてもよい。
【０１２５】
更に別の実施形態では、所定通知条件のセットは、１つ以上のユーザ装置に対するｅメール、タスク、カレンダー及びアドレスブックオーバーフロー条件を含む。装置のオーバーフローを回避するために、サーバーは、各装置アプリケーションが保持できるデータの量を監視し、記録する。データは、次のいずれかで収集され、即ち、装置の製造者により提供される情報を通じて収集され、例えば、装置のアドレスブックが最大５００の連絡先を保持できることをユーザのマニュアルで指定するか；又はユーザ装置のテストを通じて収集され、例えば、サーバーにより送られるある数以上のレコードの記憶を装置が拒絶するか；或いは実際の使用を通じて収集され、例えば、事象の数がユーザのマニュアルにおける所定の最大数を越えても、あるカレンダーアプリケーションが依然機能する。
【０１２６】
収集されたデータに基づいて、サーバーは、サーバーインフラストラクチャーにおいて装置タイプ又はアプリケーション当たりの上限のセットを定義することができる。サーバーは、各装置におけるレコードの実際数を監視するので、装置におけるレコードの数が所定の上限に近付いたときに装置へそれ以上のレコードを送信するのを停止することができる。例えば、サーバーは、ユーザがまだある程度の有用な仕事を行なえるように、装置の９０％フル状態を保つことができる。更に、サーバーは、装置の特定のアプリケーション（例えば、ｅメール又はカレンダー）が所定の上限に達したことをユーザにアラートし、そして装置におけるレコードの数を減少するために特定アプリケーション用の異なるフィルタを適用するといった先見的アクションをとるようにユーザに要求することができる。他の解決策では、異なるデータタイプに異なるルールを適用して、装置におけるレコードの量を管理することができる。例えば、
−メール：常に装置へ送信される新たなメールには高いプライオリティが指定される。装置が新たなメールのための余地を作る必要がある場合には、最も古いものから最も新しいものへの順序で古いメールが削除される。
−タスク：オープンタスクには、より高いプライオリティが指定され、期限日が近いほど、タスクの重要性は高くなる。装置が新たなタスクのための余地を作る必要がある場合には、最も古いものから最も新しいものへの順序で、完了したタスクが削除される。
−カレンダー：近い将来生じる事象には、より高いプライオリティが指定される。一般に、将来の事象は、過去の事象よりも重要である。装置が新たな事象のための余地を作る必要がある場合には、最も古いものから最も新しいものへの順序で過去の事象が削除される。
−アドレスブック：装置に既にあるものに、より高いプライオリティが与えられる。アドレスブックがいっぱいになった場合には、サーバーは、他の装置からも、後端からも、新たなアドレスを装置へ与えない。
【０１２７】
設定交換（ＳｅｔＥｘ）プロトコル
設定交換（ＳｅｔＥｘ）プロトコルは、装置とサーバーとの間で設定情報を交換するのに使用される。ＳｅｔＥｘは、データ構造体に対する変更と共にＤＰＲＥｘプロトコルによりサポートされる。ＤＰＲＥｘプロトコルと同様に、データコンテンツは、設定変更を保持するＸＭＬドキュメントである。ＸＭＬデータコンテンツドキュメントのエンコード動作は、ＸＭＬ−ＲＰＣエンベロープのエンコード動作と常に同じである。エンコード動作は、全てのユニコードキャラクタを表わすことができる。ＳｅｔＥｘプロトコルは、設定をベースＵＲＬ拡張として使用し、例えば、ｈｔｔｐ：／／ｓｅｒｖｅｒ：ｐｏｒｔ／ｄｐ／ｓｅｔｔｉｎｇは、ＳｅｔＥｘ ＵＲＬの一例である。
【０１２８】
設定交換状態コード
ＳｅｔＥｘは、ＤＰＲＥｘと同じ状態コードを使用する。状態コード３００は、装置がゾンビ状態にあって設定をサーバーへプットするか又はサーバーからゲットするよう試みるときに返送される。この場合には、装置は、先ず、装置タイプ識別を送信する。ＳｅｔＥｘは、新たな状態コード４０５を使用する。このコードは、サーバーが装置から設定をゲットすることをいつ要求するか決定するために、ＳｅｔＥｘに対する応答として返送される。
【０１２９】
設定交換プロセスフロー
一実施形態において、設定交換のプロセスフローは、次の３つの利用ケース：１）初期設定交換；２）通常の設定交換；及び３）ダンプ設定交換について説明する。
【０１３０】
初期設定交換の間に、装置は、その装置タイプをサーバーに対して識別する。この状態は、装置をサーバーに初めて接続するときに生じる。これは、ユーザが新しい装置を買ったとき、又は装置が完全にリセットされたとき、或いは装置の状態がサーバー側でゾンビにリセットされた場合に起きることに注意されたい。これら全ての状態において、装置は、装置タイプ識別設定を交換することによりスタートする。これは、サーバーが装置の真のアイデンティティ（正しい装置タイプ識別情報）を決定できるようにする。考えられるプロセスフローシナリオは２つある。第１のケースでは、装置は、それがサーバーに初めて接続されると考え、装置タイプ識別設定を交換する。第２のケースでは、装置は、それが初期化されたと考え（同期された装置タイプ識別設定）、一方、サーバーは、そうでないことを考える。これら両方のケースは、以下の章で述べるシーケンス図に関連して検討する。
【０１３１】
図１９は、本発明の一実施形態により装置が装置タイプ識別設定を交換するときのプロセスフロー図である。図１９に示すように、ステップ１において、装置は、ｐｕｔＩｔｅｍｓをコールして、装置タイプ識別設定を交換する。ステップ１．１において、サーバーは、装置を適切に識別した後に装置のゾンビ状態を終了させる。ステップ１．２において、サーバーは、ｂｕｉｌｄＥｘｃｈａｎｇｅＲｅｓｕｌｔメソッドをコールすることにより応答を構築する。この応答は、装置へ送信されるべきサーバー状態を含む。装置が、装置タイプ識別設定を受け取ったときに既にゾンビ状態から出ている場合には、このオペレーションが何ら作用しない。
【０１３２】
図２０は、本発明の一実施形態によりゾンビ状態において装置タイプ識別以外の設定を装置が交換しようと試みるときのプロセスフロー図である。この状態は、サーバーにおける装置の既知の状態がゾンビ状態にあり、且つ装置が通常のアプリケーション設定を交換しようと試みるときに生じる。図２０に示すように、ステップ１では、装置は、ｐｕｔＩｔｅｍｓをコールして、通常の設定を交換する。この場合に、サーバーは、装置がゾンビ状態にあることを指示するエラーコード３００で装置要求を拒絶する。ステップ２において、装置は、ｐｕｔＩｔｅｍｓをコールして、装置タイプ識別設定を交換し、サーバーが装置のアイデンティティを確認すると共に、ゾンビ状態を終了できるようにする。
【０１３３】
通常の設定交換の場合には、装置は、装置で実行されているアプリケーションのための設定を交換する。このシナリオでは、装置は、もはやゾンビ状態になく、装置とサーバーとの間で通常の設定交換を遂行することができる。
【０１３４】
図２１は、本発明の一実施形態による通常の設定交換のためのシーケンス図である。図２１に示すように、ステップ１において、装置は、それが設定を変更した場合に、ｐｕｔＩｔｅｍｓメソッドコールを使用してそれらをサーバーに送信する。送信すべき設定が更にある限り、このステップを繰り返す。
【０１３５】
装置は、サーバーに得られる保留中設定変更についてサーバーから通知を受け取る場合に、ｇｅｔＩｔｅｍｓコールを発生して、設定変更を検索する。装置に対してサーバーに得られる保留中設定がない場合には、このステップを省けることに注意されたい。
【０１３６】
装置は、２０１データタイプ状態コードを通して、更に設定変更が存在するというフラグを立てた場合には、ａｃｋＡｎｄＧｅｔＩｔｅｍｓメソッドコールを発生する。装置は、この場合、サーバーからの最後の応答で受け取られた設定を確認し、そしてサーバーにおける保留中設定変更を要求する。
【０１３７】
最終的に、全ての設定変更がサーバーから装置によりフェッチされた後に、ａｃｋＩｔｅｍｓコールを発生する。ａｃｋＩｔｅｍｓメソッドは、サーバーが、サーバーから送信される変更設定に関連したリソースをクリーンアップできるようにする。
【０１３８】
上述したプロセスフローでは、更新設定間に相違はない。主な相違は、データコンテンツであるが、オペレーションは異なる。次のことに注意されたい。
１．空き設定ドキュメントを伴う削除は、全データベースを削除する。
２．全ての設定、及び削除データコンテンツドキュメントに残っている設定のサブツリーが削除される。
３．削除データコンテンツのノードとしてマークされた設定は、サブツリーを削除しない。
例えば、既存のツリーは、次の通りである。
ａ／ｂ／ｍ
ａ／ｂ／ｎ
ａ／ｃ／
ｍ及びｎを削除するために、サブノードを指定することができる。ｍ及びｎを削除するためのＳｅｔＥｘデータコンテンツは、次の通りである。
<Node name = “a”>
<Leaf name = “b”></Leaf>
</Node>
サブノードｂは、削除されるデータコンテンツにおいてリーフ（葉）として指定されることに注意されたい。それにより得られるツリー（木）は、次の通りである。
ａ／ｃ
【０１３９】
リーフを削除するのは一般的でない。又、内部ノードは、セマンティックをもたないことに注意されたい。上述したスキーマの例から、ツリー（ａ／ｃ）は、（ａ／ｂ、ａ／ｃ）と同じである。というのは、ｂは、内部ノードであり、セマンティックをもたない。従って、リーフａ／ｂ／ｍ及びａ／ｂ／ｎを削除することは、前記例においてａ／ｂを削除することとセマンティック的に同じである。リーフノード削除例は、次の通りである。
<Node name = “a”>
<Node name = “b”>
<Leaf name = “m”></Leaf>
<Leaf name = “n”></Leaf>
</Node>
</Node>
それにより得られるツリーは、次の通りである。
ａ／ｃ
【０１４０】
実施を簡単化するために、データコンテンツ仕様は、特定のサブノードにおいて削除が許されることを定義する。前記例の場合のデータコンテンツ制限は、ａ／ｂに関する削除しか許されず、リーフについては許されないことである。
【０１４１】
ダンプ設定交換
ダンプ設定交換の場合には、装置は、ＳｅｔＥｘメソッドコールを発生する。サーバーは、装置から全ての設定をゲットしたいことを決定する。このメソッドは、装置から全てのデータをゲットすることによりサーバーが期待する状態に装置があることをテストし又はチェックするのに主として使用される。これが生じると、サーバーは、特殊なエラーコード４０５で応答する。エラーコードに応答して、装置は、それを生じさせたデータ形式に関する設定情報のダンピングをスタートする。
【０１４２】
図２２は、本発明の一実施形態によるダンプ設定のためのシーケンス図である。装置は、ｐｕｔＩｔｅｍｓコールを呼び出して通常の設定を交換する。サーバーは、あるデータタイプに対して既知の全ての設定を装置がダンプすることを要求する状態にある場合に、所与のデータタイプに対して４０５コードを返送する。これは、装置がｇｅｔＩｔｅｍｓコールを開始するときにも生じることに注意されたい。
【０１４３】
装置は、ｉｎｉｔＲｅｆｒｅｓｈ（コード２５１）をコールして、ダンプ設定変更をスタートしたことをサーバーに通知する。装置は、サーバーによって送信されるべきダンプ要求アラートに応答してｐｕｔＩｔｅｍｓ要求を発生する。この状態では、装置は、それが含む全ての設定をサーバーへダンプする。このステップは、ダンプする必要のある更なる設定を装置が有する限り、繰り返される。
【０１４４】
設定交換データ構造
この章は、コア装置プロキシーレコード交換（ＤＰＲＥｘ）データ構造に対する改善を説明する。ＥｘｃｈａｎｇｅＩｔｅｍ構造は、設定交換をサポートするように変更される。特に、ＥｘｃｈａｎｇｅＩｔｅｍのｉｔｅｍＴｙｐｅ及びｒｅｃｏｒｄＩＤフィールドに対しＳｅｔＥｘプロトコルにおいてどんな値が許されるかに関して制約がある。
【０１４５】
一実施形態では、ｉｔｅｍＴｙｐｅデータ構造は、「削除(Delete)」及び「置き換え(Replace)」オペレーションをサポートする。設定変更の場合に、「置き換え」は、設定が存在しなければ「追加(Add)」を意味し、さもなければ、更新を行うよう再定義される。
ｒｅｃｏｒｄＩＤフィールドは、設定変更に対して省略される。
【０１４６】
装置が設定を要求するが、メッセージサイズを規定サイズ以下に制限するときには、ＳｅｔＥｘコンテンツが、規定サイズ以下のサイズへ分割される。分割は、リーフノードの基づくものである。例えば、メッセージサイズが０にセットされた場合には、要求当たり１つのリーフノードしか転送されない。多くの場合、この定義では実施が複雑になり過ぎ、利益が得られない。実施を簡単にするために、ノードレベルで設定をグループ分けすることができる。データコンテンツは、例えば、ａ／ｂ／ｃ、ａ／ｂ／ｄ、ａ／ｂ／ｅ及びａ／ｍ／ｃとして示される。
【０１４７】
ａ／ｂ／に対してグループ分けが可能である場合は、メッセージのサイズに関わらず、ａ／ｂ／ｃ、ａ／ｂ／ｄ、及びａ／ｂ／ｅを１つのメッセージで転送することが保証される。このメッセージは、他の設定も含み得ることに注意されたい。これは、設定を定義するためのデータコンテンツ仕様までである。
【０１４８】
次の章は、サンプル設定データコンテンツを含むＸＭＬ−ＲＰＣ断片を示す。一実施形態では、装置タイプ識別設定を交換するためにＥｘｃｈａｎｇｅＩｔｅｍのデータフィールドにおける設定ツリーデータコンテンツが使用される。６つの異なる装置タイプ識別設定が使用され、それらは、Ｍｏｄ、Ｈｉｎｔ１、Ｈｉｎｔ２、Ｈｉｎｔ３、Ｈｉｎｔ４、及びＨｉｎｔ５である。ここで、Ｍｏｄは、装置のモデルを表わし、ほとんどの場合に、装置を独特に識別するのに使用できる。Ｈｉｎｔ１ないしＨｉｎｔ５は、Ｍｏｄストリングに含まれた情報に加えて、装置タイプを識別するための情報を含む。
【０１４９】
次のｄｅｖＴｙｐｅＩｄｅｎｔＸＭＬスキーマは、どのデータが許されるか定義する。この場合のデータタイプ名は、ｓ−ｄｅｖＴｙｐｅＩｄｅｎｔである。
【０１５０】
ｅメールフォルダ設定を交換するための設定ツリーデータコンテンツである、ｇｅｔＩｔｅｍｓコールに対するサーバー応答の一例を以下に示す。
【０１５１】
ＳｅｔＥｘにおいて、Ｃｌｅａｒコマンドは、以前のインストール又はデータベースアクチベーションのトレースをクリーンアップする正に第１のコマンドとしては使用されない。それ故、装置は、ＳｅｔＥｘデータタイプに対して第１同期を遂行するときに（アンカー０でのｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓコール）、それ自体でクリーンアッププロセスを開始する。装置がＳｅｔＥｘ要求に対して交換状態４１７を返送することによりｉｎｉｔＲｅｆｒｅｓｈコールを遂行するように強制するときには、同じ初期同期ルールが適用される。
【０１５２】
設定交換ファンクション
この章は、ｇｅｔＩｔｅｍｓ、ｐｕｔＩｔｅｍｓ、ａｃｋＩｔｅｍｓ及びｉｎｉｔＲｅｆｒｅｓｈを含むＤＰＲＥｘの変更された定義のリストを含む。ｇｅｔＩｔｅｍｓ及びｐｕｔＩｔｅｍｓについては、次の制約が適用される。即ち、ｒｅｃｏｒｄＩＤフィールドは使用されず、返送されるＥｘｃｈａｎｇｅＩｔｅｍインスタンスにおけるｉｔｅｍＴｙｐｅフィールドに対して「置き換え」及び「削除」だけがサポートされる。ＥｘｃｈａｎｇｅＩｔｅｍの「データ」フィールドは、設定データコンテンツを含む。
【０１５３】
ａｃｋＩｔｅｍｓについては、次の制約が適用される。即ち、ｒｅｃｏｒｄＩＤフィールドは使用されず、返送されるＥｘｃｈａｎｇｅＩｔｅｍインスタンスにおけるｉｔｅｍＴｙｐｅフィールドに対してＡｃｋ及びＡｃｋＡｌｌだけがサポートされる。このケースでは、データフィールドが使用されない。
【０１５４】
ｉｎｉｔＲｅｆｒｅｓｈメソッドは、２つのケースにおいて装置によりコールされる。第１に、装置がサーバーアラートに応答して装置に知られた全ての設定のダンプをスタートしようとしていることをサーバーに通知するのに使用される。これは、装置に知られた各データタイプに対して状態コード２５１により表わされた特殊な交換状態ＥｘｃｈａｎｇｅＡｌｌにおいて送信することで遂行される。第２に、装置は、ｇｅｔＩｔｅｍｓコールの後にサーバーにおける全ての既知の設定を検索することを希望する。装置は、各データタイプに対して状態コード２５１で表わされた状態ＩＮＩＴ＿ＲＥＦＲＥＳＨを送信することによりこれを行なう。
【０１５５】
アプリケーション交換プロトコル
アプリケーション交換プロトコルは、装置とサーバーとの間でソフトウェア変更を交換するプロセスを定義するのに使用される。アプリケーション交換機能は、ＸＭＬ＿ＲＰＣの最上部に新たなプロトコルを定義することを必須としたレコード及び設定の交換とは極めて異なる。アプリケーション交換（ＡｐｐＥｘ）ソフトウェアに対するプロトコルの流れ、データの構造及びファンクションは、以下の章で述べる。ＡｐｐＥｘプロトコルは、ａｐｐｓをベースＵＲＬ拡張として使用すると共に、バージョン番号及び外部ユーザＩＤをＵＲＬパラメータとして使用する。ＡｐｐＥｘ ＵＲＬの一例が、ｈｔｔｐ：／／ｗｗｗ．ｖｅｒｄｉｓｏｆｔ．ｃｏｍ／ｄｐ／ａｐｐｓ？ｅｘｔＩＤ＝２３４７ｄｈｊｉ３４＆ｖｅｒｓｉｏｎ＝１．０．１として示される。
【０１５６】
アプリケーション交換プロセスフロー
図２３は、本発明の一実施形態による装置とサーバーとの間のアプリケーション交換プロセスフローを示すシーケンス図である。図２３のソフトウェア交換プロセスフローにおけるステップのシーケンスを以下に説明する。
１）装置は、利用可能なアプリケーション変更についてサーバーに要求する。サーバーは、変更を利用可能にする全てのアプリケーションに対するセットアップ情報のリストを返送する。サーバーがソフトウェア変更をもたない場合には、ＡｐｐＥｘプロセスが終了となる。
２）装置は、セットアップ情報を処理し、ソフトウェア変更の実行をいつスタートすべきか判断する。
３）装置は、アプリケーションセットアップを開始する。サーバーは、装置が実行すべきセットアップコマンドのリストで応答する。
４）装置は、セットアップコマンドを処理し、アプリケーションセットアップに必要なファイルをダウンロードする。ファイルのダウンロードが失敗すると、装置は、残りのファイルのダウンロードを停止する。これは、首尾良くダウンロードされたソフトウェアをインストールし、次いで、シーケンスｄｅｖｉｃｅＳｅｔｕｐＳｔａｒｔ及びｄｅｖｉｃｅＳｅｔｕｐＥｎｄを適当なエラーコードと共に使用して、ダウンロードが失敗したことをサーバーに通知する。
５）装置は、アプリケーションセットアッププロセスが装置においてスタートすることをサーバーに通知する。この情報は、サーバーにより使用されて、装置上で変更されたソフトウェアに関連した全ての古いサービスを無効にする。サーバーは、特殊な状態コード３０１で応答して、装置が、ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅをコールすることで全プロセスを始めからスタートするよう強制する。１つのセットアップコマンドがフェイルすると、装置は、残りのコマンドの実行を停止する。
６）装置は、アプリケーションをスタートする。
７）アプリケーションは、それがインストールされたことをサーバーに通知する。サーバーは、このコールを使用して、装置の設定をスケジュールする。
８）装置は、サーバーから必要な設定をフェッチする。
９）アプリケーションは、自己テストの準備ができたことを任意の要求を通じてサーバーに通知する。サーバーは、このアプリケーションに対するある規定のテストデータをアクチベートする。
１０）装置は、装置におけるセットアッププロセスが指定のアプリケーションに対して完了したことをサーバーに通知する。要求の一部分として、装置は、新たなソフトウェア同期アンカーを送信する。
１１）アプリケーションは、使用の準備ができたことを任意の要求を通じてサーバーに通知する。
【０１５７】
アプリケーション交換データ構造
この章は、装置とサーバーとの間でのソフトウェアアプリケーションの交換に使用されるＸＭＬ＿ＲＰＣデータ構造を説明する。アプリケーション交換データ構造は、ＳｅｔｕｐＩｎｆｏ、ＳｅｔｕｐＩｎｆｏＩｔｅｍ、ＳｅｔｕｐＣｏｍｍａｎｄ、ＮａｍｅＶａｌｕｅＰａｉｒ、及びＡｐｐＥｘＲｅｓｕｌｔを含む。
【０１５８】
ＳｅｔｕｐＩｎｆｏ構造は、装置が利用可能なソフトウェア変更についてサーバーに要求するときに使用される。サーバーは、装置に利用可能なソフトウェア更新を表わすＳｅｔｕｐＩｎｆｏインスタンスを変更する。
データメンバー：
ｄｅｓｃｒｉｐｔｉｏｎ：これは、必須のフィールドであり、人間が読むことのできるものである。これは、全ソフトウェア更新を記述するもので、装置によって使用されて、ユーザが更新を受け容れるよう求められた場合にユーザに対しダイアログボックスでメッセージを表示するものである。
ｓｅｔｕｐＳｉｚｅ：これは、アプリケーション更新のためのスペース要求を指定する必須フィールドである。
ｓｕｎｓｈｉｎｅＤａｔｅ：これは、ソフトウェアを更新できるときを指定する任意のフィールドである。フォーマットは、ＵＴＣである。サーバーへのアクセスは、装置がソフトウェアを間に合うようにインストールしないときには拒絶される。このフィールドが欠けたときには、装置は、ソフトウェア変更を直ちに処理するが、さもなければ、ユーザは、更新を今得たいか後で得たいか尋ねられる。
ＳｅｔｕｐＩｎｆｏＩｔｅｍｓ：これは、任意のフィールドで、ソフトウェア変更が存在するときにＳｅｔｕｐＩｎｆｏＩｔｅｍ構造のアレーである。
【０１５９】
ＳｅｔｕｐＩｎｆｏＩｔｅｍ構造は、ＳｅｔｕｐＩｎｆｏ構造内で使用される。各ＳｅｔｕｐＩｎｆｏＩｔｅｍは、装置に利用できるソフトウェア変更を表わす。
データメンバー：
ｓｅｔｕｐＴｙｐｅ：これは、必須のフィールドであり、定数ＩＮＳＴＡＬＬ＝１、ＵＰＤＡＴＥ＝２、及びＵＮＩＮＳＴＡＬＬ＝３、のうちの１つを含む。
ａｄｄｉｔｉｏｎａｌＤｅｓｃｒｉｐｔｉｏｎ：これは、任意のフィールドで、このセットアップアイテムに対する記述が、ＳｅｔｕｐＩｎｆｏにおける全体的記述と独立し、それに追加されるもので、且つユーザに付加的に提示されることを指定する。このフラグが存在しないか又は偽である場合には、記述がユーザに提示されない。
ｓｅｔｕｐＩｎｆｏＩｄ：これは、必須のフィールドで、装置に対するアプリケーション設定変更を独特に識別する。
ｄｅｓｃｒｉｐｔｉｏｎ：これは、ソフトウェア変更を記述する任意のフィールドである。
【０１６０】
ＳｅｔｕｐＣｏｍｍａｎｄ構造は、セットアップコマンドをソフトウェア変更の一部分として送信するのに使用される。ＳｅｔｕｐＣｏｍｍａｎｄ構造及びそれに対応するデータメンバーの一例を以下に示す。
ｓｅｔｕｐＴｙｐｅ：これは、必須フィールドであり、定数ＩＮＳＴＡＬＬ＝１、ＵＰＤＡＴＥ＝２、及びＵＮＩＮＳＴＡＬＬ＝３、のうちの１つを含む。
ｉｔｅｍＲｅｆ：これは、必須のフィールドである。ＳｅｔｕｐＣｏｍｍａｎｄアレーにおけるＳｅｔｕｐＣｏｍｍａｎｄエレメントは、増加するアイテム参照番号でマークされる。このアイテム参照は、あるファンクションでは、アレーから１つのＳｅｔｕｐＣｏｍｍａｎｄエレメントを識別するのに使用される。
ＵＲＬ：ダウンロードすべきセットアップコマンド又はファイルに対してＵＲＬを指定する任意のフィールドである。このフィールドは、通常、デフォールトによりセットされる。しかしながら、あるプラットホームでは、アンインストールのためにダウンロードする必要のあるソフトウェアはない。
ＣＲＣＳｔｒ：これは、任意のフィールドで、ＣＲＣ−３２チェック和情報を含む。ＣＲＣは、ＣＲＣに基づくソフトウェアダウンロードをキャッシュ記憶するために装置により使用されてもよいし、又はダウンロードされたファイルが壊れたかどうかチェックするために使用されてもよい。
ｐｒｏｇｒａｍＩｄ：これは、必須のフィールドであり、セットアップされているアプリケーションプログラムを独特に識別するＩＤを含む。
ＮａｍｅＶａｌｕｅＰａｉｒｓ：これは、任意のフィールドであり、ＮａｍｅＶａｌｕｅＰａｉｒデータ構造を指定する。
【０１６１】
ＮａｍｅＶａｌｕｅＰａｉｒ構造は、ＳｅｔｕｐＣｏｍｍａｎｄ構造の一部分として使用される。ＮａｍｅＶａｌｕｅＰａｉｒ構造は、ネーム／バリュー対パラメータを指定するのに使用される。これらのパラメータは、このインストールに対して特定であり、例えば、特定のソフトウェア及び／又は装置タイプに必要とされるコマンドラインパラメータのような情報を搬送するのに使用される。
【０１６２】
ＡｐｐＥｘＲｅｓｕｌｔ構造は、メソッド要求の結果を返送するのに使用される。これは、アプリケーション交換に関する情報を含む。
データメンバー：
ＳｅｔｕｐＩｎｆｏ：これは、任意のフィールドで、アプリケーションセットアップ情報を装置へ返送するのに使用される。このフィールドは、装置がｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅをコールするときだけ返送される。
ＳｅｔｕｐＣｏｍｍａｎｄ：これは、任意のフィールドで、アプリケーション変更（インストール、更新、又はアンインストール）に関連したセットアップコマンドを返送するのに使用される。このフィールドは、装置がｉｎｉｔｉａｔｅＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓをコールするときに返送される。
ｒｅｓｕｌｔ：これは、必須のフィールドで、アプリケーション変更メソッド要求の結果を含む。
【０１６３】
アプリケーション交換ファンクション
この章は、装置とサーバーとの間でのアプリケーションの交換を遂行するのに使用されるファンクションを説明する。ＡｐｐＥｘファンクションは、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓ、ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓ、ｉｎｉｔｉａｔｅＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓ、ｄｅｖｉｃｅＳｅｔｕｐＳｔａｒｔｓ、ｄｅｖｉｃｅＳｅｔｕｐＥｎｄ、ａｐｐｌｉｃａｔｉｏｎＩｎｓｔａｌｌｅｄ、ａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＴｅｓｔ、ａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＧｏ、及びｉｎｉｔＲｅｆｒｅｓｈを含む。あるファンクションは、エラーコードをサーバーへ送信することができる。一実施形態では、エラーコードは、以下のテーブル５に定義される。
テーブル５
【０１６４】
ＥＲＲ＿ＣＡＮＴ＿ＤＯＷＮＬＯＡＤ＿ＦＩＬＥ又はＥＲＲ＿ＲＡＮ＿ＯＵＴ＿ＯＦ＿ＤＩＳＫＳＰＡＣＥのような装置ローカルエラーについては、装置は、エラーをサーバーへ報告する前に、エラーを固定するための全ての考えられるステップを試みる（例えば、インターネット接続をチェックしたりハードドライブをクリーンアップしたりするようにユーザに頼む）ことに注意されたい。装置が現在ソフトウェア変更の問題を報告するためにエラーコードを送信するときには、サーバーが装置をディスエイブルする。
【０１６５】
ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓは、装置が始動するたびに使用され、装置に知られた現在ソフトウェアアンカーを送信する。装置が保留中アンカーを有するときには、その保留中アンカーをサーバーにも送信する。或いは又、装置が保留中アンカーをもたないときには、保留中アンカーがサーバーへ送信されない。サーバーは、受け取ったアンカーを、サーバーに記憶されたアンカーと比較し、装置及びサーバーが同期ずれしているかどうか決定する。
AppExResult checkSyncAnchors (String anchor, StringpendingAnchor)
リターン：アンカーが一致するときには結果が２００であり、アンカーが不一致のときには結果が４１７であるようなＡｐｐＥｘＲｅｓｕｌｔのインスタンス
【０１６６】
ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓメソッドは、装置に利用できる全アプリケーション更新のリストに関する情報を返送する。
AppExResult getApplicationUpdates (String anchor)
リターン：ソフトウェア変更が利用できるときにＳｅｔｕｐＩｎｆｏ構造を含むＡｐｐＥｘＲｅｓｕｌｔのインスタンス。さもなければ、ＳｅｔｕｐＩｎｆｏメンバーはセットされない。
パラメータ：
・ａｎｃｈｏｒ−装置は、新たなアンカーを送信する。
【０１６７】
ｉｎｉｔｉａｔｅＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓメソッドは、サーバーからインストラクションのリストを得て、アプリケーション変更（インストール、更新、又はアンインストール）プロセスをスタートするために、装置により呼び出される。サーバーにより返送される情報は、ダウンロードされるべきファイルと、装置上で実行されるべきコマンドとを含む。装置は、返送されたセットアップコマンドに載せられた順序でアプリケーション変更コマンドを実行する。
AppExResult initiateApplicationUpdates (String[] setupInfoIds)
リターン：ＳｅｔｕｐＣｏｍｍａｎｄアレーを含むＡｐｐＥｘＲｅｓｕｌｔのインスタンス。
パラメータ：ｓｅｔｕｐＩｎｆｏＩｄｓ−パラメータとして、装置は、ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓ応答からｓｅｔｕｐＩｎｆｏＩｄｓを送信する。
【０１６８】
ｄｅｖｉｃｅＳｅｔｕｐＳｔａｒｔｓメソッドは、装置においてアプリケーションセットアップがスタートしたことをサーバーに通知する。これは、変更されているソフトウェアに関連した全ての古いサービスをサーバーが無効化できるようにする。他方、装置がアプリケーション更新プロセスを開始した後であって且つこのファンクションコールの前に新たなアプリケーション更新がサーバーにおいて追加された場合には、サーバーは、新たなアプリケーション更新が存在することを指示するエラーコード３０１を返送する。これが生じると、装置は、アプリケーション更新プロセスを再スタートする。
AppExResult deviceSetupStarts()
リターン：装置がＡｐｐＥｘプロセスを再スタートすることを指示するために結果コード３０１を発生するＡｐｐＥｘＲｅｓｕｌｔのインスタンス。
【０１６９】
装置は、このメソッドを要求することを試み、そしてサーバーから応答が返送されないときには、要求がサーバーにより受け取られたかどうか、又はサーバーからの応答が失われたかどうか分らない。この場合には、装置は、このメソッドに対して新たな要求で試みる。これは、応答が失われた場合には４２０エラーコードを生じさせることに注意されたい。
【０１７０】
ｄｅｖｉｃｅＳｅｔｕｐＥｎｄメソッドは、装置におけるアプリケーションセットアップが完了したことをサーバーに通知する。サーバーは、更なるソフトウェア変更がサーバーにおいてその間にスケジュールされたかどうかチェックし、そして必要に応じて新たな通知を送出する。
AppExResult deviceSetupEnds (String anchor, int itemRef, int errorCode, StringerrorMsg)
パラメータ：
・ａｎｃｈｏｒ−装置は、現在インストールされたソフトウェアを表わす新たなアンカーを送信する。
・ｉｔｅｍＲｅｆ：このパラメータは、２つの方法で使用される。
第１に、ｉｔｅｍＲｅｆは、位置“Ｎ”のコマンド、及びセットアップコマンドアレーにおいてその位置“Ｎ”より低い他の全てのコマンドは成功であり、そして他の全てのコマンドは実行されないことを指定する。
第２に、ｉｔｅｍＲｅｆは、ｉｔｅｍＲｅｆにより指定された位置、例えば、“Ｍ”におけるコマンドに対するセットアップが失敗し、“Ｍ”より低いオフセットをもつ他の全てのコマンドが成功であり、そして“Ｍ”より大きなオフセットをもつ全てのコマンドが実行されないことを指示する。
・ｅｒｒｏｒＣｏｄｅ−エラーの場合に、エラーの原因がここにリストされる。さもなければ、“ＯＫ”コードが返送される。
・ｅｒｒｏｒＭｓｇ−このパラメータは、詳細なエラーメッセージを指定する。成功の場合には、このフィールドは、ナルである。
リターン：ＡｐｐＥｘＲｅｓｕｌｔのインスタント
【０１７１】
このメソッドは、通常のオペレーションのもとでコールされる。現在ＡｐｐＥｘプロセスが、ＡｐｐＥｘコードを含むプログラムをアンインストールする場合には、装置は、アンインストールをスタートする直前にこのメソッドをコールする。
【０１７２】
ａｐｐｌｉｃａｔｉｏｎＩｎｓｔａｌｌｅｄメソッドは、アプリケーションがインストールされ又は更新されたことをサーバーに通知する。これは、ＲＥｘ ＡＰＩ又はＳｅｔＥｘ ＡＰＩを使用して装置とサーバーとの間でデータを同期する各アプリケーションに対して必須である。このメソッドの主たる使用は、プログラム更新のためである。サーバーは、このメソッドをコールして、更新されたソフトウェアにより使用される設定をアクチベートする。
AppExResult ApplicationInstalled(String programId, int errorCode, String errorMsg)
パラメータ：
・ｐｒｏｇｒａｍＩｄ−サーバー側でアプリケーションサービスを独特に識別する
・ｅｒｒｏｒＣｏｄｅ−エラーの場合には、エラーの原因がここにリストされる。さもなければ、ＯＫコードが返送される。
・ｅｒｒｏｒＭｓｇ−詳細なエラーメッセージを指定する。首尾良いアプリケーションインストールの場合には、このフィールドがナルである。
リターン：ＡｐｐＥｘＲｅｓｕｌｔのインスタンス
【０１７３】
ａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＴｅｓｔメソッドは、あるテストを行なって、それが正しく働くかどうかチェックすることを希望する旨、サーバーに通知する。サーバーは、このメソッドを使用して、あるテストデータをアクチベートする。
AppExResult ApplicationReadyToTest (String programId, int errorCode, String errorMsg)
パラメータ
・ｐｒｏｇｒａｍＩｄ−サーバー側のアプリケーションサービスを独特に識別する
・ｅｏｏｒＣｏｄｅ−エラーの場合、エラーの原因がここにリストされる。さもなければ、“ＯＫ”コードが返送される。
・ｅｒｒｏｒＭｓｇ−詳細なエラーメッセージを指定する。成功の場合、このフィールドは、ナルである。
リターン：ＡｐｐＥｘＲｅｓｕｌｔのインスタンス
【０１７４】
ａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＧｏメソッドは、使用の準備ができたことをサーバーに通知する。ａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＧｏメソッドをコールするには、ａｐｐｌｉｃａｔｉｏｎＩｎｓｔａｌｌｅｄ又はａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＴｅｓｔをコールする各プログラムが必要とされる。
AppExResult ApplicationReadyToGo (String programId, int errorCode, String errorMsg)
パラメータ
・ｐｒｏｇｒａｍＩｄ−サーバー側のアプリケーションサービスを独特に識別する
・ｅｏｏｒＣｏｄｅ−エラーの場合、エラーの原因がここにリストされる。さもなければ、“ＯＫ”コードが返送される。
・ｅｒｒｏｒＭｓｇ−詳細なエラーメッセージを指定する。成功の場合、このフィールドは、ナルである。
リターン：ＡｐｐＥｘＲｅｓｕｌｔのインスタンス
【０１７５】
ｉｎｉｔＲｅｆｒｅｓｈメソッドは、装置が、装置において全てのソフトウェアを再インストールしたいことをサーバーに通知するときに、使用される。サーバーは、この要求を受け取ると、装置にあってもよい全てのソフトウェアをインストールのためにマークする。装置は、このコールに対して首尾良い応答を受け取ると、完全なＡｐｐＥｘプロセスを遂行して、コマンドを検索する。
AppExResult initRefresh()
リターン：ＡｐｐＥｘＲｅｓｕｌｔのインスタンス
【０１７６】
サーバーは、装置に対するソフトウェア変更を有するときに通知を送信する。装置がｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓをコールするときに、サーバーは、装置が通知を受け取ったと仮定し、そしてサーバー側の通知をクリアする。これは、ユーザがソフトウェアの変更を延期する場合及び装置が再スタートされる場合の両方に装置がｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓの結果を永続的なものにすることを意味する。装置は、ＡｐｐＥｘプロセスの中間で通知を受け取ると、その通知を無視することができる。装置がｄｅｖｉｃｅＳｅｔｕｐＥｎｄをコールしてＡｐｐＥｘプロセスを終了すると、サーバーは、更なるソフトウェア変更が存在するかどうかチェックし、そして必要に応じて新たな通知を送出する。
【０１７７】
アプリケーション交換状態コード
設定交換において、装置がゾンビモードにあるときに状態コード３００が返送される。この場合には、装置は、最初に、装置プロビジョニングプロトコルを使用して装置タイプ識別を送信し、ゾンビモードを出る。
【０１７８】
ｄｅｖｉｃｅＳｅｔｕｐＳｔａｒｔｓメソッドへのコールは、装置がｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓをコールすることにより全ＡｐｐＥｘプロセスを始めからスタートするように強制する３０１結果コードを返送することができる。ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓに対する要求は、ソフトウェア変更が存在するかどうかサーバーが現在決定できないときに３０２結果コードを返送することができる。これは、サーバーが、ａｐｐｌｉｃａｔｉｏｎＩｎｓｔａｌｌｅｄ及び／又はａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＧｏをコールするために、新たにインストール又は更新されたソフトウェアプログラムを待機するときに生じることがある。この場合、装置は、遅延を増加しながら要求を後で数回再試みする。数回の再試みの後に、サーバーが、依然、３０２状態コードで応答する場合には、装置は、全ＡｐｐＥｘプロセスを終了し、次の通知を単に待機することになる。
【０１７９】
ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓメソッドへのコールは、装置上のソフトウェアと、サーバーが装置上にあると考えているソフトウェアとが異なるものであることを指示する４１７結果コードを返送することができる。サーバーへの各コールは、エラーコード５００を生じさせる。これは、サーバーがこのとき何らかの理由で装置コールに応答できないことを指示する一時的サーバーエラーである。データコンテンツは、サーバーにより検査されず、従って、間違っているとは考えられない。クライアントは、前記のように、同じインターバルを使用して同じ要求を再試みする。所与の回数の再試みの後に、クライアントは、再試みを終了し、そして通知又はポーリング時間切れといった次の通常の同期事象を待機する。
【０１８０】
ソフトウェア同期アンカー
ソフトウェア同期アンカーは、装置上のソフトウェアが、サーバーが装置上にあると考えているソフトウェアとは異なるときを検出するのに使用される。これは、ユーザが全装置をバックアップするように試みるときに生じる。この状況では、装置上のソフトウェアは、装置がバックアップから回復する前にサーバーにより装置にインストールされたソフトウェアと適合しないことがある。
【０１８１】
装置及びサーバーは、両方とも、それらが始めに同期することを保証するために同じソフトウェア同期アンカー値に初期化される。装置は、同期アンカーを駆動する。装置は、ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅ又はｄｅｖｉｃｅＳｅｔｕｐＥｎｄをコールするたびに、新たなアンカーをサーバーへ送信し、サーバーは、そのアンカーを記憶する。装置は、コールに対する首尾良い応答をサーバーから受け取ると、現在アンカーを、サーバーへ送信された新たなアンカーに置き換える。ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅ又はｄｅｖｉｃｅＳｅｔｕｐＥｎｄへのコールが失敗すると、装置は、サーバーが要求を受け取って新たなアンカーを記憶したかどうか分らない。それ故、装置は、要求を再びコールするよう試みるときに保留中の新たなアンカーを再送信する。
【０１８２】
装置は、スタートするたびに、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒを使用してサーバーへ現在アンカーを送信する。装置は、ｄｅｖｉｃｅＳｅｔｕｐＥｎｄコールに対して首尾良い応答を得ていない保留中の新規なアンカーを有するときに、このアンカーをｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓコールへのパラメータとして送信する。サーバーは、送られたアンカー（又は送信されたアンカー）を、装置から受け取った最後のアンカーと比較する。アンカーが一致しないときには、装置は、ユーザへ問題を報告し、そしてｉｎｉｔＲｅｆｒｅｓｈをコールして、スクラッチから完全ソフトウェアインストールをスタートする。
【０１８３】
アプリケーション交換状態
サーバーは、ソフトウェアインストール、アンインストール又は更新プロセス中には、２つの状態の一方にある。図２４は、本発明の一実施形態によるアプリケーション交換状態遷移図である。装置が不法メソッドをコールすると、エラー状態は、サーバーが４２０状態コードをこのコールに対する応答として返送するようにさせる。その後、状態マシンは、その状態へ復帰し、そこからエラー状態へ移行する。
【０１８４】
エラー状態から出るために、装置は、ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅをコールし、そして全アプリケーション交換プロセスを再スタートする。これを行なうために、装置は、エラーコード（例えば、２００）で且つ−１をｉｔｅｍＲｅｆとして、ｄｅｖｉｃｅＳｅｔｕｐＥｎｄをコールする。次いで、以前に割り込まれたプロセスに対してクリーンな状態から新たなＡｐｐＥｘプロセスをスタートする。
【０１８５】
アプリケーション交換インストール及び更新
装置がＡｐｐＥｘを経てソフトウェアをインストールし又は更新するときに、インストール又は更新がフェイルすることがある。変更がセットアッププログラムにより完全にロールバックされていないときには（装置がクラッシュしたために）、ソフトウェアがもはや使用できないことがある。これは、装置上でＡｐｐＥｘを遂行するソフトウェアを装置が更新するよう試みる場合に重大となる。
【０１８６】
装置は、サーバーとのＡｐｐＥｘをまだ実行できる場合に、ｉｎｉｔＲｅｆｒｅｓｈメソッドを、次いで、ＡｐｐＥｘプロセスをコールして、装置上の全てのソフトウェアプログラムを（従って、壊れたソフトウェアプログラムも）再インストールするよう試みることができる。装置は、ＡｐｐＥｘプログラムをもはや実行できない場合には、ローダーを使用して、装置能力、例えば、装置タイプ識別情報を送信し、この場合も、ＵＲＬをリモートインストーラーへ配送する。このコールは、サーバー側で全てのソフトウェアプログラムが再インストールに対してマークされることを意味する。装置は、リモートインストーラーをインストールし、次いで、ＡｐｐＥｘを使用して、ソフトウェアプログラムを再インストールする。
【０１８７】
以上、明瞭化のために、異なる機能的ユニット及びプロセッサを参照して本発明の実施形態について説明されたことが明らかであろう。しかしながら、本発明から逸脱せずに、異なる機能的ユニット又はプロセッサ間に機能を適宜に分散させられることも明らかであろう。例えば、個別のプロセッサ又はコントローラにより遂行されるべき機能は、同じプロセッサ又はコントローラによって遂行されてもよい。従って、特定の機能的ユニットを参照することは、厳密な論理的又は物理的構造又は編成を表わすのではなく、前記機能を与える適当な手段を参照するに過ぎないことが明らかであろう。
【０１８８】
本発明は、ハードウェア、ソフトウェア、ファームウェア又はその組み合せを含む任意の適当な形態で実施することができる。又、本発明は、１つ以上のデータプロセッサ及び／又はデジタル信号プロセッサ上で実行されるコンピュータソフトウェアとして部分的に実施されるのも任意である。本発明の実施形態のエレメント及びコンポーネントは、任意の適当な仕方で物理的に、機能的に及び論理的に実施されてもよい。実際に、機能は、単一ユニットで実施されてもよいし、複数のユニットで実施されてもよいし、又は他の機能的ユニットの一部分として実施されてもよい。従って、本発明は、単一のユニットで実施されてもよく、又は異なるユニットとプロセッサとの間に物理的及び機能的に分散されてもよい。
【０１８９】
当業者であれば、同じ基本的なメカニズム及び方法を使用しながら、ここに開示された実施形態の多数の考えられる変更や組み合せも使用できることが明らかであろう。以上の説明は、例示の目的で特定の実施形態を参照して書かれたものであった。しかしながら、前記説明は、これに尽きるものでもないし、又、本発明をこれに限定するものでもない。前記教示に鑑み、多数の変更や修正が考えられる。前記実施形態は、本発明の原理及びそれらの実際の応用を説明すると共に、当業者が、本発明及び種々の実施形態を、意図された特定用途に適するように種々変更を加えて最良に利用できるようにするために、選択されて説明されたものである。
【技術分野】
【０００１】
本発明は、一般に、通信ネットワークにおいて１つ以上のユーザ装置にサービスを提供するための分野に係る。より詳細には、本発明は、ユーザ装置をプロビジョニングするためのシステム及び方法に係る。
【０００２】
関連出願へのクロスリファレンス：本願は、次の特許出願に関連している。Matthias Breuer氏等の“System and Method for Servicing a User Device”と題する米国特許出願第１１／１８２，３４８号（代理人整理番号３２４２１−２００１７００号）；Torsten Schulz氏等の“System and Method for Synchronizing between a User Divice and a Server in a Communication Network”と題する米国特許出願第１１／１８２，２０３号（代理人整理番号３２４２１−２００１８００号）；Venkatachary Srinivasan氏等の“An Alert Mechanism for Notifying Multiple User Devices Sharing a Connected-Data-Set”と題する米国特許出願第１１／１８３，１３７号（代理人整理番号３２４２１−２００２２００号）；Marco Boerris氏等の“Methods and Systems for Data Transfer and Notification Mechanisms”と題する米国特許出願第１１／１８２，６１４号（代理人整理番号３２４２１−２００２１．００号）；及びTorsten Schulz氏等の“Content Router”と題する米国特許出願第１１／１８２，２８７号（代理人整理番号３２４２１−２０００９００号）。これらは、参考としてここに全体を援用するものである。
【背景技術】
【０００３】
通信、情報管理及び再生成のための電子装置の近年の急増で、デスクに縛られたパーソナルコンピュータとはかけ離れた日常の計算力が得られるようになった。ユーザは、セルラー電話、カメラ電話、パーソナルデジタルアシスタント（ＰＤＡ）及びナビゲーションシステムのような装置を、オフィスや家庭だけではなく、田畑や道路でも使用している。このような装置には、通信、ビジネス、ナビゲーション、娯楽、及び毎日の基本的活動の管理を含む様々な範囲の用途が考えられる。多くのユーザは、今日、１つのタスクに１つの装置を使用するだけであり、例えば、セルラー電話を使用して電話コールを発信し受信する。しかしながら、これら装置は、もはや、単一機能の装置ではない。それらは、種々の形式のデータ、例えば、電子メール、音声メッセージ、写真、ビデオ、等を生成することができる。装置の機能数が増すにつれて、ユーザに対する個人化のレベルも高くなる。ユーザがどこにいようと、どんな装置を使用しようと、又、どんなサービスに接続しようと、それらのデータに接続しアクセスするための接続サービスをユーザに提供することが要望される。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
このような接続サービスをユーザに提供する課題の１つは、ユーザが移動装置を購入した後にその製品をプロビジョニングする必要性である。慣習的に、ユーザは、パーソナルコンピュータに接続されたクレードルを通して装置をプロビジョニングしなければならない。これは、通常、家庭やオフィスで行なわれる。プロビジョニング段階が終了するまで、ユーザは、移動装置を使用することができない。それ故、いつでもどこでも移動装置をプロビジョニングすることが要望される。
【０００５】
このような接続サービスをユーザに提供する別の課題は、ユーザが既に自分のＰＣ、ＰＤＡ、セルラー電話、又は他の装置に確立している設定及びデータのセットに１つ以上のユーザ装置を接続する必要性である。例えば、ユーザは、新たな装置を取得したときに、設定及びデータのセットを既存の装置から新たな装置へコピーする必要がある。又、ユーザは、既存の装置を修理し、又は設定及びデータのセットを置き換える必要もある。又、ユーザは、ユーザ装置を紛失したり、盗難にあったり又は一時的に置き忘れたりした場合に、ユーザ装置のサービスを終了させる必要もある。
【０００６】
このような接続サービスをユーザに提供する更に別の課題は、設定及びデータの共通セットを共有する１つ以上のユーザ装置に対する通信の状態をユーザに通知する必要性である。例えば、１つ以上のユーザ装置においてｅメール、タスク、カレンダー事象又はアドレスブックエントリーの記憶装置にオーバーフロー状態が生じたときにユーザに通知する必要がある。
【０００７】
このような接続サービスをユーザに提供する更に別の課題は、設定及びデータの共通セットを共有するサーバー及び１つ以上のユーザ装置間でデータの一貫性を維持する必要性である。例えば、サービスがサーバーにおいて、ある時間周期中、中断されたときには、サーバー及び１つ以上のユーザ装置間でデータの変更を同期させる必要がある。
【課題を解決するための手段】
【０００８】
一実施形態において、通信ネットワーク内で１つ以上のユーザ装置を接続するための複数のエントリーポイントを与えるシステムは、１つ以上のユーザ装置と通信するサーバーであって、このサーバーが接続データセットを含み、且つ１つ以上のユーザ装置が接続データセットの一部分を共有するようにしたサーバーを備えている。このシステムは、更に、複数のエントリーポイントの１つから接続データセットにアクセスする要求をユーザ装置から受け取るためのロジックと、ユーザ装置の属性を自動的に決定するためのロジックと、ユーザ装置の属性を使用して所定のクライアント装置のデータベースから通信メソッドを選択するためのロジックと、その通信メソッドに基づいてユーザ装置をプロビジョニングするためのロジックとを備えている。
【０００９】
別の実施形態において、通信ネットワーク内で１つ以上のユーザ装置を接続するための複数のエントリーポイントを与える方法は、１つ以上のユーザ装置と通信するサーバーを用意するステップであって、このサーバーが接続データセットを含み、且つ１つ以上のユーザ装置が接続データセットの一部分を共有するようにしたステップと、複数のエントリーポイントの１つから接続データセットにアクセスする要求をユーザ装置から受け取るステップと、ユーザ装置の属性を自動的に決定するステップと、ユーザ装置の属性を使用して所定のクライアント装置のデータベースから通信メソッドを選択するステップと、その通信メソッドに基づいてユーザ装置をプロビジョニングするステップとを備えている。
【００１０】
本発明の前記特徴及び効果、並びにその付加的な特徴及び効果は、添付図面を参照した本発明の実施形態の以下の詳細な説明読んだ後に更に明確に理解されよう。
【図面の簡単な説明】
【００１１】
【図１ａ】本発明の一実施形態による接続寿命サービスを示す図である。
【図１ｂ】本発明の一実施形態による図１ａの接続寿命サービスをサポートする接続寿命サーバーを示す図である。
【図２】本発明の一実施形態による接続寿命サーバーの装置マネージャーの実施例を示す図である。
【図３】本発明の一実施形態により未構成のアカウントグループをプロビジョニングするためのワークフローを示す図である。
【図４】本発明の一実施形態により前構成されたアカウントグループをプロビジョニングするためのワークフローを示す図である。
【図５】本発明の一実施形態により「マイクロソフトアウトルック」をプロビジョニングするワークフローを示す図である。
【図６】本発明の一実施形態により前インストールされたローダーを経て装置をプロビジョニングするワークフローを示す図である。
【図７】本発明の一実施形態によりウェブサイトを経て装置をプロビジョニングするワークフローを示す図である。
【図８】本発明の一実施形態により検証された電話番号でウェブサイトを経て装置をプロビジョニングするワークフローを示す図である。
【図９】本発明の一実施形態により検証された電話番号なしにウェブサイトを経て装置をプロビジョニングするワークフローを示す図である。
【図１０】本発明の一実施形態によりＡｃｔｉｖｅＸ装置に対してウェブサイトを経て装置をプロビジョニングするワークフローを示す図である。
【図１１】本発明の一実施形態によりクライアントソフトウェアを使用してウェブサイトを経て装置をプロビジョニングするワークフローを示す図である。
【図１２】本発明の一実施形態により装置の既存の同期スタックを使用してウェブサイトを経て装置をプロビジョニングするワークフローを示す図である。
【図１３】本発明の一実施形態によりＳＭＳを経て装置をプロビジョニングするワークフローを示す図である。
【図１４】本発明の一実施形態によりオンラインショップを経て装置をプロビジョニングするワークフローを示す図である。
【図１５】ＲＥｘプロトコルフローの概要を示す図である。
【図１６】異なるＲＥｘメソッドを使用してユーザ装置とサーバーとの間の対話を示すフローチャートである。
【図１７】本発明の一実施形態による問合せプロセスのシーケンス図である。
【図１８】本発明の一実施形態によりクライアント装置とサーバーとの間で同期をとるための同期アンカープロトコルを示す図である。
【図１９】本発明の一実施形態により装置が装置タイプ識別設定を交換するときのプロセスフロー図である。
【図２０】本発明の一実施形態によりゾンビ状態において装置タイプ識別以外の設定を装置が交換しようと試みるときのプロセスフロー図である。
【図２１】本発明の一実施形態による通常の設定交換のためのシーケンス図である。
【図２２】本発明の一実施形態によるダンプ設定のためのシーケンス図である。
【図２３】本発明の一実施形態による装置とサーバーとの間のアプリケーション交換プロセスフローを示すシーケンス図である。
【図２４】本発明の一実施形態によるアプリケーション交換状態遷移図である。
【発明を実施するための形態】
【００１２】
ユーザ装置をプロビジョニングするための方法及びシステムが提供される。以下の説明は、当業者が本発明を実施し利用できるようにするためのものである。特定の実施形態及び応用は、一例に過ぎない。当業者であれば、ここに述べる実施例の種々の変更及び組み合せが容易に明らかであり、又、ここに述べる一般的な原理は、本発明の精神及び範囲から逸脱せずに、他の実施例及び応用に適用することができよう。従って、本発明は、ここに図示して説明する実施例に限定されず、ここに開示する原理及び特徴との最も広い一貫性が与えられるべきである。
【００１３】
以下の詳細な説明の幾つかの部分は、コンピュータメモリ上で遂行できるデータビットに対するオペレーションの手順、ステップ、論理ブロック、処理、及び他の象徴的表現に関して表わされる。手順、コンピュータ実行ステップ、論理ブロック、プロセス、等は、ここでは、希望の結果を導くステップ又はインストラクションの自己一貫性シーケンスであると考えられる。ステップは、物理量の物理的操作を利用するものである。これらの量は、コンピュータシステムにおいて記憶、転送、合成、比較、その他、操作することのできる電気、磁気又は無線信号の形態をとることができる。これら信号は、しばしば、ビット、値、エレメント、記号、キャラクタ、項、数字、等と称される。各ステップは、ハードウェア、ソフトウェア、ファームウェア、又はその組み合せによって遂行することができる。
【００１４】
図１ａは、本発明の一実施形態による接続寿命サービス(connected-life service)を示す。この接続寿命サービスは、ユーザがそれらの接続データセット(connected-data-set)を任意の装置と共有していつどこからでもアクセスできるようにする。ユーザ装置（装置又はクライアントとも称される）は、セルラー電話、ワイヤレスパーソナルデジタルアシスタント、ナビゲーション装置、パーソナルコンピュータ、ゲームコンソール、インターネットターミナル、及びキオスクを含む。接続データセットは、ｅメール、連絡先、カレンダー、タスク、ノート、ピクチャー、ドキュメント、音楽、ビデオ、ブックマーク及びリンクを含む。
【００１５】
異なる実施形態において、接続寿命サービスは、次の機能を提供する。１）ユーザ装置を修理し、２）第１ユーザ装置を第２ユーザ装置へ複写し、３）第１ユーザ装置を第２ユーザ装置に置き換え、及び４）ユーザ装置のサービスを終了する。ユーザ装置を修理するサービスは、１つ以上のユーザ装置の状態をリセットし、１つ以上のユーザ装置の構成及び設定を回復し、そして接続データセットを１つ以上のユーザ装置へ回復させることを含む。
【００１６】
第１ユーザ装置を第２ユーザ装置へ複写するサービスは、第１ユーザ装置の構成及び設定を第２ユーザ装置へ転送し、そして接続データセットの一部分を第１ユーザ装置の設定に基づいて第２ユーザ装置へ転送することを含む。
【００１７】
第１ユーザ装置を第２ユーザ装置と置き換えるサービスは、所定の構成及び設定のセットを構成データベースから第２ユーザ装置へ転送し、ここで、第２ユーザ装置は、第１装置と同じモデル、メーク及びタイプを有するものであり、そして接続データセットの部分を第２ユーザ装置の設定に基づいて第２ユーザ装置へ転送することを含む。第１ユーザ装置を第２ユーザ装置と置き換えるサービスは、更に、所定の構成及び設定のセットを構成データベースから第２ユーザ装置へ転送し、ここで、第２ユーザ装置は、第１装置と異なるモデル、メーク及びタイプを有するものであり、そして接続データセットの部分を第２ユーザ装置の設定に基づいて第２ユーザ装置へ転送することを含む。
【００１８】
ユーザ装置のサービスを終了させるサービスは、ユーザ装置の構成及び設定を削除し、ユーザ装置への通信を終了し、そして他のユーザ装置へ終了状態を送信することを含む。装置の終了サービスは、装置からサービスを取り除くために適用されるだけでなく、「装置紛失」又は「装置盗難」の場合にも利用できることに注意されたい。このような場合には、ソフトウェア及び設定だけでなく、ユーザデータ（メール、アタッチメント、ＰＩＭ、写真、等）も、取り除くことができる。
【００１９】
更に、装置終了サービスの別の特徴は、装置の阻止である。この場合、ユーザは、装置を見つけられないが、装置を見つける機会がまだあると仮定すれば、それを紛失したか、単にどこかに置き忘れたか確実に分らない。この場合、このサービスは、ユーザから更に命令があるまで装置を阻止するか又は少なくとも装置へのデータサービスを一時的に阻止する能力をユーザに提供する。
【００２０】
図１ｂは、本発明の一実施形態による図１ａの接続寿命サービスをサポートする接続寿命サーバーを示す。接続寿命サーバー１００は、異なる地理的位置にある１つ以上のコンピュータ／サーバーにより実施される。接続寿命サーバーは、ユーザがデータを生成し又は記憶する異なるコンピューティング装置（パーソナルコンピュータ１０２及び１０４、移動装置１０６、サーバー１０８、並びにウェブポータル１１０及び１１２を含む）の間で接続データセットを管理する。
【００２１】
図２は、本発明の一実施形態による接続寿命サーバーの装置マネージャーの実施例を示す。装置マネージャー２００は、ウェブフロントエンド２０２と、装置コントローラ２０４と、装置記述記憶装置２０６と、１セットのプロトコルアダプタ２０８とを備えている。装置マネージャーは、プロトコルアダプタ２０８を通してユーザ装置２１０と通信し、それを管理する。更に、装置マネージャーは、ユーザマネージメントユニット２１２及びスマートコンテンツルーティングユニット２１４を通して接続寿命サーバーの他の部分と通信する。ユーザマネージメントユニットは、異なるサービスからユーザ装置を管理するのに使用されることに注意されたい。このユニットは、全てのユーザが、ＳＢＣ−Ｙａｈｏｏ ＤＳＬサービスのような同じインターネットサービスプロバイダーからのものである場合には、任意である。
【００２２】
装置コントローラ２０４は、更に、ソフトウェアマネージメントユニット２１６、サービスマネージャー２１８、設定変更ディスパッチャー２２０、及び装置状態記憶装置２２２を備えている。ソフトウェアマネージメントユニット２１６は、ユーザ装置に対するレコード、設定及びアプリケーションをインストールし、更新し、そしてデインストールする。サービスマネージャー２１８は、ユーザ装置に対してサポートされるサービスのタイプを管理する。サービスマネージャーは、ユーザ装置及び接続寿命サーバーの間で接続データセットを転送するためにスマートコンテンツルーティングユニット２１４へ情報を与える。設定変更ディスパッチャー２２０は、装置設定の変更を装置マネージャーからユーザ装置へ与える。装置状態記憶装置２２２は、ユーザ装置のオペレーティング状態に関する情報を記憶する。
【００２３】
装置記述記憶装置２０６は、接続寿命サービスによりサポートされるユーザ装置２１０のタイプ記述２２４、トランスコーディング２２６、アカウントテンプレート２２８、及びサービス記述２３０を記憶する。装置マネージャーは、このような装置情報を装置記述記憶装置２０６とファイルサーバー２３０との間で転送する。装置マネージャーは、ユーザ装置を、タイプ記述、トランスコーディング、アカウントテンプレート、及びサービス記述の異なる組み合せに関連付けて、ユーザ装置の所定のグループに対して各組み合せをテストし検証できるようにする。その結果、異なるサービスラインがそれに対応する装置特徴を含み、そしてサービスを、異なるユーザグループに提供することができる。
【００２４】
プロトコルアダプタ２０８は、プロビジョニングユニット２３２、レコード交換ユニット２３４、設定交換ユニット２３６、アプリケーション交換ユニット２３８、ＳｙｎｃＭＬユニット２４０、及び他のアダプタユニット２４２を備えている。上述した機能的ユニット（即ち、論理的ブロック２００−２４４）は、ソフトウェア、ハードウェア、或いはソフトウェアとハードウェアの組み合せで実施できることに注意されたい。機能的ユニット間の相互作用については、次の章で詳細に述べる。
【００２５】
ユーザ装置のプロビジョニング
一般的に、消費者が接続寿命サービスに契約できる方法は２つある。１）アカウントを登録し、その後、装置のプロビジョニングを行なう。２）装置を登録し、従って、接続寿命サービスアカウントの登録が手順に含まれる（まだアクティブでない場合）。
【００２６】
２つの選択肢のうち、ユーザが接続寿命サービスに契約したときには、最初に、アカウントを登録する。接続寿命サービスは、顧客のアカウントを維持するサービスプロバイダーを通して提供される。これは、ｅメールアカウント、ＰＩＭ記憶及び管理ファシリティ、並びに「ブリーフケース」機能、即ち写真や音楽やドキュメントや他のデータのようなユーザの他のファイルの記憶、を含むが、これらに限定されない。
【００２７】
ユーザは、接続寿命サービスにより提供されるサービスについて登録するときに、それらを提供するサービスプロバイダーの既に登録された顧客としてこれを行なう。従って、接続寿命サービスの利用に対して可能となるアカウントを既に有する。アカウントのプロビジョニングの実施については、以下で述べる。次の章が含まれる。
−アカウントグループ
この章は、異なるアカウントグループ又はアカウントタイプについて述べる。異なるアカウントプロビジョニング利用ケースを理解するためには、このグループを知る必要がある。
−利用ケース
３つのアカウントプロビジョニング利用ケースがある。その各々を次の章で述べる。
【００２８】
又、ユーザは、最初にそれらの装置を登録することによりアカウントを登録するオプションを有する。ここでは、装置プロビジョニングプロセスの一部分として、アカウントが自動的に生成される。
【００２９】
アカウントグループ
ユーザアカウントは、グループ編成することができる。各アカウントグループは、２つ以上の方法を使用してプロビジョニングすることができる。テーブル１は、接続寿命サービスによりサポートされるサンプルアカウントグループを示す。
テーブル１
【００３０】
利用ケース
アカウントグループは、接続寿命サービスに対して３つの異なる仕方でプロビジョニングすることができる。これらの利用ケースは、次の章で説明する。
１）未構成のアカウントグループをプロビジョニングする
ここでは、ユーザが登録するアカウントの詳細は、そのほとんどの部分について、接続寿命サーバー（ＣＬＳ）には分らない。それ故、ユーザは、これらの詳細を手動で入力し、従って、経験のあるユーザについてのみ意図される。
２）前構成されたアカウントグループをプロビジョニングする
アカウントグループの技術的仕様がＣＬＳに予め分るときには、アカウントのプロビジョニングは、最小限のユーザ努力しか必要としない容易な形態で行うことができる。
３）マイクロソフトアウトルックをプロビジョニングする
自分のＰＣに位置されたアカウントをもつことを希望するユーザについては、マイクロソフトアウトルックアプリケーションを使用する。
【００３１】
未構成のアカウントグループをプロビジョニングするための必須条件は、ユーザがアウトルックリディレクタ以外のアカウントグループからのアカウントを既に有していることである。適用可能なアカウントグループは、交換、ＷｅｂＤＡＶ、ＩＭＡＰ及びＰＯＰ３である。この利用ケースにおいて、ユーザは、アカウント／データソースを登録するために、ＣＬＳにより要求される全ての情報を特定する。これは、アカウントユーザ名及びパスワードのような通常のパラメータと、サーバーの名前及びそれらの各々のポート番号とを含む。
【００３２】
これは、全部で３つの利用ケースの中で最も複雑であり、それ故、経験のあるユーザにしか推奨されない。これは、サービスプロバイダーがこれらデータソースパラメータを知らないとき、例えば、サービスプロバイダー以外のデータソースに接続することをユーザに提示する場合だけ、実施される。
【００３３】
図３は、本発明の一実施形態により未構成のアカウントグループをプロビジョニングするためのワークフローを示す。ユーザは、１）サービスプロバイダーのウェブサイトにログオンし、２）適当なアカウントグループを選択し、３）アカウントのための全ての必要なパラメータを入力する。これらのステップが完了すると、ＣＬＳは、アカウントを生成する。
【００３４】
図４は、本発明の一実施形態により前構成されたアカウントグループをプロビジョニングするためのワークフローを示す。前構成されたアカウントグループをプロビジョニングするための必須条件は、ユーザがアウトルックリディレクタ以外のアカウントグループからのアカウントを既に有していることである。適用可能なアカウントグループは、サービスプロバイダーにより提供されるものである。この利用ケースは、ユーザが登録を選択する前にアカウント仕様のほとんどを知ることに基づく。第１の利用ケースとは対照的に、これは、前構成されたアカウントグループのプロビジョニングを含む。即ち、アカウントの仕様のほとんどが接続寿命サーバーに既に知られており、ユーザは、アカウントを登録するためにサービスプロバイダーに対する証明書を単に入力するだけである。サーバー名、ポート番号、等の仕様は、タイプインする必要がない。
【００３５】
これは、アカウントをプロビジョニングする簡単な仕方である。ユーザは、「はい、このサービスへの契約を希望します」と簡単に答えるだけでよく、その他は、接続寿命サービスにより取り扱われる。ユーザは、それらのサービスプロバイダーでログオンした後、接続寿命サービスに登録したいアカウントを選択する。
【００３６】
図５は、本発明の一実施形態により「マイクロソフトアウトルック」をプロビジョニングするワークフローを示す。マイクロソフトアウトルックをプロビジョニングするための必須条件は、ユーザが自分のＰＣにマイクロソフトアウトルックをインストールすることである。適用可能なアカウントグループは、アウトルックリディレクタである。
【００３７】
このオプションでは、ユーザは、自分のパーソナルコンピュータにデータソースとしてマイクロソフトアウトルックアプリケーションをもつよう選択できる。アカウントがサービスプロバイダーのサーバーに位置された利用ケースＩ及びIIとは対照的に、マイクロソフトアウトルックアカウントのプロビジョニングは、それがユーザ自身のＰＣにローカル配置されることを意味する。
【００３８】
この方法を使用して、ユーザは、それらの交換、ＩＭＡＰ、又はＰＯＰアカウントを、接続寿命サービスアカウントとして依然もつことができるが、ＣＬＳは、マイクロソフトアウトルックに接続され、プロバイダーサーバー（１つ又は複数）には接続されない。これは、アウトルックの“．ｐｓｔ”ファイルのローカル記憶データに接続されるか、或いは交換アカウントに接続するのにアウトルックが使用される場合には、交換プロフィールに接続され、そしてそれを通して、交換サーバーに接続される。後者のシナリオは、ＣＬＳと交換サーバーとの間のファイアウオールの問題を克服するのに使用できる。
【００３９】
マイクロソフトアウトルックのプロビジョニングは、ユーザのＰＣにアウトルックリディレクタをインストールすることを意味する。リディレクタは、アウトルックの“．ｐｓｔ”ファイル／交換プロフィールと、接続寿命サーバーとの間の仲介手段として働く。アウトルックは、アカウントからデータが供給される装置としてプロビジョニングできることにも注意されたい。装置をどのようにプロビジョニングするかの詳細は、以下の章で述べる。
【００４０】
図５は、本発明の一実施形態によりアウトルックをデータソースとして登録するためのワークフローを示す。アウトルックをデータソースとして登録するためのワークフローは、次の通りである。
１．ユーザは、サービスプロバイダーのウェブサイトにログオンする。
２．ユーザは、アウトルックリディレクタアカウントグループを選択する。
３．ローダーがＰＣにインストールされる。
４．ユーザは、ＰＣに対するユーザ名及びパスワードを入力する。
５．アカウントがアクチベートされ、そしてクライアントソフトウェアがインストールされる。
【００４１】
ユーザは、それらのアカウントの登録を完了した後に装置をプロビジョニングすることができる。或いは又、接続寿命サービスは、それらの装置及びアカウントを同時に登録する（ユーザの観点から）可能性をユーザに与える。その目的は、プロビジョニングプロセスをできるだけ容易に且つ簡単にすることである。プロビジョニングの終りに、ユーザは、アカウントのデータがそれらの装置に接続された状態で去る。装置プロビジョニングプロセスには少なくとも４つのエントリーポイントがある。
１．ユーザは、ローダーソフトウェアを受け取る。
２．ユーザは、ウェブサイトを経てエントリーする。ユーザがサービスプロバイダーのウェブサイトにログオンするか、或いはセールスアシスタント又は顧客サービス代表者（ＣＳＲ）がユーザに代わってユーザを登録する（電話により店に）。
３．ユーザは、サービスプロバイダーにより指定された番号へＳＭＳを送信する。
４．ユーザは、プロバイダーのオンラインショップにログオンする。
【００４２】
更に、ユーザは、装置がそのデータの全部又は一部分を失うか、又はユーザが装置を紛失し、同じタイプの別の装置と交換する場合には、それらの装置を回復させるよう選択することができる。これらのシナリオは、全て、顧客が、接続寿命サービスを提供するサービスプロバイダーに既に登録されたユーザであると仮定している。又、ユーザが接続寿命サービスにまだ登録していない場合には、前構成されたアカウントグループをプロビジョニングするための利用ケースIIに基づいて登録される。
【００４３】
図６は、本発明の一実施形態により前インストールされたローダーを経て装置をプロビジョニングするワークフローを示す。ユーザが接続寿命サービスに対して自分の装置を登録する１つの仕方は、自分の装置にローダーアプリケーションをインストールすることによるものである。ローダーは、装置のプロビジョニング及びクライアントソフトウェアのインストールを容易にするアプリケーションである。
【００４４】
ローダーは、種々の仕方、即ちダウンロード、ＣＤ−ＲＯＭ、ＳＤ又は他のメモリカードを経て、或いはローダーを装置に送信する他の方法で、ユーザに利用できるようにされる。ローダーは、特定の装置タイプに対して表示される（バージョン番号で）。従って、装置が登録のためにＣＬＳに接続されるときには、サーバーは、装置のタイプや、クライアントソフトウェアをインストールする必要があるかどうかが自動的に分る。予めインストールされたローダーを経て装置をプロビジョニングするためのステップは、次の通りである。
１．ローダーが装置においてスタートする。
２．ローダーがサービスプロバイダーログオンスクリーンを表示する。
３．ユーザは、それらのアカウントのユーザ名、パスワード、及びそれらの装置の名前（例えば、Ｍｙ Ｐｈｏｎｅ）を入力する。
４．ユーザがまだサービスプロバイダーの顧客ではない場合には、プロバイダーに連絡するようユーザに求めるメッセージが表示される。
５．ユーザがまだ接続寿命サービスに契約しない場合には、それらのアカウントが自動的にアクチベートされる。
６．ユーザがそれらのアカウント証明書を与えると、ローダーは、予め決定されたサービス（交換されるデータタイプのような）及びデフォールトフィルタで構成されたクライアントソフトウェアをダウンロードする。ダウンロードは、オーバー・ジ・エア(over-the-air)でもよいし、ＰＣ接続によるものでもよいし、或いは単にローカルメモリカードから転送されてもよい。
７．ＣＬＳが装置においてサービスをアクチベートする。装置から既存のデータをインポートし（デフォールトオペレーション）、そして装置をアカウントへ接続する。アカウントにおけるレコードに必要な複写処理を遂行した後に、そこから装置へレコードを送信する。
これで、装置は、プロビジョニングされ、データを交換する準備ができる。
【００４５】
図７は、本発明の一実施形態によりウェブサイトを経て装置をプロビジョニングするワークフローを示す。このシナリオでは、ユーザは、ウェブブラウザを使用して、接続寿命サービスに対してそれらの装置を登録する。これは、次のいずれかである。
−顧客に利用可能なサービスプロバイダーのウェブサイトを経て直接的に。ユーザは、ログインする。
−ＣＳＲを経て。典型的なシナリオは、ユーザがサービス／セールスホットラインにコールし、又はユーザがサービスプロバイダーの店の１つを訪問することを含み、ここで、セールスアシスタントが顧客に代わって顧客を登録するように進行する。
【００４６】
ウェブブラウザを使用して装置をプロビジョニングする段階は、次の２つがある。１）装置を前プロビジョニングし、２）装置をプロビジョニングする。プロビジョニングプロセスを開始する前に、ＣＬＳは、どんな種類の装置がプロビジョニングされ、そしてそれが現在どのように（ＰＣを経て、ワイヤレスで）接続されるか決定する。又、プロビジョニングが新しいものであるかどうか、又はユーザが装置の回復を希望するかどうかも分る。装置の回復が必要であるのは、それを紛失し新しいものに置き換えるとき、ハードリセットされてそのプログラム及びデータを失ったとき、又は別の仕方でデータを失ったときである。
【００４７】
装置がＣＬＳとで交換するタイプのデータを失った場合も、装置が以前の構成へバックアップされた場合も、装置の回復は必要でない。前者のケースでは、通常のデータ交換が行なわれ、失われたデータは、アカウントから検索される。後者のケースでは、装置をアカウントの現在状態へ戻すために低速同期が開始される。換言すれば、クライアントソフトウェアが削除された場合には、復帰が要求される。サーバーは、当該装置から全てのデータを要求し、全てのレコードをインベントリと比較して不一致を識別し、インベントリからのレコードで装置を更新する。装置の復帰は、プッシュ装置には適用されないことに注意されたい。
【００４８】
サーバーがユーザ装置と同期せず且つサーバー側インベントリのバックアップが回復された場合には、サーバー側インベントリのバックアップが行われるたびに装置にチェックポイントマーカー（例えば、タイムスタンプ）を保持することにより低速同期プロセスを最適化することができる。これは、サーバーが、チェックポイントマーカーの後に変化したレコードを比較するだけでよくする。この方法は、ユーザ装置へ転送する必要のあるデータの量を減少させる。従って、低速同期プロセスの時間巾を短縮し且つその送信帯域巾の使用を軽減する。
【００４９】
プロビジョニングプロセスそれ自体は、登録される装置のタイプに依存する。この点に関して、これは、次の５つのカテゴリーに入る。
１．検証された電話番号をもつプッシュ装置
２．検証された電話番号をもたないプッシュ装置
３．ＡｃｔｉｖｅＸ−イネーブル装置
４．クライアントソフトウェアを使用する装置
５．自身の同期スタックを使用する装置
これらのプロセスは、以下の章で詳細に説明する。
【００５０】
ウェブサイトを経て装置を前プロビジョニングするステップは、次の通りである。
１．ユーザがウェブサイトを通してそれらの装置のプロビジョニングをスタートできる仕方は、多数ある。ユーザは、サービスプロバイダーのコールセンターをコールするか、それらの店の１つを訪問するか、又はそれらのウェブサイトを直接的にブラウズすることができる。全てのケースにおいて、プロビジョニングは、ウェブを経て遂行される。
２．ユーザがローダーをインストールする第１の利用ケースと同様に、ユーザがまだ接続寿命サービスアカウントを有していない場合には、これが自動的に生成される。
３．装置が回復される（例えば、ハードリセットにより）場合には、装置は、装置カテゴリーに基づいてプロビジョニングされる。
４．前プロビジョニングプロセスの残り部分は、装置がＣＬＳによりどのように検出されるかに依存し、これは、装置が現在どのように接続されるかに多くの仕方で関係している。図７は、次の３つの可能性を示している。
ａ．ユーザが装置を使用してブラウジングする
このケースでは、ＣＬＳは、装置のタイプを検出し、そしてユーザをローダーダウンロードページへ向けることができる。次いで、ローダーは、ユーザによりスタートされ、プロビジョニングプロセスが、図４に示すように続けられる。
ｂ．装置のタイプがＰＣ接続を経て検出される（又は装置がＰＣである）
ここでは、装置がＰＣに接続されるか、又はプロビジョニングされている装置がＰＣそれ自体である。アドミニストレーションアプリケーションは、ＡｃｔｉｖｅＸ制御を使用して、この接続を経て装置のタイプを検出することができる。ＰＣを経て接続された装置については、それを経てプロビジョニングが行なわれる。
ｉ．アカウント、サービス及びフィルタが構成される（ユーザにより一部分行なわれるか又は完全自動である）。
ii．サービスプロバイダーがキャリアでない場合には、装置の電話番号が入力される。プロバイダー及びキャリアが同じである場合には、番号が既に知られている。
ｃ．ユーザがメニューから装置のタイプを手動で選択する
装置は、ワイヤレスで接続されるか、又はＰＣに接続された場合は、何らかの理由でそれを検出できないと仮定する。プロビジョニングプロセスは、空中を経て行うこともできるし、装置のメモリカードを経て行うこともできるし、或いは他の方法を介して行うこともできる。
装置は自動的に検出できないので、ユーザは、装置のタイプをリストから手動で選択する。これが行なわれると、アカウント、サービス及びフィルタの前構成が行われ（前記４．ｂ．ｉを参照）、そしてそこからプロセスが続く。
５．これで、前プロビジョニングプロセスが完了となる。次いで、プロビジョニングそれ自体が装置のタイプに基づいて開始され、これは、次の章で説明する。
【００５１】
別の例では、前プロビジョニングを使用して装置を回復させる。接続寿命サービスは、次の場合に装置を回復させる可能性を与える。
−装置が同じタイプの別のものに置き換えられる（盗み、ダメージ、等により）
−装置がリセットされるか、又は何らかの他の仕方で、その接続寿命サービス構成を失った。
【００５２】
これらのケースでは、装置（又は交換装置）を回復させることができる。前プロビジョニングプロセスは、ユーザ、装置及びその以前の構成がサーバーに既に知られている状態で、ステップを経て勧められる。プロビジョニングプロセスは、装置のカテゴリーに基づいて開始することができる。
【００５３】
図８は、本発明の一実施形態により検証された電話番号でウェブサイトを経て装置をプロビジョニングするワークフローを示す。ここに述べ且つ次の章でも述べるワークフロー「ワークフロー−検証された電話番号をもたないプッシュ装置」は、いわゆる「プッシュ」装置、換言すれば、ＭＭＳ装置、に適用される。これは、データ交換の最も基本的なレベルを与え、一方向性である。本質的に、データは、ＣＬＳにより装置へプッシュされる。データは、ユーザにより装置において変更されるように意図されておらず、変更してもＣＬＳには返送されない。ｅメールは、装置にプッシュされる１つのデータタイプの例である。
【００５４】
これらの装置は、接続寿命サービスに使用するためにインストールされるべきソフトウェアを必要としない。図ＤＰ６に示されたプロビジョニングプロセスでは、前プロビジョニングプロセスが完了すると、装置の対するサービスをアクチベートし、それにデータを送信するだけである。この利用ケースでは、装置の電話番号は、ＣＬＳにより既に検証されている。電話番号の検証は、データが正しい装置に送られるよう確保するために、セキュリティの理由で行なわれる。
【００５５】
図９は、本発明の一実施形態により検証された電話番号なしにウェブサイトを経て装置をプロビジョニングするワークフローを示す。この利用ケースでは、装置は、プッシュ装置（上述したような）であるが、その電話番号を、依然、検証できる。このプロセスは、そのプロビジョニングの主要部分を形成し、これが行なわれてそのサービスがアクチベートされると、装置の動作準備ができる。電話番号の検証プロセスは、次の通りである。
１．ユーザは、電話番号を入力し、ＯＫをクリックして、ＳＭＳをそこに送る。
２．ＳＭＳが装置へ送信される。装置は、４桁の検証番号を表示する。
３．同時に、ブラウザは、ユーザがこの検証番号を入力するためにページをオープンする。
４．ユーザが検証番号を入力する。
５．確認されると、ＣＬＳは、装置に対するサービスをアクチベートするように進み、プロビジョニングプロセスが完了となる。
【００５６】
図１０は、本発明の一実施形態によりＡｃｔｉｖｅＸ装置に対してウェブサイトを経て装置をプロビジョニングするワークフローを示す。このプロビジョニングワークフローは、次の装置に適用される。
−ＡｃｔｉｖｅＸ−イネーブルウェブブラウザをもつＰＣ
−このようなＰＣに接続されたハンドヘルド装置
【００５７】
ローダーは、ＣＬＳが装置のタイプを検出しそしてクライアントソフトウェアをインストールできるようにするＡｃｔｉｖｅＸ制御を備えている。又、ＣＬＳで装置を認証し、クライアントソフトウェアのダウンロードを行えるようにする。
【００５８】
図１１は、本発明の一実施形態によりクライアントソフトウェアを使用してウェブサイトを経て装置をプロビジョニングするワークフローを示す。このワークフローは、クライアントソフトウェアのインストールを必要とする装置に適用される。その手順は、次の通りである。
１．ブラウザは、ローダーのＵＲＬと、ユーザに対する独特のＰＩＮとを表示する。更に、
ａ．ＣＳＲに対して、ブラウザは、使用可能な他のバイナリーのＵＲＬも表示する。
ｂ．開発者に対して、ブラウザは、ＣＬＳインストール及びローダーのＵＲＬ、並びにインストールする必要のない他のバイナリーのＵＲＬを入力するオプションを彼等に与える。
２．普通のユーザは、ローダーのインストールへまっすぐにジャンプする。
ａ．空気中を経てインストールされるべき場合には、ＣＬＳは、ローダーのためのＵＲＬを含む装置へ構成ＳＭＳを送信する。それをオープンすることで、ダウンロードがスタートする。
ｂ．装置がＰＣに接続されている場合には、ローダーは、自動的にダウンロードを行ってスタートする。
これらのステップは、両方とも、ユーザが既に表示されたＰＩＮを認証の目的で入力することを要求する。
３．ローダーは、それがスタートした後に、クライアントソフトウェアをダウンロードし、インストールし、そしてスタートさせる。
４．装置のサービスがアクチベートされ、データが装置からインポートされ（選択されていれば）、レコードの複写がＣＬＳにより取り扱われ、そしてアカウントからのレコードが装置へ送られる。これで、プロビジョニングプロセスが完了となる。
【００５９】
図１２は、本発明の一実施形態により装置の既存の同期スタックを使用してウェブサイトを経て装置をプロビジョニングするワークフローを示す。このワークフローは、それ自身の同期スタックを有する装置、例えば、ＳｙｎｃＭＬ装置に適用される。この場合に、クライアントソフトウェアをインストールする必要がない。ほとんどの装置のワークフローは、極めて簡単である。サーバー名、ポート番号、等々を指定する構成ＳＭＳが装置に送られるだけでよい。プロビジョニングは、実行されると、サービスをアクチベートし、データの交換をスタートさせることにより、通常の仕方で続けられる。
【００６０】
装置が付加的なソフトウェアのインストールを必要とする場合には、その後の手順は、図９に示されたローダーのインストールの場合と基本的に同じである。即ち、
１．ブラウザは、バイナリーのＵＲＬと、ユーザに対する独特のＰＩＮとを表示する。
更に、
ａ．ＣＳＲに対して、ブラウザは、使用可能な他のバイナリーのＵＲＬも表示する。
ｂ．開発者に対して、ブラウザは、ＣＬＳインストール及びローダーのＵＲＬ、並びにインストールする必要のない他のバイナリーのＵＲＬを入力するオプションを彼等に与える。
２．普通のユーザは、バイナリーのインストールへまっすぐにジャンプする。
ａ．空気中を経てインストールされるべき場合には、ＣＬＳは、バイナリーのためのＵＲＬを含む装置へ構成ＳＭＳを送信する。それをオープンすることで、ダウンロードがスタートする。
ｂ．装置がＰＣに接続されている場合には、バイナリーは、自動的にダウンロードを行ってスタートする。
これらのステップは、両方とも、ユーザが既に表示されたＰＩＮを認証の目的で入力することを要求する。
３．装置のサービスがアクチベートされ、データが装置からインポートされ（選択されていれば）、レコードの複写がＣＬＳにより取り扱われ、そしてアカウントからのレコードが装置へ送られる。これで、プロビジョニングプロセスが完了となる。
【００６１】
図１３は、本発明の一実施形態によりＳＭＳを経て装置をプロビジョニングするワークフローを示す。この利用ケースは、ユーザの経験に関して簡単なプロビジョニングプロセスを与える。ここでは、サービスプロバイダーは、特定の装置タイプに対して接続寿命サービスを提供し、そしてユーザが指定の番号へＳＭＳを単に送信するのを許し、その際に、それらのアカウントは、それがまだない場合には接続寿命使用に対してアクチベートされ、そして装置が自動的にプロビジョニングされ、最小限のユーザ相互作用しか必要としない。（特定の分岐のもとで）図１３に示されたこのワークフローは、プロビジョニングされる装置のタイプ（１つ又は複数）及びサービスプロバイダーの要求を満足するように調整されてもよい。或いは又、一般的な分岐のもとで示されるように、ＳＭＳを送信するときには、ＣＬＳは、「ウェブサイトを経て(Via Website)」の利用ケースで述べるように、ユーザがブラウズすべきＵＲＬを返送し、そして装置をプロビジョニングすることができる。
【００６２】
図１４は、本発明の一実施形態によりオンラインショップを経て装置をプロビジョニングするワークフローを示す。このプロビジョニングシナリオでは、装置は、接続寿命サービスに使用するための技術的な要件を既に満足している。ユーザは、サービスプロバイダーとのアカウントを有する（しかし、必ずしも、接続寿命サービスではない）。ユーザが行なうのは、プロバイダーのウェブサイトにログオンし、接続寿命サービスをアクチベートするのが全てである。プロビジョニングは、自動的に行なわれる。
【００６３】
レコード交換（ＲＥｘ）アプリケーションプログラムインターフェイス
レコード交換ＡＰＩは、ＳｙｎｃＭＬ（セッションベースの）プロトコルに使用される機能を発揮するように設計される。これを達成するために、必要なステップの数及びそれらステップの遂行に使用するコマンドが減少される。ＳｙｎｃＭＬモデルにおいて、プロセスの流れを以下に述べる。
−認証
−セッションをスタート
−同期セッションを初期化（データベースタイプごとに同期タイプをネゴシエーションする）
−クライアントがレコードをサーバーへ送信する（多数のメッセージを必要とすることがある）
−サーバーがクライアントのデータとそれ自身との間の同期を遂行する
−サーバーがクライアントのレコードを確認し、そしてクライアントへレコードを送信する（多数のメッセージを必要とすることがある）
−クライアントがサーバーのレコードを確認する
−セッションを終了する
【００６４】
上述したように、全セッションは、同期オペレーションを成功とみなすために首尾良く完了する。これは、主としてネットワークの接続性及び装置安定性の問題のために、全プロセスを、エラーの生じ易いものにする。
【００６５】
レコード交換ＡＰＩは、プロセスを、ほとんどの部分について互いに独立して遂行できる個別のオペレーションへと分割することにより、ＳｙｎｃＭＬ（セッションベースの）同期の完全性の問題に対処する。同期化の概念は、２つの構成部分、即ちクライアントの観点からアイテムをプット(putting)し及びゲット(getting)すること、に分割され、そして初期化の概念を、これらアクションのいずれかに結合することができる。従って、カスケード依存性を伴うプロセスにおいてアクションを使用するのではなく、レコード交換ＡＰＩを使用する典型的な同期は、次のように説明される。
−クライアントは、使用を希望するデータタイプを初期化し、アイテムを送信する。サーバーは、この要求に対して即座に応答を送信する。サーバーは、その応答において、クライアントに対して保留中のアイテムがあるかどうか指示することができる。このステップは、クライアントが必要と思われるほど何回も繰り返すことができる。
−クライアントは、使用を希望するデータタイプを初期化し、サーバーからアイテムを要求する。サーバーは、保留中のアイテムをクライアントに返送し、まだ保留があるかどうか指示する。クライアントは、このステップを繰り返し、確認情報を含ませることができる。
【００６６】
前記では２つのステップだけを示したが、レコード交換ＡＰＩは、これらステップの異なる部分を実行するための異なる機能も備えている。クライアント装置は、プット／ゲットプロセスを使用することもできるし、又は必要に応じて個別のｉｎｉｔ及び確認ステップを含む更に詳細なプロセスを使用することもできる。これらステップの各々を以下に詳細に説明する。
【００６７】
図１５は、ＲＥｘプロトコルフローの概要を示す図である。プロトコルの変更をサポートし、そしてより古い装置との後方互換性を与えるために、装置は、現在プロトコルバージョンをＵＲＬパラメータとして各要求と共に送信する。
【００６８】
レコードの交換
ＲＥｘ ＡＰＩにより交換される各アイテムがアドレスされる。これを達成するために、ＲＥｘ ＡＰＩは、アイテムに対する独特の参照を含む多数のコンポーネントを定義する。各状態に全てのコンポーネントが使用されるのではなく、所与のアイテムに対して、供給されるアドレス情報は、そのアイテムを独特に識別するに充分なものでなければならない。ＲＥｘ ＡＰＩで定義されたアドレスコンポーネントは、データソース、データタイプ、及びレコードＩＤである。
【００６９】
これらのコンポーネントの中で、レコードＩＤだけが必須である。他の２つについては、遂行されているオペレーションにおいてそれらの値が暗示されることが考えられ、このケースでは、それらを無視することができる。クライアントが、有効データソースを決定する能力を有し、且つおそらく、ユーザがどちらを使用するか選択するのを許すこともできる場合には、データソースコンポーネントを使用して、クライアントが異なるデータソースで新たなアイテムを生成できるようにする。
【００７０】
これらのコンポーネントの名前は、ＲＥｘ ＡＰＩのオリジナルドメインから発生するが、それらをアドレス要求に使用することができる。レコードＩＤは、例えば、設定経路ファンクションである。あるデータタイプについては、レコードＩＤが任意であることに注意されたい。これらのケースでは、レコードＩＤを省くことができる。サーバーからの各応答内では、レコードＩＤごとに１つのアイテムがある。
【００７１】
クライアントは、ｐｕｔＩｔｅｍｓコールを使用してサーバーにレコードを送信する。この機能は、ＥｘｃｈａｎｇｅＩｔｅｍｓのアレーをパラメータとしてとる。サーバーは、各ｐｕｔＩｔｅｍｓコールに対してＥｘｃｈａｎｇｅＲｅｓｕｌｔ構造で応答し、これは、保留中の変更を有するデータタイプのアレーと、受け取ったアイテムに対する確認とを含む。１つの要件は、クライアントが、ｐｕｔＩｔｅｍｓをコールする前にサーバーから受け取った全アイテムを確認することである。
【００７２】
いつでも、クライアントは、ｇｅｔＩｔｅｍｓ要求を送信することにより、保留中アイテムについてサーバーに問合せすることができる。このコールは、アイテムキャッシュのコンテンツを調査し、そしてクライアントに対して保留中のレコードを返送する。アイテム及び状態の最適な交換を容易にするために、クライアントは、ａｃｋＡｎｄＧｅｔＩｔｅｍｓコールを使用することにより新たなアイテムをゲットするときに確認情報を含ませることができる。確認情報のフォーマットは、以下で説明する。
【００７３】
各ｇｅｔＩｔｅｍｓコールに応答して、サーバーは、ＥｘｃｈａｎｇｅＲｅｓｕｌｔを返送し、これは、とりわけ、保留中アイテムのコンテンツを含むＥｘｃｈａｎｇｅＩｔｅｍｓのアレーと、どのデータタイプが、検索されるべきアイテムをより多く有するか指示するＤａｔａＴｙｐｅのアレーとを含む。
【００７４】
サーバーからクライアントへのアイテムの流れを最適化するために、サーバーは、常に、アイテムの追加及び置き換えの前に、削除アイテムを送信する。ｇｅｔＩｔｅｍｓ要求は、次の要件を含む。
−クライアントは、ｇｅｔＩｔｅｍｓをコールする前に、全ての保留中変更を、ｐｕｔＩｔｅｍｓを経てサーバーへ送信し、
−クライアントは、各ｇｅｔＩｔｅｍｓコールに応答してどれほど多くの情報を返送すべきか決定するためにサーバーが使用する限界値を含み、及び
−クライアントは、ｇｅｔＩｔｅｍｓコールの直後にａｃｋＩｔｅｍｓをコールする。
【００７５】
アイテムは、両方向に確認され、クライアント及びサーバーは、いつアイテムが首尾良く処理されたか分る。ａｃｋ及び確認という語は、本明細書全体にわたり交換可能に使用されることに注意されたい。ｇｅｔＩｔｅｍｓによりアイテムの受信を確認する仕方は、２つあり、即ち個々のａｃｋ ＥｘｃｈａｎｇｅＩｔｅｍによるものか、又はａｃｋ 全ＥｘｃｈａｎｇｅＩｔｅｍｓによるものである。欠陥ａｃｋは、常に、個々のａｃｋ ＥｘｃｈａｎｇｅＩｔｅｍを必要とし、従って、厳密なアイテム及び欠陥の原因を識別することができる。ａｃｋ 全ＥｘｃｈａｎｇｅＩｔｅｍｓは、アイテムを確認する前に受け取った全てのアイテムが、首尾良く処理されたとして解釈されるように取り扱われる。Ａｃｋ全アイテムメソッドは、有効データタイプ名を含む。これは、交換に含まれるデータタイプごとに個別のａｃｋ全アイテムが必要とされることを意味する。
【００７６】
サーバーは、ｐｕｔＩｔｅｍｓコールに応答してａｃｋアイテムを返送しない。むしろ、全ｐｕｔＩｔｅｍｓコールに対する全結果応答を返送する。換言すれば、ｐｕｔＩｔｅｍｓコールにおけるアイテムの処理は、全てか無かの(all-or-nothing)オペレーションである。この理由で、クライアントから送信されたアイテムを確認するときには、アイテムｒｅｆ値が使用されない。クライアントは、彼らがサーバーへ送信するＥｘｃｈａｎｇｅＩｔｅｍｓからこの値を省く。クライアントは、できるだけ早くａｃｋ全アイテムを送信し、サーバーがクライアントの最も正確な状態表示をもつことが推奨される。
【００７７】
提案されたレコードＩＤを記憶できないか又は記憶しないことを選択するクライアントは、サーバーにより提案された（一時的）ロケートユニットＩＤ（ＬＵＩＤ）と、クライアントにおけるレコードを表わすＬＵＩＤとを含むマップコマンドを返送することができる。クライアントは、ａｃｋＩｔｅｍｓコールにおいてＥｘｃｈａｎｇｅＩｔｅｍｓを通すことによりサーバーへマップコマンドを送信する。マップコマンドは、いつでも送信でき、又、何回でも送信でき（通信欠陥の場合に）、更に、アイテムの暗示的受信確認として解釈されない。クライアントは、ＩＤマップされたアイテムについても、依然、ａｃｋアイテムを明確に通せることに注意されたい。クライアントは、マップコマンドをサーバーへ送信するまで、サーバーのレコードＩＤを使用することができる。
【００７８】
ＩＤをマップするために、クライアントは、サーバーから受け取ったＥｘｃｈａｎｇｅＩｔｅｍｓを、アイテムのタイプを変更して、データメンバーをクライアントのＬＵＩＤに置き換えた後に、エコーバックする。一実施形態において、サーバーから送られるＥｘｃｈａｎｇｅＩｔｅｍの一例を以下に示す。
クライアントは、次のようなマップコマンドを返送することができる。
【００７９】
レコード交換データ構造
一実施形態において、ＲＥｘのデータ構造の例を以下に示す。
【００８０】
ＩｔｅｍＲｅｆは、クライアントへ送信するアイテムを参照するためにサーバーが使用する独特の識別子である。クライアントは、この値を使用して、サーバーから受け取ったアイテムを確認する。ＩｔｅｍＲｅｆは、整数値の単調に増加するシーケンスである。データタイプごとにシーケンスを維持する。
【００８１】
又、装置は、ＩｔｅｍＲｅｆ値の単調に増加するシーケンスと共にサーバーへ送信するコマンドをマークすることができる。サーバーと装置との間の接続が中断されたときには、サーバーは、ｉｔｅｍＲｅｆ値を調査しそして既に受け取られたコマンドを無視することにより、再送信コマンドを検出する。装置は、ｉｔｅｍＲｅｆ値を伴うコマンドをサポートするところのデータタイプごとにｉｔｅｍＲｅｆシーケンスを維持する。装置は、全コマンド又は非コマンドに対するデータタイプに基づいてｉｔｅｍＲｅｆ値を送信するように保証する。
【００８２】
１つの解決策において、有効なアイテムタイプを以下に列挙する。
−Add(追加) １
−Replace(置き換え) ２
−Delete(削除) ３
−AddOrReplace ４ 装置からサーバーへのみ有効
−Map(マップ) ５ 永続的に記憶されず
−Get(ゲット) ６
−Ack ７ 永続的に記憶されず
−AckAll ８ 永続的に記憶されず
−Query(問合せ) ９
−QueryResult １０
−QueryEnd １１
−Clear(クリア) １２
−GetResult １５
データコンテンツ：
−データのレコードコンテンツ − 追加及び置き換えのため
−ＮＵＬＬ − 削除オペレーションを遂行するのに付加的な情報が要求されない限り削除のため（ある好ましい管理のケースと同様）
−レコードＬＵＩＤ − マップのため
−任意のフィルタ − 問合せコマンドのため
【００８３】
ＲＥｘ ＡＰＩは、レコード又はデータを交換するための柔軟性のあるプロトコルである。しかしながら、ＲＥｘ ＡＰＩに組み入れられた柔軟性にも関らず、コアタイプ定義で全ての必要な情報が与えられない情況が生じる。この問題を解消する１つの仕方は、ＡＰＩが与えるコアタイプ定義に基づいて顧客タイプを定義することである。これは、ＲＥｘがＸＭＬ−ＲＰＣに基づくものであることから取り扱われる。ＲＥｘ ＡＰＩで定義された全ての構造は、ＸＭＬ−ＲＰＣフォーマットの構造として転送される。ＸＭＬ−ＲＰＣ構造は、名前／値の対の集合としてみなすことができる。構造を拡張するために、新たな名前／値の対が追加される。
【００８４】
ＲＥｘ ＡＰＩパーサは、一般的なＸＭＬ−ＲＰＣオブジェクトを構築し、そしてそれらを、プロトコルハンドラークラスに常駐するマーシャラーファンクションへ通す。コアＲＥｘ ＡＰＩファンクションは、単一のプロトコルハンドラーに常駐するが、全コアＲＥｘ ＡＰＩファンクションを受け継ぎながらそれら自身の目的で特殊なファンクションを与える顧客プロトコルハンドラーを定義することができる。これらの特殊なファンクションは、それらが受け取るパラメータをマーシャルし、そして拡張タイプを適宜に取り扱うことができる。拡張タイプの一例を以下に示す。
【００８５】
前記構造は、ＥｘｃｈａｎｇｅＩｔｅｍが予想されるところであれば、どこでも通されるが、ＤＭＥｘｃｈａｎｇｅＩｔｅｍタイプを理解するファンクションは、ｄａｔａＴｙｐｅＩＤ情報をサーチして使用することもできる。
【００８６】
レコード交換状態及び結果コード
テーブル２は、有効な交換状態及び結果コードを定義する。列挙された全ての値が全てのケースに適用できるのではないことに注意されたい。各ファンクションに適用する厳密な値に対する個々のファンクションを協議する。
テーブル２
【００８７】
１つの解決策において、ＣＬＳにエラー状態を通知するのに使用される要求、それに対応する構造、及び応答について、以下に述べる。又、構造は、エラー状態がもはや存在しないときにエラーをクリアするのにも使用される。
【００８８】
ＥｒｒｏｒＭｅｓｓａｇｅ構造は、ｒａｉｓｅＥｒｒｏｒ及びｃｌｏｓｅＥｒｒｏｒ要求に対するパラメータとして送信される。全てのメンバーが全てのエラー及び全ての要求メソッドに対して設定されるのではない。各エラー及び要求メソッドに対して、メンバーは、未使用、任意、及び必須として定義される。メンバーの後のかっこ内の数字は、メンバーの最大長さを定義することに注意されたい。
【００８９】
全ての要求に対する応答として、ＥｒｒｏｒＲｅｓｐｏｎｓｅ構造が発呼側装置へ返送される。
【００９０】
各要求に対する応答として、ＣＬＳは、応答構造において状態メンバーを設定することにより要求の結果を返送する。状態メンバーに対する値は、次の通りである。
テーブル３
【００９１】
ｒａｉｓｅＥｒｒｏｒコールは、装置にエラーが生じたことをＣＬＳに通知するのに使用される。ＥｒｒｏｒＲｅｓｐｏｎｓｅ要求は、エラー形式に基づいて異なるメンバーが設定される場合にＥｒｒｏｒＭｅｓｓａｇｅ構造をアーギュメントとみなす。その結果、ＥｒｒｏｒＲｅｓｐｏｎｓｅ構造が返送される。
ErrorResponse raiseError (ErrorMessage)
【００９２】
ｃｌｏｓｅＥｒｒｏｒ要求は、以前のｒａｉｓｅＥｒｒｏｒ要求により報告されたエラーをクリアする。ｃｌｏｓｅＥｒｒｏｒ要求に対して、ＥｒｒｏｒＭｅｓｓａｇｅ構造のｍｅｓｓａｇｅＩＤメンバーのみが使用される。ＣＬＳは、要求を受け取ると、同じｍｅｓｓａｇｅＩＤをもつ以前に報告されたエラーをクリアする。
ErrorResponse closeError (ErrorMessage)
【００９３】
レコード交換ファンクション
この章は、レコード交換ＡＰＩにおけるファンクションについて述べる。通されたパラメータを変更するファンクションについては、次の規定を使用する。
→ 右を向いた矢印は、値がクライアントにより設定され、サーバーにより変更されないことを指示する。
← 左を向いた矢印は、サーバーが、クライアントにより送られた値を読み取らず、値を返送することを指示する。
←→ 両方向矢印は、サーバーが、クライアントの値の読み取りと、おそらく更新された値の返送との両方を行うことを指示する。
【００９４】
レコード交換ＡＰＩの前交換ファンクションは、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒ、ｉｎｉｔＲｅｆｒｅｓｈ、及びｑｕｅｒｙＣｈａｎｇｅｓを含む。前交換ファンクション、それに対応するフォーマット及びパラメータについて、以下に述べる。
ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒ：クライアントは、ＤａｔａＴｙｐｅ構造内のデータタイプに対して両方のアンカーでこのファンクションをコールし、２つの同期アンカーの一方がサーバーアンカーに一致することを検証する。同期アンカーチェックが所与のデータタイプに対してフェイルした場合には、サーバーがリフレッシュ要求結果を返送する。サーバーに記憶された同期アンカー値は、変更されない。
ExchangeResult checkSyncAnchors (DataType[] dataType)
パラメータ：
ｄａｔａＴｙｐｅ−どのデータタイプをチェックに使用すべきか指示するアレー：
→ ｄａｔａＴｙｐｅＮａｍｅ
→ ｓｙｎｃＡｎｃｈｏｒ−このデータタイプに対する現在の装置同期アンカー
→ ｐｅｎｄｉｎｇＳｙｎｃＡｎｃｈｏｒ−このデータタイプに対する保留中アンカー リターン：各ＤａｔａＴｙｐｅに対して指定された適当なｅｘｃｈａｎｇｅＳｔａｔｕｓと共にＤａｔａＴｙｐｅを含むＥｘｃｈａｎｇｅＲｅｓｕｌｔ。
← 結果−サーバーが要求を首尾良く処理したときには、２００（ＯＫ）、又は定義されたエラーコード
← ｄａｔａＴｙｐｅは、データタイプに対してｅｘｃｈａｎｇｅＳｔａｔｕｓを保持する−２００（ＯＫ）、２０１、又は定義されたエラーコード
ｉｎｉｔＲｅｆｒｅｓｈ：リフレッシュが必要であることをクライアントが決定するか又はサーバーにより通知された場合には、ｉｎｉｔＲｅｆｒｅｓｈをコールして、リフレッシュプロセスを開始する。
ExchangeResult initRefresh (DataType[] dataType)
パラメータ：
ｄａｔａＴｙｐｅ−どのデータタイプを初期化に使用すべきか指示するアレー：
→ ｄａｔａＴｙｐｅＮａｍｅ
→ ｅｘｃｈａｎｇｅＳｔａｔｕｓ−２５０（交換リフレッシュ）
→ ＳｙｎｃＡｎｃｈｏｒ−このデータタイプに対する新たなアンカー
リターン：次のようにポピュレートされたＥｘｃｈａｎｇｅＲｅｓｕｌｔ：
← 結果−サーバーが要求を首尾良く処理したときには、２００（ＯＫ）、又は定義されたエラーコード
← ｄａｔａＴｙｐｅは、オリジナルコールで指定された各データタイプに対してｉｎｉｔ状態を指示する：２００（ＯＫ）、２０１、又は定義されたエラーコード
ｑｕｅｒｙＣｈａｎｇｅｓ：このファンクションは、クライアントが保留中の変更に対してサーバーをポーリングして、おそらく、交換の実行の前にユーザフィードバックを与えることを希望する場合に使用される。
ExchangeResult queryChanges (DataType[] dataType)
パラメータ：
ｄａｔａＴｙｐｅ−どのデータタイプを変更問合せに使用すべきか定義するアレー。空のデータタイプアレーを送信することで、全てのデータタイプに対する変更を問合せる。
→ ｄａｔａＴｙｐｅＮａｍｅ
リターン：次のようにポピュレートされたＥｘｃｈａｎｇｅＲｅｓｕｌｔ：
← 結果−サーバーが要求を首尾良く処理したときには、２００（ＯＫ）、又は定義されたエラーコード
← ｄａｔａＴｙｐｅは、どのＤａｔａＴｙｐｅがサーバーに保留中の変更を有するか指示する。発呼者が空のｄａｔａＴｙｐｅパラメータを通す場合には、データタイプのアレー結果が、サーバーに変更が存在するデータタイプしか含まない。発呼者が空でないｄａｔａＴｙｐｅパラメータを通す場合には、同じアレーが、各データタイプに対して指定された２００（変更なし）、２０１（レコード保留中）、又は４１７交換状態と共に返送される。
【００９５】
レコード交換ＡＰＩの後交換ファンクションは、ａｃｋＩｔｅｍｓ、ｐｕｔＩｔｅｍｓ及びａｃｋＡｎｄＰｕｔＩｔｅｍｓを含む。後交換ファンクション、それに対応するフォーマット及びパラメータについて、以下に述べる。
【００９６】
ａｃｋＩｔｅｍｓ：サーバーからアイテムを受け取った後に、クライアントは、サーバーへ確認を返送する。これは、各レコードの到着状態をサーバーに通知し、サーバーがクライアントデータのキャッシュを効率的に管理できるようにする。一実施形態において、このファンクションは、種々のｇｅｔＩｔｅｍｓコールにおいてサーバーがクライアントに何を返送するかであるＥｘｃｈａｎｇｅＩｔｅｍｓのアレーを使用する。クライアントは、各ＥｘｃｈａｎｇｅＩｔｅｍのｉｔｅｍＲｅｆ及び結果メンバーを指定するだけでよい。このファンクションを使用する別の仕方は、Ａｃｋ Ａｌｌに設定されたｉｔｅｍＴｙｐｅ、確認されているアイテムのグループに基づいて設定されたｄａｔａＴｙｐｅ、及びそのｄａｔａＴｙｐｅに対して首尾良く処理された最後のアイテムに設定されたｉｔｅｍＲｅｆと共にＥｘｃｈａｎｇｅＩｔｅｍを送信することである。サーバーは、ｉｔｅｍＲｅｆが指定のｉｔｅｍＲｅｆ値以下であるようなｄａｔａＴｙｐｅの全てのアイテムに対してこれを首尾良い確認として解釈する。多数のＥｘｃｈａｎｇｅＩｔｅｍｓをこのように送信できることに注意されたい。全ての個々のａｃｋアイテムは、ｉｔｅｍＡｃｋパラメータにおいてａｃｋ全アイテム(ack-all-items)の前に含まれる。
ExchangeResult ackItems (ExchangeItem[] itemAcks)
パラメータ：
ｉｔｅｍＡｃｋｓ−確認されているアイテムに関する情報を含むＥｘｃｈａｎｇｅＩｔｅｍｓのアレー。ｉｔｅｍＡｃｋｓの要件は、次の通りである。
テーブル４
リターン：次のようにポピュレートされたＥｘｃｈａｎｇｅＲｅｓｕｌｔ：
← 結果−サーバーが要求を首尾良く処理したときには、２００（ＯＫ）、又は定義されたエラーコード
← ｄａｔａＴｙｐｅｓ−ｄａｔａＴｙｐｅ構造アレー；各エレメントは、ｅｘｃｈａｎｇｅＳｔａｔｕｓを保持する：２００）又は定義されたエラーコード
ｐｕｔＩｔｅｍｓ：このファンクションは、クライアントが多数のアイテムをサーバーへ送信するのを許す。
ExchangeResult putItems (DataType[] dataTypes, ExchangeItem[] items):
パラメータ：
ｄａｔａＴｙｐｅ−装置は、この要求からのアイテムアレーに使用される全てのｄａｔａＴｙｐｅに対し、新たな同期アンカーを送信する。
→ ｄａｔａＴｙｐｅＮａｍｅ
→ ＳｙｎｃＡｎｃｈｏｒ−このデータタイプに対する新たなアンカー
ｉｔｅｍｓ−サーバーへ送信されるべきレコードを含むＥｘｃｈａｎｇｅＩｔｅｍｓのアレー
リターン：次のようにポピュレートされたＥｘｃｈａｎｇｅＲｅｓｕｌｔ：
← 結果−サーバーが要求を首尾良く処理したときには、２００（ＯＫ）、又は定義されたエラーコード
← ｄａｔａＴｙｐｅｓ−要求におけるデータタイプに対するｄａｔａＴｙｐｅ構造；各エレメントは、ｅｘｃｈａｎｇｅＳｔａｔｕｓを保持する：２００、２０１、又は定義されたエラーコード
ａｃｋＡｎｄＰｕｔＩｔｅｍｓ：このファンクションは、ｐｕｔＩｔｅｍｓと同様であるが、クライアントが、新たなアイテムをプットする前に、受け取ったアイテムを確認できるようにするパラメータが追加されている。
ExchangeResult ackAndPutItems (ExchangeItem[] acks, DataType[] dataTypes,
ExchangeItem[] items)
パラメータ−ｐｕｔＩｔｅｍｓと同様であるが、次のものが追加されている。
ａｃｋ−特定のＥｘｃｈａｎｇｅＩｔｅｍｓに対する確認情報を含む。サーバーは、クライアントからのレコードを受け容れる前にこれらのａｃｋを処理する。より多くの情報についてはａｃｋＩｔｅｍｓファンクションの説明を参照されたい。
リターン：ｐｕｔＩｔｅｍｓと同じ
ｇｅｔＩｔｅｍｓ：クライアントは、１つ以上のデータタイプについて保留中のレコードを検索するためにこのファンクションをコールする。これは、サーバーからレコードを検索する通常の方法である。各データタイプに対するｉｔｅｍＲｅｆ値は、サーバーが、アイテムキャッシュのどのレコードをクライアントが既に受け取ったかそしてどのレコードをまだ送信する必要があるか決定できるようにする。クライアントは、このフィールドにおいて、最後に処理したｉｔｅｍＲｅｆを送信することができる。
ExchangeResult getItems (DataType[] dataTypes, int limit)
パラメータ：
ｄａｔａＴｙｐｅｓ−どのデータタイプに同期すべきかそしてアイテムキャッシュのどのポイントでレコードの送信を開始すべきかサーバーに通知するＤａｔａＴｙｐｅのアレー。ＤａｔａＴｙｐｅアイテムは、次のように通される。
→ ｄａｔａＴｙｐｅＮａｍｅ−データタイプの名前
→ ｓｙｎｃＡｎｃｈｒ−このデータタイプに対する新たなアンカー
サーバーは、ＤａｔａＴｙｐｅアレーがエレメントを含まないときにｇｅｔＩｔｅｍｓに対する要求を無視する。
ｌｉｍｉｔ−これは、非圧縮の応答ＸＭＬ−ＲＰＣメッセージの最大サイズを指定する任意のパラメータである。この値が省かれる場合には、サーバーは、妥当と思われる限界値を使用する。
リターン：次のようにポピュレートされたＥｘｃｈａｎｇｅＲｅｓｕｌｔ：
← 結果−サーバーが要求を首尾良く処理したときには、２００（ＯＫ）、又は定義されたエラーコード
← ｄａｔａＴｙｐｅｓ−検索される準備のできたアイテムを有する要求から各データタイプに対するＤａｔａＴｙｐｅ構造を含む。これは、次のようにポピュレートされる。
← ｄａｔａＴｙｐｅＮａｍｅ
← ｅｘｃｈａｎｇｅＳｔａｔｕｓ−２００（ＯＫ）、２０１、又は定義されたエラーコード
← ｉｔｅｍｓ−次のようにポピュレートされた保留中のレコードを含む
← ｉｔｅｍＲｅｆ
← ｉｔｅｍＴｙｐｅ
← ｒｅｃｏｒｄＩＤ−追加アイテムに対して一時的ＬＵＩＤ、他の全てのアイテムタイプに対してクライアントＬＵＩＤ
← ｄａｔａＴｙｐｅＮａｍｅ
← ｄａｔａ−削除アイテムの場合は省かれる
ａｃｋＡｎｄＧｅｔＩｔｅｍｓ：このファンクションは、ｇｅｔＩｔｅｍｓと同様であるが、クライアントが、新たなアイテムをゲットしながら、受け取ったアイテムを確認できるようにするパラメータが追加される。
ExchangeResult ackAndGetItems (ExchangeItem[] ack, DataType[] dataType, int
limit)
パラメータ：
ａｃｋ−特定のＥｘｃｈａｎｇｅＩｔｅｍｓに対する確認情報を含む。サーバーは、アイテムキャッシュからレコードを検索する前にこれらのａｃｋを処理する。更なる情報については、ａｃｋＩｔｅｍｓファンクションの説明を参照されたい。
【００９７】
図１６は、異なるＲＥｘメソッドを使用してユーザ装置とサーバーとの間の対話を示すフローチャートである。
【００９８】
レコード交換アイテムタイプ
ｇｅｔＩｔｅｍｓ又はａｃｋＡｎｄＧｅｔＩｔｅｍｓ要求に対する応答として、サーバーは、Ｃｌｅａｒコマンドを返送する。このコマンドは、データコンテンツをもたず、装置が所与のデータタイプ名に対して全てのアイテムを除去するよう強制する。
【００９９】
初期同期の一部分としてクライアント装置のＰＩＭデータをインポートするか又はｄａｔａＳｏｕｒｃｅからシャドーデータをフェッチするようなある状況において、サーバーは、Ｑｕｅｒｙコマンドを装置へ返送し、装置が、所与のデータタイプに対するデータをサーバーへアップロードするように強制することができる。
【０１００】
図１７は、本発明の一実施形態による問合せプロセスのシーケンス図である。ステップ１において、装置は、サーバーから情報を要求するためにｇｅｔＩｔｅｍｓメソッドをコールする。ｇｅｔＩｔｅｍｓ又はａｃｋＡｎｄＧｅｔＩｔｅｍｓ要求に応答して、サーバーは、Ｑｕｅｒｙコマンドを返送する。コマンドのＥｘｃｈａｎｇｅＩｔｅｍにおいて、ｊｏｂＩＤフィールドが設定され、この問合せをマークする。任意のデータフィールドが問合せを制限するためのフィルタを含んでもよい。フィルタが与えられないときは、装置は、所与のデータタイプに対して全てのアイテムを返送する。Ｑｕｅｒｙコマンドに対するＥｘｃｈａｎｇｅＩｔｅｍの一例を以下に示す。
【０１０１】
ステップ２において、装置は、ａｃｋＩｔｅｍｓをコールし、Ｑｕｅｒｙコマンドを受け取ったことを確認する。ステップ３において、装置は、問合せされたデータを収集する。ステップ４において、装置は、ｐｕｔＩｔｅｍｓを使用してサーバーへデータを送信する。各々の問合せされたアイテムは、１つのＱｕｅｒｙＲｅｓｕｌｔとして送信される。全てのＱｕｅｒｙＲｅｓｕｌｔアイテムが送信された後に、問合せに対するデータアップロードが行なわれることをマークする１つのＱｕｅｒｙＥｎｄアイテムが送信される。全てのＱｕｅｒｙＲｅｓｕｌｔ及びＱｕｅｒｙＥｎｄアイテムは、問合せからのジョブＩＤに設定されたｊｏｂＩＤフィールドを有し、これらアイテムがこのｊｏｂＩＤをもつ問合せに関係していることを指示する。ＱｕｅｒｙＲｅｓｕｌｔ及び最終的なＱｕｅｒｙＥｎｄＥｘｃｈａｎｇｅＩｔｅｍの一例を以下に示す。
【０１０２】
問合せに対する結果が１つのｐｕｔＩｔｅｍｓコールに対して大き過ぎるときに、装置は、複数のｐｕｔＩｔｅｍｓを使用して、アイテムをサーバーにアップロードすることができる。最終的なＱｕｅｒｙＥｎｄコマンドは、最後のｐｕｔＩｔｅｍｓコールにおいてのみ送信される。
【０１０３】
装置は、ステップ２の後、例えば、装置クラッシュの後、ユーザが装置をターンオフした後、又は死んだバッテリを交換した後、再スタートするときに、問合せを続ける。装置は、Ｑｕｅｒｙコマンドを既に確認しているので、サーバーは、このコマンドを再送信しない。それ故、装置は、このコマンドを再スタートに生き残るように持続させる。この状況を回避するために、装置は、ステップ４において、ａｃｋＡｎｄＰｕｔＩｔｅｍｓをコールすることによりＱｕｅｒｙコマンドを確認することができる。
【０１０４】
サーバーは、データフィールドを使用して、フィルタを、Ｑｕｅｒｙコマンドの一部分として設定できることに注意されたい。一実施形態では、サーバーは、ｄａｔａＳｏｕｒｃｅのためのフィルタとしてストリング｛ｐａｒｔｉａｌ｝を使用するだけである。このフィルタは、問合せされたアイテムに対してシャドー情報のみを返送するようにｄａｔａＳｏｕｒｃｅに通知する。これは、アップロードされるデータの量を減少する。サーバーが完全なアイテムを必要とするときには、それをフェッチするためにＧｅｔコマンドを送信する。
【０１０５】
サーバーが（部分フィルタを通して）シャドー情報を要求するときには、ｄａｔａＳｏｕｒｃｅが、メール、連絡先、タスク、及び事象アイテムのような異なるタイプのデータに対してこの情報を返送する。
【０１０６】
Ｇｅｔコマンドは、ｐｕｔＩｔｅｍｓを使用してサーバーへ指定のアイテムをアップロードするために、ＬＵＩＤを指定することにより、装置に要求する。Ｇｅｔコマンドに対するＥｘｃｈａｎｇｅＩｔｅｍの一例を以下に示す。
【０１０７】
装置は、ＧｅｔＲｅｓｕｌｔを使用してアイテムを返送する。ジョブＩＤを使用して、ＧｅｔとＧｅｔＲｅｓｕｌｔを接続する。
【０１０８】
問合せのケースと同様に、装置は、ａｃｋＡｎｄＰｕｔＩｔｅｍｓを使用して、Ｇｅｔコマンドを確認すると共に、要求されたアイテムを１つのコールにおいてサーバーへ送信するか、又は装置は、Ｇｅｔコマンドの結果を永続的なものにすることに注意されたい。装置は、不存在アイテムに対してＧｅｔを受け取ると、４２２状態コードでアイテムを確認する。
【０１０９】
ＱｕｅｒｙＲｅｓｕｌｔコマンドは、問合せの結果において且つＧｅｔコマンドの応答として装置により使用される。ｄａｔａＳｏｕｒｃｅは、新たなアイテムを検出すると、Ａｄｄコマンドをサーバーへ送信する。ｄａｔａＳｏｕｒｃｅは、膨大な量の新たなアイテム（例えば、数千のｅメールがｄａｔａＳｏｕｒｃｅにコピーされた新たなｅメールフォルダ）を検出すると、シャドー情報のみを含む新たなアイテムごとにＱｕｅｒｙＲｅｓｕｌｔコマンドを送信する。ＱｕｅｒｙＲｅｓｕｌｔコマンドの最後の情報断片を送信すると、アップロードが終了したことをサーバーに通知するためのＱｕｅｒｙＥｎｄコマンドが送信される。サーバーは、１つのアイテムの完全な情報を必要とするときに、Ｇｅｔコマンドを送信する。これは、このようなケースのデータ送信量を減少する。
【０１１０】
サーバー及び装置の同期
接続寿命サーバー（ＣＬＳ）は、サーバーと１つ以上のユーザ装置との間のデータの同期を最適化する。より詳細には、ＣＬＳは、所定のバックアップインターバルに基づいてサーバーにおいて接続データセット(connected-data-set)のバックアップを生成する。次いで、接続データセットのバックアップが生成されたときに時間インターバルを追跡するためのチェックポイントマーカーを発生し、そしてそのチェックポイントマーカーを１つ以上のユーザ装置へ送信し、接続データセットに対する変更の第１レコードを維持する。
【０１１１】
サーバー及び１つ以上のユーザ装置が同期ずれしているかどうか決定するために、ＣＬＳは、サーバーの交換又はサーバーのクラッシュを検出する。或いは又、ＣＬＳは、セッションベースのｓｙｎｃＭＬプロトコル又は同期アンカープロトコル（以下に述べる）を実行して、サーバー及びユーザ装置が同期ずれしているかどうか決定してもよい。サーバー及び１つ以上のユーザ装置が同期ずれしていると決定されると、ＣＬＳは、サーバーにおいて接続データセットのバックアップデータを回復させる。次いで、チェックポイントマーカーを使用して１つ以上のユーザ装置から接続データセットの第１の変更レコードを要求する。又、１つ以上のユーザ装置からの接続データセットの第１の変更レコードに基づいてチェックポイントマーカーの後に変更を有する接続データセットの第１部分を決定する。これは、１つ以上のユーザ装置とサーバーとの間でチェックポイントマーカーの後に新しいタイムスタンプを有する接続データセットの部分を比較することによって行われる。次いで、サーバーにおいて第１の変更レコードのトランザクションを実行することにより変更を有する接続データセットの第１部分を更新する。
【０１１２】
同様に、サーバー及び後端データベースが同期ずれしていると決定すると、ＣＬＳは、サーバーにおいて接続データセットのバックアップデータを回復する。次いで、チェックポイントマーカーを使用して後端データベースから接続データセットの第２の変更レコードを要求する。又、後端データベースからの接続データセットの第２の変更レコードに基づいてチェックポイントマーカーの後に変更を有する接続データセットの第２部分を決定する。これは、後端データベースとサーバーとの間でチェックポイントマーカーの後に新しいタイムスタンプを有する接続データセットの部分を比較することによって行われる。次いで、サーバーにおいて第２の変更レコードのトランザクションを実行することにより変更を有する接続データセットの第２部分を更新する。
【０１１３】
同期アンカープロトコルの主な目的は、装置及びサーバーが交換アイテムに対して同期ずれして動作することを検出することである。クライアント装置は、サーバーと同期する責任を有する。しかしながら、クライアントだけでは検出できないシナリオが少なくとも１つある。次の事項シーケンスについて考える。
−クライアント及びサーバーは、ポイントＡにおいて同期している。
−クラインと及びサーバーは、その後、ポイントＢにおいて同期しており、実際のデータセットは、ポイントＡとは異なる。
−ユーザは、全てのデータ、構成ファイル、等を含む全装置映像のシステム回復を行なう。
−クライアントは、スタートするが、そのローカルデータをチェックするときに、ポイントＢにいるので、一貫性を調べる。しかしながら、装置がポイントＢにあると仮定すれば、サーバーとの一貫性がない（同期していない）。
【０１１４】
この問題は、ＲＥｘ同期アンカープロトコルにより対処される。同期アンカーに基づき、サーバーは、もはや同期していないことを検証してクライアントに通知することができる。これは、各データベースに対して、リフレッシュすることが必要なデータを転送するためのトラフィックを最小にするように行なわれる。交換アイテムの各タイプに対して、装置は、２つのアンカーを維持する。１つは、交換アイテムのタイプに対する現在アンカーである。装置は、サーバーからデータを要求し又はサーバーへデータを送信するときに、新たなアンカーを発生し、このデータを要求において送信する。要求がエラーなく終了すると、装置は、サーバーが新たなアンカーを首尾良く受け取ったことを知る。このケースでは、装置は、新たなアンカーを現在アンカーとして記憶する。
【０１１５】
クライアントは、サーバーとの通信を開始すると、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓメソッドをコールし、装置及びサーバーのアンカーが一致するかどうかチェックする。もしそうでなければ、装置及びサーバーは、このタイプの交換アイテムに対して同期ずれして動作している。
【０１１６】
図１８は、本発明の一実施形態によりクライアント装置とサーバーとの間で同期をとるための同期アンカープロトコルを示す。図１８に示すように、装置は、各データタイプの名前に対して２つの同期アンカーを維持する。１つは、現在アンカーであり、装置は、データを送信又は要求するメソッドをコールするときに、サーバーへの要求のデータタイプごとに新たな同期アンカー（保留中アンカー）を発生して送信する。首尾良い全体的応答は、サーバーが、これらデータタイプの名前に対して新たなアンカーを得て記憶したことを意味する（たとえ特定データタイプに対する交換状態が首尾良くなくても）。この場合には、装置は、各データタイプに対する新たなアンカーを現在アンカーとして記憶する。装置は、応答を得ないか、又は不首尾な全体的結果コードを伴う応答を得る場合、保留中アンカーを記憶し、それを次の新たなアンカーとして再送信する。
【０１１７】
装置は、現在アンカーで、そして任意であるが、保留中アンカーが存在する場合は保留中アンカーで、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓをコールする。１つのアンカーがサーバーアンカーに一致するときには、装置及びサーバーが同期状態にある。この場合及び保留中アンカーがあるときには、装置は、サーバーが保留中アンカーを受け取ったかどうか分らないので、以前に送られた現在アンカーを、現在アンカーとして使用し、そして保留中アンカーを次の新たなアンカーとして送信する。
【０１１８】
アンカーチェックが失敗すると、サーバーは、エラー状態コード４１７を返送する。装置は、アンカーを初期アンカーに戻すように設定し、新たなアンカー（初期アンカーではない）でｉｎｉｔＲｅｆｒｅｓｈをコールする。次いで、ｇｅｔＩｔｅｍｓをコールして、サーバーが装置に対してＣｌｅａｒコマンドを有するかＱｕｅｒｙコマンドを有するか決定する。次いで、装置は、ｐｕｔＩｔｅｍｓを経てサーバーへ装置管理アイテムを送信するのも任意である。最終的に、装置は、ｇｅｔＩｔｅｍｓをコールし、更新されたアイテムをサーバーから検索する。
【０１１９】
装置（又は１つのデータタイプ名に対して責任をもつ装置の一部分）は、それがスタートすると、先ず、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓをコールして、装置及びサーバーがまだ同期しているかどうかチェックする。又、ｇｅｔＩｔｅｍｓ又はａｃｋＡｎｄＰｕｔＩｔｅｍｓのようなメソッドも、要求からのデータタイプに対して４１７交換コードを返送できることに注意されたい。この場合、装置は、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓに対するコールがフェイルしたかのように働く。
【０１２０】
装置は、インストールの後、又は未知のデータタイプ４０４状態の後に、データタイプに対する初期同期をスタートすると、初期同期アンカーとしての０でｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓをコールする。装置が０を保留中アンカーとしても送信するかどうかは任意である。サーバー及び装置は、初期同期に対して同期状態にあることが要求される。
【０１２１】
装置は、初期のｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓコールの後にｇｅｔＩｔｅｍｓをコールし、そしてｇｅｔＩｔｅｍｓコールの結果として、Ｃｌｅａｒ又はＱｕｅｒｙコマンドが返送される。装置は、この初期コマンドが処理されたときに変更検出をアクチベートする。
【０１２２】
通信のユーザ装置状態の通知
ＣＬＳは、サーバーとユーザとの間の通信のユーザ状態を通知する。ユーザは、ＣＬＳによって維持された接続データセットの部分を共有する１つ以上のユーザ装置を有する。一実施形態において、ＣＬＳは、サーバーと１つ以上のユーザ装置との間の通信を、通知条件の所定セットに対して監視する。所定の通知条件のセットは、製造者により提供される情報に基づき且つ１つ以上のユーザ装置の実際の使用を通して収集される情報に基づき形成される。更に、所定の通知条件のセットは、接続データセットのエレメントの送信欠陥を含む。
【０１２３】
例えば、通知メッセージは、通知条件が検出される通信のタイトルを含む。又、通知メッセージは、通知条件が検出される通信のアブストラクトも含む。更に、サーバーにより装置へ送信される通知メッセージは、ハイパーリンクを含んでもよい。このハイパーリンクは、通知の性質についてより精巧であるウェブページを指してもよいし、又は問題を解決できるウェブページへユーザを導いてもよい（例えば、後端にアクセスするための新たなパスワードを入力する）。このメソッドが有益であるのは、通常、若干の情報アイテムしかクライアント装置へ搬送されず、且つ通知の性質を説明するのに多数のワードを必要とすることが多いためである。又、ハイパーリンクは、拡張手段も与える。通知メッセージ（又は通知スクリーン又はアプリケーションのメニュー）においては、このハイパーリンクの背後でウェブページをロードするためにブラウザをスタートするというオプションがある。
【０１２４】
通知条件が検出されると、ＣＬＳは、通知メッセージを１つ以上のユーザ装置へ送信する。一実施形態では、通知メッセージは、通知条件の所定セットが検出されたユーザ装置へ送信されることに注意されたい。別の実施形態では、通知メッセージは、通知条件の所定セットが検出されないユーザ装置へ送信されてもよい。
【０１２５】
更に別の実施形態では、所定通知条件のセットは、１つ以上のユーザ装置に対するｅメール、タスク、カレンダー及びアドレスブックオーバーフロー条件を含む。装置のオーバーフローを回避するために、サーバーは、各装置アプリケーションが保持できるデータの量を監視し、記録する。データは、次のいずれかで収集され、即ち、装置の製造者により提供される情報を通じて収集され、例えば、装置のアドレスブックが最大５００の連絡先を保持できることをユーザのマニュアルで指定するか；又はユーザ装置のテストを通じて収集され、例えば、サーバーにより送られるある数以上のレコードの記憶を装置が拒絶するか；或いは実際の使用を通じて収集され、例えば、事象の数がユーザのマニュアルにおける所定の最大数を越えても、あるカレンダーアプリケーションが依然機能する。
【０１２６】
収集されたデータに基づいて、サーバーは、サーバーインフラストラクチャーにおいて装置タイプ又はアプリケーション当たりの上限のセットを定義することができる。サーバーは、各装置におけるレコードの実際数を監視するので、装置におけるレコードの数が所定の上限に近付いたときに装置へそれ以上のレコードを送信するのを停止することができる。例えば、サーバーは、ユーザがまだある程度の有用な仕事を行なえるように、装置の９０％フル状態を保つことができる。更に、サーバーは、装置の特定のアプリケーション（例えば、ｅメール又はカレンダー）が所定の上限に達したことをユーザにアラートし、そして装置におけるレコードの数を減少するために特定アプリケーション用の異なるフィルタを適用するといった先見的アクションをとるようにユーザに要求することができる。他の解決策では、異なるデータタイプに異なるルールを適用して、装置におけるレコードの量を管理することができる。例えば、
−メール：常に装置へ送信される新たなメールには高いプライオリティが指定される。装置が新たなメールのための余地を作る必要がある場合には、最も古いものから最も新しいものへの順序で古いメールが削除される。
−タスク：オープンタスクには、より高いプライオリティが指定され、期限日が近いほど、タスクの重要性は高くなる。装置が新たなタスクのための余地を作る必要がある場合には、最も古いものから最も新しいものへの順序で、完了したタスクが削除される。
−カレンダー：近い将来生じる事象には、より高いプライオリティが指定される。一般に、将来の事象は、過去の事象よりも重要である。装置が新たな事象のための余地を作る必要がある場合には、最も古いものから最も新しいものへの順序で過去の事象が削除される。
−アドレスブック：装置に既にあるものに、より高いプライオリティが与えられる。アドレスブックがいっぱいになった場合には、サーバーは、他の装置からも、後端からも、新たなアドレスを装置へ与えない。
【０１２７】
設定交換（ＳｅｔＥｘ）プロトコル
設定交換（ＳｅｔＥｘ）プロトコルは、装置とサーバーとの間で設定情報を交換するのに使用される。ＳｅｔＥｘは、データ構造体に対する変更と共にＤＰＲＥｘプロトコルによりサポートされる。ＤＰＲＥｘプロトコルと同様に、データコンテンツは、設定変更を保持するＸＭＬドキュメントである。ＸＭＬデータコンテンツドキュメントのエンコード動作は、ＸＭＬ−ＲＰＣエンベロープのエンコード動作と常に同じである。エンコード動作は、全てのユニコードキャラクタを表わすことができる。ＳｅｔＥｘプロトコルは、設定をベースＵＲＬ拡張として使用し、例えば、ｈｔｔｐ：／／ｓｅｒｖｅｒ：ｐｏｒｔ／ｄｐ／ｓｅｔｔｉｎｇは、ＳｅｔＥｘ ＵＲＬの一例である。
【０１２８】
設定交換状態コード
ＳｅｔＥｘは、ＤＰＲＥｘと同じ状態コードを使用する。状態コード３００は、装置がゾンビ状態にあって設定をサーバーへプットするか又はサーバーからゲットするよう試みるときに返送される。この場合には、装置は、先ず、装置タイプ識別を送信する。ＳｅｔＥｘは、新たな状態コード４０５を使用する。このコードは、サーバーが装置から設定をゲットすることをいつ要求するか決定するために、ＳｅｔＥｘに対する応答として返送される。
【０１２９】
設定交換プロセスフロー
一実施形態において、設定交換のプロセスフローは、次の３つの利用ケース：１）初期設定交換；２）通常の設定交換；及び３）ダンプ設定交換について説明する。
【０１３０】
初期設定交換の間に、装置は、その装置タイプをサーバーに対して識別する。この状態は、装置をサーバーに初めて接続するときに生じる。これは、ユーザが新しい装置を買ったとき、又は装置が完全にリセットされたとき、或いは装置の状態がサーバー側でゾンビにリセットされた場合に起きることに注意されたい。これら全ての状態において、装置は、装置タイプ識別設定を交換することによりスタートする。これは、サーバーが装置の真のアイデンティティ（正しい装置タイプ識別情報）を決定できるようにする。考えられるプロセスフローシナリオは２つある。第１のケースでは、装置は、それがサーバーに初めて接続されると考え、装置タイプ識別設定を交換する。第２のケースでは、装置は、それが初期化されたと考え（同期された装置タイプ識別設定）、一方、サーバーは、そうでないことを考える。これら両方のケースは、以下の章で述べるシーケンス図に関連して検討する。
【０１３１】
図１９は、本発明の一実施形態により装置が装置タイプ識別設定を交換するときのプロセスフロー図である。図１９に示すように、ステップ１において、装置は、ｐｕｔＩｔｅｍｓをコールして、装置タイプ識別設定を交換する。ステップ１．１において、サーバーは、装置を適切に識別した後に装置のゾンビ状態を終了させる。ステップ１．２において、サーバーは、ｂｕｉｌｄＥｘｃｈａｎｇｅＲｅｓｕｌｔメソッドをコールすることにより応答を構築する。この応答は、装置へ送信されるべきサーバー状態を含む。装置が、装置タイプ識別設定を受け取ったときに既にゾンビ状態から出ている場合には、このオペレーションが何ら作用しない。
【０１３２】
図２０は、本発明の一実施形態によりゾンビ状態において装置タイプ識別以外の設定を装置が交換しようと試みるときのプロセスフロー図である。この状態は、サーバーにおける装置の既知の状態がゾンビ状態にあり、且つ装置が通常のアプリケーション設定を交換しようと試みるときに生じる。図２０に示すように、ステップ１では、装置は、ｐｕｔＩｔｅｍｓをコールして、通常の設定を交換する。この場合に、サーバーは、装置がゾンビ状態にあることを指示するエラーコード３００で装置要求を拒絶する。ステップ２において、装置は、ｐｕｔＩｔｅｍｓをコールして、装置タイプ識別設定を交換し、サーバーが装置のアイデンティティを確認すると共に、ゾンビ状態を終了できるようにする。
【０１３３】
通常の設定交換の場合には、装置は、装置で実行されているアプリケーションのための設定を交換する。このシナリオでは、装置は、もはやゾンビ状態になく、装置とサーバーとの間で通常の設定交換を遂行することができる。
【０１３４】
図２１は、本発明の一実施形態による通常の設定交換のためのシーケンス図である。図２１に示すように、ステップ１において、装置は、それが設定を変更した場合に、ｐｕｔＩｔｅｍｓメソッドコールを使用してそれらをサーバーに送信する。送信すべき設定が更にある限り、このステップを繰り返す。
【０１３５】
装置は、サーバーに得られる保留中設定変更についてサーバーから通知を受け取る場合に、ｇｅｔＩｔｅｍｓコールを発生して、設定変更を検索する。装置に対してサーバーに得られる保留中設定がない場合には、このステップを省けることに注意されたい。
【０１３６】
装置は、２０１データタイプ状態コードを通して、更に設定変更が存在するというフラグを立てた場合には、ａｃｋＡｎｄＧｅｔＩｔｅｍｓメソッドコールを発生する。装置は、この場合、サーバーからの最後の応答で受け取られた設定を確認し、そしてサーバーにおける保留中設定変更を要求する。
【０１３７】
最終的に、全ての設定変更がサーバーから装置によりフェッチされた後に、ａｃｋＩｔｅｍｓコールを発生する。ａｃｋＩｔｅｍｓメソッドは、サーバーが、サーバーから送信される変更設定に関連したリソースをクリーンアップできるようにする。
【０１３８】
上述したプロセスフローでは、更新設定間に相違はない。主な相違は、データコンテンツであるが、オペレーションは異なる。次のことに注意されたい。
１．空き設定ドキュメントを伴う削除は、全データベースを削除する。
２．全ての設定、及び削除データコンテンツドキュメントに残っている設定のサブツリーが削除される。
３．削除データコンテンツのノードとしてマークされた設定は、サブツリーを削除しない。
例えば、既存のツリーは、次の通りである。
ａ／ｂ／ｍ
ａ／ｂ／ｎ
ａ／ｃ／
ｍ及びｎを削除するために、サブノードを指定することができる。ｍ及びｎを削除するためのＳｅｔＥｘデータコンテンツは、次の通りである。
<Node name = “a”>
<Leaf name = “b”></Leaf>
</Node>
サブノードｂは、削除されるデータコンテンツにおいてリーフ（葉）として指定されることに注意されたい。それにより得られるツリー（木）は、次の通りである。
ａ／ｃ
【０１３９】
リーフを削除するのは一般的でない。又、内部ノードは、セマンティックをもたないことに注意されたい。上述したスキーマの例から、ツリー（ａ／ｃ）は、（ａ／ｂ、ａ／ｃ）と同じである。というのは、ｂは、内部ノードであり、セマンティックをもたない。従って、リーフａ／ｂ／ｍ及びａ／ｂ／ｎを削除することは、前記例においてａ／ｂを削除することとセマンティック的に同じである。リーフノード削除例は、次の通りである。
<Node name = “a”>
<Node name = “b”>
<Leaf name = “m”></Leaf>
<Leaf name = “n”></Leaf>
</Node>
</Node>
それにより得られるツリーは、次の通りである。
ａ／ｃ
【０１４０】
実施を簡単化するために、データコンテンツ仕様は、特定のサブノードにおいて削除が許されることを定義する。前記例の場合のデータコンテンツ制限は、ａ／ｂに関する削除しか許されず、リーフについては許されないことである。
【０１４１】
ダンプ設定交換
ダンプ設定交換の場合には、装置は、ＳｅｔＥｘメソッドコールを発生する。サーバーは、装置から全ての設定をゲットしたいことを決定する。このメソッドは、装置から全てのデータをゲットすることによりサーバーが期待する状態に装置があることをテストし又はチェックするのに主として使用される。これが生じると、サーバーは、特殊なエラーコード４０５で応答する。エラーコードに応答して、装置は、それを生じさせたデータ形式に関する設定情報のダンピングをスタートする。
【０１４２】
図２２は、本発明の一実施形態によるダンプ設定のためのシーケンス図である。装置は、ｐｕｔＩｔｅｍｓコールを呼び出して通常の設定を交換する。サーバーは、あるデータタイプに対して既知の全ての設定を装置がダンプすることを要求する状態にある場合に、所与のデータタイプに対して４０５コードを返送する。これは、装置がｇｅｔＩｔｅｍｓコールを開始するときにも生じることに注意されたい。
【０１４３】
装置は、ｉｎｉｔＲｅｆｒｅｓｈ（コード２５１）をコールして、ダンプ設定変更をスタートしたことをサーバーに通知する。装置は、サーバーによって送信されるべきダンプ要求アラートに応答してｐｕｔＩｔｅｍｓ要求を発生する。この状態では、装置は、それが含む全ての設定をサーバーへダンプする。このステップは、ダンプする必要のある更なる設定を装置が有する限り、繰り返される。
【０１４４】
設定交換データ構造
この章は、コア装置プロキシーレコード交換（ＤＰＲＥｘ）データ構造に対する改善を説明する。ＥｘｃｈａｎｇｅＩｔｅｍ構造は、設定交換をサポートするように変更される。特に、ＥｘｃｈａｎｇｅＩｔｅｍのｉｔｅｍＴｙｐｅ及びｒｅｃｏｒｄＩＤフィールドに対しＳｅｔＥｘプロトコルにおいてどんな値が許されるかに関して制約がある。
【０１４５】
一実施形態では、ｉｔｅｍＴｙｐｅデータ構造は、「削除(Delete)」及び「置き換え(Replace)」オペレーションをサポートする。設定変更の場合に、「置き換え」は、設定が存在しなければ「追加(Add)」を意味し、さもなければ、更新を行うよう再定義される。
ｒｅｃｏｒｄＩＤフィールドは、設定変更に対して省略される。
【０１４６】
装置が設定を要求するが、メッセージサイズを規定サイズ以下に制限するときには、ＳｅｔＥｘコンテンツが、規定サイズ以下のサイズへ分割される。分割は、リーフノードの基づくものである。例えば、メッセージサイズが０にセットされた場合には、要求当たり１つのリーフノードしか転送されない。多くの場合、この定義では実施が複雑になり過ぎ、利益が得られない。実施を簡単にするために、ノードレベルで設定をグループ分けすることができる。データコンテンツは、例えば、ａ／ｂ／ｃ、ａ／ｂ／ｄ、ａ／ｂ／ｅ及びａ／ｍ／ｃとして示される。
【０１４７】
ａ／ｂ／に対してグループ分けが可能である場合は、メッセージのサイズに関わらず、ａ／ｂ／ｃ、ａ／ｂ／ｄ、及びａ／ｂ／ｅを１つのメッセージで転送することが保証される。このメッセージは、他の設定も含み得ることに注意されたい。これは、設定を定義するためのデータコンテンツ仕様までである。
【０１４８】
次の章は、サンプル設定データコンテンツを含むＸＭＬ−ＲＰＣ断片を示す。一実施形態では、装置タイプ識別設定を交換するためにＥｘｃｈａｎｇｅＩｔｅｍのデータフィールドにおける設定ツリーデータコンテンツが使用される。６つの異なる装置タイプ識別設定が使用され、それらは、Ｍｏｄ、Ｈｉｎｔ１、Ｈｉｎｔ２、Ｈｉｎｔ３、Ｈｉｎｔ４、及びＨｉｎｔ５である。ここで、Ｍｏｄは、装置のモデルを表わし、ほとんどの場合に、装置を独特に識別するのに使用できる。Ｈｉｎｔ１ないしＨｉｎｔ５は、Ｍｏｄストリングに含まれた情報に加えて、装置タイプを識別するための情報を含む。
【０１４９】
次のｄｅｖＴｙｐｅＩｄｅｎｔＸＭＬスキーマは、どのデータが許されるか定義する。この場合のデータタイプ名は、ｓ−ｄｅｖＴｙｐｅＩｄｅｎｔである。
【０１５０】
ｅメールフォルダ設定を交換するための設定ツリーデータコンテンツである、ｇｅｔＩｔｅｍｓコールに対するサーバー応答の一例を以下に示す。
【０１５１】
ＳｅｔＥｘにおいて、Ｃｌｅａｒコマンドは、以前のインストール又はデータベースアクチベーションのトレースをクリーンアップする正に第１のコマンドとしては使用されない。それ故、装置は、ＳｅｔＥｘデータタイプに対して第１同期を遂行するときに（アンカー０でのｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓコール）、それ自体でクリーンアッププロセスを開始する。装置がＳｅｔＥｘ要求に対して交換状態４１７を返送することによりｉｎｉｔＲｅｆｒｅｓｈコールを遂行するように強制するときには、同じ初期同期ルールが適用される。
【０１５２】
設定交換ファンクション
この章は、ｇｅｔＩｔｅｍｓ、ｐｕｔＩｔｅｍｓ、ａｃｋＩｔｅｍｓ及びｉｎｉｔＲｅｆｒｅｓｈを含むＤＰＲＥｘの変更された定義のリストを含む。ｇｅｔＩｔｅｍｓ及びｐｕｔＩｔｅｍｓについては、次の制約が適用される。即ち、ｒｅｃｏｒｄＩＤフィールドは使用されず、返送されるＥｘｃｈａｎｇｅＩｔｅｍインスタンスにおけるｉｔｅｍＴｙｐｅフィールドに対して「置き換え」及び「削除」だけがサポートされる。ＥｘｃｈａｎｇｅＩｔｅｍの「データ」フィールドは、設定データコンテンツを含む。
【０１５３】
ａｃｋＩｔｅｍｓについては、次の制約が適用される。即ち、ｒｅｃｏｒｄＩＤフィールドは使用されず、返送されるＥｘｃｈａｎｇｅＩｔｅｍインスタンスにおけるｉｔｅｍＴｙｐｅフィールドに対してＡｃｋ及びＡｃｋＡｌｌだけがサポートされる。このケースでは、データフィールドが使用されない。
【０１５４】
ｉｎｉｔＲｅｆｒｅｓｈメソッドは、２つのケースにおいて装置によりコールされる。第１に、装置がサーバーアラートに応答して装置に知られた全ての設定のダンプをスタートしようとしていることをサーバーに通知するのに使用される。これは、装置に知られた各データタイプに対して状態コード２５１により表わされた特殊な交換状態ＥｘｃｈａｎｇｅＡｌｌにおいて送信することで遂行される。第２に、装置は、ｇｅｔＩｔｅｍｓコールの後にサーバーにおける全ての既知の設定を検索することを希望する。装置は、各データタイプに対して状態コード２５１で表わされた状態ＩＮＩＴ＿ＲＥＦＲＥＳＨを送信することによりこれを行なう。
【０１５５】
アプリケーション交換プロトコル
アプリケーション交換プロトコルは、装置とサーバーとの間でソフトウェア変更を交換するプロセスを定義するのに使用される。アプリケーション交換機能は、ＸＭＬ＿ＲＰＣの最上部に新たなプロトコルを定義することを必須としたレコード及び設定の交換とは極めて異なる。アプリケーション交換（ＡｐｐＥｘ）ソフトウェアに対するプロトコルの流れ、データの構造及びファンクションは、以下の章で述べる。ＡｐｐＥｘプロトコルは、ａｐｐｓをベースＵＲＬ拡張として使用すると共に、バージョン番号及び外部ユーザＩＤをＵＲＬパラメータとして使用する。ＡｐｐＥｘ ＵＲＬの一例が、ｈｔｔｐ：／／ｗｗｗ．ｖｅｒｄｉｓｏｆｔ．ｃｏｍ／ｄｐ／ａｐｐｓ？ｅｘｔＩＤ＝２３４７ｄｈｊｉ３４＆ｖｅｒｓｉｏｎ＝１．０．１として示される。
【０１５６】
アプリケーション交換プロセスフロー
図２３は、本発明の一実施形態による装置とサーバーとの間のアプリケーション交換プロセスフローを示すシーケンス図である。図２３のソフトウェア交換プロセスフローにおけるステップのシーケンスを以下に説明する。
１）装置は、利用可能なアプリケーション変更についてサーバーに要求する。サーバーは、変更を利用可能にする全てのアプリケーションに対するセットアップ情報のリストを返送する。サーバーがソフトウェア変更をもたない場合には、ＡｐｐＥｘプロセスが終了となる。
２）装置は、セットアップ情報を処理し、ソフトウェア変更の実行をいつスタートすべきか判断する。
３）装置は、アプリケーションセットアップを開始する。サーバーは、装置が実行すべきセットアップコマンドのリストで応答する。
４）装置は、セットアップコマンドを処理し、アプリケーションセットアップに必要なファイルをダウンロードする。ファイルのダウンロードが失敗すると、装置は、残りのファイルのダウンロードを停止する。これは、首尾良くダウンロードされたソフトウェアをインストールし、次いで、シーケンスｄｅｖｉｃｅＳｅｔｕｐＳｔａｒｔ及びｄｅｖｉｃｅＳｅｔｕｐＥｎｄを適当なエラーコードと共に使用して、ダウンロードが失敗したことをサーバーに通知する。
５）装置は、アプリケーションセットアッププロセスが装置においてスタートすることをサーバーに通知する。この情報は、サーバーにより使用されて、装置上で変更されたソフトウェアに関連した全ての古いサービスを無効にする。サーバーは、特殊な状態コード３０１で応答して、装置が、ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅをコールすることで全プロセスを始めからスタートするよう強制する。１つのセットアップコマンドがフェイルすると、装置は、残りのコマンドの実行を停止する。
６）装置は、アプリケーションをスタートする。
７）アプリケーションは、それがインストールされたことをサーバーに通知する。サーバーは、このコールを使用して、装置の設定をスケジュールする。
８）装置は、サーバーから必要な設定をフェッチする。
９）アプリケーションは、自己テストの準備ができたことを任意の要求を通じてサーバーに通知する。サーバーは、このアプリケーションに対するある規定のテストデータをアクチベートする。
１０）装置は、装置におけるセットアッププロセスが指定のアプリケーションに対して完了したことをサーバーに通知する。要求の一部分として、装置は、新たなソフトウェア同期アンカーを送信する。
１１）アプリケーションは、使用の準備ができたことを任意の要求を通じてサーバーに通知する。
【０１５７】
アプリケーション交換データ構造
この章は、装置とサーバーとの間でのソフトウェアアプリケーションの交換に使用されるＸＭＬ＿ＲＰＣデータ構造を説明する。アプリケーション交換データ構造は、ＳｅｔｕｐＩｎｆｏ、ＳｅｔｕｐＩｎｆｏＩｔｅｍ、ＳｅｔｕｐＣｏｍｍａｎｄ、ＮａｍｅＶａｌｕｅＰａｉｒ、及びＡｐｐＥｘＲｅｓｕｌｔを含む。
【０１５８】
ＳｅｔｕｐＩｎｆｏ構造は、装置が利用可能なソフトウェア変更についてサーバーに要求するときに使用される。サーバーは、装置に利用可能なソフトウェア更新を表わすＳｅｔｕｐＩｎｆｏインスタンスを変更する。
データメンバー：
ｄｅｓｃｒｉｐｔｉｏｎ：これは、必須のフィールドであり、人間が読むことのできるものである。これは、全ソフトウェア更新を記述するもので、装置によって使用されて、ユーザが更新を受け容れるよう求められた場合にユーザに対しダイアログボックスでメッセージを表示するものである。
ｓｅｔｕｐＳｉｚｅ：これは、アプリケーション更新のためのスペース要求を指定する必須フィールドである。
ｓｕｎｓｈｉｎｅＤａｔｅ：これは、ソフトウェアを更新できるときを指定する任意のフィールドである。フォーマットは、ＵＴＣである。サーバーへのアクセスは、装置がソフトウェアを間に合うようにインストールしないときには拒絶される。このフィールドが欠けたときには、装置は、ソフトウェア変更を直ちに処理するが、さもなければ、ユーザは、更新を今得たいか後で得たいか尋ねられる。
ＳｅｔｕｐＩｎｆｏＩｔｅｍｓ：これは、任意のフィールドで、ソフトウェア変更が存在するときにＳｅｔｕｐＩｎｆｏＩｔｅｍ構造のアレーである。
【０１５９】
ＳｅｔｕｐＩｎｆｏＩｔｅｍ構造は、ＳｅｔｕｐＩｎｆｏ構造内で使用される。各ＳｅｔｕｐＩｎｆｏＩｔｅｍは、装置に利用できるソフトウェア変更を表わす。
データメンバー：
ｓｅｔｕｐＴｙｐｅ：これは、必須のフィールドであり、定数ＩＮＳＴＡＬＬ＝１、ＵＰＤＡＴＥ＝２、及びＵＮＩＮＳＴＡＬＬ＝３、のうちの１つを含む。
ａｄｄｉｔｉｏｎａｌＤｅｓｃｒｉｐｔｉｏｎ：これは、任意のフィールドで、このセットアップアイテムに対する記述が、ＳｅｔｕｐＩｎｆｏにおける全体的記述と独立し、それに追加されるもので、且つユーザに付加的に提示されることを指定する。このフラグが存在しないか又は偽である場合には、記述がユーザに提示されない。
ｓｅｔｕｐＩｎｆｏＩｄ：これは、必須のフィールドで、装置に対するアプリケーション設定変更を独特に識別する。
ｄｅｓｃｒｉｐｔｉｏｎ：これは、ソフトウェア変更を記述する任意のフィールドである。
【０１６０】
ＳｅｔｕｐＣｏｍｍａｎｄ構造は、セットアップコマンドをソフトウェア変更の一部分として送信するのに使用される。ＳｅｔｕｐＣｏｍｍａｎｄ構造及びそれに対応するデータメンバーの一例を以下に示す。
ｓｅｔｕｐＴｙｐｅ：これは、必須フィールドであり、定数ＩＮＳＴＡＬＬ＝１、ＵＰＤＡＴＥ＝２、及びＵＮＩＮＳＴＡＬＬ＝３、のうちの１つを含む。
ｉｔｅｍＲｅｆ：これは、必須のフィールドである。ＳｅｔｕｐＣｏｍｍａｎｄアレーにおけるＳｅｔｕｐＣｏｍｍａｎｄエレメントは、増加するアイテム参照番号でマークされる。このアイテム参照は、あるファンクションでは、アレーから１つのＳｅｔｕｐＣｏｍｍａｎｄエレメントを識別するのに使用される。
ＵＲＬ：ダウンロードすべきセットアップコマンド又はファイルに対してＵＲＬを指定する任意のフィールドである。このフィールドは、通常、デフォールトによりセットされる。しかしながら、あるプラットホームでは、アンインストールのためにダウンロードする必要のあるソフトウェアはない。
ＣＲＣＳｔｒ：これは、任意のフィールドで、ＣＲＣ−３２チェック和情報を含む。ＣＲＣは、ＣＲＣに基づくソフトウェアダウンロードをキャッシュ記憶するために装置により使用されてもよいし、又はダウンロードされたファイルが壊れたかどうかチェックするために使用されてもよい。
ｐｒｏｇｒａｍＩｄ：これは、必須のフィールドであり、セットアップされているアプリケーションプログラムを独特に識別するＩＤを含む。
ＮａｍｅＶａｌｕｅＰａｉｒｓ：これは、任意のフィールドであり、ＮａｍｅＶａｌｕｅＰａｉｒデータ構造を指定する。
【０１６１】
ＮａｍｅＶａｌｕｅＰａｉｒ構造は、ＳｅｔｕｐＣｏｍｍａｎｄ構造の一部分として使用される。ＮａｍｅＶａｌｕｅＰａｉｒ構造は、ネーム／バリュー対パラメータを指定するのに使用される。これらのパラメータは、このインストールに対して特定であり、例えば、特定のソフトウェア及び／又は装置タイプに必要とされるコマンドラインパラメータのような情報を搬送するのに使用される。
【０１６２】
ＡｐｐＥｘＲｅｓｕｌｔ構造は、メソッド要求の結果を返送するのに使用される。これは、アプリケーション交換に関する情報を含む。
データメンバー：
ＳｅｔｕｐＩｎｆｏ：これは、任意のフィールドで、アプリケーションセットアップ情報を装置へ返送するのに使用される。このフィールドは、装置がｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅをコールするときだけ返送される。
ＳｅｔｕｐＣｏｍｍａｎｄ：これは、任意のフィールドで、アプリケーション変更（インストール、更新、又はアンインストール）に関連したセットアップコマンドを返送するのに使用される。このフィールドは、装置がｉｎｉｔｉａｔｅＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓをコールするときに返送される。
ｒｅｓｕｌｔ：これは、必須のフィールドで、アプリケーション変更メソッド要求の結果を含む。
【０１６３】
アプリケーション交換ファンクション
この章は、装置とサーバーとの間でのアプリケーションの交換を遂行するのに使用されるファンクションを説明する。ＡｐｐＥｘファンクションは、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓ、ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓ、ｉｎｉｔｉａｔｅＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓ、ｄｅｖｉｃｅＳｅｔｕｐＳｔａｒｔｓ、ｄｅｖｉｃｅＳｅｔｕｐＥｎｄ、ａｐｐｌｉｃａｔｉｏｎＩｎｓｔａｌｌｅｄ、ａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＴｅｓｔ、ａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＧｏ、及びｉｎｉｔＲｅｆｒｅｓｈを含む。あるファンクションは、エラーコードをサーバーへ送信することができる。一実施形態では、エラーコードは、以下のテーブル５に定義される。
テーブル５
【０１６４】
ＥＲＲ＿ＣＡＮＴ＿ＤＯＷＮＬＯＡＤ＿ＦＩＬＥ又はＥＲＲ＿ＲＡＮ＿ＯＵＴ＿ＯＦ＿ＤＩＳＫＳＰＡＣＥのような装置ローカルエラーについては、装置は、エラーをサーバーへ報告する前に、エラーを固定するための全ての考えられるステップを試みる（例えば、インターネット接続をチェックしたりハードドライブをクリーンアップしたりするようにユーザに頼む）ことに注意されたい。装置が現在ソフトウェア変更の問題を報告するためにエラーコードを送信するときには、サーバーが装置をディスエイブルする。
【０１６５】
ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓは、装置が始動するたびに使用され、装置に知られた現在ソフトウェアアンカーを送信する。装置が保留中アンカーを有するときには、その保留中アンカーをサーバーにも送信する。或いは又、装置が保留中アンカーをもたないときには、保留中アンカーがサーバーへ送信されない。サーバーは、受け取ったアンカーを、サーバーに記憶されたアンカーと比較し、装置及びサーバーが同期ずれしているかどうか決定する。
AppExResult checkSyncAnchors (String anchor, StringpendingAnchor)
リターン：アンカーが一致するときには結果が２００であり、アンカーが不一致のときには結果が４１７であるようなＡｐｐＥｘＲｅｓｕｌｔのインスタンス
【０１６６】
ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓメソッドは、装置に利用できる全アプリケーション更新のリストに関する情報を返送する。
AppExResult getApplicationUpdates (String anchor)
リターン：ソフトウェア変更が利用できるときにＳｅｔｕｐＩｎｆｏ構造を含むＡｐｐＥｘＲｅｓｕｌｔのインスタンス。さもなければ、ＳｅｔｕｐＩｎｆｏメンバーはセットされない。
パラメータ：
・ａｎｃｈｏｒ−装置は、新たなアンカーを送信する。
【０１６７】
ｉｎｉｔｉａｔｅＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓメソッドは、サーバーからインストラクションのリストを得て、アプリケーション変更（インストール、更新、又はアンインストール）プロセスをスタートするために、装置により呼び出される。サーバーにより返送される情報は、ダウンロードされるべきファイルと、装置上で実行されるべきコマンドとを含む。装置は、返送されたセットアップコマンドに載せられた順序でアプリケーション変更コマンドを実行する。
AppExResult initiateApplicationUpdates (String[] setupInfoIds)
リターン：ＳｅｔｕｐＣｏｍｍａｎｄアレーを含むＡｐｐＥｘＲｅｓｕｌｔのインスタンス。
パラメータ：ｓｅｔｕｐＩｎｆｏＩｄｓ−パラメータとして、装置は、ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓ応答からｓｅｔｕｐＩｎｆｏＩｄｓを送信する。
【０１６８】
ｄｅｖｉｃｅＳｅｔｕｐＳｔａｒｔｓメソッドは、装置においてアプリケーションセットアップがスタートしたことをサーバーに通知する。これは、変更されているソフトウェアに関連した全ての古いサービスをサーバーが無効化できるようにする。他方、装置がアプリケーション更新プロセスを開始した後であって且つこのファンクションコールの前に新たなアプリケーション更新がサーバーにおいて追加された場合には、サーバーは、新たなアプリケーション更新が存在することを指示するエラーコード３０１を返送する。これが生じると、装置は、アプリケーション更新プロセスを再スタートする。
AppExResult deviceSetupStarts()
リターン：装置がＡｐｐＥｘプロセスを再スタートすることを指示するために結果コード３０１を発生するＡｐｐＥｘＲｅｓｕｌｔのインスタンス。
【０１６９】
装置は、このメソッドを要求することを試み、そしてサーバーから応答が返送されないときには、要求がサーバーにより受け取られたかどうか、又はサーバーからの応答が失われたかどうか分らない。この場合には、装置は、このメソッドに対して新たな要求で試みる。これは、応答が失われた場合には４２０エラーコードを生じさせることに注意されたい。
【０１７０】
ｄｅｖｉｃｅＳｅｔｕｐＥｎｄメソッドは、装置におけるアプリケーションセットアップが完了したことをサーバーに通知する。サーバーは、更なるソフトウェア変更がサーバーにおいてその間にスケジュールされたかどうかチェックし、そして必要に応じて新たな通知を送出する。
AppExResult deviceSetupEnds (String anchor, int itemRef, int errorCode, StringerrorMsg)
パラメータ：
・ａｎｃｈｏｒ−装置は、現在インストールされたソフトウェアを表わす新たなアンカーを送信する。
・ｉｔｅｍＲｅｆ：このパラメータは、２つの方法で使用される。
第１に、ｉｔｅｍＲｅｆは、位置“Ｎ”のコマンド、及びセットアップコマンドアレーにおいてその位置“Ｎ”より低い他の全てのコマンドは成功であり、そして他の全てのコマンドは実行されないことを指定する。
第２に、ｉｔｅｍＲｅｆは、ｉｔｅｍＲｅｆにより指定された位置、例えば、“Ｍ”におけるコマンドに対するセットアップが失敗し、“Ｍ”より低いオフセットをもつ他の全てのコマンドが成功であり、そして“Ｍ”より大きなオフセットをもつ全てのコマンドが実行されないことを指示する。
・ｅｒｒｏｒＣｏｄｅ−エラーの場合に、エラーの原因がここにリストされる。さもなければ、“ＯＫ”コードが返送される。
・ｅｒｒｏｒＭｓｇ−このパラメータは、詳細なエラーメッセージを指定する。成功の場合には、このフィールドは、ナルである。
リターン：ＡｐｐＥｘＲｅｓｕｌｔのインスタント
【０１７１】
このメソッドは、通常のオペレーションのもとでコールされる。現在ＡｐｐＥｘプロセスが、ＡｐｐＥｘコードを含むプログラムをアンインストールする場合には、装置は、アンインストールをスタートする直前にこのメソッドをコールする。
【０１７２】
ａｐｐｌｉｃａｔｉｏｎＩｎｓｔａｌｌｅｄメソッドは、アプリケーションがインストールされ又は更新されたことをサーバーに通知する。これは、ＲＥｘ ＡＰＩ又はＳｅｔＥｘ ＡＰＩを使用して装置とサーバーとの間でデータを同期する各アプリケーションに対して必須である。このメソッドの主たる使用は、プログラム更新のためである。サーバーは、このメソッドをコールして、更新されたソフトウェアにより使用される設定をアクチベートする。
AppExResult ApplicationInstalled(String programId, int errorCode, String errorMsg)
パラメータ：
・ｐｒｏｇｒａｍＩｄ−サーバー側でアプリケーションサービスを独特に識別する
・ｅｒｒｏｒＣｏｄｅ−エラーの場合には、エラーの原因がここにリストされる。さもなければ、ＯＫコードが返送される。
・ｅｒｒｏｒＭｓｇ−詳細なエラーメッセージを指定する。首尾良いアプリケーションインストールの場合には、このフィールドがナルである。
リターン：ＡｐｐＥｘＲｅｓｕｌｔのインスタンス
【０１７３】
ａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＴｅｓｔメソッドは、あるテストを行なって、それが正しく働くかどうかチェックすることを希望する旨、サーバーに通知する。サーバーは、このメソッドを使用して、あるテストデータをアクチベートする。
AppExResult ApplicationReadyToTest (String programId, int errorCode, String errorMsg)
パラメータ
・ｐｒｏｇｒａｍＩｄ−サーバー側のアプリケーションサービスを独特に識別する
・ｅｏｏｒＣｏｄｅ−エラーの場合、エラーの原因がここにリストされる。さもなければ、“ＯＫ”コードが返送される。
・ｅｒｒｏｒＭｓｇ−詳細なエラーメッセージを指定する。成功の場合、このフィールドは、ナルである。
リターン：ＡｐｐＥｘＲｅｓｕｌｔのインスタンス
【０１７４】
ａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＧｏメソッドは、使用の準備ができたことをサーバーに通知する。ａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＧｏメソッドをコールするには、ａｐｐｌｉｃａｔｉｏｎＩｎｓｔａｌｌｅｄ又はａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＴｅｓｔをコールする各プログラムが必要とされる。
AppExResult ApplicationReadyToGo (String programId, int errorCode, String errorMsg)
パラメータ
・ｐｒｏｇｒａｍＩｄ−サーバー側のアプリケーションサービスを独特に識別する
・ｅｏｏｒＣｏｄｅ−エラーの場合、エラーの原因がここにリストされる。さもなければ、“ＯＫ”コードが返送される。
・ｅｒｒｏｒＭｓｇ−詳細なエラーメッセージを指定する。成功の場合、このフィールドは、ナルである。
リターン：ＡｐｐＥｘＲｅｓｕｌｔのインスタンス
【０１７５】
ｉｎｉｔＲｅｆｒｅｓｈメソッドは、装置が、装置において全てのソフトウェアを再インストールしたいことをサーバーに通知するときに、使用される。サーバーは、この要求を受け取ると、装置にあってもよい全てのソフトウェアをインストールのためにマークする。装置は、このコールに対して首尾良い応答を受け取ると、完全なＡｐｐＥｘプロセスを遂行して、コマンドを検索する。
AppExResult initRefresh()
リターン：ＡｐｐＥｘＲｅｓｕｌｔのインスタンス
【０１７６】
サーバーは、装置に対するソフトウェア変更を有するときに通知を送信する。装置がｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓをコールするときに、サーバーは、装置が通知を受け取ったと仮定し、そしてサーバー側の通知をクリアする。これは、ユーザがソフトウェアの変更を延期する場合及び装置が再スタートされる場合の両方に装置がｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓの結果を永続的なものにすることを意味する。装置は、ＡｐｐＥｘプロセスの中間で通知を受け取ると、その通知を無視することができる。装置がｄｅｖｉｃｅＳｅｔｕｐＥｎｄをコールしてＡｐｐＥｘプロセスを終了すると、サーバーは、更なるソフトウェア変更が存在するかどうかチェックし、そして必要に応じて新たな通知を送出する。
【０１７７】
アプリケーション交換状態コード
設定交換において、装置がゾンビモードにあるときに状態コード３００が返送される。この場合には、装置は、最初に、装置プロビジョニングプロトコルを使用して装置タイプ識別を送信し、ゾンビモードを出る。
【０１７８】
ｄｅｖｉｃｅＳｅｔｕｐＳｔａｒｔｓメソッドへのコールは、装置がｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓをコールすることにより全ＡｐｐＥｘプロセスを始めからスタートするように強制する３０１結果コードを返送することができる。ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅｓに対する要求は、ソフトウェア変更が存在するかどうかサーバーが現在決定できないときに３０２結果コードを返送することができる。これは、サーバーが、ａｐｐｌｉｃａｔｉｏｎＩｎｓｔａｌｌｅｄ及び／又はａｐｐｌｉｃａｔｉｏｎＲｅａｄｙＴｏＧｏをコールするために、新たにインストール又は更新されたソフトウェアプログラムを待機するときに生じることがある。この場合、装置は、遅延を増加しながら要求を後で数回再試みする。数回の再試みの後に、サーバーが、依然、３０２状態コードで応答する場合には、装置は、全ＡｐｐＥｘプロセスを終了し、次の通知を単に待機することになる。
【０１７９】
ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓメソッドへのコールは、装置上のソフトウェアと、サーバーが装置上にあると考えているソフトウェアとが異なるものであることを指示する４１７結果コードを返送することができる。サーバーへの各コールは、エラーコード５００を生じさせる。これは、サーバーがこのとき何らかの理由で装置コールに応答できないことを指示する一時的サーバーエラーである。データコンテンツは、サーバーにより検査されず、従って、間違っているとは考えられない。クライアントは、前記のように、同じインターバルを使用して同じ要求を再試みする。所与の回数の再試みの後に、クライアントは、再試みを終了し、そして通知又はポーリング時間切れといった次の通常の同期事象を待機する。
【０１８０】
ソフトウェア同期アンカー
ソフトウェア同期アンカーは、装置上のソフトウェアが、サーバーが装置上にあると考えているソフトウェアとは異なるときを検出するのに使用される。これは、ユーザが全装置をバックアップするように試みるときに生じる。この状況では、装置上のソフトウェアは、装置がバックアップから回復する前にサーバーにより装置にインストールされたソフトウェアと適合しないことがある。
【０１８１】
装置及びサーバーは、両方とも、それらが始めに同期することを保証するために同じソフトウェア同期アンカー値に初期化される。装置は、同期アンカーを駆動する。装置は、ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅ又はｄｅｖｉｃｅＳｅｔｕｐＥｎｄをコールするたびに、新たなアンカーをサーバーへ送信し、サーバーは、そのアンカーを記憶する。装置は、コールに対する首尾良い応答をサーバーから受け取ると、現在アンカーを、サーバーへ送信された新たなアンカーに置き換える。ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅ又はｄｅｖｉｃｅＳｅｔｕｐＥｎｄへのコールが失敗すると、装置は、サーバーが要求を受け取って新たなアンカーを記憶したかどうか分らない。それ故、装置は、要求を再びコールするよう試みるときに保留中の新たなアンカーを再送信する。
【０１８２】
装置は、スタートするたびに、ｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒを使用してサーバーへ現在アンカーを送信する。装置は、ｄｅｖｉｃｅＳｅｔｕｐＥｎｄコールに対して首尾良い応答を得ていない保留中の新規なアンカーを有するときに、このアンカーをｃｈｅｃｋＳｙｎｃＡｎｃｈｏｒｓコールへのパラメータとして送信する。サーバーは、送られたアンカー（又は送信されたアンカー）を、装置から受け取った最後のアンカーと比較する。アンカーが一致しないときには、装置は、ユーザへ問題を報告し、そしてｉｎｉｔＲｅｆｒｅｓｈをコールして、スクラッチから完全ソフトウェアインストールをスタートする。
【０１８３】
アプリケーション交換状態
サーバーは、ソフトウェアインストール、アンインストール又は更新プロセス中には、２つの状態の一方にある。図２４は、本発明の一実施形態によるアプリケーション交換状態遷移図である。装置が不法メソッドをコールすると、エラー状態は、サーバーが４２０状態コードをこのコールに対する応答として返送するようにさせる。その後、状態マシンは、その状態へ復帰し、そこからエラー状態へ移行する。
【０１８４】
エラー状態から出るために、装置は、ｇｅｔＡｐｐｌｉｃａｔｉｏｎＵｐｄａｔｅをコールし、そして全アプリケーション交換プロセスを再スタートする。これを行なうために、装置は、エラーコード（例えば、２００）で且つ−１をｉｔｅｍＲｅｆとして、ｄｅｖｉｃｅＳｅｔｕｐＥｎｄをコールする。次いで、以前に割り込まれたプロセスに対してクリーンな状態から新たなＡｐｐＥｘプロセスをスタートする。
【０１８５】
アプリケーション交換インストール及び更新
装置がＡｐｐＥｘを経てソフトウェアをインストールし又は更新するときに、インストール又は更新がフェイルすることがある。変更がセットアッププログラムにより完全にロールバックされていないときには（装置がクラッシュしたために）、ソフトウェアがもはや使用できないことがある。これは、装置上でＡｐｐＥｘを遂行するソフトウェアを装置が更新するよう試みる場合に重大となる。
【０１８６】
装置は、サーバーとのＡｐｐＥｘをまだ実行できる場合に、ｉｎｉｔＲｅｆｒｅｓｈメソッドを、次いで、ＡｐｐＥｘプロセスをコールして、装置上の全てのソフトウェアプログラムを（従って、壊れたソフトウェアプログラムも）再インストールするよう試みることができる。装置は、ＡｐｐＥｘプログラムをもはや実行できない場合には、ローダーを使用して、装置能力、例えば、装置タイプ識別情報を送信し、この場合も、ＵＲＬをリモートインストーラーへ配送する。このコールは、サーバー側で全てのソフトウェアプログラムが再インストールに対してマークされることを意味する。装置は、リモートインストーラーをインストールし、次いで、ＡｐｐＥｘを使用して、ソフトウェアプログラムを再インストールする。
【０１８７】
以上、明瞭化のために、異なる機能的ユニット及びプロセッサを参照して本発明の実施形態について説明されたことが明らかであろう。しかしながら、本発明から逸脱せずに、異なる機能的ユニット又はプロセッサ間に機能を適宜に分散させられることも明らかであろう。例えば、個別のプロセッサ又はコントローラにより遂行されるべき機能は、同じプロセッサ又はコントローラによって遂行されてもよい。従って、特定の機能的ユニットを参照することは、厳密な論理的又は物理的構造又は編成を表わすのではなく、前記機能を与える適当な手段を参照するに過ぎないことが明らかであろう。
【０１８８】
本発明は、ハードウェア、ソフトウェア、ファームウェア又はその組み合せを含む任意の適当な形態で実施することができる。又、本発明は、１つ以上のデータプロセッサ及び／又はデジタル信号プロセッサ上で実行されるコンピュータソフトウェアとして部分的に実施されるのも任意である。本発明の実施形態のエレメント及びコンポーネントは、任意の適当な仕方で物理的に、機能的に及び論理的に実施されてもよい。実際に、機能は、単一ユニットで実施されてもよいし、複数のユニットで実施されてもよいし、又は他の機能的ユニットの一部分として実施されてもよい。従って、本発明は、単一のユニットで実施されてもよく、又は異なるユニットとプロセッサとの間に物理的及び機能的に分散されてもよい。
【０１８９】
当業者であれば、同じ基本的なメカニズム及び方法を使用しながら、ここに開示された実施形態の多数の考えられる変更や組み合せも使用できることが明らかであろう。以上の説明は、例示の目的で特定の実施形態を参照して書かれたものであった。しかしながら、前記説明は、これに尽きるものでもないし、又、本発明をこれに限定するものでもない。前記教示に鑑み、多数の変更や修正が考えられる。前記実施形態は、本発明の原理及びそれらの実際の応用を説明すると共に、当業者が、本発明及び種々の実施形態を、意図された特定用途に適するように種々変更を加えて最良に利用できるようにするために、選択されて説明されたものである。
【特許請求の範囲】
【請求項１】
通信ネットワーク内で１つ以上のユーザ装置を接続するための複数のエントリーポイントを与えるシステムにおいて、
前記１つ以上のユーザ装置と通信するサーバーであって、該サーバーが接続データセットを含み、且つ前記１つ以上のユーザ装置が前記接続データセットの部分を共有するようにしたサーバーと、
前記複数のエントリーポイントの１つから前記接続データセットにアクセスする要求をユーザ装置から受け取るためのロジックと、
前記ユーザ装置の属性を自動的に決定するためのロジックと、
前記ユーザ装置の属性を使用して所定のクライアント装置のデータベースから通信メソッドを選択するためのロジックと、
前記通信メソッドに基づき前記ユーザ装置をプロビジョニングするためのロジックと、を備えたシステム。
【請求項２】
前記１つ以上のユーザ装置は、少なくとも１つ以上のセルラー電話、ワイヤレスパーソナルデジタルアシスタント、ナビゲーション装置、パーソナルコンピュータ、ゲームコンソール、インターネットターミナル、及びキオスクを含む、請求項１に記載のシステム。
【請求項３】
前記接続データセットは、少なくとも１つ以上のｅメール、連絡先、カレンダー、タスク、ノート、ピクチャー、音楽、ドキュメント、ビデオ、ブックマーク、及びリンクを含む、請求項１に記載のシステム。
【請求項４】
前記サーバーは、多数の地理的位置に分散された１つ以上のコンピュータ及びデータ記憶システムを含む、請求項１に記載のシステム。
【請求項５】
前記属性は、
装置タイプ記述と、
サービス記述と、
トランスコーディングと、
アカウントテンプレートと、
を含む請求項１に記載のシステム。
【請求項６】
前記ユーザ装置をプロビジョニングするためのロジックは、
ＳＭＳベースのプロビジョニングを遂行するロジックと、
装置ブラウザベースのプロビジョニングを遂行するロジックと、
実行可能なプログラムベースのプロビジョニングを遂行するロジックと、
ＡｃｔｉｖｅＸベースのプロビジョニングを遂行するロジックと、
を含む請求項１に記載のシステム。
【請求項７】
ＳＭＳベースのプロビジョニングを遂行する前記ロジックは、
証明書を要求しているユーザ装置へＵＲＬを送出するロジックであって、この証明書がｅメールアドレス及びパスワードを含むようなロジックと、
前記ユーザ装置から前記証明書を受け取るロジックと、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へプロビジョニングＳＭＳを送出するロジックと、
を含む請求項６に記載のシステム。
【請求項８】
装置ブラウザベースのプロビジョニングを遂行する前記ロジックは、
証明書を要求しているユーザ装置へ新たな装置インジケータを送出するロジックであって、この証明書が電話番号を含むようなロジックと、
前記ユーザ装置から前記証明書を受け取るロジックと、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へプロビジョニングＳＭＳを送出するロジックと、
を含む請求項６に記載のシステム。
【請求項９】
実行可能なプログラムベースのプロビジョニングを遂行する前記ロジックは、
前記ユーザ装置がＳＤＫ装置であるかどうか決定するロジックと、
前記ユーザ装置を構成しそして証明書を要求するために前記ユーザ装置に実行可能なプログラムを送出するロジックであって、前記証明書が電話番号を含むようなロジックと、 前記ユーザ装置から前記証明書を受け取るロジックと、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へ前記構成をダウンロードするロジックと、
を含む請求項６に記載のシステム。
【請求項１０】
構成をダウンロードする前記ロジックは、
コンピュータプログラムをインストールするロジックと、
フィルタを適用するロジックと、
前記接続データセットに接続を適用するロジックと、
を備えた請求項９に記載のシステム。
【請求項１１】
ＡｃｔｉｖｅＸベースのプロビジョニングを遂行する前記ロジックは、
ユーザ装置がＡｃｔｉｖｅＸイネーブルされたかどうか決定するロジックと、
ユーザ装置がＡｃｔｉｖｅＸイネーブルされた場合には、前記ユーザ装置にＡｃｔｉｖｅＸローダーをインストールするロジックと、
前記ユーザ装置において前記ＡｃｔｉｖｅＸローダーを実行するロジックと、
を備えた請求項６に記載のシステム。
【請求項１２】
ユーザ装置をプロビジョニングする前記ロジックは、更に、
前記ユーザ装置へサービスをアクチベートするロジックと、
前記ユーザ装置からデータをインポートするロジックと、
前記ユーザ装置を所定のアカウントに接続するロジックと、
複写レコードを取り扱うロジックと、
前記レコードを前記ユーザ装置へ送出するロジックと、
を含む請求項６に記載のシステム。
【請求項１３】
通信ネットワーク内で１つ以上のユーザ装置を接続するための複数のエントリーポイントを与える方法において、
前記１つ以上のユーザ装置と通信するサーバーを用意するステップであって、該サーバーが接続データセットを含み、且つ前記１つ以上のユーザ装置が前記接続データセットの部分を共有するようにしたステップと、
前記複数のエントリーポイントの１つから前記接続データセットにアクセスする要求をユーザ装置から受け取るステップと、
前記ユーザ装置の属性を自動的に決定するステップと、
前記ユーザ装置の属性を使用して所定のクライアント装置のデータベースから通信メソッドを選択するステップと、
前記通信メソッドに基づいてユーザ装置をプロビジョニングするステップと、
を備えた方法。
【請求項１４】
前記１つ以上のユーザ装置は、少なくとも１つ以上のセルラー電話、ワイヤレスパーソナルデジタルアシスタント、ナビゲーション装置、パーソナルコンピュータ、ゲームコンソール、インターネットターミナル、及びキオスクを含む、請求項１３に記載の方法。
【請求項１５】
前記接続データセットは、少なくとも１つ以上のｅメール、連絡先、カレンダー、タスク、ノート、ピクチャー、音楽、ドキュメント、ビデオ、ブックマーク、及びリンクを含む、請求項１３に記載の方法。
【請求項１６】
前記サーバーは、多数の地理的位置に分散された１つ以上のコンピュータ及びデータ記憶システムを含む、請求項１３に記載の方法。
【請求項１７】
前記属性は、
装置タイプ記述と、
サービス記述と、
トランスコーディングと、
アカウントテンプレートと、
を含む請求項１３に記載の方法。
【請求項１８】
ユーザ装置をプロビジョニングするための前記ステップは、
ＳＭＳベースのプロビジョニングを遂行する段階と、
装置ブラウザベースのプロビジョニングを遂行する段階と、
実行可能なプログラムベースのプロビジョニングを遂行する段階と、
ＡｃｔｉｖｅＸベースのプロビジョニングを遂行する段階と、
を含む請求項１３に記載の方法。
【請求項１９】
ＳＭＳベースのプロビジョニングを遂行する前記段階は、
証明書を要求しているユーザ装置へＵＲＬを送出し、この証明書は、ｅメールアドレス及びパスワードを含むものであり、
前記ユーザ装置から前記証明書を受け取り、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へプロビジョニングＳＭＳを送出する、
ことを含む請求項１８に記載の方法。
【請求項２０】
装置ブラウザベースのプロビジョニングを遂行する前記段階は、
証明書を要求しているユーザ装置へ新たな装置インジケータを送出し、この証明書は、電話番号を含むものであり、
前記ユーザ装置から前記証明書を受け取り、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へプロビジョニングＳＭＳを送出する、
ことを含む請求項１８に記載の方法。
【請求項２１】
実行可能なプログラムベースのプロビジョニングを遂行する前記段階は、
前記ユーザ装置がＳＤＫ装置であるかどうか決定し、
前記ユーザ装置を構成しそして証明書を要求するために前記ユーザ装置に実行可能なプログラムを送出し、前記証明書は、電話番号を含むものであり、
前記ユーザ装置から前記証明書を受け取り、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へ前記構成をダウンロードする、
ことを含む請求項１８に記載の方法。
【請求項２２】
構成をダウンロードすることは、
コンピュータプログラムをインストールし、
フィルタを適用し、
前記接続データセットに接続を適用する、
ことを含む請求項２１に記載の方法。
【請求項２３】
ＡｃｔｉｖｅＸベースのプロビジョニングを遂行する前記段階は、
ユーザ装置がＡｃｔｉｖｅＸイネーブルされたかどうか決定し、
ユーザ装置がＡｃｔｉｖｅＸイネーブルされた場合には、前記ユーザ装置にＡｃｔｉｖｅＸローダーをインストールし、
前記ユーザ装置において前記ＡｃｔｉｖｅＸローダーを実行する、
ことを含む請求項１８に記載の方法。
【請求項２４】
ユーザ装置をプロビジョニングする前記ステップは、更に、
前記ユーザ装置へサービスをアクチベートする段階と、
前記ユーザ装置からデータをインポートする段階と、
前記ユーザ装置を所定のアカウントに接続する段階と、
複写レコードを取り扱う段階と、
前記レコードを前記ユーザ装置へ送出する段階と、
を含む請求項１８に記載の方法。
【請求項２５】
通信ネットワーク内で１つ以上のユーザ装置を接続するための複数のエントリーポイントを与えるコンピュータプログラム製品であって、少なくともプロセッサユニット、ユーザインターフェイス及びメモリを有する１つ以上のコンピュータシステムにより実行するためのコンピュータプログラムを記憶するメディアを備えたコンピュータプログラム製品において、
サーバーと前記１つ以上のユーザ装置との間で通信するためのコードであって、前記サーバーが接続データセットを含み、且つ前記１つ以上のユーザ装置が前記接続データセットの部分を共有するようにしたコードと、
前記複数のエントリーポイントの１つから前記接続データセットにアクセスする要求をユーザ装置から受け取るためのコードと、
前記ユーザ装置の属性を自動的に決定するためのコードと、
前記ユーザ装置の属性を使用して所定のクライアント装置のデータベースから通信メソッドを選択するためのコードと、
前記通信メソッドに基づき前記ユーザ装置をプロビジョニングするためのコードと、
を備えたコンピュータプログラム製品。
【請求項２６】
前記１つ以上のユーザ装置は、少なくとも１つ以上のセルラー電話、ワイヤレスパーソナルデジタルアシスタント、ナビゲーション装置、パーソナルコンピュータ、ゲームコンソール、インターネットターミナル、及びキオスクを含む、請求項２５に記載のコンピュータプログラム製品。
【請求項２７】
前記接続データセットは、少なくとも１つ以上のｅメール、連絡先、カレンダー、タスク、ノート、ピクチャー、音楽、ドキュメント、ビデオ、ブックマーク、及びリンクを含む、請求項２５に記載のコンピュータプログラム製品。
【請求項２８】
前記サーバーは、多数の地理的位置に分散された１つ以上のコンピュータ及びデータ記憶システムを含む、請求項２５に記載のコンピュータプログラム製品。
【請求項２９】
前記属性は、
装置タイプ記述と、
サービス記述と、
トランスコーディングと、
アカウントテンプレートと、
を含む請求項２５に記載のコンピュータプログラム製品。
【請求項３０】
ユーザ装置をプロビジョニングするための前記コードは、
ＳＭＳベースのプロビジョニングを遂行するコードと、
装置ブラウザベースのプロビジョニングを遂行するコードと、
実行可能なプログラムベースのプロビジョニングを遂行するコードと、
ＡｃｔｉｖｅＸベースのプロビジョニングを遂行するコードと、
を含む請求項２５に記載のコンピュータプログラム製品。
【請求項３１】
ＳＭＳベースのプロビジョニングを遂行する前記コードは、
証明書を要求しているユーザ装置へＵＲＬを送出するコードであって、前記証明書がｅメールアドレス及びパスワードを含むようなコードと、
前記ユーザ装置から前記証明書を受け取るコードと、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へプロビジョニングＳＭＳを送出するコードと、
を含む請求項３０に記載のコンピュータプログラム製品。
【請求項３２】
装置ブラウザベースのプロビジョニングを遂行する前記コードは、
証明書を要求しているユーザ装置へ新たな装置インジケータを送出するコードであって、この証明書が電話番号を含むようなコードと、
前記ユーザ装置から前記証明書を受け取るコードと、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へプロビジョニングＳＭＳを送出するコードと、
を含む請求項３０に記載のコンピュータプログラム製品。
【請求項３３】
実行可能なプログラムベースのプロビジョニングを遂行する前記コードは、
前記ユーザ装置がＳＤＫ装置であるかどうか決定するコードと、
前記ユーザ装置を構成しそして証明書を要求するために前記ユーザ装置に実行可能なプログラムを送出するコードであって、前記証明書が電話番号を含むようなコードと、
前記ユーザ装置から前記証明書を受け取るコードと、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へ前記構成をダウンロードするコードと、
を含む請求項３０に記載のコンピュータプログラム製品。
【請求項３４】
構成をダウンロードする前記コードは、
コンピュータプログラムをインストールするコードと、
フィルタを適用するコードと、
前記接続データセットに接続を適用するコードと、
を備えた請求項３３に記載のコンピュータプログラム製品。
【請求項３５】
ＡｃｔｉｖｅＸベースのプロビジョニングを遂行する前記コードは、
ユーザ装置がＡｃｔｉｖｅＸイネーブルされたかどうか決定するコードと、
ユーザ装置がＡｃｔｉｖｅＸイネーブルされた場合には、前記ユーザ装置にＡｃｔｉｖｅＸローダーをインストールするコードと、
前記ユーザ装置において前記ＡｃｔｉｖｅＸローダーを実行するコードと、
を備えた請求項３０に記載のコンピュータプログラム製品。
【請求項３６】
ユーザ装置をプロビジョニングする前記コードは、更に、
前記ユーザ装置へサービスをアクチベートするコードと、
前記ユーザ装置からデータをインポートするコードと、
前記ユーザ装置を所定のアカウントに接続するコードと、
複写レコードを取り扱うコードと、
前記レコードを前記ユーザ装置へ送出するコードと、
を含む請求項３０に記載のコンピュータプログラム製品。
【請求項１】
通信ネットワーク内で１つ以上のユーザ装置を接続するための複数のエントリーポイントを与えるシステムにおいて、
前記１つ以上のユーザ装置と通信するサーバーであって、該サーバーが接続データセットを含み、且つ前記１つ以上のユーザ装置が前記接続データセットの部分を共有するようにしたサーバーと、
前記複数のエントリーポイントの１つから前記接続データセットにアクセスする要求をユーザ装置から受け取るためのロジックと、
前記ユーザ装置の属性を自動的に決定するためのロジックと、
前記ユーザ装置の属性を使用して所定のクライアント装置のデータベースから通信メソッドを選択するためのロジックと、
前記通信メソッドに基づき前記ユーザ装置をプロビジョニングするためのロジックと、を備えたシステム。
【請求項２】
前記１つ以上のユーザ装置は、少なくとも１つ以上のセルラー電話、ワイヤレスパーソナルデジタルアシスタント、ナビゲーション装置、パーソナルコンピュータ、ゲームコンソール、インターネットターミナル、及びキオスクを含む、請求項１に記載のシステム。
【請求項３】
前記接続データセットは、少なくとも１つ以上のｅメール、連絡先、カレンダー、タスク、ノート、ピクチャー、音楽、ドキュメント、ビデオ、ブックマーク、及びリンクを含む、請求項１に記載のシステム。
【請求項４】
前記サーバーは、多数の地理的位置に分散された１つ以上のコンピュータ及びデータ記憶システムを含む、請求項１に記載のシステム。
【請求項５】
前記属性は、
装置タイプ記述と、
サービス記述と、
トランスコーディングと、
アカウントテンプレートと、
を含む請求項１に記載のシステム。
【請求項６】
前記ユーザ装置をプロビジョニングするためのロジックは、
ＳＭＳベースのプロビジョニングを遂行するロジックと、
装置ブラウザベースのプロビジョニングを遂行するロジックと、
実行可能なプログラムベースのプロビジョニングを遂行するロジックと、
ＡｃｔｉｖｅＸベースのプロビジョニングを遂行するロジックと、
を含む請求項１に記載のシステム。
【請求項７】
ＳＭＳベースのプロビジョニングを遂行する前記ロジックは、
証明書を要求しているユーザ装置へＵＲＬを送出するロジックであって、この証明書がｅメールアドレス及びパスワードを含むようなロジックと、
前記ユーザ装置から前記証明書を受け取るロジックと、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へプロビジョニングＳＭＳを送出するロジックと、
を含む請求項６に記載のシステム。
【請求項８】
装置ブラウザベースのプロビジョニングを遂行する前記ロジックは、
証明書を要求しているユーザ装置へ新たな装置インジケータを送出するロジックであって、この証明書が電話番号を含むようなロジックと、
前記ユーザ装置から前記証明書を受け取るロジックと、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へプロビジョニングＳＭＳを送出するロジックと、
を含む請求項６に記載のシステム。
【請求項９】
実行可能なプログラムベースのプロビジョニングを遂行する前記ロジックは、
前記ユーザ装置がＳＤＫ装置であるかどうか決定するロジックと、
前記ユーザ装置を構成しそして証明書を要求するために前記ユーザ装置に実行可能なプログラムを送出するロジックであって、前記証明書が電話番号を含むようなロジックと、 前記ユーザ装置から前記証明書を受け取るロジックと、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へ前記構成をダウンロードするロジックと、
を含む請求項６に記載のシステム。
【請求項１０】
構成をダウンロードする前記ロジックは、
コンピュータプログラムをインストールするロジックと、
フィルタを適用するロジックと、
前記接続データセットに接続を適用するロジックと、
を備えた請求項９に記載のシステム。
【請求項１１】
ＡｃｔｉｖｅＸベースのプロビジョニングを遂行する前記ロジックは、
ユーザ装置がＡｃｔｉｖｅＸイネーブルされたかどうか決定するロジックと、
ユーザ装置がＡｃｔｉｖｅＸイネーブルされた場合には、前記ユーザ装置にＡｃｔｉｖｅＸローダーをインストールするロジックと、
前記ユーザ装置において前記ＡｃｔｉｖｅＸローダーを実行するロジックと、
を備えた請求項６に記載のシステム。
【請求項１２】
ユーザ装置をプロビジョニングする前記ロジックは、更に、
前記ユーザ装置へサービスをアクチベートするロジックと、
前記ユーザ装置からデータをインポートするロジックと、
前記ユーザ装置を所定のアカウントに接続するロジックと、
複写レコードを取り扱うロジックと、
前記レコードを前記ユーザ装置へ送出するロジックと、
を含む請求項６に記載のシステム。
【請求項１３】
通信ネットワーク内で１つ以上のユーザ装置を接続するための複数のエントリーポイントを与える方法において、
前記１つ以上のユーザ装置と通信するサーバーを用意するステップであって、該サーバーが接続データセットを含み、且つ前記１つ以上のユーザ装置が前記接続データセットの部分を共有するようにしたステップと、
前記複数のエントリーポイントの１つから前記接続データセットにアクセスする要求をユーザ装置から受け取るステップと、
前記ユーザ装置の属性を自動的に決定するステップと、
前記ユーザ装置の属性を使用して所定のクライアント装置のデータベースから通信メソッドを選択するステップと、
前記通信メソッドに基づいてユーザ装置をプロビジョニングするステップと、
を備えた方法。
【請求項１４】
前記１つ以上のユーザ装置は、少なくとも１つ以上のセルラー電話、ワイヤレスパーソナルデジタルアシスタント、ナビゲーション装置、パーソナルコンピュータ、ゲームコンソール、インターネットターミナル、及びキオスクを含む、請求項１３に記載の方法。
【請求項１５】
前記接続データセットは、少なくとも１つ以上のｅメール、連絡先、カレンダー、タスク、ノート、ピクチャー、音楽、ドキュメント、ビデオ、ブックマーク、及びリンクを含む、請求項１３に記載の方法。
【請求項１６】
前記サーバーは、多数の地理的位置に分散された１つ以上のコンピュータ及びデータ記憶システムを含む、請求項１３に記載の方法。
【請求項１７】
前記属性は、
装置タイプ記述と、
サービス記述と、
トランスコーディングと、
アカウントテンプレートと、
を含む請求項１３に記載の方法。
【請求項１８】
ユーザ装置をプロビジョニングするための前記ステップは、
ＳＭＳベースのプロビジョニングを遂行する段階と、
装置ブラウザベースのプロビジョニングを遂行する段階と、
実行可能なプログラムベースのプロビジョニングを遂行する段階と、
ＡｃｔｉｖｅＸベースのプロビジョニングを遂行する段階と、
を含む請求項１３に記載の方法。
【請求項１９】
ＳＭＳベースのプロビジョニングを遂行する前記段階は、
証明書を要求しているユーザ装置へＵＲＬを送出し、この証明書は、ｅメールアドレス及びパスワードを含むものであり、
前記ユーザ装置から前記証明書を受け取り、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へプロビジョニングＳＭＳを送出する、
ことを含む請求項１８に記載の方法。
【請求項２０】
装置ブラウザベースのプロビジョニングを遂行する前記段階は、
証明書を要求しているユーザ装置へ新たな装置インジケータを送出し、この証明書は、電話番号を含むものであり、
前記ユーザ装置から前記証明書を受け取り、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へプロビジョニングＳＭＳを送出する、
ことを含む請求項１８に記載の方法。
【請求項２１】
実行可能なプログラムベースのプロビジョニングを遂行する前記段階は、
前記ユーザ装置がＳＤＫ装置であるかどうか決定し、
前記ユーザ装置を構成しそして証明書を要求するために前記ユーザ装置に実行可能なプログラムを送出し、前記証明書は、電話番号を含むものであり、
前記ユーザ装置から前記証明書を受け取り、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へ前記構成をダウンロードする、
ことを含む請求項１８に記載の方法。
【請求項２２】
構成をダウンロードすることは、
コンピュータプログラムをインストールし、
フィルタを適用し、
前記接続データセットに接続を適用する、
ことを含む請求項２１に記載の方法。
【請求項２３】
ＡｃｔｉｖｅＸベースのプロビジョニングを遂行する前記段階は、
ユーザ装置がＡｃｔｉｖｅＸイネーブルされたかどうか決定し、
ユーザ装置がＡｃｔｉｖｅＸイネーブルされた場合には、前記ユーザ装置にＡｃｔｉｖｅＸローダーをインストールし、
前記ユーザ装置において前記ＡｃｔｉｖｅＸローダーを実行する、
ことを含む請求項１８に記載の方法。
【請求項２４】
ユーザ装置をプロビジョニングする前記ステップは、更に、
前記ユーザ装置へサービスをアクチベートする段階と、
前記ユーザ装置からデータをインポートする段階と、
前記ユーザ装置を所定のアカウントに接続する段階と、
複写レコードを取り扱う段階と、
前記レコードを前記ユーザ装置へ送出する段階と、
を含む請求項１８に記載の方法。
【請求項２５】
通信ネットワーク内で１つ以上のユーザ装置を接続するための複数のエントリーポイントを与えるコンピュータプログラム製品であって、少なくともプロセッサユニット、ユーザインターフェイス及びメモリを有する１つ以上のコンピュータシステムにより実行するためのコンピュータプログラムを記憶するメディアを備えたコンピュータプログラム製品において、
サーバーと前記１つ以上のユーザ装置との間で通信するためのコードであって、前記サーバーが接続データセットを含み、且つ前記１つ以上のユーザ装置が前記接続データセットの部分を共有するようにしたコードと、
前記複数のエントリーポイントの１つから前記接続データセットにアクセスする要求をユーザ装置から受け取るためのコードと、
前記ユーザ装置の属性を自動的に決定するためのコードと、
前記ユーザ装置の属性を使用して所定のクライアント装置のデータベースから通信メソッドを選択するためのコードと、
前記通信メソッドに基づき前記ユーザ装置をプロビジョニングするためのコードと、
を備えたコンピュータプログラム製品。
【請求項２６】
前記１つ以上のユーザ装置は、少なくとも１つ以上のセルラー電話、ワイヤレスパーソナルデジタルアシスタント、ナビゲーション装置、パーソナルコンピュータ、ゲームコンソール、インターネットターミナル、及びキオスクを含む、請求項２５に記載のコンピュータプログラム製品。
【請求項２７】
前記接続データセットは、少なくとも１つ以上のｅメール、連絡先、カレンダー、タスク、ノート、ピクチャー、音楽、ドキュメント、ビデオ、ブックマーク、及びリンクを含む、請求項２５に記載のコンピュータプログラム製品。
【請求項２８】
前記サーバーは、多数の地理的位置に分散された１つ以上のコンピュータ及びデータ記憶システムを含む、請求項２５に記載のコンピュータプログラム製品。
【請求項２９】
前記属性は、
装置タイプ記述と、
サービス記述と、
トランスコーディングと、
アカウントテンプレートと、
を含む請求項２５に記載のコンピュータプログラム製品。
【請求項３０】
ユーザ装置をプロビジョニングするための前記コードは、
ＳＭＳベースのプロビジョニングを遂行するコードと、
装置ブラウザベースのプロビジョニングを遂行するコードと、
実行可能なプログラムベースのプロビジョニングを遂行するコードと、
ＡｃｔｉｖｅＸベースのプロビジョニングを遂行するコードと、
を含む請求項２５に記載のコンピュータプログラム製品。
【請求項３１】
ＳＭＳベースのプロビジョニングを遂行する前記コードは、
証明書を要求しているユーザ装置へＵＲＬを送出するコードであって、前記証明書がｅメールアドレス及びパスワードを含むようなコードと、
前記ユーザ装置から前記証明書を受け取るコードと、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へプロビジョニングＳＭＳを送出するコードと、
を含む請求項３０に記載のコンピュータプログラム製品。
【請求項３２】
装置ブラウザベースのプロビジョニングを遂行する前記コードは、
証明書を要求しているユーザ装置へ新たな装置インジケータを送出するコードであって、この証明書が電話番号を含むようなコードと、
前記ユーザ装置から前記証明書を受け取るコードと、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へプロビジョニングＳＭＳを送出するコードと、
を含む請求項３０に記載のコンピュータプログラム製品。
【請求項３３】
実行可能なプログラムベースのプロビジョニングを遂行する前記コードは、
前記ユーザ装置がＳＤＫ装置であるかどうか決定するコードと、
前記ユーザ装置を構成しそして証明書を要求するために前記ユーザ装置に実行可能なプログラムを送出するコードであって、前記証明書が電話番号を含むようなコードと、
前記ユーザ装置から前記証明書を受け取るコードと、
前記ユーザ装置からの前記証明書を検証するときに前記ユーザ装置へ前記構成をダウンロードするコードと、
を含む請求項３０に記載のコンピュータプログラム製品。
【請求項３４】
構成をダウンロードする前記コードは、
コンピュータプログラムをインストールするコードと、
フィルタを適用するコードと、
前記接続データセットに接続を適用するコードと、
を備えた請求項３３に記載のコンピュータプログラム製品。
【請求項３５】
ＡｃｔｉｖｅＸベースのプロビジョニングを遂行する前記コードは、
ユーザ装置がＡｃｔｉｖｅＸイネーブルされたかどうか決定するコードと、
ユーザ装置がＡｃｔｉｖｅＸイネーブルされた場合には、前記ユーザ装置にＡｃｔｉｖｅＸローダーをインストールするコードと、
前記ユーザ装置において前記ＡｃｔｉｖｅＸローダーを実行するコードと、
を備えた請求項３０に記載のコンピュータプログラム製品。
【請求項３６】
ユーザ装置をプロビジョニングする前記コードは、更に、
前記ユーザ装置へサービスをアクチベートするコードと、
前記ユーザ装置からデータをインポートするコードと、
前記ユーザ装置を所定のアカウントに接続するコードと、
複写レコードを取り扱うコードと、
前記レコードを前記ユーザ装置へ送出するコードと、
を含む請求項３０に記載のコンピュータプログラム製品。
【図１ａ】
【図１ｂ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図１ｂ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【公開番号】特開２０１３−６１９５３（Ｐ２０１３−６１９５３Ａ）
【公開日】平成２５年４月４日（２０１３．４．４）
【国際特許分類】
【出願番号】特願２０１２−２３５９５５（Ｐ２０１２−２３５９５５）
【出願日】平成２４年１０月２５日（２０１２．１０．２５）
【分割の表示】特願２００８−５２１４３９（Ｐ２００８−５２１４３９）の分割
【原出願日】平成１８年７月６日（２００６．７．６）
【出願人】（５０１４３８４８５）ヤフー！ インコーポレイテッド (200)
【Ｆターム（参考）】
【公開日】平成２５年４月４日（２０１３．４．４）
【国際特許分類】
【出願日】平成２４年１０月２５日（２０１２．１０．２５）
【分割の表示】特願２００８−５２１４３９（Ｐ２００８−５２１４３９）の分割
【原出願日】平成１８年７月６日（２００６．７．６）
【出願人】（５０１４３８４８５）ヤフー！ インコーポレイテッド (200)
【Ｆターム（参考）】
[ Back to top ]