JP2007531071A - 協働的ファイル更新システム - Google Patents

Abstract

開示された方法では、ファイルの協働的な更新を容易にし、データは、複数のユーザーの一人から受け入れて保存する。このデータは、ファイルの初期バージョンを表わし、初期バージョンの一人以上の受信者を指定する。そして、ファイルの順次的な更新バージョンの各々に対して、ファイルの更新されたバージョンとファイルの直前のバージョンとの間の差分を表わすデータは、ユーザーから受け入れられる。このデータは、また、行使されたバージョンの一人以上の受信者を指定する。ファイルの更新されたバージョンのデータ値は、更新したバージョンの指定した受信者に伝送される。各受信者に対して伝送されたデータは、更新されたバージョンの受信者として指定され、直前のバージョンをアクセスした受信者へ伝送されたデータは、実質的に、ファイルの更新されたバージョンと前のバージョンとの間の差分からなる。他の方法及びシステムが開示されている。
【選択図】図９

Description

本発明は、複数のユーザによるファイルへのアクセス方法に関する。

ワークグループによる共同作業の基盤として、同僚間で電子的にメッセージを交換し、電子ファイルを共同で使用することが益々増大している。遠隔地からの参加者をワークグループへ接続するインターネットの使用の増加に伴って、ワークグループ内の作業者が、共有ファイルの保存およびアクセスを安全かつ簡便に実行できる共通ポイントに到達できない事態がしばしば生じる。このようなアクセスが可能な場合であっても（例えば、ローカル・エリア・ネットワーク内でのアクセス、あるいは、インターネットに基づくＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ：バーチャル・プライベート・ネットワーク）を介したアクセスの場合）、ワークグループへの参加者が、電子メールの慣れ親しんだ便利なインタフェースを使用することから脱することができないために、結局、電子メールの添付ファイルとしてファイルを授受する結果となることも多い。

電子ファイルに対して協働的にアクセスするために、電子メールの添付ファイルを用いることは、多くの点で非効率的である。添付ファイルとしてファイルを送信することによって、大量のネットワーク資源が消費される。この問題を悪化させる要因は、電子メールシステムで従来使用されているＢａｓｅ−６４符号化方式の非効率性である。大きなファイルが添付された電子メールメッセージの受信者は、特に比較的低速である電話回線を介して接続している場合、電子メールをチェックする際の長いダウンロード時間に悩まされることになる。多くのユーザは、ファイルを電子メールの受信箱に「詰め込む」ことよりも、所望の時と場合に応じて共有ファイルにアクセスする方を好むものである。

ワークグループによる共同作業では、単純な添付ファイルによるファイル共有に対して、共有ファイルのアクセス管理とバージョン管理が、さらに重要な問題を提起する。ファイルの起案者（originator）または作成者は、特定のバージョンのファイルを電子メールの添付ファイルとして同僚に送信した後、このバージョンのファイルに対して同僚によってなされる編集に関する制御を失うことになる。ファイルの起案者が「公式」なバージョンのファイルにこの編集を組み込むためには、別の電子メールの添付ファイルとして返送された編集版のファイルを使用して、元のファイルを上書きする必要がある。また、複数の同僚によってなされた編集を組み込むためには、それらの編集を手作業によって統合する必要がある。

サービニス（Serbinis）等による国際特許出願（特許文献１）には、ファイルの起案者が文書管理システムの保存場所にファイルをアップロードすると共に、この文書へのアクセスが認証されたユーザのリストを作成する文書管理システムが開示されている。

国際公開第００／６０５０３号パンフレット

しかしながら、文書管理システムと電子メールシステムをシームレスに統合してその利便性を促進し、ユーザが、添付ファイルによるファイル送信という、慣れ親しんではいるものの非効率なシステムに後退しないようにすることに対する要望は、依然として存在している。より良い電子メール／文書管理統合システムは、共有ファイルへのネットワークアクセスの利点を維持しながら、添付ファイルとしてファイルを送信する際の慣れ親しんだインタフェースと利便性とを提供するものであろう。

本発明の種々の構成に従う方法において、ファイルの協働的な更新を容易にするために、データが、複数のユーザーの一人から受け入れられて保存される。このデータは、ファイルの初期バージョンを表わし、序機バージョンの一人以上の受信者を指定する。

そして、ファイルの順次的に更新された複数のバージョンの各々に対して、複数のユーザーの一人から受け入れられる。このデータは、ファイルの更新されたバージョンとファイルの序九膳のバージョンの間の差分を表わす。また、このデータは、ファイルの非塵以上の受信者を指定する。ファイルの更新されたバージョンを表わすデータは、更新されたバージョンの指定された受信者に伝送される。

本発明の特定の構成によれば、全てのユーザーにアクセス可能なサーバーが、データを受け入れる。有利なことに、これらのユーザーは、ファイルのバージョンに際するリファレンスを交換することができ、指定された受信者によって作動されたとき、サーバーが元のまたは更新されたファイルのバージョンを表わすデータを伝送させる。この結果、ユーザー間に直接ファイルを伝送することを避ける。

更新されたバージョンの受信者として指定された各受信者に伝送され、かつ直前のバージョンにアクセスされたデータは、実質的に、ファイルの更新されたバージョンと前のバージョンとの間の差分からなる。その結果、更新されたファイルのバージョンを得ることができるユーザーは、単に、直前のバージョンをデータファイルとパッチングさせることによって、そのデータファイルのみを受け入れる。更新された全体のファイルは、この場合伝送する必要がない。

本発明の別の特定の構成によれば、直前のバージョンではなくて、更新されたバージョンの受信者として指定されたユーザーは、以前のバージョンからのデータよりも更新されたファイル自体のデータを受け入れる。このファイルは、伝送する前に更新され、そして、伝送した後、更新のために複数のデータを伝送する複雑化を回避する。

上記要約は、本発明の全ての構成を網羅したリストを含まない。実際、この発明者は、本発明は、上述した種々の構成の全ての組み合せから実行することができる全てのシステム及び方法を含むと考えており、更に、以下で詳細に説明する構成および本出願に添付された特許請求の範囲に記載した構成を含む。このような組み合せは、上記要約に開示されていない特定の利点を有するものである。

本発明の様々な態様に従う電子メール・ファイルアクセスシステムは、多くの利点を有しており、それらの利点には、典型的な電子メールソフトウェアで使用される一般的なユーザインタフェースに対して新規な拡張を使用することから生じる、アクセス管理の簡便性が含まれる。このシステムは、相互作用可能なハードウェア部品またはソフトウェアコンポーネントからなる任意の適切なグループを含んでおり、それによって、電子的なメッセージ交換を介するファイルのアクセスを容易にするものである。例えば、図１に示すシステム１００は、従来のネットワーク接続１４、１７、４７を介して好適にネットワーク化された第１のコンピュータ１１０、第２のコンピュータ１４０、および、第３の「アクセスサーバ」コンピュータ１７０を含んでいる。

図１は、コンピュータ１１０、１４０、１７０を方形の破線として模式的に示し、システム１００においてこれらのコンピュータが実装する機能モジュールを、各コンピュータを表す破線内に模式的に示した図である。これらの機能モジュールは、ハードウェア、ソフトウェア、または、それらの両方によって、好適に実装することができる。各機能モジュールは、相互接続の任意の適切な経路を介して相互作用することができる。これらの相互接続には、ハードウェア（例えば、バス、専用信号線等）、共有記憶媒体（例えば、ＲＡＭ媒体中の関数呼び出しの引数および戻り値、デュアルアクセスＲＡＭ、ハードディスク媒体上に存在するファイル等）へのアクセス、および、ハードウェアと共有記憶媒体へのアクセスとの組合せが含まれる。

コンピュータ１１０は、Ｉ／Ｏ（入出力）モジュール１１２、ストレージ１１４、および、プラグイン１１８によって変更された電子メールクライアント・アプリケーション１１６を含む機能モジュールを実装している。制御モジュール１２０は、これらのモジュールおよびコンピュータ１１０が実装する他の任意のモジュールの動作を管理するものである。ハードウェアおよびソフトウェア相互接続モジュール１２２は、コンピュータ１１０の様々なモジュール間の相互接続を表している。

コンピュータ１４０は、Ｉ／Ｏモジュール１４２、ストレージ１４４、電子メールクライアント・アプリケーション１４６、および、ダイレクトファイルアクセス・モジュール１４８を含む機能モジュールを実装している。制御モジュール１５０は、これらのモジュールおよびコンピュータ１４０が実装する他の任意のモジュールの動作を管理するものである。コンピュータ１４０の様々なモジュール間の相互接続は、ハードウェアおよびソフトウェア相互接続モジュール１５２によって表されている。

アクセスサーバ１７０は、ストレージモジュール１７４中のファイルへのネットワークアクセスを提供する機能モジュールを実装しており、ストレージ１７４に加えて、ネットワーク転送インタフェースモジュール１７２および制御モジュール１７６を含んでいる。相互接続モジュール１７８は、コンピュータ１７０の様々なモジュール間のハードウェアおよびソフトウェア接続を表すものである。

本発明の様々な態様に従うＩ／Ｏモジュールは、ユーザからの入力を受信すると共にユーザへの出力を伝達する任意のハードウェアまたはソフトウェアを含んでいる。システム１００において、コンピュータ１１０のユーザはファイル管理者１０２であり、コンピュータ１４０のユーザはファイル使用者１９８である。コンピュータ１１０のＩ／Ｏモジュール１１２は、コンピュータ１１０の動作を指令するファイル管理者１０２からの通常のユーザ入力（例えば、マウスおよびキーボードからの入力、音声読取り、およびコマンド入力）を受信する。また、Ｉ／Ｏモジュール１１２は、図１には図示を省略する通常の出力デバイス（例えば、ＬＣＤまたはＣＲＴモニター、スピーカー）を介して、ファイル管理者１０２にコンピュータ１１０からの出力を伝達する。同様に、コンピュータ１４０のＩ／Ｏモジュール１４２は、ファイル使用者１９８からの入力を受信し、出力を伝達する。ここで、コンピュータのユーザは、コンピュータに向かう人として図示されているが、本発明において、コンピュータのユーザは、このコンピュータの場所に常時存在していなくてもよく、または、リモートリンクを通じてのみ「存在している」人であってもよい。また、人間のユーザを、人工知能システムまたはロボットに置き換えることもできる。

コンピュータ１１０、１４０およびアクセスサーバ１７０のストレージモジュール１１４、１４４、１７４の例には、通常、ハードディスクストレージ、ＲＡＭ、ブートＲＯＭが含まれる。本発明の様々な態様に従うストレージ機能モジュールには、モジュール１１４、１４４で使用されるハードウエアおよびソフトウェアに加えて、適切にデータを保存する任意のハードウェアおよび関連するソフトウェアを含めることができる。これらのストレージは、揮発性または不揮発性の媒体への、一時的または永久的なものとすることができる。

コンピュータ１１０、１４０およびアクセスサーバ１７０の制御モジュール１２０、１５０、１７６は、通常、１つまたは複数の中央処理装置（ＣＰＵ：Central Processing Unit）集積回路が含まれており、ＣＰＵは、マイクロコード、ブートソフトウェア（例えば、ＢＩＯＳチップ中）、および、例えばＬｉｎｕｘ、ＢｅＯＳ、Ｍａｃ ＯＳ（登録商標）、ＷＩＮＤＯＷＳ（登録商標）等の適切なオペレーティングシステムを備えている。（本発明の様々な態様に従う制御モジュールは、ここれ例示したハードウェアおよびソフトウェア、または、コンピュータの動作を制御する他の任意のハードウエアおよびソフトウェアを含んでいてもよい。）オペレーティングシステムは、ＣＰＵを制御下に置いた後、そのＣＰＵのコンピュータ中の他のコンポーネントの相互作用を管理する。例えば、制御モジュール１２０は、Ｉ／Ｏモジュール１１２、ストレージモジュール１１４中のハードディスクおよびメモリ、および、電子メールクライアント・モジュール１１６並びにプラグイン１１８を実装するためのアプリケーション関数呼び出しの間のデータ交換を管理する。これらのデータ交換は、ハードウェアおよびソフトウェア相互接続モジュール１２２によって表されている。

