JPH11175607A - 書類送付システムおよび方法 - Google Patents

Abstract

(57)【要約】 【課題】インターネットなどを介して通信で電子的な書
類提出を行なう際に手数料の支払いが必要な場合におい
て、予納口座のような特別な口座を作る必要が無く、ク
レジットカードや銀行口座から別フェーズで引き落とし
処理を行なうことも無く、また料金を支払う者と書類の
提出を行なう者とが異なる場合でも適正に書類提出とそ
の料金支払いを行なうことができる書類送付システムお
よび方法を提供することを目的とする。また、通信で電
子的な書類提出を行なう場合に、悪用を許すことなく、
提出日時を合理的に決定する仕組みを備えた書類送付シ
ステムおよび方法を提供することを目的とする。 【解決手段】ネットワーク上に支払い受付サーバを設
け、該支払い受付サーバに対して支払い依頼を出せば、
支払い受付サーバが信用照会を実施し、料金の支払いが
保証される場合にはその旨を示す改ざん不可能な形式の
支払い証明書を発行するようにする。書類を提出する際
には、この支払い証明書を付して送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、電子データで各種
の書類を送付・受付し、該書類の送付・受付に伴う料金
の支払いやその支払い受付を行なう書類送付システムお
よび方法に関する。

【０００２】

【従来の技術】近年、インターネットのようなオープン
なネットワーク環境において、各種の書類データの授受
や商取引が行なわれるようになってきており、将来的に
もさらに多種多様な形態になることが予測される。例え
ば、現在、特許庁への出願書類などの提出は、提出者
が、直接、ダイヤルアップで特許庁のサーバに接続し提
出書類データを送信することが可能になっているが、将
来的にはインターネット経由で接続することが考えられ
る。一方、不動産登記や商業登記など、あるいは役所で
の住民票その他の証明書の発行業務などでは、申請する
者が登記所や役所に直接出向いて書類（各種申請書）を
提出して手続する必要があるが、このような業務も将来
的にはインターネット経由で実施できるようになること
が考えられる。

【０００３】このようにインターネットなどを介して通
信で電子的な書類提出を行なう場合、その書類提出に伴
って手数料の支払いが必要なことがある。特許庁、登記
所、あるいは役所などの官公庁に対して提出する書類で
は、印紙や証紙などを購入しそれを提出書類に貼付して
提出する形態をとることが多いが、通信で書類提出を行
なう場合には何らかの手数料支払いの仕組みが必要とな
る。特許庁の電子出願システムでは、あらかじめ書類提
出者が予納口座に幾らかの金額を振込んでおき、特許庁
の側のシステムでは出願を受け付けたときに当該予納口
座から必要な金額を引き落とす形態を採る。

【０００４】一方、いわゆる電子ショッピングなどと呼
ばれている商取引では、インターネット経由で種々の商
品を購入できるが、その支払いは、通常、クレジットカ
ードや銀行口座からの引き落としで行なわれている。具
体的には、商品を購入する者が、通信でクレジットカー
ドや銀行口座の番号を送信し、商品を売る側ではその番
号によってクレジットカードや銀行口座から所定の金額
を引き落とす。また、近年ではＳＥＴ（Secure Elector
onic Transaction）と呼ばれるインターネットの電子決
済方式なども提案されている。

【０００５】

【発明が解決しようとする課題】上述したようにインタ
ーネットなどを介して通信で電子的な書類提出を行なう
際に手数料の支払いが必要な場合、特許庁の電子出願シ
ステムのような予納口座からの引き落としの方式では、
書類提出を行なう者が必ず予納口座を作らなければなら
ず不便である。不動産登記などの申請では、その書類提
出を行なう者が生涯に１度しかその手続を行なわないこ
とも考えられるので、そのためだけに予納口座を作るの
は面倒である。

【０００６】予納口座によらない支払方法としては、ク
レジットカードや銀行口座からの引き落としがあるが、
その場合は、申請者が指定したクレジットカードや銀行
口座から引き落とす処理を、通信による書類の提出受付
け処理とは別フェーズで行なわなければならない。した
がって、例えば口座に預金されている金額が引き落とし
金額に満たないために引き落としができなくなるケース
などがある。

【０００７】上述のＳＥＴのプロトコルによればインタ
ーネット上で電子決済できるが、これは商品を購入する
者とその代金を支払う者が同じ者であって、商品購入の
申込時に同時に決済を行なうことを前提としており、特
許庁、登記所、あるいは役所などの官公庁に対して印紙
や証紙などを貼付して書類を提出する形態の手続に適用
するにはなじまない。そのような手続では、書類の申請
者の代理人が申請者を代行して書類送付を行なう場合が
あるからである。すなわち、書類に添付する証紙や印紙
などは書類の申請者が支払うべきものであり、一方、書
類は代理人が提出するので、料金を支払う者と書類を提
出する者とが異なることになり、その場合、書類の提出
手続と関係付けつつＳＥＴのプロトコルで支払い手続を
行なうことはできない。料金の支払いと書類の提出とを
無関係に行なうのであれば、料金の支払いにＳＥＴのプ
ロトコルを使用できるが、その場合は料金の支払い手続
と書類の提出手続との関係付けがなされない。無理に関
係付けようとすると、その分の手間がかかってしまう。

【０００８】さらに、各種書類の提出に際して、その提
出がいつ行なわれたかの日時を明確に確定することが必
要な場合がある。一方、通信で書類提出を行なう場合
は、通信回線の状態などに応じて再送が発生することが
あり、書類の提出時点は明確でないという不都合があ
る。特に、書類の送信を開始した時点を書類の提出時点
とした場合は、送信を開始して提出日時を確保した後、
再送が発生したことを理由に後から別の内容の書類を送
信し、その書類が前記提出日時に提出されたと主張する
ような悪用が可能になってしまう。したがって、通信で
書類を提出する際の提出時点を合理的に確定する仕組み
が求められている。

【０００９】本発明は、上述の従来形における問題点に
鑑み、インターネットなどを介して通信で電子的な書類
提出を行なう際に手数料の支払いが必要な場合におい
て、予納口座のような特別な口座を作る必要が無く、ク
レジットカードや銀行口座から別フェーズで引き落とし
処理を行なうことも無く、また料金を支払う者と書類の
提出を行なう者とが異なる場合でも適正に書類提出とそ
の料金支払いを行なうことができる書類送付システムお
よび方法を提供することを目的とする。

【００１０】また、本発明は、通信で電子的な書類提出
を行なう場合に、悪用を許すことなく、提出日時を合理
的に決定する仕組みを備えた書類送付システムおよび方
法を提供することを目的とする。

【００１１】

【課題を解決するための手段】上記目的を達成するた
め、請求項１に係る発明は、ネットワーク経由で、申請
人装置から書類受付サーバに対して書類を送付する書類
送付システムにおいて、前記ネットワークに、支払い受
付サーバを接続し、前記申請人装置は、前記支払い受付
サーバに対して、支払い金額を指定して料金支払いを依
頼する手段を備え、前記支払い受付サーバは、前記申請
人装置からの料金支払い依頼に応じて、金融機関に対す
る支払い信用照会を実施する手段と、該信用照会で前記
申請人の料金支払いが保証されることが判明したときに
は、該料金支払いが保証される旨を示す支払い証明書を
改ざん不可能な形式で作成し、前記申請人装置に送信す
る手段とを備え、前記申請人装置は、送付する書類に前
記支払い証明書を付して改ざん不可能な形式である支払
い証明書付き書類とし、前記書類受付サーバに送信する
手段を備え、前記書類受付サーバは、前記申請人装置か
ら送られてきた支払い証明書が未使用のものであること
を確認した後、該支払い証明書付き書類を保管する手段
を備えたことを特徴とする。

