JP2008518364A - 携帯端末におけるデータの管理方法及び装置 - Google Patents

Abstract

バックアップ及び復元サービスのための方法及び装置が提供される。バックアップ及び復元の機能性は、紛失した携帯端末から人事データを削除する能力と同様に、フリーとベースのプロビジョニング(fleet-based provisioning)を使用する能力を提供する。復元はこのシステムを使うことが可能なことから、携帯端末が復元され、又は新たな携帯端末に置き換わるならば、そのアドレスブックは容易に復元/転送されることが可能である。

Description

本発明はデータバックアップに関係し、より詳しくは、バックアップサーバーを用いてバックアップし、機能性を回復できるようにすることに関するものである。
（関連出願）
本願は、２００４年１０月２７日に出願された仮出願No.60/623,076を優先権主張する。

データバックアップサービスとして、同期サービスがしばしば用いられる。しかし、それらは、多目的であるとともに厳密な行動を伴わず、むしろ最も信頼できる経験則に依存することから、データ完全性において同期サービスを信頼することができない。

同期システムは、データ関係をみる上で２以上の同等な装置に一致する。そのような関係において、どんなマスターデータ権限もないし、どの装置もデータセットへの変更に寄与する。同期はタイプの異なるデータレコードを処理しなければならないので、経験則を用いて一致レコードの識別や異なるレコードの分離をする必要がある。同期は、レコードの変換を行うのだが、これは、同期ネットワークにある任意の２つのノードのレコード構造及びフォーマットが異なっているかもしれないからである。

バックアップ及び復元（ＢＡＲ）サービスは、無線モバイルネットワークを使って、セキュアなサーバー上にモバイル電話のアドレスブック情報のバックアップを周期的、自動的に提供する。一実施例において、ＢＡＲは、損傷又はアクシデントな損失の場合、アドレスブック情報を本来の携帯端末に復元するために用いられる。ＢＡＲは、アドレスブック情報を新たにアップグレードしたり、置き換えられた携帯端末に転送するために用いられる。また、ＢＡＲはアドレスブック情報をフリート展開モバイル携帯端末にプリインストールしたり、フリート携帯端末のアドレスブック情報を既知の状態にリセットしたり、又は盗難にあったり紛失した携帯端末の情報を消し去るために用いられる。

一実施例において、個人携帯バックアップサービスとしてＢＡＲサービスを展開することもできる。フリートデータ展開サービスとして、ＢＡＲサービスを展開することができる例もある。各コンフィギュレーションの特徴は以下に纏められる。

個人携帯バックアップサービス
個人携帯バックアップサービスの構成は、個々の加入者のためにデータバックアップ及び保護メカニズムとして設計される。ＢＡＲ(バックアップ及び復元)システムは、バックアップ及び復元システムとともに、アドレスブック・マイグレーション(address book migration)を提供する。一実施例において、個人携帯バックアップサービスは、個々の加入者アカウント内にアドレスブック情報のオンライン読み出し専用ビュー(view)を提供する。

一実施例において、ＢＡＲの個人携帯バックアップサービスは、選択的なプロビジョニング(provisioning)を用いて、個々の加入者ベースでアクティベーション（起動）できるようにする。電話購入時に、又は後日その加入者による選択で、本サービスを利用することができる。組み込みクライアントが携帯端末に既に存在するので、単純なOver the air provisioning code（ＩＯＴＡ）が、サービスを起動又は停止するために要求されるすべてとなる。

ＢＡＲサービス１３０は、携帯端末１２０及び通信事業者１１０の基礎を構成するマルチメディアメッセージンングシステム（ＭＭＳ）のインフラに依存する。一実施例では、バックアップサーバーに配信されるデータバックアップメッセージのためにＭＭＳメッセージングが使用される。その結果、ある実施例では、ユーザの携帯端末はＢＡＲが機能する順にＭＭＳメッセージングをサポートしなければならない。別の実施例では、シンプル・メッセージングシステム（ＳＭＳ）を本サービスのために使用してもよい。また、データ・オーバーＩＰ(data over IP)を用いることができる実施例もある。

ＢＡＲサービスは、ひとたび起動されると、自動的にデータをバックアップする。携帯端末内の組み込み型アドレスブックアプリケーションによってコミット(commit)が発行されるときはいつでも(例えば、コンタクト(contact)エントリの変更をした後)、ＢＡＲクライアントはＭＭＳメッセージとしてサーバーに送信するためのバックアップレコードを構築する。一実施例では、バックアップレコードは直ちに送信される。別の実施例の場合、バックアップレコードは、１日１回など周期的にサーバーへ送られる。また別の実施例の場合、システムは、ネットワーク利用が低いときは、新たなバックアップレコードを待ち行列に入れてサーバーに送る。バックアップは自動的であり、且つどんなユーザ介入も必要でない。

クライアントデータ１４０は安全に記憶される。一実施例では、クライアントデータ１４０がデータベースに記憶される。別の実施例では、クライアントデータは、単層ファイル(flat file)、即ち代替フォーマットに記憶される。ＢＡＲシステムが、フリート(fleet)サーバー１５０と相互作用し、フリート・プロビジョニング、バックアップを提供し、且つ初期状態に復元することもできる例も挙げられる。

図２は、ＢＡＲサーバーの一実施例のブロック図である。一実施例において、ＢＡＲの個人版は、ユーザインタフェース２３５を介してＢＡＲのＷｅｂサイトにアドレスブックのバックアップコピーに関する読み出し専用データビューを提供するだろう。ある実施例を挙げれば、Ｗｅｂサイトは白色にラベル化され、別のＷｅｂサイト（例えば携帯電話会社又は企業イントラネット）内に再ブランド化され、アクセスされることができる。ＢＡＲＷｅｂサイトを使用して、加入者は彼/彼女のアドレスブック２２５の最新バックアップバージョンを閲覧することができる。またある実施例の場合、システムは、バックアップに何らかの問題があれば、アドレスブックの“最後に知った良好な状態”を維持する。また、システムは更にサービス開始以降のトランザクションヒストリー（経緯）を維持する。ある実施例において、ヒストリーを含むこのクライントデータ２２５は、ユーザがバックアップシステムを以前の状態にセットできるようにする。

加入者は、ＢＡＲのＷｅｂサイトから“復元”オプションを選択することにより、彼/彼女の携帯端末への復元を開始することができる。“復元”オプションを選択するにあたり、形態端末の所有者の証明を要求する。認証/安全ロジック２５０はこのルールを強制する。一実施例において、所有者の証明は、（後述するように）復元プロセスの一部としてＳＭＳメッセージ経由で処理される。

携帯端末のアップグレード又は取替えのために、加入者はＢＡＲのＷｅｂサイトを使って、新たな携帯端末にバックアップ後のアドレスブック情報を手作業で移す。復元/転送ロジック２３０は、本プロセスを支援する。一実施例において、転送の手順は、取替え携帯端末の電話番号が元々の電話番号と違うならば、加入者が取替え携帯端末の電話番号を入力することを除いて復元の手順と同じである。