本発明の様々な態様に従う電子メールクライアント・モジュール１４６は、ユーザがネットワークを介して他のユーザと電子メッセージを交換可能な任意の適切なハードウェアおよびソフトウェアによって実装される任意の機能モジュールを含んでいる。プラグインモジュール１１８によって、本発明の様々な態様を実装する目的のために適切に変更された場合、例示した電子メールクライアント・モジュール１１６を、従来の電子メールクライアント・アプリケーションとすることができ、それによって、システム１００における（後述する）機能を果すものである。適切な電子メールクライアント・アプリケーションには、ロータス社／アイビーエム社（Ｌｏｔｕｓ／ＩＢＭ）のＮＯＴＥＳ（登録商標）、クォルコム社（Ｑｕａｌｃｏｍｍ）のＥＵＤＯＲＡ（登録商標）、ネットスケープ社（Ｎｅｔｓｃａｐｅ）のＭＥＳＳＥＮＧＥＲ、およびマイクロソフト社（Ｍｉｃｒｏｓｏｆｔ）のＯＵＴＬＯＯＫ（登録商標）が含まれる。あるいは、このような機能をアプリケーション・モジュール１１６に統合化することもでき、その場合、プラグインモジュール１１８は省略してもよい。

コンピュータ１４０の電子メールクライアント・モジュール１４６は、システム１００における機能を果すために、専用にプログラムされている必要はなく、プラグインモジュールによって変更する必要もない。例示したコンピュータ１４０には、そのような機能を果すために、（好ましくは、電子メールへの添付ファイルの添付時に起動される）ダイレクトファイルアクセス・モジュール１４８が含まれている。ダイレクトファイルアクセス・モジュールの利点を必要としない例では、ファイル使用者は、単に従来の電子メールクライアントを使用することができる。この例では、電子メールメッセージに埋め込まれたハイパーリンクを選択することによって、ダイレクトファイルアクセス・モジュールを要することなく、ダイレクトファイルアクセスを開始することができる。他の例では、ファイル使用者は、専用にプログラムされた電子メールクライアント、または、プラグインによって変更された電子メールクライアントを使用することができる。このように、本発明の様々な態様に従うシステムは、複数のファイル使用者のすべての電子メールソフトウェアを改造することなく、動作するものである。

少なくとも電子メールクライアントとしてＥＵＤＯＲＡ（登録商標）を使用する場合には、単一のダイナミックリンクライブラリ（ＤＬＬ：dynamic-linked library）に常駐するプログラムによって、プラグインモジュール１１８を実装することができる。インストールプログラムは、そのＤＬＬファイルを、ストレージモジュール１１４のハードディスク上の「ｐｌｕｇｉｎｓ」フォルダ（例えば、Ｃ：￥Ｐｒｏｇｒａｍ Ｆｉｌｅｓ￥Ｅｕｄｏｒａ￥ｐｌｕｇｉｎｓ）に保存する。他の電子メールクライアントでは、プラグインは、それぞれの方法で実装される。

システム１００においてメッセージおよびファイルを送信するための例示的な方法２００は、図２に示すデータフローチャートを参照することで、より理解し易くなるであろう。この例は、本発明の様々な態様を、例示的な構成であるシステム１００で使用したときの利点を説明するためのものである。ただし、本発明の特定の態様には、他の様々な態様が省略されていている場合にも、その利点を発揮するものも存在する。したがって、この例または本明細書に記載された他のすべての例は、本発明の範囲を限定するものではない。本発明は、添付請求項のみによって限定される。

方法２００の処理２００において、ファイル管理者（図２への図示は省略する）は、ファイルアクセスを許可するメッセージを準備する。これを実施するために、ファイル管理者１０２は、Ｉ／Ｏモジュール１１２（図１参照）を通じて送受信される入力および出力を介して、コンピュータ１１０と対話する。ファイル管理者は、ファイル使用者からのアクセスを許可したいファイル２２２（図１に示すストレージ１１４のハードディスクまたは他の媒体上に存在する）を指定する。ファイル管理者は、通常、アクセスを許可するファイルの作成者であるが、これに限定されるわけではない。

ファイル管理者は、ファイル使用者の電子メールメッセージのアドレス２２６を指定する。プラグインモジュール１１８による機能変更によって、モジュール１１６（図１参照）は、さらに、ファイル使用者１９８が、ファイルの閲覧が認証された閲覧者またはファイルの修正が認証された編集者のいずれであるかについての指示データを記録する。（勿論、ファイルの修正を認証することは、同時に、ファイルの閲覧を認証することを意味する。）

通常の電子メールシステムでは、電子メッセージのアドレスには、後尾に「＠」記号の付いたユーザＩＤ、続いて、そのユーザのネットワークドメイン名が含まれる。例えば、「ｔｏｍ＿ｅｄｉｓｏｎ＠ｌｉｇｈｔｕｌｂｓ．ｃｏｍ」というアドレスには、ユーザＩＤ「ｔｏｍ＿ｅｄｉｓｏｎ」と、ドメイン名「ｌｉｇｈｔｕｌｂｓ．ｃｏｍ」が含まれている。下部構造に互換性がある場合には、他の種類の電子メッセージを使用することもできる。

次いで、方法２００の処理２３０では、ファイル使用者の認証ステータスが判別される。処理２３０は、図１に示すコンピュータ１１０、アクセスサーバ・コンピュータ１７０、および、場合によってはコンピュータ１４０で実行されるものであり、認証データ２２８に基づいてこの判別を実施する。認証データ２２８は、自動的に決定されるものであってもよく、あるいは、ファイル管理者が手作業で決定するものであってもよい。手作業により認証データを決定する場合のシステムおよび方法の例は、図４および図５を参照して、後述する。

特定のファイル使用者に対する認証データは、そのファイル使用者に関連付けられた電子メッセージのアドレスに基づき、任意の適切な方法を使用して、自動的に決定することができる。図１に示すシステム１００では、例えば、コンピュータ１１０の認証データベースモジュール（図示は省略するが、ストレージ１１４に置くことができる）に、認証された使用者とそれぞれの使用者の認証ステータスのデータベースが保持されるものであってもよい。認証データベースモジュールは、ファイル使用者１９８のアドレスを検索し、一致するアドレスを発見したならば、認証データ２２８（図２参照）を更新して、ファイル使用者１９８を、ダイレクトアクセスが認証された閲覧者または編集者、あるいは、ダイレクトアクセスが認証されていない使用者として指定する。

上記認証データの決定方法に加えて、あるいは、その代りに、システム１００は、ファイル使用者１９８のユーザＩＤまたはドメイン名に基づいて、認証データを自動的に決定することもできる。例えば、ファイル管理者１０２のアドレスと同じ会社名のドメイン名を持つすべてのアドレスを、ダイレクトファイルアクセスを認証するデータに関連付けるものであってもよい。別の例として、セキュリティーの観点から、よく知られているフリーメールサービスのドメイン名を持つすべてのアドレスを、ダイレクトファイルアクセスの認証を阻止するデータに関連付けることもできる。認証の自動決定と手動決定を併用する例では、このような阻止処置に対して、あらゆるユーザ認証を覆す高い優先度を割り当てることができる。

次いで、例示した方法２００（図２参照）は、処理２３０で判別された認証ステータスに応じて、処理２５０、または、処理２４２、２４４、２４６のいずれかに進む。ファイル使用者のアドレス２２６に対してファイル２２２へのダイレクトアクセスが認証されていなかった場合、処理２５０において、通常、メッセージ２２４の添付ファイルとしてファイル２２２のコピーが送信される。一方、アドレス２２６に対してダイレクトファイルアクセスが認証されていた場合には、処理２４２でファイル２２２へのファイル参照が作成される。次いで、処理２４４で、ファイル参照が添付されるかまたは組み込まれたメッセージ２２２が、ファイル使用者に送信される。次いで、処理２４６で、ファイル２２２のデータが、ネットワーク接続１７（図１参照）を介してアクセスサーバ１７０に送信される。

システム１００（図１参照）の一例では、ダイレクトファイルアクセスが要求された場合に、添付ファイルの代りにファイル参照を送信することができる。コンピュータ１１０のこのような動作は、完全に未変更の電子メールクライアント・モジュール、または、閲覧者フィールドおよび編集者フィールドを含むようにのみ変更された電子メールクライアント・モジュールを使用している場合でも、実施することができる。この例では、コンピュータ１１０に対して、電子メールメッセージへにファイルを添付するためのＡＰＩ呼び出しを検出するモジュール（図示省略）を追加的に実装することができる。ダイレクトファイルアクセスが要求された場合、このようなモジュールによって、所望のファイルを参照する実行可能コードのファイルを添付するように、電子メールクライアント・モジュールを欺くことができる。あるいは、コンピュータ１１０にファイアーウォール型のモジュール（図示省略）を実装し、ネットワーク接続１４を介した送信の直前に、メッセージ中に添付ファイルが存在することを検出するものであってもよい。このファイアーウォール型のモジュールによって、添付ファイルをファイル参照に置換すると共に、それまで添付されていたファイルを、ネットワーク接続１７を介してアクセスサーバ１７０に送信することができる。

図１および図２に示すシステム１００および方法２００において、アクセスサーバ１７０は、ネットワークファイル転送インタフェース１７２を通じてファイル２２２のデータを受信し、そのデータをストレージ１７４に保存する。ファイル使用者１９８は、認証のレベルに従って、ファイル２２２を閲覧または編集するために、ストレージ１７４からファイル２２２を取得することができる。本発明の様々な態様に従うアクセスサーバの利点を必要としない例では、アクセスサーバ１７０を省略することができる。

本発明の様々な態様に従うファイル参照は、ファイルのロケーションを識別する任意の指示データを含んでいる。ファイル参照は、ハイパーリンクであってもよい。この場合、ファイル参照には、人間が解読できる指示データ（例えば、ファイル名）と、その指示データに関連するコンピュータが解読できる指示データ（例えば、そのファイルの取得先のネットワークアドレス）の両方が含まれる。一変形例では、ファイル参照は、ネットワークアドレスを識別するテキストのみからなるものであってもよく、この場合、ファイル使用者は、そのネットワークアドレスを適切なフィールド（例えば、Ｗｅｂブラウザのアドレスフィールド）に入力することによって、ファイルを取得することができる。

特に有利な例では、電子メールメッセージの添付ファイルに、ダイレクトファイルアクセス・モジュール（例えば、システム１００のモジュール１４８）を実装するプログラムを含めることで、ファイル参照を構成することができる。本発明の様々な態様に従うダイレクトファイルアクセス・モジュールは、ファイルへの直接的なアクセスを容易にするための任意の適切なハードウェアおよびソフトウェアによって実装される任意の機能モジュールを含んでいる。ダイレクトファイルアクセス・モジュールを実装するプログラムをファイル使用者に送信することによって、そのファイル使用者の電子メールクライアントがダイレクトファイルアクセス機能を有する必要性がなくなるため、有利なものである。ベンカトラマン（Ｖｅｎｋａｔｒａｍａｎ）等に付与された米国特許第６，０１４，６０８号明細書には、この例の実施に役立つ事項が開示されている。

ファイル参照には、参照されるファイルに関連付けられた一意的と見なし得る識別コードを表すデータ、および、他のコードを表すデータを含めることができる。本発明の様々な態様に従う一意的と見なし得る識別コードは、任意の適切な方法によって生成された任意の種類の数列であって、（１）特定の文書、文書の版数、サーバ、ユーザ、または、他の識別可能な実体（entity）に関連付けられていると共に、（２）所望の統計的確実性の範囲で、任意の他のこのような実体に関連する可能性が小さいものである。

例えば、ファイル参照には、（１）参照されるファイルが存在するアクセスサーバ、（２）参照されるファイル、（３）送信ユーザ、および、（４）ファイルの現在の版数のそれぞれに関連付けられた４つの一意的と見なし得る識別コードを含めることができる。有利なことに、このようなファイル参照の受信者は、複数のサーバに対してポーリングを実施することも、あるいは、複数のサーバのうちのいずれのサーバがファイルを保存しているのかを推定することもなく、マルチサーバ・システム中の特定の指定されたアクセスサーバから、そのファイルにアクセスすることができる。マルチコードファイル参照のこの利点および他の利点を必要としない例では、１つのコードを使用してファイルを識別することができる。

