JP5103243B2 - 書類画像を認証するサーバーシステム及び方法 - Google Patents

書類画像を認証するサーバーシステム及び方法 Download PDF

Info

Publication number
JP5103243B2
JP5103243B2 JP2008084943A JP2008084943A JP5103243B2 JP 5103243 B2 JP5103243 B2 JP 5103243B2 JP 2008084943 A JP2008084943 A JP 2008084943A JP 2008084943 A JP2008084943 A JP 2008084943A JP 5103243 B2 JP5103243 B2 JP 5103243B2
Authority
JP
Japan
Prior art keywords
log data
log
document
information
workflow
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.)
Active
Application number
JP2008084943A
Other languages
English (en)
Other versions
JP2008243209A (ja
Inventor
ゴーミッシュ マイケル
ライダウト ケヴィン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ricoh Co Ltd
Original Assignee
Ricoh Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Ricoh Co Ltd filed Critical Ricoh Co Ltd
Publication of JP2008243209A publication Critical patent/JP2008243209A/ja
Application granted granted Critical
Publication of JP5103243B2 publication Critical patent/JP5103243B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • 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)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Health & Medical Sciences (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Tourism & Hospitality (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Processing Or Creating Images (AREA)

Description

本発明は一般にディジタルオブジェクトを配布する技術分野に関連し、特に本発明は規制の遵守及び他の規制の設定で使用する情報を書類ログを使って関連付けることに関連する。
サーベンスオクスリー法(Sarbanes-Oxley)及び他のいくつもの法規制は業務で順守することを要する。これらは例えばHIPAA、OSHA、SB1386、NASD2711及びグラムリーチブライリー法(Gramm-Leach-Bliley)等を含む。
業務手続を順守していることを証明する従来の方法は「ペーパートレイル(paper trail)」又は紙の記録を持つことである。例えば、ある費用が「実際のもの」であることを証明するために、レシートが保管される。業者に対する伝票を確認するため、署名済みの購入依頼、他の業者からの見積もり、購入依頼、署名済みの梱包票、及び請求書等が存在するかもしれない。これらの紙の記録は、一般的には、何らかの形式で組織され、綴じられ、フォルダの中に置かれ、ファイリングキャビネット内に整理される。組織(整理)の仕方が良ければ、その紙書類は後に取り出されることが可能である。紙の記録は、例えば伝票番号により、或いは業者により唯一通りにファイルされ、双方によってはファイルできない。従って、他の方法でそれらを取り出すには、あるインデックスにアクセスすることを要し、そのインデックスは例えば伝票番号と支払者を結び付ける紙の又は電子的な記録である。
紙は複製が困難であるという実益を有する。高品質のプリンタを用いる場合でさえ、例えば、請求書から予め印刷されているロゴや用紙を複製することは困難である。同様に、梱包リストの手書き署名を複製することも困難である。しかしながら、アドビフォトショップTMのような画像処理プログラムと共に適度な技量を備えた者は、書類の電子コピーを修正することができる。例えば、請求書の金額を変更したり、或る書類から別の書類へ署名をスキャンして複製することは容易である。従って、電子書類の真正を確認するツールは貴重であり、そのツールは紙と共に利用可能な「トレイル」を維持又は改善するものである。
従来紙が普及しているのは、ほとんど全てのビジネスプロセスが何らかの画像により確認されることを意味する。実際の紙は電子PDFにより置き換わるかもしれないが；それは依然として関心のある視覚的な記録である。公式な書類がエクセルスプレッドシートである場合でさえ、順守の「コントロール」はワークシート中の様々なセルで計算された値であり、それらが視覚的に解釈されるようにラベル付けされる。
電子ファイル(例えば、ワード、エクセル、PDF等)は、データや表示を変える数式又は他の実行ファイルを有し、例えば、スプレッドシートの中で異なる時点で異なる量が表れてもよい。これらは異なる装置や異なるユーザに対する異なる表示になるかもしれない。人的なユーザに提示される実際の画像を計算、提供及び(紙で又はモニタに表示して)認証することは、その人がどんな情報を持っているかを知る唯１つの方法になる。
多くの書類管理システムが過去に提案され実現されている。これらの書類管理システムは、書類を格納し且つリクエストと応答の調整を処理するシステムを含む。しかしながら、これらのシステムは組織境界を越えるものではないし、必要な一致を実現するものでもない。
ポータル、コンテンツ管理システム及びWiKiはビットマップ画像を処理し、タグでサーチすることを許容し、しばしば認識されたファイルタイプで(例えば、パワーポイントスライド、図形、文字のみで)サーチすることを許容する。
ClearCase、SourceSafe、CVS、サブバージョン及びGITのようなバージョン管理システムは、書類のファミリーの変化を検出し、修正の順序を追跡する。“GIT”システムはハッシュを利用して、変更されたファイル及びディレクトリを確認する。あるバージョン管理システムは「ワークフロー」と共に統合され、例えば変更されたソースコードで一群の回帰テスト(regression test)を実行する。そのようなシステムは管理ポイントの視覚的な表現又は意図を持っていない。
TripWireのような命令検出システムは、コンピュータシステムにおける何らかのファイル群が変更されているか否かを暗号化ハッシュを使って確認する。
ウェブログ(Web log)は情報を記録するのに使用されるオンライン書類管理ツールである。ウェブログはクライアントサーバーフレームワークを使って、１つ以上のクライアントロケーションからそのウェブログを主催するサーバにおいて、コンテンツの追加又は取り出しを許可する。１つのサーバが各ウェブログを主催するので、ウェブログは一般に特定のHTTPロケーションに固定される。
Wolff,Gregory J,et al.により西暦2004年7月9日に出願された“Synchronizing distributed work through document logs”と題する米国出願第10/887,998号(特許文献１)は、書類ログの利用を通じて、分散したワークの同期をとることを開示している。そこに開示されているように、書類のようなディジタルオブジェクトに関連する或るセットにメタデータエントリが付加される。メタデータエントリは、そのメタデータエントリを参照する固有の識別子を使ってアクセスされる。一実施例では、固有の識別子の各々がそのメタデータの内容に基づく。
米国特許出願公開第20060010095号明細書
本発明の課題は、書類画像認証サーバ及びそれを使用する方法を提供することである。
一形態のサーバシステムは、１つ以上のワークフローに関連する書類画像を捕捉し、関連するワークフローを表すワークフロー情報を収集した書類にタグ付けする書類受信インターフェースと、前記書類受信インターフェースで捕捉された書類の画像及びメタデータを格納し、前記ワークフローに関して実行される確認処理の際にアクセス可能な第１メモリと、捕捉された書類画像に対応する１つ以上のメディア識別子と共にエントリを含むログを格納し、前記ワークフローに関して実行される確認処理の際にアクセス可能な第２メモリと、前記書類受信インターフェースで捕捉されたワークフローに関する前記書類画像に対応するログデータを生成し、該ログデータをログに格納する第１ユニットと、前記ログに関する情報を別のアプリケーションに提供する第２ユニットとを有するサーバシステムである。
以下でなされる詳細な説明により及び本発明の様々な実施例の添付図面により、本発明は十分に理解されるであろうが、実施例は本発明を特定の実施例に限定するために使用されるべきでなく、説明及び理解を促すためのものに過ぎない。
以下、書類画像を処理する方法及び装置が説明される。一実施例では、ここで説明されるログの利用及びロギング技術は、例えば企業の財務部のような法規制のある環境におけるツールとして使用されてよい。より具体的には一実施例ではサーベンスオクスリー法その他の法規制を企業が順守することを或るサーバが支援する。一実施例ではその支援(アシスタント)は内部的な業務手順を与える。特にそのサーバはこれらの手順と共に「会計検査」や「順守の確認」を行う際に使用されてもよい。
一実施例では、ここで説明される真正確認又は「SOX」サーバは、タグの付いた書類画像を多数のソースから受け入れ、それらの書類の確認可能なログを記憶し、そのステータスに関する情報を1つ以上の他のサーバとやりとりし、特定の時点における書類の存在を確認するツールをもたらす。
以下の説明では、本発明の更なる説明を与えるために多数の詳細が述べられる。しかしながら本発明はそれらの具体的詳細によらず実現されてもよいことは当業者に明らかであろう。また、本発明を曖昧にすることを避けるため、周知の構造や装置は詳細な形式ではなくブロック図形式で示される。
以下の詳細な説明の一部は、コンピュータメモリ内のデータビットを処理するアルゴリズム及び記号表現の観点からなされる。これらのアルゴリズムの説明及び表現は、このデータ処理技術分野の当業者が他の当業者に彼らの仕事内容を最も効率的に伝えるのに使用される手段である。ここで、アルゴリズムは一般に所望の結果に導く首尾一貫した一連のステップと考えられる。そのステップは物理量の物理的処理を必要とするものである。必須ではないが、通常それらの物理量は、格納、転送、結合、比較その他の処理を施すことの可能な電気的な又は磁気的な信号の形態をとる。原則的な一般的な用法の観点から、ビット、値、エレメント、シンボル、キャラクタ、期間、数等としてそれらの信号に言及することが折に触れて便利なことが分かる。
しかしながら、これらの及び類似の用語の全ては、適切な物理量に関連しており且つそれらの量に付された便宜的なラベルにすぎないことに留意を要する。特に断りのない限り、以下の説明から明らかなように、本説明を通じて、「処理」、「演算」、「計算」、「決定」又は「表示」等のような用語を用いる説明は、コンピュータシステム又は同様な電子コンピュータ装置の動作や処理に関連し、その動作や処理は、コンピュータシステムのレジスタ及びメモリの中で物理的な（電子的な）量として表現されるデータを、コンピュータシステムメモリやレジスタその他の情報ストレージ、伝送又は表示装置の中で物理量として同様に表現される他のデータに変換及び処理することが、理解されるであろう。
本発明はここで説明される処理を実行する装置にも関連している。その装置は、必要な目的に応じて特別に構築されてもよいし、コンピュータに格納されているコンピュータプログラムによって選択的にアクティブにされる又は再構成される汎用コンピュータで構築されてもよい。そのようなコンピュータプログラムはコンピュータ読取可能な記憶媒体に格納されてもよく、その記憶媒体は、限定ではないが、フロッピディスク、光ディスク、CD-ROM、磁気光ディスク、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、EPROM、EEPROM、磁気又は光カード等の如何なるタイプのディスクを含んでもよいし、或いは電子的な命令を格納するのに指摘した如何なるタイプの媒体を含んでもよいし、ディスクも媒体もそれぞれコンピュータシステムバスに結合される。
ここで説明されるアルゴリズム及び表示は、特定のコンピュータその他の装置のどれにも固有に関連するものではない。様々な汎用システムがここで教示するものによるプログラムと共に使用されてよく、或いは、必要な方法ステップを実行するように、よりいっそう特化した装置を構築することが便利なことが分かるかもしれない。これら様々なシステムに必要な構造は以下の説明から明らかになるであろう。更に、本発明は特定のプログラミング言語のどれにも依存しない。ここで説明される本発明の教示内容を実現するのに様々なプログラミング言語が使用されてよいことが分かるであろう。
マシン読み取り可能な媒体は、マシン(例えば、コンピュータ)で読み取り可能な形式で情報を記憶又は転送する如何なる手段をも含んでよい。例えば、マシン読み取り可能な媒体は、読み取り専用メモリ(ROM)；ランダムアクセスメモリ(RAM)；磁気ディスク記憶媒体；光記憶媒体；フラッシュメモリ装置；電気、光、音又は他の形式で伝搬する信号(例えば、搬送波、赤外線信号、ディジタル信号等)；等である。
多数のソースから画像データを捕捉し、ワークフロー、管理ポイント及びワークフローインスタンスにその画像を関連付け、(構造化された又は構造化されていない)他のメタデータを捕捉し、データ全ての整合性及びタイミングのロギング及び確認を行い、そのデータへのアクセス権を与える装置及びインフラストラクチャが説明される。
＜メディア識別子、シーケンシャルログ及びエンタングリング＞
＜物理的及び電子的アイテムのメディア識別子＞
ここで説明される発明の多くは、書類(ドキュメント)、ビデオ、歌、紙の一部又は電子ファイルを識別子で参照できることを要する。このため、書類、ビデオ、歌、紙の一部又は電子ファイルはここではメディアとして言及される。メディアを識別するのに使用される識別子は、メディア識別子と呼ばれ、一実施例では、一連のバイトである。
メディア及びメディア識別子間に本発明で有用な関連付けの特性がいくつかある：Ａ）メディアを有する誰もが同じメディア識別子を確認できることは有用である；Ｂ）同じメディア識別子を有する２つの別個のメディア部分を発見することは誰にとっても困難なことは有用である；Ｃ）メディア識別子はそのメディアの内容については何も明らかにしないことは有用である；及びＤ）メディアに対する如何なる変更も別の識別子をもたらすことは有用である。
メディアの一部に識別子を割り当てる方法は多数存在する。電子ファイルの場合、一実施例では、暗号ハッシュ関数(Cryptographic hash function)をファイルのバイトに適用することで識別子が生成される。暗号ハッシュ関数はセキュリティ業界で周知であり、様々な連邦の及び国際的な標準仕様で規格にされているソフトウエアツールキットである。
暗号ハッシュ関数は上記の性質に良く合致するので、識別子を形成するのにたとえ別の技術が使用されていたとしても、一部のメディアの識別子を決定するプロセスを「ハッシュ処理」としばしば言及し、そのメディア識別子を「ハッシュ」としばしば言及する。
ファイルに識別子を割り当てる別の方法もある。例えば、サーバは全てのファイルのコピーを保持し、過去に未使用のストリングを新たなファイル各々にランダムに割り当てる。この方法はＢ，Ｃ及びＤに非常に良く機能するが、誰もがサーバにアクセス可能な場合であって、例えばサービス拒絶でオフラインになる場合でさえサーバを変えることのできない場合にのみ上記のＡの性質に合致する。
ファイルを区別するために暗号ハッシュより簡易な関数を使用することも可能である。例えば、簡易なチェックサムがファイルに使用可能であり、その結果がメディア識別子として使用可能である。これはＡ及びＣの性質を満たすが、Ｂの性質は満たさない。何らかの変更は異なるチェックサムになるが、僅かにそうならない場合もあり、従ってＤの性質は常には満たされない。しかしながら、アプリケーションによってはこれらの性質が重要でないかもしれない。また、２つのメディア部分（何れも同じチェックサムを有し、且つ構造化されたデータの規則に従う）を見つけるのが困難であるように、あるアプリケーションは非常に構造化されたデータを有するかもしれない。
例えば、ある用紙をスキャンし、その結果のスキャンされたファイルの暗号ハッシュを計算することで、一部の紙に識別子を割り当てることができる。しかしながら、スキャン処理中のノイズに起因して、その用紙の別のスキャンがしばしば別の電子ファイルをもたらし、別の識別子をもたらす。この理由のため、バーコード又は他のマシン読み取り可能な識別子(例えば、RFIDタグ)を一部の紙に又は他の部地理装置に取り付けることがしばしば有用である。マシン読み取り可能なIDを利用することは、誰もが同じ識別子を得ることを容易にする；しかしながら、異なるメディアに同じID値を付けることも可能になるので、この場合Ｂの性質は完全には合わない。
一実施例では、マシン読み取り可能なIDの弱点を克服するため、「フィンガープリント処理」形式が物理的なメディアを識別するのに使用される。フィンガープリント処理は或る値を物理装置に関連付けるので、同じフィンガープリント(指紋)を伴う紙の部分又は新たな「フィンガ」を作成することは非常に困難に又は不可能になる。しかしながら多くの場合に「フィンガープリント」は物理メディアに関する何かを露わにしてしまい、フィンガープリントを変えずに物理メディアを僅かに変更できるかもしれない。従ってそのような場合ＣやＤの性質は完全には保たれない。
単独の一部のメディアに関連する複数の識別子が存在してもよい。例えば、SHA1暗号ハッシュ関数をメディアに使用することで形成される識別子や、SHA256又はMD5暗号ハッシュを同じメディアに使用することで形成される識別子があってもよい。一実施例では、鍵の付いたハッシュメッセージ認証コード又はHMACがメディア識別子を計算するのに使用される。HMAC-MD5又はMHAC-SHA1のようなこれらのメッセージ認証コードは、変更可能な鍵を使用するので、B,C,Dの性質に関しては、基礎的な暗号ハッシュ関数(MD5及びSHA1)よりも優れているかもしれない。しかしながら性質Ａはメッセージ認証コードと共に困難になる−なぜなら、同じハッシュを計算するため、それを計算する全ての場所で鍵に対するアクセス権を要するからである。
同じデータの異なるフォーマットに関連する識別子があってもよい。例えば、ファイルのハッシュや、ZIPと共にロスレスに圧縮された同一ファイルのハッシュは、異なる識別子になるが、それらは最終的には同じデータに関連付けられる。
メディアの一部のために形成された識別子があってもよい。例えば、ビデオの場合、異なるフレーム各々について形成された識別子があってもよい。ネットワークでのパケット損失に起因して、同じビデオを見る２人の人々は同じファイルにたどり着けないかもしれないし、従って彼らは同じ識別子を計算できないかもしれない。しかしながら各人はそのビデオのいくつかの同じフレームを受信している。従って、彼らが受信した各フレームのハッシュを彼らが計算した場合、多くの一致するハッシュに起因して、彼らが同じビデオを鑑賞していたことを彼らは確認できる。
同じ例を続けると、同じビデオを鑑賞している２人の人々は、それを異なる解像度で干渉するかもしれない。その場合、２つのフレームは同じハッシュを持たないであろう。しかしながら、例えばJPEG2000パート3のようなスケーラブル法でビデオが格納されていた場合、ビデオの最低解像度の部分は双方の視聴者にとって同じになり、共通するハッシュが確認可能になる。
ビデオがスケーラブルなフォーマットで格納されていなかった場合、一般的にはサーバはビデオの複数のバージョンを異なる解像度で格納する。従ってサーバは全ての解像度の格納しているフレーム全てのハッシュを計算することができ、クライアントに完全に受信されたどのフレームもハッシュ処理可能であり、そのハッシュはビデオを確認するためにサーバ上のものと後に比較される。
ビデオだけでなく、部分的に送信されてよい他のタイプのメディアも存在する。例えば、大きなXML書類の一部が必要とされるかもしれない。このリクエストは例えばXPATHクエリ(問い合わせ語句)によりなされてもよい。クライアントで受信される書類の部分は、サーバで利用可能な書類全体とは異なる。しかしながら、(例えば、XML書類のサブツリーのような)書類の一部について又はXML書類の特定のノードのコンテンツについてでさえハッシュを計算することができる。XML書類の一部分と共にクライアントは、受信したそのサブツリー及びノードのハッシュを計算し、それらはサーバ上の大規模なハッシュリストに適合可能である。
何らかの特定のメディアに関し、関連するデータの一部分がしばしば特定され、これらの一部分は、完全なメディアのハッシュに加えてハッシュ処理可能である。
場合によっては、配布された部分がデータの中で実際に完全には表れないように、データが処理される。例えば、カラーの画像がグレースケールに変換されて配信されてもよいし、或いはスプレッドシート中のエントリの合計が計算されて報告されてもよい。しかしながら、データが２つの場所(例えば、サーバ及びクライアント)に存在する場合、修正されたデータのみが配信される場合でさえ、サーバ及びクライアント双方にとって、修正されたデータのハッシュを記録することが可能であり、受信データ及びそのソース間の関連付けが後に用意されてもよい。
場合によっては「サーバ」は修正されたデータを初めは持っていないかもしれない。例えば、中間的な処理の場合に装置がデータに関する計算を実行する場合である。しかしながら計算のタイプが既知ならば、オリジナルのデータと受信データとを関連付けるようにサーバで後に計算を実行できる。例えば、サーバは高いビットレートのビデオを送信するかもしれないが、ネットワークの輻輳に起因して、途中のルータで品質レイヤを除去することで切り詰めるかもしれない。そしてクライアントはハッシュ処理可能な中程度のビットレートのビデオを受信する。同じハッシュを確認するために、ルータが破棄した品質レイヤなしに、サーバは高ビットレートのビデオについてハッシュ処理を行う。
＜シーケンシャルログ＞
ここで説明される本発明の多くは、イベントシーケンスを読み取ることを含む。イベントの記録は、「ログ」又は「ログ−ファイル」として言及され、船舶や航空機のイベントを記録するログブック(航行日誌)や、コンピュータシステムで行われるアクションを記録するのに使用されるログファイルと同様な関係である。一実施例では、末尾に新たな記録を追加するのは容易であるが、容易に検出される変更を伴わずに、ログの中に既にある記録を変更するのは困難であるという性質を、ログは有する。
従来の「ログブック」又は「ログファイル」とは異なり、一実施例では、記録されているイベントに関する多くの情報をそのログは開示しないことが望ましい。このようにログファイルは非常に多数の人々やシステムに利用可能になるが、その際に、何らかの記録は検査可能であるが、その記録の大部分の内容は秘密のままにするようにできる。
ログのいくつかの可能な実現手段が存在し、それらは追加が容易なこと、変更が困難なこと、情報の部分的な開示等の目的に関して、異なる達成度合いを有する。
ログを実現する概念的に簡易な手段は、不正改ざんできない追記型メモリ(tamper proof write once memory)である。記録(レコード)の各々はメモリに順番に書き込まれる。これは追加に容易で修正困難な目的には合致するが、「不正改ざんできない」メモリが変更されていないことを遠隔的に確認することは困難である。
ログを実現する１つの方法は、一連のレコードを作成することであり、そのレコードの各々は、以前のレコード中の何らかの情報のハッシュ、及び現在のレコードの内容を含む。例えば、ｉ番目のレコードのメッセージ部分をMiとし、ローリングチェックサム(rolling checksum)をriとする。ｉ番目のレコードについてのローリングチェックサムは、次のように計算できる：
ri=hash(ri-1．Mi)
この場合に、メッセージ及び以前のチェックサムは連結され(“．”で表現されている)、ハッシュ関数に与えられている。この場合のログは、メッセージ及びチェックサムのシーケンスで構成される(Mi，ri)。一実施例では、そのログへの追加は、最後のチェックサムと現在のメッセージを取り出し、それら２つを連結し、ハッシュを計算することで作成されてもよい。これは図１に示されている。図１を参照するに、新たなメッセージ及びチェックサムのペアを作成するため、メッセージ及びチェックサムのジェネレータ101は、新たなメッセージMi+3及びログ110の中で最後のエントリのチェックサムri+2を受信する。連結モジュール102は以前のチェックサムri+2とメッセージMi+3を連結する。ハッシュモジュール103は上述したようにハッシュ関数を適用し、次のチェックサムri+3を生成する。メッセージMi+3及びチェックサムri+3はログ110に格納される。メッセージ及びチェックサムジェネレータ101は、連結モジュール102及びハッシュユニット103と共に処理ユニット(例えば、マイクロプロセッサ)で構成され、102,103は処理ユニットで実行される命令のソフトウエアモジュールであることに留意を要する。或いは、これらの機能はハードウエアで実現されてもよい。
ログの中のメッセージの1つが修正された場合又はログの中のチェックサムの１つが修正された場合、以後のチェックサムは正しくなくなる。従ってレコードの修正はメッセージ及び以後の全てのチェックサムの修正を要する。チェックサムの１つが複製されてどこかに保存されると、そのチェックサムに先行する如何なる修正も消去可能になる。修正がチェックサムの変更無しになされた場合、ログ中のそのローリングチェックサムのハッシュを再計算するとエラーを表す。ハッシュが全て変更され、ログが自己矛盾しないようになった場合、それらは外部に保存された値とは合わなくなるであろう。
上述したように、ハッシュ関数は簡易なチェックサムでもよいが、好ましくは暗号ハッシュ関数である。
本方法はログの目的にほぼ合致するが、更なる利便性をもたらす変形例もある。
１つの変形例は、メッセージ自身でなくメッセージのハッシュをログに保存することである。従って、miが次のように定義される場合：
mi=hash(Mi)
ログは(mi,ri)の二乗として定義でき、riはメッセージハッシュ及び以前のチェックサムのみのチェックサムである：
ri=hash(ri-1．mi)。
これは図２に示されている。図２を参照するに、新たなメッセージ及びチェックサムのペアを作成するため、メッセージ及びチェックサムジェネレータ201は、新たなメッセージMi+3及びログ210内の最後のエントリのチェックサムri+2を受信する。連結モジュール102は以前のチェックサムri+2とメッセージMi+3を連結する。ハッシュモジュール103は上述したようにハッシュ関数を適用し、次のチェックサムri+3を生成する。ハッシュモジュール203はハッシュ関数をメッセージMi+3に適用し、ハッシュ処理されたメッセージmi+3を生成する。一実施例では、ハッシュモジュール203に適用されるハッシュ関数は、ハッシュモジュール103に適用されたハッシュ関数と同じである；或いは、ハッシュモジュール203に適用されるハッシュ関数は、ハッシュモジュール103に適用されたハッシュ関数と同じでなくてもよい。メッセージmi+3及びチェックサムri+3はログ210に格納される。メッセージ及びチェックサムジェネレータ201は、連結モジュール102、ハッシュユニット103及びハッシュユニット203と共に処理ユニット(例えば、マイクロプロセッサ)で構成され、102,103,203は処理ユニットで実行される命令のソフトウエアモジュールである。或いは、これらの機能はハードウエアで実現されてもよい。
本方法は、ハッシュ関数が固定長を有する場合に(通常的にはこの仮定は正しい)、固定長のレコードを生成するという利点を有する。更に本方法は如何なるメッセージのコンテンツもログに持ち込まない利点を有する。メッセージが何らかの顧客情報であった場合(例えば、名前、住所その他の情報の入った購入依頼であった場合)、メッセージを公表することは好ましくない。しかしながら、ハッシュ関数がそのメッセージに関する情報を明らかにしないのであれば、情報を公表することなく、(mi,ri)のシーケンス全体(即ち、ログ)を公表できる。
場合によっては、メッセージのハッシュ単独よりも多くの情報を伴うログを有することが好ましい。例えば、ログに格納された時間や、公表されたログに格納されたログエントリの情報タイプを有することがしばしば有用である。これは特定のレコードを求めてログをサーチすることを容易にする。読み取り可能なレコードの情報が「プレインテキスト(平文)」(tiと言及する)で規定されていた場合、ログは(ti,mi,ri)のシーケンスで構成され、各々のチェックサムriは次式で計算される。
ri=hash(ri-1．ti．mi)。
この数式は非常に一般的である。なぜなら、tiの部分は更なる構造を含んでもよいし(例えば、日にち、タイプ、ファイル名を常に含んでもよい)、メッセージも構造化されてよいからである。当然に、以前のローリングチェックサム、現在のメッセージ又はメッセージハッシュ及び「平文」情報の順序は、その順序がチェックサムを生成する或いは確認する必要のある全てのアプリケーションに既知である限り、変更可能である。
ログ中の情報への部分的なアクセスをもたらす別の方法は、ログに保存されている情報の一部を暗号化することである。あるログに関する暗号化された情報がEiであり、Eiのハッシュがeiであったとする。一実施例では、Ei又はeiはログに格納可能である。そして、ログエントリは(ti,mi,Ei,ri)で構成され、即ち、平文の部分、メッセージのハッシュ、或る暗号化されたデータ及びログ中の以前のハッシュに関するチェックサムで構成され、それらはメッセージのハッシュと共に連結される。一般に、時間が混ざってもよく、レコードは、いくつかの平文の部分、いくつかの暗号化部分及びいくつかのメッセージのハッシュを含んでもよい。
一実施例では、ログエントリのフォーマットは、データを伴う一群のヘッダ「ライン」及びボディで、例えば次のように表現される。
作者：ゴーミッシュ(gormish)
SHA1：1bff5d8cda307b5f3f3757cb25588a54cfb01ce0
コンテンツ長：５６７
５６７バイトのデータ。
一実施例では、このフォーマットタイプはhttp及び電子メール(email)に使用される。従って、いくつかの周知のヘッダが規定されており、ログで使用可能である。
ログの中の異なる暗号化エントリや異なるタイプの暗号化エントリについて、異なるキー(鍵)が使用されてもよい。例えば、全てのエンタングルメント(entanglement)情報が１つのキーで暗号化され、全ての分類値に異なるキーが付随してもよい。そのログが1つの書類に関連付けられ、その書類が暗号化される場合、ログ中のエントリはその書類に使用されたのと同じキーで暗号化されてもよい。これにより、書類にアクセス権を有する誰でもが、ログ中の情報にアクセスすることを許可される。
一実施例では、異なる複数のローリングハッシュ又は異なるタイプのハッシュをログはサポートし、それらのハッシュは異なる暗号化ハッシュ関数と共に計算されたものである。例えば、一実施例では、値riは次のようになる：
ri=hash(ri-1．ti．mi)。
そして、tiの値は(例えば、MD5、SHA1、SHA256等のような)どのハッシュ関数が使用されていたかを特定する。一実施例では、２つの異なるローリングチェックサムを共なうログエントリは、次のようなエントリを有し：
(ti,mi,ri,si)
ここで、riは次式で計算される：
ri=SHA(ri-1．ti．mi)。
siは次式で計算される：
si=SHA256(si-1．ti．mi)。
これは、唯１種類のハッシュしかサポートしないシステムと共に同じログが使用されることを可能にし、あるハッシュ関数が不具合を生じた場合、他のハッシュ関数が依然として有効であり、双方の組み合わせは不具合に対して強くなる。２つ以上のハッシュ関数を使用するログの他の例は、当業者には明白であろう。
新たなハッシュチェーンをログに遡及的に追加するログエントリが追加可能であることに留意すべきである。ログがメッセージ及びローリングハッシュのペア(Mi,ri)で構成され、ri=SHA(ri-1,Mi)であり、ｉは１乃至Ｎの範囲内にあるとする。新たなメッセージがログに追加可能であり、そのログは、古いメッセージと、異なるハッシュ関数と共に計算された新たなローリングハッシュとを含む。そして、メッセージＮ＋１は新たなハッシュ関数と用いて計算されたローリングチェックサムと共に結合された第１メッセージである。一般に：
MN+1=Mi．si
であり、ここで、
si=SHA256(si-1,Mi)
である。これは、同じものをカバーする新たなハッシュを加えることで、ハッシュ関数に障害のあるログの後の修正を可能にする。ハッシュ関数に障害があり新たな関数が発見される場合、いくつのハッシュ関数がこの形式で遡及的に適用されてもよい。
一実施例では、第２のハッシュ関数はその計算の際に第１のハッシュ関数を利用得する。例えば、
si=SHA256(si-1．ti．mi．ri)。
又は
si=SHA256(ri-1．si．ti．mi)。
でもよい。
＜ログの記憶＞
一実施例では、ログは単独のファイルに順に格納される。この種のログは非常に用に作成できる。なぜなら、最後のエントリによるローリングハッシュが読み取られ、新たなデータはファイルの末尾に加えられるからである。エントリが固定長であった場合、ファイル中で特定のエントリを見つけるのは容易である。多くの場合に単独のファイルで十分であり、特にログが（過剰に多くのエントリを含んでいない）単独の書類に関する場合には十分である。
場合によっては、ログが非常に長くなるかもしれない。なぜなら通常的には一般的なイベントのレコードが作成され続けるからである。ログが複数のソースからのデータを蓄積するように使用される場合、いくつものエントリが毎秒存在するかもしれない。この場合、例えば10,000エントリ毎に、ログを複数のファイルに分断することが有用かもしれない。
別の実施例では、各ログエントリが個別のファイルに格納される。この場合、高速アクセスに備えて、最も新しいエントリを指すポインタが使用される。一実施例では、レコードはその中にシーケンス番号を含み、最も新しい最近のレコードは、全てのレコードの番号を検査することで判定できる。１つの技法は、ローリングハッシュと共にファイルを指名することであり、そのファイル内の以前のレコードのローリングハッシュを含む。こうして、最も新しいエントリから、ポインタに従って全てのエントリに遡って進行することができる。
別の実施例では、ログエントリの各々がデータベースのレコードになる。特定のメッセージハッシュ、ローリングハッシュ、時間範囲又は平文を速やかに、或いはログエントリの残りのコンテンツが含む場合はいつでも、サーチできるようにする点でこれは非常に有用である。データベースは処理の統合性をもたらすので、データベース手段は、大量のエントリがログの中で作成された場合に有用である。
＜ライトワンスメモリ＞
イベントがシーケンスで発生することを保証する数学的方法に加えて、一実施例では、物理的な改ざん防止装置がイベントのシーケンスを記憶するのに使用される。一実施例では、物理的な改ざん防止装置はライトワンスメモリ(write once memory)であり、メッセージのハッシュを順番に格納する。この種のログのエントリを変えることは、メモリを変更することを要する。
ライトワンスメモリは簡易であるが、改ざんされてないことを遠隔的に確認することは困難である。従って、一実施例では、改ざん防止システムはディジタル署名又は他の認証手段をそのコンテンツのために用意する。
＜エンタングリング＞
１つのログを修正することは比較的容易なので、一実施例では、ログの間で情報がやりとりされ、或るログの中のエントリの修正が他のログを調べることで検出可能にする。第１ログの中の情報全てに依存する情報を第２ログに格納することは重要である。以前に定義されているログの場合、ローリングチェックサムはその性質を備えている。チェックサムの各々は、ログエントリ中の他のデータ及び以前のチェックサムに依存する。従って、ログエントリの何らかの部分が変更された場合、そのローリングチェックサムが変わり、その時点以後のローリングチェックサムも変わる。「ハッシュ」に使用される計算関数によらず、メッセージ又はレコードがハッシュよりも長かった場合、同じハッシュを持つ複数のメッセージ又はレコードが存在する。しかしながら、ローリングチェックサムに使用される関数が上手に選ばれていたならば、例えば暗号ハッシュ関数は、これらのメッセージを発見することを極めて困難にする。
あるログからの情報を別のログに格納するいくつもの方法がある。このプロセスはエンタングリング(entangling)−相互依存方式−と呼ばれる。なぜなら、あるログからの情報を別のログに格納した後、第２ログでの将来の全てのローリングチェックサムは、第１ログでの情報に依存することになるからである。
一実施例では、使用されるログは、メッセージハッシュ及びローリングハッシュのペア−即ち、(mi,ri)−を格納しており、第２ログ内のエントリのメッセージハッシュは、第１ログからのローリングハッシュで置換される。従って、第２ログ内のそのエントリ以降の全てのローリングハッシュは、第１ログからのそのローリングハッシュに依存する。
これは最も簡潔な例であるが、エンタングリングの際に格納される限られた量の情報により、エンタングリングの性質がどのようであるかを判定しにくくすることができる。従って、一実施例では、エンタングルメントに使用されるログエントリに追加的な情報が含められる。例えば、あるタイプの値を使うこれらのログは、そのタイプを設定し、そのデータが「正規のメッセージ」でなく「エンタングルメントエントリ」であることを示すようにしてもよい。更に、メッセージハッシュの代わりにローリングチェックサムを直接的に使用しないで、第１ログからのローリングハッシュ及び第１ログの場所(例えば、サーバ名、ログ名、ファイル名、URL等)を含むメッセージが形成されてもよい。一実施例では、第１ログのローリングハッシュのロケーション(例えば、シーケンス番号、データ等)が包含される。この例は、ログが後に続くことを可能にし、現在のログが依存する他のログを判定可能にする。
多くの場合に、どのログが第１ログに依存するかを判定することが望ましい。これを支援するため、エンタングルメントがなされる場合に、双方のログに情報が格納されてよい。図３はペアのログにエンタングルメントを施すプロセスの一例を示すフローチャートである。このプロセスは処理ロジックで実行され、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。
図３を参照するに、情報を格納する処理ロジックによりプロセスは始まり、ログＡの現在のローリングチェックサムをログＢのログエントリに含める(処理ブロック301)。
次に、処理ロジックは、ログＢに関する情報をログＡに格納する(処理ブロック302)。一実施例では、ログＡに格納されたログＢに関する情報は、ログＢのサーバ名、ファイル名又はURL、及びエンタングルメントが格納されるログの中の場所を含んでもよい。一実施例では、ログＡに格納される情報もログＢからのローリングチェックサムを含んでよい。チェックサムが格納されると、エンタングルメントがログＢからログＡへ及びログＡからログＢへなされる。
＜確認手順＞
多くの場合に、ログが作成されて以来ログが修正されているか否かを確認する必要がある。これはソフトウエア、コンピュータシステム及び人々(ログ生成のハードウエア、ソフトウエア及び人々と独立な人々)によってなされるべきである。
一実施例では、ログが首尾一貫していることを確認するため、(図８のコンピュータシステム(又は専用マシン)におけるもののような)確認ソフトウエアが、ログの中の各エントリについてローリングハッシュを再計算する。確認ソフトウエアで計算されたローリングハッシュが、ログに格納されているローリングハッシュと合致したならば、そのエントリは、ハッシュ関数が漏洩していない限り、変更されていない。この場合において、ハッシュ関数が「漏洩している」とは、２つの別個のバイトシーケンスが、同じハッシュをもたらすことが発見されていることを意味する。
ログのエントリが複数のログの間で一致するか否かを確認する際、そのエントリは、他のログに格納された(エンタングルされた)ローリングチェックサムを含む及び関心のあるメッセージの中で一貫している必要がある。第２ログの中のエントリは、エンタングルメントエントリの前後で首尾一貫している必要がある。
＜エンタングリング検出手順の具体例＞
エントリが作成されて他のログとエンタングルされた後のある時点で、ログに格納されたメッセージの有効性を第三者が確認することを希望する場合、エンタングルメント検出は、メッセージに一致するエントリを有する全てのサーバが判定されることを可能にする。図４はエンタングルメント検出を実行するプロセスの一例を示すフローチャートである。このプロセスは処理ロジックで実行され、その処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータ又は専用マシンで動作するようなもの)又はそれらの組み合わせで構成される。
図４を参照するに、空集合の(空であることの)証拠を有するサーバのリストを初期化し、単独のメッセージ又は所望のハッシュに関心のあるメッセージ又はハッシュのリストを初期化し、全ての既知のログについて関心のあるメッセージ又はメッセージハッシュをサーチする(処理ブロック401)処理ロジックによってプロセスは始まる。メッセージ又はそのハッシュが何処にも発見されなかった場合、確認は不可能であり、プロセスは終了する。
関心のあるメッセージ又はハッシュが発見された場合、処理ロジックは、メッセージ又はハッシュに続くローリングチェックサムを、そのメッセージ又はメッセージハッシュの発見されたログ全てについて確認する(処理ブロック402)。一実施例では、これは、確認ソフトウエアを使ってそのログについてチェックサムriを再計算することでなされる。
処理ロジックは、関心のあるハッシュ以後に表れる全てのローリングハッシュにハッシュのリストを付加し、現在のログで参照されるどのログにも、関心のあるログのリストを付加する(処理ブロック403)。あるログは他のログをリスト化せず、その場合そのサブステップを実行するものはない。
処理ロジックは、未探索の既知のログの1つの中で関心のあるリストのハッシュにおける全てのハッシュを探索する(処理ブロック404)。その後、処理ロジックはローリングハッシュがそのログに現れるか否かを検査する(処理ブロック405)。現れなければ、処理は処理ブロック404に移り、その処理を続ける。ローリングハッシュがログに現れた場合、処理ロジックは、オリジナルのメッセージ又はハッシュについての証拠(エビデンス)と共にそのログをログのリストに加え(処理ブロック406)、関心のあるハッシュ以後そのログに現れる全てのローリングチェックサムをそのハッシュリストに加え(処理ブロック407)、そのログで参照されるどのログもそのログリストに加える(処理ブロック408)。
その後処理ロジックは探索する何らかの別の既知のログが存在するか否かを確認する(処理ブロック409)。無ければ処理は終了する。有れば、処理は処理ブロック404に移り、関心のあるハッシュのリストに新たなハッシュが追加されなくなり、新たなログがリストログに追加されなくなるまでプロセスが反復される。
一般に、同じ装置、同じオフィス又は同じ会社に多くのログが保管されている。しかしながら、あるログが、複数の物理装置上の複数のログと関わりを持つ場合(エンタングルされる場合)又は異なる企業の管理下にあるログと関わりを持つ場合、そのログを確認する者は、そのログが変更されていないことについて更に多くの信頼を得るであろう。様々な装置とエンタングリングを行うこの利点は、ログはエンタングルされたログのアドレスを(企業及び装置境界を越えて)格納できるべきであることを意味する。これを行う1つの方法は、ログを特定するURLを利用することである。
以下のパイソン(Python)ソースコードは、他のログの中でメッセージハッシュを確認するログを判定する。このソースコードは、他のログへのリファレンスを含まないログの特定の形式で動作するように設計されている。従って、それは検査に初期化されたそのログの中だけで証拠を見つけ、新たなハッシュが既知のログだけについて探索される。ソースコードは、複数の独立したhttpサーバからログにアクセスするように設計されている。ソースの実行は今の場合サーバ毎に唯1つのログを使用しているが、サーバ当たり複数のログを許容するようにURLが修正されてもよい。
以下のサンプルソフトウエアは、有効なエンタングルメントを確認するのに使用されてよい：
一般に、ログを確認する上記の技法は多くの処理を含むかもしれない。しかしながら、以前に探索したログ及びハッシュの良好な追跡結果を保持することで、その複雑さを減らすことができる。ある時間以前に生じているログエントリを単に考察することで、或いは例えば或るログがエンタングリングに頻繁に使用されていることが分かっていた場合にそのログを先に探すことによっても複雑さを軽減することができる(そのログは早期に探索可能である)。
＜ログによる確認＞
ログの中のローリングチェックサムは、認証機構の一部に使用可能である。例えば、最も新しいローリングチェックサムrNの情報が、あるログに追加的なエントリを書き込むことの許可に使用されてもよい。ログを保持する装置は、最新のチェックサムが新たなログエントリに用意されていることを主張できる。そうすることで、２つの装置がそのチェックサムを知っており且つ双方がそのログに書き込みを要求した場合、一方のみが成功するようにできる。新たなログエントリを用意する第１の装置は、チェックサムの変更を引き起こし、以後、第２の装置は適切なチェックサムを持たなくなる。この技法は、データの提供者がそのログに関して最も最新のデータ情報を有する場合にのみ、新たなデータが追加されることを保証する方法をもたらす。こうして、チェックサムはログについての「ロック(lock)」のように使用可能であり、競合する状況を回避できる。
上記では、ログへのアクセスを管理するためにローリングチェックサムを使用することを説明しているが、ローリングチェックサムは、同じログが再び使用されることを防止するために使用されてもよい。その場合、ログの完全な内容は公に利用可能になっているべきでない。あるログを使って何者かがシステムと最初にやり取りを行い、そのログにメッセージを格納し、ローリングハッシュをシステムに提供する(例えば、ある口座に預金がなされた場合にメッセージが格納されるかもしれない。)。以後、その口座から引き出しが望まれる場合、システムはその預金をするのに使用されたローリングハッシュを要求する。更なるセキュリティが望まれる場合、一実施例では、システムはそのローリングハッシュについての情報(例えば、そのローリングハッシュのハッシュ及びチャレンジストリング)を要求する。システムは以前のやり取りに関する情報の一部分を要求することもでき、それはそのログを所有する者によってのみ回答可能である。
＜サーベンスオクスリー法の概要＞
サーベンスオクスリー法は概して以下の４ステップを要求するようにまとめられる：１）書類ビジネスワークプロセス；２）リスク確認；３）リスクを限定する管理ポイントの実現；及び４）実現手段の検査。本説明に関し、全てのワークプロセスはフローチャート又はフローダイアグラムで規定され、異なるフローチャートを伴う各ビジネスフローは異なる「ワークフロータイプ」として言及される。例えば、購入、月末締め及び出張要求等のような様々な業務処理の各々についてワークフローが存在してよい。図５には、「セールスクレジット管理」のワークフロータイプのサンプルが示されている。
一実施例では、各ワークフローは複数回使用されてもよい。例えば、「月末締め」ワークフローは年に１２回使用される。「購入」フローは、月に何百回も使用されるかもしないし、所与の何らかの時点で、ワークフローの様々なインスタンスが様々な段階にある(例えば、承認待ち、配布待ち、カットされる検査待ち等である。)。
一実施例では、各ワークフローは１つ以上の管理ポイント一式を有する。これらの管理ポイントは、監査(オーディット)で検査される項目である。「セールスクレジット管理」の管理ポイントは、図５のフローチャートでクロスハッチパターンのドットで示されている。各管理ポイントは、その管理が行われたことを確認することに関する何らかの書類画像を有する。このタイプの書類画像は、ワークフロータイプ及びそのワークフローのステップに依存する。購入ワークフローの場合、書類タイプは、リクエスト、見積もり、発注書(PO)、梱包リスト、請求書又は伝票等であってよい。月末締めの場合、このタイプは一般の台帳のエントリでもよいし、その月末処理が完了したことを宣言する最高財務責任者(CFO)からの電子メールでさえよい。
一実施例では、この履行を監査するのに要する書類収集は、(ワークフロータイプ、ワークフローインスタンス及び管理ポイントである)三要素で記述される。ワークフロー中のループに起因して、特定の三要素(ワークフロー、インスタンス及び管理ポイント)に関する１つより多くの書類が存在するかもしれないことに留意を要する。
以下の説明は、一群のやり取り及び装置を説明し、それらは監査で支援するビジネスプロセスの知識を利用する。一実施例では、「SOXサーバ」は、「書類画像」を追跡することで監視可能な何らかの法規制又は内規に有用な監視法をもたらす。
＜ユーザインタラクション＞
一実施例では、SOXサーバと主に２つのユーザのやり取りがある：タグ付けされた書類画像を追加すること、及び書類画像及びタグにアクセスし、例えば何らかの規制に準拠していることを確認することである。確認の際、特定の書類の「信憑性」に関する追加的な情報(即ち、書類が変更されてないこと及び／又は適切な者によって処理されたことの証明)を取得することができる。
一実施例では、メインユーザのやり取りに加えて、ワークフロー及びワークフロー中の書類タイプが規定されるコンフィギュレーション処理が存在する。
＜多数のソースからの画像及びメタデータ捕捉＞
一実施例では、SOXサーバは様々なソースから画像及びメタデータを受信する。この場合において、電子ソースは紙のソースと差異がない。書類はスキャンされ、電子ファイルはビットマップに変換され、ファイルは共有されるディスク、電子メール、ftp、http等を介してコンピュータから直接的に受入可能である。
現在の装置における今日のネットワークプロトコルを利用して、書類はスキャンされ、電子ビットマップはディスクに直接的に又は電子メールを介して送信される。一実施例ではこれらのコネクションは安全に(セキュアに)用意される。更に、適切なビットマップを受けたことが確認されてもよい。例えば、複合機(MFP)はビットマップの暗号ハッシュを作成し、それを保存してもよい。サーバはハッシュを作成し、それをレシートとして返送し、MFPは比較を行い、双方のハッシュの記録をとる。
一実施例では、画像エントリ、ワークプロセスのエントリ、チェックポイント、インスタンス及び画像に関する他の何らかのメタデータのエントリの制御は、１つ以上の通常のインターフェースと共になされる。例えば、データはマシンのフロントパネルに入力されるかもしれないし、管理又はジョブシートが書類と共にスキャンされるかもしれないし、或いはソース書類のウォーターマーク又はバーコードがプロセスを管理するために使用されるかもしれない。
印刷される書類に関し、印刷時点で、ほとんどのコンピュータアプリケーションプログラムは、書類画像がどのようにしてビットマップに変換されるべきかに関する特定の命令をプリンタドライバへ送る。一実施例では、プリンタドライバはこれらの命令(指示)を目視可能な画像に変える。一実施例では、このシステムはその画像を人のユーザに提示し、対話式のコンピュータインターフェースを用意し、ワークプロセス、チェックポイント、インスタンス及び必要なメタデータを収集する。一実施例では、そのスキャンする方法に類似するセキュリティ及び確認がなされてもよい。
一実施例では、書類及び／又は書類画像がHTTPサーバ及びウェブブラウザを介してシステムに入力されてよい。一実施例では、SOXサーバは、データエントリ及びメタデータ収集を制御するウェブサイトを提供する。これは安全且つ認証された処理をもたらす。
書類画像は電子メールのボディ(本体)に又はアタッチメントとして送信可能である。一実施例では、その制御及びメタデータは、サブジェクト、ボディ及びその他の電子メールのフィールドを用いて構造化された方法で送信される。サーバが適切なデータを受信しなかった場合、更なる情報を求めてリターン電子メールが送信される。ユーザは適切にフォーマットされた電子メールと共に応答し、リターン電子メールの多数のリンクに応答し、多数の電子メールアドレスに応答し、HTTP通信を開始し、或いは他の応答を行うことができる。このやり取りは、適切な電子メールクライアント及び／又はコンフィギュレーションが使用されるならば、安全であって認証されるようにすることができる。
一実施例では、このやりとりは他のコンピュータ入力と非常によく似ているが、メタデータの添付を可能にするこれらのプロトコルとのインターフェースが一切存在しないことが間々ある点で異なる。一実施例では、メタデータを管理及び追加するために、ある階層の特定のディレクトリを使用することでその問題は克服される。或いは、メタデータを含むファイルは、何らかのルールに基づくネーミングシステムに関連付けられてもよい。更に別の実施例では、そのデータのためのインターフェースを備えた特殊なアプリケーションプログラムが存在する。
＜順守の証明法＞
サーベンスオクスリー法では、ワークフロー各々について、ワークフローの使用頻度に基づいて、多数のランダム検査がなされる。例えば、月に500回使用される購入ワークフローは何回も検査されるが、年に12回しか使用されない「月末締め」は数回しか検査されなくてよい。
全ての場合において、「確認(verification)」は、ワークフローと、そのワークフローのインスタンスについて管理がなされたか否かの判定とに基づく。SOXサーバでは、各管理ポイントの視覚的なレコードがある。
図６は購入ワークフローのサンプル書類を示す。図６を参照するに、リクエスト書類、見積もり、購入依頼、梱包リスト、請求書及び伝票に応じて６つの管理ポイントが存在する。別のワークフローでは、別名の管理ポイントや別の数の管理ポイントになるであろうが、各管理ポイントの何らかの視覚的な表現は依然として存在する。図６を縦向きに見ると、異なるワークフローインスタンスがあり、その各々は異なる購入リクエストに対応する。
１つのリクエストが複数の見積もり、複数の購入依頼、複数の請求書及び複数の伝票をもたらすかもしれないことに留意を要する。或るワークフローインスタンスの特定の管理ポイントについて、書類が存在しないかもしれない。図６に示されているように、第二ワークフローインスタンスでは、「見積もり」がない。特定の業務ポリシに依存して、その省略はより多くの監査を引き起こすかもしれない。また、ある書類を避けることを受け入れてもよい(例えば、「標準的な」項目についてのあるリクエストは、見積もりを要しないようにしてもよい。)。或るワークフローでは、複数の分岐が存在し、(例えば、＄5000を越える購入は別の承認を要する場合のように)特定の分岐が使用された場合にのみ、或る管理ポイントが使用されてもよい。
一実施例では、SOXサーバは、管理ポイントに与えられた書類の意味論的な如何なる検査(semantic checking)をももたらさない。ある特定のワークフローについての「請求書(invoice)」として空白ページを入力することが可能である。従って、完全な確認は、管理ポイント画像の人による検査を含む。しかしながら、そのような確認はサーバ及びメタデータ(意味論的な検査がなされていること、それを行った者がシステムに記録され、その書類画像に関して後に認証されることを示す)により支援可能である。
＜書類の真正＞
一実施例では、サーバは書類の内容を意味論的に理解する如何なる支援も行わない。しかしながら、書類を確認する際に支援するのに外部ソースから証拠を提供する。どの書類についても、初期の格納時間及び格納に関連するメタデータが用意される。これは、ワークフロー三要素からの情報を含んでよいが、ユーザ名や部署名等の情報を含んでもよい。一実施例では、サーバは「暗号化チェックサム」(例えば、ハッシュ値)を他の装置(例えば、サーバ、他のロギング装置、サーバを含むもの等)と通信するように構成される。この通信は、その書類が特定の時点で存在していたこと及びその書類がその時点以来修正されていないことを証明できる。
書類を認証するのに利用可能な情報は、書類が記録された時に入力された如何なるメタデータを含んでもよい。これは、スマートカードになされているディジタル署名（スキャナからのもの）や、プリンタドライバからのPINを含んでもよい。利用可能なタイミングデータはより複雑なものでもよい。一実施例では、タイミングデータはSOXサーバからのタイムスタンプである。そのようなタイムスタンプは、マシンにアクセス権を有する者によって変更されているかもしれない。従って、他のサーバに至る経路(チェーン)をたどり、その経路に関するそれらのタイムスタンプを抽出することが可能である。ハッシュチェーンを利用することで、第２サーバでのタイムスタンプ以前に生じている如何なるログエントリをも認証できる。例えば、2006年9月28日木曜日午前9:57(PST：太平洋標準時間)に書類が入力されたことを、ローカルサーバが主張するかもしれない。いくらか後にエンタングルされたログを有するサーバは10:03AM以前にその書類が存在したことだけを確認し、日に一度だけそのサーバとエンタングルされたサーバは、5:00PM以前にその書類が存在したことを確認できる。サーバが１日に少なくとも１回エンタングルされるとすると、どの特定の書類の日付の信憑性も確固としたものになる。
一実施例では、ローカルSOXサーバは書類の真正についての情報を提供する。或いは、例えば監査人のコンピュータのような確認装置上の信頼できるアプリケーションが、検査対象のサーバを問い合わせるのに使用され、ローカルSOXサーバで要求されるエントリをそれらが含んでいることを確認する。
＜SOXサーバの実現手段＞
図７はSOXサーバ及び関連するシステムの一例を示すブロック図である。各ブロックは処理ロジックを表し、処理ロジックは、ハードウエア(回路、専用論理回路等)、ソフトウエア(汎用コンピュータシステム又は専用コンピュータで動作するようなもの)又はそれらの組み合わせで構成されてよい。
図７を参照するに、SOXサーバ700自体は大きな中央処理装置である。書類は波0素なるコンピュータ(PC)、スキャナ、複合機等から捕捉される。書類受信インターフェース701は、収集した書類にワークフロータイプ、ワークフローインスタンス及び管理ポイントのタグを付ける。書類及びメタデータは、画像及びメタデータ格納部702に保存され、それらは記録され(例えば、ハッシュが生成される)、メモリ704内のログ703に保存される。
ワークフロー識別部710は、書類受信インターフェース701で受信された書類に関するワークフローを識別する。一実施例では、書類を提供するユーザが、ワークフロー、タイプ、管理ポイント及びワークフローインスタンスさえも指定する。しかしながら、例えば、 には、画像分析が書類タイプを判定できる場合、ユーザはSOXサーバ700により支援され、その情報を使って、ユーザに提示されるワークフロー及びインスタンスに関する選択肢数を減らしてもよい。一実施例では、ワークフロー識別部710は、光文字認識を実行する光文字認識(OCR)モジュール711と、書類受信インターフェース701で受信した書類について画像分析を実行する画像分析モジュール712とを含む。両者の機能は、或るワークフロー、ワークフローインスタンス又は管理ポイントに特定の書類を関連付けるのに使用され、ユーザにその情報を提供する必要性を排除してもよい。
ログジェネレータ705は、他のサーバと通信を行ってチェックサム情報をやりとりする。ワークフロー更新アイテムは、書類又はステータスに関する情報を他のサーバから取得し、それを使って、画像の記憶やワークフローインスタンスの集まりを更新する。
一実施例では、確認モジュール706はSOXサーバと独立している。なぜなら、確認プロセスは、SOXサーバが漏洩しているか否かを検出できることを要するからである。確認モジュール706はSOXサーバ及び(SOXサーバが関わりを持っている)他のサーバからの情報にアクセスする。ローカルSOXサーバでデータが変更されていた場合、ローカル名ログは矛盾するようになるか、或いは他のサーバでのエントリのコピーが一致しなくなる。
＜書類ロギング＞
一実施例では、各画像がSOXサーバに負荷されるので、SOXサーバは書類のハッシュ値をログに付加し、そのログに格納されるローリングチェックサムも算出する。ワークフロータグ及び他のメタデータ並びに他のサーバからのチェックサムもそのログに格納される。一実施例では、SOXサーバは「ログエントリタイプ」、「メッセージハッシュ」及び「ローリングハッシュ」又はチェックサムをログに格納し、メッセージハッシュ及びローリングハッシュは、SHA-1が使用される場合は12バイトであり、SHA-256が使用される場合は32バイトである。このようにして、一実施例では、ログに含まれる情報は以下の表１のように組織される。“#1”のような項目を除いて、20バイトの２進値又は40バイトの16進値が格納されることに留意を要する。
一実施例では、タイプ情報がログに格納される。代替実施例では、タイプ得情報はメッセージ内容から判定される。タイプ情報をログに直接的に格納する利点は、コンテンツの何処かのインデックスとしてログを使用できることである。特に、既知の書類の真正を判定する際、一致するハッシュが見つかるまで「書類」エントリが探索され、「エンタングルメント情報」のラベルの付いた次のエントリが発見されるまでそのログがスキャンされるようにできる。
このエントリは最も速いサーバをもたらし、問題の書類の場所へ一気に至るのに使用される。
＜画像／メタデータ記憶手段に格納された情報＞
以下の表２は、SOXサーバの一例で画像／メタデータ格納部に格納される情報例を示す。これらのエントリは表＃１のデータに対応し、ハッシュ値を使うことで特定できる。
上記の表では、「書類」は管理ポイントに必要な視覚的なレコードである。レコードは例えばtiff又はjpgのようなスキャン画像でもよいし、ポストスクリプトやpdfやアスキー電子メールのような電子画像でもよい。「捕捉データ」は書類に関連する情報に関する。これは印刷した、スキャンした又は電子メール送信した装置を含んでもよいし、或いは装置で取得された書類のディジタル署名を含んでもよい。SOXサーバはこの情報を出力として確認装置に与える。
一実施例では、「ワークフローデータ」はメタデータ三要素(ワークフロータイプ、ワークフローインスタンス、管理ポイント)である。
「エンタングルメント情報」は、ログが検査される場所を示す。一実施例では、これは他のロギングサーバのURL、リモートサーバにより確認されるローカルサーバのハッシュの値及びインデックス、そしてエントリを確認するサーバ内のハッシュ及びインデックスを含む。この情報は厳密には必須でないが、確認の速度を極めて速める。
＜エンタングルメントプロトコル＞
SOXサーバは上述したように他のロギング装置とローリングハッシュを交換する。特定のサーバについてのログを確認するために他のいくつかのサーバを見つけることで、確認が実行される。
一実施例では、SOXサーバは特定のサーバとハッシュを交換するように構成され、その特定のサーバの内のいくつかは、法規制を順守するためSOXサーバを使用する企業の管理範囲外にある。ログチェックサムは、その企業と或る業務関係を既に有する各企業のサーバ同士で交換される。これらのサーバは確認を行う時間を容易に発見できる点で有利であり、確認が数年後に望まれる場合にこれらのサーバが近辺にある可能性は、それらの業務の性質に起因して高い。
一実施例では、SOXサーバはデータを実際に捕捉することもできる。例えば、或る管理ポイントが例えばウィキ(Wiki)又はブログ(Blog)に既に格納されてもよい。一実施例では、SOXサーバはRSS又はATOMフィードを用いて、新たな情報が用意されたか否かを確認し、その情報にアクセスし、視覚的なレコードを記録する。例えば、SOXサーバはブログのRSSフィードを要求し、最後の24時間になされた全てのブログにアクセスする。これらのエントリは視覚的な表現に変換され、SOXサーバに格納される。ブログ又はウィキが十分に構造化されていた場合、ワークフローインスタンス及び管理ポイントに関する情報は、追加的なユーザのやりとりなしに確認され、例えばブログのタグが請求書、ワークフロー、購入等のような書類タイプを示し、その内容は(例えば、請求書番号を使うことで)そのワークフローインスタンスに十分に合致していることを示す。
＜書類入力の注釈付け＞
データを捕捉する様々な方法を使って上記の三要素(ワークフロータイプ、ワークフローインスタンス及び管理ポイント)を取得してよい。一実施例では、(たとえ管理ポイントに書類が既に存在していたとしても)如何なる書類も如何なるワークフロー及び管理ポイントに付加可能である。実際にはこの機能は、以前に用意した書類に対する訂正を与える何らかの段階でアクセス可能であるべきである。一実施例では、これはオリジナルのものを置換しないが、以前のデータに加えて利用可能である。
一実施例では、所与のワークフロータイプの下で、SOXサーバはオープンなワークフローインスタンスのリストを用意し、新たなワークフローを開始することを提案する。ユーザはその書類を現在のインスタンスに関連付けてもよいし、新たなものを始めてもよい。SOXサーバが書類タイプ(例えば、梱包リスト)を知っていた場合、何らかのワークフローインスタンスは不適切になるかもしれない(即ち、既に梱包リストを持っているものや、購入依頼を有しないもの)。同様に、SOXサーバがワークフローインスタンスを知っていた場合、自明な次の書類タイプがしばしば存在する。一実施例では、適切な過去のエントリの場合に、これらのユーザ支援は上書きされてもよい。
場合によっては、(スキャナ又はプリンタ装置から)画像が利用可能である。これらの場合に、画像分析が書類を分類するために実行され、おそらくはその内容を判定するのに実行される。例えば、書類が「デル社の請求書」として認識された場合、発注書(PO)がデル社(Dell)に発行されているワークフローが、高い優先度に格付けされてもよい。請求書番号(＃)が認識可能な場合、メタデータ三要素を自動的に判定することが可能かもしれない。おそらくは、その書類がワークフロー(コンピュータが要求され且つデル社がベンダに選択されたワークフロー)に付加されるべきことだけをユーザは確認する。
＜確認法の具体例＞
一実施例では、ワークフローを確認するため、ワークフロー状態及びそのワークフロー中の各項目のハッシュに関するSOXデータベースに格納されている情報と共に、確認ソフトウエアは始める。これらの項目は、SOXサーバ画像格納部からアクセス可能であり、図６の1行として例えば表示されている。一実施例では、確認ソフトウエアは、要求される書類タイプが全ては存在しないことに起因してワークフローが不完全であったことを宣言する。一実施例では、確認ソフトウエアはそのコンテンツ(内容)を知らないので、確認ソフトウエアのユーザは、デル社からの請求書が例えば空白用紙でないことを確認しなければならない。
如何なる書類についても、確認ソフトウエアは、ログファイル中の書類ハッシュのその場所から、「エンタングリング情報」を含む次のエントリへ進行することができる。そしてソフトウエアは、メタデータ格納部からの「証明書」にアクセスし、確認を行うようにいすとされているサーバにアクセスし、SOXサーバのチェックサムがサーバのログに実際に現れているか否かを判定する。これらの全てのチェックサムが合致していたならば、確認ソフトウエアは、特定の日までその書類が存在していたことを、特定の外部サーバのクロックに基づいて示すことができる。
＜コンピュータシステムの具体例＞
図８は上記の動作の1つ以上の実行するコンピュータシステムの一例を示すブロック図である。図８を参照するに、コンピュータシステム800は例示的なクライアント又はサーバコンピュータシステムで構成されてよい。コンピュータシステム800は、情報を通信する通信手段又はバス811、及び情報を処理するためにバス811に結合されたプロセッサ812を有する。プロセッサ812は例えばペンティアム(登録商標)等のようなマイクロプロセッサを含むがこれに限定されない。
システム800は、バス811に結合された、ランダムアクセスメモリ(RAM)又は他のダイナミックストレージデバイス804(メインメモリと言及される)を更に有し、これらのメモリ等はプロセッサ812で実行される命令や情報を格納する。メインメモリ804はプロセッサ812による命令の実行中に変数や他の中間的な情報を一時的に格納する。
コンピュータシステム800は、バス811に結合されたリードオンリメモリ(ROM)及び／又は他のスタティックストレージデバイス806(これらもプロセッサ812のための命令や静的な情報を格納する)と、磁気ディスク、光ディスク及びディスクドライブに関連するようなデータストレージデバイス807とを更に有する。データストレージデバイス807は情報及び命令を格納するためにバス811に結合される。
コンピュータシステム800は、バス811に結合され、コンピュータユーザに情報を表示する陰極線管(CRT)液晶ディスプレイ(LCD)のようなディスプレイ装置821に結合される。情報及びコマンド選択内容をプロセッサ812に通知するため、英数字及び他のキーを含む英数字入力装置822もバス811に結合される。更なるユーザ入力装置はカーソル制御部823(例えば、マウス、トラックボール、トラックパッド、スタイラス又はカーソル指示キー)であり、指示情報及びコマンド選択内容をプロセッサ812に通知したり、ディスプレイ装置821でのカーソルの動きを制御するのに使用される。
バス811に結合される他の装置はハードコピー装置824であり、命令、データ又は他の情報を紙、フィルム又は同様なタイプの媒体に印刷するのに使用される。更に、スピーカ及び／又はマイクロフォン等を備えた音声記録及び再生装置がバス811に選択的に結合され、コンピュータシステム800との音声インターフェースを用意する。バス811に結合されてよい別の装置は、有線の／無線の通信機能部825であり、電話又は携帯用装置と通信する。
システム800及び関連するハードウエアの要素の全部又はどの一部分でもが本発明で使用されてよいことに留意を要する。しかしながら、コンピュータシステムの他のコンフィギュレーションは本装置の全部又は一部を含んでよいことが理解されるであろう。
本発明に関する多くの代替例及び変形例は、上記の説明を理解した当業者にとっては 疑う余地無く明らかである。例示的に図示及び説明された如何なる特定の実施例も、限定的に解釈されるべきでないことが理解されるべきである。従って、様々な実施例の詳細に関連するものは、本発明の範囲を限定するように解釈されるべきでなく、特許請求の範囲は、本発明に本質的であると認められる事項のみを列挙している。
エントリを生成してログの中に格納する様子を示す図である。 メディアのハッシュを生成してログの中に格納する様子を示す図である。 ログのペアを関連付けるプロセスの一例を示すフローチャートである。 エンタングルメント検出を実行するプロセスの一例を示すフローチャートである。 「セールスクレジット管理」のワークフロータイプの一例を示す図である。 購入ワークフローのサンプル書類を示す図である。 SOXサーバ及び関連システムの一例を示すブロック図である。 コンピュータシステムの一例を示すブロック図である。
符号の説明
101 メッセージ及びチェックサムジェネレータ
102 連結モジュール
103，203 ハッシュモジュール
110，210 記録部
700 SOXサーバ
701 書類受信インターフェース
702 画像／メディア格納部
703 記録部
710 ワークフロー識別部
711 OCR部
712 画像分析部
804 メインメモリ
806 スタティックメモリ
807 大容量ストレージメモリ
811 バス
812 プロセッサ
820 外部ネットワークインターフェース
821 ディスプレイ
822 キーボード
823 カーソル制御装置
824 ハードコピー装置

Claims (19)

  1. １つ以上のワークフローに関連する書類の画像を捕捉し、関連するワークフローを表すワークフロー情報を収集して書類にタグを付ける書類受信インターフェースと、
    前記書類受信インターフェースで捕捉された書類の画像及びメタデータを格納し、前記ワークフローに関して実行される確認処理の際にアクセス可能な第１メモリと、
    捕捉された書類の画像に対応する１つ以上のメディア識別子と共にエントリを含むログデータを格納し、前記ワークフローに関して実行される確認処理の際にアクセス可能な第２メモリと、
    前記書類受信インターフェースで捕捉されたワークフローに関する前記書類の画像に対応するログデータを生成し、該ログデータを前記第２メモリに与える第１ユニットと、
    前記ログデータに含まれている１つ以上のエントリが変更されているか否かを判定するために使用されるエンタングルメント情報を前記ログデータに含め、前記ログデータに関する情報をネットワークを介して送受信する第２ユニットと、
    を有し、前記第２ユニットは前記エンタングルメント情報を用いて特定の時点に１つ以上のエントリが前記ログデータ内に存在していたか否かを判定し、前記ログデータ内に存在するエントリが特定の時点に存在していたか否かは、前記ログデータの中にエントリの後に保存されたエンタングルメント情報を用いることで判定され、前記エンタングルメント情報はハッシュ値が確認される場合にクロック値を与えるピアサーバに示され、前記ログデータ内の第１のインデックス及び第１のハッシュ値は前記ピアサーバにより確認可能であり、前記ログデータ内の第２のインデックス及び第２のハッシュ値は前記ログデータ内に存在するエントリを確認する前記ピアサーバにより保存される、サーバシステム。
  2. 前記第１ユニットは、捕捉した書類各々についてメディア識別子を生成し、各メディア識別子を前記第２メモリに与える、請求項１記載のサーバシステム。
  3. 前記メディア識別子は、前記捕捉された書類の画像各々にハッシュ関数を適用することで生成されたハッシュ値を有する、請求項２記載のサーバシステム。
  4. 前記第１ユニットは、前記ハッシュ値をローリングチェックサムと共に前記ログデータに加える、請求項３記載のサーバシステム。
  5. 前記第１ユニットは、ワークフローの前記タグ及び他のサーバからのチェックサムを前記ログデータに加える、請求項４記載のサーバシステム。
  6. 前記ログデータが、ログエントリタイプ、メッセージハッシュ及びローリングハッシュを有するエントリを含む、請求項１記載のサーバシステム。
  7. 前記ログデータが、ピアサーバを表す相互関連情報を含む、請求項１記載のサーバシステム。
  8. 前記第２ユニットが、暗号チェックサム情報をピアサーバと交換する、請求項７記載のサーバシステム。
  9. 前記書類受信インターフェースが、捕捉された前記書類の画像に関連する情報を捕捉する、請求項１記載のサーバシステム。
  10. 前記ワークフロー情報が、ワークフロータイプ、ワークフローインスタンス及び管理ポイントを示す、請求項１記載のサーバシステム。
  11. 各ワークフローが複数の管理ポイントを含み、各管理ポイントは少なくとも１つの画像に関連している、請求項１記載のサーバシステム。
  12. 前記第１ユニットは、前記第２メモリのログデータが格納された時間と、管理ポイントに関連する画像に関連する１つ以上のデータとを生成する、請求項１０記載のサーバシステム。
  13. 前記第１ユニットは、タグの付いた画像を前記第１メモリに与えることで通信をサポートし、規制に合っていることを確認するために前記画像に対するアクセス権を設定する、請求項１記載のサーバシステム。
  14. 複数のワークフローの各々がビジネスプロセスであり、前記複数のワークフローの各々が複数の管理ポイントを有し、前記管理ポイントは監査で検査される項目であり、各管理ポイントは、１つ以上の書類について管理が実行されたことを確認する、請求項１記載のサーバシステム。
  15. 前記第２ユニットは、前記ネットワークを介して少なくとも１つの装置と情報を交換し、ログデータを互いに関わらせる、請求項１記載のサーバシステム。
  16. １つ以上のワークフローの管理ポイントに関連する書類の画像を受信するステップであって、前記ワークフローの各々はビジネスプロセスであり、前記ワークフローの各々は複数の管理ポイントを有し、前記管理ポイントは監査で検査される項目であり、各管理ポイントは、１つ以上の書類について管理が実行されたことを確認する、ステップと、
    ワークフローのワークフロー情報と共に収集した書類にタグを付けるステップと、
    前記ワークフローに関して実行される確認処理の際にアクセス可能な第１メモリに、受信した書類の画像をメタデータと共に格納するステップと、
    第１ユニットにより、受信した画像に対応する１つ以上のメディア識別子と共にエントリを含むログデータを生成し、前記ワークフローに関して実行される確認処理の際にアクセス可能な第２メモリに該ログデータを格納するステップと、
    を有し、前記ログデータを生成する際、第２ユニットにより、前記ログデータに含まれている１つ以上のエントリが変更されているか否かを判定するために使用されるエンタングルメント情報が前記ログデータに含められ、前記ログデータに関する情報はネットワークを介して送受信され、
    前記第２ユニットは前記エンタングルメント情報を用いて特定の時点に１つ以上のエントリが前記ログデータ内に存在していたか否かを判定し、前記ログデータ内に存在するエントリが特定の時点に存在していたか否かは、前記ログデータの中にエントリの後に保存されたエンタングルメント情報を用いることで判定され、前記エンタングルメント情報はハッシュ値が確認される場合にクロック値を与えるピアサーバに示され、前記ログデータ内の第１のインデックス及び第１のハッシュ値は前記ピアサーバにより確認可能であり、前記ログデータ内の第２のインデックス及び第２のハッシュ値は前記ログデータ内に存在するエントリを確認する前記ピアサーバにより保存される、サーバシステムが行う方法。
  17. 前記ログデータを生成する際に、受信した書類にハッシュ関数を適用することで、捕捉した書類各々についてハッシュ値を生成し、ローリングチェックサムと共に前記ログデータに各メディア識別子を含める、請求項１６記載の方法。
  18. 前記ネットワークを介して少なくとも１つの装置と情報を交換し、ログデータを互いに関わらせる、請求項１６記載の方法。
  19. 前記ログデータを生成する際に、前記ログデータのハッシュを１つ以上の他のログデータに関連付け、前記１つ以上の他のログデータに関する情報を前記第２メモリに記録し、前記１つ以上の他のログデータは或るログデータと相互に参照され、前記第２メモリに格納されたログデータの以後の確認を支援する、請求項１６記載の方法。
JP2008084943A 2007-03-28 2008-03-27 書類画像を認証するサーバーシステム及び方法 Active JP5103243B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/692,834 US9081987B2 (en) 2007-03-28 2007-03-28 Document image authenticating server
US11/692,834 2007-03-28

Publications (2)

Publication Number Publication Date
JP2008243209A JP2008243209A (ja) 2008-10-09
JP5103243B2 true JP5103243B2 (ja) 2012-12-19

Family

ID=39730597

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008084943A Active JP5103243B2 (ja) 2007-03-28 2008-03-27 書類画像を認証するサーバーシステム及び方法

Country Status (3)

Country Link
US (1) US9081987B2 (ja)
EP (1) EP1986119A1 (ja)
JP (1) JP5103243B2 (ja)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7953758B2 (en) * 2006-11-10 2011-05-31 Ricoh Company, Ltd. Workflow management method and workflow management apparatus
US20080282090A1 (en) * 2007-05-07 2008-11-13 Jonathan Leybovich Virtual Property System for Globally-Significant Objects
US10102439B2 (en) * 2008-01-14 2018-10-16 Hewlett-Packard Development Company, L.P. Document verification method and system
JP5178293B2 (ja) * 2008-04-15 2013-04-10 キヤノン株式会社 ワークフロー実行装置、ワークフロー実行方法、及びコンピュータプログラム
US11182175B2 (en) * 2008-09-18 2021-11-23 International Business Machines Corporation Apparatus and methods for workflow capture and display
US9026474B2 (en) * 2011-03-07 2015-05-05 Google Inc. Generating printable certificates to verify log authenticity
US20120328148A1 (en) * 2011-06-27 2012-12-27 Grey William Doherty Method and system for secure image management
JP2014035592A (ja) * 2012-08-07 2014-02-24 Fujitsu Ltd 画像キャプチャ装置、画像キャプチャ方法およびプログラム
FR3001313B1 (fr) * 2013-01-22 2016-02-12 Univ Aix Marseille Procede de verification d'au moins une metadonnee d'un bloc de donnees numeriques
JP2015103919A (ja) * 2013-11-22 2015-06-04 キヤノン株式会社 情報処理装置、システム、方法およびプログラム
US11488180B1 (en) * 2014-01-22 2022-11-01 Amazon Technologies, Inc. Incremental business event recording
US10191889B2 (en) * 2014-07-29 2019-01-29 Board Of Regents, The University Of Texas System Systems, apparatuses and methods for generating a user interface by performing computer vision and optical character recognition on a graphical representation
US10146752B2 (en) 2014-12-31 2018-12-04 Quantum Metric, LLC Accurate and efficient recording of user experience, GUI changes and user interaction events on a remote web document
CZ28571U1 (cs) * 2015-05-04 2015-08-31 Jan Bednář Systém pro certifikaci elektronické pošty
IL256893B (en) 2015-07-16 2022-08-01 Quantum Metric Inc File capture using client-server delta encoding
KR101648000B1 (ko) * 2015-11-16 2016-08-12 (주)영신인포텍 스마트 패널을 이용한 캐비닛 보관문서 관리시스템
US20170161754A1 (en) * 2015-12-07 2017-06-08 Hattar Tanin LLC Counter fraud systems
US10642796B2 (en) * 2017-07-18 2020-05-05 International Business Machines Corporation File metadata verification in a distributed file system
US11036677B1 (en) * 2017-12-14 2021-06-15 Pure Storage, Inc. Replicated data integrity
US11683180B1 (en) 2018-05-24 2023-06-20 Swear Inc. Protecting digital media with nested hashing techniques
US10348505B1 (en) 2018-05-24 2019-07-09 DeepTruth, LLC Systems and techniques for validation of media data
US10938568B2 (en) 2018-06-05 2021-03-02 Eight Plus Ventures, LLC Image inventory production
US10289915B1 (en) * 2018-06-05 2019-05-14 Eight Plus Ventures, LLC Manufacture of image inventories
US10296729B1 (en) 2018-08-23 2019-05-21 Eight Plus Ventures, LLC Manufacture of inventories of image products
US10606888B2 (en) 2018-06-05 2020-03-31 Eight Plus Ventures, LLC Image inventory production
GB201811263D0 (en) * 2018-07-10 2018-08-29 Netmaster Solutions Ltd A method and system for managing digital using a blockchain
US10467391B1 (en) 2018-08-23 2019-11-05 Eight Plus Ventures, LLC Manufacture of secure printed image inventories
CN109299763B (zh) * 2018-10-17 2021-11-02 国网江苏省电力有限公司无锡供电分公司 基于rfid密钥链的纸质涉密载体防篡改伪造方法
US10565358B1 (en) 2019-09-16 2020-02-18 Eight Plus Ventures, LLC Image chain of title management
US11829457B1 (en) * 2023-03-31 2023-11-28 Fmr Llc System and method for preventing code exfiltration

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5978475A (en) * 1997-07-18 1999-11-02 Counterpane Internet Security, Inc. Event auditing system
CN1332919A (zh) * 1998-10-30 2002-01-23 塞特科公司 在分布加密中采用共享的随机性
US9311499B2 (en) * 2000-11-13 2016-04-12 Ron M. Redlich Data security system and with territorial, geographic and triggering event protocol
JP2003143139A (ja) 2001-11-07 2003-05-16 Fujitsu Ltd デジタルデータ記憶・検証プログラムおよびデジタルデータ記憶・検証方法
US8005709B2 (en) * 2003-06-17 2011-08-23 Oracle International Corporation Continuous audit process control objectives
JP2005148917A (ja) 2003-11-12 2005-06-09 Ntt Data Itec Corp 文書ワークフローシステム
US8719576B2 (en) * 2003-12-22 2014-05-06 Guardtime IP Holdings, Ltd Document verification with distributed calendar infrastructure
US20050226473A1 (en) * 2004-04-07 2005-10-13 Subramanyan Ramesh Electronic Documents Signing and Compliance Monitoring Invention
US7949666B2 (en) 2004-07-09 2011-05-24 Ricoh, Ltd. Synchronizing distributed work through document logs
WO2006028920A2 (en) 2004-09-01 2006-03-16 Ubmatrix, Inc. Method and system for automatic audit trail
US20090320088A1 (en) 2005-05-23 2009-12-24 Jasvir Singh Gill Access enforcer
EP1806688A1 (en) * 2005-12-05 2007-07-11 Sap Ag Decentralised audit system in collaborative workflow environment
US7505933B1 (en) * 2005-12-22 2009-03-17 Avalion Consulting, Llc System for accelerating Sarbanes-Oxley (SOX) compliance process for management of a company
US7849053B2 (en) * 2005-12-29 2010-12-07 Ricoh Co. Ltd. Coordination and tracking of workflows
US8015194B2 (en) * 2005-12-29 2011-09-06 Ricoh Co., Ltd. Refining based on log content
US8006094B2 (en) * 2007-02-21 2011-08-23 Ricoh Co., Ltd. Trustworthy timestamps and certifiable clocks using logs linked by cryptographic hashes

Also Published As

Publication number Publication date
JP2008243209A (ja) 2008-10-09
US20080243898A1 (en) 2008-10-02
EP1986119A1 (en) 2008-10-29
US9081987B2 (en) 2015-07-14

Similar Documents

Publication Publication Date Title
JP5103243B2 (ja) 書類画像を認証するサーバーシステム及び方法
US20230139312A1 (en) Website Integrity and Date of Existence Verification
JP5053146B2 (ja) 携帯装置、携帯装置が行う方法及びコンピュータプログラム
US8977860B2 (en) Method and apparatus for tamper proof camera logs
JP6959618B2 (ja) 文書情報の真正性検証のためのシステムおよび方法
US8185733B2 (en) Method and apparatus for automatically publishing content based identifiers
US8788830B2 (en) Method and apparatus for logging based identification
US9146953B1 (en) Method and system to audit physical copy data leakage
US8572049B2 (en) Document authentication
JP5030654B2 (ja) ロギングとデータ交換同期のセキュアかつ効率的な方法
US20110173213A1 (en) System and method for data preservation and retrieval
US8996483B2 (en) Method and apparatus for recording associations with logs
US20210073369A1 (en) Tampering detection method and apparatus and non-transitory computer-readable storage medium
US8255340B2 (en) Method and apparatus for risk analysis of published logs
US9223784B2 (en) Method and apparatus for archiving media using a log
US20080243752A1 (en) Method and Apparatus for Process Logging
JP2004046590A (ja) 契約書保管装置、システム及びその方法
JP5063440B2 (ja) 処理装置及び処理方法
WO2020047736A1 (zh) 网站后台图片资源完整性的验证方法和系统
JP2008242994A (ja) 記録管理装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110204

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120313

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120327

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120521

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120612

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120809

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: 20120904

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: 20121001

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151005

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5103243

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150