JP2008257719A

JP2008257719A - 局所超流通及び鍵交換によるセキュアな事前キャッシュ

Info

Publication number: JP2008257719A
Application number: JP2008086836A
Authority: JP
Inventors: Bradley J Rhodes; ジェイロードスブラドリー; R Sabikki Stephen; アールサビツキーステフェン; Piasoru Kurt; ピアソルカート
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2007-03-30
Filing date: 2008-03-28
Publication date: 2008-10-23
Anticipated expiration: 2028-03-28
Also published as: EP1975835A1; US20090327729A1; JP5298599B2; US8046328B2; DE602008001119D1; EP1975835B1

Abstract

【課題】分散型ピアツーピア文書保管システムは、集中型ストレージ・システムに通常、関連付けられる、バージョン管理、セキュリティ、アクセス・コントロール、記憶された文書間のリンク付け、及び文書への遠隔アクセスを提供する。
【解決手段】個人及びピアツーピアのストレージ・システムに関連付けられる、単純性、個人化、及びネットワーク障害に対するロバスト性を提供する。
【選択図】図２

Description

本発明は、一般に文書保管及び文書流通に関し、特に、分散化されたセキュアなピアツーピア文書保管システムに関する。

通常のビジネス・ワークグループのITインフラストラクチャでは、基本機能を２つ備えなければならない。第１に、チームのメンバ（構成員）が文書にアクセスし、他のメンバと共有することができることを確実にする。第２に、他人が誰も前述の文書にアクセスすることが可能でないことを確実にする。第１の機能は通常、専用ファイル・サーバ、集中化されたバックアップ、専用ネットワーク、静的IPアドレス及びドメイン名サービスを必要とし、第２の機能は、ファイヤウォール、アカウント及びパスワードの管理、並びに、自分のサーバの物理セキュリティを必要とする。チームへの所属が明確に定義されており、比較的静的であっても、前述のインフラストラクチャは、小企業が維持するのが難しく、費用が高くつく。いくつかの別々の組織からであり、特定の分野で協力し、他の分野で競合し得る構成員でチームが構成されている場合は更に難しくなる。

現行の文書保管（文書アーカイブ）システムは、２つのモデルのうちの１つに従う傾向にある。

グループウェア・モデルは、「グループ・メモリ」を維持したい明確に定義された単一のワークグループ、企業や他の明確に定義された協力者群にとって特に有用な機能を提供する。前述の機能には、文書への遠隔アクセス、グループの非構成員に対して制限されたアクセス、セキュリティ、バージョン管理、並びに複合文書のリンク及び作成を可能にするための、文書に固有のハンドルがある。グループウェア・システムは、集中化されたアーキテクチャ（ファイル・サーバや、ウェブベースのコンテンツ・マネージャなど）によって最も頻繁に提供される。

逆に、個人アーカイブ・モデルは、今日のビジネスの世界で一層普及してきているモバイル組織、分散組織、及び関連性の弱い組織をサポートするための機能を有する。前述の環境における知識労働者は、多くのプロジェクトに一度に取り組む傾向にあり、同時に、多くの重なり合っており（、場合によっては競合している）集団に属している。前述の知識労働者は更に、一層モバイルになってきており、ネットワーク・アクセスが遅いか、区分されているか、又はない環境にいることに気付くことが多い。前述の環境における知識労働者は、共有可能な個人アーカイブ（すなわち、一個人が維持することが簡単であり、オンラインでもオフラインでも動作し、他の情報を秘密状態に保つ一方で、臨時のワーキング・グループが特定の情報を共有することを可能にする、直観的に使える限定発行モデルをサポートするもの）を必要としている。前述の機能は全て、今日、PDA、局所に記憶された電子メール・アーカイブ、及び伝統的な紙ベースの文書によって提供されるように、各ユーザが自分自身のアーカイブを維持し、特定のファイルを他者と共有する分散化された解決策を示唆している。

ユーザの観点からは、集中化された解決策と分散化された解決策との主たる違いは、制御がもともと、文書の発行者にあるか、又は閲覧者にあるかにある。ウェブ上では、サイトの発行者（、又は前述の発行者が指定したサイト管理者）は、文書へのアクセスを有する者が誰であるか、文書を修正することが可能な者が誰であるか、及び過去のバージョンが利用可能にされるか否かに対する最終的なコントロール及び責任を有する。発行者は、サイトを完全にダウンさせ、よって、誰へのアクセスも拒否するようにすることもできる。電子メールベースの解決策、及び紙ベースの解決策の場合、コントロールを有するのは閲覧者である。紙文書を受け取る者は誰も、単にコピーをとることによって他者と共有する機能を有し、誰かが紙文書を一旦受け取ると、元の作成者が「取り戻す」のは非常に難しい。同様に、電子メールは多くの場合、（時には、転送を行う個人によって行われる修正及び注釈を伴って）他者に転送される。文書へのアクセスを付与又は拒否する決定は、既にアクセスを有する人々中心に分散化され、制約は社会的（及び時には、法的）規則によって課される。

「より好適である」のが発行者によるコントロールであるか、又は閲覧者によるコントロールであるかは、組織と、情報が生成され、使用される環境と、場合によっては、判断を行う者が誰であるかとによって変わってくる。パスワード及びファイヤウォールによって保護されたウェブ・サーバなどの集中化された解決策は、明確に定義された文書組に対するアクセスを必要とする明確に定義された個人グループが存在している環境、及び情報の作成者と消費者との間の明確な区別が存在している環境においてうまく機能する。グループの境界がよりファジーなより協力的な環境では、分散化された解決策は、しばしば、より好適である。今日の大半の労働者は、常時の協力、及び臨時の協力にかかわって、前述の２つの環境間のどこかに収まり、よって、集中化されたシステム及び分散化されたシステムの利点を必要とする。

本発明による個人文書アーカイブ・システムは、限定された閲覧者に対して複合文書のセキュアな発行を提供する。本発明は、本願の発明者によって実施されており、全体をMakyohとして表す。

機能には、バージョン管理、セキュアな記憶、発行及びバージョンの永久ハンドル（URI）、及び複合文書を構築し、文書をディレクトリ木に編成する機能がある。上記システムは、ロバストな冗長記憶、直観的に使える、「紙のような」発行及びアクセス制御モデル、及び、ネットワーク・アクセスが遅いか、区分されているか、又はない環境において動作する機能を含む構成も提供する。

本発明は、「フィード」（ウェブ上で利用される「ニュース・フィード」から借りているが、それ以外は混同すべきでない語である）の考え方を導入している。本発明による「フィード」は、変更可能な文書を表すことが可能である。新たな「フィード・エントリ」はそれぞれ、文書の新たなバージョンを表す。「フィード」は、各フィード・エントリがそれ自身のコンテンツである発行チャネルを表すことも可能である（例えば、ブログ・エントリや、掲示板上のメッセージ）。フィードにおける個々のエントリは、それ自身に固有のURIによってアクセスすることが可能である。本発明は、フィードにおける最新エントリ（バージョン管理された文書を表すうえで有用である）にアクセスし、既知のエントリ全てのマージされたビュー（ブログ、及び他の一括の複数文書を表すうえで有用である）にアクセスするための特別なURIを提供する。

エントリを、複数のマシン（Makyohサーバ）からのフィードに（必要な場合、複数の作成者によって）ポスティングすることが可能である。文書のオーサリング、流通及び読み出しは全て、完全に分散化されている。発行する機能は、フィードの発行鍵を得ることによって得られる。

特定の文書又はフィードにアクセスするために、ユーザは、その文書の鍵又はフィードの鍵を有していなければならない。ファイル又はファイル組によって表される各文書は、「文書鍵」と呼ばれる固有の鍵と関連付けられる。文書鍵は、関連付けられた文書の単一の固定バージョンを構成するファイル又はファイル組を識別し、復号する機能を付与する。各フィード（及びそのエントリ）には、「加入鍵」及び「発行鍵」と呼ばれる２つの固有の鍵に関連付けられる。加入鍵は、関連付けられたフィードにおけるエントリを構成するファイル又はファイル組を識別し、復号する機能を付与するが、新たなエントリをフィードに追加する機能を付与しない。発行鍵は、関連付けられたフィードにおけるエントリを構成するファイル又はファイル組を識別し、復号する機能を付与し、「発行」と呼ばれる処理によって新たなエントリをフィードに追加する機能も付与する。ユーザは、適切な鍵を与えることにより、文書又はフィードへのアクセスを他の誰かに付与することが可能である。受信側は次いで、鍵を自分の個人のMakyohサーバに「インポート」する。本発明の実施例では、鍵は、ユーザのパスフレーズを用いて暗号化され、自分の個人のMakyohサーバの局所ディスク上の私設ディレクトリに記憶される。

本発明による個人文書アーカイブ・システムは、従来の保管システムにおいて必要であったインフラストラクチャを何れも必要とすることなく、ロバストでセキュアな文書記憶及び共有を提供する。上記システムは、専用サーバ、スケジュールされたバックアップなしで、又は高信頼度ネットワークさえなしでロバストであり、アカウント・パスワード、ファイヤウォール、又はセキュアなサーバ室に対する必要性なしでセキュアである。エンド・ユーザ（及びそのアプリケーション）に対して、アーカイブは局所ディスクにみえる。ユーザが自分のパスフレーズを入力してシステムをロック解除すると、自分のアーカイブ全てがこのようにして利用可能である。本発明の特定の実施例では、各ファイル及び各ディレクトリは、BLOB（バイナリー・ラージ・オブジェクト）と呼ばれるそれ自身の暗号化されたファイル内のディスク上に実際に記憶されている。各BLOBは、それ自身の固有の１２８ビットの対称復号鍵を有する。ハード・ドライブを盗んでも、適切な鍵なしでアーカイブのコンテンツにアクセスすることは誰も可能でない。BLOB復号鍵は、暗号化ディレクトリBLOBに一覧化することが可能であるが、全ての場合において可能である訳ではない。例えば、単一ファイル文書を表すBLOBの鍵は、文書鍵を表す印刷された２Dバーコードとしてしか存在することができないことがあり得る。

前述の通り、従来の集中化システム及び分散化システムは通常、発行者と閲覧者との間で、文書に対するコントロールがどのようにして分けられるかが異なる。本発明によれば、資源（例えば、ファイル、ディレクトリや、フィード・エントリ）にどのようにしてアクセスし、修正することが可能かに対するコントロールは、通常の中央サーバ・システム（ウェブなど）又は分散化システム（電子メールなど）の場合よりも、発行者と消費者との間でより一様にバランスされている。特に、本発明は、閲覧者、発行者及び再発行者（例えば、発行者でもある閲覧者。例えば、読んだ内容を修正し、次いで、修正した内容を発行する閲覧者）にとっての以下のニーズが満たされることを確実にする。

A. 閲覧者のニーズ
永続性：閲覧者自身のミラーリングされた資源は、閲覧者の許可なしで削除又は修正することが可能でない。

共有可能性：資源を他者と、前述の資源が別の誰かによって元々制作されている場合でも共有する機能
更新：資源の最新発行バージョンを受け取る機能（本発明では、マルチバージョンの資源はフィードによって表す。各バージョンは、フィード内のエントリである。）
B. 発行者のニーズ
アクセス制御：資源への初期アクセスを制限する機能（しかし、アクセスが付与される者は誰でも、資源を他者になお転送することが可能である。）
バージョン管理：資源の新たなバ―ジョンを発行する機能
認証：発行の出所を証明する機能
匿名使用：物理的な識別情報に結びつけられていない名称で内容を制作する機能
完全性：資源のミラーが完全であるか否かを閲覧者が分かり得る（すなわち、完全な文書又はフィード・エントリを読むために必要なファイル全てを有している状態になった時点が分かり得る）ことを確実にする機能
預託：暗号化された文書が第三者によってミラーリングされるが、後の時点で鍵が生成されるまで復号することが可能でないように「預託して」文書を発行する機能
C. 再発行者のニーズ
リンク：それ自体が別の誰かによって制作された資源にリンクするか、又はその資源を使用する資源を発行する機能。リンクされた、又は含められた前述の資源が、元々発行されたものとは変わらないという証明。

分岐：別の資源（場合によっては、別の者によって制作された資源）の内容に基づいた新たな資源を作成する機能。

ウェブベースの発行システムと比較して、発行者の必要性を満たそうとする一方、本発明によるシステムは、閲覧者及び再発行者により多くの能力を付与する傾向にある。これは２つの理由からである。まず、前述の通り、情報を再流通し、再発行する機能を最終閲覧者に付与することは、中央制御よりもずっと効率的である。「共有」及び「再発行」のような語は、音楽及び映画の業界における幹部にとって悪夢であるが、この種の通信は、社内通信の場合（特に紙文書を取り扱う場合）標準である。第２に、大半の技術トレンドは、より少ない閲覧者コントロールよりもより多くの閲覧者コントロールの方向に向いている。局所記憶容量は増加し続け、局所CPUは加速化し続けている一方、モバイル・ネットワークの速度、及び給電するために必要なバッテリの改良はずっとゆっくりである。消えてなくなり得るウェブ・ページは、グーグルによってキャッシングされるのみならず、インターネット・アーカイブ、メモリ・ホールのような非営利組織によってキャッシングされ、独立系ブロッガーによってもキャッシングされる。一度ウェブ上に排他的に発行されたコンテンツ・サイトは、閲覧者がコンテンツをダウンロードし、自分自身の局所キャッシュから読むか、聴くことを容易にするポッドキャスティング及びRSSフィードが加速的に提供されている。一方、音楽、映画、及び書籍産業における発行者に能力を復活させるよう企図されたディジタル権利管理（DRM）システムは、リリース直後にそのスキームが破られることが分かっており、セキュリティの専門家は、DRMの考え方自体に基本的に欠陥があると言う。

本発明は、本願の出願者によって実施されており、以下、全体をMakyohとして表す。Makyoh個人サーバのプロトタイプ・バージョンが、ジャバベースのサーバ上に実現されている。暗号化、記憶、バージョン管理、ディジタル署名機能、ピアツーピア流通、及びサーバ発見は全て実現されている。