複数のアクセスサーバを使用することは、特に次のような点で有利である。例えば、ユーザが地理的にクラスタ化されている場合、互いに遠距離に存在するそれぞれのクラスタに属するユーザに対して、そのクラスタに近いアクセスサーバを割り当てることができる。各ユーザは、割り当てられたアクセスサーバに対してのみファイルを送信することが許可される。受信者は、上述したように、ファイル参照と共にそのアクセスサーバの識別コードを受信するか、または、ユーザとユーザに許可された「書き込み用」サーバの登録リストから該当する送信ユーザを検索することによって、複数のサーバのうちのいずれのサーバがファイルを保存しているのかを推定することができる。ランダムに選択されるかまたは所定の選択スキームに従って選択される複数のアクセスサーバを１箇所で使用して、複数のコンピュータ間で負荷を分散することもできる。

特定レベルの認証ユーザのみがその権限を行使できるようことを保障して、セキュリティーを強化するために、ファイル参照は、暗号化されるか、または、一方向暗号化関数に代入されることが好ましい。指定されたファイル使用者の公開鍵、または、ファイル使用者とファイル管理者だけが知っている共有秘密鍵に従ってファイル参照を暗号化することによって、指定されたファイル使用者以外のユーザがそのファイル参照を使用することを、防止することができる。また、ファイル参照を一方向暗号化関数に代入することによって、侵入者がファイル参照に基づいてファイル名を識別することを、防止することができる。ファイル参照を暗号化しない例では、パスワードまたはパスフレーズを要求するか、または、認証されたネットワークアドレスへのＳＳＬ接続のみを許可する等の、別のアクセス制御手段を使用することが好ましい。

１９９８年１２月２３日を国際公開日とする国際公開第９８／５８３３２号パンフレットに先行技術文献として掲げられた１９９７年６月１７日を出願日とする米国特許出願第０８／８７７，０６５号、および、１９９８年６月５日を出願日とする米国特許出願第０９／０９２，１３２号には、ファイル参照のセキュリティー強化を実施するために役立つ事項が開示されている。

図２に示す方法２００に従って動作する場合、コンピュータ１１０（図１参照）の電子メールクライアント・モジュール１１６は、ファイル管理者１０２の制御の下に、コンピュータ１４０の電子メールクライアント・モジュール１４６にメッセージ２２４を送信する。ダイレクトファイルアクセスが認証されているファイル使用者１９８は、メッセージ２２４とは別にファイル２２２（図２参照）にアクセスすることができる。ファイル２２２のファイル使用者１９８、および、任意の他の認証されたファイル使用者は、アクセスサーバ１７０を介してファイル２２２のデータを取得し、（編集者とし認証されている場合には、）それを修正することができる。このような、通常は帯域幅集中的（bandwidth-intense）であってかつ規制されたファイルアクセスは、コンピュータ１１０とコンピュータ１１０との間のネットワーク接続１４とは別に、ネットワーク接続４７を介して生じる。したがって、ネットワーク接続１４は、ファイル２２２がアクセスサーバ１７０に保存された後、ファイル２２２へのアクセスの特性に影響を及ぼすことなく、低帯域幅かつ散発的な接続によって実現することができる。

ネットワーク接続１４、１７、４７は、任意の適切な接続設備および通信プロトコルを使用して実装することができる。適切な接続設備の例には、対撚り線ケーブル、光ファイバーケーブル、スペクトラム拡散方式無線通信（赤外線またはＲＦ）、ＲＦ衛星中継、可聴変調の電話接続が含まれる。様々な階層における適切な通信プロトコルの例には、ＡＴＭ、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＦＴＰ、ＮｅｔＢＥＵＩ、および、対称鍵暗号または公開鍵暗号が含まれる。システム１００の典型的の実装において、特に、ネットワーク接続１４、１７、４７が、インターネットのような広域的かつプラットフォームに依存しないネットワークである場合には、複数種類の接続設備およびプロトコルが使用されるものである。

システム１００の特に有利な例では、コンピュータ１１０は、低帯域幅または他の非理想的な状況下で、ファイル２２２のアクセスサーバ１７０への送信を延期する一方、コンピュータ１４０に対して電子メッセージ２２４を送信することができる。このようなシステムは、ネットワーク接続１７の状況を監視し、接続１７の品質レベルが改善したときにファイル２２２を送信する。品質レベルは、好ましくは速度に基づいて判別されるが、中断頻度（interruption frequency）の要因ともなるものである。

ファイル転送の延期は、任意の適切な基準を用いて任意の適切な方法により解析することができる。例示的な方法では、コンピュータ１１０は、ファイル使用者へ送信されるメッセージの送信の間に、ネットワーク接続１４を介して送信されるパケットを解析することにより、接続の状況を判別する。パケット送信のタイミングが、（予め定められた基準により、）接続１７の品質が、参照として「添付された」ファイルを送信するための品質として不適当であることを示す場合には、コンピュータ１１０は、状況が改善されるまで、その送信を延期する。コンピュータ１１０は、ファイルが添付された電子メッセージ以外の電子メッセージの送信の間、または、インターネットのＷｅｂページの取得の間に送信されるパケットを解析することによって、定期的に状況を監視することもできる。この方法に代わる多くの可能な方法のうちの１つは、コンピュータ１１０のローカルエリアネットワーク接続が動作中であるか、または、モデム接続が動作中であるかを検査して、ローカルエリアネットワーク接続が動作中になるまで、ファイル送信を延期する方法である。別の方法とは、送信のレイテンシーに基いて、アクセスサーバ１７０で「ｐｉｎｇｉｎｇ」を実行し、送信時間を判別する方法である。

１９９９年５月２７日を国際公開日とする国際公開第９９／２６１２１号パンフレットに先行技術文献として掲げられた１９９７年１１月１３日を出願日とする米国特許出願第６０／０６５，５３３号、１９９８年５月１４日を出願日とする米国特許出願第６０／０８５，４２７号、および、１９９８年９月１７日を出願日とする米国特許出願第６０／１００，９６２号、には、ファイル参照のセキュリティー強化を実施するために役立つ事項が開示されている。

本発明の様々な態様に従う電子メッセージの送信のための信号の例は、図６を参照することにで、より理解し易くなるであろう。搬送される信号６００は、一連のデータフレームを含んでおり、図６Ａに示す部分で開始し、図６Ｂに示す部分で終了する。一連のデータフレーム（連続する列または無関係のデータを散在させた列をなす、並列フォーマットまたは直列フォーマット）を有する任意の適切な種類の信号を使用することができる。

フレーム６１０は、サブフレーム６１２〜６１８を含み、このメッセージを識別し、従来のメッセージ送信プロトコル（例えば、ＭＩＭＥ）を使用して従来のシステムでメッセージを処理可能にするための補助メッセージデータを含んでいる。

フレーム６２０〜６６０はのそれぞれには、２つのサブフレームが含まれている。サブフレーム６２２、６３２、６４２、６５２、６６２は、各フレームの内容を識別するヘッダを含んでいる。サブフレーム６２４、６３４、６４４、６５４、６６４は、それぞれのヘッダに関連付けられた指示データのセット（例えば、電子メールアドレスのＡＳＣＩＩテキスト）を含んでいる。フレーム６２０〜６６０のいくつかは、左側を空白とし、フレームを識別するヘッダのみを含むものであってもよい。

フレーム６２０、６３０、６４０は、メッセージ受信者フレームである。これらのフレームは、電子メッセージのウィンドウにおける従来のフィールド（この例では、「ＴＯ：」、「ＣＣ：」、および、「ＢＣＣ：」）で指定されたメッセージ受信者の１つまたは複数のアドレスを含んでいる。フレーム６５０、６６０には、それぞれ、メッセージ中で参照されるファイルへの直接的な閲覧アクセスまたは編集アクセスが認証された閲覧者または編集者として指定されたメッセージ受信者の１つまたは複数のアドレスを含めることができる。

フレーム６７０は、サブフレーム６７２、６７４を含み、メッセージの実際の情報を含んでいる。例えば、ダイレクトファイルアクセスが認証されていないユーザに対して、添付ファイルと共に送信されるメッセージの場合、サブフレーム６７４には、添付ファイルの実際のデータを含めることができる。しかし、図６Ｂに示すように、メッセージ信号６００は、ファイルを参照するデータ６７４を含むものである。上述したように、ファイル参照データには、例えば、実行時にダイレクトファイルアクセス・モジュールを実装するプログラム、または、ハイパーリンクを含めることができる。

システム１００におけるファイルアクセスのための例示した方法３００は、図３を参照することで、より良く理解できるであろう。（ここで、この例および本明細書に記載された他の例は、本発明を限定するものではないことを再記しておく。）図１に示すコンピュータ１４０は、ダイレクトファイルアクセス・モジュール１４８が動作している間に、方法３００を実施する。

方法３００は、図３に示す処理３１０において、電子メールクライアント・モジュール１４６を使用してメッセージ３２５（図３参照）を閲覧するファイル使用者１９８（図１参照）の動作で開始する。メッセージ３２５は、メッセージ２２２（図２参照）のデータのコピーであり、コンピュータ１１０から、ネットワーク接続１４（図１）を介してコンピュータ１４０で受信される。メッセージ３２５は、図２に示すファイル２２２への参照含んでいる。例示したシステム１１０および方法２００、３００では、このファイル参照は、添付されたプログラムであり、これによって、ファイル使用者１９８は、ダイレクトファイルアクセス・モジュール１４８を実装することができる。

方法３００は、図３に示す処理３３０に進んでダイレクトファイルアクセス・モジュール１４８を起動し、次いで、処理３４０、３５０、３７０（図３では、これらの処理１４８は、方形の破線で表されたモジュール１４８中に示されている）を実行する。処理３４０は、ファイル使用者に対するユーザインタフェースを表示する。このユーザインタフェースは、ユーザが指定されたファイルにアクセスするかどうかを確認するためのダイアログボックスのような、単純なものであってもよい。ユーザインタフェース処理３４０は、モジュール１４８の起動時に自動的に１つのファイルを開くことが許容される場合には、完全に省略することができる。

ユーザインタフェース処理３４０は、ファイル使用者１９８の指示に従って処理３５０を実行し、アクセスサーバ１７０（図１参照）からファイル２２２（図２参照）のデータを取得する。図３では、コンピュータ１４０の外で発生するすべてのイベントは、ネットワークを示す雲３６０によって露あされているため、この処理３５０は、図１を参照することで、より良く理解されるであろう。処理３５０の間に、コンピュータ１４０のダイレクトファイルアクセス・モジュール１４８は、アクセスサーバ１７０のネットワークファイル転送インタフェース１７２と通信し、ストレージ１７４からファイル２２２を取得して、ファイル２２２のデータを、ネットワーク接続４７を介してモジュール１４８へ送信する。

処理３５０は、ファイル２２２のデータを、コンピュータ１４０がそのストレージモジュール１４４に保持しているローカルデータストレージ３８０（図３参照）に保存する。次いで、ユーザインタフェース処理３４０は、ユーザインタフェースのフォーカスを編集または閲覧処理３９０に送信する（例えば、新たなユーザインタフェースウィンドウを開く）ことができる。次いで、ファイル使用者１９８は、適切なソフトウェアモジュールを使用して、ファイル２２２を閲覧または修正することができる。例えば、ファイル使用者１９８は、ワードプロセッサを使用してテキスト文書を閲覧または編集することができる。

例示した方法３００におけるファイル２２２へのアクセスは、ローカルデータストレージ３８０内にキャッシュされたファイルのコピーを使用した間接的なものである。有利なことに、ファイル２２２に対してなされる任意の修正は、ます、キャッシュされたコピーに対してなされるものであり、その後初めて、アクセスサーバ１７０のストレージ１７４内にある元のファイルに適用される。処理３７０は、ローカルデータストレージ３８０内にキャッシュされたコピーの状態に基づいて、元のファイル２２２の更新を実行する適切な時期を判別する。次いで、処理３７０は、雲３７０で示すネットワークによってアクセスサーバ１７０と通信し、適宜に更新を実行する。

