JP2005527883A - バッテリー駆動のモバイルコンピュータ装置上で表示画面を更新する方法 - Google Patents

Abstract

バッテリー駆動のモバイルコンピュータ装置が、その装置上のアプリケーション又はユーザインタフェースプログラムが表示するためにデータベースにおいて変更されたデータを該アプリケーション又はユーザインタフェースプログラムへと継続的にプッシュすることにより、該アプリケーション又はユーザインタフェースプログラムが変更されたデータを求めてデータベースをポーリングする必要のないデータベースを有する。継続的にプッシュされるデータは、アプリケーション（又はＵＩプログラム／コンポーネント）が必要−例えば、表示のために必要と定義するデータのみである。この手法は、自動バックグラウンドプロセスであるので、割込みの促進画面を使用する従来の手法よりも優れている。実際に表示の必要があるときにのみ電力及び処理サイクルを使用するので、データ変更がないときにも定期的にデータベースをポーリングする必要のある自動バックグラウンド手法よりも優れている。

Description

本発明は、バッテリー駆動のモバイルコンピュータ装置、特に携帯電話又は電子手帳などのリソース制約型モバイル装置（すなわち、メモリ、処理能力、及びバッテリー寿命に制限のある装置）上で表示画面を更新する方法に関する。

モバイルコンピュータ装置は、アプリケーションが稼動中でないときに、データを保持する何らかのローカルなデータベースにデータを読み書きすることができる単純なファイリングシステムを有する傾向にある。一般的に、このようなアプリケーションは、利用可能なデータの集合を読み込み、表示画面にデータを表示するユーザインタフェースを提供する。

データベースからの読み込みは、データベース中のデータが変更された（例えば、電子メールデータベースにおいて新規の電子メールが到着した）場合に、アプリケーションにより自動的且つ定期的に行なわれる。しかしながら、このプロセスは、バッテリー駆動の無線モバイルコンピュータ装置で貴重な電力を消耗し、プロセッサ能力を使い果たす。また、データベース中のデータに変更がない場合でもプロセスを行なう必要があるので無駄である。

代わりに、データベースのデータが変更された際にデータベースが割込み画面を生成（例えば、「新着メールがあります」画面を生成）し、ユーザが「読む」ボタンを押下するように促すこともできる。この操作により、表示画面は新たなデータで更新／リペイントされる。ユーザは、特に小さいディスプレイしかないモバイルコンピュータ装置ではこの種の割込み画面を望まない場合が多いので、この構成はユーザ相互作用の観点から具合が悪い。

他にも幾つかの欠点がある：
・アプリケーションはデータの全部又は一部の複製を格納する必要があり、これが乏しいメモリを占有する
・２以上のアプリケーションが同じデータの集合をアクセスできるようにすることは問題となる
・データを読んだり操作したりするための類似のコードが装置上で稼動する幾つかのアプリケーションで出現する
・プログラムが起動するときのデータの読み込みに時間がかかる
リソース制約型バッテリー駆動のモバイルコンピュータ装置には、より電力効率及びメモリ効率の高い手法が求められている。

［発明の概要］
本発明の第１の態様によると、バッテリー駆動のモバイルコンピュータ装置上で電力消費及び処理要件を最小限にするように表示画面を更新する方法であって、
前記装置上のアプリケーション又はユーザインタフェースプログラムが表示するためにデータベースにおいて変更されたデータを該アプリケーション又はユーザインタフェースプログラムへと継続的にプッシュすることにより、該アプリケーション又はユーザインタフェースプログラムが変更されたデータを求めて前記データベースをポーリングする必要のないデータベースを提供する工程を有することを特徴とする方法が提供される。

継続的にプッシュされるデータは、アプリケーション（又はＵＩプログラム／コンポーネント）が必要−例えば、表示のために必要と定義するデータのみであるのが好ましい。このため、アプリケーションが「緊急」又は高優先度（あるいは、その他のユーザ選択フィルタ）として分類されたメッセージのみを表示するように設定された電子メールアプリケーションである場合、電子メールメッセージデータベースは、緊急として分類された新規の電子メールメッセージのみを電子メールアプリケーション／ＵＩプログラムに対して表示のためにプッシュするであろう。表示は自動的に、装置によりメッセージが受信された（通常、無線ネットワークを介して）直後に行なわれるであろう。

