JP4036422B2

JP4036422B2 - Data transmission / reception system and data transmission / reception method

Info

Publication number: JP4036422B2
Application number: JP2001176382A
Authority: JP
Inventors: 純子廣田; 敏武内; 浩一山部
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2001-06-11
Filing date: 2001-06-11
Publication date: 2008-01-23
Anticipated expiration: 2017-12-05
Also published as: JP2002040934A

Description

【０００１】
【発明の属する技術分野】
本発明は、電子データで各種の書類を送付・受付し、該書類の送付・受付に伴う料金の支払いやその支払い受付を行なうデータ送信システム、およびデータ送受信方法に関する。
【０００２】
【従来の技術】
近年、インターネットのようなオープンなネットワーク環境において、各種の書類データの授受や商取引が行なわれるようになってきており、将来的にもさらに多種多様な形態になることが予測される。例えば、現在、特許庁への出願書類などの提出は、提出者が、直接、ダイヤルアップで特許庁のサーバに接続し提出書類データを送信することが可能になっているが、将来的にはインターネット経由で接続することが考えられる。一方、不動産登記や商業登記など、あるいは役所での住民票その他の証明書の発行業務などでは、申請する者が登記所や役所に直接出向いて書類（各種申請書）を提出して手続する必要があるが、このような業務も将来的にはインターネット経由で実施できるようになることが考えられる。
【０００３】
このようにインターネットなどを介して通信で電子的な書類提出を行なう場合、その書類提出に伴って手数料の支払いが必要なことがある。特許庁、登記所、あるいは役所などの官公庁に対して提出する書類では、印紙や証紙などを購入しそれを提出書類に貼付して提出する形態をとることが多いが、通信で書類提出を行なう場合には何らかの手数料支払いの仕組みが必要となる。特許庁の電子出願システムでは、あらかじめ書類提出者が予納口座に幾らかの金額を振込んでおき、特許庁の側のシステムでは出願を受け付けたときに当該予納口座から必要な金額を引き落とす形態を採る。
【０００４】
一方、いわゆる電子ショッピングなどと呼ばれている商取引では、インターネット経由で種々の商品を購入できるが、その支払いは、通常、クレジットカードや銀行口座からの引き落としで行なわれている。具体的には、商品を購入する者が、通信でクレジットカードや銀行口座の番号を送信し、商品を売る側ではその番号によってクレジットカードや銀行口座から所定の金額を引き落とす。また、近年ではＳＥＴ（Secure Electoronic Transaction）と呼ばれるインターネットの電子決済方式なども提案されている。
【０００５】
【発明が解決しようとする課題】
上述したようにインターネットなどを介して通信で電子的な書類提出を行なう際に手数料の支払いが必要な場合、特許庁の電子出願システムのような予納口座からの引き落としの方式では、書類提出を行なう者が必ず予納口座を作らなければならず不便である。不動産登記などの申請では、その書類提出を行なう者が生涯に１度しかその手続を行なわないことも考えられるので、そのためだけに予納口座を作るのは面倒である。
【０００６】
予納口座によらない支払方法としては、クレジットカードや銀行口座からの引き落としがあるが、その場合は、申請者が指定したクレジットカードや銀行口座から引き落とす処理を、通信による書類の提出受付け処理とは別フェーズで行なわなければならない。したがって、例えば口座に預金されている金額が引き落とし金額に満たないために引き落としができなくなるケースなどがある。
【０００７】
上述のＳＥＴのプロトコルによればインターネット上で電子決済できるが、これは商品を購入する者とその代金を支払う者が同じ者であって、商品購入の申込時に同時に決済を行なうことを前提としており、特許庁、登記所、あるいは役所などの官公庁に対して印紙や証紙などを貼付して書類を提出する形態の手続に適用するにはなじまない。そのような手続では、書類の申請者の代理人が申請者を代行して書類送付を行なう場合があるからである。すなわち、書類に添付する証紙や印紙などは書類の申請者が支払うべきものであり、一方、書類は代理人が提出するので、料金を支払う者と書類を提出する者とが異なることになり、その場合、書類の提出手続と関係付けつつＳＥＴのプロトコルで支払い手続を行なうことはできない。料金の支払いと書類の提出とを無関係に行なうのであれば、料金の支払いにＳＥＴのプロトコルを使用できるが、その場合は料金の支払い手続と書類の提出手続との関係付けがなされない。無理に関係付けようとすると、その分の手間がかかってしまう。
【０００８】
さらに、各種書類の提出に際して、その提出がいつ行なわれたかの日時を明確に確定することが必要な場合がある。一方、通信で書類提出を行なう場合は、通信回線の状態などに応じて再送が発生することがあり、書類の提出時点は明確でないという不都合がある。特に、書類の送信を開始した時点を書類の提出時点とした場合は、送信を開始して提出日時を確保した後、再送が発生したことを理由に後から別の内容の書類を送信し、その書類が前記提出日時に提出されたと主張するような悪用が可能になってしまう。したがって、通信で書類を提出する際の提出時点を合理的に確定する仕組みが求められている。
【０００９】
本発明は、上述の従来形における問題点に鑑み、インターネットなどを介して通信で電子的な書類提出を行なう際に手数料の支払いが必要な場合において、予納口座のような特別な口座を作る必要が無く、クレジットカードや銀行口座から別フェーズで引き落とし処理を行なうことも無く、また料金を支払う者と書類の提出を行なう者とが異なる場合でも適正に書類提出とその料金支払いを行なうことができるデータ送信システム、データ送信方法、データ送信装置、およびデータ受信装置を提供することを目的とする。
【００１０】
また、本発明は、通信で電子的な書類提出を行なう場合に、悪用を許すことなく、提出日時を合理的に決定する仕組みを備えたデータ送信システム、データ送信方法、データ送信装置、およびデータ受信装置を提供することを目的とする。
【００１１】
【課題を解決するための手段】
上記目的を達成するため、請求項１に係る発明は、所定の装置から他の装置へデータを送るデータ送受信システムであって、前記所定の装置は、送信すべき対象データに一方向関数を施し圧縮データとする手段と、前記対象データの送信に先立って、該圧縮データを前記他の装置へ送信する手段と、前記他の装置からチケットを受信した後、受信したチケットと前記対象データを前記他の装置に送信する手段とを有し、前記他の装置は、前記所定の装置から送信された圧縮データを所定の記憶手段に記憶すると共に、有効期限を含むチケットを前記所定の装置に返信する手段と、前記所定の装置から送信されるチケットおよび対象データを受信する手段と、受信したチケットの有効期限を取り出し、該チケット受信時点が該有効期限内であるか否か判定し、有効期間内でないと判定された場合にはチケット不正として以降の処理を行わないように制御する手段と、有効期限内であると判定された場合は、受信した対象データに一方向関数を施し圧縮データを生成する手段と、生成された前記圧縮データと前記記憶手段に記憶されている圧縮データとを比較し、前記比較によって圧縮データが一致した場合、前記対象データを、前記圧縮データを受信した時点で受け付けたものと認定する手段とを有することを特徴とする。
【００１３】
請求項２に係る発明は、所定の装置から他の装置へデータを送信するデータ送受信方法において、前記所定の装置が備える書類送付処理部の圧縮データ送付手段が、送信すべき対象データに一方向関数を施して圧縮データを生成し、生成した圧縮データを、前記対象データの送信に先立って、前記他の装置へ送信するステップと、前記他の装置が備えるチケット発行処理手段が、受信した圧縮データを所定の記憶手段に記憶したのち、前記所定の装置に、有効期限を含むチケットを送信するステップと、前記所定の装置が備える書類送付処理部の対象データ送付手段が、チケットを受信したら、受信したチケットと前記対象データを前記他の装置へ送信するステップと、前記他の装置が備える受信手段が、前記所定の装置から送信されるチケットおよび対象データを受信するステップと、前記他の装置が備える書類受付処理部のチケット有効期限検証手段が、受信したチケットの有効期限を取り出し、該チケット受信時点が該有効期限内であるか否か判定し、有効期間内でないと判定された場合にはチケット不正として以降の処理を行わないように制御するステップと、前記他の装置が備える書類受付処理部の圧縮データ検証手段が、前記チケットが有効期限内であると判定された場合、受信した対象データに一方向関数を施して生成した圧縮データと、前記記憶手段に記憶してある圧縮データとを比較し、それらの圧縮データの一致が確認できた場合、前記対象データを、前記圧縮データを受信した時点で受け付けたものと認定するステップとを備えたことを特徴とする。
【００１９】
【発明の実施の形態】
以下、図面を用いて、本発明の実施の形態を説明する。
【００２０】
図１は、本発明の一つの実施の形態の書類送付システムの全体図である。インターネット１１０に、書類受付サーバ１０１、支払い受付サーバ１０２、認証局１０３、代理人装置１０４、申請人装置１０５、金融機関サーバ１０６、および金融機関認証局１０７が接続されている。
【００２１】
図１のシステムにおける処理の流れの概要を説明する。特に、暗号化／復号化処理やディジタル署名処理の説明は除き（それらについては後にフローチャートを参照して説明する）、データの流れに着目した処理の流れを説明する。
【００２２】
申請人装置１０５は、所定の料金を支払って書類を提出したい申請人が操作する装置であり、代理人装置１０４は、その申請人を代理して書類提出（実際の書類送信）を行なう代理人が操作する装置である。提出する書類は、まず代理人が、申請人の依頼に応じて代理人装置１０４で作成する。作成した書類データは、申請人装置１０５に送信する。申請人は、受信した書類データの内容を確認し、該書類データを保存しておく。また、申請人は、申請人装置１０５から支払い受付サーバ１０２に接続し、料金支払い処理を行なう。
【００２３】
支払い受付サーバ１０２は、書類提出に伴う料金の支払いに関する処理を行なうサーバであり、申請人装置１０５からの料金支払い処理要求を受けたときには、金融機関サーバ１０６に接続して当該申請人の信用照会を実施した後、支払い証明書を申請人装置１０５に返送する。支払い証明書は、申請人が料金支払いを行なったこと（あるいは、行なうことが保証されたこと）を証明するデータであり、印紙や証紙に相当するデータであるが、詳しくは後述する。支払い証明書は、書類受付サーバ１０１および支払い受付サーバ１０２の両者で共通にアクセス可能な支払い証明書管理データベース（ＤＢ）で管理される。申請人は、申請人装置１０５によりその支払い証明書を受信し、保存してあった書類データに支払い証明書を付けて代理人装置１０４に送信する。代理人は、代理人装置１０４により、該データを受信し、いったん保管する。その後任意の時期に、代理人は、該データを書類受付サーバ１０１に送信する。
【００２４】
書類受付サーバ１０１は、代理人装置１０４から送信されてくる提出書類を受付るサーバである。書類受付サーバ１０１は、代理人から送信されたデータ（書類データに支払い証明書を付けたデータ）を受信し、支払い証明書を検証し書類データを保管する。支払い証明書の検証とは、当該支払い証明書が未使用のものであることを支払い証明書管理ＤＢに問い合わせ、未使用であったら使用済みにする処理である。
【００２５】
認証局１０３は、申請人や代理人の認証を行なうために使用する証明書を発行する認証局である。金融機関サーバ１０６は、申請人の口座が設けられている金融機関のサーバである。金融機関認証局１０７は、その口座を持つ申請人の認証を行なうために使用する証明書を発行する認証局である。
【００２６】
図２は、図１の書類受付サーバ１０１および支払い受付サーバ１０２の内部構成を示す。
【００２７】
書類受付サーバ１０１は、チケット発行処理部２１１、書類受付処理部２１２、署名生成部２１３、暗号化／復号化処理部２１４、および通信制御部２１５を備えている。支払いサーバ１０２は、支払い受付処理部２２１、署名生成部２２２、暗号化／復号化処理部、支払い証明書生成管理部２２４、ＳＥＴ処理部２２５、および通信制御部２２６を備えている。また、書類受付サーバ１０１および支払いサーバ１０２の両方からアクセスできる共通データベース（ＤＢ）として、受付管理ＤＢ２３１、鍵・証明書管理ＤＢ２３２、申請人・代理人管理ＤＢ２３３、および支払い証明書管理ＤＢ２３４を備えている。
【００２８】
書類受付サーバ１０１は、インターネット１１０を介して代理人装置１０４から送信されてくる書類を受付ける。書類受付処理部２１２は、その書類受付処理（図１８で詳しく説明する）を行なう。チケット発行処理部２１１は、書類受付処理を行なうにあたって、実際の書類データを受取る前にチケットを発行する処理（図１７で詳しく説明する）を行なう。チケットの発行は、書類提出日時を決定するための処理である。すなわち、代理人装置１０４から書類受付サーバ１０１に書類を送付する際に、実際に送付しようとするデータをそのまま送信すると、再送が発生してその書類提出時点があいまいになる恐れがあるので、以下の▲１▼〜▲４▼のように処理して悪用を防ぐものである。
▲１▼まず代理人装置１０４で、実際に送付しようとするデータを一方向関数で圧縮しメッセージダイジェストを求め、該メッセージダイジェストを書類受付サーバ１０１に送る。（なお、詳しくは証明書付で暗号通信を行なう。）
▲２▼書類受付サーバ１０１では、チケット発行処理部２１１によるチケット発行処理（図１７）で、新たな受付番号を取得し、該受付番号と該メッセージダイジェストを対応させて記憶するとともに、その受付番号を代理人装置１０４に送る。その受付番号を送るためのデータがチケットである。
▲３▼代理人装置１０４は、チケットにより受付番号を受取り、該受付番号を付けて実際に送付しようとするデータを、書類受付サーバ１０１に送る。
▲４▼書類受付サーバ１０１では、代理人装置１０４からのデータをすべて受信した後、そのデータを一方向関数（▲１▼で使用したのと同じ関数）で圧縮しメッセージダイジェストを求め、それが上記▲２▼で記憶してあるメッセージダイジェストと一致するか否かを確認する。一致すれば、チケット発行時に代理人装置１０４から実際に送付しようと意図していたデータが実際に受信されたことになる。一方、一致しなければ、別のデータが送信されてきたことになる。
【００２９】
図８に、本実施の形態のシステムで書類受付サーバ１０１から代理人装置１０４に送られるチケットの内容を示す。受付番号８０１は、代理人装置１０４から書類送付する際に、その書類送付に対応して書類受付サーバ１０１が新たに割当てる番号である。送信者情報８０２は、その書類を送付する送信者（代理人）を特定する種々の情報である。有効期限８０３は、このチケットの有効期限を示す。代理人装置１０４から書類送付する際に、再送が発生しても当該書類の送付に十分な時間だけ有効期限（チケット発行時から所定時間を取ればよい）を取っておけばよい。無制限に遅れて書類送付されることを防ぐため、有効期限８０３を決めてある。署名８０４は、８０１〜８０３のデータに対して書類受付サーバ１０１の署名を付したものである。
【００３０】
図９は、本実施の形態のシステムで使用する図１の受付管理ＤＢ２３１の内容を示す。書類受付サーバ１０１は、上記▲２▼のチケット発行処理（図１７）で新たな受付番号を取得する際に、この受付管理ＤＢ２３１上で新たな受付番号を取得し、その受付番号に対応する１行分の領域を確保する。受付番号９０１、送信者情報９０２、および有効期限９０３には、送信したチケット（図８）に設定した情報８０１〜８０３と同内容を記憶しておく。メッセージダイジェスト９０４、および送信者証明書９０５には、上記▲１▼で代理人装置１０４から送られてくる情報を記憶しておく。また、チケット管理情報９０６は、当該チケットが使用されたか否かのフラグ情報を記憶するもので、初期値は「未使用」にしておく。書類の内容９０７は、代理人装置１０４から送られてくる書類の全体を記憶しておく領域である。上記▲４▼でメッセージダイジェストの一致確認がなされたら、チケット管理情報９０６を「使用済み」とし、受信した書類データを書類の内容９０７に記憶するものである。
【００３１】
再び、図２に戻って、書類受付サーバ１０１の構成の説明を続ける。署名生成部２１３および暗号化／復号化処理部２１４は、書類受付処理を行なうにあたって、送受するデータに署名を付すとき、および暗号化／復号化処理を行なうときに使用する。通信制御部２１５は、インターネット１１０との間の通信制御を行なう。
【００３２】
支払い受付サーバ１０２は、申請人からの料金支払いを受付ける。この実施の形態のシステムでは、申請人は申請人装置１０５から支払い受付サーバ１０２に接続して、料金支払い処理を行なうことができる。支払い受付処理部２２１は、その申請人からの料金支払い要求を受付ける処理（図１３で詳しく説明する）を行ない、申請人が料金支払いを行なったこと（あるいは支払うことが保証されたこと）を示す支払い証明書を申請人に発行する。支払い証明書は、印紙や証紙、あるいは金券や商品券のような役割を果たすものである。支払い証明書の発行は、当該申請人について金融機関に対して支払い信用照会を行なった上で発行するようになっているので、書類受け付けサーバ１０１および支払い受付サーバ１０２の運営機関は、支払い証明書を発行した金額については必ず当該申請人の口座から引き落としができる。また、支払い証明書は、予納とは異なり、あらかじめ予納口座を開く必要はない。支払い証明書は、印紙のように、別件に使用したり他人に贈与してもよい。
【００３３】
図６に、本実施の形態のシステムで用いる支払い証明書の内容を示す。支払い証明書は、管理番号６０１、支払い金額６０２、申請人情報６０３、有効期限６０４、および支払い受付サーバ１０２の署名６０５を備えている。管理番号６０１は、支払い証明書に固有の管理番号である。支払い金額６０２は、申請人が支払うことを指定した金額の情報である。申請人情報６０３は、支払い要求を出して当該支払い証明書を受け取った申請人を特定する情報である。有効期限６０４は、当該支払い証明書の有効期限である。署名６０５は、当該支払い証明書を発行した支払い受付サーバ１０２の署名であり、これにより当該支払い証明書が確かに支払い受付サーバ１０２から発行されたことが保証される。これらの情報６０１〜６０５は、支払い受付サーバ１０２が当該支払い証明書を発行する際に設定するものである。
【００３４】
図７は、本実施の形態のシステムで使用する図１の支払い証明書管理ＤＢ２３４の内容を示す。支払い受付サーバ１０２は、発行した支払い証明書を、この支払い証明書管理ＤＢ２３４で管理する。支払い証明書管理ＤＢ２３４の７０１〜７０５には、発行した支払い証明書の６０１〜６０５の情報を記憶しておく。しよう状態７０６は、当該支払い証明書が使用されているか否かを示すフラグである。書類受付サーバ１０１が書類を受付けたとき、その書類に付いてきた支払い証明書の管理番号６０１で支払い証明書管理ＤＢ２３４を検索し、対応するエントリを探す。そのエントリの使用状態７０６が「未使用」であれば、その支払い証明書は未だ使用されていなかったものであるから、その使用状態７０６を「使用済み」とする。これは印紙や証紙などの貼付を確認することに相当するものである。再度同じ支払い証明書を使った書類が送付されてきたときは、使用状態７０６が「使用済み」であるので、料金支払いが保証されていないことが確認される。
【００３５】
図７のような支払い証明書管理ＤＢ２３４で支払い証明書を管理しているので、料金を支払う申請人と書類の送付を実際に実行する代理人とが異なる場合でも手続できる。また、支払い証明書を他人に譲渡して、その他人が使用することもできる。
【００３６】
再び、図１に戻って、支払い受付サーバ１０２の構成の説明を続ける。署名生成部２２２および暗号化／復号化処理部は、支払い受付処理を行なうにあたって、送受するデータに署名を付すとき、および暗号化／復号化処理を行なうときに使用する。支払い証明書生成管理部２２４は、図６の構成の支払い証明書を生成し、図７の支払い証明書管理ＤＢ２３４で管理する処理を行なう。ＳＥＴ処理部２２５は、支払い受付サーバ１０２から金融機関サーバ１０６に対して申請人の信用照会を行なう際にＳＥＴプロトコルにしたがう処理を行なう。通信制御部２２６は、インターネット１１０との間の通信制御を行なう。
【００３７】
書類受付サーバ１０１および支払いサーバ１０２の両方からアクセスできる共通ＤＢである受付管理ＤＢ２３１および支払い証明書管理ＤＢ２３４については、図９および図７により説明した。鍵・証明書管理ＤＢ２３２は、この書類受付サーバ１０１および支払いサーバ１０２の秘密鍵、公開鍵、および認証局１０３，１０７から発行してもらった証明書、認証を行なう際に使用する認証局１０３，１０７の公開鍵、並びに、通信相手の公開鍵などを管理するＤＢである。申請人・代理人管理ＤＢ２３３は、この書類受付サーバ１０１および支払いサーバ１０２に接続してくる申請人や代理人に関する情報を管理するＤＢである。
【００３８】
なお、この実施の形態では、書類受付サーバ１０１と支払いサーバ１０２とを別装置で分け、共通ＤＢ２０３を共通に使用するような構成としたが、共通ＤＢとせず、完全にＤＢを分けて構成してもよい。その場合は、受付管理ＤＢ２３１は書類受付サーバ１０１で管理し、支払い証明書管理ＤＢ２３４は支払い受付サーバ１０２で管理すればよい。逆に、書類受付サーバ１０１および支払いサーバ１０２をＤＢ２０３も含めて１台の装置上に構成してもよい。その場合は、通信制御部、署名生成部、暗号化／復号化処理部などは共通の構成としてもよい。
【００３９】
図３は、図１の認証局１０３の構成を示す。認証局１０３は、証明書発行処理部３０１、証明書管理部３０２、通信制御部３０４、および証明書管理ＤＢ３１１を備えている。認証局１０３は、あらかじめ代理人や申請人に証明書を発行する。
【００４０】
図４は、図１の代理人装置１０４の構成を示す。代理人装置１０４は、申請書エディタ４０１、署名生成部４０２、暗号化／復号化処理部４０３、書類送付処理部４０４、書類受取り処理部４０５、通信制御部４０６、申請書管理ＤＢ４１１、および鍵・証明書管理ＤＢ４１２を備えている。
【００４１】
申請書エディタ４０１は、送付する書類を作成するために使用するエディタである。書類送付処理部４０４は、申請人装置１０５に書類を送付する処理（図１０で詳しく説明する）や、書類受付サーバ１０１に支払い証明書付き書類を送付する処理（図１６で詳しく説明する）を行なう。書類受取り処理部４０５は、申請人から送られてくる支払い証明書付き書類の受取り処理（図１５で詳しく説明する）を行なう。署名生成部４０２および暗号化／復号化処理部４０３は、送受するデータに署名を付すとき、および暗号化／復号化処理を行なうときに使用する。通信制御部４０６は、インターネット１１０との間の通信制御を行なう。
【００４２】
申請書管理ＤＢ４１１は、申請書エディタ４０１で作成した書類や、申請人から送られてくる支払い証明書付き書類を保存して管理するＤＢである。鍵・証明書管理ＤＢ４１２は、この代理人装置１０４の秘密鍵、公開鍵、および認証局１０３，１０７から発行してもらった証明書、認証を行なう際に使用する認証局１０３，１０７の公開鍵、並びに、通信相手の公開鍵などを管理するＤＢである。
【００４３】
図５は、図１の申請人装置１０５の構成を示す。申請人装置１０５は、書類受取り処理部５０１、受取り書類管理部５０２、暗号化／復号化処理部５０３、署名生成部５０４、支払い処理部５０５、書類送付処理部５０６、支払い証明書管理部５０７、通信制御部５０８、申請書管理ＤＢ５１１、鍵・証明書管理ＤＢ５１２、および支払い証明書管理ＤＢ５１３を備えている。
【００４４】
書類受取り処理部５０１は、代理人から送られてくる書類の受取り処理（図１１で詳しく説明する）を行なう。支払い処理部５０５は、支払い受付サーバ１０２に接続して支払いを行なう処理（図１２で詳しく説明する）を行なう。書類送付処理部５０６は、代理人に対して支払い証明書付き書類などを送付する処理（図１４で詳しく説明する）を行なう。署名生成部５０４および暗号化／復号化処理部５０３は、送受するデータに署名を付すとき、および暗号化／復号化処理を行なうときに使用する。支払い証明書管理部５０７は、支払い受付サーバ１０２から発行してもらった支払い証明書を支払い証明書管理ＤＢ５１３で管理する処理を行なう。通信制御部５０８は、インターネット１１０との間の通信制御を行なう。
【００４５】
申請書管理ＤＢ５１１は、代理人から送られてくる書類などを保存して管理するＤＢである。鍵・証明書管理ＤＢ５１２は、この申請人装置１０５の秘密鍵、公開鍵、および認証局１０３，１０７から発行してもらった証明書、認証を行なう際に使用する認証局１０３，１０７の公開鍵、並びに、通信相手の公開鍵などを管理するＤＢである。支払い証明書管理ＤＢ５１３は、支払い受付サーバ１０２から発行してもらった支払い証明書を保存して管理するＤＢである。その構成は、図７で説明した支払い受付サーバ１０２の支払い証明書管理ＤＢ２３４と同じである。ただし、支払い証明書管理ＤＢ５１３は、この申請人が受け取った支払い証明書を管理するものであり、使用状態７０６はこの申請人が使用したか否かを示す情報である。
【００４６】
次に、図１０〜図１８のフローチャートを参照して、図１のシステムにおける各処理の詳細を説明する。
【００４７】
図１０は、代理人装置１０４から申請人装置１０５への書類送付の流れを示すフローチャートである。この処理は、主として図４の書類送付処理部４０４による処理である。まず代理人は、申請人の依頼に基づいて、図４の申請書エディタ４０１を用いて書類を作成しておく。ステップ１００１で、送付する該書類に対して代理人の電子署名を実施する。具体的には、書類データを一方向関数（ハッシュ関数など）で圧縮し、その圧縮データ（メッセージダイジェスト）を代理人の秘密鍵で暗号化した署名データを、元の書類データに付して、代理人署名付き書類を作る。次に、ステップ１００２で、代理人署名付き書類を暗号化する共通鍵を生成し、その共通鍵で代理人署名付き書類を暗号化する。次に、ステップ１００３で、申請人の公開鍵によって前記共通鍵を暗号化する。ステップ１００４では、暗号化された代理人署名付き書類と共通鍵を、代理人の証明書と共に申請人装置１０５に送信し、処理を終了する。
【００４８】
なお、代理人の証明書は、あらかじめ認証局１０３から取得しておく。代理人の証明書とは、代理人の公開鍵を該代理人に関する種々の情報と連結し、該連結データに対し認証局１０３の秘密鍵で署名を付したデータである。認証局１０３は、代理人から証明書発行依頼を受けたとき、当該代理人の身元確認を行なった後、証明書を発行する。代理人装置１０４から送信するデータにこの証明書を付ければ、当該データが確かに当該代理人から送られたものであることを、この証明書によって検証することができ、またこの証明書から代理人の公開鍵や代理人を特定する種々の情報を取得することができる。同様にして、申請人も、あらかじめ認証局１０３から証明書を取得しておく。
【００４９】
図１１は、図１０の処理により代理人装置１０４から申請人装置１０５へ送られたデータを受取る申請人装置１０５の処理の流れを示す。この処理は、主として図５の書類受取り処理部５０１による処理である。まずステップ１１０１で、受信データ中の代理人の証明書を検証するとともに、受信データ中の暗号化された共通鍵を申請人の秘密鍵を用いて復号化する。ステップ１１０２で、復号化された共通鍵を用いて、代理人署名付き書類を復号化する。ステップ１１０３では、その代理人署名付き書類の署名を代理人の公開鍵を用いて検証する。この検証は、署名データを代理人の公開鍵で復号化した値が、書類データを一方向関数（図１０のステップ１００１で使用したのと同じ関数を用いる）で圧縮した圧縮データ（メッセージダイジェスト）に等しくなるか否かを確認する処理である。検証の結果、適正な署名であったら、ステップ１１０５で当該代理人署名付き書類を保管する。検証の結果、適正な署名でなかったら、ステップ１１０６で申請書類が改ざんされていることを申請人に報告して、処理を終了する。
【００５０】
図１２は、申請人による料金支払い処理の流れを示すフローチャートである。この処理は、主として図５の支払い処理部５０５による処理である。まずステップ１２０１で、申請人装置１０５から支払い受付サーバ１０２に接続し、支払い金額を決定・送信する。ステップ１２０２で、申請人の証明書（認証局１０３から取得した証明書）を支払い受付サーバ１０２に提示する。ステップ１２０３は、支払い受付サーバ１０２側の処理であり、図１３で後述するが、支払い受付サーバ１０２からは、申請人の公開鍵で暗号化された共通鍵と該共通鍵で暗号化された支払い証明書（図６）が送信されてくる。ステップ１２０４では、支払い受付サーバ１０２から送信された暗号化された共通鍵を申請人の秘密鍵で復号化する。ステップ１２０５では、復号化された共通鍵を用いて、暗号化された支払い証明書を復号化する。ステップ１２０６で、復号化された支払い証明書を、支払い証明書管理ＤＢ５１３（図７）に保管して、処理を終了する。
【００５１】
図１３は、図１２のステップ１２０３の処理、すなわち支払い受付サーバ１０２における支払い受付処理の流れを示すフローチャートである。この処理は、主として図２の支払い受付処理部２２１による処理である。まず、ステップ１３０１で、申請人から送られた証明書を検証し、申請人の公開鍵を取得する。次にステップ１３０２で、例えばＳＥＴのプロトコルを用いて、申請人からの支払い信用照会（与信）を金融機関に対して実施する。具体的には、図１の金融機関サーバ１０６に申請人と引き落とし金額を特定する情報を送信し、該申請人の口座からその引き落とし金額分を確保する。
【００５２】
なお、金融機関に対して支払い信用照会を実施する際、支払い受付サーバ１０２を運営する機関の身元を証明するため、あらかじめ支払い受付サーバ１０２を運営する機関は、金融機関認証局１０７から証明書を取得しておく必要がある。また、この支払い信用照会では、引き落としを行なう申請人についての認証も行なうので（確かにその申請人からの引き落とし依頼であるかどうかを確認する必要がある）、あらかじめ申請人は金融機関認証局１０７から証明書を取得しておくとともに、その金融機関の証明書をステップ１２０２で支払い受付サーバ１０２に送り、支払い受付サーバ１０２はステップ１３０２で信用照会するときその申請人の金融機関の証明書を付けて信用照会する必要がある。
【００５３】
ステップ１３０２の信用照会の結果、ステップ１３０３で、上記引き落とし金額分の引き落とし枠が確保できたらステップ１３０４に進む。信用照会結果に何らかの問題があったら、処理を終了する。ステップ１３０４では、新たに発行する支払い証明書の管理番号を取得する。具体的には、図７の構成の支払い証明書管理ＤＢ２３４で新規管理番号の一行分の領域を確保する。次に、ステップ１３０５で、申請人の証明書から申請人を特定する情報を抽出する。ステップ１３０６では、管理番号、支払い金額、申請人を特定する情報、および有効期限を連結したデータに電子署名を実施して、支払い証明書（図６）を作成する。具体的には、上記連結データを一方向関数（ハッシュ関数など）で圧縮し、その圧縮データを支払い受付サーバ１０２の秘密鍵で暗号化した署名データを、元の連結データに付して、支払い証明書を作る。
【００５４】
ステップ１３０７では、作成した支払い証明書に含めた情報を支払い証明書管理ＤＢ２３４（図７）に記録する。そして、ステップ１３０８で、支払い証明書を暗号化するための共通鍵を生成し、その共通鍵で支払い証明書を暗号化する。次に、ステップ１３０９で、申請人の公開鍵によって前記共通鍵を暗号化する。ステップ１３１０では、暗号化された共通鍵と該共通鍵で暗号化された支払い証明書とを申請人装置１０５に送信し、処理を終了する。
【００５５】
図１４は、申請人装置１０５から代理人装置１０４への書類送付の流れを示すフローチャートである。この処理は、主として図５の書類送付処理部５０６による処理である。まずステップ１４０１で、図１１のステップ１１０５で保管してある代理人署名付き書類を取り出す。ステップ１４０２では、代理人署名付き書類と支払い証明書とを含めたデータに対して、申請人の電子署名を実施する。これを支払い証明書付き書類と呼ぶ。なお、ここで使用する支払い証明書は、図７の構成の支払い証明書管理ＤＢ５１３で管理されている支払い証明書のうち、使用状況７０６が「未使用」のものを使用する。使用した支払明細書の使用状況７０６は「使用済み」に変更しておく。
【００５６】
次に、ステップ１４０３で、共通鍵を生成し、該共通鍵で支払い証明書付き書類を暗号化する。ステップ１４０４で、代理人の公開鍵を用いて、前記共通鍵を暗号化する。ステップ１４０５では、暗号化された共通鍵と該共通鍵で暗号化された支払い証明書付き書類を代理人装置１０４に送信する。
【００５７】
図１５は、図１４で送信された申請人からのデータを受取る代理人装置１０４の処理の流れを示すフローチャートである。この処理は、主として図４の書類受取り処理部４０５による処理である。まずステップ１５０１で、受信データ中の暗号化された共通鍵を代理人の秘密鍵を用いて復号化する。ステップ１５０２で、復号化された共通鍵を用いて、支払い証明書付き書類を復号化する。ステップ１５０３では、その支払い証明書付き書類に添付されている申請人の電子署名を申請人の公開鍵を用いて検証する。この検証は、署名データを申請人の公開鍵で復号化した値が、支払い証明書付き書類を一方向関数（図１４のステップ１４０２の署名で使用したのと同じ関数）で圧縮した圧縮データに等しくなるか否かを確認する処理である。
【００５８】
ステップ１５０４で、検証の結果、適正な署名であったら、ステップ１５０６に進む。ステップ１５０６では、支払い証明書付き書類に含まれている支払い証明書の電子署名を支払い受付サーバ１０２の公開鍵を用いて検証する。この検証は、署名データを支払い受付サーバ１０２の公開鍵で復号化した値が、支払い証明書に含まれている管理番号、支払い金額、申請人を特定する情報、および有効期限を連結したデータを一方向関数（図１３のステップ１３０６の署名で使用したのと同じ関数）で圧縮した圧縮データに等しくなるか否かを確認する処理である。
【００５９】
ステップ１５０７で、検証の結果、適正な署名であったら、ステップ１５０９に進む。ステップ１５０９では、支払い証明書付き書類に含まれている代理人署名付き書類中の代理人の署名を、代理人の秘密鍵を用いて検証する。ステップ１５１０で検証結果が適正な署名であったら、ステップ１５１２で支払い証明書付き書類を保管して、処理を終了する。ステップ１５０４，１５０７，１５１０の何れかのステップで、検証結果が不正な署名であることを示していたら、それぞれ、ステップ１５０５，１５０８，１５１１で書類が改ざんされていることを代理人に報告して、処理を終了する。
【００６０】
図１６は、代理人装置１０４から書類受付サーバ１０１への支払い証明書付き書類の送付処理の流れを示すフローチャートである。この処理は、主として図４の書類送付処理部４０４による処理である。まずステップ１６０１で、送付しようとする支払い証明書付き書類を一方向関数で圧縮し、圧縮データ（メッセージダイジェスト）を生成する。次に、ステップ１６０２で、共通鍵を生成し、該共通鍵で上記メッセージダイジェストを暗号化する。ステップ１６０３では、上記共通鍵を書類受付サーバ１０１の公開鍵で暗号化する。ステップ１６０４では、暗号化された共通鍵と該共通化鍵で暗号化されたメッセージダイジェストに、代理人の証明書を添付して書類受付サーバ１０１に送付する。ステップ１６０５は、書類受付サーバ１０１側のチケット発行処理であり、図１７で後述するが、書類受付サーバ１０１からは、代理人の公開鍵で暗号化された共通鍵（書類受付サーバ１０１側で生成した鍵）と該共通鍵で暗号化されたチケット（図８）が送信されてくる。
【００６１】
ステップ１６０６では、書類受付サーバ１０１から送られてきた暗号化された共通鍵を、代理人の秘密鍵を用いて復号化する。ステップ１６０７では、復号化された共通鍵を用いてチケットを復号化する。次に、ステップ１６０８で、書類受付サーバ１０１の公開鍵を用いて、チケット（図８）に付いている電子署名を検証する。ステップ１６０９で、検証結果が適正な署名であることを示していたら、書類受付サーバ１０１が提出日時を確保したということであるから、ステップ１６１１に進む。ステップ１６０９で、不正な署名であったら、ステップ１６１０でチケットが改ざんされていることを代理人に報告し、処理を終了する。
【００６２】
チケットが取れたら、ステップ１６１１で共通鍵を生成し、ステップ１６１２で支払い証明書付き書類を該共通鍵で暗号化する。ステップ１６１３では、該共通鍵でチケットを暗号化する。次に、ステップ１６１４で、書類受付サーバ１０１の公開鍵で上記共通鍵を暗号化する。そして、ステップ１６１５で、暗号化した共通鍵、および該共通鍵で暗号化したチケットと支払い証明書付き書類を書類受付サーバ１０１に送付する。ステップ１６１６は、書類受付サーバ１０１側の処理であり、図１８で後述するが、書類受付サーバ１０１からは、代理人の公開鍵で暗号化された共通鍵と該共通鍵で暗号化された受付確認書が送信されてくる。
【００６３】
ステップ１６１７では、書類受付サーバ１０１から送信された暗号化された共通鍵を代理人の秘密鍵で復号化する。ステップ１６１８では、復号化された共通鍵を用いて、暗号化された受付確認書を復号化する。ステップ１６１９で、受付確認書に添付された書類受付サーバ１０１の電子署名を検証する。ステップ１６２０で検証結果が適正な署名であることを示していたら、ステップ１６２２で、受付確認書を保管して、処理を終了する。ステップ１６２０で、検証結果が不正な署名であることを示していたら、ステップ１６２０で何らかのデータ改ざんがなされたことを代理人に報告し、処理を終了する。
【００６４】
図１７は、図１６のステップ１６０５の処理、すなわち書類受付サーバ１０１のチケット発行処理の流れを示すフローチャートである。この処理は、主として図２のチケット発行処理部２１１による処理である。まずステップ１７０１で、書類受付サーバ１０１の秘密鍵を用いて、代理人から送られてきた共通鍵を復号化する。次に、ステップ１７０２で、該共通鍵を用いてメッセージダイジェストを復号化する。そして、ステップ１７０３で、新たな受付番号を取得し、該受付番号９０１、代理人（送信者）に関する情報９０２、有効期限９０３、メッセージダイジェスト９０４、および代理人の証明書９０５を、受付管理ＤＢ２３１（図９）に保管する。なお、代理人に関する情報は、代理人から送られてきたデータに含まれている代理人の証明書から抽出した情報を設定する。有効期限は、現時点に所定時間を加えた時間を設定する。また、チケットの管理情報９０６は「未使用」に初期化しておく。
【００６５】
次に、ステップ１７０４では、受付番号と、代理人に関する情報と、有効期限とを連結したデータを生成し、該連結データに対して電子署名を実施する。この電子署名付きデータがチケット（図８）である。具体的には、上記連結データを一方向関数（図１６のステップ１６０１や１６０８で用いたのと同じ関数）で圧縮し、その圧縮データを書類受付サーバ１０１の秘密鍵で暗号化した署名データを、元の連結データに付して、チケット（図８）を作る。次に、ステップ１７０５で、共通鍵を生成し、該共通鍵で上記チケットを暗号化する。ステップ１７０６では、代理人の公開鍵を用いて、上記共通鍵を暗号化する。ステップ１７０７で、暗号化された共通鍵、および該共通鍵で暗号化されたチケットを代理人に対して送付し、処理を終了する。
【００６６】
図１８は、図１６のステップ１６１６の処理、すなわち書類受付サーバ１０１による書類受付処理の流れを示すフローチャートである。この処理は、主として図２の書類受付処理部２１２により実行される処理である。まずステップ１８０１で、書類受付サーバ１０１の秘密鍵を用いて、代理人から送られてきた共通鍵を復号化する。ステップ１８０２で、復号化された共通鍵を用いて、チケットと支払い証明書付き書類を復号化する。次に、ステップ１８０３で、チケットに付いている電子署名、および有効期限を検証する。検証の結果、ステップ１８０４で、署名も適正で有効期限内であるときは、ステップ１８０６に進む。署名が不正、または有効期限が過ぎていた場合は、ステップ１８０５でチケット不正を表示して、処理を終了する。
【００６７】
ステップ１８０６では、代理人から送付されてきた支払い証明書付き書類を、代理人装置１０４で使用した一方向関数（図１６のステップ１６０１や１６０８で用いたのと同一の関数）で圧縮し、メッセージダイジェストを生成する。ステップ１８０７では、代理人から送付されてきたチケットから受付番号を取り出し、受付管理ＤＢ２３１（図９）を参照して、当該受付番号に対応するチケット請求時のメッセージダイジェストを取り出し、ステップ１８０６で生成したメッセージダイジェストと比較する。比較の結果、ステップ１８０８で同一であれば、確かにチケット請求時に送ろうとしていた内容が送られてきたものと認められるので、ステップ１８１０に進む。ステップ１８０８で比較の結果が同一でないときは、チケット請求時に送ろうとしていた内容と別の内容が送られてきたということだから、ステップ１８０９で送付データ不一致の表示を行ない、処理を終了する。
【００６８】
ステップ１８１０では、支払い証明書に含まれている管理番号のデータを支払い証明書管理ＤＢ２３４（図７）から検索し、その使用状況７０６が「未使用」であるか否かを検証する。ステップ１８１１で、「未使用」であったときは、ステップ１８１３で、支払い証明書管理ＤＢ２３４の当該管理番号の支払い証明書の使用状況７０６を「使用済み」に変更する。次に、ステップ１８１４で、当該受付番号のチケットの管理情報９０６を「使用済み」に変更する。そして、ステップ１８１５で、支払い証明書付き書類を保管する。書類の保管は、図９の受付管理ＤＢ２３１の書類の内容９０７に格納することにより行なう。
【００６９】
さらに、ステップ１８１６で、受付番号などの受付情報を含む受付確認書を作成し、電子署名を実行する。ステップ１８１７で、共通鍵を生成し、該共通鍵で上記電子署名付き受付確認書を暗号化する。ステップ１８１８では、代理人の公開鍵で上記共通鍵を暗号化する。ステップ１８１９で、暗号化した共通鍵、および該共通鍵で暗号化した電子署名付き受付確認書を代理人に送付して、処理を終了する。
【００７０】
上記実施の形態のシステムによれば、申請人が支払い証明書を取得し、代理人が提出書類に支払い証明書を付けて、書類受付サーバに送付することが可能になる。支払い証明書は、印紙や証紙、金券や商品券のようなイメージで使用することができ、支払い受付サーバの署名が付いているので容易に改ざんされない。実際の決済はどのような形態で行なってもよいが、与信の段階で引き落とし可能であることが保証されるので、書類受付サーバの側では必ず料金を徴収できる。また、申請人が書類に支払い証明書を付けて、その全体に署名を付して、代理人に送っているので、申請人が当該書類の内容で了解しているという意志表示をしたことになるし、その後代理人が書類を改ざんすることもできない。
【００７１】
さらに、書類提出時点を決定する際、始めに提出者から送付しようとする書類データを一方向関数で圧縮してメッセージダイジェストを求め、これを証明書と一緒に書類受付サーバに送り、書類受付サーバではそのメッセージダイジェストを記憶して、チケットを返す。その後、提出者から書類データの全体が送られてきたときには、そのメッセージダイジェストを求めて、チケット発行時に記憶してあるメッセージダイジェストと比較することで、当初から送る予定の書類が確かに送られてきたことを確認できる。そのため、チケット発行時を書類提出時点とみなすことができるようになる。
【００７２】
なお、上記実施の形態では、代理人が申請者を代理して書類提出を行なう例を説明したが、代理人経由でなく、直接、申請人が書類受付サーバに対する書類送付を行なうようにしてもよい。
【００７３】
また、上記実施の形態では、支払方式としてＳＥＴを用いた例を説明したが、ＳＥＴ以外の支払方式、例えばＳＥＴを使わないクレジットカード支払いの方式などを用いてもよい。
【００７４】
本発明は、特許庁、登記所、あるいは役所などの官公庁に対してインターネット経由で書類を送付する場合などに適用可能である。また、いわゆる電子ショッピングなどに適用することも可能である。
【００７５】
【発明の効果】
以上説明したように、本発明によれば、書類を送付する前に、送付する書類を一方向関数で圧縮した圧縮データを送り、あとで実際に送られてきた書類に対して同じ一方向関数で圧縮した圧縮データと比較確認しているので、通信で電子的な書類提出を行なう場合に、悪用を許すことなく、提出日時を合理的に決定する仕組みが提供される。また、チケットには有効期限が含まれるので、チケットを利用する上で有効期限を有効に利用できる。
【図面の簡単な説明】
【図１】本発明の実施の形態の書類送付システムの全体図
【図２】書類受付サーバおよび支払い受付サーバの内部構成図
【図３】認証局の構成図
【図４】代理人装置の構成図
【図５】申請人装置の構成図
【図６】本実施の形態のシステムで用いる支払い証明書の内容を示す図
【図７】本実施の形態のシステムで使用する支払い証明書管理ＤＢの内容を示す図
【図８】本実施の形態のシステムで書類受付サーバから代理人装置に送られるチケットの内容を示す図
【図９】本実施の形態のシステムで使用する受付管理ＤＢの内容を示す図
【図１０】代理人装置から申請人装置への書類送付の流れを示すフローチャート図
【図１１】代理人装置から申請人装置へ送られたデータを受取る申請人装置の処理の流れを示すフローチャート図
【図１２】申請人による料金支払い処理の流れを示すフローチャート図
【図１３】支払い受付サーバにおける支払い受付処理の流れを示すフローチャート図
【図１４】申請人装置から代理人装置への書類送付の流れを示すフローチャート図
【図１５】申請人からのデータを受取る代理人装置の処理の流れを示すフローチャート図
【図１６】代理人装置から書類受付サーバへの支払い証明書付き書類の送付処理の流れを示すフローチャート図
【図１７】書類受付サーバのチケット発行処理の流れを示すフローチャート図
【図１８】書類受付サーバによる書類受付処理の流れを示すフローチャート図
【符号の説明】
１０１…書類受付サーバ、１０２…支払い受付サーバ、１０３…認証局、１０４…代理人装置、１０５…申請人装置、１０６…金融機関サーバ、１０７…金融機関認証局、１１０…インターネット。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a data transmission system for sending / receiving various documents as electronic data, and for paying a fee associated with sending / receiving the document and for receiving the payment, and Data transmission Reception method About.
[0002]
[Prior art]
In recent years, in the open network environment such as the Internet, various kinds of document data have been exchanged and commercial transactions have been carried out, and it is predicted that there will be various forms in the future. For example, it is now possible for applicants to submit application documents to the JPO by dialing up directly by connecting to the JPO server and sending the submitted document data. It is possible to connect via the Internet. On the other hand, in the real estate registration, commercial registration, etc., or in the issuance of resident's card or other certificates at the government office, it is necessary for the applicant to go directly to the registration office or government office and submit documents (various application forms) However, it is conceivable that such operations can be performed via the Internet in the future.
[0003]
When electronic documents are submitted through communication via the Internet or the like, a fee may be required for the submission of the documents. Documents to be submitted to government offices such as the JPO, the registration office, or government offices are often in the form of purchasing stamps and stamps and pasting them on the submitted documents. In some cases, some kind of fee payment mechanism is required. In the JPO electronic application system, the document submitter will transfer some amount in advance to the prepaid account, and the JPO system will deduct the necessary amount from the prepaid account when the application is accepted. .
[0004]
On the other hand, in a commercial transaction called so-called electronic shopping, various products can be purchased via the Internet, but the payment is usually made by debiting from a credit card or a bank account. Specifically, a person who purchases a product transmits a credit card or bank account number via communication, and the seller selling the product deducts a predetermined amount from the credit card or bank account using the number. In recent years, an electronic payment method for the Internet called SET (Secure Electronic Transaction) has also been proposed.
[0005]
[Problems to be solved by the invention]
As described above, when payment of a fee is required when electronic documents are submitted via communication via the Internet, etc., the documents are submitted by a method of withdrawal from a prepaid account such as the JPO electronic application system. It is inconvenient for a person to make a prepayment account. When applying for real estate registration, it is possible that the person who submits the document will perform the procedure only once in his lifetime, so it is troublesome to create a prepaid account just for that purpose.
[0006]
Payment methods that do not depend on a prepaid account include debit from a credit card or bank account. In that case, the process of debiting from a credit card or bank account specified by the applicant is the process of accepting documents via communication. Must be done in a separate phase. Accordingly, for example, there are cases where the amount deposited in the account cannot be withdrawn because the amount deposited is less than the amount withdrawn.
[0007]
According to the above-mentioned SET protocol, electronic payment can be made on the Internet. This is based on the premise that the person who purchases the product and the person who pays for it are the same person and make payment at the same time when applying for the purchase of the product. It does not apply to procedures in which documents are submitted by attaching stamps or stamps to government offices such as the JPO, the registry office, or government offices. In such a procedure, the document applicant's agent may send the document on behalf of the applicant. In other words, stamps and stamps attached to documents are to be paid by the applicant of the documents, while the documents are submitted by the agent, so the person who pays the fee is different from the person who submits the document, In that case, the payment procedure cannot be performed using the SET protocol in connection with the document submission procedure. If the fee payment and the document submission are performed independently of each other, the SET protocol can be used for the fee payment. However, in this case, the fee payment procedure is not related to the document submission procedure. If you try to forcibly relate, it will take time and effort.
[0008]
In addition, when submitting various documents, it may be necessary to clearly determine when the submission was made. On the other hand, when documents are submitted via communication, retransmission may occur depending on the state of the communication line, etc., and there is an inconvenience that the document submission time is not clear. In particular, if the time when you started sending the document is the time when you submitted the document, after sending it and securing the submission date, send another document later because of the resending, It would be possible to misuse the claiming that the document was submitted on the submission date. Therefore, there is a need for a mechanism that reasonably establishes the submission point when submitting documents via communication.
[0009]
In view of the above-mentioned problems in the conventional system, the present invention needs to create a special account such as a prepaid account when payment of a fee is required when electronic documents are submitted by communication via the Internet or the like. There is no credit card or bank account debit processing in another phase, and even if the person who pays the fee is different from the person who submits the document, it is possible to properly submit the document and pay the fee An object is to provide a data transmission system, a data transmission method, a data transmission device, and a data reception device.
[0010]
The present invention also provides a data transmission system, a data transmission method, a data transmission device, and a data transmission system having a mechanism for rationally determining the submission date and time without allowing misuse when electronic documents are submitted by communication. An object is to provide a receiving apparatus.
[0011]
[Means for Solving the Problems]
In order to achieve the above object, an invention according to claim 1 is a data transmission / reception system for transmitting data from a predetermined device to another device, wherein the predetermined device performs a one-way function on the target data to be transmitted. Prior to transmission of the target data, means for transmitting the compressed data to the other device, and after receiving a ticket from the other device, the received ticket and the target data are Means for transmitting to another device, said other device storing the compressed data transmitted from said predetermined device in a predetermined storage means and returning a ticket including an expiration date to said predetermined device Means for receiving the ticket and target data transmitted from the predetermined device, and taking out the expiration date of the received ticket, Receive the ticket It is determined whether or not the time is within the validity period. If it is determined that the time is not within the validity period, the ticket is invalid. After Processing Control not to do And means for generating a compressed data by applying a one-way function to the received target data, and the generated compressed data and the compressed data stored in the storage means, if determined to be within the expiration date And the compressed data match by the comparison , The target data, When the compressed data is received Authenticate as accepted at Means.
[0013]
The invention according to claim 2 is a data transmission / reception method for transmitting data from a predetermined apparatus to another apparatus, wherein the predetermined apparatus The compressed data sending means of the document sending processing unit , Generate a compressed data by applying a one-way function to the target data to be transmitted, Generated compressed data Prior to transmission of the target data, transmitting to the other device; and Ticket issuing processing means Storing the received compressed data in a predetermined storage means, and then transmitting a ticket including an expiration date to the predetermined device; and the predetermined device The target data sending means of the document sending processor Receiving the ticket, transmitting the received ticket and the target data to the other device, and the other device The receiving means provided by Receiving a ticket and target data transmitted from the predetermined device, and the other device The ticket expiration date verification means of the document reception processing unit , Retrieve the expiration date of the received ticket, Receive the ticket It is determined whether or not the time is within the validity period. If it is determined that the time is not within the validity period, the ticket is invalid. After Processing Control not to do Steps, The compressed data verification means of the document reception processing unit provided in the other device has the ticket If it is determined that it is within the expiration date, the compressed data generated by applying a one-way function to the received target data is compared with the compressed data stored in the storage means, and the compressed data matches. If you can confirm , The target data is When compressed data is received Authenticate as accepted at And a step.
[0019]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0020]
FIG. 1 is an overall view of a document delivery system according to an embodiment of the present invention. A document reception server 101, a payment reception server 102, an authentication station 103, an agent device 104, an applicant device 105, a financial institution server 106, and a financial institution authentication station 107 are connected to the Internet 110.
[0021]
An outline of the flow of processing in the system of FIG. 1 will be described. In particular, except for the description of the encryption / decryption process and the digital signature process (which will be described later with reference to a flowchart), the process flow focusing on the data flow will be described.
[0022]
The applicant device 105 is a device operated by an applicant who wants to submit a document by paying a predetermined fee, and the agent device 104 is an agent who submits a document (actual document transmission) on behalf of the applicant. Is a device to operate. Documents to be submitted are first prepared by the agent device 104 in response to the request of the applicant. The created document data is transmitted to the applicant device 105. The applicant confirms the contents of the received document data and saves the document data. Further, the applicant connects to the payment acceptance server 102 from the applicant device 105 and performs fee payment processing.
[0023]
The payment acceptance server 102 is a server that performs processing related to payment of fees associated with document submission. When receiving a fee payment processing request from the applicant device 105, the payment acceptance server 102 is connected to the financial institution server 106 to check the credit of the applicant. Then, the payment certificate is returned to the applicant apparatus 105. The payment certificate is data certifying that the applicant has paid (or guaranteed to pay), and is data corresponding to a stamp or a certificate, which will be described in detail later. The payment certificate is managed by a payment certificate management database (DB) that can be commonly accessed by both the document reception server 101 and the payment reception server 102. The applicant receives the payment certificate by the applicant device 105, attaches the payment certificate to the stored document data, and transmits it to the agent device 104. The agent receives the data by the agent device 104 and temporarily stores the data. Thereafter, the agent transmits the data to the document reception server 101 at an arbitrary time.
[0024]
The document receiving server 101 is a server that receives a submitted document transmitted from the agent device 104. The document reception server 101 receives data transmitted from the agent (data obtained by adding a payment certificate to the document data), verifies the payment certificate, and stores the document data. The verification of the payment certificate is a process of making an inquiry to the payment certificate management DB that the payment certificate is unused, and making it used if it is not used.
[0025]
The certificate authority 103 is a certificate authority that issues a certificate used to authenticate the applicant or agent. The financial institution server 106 is a financial institution server where an applicant's account is provided. The financial institution certificate authority 107 is a certificate authority that issues a certificate used to authenticate an applicant having the account.
[0026]
FIG. 2 shows an internal configuration of the document reception server 101 and the payment reception server 102 of FIG.
[0027]
The document reception server 101 includes a ticket issue processing unit 211, a document reception processing unit 212, a signature generation unit 213, an encryption / decryption processing unit 214, and a communication control unit 215. The payment server 102 includes a payment acceptance processing unit 221, a signature generation unit 222, an encryption / decryption processing unit, a payment certificate generation management unit 224, a SET processing unit 225, and a communication control unit 226. Also, as a common database (DB) that can be accessed from both the document reception server 101 and the payment server 102, a reception management DB 231, a key / certificate management DB 232, an applicant / agent management DB 233, and a payment certificate management DB 234 are provided. Yes.
[0028]
The document reception server 101 receives a document transmitted from the agent device 104 via the Internet 110. The document reception processing unit 212 performs the document reception processing (described in detail with reference to FIG. 18). The ticket issuance processing unit 211 performs a process of issuing a ticket (described in detail with reference to FIG. 17) before receiving actual document data when performing document acceptance processing. Issuing a ticket is a process for determining the document submission date and time. That is, when sending a document from the agent device 104 to the document reception server 101, if the data to be actually sent is sent as it is, there is a possibility that retransmission will occur and the time of submission of the document may be ambiguous. (1) to (4) are used to prevent misuse.
(1) First, the agent device 104 compresses the data to be actually sent with a one-way function to obtain a message digest, and sends the message digest to the document reception server 101. (For details, perform cryptographic communication with a certificate.)
(2) The document reception server 101 acquires a new reception number in the ticket issuance processing (FIG. 17) by the ticket issuance processing unit 211, stores the reception number in correspondence with the message digest, and receives the reception number. Is sent to the agent device 104. Data for sending the receipt number is a ticket.
{Circle around (3)} The agent device 104 receives the receipt number from the ticket, and sends the data to be actually sent with the receipt number to the document acceptance server 101.
(4) After receiving all the data from the agent device 104, the document acceptance server 101 compresses the data with a one-way function (the same function used in (1)), obtains a message digest, and It is confirmed whether or not it matches the message digest stored in (2) above. If they match, the data intended to be actually sent from the agent device 104 when the ticket is issued is actually received. On the other hand, if they do not match, another data has been transmitted.
[0029]
FIG. 8 shows the contents of a ticket sent from the document reception server 101 to the agent device 104 in the system according to the present embodiment. The reception number 801 is a number newly assigned by the document reception server 101 in response to the document transmission when the agent device 104 transmits the document. The sender information 802 is various information for specifying a sender (agent) who sends the document. The expiration date 803 indicates the expiration date of this ticket. When a document is sent from the agent device 104, even if retransmission occurs, an expiration date (a predetermined time may be taken from the time of ticket issuance) only for a time sufficient for sending the document may be kept. An expiration date 803 is set to prevent the documents from being sent indefinitely. A signature 804 is obtained by adding the signature of the document reception server 101 to the data 801 to 803.
[0030]
FIG. 9 shows the contents of the reception management DB 231 of FIG. 1 used in the system of this embodiment. When the document reception server 101 acquires a new reception number in the ticket issuing process (2) (FIG. 17), the document reception server 101 acquires a new reception number on the reception management DB 231 and 1 corresponding to the reception number. Reserve a line area. In the reception number 901, the sender information 902, and the expiration date 903, the same contents as the information 801 to 803 set in the transmitted ticket (FIG. 8) are stored. The message digest 904 and the sender certificate 905 store the information sent from the agent device 104 in (1) above. The ticket management information 906 stores flag information indicating whether or not the ticket is used, and the initial value is set to “unused”. The document content 907 is an area for storing the entire document sent from the agent device 104. When the message digest match is confirmed in (4) above, the ticket management information 906 is set to “used”, and the received document data is stored in the document content 907.
[0031]
Returning to FIG. 2 again, the description of the configuration of the document reception server 101 will be continued. The signature generation unit 213 and the encryption / decryption processing unit 214 are used to add a signature to data to be transmitted and received and to perform encryption / decryption processing when performing document acceptance processing. The communication control unit 215 performs communication control with the Internet 110.
[0032]
The payment acceptance server 102 accepts fee payment from the applicant. In the system of this embodiment, the applicant can connect to the payment acceptance server 102 from the applicant device 105 and perform the fee payment processing. The payment acceptance processing unit 221 performs a process of receiving a fee payment request from the applicant (described in detail in FIG. 13), and indicates that the applicant has paid (or guaranteed to pay). Issue a payment certificate to the applicant. The payment certificate plays a role like a stamp, a certificate, a gold certificate or a gift certificate. Since the payment certificate is issued after making a payment credit inquiry to the financial institution for the applicant, the operating organization of the document reception server 101 and the payment reception server 102 The amount issued can always be deducted from the applicant's account. Also, unlike payment in advance, payment certificates do not need to be opened in advance. The payment certificate may be used for another case or given to another person like a stamp.
[0033]
FIG. 6 shows the contents of the payment certificate used in the system of the present embodiment. The payment certificate includes a management number 601, a payment amount 602, applicant information 603, an expiration date 604, and a signature 605 of the payment acceptance server 102. The management number 601 is a management number unique to the payment certificate. The payment amount 602 is information on the amount designated by the applicant to pay. The applicant information 603 is information for identifying an applicant who has issued a payment request and received the payment certificate. The expiration date 604 is the expiration date of the payment certificate. The signature 605 is a signature of the payment acceptance server 102 that has issued the payment certificate, and this ensures that the payment certificate has been issued from the payment acceptance server 102. These pieces of information 601 to 605 are set when the payment acceptance server 102 issues the payment certificate.
[0034]
FIG. 7 shows the contents of the payment certificate management DB 234 of FIG. 1 used in the system of the present embodiment. The payment acceptance server 102 manages the issued payment certificate with this payment certificate management DB 234. Information 601 to 605 of the issued payment certificate is stored in 701 to 705 of the payment certificate management DB 234. The trying state 706 is a flag indicating whether or not the payment certificate is used. When the document reception server 101 receives a document, the payment certificate management DB 234 is searched with the management number 601 of the payment certificate attached to the document to search for a corresponding entry. If the usage status 706 of the entry is “unused”, the payment certificate has not been used yet, so the usage status 706 is set to “used”. This is equivalent to confirming the sticking of a stamp or a stamp. When a document using the same payment certificate is sent again, the usage state 706 is “used”, so it is confirmed that the charge payment is not guaranteed.
[0035]
Since the payment certificate is managed by the payment certificate management DB 234 as shown in FIG. 7, the procedure can be performed even when the applicant who pays the fee is different from the agent who actually sends the document. In addition, the payment certificate can be transferred to another person and used by others.
[0036]
Returning to FIG. 1 again, the description of the configuration of the payment acceptance server 102 will be continued. The signature generation unit 222 and the encryption / decryption processing unit are used when a signature is added to data to be transmitted / received and an encryption / decryption process is performed when performing the payment acceptance process. The payment certificate generation management unit 224 generates a payment certificate having the configuration shown in FIG. 6 and performs processing managed by the payment certificate management DB 234 shown in FIG. The SET processing unit 225 performs processing according to the SET protocol when making a credit inquiry of the applicant from the payment acceptance server 102 to the financial institution server 106. The communication control unit 226 performs communication control with the Internet 110.
[0037]
The reception management DB 231 and the payment certificate management DB 234, which are common DBs that can be accessed from both the document reception server 101 and the payment server 102, have been described with reference to FIGS. The key / certificate management DB 232 includes the secret key and public key of the document receiving server 101 and the payment server 102, the certificate issued from the certificate authorities 103 and 107, and the certificate authority 103 used for authentication. This DB manages the public key 107 and the public key of the communication partner. The applicant / agent management DB 233 is a DB that manages information related to the applicant and the agent connected to the document reception server 101 and the payment server 102.
[0038]
In this embodiment, the document reception server 101 and the payment server 102 are separated by different devices and the common DB 203 is used in common. However, the common DB 203 is not shared, and the DB is completely separated. May be. In that case, the reception management DB 231 may be managed by the document reception server 101, and the payment certificate management DB 234 may be managed by the payment reception server 102. Conversely, the document reception server 101 and the payment server 102 may be configured on a single device including the DB 203. In that case, the communication control unit, signature generation unit, encryption / decryption processing unit, and the like may be configured in common.
[0039]
FIG. 3 shows the configuration of the certificate authority 103 of FIG. The certificate authority 103 includes a certificate issuance processing unit 301, a certificate management unit 302, a communication control unit 304, and a certificate management DB 311. The certificate authority 103 issues a certificate to the agent or the applicant in advance.
[0040]
FIG. 4 shows the configuration of the agent device 104 of FIG. The agent device 104 includes an application form editor 401, a signature generation unit 402, an encryption / decryption processing unit 403, a document sending processing unit 404, a document reception processing unit 405, a communication control unit 406, an application form management DB 411, and a key / A certificate management DB 412 is provided.
[0041]
The application form editor 401 is an editor used for creating a document to be sent. The document sending processing unit 404 performs processing for sending a document to the applicant apparatus 105 (described in detail in FIG. 10) and processing for sending a document with a payment certificate to the document reception server 101 (described in detail in FIG. 16). Do. The document reception processing unit 405 performs processing for receiving a document with a payment certificate sent from the applicant (described in detail in FIG. 15). The signature generation unit 402 and the encryption / decryption processing unit 403 are used when a signature is added to data to be transmitted and received and when encryption / decryption processing is performed. The communication control unit 406 performs communication control with the Internet 110.
[0042]
The application form management DB 411 is a DB that stores and manages documents created by the application form editor 401 and documents with a payment certificate sent from the applicant. The key / certificate management DB 412 includes the secret key of the agent device 104, the public key, the certificate issued from the certificate authorities 103 and 107, and the public key of the certificate authorities 103 and 107 used for authentication. And a DB for managing the public key of the communication partner.
[0043]
FIG. 5 shows a configuration of the applicant apparatus 105 of FIG. The applicant apparatus 105 includes a document reception processing unit 501, a received document management unit 502, an encryption / decryption processing unit 503, a signature generation unit 504, a payment processing unit 505, a document delivery processing unit 506, a payment certificate management unit 507, A communication control unit 508, an application form management DB 511, a key / certificate management DB 512, and a payment certificate management DB 513 are provided.
[0044]
The document reception processing unit 501 performs processing for receiving a document sent from the agent (described in detail with reference to FIG. 11). The payment processing unit 505 performs processing (described in detail in FIG. 12) for connecting to the payment receiving server 102 and making payment. The document delivery processing unit 506 performs a process of sending a document with a payment certificate to the agent (described in detail in FIG. 14). The signature generation unit 504 and the encryption / decryption processing unit 503 are used when a signature is added to data to be transmitted / received and when encryption / decryption processing is performed. The payment certificate management unit 507 performs processing for managing the payment certificate issued from the payment acceptance server 102 by the payment certificate management DB 513. The communication control unit 508 performs communication control with the Internet 110.
[0045]
The application form management DB 511 is a DB that stores and manages documents and the like sent from the agent. The key / certificate management DB 512 includes the private key of the applicant device 105, the public key, the certificate issued from the certificate authority 103, 107, and the public key of the certificate authority 103, 107 used for authentication. And a DB for managing the public key of the communication partner. The payment certificate management DB 513 is a DB that stores and manages a payment certificate issued from the payment acceptance server 102. The configuration is the same as the payment certificate management DB 234 of the payment acceptance server 102 described in FIG. However, the payment certificate management DB 513 manages the payment certificate received by the applicant, and the usage state 706 is information indicating whether or not the applicant has used it.
[0046]
Next, details of each process in the system of FIG. 1 will be described with reference to the flowcharts of FIGS.
[0047]
FIG. 10 is a flowchart showing the flow of document delivery from the agent device 104 to the applicant device 105. This processing is mainly processing by the document delivery processing unit 404 in FIG. First, the agent creates a document using the application form editor 401 of FIG. 4 based on the request of the applicant. In step 1001, an electronic signature of the agent is executed on the document to be sent. Specifically, the document data is compressed with a one-way function (such as a hash function), and the signature data obtained by encrypting the compressed data (message digest) with the secret key of the agent is attached to the original document data, Make an agent-signed document. Next, in step 1002, a common key for encrypting the document with the agent signature is generated, and the document with the agent signature is encrypted with the common key. Next, in step 1003, the common key is encrypted with the applicant's public key. In step 1004, the encrypted agent-signed document and the common key are transmitted to the applicant device 105 together with the agent certificate, and the process is terminated.
[0048]
The agent's certificate is obtained from the certificate authority 103 in advance. The certificate of the agent is data obtained by concatenating the public key of the agent with various information related to the agent and signing the concatenated data with the secret key of the certificate authority 103. When the certificate authority 103 receives a certificate issuance request from the agent, the certificate authority 103 confirms the identity of the agent and then issues a certificate. If this certificate is attached to the data transmitted from the agent device 104, it can be verified by this certificate that the data is surely sent from the agent. It is possible to acquire various information for specifying a person's public key and agent. Similarly, the applicant also obtains a certificate from the certificate authority 103 in advance.
[0049]
FIG. 11 shows a process flow of the applicant apparatus 105 that receives data transmitted from the agent apparatus 104 to the applicant apparatus 105 by the process of FIG. This processing is mainly processing by the document reception processing unit 501 in FIG. First, in step 1101, the agent's certificate in the received data is verified, and the encrypted common key in the received data is decrypted using the applicant's private key. In step 1102, the agent-signed document is decrypted using the decrypted common key. In step 1103, the signature of the document with the agent signature is verified using the agent's public key. In this verification, compressed data (message digest) obtained by compressing the document data with a one-way function (using the same function as used in step 1001 in FIG. 10) is obtained by decrypting the signature data with the public key of the agent. It is a process for confirming whether or not it becomes equal to. As a result of the verification, if the signature is proper, the agent-signed document is stored in step 1105. As a result of the verification, if the signature is not proper, in step 1106 it is reported to the applicant that the application document has been tampered with, and the process is terminated.
[0050]
FIG. 12 is a flowchart showing a flow of fee payment processing by the applicant. This processing is mainly processing by the payment processing unit 505 in FIG. First, in step 1201, the applicant apparatus 105 connects to the payment acceptance server 102, and determines and transmits the payment amount. In step 1202, the applicant's certificate (certificate acquired from the certificate authority 103) is presented to the payment acceptance server 102. Step 1203 is processing on the payment acceptance server 102 side. As will be described later with reference to FIG. 13, the payment acceptance server 102 receives a common key encrypted with the applicant's public key and a payment encrypted with the common key. A certificate (FIG. 6) is transmitted. In step 1204, the encrypted common key transmitted from the payment acceptance server 102 is decrypted with the applicant's private key. In step 1205, the encrypted payment certificate is decrypted using the decrypted common key. In step 1206, the decrypted payment certificate is stored in the payment certificate management DB 513 (FIG. 7), and the process ends.
[0051]
FIG. 13 is a flowchart showing the process of step 1203 in FIG. 12, that is, the flow of the payment acceptance process in the payment acceptance server 102. This processing is mainly processing by the payment acceptance processing unit 221 in FIG. First, in step 1301, the certificate sent from the applicant is verified, and the applicant's public key is acquired. Next, in step 1302, a payment credit inquiry (credit) from the applicant is executed to the financial institution using, for example, the SET protocol. Specifically, information for identifying the applicant and the withdrawal amount is transmitted to the financial institution server 106 of FIG. 1, and the amount of the withdrawal amount is secured from the account of the applicant.
[0052]
In order to verify the identity of the organization that operates the payment acceptance server 102 when performing a payment credit inquiry to the financial institution, the organization that operates the payment acceptance server 102 beforehand obtains a certificate from the financial institution certification authority 107. It is necessary to obtain it. In addition, in this payment credit inquiry, the applicant who performs the debit is also authenticated (it is necessary to confirm whether or not it is a debit request from the applicant). In step 1202, the certificate of the financial institution is sent to the payment acceptance server 102, and the payment acceptance server 102 attaches the certificate of the applicant's financial institution when making a credit inquiry in step 1302. It is necessary to make a credit inquiry.
[0053]
As a result of the credit inquiry in step 1302, if a deduction frame corresponding to the deduction amount is secured in step 1303, the process proceeds to step 1304. If there is any problem with the credit inquiry result, the process is terminated. In step 1304, a management number of a payment certificate to be newly issued is acquired. Specifically, an area for one line of the new management number is secured in the payment certificate management DB 234 having the configuration shown in FIG. Next, in step 1305, information identifying the applicant is extracted from the applicant's certificate. In step 1306, an electronic signature is applied to the data obtained by concatenating the management number, the payment amount, the information for identifying the applicant, and the expiration date, and a payment certificate (FIG. 6) is created. Specifically, the concatenated data is compressed with a one-way function (such as a hash function), and the compressed data is encrypted with the private key of the payment receiving server 102, and the original concatenated data is attached to the payment data. Make a certificate.
[0054]
In step 1307, the information included in the created payment certificate is recorded in the payment certificate management DB 234 (FIG. 7). In step 1308, a common key for encrypting the payment certificate is generated, and the payment certificate is encrypted with the common key. In step 1309, the common key is encrypted with the applicant's public key. In step 1310, the encrypted common key and the payment certificate encrypted with the common key are transmitted to the applicant apparatus 105, and the process ends.
[0055]
FIG. 14 is a flowchart showing the flow of document delivery from the applicant device 105 to the agent device 104. This processing is mainly processing by the document delivery processing unit 506 in FIG. First, in step 1401, the agent-signed document stored in step 1105 of FIG. 11 is taken out. In step 1402, the applicant's electronic signature is implemented on the data including the agent-signed document and the payment certificate. This is called a document with a payment certificate. The payment certificate used here is a payment certificate managed by the payment certificate management DB 513 having the configuration shown in FIG. The usage status 706 of the used payment statement is changed to “used”.
[0056]
Next, in step 1403, a common key is generated, and the document with the payment certificate is encrypted with the common key. In step 1404, the common key is encrypted using the public key of the agent. In step 1405, the encrypted common key and the document with the payment certificate encrypted with the common key are transmitted to the agent device 104.
[0057]
FIG. 15 is a flowchart showing the flow of processing of the agent device 104 that receives data from the applicant sent in FIG. This processing is mainly processing by the document reception processing unit 405 in FIG. First, in step 1501, the encrypted common key in the received data is decrypted using the secret key of the agent. In step 1502, the document with the payment certificate is decrypted using the decrypted common key. In step 1503, the electronic signature of the applicant attached to the document with the payment certificate is verified using the applicant's public key. In this verification, the value obtained by decrypting the signature data with the applicant's public key is compressed data obtained by compressing the document with the payment certificate with the one-way function (the same function used for the signature in step 1402 in FIG. 14). This is a process for confirming whether or not they are equal.
[0058]
If it is determined in step 1504 that the signature is proper, the process proceeds to step 1506. In step 1506, the electronic signature of the payment certificate included in the document with the payment certificate is verified using the public key of the payment acceptance server 102. In this verification, the value obtained by decrypting the signature data with the public key of the payment acceptance server 102 is obtained by concatenating the management number, payment amount, information for identifying the applicant, and data obtained by concatenating the expiration date. This is a process for confirming whether or not the compressed data is equal to the compressed data compressed by the one-way function (the same function used in the signature in step 1306 in FIG. 13).
[0059]
If it is determined in step 1507 that the signature is a proper signature, the process proceeds to step 1509. In step 1509, the signature of the agent in the document signed by the agent included in the document with the payment certificate is verified using the secret key of the agent. If the verification result is a proper signature in step 1510, the document with the payment certificate is stored in step 1512, and the process is terminated. If any of the steps 1504, 1507, and 1510 indicates that the verification result is an illegal signature, report to the agent that the document has been tampered with in steps 1505, 1508, and 1511, respectively. The process is terminated.
[0060]
FIG. 16 is a flowchart showing the flow of processing for sending a document with a payment certificate from the agent device 104 to the document reception server 101. This processing is mainly processing by the document delivery processing unit 404 in FIG. First, in step 1601, a document with a payment certificate to be sent is compressed with a one-way function to generate compressed data (message digest). Next, in step 1602, a common key is generated, and the message digest is encrypted with the common key. In step 1603, the common key is encrypted with the public key of the document reception server 101. In step 1604, an agent's certificate is attached to the encrypted common key and the message digest encrypted with the common key, and sent to the document reception server 101. Step 1605 is a ticket issuing process on the document reception server 101 side. As will be described later with reference to FIG. 17, the document reception server 101 generates a common key encrypted with the agent's public key (generated on the document reception server 101 side). Key) and a ticket (FIG. 8) encrypted with the common key.
[0061]
In step 1606, the encrypted common key sent from the document reception server 101 is decrypted using the secret key of the agent. In step 1607, the ticket is decrypted using the decrypted common key. Next, in step 1608, the electronic signature attached to the ticket (FIG. 8) is verified using the public key of the document reception server 101. If it is determined in step 1609 that the verification result is a proper signature, the document reception server 101 has secured the submission date and time, and the process advances to step 1611. In step 1609, if the signature is invalid, in step 1610 it is reported to the agent that the ticket has been tampered with, and the process is terminated.
[0062]
When the ticket is obtained, a common key is generated in step 1611, and the document with the payment certificate is encrypted with the common key in step 1612. In step 1613, the ticket is encrypted with the common key. Next, in step 1614, the common key is encrypted with the public key of the document reception server 101. In step 1615, the encrypted common key, the ticket encrypted with the common key, and the document with the payment certificate are sent to the document reception server 101. Step 1616 is processing on the document reception server 101 side. As will be described later with reference to FIG. 18, from the document reception server 101, a common key encrypted with the public key of the agent and a reception encrypted with the common key are received. A confirmation letter is sent.
[0063]
In step 1617, the encrypted common key transmitted from the document reception server 101 is decrypted with the secret key of the agent. In step 1618, the encrypted acceptance confirmation is decrypted using the decrypted common key. In step 1619, the electronic signature of the document reception server 101 attached to the reception confirmation is verified. If the verification result indicates that the verification result is a proper signature in step 1620, the acceptance confirmation is stored in step 1622 and the process is terminated. If it is determined in step 1620 that the verification result is an illegal signature, the fact that some data alteration has been made is reported to the agent in step 1620, and the process ends.
[0064]
FIG. 17 is a flowchart showing the flow of the process of step 1605 of FIG. 16, that is, the flow of the ticket issuing process of the document reception server 101. This processing is mainly processing by the ticket issuing processing unit 211 in FIG. First, in step 1701, the common key sent from the agent is decrypted using the secret key of the document reception server 101. Next, in step 1702, the message digest is decrypted using the common key. In step 1703, a new reception number is acquired, and the reception number 901, information about the agent (sender) 902, expiration date 903, message digest 904, and agent certificate 905 are stored in the reception management DB 231 ( Store in Figure 9). The information regarding the agent is set to information extracted from the agent certificate included in the data sent from the agent. The expiration date is set to a time obtained by adding a predetermined time to the current time. The ticket management information 906 is initialized to “unused”.
[0065]
Next, in step 1704, data obtained by concatenating the receipt number, information on the agent, and the expiration date is generated, and an electronic signature is performed on the concatenated data. This digitally signed data is a ticket (FIG. 8). Specifically, signature data obtained by compressing the concatenated data with a one-way function (the same function used in steps 1601 and 1608 in FIG. 16) and encrypting the compressed data with the secret key of the document reception server 101 is obtained. A ticket (FIG. 8) is created by attaching to the original concatenated data. Next, in step 1705, a common key is generated and the ticket is encrypted with the common key. In step 1706, the common key is encrypted using the public key of the agent. In step 1707, the encrypted common key and the ticket encrypted with the common key are sent to the agent, and the process ends.
[0066]
FIG. 18 is a flowchart showing the process of step 1616 in FIG. 16, that is, the flow of the document reception process by the document reception server 101. This processing is mainly processing executed by the document reception processing unit 212 in FIG. First, in step 1801, the secret key sent from the agent is decrypted using the secret key of the document reception server 101. In step 1802, the ticket and the document with the payment certificate are decrypted using the decrypted common key. Next, in step 1803, the electronic signature attached to the ticket and the expiration date are verified. As a result of the verification, if it is determined in step 1804 that the signature is also valid and valid, the process proceeds to step 1806. If the signature is invalid or the expiration date has passed, a ticket fraud is displayed in step 1805, and the process ends.
[0067]
In step 1806, the document with the payment certificate sent from the agent is compressed with the one-way function used in the agent device 104 (the same function used in steps 1601 and 1608 in FIG. 16), and the message is sent. Generate a digest. In step 1807, the receipt number is extracted from the ticket sent from the agent, the message digest at the time of ticket request corresponding to the reception number is extracted with reference to the reception management DB 231 (FIG. 9), and generated in step 1806 Compare with message digest. As a result of the comparison, if they are the same in step 1808, it is confirmed that the content that was going to be sent at the time of ticket request is surely sent, so the flow proceeds to step 1810. If the comparison result is not the same in step 1808, it means that the content different from the content that was to be sent at the time of ticket request has been sent. Therefore, in step 1809, the display shows that the sending data does not match, and the processing ends.
[0068]
In step 1810, the management number data included in the payment certificate is retrieved from the payment certificate management DB 234 (FIG. 7), and it is verified whether or not the usage status 706 is “unused”. If “not used” in step 1811, the usage status 706 of the payment certificate of the management number in the payment certificate management DB 234 is changed to “used” in step 1813. Next, in step 1814, the ticket management information 906 of the receipt number is changed to “used”. In step 1815, the document with the payment certificate is stored. Documents are stored by storing them in the document contents 907 of the reception management DB 231 shown in FIG.
[0069]
In step 1816, a receipt confirmation including receipt information such as a receipt number is created and an electronic signature is executed. In step 1817, a common key is generated, and the reception confirmation with electronic signature is encrypted with the common key. In step 1818, the common key is encrypted with the public key of the agent. In step 1819, the encrypted common key and the reception confirmation with electronic signature encrypted with the common key are sent to the agent, and the process ends.
[0070]
According to the system of the above embodiment, the applicant can obtain the payment certificate, and the agent can attach the payment certificate to the submitted document and send it to the document reception server. The payment certificate can be used as an image such as a stamp, a certificate, a voucher or a gift certificate, and since it is signed by the payment acceptance server, it is not easily tampered with. The actual settlement may be made in any form, but since it is guaranteed that it can be debited at the credit stage, the document reception server can always collect a fee. In addition, since the applicant attached a payment certificate to the document, signed the entire document, and sent it to the agent, the applicant indicated that he / she understood the contents of the document. After that, the agent cannot tamper with the document.
[0071]
Furthermore, when deciding when to submit a document, the document data to be sent from the submitter is first compressed with a one-way function to obtain a message digest, which is sent along with the certificate to the document reception server. Then memorize the message digest and return the ticket. After that, when the entire document data is sent from the submitter, the message digest is obtained and compared with the message digest stored at the time of ticket issuance, the document to be sent from the beginning is surely sent. Can be confirmed. For this reason, the ticket issue time can be regarded as the document submission time.
[0072]
In the above embodiment, an example has been described in which an agent submits documents on behalf of the applicant. However, the applicant may directly send documents to the document reception server, not via the agent. Good.
[0073]
Moreover, although the example using SET as the payment method has been described in the above embodiment, a payment method other than SET, for example, a credit card payment method that does not use SET may be used.
[0074]
The present invention can be applied to a case where documents are sent via the Internet to a public office such as a patent office, a registration office, or a government office. Also, it can be applied to so-called electronic shopping.
[0075]
【The invention's effect】
As described above, according to the present invention, before sending a document, compressed data obtained by compressing the document to be sent with a one-way function is sent, and the same one-way function is applied to the actually sent document later. Compared with the compressed data compressed in step 1, when submitting electronic documents via communication, a mechanism is provided for rationally determining the submission date and time without allowing abuse. Further, since the ticket includes an expiration date, the expiration date can be used effectively when using the ticket.
[Brief description of the drawings]
FIG. 1 is an overall view of a document sending system according to an embodiment of the present invention.
FIG. 2 is an internal configuration diagram of a document reception server and a payment reception server.
[Fig. 3] Configuration diagram of the certificate authority
FIG. 4 is a configuration diagram of an agent device.
[Fig. 5] Configuration diagram of the applicant device
FIG. 6 is a diagram showing the contents of a payment certificate used in the system according to the present embodiment.
FIG. 7 is a view showing the contents of a payment certificate management DB used in the system according to the present embodiment;
FIG. 8 is a view showing the contents of a ticket sent from the document reception server to the agent device in the system according to the present embodiment;
FIG. 9 is a diagram showing the contents of a reception management DB used in the system according to the present embodiment
FIG. 10 is a flowchart showing the flow of sending documents from the agent device to the applicant device.
FIG. 11 is a flowchart showing a processing flow of an applicant apparatus that receives data sent from the agent apparatus to the applicant apparatus;
FIG. 12 is a flowchart showing a flow of fee payment processing by an applicant.
FIG. 13 is a flowchart showing a flow of payment acceptance processing in the payment acceptance server.
FIG. 14 is a flowchart showing the flow of sending documents from the applicant device to the agent device.
FIG. 15 is a flowchart showing a processing flow of an agent device that receives data from an applicant.
FIG. 16 is a flowchart showing the flow of processing for sending a document with a payment certificate from the agent device to the document reception server.
FIG. 17 is a flowchart showing a flow of ticket issuing processing of the document reception server.
FIG. 18 is a flowchart showing a flow of document reception processing by the document reception server.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 101 ... Document acceptance server, 102 ... Payment acceptance server, 103 ... Certification authority, 104 ... Agent apparatus, 105 ... Applicant apparatus, 106 ... Financial institution server, 107 ... Financial institution certification authority, 110 ... Internet.