選択的に、加入者は、ユーザインタフェース２３５を用いてアドレスブックへ追加レコードを手作業で加えるために、ＢＡＲのＷｅｂサイトを使用することができる。これは、新たなコンタクト(contact)の入力をする上で、携帯端末のキーパッドよりもパーソナルコンピュータを使いたいと願う加入者にとって便宜を図るために提供されたオプション的な特徴である。ある実施例の場合、新たなコンタクトは、Ｗｅｂサイトビューに示されるアドレスブックへ、及びＭＭＳメッセージを介した携帯端末へ追加されるだろう。

携帯端末を失った場合のために、加入者又はサポート事務員は、リセットロジック２４０を介して携帯端末に対してマニュアル・データリセットを発行することができる実施例もある。マニュアル・リセットは、その失った携帯端末への連絡を確立できるということを前提として、携帯端末のアドレスブックにあるデータ、呼び出しヒストリーリスト、及び呼び出し失敗リストを消し去るだろう。手動のリセットは、ＢＡＲサーバーにある情報のバックアップコピーに影響しないだろう。ある実施例では、復元オペレーションを使っていつでも消去されたアドレスブックを元に戻すことができる。復元/削除メッセージ及び他のメッセージは、マルチメディアメッセージング経由で携帯端末に送信される。マルチメディア・メッセージ・クリエータ２４５は、ユーザが入力した情報に基づきメッセージを生成する。次に、これはＭＭＳトランシーバー２１０に送信される。ＭＭ７フォーマットのメッセージがＭＭＳＣに送信され、次にＭＭＳＣはそれをユーザの形態端末に送信する実施例がある。別の実施例では、ＭＭ１フォーマットのメッセージが携帯端末へ直接送信される。

一実施例において、ＢＡＲはユーザインタフェース２３５を介して顧客サポートインタフェースを提供するだろう。このユーザインタフェースは、通信事業者の顧客サポート職員が、加入者の携帯端末へ復元，転送，又はリセット命令を発行できるようにする。顧客サポートインタフェースは、コンタクト数及びバックアップデータのリストなど、特定の加入者のアカウントに関する非個人的な情報のみを提供してもよい。顧客サポートインタフェースは、加入者アドレスブックの内容を表示しない。一実施例では、顧客サポートツールは、詳細な加入者のアカウント情報に加えて統計データも提供するだろう。統計データは、活動中の加入者数、平均アドレスブックサイズ、及びバックアップ頻度を含み得る。

フリートデータ展開サービス(Fleet Data Deployment Service)
ＢＡＲのフリートサーバーのブロック図を図３に示す。ＢＡＲフリートデータ展開サービスの構成は、レンタカープログラム等のフリートサービス向けに設計され、携帯端末阿アドレスブック情報をリセットし、且つレンタル携帯端末に情報を一時的に記憶する便利な方法を顧客に許可するメカニズムを提供する。フリートサービスは、従業員に携帯端末を提供する企業組織も含み得る。中央制御された携帯端末をユーザ/メンバーに提供したいと願うどんな組織も、ＢＡＲのフリートデータ展開サービスを利用することができる。簡単にするため、使用可能な携帯端末を述べるために“レンタルモード”という語を用いる。もちろん、当業者であれば、これが“レンタル”を要求するのではなく、そのように用いられる使用中の携帯端末に言及していることが理解できるであろう。

ＢＡＲによるプロビジョニング(provisioning)は、個々の加入者というよりフリート/グループによる。各アカウントは、携帯端末がレンタルモードであり、且ついったん携帯端末が返却されるとリセットされる期間は有効である。有効(activation)ロジック３１５は、携帯端末がフリート/レンタルモードに置かれ且つ返却された後で携帯端末を有効にするとき、携帯端末を有効状態にする。個々の加入者アカウント及び関連するユーザデータ３３０は、携帯端末の配布の前と携帯端末の廃棄の後には、携帯端末から切り離される。一実施例において、個々の加入者アカウントは、廃棄後も存続することができる。これは、例えば様々な場所にオフィスをもち、フリート携帯端末を付与する企業にとっては有益である。旅行ユーザは、ユーザ自身のアドレスブックと同様、ベースラインデータ３２５を設計し、既にプリインストールされたローカル企業アドレスブックとを備えたローカル携帯端末を受け取ることができる。一実施例において、復元/転送ロジック３２０は、デバイスに加えられる内容を特定するのに用いられる。

一実施例の場合、ＢＡＲはフリートデータリセット機関をサポートする。携帯端末が返却され且つフリート事務員が関連アカウントをリセットすると、フリートデータリセットは自動的に起動する。一実施例において、リセットロジック３５０は、携帯端末内の記憶されたすべてのアドレス情報を除去し、フリートエージェンシーによって制御されたデフォルトのアドレスブックでそのアドレス情報を置き換える。例えば、デフォルトのアドレスブックは、緊急ナンバーや顧客サービスナンバーを含み得る。返却された携帯端末とリンクする顧客アカウントもまた破壊される。しかしながら、顧客アカウントは、有効のままで、携帯端末が返却され且つリセットされた後、存続し続けることができる。顧客アカウントデータは、ユーザデータ３３０として記憶される。

一実施例において、個々の加入者は、ＢＡＲのＷｅｂサイト上でユーザインタフェース３１０を使用して、コンタクト情報をレンタル電話に転送することができる。ひとたび携帯端末が動作すると、個々のユーザアカウント情報が携帯端末にリンクし、データが転送されるだろう。携帯端末が復元し且つリセットされるときは、アカウント情報が携帯端末からリンクされなくなるだろう。つまり、例えば、人が、ＢＡＲサーバー上の個人アドレスブックをレンタル携帯端末の電話番号にリンクすることによって以前インストールしたデフォルトのアドレスブックに彼らの個人アドレスブックを追加することができる。マルチメディア・メッセージ・クリエータ３３５はユーザインタフェース３１０を通して入力された情報、又はＭＭＳメッセージを介して受信された情報に基づいてメッセージを生成する。次に、これは携帯端末用のためにＭＭＳ受信機３１０へ送信される。

一実施例において、ＢＡＲサービスは、データバックアップ用に明確に定義されたメカニズムを使用する。このメカニズムは唯一の目的をもち、ロジックまたはデータ記憶に関して曖昧さを認めない。このサービスはデータ完全性に左右されるので、厳格なまでの定義に従うのである。同期と異なり、ＢＡＲの個人データ展開サービスは、非常に詳細なマスター・スレーブ関係を持ち、携帯端末のクライアントがマスターとして、そしてバックアップサーバーがスレーブとして機能する。ＢＡＲフリートデータ展開サービスは、反対のマスター・スレーブ関係を持ち、携帯端末のクライアントがスレーブとして、そしてフリートサーバーがマスターとして機能する。