この手法は、自動バックグラウンドプロセスであるので、割込みの促進画面を使用する従来の手法よりも優れている。また、実際に表示の必要がある（例えば、新着メッセージあり）ときにのみ電力及び処理サイクルを使用するので、データ変更がない（新着メッセージなし）ときにも定期的にデータベースをポーリングする必要のある自動バックグラウンド手法よりも優れている。

更に、アプリケーションは、実際に表示中の（又は表示が想定される−例えば、オープンウィンドウ内でスクロール可能な）データのみを格納すれば良いので、アプリケーションが実際に表示されている又は表示が想定されるデータの上位集合をメモリに格納する必要があるシステムと比較して、相当なメモリ空間が節約される。

１つの実施例において、データベースは、幾つかの異なるアプリケーションにより使用するためのデータを提供することができる。例えば、データベースが全種別のメッセージ（電子メール、ｓｍｓ、画像など）を受信する場合、新規のメッセージを幾つかの異なる種別のアプリケーション（例えば、全種別のメッセージを列挙するメッセージングアプリケーション及び全ての受信フォトメッセージのサムネイルを列挙・表示し、この写真を最高解像度で表示できるようにするフォトアプリケーション）へとプッシュすることができるだろう。従って、データベースは、どのアプリケーションが異なる種類の変更されたデータを必要とし、そのデータをプッシュすることができるかを認識している。

データの格納作業、ソーティング作業、及び索引付け作業の全てはデータベースにより行なわれるので、この機能を各アプリケーションにおいて繰り返す必要がない。このため、アプリケーションコードサイズが削減される。

変更されたデータは、データベース中の新規のオブジェクト又はレコード、データベースから削除されたオブジェクト又はレコード、データベース中のオブジェクトの変更されたプロパティ又はレコードの変更されたフィールドであっても良い。更に、アプリケーションはデータの表示を直接更新するのではなく、データの表示を更新するデータベースを更新する。アプリケーションは、データベースがデータをソートする方法及びデータのソート済リスト上に小型のウィンドウが必要であるか否かを指定することができる。

アプリケーションは、通常、以下のリストから選択されるアプリケーションである：
（ａ）連絡先
（ｂ）予定表／日誌
（ｃ）メッセージング
（ｄ）プレゼンス及びインスタントメッセージング
（ｅ）フォトギャラリー
（ｆ）呼出し音ダウンロード、サンプリング、及び順序付け
（ｇ）バンキング
（ｈ）装置管理
第２の態様において、電力消費及び処理要件を最小限にするように表示画面を更新するべくプログラムされたバッテリー駆動のモバイルコンピュータ装置において、
アプリケーション又はユーザインタフェースプログラムが表示するためにデータベースにおいて変更されたデータを該アプリケーション又はユーザインタフェースプログラムへと継続的にプッシュすることにより、該アプリケーション又はユーザインタフェースプログラムが変更されたデータを求めて前記データベースをポーリングする必要のないデータベースを備えることを特徴とする装置が提供される。

本発明は、Cognima Limited of London, United Kingdomによる実施例を参照して説明する。コグニマ（Cognima）では、消費者によるデータサービスの利用を増加させ、大切な顧客の固定客化を促進し、競合他社から自社のサービスを差別化するために、モバイルサービスプロバイダ（ＭＳＰ）及びネットワークオペレータの必要性に直接対処するデータ複製技術を開発してきた。

コグニマのデータ複製ソリューションは、これらの問題に対して以下の手法により対処する：
・注目度の高い、容易に利用可能なものにすることにより、データサービスの利用を増加すること
・加入者の個人データを担当のＭＳＰにより制御されたサーバ上で確実にバックアップすることにより、乱れ（churn）の防止を強化すること
・顧客の経験を制御することによってＭＳＰが差別化されたサービスを作り出せるようにすること。

１．コグニマデータ複製フレームワークの用途の概説
コグニマのデータ複製フレームワークにより、モバイルサービスプロバイダは消費者市場に対して注目度の高いサービスを設立することができる。ＭＳＰは、データセンタにおけるコグニマサーバのホストとして機能する。サーバは、規格ベースのＪ２ＥＥアプリケーションサーバ及びキャリア級のＵｎｉｘ（登録商標）ハードウェア上で動作するオラクルデータベース及びコグニマのマルチスレッドＪａｖａ（登録商標）通信サーバから構成される。第４節以降では、技術的な実現を詳細に説明する。