Ｉ．概要
Makyohは、例として前述したような従来のインフラストラクチャを何れも必要とすることなく、ロバストかつセキュアな文書記憶及び文書共有を提供する。上記システムは、専用サーバ、スケジュールされたバックアップを必要とすることなく、又は高信頼度ネットワークさえ必要とすることなくロバストであり、アカウント・パスワード、ファイヤウォール、又はセキュアなサーバ室に対する必要なしでセキュアである。本発明の実施例によれば、エンド・ユーザ（及びそのアプリケーション）にとって、Makyohアーカイブは、局所ディスク（実際には、局所で実行しているWebDAVサーバ、時には、ウェブ・フォルダと呼ばれる）であるようにみえる。ユーザが自分のパスフレーズを入力してMakyohシステムをロック解除すると、自分のアーカイブ全てがこのようにして（すなわち、局所ディスクとして）利用可能である。全てのウェブDAVサーバと同様に、自分のアーカイブは、標準ウェブ・ブラウザを用いてウェブ・ページとしてみることも可能である。特定の実施例では、各ファイル及びディレクトリが、ハード・ドライブなどの永久記憶媒体上、又は取り外し可能な媒体（例えば、「サムネイル・ドライブ」として一般に表される装置）のBLOB（バイナリー・ラージ・オブジェクト）と呼ばれるそれ自身の暗号化ファイルに記憶される。各BLOBは、それ自身の固有の１２８ビットの対称復号鍵を有する。よって、記憶媒体を盗んでも、適切な鍵なしでアーカイブのコンテンツにアクセスすることは誰も可能でない。BLOB復号鍵は、暗号化ディレクトリBLOBに一覧化することが可能であるが、全ての場合において可能である訳でない。例えば、単一ファイル文書を表すBLOBの鍵は、文書鍵を表す印刷された２Dバーコードとしてしか存在することができないことがあり得る。

II. Makyoh
本発明による個人文書アーカイブ・システム１００（本明細書及び特許請求の範囲にMakyohとしても表している）を図１に示す。システム１００は、文書を受け取り、記憶し、文書を処理する複数の個人サーバ（本明細書及び特許請求の範囲では、個人サーバ、Makyoh個人サーバ、Makyohサーバ等として表す）を含む。図は例として、４つのポータブル個人サーバ１０２乃至１０８（ラップトップ・コンピュータ、ハンドヘルド・データ装置、携帯電話機等など）を示す。個人サーバ１０２乃至１０８は、伝統的にポータブルでない計算機装置（デスクトップPC等など）でもあり得る。個人サーバ１０２乃至１０８間の通信は、適切な無線技術（例えば、ブルートゥース、IEEE802.11等）、又は何れかの適切な有線技術（例えば、イーサネット（登録商標）、シリアル・ポート接続等）によるものであり得る。

個人サーバ１０２乃至１０８は、資源のセキュアな記憶、及び、限定された閲覧者に向けて資源を発行するためのセキュアなピアツーピア・モデルを併せて提供する。各個人サーバ１０２乃至１０８は、１つ又は複数の資源を備えたMakyohアーカイブを記憶する。ここで、資源は、ファイル、ディレクトリ、フィード、又はフィード・エントリである。Makyohアーカイブそれぞれは、局所で作成されている資源、及び、他のMakyohサーバ上で作成され、その後、発行されている資源の暗号化されている、局所でキャッシュされたミラーとして考えることが可能である。Makyohアーカイブは、暗号化されたBLOB（ファイル、ディレクトリ及びフィード鍵を表す）、復号鍵組、及びフィード・エントリ・ファイル（それぞれが、特定のフィードと関連付けられている）の組み合わせを用いて実現される。通常、各ユ―ザは、自分自身の局所に記憶されたMakyohアーカイブを自分の個人サーバ上に記憶することになる。Makyohアーカイブの更なる詳細は以下に表す。

Makyoh個人サーバ１０２は、３つの主要機能を行う。まず、サーバは、暗号化され、バージョン管理された個人アーカイブを維持する。第２に、サーバは、他のMakyoh個人サーバ104乃至108によって発行されている資源の局所ミラーとしてふるまう。最後に、サーバは、接触する他のMakyoh個人サーバに、前述のミラーイングされた資源を流通させる。このようにして、各Makyoh個人サーバ１０２乃至１０８は、個人アーカイブとして機能し、ピアツーピア・ネットワークにおけるノード及びルータとして機能し、近傍のアーカイブのミラーとして機能する。個人サーバ１０２乃至１０８は全て、ルーティング活動及びミラーイング活動に参加することができるが、資源は全て暗号化されているので、特定の資源に対する復号鍵を知っている者のみがそのコンテンツを読み出すことができる。

BLOBは、常に暗号化されているので、機密情報を明らかにすることを気にすることなく自由に流通させることが可能である。特に、ユーザが資源にアクセスする都度、自分の局所Makyohサーバ１０２は、近傍のMakyohサーバ104-108全てを（ボンジュールと呼ばれるオープン・プロトコルを用いて）自動的に見つけ、その文書に関連付けられたBLOB全てを、前述の領域における他のMakyohサーバ全てに流通させる。本明細書及び特許請求の範囲では「局所超流通」として表すこの処理は２つのことを達成する。まず、前述の処理は、前述の領域における他のマシン（Makyohサーバ）全ての上に、ユーザの文書１２２の暗号化されたバックアップを作成する。第２に、前述の処理は、前述の領域における他の人々とユーザが共有したいことがあり得る文書を事前キャッシュする。

図１Aは、本発明のより一般化された実施例を示す。例証された実施例では、装置102’は、本明細書及び特許請求の範囲記載のMakyohサーバの機能を提供するようにも構成された何れかの文書処理装置であり得る。例えば、装置102’は、コピー機、ファクシミリ機、プリンタ等（それらの組み合わせを含む）であり得る。例えば、文書処理装置102’が複写機の場合、文書ソース１０１（例えば、人間のユーザ）は、コピーするために文書をコピー機上におき、例えば「開始」ボタンを押すことにより、コピー処理を起動させることになる。コピー処理の実行に加えて、コピー機は、以下に更に詳細に説明するように、本発明による文書の暗号化、記憶及び流通を行うよう構成することが可能である。文書処理装置102’が印刷装置である場合、文書ソース１０１は、プリンタに接続された計算機装置（例えば、局所でプリンタに接続されたラップトップや、ネットワーク接続を介した、プリンタへのアクセス）であり得る。印刷用の文書がプリンタによって受け取られると、文書は、印刷されることに加えて、本発明によって暗号化され、記憶され、流通させることが可能である。

図２は、本発明の実施例による、Makyohサーバ102を備えた特定のハードウェア要素及びソフトウェア要素の概要レベルのブロック図を示す。Makyohサーバ102は、汎用CPU、カスタムASIC（特殊用途向集積回路）や、何れかの他の適切なデータ処理ロジックなどの適切なデータ処理構成部分２０２を備える。記憶装置の汎用的な表現は、記憶構成部分２０４として示しており、一時的なデータ記憶のため（例えば、DRAM等）、及び永久データ記憶のため（例えば、ハード・ドライブ、ROM、フラッシュ・メモリ、取り外し可能なフラッシュ・メモリ等）の、サーバ１０２の記憶機能を表す。記憶構成部分２０４は、以下に更に詳細に説明するように、本発明の個人アーカイブ・システムにおいてサーバ１０２の動作に関する処理を行う、データ処理構成部分２０２によって実行するプログラム・コードを、他のデータの中でも記憶する。記憶構成部分２０４は、以下に詳説するように、Makyohアーカイブも記憶する。

通信インタフェース２０６は、ユーザや他のMakyohサーバ１０４、１０６と通信するためのハードウェア要素及びソフトウェア要素を表す。例えば、通信インタフェース２０６は、表示装置及び入力装置（例えば、キーボード）が接続された１つ又は複数のコネクタ、並びに、表示装置及び入力装置と相互作用するための関連ドライバを含み得る。通信インタフェース２０６は、他のMakyohサーバ１０４、１０６との有線通信のためのコネクタ（例えば、イーサネット（登録商標））を含み得る。通信インタフェース２０６は、他のMakyohサーバ１０４、１０６との無線通信のための無線送受信器（例えば、ブルートゥース又は802.11準拠装置）を含み得る。

オペレーティング・システム（OS）２２２を実行するデータ処理構成部分２０２を示す。例えば、本発明の実施例では、OS２２２は、マイクロソフト（登録商標）ウィンドウズ（登録商標）オペレーティング・システム、アップル（登録商標）のOS Xオペレーティング・システム、又はリナックス・オペレーティングであり得る。信頼できるユーザのAPI２３２と一方が呼ばれ、遠隔ユーザAPI２４２と他方が呼ばれる２つのアプリケーション・プログラミング・インタフェース（API）を実行するデータ処理構成部分２０２も示している。OSの機能とともに動作する前述のAPIは、本発明による機能をアプリケーション・レベル・プログラム２５２に提供する。API２３２、２４２は以下に更に詳細に説明する。

API２３２、２４２は、高レベル・アプリケーション２５２のサービスを提供する。本発明の特定の実施例では、前述のアプリケーション２５２の１つは、ジャバベースのサーバである。サーバ・アプリケーションは、OS２２２（例えば、マイクロソフト（登録商標）ウィンドウズ・オペレーティング・システム、アップル（登録商標）OS Xオペレーティング・システム、リナックス・オペレーティング・システム等）下でディスクとして資源、又は完全なアーカイブを搭載するために必要なWebDAV（ウェブベースの分散オーサリング及びバージョン管理）機能全てを含む。アーカイブは次いで、オペレーティング・システムの標準ファイルブラウジング・ユーザ・インタフェース、又は何れかの他の適切なファイルブラウジング・アプリケーションを用いてブラウジングし、修正することが可能である。

III. 鍵及びハッシュURI
Makyohアーカイブ（後述する）における全資源は、「ハッシュURI」として明細書及び特許請求の範囲に表す固有のURI(ユニバーサル・リソース識別子)に関連付けることが可能である。この特別なタイプのURIは、以下の特定の形式を有する、ウェブ・ブラウザに通常用いる汎用的なURI形式に従う。

hash:sha1=<id>;aes128-key=<key>?content-type=<MIME-type>&name=<name>
ここで、
<id>は、小文字の40文字の１６進形式の文字列として符号化されたファイル又はディレクトリを表す暗号化されたBLOBのSHA-1（セキュア・ハッシュ・アルゴリズム）のハッシュである。パラメータ識別子（現在sha1）は、コンテンツの固有のIDの生成に用いるハッシュ・アルゴリズムを示し、形式に対する将来の拡張は、更なるハッシュ・アルゴリズムを含み得る。2つの別個のBLOBが偶然に同じIDを有することが理論的に可能である一方、前述の衝突をちょうど１つ見つける可能性が100万の1の可能性もある状態になる前に266のBLOBを生成することを必要とするので、IDは大局的に固有であるとみなし得る。

<key>は、小文字の３２文字の１６進形式の文字列として符号化された関連付けられたBLOBの復号に用いるAES-128鍵である。Makyohでは、この鍵が常に、以下に説明するようにヘッダを前に付加した、平文ファイルのMD5（メッセージ・ダイジェスト・アルゴリズム５）になる。keyフィールドは任意であり、読み出すのに必要な復号鍵を特定することなく、暗号化されたBOLBを識別するハッシュURIを構成するよう省略することができる。パラメータ識別子（現在、aes128-key）は、使用される暗号化アルゴリズムを示し、前述の形式に対する将来の拡張は更なるアルゴリズムを含み得る。

<MIME-type>は、ファイルのMIME（多目的インターネット・メール拡張）タイプ（非常によく知られており、理解されるデータ・タイプ）である。Makyoh特有のファイル（例えば、ディレクトリ及びフィード鍵ファイル）は、MIMEタイプのテキスト／平文を用いる。

<name>は、ファイル又はディレクトリの名称である。これは通常、拡張子（例えば、「my-document.pdf」）を含む。

ハッシュURIは、識別子及び鍵として機能し、よって、近傍サーバ104乃至108からの暗号化BLOBを取り出し、一度取り出されたBLOBを復号するために用いることが可能である。取り出されると、BLOBコンテンツを復号し、ユーザに提示することを要する方法を残りのフィールドがサーバに知らせる。

Makyohにおけるアクセス制御は主として、ハッシュURIを用いて行う。誰かがハッシュURI(多くの場合、単に鍵と呼ばれる)を自分のMakyohアーカイブにインポートすると、識別するファイルのコンテンツへのアクセスを有する。Makyohは、特別の種類のファイル（すなわち、ディレクトリBLOB及びフィード鍵BLOB）を用いて、単一のハッシュURIを前提として、大きく、かつ場合によっては拡張可能なファイル組へのアクセスを付与する。一般に、ユーザは、３つの種類のハッシュ（文書鍵（単一の変更可能でないファイル、又はディレクトリ木へのアクセスを付与する）、加入鍵（特定のフィードのフィード・エントリを読み出す機能を与える）、及び発行鍵（特定のフィードのフィード・エントリを読み出し、そのフィードの新たなエントリを発行する機能を与える））と相互作用する。

ハッシュＵＲＩは、電子メール及びウェブ・ページにＵＲＬがどのようにして埋め込まれているかと同様なハイパリンクとして直接用いることが可能である。必要になるのは、新たなＵＲＩ形式にアクセスするようブラウザ・プラグインを書き込み、特定のデータ記憶装置から必要なＢＬＯＢを取り出すことが必要になる。しかし、この種の使用は、アクセスの点であまり柔軟でないので、Makyohにおいて妨げられる。ユーザは、別の文書のハッシュURIを含む文書にアクセスを有している場合、両方へのアクセスを自動的に有する。後の時点で、制作者が、第１の文書にのみアクセスを可能にしたい場合、ハッシュURIを第１の文書に渡す前に、そのコンテンツを編集し、第２のハッシュURIの表現を全て除外する必要がある
ハッシュURIを直接使用する代わりに、文書又はフィードのIDに基づいて、信頼できるユーザAPIにおいて提示されたアクティブ・ディレクトリ構造を使用することが好ましい。ハッシュURIと同様に、特定の文書又はフィード・エントリへのパスは、Makyohユーザ全てについて同じであるが、ハッシュURIと違って、アーカイブ・パスは、文書の復号鍵を明らかにしない。鍵を既に有しており（、よって、文書又はフィードへのアクセスが付与されている）ユーザは、特定のパスにおけるファイルにアクセスすることが可能になるが、他のユーザが可能にならない。