ＢＡＲはデータ同期サービスではない。ＢＡＲはレコードのマッチング（一致）を行わない。その代わりに、ＢＡＲは携帯端末の個々のレコードにある各スロットを考慮し、すべての修正ヒストリーをＢＡＲサーバー上のそのレコードスロットに保管(アーカイブ：archive)する。ＢＡＲは、携帯端末内にデータが表れるとき当該データのみを記録する。

複数の装置（ピア）からの修正が同一レコードに対して検出されるときはいつでも、同期は競合解消(conflict resolution)を実行しなければならない。これはしばしばユーザ介入を要求する。他方で、ＢＡＲは、携帯端末のクライアントをサーバーとの関係で明確に定義するので、解決するための競合は存在しない。

同期は、レコードへの変化とレコードの意図した重複との間にある違いを認識し損なうことがあり得る。このしばしば遭遇する瀬戸際のケースは、重複衝突(duplicate collision)として知られており、コンフリクト、又は殆どの場合、マニュアル的なユーザ介入を解決するために重複管理オートマトンを使用することを要求する。ＢＡＲは重複衝突に悩まされない。なぜならすべてのトランザクションがスロットベースであり、且つ意図した重複が文字どおりとられているからである。

ＢＡＲはデータバックアップサービスである。後日、新たな携帯端末への転送又は再記憶のために使用され得るモバイル携帯端末アドレスブックの文字どおりの提供が意図される。携帯端末で修正される各レコードのために、サーバー上で対応するエントリを生成する。一実施例の場合、レコードへの各修正は、サーバーによって特定のレコードと関連した時間的ヒストリーの一部として保持される。一実施例の場合、“更新”のそれぞれは、時間軸で新たなエントリを生成する。一実施例の場合、更新は日付と時間でグループ化される。よって、例えば特定の日付で行われたすべての更新が一つの“更新”へとまとめることができる。このメカニズムを使って、履歴に基づく時間軸に沿った任意の特定の状態にアドレスブックを復元することができる。

これまで纏めてきたように、ＢＡＲは各モバイル携帯端末のレコードを文字どおりに保管する。そして、ＢＡＲは、それを変えたり、或いは複数の装置（ピア）又は標準フォーマットにレコードを変換しない。ＢＡＲはレコード・マッチング（一致）を実行しようとせず、むしろモバイル携帯端末内のその位置（スロット）によって各レコードを追跡する。ＢＡＲは、履歴トランザクションとして各々の修正（追加、編集、削除）を考慮し、且つ、コンフリクトにおける“成功”トランザクションを解決しようとしない。実際、各トランザクションが履歴の時間軸に沿った設定位置でおきるのでどんなコンフリクトもない。ＢＡＲは重複を識別し且つ統合しようとはしない。全てのレコードトランザクションが文字どおりなされる。

ＢＡＲは、ユーザ携帯端末上のクライアントソフトウェア要素と、遠隔サーバー上の記憶サービスという２つの構成要素からなる。一実施例において、セキュアなバックアップと記憶サーバーをサービスプロバイダーによるフェイルセーフ方式で動作する。そのサーバーはメッセージサービスを介してユーザ携帯端末にアクセス可能である。一実施例において、携帯端末にクライアントがプリインストールされる。これは、ダウンロード可能などんなクライアントソフトウェアも要求されないことを意味する。ＢＡＲはいかなるＰＣソフトウェア、ケーブル、又は他の付加的なハードウェア若しくはソフトウェア要素もその機能に要求しない。一実施例において、ＢＡＲは、無線通信事業者にあるマルチメディアメッセージサービス（ＭＭＳ）のインフラを使って、シームレス且つ自動的に動作する。あるいはまた、ショートメッセージシステム（ＳＭＳ）のインフラを用いてもよい。或いはまた、コネクションに基づくセッション開始プロトコル（ＳＩＰ）を用いてもよい。

一実施例において、携帯端末の製造者に対してＢＡＲの携帯端末クライアントを提供し、その携帯端末に直接組み入れる。別の実施例では、ＢＡＲの携帯端末クライアントは、インストール可能な携帯端末アプリケーションとして提供される。

一実施例の場合、通信事業者とのコンタクトの下、単一のサービスプロバイダーがＢＡＲサーバーを保持し且つ操作する。別の実施例では、各通信事業は自分自身のＢＡＲサーバーを保持する。サーバーは通信事業者のマルチメディアメッセージング・サービスセンター（ＭＭＳＣ）のＭＭ７インタフェースを介して無線通信事業者ネットワークへ結合される。

一実施例において、サービスプロバイダー及び通信事業者は、固定の通信先識別子（例えば、短コードアドレス）を使用して、サービスプロバイダーに転送されるはずのバックアップメッセージを特定する。次に、この短コードアドレスはＢＡＲサーバーをアドレスするために携帯端末クライアントへプログラムされる。一実施例において、通信事業者はクライアントのデータを更新し、この短コードアドレスを変更することができる。サーバーは、ＭＭ７経由で、個々の携帯端末所有者によってのみアクセス可能なセキュアな短距離の範囲内にＭＭＳで発行されたすべてのトランザクションを保管するだろう。

図４はクライアントアプリケーションの一実施例を示すブロック図である。一実施例において、クライアントアプリケーションは機能的であり、モバイル携帯端末の組み込みファームウェアの構成要素としてプリインストールされる。一実施例において、クライアントは永続的に作動（active)にされる。クライアントを利用可能又は利用不可能にする能力はない。携帯端末内のアドレスブック情報に対する任意の変更は、クライアントに対して、パッケージ化すること、及びＢＡＲサーバー用のプリプログラム化されたＭＭＳアドレスにＭＭＳメッセージを送信することを指示する。別の実施例において、クライアントはソフト起動される。無線(Over-The-Air)提供コマンドは、クライアント用の利用可能フラグをセット又はリセットするだろう。一実施例において、ＯＴＡコマンドはＳＭＳ経由で電話へ送信される。利用可能であれば、アドレスブック情報に対する任意の変更は、クライアントに対して、パッケージ化すること、及びサーバー用のプリプログラム化されたＭＭＳアドレスにＭＭＳメッセージを送信することを指示する。システムが利用可能でないとき、そのようなメッセージは送信されない。

一実施例において、初期起動がされると、ＢＡＲクライアントは携帯端末アドレスブックのコンテンツをパッケージするとともにＢＡＲサーバーに送信する。この最初のステップはサーバーコピーを開始するためのものである。開始後、携帯端末の常駐アドレスブック内での次のデータコミットで、ＢＡＲクライアントは、コンタクトレコードの変更を包含するＭＭＳメッセージをパッケージ化し且つ送信するだろう。コミットは追加、変更、削除を含む。一実施例において、データコミットは、ユーザが編集機能(editing feature)から抜け出るときに起こる。これにより、一実施例の場合、コミットが起きる前に、１以上のアイテムが編集セッションで変更されうる。

