JP2004526389A

JP2004526389A - 有価ドキュメントを作成および検証する方法およびシステム

Info

Publication number: JP2004526389A
Application number: JP2002589929A
Authority: JP
Inventors: バーリン・レイ・ヘンダーソン; トラビス・ジェイムズ・ジャノビッチ; リアン・ウェイゲン; ジョン・チャールズ・ピープルズ
Original assignee: INTELLIMARK TECHNOLOGIES Inc
Current assignee: INTELLIMARK TECHNOLOGIES Inc
Priority date: 2001-05-17
Filing date: 2002-05-15
Publication date: 2004-08-26
Also published as: AU2002308737A1; EP1402446A2; EP1402446A4; US20020188845A1; US6944770B2; WO2002093316A2; WO2002093316A3

Abstract

有価ドキュメント作成・検証方法およびシステムは、有価ドキュメントに関するリクエストを受け取る発行者モジュールを有する。発行者モジュールは、保証者モジュールにリクエストを送る。このリクエストは、所望するセキュリティレベルおよび／または対象検証者を含んでいてもよい。保証者モジュールは、有価ドキュメントを作成し、有価ドキュメントを暗号化するための１つの暗号鍵を無作為または擬似無作為に選択する。一連の鍵は、対象検証者および／または要求されるセキュリティレベルに基づいて選択された鍵空間であってもよい。保証者モジュールは、選択された暗号鍵を用いて、有価ドキュメントを暗号化し、発行者に送る。発行者は、暗号化された有価ドキュメントを請求者へ送る。請求者がリクエストを権利行使しようとしたとき、請求者は有価ドキュメントを検証者に提示する。検証者は、有価ドキュメントからインデックスを抽出し、インデックスを用いて復号鍵を特定し、この鍵を用いてドキュメントを検証する。

Description

