JP2001503537A - オンラインデータリポジトリの変更データの識別 - Google Patents

Abstract

(57)【要約】 バージョン毎にその内容が変更する遠隔のリポジトリ内の文書にアクセスするためのシステム。このシステムは、ユーザーが関心のある文書のリストを指定することを可能にし、そのリストに基づいて、リストに挙げられた各文書の１バージョンのコピーと、他のバージョンを再構築するのを可能にする内容とを含むアーカイブを保持する。上記システムは、リポジトリ内の文書の最新バージョンとアーカイブを周期的に比較し、アーカイブを更新することで、最新のバージョンを再構築する機能を保持する。上記システムはまた、各ユーザーのバージョンへのアクセスをモニタする。ユーザーが最新バージョンを要求すると、上記システムは最新バージョンを提示し、その最新バージョンのどの部分にユーザーがこれまでアクセスしていないかを示す。

Description

【発明の詳細な説明】 オンラインデータリポジトリの変更データの識別 本発明は、データリポジトリから検索した文書の最新バージョンの提示（プレ ゼンテーション）に関する。この提示は、閲覧者が前のバージョンにアクセスし てからのその文書の変更を示すものである。 発明の背景 コンピュータ化されたシステム内に記憶された情報は、通知することなく頻繁 に変更する可能性がある。例えば、開発中のソフトウェアには多くの人が関わる ことが多く、一般に中央の記憶位置に記憶されている。それに関わる人は各自、 他人に知らせることなくそれぞれソフトウェアを思いつくままに変更することが できる。 変更可能なデータを含むこのようなシステムでは、一般に、任意の日に情報を 調べる人は、前回調べてからその情報が変更されたかどうか、そしてどのように 変更されたかは知らないため、最新の情報を前のバージョンの情報と比較するの に時間を費やさなくてはならない。 この比較を簡単にするためのソフトウェアが存在する。例えば、「バージョン 制御システム」または「改訂制御システム」として知られるシステムは、図１Ａ に示されるように、様々な文書の多数のバージョンを表すデータを記憶する。こ の図には、点線の枠内に示されるバージョンとともにデータが図示される。 この枠は、バージョンが これよりもかなり大きな文書に散在している。小さな矢印が変更を示し、この場 合には主に追加点である。「最終更新」日の変更は、テキストが置き換えられる 例を示す。ここでは、ページ作成者は、小さなアイコンを伴ってマニュアルで変 更を強調させている。ページの上部のバナー（見出し）は、HTMLDIFFによって挿 入されたものである。 図１２は、バージョンの履歴を示しており、これによってユーザーは任意の二 つのバージョンを比較したり、選択したバージョンに直接アクセスできる。 図１３は、W3NEWERの出力を示し、いくつかのアンカー（記述テキストはホッ トリストから生じる）を示す。「変更した」と示されたアンカーは、ユーザーの ブラウザの履歴によってそのＵＲＬを最後に見てからの変更日を伴う。ＵＲＬの 中には全くチェックされないものもあるし、チェックされ、ユーザーに見られた ことがわかっているものもある。 図１４は、ユーザーがＵＲＬに対する動作を指定するのを可能にするSNAPSHOT 機能の使用法を示す。この例では、DOUGLIS@RESEARCH.ATT.COMが、HTTP://SNAPP LE.CS.WASHINGTON.EDU:600/MOBILE/というＵＲＬを「記憶」している。 発明の詳細な説明 本明細書の末尾の「技術面の補遺」に本発明が詳細に説明されている。その後 に本発明の一形態を実現するコードを含むコンピュータプログラムリストを添付 している。 本発明の例示的な実施形態を以下に説明する。 発明の概説 一般的に使用されている情報リポジトリは、ワールドワイドウェブ(World Wid e Web)、すなわちＷＷＷとして知られている。ＷＷＷでは、情報提供者によって ユーザーが「ページ」の形態でその情報を入手できるようにされる。各ページに は名前が割り当てられており、それによって他のページと区別し、ユーザーがそ のページの位置を突き止められるようにする。 ＷＷＷは、「ハイパーテキスト」と称する情報検索および表示法を用いて情報 を提供する。ハイパーテキストでは、ページは他のページまたは他の文書への参 照を含む。ユーザーは、ポインティングデバイスでその参照部（Universal Reso urce Locator;URL)をクリックすることによって参照するページを呼び出すこと ができる。図１Ｂにその一例を示す。 図１Ｂにおいて、文書Ｄがユーザーに表示される。参照部Ｒは他の文書への参 照を与える。例えば、Ｒ１はＤ１への参照を与え、Ｒ２はＤ２へ、という具合で ある。参照された文書自体もまた他の文書への参照を含む可能性があり、例えば Ｒ４はＤ４への参照を与える。 ユーザーは、参照する文書Ｄに対する参照部Ｒをクリックすることによってそ の文書を検索することができる。例えば、Ｒ１をクリックするとＤ１が検索され 、これが表示される。 本発明によると、ＷＷＷのユーザーは最初に自分が関心のあるページを特定す る。図１Ｂの文書Ｄは、あるページを表している。これらの選択されたページが 「ホットリスト」を形成する。次に、本発明では以下のことを行う。 （ａ）ホットリストに挙げられたページをアーカイブにコピーする。アーカイブ とは、ＷＷＷとは別個の記憶位置であり、独立して制御される。コピーした後も 、元のページはＷＷＷ内に存在し続け、コピーはアーカイブ内に存在する。 （ｂ）その後の元のページの変更をモニタし、その変更をアーカイブする。 （ｃ）その後ユーザーがホットリストに挙げられた各ページにアクセスした時間 を記録する。 （ｄ）ユーザーがホットリストに挙げられたページにアクセスする度に、ユーザ ーに以下を提示する。 ｉ）ページの最新バージョン（これはアーカイブ内に記憶された最初のコピ ーとは異なる可能性がある） ｉｉ）ページの選択されたバージョンを比較するオプション。この比較は、 バージョン対に対する差異特定動作を行うことによって実現される。 （ｅ）オプションとして、本発明ではページによって参照された文書に対しても 上述のステップを実施する。例えば、図１Ａにおいて、ユーザーが文書Ｄを見て いるとすると、本発明では参照文書Ｄ２の最新バージョンをＤ２の履歴とともに 提示することができる。 より詳細な説明 ホットリストに挙げられたページの外部サービスへの記憶 図１は、ＷＷＷ等の情報リポジトリを示す。リポジトリにアクセスするのを補 助するため、本発明は以下を含む外部サービスを提供する。 （ａ）添付のコンピュータプログラムリストに見られるようなソフトウェア （ｂ）そのソフトウェアを実行するサーバー、または他のコンピュータ （ｃ）ユーザーとリポジトリの双方をリンクする通信システム 外部サービス内に配置されるサーバーおよび通信システムは当該分野では周知で ある。図に示されるように、外部サービスはリポジトリとは別個のものであり、 別々に制御される。 本発明はユーザーのリポジトリとの通常の対話（インタラクション）を妨げる ものではなく、ユーザーは通常通りリポジトリと対話できるのに加えて、外部サ ービスとも対話できる。本発明の例示的な動作態様をいくつか例を挙げて説明す る。 例：シングルユーザー まず、ユーザーが一人である（シングルユーザー）場合の動作を説明する。図 ２は、ユーザー１によって提出されたホットリスト４を示し、ユーザー１がペー ジＡおよびＢに関心を示していることを特定している。本発明によると、ユーザ ーが後でホットリストを変更することも許可する。本発明によると、点線の矢印 で示されるように、ホットリストに応じてリポジトリからページＡおよびＢがコ ピーされる。これらのページを「基本ページ」と称する。このときページＡおよ びＢのオリジナルはリポジトリ内に存在し、コピーは外部サービス内に存在する 。 次に、本発明によると、リポジトリ内のページＡおよびＢのオリジナルの変更 について周期的に調べる。変更点を探す際に、本発明ではまず、（１）変更日、 および（２）チェックサム、等の情報に基づいて予備チェックを行う。 変更日は、ページの提供者によってページに加えられることもある。これらの 日付は、最初にアーカイブされたバージョンが変更したかどうかを直接示すもの である。 チェックサムは本発明によって生成される。チェックサムの一例としては、１ 行または１ページ内のすべての文字の数の和が挙げられる。チェックサムが変わ ると（つまり文字数が変わったことを示すと）、その変更はページ内に変更があ った確率が高いことを示す。（実用において使用されるチェックサムはこの単純 な例よりも複雑である。チェックサムは当該分野では周知である。） 変更日またはチェックサムによる予備チェックで変更があったことが示される と、本発明では、そのページの現在のバージョンを外部サービスへとコピーし、 それを基本ページと比較して、変更箇所を突き止める。このような変更を検出す るためのコンピュータプログラムは当該分野では既知であり、その例のいくつか を「技術面の補遺」に挙げている。従来知られていない好適なプログラムはW3NE WERと称するもので、本願発明者らによって開発された。W3NEWERは、本明細書の 末尾のリストに含まれている。 変更を見出すと、本発明ではそれを外部サービスに記憶する。図３は、ページ ＡおよびＢの下の小さなボックス６によって変更の記憶を示す。ボックス６内の 日付は、変更がセーブされた日付を表す。 図３Ａは、本発明においてバージョンの履歴をどのように表示するかを示す。 コラム７は、本発明によって各バージョンに割り当てられた番号を示し、コラム ８は、本発明によって各バージョンが検索された時間を示す。コラム８Ａにより 、以下に説明するようにユーザーは差異特定動作を行うバージョン対を選択する ことができる。 説明を簡単にするために、図３はページの初期のバージョンである基本ページ とボックス６で示されるその後の変更との記憶を図示しているが、実用において は、（初期のバージョンではなく）最新バージョンを基本ページとして記憶し、 変更６を記憶してそこから初期のバージョンを再構築するといった、逆の方法で 記憶を行う方が効率的なこともある。その理由の一つは、ユーザーが初期のバー ジョンよりも最新バージョンを求めることの方が多いと考えられることである。 最新バージョン全体を記憶することによって、それを再構築する必要がなくなる 。 変更とその基本ページがアーカイブを形成し、これによってどの希望の日付の ページも再構築できる。例えば、 −− ページＡ自体（すなわち基本ページ）と日付１で示される変更によって 日付１の時点でのページＡのバージョンを再構築できる。 −− ページＡ自体と、日付１および日付２で示される変更とによって日付２ の時点でのページを再構築できる、という具合である。 ユーザー１がページＡを見たい場合には、本発明では通常最新バージョンを検 索して提示する。本発明はまた、ユーザーが指定した日付のページを再構築する オプションも提供し、図４に示されるフォーマットでこれを提示する。リストに あるプログラムHTMLDIFFによって図４の画像を生成する。ページの内容は３つの クラスに分類することができる。 第１のクラスは、変更されていない内容を含むものである。このクラスの内容 は、リポジトリからダウンロードされる文書の通常のフォント、サイズ、色、お よび背景で表示される。 第２のクラスは変更を表し、基本ページにはなかったもので追加された内容を 含むものである。括弧９で係る内容を示す（括弧９は図４の一部であり、必ずし も本発明によって生成するページの一部ではない）。この内容は、特定のフォン ト、特定のサイズ、特定の色、そして特定の背景で提示される。これらのパラメ ータの選択は様々であってよいが、一般には第１のクラスの内容とのコントラス トを最大にするように選択すべきである。上記のフォーマッティングに加え、追 加された内容はさらに矢印７で強調される。 第３のクラスは、基本ページから削除された内容を含む。削除された内容は少 なくとも３つの方法で処理することができる。１つは、削除された内容は単に削 除し、読み手に提示されるページが削除された内容への参照を含まないようにす るものである。 ２つ目として、削除された内容は削除するが、「削除された内容はここで表示 される」等の文で削除を示す参照を追加してもよい。この場合には、削除された 見えない内容を取り出すオプションをユーザーに与えることができる。 ３つ目として、削除された内容を提示し、削除された内容に赤などの横線を引 く「レッドライン」フォーマット等によって削除されたことを示してもよい。 図３Ｂは、本発明によって生成される表示であり、ユーザーのホットリストに あるページが変更を受けたことを示している。 第２例：ユーザーが複数の場合 実用では、複数のユーザーが本発明を利用すると考えられ、各自がホットリス トを提出する。本発明の手法の一つでは、ユーザーが複数の場合に対してもシン グルユーザーの場合（先に説明した）にとった手順を繰り返す。すなわち、上述 のように、全ホットリストの全ページを外部サービスにコピーし、各ホットリス トについて、リポジトリにあるページのオリジナルの変更をモニタし、その変更 を外部サービスへと取り込む。 しかし、この手法には非効率な点がある。例えば、あるページが２つ以上のホ ットリストで指定される可能性がある。そのページを各ホットリストについて繰 り返しコピーすると同じページの複数のコピーを記憶することになる。さらに、 その複数のコピーをリポジトリ内のオリジナルと繰り返し比較するのはコンピュ ータの時間の無駄であり、一回比較すれば十分である。本発明は、図５に示され る手法によってこれらの非効率な点を改良する。 この図は図４にユーザー２のためのホットリストを加えることでこれを変形し たものである。追加されたホットリストはページＡとＣを指定している。 新しいホットリストを処理するために、本発明では、追加されたホットリスト で指定されたページが外部サービス内にアーカイブされているかどうかをまずチ ェックする。ページＡはその変更とともにすでにアーカイブ内に含まれているた め、このページはコピーされない。しかし、ページＣはアーカイブ内に存在しな いため、点線の矢印で示されるようにアーカイブされる。 この時点で、全ホットリストで指定された全ページがアーカイブ内に含まれる 。このことを強調するために、ページＡは、１回目はユーザー１のために、そし て２回目は点線のページ１４で示されるようにユーザー２のためにと２回示され ているが、上述のようにページＡは一度しか記憶されない。 必要なページをすべてアーカイブした後、上述のように、リポジトリ内のオリ ジナルの変更について周期的にモニタする。変更は外部サービスのアーカイブに コピーされる。 フローチャート シングルユーザーの場合の例示的なフローチャートが図６に示される。ブロッ ク２０において、外部サービスはユーザーからホットリストを受け取る。次に、 ブロック２３で、外部サービスはホットリスト上で指定されたページがアーカイ ブ内にあるかどうかをチェックする。もしなければ、ブロック２６で示されるよ うにリポジトリからページがコピーされる。 次に、論理はブロック２９へと進み、ここでリポジトリ内のページのオリジナ ルの変更について調べる。この調査は、上述の予備チェック（チェックサムと変 更日についてのチェック）を含み得る。変更が見つかると、それらを含むページ 全体が外部サービスにダウンロードされ、図３のブロック６で示される変更が導 出される。ブロック３２は、外部サービスに記憶された関連情報を示す。 ユーザーが各ページのどのバージョンを最後に見たかを特定するために、ユー ザーがページにアクセスすると、ブロック３５でアクセス時間をモニタする。ブ ロック３２および点線矢印３７で示されるように、これらの時間は、記憶され、 これを利用して、各ユーザーによってページが呼び出されると図４のどの変更を 新しい内容として特定すべきかを判断する。以下に一例を挙げる。 図７の上部はページＡに対して行われた変更の時間的履歴を示す。ユーザー１ は、図示の通り、このページに時間２でアクセスしている。図６のブロック３５ でこの時間をモニタし、これを記録する（もちろん図７の時間２においてであり 、これより早くには行われない）。 ユーザー１が時間５でこのページに再びアクセスすると、本発明ではユーザー にバージョン１を提示する。しかし、ユーザーが時間１１でこのページにアクセ スすると、ユーザー１の最後のアクセス時からバージョン２がすでに形成されて いる。本発明ではすでに変更を特定して、図３で示されるようにこれらをコピー している。そこで、本発明では、時間１１でのアクセス時に、図６のブロック３ ５でユーザーがバージョン２を見ていないことが示されるため、バージョン１と その変更とを提示してバージョン２を形成する。 ここで図６のフローチャートに戻って、ブロック３９で、ユーザーがページを 要求すると、本発明では最新バージョンを提示し、ユーザーがそのページに最後 にアクセスしたときから行われた変更を（図４のように）示す。上記の例では、 本発明は図７のようにページＡのバージョン２を提示し、ユーザー１が最後にア クセスしたのはバージョン１であるため、バージョン１から行われた変更を示す 。 図６のフローチャートは、本発明を線形かつ逐次的な動作モードに制限するも のではない。実用においては、複数のユーザーが同時にホットリストを提示する 可能性があり、フローチャートに示されるもの以外の動作も同時に起こりうるも のである。 第３例：変更の通知 本発明では、ユーザーがホットリストに挙げたページに変更があると、図６の 点線のブロック４０に示されるように、ユーザーにこれを知らせることができる 。この通知は、図８の基本ページと関連するフラグの形態をとっても良い。ユー ザーが外部サービスにログインすると、本発明では、ユーザーにそれぞれのペー ジの変更を知らせる。図３Ｂは、変更したページを特定する手法の一つを示す。 他のタイプの通知も可能である。例えば、本発明では、ユーザーがページにア クセスするのを待つ必要はなく、変更が見つかるとユーザーに電子メールメッセ ージを送ることでユーザーに知らせることができる。 第４例：共通のホットリスト 本発明では、ユーザーの一集団（コミュニティー）に対して所定のホットリス トを維持することができる。このホットリストは、その集団の一般的な関心事で あると考えられるページのリストを含む。このホットリストとそれに指定された ページは、すべてのユーザーに対して公開されるが、読み出し専用である。ユー ザーがホットリストまたはページを変更することはできない。 この所定のホットリストは教育ツールとして役立てることもでき、本発明の動 作についてユーザーを教育したり、所望の特徴を説明したりしても良い。 データ記憶のアーキテクチャ 図６のフローチャートのブロック３２に示される情報を記憶する手法の例が図 ８に示されており、これを図７を参照して説明する。 図７は、図５の２つのホットリストで特定された３つのページに対して行われ た仮定上の変更を示す。ページＡは時間７および１３で変更されており、ページ Ｂは時間１０で変更されており、以下同様である。 図７において、「ユーザー１」等の文字から延びる矢印は、ユーザーによるア クセスの時間を示す。例えば、ユーザー１は時間２でページＡのバージョン１に アクセスしており、次に時間９でページＡのバージョン２にアクセスしている。 以下も同様である。 本発明では、図８の右側に示されるように、これらの時間の表と、各ユーザー が所有する文書またはページのリストとを保持する。所有者は、ホットリストに よって決定される。本発明ではさらに、この図の左側に示されるように、（ａ） 基本ページと、（ｂ）その各々に対する変更と、（ｃ）各変更の時間とを保持す る。このデータから、本発明では基本ページの日付以降のどの日付のどのページ も再構築することができる。 補足 １．「ページ」の一定義は、それが特定の名前によって特定されるシステム内 に記憶されたデータの単位を指すというものである（ＷＷＷでは各ページが一意 的な名前を持つ）。「ファイル」や「文書」といった他の用語もこのようなデー タ単位を指し得る。一般に、使用する特定の名前は、データを記憶するシステム に依存する。 ２．「リポジトリ」の一定義は、コンピュータによってアクセス可能なデータ の集まりである。リポジトリは公開されても良いし、アクセスを制限しても良い 。一般に、リポジトリは分散していると考えられる。つまり、記憶位置は地理的 に広範囲にわたって物理的に分散しており、通信システムによって互いにリンク されると考えられる。 ３．本発明が任意の選択日のページを再構築できることについては上述したが 、この再構築は、図３の変更６に基づく。これらの変更は周期的に検出され、そ の周期は、設計者およびシステム管理者が課す制限のもと、システムの各ユーザ ーによって決定される。 例えば、ユーザーＡがそのホットリストのページの変更をチェックするのに一 日という周期を指定するのに対して、ユーザーＢはＢのページについて例えば一 週間という違う周期を指定しても良い。システム管理者は、どのユーザーについ ても１時間未満の周期にはしないように指定することができる。 この結果、リポジトリ内のページの変更は、変更が検出された後で外部サービ スが行う再構築において現れるのであって、これより早くには現れない。この違 いを示す一例を挙げる。 例えば、本発明で奇数日に変更を調べると仮定する。すると、ある月の４日に 起こった変更は５日に検出される。しかし、ユーザーがたまたま４日に再構築を 求めると、４日に起こった変更は再構築の際には現れない。その前の検出時、す なわち３日に起こった変更のみが現れる。 このことによる影響が無視できる程度となるくらい十分に頻繁に検出処理が行 われることが望まれる。 ４．本発明の差異特定機能（すなわちページの変更を調べること）を、ユーザ ーがアクセスしたページによって参照したページにまで拡張することができる。 例えば、ユーザーが図１Ｂの文書Ｄにアクセスすると、本発明により、文書Ｄに よって参照されたすべての文書、例えば、Ｄ１、Ｄ２、Ｄ３等の変更を検出する ことができる。 別の実施形態として、この差異特定を、参照された文書によって参照された文 書にまで拡張することもできる。例えば、参照された文書（Ｄ１、Ｄ２、および Ｄ３）がＤ５およびＤ６を参照すると、これらの文書（Ｄ５およびＤ６）に対し ても差異特定を行い、さらにこれらが参照した文書に対しても同様に差異特定を 行うことができる。 ５．本発明では、ページの最新バージョンを得るもととなった情報すべてを提 供する。図４にその一例を示す。図４は、このようなすべての情報とともに、前 のバージョンからの変更を示す他の情報も含む。 ６．これまで、ページの異なるバージョン間の比較すなわち差異特定が外部サ ービスで行われるものとして説明してきたが、必ずしもその必要はなく、比較は いかなる好都合な位置で行われても良い。さらに、変更の有無についての予備チ ェックもいかなる好都合な位置で行われても良い。 ７．データ記憶システムにおいて、情報単位に名称が付けられるが（例えば、 文書、ページ、レコード）、この名称はデータベース毎に異なっていても良い。 しかし、一般にこの単位の名称は、単位内に含まれる情報に変更が加えられても 時を問わず同じである。従って、「バージョン」という言葉の一定義は、同じ名 称の前の単位とは異なる情報の単位である。 ８．図１内のリポジトリは、一般に外部サービスから遠隔の位置にある。その 通信は、インターネット等の公衆アクセス通信ネットワーク等の何らかの好都合 な方法で行われる。 一般に、リポジトリは外部サービスとは別個に制御される。この独立制御の結 果の一つとして、外部サービスにコピーされたページに対して行われるタイプの 処理は、リポジトリではなく外部サービスによって制御される。例えば、（ａ） 相違点を特定して記憶するのに用いる特定のプロセス、（ｂ）処理の頻度、およ び（ｃ）ユーザーへの通知モードは、外部サービスの設計者によって制御される 。リポジトリのオペレータはこの処理には関与しない。 ９．図９は、本発明の別の形態を示す。本発明では、ホットリスト３６に要求 されるように外部サービス内に基本ページ３０を保持する。基本ページ３０は、 それぞれのリポジトリ４２Ａ、４２Ｂ等からダウンロードされている。 本発明ではリポジトリ４２内のページのオリジナル３０Ａの変更について周期 的にモニタし、その変更を外部サービス内に記憶する。本発明では、ユーザーの ホットリストのページに変更があればユーザーに通知する（通知は図示されてい ない）。 バージョン制御システム３９によって、ユーザーはどのページのどのバージョ ンも取り込み、それを見ることが可能となる。 １０．文書の様々なバージョンは、図や、音が生成されうるファイル、ビデオ クリップおよびアニメーションを生成するファイル、および厳密には英数字から なるわけではない他の要素を含みうる。本発明では、これらの要素における変更 の有無を検出し、変更の性質については必ずしも詳細に特定することなく、その 変更の有無を図４に示されるような表示で示す。 １１．本発明の主な使用法を図１０に示される状況で表す。外部サービスはＷ ＷＷ等のリポジトリからページのコピーを得るが、外部サービスにはリポジトリ 内に含まれるページを交換または変更する権限はない。外部サービスに関しては 、書き込み動作を示す矢印５０にＸが付されているように、ページは読み出し専 用データを表す。 外部サービスは、コピーしたページの最新バージョンと前のバージョンを表す データの差異特定を行う。外部サービス内に記憶されたデータは、外部サービス によって読み出されることも書き込まれることも可能である。外部サービスは、 上述のように、要求に応じてどのバージョンも再構築し、ユーザーが選択した任 意の２つのバージョン間の相違点を示す。これらの機能は、従来の改訂制御シス テムＲＣＳ（バージョン制御システムとも称する）によって、または本明細書中 のリストにあるコードによって達成できる。 １２．本発明の一形態では、検索ページはハイパーテキストマークアップ言語 （ＨＴＭＬ）等の「マークアップ言語」で書かれている。一般に、マークアップ 言語は、実際の文書テキストに散在する２種類のコードを含む。 そのうち１種類は、ページの表示のしかたを示す。例えば、コードの中には、 段落のインデント（字下げ）を示すものや、フォントスタイルを示すもの、さら に、斜字体、下線、二重文字(double-striking)、太字等のフォントにおけるフ ォントスタイルを示すものがある。この種のコードはフォーマット定義型といわ れる。 第２の種類のコードは、その他の位置にあるビットマップファイル等の画像を 特定できるものである。ページを表示するシステムによってこのようなコードが 読み出されると、画像のコピーが検索されてページ内のコードに指定された位置 で表示される。この種のコードはコンテント定義型といわれる。 本発明では、フォーマット定義コードの変更は内容における変更のようには扱 われない。従って、レイアウトまたはタイプスタイルのみが変わっているページ は変更されたページとしては指定されない。 コンピュータプログラムリスト内の差異特定プログラムは、異なるバージョン をサブユニット毎に比較する。たとえば、このプログラムは異なるバージョン内 の対応する文を比較し、その文は終止符によって検出される。（段落やページ等 のより長いサブユニットを用いても良い。）終止符は、マークアップ言語のサブ セットであり、具体的には、フォーマット定義コードである。 コンピュータプログラムリスト プログラムリストは３つのセクションに分かれている。 １．以下を含むHTMLDIFF −− html_diff.sml（５ページ） −− diff.sml（３ページ） −− mlweb.sml（４ページ） −− html.lex（１ページ） ２．W3NEWER（１７ページ） ３．以下を含むNOHANDS −− nohandsBE（１１ページ） −− no-hands.cgi（３ページ） −− rcsdiff.cgo（４ページ） −− snapshot.cgi（３ページ） NOHANDSは、W3NEWERとHTMLDIFFを利用する包括的なプログラムセットである 。 技術面の補遺 全１２ページの技術面の補遺を添付する。その内の２ページは白紙であり、ま た補遺中の図は本明細書の図１１−１４を参照する。 本発明の真の精神および範囲を逸脱することなく数々の変更および変形を行う ことが可能である。特許証によって保護したいのは以下の請求の範囲に定義され る発明である。 技術面の補遺 ウェブ上の変更の追跡および表示 要約 ワールドワイドウェブのページがいつ変更されたかを検出し、マークアップＨ ＴＭＬでユーザーに視覚的にその変更を提示するツールについて説明する。ツー ルは３つの要素からなる。すなわち、ページの変更を検出するW3NEWERと、ユー ザーが任意のウェブページのコピーを記憶させ、ページのその後のバージョンを そのセーブしたバージョンと比較することを可能にするsnapshotと、ＨＴＭＬテ キストが前のバージョンからいかに変更したかを示すようにこれをマークアップ するhtmldiffとからなる。これらのツールをまとめて、NO HANDS(Network-Orien ted HTML Archival，Notification，and Differencing System;ネットワーク指 向ＨＴＭＬアーカイブ、通知、および差異特定システム)と称する。この論文で は、スケーラビリティ、セキュリティ、エラー状態等のシステムの問題に重点を 置いて、NO HANDSのいくつかの特徴について説明する。 １．はじめに ワールドワイドウェブ（Ｗ³）の利用は、トラフィックの量の面でもユーザー および内容提供者の多様性の面でも、この数年で劇的に増大した。Ｗ³は、学究 的環境（そのそもそものきっかけとなった分野である）、商業的環境、そして様 々な分野で関心をともにする人々の仮想コミュニティにとっての情報提供媒体と なった。メーリングリストまたはニュースグループを購読しているユーザーに対 するアクティブメディアである電子メールまたはUSENETを介してこれまで送られ ていた情報を現在はＷ³ページ上で公表することができる。そのデータに関心の あるユーザーはそのページにアクセスして、新しい情報を得るのである。 ユーザーにとって関心のあるページのＵＲＬは「ホットリスト」(Netscape^TM ではブックマークファイルとして知られている)にセーブすることができ、その ページにアクセスするのが便利になっている。では、ページがいつ変更されたか をユーザーはどのように見出すのだろう。ページが最新のデータ（例えば株式相 場）を含んでいたり、その所有者によって頻繁に変更されることをユーザーが知 っていれば、そのページに頻繁にアクセスするであろう。しかし、そうでないペ ージは、無視されたり、またはブラウズしても変更されていなかったりすること がある。 最近、いつページが変更されたかを判断する問題に対処するためのツールがい くつか利用できるようになった。このようなツールの一例が、webwatchである。 これは、Windows^TM用の製品であり、HTTPのHEADコマンドを用いてページがユー ザーのウェブブラウザによって最後に閲覧されてからいつ変更されたかを見出し 、ユーザーがその更新されたページに直接アクセスするのを可能にするレポート をＨＴＭＬで生成する。別の例は、UNIX^R上で動作するパブリックドメインperl スクリプトであるBrooks CutterのW3NEWである[2]。 これらの各ツールには重大な欠点がある。すなわち、ユーザーにページが変更 されたことを知らせるものの、そのページがどう変わったかは示さないのである 。ページの中にはその保守者(maintainer)が最も最近の変更を強調するように編 集するものもあるが、特にページが大きければ、変更が目立たない場合が多い。 最近の変更を特に強調しているページでも問題があり、ユーザーがページに頻繁 にアクセスしていると、保守者にとって「新しい」ものもユーザーにとっては「 新しい」わけではない可能性がある。逆に、ページにそう頻繁にはアクセスしな いユーザーは保守者が古いと判断した変更を見落とす可能性がある。 本願発明者らは、ページがいつ変更したかを効率的に追跡し、ユーザーごとに ^TM Netscapeは、Netscape Communications社の商標である。^TM Windowsは、Microsoft社の商標である。^R UNIXは、X/Openの登録商標である。 バージョンをコンパクトに記憶し、ページ同士を自動的に比較してその相違点を 提示するシステムを開発した。NO HANDS(Network-Oriented HTML Archival，Not ification，and Differencing System:ネットワーク指向ＨＴＭＬアーカイブ、 通知、および差異特定システム)は、３つのツールでＷ³ページのバージョンの「 個人化された」ビュー（表示）を提示する。その第１のw3newerは、CutterのW3n ew変更追跡ツールよりもスケーラブルであって、周期的にＷ³にアクセスしてユ ーザーのホットリスト上のページがいつ変更されたかを見出す。第２のsnapshot は、ユーザーがページのバージョンをセーブし、後に第３のツールhtmldiffを使 ってそれがどのように変更したかを知ることを可能にする。htmldiffは、２つの ＨＴＭＬページを自動的に比較し、「併合された」ページを形成して、特殊なＨ ＴＭＬマークアップでその相違点を示す。 チェックされない。しきい値はＵＲＬによって異なり、どのしきい値を採用する かを決定するのにperlパターンマッチング（照合）を利用し、第１の照合パター ンを使用する。表１は、^〜/.w3newer_thresholdsコンフィギュレーション（環境 設定）ファイルの一例を示す。しきい値は日付（ｄ）と時間（ｈ）の組み合わせ として指定し、０は、w3newerを起動する度にページをチェックする必要がある ことを示し、「なし」はチェックする必要がないことを示す。 表１：w3newerに対して指定されたしきい値の例 ２．３ キャッシュコンシステンシの問題 ＨＴＴＰページがいつ変更されたかを判断するのは、分散ファイルシステムに ファイルをキャッシュし、ファイルがいつ変更されたかを判断するのに似ている 。Andrew File System[6]およびSprite[8]等のファイルシステムは、無効コピー を伴うホストへのコールバックを発行することによってキャッシュコンシステン シを保証する。ＨＴＴＰアクセスは、クライアントがアクセスする各ファイルに ついて周期的にサーバーにチェックを入れる従来のＮＦＳ[12]の手法により近い 。Netscapeは、各セッションにつき一度、毎アクセス時にキャッシュされたペー ジの変更日をチェックするか、または全くこれを行わないように構成することが 出来る。キャッシングサーバーは、クライアントが完全なリロードを要求すると き、または「活き時間」(time-to-live)が切れるとチェックを行う。 ここで、目的とする環境によって問題が複雑化する。つまり、現在見ているペ ージがいつ変更したかのみならず、暫く見ていないページがいつ変更したかも知 りたいものである。幸い、ファイルシステムとは異なり、ＨＴＴＰデータは通常 多少のインコンシステンシ（矛盾）については許容できる。ユーザーにとって関 心はあるものの最近見ていないページの場合には、通常、１日または１週間とい ったある妥当な期間内に見いだせば十分である。ページに変更があったときに関 心のある者全員に通知する機構がサーバーにあったとしても、オーバーヘッドを 費やしてすぐに通知する価値がないこともある。 そこで、上述の動作に代えて、ハーベストリプリケーション(Harvest Replica tion)やキャッシングサービス[１]のようなものを用いて、関心のある者にゆっ く りと通知することが考えられるだろう。現在ページをキャッシュしているブラウ ザまたはページに関心を示しているユーザーは、ページに関心があることをその ローカルキャッシングサービスに登録することが出来る。すると、キャッシング サービスはインターネットワイドの分散サービスにその関心を登録し、その分散 サービスが最善を尽くしてキャッシングサービスに変更をタイムリーに通知する 。（このサービスは、ＨＴＴＰページのバージョンもアーカイブする可能性があ る。）ページはすでに複製されており、サーバーのロードは分散され、ページが 変更するとそれを発見するための機構は、分散リポジトリと内容提供者との間の 交渉にゆだねられる。つまり、内容提供者がリポジトリに変更を通知するか、ま たはリポジトリが周期的にポーリングするのである。いずれにしても、関心のあ るＨＴＴＰサーバーの各々をポーリングするクライアントは多くはないであろう 。ＨＴＴＰキャッシングについてのインテリジェンスをサーバーに移すことは、 GwertzmanおよびSeltzer[3]らによって提言されている。 NO HANDSの機能をファイルシステムに統合することも考えられるであろう。任 意のファイルが変更したときにアクションをおこすことが出来るツールは存在す るものの、広く入手可能であるわけではない[11]。ユーザーは新しいファイルお よびＷ³ページの統合レポートが欲しいと考えるであろうし、w3newerは「ファイ ル」仕様をサポートし、ローカルファイルが変更したかどうかを見いだすことが 出来る。しかし、snapshotにはユーザーの（遠隔の）ファイルシステムのファイ ルにアクセスする手だてがない。ブラウザに機能を移すことによって、改訂制御 システム（ＲＣＳ）等のバージョニングシステムの制御下にまだないファイルの スナップショットを個々のユーザーが得ることが可能となる[14]。これは、HotJ ava等のクライアント側の実行を伴うブラウザの適切な使用といえるかもしれな い。 ２．４ エラー状態 周期的なタスクで多数のＵＲＬの状態をチェックすると、いくつか誤動作が起 こるおそれがある。ネットワークの接続性やプロキシキャッシングサーバーの状 態等のローカル（局所的）な問題によって、ＨＴＴＰリクエストがすべて失敗に 終わる可能性がある。プロキシキャッシングサーバーは多数のリクエストをタイ ムアウトとするほどにオーバーロードされることがあり、短時間で多くのＵＲＬ を検索するバックグラウンドタスクによってこの状態がさらに悪化する可能性が ある。従って、w3newerは実行を中止して後で再試行（ユーザーが更新されたレ ポートを見るのに間に合うのが好ましい）する場合を検出できなくてはならない 。 同時に、個々のＵＲＬによっていくつかエラーが起こることもある。これらは 、転送ポインタを残したり、または残すことなく移動することがある。ＵＲＬの ためのサーバーが、非活動化されたり、名称が変わったりすることもある。これ らは「ロボット」による検索を却下することがある。つまり、「ロボット排他プ ロトコル」[10]に従ういかなるプログラムもこれらを検索することが出来ない場 合がある。ロボットテキスト（robots.txt；排他プロトコルの一部）を検索する コストと比較すると、変更日を検索するコストは小さいため、このタスクについ てはロボット排他プロトコルを無視するか、または各ホストについてごくたまに ロボットテキストをチェックするのが適切であろう。それでも、特にページ内容 が毎回検索される場合には、多くのＵＲＬがチェックされるホストについてはプ ロトコルを遵守するのが賢明であろう。 変更日およびチェックサム等の情報に基づく変更の自動検出は、「煩わしい」 変更によっても変更が通知されるため、「ジャンクメール」等の発生につながる 可能性がある。たとえば、アクセスされた回数を報告したりその時の時間を組み 込んだページは、検索する度に異なって見えるであろう。 w3newerは以下のステップによってこれらの問題に対処する。 ・ロボットがＵＲＬにアクセス出来ない場合には、その事実をキャッシュし、ス クリプトが呼び出される際に特殊なフラグがセットされない限りはそのページに はアクセスしないようにする。 ・別のフラグで、ＵＲＬのタイムスタンプに関する限り、エラー状態をエラーの ないチェックとして扱うようにw3newerに指示する。たとえば、w3newerが毎日稼 働されて特定のＵＲＬを４日ごとにチェックする場合、通常、月曜日にページに アクセスした際にエラーがあるともう一度火曜日にチェックされる。このフラグ を用いると、金曜日にもう一度チェックすることとなる。一般に、エラーは一過 性である傾向があり、w3newerを次に稼働したときにチェックするのが妥当であ ろう。 ・ＵＲＬにアクセスできなければ、ステータス（状態）レポートにエラーメッセ ージが現れ、ユーザーがもう存在しないＵＲＬや頻繁にエラーに当たるＵＲＬを 除去するようにすることが出来る。 さらに、w3newerは、特定のＵＲＬでエラーに出くわした回数の連続カウンタ を保持したり、ホストまたはネットワークエラー（たとえば、「タイムアウト」 や「ネットワーク接続不可能」など）が起こっていれば、ホストに関する後続の ＵＲＬをスキップするように変更することが出来る。「煩わしい」変更の問題に 対処するには、意味論レベルでの相違点を調べるためのヒューリスティックス（ 発見的方法）を必要とする。 ３．Snapshots：バージョンの履歴の外部表現 Ｗ³ページがいつ変更されたかを判断するための機構を提供するのに加えて、 比較のためにページの複数のバージョンにアクセスする方法が必要である。この セクションでは、バージョンの履歴を保持する方法と本願発明者らの解決策によ って生じるいくつかの問題について論じる。 ３．１ 選択的手法 Ｗ³ページのバージョニングを提供するのに３つの可能な手法がある。すなわ ち、各内容提供者が全バージョンの履歴を保持するようにするか、各ユーザーが この履歴を保持するようにするか、バージョンの履歴を外部サーバーに記憶する かである。 サーバー側のサポート 各サーバーがそのページの履歴を記憶し、その履歴を 用いて変更を強調するマークアップページを生成する機構を与えてもよい。この 方法では任意の内容提供者がバージョニングと差異特定を提供しなくてはならず 、実用的ではないが、内容提供者がやろうとするのであれば、この特徴をサポー トするのが望ましい。（セクション６．１を参照） クライアント側のサポート ホットリストのアイテムをローカルに記憶するプ ログラムを各ユーザが実行し、ローカルにセーブされたコピーに対してhtmldiff を動作させてもよい。この方法では、関心のあるページすべてを各ユーザーがセ ーブする必要があり、平均的ユーザーのホットリストのページ数が増えるにつれ て望ましくないものとなるであろうし、さらにＷ³ブラウザを動作させる全ての プラットフォームに対してhtmldiffを実行する能力が必要とされる。Netscape等 のプログラムはいずれにせよローカルにページをキャッシュし得るため、ホット リストによって参照されたページを記憶するのが妥当であるとはいえないかもし れない。この機能を与えるwarmlist[16]等の他の外部ツールも存在する。 外部サービス 本願発明者らの手法は、内容提供者とクライアントの双方から分 離されたサービスを稼働させるというものである。ページはＨＴＭＬフォームで サービスに登録され、同じように相違点を検索することが出来る。一旦、ページ がサービスに記憶されると、その後ページの状態を記憶するようにリクエストす ることでそのページと前にチェックしたバージョンとの相違点のみをセーブする ＲＣＳ「チェックイン」動作が行われる。従って、一度に多くの点で変更するペ ージを除いては、最初にページのコピーをセーブする必要がある以外は記憶のオ ーバーヘッドが最小にされる。 「外部サービス」の手法での不都合は、サービスを利用する者全員が関心を示 したページ全部の状態を記憶し、かつどのユーザーが各ページのどのバージョン を見たかを記憶しなくてはならない点である。前者の問題は、主にリソース（資 源）割り当ての問題であり、サービスが非常に多くのクライアントによって多数 の大きなページに対して利用されていなければさほど大きな問題ではないと考え られる。後者の問題は、ＲＣＳのデートスタンプのサポートを利用し、ある時間 に存在した状態のページをリクエストすることによって対処できる。これに代え て、＜ユーザー、ＵＲＬ＞の各組み合わせについてバージョン番号を保持しても 良い。 ページがそれを元々提供していたマシンから移った場合に相対リンクが問題と なる。ソースが変更されないで渡されるのであれば、ブラウザは、snapshotスク リプトを含むＣＧＩディレクトリに対してリンクが相対的であると見なすであろ う。ＨＴＭＬは、異なるＵＲＬに対して相対的な相対リンクを形成するＢＡＳＥ 指示文をサポートし、これによって上記問題はほとんど対処できる。しかし、Ne tscapel.1Nはこのような文書内の内部リンクを新しいＢＡＳＥにも相対的である ものとして扱い、それによってブラウザはhtmldiff出力と元の文書との間で予測 しないジャンプを行うこととなり得る。 ３．２ システムの問題 snapshot機能で４つの重要な問題、すなわち、ＣＧＩの使用、同期、リソース 活用、およびセキュリティ／プライバシーの問題に対処しなくてはならない。 ＣＧＩは、snapshotがＨＴＭＬ出力を送信する以外にユーザーおよびそのブラ ウザと対話する手だてがないために問題となる。ＣＧＩスクリプトが呼び出され ると、httpdがデフォルトのタイムアウトをセットアップし、スクリプトがフル のタイムアウト間隔の間に出力を発生しなければ、httpdはブラウザにエラーを 返す。このことは、スクリプトがインターネットを介してページを検索してアー カイブされたバージョンと時間のかかる比較を行わなくてはならない可能性があ るため、snapshotにとって問題となる。その後の検索のタイムアウトの間隔がど の程度であれば妥当かについては、サーバーからsnapshotに知らされるのではな く、スクリプトへのハードコードとされる。ＨＴＴＰコネクションを活かした状 態で保持するために、snapshotは、数秒ごとに１スペース（Ｗ³ブラウザには無 視される）を生成する子プロセスにフォーク（分岐）し、一方で親プロセスでは ページを検索するかまたはhtmldiffを実行する。 本機能を同時に利用するユーザー間での同期化は、ブックキーピングのための 複数ファイルの使用によって複雑になる。システムはＲＣＳリポジトリへのアク セスと、ＨＴＭＬ文書のローカルにキャッシュされたコピーと、各ページのどの バージョンをユーザーが見たかを記録する制御ファイルとを同期化しなくてはな らない。現在、ＵＲＬ毎のロックファイルとユーザー毎の制御ファイルの両方に 対してロックするUNIXファイルを用いてこれを行っている。複数のユーザーが同 時に同じページをリクエストすると第２のsnapshotプロセスはその作業を繰り返 すのではなくそのページを待ってから返すようにロックが待ち行列に入れられる のが理想である。これはスナップショットを行うためにはそう重要ではなく、そ の場合、プロキシキャッシュサーバーは第２のリクエストに迅速に応え、ＲＣＳ は何も変更がないことを容易に判断することが出来るが、同じデータに対してht mldiffを２度起動する理由はない。 後者の点はリソース活用の一般的問題に関連している。Snapshotは、処理量も ディスク空間も大量に使用する可能性がある。サーバーに対してhtmldiffを実行 する必要があることによって、この機能がかなり利用される場合にはプロセッサ のロードが大きくなる可能性がある。これらのロードについては、しばらくhtml diffの出力をキャッシュして、あるページのＮおよびＮ＋１バージョンを見た多 くのユーザーがhtmldiffを１度呼び出せばhtmldiff（ページＮ，ページＮ＋１） を検索できるようにする事によって、緩和することができる。この機能はまた、 多くのＷ³サービスのように、同時ユーザー数に制限を課したり、または複数の コンピュータ間でそれ自体を複製することもできる。 ディスク空間は、リポジトリが制限なく大きくなりユーザーにコストがかから なければ、問題となる可能性がある。実際に、このようなサービスをインターネ ット上に導入する前に、各ユーザーの認証を取り、ユーザーに固定数のＵＲＬお よび／またはディスクブロックの制限を課す必要があろう。インターネットの商 用機能を用いて、ＵＲＬ群を記憶する許可と引き替えに料金を徴収することが考 えられよう。この料金は、差異特定サービスに対しての支払いともなるため、記 憶媒体のコストを容易に相殺するであろう。 最後に、セキュリティおよびプライバシーも重要である。ＣＧＩスクリプトは 最小特権で動作するため、多くの人がアクセスを有するアカウントから、リポジ トリ内のデータが任意のＣＧＩスクリプトおよびＣＧＩ領域にアクセスを有する 任意のユーザーの影響を受けやすい。このリポジトリ内のデータは、ブラウズ、 変更、または削除が可能である。この機能を用いるためには、後にバージョン番 号を比較するのに用いる識別子（現在は電子メールアドレスを用いており、これ は誰でも特定できる）を与えなくてはならない。従って、リポジトリのブラウジ ングによってどのユーザーがどのページに関心があり、ユーザーが新しいチェッ クポイントをどれだけ頻繁にセーブしたかを示すことが出来る。 安全が保証された機械上の認証されたシステムに移行することによって、より セキュリティを与えながら、これらのうちのある接続を断ち、個人のアクティビ ティを曖昧にすることができる。リポジトリは、バージョン番号とＵＲＬのセッ トと非個人のアカウント識別子を関連づけ、これらのアカウントのうちの１つに アクセスするのにパスワードが必要とされるであろう。しかし、アカウント形成 が匿名で行えない限りは、この機能を実行する者がどのユーザーがどのページに アクセスするかの情報を有するのである。 ４ HtmlDiff：ＨＴＭＬページの比較 本願発明者らの経験では、Ｗ³上のページのうちのごく一部しかページがどの 様に変更されたかをユーザーが確認するのを可能にする情報を含んでいない。最 近追加したものを強調するアイコンや、「変更記録簿」へのリンク、または特別 の「新規事項」ページ等がその例である。導入部で言及したように、これらの手 法には欠点がある。これらは、すべてのユーザーに見られることを意図している が、ユーザーはそれぞれ異なる間隔でページにアクセスし、「新規事項」に対す る概念がそれぞれ異なるのである。さらに、保守者は、通常マニュアルでＨＴＭ Ｌをマークアップすることによって最近の変更のリストを明確に生成しなくては ならない。 ＨＴＭＬページの自動比較およびマークアップページの生成により、ＨＴＭＬ の提供者は何が新しいかを判断する必要も、相違点を示す新しいまたは変更され たＨＴＭＬページを形成する必要もなくなる。文書の比較やその結果を提示する のには多くの方法がある。このセクションでは、ＨＴＭＬ文書の比較に関する種 々のモデル、本願発明者らの比較アルゴリズム、および比較結果の提示にまつわ る問題について説明する。 ４．１ Diffの内容 ＨＴＭＬはマークアップと内容（生テキスト）を区別する。多くのマークアッ プ（たとえば、＜Ｐ＞、＜Ｉ＞、および＜ＨＲ＞）は、単に生テキストのフォー マティングおよびその提示を変更する一方で、マークアップの中には画像（＜Ｉ ＭＧ src=...＞）や、ハイパーテキスト参照（＜Ａ href=...＞）等の内容定義 型のものがある。文書内の余白は（おそらく＜ＰＲＥ＞内部以外は）いかなる内 容も与えず、比較に影響を与えるものであってはならない。 極端に言えば、ＨＴＭＬ文書を単なる「内容定義型」マークアップと単語の列 としてみることが出来る。「内容定義」型でないマークアップと余白は比較とい う目的に関しては無視される。＜Ｐ＞...＜／Ｐ＞内のテキストが段落として論 理的に一緒に分類されるということは無視される。その結果、４つの文からなる 段落をとってそれを４つの文（各々＜ＬＩ＞で始まる）のリスト（＜ＵＬ＞）に すると、内容は完全に一致するために相違点にはフラグは立てられない。 その逆に極端に言えば、ＨＴＭＬを階層型文書としてみて、その文書の解析（ パーズ）木または抽象構文木の表現を、部分木の等しさ（または何らかのより弱 い基準）を比較の基本として使用して、比較することが出来る。この場合、段落 （＜Ｐ＞...＜／Ｐ＞）を表す部分木は、リスト（＜ＵＬ＞...＜／ＵＬ＞）を表 す部分木とは比較できない可能性がある。段落をリストと置き換える例は、内容 およびフォーマット変更の両方としてフラグが立てられる。 本願発明者らは、ＨＴＭＬ文書を「文分断」マークアップ（たとえば＜Ｐ＞， ＜ＨＲ＞，＜ＬＩ＞または＜Ｈ１＞）と文の列としてみなし、ここで「文」はあ る（文を分断しない）マークアップ（たとえば＜Ｂ＞または＜Ａ＞）と単語の列 である。「文」は、多くても英文１文を含むが、英文の一部分であっても良い。 マークアップは全て、それが「内容定義型」であるかないかに関わらず、表現さ れ、比較される。段落からリストに置き換える例では、比較によって内容の変更 は示されないが、フォーマットに対する変更は示される。 本願発明者らは、ＨＴＭＬ文書を比較するのに最長共通サブシーケンス（ＬＣ Ｓ）の問題に対するHirshbergの解決策[4,5］（その速度は最適化した）を採用 した。これは、UNIXのdiffユーティリティで利用される周知の比較アルゴリズム である[7]。ＬＣＳの問題は、最長である（または重みが一番大きい）２つのト ークン列の（必ずしも連続していない）の共通部分列を見つけることである。Ｌ ＣＳにないトークンは変更を表す。Unixのdiffでは、トークンはテキストライン であり、各ラインが１に等しい重みを有する。htmldiffでは、トークンは、単語 および文分断マークアップの列からなる文または文分断マークアップのいずれか である。文の定義は再帰的ではなく、つまりある文がさらに文を含むことは出来 ないことに留意されたい。ＨＴＭＬ文書の単純な字句解析によってトークン列を 形成し、マークアップ名と関連の（変数，値）ペアのケースをアッパーケース（ 大文字）に変換する。構文解析は必要ではない。 次に、重みづけＬＣＳアルゴリズムがどの様に２つのトークンを比較し、負で ない重みを計算してそれらの一致の程度を反映させるかを説明する（重み０は不 一致を示す）。文分断マークアップは文分断マークアップとしか一致し得ない。 これらは一致するためには、（余白、ケース、および（変数、値）ペアのリオー ダを法として）同一でなくてはならない（この区分の議諭についてはセクション ４．３を参照されたい）。一致は１に等しい重みを有する。文は文としか一致し 得ないが、文が一致するには互いに同一である必要はない。２つの文が一致する かどうかを判断するのに２つのステップを用いる。第１のステップは、文の長さ を比較単位として用いる。文の長さは、文中の単語と＜ＩＭＧ＞または＜Ａ＞等 の「内容定義型」マークアップの数として定義される。＜Ｂ＞または＜Ｉ＞等の マークアップはカウントされない。２つの文の長さが「十分に近い」のでなけれ ば、これらは一致しない。「十分に近い」場合には、第２のステップで２つの文 のＬＣＳを計算する（単語と完全に一致する単語には重み１を割り当てられ、マ ークアップと完全に一致するマークアップも同様である）。Ｗを２つの文のＬＣ Ｓの単語および内容定義型マークアップの数とし、Ｌを２つの文の長さの和とす る。（２＊Ｗ）／Ｌの割合が十分に大きければ、それらの文は重みＷで一致する が、そうでない場合には一致しない。 ４．２ 相違点の提示 上述の比較アルゴリズムにより、古い文書のトークンから新しい文書のトーク ンへのマッピングが得られる。マッピングを有するトークンは「共通」と称し、 古い（新しい）文書にはあるが新しい（古い）文書にはないトークンは「古い」 （「新しい」）と称する。「古い」および「新しい」トークンを「相違点」と称 する。 種々のマークアップ技術で相違点を強調するＨＴＭＬ文書を形成することによ り相違点を提示する３つの基本的な方法について調べた。 並置 縦方向に同期化された共通テキストを伴う文書を並置提示するのは、文 書間の相違点を表示する非常に一般的で納得のいく方法である（たとえば、Unix のsdiffまたはＳＧＩのグラフィックdiffツールgdiffを参照）。残念ながら、現 在のＨＴＭＬおよびブラウザ技術にはこのような同期化を可能にする良好な機構 は（列毎に文書を有し、その行を使用して同期を達成する表を含む文書を形成す るのは可能かもしれないが）存在しない。 相違点のみの表示 相違点（古いものと新しいもの）のみを表示し、共通部分 は排除する（Unixのdiffと同様）。これは、文書問に共通部が多い「共通」ケー スには最適である。これは、非常に大型の文書には特に有用であるが、周囲の共 通コンテキスト（文脈）が失われるため、混乱を招きかねない。この手法での別 の問題としては、古い部分と新しい部分が介挿されているＨＴＭＬ文書は構文的 に不正確な可能性がある点である。 統合ページ 共通した内容、新しい内容、および古い内容全てを集約したＨＴ ＭＬページを形成する。これには、共通の内容が一度しか表示されない（並置提 示とは異なる）という利点がある。しかし、２つのページを１つに統合すると、 構文的および意味諭的に不正確なＨＴＭＬが形成される恐れが生じる。（たとえ ば、アイテムのリストを表に変換するケースを考察されたい。） 本願発明者らが選択したのは、相違点を統合ページのフォーマットで提示し、 コンテキストを与え、内部ハイパーテキスト参照を用いて相違点をまとめてチェ ーン状にリンクして、ユーザーが相違点から相違点へと迅速にジャンプできるよ うにする方法である。現在、統合による構文上／意味論上の問題については、統 合ページから古いマークアップを全て排除することによって対処している。（こ れは古い方のマークアップ全てという意味ではなく、比較アルゴリズムによって 「古い」と分類されたものだけであることに留意されたい）。そのため、古いハ イパーテキスト参照および画像は統合ページには現れない（もちろん、これらは 削除されているため、いずれにしてもアクセスできない）。しかし、「古い」と 「新しい」の意味を逆にすることによって、古いマークアップはそのままにして 新しいものを削除した統合ページを形成することが出来る。より厳しいオプショ ンは、古い内容全てを取り除くことであろう。この場合には、そもそも最も最近 のページが構文的に正確であれば、構文上の問題はない。統合ページは、単に最 も最近のページと新しい内容を指すマークアップとを併せたものとなる。統合ペ ージ形成の他の方法についても研究中である。 htmldiffの統合ページの出力の例が図１に示される。以下のように古い内容と 新しい内容を強調するのにマークアップが用いられる。文書内の変更領域を指す のに２つの小さな矢印の像が用いられる。赤い矢印は古い内容を指し、緑の矢印 は新しい内容を指す。矢印はまた、互いへの内部ハイパーテキスト参照であり、 チェーン状にリンクされて相違点に迅速に移動するのを可能にする。文書の前部 のバナーは、第１の相違点へのリンクを含む。古いテキストは<STRIKE>を用いて 、我々の経験上Ｗ³上で見られるＨＴＭＬでは滅多に用いられない「ストラック アウト」フォントで表示する。残念ながら、「新しい」テキストを示す理想的な フ ォントはなく、現在のところ<STRONG><I>を使用している。古いテキストと新し いテキストを強調するためにテキストまたはテキストの背景をカラーコードでき るのが理想であるが、現在のブラウザはこの機能を提供していない。別の手法と して、相違点でアクティブでないフオントを選択することも考えられる。 ここで、文書内のすべての変更が強調されるわけではないことに留意されたい 。たとえば、「内容定義型」でない新しいマークアップ（例えば＜Ｐ＞）はマー クアップされないが、アンカー等のマークアップは強調される。アンカーにおけ るＵＲＬは変更されるが＜Ａ＞...＜／Ａ＞に囲まれる内容は変更されない例に ついて考えると、この場合、矢印によりアンカーのテキストが指されるが、テキ スト自体はその元のフォントのままであり、ＵＲＬのみに対する変更を示す。 ４．３ 問題および拡張 htmldiffは、ＨＴＭＬ文書の構文解析を行ってマークアップが不一致であった り抜けていたりといった構文上の問題を修正することができるため、唯一起こり そうな真の問題は、変更があまりにも広範囲に及んでいて、得られる統合ＨＴＭ Ｌが解読不可能になることである。たとえば、一行おきに変更があれば、関連の ないストラックアウトおよび強調テキストが混在してしまう。古いテキストと新 しいテキストとを散在させられる度合いを変える方法と、変更が多すぎて表示す る意味がない場合を特定するしきい値については開発中である。 現在、htmldiffは「バージョン認識」も「ウェブ認識」もしない。つまり、ht mldiffは単に２つのＨＴＭＬページのテキストを比較するだけで、ページが参照 したり、アクセスしたり、他の参照ページ上で再帰的に呼び出したりするエンテ ィティのバージョン同士の比較は行わない。これにより様々な結果が生まれる。 良い点は、htmldiffが、リポジトリからバージョンを引き出したりＷ³上で情報 に対するリクエストを送ることによるオーバーヘッドを被らないことである。こ のコストはw3newerとsnapshotによって負担される。悪い点は、相違点の中には 無視されるものがあることである。例えば、画像ファイルの内容は変更されても ファイルのＵＲＬは変更されない場合には、そのページのＵＲＬは変更されたも のとしてフラグが立てられないのである。このような比較をサポートするには参 照されるエンティティのある種のバージョニングが必要となり、さらにhtmldiff がバージョンリポジトリにアクセスを有する必要がある。すべてのエンティティ の完全なバージョニングによって興味深い 比較を行うことができるだろうが、記憶上の要件を劇的に増大させてしまう。よ り安価な代替策として、各エンティティのチェックサムを記憶し、それを利用し て何か変更があったかどうかを判断することが考えられる。このような「より賢 い」比較を効率的に行う方法については研究中である。 ５ ツールの統合 NO HANDSへのエントリポイント（入口）は、w3newerを介するものとsnapshot を介するものとの２つがある。 現在のところ、w3newerがユーザーによって直接、多くはcrontabエントリによ って呼び出され、どのページが変更したかを示すＨＴＭＬ文書を生成する。指定 されると、w3newerはホットリストの各文書と以下の３つのリンクを関連させる 。 記憶 snapshot機能にＵＲＬを送り、ページのコピーをセーブする。ページが 検索されても、ＲＣ Ｓciコマンドにより、前回記憶したものと変更がなければ セーブされないようになっている。 Diff snapshot機能にhtmldiffを呼び出させて、ユーザーが前回セーブしてか らのページの変更を表示させる。 履歴 snapshotに、任意のバージヨョるか、または特定のバージョンを直接見 せる機能を伴って、このページのバージョンの全ログを表示させる。（図２を参 照） このように、「新しい」と報告された各ページを即座にhtmldiffに渡すことが でき、リストのどのページも将来使用するのに備えて「記憶」することができる 。w3newerの出力の一例を図３に示す。 ユーザーはまた、snapshotに直接入ることを選択して、ページのチェックイン を行ったり、最新ページまたはバージョンの履歴を見るようにしても良い。図４ は、snapshotを介したNO HANDSへのインターフェースを示す。ユーザーが履歴の リンクを選択した場合には、図２に示されるページが提示される。比較する２つ のページを選択すると、図１のようにhtmldiffが呼び出される。 この手法の不利な点は、w3newer、snapshot、Ｗ³ブラウザの間に直接のインタ ラクションがないことである。htmldiffでページを見てもブラウザはそのページ が見られたことを記録することにはならず、ブラウザはまずhtmldiffを呼び出す のに使用したＵＲＬを記録する。その後、w3newerはブラウザから古くなってし まったデートスタンプを使用し、ブラウザが見たのよりも最近にページが変更さ れたことを報告し続ける。その結果、ユーザーはページを直接見ると共にhtmldi ffを介しても見ない限りは、これを変更ページのリストから外して実際の相違点 を見ることはできない。 ６ 拡張 このセクションでは、既に説明した作業に対して実行できる拡張について説明 する。セクション６．１では、既に実現されているhtmldiffとＲＣＳのインター フェースについて述べ、セクション６．２および６．３ではまだ実現されていな い、変更の追跡のサーバーへの統合とＨＴＴＰ ＰＯＳＴプロトコルを介したス クリプトの呼び出しについての拡張を論じる。 ６．１ サーバー側のバージョン制御 上述のツールは、Ｗ³上の任意のクライアントまたはサーバーの変更を必要と しない。文書のバージョンをセーブしてそれらがどう変更されたかを示すマーク アップ済みバージョンを与える特定のサーバーと通信するのには、既存のＧＥＴ およびＰＯＳＴプロトコルを用いる。しかし、サーバーがhtmldiffおよびあるpe rlスクリプトを動作させる場合には、直接的なバージョン制御インターフェース を与えてそのＨＴＭＬ文書のコピーをどこか別の場所に記憶させる必要をなくす ことができる。 本願発明者らが作成したperlスクリプトは、ＲＣＳへのインターフェースを与 える[14]。ＣＧＩスクリプト(/cgi-bin/rlog)は、rlogの出力をＨＴＭＬに変換 し、任意の特定のバージョンを見たり２つのバージョン間の相違点を見いだすた めのリンクを伴った文書の履歴をユーザーに示す。別のスクリプト(/cgi-bin/co )は、ＲＣＳの制御下で文書のバージョンを表示し、さらに別のスクリプト(cgi- bin/rcsdiff)は、相違点を表示する。ファイル名が.htmlで終わる場合には、rcs diffではなくhtmldiffを用いて相違点を表示する。 例えば、ＨＴＭＬ文書の末尾にLast-Modifiedフィールドをrlogスクリプトへ のリンクとなるようにセットアップして、文書名をパラメータとして指定しても よい。この目立たないフィールドをクリックすると、ユーザーは文書の履歴を見 ることができる。 ６．２ サーバー側のＵＲＬ追跡 現在、w3newerはユーザーのマシン上で動作するため、スクリプトの複数のイ ンスタンシエーションにより同じ作業を行う可能性がある。これは、ＡＴ＆Ｔワ イドのプロキシキャッシングサーバーと同じマシン上の関連デーモンを動作させ て、現在サーバー上でキャッシュされているページについての情報を戻してイン ターネットを介してのいくつかのアクセスについては行わないのだが、そのキャ ッシュには多数のリクエストの必要をなくすだけの十分な局所性がない。 これに代えて、w3newerをsnapshotデーモンによってセーブされたページ群に 対して動作させてもよい。ページに関心があるとして登録したユーザーの数に関 わらず、一度チェックするだけでよいのである。変更があると、新しいバージョ ンが自動的にセーブされる。すると、ユーザーはセーブされた全ページのリスト をリクエストして、ユーザーがセーブしてからどのページが変更されたかの示唆 を受けることができる。 これにより規模の利益(economies of scale)が得られるため、この機能を加え るのは有用である。しかし、ユーザーのＷ³ブラウザ履歴からは切り離されると いう不都合がある。すなわち、ユーザーがページを直接見ると、snapshot機能は これを示さないため、このページを変更されたものとして提示する可能性がある 。 ６．３ ＣＧＩスクリプトとのインタラクション NO HANDSは任意のＵＲＬを扱うことができるため、ＵＲＬの一部としてスクリ プトにアーギュメント（引数）を受け渡しすることによって、ＧＥＴプロトコル を使用するＣＧＩスクリプトと対話できる。しかし、ＰＯＳＴを使用するサービ スへの入力は記憶されないため、このサービスにはアクセスできない。 w3newerもsnapshotもＰＯＳＴプロトコルをサポートするように変更しなけれ ば、サービスを呼び出して結果が変更されたかどうかを調べ、その結果を記憶し てもし変更があれば表示するということはできない。しかし、ＰＯＳＴをサポー トするNO HANDSへのインターフェースは、わかりやすくはない。ユーザーはフォ ームが呼び出すＵＲＬをNO HANDSによって与えられるものに変更する。そして、 実際のサービスに渡すにはその入力のコピーを形成しなくてはならない。その結 果は、UNIXのパイプに相当するHTTPであって、ユーザーが呼び出そうとしている サービスとブラウザとの間に追加のサービスを介挿することとなる。 これに代えて、フォームに関してよりよいサポートを有するようにブラウザを 変更することができる。すなわち ・そのブックマークファイルにフォームの記入済みのものを記憶させて、ユー ザーがＣＧＩスクリプトの出力に直接ジャンプできるようにする。 ・ＦＯＲＭタグで指定されたＵＲＬとともに、フォームをNO HANDSに直接渡し て、出力がＲＣＳのもとで記憶されるようにする。 ７ 結論 NO HANDSは、単一の結合ツールにＷ³ページの通知、アーカイビング、差異特 定を組み合わせるものである。さらに、不必要なHTTPアクセスを避け、各ページ は変更される度に（それを追跡するユーザーの数に関わらず）多くても一度だけ セーブされ、基底バージョニングシステムとしてＲＣＳを使用することにより、 規模の利益を与える。ＨＴＭＬの枠内での相違点の自動生成によって、ユーザー は好都合に挿入点と削除点の両方を知ることができる。 Ｗ³および文書検索の一般的環境において、NO HANDSは、２つの集団に利益を 与える。すなわち、Ｗ³のユーザーは変更した関心のあるページを探すためにブ ラウズする必要がなくなるし、ＨＴＭＬ提供者は「新規事項」を示すために適切 にマークアップされたページを形成する必要がなくなる。このような自動化がこ の一般的状況で便利であることは明らかであるが、さらに、共同作業や分散型作 業に関わる領域では特に、Ｗ³のより集中的な使用においてNO HANDSが重要な役 割を果たすことが期待される。 まだ対処すべき問題がいくつか残っている。特に、Ｗ³ブラウザおよびサーバ ーとよりよく統合させることによってNO HANDSの多くの複雑な点を回避できるで あろう。例えば、あるページの古いバージョンと最新バージョンとの相違点を見 ることにより、ページがいつ最後に見られたかについてのブラウザの認識が更新 されるようにしなくてはならない。最後に、Harvest[1]等の分散型階層HTTPリポ ジトリの可用性が増大すると、スケーラブル通知機構およびバージョンアーカイ ブにとって好機であり課題となるであろう。 コンピュータプログラムリスト

