(57)【要約】      （修正有）【課題】ファイルを確実かつ検証可能な方法で転送すると同時に、ファイルを受信するサイトがもっとも便利なソースからファイルを獲得することが出来る、方法及び装置を提供する。【解決手段】発信元のコンピュータ上にいくつかのアセットを作成する工程は、作成するアセットを選択することからスタートする１０２。暗号ハッシュアセット識別子が生成される１０４。各アセット識別子は、特定のアセットのコンテンツを使用して計算される。アセットから計算されるアセット識別子を含んだ、アセットリストが生成される１０６。アセットリストから計算される、暗号ハッシュアセットリスト識別子が生成される１０８。アセットリスト識別子は、後で呼び出すのに備えて記憶される。選択されたアセットもまた、安全に保管するため、ローカルまたはコンピュータネットワーク上のいずれかに記憶される。【選択図】図１
2006338680.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも第１及び第２のコンピュータを含むコンピュータシステムにおいて使用するための方法であって、前記第１のコンピュータがコンテンツをアドレス可能なストレージを提供するものであり、方法は、
（Ａ）  前記第１のコンピュータにてリクエストを受信して該第１のコンピュータによって格納されたデータにアクセスする動作であって、前記リクエストは、前記データのコンテンツに少なくとも部分的に基づく識別子により前記データを識別することである、動作（Ａ）、
（Ｂ）  前記識別子を用いて前記データを探索する動作を備える、方法。
【請求項２】
請求項１に記載の方法において、前記リクエストは、前記リクエストを発行したものとして前記第２のコンピュータを認識することであり、方法は
（Ｃ）  前記第２のコンピュータに前記データを返信する動作を更に備える、方法。
【請求項３】
請求項１に記載の方法において、前記データは少なくとも一つのデジタルアセットを含む、方法。
【請求項４】
請求項１に記載の方法において、前記デジタルアセットは少なくとも一つのデータと、該少なくとも一つのデータに関連するメタデータとを含む、方法。
【請求項５】
請求項１に記載の方法において、前記識別子は、暗号ハッシュ関数を前記データのコンテンツの少なくとも一部に適用することにより生成される、方法。
【請求項６】
請求項１に記載の方法において、前記リクエストにおける前記識別子は、前記データに対する第１の識別子であり、方法は
（Ｃ）  前記第１のコンピュータにて、該第１のコンピュータにより格納されたデータのコンテンツに基づいて前記データの第２の識別子を生成する動作、
（Ｄ）  前記第２の識別子を前記第２の識別子と比較して前記第１及び第２の識別子が同一であることを検証する段階を更に備える、方法。
【請求項７】
請求項１に記載の方法において、前記第１のコンピュータは前記第１のコンピュータによって格納されたデータを管理するファイルシステムを含み、前記識別子は前記ファイルシステムによりデータが格納されているファイルの名前として使用され、前記動作（Ｂ）は、前記識別子を前記ファイルシステムへの指標として用いて前記データを探索する動作を含む、方法。
【請求項８】
請求項１に記載の方法において、前記第１のコンピュータはサイロである、方法。
【請求項９】
請求項１に記載の方法において、前記第１のコンピュータはファイルサーバである、方法。
【請求項１０】
請求項１に記載の方法において、前記コンピュータシステムは前記第１及び第２のコンピュータに加えて複数のコンピュータを含み、前記複数のコンピュータは少なくとも一つのネットワークにより相互接続され、前記複数のコンピュータの各々は前記複数のデジタルアセットの一つ以上の格納を管理する、方法。
【請求項１１】
第１のコンピュータ及び第２のコンピュータを含むコンピュータシステムにおいて使用され、コンテンツをアドレス可能なストレージを提供する第１のコンピュータであって、
アクセスリクエストを受信する入力と、
前記入力に接続された少なくとも一つのコントローラであって、
前記入力を介してリクエストを受信して該第１のコンピュータによって格納されたデータにアクセスし、ここで、前記リクエストは、前記データのコンテンツに少なくとも部分的に基づく識別子により前記データを識別することであり、
前記識別子を用いて前記データを探索する少なくとも一つのコントローラとを備える、第１のコンピュータ。
【請求項１２】
請求項１１に記載の第１のコンピュータにおいて、前記データは、少なくとも一つの記述子ファイルを含む、第１のコンピュータ。
【請求項１３】
請求項１１に記載の第１のコンピュータにおいて、前記デジタルアセットは、少なくとも一つのデータと、該少なくとも一つのデータに関連するメタデータとを含む、第１のコンピュータ。
【請求項１４】
請求項１１に記載の第１のコンピュータにおいて、前記識別子は、暗号ハッシュ関数を前記データのコンテンツの少なくとも一部に適用することにより生成される、第１のコンピュータ。
【請求項１５】
請求項１４に記載の第１のコンピュータにおいて、前記識別子は、暗号ハッシュ関数を前記データのコンテンツの全体に適用することにより生成される、第１のコンピュータ。
【請求項１６】
請求項１２に記載の第１のコンピュータにおいて、前記記述子ファイルは、少なくともひとつのデジタルアセット用の第２の識別子と、前記少なくとも一つのデジタルアセットに関連するメタデータとを含み、前記第２の識別子は、前記少なくとも一つのデジタルアセットのコンテンツに基づくものである、第１のコンピュータ。
【請求項１７】
請求項１６に記載の第１のコンピュータにおいて、前記リクエストは、前記記述子ファイルを削除するリクエストであり、前記少なくとも一つのコントローラは、前記リクエストの受信に応答して前記記述子ファイルを削除する、第１のコンピュータ。
【請求項１８】
請求項１１に記載の第１のコンピュータにおいて、前記第１のコンピュータは前記第１のコンピュータによって格納されたデータを管理するファイルシステムを含み、前記識別子は、前記ファイルシステムによりデータが格納されているファイルの名前として使用され、前記少なくとも一つのコントローラは、前記識別子を前記ファイルシステムへの指標として用いて前記データを探索する、第１のコンピュータ。
【請求項１９】
請求項１８に記載の第１のコンピュータにおいて、前記識別子は前記データの少なくとも一部に暗号ハッシュ関数を適用することにより生成される、第１のコンピュータ。
【請求項２０】
請求項１９に記載の第１のコンピュータにおいて、前記識別子は前記データの全体のコンテンツに暗号ハッシュ関数を適用することにより生成される、第１のコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、情報をカプセル化し、その情報を識別し、その情報を表現するための方法および装置に関し、さらには、ユーザとユーザの間、リモートストレージと発信元のユーザの間、およびリモートストレージとリモートストレージの間における、コンピュータおよびデジタル通信網を使用した情報の伝送を促進するための、方法および装置に関する。
【背景技術】
【０００２】
デジタル情報は、大抵の場合、ある事象が起こった時点またはある時刻におけるアセット（ファイル等）の状態で表される、特定の状態にあること、が識別されなければならない。このようなアセットは、伝統的なデータファイルや、マルチメディアファイルおよび断片や、構造化データベースからのレコードや、何らかのアプリケーションもしくはデバイスで全体的もしくは部分的に使用されるその他のあらゆるデジタル情報ストリングを含む。デジタル情報は非常に改変しやすいことから、そのコンテンツを検査し、事前のある時間または事象以来改変されたかどうかを確実に認識できる方法は、ほとんど存在しない。コンテンツを改善もしくは完全化させる通常の試みや、コンテンツを改変する偶発的なコマンドもしくはアクション、またはデジタル情報のもとの所有者が知らないうちに他者が行う調節等は、発見することが非常に困難である。このように、コンピュータのユーザは、コンテンツの特定バージョンの初期状態を保ちまたは完全性を保持するのに便利なメカニズムを有さない。
【０００３】
デジタル情報（コンピュータファイル等）のもう１つの問題のある特性は、コンテンツが同一で、コンピュータシステムがデジタル情報を関連付けるのに使用するメタデータが異なるような、コピーが存在し得る点である。このようなメタデータは、ファイルを作成したかまたは最後に更新した日付／時刻、ファイルに関連づけられたファイル名、およびその他の情報を含む。メタデータは、実際には同一のデジタル情報のコピーを、誤って異なっていると判断させる恐れがある。このような混乱により、個別のコンピュータまたはネットワーク上のコンピュータの集合において、コンテンツの不必要な重複を避けるのが困難になる。また、このような混乱の結果、必要とされる特定のデータファイルが、すでにコンピュータシステム上またはネットワーク上で使用可能になっている場合でも、ネットワークまたは他のメディアを通じて不必要にコピーされる恐れがある。
【０００４】
特定のファイルが複数の名前で存在する場合にも、上述したのと類似の問題を生じる。コンピュータシステム上のデータは、一般に、識別子またはロケーションメカニズムを介してのみアクセスすることができる。このロケーションメカニズムは、多かれ少なかれ、コンピュータのストレージ内におけるファイルの場所に関する情報を含む。これは、他者によって容易に変更される要素を含んでいる、保存または記憶している名前を通じて、ユーザが、データにアクセスすることを意味する。例えば、何者かがサブディレクトリの名前を変更したとすると、サブディレクトリのファイルは危険な状態に陥る。もし変更されていたとすると、ファイルに至る経路が無効となり、保存または記憶しているファイル名も全て無効となる。このような、ロケーションに基づくデータ場所への脆弱なアプローチは、コンピュータシステムのユーザや管理者、なかでもネットワークシステムで働く者たちに、多くの問題を引き起こす。
【０００５】
結局、コンピュータのユーザは、デジタルファイルの特定バージョンの集合を識別するのに便利な方法を有さない。コンピュータまたはそのユーザには、ファイルのコピーを新しい形式で組み込んだ新しい実体を作成することなく、デジタルファイルの特定コピーまたは特定バージョンの集合を関連付けるための、確固としたメカニズムが存在しない。数多くのメカニズムが、このようなコピーをアーカイブファイルと通常呼ばれるファイルに集合させる目的で作成されてきた。アーカイブユーティリティの例としては、ＵＮＩＸ（登録商標）システムでよく見られるアーカイビングファシリティ:tar、およびパソコン上の各種zipプログラムが含まれる。このような解決策を使用すると、多くのシステムに至るまで増殖する追加のコピーが形成されることが多い。このような解決策の難点は、アーカイブ内のファイルの厳密なデジタルコピーの多くが、それらのコピー先であるシステムにすでに存在することにある。実際、多くのコンピュータシステムにおいて、全く同じコンテンツを有するデジタルファイルのコピーが多数存在している。既存の技術を使用する限り、このような同一コンテンツの複製は避けがたい。
【０００６】
このような問題点が存在するために、デジタルファイルの複製コピーが、コンピュータの記憶装置に（システム所有者の負担により）記憶されるか、またはメディアもしくは通信デバイス上を（システム所有者および通信プロバイダのさらなる負担により）伝送されることが、しばしば生じる。このような複製により、限られた資源が酷使され、ローカルプライベートネットワーク（例えばローカルエリアネットワーク）上およびデジタル通信網で接続されたシステム集合上で、不必要な混乱が生じてしまう。余分なコピーの作成にともなう問題点は、１つには、実際は同一のものを異なるものと見なしたり（そしてコピーが不必要に記憶される）、あるいは異なるものを同じファイル名だという理由で同一と見なしたりすることにある。
【０００７】
システムが、識別子が同一でバージョンが異なるファイルを確実に区別したり、または識別子が異なる同一のファイルを確実に認識したりすることができないと、ネットワークの資源が浪費され、ネットワークのユーザ間でファイルを伝送する際に、混乱が生じる。ユーザは多くの場合、自分が同一のドキュメント上で作業していること、または自分がアプリケーションの同一バージョンで作業していることを、知っていることが不可欠である。例えば、あるユーザが別のユーザへ電子メールを送信する際に、アプリケーションまたはドキュメントを含む添付のコンピュータファイルが一緒に送信されることはよくある。そして、アプリケーションを分散させるためのファイルを転送する必要もある。添付ファイルをともなった電子メールの送信、またはネットワーク内における１対１のスキームを使用したファイルの分散は、使用されるネットワークの帯域幅によっては非効率的になる恐れがある。例えば、ユーザが電子メールにファイルを数個添付した場合は、それらのうち１つまたはそれ以上のコピーが、予定される受信者のハードドライブにすでに格納されている可能性がある。このような場合、添付ファイルの転送に使用されるネットワークの帯域幅が、浪費されることになる。ファイルを確実に識別し、ファイルのコンテンツを確実に検証することができれば、受信者は、自分のハードドライブまたはローカルネットワークのサーバからファイルを呼び出して、電子メールのメッセージに添付されたものであるかの検証を行うだけで良い。
【０００８】
ネットワーク上でコンピュータを管理し、それらのコンピュータが一定のアプリケーションにより一定の方式で構成されていることを確認する際にも、上述したのと類似の問題が生じる。例えば、ネットワークで使用可能なオペレーティングシステムまたはハードウェアがわずかに変更されたとすると、そのネットワーク上の各コンピュータに、一定のファイルを転送する必要がある。ファイルを転送されるコンピュータは、必要なファイルの大部分またはほとんど全部を有しており、中央ソースから、残り数種のファイルを得るかまたは更新するだけで良いかもしれない。リクエストを出すコンピュータとソースコンピュータは、互いに遠く隔たっており、ローカルなデータリンクより低速のデータリンクによって接続されていることが多い。現時点では、リクエストを出しているコンピュータ上のファイルと、追加する必要があるファイルの両方の履歴を押さえ、適切な更新を行う必要がある。転送される予定のファイルを全て指定し、その指定した内容を、ファイルを最も便利な場所（できればローカルに）から呼び出せるようにカプセル化できる方法が、存在すると便利であろう。この方法は、ファイルが正しいファイルであることを確実に検証できるとさらに便利であろう。
【０００９】
上述した問題は、外部にあるソースからローカルエリアネットワーク（ＬＡＮ）にファイルを分散させる場合に、より深刻となる。例えば、ネットスケープ・コミュニケーション・コーポレーション等の会社がそのウェブサイト上に新しいウェブブラウザを提供すると、ある１社だけでも何百から何千という社員が、ネットスケープのウェブサイトからブラウザをダウンロードしようとする。これは、恐らく、必要なソフトウェアを社内に配置する最も非効率的な方法であろう。例えば、必要なファイルを同僚のところから確実に取って来られるとより効率的である。ファイル内の実際のデータを最も便利なソースから得られるように、何らかの方法で必要なファイルを一意に特定することができれば、全ユーザが外部のソースからファイルをダウンロードするのに使用しつくされる外部への帯域幅を、全て節約することができる。また、ユーザもより高速でファイルにアクセスすることができる。
【００１０】
ネットワーク上の各コンピュータに格納するファイルの組の指定、およびそのコンピュータでの正しいファイルの格納の確保という問題が、フィッツジェラルドらによる米国特許第５，５８１，７６４号に記述されている。フィッツジェラルドは、コンピュータネットワーク上で資源を分散させる方法を教示した。この方法は、ネットワーク上の各コンピュータに「すでにある」リストおよび「あるべき」リストを作成し、あるべきリストの最終更新日付／時刻（ＬＵＤＴ：Last Updated Date/Time）フィールドをすでにあるリストの最終同期化日付／時刻（ＬＳＤＴ：Last Synchronized Date/Time）と比較するプロセスを含む。このメカニズムは、システムクロックおよび日付設定の完全性に依存するが、このシステムクロックおよび日付設定は、偶発的または故意に偽りの設定が入力される恐れがあるため不確実である。さらに、このメカニズムは原則として、異なるシステムからの同一ファイルの識別を扱う場合に役に立たない。よって、更新の日時と同期化の日時を詳細に比較しなくても、ファイルを確実に指定し、必要なファイルを確実に識別することができる、フィッツジェラルドの方法に代わる方法があると便利であろう。
【００１１】
アリーらによる米国特許第５，７１０，９２２号は、コンピュータシステムの間で情報を同期化およびアーカイブするための方法を記述している。レコードの識別は、一意な識別の表示と、そのレコードが最後に変更された時刻を示す表示と、を使用して行われる。最後に同期化した際の時間情報を使用することにより、コンピュータシステムの１つにおいて最後に同期化して以来追加または削除された各選択レコードを識別し、それらをそのコンピュータシステムに追加するかまたはそこから削除する。一定の技術およびオペレーションでは、実際は変化していないレコードに対しても誤って変化を示す恐れがある。さらに、アリーによるメカニズムにはそういったメカニズムが提供されていないため、異なるシステムに存在する同一のデジタルファイルのコピーを、直ちに同一だと認識することができない。また、更新時刻および同期化時刻の分析を必要としたり依存したりせずに、ファイルシステムを同期化するような方法が、開発されると便利であろう。
【００１２】
一般に、周知のデータアセット（コンピュータファイル等）の状態を指定し、それらの一意なデータアセットへの（特にネットワークを経た）アクセスを提供するための、より確実、柔軟、且つ検証可能な方法が必要とされている。現時点では、データソースであるネットワークサイトを反映させて、データを提供するサーバの中で負荷を分散させるために、様々な負荷分散スキームが編み出されてきた。しかしながら、データへのアクセスを、共有および提供するための真の意味での分散システムは、これまで編み出されたことがなかった。すなわち、データへのアクセスを格納および提供するよう設計された指定された場所からデータを入手する代わりに、そのデータを見つけ得るネットワーク上の任意の場所から確実且つ自動的に入手できるような、分散システムは、これまで編み出されたことがなかった。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
以上から、ファイルを確実且つ検証可能な方法で転送すると同時に、ファイルを受信するサイトが最も便利なソースからファイルを獲得することができる、方法および装置が必要とされていることがわかる。さらに、これらの技術は、効率的な方法でファイルを獲得し、もし可能ならばローカルシステム内から（locally）ファイルを獲得し、獲得したファイルのコンテンツが転送するはずだったファイルのコンテンツと同一かどうかを検証するものであることが望ましい。また、システムまたはネットワーク内で格納または転送されるデータを最小化する、方法および装置が必要とされている。これらの技術は、在来のやり方でコンピュータシステム上に格納されるメタデータを専ら使用するよりも、むしろコンテンツに基づいてデータの識別、探索、およびアクセスを実施するような、確かなメカニズムを提供するものであることが望ましい。
【課題を解決するための手段】
【００１４】
以上の要請に基づき、電子紙用クリップまたはｅ−ＣＬＩＰ（商標）内でデジタル情報を表現するための、システムおよび方法が開示される。ｅ−ＣＬＩＰは、デジタル情報を収集するための、再現性があり、高度の信頼性のもとで一意な識別子であり、デジタル情報自身のコンテンツから導出されるものである。本発明の一実施形態におけるｅ−ＣＬＩＰは、英数字指示である。ｅ−ＣＬＩＰは、ファイル、ファイルのグループ、ファイル識別子のグループ、またはデータもしくはデータベース情報のその他集合の表現であって良い。このようなデータもしくはデータベース情報のその他集合は、リレーショナルで階層型のネットワークもしくはその他のフォーマットデータベースからの選択データベースレコードか、デジタルオーディオもしくはビデオストリームからの選択フレームもしくはクリップか、メッセージレコードもしくはファイルのストリームからのメッセージか、システム、サブシステム、および／もしくはアプリケーションの追跡ログもしくは状態ログからのログ入力か、またはその他のあらゆるデジタルアセットを含んで良い。そして、そのようなデータもしくはデータベース情報のその他集合は、ある前後関係の中で、ある具体的な時刻において、他に代え難い一意な（unique）重要性を有する状態となる。アプリケーションが、本発明を実施して、メカニズムまたはシステムに一意なデジタルアセットを提供する限り、これら各アセットのオリジナルな形またはコンテキストは無意味である。本発明は、上述したような一意なアセットおよび関連づけられたメタデータに基づいて作用し、一意で有用な識別子を作成する。その識別子によって、将来、オリジナルから複製を制作するための、関連するアセットの永続的なストレージを形成することができる。
【００１５】
暗号ハッシュ関数を使用して、表現されているデータのための識別子を計算する。各バイナリアセットは、潜在的に一意なバイナリ配列（binary sequence）として扱われる。つまり、あらゆるバイナリ実体は、潜在的に一意な有限長さのパターンと、その後に続くバイナリ数字（digits）の列を有する。よって、ある時刻におけるバイナリアセットは、一意であるかまたはそうではないかもしれないバイナリ配列である。暗号ハッシュ関数の使用により、バイナリ配列を仮想的に一意に（uniquely）識別するデジタル指紋またはサインが確立される。また、暗号ハッシュバイナリ配列の識別子は、コンテンツでアドレスを特定できるような（content-addressable）データの名前、またはコンテンツベースのデータの名前だと見なされる。ファイルまたはその他デジタルアセットのグループが表現されると、暗号ハッシュ関数を使用して各ファイルの識別子が作成され、記述子ファイル内に配置される。また、記述子ファイルは、ファイル、レコード、またはファイル、レコード、もしくはアセット名、サイズ、日付および時刻スタンプ、ならびにその他記述型データもしくは属性等の、その他アセットメタデータはもちろんのこと、任意のディレクトリ構造（リレーショナルまたは階層型の関連を含む）情報等の、メタデータをも含む。また、記述子ファイルは、集合（作成時の時刻および日付、作成者のユーザＩＤ等）の作成に関するコンテクスト情報をも含む。次いで、暗号ハッシュ記述子ファイル識別子（または記述子ファイルハッシュ）が、記述子ファイルに対して計算される。
【００１６】
ｅ−ＣＬＩＰは、記述子ファイルハッシュを含んでおり、ファイル名またはＵＲＬ等のファイルロケータを含んでいても良い。ファイルロケータは、便利な格納場所内においてローカルに記述子ファイルを見つけられない場合に、記述子ファイルを獲得し得るようなソースを与えるものである。バイナリ配列ハッシュおよび記述子ファイルハッシュ（バイナリ配列ハッシュの特殊なケースである）は、関連したバイナリ配列の識別子であり、立証に用いることができるような、一意なものである。このように、アセットの識別子（キー、ロケータ、またはその他のメカニズム）としてハッシュを使用することにより、これらのシーケンスを、ファイル、データベースレコード、またはその他のデジタル実体として格納および検索するための、基礎が形成される。ハッシュがバイナリ配列そのもの即ちデジタルコンテンツから導出されるため、このようなアプローチは、コンテンツでアドレスを特定できるような（content addressable）ストレージの提供、ということができる。
【００１７】
本発明のある形態は、各ファイル／レコード／アセットに関連づけられたメタデータ、これらのアセットのそれぞれまたは全体に関連づけられた他のデータ、および集合に関するコンテキスト・データも、記述子ファイルに含まれている点において有利である。このため受信者は、記述子ファイルを獲得する際に、各アセットに関する重要なメタデータ、および集合に関するコンテキスト情報をも受け取る。メタデータは、所有の在処を示し、更新の日付を示し、または各ファイルに関するその他必要な情報を提供する目的で、ファイル／レコード／アセットのさらなる検証を行うのに使用されても良い。また、本発明の一実施形態は、ファイルディレクトリ構造にファイルリストも含まれている点において有利である。このようなファイルディレクトリ構造は、ファイルを各フォルダの中でどのように編成するかを決定するのに役立つ。例えば、あるコンピュータにおいてデータが失われたとすると、ファイルリストは、失われたファイルを識別するだけでなく、そのファイルを適切なディレクトリ構造に再編成するのにも、使用されることができる。同様に、記述子ファイル内に登録されたデータベースレコードに関するメタデータは、これらのレコードが属する表またはファイルを識別するのに、使用されることができる。これらは、オーディオまたはビデオクリップ等の、他の形態のデジタルアセットと比較されることができる。
【００１８】
ｅ−ＣＬＩＰは、キーボックスへのキーとして機能する。ここで、キーボックスは記述子ファイルであり、キーはバイナリ配列識別子（またはバイナリ配列ハッシュ）である。キーという用語の使用は、本発明の文脈において暗号またはその他の意味を有するものではない。ｅ−ＣＬＩＰは、バックアップされたり転送されたりしたファイルのグループを識別するのに役立つ。ユーザ（またはシステム）は時には、ｅ−ＣＬＩＰのみを手がかりにしてファイルにアクセスしようとすることもできる。
【００１９】
ｅ−ＣＬＩＰを使用して記述子ファイル（またはキーボックス）を発見すると、記述子ファイル内の一意なバイナリ配列識別子を使用して、各バイナリ配列識別子に対応するファイル／レコード／アセットを発見することもできる。特定のバイナリ配列がソースから獲得されたら、暗号ハッシュ関数を使用してバイナリ配列識別子を再計算して、獲得されたアセットが、アクセスする予定だった正しいアセットであるかどうかを検証する。ｅ−ＣＬＩＰで格納および参照できるデータ、メタデータ、またはファイルシステムの構造に、制限はない。
【００２０】
本発明は、工程、装置、システム、デバイス、方法、またはコンピュータ読み取り可能媒体を使用して等などの、多くの方法により具現することができる。
１つの実施形態では、複数のアセット（ファイル、レコード、またはその他のデジタルアセット）を表現するためのシステムおよび方法が開示される。この方法は、転送される複数のアセット（バイナリ配列）を選択する工程を含む。複数のアセットに対し、複数の暗号ハッシュバイナリ配列識別子を作成する。複数の暗号ハッシュアセット識別子は、それぞれ特定のアセットのコンテンツをもとに計算される。転送される複数のアセットをもとに計算される複数の暗号ハッシュバイナリ配列識別子を含む、記述子ファイルが作成される。そして、記述子ファイルから計算される、暗号ハッシュ記述子ファイル識別子が作成される。計算された暗号ハッシュ記述子ファイル識別子は、別の識別子リスト等に含まれても良いため、複雑な構造を、極めてコンパクトな形に簡略化して表現することができる。
【００２１】
もう１つの実施形態では、アセットを識別する方法が開示される。この方法は、識別されるアセットを選択する工程を含む。選択されたアセットに対し、暗号ハッシュアセット識別子を獲得する。選択されたアセットのコピーを獲得して、そこから暗号ハッシュファイル識別子を再生し、識別されたアセットの暗号ハッシュアセット識別子と比較することにより、コピーの完全性の検証を行う。
【発明を実施するための最良の形態】
【００２２】
次に、本発明の好ましい実施形態を詳しく述べる。添付した図面には、好ましい実施形態の一例が示されている。以下では、本発明を好ましい実施形態と関連させて説明するが、これは、本発明を１つの好ましい実施形態に限定することを意図するものではない。反対に、翻案、変更態様、および均等物も、カバーされて、添付した請求の範囲により定義される本発明の精神および範囲に含まれる、と考えられる。例えば、添付した図面の多くは、本発明を在来のコンピュータファイルに使用した場合を示して理解の促進を図っているが、上述したように、本発明はあらゆるデジタルアセットまたはバイナリ配列への使用にも適している。
【００２３】
以下の説明では、本発明の完全な理解を促すために多くの項目を特定している。しかしながら、本発明は、これらの項目の一部または全てを特定しなくても実施することができる。そのほか、本発明を不必要に不明瞭化するのを避けるため、周知の処理工程の説明は省略した。
【００２４】
あらまし
本発明は、ユーザが定義したバイナリ配列（デジタルアセット）集合内の各バイナリ配列に対して、確実に一意なバイナリ配列識別子（バイナリ配列ハッシュまたは暗号ハッシュバイナリ配列識別子とも呼ばれる）を作成する、技術およびメカニズムを提供する。これらのバイナリ配列識別子は、本発明による記述子ファイルに格納されているため、ファイルの集合が再構築または検証された際に、それら収集されたファイルの真の且つ正確なコピーを識別および／または検証することができる。さらに、確実に一意な記述子ファイル識別子（または記述子ファイルハッシュ）が記述子ファイルに対して作成され、ファイル集合の表現として機能する。
【００２５】
本発明を使用すると、デジタルアセットのあらゆる集合を検査することにより、集合内の各アセットが特定のコンピュータシステムまたはネットワーク上に存在するかどうかを、そのアセット全体の参照コピーを参照したり、または誤認を導く可能性がある外来的なネーミングもしくは場所的な情報に依存したりすることなく、確証することができる。こうすると、システムまたはネットワークに欠けていると確証できるアセットのみを、アセット集合の再生のために他のソースから獲得すれば良い。本発明の好ましい実施形態は、データファイルであるデジタルアセットを主として扱う。本発明の好ましい実施形態は、適切なインターフェースで簡単に拡張されることができ、それにより、全種類の構造化ファイルおよびデータベースからのレコード、マルチメディアデータ（例えば、デジタルオーディオまたはデジタルビデオ等）のストリームからの選択もしくはクリップ、または他の構造化もしくは非構造化デジタルデータ（バイナリ配列）からの選択もしくはサブセット等のデジタルアセットにも、同等に作用することができる。
【００２６】
本発明の好ましい実施形態では、デジタルアセットのコンテンツを使用して数学および／または論理演算による一意なバイナリナンバ（a unique binary number）を形成する、暗号ハッシュ関数のクラスの１つを使用する。このような関数は、一般にデジタル情報の暗号化に使用されており、デジタルデータの仮想的にあらゆる特殊な組み合わせに対して一意なバイナリナンバを生成するための代替法を記述する拡張ボディが存在する。好ましい実施形態では、周知のＭＤ５アルゴリズムを使用する。ただし、確実に一意なアセット識別子の生成には、他の多くのアルゴリズムも同様に使用できることを認識しておく必要がある。アルゴリズムは、デジタルファイルのあらゆる特殊インスタンスに対し、一貫して同一のバイナリナンバを形成することが好ましく、このようなバイナリナンバは、識別されるバイナリファイルのクラスに対して適度に高い確率で一意であることを、事実上確証されている必要がある。同一の暗号ハッシュ（バイナリナンバ）に帰着する２つのバイナリ配列については、それら２つのバイナリ配列が同一であることを暗号ハッシュが示している、ということが、このようなアルゴリズムにより立証される。逆に、異なる暗号ハッシュ（バイナリナンバ）に帰着する２つのバイナリ配列については、暗号ハッシュは、それらの２つのバイナリ配列が異なるものであることを示している。このようなアルゴリズムにより、特定のバイナリ配列のコピーを識別するのが簡単になる。
【００２７】
デジタルアセットのユーザ定義の集合、関連のメタデータおよびコンテキスト・情報をひとまとめにして、記述子ファイルが形成される。図２に、記述子ファイルの一例が示されている。このように、記述子ファイルは、デジタルアセットへのキーのボックスまたはリストとして特徴付けることができる。また、記述子ファイルはそれらのアセットに関する他の情報も含む。このキーボックスは、独立したデジタルアセットとして扱われ、その一意なコンテンツから自身のキーが導出される。結果として得られるキーは、キーボックスへのキーであり、デジタルアセットの集合を表現するｅ−ＣＬＩＰの形成に使用することもできる。
【００２８】
ユーザまたはシステムは、信頼に足るあらゆるソースからｅ−ＣＬＩＰを獲得することができる。そしてそのｅ−ＣＬＩＰを使用して、アセット情報の集合をさらに含む記述子ファイルの、正確なコピーを発見または識別することができる。本発明を使用してオリジナルなアセットのコピーが発見されれば、そのアセットを、オリジナルなアセットの正確なコピーとして安全に扱うことができる。アセットが記述子ファイルである場合は、それを読み取ったり開いたりすることができ、デジタルアセットの集合に対する暗号ハッシュバイナリ配列識別子を獲得することができる。これらのバイナリ配列識別子に対応するファイルは、提供されたバイナリ配列識別子を、暗号ハッシュ関数を使用して新たに導出されたバイナリ配列識別子と比較することにより、獲得および検証しても良い。
【００２９】
記述子ファイルで識別されたファイルを発見できない場合には、ファイルの集合を再構築することができない。これは、フラストレーションを引き起こすものとなりうる事実である。それにもかかわらず、上述した方法により、ファイルの集合を確実に再生できるか、または使用不可能であることを同程度の確実性で立証できるような、メカニズムが提供される。
【００３０】
好ましい一実施形態では、デジタルアセットの選択集合内の各デジタルアセットに対して暗号ハッシュバイナリ配列識別子を生成し、記述子ファイルを形成した。暗号ハッシュバイナリ配列識別子は、各アセットの実際のデータコンテンツ上で暗号ハッシュ関数を使用して生成された。幾つかの実施形態では、アセット全体を使用して暗号ハッシュバイナリ配列識別子を生成し、その他の実施形態ではアセットを部分的に使用した。暗号ハッシュバイナリ配列識別子が一意である可能性を確実にするためには、十分に大きい部分のアセットを使用することが好ましい。別の実施形態では、異なる暗号ハッシュ関数を使用した。好ましい一実施形態では、ＭＤ５アルゴリズムを使用し、ファイルを表現する１２８ビットの数字を生成した。１２８ビットの数字は、ｂａｓｅ３６への翻訳により２６文字の英数字ストリングとして表現される。そしてｂａｓｅ３６は、ｂａｓｅＡＳＣＩＩ文字セット内の英字および数字のセットにマッピングされる。好ましい一実施形態では、結果として得られるストリング内の事前決定位置にフラグ文字が含まれており、これによってストリングの全長は２７文字となる。このマッピングはＡＳＣＩＩ Ａｒｍｏｒｉｎｇと呼ばれ、一般に、コンテンツを英数字のバイナリコードに限定する必要があるプロトコルを介してデータを送信するために、バイナリ情報を限定文字セット内に制限するのに使用される。
【００３１】
上述したように、暗号ハッシュバイナリ配列識別子のこの特定の表現方法は、人にも判読でき、容易に伝達して使用できる、という利点を有する。例えば、書き留める、ソフトウェアにより送信する、データの問い合わせにより検索する、ソフトウェアアプリケーションのファイルリクエストにコード化する、コンテンツまたはアセットの管理システムで参照する、オブジェクトブラウザ内でリクエストする、電子コピーをとってドキュメントからドキュメントへ引き渡す、電子メールで送る、等などが可能である。
【００３２】
１つの実施形態では、ＭＤ５アルゴリズム等の暗号ハッシュ関数を使用して、暗号ハッシュバイナリ配列識別子を生成する。これは、暗号ハッシュ関数は、同一の暗号ハッシュバイナリ配列識別子上に類似のアセットがマッピングされる可能性を最小化することが、数学的に立証されているからである。これは、暗号ハッシュバイナリ配列識別子が一意なアセット識別子として使用されており、２つのアセットから同じ暗号ハッシュバイナリ配列識別子が生成されると、それらのアセットは同一だと断定的に示されたと見なされる点において、重要である。反対に、異なるバイナリ配列が異なるバイナリ配列識別子を形成し、その結果としてそれらのバイナリ配列が同一でないことを断定的に示せる点においても、やはり有用である。ＭＤ５アルゴリズムは高い信頼水準を有しているため、ユニークなアセット識別子を形成する技術として信頼が高い。
【００３３】
異なるファイルから同一の識別子を生成する可能性が、許容可能だと見なされる閾値未満である限りにおいて、アセット識別子を生成するために、その他のハッシュ関数、またはバイナリ配列（コンテンツ）をもとにしたその他のタイプの関数を使用しても良い。
【００３４】
選択された各アセットに対して生成された暗号ハッシュファイル識別子は、その他のアセット情報とともに記述子ファイル内に含まれる。ここで、ファイルリストに含まれるその他のアセット情報は、ファイル名、ファイルのサイズ、各アセットの時刻および日付スタンプ、アセットの所有の在処、ならびに以下で説明するその他のアセットメタデータはもちろんのこと、アセットがコンピュータシステム内でどのように組織されたかに関するディレクトリ情報を含んでも良い。また、記述ファイルは、アセット集合のコンテキストもしくは関係（インプリケーション）に関するデータ、集合が形成された目的、またはその他あらゆる情報を含んでも良い。次に、好ましい一実施形態において、記述子ファイルは、自身が属するコンピュータシステムのタイプまたはその他の環境に適した形でデジタルファイルに格納される。他の実施形態では、記述子ファイルは、データベース、または、便利で効率的で安全なストレージと検索能力を提供できるその他のデジタルリポジトリに格納されても良い。次いで、格納された記述子ファイルに対して、暗号ハッシュバイナリ配列識別子が算出される。これは、１つの実施形態において、収集されたアセットを参照、発見、および検証できるｅ−ＣＬＩＰとなる。ここで、集合を識別するｅ−ＣＬＩＰが、記述子ファイル内で命名および列挙された各アセットに対して暗号ハッシュバイナリ配列識別子を計算するのに使用したのと同じアルゴリズムによって作成される点を、認識する必要がある。他の実施形態では、記述子ファイルのバイナリ配列識別子は他の情報（ファイルロケータ等）と組み合わされてｅ−ＣＬＩＰを形成する。
【００３５】
ｅ−ＣＬＩＰの生成
図１は、リスト内のアセットに対するメタデータおよびコンテキスト・データを含む、アセットリストの暗号ハッシュバイナリ配列識別子を形成するための、工程を示した流れ図である。ステップ１０２において、表現されるアセットのリストが選択され、アセットデータ、メタデータ、および／またはコンテキスト・データが収集される。アセットのリストは、複数のアセットもしくは１つのアセットを含んで良く、またはアセットを含んでいなくても良い。アセットのリストは、ｅ−ＣＬＩＰを含む、前もって形成された記述子ファイルまたはアセットすら含んでも良い。記述子ファイルにデジタルアセット（ファイル、データベースレコード、マルチメディアクリップ等）が含まれていない場合は、形成される記述子ファイルは、選択されたスキームを使用してデジタルアセットを探索および獲得するのに使用される他のデータを含んでも良く、または、独立したバイナリ配列への参照なしにメタデータおよびコンテキスト・データの変数集合を含んでも良い。このような場合においても、記述子ファイルに対する暗号ハッシュバイナリ配列識別子は、依然として、記述子ファイル内のデータの完全性を保証するものである。
【００３６】
少なくとも１つのアセットが選択された場合は、ステップ１０４において、選択された各アセットに対して暗号ハッシュバイナリ配列識別子が生成される。上述したように、１つの実施形態において、暗号ハッシュバイナリ配列識別子の生成にＭＤ５アルゴリズムが使用される。このため、暗号バイナリ配列ハッシュは、各アセットに対するアセット識別子として使用される。ステップ１０６において、各アセットに関連づけられたメタデータ、アセットに関するメタデータ、集合に関するコンテキスト・データ、およびステップ１０４で生成された暗号ハッシュバイナリ配列識別子を使用して、記述子ファイルが形成される。記述子ファイルの一例を図２に示した。
【００３７】
ステップ１０８において、記述子ファイルそのものから暗号ハッシュが生成される。記述子ファイル内の各暗号ハッシュバイナリ配列は、暗号ハッシュファイル識別子が識別するデジタルアセットへのキーだと考えて良い。このため、記述子ファイルは、キーの集合またはボックスだと考えることができる。記述子ファイルの暗号ハッシュバイナリ配列識別子は暗号ハッシュバイナリ配列リスト識別子と呼ばれ、記述子ファイル内に列挙されたキーボックスへのキーだと考えることができる。暗号ハッシュバイナリ配列リスト識別子は、記述子ファイルの探索および検証に使用される。そして今度は記述子ファイルのコンテンツが、記述子ファイル内に表現された各アセットの探索および検証に使用される。ステップ１１０において、暗号ハッシュバイナリ配列リスト識別子がＡＳＣＩＩフォーマットに変換される。上述したように、１つの実施形態において、１２８ビットのファイルリスト識別子は２７文字のｂａｓｅ３６ ＡＳＣＩＩストリングに変換される。こうして、２７文字のストリングは人が判読可能なテキスト形式になり、処理、参照、または格納のために手動または電子的にコピーすることができる。
【００３８】
１つの実施形態において、暗号ハッシュバイナリ配列リスト識別子はバーコードとして格納される。これは、オブジェクトに関する識別情報が、オブジェクト自体の上に配されている際に特に有用である。例えば、電子レンジやビデオデッキ（VCR）等の電気器具は、その装置の上に、暗号ハッシュバイナリ配列リスト識別子を表現するバーコードを有することができる。この識別子は、その電気器具のマニュアルやそのほか関連する資料を含むアセットから生成される。このため、マニュアルおよび関連資料は、以下のようにして得られる。すなわち、バーコードを走査し、記述子ファイル識別子を読む。その記述子ファイル識別子に対応する記述子ファイルを獲得する。その記述子ファイルと、その中の個別のバイナリ配列識別子を読む。そのバイナリ配列識別子に対応するデジタルアセットを獲得する。そして最後に、マニュアルおよび関連資料を含む獲得されたアセットを読む。他のインデックスまたはソフトウェアアプリケーションについて、データまたはソフトウェアコードを含んだ他のデジタルアセットを指定し、検索し、および獲得するために、類似のコーディングを使用することができる。
【００３９】
ステップ１１２において、ＡＳＣＩＩストリングが一意な識別子またはｅ−ＣＬＩＰとして格納される。一意な識別子は、人または電子手段のいずれかによっても容易に読み取るまたはコピーすることができる。次のステップ１１４では、一部の実施形態において、一意な識別子が（ｅ−ＣＬＩＰのヒントとしての）ファイルロケータと組み合わされてｅ−ＣＬＩＰを形成する。ファイルロケータは、記述子ファイルとされるものおよび関連づけられたデジタルアセット（バイナリ配列）が存在する可能性がある場所を示す。ここで、多くの実施形態において、ｅ−ＣＬＩＰが記述子ファイルロケータ（ｅ−ＣＬＩＰのヒント）を必要としない点に注意が必要である。しかしながら、記述子ファイルを発見し得る場所として、記述子ファイルロケータが含まれていると有益な場合が多く、記述子ファイルまたは１つもしくはそれ以上の関連づけられたデジタルアセットが、便利な場所ですぐに発見されない場合などに、特に有益である。
【００４０】
このためｅ−ＣＬＩＰは、一意な識別子として表現され、１つの実施形態では、人による判読が可能なバージョンの、暗号ハッシュバイナリ配列リスト識別子である。暗号ハッシュバイナリ配列リスト識別子は、任意のサイズ、タイプ、複雑性、およびファイル構造などの情報を、一意に参照するもの（a unique reference）である。つまり、暗号ハッシュバイナリ配列リスト識別子は、任意数のデジタルアセットを表現していて良く、これらのデジタルアセットはさらに、ファイルシステムの構造、データベースの関連、マルチメディアコンテンツの情報、またはその他の有用な情報に関する任意量のメタデータにより記述される。記述子ファイル内で指定されたディレクトリ構造の一例を、図２に示した。
【００４１】
図２は、記述子ファイル２００の構造を示した図である。図示された特定の記述子ファイルは、ＸＭＬにもとづいたハイパーファイルモデリング言語（ＨＦＭＬ）を使用して、ファイル自体はもちろん、ファイルを含んだディレクトリの構造も記述する。ＨＦＭＬは、上述した仮特許出願に記述されている。一般に、ｅ−ＣＬＩＰの実装は、このシンタックスで書かれた記述子ファイルに限定されない。この好ましい実施形態でＨＦＭＬを使用するのは、ＨＦＭＬが容易に中身を解析できて、記述子ファイルに含まれるファイルおよびキーのツリー構造のディレクトリを生成するのに使用できるためである。この例では、特定の形態を有したコンピュータおよびソフトウェアから得られるファイルおよびキーの記述に、範囲を限定している。本発明は、記述子ファイルの形成に使用される言語またはコードの拡張を提供し、あらゆるデジタルアセット、関連、ならびにその他のメタおよびコンテキスト・データを仮想的に無制限に記述する。
【００４２】
記述子ファイル２００内の第１の項目は、フォルダ２０２である。フォルダ２０２には、時刻スタンプ２０６はもちろんフォルダ名２０４も含まれている。フォルダ２０２は、フォルダ２０２の終了を記すエンドフォルダタグ２０８と対をなす。フォルダ２０２の中にネストされた（入れ子になっている）中身は、第１のネストフォルダ２１２である。フォルダ２１２は、フォルダ名および時刻スタンプ２２６を含む。ファイル２２２は、フォルダ２１２の内部に含まれる。ファイル２２２は、ファイル名２２４、時刻および日付スタンプ２２６、サイズ２２８、ならびに、ＭＤ５アルゴリズムにより生成され２７文字のストリングとして表現される暗号ハッシュファイル識別子２３０を含む。同様に、フォルダ２１２もまたファイル２３２を含む。ファイル２３２は、ファイル名２３４、時刻および日付スタンプ２３６、サイズ２３８、ならびに暗号ハッシュファイル識別子２４０を含む。フォルダ２１２は、エンドフォルダタグ２１９と対をなす。
【００４３】
他のフォルダ内に、希望する任意数のフォルダを表現およびネストできる（入れ子にできる）ため、ディレクトリの各フォルダ内で指定される任意数のファイルにより、任意のツリー構造のディレクトリを指定できることは明らかである。各ファイルは、ファイル名、および希望するその他のメタデータに加えて、ファイルのコンテンツにもとづいてファイルを一意に識別する暗号ハッシュバイナリ配列識別子を含有して良い。幾つかの実施形態では、暗号ハッシュバイナリ配列識別子がファイルの唯一の識別子であり、他の実施形態では、ファイルに従来のファイル名も付随している。
【００４４】
このため、ｅ−ＣＬＩＰで指定された記述子ファイル（例えばコンピュータがクラッシュした後に）が回復し、記述子ファイルが（恐らくその他のデジタルアセットに加えて）コンピュータファイルの定義を含んでいる場合には、ｅ−ＣＬＩＰで指定されたファイルの完全なファイル名およびディレクトリ情報を、獲得できることがわかる。記述子ファイルを呼び出して、その記述子ファイルで指定されたファイルを発見する工程を、図３に示した。
【００４５】
ファイルの呼び出し
図３は、ｅ−ＣＬＩＰを使用して、記述子ファイルとデジタルアセット（バイナリ配列）の両方を発見するための工程を示したフローチャートである。この例において、デジタルアセットとは、記述子ファイル内において指定されるファイルであり、記述子ファイルで指定されたディレクトリ構造内にファイルを入れるためのものである。ステップ３０２において、ｅ−ＣＬＩＰが受信される。ｅ−ＣＬＩＰは、ファイルのセットを指定するのにユーザにより使用され、電子メールのメッセージに組み込まれた形で受信されても良いし、あるいは代わりに、ｅ−ＣＬＩＰ内で指定されたファイルおよびディレクトリのバックアップを実施するネットワークデバイスにより、自動的に生成されても良い。ｅ−ＣＬＩＰは、ビジネスアプリケーションにより作成されて、特定の取引に関係する関連のデジタルアセットを指定する物であってもよい。また、ｅ−ＣＬＩＰは、何らかの目的のためにファイルまたはファイルのグループを一意に指定する必要があるような、任意のユーザ、ネットワークノード、アプリケーション、またはハードウェアデバイスにより、他の理由のために生成されても良い。このようなｅ−ＣＬＩＰは、データベースアプリケーション、メインフレーム上を走るレガシーアプリケーション、テキスト検索アプリケーション、ウェブサイト等などに組み込まれ、そこから直ちにアクセスされても良い。
【００４６】
ステップ３０４において、ｅ−ＣＬＩＰの受信者は、ｅ−ＣＬＩＰ内において発見された一意な識別子に対応するファイルを求めるリクエストをブロードキャストする。次に、ステップ３０６において、ｅ−ＣＬＩＰの受信者は、一意な識別子に対応しているとされる記述子ファイルを受信する。次に、ステップ３０８において、受信者は、ｅ−ＣＬＩＰ内で発見された一意な識別子を生成するのに使用されたのと同じ暗号ハッシュ関数を使用して、受信された記述子ファイルの暗号ハッシュを計算する。ステップ３１０において、受信者は、ｅ−ＣＬＩＰ内で発見された一意な識別子が、記述子ファイルの暗号ハッシュの結果と一致するかどうかを検証する。一意な識別子が適切に検証されなかった場合は、制御がステップ３０４に転送されて戻され、ｅ−ＣＬＩＰ内で識別されたファイルを求めるリクエストが再び送信される。また、エラーメッセージまたはその他の通知も生成される。
【００４７】
ステップ３１０において一意な識別子の検証がなされると、ステップ３１２に制御が転送され、受信者は記述子ファイル内で指定されたディレクトリ構造を構築する。システム設定を実施するためにプログラミング論理が適用され、必要なディレクトリを形成するために、例えばＨＦＭＬにより記述されるようなプログラミング演算を使用したファイル演算が適用される。ディレクトリ内の各フォルダは、指定された構造にもとづいて形成されることが好ましい。次に、ステップ３１４において、ｅ−ＣＬＩＰの受信者は、記述子ファイル内に列挙されたファイルを求めるリクエストをブロードキャストする。図６Ａは、ファイルリクエストの構造の一例を示したものである。
【００４８】
リクエストされたファイルのコピーを提供するレスポンスを分析し、使用可能なソースのうち最も効率的なソースから、ファイルのコピーを引き出す。使用可能なソースは、ローカルファイルシステム、受信者が実行しているシステムで使用可能なローカルネットワークファイルシステム、ファイル転送プロトコル（ＦＴＰ）等の標準的なネットワークプロトコル、または作成もしくは指定され得る任意の他のネットワークプロトコルを通じて等を含む。
【００４９】
ステップ３１６において、ｅ−ＣＬＩＰの受信者は、リクエストされたファイルを受信し、ファイルデータの暗号ハッシュを生成して得られた結果を記述子ファイル内に列挙されたファイル識別子と比較することにより、ファイルコンテンツの検証を行う。ファイルのどれかが検証テストを通過しなかったら、これらのファイルは再リクエストされて、適切な通知が生成される。こうして、工程が終了する。
【００５０】
こうして、ｅ−ＣＬＩＰの受信者は、ｅ−ＣＬＩＰ内の一意な識別子で識別された記述子ファイルへのリクエストをブロードキャストする。記述子ファイルが受信されると、ｅ−ＣＬＩＰの受信者は、正しい記述子ファイルが回復したかどうかを検証できるようになり、次いで、その記述子ファイル内で指定されたファイルへのリクエストをブロードキャストする。これらのファイルは、受信および検証されたら、記述子ファイル内で指定されたディレクトリ構造に挿入される。ファイルへのリクエストをブロードキャストする工程、ファイルを受信および検証する工程、ならびにブロードキャストされたリクエストを変更する工程は、１つの実施形態ではインポータを使用して達成される。インポータは小プログラムであり、好ましくはＪａｖａプログラミング言語内に、またはその他任意の適切な言語内にエンコードされている。
【００５１】
図４は、図３のステップ３１６で指定されているように、ファイルなどのリクエストされたデジタルアセット（バイナリ配列）の受信、およびそれらのファイル識別子の検証に使用される、インポータ上で走る工程を示したフローチャートである。ここで、このようなファイル識別子のリクエストおよび検証には、本発明の精神および範囲内で、他の工程および言語を使用できる点に注意が必要である。ステップ４０２において、インポータはファイルの受信を待機する。ファイルが受信されると、制御がステップ４０４に転送される。ファイルを断片的に受信し、これらの断片を組み合わせる工程を、図５でさらに説明する。ステップ４０４において、インポータは、受信されたファイルの暗号ハッシュが、ファイルのリクエストで送信されたファイル識別子と一致するかどうかを検証する。ファイル識別子が一致しなかった場合は、制御がステップ４０６に転送され、エラーハンドラがアクティベイトされる。すると、ステップ４０８においてファイル全体へのリクエストが生成され、制御が再びステップ４０２に転送されて戻される。
【００５２】
しかしながら、もしファイルが一致した場合には、ブロードキャストのためのファイルリクエストリストがステップ４１０において更新され、制御がステップ４１２に転送される。ステップ４１２では、ｅ−ＣＬＩＰ内で識別される記述子ファイル内で指定されたファイルが全て受信されたかどうかが決定される。ファイルが全て受信されていた場合は、制御がステップ４１４に転送され、全てのｅ−ＣＬＩＰファイルが獲得されたことが示される。こうして、工程が終了する。全てのファイルが受信されていない限り、制御はステップ４１２からステップ４０２に戻ることを繰り返し、残りのファイルの受信およびチェックが行われる。
【００５３】
ここで、この説明で使用される例が、全てファイルを参照している点に注意が必要である。しかしながら、アセットは、データベースレコードへのアセット、より大きなビデオストリーム内から取られたビデオクリップ、または他のソフトウェアプログラムもしくは処理に引き渡されるために格納されたその他のデジタルアセットでも良い。ディレクトリを初期化して、デジタルアセットのコンテンツを有するファイルを新規に形成するよりも、受信者はむしろ、その他のスタンダードアプリケーションプログラミングインターフェースを介し、それらのファイルを使用可能とすることを選択するであろう。アセットをリクエストする工程、アセットのコンテンツを検証する工程、アセットを一時的で検証のための保持領域内に維持する工程、ならびに全てのアセットが受信および検証された後に、その集合を使用可能とする工程は、デジタルアセットのタイプまたはソースに関わらず、あらゆるデジタルアセットの集合に対して論理的に同じものである。
【００５４】
コンテンツでアドレスを特定できるような（content-addressable）アセット識別子を使用した、デジタルアセットを検証および検証するためのこのタイプの手続きは、アセットの完全性を確実にし、自動的にスプーフィング（spoofing）およびウイルス感染を排除し、失われたアセットの自動または手動による再構築を可能とする。本発明による、コンテンツでアドレスを特定できるアセット識別子のシステムは、識別子がデジタルアセットコンテンツから導出されるのではなく、その代わりに経路名ロケータ、ファイルの作成者、ファイルの作成／変更日、ファイルのサイズ、または環境もしくはアプリケーションのその他のメタデータに依存する他のアセット識別システムよりも、優れている。こういった従来技術による識別子は、コンテンツでアドレスを特定できないため、容易にスプーフ（spoof）される恐れがある。これとは対照的に、本発明による検証のステップ４０４では、アセットのエラーを検出することができる。本発明では、好都合なことに、エラーが検出されてウイルスまたはスプーフィングが推測された場合には、推測されたアセットを別の場所から再構成しても良いし、または、より安全なファイル転送の方法を呼び出しても良い。
【００５５】
図５は、ステップ４０２の一実施形態を示した流れ図であり、インポータが、どのようにマルチキャスト送信をチェックし、断片ごとに受信されたアセットを再構成するかを示したものである。マルチキャスト送信は、ピアから、ネットワーク上で使用可能な全ピアにアドレスされた送信である。同様に、マルチキャストリクエストは、ネットワーク上で使用可能な全ピアにリクエストを送信することによりなされて良い。ピアは、定義されたマルチキャストグループ内に含まれるあらゆるデバイスを含み、マルチキャストグループは、データリングを通じてアクセス可能なあらゆるデバイスを含んで良い。この方法は、アセットのかたまり（チャンク）を正しい順序に位置付けることによりアセットを満たし、穴を埋めるのに必要なかたまり（チャンク）をリクエストし続けることから、スイスチーズメソッドと呼ばれている。この方法は、マルチプルソース、変数、無順序のデジタルアセットセグメントが、コンテンツでアドレスを特定できるような（content-addressable）アセット名（暗号ハッシュアセット識別子等）を使用して、リクエストに答えて転送されるのを可能とする。もちろん、ファイルを受信するために他の方法を使用しても良い。
【００５６】
ステップ５１０において、インポータはマルチキャスト伝送を受信する。次に、ステップ５２０において、インポータは、そのアセットリクエストリスト（ショッピングリストに類似する）をチェックし、受信されたデジタルアセットの断片またはセグメントが必要されているかどうかを見る。そのアセットセグメントが必要とされている場合は、ステップ５３０において、データをそのシーケンスナンバにもとづき正しい順序で格納し、アセットリクエストリストを更新して、その特定のアセットセグメントがこれ以上リクエストされないようにする。こうして工程が終了する。
【００５７】
ここで、上述したプロトコルに関して、デジタルアセット（バイナリ配列）が断片またはセグメントとして分けて受信され、アセットリクエストリストが、アセット（バイナリ配列）が完全に受信されるまではリクエストされている全アセットを含む点に、注意が必要である。他の実施形態では、アセットは、全部受信されても良いし、または、任意のファイル転送プロトコルにより指定された方法で受信されても良い。幾つかの実施形態では、リクエストされている個別のセグメントを含んだ、アセットセグメントリクエストリストが具現されていることも可能である。例えば、ソフトウェアアプリケーションのためのデータもしくはコードパッチが必要とされている場合、または、格納または問い合わせの結果によりデータベース特有のエントリが獲得された場合などに、アセットの個別のセグメントがリクエストされて良い。インポータは、ｅ−ＣＬＩＰの受信者へのアセットの転送を管理して、アセットがいつ完全となるかを決定し、正しいアセットが受信されたかを検証するのに、記述子ファイル内で指定された暗号ハッシュファイル識別子を使用できるようにする。検証は、暗号ハッシュアセット識別子を、受信されたアセット（バイナリ配列）を使用して計算されて新しく生成されたＭＤ５暗号ハッシュアセット識別子と比較することにより、達成される。
【００５８】
図６Ａは、ステップ４０２で説明したように、インポータにより生成されたアセットリクエストの構造を示したブロック図である。リクエスト６００は、アセット識別子６０２と、シーケンスナンバ６０４と、チャンクサイズ６０６とを含む。アセット識別子は、記述子ファイルから得られる。シーケンスナンバは、インポータにより、それがリクエストする予定のアセットセグメントのサイズにもとづいて生成される。チャンクサイズは、一定の実施形態ではインポータにより指定される。ここで、その他の実施形態では、チャンクサイズが、個別のファイルインポータによる変更が不可能なシステムにより指定されている点に、注意が必要である。
【００５９】
図６Ｂは、アセットリクエストに答えてリクエスト元にファイルデータを送る、データパケットの構造を示したブロック図である。データパケット６１０は、アセット識別子６１２と、シーケンスナンバ６１４と、アセットセグメントデータそのものを表わすデータ６１６とを含む。データの長さは、リクエスト６００で指定されたチャンクサイズ６０６の長さに対応する。このため、入力アセットセグメントを、それらのシーケンスナンバにもとづいてオーダすることができ、全セグメントが受信されたら、ファイル内のデータを、オーダされたセグメントから回復させることができる。特に注目に値するのは、異なるソースから無順序に受信された断片が、連結または埋め込まれて目的のデジタルアセット（バイナリ配列）を形成する点である。
【００６０】
１つの実施形態において、インポータは、それが記述子ファイル内に列挙されたアセットを探索する場所であるコンピュータシステム内（またはネットワーク上）で、場所の特殊な階層構造を有する。このため、インポータは、異なる場所でデジタルアセットを探索する複数のインポータからなる、連鎖システムを使用して具現されて良い。
【００６１】
図７は、このようなインポータの連鎖セットの一例を示したブロック図である。検証インポータ７０２は、先ず、デジタルアセットがアセットストレージ内のローカルディスク上に格納されているかを検証する。アセットストレージは、暗号ハッシュファイル識別子を使用したインスタント検索のために最適化された方法で、バイナリ形式でデータを格納するために留保されている、ローカルメモリの一領域である。アセットストレージ内でデジタルアセットが発見された場合は、検証インポータは、暗号ハッシュアセット識別子を計算によりチェックし、アセットストレージ内のアセットが、事実リクエストされているアセットかどうかを検証する。
【００６２】
検証インポータが、アセットストレージ内でデジタルアセットを発見できない場合は、発見インポータ７０４が解除され、もしできるならば、通常のローカルストレージ内で（もしファイルであれば）アセットの場所を探そうとする。アセットがファイルであり且つ通常のローカルストレージ内では発見できない場合、またはアセットが他の形態のデジタルアセットである場合は、図５で上述したようなマルチキャストインポータ７０６が解除され、ｅ−ＣＬＩＰの受信者が属するマルチキャストグループ内で信号をブロードキャストし、ｅ−ＣＬＩＰによって指定されたアセットを獲得しようと試みる。マルチキャストインポータでもアセットが得られない場合は、コピーインポータ７０８が使用され、それがアクセス可能なファイルサーバ上のあらゆるマウントされたボリューム上において、アセットがコンテンツアドレス可能なファイルとして格納されていないかどうか探索する。アセットが依然として発見できない場合は、今度はダウンロードインポータ７１０が使用され、ＦＴＰサーバまたはその他の外部ソースからの、コンテンツアドレス可能なファイルとして格納されているアセットを、ダウンロードする。上述したように、特定のｅ−ＣＬＩＰは、ＵＲＬ等のリソースロケータを含んでいる。リソースロケータは、インポータ７１０以前のいずれのインポータを用いてもアセットを獲得できない場合に、ｅ−ＣＬＩＰ内に含まれるファイルとして格納されているアセットを発見し得る、外部の特殊な場所を指定している。これに代わるものとして、在来のファイル転送リクエストを使用することができる。
【００６３】
このように、インポータは階層構造をなしており、アセットは、先ず最も便利な場所で検索された後、便利でない場所へと順に進んでいく。インポータのこの組立ラインは、１種類または多種類のインポータで構成されて良く、経済性、セキュリティ、または性能を最適化するために自動的および動的に変化することができる。暗号ハッシュアセット識別子は、アセットが回復したらそのコンテンツを検証できるような、コンテンツベースのファイル名として機能するため、チェックサムの類を使用してアセットのコンテンツをチェックすることを考慮せずとも、アセットを、それを発見し得る任意の場所から回復させることができる。特に、暗号ハッシュアセット識別子が、デジタルアセット（バイナリ配列）識別子、およびアセットコンテンツを検証する手段の両方として作用できる点が、注目に値する。
【００６４】
結論
１つの実施形態において、目的とするシステムで使用可能なあらゆるソースから再構築される、任意のディレクトリ構造を有したファイル集合を指定するための、システムおよび方法を説明した。ファイルは、記述子ファイル内のディレクトリ構造内に記述され、暗号ハッシュファイルリスト識別子（ｅ−ＣＬＩＰ）は、その記述子ファイルに対して生成される。ｅ−ＣＬＩＰはファイルの集合を表現したものであり、転送、格納等が可能である。
【００６５】
受信者がｅ−ＣＬＩＰを使用して記述子ファイルを獲得すると、記述子ファイルは、暗号ハッシュファイルリスト識別子を生成するのに使用されたのと同じアルゴリズムを使用して、ｅ−ＣＬＩＰ内で指定された正しい記述子ファイルであるかを検証される。そして、記述子ファイル内で指定された各ファイルが、インポータを使用して回復され、ファイルは、各ファイルのための暗号ハッシュファイル識別子を使用して検証される。このため、受信者は、情報送信者の場所から一つの通信回線を介して全情報を受信するよりも、より効率的な手段を使用して情報を獲得することができる。ｅ−ＣＬＩＰは各ファイルに対する暗号ハッシュファイル識別子を含んでおり、これらはファイルのコンテンツを検証するのに使用されることから、ｅ−ＣＬＩＰの受信者は、確実な方法で情報を収集することができる。
【００６６】
ここで説明するｅ−ＣＬＩＰは、ある実体から別の実体への転送のためにファイルを指定するのに加えて、コンピュータ内のあらゆるファイル集合の状態の厳密なレコードを、任意の時刻において形成するのに使用することもできる。これは、コンピュータ内のファイル集合に対するディレクトリ情報を含んだ記述子ファイルの暗号ハッシュファイル識別子である、ｅ−ＣＬＩＰを生成することにより達成される。全てのファイルは、必要な際に後ほど呼び出せるように、先ずどこか他の場所でバックアップされていることが好ましい。何らかの理由でコンピュータファイルが失われたら、ｅ−ＣＬＩＰを使用して記述子ファイル（安全な場所に格納されている）を呼び出す。そして、記述子ファイルを使用して、ローカルまたはネットワーク上の如何に関わらず、その中で参照されている全てのファイルを引き出すことができる。ファイルの呼び出しには、ここで説明したインポータが使用されることが好ましい。
【００６７】
このように、ファイルのためのｅ−ＣＬＩＰを生成して安全な場所に格納し、さらにファイルのコピーがどこか他の場所に存在しているよう気をつけるだけで、コンピュータ内のファイルの状態を、厳密に記録することができる。ファイルが必要になったら、先ずｅ−ＣＬＩＰを呼び出して記述子ファイルを発見し、その記述子ファイルを開き、さらに、そこに表現されている全ファイルの正しいバージョンをインポータを使用して呼び出すことにより、必要なファイルを回復させることができる。
【００６８】
この方法によれば、多くのコンピュータが同じファイルを含んでいる際に、ネットワーク上の多数のコンピュータを効率的にバックアップすることができる。ネットワーク上の各コンピュータが、そのディレクトリ構造はもちろんその全ファイルをも記述した記述子ファイルを生成する。記述子ファイルはセントラルバックアップコンピュータに送られ、各記述子ファイルで指定されたファイルが全て含まれていることが確かめられる。このスキームにより達成できるデータ圧縮の量は、バックアップされているコンピュータが、ローカルエリアネットワーク（ＬＡＮｓ）のパソコンのように共通のファイルを多く含んでいる場合に、非常に膨大なものとなる。各ファイルは、セントラルバックアップコンピュータにより一回獲得および格納されるだけで、各コンピュータ上で発見されたファイルを表現する各記述子ファイル内で、必要に応じて何回も指定することができる。
【００６９】
続くバックアップは、新しいまたは変更されたファイルのファイルハッシュを含んだ新しい記述子ファイルを生成し、その新しい識別子ファイルと、新しく形成されたまたは変更された全てのファイルとをセントラルコンピュータに格納することにより、達成することができる。このため、事前にアーカイブされた未変更のファイルを移動させることなしに、新しいまたは変更されたファイルを確実に識別し、セントラルバックアップコンピュータにコピーすることができる。新たにバックアップする際に、新しいまたは変更されたファイルを追加で格納するだけで良いため、各コンピュータのための周期的なバックアップを、夥しい量のファイル格納を必要とすることなしに達成することができる。
【００７０】
データベースの個別レコード、ウェブページ、および／または何らかの工程により識別されて、上述したのと性質的に同一なメカニズムにおいて使用可能となったその他の任意のデジタルアセットに対してアーカイビングを実施する、類似のメカニズムを具現することができる。
【００７１】
以上、理解をより明瞭なものとする目的で本発明の説明を行ってきたが、添付した特許請求の範囲の範囲内において、一定の変更および変形が可能であることは明白である。例えば、アセットおよび記述子ファイルのための一意なファイル識別子を計算するのに、広範囲に渡る様々なアルゴリズムを使用することができる。また、アセットリストハッシュは、バイナリ、別の適切なｂａｓｅ、ＡＳＣＩＩ、英数字等などの、あらゆる適切な形で表現されることができる。ｅ−ＣＬＩＰ、記述子ファイル、および個別のアセットは、同じ場所に格納されていても良いし、異なる場所に格納されていても良い。記述子ファイルはさまざまな形を採ることができる。各デジタルアセット（バイナリ配列）のためのアセットハッシュのみを含んでいても良いし、広範囲に渡るその他様々な情報を含んでいても良い。アセットは、ここで説明したインポータを使用して呼び出されても良いし、他の技術を使用して呼び出されても良い。アセットは、厳密にマッチした場合にのみ一致したと見なしても良いし、ファイル内のわずかな変化を許容してエラーの余地を設けても良い。したがって、これらの実施形態は、例示的なもので非限定的だと考えられ、本発明は、ここで提起した詳細に限定されず、添付した特許請求の範囲の範囲および同等物の範囲内で変更することが可能である。
【００７２】
コンピュータシステムの実施形態
図８および図９は、本発明の実施形態を具現するのに適したコンピュータシステム９００を示した図である。図８は、コンピュータシステムの可能な物理的形態の一例を示したものである。もちろん、コンピュータシステムは、集積回路やプリント回路板、手で持てる小型のデバイスから巨大なスーパーコンピュータに至るまで、広範囲に渡る多くの物理的形態を採ることが可能である。コンピュータシステム９００は、モニタ９０２と、ディスプレイ９０４と、ハウジング９０６と、ディスクドライブ９０８と、キーボード９１０と、マウス９１２とを備える。ディスク９１４は、コンピュータシステム９００との間でデータを転送するのに使用されるコンピュータ読み取り可能媒体である。
【００７３】
図９は、コンピュータシステム９００のブロック図の一例を示したものである。システムバス９２０には、広範囲に渡る様々なサブシステムが取り付けられている。プロセッサ（または複数のプロセッサ）９２２（中央処理装置またはＣＰＵｓとも呼ばれる）は、メモリ９２４を含むストレージデバイスに結合されている。メモリ９２４は、ランダムアクセスメモリ（ＲＡＭ）とリードオンリメモリ（ＲＯＭ）とを含む。当業者には周知のように、ＲＯＭは、ＣＰＵに一方向的にデータおよび命令を転送し、ＲＡＭは、データおよび命令を双方向に転送するのに使用されるのが典型的である。これら２タイプのメモリは、いずれも、以下に挙げる任意の適切なコンピュータ読み取り可能媒体を含んで良い。固定ディスク９２６もまた、ＣＰＵ９２２に双方向に双方向に結合されて、追加のデータ記憶容量を提供しており、以下に挙げる任意のコンピュータ読み取り可能媒体を含んで良い。固定ディスク９２６は、プログラム、データ等を格納するのに使用されて良く、プライマリストレージよりも低速な、セカンダリストレージ媒体（ハードディスク等の）であるのが典型的である。ここで、固定ディスク９２６に保持されている情報が、適切な場合において、スタンダードな方式によりメモリ９２４内に仮想メモリとして組み込まれる点が重要である。リムーバブルディスク９１４は、以下に挙げるコンピュータ読み取り可能媒体のいずれの形を採っても良い。
【００７４】
ＣＰＵ９２２もまた、ディスプレイ９０４、キーボード９１０、マウス９１２、スピーカ９３０等の、各種入出力デバイスに結合されている。入出力デバイスは一般に、ビデオディスプレイ、トラックボール、マウス、キーボード、マイクロフォン、タッチディスプレイ、トランスデューサカードリーダ、磁気もしくは紙のテープリーダ、タブレット、スタイラス、音声もしくは筆跡レコグナイザ、バイオメトリックリーダ、または他のコンピュータのいずれであっても良い。ＣＰＵ９２２は、ネットワークインターフェース９４０を使用して、別のコンピュータまたは通信網に選択的に結合されていても良い。このようなネットワークインターフェースにより、ＣＰＵは、上述した方法の各ステップを実施するに当たって、ネットワークとの間で情報を送受信することができると考えられる。さらにまた、本発明の方法の実施形態は、ＣＰＵ９２２のみを対象として実行されても良いし、処理を部分的に共有する遠隔ＣＰＵと関連させてインターネット等のネットワークを通じて実行されても良い。
【００７５】
また、本発明の実施形態はさらに、コンピュータで具現される様々な演算を実施する目的でコンピュータコードを搭載している、コンピュータ読み取り可能媒体を有したコンピュータストレージ製品に関する。この媒体およびコンピュータコードは、本発明の目的のために特別に設計および構築されたものでも良いし、コンピュータソフトウェア技術の当業者にとって周知および使用可能なタイプのものでも良い。コンピュータ読み取り可能媒体の例は、ハードディスク、フロッピィディスク、磁気テープ等の磁気媒体と、ＣＤ−ＲＯＭ、ホログラムデバイス等の光学媒体と、光フロッピィディスク等の光磁気媒体と、特定用途向け集積回路（ＡＳＩＣｓ）、プログラム可能型論理デバイス（ＰＬＤｓ）、ＲＯＭ−ＲＡＭデバイス等の、プログラムコードを格納および実行するために特別に構成されたハードウェアデバイスを含み、これらに限定されない。コンピュータコードの例は、コンパイラにより作成されたマシンコード、インタープリタを使用してコンピュータにより実行される高級コードを含んだファイル等を含む。
【図面の簡単な説明】
【００７６】
【図１】リスト内のアセットに対するファイルメタデータを含む、記述子ファイルの暗号ハッシュ記述子ファイル識別子を作成するための工程を示したフローチャートである。
【図２】記述子ファイルの構造を示した図である。
【図３】ｅ−ＣＬＩＰを使用して、記述子ファイルと、記述子ファイル内で指定されたアセットとを発見するための、工程を示したフローチャートである。
【図４】図３のステップ３１６で指定されるように、リクエストされたアセットを受信してバイナリ配列識別子を検証するのに使用される、インポータ上で走る工程を示したフローチャートである。
【図５】ステップ４０２の一実施形態を示したフローチャートであり、インポータが、どのようにマルチキャスト送信をチェックし、断片ごとに受信されたアセットを再構成するかを示したものである。
【図６Ａ】ステップ４０２で説明したように、インポータにより生成されたアセットリクエストの構造を示したブロック図である。
【図６Ｂ】アセットリクエストに答えてリクエスト元にファイルデータを送る、データパケットの構造を示したブロック図である。
【図７】インポータの連鎖セットの一例を示したブロック図である。
【図８】本発明の実施形態を具現するのに適したコンピュータシステム９００を示した図である。
【図９】本発明の実施形態を具現するのに適したコンピュータシステム９００を示した図である。
【図１】
2006338680.tif 000003
【図２】
2006338680.tif 000004
【図３】
2006338680.tif 000005
【図４】
2006338680.tif 000006
【図５】
2006338680.tif 000007
【図６Ａ】
2006338680.tif 000008
【図６Ｂ】
2006338680.tif 000009
【図７】
2006338680.tif 000010
【図８】
2006338680.tif 000011
【図９】
2006338680.tif 000012