一実施例の場合、サーバーから最後に分かった優良なアドレスブックを復元し又はアップロードすることはＢＡＲＷｅｂサイトから引き起こされる。別の実施例では、ＢＡＲクライアントを使って携帯端末上で引き起こされる。復元が引き起こされる場合、ＢＡＲサーバーはメッセージをデータとともにユーザの携帯端末に送信する。一実施例では、メッセージはＭＭＳメッセージである。ＢＡＲクライアントは、携帯端末のアドレスブック内のエントリをＭＭＳメッセージ内の対応のエントリと置き換えることによってＢＡＲサーバーからのメッセージに答えるだろう。

一実施例において、クライアントは以下のようなサーバーＭＭＳメッセージに答えるだろう。
（１）完全アドレスブック：完全アドレスブックは携帯端末アドレスブックのコンテンツ全体を新たなファイルに置き換えるだろう。完全アドレスブックは空白（ブランク）であるかもしれない。ＢＡＲサーバーからのメッセージは、そのメッセージが完全アドレスブックであるか又はアドレスブックのサブセットであるかどうかを指し示す。
（２）単一アドレスエントリ：単一アドレスエントリは、携帯端末のアドレスブック内の特定のアドレスブックエントリのみえお置き換えるだろう。エントリは空白（ブランク）であるかもしれない。
（３）エントリのサブセット：そのメッセージは携帯端末内で置き換わるエントリのサブセットを含み得る。

一実施例において、ＢＡＲサーバーは空のアドレスブックを送信し、携帯端末のアドレスブックを消し去る。別の実施例では、その後に、空のアドレスブックの受領は装置を操作不能状態にロックするだろう。別の実施例では、装置をロックダウンするためにばらばらのメッセージを送信する。ロックダウンは、装置が盗まれたり紛失したりしたとき有益である。

一実施例では、ＢＡＲサーバーは携帯端末を消し去るために単一メッセージを送信する。この単一メッセージは、特定のキーワード信号コンテンツと一緒にアドレスブックにある。一実施例では、信号メッセージはロックされた装置上で表示される“持ち主へ戻って下さい”などの表示コンテンツを含んでいる。

一実施例において、単一或いは完全ファイル内に包含された何れかのアドレスブックエントリすべては、エントリがそこに適合する対応の携帯端末ブックスロットを示すラベルされたフィールドを含む。アドレスブックエントリは、ｖＣａｒｄフォーマットで送信される。代替フォーマットを使用することもできる。一実施例において、ＢＡＲはどのフォーマットをユーザ携帯端末がサポートするかを決め、そしてその正しいフォーマットでデータが送信される。

一実施例において、ＢＡＲクライアント用の携帯端末ユーザインタフェースはない。操作はユーザにとってトランスペアレント(transparent)である。エラー状況のユーザ通知を除き、これは顔のみえないクライアントである。ユーザ行動を要求するエラー状況は、携帯端末のメッセージボックスとしてあらわれる。別の実施例では、エラー状況を示すために、サーバーから携帯端末へショートＳＭＳフォーマット・メッセージが送信される。エラー状況は以下のものを含む。
（１）非ＭＭＳサービス
（２）ＭＭＳ アウトボックスの満杯
（３）存在しないスロット番号に対応するアドレスエントリ
（４）アドレスブックの満杯
（５）サーバーからの未承認ＭＭＳメッセージ
これらのエラーメッセージの場合、ユーザは問題に気付かされる。一実施例では、ユーザは好ましい解決を示すことができる。

一実施例において、ＢＡＲサーバーとＢＡＲクライアント間で送信されるＭＭＳメッセージのデータフォーマットはｖＣａｒｄである。ＢＡＲクライアントがｖＣａｒｄメッセージのコンテンツを処理し且つ行動するため、サーバーはそのメッセージを電子指紋で署名しなければならず、各アドレスブックエントリはスロット番号に対応する有効を包含する。一実施例において、非署名ｖＣａｒｄメッセージは、セキュアでないアドレス通知として扱われ、結果としてエラー通知をもたらす。一実施例では、ユーザはそのようなセキュアでないアドレス通知をインストールすることを選ぶことができる。

一実施例において、ＢＡＲサーバーは、ＭＭＳサービスと接続されたＭＭ７として利用可能である。別の実施例では、ＢＡＲサーバーは将来サービスとして通信事業者のＷｅｂサイトへ統合される。ＢＡＲサーバーＷｅｂインタフェースは別々のサーバーを通して提供される。

加入者認証及びアクセス検査は通信事業者Ｗｅｂサイトによって処理される。この通信事業者は、特定のユーザ名（モバイル番号）及びパスワードに対応する固有のＢＡＲ加入識別子を保持する責任がある。
一実施例において、ＢＡＲサーバーは自動化された提供メカニズムを使用する。ＢＡＲサーバーは、存在しないアカウント用の新たな固有加入者ＩＤを自動的に生成し、バックアップメッセージを最初に受信する。

一実施例において、ＢＡＲサーバーは通信事業者のＷｅｂサイトのサブコンポーネントとして実行される。ＢＡＲサービスに対するナビゲーションは、通信事業者にあるＷｅｂサイトタブ又はナビゲーション構造を経由するだろう。一実施例では、２００２年４月１７日に提出された“System Providing Methods For Dynamic Customization And Personalization Of User Interface”という表題の米国特許出願Ｎｏ．10/125,049に記載された技術が用いられ、通信事業者自身のＷｅｂサイトのインタフェースに合致するカスタマイズされたインタフェースを生成する。ＢＡＲは、カラー調整及びスタイルを提供するインタフェースを与え、通信事業者にあるフォーマット及びスタイルに合致させる。これにより、サードパーティのサービスプロバイダーが実際のサービスを提供することになるかもしれないが、ユーザに対するサービスが通信事業者から提供されるようにみえる。

一実施例では、ＢＡＲＷｅｂサイトインタフェースは、アドレスブックの履歴バックアップを表示することができることを含む。ユーザはアドレスブックのどんな履歴バージョンも携帯端末に復元することができる。Ｗｅｂインタフェースは、アドレスブックの表示、データセレクター、復元をアクティブにするためのボタンを含む。図８Ａは、現在表示のデータ（８１５）を含むアドレスブック（８１０）の一実施例を示したものである。ユーザはデータ８１５を選択し、過去の状態を表示することができる。一実施例において、ユーザは復元ボタン（８２０）を使って携帯端末を過去のある状態に“復元”できる。

一実施例では、ＢＡＲＷｅｂインタフェースは、アドレスブック内にログ(log)した変更イベントに対応するエントリをもつデータセレクター８１５を含むだろう。データセレクターは、最初は、最新データによる新しい順にあるだろう。特定の日を選択することは、アドレスブックの履歴時間軸に沿った特定の日に対応する状態に、そのアドレスブックを再表示する。