【技術分野】
【０００１】
本発明は、ドキュメントを作成して有効にするための方法およびシステムに関する。とりわけ本発明は、有価（価値を有する）ドキュメントを作成し、検証するための方法およびシステムに関する。
【背景技術】
【０００２】
チケット、入館許可券、ギフト券などの有価ドキュメントは、請求者（requester）に対して発行され、検証者（検証体、validator）により効率的にかつ確実に有効であることを検証されなければならない。例えば、チケット作成・検証システムにおいて、チケット発行者（発行体、issuer）に過大な負担をかけることなく、偽造を防止するメカニズムが必要である。したがって、いくつかのドキュメント作成／検証システムは、チケットに含まれる情報の一部または全部を暗号化する。
【０００３】
既存のドキュメント作成／検証システムにおいて暗号化する際の１つの問題点は、単一の暗号鍵または暗号鍵のペアに基づいて、ドキュメントを暗号化し、検証する点にある。例えば、対称暗号を用いたドキュメント作成／検証システムにおいては、単一鍵を用いて、すべてのドキュメントを暗号化し、検証する。単一鍵が知られると、この単一鍵を用いて暗号化されたすべてのドキュメントを再発行する必要が生じる。例えば、同じ鍵ですべてのチケットを発券する電気式のチケット発券システムにおいて、偽造者がこの鍵を見破ると、新しい鍵を用いてすべてのチケットを再発行する必要がある。その結果、単一鍵によるドキュメント作成／検証システムにおいては、解読される可能性を低減するために、複雑な暗号化アルゴリズムと長い鍵を用いる。暗号化アルゴリズムが複雑になり、暗号鍵が長くなると、暗号化されたドキュメントを作成する当事者およびドキュメント発行者に対する計算上の負担が大きくなる。
【０００４】
単一鍵または鍵ペアを用いて、ドキュメントを検証する上での別の問題点は、特定の発行者（Issuer）の要請に応えるように暗号を変えることができない点にある。例えば、１０ドルのギフト券の発行者は、１０００ドルのギフト券の発行者ほど、暗号鍵を喪失することについて心配しないかもしれない。しかし、単一鍵を用いているので、両方の場合において、同じ暗号レベルを適用しなければならない。すなわち、従来式のドキュメント作成／検証システムによれば、個々の発行者の要請に応えるような柔軟性が欠如している。
【０００５】
したがって、有価ドキュメントを作成し、検証するための改良された方法およびシステムに対して、長く待望されている。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、有価ドキュメントを作成し、検証するための方法およびシステムを含む。ここで用いられるように、有価ドキュメントとは、所持者または所有者に金銭的または他の価値を与える印刷形態または電子形態の情報、あるいは認証または秘匿を要する任意の他の情報を意味する。有価ドキュメントの具体例として、チケット、入場許可証、ギフト券、ギフトカード、遺言、法的証書、権利書、処方箋、医療記録、クーポン、商品引換券、トラベラーズチェック、貨幣、および電信送金を含む金融証書、入場許可証、パスポート、および他のＩＤ（同定）証、市民証、投票登録カード、政府発行の免許証および許可証、ＣＰＡドキュメント、機密扱い社内文書、機密扱い政府文書、投票用紙、有価証券などのドキュメント、公証を要する謄本や文書などの他の政府文書、くじ券、郵便受領確認書、小荷物追跡所、予約確認書、在庫確認書が挙げられる。
【０００７】
１つの態様によれば、本発明は、有価ドキュメントを作成し、検証するためのシステムを含む。このシステムは、保証者（保証体、guarantor）モジュール、発行者モジュール、および検証者モジュールを備える。各モジュールは、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組み合わせで実施してもよい。保証者モジュールは、有価ドキュメントを暗号化するために用いられる一連の暗号鍵を有する。また保証者モジュールは、鍵に対応する一連のインデックスを形成する。一連の鍵およびインデックスは、検証者モジュールに送信され、有価ドキュメントを検証する際に用いられる。発行者モジュールは、有価ドキュメントに関するリクエストを受け取る。発行者モジュールは、有効開始日と有効終了日を含む有価ドキュメントを作成する。発行者モジュールは、ドキュメントを保証者モジュールに所望する暗号レベルを指定しながら送付する。保証者モジュールは、各リクエストに関して、選択され鍵空間から１つの鍵を無作為または擬似的無作為に選択する。保証者モジュールは、無作為または擬似的無作為に選択された暗号鍵を用いて、各有価ドキュメントを暗号化する。その後、有価ドキュメントを発行者に送信する。発行者は、有価ドキュメントを請求者に送る。請求者は、インデックスを含む有価ドキュメントを検証モジュールに提示する。検証者モジュールは、インデックスに基づいてドキュメントを復号化するために用いる鍵を特定する。そして検証者モジュールは、この鍵を用いて、ドキュメントを検証する。
【０００８】
保証者は、各ドキュメントに対して、無作為または擬似的無作為に選択するので、１つの鍵が解読されても、少量のドキュメントが解読されるに過ぎない。例えば、チケット作成・検証システムにおいて、保証者が２０００個の鍵を用いて、２０００座席のアリーナの２０００枚のチケットに関する内容または座席情報を暗号化することができる。保証者が１つの鍵を選択するとき、各鍵が選択される確率は１／２０００である。１つの鍵が見破られた場合、他のチケットが解読またはコピーされる確率は１／２０００しかない。
【０００９】
別の態様によれば、本発明は、保証者から発行者へ、請求者から検証者へ送達される独特のメッセージを有し、このメッセージは、暗号化された有価ドキュメントと、これを復号化し、検証するために用いられる情報とを含む。このメッセージ内の１つの独特のフィールドは、復号鍵および／または有価ドキュメントを復号化するために用いるスキームを検証者が特定するために用いられるインデックスを記憶する暗号スキームインデックスフィールドである。鍵および／または暗号スキームを選択するために用いられる本発明のインデックスにより、有価ドキュメントの作成システムの柔軟性を増大させる。例えば、異なる長さの鍵、または異なる鍵または暗号スキームに対応する異なる暗号スキームおよびインデックスを用いることに、保証者および検証者が同意することができる。すると、保証者は、請求された有価ドキュメントの特性に応じた鍵長さおよび／または暗号スキームを動的に選択することができる。
【００１０】
暗号システムの頑健さは暗号鍵の長さに依存するので、高いセキュリティが望まれる場合には鍵の長さを長くし、低いセキュリティが所望される場合には鍵の長さを短くする。例えば、１０ドルのギフト券の価値情報を暗号化するときにはｎビットの鍵を選択し、１００ドルのギフト券を暗号化するときには（ｎ＋ｘ）ビットの鍵を用いる。保証者、発行者、および検証者の間で有価ドキュメントを通信する際に用いられる独特のメッセージにより、暗号レベルおよびスキームを自在に選択することができる。
【００１１】
したがって、本発明の目的は、複数ドキュメント作成システムにおいて、各ドキュメントを暗号化するために、無作為または擬似的無作為に鍵を選択するドキュメント検証方法およびシステムを提供することにある。
【００１２】
本発明の別の目的は、請求者、保証者、検証者、および発行者の間で有価ドキュメントを通信するのに適したメッセージフォーマットを提供することにある。
【００１３】
本発明のいくつかの目的については以下において説明されるが、他の目的が添付図面と関連する最良の形態の説明から明らかとなる。
【発明を実施するための最良の形態】
【００１４】
添付図面を参照しながら、本発明の好適な実施形態について以下説明する。図面を参照すると、同様の構成部品に対して、同様の参照符号が用いられ、本発明は、適当なコンピュータ環境において実施される。必要ではないが、パーソナルコンピュータにより実行されるプログラムモジュールなどのコンピュータにより実行可能な指令の一般的文脈において、本発明を説明する。プログラムモジュールは、一般に、特定の処理を実行し、特定の抽象的なデータ種別を実行するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに当業者ならば理解されるように、本発明は、携帯装置、マルチプロセッサシステム、マイクロプロセッサを用いた、またはプログラム可能な家電製品、ネットワークパーソナルコンピュータ、ミニコンピュータ、メインフレームコンピュータなどを含む他の構成のコンピュータシステムと共に実施することができる。また、本発明をコンピュータ環境に配信してもよく、このとき通信ネットワークを介して接続されて遠隔処理を行う装置により処理が実行される。配信されたコンピュータ環境においては、局在的な、または遠隔地のメモリストレージ装置にプログラムモジュールを格納してもよい。
【００１５】
図１を参照すると、本発明を実行する具体例のシステムは、従来式のパーソナルコンピュータ２０の形態を有する汎用コンピュータ装置であって、このコンピュータ装置は、演算ユニット２１、システムメモリ２２、およびシステムバス２３を有し、システムバスは、システムメモリを含むさまざまなシステム構成部品と演算ユニット２１とを接続する。システムバス２３は、メモリバスまたはメモリコントローラ、周辺バス、さまざまな任意のバスアーキテクチャを用いるローカルバスを含むいくつかの任意の形態のバス構造体を有していてもよい。システムメモリは、読出専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を有する。スタートアップ時など、パーソナルコンピュータ内の構成部品の間における情報の転送を支援する基本ルーチンを含む基本入出力デバイス（ＢＩＯＳ）２６が、ＲＯＭ２４内に格納される。パーソナルコンピュータ２０は、さらに、ハードディスクに読み書きするためのハードディスクドライブ２７と、着脱可能な磁気ディスク２９に読み書きするための磁気ディスクドライブ２８と、ＣＤ−ＲＯＭまたは他の光学式媒体などの着脱可能な光ディスク３１に読み書きするための光ディスクドライブ３０とを有する。
【００１６】
ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれハードディスクドライブインターフェイス３２、磁気ディスクドライブインターフェイス３３、および光ディスクドライブインターフェイス３４を介して、システムバス２３に接続される。これらのドライブと、関連するコンピュータにより読取可能な媒体とにより、コンピュータにより読取可能な指令、データ構造体、プログラムモジュール、およびパーソナルコンピュータ２０の他のデータに関して不揮発性の記憶が得られる。ここで開示された具体例の環境においては、ハードディスク、着脱可能な磁気ディスク２９、および着脱可能な光ディスク３１を用いたが、当業者ならば理解されるように、コンピュータによりアクセス可能なデータを記憶できるコンピュータにより読取可能な他の形態の媒体、例えば、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌイカートリッジ、ランダムアクセスメモリ、読出専用メモリなどの媒体も同様に、この具体例の環境において利用することができる。
【００１７】
オペレーティングシステム３５、１つまたはそれ以上のアプリケーションプログラム３６、他のプログラムモジュール３７、およびプログラムデータ３８を含む、数多くのプログラムモジュールを、ハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４、またはＲＡＭ２５に格納することができる。本発明の実施形態に特に関連のあるアプリケーションプログラムは、検証者モジュール３６Ａ、保証者モジュール３６Ｂ、および発行者モジュール３６Ｃを有する。図示された実施形態によれば、モジュール３６Ａ〜３６Ｃは、ＲＡＭ２５内に格納されるように図示されている。これらのモジュールは、ハードディスクなどの長期記録媒体に同様に格納されることが理解されよう。検証者モジュール３６Ａは、請求者から受領した有価ドキュメントを検証する。発行者モジュール３６Ｃは、有価ドキュメントを請求者に発行する。保証者モジュール３６Ｂは、有価ドキュメントを安全に送達するために暗号化する。モジュール３６Ａ〜３６Ｃについて、より詳細に以下説明する。
【００１８】
ユーザは、キーボード４０および指示デバイス４２などの入力デバイスを介して、命令および情報をパーソナルコンピュータ２０に入力する。例えば、ユーザは、キーボード４０および指示デバイス４２を用いて、有価ドキュメントに対するリクエストを入力することができる。他の入力装置として、（図示しないが）マイクロフォン、タッチパネル、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどが挙げられる。これらの装置および他の装置は、しばしばシステムバスに接続されるシリアルポートインターフェイス４６を介して演算ユニット２１と接続されるが、パラレルポート、ゲームポート、または汎用シリアルバス（ＵＳＢ）などの他のインターフェイスを介して接続してもよい。モニタ４７または他の種類の表示装置も同様に、ビデオアダプタ４８などのインターフェイスを介してシステムバス２３に接続される。モニタに加えて、パーソナルコンピュータは、通常、図示しないスピーカおよびプリンタなどの周辺出力装置を有する。本発明に関し、ユーザは、モニタ４７を見ながら、１つの入力装置を用いて、ユーザに提示された選択肢の中からユーザの希望を示すデータを入力する。
【００１９】
パーソナルコンピュータ２０は、遠隔コンピュータ４９などの１つまたそれ以上の遠隔コンピュータに対する論理接続を用いてネットワーク化された環境において動作する。遠隔コンピュータ４９は、別のパーソナルコンピュータ、ルータ、ネットワークパーソナルコンピュータ、ピアデバイス、または他の共通ネットワークノードであってもよく、図１ではメモリストレージデバイス５０しか図示されていないが、遠隔コンピュータ４９は、通常、パーソナルコンピュータに関連して上述した多くの、またはすべての構成部品を有している。図示した具体例において、遠隔コンピュータ４９は、同様に、有価ドキュメントを作成し、検証するためのモジュール３６Ａ〜３６Ｃを有する。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１、広域エリアネットワーク（ＷＡＮ）５２、およびシステムエリアネットワーク（ＳＡＮ）５３を含む。ローカルエリアネットワークおよび広域エリアネットワークの環境は、企業内ネットワーク、イントラネット、およびインターネットとして、オフィスにおいて一般的である。
【００２０】
システムエリアネットワーク環境を用いて、クラスタリングなどの配信コンピュータシステム内のノードを内部接続する。例えば、図示された実施形態において、パーソナルコンピュータ２０はクラスタリング内の第１ノードを構成し、遠隔コンピュータ４９はクラスタリング内の第２ノードを構成してもよい。こうした環境において、好適には、パーソナルコンピュータ２０および遠隔コンピュータ４９を共通の管理ドメイン下に置く。すなわち、コンピュータ４９は「遠隔」と識別されるものの、パーソナルコンピュータ２０と物理的に近接させることができる。
【００２１】
ＬＡＮまたはＳＡＮのネットワーク環境で利用される場合、パーソナルコンピュータ２０は、ネットワークインターフェイスアダプタ５４，５４Ａを介して、ローカルエリアネットワーク５１またはシステムエリアネットワーク５３に接続される。ネットワークインターフェイスアダプタ５４，５４Ａは、演算ユニット５５，５５Ａ、および１つまたはそれ以上のメモリユニット５６，５６Ａを有していてもよい。ＷＡＮのネットワーク環境で利用される場合、パーソナルコンピュータ２０は、通常、モデムまたはＷＡＮ上での通信を可能にする他の手段を有する。モデム５８は、内蔵式または外付式であってもよいが、シリアルポートインターフェイス４６を介して、システムバス２３に接続される。ネットワーク環境において、パーソナルコンピュータ２０に対して描写されるプログラムモジュールまたはその一部を、遠隔メモリストレージ装置に記録してもよい。図示されたネットワーク接続は一例を示すものであって、他の手段が用いて、コンピュータ間の通信リンクを実現できると理解される。
【００２２】
以下の記載において、特に言及しない場合、１つまたそれ以上のコンピュータが実行する所作および動作に関する象徴的な表現を引用しながら、本発明を説明する。したがって、所作および動作は、ときどきコンピュータにより実行されるものとして説明されるが、構造形態においてデータを表現する電気信号に関する、コンピュータの演算ユニットおよび／または入出力装置の演算ユニットによる処理を含むものと理解される。この処理により、データが変換され、データがコンピュータおよび／または入出力装置のメモリシステム内の所定位置に維持され、その結果、コンピュータおよび／または入出力装置の動作が当業者に広く知られているように再構成または変更される。データが維持される場所である構造体とは、データフォーマットにより定義される特定のプロパティを有するメモリの物理的な記憶位置である。ただし、上記文脈において本発明を説明するとき、当業者ならば理解されるように、以下に説明する所作および動作がハードウェア内において実施可能であると限定する意図はない。
【００２３】
図２は、本発明の実施形態による有価ドキュメントの作成・検証方法およびシステムを図示するメッセージフロー図である。図２における通信エンティティは、図１で上述したように、検証者モジュール３６Ａ、保証者モジュール３６Ｂ、および発行者モジュール３６Ｃを含む。さらに、請求者２００は、発行者モジュール３６Ｃと情報交換して有価ドキュメントを入手し、検証者モジュール３６Ａと情報交換して有価ドキュメントを検証させる。請求者２００は、コンピュータであってもよいし、あるいはコンピュータを用いてモジュール３６Ａ〜３６Ｃにアクセス可能なエンドユーザであってもよい。モジュール３６Ａ〜３６Ｃは、同一のコンピュータ上に配置してもよいし、あるいはローカルエリアネットワークまたは広域エリアネットワークを介して接続された異なるコンピュータ上に配置してもよい。
【００２４】
ステップ１において、請求者２００は、発行者モジュール３６Ｃからの有価ドキュメントをリクエスト（請求）する。請求者２００は、発行者モジュール３６Ｃが配置されるコンピュータにアクセスする場合、単純に、グラフィカルユーザインターフェイスまたはコマンドラインインターフェイスなどのローカルユーザインターフェイスにアクセスしてもよい。請求者２００が発行者モジュール３６Ｃから離れたところにある場合、請求者２００は、マイクロソフト社のINTERNET EXPLORER（登録商標）またはネットスケープ社のNAVIGATOR（登録商標）などのウェブブラウザを用いて発行者モジュール３６Ｃにアクセスすることができる。本発明は、リクエストを送信する任意の特定装置の如何に限定されない。例えば、パーソナルコンピュータ、携帯コンピュータ、携帯電話、陸上通信線、または無線アクセスプロトコル（ＷＡＰ）電話などの電話、または請求者から情報を受信し、発行者モジュール３６Ｃへ情報を送信できる他の任意の装置を用いて、このリクエストを送信してもよい。請求者２００は、同様に、コンピュータプログラムであってもよい。
【００２５】
有価ドキュメントに対するリクエストを受け取ると、ステップ２において、発行者モジュール３６Ｃは、有価ドキュメントを作成するとともに、有価ドキュメントを暗号化するためにリクエストを保証者モジュール３６Ｂに送信する。発行者モジュール３６Ｃからのリクエストは、請求者２００から受信した情報、価値情報、および有価ドキュメントを検証するために必要な他の情報を含んでいてもよい。例えば、この有価ドキュメントがギフト券である場合、価値情報が必要であり、必ずしも請求者を特定する必要はない。入館許可証である場合、請求者とその住所を特定する必要がある。同様に、リクエストは、例えば、すなわち請求されたドキュメントの価値に基づいて必要とされるセキュリティレベルを有していてもよい。発行者モジュール３６Ｃを用いてドキュメントに応じてセキュリティレベルを要求できるので、従来式のドキュメント検証システムに比して、本発明によるドキュメント検証方法およびシステムのフレキシビリティを大幅に増大させることができる。請求者からのリクエストは、暗号化された有価ドキュメントを検証するために、対象検証者にも通達される。好適には、セキュリティソケットレイヤ（ＳＳＬ）などの安全通信チャンネルを介して、保証者モジュール３６Ｂにリクエストを通信する。
【００２６】
発行者モジュール３６Ｃは、請求者のクレジットカード情報を入手し、処理することにより、ドキュメントに対する費用を請求者に課金してもよい。請求者のクレジットカードに課金するための任意のセキュリティ手法を用いて、請求者２００から費用を得てもよい。例えば、安全電子決済手続（ＳＥＴ：Secure electronic transaction）を用いて、請求者に課金して、クレジットカード発行者から支払いを受けてもよい。
【００２７】
ステップ３において、保証者モジュール３６Ｂは、発行者モジュール３６Ｃからリクエストを受信し、暗号化された有価ドキュメントを含むメッセージを形成する。暗号化された有価ドキュメントに加えて、このメッセージは、好適には、有価ドキュメントを解読する方法を対象検証者に示唆するためのインデックスを含む。このメッセージの構成は、以下においてより詳細に説明する。
【００２８】
図３は、保証者モジュール３６Ｂが暗号化された有価ドキュメントを含むメッセージを形成するときに実施するステップの一例を図示する。本発明の重要な態様によれば、チケット作成／検証システムなどのような複数の価値を保有するドキュメントに関する有価ドキュメントシステムにおいて、保証者モジュール３６Ｂは、ステップＳＴ１において、このシステムが各有価ドキュメントを暗号化するために要する所定の一連の鍵から１つの鍵を選択する。本発明の好適な実施形態において、保証者モジュール３６Ｂは、汎用鍵空間と同様、各検証者に関する鍵空間を維持管理する。各検証者のための鍵空間を、ドキュメント発行者が要求するセキュリティレベルに応じて部分空間に分割してもよい。例えば、ドキュメント発行者は、検証される特定のドキュメントが有する価値または特性に依存して、暗号化なし、低い程度の暗号化、中程度の暗号化、高い程度の暗号化に関するセキュリティレベルを要求してもよい。保証者モジュール３６Ｂにおける各鍵空間は、要求されたセキュリティレベルに相当する長さを有する鍵を含む。発行者モジュール３６Ｃは、保証者モジュール３６Ｂに送信されたリクエストの中に、要求された暗号化レベルを含んでいてもよい。発行者モジュール３６Ｃおよび保証者モジュール３６Ｂは、特定の発行者に対する対象検証者を特定してもよい。その後、保証者モジュール３６Ｂは、この検証者に対する鍵空間を設定してもよい。次に、保証者モジュール３６Ｂは、特定の検証者に対して、鍵空間内の部分空間を設定してもよい。最終的に、鍵空間が選択されると、保証者モジュール３６Ｂは、鍵空間内において、無作為または擬似的無作為な選択を実行してもよい。複数のドキュメントシステムにおいて各ドキュメントに対して、暗号スキームまたは鍵を無作為または擬似的無作為に選択することにより、追加的な計算上の負担を保証者モジュール３６Ｂおよび検証者モジュール３６Ａにかけることなく、システムのセキュリティを大きく改善することができる。例えば、ｎ個の鍵を含む鍵空間において、１つの鍵が見破られた場合、ドキュメントを解読するのに有効である確率は１／ｎに過ぎない。単一の鍵または鍵ペアに基づく従来式の有価ドキュメント配信システムによれば、単一鍵が見破られると、この鍵に基づいて暗号化されたすべてのドキュメントの信用が失墜するため、複雑な暗号を用いる必要があった。これとは異なり、本発明の実施形態による有価ドキュメント作成・検証方法およびシステムによれば、１つの鍵を失った場合でもシステムに与える影響が小さいので、より簡便な暗号化アルゴリズム、またはより短い鍵を用いることができる。その結果、計算上の複雑さは低減される。
【００２９】
各検証者に対して異なる鍵空間を維持することにより、同様に、セキュリティを改善することができる。例えば、ある検証者に対する鍵空間が見破られた場合でも、他の検証者に対する鍵空間は影響を受けない。各検証者に対して、鍵空間内の異なる部分空間を維持することにより、セキュリティとフレキシビリティの両方を改善することができる。セキュリティに関しては、１つの部分空間が見破られても、他の部分空間は影響を受けない。フレキシビリティに関しては、発行者は、部分空間を用いて、形成・検証されるドキュメントの価値および本質に対応する暗号レベルを選択することができる。
【００３０】
鍵が選択されると、ステップＳＴ２において、保証者モジュール２６Ｂは、選択された鍵を用いて、有価ドキュメントを暗号化する。ドキュメントを暗号化するために、任意の適当な暗号化アルゴリズムを用いてもよい。例えば、データ暗号標準（ＤＥＳ：data encryption standard）などの暗号アルゴリズムを用いてもよい。択一的には、リベスト・シャミル・エーデルマン（ＲＳＡ：Rivest, Shamir, Adelman）方式などの非対称暗号化アルゴリズムを用いてもよい。
【００３１】
ドキュメントの完全性を保証するために、ステップＳＴ３において、保証者モジュール３６Ｂは、好適には、暗号化された有価ドキュメントを発行者モジュール３６Ｃに送る前に、暗号化された有価ドキュメントのハッシュ値またはメッセージダイジェストを計算する。任意の適当なハッシュアルゴリズムを用いてもよい。本発明の好適な実施形態において、ＭＤ５ハッシュアルゴリズムを用いて、暗号化された有価ドキュメントのハッシュ値を計算する。メッセージのハッシュ値をメッセージに添付して送信することは安全ではないので、ステップＳＴ４において、保証者モジュール３６Ｂは、好適には、発行者モジュール３６Ｃにメッセージを送信する前に、ハッシュ値を暗号化する。ハッシュ値付きメッセージは、保証者モジュールの秘密鍵を用いて、暗号化またはデジタル式に署名される。検証者モジュール３６Ａなどの他のエンティティは、認証後、認証局（certificate authority）から保証者の公開鍵を入手して、保証者の署名を検証する。
【００３２】
メッセージダイジェストが計算され、暗号化されると、ステップＳＴ５において、保証者モジュール３６Ｂは、このメッセージダイジェストを暗号化された有価ドキュメントに数珠繋ぎにする。暗号化された有価ドキュメントと暗号化されたメッセージダイジェストを以下、ペイロードと呼ぶ。ペイロードが形成されると、ステッＳＴ６において、保証者モジュール３６Ｂは、オプションフィールドを形成し、ペイロードに添付する。オプションフィールドを用いて、保証者モジュール３６Ｂは、任意の所望する情報を搬送することができる。
【００３３】
オプションフィールドが形成され、埋めると（または空欄のままにしておくと）、ステップＳＴ７において、保証者モジュール３６Ｂは、暗号スキームインデックスをメッセージに添付する。暗号スキームインデックスにより、検証者モジュール３６Ａは、特定の暗号スキームおよび／またはメッセージを暗号化した際の鍵が通知される。例えば、保証者モジュール３６Ｂおよび検証者モジュール３６Ａのそれぞれは、暗号スキームインデックス、および対応する鍵と暗号スキームに関するデータベースを維持管理してもよい。表１は、保証者のためのこうしたデーベースのフォーマットの一例を図示し、表２は、検証者のためのこうしたデーベースのフォーマットの一例を図示する。
【表１】

