(57)【要約】  ネットワーク内に分散されたデジタル資産および関係メタデータを管理するためのシステムは、相互接続された複数のノードを含み、相互接続されたノードの各々は、ユーザ制御によるストアとキャッシングサブシステムを介して、分散された資産および関係メタデータへのアクセス可能性を提供し、資産と関係メタデータの管理が所定の基準に基づいて行われるようになっている。各ノードは、キャッシングサブシステム、メタデータストア、コントローラ、ユーザ制御による資産ストレージコンポーネント、および各ノード間の通信のためのネットワーキングサブシステムと、を有する。相互接続されたノードは、クライアントアプリケーションのプラットフォーム運用をサポートする。
2012516503.tif 000002
【特許請求の範囲】
【請求項１】
あるネットワークにおける分散されたデジタル資産と関係メタデータを管理するシステムであって、
相互接続された複数のノードを有し、前記相互接続されたノードの各々は、ユーザ制御によるストアとキャッシングサブシステムを通じて、前記分散された資産へのアクセス可能性を提供し、前記資産と関係メタデータの管理が所定の基準に基づいて行われるようになっており、前記相互接続された複数のノードの各ノードは、キャッシングサブシステムと、メタデータストアと、コントローラと、ユーザ制御による資産コンポーネントと、前記各ノード間の通信のためのネットワーキングサブシステムと、を含み、前記相互接続された複数のノードは、クライアントアプリケーションのプラットフォーム運用をサポートすることを特徴とするシステム。
【請求項２】
請求項１に記載のシステムであって、
前記分散されたデジタル資産の管理のための前記所定の基準は、ノードの可用性、ノードの能力、資産の人気と需要、資産安全要求、および資産可用性優先性要求を含むことを特徴とするシステム。
【請求項３】
請求項１に記載のシステムであって、
前記相互接続された複数のノードは、個別に構成されることを特徴とするシステム。
【請求項４】
請求項１に記載のシステムであって、
前記コントローラは、前記クライアントアプリケーションのためのアプリケーションプログラムインタフェース（ＡＰＩ）を提供して、前記分散されたデジタル資産と関係メタデータにアクセスし、これを管理することを特徴とするシステム。
【請求項５】
請求項１に記載のシステムであって、
１つまたは複数の相互接続されたノードの間の同期が、少なくとも１つのノードへの変更の結果として開始されることを特徴とするシステム。
【請求項６】
請求項２に記載のシステムであって、
前記関係メタデータの管理はさらに、１つまたは複数のノードを同期させ、前記関係メタデータが、前記相互接続されたノードの各々に関連する挙動に適用される前記所定の基準に従って、個別に調整されるようにすること含むことを特徴とするシステム。
【請求項７】
請求項２に記載のシステムであって、
前記資産の管理はさらに、１つまたは複数のノードを同期させ、前記資産が、前記相互接続されたノードの各々に関連する挙動に適用される所定の基準に従って、個別に調整されるようにすることを含むことを特徴とするシステム。
【請求項８】
請求項５に記載のシステムであって、
実質的な数のノードペアが相互に同期されることを特徴とするシステム。
【請求項９】
請求項８に記載のシステムであって、
所定の期間だけオフラインであったノードは、前記ノードがオフラインに戻った時に、新しいメタデータでそれを更新することを特徴とするシステム。
【請求項１０】
複数のユーザ間のデータ資産へのアクセスを提供する方法であって、
少なくとも第一のユーザと第二のユーザの間で前記データ資産を共有するためのネットワークを提供するステップと、
前記データ資産の共有への招待を有効にするステップであって、前記招待が前記第一のユーザから前記第二のユーザに送信されるステップと、
前記第二のユーザによる前記招待の受入を有効にするステップと、
共有されるデータ資産に対応する共有メタデータが作成されるようにするステップと、
前記第一と第二のユーザ間の前記データ資産の共有を有効にするために、前記共有メタデータのコピーを送信するステップと、
前記共有メタデータが、少なくとも、最近のメタデータ変更が反映されるように変更されている場合、前記共有メタデータを同期させるステップと、
を含むことを特徴とする方法。
【請求項１１】
請求項１０に記載の方法であって、
前記第二のユーザによって、データ資産のレプリカを要求するステップと、
要求されたデータ資産のレプリカを有する少なくとも１つのノードが利用可能か否かを判断するステップと、
データ資産の新しいコピーを前記第二のユーザに伝送するステップと、
指定されたノードに位置する追加のデータ資産の存在を、前記データ資産の新しいコピーを反映させるように記録するステップと、
をさらに含むことを特徴とする方法。
【請求項１２】
請求項１１に記載の方法であって、
前記同期させるステップは、すべてのレプリカの位置を含むことを特徴とする方法。
【請求項１３】
請求項１１に記載の方法であって、
前記データ資産の新しいコピーは、キャッシュ内に設置されることを特徴とする方法。
【請求項１４】
複製のデータ資産を判断する方法であって、
モニタされた切断ノードにおける追加資産を判断するステップと、
前記追加資産が既存の資産の複製であるか否か評価するステップと、
前記モニタされた切断ノードにおいて見つけられた複製資産を追加レプリカとして分類するステップであって、前記切断ノードに複製資産が見つからなかった場合は、前記切断ノードを再接続するステップと、
わかっているその他すべてのユーザノードに連絡して、前記複製資産がこれらのノードに存在するか否かを判断するステップと、
前記わかっているその他のユーザノードにおいて見つけられた複製資産を追加レプリカとして分類するステップと、
前記わかっているユーザノードにおいて前記追加資産が存在しない場合、前記追加資産を新規資産に分類するステップと、
を含むことを特徴とする方法。
【請求項１５】
請求項１４に記載の方法であって、
前記わかっているユーザノードのいくつかがオフラインであり、前記追加資産が暫定新規資産として記録されることを特徴とする方法。
【請求項１６】
請求項１５に記載の方法であって、
わかっているユーザノードの各々がオンラインに戻ったとき、前記オンラインに戻った、わかっているユーザノード上の前記複製資産の存在を判断するステップをさらに含むことを特徴とする方法。
【請求項１７】
請求項１６に記載の方法であって、
検出された複製資産をレプリカとして分類するステップをさらに含むことを特徴とする方法。
【請求項１８】
複数のノードにわたって、共有デジタル資産に関連するメタデータを管理するシステムであって、
ａ）共有資産に関連する前記メタデータと前記共有デジタル資産へのアクセスを制御するノードコントローラと、
ｂ）ローカルノードに関するメタデータを保有し、ユーザの集合における資産に対応するメタデータストアと、
ｃ）前記ノードコントローラの処理を制御するワークフローマネージャと、
を備えることを特徴とするシステム。
【請求項１９】
請求項１８に記載のシステムであって、
共有資産に関する前記メタデータには、ユーザの分散されたデジタル集合の中の資産に関する情報が含まれることを特徴とするシステム。
【請求項２０】
請求項１８に記載のシステムであって、
いずれか１つのノードで生成されるメタデータは、ノード同期プロセスを通じて他のノードに通信され、前記メタデータには、画像とオーディオクリップがサムネイルとパスワードとして含まれることを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のデバイス、サーバおよびシステムの間でデータを管理するためのアーキテクチャ、サービスおよび方法に関する。特に、本発明は、いずれかのシステムノードまたはデバイスからのメタデータを含むあるユーザのデータ関連資産について、論理的に一元化した統合ビューを提供することに関する。
【背景技術】
【０００２】
データ関連資産には、個人で楽しむために制作されたり、パーソナルコンピュータ（ＰＣ）のストレージにダウンロードされたりする画像、ビデオおよび音楽ファイルがある。一般に、今日のデータ関連資産は、たとえ当初はそうでなくても、デジタルフォーマットであることが多い（すなわち、「デジタル資産」）。通常、これらのデジタル資産には、見る、聴く、または再生するために必要な時だけアクセスされる。さまざまなデバイスやインターネットサービスがこれらの資産を提供、利用し、たとえば携帯情報端末（ＰＤＡ）、デジタルカメラ、パーソナルコンピュータ（ＰＣ）、メディアサーバ、端末およびウェブサイト等がある。これらのデバイスやサービスプロバイダに保存された資産の集合は一般に、緩く結合されているか、まったく結合されず、現行同期プロセスは通常、２つのデバイス、たとえばメディアプレイヤとＰＣとの間で行われる。
【０００３】
多くの既存のソリューションでは、分散されたデジタル資産の集合の統合ビューが、すべてのノードで各資産を複製することによって（すなわち、その資産に関連付けられたすべてのデータファイルを複製する）ことによって提供される。Ｓｙｎｃｐｌｉｃｉｔｙ、ＳｈａｒｐｃａｓｔのＳｕｇａｒＳｙｎｃおよびＭｉｃｒｏｓｏｆｔのＬｉｖｅ  Ｍｅｓｈは、この複製方式を用いた、現時点での市販品の例である。このようなシステムの１つの欠点は、ストレージの非効率性である。新しい資産が他のノードに追加されるたびに、すべてのノードにおいて、保存された資産がそのノードに必要か否かに関係なく、追加のストレージ容量が必要となる。
【０００４】
すべてのノードで新しい資産を複製する上記のシステムの別の欠点は、ユーザが資産のアップロードを待っている間、ユーザの使用体験上に与えられる大きな影響である。多くの一般的なワークフローでは、関心対象の資産(asset interest)をアップロードする（たとえば、共有または印刷する）必要があるため、ユーザの使用体験は、アップロード作業の実行中、実質的に遅延される。
【０００５】
従来のシステムのさらに別の欠点は、過去に共有された資産へのアクセスを制限する能力に関する。共有された資産が他のユーザと共有されると、その資産は、受領者のノードでも複製される。既存のソリューションの多くにおいて、その資産の新しい、同一のレプリカが受領者のノードまたはコンピュータ上に存在するとき、当初の共有者はそのレプリカを削除することができない。
【０００６】
他の従来のソリューションは、分散されたデジタル資産の集合について、資産を保存している各ノードが、要求された資産のあるバージョンを、要求しているノードに放送できるようにすることによってその統合ビューを提供する。その一例がＯｒｂ  Ｓｙｓｔｅｍｓである。各アクセスポイントノードにインストールされたクライアントアプリケーションは、要求された資産を、要求された要件（たとえば、解像度基準）にしたがって、他のノード上に流す。このタイプのシステムの欠点は、アクセスポイントがシステムに接続されていないときに（すなわち、オフライン状態では）、アクセスできないことである。さらに、オフラインノードは事実上、動作せず、ローカルに保存された資産に関する数値しか提供しない。さらに、他の制約は、ある資産を保存するノードがオフラインであると、他のシステムの中のどのノードも、保存された資産の存在に気付かないことである。
【０００７】
既存のシステムの別の欠点は、集合に新たに導入された資産がすでに存在するかもしれないことを認識する能力が限られていることであり、したがって、システムは通常、集合の中に不要な複製を生成し、これが動作のための追加の資源（たとえば、保存スペースや処理時間）を必要とすることによって、システムに影響を与える。これはまた、そのシステムに同じ資産のコピーがいくつも含まれていることに気付かないユーザにも影響を与える。
【０００８】
最後に、分散されたデジタル資産の集合の従来の統合ビューの別の欠点は、所有者が自分の資産をローカルで（たとえば、ピクチャを整理するＷｉｎｄｏｗｓ（登録商標）フォルダシステム）整理しているときに生成される情報が、破壊されるか、無視されるかもしれないという点である。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】国際公開第２００７／０２４３８０号
【非特許文献】
【００１０】
【非特許文献１】アンドロウトセリス−セオトキスら（ＡＮＤＲＯＵＴＳＥＬＬＩＳ−ＴＨＥＯＴＯＫＩＳ  Ｓ  ＥＴ  ＡＬ）、「ピアツーピアコンテント分配技術の概説（Ａ  ｓｕｒｖｅｙ  ｏｆ  ｐｅｅｒ−ｔｏ−ｐｅｅｒ  ｄｉｓｔｒｉｂｕｔｉｏｎ  ｔｅｃｈｎｏｌｏｇｉｅｓ）」、エーシーエムコンピューティングサーベイ（ＡＣＭ  ＣＯＭＰＵＴＩＮＧ  ＳＵＲＶＥＹＳ），エーシーエム（ＡＣＭ）、ニューヨーク（ＮＥＷＹＯＲＫ）、（米国）、Ｖｏｌ．３６、Ｎｏ．４、２００４年１２月１日、ｐ．３３５−３７１
【非特許文献２】マーチン  ブイら（ＭＡＲＴＩＮＳ  Ｖ  ＥＴ  ＡＬ）、「Ｐ２Ｐシステムにおけるデータ複製の概説（Ｓｕｒｖｅｙ  ｏｆ  ｄａｔａ  ｒｅｐｌｉｃａｔｉｏｎ  ｉｎ  Ｐ２Ｐ  ｓｙｓｔｅｍｓ）」、［ｏｎｌｉｎｅ］、２００６年１２月１日、ｐ．１−４５、［２００８年１０月１７日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｈａｌ．ｉｎｒｉａ．ｆｒ／ｄｏｃｓ／００／１２／２２／８２／ＰＤＦ／Ｓｕｒｖｅｙ＿ｏｆ＿ｄａｔａ＿ｒｅｐｌｉｃａｔｉｏｎ＿ｉｎ＿Ｐ２Ｐ＿ｓｙｓｔｅｍｓ．ＯＤＦ＞
【非特許文献３】デ  ブルム  サッコル  ディーら（ＤＥ  ＢＲＵＭ  ＳＡＣＣＯＬ  Ｄ  ＥＴ  ＡＬ）、「ピアツーピア環境におけるレプリカとバージョンの検出、管理及び検索（Ｄｅｔｅｃｔｉｎｇ、  ｍａｎａｇｉｎｇ  ａｎｄ  ｑｕｅｒｙｉｎｇ  ｒｅｐｌｉｃａｓ  ａｎｄ  ｖｅｒｓｉｏｎｓ  ｉｎ  ａ  ｐｅｅｒ−ｔｏ−ｐｅｅｒ  ｅｎｖｉｒｏｎｍｅｎｔ）」、第７７回クラスタコンピューティングとグリッドのＩＥＥＥ国際シンポジウム（ＣＣＧＲＩＤ  ２００７）  ＩＥＥＥ  ピスカタウェイ（ＰＩＳＣＡＴＡＷＡＹ）、ニュージャージー（ＮＪ）、（米国）、２００７年、ｐ．８３３−８３８
【発明の概要】
【発明が解決しようとする課題】
【００１１】
したがって、当業界では依然として、今日存在する、従来の分散型デジタル資産集合システムに関わる欠陥や制約を克服することに対するニーズがある。
【課題を解決するための手段】
【００１２】
上記のニーズは、あるネットワークにおいて分散されたデジタル資産と関係メタデータを管理するシステムを開示する本発明によって満たされ、このシステムは、いくつかの相互接続されたノードを含み、相互接続されたノードの各々は、ユーザ制御によるストアとキャッシングサブシステムを介して、分散されたデジタル資産へのアクセス可能性を提供し、資産と関係メタデータの管理が所定の基準に基づいて行われるようになっている。相互接続された各ノードは、キャッシングサブシステム、メタデータストア、コントローラ、ユーザ制御による資産ストレージコンポーネント、および各ノード間の通信のためのネットワーキングサブシステムと、を有する。相互接続されたノードは、クライアントアプリケーションのプラットフォーム運用をサポートする。
【００１３】
本発明はさらに、モニタされた切断されたノードにおいて追加された資産を判断し、追加された資産が既存の資産の複製であるか否かを判断することによって、複製データ資産を判断する方法を提供する。追加された資産が複製であると直ちに評価された場合、この資産は、追加されたレプリカとして分類される。切断されたノードで何の複製資産も見つからない場合、ノードが再接続されたときに、他のすべてのわかっているユーザノードに連絡して、それらのノードに複製資産が存在するか否か判断する。もし存在すれば、その複製資産は追加されたレプリカとして分類される。わかっているユーザノードに追加された資産が存在しない場合、その追加された資産は新規資産として分類される。
【００１４】
本発明のさらに１つの他の態様では、このシステムの１人のユーザは、ある資産を第二のユーザと、第二のユーザがその資産を見て、その資産とそのメタデータの変更を見ることができ、また、資産の所有者からそれを行うための許可を受ければ、その資産とそのメタデータに変更を加えることができるような方法で共有できる。
【００１５】
したがって、複数のユーザ間でデータ資産のアクセスを提供する方法が開示され、この方法は、少なくとも第一のユーザと第二のユーザとの間でデータ資産を共有するためのネットワークを提供するステップを含む。第二のステップは、データ資産共有への招待を有効にする。招待が第一のユーザから第二のユーザに送信される。第三のステップは、第二のユーザによる招待の受入を有効にし、したがって、その後、共有されるデータ資産に対応する共有メタデータが生成される。別のステップは、メタデータのコピーを第二のユーザに送信して、第一と第二のユーザの間のデータ資産の共有を有効にする。最後のステップでは、共有メタデータが変更されている場合に、共有メタデータを同期させ、少なくとも、最近のメタデータの変更が反映されるようにする。
【図面の簡単な説明】
【００１６】
【図１】本発明による完全分散型システムの一例を、ピアツーピアネットワークによって相互接続されたノード群として示す図である。
【図２】１つのノードのコンポーネントを示す図である。
【図３】バージョンベクタの成分を示す図である。
【図３ａ】ユーザ間である資産を共有し、その資産の変更を同期させるステップの例を示す図である。
【図４】切断されたノードによる複製検出のステップの例を示す図である。
【図５】同じメタデータを保存するノードを同期させるステップの例を示す図である。
【図６】メタデータレベルの異なるノードを（能力の高いものから能力の低いものへ）同期させるステップの例を示す図である。
【図７】メタデータレベルの異なるノードを（能力の高いものから能力の低いものへ）同期させるステップの例を示す図である。
【図８】同じメタデータレベルのノードを同期させるステップの例を示す（部分同期を記入）図である。
【発明を実施するための形態】
【００１７】
本明細書では、本発明による分散デジタル資産管理システムについて述べる。分散デジタル資産管理システムは時々、連合資産管理システム（フェデレイテッド資産マネジメントシステム(federated asset management system)）と呼ばれる。分散デジタル資産管理システムは、本発明の文脈において、異なるソースからのデータを、システムのユーザにとって、すべてのデータが一緒に保存されているかのように見える方法で結合する。これらのソースには、たとえば、パーソナルコンピュータ、サーバ、携帯電話、ゲーム機等がある。データには、デジタルデータ、オーディオデータ、画像処理データ等がある。したがって、本発明の文脈において、「資産」は、当初からデジタル化された、または後にデジタルフォーマットに変換される画像、ビデオ、音楽、その他のオーディオデータおよびファイルに関する。
【００１８】
本発明のいくつかの態様の１つは、所有され、共有されるすべてのメディア資産の統合ビュー（１つのノードまたは多数のノードを通じたもの）とアクセスを提供する。あるユーザによって所有または共有されるデジタル／メディア資産の全部が統合され、あるユーザの仮想集合と呼ばれる。本発明は、そのユーザのデジタル資産およびこの仮想集合に関連付けられるメタデータの全部または選択された量を管理するための分散システムについて述べ、これにはそのユーザが使用したい、またはそのユーザの資産が存在するかもしれず、かつその他のノードと通信する各種のノードの上で実行されるソフトウェアサービス群が含まれる。
【００１９】
本発明による、一例としての分散デジタル資産管理システム（以下、「システム」とも称する）には、図１に示すように、ノード群（１、４、５および６）が含まれる。ノード１、４、５および６には、コンピュータ上で実行されるソフトウェアサービスまたはサービス群が含まれる。このコンピュータは、あるユーザに帰属するワークステーションであってもよいが、ノードは携帯情報端末（ＰＤＡ）またはその他のネットワーク対応デバイス、たとえば携帯電話またはゲーム機等であってもよい。ノード１、４、５および６はネットワーク上で、ピアツーピアリンク２を使って相互に通信する。このネットワークは一般にインターネットであるが、Ｂｌｕｅｔｏｏｔｈ（登録商標）等、他のプロトコルに基づくアドホックサブネットワークを含んでいてもよい。いくつかのノードは、アプリケーション３と通信する。典型的なアプリケーションは、ユーザ（「メンバ」とも称する）に閲覧させ、共有させ、またさもなければ、他のノードにある自分の仮想集合の中の資産を含む自分の仮想集合およびその集合に属する資産とメタデータのすべてを操作させる。あるコンピュータ上の各ノードは、そのコンピュータを使用するすべてのユーザをサポートする。この分散システムの構成は、好ましくは中央ノード５を含む。中央ノード５は、ネットワークサーバ群の上にある。中央ノード５は、分散システム上の異なるユーザとの最初のコンタクトを支援し、ウェブアプリケーションをサポートし、写真仕上げ等の外部サービスをサポートする。中央ノード５はまた、可用性が保証される必要のある資産のためのキャッシングストレージを提供することができる。この分散システムのほとんどのユーザについて、相互作用と通信は主として中央以外の（縁辺）ノードと、またそれらの間で行われる。
【００２０】
ノードの一例の内部構造を図２に示す。典型的なノードは、相互にメッセージ１０を伝えることによって通信する、多数のコンポーネントを含む。あるシステムでは、メッセージはＭｉｃｒｏｓｏｆｔのＭＳＭＱまたは同様のソフトウェアによって実装される同期キューを伝えるが、これらのコンポーネントはまた、メッセージを直接伝えることもできる。Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）であるコンポーネント１１は、ユーザアプリケーションに、そのユーザの仮想集合およびそれに関する対応の情報へのアクセスを与える。ネットワークインタフェース１２により、各ノードは、メッセージの送受によって他のすべてのノードと通信できる。ユーザ制御によるメモリ／ストレージであるコンポーネント１３は、ユーザ制御による資産を管理する。一般に、ユーザ制御によるメモリ／ストレージであるコンポーネント１３によって管理される資産には、そのノードが位置するコンピュータにあるファイルが含まれる。しかしながら、ユーザ制御によるメモリ／ストレージであるコンポーネント１３は、Ｆｌｉｃｋｒ（登録商標）等の遠隔ネットワークサイトにおける資産を管理することも可能である。大量資産キャッシュ（ｈｅａｖｙ  ａｓｓｅｔ  ｃａｃｈｅ）１４には、このノードに一時的に保存されている資産およびその他のファイルが含まれる。コントローラ１５は、ノードによって処理されるタスクを実行するワークフローを起動する。これらのワークフローは、ノードデータベース１７に保存されているワークフローの説明とポリシーによって制御される。ノードは、これらのワークフローの説明とポリシーを変更することによって、個別に構成することができる。たとえば、ＰＤＡとワークステーションのワークフローは大きく異なるであろう。コントローラによって使用されるワークフローとポリシーには、大量資産キャッシュの管理に適用されるポリシーが含まれる。
【００２１】
メタデータストア１６は、ユーザの集合の中の資産に対応するメタデータを含む。一般に、あるユーザのためのメタデータストア１６には、そのユーザの集合の中のすべての資産のためのメタデータが含まれるであろう。資産に対応するサムネイル（たとえば、画像やオーディオクリップ）もまた、この分散システムではメタデータと考えられる。サムネイルは、サムネイルキャッシュ１８の中に保存される。本発明の他の実施形態では、サムネイルをメタデータストア１６の中に保存することができる。あるノードに保存されるメタデータの量は十分であり、コンピュータがネットワークから分離されても、ユーザは集合全体を閲覧し、これを使って何らかの活動を行うことができる。各ノードにどの資産メタデータが保存されるかに関する正確な仕様は、ノードデータストア１７に保存された基準によって決定される。
【００２２】
ネットワークインタフェース１２は、ノード間のピアツーピア接続の管理を担当する。これは、ノード間でメッセージとファイルを伝送し、どのノードがオンラインかを発見する。ネットワークインタフェース１２は、２つの部分から構成される。１つの部分は、Ｎｅｔｗｏｒｋ  Ｔａｌｋｅｒ／Ｌｉｓｔｅｎｅｒと呼ばれ、残りのノードからメッセージを受け取る。これらのメッセージは、そのシステム特定のものであり、伝送とは無関係のフォーマットである。これらのメッセージは、特定のノード上の特定のユーザに宛てられる。ノードの識別は、特定のネットワークアドレスを参照しない方法で特定される。第二の部分は、Ｔａｌｋｅｒ／Ｌｉｓｔｅｎｅｒがメッセージの送受信に使用するインタフェースである。Ｎｅｔｗｏｒｋ  Ｔａｌｋｅｒ／Ｌｉｓｔｅｎｅｒが使用する伝送インタフェースは、そのシステムに利用できる各種の伝送に関するすべての情報をカプセル化する。ノード間の通信のための最も好ましいメカニズムは、ルータとファイヤウォールによって分離されるホームシステム間でデータを伝送する。理想的には、ネットワークインタフェース１２は、ユーザがそのルータまたはファイヤウォールに穴を開けることを必要とせずに、この伝送を行うべきである。そのために、このシステムの１つの実施形態において最も一般的に使用されるノード間でデータとメタデータを伝送するのに使用される方法は、Ｇｏｏｇｌｅにより開発されたｌｉｂｊｉｎｇｌｅと呼ばれるソフトウェアパッケージを使う。このパッケージは、コンピュータ間でメッセージを送信するチャットメカニズムを、民生用ネットワークルータを通じてデータを受け渡すことのできるピアツーピアファイル伝送メカニズムと組み合わせる。コンピュータ間でピアツーピア接続を確立するためのその他のよく知られた方法もまた、このシステムで使用できる。これに加えて、１つのホームネットワーク内に位置するノードは、単純なＴＣＰ／ＩＰベースのプロトコルを使って通信でき、外部チャットサーバの使用を必要としない。
【００２３】
ユーザは、アプリケーションを通じてこのシステムにアクセスし、そのアプリケーションはグラフィカルユーザインタフェース（すなわち、ＧＵＩ）を提供し、それによってユーザは集合を見る／編集することができる。これらのアプリケーションは、ローカルの資産管理ノードによって提供されるサービスを利用して、あるユーザに属する分散された集合にアクセスし、アプリケーションはその資産またはそのメタデータの位置の詳細を知っていなくてよい。アプリケーションは、分散され、システムのアプリケーションの一部としてロードされたライブラリを使用する。このライブラリは、ローカルノード上の、そのシステムのＡｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）であるコンポーネント１１と通信する。ライブラリは、標準的なプロセス間通信方式を用いてＡＰＩであるコンポーネント１１にメッセージを送信することによって、通信する。システムＡＰＩであるコンポーネント１１は、アプリケーションからのメッセージに応答して、システムノードの他のコンポーネントと通信する。
【００２４】
アプリケーションは、システムＡＰＩを使って、システムメタデータ（たとえば、メンバの情報、集合の情報および資産の情報）の読取りと書込みを行うことができる。アプリケーションはまた、状態およびエラーの両方の情報のための通知と、アプリケーション外で集合が変更されたときの通知を予約することができる。アプリケーションは、システムサービスを使って、大量資産キャッシュ１４内の大量資産（すなわち、フル解像度資産ファイル）にアクセスする。大量資産へのアクセスは、その資産のためのローカルパスを要求するか、その資産へのストリームを開くことによって実行できる。システムサービスは、大量資産の実際のストレージの位置に関係なく、使用可能なローカルパスまたはストリームを提供する。
【００２５】
中央ノード５では、ＡＰＩがネットワーク環境にとって適当である必要がある。インターネットＡＰＩのために最も一般的に使用されるプロトコルは、Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）とＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）プロトコルであり、その各々にＨＴＴＰパケット内のＡＰＩパラメータと応答の伝送が関わる。中央ノード５の上にあるＡＰＩプロセッサは、ＲＥＳＴコマンドに応答する。このＡＰＩを通じて大量資産を要求すると、その資産のコピーが中央の大量資産キャッシュ１４に移動し、中央の大量資産キャッシュ１４からその資産の読出しに使用できるプロキシＵＲＬを戻す。
【００２６】
システムメタデータには、本発明によれば、集合内の資産に関する情報のほか、ユーザ情報（たとえば、パスワード、ファイル名、ビデオプレビュー、資産作成日、ユーザ提供のタグ）と、システム動作の状態／ステータス（たとえば、ファイルコピー、ファイル共有）が含まれる。資産情報には、ファイルから抽出されるＥｘｉｆタグ等の情報、ユーザにより追加されるキャプション等の情報および、イメージインテリジェンス(image intelligence)の作業を用いて資産のコンテンツから抽出されるデータを含む。ある資産に関するメタデータにはまた、その資産に関するサムネイル、たとえば、その資産から抽出され、ユーザがその資産を容易に視覚的に識別できるようにする小さな画像も含む。ある資産のメタデータには、その資産のわかっているすべてのコピーへのリファレンスおよび、その資産から作成されたその他すべての資産へのリファレンスも含まれる。システムが、ある資産がどの資産から導出されたものかを知っていれば、資産メタデータには、その資産が導出された元の資産へのリファレンスも含まれる。ある資産のアクセス制御情報もまた、その資産のメタデータの一部である。システムメタデータは、特性を有するサブジェクトとしてオーガナイズされ、そのサブジェクトと特性はどちらも、それ自体がメタデータの一部である。
【００２７】
１つのノードで発生されるメタデータは、ノード同期プロセスを通じて他のノードに伝えられる。本発明のある一面において、あるシステムのノードは、そのノードを使用するユーザの集合に関連付けられるメタデータひとつひとつのすべてを有しているわけではない。しかしながら、各ノードは、それが「アクセスクリティカル(access-critical)」と考えるメタデータを保存する。アクセスクリティカルなメタデータとは、そのノードがオフラインのときに、ローカルアプリケーションが機能するのに必要なメタデータである。ノードにより、何が「アクセスクリティカルなメタデータ」かの考え方は異なり、たとえば、携帯電話は資産ＩＤのリストしか保存しないかもしれない。ＰＣは、資産ＩＤ、日付、キャプション、説明等を含む、ずっと大きなメタデータ群を有するかもしれない。ノード同期プロセスの中で、各ノードは、それが「アクセスクリティカル」であると考える特定のメタデータ群を他のノードに伝える。また、そのローカルノードにのみ関係するメタデータを保持する別のメタデータストア１６があってもよい。別のメタデータストア１６は、たとえば、物事の局所状態に関する項目を保持する。
【００２８】
集合のメタデータには、リファレンスのほか数値もまた含めることができる。たとえば、資産メタデータの１つは、その資産のプロパティである。ある資産の、異なるノード上に位置する各種のコピーもまた、ある資産のプロパティであり、これらのコピーのリファレンスがメタデータストアに保存される。システムは、これらのリファレンスをシステムのＵｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）として保存する。システム資源の特定に加え、システムＵＲＩは、その基本的アクセスメカニズム（たとえば、そのネットワークの「位置」）を説明することによって、その資源の位置を特定する手段を提供するため、システムのＵｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ＵＲＬ）でもある。ＵＲＬをこのように使用できるのは、それが、各ノードを一意的に特定し、ネットワークインタフェースコンポーネントによって解釈可能なＧｌｏｂａｌｌｙ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｅｒ（ＧＵＩＤ）であるシステムネットワークノードＩＤを含んでいるからである。あるノードに、それがローカルで保存していないメタデータまたは資産が求められると、このノードはシステムＵＲＬを使って、必要なデータを確かに有するのはどのノードかを見つけ出し、これらのノードに対し、所望のデータを求めるメッセージを送信する。
【００２９】
メタデータストア１６には、さまざまなデータベース技術を含めることができる。集合メタデータの多くが、Ｒｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ（ＲＤＦ）を実装するデータベースの中に保存される。ＲＤＦは、セマンティックウェブが、アプリケーション、企業および社会の境界を越えたデータの共有と再使用を可能にする共通のフレームワークを提供するための手段である。これに加えて、過去および進行中のセマンティックウェブの作業の多くは、ＲＤＦを使って表されるデータに関する「推論」を含む。メタデータの共有と再使用およびメタデータに関する推論はシステム、ひいてはオープンインタフェースとイメージインテリジェンスの使用にとって重要である。従来のリレーショナルデータベースと比較したＲＤＦのその他の利点は、新しい種類の情報を設計の中に容易に追加できることである。しかしながら、ＲＤＦに伴う、および、Ｅｘｉｆファイル等の特定の種類のデータに関してはコストも発生するため、リレーショナルデータベースのほうがよりよい選択肢である。したがって、本発明の１つの実施形態は、複合的なデータベースを使用する。各種類のメタデータは、ストレージの種類に関連付けられる。メタデータストア１６は、特定の種類のメタデータにアクセスする必要がある場合、その種類のメタデータに関するそのストレージモードを見て、どのデータベースに行くべきかを決定する。
【００３０】
あるノード上のノードコントローラ１５は、システムメタデータと資産へのアクセスを制御する。その動作は、ノードデータストア１７に保存されているそのノードの能力に関する情報によって制御される。ノードコントローラ１５は、ワークフローマネージャを使ってその処理の多くを制御する。他のシステムコンポーネントからのメッセージの一連の送受信を行わなければ、メッセージの処理が完了したとは考えられないワークフローが数多くある。ワークフローマネージャは、これらのワークフローの全部の管理を担当する。ワークフローマネージャはまた、メッセージ間のワークフローの状態を保持するために、その状態を説明するパラメータをノードデータストア１７に保存することも担当する。
【００３１】
ワークフローマネージャは、ポリシーにしたがって動作する。これは、それが動作しているノードの種類に関する知識を持ち、あるノードの能力と要求に見合ったワークフローのセットアップと実行においてこの情報を使用するコンポーネントである。ワークフローマネージャはまた、メタデータの一部を使って、ローカルで保存されていない資産とメタデータを発見する。ワークフローそのものは、Ｂｕｓｉｎｅｓｓ  Ｐｒｏｃｅｓｓ  Ｅｘｅｃｕｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＢＰＥＬ）によるステートメントで具体的に説明される。ノードコントローラ１５は、ＢＰＥＬによるワークフローの説明をノードデータストア１７に保存し、これらを、ノードコントローラ１５の一部である実行エンジンを使って実行する。そのノードに関するワークフローはそのノードに保存されるため、ワークフローはノードごとに違うこともあり、能力レベルの異なるノード上で違っていることもある。
【００３２】
各ノードのシステムストレージは、そのノード上の資産の全部を含む。資産ストレージは、資産マネージャによって管理される。これらの資産マネージャは、そのシステムの他のコンポーネントと通信し、分散システムに対して、資産にアクセスし、これを管理する方法を提供する。各資産マネージャは、それが担当するデータに関する情報を管理または要求するためのメッセージを受け入れる。これらは、システムと、そのシステムがサポートできる各種の資産ストレージの間の標準的インタフェースとなる。
【００３３】
資産ストレージの種類に対応する資産マネージャには、３つの基本的な種類がある。
１）ユーザ資産マネージャ(User Asset Manager)（ＵＡＭ）−ＵＡＭは、ユーザが選択した保存と整理の方法にしたがって位置付けられ、整理される、ローカルコンピュータ上に保存された各種の資産ファイルを管理する。このシステムソフトウェアをインストールしたユーザは、ローカル資産ファイルがどこにあるかをソフトウェアに伝えるが、ローカル資産をいずれかの特定の場所に移す必要も、またいずれかの特定の階層に従って整理する必要もない。ユーザは、ローカルコンピュータファイルシステムユーティリティを使って、これらのファイルをまったく自由に追加、削除または移動することができる。このことから、ＵＡＭにより管理されるストレージは、ユーザ制御によるストレージと呼ばれる。
２）サムネイル資産マネージャ(Thumbnail Asset Manager)（ＴＡＭ）−ＴＡＭは、ある人物の仮想集合の中のすべての資産に関するサムネイルファイルを含むサムネイルキャッシュを管理する。各ノードのサムネイルキャッシュは、そのノードで実行されるシステムサービスによって完全に制御される。
３）キャッシュ資産マネージャ(Cache Asset Manager)（ＣＡＭ）−ＣＡＭは大量資産キャッシュを管理するもので、あるノード上のシステムコントローラによって、コントローラが他のノードからコピーした資産のコピーを保存するのに使用される。これは、そのノード上で実行されるシステムサービスによって完全に管理される。ＵＡＭはまた、仮想集合と各種の実物資産ストレージの間の統一されたインタフェースにもなる。新しい種類のＵＡＭを追加することにより、システムを将来開発される種類の資産ストレージ媒体にも拡張できる。
【００３４】
より具体的には、ユーザ資産マネージャは、資産データをユーザの資産管理仮想集合に供給することを担当する。ＵＡＭは一般に、ファイルスニファ（file sniffer）または、それが管理するディレクトリの中の資産の追加、削除および変更を検出するその他何らかの方法を含む。ＵＡＭは、ある資産の変更を検出すると、ノードコントローラにメッセージを送信する。ノードコントローラはそのメッセージに応答して、ワークフローを開始する。新たに発見された資産に関して、このワークフローは、その資産が新しいか、それとも既存の資産の複製かを判断する。新しい資産であれば、ワークフローはその資産ファイル内に含まれるすべてのメタデータを抽出し、その資産のサムネイルを作成し、その資産に関するすべてのメタデータをメタデータストアの中に保存する。サムネイルを作成させたワークフローはまた、異なる解像度のいくつかのサムネイルを作成させることもできる。ワークフローがこれを行うか否かは、それぞれのノードに実装されているワークフローポリシーによる。
【００３５】
サムネイル資産マネージャは、ノードによって保存されたサムネイルを管理する。これらのサムネイルの中には、ローカルで生成されて、新しい資産の発見に適用されるワークフローによってサムネイルキャッシュの中に移されたものがあれば、他のノードとのメタデータ同期を制御するワークフローによってサムネイルキャッシュに移動されたものもある。ユーザがある資産を削除すると、資産削除を制御するワークフローがそのサムネイルを削除する。
【００３６】
キャッシュ資産マネージャは、ノード上の一時的な保存を制御する。キャッシュ資産マネージャは、ローカルの大量資産キャッシュ１４の中の資産を管理する。この一時的ストレージには、そのノードにコピーされ、そこに一時的に保存されている、その他のノードからの資産が含まれる。キャッシュ資産マネージャは、ローカルキャッシュの中の資産のコピーを追跡し、必要に応じてこれらを削除して、そのキャッシュのディスクスペース割当を管理する。ワークフローポリシーが、キャッシュからの資産の削除を制御する。たとえば、変更された資産は、同期または、ローカルのレプリカが存在する場合にはローカルワークフローを介して、その資産の少なくとも１つの他のレプリカにその変更が適用されるまで削除されない。別の例として、「人気のある」資産（すなわち、多くの他のユーザと共有される資産）は、より人気の低い資産より優先的にキャッシュに保持されるかもしれない。
【００３７】
同様に、需要の高い資産（すなわち、ユーザが頻繁にアクセスする資産）を優先的に保持することができる。別の例として、喪失するリスクがより高いと判断される資産（たとえば、バックアップコピーが少ないもの、携帯電話のように保存の信頼性が低いデバイスに保存されているもの）は、よりリスクが低いと判断される資産（たとえば、信頼性の高いオンラインサービス上で保存されるバックアップコピー）より優先的に保持することができる。資産をキャッシュから削除するワークフローは、ノードごとに異なることがある。ＣＡＭは、そのキャッシュの中のある資産に加えられた変更を検出すると、ワークフローマネージャに通知する。すると、ワークフローマネージャは、この変更に対処するための適当なステップを開始する。
【００３８】
大量資産キャッシュ１４は、当初は空である。大量資産は、ワークフローが、別のノードに保存された資産のコピーをローカルでも保存するように要求した時に、キャッシュに追加される。ある資産のコピーをキャッシュに保存することにはさまざまな理由がある。１つの理由は、あるノード上のアプリケーションが、そのレプリカのすべてが他のノードにあるような資産にアクセスしたいと望むことである。その場合、ノードコントローラ１５が、その資産をローカルキャッシュに移し、その後、アプリケーションに、その新しいローカルのレプリカへのアクセスを提供する。大量資産キャッシュ１４を使用する、より興味深い理由は、便宜、性能、安全、または可用性の検討事項に関わる。資産の中には、ユーザにとって他の資産より重要なものがある。ある人物は、その資産に重要であるとマークするかもしれない。あるいは、その重要性は、この資産に関するユーザの行動の記録から、またはその資産のコンテンツの解析から導き出すことができる。いずれの場合も、資産、たとえば、特定のピクチャの重要性は、そのピクチャのメタデータプロパティとなる。あるユーザが、その資産を誤って削除されないように保護するべきであると指示した場合、分散システムは確実に、その資産のレプリカを複数カ所に置くようにすることができる。重要な資産の唯一のコピーが、時々しかオンラインとならない機械の上にある場合、本願による分散システムは、この重要な資産を、より高い信頼性でオンラインとなるノードに、または常時オンラインの中央ノード５に移すことができる。このような場合、選択されたピクチャは、他のノードの上の大量資産キャッシュに移されるであろう。あるノードのワークフローポリシーが、その資産のコピーを別のノード上にあるユーザ制御によるストレージに移すように指示することさえ可能である。ここでも、ワークフローがこれらの資産の移動を管理する。ワークフローは、システムのＡＰＩを通じて伝えられるユーザの行動によって開始することができ、また、同期命令によっても開始することができ、これは同期サイクルの完了によってユーザの集合の状態の変化が示されるからである。これらのワークフローを容易にするために、各ノードに関連付けられるノード可用性メタデータがある。このノード可用性メタデータは、そのノードが連絡する他のノードと共有される。ノード可用性メタデータによって、ノードは、可用性の理由から、資産を他のノードに移すべきか否かを知ることができる。
【００３９】
このシステムは、システムメンバデータのコピー（レプリカ）を、特定の時点でオンラインかもしれないし、オフラインかもしれないシステムノードに保存する。このシステムにより、各ノードは、そのデータを他のノード上のデータと調和させて、分散システムが全体として自己矛盾のない状態になるようにすることができる。このシステムにより、メンバは、現時点でオンラインか否かに関係なく、その集合を用いた作業を行うことができる。これは、他のノードを更新することができないときに、データをノード上で変更できることを意味する。また、同じデータの異なるコピーに異なる変更を加えることも可能である。同期は、異なるノード上に存在しうる同じデータのコピー間の違いを調整することによって、すべてのシステムノード間でメンバデータをコヒーレント状態にするためにシステムが使用するプロセスである。
【００４０】
システムデータは、多くの従来の複製システムとは、各資産に関する情報が異なるニードに多かれ少なかれ保存されうるという点で異なる。（従来の同期メカニズムは、すべてのデータがすべてのノード上で複製されるフルレプリカ用に設計されている。）本明細書において、「より低能力のノード」とは、必ずしもすべてのメタデータを保存するとはかぎらないノードを指す。すべてのノードに少なくともいくつかのメタデータが保存される一方で、いずれかのノードにいくつの大量資産が存在してもよいし、しなくてもよい。本発明において、システム同期の実装は、１つのメカニズムによるメタデータと大量資産の両方の同期をサポートする。
【００４１】
２つのノードに同じデータの異なるバージョンがあるとき、それは３つの異なる理由で正しいといえる。第一のノードに、そのデータのより最近のバージョンがあるかもしれず、第二のノードに、そのデータのより最近のバージョンがあるかもしれず、あるいは両方のノードに、そのデータの同程度に最近ではあるが異なるバージョンがあるかもしれず、これは、ノードが最後に同期されて以降、各ノードのユーザらが同じデータを変更したからである。このシステムでは最後の可能性が特に高いが、それは、このシステムではノードがオフラインで動作でき、これらを常に同期できるとはかぎらないからである。このシステムで、どの可能性が発生したかを効率的に判断できるようにするために、システムはバージョンベクタを使用する。バージョンベクタと変更リストは、システムがシステムノード上のレプリカとシステムデータのバージョンを追跡する手段であり、また、同期が必要か否かを判断するための主要なメカニズムである。
【００４２】
システム変更は、１つのノードの上のシステムデータに加えられた１つまたは複数の変更のまとまりであり、システムはこれに連続するバージョン番号を付与する。システム変更の例としては、写真のタイトルの変更、１つのアプリケーションからの複数のエディットの取入れ、およびシステムユーザまたは資産マネージャによって発見された複数の資産の追加等がある。１つより多いシステム変更が同期動作中に行われることがある。複数のシステム変更は、システムの変更リスト(Change List)の中に保存される。各ノードは、システムの変更リスト内に自己の変更を保存するだけでなく、それが同期中に他のノードから受け取った変更のコピーも保存する。特定のノードに関するすべてのシステム変更から最も高いバージョン番号がそのノードの、その各々のバージョンベクタの要素の中に保存される。システムのバージョンベクタは、メタデータへの変更を明示的に追跡し、大量資産レプリカへの変更は黙示的に追跡する。バージョンベクタ３０（図３ａに示す）は、各ノードのための要素３１を含むアレイである。１つの実装例において、メタデータまたは資産を保存する各システムノードは、そのノード上にデータを有する各システムメンバに関してバージョンベクタを１つだけ有する。したがって、バージョンベクタは、そのシステムメンバがデータを保存する各ノードについて１つの要素を含む。
【００４３】
１つの実施の形態において、バージョンベクタは、これまでにその関連するメタデータに変更を行ったことのあるノードだけを説明する。システムは、最上位のバージョンベクタをシステム変更リストとともに使用して、すべてのシステムメンバノードを通じたシステムメンバデータを追跡し、同期する。バージョンベクタの各要素３１は、特定のノードに関するユーザに対応する同期ＩＤ３２（たとえば、図３ａの“Ａ”）を、そのユーザのためのそのノードのデータが変更されるたびにソフトウェアがカウントを増やすカウンタ３３（たとえば、図３Ａの“９”）（すなわち、「論理バージョン」）とともに保有するあるノードは、あるユーザのシステムデータについて同じ同期ＩＤを保持するが、それがそのデータベースを喪失し、完全に更新しなければならない場合、または他のノードがその変更リストの中に必要な変更のコピーを持たなくなるために、通常の同期をサポートできない場合を除く。特定のメンバ／ノードに関するバージョンベクタには、そのメンバ／ノードに関する現行バージョン情報と、最後に同期が行われた時点でそのメンバが使用していた他のノードに関する改訂情報が含まれる。各ノード上の集合の各共有部分については、また別のバージョンベクタがある。
【００４４】
同期は少なくとも１対のノードの間で行われる。同期サイクル（“ｓｙｎｃ  ｃｙｃｌｅ”）は、あるノードに、その最後の同期サイクル以降、所定の回数だけ変更が行われたとき、または最後の同期サイクル以降、所定の時間が経過した時に行われる。あるノードでそれが行われると、そのノードはあるユーザのためのバージョンベクタを、それがユーザの他のノードから過去に受け取った、そのユーザのためのバージョンベクタのコピーと比較して、これらの他のノードのうちのどれが、それより低い改訂レベルにあり、したがってそのデータで更新される必要があるかを判断する。ノードは、これらのその他ノードに「同期サイクル必要」というメッセージを送信する。このメッセージを受け取ったノードは、「同期サイクル必要」のメッセージを送信したノードとの同期サイクルを開始する。同期サイクルは、１つのノード、すなわちそのバージョンベクタを他のノード（ソース）に送信する「要求者」から始まる。ソースは、要求者の中のバージョン番号とそのバージョンベクタを比較する。目的は、ソースが要求者に対して、最後に要求者と同期して以降、ソースにおいて発生したすべての変更（要求者が、その能力レベルに基づいて要求するもの）を送信することである。バージョンベクタの比較により、ソースが目的地に変更を送信するべきであることが示された場合、ソースは、その変更リストを見て、そのバージンベクタ内の改訂レベルの数値に応じて、要求者に送信する必要のある変更はどれかを判断する。同期サイクルが完了したら、要求者は新しい変更レベルを反映させるように、そのバージョンベクタを更新し、その後、それが受け取った、同期サイクルを求める他のメッセージに応答する。
【００４５】
図５、図６、図７、図８は、異なるノード能力を異なる組み合わせにしたノードに関する同期サイクルの中のステップを示す。これらのステップは好ましくは、プロセッサ、コンピュータまたは、特定用途集積回路（ＡＳＩＣ）によって実行される。これらのステップは、コンピュータにより読取可能な記憶媒体、たとえば、磁気ディスク（たとえば、ハードドライブまたはフロッピー（登録商標）ディスク）または磁気テープ等の磁気記憶媒体、光ディスク、光テープまたは機械により読取可能なバーコード等の光記憶媒体、ランダムアクセスメモリ（ＲＡＭ）またはリードオンリメモリ（ＲＯＭ）等のソリッドステート電子記憶デバイス、またはコンピュータプログラムの保存に利用されるその他の物理的デバイスまたは媒体等に保存可能なコンピュータプログラムであってもよい。
【００４６】
それぞれの場合において、同期サイクルは、バージョンベクタの交換から始まる。図５では、バージョンベクタは同一であり、したがって、それ以上の処理は行われない。具体的には、ノード２とノード３の交換について記されているステップ５０１で、ノード２は、そのバージョンベクタ＿Ｎ２（ＶＶ＿Ｎ２）で同期開始（Ｓｔａｒｔ  Ｓｙｎｃ）メッセージをノード３に送信する。ステップ５０２で、ノード３はＶＶ＿Ｎ２を自己のバージョンベクタと比較する。比較の結果、ノード３は変更を検出して、ノード２にはない、ノード３が有する変更リストを編集する。ステップ５０３で、ノード３はＶＶ＿Ｎ３と変更リストで、同期開始（Ｓｔａｒｔ  Ｓｙｎｃ）応答メッセージを送信する。
【００４７】
ステップ５０４で、ノード２はノード３を自己のバージョンベクタと比較する。比較の結果、ノード２は変更を検出し、ノード３によって送信された変更リストを見る。ノード２はその後、自己の変更リストとノード３の変更リストの間に矛盾がないかチェックする。この例においては、矛盾はない。ステップ５０５で、ノード２はその変更リストをノード３に送信する。ステップ５０６で、ノード２はノード３の変更を自己のデータストアの中に組み込み、追加の変更を反映させるようにその変更リストを更新する。これに加え、ＶＶ＿Ｎ２が更新される。同様に、ステップ５０７で、ノード３はノード２の変更を自己のデータストアの中に組み込み、その変更リストを、追加の変更を反映させるように更新し、ＶＶ＿Ｎ３が更新される。この例では、最終ステップ５０８において、ＶＶ＿Ｎ２とＶＶ＿Ｎ３は同じである。
【００４８】
図６において、１つのノード（ノード０）は、バージョンベクタから、２つのノード（ノード０とノード２）の同期が必要であることを検出する。これらのノードは変更リストを交換し、変更リストを使って、どのメタデータを変更する必要があるかを判断し、２つのノードを同期させるために必要なすべてのメタデータを交換する。特に、ステップ６０１で、ノード２は、そのバージョンベクタ＿Ｎ２（ＶＶ＿Ｎ２）でノード０に同期開始（Ｓｔａｒｔ  Ｓｙｎｃ）メッセージを送信する。ステップ６０２で、ノード０はＶＶ＿Ｎ２を自己のバージョンベクタと比較する。したがって、ノード０は、ノード２にノード０が必要とする変更があるが、ノード０にはノード２が必要とする変更がないことを知る。ステップ６０３で、ノード０はＶＶ＿Ｎ３で同期開始（Ｓｔａｒｔ  Ｓｙｎｃ）応答メッセージを送信する。その後、ステップ６０４で、ノード２はノード０を自己のバージョンベクタと比較する。ノード２は、ノード０に送信する必要のある変更があることを知るか、これを検出する。したがって、ステップ６０５で、ノード２はその変更リストをノード０に送信する。
【００４９】
ステップ６０６において、ノード０はノード２からの各変更を調べ、評価し、それがノード０によって保存されたものに影響を与えるかどうか判断する。保存された資産に影響がある場合、ノード０はそのストアと変更リストを更新する。保存された資産に影響がない場合、ノード０は変更を廃棄し、変更リストの中にプレースホルダとして空値（ｎｕｌｌ）を追加する。最終ステップのステップ６０７では、ＶＶ＿Ｎ２とＶＶ＿Ｎ０は同じであるが、ノード０には、そのバージョンベクタに部分更新フラグがセットされている。
【００５０】
図７と図８において、１つのノードはもう一方のノードより能力が低く、すなわち、そのノードは必ずしもすべてのメタデータを含んでいない。携帯電話に位置するノードはデスクトップＰＣに位置するノードより能力が低いが、これは、携帯電話はデスクトップＰＣほど各資産に関すメタデータを多く保存できないからである。携帯電話の能力データには、携帯電話のノードにどの種類のメタデータが保存されていないかの説明が含まれる。これらの図は、同期サイクルがより高い能力のノードとより低い能力のノードのどちらから始まっているかが異なる。プロセスは、能力が等しいノードの場合と、能力の低いノードがそのデータのすべてを更新するとは限らないという点において異なる。図はまた、同期サイクルが起こった前後のバージョンベクタを示す。これらのバージョンベクタは括弧の中に記されている。注記は、当該のノードが知っているすべてのその他のノード、これらのノードの各々のバージョンレベル、およびこれらのノードのいずれかが部分的に更新されているか否かを示す。
【００５１】
具体的には、図７に示される実施の形態に関して、ステップ７０１で、ノード３はそのＶＶ＿Ｎ３で同期開始（Ｓｔａｒｔ  Ｓｙｎｃ）メッセージをノード０に送信する。ステップ７０２で、ノード０はＶＶ＿Ｎ３を自己のバージョンベクタと比較する。ノード０は、それにノード３が必要とする変更があることを検出する。ノード３には、それが必要とする変更がない。ステップ７０３で、ノード０はＶＶ＿Ｎ０で同期開始（Ｓｔａｒｔ  Ｓｙｎｃ）応答メッセージと、そのバージョンベクタのＮ２：６とＮ２：６に配置するための変更リストを送信する。ステップ７０４で、ノード３はノード０を自己のバージョンベクタと比較する。ノード３は、それがノード０に送信する必要のある変更があることを知る。
【００５２】
ステップ７０５で、ノード３はノード０からの変更リストを見直す。ノード０は、場所Ｎ２：５に空値があることを知り、これはノード０が変更を保存していないことを示す。これに加えて、ノード３はＮ２：６の変更を知り、したがってノード３のデータベースが更新される。特に、ノード０のバージョンベクタはＮ２に“ｐ”を有し、したがってノード３も、ノード３について“ｐ”を設定する。ステップ７０６で、ＶＶ＿Ｎ３とＶＶ＿Ｎ０は同じであり、どちらもノード２のバージョンベクタを有し、ＶＶには部分更新フラグがセットされている。
【００５３】
図８に示した実施の形態において、ステップ８０１は、ノード３がそのＶＶ＿Ｎ３で同期開始（Ｓｔａｒｔ  Ｓｙｎｃ）メッセージをノード０に送信することを示している。ステップ８０２において、ノード０はＶＶ＿Ｎ３を自己のバージョンベクタと比較して、ノード３が必要とする変更を検出する。この例において、ノード３には、それが必要とする変更がない。続いて、ステップ８０４で、ノード３はノード０を自己のバージョンベクタと比較して、それがノード０に送信する必要のある変更があるか否かを検出する。ステップ８０５で、ノード３はノード０からの変更リストを見直す。Ｎ２：５には空値があり、これはノード０が変更を保存しなかったことを示す。変更がＮ２：６にあり、したがって、対応するデータベースが更新される。ノード０のバージョンベクタはＮ２に“ｐ”があるため、ノード３もノード３について“ｐ”を設定する。最終ステップ８０６では、同じバージョンベクタ、ＶＶ＿Ｎ３とＶＶ＿Ｎ０があり、どちらもノード２のバージョンベクタを有し、ＶＶには部分更新フラグがセットされている。
【００５４】
共有データの同期サイクルは、若干異なる方法で実行される。第一のユーザがアカウントを有するノードに他のユーザと共有されていたデータが含まれていれば、それは共有データに対応するバージョンベクタを有する。共有データが第一のユーザのための特定のノードで変更した場合、そのノードは、第二のユーザのためのアカウントを有する別のノードと同期サイクルを開始する。第二のユーザのノードが同期された後、それは通常の同期プロセスを使って、それ自身を第二のユーザのアカウントを有する他のノードと同期させる。
【００５５】
変更リストは時間の経過と共に増大するため、これらは時々、プルーニング（ｐｒｕｎｅｄ）を行う必要がある。すべてのノードが常にオンラインであれば、プルーニング（ｐｒｕｎｉｎｇ）は容易であり、ある変更が他のすべてのノードに伝搬されるとすぐに、その変更リスト項目は不要となり、削除できる。事実、ノードのペアが同期されると、システム全体が実質的に同期され、これは、ノードの実質的な部分が相互に同期されるからである。例外は、オフラインのノードであり、これはオンラインになるまで同期することができない。あるノードが所定の時間だけオフラインであると、他のノードは、オフラインのノードがそれらの変更を受け取るまで待たず、その他すべての、オフライン以外のノードに伝搬された変更に関する変更リスト項目を削除する。この削除プロセスがプルーニングと呼ばれる。オフラインであったノードがオンラインに戻ると、これは再び他のノードとの同期サイクルに加わる。これらの同期サイクルは通常通りに進めることができず、これは、他のノードに、そのノードがオフラインになった後にこれらのノードに発生した変更に対応する変更リスト項目は、プルーニングを行ってしまったために、なくなっているからである。したがって、以前にオフラインであったノードはその後、修正後の同期サイクルに参加する。まず、このノードは、オフラインであった間に発生した変更を第二のノードに送信する。これらのオフラインでの変更はすべて、矛盾する可能性があると想定され、ユーザには、これらの変更を受け入れるべきか否かを判断するように求められる。次に、矛盾が解消された後に、以前にオフラインであったノードは、そのメタデータストア全体と変更リストを、それがその変更を送信した先である、同じ第二のノードから更新する。これの、より単純な例は、新しいノードがオンラインで加わり、その他すべてのノードがその変更リストをすでにプルーニングした場合である。新しいノードは、そのメタデータストア全体を他のノードから更新する。特に、この例では、新しいノードには何の変更もない可能性が非常に高い。
【００５６】
デジタル資産管理における共有は、他のユーザ（時々、「共有受信者」と呼ばれる）は、あるユーザの集合の中のデジタル資産にアクセスできることを意味する。他のユーザが有するアクセスの量は、その資産を所有するユーザが管理する。部分的にのみ信頼される共有受信者には、その資産に関するメタデータの一部への読取アクセスしか認めなくてもよく、全面的に信頼される共有受信者には、資産そのものを修正する権利を与えることができる。共有は、１人のユーザによって開始または提供され、他のユーザに向けられる。第二のユーザには共有招待のメッセージが送られ、共有招待を受け入れても、拒絶してもよく、応答メッセージを返す。このメッセージは、他のノード間通信と同じピアツーピアネットワークを使用する。共有招待が受け入れられた場合、それはまた、共有資産に関する情報をメタデータに追加するワークフローと、提供ユーザによる共有資産の追跡を開始する。ここでも、共有資産の所有者は、共有資産に関して、どれだけのアクセスが共有受信者に付与されるかを管理する。本システムの実施の形態において、共有者は、各共有受信者に役割を割り当てる。この割り当てられた役割は、共有受信者の識別情報とともに共有者のメタデータストア１６の中に保存される。ノードコントローラ１５は、この割り当てられた役割を使って、共有受信者が共有資産を読み、または変更することを許可するか否かを判断する。
【００５７】
資産を第二のユーザと共有するために、提供するユーザはまず、自分のコンタクトリストに第二のユーザを入れる必要がある。システムネットワーク内のどのノードも、中央ノード５に尋ねることによって、他のユーザを利用できるか否かがわかるが、これはすべてのユーザが中央ノード５と連絡しているからである。中央ノード５が利用できない場合は、ノードは少なくとも、それがそれらのユーザのために連絡しているノードに尋ねることができる。システムメンバが潜在コンタクトのリストを入手したら、そのメンバは、コンタクトとなるように招待するメッセージの送信先となるべきユーザを選択することができる。メッセージは、他のユーザメッセージと同様に、メッセージの宛先となる人物のアカウントを含むことがわかっている少なくとも１つのノードに送信され、同期プロセスを通じて、そのユーザを含む他のノードに伝搬される。第二のユーザがコンタクトとなると、提供するユーザは、第二のユーザと資産を共有することができる。提供するユーザは、ユーザメッセージを潜在的な共有受信者に送信し、選択された資産の共有にその共有受信者を招待する。共有受信者が共有招待を受け入れると、共有受信者が作業しているノードは、提供する使用者のノードの一つに、その資産を説明するメタデータを照会し、そのメタデータを、それが共有されていることを示す追加の属性とともにその集合メタデータに追加する。
【００５８】
図３は、「ボブ」と「テッド」が関わる例としてのフローチャート３００における共有資産の同期に関するステップを示す。これらのステップは好ましくは、プロセッサ、コンピュータまたは、特定用途集積回路（ＡＳＩＣ）によって実行される。これらのステップは、コンピュータにより読取可能な記憶媒体、たとえば、磁気ディスク（たとえば、ハードドライブまたはフロッピー（登録商標）ディスク）または磁気テープ等の磁気記憶媒体、光ディスク、光テープまたは機械により読取可能なバーコード等の光記憶媒体、ランダムアクセスメモリ（ＲＡＭ）またはリードオンリメモリ（ＲＯＭ）等のソリッドステート電子記憶デバイス、またはコンピュータプログラムの保存に利用されるその他の物理的デバイスまたは媒体等に保存可能なコンピュータプログラムであってもよい。
【００５９】
最初のステップ３１０において、ボブはテッドと資産“Ａ”を共有する。ステップ３１５で、システムは共有資産Ａのメタデータをテッドの集合にコピーし、ボブを所有者として特定する。ステップ３２０で、ボブは資産ＡとＢのためのメタデータを修正する。ステップ３２５で、システムは資産ＡとＢに関する変更をボブのノードの全部に同期させる。これに加えて、システムは資産Ａの変更をテッドのノードの全部に同期させる（すなわち、‘ｓｙｎｃｈｓ’）。ステップ３３０で、テッドは資産ＡとＣのメタデータを修正する。
【００６０】
ステップ３３５で、システムはＡとＣの変更をテッドのノードの全部に同期させ、その一方で、資産Ａに関する変更をボブのノードの全部に同期させる。ステップ３４０で、テッドはそのノードを分散システムから切断する（すなわち、オフラインにする）。ステップ３４５で、テッドは、ボブから切断されている間に資産Ａのメタデータを修正する。続いて、ステップ３５０で、テッドは自分のノードを分散システムに再接続する。ステップ３５５で、システムはＡの変更をテッドのノードの全部とボブのノード全部とに同期させる。
【００６１】
ステップ３６０で、テッドは資産Ａの画像データを編集することに決める（ボブがテッドにその許可を与えている）。ステップ３６５で、システムはテッドの仮想集合の中の資産Ａのメタデータを使ってレプリカを見つけ、それをコピーして、テッドが編集するために、テッドのシステムキャッシュの中に新しいレプリカを作成する。システムは資産Ａのメタデータを更新して、新たに作成されたレプリカを含める。ステップ３７０で、システムはＡのメタデータの変更をテッドのすべてのノードとボブのすべてのノードと同期させる。
【００６２】
ステップ３７５で、テッドは資産Ａの画像データを編集する。ステップ３８０で、システムは画像の変更を資産Ａのレプリカの全部に同期させる。ステップ３８５で、テッドは再び、分散システムから切断する。最後のステップ、ステップ３９０で、テッドは資産Ａからの画像データを自分のプリンタで印刷する（システムは、資産ファイルのキャッシュに入っているコピーを使用する）。
【００６３】
本発明の別の特徴において、あるノードのＵＡＭが新たな資産を検出すると、システムはそれが完全に新しい資産であるか、すでにシステムに知られている資産のコピーであるかを判断する必要がある。その資産がすでにシステムに知られている資産のコピーである場合、分散システムはその資産ファイルを、新規資産ではなく、既存資産のレプリカと分類する。資産が、ノードがすでにその資産のためのメタデータを含んでいる場合に固有であるか否かを判断する手段は知られている。しかしながら、本明細書に記載されている分散システムは、オフラインのノードもこれを使用することができるため、相互に連絡していない２つのノードはどちらも、同じ資産を追加して、両方の複製が個別に集合データベースに追加されるまで、複製を検出できないようにすることが可能である。ノードが連絡を取ると、いずれかの資産がノード間で複製であると特定される必要があるかないかを判断する効率的な手段が必要である。本発明の分散システムは、オフラインノードによって発見された新しい資産を「暫定新規資産」として記録することにより、複製特定の問題を解決する。分散システムは、これを行うために、オフラインノードで新たに発見された資産に、「暫定新規資産プロパティ」というある種の資産メタデータを割り当てる。暫定新規資産プロパティは、その資産について複製チェックが完了しておらず、まだ行う必要があること示す、明確なインディケータとなる。図４は、一例としてのフローチャート４００の中の暫定新規資産プロパティと「マイピクチャ」とラベリングされたファイルを割り当てて、使用するステップを示す。
【００６４】
これらのステップは好ましくは、プロセッサ、コンピュータまたは、特定用途集積回路（ＡＳＩＣ）によって実行される。これらのステップは、コンピュータにより読取可能な記憶媒体、たとえば、磁気ディスク（たとえば、ハードドライブまたはフロッピー（登録商標）ディスク）または磁気テープ等の磁気記憶媒体、光ディスク、光テープまたは機械により読取可能なバーコード等の光記憶媒体、ランダムアクセスメモリ（ＲＡＭ）またはリードオンリメモリ（ＲＯＭ）等のソリッドステート電子記憶デバイス、またはコンピュータプログラムの保存に利用されるその他の物理的デバイスまたは媒体等に保存可能なコンピュータプログラムであってもよい。
【００６５】
ステップ４１０で、ユーザは「マイピクチャ」というファイルをそのシステム仮想集合に追加する。ステップ４２０で、システムは資産（ＩＤ、種類、サムネイル等）とレプリカ（ＩＤ、種類、サムネイル等）のメタデータを作成し、これをユーザの仮想集合メタデータに追加する。ステップ４３０で、システムは「暫定新規資産」プロパティを、ユーザの集合の中に新たに追加された資産のメタデータに追加する。ステップ４４０で、システムは現在接続されているユーザの全ノードに照会することによって、複製検出方法を適用する。
【００６６】
ステップ４４５で問い合わせを行い、複製が見つかったか判断する。複製が見つかった場合、ステップ４５０で、「マイピクチャ」を既存の資産のレプリカとしてラベリングする。ステップ４６０で、システムは新規に追加された資産に関するレプリカのメタデータを既存の資産に移動させる。言い換えれば、既存の資産が追加のレプリカを獲得する。ステップ４７０で、システムは、ユーザの集合から、そこに残っている新規に追加された資産のメタデータを削除して、ワークフローが完了する。
【００６７】
あるいは、レプリカが見つからない場合、ノードが再接続されると、ステップ４７５でまた別の問い合わせにより、そのユーザのすべてのノードに照会して複製の有無を確認する。ユーザの全ノードへの照会が終了したら、その資産は新しいと考えられ、ステップ４８０で暫定プロパティの指定が削除され、その後ワークフローが完了する。
【００６８】
ユーザのすべてのノードの照会が済んでいない場合、ステップ４８５でさらに問い合わせを行うことによって、特定のノードがオンラインであるか否かを判断し、オンライン状態になるまでポーリングを続ける。ステップ４９０で、システムは、反復サイクル中に新規に接続されたノードに複製の有無を照会するのに複製検出方法を適用する。
【００６９】
オフラインであったノードが連絡した時に、複製資産を検出する別の方法を以下に説明する。ノードは、連絡すると、それらのメタデータを同期させる。このプロセスによって、１つのノードに追加された資産が他のノードのメタデータに追加される。２つのノードの同期では、これらのノード間の資産変更リストが交換されるため、また、あるノードの変更リストによってどの資産が新しいかが示されるため、特定の資産に関する複製チェックを実行する必要性は、同期中に交換される資産変更リストから推定される。
【符号の説明】
【００７０】
１  ノード
２  ピアツーピアリンク
３  アプリケーション
５  中央ノード
１０  通信するコンポーネント
１１  ＡＰＩコンポーネント
１２  ネットワークインタフェース
１３  ストレージコンポーネント
１４  資産キャッシュ
１５  ノードコントローラ
１６  メタデータストア
１７  ノードデータベース
１８  サムネイルキャッシュ
３０  バージョンベクタ
３１  バージョンベクタの要素
３２  同期ＩＤ
３３  バージョンカウンタ
３００  フローチャート
３１０  最初のステップ
３１５  ステップ
３２０  ステップ
３２５  ステップ
３３０  ステップ
３３５  ステップ
３４０  ステップ
３４５  ステップ
３５０  ステップ
３５５  ステップ
３６０  ステップ
３６５  ステップ
３７０  ステップ
３７５  ステップ
３８０  ステップ
３８５  ステップ
３９０  ステップ
５０１  ステップ
５０２  ステップ
５０３  ステップ
５０４  ステップ
５０５  ステップ
５０６  ステップ
５０７  ステップ
５０８  ステップ
６０１  ステップ
６０２  ステップ
６０３  ステップ
６０４  ステップ
６０５  ステップ
６０６  ステップ
６０７  ステップ
７０１  ステップ
７０２  ステップ
７０３  ステップ
７０４  ステップ
７０５  ステップ
７０６  ステップ
８０１  ステップ
８０２  ステップ
８０３  ステップ
８０４  ステップ
８０５  ステップ
８０６  ステップ
【図１】
2012516503.tif 000003
【図２】
2012516503.tif 000004
【図３】
2012516503.tif 000005
【図３ａ】
2012516503.tif 000006
【図４】
2012516503.tif 000007
【図５】
2012516503.tif 000008
【図６】
2012516503.tif 000009
【図７】
2012516503.tif 000010
【図８】
2012516503.tif 000011
【国際調査報告】
2012516503.tif 000012
2012516503.tif 000013
2012516503.tif 000014
2012516503.tif 000015
2012516503.tif 000016