IV. API
Makyohは、個人アーカイブを提供し、通常、各ユーザは自分自身の個々の個人サーバ１０２を実行する。個人サーバ１０２は、ユーザの全体アーカイブ全ての暗号化された局所のコピーを維持し、更に、近傍サーバ１０４乃至１０８上に、暗号化された文書をコピーする。このことにより、記憶サーバの分散ネットワークにおける特定モードに各ファイルを割り当てる、フリーネットやオーシャンストアのような従来の分散化された文書記憶装置と、Makyohが区別される。Makyohは２つの別個のAPIを提示する。

第１のAPIは、図２に示す「信頼できるユーザのAPI」である。図が示すように、Makyohアーカイブは、信頼できるユーザAPIの２３２を介して仮想ファイル・システム（アーカイブ・ビューとしても表す）としてみえる。信頼できるユーザに提示されるファイル・システム構造は必ずしも、記憶装置上に記憶されたような、Makyohアーカイブの構成ファイルの下にある編成のファイル・システム構造でない。仮想ビューは、Makyohアーカイブを構成する下にある物理ファイルの抽象化を提示する。仮想ビューは、何れかの適切なファイル構造ビューであり得る。当然、共通のパラダイムは、階層ファイル構造である。説明の目的で、仮想階層ファイル・システムを前提とする。

図２に示すように、信頼できるユーザのAPI２３２は、ディレクトリ階層（仮想ファイル・システム、アーカイブ・ビュー）において編成されたフォルダ及び文書のファイル・システムとしてMakyohアーカイブを提示する。このアーカイブ・ビューの更なる詳細を以下に説明する。Makyohアーカイブは、HTTPを用いて局所Makyohサーバ１０２（局所ホストとしても表す）と通信する標準ウェブ・ブラウザを用いて、又は、WebDAVプロトコルを用いて局所ファイル・システム（場合によってはウェブ・フォルダと呼ぶ）の一部としてアクセスすることが可能である。信頼できるユーザのAPI２３２は、局所で生成された接続（すなわち、局所ホスト１０２への接続）から、かつ、ユーザが自分のパスフレーズを用いてMakyohサーバによって認証してからのみ、利用可能であるに過ぎない。

第２のAPIは、やはり図２に示す「遠隔ユーザAPI」である。遠隔ユーザAPI２４２は、実際に記憶構成部分２０４に記憶されているのでMakyohアーカイブ（例えば、フィード・エントリ・ファイル、暗号化されたBLOB等）を備えた未処理ファイルを他のMakyohサーバ１０４、１０６（いわゆる、信頼できないユーザ）に提示する。前述の未処理ファイルは、HTTPプロトコル及びWebDAVプロトコルによってもアクセス可能であり、他のMakyohサーバが用いて、必要なBLOB及びフィード・エントリを見つけ、取り出し、BLOB及びフィード・エントリ・ファイルを更に他のサーバにプッシュする。

A. 信頼できるユーザのビュー
認証されたユーザの観点からは、Makyohアーカイブの仮想ファイル・システム・ビューは2種類の資源（文書及びフィード）を含む。「文書」は、変更可能でないファイル又はディレクトリ木である一方、「フィード」は、フィードに発行される新たな文書（エントリと呼ぶ）に加入することができる流通チャネルを規定する。文書及びフィードそれぞれは、資源へのアクセスを可能にする識別子及び復号鍵としての役目を担う固有のURI（汎用資源識別子）に関連付けられる。文書は変更可能でない。文書を指し示すURIは、ちょうど同じコンテンツを常に指し示すことが保証される。新たなエントリを特定のフィードに発行することが可能である点で、フィードは変更可能である。各フィード・エントリは、それ自身のURIによって識別可能であり、エントリのコンテンツを表す変更可能でない文書をそれ自身が指し示す。フィードは、各フィード・エントリ（例えば、ブログのエントリや、掲示板上のメッセージ）がそれ自身のコンテンツである発行チャネルとして用いることが可能であるか、又は、新たなフィード・エントリそれぞれが、新たな文書バージョンを表す変更可能なバージョン管理された文書を表し得る。

図３は、信頼できるユーザに提示されるMakyohアーカイブの仮想ファイル・システム・ビューの例を示す。図３に示すように、認証された局所ユーザに提示されるサ―バ１０２の仮想ファイル・システムのルート・ディレクトリ・ツリー３０２は３つのディレクトリ（文書(docs)、フィード及び鍵リング）を有する。ルート・ディレクトリ・ツリー３０２は、Makyohアーカイブの仮想ファイル・システム・ビューにおける最高レベルを表し、下にある物理ファイル・システムの「ルート」と必ずしも一致する訳でない。

文書ディレクトリ３１２は、変更可能でない（すなわち、変更されない）文書を含む。フィード・ディレクトリ３１４は、局所サーバ１０２により、かつ、遠隔サーバ１０４‐１０８により発行されるエントリを受け取ることによって変更可能であるフィード・エントリを含む。ユーザは、文書ディレクトリ312における文書を復号し、見ることが可能であり、適切な文書、加入又は発行鍵をインポートしているフィード・ディレクトリ３１４にエントリをフィードすることが可能である。鍵リング・ディレクトリ３１６は、ユーザがこれまでにインポートした鍵全てを含む。本発明の実施例では、前述の鍵は、対称鍵としてユーザのパスフレーズを用いて暗号化されており、局所サーバ１０２上の私設ディレクトリに記憶されている。

文書は、文書ディレクトリ３１２下でそれぞれのサブディレクトリ３２２に記憶される。各サブディレクトリ３２２は、小文字の４０文字の１６進形式の文字列として記述された、文書のファイル又はルート・ディレクトリを表すBLOBの暗号化コンテンツのSHA-1ハッシュとして定義された、BLOB-Idとして表す識別子によって命名される。例えば、文書３３２が単一ファイル（例えば、「my-document.pdf」）である場合、そのファイルがその中で提示されるサブディレクトリ<sub-D1>の名称は、ファイルの対応しているBLOBの暗号化コンテンツのSHA-1ハッシュに基づいている。例えば、my-document.pdfを表す暗号化されたBLOBの暗号化コンテンツのSHA-1ハッシュがテキスト列
「c10b555f72d954c8c889c97d357161790e0da4a5」
であるとする。

本発明の実施例では、文書のパス名は、
/docs/c10b555f72d954c8c889c97d357161790e0da4a5/my-document.pdf
としてあらわれ得る。ここで、my-document.pdfを表す暗号化BLOBのSHA-1ハッシュ（「c10b555f72d954c8c889c97d357161790e0da4a5」）が<sub-D1>の名称の役目を担う。

文書がファイル・ディレクトリを有する場合、サブディレクトリの名称は、ファイルのディレクトリに対応するディレクトリBLOBのSHA-1ハッシュに基づく。「ディレクトリBLOB」は、ディレクトリ自体のコンテンツについての情報を記憶する目に見えないファイル（例えば、ファイル及び／又はサブディレクトリのリスト）である。例えば、図３は、サブディレクトリ322aがファイルのディレクトリ（「my-web-page」と呼ぶ）を含むことを示す。図３に、点線を付したボックス332aによって略示したディレクトリ・ファイルは、ディレクトリ「my-web-page」についての情報を含む。サブディレクトリ322aの名称は、そのディレクトリ・ファイル332aの暗号化されたコンテンツのSHA-1ハッシュに基づいており、本発明の実施例では、パス名は、
/docs/2f267747fd8b6212aed1192ec05f42bc014f2ed7/my-web-page/index.htm
/docs/2f267747fd8b6212aed1192ec05f42bc014f2ed7/my-web-page/image-1.jpg
/docs/2f267747fd8b6212aed1192ec05f42bc014f2ed7/my-web-page/…
として現れ得る。ここで、<sub-Dn>の名称は、そのディレクトリ・ファイル332aの暗号化コンテンツのSHA-1ハッシュを表すテキスト列
「2f267747fd8b6212aed1192ec05f42bc014f2ed7」
である。当然、「my-web-page」ディレクトリ自体は、サブディレクトリを含み得る。

図３Aを参照すれば、フィードが、フィード・ディレクトリ３１４の下に記憶される。各フィードは、フィードの署名（後述する）の検証に用いる公開鍵の指紋として定義されるフィードのIDによって命名されるフィード・サブディレクトリ３２４に記憶される。フィード・ディレクトリ３２４それぞれは、エントリの作成時点、それに続くピリオド（「.」）、及びそれに続く、フィード・エントリ・ファイルのコンテンツのSHA-1ハッシュによって命名される、エントリ毎のサブディレクトリ３３４を含む。作成時点は、yyyyMMdd+「T」+HHmmss+「Z」の形式の協定世界時（UTC）でコード化すべきである。ここで「hh」は、２４時間形式の時間であり、「T」及び「Z」はリテラル文字T及びZである。

フィード・ディレクトリ３３４内にあるのは、ファイル344’、又はエントリを表すディレクトリ・ツリー３４４である。例えば、２つのエントリを備えたフィードは、
「/feeds/2f267747fd8b6212aed1192ec05f42bc014f2ed7/20070302T005408Z.25275a4085476e08cda88cd701d1949c72612d1a/my-feed/file.pdf」及び「/feeds/2f267747fd8b6212aed1192ec05f42bc014f2ed7/20070306T161144Z.bca9e1954824a32b1f8424511b3f01340ffe231b/my-feed/file-v2.pdf」として現れ得る。

フィード-Idは、
2f267747fd8b6212aed1192ec05f42bc014f2ed7であり、
サブディレクトリ334の名称の例は、
20070306T161144Z.bca9e1954824a32b1f8424511b3f01340ffe231b
である。

更に、フィードは最大３つの他のディレクトリ（すなわち、スクラッチ・ディレクトリ(.../-/)344a、最新ディレクトリ(.../latest/)344b、及びマージ・ディレクトリ(.../merged/)344c）を含む。ユーザが、特定のフィードに発行する機能を有する場合、スクラッチ・ディレクトリ344aが、対応するサブディレクトリ334において利用可能になる。これは、後にフィード・エントリとして発行され得る編集可能な局所のみのディレクトリである。スクラッチ・ディレクトリのコンテンツは、発行されるまで他のMakyohサーバに利用可能でない。フィードが、発行された少なくとも１つのエントリを含む場合、対応する最新のディレクトリ及びマージ・ディレクトリ344b、344cが利用可能になる。最新ディレクトリ344bは常に、エントリのタイムスタンプによって定められる、最新の既知エントリのコピーを有する。マージ・ディレクトリ344cは、既知エントリ全ての中に含まれるパス全てを含む。

例えば、フィードが２つのエントリ（一方はpath.../images/thing1.jpgを含み、他方はpath.../images/thing2.jpgを含む）を含む場合、「.../merged/images/」のリストがthing1.jpg及びthing2.jpgを示す。ディレクトリ構造は、
/feeds/2f267747fd8b6212aed1192ec05f42bc014f2ed7/-/
/feeds/2f267747fd8b6212aed1192ec05f42bc014f2ed7/20070306T…231b/images/thing1.jpg
/feeds/2f267747fd8b6212aed1192ec05f42bc014f2ed7/20070528T…54f2/images/thing2.jpg
/feeds/2f267747fd8b6212aed1192ec05f42bc014f2ed7/merged/images/thing1.jpg
/feeds/2f267747fd8b6212aed1192ec05f42bc014f2ed7/merged/images/thing2/jpg
として現れ得る。

２つの別々のファイルが同じ完全なパスを共有している場合、後のファイルのほうが優先する。

鍵リング・ディレクトリ３１６は、ユーザが今までにインポートした鍵全てを含むディレクトリである。鍵は、拡張子「.makyoh」を備えた鍵ファイル３２６として表される。文書鍵の鍵ファイルは、鍵に関連付けられた文書を表すファイル又はディレクトリのハッシュURIを含む。以下に説明するように、フィードのために２つの種類の鍵（すなわち、加入鍵及び発行鍵）が存在している。フィードの加入鍵の鍵ファイルは、加入フィード鍵BLOBのハッシュURIを含む。同様に、フィードの発行鍵の鍵ファイルは、発行フィード鍵BLOBのハッシュURIを含む。

局所ユーザは、通常のHTTP要求及びWebDAV要求（すなわち、GET、PUT、HEAD、MKCOL、PROPFIND、LOCK、UNLOCK、DELETE,MOVE,COPY and OPTIONS（POSTは現在サポートされていない））を行うことが可能である。更に、局所ユーザ（すなわち、局所ホスト１０２上のユーザ）は、クエリ・パラメータop=<operation>により、適切なポートに対して、局所ホスト102へのHTTP GET要求を行うことによって、種々の動作を実行することができる。以下の動作を提供する。

login：局所Makyohサーバへの認証を行う。ログイン動作及び停止動作以外には、ユーザがログインするまで、信頼できるユーザのAPIは利用可能でない。パラメータ「passphrase」（すなわち、ユーザのログイン・パスフレーズ）を取り込む。ユーザの全く最初のログインで、パスフレーズがセットされる。

create：新たなフィードが作成される。加入鍵及び発行鍵を生成する。フィードのパス、及びハッシュURI（両方のフィード鍵を指し示す）を返す。

createdoc：新たな文書を作成する。要求URLのパス部分は、フィード内のファイル又はディレクトリであるべきである。現在、文書のコンテンツ・タイプは、特定のパス上のファイル名の拡張子、又はディレクトリのテキスト／プレーンから自動的に決定される。パスに表したものとは別のファイル名を用いるためにパラメータnameを任意的に備えることができる。

publish：新たなフィード・エントリを発行する。要求URLのパス部分は、所望のフィードの/feeds/<feed-Id>/directoryの下のどこかのファイル又はディレクトリであるべきである。フィードの発行鍵は知られていなければならない。エントリのルート・ディレクトリのファイル名は、フィードの名称がデフォールトになるが、nameパラメータをセットすることによって上書きすることが可能である。任意のパラメータeraseをtrueにセットすると、発行後にスクラッチ・ディレクトリ(/‐/)が消去されることになる。

import;新たな鍵（ハッシュURI）をインポートし、関連付けられたBLOB及びフィード・エントリ・ファイルを取り出し、かつ／又は超流通させようとする。Keyパラメータは、インポートするためにハッシュURIにセットされるべきである。

stop:Makyohサーバをクリーンにシャットダウンする。

dbtrace:一時データベース及び要求リストのコンテンツを示す。デバッグに用いられる。任意的なパラメータlimitは、返される行数を制限するようセットすることが可能である。