コグニマフレームワークは、携帯電話に入力されたデータを自動的に（ユーザの介入なしに）コグニマサーバを介して他の電話機へと複製する。同様に、コグニマサーバに接続された外部システムからのデータは、携帯電話上で自動的に最新の状態に維持される。

コグニマ対応アプリケーションを使用するモバイル加入者は、「個人情報」及び「複数の友人」に対する「常時利用可能な」、「即時」接続を経験する。
・「個人情報」は、加入者の住所録、メッセージ、銀行口座取引明細、株価、ピザ注文、カレンダー、職場への通勤経路の現在の交通状況、又はその他の個人化されたコンテンツを含むことができる。データは常にコグニマサーバ上で確実にバックアップされ、全ての関連するクライアント装置上で自動的に複製される
・「常時利用可能な」は、現在ネットワークに接続されているか否かに関わらず、加入者が携帯する何れの装置又はハンドセット上でも個人情報をアクセス可能であることを意味する。ユーザは、装置上にローカルに格納された個人情報を常にアクセスすることができるからである。また、ユーザはウェブインタフェース−Virtual Phone−を介してサーバ上で直接個人情報を編集・管理することができる
・「即時」は、加入者がサーバからのデータのダウンロードを待つ必要がないことを意味する。最新の情報は、加入者がその必要性を認識していなくても既にそのハンドセット上にある。データが自動的にハンドセットへと送信されるからである（例えば、ハンドセットによるポーリングが行われるであろう。このポーリングは、例えば３０分ごと又は所定の時刻（午後４時、午後５時など）に定期的に行うことができる。ハンドセットに対するプッシングも起こり得る）
・加入者は複数の装置に渡って彼らの「複数の友人」とデータを共有することができる。コグニマサーバはこのデータを任意の定義済の装置又は定義済の個人へと複製することができるからである。

１．１ コグニマアプリケーションの例

２．モバイル加入者にとっての利点
コグニマは、以下の重要な利点に基づいて量販市場の消費者データサービスを実現するための理想的なフレームワークを提供する：
・「親しみやすさ」：ユーザの介入は不要である。加入者は自身のデータをアクセスするのに「同期」又は「ダウンロード」ボタンを押下する必要がない。システム構成及び確実なデータ転送は、エンドユーザからは完全に見えない
・「即時可用性」：ユーザは常に、ローカルデータとは即時に相互に作用することができる（オフライン時であっても）。一方で、更新はバックグラウンドでひそかに行われる。例えば、ユーザは地下鉄でも個人化されたコンテンツを読むことができる。ユーザ行為（user experience）はデータ転送から切り離されている
・「値ごろ感」：ＭＳＰは複製をいつ実行するかを制御でき、もたらされるサービス品質（ＱｏＳ）を制御できる。しかし、ユーザ行為はデータ転送から切り離されているので、低いＱｏＳでもユーザのサービスに対する認識には影響しない。このため、ＭＳＰはユーザ行為を犠牲にすることなく、比較的低いＱｏＳで低コストな加入ベースのサービスを提供することができる。例えば、銀行口座取引明細などの緊急でないデータサービスに関しては、データ複製を夜間に行うことも可能であり、この場合でもユーザは不満を感じない。夜間のデータ複製では、十分に利用されていない帯域幅を使用するため、ピーク時のデータ複製に比べて格段に費用が安い。緊急のデータ複製（例えば、プレゼンス情報）は、定期的に又は（オプションとして）継続的に（プッシュで）随時行うことができ、請求料金をより高額なものにすることができる。更に、電話機のメモリ及びプロセッサ能力の有効利用により、コグニマクライアントソフトウェアは、安価な量販市場の電話機においても、経済的にインストールすることができる。

３．モバイルサービスプロバイダにとっての利点
コグニマは、新規のデータ収入を生み出し、乱れを減少させ、自社のサービスを競合他社のサービスから差別化する手段を提示する。

３．１ 既存のモバイルサービスの利用度の向上
コグニマは、既存のモバイルサービスの利用度を向上する：
・メッセージングサービス及びコンテンツベースのサービスは、ますます便利になると共に即時性が高まり、両サービスの利用度が向上することになる
・プレゼンス情報の即時性が向上するため、チャット、インスタントメッセージング及び音声通話の空き容量があることを示すアラートの利用が増加することになる
・複数の装置を容易に管理することができるので、ユーザはいかなる場合でも適切な電話機を携帯することができ、通話やメッセージ送信が増加する。