アドレスブック・ビュー(view)８１０は、データセレクター８１５において選択された日に対応するアドレスブックのアドレスブックエントリすべてを含むだろう。一実施例において、エントリ数が表示可能な領域を超える場合は、ビューはスクロール可能である（８２５）。ビューは、携帯端末に復元され得る各アドレスブックエントリ内の情報のみを含む。一実施例では、アドレスブック・ビューは読み出し専用である。別の実施例では、ユーザは、Ｗｅｂページ上のアドレスブックのバージョンを編集する（８３０）。一実施例において、システムは別の更新としてこれを記憶する、即ち、変更に先立って、履歴状態を維持する。

Ｗｅｂインタフェースは、目下、目に見えるアドレスブックの状態を加入者の携帯端末に復元し且つ転送するためのリンクを記憶すること８２０、及び転送すること８３５を含む。一実施例において、ユーザの現在の携帯端末又は新たな携帯端末にデータを転送することができる。記憶すること及び転送することは、転送オプションを使って特定のモバイル番号を明確化することができる違いをもつオペレーションと殆ど同じである。

一実施例では、ユーザは、目下、表示されているアドレスブックのバージョンから１又はそれ以上のアドレスを選択し、そして選択されたアドレスのサブセットを携帯端末に転送することができる。

記憶すること及び転送することの機能は単一の“復元”機能にまとめられ、それは復元に先立って携帯端末番号の認証を常に尋ねる。

Ｗｅｂサイトは“追加”リンク８４０を含み、加入者が新たなアドレスブックエントリを構成したり、それをアドレスブックの最新バージョンに付け足すことができるようにする。新たなエントリ・フォームは、携帯端末のフィールド・フォームと合致し、携帯端末に保存できない値を含まない。申し出があると、新たなエントリ・フォームは、コンタクト情報をアドレスブックに付け足し、そのエントリを履歴修正としてアドレスブックに記録するだろう。要求がなされると、新たな履歴ラベルが、新たなエントリの追加に対応した時間軸に追加されるだろう。

一実施例において、特定のアドレスブック・ヒストリーにある履歴ラベルの精度は、一日である。アドレスブックに同日になされた修正すべては、その日に関する１つの統一されたイベントへと正規化される。この正規化プロセスはサーバー駆動であり、特定の日に関するすべての修正が包含された結合ＭＭＳメッセージを発行する携帯端末に依存しない。加入者を混乱させることを避けるため、時間の正規化はＧＭＴではなく携帯端末のローカルタイムで表示される。別の実施例では、携帯端末は一日に一回、ＢＡＲサーバーへデータを転送することだけを行い、その結果、転送時まで変更を蓄積しておくだろう。

復元及び転送は、一つの違いを除き同一の機能である。つまり、“転送”は加入者が特定のモバイル番号を明確化できるようにするのに対して、“復元”はオリジナルの（補完されている）モバイル番号がターゲットであることを仮定している。データセレクターによって示されるように、転送又は復元を選択することは、アドレスブック・ビューに目下目に見えるアドレスブック状態の復元を実行するだろう。一実施例では、携帯端末の所有者はＷｅｂページ上でユーザデータにアクセスするのみなので、どんな検証も要求されない。別の実施例では、復元又は転送は携帯端末の所有者の検証を別個に要求する。これは以下のように実行される。

（１）ＢＡＲサーバーは６桁より大きくなく且つ４桁よりも小さくない、ダイナミックな数値ＰＩＮコードを生成する。
（２）ＢＡＲサーバーは携帯端末へＰＩＮコードをＳＭＳメッセージとして送信する。
（３）ＢＡＲサーバーは、Ｗｅｂサイトを使って、加入者が復元又は転送を開始するのに先立って携帯端末に送られるＰＩＮコードを入力することを要求する。
（４）有効なＰＩＮコードの認証によって、ＢＡＲサーバーは、アドレスブック又はアドレスブックの選択された部分をパッケージ化し、そしてそれをＭＭＳメッセージとして携帯端末へ送信する。
（５）携帯端末に送られるＭＭＳメッセージは、ＢＡＲサーバーによって生成されたディジタル署名を含む。

一実施例において、ＢＡＲサーバーから送信されたすべてのファイルは、加入者に一致するディジタル署名と、携帯端末によって認証され得る携帯端末の特定情報と一緒に署名される。組み込み型ＢＡＲクライントは、署名されていない復元／転送メッセージの手作業による承認を拒絶したり要求したりする。

一実施例において、ＢＡＲＷｅｂサイトの“追加”リンクは、名前の値の組に対応したエントリを含むＷｅｂフォームの表示のトリガーとなり、上記名前の値の組は一つのコンタクト・エントリ用のコンタクト形式に合致しているだろう。フォームの提出により、加入者により入力された新たなコンタクト・データが、特定のスロットに対する履歴修正としてアドレスブックの空のスロットに付け足されるだろう。ユーザは任意のエントリを同様に編集することができる。

ＢＡＲサービスは、アドレスブック更新メッセージを配信するために携帯端末内の組み込み型マルチメディアメッセージサービス（ＭＭＳ）サブシステムを使用し、バックアップメッセージを送出する。一実施例において、ＭＭＳサブシステムは携帯端末内の機能するＭＭ１スタック、ＭＭＳのｖＣａｒｄを受信するとＢＡＲクライアントをアクティブにするメッセージルーター、機能するマルチメディアメッセージサービスセンター（ＭＭＳＣ）、ＢＡＲサービスのためのＭＭＳ宛先アドレス（短コード）、及び加入者用のアクティブＭＭＳアカウントを含む。

一実施例において、マルチメディアメッセージサービスセンター（ＭＭＳＣ）、及びＭＭ１スタックに常駐するクライアントは、有効なＭＭＳメッセージペイロードとしてｖＣａｒｄデータフォーマットをともにサポートしなければならない。ＭＭ１スタックもＭＭＳＣのいずれも、ｖＣａｒｄデータの内容を変更しない。

ＢＡＲのソフト起動のためのオプションが選択されるとき、通信事業者ネットワーク及び携帯端末は、Over the air provisioning 方法を用いる。この方法は、ＢＡＲサービスの利用可能な設定の状態を確実に変更する。

一実施例において、ＢＡＲサーバーは、マルチメディアメッセージサービスセンター（ＭＭＳＣ）及び対応のＭＭＳ宛先アドレス（短コード）に対する標準ＭＭ７コネクションを使用する。ＭＭ７インタフェースは、ＢＡＲサーバーとＭＭＳＣが一緒に用いられることを要求しない。しかしながら、一実施例では、２つのシステム間のセキュアなリンクが使用される。別の実施例では、他のＭＭＳＣであるかのようなサーバーを持つことによって、ＭＭ１リンク上にコネクションがある。

ＢＡＲクライアントは携帯端末のファームウェア内のコンポーネントに対する機能的な接続性を要求する。一実施例では、接続性は、一組の定義されたアプリケーションプログラムインタフェース（ＡＰＩ）である。これらのインタフェースの典型的な組を以下にまとめた。