info：要求URLパスに規定されたフィード又は文書についての情報を示す。情報は、プログラムによる容易な解析が意図されている。フィードに対して現在実行しているinfoにより、それら自身の行それぞれにフィードの名称、発行鍵（既知の場合）、及び加入鍵が与えられる。これには、各フィード・エントリのハッシュURI、及び（TABだけ離された）作成日（それぞれが、それ自身の行上にある）が続く。文書の場合、文書名が1行にあり、そのハッシュURIが、次の行にある。

iscomplete：要求されたURIのパスを示すために必要なBLOB及びファイル全てが、局所キャッシュにおいて利用可能な場合、列trueを返す。さもなければ、列falseを返す。これは、新たにインポートされたディレクトリ又はフィード・エントリが、近傍サーバからのダウンロードをもう終えたか否かを判定するために有用である。

B. 遠隔ビュー
図４を参照すれば、遠隔Makyohサーバ104乃至108からMakyohサーバ１０２への接続が、Makyohサーバ１０２の記憶構成部分２０４の記憶装置上に記憶されたファイルのビュー（「物理ビュー」）によって提示される。これは、図３に表した信頼できるユーザに提示されるアーカイブ（論理又は物理）ビューと比較される。

特定の実施例では、遠隔ユーザには、BLOBディレクトリ４１２及びエントリ・ディレクトリ４１４が提示される。BLOBディレクトリ４１２は、そのファイル名としてのその暗号化ファイルのコンテンツのSHA-1ハッシュをそれぞれが備えた暗号化BLOBファイル４２２を含むに過ぎない。例えば、
/blobs/003920e219057a12af32bbb65f196ade61e868c3
/blobs/0b294c4e2ca8903939673513df366567e9a13c7a
である。

BLOB４２２は、通常のコンテンツ・ファイル、ディレクトリ、又は、特別な内部使用ファイル（「フィード鍵」と呼ばれる」）を表すことが可能である。

エントリ・ディレクトリ４１４は、フィードIDによって命名されるサブディレクトリ４２４内にそれぞれがあるフィード・エントリ・ファイル４３４を含む。エントリ・ファイル自体４３４は、エントリの作成時点と、それに続くピリオド「.」、及びそれに続く、フィード・エントリ・ファイルのコンテンツのSHA-ハッシュとによって命名される。前述の通り、作成時点は、yyyyMMdd+「T」+HHmmss+「Z」の形式の協定世界時（UTC）でコード化すべきである。ここで「hh」は、２４時間形式の時間であり、「T」及び「Z」はリテラル文字T及びZである。例えば、
/entries/2f267747fd8b6212aed1192ec05f42bc014f2ed7/20070302T005408Z.25275a4085476e08cda88cd701d1949c72612d1a
/entries/2f267747fd8b6212aed1192ec05f42bc014f2ed7/20070306T161144Z.bca9e1954824a32b1f8424511b3f01340ffe231b
である。

本発明の実施例によれば、遠隔ビューにおいて提示されたファイル及びディレクトリは、ディスク上に記憶された実際のファイル及びディレクトリ構造である。遠隔サーバは、HTTP及びWebDAV（タイプ２）要求（例えば、GET、PUT、HEAD、MKCOL、PROPFIND、LOCK、UNLOCK及びOPTIONS）の部分集合を行うことが可能である。他の要求（例えば、POST、DELETE、MOVEやCOPY）により、Bad Requestエラー(400)が返されることになる。

V. ファイル形式
A. BLOBファイル形式
次いで図５を参照すれば、BLOBファイル５０２は、変更可能でなく、特定の時点で存在していたファイルの単一のバージョンのみを表す。図５では、各BLOBファイル５０２は、文書アイコン及びロック・アイコンによって示す。BLOBファイル５０２に関連付けられた文書アイコンは、コンテンツが暗号化されている旨を関連ロック・アイコンが示す、ファイルのコンテンツを表す。BLOBファイル５０２の暗号化コンテンツは、そのそれぞれの対称復号鍵520aを用いて復号される。各復号鍵502aは、復号鍵としての役目を担う暗号化BLOBファイル５０２につながる矢印によって図５に示す。

前述の通り、BLOBファイル５０２は変更可能でない。すなわち、BLOBファイルの特定のインスタンスは修正することが可能でない。しかし、ユーザは、例えば、ファイルの中を読み取り、所望の編集を行い、それ自身の固有のID及び復号鍵502aとともに、完全に新たなBLOBファイルに、修正されたコンテンツを書き出すことにより、修正を行うことが可能である。BLOBファイル５０２は、そのID及び鍵502aとともに、暗号化されているファイルのコンテンツに基づいて自動的に計算される。ファイルには、全てスペースで離された、BLOBのタイプ（現在、BLOB、ディレクトリ又はフィード鍵）、バイト単位での文書の長さ、及び任意的な「salt」列を有する、ヌルで終わるヘッダが最初に付加される。この平文テキストは次いで、DEFLATEアルゴリズムと呼ばれる既知のアルゴリズムを用いて圧縮され、平文のMD5ハッシュを暗号鍵として用いて、既知の高度（Advanced）暗号化システム・アルゴリズムによって暗号化される。結果として生じるBLOBのIDは、小文字の16進形式の40桁の列としてコード化された、暗号化BLOBのコンテンツのSHA-1ハッシュである。より公式には、
header=type+「」+length[+「」+salt]+null
type=「blob」|「directory」|「feedkey」
length=10進形式の列として表す、バイト単位の、文書の長さ
salt=最大128バイトの任意の列
null=ゼロのバイト(0x00)
blob-key=128ビットの数として表すMD5(header+document)
init-vector=ゼロのバイト(0x00)
compressed-doc=DEFLATE(header+document)（修正タイムスタンプが-1にセットされる）
blob=AES(header+compressed-doc, blob-key, init-vector)
blob-id=小文字の16進形式の40桁の列として表すSHA-1(blob)
ヘッダは２つの目的にかなう。まず、ヘッダは、長さがゼロの文書でさえMD5ハッシュを生成することが可能であることを保証する。第２に、ヘッダは、saltが使用されなかった場合に得られる、別のIDを備えたBLOBファイルを生成するために使用することが可能な任意的な「salt」を含む。これは、記憶の点で、より効率的でないことがあり得るが、特定の種類の攻撃に対する更なるプライバシをもたらす。

BLOBの鍵502a及びIDのハッシュを用いることの一利点は、処理が、文書コンテンツによって完全に判定されるということである。ちょうど同じ文書の複数のコピーは、文書が別々の個人によって無関係に発行された場合にも、同じBLOBファイル及びBLOB-Idを生成する。これは、いくつかの違った文書のディレクトリ・ツリーに同じファイルが現れる場合に特に、アーカイブが用いる記憶量を削減する。唯一の例外は、発行者が、任意的なsaｌｔをそのヘッダに加える場合である。この場合、saltに基づいた別のblob及びblob-Idが（作為的に）作成される。

B. ディレクトリBLOB
ディレクトリBLOB５０４は、前述の通り、コード化され、暗号化された（BLOB形式で）、ディレクトリが含むファイル及びサブディレクトリを指し示すハッシュURIのリストに過ぎない。ディレクトリBLOB５０４は、タイプdirectoryを有する。例えば、２つのファイル、及びサブディレクトリを含むディレクトリBLOB５０４の復号されたコンテンツは、以下を含む。

ディレクトリ413[ヌル]
hash:sha1=0b294c4e2ca8903939673513df366567e9a13c7a;aes128-key=8254de7ae9e95bd6fef8f8a821b4aa49?content-type=text/html&name=index.html
hash:sha1=392bec1f9988f506d148166f1a02f1d9117fb2fd;aes128-key=7ba3350396f7b8502863fe52160c88ba?content-type=image/jpeg&name=thumbnail.jpg
hash:sha1=7c532dd44cd0f54201c72539dcfdbf49bd00ae4a;aes128-key=873cc62fb1af8aec4c3127b8ecfa941e?content-type=application/octet-stream&name=thumbnails/
ディレクトリが、信頼できるユーザのAPIにおいて取り出されると、対応するディレクトリBLOB５０４が復号され、そのコンテンツのID、鍵、MIMEタイプ、及び名称が一時データベースにキャッシュされる。このデータベースを次いで用いて、ユーザのアーカイブのディレクトリ構造及びファイルを提示する。キャッシング・データベースの使用は、性能を改善するが、必然的でなく、本発明の他の実施例をデータベースなしで容易に実現することが可能である。

C. フィード鍵BLOB
フィード鍵BLOB５０６は、フィード・エントリの復号及び検証に必要であり、任意的にフィード・エントリの作成（発行）に必要な鍵を含むファイルである。フィード鍵の形式には２つある（すなわち、フィードへの読み出し専用アクセスを付与する加入鍵、及びエントリを読み出し、新たなエントリを発行する機能を付与する発行鍵）。フィード鍵ファイル５０６は、それぞれがラインフィード（＼n）だけ隔てられた、以下のフィールドを含む。コンテンツ全体が次いで、暗号化され、BLOBとしてコード化される（前述の通り）。

Header：列「MAKYOH FEEDKEY VERSION n」。ここで、nは、使用される、フィード鍵ファイル形式のバージョン番号（現在、1.0）である。

Entry-key：列「Entry-key:」及び、これに続く、このフィードの各フィード・エントリ・ファイルにおけるエントリ・フィールドを暗号化し、復号するために用いるランダムに生成される128ビットの対称鍵。上記鍵は、小文字の１６進形式の３２文字の文字列としてコード化される。

Verify-key：列「Verify-key:」と、これに続く、ラインフィード(＼n)と、これに続く、フィード・エントリに署名するために用いるための公開鍵と、これに続く別のラインフィード。例えば、この鍵は、オープンPGP形式標準によって定義されるASCII形式の公開鍵であり得る。行は、キャリッジ・リターン・ラインフィード（＼r＼n）でなく、ラインフィード(＼n)で隔てられるべきである。

Write-key:（任意）列「Write-key：」、並びにそれに続く、ラインフィード(＼n)、及び新たなフィード・エントリの署名に用いるための秘密鍵。例えば、この鍵は、オープンPGP形式標準によって規定されるASCII形式の秘密鍵であり得るものであり、フィードのverify-keyのsecret-key対であるべきである。Write-keyフィールドは、加入鍵において一覧化されず、発行鍵においてのみ一覧化される。

フィードIDは、小文字の40文字の16進形式の文字列としてコード化された、オープンPGP形式標準によるフィードの検証鍵の１６０ビットの鍵の指紋として定義される。

D. フィード・エントリ・ファイル
フィード・エントリ・ファイル506aは、フィードに対するエントリについての情報を含むファイルである。フィード・エントリ・ファイル５０６aは、それぞれがラインフィード（＼n）だけ隔てられた、以下のフィールドを含む。前述のコンテンツは、暗号化BLOBとしてコード化されない（しかし、図５に示す「エントリ」フィールド506bは、後述するように暗号化形式で暗号化される）。

Header：列「MAKYOH FEED KEY ENTRY VERSION n」。ここで、nは、使用される、フィード・エントリ・ファイル形式のバージョン番号（現在、1.0である）である。

Date:列「Date:」、及びそれに続く、yyyy-MM-dd+「T」+HHmmss+「Z」としてコード化された、協定世界時（UTC）におけるこのエントリの作成日。例えば、「Date:2007-03-02T00:54:08Z」
Entry：列「Entry:」、及び次に続く、フィードのフィード鍵において規定されたEntry-keyを用いて暗号化された、このエントリを表す文書（ファイル又はルート・ディレクトリ）のハッシュURI。暗号化されたコンテンツは、小文字の１６進形式の文字列（通常約２５６文字）としてコード化される。

Verify-key：列「Verify-key:」と、これに続く、ラインフィード(＼n)と、これに続く、フィード・エントリを検証するために用いるための公開鍵と、これに続く別のラインフィード。例えば、この鍵は、オープンPGP形式標準によって定義されるASCII形式の公開鍵であり得る。

Signature：フィードのフィード鍵において規定された書き込み鍵を用いた、前述のフィールドのコンテンツに対する公開鍵署名。例えば、この署名は、オープンPGP形式標準によって定義されるASCII形式の署名ブロックであり得る。

E. 鍵リング
鍵リングは、ユーザがインポートした鍵（すなわち、URI）の集合物である。本発明の一インスタンス化では、鍵リングは、局所のMakyohサーバ１０２上に記憶された私設ディレクトリとして実現される。図３及び図５を参照すれば、全く初めてユーザがMakyohサーバにログインすると、個人鍵リング・ディレクトリ３１６が自動的に作成される。鍵がインポートされると、それはユーザのパスフレーズを対称鍵として用いて暗号化され、結果として生じる暗号化ファイル３２６は次いで、鍵リング・ディレクトリ３１６に記憶される。ユーザが自分のパスフレーズを用いてログインすると、Makyohは、ユーザの鍵リング・ディレクトリにおける全ての鍵ファイルを復号することによって立ち上げる。鍵（ハッシュURI）をインポートする処理は、以下に更に説明する。

VI. 発行及び超流通
本発明の通常の利用シナリオを次いで説明する。例として、ユーザ（アラン）が、競合会社とのビジネス交渉に出席しており、ユーザの文書が、自分のラップトップ上で実行する自分の個人Makyohアーカイブに記憶されているとする。アランが、自分のラップトップ上の交渉戦略の概要にアクセスすると、その概要の暗号化BLOBが、当該領域においてMakyohを実行している他のラップトップ全てに対して自分のラップトップによって複製される。その文書に対する鍵が全く明らかにされない場合、ユーザは、自分の文書のコピーを、会議における他の人全員のラップトップ上に効果的にセキュアにバックアップしていることになる。逆に、ユーザのMakyohサーバは同様に、他のラップトップの文書を、前述のラップトップ上の文書にアクセスされるとバックアップする。アランは、ラップトップが後に盗まれた場合、新たなラップトップを購入し、Makyohをインストールし、自分の鍵を再インポートすることにより、自分の文書を回復することが可能であり、Makyohは次いで、当該領域における他のラップトップから必要なBLOB全てを自動的に取り出すことになる。本発明の特定の実施例では、「鍵」は前述のハッシュURIである。ユーザは、ハッシュURI（文書、文書ディレクトリ、又はフィード・エントリ毎に１つ）を搬送し、他のユーザに回して情報へのアクセスを付与する。ハッシュURIは、記憶装置（例えば、サムドライブ）上、印刷可能な媒体（例えば、線形バーコード、2次元バーコード等）上等の「鍵ファイル」に好都合に記憶することが可能な数百バイト程度の小量のデータである。