３．２ 注目度の高い新規のサービス
コグニマは、注目度が高くお手頃な新規のモバイルデータサービスの急速な導入を可能にする。
・コグニマは、余剰のネットワーク容量のみを使用し、ローエンドの電話機における新規のサービスに対する注目度の高いユーザ行為をもたらす。これは、ネットワークオペレータにとって入手可能であると共にスケーラブルであり、ＭＳＰは量販市場の加入者に対して理解可能且つ予測可能な値段設定を提供することができる
・新規のコグニマサービスに対するアプリケーション開発の大半は、サーバ側で行われるため、ＭＳＰは新規のサービスを市場に迅速にもたらすことができる
・コグニマのクライアントソフトウェアは、フラッシュメモリのアップグレードとしてインストールすることができ、今日の量販市場のハンドセットに多機能電話並みの機能を付与する。新規のソフトウェアアプリケーションは、無線により既存のコグニマ対応ハンドセットへとダウンロードすることができるので、ＭＳＰは新規のデータサービスをそのサービスに対応した新規の装置を待たずとも展開することができる
・サードパーティのアプリケーション開発者は、ＭＳＰのコグニマインフラストラクチャを活用して、ＭＳＰのネットワークに対する新規のアプリケーションを開発することができる。

３．３ 乱れ削減
コグニマは、乱れを防止する重大な障壁となる。例えば、個人情報をＭＳＰのコグニマサーバに確実に格納する加入者は、新しい電話機を購入し、全ての個人情報を即時に新規の装置へと取得することができる。異なるサービスプロバイダに加入することにした場合、この個人情報は全て失われることになるだろう。

３．４ 差別化
現在加入者は、全てのネットワーク上でモバイルデータサービスを使用するという同じ基本的な経験を有する。例えば、ＷＡＰサービスを使用する経験は、ＷＡＰプロトコル、電話機中のブラウザ、及びアクセスされるコンテンツにより定義される。多くのＭＳＰは、独自のユーザ行為を加入者に与えることで自身の差別化を図らなければならないことを認識している。しかし、モバイルハンドセットにおいてサービスをカスタマイズすることに対する厳しい制約が、その差別化の障害となっている。

コグニマにより、ＭＳＰはハンドセット上でサービスを実現し、加入者のユーザ行為の制御を取り戻すことができるようになる。最も重要なことは、コグニマは相互運用性を犠牲にすることなく、これを実現するということであり、コグニマサーバとの簡単な統合を介して業界標準への対応も達成される。最終的には、価値連関表におけるＭＳＰの地位は、ハンドセットメーカー及びコンテンツプロバイダの強力なブランドに対して強化される。

４．コグニマデータ複製フレームワークの機能設計
４．１ 概論
詳細な説明の本節以降の各節では、コグニマデータ複製システムが実際にどのように機能するかを説明することを意図する。この説明には、クライアント装置、コグニマサーバ、及びウェブクライアントの挙動が含まれるが、特定のハードウェア、プログラミング言語、ソフトウェアクラス設計、又は環境の詳細については触れない。使用される基本的なデータ構造及びアルゴリズムについては説明する。

用語

４．２ 目的
コグニマソフトウェアの目的は以下の通りである：
・ユーザ即時アクセスにより、無線データ接続が可能な複数のハンドヘルド装置上でデータの「最新の」コピーを表示・修正できるようにする
・ユーザが従来のウェブブラウザを使用して同じデータを表示・修正できるようにする
・ユーザのデータの確実なバックアップを簡単に実現できるようにする
・複雑で費用のかかる処理をサーバに転嫁することによって、安価なハンドセット上で強力なデータ機能をユーザに対して提供する。

４．３ 最高レベルの説明
クライアント装置は、クライアント装置上のデータベースにユーザのデータのコピーを保持する。ネットワーク接続の有無に関わらずこのデータにアクセスすることができるので、ユーザは常に即時アクセス権を有することになる。ユーザが装置上でデータを変更すると、変更は変更−ログへとコピーされる。クライアント装置は、定期的に無線ネットワーク上のコグニマサーバへと接続し、変更−ログから変更を送信し、新規のデータを受信する。これにより、データを変更する操作においてネットワークへと接続する必要はなくなる（すなわち、プッシュは好適な実施例では連続的ではない）。コグニマサーバは、クライアント装置から受信したデータ変更でデータベースを更新し、ユーザが所有する全ての装置の変更−ログにデータ変更を反映させる。これらの装置が次に接続するときには、変更を受信し、同じデータのコピーを伴って同期状態に維持されるであろう。