例示した方法３００において、ファイル修正を延期することは、ファイルに対してローカルに（すなわち、コンピュータ１４０内で）アクセスし、それによって、大規模なファイルの閲覧および修正に要するネットワークトラフィック量を削減する点で、有利である。加えて、修正を延期することによって、元のファイル２２２に対する修正のバージョン管理を単純化することができる。図７〜図１０を参照して後述するように、編集者の修正の伴うファイルの更新は、ブロックまたはバイト差分法を使用して実施することができる。

本発明の様々な態様に従うダイレクトファイルアクセスの有利な例では、ドライブマッピングインタフェースを含むものである。このインタフェースを使用すると、アクセスサーバ１７０（図１参照）のストレージモジュール１７４中の１つまたは複数のフォルダに、それらのフォルダがコンピュータ１４０に保持されているかのようにして、アクセスすることができる。

本発明の様々な態様に従う、直接的にアクセスされたファイルに対する修正の例示的な調整方法７００、８００は、図７〜図１０を参照することで、より良く理解されるであろう。これまでの説明と同様に、例示したファイル２２２（図２参照）に対する修正は、例示したシステム１００（図１参照）、および方法２００、３００（図２、図３参照）に基づいて説明される。

図７は、バイト差分法を使用してファイル２２２を維持するための方法７００を示す機能フローチャートである。方法７００は、２つの並列なステップで開始する。決定ステップ７１０は、ファイル２２２がファイルの編集者によってアクセスされた（または、編集者にリンクされた）かどうかを判別する。ステップ７２０は、決定ステップ７１０の結果とは独立に、アクセスサーバ１７０にファイル２２２のデータへの参照（例えば、リンク）を作成する。

方法７００（または、少なくとも図７に示す方法７００のインスタンス）の開始前にファイルの編集者がファイル２２２に直接的にアクセスしていた場合には、ステップ７５０に進み、ファイル２２２の直前のバージョンを取得する。次いで、処理７６０は、バイト差分エンジンを使用して、直前のバージョンと現在の（すなわち、使用者により修正された）バージョンとを比較する。バイト差分エンジンは、任意の適切なハードウェアまたはソフトウェアを使用して、２つのファイルを個々のバイト毎に比較し、個々のバイト間の差分の指示データを生成する。次いで、処理７７０に進み、この指示データを含む差分ファイルを作成する。処理７７０は、保存処理７３０により示されているように、処理７２０で作成された参照に従って、この差分ファイルをアクセスサーバ１７０に送信する。（差分ファイルは、好ましくは、適切に暗号化または圧縮されたフォーマットで送信される。）方法７００の最後の処理７８０は、任意選択で、ファイル２２２の直前のバージョンを削除する。

方法７００が開始する前にファイルの編集者がファイル２２２に直接的にアクセスしていなかった場合、処理７４０は、単にファイル２２２を圧縮（および、好ましくは暗号化）し、それを、ファイル管理者１０２のコンピュータ１１０から（例えば、方法２００を使用して）アクセスサーバ１７０に送信する。ファイル２２２の修正が認証されたユーザが誰もアクセスしなかった場合、差分ファイルは必要ない。

図８は、（バイト差分法ではなく、）ブロック差分法を使用してファイル２２２を維持するための方法８００を示す機能フローチャートである。方法８００は、方法７００とほぼ同様に進行し、方法８００の処理８１０、８２０、８３０、８４０は、方法７００の処理７１０、７２０、７３０、７４０と同様のものである。ただし、処理８５０では、ファイルそれ自体ではなく、ファイル２２２の直前のバージョンのブロックの統計情報を取得する。この理由は、各ブロックはファイル２２２の異なるユニットであり、アクセスサーバ１７０へ送信する必要があるのは、ファイル２２２のうち、編集者による修正の結果、変更されたブロックのみであるからである。ブロック中のデータを、所望の統計的確実性の範囲で、一意的に記述する任意の適切な種類の統計情報、例えば、ＳＨＡ−１ハッシュまたは３２ビットＣＲＣ、を使用することができる。

方法８００は、ステップ８５５に進み、ファイル２２２の修正された（すなわち、現在の）バージョンを読取る。次いで、ステップ８６０は、２つのバージョンのブロックの統計情報を比較し、ステップ８７０は、変更されたファイルのブロックの統計情報を使用して、変更されたブロックの差分ファイルを作成する。方法８００の最後のステップであるステップ８００は、任意選択で、ファイル２２２の直前のバージョンの統計情報を削除する。

図３、図７、図８にそれぞれ例示した方法３００、７００、８００は、図１に示すシステム１００、ファイル管理者１０２、および、ファイル使用者１９８を参照するダイレクトファイルアクセスのさらに詳細な例を示すことで、より良く理解されるであろう。この例は、以下の表１、表２、表３を参照することで、より良く理解されるであろう。この例において、システム１００は、次のように構成されている。（１）ファイル使用者１９８に対して、例示したファイルを編集するダイレクトファイルアクセスが認証されている。（２）ダイレクトファイルアクセスの対象となるファイルは、そのファイルを開くときおよび保存するときには、暗号が解除されているかまたは圧縮が解凍されている。（３）電子メールクライアント・モジュール１４６は、本発明の様々な態様に従うように、その機能が適切にカスタマイズされている。（４）コンピュータ１４０は、添付ファイルをファイル参照に置換するタイプの上述した追加モジュール（図示は省略する）を実装している。

表１は、ファイル使用者１９８がファイルにアクセスする際の、好ましい一連のステップのリストとして、この例の説明を始めるものである。次の表２は、ファイル使用者１９８が修正ファイルをファイル管理者１０２に返送する際の、好ましい一連のステップのリストにより、この例の説明を継続するものである。

次の表３は、ファイル管理者が修正されたファイルにアクセスする際の好ましい一連のステップのリストとして、この例の説明を完結するものである。

手作業により認証データを決定するためのシステムおよび方法の例は、図４および図５を参照することで、より良く理解されるであろう。図４および図５には、それぞれ電子メッセージのウィンドウが示されている。本発明の様々な態様に従う電子メッセージのウインドウは、ユーザが電子メッセージを作成するために適切な、コンピュータディスプレイ上に表示される可視要素の任意の集合体を含んでいる。ウィンドウ４００、５００は、それぞれ、「ＴＯ：」のラベルが付いた受信者フィールド４１２、５１２、「ＣＣ：」のラベルが付いた二次的な受信者フィールド４１４、５１４、「ＢＣＣ：」のラベルの付いた秘匿性の二次的受信者フィールド４１６、５１６、ファイル名フィールド４３０、５３０、件名フィールド４４０、４５０、および、メッセージテキストフィールド４５０、５５０を含んでいる。これらのフィールドの利点を必要としない例では、これらのフィールドのいくつかを省略することができる。

本発明の様々な態様に従って、メッセージウィンドウ４００、５００のそれぞれは、さらに、閲覧者フィールドおよび編集者フィールドを含んでいる。ファイル使用者のアドレスの指示データを閲覧者フィールドに記録することによって、そのファイル使用者に対してメッセージウィンドウのファイル名フィールドに指定されたファイルの閲覧を認証すると共に、修正を認証しないことが指定される。ファイル使用者のアドレスの指示データを編集者フィールドに記録することによって、そのファイル使用者に対して指定されたファイルの修正を認証することが指定される。ファイル管理者は、該当するフィールドに複数のアドレスを入力することにより、複数のファイル閲覧者およびファイル編集者を、所望の組み合わせで指定することができる。

例示したシステム１００、および方法２００、３００では、ファイル使用者１９８は、ファイルアクセス認証を受信することに加えて、「ＴＯ：」、「ＣＣ：」、または、「ＢＣＣ：」のいずれの受信者としても、メッセージ２２４を受信することができる。メッセージ２２４の他の受信者に対して、ファイル使用者１９８がメッセージ２２４に加えてアクセス認証を受けたことを通知する必要はないが、所望の場合には、メッセージ２２４に、その旨を公開する可読指示データを含めることもできる。

図４に示すウィンドウ４００は、「Ｖｉｅｗｅｒ：」とラベルの付いた閲覧者フィールド、および、「Ｅｄｉｔｏｒ：」とラベルの付いた編集者フィールドを含んでいる。（ラベルのテキストは、言語学的に等価な（例えば、外国語における）任意の単語であってもよく、大文字または小文字であってもよい。）ファイル管理者１０２は、ファイル使用者１９８の電子メールアドレスを閲覧者フィールド４２４または編集者フィールド４２６に入力することによって、ファイル使用者１９８を閲覧者または編集者として指定することができる。また、ファイル管理者１０２は、各フィールド４１２、４１４、４１６にアドレスを入力することによって、ファイル使用者１９８を、「ＴＯ：」、「ＣＣ：」、「ＢＣＣ：」の受信者として指定するこもできる。

ファイル管理者１０２は、単に再度タイプ入力するかまたは切り取りと貼り付けを使用することにより、ファイル使用者のアドレスを、メッセージウィンドウ４００の第２のフィールドに複製することできる。有利な電子メールクライアント・モジュール１１６の例では、アドレスが最初に入力されたフィールドを参照して、そのアドレスが第２のフィールドに自動的に複製される。これによって、ファイル管理者１０２がアドレスを二回入力する手間が省けるものである。

その一例では、（例えば、ポインティングデバイスでアドレス上を右クリックすることによって）入力されたアドレスを選択すると、そのアドレスに対する異なるフィールドの指定を素早く実行するためのコンテキストメニューが表示される。例えば、図４には、アドレス４６２「ｃｈａｒｌｅｓ＠ｃｏｍｐａｎｙ．ｃｏｍ」上を右クリックした結果、ウィンドウ４００上に表示されたコンテキストメニュー４６４が示されている。コンテキストメニュー４６４は、アドレス「ｃｈａｒｌｅｓ＠ｃｏｍｐａｎｙ．ｃｏｍ」を、フィールド３１２、４１４、または、４１６に複製するための、３つのメニュー項目を含んでいる。アドレス４６４「ａｌｉｃｅ＠ｃｏｍｐａｎｙ．ｃｏｍ」を同様に選択することによって、選択項目として「Ｖｉｅｗｅｒ」および「Ｅｄｉｔｏｒ」を有するコンテキストメニュー（図示は省略する）が表示され、このアドレスをアドレスフィールド４２４または４２６に複製することができる。図４の例は、ファイル管理者１０２が、「ａｌｉｃｅ＠ｃｏｍｐａｎｙ．ｃｏｍ」を「ＢＣＣ：」フィールド４１６に入力し、それを「Ｖｉｅｗｅｒ：」フィールド４２４に複製したものである。

他の場所に複製したアドレスのテキストを、ハイパーリンクとして機能させることもできる。ポインティングデバイスによる選択の際に、このようなテキストは、カーソルのフォーカスを参照アドレスに送るか、または、コンテキストメニュー（例えば、メニュー４６４）を表示するものである。

有利なことに、手作業により入力および複製されるアドレスは、本発明の様々な態様に従うウィンドウに様々な態様で表示させることができる。例えば、メッセージウィンドウ４００では、複製されないアドレス（例えば、アドレス４６６「ｃｏｎｓｕｌｔａｎｔ＠ｕｎｉｖｅｒｓｉｔｙ．ｅｄｕ」）は、第１の表示態様を有している。ウィンドウ４００において、第１の表示態様は、単なる通常の文字である。最初にフィールドに入力されて別のフィールドに複製されたアドレス（例えば、アドレス４６２）は、第２の表示態様を有しており、ウィンドウ４００において、第２の表示態様は、下線付き文字である。別のフィールドから複製されたアドレス（例えば、フィールド４１のアドレス４６８）は、第３の表示態様を有しており、ウィンドウ４００において、第３の表示態様は、斜体文字である。異なる表示態様に対して異なる色を使用することも可能であり、この場合、第２の表示態様を有するテキストは、ハイパーリンクで一般的に使用される青色を有していてもよい。

