(57)【要約】ネットワークオペレータは、複製されるべきデータオブジェクトに適用されるパラメータを使用して、利用可能な帯域幅を最も有効的に使用するために、データ複製サービスの利用可能な帯域幅の使用方法を制御できる。パラメータは、時間に依存してもよく、オブジェクトの複製の緊急度に関連してもよい。変更ログは、装置及び／又はサーバにおける複製されるべき全てのオブジェクトをリスト化し、パラメータは、オブジェクトの複製の緊急度を規定する各オブジェクトに関連付けられた重みを有する；各オブジェクトの重みは、ある時間における閾値とローカルで比較され、その比較結果により、オブジェクトがその時点で、複製されるために送信されるか否かが判定される。この重みと閾値との組合せにより、データの複製のタイミングに関して融通性のある制御を行い、帯域幅を最適に使用する。
2006511134.tif 000002
【特許請求の範囲】
【請求項１】
無線ネットワークを介して相互に接続する移動装置とサーバとの間で、データオブジェクトを自動的に複製する方法において、前記ネットワークを介するデータ複製のタイミングは、ネットワークオペレータがネットワークの帯域幅を有効的に使用するためのパラメータを適用して判定することを特徴とする方法。
【請求項２】
あるオブジェクトに適用される前記パラメータは、時間に依存し、且つオブジェクトの複製の緊急度に関連することを特徴とする請求項１記載の方法。
【請求項３】
変更ログは、前記装置及び／又はサーバにおいて複製されるべき全てのオブジェクトをリスト化し、前記パラメータは、前記オブジェクトの複製の緊急度を規定する各オブジェクトに関連付けられた重みを有することを特徴とする請求項１又は２記載の方法。
【請求項４】
前記パラメータは、時間に対する閾値を更に有し、各オブジェクトの前記重みは、ある時間における前記閾値とローカルで比較され、その比較結果により、前記オブジェクトがその時点で、複製されるために送信されるか否かが判定されることを特徴とする請求項３記載の方法。
【請求項５】
任意のオブジェクトの前記重みがある時点において前記閾値を超過する場合、接続は、その時点で確立することを特徴とする請求項４記載の方法。
【請求項６】
ある時点におけるオブジェクトの重みが：
（ａ）データ複製の方向（装置からサーバ、又はサーバから装置)
（ｂ）前記オブジェクトが、変更ログに存在し、自動的に削除された場合のその後のある時間又は期間を規定する保存期間
（ｃ）前記オブジェクトが上書き可能か否か
（ｄ）バイト単位でのサイズ
（ｅ）変更ログに入力された時間
（ｆ）優先順位
（ｇ）タイムアウト間隔
（ｈ）複製に割り当てられた時間
（ｉ）あるオブジェクトに対するデフォルト値でない優先順位のユーザ割り当て
（ｊ）利用可能なメモリ
のうちの１つ以上に依存することを特徴とする請求項３記載の方法。
【請求項７】
前記ネットワークオペレータが、オブジェクトの前記重みを随時変更できることを特徴とする請求項６記載の方法。
【請求項８】
前記ネットワークオペレータが、前記閾値を随時変更できることを特徴とする請求項４記載の方法。
【請求項９】
前記閾値は、利用可能な帯域幅を有効的に使用する方法において、時間と共に変動することを特徴とする請求項４記載の方法。
【請求項１０】
前記閾値は、エンドユーザの異なるグループ、個々のエンドユーザ又はアプリケーションに対する異なる方法において、時間と共に変動することを特徴とする請求項４記載の方法。
【請求項１１】
前記閾値の動的変動は、セル又はネットワークの負荷の変化に従って発生することを特徴とする請求項４記載の方法。
【請求項１２】
前記閾値の動的変動は、新規データ複製サービスの取り込みを促進するために発生することを特徴とする請求項４記載の方法。
【請求項１３】
前記閾値は：
（ａ）現在の時間
（ｂ）装置のローミングの状態
（ｃ）セル又はネットワークの負荷
（ｄ）前回の複製からの時間
（ｅ）ユーザの料金
のうちの１つ以上の状況に従って、変動可能であることを特徴とする請求項４記載の方法。
【請求項１４】
前記重みがある時間において前記閾値を超過するオブジェクトが１つも存在しない場合、任意のオブジェクトの前記重みが前記閾値を超過する前に経過する時間間隔を計算し、タイマを前記時間間隔に対して設定することを特徴とする請求項４記載の方法。
【請求項１５】
前記時間間隔は：
（ａ）新規オブジェクトが変更ログに追加される
（ｂ）新規閾値が展開される
（ｃ）前記タイマが無効となる
（ｄ）セル又はネットワークの負荷が変化する
（ｅ）装置のメモリが所定の基準を下回る
（ｆ）前記装置がローミングの状態の変化を検出する
（ｇ）新規アプリケーションが装置上で起動される
（ｈ）ネットワーク接続が終了する
場合に、再計算されることを特徴とする請求項１４記載の方法。
【請求項１６】
前記装置の前記エンドユーザは、特定のオブジェクト又はオブジェクトの型に関して、デフォルトの複製タイミングを無効にできることを特徴とする請求項１記載の方法。
【請求項１７】
複製されるべきオブジェクトは、時間の複製が発生すべきである時間制限を割り当てられることを特徴とする請求項１記載の方法。
【請求項１８】
前記時間制限は動的であることを特徴とする請求項１７記載の方法。
【請求項１９】
前記装置のメモリが変化する場合、又は前記装置が新規ネットワークにローミングする場合、前記時間制限は変更されることを特徴とする請求項１７記載の方法。
【請求項２０】
複製されるべきオブジェクトは、ある時間又は期間を規定する保存期間が割り当てられ、前記保存期間の後、前記オブジェクトは、複製されていない場合に、自動的に削除されることを特徴とする請求項１記載の方法。
【請求項２１】
個々のパラメータにより、前記ネットワークオペレータは、各々が異なる料金に対応付けられた異なるレベルのデータ複製サービスを、エンドユーザに提供することができることを特徴とする請求項１記載の方法。
【請求項２２】
接続開始オブジェクトが複製されると、変更ログにある更に別のオブジェクト及び保留状態の複製が送信されることを特徴とする請求項１記載の方法。
【請求項２３】
機会主義閾値機能は、送信される更に別のオブジェクトを判定することを特徴とする請求項２２記載の方法。
【請求項２４】
前記機会主義閾値は、装置がローミングネットワーク上にある場合に変化することを特徴とする請求項２３記載の方法。
【請求項２５】
前記機会主義閾値は、装置が配置されるセルの負荷の閾値を超過するか否かに従って変化することを特徴とする請求項２３記載の方法。
【請求項２６】
前記機会主義閾値は、ネットワークを介して通信する前記閾値に対する変化に伴い、装置及びサーバにより常に適用されることを特徴とする請求項２３記載の方法。
【請求項２７】
前記ネットワークオペレータは、前記機会主義閾値を変動させることができることを特徴とする請求項２３記載の方法。
【請求項２８】
複製の実際の時間は、移動装置の状態、ネットワークの状態及びパラメータに依存することを特徴とする請求項１記載の方法。
【請求項２９】
請求項１記載の方法を使用してサーバに対するデータ複製を可能にするソフトウェアでプログラムされたことを特徴とする移動装置。
【請求項３０】
請求項１記載の方法を使用して移動装置に対するデータ複製を可能にするソフトウェアでプログラムされたことを特徴とするサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動装置とサーバとの間でデータオブジェクトを自動的に複製する方法に関する；データの複製は、例えば、移動装置からサーバにデータのバックアップを行うため、及び移動装置がサーバに保持された最新のデータを有することを保証するために必要である。移動装置及びサーバは、無線ネットワークを介して接続される。無線ネットワークは、携帯電話ネットワーク等の広域ネットワークを含んでもよい。更に、無線ネットワークは、802.11ネットワーク等の狭域ネットワーク或いは狭域、広域及び有線接続の組合せを含んでもよい。
【背景技術】
【０００２】
移動装置（移動電話、スマートフォン、通信機及び他の種類の無線情報装置等）とサーバとの間のデータの複製は、大きな注目を集めてきた。参考文献として、PCT/GB2002/005308及びPCT/GB2002/005311（本出願人に付与）を示し、これらの内容を含有する。
【０００３】
無線ネットワークの１つの特徴として、効率的に帯域幅を使用する必要がある；これは、特に、携帯ネットワーク等の広域ネットワークに適用され、802.11システムに基づくネットワーク等の他の種類の無線ネットワークにも適用される。本発明は、このような全てのネットワークの使用の効率性を向上させることに関する。
【０００４】
携帯電話ネットワークオペレータは、移動装置に現在のデータをプッシュし、例えば、移動電話にダウンロード可能なゲーム名のメニュー等のデータで、その装置を更新する。効率的に帯域幅を使用する簡単な例は、利用可能な帯域幅を使用して、夜間に、これらゲームのメニューのダウンロードを実行することである。
【０００５】
今日まで、（単純な一方向プッシュ更新システムとは対照的な）データ複製システムの設計者は、ネットワークの帯域幅を有効利用することについて考慮していなかった。殆どのデータ複製システムが、帯域幅への影響を考慮することなく、即時に複製を行う必要があるという仮定に基づいていたので、この問題は発生した。
【０００６】
［本発明の概要］
第１の態様において、無線ネットワークを介して相互に接続される移動装置とサーバとの間で、データオブジェクトを自動的に複製する方法が提供される。この方法において、ネットワークを介するデータの複製タイミングは、ネットワークオペレータがネットワークの帯域幅を有効的に使用するためのパラメータを適用して判定する。
【０００７】
従って、本発明は、データの複製が即時実行されることが重要であるという仮定は不適切であるという見識に基づいている。帯域幅を最も有効的に使用するために、データ複製サービスの利用可能な帯域幅の使用方法を制御する機能を、（携帯サービス、又は802.11サービスを提供するネットワークオペレータ等の）ネットワークオペレータに提供できることは実用的である。
【０００８】
あるオブジェクトに適用されるパラメータは、時間に依存してもよく、オブジェクトの複製の緊急度に関連してもよい。例えば、変更ログは、少なくとも装置及びサーバにおける複製されるべき全てのオブジェクトのリストを作成してもよく、パラメータは、各オブジェクトに関連付けられた重みを含む。重みは、オブジェクトの複製の緊急度を規定する。パラメータは、時間に対する閾値を更に含んでもよく、各オブジェクトの重みは、ある時間における閾値とローカルで比較され、その比較結果により、オブジェクトがその時点で、複製されるために送信されるか否かが判定される。この重みと閾値との組合せにより、データの複製のタイミングに関して融通性のある制御を行い、帯域幅を最適に使用する。
【０００９】
更なる態様及び詳細を特許請求の範囲に定義する。
【発明を実施するための最良の形態】
【００１０】
本発明は、コグニマ  リミテッド（London, United Kingdom）により実現され、これにより、モバイルネットワークオペレータは、コグニマ複製TMシステムにおいて、データの複製のタイミングを制御することができる。本明細書は、コグニマ複製TMシステムの機能を熟知していることを前提とする。コグニマ複製TMシステムは、付録１で更に詳細に説明される。
【００１１】
尚、用語「サービス品質」又は「ＱｏＳ」は、本明細書を通して使用されるが、文中で指示がない限り、ＲＦＣ２４７５のＱｏＳの技術的な意味と関連しない。このＩＥＴＦのドキュメントは、ＩＰ層の多数のメトリクスに関して、ＱｏＳを明確に定義しているが、コグニマＱｏＳの第１の実現はアプリケーション層で適用され、ネットワークサーバパラメータのサービス固有の構成に依存しない。
【００１２】
１．  スケジュールされたデータの複製
本発明は、パケット交換無線ネットワークを介するデータ伝送が高度にスケジュールされる方法を規定し、ユーザ体験を大きく損うことなく、ネットワークの帯域幅の使用効率を向上させる。
【００１３】
１．１  コグニマ複製
コグニマ複製システムは、モバイルクライアントとネットワークサーバとの間でユーザが介入せずに、ユーザデータを複製するように設計されている。クライアント及びサーバの双方が、何時複製の実行を要求するデータに対する変更があったかを認識し、クライアント及びサーバにより共有される分散型オブジェクトデータベースの整合性を保証する。この方法は、システムのエンドユーザに対して手動による同期をとらずに、ユーザの全てのデータへの即時アクセスを常に実行できる。ユーザの目に見えない複製をすることは、複製が実行される時に、指示もユーザの制御も必要ないことを意味する。クライアント装置及びサーバ装置は、モバイルネットワークオペレータにより設定される動的パラメータに基づくタイミング判定により、複製が行われるべき時期を制御する。
【００１４】
１．２  スケジュールされた複製とネットワークオペレータ
ネットワークオペレータは、帯域幅を最も効率的に使用するために、１日のネットワーク使用サイクルの最大使用時及び最小使用時となる部分を均等化することを必要とする。すなわち、データ通信量を、最大使用時からサイクルの最小使用時の部分へ、可能な限り移動させる。オペレータは、複製が実行される時期に悪影響を及ぼす設定を調整し、ネットワークの効率化を図れることを高く評価するであろう。
【００１５】
更に、オペレータは様々な顧客の要求に対処するため、（通常、既存のデータ料金表と共にサービスレベルの選択肢として表現される）異なるＱｏＳ及び異なるコストレベルのサービスを提供したいと望むであろう。これは、ユーザの観点から複製ＱｏＳを規定するパラメータを動的に設定する機会を、ネットワークオペレータに提供することにより可能となる。
【００１６】
最も重要なことは、オペレータが提供するサービスが魅力あるユーザ体験を顧客に供給することである。
【００１７】
１．３  スケジュールされた複製とユーザ予想
コグニマの技術は、ユーザにとって新しいメンタルモデルを提供する。複製スケジューリングモデル及び対応するサービスプランは、ユーザに受け入れられるために、単純で、安定したものである必要がある。ユーザは可能な限り複製の詳細から隔離され、データはユーザの予想通りに複製されるべきである。
【００１８】
ユーザは、選択項目の範囲から１つのＱｏＳレベルを選択できることを望む。選択できない場合、ユーザはサービスに対して支払い過ぎを感じ、良いサービスを受けていないと感じる。ユーザに対するＱｏＳの選択項目は単純である必要がある。ユーザは、「連絡先：早急に、写真：一晩中、銀行業務：３０分で」等を提案するプランに対して「連絡先：２分で、写真：３時間で、銀行業務：一晩中」を提案するプランの相対的な利益を評価することが困難だと判断するだろう。如何にこれらの選択項目がネットワークオペレータの人口統計研究に適合していてもである。
【００１９】
ユーザは、一般標準のサービス−例えば基本−を選択し、１つの特定のサービスをアップグレードすることを、より快適に感じるであろう。ユーザは、コストに対するサービス又は個別のオブジェクトにより、複製の遅延を一時的にアップグレードする機会を得ることができる。例えば、ユーザは、プレミアムオプション「この写真を直ちに送信する」を希望するかもしれない。このオプションは、他の全ての写真はコグニマサーバに複製されるというデフォルトの優先順位を無効にする。
【００２０】
１．４  スケジュールされた複製とコグニマの構造
技術的観点から、方法は、複雑なルールセットではなく、単純なモデルに基づくことが必要である。タイムアウトに依存するルール（例えば、各オブジェクトは、各オブジェクトが変更−ログに入力される時に秒読みを開始する固有の時間制限を有する必要がある）は、性能に大きな悪影響を及ぼす。同様に、ｘ秒毎に変更−ログをポーリングするＣＲＥを必要とする方法も、性能を低下させる。
【００２１】
２．  ＱｏＳの実現
２．１  ＱｏＳプロファイル
任意の型のオブジェクトが任意のユーザのために複製される時期を判定するＱｏＳプロファイルの概念を説明する。
【００２２】
ネットワークオペレータは、全てのオブジェクトが最大使用時料金及び最小使用時料金、又はネットワーク通信量の要求の多い期間に従って複製されるタイミングに影響を及ぼすことができる。各装置が変更−ログのオブジェクトの複製優先順位及び時間制限を一致させ、複製の動作を判定することを防止するために、ネットワークオペレータはアプリケーション毎にタイミングプロファイルを定義できる。このグラフの形状は、データ通信量の監視に関するネットワークオペレータの経験を含む多くの要因により判定される。
【００２３】
ネットワークオペレータは、接続開始のオブジェクトが送信された後、データ接続開始の際に変更−ログ中の他の（優先順位の低い）オブジェクトを複製すべきか否かに影響を及ぼすことができる。これを制御する機会主義閾値（opportunism threshold）を定義できる。
【００２４】
例えば、いくつかの緊急を要さない項目が、装置の変更ログにある。ユーザは、装置の設定を変更してデータ接続を即時に開始する。ネットワークオペレータは、変更ログ内の２０ｋＢ未満のオブジェクトが、開始された接続を使用して複製される必要があることを特定した。
【００２５】
ユーザが接続を開始することに対するコストが、ネットワークオペレータが最大使用期間により多くのデータを送信することに対する影響より重要であるため、装置がローミングネットワークで動作している場合、異なる機会主義閾値を使用する必要がある。クライアント装置上の他のＱｏＳ制御パラメータと共に、機会主義閾値は、複製フレームワークを使用してクライアントに通信され、クライアントとサーバとの間で同調して自動的に保持される。
【００２６】
ＱｏＳ制御の更に進んだ実現において、ネットワークサーバは、ある移動装置に対するセルの負荷を判定できる。セルの負荷が、規定されたセルの負荷の閾値を下回ると、サーバは日和見主義的複製（opportunistic replication）を開始できることをクライアントに合図できる。クライアント装置が固定に割り当てられたＩＰアドレスを有し、サーバから即時に接続される場合、これは全てのＩＰネットワークにおいて、最大の利益をもたらす。この条件に当てはまらない場合、通信開始要求をクライアント装置に送信する処理は、セルの負荷に影響を与え、複製を開始する前にセルの負荷が変化する機会を与えるシステムの待ち時間が長くなる。
【００２７】
ネットワークオペレータは、展開後、データ通信量のグラフ、機会主義閾値及びセルの負荷の閾値を更新できる。これにより、経験によるＱｏＳ制御の最適化が可能になる。
【００２８】
装置の変更ログに追加される全てのオブジェクトは、この時点でPause Before Connect遅延の管理下にある。しかし、ネットワークオペレータが、一括処理される変更の範囲を限定するための機構を規定したため、一般に、ＱｏＳ制御が、Pause Before Connect遅延に取って代わる。
【００２９】
２．２  サービスプロバイダ制御
サービスプロバイダは、コグニマサービス毎にＱｏＳプロファイルを判定する機会を有する。このプロファイルは、複製時間制限の集合を含み、そのサービスにより作成されるコグニマオブジェクトは、その時間制限内に複製されることになっている。時間制限内に複製が実際に行われる時間は、コグニマクライアントソフトウェアの状態、クライアント装置の状態、並びに、最大使用時／最小使用時のデータ料金及びセルの負荷等のネットワーク要因を含むシステムにおける多くの要素により判定される。サービスプロバイダは、時間制限をゼロに設定、すなわち、ある型のオブジェクトに対して即時複製の要求ができる。複製が実行され、失敗した場合、そのオブジェクトは複製のスケジュールがされたままの状態であるが、既存のバックオフ動作の管理下にある。
【００３０】
例えば、プロバイダは、サーバに対する新規連絡先の複製が２時間の時間制限内に実行される必要があると特定する。連絡先が、ネットワークが確立している間又はセルの負荷が低い間に作成される場合、装置は、即時にその連絡先を送信してもよい。そのタイミングがネットワークの最大使用時、又はセルの負荷が高い時である場合、装置は２時間まで、状況が変化するのを待つことができるが、その後は、状況に関係なく複製を実行しなければならない。
【００３１】
ＱｏＳプロファイルは、複製のタイミングを判定するパラメータとして、以下の要素を定義する。
・オブジェクトの型（例えば、連絡先、写真、ＤＣＣディレクトリ、ＤＣＣ使用ログ等）
・オブジェクトの作成方法（例えば、送受話器上の新規連絡先、ポータル上で作成された連絡先に対する編集等）
・移動の方向（例えば、ポータル上の連絡先の編集は即時に移動する、電話機の連絡先の編集は２時間以内に移動する）
・送受話器はホームネットワーク／ローミングネットワーク上にある（例えば、写真はホームで即時に複製されるが、ローミングの場合は１２時間以内に複製される）
以下は、任意である。
・オブジェクトのサイズ（例えば、５ｋＢを超過する連絡先（すなわち、画像を含む）−１２時間以内に送信、５ｋＢ以下の連絡先−即時に送信）
・サーバが最初に起動される場合の異なる動作（例えば、写真の最初のアップロードは即時で、その後は１２時間以内）。
【００３２】
複製の時間制限は、オブジェクトの作成時間に基づくＱｏＳプロファイルにより、オブジェクトに割り当てられる。しかし、装置上の利用可能なメモリが変化する等の後続する事象、又は送受話器が他のネットワークへローミングするか否かに従って、既に割り当てられた制限を変更できる。これにより、変更ログ中の項目の重みを臨時に再計算することが必要となる。
【００３３】
サービスプロバイダは、ＱｏＳプロファイルのオブジェクトの保存期間を規定できる。オブジェクトが変更ログ中に存在する間に、そのオブジェクトの保存期間に到達すると、オブジェクトは削除される。
【００３４】
例えば、サービスプロバイダは、ＤＣＣサービスの気象情報の更新が２４時間の保存期間を有することを特定する。この時間内に項目が送受話器に複製されなかった場合、その項目は変更ログから削除される。
【００３５】
サービスプロバイダは、オブジェクトを上書き可能として定義できる。変更ログにある旧バージョンと置き換わる新規オブジェクトが、変更ログに入力されると、旧バージョンは、削除される。この場合、サービスプロバイダは、新規オブジェクトが上書きされたオブジェクトのタイミングを採用すべきか、又は新規の複製時間制限と共にシステムに入力されるべきかを判定できる。デフォルト設定では、新規オブジェクトが置き換えるオブジェクトに固有のタイミングを採用する。
【００３６】
例えば、サービスプロバイダは、気象情報の更新クラスのオブジェクトが上書き可能であり、新規エントリが上書きされたエントリのタイミングを採用する必要があると特定する。すなわち、旧予報メッセージは新規予報メッセージで上書きされるが、新規予報メッセージもまた複製の対象となる。
【００３７】
サービスプロバイダは、プロファイルの集合内で、異なるサービスのクラスを提供できる。これを実行する１つの方法は、サービスのクラス毎に個別のＱｏＳプロファイルを定義することである。
【００３８】
例えば、Goldサービスにおいて、連絡先は、作成後即時に複製されるが、同一のネットワークのSilverサービスでは、２時間以内に複製が実行される。
【００３９】
コグニマサービスが、特定の料金において、サービス群として加入者に提供される可能性はあるが、ＱｏＳ料金表は、個別のコグニマサービスに適用される。
【００４０】
ＱｏＳプロファイルは、展開された後、サービスプロバイダにより変更可能である。各ＱｏＳプロファイルの解釈がシステムの全てのエンティティ間で共通であるように、プロファイルに対する変更は、関連するクライアント装置に複製される。
【００４１】
２．３  ＱｏＳプロファイル取得についての説明
プロファイルに定義されたネットワークオペレータ（又は「netop」）のパラメータは、以下について均整をとることを意図する：
・ある料金に対して、受け入れられるユーザ体験は何か？
・変更を一括処理する（概して、ローミングの際、更に多くの量を一括処理する）ために与えられるべき範囲は？
・ネットワークの最大使用時を回避するために与えられるべき範囲は？
通常、ユーザは、ポータル上の変更を、電話機における変更よりも速く必要とすると予想される−ＰＣに向かっているユーザは、電話機を有しているが、逆に電話を有しているユーザは、ＰＣに向かっていないだろう。起動して最初の複製は、最初のユーザ体験のため、即時である必要がある。
【００４２】
ユーザが、ローミングの際にいくつかのデータ接続を開始することに対するコストは、ネットワークオペレータが最大使用期間により多くのデータを送信することに対する影響より重要である可能性がある。
【００４３】
３．  ＱｏＳのアルゴリズムの実現
３．１  概要
コグニマシステムにおいて、ＱｏＳは、クライアント及びサーバの双方の機能性を拡張させるものとして実現される。特に、ＱｏＳは変更ログの動作の変形を必要とし、待機中の変更ログのエントリのある属性を再計算する必要性を生じる。この再計算の結果として、複製が実行される。
【００４４】
３．２  アルゴリズムの説明
アルゴリズムは、いくつかの構成要素で構成される。変更ログの項目の重みを導入する。この重みは、変更ログの項目の送信必要性の緊急度を示し、重みが大きい程、項目の緊急度が高い。また、変更ログの閾値を導入する。閾値以上の重みを有する項目は、即時に送信される必要がある。接続が確立すると、（閾値−デルタ）より大きい重みを有する全ての項目が送信される。デルタは機会主義を表す。
【００４５】
具体化するため、重み及び閾値は０と１００との間で変動するとする。即時送信されるべき項目の重みは、１００である；変更ログのゼロの閾値は、変更ログの任意のエントリが即時に複製可能であることを示す。
【００４６】
重み及び閾値の双方とも、１日を通して変動可能である。予測可能な変動もあれば、動的な変動も起こる。いくつかの例で、これを明らかにする。
【００４７】
図１において、重み４０における直線は、重みがある時間を通して一定であることを示す。ある時間内に実行されるべき項目の重みを図２に示す。項目の重みは、低い優先順位を示す相対的に低い値で開始し、制限時間に到達すると、重みが急激に大きくなる−新しい値１００は、時間Ｔ１において、クライアントにオブジェクトの複製を実行させる。
【００４８】
ある時間においてのみ実行される項目は、図２のようになるが、特定の期間後ではなく、特定の時間において急激な変化が起こる。項目の重みは、動的に変化することがある。例えば、装置のスペースが欠乏しているとする：項目の重みは、変更ログからその項目を取り出すために増加し、ゴースティング（この用語の説明に関しては、付録１から現時点までの説明を参照）を可能にする。更に、閾値もある時間を通してのグラフを有する。次の図３は、１日の閾値サイクルの様子の例を示す。グラフは、最大使用時間帯（例えば、９時以降の数時間）の低い通信量から保護するための大きい閾値と、従来のデータネットワークの最小使用時（２４時〜６時の間、閾値はゼロ）の小さい閾値とを有する。
【００４９】
この例は、各帯域に対して適切に設定された複製の閾値を有する最小使用時、標準時、最大使用時の３つの通信帯域に分割される１日のサイクルを効果的に示す。尚、閾値が０になる午前０時直後に４つ目の帯域が存在する−これは、１日に１度、最も閑散な期間に、全ての変更ログが空になることを保証するために導入される。この閾値ゼロの期間は、１週間に１度、又はネットワークオペレータにより規定される他の間隔で定義されるが、規定されたＱｏＳプロファイルがオブジェクトの複製を妨害しないことを保証することが推奨される。一方で、プロファイルにおいて、最小使用期間は、夕方遅くから夜にかけて延長され、データネットワークが低い通信量を提供すると予測される時間を示す；この時間中に大きなオブジェクトを複製することにより、モバイルネットワークオペレータは、最大使用時間帯に、制限された利用可能な帯域を適切に使用できる。
【００５０】
閾値ゼロの期間は、ネットワークオペレータが経験により調整できる；個々のユーザグループ、各アプリケーション、又は各ユーザに対して、微調整をすることにより、最小使用時のネットワークを交替で使用し、あるサーバに対する全ユーザベースで、同時にコグニマサーバへ接続しないことを保証する。
【００５１】
例えば、セルの負荷から、又は新規サービスの市場活動促進のために、閾値は、動的に変化する（最大使用時間帯にネットワーク上にある基本料金のデータが処理を促進できることが好ましい時間中に）。装置がそのセルの負荷が高くないことを検出できれば、閾値を少し下げ、複製をトリガしてもよい。
【００５２】
アルゴリズムの中心は、変更ログの各項目の閾値のグラフ及び重みのグラフを計算することである。任意の項目の現在の重みが現在の閾値よりも大きい場合、接続は確立する。そうでなければ、任意の項目が閾値を超過する次の時間（すなわち、グラフが交差する時）が推定され、その間隔でタイマが設定される。重み及び閾値の双方が動的であるため、再計算をトリガする以下の事象が起こる：
・変更ログの新規項目が追加される
・サーバは、新しい閾値をクライアントにプッシュしてもよい。これは、クライアントのＱｏＳオブジェクトが通常の方法の複製を通して制御されるため、前事象の特別な事例である。すなわち、新しい閾値は、サーバ上にある装置の変更ログのキューに変更が登録されることにより、クライアントへ配信される−この変更ログのエントリは、即時複製を実行するために、１００の重みを有する必要があり、閾値の変更の結果、既に順番待ちにある他のエントリの複製をトリガしてもよく、又は遅延させてもよい。
・タイマの無効−通常、これは、変更ログの既存のエントリの重みが現在の変更ログの閾値を超過する予定である時点を示すタイマとなる
・セル（又はネットワーク）の負荷の変更
・クライアント装置上の利用可能なメモリが、所定の基準を下回る
・装置がローミングの状態の変化を検出する
・装置に新規アプリケーションが展開され、起動される
・接続の終了−これにより、「次の接続」タイマの作成／更新を行う
２つの異なる計算を行う：項目の重みのグラフ及び閾値のグラフである。
【００５３】
時間中の任意の時点における項目の重みに影響を与えるパラメータは、以下の通りである：
・方向（クライアント→サーバ、又はサーバ→クライアント）
・保存期間（通常、これは、クラスで符号化される）
・書き換え可能（通常、これは、クラスで符号化される）
・バイト単位でのサイズ
・変更ログに入力された時間
・優先順位
・タイムアウト間隔
・複製に割り当てられた時間
・あるオブジェクトに対する非デフォルト値のユーザ割り当て（ユーザのメディアギャラリアカウントにアップロードするための画像の「直ちに送信」オプション等）
・利用可能なメモリ
これらのパラメータが重みに与える影響の範囲は、上述の「サービスプロバイダ制御」において説明したように、サービスプロバイダ（すなわち、ネットワークオペレータ）により制御される。
【００５４】
変更ログの現在の閾値に影響を与えるパラメータは以下の通りである：
・その日の時間
・ローミングの状況
・セル／ネットワークの負荷
・前回の複製からの時間
・ユーザの料金。
【００５５】
変更ログを復元する度に、クライアントソフトウェアは、重みのグラフと閾値のグラフとが次に交差するまでの時間間隔を計算する；これは、スケジュールされた時間の前に変更がない場合でも、スケジュールされた複製が必要に応じて実行されるようにするためである。一般に、変更ログに対する「次の事象」は、この交差の計算により予測された通りであるか、又は、変更ログに新規エントリを登録する外部の事象（これは、当然、全ての重みの値及び閾値を復元してもよい）により作成される。尚、上述の例のように、有効なＱｏＳプロファイルが閾値ゼロの期間を有していない限り、変更ログが空である場合、「次の接続」事象は、「なし」の値を有してもよい。
【００５６】
３．３  バンディング
バンディングと呼ばれる構造により、クライアントの重みのグラフ及び閾値のグラフを制御する。全てのグラフは、急激に変化する水平な線の集合（階段関数の連結）として描画できる。従って、あるクラスのＱｏＳプロファイルは、帯域の配列により記述できる。帯域は、以下のようにパラメータ化される：
【００５７】
【表１】
2006511134.tif 000003
【００５８】
帯域は、開始時間からのデルタとして、又は、システムクロック（絶対値）に対して定義できる。オブジェクト作成から２時間以内に実行されるようにスケジュールされるべきクラスに対する重みのグラフは、一対の帯域により描画される：以下の表は、Contactsクラスに対するＱｏＳ重みプロファイルを説明する。
【００５９】
【表２】
2006511134.tif 000004
【００６０】
上述の例におけるグラフを説明する閾値のグラフは、以下の通り表される。
【００６１】
【表３】
2006511134.tif 000005
【００６２】
尚、サーバ上で作成されたオブジェクト又は変更されたオブジェクトに対して異なる重みが存在し、この重みは、１日のサイクルを通して一定である。この方法は、サーバ側の変更がクライアント上で行われた変更と異なる優先順位を有してもよいという情報をミラーリングするのに使用される。
【００６３】
クライアント及びサーバは、上述の表をカプセル化するＱｏＳオブジェクトを伝送し、複製のスケジューリングに影響を与える。ユーザの装置は、装置にインストールされたデータクラス毎のＱｏＳオブジェクトに加え、システム全体を示す単一の閾値オブジェクトを保持する。各ＱｏＳオブジェクトは、単一の重みのグラフを描画する帯域の配列を保持する。これらのグラフが交差する地点は、何時ある型のオブジェクトが複製されるかを判定する−これらの交差地点は、ある時間におけるシステムの各オブジェクトの重み及び閾値を判定することにより、計算される必要がある。
【００６４】
３．４  変更ログ項目の重みの計算
変更ログの項目の重みを計算する必要がある。その項目のクラスに対するＱｏＳオブジェクトは、データ記憶装置から検索される。バンディング構造が検査され、重みが、重みのグラフから検索される（帯域の型がデルタの場合、現在の時間−作成時間を計算することにより、又は帯域の型が絶対値の場合、システム時間を比較することにより）。重みの計算の際、オブジェクトサイズをパラメータとして含めるために、バンディング構造に別の２つのフィールドを追加した。
【００６５】
【表４】
2006511134.tif 000006
【００６６】
オブジェクトサイズがサイズ制限を超過する場合、超過の重みが使用される−尚、この重みは、クラスのデフォルトの重みより大きい又は小さいことがある。一部のアプリケーションにおいて、オブジェクトの重みは、重みを１００に設定するというユーザの要求（実際上は、「直ちに送信」ボタン）により無効にすることが可能である。
【００６７】
３．５  変更ログの閾値の計算
現在の変更ログの閾値の重みは、現在のシステム時間を使用して、閾値ＱｏＳオブジェクトから抽出できる。この値は、動的変数により変更できる−例えば、装置がローミングの状態を検出できる場合、閾値に影響を与えられる。一般に、ローミングの際、閾値はより大きく、複製のコストがより高いという事実を示す；ある帯域における閾値に対する下限を特定でき、装置がホームネットワークへ戻る前に、優先順位の低いオブジェクトを全く複製しないようにする。展開の際に、モバイル端末がローカルセルの負荷の状況を認識できる場合、セルの負荷は、現在の閾値を調整する要素として使用される：ローカルセルの通信負荷がある値（例えば、７０％）より低い場合、閾値を減少できる。セルの負荷がある値（例えば、９５％）を高い場合、閾値を増加できる。
【００６８】
ＱｏＳオブジェクトは、閾値が変化すると分かっている時間を表すタイマ事象を作成し、ネットワークオペレータにより定義されるようなＱｏＳプロファイルの構造を反映する。これらのタイマ事象の各々が実行されると、ＱｏＳ閾値は、新しい値が割り当てられ、重み付けの再計算により、正確な重みを有するオブジェクトを複製できる。
【００６９】
３．６  次の接続時間の計算
項目の重み≧閾値の重みとなる次の時間を検出するために、項目の重みのグラフと変更ログの閾値のグラフとの比較が必要である。この計算では、定義上、予測できない閾値の重みに対する動的変化を無視する。これは、帯域を一致させ、一致する時間の重みを比較するとても単純な計算である。
【００７０】
複製セッションを開始する可能性のある３つの事象が存在する：
・新規帯域へ移動したために、変更ログの変更オブジェクトの重みが増加する
・ある時間ベースの料金から別の料金へ移動したために、ＱｏＳの閾値が減少する
・現在の閾値よりも大きい重みを有する新規エントリが、変更ログに登録される
最初の２つの事象の場合、セッションが開始される時間は、予測可能であり、各複製セッションの終了時に計算する必要がある。これは、次のスケジュールされた接続時間を表す。
【００７１】
付録１  データ複製システムの説明
United Kingdom、Londonの会社であるコグニマによる実現を参照して、本発明を説明する。コグニマは、モバイルサービスプロバイダ（ＭＳＰ）及びネットワークオペレータが必要とする消費者のデータサービス採用の増加、貴重な顧客の忠誠の促進、及び競合他社とのサービスの弁別に直接対処するデータ複製技術を開発した。
【００７２】
コグニマのデータ複製ソリューションは、以下の方法でこれらの問題に対処する：
・魅力があり、使用が容易なデータサービスにより採用を増加させる。
・加入者のＭＳＰにより制御されるサーバ上に、加入者の個人データを確実にバックアップすることによりチャーンに対する高いバリアを確立する。
・ＭＳＰは、顧客体験を制御することにより、弁別されたサービスを作成できる。
【００７３】
１．  コグニマデータ複製フレームワークの使用の概要
コグニマのデータ複製フレームワークにより、モバイルサービスプロバイダは、消費者市場に対して、魅力あるサービスを作成できる。ＭＳＰは、データセンタにおいてコグニマサーバをホストとして有する。サーバは、Oracleデータベースと、コグニマのマルチスレッド型Java(登録商標)通信サーバとを有し、標準に基づくJ2EEアプリケーションサーバ及びCarrier Grade Unix(登録商標)ハードウェアの環境で動作する。第４節及び後述の節では、技術的実現を詳細に説明する。
【００７４】
コグニマフレームワークは、移動電話に入力されたデータを、コグニマサーバを介し、他の電話機に対して自動的に（ユーザが介入せずに）複製する。同様に、コグニマサーバに接続された外部システムからのデータも、最新の状態で、移動電話に自動的に保持される。
【００７５】
モバイル加入者は、コグニマに有効化されたアプリケーションを使用し、個人情報及び友人に対して、常時利用可能な即時接続を体験する。
・「個人情報」は、加入者のアドレス帳、メッセージ、銀行預金口座の明細、株価、ピザの発注、カレンダ、現在の職場への経路の交通量、又は他の任意の個人内容を含むことができる。データは、常に、コグニマサーバ上に確実にバックアップされ保持される。また、全ての関係するクライアント装置に自動的に複製される。
・「常時利用可能」は、常にユーザが装置にローカルに格納された個人情報へアクセスできるため、現在ネットワークへ接続していても接続していなくても、加入者が所持している装置又は送受話器の個人情報にアクセス可能であることを意味する。更に、ユーザは、ウェブインタフェース−バーチャルホンを介して、サーバ上の自分の個人データを直接編集し、管理できる。
・「即時」は、加入者がサーバからのデータのダウンロードを待つ必要がないことを意味する；データが送受話器に自動的に送信されるため、最新情報は、加入者が必要だと気付く前でも、送受話器に存在する（例えば、送受話器によるポーリングが発生してもよい；これは、３０分毎等の定期的でもよく、又は所定の時間（午後４時、午後５時等）でもよい。また、送受話器に対するプッシュが発生してもよい）。
・コグニマサーバは、規定された装置又は規定された個人に対して、データを複製できるため、加入者は、多数の装置及び友人とデータを共有できる。
【００７６】
１．１  コグニマアプリケーションの例
【００７７】
【表５】
2006511134.tif 000007
【００７８】
【表６】
2006511134.tif 000008
【００７９】
【表７】
2006511134.tif 000009
【００８０】
２．  モバイル加入者の利益
コグニマは、以下の主な利益に基づく量販市場消費者データサービスを実現するための理想的なフレームワークを提供する：
・使い易さ：ユーザの介入は不要である。加入者は、データにアクセスするために「同期」ボタン又は「ダウンロード」ボタンを押下する必要がない。システム構成及び確実なデータ転送は、エンドユーザには完全に見えない。
・即時可用性：常に、ユーザは、ローカルデータと即時に対話でき（オフラインであっても）、その一方で、更新処理がバックグラウンドで密かに実行される。例えば、ユーザは、地下鉄に乗っている間に、個人内容を読むことができる。ユーザ体験は、データ移送から独立している。
・入手し易さ：ＭＳＰは、複製の実行の時期及び提供されるサービス品質（ＱｏＳ）を制御できる。しかし、ユーザ体験がデータ移送から独立しているため、低いＱｏＳでも、ユーザのサービスの認識に悪影響を与えない。極めて重大なことは、これにより、ＭＳＰは、ユーザ体験を犠牲にせず、相対的に低いＱｏＳで、低コストの契約のサービスを提供することができる−例えば、銀行口座取引明細等の緊急を要さないデータサービスに対して、データ複製を一晩を通して実行しても、ユーザにとって満足のいくものである。一晩を通してのデータの複製は、十分に使用されていない帯域を使用するため、最大使用時のデータ複製より相当安価である。緊急のデータ複製（例えば、存在情報）は、定期的又は（任意に）連続的（プッシュ）に、いつでも実行可能であり、課金率がより高い。更に、電話機のメモリ及び処理能力を有効的に使用することにより、最も安価な量販市場向けの電話機においても、コグニマクライアントソフトウェアを低コストでインストールできる。
【００８１】
３．  モバイルサービスプロバイダの利益
コグニマは、新しいデータ収益の産出、チャーンの減少、及び競合他社のサービスとの弁別の方法をＭＳＰに提供する。
【００８２】
３．１  既存モバイルサービスの使用の増加
コグニマは、既存モバイルサービスの使用を増加させる。
・メッセージングサービス及びコンテンツベースのサービスは、更に便利で迅速となり、サービスの使用が増加するであろう。
・存在情報の即時性の向上により、チャット及びインスタントメッセージングの使用が増加し、また、未使用能力の時期を警告することにより音声通話が増加する。
・複数の装置の使用が容易であるため、ユーザは、いかなる場合においても、適当な電話機を所持できる。これにより、より多く電話をかけ、より多くのメッセージを送信できる。
【００８３】
３．２  魅力ある新規サービス
コグニマは、魅力ある手頃なモバイルデータサービスの迅速な導入を可能にする。
・コグニマは、予備のネットワーク容量のみを使用して、新規サービスに対する魅力あるユーザ体験を低価格の電話機に配信する。これは、ネットワークオペレータにとって、手頃で適応性があり、ＭＳＰは、量販市場の加入者に対して、理解可能及び予測可能な価格付けができる。
・新規コグニマサービスのアプリケーション開発の殆どがサーバ側で行われるため、ＭＳＰは、新規サービスを迅速に市場へ提供できる。
・コグニマのクライアントソフトウェアは、フラッシュメモリのアップグレードとしてインストールできるため、スマートフォンのような性能を有する今日の量販市場向け送受話器が提供される。新規ソフトウェアアプリケーションは、既存のコグニマ使用可能な送受話器に、無線でダウンロードされるため、ＭＳＰは、ＭＳＰを支持する新規装置を待たずに、新規データサービスをロールアウトできる。
・サードパーティアプリケーション開発者は、ＭＳＰのコグニマインフラストラクチャを活用して、ＭＳＰのネットワークに対して、新規アプリケーションを開発できる。
【００８４】
３．３  チャーンの減少
コグニマサービスは、チャーンに対して有効なバリアとしての役割を果たす。例えば、個人情報をＭＳＰのコグニマサーバに確実に格納する加入者は、新しい電話機を購入し、且つその新規装置へ、全ての個人情報を即時に回復できる。加入者が異なるサービスプロバイダと契約することを決定すると、全ての個人情報は消去される。
【００８５】
３．４  弁別
現在加入者は、全てのネットワークにおいて、モバイルデータサービスを使用する同一の基本的な体験をする。例えば、ＷＡＰサービスを使用する体験は、ＷＡＰプロトコル、電話機のブラウザ及びアクセスされる内容により規定される。多くのＭＳＰは、固有のユーザ体験を加入者に提供することにより、自身を弁別する必要があることを認識しているが、移動送受話器におけるサービスのカスタマイズに対する厳しい制約が、弁別を妨害する。
【００８６】
コグニマは、ＭＳＰが送受話器におけるサービスを実現し、加入者のユーザ体験を制御することを可能にする。最も重要なことは、コグニマが相互情報交換可能性を犠牲にすることなく、これを可能にすることであり、業界標準は直接コグニマサーバと統合することにより達成される。バリューチェーンにおけるＭＳＰの地位は、送受話器の製造会社及びコンテンツプロバイダの強力なブランドに対して強固になる。
【００８７】
４．  コグニマデータ複製フレームワーク機能設計
４．１  概要
詳細な説明の本節及び次節において、コグニマデータ複製システムの実際の動作方法について説明する。クライアント装置、コグニマサーバ及びウェブクライアントの動作を対象とし、特定のハードウェア、プログラミング言語、ソフトウェアクラスの設計又は環境の詳細は説明しない。また、基本的なデータ構造及び使用されるアルゴリズムを説明する。
用語
【００８８】
【表８】
2006511134.tif 000010
【００８９】
４．２  目的
コグニマソフトウェアの目的は以下の通りである：
・ユーザ即時アクセスにより、無線データ接続が可能な複数のハンドヘルド装置上のデータの「最新」コピーを参照し変更できるすること。
・ユーザが、従来のウェブブラウザを使用して、同一データを参照し変更できるようにすること。
・ユーザのデータの確実なバックアップを容易に提供すること。
・複雑でコストの高い処理をサーバへ移動することにより、安価な送受話器上の強力なデータ機能性をユーザに提供すること。
【００９０】
４．３  最高レベルの説明
クライアント装置は、クライアント装置のデータベースにあるユーザのデータのコピーを保持する。ユーザは、ネットワーク接続を有するか有さないかに関わらず、このデータにアクセス可能であるため、常に即時アクセスができる。ユーザがユーザの装置上でデータを変更すると、その変更は、変更−ログにコピーされる。クライアント装置は、定期的に、無線ネットワーク上のコグニマサーバに接続し、変更−ログから変更を送信し、新規データを受信する。これにより、データを変更する動作は、ネットワーク接続の必要性から切り離される。（すなわち、プッシュは、好適な実現において連続的ではない）。コグニマサーバは、クライアント装置から受信したデータ変更で、データベースを更新し、ユーザの所有する他の装置の変更−ログを読み込む。これらの装置は、次に接続する時にその変更を受信する。従って、各装置が同一のデータのコピーを有し、同期がとられる。
【００９１】
コグニマサーバは、ウェブサーバを含む。ウェブサーバにより、ユーザは、クライアント装置上で、直接ウェブブラウザを使用して、コグニマサーバデータベースに保持されるデータのコピーを検査し、そのデータに対して変更ができる。コグニマサーバは、ユーザがネットワーク／インターネット上の他のサーバと通信するために、ゲートウェイとしても動作する。例えば、クライアント装置は、メッセージオブジェクトにフラグを設定することにより、ＳＭＳ又は電子メール又はファックスとしてメッセージを送信するように、コグニマサーバに実際に要求できる。コグニマサーバは、電子メールサーバ、ＳＭＳサーバ及びファクシミリ装置と通信する機能を含む。これは、呼び出し音、銀行預金口座の詳細、ゲーム等を保持するサーバへと拡張できる。他のサーバと対話するために、コグニマサーバにソフトウェアを適用することは、クライアント装置にソフトウェアを適用するよりも容易で安価である。
【００９２】
５．  下位レベルの概要
５．１  データ構造
５．１．１  ＩＤ
オブジェクトデータベースの用語：クラス及びオブジェクトを使用し、コグニマユーザデータを説明する。しかし、ＯＯプログラミング概念と類似して呼ばれるものと混同する可能性があるため、注意が必要である。
【００９３】
コグニマネットワークの全てのユーザは、ユーザＩＤが割り当てられる。このＩＤは、ネットワークに固有、すなわち、あるネットワークオペレータにより提供される。全てのユーザは、ユーザＩＤ及びコグニマサーバＵＲＬの組合せであるコグニマアドレスを有する。これは、世界中で固有である。ユーザに属する各装置は、装置ＩＤが割り当てられる。この装置ＩＤは、ユーザに固有である。これは、８ビットであるため、ユーザは、最大２５３個（ＩＤ２５４はウェブのために確保され、ＩＤ２５５は予備、ＩＤ０は無効である）の装置を有することができる。全てのユーザデータは、クラス（contentsクラス、messagesクラス、bank transactionsクラス等）に分類され、クラスには、世界中で固有のクラスＩＤが割り当てられる。例えば、クラスＩＤ「１２」は、連絡先を参照する。
【００９４】
クラスのインスタンスはオブジェクトであり、ユーザに固有のオブジェクトＩＤが割り当てられる。例えば、contactsクラスオブジェクトは、「John Smith」の連絡先であるかもしれない。オブジェクトＩＤは、オブジェクトを作成した装置の装置ＩＤを、装置の寿命期間中に増加する単調な増加カウントと連結することにより生成される。各装置は、最大１６，７７７，２１５個（この制限に達した場合、装置ＩＤをリセットできる）のオブジェクトを作成できる。クラスは、そのクラスを構成するプロパティにより定義される。クラスは、基本的にプロパティの配列である。クラスの各プロパティは、クラスに固有の（且つ実際には、プロパティ配列のプロパティの配列位置を示し、ゼロから開始する）プロパティＩＤを有する。
【００９５】
５．１．２  オブジェクトの作成
オブジェクトは、装置上で作成される。オブジェクトは、オブジェクトＩＤが割り当てられ、装置のデータベースに保管される。コピーも、変更−ログに保管される。装置が次にコグニマサーバに接続する時、変更−ログのエントリが送信される。コグニマサーバは、オブジェクトをサーバのデータベースに保管し（システム時間を記録する）、必要なクラス特有の処理（電子メールの生成及び送信等）を実行する。更に、対象としてクラスに宣言したユーザが所有する他の装置の変更−ログに、エントリを追加する。（エントリは、装置上のクラスの正確なバージョンに対するものである必要がある。）
オブジェクトは、ウェブポータル上で作成されてもよい。オブジェクトＩＤが生成され（上述のように、２５４の装置ＩＤを使用して）、装置と同様に処理される。ウェブポータルの変更−ログは存在せず、コグニマサーバデータベースから直接選択内容を取得する。
【００９６】
オブジェクトは、サーバアプリケーション（例えば、メッセージングモジュールは、電子メールを受信し、この電子メールからメッセージオブジェクトを作成する）により作成されてもよい。オブジェクトＩＤが生成され（上述のように、２５４の装置ＩＤを使用して）、装置と同様に処理される。
【００９７】
５．１．３  オブジェクトの更新
既存のオブジェクトの１つ以上のプロパティは、装置上で変更される。その変更は、装置のデータベースに保存される。変更された各プロパティは、装置の変更−ログにエントリを生成するために使用される。これらは、コグニマサーバに送信される。
【００９８】
更新時間がコグニマサーバデータベースのプロパティに対する「前回の変更」時間よりも後の場合、コグニマサーバは、データベースにその変更を保管し（プロパティに対して新しい「前回の変更」時間を記録する）、必要なクラス特有の処理を実行し、他の装置の変更−ログにエントリを追加する。ここで、他の装置というのは、そのユーザに属し、そのクラスを宣言し、且つそのプロパティを含むクラスのバージョンを有する装置である。更新は、変更が行われた装置の変更−ログにも登録される。これは、奇妙に思われるかもしれないが、以下のような場合に対処するために必要となる：
「ユーザが２つの装置Ａ及びＢを有する。午後５時にＡのプロパティ７をオフラインで更新し、午後６時にＢのプロパティ７をオフラインで更新する。最初に、Ａをネットワークに接続する。Ａの７の値は、Ｂに送信されるように、変更−ログに登録される。その後、Ｂを接続する。Ｂの７の値がより新しいため、Ａに送信されるが、ＢはＡの値を取得する。７の値を複製し、Ｂに戻すことにより、これを修正する。」
コグニマサーバが、削除済みと記録されたオブジェクトに対する更新データを受信し、且つその更新が削除よりも後の場合、未削除として解釈される。そのオブジェクトは、削除されず、更新され、オブジェクトの最新情報は、対応する全ての装置の変更−ログに登録される。ウェブポータル又はサーバアプリケーションからの更新は、同様に動作する。
【００９９】
５．１．４  オブジェクトの削除
オブジェクトは、装置上で削除される。そのオブジェクトは、装置のデータベースから除去され、エントリは、クラスＩＤ及びオブジェクトＩＤをリストにした変更−ログに登録される。そのエントリは、コグニマサーバに送信される。
【０１００】
削除時間がオブジェクトの前回の更新時間よりも後の場合、コグニマサーバは、データベースのそのオブジェクトに、削除済みと記録し、クラス特有の処理を実行する。更に、そのユーザに属し且つそのクラスを宣言した他の装置に、エントリを追加する。
【０１０１】
削除時間が前回の更新時間よりも早い場合、その削除が無効であることを示し、オブジェクトの復元が、削除を行った装置の変更−ログに登録される。
【０１０２】
削除されたオブジェクトは、削除の状態が明らかになるように、ウェブポータルにおいて参照可能である。ユーザは、未削除にするために、オブジェクトを選択できる。削除の印がコグニマサーバデータベースのオブジェクトから除去され、オブジェクトを復元するエントリが、そのユーザに属し且つそのクラスを宣言した全ての装置の変更−ログに登録される。
【０１０３】
５．１．５  プロパティの型
各プロパティは、型を有する。現在、９つの認可されたプロパティの型が存在する：
【０１０４】
【表９】
2006511134.tif 000011
【０１０５】
CogStringは、文字数とそれに後続する文字である。文字列がASCIIの場合、文字列のより使用される空間は、（４＋文字数）バイトである。文字列がUnicodeの場合、使用される空間は、（４＋（文字数×２））バイトである。
【０１０６】
CogTypedStringは、CogStringとそれに先行する型（４バイトの符号なし整数）である。現在のところ、型付けされた列の使用目的は、連絡先である。その型は、連絡先の型（例えば、電子メールアドレス、自宅の電話）を識別し、文字列はアドレス（例えば、bob@xxx.yyy、01233556677）を保持する。
【０１０７】
CogBlobは、バイト長と後続するバイト数である。任意のバイナリデータを格納するために使用される。
【０１０８】
CogArrayは、２つのＢＬＯＢが後続する４バイトの符号なし整数「型」として渡される。この「型」は、配列に保持される要素の型を示す。第１のＢＬＯＢは、索引ＢＬＯＢである：これは、第２のＢＬＯＢに対するオフセットのシーケンス（４バイトの符号なし整数）を保持する。第２のＢＬＯＢは、データＢＬＯＢであり、バイナリ集合のシーケンスとして、配列の要素を保持する。要素は、索引ＢＬＯＢをカウントすることによりデータＢＬＯＢから抽出され、データＢＬＯＢの要素の開始オフセットが取得される。これは、渡される時のCogArrayのストリーム構造である。特定のシステム内において、従来のベクトル（すなわち、解析済み）として出現してもよい。
【０１０９】
CogArrayの唯一の実現例は、MessageAddressである。MessageAddressの各要素は、AddressPairである。AddressPairは、連絡先ＩＤ（contactオブジェクトのオブジェクトＩＤ）とそれに後続する連絡先である。
【０１１０】
５．１．６  スマートプロパティパラメータ
一部のプロパティは、「スマート」にすることができる。すなわち、特定の装置対してプロパティをパラメータ化し、その装置の特徴を示すプロパティのデータを変形することができる。そのパラメータは、実際には、２つの４バイト符号なし整数であり、一方は、スマート型、他方は、最大サイズである。例えば、メッセージの本文を保持するプロパティは、メモリが制限された安価な電話機においては、スマート型kCogPlainTextで最大サイズ１００にパラメータ化されるが、より多くのメモリを有するＰＤＡにおいては、スマート型kCogRickTextで最大サイズ１０００にパラメータ化される可能性もある。
【０１１１】
アプリケーションが装置に追加されると、パラメータはコグニマサーバにより格納される。クラスに対する新規オブジェクト及び更新データは、その装置に対するコグニマサーバの変更ログに登録されると、スマートパラメータに従って処理される。この処理は、例えば、テキストを切り捨てること、Unicodeのテキストをnarrowテキストに変換すること、又は画像形式を変換することを含む可能性がある。
【０１１２】
データ保全性のために、コグニマサーバデータベースに保持されるオブジェクトは、オブジェクトが生成された時のオブジェクトのコピーであることが重要である。装置では縮小バージョンを参照する場合でも、コグニマサーバ上の完全なバージョンを効率的に操作できる。
【０１１３】
５．１．７  クラスバージョン
４バイトの符号なし整数により定義されるクラスバージョンの概念が存在する。新規クラスバージョンは、旧クラスの最後にプロパティを追加してもよいが、既存のプロパティの変更又は除去、あるいは、既存のプロパティの間に新規プロパティを挿入することは、許可されない。これにより、バージョン間の相互情報交換が可能となる。異なるスマートプロパティパラメータを有するクラスの定義は、異なるバージョンではない。
【０１１４】
５．２  ユーザデータの伝達
コグニマは、データベース間でコピーに必要なデータを最小限にするため、クラスメタデータの概念を利用する。クラスメタデータは、基本的に、プロパティメタデータの配列である。プロパティメタデータは、プロパティＩＤ、プロパティ型、スマート型及び最大サイズである。
【０１１５】
ユーザデータは、クラスＩＤ以外のフォーマットされていない情報を有するストリームとして転送される。このストリームは、クラスメタデータを検索することにより、解析される。ストリームがクラス６に対して受信され、且つクラス６のクラスメタデータが、プロパティ０はKcogTypeUIntであり、プロパティ１はKcogTypeStrであると決定すると、ストリームの最初の４バイトは、符号なし整数として解釈され、次の４バイトは、後続する文字列の文字数ｎを保持する符号なし整数として解釈され、更に、次のｎ（Unicodeの場合は、ｎ×２）バイトは、文字列の文字を保持すること等が分かる。
【０１１６】
クライアント装置は、サポートするクラスを、コグニマサーバに対して宣言する。これにより、装置は、未処理のユーザデータ（クラスＩＤ、オブジェクトＩＤ及びその他の内容を含むヘッダと共に）を順次送信し、必要な帯域幅を最小限にすることができる。これは、例えば、更に多くの帯域幅を要求するＸＭＬ依存のシステムと対比される。
【０１１７】
更に、クライアント装置のクラス宣言は、コグニマサーバが装置のためにデータを変形できるように、スマートプロパティパラメータを含む。プロパティの「意味」をアプリケーションにハードコード化することは、強調すべきことである。クラスメタデータは、クラス７のプロパティ２が最大３０文字を有する文字列であることを示す。これは、クラス７のプロパティ２をフットボールチーム名として解釈するアプリケーションのコードである。
【０１１８】
５．２．１  データ複製の問題点の詳細
データは、クライアント装置及びクライアント装置が接続されるサーバ（コグニマサーバとして知られる）で作成されたオブジェクトに保持される。これらオブジェクト及びオブジェクトに対して行われた変更は、クライアント装置とコグニマサーバとの間で複製される。
【０１１９】
複製処理の設計は以下のことを可能にする：
・同一なオブジェクトの集合が、コグニマサーバ及びあるユーザに対するサーバにログインしている全てのクライアント装置に保持されるように、オブジェクトの集合を、複製対象として定義することができる。任意の装置又はサーバで作成された新規オブジェクトは、他の全ての装置に複製される。オブジェクトの任意のプロパティにおける変更は、全ての装置に複製される。
・データの変更のみがクライアントからコグニマサーバへ、又はコグニマサーバからクライアントへ送信されるため、ある更新に対して、最小限のデータのみを、ネットワークを介して転送できる。
・制約のあるクライアント装置におけるプロパティの更新は遅く、オブジェクトの各プロパティに対する前回の変更時間を保持するには多くの空間を必要とするため、設計の主要部分として、オブジェクトの各プロパティに対する変更時間を、クライアント装置に保持する必要がないようにした。
・コグニマサーバが十分な記憶領域及び処理能力を有するため、コグニマサーバ上に、オブジェクトの全てのプロパティに対する変更時間を格納することは、問題ではない。
【０１２０】
５．２．２  メタデータ
システムが動作するために、オブジェクトのあるクラスに対して定義されるプロパティの明確な概念が必要である。これは、クラスメタデータの定義を可能にするＣ＋＋コンパイラマクロをプログラマに提供することにより達成される。
【０１２１】
クラスで使用されるプロパティの定義は、クラスメタデータの定義となる。この定義は、あるプロパティの型をＣＲＥ（Cognima recognition engine）に伝え、データリンクを介して転送するために、オブジェクト又はプロパティをパック及びアンパックすることが可能になる。ＣＲＥシステムが動作するために、全てのクライアント及びサーバは、同一のクラスメタデータの定義を有する必要がある。従って、以下のことが発生する：
・新規メタデータ定義がクライアント装置で宣言される場合、その定義はコグニマサーバに送信され、コグニマサーバは、全てのクライアントにそれを送信する。
・新規メタデータ定義がコグニマサーバで宣言される場合、その定義は、全てのクライアント装置に送信される。
・新規クライアント装置がコグニマサーバに初めてログインする場合、オブジェクトが送信される前に、全てのメタデータ定義が、装置に送信される。
・上述の全ての場合において、コグニマサーバは、メタデータが参照するクラス（及び特定のプロパティ）にアクセスするクライアントに対して、メタデータ定義のみを送信するように、今後の最適化を行ってもよい。
【０１２２】
５．２．３  変更ログ
変更ログの目的は、クライアント装置が前回コグニマサーバに（又は、コグニマサーバがクライアント装置に）接続してから発生した変更を記録することである。コグニマＡＰＩを使用して、アプリケーションはＣＲＥに接続し、オブジェクトを作成又は削除、あるいは、オブジェクトのプロパティを変更できる。これらの変更は、変更された通りに、変更が行われた時間と共に、ローカル装置の変更−ログに追加される。あるオブジェクトが常に識別可能であるように、オブジェクトが作成される時に、オブジェクトに固有の識別子が付与される。
【０１２３】
同様に、コグニマサーバで実行されるアプリケーションによるオブジェクトの作成及び削除、並びに、オブジェクトプロパティに対する変更は、コグニマサーバのユーザに登録された全てのクライアント装置に対する全ての変更−ログに追加されるべき変更である。変更時間は、オブジェクト又はプロパティ毎に記録される。
【０１２４】
変更ログは、２つの方法で作成される：
・新規オブジェクトが作成され、プロパティが変更される時（通常、これはクライアント装置の場合）
・あるいは、オブジェクト及びプロパティの前回の変更時間を使用するために変更ログが必要な時で、変更ログがシステム上に格納されている場合に、要求に応じて作成される（ある環境下において、上述の方法の代わりに、この方法がコグニマサーバ上で使用されてもよい）。
【０１２５】
５．２．４  複製
クライアント装置は、変更ログ中に、送信すべき項目を有する場合、コグニマサーバに接続する（同様に、コグニマサーバの場合、クライアント装置に接続する）。デフォルトでは、変更ログの項目は、変更ログに追加された順番で送信される。しかし、プレミアムサービスを提供するために緊急のデータ等を送信する直前に、再度優先順位付けされてもよい。以下の項目が転送される：
・オブジェクトのあるクラスの各プロパティの型を含むメタデータ定義。
・作成された新規オブジェクトであり、そのオブジェクトのプロパティの内容を含む。
・変更されたプロパティであり、そのプロパティの新しい値を含む。
・削除されたオブジェクト
上述の全ての場合において、適当なＩＤが、関係するオブジェクト、クラス及びプロパティを識別するために送信される。変更ログの全ての項目に、項目が変更ログに追加された時間を記録する。これらの時間は、常にローカル装置の時間であり、第６．２節で説明される時間管理方法により、ＧＭＴに変換される。
【０１２６】
クライアント装置がコグニマサーバから変更ログの項目を受信する場合：
・クライアント装置は、コグニマサーバから新規オブジェクトメッセージを受信すると、その新規オブジェクトをローカルデータベースに追加する。
・クライアント装置は、コグニマサーバからオブジェクト削除メッセージを受信すると、ローカルデータベースにあるそのオブジェクトに、削除済みと記録する。
・クライアント装置がプロパティの変更を受信する時、次のことが常に仮定される。コグニマサーバがデータベースの現状を支配するため、変更は、常にローカルデータベースに保持されるプロパティの値に対して行われる。
【０１２７】
コグニマサーバがクライアント装置から変更ログの項目を受信する：
・コグニマサーバがクライアント装置から新規オブジェクトを受信すると、新規オブジェクトは、コグニマサーバデータベースに追加され、更に、最初にその新規オブジェクトを送信した装置の変更−ログとは別に、そのユーザに登録されているクライアント装置の全ての変更−ログにも追加される。
・コグニマサーバがクライアント装置からオブジェクトの削除を受信すると、そのオブジェクトは、削除の記録がされ、オブジェクト削除メッセージは、最初にオブジェクトの削除を送信した装置の変更−ログとは別に、そのユーザに登録されている装置の全ての変更−ログに追加される。
・コグニマサーバは、プロパティの変更を受信すると、変更時間をコグニマサーバにあるプロパティに対して保持される現在時間と比較する。プロパティの変更時間がコグニマサーバに保持される時間よりも遅い場合、サーバデータベースのプロパティの値は変更され、この変更は、プロパティの変更を送信した装置を含み（その間にオブジェクトの他の更新が装置に送信される場合に備えて）、そのユーザに登録されているクライアント装置の全ての変更−ログに追加される。プロパティの変更がコグニマサーバに保持される時間よりも遅くない場合、格納されたプロパティの値がより新しいため、変更は行われない−しかし、ユーザが必要な場合にその値を後で検索できるように、その値は、コグニマサーバ上の旧プロパティ値のリストに追加される。時間が比較される時、以下の第６．２節で説明される時間管理方法が使用される。
【０１２８】
装置が最初にコグニマサーバに接続される場合、全てのクラスメタデータ定義及びそのユーザに対するデータベースにある全てのオブジェクトが送信される。一般に、削除メッセージは、オブジェクトに対して削除の記録のみを行う。そのオブジェクトを参照する全てのオブジェクトが削除された後で、オブジェクトは、データベースから実際に除去できる。
【０１２９】
５．２．５  最適化
上述の複製プロトコルの最適化バージョンは、変更ログにあるエントリの集合を考慮する。変更ログ（コグニマサーバ又はクライアント装置の）がまだ複製されておらず、次のエントリが追加される場合、既存のエントリは、次の接続の間に複製される必要があるエントリ数を減少させるために、走査される：
・新規エントリが、既に更新のスケジュールがされているプロパティに対する更新である場合、後のエントリのみを保持する必要がある。
・新規エントリがオブジェクトの削除である場合、そのオブジェクトに対する全てのプロパティの更新は、変更ログから除去できる。
・新規エントリが「未削除」コマンドであり、元の削除がまだ変更ログに存在する場合、２つのエントリは、共に変更ログから除去できる。
【０１３０】
６．  主なアルゴリズム
６．１  エンディアンの処理
オペレーティングシステムは、基本的に、数字及び文字列が格納されるバイトの順番を選択するリトルエンディアン又はビッグエンディアンである。異なるエンディアンを有する２つのコンピュータが通信する場合、一方のコンピュータは、データパケットのエンディアンを切り替える必要がある。コグニマ環境において、コグニマクライアントソフトウェアは、ホストクライアント装置と同一のエンディアンを使用する。コグニマサーバは、クライアント装置のエンディアンを判定し（クライアントからのデータの最初のパケットにある基準値を使用する）、一貫したエンディアンをコグニマサーバに維持する必要がある場合は、次の受信データを変換する必要がある。更に、コグニマサーバは、クライアント装置に送り返すデータを変換する必要がある。
【０１３１】
６．２  システム時間の同期化
異なる装置は、必然的に若干異なるシステム時間を有する。クライアント装置からコグニマサーバに送信された変更は、変更時の装置のシステム時間で記録される。変更が行われた順番を判定し、正確な更新が記録できるように、異なる装置の各時間を解決することは、コグニマサーバの責任である。
【０１３２】
装置のログオンは、現在の装置の時間を含む。コグニマサーバは、ネットワークの待ち時間を補償し、ログイン時間をサーバのシステム時間と比較する必要がある。これにより、装置の時間とコグニマサーバの時間との間のデルタを取得する。このデルタは、このセッションにおいて、装置から送信される別の時間に適用できる。
【０１３３】
コグニマサーバは、連続セッションにおける装置からの複数のデルタを比較し、装置のクロック「クリープ」又はタイムゾーンの変化を判定できる：システムの全てのクライアント装置が相互に十分に同期のとられたクロックを有すると、仮定することはできない：
・クロックタイムは、装置のクロックの精度によって装置上で変動する。
・一部のユーザは、例えば、５分早くクロックを設定することを好む。
・一部のユーザは、ロケール設定を調整するのではなく、夏時間のためにクロックを変更する（一部のＯＳは、ロケール機能を提供しない、すなわち、ユーザにクロックを直接変更させる）。
【０１３４】
この問題を回避するために、サーバは、サーバ上で比較される場合、クライアント装置により使用される時間をＧＭＴに調整し、メッセージがコグニマサーバからクライアント装置に送信される場合、ＧＭＴをクライアント装置と等しい時間に調整する役割を担う。
【０１３５】
クライアント装置は、ローカルクロックから取得した時間で、変更ログの全ての項目にタグ付けする−クライアント装置に関する限り、クライアント装置自体のクロックに基づく時間で処理する。
【０１３６】
クライアント装置がコグニマサーバに接続する度に、クライアント装置のクロックにより提供された現在の時間の表示を送信する。これにより、サーバは、以下を算出できる：
・ＧＭＴに対するデルタの値を算出できる
・サーバがＧＭＴに対する前回のデルタの記録、及び前回接続された時間を保持し、これらの時間を比較できるため、移動装置のクロックにおいて、前回ログオンした時間からのずれがあるか否かを算出できる。ずれがある場合、サーバは、移動装置により送信された全ての時間を案分して調整できる。
【０１３７】
例えば、以下の表は、コグニマサーバに接続するクライアント装置での事象のパターンを示す。クライアント装置の時間は、コグニマサーバの時間よりも５分遅く、毎時間、１分ずつ遅れていく（要点を示すための極端な場合である）。更に、要点を示すために、以下のことを仮定する。すなわち、09:00〜12:00の間、ユーザが飛行機内で、コグニマサーバに接続しないため、装置は、この時間中に接続しない：
【０１３８】
【表１０】
2006511134.tif 000012
【０１３９】
算出するために、コグニマサーバに時間が格納される前後にプロパティの変更が行われた場合、時間Ｘ及びＹを算出する必要がある。上述の情報から、コグニマサーバは、クライアントが前回接続したのは、約３時間前であり、その時の時間差が５分であったため、現在の時間差は８分であるということが分かる。従って、クロックのずれが線形的に発生すると仮定すると、コグニマサーバは、装置がＧＭＴに対して５分遅れており、クロックは毎時間１分ずつ後ろにずれていくことを算出する。
【０１４０】
これにより、クライアント装置がプロパティＡの変更が10:00であると認識するその時間に初期のずれである５分を加算し、プロパティが変更されるまでの時間に発生する追加のずれである１分を加算する必要があることを算出できる。
【０１４１】
同様に、プロパティＢは、初期のずれ５分に、09:00からプロパティが変更された11:00までの間に２時間経過したため、２分加算して、11:07に調整される必要がある。
【０１４２】
実際には、クライアント装置の時間とＧＭＴとの間の時間に対するデルタは、数分かもしれないが、ずれは、１時間に１秒の数分の１であろう。
【０１４３】
６．２．１  時間の調整
ＧＭＴに対するデルタ及びクライアント装置のクロックのずれと同様に、ユーザは、クライアント装置の時間を変更できる。ユーザは、時間を正確なローカル時間に再設定することにより、時間を変更してもよい（これを自動的に発生させる選択肢をユーザに提供できるが、一部のユーザは、クライアント装置の時間を自分で制御したいと考える可能性もある−例えば、ユーザは、５分早くクロックを設定することを好む）。また、ユーザは、ローカル時間の変更（すなわち、夏時間又はタイムゾーンの変更）を反映して調整を行ってもよい。ユーザが装置のクロックをユーザに都合の良い時間に変更でき、装置が単にこれを考慮に入れることが目的である。
【０１４４】
ユーザがクライアント装置の時間に対して変更を行うと、殆どのオペレーティングシステムは、この変更を報告する（これを行わないシステムの場合、時間は、例えば１分毎にポーリングされ、そのような変更をチェックする）。時間における変更を検出すると、クライアント装置は、新しい時間と変更前の時間との間のデルタを算出する。例えば、ユーザがタイムゾーンを移動したために、１時間加算される変更であるかもしれない。クライアント装置は、この時間差を調整時間として格納し、コグニマサーバへの次の接続のために保管する。更に、クライアント装置は、変更ログの各エントリを参照し、ログの全ての時間を調整時間で更新する。これにより、変更ログのエントリは、常に、クライアント装置のローカル時間を基準とすることが保証される。
【０１４５】
そのような調整は、コグニマサーバへの複数の接続間で行われることがある−各時間の時間の変更量が調整時間と合計され、ログの全ての時間がクライアント装置のローカル時間を基準とするように、変更ログが更新される。
【０１４６】
クライアント装置が次にコグニマサーバに接続すると、クライアント装置は、ログオン時に、格納された調整時間、すなわち、クライアント装置のクロックが、前回の接続から後前に調整された時間量を送信する。その後、コグニマサーバは、GMTに対するデルタ及びずれの計算により、時間からこの時間量を除去できる。
【０１４７】
６．２．２  クライアント装置に対するＧＭＴ
同一の一連の計算は、反対に、コグニマサーバで行われた変更のＧＭＴ時間を、あるクライアント装置の正確なローカル時間に変換するためも実行される。
【０１４８】
６．３  アプリケーションの追加
アプリケーションは、ユーザデータを保持するために、１つ以上のクラスを使用する。クラスの定義は、アプリケーション中にハードコード化される。クラスのバージョンは、アプリケーションのリリースにより同等になる。
【０１４９】
統計アプリケーションは、フットボール選手についてのデータを保持するFootballerクラスを使用する。アプリケーションが最初にクライアント装置で開始されると、装置がすでに保持するFootballerクラスのバージョンを、装置から問い合わせる。装置上のバージョンが、アプリケーションが使用されるためにハードコード化されたバージョンと同一である場合、何も実行されなくてよい。
【０１５０】
装置がFootballerクラスのより新しいバージョンを保持する場合、アプリケーションは、予想より多くのプロパティを処理するのに十分にロバストである必要がある。（この状況は、複数のアプリケーションに使用されているクラスを有し、何らかの理由で、その複数のアプリケーションのうち旧バージョンの１つをインストールした場合に発生する。これは、稀であるが、相互依存するアプリケーションは、同時にアップグレードすることが理想である。）
装置がFootballerクラスの旧バージョンを保持する（又はどのバージョンも有していない）場合、アプリケーションのFootballerクラスのバージョンでそれを置き換える必要がある。新バージョンは、コグニマサーバに送信される。従って、コグニマサーバは、全ての装置で使用されたクラスのバージョンのリストを維持する。
【０１５１】
ウェブポータルのページは、ハードコード化された装置アプリケーションと同等である。ウェブは、クラスの最新バージョンに従って、データベースからオブジェクトを抽出できる。予想してハードコード化されたプロパティより多くのプロパティが存在する場合は、ウェブは、それらを無視できる。従って、ウェブは、クラスのバージョンを宣言する必要がない。
【０１５２】
６．４  変更−ログの最適化
コグニマサーバは、装置が次に接続する時に装置に送信される変更をリスト化した全ての装置に対する変更−ログを維持する。変更−ログに行うことのできる最適化は、例えば：
・同一のプロパティに対して２つより多くの変更が変更−ログのキューに登録されている場合、最後のみ保持される必要がある。
・オブジェクトに対する削除がキューに登録されている場合、それに先行するキューにある更新は、除去してもよい。
・オブジェクトに対する更新がキューに登録されている場合、それに先行するキューにある削除は、除去される必要がある。
・装置が新規アプリケーションを登録する場合、アプリケーションに送信すべきオブジェクト（例えば、メッセージ履歴）が極めて多くなる可能性がある。変更−ログは、アプリケーションに追加された「妥当な」数のオブジェクト（例えば、最新の２０個のメッセージ）のみを有する。
【０１５３】
７．  ゴースティング、復活、固定、回収
通常、ユーザデータを保持するためのクライアント装置の使用可能な空間は、サーバの使用可能な空間よりも数桁小さい。装置は、データの部分集合を保持する必要があり、この部分集合を維持するためにユーザが行う作業は、可能な限り少なくする必要がある。ゴースティング及び回収は、これを支援するツールである。
【０１５４】
クラス定義は、あるプロパティに「ゴースティング可能」としてフラグを立てることを含む。これは、オブジェクトがゴースティングされる場合、プロパティはヌルにされ、クライアント装置のメモリ空間を解放する。ゴースティングは、装置上で自動的に行われる。どのオブジェクトをゴースティングするかは、以下の「ゴースティング規則」により判定され、オブジェクトが作成又は更新される度に、この規則を適用する。規則は、セレクションのオブジェクトの最大数を規定する。その最大数を超過すると、ソート順の末尾にあるセレクションのオブジェクトがゴースティングされる。
【０１５５】
例えば、クラスがmessagesであり、セレクションは、受信箱の複数のメッセージであり、ソート順は、日付／時間によるものであり、且つ、最大数が５０であるとする。受信箱に５０個のメッセージがあり、新規メッセージが到着する場合、受信箱の１番古いメッセージが、ゴースティングされる。ゴースティングにおいて、メッセージ本分を除去し、メッセージを認識するための十分なヘッダ情報を残してもよい。
【０１５６】
回収（以前には、自動削除且つ除去として知られる）は、ゴースティングに類似するが、オブジェクトの一部ではなく、オブジェクト全体を除去することにより動作する。
【０１５７】
ゴースティング及び回収の双方とも、コグニマサーバに通知されない。これらは、クライアント装置に特定のものである。従って、異なる装置は異なる数のオブジェクトを有してもよい。この状態においても、装置上のデータは、基本的に同期がとられているが、装置はそれぞれ、異なるデータ部分集合を保持する。
【０１５８】
ユーザがゴーストを復活させることを望む場合、オブジェクトを復活させる要求は、クライアントからコグニマサーバに送信される。オブジェクトの復元は、装置へ送信され、オブジェクトは、通常な状態に戻される。
【０１５９】
個々のオブジェクトは、固定することができる。固定されたオブジェクトは、ゴースティングも除去も行われない。固定は、ユーザにより選択されるか、又は自動的に発生させることができる。例えば、復活したオブジェクトは、自動的に固定される。
【０１６０】
８．  ユーザ複製−オブジェクトの共有
ユーザにとって、オブジェクトを共有するために有用だと考えられるアプリケーションは、多数ある。オブジェクトを共有する一般的な方法は、次に示すものである：ユーザは、オブジェクトを共有したいと考えるユーザのCognimaアドレスを知る必要がある。コグニマサーバ構成における詳細なアドレスの検索について説明することが、より適切である。ここで、そのようなリストが入手可能であると仮定する。
【０１６１】
１つ以上のCognimaアドレスの集合が、共有されるべきオブジェクトに添付される。そのオブジェクトは、読み取り専用（オブジェクトの共有者は、それを変更できない）に設定される。コグニマサーバは、ウェブ又はクライアント装置から、新規オブジェクトを受信（又はオブジェクトに対する更新を受信）すると、それを通常通り複製する。
【０１６２】
また、サーバは、「共有者」のCognimaアドレスのリストを検索する。オブジェクトに発信者ＩＤ（すなわち、オブジェクト所有者のCognimaアドレス＋オブジェクトＩＤ）を記録し、それを共有者に送信する。共有ユーザは、同一のコグニマサーバに存在してもよいし、異なるコグニマサーバに存在してもよい。共有者のコグニマサーバは、そのオブジェクトを受信する。それが新規オブジェクトである場合、新規のオブジェクトＩＤ（発信者ＩＤの記録を保持する）を割り当てる。更新である場合、発信者ＩＤを使用して、オブジェクトを検索する。共有者がオブジェクトの更新を許可されている場合、その更新は、複製され、発信者ＩＤを使用してオブジェクト所有者に戻される。
【０１６３】
９．  データの表示
ＰＤＡのような従来の小型装置は、アプリケーションが実行されていない時に、アプリケーションが、データを保持する何らかの記憶装置においてデータを読み書きできる単純なファイルシステムを有することが多い。一般に、これらのプログラムは、使用可能なデータの集合を読み込み、画面上にそのデータを表示するためのユーザインタフェースを提供する。これには、以下の欠点がある：
・プログラムが開始する時に、データを読み込むのに時間がかかる。
・アプリケーションは、全て又は一部のデータをメモリに格納する必要があり、クライアント装置において、より多くのメモリを占有していることを意味する。
・２つ以上のアプリケーションが同一のデータ集合にアクセスできるようにすることは、問題となる。
・データを読み操作するための類似するコードが、装置上で実行される複数のアプリケーションに発生する。
【０１６４】
コグニマの方法は異なる：
・複数のアプリケーションによりアクセス可能なオブジェクトデータベースに、データが格納される。
・コグニマアプリケーションは、処理する全てのデータをデータベースから読み込まない。その代わり、「セレクション」、すなわち、現在関心のあるデータの部分集合を作成する。一般に、このセレクションは、装置の画面に現在表示されているデータと一致する。従って、アプリケーションにより現在使用されているデータのみが、メモリに保持される−多くのメモリ空間が節約される。
・データの格納、ソート及び索引付けの全ての作業は、オブジェクトデータベースにより実行されるため、この機能を、各アプリケーションで繰り返す必要がない。
・アプリケーションのデータに対する変更が必要な場合、アプリケーションが、データの表示を直接更新することはない。変更は、オブジェクトのプロパティを更新するか、あるいは、オブジェクトを作成又は削除する。他のアプリケーションにより、又は、他の装置で変更されたデータのためにコグニマサーバから受信した更新により、データが変更される。
・アプリケーションは、セレクションをセットアップすると、データがそのセレクションに含まれるか又は除外されるかの条件のリストを提供する−従って、コグニマ複製エンジンは、オブジェクトが作成、削除又は更新された時間を通知するのがどのアプリケーションであるかを識別できる。
・更新がアプリケーションに送信される必要がある場合、このデータを含むセレクションに関連するアプリケーションのコードが呼び出され、この方法で、アプリケーションは、行われた変更に対して応答できる。
・セレクションがセットアップされると、アプリケーションは、データの格納方法を特定し、且つ格納されたデータのリストに小型ウィンドウのみが必要（ビューとして知られる）であるかを特定できる。
【０１６５】
この方法は、ウィンドウシステムのグラフィック画面に再描画するために使用される画面リペイント方法に類似する。画面のある領域がリペイントを必要とする場合、その画面の領域を制御するアプリケーションは、画面をリペイントするために呼び出される。
【０１６６】
９．１  例
クライアント装置は、装置上で実行されるコンタクトアプリケーションを有してもよい。この装置は、コンタクトアプリケーションを実行する他のクライアント装置に接続するコグニマサーバを使用して、データを複製する。オブジェクトのクラスは、名前及び電話番号を含むContactに対して定義され、これらは、あるユーザの全ての装置に複製される。
【０１６７】
ある装置のアプリケーションが、頭文字により全ての連絡先を示す画面を有してもよい−例えば、インタフェースにより、ユーザは、Ｄボタンを押下し、Ｄで始まる全ての名前を表示できる。このアプリケーションは、以下のオブジェクトを含むセレクションをセットアップする：
・クラスがContactsとして定義される
・名前が選択された文字（例えば、Ｄ）で始まる
セレクションが定義されると、アプリケーションは、オブジェクトが追加、削除又は更新される時に、ＣＲＥにより呼び出されるコードも定義する。
【０１６８】
セレクションが最初にセットアップされると、そのコードは、上述の条件を満たす第１のオブジェクトの集合と共に呼び戻される。
【０１６９】
アプリケーションは、Ｄで始まる名前の新規連絡先を作成するように要求されると、オブジェクトの作成のみを実行する。ＣＲＥは、新規オブジェクトを検出し、新規オブジェクトのセレクションコードを通知するためにセレクションコードを呼び戻す。
【０１７０】
同様に、新規Contactオブジェクトが他の装置に作成され、クライアント装置に複製された。そのContactの名前がＤで始まる場合、アプリケーションは、通知される。
【０１７１】
９．２  ソート
一般に、セレクション中のデータは、ソートされる必要がある−それは、多くの場合、表示された時に、ユーザが論理的形式のデータを参照できるようにするためである。セレクションが定義されると、ソート順、すなわち、ソートすべきプロパティ、ソートされる順番及び使用されるソートアルゴリズムが特定される。
【０１７２】
９．３  ビュー
セレクション中にデータの多くの項目があってもよい。一般に、データが表示されている時、データは、画面上に全て収まらず、ユーザはデータを上下にスクロールする必要があることもある。ビューは、セレクションが処理したいデータの項目数、及びアプリケーションがセレクション中に表示させたいデータの完全なリストの範囲外にあるデータの第１の項目の数を特定することにより、この機能を提供する。
【０１７３】
ビューにより、アプリケーションが、ローカルに格納するデータ量を、画面上に表示させる必要のある量に制限することができるため、ビューは重要であり、これにより、データの不必要な重複を減少させることができる。
【０１７４】
９．４  効率性
コグニマは、コグニマサーバとクライアントアプリケーションとの間のデータの転送方法において、効率的な最適化を実行する−複数のデータが変更される場合、データはブロックで送信され、アプリケーションは、変更が完了したことが報告されるため、アプリケーションのユーザインタフェースを１度更新すればよい。
【０１７５】
９．５  例
例として、ContactSelectionと呼ばれるセレクションを定義する。これは、フレームワークが、選択されたオブジェクトに対して変更が行われる度に呼び戻すコードである。コグニマフレームワークにおいて、これは、COdbSelectテンプレートクラスから導き出したオブジェクトとして実装される−テンプレートの引数として、セレクション中に保持したいオブジェクトの型を特定する。
class CContactSelect: public COdbSelect＜CContact＞
{
public:
CContactSelect(COdb *aOdb);
void ObjectAdded(CContact *aObject);
void ObjectUpdated(CContact *aObject);
void ObjectRemoved(const TOdbObjectId aObjectId);
private:
bool ListContactsO;
};
メソッドObjectAdded()、ObjectUpdated()及びObjectRemoved()は、それぞれ、オブジェクトが追加される時、更新される時、除去される時にフレームワークにより呼び出される。Selectionクラスを実装する時、これらの事象において、インスタンス化を実行したくない場合は、これら全てのメソッドを実装する必要はない−ある場合においては、あるオブジェクトの集合のリストを保持するためにセレクションをセットアップするが、他の事象においては、リストをチェックするのみでよいため、上述のメソッドは必要ない。
【０１７６】
ListContacts()と呼ばれる別のPrivateメソッドを定義した−これは、セレクションにより保持される現在の全ての連絡先をリスト化する。
【０１７７】
以下は、このクラスの実装である：
CContactSelect::CContactSelect(COdb *aOdb)
:COdbSelect＜CContact＞(aOdb)
{
}
void CContactSelect::ObjectAdded(CTestContact *aContact)
{
OdbLog(OdbLogApp,L"New contact added:" ＜＜aContact-＞GetName());
ListContacts();
}
void CContactSelect::ObjectUpdated(CTestContact *aContact)
{
OdbLog(OdbLogApp,L"Contact updated:" ＜＜aContact-＞GetName());
ListContacts();
}
void CContactSelect::ObjectRemoved(const TOdbObjectId aObjectId)
{
OdbLog(OdbLogApp,L"Contact deleted - Id:" ＜＜aObjectId);
ListContacts();
}
void CContactSelect::ListContacts()
{
OdbLog(OdbLogApp,L"Contacts list:");
for (unsigned long Index=0; Index＜iResult.size(); Index++)
{
CTestContact*Contact=iResult[Index];
OdbLog(OdbLogApp,Contact-＞GetName() ＜＜","
＜＜Contact-＞GetPhone() ＜＜","
＜＜Contact-＞GetEmail());
}
}
コンストラクタは、単純にデフォルトのCOdbSelectコンストラクタを呼び出す。ObjectAdded()、ObjectUpdated()及びObjectRemoved()メソッドは、行われた変更の内容を出力し、リストの現在の内容を示すために、ListContacts()を呼び出す。
【０１７８】
ListContacts()は、セレクションにより保持されるオブジェクトの現在のリストへのアクセス方法を示す。オブジェクトに対するポインタの現在のリストは、iResultと呼ばれるコンテナクラスに保持される−これは、通常のコンテナクラスインテグレータによりアクセスされる。この場合、単純にリストを参照し、リストにある全てのオブジェクトを出力する。
【図面の簡単な説明】
【０１７９】
添付の図面を参照して本発明を説明する。図面に、データの複製を制御するために使用されるパラメータが時間と共に変動する様子のグラフを示す。
【図１】
2006511134.tif 000013
【図２】
2006511134.tif 000014
【図３】
2006511134.tif 000015
【手続補正書】
【提出日】平成17年8月10日(2005.8.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
無線ネットワークを介して相互に接続する移動装置とサーバとの間で、データオブジェクトを自動的に複製し、前記ネットワークを介するデータ複製のタイミングは、ネットワークオペレータがネットワークの帯域幅を有効的に使用するためのパラメータを適用して判定を行う方法であって：
（i）変更ログは、少なくとも装置及びサーバにおいて複製されるべき全てのオブジェクトをリスト化し、前記パラメータは、前記オブジェクトの複製の緊急度を規定する各オブジェクトに関連付けられた重みを含み；且つ
（ii）前記パラメータは、時間に対する閾値を更に含み、各オブジェクトの前記重みは、ある時間における前記閾値とローカルで比較され、その比較結果により、前記オブジェクトがその時点で、複製されるために送信されるか否かが判定される方法において；
オブジェクトの複製の緊急度に関連する全ての条件は、前記オブジェクトに関連付けられた単一の重みにより表現されることを特徴とする方法。
【請求項２】
任意のオブジェクトの前記重みが、ある時点において前記閾値を超過する場合、接続は、その時点で確立することを特徴とする請求項１記載の方法。
【請求項３】
ある時点におけるオブジェクトの重みが：
（ａ）データ複製の方向（装置からサーバ、又はサーバから装置)
（ｂ）前記オブジェクトが、変更ログに存在し、自動的に削除された場合のその後のある時間又は期間を規定する保存期間
（ｃ）前記オブジェクトが上書き可能か否か
（ｄ）バイト単位でのサイズ
（ｅ）変更ログに入力された時間
（ｆ）優先順位
（ｇ）タイムアウト間隔
（ｈ）複製に割り当てられた時間
（ｉ）あるオブジェクトに対するデフォルト値でない優先順位のユーザ割り当て
（ｊ）利用可能なメモリ
のうちの１つ以上に依存することを特徴とする請求項１記載の方法。
【請求項４】
前記ネットワークオペレータが、オブジェクトの前記重みを随時変更できることを特徴とする請求項１記載の方法。
【請求項５】
前記ネットワークオペレータが、前記閾値を随時変更できることを特徴とする請求項１記載の方法。
【請求項６】
前記閾値は、利用可能な帯域幅を有効的に使用する方法において、時間と共に変動することを特徴とする請求項１記載の方法。
【請求項７】
前記閾値は、エンドユーザの異なるグループ、個々のエンドユーザ又はアプリケーションに対する異なる方法において、時間と共に変動することを特徴とする請求項１記載の方法。
【請求項８】
前記閾値の動的変動は、セル又はネットワークの負荷の変化に従って発生することを特徴とする請求項１記載の方法。
【請求項９】
前記閾値の動的変動は、新規データ複製サービスの取り込みを促進するために発生することを特徴とする請求項１記載の方法。
【請求項１０】
前記閾値は：
（ａ）現在の時間
（ｂ）装置のローミングの状態
（ｃ）セル又はネットワークの負荷
（ｄ）前回の複製からの時間
（ｅ）ユーザの料金
のうちの１つ以上の状況に従って、変動可能であることを特徴とする請求項１記載の方法。
【請求項１１】
前記重みがある時間において前記閾値を超過するオブジェクトが１つも存在しない場合、任意のオブジェクトの前記重みが前記閾値を超過する前に経過する時間間隔を計算し、タイマを前記時間間隔に対して設定することを特徴とする請求項１記載の方法。
【請求項１２】
前記時間間隔は：
（ａ）新規オブジェクトが変更ログに追加される
（ｂ）新規閾値が展開される
（ｃ）前記タイマが無効となる
（ｄ）セル又はネットワークの負荷が変化する
（ｅ）装置のメモリが所定の基準を下回る
（ｆ）前記装置がローミングの状態の変化を検出する
（ｇ）新規アプリケーションが装置上で起動される
（ｈ）ネットワーク接続が終了する
場合に、再計算される請求項１１記載の方法。
【請求項１３】
前記装置の前記エンドユーザは、特定のオブジェクト又はオブジェクトの型に関して、デフォルトの複製タイミングを無効にできることを特徴とする請求項１記載の方法。
【請求項１４】
複製されるべきオブジェクトは、時間の複製が発生すべきである時間制限を割り当てられることを特徴とする請求項１記載の方法。
【請求項１５】
前記時間制限は動的であることを特徴とする請求項１４記載の方法。
【請求項１６】
前記装置のメモリが変化する場合、又は前記装置が新規ネットワークにローミングする場合、前記時間制限は変更されることを特徴とする請求項１４記載の方法。
【請求項１７】
複製されるべきオブジェクトは、ある時間又は期間を規定する保存期間が割り当てられ、前記保存期間の後、前記オブジェクトは、複製されていない場合に、自動的に削除されることを特徴とする請求項１記載の方法。
【請求項１８】
個々のパラメータにより、前記ネットワークオペレータは、各々が異なる料金に対応付けられた、異なるレベルのデータ複製サービスを、エンドユーザに提供することができることを特徴とする請求項１記載の方法。
【請求項１９】
接続開始オブジェクトが複製されると、変更ログにある更に別のオブジェクト及び保留状態の複製が送信されることを特徴とする請求項１記載の方法。
【請求項２０】
機会主義閾値機能は、送信される更に別のオブジェクトを判定することを特徴とする請求項１９記載の方法。
【請求項２１】
前記機会主義閾値は、装置がローミングネットワーク上にある場合に変化することを特徴とする請求項２０記載の方法。
【請求項２２】
前記機会主義閾値は、装置が配置されるセルの負荷の閾値を超過するか否かに従って変化することを特徴とする請求項２１記載の方法。
【請求項２３】
前記機会主義閾値は、ネットワークを介して通信する前記閾値に対する変化に伴い、装置及びサーバにより常に適用されることを特徴とする請求項２１記載の方法。
【請求項２４】
前記ネットワークオペレータは、前記機会主義閾値を変動させることができることを特徴とする請求項２１記載の方法。
【請求項２５】
複製の実際の時間は、移動装置の状態、ネットワークの状態及びパラメータに依存することを特徴とする請求項１記載の方法。
【請求項２６】
請求項１記載の方法を使用してサーバに対するデータ複製を可能にするソフトウェアでプログラムされたことを特徴とする移動装置。
【請求項２７】
請求項１記載の方法を使用して移動装置に対するデータ複製を可能にするソフトウェアでプログラムされたことを特徴とするサーバ。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
今日まで、（単純な一方向プッシュ更新システムとは対照的な）データ複製システムの設計者は、ネットワークの帯域幅を有効利用することについて考慮していなかった。殆どのデータ複製システムが、帯域幅への影響を考慮することなく、即時に複製を行う必要があるという仮定に基づいていたので、この問題は発生した。
PCT/CA01/00486を参照してもよい。これは、メッセージサーバから移動装置、及び移動装置からメッセージサーバにメッセージをプッシュするシステムを開示する。メッセージが送信される時期を判定するために、異なる条件が展開される；（例えば、最大のメッセージサイズ、到達する最大時間、メッセージの特定の型、転送先アドレス、内容識別子、時間等）。あるメッセージが伝送されるべきか否かを評価することは、各条件に関連して実行されるべき特定のアルゴリズムを要求し、解決されるべき複雑な優先順位は、衝突する可能性がある。移動装置上で評価される場合、不可避の電力の制約の下、課題は、消費電力（例えば、タスクを完了するために必要なプロセッササイクル）を最小限にすることである。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【０００６】
［本発明の概要］
第１の態様において、無線ネットワークを介して相互に接続する移動装置とサーバとの間で、データオブジェクトを自動的に複製し、前記ネットワークを介するデータ複製のタイミングは、ネットワークオペレータがネットワークの帯域幅を有効的に使用するためのパラメータを適用して判定を行う方法であって：
（i)変更ログは、少なくとも装置及びサーバにおいて複製されるべき全てのオブジェクトをリスト化し、前記パラメータは、前記オブジェクトの複製の緊急度を規定する各オブジェクトに関連付けられた重みを含み；且つ
（ii）前記パラメータは、時間に対する閾値を更に含み、各オブジェクトの前記重みは、ある時間における前記閾値とローカルで比較され、その比較結果により、前記オブジェクトがその時点で、複製されるために送信されるか否かが判定される方法において；
オブジェクトの複製の緊急度に関連する全ての条件は、前記オブジェクトに関連付けられた単一の重みにより表現されることを特徴とする方法が提供される。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
この「重み」及び閾値の組合せは、データ複製のタイミングに関して融通性のある制御を行い、帯域幅を最適に使用する。従来技術の方法は、メッセージが送信されるか否かを判定するために、多くの異なる条件を使用する（例えば、最大のメッセージサイズ、到達する最大時間、メッセージの特定の型、転送先アドレス、内容識別子、時間等）。上述のように、あるメッセージが伝送されるべきか否かを評価することは、各条件に関連して実行されるべき特定のアルゴリズムを要求とし、解決されるべき複雑な優先順位は、衝突する可能性がある。しかし、本発明において、異なる条件は、個別に評価されず、「weight」（重み）と呼ばれる抽象エンティティが使用される；「weight」は、任意の全ての条件をモデル化できる。評価は、単に単一の「weight」の値の閾値に対する比較の問題であるため、より高速で効率的である；単一の重みの条件のみが閾値を変動させる時間と比較されるため、相当な速度と効率が得られる。不可避の電力の制約の下、移動装置上で評価される場合、速度及び効率は、極めて貴重な属性である。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】削除
【補正の内容】
【国際調査報告】
2006511134.tif 000016
2006511134.tif 000017