ＢＡＲクライアントは、アドレスブックエントリを追加し、除去し、且つ修正する目的のために携帯端末のアドレスブッククライアントに対する直接の接続性を有する。システムが用いる典型的ないくつかのコマンドは、以下のものである。
（１）ResetAddressBook():
このＡＰＩコマンドはＢＡＲクライアントによって組み込み型アドレスブックに対して発行される。アドレスブックは、記憶された携帯端末のアドレスブックの内容を消去することによって応答する。
（２）SetAddressEntry():
このＡＰＩコマンドはＢＡＲクライアントによって組み込み型アドレスブックに対して発行される。アドレスブックは、特定のアドレスブックエントリ（スロット）の内容を、所与のメモリ構造の内容に置き換えることによって応答する。
（３）GetAddressEntry():
このＡＰＩコマンドはＢＡＲクライアントによって組み込み型アドレスブックに対して発行される。アドレスブックは、アドレスブックエントリ（スロット）の内容を備えた所与のメモリ構造の内容をファイリングすることによって応答する。
（４）ResetCallList():
このＡＰＩコマンドはＢＡＲクライアントによって組み込み型携帯端末コールリスト・マネージャーに対して発行される。コールリスト・マネージャーは、最近のコールリスト及びミスしたコールリストの内容を消去することによって応答する。
（５）NotifyCommit():
このＡＰＩコマンドは携帯端末アドレスブッククライアントによって組み込み型ＢＡＲクライアントに対して発行され、変更が携帯端末のアドレスブック内の特定スロットに生じたかを示す。多数のコミット通知が携帯端末アドレスブッククライアントによって発行され、そして１以上の正式のＭＭＳメッセージが形成されるまでこれらの通知を追跡することがＢＡＲクライントに委ねられる。

（６）SendMessage():
このＡＰＩコマンドはＢＡＲクライアントによって携帯端末内の組み込み型ＭＭＳメッセージングサブシステムに対して発行される。このコマンドはバックアップメッセージをクライアントのアウトボックス(outbox)に置く。一実施例において、メッセージは、添付のｖＣａｒｄと共に完全にフォーム化されたＭＭＳメッセージである。ＭＭＳメッセージは適切なメッセージヘッダー、及びＢＡＲサーバー終点用の有効な宛先アドレスを含む。
注：ＭＭＳメッセージがメッセージアウトボックスに置かれると、ネットワークを使ってＭＭＳメッセージを配信することは携帯端末内のＭＭＳサブシステムの責任である。
（７）ParseMessage():
このＡＰＩコマンドは携帯端末内の組み込み型ＭＭＳメッセージルーターによってＢＡＲクライントに対して発行される。このコマンドは、MMSインボックスからの完全にフォーム化された“as-is”メッセージが構文解析(parsing)として利用可能であるかをＢＡＲクライントに知らせる。ＢＡＲクライントはＭＭＳメッセージ内容を構文解析し、そしてメッセージ署名を正当であると確認する。構文解析が成功すると、ＢＡＲクライントは適切なアドレスブックＡＰＩを呼び出し、携帯端末のアドレスブックを修正する。
（８）PeriodicCheck():
このＡＰＩコマンドはＢＡＲクライアント内のタイミングチェック機能を呼び出すために、携帯端末のファームウェアサブシステムによって周期的にコールされる。一実施例において、ＢＡＲクライントは、最も短い持続時間内のファンクション・コールからリターンし、携帯端末をロックしてしまったりタイマー競争状況を生じさせてしまうことを避ける。
注：一実施例において、ＢＡＲの組み込みクライントは、組み込み型携帯端末のコンフィギュレーション・マネジャーに対して直接的な接続性を使用する。
（９）GetTime():
このＡＰＩコマンドは、現在の時刻を検索するためにＢＡＲクライアントによって携帯端末ファームウェアに対して発行され、サーバーに送信されるＭＭＳメッセージ用のタイムスタンプとして使用する。一実施例において、現在の時刻は携帯端末のローカル時刻であってＧＭＴではない。
注：一実施例において、ＢＡＲの組み込みクライントは、そのタスク・キュー(task queue)を周期的にチェックし、現在の時刻と日付を決定する目的のために、組み込み型携帯端末のタイミングサービスに対して直接的な接続性を使用する。
（１０）GetServerAddress():
このＡＰＩコマンドは、ＢＡＲサーバー用のＭＭＳ宛先アドレスを検索するためにＢＡＲクライアントによって携帯端末ファームウェアに対して発行される。携帯端末ベンダーは、携帯端末のコンフィギュレーション設定内のアドレス値を設定する能力を選択的に提供する。
（１１）IsEnabled():
このＡＰＩコマンドは、ＢＡＲアプリケーションの組み込み状態を検索するためにＢＡＲクライアントによって携帯端末ファームウェアに対して発行される。携帯端末ベンダーは、携帯端末のコンフィギュレーション設定内のフラグ値を設定する能力を選択的に提供する。理想的には、このコンフィギュレーションは、over the air（ＯＴＡ）コンフィギュレーションコマンドによってプログラム可能である。

アドレスブック情報のためのデータ記憶は、図５に一例を示したように、論理的には２次元データ構、携帯端末内の特定のコンタクトデータエントリのインデックスに対応する。第２の次元５３０は、時間正規化された変更イベント５４０、即ち、アドレスブックのすべて又は幾つかの情報が変更される時間の瞬間に対応する。

この２つの次元のデータ対照を用いて、所与のデータラベルのためにアドレスブックの履歴アーカイブ（保管）を再構築することができる。一実施例において、所与のスロット番号に対応するすべてのコンタクト情報は、そのスロットに対する変更履歴を考慮している。追加５６０及び修正５５０は、特定のスロットの空でないレコードによって示される。削除５８０は、特定のスロットの空のレコードによって示される。所与の時間で、スロット内でいかなる変更も生じないことを示さないレコードはない。

特定のスロットについて、携帯端末によってサーバーへ送信されるデータ情報がエラーである可能性はある。詳細に言えば、携帯端末は、特定のレコードに対する最後の更新時の前に、時刻に対応する日付値を送信することができるであろう。これはエラー状況であり、サーバーによって処理される。一実施例において、サーバーは特定のレコードに対応する任意のデータエントリを、現在のサーバータイムスタンプを置き換えることによって、そのレコードに関する以前のエントリに先立つ値で、又は値のない全てによって正規化するだろう。特定のレコードエントリに関連するすべてのレコードは唯一(unique)であり、古い順に昇順で記憶される。

一般的に、アドレスブックのバックアップ情報は加入者毎に唯一である。１つのデータベースに情報を集約させる必要はない。多数の加入者データベースからのどんなレコードも今まで共有やリンクされていないので、一実施例では、個々の加入者のマイクロデータベースが用いられる。別の実施例では、単純なフラットファイル構造が使用される。