【００１２】請求項２に係る発明は、ネットワーク経由
で、申請人装置が送付したい書類を、代理人装置が代理
して書類受付サーバに対して送付する書類送付システム
において、前記ネットワークに、支払い受付サーバを接
続し、前記申請人装置は、前記支払い受付サーバに対し
て、支払い金額を指定して料金支払いを依頼する手段を
備え、前記支払い受付サーバは、前記申請人装置からの
料金支払い依頼に応じて、金融機関に対する支払い信用
照会を実施する手段と、該信用照会で前記申請人の料金
支払いが保証されることが判明したときには、該料金支
払いが保証される旨を示す支払い証明書を改ざん不可能
な形式で作成し、前記申請人装置に送信する手段とを備
え、前記申請人装置は、送付する書類に前記支払い証明
書を付して改ざん不可能な形式である支払い証明書付き
書類とし、前記代理人装置に送信する手段を備え、前記
代理人装置は、受信した支払い証明書付き書類を前記書
類受付サーバに送信する手段を備え、前記書類受付サー
バは、前記代理人装置から送られてきた支払い証明書が
未使用のものであることを確認した後、該支払い証明書
付き書類を保管する手段を備えたことを特徴とする。

【００１３】請求項３に係る発明は、ネットワーク経由
で、申請人装置から書類受付サーバに対して書類を送付
する書類送付システムにおいて、該書類の送付に伴う料
金の支払いを受付ける支払い受付サーバであって、前記
申請人装置からの料金支払い依頼に応じて、金融機関に
対する支払い信用照会を実施する手段と、該信用照会で
前記申請人の料金支払いが保証されることが判明したと
きには、該料金支払いが保証される旨を示す支払い証明
書を改ざん不可能な形式で作成し、前記申請人装置に送
信する手段とを備えたことを特徴とする。

【００１４】請求項４に係る発明は、ネットワーク経由
で、所定の装置から書類受付サーバに対して書類を送付
する書類送付システムにおいて、前記書類を送付する装
置で、送付したい書類データに一方向関数を施して圧縮
データを取得し、該圧縮データを改ざん不可能な形式で
前記書類受付サーバに送信する手段と、前記書類受付サ
ーバで、受信した圧縮データを記憶したのち、前記書類
を送付する装置にチケットを送信する手段と、前記書類
を送付する装置で、チケットを受信したら、送付したい
書類データの前記書類受付サーバへの送信を実行する手
段と、前記書類受付サーバで、前記書類データをすべて
受信したら、該書類データに前記一方向関数を施して得
た圧縮データと、前記記憶してある圧縮データとを比較
し、それらの圧縮データが一致することを確認する手段
とを備えたことを特徴とする。

【００１５】請求項５に係る発明は、ネットワーク経由
で、申請人装置から書類受付サーバに対して書類を送付
する書類送付方法において、前記ネットワークに、支払
い受付サーバを接続するとともに、前記申請人装置か
ら、前記支払い受付サーバに対して、支払い金額を指定
して料金支払いを依頼するステップと、前記支払い受付
サーバにより、前記申請人装置からの料金支払い依頼に
応じて、金融機関に対する支払い信用照会を実施するス
テップと、該信用照会で前記申請人の料金支払いが保証
されることが判明したときには、該料金支払いが保証さ
れる旨を示す支払い証明書を改ざん不可能な形式で作成
し、前記申請人装置に送信するステップと、前記申請人
装置により、送付すべき書類に前記支払い証明書を付し
て改ざん不可能な形式である支払い証明書付き書類と
し、前記書類受付サーバに送信するステップと、前記書
類受付サーバにより、前記申請人装置から送られてきた
支払い証明書が未使用のものであることを確認した後、
該支払い証明書付き書類を保管するステップとを備えた
ことを特徴とする。

【００１６】請求項６に係る発明は、ネットワーク経由
で、所定の装置から書類受付サーバに対して書類を送付
する書類送付方法において、前記書類を送付する装置
で、送付したい書類データに一方向関数を施して圧縮デ
ータを取得し、該圧縮データを改ざん不可能な形式で前
記書類受付サーバに送信するステップと、前記書類受付
サーバで、受信した圧縮データを記憶したのち、前記書
類を送付する装置にチケットを送信するステップと、前
記書類を送付する装置で、チケットを受信したら、送付
したい書類データの前記書類受付サーバへの送信を実行
するステップと、前記書類受付サーバで、前記書類デー
タをすべて受信したら、該書類データに前記一方向関数
を施して得た圧縮データと、前記記憶してある圧縮デー
タとを比較し、それらの圧縮データが一致することを確
認するステップとを備えたことを特徴とする。

【００１７】

【発明の実施の形態】以下、図面を用いて、本発明の実
施の形態を説明する。

【００１８】図１は、本発明の一つの実施の形態の書類
送付システムの全体図である。インターネット１１０
に、書類受付サーバ１０１、支払い受付サーバ１０２、
認証局１０３、代理人装置１０４、申請人装置１０５、
金融機関サーバ１０６、および金融機関認証局１０７が
接続されている。

【００１９】図１のシステムにおける処理の流れの概要
を説明する。特に、暗号化／復号化処理やディジタル署
名処理の説明は除き（それらについては後にフローチャ
ートを参照して説明する）、データの流れに着目した処
理の流れを説明する。

【００２０】申請人装置１０５は、所定の料金を支払っ
て書類を提出したい申請人が操作する装置であり、代理
人装置１０４は、その申請人を代理して書類提出（実際
の書類送信）を行なう代理人が操作する装置である。提
出する書類は、まず代理人が、申請人の依頼に応じて代
理人装置１０４で作成する。作成した書類データは、申
請人装置１０５に送信する。申請人は、受信した書類デ
ータの内容を確認し、該書類データを保存しておく。ま
た、申請人は、申請人装置１０５から支払い受付サーバ
１０２に接続し、料金支払い処理を行なう。

【００２１】支払い受付サーバ１０２は、書類提出に伴
う料金の支払いに関する処理を行なうサーバであり、申
請人装置１０５からの料金支払い処理要求を受けたとき
には、金融機関サーバ１０６に接続して当該申請人の信
用照会を実施した後、支払い証明書を申請人装置１０５
に返送する。支払い証明書は、申請人が料金支払いを行
なったこと（あるいは、行なうことが保証されたこと）
を証明するデータであり、印紙や証紙に相当するデータ
であるが、詳しくは後述する。支払い証明書は、書類受
付サーバ１０１および支払い受付サーバ１０２の両者で
共通にアクセス可能な支払い証明書管理データベース
（ＤＢ）で管理される。申請人は、申請人装置１０５に
よりその支払い証明書を受信し、保存してあった書類デ
ータに支払い証明書を付けて代理人装置１０４に送信す
る。代理人は、代理人装置１０４により、該データを受
信し、いったん保管する。その後任意の時期に、代理人
は、該データを書類受付サーバ１０１に送信する。

【００２２】書類受付サーバ１０１は、代理人装置１０
４から送信されてくる提出書類を受付るサーバである。
書類受付サーバ１０１は、代理人から送信されたデータ
（書類データに支払い証明書を付けたデータ）を受信
し、支払い証明書を検証し書類データを保管する。支払
い証明書の検証とは、当該支払い証明書が未使用のもの
であることを支払い証明書管理ＤＢに問い合わせ、未使
用であったら使用済みにする処理である。

