(57)【要約】【課題】属性の分散管理することができ、属性粒度許可に基づく属性を伝搬することができるシステムを提供する。【解決手段】前記技術に応じたについての例は、第一クライアントと第二クライアントとに接続されるサーバーであって、前記第一クライアントから属性データを受信するモジュールと；前記第一クライアントと関連する第一許可が前記第二クライアントに対して個々の属性レベルで設定される許可データベースと；前記許可データベースをアップデートし、前記第二クライアントのために前記第一許可を有効にするためのエンジンと； 1つ以上の第二宛先格納部と関連する宛先に、有効な許可に基づく第一クライアントのアップデートを分散するためのエンジンとを具備するサーバーを備える。【特許請求の範囲】
【請求項１】
複数のエンティティのうちの第一エンティティと関連する第一属性と、複数のエンティティのうちの第二エンティティと関連する第二属性とを保持し；
前記第一エンティティを前記第二エンティティと結び付け；
前記第一エンティティと関連する第一宛先を前記第二属性に供給し；
前記第一属性についての第一許可を前記第二エンティティに与え；
前記第二エンティティと関連する第二宛先を前記第一属性に供給し；
前記第二属性についての第二許可を前記第一エンティティに与え；
前記許可を介しての前記宛先への共用属性の伝搬を促進し；
シンジケート化された分散された安全なデータ交換を作成するために属性のその後の変更を管理する；
ことを特徴とする方法。
【請求項２】
ローカルキャッシュからユーザーIDとデバイスIDとを読み取り；
許可がローカルに格納されていない場合には、ユーザーIDについての許可をリクエストするためにサーバーメソッドを呼び出し；
許可がローカルに格納されている場合には、ローカルファイルから許可を読み出す；
ことを特徴とする請求項1記載の方法。
【請求項３】
個人属性レコード(PAR)が離れて格納されている場合に、前記PARをリクエストするためにサーバーメソッドを呼び出し；
前記PARがローカルに格納されている場合には、ローカルファイルから前記PARを読み出す；
ことを特徴とする請求項1記載の方法。
【請求項４】
未決定のトランザクションをサーバーにリクエストすること、待つこと、またはトランザクションを送信するためのサーバーによって、トランザクションを取得することを特徴とする請求項1記載の方法。
【請求項５】
接続リストから1人以上の被授与者を選択し；
選択された接続の属性許可を有効にし；
サーバーについての許可設定をアップデートするためにサーバーメソッドを呼び出す；
ことを特徴とする請求項1記載の方法。
【請求項６】
授与者によって指定されるように許可テーブルをアップデートし；
授与者に所有されている各新しいデバイスのために、新しい許可設定を送信し；
被授与者に所有されている各デバイスのために、新しい属性値を送信し；
授与者が許可を与えている場合には、アップデート許可呼び出しに送信された前記属性値を送信し；
授与者が許可を取り除いている場合には、ヌル値を送信する；
ことを特徴とする請求項1記載の方法。
【請求項７】
授与者の属性についての被授与者を許可テーブルから選択し；
属性の変更に被授与者を接続し；
属性トランザクションを作成し；
被授与者と関連する宛先に属性トランザクションの変更を送信する；
ことを特徴とする請求項1記載の方法。
【請求項８】
デバイステーブルから授与者のデバイスを選択し；
属性の変更に被授与者を接続し；
個人属性レコード(PAR)トランザクションを作成し；
授与者と関連する宛先にPARを送信する
ことを特徴とする請求項1記載の方法。
【請求項９】
第一エンティティと関連する第一属性の第一許可を第二エンティティに与え；
第二エンティティと関連する第二属性の第二許可を第一エンティティに与え；
許可を介した共用属性の伝搬を促進し；
前記第一属性の第一許可を、前記第一エンティティと関連する第三属性の第三許可に変更し；
伝搬された共用属性を前記第三許可に従って呼び戻す；
ことを特徴とする方法。
【請求項１０】
第一クライアントであって：
第一属性データ格納部と；
1つ以上の第一宛先格納部と；
前記第一データ格納部への属性アップデートを特定し、アップデートと関連するデータを具備する許可ベーストランザクションを作成し、許可ベーストランザクションと関連するアップデートされたデータを送信するためのエンジンと；を備える第一クライアントと、
第二クライアントであって：
第二属性データ格納部と；
1つ以上の第二宛先格納部と；
前記第一データ格納部への許可ベースアップデートを特定し、前記許可ベースアップデートと関連するデータを具備するトランザクションを作成し、許可ベースアップデートと関連するデータを送信するためのエンジン；とを備える第二クライアントと、
第一クライアントと第二クライアントとに接続されるサーバーであって：
前記第一クライアントから属性データを受信するモジュールと；
前記第一クライアントと関連する第一許可が前記第二クライアントに対して個々の属性レベルで設定される許可データベースと；
前記許可データベースをアップデートし、前記第二クライアントのために前記第一許可を有効にするためのエンジンと；
1つ以上の第二宛先格納部と関連する宛先に、有効な許可に基づく第一クライアントのアップデートを分散するためのエンジンとを備えるサーバーと、
を備えることを特徴とするシステム。
【請求項１１】
前記第一クライアントは、アドレスブックプラグインを備えることを特徴とする請求項10記載のシステム。
【請求項１２】
前記第一クライアントは、個人属性レコード(PAR)データベースを備えることを特徴とする請求項10記載のシステム。
【請求項１３】
前記第一クライアントは、共有PIMデータベースを備えることを特徴とする請求項10記載のシステム。
【請求項１４】
前記第二クライアントは、アドレスブックプラグインを備えることを特徴とする請求項10記載のシステム。
【請求項１５】
前記第二クライアントは、個人属性レコード(PAR)データベース備えることを特徴とする請求項10記載のシステム。
【請求項１６】
前記第二クライアントは、共有PIMデータベースを備えることを特徴とする請求項10記載のシステム。
【請求項１７】
前記第一クライアントは、トランザクション履歴データベースを備えることを特徴とする請求項10記載のシステム。
【請求項１８】
前記第二クライアントは、トランザクション履歴データベースを備えることを特徴とする請求項10記載のシステム。
【請求項１９】
前記第一クライアントは、PIMプラグインを具備するインストーラを備えることを特徴とする請求項10記載のシステム。
【請求項２０】
前記第二クライアントは、PIMプラグインを具備するインストーラを備えることを特徴とする請求項10記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、個人属性に対する分散管理フレームワークに関する。
【背景技術及び発明が解決しようとする課題】
【０００２】
データベースは、データベースマネージャとして知られているアプリケーションによって指定される方法で編成され、格納され、マニピュレートされるデータエントリについてのコレクションである。データベースエントリーがデータベースにて編成される方法は、データベースのデータ構造として知られている。データベースマネージャは、フィールドからなる各レコードを用いて、データベースの情報をレコードに編成する。フィールドとレコードとは、データベースマネージャの目的と機能とに依存して異なる特徴を有し得る。ここで用いられる「データベース(database)」の文言は、データエントリと、関連するデータベースマネージャとを示す。以下では、「データベース」の文言は、データエントリと、関連するデータベースマネージャとの両方を含むことを意図している。
【０００３】
データベースを同期させることは時には好ましい。ここで用いられる「同期させる(synchronize)」の文言は、2つ以上のデバイスと関連するデータベースオペレーションを参照しており、それが他のデータベースのコンテンツに適合するまたは「映す(mirrors)」ように、データベースのコンテンツを変更する。同期化は、全体的(例えば、データベースのすべてのコンテンツを映している)、または、部分的(例えば、データベースのすべてのコンテンツについてのサブセットを映している)とすることができる。かかる同期化、時には「遅い同期化」と称される、を達成するための従来技術は、各データベースにおいて各レコードを比較することを具備する。遅い同期化は、部分的な同期化が不可能であることに留意する。さらに、遅い同期化は、複雑且つ時間がかかりすぎる。
【０００４】
データベースを同期させる別の従来技術は、変更ログをインプリメントすることを具備している。変更ログは、データベース間の同期化の後に双方のデータベースで操作されるレコードについての情報を有している。変化ログはまた、前のアップデートに先がけてなされた変更が無視され得るように、同期操作が2つのデータベース間で最後に実行された時間を記録する。そして、同期手順は、どのレコードを同期させるべきかを判断するために変更ログを利用する。これは、データベース全体を同期させることについての負担を軽くする。この技術は、時には「速い同期」と称される。
【０００５】
かかる技術の1つの欠点は、以下の例によって示される。映された情報は、第一デバイスおよび第二デバイスにあると仮定する。変更は、第一デバイスにて新しい有効な情報になされる。その後、第二デバイスにて変更がなされ、古い無効のデータをアップデートされたが無効であるデータに変更する。一般に、タイム・スタンプは、変更ログにおける双方の変更と関連している。2つの変更を解決する場合には、最も近いタイム・スタンプが好ましい。それに応じて、この例では、新しい有効なデータへの第一デバイスの変更は、変更が合間(すなわち、有効なデータを映す同期化の前)になされるので、第二デバイスではインプリメントされないであろう。
【０００６】
タイム・スタンプは同期プロセスにおいて重要な役割を果たすので、デバイスのクロックは、正確で、互いに合わせされ、不変である必要がある。このことは、常に、例えばモバイル機器における事例であるわけではない。実際には、モバイル機器のユーザーが、別のタイムゾーンに旅行してデバイスのクロックに関する時間を変更することはまったく一般的である。このことは、同期化についての問題を引き起し得る。場合によっては、タイム・スタンプについての問題は、変更を事実上失ったとして、同期化動作の変更をデバイスに無視させることができる。
【０００７】
同期化の問題に加えて、ユーザーは、それが退屈であると思うかもしれないし、或いは、新しいデータでデータベースをアップデートすることを忘れるかもしれない。例えば、ユーザーは、アドレスブックをローカルにアップデートすることができるけれども、変更された情報を知らせるためにアップデートを知人に送信するのに失敗する。さらに、アップデートされた情報を受信するユーザーは、接続情報をアップデートするのを忘れるかもしれないし、或いは、多数の接続のために継続的に情報をアップデートすることが退屈であると思うかもしれない。接続データベースを管理する企業にとっては、このことは特に時間がかかりすぎてしまう。
【発明の開示】
【課題を解決するための手段】
【０００８】
以下の実施形態と態様とは、範囲を限定しないで、例となり実例となることを意図されているシステムとツールと方法とに関連して説明されて示される。様々な実施形態において、他の実施形態が他の改良に向けられているにもかかわらず、上述の問題の1つ以上が削減または解消される。
【０００９】
属性の分散管理のための技術は、属性粒度許可に基づく属性を伝搬することを備える。前記技術に応じた方法についての例は、複数のエンティティの第一エンティティと関連する第一属性と、複数のエンティティの第二エンティティと関連する第二属性とを保持することを備える。前記方法は、前記第一エンティティを前記第二エンティティと結び付けることをさらに備える。前記方法は、前記第一エンティティと関連する第一宛先を前記第二属性に供給することをさらに備える。前記方法は、前記第一属性についての第一許可を前記第二エンティティに与えることをさらに備える。前記方法は、前記第二エンティティと関連する第二宛先を前記第一属性に供給することをさらに備える。前記方法は、前記第二属性についての第二許可を前記第一エンティティに与えることをさらに備える。前記方法は、前記許可を介しての前記宛先への共用属性の伝搬を促進することをさらに備える。前記方法は、シンジケート化された分散された安全なデータ交換を作成するために属性のその後の変更を管理することをさらに備える。
【００１０】
前記技術に応じたシステムについての例は、第一クライアントと第二クライアントとに接続されるサーバーであって、前記第一クライアントから属性データを受信するモジュールと；前記第一クライアントと関連する第一許可が前記第二クライアントに対して個々の属性レベルで設定される許可データベースと；前記許可データベースをアップデートし、前記第二クライアントのために前記第一許可を有効にするためのエンジンと； 1つ以上の第二宛先格納部と関連する宛先に、有効な許可に基づく第一クライアントのアップデートを分散するためのエンジンとを具備するサーバーを備える。
【００１１】
提案されているシステムと方法とデバイスとは、他にも利点があるが、属性の分散管理を提供し得る。本発明のこのことと他の利点とは、以下の説明と図面とを参照することで当業者に明白となる。
【発明を実施するための最良の形態】
【００１２】
本発明の実施形態は図にて説明される。しかしながら、実施形態と図とは、限定するというよりも説明に役立っている；それらは本発明の例を示す。
【００１３】
図1は、本実施形態に係る安全なコンタクト・データベース・同期システム100の概念図を示す。図1の例において、前記システム100は、サーバー102と、ネットワーク104と、クライアント106-1乃至106-N(以下、纏めてクライアント106と称する)と、モバイル機器108-1乃至108-N(以下、纏めてモバイル機器108と称する)と、クライアント110とを具備する。前記クライアント110は例の目的のためだけにクライアント106と区別されるということに留意する。クライアント106、110の何れかに関して説明される態様は、クライアント106、110の全てまたは一部に適用可能である。
【００１４】
前記サーバー102は、図7および8に関連して後述するように、様々なハードウェアおよび／またはソフトウェアコンポーネントを具備し得る。前記ネットワーク104は、図7および8に関連して後述するように、インターネットまたは他の何れかのネットワークであってもよい。
【００１５】
クライアント106は、図7および8に関連して後述するように、様々なハードウェアおよび／またはソフトウェアコンポーネントを具備し得る。さらに、本実施形態においては、クライアント106は、ユークライアント112(YouClient 112)とアドレスブック114とを具備する。ユークライアント112の機能は、図4と5に関連して後述される。前記アドレスブック114は、例であって限定されるものではないが、パーム・アドレスブック(AB)(Palm Address Book (AB))、アウトルックAB (Outlook AB)、モジラAB (Mozilla AB)、エンタレージAB (Entourage AB)、マックスOS X AB(Max OS X AB)、若しくは、あらゆる公知または最終のABタイプを含むさまざまなアドレスブック構成の何れかを具備し得る。
【００１６】
前記モバイル機器108は、図7および8に関連して後述されるように、様々なハードウェアおよび／またはソフトウェアコンポーネントを具備し得る。実際には、前記クライアント106がモバイル機器であってもよい。しかしながら、説明のために、モバイル機器108は、コンピュータ技術にて知られている方法でクライアント110と同期化する。例えば、モバイル機器108-1は、一例であって限定されるものではないが、携帯電話であってもよく、モバイル機器108-2は、一例であって限定されるものではないが、PDAであってもよく、それら双方は、一例であって限定されるものではないが、コンピュータ技術にて知られているiシンクロメカニズム(an iSync mechanism)を介してユーザーのコンピュータ（例えばクライアント110）上のマック OS Xアドレスブック(Mac OS X Address Book)と同期することができる。クライアント110は、その後、iシンクロの結果に基づくローカルデータベースをアップデートする。同等の技術は、様々なABタイプと様々なオペレーティングシステムとについて存在している。
【００１７】
図7および8に関連して後述されるように、クライアント110は、様々なハードウェアおよび／またはソフトウェアコンポーネントを具備し得る。さらに、本実施形態では、クライアント110は、ユークライアントモジュール112と、アドレスブック114と、ABタイプデータベース(dB)116と、同期モジュール118とを具備する。様々なコンポーネントがバス119に接続される。コンピュータアーキテクチャの当業者に明白であるように、一部または全てのコンポーネントをバス119に接続しない代わりの実施形態が、特に分散アーキテクチャーにおいて可能であることに留意する。
【００１８】
ユークライアントモジュール112の機能は、図4および5を参照して後述される。前記アドレスブック114は、さまざまなアドレスブック構成の何れかを具備し得る。前記ABタイプdB116は、様々なABタイプに関するデータを具備し、ユークライアントモジュールがそれと同期するために設定される。本実施形態では、新しいABタイプをABタイプdB116に追加することは、ユークライアントモジュール112の再コンパイルまたは他の再構成の必要を結果的に生じない。他の実施形態では、アドレスブック114(若しくはモバイル機器108またはクライアント106のうちの1つについてのアドレスブック)が一方のABタイプから別のものに変更される場合やアドレスブック114が新バージョンにアップグレードされる場合には、ユークライアントモジュール112の再コンパイルまたは他の再構成は必要でない。前記同期モジュール118は、モバイル機器108についてのクライアント110との公知の方法での同期化を促進する。ユークライアントモジュール112は、図4および5に関連してより詳細に説明されるように、同期モジュール118によってなされたアップデートを検出し、適切な行動を実行する。
【００１９】
オペレーションの例において、加入者はクライアント110に関連する。前記加入者は、モバイル機器108を所有している(または、少なくとも、モバイル機器のオーナーは、同期モジュール118にアクセスできる)。加入者は、モバイル機器108のアドレスブックをアップデートすることができ、および／または、加入者は、入力デバイスを使ってアドレスブック114をアップデートすることができる(その例は、図7と8とにおいて示される)。前記ABタイプdB116は、モバイル機器108のアドレスブックを認証することができてもよく、またはできなくてもよい。同期モジュール118が、ユークライアントモジュール112に認識可能なフォーマットにデータをレンダリングすることができる場合には、前記認証は必要でない。
【００２０】
ともかく、モバイル機器108のうちの1つ以上についてのアドレスブックを同期させることを通じて、或いは、加入者の入力などの他の方法によって、アドレスブック114への変更が遂行されるかどうかにかかわらず、ユークライアントモジュール112は変更を検出する。その後、図4および5においてより詳細に説明されるように、ユークライアントモジュール112は、許可をチェックするなどの所定のタスクを実行し、アップデートに関連するデータを、必要ならば適切な手順で、ネットワーク104を通してサーバー102に転送する。本実施形態において、セキュリティを保証するために、クライアント110とサーバー102との間のトランザクションが暗号化される。
【００２１】
前記サーバー102は、図4と5に関してより詳細に説明されるように、各クライアント108のユークライアントモジュールにアップデートを転送することを含むタスクを実行する。
【００２２】
限定しない実施形態において、クライアント108の各ユークライアントモジュールは、それらが起動しているおよび／またはアップデートを受信する用意ができていることについてサーバー102に定期的に信号を送る。サーバー102は、アップデートを受信する用意ができているおよび／または許容されているクライアント108に、ネットワーク104を通してアップデートを送信する。クライアント108がアップデートを受信すると、それらの各ユークライアントモジュールは、各々のアドレスブックをアップデートする。
【００２３】
図2は、本実施形態に係るクライアントコンピュータ210を示す。前記クライアントコンピュータ210は、クライアント110(図1)に類似していてもよい。図2の例において、クライアントコンピュータ210は、ユークライアント212と、アドレスブック214と、ユーインストールウィザード222(YouInstallWizard 222)と、ユーNIQモジュール224(YouNIQ module 224)と、ライブラリディレクトリ240 (library directory 240)とを具備する。ユーインストールウィザード222は、コンピュータ210上のローカルファイルを設定するために用いられる。ユーインストールウィザード222の機能は、図4と5に関連して後述される。ユーNIQモジュール224は、一例であって限定されるものではないが、クライアント106（図1）のように、どんな情報を他と共有するかをコントロールするための許可を設定するために用いられる。ユーNIQモジュール224の機能は、図4および5に関連してより詳細に説明される。限定しない実施形態において、ユークライアント212はJavaアプリケーションである。他の限定しない実施形態において、ユーインストールウィザード222とユーNIQモジュール224とはJava GUIに関連している。
【００２４】
図2の例において、前記ライブラリディレクトリ240は、ユークライアント.xmlファイル242(YouClient.xml file 242)と、ユーNIQ.xmlファイル244 (YouNIQ.xml file 244)と、ミーカードキャッシュ.xmlファイル246 (MeCardCache.xml file 246)と、ABタイプdB216とを具備している。ユークライアント.xmlファイル242は、ローカル構成情報と関連するデータを具備し得る。ユーNIQ.xmlファイル244は、許可とプロフィールとに関連するデータを具備し得る。ミーカードキャッシュ.xmlファイル246は、サーバー102(図1)などのサーバーに予め送信されている‘ミー(me)’レコードと関連するデータを具備し得る。これらのファイルは、例示のために示されており、図4および5に関連して説明される機能を容易にするために用いられ得るファイルのブロードカテゴリーを示すことを目的としている。そのようなものとして、前記ファイルは、一例であって限定されないが、.xmlなどのあらゆるファイル形式とすることができる。さらに、おそらく、様々なファイルに関連すると単に説明された情報に大まかに関連しているだけの任意の数のそのようなファイルがあってもよい。
【００２５】
図2の例において、前記ABタイプdB216は、エンタレージタイプ252 (Entourage type 252)と、マックOSX ABタイプ254(MacOSX AB type 254)と、パームタイプ256 (Palm type 256)と、その他(図示しない)とを含む。これらのタイプは、限定しない実施形態にて挙げられる。与えられたABタイプdB216は、前記示されたタイプを含んでも或いは含まなくてもよく、若しくは、ABタイプの追加までタイプを全く含まなくてもよい。本実施形態においては、新しいABタイプを追加することは、頻繁にうまく定義されたインタフェースとなる新しいABタイプクラスを、ABタイプdB216にロードすることを具備してもよい。そのような実施形態において、前記示されたタイプ252、254、256は、ABタイプクラスを代表していてもよい。クラス以外のデータ表現が代わりの実施形態において用いられ得るということに留意する。
【００２６】
オペレーションにおいて、加入者は、一例であって限定するものではないUIDを取得するためのサーバー102(図1)などようなサーバーに接続するために、ユーインストールウィザード222を実行する。代わりに、アドレスブック214がアップデートされた場合または他の刺激に応じて、ユーインストールウィザード222は自動的に実行され得る。また、プラットフォームがローカルファイルを許容すると仮定すると、加入者は、コンピュータ210上のローカルファイルを設定するためにユーインストールウィザード222を用いてもよい。代わりに、ユーインストールウィザード222は、自動的または他の刺激に応じて、必須のまたは所望の構成の一部または全部を実行してもよい。また、加入者は、それらのデータベースにおいて自己のレコードをアップデートすることを許容した者と関連するユーザーデータを取得するためにユーインストールウィザード222を用いてもよい。代わりに、ユーインストールウィザード222は、自動的または他の刺激に応じてデータを取得してもよい。加入者は、必須情報の一部または全部を入力するためのユーインストールウィザード222と関連するGUIを用いても或いは用いなくてもよい。本実施形態においては、ユーインストールウィザード222は、新しいUTDを取得し、(プラットフォームがローカルファイルを許容する場合には)クライアントデバイス上にローカルファイルを設定する。また、ユーインストールウィザード222は、ユーザーのアドレスブックにおける加入者のレコードをアップデートするために加入者を許容するユーザーを(もしあれば)取得する。
【００２７】
加入者は、許可を設定するためにユーNIQモジュール224に関連するGUIを用いてもまたは用いなくてもよい。前記許可は、前記クライアント106（図1）などのように、どんな情報を他と共有することができる或いは共有することができないかをコントロールする。ユーNIQモジュール224は、適切なパーティーへのアップデートの転送を起動してもよい。本実施形態において、転送されたアップデートは、実際には、関連するクライアント106への加入者に関連するレコードをアップデートする。
【００２８】
ユークライアントモジュール212は、誰に前記アップデートを転送するかを決定するために許可をチェックし、その後、サーバー102(図1)などのサーバーにアップデートと関連するデータを転送する。限定しない実施形態では、前記サーバーは、問題がある場合には追加情報を要求し、および／または、アップデートのステータスについてユークライアントモジュール212に通知してもよい。
【００２９】
限定しない実施形態において、コンピュータ210が他のものによってアップデートされ得ることに留意する。本実施形態では、前記コンピュータ210は、クライアント106(図1)の1つに類似している。オペレーションにおいて、ユークライアントモジュール212は、コンピュータ210が起動しおよび／またはアップデートを受信する用意ができていることを、サーバー102(図1)などのサーバーに定期的に信号を送って知らせても或いは知らせなくてもよい。前記サーバーが送信すべきアップデートを具備している場合には、サーバーは、適用可能ならば他の情報とともにアップデートを送信することができる。ユークライアントモジュール212は、アップデートを受信し、それに応じてローカルアドレスブックをアップデートする。
【００３０】
図3は本実施形態に係るサーバー302を示す。前記サーバー302は、ユーサーバーデータベース332 (YouServer database 332)と、ユーサーバーモジュール334(YouServer module 334)と、ユーサーバートランザクションログ336 (YouServer transaction log 336)とを含む。ユーサーバーデータベース332は、一例であって限定するものではないユーザー(例えば、UIDとip/ポート(port)などの接続情報とを含む)を含むさまざまなレコードを具備し得る；例えばvカード(vCard)規格(例えば、FIDとフィールド名とを含む)によって定義されるフィールド；許可テーブル(例えば、UID授与者とFIDとUID被授与者とを含む)；および、未決定のトランザクションログ(例えば、UID授与者、UID被授与者、プッシュ／プルブーリアン(push/pull Boolean)、FID、値)。さらに、請求などの内部スキーマと関連するデータベースがあってもよい。
【００３１】
限定しない実施形態において、前記ユーサーバーモジュール334の機能は、クライアント210(図2)などのクライアントからの要求に応答することである。ユーサーバーモジュール334は、一例であって限定するものではないが、加入者、許可、および未決定のトランザクションの経過を追うために、SQLデータベースを活用することができる。前記ユーサーバーデータベース332は、SQLデータベースを具備してもしなくてもよい。クライアントからの要求は、一例であって限定するものではないが、誰が加入者の‘ミー(me)’レコードに関する変更のコピーを取得するかについての許可を設定／変更するためと、新しい加入者に対するユーザーid(UID)を取得するためと、加入者がユーザーのアドレスブックの前記加入者に関連するレコードをアップデートするための許可を与えられた前記ユーザーのUIDを取得するためと、データトランザクションリクエストを受信して処理する(例えば、ミーエンジン(Me engine)は、‘ミー(me)’レコードの変更を検出し、許可が適切に設定されている場合には、それをサーバーへ送信し、サーバーは、前記許可を検査すると共にトランザクションログに<pushData>トランザクションを格納する) ためと、クライアントからの<awake>トランザクションを受信して処理する(例えば、クライアントは、入手可能な新しい<pushData>があるかどうかを確かめるために、定期的に< awake>トランザクションを送信することができる)ためと、新しいデータがある場合に、クライアントの< awake>トランザクションに<pushData>にて応答する要求を具備してもよい。<awake>および<pushData>トランザクションは、図5Aおよび5Bの例に関連して後述される。
【００３２】
前記ユーサーバーモジュール334は、一般にネットワークを介して加入者から、ネットワークまたはローカルインプットデバイスを介して管理者から、若しくは、ソフトウェアおよび／またはハードウェアアプリケーションから情報を受信することができる。読み取られた要求が、書き込み要求がインプットによりトリガーされている場合にユーサーバーデータベース332を書き込むインプットによりトリガーされている場合、ユーサーバーモジュール334は、ユーサーバーデータベース332を読み取る。さらに、ユーサーバーモジュール334は、一例であって限定するものではないが、SQLトランザクションとすることができるユーサーバートランザクションログ336をアップデートする。
【００３３】
ユーサーバーモジュール324は、管理者、加入者、第三者ベンダ、および／または自動化されたモジュールから加入者情報を受信することができる。加入者(または、他のパーティー)は、ユーサーバーデータベース322に読み取りまたは書き込むときに、他の機能を実行するために、ユーサーバーモジュール324にリクエストを送信することができる。例えば、加入者は、ユーサーバーデータベース322の許可テーブルをアップデートするようにユーサーバーモジュール324に促す許可変更通知を送信することができる。別の例として、加入者は、許可テーブルをアップデートしおよび／またはユーサーバーデータベース322の未決定のトランザクションログにトランザクションを記録するように、ユーサーバーモジュール324に促す情報アップデートを加入者に送信することができる。加入者は、ユーサーバーデータベース322のユーザーテーブルをアップデートし得る追加ユーザー要求を、送信することができてもできなくてもよい。加入者は、内部スキーマデータベースについての読み込みまたは書き込みを招き得るアカウント情報をアップデートすることができてもできなくてもよい。他のトランザクションは、ユーサーバートランザクションログ326の未決定のトランザクションにアクセスすることができるユーザー同期リクエスト(プル(pull))とユーザー同期リクエスト(プッシュ(push))とを具備してもよい。
【００３４】
オペレーションにおいて、ユーサーバーモジュール324は、加入者情報を受信し、それに応じてユーサーバーデータベース322をアップデートする。そして、ユーサーバーモジュール324は、クライアント110(図1)などのクライアントコンピュータと関連し得る加入者から、アップデートともしあれば関連する指示とを受信する。ユーサーバーデータベース322は、必要であれば、関連する指示に従って修正され、アップデートに関するデータは、ユーサーバートランザクションログ326に入力される。ユーサーバートランザクションログ326のエントリーは、アップデートを受信するための許可を具備するクライアント106(図1)などのクライアントに対するユーザー同期リクエストを促進するのに十分な情報を具備する。限定しない実施形態において、ユーサーバートランザクションログ326は、アップデートを受信することを許可されている各クライアントに対して1つのエントリーを具備する。別の実施形態では、ユーサーバートランザクションログ326は、トランザクションログエントリーと関連するアップデートを受信するための許可を有する各クライアントを識別するのに十分なデータを具備して、各アップデートに対して1つのエントリーを具備する。クライアントが、アップデートを受信する用意ができており、アップデートがユーサーバートランザクションログ326で表示されているとの信号を送る場合には、ユーサーバーモジュール324は、アップデートをクライアントに送信し、ユーサーバートランザクションログ326からエントリーを削除する(各トランザクションログエントリーが1つのクライアントと関連する実施形態を仮定する)。
【００３５】
図4は、本実施形態に係る図1のシステムと関連するフローチャート400を示す。本実施形態では、フローチャート400は、加入者がアドレスブックの個人情報をアップデートするブロック402で始まる。アドレスブックは、一例であって限定するものではないが、マッキントッシュ OS Xアドレスブック(Macintosh OS X address book)とすることができる。
【００３６】
本実施形態では、フローチャート400は、コンタクトがアップデートを確認することができるということを承認するために許可テーブルをユークライアントモジュールが検査するブロック404へ進む。許可テーブルは、ローカルに入手可能であってもなくてもよい。さらに、加入者は、「直ちに」許可を適合させてもさせなくてもよい。もちろん、加入者は、直ちに、アドレスブックをアップデートする前に、または、いくつかの他のポイントかどうかにかかわらず、いくつかのポイントで許可を適合させることができる。
【００３７】
本実施形態において、フローチャート400は、適切な場合にユークライアントが適切な指示を有するアップデートをユーサーバーに転送するブロック406へ進む。指示は、アップデートを送信する場合に適合してもしなくてみよい。例えば、ユーサーバーが追加の指示なしでアップデートを処理する方法を認識している場合には、前記追加の指示は必要ではない。代わりに、ユーサーバーは、一例であって限定するものではないが、アップデートの前に、ユーサーバーにおいて、加入者を識別する(そのような情報がアップデートから判断できない場合)または許可を変更する追加の手順を必要としてもよい。様々な実施形態において、アップデートは、複数のクライアントに対する1つのアップデートとして、または、複数のクライアント各々に対する1つのアップデートとして送信されてもよい。
【００３８】
本実施形態では、フローチャート400は、ユーサーバーが許可テーブルを検査するブロック408へ進む。この許可テーブルは、加入者に関連するクライアントにローカルな許可テーブルに類似しても或いは類似しなくてもよい。許可テーブルは、一例であって限定するものではないが、SQLテーブルであってもよい。
【００３９】
本実施形態では、フローチャート400は、ユーサーバーがトランザクションログにアップデートを格納するブロック410へ進む。ユーサーバーがトランザクションログにアップデートを格納する前に許可テーブルを検査する実施形態を仮定すると、トランザクションログの各エントリーは、アップデートを受信することができる1つのクライアントと関連してもよい。そのような実施形態では、クライアントがアップデートされていることをユーサーバーが認識している場合には、トランザクションログはエントリーを消去され得る。代わりの実施形態では、1つのアップデートは、アップデートを受信することを許可されている複数の関連するクライアントを具備してもよい。
【００４０】
本実施形態では、フローチャート400は、ユークライアントが、起動状態で且つアップデートを受信する用意ができていることについてユーサーバーに定期的に信号を送るブロック412へ進む。ユークライアントがしばらくの間ユーサーバーに信号を送らない場合には、ユーサーバーは、ユークライアントに対するアップデートに関連するエントリーをトランザクションログから消去しても或いはしなくてもよい。例えば、ユークライアントが1年間利用可能でない場合、トランザクションログは、古いアップデート情報を削除するためにアップデートされ得る。この方法においては、トランザクションログは、ログが扱いきれないほど大きくなることなく維持され得る。さらに、別の実施形態によれば、トランザクションログは、該トランザクションログが任意に大きなサイズになった場合に、エントリーを消去され得る。前記消去は、エントリーのタイム・スタンプ、および／または、他のファクターに基づいてもよい。さらに、第一アップデートと第二アップデートとが同じクライアントと関連する場合には、2つのアップデートが統合され得る。
【００４１】
本実施形態では、フローチャート400は、ユーサーバーがユークライアントにアップデートを送信するブロック414へ進む。本実施形態では、ユークライアントは、ユークライアントがアップデートを受信する用意ができていることをユーサーバーに通知し、それに応じて、ユーサーバーは、ユークライアントと関連するあらゆるアップデートを送信する。別の実施形態では、ユーサーバーは、ユークライアントに情報を転送しようと試みてもよく、該試みは、ユークライアントがアップデートを受信することができるかどうかに依存して成功しても或いはしなくてもよい。
【００４２】
本実施形態では、フローチャート400は、ユークライアントがローカルアドレスブックをアップデートするブロック416へ進む。ユークライアントがユーサーバーからアップデートを受信する場合、ユークライアントは、ローカルコンタクト情報をアップデートするための許可を有すると推定される。それに応じて、ユークライアントは、前記アップデートを用いてローカルアドレスブックをアップデートする。本実施形態では、ユークライアントに関連する加入者は、ユーサーバーからアップデートを受信すると、ユークライアントがローカルアドレスブックをアップデートすることを許可されていることを事前に示す。別の実施形態では、ユークライアントに関連する加入者は、ユークライアントがローカルアドレスブックをアップデートすることを許可するかどうかについてアップデートが入手可能となるたびに、問い合わせられてもよい。
【００４３】
図5Aおよび5Bは、前記システムに関連する実施形態とトランザクションとに係るシステム500を例示する。図5Aおよび5Bの例は、データベース同期システムのトランザクションの発生と消費とを示すことを意図している。これが、本実施形態に係るデータ同期システムをインプリメントする多くの方法のほんの1つであり、限定しない例としてのみ意図されていることに留意すべきである。他の実施形態は、より多くまたはより少なく、そして異なるトランザクションを具備してもよい。
【００４４】
システム500は、ユークライアントモジュール512とユーNIQエンジン524とを備える。図5Aに例において、ユークライアントモジュール512は、ミーエンジン526と、ユークライアントエンジン528と、アドレスブック514とを具備する。
【００４５】
本実施形態では、ユーNIQエンジン524は、許可設定を加入者に促進するGUIを具備する。前記許可設定は、加入者がいかなる情報を他のユーザーと共有するかをコントロールする。例えば、ユーザーが加入者のホームEメール情報を確認するための許可を有する場合、ユーザーは、許可が適切に設定されていれば、加入者のホームEメールの現行値を取得することとなる。さらに、別の実施形態では、ユーNIQエンジン524は、加入者が時間とともにホームEメールになすあらゆる変更の許可を有するユーザーに転送することができる。特に、ユーNIQエンジン524は、ユーザーのローカルアドレスブックの加入者の情報をアップデートすることを促進する。別の実施形態では、テンプレートおよび／またはデフォルトは、加入者セット個人フィールドを必要とせずに加入者による許可の設定を促進する。例えば、データベースは、フィールドと関連した情報を具備し、関連したフィールドのアップデートをなすためにテンプレートを用いることができる。
【００４６】
本実施形態では、ミー(me)エンジン526は、加入者のローカルマシン上の加入者のコンタクト情報にアップデートを検出する。前記ミーエンジン526は、サーバーにアップデートを送信し、そして、アップデートを受信するための許可と共に<pushData>トランザクションとしてアップデートをユーザーに次々に送信することができる。
【００４７】
本実施形態では、ユークライアントエンジン528は、ローカル許可キャッシュを処理し、ユーサーバーとユーNIQ(およびアドレスブック)との間の導管として作動する。別の実施形態では、ユーサーバーとクライアントデバイスとの間には通信ポイントが1つしかない。別の実施形態では、加入者がユーサーバーコンポーネントに関連するソフトウェアをインストールする場合と、ユーインストールウィザード222（図2）などのウィザードが加入者のためのシステム500を構成するためにサーバーと通信する場合とにのみ、前記1つの通信ポイントモデルが破壊される。
【００４８】
本実施形態では、ユークライアントエンジン528は、また、サーバーからの<pushData>トランザクションを処理し、ユーザーのアドレスブック514をアップデートする。例えば、ユーザーがユーザーのアドレスブックの加入者のレコードへの加入者アクセスを取得した場合、ユーザーのクライアントデバイスのユークライアントエンジン528は、加入者がローカル情報をアップデートする際に、ユーザーのアドレスブックの加入者のレコードをアップデートすることができる。概念的に、加入者がユーザーによって許可を与えられている場合には、加入者は、加入者に関連するデータを変更するためにユーザーのアドレスブックに達することができる。
【００４９】
前記システム500は、ユーサービスdB532(YouService dB532)と、ユーサーバーモジュール534と、トランザクションログ536とを具備する。ユーサービスdB532は、複数のデータベース、テーブル、および／またはレコードを具備し得る。限定しない実施形態に係るユーサービスdB532の例は、図6に関連して以下で説明される。ユーサーバーモジュール534は、ユーサーバーdBエンジン552とユーサーバーログエンジン554とを具備し得る。限定しない実施形態では、ユーサーバーdBエンジン552は、ユーサービスdB532に読み取り／書き込みするトランザクションを処理する。限定しない実施形態では、ユーサーバーログエンジン554は、以下で例示され、<pushData>を具備することができるトランザクションログ−タイプトランザクション全てを処理する。トランザクションログ536は、サーバーの故障を通してさえ、未決定のトランザクションを維持するようにデザインされ得る。
【００５０】
ここで用いられるようなエンジンは、プラットフォームとアーキテクチャ上の決定と選択とに依存して、プロセス、スレッド、クラス、機能、方法、モジュール、プログラム、ファイル、および／またはこれらのうちのいくつかの組み合わせを参照することができることに留意すべきである。他のコンポーネントは、様々な実施形態において用いられ得る。例えば、ブローカーコンポーネント(図示しない)は、受信したトランザクションを取得し、ユーサーバーdBエンジン552またはユーサーバーログエンジン554にそれらをハンドオフする(渡す)ことができる。
【００５１】
以下のシステム500の説明において、トランザクション参照数字は、XXX-1およびXXX-2として表され、XXX-1がトランザクションが作成される場所を示し、XXX-2がトランザクションが消費される場所を示す。トランザクションは、作成と消費との位置に関係なく、トランザクションXXXと称され得る。
【００５２】
図5Aの例において、ユーNIQエンジン524は、加入者にGUIを供給することについて関与する。加入者は、他のユーザーがコンタクト情報などの加入者に関連する情報を確認することを可能にする許可を設定することができる。ユーNIQエンジン524GUIを用いている加入者が適切なボタンをクリックする(または、他の動作を実行する)と、ユーNIQエンジン524は、<setPermissions>トランザクション570-1を作成し、ユークライアントエンジン528を通してトランザクション570をユーサーバー534のユーサーバーdBエンジン552に送信する。
【００５３】
ユーサービスdBエンジン552は、<setPermissions>トランザクション570-2を消費し、ユーサーバーdB532の許可テーブルに新しいまたはアップデートされた許可を格納する。ユーサービスdBエンジン552が無事にユーサーバーdB532に前記許可を格納すると、ユーサービスdBエンジン552は、<pFileRefresh>トランザクション571-1を作成し、ユークライアントエンジン528を通してトランザクション571をユーNIQエンジン524に送信する。
【００５４】
ユーNIQエンジン524は、<pFileRefresh>トランザクション571-2を消費し、ローカル許可キャッシュをアップデートする。限定しない実施形態では、前記ローカル許可キャッシュはファイルであるが、そうである必要はない。さらに、いくつかのクライアントのために、ローカル許可キャッシュが存在さえしなくてもよく、この場合、クライアントはそれ自身の許可テーブルをサーバーに要求する必要があり得る。
【００５５】
図5Aの例では、前記ミーエンジン526は、加入者の『ミー(me)』レコード のフィールドを観察することに関与する。‘ミー(me)’レコードのフィールドの例は、図6に関連して以下でより詳細に説明される。前記ミーエンジン526が『ミー(me)』レコード のフィールドについての変更を検出すると、ミーエンジン526は、<setData>トランザクション572-1を作成する。本実施形態では、ミーエンジン526は、加入者が別のユーザー（または、複数のユーザー）がアップデートされたフィールドを確認するための許可を取得した場合に、<setData>トランザクション572-1を作成するのみである。
【００５６】
図5Aの例では、<setData>トランザクション572-1を作成した後（または、大体同じ時間）に、ミーエンジン526は、<setDataChk>トランザクション573-1を作成する。前記<setDataChk>トランザクション573は、任意の長さの時間間隔に関連する。<setData>トランザクション571が成功したという指示をミーエンジン526が受信すると、前記<setDataChk>トランザクション573は、『タイムアウトする』。一方、<setData>トランザクション571が成功したという指示が全く受信されない場合には、前記ミーエンジンは、本実施形態では、新しい<setData>トランザクション571を作成する、或いは、前記ユークライアント512は、新しい<setData>トランザクション571が作成されるべきかその他であるかどうかを判断するために、所定の他の動作を実行する場合もある。
【００５７】
前記ミーエンジン526が<setData>トランザクション572-1を作成すると仮定すると、トランザクション572は、アップデートと関連するデータとともにユークライアントエンジン528を介してユーサーバー534に転送される。図5Bの例において、サーバーdBエンジン552は、<setData>トランザクション572-2を消費することと、<setData>トランザクション572と関連するデータを利用しているユーサービスdB532をアップデートすることとに関与する。アップデートが成功すると、サーバーdBエンジン552は、<setDataOK>トランザクション574-1を作成すると共にユークライアントエンジン528に<setDataOK>トランザクションを返送し、<setDataOK>トランザクション574をミーエンジン526に転送し、<setDataChk>トランザクション573-2は、消費されて終了またはタイムアウトされる。
【００５８】
ユークライアント512は、アップデートされたデータを送信し、アップデートされたデータがサーバーで受信されて記録されていることについて判断する。本実施形態においては、サーバーは、クライアントへの成功または不成功の配信に続いて、ユークライアント512に追加情報を送信することができることに留意すべきである。
【００５９】
図5Bの例において、本実施形態のユーサーバーdBエンジン552は、ユーサーバーdBエンジン552が<setData>トランザクション572-2を消費した後に、誰がトランザクション572と関連するアップデートを受信することを許可されるかを判断するために、ユーサーバーdB532の許可テーブルを参考にする。そして、許可データを利用して、ユーサーバーdBエンジン552は、1つ以上の<pushData>トランザクション575-1を作成し、トランザクション575をユーサーバーログエンジン554に送信する。本実施形態では、ユーサーバーdBエンジン552は、アップデートを受信するための許可を有する各クライアントに対して1つの<pushData>トランザクション575-1を作成する。例えば、加入者が10人の人々にアップデートの受信を許可する場合、ユーサーバーdBエンジン552は、10回の<pushData>トランザクション575-1を作成してもよい。
【００６０】
ユーサーバーログエンジン554は、トランザクションログ536のエントリーとして<pushData>トランザクション575と関連するデータを記録する。限定しない実施形態においては、トランザクションログ536のかかる各々のエントリーは、関連したアップデートの受信許可を有する異なるクライアントと関連する。
【００６１】
図5Bの例において、<pushData>トランザクション575と関連するアップデートデータをユーサーバーログエンジン554が記録するのとほぼ同じ時間で、ユーサーバーログエンジン554は、<pushDataChk>トランザクション574-1を作成し、トランザクション574を自身に送信する。ユーサーバーログエンジン554がクライアントへのデータの配信の成功という情報を受信すると、<pushDataChk>トランザクション576が終了またはタイムアウトするということを除いて、<pushDataChk>トランザクション576は、上述した<setDataChk>トランザクション573に類似している。概念的に、ユーサーバーログエンジン554は、それが<pushData>トランザクションを受信したとのクライアントからの返信を待つと共に確認したので、クライアントに<pushData>トランザクションのみを行うということを自身に告げる。クライアントが返信しない場合には、ユーサーバーログエンジン554は、それを記録しても或いはしなくてもよい。ユーサーバーログエンジン554がファイアウォールの背後にある実施形態においては、上述のインプリメンテーションは様々な形態で作動する。しかし、<pushDataChk>トランザクション576は、ユーサーバー534が、クライアントへ単に返信するのとは対照的に、積極的にデータを配信しない限り、特に有益でない場合があることに留意すべきである。ファイアウォールについての当業者には承知されているように、サーバーは、サーバーがクライアントからファイアウォールによって分離される場合に、クライアント要請に応答することができるだけであってもよい。それに応じて、本実施形態では、<pushDataChk>トランザクション576は、サーバーとクライアントとの双方が組織のファイアウォールの背後に配備される場合に、一般に利用されるであろう。ミーエンジン526は、ユーサーバーログエンジン554によって消費され得る上述した<pushDataChk>トランザクション576-1も作成し得るということに留意すべきである。
【００６２】
図5Aの例において、ユークライアントエンジン530は、クライアントに対する未決定の<pushData>トランザクション575がある場合に、ユーサーバー534に要求するための<awake>トランザクション577-1を作成する。
【００６３】
図5Bの例において、クライアントに対する未決定の<pushData>トランザクション575が全くない場合には、ユーサーバーログエンジン554は、<awakeOK>トランザクション578-1を作成する。<awakeOK>トランザクション578は、クライアントがアップデートを受信する準備ができているとサーバーが認識していることを表示するけれども、供給すべきものは有していない。
【００６４】
図5Aの例において、ユークライアントエンジン528は、<awakeOK>トランザクション578-2を消費し、所定期間後に、別の<awake>トランザクション577-1を作成する。これは、未決定の<pushData>トランザクション575が入手可能になるまで続けられる。ユークライアントエンジン528が加入者以外のユーザーと恐らく関連するということに留意することは有益である場合がある。従って、上述の(および最初のアップデートと関連した)<setData>トランザクション572-1は、最初のアップデートと関連する<pushData>トランザクション575-2を消費するクライアントとは異なるクライアントにて恐らく作成されることとなる。簡単に言うと、クライアントがそれ自身のアップデートを消費することは特に有利なことではない。
【００６５】
図5Bの例において、クライアントに対する未決定の<pushData>トランザクション575がある場合、ユーサーバーログエンジン554は、<awake>トランザクション577に応じて<pushData>トランザクション575をクライアントに発送する。<awake>トランザクションを具備しない実施形態においては、ユーサーバーログエンジン554は、それが入手可能になった場合に<pushData>トランザクション575を発送するだけであってもよい。
【００６６】
図5Aの例において、ユークライアントエンジン528は、<pushData>トランザクション575と関連するデータをアドレスブック514に配信する。アップデートが成功している場合、ユークライアントエンジン528は、<pushDataOK>トランザクション579-1を作成しユーサーバー534に送信する。
【００６７】
図5Bの例において、ユーサーバーログエンジン554は、<pushDataChk>トランザクション576-2を無事に終了させる。このことは、データがクライアントに無事に配信されたことをサーバーが認識しているということを意味している。ユーサーバーログエンジン554は、関連する<pushData>トランザクション575をトランザクションログ536から消去してもよい。一般に、ユーサーバー534は、<setData>トランザクション572と関連するデータが同様にクライアントに無事に配信されていることをユークライアントエンジン530に知らせる。
【００６８】
本実施形態によると、図6は、ユーサーバーdB532(図5)などのデータベースに具備され得るテーブルのいくつかの例を示す。テーブルは、ユーザーテーブル602とフィールドテーブル604と許可テーブル606と未決定トランザクションログ608とを具備する。
【００６９】
図6の例においては、ユーザーテーブル602は、フィールドUIDと接続情報とを具備する。UIDは加入者を識別することができ、接続情報は、一例であって限定するものではないが、ip/ポート(port)数を識別することができる。加入者が追加されると、エントリーがユーザーテーブル602に追加されてもよい。同様に、加入者が除外されると、ユーザーテーブル602のエントリーが削除されてもよく、内部スキーマが、一例であって限定するものではないが、要求している目的のためにユーザーテーブル602にアクセスしてもよい。
【００７０】
図6の例において、フィールドテーブル604は、FIDフィールドとフィールド名とを具備する。FIDフィールドは、多数または他の識別スキームによってフィールドを識別する。フィールド名は、一例であって限定するものではないがvCard規格などの規格と関連するフィールドを識別する。
【００７１】
図6の例において、許可テーブル606は、授与者UIDとFIDと被授与者UIDとのフィールドを具備する。授与者UIDは、被授与者UIDフィールドで識別されたユーザーがFIDフィールドにて識別したフィールドにアクセスする許可を与えている加入者を識別する。許可テーブル606は、許可変更通知とユーザーデータ変更とに従って変更されてもよい。
【００７２】
図6の例において、未決定トランザクションログ608は、授与者UIDと被授与者UIDとプッシュ／プル(push/pull)とFIDと値とのフィールドを具備する。授与者UIDは、FIDフィールドによって識別されたフィールドを値フィールドで表示された値に変更した加入者を識別する。アップデートは、プッシュ／プルフィールドで示されるように、プッシュまたはプルベースに関する被授与者UIDフィールドで識別されたユーザーに利用可能である。ユーザーデータ変更は、未決定トランザクションログ608の追加のレコードをもたらす。プルトランザクション検査と関連するユーザー同期リクエストは、未決定トランザクションログ608がプルトランザクションの要求と関連する被授与者UIDのために検査され、適合がある場合にデータが供給される。一方、プッシュトランザクションは、未決定トランザクションログ608から適切な被授与者へデータを配信する。
【００７３】
ユーサービスは、トラフィックとアップデートとを管理するための無料のプロセッササイクルを利用するためのグリッドコンピューティング技術を利用したピアツーピア通信技術に基づいている。本出願のドラフティング時では、サービスプラグイン(service plugin)は、マックOS Xメーラー(Mac OS X Mailer)やロータスドミノクライアント(Lotus Domino client)、ネットスケープメール(Netscape Mail)と同様に、マイクロソフトアウトルック(Microsoft Outlook)2002，2002/XPおよびマイクロソフトアウトルックエクスプレス(Microsoft Outlook Express)向けに開発されている。また、ユーサービスクライアントは、マイクロソフトウWindows (Microsoft Windows) 98，ME，2000，NT，またはXPとマックOS 9，Xとリナックス(Linux)とにジャバクライアント(Java client)を具備するであろう。
【００７４】
ここに説明されるようにアップデートされ得る個人的なプロフィールは、例であって限定するものではないが、名前、重要な記念日、住所、勤め先住所、自宅の電話番号、家庭のファックス、携帯電話、ビジネス電話、ビジネスファックス、個人的なEメール、ビジネスEメール、好きなチャリティ活動、希望リスト、衣類サイズ、好きな色、好きなワイン、好きな食物など多種多様なデータフィールドを具備することができる。各フィールドは、公的または複数のユーザーに開放している、秘密であるように設定することができる。例えば、自己専門の窓口すべてに自己の携帯電話を利用可能とすることもでき、或いは、自己の希望リストへのアクセスを自己の配偶者にのみ許可することもできる。さらに、フィールドは、個人またはビジネスなどのカテゴリーにまとめられ得、そして、ユーザーは、例えばそれらが個人またはビジネスの窓口として指定されるかどうかに基づいたアクセスを許可され得る。
【００７５】
図7Aおよび7Bについての以下の説明は、ここに説明する本発明にかかる方法を実行するのに適したコンピュータハードウェアと他の動作コンポーネントとの概要を示すことを意図しているが、適用可能な環境を限定することを意図していない。同様に、コンピュータハードウェアと他の動作コンポーネントとは、ここに説明される本発明にかかる装置の一部として適していてもよい。本発明は、携帯デバイスと、マルチプロセッサシステムと、マイクロプロセッサーベースまたはプログラム化可能な家電製品と、ネットワークPCと、小型コンピュータと、大型コンピュータと、ワイアレスデバイスと、これらと同様のものとを具備する他のコンピュータシステム構成によって実施され得る。また、本発明は、通信ネットワークを介してリンクされる遠隔処理デバイスによってタスクが実行される分散コンピューティング環境において実施され得る。
【００７６】
図7Aは、個人の属性についての分散管理フレームワークがインプリメントされ得るシステムを示す。図7Aは、インターネットなどのネットワーク702を介して接続された複数のコンピュータシステムを具備するネットワーク化されたシステム700を示す。ここで用いられる「インターネット」の文言は、TCP/IPプロトコルなどの所定のプロトコルと、場合によっては、ワールドワイドウェブ(ウェブ)を形成するハイパーテキスト・マークアップ言語(HTML)文書についてのハイパーテキスト転送プロトコル(HTTP)などの他のプロトコルとを利用するネットワークのネットワークを参照する。インターネットおよびプロトコルの物理的接続と、インターネットの通信手順とは、当業者に公知である。
【００７７】
ウェブサーバー704は、一般に、サーバーコンピュータシステムとして動作する少なくとも1つのコンピュータシステムであり、ワールドワイドウェブのプロトコルによって動作するように設定され、インターネットに接続される。ウェブサーバーシステム704は、従来のサーバーコンピュータシステムであってもよい。ウェブサーバー704は、任意で、クライアントシステムのインターネットへのアクセスを形成するISPの一部とすることができる。ウェブサーバー704は、ウェブコンテンツ708に接続されているサーバーコンピュータシステム706に接続されており、メディアデータベースのフォームと考えることができる。図7Aには2つのコンピュータシステム704と706とが示されているものの、ウェブサーバーシステム704とサーバーコンピュータシステム706とは、ウェブサーバー機能を形成する異なるソフトウェアコンポーネントと、サーバーコンピュータシステム706によって形成されるサーバー機能とを具備する1つのコンピュータシステムであってもよく、それについては以下で説明する。
【００７８】
ネットワーク702へのアクセスは、一般にISP710および716などのインターネットサービスプロバイダー(ISP)によって形成される。クライアントコンピュータシステム712や718、722、726などのクライアントシステム上のユーザーは、ISP710および716を介してインターネットへアクセスしている。インターネットへのアクセスは、クライアントコンピュータシステムのユーザーが、情報を交換し、電子メールを送受信し、HTMLフォーマットで作成されている文書などの文書を表示することを可能にする。これらの文書は、ウェブサーバー704などのウェブサーバーによって供給され、インターネット「上」にあると言われる。大抵、これらのウェブサーバーは、コンピュータシステムが、ISPであるそのシステムなしで設定されてインターネットに接続され得るけれども、ISP710などのISPによって形成される。
【００７９】
クライアントコンピュータシステム712、718、722、726は、それぞれ、適切なウェブブラウズソフトウェアによって、ウェブサーバー704によって提供されたHTMLページを表示することができる。ISP710は、モデムインタフェース714を介してクライアントコンピュータシステム712にインターネット接続を形成し、クライアントコンピュータシステム712の一部と考えることができる。クライアントコンピュータシステムは、パーソナル・コンピュータ・システムやネットワーク・コンピュータ、ウェブテレビシステム、他のコンピュータシステムとすることができる。図7Aには「モデム」として総称的にモデムインタフェース714が示されているものの、インタフェースは、アナログモデムやisdnモデム、ケーブル・モデム、衛星送信インタフェース(例えば「ダイレクトPC」)、コンピュータシステムを他のコンピュータシステムに接続するための他のインタフェースであってもよい。
【００８０】
ISP714と同様に、ISP716は、クライアントシステム718、722、726のインターネット接続を形成しているが、図7Aに例示するように、当該接続は、これら3つのコンピュータシステムと同じではない。クライアントコンピュータシステム718は、モデムインタフェース720を介して接続されている一方で、クライアントコンピュータシステム722および726は、LAN730の一部である。
【００８１】
クライアントコンピュータシステム722および726は、ネットワークインタフェース724および728を介してLAN730に接続されており、イーサーネットネットワークまたは他のネットワークインタフェースであってもよい。また、LAN730は、ローカルエリアネットワークに対してファイアウォールと他のインターネット関連サービスとを提供することができるゲートウェイコンピュータシステム732に接続されている。このゲートウェイコンピュータシステム732は、クライアントコンピュータシステム722および726へのインターネット接続を形成するためにISP716に接続されている。ゲートウェイコンピュータシステム732は、従来のサーバーコンピュータシステムであってもよい。
【００８２】
代わりに、サーバーコンピュータシステム734は、ゲートウェイシステム732を介してインターネットに接続する必要なく、クライアント722および726にファイル738と他のサービスとを提供するべくネットワークインタフェース736を介してLAN730に直接接続されてもよい。
【００８３】
図7Bは、システム700(図7A)で利用するためのコンピュータシステム740を示す。コンピュータシステム740は、クライアントコンピュータシステムまたはサーバーコンピュータシステムとして、若しくはウェブサーバーシステムとして利用することができる従来のコンピュータシステムであってもよい。そのようなコンピュータシステムは、ISP710(図7A)などのインターネットサービスプロバイダーの機能の多くを実行するのに用いられる。
【００８４】
図7Bの例において、コンピュータシステム740は、コンピュータ742と、I／Oデバイス744と、ディスプレイデバイス746とを具備する。コンピュータ742は、プロセッサ748と、通信インタフェース750と、メモリー752と、ディスプレイコントローラ754と、不揮発性記憶装置756と、I／Oコントローラ758とを具備する。コンピュータシステム740は、I／O デバイス744とディスプレイデバイス746とを接続する、または、具備することができる。
【００８５】
コンピュータ742は、モデムまたはネットワークインタフェースを具備する通信インタフェース750を介して外部システムにインタフェースで接続する。通信インタフェース750が、コンピュータシステム740の一部またはコンピュータ742の一部であると考えられ得ることは高く評価される。通信インタフェースは、アナログモデムまたはISDNモデム、ケーブル・モデム、トークンリングインタフェース、衛星送信インタフェース(例えば「ダイレクトPC」)、他のコンピュータシステムにコンピュータシステムを接続するための他のインタフェースであってもよい。
【００８６】
プロセッサ748は、例えば、インテルペンティアムマイクロプロセッサーまたはモトローラパワーPCマイクロプロセッサーなどの従来のマイクロプロセッサーであってもよい。メモリー752はプロセッサ748にバス760で接続されている。メモリー752は、ダイナミックRAM(DRAM)であってもよく、また、スタティックRAM(SRAM)を具備してもよい。バス760は、プロセッサ748を、メモリー752と、不揮発性記憶装置756と、ディスプレイコントローラ754と、I／Oコントローラ758とに接続している。
【００８７】
I／Oデバイス744は、マウスまたは他のポインティングデバイスを含めて、キーボードと、ディスクドライブと、プリンタと、スキャナと、他の入力および出力デバイスとを具備し得る。ディスプレイコントローラ754は、ディスプレイデバイス746上のディスプレイ、例えばブラウン管(CRT)または液晶ディスプレイ(LCD)を従来の方法でコントロールすることができる。ディスプレイコントローラ754とI／Oコントローラ758とは、従来より公知の技術によってインプリメントされ得る。
【００８８】
不揮発性記憶装置756は、大抵、磁気ハードディスクや光ディスク、大量のデータ用のストレージについての別の形式である。このデータのいくつかは、コンピュータ742のソフトウェアの実行の間に、ダイレクトメモリーアクセスプロセスによって、メモリー752に大抵書き込まれる。当業者は、「機械可読メディア」または「コンピュータ可読メディア」の文言が、プロセッサ748によってアクセス可能なあらゆるタイプの記憶装置を含み、また、データ信号をエンコードする搬送波を含むことをすぐに認識するであろう。
【００８９】
オブジェクトと、方法と、インラインキャッシュと、キャッシュ状況と、他のオブジェクト指向コンポーネントとは、不揮発性記憶装置756に格納されてもよく、または、例えばオブジェクト指向ソフトウェアプログラムを実行している間にメモリー752に書き込まれてもよい。この方法では、例えば図1乃至6で説明されたコンポーネントは、コンピュータシステム740上でインスタンスを作成することができる。
【００９０】
コンピュータシステム740は、異なるアーキテクチャを有する多くの可能なコンピュータシステムのうちの1例である。例えば、インテルマイクロプロセッサーに基づくパーソナル・コンピュータは、多重バスを大抵有しており、そのうちの一つは、周辺装置のI／Oバスと、プロセッサ748およびメモリー752を直接接続するもの(大抵メモリーバスと称される)とすることができる。バスは、異なるバスプロトコルのために、いかなる必要な翻訳でも実行するブリッジコンポーネントを介して一緒に接続されている。
【００９１】
ネットワーク・コンピュータは、本発明に利用され得る別のタイプのコンピュータシステムである。ネットワーク・コンピュータは、通常、ハードディスクまたは他の大容量記憶装置を具備せず、実行可能なプログラムは、プロセッサ748によって実行すべくネットワーク接続からメモリー752にロードされる。また、技術分野において知られているWebテレビシステムは、本発明に従えば、コンピュータシステムであると考えられるが、所定の入力または出力デバイスなどの図7Bに示される機能のうちのいくつかを欠いていてもよい。典型的なコンピュータシステムは、通常、少なくともプロセッサと、メモリーと、プロセッサにメモリーを接続しているバスとを具備する。
【００９２】
さらに、コンピュータシステム740は、ディスク・オペレーティングシステムなどのオペレーティングシステムソフトウェアの一部であるファイル管理システムを具備するオペレーティングシステムソフトウェアによってコントロールされる。関連するファイル管理システムソフトウェアを有するオペレーティングシステムソフトウェアの一例は、ワシントン州レドモンドのマイクロソフト社製のWindowsとして知られているオペレーティングシステムとそれらの関連するファイル管理システムとのファミリーである。関連するファイル管理システムソフトウェアを有するオペレーティングシステムソフトウェアの別の例は、Linuxオペレーティングシステムとその関連するファイル管理システムとである。ファイル管理システムは、一般に不揮発性記憶装置756に格納され、プロセッサ748に、データを入力および出力するためのオペレーティングシステムに必要とされている様々な行為を実行させ、不揮発性記憶装置756のファイルを保存することを含めてメモリーにデータを保存させる。
【００９３】
図8A乃至8Fは、個人属性の分散管理可能なシステムのコンポーネントの例を示す。図8A乃至8Fに例示されるコンポーネントは、図1に示されるシステムなどの1つのシステムに結合され得、図8A乃至8Fのサブセットが利用され得る。クライアントについての代わりの構成などの他のコンポーネントは、すべてを含むシステムまたは図8A乃至8Fに示されるコンポーネントのサブセットに具備され得る。多くの構成があるので、すべての可能なクライアント構成の完全なリストは、試みられているわけではないが、当業者は、提供された6つの限定しない例を用いて、選択肢がありそうであるということと、あらゆる公知のまたは便利な構成でも利用することができるということとを認識するべきである。
【００９４】
図8Aはシステム800Aの例を示す。該システム800Aはネットワーク804とクライアント810とを具備する。クライアント810は、クライアント通信サービス812と、アドレスブック814と、同期モジュール818と、モバイル機器808-1乃至808-N(以下、モバイル機器808)とを具備する。図8Aは、クライアント810が、例であって限定するものではないが、アドレスブック814の個人属性を有することができるということと、クライアント810が1つ以上のモバイル機器808を個人属性と同期させることができるということとを説明することを目的としている。クライアント通信サービス812は、ポーリングサービスまたは他のプッシュ-プルモデルサービスを具備してもよい。
【００９５】
図8Bはシステム800Bの例を示す。該システム800Bはネットワーク804とクライアント810とを具備する。クライアント810は、クライアント通信サービス812と、アドレスブック814と、アドレスブックプラグイン816とを具備する。図8Bは、例であって限定するものではないが、アドレスブック814の個人属性がプラグイン816を介してアクセス可能であってもよいということを説明することを目的としている。
【００９６】
図8Cはシステム800Cの例を示す。該システム800Cはネットワーク804とクライアント810とを具備する。クライアント810は、クライアント通信サービス812と、アドレスブック814と、モバイル機器808とを具備する。図8Cには一例のみが示されているが、クライアント810は任意の数のモバイル機器を具備することが可能である。図8 Cは、クライアント810が、ネットワーク804を介して個人属性に接続されるモバイル機器を具備してもよいということを説明することを目的としている。
【００９７】
図8Dはシステム800Dの例を示す。該システム800Dはネットワーク804とクライアント810とを具備する。クライアント810は、クライアント通信サービス812と、アドレスブック814と、ウェブベースメール/アドレスブックインタフェース820と、PARデータベース822とを具備する。ウェブベースメール/アドレスブックインタフェース820は、ユーザーのコミュニティのためのインタフェースの多数であってもよい。図8Dは、クライアント810が、ネットワーク804を介してクライアント通信サービス812に接続されるウェブベースメール/アドレスブックインタフェースを具備してもよいということを説明することを目的としている。システム810の例は、例であって限定するものではないが、モジラと、ネットスケープ8と、サンダーバードとを具備する。
【００９８】
図8Eはシステム800Eの例を示す。該システム800Eは、ネットワーク804と、クライアント810と、サーバー824とを具備する。クライアント810は、ウェブベースメール/アドレスブックサーバー803と、ウェブベースクライアントサービス805と、ウェブベースメール/アドレスブックインタフェース820と、ウェブベースクライアント(PAR)データベース841と、バックエンドメールおよびアドレスブックデータベース842とを具備する。図8Eは、クライアント810が、ウェブベースメール/アドレスブックサーバーを具備してもよいということと、クライアントサービスがウェブベースであってもよいということとを説明することを目的としている。図8Eの例ではPARデータベース841が具備されているが、システム800Eは、PIMデータベースを具備し得るということに留意されるべきである。
【００９９】
図8Fはシステム800Fの例を示す。該システム800Fは、サービスプロバイダー802と、ネットワーク804と、クライアント810と、サーバー824と、サービスプロバイダー826と、サーバー830とを具備する。クライアント810はウェブベースメール/アドレスブックユーザー820を具備する。サーバー824は、ウェブベースメール/アドレスブックサーバー803と、ウェブベースクライアントサービス805と、バックエンドメールおよびアドレスブックデータベース842とを具備する。サーバー830は、接続サーバー832とウェブベースクライアント(PAR)データベース841とを具備する。サービスプロバイダー826は、サーバー824をネットワーク804へ接続する。サービスプロバイダー802は、サーバー830をネットワーク804へ接続する。図8Fは、ウェブベースクライアント(PAR)データベース841(図8E)がサービスプロバイダー802(図8F)を介してクライアント810に接続され得るということを説明することを目的としている。図8Fの例ではPARデータベース841を具備しているが、システム800Fは、PIMデータベースを具備することができるということには留意されるべきである。代案においては、PARデータベース841は分配され得る(例えば、PARデータベースの部分は、サーバー824上にあってもよい)。
【０１００】
図9は個人属性の分配管理のためのシステム900を示す。図9の例においては、システム900は、サーバー902と、ネットワーク904と、クライアント910とを具備する。サーバー902は通信APIを具備してもよい。APIは、論理グループ、例えば、セットアップと許可と認証と個人属性と通信とモバイル機器とユーザーとエラーとに分類されてもよい。APIは、図10および11を参照して後述される。
【０１０１】
図9の例では、ネットワーク904はサーバー902をクライアント910へ接続する。図9の例では、クライアント910は、クライアント通信サービスモジュール912と、クライアントUIモジュール914と、インストーラモジュール916と、PARデータベース918と、トランザクションヒストリーデータベース920と、PIM922とを具備する。クライアント通信サービスモジュール912は、任意のPIMプラグイン924を具備してもしなくてもよい。インストーラモジュール916は、アウトルック931、マックアドレスブック932、パームデスクトップ933、モトローラモバイル934など(説明のためだけに示される)のための任意のPIMプラグイン930を具備してもしなくてもよい。図9では1つのPIMのみ示されているが、アドレスブックまたは他のデータベースなどの複数のPIMは、別の実施形態でのクライアント910において見られ得る。
【０１０２】
図10は、図9のシステムと関連するエンジンとトランザクションとの概念図1000を示す。図10の例では、概念図1000は、セットアップエンジン1010と、許可エンジン1020と、認証エンジン1030と、個人属性エンジン1050と、モバイル機器エンジン1060と、通信エンジン1070と、ユーザーエンジン1080とを具備する。以下で説明される実施形態では、エンジンはAPIを用いている。しかし、あらゆる公知のまたは便利なインプリメンテーションでも十分であろう。トランザクションの例は、エンジンと関連しており、図11を参照して説明される。
【０１０３】
図11は、図9のシステムのデータベースに具備され得るテーブルについてのいくつかの例1100を示す。テーブルの例1100は、ユーザーテーブル1102と、フィールドテーブル1104と、デバイステーブル1106と、許可テーブル1108と、同期テーブル1110と、接続テーブル1112と、トランザクションテーブル1114とを具備する。
【０１０４】
再び図10を参照して、トランザクションについての4つの例がセットアップエンジン1010と関連している：ユーザーAPI1012を作成し、既存のユーザーAPI1014に宛先を追加し、既存のユーザーAPI1016にモバイル宛先を追加し、そして、ログインAPI1018を確認する。作成したユーザーAPI1012は、例であって限定するものではないが、ユーザーネームやパスワード、ファーストネーム、ラストネーム、Eメールなどの複数のパラメータを有してもよい。このAPIは、ユーザーテーブル1102のエントリーをもたらしてもよい。既存のユーザーAPI1014へ追加された宛先は、例であって限定するものではないが、ユーザーネームやパスワード、宛先タイプ(destinationtype) (物理的なデバイスまたは論理的なデバイスであってもよい)、宛先名(destinationname)などのパラメータを有してもよい。このAPIは、デバイステーブル1106のエントリーをもたらしてもよい。既存のユーザーAPI1016へ追加されたモバイル宛先は、例であって限定するものではないが、ユーザーネームやパスワード、宛先タイプ、宛先名などのパラメータを有してもよい。このAPIは、デバイステーブル1106のエントリーをもたらしてもよい。確認されたログインAPI1018は、例であって限定するものではないが、ユーザーネームやパスワードなどのパラメータを有してもよい。
【０１０５】
図10の例では、トランザクションについての3つの例は、許可エンジン1020と関連している：許可API1022と、アップデート許可API1024と、リクエスト同期API1026とを取得する。APIについてのこのグループは、ユーザーの許可の管理を行う。許可は、他のユーザーとのデータの共有を許可または却下する。取得された許可API1022は、ユーザーid(uid)とデバイスidパラメータとを有してもよく、0..n個の許可アイテムを有する結果を返信してもよい。これらの許可アイテムは、許可テーブル1108から取り出され得る。アップデート許可API1024は、uidとデバイスidと被授与者id(gid)とパーム[フィールド]と値[フィールド]とのパラメータを具備してもよい。パーム[フィールド]は、許可が与えられている場合には、‘1’という値を有し、許可が与えられていない場合には、‘0’という値を有する。このAPIは、許可テーブル1108にエントリーをもたらすべきである。‘0’または‘1’以外の許可についての複数のレベルがあり得るということに留意すべきである。あらゆる与えられたインプリメンテーションにおいて、許可レベルのあらゆる便利な数が利用され得る。リクエスト同期API1026は、uidとデバイスidパラメータとを有してもよい。このAPIは、共有データのフルセットを有しなくてもよい宛先にデータを同期させるやめに利用されてもよい。サーバーはデータをどこから取得するか処理し、結果は新しい宛先に渡される。
【０１０６】
図10の例では、トランザクションの5つの例は、認証エンジン1030と関連している：結合API1032を追加し、承認API1034を確認し、拒否API1036を確認し、結合API1038を確認し、結合API1040を拒否する。APIのこのグループはユーザー結合の管理を行う。追加された結合API1032は、uidとデバイスidとグループID(gid)とのパラメータを有してもよい。このAPIの結果は、接続テーブル1112のエントリーである。確認された承認API1034と、確認された拒否API1036と、確認された結合API1038と、否定された結合API1040とは、uidとデバイスidとgidとのパラメータを有してもよく、予測可能な結果を有してもよい。
【０１０７】
図10の例では、トランザクションについての3つの例は、個人属性エンジン1050と関連する：宛先保存変更API1052と確認宛先保存変更API1054とリクエストPARデータAPI1056とである。コマンドのこのグループは、ユーザーのデータ値の管理を行う。これらは、いわゆる個人属性レコード(PAR)の中に存在する。宛先保存変更API1052は、uidとデバイスidと値[フィールドid]とのパラメータを有してもよい。本実施形態では、[フィールドid]データの複数のセットは、パラメータのシングルセットでサーバーに渡されてもよい。サーバーは、トランザクションテーブル1114に対するエントリーを作成することが可能であるべきである。確認宛先変更API1054は、uidとデバイスidとのパラメータを有してもよく、予測可能な結果を有してもよい。PARデータAPI1056に対するリクエストは、uidとデバイスidとフィールド[フィールドid]とのパラメータを有してもよい。本実施形態では、[フィールドid]データの複数セットは、パラメータのシングルセットで渡されてもよい。さらに、[フィールドid]のセットがまったく渡されない場合には、サーバーは全てのフィールドへのリクエストを開始してもよい。このAPIは、トランザクションテーブル1114のエントリーをもたらしてもよい。有利なことに、サーバーは、PIMまたは宛先保存の再生を許可して、クライアントに送信されたすべてのデータを再送するように求められ得る。本実施形態では、このことは、過去にいかなる情報が形成されたかを判断するためのトランザクション履歴ログを利用して遂行される。
【０１０８】
図10の例では、トランザクションの2つの例はモバイル機器エンジン1060と関連する：変更API1062に対してポーリングし、変更1064を承認する。コマンドのこのグループは、変更について定期的にサーバーをチェックすることを行う。ポーリングされた変更API1062のパラメータは、uidとデバイスidとバージョンとを有してもよい。少なくとも1つのトランザクションアイテムがある場合には、結果は、1つのトランザクションidアイテムを有するはずである。結果は、トランザクションテーブル1114から0..n個のトランザクションアイテムを引き込むはずである。承認された変更API1064のパラメータは、uidとデバイスidとバージョンとを有してもよい。少なくとも1つのトランザクションがある場合には、結果は、1つのトランザクションidアイテムを有するはずである。本実施形態では、承認変更API1064は、ポーリングをインプリメントしない（例えば、それはプッシュモデルを利用する）。
【０１０９】
図10の例では、トランザクションの3つの例は通信エンジン1070と関連する：変更API1072に対してポーリングし、変更API1074を承認し、トランザクションAPI1076を消去する。コマンドのこのグループは、変更について定期的にサーバーをチェックすることを行う。ポーリングされた変更API1072と、承認された変更API1074とは、上述したポーリングされた変更API1062と承認された変更API1064とに類似している。消去されたトランザクションAPI1074は、uidとデバイスidとトランザクションidとのパラメータを有してもよく、結果は予測可能である。
【０１１０】
図10の例では、トランザクションの4つの例はユーザーエンジン1080と関連する：ユーザーAPI1082を認証し、ユーザーAPI1084を検索し、結合API1086を取得し、フィールドAPI1088を取得する。コマンドのこのグループは、ユーザーを検索することについての管理を行う。認証されたユーザーAPI1082のパラメータは、uidとデバイスidとであり、結果は予測可能である。検索されたユーザーAPI1084のパラメータは、例であって限定するものでないが、uidとデバイスidとユーザーネームとファーストネームとラストネームとを有してもよく、結果は0..n個のユーザーアイテムである。取得された結合API1086のパラメータは、uidとデバイスidとであり、結果は0..n個のユーザーアイテムである。取得したフィールドAPI1088のパラメータは、uidとデバイスidとであり、結果は、1..n個のフィールドオブジェクトを具備する1..n個のグループオブジェクトを具備する。このAPIは、サーバーのフィールドテーブル1104からフィールドデータを取得するために利用され、クライアントがディスプレイにこれを利用することができるようにフィールドグループに分離されている。また、これはフィールドについての属性を有する。
【０１１１】
また、システムは、エラーページにエラー結果を供給することができるエラートランザクション(図示しない)を具備してもよい。
【０１１２】
図12は、個人属性フレームワークの分配管理のスタートアップ方法についての例のフローチャート1200を示す。図12の例では、フローチャート1200は、ローカルまたは遠隔キャッシュ若しくはファイル、データベース、同様のものからUIDとデバイスlDとを読み取ることを具備するモジュール1202で始まる。フローチャート1200は、UIDに対する許可をリクエストするためにサーバーメソッドを呼び出すことを具備するモジュール1204に進む。サーバーが接続されず、許可がローカルに保存される場合には(1206-Y)、フローチャート1200は、ローカルファイルから許可を読み取ることを具備するモジュール1208に進む。どちらの場合にも、フローチャート1200は、PARデータがローカルに格納されているかどうか判断される判断ポイント1210に進む。PARデータがローカルに格納されていない場合には(1210-N)、フローチャート1200は、サーバーメソッドがPARデータをリクエストするために呼び出されるモジュール1212に進む。PARデータがローカルに格納されている場合には(1210-Y)、フローチャート1200は、PARデータがローカルファイルから読み取られるモジュール1214に進む。どちらの場合にも、フローチャート1200は、クライアントデバイスのタイプまたは設定に基づいて、かかるデバイスがすることとなっているトランザクションが、(1216-1)サーバーから未決定のトランザクションをリクエストする、または、(1216-2)サーバーがトランザクションを送信するのを待つ、の何れかによってサーバーから取得されるモジュール1216に進む。
【０１１３】
図13は、個人属性フレームワークの分散管理においてユーザーまたは宛先を追加する方法についての例のフローチャート1300を示す。図13の例では、フローチャート1300は、証明書がローカルに保存されているか否かについて判断される判断ポイント1302で始まる。証明書がローカルに保存されている場合には(1302-Y)、フローチャート1300は、証明書が有効であることをサーバーが確認するモジュール1308に進む。証明書がローカルに保存されていない場合には(1302-N)、フローチャート1300は、ユーザーが新しいユーザーであるかどうかが判断される判断ポイント1304に進む。ユーザーが新しいユーザーである場合(1304- Y)については後述する。ユーザーが新しいユーザーではないと判断した場合(1304-N)、フローチャート1300は、ユーザーがクライアントにて証明書について入力要求（プロンプト）されるモジュール1306に進み、そして、フローチャート1300は、証明書が有効であることをサーバーが確認するモジュール1308に進む。フローチャート1300は、モジュール1308から、証明書が有効であるかどうかが判断される判断ポイント1310に続いている。証明書が有効である場合には(1310- Y)、フローチャート1300は、クライアント通信サービスおよび／またはUIが始められるモジュール1314で終了する。代案では、クライアントサービスは、モジュール1314でクライアントサービスを始める必要性を取り除いてすでに作動していてもよい。このことは、複数のクライアントが1つのクライアントサービス(例えば、接続サーバー)を介して接続することを可能にするかもしれない。証明書が有効でない場合には(1310-N)、フローチャート1300は、クライアントがオフラインで動作する予定であるかどうかが判断される判断ポイント1312に進む。クライアントがオフラインで動作する予定でない場合には(1312-N)、フローチャートは、上述のようにモジュール1306から続く。クライアントがオフラインで動作する予定である場合には(1312- Y)、フローチャート1300は、上述のようにモジュール1314で終了する。
【０１１４】
再度、判断ポイント1304に戻って、ユーザーが新しいユーザーであると判断した場合には(1304-Y)、フローチャート1300は、クライアントが新しい証明書と宛先情報とをプロンプトされるモジュール1316に進む。フローチャート1300は、新しい証明書と宛先情報とが有効であることをサーバーが確認するモジュール1318に進む。フローチャート1300は、新しい証明書と宛先情報とが有効であるかどうかが判断される判断ポイント1320に進む。新しい証明書と宛先情報とが有効でないと判断された場合には(1320-N)、フローチャートは、クライアントがオフラインで動作する予定であるかどうかが判断される判断ポイント1322に進み、動作する予定でない場合には、フローチャート1300は、上述のようにモジュール1316に進み；動作する予定である場合には、フローチャート1300は、上述のようにモジュール1314に進む。新しい証明書と宛先情報とが有効であると判断された場合には(1320-Y)、フローチャート1300は、ユーザーがサーバーのユーザーテーブルに追加されるモジュール1326に進み、サーバーがUIDとデバイスIDとを返信するモジュール1328に進み、クライアントがPARにデータを書き込むモジュール1330に進み、そして、上述したモジュール1314に進む。
【０１１５】
図14は、個人属性フレームワークの分散管理において許可を設定する方法についての例のフローチャート1400を示す。図14の例では、フローチャート1400は、授与者が接続リストから宛先UIを介して1人以上の被授与者を選択するモジュール1402で始まる。フローチャート1400は、ユーザーが選択した接続に対する属性許可を可能または不可能にするモジュール1404に進む。フローチャート1400は、サーバーメソッドがサーバー上に設定されている許可をアップデートするために呼び出されるモジュール1406に進む。フローチャート1400は、サーバーが、授与者によって指定されるように許可テーブルをアップデートするモジュール1408に進む。フローチャート1400は、授与者に所有されている各宛先に対して、新しい許可設定が送信されるモジュール1410に進む。フローチャート1400は、モジュール1412で終了する。ここで、モジュール1412は、被授与者に所有されている各デバイスに対して、新しい属性値が送信されるもので、(1412-1)授与者が許可を与えている場合には、モジュール1408に送信された属性値が送信され、(1412-2)授与者が許可を取り除いている場合には、ヌル値が送信される。
【０１１６】
図15Aと15Bとは、個人属性フレームワークの分散管理において属性を変更する方法についての例のフローチャート1500を示す。図15Aの例では、フローチャート1500は、授与者が彼らのPARの1つ以上の属性をアップデートしているかどうかについてのモジュール1502で始まる。フローチャート1500は、許可がキャッシュされたかどうかが判断される判断ポイント1504に進む。許可がキャッシュされている場合には(1504- Y)、フローチャート1500は、許可が与えられたかどうかが判断される判断ポイント1506に進み、許可が与えられていない場合には、フローチャート1500は終了する。許可が与えられている場合には、フローチャート1500はモジュール1508に進む。許可がキャッシュされていない場合には(1504-N)、フローチャート1500は、変更とUIDとがクライアントからサーバーに送信されるモジュール1508に進む。
【０１１７】
図15Aの例では、フローチャート1500は、授与者の属性に対する被授与者が許可テーブルから選択されるモジュール1510に進み、被授与者が属性変更とともに結合されるモジュール1512に進み、属性トランザクションが作成されるモジュール1514に進む。フローチャート1500は、ポーリングを待つかどうかが判断される判断ポイント1516に進む。サーバーがポーリングを待つべきであると判断した場合には(1516-Y)、フローチャート1500は、ポーリングが行われたと判断されるまで判断ポイント1516を繰り返す。サーバーがポーリングを待つべきでない(1516-N)、または、ポーリングが行われている場合には、フローチャート1500は、属性トランザクション変更が被授与者のデバイス(例えば、接続サーバー)に送信されるモジュール1518に進む。「送信された」との文言が使われているが、クライアントがポーリングしている場合には、トランザクションは、プッシュ/送信というよりも、実際にはプルトランザクションであることには留意するべきである。フローチャート1500は、クライアントが変更された属性の受信者をアップデートする1520で終了する。
【０１１８】
図15Aの例では、モジュール1508にて変更とUIDとがクライアントからサーバーに送信された後、フローチャートは、上述のようにモジュール1510に進むが、授与者のデバイスがサーバーでデバイステーブルから選択されるモジュール1522にも進む(図15B)。フローチャート1500は、サーバーが属性変更および作成PARトランザクションとともに結合されるモジュール1524に進む。フローチャート1500は、サーバーがポーリングを待つ(または待たない)かどうかを判断する判断ポイント1526に進み、PAR変更が授与者のデバイスに送信されるモジュール1528に進む。フローチャート1500は、PARをアップデートするモジュール1530で終了する。
【０１１９】
図16は、個人属性フレームワークの分散管理において接続を形成する方法についての例のフローチャート1600を示す。図16の例では、フローチャート1600は、リクエスタがユーザーネームをUIに入力する、または、ルックアップがクライアントで実行されるモジュール1602で始まる。フローチャート1600は、接続がクライアントに追加されるモジュール1604に進む。フローチャート1600は、リクエスティ(requestee)が不呼び出しリストにリクエスタを具備しているかどうかが判断される判断ポイント1606に進む。リクエスティが不呼び出しリストにリクエスタを具備している場合には(1606-Y)、フローチャートは終了し、リクエスタは通知を受信してもしなくてもよい。リクエスティが不呼び出しリストにリクエスタを具備していない場合には(1606-N)、サーバーはリクエストをリクエスティに送信する。フローチャート1600は、リクエスティがプロンプトされるモジュール1610に進み、リクエスティがサーバーに応答を送信するモジュール1612に進む。
【０１２０】
図16の例では、フローチャート1600は、リクエスティがリクエストを受信したかどうかが判断される判断ポイント1614に進む。リクエスティがリクエストを受信している場合には(1614-Y)、フローチャート1600は、接続フラッグがサーバーに設定されるモジュール1616に進み、そして、フローチャート1600は、授与者と被授与者とに所有されているデバイスが通知されるモジュール1618で終了する。リクエスティがリクエストを受信していない場合には（1614-N）、フローチャート1600は、リクエスティがリクエストを拒否するかどうかだけではなく、リクエスタを不呼び出しリストに追加するかどうかも判断される判断ポイント1620に進む。リクエスタが不呼び出しリストに追加される必要がないと判断された場合には（1620-N）、フローチャート1600は、リクエスティがリクエストを受け取らずに終了する。リクエスタが不呼び出しリストに追加される必要があると判断された場合には（1620Y）、フローチャート1600は、不呼び出しフラッグを設定するモジュール1622で終了する。
【０１２１】
個人データの分散システムについての詳細な複数の例を説明することによって、図17に示されるような個人データの分散システムの例は容易に理解できるはずである。図17は、個人データの分散システム1700についての例を示す。図17の例では、システム1700は、サーバー1702と、ネットワーク1704と、授与者1706と、被授与者1708-1乃至1708-N(以下、被授与者1708として集合的に参照する)と、リクエスタ1710とを具備する。サーバー1702は、許可データベース1712とトラストメカニズム1714とを具備する。トラストメカニズム1714は多くの方法でインプリメントされ得る。例えば、トラストメカニズム1714は、データがソース(例えば授与者1706)から来るかどうかを確認してみてもよい。それが可能でない場合には、トラストメカニズム1714は、ローカルサインされたコピーを確認してみてもよい。それが可能でない場合には、トラストメカニズム1714は、2つの第三機関を比較することによってデータを確認してみてもよい(2つの第三機関が同一のデータを有している場合には、そのデータは有効であると思われるためである)。これはトラストメカニズム手順の一例であるが、あらゆる公知のまたは便利な手順であっても利用することができる。授与者1706は個人属性データベース1716を具備する。被授与者1708のそれぞれは、個人属性データベース1718-1乃至1718-N(以下、与えられた個人属性データベース1718として集合的に参照される)を具備する。被授与者1708は、個人情報の重要なデータ保存を備えるエージェントであってもなくてもよい。与えられた個人属性データベース1718は、例であって限定するものではないが、アドレスブックなどのPIMを具備する。
【０１２２】
図17の例では、授与者1706は、恐らく、被授与者1708への授与者の個人属性のいくつかまたはすべてに許可を与える。許可は、許可データベース1712に格納される。本実施形態では、サーバー1702は個人属性を一切有しない。有利なことに、このことは、大量のデータを保存するサーバー1702の負担を減らす。また、本実施形態のサーバー1702は個人データを有しないので、サーバーでのデータ検索(ハッキングまたはより合法的な方法を介しての何れか)は、より有害でなくすることができる。
【０１２３】
図17の例では、オペレーションにおいて、リクエスタ1710は、授与者の個人属性のいくつかまたはすべてにアクセスする許可を要求する。代わりに、授与者は、(例えば、リクエストを受信することなく)被授与者と共有することを選択してもよい。授与者1706または授与者1706のエージェントは、許可を与えることができる(または、許可は公的なデータに対して自動的に与えられてもよく、或いは、許可は事前に与えられてもよい)。リクエスタ1710が許可を与えられると、サーバー1702は、リクエスタ1710のために情報を取得することを試みるであろう。しかし、個人属性データベース1716は入手可能であってもなくてもよい。例えば、授与者1706は、個人属性データベース1716が格納される機械のスイッチを止めてもいいし接続を絶ってもよく、または、個人属性データベース1716は、他の理由のためにアクセス可能でなくてもよい。有利なことに、サーバー1702は、どの被授与者がどの情報に許可を与えられているかを判断するために許可データベース1712にアクセスすることができる。サーバー1702は、どの被授与者がどの情報への許可を与えられているかを知っているので、サーバー1702は、与えられた個人属性データベース1718からの情報をリクエスタ1710が供給することを容易にすることができる。場合によっては、人が個人属性を有するコンピュータのスイッチを切って休んでいる際に、システム1700は、分や日、月についての状況におけるリクエストされたデータをリクエスタ1710に供給することができる。
【０１２４】
図18は、多数の被授与者から個人データを取得する方法についての例のフローチャート1800を示す。図18の例では、フローチャート1800は、クライアントがデータをサーバーにリクエストするモジュール1802で始まる。フローチャート1800は、サーバーが、許可データベースの利用を生み出すべく、最終データセットについてのマップを形成するモジュール1804に進む。許可データベースは、許可が与えられている授与者と被授与者と属性とを識別するテーブルを具備してもよい。授与者は、あらゆる理由について異なる個人情報に許可を与えることができる。
【０１２５】
図18の例では、フローチャート1800は、リクエストされたデータの一部がクライアント1乃至Nから取得されるモジュール1806-1乃至1806-Nに進む。クライアントが同じデータに許可を与えられない場合には、データが1人のクライアントから取得することができないということがあり得る。また、新しいデータが信頼され得ないように、クライアントが授与者によってコントロールされるフィールドを変更しているということがあり得る(そして、違うクライアントは、信頼されたデータを取得するために接続されなければならない)。複数のクライアントがリクエストされたデータのうちの異なる部分を供給する任意の数の理由があり得る。
【０１２６】
図18の例では、フローチャート1800は、リクエストしているクライアントにデータが返送されるモジュール1808に進む。データは、サーバーでアセンブルされてもよいし、或いは、データは直接送信され得る。すべてのデータが受信されると、サーバーは、リクエストしているクライアントに通知してもしなくてもよい。サーバーは、リクエストしているクライアントへの送信のためにサーバーがデータをアセンブルしない場合には、本実施形態の送信するクライアントに通知してもしなくてもよい。
【０１２７】
有利なことに、データを失ったユーザーは、この技術を利用してデータを再投入することができる。例えば、ユーザーのEメールプログラムが破損または失われたデータとなった場合には、ユーザーは、再インストールおよび再投入することができる。ユーザーは、別のユーザーまたはデバイスがデータにアクセスしない限り、個人データを再投入することさえできる。さらに、新しいデバイスを使用し始めるが、個人データが格納されている別のデバイスにアクセスしないユーザーは、このテクニックを利用して新しいデバイスを投入することができる。別のユーザーから受信したデータを変更しようとするユーザーは、無意識にそうするかもしれない。そのようなユーザーは、彼らが別のユーザーによってコントロールされているデータを変更しているという警告を受信することができる(そして、彼らが本当にデータを変更したいかどうかを尋ねられる)。
【０１２８】
PIMまたはログ、データベースにデータをローカルに格納させるイベントについてのトランザクションログを備えることが好ましい。トランザクションログは、クライアントに関する個人属性の状態についてのスナップショットとして役立ち得る。トランザクションログは、データのすべてが再度必要である場合に高速再投入するのに有益である。さらに、トランザクションログは、データのコントローラがデータをアップデートした場合に、誰がどのようなデータをコントロールし、或いは他の情報をコントロールしているかを判断するために検索され得る。
【０１２９】
詳細な説明のいくつかの部分は、コンピュータメモリー中のデータビットに関するオペレーションのアルゴリズムおよび象徴の文言で示されているかもしれない。これらのアルゴリズム的な説明と表現とは、研究の本質を他の当業者に最も効果的に伝えるために、データ処理技術の当業者によって用いられる手段である。アルゴリズムは、ここでは、一般に、要求された結果につながる自己矛盾のないオペレーションシーケンスであると思われる。オペレーションは、物理量についての物理的マニピュレーションを要求しているそれらである。通常、必須ではないけれども、これらの量は、保存や転送、コンバイン、比較、さもなければマニピュレートされ得る電気的または磁気的な信号形式を採る。それは、これらのシグナルを、ビットや値、要素、シンボル、文字、用語、数、または同様のものと称するための主な共通用法であるので、時々便利であると判明している。
【０１３０】
しかしながら、これらのおよび同様な用語が、適切な物理量と関連しており、これらの量に適用された単に便利なラベルであることは心に留めておくべきである。以下の議論から明白であるように違った形で特に述べられない限り、説明にわたって、「処理」または「コンピューティング」、「計算」、「判断」、「表示」、若しくは同様のものなどの用語を利用している議論が、コンピュータシステムの動作とプロセスとに言及していること、或いは、コンピュータシステムのレジスターとメモリーとにおいて物理的な(電子)量として示されているデータを、コンピュータシステムメモリー若しくはレジスター、他のそのような情報格納または送信、ディスプレイデバイスにおいて物理量として同様に示されている他のデータへマニピュレートすると共に変換する同様の電子コンピューティングデバイスの動作とプロセスとに言及していることは高く評価される。
【０１３１】
本発明は、いくつかの実施形態において、ここでのオペレーションを実行するための装置と関連している。この装置は、必要な目的に対して特別に構成されてもよく、或いは、有利なことに、それは、コンピュータに保存されたコンピュータプログラムによって選択的に作動または再設定される汎用コンピュータから構成されてもよい。そのようなコンピュータプログラムは、限定するものではないが、フロッピーディスクや光ディスク、CD-ROM、磁気光ディスク、読み取り専用メモリ(ROM)、ランダムアクセスメモリー(RAM)、EPROM、EEPROM、磁気または光カード、電子マニュアルを保存するのに適すると共にそれぞれがコンピュータシステムバスに接続されているあらゆるタイプのメディアを含むあらゆるタイプのディスクなどの、コンピュータの読み取り可能な記憶媒体に保存されてもよい。
【０１３２】
ここに示されたアルゴリズムとディスプレイとは、いかなる特定のコンピュータまたは他の装置とも本質的に関連していない。様々な汎用システムは、ここでの教示に従ってプログラムとともに使用されてもよく、或いは、それは、いくつかの実施形態についての方法を実行するためのより専門的な装置を構成するのに便利であると判明するかもしれない。さまざまなこれらのシステムに必要とされている構成は、下記の説明から現れる。さらに、本発明は、あらゆる特定のプログラミング言語に関して説明されておらず、従って、様々な実施形態がさまざまなプログラミング言語を使って実施されるかもしれない。
【０１３３】
本発明は、所定の形態で具体例として説明される一方で、一定の改良や置換、それらと同等のものが本発明の範囲にあることは当業者よって高く評価されるであろう。従って、添付の特許請求の範囲には、本発明の範疇に含まれるようなすべてのそのような改良や置換、それらと同等のものが含まれている；本発明は特許請求の範囲によってのみ限定される。
【図面の簡単な説明】
【０１３４】
【図１】コンタクトデータベース同期システムの概念図を示す。
【図２】図1のシステムにて使用するためのクライアントコンピュータを示す。
【図３】図1のシステムにて使用するためのサーバーコンピュータを示す。
【図４】図1のシステムに関連するフローチャートを示す。
【図５Ａ】図1のシステムに関連するシステム及びトランザクションの例を示す。
【図５Ｂ】図1のシステムに関連するシステム及びトランザクションの例を示す。
【図６】図1のシステムのデータベースに具備され得るテーブルのいくつかの例を示す。
【図７Ａ】個人属性についての分散管理フレームワークがインプリメントされる得るシステムの例を示す。
【図７Ｂ】個人属性についての分散管理フレームワークがインプリメントされる得るシステムの例を示す。
【図８Ａ】個人属性の分散管理が可能なシステムのコンポーネントの例を示す。
【図８Ｂ】個人属性の分散管理が可能なシステムのコンポーネントの例を示す。
【図８Ｃ】個人属性の分散管理が可能なシステムのコンポーネントの例を示す。
【図８Ｄ】個人属性の分散管理が可能なシステムのコンポーネントの例を示す。
【図８Ｅ】個人属性の分散管理が可能なシステムのコンポーネントの例を示す。
【図８Ｆ】個人属性の分散管理が可能なシステムのコンポーネントの例を示す。
【図９】個人属性の分散管理のためのシステムを示す。
【図１０】図9のシステムに関連するエンジン及びトランザクションの概念図を示す。
【図１１】図9のシステムのデータベースに具備され得るテーブルのいくつかの例を示す。
【図１２】個人属性フレームワークの分散管理のスタートアップ方法の例のフローチャートを示す。
【図１３】個人属性フレームワークの分散管理においてユーザーまたはデバイスを追加する方法の例のフローチャートを示す。
【図１４】個人属性フレームワークの分散管理において許可を設定する方法の例のフローチャートを示す。
【図１５Ａ】個人属性フレームワークの分散管理において属性を変更する方法の例のフローチャートを示す。
【図１５Ｂ】個人属性フレームワークの分散管理において属性を変更する方法の例のフローチャートを示す。
【図１６】個人属性フレームワークの分散管理において接続を形成する方法の例のフローチャートを示す。
【図１７】個人データの分散システムの例を示す。
【図１８】複数の被許可者から個人データを得る方法の例のフローチャートを示す。
【符号の説明】
【０１３５】
100…コンタクト・データベース・同期システム、102…サーバー、104…ネットワーク、110…クライアント
【図１】
2009503625.tif 000002
【図２】
2009503625.tif 000003
【図３】
2009503625.tif 000004
【図４】
2009503625.tif 000005
【図５Ａ】
2009503625.tif 000006
【図５Ｂ】
2009503625.tif 000007
【図６】
2009503625.tif 000008
【図７Ａ】
2009503625.tif 000009
【図７Ｂ】
2009503625.tif 000010
【図８Ａ】
2009503625.tif 000011
【図８Ｂ】
2009503625.tif 000012
【図８Ｃ】
2009503625.tif 000013
【図８Ｄ】
2009503625.tif 000014
【図８Ｅ】
2009503625.tif 000015
【図８Ｆ】
2009503625.tif 000016
【図９】
2009503625.tif 000017
【図１０】
2009503625.tif 000018
【図１１】
2009503625.tif 000019
【図１２】
2009503625.tif 000020
【図１３】
2009503625.tif 000021
【図１４】
2009503625.tif 000022
【図１５Ａ】
2009503625.tif 000023
【図１５Ｂ】
2009503625.tif 000024
【図１６】
2009503625.tif 000025
【図１７】
2009503625.tif 000026
【図１８】
2009503625.tif 000027