【表２】

【００３４】
有価ドキュメントを暗号化する前に、保証者モジュール３６Ｂと検証者モジュール３６Ａの間において、表１に示す暗号スキームインデックスおよび対応する鍵をオフラインで交換してもよい。暗号鍵は、サン・マイクロシステムズから市販されているJAVA Development Kit （登録商標）の鍵ツールなどの任意の標準的鍵生成ツールを用いて生成してもよい。
【００３５】
暗号スキームインデックスがメッセージに追加されると、ステップＳＴ８において、保証者モジュール３６Ｂは、長さフィールドをメッセージに追加する。長さフィールドは、暗号化されたメッセージの長さを示唆する。検証者モジュール３６Ａは、この値を用いて、メッセージを復号化し、解釈する。図４は、本発明の実施形態による暗号化された有価ドキュメントを発行者モジュール３６Ｃに供給するために、作成者モジュール３６Ｂが作成し、利用する動的取引プロトコルメッセージの一例を示す。図示された実施形態において、動的取引プロトコルメッセージ３００は、メッセージの長さを記憶する長さフィールド３０２と、メッセージを復号化するとき、どの鍵、鍵のペア、および／または暗号スキームを用いるべきかを示すのに用いられるインデックス値を記録するための暗号スキームインデックスフィールド３０４と、将来の使用に際して確保されるオプションフィールド３０６と、暗号化された有価ドキュメントを記憶するための暗号化ドキュメントフィールド３０８と、メッセージの暗号化されたダイジェストを記録するためのメッセージダイジェストフィールド３１０と、を有する。保管者モジュール３６Ｂが動的取引プロトコルメッセージ３００を形成すると、保管者モジュール３６Ｂは、メッセージをアスキー（ASCII）フォーマットに変換してもよい。有価ドキュメントを印刷形態で請求者に送付する場合、アスキーフォーマットへの変換が必要となる。同様に、有価ドキュメントをバーコードの形態で請求者に送付する場合、アスキーフォーマットへの変換が必要となる。例えば、保証者モジュール３６Ｂまたは発行者モジュール３６Ｃにより、メッセージをＰＤＦ４１７フォーマットなどのバーコードフォーマットに変換してもよい。メッセージをバーコードフォーマットに変換することにより、検証者モジュール３６Ａによる検証を促進することができる。例えば、メッセージが暗号化されたチケットを含む場合、検証者モジュール３６Ａは、バーコードリーダと接続してもよく、バーコードリーダは、暗号化されたドキュメントを読み取り、検証者モジュール３６Ａは、検証できるように、コード化された情報を受信する。
【００３６】
図２に戻ると、発行者モジュールが暗号化された有価ドキュメントを含むメッセージを受信すると、ステップ４において、発行者モジュール３６Ｃは、メッセージを請求者２００に送達する。請求者２００へのメッセージ送達は、例えば、コンピュータネットワークを介した電子形態または宅配便による紙形態など、任意の適当な手段で行うことができる。ステップ５において、請求者２００は、検証者モジュール３６Ａに検証させるために。メッセージを提示する。ステップ６において、検証者モジュール３６Ａは、メッセージを検証する。
【００３７】
図５Ａおよび図５Ｂは、メッセージを検証する際、検証者モジュール３６Ａにより実施されるステップの一例を示すフローチャートである。図５Ａを参照すると、ステップＳＴ１において、検証者モジュール３６Ａは、受信したメッセージをバイナリフォーマットに変換する。メッセージが検証者モジュール３６Ａに対してアスキーフォーマットなどの非バイナリフォーマットで提示された場合に、このステップは必要となる。メッセージがバイナリフォーマットで提示された場合には、ステップＳＴ１は省略してもよい。ステップＳＴ２において、検証者モジュール３６Ａは、受信したメッセージからデータ長の値を抽出する。データ長の値は、後に利用できるように記録しておいてもよい。ステップＳＴ３において、検証者モジュール３６Ａは、メッセージから暗号スキームインデックスを抽出する。暗号スキームインデックスは、暗号鍵データベースから暗号鍵を抽出する際、後に利用できるように記録しておいてもよい。ステップＳＴ４において、検証者モジュール３６Ａは、受信したメッセージからオプション値を抽出する。オプション値は、検証者モジュール３６Ａと保証者モジュール３６Ｂの間における合意に基づいた任意の用途に利用することができる。ステップＳＴ５において、検証者モジュール３６Ａは、抽出されたデータ長の値を用いて、受信したメッセージから暗号化されたドキュメントを抽出する。ステップＳＴ６において、検証者モジュール３６Ａは、ステップＳＴ７で受信されたメッセージから抽出された暗号スキームインデックスに対応する暗号鍵を入手する。
【００３８】
図５Ｂを参照すると、ステップＳＴ８において、検証者モジュール３６Ａは、受信メッセージから暗号化されたメッセージダイジェストを抽出する。ステップＳＴ９において、検証者モジュール３６Ａは、受信メッセージから抽出された暗号化ドキュメントのメッセージダイジェストを計算する。ステップＳＴ１０において、検証者モジュール３６Ａは、保証者の公開鍵を用いて、受信メッセージから抽出されたメッセージダイジェストを復号化する。ステップＳＴ１１およびＳＴ１２において、検証者モジュール３６Ａは、計算されたメッセージダイジェストを受信されたメッセージダイジェストと比較する。両方のメッセージダイジェストが一致した場合、ステップＳＴ１３において、検証者モジュール３６Ａは、ステップＳＴ１４に進み、ここでデータベースから抽出された鍵を用いて、メッセージが復号化される。
【００３９】
ステップＳＴ１５において、検証者モジュール３６Ａは、ドキュメントの内容を検証する。ドキュメントの内容を検証する際に行われるステップは、検証されるドキュメントの種別に依存する。例えば、ドキュメントがチケットである場合、ドキュメントが復号化されると、セクション番号、席列番号、およびイベントコードがドキュメントから読み出される。これらの内容がチェックされ、特定のセクション番号、席列番号、およびイベントコードがその開催地において実際に存在するかどうか、先に検証されたチケットが重複しないかどうか確認される。別の検証例として、ドキュメントが商品券またはギフト券である場合、検証プロセスは、偽造をチェックするために、商品券を一意的に特定する価値情報およびコードを読み取るステップを含む。ステップＳＴ１６において、検証結果は返信される。
【００４０】
ドキュメント検証プロセスは、ドキュメントが有効開始日と有効終了日の間にあるかどうか認証するステップを含んでいてもよい。例えば、発行モジュール３６Ｃが有価ドキュメントを発行するとき、発行モジュール３６Ｃは、ドキュメントが有効となる期間を設定する有効開始日および有効終了日を盛り込んでもよい。保証者モジュール３６Ｂは、暗号化された有価ドキュメントの中に、この情報を含めてもよい。メッセージの暗号化された部分に開始日と終了日を記憶させることは、セキュリティの理由から好ましい。さもなければ、ドキュメントの所有者は、有効期限を変更することができ、ドキュメントが有効である間に期間を延長することができる。検証者モジュール３６Ａは、有価ドキュメントを復号化する時、現時点の日付が有効な開始日と終了日の間にあることを確認する。現時点の日付が有効な開始日と終了日の間にある場合、検証者モジュール３６Ａは、上述のように、残りのフィールドを検証する手続を行う。現時点の日付が有効な開始日と終了日の間にない場合、検証者モジュール３６Ａは、ドキュメントを拒絶してもよい。
【００４１】
図２に戻って、検証が完了すると、ステップＳＴ６において、検証者モジュール３６Ａは、ドキュメントが検証されたかどうか、請求者２００に通知する。請求者が検証場所に物理的に存在する場合、検証結果を請求者にコンピュータ画面上で表示してもよい。請求者が検証場所に存在しない場合、検証結果をネットワークパケットに要約して、コンピュータネットワークを介して請求者に送信してもよい。
【００４２】
本発明は、検証者モジュール３６Ａが実行するすべての検証ステップを行うことに限定されない。例えば、本発明の択一的な実施形態において、保証者モジュールが検証を行ってもよい。図６は、図２と同様のメッセージフロー図であって、検証ステップは、検証者モジュール３６Ａではなくて、保証者モジュール３６Ｂにより実施される。図６における通信エンティティは、図２で上述したものと同様である。したがって、これらに関する説明を反復しない。同様に、発行モジュール３６Ｃおよび保証者モジュール３６Ｂの間、請求者２００および検証者モジュール３６Ａの間で情報交換されるメッセージは、図２で説明したものと同様である。図６のフロー図で追加されたメッセージはステップ６および７であって、検証者モジュール３６Ａが保証者モジュール３６Ｂに検証を要求し、受信する。保証者モジュール３６Ｂは、図５で説明した検証ステップを行う。すなわち、図６は、検証者モジュール３６Ａではなく、保証者モジュール３６Ｂがドキュメント検証を行う本発明の実施形態を図示する。
【００４３】
検証者モジュール３６Ａは、１つの場所で提示されるドキュメントを検証するために、請求者と直接的に情報交換する独立型ユニットであってもよい。択一的には、検証者モジュール３６Ａは、さまざまな異なる場所で提示されるドキュメントを検証するように構成された管理集中型ユニットであってもよい。いずれにせよ、検証者モジュール３６Ａは、単一のイベントまたは目的、あるいは複数の異なるイベントまたは目的に関するドキュメントを検証することができる。図７は、本発明の実施形態による独立型検証者モジュールの一例を示す。図７において、独立型検証者モジュール３６Ａは、請求者２００と直接、情報交換して、１つの場所で提示されるドキュメントを検証する。例えば、検証者モジュール３６Ａは、チケット保持者がイベント開催地内に入る際にチケットを検証するための、イベント開催地に配置されたチケット検証者であってもよい。
【００４４】
図８は、本発明の実施形態による管理集中型の検証者を図示する。図８において、検証者モジュール３６Ａは、複数の場所において、複数のイベント／目的のための提示されるドキュメントを検証することができる汎用検証者を有する。検証クライエント８００は、請求者２００から検証リクエストを受け、管理集中型の検証者モジュール３６Ａからの検証を要請する。クライエント８００は、異なるイベント開催地または１つのイベント開催地の異なる入口に設置されたコンピュータまたは任意の他の同様の装置であってもよい。検証クライエント８００は、安全な通信リンク８０２を介して、検証者モジュール３６Ａと接続することができる。安全通信リンクは、ＳＳＬ接続などの任意の適当な通信リンクであってもよい。検証者モジュール３６Ａは、１つの検証クライエントに対して上述したのと同様に、複数のクライエント８００からの検証リクエストを受信し、処理する。したがって、本発明は、有価ドキュメントを検証するための独立型および管理集中型の検証者モジュールを含む。
【００４５】
有価ドキュメント作成・検証方法およびシステムは、作成および検証される有価ドキュメントの種別に応じて、変形または変更することができる。以下に示す表３は、本発明のシステムの変更例を含む。表３において、第１列は、保証者モジュール３６Ｂと検証者モジュール３６Ｃの間にネットワーク常時接続があるかどうかを示している。第２列は、対象検証者を知っているかどうかを示し、そして第３列は、ドキュメントを検証できる回数に制限あるかどうかを示す。
【表３】