【００２３】認証局１０３は、申請人や代理人の認証を
行なうために使用する証明書を発行する認証局である。
金融機関サーバ１０６は、申請人の口座が設けられてい
る金融機関のサーバである。金融機関認証局１０７は、
その口座を持つ申請人の認証を行なうために使用する証
明書を発行する認証局である。

【００２４】図２は、図１の書類受付サーバ１０１およ
び支払い受付サーバ１０２の内部構成を示す。

【００２５】書類受付サーバ１０１は、チケット発行処
理部２１１、書類受付処理部２１２、署名生成部２１
３、暗号化／復号化処理部２１４、および通信制御部２
１５を備えている。支払いサーバ１０２は、支払い受付
処理部２２１、署名生成部２２２、暗号化／復号化処理
部、支払い証明書生成管理部２２４、ＳＥＴ処理部２２
５、および通信制御部２２６を備えている。また、書類
受付サーバ１０１および支払いサーバ１０２の両方から
アクセスできる共通データベース（ＤＢ）として、受付
管理ＤＢ２３１、鍵・証明書管理ＤＢ２３２、申請人・
代理人管理ＤＢ２３３、および支払い証明書管理ＤＢ２
３４を備えている。

【００２６】書類受付サーバ１０１は、インターネット
１１０を介して代理人装置１０４から送信されてくる書
類を受付ける。書類受付処理部２１２は、その書類受付
処理（図１８で詳しく説明する）を行なう。チケット発
行処理部２１１は、書類受付処理を行なうにあたって、
実際の書類データを受取る前にチケットを発行する処理
（図１７で詳しく説明する）を行なう。チケットの発行
は、書類提出日時を決定するための処理である。すなわ
ち、代理人装置１０４から書類受付サーバ１０１に書類
を送付する際に、実際に送付しようとするデータをその
まま送信すると、再送が発生してその書類提出時点があ
いまいになる恐れがあるので、以下の〜のように処
理して悪用を防ぐものである。

【００２７】まず代理人装置１０４で、実際に送付し
ようとするデータを一方向関数で圧縮しメッセージダイ
ジェストを求め、該メッセージダイジェストを書類受付
サーバ１０１に送る。（なお、詳しくは証明書付で暗号
通信を行なう。） 書類受付サーバ１０１では、チケット発行処理部２１
１によるチケット発行処理（図１７）で、新たな受付番
号を取得し、該受付番号と該メッセージダイジェストを
対応させて記憶するとともに、その受付番号を代理人装
置１０４に送る。その受付番号を送るためのデータがチ
ケットである。 代理人装置１０４は、チケットにより受付番号を受取
り、該受付番号を付けて実際に送付しようとするデータ
を、書類受付サーバ１０１に送る。 書類受付サーバ１０１では、代理人装置１０４からの
データをすべて受信した後、そのデータを一方向関数
（で使用したのと同じ関数）で圧縮しメッセージダイ
ジェストを求め、それが上記で記憶してあるメッセー
ジダイジェストと一致するか否かを確認する。一致すれ
ば、チケット発行時に代理人装置１０４から実際に送付
しようと意図していたデータが実際に受信されたことに
なる。一方、一致しなければ、別のデータが送信されて
きたことになる。

【００２８】図８に、本実施の形態のシステムで書類受
付サーバ１０１から代理人装置１０４に送られるチケッ
トの内容を示す。受付番号８０１は、代理人装置１０４
から書類送付する際に、その書類送付に対応して書類受
付サーバ１０１が新たに割当てる番号である。送信者情
報８０２は、その書類を送付する送信者（代理人）を特
定する種々の情報である。有効期限８０３は、このチケ
ットの有効期限を示す。代理人装置１０４から書類送付
する際に、再送が発生しても当該書類の送付に十分な時
間だけ有効期限（チケット発行時から所定時間を取れば
よい）を取っておけばよい。無制限に遅れて書類送付さ
れることを防ぐため、有効期限８０３を決めてある。署
名８０４は、８０１〜８０３のデータに対して書類受付
サーバ１０１の署名を付したものである。

【００２９】図９は、本実施の形態のシステムで使用す
る図１の受付管理ＤＢ２３１の内容を示す。書類受付サ
ーバ１０１は、上記のチケット発行処理（図１７）で
新たな受付番号を取得する際に、この受付管理ＤＢ２３
１上で新たな受付番号を取得し、その受付番号に対応す
る１行分の領域を確保する。受付番号９０１、送信者情
報９０２、および有効期限９０３には、送信したチケッ
ト（図８）に設定した情報８０１〜８０３と同内容を記
憶しておく。メッセージダイジェスト９０４、および送
信者証明書９０５には、上記で代理人装置１０４から
送られてくる情報を記憶しておく。また、チケット管理
情報９０６は、当該チケットが使用されたか否かのフラ
グ情報を記憶するもので、初期値は「未使用」にしてお
く。書類の内容９０７は、代理人装置１０４から送られ
てくる書類の全体を記憶しておく領域である。上記で
メッセージダイジェストの一致確認がなされたら、チケ
ット管理情報９０６を「使用済み」とし、受信した書類
データを書類の内容９０７に記憶するものである。

【００３０】再び、図２に戻って、書類受付サーバ１０
１の構成の説明を続ける。署名生成部２１３および暗号
化／復号化処理部２１４は、書類受付処理を行なうにあ
たって、送受するデータに署名を付すとき、および暗号
化／復号化処理を行なうときに使用する。通信制御部２
１５は、インターネット１１０との間の通信制御を行な
う。

【００３１】支払い受付サーバ１０２は、申請人からの
料金支払いを受付ける。この実施の形態のシステムで
は、申請人は申請人装置１０５から支払い受付サーバ１
０２に接続して、料金支払い処理を行なうことができ
る。支払い受付処理部２２１は、その申請人からの料金
支払い要求を受付ける処理（図１３で詳しく説明する）
を行ない、申請人が料金支払いを行なったこと（あるい
は支払うことが保証されたこと）を示す支払い証明書を
申請人に発行する。支払い証明書は、印紙や証紙、ある
いは金券や商品券のような役割を果たすものである。支
払い証明書の発行は、当該申請人について金融機関に対
して支払い信用照会を行なった上で発行するようになっ
ているので、書類受け付けサーバ１０１および支払い受
付サーバ１０２の運営機関は、支払い証明書を発行した
金額については必ず当該申請人の口座から引き落としが
できる。また、支払い証明書は、予納とは異なり、あら
かじめ予納口座を開く必要はない。支払い証明書は、印
紙のように、別件に使用したり他人に贈与してもよい。

【００３２】図６に、本実施の形態のシステムで用いる
支払い証明書の内容を示す。支払い証明書は、管理番号
６０１、支払い金額６０２、申請人情報６０３、有効期
限６０４、および支払い受付サーバ１０２の署名６０５
を備えている。管理番号６０１は、支払い証明書に固有
の管理番号である。支払い金額６０２は、申請人が支払
うことを指定した金額の情報である。申請人情報６０３
は、支払い要求を出して当該支払い証明書を受け取った
申請人を特定する情報である。有効期限６０４は、当該
支払い証明書の有効期限である。署名６０５は、当該支
払い証明書を発行した支払い受付サーバ１０２の署名で
あり、これにより当該支払い証明書が確かに支払い受付
サーバ１０２から発行されたことが保証される。これら
の情報６０１〜６０５は、支払い受付サーバ１０２が当
該支払い証明書を発行する際に設定するものである。