次に、会議においてその後、同僚（ボブ）が、アランの戦略の概要のコピーを要求するとする。ファイルは、特にマルチメディアを含んでいる場合、非常に大量であり得るものであり、無線を介した、又はUSBサムドライブを介した転送に数分かかり得る。しかし、アランのMakyohは、文書を構成する暗号化されたBLOBを、ボブのものを含む他のラップトップに既に流通させているので、データはボブのラップトップに既にある。アランは、通常は数百バイト未満になる関連付けられた鍵ファイル（ファイルに記憶されたハッシュURI）をボブに渡すだけでよい。鍵は、非常に小量であるので、すばやくかつセキュアに、より大きなファイルでは可能でない種々のやり方で送信することが可能である。例えば、鍵は、名刺上に2次元バーコードとして印刷し、赤外線によってPDAに送り、NTTのレッドタクトンなどの手法を用いてヒューマン・タッチにより、又は、ブルートゥースやインスタント・メッセージングなどのより伝統的な手段によって送信することが可能である。数秒以内に、同僚は、BLOBの元の送信（この時点では既に完了している）が数分かかっていても、文書にアクセスすることが可能である。

前述の使用法の説明は、本発明の種々の動作を例証しており、これらは次いで、以下の図における処理の説明に関して更に詳細に説明する。処理は、図２に示すMakyohサーバの適切なデータ処理構成部分によって行うことが可能である。以下の図に表す処理は、データ処理構成部分２０２によって実行される適切なコンピュータ・プログラム・コードで実施することが可能である。

1. アクセス
文書がアーカイブからアクセスされると、それに関連付けられたBLOBのIDは、他のサーバにプッシュする対象のファイルのリストに自動的に追加され（プットBLOBキュー）、見つからない、文書によって必要なBLOBは、他のサーバから得る対象のファイルのリストに追加される（ゲットBLOBキュー）。同様に、フィード・エントリにアクセスされると、対応するフィード・エントリ・ファイルが、他のサーバにプッシュする対象のフィード・エントリ・リストに追加され（プット・フィード・エントリ・キュー）、そのフィード-Idが、他のサーバ上の新たなエントリを求めて確認する対象のフィード・リストに追加される（ゲット・フィード・キュー）。ゲットBLOBキュー、プットBLOBキュー、ゲット・フィード・キュー及びプット・フィード・キューに追加される要求は、特定量の時間（デフォールトでは1時間）後に満了し、その後、前述の要求は、個別のキューから除去される。通常、前述のキューは、Makyohサーバのメモリにおけるデータ構造として実現される。しかし、他の機構が考えられることが以下の記載から明らかになるであろう。

本発明の実施例による、文書アクセスの概略フローの説明について図６Aを参照されたい。要求者（すなわち、信頼できるユーザ）は、アクセスする対象の文書のパス名をMakyohサーバ（「局所サーバ」）に規定する。信頼できるAPIでは、ユーザは、取り出す対象のファイル又はディレクトリの完全なパス名を規定する。例えば、
/docs/c10b555f72d954c8c889c97d357161790e0da4a5/my-document.pdf又は
/docs/92572a9472d954c8c889c97d357161790e259751/my-webpage/images/thumbnail.jpfである。

本発明の実施例では、Makyohアーカイブの信頼できるユーザのビューは、仮想ファイル・システムのビュー（図３）である。ユーザによって提供されるパス名は、その仮想ファイル・システムのコンテキストにある。本明細書及び特許請求の範囲記載の仮想ファイル・ファイル・システムの実施例では、ファイル・システムは、UNIX(登録商標)オペレーティング・システムなどのように階層的であり、よって、パス名がUnix(登録商標)パス名のようにみえる。

本発明の特定の実施例では、パス名は、暗号化BOLBファイルにつながる。その暗号化BLOBファイルから、要求された文書の平文表現が得られる。暗号化BLOBが得られると、鍵（ハッシュURI）を用いて、得られたBLOBのコンテンツを復号する。以下に、局所Makyohサーバにおいて行われる処理を説明する。

工程602では、要求された文書のBLOB-Idが、要求者によって指定されるパス名に基づいて判定される。本発明の特定の実施例では、BLOB-Idは、パス名におけるサブディレクトリ３２２（図３）の名称である。前述の例を用いて、
/docs/c10b555f72d954c8c889c97d357161790e0da4a5/my-document.pdfとする。
BLOB-Idは、
c10b555f72d954c8c889c97d357161790e0da4a5になる。

工程601では、BLOB-Idが鍵リングに既にあるか否かが判定される。前述の特定の実施例では、鍵リング・ディレクトリ３１６（図３）は鍵ファイル３２６を含む。鍵ファイル３２６のそれぞれは、鍵に関連付けられた文書を表す、ファイル又は文書のハッシュURIを含む。ハッシュURIはBLOB-Idを含む。工程６０２から判定されたBLOB-Idを求めて、鍵ファイル３２６におけるハッシュURIのサーチが行われ、よって、要求された文書に関連付けられた鍵ファイルを識別する。BLOB-Idが見つからなかったと工程６０１で判定された場合、要求された文書が、見つかっていないと認められ、要求された文書が見つからない旨を示す適切な応答が工程６９２において要求者に送出される。

図６Aにおける工程６１５について説明する。鍵ファイル３２６のうちの１つにおいてBLOB-Idが見つかった旨が工程６０１で判定された場合、要求されたBLOBファイルの局所コピーが、要求者の局所Makyohサーバの文書ディレクトリ３１２（図３）に記憶されているか否かが工程６０３で判定される。否定の場合、工程６１０で、別の（「遠隔」）Makyohサーバから、要求された文書を得ようとして、キューにBLOB-Idを入れることによってゲットBLOBキュー上に「プル要求」がキューイングされる。工程６１２では、以下に更に説明するように、ゲットBLOBキューが処理される。ゲットBLOBキューにおけるBLOB-Idは、文書アクセス毎に、あるいは、ある所定数の文書アクセスが生じた後に、あるいは、所定期間が経過した後に、あるいは、他の適切な基準に基づいて、あるいは、上記の特定の組み合わせに基づいて処理することが可能である。本発明の実施例では、ゲットBLOBキューに追加される要求は、特定量の時間（例えば、1時間）後、満了する。その後、前述の要求はキューより除外される。

工程６０７では、BLOBが遠隔Makyohサーバから首尾良く取り出され、局所サーバの記憶構成部分２０４に記憶されていると判定された場合、処理は以下の工程６０４に進む。BLOBが首尾良く取り出されなかった（例えば、他のMakyohサーバがBLOBを含んでいない）と工程６０７で判定された場合、要求された文書が見つからなかった旨を示す適切な応答を工程６９２で要求者に送出する。

要求されたBLOBの局所コピーが見つかった（工程６０３）か、又は要求されたBLOBファイルのコピーが、遠隔Makyohサーバから取り出された（工程６０７）場合、工程６０４で、要求された文書に関連付けられた鍵ファイル３２６に記憶されたハッシュURIに含まれたBLOB-keyを取得し、使用して、暗号化BLOBファイルを復号する。結果として生じる平文は、要求された文書を構成する。

コンテンツの処理が次いで、アクセスを行うアプリケーションに渡される。要求された文書が実際にディレクトリであるか、又は実際の文書であるか（例えば、PDFファイル）であるかが工程６０５で判定される。アプリケーションは、ブラウザ、又はOSのウィンドウイング・システムである場合、ファイル（工程６０６）又はディレクトリ（工程６０８）をユーザに提示することが可能である。「ディレクトリ」の場合、ユーザは、ディレクトリにおける文書の１つを選択し、アクセスを起動させ、よって、選択された文書を得るよう上記を繰り返す。別のアプリケーションは、ユーザに何も表示しない動作をとり得る。例えば、その別のアプリケーションは、アクセスされたファイルからその構成情報を読み出すことができる。

図１Aに戻れば、本発明の別の実施例では、Makyohサーバは、プリンタやファックス機等などの文書処理装置102’において実施することが可能である。図６Aの一コンテキストでは、ユーザは、ラップトップやPDAなどの自分の個人サーバに対して要求を行って文書にアクセスすることが可能である。別のコンテキストでは、ユーザは、プリンタ装置（又はファクシミリ機）に対して同様の要求を行って、印刷（又はファックス）する対象の文書にアクセスすることが可能である。装置102’は、Makyohサーバとして構成することが可能であり、必要な場合、別のMakyohサーバから文書を得る工程、及び、得られた文書を印刷又はファックスする工程に加えて、文書を他のMakyohサーバに流通させる工程を含み、図６Aにより、文書にアクセスすることが可能である。

図6Bを参照すれば、フィード・エントリへのアクセスの全体フローは、文書へのアクセスのフローと同様である。前述の通り、ユーザは、信頼できるユーザに提示されるアーカイブ・ビューによってパス名を規定する。しかし、フィードの場合、特定のフィード・エントリは、
/feeds/2f267747fd8b6212aed1192ec05f42bc014f2ed7/20070306T161144Z.bca9e1954824a32b1f8424511b3f01340ffe231b/my-entry.pdf、又は
/feeds/a2693f77fd8b6212aed1192ec05f42bc014f2ed7/20070215T121022Z.f294e1954824a32b1f8424511b3f01340ffe1194/my-entry-dir/images/thumbnail.jpg
のようになり得る。

工程632では、要求されたフィードのフィード-Idが、局所Makyohサーバにおいて要求者によって指定されるパス名に基づいて判定される。本発明の特定の実施例では、フィード-Idは、パス名におけるサブディレクトリ324（図３A）の名称である。

工程631で、フィード-Idに関連付けられたフィード鍵が既知であるか否かが判定される。一実施例では、これは、フィード鍵リストと呼ばれる連想リストを維持し、サーチすることによって実現することが可能である。フィード鍵リストは、特定のフィード-Idのフィード鍵ファイルのルックアップを可能にする。ユーザが、自分のパスフレーズにログインすると、フィード鍵リストは、加入鍵又は発行鍵がユーザの鍵リングに存在しており、関連付けられたBLOBがユーザの局所レポジトリに記憶されているフィード鍵全てを含むよう初期化される。この初期化が行われる処理は以下に更に詳細に説明する。工程６３２から判定されるフィード-Idに関連付けられたフィード鍵を求めて、フィード鍵リストにおけるサーチを行い、よって、要求されたフィードに関連付けられたフィード鍵ファイルを識別する。フィード-Id及び関連付けられたフィード鍵が見つからなかった場合、要求されたフィードが見つからなかった旨を示す適切な応答が工程６９４で要求者に送出される。

フィード-Idがフィード鍵リストにおいて見つかった場合、要求されたフィードのエントリ・ファイル４３４（図４）の局所コピーが、要求者のMakyohサーバ１０２のエントリ・ディレクトリ４１４に記憶されているか否かが工程６３３で判定される。フィード-Idがフィード鍵リストにおいて見つからなかった場合、工程６４０で、別の（「遠隔」）Makyohサーバから、要求されたフィードのエントリ・ファイルを得ようとしてキューにフィード-Idを入れることにより、ゲット・フィード・キュー上に「プル要求」がキューイングされる。工程642では、以下に更に説明するように、ゲット・フィード・キューが処理される。ゲット・フィード・キューにおけるフィード-Idは、フィード・アクセス毎に、あるいは、ある所定数のフィード・アクセスが生じた後に、あるいは、所定期間が経過した後に、あるいは、他の適切な基準に基づいて、あるいは、上記の特定の組み合わせに基づいて処理することが可能である。本発明の実施例では、ゲット・フィード・キューに追加される要求は、特定量の時間（例えば、1時間）後、満了する。その後、前述の要求はキューより除外される。

工程637で、エントリ・ファイルが遠隔サーバから首尾良く取り出され、局所記憶構成部分204に記憶されていると判定された場合、処理は以下の工程634に進む。エントリ・ファイルが首尾良く取り出されなかった（例えば、他のMakyohサーバがエントリ・ファイルを含んでいない）と工程637で判定された場合、要求された文書が見つからなかった旨を示す適切な応答を工程694で要求者に送出する。

要求されたフィードのエントリ・ファイルの局所コピーが見つかった（工程６３３）か、又は、エントリ・ファイルのコピーが別のMakyohサーバから取り出された（工程６３７）場合、工程６３４で、エントリ・フィールド（506b、図５）を、要求されたフィードに関連付けられたフィード鍵リストから取り出されたフィード鍵ファイルを用いて復号して、要求されたフィード・エントリに関連付けられたファイル又はルート・ディレクトリのハッシュＵＲＩを得る。工程６４４で、このハッシュＵＲＩが、以下に説明する鍵リングにインポートされる。工程６４５で、ハッシュＵＲＩに関連付けられた文書パスが、列「/docs/」、ハッシュURIにおいて規定されたBLOB-Id、列「/」、及びハッシュURIにおいて規定されたファイル名を連結することによって算出される。例えば、ハッシュURIがhash:sha1=c10b555f72d954c8c889c97d357161790e0da4a5;aes128 key=82c…b163?content type=application/pdf&name=my-document.pdf
であるとする。

文書パスは、
/docs/c10b555f72d954c8c889c97d357161790e0da4a5/my-document.pdf
となる。

工程６３６では、フィード・エントリは、適切な（例えば、文書の表示及び／又は編集を可能にするための）ソフトウェアを介して要求者にフィード・エントリを通信する工程を含む、前述の図６Aによる文書の取り出しと同様に取り出される。

2. 新たなサーバの加入
各Makyohサーバは、そのサーバの「近傍」と呼ばれる、BLOB及びフィード・エントリを共有すべきサーバ組を維持する。一般に、近傍は、「近い」とみなすことが可能な、Makyohを実行するサーバに限定される。例えば、（「局所」サーバとしても表す）特定のMakyohサーバの近傍は、局所サーバと同じ局所サブネット上で通信する他のMakyohサーバ（「遠隔」サーバとしても表す）として定義される。「近く」は、物理的な至近性を示唆してもしなくてもよい。例えば、局所サブネット上の大半のサーバは、物理的に互いに近くなる可能性が高くなるが、一部のサーバは、ＶＰＮ（仮想私設ネットワーク）を介して接続されている場合、物理的に離れていることがあり得る。重要なのは、送信されるＢＬＯＢを復号することが最終的にできる平均確率、又は、復号することが可能なマシンにＢＬＯＢを再配分する平均確率よりも高い確率を有するマシンに流通が限定される。この例では、同じサブネット上のユーザはおそらく、同じ組織の一部であり、したがって、互いに文書を共有する可能性が高い。