電子メールクライアント・モジュール１１６の他の有利な例では、ファイルの閲覧者および編集者のフィールドは、従来の「ＴＯ：」、「ＣＣ：」、「ＢＣＣ：」の受信者フィールドとは異なるものであってもよい。例えば、図５に示すウィンドウ５００は、従来の受信者フィールド５１２〜５１６に加えて、閲覧者フィールド５２４および編集者フィールド５２６を含んでいる。例示したメッセージウィンドウ５００の領域５２０において、各フィールド５２４、５２６は、縦に配列されたラジオボタンの列をなしており、それぞれの行は、従来の受信者フィールド５１２〜５１６に入力されたアドレスに対応している。

通常、ラジオボタン・ユーザインタフェース要素は、グループ内において、、唯一のボタンが選択されると共に少なくとも１つのボタンは選択されるようにクラスタ化されるものである。従来の規則に従うために、領域５２０は、「ｎｏ ａｕｔｈｏｒｉｚａｔｉｏｎ」フィールド５２２のラジオボタン含んでいる。特定のアドレスに対して、フィールド５２４の「ＶＩＥＷＥＲ」ラジオボタンも、また、フィールド５２６の「ＥＤＩＴＯＲ」ラジオボタンも選択されない場合には、該当する「ｎｏ ａｕｔｈｏｒｉｚａｔｉｏｎ」ラジオボタンが選択状態になる。このように、各アドレスに対応するそれぞれの行において、１つのラジオボタンが選択された状態が維持される。

ウィンドウ５００において、各フィールド５２２、５２４、５２６の行数は、フィールド５１２〜５１６に記録されたアドレスの数と一致する。記録されるアドレスの数の増減に応じて、領域５２０のボタンの行数も増減する。好ましくは、削除された行の状態は、それが削除された後も（例えば、グレイテキストを使用することにより）保持されるものであり、それによって、フィールド５１２〜５１６の１つに再び該当するアドレスが記録された場合、その行を復元することができる。例えば、システム１００および方法２００において、ファイル管理者１０２は、「ＣＣ：」フィールド５１４から「ａｌｉｃｅ＠ｃｏｍｐａｎｙ．ｃｏｍ」を削除し、代わりに、このアドレスを「ＢＣＣ：」フィールド５１６に置くこともできる。このアドレスをフィールド５１４に記録した際に、ファイル管理者１０２が、このアドレスを、ファイル「Ｗｉｄｇｅｔ Ｄｅｓｉｇｎ Ｓｐｅｃ．ｒｔｆ」の閲覧者に属するアドレスとして指定していた場合、このアドレスをフィールド５１６に記録する際に同じ指定が保持されていれば、ファイル管理者にとって便利である。

認証の自動決定と手動決定とを併用する例では、ユーザの利便性を向上するために、閲覧者および編集者のデフォルトの指定を自動決定により生成することができる。例えば、「ｂｏｂ＠ｃｏｍｐａｎｙ．ｃｏｍ」が、ファイル「Ｗｉｄｇｅｔ Ｄｅｓｉｇｎ Ｓｐｅｃ．ｒｔｆ」の編集権限を有する編集者に属するアドレスとして決定された場合、このアドレスのフィールド４１２、４１４、または４１６への入力時に、ウィンドウ４００の「Ｖｉｅｗｅｒ：」フィールド４２４に自動的に複製することができる。同様に、このアドレスのフィールド５１２、５１４、５１６への入力時に、ウィンドウ５００の領域５２０に、フィールド５２６の該当するラジオボタンが自動的に選択されて、このアドレスが表示されるものであってもよい。

さらに、自動決定による認証は、閲覧者または編集者として手作業で指定された任意のアドレスをオーバーライドする、高い優先度を有するものであってもよい。手作業によるい指定のオーバーライドは、視覚的に表示することもできる。例えば、ウィンドウ５００の領域５２０中のいくつかのラジオボタンを、グレイ表示するものであってもよい。ウィンドウ４００において、アドレスを閲覧者または編集者として指定するためのメニュー項目を、同様にグレイ表示することもできる。

図４および図５の例は、本発明の様々な態様に従う電子メールを介したファイルアクセスの簡便性を例示するものである。両方の例において、ファイル「Ｗｉｄｇｅｔ Ｄｅｓｉｇｎ Ｓｐｅｃ．ｒｔｆ」のファイル管理者は、単純な電子メールのみを使用して、４人のユーザに対して３つの異なる種類の認証を実行している。それらのユーザのうちの２人（「Ｂｏｂ」と「Ｃｈａｒｌｅｓ」）は、「Ｃｏｍｐａｎｙ」内のファイル管理者の同僚であり、ダイレクトアクセスが認証された編集者として指定されている。したがって、彼等はファイルを修正することができ、ファイル管理者は、メッセージの本文（フイールド４５０および５５０）で、その旨を指示している。

「Ｃｏｍｐａｎｙ」内の他のユーザ（「Ａｌｉｃｅ」）も、このファイルに対するダイレクトアクセスが認証されているが、そのレベルは閲覧のみである。「Ａｌｉｃｅ」は、例えば、異なる部署の人間であって査察的な役割でのみ参加しているか、または、組織内おける権限として、ファイルの内容に対してコメントを付けることのみを許可されているものである。

外部の組織（「Ｕｎｉｖｅｒｓｉｔｙ」）の人間である第４のユーザ（「Ｃｏｎｓｕｌｔａｎｔ」）に対しては、ダイレクトファイルアクセスを認証していない。これには多くの理由が想定される。例えば、この外部の組織が、ファイルに対して直接的にアクセスするためのアクセスサーバに接続する、互換性を有するネットワーク接続を有していないこともあり得る。別の例としては、「Ｃｏｍｐａｎｙ」のコンピュータシステム管理者が、この組織のローカルエリアネットワークの外部の人間からのダイレクトファイルアクセスを禁止する、セキュリティーポリシーを有している場合もある。「Ｃｏｎｓｕｌｔａｎｔ」は、受信するメッセージのコピーに添付された通常の添付ファイルとして、ファイルのコピーを受け取るものである。（メッセージの他の受信者は、ファイルに直接的にアクセスできるため、添付ファイルとしてファイルのコピーを受信する必要はない。）

ウィンドウ４００、５００は、ファイル管理者に対して、ファイル「Ｗｉｄｇｅｔ Ｄｅｓｉｇｎ Ｓｐｅｃ．ｒｔｆ」へのアクセスを管理するために、慣れ親しんだ直感的なインタフェースを提示するものである。ファイル管理者は、ダイレクトファイルアクセスを認証するために、３つの単純な作業の１つを実施すればよい。第１の選択肢は、「Ｖｉｅｗｅｒ：」または「Ｅｄｉｔｏｒ：」フィールド（４２４または４２６）に電子メールアドレスを入力することである。第２の選択肢は、通常の「ＴＯ：」、「ＣＣ：」、または、「ＢＣＣ：」フィールド（４１２〜４１６）に既に入力された電子メールアドレスを右クリックすることである。第３の選択肢は、ラジオボタンを選択することである。従来の電子メールシステムに見られる周知のインタフェースにこれらの新規な拡張を施すことによって、本発明の様々な態様に従って、共有ファイルへのネットワークアクセスの利点を維持しながら、添付ファイルとしてファイルを送信することの利便性を提供することができる。

図７、図８、および表２に関連して上述したように、ファイルは、受信者がそのファイルの直前のバージョンを有しているか否かに応じて、異なる方法で送信することができる。受信者が、そのファイルの直前のバージョンを取得していた場合には、（例えば、直前のバージョンから変更されたブロックまたはバイトのみを含む）差分ファイルを送信するのみで十分である。受信者のコンピュータは、受信者が差分ファイルを開いたときに、元のファイルにパッチを当てて要求されたバージョン（最新のバージョンとは限らない）のファイルをコンパイすることが可能なように、直前のバージョンと共に差分ファイルを保存することができる。受信者が直前のバージョンを取得していなかった場合、受信者のコンピュータに全ファイルが送信されて保存される。

さらに、ユーザがファイルを更新する際に、更新の送信先に対応するエンティティーが、ファイルの直前バージョンを保持するものであることが知られている場合、ユーザのコンピュータは、差分ファイルのみを送信することができる。そのユーザのコンピュータは、更新バージョンのファイルを、別のエンティティーへ送信する場合、繰返して閲覧する場合、または、さらに更新する場合等の必要に応じて、差分ファイルを直前のバージョンに適用して更新バージョンを再構築できる場所に、直前のバージョンと共に差分ファイルをローカルに保存することができる。そうでない場合、ユーザのコンピュータは、更新されたファイル全体を送信することができる。

本発明の様々な態様に従う協働的ファイル更新システムは、ファイルの更新バージョンを表すデータを、ファイルの受信者に指定されたユーザに効果的に送信するものである。更新バージョンと直前のバージョンの両方の受信者として指定されたユーザは、差分ファイルを受信する。差分ファイルは、ファイルの更新バージョンと直前のバージョンとの間の差を実質的に表すデータからなる。したがって、単に差分ファイルを使用して直前のバージョンにパッチを当てることにより、ファイルの更新バージョンを取得可能なユーザは、差分ファイルのみを受信する。このような場合、更新されたファイル全体を送信する必要はない。

本発明の特定の態様に従って、更新バージョンの受信者に指定されているが、直前のバージョンの受信者ではないユーザは、以前のどのバージョンからの差分ファイルでもなく、更新されたファイル自体を受信する。このファイルは、送信の前に更新されているため、送信後の更新ために複数の差分ファイルを送信する複雑性を回避することができる。

本発明の様々な態様に従う協働的ファイル更新システムには、本発明に係る電子メール・ファイルアクセスシステムの（上述した）すべてのハードウェアおよびソフトウェアを含めることができる。例えば、このようなシステムは、図１〜図３を参照して上述したように、ファイル自体ではなく、ファイルへの参照を含む電子メールメッセージを送信することができる。参照されるファイルは、ファイルの送信者と受信者の両方からアクセス可能なアクセスサーバに保存される。参照ファイルを送信することの利点を必要としない協働的ファイル更新システムの例では、このシステムは添付ファイルとしてファイルそれ自体を送信することができる。

図１０〜図１９は、本発明の様々な態様に従う電子メール・ファイルアクセスシステムの一部として、図９に例示する方法９００により使用される協働的ファイル更新システムの様々な状態を示す図である。

方法９００に例示する本発明に係る協働的なファイル更新方法は、ユーザ「Ａ」から「Ｄ」の複数（この例では４人、ただし、図示は省略する）の間で、ユーザファイルの版数を管理するものである。例示した方法９００は、図９においてユーザのワークステーション（すなわち、コンピュータ）によってグループ化され、ワークステーション上で実行される様々な処理装置を含んでいる。グループ９１０の処理９１４〜９２０は、ローカルデータストレージ９１２を有する第１のユーザＡのコンピュータ１０２０（図１０参照）上で実行される。処理９３４〜９３８は、ローカルデータストレージ９３２を有する第３のユーザＢのコンピュータ１０３０（図１４参照）上で実行される。処理９５４〜９５６は、ローカルデータストレージ９５２を有する第３のユーザＣのコンピュータ１０４０（図１４参照）上で実行される。処理９７４は、ローカルデータストレージ９７２を有する第４のユーザＤのコンピュータ１６３０（図１６参照）上で実行される。

図示された処理方法９００のそれぞれは、ユーザの１人によって送信されるファイルのデータへの参照を受信し、参照されたデータを共通のアクセスサーバ９９０から取得し、そのデータをローカルデータストレージに書き込むものである。処理装置９１６、９１８、９３４、９７４は、また、次のバージョンにファイルを修正し、そのファイルのデータをサーバ９９０に送信し、そのファイルデータへの参照を少なくとも１人のユーザに送信する。

図１０〜図１９は、方法９００における処理９１４〜９７４の間に使用されるハードウェアおよびデータ構造を破線で囲んで示す図である。図１０〜図１９の符号は、図９に示処理に関連する。

図に例示した方法９００は、ユーザＡがファイルの「ｒｅｖ０」を起案する処理９１４で開始する。ファイルの版数の送信を管理する本発明の方法は、より包括的な方法の一部であってもよく、方法９００の「ｒｅｖ０」は、実施には、方法９００を含む方法（図示は省略）で以前に起案されたファイルの何版目かのファイルであってもよい。同様に、方法９００では、ファイルに対して「ｒｅｖ４」（処理９７４、図１８）を超える修正はなされていないが、このような方法９００を含む包括的な方法は、さらなるファイルの修正を含んでいてもよい。