【００３３】図７は、本実施の形態のシステムで使用す
る図１の支払い証明書管理ＤＢ２３４の内容を示す。支
払い受付サーバ１０２は、発行した支払い証明書を、こ
の支払い証明書管理ＤＢ２３４で管理する。支払い証明
書管理ＤＢ２３４の７０１〜７０５には、発行した支払
い証明書の６０１〜６０５の情報を記憶しておく。しよ
う状態７０６は、当該支払い証明書が使用されているか
否かを示すフラグである。書類受付サーバ１０１が書類
を受付けたとき、その書類に付いてきた支払い証明書の
管理番号６０１で支払い証明書管理ＤＢ２３４を検索
し、対応するエントリを探す。そのエントリの使用状態
７０６が「未使用」であれば、その支払い証明書は未だ
使用されていなかったものであるから、その使用状態７
０６を「使用済み」とする。これは印紙や証紙などの貼
付を確認することに相当するものである。再度同じ支払
い証明書を使った書類が送付されてきたときは、使用状
態７０６が「使用済み」であるので、料金支払いが保証
されていないことが確認される。

【００３４】図７のような支払い証明書管理ＤＢ２３４
で支払い証明書を管理しているので、料金を支払う申請
人と書類の送付を実際に実行する代理人とが異なる場合
でも手続できる。また、支払い証明書を他人に譲渡し
て、その他人が使用することもできる。

【００３５】再び、図１に戻って、支払い受付サーバ１
０２の構成の説明を続ける。署名生成部２２２および暗
号化／復号化処理部は、支払い受付処理を行なうにあた
って、送受するデータに署名を付すとき、および暗号化
／復号化処理を行なうときに使用する。支払い証明書生
成管理部２２４は、図６の構成の支払い証明書を生成
し、図７の支払い証明書管理ＤＢ２３４で管理する処理
を行なう。ＳＥＴ処理部２２５は、支払い受付サーバ１
０２から金融機関サーバ１０６に対して申請人の信用照
会を行なう際にＳＥＴプロトコルにしたがう処理を行な
う。通信制御部２２６は、インターネット１１０との間
の通信制御を行なう。

【００３６】書類受付サーバ１０１および支払いサーバ
１０２の両方からアクセスできる共通ＤＢである受付管
理ＤＢ２３１および支払い証明書管理ＤＢ２３４につい
ては、図９および図７により説明した。鍵・証明書管理
ＤＢ２３２は、この書類受付サーバ１０１および支払い
サーバ１０２の秘密鍵、公開鍵、および認証局１０３，
１０７から発行してもらった証明書、認証を行なう際に
使用する認証局１０３，１０７の公開鍵、並びに、通信
相手の公開鍵などを管理するＤＢである。申請人・代理
人管理ＤＢ２３３は、この書類受付サーバ１０１および
支払いサーバ１０２に接続してくる申請人や代理人に関
する情報を管理するＤＢである。

【００３７】なお、この実施の形態では、書類受付サー
バ１０１と支払いサーバ１０２とを別装置で分け、共通
ＤＢ２０３を共通に使用するような構成としたが、共通
ＤＢとせず、完全にＤＢを分けて構成してもよい。その
場合は、受付管理ＤＢ２３１は書類受付サーバ１０１で
管理し、支払い証明書管理ＤＢ２３４は支払い受付サー
バ１０２で管理すればよい。逆に、書類受付サーバ１０
１および支払いサーバ１０２をＤＢ２０３も含めて１台
の装置上に構成してもよい。その場合は、通信制御部、
署名生成部、暗号化／復号化処理部などは共通の構成と
してもよい。

【００３８】図３は、図１の認証局１０３の構成を示
す。認証局１０３は、証明書発行処理部３０１、証明書
管理部３０２、通信制御部３０４、および証明書管理Ｄ
Ｂ３１１を備えている。認証局１０３は、あらかじめ代
理人や申請人に証明書を発行する。

【００３９】図４は、図１の代理人装置１０４の構成を
示す。代理人装置１０４は、申請書エディタ４０１、署
名生成部４０２、暗号化／復号化処理部４０３、書類送
付処理部４０４、書類受取り処理部４０５、通信制御部
４０６、申請書管理ＤＢ４１１、および鍵・証明書管理
ＤＢ４１２を備えている。

【００４０】申請書エディタ４０１は、送付する書類を
作成するために使用するエディタである。書類送付処理
部４０４は、申請人装置１０５に書類を送付する処理
（図１０で詳しく説明する）や、書類受付サーバ１０１
に支払い証明書付き書類を送付する処理（図１６で詳し
く説明する）を行なう。書類受取り処理部４０５は、申
請人から送られてくる支払い証明書付き書類の受取り処
理（図１５で詳しく説明する）を行なう。署名生成部４
０２および暗号化／復号化処理部４０３は、送受するデ
ータに署名を付すとき、および暗号化／復号化処理を行
なうときに使用する。通信制御部４０６は、インターネ
ット１１０との間の通信制御を行なう。

【００４１】申請書管理ＤＢ４１１は、申請書エディタ
４０１で作成した書類や、申請人から送られてくる支払
い証明書付き書類を保存して管理するＤＢである。鍵・
証明書管理ＤＢ４１２は、この代理人装置１０４の秘密
鍵、公開鍵、および認証局１０３，１０７から発行して
もらった証明書、認証を行なう際に使用する認証局１０
３，１０７の公開鍵、並びに、通信相手の公開鍵などを
管理するＤＢである。

【００４２】図５は、図１の申請人装置１０５の構成を
示す。申請人装置１０５は、書類受取り処理部５０１、
受取り書類管理部５０２、暗号化／復号化処理部５０
３、署名生成部５０４、支払い処理部５０５、書類送付
処理部５０６、支払い証明書管理部５０７、通信制御部
５０８、申請書管理ＤＢ５１１、鍵・証明書管理ＤＢ５
１２、および支払い証明書管理ＤＢ５１３を備えてい
る。

【００４３】書類受取り処理部５０１は、代理人から送
られてくる書類の受取り処理（図１１で詳しく説明す
る）を行なう。支払い処理部５０５は、支払い受付サー
バ１０２に接続して支払いを行なう処理（図１２で詳し
く説明する）を行なう。書類送付処理部５０６は、代理
人に対して支払い証明書付き書類などを送付する処理
（図１４で詳しく説明する）を行なう。署名生成部５０
４および暗号化／復号化処理部５０３は、送受するデー
タに署名を付すとき、および暗号化／復号化処理を行な
うときに使用する。支払い証明書管理部５０７は、支払
い受付サーバ１０２から発行してもらった支払い証明書
を支払い証明書管理ＤＢ５１３で管理する処理を行な
う。通信制御部５０８は、インターネット１１０との間
の通信制御を行なう。

【００４４】申請書管理ＤＢ５１１は、代理人から送ら
れてくる書類などを保存して管理するＤＢである。鍵・
証明書管理ＤＢ５１２は、この申請人装置１０５の秘密
鍵、公開鍵、および認証局１０３，１０７から発行して
もらった証明書、認証を行なう際に使用する認証局１０
３，１０７の公開鍵、並びに、通信相手の公開鍵などを
管理するＤＢである。支払い証明書管理ＤＢ５１３は、
支払い受付サーバ１０２から発行してもらった支払い証
明書を保存して管理するＤＢである。その構成は、図７
で説明した支払い受付サーバ１０２の支払い証明書管理
ＤＢ２３４と同じである。ただし、支払い証明書管理Ｄ
Ｂ５１３は、この申請人が受け取った支払い証明書を管
理するものであり、使用状態７０６はこの申請人が使用
したか否かを示す情報である。