コグニマサーバはウェブサーバを含む。このウェブサーバにより、ユーザはコグニマサーバのデータベースに保持されるデータのコピーを直接調べることができ、クライアント装置上で行うように変更を加えることができる。また、コグニマサーバは、ユーザがネットワーク／インターネット上の他のサーバと通信するためのゲートウェイとしても機能する。例えば、クライアント装置はメッセージオブジェクトに少数のフラグを設定することによって、ＳＭＳ、電子メール、又はファックスとしてメッセージを送信するようにコグニマサーバに事実上要求することができ、コグニマサーバは電子メールサーバ、ＳＭＳサーバ、及びファックス装置と通信を行う機能を含む。これは、呼出し音、バンキング明細、ゲームなどを保持するサーバへと拡大することができる。クライアント装置上にソフトウェアを構築するよりも、コグニマサーバ上にソフトウェアを構築して他のサーバに問い合わせる方がより簡単で安価である。

５．より低いレベルの概念
５．１ データ構造
５．１．１ ＩＤ
コグニマユーザデータは、オブジェクトデータベースの専門用語：クラス及びオブジェクトを用いて記述される。同様の名称を有する○○プログラミング概念と混同される可能性があるので、注意が必要である。

コグニマネットワークの全てのユーザには「ユーザＩＤ」が割り当てられる。このＩＤは、コグニマネットワーク特有のものであり、ネットワークオペレータにより提供される。全てのユーザは、ユーザＩＤとコグニマサーバのＵＲＬとの組み合わせである「コグニマアドレス」を有する。これは世界でただ１つのものである。ユーザに所属する各装置には「装置ＩＤ」が割り当てられる。この装置ＩＤはユーザ特有のものである。このＩＤは８ビットであるので、ユーザは最大２５３台の装置を持つことができる（ＩＤ２５４はウェブのために予約されており、ＩＤ２５５は予備であり、ＩＤ０は無効である）。全てのユーザデータは、クラス（連絡先クラス、メッセージクラス、銀行取引クラスなど）に分類され、各クラスには世界でただ１つのクラスＩＤが割り当てられる。例えば、クラスＩＤ「１２」は連絡先のことを指す。

クラスのインスタンスはオブジェクトであり、オブジェクトにはユーザ特有の「オブジェクトＩＤ」が割り当てられる。例えば、ある連絡先クラスオブジェクトは、「John Smith」の連絡先であるだろう。オブジェクトＩＤは、オブジェクトを作成した装置の装置ＩＤを装置の寿命を超えて増加する単調増加のカウントと結びつけることにより生成される。各装置は最大１６，７７７，２１５個のオブジェクトを作成することができる（この制限値に到達した場合には装置ＩＤをリセットすることができるだろう）。クラスはそれを構成するプロパティにより定義される。クラスは本質的にプロパティの配列である。クラスの各プロパティはプロパティＩＤを持ち、このＩＤはクラス特有のものである（実際は、０から始まるプロパティ配列におけるプロパティの配列位置）。

５．１．２ オブジェクト作成
オブジェクトは装置上で作成される。このオブジェクトにはオブジェクトＩＤが割り当てられ、装置データベースに保存される。コピーも変更−ログへと保存される。装置が次にコグニマサーバへと接続すると、変更−ログのエントリが送信される。コグニマサーバはオブジェクトをデータベースに保存し（システム時間を記録）、必要とされるクラス特有の処理（例えば、電子メールの生成・送信）を行い、ユーザが所有すると共にクラスへの関わりを宣言したその他の装置の変更−ログにエントリを追加する。（このエントリは、装置上のクラスの正しいバージョンに対するものでなければならない）。

オブジェクトはウェブポータル上に作成されても良い。オブジェクトＩＤが生成され（上述のように装置ＩＤ２５４を使用して）、装置と同様に処理される。ウェブポータルに対しては変更−ログはなく、コグニマサーバのデータベースから直接に選択内容を取得する。