【手続補正書】特許法第１８４条の８第１項 【提出日】平成９年５月２３日（１９９７．５．２３） 【補正内容】 データ内に含まれており、そこから導出できることを示している。例えば、各バ ージョンはその全体が記憶されてもよいし、または、バージョンの一つについて はその全体が記憶されて、他のバージョンはそのバージョンとの相違の形態とし て記憶されてもよい。 バージョン制御システムは、ユーザーに選択されたどのバージョンをも再構築 する。 しかし、このようなソフトウェアの多くに欠点がある。一般に、システムの中 には、ユーザーに変更があったことは知らせるものの、その変更自体は識別しな いものがあったり、逆に、変更は識別する（これらのシステムは一般に「diff」 システムとして知られる）ものの、特定の文書対の識別に応じてのみこれを行う ものがある。 発明の概要 本発明の一形態は、リポジトリ内に含まれる文書をユーザーが調べるのを監視 するものである。本発明では、その文書の変更について継続的にモニタする。本 発明によると、ユーザーがその後で文書を調べる際に、その最新の形態の文書を 提示し、ユーザーがその文書を最後に見た後に起こった変更を示す。 図面の簡単な説明 図１Ａは、従来のバージョン制御システムを示す。 図１Ｂは、ハイパーテキスト情報検索に関わる選択概念を示す。 図１は、本発明の例示的な実施形態を示す。 図２は、ホットリストと、リポジトリから外部サービスへのページのコピーを 示す。 図３は、ページの元のバージョンのコピーと、その元のバージョンに対して行 われた変更を含む外部サービス内のアーカイブを示す。 図３Ａは、ページの種々のバージョンをリストにした本発明によって生成され る表示を示す。 図３Ｂは、ホットリスト内のページで変更されたものを特定する本発明によっ て生成される表示を示す。 図４は、前のバージョンから行われた変更を示すフォーマットで提示されるペ ージの最新バージョンを示す。 図５は、図２のユーザーが一人であった場合に対して、二人のユーザーのホッ トリストを示す。 図６は、本発明の一形態によって実現される論理を示すフローチャートである 。 図７は、３つのページの時間的履歴である。 図８は、外部サービスの１タイプのアーキテクチャの一部である。 図９は、本発明の一形態を示す。 図１０は、本発明の一形態を示す。 図１１は、HTTP://SNAPPLE.CS.WASHINGTON.EDU.600/MOBILE/の２つのバージョ ンのサブセット間の相違点を示すHTMLDIFFの出力を示す。もとのＨＴＭＬソース は、その結果が１ページに収まるようにマニュアルで編集される。実用では、強 調されている変更は、