【００４５】次に、図１０〜図１８のフローチャートを
参照して、図１のシステムにおける各処理の詳細を説明
する。

【００４６】図１０は、代理人装置１０４から申請人装
置１０５への書類送付の流れを示すフローチャートであ
る。この処理は、主として図４の書類送付処理部４０４
による処理である。まず代理人は、申請人の依頼に基づ
いて、図４の申請書エディタ４０１を用いて書類を作成
しておく。ステップ１００１で、送付する該書類に対し
て代理人の電子署名を実施する。具体的には、書類デー
タを一方向関数（ハッシュ関数など）で圧縮し、その圧
縮データ（メッセージダイジェスト）を代理人の秘密鍵
で暗号化した署名データを、元の書類データに付して、
代理人署名付き書類を作る。次に、ステップ１００２
で、代理人署名付き書類を暗号化する共通鍵を生成し、
その共通鍵で代理人署名付き書類を暗号化する。次に、
ステップ１００３で、申請人の公開鍵によって前記共通
鍵を暗号化する。ステップ１００４では、暗号化された
代理人署名付き書類と共通鍵を、代理人の証明書と共に
申請人装置１０５に送信し、処理を終了する。

【００４７】なお、代理人の証明書は、あらかじめ認証
局１０３から取得しておく。代理人の証明書とは、代理
人の公開鍵を該代理人に関する種々の情報と連結し、該
連結データに対し認証局１０３の秘密鍵で署名を付した
データである。認証局１０３は、代理人から証明書発行
依頼を受けたとき、当該代理人の身元確認を行なった
後、証明書を発行する。代理人装置１０４から送信する
データにこの証明書を付ければ、当該データが確かに当
該代理人から送られたものであることを、この証明書に
よって検証することができ、またこの証明書から代理人
の公開鍵や代理人を特定する種々の情報を取得すること
ができる。同様にして、申請人も、あらかじめ認証局１
０３から証明書を取得しておく。

【００４８】図１１は、図１０の処理により代理人装置
１０４から申請人装置１０５へ送られたデータを受取る
申請人装置１０５の処理の流れを示す。この処理は、主
として図５の書類受取り処理部５０１による処理であ
る。まずステップ１１０１で、受信データ中の代理人の
証明書を検証するとともに、受信データ中の暗号化され
た共通鍵を申請人の秘密鍵を用いて復号化する。ステッ
プ１１０２で、復号化された共通鍵を用いて、代理人署
名付き書類を復号化する。ステップ１１０３では、その
代理人署名付き書類の署名を代理人の公開鍵を用いて検
証する。この検証は、署名データを代理人の公開鍵で復
号化した値が、書類データを一方向関数（図１０のステ
ップ１００１で使用したのと同じ関数を用いる）で圧縮
した圧縮データ（メッセージダイジェスト）に等しくな
るか否かを確認する処理である。検証の結果、適正な署
名であったら、ステップ１１０５で当該代理人署名付き
書類を保管する。検証の結果、適正な署名でなかった
ら、ステップ１１０６で申請書類が改ざんされているこ
とを申請人に報告して、処理を終了する。

【００４９】図１２は、申請人による料金支払い処理の
流れを示すフローチャートである。この処理は、主とし
て図５の支払い処理部５０５による処理である。まずス
テップ１２０１で、申請人装置１０５から支払い受付サ
ーバ１０２に接続し、支払い金額を決定・送信する。ス
テップ１２０２で、申請人の証明書（認証局１０３から
取得した証明書）を支払い受付サーバ１０２に提示す
る。ステップ１２０３は、支払い受付サーバ１０２側の
処理であり、図１３で後述するが、支払い受付サーバ１
０２からは、申請人の公開鍵で暗号化された共通鍵と該
共通鍵で暗号化された支払い証明書（図６）が送信され
てくる。ステップ１２０４では、支払い受付サーバ１０
２から送信された暗号化された共通鍵を申請人の秘密鍵
で復号化する。ステップ１２０５では、復号化された共
通鍵を用いて、暗号化された支払い証明書を復号化す
る。ステップ１２０６で、復号化された支払い証明書
を、支払い証明書管理ＤＢ５１３（図７）に保管して、
処理を終了する。

【００５０】図１３は、図１２のステップ１２０３の処
理、すなわち支払い受付サーバ１０２における支払い受
付処理の流れを示すフローチャートである。この処理
は、主として図２の支払い受付処理部２２１による処理
である。まず、ステップ１３０１で、申請人から送られ
た証明書を検証し、申請人の公開鍵を取得する。次にス
テップ１３０２で、例えばＳＥＴのプロトコルを用い
て、申請人からの支払い信用照会（与信）を金融機関に
対して実施する。具体的には、図１の金融機関サーバ１
０６に申請人と引き落とし金額を特定する情報を送信
し、該申請人の口座からその引き落とし金額分を確保す
る。

【００５１】なお、金融機関に対して支払い信用照会を
実施する際、支払い受付サーバ１０２を運営する機関の
身元を証明するため、あらかじめ支払い受付サーバ１０
２を運営する機関は、金融機関認証局１０７から証明書
を取得しておく必要がある。また、この支払い信用照会
では、引き落としを行なう申請人についての認証も行な
うので（確かにその申請人からの引き落とし依頼である
かどうかを確認する必要がある）、あらかじめ申請人は
金融機関認証局１０７から証明書を取得しておくととも
に、その金融機関の証明書をステップ１２０２で支払い
受付サーバ１０２に送り、支払い受付サーバ１０２はス
テップ１３０２で信用照会するときその申請人の金融機
関の証明書を付けて信用照会する必要がある。

【００５２】ステップ１３０２の信用照会の結果、ステ
ップ１３０３で、上記引き落とし金額分の引き落とし枠
が確保できたらステップ１３０４に進む。信用照会結果
に何らかの問題があったら、処理を終了する。ステップ
１３０４では、新たに発行する支払い証明書の管理番号
を取得する。具体的には、図７の構成の支払い証明書管
理ＤＢ２３４で新規管理番号の一行分の領域を確保す
る。次に、ステップ１３０５で、申請人の証明書から申
請人を特定する情報を抽出する。ステップ１３０６で
は、管理番号、支払い金額、申請人を特定する情報、お
よび有効期限を連結したデータに電子署名を実施して、
支払い証明書（図６）を作成する。具体的には、上記連
結データを一方向関数（ハッシュ関数など）で圧縮し、
その圧縮データを支払い受付サーバ１０２の秘密鍵で暗
号化した署名データを、元の連結データに付して、支払
い証明書を作る。

【００５３】ステップ１３０７では、作成した支払い証
明書に含めた情報を支払い証明書管理ＤＢ２３４（図
７）に記録する。そして、ステップ１３０８で、支払い
証明書を暗号化するための共通鍵を生成し、その共通鍵
で支払い証明書を暗号化する。次に、ステップ１３０９
で、申請人の公開鍵によって前記共通鍵を暗号化する。
ステップ１３１０では、暗号化された共通鍵と該共通鍵
で暗号化された支払い証明書とを申請人装置１０５に送
信し、処理を終了する。

