JP5030654B2 - Secure and efficient method of logging and data exchange synchronization - Google Patents
Secure and efficient method of logging and data exchange synchronization Download PDFInfo
- Publication number
- JP5030654B2 JP5030654B2 JP2007112344A JP2007112344A JP5030654B2 JP 5030654 B2 JP5030654 B2 JP 5030654B2 JP 2007112344 A JP2007112344 A JP 2007112344A JP 2007112344 A JP2007112344 A JP 2007112344A JP 5030654 B2 JP5030654 B2 JP 5030654B2
- Authority
- JP
- Japan
- Prior art keywords
- log
- entry
- attribute
- content
- context
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2101—Auditing as a secondary aspect
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Bioethics (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Storage Device Security (AREA)
- Debugging And Monitoring (AREA)
Description
本発明は文書処理の分野に関する。より具体的には、本発明はロギングとデータ交換同期に関する。 The present invention relates to the field of document processing. More specifically, the present invention relates to logging and data exchange synchronization.
信頼できる共有の履歴を残すことは、地域社会における信頼の基礎である。複式会計やペーパートレール(paper trails)等の標準的なプロセスによりトレーサビリティ(traceability)と監査のサポートが得られる。これらの記録を独立に検証することは、地域の病院と自助グループから世界的な証券取引まですべての地域社会と機関が機能する上で重要である。 Keeping a reliable sharing history is the foundation of trust in the community. Traceability and audit support are provided by standard processes such as double accounting and paper trails. Independent verification of these records is important for the functioning of all communities and institutions, from local hospitals and self-help groups to global securities trading.
ロギング(logging)及び/またはデータ交換同期のための方法と装置を提供する。 Methods and apparatus for logging and / or data exchange synchronization are provided.
一実施形態において、本方法は、要求装置からの第1のログにデータをポストする要求を受ける段階と、第1のログの記憶場所を示す要求中のコンテクスト識別子と第1のログに対応する文書に関するデジタルデータとに基づきログを特定する段階と、要求中のデータに基づいて第1のエントリを生成する段階と、第1のログに第1のエントリを加える段階と、第1のログ中のログエントリに基づいて第1の識別子を計算する段階と、第1の識別子を要求装置に送信する段階とを有する。
(発明の詳細な説明)
In one embodiment, the method corresponds to receiving a request to post data to a first log from a requesting device, and a requesting context identifier indicating a storage location of the first log and the first log. Identifying a log based on digital data relating to the document; generating a first entry based on the requested data; adding a first entry to the first log; and in the first log Calculating a first identifier based on the log entries and transmitting the first identifier to the requesting device.
(Detailed description of the invention)
本発明は、以下の詳細な説明と本発明のいろいろな実施形態を示した添付図面から、よりよく理解できるであろう。しかし、これらの実施形態は、本発明を限定されるものと解してはならず、説明と理解を目的としたものと解すべきである。 The invention will be better understood from the following detailed description and the accompanying drawings showing various embodiments of the invention. However, these embodiments should not be construed as limiting the invention, but should be construed as illustrative and understandable.
かかるデジタル交換をするためのデジタルデータトラッキング(tracking)方法と装置を説明する。デジタル交換にトレーサビリティ(traceablility)と透明性の標準をもたらす慣習、プロトコル、及びプロセスのセットがこれらの技術(techniques)をサポートする。かかる技術は、これらの原理に従って同時に使用するソフトウェアとシステムを作成するときに、開発者が使用できる。
本システムの一実施形態の要素としては、グローバルに一意的な識別子、HTTPベースのデータ交換、ロギングフォーマット、同期方法、監査手続及び認証手続がある。各要素は、以下に詳細に説明し、上記のプロジェクトの実施例を例示する。
A digital data tracking method and apparatus for such digital exchange is described. A set of conventions, protocols, and processes that provide traceability and transparency standards for digital exchanges support these technologies. Such techniques can be used by developers when creating software and systems for simultaneous use according to these principles.
Elements of one embodiment of the system include globally unique identifiers, HTTP-based data exchange, logging formats, synchronization methods, audit procedures, and authentication procedures. Each element is described in detail below and illustrates an example of the above project.
以下の説明では、多数の詳細事項を記載して本発明をより詳しく説明する。しかし、言うまでもなく、本発明はこれらの詳細事項がなくても実施することができる。他の場合では、詳細事項ではなくブロック図に周知の構造と機器を示すが、これは本発発明が不明瞭になることを避けるためである。 In the following description, numerous details are set forth to provide a more thorough explanation of the present invention. However, it will be appreciated that the invention may be practiced without these details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the invention.
以下の詳細な説明の一部は、コンピュータメモリ中のデータビットに対する操作のアルゴリズムと記号による表現により表されている。これらのアルゴリズムによる説明と表現は、データ処理技術の当業者が、自分の仕事内容を他の分野の人に最も効果的に伝える手段である。ここで、また一般的に、アルゴリズムとは、所望の結果に導く自己矛盾のないステップのシーケンスである。このステップは、物理量の物理的操作を要するステップである。通常、必ずしも必要ではないが、この物理量には、記憶し、伝達し、結合し、比較し、操作できる電気的または磁気的信号の形をとる。主に一般的な使用のために、これらの信号をビット、値、要素、記号、文字、式、数字等で表すと便利な時がある。 Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means by which those skilled in the data processing arts most effectively convey their work to others in the field. Here and in general, an algorithm is a sequence of steps that is self-consistent leading to a desired result. This step is a step requiring physical manipulation of physical quantities. Usually, though not necessarily, this physical quantity takes the form of an electrical or magnetic signal that can be stored, transmitted, combined, compared, and manipulated. It is sometimes convenient to represent these signals as bits, values, elements, symbols, characters, expressions, numbers, etc., mainly for general use.
しかし、これらの用語や類似の用語は適当な物理量と関連しているべきであり、これらの物理量に付された便利なラベルに過ぎないことに留意すべきである。特に断らなければ、以下の説明から明らかなように、言うまでもなく、この明細書全体において、「処理」、「算出」、「計算」、「判断」、「表示」等の用語を用いた説明は、コンピュータシステム、類似の電子的計算機器の動作やプロセスであって、コンピュータシステムのレジスタやメモリ内の物理的(電子的)量として表されたデータを操作し、コンピュータシステムメモリやレジスタ、その他の情報記憶装置、伝送機器、表示機器内の物理量として同様に表された他のデータに変換するものの動作や処理を指す。 However, it should be noted that these terms and similar terms should be associated with the appropriate physical quantities and are merely convenient labels attached to these physical quantities. Unless otherwise noted, as will be apparent from the following description, needless to say, throughout this specification, explanations using terms such as “processing”, “calculation”, “calculation”, “judgment”, “display”, etc. The operation or process of a computer system, similar electronic computing equipment, that manipulates data represented as physical (electronic) quantities in a computer system register or memory, computer system memory or register, etc. It refers to the operation or processing of what is converted into other data that is similarly expressed as physical quantities in the information storage device, transmission device, and display device.
本発明は、また、これらの動作を実行する装置にも関する。この装置は、必要な目的のために特に構成されたものでもよく、コンピュータ中に記憶されたコンピュータプログラムにより選択的に起動または再構成された汎用コンピュータを有していてもよい。かかるコンピュータプログラムは、コンピュータによる読み取りが可能な記憶媒体に記憶することができる。このような記憶媒体には、フロッピー(登録商標)ディスク、光ディスク、CD−ROM、光磁気ディスク等のいかなるタイプのディスクも含まれ、読み出し専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、EPROM、EEPROM、磁気または光カード、電子的命令を格納するのに好適な、コンピュータシステムバスに結合されたいかなるタイプの媒体も含まれるが、これらに限定されるわけではない。 The invention also relates to an apparatus for performing these operations. This apparatus may be specially configured for the required purposes and may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer-readable storage medium. Such storage media include any type of disk such as floppy disk, optical disk, CD-ROM, magneto-optical disk, etc., read only memory (ROM), random access memory (RAM), EPROM, It includes, but is not limited to, EEPROM, magnetic or optical card, any type of medium coupled to the computer system bus suitable for storing electronic instructions.
ここで説明するアルゴリズムとディスプレイは、特定のコンピュータその他の装置に本質的に関係するものではない。いろいろな汎用システムをここでの教示に従ったプログラムで用いることができるし、必要な方法ステップを実行することに特化した装置を構成しても便利である。これらのシステムに必要な構成を以下に示す。また、本発明は特定のプログラミング言語により記述されるものではない。言うまでもなく、いろいろなプログラミング言語を用いてここに説明する本発明の教示を実施できる。 The algorithms and displays described herein are not inherently related to a particular computer or other device. Various general purpose systems can be used in the program according to the teachings herein, and it is convenient to construct an apparatus specialized to perform the necessary method steps. The configuration required for these systems is shown below. In addition, the present invention is not described by a specific programming language. It will be appreciated that the teachings of the invention described herein can be implemented using various programming languages.
機械読み取り可能媒体には、機械による読み取りが可能な形式で情報を記憶または伝送するいかなるメカニズムも含まれる。例えば、機械読み取り可能媒体には、読出専用メモリ(ROM)、ランダムアクセスメモリ(RAM);磁気ディスク記憶媒体;光記憶媒体;フラッシュメモリデバイス;電子的、光学的、音響的その他の形式の伝送信号(例えば搬送波、赤外線信号、デジタル信号等)などが含まれる。 A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine. For example, machine-readable media include read only memory (ROM), random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electronic, optical, acoustic and other types of transmission signals (For example, a carrier wave, an infrared signal, a digital signal, etc.).
概要
コンテクスト
本技術を詳細に説明する前に、ここで使用する「コンテクスト(contexts)」の概念及びそれがいかにトレーサビリティをサポートするかを説明する。この目的のため、一実施形態では、コンテクストは2つの一意的識別子の組み合わせである。第1の識別子は1つのマシン(machine)(例えば、サーバ)を識別する。第2の識別子は1つのデジタルデータ(例えば、文書ファイル)を識別する。この2つの識別子を組み合わせて、さらに別のグローバルに一意的な「コンテクスト識別子」を生成する。
Overview Before discussing this technology in detail, we will discuss the concept of “contexts” used here and how it supports traceability. For this purpose, in one embodiment, the context is a combination of two unique identifiers. The first identifier identifies a machine (eg, a server). The second identifier identifies one piece of digital data (eg, a document file). The two identifiers are combined to generate yet another globally unique “context identifier”.
「コンテクストログ」はこのコンテクストに関するエントリのシーケンスである。以下に説明するように、このシーケンスはそのコンテクストの履歴として機能する。特に、コンテクストログは、デジタルファイルに適用されたステップのシーケンス、文書のバージョン履歴、文書のアクセス、いろいろなアプリケーションに関係するその他の情報を表す。換言すると、コンテクストログは、1つのデジタルデータの履歴を表す。一実施形態では、コンテクストログは、透明で、監査可能で、偽造困難または不可能な方法で格納され交換される。それゆえ、コンテクストログは紙の文書に似た特性を有し、デジタルデータのトレーサビリティの基礎となる。 A “context log” is a sequence of entries for this context. As explained below, this sequence serves as a history of that context. In particular, the context log represents a sequence of steps applied to a digital file, document version history, document access, and other information related to various applications. In other words, the context log represents the history of one piece of digital data. In one embodiment, context logs are stored and exchanged in a way that is transparent, auditable, difficult to forge or impossible. Therefore, the context log has characteristics similar to a paper document and is the basis for traceability of digital data.
識別子
本技術とともに使用されるいくつかの識別子をここに説明する。以下は識別子またはその一部を表すために使用される文字のリストである。
A −Aはデジタルデータを表す。一実施形態では、Aはデジタルファイルであるが、Aは任意のデジタルデータまたはバイトシーケンスであってもよい。
0xA− 0xA=SHA1(A)であり、HASH(例えば、SHA1関数)バイトストリングAに適用したものである。いかなるハッシュ関数を使用してもよい。一実施形態では、これは40桁の16進数である。
#0n −頭に0を付けて一定の長さ(例えば、20桁)にした10進数を表す。
Identifiers Several identifiers used with the present technology are described herein. The following is a list of characters used to represent an identifier or part of it.
A-A represents digital data. In one embodiment, A is a digital file, but A may be any digital data or byte sequence.
0xA−0xA = SHA1 (A), which is applied to HASH (for example, SHA1 function) byte string A. Any hash function may be used. In one embodiment, this is a 40 digit hexadecimal number.
# 0n-Represents a decimal number with a leading length of 0 and a fixed length (eg, 20 digits).
コンテンツエントリ
任意のデジタルデータは、nバイトのシーケンスとして表される。一実施形態において、0xA:nは1つのデータの識別子として使用され、ハッシュ値が0xAであるnバイトのシーケンスを表す。この識別子にはいくつかの利点がある。第1に、識別子をデータ自体から計算でき、グローバルに一意的であることを基本的に保証できる。これは、識別子はそれ自体が正当性を証明していることを意味し、これはデジタルデータが与えられれば、識別子を計算し、確認(verify)することができることを意味する。しかし、ここで留意すべきことは、その逆は正しくないことである。識別子に関連するデータは不変なので、この識別子を使用してキャッシング(caching)とマシン間の同期を非常に簡単かつ効率的にできる。識別子がローカル(local)のファイルリスト中にあれば、そのファイルを離れたところにあるサーバに要求する必要はない。
Content entry Arbitrary digital data is represented as a sequence of n bytes. In one embodiment, 0xA: n is used as an identifier for one data and represents an n-byte sequence with a hash value of 0xA. This identifier has several advantages. First, the identifier can be calculated from the data itself and can basically be guaranteed to be globally unique. This means that the identifier itself proves correctness, which means that given digital data, the identifier can be calculated and verified. However, it should be noted here that the reverse is not true. Since the data associated with the identifier is immutable, it can be used to make caching and synchronization between machines very simple and efficient. If the identifier is in the local file list, there is no need to request that file from a remote server.
留意すべきことは、いくつかのアプリケーションでは、データの長さ(:n)は省略されることである。これは、特に、基礎となるデータ自体がプライベート(private)であり、一方識別子がパブリック(public)である場合である。(nを知っているので、サーチする範囲を狭くできる。):nが指定されようがされまいが、システムが機能するように、交換の実施をコード化すべきである。 It should be noted that in some applications the length of data (: n) is omitted. This is particularly the case when the underlying data itself is private, while the identifier is public. (Because n is known, the search range can be narrowed.): Whether or not n is specified, the exchange implementation should be coded so that the system works.
属性エントリ
1つのコンテクスト(context)において、1つのデータはそれに関連する属性を有する。例えば、写真にはタイトルがある。これらの属性は名称値ペアのシーケンス、attr1=val1、attr2=val2、...として表される。
Attribute entry In a context, a piece of data has attributes associated with it. For example, a photo has a title. These attributes are a sequence of name-value pairs, attr1 = val1, attr2 = val2,. . . Represented as:
一実施形態において、0xM.0xA:mを用いてコンテクスト0xMのデータ0xAと関連づけられた属性のシーケンスを示す。Mは、ログファイルと関連付けられた識別子であり、通常はマシン名またはIDを含むログファイルのカノニカル(canonical)URLである。前述の通り、0xAはコンテンツエントリAの識別子である。 In one embodiment, 0xM. 0xA: Indicates a sequence of attributes associated with data 0xA in context 0xM using m. M is an identifier associated with the log file and is usually a canonical URL of the log file including the machine name or ID. As described above, 0xA is the identifier of the content entry A.
コンテンツエントリとは異なり、1つのコンテクストのコンテンツと関連付けられた属性は時間的に変化できる。一実施形態では、属性エントリIDは、そのコンテクスト中の1つのコンテンツの「最新の」属性を言う。他の実施形態では、属性エントリIDを用いて、そのコンテクストの属性の履歴全体を指す。 Unlike content entries, attributes associated with content in one context can change over time. In one embodiment, the attribute entry ID refers to the “latest” attribute of a piece of content in the context. In another embodiment, the attribute entry ID is used to refer to the entire history of attributes for that context.
一実施形態では、属性識別子をティドリーウィキ(TiddlyWiki)ファイルのDIV XML要素のID属性として使用する。その場合、Mは通常、ティドリーウィキと関連付けられたログが読み出されたURLであり、Aは(個々のティドラー(tiddler)のテキストである)DIVのコンテンツである。 In one embodiment, the attribute identifier is used as the ID attribute of the DIV XML element of the TidlyWiki file. In that case, M is typically the URL from which the log associated with Tidley Wiki was read, and A is the content of the DIV (which is the text of the individual tiddler).
一実施形態では、コンテンツの履歴中の属性のセットを識別するために、0xM#nnn.0xA:mを使用できる。 In one embodiment, 0xM # nnn.0xA: m can be used to identify a set of attributes in the history of content.
mを省略できることにも留意せよ。これは、単に属性のセットの全体的長さを与えるヒントである。記法を明確にするため、コンテンツと属性エントリの:mと:nの長さのコンポーネントは、一般的に例では省略する。 Also note that m can be omitted. This is just a hint that gives the overall length of the set of attributes. For clarity of notation, the: m and: n length components of content and attribute entries are generally omitted in the examples.
チェックポイント
コンテクストはコンテンツエントリと属性エントリのシーケンスである。そのシーケンスにはいくつかのチェックポイントが含まれることが多い。一実施形態では、チェックポイントは0xCC#0nと表される。ここで、0xCC=SHA1(0xC#0n−1,ABC)である。すなわち、前のチェックポイント0xC#n−1のハッシュに先行チェックポイントと計算される新しいチェックポイント間のすべてのエントリを連結したもののハッシュである。0nはこのチェックポイントのインデックスである。そのインデックスはシーケンス中のすべてのチェックポイントについて単調増加する。
A checkpoint context is a sequence of content entries and attribute entries. The sequence often includes several checkpoints. In one embodiment, the checkpoint is represented as 0xCC # 0n. Here, 0xCC = SHA1 (0xC # 0n-1, ABC). That is, the hash of the previous checkpoint 0xC # n-1 concatenated with all entries between the previous checkpoint and the calculated new checkpoint. 0n is the index of this checkpoint. The index increases monotonically for every checkpoint in the sequence.
これらのチェックポイントは、以下に説明するプロセスの同期と監査のためのログファイルで主として使用される。 These checkpoints are mainly used in the log files for process synchronization and audits described below.
HTTP API
一実施形態では、デジタル交換の中核となる組み立てブロックは4つの方法である。それらの方法は、コンテンツエントリをアップロードするメカニズム、コンテンツエントリをダウンロードするメカニズム、コンテンツ属性をアップロードするメカニズム、及びコンテンツ属性をダウンロードするメカニズムである。以下、これらのプロセスをウェブクライアントとウェブサーバ間のインターラクション(interaction)として説明する。留意すべきことは、交換の状況に応じてその他の多数の実施形態が可能だということである。特に、共有記録API(Shared Records API)は、これらの方法のJAVA(登録商標)ベースのプログラムインターフェイスを記述する。
HTTP API
In one embodiment, the core block of digital exchange is four ways. These methods are a mechanism for uploading content entries, a mechanism for downloading content entries, a mechanism for uploading content attributes, and a mechanism for downloading content attributes. Hereinafter, these processes will be described as interactions between the web client and the web server. It should be noted that many other embodiments are possible depending on the exchange situation. In particular, the Shared Records API describes a JAVA (registered trademark) based program interface for these methods.
ポストコンテンツ
クライアントはHTTP POSTメソッドを使用して、RFC1867で規定されたマルチパート/フォームデータエンコーディング(multipart/form-data encoding)サーバにデジタルデータファイルを送信する。「コンテンツトランスファエンコーディング」ヘッダ(“content-transfer-encoding” header)によりデータをデコードしてから、そのデータのSHA1ハッシュを計算する。上記の通り、この識別子はこのコンテンツを指すときに使用する。サーバは、通常、そのデータファイルを読み出すために使用できるURLの一部として、その識別子をクライアントに返す。(以下のコンテンツ取得のセクションを参照せよ。)
一実施形態では、データはローカルの記憶ディレクトリ内のファイルに記憶される。コンテンツのフィンガープリント0xAは、GUIDとも呼ぶが、ファイル名として使用される。また、GUIDはサーバのデータベースに記憶されてもよい。
The post content client uses the HTTP POST method to send the digital data file to a multipart / form-data encoding server defined in RFC1867. After the data is decoded by the “content-transfer-encoding” header, the SHA1 hash of the data is calculated. As described above, this identifier is used to indicate this content. The server typically returns its identifier to the client as part of a URL that can be used to read the data file. (See the content acquisition section below.)
In one embodiment, the data is stored in a file in the local storage directory. The content fingerprint 0xA, which is also called a GUID, is used as a file name. The GUID may be stored in a database of the server.
一実施形態では、この時点で、サーバはそのサーバのマスターログにそのGUIDを登録し、このGUIDの新しいログを作成する(このGUIDはこのサーバに始めてのものであると仮定する)。(以下のロギングのセクションを参照せよ。)
アプリケーションに応じて動作やフィールド名はカスタマイズしてもよい。例えば、一実施形態では、「アップロード(upload)」を動作として使用し(例えば、http://server.org/upload)、「データ」をファイルのコンテンツのフィールド名として使用する。
In one embodiment, at this point, the server registers its GUID in its master log and creates a new log for this GUID (assuming this GUID is the first for this server). (See the logging section below.)
The operation and field names may be customized according to the application. For example, in one embodiment, “upload” is used as the action (eg, http://server.org/upload), and “data” is used as the field name for the contents of the file.
他の実施形態では、ファイル名をファイルデータを含むMIME部のヘッダの属性として使用する。この属性(及びその他の属性)が属性エントリとしてコンテンツエントリと関連づけられる。一実施形態では、このファイル名のファイル拡張子をそのファイルのローカルに保存されたコピーの拡張子として使用する。 In another embodiment, the file name is used as an attribute of the header of the MIME part including file data. This attribute (and other attributes) is associated with the content entry as an attribute entry. In one embodiment, the file extension of this filename is used as the extension for the locally stored copy of the file.
コンテンツ取得
一実施形態では、クライアントはHTTP GETメソッドを用いてサーバにGUIDに関連付けられたデータを要求する。この要求のURLは通常:
http://server.org/0xA/0xA
ここで、最初の0xAはコンテンツの(記憶場所を識別するための)GUIDであり、次の0xAは実際のデータを指す。(任意的にこのGUIDには拡張子.extが加えられる。)サーバは対応するデータに応答する。一実施形態では、この応答のヘッダにはそのコンテンツと関連付けられた(MIMEタイプを含む)様々な属性が含まれる。
In one embodiment of content acquisition, the client requests data associated with the GUID from the server using an HTTP GET method. The URL for this request is usually:
http://server.org/0xA/0xA
Here, the first 0xA is the GUID (for identifying the storage location) of the content, and the next 0xA indicates the actual data. (Optionally the extension .ext is added to this GUID.) The server responds to the corresponding data. In one embodiment, the header of this response includes various attributes (including MIME types) associated with the content.
クライアントは、ダウンロードしたデータのSHA1ハッシュを計算し、識別子0xAと比較して、そのデータを確認(verify)することができる。 The client can calculate the SHA1 hash of the downloaded data and compare it with the identifier 0xA to verify the data.
このダウンロードのパスコンポーネント(path component)はローカルのアプリケーションに対してカスタマイズされてもよい。例えば、パスコンポーネントは次の通りである:
http://server.org/download/0xA。
しかし、既存のキャッシングメカニズムを利用しやすくするために、一実施形態では、GUIDは、URLのクエリ成分ではなく、パスの一部、好ましくはパスの最後の「ファイル名」部分として規定される。クエリストリングにGUIDを使用して、0xAのコンテクストに関連づけられた属性にアクセスするために、以下ではhttp://server.org/get?uid=0xAなどを使用する。0xAはグローバルで一意的なので、パス成分はデータを位置特定するには必要ない。一実施形態では、クライアントと中間サーバは要求を傍受(intercept)して、キャッシュに対応するデータがあればそれを回答する。また、一実施形態では、HTML文書内のコンテンツファイルの参照は、「href=0xA」の形で行われ、ローカルの参照とグローバルの参照の間の変換の問題を避ける。
This download path component may be customized for local applications. For example, the path component is:
http://server.org/download/0xA.
However, to facilitate the use of existing caching mechanisms, in one embodiment the GUID is defined as part of the path, preferably the last “file name” part of the path, rather than the query component of the URL. In order to access the attribute associated with the context of 0xA using the GUID in the query string, http://server.org/get?uid=0xA is used below. Since 0xA is globally unique, the path component is not required to locate the data. In one embodiment, the client and intermediate server intercept the request and answer any data corresponding to the cache. Also, in one embodiment, content file references in HTML documents are made in the form of “href = 0xA” to avoid the problem of conversion between local and global references.
ポスト(Post)属性
一実施形態では、クライアントはHTTP POSTメソッドを使用して属性をサーバに送信し、要求は2つのパラメータUIDとDIVSを含み、application/x-www-form-urlencodedエンコーディングを用いて送信される。
Post attribute In one embodiment, the client uses the HTTP POST method to send the attribute to the server, the request includes two parameters UID and DIVS, using application / x-www-form-urlencoded encoding. Sent.
例として、server.org上のファイル0xAに関連付けられたコメント「Aコメント」をアップロードするために使用できるURLを以下に示す。 As an example, the URL that can be used to upload the comment “A comment” associated with file 0xA on server.org is shown below.
http://server.org/ 0xA&DIVS=<div title=’’A Comment’’>body of comment</div>
この例は、POSTメソッドではなくHTTP GETメソッドを用いて、HTTP要求のURLを用いて示されている。GETメソッドでは、DIVSパラメータがURLのクエリストリング(query string)として含まれる。POSTメソッドでは、これらのパラメータはサーバに送信される要求メッセージの本文に含まれる。実際、ほとんどのウェブアプリケーションはこれら2つの要求メソッドを同一に扱い、URLの長さの限度を超えない少量データの場合は、クライアントは一般的にクライアントは一般的にいずれのアプローチを使用することもできる。一般に、POSTメソッドを使用する方が安全である。
http://server.org/ 0xA & DIVS = <div title = '' A Comment ''> body of comment </ div>
This example is shown using the HTTP request URL using the HTTP GET method instead of the POST method. In the GET method, the DIVS parameter is included as a URL query string. In the POST method, these parameters are included in the body of the request message sent to the server. In fact, most web applications treat these two request methods the same, and for small amounts of data that do not exceed the URL length limit, the client will generally use either approach. it can. In general, it is safer to use the POST method.
留意すべきことは、この例は、ティドリーウィキ(TiddlyWiki)の「ティドラー(tiddlers)」をアップロードするモデルのものだということである。共有レコードAPI(SharedRecords API)の場合、レコードに関連付けられたメタデータのポスティングにはすこし違うフォーマットが使用されるが、基本的な考え方は同じである。 Note that this example is for a model that uploads TiddlyWiki's "tiddlers". In the case of a shared record API (SharedRecords API), a slightly different format is used for posting metadata associated with a record, but the basic idea is the same.
この場合、XMLをDIVの要素のフィールド値として使用する。このXMLは、個々のDIV要素により構成され、属性エントリとコンテンツエントリの両方を同時に指定することができる。コンテンツエントリはDIV要素の本文である。DIV要素の属性の名前−値ペアは、UIDにより画成されたコンテンツのそのコンテンツエントリに関係づけられた属性である。留意すべきことは、HTTP要求自体の名前=値ペアを使用して属性エントリを指定することもあることである。これは可能だが2つの問題が生じる。第1の問題は、アップロードを処理するウェブアプリケーションがそれ自体のためにUID等の特定のフィールド名を使用していると、名前の衝突が発生する可能性があることである。第2の問題は、ほとんどのウェブアプリケーションは、POST要求のためのフィールド名を含む入力が適切なものであるか確認するように書かれていることである。フィールド名と値の範囲を不必要に制限することなくこの種の確認を正しいエントリにする必要はない。属性エントリ自体をXMLとしてエンコードし、それを指定されたフィールドの値として送信すれば、これらの問題は回避できる。ちなみに、そうすると、クライアントでの処理が非常に容易にもなる。クライアントはローカルの記憶領域に記憶されたまだ解析していないDIVSだけを送信できるからである。 In this case, XML is used as the field value of the DIV element. This XML is composed of individual DIV elements, and both attribute entries and content entries can be specified at the same time. The content entry is the body of the DIV element. An attribute name-value pair of a DIV element is an attribute associated with that content entry of the content defined by the UID. It should be noted that the attribute entry may be specified using the name = value pair of the HTTP request itself. This is possible but causes two problems. The first problem is that name collisions can occur if the web application that handles the upload uses a specific field name such as a UID for itself. A second problem is that most web applications are written to verify that the input containing the field name for the POST request is appropriate. This type of confirmation need not be a correct entry without unnecessarily restricting the range of field names and values. These problems can be avoided by encoding the attribute entry itself as XML and sending it as the value of the specified field. By the way, processing on the client becomes very easy. This is because the client can only send a DIVS stored in the local storage area and not yet analyzed.
この要求を受信すると、サーバはコンテンツエントリ0xDのGUIDを計算し、関連する属性エントリである例えば0xM.0xDのGUIDを計算する。コンテンツエントリと属性エントリは、コンテクスト0xMと関連付けられたログに記憶される。 Upon receiving this request, the server calculates the GUID of the content entry 0xD and the associated attribute entry, eg 0xM. Calculate the GUID of 0xD. The content entry and attribute entry are stored in a log associated with context 0xM.
一実施形態では、サーバは、これらの属性エントリを受けるか否か決定しGET ATTRIBITESメソッドで利用できるようにする前に、別のいくつかのチェックをする。グローバルに一意的かつ不変なコンテンツエントリとは異なり、属性エントリはサーバコンテンツに固有である。 In one embodiment, the server makes several other checks before deciding whether to receive these attribute entries and making them available with the GET ATTRIBITES method. Unlike globally unique and immutable content entries, attribute entries are specific to server content.
チェックが無事終了すると、サーバは指定されたコンテクストに関連するサーバ上の最新のチェックポイントを返す。様々な実施形態ではチェックが無事終了した時に返すものが異なる。もっとも新しいチェックポイントを返すことにより、クライアントはそのローカルな属性シーケンスがサーバのものと一致するか否か確認できる。留意すべきことは、クライアントはチェックポイント以降、常にサーバに属性のセットを問い合わせることもできることである。これについては後でより詳しく説明する。 If the check is successful, the server returns the latest checkpoint on the server associated with the specified context. In various embodiments, what is returned when the check is successful is different. Returning the most recent checkpoint allows the client to check whether its local attribute sequence matches that of the server. It should be noted that the client can always query the server for a set of attributes after the checkpoint. This will be described in more detail later.
ポスト(Post)属性コンテクスト
上記の通り、コンテクスト識別子0xMは一般的に2つの一意的識別子からできる。一実施形態では、カノニカルURL(canonical URL)のハッシュを、コンテクストを読み出すためにそのコンテクストの識別子として使用する。上記の例では、Mは次のURLのハッシュに等しい:
http://server.org/get?UID=0xA
これは、server.org上の0xAと関連する属性シーケンスを求めるURLとして機能する。以下に詳細に説明する。
Post attribute context As described above, the context identifier 0xM is generally made up of two unique identifiers. In one embodiment, a hash of a canonical URL is used as the context identifier to retrieve the context. In the above example, M is equal to the hash of the following URL:
http://server.org/get?UID=0xA
This serves as the URL for the attribute sequence associated with 0xA on server.org. This will be described in detail below.
プログラマは、Mを名前空間と考え、あるサーバでどの名前空間を使用するか選択するために0xAを使用する。1つのサーバは異なる多数の「名前空間(namespace)」を有してもよいし、同じ「名前空間」が異なる多数のサーバ上にあってもよい。(以下、本明細書では、0xAに対して「名前空間」ではなく「デジタルデータ」または「文書」という用語を使用する。しかし、0xAが何らかの既知のデータのハッシュに対応しなければならないとの必要性はない。このため、この識別子は正しい統語仕様(syntactic conventions)に沿っていればいかなる文字列であってもよい。 The programmer considers M as a namespace and uses 0xA to select which namespace to use on a server. One server may have many different “namespaces”, or the same “namespace” may be on many different servers. (Hereinafter, we will use the term “digital data” or “document” instead of “namespace” for 0xA. However, 0xA must correspond to a hash of some known data. There is no need, so this identifier can be any string that conforms to the correct syntactic conventions.
URLのハッシュをコンテクスト識別子として使用すると、クライアントが属性シーケンスの信ぴょう性を確認するために使用した他の情報が提供される。特に、以下に説明するように1組の属性を読み出すとき、一実施形態では、クライアントは要求URLに基づいて識別子を計算し、それを要求に応答して返された属性エントリ識別子と一致するか確認する。 Using the URL hash as a context identifier provides other information that the client has used to verify the authenticity of the attribute sequence. In particular, when reading a set of attributes as described below, in one embodiment, the client calculates an identifier based on the request URL and matches it with the attribute entry identifier returned in response to the request. Check.
サーバは異なるコンテクストのエントリを受け取ることもできる。例えば、クライアントは、異なるコンテクストを指定するID属性をすでに有するDIVをアップロードしてもよい。これをどう処理するかはサーバにより異なってもよい。サーバは、「無関係な(foreign)」コンテクスト識別子を有するその属性を、GET要求に応答して返す属性に含めてもよい。サーバは、かかるエントリを自機のエントリとして受けてもよいし、そのコンテクストから新しい識別子を割り当ててもよい。これについては、以下に同期とともに説明する。 The server can also receive entries for different contexts. For example, a client may upload a DIV that already has an ID attribute that specifies a different context. How this is handled may vary from server to server. The server may include that attribute with a “foreign” context identifier in the attributes returned in response to the GET request. The server may receive such an entry as its own entry, or may assign a new identifier from the context. This will be described below together with synchronization.
属性取得(get attributes)
一実施形態では、1組の属性を読み出すため、クライアントは次の形式のURLを有するHTTP GETを使用する:
http://server.org/get?UID=0xA
これにより、1組の属性を含むHTML文書またはXML文書が返される。ティドリーウィキ(TiddlyWiki.org)の場合、これはJava(登録商標)Scriptヘッダとそれに続くDIV要素のシーケンスを含む「記憶領域」を含むティドリーウィキそのものである。一実施形態では、各DIV要素は0xM.0xDの形のIDを有する。ここでDはDIV要素の本文のハッシュである。別の実施形態では、最初の送信では本文は省略され、AJAXスタイルのJava(登録商標)Script要求を用いるGET CONTENTの上記方法を用いて読み出される。これにより、大きなデータを含むティドラー(tiddlers)の効率が大幅に高くなる。
Get attributes
In one embodiment, to retrieve a set of attributes, the client uses an HTTP GET with a URL of the following form:
http://server.org/get?UID=0xA
This returns an HTML or XML document that contains a set of attributes. In the case of TiddlyWiki (TiddlyWiki.org), this is the Tidley Wiki itself that includes a “storage area” that includes a Java® Script header followed by a sequence of DIV elements. In one embodiment, each DIV element is 0xM. It has an ID of the form 0xD. Here, D is a hash of the body of the DIV element. In another embodiment, the body is omitted from the initial transmission and is read using the above method of GET CONTENT using an AJAX style JavaScript request. This greatly increases the efficiency of tiddlers that contain large amounts of data.
この応答は、サーバの現在の状態を表すチェックポイント(CHECKPOINT)識別子を含んでもよい。通常、これは記憶領域を含むDIVのID要素、すなわち、0xAに関連付けられた属性に対応する1組のDIVを含む要素として含まれる。 This response may include a CHECKPOINT identifier that represents the current state of the server. Usually this is included as an ID element of the DIV that contains the storage area, ie, an element that contains a set of DIVs corresponding to the attribute associated with 0xA.
公開(publish)
上記の4つの方法は、クライアントとサーバ間でデータを交換するための基本的な要素である。同期と監査(auditing)に関する方法を以下に説明する。これらの方法は、サーバ間の通信及びトラッキング機能に有用である。
Publish
The above four methods are basic elements for exchanging data between a client and a server. Methods for synchronization and auditing are described below. These methods are useful for server-to-server communication and tracking functions.
また、「草稿」情報と「公開」情報を区別することが必要な場合が多い。特に、1つのコンテクストと関連付けられたすべての属性エントリが、その情報を利用可能とする前にサーバにより登録されていることの確認をユーザまたはプロセスは欲することがある。換言すると、1組の属性の一貫性をそれが公開される前に確認することを欲することがある。 Also, it is often necessary to distinguish between “draft” information and “public” information. In particular, a user or process may want confirmation that all attribute entries associated with a context have been registered by the server before making that information available. In other words, you may want to check the consistency of a set of attributes before they are published.
一実施形態では、これを実現するため、クライアントはURLの「公開(PUBLISH)」パスまたはクエリコンポーネントを有するHTTP GETメソッドを使用する。例えば、
http://server.org/publish?UID=0xA&CHECKPOINT =0xCC
は、UID0xAからチェックポイント0xCCまでに関連する1組のエントリを公開するようにサーバに命じる。
In one embodiment, to accomplish this, the client uses an HTTP GET method with a “PUBLISH” path or query component of the URL. For example,
http://server.org/publish?UID=0xA&CHECKPOINT=0xCC
Tells the server to publish a set of entries related to UID0xA through checkpoint 0xCC.
ティドリーウィキの場合、これは既知の記憶場所にある静的なHTMLファイルを公開することに対応する。記憶場所とは、例えば、:
http://server.org/ 0xA/index.html
この命令が無事に実行されると、上記のURLがHTMLページの一部として読み出され、クライアントに送信される。
In the case of Tidley Wiki, this corresponds to publishing a static HTML file in a known storage location. Examples of storage locations are:
http://server.org/ 0xA / index.html
If this command is executed successfully, the above URL is read out as a part of the HTML page and transmitted to the client.
エラー
上記の通信では、要求が失敗した場合、一般的なHTTPエラーはすべてクライアントに返されてもよい。
Errors In the above communication, if the request fails, all common HTTP errors may be returned to the client.
しかし、一実施形態では、追加的エラー条件が使用され処理される。この追加的エラー条件には、「GUIDミスマッチ(GUID Mismatch)」と「無効属性エントリ(Invalid Attribute Entries)」エラー条件が含まれる。 However, in one embodiment, additional error conditions are used and handled. This additional error condition includes a “GUID Mismatch” and an “Invalid Attribute Entries” error condition.
GUIDミスマッチ−ダウンロードしたデータのハッシュが要求された識別子にマッチしない場合、これはクライアントが処理するエラー条件を構成する。それはなりすまし(spoofing)か、または単なるデータの破損を意味する。 GUID mismatch-if the hash of the downloaded data does not match the requested identifier, this constitutes an error condition for the client to handle. It means spoofing or just data corruption.
無効属性エントリ−サーバはクライアントからの属性エントリの一部または全部の受け取りを拒否する。これにより、クライアントはサーバと同期しなくなる。これはクライアントがサーバから帰されたチェックポイントを確認(verifying)するか、最新バージョンを要求することによりテストされ得る。いずれの場合にも、この条件もクライアントにより処理される。 Invalid attribute entry—The server refuses to accept some or all of the attribute entries from the client. This causes the client to become out of sync with the server. This can be tested by the client verifying the checkpoint returned from the server or by requesting the latest version. In either case, this condition is also handled by the client.
ロギングファイルフォーマット(Logging File Format)
サーバに記憶された各コンテクストに対して、サーバはコンテクストログを持っている。一実施形態では、これは「付加のみ(append only)」のファイルフォーマットである。
Logging file format
For each context stored in the server, the server has a context log. In one embodiment, this is an “append only” file format.
ログファイルフォーマット自体は3種類のアイテム、すなわちコンテンツエントリ(ContentEntries)、属性エントリ(AttributeEntries)及びチェックポイント(Checkpoints)を含む。上記の定義を用いて、ログファイルのフォーマットは以下の通りである:
コンテンツエントリ−ストリングエントリは0xA:nストリング(STRING)から構成される。ここでストリングはエントリのコンテンツであり、nはストリング中の文字(バイト)数であり、0xAはストリングのハッシュである。
The log file format itself includes three types of items: content entries (ContentEntries), attribute entries (AttributeEntries), and checkpoints (Checkpoints). Using the above definition, the log file format is as follows:
The content entry-string entry is composed of 0xA: n string (STRING). Here, the string is the contents of the entry, n is the number of characters (bytes) in the string, and 0xA is a hash of the string.
属性エントリ−属性エントリは0xM.0xA:m属性1=値1 属性2=値2により構成される。Mは属性割り当てのコンテンツと呼ばれる。Mは、ログファイルと関連付けられた識別子であり、通常はマシン名またはIDを含むログファイルのカノニカル(canonical)URLである。上記の通り、0xAはコンテンツエントリAの識別子であり、属性1は第1の属性のラベルであり、値1はコンテンツMのコンテンツAのその属性と関連付けられた値である。スペースで隔てられた属性値ペアはいくつあってもよい。mは属性値ペアのリスト中の全文字数であり、空白のデリミタ(delimiters)を含む。 Attribute entry-The attribute entry is 0xM. 0xA: m attribute 1 = value 1 attribute 2 = value 2 M is called attribute assignment content. M is an identifier associated with the log file and is usually a canonical URL of the log file including the machine name or ID. As described above, 0xA is the identifier of the content entry A, the attribute 1 is the label of the first attribute, and the value 1 is a value associated with the attribute of the content A of the content M. There can be any number of attribute-value pairs separated by spaces. m is the total number of characters in the list of attribute value pairs, including blank delimiters.
チェックポイント−チェックポイントは0xCC#0nで表される。ここで、0xCC=SHA1(0xC#0n−1,ABC)である。すなわち、前のチェックポイント0xC#n−1のハッシュにそのチェックポイントと計算される新しいチェックポイント間のすべてのエントリ(例えば、ABC)を連結したもののハッシュである。0nはファイル中のすべてのチックポイントに対して単調増加するチェックポイントのインデックスである。 Checkpoint-The checkpoint is represented by 0xCC # 0n. Here, 0xCC = SHA1 (0xC # 0n-1, ABC). That is, the hash of the previous checkpoint 0xC # n-1 concatenated with all entries (eg, ABC) between that checkpoint and the new checkpoint being calculated. 0n is a checkpoint index that monotonically increases for all tick points in the file.
一実施形態では、ログファイルは、コンテンツを表すURLそのものであるコンテンツエントリで始まる。そのURLは、すなわち、このログファイルのコンテンツを読み出すことができるカノニカルな記憶場所(canonical location)である。ログファイルのエントリの第1の例は:
0xM:25 http://server.org/0xABC/ 0Xcc#0001
これは、サーバ(server.org)と名付けられたマシン上の識別子0xABC(一般的に、これはこのマシン上のコンテンツまたは「名前空間」であるデジタルデータのハッシュである)と関連付けられたログである。0xCCはストリング「0xM:25 http://server.org/0xABC/」のハッシュである。チェックポイントはいつファイルに挿入されてもよい。一実施形態では、チェックポイントは各ポスト(POST)要求の後に挿入される。
In one embodiment, the log file begins with a content entry that is the URL itself representing the content. That URL is a canonical location from which the contents of this log file can be read. The first example of a log file entry is:
0xM: 25 http://server.org/0xABC/ 0Xcc # 0001
This is the log associated with the identifier 0xABC on the machine named server (server.org) (typically this is the hash of the digital data that is the content or “namespace” on this machine) is there. 0xCC is a hash of the string “0xM: 25 http://server.org/0xABC/”. Checkpoints may be inserted into the file at any time. In one embodiment, a checkpoint is inserted after each post (POST) request.
留意すべきことは、この場合、0xMは、このファイル中の属性エントリに割り当てられたGUIDの一部として使用されるコンテクスト識別子に厳密に一致(corresponds)することである。
一実施形態では、属性エントリは、0xM.0xD:29タイトル=A「コンテンツ」修正=「2005年12月22日」のようなものである。これはこのコンテンツ中の(ハッシュ値0xDを有する)コンテンツのタイトルと修正日を示す。一実施形態では、ティドリーウィキの場合、コンテンツはストリングのコメントであり、おそらく前にファイル中に現れている:
0xD:17 コメントの本文
しかし、コンテンツがログファイル中に現れなければならないという必要性はない。コンテンツがファイルに含まれていなくても、GUIDは属性識別子の一部として現れる。これはコンテンツが別のところに記憶された画像等の大きなファイルである場合に、特に有用である。コンテンツログファイルの一例は以下の通りである。
It should be noted that in this case, 0xM closely matches the context identifier used as part of the GUID assigned to the attribute entry in this file.
In one embodiment, the attribute entry is 0xM. 0xD: 29 title = A “content” modification = “December 22, 2005”. This indicates the title and modification date of the content (having the hash value 0xD) in this content. In one embodiment, for Tidley Wiki, the content is a string comment, presumably appearing earlier in the file:
0xD: 17 Comment body However, it is not necessary that the content must appear in the log file. Even if the content is not included in the file, the GUID appears as part of the attribute identifier. This is particularly useful when the content is a large file such as an image stored elsewhere. An example of the content log file is as follows.
図1を参照して、本プロセスは、処理ロジック(processing logic)が、コンテンツのシーケンスと、1つ以上のチェックポイントにより区切られた各コンテンツに関連する属性エントリとを含むファイルフォーマットを有するコンテクストログを作成(maintain)することにより始まる(処理ブロック101)。一実施形態では、1つのコンテンツエントリはストリングのハッシュとそのストリングとを有するベクトルを含む。一実施形態では、1つの属性エントリは、コンテンツエントリの識別子と、コンテンツ中のそのコンテンツエントリの属性のラベルとその属性に関連付けられた値とにより構成された1つ以上のペアとをつなげた、ログファイルと関連付けられた識別子を含むエントリを有するベクトルを有する。一実施形態では、コンテンツエントリの識別子はそのコンテンツエントリのハッシュを有し、ログファイルと関連付けられた識別子は属性割り当てのコンテクストのハッシュを含む。一実施形態では、少なくとも1つのチェックポイントは、前のチェックポイントのハッシュに、その前のチェックポイントとその少なくとも1つのチェックポイントとの間のすべてのエントリがつながったものを含む。一実施形態では、コンテクストは、第1と第2の識別子の組み合わせである。第1の識別子はマシンを識別し、第2の識別子はデジタルデータのグループを識別する。 Referring to FIG. 1, the process includes a context log having a file format in which processing logic includes a sequence of content and attribute entries associated with each content separated by one or more checkpoints. Is started (processing block 101). In one embodiment, one content entry includes a vector having a hash of the string and the string. In one embodiment, an attribute entry connects one or more pairs consisting of an identifier of a content entry, a label of the attribute of the content entry in the content, and a value associated with the attribute, Having a vector with an entry containing an identifier associated with the log file. In one embodiment, the identifier of the content entry has a hash of the content entry, and the identifier associated with the log file includes a hash of the attribute assignment context. In one embodiment, the at least one checkpoint includes a hash of the previous checkpoint plus all entries between the previous checkpoint and the at least one checkpoint. In one embodiment, the context is a combination of first and second identifiers. The first identifier identifies the machine and the second identifier identifies a group of digital data.
そのあと、処理ロジック(processing logic)はコンテクストログにアクセスしてそこに記憶されている情報をレビューする(処理ブロック102)。 Thereafter, processing logic accesses the context log to review the information stored therein (processing block 102).
特性
上記の通り、一実施形態では、ログファイルは、チェックポイントにより区切られたコンテンツと属性エントリのシーケンスにより構成される。一実施形態では、このファイルは「付加のみ(append only)」である。換言すると、すべてのエントリはファイルの終わりに付加され、一旦エントリがされるとそれは変更できない。
Characteristics As described above, in one embodiment, a log file is composed of a sequence of content and attribute entries separated by checkpoints. In one embodiment, this file is “append only”. In other words, all entries are appended to the end of the file and once an entry is made it cannot be changed.
図2は、コンテクストログ修正プロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア(例えば回路、専用ロジック等)、(汎用コンピュータシステムまたは専用機上で実行される)ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。 FIG. 2 is a flow diagram illustrating one embodiment of a context log modification process. This process is performed by processing logic including hardware (eg, circuitry, dedicated logic, etc.), software (running on a general purpose computer system or a dedicated machine), or a combination of these.
図2を参照して、本プロセスは、処理ロジック(processing logic)が、コンテンツのシーケンスと、1つ以上のチェックポイントにより区切られた各コンテンツに関連する属性エントリとを含むファイルフォーマットを有するコンテクストログを作成(maintain)することにより始まる(処理ブロック201)。そのあと、処理ロジック(processing logic)はコンテクストログにアクセスしてそこに記憶されている情報をレビューする(処理ブロック202)。処理ロジックは、コンテクストログの終わりに新しいエントリを付加することによりコンテンツログを修正する(処理ブロック203)。 Referring to FIG. 2, the process includes a context log having a file format in which processing logic includes a sequence of content and attribute entries associated with each content separated by one or more checkpoints. Is started (processing block 201). Thereafter, processing logic accesses the context log to review the information stored therein (processing block 202). Processing logic modifies the content log by appending a new entry to the end of the context log (processing block 203).
ファイルは、そのリーダがすべてのチェックポイントを計算してログのインテグリティ(integrity)を確認できるという意味で、自己確認的(self-verifying)である。ファイルの一部が破損していても、そのファイルの残りは依然として有効である。ただし、履歴(history)は破損後の最初のチェックポイントまでしかたどれない。 The file is self-verifying in the sense that its reader can calculate all checkpoints to verify the integrity of the log. If part of a file is damaged, the rest of the file is still valid. However, the history can only be traced to the first checkpoint after corruption.
そのファイルは非常に解析しやすい。すべての有効なエントリは、0xで始まり、有限数の空白を含まない文字が続く。これは識別されたラベルまたはエントリと呼ばれる。一実施形態では、チェックポイントは固定サイズであり、エントリの長さはエントリ識別子中に含まれている。改行文字がエントリとチェックポイントを分離する。これは、パーサ(parser)がエントリの実際のコンテンツをスキップできることを意味する。また、ファイルのサイズは、エントリとチェックポイントのサイズと数が分かっている場合、予想できることを意味する。 The file is very easy to analyze. All valid entries begin with 0x and are followed by a finite number of non-blank characters. This is called an identified label or entry. In one embodiment, the checkpoint is a fixed size and the length of the entry is included in the entry identifier. A newline character separates the entry from the checkpoint. This means that the parser can skip the actual content of the entry. Also, the file size means that it can be predicted if the size and number of entries and checkpoints are known.
一実施形態では、スレッド問題(threading issues)を回避するため、コンテクストログファイルに書き込んでいるプロセスは、ファイルに付加するとき、そのファイルをロックする。留意すべきことは、このロックは、チェックポイントを含むエントリを書き込むのに必要な限りにおいて維持されることである。ファイルに書き込む前に、本プロセスはファイルの終わりを見つけて、最後のNバイトが有効なチェックポイントを構成することを確認する。(チェックポイントのサイズは一定であり、慣例的に、ファイルはチェックポイントで終わるので、これは簡単な動作である。)このチェックポイントは、書き込まれるログエントリの付加の最後に、付加すべき次のチェックポイントの計算に使用される。 In one embodiment, to avoid threading issues, a process writing to a context log file locks the file when appending to the file. Note that this lock is maintained as long as necessary to write the entry containing the checkpoint. Before writing to the file, the process finds the end of the file and verifies that the last N bytes constitute a valid checkpoint. (This is a simple operation because the size of the checkpoint is constant and, by convention, the file ends with a checkpoint.) This checkpoint is the next to be appended at the end of appending log entries to be written. Used for the calculation of checkpoints.
拡張子(Extensions)
慣例により、コンテクストの現在のログファイルは「インデックス.ログ(index.log)」と名付けられ、0xABCと名付けられたディレクトリに格納される。ここで0xABCはコンテクスト識別子のGUIDコンポーネントである。言い換えると、このログファイルがデジタルファイルのイベントまたは処理のログである場合、0xABCはそのファイルのハッシュである。ログファイルはいくらでも大きくなるので、コンテクストログは別のファイルにすると便利である。そうするために、現在のログファイル、例えばインデックス.ログのハッシュを計算し、インデックス.ログファイルをその値(例えば、0xFFFがそのファイルのハッシュ値である場合、0xFFF.log)で名前の付け替えをする。この時点では、ファイル0xFFF.logは、何らかの変化をすればファイル中のデータのハッシュ値とファイル名とが異なるので、「不変である(immutable)」と考えられる。
Extensions
By convention, the context's current log file is named “index.log” and is stored in a directory named 0xABC. Here, 0xABC is a GUID component of the context identifier. In other words, if this log file is a digital file event or process log, 0xABC is the hash of that file. Since the log file can grow as much as you like, it is convenient to keep the context log in a separate file. To do so, the current log file, eg index. Calculate log hash and index. Rename the log file with its value (for example, 0xFFF.log if 0xFFF is the hash value of the file). At this point, the file 0xFFF. The log is considered to be “immutable” because the hash value of the data in the file and the file name differ if any change is made.
新しいindex.logファイルを生成する。そのファイルの第1ラインは前のファイルに書き込まれた最後のチェックポイント(すなわち、0xFFF.log中の最後のチェックポイント)のコピーである。次に、属性エントリが新しく生成されたindex.logに書き込まれ、0xFFFがこのログの前のバージョンであることを示す。例えば、属性エントリはは次の通りである:
0xM.0xFFF:22_type=previous_log file_location=0xFFF.log
この場合、プライベート情報に使用される_typeはこのコンテクストにあり、ハッシュ0xFFFを有するコンテンツは、このコンテンツ内の前のログエントリから構成されていると識別する。また、ファイル記憶場所(file_location)はローカルマシン上のファイルを見つけるヒントとして提供される。チェックポイント数やそのログファイル中の最後のチェックポイントの追加情報を属性として提供することもできる。
New index. Generate a log file. The first line of that file is a copy of the last checkpoint written to the previous file (ie, the last checkpoint in 0xFFF.log). Next, the newly created index. written to log, indicating that 0xFFF is the previous version of this log. For example, the attribute entry is:
0xM.0xFFF: 22_type = previous_log file_location = 0xFFF.log
In this case, the _type used for the private information is in this context, and the content with hash 0xFFF is identified as consisting of the previous log entry in this content. The file storage location (file_location) is provided as a hint for finding a file on the local machine. Additional information about the number of checkpoints and the last checkpoint in the log file can also be provided as attributes.
このように、1つの大きな「仮想」コンテクストログを形成するファイルのチェーン全体を生成できる。現在のインデックス.ログファイル以外のすべてのファイルは不変なので、他のコンテンツとして取り扱うこともできる。例えば、それらのファイルを他のサーバに格納及び/またはキャッシュすることもできる。 In this way, the entire chain of files that forms one large “virtual” context log can be generated. The current index. All files other than log files are immutable and can be handled as other content. For example, the files can be stored and / or cached on other servers.
マスターコンテクストファイル
一実施形態では、マスターコンテクストファイルを使用してサーバ上の重要な変更を記録する。例えば、新しいコンテンツエントリがサーバにアップロードされるたびに、及び/または新しいコンテンツログが生成されるたびに、マスターコンテンツファイルはその事実を記録するために修正される。このように、マスターコンテクストファイルはマスターログとして機能する。
Master Context File In one embodiment, a master context file is used to record important changes on the server. For example, each time a new content entry is uploaded to the server and / or a new content log is generated, the master content file is modified to record that fact. Thus, the master context file functions as a master log.
一実施形態では、このマスターログにおいて、新しいコンテンツログが生成されるといつも新しい属性エントリが追加される。新しい属性エントリの例は次の通りである:
0xMASTER:0xM:22 created= “2005/12/22” data=0xA
ここで、0xMASTERはサーバのマスタコンテクストであり、0xMはサーバ上のコンテクストである。この場合、データ=0xA属性は、このコンテクストがハッシュ値0xAを有するデジタルデータと関連づけられていることを示す。任意的に、生成された属性は、いつコンテクストログファイルが最初に生成されたか示す。
In one embodiment, in this master log, new attribute entries are added whenever a new content log is generated. An example of a new attribute entry is:
0xMASTER: 0xM: 22 created = “2005/12/22” data = 0xA
Here, 0xMASTER is the master context of the server, and 0xM is the context on the server. In this case, the data = 0xA attribute indicates that this context is associated with digital data having the hash value 0xA. Optionally, the generated attribute indicates when the context log file was first generated.
一実施形態では、サーバのマスターコンテクストの識別子は、http://server.org/index.logのハッシュである。 In one embodiment, the server's master context identifier is a hash of http://server.org/index.log.
http://server.org/index.log
すべてのコンテクストファイル、及び特にマスターコンテクストファイルは、「シークレットデータ(secret data)」と関連づけられた属性エントリを含む。これは、サーバの秘密鍵を用いた「デジタル署名」である正確なエントリを含むか、またはサーバにのみ分かっているデータのハッシュである。コンテクストファイル中のこのシークレットデータと関連エントリを用いて、ログファイルの信ぴょう性を確認する。例えば、ログファイルのエントリの第1のエントリは:
0xM.0xS:12 _type=seed
ここで、0xSはサーバにだけ分かっている秘密の「シード」のハッシュである。かかるシードはログを初期化するためにいくつ使用してもよい。この最初のログは広く伝達される。サーバは、あるログを生成したことを証明するように求められると、その秘密データを提供しシードと関連させる。同様に、ログの後ろの方のエントリは、「サインされたチェックポイント(signed checkpoints)」である属性エントリであり得る。ファイル中の最も新しいのチェックポイントは、秘密シードの1つと連結され、属性エントリは例えば次のログに入れられる:
0xM.0xS22:19 _type=signed_checkpoint seed=0xS
ここで、0xS22は前のチェックポイントと0xSで特定されるシードとの連結のハッシュである。
http://server.org/index.log
All context files, and in particular the master context file, contain an attribute entry associated with “secret data”. This is a hash of data that contains an exact entry that is a “digital signature” using the server's private key, or is known only to the server. Using this secret data and related entries in the context file, the authenticity of the log file is confirmed. For example, the first entry in the log file entry is:
0xM.0xS: 12 _type = seed
Here, 0xS is a secret “seed” hash known only to the server. Any number of such seeds may be used to initialize the log. This first log is widely communicated. When the server is asked to prove that it has generated a log, it provides that secret data and associates it with the seed. Similarly, the entries later in the log can be attribute entries that are “signed checkpoints”. The most recent checkpoint in the file is concatenated with one of the secret seeds and the attribute entry is placed in the following log, for example:
0xM.0xS22: 19 _type = signed_checkpoint seed = 0xS
Here, 0xS22 is a hash of concatenation of the previous checkpoint and the seed specified by 0xS.
同期
コンテンツエントリ
一実施形態では、サーバはそのディスクにローカルに記憶されたコンテンツエントリのリストを持っている。これは、各ファイルはその識別子に従って記憶されている簡単なディレクトリリストの形であるか、または実際の記憶場所へのポインタを有する識別子のデータベースの形である。
(例えば、GET CONTENT動作を通して)あるコンテンツを求められると、サーバはこのリストをチェックして、そのリストに要求された識別子が見つかった場合、ファイル中の関連データを応答として返す。
Synchronous Content Entry In one embodiment, the server has a list of content entries stored locally on its disk. This is either in the form of a simple directory list where each file is stored according to its identifier, or in the form of a database of identifiers with pointers to actual storage locations.
When asked for some content (eg, through a GET CONTENT operation), the server checks this list and if it finds the requested identifier in that list, it returns the relevant data in the file as a response.
離れたところにあるマシンのファイルをミラーまたはバックアップするために、サーバは、そのマシンのコンテクスト識別子のリストを取得する。これは、例えば、その離れたところにあるマシンからマスタコンテクストログを取得することにより行われる。コンテクスト識別子のリストを取得すると、サーバは、そのリストからすでにローカルに記憶されている識別子をすぐに削除できる。次に、サーバは、例えばGET CONTENTメソッドを用いて、離れたところにあるマシンから新しい識別子を要求する。 To mirror or back up a file on a remote machine, the server obtains a list of context identifiers for that machine. This is done, for example, by obtaining a master context log from a machine at a distance. Having obtained a list of context identifiers, the server can immediately remove identifiers already stored locally from the list. The server then requests a new identifier from a remote machine, for example using the GET CONTENT method.
図3Aは、コンテクストログ同期プロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア(例えば回路、専用ロジック等)、(汎用コンピュータシステムまたは専用機上で実行される)ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。一実施形態では、このプロセスは、コンテクストログをサーバのコンテクストログと同期させることを欲するクライアントとともに動作するサーバにより実行される。 FIG. 3A is a flow diagram illustrating one embodiment of a context log synchronization process. This process is performed by processing logic including hardware (eg, circuitry, dedicated logic, etc.), software (running on a general purpose computer system or a dedicated machine), or a combination of these. In one embodiment, this process is performed by a server operating with a client that wants to synchronize the context log with the server's context log.
図3Aを参照して、本プロセスは、処理ロジック(processing logic)が、コンテンツのシーケンスと、1つ以上のチェックポイントにより区切られた各コンテンツに関連する属性エントリとを含むファイルフォーマットを有するコンテクストログを作成(maintain)することにより始まる(処理ブロック301)。次に、処理ロジックは、コンテクストログ中のエントリに対する要求を受信し(処理ブロック302)、そのコンテクストログにアクセスしてそれに記憶された情報を読み出し(処理ブロック303)、最初のチェックポイントの後ろにあるコンテクストログのエントリを送信して要求を満たす(処理ブロック304)。 Referring to FIG. 3A, the process includes a context log having a file format in which processing logic includes a sequence of content and attribute entries associated with each content separated by one or more checkpoints. Is started (processing block 301). Next, processing logic receives a request for an entry in the context log (processing block 302), accesses the context log and reads the information stored therein (processing block 303), after the first checkpoint. A context log entry is sent to satisfy the request (processing block 304).
図3Bは、コンテクストログ同期プロセスの他の実施形態を示すフロー図である。このプロセスは、ハードウェア(例えば回路、専用ロジック等)、(汎用コンピュータシステムまたは専用機上で実行される)ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。一実施形態では、このプロセスは、コンテクストログをサーバのコンテクストログと同期させることを欲するクライアントとともに動作するサーバにより実行される。 FIG. 3B is a flow diagram illustrating another embodiment of a context log synchronization process. This process is performed by processing logic including hardware (eg, circuitry, dedicated logic, etc.), software (running on a general purpose computer system or a dedicated machine), or a combination of these. In one embodiment, this process is performed by a server operating with a client that wants to synchronize the context log with the server's context log.
図3Bを参照して、本プロセスは、処理ロジック(processing logic)が、コンテンツのシーケンスと、1つ以上のチェックポイントにより区切られた各コンテンツに関連する属性エントリとを含むファイルフォーマットを有するコンテクストログを作成(maintain)することにより始まる(処理ブロック311)。次に、処理ロジックは、1つのチェックポイント以降に為されたコンテンツログのエントリに対する要求を受信し(処理ブロック312)、コンテクストログにアクセスしてそこに格納されている情報を見る(処理ブロック313)。処理ロジックは、次に、第1のチェックポイントがコンテクストログ中にあるかチェックする(処理ブロック314)。もしあれば、処理ロジックは、第1のチェックポイントより後ろのコンテクストログのエントリを送信して要求を満たす(処理ブロック315)。もしなければ、プロセスは終了する(処理ブロック316)。 Referring to FIG. 3B, the process includes a context log having a file format in which processing logic includes a sequence of content and attribute entries associated with each content separated by one or more checkpoints. Is started (processing block 311). Next, processing logic receives a request for a content log entry made after one checkpoint (processing block 312) and accesses the context log to view the information stored therein (processing block 313). ). Processing logic then checks to see if the first checkpoint is in the context log (processing block 314). If so, processing logic sends a context log entry after the first checkpoint to satisfy the request (processing block 315). If not, the process ends (processing block 316).
図4は、コンテクストログ中のエントリの同期プロセスの他の実施形態を示すフロー図である。このプロセスは、ハードウェア(例えば回路、専用ロジック等)、(汎用コンピュータシステムまたは専用機上で実行される)ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。一実施形態では、このプロセスは、コンテクストログを持っているサーバとともに動作するクライアントにより実行される。 FIG. 4 is a flow diagram illustrating another embodiment of a process for synchronizing entries in a context log. This process is performed by processing logic including hardware (eg, circuitry, dedicated logic, etc.), software (running on a general purpose computer system or a dedicated machine), or a combination of these. In one embodiment, this process is performed by a client operating with a server having a context log.
図4を参照して、本プロセスは、処理ロジック(processing logic)が、チェックポイントの後にある第1のコンテクストログに含まれたエントリに対する要求を送信して始まる。第1のコンテクストログは、コンテンツのシーケンスと、1つ以上のチェックポイントにより区切られた各コンテンツに関連する属性エントリとを含むファイルフォーマットを有する(処理ブロック401)。次に、処理ロジックは、要求を満たすために、第1のチェックポイントの後にあるエントリを受信し(処理ブロック402)、第2のコンテクストログにこれらのエントリを加える。 Referring to FIG. 4, the process begins with processing logic sending a request for an entry contained in a first context log after a checkpoint. The first context log has a file format that includes a sequence of content and attribute entries associated with each content separated by one or more checkpoints (processing block 401). Next, processing logic receives the entries after the first checkpoint to satisfy the request (processing block 402) and adds these entries to the second context log.
コンテクストログ(Context logs)
チェックポイントを使用して、別々のマシンに記憶されたログを効率的に同期できる。文書Xと関連づけられたログの場合、マシン#1はXのログ中のマシン#2からの最新のチェックポイント(例えば、5番目のチェックポイントである0xC2#05)を追跡できる。マシン#1は、そのログをマシン#3からの新しいエントリで更新したいとき、0xC2#05以降のすべてのエントリを求める。新しいエントリを受信すると、マシン#1はそれ自体のログにそれらのエントリを加える。マシン#1がマシン#2と厳密に同じエントリのシーケンスを有する場合、そのログとチェックポイントは文書Xのマシン#2と同じである。アプリケーションに応じて、これは最も一般的な場合である。
Context logs
Checkpoints can be used to efficiently synchronize logs stored on separate machines. For the log associated with document X, machine # 1 can track the latest checkpoint from machine # 2 in the log for X (eg, the fifth checkpoint, 0xC2 # 05). When machine # 1 wants to update its log with a new entry from machine # 3, it asks for all entries after 0xC2 # 05. As new entries are received, machine # 1 adds those entries to its own log. If machine # 1 has the exact same sequence of entries as machine # 2, its log and checkpoint are the same as machine # 2 of document X. Depending on the application, this is the most common case.
一方、マシン#1のログが#2のログと異なる場合、マシン#1は自分自信のログ中のマシン#2の最新チェックポイントに対応するチェックポイントを追跡しなければならない。この場合、マシン#2は、0xC2#05(マシン#1のリストに現れないチェックポイント)以降のすべてのエントリを求めることができる。マシン#1は、通信を追跡していた場合、それ自体のログ中の対応するチェックポイント以降のすべての新しいエントリを応答することができる。留意すべきことは、マシン#2は、そのログにこれらのエントリの一部をすでに有しており、再度加えることはない可能性があることである。また、いずれかのマシンがハッシュテーブルにエントリのラベルを記憶していて、アイテムをログに加える前にこのテーブルをチェックするかも知れない。
マシン#1は、マシン#2のログの既存のチェックポイントを持たない場合、「0」を送信して、すべてのエントリの受信を希望することを示す。
On the other hand, if the log of machine # 1 is different from the log of # 2, machine # 1 must track the checkpoint corresponding to the latest checkpoint of machine # 2 in its own log. In this case, the machine # 2 can obtain all entries after 0xC2 # 05 (a checkpoint that does not appear in the list of the machine # 1). If machine # 1 was tracking communications, it can respond with all new entries since the corresponding checkpoint in its own log. Note that machine # 2 already has some of these entries in its log and may not add it again. Also, any machine may store the label of the entry in a hash table and check this table before adding items to the log.
If the machine # 1 does not have an existing checkpoint in the log of the machine # 2, it sends “0” to indicate that it wants to receive all entries.
同期手続の例
一実施形態では、クライアントは、サーバに記憶されている最新のコンテクストログと関連コンテンツのローカルなコピーを欲する場合、要求をしてコンテクストと関連づけられた現在のindex.logファイルを求める。例えば、要求とそれに続いて
http://server.org/0xA/index.log
により、server.org上の0xA(例えば文書のハッシュ)と関連づけられたログが返される。クライアントはダウンロードしたファイル中の各属性エントリをチェックする。クライアントにローカルに記憶されていないデータを参照するエントリの後のエントリに対して、クライアントはGET CONTENT要求をする。
Example Synchronous Procedure In one embodiment, if the client wants a local copy of the latest context log and related content stored on the server, the current index. Find the log file. For example, a request followed by
http://server.org/0xA/index.log
Server. The log associated with 0xA on org (eg, the hash of the document) is returned. The client checks each attribute entry in the downloaded file. For an entry after an entry that references data not stored locally on the client, the client makes a GET CONTENT request.
効率のために、クライアントは、index.logを最も新しくダウンロードしたバージョン中の最後のチェックポイントを追跡する。新しいバージョンがダウンロードされると、チェックポイントを比較して、前のチェックポイントより後にあるアイテムだけを調べてダウンロードする。 For efficiency, the client tracks the last checkpoint in the most recently downloaded version of index.log. When a new version is downloaded, checkpoints are compared and only items that are after the previous checkpoint are examined and downloaded.
カノニカルバージョン(Canonical Version)
一実施形態では、2つの別々のマシンは、1つのコンテクストについて動作を同期させるために、第3の「カノニカル」サーバからのログエントリのシーケンスを使用することに同意する。その後、各サーバの各々により生成されたエントリはカノニカルサーバに直接または間接にポストされる。カノニカルサーバからのコンテクストログ中にあるエントリの後のエントリのシーケンスは、それらのエントリの同意された順序を決定する。かかる情報を用いて、例えば、2つの別々のサーバ上で同時に変化する文書の「オフィシャルな」履歴を決定することができる。
Canonical version
In one embodiment, two separate machines agree to use a sequence of log entries from a third “canonical” server to synchronize operations for one context. Thereafter, the entries generated by each of each server are posted directly or indirectly to the canonical server. The sequence of entries after the entries in the context log from the canonical server determines the agreed order of those entries. Such information can be used, for example, to determine an “official” history of documents that change simultaneously on two separate servers.
複数バージョン
一実施形態では、単一サーバのログファイルは複数のサーバからのエントリを含む。特に、これは、ログファイルがコンテンツ識別子が混ざったものを含む、すなわち、例えば、
0xM1.0xD: title=” Machine M1 title”
0xM.0xCM1: _type=”M1 Checkpoint entry”
0xM2.0xD: title=” Machine M2 title”
0xM.0xCM2: _type=”M1 Checkpoint entry”
…
ここで、M1とM2は異なるマシンの同じ「名前空間」(例えば、0xA)を指す。この場合、現在のサーバは0xDの正確なエントリを有さず、またはサーバM1及びM2の属性と関連づけられた0xCM1と0xCM2からのエントリの後のいずれかのエントリを使用するよう決定する。これは確認と監査のために使用できる。
Multiple Versions In one embodiment, a single server log file includes entries from multiple servers. In particular, this includes log files with mixed content identifiers, ie, for example,
0xM1.0xD: title = ”Machine M1 title”
0xM.0xCM1: _type = ”M1 Checkpoint entry”
0xM2.0xD: title = ”Machine M2 title”
0xM.0xCM2: _type = ”M1 Checkpoint entry”
...
Here, M1 and M2 refer to the same “namespace” (eg, 0xA) of different machines. In this case, the current server does not have an exact entry of 0xD or decides to use any entry after the entry from 0xCM1 and 0xCM2 associated with the attributes of servers M1 and M2. This can be used for verification and auditing.
0xM.0xD: title=” Machine M1 title”
1つのサーバからの属性を読み取る(例えば、server.orgからティドリーウィキを取得する)クライアントは、そのコンテクスト(例えば、0xM.0xD)と関連づけられた属性にだけ興味を有するかも知れない。一方、クライアントは、ログは0xMと関連づけられたサーバから読み出していても、異なるコンテクストと関連づけられた属性、例えば0xM2と関連づけられたサーバからの0xM2属性にのみ関心を有しているかも知れない。
0xM.0xD: title = ”Machine M1 title”
A client that reads attributes from one server (eg, gets a Tidley Wiki from server.org) may only be interested in the attributes associated with that context (eg, 0xM.0xD). On the other hand, the client may only be interested in attributes associated with different contexts, eg, 0xM2 attributes from the server associated with 0xM2, even though the logs are being read from the server associated with 0xM.
特性と確認(Properties and verification)
2つのマシンからの2つのコンテクストログがある場合、これらのログにオーバーラップしたエントリがあるか否か確認し、これらのエントリが各ログで同じ順序で現れるか確認することは非常に簡単である。
Properties and verification
If you have two context logs from two machines, it is very easy to see if there are overlapping entries in these logs and see if these entries appear in the same order in each log .
図5は、文書確認プロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア(例えば回路、専用ロジック等)、(汎用コンピュータシステムまたは専用機上で実行される)ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。 FIG. 5 is a flow diagram illustrating one embodiment of a document confirmation process. This process is performed by processing logic including hardware (eg, circuitry, dedicated logic, etc.), software (running on a general purpose computer system or a dedicated machine), or a combination of these.
図5を参照して、本プロセスは、処理ロジック(processing logic)が、コンテンツのシーケンスと、1つ以上のチェックポイントにより区切られた各コンテンツに関連する属性エントリとを含むファイルフォーマットを有するコンテクストログを作成(maintain)することにより始まる(処理ブロック501)。次に、処理ロジックはコンテクストログのエントリの確認要求を受ける。処理ロジックはコンテクストログにアクセスして(処理ブロック503)、コンテクストログに格納された情報の最新の状態を確認する(処理ブロック504)。一実施形態では、コンテクストログに記憶された情報の現在の状態を確認する段階は、コンテクストログのエントリに基づき文書の現在の状態を確認する。 Referring to FIG. 5, the process includes a context log having a file format in which processing logic includes a sequence of content and attribute entries associated with each content separated by one or more checkpoints. Is started (processing block 501). Next, processing logic receives a confirmation request for a context log entry. Processing logic accesses the context log (processing block 503) and checks the latest state of the information stored in the context log (processing block 504). In one embodiment, checking the current state of the information stored in the context log checks the current state of the document based on the context log entry.
図6は、オーバーラップするエントリを有するログが同じ順序であるか確認するプロセスを示す。このプロセスは、ハードウェア(例えば回路、専用ロジック等)、(汎用コンピュータシステムまたは専用機上で実行される)ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。 FIG. 6 illustrates the process of checking that logs with overlapping entries are in the same order. This process is performed by processing logic including hardware (eg, circuitry, dedicated logic, etc.), software (running on a general purpose computer system or a dedicated machine), or a combination of these.
図6を参照して、処理の開始において、処理ロジックが両方のログにある属性エントリの交わりを計算する(処理ブロック601)。次に、処理ロジックはこれらのエントリを第1のログで出てくる順序で並べる(処理ブロック602)。次に、第2のログを調べて、各エントリについて、処理ロジックはそのエントリがその交わりにないこと、またはそのエントリが第1のログに従って順序付けられたシーケンス中の「次の」ものであるか確認する(処理ブロック603)。 Referring to FIG. 6, at the start of processing, processing logic calculates the intersection of attribute entries in both logs (processing block 601). Next, processing logic arranges these entries in the order they appear in the first log (processing block 602). Then, looking at the second log, for each entry, processing logic is that the entry is not in its intersection, or is the "next" in the sequence ordered according to the first log? Confirmation (processing block 603).
この手続をログ1のチェックポイント#C1及びログ2のチェックポイント#C2までのエントリに対して行うと、処理ロジックはそれ以降の比較はそれらのチェックポイント以降のもにしかやらない。留意すべきことは、チェックポイント#C1とチェックポイント#C2は、両方のログにある最後のエントリのすぐ前の最後のチェックポイントであることである。 If this procedure is performed for entries up to the checkpoint # C1 of the log 1 and the checkpoint # C2 of the log 2, the processing logic can only compare after those checkpoints. It should be noted that checkpoint # C1 and checkpoint # C2 are the last checkpoints immediately before the last entry in both logs.
不変なシーケンス
上記の通り、一実施形態では、ログファイルへの変更はすべてすぐに検出可能である。チェックポイントがもはや有効ではないか、前のチェックポイント(例えば、他のログに記憶されたもの)がもはやログに見つからないからである。
Immutable Sequence As noted above, in one embodiment, all changes to the log file are immediately detectable. This is because the checkpoint is no longer valid or the previous checkpoint (eg, stored in another log) is no longer found in the log.
この特性を使用して、ログ間の依存関係を作る。例えば、ログ2がログ1のチェックポイント0xC1への参照を含み、ログ1がログ2の後続のチェックポイント0xC2への参照を含む場合、攻撃者は、ログ2との一貫性を保つようにログ1を修正することが不可能になる。例え攻撃者がログ1の新しいチェックポイントを作っても、ログ2中のエントリは残る。攻撃者が偽造ログ中に0xC2への参照を含めても、0xC2はもはや有効ではないログ1中のチェックポイントに基づくことが確認される。 Use this property to create dependencies between logs. For example, if log 2 contains a reference to checkpoint 0xC1 in log 1 and log 1 contains a reference to a subsequent checkpoint 0xC2 in log 2, the attacker logs to be consistent with log 2 It becomes impossible to correct 1. Even if an attacker creates a new checkpoint for log 1, the entry in log 2 remains. Even if an attacker includes a reference to 0xC2 in the forged log, it is confirmed that 0xC2 is based on a checkpoint in log 1 that is no longer valid.
それゆえ、一貫性を保つためには、攻撃者はログ2も変更しなければならない。しかし、このログは別のマシンにあり、攻撃者の知らないログのチェックポイントや秘密データのハッシュへの参照を含むから、攻撃者は有効な偽造ログを作ることができない。ログ間(特に別のマシンのログ間)の相互参照の数が増えれば、偽造ログを作れる可能性はほとんどなくなる。 Therefore, to maintain consistency, the attacker must also change log 2. However, because this log is on a separate machine and contains a reference to the log's unknown checkpoint and a hash of secret data, the attacker cannot create a valid forged log. If the number of cross-references between logs (especially between logs on different machines) increases, the possibility of creating forged logs is almost eliminated.
プライバシー
コンテクストログと関連特性がその基礎となるコンテンツエントリの知識を必要としないということを強調しておく。例えば、識別子0xAと関連づけられた実際のデータは、単一のマシンしか知らない。しかし、その識別子と関連づけられた属性は、別の多数のマシン上で設定、修正ができる。
Emphasize that privacy context logs and related characteristics do not require knowledge of the underlying content entry. For example, the actual data associated with the identifier 0xA knows only a single machine. However, the attribute associated with that identifier can be set and modified on many other machines.
この特性により、属性(一般的にはメタデータ)へのアクセスから切り離せるデータへのアクセスをローカルで精密に(fine-grained)制御することができ、一方で監査可能性(auditability)と説明可能性(accountability)とを維持することができる。 This property allows local fine-grained control of access to data that can be separated from access to attributes (typically metadata), while accounting for auditability. Accountability can be maintained.
このローカルな制御により、異なる多数のアプリケーションが同じ基本システムを使用することができる。例えば、サービスリンクプロトタイプ(ServiceLink prototype)により使用される共有記録(SharedRecord)システムにおいて、データ(例えば、テスト結果等の医療文書)は最初に暗号化されてから記憶される。これにより、データ(医療文書)へのアクセスとその文書に関連づけられたコメントその他のメタデータへのアクセスを別々に制御することができる。暗号化されたデータのハッシュは関連エントリの識別子として使用し、文書自体を復号して見るためには別の復号鍵が必要である。属性は、コメントその他のエントリとして暗号化ファイルの識別子と公開して関連づけることができ、暗号化されていてもいなくてもよく、暗号化ファイルと関連づけられたログに加えられる。さらにまた、別のセットのエントリすなわち第2のコンテクストを、同じファイルの暗号化していないバージョンと関連づけてもよい。暗号化していないデータにアクセスできる人(例えば復号鍵を有する人)は、識別子を計算して、エントリを暗号化されていないファイルと関連づけて、それらのエントリを暗号化されたバージョンの識別子と関連づけられたエントリとリンクすることができる。別のセットのコメントを同じ文書の他の暗号化バージョンであって各々が別の暗号化鍵を使用するものと関連づけることができる。このアプローチを変形して、アスリート(athletes)と関連文書へのアクセスを精密かつローカルに制御することもできる。 This local control allows many different applications to use the same basic system. For example, in a shared record system used by a ServiceLink prototype, data (eg, medical documents such as test results) is first encrypted and then stored. Thereby, access to data (medical document) and access to comments and other metadata associated with the document can be controlled separately. The hash of the encrypted data is used as an identifier for the related entry, and another decryption key is required to decrypt and view the document itself. The attribute can be publicly associated with the identifier of the encrypted file as a comment or other entry, which may or may not be encrypted, and is added to the log associated with the encrypted file. Furthermore, another set of entries or second context may be associated with an unencrypted version of the same file. A person who has access to unencrypted data (eg, a person with a decryption key) calculates an identifier, associates the entry with an unencrypted file, and associates the entry with an encrypted version of the identifier. Can be linked to the specified entry. Different sets of comments can be associated with other encrypted versions of the same document, each using a different encryption key. This approach can be modified to precisely and locally control access to athletes and related documents.
図7は、コンテクストログデータのプライバシーを守るプロセスの一実施形態を示すフロー図である。図7のプロセスは、ハードウェア(例えば回路、専用ロジック等)、(汎用コンピュータシステムまたは専用機上で実行される)ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。 FIG. 7 is a flow diagram illustrating one embodiment of a process for protecting the privacy of context log data. The process of FIG. 7 is performed by processing logic including hardware (eg, circuitry, dedicated logic, etc.), software (running on a general purpose computer system or a dedicated machine), or a combination thereof.
図7を参照して、処理ロジックは最初にデータ(例えば、文書)を暗号化し、暗号化したデータの識別子(例えば、暗号化データのSHA1)を計算する(処理ブロック701)。処理ロジックは、次に、公開して暗号化データの識別子に属性を関連づける(処理ブロック702)。 Referring to FIG. 7, processing logic first encrypts data (eg, a document) and calculates an identifier for the encrypted data (eg, SHA1 of the encrypted data) (processing block 701). Processing logic then publishes and associates the attribute with the identifier of the encrypted data (processing block 702).
その後、処理ロジックは、データの暗号化されていないバージョンを用いて第2の識別子を計算する(処理ブロック703)。処理ロジックは、エントリのセットを暗号化されていないデータに関連づけられたこの第2の識別子と関連づけ、次に、それらのエントリを暗号化されたバージョンの識別子と関連づけられたエントリと結合またはリンクする(処理ブロック704)。 Thereafter, processing logic calculates a second identifier using the unencrypted version of the data (processing block 703). Processing logic associates the set of entries with this second identifier associated with the unencrypted data, and then combines or links those entries with the entry associated with the encrypted version of the identifier. (Processing block 704).
他の場合、コンテンツはトランザクション情報を含む。個々の関係者は互いに情報を秘密にしておきたいと欲するが、第三者の監査人には事後にその情報を開示する。コンテクストログの共有バージョンがあれば、事後にそのデータを偽造したり改変することを防止できる。この場合、関係者は属性エントリのみをログに入れ、コンテンツエントリを秘密にしておくことができる。監査人は、その属性エントリが同じコンテンツエントリを指していること(エントリ中のコンテンツに対して同じフィンガープリントを使用していること)を確認できる。さらにまた、監査人は、関係者が関連するコンテンツエントリ(またはそれらのエントリの特定の一部)を作ることを要求し、これらのエントリがログ中の属性エントリに対応することを確認できる。 In other cases, the content includes transaction information. Individual parties want to keep information secret from each other, but disclose the information to third-party auditors after the fact. If there is a shared version of the context log, it is possible to prevent the data from being forged or altered afterwards. In this case, the parties can log only the attribute entry and keep the content entry secret. The auditor can confirm that the attribute entry points to the same content entry (uses the same fingerprint for the content in the entry). Furthermore, the auditor can request that interested parties make relevant content entries (or a specific portion of those entries) and verify that these entries correspond to attribute entries in the log.
認証
クライアント/サーバシステムでは、通常はサーバが、誰がそのサーバまたはその様々なリソースにアクセスできるかを管理する。これは、一般的にはクライアントが入力するログインIDとパスワードを用いて行われ、このログインIDとパスワードをサーバに格納されたデータベースと比較する。もちろん、ここに説明するシステムにおいては、サーバのユーザを認証及び確認するために、同種のメカニズムを使用することもできる。
In an authenticated client / server system, the server typically manages who has access to the server or its various resources. This is generally performed using a login ID and password input by the client, and the login ID and password are compared with a database stored in the server. Of course, in the system described here, a similar mechanism can be used to authenticate and verify the user of the server.
補足的または代替的アプローチとして、認証情報を、各コンテクストまたはマシンによらない名前空間の特定の属性エントリに格納することもできる。
例えば、現在の実施形態では、コンテクストログはタイプが「\_update\_keys」である例えば以下の属性エントリを含む:
0xM.0xK:22 title=''\_update\_keys''
サーバはこのコンテクストへのポストの認証のために、識別子0xKと関連づけられたコンテンツを使用する。特に、0xKはリストのハッシュであり、各々は電子メールアドレスその他のフレーズ(phrase)に対応している。クライアントは、ポスト要求をすると、プレーンテキストの電子メールアドレスまたはフレーズ、例えばowner=''wolff@ricoh.com''を含むクッキー(cookie)または属性を含める。サーバは、このフレーズのハッシュを計算し、その結果を0xK中のハッシュのリストと比較する。リスト中にあれば、ポスト要求は受け付けられる。
As a complementary or alternative approach, authentication information can also be stored in specific attribute entries in the namespace that are not dependent on each context or machine.
For example, in the current embodiment, the context log includes the following attribute entries of type “\ _update \ _keys”, for example:
0xM.0xK: 22 title = `` \ _update \ _keys ''
The server uses the content associated with the identifier 0xK for authentication of posts to this context. In particular, 0xK is a hash of the list, each corresponding to an email address or other phrase. When a client makes a post request, it includes a cookie or attribute that includes a plain text email address or phrase, for example, owner=''wolff@ricoh.com ''. The server calculates the hash of this phrase and compares the result to the list of hashes in 0xK. If it is in the list, the post request is accepted.
図8は、認証プロセスの一実施形態を示すフロー図である。図8のプロセスは、ハードウェア(例えば回路、専用ロジック等)、(汎用コンピュータシステムまたは専用機上で実行される)ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。一実施形態では、このプロセスはサーバにより実行される。 FIG. 8 is a flow diagram illustrating one embodiment of an authentication process. The process of FIG. 8 is performed by processing logic including hardware (eg, circuitry, dedicated logic, etc.), software (running on a general purpose computer system or a dedicated machine), or a combination thereof. In one embodiment, this process is performed by a server.
図8を参照して、本プロセスの開始において、処理ロジックは、各々が認証のために使用されるコンテンツ(電子メールアドレス、フレーズ等)に対応するハッシュまたはそのリストを格納する(処理ブロック801)。次に、処理ロジックは、認証情報(例えば、電子メールアドレス、フレーズ等)のプレーンテキストバージョンを含むポスト要求を受ける(処理ブロック802)。一実施形態では、認証情報のプレーンテキストバージョンは、属性に含まれてもよい。次に、処理ロジックは、要求で受け取った認証情報のハッシュを計算し(処理ブロック803)、それをハッシュのリストと比較する(処理ブロック804)。その後、処理ロジックは、認証情報のハッシュがハッシュのリストにあるかテストする(処理ブロック805)。あれば、処理ロジックはポスト要求を受け付け(処理ブロック806)、処理を終了する。なければ、処理ロジックはポスト要求を拒絶し(処理ブロック807)、処理を終了する。 Referring to FIG. 8, at the start of the process, processing logic stores a hash or list thereof, each corresponding to content (email address, phrase, etc.) used for authentication (processing block 801). . Next, processing logic receives a post request that includes a plain text version of authentication information (eg, email address, phrase, etc.) (processing block 802). In one embodiment, a plain text version of the authentication information may be included in the attribute. Next, processing logic calculates a hash of the authentication information received in the request (processing block 803) and compares it to the list of hashes (processing block 804). Thereafter, processing logic tests whether the hash of the authentication information is in the list of hashes (processing block 805). If so, processing logic accepts the post request (processing block 806) and ends processing. If not, processing logic rejects the post request (processing block 807) and ends processing.
特に、このポスト要求は「_update_keys」属性エントリの新しい値を提供することに留意せよ。このように、クライアントは特定のコンテクスト内の認証をローカルで管理することができる。
新しいコンテクストログがユーザ要求により開始される時、その要求のオーナーパラメータ(owner parameter)(または同等のクッキー)を使用して「_update_keys」の初期値をシード(seed)することができる。
In particular, note that this post request provides a new value for the “_update_keys” attribute entry. In this way, the client can locally manage authentication within a particular context.
When a new context log is initiated by a user request, the request's owner parameter (or equivalent cookie) can be used to seed the initial value of “_update_keys”.
GET要求、PUBLISH要求にも同様の方法を使用できる。 A similar method can be used for GET requests and PUBLISH requests.
サーバポリシー(Server Policies)
サーバによって、この種の情報をどう取り扱うかのポリシーが異なることに留意せよ。別の実施形態では、サーバは毎回新しい鍵(例えばハッシュ)が提供されることを要求する。これは、クライアントが最新の鍵のプレーンテキストであるパラメータに加えて、「次の」鍵のハッシュを提供するか、またはサーバが応答の一部としてクライアントに「次の」プレーンテキストの鍵を提供するからである。
Server policies
Note that different servers have different policies on how to handle this type of information. In another embodiment, the server requires a new key (eg, a hash) to be provided each time. This can be a parameter where the client is the plaintext of the latest key plus a hash of the “next” key, or the server provides the client with the “next” plaintext key as part of the response Because it does.
サーバは、どの属性エントリをローカルコンテクストに受け入れるかに関しても異なる。上記の通り、1つのサーバ上のコンテクストログは、同じコンテンツと関連づけられたローカルの属性エントリ(例えば、0xM.0xD:foo=“bar”と0xM1.0xD:foo=“notbar”は同じログ中に存在し得る)とは異なる、異なるコンテクストからの属性エントリ(例えば、0xM1がリモートサーバの0xAと関連づけられている場合、0xM1.0xD)を含んでもよいサーバがどのエントリを自機のコンテクスト内にあると認めるかを管理するポリシーはサーバ毎に異なる。しかし、監査と比較のメカニズム(これはトレーサビリティの基本である)はどのサーバでも同一である。 The server also differs as to which attribute entries are accepted in the local context. As described above, the context log on one server has local attribute entries (eg, 0xM.0xD: foo = “bar” and 0xM1.0xD: foo = “notbar” associated with the same content in the same log) A server that may contain attribute entries from a different context (eg 0xM1.0xD if 0xM1 is associated with the remote server's 0xA), which entry is in its own context. The policy for managing whether or not to be recognized is different for each server. However, the audit and comparison mechanism (which is the basis for traceability) is the same for every server.
コンテンツベース認証(content based authentication)
秘密情報をサーバ間の認証に使用することもできる。例えば、コンテンツエントリの識別子0xAは、少数の人またはマシンだけが知っている「秘密の」フレーズまたはデータに対応する。例えば、このデータは、イントラネット上のページのURL、電子メールの主題、またはユーザのPCのローカルファイルシステムに格納されたJPEGファイルである。
Content based authentication
Secret information can also be used for authentication between servers. For example, the content entry identifier 0xA corresponds to a “secret” phrase or data known only by a few people or machines. For example, this data is the URL of a page on an intranet, the subject of an email, or a JPEG file stored in the user's PC's local file system.
識別子0xAが公開されていても、秘密データをエントリの認証または確認に使用できる。例えば、0xAに対応する主題ヘディングを有する特定の電子メールを受信した人だけが、0xAと関連づけられたコンテクストの属性エントリを加えられるとする。
各ユーザは、最初に、例えばコメント本文を含む通常の属性エントリを送信することにより属性エントリを「サイン(sign)」することできる。次に、次の形式の「署名(signature)」属性エントリを送ることができる:
0xM.0xDS:22 type=signature entry=0xD
この場合、0xDSは、0xDで特定されたコンテンツが連結された秘密データのハッシュである。コンテンツ(すなわちハッシュが0xDとなるデータ)と、秘密データ(ハッシュが0xAとなるデータ)の両方にアクセスできる他のユーザまたはマシンは、0xDSが正しいハッシュであることを確認できる。これにより、中央サーバに対する信頼を必要とせずに、個々のユーザが互いのエントリを認証する方法を提供する。
Even if the identifier 0xA is public, the secret data can be used for authentication or confirmation of the entry. For example, only a person who receives a specific email with a subject heading corresponding to 0xA can add an attribute entry in the context associated with 0xA.
Each user can first "sign" the attribute entry by sending a normal attribute entry including, for example, a comment body. Then you can send a "signature" attribute entry of the form:
0xM.0xDS: 22 type = signature entry = 0xD
In this case, 0xDS is a hash of secret data to which the content specified by 0xD is concatenated. Other users or machines that have access to both content (ie, data with a hash of 0xD) and secret data (data with a hash of 0xA) can confirm that 0xDS is the correct hash. This provides a way for individual users to authenticate each other's entries without requiring trust to the central server.
図9は、信頼できる中心の関係者(trusted central party)を用いずに他のユーザのエントリを認証するプロセスの一実施形態を示すフロー図である。このプロセスは、ハードウェア(例えば回路、専用ロジック等)、(汎用コンピュータシステムまたは専用機上で実行される)ソフトウェア、またはこれらの組み合わせを含む処理ロジックにより実行される。 FIG. 9 is a flow diagram illustrating one embodiment of a process for authenticating another user's entry without using a trusted central party. This process is performed by processing logic including hardware (eg, circuitry, dedicated logic, etc.), software (running on a general purpose computer system or a dedicated machine), or a combination of these.
図9を参照して、プロセスの開始において、処理ロジックはコンテンツ(ハッシュが署名エントリになるデータ)と秘密データの両方を格納するかアクセスする(処理ブロック901)。その後、処理ロジックは、他のマシンから通常の属性エントリと署名属性エントリを受け取る(処理ブロック902)。署名属性エントリは、それにより特定されるコンテンツと関連づけられた秘密データのハッシュであるデータを含む。処理ロジックは、次に、その署名により特定されるコンテンツに連結された秘密データのハッシュを確認することにより、1つ以上の他人のエントリを認証する(処理ブロック903)。 Referring to FIG. 9, at the start of the process, processing logic stores or accesses both content (data whose hash is the signature entry) and secret data (processing block 901). Thereafter, processing logic receives normal and signature attribute entries from other machines (processing block 902). The signature attribute entry includes data that is a hash of secret data associated with the content identified thereby. Processing logic then authenticates one or more other entries by verifying the hash of the secret data concatenated with the content identified by the signature (processing block 903).
バージョニング(versioning)
コンテクストログの典型的な使用方法はバージョンの追跡である。例えば、0xAが次のもののハッシュに対応するとする:
http://server.org/wolff/index.html
0xAと関連づけられたログは、このファイルの後のバージョンを指すエントリのシーケンスを含む。例えば、1つのエントリは:
0xM.0xA1:22 type=contents modified=2005/12/22
であり、その日付に、ファイルindex.htmlのコンテンツが識別子0xA1を有することを示す。後で、そのファイルの新しいバージョンが上記URLで公開される。その場合、他のエントリが次のログに含められる:
0xM.0xA2:22 type=contents modified=2005/12/22
事実上、第2のエントリは前のエントリより優先される。このように、0xAに対応するURLにあるファイルのコンテンツのバージョン履歴が保持される。例えば、公開された記憶場所0xAとともに、前のバージョンと次のバージョンを指す0xA1と0xA2のコンテクストログを相互参照があってもよい。
Versioning
A typical use of context logs is version tracking. For example, suppose 0xA corresponds to a hash of:
http://server.org/wolff/index.html
The log associated with 0xA contains a sequence of entries that point to later versions of this file. For example, one entry is:
0xM.0xA1: 22 type = contents modified = 2005/12/22
At that date, the file index. Indicates that the content of html has the identifier 0xA1. Later, a new version of the file is published at the URL. In that case, other entries will be included in the following logs:
0xM.0xA2: 22 type = contents modified = 2005/12/22
In effect, the second entry takes precedence over the previous entry. In this way, the version history of the content of the file at the URL corresponding to 0xA is held. For example, there may be a cross-reference to the 0xA1 and 0xA2 context logs pointing to the previous and next versions, along with the published storage location 0xA.
これらのエントリは、別の時間に別のマシンで分散されてこれらのエントリがされてもよいことに留意することは有用である。例えば、他のマシンのユーザは、ファイル0xA2をダウンロードして修正できる。そのマシンにおいて、他のエントリをしてもよい:
0xM1A2.0xA3:22 type=NewVersion modified=2005/12/23
ここで、0xM1A2は、0xA2のマシンM1上のコンテクストログであり、0xA3は0xA2に基づく新しいデジタルファイルである。マシンMとM1のログを調整するとき、元の文書0xA1の履歴を、対応するログの属性エントリを用いて0xA2から0xA3まで追跡することができる。
It is useful to note that these entries may be distributed on different machines at different times. For example, users of other machines can download and modify file 0xA2. Other entries may be made on that machine:
0xM1A2.0xA3: 22 type = NewVersion modified = 2005/12/23
Here, 0xM1A2 is a context log on the machine M1 of 0xA2, and 0xA3 is a new digital file based on 0xA2. When adjusting the logs of machines M and M1, the history of the original document 0xA1 can be tracked from 0xA2 to 0xA3 using the corresponding log attribute entry.
ティドリーウィキ(TiddlyWiki)
以下は、上記のコンテクストログの例に対応するティドリーウィキhtmlファイルの記憶領域(storeArea)コンポーネントの例である。コンテクストログが同じタイトルを有する複数の属性エントリを含む場合、サーバは、そのティドラー(tiddler)の最新バージョンのみを応答してもよいことに留意せよ。また、ログが他のコンテクストからの属性エントリ(例えば、0xM.0xDではなく0xM1.0xD)を含む場合、サーバまたはクライアントは、それらのエントリを含めないこと、または0xMコンテクストに割り照られた属性がない場合にのみ含めることを決定してもよい。
TiddlyWiki
The following is an example of a storage area (storeArea) component of a Tidley Wiki html file corresponding to the above example of the context log. Note that if a context log contains multiple attribute entries with the same title, the server may respond only with the latest version of that tiddler. Also, if the log contains attribute entries from other contexts (eg, 0xM1.0xD instead of 0xM.0xD), the server or client must not include those entries, or the attributes assigned to the 0xM context You may decide to include it only if you do not.
図10は、ここに記載した1つ以上の動作を実行するコンピュータシステムの例を示すブロック図である。図10を参照して、コンピュータシステム1000は、クライアントまたはサーバのコンピュータシステムを含む。コンピュータシステム1000は、情報をやりとりする通信メカニズムすなわちバス1011と、情報を処理する、バス1011に結合したプロセッサ1012とを有する。プロセッサ1012は、例えばペンティアム(登録商標)プロセッサ、パワーPC(商標)、アルファ(商標)等のマイクロプロセッサを含むが、マイクロプロセッサに限定されない。
システム1000は、さらに、プロセッサ1012により実行される情報及び命令を格納する、バス1011に結合したランダムアクセスメモリ(RAM)またはその他のダイナミック記憶装置1004(ここではメインメモリと呼ぶ)を有する。メインメモリ1004は、プロセッサ1012による命令の実行中に、一時的変数やその他の中間情報を記憶するために使用される。
System 1000 further includes a random access memory (RAM) or other dynamic storage device 1004 (referred to herein as main memory) coupled to bus 1011 for storing information and instructions executed by
コンピュータシステム1000は、プロセッサ1012の静的情報や命令を記憶する、バス1011に結合した読み出し専用メモリ(ROM)及び/またはその他の静的記憶装置1006と、磁気ディスク、光ディスクとその対応するディスクドライブ等であるデータ記憶装置1007とを有する。データ記憶装置1007は、情報と命令を記憶し、バス1011に結合している。
The computer system 1000 includes a read only memory (ROM) and / or other static storage device 1006 coupled to the bus 1011 for storing static information and instructions of the
コンピュータシステム1000は、コンピュータのユーザに情報を表示するための、バス1011に結合した、陰極線管(CRT)または液晶ディスプレイ(LCD)等のディスプレイ装置1021に結合している。英数字入力装置1022は、英数字その他のキーを含み、バス1011に結合され、プロセッサ1012に情報とコマンド選択を送る。追加的なユーザ入力装置として、マウス、トラックボール、トラックパッド、スタイラス、またはカーソル、方向キー等のカーソル制御1023があり、バス1011に結合し、プロセッサ1012に方向情報とコマンド選択を送り、ディスプレイ1021上のカーソルの動きを制御する。
Computer system 1000 is coupled to a
バス1011に結合した他の装置としてハードコピー装置1024がある。このハードコピー装置1024は、紙、フィルム、その他のメディア上に、命令、データ、その他の情報を印刷するために使用される。バス1011に結合する他の装置として、電話やハンドヘルドパームトップ装置と通信する、有線または無線の通信機能1025がある。 Another device coupled to the bus 1011 is a hard copy device 1024. The hard copy device 1024 is used to print instructions, data, and other information on paper, film, and other media. Another device coupled to the bus 1011 is a wired or wireless communication function 1025 that communicates with a telephone or handheld palmtop device.
システム1000のどの構成要素もそれに関連するハードウェアも、本発明で使用してもよい。しかし、言うまでもなく、他の構成のコンピュータシステムでは、これらの構成要素の一部または全部を含んでもよい。 Any component of system 1000 and associated hardware may be used in the present invention. However, it goes without saying that a computer system having other configurations may include some or all of these components.
上記の説明を読んだ当業者には本発明の変形例や修正例が明らかになったことは間違いなく、言うまでもなく、上記のどの実施形態も本発明を限定することを目的としたものではない。それゆえ、いろいろな実施形態の詳細の説明は、本発明に本質的であると考えられる特徴のみを記載した請求項の範囲を限定するものではない。 It will be apparent to those skilled in the art who have read the above description that variations and modifications of the present invention have become apparent, and it goes without saying that any of the above embodiments is not intended to limit the present invention. . Therefore, the detailed description of various embodiments does not limit the scope of the claims which merely describe the features believed to be essential to the invention.
1004 メインメモリ
1006 静的メモリ
1007 大容量メモリ
1011 バス
1012 プロセッサ
1020 外部ネットワークインターフェイス
1021 ディスプレイ
1022 キーボード
1023 カーソル制御装置
1024 ハードコピー装置
1004 Main memory 1006 Static memory 1007 Mass memory 1011
Claims (6)
保持手段が、チェックポイントにより区切られたコンテンツエントリと属性エントリとのシーケンスを含むファイルフォーマットを有する第1のログを記憶手段に保持する段階であって、前記コンテンツエントリはストリングのハッシュと前記ストリングとを有するベクトルを含み、前記属性エントリはログファイルに関連する識別子と、コンテンツエントリの識別子と、前記コンテンツエントリの属性の名称及び前記属性に関連する値のペアとを含む、保持する段階と、
受信手段が、第1のログにデータをポストする要求を要求装置から受ける段階と、
特定手段が、前記第1のログの記憶場所と、前記第1のログに対応する文書に関連するデジタルデータとを示す前記要求中のコンテクスト識別子に基づき前記第1のログを特定する段階と、
生成手段が、前記要求中の前記デジタルデータに基づいて、ポストする前記データのハッシュと、前記データを表すストリングと、前記ストリング中の文字数とを含む第1のエントリを生成する段階と、
加える手段が、前記第1のログに第1のエントリを加える段階と、
計算手段が、ポストした前記データのハッシュを計算する段階と、
送信手段が、前記計算したハッシュを前記要求装置に送信する段階とを有する、方法。 A method in a computer system, comprising:
Holding means for holding in the storage means a first log having a file format including a sequence of content entries and attribute entries delimited by checkpoints, the content entry comprising a string hash, the string, Holding the attribute entry including an identifier associated with the log file, an identifier of the content entry, and a name pair of the attribute of the content entry and a value associated with the attribute;
Receiving a request from the requesting device to post data to the first log;
Identifying means for identifying the first log based on a context identifier in the request indicating a storage location of the first log and digital data associated with a document corresponding to the first log;
Generating means based on the digital data in the request to generate a first entry including a hash of the data to post, a string representing the data, and a number of characters in the string;
Means for adding adds a first entry to the first log;
Calculating means for calculating a hash of the posted data;
Transmitting means for transmitting the calculated hash to the requesting device.
検索手段が、コンテクストログにアクセスして、その内部に記憶された情報を検索する段階とをさらに含む、
請求項1に記載の方法。 The retaining means retains the first log in a format including a sequence of content and attribute entries associated with each context delimited by one or more checkpoints;
The retrieval means further includes accessing the context log to retrieve information stored therein;
The method of claim 1.
請求項2に記載の方法。 The context is a combination of first and second identifiers, where the first identifier identifies the machine that stored the first log, and the second identifier identifies a group of digital data.
The method of claim 2 .
前記チェックポイントの後のエントリを送信して前記要求を満たす段階とをさらに有する、
請求項1に記載の方法。 Receiving a request including a checkpoint for an entry in the first log;
Sending an entry after the checkpoint to satisfy the request;
The method of claim 1.
比較手段が、前記ハッシュを前記第1のログと関連づけられた識別子中の1つ以上のハッシュのリストと比較する段階と、
受け入れ手段が、前記ハッシュが前記識別子中のハッシュのリストに現れる場合、ポスト要求を受け入れる段階とを有する、
請求項1に記載の方法。 Calculating means for calculating a hash of a portion of the data received in the request;
Comparing means comparing the hash with a list of one or more hashes in an identifier associated with the first log;
Accepting means for accepting a post request if the hash appears in the list of hashes in the identifier;
The method of claim 1.
チェックポイントにより区切られたコンテンツエントリと属性エントリとのシーケンスを含むファイルフォーマットを有する第1のログを記憶手段に保持する段階であって、前記コンテンツエントリはストリングのハッシュと前記ストリングとを有するベクトルを含み、前記属性エントリはログファイルに関連する識別子と、コンテンツエントリの識別子と、前記コンテンツエントリの属性の名称及び前記属性に関連する値のペアとを含む、保持する段階と、
第1のログにデータをポストする要求を要求装置から受ける段階と、
前記第1のログの記憶場所と、前記第1のログに対応する文書に関連するデジタルデータとを示す前記要求中のコンテクスト識別子に基づき前記第1のログを特定する段階と、
前記要求中の前記デジタルデータに基づいて、ポストする前記データのハッシュと、前記データを表すストリングと、前記ストリング中の文字数とを含む第1のエントリを生成する段階と、
前記第1のログに第1のエントリを加える段階と、
ポストした前記データのハッシュを計算する段階と、
前記計算したハッシュを前記要求装置に送信する段階と
を実行させる、コンピュータプログラム。
A computer program, when executed by a computer system, to the computer system,
Storing in a storage means a first log having a file format including a sequence of content entries and attribute entries delimited by checkpoints, wherein the content entries have a vector comprising a hash of a string and the string The attribute entry includes an identifier associated with the log file, an identifier of the content entry, and a name pair of the attribute of the content entry and a value pair associated with the attribute;
Receiving a request from the requesting device to post data to the first log;
Identifying the first log based on a context identifier in the request indicating a storage location of the first log and digital data associated with a document corresponding to the first log;
Generating, based on the digital data in the request, a first entry including a hash of the data to post, a string representing the data, and a number of characters in the string;
Adding a first entry to the first log;
Calculating a hash of the posted data;
Transmitting the calculated hash to the requesting device.
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US79396706P | 2006-04-21 | 2006-04-21 | |
US60/793,967 | 2006-04-21 | ||
US11/673,496 | 2007-02-09 | ||
US11/673,496 US7809685B2 (en) | 2006-04-21 | 2007-02-09 | Secure and efficient methods for logging and synchronizing data exchanges |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2007293855A JP2007293855A (en) | 2007-11-08 |
JP2007293855A5 JP2007293855A5 (en) | 2010-02-18 |
JP5030654B2 true JP5030654B2 (en) | 2012-09-19 |
Family
ID=38267689
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007112344A Expired - Fee Related JP5030654B2 (en) | 2006-04-21 | 2007-04-20 | Secure and efficient method of logging and data exchange synchronization |
Country Status (3)
Country | Link |
---|---|
US (1) | US7809685B2 (en) |
EP (1) | EP1847935A3 (en) |
JP (1) | JP5030654B2 (en) |
Families Citing this family (38)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8001080B2 (en) * | 2006-09-12 | 2011-08-16 | Infosys Technologies Ltd. | Managing real-time execution of transactions in a network |
US20080282175A1 (en) * | 2007-05-07 | 2008-11-13 | Adobe Systems Incorporated | Automatically encoded, gracefully degrading panels |
US8683458B2 (en) * | 2007-11-30 | 2014-03-25 | Red Hat, Inc. | Automatic full install upgrade of a network appliance |
US8589592B2 (en) * | 2007-12-11 | 2013-11-19 | Red Hat, Inc. | Efficient object distribution |
US8418164B2 (en) * | 2008-05-29 | 2013-04-09 | Red Hat, Inc. | Image install of a network appliance |
US20100004950A1 (en) * | 2008-07-03 | 2010-01-07 | Nokia Corporation | System and method for usage of personal medical records in mobile devices |
US8255373B2 (en) * | 2008-10-24 | 2012-08-28 | Microsoft Corporation | Atomic multiple modification of data in a distributed storage system |
US9208315B2 (en) * | 2009-03-17 | 2015-12-08 | Microsoft Corporation | Identification of telemetry data |
US8819208B2 (en) | 2010-03-05 | 2014-08-26 | Solidfire, Inc. | Data deletion in a distributed data storage system |
WO2011111837A1 (en) * | 2010-03-11 | 2011-09-15 | 楽天株式会社 | Information processing method, information processing device, program, and recording medium |
US8521849B2 (en) * | 2010-07-08 | 2013-08-27 | Panasonic Corporation | Transmission control device and computer program controlling transmission of selected content file |
US20120143824A1 (en) * | 2010-12-02 | 2012-06-07 | Microsoft Corporation | Protecting files that include editable metadata |
US9824091B2 (en) | 2010-12-03 | 2017-11-21 | Microsoft Technology Licensing, Llc | File system backup using change journal |
US8620894B2 (en) | 2010-12-21 | 2013-12-31 | Microsoft Corporation | Searching files |
US8527472B2 (en) * | 2011-03-29 | 2013-09-03 | Kaseya International Limited | Method and apparatus of securely processing data for file backup, de-duplication, and restoration |
US8805901B1 (en) * | 2011-07-19 | 2014-08-12 | Google Inc. | Geographically distributed file system |
US9229818B2 (en) | 2011-07-20 | 2016-01-05 | Microsoft Technology Licensing, Llc | Adaptive retention for backup data |
US8825697B2 (en) * | 2011-09-13 | 2014-09-02 | Stefano Foresti | Method and system to capture, share and find information and relationships |
US9043866B2 (en) * | 2011-11-14 | 2015-05-26 | Wave Systems Corp. | Security systems and methods for encoding and decoding digital content |
US9015857B2 (en) * | 2011-11-14 | 2015-04-21 | Wave Systems Corp. | Security systems and methods for encoding and decoding digital content |
US9054992B2 (en) | 2011-12-27 | 2015-06-09 | Solidfire, Inc. | Quality of service policy sets |
US9838269B2 (en) | 2011-12-27 | 2017-12-05 | Netapp, Inc. | Proportional quality of service based on client usage and system metrics |
US9401904B1 (en) * | 2012-03-15 | 2016-07-26 | Motio, Inc. | Security migration in a business intelligence environment |
CN104685825B (en) * | 2012-09-26 | 2018-07-06 | 英派尔科技开发有限公司 | A kind of method of secure communication, computing device and non-transient computer readable storage medium storing program for executing |
TW201423469A (en) * | 2012-12-03 | 2014-06-16 | Inst Information Industry | Device, method and computer readable storage medium thereof for electronic digital data hiding |
US9935910B2 (en) | 2012-12-21 | 2018-04-03 | Google Llc | Recipient location aware notifications in response to related posts |
US9268653B2 (en) * | 2014-01-17 | 2016-02-23 | Netapp, Inc. | Extent metadata update logging and checkpointing |
US20150244795A1 (en) | 2014-02-21 | 2015-08-27 | Solidfire, Inc. | Data syncing in a distributed system |
US10133511B2 (en) | 2014-09-12 | 2018-11-20 | Netapp, Inc | Optimized segment cleaning technique |
US9836229B2 (en) | 2014-11-18 | 2017-12-05 | Netapp, Inc. | N-way merge technique for updating volume metadata in a storage I/O stack |
US10223372B2 (en) | 2016-01-26 | 2019-03-05 | International Business Machines Corporation | Log synchronization among discrete devices in a computer system |
US10929022B2 (en) | 2016-04-25 | 2021-02-23 | Netapp. Inc. | Space savings reporting for storage system supporting snapshot and clones |
US10642763B2 (en) | 2016-09-20 | 2020-05-05 | Netapp, Inc. | Quality of service policy sets |
US11048695B2 (en) * | 2017-09-12 | 2021-06-29 | Sap Se | Context-aware data commenting system |
EP3750272A4 (en) | 2018-02-06 | 2021-12-15 | Nb Research Llc | System and method for securing a resource |
CN109472150B (en) * | 2018-10-31 | 2021-06-29 | 佛山科学技术学院 | Method for setting and reading file information |
US11093642B2 (en) * | 2019-01-03 | 2021-08-17 | International Business Machines Corporation | Push down policy enforcement |
WO2022230153A1 (en) * | 2021-04-28 | 2022-11-03 | 富士通株式会社 | Evaluation method, evaluation program, information processing device, and evaluation system |
Family Cites Families (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6345288B1 (en) * | 1989-08-31 | 2002-02-05 | Onename Corporation | Computer-based communication system and method using metadata defining a control-structure |
US6044205A (en) * | 1996-02-29 | 2000-03-28 | Intermind Corporation | Communications system for transferring information between memories according to processes transferred with the information |
US5963962A (en) * | 1995-05-31 | 1999-10-05 | Network Appliance, Inc. | Write anywhere file-system layout |
JP3593366B2 (en) * | 1994-09-19 | 2004-11-24 | 株式会社日立製作所 | Database management method |
US5592618A (en) * | 1994-10-03 | 1997-01-07 | International Business Machines Corporation | Remote copy secondary data copy validation-audit function |
CN1276321C (en) | 1995-02-13 | 2006-09-20 | 英特特拉斯特技术公司 | Systems and methods for secure transaction management and electronic rights protection |
US5708780A (en) * | 1995-06-07 | 1998-01-13 | Open Market, Inc. | Internet server access control and monitoring systems |
CA2227431C (en) * | 1995-07-20 | 2001-05-15 | Novell, Inc. | Transaction log management in a disconnectable computer and network |
US5809415A (en) * | 1995-12-11 | 1998-09-15 | Unwired Planet, Inc. | Method and architecture for an interactive two-way data communication network |
US6308175B1 (en) | 1996-04-04 | 2001-10-23 | Lycos, Inc. | Integrated collaborative/content-based filter structure employing selectively shared, content-based profile data to evaluate information entities in a massive information network |
US6026379A (en) * | 1996-06-17 | 2000-02-15 | Verifone, Inc. | System, method and article of manufacture for managing transactions in a high availability system |
US20020046072A1 (en) | 1996-06-18 | 2002-04-18 | Toshikatsu Arai | Workflow system |
US5845292A (en) * | 1996-12-16 | 1998-12-01 | Lucent Technologies Inc. | System and method for restoring a distributed checkpointed database |
US6065018A (en) * | 1998-03-04 | 2000-05-16 | International Business Machines Corporation | Synchronizing recovery log having time stamp to a remote site for disaster recovery of a primary database having related hierarchial and relational databases |
US6360215B1 (en) | 1998-11-03 | 2002-03-19 | Inktomi Corporation | Method and apparatus for retrieving documents based on information other than document content |
US6584477B1 (en) * | 1999-02-04 | 2003-06-24 | Hewlett Packard Development Company, L.P. | High speed system and method for replicating a large database at a remote location |
US6574627B1 (en) * | 1999-02-24 | 2003-06-03 | Francesco Bergadano | Method and apparatus for the verification of server access logs and statistics |
US7278115B1 (en) | 1999-06-18 | 2007-10-02 | Microsoft Corporation | Methods, apparatus and data structures for providing a user interface to objects, the user interface exploiting spatial memory and visually indicating at least one object parameter |
US6546385B1 (en) | 1999-08-13 | 2003-04-08 | International Business Machines Corporation | Method and apparatus for indexing and searching content in hardcopy documents |
JP2001092827A (en) * | 1999-09-20 | 2001-04-06 | Toshiba Corp | Device and method for managing data |
US7134021B2 (en) * | 1999-10-22 | 2006-11-07 | Hitachi, Ltd. | Method and system for recovering the validity of cryptographically signed digital data |
WO2001095208A1 (en) * | 2000-06-02 | 2001-12-13 | Iprint.Com, Inc. | Integrated electronic shopping cart system and method |
US6687696B2 (en) | 2000-07-26 | 2004-02-03 | Recommind Inc. | System and method for personalized search, information filtering, and for generating recommendations utilizing statistical latent class models |
US6615208B1 (en) | 2000-09-01 | 2003-09-02 | Telcordia Technologies, Inc. | Automatic recommendation of products using latent semantic indexing of content |
US8032542B2 (en) | 2000-10-26 | 2011-10-04 | Reynolds Mark L | Creating, verifying, managing, and using original digital files |
US20020103920A1 (en) | 2000-11-21 | 2002-08-01 | Berkun Ken Alan | Interpretive stream metadata extraction |
US20040030681A1 (en) | 2000-11-21 | 2004-02-12 | Shannon Paul Thurmond | System and process for network site fragmented search |
US20020161846A1 (en) | 2001-01-29 | 2002-10-31 | Ulrich Thomas R. | Data path controller architecture |
US20020120484A1 (en) | 2001-02-23 | 2002-08-29 | International Business Machines Corporation | Method and system for providing intelligent rules-based engine with heuristics for determining optimal routing and processing of business events |
US7200627B2 (en) | 2001-03-21 | 2007-04-03 | Nokia Corporation | Method and apparatus for generating a directory structure |
US7668718B2 (en) | 2001-07-17 | 2010-02-23 | Custom Speech Usa, Inc. | Synchronized pattern recognition source data processed by manual or automatic means for creation of shared speaker-dependent speech user profile |
CA2456962C (en) * | 2001-08-16 | 2012-01-17 | Samuel T. Barone, Jr. | Digital data monitoring and logging in an itv system |
US20030046586A1 (en) | 2001-09-05 | 2003-03-06 | Satyam Bheemarasetti | Secure remote access to data between peers |
US7007074B2 (en) | 2001-09-10 | 2006-02-28 | Yahoo! Inc. | Targeted advertisements using time-dependent key search terms |
WO2003046689A2 (en) | 2001-11-21 | 2003-06-05 | Amicas, Inc. | System and methods for real-time worklist service |
US20030126276A1 (en) * | 2002-01-02 | 2003-07-03 | Kime Gregory C. | Automated content integrity validation for streaming data |
US6965883B2 (en) | 2002-02-20 | 2005-11-15 | Nokia Corporation | Charging mechanism for multicasting |
US20030217008A1 (en) | 2002-02-20 | 2003-11-20 | Habegger Millard J. | Electronic document tracking |
KR20040032260A (en) | 2002-10-08 | 2004-04-17 | 전자부품연구원 | Advertisements display apparatus using metadata and its service method |
US7263521B2 (en) * | 2002-12-10 | 2007-08-28 | Caringo, Inc. | Navigation of the content space of a document set |
US20050004899A1 (en) | 2003-04-29 | 2005-01-06 | Adrian Baldwin | Auditing method and service |
US20040260593A1 (en) | 2003-05-20 | 2004-12-23 | Klaus Abraham-Fuchs | System and user interface supporting workflow operation improvement |
US7406487B1 (en) | 2003-08-29 | 2008-07-29 | Symantec Operating Corporation | Method and system for performing periodic replication using a log |
US8229932B2 (en) | 2003-09-04 | 2012-07-24 | Oracle International Corporation | Storing XML documents efficiently in an RDBMS |
CA2442796A1 (en) | 2003-09-26 | 2005-03-26 | Ibm Canada Limited - Ibm Canada Limitee | Binding a workflow engine to a data model |
US7203796B1 (en) * | 2003-10-24 | 2007-04-10 | Network Appliance, Inc. | Method and apparatus for synchronous data mirroring |
US7451167B2 (en) * | 2003-10-24 | 2008-11-11 | Network Appliance, Inc. | Verification of file system log data using per-entry checksums |
US7392533B2 (en) | 2004-05-19 | 2008-06-24 | Microsoft Corporation | System and method for management of a componentized electronic document retrievable over a network |
US20050289187A1 (en) | 2004-06-29 | 2005-12-29 | Oracle International Corporation | System and method for investigating a data operation performed on a database |
US7949666B2 (en) | 2004-07-09 | 2011-05-24 | Ricoh, Ltd. | Synchronizing distributed work through document logs |
US8230326B2 (en) | 2004-12-17 | 2012-07-24 | International Business Machines Corporation | Method for associating annotations with document families |
US20060218204A1 (en) * | 2005-03-25 | 2006-09-28 | International Business Machines Corporation | Log stream validation in log shipping data replication systems |
US20070143356A1 (en) | 2005-12-15 | 2007-06-21 | Kleinsmith Richard A | Enforcing workflow for implementing unique identification |
US8095537B2 (en) * | 2005-12-29 | 2012-01-10 | Ricoh Co., Ltd. | Log integrity verification |
US8943332B2 (en) * | 2006-10-31 | 2015-01-27 | Hewlett-Packard Development Company, L.P. | Audit-log integrity using redactable signatures |
-
2007
- 2007-02-09 US US11/673,496 patent/US7809685B2/en not_active Expired - Fee Related
- 2007-04-20 JP JP2007112344A patent/JP5030654B2/en not_active Expired - Fee Related
- 2007-04-23 EP EP07251693A patent/EP1847935A3/en not_active Ceased
Also Published As
Publication number | Publication date |
---|---|
JP2007293855A (en) | 2007-11-08 |
US20070255530A1 (en) | 2007-11-01 |
EP1847935A2 (en) | 2007-10-24 |
EP1847935A3 (en) | 2010-10-27 |
US7809685B2 (en) | 2010-10-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5030654B2 (en) | Secure and efficient method of logging and data exchange synchronization | |
CN110495132B (en) | System and method for generating, uploading and executing code blocks within distributed network nodes | |
CN110785760B (en) | Method and system for registering digital documents | |
US8903788B2 (en) | Synchronizing distributed work through document logs | |
JP5103243B2 (en) | Server system and method for authenticating document images | |
US8793278B2 (en) | System and method for data preservation and retrieval | |
JP2022509104A (en) | Systems and methods for efficient and secure processing, access, and transmission of data over blockchain networks | |
US8887297B2 (en) | Creating and validating cryptographically secured documents | |
US8572049B2 (en) | Document authentication | |
JP2020526820A (en) | Systems and methods for managing the public software component ecosystem with a blockchain | |
US20090199274A1 (en) | method and system for collaboration during an event | |
JP2012085276A (en) | Digital signatures on composite resource documents | |
WO2017156160A1 (en) | Management of workflows | |
US10691834B2 (en) | System and method of a privacy-preserving semi-distributed ledger | |
US20090019549A1 (en) | Updating and Validating Documents Secured Cryptographically | |
US11003653B2 (en) | Method and system for secure digital documentation of subjects using hash chains | |
WO2000046681A1 (en) | Content certification | |
US11283595B1 (en) | Systems and methods for securing cached data stored off-chain in a blockchain-based network | |
KR20060031583A (en) | Time stamp service system, time stamp information verification server apparatus, and computer software | |
JP2024512068A (en) | Improved signature verification methods and systems for data applications running on blockchain | |
Marian et al. | Requirements Analysis for a System for Certifying Online Content | |
JP3818795B2 (en) | Electronic form processing method | |
WO2002077831A1 (en) | Content certification | |
JP2008305383A (en) | Apparatus and method for authenticating document image | |
Schmidmaier | Design and Implementation of a Decentralized Trusted Issuer Registry for Self-Sovereign Identity |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091225 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20091225 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120124 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120326 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120410 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120511 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20120529 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120626 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5030654 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150706 Year of fee payment: 3 |
|
LAPS | Cancellation because of no payment of annual fees |