モバイル携帯端末には固有の記憶制限があるので、加入者のデータベースは１０００エントリを超えることは期待できない。加入者データベースの平均サイズは、３０よりも少ないエントリを含むものとされている。この理由のため、要求されているわけではないが、ＢＡＲサーバーは、構造化データベースシステムというようりもオンザフライ（on-the-fly）によるソート(sort)を使って固定データからメモリ内データベースの創生を実行することが可能である。

共有されたロッキング(locking)が利用可能に与えられた場合、アクセスのコリジョン（衝突）を心配することなくファイルとして、加入者用の完全なアドレスブックデータベースを加入者データ領域に記憶することができる。加入者のアドレスブック情報は個人的なものであり、認証されていない者によって見られるようになっていない。一実施例において、顧客サポート職員は加入者のアドレスブック内容を見ることができない。セキュアなバックアップ記憶がＢＡＲサーバー上で提供される。

個々の加入者アドレスブックエントリがロジカルスロット番号によって秘密化され、携帯端末内のスロット番号と直接的に対応付けられる。スロットに対する変更の履歴を纏めながら、多数のエントリが各携帯端末スロット用に存在し得る。一実施例においては、エントリはアドレスブックの寿命のために維持されている。

一実施例において、加入者データベース内のどんなデータもこれまで除去されていない。むしろ、加入者データベースは、スロット単位を基本としてアドレスブックでなされた修正の完全な履歴レコードを含む。各アドレスブックエントリはタイムスタンプを含み、そのタイムスタンプは特定の時間についてアドレスブック状態を再構築するために用いることができる。
例えば、特定の時間についてアドレスブック状態を再構築するために、システムは所与のタイムスタンプに先立ってすべてのれコードを選択し、シーケンシャルな順でスロットごとに全てのレコードを適用する。その結果は日付でなされる修正の履歴表現を含むだろう。

追加は、空のスロットを置き換えるレコードエントリである。変更は、前のレコードエントリを置き換えるレコードエントリである。削除は、前のレコードエントリを置き換える空のレコードエントリである。このようにして、本システムは、ユーザのアドレスブックの履歴レコードと同様に、完全なバックアップを提供する。

アドレスブックがここで述べられたのであるが、コンタクト、カレンダー、メディアファイルなどのユーザの携帯端末デバイス上で維持される任煮の構造化データに対して同様なシステムを適用できることに留意されたい。

図９は本発明で用いられるコンピュータシステムの一実施例である。しかしあながら、当業者であれば、様々なシステムアーキテクチャの他の代替システムもまた用いることができることは明らかである。

図９に示すデータ処理システムは、情報通信のためのバス又は他の内部通信手段９１５、及び情報を処理するバス９１５に接続されたプロセッサ９１０を含む。システムは更にランダムアクセスメモリ（ＲＡＭ）又は他の揮発性記憶デバイス９５０（メモリと称する）を含み、それらは情報及びプロセッサ９１０によって実行される命令を記憶するバス９１５と接続する。また、主メモリ９５０は、プロセッサ９１０による命令実行の間、一時変数又は他の中間情報を記憶するのに用いられる。また、このシステムは読み出し専用メモリ（ＲＯＭ）及び／又はプロセッサ９１０用の静的情報及び命令を記憶するバス９１５と接続する静的記憶デバイス９２０、及び磁気ディスク又は光ディスク及びその対応のディスクドライブなどのデータ記憶デバイス９２５を含む。データ記憶デバイス９２５は、情報及び命令を記憶するバス９１５と接続される。

システムは更に、コンピュータユーザへ情報を表示するバス９６５を介したバス９１５に接続するブラウン管（ＣＲＴ）又は液晶ディスプレイ（ＬＣＤ）などの表示デバイス９７０とつながる。英数字及び他のキーを含む英数字入力デバイス９７５もまた、プロセッサ９１０へ情報及びコマンド選択を通信するバス９６５を介したバス９１５に接続する。付加的なユーザ入力デバイスは、プロセッサ９１０へ検出情報及びコマンド選択を通信したり、表示デバイス９７０条でカーソルの動きを制御するバス９６５を介したバス９１５に接続するマウス、トラックボール、スタイラス、又はカーソル検出キーなどのカーソルコントロールデバイス９８０である。

コンピュータシステム９００と選択的に接続される他のデバイスは、ネットワーク経由で分散システムの他のノードをアクセスする通信デバイス９９０である。この通信デバイス９９０は、イーサネット(登録商標)、トークンリング、インターネット、又はワイドエリアネットワークと接続するために用いられる、商業上利用可能な多数のネットワーク周辺デバイスのどれかを含み得る。さらに通信デバイス９９０は、ヌルモデム(null modem)接続、又はコンピュータシステム９００及び外部世界との間の接続性を提供する他の任意のメカニズムである。図９及びに示すシステム及びこれに関連するハードウェアの構成要素の何れか又は全ては、本発明の様々な実施例で用いられ得ることに留意されたい。

このシステムの構成は、特定の実施に基づいて様々な目的のために用いられることを当業者であれば理解できるであろう。本発明を実行する制御ロジック又はソフトウェアは主メモリ９５０、大規模記憶デバイス９２５、又はプロセッサ９１０にローカル又はリモートでアクセス可能な他の記憶メディアに記憶されることが可能である。当業者であれば、ここで開示する本システム・方法・プロセスは、主メモリ９５０又は読み出し専用メモリ９２０に記憶されたソフトウェアとして実行され、且つプロセッサ９１０によって演算されることができる。また、この制御ロジック又はソフトウェアは、そこに組み込まれた読み出し可能なプログラムコードを有するコンピュータ読み出し可能メディアを含む製造物に存在し、大規模記憶デバイス９２５によって読み出され、且つプロセッサ９１０がここで教示した方法に従う動作を生じさせる。

また、上述したように、本発明は、コンピュータハードウェア要素のサブセットを含む携帯端末又はポータブルデバイスに組み込まれることができる。例えば、携帯端末デバイスは、バス９１５、プロセッサ９１０及びメモリ９５０及び/又は９２５のみを含むよう構成される。また、携帯端末デバイスは、一組のボタン、又はユーザが一組の利用可能なオプションから選択することのできるシグナル伝達要素を含むよう構成される。また、携帯端末デバイスは、液晶ディスプレイ（ＬＣＤ）又は携帯端末デバイスのユーザに情報を表示するディスプレイの行列要素などの出力装置を含むよう構成される。従来の方法は、携帯端末デバイスなどを実行するために用いられている。ここで提供したような本発明の開示に接した当業者であれば、そのようなデバイスに関する本発明の実行は明らかであろう。