【００５４】図１４は、申請人装置１０５から代理人装
置１０４への書類送付の流れを示すフローチャートであ
る。この処理は、主として図５の書類送付処理部５０６
による処理である。まずステップ１４０１で、図１１の
ステップ１１０５で保管してある代理人署名付き書類を
取り出す。ステップ１４０２では、代理人署名付き書類
と支払い証明書とを含めたデータに対して、申請人の電
子署名を実施する。これを支払い証明書付き書類と呼
ぶ。なお、ここで使用する支払い証明書は、図７の構成
の支払い証明書管理ＤＢ５１３で管理されている支払い
証明書のうち、使用状況７０６が「未使用」のものを使
用する。使用した支払明細書の使用状況７０６は「使用
済み」に変更しておく。

【００５５】次に、ステップ１４０３で、共通鍵を生成
し、該共通鍵で支払い証明書付き書類を暗号化する。ス
テップ１４０４で、代理人の公開鍵を用いて、前記共通
鍵を暗号化する。ステップ１４０５では、暗号化された
共通鍵と該共通鍵で暗号化された支払い証明書付き書類
を代理人装置１０４に送信する。

【００５６】図１５は、図１４で送信された申請人から
のデータを受取る代理人装置１０４の処理の流れを示す
フローチャートである。この処理は、主として図４の書
類受取り処理部４０５による処理である。まずステップ
１５０１で、受信データ中の暗号化された共通鍵を代理
人の秘密鍵を用いて復号化する。ステップ１５０２で、
復号化された共通鍵を用いて、支払い証明書付き書類を
復号化する。ステップ１５０３では、その支払い証明書
付き書類に添付されている申請人の電子署名を申請人の
公開鍵を用いて検証する。この検証は、署名データを申
請人の公開鍵で復号化した値が、支払い証明書付き書類
を一方向関数（図１４のステップ１４０２の署名で使用
したのと同じ関数）で圧縮した圧縮データに等しくなる
か否かを確認する処理である。

【００５７】ステップ１５０４で、検証の結果、適正な
署名であったら、ステップ１５０６に進む。ステップ１
５０６では、支払い証明書付き書類に含まれている支払
い証明書の電子署名を支払い受付サーバ１０２の公開鍵
を用いて検証する。この検証は、署名データを支払い受
付サーバ１０２の公開鍵で復号化した値が、支払い証明
書に含まれている管理番号、支払い金額、申請人を特定
する情報、および有効期限を連結したデータを一方向関
数（図１３のステップ１３０６の署名で使用したのと同
じ関数）で圧縮した圧縮データに等しくなるか否かを確
認する処理である。

【００５８】ステップ１５０７で、検証の結果、適正な
署名であったら、ステップ１５０９に進む。ステップ１
５０９では、支払い証明書付き書類に含まれている代理
人署名付き書類中の代理人の署名を、代理人の秘密鍵を
用いて検証する。ステップ１５１０で検証結果が適正な
署名であったら、ステップ１５１２で支払い証明書付き
書類を保管して、処理を終了する。ステップ１５０４，
１５０７，１５１０の何れかのステップで、検証結果が
不正な署名であることを示していたら、それぞれ、ステ
ップ１５０５，１５０８，１５１１で書類が改ざんされ
ていることを代理人に報告して、処理を終了する。

【００５９】図１６は、代理人装置１０４から書類受付
サーバ１０１への支払い証明書付き書類の送付処理の流
れを示すフローチャートである。この処理は、主として
図４の書類送付処理部４０４による処理である。まずス
テップ１６０１で、送付しようとする支払い証明書付き
書類を一方向関数で圧縮し、圧縮データ（メッセージダ
イジェスト）を生成する。次に、ステップ１６０２で、
共通鍵を生成し、該共通鍵で上記メッセージダイジェス
トを暗号化する。ステップ１６０３では、上記共通鍵を
書類受付サーバ１０１の公開鍵で暗号化する。ステップ
１６０４では、暗号化された共通鍵と該共通化鍵で暗号
化されたメッセージダイジェストに、代理人の証明書を
添付して書類受付サーバ１０１に送付する。ステップ１
６０５は、書類受付サーバ１０１側のチケット発行処理
であり、図１７で後述するが、書類受付サーバ１０１か
らは、代理人の公開鍵で暗号化された共通鍵（書類受付
サーバ１０１側で生成した鍵）と該共通鍵で暗号化され
たチケット（図８）が送信されてくる。

【００６０】ステップ１６０６では、書類受付サーバ１
０１から送られてきた暗号化された共通鍵を、代理人の
秘密鍵を用いて復号化する。ステップ１６０７では、復
号化された共通鍵を用いてチケットを復号化する。次
に、ステップ１６０８で、書類受付サーバ１０１の公開
鍵を用いて、チケット（図８）に付いている電子署名を
検証する。ステップ１６０９で、検証結果が適正な署名
であることを示していたら、書類受付サーバ１０１が提
出日時を確保したということであるから、ステップ１６
１１に進む。ステップ１６０９で、不正な署名であった
ら、ステップ１６１０でチケットが改ざんされているこ
とを代理人に報告し、処理を終了する。

【００６１】チケットが取れたら、ステップ１６１１で
共通鍵を生成し、ステップ１６１２で支払い証明書付き
書類を該共通鍵で暗号化する。ステップ１６１３では、
該共通鍵でチケットを暗号化する。次に、ステップ１６
１４で、書類受付サーバ１０１の公開鍵で上記共通鍵を
暗号化する。そして、ステップ１６１５で、暗号化した
共通鍵、および該共通鍵で暗号化したチケットと支払い
証明書付き書類を書類受付サーバ１０１に送付する。ス
テップ１６１６は、書類受付サーバ１０１側の処理であ
り、図１８で後述するが、書類受付サーバ１０１から
は、代理人の公開鍵で暗号化された共通鍵と該共通鍵で
暗号化された受付確認書が送信されてくる。

【００６２】ステップ１６１７では、書類受付サーバ１
０１から送信された暗号化された共通鍵を代理人の秘密
鍵で復号化する。ステップ１６１８では、復号化された
共通鍵を用いて、暗号化された受付確認書を復号化す
る。ステップ１６１９で、受付確認書に添付された書類
受付サーバ１０１の電子署名を検証する。ステップ１６
２０で検証結果が適正な署名であることを示していた
ら、ステップ１６２２で、受付確認書を保管して、処理
を終了する。ステップ１６２０で、検証結果が不正な署
名であることを示していたら、ステップ１６２０で何ら
かのデータ改ざんがなされたことを代理人に報告し、処
理を終了する。

【００６３】図１７は、図１６のステップ１６０５の処
理、すなわち書類受付サーバ１０１のチケット発行処理
の流れを示すフローチャートである。この処理は、主と
して図２のチケット発行処理部２１１による処理であ
る。まずステップ１７０１で、書類受付サーバ１０１の
秘密鍵を用いて、代理人から送られてきた共通鍵を復号
化する。次に、ステップ１７０２で、該共通鍵を用いて
メッセージダイジェストを復号化する。そして、ステッ
プ１７０３で、新たな受付番号を取得し、該受付番号９
０１、代理人（送信者）に関する情報９０２、有効期限
９０３、メッセージダイジェスト９０４、および代理人
の証明書９０５を、受付管理ＤＢ２３１（図９）に保管
する。なお、代理人に関する情報は、代理人から送られ
てきたデータに含まれている代理人の証明書から抽出し
た情報を設定する。有効期限は、現時点に所定時間を加
えた時間を設定する。また、チケットの管理情報９０６
は「未使用」に初期化しておく。