他の実施例は、近傍を構成するために他の基準を用いることができる。例えば、近傍は、ユーザの仕事用マシン及び家庭用マシンを含み得る。別の例として、普段、電子メール、インスタント・メッセージング又は電話を介して通信する人々のMakyohサーバは、物理的に数千マイル離れていて、別々のサブネット上で通信しても近傍とみなし得る。前述のサーバは、通信が進行中である間（例えば、ユーザが電話で互いに通信している時）にのみ互いの近傍にあり得るか、又は、通信が終わってからしばらくは互いの近傍にあり続け得る。

一実施例では、局所Makyohサーバは、Makyohを実行するマシンが、局所サブネットに加入するか、局所サブネットを離れる都度、ボンジュール（汎用的に、マルチキャストDNS+DNSサービス・ディレクトリとして知られている）と呼ばれるオープン・プロトコルを用いて通知される。局所Makyohサーバは、新たなサーバについて通知されると、新たに加入するサーバが、ゲット及びプットBLOBキュー上にBLOB及びエントリ・ファイルを有するか否かを（HTTP ヘッド要求及びHTTP PROPFIND要求を用いて）自動的に判定し、次いで、必要に応じて、HTTP GET要求及びHTTP PUT要求を用いてファイルの適切なプッシュ又はプルを行う。新たな要求が追加される都度、局所サーバの近傍における既知のサーバ全てについて、同様な動作組が行われる。各遠隔サーバ上に保持されるファイルはキャッシュされるので、要求をセッション毎に2回以上行わなくてよい。

本発明の別の実施例では、局所Makyohサーバの近傍は、DNSリソース・ディスカバリを用いて、特定の組織内でMakyohを実行するサーバ組（組織において実行するMakyohサーバ全てについてその組織のドメイン名サービス・サーバにクエリすることによって判定される）として定義される。この実施例では、新たなサーバは、オープンDNS UPDATEプロトコルを用いることにより、近傍に加入する。別の実施例では、局所Makyohサーバの近傍が明示的に（例えば、構成ファイルの使用によって）セットされる。

別の実施例では、局所Makyohサーバの近傍は、直接無線通信を設定することが可能な、Makyohを実行する他のサーバの組（すなわち、無線の範囲内のサーバ）として定義される。この実施例では、新たなサービスは、範囲内の他のMakyohサーバに無線チャネルを介してその存在をブロードキャストすることにより、近傍に加入する。

別の実施例では、局所Makyohサーバの近傍は、他の最近のネットワーク・トラフィックが最近、通信されている、Makyohを実行するマシンの組として定義される。例えば、ユーザが、別のユーザとのインスタント・メッセージ（IM）チャットを起動させた場合、その個人Makyohサーバそれぞれは、他者の近傍に加入する。その個人Makyohサーバは、一方ユーザが電子メールを他方ユーザに送出した場合、一方のユーザが他方のユーザを電話で呼び出した場合等に互いの近傍に加入する。

別の実施例では、遠隔Makyohサーバは、局所Makyohサーバに対するGET又はPUTを起動させようとした場合、局所サーバの近傍に自動的に追加される。この実施例により、近傍の異なる基準を用いたサーバが、互いの近傍へ互いに加入することが確実になる。当然、近傍の種々の定義を（例えば、局所サブネット上のサーバ、及び無線範囲内のサーバを含めることにより）組み合わせることができ、「近傍」の複数の定義を用いることもでき、近傍の他の定義をなお想定することが可能である。

「セッション」は、局所サーバが遠隔サーバを検出した時点（例えば、ボンジュールによってアナウンスされた時点）から、遠隔サーバがそのアプリケーションをやめるか、又はさもなければ、近傍を離れる時点までの時間を表す。遠隔サーバは、近傍を離れると、事実上、やめている（又はログアウトしている）。保持していたファイルのレコード全てが廃棄される。これは部分的に行われる。アナウンスされている新たなサーバが、先行して局所サーバに知られているものか否かが分かる直接的な方法が存在しないからである。サーバは通常、固有のIDを有しておらず、サーバIPアドレスは変わり得る（例えば、DHCP（動的ホスト構成プロトコル）の場合）。

図７Aは、新たなサーバ（新たに加入したサーバ）の検出の処理の基本工程を示す。第１に、新たなサーバが、新たに加入したサーバを検出するサーバに記憶されたREMOTEリスト（工程７０２）に追加される。このリストは、以下に説明する対象のサービス・ルーチンにおいて用いる。更に、工程７０４及び７０６では、ゲット・フィード・キュー及びゲットBLOBキューを処理して、新たに加入したサーバからフィード・エントリ及びBLOBを得るようサービス・ルーチンが実行される。次いで、工程７０８及び７１０において、プット・ブロブ・キュー及びプット・フィード・キューを処理して、新たに加入したサーバから得られた文書を、先行して検出されたサーバに流通させるようサービス・ルーチンが実行される。別の実施例では、単一のREMOTEリストが、「近傍」におけるサーバによって更新し、アクセスすることが可能な、共通にアクセス可能な場所（例えば、DNSサーバ）に記憶することが可能である。

図７Aは、近傍にあるMakyohサーバが、加入サーバによって通知される処理を表す。あるいは、近傍における各サーバは、それ自体により、加入サーバについて通知され得る。例えば、サーバは、他のサーバの物理的な存在を求めて監視するディジタル・カメラを有し得る。サーバは、画像を定期的に捕捉し、画像を解析することにより、新たなサーバが近傍に加入した旨を判定することが可能である。単純であるが、この例は、加入サーバがその存在をブロードキャストしなくてよい旨を指摘している。この考え方は、近傍におけるサーバが、新たに加入するサーバについて通信され得るか、又はさもなければ、新たに加入するサーバのことを知り、これに応答して、図７Aに表す工程を行うというものである。

図7Bは、サーバがサーバ群を「離れる」と、群内に留まっているサーバがこれを検出し、それぞれは、離れるサーバをそのREMOTEリストから除外することになる。特定の実施例では、離れるサーバの残りのサーバによる検出は、ボンジュール・プロトコルによって全面的に処理される。基本的に、サーバは、ネットワークを立ち去るか、又は離れる場合、その離脱をアナウンスするマルチキャスト又はブロードキャストのメッセージを送出する。残りのサーバは、前述のメッセージを受け取ると、適切な動作を行うことが可能である。

3. インポート鍵
図８は、ハッシュURIがインポートされると生じる処理を示す。ハッシュURIは、記憶された暗号化BLOB又はフィード鍵（それ自体がBLOBである）を復号するための復号鍵を提供する。サーバ（受信サーバ）がハッシュURIを受信すると、工程８０１で、受信されたハッシュURIが受信サーバに既に記憶されているか否かが工程８０１で判定される。否定の場合、受信されたハッシュURIは、受信サーバの記憶装置２０４に記憶される（工程８０６）。処理は工程８０２に進む。工程８０２では、BLOB-IdがハッシュURIから得られる。工程８０３では、BLOB-Idに関連付けられたBLOBのコピーが、受信サーバに既に入っているか否かが判定される。コピーが存在している場合、プッシュBLOBサービスが、図１３に表すように、工程８０４において行われる。図１３の説明から明らかになるように、受信サーバに既に記憶されている場合、これは、BLOBのコピーを他の遠隔サーバに流通させることになる。BLOB-Idに関連付けられたBLOBのコピーが受信サーバにまだ入っていない場合（工程８０３）、工程８０８で、BLOB-IdがゲットBLOB上にキューイングされ、工程８１０で、ゲットBLOBキューが、図１０のように処理される。

上記利用シナリオでは、アランのラップトップは、アランの暗号化された戦略概要をボブのラップトップにコピーしている。新たなユーザ（カール）は、アランのMakyohサーバによる、暗号化された戦略概要のコピー後にグループに加入している場合、コピーを有しないことになる。しかし、例えば、バーコードを走査することにより、アランがその後、ボブに自分の鍵（ハッシュURI）を渡すと、ボブはアランの鍵を「インポート」し、そうすることにより、カールは、図８に表す処理の動作により、暗号化された戦略概要のコピーを受け取る。カールはその場合、単に、アランから、又はボブから鍵を取得すればよい。

次いで、ダンがグループに加入したとする。ダンは、アランの暗号化された戦略概要のコピーを有していない。更に、ダンがグループに加入して以来、直近の一時間に誰もアランの鍵をインポートしていないとする（一時間後にBLOB-Idがキューから除去されるとする。「旧くなった」idは以下に説明する）。以下に説明するように、旧くなったidはキューから除外される。ダンにとってこれが何を意味するかといえば、ダンが加入すると、アランのサーバが、上記概要のコピーを送出しない（アランのプットBLOBキュー内のｉｄが削除されていることになるからである）。しかし、ダンは、単に、ログイン後にアランの鍵をインポートすることにより、アランの概要のコピーをなお得ることが可能であり、図８の処理により、概要のコピーが、ダンのMakyohサーバ上に複製されることになる。

4. BLOBサービス
図９Aは、局所Makyohサーバ上でゲットBLOBキューを処理するための処理を示す。局所Makyohサーバは、BLOB-Idのリストを後の処理（Blob-Idに関連付けられたBLOBは、他の（遠隔）Makyohサーバから取り出され、局所Makyohサーバの記憶装置２０４に記憶される）のために作成する。本発明の特定の実施例では、ゲットBLOBキューにおける旧くなったBLOB-Idは工程９１３で除去される。これは図１４に関し、以下に更に詳細に説明する。工程902a、902bは、ゲットBLOBキュー上の各Blob-Idを処理するための外部ループを表す。BLOB-Id毎に、例えば、図７A及び図７Bによって管理するように内部ループ904a、904bが、REMOTEリスト内のMakyohサーバ毎に処理される。よって、REMOTEリストにおける候補サーバ毎に、工程９０３で、候補サーバがBLOB-Idを有しているか否かが判定しようとする。判定を行うことが可能でない場合、工程９０６で、HEAD要求を候補サーバに対して行って、BLOB-Idを含むか否んでいるか否かについて尋ねる。工程９０３で、候補サーバがBLOB-Idを含まないと判定された場合、REMOTEリスト内の次のサーバが検討される（工程904a、904b）。

工程９０３で、候補サーバがBLOB-Idを実際に含むと工程９０３で判定された場合、工程９０８で、GET要求をそのサーバに対して行って、対応するBLOB（新たなBLOB）を取得する。新たなBLOBが、工程９１０で処理される。その更なる詳細は以下に説明する。新たなBLOBが却下されたか否かが工程９０５で判定される。新たなBLOBが却下された場合、工程９１２で、その候補サーバが、BLOBを有していないとしてマーキングされる。その結果、工程９０３で、NO分岐がそのサーバについて採用される。新たなBLOBが却下されない場合、処理は、ゲットBLOBキュー内の次のBLOB-Idに続く（工程902a、902b）。

図９Bは、局所Makyohサーバ（すなわち、新たなBLOBを受信するサーバ）による、新たなBLOBの処理を表す。初期検証が、BLOBコンテンツのSHA-1ハッシュを計算し（工程942a）、BLOBが書き込まれるパスに規定されたBLOB-Idを計算し（工程942b)、次いで、上記２つを比較する（工程942c）。局所サーバが、対象のBLOBを復号することができない場合、この検証を行うことが可能である。一致が存在しない場合、新たなBLOBジョブが何らかの方法で損なわれており、工程９５０で却下されており、局所アーカイブに記憶されていないとする。

一致が存在する場合、工程９４４で、BLOB-Idが局所サーバの記憶装置２０４内のBLOBのファイル名としてのサブディレクトリ４１２にBLOBが記憶される。工程９４６で、BLOB-Idの要求がゲットBLOBキューから除去される。工程９４８で、図１３に関して以下に説明するように、プッシュBLOBサービスが行われる。この場合、プッシュBLOBサービスは、受信されたBLOBを他のMakyohサーバ（例えば、104-108）に流通させる（プッシュする）役目を担う。よって、プリンタやファックスなどの装置102’がMakyohサーバとして構成される実施例では、文書を別のサーバから得なければならない場合、文書は、ゲットBLOBキューを処理する動作により、他のMakyohサーバに流通させられる。

図１０は、プットBLOBキューを処理するための処理を示す。局所MakyohサーバのプットBLOBキュー上のBLOB-Idは、他のサーバに流通させる対象の、局所サーバ上に記憶されたBLOBを識別する。本発明の特定の実施例では、プットBLOBキューにおける旧くなったBLOB-Idは、図１４のように工程1002で除去される。工程1004a、1004bは、プットBLOBキュー上の各Blob-Idを処理するための外部ループを表す。BLOB-Id毎に、内部ループ1006a、1006bが、REMOTEリスト内のMakyohサーバ毎に処理される。よって、REMOTEリストにおける候補サーバ毎に、工程1001で、候補サーバがBLOB-Idを既に有しているか否かが判定しようとされる。判定を行うことが可能でない場合、工程1008で、HEAD要求を候補サーバに対して行って、BLOB-Idを含むか否かについて尋ねる。工程1001で、候補サーバがBLOB-Idを既に含んでいると判定された場合、REMOTEリスト内の次のサーバが検討される（工程1006a、1006b）。
工程1001で、候補サーバがBLOB-Idを実際に含んでいないと工程1001で判定された場合、工程1010で、PUT要求をそのサーバに対して行って、対応するBLOBをサーバに送出する。処理は次いで、REMOTEリスト内の次の目標サーバに進む（工程1006a、1006b）。全サーバが処理されると、処理は、プットBLOBキューにおける次のBlob-Idに続く（工程1004a、1004b）。

5. フィード・サービス
図11Aは、ゲット・フィード・キューを処理する処理を示す。これは、BLOBのGET要求の処理と同様な考え方である。基本的には、局所Makyohサーバは、フィード-Idのリストを後の処理（フィード-Idに関連付けられたフィード・エントリ・ファイルは、他の（遠隔）Makyohサーバから取り出され、局所Makyohサーバの記憶装置２０４に記憶される）のために作成する。ゲット・フィード・キューは、局所サーバによる１つ又は複数のGET要求によって処理される対象のフィード-Idのリストを含む。本発明の特定の実施例では、ゲット・フィード・キューにおける旧くなったフィード-Idは、図１４のように工程1101で除去される。工程1102a及び1102bは、ゲット・フィード・キュー上の各フィード-Idを処理するための外部ループを表す。フィード-Id毎に、内部ループ1104a、1004bが、REMOTEリスト内のMakyohサーバ毎に処理される。よって、REMOTEリスト内の候補サーバ毎に、候補サーバがフィード-Idを有しているか否かが工程1103で判定されようとする。候補サーバがフィード-Idを含んでいないと判定された場合、REMOTEリストにおける次のサーバが検討される（工程1104a、1004b）。