処理９１４（図１０参照）において、ユーザＡは、ファイルを起案（または、図示しない以前の処理により起案されたファイルを編集）し、ファイルのデータをファイルデータセット１０２４として、ユーザＡのコンピュータ１０２０（図１０参照）上に保存する。データセット１０２４は、コンピュータ１０２０のローカルストレージのアドレス指定可能なデータセグメント１０２２中に存在する。図９は、コンピュータ１０２０のローカルストレージを、データ保存庫９１２として概念的に示すものである。

コンピュータ上のローカルストレージの、本発明の様々な態様に従うアドレス指定可能なデータセグメントは、特定の名前または識別コードで適切に選択できるデータの集合を含んでいる。例えば、図２０を参照して以下に詳述するように、コンピュータ１０２０のローカルストレージのセグメント１０２２（図１０参照）は、コンピュータ１０２０によって制御されるハードディスク上の階層化ディレクトリ（すなわち、フォルダ）構造である。ファイルデータセット１０２４は、セグメント１０２２の最新のサブディレクトリ中に存在するファイルであり、（作成またはローカルに受信した）ファイルの初期バージョンと、ファイルを現在の版数に再構築するための差分ファイルを保存している。データセット１０２４は、標準的なファイルシステムのファイル、すなわち、ファイルシステムのパスおよびファイル名によってアドレス指定可能な文字の集合である。アドレス指定可能なデータセグメントおよびファイルデータセットの他の適切な種類には、例えば、ｍｙＳＱＬデータベーステーブルおよびそのレコード、および、オフセットインデックス付きのレコードを備えた「フラットファイル」データベースが含まれる。

処理９１４は、図９に太い矢印９１５で示すように、ファイルの全体を表すデータ１０１０をサーバ９９０に送信する。サーバ９９０は、そのファイルのデータを、アドレス指定可能なデータセグメント９９２でユーザＡのために維持を開始したファイルデータセット９９４に書き込む。データ１０１０は、適切に圧縮するか、または、暗号化するか、あるいは、その両方の処理を施すことができる。

処理９１４は、電子メールメッセージ１０１２を、電子メールサーバ１０４０を介してユーザＢのコンピュータ１０３０に送信する。メッセージ１０１２は、例えば、ハイパーリンクまたはダイレクトファイルアクセス・モジュールのような、図１のシステム１００に関連して上述したタイプのファイル参照（図示しない）を含んでいる。このファイル参照によって、ユーザＢは、処理９３４において、サーバ９９０からファイルのデータのコピー１０５０を取得することができる。処理１０３０は、ファイルのデータを、ディレクトリ１０３２内のファイルデータセット１０３４に書き込む。

図１１に示すように、処理９１４の結果として、（１）ユーザＡのコンピュータ１０２０のファイルデータセット１０２４、（２）サーバ９９０のファイルデータセット９９４、（３）ユーザＢのコンピュータ１０３０のファイルデータセット１０３４中に、「ｒｅｖ ０」のファイルのコピーが存在する。処理９１４の終了後には、電子メールサーバ１０４０のローカルストレージ１０４２中に、電子メールメッセージ１０１２（図１０参照）のコピー１０４４が存在する。一例では、電子メールサーバ１０４０は、処理９３４が電子メールメッセージ１０１２を取得した後に、そのすべてのコピーを削除する。

図９および図１２から分かるように、ユーザＢは、処理９３４において、ファイルを「ｒｅｖ１」に編集する。この処理は、編集の結果修正されたファイル１２１０をローカルに書き込むことによって方法９００に進み、ファイルデータセット１０３４に対するファイル修正を表す差分「ｒｅｖ１」を書き込み、この差分を表すデータ１２１２をサーバ９９０に送信する。図９には、データ全体ではない差分ファイルの送信が、細い矢印９３５で示されている。

本発明の様々な態様に従う協働的ファイル更新システムにおけるユーザのコンピュータでは、コンピュータのユーザは、コンピュータ自体がサーバから受信された以前のバージョンからファイルを更新したときに、更新されたファイルの全データを、共通にアクセス可能なサーバへ書き込むことを回避することができる。例えば、図１２に示す処理９３４の間に、コンピュータ１０３０は、ローカルのファイルデータセット１０３４中にファイルの「ｒｅｖ０」が存在しているか否かを判別する。したがって、処理９３４は、修正されたファイル１２１０の内容全体を送信して資源を消費する代わりに、差分データ１２１２のみをサーバ９９４に返信すればよい。

ファイルデータセットを保存するために準備されたデータ構造は、図２０、図２１を参照することで、より良く理解されるであろう。上述したように、図２０は、アドレス指定可能なデータセグメント１０２２の階層的ディレクトリ構造を示すものであり、このデータセグメント１０２２は、ユーザＡのコンピュータ１０２０（図１０参照）により制御されるハードディスク９１２(図９)上に存在する。セグメント１０２２は、所望のディレクトリまたはハードディスクのファイル構造のルートに存在する、トップレベルのディレクトリ２０１０およびサブディレクトリ２０２０、２０３０を含んでいる。

ファイルデータセットの素早くかつ秩序だった選択を容易にするために、本発明の様々な態様に従う協働的ファイル更新システムは、自動的に名付けられた一連のディレクトリ中の自動的に名付けられたファイルとして、データセットを保存することができる。例えば、ファイルデータセグメント１０２２のディレクトリ２０１０〜２０３０は、一意的と見なし得るコード（図示は省略する）の異なる部分文字列であるような名前を有している。例示したファイルデータセグメント１０２２は、１２８ビットの識別コード（３２個の１６進文字）を使用しており、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ＡＰＩへの標準的な呼び出しの結果として生成された、ＧＵＩＤ（ＧＬｏｂａｌｌｙ Ｕｎｉｑｕｅ ＩＤ）とすることができる。トップレベルのディレクトリ２０１０は、このＧＵＩＤコードの最初の２つの１６進文字をその名前として使用し、一方、ディレクトリ２０２０および２０３０は、それぞれ第２および第３のペアを、それらの名前として使用する。ファイルデータセット１０２４は、このコードの残りの２６文字をその名前として使用する。一意的と見なし得る他の種類のコードとして、例えば、ファイル名、作成日時タイムスタンプ、および、作成者のユーザ名を連結した文字列のＳＨＡ−１ハッシュ値を使用することができる。

図２０、図２１に示す階層化ディレクトリ構造１０２２、９９２のツリーのバランスを容易に取るために、使用される一意的と見なし得るコードは、統計的に一様に分布した数字を有することが好ましい。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）２０００またはＸＰのＡＰＩへの呼び出しによって生成されるＧＵＩＤは、そのような分布に十分適合すると見なし得るものであるが、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）９５のＡＰＩへの呼び出しによって生成されるＧＵＩＤは、所望のレベルの統計的確実性を確保するために、さらなる処理を施す必要がる場合がある。

図１２および図１３に示したように、サーバ９９０は、ユーザＢのコンピュータ１０３０からデータ（この時点では、「ｒｅｖ１」差分データのみ）を保存するために、アドレス可能なデータセグメント９９２中に、分離されたファイルデータセット１２２０を維持してい。各ユーザに対して分離されたファイルデータセットを維持することによって、サーバ９９０は、異なるユーザが同時にいくつかの版数をファイルへ保存することによって発生する書き込み衝突を解決することを回避することができる。代わりに、（例えば、データセット９９４、１２２９が標準的なコンピュータファイルであるカーネルレベルのファイルシステムのような、）分離されたデータセットを維持するどんなメカニズムも、同時の文書編集の解決を管理するものである

図２１は、アドレス指定可能なデータセグメント９９２を詳細に示すものであり、４つの階層化されたディレクトリ２１１０〜２１４０、および、ディレクトリ２１４０の最深レベルに存在する２つのファイルデータセット９９４、１２２０を含んでいる。ディレクトリ２１１０〜２１３０は、上述した３２の文字コードの、第１、第２、および、第３のペアの英数文字を、それぞれに、その名前として使用している。ファイルデータセット９９４、１２２０は、ユーザＡおよびユーザＢに関連付けられた一意的と見なし得る識別コードを、それらの名前としてそれぞれ使用している。（ファイルデータセットを含むすべてのファイルは、ベールファイル名に加えて標準的なファイル拡張子を有することができる。）

図９および図１２、図１３を参照することで、より良く理解されるように、方法９００は、サーバ１０４０によってメッセージ１２３０から中継された電子メールメッセージ１２４０を受信する処理９１６に進む。ユーザＡは、電子メールメッセージ１２４０中のファイル参照（図示は省略する。例えば、図６ｂ参照）を介してサーバ９９０から「ｒｅｖ１」データにアクセスする。ユーザＡのコンピュータのファイルデータセット１０２４は、既にファイルの「ｒｅｖ０」のデータを含んでいるため、サーバ９９０は、ユーザＢのコンピュータ１０３０が処理９３４でサーバ９９０に送信した差分データ１２１０のコピーである、差分データ１３１０のみを送信する。データ１３１０は、コンピュータ１０３０が元のデータ１２１０を送信した日付および時刻、他のユーザによってアクセスされたデータ１２１０の他のコピーに関する情報、等の追加のデータ要素を含んでいてもよい。データ１２１０、１３１０は、同じフォーマットでもよく、適切に使用可能な異なるフォーマットでもよい。例えば、データ１２１０は、クライアントのアップロードデータ速度が通常は低速である点から、より圧縮されたものであってもよい。

ファイルの「ｒｅｖ１」を受信した後、ユーザＡは、処理９１６（図９、図１４参照）
で、ファイルを「ｒｅｖ２」に編集し、差分ファイル１４０５をサーバ９９０に返送し、ファイルの更新版へのファイル参照を含む電子メールメッセージ１４１０を、ユーザＢ（電子メールのコピー１４２０を処理９３６）およびユーザＣ（電子メールのコピー１４３を処理９５４）に、電子メールサーバ１０４０を介して送信する。サーバ９９０は、データセット９９４中に「ｒｅｖ２」差分データを保持しており、ユーザＡのために維持される。

図１５を参照することでよく理解されるように、処理９３６は、ファイルの「ｒｅｖ２」のための差分データ１５１０をサーバ９９０から取得し、サーバ９９０は、データセット９９４からデータを取得する。処理９３６は、ローカルのファイルデータセット１０３４中にファイル１２１０の「ｒｅｖ１」のローカルコピーを有しているため、ファイルの更新版の完全なコピーではなく、差分データ１５１０のみを要するものである。差分ファイル１５１０に基づいて、（例えば、特定のバイトまたはブロックを置換することによって）コピー１２１０を更新することは、容易である。しかし、処理９５４は、ファイルの以前の（または、関連する任意のコピー）を有しておらず、したがって、ファイル１５２０の「ｒｅｖ２」の内容全体を取得するものである。

ユーザＡは、処理９１８（図１６参照）において、ファイルの編集を継続し、ファイルの「ｒｅｖ３」を表す差分データ１６０５をサーバ９９０に送信する。再び、サーバ９９０は、このファイルの直前のバージョンを有しているため、必要なのは差分データのみである。また、処理９１８は、更新版への参照を含む電子メールメッセージ１６１０を、ユーザＣのコンピュータ１６３０に送信する。処理９７４は、電子メールサーバ１０４０により中継されたコピー１６２０を介して、メッセージを受信する。図１７に示すように、処理９７４は、ファイルの「ｒｅｖ３」のデータ１７１０を、更新された通りに受信する。サーバ９９０は、データセット９９４の内容に基づいて、「ｒｅｖ２」状態のファイルから、サーバ９９０がユーザＡによる改版のために維持するデータ１７１０を構築する。

あるいは、サーバ９９０は、図１０の処理９１４から受信してデータセット９９４に保存したときに、データセット１２２０に保存されている「ｒｅｖ１」差分データみより、パッチを当てることにより元の「ｒｅｖ０」状態のファイルにパッチを当て、次いで、生成された「ｒｅｖ１」状態のファイルに、データセット９９４中の「ｒｅｖ２」差分データを使用してパッチを当て、次いで、生成された「ｒｅｖ２」状態のファイルに、同様にデータセット９９４中の「ｒｅｖ３」差分データを使用してパッチを当てることによって、様々な版数のファイルのコピーを維持することを回避することもできる。