表３に示すシステム変形例は、上述した種別の１つまたはそれ以上のドキュメントと対をなすことができる。例えば、保証者と検証者の間が接続されておらず、対象検証者が既知で、検証数が限られている場合のシステムを用いて、ギフト券、チケット、およびデビットアイテム（debit item）を検証することができる。こうしたアイテムは、通常、１回だけ検証される。こうしたシステムは、ドキュメントの有効性を検証するために、暗号化および認証の両方を必要とする。
【００４６】
送達手段に信頼性がない場合に、上述したのと同様の種別のドキュメントに関して、保証者と検証者の間が常時接続されており、対象検証者が未知で、ドキュメント当たりの検証回数が限定的である場合のシステムを用いることができる。送達手段とは、ドキュメント発行者から検証者へ暗号化された有価ドキュメントを通信する手段を意味する。信頼性のない送達手段の一例は、暗号化された有価ドキュメントが請求者のインクジェットプリンタで印刷されたバーコードである場合である。こうしたバーコードは、不鮮明になり、判読不能になり得るので、保証者と検証者の間に常時接続またはバックアップ接続することが好ましい。こうしたバックアップ接続は、コンピュータネットワーク接続または電話接続であってもよい。バーコードが判読できない場合、この接続を用いて、有価ドキュメントの表面に印刷されたシリアル番号などの他の情報を保証者に通信してもよい。
【００４７】
保証者と検証者の間に接続がなく、対象検証者が既知で、検証回数が無制限である場合のシステムを用いて、遺書や認証を必要とする他のドキュメントなどの法的証書を検証することができる。
【００４８】
送達手段に信頼性がないとき、保証者と検証者の間に常時接続があり、対象検証者が既知で、検証回数が無制限である場合のシステムを用いて、上述と同様の種別のドキュメントを検証することができる。
【００４９】
保証者と検証者の間に接続がなく、対象検証者が未知で、検証回数が無制限である場合のシステムを用いて、入館許可証を検証することができる。
【００５０】
送達手段に信頼性がないとき、保証者と検証者の間に常時接続があり、対象検証者が未知で、検証回数が無制限である場合のシステムを用いて、上述と同様の種別のドキュメントを検証することができる。
【００５１】
貨幣、小切手、または電信送金などの金融ドキュメントを発行し、検証するために、以上説明した本発明の実施形態を用いた具体例を用いることができる。例えば、請求者は、遠隔地にいる親戚に送金したいとする。請求者は、例えばクレジットカードを用いて、発行者端末からの有価ドキュメントを要請することができる。すると、有価ドキュメントが上述の手法で形成され、暗号化される。そして請求者は、例えば電子メールを用いて、暗号化された有価ドキュメントを所望する受信先に送信する。受信者は、暗号化された有価ドキュメントを、会社、銀行、政府当局などの検証者に提示して、支払いを受ける。電信送金の代わりに、この方法を用いて、遠隔場所に金銭を送る。
【００５２】
本発明のさまざまな詳細事項は、本発明の精神から逸脱することなく、変更することができる。さらに、上述の開示は、説明のためだけのものであって、限定する意図はなく、本発明はクレームにより定義される。
【図面の簡単な説明】
【００５３】
【図１】図１は、本発明に係る実施形態による有価ドキュメント作成・検証方法およびシステムのための動作環境の一例を示すブロック図である。
【図２】図２は、本発明に係る実施形態による有価ドキュメント作成・検証方法およびシステムを図示するメッセージフロー図である。
【図３】図３は、本発明に係る実施形態による有価ドキュメントを含む動的取引プロトコルメッセージを作成する際に、発行者モジュールが実施するステップの一例を示すフローチャートである。
【図４】図４は、本発明に係る実施形態による有価ドキュメントを搬送するために用いられる動的取引プロトコルメッセージのブロック図である。
【図５Ａ】図５Ａは、本発明に係る実施形態による受信された動的取引プロトコルメッセージを検証する際に、検証者モジュールまたは保証者モジュールが実施するステップの一例を示すフローチャートである。
【図５Ｂ】図５Ｂは、本発明に係る実施形態による受信された動的取引プロトコルメッセージを検証する際に、検証者モジュールまたは保証者モジュールが実施するステップの一例を示すフローチャートである。
【図６】図６は、本発明に係る別の実施形態による有価ドキュメント作成・検証方法およびシステムを示すフローチャートである。
【図７】図７は、本発明に係る実施形態による独立型の検証者モジュールを含む有価ドキュメントの検証システムを示すブロック図である。
【図８】図８は、本発明に係る実施形態による管理集中型の検証者モジュールを含む有価ドキュメントの検証システムを示すブロック図である。
【符号の説明】
【００５４】
２０パーソナルコンピュータ、２１演算ユニット、２２システムメモリ、２３システムバス、２４読出専用メモリ（ＲＯＭ）、２５ランダムアクセスメモリ（ＲＡＭ）、２６基本入出力デバイス（ＢＩＯＳ）、２７ハードディスクドライブ、２８磁気ディスクドライブ、２９磁気ディスク、３０光ディスクドライブ、３１光ディスク、３２ハードディスクドライブインターフェイス、３３磁気ディスクドライブインターフェイス、３４光ディスクドライブインターフェイス、３５オペレーティングシステム、３６Ａ検証者モジュール、３６Ｂ保証者モジュール、３６Ｃ発行者モジュール、３７プログラムモジュール、３８プログラムデータ、４０キーボード、４２指示デバイス、４６シリアルポートインターフェイス、４７モニタ、４８ビデオアダプタ、４９遠隔コンピュータ、５０メモリストレージデバイス、５１ローカルエリアネットワーク（ＬＡＮ）、５２広域エリアネットワーク（ＷＡＮ）、５３システムエリアネットワーク（ＳＡＮ）、５４，５４Ａネットワークインターフェイスアダプタ、５５，５５Ａ演算ユニット、５６，５６Ａメモリユニット、５８モデム、２００請求者、３００動的取引プロトコルメッセージ、３０２長さフィールド、３０４暗号スキームインデックスフィールド、３０６オプションフィールド、３０８暗号化ドキュメントフィールド、３１０メッセージダイジェストフィールド、８００検証クライエント、８０２通信リンク。