工程1103で、目標サーバがフィード-Idを含んでいるか、又は判定を行うことが可能でない旨が判定された場合、工程１１０６で、その候補サーバのフィード-Idのディレクトリ・リストを得る旨のPROPFIND要求が候補サーバに対して行われる（図４）。候補サーバのディレクトリ４２４に一覧化されたフィード・エントリ・ファイル４３４（図５の506aも参照されたい）毎に工程1108a乃至1108bが繰り返される。よって、工程1105で、リスト内の候補フィード・エントリ・ファイルが既に局所に記憶されているか否かが判定される。肯定の場合、リストにおける次のフィード・エントリ・ファイルが処理される（工程1108a、1108b）。

局所Makyohサーバがまだ候補フィード・エントリ・ファイルのコピーを有していない場合、工程1110で、GET要求を候補サーバに対して行って、局所サーバの新たなフィード・エントリ・ファイルを得る。新たなフィード・ファイルが工程1114で処理される。これはまもなく説明する。処理は次いで、ゲット・フィード・キューにおける次のフィード-Idに続く（工程1102a、1102b）。

図１１Bは、新たなフィード・エントリの処理を表す。工程1132で、フィード-Idがフィード・エントリから計算される。工程1134で、フィード・エントリにおける検証鍵の指紋が計算される。フィード-Idが指紋に一致するか否かを工程1131で判定し、否定の場合、工程１１４４で、新たなフィード・エントリは、何らかの方法で損なわれているとみなされ、却下される。一致が存在している場合、フィード・エントリに規定されたverify-keyが署名者の公開鍵であることを前提とすれば、フィード・エントリの署名フィールドは、フィード・エントリのコンテンツの残りの有効な署名であるか否かが工程１１３３で判定される。フィード・エントリ上の署名が検証されていない場合、フィード・エントリは却下される。

検証されたフィード・エントリは工程１１３６で局所サーバの記憶装置に記憶される。フィード鍵が、フィード鍵リスト内のフィード-Idに対するものである場合（工程１１３５）、エントリ鍵が、工程１１３８で、フィード鍵ファイルから得られる。工程１１４０で、フィード・エントリの「エントリ」フィールドをエントリ鍵を用いて復号してそのハッシュURIを得る。このハッシュURIは次いで、図８に示すように工程１１４２で「インポートされる」。

図１２は、プット・フィード・エントリ・キューを処理する処理を示す。本発明の特定の実施例では、プット・フィード・キューにおける旧くなったフィード-Idは、図１４のように工程1202で除去される。工程1204a及び1204bは、プット・フィード・エントリ・キュー内のフィード・エントリ毎に行われるループを表す。フィード・エントリ毎に、工程1206a、1206bによって表す内部ループが、REMOTEリスト内の目標サーバ毎に行われる。よって、工程１２０１で、目標サーバが既にフィード・エントリを有しているか否かが判定される。肯定の場合、次のサーバが検討される（工程1206a、1206b）。目標サーバがフィード・エントリを含んでいるか否かが未知の場合、工程１２０８で、そのサーバがその記憶装置にフィード・エントリのコピーを有しているか否かを判定する旨のHEAD要求が行われる。目標サーバがフィード・エントリのコピーを有していない場合、PUT要求を工程１２１０において行って、フィード・エントリのコピーを有している旨を示すようREMOTEリストを更新するとともに、そのサーバにフィード・エントリのコピーを入れる。

図１３を参照すれば、工程１３０１で、他のサービスにBLOBをプッシュする旨の要求が、BLOB-IdをプットBLOBキューに付加することによってキューイングされる。工程１３０２で、BLOB-Idに対応するハッシュURIが局所サーバの鍵リングにあるか否かを判定する。本発明の一実施例では、この判定は、各鍵ファイル３２６をサーチし、包含されたハッシュURIのBLOB-Id部分を、プッシュされているBLOB-Idと比較することによって達成される。別の実施例では、鍵リングが一時データベースに記憶され、これは、そのBLOB-Id構成部分に基づいてハッシュURIの高速ルックアップを可能にする。適切なハッシュURIが工程１３０２で見つからなかった場合、工程１３１２で、プットBLOBキューが図９Aに示す処理によって処理され、処理が完了する。

工程１３０２に戻れば、適切なハッシュURIが見つかった場合、工程１３０３で、BLOBコンテンツが、ハッシュURIに規定された鍵を用いて復号される。BLOBがフィード鍵であるか否かの判定が工程１３０４で行われる。この判定は、BLOBのヘッダにおいて規定されるように、BLOBタイプを検査することによって行われる。

BLOBがフィード鍵タイプの場合、工程１３０５で、そのフィード鍵に対応するフィードのフィード-Idが、フィード鍵のverify-keyの指紋を、例えば、オープンPGP標準に規定された既知の手法を用いて算出することによって得られる。フィード鍵が次いで、工程１３０６で、フィード鍵リスト内の算出されたフィード-Idと関連付けられる。次いで、工程１３０７で、フィード-Idをゲット・フィード・キューに付加することにより、新たなフィード・エントリを他のサーバから取り出す旨の要求がキューイングされる。ゲット・フィード・キューが次いで、図１１Aに示す処理により、工程１３０８で処理される。次いで、工程1309a及び1309bによって表されるループでは、フィード-Idに関連付けられたいくつかの局所に記憶されたフィード・エントリが、フィード-Idに関連付けられたディレクトリ４２４を一覧化することによって判定される。そのように一覧化された局所に記憶されたフィード・エントリの数は、構成パラメータによって決まってくるものであり、前述のエントリの全て又は一部を含んでよく、前述のエントリを何ら含まなくてもよい。そのように一覧化された数が、フィード-Idについて局所に記憶されたエントリの数よりも少ない場合、フィード・エントリのファイル名４３４におけるタイムスタンプに基づいて、最も直近のエントリが一覧化される。工程1309a及び工程1309bにおいて判定されたフィード・エントリは次いで、各フィード・エントリのパスをプット・フィード・エントリに加えることにより、工程１３１０で、他のサーバ104-108にプッシュされるようキューイングされる。一覧化されたエントリ全てが加えられると、プット・フィード・エントリ・キューは、工程１３１１で図１２によって処理される。プッシュBLOBキューは次いで、図１０によって工程１３１２で処理され、処理は終了する。

工程１３０４に戻れば、BLOBがフィード鍵タイプのものでない場合、BLOBのヘッダに規定されているように、BLOBのタイプを検査することにより、BLOBがディレクトリであるか否かを工程１３１３で行う。受信されたBLOBがディレクトリでない（例えば、タイプ「BLOB」の通常コンテンツ・ファイルの場合）、プットBLOBキューが、図１０のように工程１３１２で処理され、処理は終了する。工程１３１３に戻れば、BLOBがタイプ・ディレクトリの場合、ディレクトリBLOBに一覧化された各ハッシュURIにわたってループが行われる（工程1314a及び1314b）。ここでは、各ハッシュURIが、図８により、工程１３１５でインポートされる。ディレクトリの一覧化されたハッシュURIにわたるループが終了すると、プットBLOBキューが次いで、図１０のように工程１３１２で処理され、処理は終了する。

図１４は、種々のキューにおける旧くなったエントリを処理することの効用を表す。よって、ループ1402a、1402bは、キュー（ゲットBLOBキュー、プットBLOBキュー、ゲット・フィード・キュー、及びプット・フィード・エントリ・キュー）毎に繰り返される。キュー毎に、そのキューにおける各要求がループ1404a、1404bにおいて検討される。要求毎に、タイムアウト・パラメータよりも大きな期間の間、上記各要求がそのキュー上にあったか否かが工程１４０１で判定される。各キューは、それ自体のパラメータを有し得るものであり、又は、図に表すように、単一のパラメータを用いることが可能である。要求は、「旧い」場合、そのキューから除外される。

6. ユーザ・ログイン
図１５は、ユーザがログインする場合に行われる工程を表す。実際のログイン手順の形態は、何れかの適切な形態であり得る。ユーザにはログイン画面を提示することが可能である。このログイン画面は通常、ユーザ名及びパスワードの入力を伴う。示唆ログインは、ユーザのMakyohサーバがサーバ・グループに加入する場合に行われ得る。前述のグループに加入するイベントは、ログインを構成する。例えば、加入するサーバが、既存のサーバ・グループの検出範囲内に入るとする。既存サーバ、及び加入するサーバは、例えば、図８に関して説明した、この生起を検出することが可能である。加入するサーバは次いで、図１５に表すログイン処理を起動させることが可能である。示唆ログインは単に、Makyohサーバの起動時に、又は、ログイン・サーバに対して起動されたパスへの第１の要求を行うと行うことも可能である。

ログイン処理は、サーバの物理的な局所ディスクに記憶された暗号化鍵ファイルの局所ディレクトリに対して行われるループを規定する工程1502a、1502bを含む。このディレクトリは、私設の局所構成ディレクトリにある。これは、信頼できるAPIにわたっても遠隔APIにわたっても流通されていない。各ファイルは、ユーザのパスフレーズを用いて暗号化された、鍵リングにおける１つの鍵を含む。図３におけるディレクトリは仮想であり、よって、信頼できる局所ユーザにしか示されない。仮想鍵ファイル３２６は、平文として提示され、他の誰かに渡すことが可能であるように自分の鍵にアクセスするのに簡単なやり方として意図されている。鍵リング・ディレクトリ３１６は、ユーザ・ログイン「後」しか利用可能でなく、よって、ログイン中にルーピングすることが可能でない。

ユーザの鍵ファイル３２６毎に、鍵ファイルが工程１５０４においてユーザのパスフレーズを用いて復号して、そのコンテンツ（すなわち、ハッシュURI）にアクセスする。工程1506で、BLOB-IdがハッシュURIから得られる。工程１５０１で、得られたBLOB-Idに関連付けられたBLOBが局所に記憶されない（すなわち、ユーザのサーバに記憶される）旨が判定された場合、ユーザの鍵リング３１６における次の鍵ファイル３２６が処理される（工程1502a、1502b）。判定は、「BLOBファイル形式」の部分で前述した復号されたBLOBのヘッダ部分における「タイプ」フィールドを用いる。

工程１５０１で、得られたBLOB-Idに関連付けられたBLOBが局所に記憶されている場合、BLOBを工程１５０８で、ハッシュURIから得られた復号鍵を用いて工程１５０８において復号する。工程１５０３で、BLOBがファイルであると平文コンテンツから判定された場合、ユーザの鍵リング３１６における次の鍵ファイル３２６が処理される（工程1502a、1502b）。

工程1503で、BLOBがフィード鍵であることが平文コンテンツから判定された場合、フィード-Idが工程1510で検証-keyの署名から得られる。フィード-Id及びBLOBは次いで、工程1512で、フィード鍵リストに加えられる。処理は次いで、ユーザの鍵リング３１６における次の鍵ファイル３２６に続く（工程1502a、1502b）。

7. 発行
新たなファイル及びディレクトリがMakyohにおいて、スクラッチ・ディレクトリ344aにおいて、標準WebDAV手法（特に、PUT、COPY、DFLETE、MOVE及びRENAME）を用いて作成される。前述のファイル及びディレクトリは、局所でしかアクセス可能でなく、他のMakyohサーバには流通されない。スクラッチ・ディレクトリは、そのコンテンツを他のサーバに利用可能にするために、クエリ・パラメータ「op=createdoc」によってパスが発行される旨のHTTP GET要求を実行することにより、まず、「発行」しなければならない。Makyohサーバは次いで、発行される各ファイル及びディレクトリに関連付けられたBLOBファイルがサブディレクトリ４１２における遠隔サーバに利用可能にされることを確実にし、関連付けられたハッシュURIを局所鍵リングにインポートし、関連付けられたBLOBを既知の遠隔サーバに押し出す。

図１６Aを参照すれば、ファイルが工程１６０１で発行されると、ファイルの長さ、ファイルのタイプ（「BLOB」又は「フィード鍵」）、及び任意のsaltを有するBLOBヘッダがファイルの最初に付加され、結果として生じる最初に付加されたファイルのMD5ハッシュを計算することにより、工程１６０２においてBLOB-keyが判定される。最初に付加されたファイルを次いで工程１６０３で（例えば、既知の高度暗号化標準（AES-128）を用いて）BLOB-keyを対称鍵として用いて暗号化して「BOLB」（BLOBファイル）を生成する。「BLOB-Id」が次いで、工程１６０４で、結果として生じる暗号化BLOBファイルのSHA-1ハッシュを計算することにより、工程１６０４において算出される。次いで工程１６０５で、BLOBを、算出されたBLOB-Idをそのファイル名として用いて、サブディレクトリ４１２に記憶する。「ハッシュURI」が次いで、テキスト「hash:id=」、BLOB-Id、「;aes128-key=」、BLOB-key、「?content-type=」、発行されているファイルのMIMEタイプ、「&name=」、及びファイルのファイル名を連結することにより、工程１６０６で、BLOBに対して生成される。このハッシュURIが次いで、図８に表した処理のように工程１６０７で鍵リングにインポートされる。前述の通り、このサービスにより、新たに付加されたファイルが流通されることになる。

ユーザのラップトップあるいはPDAあるいは同様な装置の場合、ユーザは文書を作成するか、又はさもなければ、新たな文書を受け取る。ユーザは、自分のMakyohアーカイブにそれを付加したい場合、図１６Aに表す処理を引き起こすことが可能である。プリンタ、あるいはファクシミリ、あるいはスキャナなどの文書処理装置102’（図１A）の場合、ユーザ又は別のマシンは、印刷又はファックスされる対象の文書を装置に送出することが可能であるか、又はユーザは、走査する対象のスキャナ上に文書を置くことができる。装置102’が、Makyohサーバとして構成された場合、受け取られた文書は、新たな文書としてみることが可能であり、図１６Aの処理をトリガして、受け取られた文書を装置のMakyohアーカイブに組み込むことが可能であり、受け取られた文書を他のMakyohサーバに流通させることも可能である。

