(57)【要約】データが正しいものであると判断できなかった場合には、そのデータの利用できる部分を再利用することを目的とする。このために入力部１０１がデータ１０５を入力し、処理部１０２において処理済みデータ１０７を生成する。処理済みデータ１０７の生成に応じて検証データ生成部１０３において処理済みデータの真正性を保証するための検証データ１０８を生成して出力部１０４において処理済みデータ１０７と検証データ１０８とを関連付けた検証付きデータ１０６を出力する。処理済みデータ１０７に入力されたデータ１０５を含むようにすることにより、処理済みデータ１０７の真正性が肯定できない場合であってもデータ１０５の真正性が保証できれば、データ１０５を用いて処理が行なえる。また、処理済みデータに真正性が肯定的ない場合の処理のために必用となる状態復帰情報を含ませることにより柔軟な処理の指定が可能となる。
2003036866.tif 000002
【特許請求の範囲】
【請求項１】
データを入力する入力部と、
入力部に入力されたデータを処理して処理済みデータを生成する処理部と、
処理部での処理済みデータの生成に応じて、処理済みデータの真正性を保証するための検証データを生成する検証データ生成部と、
処理済みデータと検証データとを関連付けたデータである検証付きデータを出力する出力部と、を具備する情報処理装置。
【請求項２】
処理済みデータは、処理部における処理の完了を示すデータである請求の範囲第１項に記載の情報処理装置。
【請求項３】
入力部は、データとして検証付きデータを入力する請求の範囲第１項に記載の情報処理装置。
【請求項４】
入力部に入力された検証付きデータの検証データに基づいて、入力された検証付きデータの真正性を検証する検証部を有する請求の範囲第３項に記載の情報処理装置。
【請求項５】
処理部は、入力部に入力された検証付きデータを含む処理済みデータを生成する請求の範囲第４項に記載の情報処理装置。
【請求項６】
処理済みデータには、検証部における検証結果が検証付きデータの真正性を肯定するものでない場合の検証付きデータに対する処理のために必要となる情報である状態復帰情報を含む請求の範囲第４項または請求の範囲第５項に記載の情報処理装置。
【請求項７】
検証部は、検証部で検証した真正性を肯定することができない検証付きデータを出力した情報処理装置である一次原情報処理装置に対して検証付きデータを出力した情報処理装置である二次原情報処理装置がある場合には、二次原情報処理装置の出力した検証付きデータの検証を行なう請求の範囲第６項に記載の情報処理装置。
【請求項８】
状態復帰情報は、二次原情報処理装置の出力した検証付きデータの検証結果が検証付きデータの真正性を肯定するものである場合には二次原情報処理装置の処理済みデータに含まれる状態復帰情報に基づいて二次原情報処理装置の出力した検証付きデータの処理を行なうための情報である請求の範囲第７項に記載の情報処理装置。
【請求項９】
状態復帰情報には、真正性が肯定されなかった検証付きデータに対する処理をするために必要となるＵＲＬ、電話番号、電子メールアドレス、プログラムのいずれか一以上を含む請求の範囲第６項から第８項のいずれか一に記載の情報処理装置。
【請求項１０】
入力されたデータを取得する入力ステップと、
入力ステップにおいて取得されたデータを処理して処理済みデータを生成する処理ステップと、
処理ステップでの処理データの生成に応じて、処理済みデータの真正性を保証するための検証データを生成する検証データ生成ステップと、
処理済みデータと検証データとを関連付けたデータである検証付きデータを出力する出力ステップと、を計算機に実行させるための情報処理プログラム。
【請求項１１】
入力されたデータを取得する入力ステップと、
入力ステップにおいて取得されたデータを処理して処理済みデータを生成する処理ステップと、
処理ステップでの処理データの生成に応じて、処理済みデータの真正性を保証するための検証データを生成する検証データ生成ステップと、
処理済みデータと検証データとを関連付けたデータである検証付きデータを出力する出力ステップと、を備えることを特徴とする情報処理方法。
【発明の詳細な説明】
技術分野
本発明は、データ処理に関しており、特にデータの真正性を示す検証データ付きのデータ処理に関する。
背景技術
従来、通信相手から送付されたデータが正しいものであるかどうかを調べる手法として「署名」が用いられてきた。署名とは、データに対してＭＤ５（ＲＦＣ１３２１参照）などの要約関数を用いてデータを特徴づける要約を求め、それを暗号化して得られる。データとその署名とを受け取った者は、署名が、そのデータから要約関数と暗号化によって得られたものであるかどうかを判定することにより、データが正しいものであるかどうかを判定する。
署名の例として、ブラウザとサーバとの間でのセキュアな通信を確保するためのＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）の「証明書」を挙げることができる。この証明書は、通信相手の公開鍵の正当性を証明するものであり、公開鍵の対象であるサブジェクト、証明書発行者名、公開鍵、有効期限、その他関連情報からなり、加えて、これらが正しいものであることを示す認証局による署名が含まれる。このような証明書は、通信相手から送付された公開鍵が正しいものかどうかを判断するために用いられる。
しかしながら、従来の署名を用いる通信方法では、署名によりデータが正しいものであると判断できなかった場合には、そのデータの利用できる部分を再利用することなく、そのデータが全て破棄されて再度送信がされることになり、通信量の増大を招いていた。また、署名によりデータが正しいものであると判断できなかった場合には、データに応じて動的に処理を行なう指定はできなかった。
発明の開示
以上の課題を解決するために、本発明においては、第一に、入力されたデータを処理する処理部と、処理部での処理済みデータの生成に応じて処理済データの署名（以下では、「検証データ」と呼ぶ）を生成し、処理済みデータと検証データとを関連付けて出力する情報処理装置を提供する。また、処理済みデータは、処理の完了を示すデータであってもよい。これにより、情報処理装置の出力の検証データを調べることにより、情報処理装置での処理結果を知ることができる。
この場合において、情報処理装置に入力されるデータは、検証データと関連付けられたデータであってもよい。また、情報処理装置が入力されたデータに関連付けられた検証データを用いて入力されたデータの正しさを判断するようにしてもよい。これにより、多段階で処理がされる場合に、前段階までの処理の結果を知ることができるようになる。
第二に、処理済みデータは、入力されたデータを含むように処理部が動作するようにしてもよい。これにより、処理を行った履歴が処理済みデータに含まれるようになり、処理結果が正しくないと判明した場合に、最初から処理を再度行なうのではなく、処理結果が正しいところから処理を行なうことができ、無駄な処理をしないで済むようになり、また、通信量の削減ももたらす。
第三に、処理済みデータに、検証データにより処理済みデータが正しくないと判断された場合の処理に必要となる情報である状態復帰情報を含むようにしてもよい。これにより、処理済みデータが正しくないことが判明した場合の処理を動的に指定することが可能となる。
第四に、検証データにより処理済みデータが正しくないと判断された場合には、前の処理段階に入力されたデータに関連付けられた検証データにより、その入力されたデータが正しいかどうかを判断するようにした。これにより、処理の履歴を遡ることができ、正しい処理から処理を再開することができる。
第五に、検証データにより処理済みデータが正しくないと判断された場合には、前の処理段階に入力されたデータに関連付けられた検証データにより、その入力されたデータが正しいかどうかを判断し、正しいと判断された場合には、その入力されたデータに含まれる状態復帰情報に基づいて処理を行なうようにした。これにより、処理の履歴を遡り、正しい処理を行なうための処理が動的に指定できるようになる。
発明を実施するための最良の形態
以下、本発明の実施の形態について、図を用いて説明する。なお、本発明は、これら実施の形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる形態で実施し得る。
（実施の形態１）
図１は、本発明の実施の形態１に関する情報処理装置の機能ブロック図を例示する。図１において、情報処理装置１００は、入力部１０１と、処理部１０２と、検証データ生成部１０３と、出力部１０４と、を具備している。
入力部１０１は、データ１０５を入力する。本発明において、「データ」とは、デジタル情報によって表現されたものを想定しており、データの例を示すと、伝票データ、チケットデータなどが挙げられる。入力部１０１は、入力されたデータを処理部１０２へ渡す。
処理部１０２は、入力部１０１に入力されたデータを処理して処理済みデータを生成する。例えば、伝票データに保持されている金額の合計を求め、その合計の金額を含む伝票データや、チケットデータの有効性を判断した結果を示すデータがある。処理部１０２は処理済みデータを検証データ生成部１０３と出力部１０４へ渡す。
検証データ生成部１０３は、処理部１０２での処理済みデータの生成に応じて、処理済みデータの真正性を保証するための検証データを生成する。「処理済みデータの生成に応じて」とは、「処理部１０２での処理済みデータの生成のときに処理済みデータに基づいて」ということであり、処理済みデータの生成と並列に検証データが生成されるものであってもよいし、処理済みデータの生成が全て終了してから検証データが生成されるものであってもよい。「検証データ」とは処理済みデータの真正性を保証するためのデータであり、「処理済みデータの真正性」とは、処理済みデータが情報処理装置１００の処理部１０２によって生成されたことを意味する。検証データの一例としては、図３に例示するように、処理済みデータ３０１を要約し、その要約結果に対して暗号化を施した結果を検証データ３０２することが考えられる。「処理済みデータ３０１を要約」するとは、異なる処理済みデータには異なる値、あるいは、できるだけ異なる値、を対応付けることである。その対応付けのアルゴリズムとしては、Ｍｅｓｓａｇｅ  Ｄｉｇｅｓｔ  ５（ＲＦＣ１３２１として規定されているアルゴリズム。以下、「ＭＤ５」と略記）が知られており、このＭＤ５においては、任意長のデータに１２８ビットのデータを割り当てる。ＭＤ５においては、あるデータＡに対して１２８ビットの値ａが得られた場合、値ａを用いてＡと異なるデータであってＭＤ５により値ａが得られるデータＢを求めることは事実上不可能と考えられている。暗号化の方法としては、公開鍵暗号方式が知られており、要約の結果を秘密鍵によって暗号化する。このようにすれば、処理済みデータ３０１と検証データ３０２とを受け取った者は、検証データ３０２を秘密鍵に対応する公開鍵によって復号した結果と処理済みデータ３０１の要約結果とが等しくなるかどうかによって処理済みデータ３０１の真正性を検証することが可能である。なお、公開鍵暗号方式を用いなくても、共通鍵暗号化方式を用いて共通鍵によって要約の結果を暗号化し、検証データをその共通鍵で復号してもよい。また、処理済みデータ３０１を要約し、それを共通鍵で暗号化したものが検証データと同じになるかどうかを調べてもよい。
出力部１０４は、処理済みデータと検証データとを関連付けたデータである検証付きデータを出力する。すなわち、処理部１０２で生成された処理済みデータと検証データ生成部１０３で生成された検証データを関連付け、図１に例示する処理済みデータ１０７と検証データ１０８とを含む検証付きデータ１０６を出力する。この場合、処理済みデータ１０７が、データ１０５を処理部１０２において処理して生成されたデータであり、検証データ１０８が、処理部１０２での処理済みデータ１０７の生成に応じて検証データ生成部１０３で生成された検証データである。
なお、図１においては、処理部１０２は処理済みデータを検証データ生成部１０３と出力部１０４とへ渡すように書かれているが、図２に示すように、処理部２０１と検証データ生成部２０２とが直列に接続されていてもよい。処理部２０１は、処理部１０２と同様に入力部１０１に入力されたデータを処理して処理済みデータを生成し、検証データ生成部２０２は、処理部２０１での処理済みデータの生成に応じて、処理済みデータの真正性を保証するための検証データを生成する。図１との違いは、処理部２０１は処理済みデータを検証データ生成部２０２へ渡し、検証データ生成部２０２が処理部２０１より処理済みデータを受け取り、その受け取りに応じて検証データを生成し、出力部１０４へ処理済みデータと検証データを渡すようにしている点である。
図４は、情報処理装置１００の処理を説明するフローチャートである。ステップＳ４０１において、データを入力する。すなわち、入力部１０１にデータの入力を行なわせる。
ステップＳ４０２において、処理済みデータを生成する。すなわち、処理部１０２に入力部１０１に入力されたデータを処理させ処理済みデータを生成させる。
ステップＳ４０３において、処理済みデータの生成に応じて検証データを生成する。すなわち、検証データ生成部１０３に、処理部１０２での処理済みデータの生成に応じて処理済みデータの真正性を保証するための検証データを生成させる。
ステップＳ４０４は、検証付きデータを出力する。すなわち、出力部１０４に処理済みデータと検証データとを関連付けたデータである検証付きデータを出力させる。
なお、図４においては、ステップＳ４０２が終了してからステップＳ４０３が実行されるように書かれているが、処理部１０２と検証データ生成部１０３を並列して動作させることにより、ステップＳ４０２とステップＳ４０３とを並列に実行することも可能である。
また、図４は、情報処理装置１００を計算機によって実現する場合における各ステップを計算機に実行させるための情報処理プログラムのフローチャートとみなすこともでき、ステップＳ４０１は、入力されたデータを取得する入力ステップであり、ステップＳ４０２は、入力ステップであるステップＳ４０１で取得されたデータを処理して処理済みデータを生成する処理ステップであり、ステップＳ４０３は、処理ステップであるステップＳ４０２での処理データの生成に応じて、処理済みデータの真正性を保証するための検証データを生成する検証データ生成ステップであり、ステップＳ４０４は、処理済みデータと検証データとを関連付けたデータである検証付きデータを出力する出力ステップである。
また、図４は、入力ステップ、処理ステップ、検証データ生成ステップ、出力ステップとを備えることを特徴とする情報処理方法の使用を説明するフローチャートとみなすこともできる。情報処理装置１００は、その情報処理方法を使用するための装置であるとみなすことができる。
図５は、本実施の形態における情報処理装置１００の利用形態の一例を示している。図５は自動改札機の内部の機能ブロック図を例示しており、情報処理装置１００とゲート制御装置５０１とが示されている。情報処理装置１００にはデータとして切符などの裏面の磁気部分に記録されたチケットデータ５０３が入力され、処理部１０２は、チケットデータ５０３が有効か無効かどうか、例えば有効期限が過ぎていないか、既に使用されたものでないか、を判断した結果である判断結果を処理済みデータとして生成し、検証データ生成部１０３は、その判断結果の検証データを生成し、出力部１０４はその判断結果と検証データとを関連付けた検証付きデータ５０４を出力する。検証付きデータ５０４は、ゲート制御装置５０１に入力され、検証付きデータ５０４の検証データによって判断結果の真正性を検証し、真正性が肯定され、判断結果が「有効」であればゲートの開閉指示５０２としてゲートを開く指示を出力し、判断結果の真正性が肯定されないか、判断結果が「無効」であればゲートの開閉指示５０２としてゲートを閉じる指示を出力する。
図６は、ゲート制御装置５０１の処理を説明するフローチャートであり、ステップＳ６０１において検証付きデータ５０４を取得する。
ステップＳ６０２において、検証データを用いて判断結果である処理済みデータが真正なものであるかどうか、すなわち、真正性を判断し、真正性が肯定されればステップＳ６０３へ移行し、肯定されなければ（否定されれば）ステップＳ６０５へ移行する。
ステップＳ６０３において、判断結果が「有効」であるかどうかを判断し、「有効」であると判断されればステップＳ６０４へ移行し、ゲートの開閉指示５０２としてゲートを開ける指示を出力する。ステップＳ６０３において「有効」でないと判断されれば、ステップＳ６０５へ移行する。
ステップＳ６０５へは、判断結果である処理済みデータの真正性が肯定されない場合、または、判断結果が「有効」でないと判断された場合に処理の制御が移るので、ゲートの開閉指示５０２としてゲートを閉める指示を出力する。
このように情報処理装置１００とゲート制御装置５０１とを用いることにより、ゲート制御装置５０１は、情報処理装置１００から出力される検証付きデータ５０４に基づいた処理を行なえばよく、チケットデータの有効性を判断する必要がなくなる。また、ゲート制御装置５０１の構造が簡略化される。また、自動改札機を構成する装置のモジュール性も高まる。
なお、図５において、情報処理装置１００は、入力されるチケットデータ５０３が有効なものでないと判断した場合には、ゲート制御装置によって真正性が肯定されない検証付きデータ５０４を出力するようにしてもよい。このようにすれば、ゲート制御装置５０１はステップＳ６０２の処理済みデータが真正かどうかを判断すればよく、ステップＳ６０３の判断を省略することが可能となり、ゲート制御装置５０１が簡略化される。
また、図１において処理部１０２が生成する処理済みデータは、処理部１０２における処理の完了を示すデータであってもよい。この場合、検証データ生成部１０３は、処理の完了を示すデータの真正性を保証するための検証データを生成し、出力部１０４は処理の完了を示すデータと検証データを関連付けたデータを出力することになる。
処理済みデータが、処理部１０２における処理の完了を示すデータとなる実施例としては、次のものを挙げることができる。すなわち、図５の情報処理装置が、チケットデータ５０３が「有効」であるという判断結果の生成という処理が完了したことを示すデータである判定完了データと、その判定完了データの真正性を保証するための検証データと、を入場者数のカウントを行なう装置へ送信する。その入場者数のカウントを行なう装置は、情報処理装置１００からの検証付きデータを受け取り、真正性が肯定されれば入場者数の数を一だけ増やすことを行なう。あるいは、図５のゲート制御装置５０１を本実施の形態における情報処理装置とし、ゲート制御装置５０１が検証付きデータ５０４を取得し、その判断結果の真正性の判断と判断結果が「有効」かどうかの判断を行なう。ゲート盛業装置５０１がゲートを開ける指示を出力した時に、ゲートを開ける指示の出力の完了を示すデータとそのデータの真正性を保証するための検証データとを入場者数をカウントする装置へ送信するようにしてもよい。
また、情報処理装置１００の出力部は、検証付きデータ１０６とは別に、処理済みデータを出力するようにしてもよい。図７は、このような場合の機能ブロック図を例示している。出力部１０４は、処理部１０２と検証データ生成部１０３とで生成された処理済みデータと検証データとを受け取り、処理済みデータ７０１と検証付きデータ１０６とを出力するようになっている。この場合において検証付きデータ１０６は、処理済みデータ７０１とその真正性を保証するための検証データとを関連づけたデータであってもよい。また、検証データ生成部１０３が処理部１０２における処理の完了を示すデータの真正性を保証するための検証データを生成するようにし、検証付きデータ１０６は処理１０２における処理の完了を示すデータとその真正性を保証するための検証データを関連付けたものであってもよい。
図８は、図７に示された情報処理装置１００の利用形態の一例である自動改札機の機能ブロック図を示している。図８において、チケットデータ８０１は「（Ｎ）」と書かれているようにＮ回利用できる回数券のデータであり、情報処理装置は、チケットデータ８０１の有効性を判断する処理を行い、図５の場合と同じように、有効性の判断についての検証付きデータ１０６を出力する。また、情報処理装置１００は、処理済みデータとしてチケットデータ８０２を出力し、「（Ｎ−１）」と書かれているようにＮ−１回利用できる回数券のデータを出力する。この処理済みデータを切符の裏面の磁気部分に書き込むことにより、利用回数が一回減った切符となる。
このように、情報処理装置において、処理済みデータと検証データとを関連付けた検証付きデータを出力することにより、出力された検証付きデータを取得する装置は、検証付きデータの検証データにより処理済みデータの真正性を確認すればよいので、構造が簡略化され、また、装置のモジュール性が高まる。このような効果は、処理済みデータが処理の完了を示すデータであっても同様に得られる。
（実施の形態２）
実施の形態１において、情報処理装置１００の入力部１０１は、データとして検証付きデータを入力するようにしてもよい。
図９は、データとして検証付きデータを入力する情報処理装置の利用形態を例示する。図９には、情報処理装置９０１と、端末９０２と、情報処理装置９０３と、が示されている。情報処理装置９０１は、データ９０４を取得する。また、情報処理装置９０１は、端末９０２が送信する要求９０５に応じて、データ９０４に対して処理を行い、その結果として、検証付きデータ９０６を端末９０２へ送信する。端末９０２は、検証付きデータ９０６を受け取ると、検証付きデータ９０７として情報処理装置９０３へ送信する。このとき、端末は、情報処理装置９０１より受け取った検証付きデータに変更を加えず、そのまま検証付きデータ９０７として送信してもよいし、なんらかの処理を行ってから送信するようにしてもよい。情報処理装置９０３の入力部は、データとして端末９０２から送信された検証付きデータ９０７を入力するようになっている。
図１０は、情報処理装置９０１と、端末９０２と、情報処理装置９０３と、の間の送受信の関係を示したシーケンス図であり、ステップＳ１００１において、情報処理装置９０１がデータ９０４を取得する。ステップＳ１００２において端末９０２から情報処理装置９０１へ要求が送信され、これに対応して、ステップＳ１００３において、情報処理装置９０１から端末９０２へ検証付きデータが送信される。ステップＳ１００４において、端末より検証付きデータが情報処理装置９０３へ送信される。この図１０において、端末９０２と情報処理装置９０３が、入力部が検証付きデータを入力する情報処理装置となっている。
このように、入力部がデータとして検証付きデータを入力することにより、端末を介して多段階に処理が行なえるようになる。また、端末を操作することにより、受け取った検証付きデータの内容により送信先の情報処理装置を選択して送信することが可能になる。
図１１は、端末を介さず、情報処理装置間で多段階に処理を行なう場合を例示している。情報処理装置１１０１はデータ１１０４を受け取り、処理を行い、検証付きデータ１１０５を出力し、情報処理装置１１０２へ入力する。情報処理装置１１０２は、検証付きデータ１１０５を処理し、検証付きデータ１１０６を出力し、情報処理装置１１０３へ入力する。この図１１において、情報処理装置１１０２以降が、入力部が検証付きデータを入力するようになっている。
このように、入力部がデータとして検証付きデータを入力することにより、処理が多段階に行なえるようになる。また、同一装置内で多段階処理を行なう場合には、データの真正性を確認するために行なう各処理間での認証の手続きを省略することができる。また、複数装置間で多段階処理を行なう場合には、データ送受信毎に装置間で行なうデータの真正性を確認するための認証の手続きを省略することができる。
（実施の形態３）
図１２は、本発明の実施の形態３における情報処理装置の機能ブロック図を示す。本実施の形態は、実施の形態２の情報処理装置に検証部１２０２が追加された形態になっている。
検証部１２０２は、入力部１０１に入力された検証付きデータの検証データに基づいて入力された検証付きデータの真正性を検証する。この検証の方法は、実施の形態１の説明に記した通りである。すなわち、入力部１０１に入力された検証付きデータ１２０１よりデータと検証データを取り出し、データに対する要約の結果と暗号化されている検証データを復号して得られる結果とが一致するかどうか、もしくはデータに対する要約の結果が検証データを共通鍵によって復号したものと同じかどうか、で判断する。あるいは、共通鍵暗号方式を用いている場合には、データに対する要約の結果を共通鍵によって暗号化したものが検証データと同じになるかどうかで判断するようにしてもよい。
図１３は、本実施の形態における情報処理装置１００の処理を説明するフローチャートである。ステップＳ１３０１において、データを入力する。
ステップＳ１３０２において、データが真正なものであるかどうか、真正性の判断を行なう。もし、真正なものでないと判断されれば、ステップＳ１３０３へ移行し、エラー処理を行い、処理を終了する。
ステップＳ１３０２においてデータが真正なものであると判断された場合には、ステップＳ１３０４へ移行し、処理済みデータを生成することを行ない、ステップＳ１３０５において、処理済みデータの生成に応じて、検証データを生成することを行ない、ステップＳ１３０６において、ステップＳ１３０４で生成された処理済みデータとステップＳ１３０５で生成された検証データとを関連付けた検証付きデータを出力する。
このように、情報処理装置が検証部を備えることにより、真正性が検証できないデータは処理がされないようになる。例えば、図９のように端末９０２を経由して検証付きデータが入力される場合には、端末９０２においてデータの改竄が行われる可能性があり、そのような場合に備えて情報処理装置９０３が検証部を具備することにより、改竄が行われたデータを処理しないようにできる。また、破損したデータが情報処理装置９０３に入力された場合にも、そのようなデータを処理しないようにすることができる。
また、図１４のように、情報処理装置である伝票作成端末１４０１と、製品管理サーバ１４０２と、経理処理サーバ１４０３と、請求書作成サーバ１４０４と、が通信網１４００を介して接続されている場合に、各情報処理装置間でデータを通信し合う場合に、通信の不具合によりデータが破損したり、悪意を持ったものが不正なデータを流したりした場合にも、検証部である伝票検証部１４０８、伝票検証部１４１３、伝票検証部１４１８においてデータを検証することにより、そのようなデータを処理しないようにすることが可能となる。
なお、図１４の伝票作成端末１４０１と、製品管理サーバ１４０２と、経理処理サーバ１４０３と、請求書作成サーバ１４０４と、における処理の流れを説明すると、次のようになる。伝票作成端末１４０１は、検証データを付与した伝票データを作成し、製品管理サーバ１４０２へ送信する。製品管理サーバ１４０２は、伝票作成端末１４０１から送信されてきた伝票データの検証データにより伝票データの真正性が肯定できるかどうかを確認し、肯定できれば発送処理を行なう。発送処理完了後、検証データを付与し、経理処理サーバ１４０３へ送信する。経理処理サーバ１４０３は、製品管理サーバ１４０２から送信されてきた伝票データの検証データにより伝票の真正性が肯定できるかどうか確認し、肯定できれば経理処理を行なう。経理処理完了後、検証データを付与し、請求書作成サーバ１４０４へ送信する。請求書作成サーバ１４０４は、経理処理サーバ１４０３から送信されてきた伝票データの検証データにより伝票データの真正性が肯定できるかどうかを判断し、肯定できる場合には顧客毎に請求書作成を行なう。なお、伝票作成端末１４０１と、製品管理サーバ１４０２と、経理処理サーバ１４０３と、請求書作成サーバ１４０４と、は各自が持つ秘密鍵を用いて検証データを生成し、検証データによる真正性の確認は、送信者に対応した公開鍵を用いて行なうようにしてもよい。
（実施の形態４）
実施の形態４においては、実施の形態３における情報処理装置の処理部は、入力部に入力された検証付きデータを含む処理済みデータを生成する。すなわち、処理部により生成される処理済みデータは、入力部より渡された検証付きデータと、その検証付きデータに対して処理を行って生成されるデータと、を含むようになっている。この様子を示したのが図１６であり、１６０１が処理部によって生成された処理済みデータであり、符号１６０１ａの部分に入力部より渡された入力された検証付きデータがあり、符号１６０１ｂの部分が処理部によって生成されたデータとなっている。このとき、検証データ生成部は、処理済みデータ１６０１全体に対する検証データ１６０２を生成し、出力部１０４は、処理済みデータ１６０１と検証データ１６０２とを関連付けたデータ１６０３を出力することになる。
図１５は、より具体的な例を示している。この例は、図１４に示した情報処理装置の間で入出力がされるデータを模式的に示している。データ１５０１は、情報処理装置である伝票作成端末１４０１から出力されるデータであり符号１５０４を付けた部分が伝票作成端末１４０１の処理部が生成した処理済みデータであり、符号１５０５を付けた部分が検証データ生成部により生成された検証データである。伝票作成端末１４０１がデータ１５０１を出力し製品管理サーバ１４０２へ入力すると、製品管理サーバ１４０２は、これに対して処理を行い、データ１５０２を出力する。データ１５０２の符号１５０６を付けた部分が製品管理サーバ１４０２の処理部が生成した処理済みデータであり、この上の部分には、データ１５０１が変更などを受けずにに存在し、一番下に「発送処理日時」として製品管理サーバ１４０２が生成したデータが追加されている。そして、符号１５０７を付けた部分に符号１５０６を付けた部分の処理済みデータの生成に応じて生成された検証データ′が追加される。製品管理サーバ１４０２は、データ１５０２を出力し、経理処理サーバ１４０３へ入力する。経理処理サーバ１４０３は、これに対してデータ１５０３を出力する。データ１５０３には、符号１５０８を付した部分の上の部分には、入力されたデータ１５０２が変更などを受けずに存在し、一番下の部分に「経理処理日時」として経理処理サーバ１４０３が生成したデータが追加されている。そして符号１５０９をつけた部分に符号１５０８をつけた部分の処理済みデータの生成に応じて生成された検証データ′′１５０９が追加される。
このように、処理部が入力部に入力された検証付きデータを含む処理済みデータを生成することにより、処理の履歴がわかり、検証付きデータの真正性が肯定されない場合（すなわち、検証付きデータの真正性が否定された場合）に、真正性が肯定される処理まで遡ることができ、そこから処理を再開すればよい。例えば、経理処理サーバ１４０３からデータ１５０３を受け取った請求書作成サーバ１４０４が検証データ′′によるデータ１５０３の真正性が否定されたことを検出すると、符号１５０８を付けた部分よりデータ１５０２を取り出し、検証データ′１５０７によりデータ１５０２の真正性を判断する。もし真正性が肯定されれば、データ１５０２を経理処理サーバ１４０３へ入力すればよく、再びデータ１５０１の発行からやり直すことがなくなり、無駄が省けることになり、また、通信網１４００における通信量が少なくて済むことになる。
（実施の形態５）
実施の形態３または実施の形態４において、処理済みデータに、状態復帰情報が含まれるようにしてもよい。状態復帰情報とは、検証部における検証結果が検証付きデータの真正性を肯定するものでない場合の検証付きデータに対する処理のために必要となる情報である。「真正性を肯定するものでない場合の検証付きデータに対する処理」とは、例えば、検証付きデータが真正でない場合に、真正性が保証されるデータを取り出して、それを処理するための情報処理装置に送信することや、なぜ真正性が肯定されないようになったかの理由の解析の依頼を行なう処理など、図１３においてステップＳ１３０３において行なう処理のことである。「真正性を肯定するものでない場合の検証付きデータに対する処理のために必要となる情報」とは、真正性を肯定するものでない場合の検証付きデータに対する処理に必要となる情報であり、例えば、真正性が保証されるデータを取り出して、それを処理するための情報処理装置に送信するためのＩＰアドレス、ポート番号やＵＲＬ、あるいは、その情報処理装置にデータを送信するためのプログラムや、なぜ真正性が肯定されないようになったかの理由の解析の依頼を行なうための依頼先のＵＲＬ、電話番号、電子メールアドレス、依頼を行なうプログラムなど、ステップＳ１３０３の処理において必要となる情報である。
図２１は、図１４に示した情報処理装置の間で入出力されるデータに状態復帰情報が含まれている場合を説明するための図である。符号２１０１の範囲に示される部分が伝票作成端末１４０１によって製品管理サーバに入力されるデータを示す。製品管理サーバは、このデータに発送処理日時２１０４と、状態復帰情報であるメールアドレス′２１０５と、検証データ′２１０６とを追加し、符号２１０２の範囲に示されるデータを経理処理サーバ１４０３に送信する。経理処理サーバ１４０３は、経理処理日時２１０７と、状態復帰情報であるメールアドレス′′２１０８と、検証データ′′２１０９とを追加し、請求書作成サーバ１４０４へ送信する。
もし、請求書作成サーバ１４０４の伝票検証部１４１８により、符号２１０３の範囲のデータの真正性が肯定されなければ、請求書作成サーバ１４０４は、符号２１０２の範囲のデータを取り出し、真正性を判断する。もし、ここで真正性が肯定されれば、状態復帰情報であるメールアドレス′２１０５を用いて処理を行なう。例えば、メールアドレス′２１０５で示されるメールアドレスへデータを送る。もし、請求書作成サーバ１４０４の伝票検証部１４１８により、符号２１０２の範囲のデータの真正性も肯定されなければ、符号２１０１の範囲のデータを取り出し、真正性を検証することになる。符号２１０１の範囲に状態復帰情報があればそれに従った処理を行い、無ければ、エラー処理あるいは、その他のあらかじめ決められた処理を行なうことになる。
図１７は、本実施の形態における情報処理装置１７０１にデータ１７０２を入力して出力される検証付きデータを模式的に示すものである。出力される検証付きデータ１７０３は、処理済みデータ１７０５と処理済みデータの真正性を保証するための検証データ１７０４とから成る。処理済みデータ１７０５は、入力されたデータ１７０２と状態復帰情報１７０６とから構成されている。ここで注意しなければいけないのは、状態復帰情報１７０６は、検証データ１７０４により処理済みデータ１７０５の真正性が肯定されない場合に使われるのではないことである。なぜなら、処理済みデータ１７０５の真正性が肯定されないので、状態復帰情報１７０６も真正性が否定され得るためである。したがって、状態復帰情報１７０６が使用されるのは、検証付きデータ１７０３を含む検証付きデータの真正性が肯定されず、検証付きデータ１７０３の真正性が保証される場合である。すなわち、検証付きデータ１７０３が更に別の情報処理装置Ｘに入力され、検証付きデータ１７０３を含む処理済みデータが生成され、それに検証データを関連付けて得られる検証付きデータが出力されて、別の情報処理装置Ｙに入力されたときに、Ｙに入力された検証付きデータの真正性が肯定されず、その検証付きデータより取り出された検証付きデータ１７０３の真正性が肯定された場合に、状態復帰情報１７０６が使用される。
なお、状態復帰情報１７０６の真正性を保証する検証データが処理済みデータ１７０５に含まれるようにしておけば、検証データ１７０４により処理済みデータ１７０５の真正性が肯定されない場合であっても、状態復帰情報１７０６の検証データによって状態復帰情報１７０６の真正性が肯定されるのであれば、状態復帰情報１７０６を用いて処理を行なうようにすることも可能である。
図１８は、この状態復帰情報が使用される場合を説明するための図であり、データ１８０３が情報処理装置である二次原情報処理装置１８０１に入力されて検証付きデータ１８０６が得られたとする。検証付きデータは、処理済みデータ１８０５を含み、処理済みデータ１８０５には入力されたデータ１８０３と状態復帰情報１８０４が含まれている（図を簡単にするために検証データは図示されていない）。この検証付きデータ１８０６が更に別の情報処理装置である一次原情報処理装置１８０２に入力され、検証付きデータ１８０９が出力される。検証付きデータには処理済みデータ１８０８が含まれ、処理済みデータには、状態復帰情報１８０７と一次原情報処理装置１８０２に入力された検証付きデータ１８０６が含まれている。もし、この検証付きデータ１８０９が別の情報処理装置に入力され、真正性が肯定されないとする。すなわち、処理済みデータ１８０８の真正性が肯定されないとすると、その情報処理装置は、処理済みデータ１８０８に含まれる検証付きデータ１８０６を取り出し、この真正性が肯定されるかどうかを判断する。もし、この段階で真正性が肯定されれば、状態復帰情報１８０４を取り出し、状態復帰情報１８０４を用いて処理を行なう。例えば、状態復帰情報１８０４に一次原情報処理装置１８０２のＵＲＬが含まれている場合には、そのＵＲＬへ検証付きデータ１８０６を送信し、再度、一次原情報処理装置１８０２に処理を行なわせる。あるいは、どのような理由で検証付きデータ１８０９の真正性が肯定できないかを調査するために状態復帰情報１８０４に含まれる電子メールアドレスに検証付きデータ１８０９を送信する。あるいは、電話番号にダイアルアップを行って送信したりする。
図１９は、一次原情報処理装置１８０２の出力した検証付きデータ１８０９の真正性が肯定できない場合の処理の流れを説明するフローチャートであり、ステップＳ１９０１において、二次原情報処理装置１８０１の出力した検証付きデータ１８０６を、検証付きデータ１８０９より取り出す。
ステップＳ１９０２において、検証付きデータ１８０６の真正性が肯定できるかどうかを判断する。もし、肯定できるのであれば、ステップＳ１９０３に移行し、検証付きデータ１８０６の処理を行なう。例えば、検証付きデータ１８０６に含まれる状態復帰情報１８０４に基づいて処理を行なう。
もし、ステップＳ１９０２において、検証付きデータ１８０６の真正性が肯定できなければ、ステップＳ１９０４へ移行し、二次原情報処理装置を一次原情報処理装置とみなして処理を行なう。すなわち、データ１８０３を取り出し、その真正性を判断することになる。もし、データ１８０３が検証付きデータでなければエラーを報告したり、その他のあらかじめ定められた処理を行なうようにしたりなどする。
図２０は、図１９のフローチャートをより詳細にしたものである。このフローチャートでは、本発明の情報処理装置が検証付きデータを取得し、検証部によってその真正性が肯定されない場合の処理が説明されている。
ステップＳ２００１において、現在のデータに検証データが含まれるかどうかを判断する。図２０のフローチャートでは、真正性が肯定されないと、検証付きデータに含まれる処理済みデータからデータが取り出されて行くので、最後に検証データがないデータが取り出されてしまうことがあるので、ステップＳ２００１で、検証データがあるかどうかを判断する。もし、検証データがなければ、ステップＳ２００２へ移行し、エラー処理を行なう。なお、エラー処理のかわりに、その他のあらかじめ定められた処理を行なうようにしてもよい。
ステップＳ２００１において検証データがあると判断された場合には、ステップＳ２００３へ移行し、真正性が肯定されるかどうかを判断する。もし、真正性が肯定されれば、ステップＳ２００４へ移行し、状態復帰情報があるかどうかを判断する。もし、状態復帰情報があれば、ステップＳ２００５へ移行し、その状態復帰情報に基づいて処理を行なう。もし、状態復帰情報がなければ、ステップＳ２００６へ移行し、エラー処理を行なう。なお、エラー処理のかわりに、その他のあらかじめ定められた処理を行なうようにしてもよい。
ステップＳ２００３において真正性が肯定されなければ、ステップＳ２００７へ移行し、現在のデータから二次原情報処理装置の出力した検証付きデータを取り出し、それを現在のデータとしてステップＳ２００１へ戻る。
したがって、以上説明したように、本実施の形態において、検証部は、検証部で検証した真正性を肯定することができない検証付きデータを出力した情報処理装置である一次原情報処理装置に対して検証付きデータを出力した情報処理装置である二次原情報処理装置がある場合には、二次原情報処理装置の出力した検証付きデータの検証を行なうようにしてもよい。なお、「一次原情報処理装置」、「二次原情報処理装置」における「装置」とは、その処理における装置のことを言う。
また、二次原情報処理装置の出力した検証付きデータの検証結果が検証付きデータの真正性を肯定するものである場合には、状態復帰情報は、二次原情報処理装置の処理済みデータに含まれる状態復帰情報に基づいて二次原情報処理装置の出力した検証付きデータの処理を行なうための情報であってもよい。
このように処理済みデータに状態復帰情報を含ませることにより、検証付きデータの真正性が肯定されない場合の処理に必用となる情報を含ませることにより、真正性が肯定されない場合に動的に処理の内容を指定することが可能となる。このことは、処理の段階がデータによって変化する場合に特に有利な効果をもたらす。
なお、以上に述べた実施形態においては、具体的な例として伝票処理やチケット処理などを示したが、これらに限られるものはない。本発明により開示される処理検証やデータ修復（状態復帰）などが行なわれることが好ましい他の用途としては、例えば、以下に示すもの、及び、それ以外の様々なものを挙げることができる。
“コンテンツ配信サービス”：これは、コンテンツをネットワーク経由でユーザに配信するサービスである。このサービスの実現のためには、ユーザに販売するコンテンツのリストを提示する販売サーバと、課金処理を行なう課金サーバと、コンテンツの実データを保持しダウンロード処理を司る配信サーバと、がネットワーク上に分散配置されたシステム（コンテンツ配信システム）が用いられる。
このようなコンテンツ配信システムにおいては、販売サーバより検証データ付きのコンテンツのリストがユーザの端末に送信される。ユーザがコンテンツを選択すると、その選択結果がコンテンツのリストに付加された検証データ付きのデータとして課金サーバに送られる。課金サーバからは、課金が完了したことを示すデータが検証付きデータとして配信サーバへ送信され、配信サーバは、検証を行なうことで課金が完了したことを確認した後に、コンテンツをダウンロード可能とする。
また、状態復帰情報を用いることで、コンテンツのリストの提示、コンテンツの選択、課金、ダウンロードのいずれかの工程でエラーが起きた際に、適切な処理を行なうことが可能となる。
“検索データクリッピングサービス”：これは、エージェントプログラムが、ネットワーク上に分散配置されたデータベースを巡回し、ユーザによって支持された検索キーワードを用いた検索を行い、適切な情報を取得し、それらをマージしたり要約したりしてユーザに提示するサービスである。
例えば、エージェントプログラムが、それまでに取得したデータに対して、あるデータベースを検索することにより取得したデータを追加して処理済みデータとし、それに検証データを付加していくようにしてもよい。また、状態復帰情報を付加すれば、巡回の途中において、取得したデータの破損などが見つかった場合に、どのデータベースから再度巡回するべきかなどを検出できるようになる。“コンテンツ編集サービス（データ処理サービス）”：これは、ネットワーク上に配置された複数台のサーバごとに、コンテンツに特殊加工を施す機能を担当させ、このように機能を担当させたサーバ間でコンテンツを交換させることによって、所望の加工をコンテンツに施すようにするサービスである。
このサービスの実現のためには、例えば、コンテンツをエージェントプログラムに保持させ、コンテンツに対してどのような加工を施したいかをユーザがこのエージェントプログラムに提示し、その提示に従って、エージェントプログラムがサーバ間を移動する。その際、あるサーバが、コンテンツの加工の結果に状態復帰情報を付加するようにすることにすれば、もし、エージェントプログラムがサーバを移動している間にデータの破損などが見つかっても、エージェントプログラムやサーバは、破損などに応じた処理を行なうことができる。
産業上の利用可能性
以上のように本発明によれば、第一に、情報処理装置において、処理済みデータと検証データとを関連付けた検証付きデータを出力するようにすることにより、出力された検証付きデータを取得する装置は、検証付きデータの検証データにより処理済みデータの真正性を確認すればよいので、構造が簡略化され、また、装置のモジュール性が高まる。このような効果は、処理済みデータが処理の完了を示すデータであっても同様に得られる。
第二に、入力部がデータとして検証付きデータを入力することにより、処理が多段階に行なえるようになる。
第三に、情報処理装置が検証部を備えることにより、真正性が検証できないデータは処理がされないようになる。例えば、改竄、破損などにより正しくないデータを排除することができる。
第四に、処理部が入力部に入力された検証付きデータを含む処理済みデータを生成することにより、処理の履歴がわかり、検証付きデータの真正性が否定された場合に、真正性が肯定される処理まで遡ることができ、そこから処理を再開すればよいことになり、最初から処理をやり直す無駄が無くなる。また、無駄な通信も減ることになる。
第五に、処理済みデータに状態復帰情報を含ませることにより、検証付きデータの真正性が肯定されない場合の処理に必用となる情報を含ませることにより、真正性が肯定されない場合に動的に処理の内容を指定することが可能となる。このことは、処理の段階がデータによって変化する場合に特に有利な効果をもたらす。
【図面の簡単な説明】
図１は、実施の形態１における情報処理装置の機能ブロック図である。
図２は、実施の形態１における情報処理装置の別の機能ブロック図である。
図３は、処理済みデータから検証データの生成を説明する模式図である。
図４は、実施の形態１における情報処理装置の処理を説明するフローチャートである。
図５は、実施の形態１における情報処理装置の利用形態の一例図である。
図６は、ゲート制御装置の処理を説明するフローチャートである。
図７は、実施の形態１における情報処理装置の別の機能ブロック図である。
図８は、実施の形態１における情報処理装置の利用形態の一例図である。
図９は、実施の形態２における情報処理装置の利用形態の一例図である。
図１０は、実施の形態２における利用形態のシーケンス図である。
図１１は、実施の形態２における情報処理装置間で多段階に処理を行なう利用形態の一例図である。
図１２は、実施の形態３における情報処理装置の機能ブロック図である。
図１３は、実施の形態３における情報処理装置の処理を説明するフローチャートである。
図１４は、実施の形態３における情報処理装置の利用形態の一例図である。
図１５は、実施の形態４の情報処理装置間で入出力されるデータの一例図である。
図１６は、実施の形態４における出力部の動作を説明する図である。
図１７は、実施の形態５の概念図である。
図１８は、実施の形態５の概念図である。
図１９は、実施の形態５における情報処理装置の処理を説明するフローチャートである。
図２０は、実施の形態５における情報処理装置の処理を説明するフローチャートである。
図２１は、実施の形態５における情報処理装置の利用形態におけるデータを説明する図である。
【図１】
2003036866.tif 000003
【図２】
2003036866.tif 000004
【図３】
2003036866.tif 000005
【図４】
2003036866.tif 000006
【図５】
2003036866.tif 000007
【図６】
2003036866.tif 000008
【図７】
2003036866.tif 000009
【図８】
2003036866.tif 000010
【図９】
2003036866.tif 000011
【図１０】
2003036866.tif 000012
【図１１】
2003036866.tif 000013
【図１２】
2003036866.tif 000014
【図１３】
2003036866.tif 000015
【図１４】
2003036866.tif 000016
【図１５】
2003036866.tif 000017
【図１６】
2003036866.tif 000018
【図１７】
2003036866.tif 000019
【図１８】
2003036866.tif 000020
【図１９】
2003036866.tif 000021
【図２０】
2003036866.tif 000022
【図２１】
2003036866.tif 000023
【国際調査報告】
2003036866.tif 000024
2003036866.tif 000025