また、オブジェクトはサーバアプリケーションにより作成されても良い（例えば、メッセージングモジュールは電子メールを受信し、この電子メールよりメッセージオブジェクトを作成する）。オブジェクトＩＤは、（上述のように装置ＩＤ２５４を使用して）生成され、装置と同様に処理される。

５．１．３ オブジェクトの更新
既存のオブジェクトの１つ以上のプロパティが装置上で修正される。変更は装置データベースへと保存される。変更された各プロパティは装置変更−ログにおいてエントリを生成するのに使用される。これらは、コグニマサーバへと送信される。

更新時間がコグニマサーバのデータベースのプロパティに対する「最終変更」時間より後である場合、コグニマサーバは変更をデータベースに保存し（プロパティに対する新規の「最終変更」時間を記録）、所要のクラス特有の処理を行う。更に、コグニマサーバは、ユーザに所属し、クラスを宣言すると共に、プロパティを含むクラスのバージョンを有するその他の装置の変更−ログにエントリを追加する。更新は、変更が最初に行われた装置の変更−ログに対しても行われる。奇妙に思えるかもしれないが、これは以下のシナリオに対処するのに必要である：
ユーザは２台の装置Ａ及びＢを持っている。ユーザは、午後５時にＡにおいてオフラインでプロパティ７を更新し、午後６時にＢにおいてオフラインでプロパティを更新する。まず、Ａを用いてネットワークへと接続する。Ａ上の値７は、Ｂに送信されるべく変更−ログに反映される。その後、Ｂを用いて接続する。値７はより最近のものであるため、Ｂ上の値７がＡへと送信される。しかし、ＢはＡの値を入手する。値７をＢに複製し直すことによりこれが確定される。

削除済としてマーク付けされたオブジェクトに対して更新がコグニマサーバにより受信され、更新が削除よりも後に行われている場合、復旧と解釈される。オブジェクトは復旧され、更新され、オブジェクトのリフレッシュが全ての適切な装置の変更−ログ上で行われる。ウェブポータル又はサーバアプリケーションからの更新も同様に機能する。

５．１．４ オブジェクトの削除
オブジェクトが装置上で削除される。装置データベースから削除され、クラスＩＤ及びオブジェクトＩＤを列挙する変更−ログ上にエントリが設けられる。エントリはコグニマサーバへと送信される。

削除時間がオブジェクトの最終更新時間より後である場合、コグニマサーバはデータベースにおいてそのオブジェクトに削除済としてマーク付けし、クラス特有の処理を行い、ユーザに所属すると共にクラスを宣言したその他の装置にエントリを追加する。

削除時間が最終更新時間より前の場合、削除が無効であることを示す。オブジェクトのリフレッシュが、削除が最初に行われた装置の変更−ログに対して行われる。

削除されたオブジェクトは、削除状態が明らかになるようにウェブポータルで見ることができる。ユーザは復旧のためにオブジェクトを選択することができる。削除マークがコグニマサーバのデータベース中のオブジェクトから削除され、オブジェクトをリフレッシュするためのエントリが、ユーザに所属すると共にクラスを宣言した全ての装置の変更−ログ上に設けられる。

５．１．５ プロパティ型
各プロパティには型がある。現在、９個の許容されたプロパティ型がある：

「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）送信される全ての時間を調整することができる。

例えば、以下の表に、コグニマサーバへと接続するクライアント装置におけるイベントのパターンを示す。クライアント装置の時間はコグニマサーバより５分遅く、毎時１分遅れている（要点を示すために極端な場合を挙げる）。更に要点を示すために、０９：００から１２：００までユーザは機上でコグニマサーバと接触がなく、この間クライアント装置は接続していないものとする：

プロパティ変更がコグニマサーバ上に格納された時間の前後に行われたか否かを導き出すために、時間Ｘ及びＹを計算する必要がある。上述の情報から、コグニマサーバには、クライアントが前回接続したのは約３時間前であり、その時点では時間差は５分であったが、現在は８分になっていることが分かっている。クロック変動が直線的に発生するものと想定すると、コグニマサーバは、装置がＧＭＴより５分遅れており、クロックは毎時１分遅れることを算出することができる。

これにより、クライアント装置がプロパティＡの変更に対して１０：００として認識する時間は、初期変動として５分を加える必要があり、プロパティが変更されるまでの時間に発生した追加の変動のために更に１分加える必要がある。