装置102’は、暗号化されていない画像又はファイル・データを受け取ることになる。装置102’は次いで、文書を発行し、暗号化されたBLOBを局所に記憶し、文書を復号する対象の鍵をユーザに（例えば、２Dバーコードの形式で）与える。本発明の実施例では、装置102’は、鍵を局所に記憶しない（又は、実際に鍵リングを全く有しない）。そのようにして、データが完全にセキュアな状態に保たれる。

図１６Bを参照すれば、ディレクトリが発行されると、ブランクのディレクトリ・ファイルが工程１６３０で作成される。次いで、各子（すなわち、各ファイル又はサブディレクトリ）がループ（工程1631a及び1631b）において処理される。ここで、まず、子がディレクトリであるか否かについての第１の判定が工程１６３２において行われる。子がディレクトリでない（すなわち、ファイルである）場合、工程１６３３で、子が、前述の図１６Aに表す方法によって発行される。結果として生じるハッシュURIを次いで、工程1634で、先行して作成されたディレクトリ・ファイルに加える。工程１６３２で、子が、ディレクトリであると判定された場合、再帰的に前述の方法を適用することにより、工程１６３５で子が発行され、その後、結果として生じるハッシュURIが、工程１６３４で、先行して作成されたディレクトリ・ファイルに加えられる。発行されたディレクトリにおけるファイル及びサブディレクトリ全てが処理されると、ループが終了し（工程1631b）、先行して作成されたディレクトリ・ファイルが、前述の方法による、かつ、図１６Aにおける工程１６３６で発行される。

エントリを発行する前にフィードを作成しなければならない。フィード作成は、本発明の一実施例において、クエリ・パラメータが「op=create」のHTTP GET要求を実行すること（これにより、新たなフィードのフィード鍵が生成され、次いで、前述のフィード鍵が発行される）によって達成される。図１６Cを参照すれば、新たな発行フィード鍵５０６が工程１６５１において、書き込み鍵、及び鍵の検証鍵フィールドの非対称鍵対を（例えば、既知のオープンPGP標準を用いて）生成することによって生成され、フィード鍵のエントリ鍵フィールドのランダム対称鍵が生成される。上記ファイルが次いで工程１６５２で、前述されており、図１６Aにおいて表す方法を用いて発行される。作成された発行フィード鍵に対応する加入フィード鍵が次いで、工程１６５３で、verify-keyフィールドを発行フィード鍵から除去することによって計算される。この加入鍵が次いで工程１６５４で発行され、作成処理が終了する。

クエリ・パラメータが「op=publish」である、発行する対象のエントリを含むスクラッチ・ディレクトリ344aに対応するパスのHTTP GET要求を実行することにより、フィードの新たなフィード・エントリが作成され、発行される。Makyohサーバは次いで、サブディレクトリ４１４内の遠隔サーバにエントリ・フィード・エントリ・ファイルが利用可能にされることを確実にし、エントリのコンテンツを構成するファイル及びディレクトリ全てを表すBLOBファイルがサブディレクトリ４１２内の遠隔サーバに利用可能にされることを確実にし、関連付けられたハッシュURIを局所鍵リングにインポートし、エントリ・ファイル及び関連付けられたBLOBを既知の遠隔サーバに押し出す。

図１６Dを参照すれば、まず、発行する対象のフィード-Idに関連付けられた発行フィード鍵をフィード鍵リストに見つけることが可能であるか否かが工程１６７１で判定される。否定の場合、エラーが工程１６７２で報告され、処理が終了する。発行フィード鍵が見つかった場合、エントリのルート（すなわち、エントリの主コンテンツ）がディレクトリであるか否かについての別の判定が工程１６７３で行われる。否定の場合（すなわち、エントリが、単一のファイルのみを有する場合）、エントリのルート・ファイルが工程１６７４で発行される。フィード・エントリ・ファイルが次いで工程１６７５で、フィード・エントリのコンテンツに署名するために発行フィード鍵によって規定されるwrite-keyを用いて、新たに発行されたエントリ・ルートのハッシュURIを暗号化するために発行フィード鍵に規定されたエントリ鍵を用いて作成される。フィード・エントリ・ファイルが次いで工程１６７６でフィードのサブディレクトリ４２４に記憶される。フィード・エントリをプッシュする旨の要求がプット・フィード・エントリ・キューに工程１６７７で追加され、そのキューが工程１６７８で図１２のように処理され（これは、受信されたフィード・エントリを他のMakyohサーバに流通させる役目を担う）、処理は終了する。

工程１６７３に戻れば、エントリ・ルートがディレクトリの場合、図１６Bの上記方法を用いて、工程１６７９で、ディレクトリが発行される。処理が次いで、上記の通り、工程1675-1678に進む。

VII. ロバスト性及びセキュリティ
Makyohは、その多くについて既に言及している多くの種類の攻撃に対して保護するよう企図されている。要約すれば、Makyohは以下の脅威に対して保護する。

1. ディスク媒体の紛失又は盗難：データは全てディスク上に暗号化されているので、アーカイブを含むハード・ドライブ又はUSBサムドライブの紛失又は盗難により、情報は何ら明らかにされない。

2. ネットワーク・スニッフィング： Makyohサーバ間の通信は全て暗号化されているので、文書コンテンツは、ネットワーク上でリスニングしている何者かに明らかにされない。

3. 中間者攻撃： BLOBに対する攻撃は、BLOBの復号鍵を明らかにしないので、要求にリッスンし、次いで、後に別のサーバに向けて再生することにより、組へのアクセスを得ること（すなわち、「中間者攻撃」）は可能でない。

4. 認可されていない発行：攻撃者は、適切な公開鍵なしでフィードに発行することが可能でない。攻撃者が、有効なフィード・エントリから署名ブロックをコピーし、自分自身のものに添付した場合、署名は一致しない。攻撃者が代わりにエントリの検証鍵を自分自身の鍵に変更した場合、エントリのフィード-Idは、検証鍵の指紋に一致しなくなる。いずれの場合も、フィード・エントリを受信したMakyohサーバは、攻撃者がフィードの加入鍵を知っており、受信するサーバが知らなかった場合でも、ファイルを却下する。

5. 置換： BLOB及びファイル・エントリのファイル名はファイル・コンテンツのファイルを含んでいるので、攻撃者も、既存のものの代わりに完全に新たなBLOB又はフィード・エントリを置換することが可能でない。受信サーバは、攻撃者が、適切な復号鍵を知っており、受信サーバが知っていなくても、そのファイル名内のIDに一致しないとしてBLOB又はフィード・エントリを却下する。

本発明の実施例による個人アーカイブ・サーバのシステムを示す図である。本発明の個人アーカイブ・サーバの別の実施例を表す図である。本発明の実施例による個人アーカイブ・サーバのブロック図である。本発明の実施例によるアーカイブのアーカイブ・ビューを表す図である。本発明の実施例によるアーカイブのアーカイブ・ビューを表す図である。本発明によるアーカイブの記憶ビューを表す図である。本発明によるフィード・アーキテクチャを示す図である。文書のアクセスの全体フローを示す図である。フィード・エントリのアクセスの全体フローを示す図である。新たなサーバの加入の処理の全体フローを示す図である。新たなサーバの除外の処理の全体フローを示す図である。ハッシュURIのインポートの全体フローを示す図である。ゲットBLOBキューの処理の全体フローを示す図である。新たに受け取られたBLOBの処理の全体フローを示す図である。プットBLOBキューの処理の全体フローを示す図である。ゲット・フィード・キューの処理の全体フローを示す図である。新たなフィード・エントリの処理の全体フローを示す図である。プット・フィード・エントリ・キューの処理の全体フローを示す図である。プッシュBLOBサービスの全体フローを示す図である。旧くなったキュー・エントリの処理の全体フローを示す図である。ユーザ・ログインの処理フローを示す図である。アーカイブにファイルを付加する処理を示す図である。アーカイブにディレクトリを付加する処理を示す図である。フィードの作成の処理を示す図である。フィード・エントリの発行の処理を示す図である。

符号の説明

101 文書ソース
102 文書処理装置
204 記憶装置

Claims

複数の第２の装置の間で文書を流通させる、局所データ記憶装置を含む第１の装置における方法であって、
文書オブジェクトに暗号化形式で記憶されるコンテンツを含む第１の文書を識別する文書取り出し要求を前記第１の装置のユーザから受け取る工程と、
前記文書オブジェクトが前記局所データ記憶装置に記憶されている場合、当該文書オブジェクトのコピーを有しない各第２の装置に前記文書オブジェクトを送出する工程と、
前記文書オブジェクトが前記局所データ記憶装置に記憶されていない場合、前記文書オブジェクトを前記第２の装置のうちの１つから取り出す工程とを備え、
前記取り出す工程は、
前記第２の装置のうちの１つから前記文書オブジェクトのコピーを取り出す旨の取り出し要求を前記第２の装置に送出する工程と、
取り出された前記文書オブジェクトのコピーを前記局所データ記憶装置上に記憶する工程とを備える方法。
取り出された前記文書オブジェクトのコピーを記憶する工程はさらに、そこに前記文書オブジェクトのコピーを記憶させていない各第２の装置に、取り出された前記文書オブジェクトのコピーのコピーを送出する工程を更に備える請求項１記載の方法。
前記第１の装置、及び第１の複数の前記第２の装置は、近傍のメンバを構成し、取り出し要求を送出する工程、及び前記文書オブジェクトを送出する工程は、前記近傍のメンバについてのみ行われ、
前記近傍のメンバに加入していない第２の装置が前記近傍のメンバに加入すると、取り出し要求を送出する工程、及び前記文書オブジェクトを送出する工程も前記加入する第２の装置について行われ、
前記近傍のメンバであった第２の装置が前記近傍を離脱すると、取り出し要求を送出する工程、及び前記文書オブジェクトを送出する工程はもう、前記離脱する第２の装置について行わない請求項１記載の方法。
取り出された前記文書オブジェクトのコピーを前記局所データ記憶装置上に記憶する工程は、
取り出された前記文書オブジェクトのコピーのコンテンツに基づいて導出データを計算する工程と、
前記導出データを、前記文書取り出し要求に含まれる文書情報と比較する工程と、
前記比較の結果に応じて、取り出された前記文書オブジェクトのコピーを前記局所データ記憶装置上に記憶する工程とを備える請求項１記載の方法。
文書鍵を前記局所データ記憶装置から得る工程を更に備え、前記文書鍵は、前記文書オブジェクトを復号するための復号鍵を含む請求項１記載の方法。
第１の装置から複数の第２の装置に文書を流通させる方法であって、
第１の文書鍵を受け取る工程であって、前記第１の文書鍵を備えるデータが第1の文書オブジェクトを識別する工程と、
前記第１の文書オブジェクトが前記第１の装置の局所記憶装置上に記憶されている場合、当該前記第１の文書オブジェクトのコピーを有しない各第２の装置に前記第１の文書オブジェクトを送出する工程と、
前記第１の文書オブジェクトが前記局所記憶装置上に記憶されていない場合、前記第１の文書オブジェクトを前記第２の装置のうちの１つから取得し、前記取得された第１の文書オブジェクトを前記局所記憶装置上に記憶する工程とを備える方法。
前記取得された前記第１の文書オブジェクトを記憶する工程はさらに、そこに前記第１の文書オブジェクトのコピーを記憶させていない各第２の装置に前記取得された第１の文書オブジェクトのコピーを送出する工程を更に備える請求項６記載の方法。
前記取得する工程は、
前記第１の文書鍵を備えるデータに基づいて第１の導出デ―タを生成する工程と、
取り出し要求を前記第２の装置に送出する工程であって、前記取り出し要求が前記第１の導出データを含み、前記第１の導出データは、前記文書オブジェクトを識別する役目を担う工程と、
前記第２の装置のうちの１つから前記第１の文書オブジェクトのコピーを受け取る工程とを備える請求項６記載の方法。
前記取り出し要求が、一度に１つの第２の装置に送出される請求項８記載の方法。
請求項６記載の方法はさらに、前記第１の文書オブジェクトの平文コンテンツを生成するために復号鍵として前記文書鍵を備えた、前記データの一部を用いて前記第１の文書を復号する工程を備える方法。
複数の第２の装置の間で文書を流通させる、局所データ記憶装置を含む第１の装置における方法であって、
第１の文書にアクセスする旨の文書取り出し要求を前記第１の装置のユーザから受け取る工程であって、前記第１の文書は、複数の第１の文書オブジェクトと関連付けられる工程と、
前記局所データ記憶装置に記憶された各第１の文書オブジェクトについて、
前記各第１の文書オブジェクトのコピーをそこに記憶させていない各第２の装置に前記各第１の文書オブジェクトを送出する工程と、
前記局所データ記憶装置に記憶されていない各第１の文書オブジェクトについて、前記各第１の文書オブジェクトを前記第２の装置のうちの１つから取り出す工程とを備え、前記各第１の文書オブジェクトを前記第２の装置のうちの１つから取り出す工程は、
前記第２の装置のうちの１つから前記各第１の文書オブジェクトのコピーを取り出す旨の取り出し要求を前記第２の装置に送出する工程と、
取り出された前記各第１の文書オブジェクトのコピーを前記局所データ記憶装置上に記憶する工程とを含む方法。
取り出された前記各第１の文書オブジェクトのコピーを記憶する工程に後続して、そこに前記各第１の文書オブジェクトのコピーを記憶させていない各第２の装置に前記取り出された前記各第１の文書オブジェクトのコピーのコピーを送出する工程を更に備える請求項１１記載の方法。
第１の装置から複数の第２の装置に文書を流通させる方法であって、
第１の文書鍵を受け取る工程であって、前記第１の文書鍵を備えるデータは第１のオブジェクトを識別し、前記第１のオブジェクトは、複数の第１の文書オブジェクトをそれに関連付けており、
各第１の文書オブジェクトについて、
前記各第１の文書オブジェクトが前記第１の装置の局所記憶装置上に記憶されている場合、そこに前記各第１の文書オブジェクトのコピーを記憶させていない各第２の装置に前記各第１の文書オブジェクトを送出する工程と、
前記各第１の文書オブジェクトが前記局所記憶装置上に記憶されていない場合、
前記各第１の文書オブジェクトを前記第２の装置のうちの１つから得る工程と、
前記得られた第１の文書オブジェクトを前記局所記憶装置上に記憶する工程とを備える方法。
請求項１３記載の方法はさらに、前記各第１の文書オブジェクトのコピーをそこに記憶させていない各第２の装置に前記得られた第１の文書オブジェクトを送出する工程を備える方法。