処理９７４は、ローカルのファイルデータセット１７２０に、ファイルのコピー１７１０を書き込むものである。図１８を参照することで、より良く理解されるように、ユーザＤは、次に、処理９７４でファイルを修正し、「ｒｅｖ４」レベルのファイルのローカルコピー１８１０を保存し、「ｒｅｖ４」の差分を表す差分データ１８２０を、サーバ９９０に返送する。サーバ９９０は、この差分データをデータセット１８３０に書き込み、ユーザＤのコンピュータ１６３０のためのデータの維持が開始する。処理９７４は、ユーザＡ、Ｂ、Ｃをフ「ｒｅｖ４」ファイルの受信者として指定して、電子メールメッセージ１８４０を電子メールサーバ１０４０に送信する。

図１９に示すように、電子メールサーバ１０４０は、メッセージ１８４０のコピー１９１０、１９２０、１９３０を、コンピュータ１０２０、１０３０、１０４０に中継する。ユーザＡのコンピュータ１０２０は、差分データ１９１２をサーバ９９０から取得する。ファイルデータセット１０２４は、ファイルの「ｒｅｖ３」を含んでいるため、そこから「ｒｅｖ４」への差分データのみを要するものである。ユーザＢのコンピュータ１０３０およびユーザＣのコンピュータ１４４０は、コンピュータ１０３０のファイルデータセット１０３４とコンピュータ１４４０のデータセット１５５０の何れにも、直前の「ｒｅｖ３」レベルのファイルは含まれていないため、「ｒｅｖ４」レベルのファイルの完全な内容のデータ１９３２を取得する。

本発明の様々な態様に従う電子メール・ファイルアクセスの様々な望ましい特徴は、方法９００の間に使用することができる。例えば、図７を参照して上述したように、差分ファイル１２１２は、「ｒｅｖ０」レベルのファイルの個々のバイトと「ｒｅｖ１」レベルのファイルの個々バイトとの間の相違を実質的に示す指示データからなるものであってもよい。換言すれば、データ１２１２には、そのようなバイトの差分を除く（ファイルの内容に関連する）内容のどんなデータも含める必要がない。あるいは、図８を参照して上述したように、データ１２１２は、２つの版のファイルの内容の個々のブロックの間の差分を実質的に示す指示データからなるものであってもよい。

本発明の様々な態様従う協働的ファイル更新システムの動作の間に送信される電子メールメッセージは、図４、図５を参照して上述した種類の「Ｖｉｅｗｅｒ」フィールドおよび「Ｅｄｉｔｏｒ」フィールドを含むことができる。例えば、方法９００がそのようなメッセージ１０１２（図１０参照）を送信する場合、ユーザＢは編集者として、ユーザＢは、処理９３４（図１３）におけるファイル修正により分かるように、メッセージ１０１２参照するファイルを修正するように認証されているため、ユーザＢを編集者に指定している。メールサーバ１０４０がメッセージ１４２０、１４３０としてユーザＢおよびユーザＣに中継するメッセージ１４１０（図１４）は、ユーザＣはファイルを閲覧するだけであり修正しないため（図９、図１４、図１５、図１９の処理９５４、９５６の間）、ユーザＣをそのファイルの閲覧者として指定している。

本発明の様々な態様に従う協働的なファイルの更新を容易にするための方法では、複数のユーザの一人からファイルの初期バージョンを表すデータを受信して保存する。例示的な方法９００を参照して上述したように、サーバ９９０（図１０）は、ユーザＡのコンピュータ１０２０からファイルの初期バージョンを表すデータを受信する。例えば、方法９００におけるコンピュータ１０３０を有するユーザＢのように、初期バージョンの１人または複数の受信者が指定される。

次いで、ファイルの受信更新された複数のバージョンの１つのそれぞれに対して、複数のユーザの一人から、ファイルの更新されたバージョンと直前のバージョンとの間の差分を表すデータが受信される。例えば、サーバ９９０は、ユーザＢによって更新されたファイルの「ｒｅｖ１」とユーザＡによって作成された直前のファイルの「ｒｅｖ０」との間の差分データ１２１（図１２）を受信する。更新されたバージョンの一人または複数の受信者、例えば、方法９００（図９）の処理９３４において（電子メールメッセージ１２３０を介して指定された）ユーザＡが指定される。別の例として、「ｒｅｖ２」、「ｒｅｖ３」と順次的に更新された後、サーバ９９０は、更新された「ｒｅｖ４」バージョンとユーザＤのコンピュータ１６３０（図１８）からの直前の「ｒｅｖ３」との間の差分を表すデータ１８２０を受信する。この例では、メッセージ１９１０、１９２０、１９３０（図１９）として電子メールサーバ１０４０が中継する電子メールメッセージ１８４０は、ユーザＡ、Ｂ、Ｃをこの更新バージョンの受信者として指定している。

本方法において、更新された版の受信者として指定された各受信者に送信され、直ちに以前の版にアクセスされるデータは、ファイルの更新された版とファイルの以前の版との間に、実質的な相違がある。方法９00のプロセス９２０で、例えば、ユーザAが更新された“４版”の受信者として指定され、直ちに以前の版“３版”の受信者として指定されたので、サーバ９９０は、ユーザAのコンピュータ１０２０へ差分データ１９１２（図１９）のみを送信する。したがって、サーバ９９０はユーザB及びCへ更新されたものとしてファイルを示すデータ１９３２を送信し、そのためこれらユーザは、その版の作成者又は編集者、あるいはその版の指定された受信者のいずれかとして、ファイルの以前の版にアクセスできない。

“合作ファイル更新システム”の名称での米国仮出願60／486,708は、全体としてここに参考として含まれる。さらに、詳細な説明の好ましい実施形態は、ある特許および一般的に参照し得る特許出願の詳細な記述に言及しており、それら全てはここに参考として包含される。これら挙げられた特許あるいは出願中に参考として含まれる全ての米国特許および出願の詳細な説明の部分は、また、特に参考としてここに含まれる。

本発明及び特許請求の範囲の有効範囲に関する一般的注意

本発明は、好ましい実施形態及びこれに関連した方法について記載してきたが、本発明者は、好ましい実施形態及び方法の変形及び置換は、明細書を読み及び図面の調べることにより、当業者には明らかになるであろう。

さらなる構成は、このような構成または方法に関連しないで本発明の請求項に記載した種々の構成を実践しながら実行された付加的な方法を含むことができる。

従って、好ましい例示的な実施形態の上記記載または要約のいずれにも、本発明を限定しまたは制限するものではない。むしろ、特許請求の範囲に記載された内容が本発明を定めるものである。本発明の各変形例は、その請求項に記載の限定および等価物によってのみ制限されるものであり、請求項に表現されていない他の言葉によって制限されるものではない。

更に、本発明の構成は、技術用語を用いて特定されており、本発明者は、最も広い合理的な解釈を有するものと考える。
本発明者は、本発明のある実施に多分、絶対不可欠で有利なものとして、出願された特許請求の範囲に引用される特徴および方法の種々な要素を考慮している。しかしながら、本発明者は、特定の請求項に規定される場合を除き、“本質的”であるものとして特別な要素は何も注意していない。

図１は、本発明の様々な態様に従う電子ファイルアクセスシステムを概念的に示すブロック図である。用するイオン注入装置の概要を示す図である。 図２は、図１に示すシステムにおいて、ファイルデータを送信するための方法を示すフローチャートである。 図３は、図２の方法によって送信されたデータにアクセスするための方法を示すフローチャートである。 図４は、本発明の様々な態様に従う電子メールメッセージウィンドウの一例を示す図である。 図５は、本発明の様々な態様に従う電子メールメッセージウィンドウの別の一例を示す図である。 図６Ａは、メッセージエンコード・データストリームとして実現された、本発明の様々な態様に従う搬送信号を示す図である。 図６Ｂは、メッセージエンコード・データストリームとして実現された、本発明の様々な態様に従う搬送信号を示す図である。 図７は、本発明の様々な態様に従って、バイト差分法を使用して、ファイル修正の維持管理を実行するための処理を示すフローチャートである。 図８は、本発明の様々な態様に従って、ブロック差分法を使用して、ファイル修正の維持管理を実行するための処理を示すフローチャートである。 図９は、本発明の様々な態様に従う協働的ファイル更新システムの動作を示すフローチャートである。 図１０は、図９に示す様々な状態において、本発明の様々な態様に従う協働的ファイル更新システムを概念的に示すブロック図である。 図１１は、図９に示す様々な状態において、本発明の様々な態様に従う協働的ファイル更新システムを概念的に示すブロック図である。 図１２は、図９に示す様々な状態において、本発明の様々な態様に従う協働的ファイル更新システムを概念的に示すブロック図である。 図１３は、図９に示す様々な状態において、本発明の様々な態様に従う協働的ファイル更新システムを概念的に示すブロック図である。 図１４は、図９に示す様々な状態において、本発明の様々な態様に従う協働的ファイル更新システムを概念的に示すブロック図である。 図１５は、図９に示す様々な状態において、本発明の様々な態様に従う協働的ファイル更新システムを概念的に示すブロック図である。 図１６は、図９に示す様々な状態において、本発明の様々な態様に従う協働的ファイル更新システムを概念的に示すブロック図である。 図１７は、図９に示す様々な状態において、本発明の様々な態様に従う協働的ファイル更新システムを概念的に示すブロック図である。 図１８は、図９に示す様々な状態において、本発明の様々な態様に従う協働的ファイル更新システムを概念的に示すブロック図である。 図１９は、図９に示す様々な状態において、本発明の様々な態様に従う協働的ファイル更新システムを概念的に示すブロック図である。 図２０は、本発明の様々な態様に従うローカルストレージのアドレス指定可能なデータセグメントとして使用される階層化ディレクトリ構造を示すブロック図である。 図２１は、本発明の様々な態様に従うローカルストレージのアドレス指定可能なデータセグメントとして使用される階層化ディレクトリ構造を示すブロック図である。

Claims (36)

1. ファイルの協働的な更新を容易にするための方法であって、
   (a)複数のユーザの一人から、（i）第１のバージョンのファイルを表すと共に（ii）該第１のバージョンのファイルの一人または複数の受信者を指定する第１のデータセットを受信し、保存するステップと、
   (b)次いで、順次的に更新される複数のバージョンのファイルのそれぞれについて、
   （1）複数のユーザの一人から、（i）更新されたバージョンのファイルと直前のバー
   ジョンのファイルとの差分を表すと共に（ii）該更新されたバージョンのファイルの一人
   または複数の受信者を指定する第２のデータセットを受信し、そして、
   （2）前記更新されたバージョンのファイルを表す第３のデータセットを、前記第２
   のデータセットで指定された前記更新されたバージョンの受信者に送信するステップと、
   を含んでおり、
   (c)前記直前のバージョンのファイルにアクセスし、かつ、前記第２のデータセットで
   指定されたそれぞれの受信者のための前記第３のデータセットは、実質的に前記更新され
   たバージョンのファイルと前記直前のバージョンのファイルとの差分からなる、
   ことを特徴とする方法。
2. 前記第１のデータセットを受け入れる前に、
   (a)前記ファイルのオリジナルバーションを発生させる１人のユーザーを有し、
   (b)前記第１のバーションの前に前記ファイルの順次更新される複数のバーションを受け入れる、各ステップをさらに含むことを特徴とする請求項１記載の方法。