同様に、プロパティＢは１１：０７に調整される必要がある−５分の初期変動に加えて、プロパティが変更されたとき０９：００から１１：００まで２時間経過しているために更に２分必要である。

実際には、クライアント装置の時間とＧＭＴとの間の時間に対する差分は数分であるが、変動は１時間あたり数分の１秒のオーダーとなるであろう。

６．２．１ 時間調整
ＧＭＴに対する差分及びクライアント装置のクロックと同様に、ユーザはクライアント装置上の時間を変更することができる。ユーザは、時間を正しい現地時間にリセットするためにこの変更を行うかもしれない（ユーザは自動的にこの変更を行うオプションを選択することもできるが、ユーザの中にはクライアント装置の時間を自分で制御したい−例えば、クロックを５分早く設定したいと思う人もいるかもしれない）。また、現地時間（すなわち、サマータイム又は時間帯の変更）の変更を反映させるために変更を行うかもしれない。目的は、ユーザが自身に即した任意の時間に装置上のクロックを変更することができ、装置はただこれを考慮するだけであるように構成することである。

ユーザがクライアント装置の時間に対して変更を行う場合、大半のオペレーティングシステムはこの変更を報告する（これを行わないシステムにおいては、このような変更をチェックするために、例えば、毎分時間をポーリングすることができる）。時間の変更を検出すると、クライアント装置は新しい時間と変更前の時間との間の差分を算出するであろう。例えば、ユーザが時間帯を移動したときにはプラス１時間の変更となるかもしれない。クライアント装置は、この時間差を調整時間として格納する。この調整時間は、コグニマサーバへの次回の接続時のために保存される。また、クライアント装置は、変更ログの全ての項目に目を通し、調整時間によりログ中の全ての時間を更新する。これにより、変更ログ中の各エントリをクライアント装置上の現地時間と常に関連させておくことができる。

このような調整は、コグニマサーバへの接続間でも行うことができるだろう−ログ中の各時間は全てクライアント装置上の現地時間に関連するように、毎回、時間変更の量が調整時間を用いてまとめられ、変更ログが更新される。

クライアント装置が次にコグニマサーバへと接続するときには、格納された調整時間−すなわち、前回の接続以降クライアント装置のクロックが進められた又は遅らせられた量−をログオン時に送信する。コグニマサーバは、ＧＭＴに対する差分及び変動計算により時間からこの量を差し引くことができる。

６．２．２ クライアント装置に対するＧＭＴ
コグニマサーバ上で行われた変更のＧＭＴ時間をあるクライアント装置にとって正しい現地時間に変更するべく、同じ一連の計算を逆に行うことができる。

６．３ アプリケーションの追加
アプリケーションは１つ以上のクラスを使用してユーザデータを保持するであろう。クラスの定義はアプリケーションへとハードコードされる。クラスのバージョンは、アプリケーションのリリースにより調整される。

統計アプリケーションがフットボール選手クラスを使用してフットボール選手に関するデータを保持するものとする。アプリケーションがクライアント装置上で最初に起動されるとき、どのバージョンのフットボール選手クラスを既に保持しているかを装置に問い合わせる。装置上のバージョンが、アプリケーションが使用すべくハードコードされたバージョンと同じである場合、それ以上何も行わなくて良い。

装置が、フットボール選手クラスの新しいバージョンを保持する場合、アプリケーションは予想よりも多くのプロパティに対処できるよう十分頑強でなければならない（複数のアプリケーションにより使用されるクラスを有していて、何らかの理由でアプリケーションのうちの１つの古いバージョンをインストールした場合にこの状況が発生するであろう。これは稀なケースであり、理想的には相互依存するアプリケーションは共にアップグレードすべきである。）。

装置がフットボール選手クラスの古いバージョンを保持する（又は全くバージョンを保持しない）場合、アプリケーションの有するフットボール選手クラスのバージョンをそれと置き換えるべきである。新しいバージョンはコグニマサーバへと送信される。コグニマサーバは全ての装置上で使用されるクラスの各バージョンのリストを維持する。

ウェブポータルのページは、ハードコードされた装置のアプリケーションと同等であろう。ウェブはクラスの最新バージョンに従ってデータベースからオブジェクトを抽出することができ、予想してハードコードされたよりも多くのプロパティがある場合は無視することができる。従って、ウェブはクラスバージョンを宣言する必要がない。