【００６４】次に、ステップ１７０４では、受付番号
と、代理人に関する情報と、有効期限とを連結したデー
タを生成し、該連結データに対して電子署名を実施す
る。この電子署名付きデータがチケット（図８）であ
る。具体的には、上記連結データを一方向関数（図１６
のステップ１６０１や１６０８で用いたのと同じ関数）
で圧縮し、その圧縮データを書類受付サーバ１０１の秘
密鍵で暗号化した署名データを、元の連結データに付し
て、チケット（図８）を作る。次に、ステップ１７０５
で、共通鍵を生成し、該共通鍵で上記チケットを暗号化
する。ステップ１７０６では、代理人の公開鍵を用い
て、上記共通鍵を暗号化する。ステップ１７０７で、暗
号化された共通鍵、および該共通鍵で暗号化されたチケ
ットを代理人に対して送付し、処理を終了する。

【００６５】図１８は、図１６のステップ１６１６の処
理、すなわち書類受付サーバ１０１による書類受付処理
の流れを示すフローチャートである。この処理は、主と
して図２の書類受付処理部２１２により実行される処理
である。まずステップ１８０１で、書類受付サーバ１０
１の秘密鍵を用いて、代理人から送られてきた共通鍵を
復号化する。ステップ１８０２で、復号化された共通鍵
を用いて、チケットと支払い証明書付き書類を復号化す
る。次に、ステップ１８０３で、チケットに付いている
電子署名、および有効期限を検証する。検証の結果、ス
テップ１８０４で、署名も適正で有効期限内であるとき
は、ステップ１８０６に進む。署名が不正、または有効
期限が過ぎていた場合は、ステップ１８０５でチケット
不正を表示して、処理を終了する。

【００６６】ステップ１８０６では、代理人から送付さ
れてきた支払い証明書付き書類を、代理人装置１０４で
使用した一方向関数（図１６のステップ１６０１や１６
０８で用いたのと同一の関数）で圧縮し、メッセージダ
イジェストを生成する。ステップ１８０７では、代理人
から送付されてきたチケットから受付番号を取り出し、
受付管理ＤＢ２３１（図９）を参照して、当該受付番号
に対応するチケット請求時のメッセージダイジェストを
取り出し、ステップ１８０６で生成したメッセージダイ
ジェストと比較する。比較の結果、ステップ１８０８で
同一であれば、確かにチケット請求時に送ろうとしてい
た内容が送られてきたものと認められるので、ステップ
１８１０に進む。ステップ１８０８で比較の結果が同一
でないときは、チケット請求時に送ろうとしていた内容
と別の内容が送られてきたということだから、ステップ
１８０９で送付データ不一致の表示を行ない、処理を終
了する。

【００６７】ステップ１８１０では、支払い証明書に含
まれている管理番号のデータを支払い証明書管理ＤＢ２
３４（図７）から検索し、その使用状況７０６が「未使
用」であるか否かを検証する。ステップ１８１１で、
「未使用」であったときは、ステップ１８１３で、支払
い証明書管理ＤＢ２３４の当該管理番号の支払い証明書
の使用状況７０６を「使用済み」に変更する。次に、ス
テップ１８１４で、当該受付番号のチケットの管理情報
９０６を「使用済み」に変更する。そして、ステップ１
８１５で、支払い証明書付き書類を保管する。書類の保
管は、図９の受付管理ＤＢ２３１の書類の内容９０７に
格納することにより行なう。

【００６８】さらに、ステップ１８１６で、受付番号な
どの受付情報を含む受付確認書を作成し、電子署名を実
行する。ステップ１８１７で、共通鍵を生成し、該共通
鍵で上記電子署名付き受付確認書を暗号化する。ステッ
プ１８１８では、代理人の公開鍵で上記共通鍵を暗号化
する。ステップ１８１９で、暗号化した共通鍵、および
該共通鍵で暗号化した電子署名付き受付確認書を代理人
に送付して、処理を終了する。

【００６９】上記実施の形態のシステムによれば、申請
人が支払い証明書を取得し、代理人が提出書類に支払い
証明書を付けて、書類受付サーバに送付することが可能
になる。支払い証明書は、印紙や証紙、金券や商品券の
ようなイメージで使用することができ、支払い受付サー
バの署名が付いているので容易に改ざんされない。実際
の決済はどのような形態で行なってもよいが、与信の段
階で引き落とし可能であることが保証されるので、書類
受付サーバの側では必ず料金を徴収できる。また、申請
人が書類に支払い証明書を付けて、その全体に署名を付
して、代理人に送っているので、申請人が当該書類の内
容で了解しているという意志表示をしたことになるし、
その後代理人が書類を改ざんすることもできない。

【００７０】さらに、書類提出時点を決定する際、始め
に提出者から送付しようとする書類データを一方向関数
で圧縮してメッセージダイジェストを求め、これを証明
書と一緒に書類受付サーバに送り、書類受付サーバでは
そのメッセージダイジェストを記憶して、チケットを返
す。その後、提出者から書類データの全体が送られてき
たときには、そのメッセージダイジェストを求めて、チ
ケット発行時に記憶してあるメッセージダイジェストと
比較することで、当初から送る予定の書類が確かに送ら
れてきたことを確認できる。そのため、チケット発行時
を書類提出時点とみなすことができるようになる。

【００７１】なお、上記実施の形態では、代理人が申請
者を代理して書類提出を行なう例を説明したが、代理人
経由でなく、直接、申請人が書類受付サーバに対する書
類送付を行なうようにしてもよい。

【００７２】また、上記実施の形態では、支払方式とし
てＳＥＴを用いた例を説明したが、ＳＥＴ以外の支払方
式、例えばＳＥＴを使わないクレジットカード支払いの
方式などを用いてもよい。

【００７３】本発明は、特許庁、登記所、あるいは役所
などの官公庁に対してインターネット経由で書類を送付
する場合などに適用可能である。また、いわゆる電子シ
ョッピングなどに適用することも可能である。

【００７４】

【発明の効果】以上説明したように、本発明によれば、
インターネットなどを介して通信で電子的な書類提出を
行なう際に手数料の支払いが必要な場合において、支払
い受付サーバに対して支払い依頼を出せば、支払い受付
サーバが信用照会を実施し、料金の支払いが保証される
場合にはその旨を示す改ざん不可能な形式の支払い証明
書を発行してくれるので、予納口座のような特別な口座
を作る必要が無く、クレジットカードや銀行口座から別
フェーズで引き落とし処理を行なう場合に引き落とせな
いというようなことも無く、また料金を支払う者と書類
の提出を行なう者とが異なる場合でも適正に書類提出と
その料金支払いを行なうことができる。

【００７５】また、書類を送付する前に、送付する書類
を一方向関数で圧縮した圧縮データを送り、あとで実際
に送られてきた書類に対して同じ一方向関数で圧縮した
圧縮データと比較確認しているので、通信で電子的な書
類提出を行なう場合に、悪用を許すことなく、提出日時
を合理的に決定する仕組みが提供される。

【図面の簡単な説明】

【図１】本発明の実施の形態の書類送付システムの全体
図

【図２】書類受付サーバおよび支払い受付サーバの内部
構成図

【図３】認証局の構成図

【図４】代理人装置の構成図

【図５】申請人装置の構成図