また、本発明は、上述したように、コンピュータハードウェア構成要素のサブセットを含む特別な目的の機器に組み込むことができる。例えば、その機器はプロセッサ９１０、データ記憶デバイス９２５、バス９１５、及びメモリ９５０、そしてユーザが基本的な方法でデバイスと通信することを許可する小さなタッチスクリーン等のまさに原始的な通信メカニズムを含む。一般的に、デバイスがより特殊用途になるほど、デバイスの機能に必要な要素は少なくなる。幾つかのデバイスの場合、ユーザとの通信はタッチベースのスクリーン、即ち小さなメカニズムを介すことになる。

当業者であれば、特定の実施に基づく様々な目的のためにこのシステムのコンフィギュレーションを使用することが理解できるであろう。本発明を実行する制御ロジック又はソフトウェアは、プロセッサ９１０にローカル又はリモートでアクセス可能な機械読み出し可能なメディアに記憶することが可能である。機械読み出し可能なメディアは、マシーン（例えば、コンピュータ）によって読み出し可能な形式で情報を記憶したり、転送したりする任意のメカニズムを含む。例えば、機械読み出し可能なメディアは、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶メディア、光記憶メディア、フラッシュメモリデバイス、電気・光・音響又は他の形式の伝播信号（例えば、搬送波、赤外線信号、ディジタル信号等）を含む。

先の実施例においては、典型的な実施例を明確にすることに関連して本発明を説明した。しかしながら、特許請求項の範囲に示すように、本発明のより広範な範囲及び範囲から逸脱することなく様々な変更及び修正がここでなされることは明白である。したがって、明細書及び図面は、限定的に解釈されるものではなく例示的にみなされるものである。

本発明は添付図面における例示された方法で説明されたが、これに限定されるものではない。なお、図面においては、同様の要素には同一の参照番号を付している。

システムの要素間における関係の一実施例を示したネットワーク図である。 バックアップ及び復元（ＢＡＲ）サーバーの一実施例であるブロック図である。 フリート(fleet)オペレーション用に用いられるＢＡＲサーバーの一実施例であるブロック図である。 携帯端末上に常駐するＢＡＲクライアントの一実施例であるブロック図である。 システムに記憶されたバックアップの二次元フォーマットの一実施例であるダイアグラムである。 ＢＡＲサーバーを用いた一実施例のフローチャートである。 フリート・オペレーション型のＢＡＲサーバーを用いた一実施例のフローチャートである。 ＢＡＲサーバーと関連するＷｅｂインタフェースのユーザインタフェース図である。 ＢＡＲサーバーと関連するＷｅｂインタフェースのユーザインタフェース図である。 ＢＡＲサーバーと関連するＷｅｂインタフェースのユーザインタフェース図である。 本発明で用いられ得るコンピュータシステムの一実施例であるブロック図である。

Claims (20)

1. バックアップ及び復元サービスを提供する方法であって、
   編集イベントに応答して生成されたメッセージをクライアントデバイスから受信する処理であって、そのメッセージはクライアントデータのエントリに対する変更を含み、エントリは関連スロットを有する、前記受信処理と、
   スロット番号に従って前記エントリに対する変更を追跡する前記編集イベントを、関連の日付とともにバックアップ及び復元サーバーに記憶する処理と、
   ユーザ要求に応答して、前記クライアントデバイスにあるクライアントデータを前記バックアップ及び復元サーバーから復元する能力を提供する処理と、を含む方法。
2. 編集イベントは、新たなエントリの追加、エントリの削除、ブランクエントリから実体のあるエントリへの変更、及びエントリの幾つかの側面(aspect)への変更の何れかを含む、請求項１に記載の方法。
3. 削除要求を受信したことに応答して、前記クライアントにメッセージを送信し、前記クライアントデータ内の全てのエントリを削除するよう指示することを更に含む、請求項１に記載の方法。
4. 前記送信者の認証を有効にする署名を前記メッセージと一緒に有することを更に含む、請求項１に記載の方法。
5. ユーザが前記サーバー上で前記クライアントデータを編集することができるためのＷｅｂインタフェースを提供する処理を更に含む、請求項１に記載の方法。
6. 前記クライントに対するメッセージを生成して、前記サーバー上でなされる変更に関連したクライアントデータを更新するよう指示することを更に含む、請求項５に記載の方法。
7. ユーザが前記バックアップ及び復元サーバーから新たなクライアントデバイスへ前記クライントデータを転送できるようにすることを更に含む、請求項１に記載の方法。
8. 前記バックアップ及び復元サーバーから前記クライアントデバイスへ、選択されたクライントデータを送信するマルチメディアメッセージシステム（ＭＭＳ）メッセージを構築する処理を更に含む、請求項１に記載の方法。
9. 前記クライントデータはアドレスブックであり、且つ前記メッセージの本体はｖＣａｒｄを含む、請求項８に記載の方法。
10. 新たなクライアントデータのレコードを受け入れることを、セッション開始プロトコル（ＳＩＰ）経由で前記クライアントに通知することを更に含む、請求項１に記載の方法。
11. 前記クラントデバイスがモバイル電話を含む通信デバイスに無線接続されている、請求項１に記載の方法。
12. 前記クライアントデバイスがvoice-over-IP（ＶｏＩＰ）電話を含む通信デバイスに有線接続されている、請求項１に記載の方法。
13. 複数のレコードを含むクライントデータと、
    クライアントデバイスの内容を消去するためのリセット・ロジックであって、その消去は前記デバイスからレコードのすべてを除去する前記ロジックと、
    前記サーバーに記憶された前記クライアントデータで前記クライントデバイスの内容をリセットする復元/転送ロジックと、を含むバックアップ及び復元サーバー。
14. 前記クライントデータは、
    前記クライアントデバイスが発行する認証に関連したベースラインデータと、
    前記クライアントデバイスが属する特定ユーザに関連したユーザデータとを、含む請求項１３に記載のサーバー。
15. 履歴データを含むクライアントデータを更に含む請求項１３に記載のサーバー。
16. 前記復元/転送ロジックは、更に、ユーザが前記クライントデバイスを前の状態にリセットできるようにすることを含む請求項１５に記載のサーバー。
17. 前記クライントデバイスがユーザに割当てられるときはそのクライントデバイスを作動状態にし、そして前記クライントデバイスが復帰するときはそのクライントデバイスを不作動状態にする、作動ロジックを含む請求項１３に記載のサーバー。
18. 前記サーバーはフリート(fleet)サーバーとして動作し、クライアントデバイスがユーザに提供されるときはそのクライアントデバイスがデフォルトデータで開始されるようにし、そして前記ユーザが前記クライントデバイスに復帰するときは初期状態(pristine state)に戻ることができるようにする、請求項１３に記載のサーバー。
19. 前記クライアントデバイスは、前記デフォルトデータに加えて、更に前記ユーザ自身のデータでイニシャライズされる、請求項１８に記載のサーバー。
20. 前記サーバーは、バックアップ及び転送サーバーとして動作し、ユーザが前記クライントデータを新たなクライントデバイスに転送できるようにする、請求項１８に記載のサーバー。

Images