Claims (1)

1. 【特許請求の範囲】 １．システムであって、 ａ）前記システムに対して読み出し専用でページを提供する外部リポジトリか らページのバージョンをコピーするための手段と、 ｂ）ｉ）選択されたバージョンを再構築するのを可能にし、 ｉｉ）選択されたバージョン間の相違点を特定することができる データを記憶するための手段と、 を含むことを特徴とするシステム。 ２．請求項１に記載のシステムであって、再構築されるバージョンが、ユーザ ーによって提供されるリスト上で特定されることを特徴とするシステム。 ３．複数のユーザーが、時間がたつにつれてそのうちの少なくともいくつかが 変更するデータのバージョンを含む別のシステムとインターフェースすることを 可能にするシステムにおいて、その改良点が ａ）ユーザーが最新バージョンと前のバージョンを識別することを可能にする 手段と、 ｂ）最新バージョンを前のバージョンと区別するフォーマットで該最新バージ ョンを表示するための手段と、 を含むことを特徴とするシステム。 ４．時間とともに変更する最新バージョンの形態でデータ単位を記憶するリポ ジトリと通信する方法であって、 ａ）複数のユーザーからデータ単位のリストを受け取るステップと、 ｂ）リストに含まれるデータ単位の選択されたバージョンの再構築を可能にす る内容を含むアーカイブを保持するステップと、 ｃ）間隔をおいて、最新バージョンをアーカイブされた内容と比較し、該アー カイブを更新するステップと、 を含むことを特徴とする方法。 ５．請求項４に記載の方法であって、 ｄ）各ユーザーがどのバージョンにアクセスしたかを記録するステップをさら に含むことを特徴とする方法。 ６．請求項５に記載の方法であって、 ｅ）ユーザーからデータ単位に対するリクエストを受け取るステップと、 ｆ）該データ単位の最新バージョンを提示するステップと、 ｇ）ユーザーがアクセスした前のバージョンにはなかった該最新バージョン内 の内容を強調させるステップと、 をさらに含むことを特徴とする方法。 ７．時間とともに変更するバージョンの形態でデータ単位を記憶するリポジト リと通信する方法であって、 ａ）データ単位の選択されたバージョンの再構築を可能にする内容を含むアー カイブを保持するステップと、 ｂ）ユーザーからデータ単位のリストを受け取るステップと、 ｃ）受け取った各リストについて、該アーカイブをチェックし、リストに挙げ られたデータ単位がアーカイブされていなければ、該リポジトリから最新バージ ョンをコピーするステップと、 ｄ）間隔をおいて ｉ）（Ａ）該アーカイブ内に含まれるバージョンと、（Ｂ）該リポジトリ内 に含まれる最新バージョンと、の相違点を見出すステップと、 ｉｉ）該アーカイブに該相違点を記憶するステップと、 ｅ）各ユーザーがアクセスした最も最近のバージョンを示す情報を該各ユーザ ーについて保持するステップと、 ｆ）ユーザーから最新バージョンに対するリクエストを受け取り、それに応じ て、 ｉ）該リポジトリから該最新バージョンをコピーするステップと、 ｉｉ）該最新バージョンと該アクセスした最も最近のバージョンとの相違点 を見出すステップと、 ｉｉｉ）該相違点を強調させるフォーマットで該最新バージョンを表示する ステップと、 を含むことを特徴とする方法。 ８．語とマークアップコマンドの列を含むマークアップ言語で書かれた第１の テキストと、第２のそのようなテキストとを比較するための装置であって、 ａ）その第１のサブセットに属する句点およびマークアップコマンドを含む終 止符群に定義される該第１および第２のテキストの列を比較して、該テキスト間 の相違点を示す結果を生成する第１および第２のテキストの比較手段と、 ｂ）該結果を受け、それに応じて該相違点を表示する手段と、 を含むことを特徴とする装置。 ９．リポジトリ内のページのバージョン同士を比較するための装置であって、 ａ）第２のページが第１のページの新しいバージョンであることを検出するた めの手段と、 ｂ）前記検出手段に応じて、該第１のページを該第２のページと比較し、該第 １および第２のページ間の相違点を示す結果を生成するための手段と、 ｃ）該結果に応じて、該相違点を表示するための手段と、 を含むことを特徴とする装置。 １０．リポジトリ内のページが、あるユーザーが最後にそれを見てから変更さ れているかどうかを検出する方法であって、前記ユーザーが用いるコンピュータ システムにおいて実行される以下のステップ、すなわち、 ａ）前記コンピュータシステム内で、第１のページ群の各ページについて前記 ユーザーが該ページを見た最後の時間を示すページ最終閲覧時間の第１の記録を 保持して、最後に見た時間が該第１の記録に記録される所与のページについて、 前記コンピュータ内のページ最終変更時間の第２の記録から、該所与のページの 最後変更時間を得て、該第２の記録からの該最終変更時間が、該所与の記録につ いての最終閲覧時間よりも遅いような時間であるかどうかを判断するステップと 、 ｂ）該第２の記録が、そのような時間である最終変更時間を与えていなければ 、ユーザーがアクセスを有する前記コンピュータシステムの外部のソースから最 終変更時間を得て、該外部ソースからの該最終変更時間がそのような時間である かどうかを判断するステップと、 ｃ）該外部ソースから得られた該最終変更時間がそのような時間であれば、該 第２の記録を該最終変更時間で更新するステップと、 を含むことを特徴とする方法。 １１．ユーザーによって定義されたページのバージョン履歴を保持する方法で あって、 ａ）ページの所与のバージョンを該ページのバージョン履歴に保持すべきこと を指定する指示を該ユーザーから受けるステップと、 ｂ）該所与のバージョンが該バージョン履歴内のページの最初のバージョンで あれば、該所与のバージョンのコピーを該バージョン履歴に記憶するステップと 、 ｃ）そうでなければ、少なくとも、該所与のバージョンと該バージョン履歴内 の最も最近の前のバージョンとの何らかの相違点について記憶するステップと、 を含むことを特徴とする方法。