3. 更新されたバーションの各受信者が、前のバーションの受信者として指定されておらず、前記第３のデータセットが、実質的に更新された前記ファイルからなることを特徴とする請求項１記載の方法。
4. ディレクトリの階層構造内にデータファイルとして前記データセットを保存するステップをさらに含むことを特徴とする請求項１記載の方法。
5. 前記ファイルに関連した最もらしいユニークな識別コードを発生するステップを更に含み、各ディレクトリは、このディレクトリの名前の中に、前記識別コードの少なくとも一部分を含んでいることを特徴とする請求項４記載の方法。
6. 前記識別コードは、統計的に均一な分布を有するディジットを含んでいることを特徴とする請求項５記載の方法。
7. 複数のユーザーの各々に対して、前記ユーザーに関連した最もらしいユニークな識別コードを発生させ、各データファイルが、このファイルの名前の中に、前記複数のユーザーの一人と関連した識別コードの少なくとも一部分を含んでいることを特徴とする請求項４記載の方法。
8. 前記第２データセットの異なるデータは、異なるバージョンのデータ識別バイトを含んでいることを特徴とする請求項１記載の方法。
9. 前記第２データセットの異なるデータは、異なるバージョンのデータ識別ブロックを含んでいることを特徴とする請求項１記載の方法。
10. (a)複数のユーザーの全てにアクセス可能なファイルサーバーを設け、
    (b)第１、第２、及び第３のデータセットを受入れかつこれを伝送するファイルサーバーを有することを、更に含んでいることを特徴とする請求項１記載の方法。
11. (a)複数のユーザーの全てにアクセス可能なｅ−メールサーバーを設け、
    (b)前記複数のユーザーの間でｅ−メールメッセージを中継するｅ−メールサーバーを有し、前記ｅ−メールメッセージは、各々、指定された受信者が、前記ファイルサーバーからデータセットを読み出すことができるリファレンスを含んでいることを特徴とする請求項１０記載の方法。
12. リファレンスは、各々がダイレクトファイルアクセスモジュールを実行するコードを含むアタッチメントであることを特徴とする請求項１１記載の方法。
13. ｅ−メールメッセージは、それぞれメッセージを符号化したデータストリームを更に含み、このデータストリームは、一連のデータフレームを有しており、このデータフレームは、
    (a)メッセージ受信者フレームと、
    (b)ヘッダーを有するファイルビューワーフレームと、
    (c)ヘッダーを有するファイルエディターフレームとを含み、
    (d)少なくとも１つの前記ビューワーフレームと前記エディターフレームは、（1）前記ビューワーフレームに対して、前記ファイルを見るために認可されたビューワーを識別するデータを含み、（2）前記エディターフレームに対して、前記ファイルを修正するために認可されたエディターを識別するデータを含んでいること、
    を特徴とする請求項１１記載の方法。
14. ディレクトリーの階層構造内にデータファイルとしてデータセットを保存するステップを更に含むことを特徴とする請求項１０記載の方法。
15. 前記ファイルに関連した最もらしいユニークな識別コードを発生するステップを更に含み、各ディレクトリが、前記識別コードの少なくとも一部分に、前記ディレクトリの名前を含んでいることを特徴とする請求項１４記載の方法。
16. 前記識別コードは、統計的に均一な分布を有するディジットを含んでいることを特徴とする請求項１５記載の方法。
17. 前記複数のユーザーの各一人に対して分離したファイルデータセット内にデータを保存するファイルサーバーを有することをさらに含んでいる請求項１０記載の方法。
18. 複数のユーザーの各々に対して、前記ユーザーに関連した最もらしいユニークな識別コードを発生させ、各データファイルセットが、このファイルの名前の中に、前記複数のユーザーの一人と関連した識別コードの少なくとも一部分を含んでいることを特徴とする請求項１７記載の方法。
19. ファイルの協働的な更新を容易にする方法を実行するために、１以上のプロセッサに対する命令の証印を含んでいるデータ保存媒体であって、
    (a)複数のユーザーの一人を受け入れ、そして、(i)前記ファイルの第１バージョンを表わし、そして、(ii)前記最初のバージョンの一人以上の受信者を指定する、第１データセットを保存し、
    (b)その後、前記ファイルの順次更新された複数のバージョンの各々が、
    （1）前記複数のユーザーの一人から(i)前記ファイルの更新されたバージョンと前記ファイルの直前のバージョンとの間の差分を表わし、(ii)前記更新されたバージョンの１つ以上の受信者を指定する第２データセットを受入れ、
    （2）前記第２データセットによって指定された前記更新されたバージョンの受信者に前記ファイルの更新されたバージョンを表わす第３データセットを伝送する、各ステップを含み、
    (c) 前記ファイルの直前のバージョンをアクセスされ、前記第２データセットによって指定された各受信者に対して、前記第３データセットが、前記ファイルの更新されたバージョンと前記ファイルの前のバージョンとの間の差分からなることを特徴とするデータ保存媒体。
20. 前記第１のデータセットを受け入れる前に、前記第１バーションの前の前記ファイルにおける順次更新された複数のバーションを受け入れる、ステップをさらに含むことを特徴とする請求項１９記載のデータ保存媒体。
21. 更新されたバーションの各受信者が、前のバーションの受信者として指定されておらず、前記第３のデータセットが、更新されたものとして実質的に前記ファイルからなることを特徴とする請求項１９記載のデータ保存媒体。
22. ディレクトリの階層構造内にデータファイルとして前記データセットを保存するステップをさらに含むことを特徴とする請求項１９記載のデータ保存媒体。
23. 前記ファイルに関連した最もらしいユニークな識別コードを発生するステップを更に含み、各ディレクトリが、前記識別コードの少なくとも一部分に、前記ディレクトリの名前を含んでいることを特徴とする請求項２２記載のデータ保存媒体。
24. 前記識別コードは、統計的に均一な分布を有するディジットを含んでいることを特徴とする請求項２３記載の方法。
25. 複数のユーザーの各々に対して、前記ユーザーに関連した最もらしいユニークな識別コードを発生させ、各データファイルが、このファイルの名前の中に、前記複数のユーザーの一人と関連した識別コードの少なくとも一部分を含んでいることを特徴とする請求項２２記載の方法。
26. 前記第２データセットの異なるデータは、異なるバージョンのデータ識別バイトを含んでいることを特徴とする請求項１９記載の方法。
27. 前記第２データセットの異なるデータは、異なるバージョンのデータ識別ブロックを含んでいることを特徴とする請求項１９記載の方法。
28. 複数のユーザーの全てにアクセス可能なファイルサーバーにおいて、前記方法を実行し、さらに、第１、第２、及び第３のデータセットを受入れかつこれを伝送する前記ファイルサーバーを有することを、更に含んでいることを特徴とする請求項１９記載の方法。
29. ファイルの協働的な更新を容易にするためのシステムであって、
    (a)複数のユーザーの一人を受け入れ、そして、(i)前記ファイルの第１バージョンを表わし、そして、(ii)前記最初のバージョンの一人以上の受信者を指定する、第１データセットを保存する手段と、
    (b)前記ファイルの順次更新された複数のバージョンの各々が、
    （1）前記複数のユーザーの一人から(i)前記ファイルの更新されたバージョンと前記ファイルの直前のバージョンとの間の差分を表わし、(ii)前記更新されたバージョンの一人以上の受信者を指定する第２データセットを受入れ、
    （2）前記第２データセットによって指定された前記更新されたバージョンの受信者に前記ファイルの更新されたバージョンを表わす第３データセットを伝送するための手段と、を含み、
    (c) 前記ファイルの直前のバージョンをアクセスされ、前記第２データセットによって指定された各受信者に対して、前記第３データセットが、前記ファイルの更新されたバージョンと前記ファイルの前のバージョンとの間の差分からなることを特徴とするシステム。
30. 複数のユーザーの間でファイルのバージョンにおける伝送を管理する方法であって、
    (a)前記ファイルの第１バージョンを表す第１データセットを第１のユーザから受け入れて保存し、
    (b)第２のユーザが、前記第１バージョンに対するリファレンスを作動させた結果として、前記第２のユーザに前記第１データセットを伝送し、
    (c)前記ファイルの第１バージョンと第２バージョンとの間の差分を表わす第２データセットを前記第２のユーザーから受け入れて保存し、
    (d)前記第２のユーザが、前記第２バージョンに対するリファレンスを作動させた結果として、前記第１のユーザに前記第２データセットを伝送し、前記リファレンスが前記第２のユーザーから受け入れたｅ−メールメッセージ内に含まれており、
    (e) 第３のユーザーが、前記第２のユーザーから受け入れたｅ−メールメッセージ内に含まれている前記リファレンスを、前記第２バージョンに対して作動させた結果として、
    （1）前記ファイルの第１バージョンを第２データセットとパッチングさせ、これにより、前記ファイルの第２バージョンを表わす第３データセットを作り出し、
    （2）前記第３データセットを前記第３のユーザーに伝送する、各ステップを有することを特徴とする方法。
31. 前記複数のユーザーの各一人に対して分離したファイルデータセット内にデータを保存する、ステップをさらに含むことを特徴とする請求項３０記載の方法。
32. 前記複数のユーザーの各々に対して関連した最もらしいユニークな別個の識別コードを発生させ、各データファイルが、このファイルの名前の中に、それぞれの識別コードの少なくとも一部分を含んでいることを特徴とする請求項３１記載の方法。
33. 複数のユーザーの間でファイルのバージョンにおける伝送を管理する方法を実行するために、１以上のプロセッサに対する命令の証印を含んでいるデータ保存媒体であって、前記方法が、
    (a) 第１のユーザーから受け入れた、前記ファイルの第１バージョンを表わす第１データセットを保存し、
    (b) 第２のユーザーが前記第１バージョンに対するリファレンスを作動させた結果として、前記第２のユーザーに前記第１データを伝送し、前記リファレンスが前記第１のユーザーから受け入れたｅ−メールメッセージに含まれており、
    (c)前記ファイルの第１バージョンと第２バージョンとの間の差分を表わす第２データセットを前記第２のユーザーから受け入れて保存し、
    (d)前記第１のユーザが、前記第２バージョンに対するリファレンスを作動させた結果として、前記第１のユーザに前記第２データセットを伝送し、前記リファレンスが前記第２のユーザーから受け入れたｅ−メールメッセージ内に含まれており、
    (e) 第３のユーザーが、前記第２のユーザーから受け入れたｅ−メールメッセージ内に含まれている前記リファレンスを、前記第２バージョンに対するリファレンスを作動させた結果として、
    （1）前記ファイルの第１バージョンを第２データセットとパッチングさせ、これにより、前記ファイルの第２バージョンを表わす第３データセットを作り出し、
    （2）前記第３データセットを前記第３のユーザーに伝送する、各ステップを含んでいることを特徴とするデータ保存媒体。
34. 前記方法は、複数のユーザーの各一人に対して別個のファイルデータセット内にデータを保存するステップを更に含むことを特徴とする請求項３３記載のデータ保存媒体。
35. 前記方法は、前記複数のユーザーの各一人に対して関連した最もらしいユニークな別個の識別コードを発生させ、各データファイルが、このファイルの名前の中に、それぞれの前記識別コードの少なくとも一部分を含んでいることを特徴とする請求項３４記載のデータ保存媒体。
36. 第１、第２、及び第３のユーザを含む複数のユーザーにアクセス可能なファイルサーバーであって、
    (a)第１のユーザーから受け入れた、前記ファイルの第１バージョンを表わす第１データセットを保存する手段と、
    (b)前記第１バージョンに対するリファレンスを作動させた第２のユーザーに応答し、前記リファレンスが前記第１のユーザーから受け入れたｅ−メールメッセージ内に含まれ、前記第２のユーザーに前記第１データセットを伝送するための手段と、
    (c)前記第２のユーザーから受け入れた、前記ファイルの第１バージョンと第２バージョンとの間の差分を表わす第２データセットを保存する手段と、
    (d)前記第２バージョンに対してリファレンスを作動させた第１のユーザーに応答し、前記リファレンスが前記第２のユーザーから受け入れたｅ−メールメッセージ内に含まれ、前記第１のユーザーに前記第１データセットを伝送するための手段と、
    (e)前記第２バージョンに対してリファレンスを作動させた第２のユーザーに応答し、前記リファレンスが前記第２のユーザーから受け入れたｅ−メールメッセージ内に含まれ、
    （1）前記ファイルの第１バージョンを第２データセットとパッチングさせ、これにより、前記ファイルの第２バージョンを表わす第３データセットを作り出し、
    （2）前記第３データセットを前記第３のユーザーに伝送する手段と、を含むことを特徴とするファイルサーバー。
    
    

Images