【図６】本実施の形態のシステムで用いる支払い証明書
の内容を示す図

【図７】本実施の形態のシステムで使用する支払い証明
書管理ＤＢの内容を示す図

【図８】本実施の形態のシステムで書類受付サーバから
代理人装置に送られるチケットの内容を示す図

【図９】本実施の形態のシステムで使用する受付管理Ｄ
Ｂの内容を示す図

【図１０】代理人装置から申請人装置への書類送付の流
れを示すフローチャート図

【図１１】代理人装置から申請人装置へ送られたデータ
を受取る申請人装置の処理の流れを示すフローチャート
図

【図１２】申請人による料金支払い処理の流れを示すフ
ローチャート図

【図１３】支払い受付サーバにおける支払い受付処理の
流れを示すフローチャート図

【図１４】申請人装置から代理人装置への書類送付の流
れを示すフローチャート図

【図１５】申請人からのデータを受取る代理人装置の処
理の流れを示すフローチャート図

【図１６】代理人装置から書類受付サーバへの支払い証
明書付き書類の送付処理の流れを示すフローチャート図

【図１７】書類受付サーバのチケット発行処理の流れを
示すフローチャート図

【図１８】書類受付サーバによる書類受付処理の流れを
示すフローチャート図

【符号の説明】

１０１…書類受付サーバ、１０２…支払い受付サーバ、
１０３…認証局、１０４…代理人装置、１０５…申請人
装置、１０６…金融機関サーバ、１０７…金融機関認証
局、１１０…インターネット。

Claims (6)

【特許請求の範囲】
1. 【請求項１】ネットワーク経由で、申請人装置から書類
   受付サーバに対して書類を送付する書類送付システムに
   おいて、 前記ネットワークに、支払い受付サーバを接続し、 前記申請人装置は、前記支払い受付サーバに対して、支
   払い金額を指定して料金支払いを依頼する手段を備え、 前記支払い受付サーバは、前記申請人装置からの料金支
   払い依頼に応じて、金融機関に対する支払い信用照会を
   実施する手段と、該信用照会で前記申請人の料金支払い
   が保証されることが判明したときには、該料金支払いが
   保証される旨を示す支払い証明書を改ざん不可能な形式
   で作成し、前記申請人装置に送信する手段とを備え、 前記申請人装置は、送付する書類に前記支払い証明書を
   付して改ざん不可能な形式である支払い証明書付き書類
   とし、前記書類受付サーバに送信する手段を備え、 前記書類受付サーバは、前記申請人装置から送られてき
   た支払い証明書が未使用のものであることを確認した
   後、該支払い証明書付き書類を保管する手段を備えたこ
   とを特徴とする書類送付システム。
2. 【請求項２】ネットワーク経由で、申請人装置が送付し
   たい書類を、代理人装置が代理して書類受付サーバに対
   して送付する書類送付システムにおいて、 前記ネットワークに、支払い受付サーバを接続し、 前記申請人装置は、前記支払い受付サーバに対して、支
   払い金額を指定して料金支払いを依頼する手段を備え、 前記支払い受付サーバは、前記申請人装置からの料金支
   払い依頼に応じて、金融機関に対する支払い信用照会を
   実施する手段と、該信用照会で前記申請人の料金支払い
   が保証されることが判明したときには、該料金支払いが
   保証される旨を示す支払い証明書を改ざん不可能な形式
   で作成し、前記申請人装置に送信する手段とを備え、 前記申請人装置は、送付する書類に前記支払い証明書を
   付して改ざん不可能な形式である支払い証明書付き書類
   とし、前記代理人装置に送信する手段を備え、 前記代理人装置は、受信した支払い証明書付き書類を前
   記書類受付サーバに送信する手段を備え、 前記書類受付サーバは、前記代理人装置から送られてき
   た支払い証明書が未使用のものであることを確認した
   後、該支払い証明書付き書類を保管する手段を備えたこ
   とを特徴とする書類送付システム。
3. 【請求項３】ネットワーク経由で、申請人装置から書類
   受付サーバに対して書類を送付する書類送付システムに
   おいて、該書類の送付に伴う料金の支払いを受付ける支
   払い受付サーバであって、 前記申請人装置からの料金支払い依頼に応じて、金融機
   関に対する支払い信用照会を実施する手段と、 該信用照会で前記申請人の料金支払いが保証されること
   が判明したときには、該料金支払いが保証される旨を示
   す支払い証明書を改ざん不可能な形式で作成し、前記申
   請人装置に送信する手段とを備えたことを特徴とする書
   類送付システムの支払い受付サーバ。
4. 【請求項４】ネットワーク経由で、所定の装置から書類
   受付サーバに対して書類を送付する書類送付システムに
   おいて、 前記書類を送付する装置で、送付したい書類データに一
   方向関数を施して圧縮データを取得し、該圧縮データを
   改ざん不可能な形式で前記書類受付サーバに送信する手
   段と、 前記書類受付サーバで、受信した圧縮データを記憶した
   のち、前記書類を送付する装置にチケットを送信する手
   段と、 前記書類を送付する装置で、チケットを受信したら、送
   付したい書類データの前記書類受付サーバへの送信を実
   行する手段と、 前記書類受付サーバで、前記書類データをすべて受信し
   たら、該書類データに前記一方向関数を施して得た圧縮
   データと、前記記憶してある圧縮データとを比較し、そ
   れらの圧縮データが一致することを確認する手段とを備
   えたことを特徴とする書類送付システム。
5. 【請求項５】ネットワーク経由で、申請人装置から書類
   受付サーバに対して書類を送付する書類送付方法におい
   て、 前記ネットワークに、支払い受付サーバを接続するとと
   もに、 前記申請人装置から、前記支払い受付サーバに対して、
   支払い金額を指定して料金支払いを依頼するステップ
   と、 前記支払い受付サーバにより、前記申請人装置からの料
   金支払い依頼に応じて、金融機関に対する支払い信用照
   会を実施するステップと、 該信用照会で前記申請人の料金支払いが保証されること
   が判明したときには、該料金支払いが保証される旨を示
   す支払い証明書を改ざん不可能な形式で作成し、前記申
   請人装置に送信するステップと、 前記申請人装置により、送付すべき書類に前記支払い証
   明書を付して改ざん不可能な形式である支払い証明書付
   き書類とし、前記書類受付サーバに送信するステップ
   と、 前記書類受付サーバにより、前記申請人装置から送られ
   てきた支払い証明書が未使用のものであることを確認し
   た後、該支払い証明書付き書類を保管するステップとを
   備えたことを特徴とする書類送付方法。
6. 【請求項６】ネットワーク経由で、所定の装置から書類
   受付サーバに対して書類を送付する書類送付方法におい
   て、 前記書類を送付する装置で、送付したい書類データに一
   方向関数を施して圧縮データを取得し、該圧縮データを
   改ざん不可能な形式で前記書類受付サーバに送信するス
   テップと、 前記書類受付サーバで、受信した圧縮データを記憶した
   のち、前記書類を送付する装置にチケットを送信するス
   テップと、 前記書類を送付する装置で、チケットを受信したら、送
   付したい書類データの前記書類受付サーバへの送信を実
   行するステップと、 前記書類受付サーバで、前記書類データをすべて受信し
   たら、該書類データに前記一方向関数を施して得た圧縮
   データと、前記記憶してある圧縮データとを比較し、そ
   れらの圧縮データが一致することを確認するステップと
   を備えたことを特徴とする書類送付方法。