Claims

A data transmission / reception system for sending data from a predetermined device to another device,
The predetermined apparatus is:
Means for applying a one-way function to the target data to be transmitted to form compressed data;
Means for transmitting the compressed data to the other device prior to transmission of the target data;
After receiving a ticket from the other device, the received ticket and the means for transmitting the target data to the other device,
The other device is
Means for storing the compressed data transmitted from the predetermined device in a predetermined storage means and returning a ticket including an expiration date to the predetermined device;
Means for receiving a ticket and target data transmitted from the predetermined device;
Taking out the expiration date of the received ticket, the ticket reception time is judged whether it is within the validity period, controls so as not to subsequent processing as an unauthorized ticket when it is determined not to be within the valid period Means,
If it is determined that it is within the expiration date, means for applying a one-way function to the received target data and generating compressed data;
The generated compressed data is compared with the compressed data stored in the storage means, and when the compressed data matches by the comparison , the target data is recognized as being accepted when the compressed data is received. data transmission and reception system, characterized in that it comprises a means for.

In a data transmission / reception method for transmitting data from a predetermined device to another device,
The compressed data sending means of the document sending processing unit provided in the predetermined device generates compressed data by applying a one-way function to the target data to be transmitted, and the generated compressed data is transmitted prior to the transmission of the target data, Transmitting to the other device;
The ticket issuing processing means provided in the other device stores the received compressed data in a predetermined storage means, and then transmits a ticket including an expiration date to the predetermined device;
When the target data sending means of the document delivery processing unit included in the predetermined device receives the ticket, the received ticket and the target data are transmitted to the other device;
Receiving means included in the other device , receiving a ticket and target data transmitted from the predetermined device;
The ticket expiration date verification unit of the document reception processing unit provided in the other apparatus extracts the expiration date of the received ticket , determines whether or not the ticket reception time is within the expiration date, and determines that it is not within the expiration date. If it is , the step of controlling not to perform subsequent processing as ticket fraud,
When the compressed data verification unit of the document reception processing unit provided in the other device determines that the ticket is within the expiration date, the compressed data generated by applying a one-way function to the received target data, and the storage Comparing the compressed data stored in the means and confirming that the compressed data matches , the step of certifying that the target data was received when the compressed data was received. A data transmission / reception method characterized by the above.