Claims

有価ドキュメントの作成および検証方法であって、
（ａ）有価ドキュメントに関するリクエストを請求者から受け取るステップと、
（ｂ）有価ドキュメントを作成するステップと、
（ｃ）所定の鍵空間から暗号鍵を選択し、選択された暗号鍵を用いて有価ドキュメントに含まれる情報の少なくとも一部を暗号化するステップと、
（ｄ）暗号化された部分と、この部分を暗号化するために用いられた暗号鍵を示すインデックスとを含むメッセージを作成し、このメッセージを請求者に提供するステップと、
（ｅ）メッセージを受け取り、インデックスを用いて有価ドキュメントを検証するステップと、を有することを特徴とする方法。
請求項１に記載の方法であって、
有価ドキュメントに関するリクエストを受け取るステップは、チケットに関するリクエストを受け取るステップを含み、
有価ドキュメントを作成するステップは、チケットを作成するステップを含むことを特徴とする方法。
請求項１に記載の方法であって、
有価ドキュメントに関するリクエストを受け取るステップは、金融ドキュメントに関するリクエストを受け取るステップを含み、
有価ドキュメントを作成するステップは、金融ドキュメントを作成するステップを含むことを特徴とする方法。
請求項１に記載の方法であって、
有価ドキュメントに関するリクエストを受け取るステップは、ギフト券に関するリクエストを受け取るステップを含み、
有価ドキュメントを作成するステップは、ギフト券を作成するステップを含むことを特徴とする方法。
請求項１に記載の方法であって、
所定の鍵空間から暗号鍵を選択するステップは、ｎを１より大きい整数として、所定のｎ個の暗号鍵群から１つの暗号鍵を無作為または擬似的無作為に選択するステップを含むことを特徴とする方法。
請求項１に記載の方法であって、
所定の鍵空間から暗号鍵を選択するステップは、有価ドキュメントの発行者が要請するセキュリティレベルに呼応して、検証者特定の鍵空間内の部分空間から暗号鍵を無作為または擬似的無作為に選択するステップを含むことを特徴とする方法。
請求項１に記載の方法であって、
メッセージを作成するステップは、暗号化された部分の長さを示すための長さフィールドと、インデックスを記憶するための暗号スキームインデックスフィールドと、暗号化された部分のメッセージダイジェストを記憶するための暗号化メッセージダイジェストフィールドと、を含むメッセージを作成するステップを含むことを特徴とする方法。
請求項１に記載の方法であって、
インデックスを用いて有価ドキュメントを検証するステップは、インデックスを用いてデータベースから復号鍵を抽出するステップと、抽出された復号鍵を用いて有価ドキュメントを復号化するステップとを含むことを特徴とする方法。
請求項１に記載の方法であって、
メッセージを受け取るステップは、請求者からメッセージを受け取るステップを含むことを特徴とする方法。
請求項１に記載の方法であって、
メッセージを受け取るステップは、請求者からメッセージを入手した第三者からメッセージを受け取るステップを含むことを特徴とする方法。
複数ドキュメントの作成・検証システムにおいて検証されるドキュメントを作成する方法であって、
（ａ）ｎを１より大きい整数として、ｎ個の暗号鍵群を形成するステップと、
（ｂ）ｎ個の暗号鍵のそれぞれにインデックスを付与するステップと、
（ｃ）インデックスおよび暗号鍵を複数ドキュメントの作成・検証システムにおけるドキュメント検証者に送信するステップと、
（ｄ）暗号化される有価ドキュメントに関するリクエストを発行者から受け取るステップと、
（ｅ）それぞれのリクエストに関して、複数の暗号鍵の中から１つの暗号鍵を無作為または擬似的無作為に選択し、選択された暗号鍵を用いて有価ドキュメントを暗号化し、暗号化された有価ドキュメントおよびインデックスを発行者に送信するステップと、を有することを特徴とする方法。
請求項１１に記載の方法であって、
暗号化される有価ドキュメントに関するリクエストを受け取るステップは、暗号化チケットに関するリクエストを受け取るステップを含むことを特徴とする方法。
請求項１１に記載の方法であって、
暗号化される有価ドキュメントに関するリクエストを受け取るステップは、暗号化金融ドキュメントに関するリクエストを受け取るステップを含むことを特徴とする方法。
請求項１１に記載の方法であって、
暗号化される有価ドキュメントに関するリクエストを受け取るステップは、暗号化ギフト券に関するリクエストを受け取るステップを含むことを特徴とする方法。
請求項１１に記載の方法であって、
暗号化された有価ドキュメントおよびインデックスを発行者に送信するステップは、暗号化された有価ドキュメントの長さを記憶するための長さフィールドと、各ドキュメントの暗号化に対応するインデックスを記憶するための暗号スキームインデックスフィールドと、暗号化された有価ドキュメントの暗号化されたメッセージダイジェストを記憶するための暗号化メッセージダイジェストフィールドと、をそれぞれ含むメッセージを作成し、メッセージを発行者に送信するステップを含むことを特徴とする方法。
請求項１３に記載の方法であって、
メッセージをバーコードフォーマットに変更するステップと、
バーコードフォーマット化されたメッセージを請求者に送付するステップと、を有することを特徴とする方法。
請求項１１に記載の方法であって、
請求者から暗号化された有価ドキュメントを受け取るステップと、
インデックスおよび対応する暗号鍵を用いて、暗号化された有価ドキュメントを検証するステップと、を有することを特徴とする方法。
請求項１１に記載の方法であって、
１つの暗号鍵を無作為または擬似的無作為に選択するステップは、ドキュメント発行者特定の暗号レベルに対応して、検証者特定の鍵空間内の部分空間から１つの暗号鍵を選択するステップを含むことを特徴とする方法。
安全な有価ドキュメントを作成する方法であって、
（ａ）暗号化された有価ドキュメントを作成するリクエストをドキュメント請求者から受け取るステップと、このときリクエストは、暗号化される有価ドキュメントに含むべき情報と、所望するセキュリティレベルと、ドキュメントの有効開始日時および終了日時と、を含み、
（ｂ）要求されたセキュリティレベルに応じて、検証者特定の鍵空間内の部分空間から１つの暗号鍵を無作為または擬似的無作為に選択するステップと、
（ｃ）選択された暗号鍵を用いて、有価ドキュメントを暗号化するステップと、
（ｄ）暗号化された有価ドキュメントをドキュメント請求者に送信するステップと、を有することを特徴とする方法。
ドキュメント検証システムであって、
（ａ）エンドユーザから有価ドキュメントのリクエストを受け取る発行者モジュールと、
（ｂ）発行者モジュールからのリクエストを受け取り、このリクエストに基づいて、暗号化された有価ドキュメントを作成する保証者モジュールと、
このとき暗号化された有価ドキュメントを作成するステップは、
ｎを１より大きい整数として、所定のｎ個の暗号鍵群から１つの暗号鍵を無作為または擬似的無作為に選択するステップと、
無作為または擬似的無作為に選択された１つの暗号鍵を用いて、各有価ドキュメントを暗号化するステップと、
暗号化された有価ドキュメントおよび各有価ドキュメントを復号化するためのインデックスを、発行者モジュールに送信するステップと、を含み、
このとき発行者モジュールは、暗号化された有価ドキュメントを請求者に送り、
（ｃ）暗号化された有価ドキュメント、およびインデックスに基づいて有価ドキュメントを復号化するために選択された復号鍵に関するインデックスを請求者から受け取り、選択された復号鍵を用いて有価ドキュメントを検証するための検証者モジュールと、を備えたことを特徴とするシステム。
請求項２０に記載のシステムであって、
有価ドキュメントはチケットであることを特徴とするシステム。
請求項２０に記載のシステムであって、
有価ドキュメントは金融ドキュメントであることを特徴とするシステム。
請求項２０に記載のシステムであって、
有価ドキュメントはギフト券であることを特徴とするシステム。
請求項２０に記載のシステムであって、
発行者モジュールは、暗号化された有価ドキュメント情報を含むバーコードを形成し、請求者にバーコードを送るように構成されることを特徴とするシステム。
請求項２０に記載のシステムであって、
発行者モジュールは、保証者モジュールからのセキュリティレベルを要求するように構成され、
保証者モジュールは、要求されたセキュリティレベルに基づいて、鍵空間から暗号鍵を選択するように構成されることを特徴とするシステム。
請求項２５に記載のシステムであって、
発行者モジュールは、保証者モジュールから対象検証者を要求するように構成され、
保証者モジュールは、対象検証者に基づいて、鍵空間から暗号鍵を選択するように構成されることを特徴とするシステム。
請求項２０に記載のシステムであって、
保証者モジュールは、暗号化された有価ドキュメントを含むバーコードを形成し、発行者モジュールにバーコードを送るように構成されることを特徴とするシステム。
請求項２０に記載のシステムであって、
保証者モジュールは、暗号化された有価ドキュメントを含むバーコードを含むメッセージを形成するように構成され、
各メッセージは、暗号化された部分の長さを記憶するための長さフィールドと、インデックスを記憶するための暗号スキームインデックスフィールドと、暗号化された有価ドキュメントを記憶するための暗号化メッセージフィールドと、暗号化された有価ドキュメントの暗号化されたメッセージダイジェストを記憶するためのメッセージダイジェストフィールドとを含むことを特徴とするシステム。
請求項２８に記載のシステムであって、
保証者モジュールは、暗号化された有価ドキュメントのそれぞれのメッセージダイジェストを作成し、メッセージダイジェストを暗号化し、暗号化されたメッセージダイジェストの内容をメッセージダイジェストフィールドに格納するように構成されたことを特徴とするシステム。
請求項２９に記載のシステムであって、
検証者モジュールは、暗号化された有価ドキュメントおよびメッセージダイジェストを復号化し、暗号化された有価ドキュメントのメッセージダイジェストを計算し、受信された有価ドキュメントの完全性を認証するために計算されたメッセージダイジェストを復号化されたメッセージダイジェストと比較することにより、各メッセージを検証するように構成されたことを特徴とするシステム。
請求項２０に記載のシステムであって、
検証者モジュールは、１つの場所で提示される有価ドキュメントを検証するように構成される独立型ユニットを有することを特徴とするシステム。
請求項２０に記載のシステムであって、
検証者モジュールは、複数の場所で提示される有価ドキュメントを検証するように構成される管理集中型ユニットを有することを特徴とするシステム。
コンピュータにより判読可能な媒体に具現化された、コンピュータにより実行可能な指令を含むコンピュータプログラム製品であって、その指令は、
（ａ）暗号化される有価ドキュメントに関するリクエストを受信するステップと、
（ｂ）各リクエストに対して、ｎを１より大きい整数として、所定のｎ個の暗号鍵群から１つの暗号鍵を選択するステップと、
（ｃ）各リクエストに対して、１つの選択された暗号鍵を用いて、有価ドキュメントを暗号化するステップと、
（ｄ）暗号化された有価ドキュメントをドキュメント請求者に送信するためのメッセージを作成するステップと、各メッセージは、有価ドキュメントを復号化する鍵を特定するための暗号スキームインデックスを有し、
（ｅ）メッセージをドキュメント請求者に送るステップと、を有することを特徴とするコンピュータプログラム製品。
請求項３３に記載のコンピュータプログラム製品であって、
暗号化される有価ドキュメントに関するリクエストを受信するステップは、チケットを暗号化するリクエストを受け取るステップを含むことを特徴とするコンピュータプログラム製品。
請求項３３に記載のコンピュータプログラム製品であって、
暗号化される有価ドキュメントに関するリクエストを受け取るステップは、有価ドキュメントを暗号化するリクエストを受け取るステップを含むことを特徴とするコンピュータプログラム製品。
請求項３３に記載のコンピュータプログラム製品であって、
暗号化される有価ドキュメントに関するリクエストを受け取るステップは、ギフト券を暗号化するリクエストを受け取るステップを含むことを特徴とするコンピュータプログラム製品。
請求項３３に記載のコンピュータプログラム製品であって、
暗号化される有価ドキュメントに関するリクエストを受け取るステップは、特定の暗号レベルを含むリクエストを受け取るステップを含み、
各リクエストに対して１つの暗号鍵を選択するステップは、特定の暗号レベルに基づいて選択するステップを含むことを特徴とするコンピュータプログラム製品。
請求項３３に記載のコンピュータプログラム製品であって、
各リクエストに対して１つの暗号鍵を選択するステップは、各有価ドキュメントの価値に基づいて暗号鍵の長さを選択するステップを含むことを特徴とするコンピュータプログラム製品。
請求項３３に記載のコンピュータプログラム製品であって、
所定のｎ個の暗号鍵群から１つの暗号鍵を選択するステップは、暗号鍵を無作為または擬似的無作為に選択するステップを含むことを特徴とするコンピュータプログラム製品。
請求項３３に記載のコンピュータプログラム製品であって、
選択された１つの暗号鍵を用いて、各有価ドキュメントを暗号化するステップは、有価ドキュメントを暗号化するために対称アルゴリズムを用いるステップを含むことを特徴とするコンピュータプログラム製品。
請求項３３に記載のコンピュータプログラム製品であって、
選択された１つの暗号鍵を用いて、各有価ドキュメントを暗号化するステップは、有価ドキュメントを暗号化するために非対称アルゴリズムを用いるステップを含むことを特徴とするコンピュータプログラム製品。
請求項３３に記載のコンピュータプログラム製品であって、
前記ステップ（ａ）ないし(ｄ)は、発行者モジュールにより実施されることを特徴とするコンピュータプログラム製品。
請求項３３に記載のコンピュータプログラム製品であって、
前記ステップ（ａ）ないし(ｄ)は、保証者モジュールにより実施されることを特徴とするコンピュータプログラム製品。
請求項３３に記載のコンピュータプログラム製品であって、
前記ステップ（ａ）ないし(ｄ)は、発行者モジュールおよび保証者モジュールの組み合わせにより実施されることを特徴とするコンピュータプログラム製品。
請求項３３に記載のコンピュータプログラム製品であって、
メッセージを作成するステップは、動的取引プロトコルメッセージを作成するステップを含み、
各動的取引プロトコルメッセージは、暗号化された有価ドキュメントの長さを示すデータ長を記憶するための長さフィールドと、暗号スキームインデックスを記憶するための暗号スキームインデックスフィールドと、暗号化された有価ドキュメントの暗号化メッセージダイジェストを記憶するためのメッセージダイジェストフィールドと、を含むことを特徴とするコンピュータプログラム製品。