(57)【要約】  第１のコンピュータ装置が、第２のコンピュータ装置で稼働するクロックを用いて第２のコンピュータ装置によってタイムスタンプを押されたデータが複製されたか否かを判定し、第１のコンピュータ装置は、第２のコンピュータ装置からのタイムスタンプを自身のローカルクロックからの時間信号と比較して差分を判定し、その差分を使用して第２のコンピュータ装置からの後のデータと関連付けられたタイムスタンプに適用するための正しい差分を導き出す。【特許請求の範囲】
【請求項１】
各々がローカルクロックを使用する複数のコンピュータ装置における第１のコンピュータ装置が、第２のコンピュータ装置で稼働するクロックを用いて前記第２のコンピュータ装置によってタイムスタンプを押されたデータが複製されたか否かを判定する複数のコンピュータ装置間でデータを複製する方法であって、
前記第１のコンピュータ装置は、前記第２のコンピュータ装置からのタイムスタンプを自身のローカルクロックからの時間信号と比較して差分を判定し、前記差分を使用して前記第２のコンピュータ装置からの後のデータと関連付けられたタイムスタンプに適用するための正しい差分を導き出すことを特徴とする方法。
【請求項２】
前記第１のコンピュータ装置の前記ローカルクロックは、絶対的な対外的に生成された時間に設定されることを特徴とする請求項１記載の方法。
【請求項３】
前記第１のコンピュータ装置によって導き出される前記差分は、前記第２のコンピュータ装置の前記ローカルクロックが線形に変動していることを前提とすることを特徴とする請求項１記載の方法。
【請求項４】
時間枠の変更を吸収するための故意の時間調整が前記第２のコンピュータ装置上の前記ローカルクロックに対して行なわれると、前記第２のコンピュータ装置はこの時間調整の記録を格納し、前記第１のコンピュータ装置へと提供することを特徴とする請求項１記載の方法。
【請求項５】
前記第２のコンピュータ装置は、格納される１つ以上のタイムスタンプが新規の時間枠においても正しいままであるように前記故意の時間調整の量だけ前記タイムスタンプを変更することを特徴とする請求項４記載の方法。
【請求項６】
前記第１のコンピュータ装置は、時間依存仲裁規則を正しく適用して幾つかの矛盾するデータ複製要求のうちのどれを実行すべきかを判定するために、自身のクロックに関連する正しい差分の知識を使用することを特徴とする請求項１記載の方法。
【請求項７】
前記第２のコンピュータ装置により適用される前記タイムスタンプは、複製されるべきデータを含むデータベースレコードの一部ではないことを特徴とする請求項１記載の方法。
【請求項８】
前記タイムスタンプは、データに対する変更を識別するのに必要な最小限のデータのみを含む変更ログに存在することを特徴とする請求項７記載の方法。
【請求項９】
データを複製することができ、第２のコンピュータ装置によってタイムスタンプを押されたデータが前記第２の装置上で稼動するクロックを使用して複製されたか否かを判定するコンピュータ装置において、
前記第２のコンピュータ装置からのタイムスタンプを自身のローカルクロックからの時間信号と比較して差分を判定し、前記差分を使用して前記第２のコンピュータ装置からの後のデータと関連付けられたタイムスタンプに適用するために正しい差分を導き出すことを特徴とする装置。
【請求項１０】
サーバであり、前記第２のコンピュータ装置は前記サーバのクライアントとして動作することを特徴とする請求項９記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、各々がローカルクロックを使用するコンピュータ装置間でデータを複製する方法に関する。
【背景技術】
【０００２】
コンピュータ装置間でのデータ複製は、同一人物によって使用される異なるコンピュータ装置間で文書、電子メール、連絡先、及びカレンダーへの記入を同期させる際などの多様な状況において行われる。データ複製を正しく行うためには、２つ以上の矛盾するデータ複製要求のうちの何れに従うべきかを決定する何らかのシステムが必要である。例えば、時点１において、ユーザが携帯電話上で人物Ｘの電子メールの詳細に対する変更を入力するとする。しばらくして、時点２において、ユーザはその変更に誤りがあったことに気づく。人物Ｘの電子メール詳細に更なる変更を加え、同じことをＰＣ上でも実施する。時点３において、ユーザはＰＣをマスタサーバに同期させて、人物Ｘの電子メールのマスタレコードを正しいアドレスへと更新する。しかし、更に時間が経過してから、時点４において、携帯電話をマスタサーバに同期させるとする。この場合、人物Ｘの正しい電子メール詳細（時点２で入力）を時点１で最初に入力した不正確な詳細で上書きする可能性がある。
【０００３】
この問題に対処するために、同期化システムは、通常、最後に記録された変更（上述の例では時点１ではなく時点２）を優先するなどの時間ベースの仲裁規則を使用する。これは、装置上でデータがいつ変更されたのかを示すために、タイムスタンプをそのデータと関連付けることをその装置に要求する。この処理は通常、ある特定の種類のデータを格納するコンピュータ装置上でデータベース（例えば、個人の全ての連絡先詳細−名前、電子メール、電話、携帯電話などであり、これらで単一の連絡先レコードを形成する−に対するデータベース。通常、電子メール、カレンダーへの記入などに対してはそれぞれ別のデータベースが存在する）を提供することにより、有線ベースの装置に対して行われる（無線ネットワークを介して通信する装置とは対照的に）。レコードの何らかのデータが変更されると（例えば、ある個人の新規の電子メールアドレス）、装置はその変更をレコードの一部として記録し、装置上でローカルに稼動する水晶時計により設定される時間でタイムスタンプを押す（レコードの一部を形成するエントリとして）。データの変更（例えば、その個人に対する新規の電子メール連絡先詳細）は中央サーバへと送られる。完全な置換レコードが、通常、送信される（例えば、個人に対する全ての既存の連絡先詳細＋新規の電子メールアドレス＋タイムスタンプ）−中央サーバは、情報のマスタコピーを更新し、全ての装置が同じ情報を維持するように各装置に更新情報を送信する。中央サーバは、通常、タイムスタンプを使用して仲裁規則を適用し、競合／矛盾する同期化要求間の競合を解消する。
【０００４】
従って、従来のデータ複製システムは、データベースレコードに適用されるタイムスタンプに依存する。タイムスタンプは、変更されたデータが最初に入力された装置上で稼動するローカルクロックにより作成される。この装置は、クライアント装置であっても、サーバであっても、あるいは、ピアであっても良い。同じデータに対する変更を受け入れることができる装置（各々ローカルクロックを所有）が何台かある場合、タイムスタンプが押されたデータベースレコードを使用して時間ベースの仲裁規則を適用するように１台の装置が指名される。問題は、タイムスタンプを適用するこれらのローカルクロックが稀にしか相互に同期しないことである。この原因は、（ａ）水晶時計の時間が変動すること、（ｂ）ユーザが若干の時間調整（例えば、装置のクロックが５分進んで動くように）を故意に入力できること、及び（ｃ）ユーザが±ｎ時間の故意の時間調整（例えば、時間帯の変更／サマータイム）を入力できることにある。結果として、通常の仲裁規則により正しく扱うことができない競合／矛盾する同期化要求が生成されることになる可能性がある。
【０００５】
これを解消する１つの手法としては、全ての装置が外部の正確なクロック−例えば、ＧＭＴ（又は適用可能な現地時間）を提供するウェブベースのクロック−に定期的に接続し、これを用いてそれぞれのクロックをリセットすることが必要である。しかし、多くのユーザはこの手法に対して消極的である。更に、複製対象のデータを中央のアービトレータへと提供する全ての装置が、実際に、相互に同期する保証はない。
【０００６】
［発明の概要］
本発明の第１の態様によると、各々がローカルクロックを使用する複数のコンピュータ装置における第１のコンピュータ装置が、第２のコンピュータ装置で稼働するクロックを用いて前記第２のコンピュータ装置によってタイムスタンプを押されたデータが複製されたか否かを判定する複数のコンピュータ装置間でデータを複製する方法であって、
前記第１のコンピュータ装置は、前記第２のコンピュータ装置からのタイムスタンプを自身のローカルクロックからの時間信号と比較して差分を判定し、前記差分を使用して前記第２のコンピュータ装置からの後のデータと関連付けられたタイムスタンプに適用するための正しい差分を導き出すことを特徴とする方法が提供される。
【０００７】
このようにして、第１のコンピュータ装置は、時間依存仲裁規則を正しく適用して幾つかの矛盾するデータ複製要求（例えば、何台かの第２のコンピュータ装置、第１のコンピュータ装置及び第２のコンピュータ装置から）のうちのどれを実行すべきかを判定するために、内部のクロックに関連する正しい差分の知識を使用する。ローカルクロック変動は十分に補償することができる。
【０００８】
この手法は、第２のコンピュータ装置により後のデータに適用されるタイムスタンプが生成された時に受信されず、相当後になって受信される場合に有用である。このため、第１のコンピュータ装置は自身のクロックからの信号とタイムスタンプを直接比較することができない。この状況は、実際には頻繁に発生するであろう。特に、第２のコンピュータ装置が携帯無線装置（例えば、携帯電話）であり、帯域幅の有効利用のために複製対象の全てのデータをまとめる場合に、低コストの夜間料金を使用するため、あるいは、単に変更が最初に入力されたときに有効範囲外である場合に発生するであろう。
【０００９】
１つの実施例において、第１のコンピュータ装置の内部クロックは、ＧＭＴなどの絶対的な外部から得られる時間に設定される。他の付加的な特徴としては、第１のコンピュータ装置により導き出される差分は、第２のコンピュータ装置のローカルクロックが予測可能なように、例えば直線的に変動していることを前提とする。
【００１０】
更に、時間枠の変更（例えば、新規の時間帯／サマータイム）を吸収するための故意の時間調整が第２のコンピュータ装置上のローカルクロックに対して行なわれる場合、第２のコンピュータ装置はこの時間調整の記録を格納し、第１のコンピュータ装置へと提供することができる。第１のコンピュータ装置は、故意の時間調整を補償し、第２のコンピュータ装置から送信されたタイムスタンプを自身の内部クロックへと正しく関連付けることができる。これにより、第１のコンピュータ装置は、接続され且つタイムスタンプが押されたデータ複製要求を供給する全ての装置に対して整合性をもって時間ベースの仲裁規則を適用することができる。また、第２のコンピュータ装置は、格納される１つ以上のタイムスタンプが、新規の時間枠においても正しいままであるように、故意の時間調整の量だけタイムスタンプを変更することができる。
【００１１】
第２の態様において、データを複製することができ、第２のコンピュータ装置によってタイムスタンプを押されたデータが前記第２の装置上で稼動するクロックを使用して複製されたか否かを判定するコンピュータ装置において、
前記第２のコンピュータ装置からのタイムスタンプを自身のローカルクロックからの時間信号と比較して差分を判定し、前記差分を使用して前記第２のコンピュータ装置からの後のデータと関連付けられたタイムスタンプに適用するために正しい差分を導き出すことを特徴とする装置が提供される。
【００１２】
以下の詳細な説明の第６．２節では、実施例を詳細に説明する。
【発明を実施するための最良の形態】
【００１３】
本発明は、Cognima Limited of London, United Kingdomによる実施例を参照して説明する。コグニマ（Cognima）では、消費者によるデータサービスの利用を増加させ、大切な顧客の固定客化を促進し、競合他社から自社のサービスを差別化するために、モバイルサービスプロバイダ（ＭＳＰ）及びネットワークオペレータの必要性に直接対処するデータ複製技術を開発してきた。
【００１４】
コグニマのデータ複製ソリューションは、これらの問題に対して以下の手法により対処する：
・注目度の高い、容易に利用可能なものにすることにより、データサービスの利用を増加すること
・加入者の個人データを担当のＭＳＰにより制御されたサーバ上で確実にバックアップすることにより、乱れ（churn）の防止を強化すること
・顧客の経験を制御することによってＭＳＰが差別化されたサービスを作り出せるようにすること。
【００１５】
１．コグニマデータ複製フレームワークの用途の概説
コグニマのデータ複製フレームワークにより、モバイルサービスプロバイダは消費者市場に対して注目度の高いサービスを設立することができる。ＭＳＰは、データセンタにおけるコグニマサーバのホストとして機能する。サーバは、規格ベースのＪ２ＥＥアプリケーションサーバ及びキャリア級のＵｎｉｘ（登録商標）ハードウェア上で動作するオラクルデータベース及びコグニマのマルチスレッドＪａｖａ（登録商標）通信サーバから構成される。第４節以降では、技術的な実現を詳細に説明する。
【００１６】
コグニマフレームワークは、携帯電話に入力されたデータを自動的に（ユーザの介入なしに）コグニマサーバを介して他の電話機へと複製する。同様に、コグニマサーバに接続された外部システムからのデータは、携帯電話上で自動的に最新の状態に維持される。
【００１７】
コグニマ対応アプリケーションを使用するモバイル加入者は、「個人情報」及び「複数の友人」に対する「常時利用可能な」、「即時」接続を経験する。
・「個人情報」は、加入者の住所録、メッセージ、銀行口座取引明細、株価、ピザ注文、カレンダー、職場への通勤経路の現在の交通状況、又はその他の個人化されたコンテンツを含むことができる。データは常にコグニマサーバ上で確実にバックアップされ、全ての関連するクライアント装置上で自動的に複製される
・「常時利用可能な」は、現在ネットワークに接続されているか否かに関わらず、加入者が携帯する何れの装置又はハンドセット上でも個人情報をアクセス可能であることを意味する。ユーザは、装置上にローカルに格納された個人情報を常にアクセスすることができるからである。また、ユーザはウェブインタフェース−Virtual Phone−を介してサーバ上で直接個人情報を編集・管理することができる
・「即時」は、加入者がサーバからのデータのダウンロードを待つ必要がないことを意味する。最新の情報は、加入者がその必要性を認識していなくても既にそのハンドセット上にある。データが自動的にハンドセットへと送信されるからである（例えば、ハンドセットによるポーリングが行われるであろう。このポーリングは、例えば３０分ごと又は所定の時刻（午後４時、午後５時など）に定期的に行うことができる。ハンドセットに対するプッシングも起こり得る）
・加入者は複数の装置に渡って彼らの「複数の友人」とデータを共有することができる。コグニマサーバはこのデータを任意の定義済の装置又は定義済の個人へと複製することができるからである。
【００１８】
１．１  コグニマアプリケーションの例
2005510796.tif 000002
２．モバイル加入者にとっての利点
コグニマは、以下の重要な利点に基づいて量販市場の消費者データサービスを実現するための理想的なフレームワークを提供する：
・「親しみやすさ」：ユーザの介入は不要である。加入者は自身のデータをアクセスするのに「同期」又は「ダウンロード」ボタンを押下する必要がない。システム構成及び確実なデータ転送は、エンドユーザからは完全に見えない
・「即時可用性」：ユーザは常に、ローカルデータとは即時に相互に作用することができる（オフライン時であっても）。一方で、更新はバックグラウンドでひそかに行われる。例えば、ユーザは地下鉄でも個人化されたコンテンツを読むことができる。ユーザ行為（user experience）はデータ転送から切り離されている
・「値ごろ感」：ＭＳＰは複製をいつ実行するかを制御でき、もたらされるサービス品質（ＱｏＳ）を制御できる。しかし、ユーザ行為はデータ転送から切り離されているので、低いＱｏＳでもユーザのサービスに対する認識には影響しない。このため、ＭＳＰはユーザ行為を犠牲にすることなく、比較的低いＱｏＳで低コストな加入ベースのサービスを提供することができる。例えば、銀行口座取引明細などの緊急でないデータサービスに関しては、データ複製を夜間に行うことも可能であり、この場合でもユーザは不満を感じない。夜間のデータ複製では、十分に利用されていない帯域幅を使用するため、ピーク時のデータ複製に比べて格段に費用が安い。緊急のデータ複製（例えば、プレゼンス情報）は、定期的に又は（オプションとして）継続的に（プッシュで）随時行うことができ、請求料金をより高額なものにすることができる。更に、電話機のメモリ及びプロセッサ能力の有効利用により、コグニマクライアントソフトウェアは、安価な量販市場の電話機においても、経済的にインストールすることができる。
【００１９】
３．モバイルサービスプロバイダにとっての利点
コグニマは、新規のデータ収入を生み出し、乱れを減少させ、自社のサービスを競合他社のサービスから差別化する手段を提示する。
【００２０】
３．１  既存のモバイルサービスの利用度の向上
コグニマは、既存のモバイルサービスの利用度を向上する：
・メッセージングサービス及びコンテンツベースのサービスは、ますます便利になると共に即時性が高まり、両サービスの利用度が向上することになる
・プレゼンス情報の即時性が向上するため、チャット、インスタントメッセージング及び音声通話の空き容量があることを示すアラートの利用が増加することになる
・複数の装置を容易に管理することができるので、ユーザはいかなる場合でも適切な電話機を携帯することができ、通話やメッセージ送信が増加する。
【００２１】
３．２  注目度の高い新規のサービス
コグニマは、注目度が高くお手頃な新規のモバイルデータサービスの急速な導入を可能にする。
・コグニマは、余剰のネットワーク容量のみを使用し、ローエンドの電話機における新規のサービスに対する注目度の高いユーザ行為をもたらす。これは、ネットワークオペレータにとって入手可能であると共にスケーラブルであり、ＭＳＰは量販市場の加入者に対して理解可能且つ予測可能な値段設定を提供することができる
・新規のコグニマサービスに対するアプリケーション開発の大半は、サーバ側で行われるため、ＭＳＰは新規のサービスを市場に迅速にもたらすことができる
・コグニマのクライアントソフトウェアは、フラッシュメモリのアップグレードとしてインストールすることができ、今日の量販市場のハンドセットに多機能電話並みの機能を付与する。新規のソフトウェアアプリケーションは、無線により既存のコグニマ対応ハンドセットへとダウンロードすることができるので、ＭＳＰは新規のデータサービスをそのサービスに対応した新規の装置を待たずとも展開することができる
・サードパーティのアプリケーション開発者は、ＭＳＰのコグニマインフラストラクチャを活用して、ＭＳＰのネットワークに対する新規のアプリケーションを開発することができる。
【００２２】
３．３  乱れ削減
コグニマは、乱れを防止する重大な障壁となる。例えば、個人情報をＭＳＰのコグニマサーバに確実に格納する加入者は、新しい電話機を購入し、全ての個人情報を即時に新規の装置へと取得することができる。異なるサービスプロバイダに加入することにした場合、この個人情報は全て失われることになるだろう。
【００２３】
３．４  差別化
現在加入者は、全てのネットワーク上でモバイルデータサービスを使用するという同じ基本的な経験を有する。例えば、ＷＡＰサービスを使用する経験は、ＷＡＰプロトコル、電話機中のブラウザ、及びアクセスされるコンテンツにより定義される。多くのＭＳＰは、独自のユーザ行為を加入者に与えることで自身の差別化を図らなければならないことを認識している。しかし、モバイルハンドセットにおいてサービスをカスタマイズすることに対する厳しい制約が、その差別化の障害となっている。
【００２４】
コグニマにより、ＭＳＰはハンドセット上でサービスを実現し、加入者のユーザ行為の制御を取り戻すことができるようになる。最も重要なことは、コグニマは相互運用性を犠牲にすることなく、これを実現するということであり、コグニマサーバとの簡単な統合を介して業界標準への対応も達成される。最終的には、価値連関表におけるＭＳＰの地位は、ハンドセットメーカー及びコンテンツプロバイダの強力なブランドに対して強化される。
【００２５】
４．コグニマデータ複製フレームワークの機能設計
４．１  概論
詳細な説明の本節以降の各節では、コグニマデータ複製システムが実際にどのように機能するかを説明することを意図する。この説明には、クライアント装置、コグニマサーバ、及びウェブクライアントの挙動が含まれるが、特定のハードウェア、プログラミング言語、ソフトウェアクラス設計、又は環境の詳細については触れない。使用される基本的なデータ構造及びアルゴリズムについては説明する。
【００２６】
用語
2005510796.tif 000003
４．２  目的
コグニマソフトウェアの目的は以下の通りである：
・ユーザ即時アクセスにより、無線データ接続が可能な複数のハンドヘルド装置上でデータの「最新の」コピーを表示・修正できるようにする
・ユーザが従来のウェブブラウザを使用して同じデータを表示・修正できるようにする
・ユーザのデータの確実なバックアップを簡単に実現できるようにする
・複雑で費用のかかる処理をサーバに転嫁することによって、安価なハンドセット上で強力なデータ機能をユーザに対して提供する。
【００２７】
４．３  最高レベルの説明
クライアント装置は、クライアント装置上のデータベースにユーザのデータのコピーを保持する。ネットワーク接続の有無に関わらずこのデータにアクセスすることができるので、ユーザは常に即時アクセス権を有することになる。ユーザが装置上でデータを変更すると、変更は変更−ログへとコピーされる。クライアント装置は、定期的に無線ネットワーク上のコグニマサーバへと接続し、変更−ログから変更を送信し、新規のデータを受信する。これにより、データを変更する操作においてネットワークへと接続する必要はなくなる（すなわち、プッシュは好適な実施例では連続的ではない）。コグニマサーバは、クライアント装置から受信したデータ変更でデータベースを更新し、ユーザが所有する全ての装置の変更−ログにデータ変更を反映させる。これらの装置が次に接続するときには、変更を受信し、同じデータのコピーを伴って同期状態に維持されるであろう。
【００２８】
コグニマサーバはウェブサーバを含む。このウェブサーバにより、ユーザはコグニマサーバのデータベースに保持されるデータのコピーを直接調べることができ、クライアント装置上で行うように変更を加えることができる。また、コグニマサーバは、ユーザがネットワーク／インターネット上の他のサーバと通信するためのゲートウェイとしても機能する。例えば、クライアント装置はメッセージオブジェクトに少数のフラグを設定することによって、ＳＭＳ、電子メール、又はファックスとしてメッセージを送信するようにコグニマサーバに事実上要求することができ、コグニマサーバは電子メールサーバ、ＳＭＳサーバ、及びファックス装置と通信を行う機能を含む。これは、呼出し音、バンキング明細、ゲームなどを保持するサーバへと拡大することができる。クライアント装置上にソフトウェアを構築するよりも、コグニマサーバ上にソフトウェアを構築して他のサーバに問い合わせる方がより簡単で安価である。
【００２９】
５．より低いレベルの概念
５．１  データ構造
５．１．１  ＩＤ
コグニマユーザデータは、オブジェクトデータベースの専門用語：クラス及びオブジェクトを用いて記述される。同様の名称を有する○○プログラミング概念と混同される可能性があるので、注意が必要である。
【００３０】
コグニマネットワークの全てのユーザには「ユーザＩＤ」が割り当てられる。このＩＤは、コグニマネットワーク特有のものであり、ネットワークオペレータにより提供される。全てのユーザは、ユーザＩＤとコグニマサーバのＵＲＬとの組み合わせである「コグニマアドレス」を有する。これは世界でただ１つのものである。ユーザに所属する各装置には「装置ＩＤ」が割り当てられる。この装置ＩＤはユーザ特有のものである。このＩＤは８ビットであるので、ユーザは最大２５３台の装置を持つことができる（ＩＤ２５４はウェブのために予約されており、ＩＤ２５５は予備であり、ＩＤ０は無効である）。全てのユーザデータは、クラス（連絡先クラス、メッセージクラス、銀行取引クラスなど）に分類され、各クラスには世界でただ１つのクラスＩＤが割り当てられる。例えば、クラスＩＤ「１２」は連絡先のことを指す。
【００３１】
クラスのインスタンスはオブジェクトであり、オブジェクトにはユーザ特有の「オブジェクトＩＤ」が割り当てられる。例えば、ある連絡先クラスオブジェクトは、「John Smith」の連絡先であるだろう。オブジェクトＩＤは、オブジェクトを作成した装置の装置ＩＤを装置の寿命を超えて増加する単調増加のカウントと結びつけることにより生成される。各装置は最大１６，７７７，２１５個のオブジェクトを作成することができる（この制限値に到達した場合には装置ＩＤをリセットすることができるだろう）。クラスはそれを構成するプロパティにより定義される。クラスは本質的にプロパティの配列である。クラスの各プロパティはプロパティＩＤを持ち、このＩＤはクラス特有のものである（実際は、０から始まるプロパティ配列におけるプロパティの配列位置）。
【００３２】
５．１．２  オブジェクト作成
オブジェクトは装置上で作成される。このオブジェクトにはオブジェクトＩＤが割り当てられ、装置データベースに保存される。コピーも変更−ログへと保存される。装置が次にコグニマサーバへと接続すると、変更−ログのエントリが送信される。コグニマサーバはオブジェクトをデータベースに保存し（システム時間を記録）、必要とされるクラス特有の処理（例えば、電子メールの生成・送信）を行い、ユーザが所有すると共にクラスへの関わりを宣言したその他の装置の変更−ログにエントリを追加する。（このエントリは、装置上のクラスの正しいバージョンに対するものでなければならない）。
【００３３】
オブジェクトはウェブポータル上に作成されても良い。オブジェクトＩＤが生成され（上述のように装置ＩＤ２５４を使用して）、装置と同様に処理される。ウェブポータルに対しては変更−ログはなく、コグニマサーバのデータベースから直接に選択内容を取得する。
【００３４】
また、オブジェクトはサーバアプリケーションにより作成されても良い（例えば、メッセージングモジュールは電子メールを受信し、この電子メールよりメッセージオブジェクトを作成する）。オブジェクトＩＤは、（上述のように装置ＩＤ２５４を使用して）生成され、装置と同様に処理される。
【００３５】
５．１．３  オブジェクトの更新
既存のオブジェクトの１つ以上のプロパティが装置上で修正される。変更は装置データベースへと保存される。変更された各プロパティは装置変更−ログにおいてエントリを生成するのに使用される。これらは、コグニマサーバへと送信される。
【００３６】
更新時間がコグニマサーバのデータベースのプロパティに対する「最終変更」時間より後である場合、コグニマサーバは変更をデータベースに保存し（プロパティに対する新規の「最終変更」時間を記録）、所要のクラス特有の処理を行う。更に、コグニマサーバは、ユーザに所属し、クラスを宣言すると共に、プロパティを含むクラスのバージョンを有するその他の装置の変更−ログにエントリを追加する。更新は、変更が最初に行われた装置の変更−ログに対しても行われる。奇妙に思えるかもしれないが、これは以下のシナリオに対処するのに必要である：
ユーザは２台の装置Ａ及びＢを持っている。ユーザは、午後５時にＡにおいてオフラインでプロパティ７を更新し、午後６時にＢにおいてオフラインでプロパティを更新する。まず、Ａを用いてネットワークへと接続する。Ａ上の値７は、Ｂに送信されるべく変更−ログに反映される。その後、Ｂを用いて接続する。値７はより最近のものであるため、Ｂ上の値７がＡへと送信される。しかし、ＢはＡの値を入手する。値７をＢに複製し直すことによりこれが確定される。
【００３７】
削除済としてマーク付けされたオブジェクトに対して更新がコグニマサーバにより受信され、更新が削除よりも後に行われている場合、復旧と解釈される。オブジェクトは復旧され、更新され、オブジェクトのリフレッシュが全ての適切な装置の変更−ログ上で行われる。ウェブポータル又はサーバアプリケーションからの更新も同様に機能する。
【００３８】
５．１．４  オブジェクトの削除
オブジェクトが装置上で削除される。装置データベースから削除され、クラスＩＤ及びオブジェクトＩＤを列挙する変更−ログ上にエントリが設けられる。エントリはコグニマサーバへと送信される。
【００３９】
削除時間がオブジェクトの最終更新時間より後である場合、コグニマサーバはデータベースにおいてそのオブジェクトに削除済としてマーク付けし、クラス特有の処理を行い、ユーザに所属すると共にクラスを宣言したその他の装置にエントリを追加する。
【００４０】
削除時間が最終更新時間より前の場合、削除が無効であることを示す。オブジェクトのリフレッシュが、削除が最初に行われた装置の変更−ログに対して行われる。
【００４１】
削除されたオブジェクトは、削除状態が明らかになるようにウェブポータルで見ることができる。ユーザは復旧のためにオブジェクトを選択することができる。削除マークがコグニマサーバのデータベース中のオブジェクトから削除され、オブジェクトをリフレッシュするためのエントリが、ユーザに所属すると共にクラスを宣言した全ての装置の変更−ログ上に設けられる。
【００４２】
５．１．５  プロパティ型
各プロパティには型がある。現在、９個の許容されたプロパティ型がある：
2005510796.tif 000004
「CogString」は文字カウントであり、文字が後続する。文字列がASCIIの場合、文字列が占める空間は（4 + 文字カウント）バイトとなる。文字列がユニコードの場合、占める空間は（4 + (文字カウント * 2)）バイトとなる。
【００４３】
「CogTypedString」は、型（４バイト符号なし整数）が先行する「CogString」である。現時点では型付き文字列の唯一の用途は接点である。型は接点の型（例えば、電子メールアドレス、自宅の電話）を識別し、文字列はアドレスを保持する（例えば、bob@xxx.yyy、01233556677）。
【００４４】
「CogBlob」はバイト長であり、バイト数が後続する。任意のバイナリデータを格納するのに使用することができる。
【００４５】
「CogArray」は、４バイト符号なし整数「型」として渡され、２個のブロブが後続する。「型」は配列に保持される要素の型を示す。第１のブロブはインデックスブロブであり、第２のブロブへのオフセットのシーケンス（４バイト符号なし整数）を保持する。第２のブロブはデータブロブであり、バイナリランプのシーケンスとして配列の要素を保持する。各要素は、インデックスブロブに沿ってカウントし、データブロブ中の要素の開始のオフセットを取得することによってデータブロブから抽出することができる。これが、渡されるときの「CogArray」のストリーム構造である。特定のシステムの内部では、従来のベクタ（すなわち、解析済）のように見えるかもしれない。
【００４６】
「CogArray」の唯一の実施例は、「MessageAddress」である。「MessageAddress」の各要素は「AddressPair」である。「AddressPair」は連絡先ＩＤ（連絡先オブジェクトのオブジェクトＩＤ）であり、接点が後続する。
【００４７】
５．１．６  スマートプロパティパラメータ
プロパティの一部は「スマート」にすることができる。これは、装置の特徴に対するプロパティにデータを刻むために、一部のプロパティを特定の装置に対してパラメータ化できることを意味する。実際、パラメータは２つの４バイト符号なし整数である。一方はスマート型であり、他方は最大サイズである。例えば、メッセージの本文テキストを保持するプロパティは、メモリ容量の限られた安価な電話機では、スマート型kCogPlainTextで最大サイズ１００にパラメータ化されるかもしれないが、メモリ容量の多いＰＤＡ上では、スマート型kCogRichTextで最大サイズ１，０００にパラメータ化されるかもしれない。
【００４８】
パラメータは、アプリケーションが装置に追加されるときにコグニマサーバにより格納される。新規のオブジェクト又はそのクラスに対する更新が、その装置に対するコグニマサーバ変更−ログに反映されると、スマートパラメータに従って処理される。これは、例えば、テキストを切り詰めたり、ユニコードテキストをバイト数の少ないテキストへと変換したり、あるいは、画像形式を変換したりすることを含むであろう。
【００４９】
データ保全の点では、コグニマサーバのデータベースで保持されるオブジェクトが生成されたときのオブジェクトのコピーであることが重要である。縮小バージョンを装置上で見る場合でも、コグニマサーバ上では完全バージョンを効果的に操作することができる。
【００５０】
５．１．７  クラスバージョン
４バイト符号なし整数により定義されるクラスバージョンの概念がある。新規のクラスバージョンは古いクラスの終わりにプロパティを追加しても良いが、既存のプロパティを変更／削除したり、既存のプロパティ間に新規のプロパティを挿入したりしてはならない。バージョン間の相互運用性が可能でなければならない。異なるスマートプロパティパラメータを有するクラス定義は異なるバージョンではない。
【００５１】
５．２  ユーザデータ渡し
コグニマは、クラスメタデータの考えを利用してデータベース間でコピーして渡される必要のあるデータを最小限にする。クラスメタデータは、本質的にプロパティメタデータの配列である。プロパティメタデータは、プロパティＩＤ、プロパティ型、スマート型、及び最大サイズである。
【００５２】
ユーザデータは、クラスＩＤ以外のフォーマッティング情報を伴わないストリームとして転送される。このストリームは、クラスメタデータを参照することによって解析される。このため、ストリームがクラス６に対して受信され、クラス６に対するクラスメタデータが、プロパティ０がKcogTypeUIntであり、プロパティ１がKcogTypeStrであると示す場合、ストリームの最初の４バイトは符号なし整数として、次の４バイトは後続する文字列の文字数を保持する符号なし整数として、次のｎ（ユニコードの場合は２倍）バイトは文字列中の文字を保持するものとして解釈すべきであることが分かる。
【００５３】
クライアント装置は、コグニマサーバに対してサポートするクラスを宣言する。これにより、装置は生のユーザデータ（クラスＩＤ、オブジェクトＩＤ、及び少数のその他の項目を含むヘッダを伴う）のみを送信し、所要帯域幅を最小限にすることができる。これは、例えば、格段に広い帯域幅を必要とするＸＭＬ依存システムと対照させることができる。
【００５４】
コグニマサーバが装置に対するデータを刻むことができるように、クライアント装置のクラス宣言はスマートプロパティパラメータを含む。プロパティの意味がアプリケーションへとハードコードされることを強調しておいても良いだろう。クラスメタデータは、クラス７におけるプロパティ２は最大長が３０文字の文字列であることを記述する。これは、クラス７におけるプロパティ２をフットボールチームの名称として解釈するアプリケーション中のコードである。
【００５５】
５．２．１  データ複製の問題の詳細
データは、クライアント装置及びこれらの装置が接続されるサーバ（コグニマサーバとして既知）上で作成されるオブジェクトにおいて保持される。これらのオブジェクト及びこれに加えられる変更は、クライアント装置とコグニマサーバとの間で複製される。
複製プロセスの設計により以下のことが可能になる：
・コグニマサーバ及びあるユーザに対してサーバにログオンされる全てのクライアント装置上で保持されるように複製されることになる１組のオブジェクトが定義される。任意の装置又はサーバ上で作成される新規のオブジェクトは、他の全ての装置へと複製されることになる。オブジェクトの何れかのプロパティにおける変更は、全ての装置へと複製される
・データにおける変更のみがクライアントからコグニマサーバへ、あるいは、その逆に送信されるため、ある更新に対して最小限のデータのみがネットワークを介して送信される
・設計の重要な部分は、クライアント装置上でオブジェクトの各プロパティに対して修正時間が維持される必要がないことである。制限されたクライアント装置上で修正時間を更新するのには時間がかかり、オブジェクト中の各プロパティに対する最終修正時間を維持するのには広い空間を必要とする
・コグニマサーバは十分な記憶空間を有し、対処するだけの処理能力を有するため、コグニマサーバ上で、オブジェクトの全てのプロパティに対する修正時間を格納しても問題はない
５．２．２  メタデータ
システムが機能するためには、あるクラスのオブジェクトに対してどのプロパティが定義されるのかに関して明確に理解する必要がある。これは、クラスメタデータの定義を可能にする数少ないＣ＋＋コンパイラマクロをプログラマに提供することにより行われる。
【００５６】
クラスにおいて使用されるプロパティの定義は、結果としてクラスメタデータ定義となる。この定義により、ＣＲＥ（コグニマ認識エンジン）はプロパティがどの型であるかを認識し、データリンクを介して送受信するためにオブジェクト又はプロパティを圧縮／復元できるようになる。ＣＲＥシステムが機能するためには、全てのクライアント及びサーバは同じクラスメタデータ定義を有する必要がある。従って、以下の状況が発生する：
・新規のメタデータ定義がクライアント装置上で宣言されると、コグニマサーバへと送信される。コグニマサーバは他の全てのクライアントに対してそのメタデータ定義を送信する
・新規のメタデータ定義がコグニマサーバ上で宣言されると、定義は全てのクライアント装置へと送信される
・新規のクライアント装置が初めてコグニマサーバへとログオンすると、何れかのオブジェクトが送信される前に全てのメタデータ定義がその装置へと送信される
・上記の場合の全てにおいて、コグニマサーバが、メタデータが指し示すクラス（及び特定のプロパティ）をアクセスするクライアントだけにメタデータ定義を送信するように今後は最適化されるであろう
５．２．３  変更ログ
変更ログの目的は、クライアント装置がコグニマサーバに（又はコグニマサーバがクライアント装置に）最後に接続した時以降に発生した変更を記録することである。コグニマＡＰＩを使用して、アプリケーションはＣＲＥへと接続し、オブジェクトを作成／削除したり、オブジェクト中のプロパティを変更したりする。これらの変更は、変更が行われたときに変更が行われた時間と共にローカル装置上の変更−ログへと追加される。常に識別することができるように、オブジェクトにはその作成時に固有の識別子が与えられる。
【００５７】
同様に、コグニマサーバ上で稼動するアプリケーションによるオブジェクトの作成・削除及びオブジェクトプロパティへの変更により、結果として、コグニマサーバ上でそのユーザに対して登録された全てのクライアント装置の全ての変更−ログへと変更が追加されることになる。変更時間は、オブジェクトごと又はプロパティごとに記録される。
【００５８】
変更ログは以下の２通りの方法で作成することができる：
・新規のオブジェクトが作成され、プロパティが変更されたとき（これはクライアント装置においてはよくあることである）
・あるいは、オブジェクト及びプロパティの最終修正時間がシステム上に格納される場合、これらを使用することによって必要に応じて新規のオブジェクトを作成することができる（状況によっては、この方法は上述の方法ではなく、コグニマサーバ上で使用されることもある）
５．２．４  複製
クライアント装置が送信すべき項目を変更ログに有している場合、コグニマサーバへと接続することになる（コグニマサーバがクライアント装置へと接続する場合も同様）。デフォルトでは、変更ログの各項目は変更ログに追加された順序で送信される。しかし、特別なサービス及び緊急のデータなどの準備の際には、送信の直前に再度優先順位付けされても良い。転送される項目は以下の通りである：
・あるクラスのオブジェクトの各プロパティの型を含むメタデータ定義
・作成された新規のオブジェクト−そのオブジェクトのプロパティの内容を伴う
・プロパティが変更された−そのプロパティの新規の値を伴う
・オブジェクトが削除された
上述の何れの場合にも、関係するオブジェクト、クラス、及びプロパティを識別するために適切なＩＤが送信される。全ての変更ログ項目は、変更ログに追加された時間でマーク付けされる。この時間は、常に、ローカルマシン時間であり、第６．２節で説明される時間管理手法によりＧＭＴへと変換される。
【００５９】
クライアント装置がコグニマサーバから変更ログ項目を受信する場合：
・コグニマサーバから新規のオブジェクトメッセージを受信する場合、クライアント装置はこの新規のオブジェクトをローカルデータベースに追加する
・コグニマサーバからオブジェクト削除メッセージを受信する場合、クライアント装置はローカルデータベースにおいてこのオブジェクトに削除済としてマーク付けする
・クライアント装置がプロパティ変更を受信する場合、常に、コグニマサーバがデータベースの現在の状態に関して信頼できるものと想定されるので、変更はローカルデータベースに保持されるプロパティの値に行われる
コグニマサーバはクライアント装置から変更ログ項目を受信する：
・コグニマサーバがクライアント装置から新規のオブジェクトを受信する場合、オブジェクトはコグニマサーバのデータベースに追加され、最初に新規のオブジェクトを送信したマシンの変更−ログを除いてそのユーザに対して登録されたクライアント装置の全ての変更−ログにも追加される
・コグニマサーバがクライアント装置からオブジェクト削除を受信する場合、オブジェクトは削除のためにマーク付けされ、オブジェクト削除メッセージが、最初にオブジェクト削除を送信したマシンの変更−ログを除いてそのユーザに対して登録された装置の全ての変更−ログに追加される
・プロパティ変更を受信する場合、コグニマサーバは変更の時間をコグニマサーバ上でそのプロパティに対して保持される現在時間と比較する。プロパティ変更の時間がコグニマサーバ上で保持される時間より後の場合、サーバデータベースにおいてプロパティ値が変更され、この変更はそのユーザに対して登録されたクライアント装置の全ての変更−ログ−プロパティ変更において送信されるマシンのものを含む−にも追加される（別のオブジェクト更新がその間マシンに送信される場合）。プロパティ変更がコグニマサーバ上で保持されるものより前の場合、格納されたプロパティ値の方がより最近のものであるので変更は行われない。しかし、ユーザが必要に応じて後で取得できるように値はコグニマサーバ上の古いプロパティ値のリストに追加される。時間同士が比較されるときには、第６．２節にて後述する時間管理手法が使用される。
【００６０】
装置が最初にコグニマサーバへと接続する場合、全てのクラスメタデータ定義及びそのユーザに対するデータベース中の全てのオブジェクトが送信されることになる。一般的に、削除メッセージは削除のためにオブジェクトにマーク付けするだけである。オブジェクトのデータベースからの実際の削除は、そのオブジェクトを参照する全てのオブジェクトが削除された後で行われるであろう。
【００６１】
５．２．５  最適化
上述の複製プロトコルの最適化バージョンは、変更ログ中のエントリの集約を考慮に入れている。変更ログ（コグニマサーバ中又はクライアント装置上）がまだ複製されていない場合、後続のエントリが追加される。既存のエントリを走査することにより、次の接続中に複製される必要のあるエントリ数を場合によっては削減することができる：
・新規のエントリが、更新が予定されているプロパティに対する更新である場合、後のエントリのみが保持されれば良い
・新規のエントリがオブジェクト削除である場合、そのオブジェクトに対する全てのプロパティ更新を変更ログから削除することができる
・新規のエントリが「復旧」コマンドであり、元の削除がまだ変更ログ内にある場合、２つのエントリは共に変更ログから削除することができる。
【００６２】
６．コアアルゴリズム
６．１  エンディアンネスの処理
オペレーティングシステムは、基本的にリトルエンディアン及びビッグエンディアンのうちの何れかである。これは、数字及び文字が格納されるバイトの並び順の選択である。異なるエンディアンネスを有する２台のコンピュータが通信を行う必要がある場合、片方のコンピュータはデータパケットのエンディアンネスを切替えなければならないだろう。コグニマ環境では、コグニマクライアントソフトウェアはホストクライアント装置と同じエンディアンネスを使用する。コグニマサーバはクライアント装置のエンディアンネスを判定し（クライアントからのデータの最初のパケットに含まれる参照値を使用）、コグニマサーバにおいて一貫したエンディアンネスを維持する必要がある場合に後続の受信データを変換しなければならない。また、コグニマサーバはクライアント装置に送り返す送信データを変換しなければならない。
【００６３】
６．２  システム時間の同期化
異なる装置は必然的に多少異なるシステム時間を有することになる。クライアント装置からコグニマサーバへと送信される変更は、変更時の装置のシステム時間でスタンプされる。変更が発生した順序を判断し、正しい更新を記録することができるように異なる装置上で時間を変換することはコグニマサーバの役目である。
【００６４】
装置のログオンは現在の装置の時間を含む。コグニマサーバはネットワークの待ち時間を補償し、ログイン時間をそれ自体のシステム時間と比較することができなければならない。これにより、装置の時間とコグニマサーバの時間との間に差分が生じることになる。この差分はそのセッションにおいて装置により送信される更なる時間に適用することができる。
【００６５】
コグニマサーバは、連続セッションにおける装置からの差分同士を比較し、装置上のクロック「クリープ」又は時間帯の変更を判定することができる。システム内の全てのクライアント装置が相互に十分に同期のとれたクロックを有することは以下に示すように想定しがたい：
・装置のクロック精度によってクロック時間は装置上で変動する
・ユーザの中には、例えば、５分早くクロックを設定することを好む人もいる
・ユーザの中には、ローカル設定を調整するよりはサマータイムのためにクロックを変更する人もいる（また、ＯＳの中にはローカル特性を提供せず、ユーザがクロックを直接変更することを強制するものもあるかもしれない）
この問題を克服するために、サーバは、サーバ上で比較が行われる場合にクライアント装置により使用される時間をＧＭＴへと調整し、メッセージがコグニマサーバからクライアント装置へと送信される場合にＧＭＴからクライアント装置に対する同等の時間へと調整する役目を負うであろう。
【００６６】
クライアント装置は、変更ログ中の全ての項目にローカルクロックから取得された時間でタグ付けすることになる。クライアント装置に関する限りでは、クライアント装置自体のクロックに基づいて時間を扱う。
【００６７】
コグニマサーバへと接続するたびに、クライアント装置はそれ自体のクロックにより得られた現在時間のビューを送信する。これにより、サーバは以下のことを導き出すことができる：
・ＧＭＴに対する差分
・前回ログオンして以降モバイル装置のクロックに変動があった場合、サーバはＧＭＴに対する最終差分及び最後の接続の時間を記録し、これらを比較することができる。変動がある場合、サーバはモバイル装置に応じて（pro-rata）送信される全ての時間を調整することができる。
【００６８】
例えば、以下の表に、コグニマサーバへと接続するクライアント装置におけるイベントのパターンを示す。クライアント装置の時間はコグニマサーバより５分遅く、毎時１分遅れている（要点を示すために極端な場合を挙げる）。更に要点を示すために、０９：００から１２：００までユーザは機上でコグニマサーバと接触がなく、この間クライアント装置は接続していないものとする：
2005510796.tif 000005
プロパティ変更がコグニマサーバ上に格納された時間の前後に行われたか否かを導き出すために、時間Ｘ及びＹを計算する必要がある。上述の情報から、コグニマサーバには、クライアントが前回接続したのは約３時間前であり、その時点では時間差は５分であったが、現在は８分になっていることが分かっている。クロック変動が直線的に発生するものと想定すると、コグニマサーバは、装置がＧＭＴより５分遅れており、クロックは毎時１分遅れることを算出することができる。
【００６９】
これにより、クライアント装置がプロパティＡの変更に対して１０：００として認識する時間は、初期変動として５分を加える必要があり、プロパティが変更されるまでの時間に発生した追加の変動のために更に１分加える必要がある。
【００７０】
同様に、プロパティＢは１１：０７に調整される必要がある−５分の初期変動に加えて、プロパティが変更されたとき０９：００から１１：００まで２時間経過しているために更に２分必要である。
【００７１】
実際には、クライアント装置の時間とＧＭＴとの間の時間に対する差分は数分であるが、変動は１時間あたり数分の１秒のオーダーとなるであろう。
【００７２】
６．２．１  時間調整
ＧＭＴに対する差分及びクライアント装置のクロックと同様に、ユーザはクライアント装置上の時間を変更することができる。ユーザは、時間を正しい現地時間にリセットするためにこの変更を行うかもしれない（ユーザは自動的にこの変更を行うオプションを選択することもできるが、ユーザの中にはクライアント装置の時間を自分で制御したい−例えば、クロックを５分早く設定したいと思う人もいるかもしれない）。また、現地時間（すなわち、サマータイム又は時間帯の変更）の変更を反映させるために変更を行うかもしれない。目的は、ユーザが自身に即した任意の時間に装置上のクロックを変更することができ、装置はただこれを考慮するだけであるように構成することである。
【００７３】
ユーザがクライアント装置の時間に対して変更を行う場合、大半のオペレーティングシステムはこの変更を報告する（これを行わないシステムにおいては、このような変更をチェックするために、例えば、毎分時間をポーリングすることができる）。時間の変更を検出すると、クライアント装置は新しい時間と変更前の時間との間の差分を算出するであろう。例えば、ユーザが時間帯を移動したときにはプラス１時間の変更となるかもしれない。クライアント装置は、この時間差を調整時間として格納する。この調整時間は、コグニマサーバへの次回の接続時のために保存される。また、クライアント装置は、変更ログの全ての項目に目を通し、調整時間によりログ中の全ての時間を更新する。これにより、変更ログ中の各エントリをクライアント装置上の現地時間と常に関連させておくことができる。
【００７４】
このような調整は、コグニマサーバへの接続間でも行うことができるだろう−ログ中の各時間は全てクライアント装置上の現地時間に関連するように、毎回、時間変更の量が調整時間を用いてまとめられ、変更ログが更新される。
【００７５】
クライアント装置が次にコグニマサーバへと接続するときには、格納された調整時間−すなわち、前回の接続以降クライアント装置のクロックが進められた又は遅らせられた量−をログオン時に送信する。コグニマサーバは、ＧＭＴに対する差分及び変動計算により時間からこの量を差し引くことができる。
【００７６】
６．２．２  クライアント装置に対するＧＭＴ
コグニマサーバ上で行われた変更のＧＭＴ時間をあるクライアント装置にとって正しい現地時間に変更するべく、同じ一連の計算を逆に行うことができる。
【００７７】
６．３  アプリケーションの追加
アプリケーションは１つ以上のクラスを使用してユーザデータを保持するであろう。クラスの定義はアプリケーションへとハードコードされる。クラスのバージョンは、アプリケーションのリリースにより調整される。
【００７８】
統計アプリケーションがフットボール選手クラスを使用してフットボール選手に関するデータを保持するものとする。アプリケーションがクライアント装置上で最初に起動されるとき、どのバージョンのフットボール選手クラスを既に保持しているかを装置に問い合わせる。装置上のバージョンが、アプリケーションが使用すべくハードコードされたバージョンと同じである場合、それ以上何も行わなくて良い。
【００７９】
装置が、フットボール選手クラスの新しいバージョンを保持する場合、アプリケーションは予想よりも多くのプロパティに対処できるよう十分頑強でなければならない（複数のアプリケーションにより使用されるクラスを有していて、何らかの理由でアプリケーションのうちの１つの古いバージョンをインストールした場合にこの状況が発生するであろう。これは稀なケースであり、理想的には相互依存するアプリケーションは共にアップグレードすべきである。）。
【００８０】
装置がフットボール選手クラスの古いバージョンを保持する（又は全くバージョンを保持しない）場合、アプリケーションの有するフットボール選手クラスのバージョンをそれと置き換えるべきである。新しいバージョンはコグニマサーバへと送信される。コグニマサーバは全ての装置上で使用されるクラスの各バージョンのリストを維持する。
【００８１】
ウェブポータルのページは、ハードコードされた装置のアプリケーションと同等であろう。ウェブはクラスの最新バージョンに従ってデータベースからオブジェクトを抽出することができ、予想してハードコードされたよりも多くのプロパティがある場合は無視することができる。従って、ウェブはクラスバージョンを宣言する必要がない。
【００８２】
６．４  変更−ログの最適化
コグニマサーバは、装置が次に接続するときに送信されることになる変更を列挙する全ての装置に対する変更−ログを維持する。例えば、変更−ログに対して行うことができる最適化には以下に示すようなものがあるだろう：
・同じプロパティに対する３つ以上の更新が変更−ログにキューイングされている場合、最後の更新のみを維持すれば良い
・あるオブジェクトに対して削除がキューイングされている場合、キューの前方にある更新は全て削除されても良い
・あるオブジェクトに対して更新がキューイングされている場合、キューの前方にある削除は削除されるべきである
・装置が新規のアプリケーションを登録する場合、そのアプリケーションに対して送信すべきオブジェクト（例えば、メッセージ履歴）が非常に多くなる可能性がある。変更−ログは、追加対象として妥当な数のオブジェクト（例えば、最新の２０通のメッセージ）のみを持つべきである
７．ゴースト化、復活（resurrection）、ピン止め（pinning）、及び撤回（withdrawal）
クライアント装置上で利用可能なユーザデータを保持する空間は、通常、サーバ上で利用可能な空間よりも数桁小さい。装置は、データのサブセットを保持する必要があり、ユーザはこのサブセットを維持するだけで良い。ゴースト化及び撤回はこれを支援するためのツールである。
【００８３】
クラス定義は、ある特定のプロパティに「ゴースト化可能」としてフラグを立てることを含んでも良い。これは、オブジェクトがゴースト化される場合、プロパティがゼロになり、クライアント装置上の空間が解放されることを意味する。ゴースト化は装置上で自動的に行われる。どのオブジェクトをゴースト化すべきかの決定は、「ゴースト化規則」に従い、オブジェクトが作成又は更新されるたびに規則を適用することによって行われる。規則は、オブジェクトのセレクションの最大数を定義する。最大値を超える場合、ソート順の末尾にあるセレクション中のオブジェクトはゴースト化される。
【００８４】
例えば、クラスはメッセージであり、セレクションは受信ボックス内のメッセージであり、ソート順は日時であり、最大数は５０であるかもしれない。受信ボックスに５０通のメッセージがある状態で新規のメッセージが到着した場合、受信ボックス中の最も古いメッセージがゴースト化される。ゴースト化では、メッセージ本体を削除した場合でもメッセージを認識するのに十分なヘッダ情報を残しておいて良い。
【００８５】
撤回（従来は自動削除及び削除としても既知）は、ゴースト化に類似しているが、オブジェクトの一部ではなく全体を削除することによって機能する。
【００８６】
ゴースト化も撤回もコグニマサーバには通知されない。これらの操作はクライアント装置特有のものである。異なる装置は異なる個数のオブジェクトを有しても良い。装置上のデータは基本的に同期がとれているが、各装置は異なるデータ部分集合を保持する。
【００８７】
ユーザがゴーストの復活を希望する場合、オブジェクトが復活するようにクライアントからコグニマサーバへと要求が渡される。オブジェクトのリフレッシュが装置へと送信され、オブジェクトは正常に戻る。
【００８８】
個々のオブジェクトはピン止めすることができる。ピン止めされたオブジェクトは、ゴースト化されたり削除されたりすることはない。ピン止めはユーザが選択することも、自動的に行うこともできる。例えば、復活したオブジェクトは自動的にピン止めされる。
【００８９】
８．ユーザ複製−オブジェクトの共有
ユーザがオブジェクトを共有するのに役立つと思われるアプリケーションは数多く存在する。これが有効に機能すると思われる一般的な場合は、ユーザがオブジェクトを共有したいユーザのコグニマアドレスを知る必要がある場合である。これらのアドレスの取得については、コグニマサーバアーキテクチャにおいて詳細に検討することがより適切である。ここでは、このようなリストが利用可能であると想定する。
【００９０】
１つ以上のコグニマアドレスの集合が共有対象のオブジェクトに添付される。オブジェクトは読出し専用に設定することができる（共有相手が修正できないように）。ウェブ又はクライアント装置から新規のオブジェクトを受信する（あるいは、オブジェクトに対する更新を受信する）と、コグニマサーバは通常通りそれを複製する。
【００９１】
また、コグニマサーバは「共有者」のコグニマアドレスのリストを参照する。オブジェクトに発信者のＩＤ（すなわち、オブジェクト所有者のコグニマアドレス＋オブジェクトＩＤ）でマーク付けし、共有者へと送信する。共有ユーザは同じコグニマサーバ上又は異なるコグニマサーバ上に存在する。共有者のコグニマサーバがオブジェクトを受信する。新規のオブジェクトの場合には新規のオブジェクトＩＤを割り当てる（発信者ＩＤを記録）。更新の場合には発信者ＩＤを使用しているオブジェクトを探し出す。共有者がオブジェクトを更新する許可を受けている場合、発信者ＩＤを使用して更新を逆にオブジェクト所有者へと複製することができる。
【００９２】
９．データの表示
ＰＤＡなどの従来の小型装置は単純なファイリングシステムを有する傾向にある。これらのシステムによりアプリケーションは、稼動中でないときにデータを保持する何らかの記憶装置においてデータを読み書きすることができる。一般的に、このようなプログラムは利用可能なデータの集合を読み込み、データを画面に表示するためのユーザインタフェースを提供する。これには幾つかの欠点がある：
・プログラムが起動するときのデータの読み込みに時間がかかる
・アプリケーションはデータの全部又は一部をメモリに格納する必要がある（つまり、クライアント装置上ではより多くのメモリを占めている）
・２つ以上のアプリケーションが同じデータの集合をアクセスできるようにすることは問題となる
・データを読んだり操作したりするための類似のコードが装置上で稼動する幾つかのアプリケーションで出現する
コグニマ手法はこれとは異なる：
・データは幾つかのアプリケーションによるアクセスが可能なオブジェクトデータベースに格納される
・コグニマアプリケーションは、データベースから扱う全てのデータを読み込まない。その代わりに、セレクション−現在関心のあるデータの部分集合−を作成する。一般的に、このセレクションは装置の画面上に現在表示されているデータと一致する。このため、アプリケーションが現在使用中のデータのみがメモリに保持される−メモリ空間を大いに節約することになる
・データの格納作業、ソーティング作業、及び索引付け作業の全てはオブジェクトデータベースにより行われるので、この機能を各アプリケーションにおいて繰り返す必要がない
・アプリケーションにおいてデータに変更を加える必要がある場合、アプリケーションはデータの表示画面を直接更新しない。変更は、オブジェクト中のプロパティを更新するか、あるいは、オブジェクトを作成又は削除することになる。データの変更は、別のアプリケーションにより、あるいは、別のマシン上でデータが変更されたためにコグニマサーバから受信された更新により行うことができるだろう
・アプリケーションがセレクションを設定するときには、データがセレクションに含まれるか、あるいは、除外されるかを決める基準のリストが与えられる−これにより、コグニマ複製エンジンはオブジェクトが作成、削除、又は更新されたときにどのアプリケーションに通知すべきかが分かる
・更新をアプリケーションへと送信する必要がある場合、このデータを含むセレクションへとリンクされたアプリケーション中のコードが呼び出され、こうして、アプリケーションは行われた変更に応えることができる
・セレクションが設定されるとき、アプリケーションはデータのソート方法と必要なのはデータのソート済リスト上の小型のウィンドウのみであるか（ビューとして既知）とを指定することができる
この手法は、各ウィンドウイングシステム上でグラフィックスを再描画するのに使用される画面リペイント手法に類似している。画面のある領域がリペイントを必要とするとき、その画面の一部を担当するアプリケーションが画面のリペイントのために呼び出される。
【００９３】
９．１  例
クライアント装置は、装置上で稼動する連絡先アプリケーションを有することもある−この装置は、同様に連絡先アプリケーションを実行中の他のクライアント装置に接続されるコグニマサーバを用いてデータを複製する。名前及び電話番号を含むある連絡先に対してオブジェクトのクラスが定義され、これらのデータが特定のユーザの全ての装置へと複製される。
【００９４】
ある装置上のアプリケーションは、頭文字により全ての連絡先を表示する表示画面を有しても良い−例えば、インタフェースによりユーザがＤのボタンを押下することで、Ｄで始まる全ての名前を表示することができる。このアプリケーションは、以下のような場合にオブジェクトを含むセレクションを設定するであろう：
・クラスが連絡先として定義される場合
・名前が選択された文字（例えば、Ｄ）で始まる場合
セレクションが定義される場合、アプリケーションはオブジェクトが追加、削除、又は更新されたときにＣＲＥにより呼び出されるコードも定義する。
【００９５】
セレクションが最初に設定される場合、このコードは上述の基準を満たす第１のオブジェクト集合を伴って呼び戻されることになる。
【００９６】
Ｄで始まる名前を有する新規の連絡先を作成するように要求された場合、アプリケーションはオブジェクトを作成する以外のことは行わない。ＣＲＥは新規のオブジェクトを検出して、新規のオブジェクトを通知するためにセレクションコードを呼び戻すであろう。
【００９７】
同様の場合は、新規の連絡先オブジェクトが別の装置上で作成され、クライアント装置へと複製された場合である−連絡先の名前がＤで始まる場合、アプリケーションは通知を受けるであろう。
【００９８】
９．２  ソーティング
一般的に、セレクション中のデータはソートする必要がある−多くの場合、表示時にユーザが論理フォーマットでデータを見ることができるようにするためである。セレクションが定義されるときに、ソーティング順（どのプロパティによってソートすべきか、どの順序でソートすべきか、及びどのソーティングアルゴリズムを使用すべきか）を指定することができる。
【００９９】
９．３  ビュー
セレクション中には多数のデータ項目が存在することもある。通常、データの表示中にデータが画面内に収まらない可能性もあり、ユーザはデータを上下にスクロールする必要があるだろう。ビューは、セレクションが扱うデータ項目の個数とアプリケーションがセレクション中に出したいデータを網羅するリストのうちの第１のデータ項目の個数とを指定することによってこの機能を提供する。
【０１００】
アプリケーションは、画面上に表示するのに必要な量のみに制限されるようにローカルで格納するデータ量を制限することができるので、ビューは重要である。これにより、データの不要な複製が減少する。
【０１０１】
９．４  効率
コグニマは、データがコグニマサーバとクライアントアプリケーションとの間で転送される方法において効率的な最適化を成し遂げた−複数のデータ変更が行われると、アプリケーションはユーザインタフェースを１回だけ更新すれば良いように、データはブロックで送信され、アプリケーションは変更が完了したことを通知される。
【０１０２】
９．５  例
一例として、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 ListContacts();
};
オブジェクトが追加、更新、又は削除されるたびにフレームワークにより各メソッドObjectAdded()、ObjectUpdated()、及びObjectRemoved()がそれぞれ呼び出される。セレクションクラスを実現する際に、これらのイベント発生時にインスタンスアクションを取りたくない場合には、全てのメソッドを実現する必要はない−ある特定のオブジェクト集合のリストを維持するためにセレクションを設定するが、他の何らかのイベント発生時にのみリストのチェックを行い、上述のメソッドが必要でない場合もある。
【０１０３】
更にプライベートメソッドListContacts()も定義している−これは、セレクションにより保持される全ての現在の連絡先を列挙する。
【０１０４】
このクラスの実施例を挙げる：
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()、Updated()、及びRemoved()メソッドは、何の変更があったのかをプリントアウトし、ListContacts()を呼び出してリストの現在の内容を示す。
【０１０５】
ListContacts()は、セレクションにより保持されるオブジェクトの現在のリストがどのようにアクセス可能になるかを示す。オブジェクトを指し示すポインタの現在のリストがiResultと呼ばれるコンテナクラスに保持される−これは、通常のコンテナクラスインテグレータによりアクセスすることができる。この場合、リストに目を通して、リスト中の全てのオブジェクトをプリントするだけである。
【国際調査報告】
2005510796.tif 000006
2005510796.tif 000007
2005510796.tif 000008