６．４ 変更−ログの最適化
コグニマサーバは、装置が次に接続するときに送信されることになる変更を列挙する全ての装置に対する変更−ログを維持する。例えば、変更−ログに対して行うことができる最適化には以下に示すようなものがあるだろう：
・同じプロパティに対する３つ以上の更新が変更−ログにキューイングされている場合、最後の更新のみを維持すれば良い
・あるオブジェクトに対して削除がキューイングされている場合、キューの前方にある更新は全て削除されても良い
・あるオブジェクトに対して更新がキューイングされている場合、キューの前方にある削除は削除されるべきである
・装置が新規のアプリケーションを登録する場合、そのアプリケーションに対して送信すべきオブジェクト（例えば、メッセージ履歴）が非常に多くなる可能性がある。変更−ログは、追加対象として妥当な数のオブジェクト（例えば、最新の２０通のメッセージ）のみを持つべきである
７．ゴースト化、復活（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と呼ばれるコンテナクラスに保持される−これは、通常のコンテナクラスインテグレータによりアクセスすることができる。この場合、リストに目を通して、リスト中の全てのオブジェクトをプリントするだけである。

Claims (13)

1. バッテリー駆動のモバイルコンピュータ装置上で電力消費及び処理要件を最小限にするように表示画面を更新する方法であって、
   前記装置上のアプリケーション又はユーザインタフェースプログラムが表示するためにデータベースにおいて変更されたデータを該アプリケーション又はユーザインタフェースプログラムへと継続的にプッシュすることにより、該アプリケーション又はユーザインタフェースプログラムが変更されたデータを求めて前記データベースをポーリングする必要のないデータベースを提供する工程を有することを特徴とする方法。
2. 前記継続的にプッシュされるデータは、前記アプリケーション又はユーザインタフェース（ＵＩ）プログラムが必要と定義するデータのみであることを特徴とする請求項１記載の方法。
3. 前記アプリケーション又はＵＩプログラムは、表示のために必要なデータのみを必要と定義することを特徴とする請求項２記載の方法。
4. 前記データベースは幾つかの異なるアプリケーションによって使用するためのデータを提供することを特徴とする請求項１記載の方法。
5. アプリケーションが前記データの表示を直接更新するのではなく、前記表示を更新する前記データベースを更新することを特徴とする請求項１記載の方法。
6. 前記変更されたデータは、前記データベースの中の新規のオブジェクト又はレコード、前記データベースから削除されたオブジェクト又はレコード、及び前記データベースの中のオブジェクトの変更されたプロパティ又はレコードの変更されたフィールドであることを特徴とする請求項１記載の方法。
7. 前記アプリケーションは以下のリスト：
   （ａ）連絡先
   （ｂ）予定表／日誌
   （ｃ）メッセージング
   （ｄ）プレゼンス及びインスタントメッセージング
   （ｅ）フォトギャラリー
   （ｆ）呼出し音ダウンロード、サンプリング、及び順序付け
   （ｇ）バンキング
   （ｈ）装置管理
   から選択されるアプリケーションであることを特徴とする請求項１記載の方法。
8. 前記アプリケーションは、前記データベースがデータをソートする方法及びデータのソート済リスト上に小型のウィンドウが必要であるか否かを指定することを特徴とする請求項１記載の方法。
9. 電力消費及び処理要件を最小限にするように表示画面を更新するべくプログラムされたバッテリー駆動のモバイルコンピュータ装置において、
   アプリケーション又はユーザインタフェースプログラムが表示するためにデータベースにおいて変更されたデータを該アプリケーション又はユーザインタフェースプログラムへと継続的にプッシュすることにより、該アプリケーション又はユーザインタフェースプログラムが変更されたデータを求めて前記データベースをポーリングする必要のないデータベースを備えることを特徴とする装置。
10. 前記継続的にプッシュされるデータは、前記アプリケーション又はユーザインタフェース（ＵＩ）プログラムが必要と定義するデータのみであることを特徴とする請求項９記載の装置。
11. 前記アプリケーション又はＵＩプログラムは、表示のために必要なデータのみを必要と定義することを特徴とする請求項９記載の装置。
12. 前記データベースは幾つかの異なるアプリケーションによって使用するためのデータを提供することを特徴とする請求項９記載の装置。
13. アプリケーションが前記データの表示を直接更新するのではなく、前記表示を更新する前記データベースを更新することを特徴とする請求項９記載の装置。