JP2002117361A - 電子決済方法及び電子決済システム - Google Patents
電子決済方法及び電子決済システムInfo
- Publication number
- JP2002117361A JP2002117361A JP2000313119A JP2000313119A JP2002117361A JP 2002117361 A JP2002117361 A JP 2002117361A JP 2000313119 A JP2000313119 A JP 2000313119A JP 2000313119 A JP2000313119 A JP 2000313119A JP 2002117361 A JP2002117361 A JP 2002117361A
- Authority
- JP
- Japan
- Prior art keywords
- payment
- intention
- transfer account
- electronic
- settlement
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 194
- 238000012546 transfer Methods 0.000 claims abstract description 473
- 238000012545 processing Methods 0.000 claims description 407
- 230000005540 biological transmission Effects 0.000 claims description 18
- 230000000737 periodic effect Effects 0.000 claims description 17
- 230000004044 response Effects 0.000 claims description 11
- 238000012790 confirmation Methods 0.000 claims description 8
- 238000010586 diagram Methods 0.000 description 18
- 238000004891 communication Methods 0.000 description 11
- 238000012795 verification Methods 0.000 description 11
- 230000000875 corresponding effect Effects 0.000 description 9
- 230000006870 function Effects 0.000 description 5
- 230000000694 effects Effects 0.000 description 3
- 230000002452 interceptive effect Effects 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 2
- 238000007796 conventional method Methods 0.000 description 2
- 230000002079 cooperative effect Effects 0.000 description 2
- 230000002427 irreversible effect Effects 0.000 description 2
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 1
- FFBHFFJDDLITSX-UHFFFAOYSA-N benzyl N-[2-hydroxy-4-(3-oxomorpholin-4-yl)phenyl]carbamate Chemical compound OC1=C(NC(=O)OCC2=CC=CC=C2)C=CC(=C1)N1CCOCC1=O FFBHFFJDDLITSX-UHFFFAOYSA-N 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
- 230000001755 vocal effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
(57)【要約】
【課題】本発明の課題は、金銭が受取人に受け取られな
かった場合に、支払人の決済手続きの負担を軽減するこ
とである。 【解決手段】保険庁システム1100が支払意図を決済
仲介システム1200へ通知し、決済仲介システム12
00が支払意図の通知を受けた場合に受益人システム1
300へ支払意図を通知し、受益人システム1300が
支払意図の通知を受けた場合に決済仲介システム120
0へ振込口座を通知し、決済仲介システム1200が支
払人により指定された支払期限又は支払期間内に振込口
座の通知を受けた場合に振込口座に支払人により指定さ
れた額の金銭を振り込む。
かった場合に、支払人の決済手続きの負担を軽減するこ
とである。 【解決手段】保険庁システム1100が支払意図を決済
仲介システム1200へ通知し、決済仲介システム12
00が支払意図の通知を受けた場合に受益人システム1
300へ支払意図を通知し、受益人システム1300が
支払意図の通知を受けた場合に決済仲介システム120
0へ振込口座を通知し、決済仲介システム1200が支
払人により指定された支払期限又は支払期間内に振込口
座の通知を受けた場合に振込口座に支払人により指定さ
れた額の金銭を振り込む。
Description
【0001】
【発明の属する技術分野】本発明は、取引により生じる
当事者間の債権債務関係を電子的に清算する電子決済方
法及び電子決済システムに関する。
当事者間の債権債務関係を電子的に清算する電子決済方
法及び電子決済システムに関する。
【0002】
【従来の技術】取引により生じる当事者間の債券債務関
係を清算する決済方法では、受取人(金銭の受取権利を
有する債権者)から支払人(金銭の支払い義務を負う債
務者)への支払請求が、個別の支払ごとに行われず、包
括的な契約に基づき継続的に支払が行われるものが存在
する。例えば、社会保険庁(債務者)から受益人(債権
者)への保険金の支払方法や雇用者(債務者)から被雇
用者(債権者)への給与の支払方法などである。以下、
包括的な契約に基づき継続的に支払が行われる決済方法
を「個別請求不要決済」という。一般に個別請求不要決
済を行う場合には、受取人が支払人に対して予め振込口
座を指定しておき、支払時に支払人が振込口座へ金銭を
振り込むことでにより実現されている。
係を清算する決済方法では、受取人(金銭の受取権利を
有する債権者)から支払人(金銭の支払い義務を負う債
務者)への支払請求が、個別の支払ごとに行われず、包
括的な契約に基づき継続的に支払が行われるものが存在
する。例えば、社会保険庁(債務者)から受益人(債権
者)への保険金の支払方法や雇用者(債務者)から被雇
用者(債権者)への給与の支払方法などである。以下、
包括的な契約に基づき継続的に支払が行われる決済方法
を「個別請求不要決済」という。一般に個別請求不要決
済を行う場合には、受取人が支払人に対して予め振込口
座を指定しておき、支払時に支払人が振込口座へ金銭を
振り込むことでにより実現されている。
【0003】一方、電子決済方法に関する従来の技術と
して、特表平10-508708号公報には、情報製品を提供す
る第2のインターネットユーザーが、情報製品を購入し
た第1のインターネットユーザーに対しインターネット
を介して情報製品を送ると同時に支払リクエストを送
り、支払リクエストを受け取った第1のインターネット
ユーザーが第2のインターネットユーザーに対しインタ
ーネット以外の方法で支払いを行う支払システムが記載
されている。
して、特表平10-508708号公報には、情報製品を提供す
る第2のインターネットユーザーが、情報製品を購入し
た第1のインターネットユーザーに対しインターネット
を介して情報製品を送ると同時に支払リクエストを送
り、支払リクエストを受け取った第1のインターネット
ユーザーが第2のインターネットユーザーに対しインタ
ーネット以外の方法で支払いを行う支払システムが記載
されている。
【0004】また、特開平11-353372号公報には、支払
者(債務者)の支払側装置に支払予約情報に支払予約番
号を付加して記憶しておき、集金者(債権者)の集金側
装置から支払予約番号を指定した支払請求がある場合
に、支払請求データと支払予約情報との一致を判定し、
支払側装置から集金側装置へ電子マネーを払い込む電子
マネー自動決済システムが記載されている。
者(債務者)の支払側装置に支払予約情報に支払予約番
号を付加して記憶しておき、集金者(債権者)の集金側
装置から支払予約番号を指定した支払請求がある場合
に、支払請求データと支払予約情報との一致を判定し、
支払側装置から集金側装置へ電子マネーを払い込む電子
マネー自動決済システムが記載されている。
【0005】しかし、特表平10-508708号公報や特開平1
1-353372号公報の発明では、支払請求が個別の支払ごと
に行われており、個別請求不要決済に関しては何ら考慮
されていない。
1-353372号公報の発明では、支払請求が個別の支払ごと
に行われており、個別請求不要決済に関しては何ら考慮
されていない。
【0006】個別請求不要決済では所定期間に支払が時
間軸において離散的に続くことが多い。よって、振込口
座を指定する決済方法では、受取人側の振込口座や連絡
先が変更され、その変更が支払人側へ連絡されない場合
に、金銭の振込が失敗することがある。振込の失敗が生
じた場合、支払人が失敗理由の調査や受取人への連絡等
の事務処理を行う必要があり、支払人の負担が過大とな
る。
間軸において離散的に続くことが多い。よって、振込口
座を指定する決済方法では、受取人側の振込口座や連絡
先が変更され、その変更が支払人側へ連絡されない場合
に、金銭の振込が失敗することがある。振込の失敗が生
じた場合、支払人が失敗理由の調査や受取人への連絡等
の事務処理を行う必要があり、支払人の負担が過大とな
る。
【0007】これに対し、金融機関に口座を持たない相
手に送金することを目的とした従来の技術として、特開
平11-265413号公報には、送金人(債権者)からATM
(Automatic Teller Machine;現金自動預け払い機)を
介して送金依頼を受け取った場合に、送金人の口座から
送金金額を引出し、受取人の仮口座レコード又は送金人
の口座の関連レコードを生成して格納し、受取人(債権
者)からATMを介して支払い依頼を受け取った場合に、
仮口座レコード又は送金人の口座の関連レコードを読み
込み支払いを行う金融処理装置が記載されている。
手に送金することを目的とした従来の技術として、特開
平11-265413号公報には、送金人(債権者)からATM
(Automatic Teller Machine;現金自動預け払い機)を
介して送金依頼を受け取った場合に、送金人の口座から
送金金額を引出し、受取人の仮口座レコード又は送金人
の口座の関連レコードを生成して格納し、受取人(債権
者)からATMを介して支払い依頼を受け取った場合に、
仮口座レコード又は送金人の口座の関連レコードを読み
込み支払いを行う金融処理装置が記載されている。
【0008】
【発明が解決しようとする課題】しかし、特開平11-265
413号公報の発明では、送金依頼時に送金者の口座から
送金金額を減算し、有効期間が過ぎても仮口座等の送金
が引き出されない場合に送金元に払い戻される。即ち、
特開平11-265413号公報の発明は、送金依頼時に送金者
の口座から送金金額を異動しており、支払い依頼時に送
金者の口座から送金金額を移動しているわけではない。
従って、送金の引き出しがされない場合は、金融処理装
置が払い戻し処理を行う必要が生じ、決済処理の手続き
が煩雑となる。特開平11-265413号公報には、口座を持
たない相手に送金するという課題を解決するための金融
処理装置が記載されているにすぎず、この金融処理装置
を利用した決済方法までは記載されていない。
413号公報の発明では、送金依頼時に送金者の口座から
送金金額を減算し、有効期間が過ぎても仮口座等の送金
が引き出されない場合に送金元に払い戻される。即ち、
特開平11-265413号公報の発明は、送金依頼時に送金者
の口座から送金金額を異動しており、支払い依頼時に送
金者の口座から送金金額を移動しているわけではない。
従って、送金の引き出しがされない場合は、金融処理装
置が払い戻し処理を行う必要が生じ、決済処理の手続き
が煩雑となる。特開平11-265413号公報には、口座を持
たない相手に送金するという課題を解決するための金融
処理装置が記載されているにすぎず、この金融処理装置
を利用した決済方法までは記載されていない。
【0009】本発明の目的は、支払人の決済手続きの負
担を軽減することができる電子決済方法及び電子決済シ
ステムを提供することにある。
担を軽減することができる電子決済方法及び電子決済シ
ステムを提供することにある。
【0010】本発明の目的は、受取人の被決済手続きの
負担を軽減することができる電子決済方法及び電子決済
システムを提供することにある。
負担を軽減することができる電子決済方法及び電子決済
システムを提供することにある。
【0011】
【課題を解決するための手段】本発明は、支払人が支払
意図を決済仲介人へ通知し、決済仲介人が支払意図の通
知を受けた場合に受取人へ支払意図を通知し、受取人が
支払意図の通知を受けた場合に決済仲介人へ振込口座を
通知し、決済仲介人が支払人により指定された支払期限
又は支払期間内に振込口座の通知を受けた場合に振込口
座に支払人により指定された額の金銭を振り込む。尚、
支払人は、受取人へ支払意図を直接的に通知してもよ
い。
意図を決済仲介人へ通知し、決済仲介人が支払意図の通
知を受けた場合に受取人へ支払意図を通知し、受取人が
支払意図の通知を受けた場合に決済仲介人へ振込口座を
通知し、決済仲介人が支払人により指定された支払期限
又は支払期間内に振込口座の通知を受けた場合に振込口
座に支払人により指定された額の金銭を振り込む。尚、
支払人は、受取人へ支払意図を直接的に通知してもよ
い。
【0012】本発明は、支払人が支払意図を決済仲介人
へ通知し、決済仲介人が支払意図の通知を受けた場合に
受取人へ支払意図を通知し、受取人が支払意図の通知を
受けた場合に決済仲介人へ振込口座を通知し、決済仲介
人が決済毎に振込口座の通知を受けた場合に振込口座に
支払人により指定された額の金銭を振り込む。
へ通知し、決済仲介人が支払意図の通知を受けた場合に
受取人へ支払意図を通知し、受取人が支払意図の通知を
受けた場合に決済仲介人へ振込口座を通知し、決済仲介
人が決済毎に振込口座の通知を受けた場合に振込口座に
支払人により指定された額の金銭を振り込む。
【0013】本発明は、金銭の受取人から予め振込口座
の指定を受け、振込口座に関するデータをデータベース
に保存し、振込口座の指定を受けた場合に振込口座に金
銭を振り込む支払人又は決済仲介人から金銭の支払意図
の通知を受けた場合に支払意図から特定される受取人の
振込口座をデータベースから検索し、検索された振込口
座を支払人又は決済仲介人へ通知する。
の指定を受け、振込口座に関するデータをデータベース
に保存し、振込口座の指定を受けた場合に振込口座に金
銭を振り込む支払人又は決済仲介人から金銭の支払意図
の通知を受けた場合に支払意図から特定される受取人の
振込口座をデータベースから検索し、検索された振込口
座を支払人又は決済仲介人へ通知する。
【0014】
【発明の実施の形態】以下、本発明の第1の実施形態に
ついて、図1〜図13を用いて説明する。
ついて、図1〜図13を用いて説明する。
【0015】図1に、本発明の第1の実施形態における
システム全体のシステム構成図を示す。第1の実施形態
は、社会保険庁が受益人に対して保険金や年金を支払う
決済方法を例にしたものである。
システム全体のシステム構成図を示す。第1の実施形態
は、社会保険庁が受益人に対して保険金や年金を支払う
決済方法を例にしたものである。
【0016】社会保険庁が使用する保険庁システム11
00と、決済仲介人が使用する決済仲介システム120
0と、受益人が使用する受益人システム1300と、金
融機関が使用する金融システム1400とが、ネットワ
ーク1500により接続される。社会保険庁とは、金銭
を支払う支払人であり、金銭の支払義務を負う債務者で
ある。決済仲介人とは、社会保険庁から委託を受けて、
受益人へ金銭の支払意図があることを通知し、受益人か
らの受取意図(例えば、振込口座の指定の連絡)に応じ
て受益人に金銭を支払う者である。受益人とは、金銭を
受け取る受取人であり、金銭を受け取る権利を有する債
権者である。金融機関とは、金融取引を仲介する機関を
いい、例えば、日本銀行、普通銀行、長期信用銀行、信
託銀行、信用金庫、信用組合、農業協同組合、漁業協同
組合、保険会社、証券会社、ノンバンク、郵便局などを
いう。ネットワーク1500は、放送電波や電気通信回
線であり、例えばインターネットである。保険庁システ
ム1100は、例えばパーソナルコンピュータである。
00と、決済仲介人が使用する決済仲介システム120
0と、受益人が使用する受益人システム1300と、金
融機関が使用する金融システム1400とが、ネットワ
ーク1500により接続される。社会保険庁とは、金銭
を支払う支払人であり、金銭の支払義務を負う債務者で
ある。決済仲介人とは、社会保険庁から委託を受けて、
受益人へ金銭の支払意図があることを通知し、受益人か
らの受取意図(例えば、振込口座の指定の連絡)に応じ
て受益人に金銭を支払う者である。受益人とは、金銭を
受け取る受取人であり、金銭を受け取る権利を有する債
権者である。金融機関とは、金融取引を仲介する機関を
いい、例えば、日本銀行、普通銀行、長期信用銀行、信
託銀行、信用金庫、信用組合、農業協同組合、漁業協同
組合、保険会社、証券会社、ノンバンク、郵便局などを
いう。ネットワーク1500は、放送電波や電気通信回
線であり、例えばインターネットである。保険庁システ
ム1100は、例えばパーソナルコンピュータである。
【0017】図2に、本発明の第1の実施形態における
各システムのシステム構成図を示す。保険庁システム
は、記憶装置2010、通信装置2020、処理装置2
030、入力装置2040、出力装置2050、ICカ
ードR/W(リーダ/ライタ)2060をバス2070
で接続して構成する。記憶装置2010は、データや処
理プログラムを記憶する装置であり、例えばメモリであ
る。通信装置2020は、ネットワーク1500と接続
し、保険庁システム1200が、他の決済仲介システム
1200、受益人システム1300、金融システム14
00とデータの送受信するのに用いる装置であり、例え
ばネットワークカードである。処理装置2030は、記
憶装置2010に記憶されたプログラムを実行する装置
であり、例えばCPUである。入力装置2040は、装
置の使用者等による外部からの入力をうける装置であ
り、例えばキーボードやマウスである。出力装置205
0は、装置の使用者等の外部に対して情報を出力する装
置であり、例えばディスプレィである。ICカードR/
W2060は、ICカードとデータの送受信を行う装置
である。ICカードとは、ICカードを使用する者の身
分を証明するためのデータを記憶する記録媒体である。
各システムのシステム構成図を示す。保険庁システム
は、記憶装置2010、通信装置2020、処理装置2
030、入力装置2040、出力装置2050、ICカ
ードR/W(リーダ/ライタ)2060をバス2070
で接続して構成する。記憶装置2010は、データや処
理プログラムを記憶する装置であり、例えばメモリであ
る。通信装置2020は、ネットワーク1500と接続
し、保険庁システム1200が、他の決済仲介システム
1200、受益人システム1300、金融システム14
00とデータの送受信するのに用いる装置であり、例え
ばネットワークカードである。処理装置2030は、記
憶装置2010に記憶されたプログラムを実行する装置
であり、例えばCPUである。入力装置2040は、装
置の使用者等による外部からの入力をうける装置であ
り、例えばキーボードやマウスである。出力装置205
0は、装置の使用者等の外部に対して情報を出力する装
置であり、例えばディスプレィである。ICカードR/
W2060は、ICカードとデータの送受信を行う装置
である。ICカードとは、ICカードを使用する者の身
分を証明するためのデータを記憶する記録媒体である。
【0018】保険庁システム1100の記憶装置201
0は、支払意図作成処理1180と保険庁秘密鍵151
0とを記録する。決済仲介システム1200、受益人シ
ステム1300、金融システム1400のシステム構成
も、図2に示す保険庁システム1100と同様に、記憶
装置2010、通信装置2020、処理装置2030、
入力装置2040、出力装置2050、ICカードR/
W(リーダ/ライタ)2060をバス2070で接続し
て構成され、さらに通信装置2020がネットワーク1
500に接続して構成される。尚、ネットワーク150
0への接続形態は、通信装置2020とネットワーク1
500とが直接接続される接続形態でもよいし、通信装
置2020とネットワーク1500とが接続を仲介する
接続仲介システムを経由して接続されてもよい。保険庁
システム1100は、支払意図を記憶する支払意図DB
1110に接続される。接続仲介システムは、例えばイ
ンターネット接続プロバイダのシステムである。決済仲
介システム1200の記憶装置2010は、支払意図登
録通知処理1280、振込口座登録処理1282、定期
処理1284とを記憶する。決済仲介システム1200
のバス2070は、データベースである参加者DB12
10および支払意図DB1220に接続される。
0は、支払意図作成処理1180と保険庁秘密鍵151
0とを記録する。決済仲介システム1200、受益人シ
ステム1300、金融システム1400のシステム構成
も、図2に示す保険庁システム1100と同様に、記憶
装置2010、通信装置2020、処理装置2030、
入力装置2040、出力装置2050、ICカードR/
W(リーダ/ライタ)2060をバス2070で接続し
て構成され、さらに通信装置2020がネットワーク1
500に接続して構成される。尚、ネットワーク150
0への接続形態は、通信装置2020とネットワーク1
500とが直接接続される接続形態でもよいし、通信装
置2020とネットワーク1500とが接続を仲介する
接続仲介システムを経由して接続されてもよい。保険庁
システム1100は、支払意図を記憶する支払意図DB
1110に接続される。接続仲介システムは、例えばイ
ンターネット接続プロバイダのシステムである。決済仲
介システム1200の記憶装置2010は、支払意図登
録通知処理1280、振込口座登録処理1282、定期
処理1284とを記憶する。決済仲介システム1200
のバス2070は、データベースである参加者DB12
10および支払意図DB1220に接続される。
【0019】決済仲介システム1200の記憶装置20
10に記憶してある各々の処理は、参加者DB1210
又は支払意図DB1220DBに記憶されるデータへア
クセス可能である。受益人システム1300の記憶装置
2010は、振込口座指定処理1380と受益人秘密鍵
1610とを記憶する。金融システム1400の記憶装
置2010はは、振込処理1480を記憶する。保険庁
システム1100の記憶装置2010は、振込処理14
80を記憶する。
10に記憶してある各々の処理は、参加者DB1210
又は支払意図DB1220DBに記憶されるデータへア
クセス可能である。受益人システム1300の記憶装置
2010は、振込口座指定処理1380と受益人秘密鍵
1610とを記憶する。金融システム1400の記憶装
置2010はは、振込処理1480を記憶する。保険庁
システム1100の記憶装置2010は、振込処理14
80を記憶する。
【0020】以下、各処理の概要について述べる。保険
庁システム1100の支払意図作成処理1180は、予
め定められたスケジュールに従って(決済毎に)、又は
社会保険庁の職員から決済処理開始の指令を受けた場合
に、図3に示す支払意図3100を作成し、支払意図D
B1110に支払意図3100を記憶させると共に、決
済仲介システム1200の支払意図登録通知処理128
0に支払意図3100を登録するように要求する。この
登録要求のメッセージフローが、支払意図の登録181
0である。支払意図3100は、支払意図3100の登
録者あるいは登録代行を依頼した者が、支払意図311
0内に記録してある受取人に対して、支払意図3110
内に記録してある支払金額を、支払意図3110内に記
録してある支払日に支払う意図がある旨を示すデータで
ある。支払意図登録処理1280と支払意図作成処理1
180は、例えばWEBのサーバアプリケーション・ク
ライアントアプリケーションとして実現しても良い。例
えば、支払意図登録処理1280をWEBサーバからC
GI(Common Gateway Interface)等を経由してクライ
アント側のアプリケーション(支払意図登録処理128
0)とデータのやりとりを行うサーバアプリケーション
とし、かつ、支払意図作成処理1180がブラウザ上で
動作するスクリプト言語により記述したプログラムとし
て実行しても良い。支払意図登録通知処理1200は、
支払意図3100の登録要求を受けると、支払意図31
00を支払意図DB1220に登録する。また支払意図
登録通知処理1200は、受益人システム1300に対
して、支払意図3100を登録した旨を通知する。この
メッセージフローが支払意図の到着通知1820であ
る。保険庁システム1100は、インターネット150
0を介して、直接的に、受益人システム1300へ支払
意図を通知してもよい。保険庁システム1100は、イ
ンターネット1500からアクセス可能でかつ社会保険
庁が使用するWEBサイトに、支払意図を登録し、これ
により公示してもよい。社会保険庁は、受益人に対し、
支払意図を郵送してもよい。社会保険庁は、情報メディ
ア(新聞等)に、支払意図を登録し、これにより公示し
てもよい。支払意図の通知は、支払意図の公示を含む概
念である。また、支払意図の登録1810や支払意図の
到着通知1820は、ネットワーク1500の代わりに
放送電波を利用して、送信されてもよい。
庁システム1100の支払意図作成処理1180は、予
め定められたスケジュールに従って(決済毎に)、又は
社会保険庁の職員から決済処理開始の指令を受けた場合
に、図3に示す支払意図3100を作成し、支払意図D
B1110に支払意図3100を記憶させると共に、決
済仲介システム1200の支払意図登録通知処理128
0に支払意図3100を登録するように要求する。この
登録要求のメッセージフローが、支払意図の登録181
0である。支払意図3100は、支払意図3100の登
録者あるいは登録代行を依頼した者が、支払意図311
0内に記録してある受取人に対して、支払意図3110
内に記録してある支払金額を、支払意図3110内に記
録してある支払日に支払う意図がある旨を示すデータで
ある。支払意図登録処理1280と支払意図作成処理1
180は、例えばWEBのサーバアプリケーション・ク
ライアントアプリケーションとして実現しても良い。例
えば、支払意図登録処理1280をWEBサーバからC
GI(Common Gateway Interface)等を経由してクライ
アント側のアプリケーション(支払意図登録処理128
0)とデータのやりとりを行うサーバアプリケーション
とし、かつ、支払意図作成処理1180がブラウザ上で
動作するスクリプト言語により記述したプログラムとし
て実行しても良い。支払意図登録通知処理1200は、
支払意図3100の登録要求を受けると、支払意図31
00を支払意図DB1220に登録する。また支払意図
登録通知処理1200は、受益人システム1300に対
して、支払意図3100を登録した旨を通知する。この
メッセージフローが支払意図の到着通知1820であ
る。保険庁システム1100は、インターネット150
0を介して、直接的に、受益人システム1300へ支払
意図を通知してもよい。保険庁システム1100は、イ
ンターネット1500からアクセス可能でかつ社会保険
庁が使用するWEBサイトに、支払意図を登録し、これ
により公示してもよい。社会保険庁は、受益人に対し、
支払意図を郵送してもよい。社会保険庁は、情報メディ
ア(新聞等)に、支払意図を登録し、これにより公示し
てもよい。支払意図の通知は、支払意図の公示を含む概
念である。また、支払意図の登録1810や支払意図の
到着通知1820は、ネットワーク1500の代わりに
放送電波を利用して、送信されてもよい。
【0021】受益人システム1300の振込口座指定処
理1380は、図4に示す振込口座指定データ4100
を作成し、決済仲介システム1200の振込口座登録処
理1282に振込口座指定データ4100を登録するよ
う要求する。このメッセージフローが振込口座の指定1
830である。振込口座指定データ4100は、振込口
座指定データ4100で示す振込口座へ、支払を行うよ
うに指示するデータである。振込口座登録処理1282
と振込口座指定処理1380は、支払意図登録処理12
80と支払意図作成処理1180の実現形態の場合と同
様に、WEBのサーバアプリケーション・クライアント
アプリケーションとして実現しても良い。振込口座登録
処理1282は、振込口座指定データ4100の登録要
求を受けると、振込口座指定データ4100を支払意図
DB1220に登録する。
理1380は、図4に示す振込口座指定データ4100
を作成し、決済仲介システム1200の振込口座登録処
理1282に振込口座指定データ4100を登録するよ
う要求する。このメッセージフローが振込口座の指定1
830である。振込口座指定データ4100は、振込口
座指定データ4100で示す振込口座へ、支払を行うよ
うに指示するデータである。振込口座登録処理1282
と振込口座指定処理1380は、支払意図登録処理12
80と支払意図作成処理1180の実現形態の場合と同
様に、WEBのサーバアプリケーション・クライアント
アプリケーションとして実現しても良い。振込口座登録
処理1282は、振込口座指定データ4100の登録要
求を受けると、振込口座指定データ4100を支払意図
DB1220に登録する。
【0022】決済仲介システム1200の定期処理12
84は、振込口座指定データ4100が登録され支払日
を向かえた支払意図3100を支払意図DB1220か
ら抽出し、金融システム1400の振込処理1400に
対して、支払意図3100で指定された支払口座から振
込口座指定データ4100で指定された受取口座への振
込をするように要求する。このメッセージフローが振込
要求1840である。振込処理1400とは、振込口座
(預金口座)などに金銭を払い込む処理をいい、振替処
理を含む。また、金銭の振り込みとは、金融機関が行う
行為の他、決済仲介人が金融機関に振込要求をして振り
込みを行う行為、社会保険庁が金融機関に振込要求をし
て振り込みを行う行為、受益人が金融機関に振込要求を
して振り込みを行う行為を含む。
84は、振込口座指定データ4100が登録され支払日
を向かえた支払意図3100を支払意図DB1220か
ら抽出し、金融システム1400の振込処理1400に
対して、支払意図3100で指定された支払口座から振
込口座指定データ4100で指定された受取口座への振
込をするように要求する。このメッセージフローが振込
要求1840である。振込処理1400とは、振込口座
(預金口座)などに金銭を払い込む処理をいい、振替処
理を含む。また、金銭の振り込みとは、金融機関が行う
行為の他、決済仲介人が金融機関に振込要求をして振り
込みを行う行為、社会保険庁が金融機関に振込要求をし
て振り込みを行う行為、受益人が金融機関に振込要求を
して振り込みを行う行為を含む。
【0023】以下、各処理の処理内容の詳細について述
べる。
べる。
【0024】支払意図作成処理1180について述べ
る。支払意図作成処理1180において、保険証システ
ム1100は、図7に示すログイン画面7100を、保
険庁システム1100の出力装置2050を用いて出力
する。保険庁システム1100の入力装置2040は、
参加者ID入力欄7110およびパスワード入力欄71
20への入力を受けることが可能である。次に、支払意
図作成処理1180において、保険証システム1100
は、ログインボタン7130のクリックの入力を保険証
システム1100の入力装置2040から受けると、図
13に示すログインデータ13100を作成する。ログ
インデータ13100は、参加者ID入力欄7110お
よびパスワード入力欄7120に入力を受けた値をそれ
ぞれログインデータ13100の参加者ID5100、
パスワード5200にコピーすることにより作成する。
そして、支払意図作成処理1180において、保険証シ
ステム1100は、ログインデータ13100を決済仲
介システム1200(支払意図登録通知処理1280)
に送信し認証を要求する。決済仲介システム1200
は、送信されたログインデータ13100を、図10に
示す支払意図登録通知処理1280の処理ステップ10
010により受信する。決済仲介システム1200は、
認証要求に対する返信を、処理ステップ10030ある
いは処理ステップ10100により実行する。認証方法
は、ログインIDとパスワードを用いる方法の他に、チ
ャレンジデータによる認証方法等の他の認証方法を用い
ても良い。チャレンジデータによる認証方法は、決済仲
介システム1200でチャレンジデータ乱数を発生し、
保険庁システム1100に送信する。保険庁システム1
100は、保険庁秘密鍵1510を用いてチャレンジデ
ータに対して署名を付与し、決済仲介システム1200
(決済仲介システム1200)に返信する。決済仲介シ
ステム1200は、保険庁秘密鍵1510に対応する公
開鍵を用いて署名検証を行い、正しければ認証が成功し
たとみなし、正しくなければ認証が失敗したとみなす。
支払意図作成処理1180で認証が失敗した場合は、支
払意図作成処理1180が終了する。支払意図作成処理
1180で認証が成功した場合は、保険証システム11
00は、図8に示す支払意図入力画面8100を、保険
庁システム1100の出力装置2050を用いて表示す
る。保険庁システム1100の入力装置2040は、支
払人ID入力欄8105、支払額入力欄8110、支払
日入力欄8120、支払期限入力欄8130、支払口座
入力欄8140、受取人ID入力欄8150に対する値
の入力を受けることができる。支払意図作成処理118
0において、保険証システム1100は、登録ボタン7
130のクリックの入力を入力装置2040から受ける
と、図3に示す支払意図3100を作成する。支払意図
3100は、支払意図入力画面8100の支払人ID入
力欄8105、支払額入力欄8110、支払日入力欄8
120、支払期限入力欄8130、支払口座入力欄81
40、受取人ID入力欄8150の内容を、それぞれ支
払人ID3110、支払額3120、支払日3130、
支払期限3140、支払口座3150、受取人ID31
60にコピーすることにより作成する。支払日3130
は、支払を開始する日であり、支払期限3140は、支
払を停止する日である。支払期限3140は、支払期間
であってもよい。支払額は、一定であってもよいし、支
払時毎に異なる額であってもよい。支払口座3150
は、金融機関の名称と振込口座とを含む。さらに、支払
意図作成処理1180において、保険庁システム110
0は、保険庁秘密鍵1510を用いて、支払人ID31
10、支払額3120、支払日3130、支払期限31
40、支払口座3150、受取人ID3160に対する
署名値を計算し、支払人署名3170に格納する。署名
方法は、XML(Extensible Mark-up Language)文章
等に対する電子署名の付与と同様に行う。具体的には、
まず支払人ID3110、支払額3120、支払日31
30、支払期限3140、支払口座3150、受取人I
D3160の内容が、一連のビット列にシリアライズさ
れる。次にシリアライズされたビット列のハッシュ値を
計算する。ハッシュ値は、ビット列を固定長の疑似乱数
を生成する不可逆な一方向関数(ハッシュ関数)で処理
することにより算出する。最後に、ハッシュ値が、保険
庁秘密鍵1510を用いて暗号化される。保険庁秘密鍵
1510は、公開鍵暗号における秘密鍵である。秘密鍵
で暗号化したデータは、対応する公開鍵で復号化でき
る。以後、本明細書において署名を付与する場合は、上
記署名方法と同じ方法で付与するものとする。次に保険
庁システム1100は、作成された支払意図3100を
支払意図DB1110に記憶させる。そして、保険庁シ
ステム1100は、予め定められたスケジュールに従っ
て(決済毎に)、又は入力装置2040から決済処理開
始の指令を受けた場合に、支払意図DB1110から支
払意図3100を呼び出し、出力装置2050へ出力す
る。保険庁システム1100は、支払人ID入力欄81
05、支払額入力欄8110、支払日入力欄8120、
支払期限入力欄8130、支払口座入力欄8140、受
取人ID入力欄8150のうち固定されたもの以外を空
白として、出力装置2050へ出力するのが好ましい。
また支払意図作成処理1180において、保険証システ
ム1100は、作成した支払意図3100を支払意図登
録通知処理1280に送信し、支払意図の登録が成功し
たかどうかの返信を受信する。決済仲介システム120
0は、送信された支払意図3100を、図10に示す支
払意図登録通知処理1280の処理ステップ10040
により受信する。決済仲介システム1200は、支払意
図の登録が成功したかどうかの返信を、処理ステップ1
0090あるいは処理ステップ10110により実行す
る。第1の実施形態では、保険庁が直接決済仲介システ
ム1200に対して支払意図3100の登録を行ってい
る例を示しているが、保険庁の代理人が、保険庁の代理
として、決済仲介システム1200に保険庁の支払意図
3100の登録を行ってもよい。この場合のシステム構
成は第1の実施形態と同様で、決済仲介システム120
0が代理人のシステムであると見なせば良い。
る。支払意図作成処理1180において、保険証システ
ム1100は、図7に示すログイン画面7100を、保
険庁システム1100の出力装置2050を用いて出力
する。保険庁システム1100の入力装置2040は、
参加者ID入力欄7110およびパスワード入力欄71
20への入力を受けることが可能である。次に、支払意
図作成処理1180において、保険証システム1100
は、ログインボタン7130のクリックの入力を保険証
システム1100の入力装置2040から受けると、図
13に示すログインデータ13100を作成する。ログ
インデータ13100は、参加者ID入力欄7110お
よびパスワード入力欄7120に入力を受けた値をそれ
ぞれログインデータ13100の参加者ID5100、
パスワード5200にコピーすることにより作成する。
そして、支払意図作成処理1180において、保険証シ
ステム1100は、ログインデータ13100を決済仲
介システム1200(支払意図登録通知処理1280)
に送信し認証を要求する。決済仲介システム1200
は、送信されたログインデータ13100を、図10に
示す支払意図登録通知処理1280の処理ステップ10
010により受信する。決済仲介システム1200は、
認証要求に対する返信を、処理ステップ10030ある
いは処理ステップ10100により実行する。認証方法
は、ログインIDとパスワードを用いる方法の他に、チ
ャレンジデータによる認証方法等の他の認証方法を用い
ても良い。チャレンジデータによる認証方法は、決済仲
介システム1200でチャレンジデータ乱数を発生し、
保険庁システム1100に送信する。保険庁システム1
100は、保険庁秘密鍵1510を用いてチャレンジデ
ータに対して署名を付与し、決済仲介システム1200
(決済仲介システム1200)に返信する。決済仲介シ
ステム1200は、保険庁秘密鍵1510に対応する公
開鍵を用いて署名検証を行い、正しければ認証が成功し
たとみなし、正しくなければ認証が失敗したとみなす。
支払意図作成処理1180で認証が失敗した場合は、支
払意図作成処理1180が終了する。支払意図作成処理
1180で認証が成功した場合は、保険証システム11
00は、図8に示す支払意図入力画面8100を、保険
庁システム1100の出力装置2050を用いて表示す
る。保険庁システム1100の入力装置2040は、支
払人ID入力欄8105、支払額入力欄8110、支払
日入力欄8120、支払期限入力欄8130、支払口座
入力欄8140、受取人ID入力欄8150に対する値
の入力を受けることができる。支払意図作成処理118
0において、保険証システム1100は、登録ボタン7
130のクリックの入力を入力装置2040から受ける
と、図3に示す支払意図3100を作成する。支払意図
3100は、支払意図入力画面8100の支払人ID入
力欄8105、支払額入力欄8110、支払日入力欄8
120、支払期限入力欄8130、支払口座入力欄81
40、受取人ID入力欄8150の内容を、それぞれ支
払人ID3110、支払額3120、支払日3130、
支払期限3140、支払口座3150、受取人ID31
60にコピーすることにより作成する。支払日3130
は、支払を開始する日であり、支払期限3140は、支
払を停止する日である。支払期限3140は、支払期間
であってもよい。支払額は、一定であってもよいし、支
払時毎に異なる額であってもよい。支払口座3150
は、金融機関の名称と振込口座とを含む。さらに、支払
意図作成処理1180において、保険庁システム110
0は、保険庁秘密鍵1510を用いて、支払人ID31
10、支払額3120、支払日3130、支払期限31
40、支払口座3150、受取人ID3160に対する
署名値を計算し、支払人署名3170に格納する。署名
方法は、XML(Extensible Mark-up Language)文章
等に対する電子署名の付与と同様に行う。具体的には、
まず支払人ID3110、支払額3120、支払日31
30、支払期限3140、支払口座3150、受取人I
D3160の内容が、一連のビット列にシリアライズさ
れる。次にシリアライズされたビット列のハッシュ値を
計算する。ハッシュ値は、ビット列を固定長の疑似乱数
を生成する不可逆な一方向関数(ハッシュ関数)で処理
することにより算出する。最後に、ハッシュ値が、保険
庁秘密鍵1510を用いて暗号化される。保険庁秘密鍵
1510は、公開鍵暗号における秘密鍵である。秘密鍵
で暗号化したデータは、対応する公開鍵で復号化でき
る。以後、本明細書において署名を付与する場合は、上
記署名方法と同じ方法で付与するものとする。次に保険
庁システム1100は、作成された支払意図3100を
支払意図DB1110に記憶させる。そして、保険庁シ
ステム1100は、予め定められたスケジュールに従っ
て(決済毎に)、又は入力装置2040から決済処理開
始の指令を受けた場合に、支払意図DB1110から支
払意図3100を呼び出し、出力装置2050へ出力す
る。保険庁システム1100は、支払人ID入力欄81
05、支払額入力欄8110、支払日入力欄8120、
支払期限入力欄8130、支払口座入力欄8140、受
取人ID入力欄8150のうち固定されたもの以外を空
白として、出力装置2050へ出力するのが好ましい。
また支払意図作成処理1180において、保険証システ
ム1100は、作成した支払意図3100を支払意図登
録通知処理1280に送信し、支払意図の登録が成功し
たかどうかの返信を受信する。決済仲介システム120
0は、送信された支払意図3100を、図10に示す支
払意図登録通知処理1280の処理ステップ10040
により受信する。決済仲介システム1200は、支払意
図の登録が成功したかどうかの返信を、処理ステップ1
0090あるいは処理ステップ10110により実行す
る。第1の実施形態では、保険庁が直接決済仲介システ
ム1200に対して支払意図3100の登録を行ってい
る例を示しているが、保険庁の代理人が、保険庁の代理
として、決済仲介システム1200に保険庁の支払意図
3100の登録を行ってもよい。この場合のシステム構
成は第1の実施形態と同様で、決済仲介システム120
0が代理人のシステムであると見なせば良い。
【0025】次に、支払意図登録通知処理1280につ
いて述べる。図10に、本発明の第1の実施形態におけ
る支払意図登録通知処理のフロー図を示す。処理ステッ
プ10010において、決済仲介システム1200は、
支払意図作成処理1180からログインデータ1310
0を受信する。処理ステップ10015において、決済
仲介システム1200は、ログインデータ13100の
参加者ID5100と一致する参加者ID5100を有
する参加者情報5000を、参加者DB1210から検
索する。参加者DB1210は、図5に示すように、参
加者情報5000が登録してあるテーブルである。参加
者情報5000は、参加者ID5100、取扱対象者I
D5150、パスワード5200、公開鍵5300、連
絡先5400とを有する。連絡先5400は、複数個存
在してもよい。参加者情報5000の参加者ID510
0は、その参加者情報5000がどの参加者に関する情
報であるかを特定するために用いるデータである。参加
者とは、決済仲介システム1200に直接または間接的
にアクセスし、データの送受信を行う者である。図5に
示す例においては、参加者として、社会保険庁、受益
人、受益人の代理人とが登録される。取扱対象者ID5
150は、その参加者情報5000で示される参加者
が、どの参加者の支払意図3100あるいは、振込口座
指定データ4100の登録を行えるかを示すデータであ
る。自分自身の支払意図3100あるいは振込口座指定
データ4100の登録を行う場合は、参加者ID510
0と取扱対象者ID5150は同じ値になる。また他の
参加者の支払意図3100あるいは振込口座指定データ
4100の登録を代行する参加者は、自分の参加者ID
を参加者ID5100に、代行したい参加者のIDを取
扱対象者ID5150に登録しておく。参加者情報50
00のパスワード5200は、参加者の認証に用いるデ
ータである。公開鍵5300は、参加者の公開鍵であ
り、各参加者の持つ秘密鍵に対応する公開鍵が記録して
ある。連絡先5400は、決済仲介システム1200か
ら参加者に情報を送る際の連絡先であり、例えばメール
アドレス、住所、電話番号である。以後本処理の説明に
おいて、単に参加者情報5000と記載した場合は、本
処理ステップにて検索した参加者情報を指すものとす
る。処理ステップ10020において、決済仲介システ
ム1200は、参加者情報5000のパスワード520
0とログインデータ13100のパスワード5200が
一致するかを判断し、一致すると判断した場合は処理フ
ローを処理ステップ10030へ移し、一致しないと判
断した場合は処理フローを処理ステップ10100に移
す。処理ステップ10030のおいて、決済仲介システ
ム1200は、認証が成功した旨を支払意図作成処理1
180に返信する。例えば「認証成功」の文字列を返信
する。処理ステップ10040において、決済仲介シス
テム1200は、支払意図作成処理1180から支払意
図3100を受信する。処理ステップ10050におい
て、決済仲介システム1200は、支払意図3100の
支払人署名3170が正しいかを検証し、正しいと判断
した場合は処理フローを処理ステップ10055に移
し、正しくないと判断した場合は処理フローを処理ステ
ップ10110に移す。支払人署名3170の検証は、
XML文章に対する電子署名の検証等と同様に行う。具
体的には、まず署名対象である、支払人ID3110、
支払額3120、支払日3130、支払期限3140、
支払口座3150、受取人ID3160の内容が一連の
ビット列にシリアライズされる。次にビット列のハッシ
ュ値が計算される。一方支払人署名3170が参加者情
報5000の公開鍵を用いて復号化され、復号化された
値とハッシュ値とを比較して、それらの値が一致すれば
署名が正しいと判断され、一致しない場合は署名が不正
であると判断されるものとする。以下本明細書において
署名を検証する場合は上記方法と同じ方法で検証するも
のとする。支払人署名3170を検証することで支払人
が本当に支払意図3100を作成したのかを推定するこ
とができる。処理ステップ10055において、決済仲
介システム1200は、支払意図3100の支払人ID
3160と参加者情報5000の取扱対象者ID515
0とが一致するかを判断し、一致すると判断した場合は
処理フローを処理ステップ10060に移し、一致しな
いと判断した場合は処理フローを処理ステップ1011
0に移す。処理ステップ10060において、決済仲介
システム1200は、支払意図3100の受取人ID3
160と同一の値を取扱対象者ID5150を有する参
加者情報5000が参加者DB1210に存在するかを
検証し、登録してあることを検証した場合は処理フロー
を処理ステップ10070に移し、登録してないことを
検証した場合は処理フローを処理ステップ10110に
移す。支払意図登録通知処理1280の説明において、
参加者情報5000を受取人の参加者情報5000と記
す。処理ステップ10070のおいて、決済仲介システ
ム1200は、図6に示す支払意図情報6000を作成
する。支払意図情報6000は、支払意図3100、振
込口座指定データ4100、状態6100を有するデー
タである。状態6100は、例えば、支払意図3100
の状態を示すデータであり、振込口座の指定を受けてい
ないことを示す「振込口座未指定」、振込口座の指定は
完了しているが支払日に達しておらず支払が行われてい
ないことを示す「未支払」、支払が完了していることを
示す「支払済」、支払期限を過ぎてしまったことを示す
「失効済」をいう。さらに処理ステップ10070にお
いて、決済仲介システム1200は、作成した支払意図
情報6000に処理ステップ10040で受信した支払
意図3100を登録し、状態6100を「振込口座未指
定」とする。次に、処理ステップ10070において、
決済仲介システム1200は、作成された支払意図情報
6000を支払意図DB1220に登録する。支払意図
DB1220は、図6に示すように、支払意図情報60
00を登録したテーブルである。処理ステップ1008
0において、決済仲介システム1200は、受取人の参
加者情報5000の連絡先5400に対して、支払意図
3100が到着した旨を通知する。連絡先5400が複
数ある場合は全ての連絡先5400に対して支払意図3
100が到着した旨を通知するのが好ましい。支払意図
3100が到着した旨の通知は、例えば「支払意図が到
着しました」という文字列を送信する。処理ステップ1
0090において、決済仲介システム1200は、支払
意図3100の登録が成功した旨を、支払意図作成処理
1180に返信し、支払意図登録通知処理1280を終
了する。支払意図3100の登録が成功した旨の返信
は、例えば「支払意図の登録成功」の文字列を返信す
る。処理ステップ10100において、決済仲介システ
ム1200は、認証が失敗した旨を支払意図作成処理1
180に返信し、支払意図登録通知処理1280を終了
する。認証が失敗した旨の返信は、例えば「認証失敗」
の文字列を返信する。処理ステップ10110におい
て、決済仲介システム1200は、支払意図3100の
登録が失敗した旨を、支払意図作成処理1180に返信
し、支払意図登録通知処理1280を終了する。支払意
図3100の登録が失敗したの返信は、例えば「支払意
図の登録失敗」の文字列を返信する。
いて述べる。図10に、本発明の第1の実施形態におけ
る支払意図登録通知処理のフロー図を示す。処理ステッ
プ10010において、決済仲介システム1200は、
支払意図作成処理1180からログインデータ1310
0を受信する。処理ステップ10015において、決済
仲介システム1200は、ログインデータ13100の
参加者ID5100と一致する参加者ID5100を有
する参加者情報5000を、参加者DB1210から検
索する。参加者DB1210は、図5に示すように、参
加者情報5000が登録してあるテーブルである。参加
者情報5000は、参加者ID5100、取扱対象者I
D5150、パスワード5200、公開鍵5300、連
絡先5400とを有する。連絡先5400は、複数個存
在してもよい。参加者情報5000の参加者ID510
0は、その参加者情報5000がどの参加者に関する情
報であるかを特定するために用いるデータである。参加
者とは、決済仲介システム1200に直接または間接的
にアクセスし、データの送受信を行う者である。図5に
示す例においては、参加者として、社会保険庁、受益
人、受益人の代理人とが登録される。取扱対象者ID5
150は、その参加者情報5000で示される参加者
が、どの参加者の支払意図3100あるいは、振込口座
指定データ4100の登録を行えるかを示すデータであ
る。自分自身の支払意図3100あるいは振込口座指定
データ4100の登録を行う場合は、参加者ID510
0と取扱対象者ID5150は同じ値になる。また他の
参加者の支払意図3100あるいは振込口座指定データ
4100の登録を代行する参加者は、自分の参加者ID
を参加者ID5100に、代行したい参加者のIDを取
扱対象者ID5150に登録しておく。参加者情報50
00のパスワード5200は、参加者の認証に用いるデ
ータである。公開鍵5300は、参加者の公開鍵であ
り、各参加者の持つ秘密鍵に対応する公開鍵が記録して
ある。連絡先5400は、決済仲介システム1200か
ら参加者に情報を送る際の連絡先であり、例えばメール
アドレス、住所、電話番号である。以後本処理の説明に
おいて、単に参加者情報5000と記載した場合は、本
処理ステップにて検索した参加者情報を指すものとす
る。処理ステップ10020において、決済仲介システ
ム1200は、参加者情報5000のパスワード520
0とログインデータ13100のパスワード5200が
一致するかを判断し、一致すると判断した場合は処理フ
ローを処理ステップ10030へ移し、一致しないと判
断した場合は処理フローを処理ステップ10100に移
す。処理ステップ10030のおいて、決済仲介システ
ム1200は、認証が成功した旨を支払意図作成処理1
180に返信する。例えば「認証成功」の文字列を返信
する。処理ステップ10040において、決済仲介シス
テム1200は、支払意図作成処理1180から支払意
図3100を受信する。処理ステップ10050におい
て、決済仲介システム1200は、支払意図3100の
支払人署名3170が正しいかを検証し、正しいと判断
した場合は処理フローを処理ステップ10055に移
し、正しくないと判断した場合は処理フローを処理ステ
ップ10110に移す。支払人署名3170の検証は、
XML文章に対する電子署名の検証等と同様に行う。具
体的には、まず署名対象である、支払人ID3110、
支払額3120、支払日3130、支払期限3140、
支払口座3150、受取人ID3160の内容が一連の
ビット列にシリアライズされる。次にビット列のハッシ
ュ値が計算される。一方支払人署名3170が参加者情
報5000の公開鍵を用いて復号化され、復号化された
値とハッシュ値とを比較して、それらの値が一致すれば
署名が正しいと判断され、一致しない場合は署名が不正
であると判断されるものとする。以下本明細書において
署名を検証する場合は上記方法と同じ方法で検証するも
のとする。支払人署名3170を検証することで支払人
が本当に支払意図3100を作成したのかを推定するこ
とができる。処理ステップ10055において、決済仲
介システム1200は、支払意図3100の支払人ID
3160と参加者情報5000の取扱対象者ID515
0とが一致するかを判断し、一致すると判断した場合は
処理フローを処理ステップ10060に移し、一致しな
いと判断した場合は処理フローを処理ステップ1011
0に移す。処理ステップ10060において、決済仲介
システム1200は、支払意図3100の受取人ID3
160と同一の値を取扱対象者ID5150を有する参
加者情報5000が参加者DB1210に存在するかを
検証し、登録してあることを検証した場合は処理フロー
を処理ステップ10070に移し、登録してないことを
検証した場合は処理フローを処理ステップ10110に
移す。支払意図登録通知処理1280の説明において、
参加者情報5000を受取人の参加者情報5000と記
す。処理ステップ10070のおいて、決済仲介システ
ム1200は、図6に示す支払意図情報6000を作成
する。支払意図情報6000は、支払意図3100、振
込口座指定データ4100、状態6100を有するデー
タである。状態6100は、例えば、支払意図3100
の状態を示すデータであり、振込口座の指定を受けてい
ないことを示す「振込口座未指定」、振込口座の指定は
完了しているが支払日に達しておらず支払が行われてい
ないことを示す「未支払」、支払が完了していることを
示す「支払済」、支払期限を過ぎてしまったことを示す
「失効済」をいう。さらに処理ステップ10070にお
いて、決済仲介システム1200は、作成した支払意図
情報6000に処理ステップ10040で受信した支払
意図3100を登録し、状態6100を「振込口座未指
定」とする。次に、処理ステップ10070において、
決済仲介システム1200は、作成された支払意図情報
6000を支払意図DB1220に登録する。支払意図
DB1220は、図6に示すように、支払意図情報60
00を登録したテーブルである。処理ステップ1008
0において、決済仲介システム1200は、受取人の参
加者情報5000の連絡先5400に対して、支払意図
3100が到着した旨を通知する。連絡先5400が複
数ある場合は全ての連絡先5400に対して支払意図3
100が到着した旨を通知するのが好ましい。支払意図
3100が到着した旨の通知は、例えば「支払意図が到
着しました」という文字列を送信する。処理ステップ1
0090において、決済仲介システム1200は、支払
意図3100の登録が成功した旨を、支払意図作成処理
1180に返信し、支払意図登録通知処理1280を終
了する。支払意図3100の登録が成功した旨の返信
は、例えば「支払意図の登録成功」の文字列を返信す
る。処理ステップ10100において、決済仲介システ
ム1200は、認証が失敗した旨を支払意図作成処理1
180に返信し、支払意図登録通知処理1280を終了
する。認証が失敗した旨の返信は、例えば「認証失敗」
の文字列を返信する。処理ステップ10110におい
て、決済仲介システム1200は、支払意図3100の
登録が失敗した旨を、支払意図作成処理1180に返信
し、支払意図登録通知処理1280を終了する。支払意
図3100の登録が失敗したの返信は、例えば「支払意
図の登録失敗」の文字列を返信する。
【0026】次に振込口座指定処理1380について述
べる。まず受益人システム1300は、図7に示すログ
イン画面7100を受益人システム1300の出力装置
2050を用いて表示する。受益人システム1300
は、受益人システム1300の入力装置2040を用い
て参加者ID入力欄7110およびパスワード入力欄7
120への入力を受け、ログインデータ13100を作
成する。これらの処理内容は、支払意図作成処理118
0においてログインデータ13100を作成する処理と
同様とする。次に受益人システム1300は、ログイン
データ13100を決済仲介システム1200(振込口
座登録処理1282)に送信し認証を要求する。決済仲
介システム1200は、送信されたログインデータ13
100を、図11に示す振込口座登録処理1282の処
理ステップ11010により受信する。受益人システム
1300は、認証要求に対する返信を、処理ステップ1
1030あるいは処理ステップ11110により実行す
る。次に認証が失敗した場合に、受益人システム130
0は、振込口座指定処理1380を終了する。認証が成
功した場合に、受益人システム1300は、振込口座登
録処理1282から支払意図3100を受信する。決済
仲介システム1200は、支払意図3100の受信に対
する送信を、振込口座登録処理1282の処理ステップ
11050により実行する。次に受益人システム130
0は、図9に示す振込口座指定画面9100を受益人シ
ステム1300の出力装置2050を用いて表示する。
支払意図表示欄9110には、支払意図3100の内容
を表示する。次に受益人システム1300は、受益人シ
ステム1300の入力装置2040を用いて、振込口座
入力欄9120に対する値の入力を受ける。次に受益人
システム1300は、登録ボタン9130のクリックの
入力を受益人システム1300の入力装置2040から
受けると、図4に示す振込口座指定データ4100を作
成する。振込口座指定データ4100は、支払意図31
00のハッシュ値が求められ、支払意図のハッシュ値4
110に格納され、振込口座入力欄9120の内容が振
込口座4120にコピーされ、支払意図のハッシュ値4
110と振込口座4120に対する署名値とが、受益人
秘密鍵1610を用いて計算され、署名値を受取人署名
4130に格納される。支払意図のハッシュ値4110
は、振込口座指定データ4100がどの支払意図310
0に対して、振込口座4120を指定したのかを特定す
るためのデータであり、その作成方法は、前述した署名
付与手順におけるハッシュ値の計算方法と同じである。
即ち、支払意図3100の内容が一連のビット列にシリ
アライズされ、ビット列を固定長の疑似乱数を生成する
不可逆な一方向関数計算(ハッシュ関数)で処理され
る。次に受益人システム1300は、振込口座指定デー
タ4100を決済仲介システム1200(振込口座登録
処理1282)に送信し、振込口座の登録が成功したか
どうかの返信を受信する。前記送信は、図11に示す振
込口座登録処理1282の処理ステップ11060によ
り処理する。また、決済仲介システム1200は、振込
口座の登録が成功したかどうかの返信を、処理ステップ
11100あるいは処理ステップ11120により実行
する。以上により、受益人システム1300は、振込口
座指定処理1380を終了する。
べる。まず受益人システム1300は、図7に示すログ
イン画面7100を受益人システム1300の出力装置
2050を用いて表示する。受益人システム1300
は、受益人システム1300の入力装置2040を用い
て参加者ID入力欄7110およびパスワード入力欄7
120への入力を受け、ログインデータ13100を作
成する。これらの処理内容は、支払意図作成処理118
0においてログインデータ13100を作成する処理と
同様とする。次に受益人システム1300は、ログイン
データ13100を決済仲介システム1200(振込口
座登録処理1282)に送信し認証を要求する。決済仲
介システム1200は、送信されたログインデータ13
100を、図11に示す振込口座登録処理1282の処
理ステップ11010により受信する。受益人システム
1300は、認証要求に対する返信を、処理ステップ1
1030あるいは処理ステップ11110により実行す
る。次に認証が失敗した場合に、受益人システム130
0は、振込口座指定処理1380を終了する。認証が成
功した場合に、受益人システム1300は、振込口座登
録処理1282から支払意図3100を受信する。決済
仲介システム1200は、支払意図3100の受信に対
する送信を、振込口座登録処理1282の処理ステップ
11050により実行する。次に受益人システム130
0は、図9に示す振込口座指定画面9100を受益人シ
ステム1300の出力装置2050を用いて表示する。
支払意図表示欄9110には、支払意図3100の内容
を表示する。次に受益人システム1300は、受益人シ
ステム1300の入力装置2040を用いて、振込口座
入力欄9120に対する値の入力を受ける。次に受益人
システム1300は、登録ボタン9130のクリックの
入力を受益人システム1300の入力装置2040から
受けると、図4に示す振込口座指定データ4100を作
成する。振込口座指定データ4100は、支払意図31
00のハッシュ値が求められ、支払意図のハッシュ値4
110に格納され、振込口座入力欄9120の内容が振
込口座4120にコピーされ、支払意図のハッシュ値4
110と振込口座4120に対する署名値とが、受益人
秘密鍵1610を用いて計算され、署名値を受取人署名
4130に格納される。支払意図のハッシュ値4110
は、振込口座指定データ4100がどの支払意図310
0に対して、振込口座4120を指定したのかを特定す
るためのデータであり、その作成方法は、前述した署名
付与手順におけるハッシュ値の計算方法と同じである。
即ち、支払意図3100の内容が一連のビット列にシリ
アライズされ、ビット列を固定長の疑似乱数を生成する
不可逆な一方向関数計算(ハッシュ関数)で処理され
る。次に受益人システム1300は、振込口座指定デー
タ4100を決済仲介システム1200(振込口座登録
処理1282)に送信し、振込口座の登録が成功したか
どうかの返信を受信する。前記送信は、図11に示す振
込口座登録処理1282の処理ステップ11060によ
り処理する。また、決済仲介システム1200は、振込
口座の登録が成功したかどうかの返信を、処理ステップ
11100あるいは処理ステップ11120により実行
する。以上により、受益人システム1300は、振込口
座指定処理1380を終了する。
【0027】次に図11を用いて振込口座登録処理12
82について述べる。処理ステップ11010におい
て、決済仲介システム1200は、振込口座指定処理1
380からログインデータ13100を受信する。処理
ステップ11015において、決済仲介システム120
0は、ログインデータ13100の参加者ID5100
と一致する参加者ID5100を有する参加者情報50
00を参加者DB1210から検索する。以後本処理の
説明において、単に参加者情報5000と記載した場合
は、本処理ステップにて検索した参加者情報を指すもの
とする。処理ステップ11020において、決済仲介シ
ステム1200は、参加者情報5000のパスワード5
200とログインデータ13100のパスワード520
0が一致するかを判断し、一致すると判断した場合は処
理フローを11030に移し、一致しないと判断した場
合を処理フローを11110に移す。処理ステップ11
030において、決済仲介システム1200は、認証が
成功した旨を受益人システム1300(振込口座指定処
理1380)に返信する。処理ステップ11040にお
いて、決済仲介システム1200は、支払意図DB12
20の中から、支払意図3100の受取人ID3160
が参加者情報5000の取扱対象者ID5150と一致
しかつ状態6100が「振込口座未指定」の支払意図情
報6000を検索する。以下本処理の説明において、単
に支払意図情報6000と記した場合は、本処理ステッ
プで検索した支払意図情報6000を指すものとする。
処理ステップ11050において、決済仲介システム1
200は、支払意図情報6000の支払意図3100を
受益人システム1300(振込口座指定処理1380)
に送信する。処理ステップ11060において、決済仲
介システム1200は、受益人システム1300(振込
口座指定処理1380)から振込口座指定データ410
0を受信する。処理ステップ11070において、決済
仲介システム1200は、振込口座指定データ4100
の支払意図のハッシュ値4110が正しいかを検証し、
正しいと判断した場合は処理フローを処理ステップ11
080に移し、正しくないと判断した場合は処理フロー
を処理ステップ11120に移す。支払意図のハッシュ
値4110が正しいかは、支払意図情報6000の支払
意図3100が一連のビット列にシリアライズされ、そ
のハッシュ値が求められ、求られたハッシュ値が支払意
図のハッシュ値4110と一致するかで判断される。処
理ステップ11080において、決済仲介システム12
00は、振込口座指定データ4100の受取人署名41
30が正しいかを検証し、正しいと判断した場合は処理
フローを処理ステップ11090に移し、正しくないと
判断した場合は処理フローを処理ステップ11120に
移す。処理ステップ11090において、決済仲介シス
テム1200は、支払意図情報6000の振込口座指定
データ4100に、受信した振込口座指定データ410
0を登録する。また決済仲介システム1200は、支払
意図情報6000の状態6100を「未支払」に変更す
る。処理ステップ11100において、決済仲介システ
ム1200は、振込口座の登録が成功した旨を、受益人
システム1300(振込口座指定処理1380)に返信
して、振込口座登録処理1282を終了する。処理ステ
ップ11110において、決済仲介システム1200
は、認証が失敗した旨を、受益人システム1300(振
込口座指定処理1380)に返信して、振込口座登録処
理1282を終了する。処理ステップ11120におい
て、決済仲介システム1200は、振込口座の登録が失
敗した旨を、受益人システム1300(振込口座指定処
理1380)に返信して、振込口座登録処理1282を
終了する。
82について述べる。処理ステップ11010におい
て、決済仲介システム1200は、振込口座指定処理1
380からログインデータ13100を受信する。処理
ステップ11015において、決済仲介システム120
0は、ログインデータ13100の参加者ID5100
と一致する参加者ID5100を有する参加者情報50
00を参加者DB1210から検索する。以後本処理の
説明において、単に参加者情報5000と記載した場合
は、本処理ステップにて検索した参加者情報を指すもの
とする。処理ステップ11020において、決済仲介シ
ステム1200は、参加者情報5000のパスワード5
200とログインデータ13100のパスワード520
0が一致するかを判断し、一致すると判断した場合は処
理フローを11030に移し、一致しないと判断した場
合を処理フローを11110に移す。処理ステップ11
030において、決済仲介システム1200は、認証が
成功した旨を受益人システム1300(振込口座指定処
理1380)に返信する。処理ステップ11040にお
いて、決済仲介システム1200は、支払意図DB12
20の中から、支払意図3100の受取人ID3160
が参加者情報5000の取扱対象者ID5150と一致
しかつ状態6100が「振込口座未指定」の支払意図情
報6000を検索する。以下本処理の説明において、単
に支払意図情報6000と記した場合は、本処理ステッ
プで検索した支払意図情報6000を指すものとする。
処理ステップ11050において、決済仲介システム1
200は、支払意図情報6000の支払意図3100を
受益人システム1300(振込口座指定処理1380)
に送信する。処理ステップ11060において、決済仲
介システム1200は、受益人システム1300(振込
口座指定処理1380)から振込口座指定データ410
0を受信する。処理ステップ11070において、決済
仲介システム1200は、振込口座指定データ4100
の支払意図のハッシュ値4110が正しいかを検証し、
正しいと判断した場合は処理フローを処理ステップ11
080に移し、正しくないと判断した場合は処理フロー
を処理ステップ11120に移す。支払意図のハッシュ
値4110が正しいかは、支払意図情報6000の支払
意図3100が一連のビット列にシリアライズされ、そ
のハッシュ値が求められ、求られたハッシュ値が支払意
図のハッシュ値4110と一致するかで判断される。処
理ステップ11080において、決済仲介システム12
00は、振込口座指定データ4100の受取人署名41
30が正しいかを検証し、正しいと判断した場合は処理
フローを処理ステップ11090に移し、正しくないと
判断した場合は処理フローを処理ステップ11120に
移す。処理ステップ11090において、決済仲介シス
テム1200は、支払意図情報6000の振込口座指定
データ4100に、受信した振込口座指定データ410
0を登録する。また決済仲介システム1200は、支払
意図情報6000の状態6100を「未支払」に変更す
る。処理ステップ11100において、決済仲介システ
ム1200は、振込口座の登録が成功した旨を、受益人
システム1300(振込口座指定処理1380)に返信
して、振込口座登録処理1282を終了する。処理ステ
ップ11110において、決済仲介システム1200
は、認証が失敗した旨を、受益人システム1300(振
込口座指定処理1380)に返信して、振込口座登録処
理1282を終了する。処理ステップ11120におい
て、決済仲介システム1200は、振込口座の登録が失
敗した旨を、受益人システム1300(振込口座指定処
理1380)に返信して、振込口座登録処理1282を
終了する。
【0028】次に定期処理1284について図12を用
いて述べる。処理ステップ12010において、決済仲
介システム1200は、処理ステップ12050によっ
てなされる処理ループにおいて未処理の支払意図情報6
000を支払意図DB1220から選択する。以後、処
理ステップ12050を除く本処理の説明において、単
に支払意図情報6000と記した場合は、本処理で選択
した支払意図情報6000を指すものとする。処理ステ
ップ12020において、決済仲介システム1200
は、支払意図情報6000の状態6100が「失効済」
あるいは「支払済」かを判断し、「失効済」あるいは
「支払済」である場合は処理フローを処理ステップ12
050に移し、「失効済」及び「支払済」でない場合
(「未払い」である場合)は処理フローを処理ステップ
12030に移す。処理ステップ12030において、
決済仲介システム1200は、支払意図情報6000の
支払意図3100の支払期限3140が過ぎたかを判断
し、過ぎた場合は処理フローを処理ステップ12060
に移し、過ぎてない場合は処理フローを処理ステップ1
2040に移す。処理ステップ12040において、決
済仲介システム1200は、支払意図情報6000の支
払意図3100の支払日3130が過ぎたかを判断し、
過ぎた場合は処理フローを処理ステップ12080に移
し、過ぎてない場合は処理フローを処理ステップ120
50に移す。処理ステップ12050において、決済仲
介システム1200は、支払意図DB1220に登録し
てある全ての支払意図情報6000に対して処理が完了
したかを判断し、完了したと判断した場合は定期処理1
284を終了し、完了していないと判断した場合は処理
フローを処理ステップ12010に移す。処理ステップ
12060において、決済仲介システム1200は、支
払意図情報6000の状態6100を「失効済」にす
る。処理ステップ12070において、決済仲介システ
ム1200は、支払意図情報6000の支払意図310
0の支払人ID3110と受取人ID3160と同一の
値を取扱対象者ID5150に持つ参加者情報5000
をそれぞれ検索する。次に決済仲介システム1200
は、それぞれの参加者情報5000の連絡先5400に
対して、支払意図が失効した旨を通知する。例えば、
「失効済」の文字列と共に、支払意図3100を送信す
る。処理ステップ12080において、決済仲介システ
ム1200は、状態6100が「振込口座未指定」かを
判断して、「振込口座未指定」である場合は処理フロー
を処理ステップ12050に移し、「振込口座未指定」
でない場合は処理フローを処理ステップ12090に移
す。処理ステップ12090において、決済仲介システ
ム1200は、金融システム1400(振込処理148
0)に対して支払意図3100と振込口座指定データ4
100を送信する。処理ステップ12100において、
決済仲介システム1200は、支払意図情報6000の
支払意図3100の支払人ID3110と受取人ID3
160と同一の値を取扱対象者ID5150に持つ参加
者情報5000を検索する。次に決済仲介システム12
00は、それぞれの参加者情報の連絡先5400に対し
て、支払が行われた旨を通知する。例えば、「支払済」
の文字列と共に、支払意図3100を送信する。決済仲
介システム1200は、処理ステップ12100の終了
後は処理フローを処理ステップ12050に移す。
いて述べる。処理ステップ12010において、決済仲
介システム1200は、処理ステップ12050によっ
てなされる処理ループにおいて未処理の支払意図情報6
000を支払意図DB1220から選択する。以後、処
理ステップ12050を除く本処理の説明において、単
に支払意図情報6000と記した場合は、本処理で選択
した支払意図情報6000を指すものとする。処理ステ
ップ12020において、決済仲介システム1200
は、支払意図情報6000の状態6100が「失効済」
あるいは「支払済」かを判断し、「失効済」あるいは
「支払済」である場合は処理フローを処理ステップ12
050に移し、「失効済」及び「支払済」でない場合
(「未払い」である場合)は処理フローを処理ステップ
12030に移す。処理ステップ12030において、
決済仲介システム1200は、支払意図情報6000の
支払意図3100の支払期限3140が過ぎたかを判断
し、過ぎた場合は処理フローを処理ステップ12060
に移し、過ぎてない場合は処理フローを処理ステップ1
2040に移す。処理ステップ12040において、決
済仲介システム1200は、支払意図情報6000の支
払意図3100の支払日3130が過ぎたかを判断し、
過ぎた場合は処理フローを処理ステップ12080に移
し、過ぎてない場合は処理フローを処理ステップ120
50に移す。処理ステップ12050において、決済仲
介システム1200は、支払意図DB1220に登録し
てある全ての支払意図情報6000に対して処理が完了
したかを判断し、完了したと判断した場合は定期処理1
284を終了し、完了していないと判断した場合は処理
フローを処理ステップ12010に移す。処理ステップ
12060において、決済仲介システム1200は、支
払意図情報6000の状態6100を「失効済」にす
る。処理ステップ12070において、決済仲介システ
ム1200は、支払意図情報6000の支払意図310
0の支払人ID3110と受取人ID3160と同一の
値を取扱対象者ID5150に持つ参加者情報5000
をそれぞれ検索する。次に決済仲介システム1200
は、それぞれの参加者情報5000の連絡先5400に
対して、支払意図が失効した旨を通知する。例えば、
「失効済」の文字列と共に、支払意図3100を送信す
る。処理ステップ12080において、決済仲介システ
ム1200は、状態6100が「振込口座未指定」かを
判断して、「振込口座未指定」である場合は処理フロー
を処理ステップ12050に移し、「振込口座未指定」
でない場合は処理フローを処理ステップ12090に移
す。処理ステップ12090において、決済仲介システ
ム1200は、金融システム1400(振込処理148
0)に対して支払意図3100と振込口座指定データ4
100を送信する。処理ステップ12100において、
決済仲介システム1200は、支払意図情報6000の
支払意図3100の支払人ID3110と受取人ID3
160と同一の値を取扱対象者ID5150に持つ参加
者情報5000を検索する。次に決済仲介システム12
00は、それぞれの参加者情報の連絡先5400に対し
て、支払が行われた旨を通知する。例えば、「支払済」
の文字列と共に、支払意図3100を送信する。決済仲
介システム1200は、処理ステップ12100の終了
後は処理フローを処理ステップ12050に移す。
【0029】金融期間は、支払意図3100の支払口座
3150で指定された口座を有する、即ち、社会保険庁
名義の口座を有する金融機関であってもよいし、振込口
座指定データ4100の振込口座4120で指定される
口座を有する、即ち、受益人名義の口座を有する金融機
関であってもよい。支払意図3100の支払口座315
0で指定された口座を有する金融機関と振込口座指定デ
ータ4100の振込口座4120で指定される口座を有
する金融機関とが、同一である場合もあれば、異なる場
合もある。支払意図3100の支払口座3150で指定
された口座を有する金融機関と振込口座指定データ41
00の振込口座4120で指定される口座を有する金融
機関とが、同一である場合は、金融機関は、自己内で口
座間の振り込みを行う。支払意図3100の支払口座3
150で指定された口座を有する金融機関と振込口座指
定データ4100の振込口座4120で指定される口座
を有する金融機関とが、異なる場合は、一方の金融機関
が他方の金融機関から振り込みを行う。
3150で指定された口座を有する、即ち、社会保険庁
名義の口座を有する金融機関であってもよいし、振込口
座指定データ4100の振込口座4120で指定される
口座を有する、即ち、受益人名義の口座を有する金融機
関であってもよい。支払意図3100の支払口座315
0で指定された口座を有する金融機関と振込口座指定デ
ータ4100の振込口座4120で指定される口座を有
する金融機関とが、同一である場合もあれば、異なる場
合もある。支払意図3100の支払口座3150で指定
された口座を有する金融機関と振込口座指定データ41
00の振込口座4120で指定される口座を有する金融
機関とが、同一である場合は、金融機関は、自己内で口
座間の振り込みを行う。支払意図3100の支払口座3
150で指定された口座を有する金融機関と振込口座指
定データ4100の振込口座4120で指定される口座
を有する金融機関とが、異なる場合は、一方の金融機関
が他方の金融機関から振り込みを行う。
【0030】金融機関が振込口座指定データ4100の
振込口座4120で指定される口座を有する金融機関で
あって、複数の受益人から決済仲介人に対し異なる金融
機関の振込口座の指定1830を通知する場合は、決済
仲介人は、金融機関毎に支払意図3100と振込口座指
定データ4100を通知するのが好ましい。即ち、処理
ステップ12080と処理ステップ12090との間に
おいて、決済仲介システム1200は、振込口座指定デ
ータ4100の振込口座欄に金融期間名称を識別し、金
融機関名称毎に支払意図3100と振込口座指定データ
4100をまとめる。処理ステップ12090におい
て、決済仲介システム1200は、金融機関毎に金融シ
ステム1400(振込処理1480)に対して支払意図
3100と振込口座指定データ4100を送信するこれ
により、決済仲介人は、金融機関へ振込要求1840を
通知する回数が減少するため、決済仲介人の処置手続負
担を低減することができるという効果を有する。
振込口座4120で指定される口座を有する金融機関で
あって、複数の受益人から決済仲介人に対し異なる金融
機関の振込口座の指定1830を通知する場合は、決済
仲介人は、金融機関毎に支払意図3100と振込口座指
定データ4100を通知するのが好ましい。即ち、処理
ステップ12080と処理ステップ12090との間に
おいて、決済仲介システム1200は、振込口座指定デ
ータ4100の振込口座欄に金融期間名称を識別し、金
融機関名称毎に支払意図3100と振込口座指定データ
4100をまとめる。処理ステップ12090におい
て、決済仲介システム1200は、金融機関毎に金融シ
ステム1400(振込処理1480)に対して支払意図
3100と振込口座指定データ4100を送信するこれ
により、決済仲介人は、金融機関へ振込要求1840を
通知する回数が減少するため、決済仲介人の処置手続負
担を低減することができるという効果を有する。
【0031】次に振込処理1480について述べる。振
込処理1480において、金融システム1400は、図
12に示す定期処理1284の処理ステップ12100
で支払意図3100と振込口座指定データ4100を受
信すると、支払意図3100の支払口座3150で指定
された口座から、振込口座指定データ4100の振込口
座4120で指定される口座へ、支払意図3100の支
払額3120で指定された金額の金銭を振込えて処理を
終了する。金融システム1400が振込処理1480を
実行するかわりに、決済仲介システム1200が支払口
座3150および振込口座4120を管理する場合、つ
まり決済仲介システム1200を有する機関が金融機関
の場合は、決済仲介システム1200が振込処理148
0を行ってもよい。
込処理1480において、金融システム1400は、図
12に示す定期処理1284の処理ステップ12100
で支払意図3100と振込口座指定データ4100を受
信すると、支払意図3100の支払口座3150で指定
された口座から、振込口座指定データ4100の振込口
座4120で指定される口座へ、支払意図3100の支
払額3120で指定された金額の金銭を振込えて処理を
終了する。金融システム1400が振込処理1480を
実行するかわりに、決済仲介システム1200が支払口
座3150および振込口座4120を管理する場合、つ
まり決済仲介システム1200を有する機関が金融機関
の場合は、決済仲介システム1200が振込処理148
0を行ってもよい。
【0032】決済仲介人システム1200は、支払義務
の発生毎(決済毎)に受益人システム1300から振込
口座の指定1830がなければ、金融システム1400
に対し振込要求1840を送信しない。即ち、決済仲介
人システム1200は、支払義務の発生毎(決済毎)に
受益人システム1300から振込口座の指定1830を
受信した場合に限り、金融システム1400に対し振込
要求1840を送信する。よって、受益者は、今回の決
済時の振込口座が前回の決済時と同一の振込口座であっ
ても、決済仲介人へ振込口座を通知しないと、金銭を受
け取ることができない。一方、支払意図の登録1810
又は支払意図の到着通知1820は、支払義務の発生毎
(決済毎)に実行してもよいし、複数の支払義務の発生
(決済毎)毎に実行してもよい。
の発生毎(決済毎)に受益人システム1300から振込
口座の指定1830がなければ、金融システム1400
に対し振込要求1840を送信しない。即ち、決済仲介
人システム1200は、支払義務の発生毎(決済毎)に
受益人システム1300から振込口座の指定1830を
受信した場合に限り、金融システム1400に対し振込
要求1840を送信する。よって、受益者は、今回の決
済時の振込口座が前回の決済時と同一の振込口座であっ
ても、決済仲介人へ振込口座を通知しないと、金銭を受
け取ることができない。一方、支払意図の登録1810
又は支払意図の到着通知1820は、支払義務の発生毎
(決済毎)に実行してもよいし、複数の支払義務の発生
(決済毎)毎に実行してもよい。
【0033】決済仲介人(決済仲介システム1200)
が存在しない場合は、社会保険庁(保険庁システム11
00)が、支払意図登録通知処理1280、振込口座登
録処理1282及び定期処理1284と同等の処理を行
う。また、決済仲介人(決済仲介システム1200)が
存在しない場合は、金融機関(金融システム1400)
が、支払意図登録通知処理1280、振込口座登録処理
1282及び定期処理1284と同等の処理を行う。
が存在しない場合は、社会保険庁(保険庁システム11
00)が、支払意図登録通知処理1280、振込口座登
録処理1282及び定期処理1284と同等の処理を行
う。また、決済仲介人(決済仲介システム1200)が
存在しない場合は、金融機関(金融システム1400)
が、支払意図登録通知処理1280、振込口座登録処理
1282及び定期処理1284と同等の処理を行う。
【0034】決済仲介人は、決済毎に社会保険庁から支
払意図を受けた場合に、受益人の振込口座の有無を調査
し、受益人の振込口座が存在する場合(振込口座の変更
が無い場合)は受益人へ振込口座へ金銭を振り込み(受
益人へ支払意図の到着を通知してもよし、通知しなくて
もよい。)、受益人の振込口座が存在しない場合(振込
口座の変更があった場合)は、受益人へ支払意図の到着
を通知すると共に支払意図を送信し受益人から振込口座
の指定があった場合に新たに指定された振込口座へ金銭
を振り込んでもよい。即ち、振込口座登録処理1282
において、決済人システム1200は、受益人から振込
口座の指定を受けた場合にその振込口座指定データ41
00を支払意図DB1220に登録する。次に、支払意
図登録通知処理1280において、決済人システム12
00は、保険庁システム1100から支払意図の登録1
810を受信した場合に、受益人システム1300へ支
払意図の到着通知1820を送信する。また、振込口座
確認処理において、決済人システム1200は、保険庁
システム1100から支払意図の登録1810を受信し
た場合に、支払意図の受益人IDをキーとして支払意図
DB1220から受益人IDに対応する振込口座を検索
し、検索結果として抽出された振込口座を有する金融機
関システム1400へその(受益人名義の)振込口座の
有無を確認するための確認要求を送信する。また、振込
口座確認処理において、決済人システム1200は、保
険庁システム1100から支払意図の登録1810を受
信した場合に、支払意図DBの振込口座指定データ41
00の状態6100を「振込口座未指定」にする。金融
機関システム1400は、振込口座の有無を調査し、振
込口座が存在する場合はその旨を通知するための回答を
仲介人システム1200へ送信し、振込口座が存在しな
い場合はその旨を通知するための回答を仲介人システム
1200へ送信する。金融機関システム1400は、振
込口座の名義人が振込口座が喪失(解約)した場合、振
込口座を変更した場合、振込口座の名義人を変更した場
合に、振込口座が存在しないと判断する。振込口座確認
処理において、決済仲介人システム1200は、振込口
座が存在する旨の回答を受信した場合は、支払意図DB
の振込口座指定データ4100の状態6100を「未支
払」にする。尚、決済仲介人システム1200は、振込
口座が存在する旨の回答を受信した場合は、支払意図を
受益人システム1300へ送信する必要がないし、振込
口座の指定1830を受益人システム1300から受信
する必要がない。但し、決済仲介人システム1200
は、振込口座が存在する旨の回答を受信した場合は、支
払意図の到着通知1820を受益人システム1300へ
送信するのが好ましいが、支払意図の到着通知1820
を受益人システム1300へ送信しなくてもよい。一
方、振込口座確認処理において、決済仲介人システム1
200は、振込口座が存在しない旨の回答を受信した場
合は、支払意図登録通知処理1280の処理10070
以降を実行する。これにより、受益人は、振込口座の変
更又は解約をした場合にのみ、決済仲介人へ振込口座の
指定を通知すればよくなるため、受益人の被決済手続き
の負担が軽減することができる。
払意図を受けた場合に、受益人の振込口座の有無を調査
し、受益人の振込口座が存在する場合(振込口座の変更
が無い場合)は受益人へ振込口座へ金銭を振り込み(受
益人へ支払意図の到着を通知してもよし、通知しなくて
もよい。)、受益人の振込口座が存在しない場合(振込
口座の変更があった場合)は、受益人へ支払意図の到着
を通知すると共に支払意図を送信し受益人から振込口座
の指定があった場合に新たに指定された振込口座へ金銭
を振り込んでもよい。即ち、振込口座登録処理1282
において、決済人システム1200は、受益人から振込
口座の指定を受けた場合にその振込口座指定データ41
00を支払意図DB1220に登録する。次に、支払意
図登録通知処理1280において、決済人システム12
00は、保険庁システム1100から支払意図の登録1
810を受信した場合に、受益人システム1300へ支
払意図の到着通知1820を送信する。また、振込口座
確認処理において、決済人システム1200は、保険庁
システム1100から支払意図の登録1810を受信し
た場合に、支払意図の受益人IDをキーとして支払意図
DB1220から受益人IDに対応する振込口座を検索
し、検索結果として抽出された振込口座を有する金融機
関システム1400へその(受益人名義の)振込口座の
有無を確認するための確認要求を送信する。また、振込
口座確認処理において、決済人システム1200は、保
険庁システム1100から支払意図の登録1810を受
信した場合に、支払意図DBの振込口座指定データ41
00の状態6100を「振込口座未指定」にする。金融
機関システム1400は、振込口座の有無を調査し、振
込口座が存在する場合はその旨を通知するための回答を
仲介人システム1200へ送信し、振込口座が存在しな
い場合はその旨を通知するための回答を仲介人システム
1200へ送信する。金融機関システム1400は、振
込口座の名義人が振込口座が喪失(解約)した場合、振
込口座を変更した場合、振込口座の名義人を変更した場
合に、振込口座が存在しないと判断する。振込口座確認
処理において、決済仲介人システム1200は、振込口
座が存在する旨の回答を受信した場合は、支払意図DB
の振込口座指定データ4100の状態6100を「未支
払」にする。尚、決済仲介人システム1200は、振込
口座が存在する旨の回答を受信した場合は、支払意図を
受益人システム1300へ送信する必要がないし、振込
口座の指定1830を受益人システム1300から受信
する必要がない。但し、決済仲介人システム1200
は、振込口座が存在する旨の回答を受信した場合は、支
払意図の到着通知1820を受益人システム1300へ
送信するのが好ましいが、支払意図の到着通知1820
を受益人システム1300へ送信しなくてもよい。一
方、振込口座確認処理において、決済仲介人システム1
200は、振込口座が存在しない旨の回答を受信した場
合は、支払意図登録通知処理1280の処理10070
以降を実行する。これにより、受益人は、振込口座の変
更又は解約をした場合にのみ、決済仲介人へ振込口座の
指定を通知すればよくなるため、受益人の被決済手続き
の負担が軽減することができる。
【0035】社内保険庁を企業(雇用者)とし、受益人
を前記企業の従業者(被雇用者)とすることにより、本
発明は給与の支払システムに適用することが可能であ
る。また保険庁を株式会社とし、受益人を株式会社の株
主とすることにより、本発明は株式の配当金支払システ
ムに適用することが可能である。また保険庁を社債の発
行企業とし、受益人を前記社債の権利者とすることで、
本発明を利息の配当システムに適用することが可能であ
る。
を前記企業の従業者(被雇用者)とすることにより、本
発明は給与の支払システムに適用することが可能であ
る。また保険庁を株式会社とし、受益人を株式会社の株
主とすることにより、本発明は株式の配当金支払システ
ムに適用することが可能である。また保険庁を社債の発
行企業とし、受益人を前記社債の権利者とすることで、
本発明を利息の配当システムに適用することが可能であ
る。
【0036】次に、本発明の第2の実施形態について、
図14、15を用いて述べる。
図14、15を用いて述べる。
【0037】第2の実施形態と第1の実施形態の違いは
図14に示すように、決済仲介システム1200が金融
システム1480に対して振込要求を行うのではなく、
受益人システム1300が金融システム1480に対し
て直接振込要求を行う点である。よって、第2の実施形
態のシステム構成は、第1の実施形態のシステム構成と
以下の点において異なる。まず決済仲介システム120
0の記憶装置2010は、支払意図送信処理14100
を記憶する。受益人システム1300の記憶装置201
0は、支払意図要求処理14200と振込要求処理14
300を記憶する。受益人システム1300のICカー
ドR/W2060は、受益人ICカード1600が挿入
される。金融システム1400の記憶装置2010は、
振込処理II14400を記憶する。金融システム140
0のバス2070は、参加者DB1210に接続され
る。
図14に示すように、決済仲介システム1200が金融
システム1480に対して振込要求を行うのではなく、
受益人システム1300が金融システム1480に対し
て直接振込要求を行う点である。よって、第2の実施形
態のシステム構成は、第1の実施形態のシステム構成と
以下の点において異なる。まず決済仲介システム120
0の記憶装置2010は、支払意図送信処理14100
を記憶する。受益人システム1300の記憶装置201
0は、支払意図要求処理14200と振込要求処理14
300を記憶する。受益人システム1300のICカー
ドR/W2060は、受益人ICカード1600が挿入
される。金融システム1400の記憶装置2010は、
振込処理II14400を記憶する。金融システム140
0のバス2070は、参加者DB1210に接続され
る。
【0038】次に同じく図14を用いて第2の実施形態
の処理概要について述べる。支払意図3100のの作
成、登録、通知に関する処理である支払意図作成処理1
180、支払意図登録通知処理1280の処理内容につ
いては第1の実施形態と同じである。受益人システム1
300の支払意図要求処理14200の要求により、支
払意図送信処理14100は、支払意図3100を送信
する。このメッセージフローが支払意図のダウンロード
14010である。次に振込要求処理14300は、振
込口座指定データ4100を作成し、振込処理II144
00に支払意図3100と振込口座指定データ4100
を送信して振込を要求する。振込処理II14400は、
支払意図3100と振込口座指定データ4100の内容
をチェックし振込を行う。
の処理概要について述べる。支払意図3100のの作
成、登録、通知に関する処理である支払意図作成処理1
180、支払意図登録通知処理1280の処理内容につ
いては第1の実施形態と同じである。受益人システム1
300の支払意図要求処理14200の要求により、支
払意図送信処理14100は、支払意図3100を送信
する。このメッセージフローが支払意図のダウンロード
14010である。次に振込要求処理14300は、振
込口座指定データ4100を作成し、振込処理II144
00に支払意図3100と振込口座指定データ4100
を送信して振込を要求する。振込処理II14400は、
支払意図3100と振込口座指定データ4100の内容
をチェックし振込を行う。
【0039】以下第2の実施形態において、第1の実施
形態と異なる処理である、振込意図送信処理1410
0、支払意図要求処理14200、振込要求処理143
00、振込処理14400について述べる。
形態と異なる処理である、振込意図送信処理1410
0、支払意図要求処理14200、振込要求処理143
00、振込処理14400について述べる。
【0040】支払意図要求処理14200は、第1の実
施形態の振込口座指定処理1380における認証を受け
て支払意図3100を受信するまでと同じ処理を行う。
但し、第1の実施形態の振込口座指定処理1380が、
振込口座登録処理1282に対して認証の要求と支払意
図の受信を行っていたのに対して、第2の実施形態の支
払意図要求処理14200は、支払意図送信処理141
00に対して認証の要求と支払意図の受信を行う。また
支払意図3100は、支払意図送信処理14100から
受益人システム1300の記憶装置2010ではなく、
受益人ICカード1600に暗号化して送信する。これ
により支払意図1600の複製が受益人システム130
0において受益人ICカード1600外に作成されない
ようにする。
施形態の振込口座指定処理1380における認証を受け
て支払意図3100を受信するまでと同じ処理を行う。
但し、第1の実施形態の振込口座指定処理1380が、
振込口座登録処理1282に対して認証の要求と支払意
図の受信を行っていたのに対して、第2の実施形態の支
払意図要求処理14200は、支払意図送信処理141
00に対して認証の要求と支払意図の受信を行う。また
支払意図3100は、支払意図送信処理14100から
受益人システム1300の記憶装置2010ではなく、
受益人ICカード1600に暗号化して送信する。これ
により支払意図1600の複製が受益人システム130
0において受益人ICカード1600外に作成されない
ようにする。
【0041】支払意図送信処理14100は、支払意図
3100の返信に至るまで図11に示す振込口座登録処
理1282と同様の処理(処理ステップ11050まで
と処理ステップ11110)を行う。ただし支払意図送
信処理14100は、送信される振込意図に暗号化を行
い受益人ICカード1600に対して送信する。また支
払意図送信処理14100は、支払意図3100の送信
を完了すると、送信した支払意図3100を削除する。
これにより、受益人システム1200が二重に支払意図
3100のダウンロードを行うのが防止される。
3100の返信に至るまで図11に示す振込口座登録処
理1282と同様の処理(処理ステップ11050まで
と処理ステップ11110)を行う。ただし支払意図送
信処理14100は、送信される振込意図に暗号化を行
い受益人ICカード1600に対して送信する。また支
払意図送信処理14100は、支払意図3100の送信
を完了すると、送信した支払意図3100を削除する。
これにより、受益人システム1200が二重に支払意図
3100のダウンロードを行うのが防止される。
【0042】次に振込要求処理14300について述べ
る。振込要求処理14300は、認証を受けてから振込
口座指定データ4100を送信するまで、振込口座指定
処理1380と同様の処理を行う。ただし以下の点にお
いて振込口座指定処理1380と異なる。振込要求処理
14300は、支払意図3100を振込口座登録処理1
282からダウンロードしない。支払意図のハッシュ値
4110は、受益人ICカード1600内で計算され
る。これにより、支払意図3100の不正コピーを防止
することができる。尚、金融システム1400において
支払意図の検証を行うため、保険庁システム1100又
は決済仲介システム1200が、金融システム1400
へ支払意図を予め送信してもよい。また振込要求処理1
4300は、支払意図3100を振込処理II14400
に対して送信する。この時支払意図3100は、支払意
図要求処理14200と同様暗号化して送信し送信後は
受益人ICカード1600内の支払意図3100が削除
される、これにより、受益人システム1300において
受益人ICカード1600外での支払意図3100の複
製を防止することができる。支払意図3100の送信
は、図15に示す振込処理II14400の処理ステップ
15050で実行する。次に振込要求処理14300
は、振込口座指定データ4100を振込処理II1440
0に送信する。振込口座指定データ4100の送信は、
振込処理II14400の処理ステップ15060におい
て実行する。さらに振込処理14400により振込が失
敗し、支払意図3100が返信された場合は、支払意図
要求処理14200における支払意図3100の受信の
場合と同様に、返信された支払意図3100を受益人I
Cカード1600に格納する。この送信は振込処理II1
4400の処理ステップ15130において実行する。
詳細は後述する。
る。振込要求処理14300は、認証を受けてから振込
口座指定データ4100を送信するまで、振込口座指定
処理1380と同様の処理を行う。ただし以下の点にお
いて振込口座指定処理1380と異なる。振込要求処理
14300は、支払意図3100を振込口座登録処理1
282からダウンロードしない。支払意図のハッシュ値
4110は、受益人ICカード1600内で計算され
る。これにより、支払意図3100の不正コピーを防止
することができる。尚、金融システム1400において
支払意図の検証を行うため、保険庁システム1100又
は決済仲介システム1200が、金融システム1400
へ支払意図を予め送信してもよい。また振込要求処理1
4300は、支払意図3100を振込処理II14400
に対して送信する。この時支払意図3100は、支払意
図要求処理14200と同様暗号化して送信し送信後は
受益人ICカード1600内の支払意図3100が削除
される、これにより、受益人システム1300において
受益人ICカード1600外での支払意図3100の複
製を防止することができる。支払意図3100の送信
は、図15に示す振込処理II14400の処理ステップ
15050で実行する。次に振込要求処理14300
は、振込口座指定データ4100を振込処理II1440
0に送信する。振込口座指定データ4100の送信は、
振込処理II14400の処理ステップ15060におい
て実行する。さらに振込処理14400により振込が失
敗し、支払意図3100が返信された場合は、支払意図
要求処理14200における支払意図3100の受信の
場合と同様に、返信された支払意図3100を受益人I
Cカード1600に格納する。この送信は振込処理II1
4400の処理ステップ15130において実行する。
詳細は後述する。
【0043】次に振込処理II14400について、図1
5のフローチャートを用いて述べる。
5のフローチャートを用いて述べる。
【0044】振込処理II14400における認証処理で
ある処理ステップ15010から処理ステップ1504
0と処理ステップ15120の処理内容は、振込口座登
録処理1282における認証処理である処理ステップ1
1010から処理ステップ11040及び処理ステップ
11110と同様の処理を行う。但し振込口座登録処理
1282が、決済仲介システム1200に接続してある
参加者DB1210にアクセスするのに対して、振込処
理II14400は、金融システム1400に接続してあ
る参加者DB1210にアクセスする点において異な
る。処理ステップ15050において、金融システム1
400は、支払意図3100を受信し復号化する。以後
本処理の説明において単に支払意図3100と記載した
場合は、本処理ステップで受信した支払意図3100を
指すものとする。処理ステップ15060において、金
融システム1400は、振込口座指定データ4100を
受信する。以後本処理の説明において単に振込口座指定
データ4100と記載した場合は、本処理ステップで受
信した振込口座指定データ4100を指すものとする。
処理ステップ15070において、金融システム140
0は、支払意図3100の支払人署名3170が正当な
署名であるかを検証し、正しいと判断した場合は処理フ
ローを処理ステップ15075に移し、正しくないと判
断した場合は処理フローを処理ステップ15130に移
す。この検証は、支払意図登録通知処理1280の処理
ステップ10050における署名の検証と同様に行う。
処理ステップ15075において、金融システム140
0は、振込口座指定データ4100内の支払意図のハッ
シュ値4110が正しいハッシュ値かを検証し、正しい
と判断した場合には、処理フローを15080に移し、
正しくないと判断した場合は処理フローを処理ステップ
15130に移す。この検証は、振込口座登録処理12
82の処理ステップ11070の検証と同様に行う。処
理ステップ15080において、金融システム1400
は、振込口座指定データ4100の受取人署名4130
が正当な署名であるかを検証し、正しいと判断した場合
は処理フローを処理ステップ15090に移し、正しく
ないと判断した場合は処理フローを処理ステップ151
30に移す。この検証は、振込口座登録処理1282の
処理ステップ11080の検証と同様に行う。処理ステ
ップ15090において、金融システム1400は、支
払意図3100の支払期限3140が過ぎたかを判断
し、過ぎた場合は処理フローを処理ステップ15030
に移し、過ぎてない場合は処理フローを処理ステップ1
5100に移す。処理ステップ15100において、金
融システム1400は、支払意図3100の支払日31
30が過ぎたかを判断し、過ぎた場合は処理フローを処
理ステップ15110に移し、過ぎてない場合は処理フ
ローを処理ステップ15030に移す。処理ステップ1
5110において、金融システム1400は、支払意図
3100の支払口座3150から振込口座指定データ4
100の振込口座4120に支払意図3100の支払額
3120で示された金額を振込え振込処理II14400
を終了する。処理ステップ15130において、金融シ
ステム1400は、振込要求処理14300に対して受
益人ICカード1600に格納するよう、支払意図を暗
号化して送り返し振込処理II14400を終了する。
ある処理ステップ15010から処理ステップ1504
0と処理ステップ15120の処理内容は、振込口座登
録処理1282における認証処理である処理ステップ1
1010から処理ステップ11040及び処理ステップ
11110と同様の処理を行う。但し振込口座登録処理
1282が、決済仲介システム1200に接続してある
参加者DB1210にアクセスするのに対して、振込処
理II14400は、金融システム1400に接続してあ
る参加者DB1210にアクセスする点において異な
る。処理ステップ15050において、金融システム1
400は、支払意図3100を受信し復号化する。以後
本処理の説明において単に支払意図3100と記載した
場合は、本処理ステップで受信した支払意図3100を
指すものとする。処理ステップ15060において、金
融システム1400は、振込口座指定データ4100を
受信する。以後本処理の説明において単に振込口座指定
データ4100と記載した場合は、本処理ステップで受
信した振込口座指定データ4100を指すものとする。
処理ステップ15070において、金融システム140
0は、支払意図3100の支払人署名3170が正当な
署名であるかを検証し、正しいと判断した場合は処理フ
ローを処理ステップ15075に移し、正しくないと判
断した場合は処理フローを処理ステップ15130に移
す。この検証は、支払意図登録通知処理1280の処理
ステップ10050における署名の検証と同様に行う。
処理ステップ15075において、金融システム140
0は、振込口座指定データ4100内の支払意図のハッ
シュ値4110が正しいハッシュ値かを検証し、正しい
と判断した場合には、処理フローを15080に移し、
正しくないと判断した場合は処理フローを処理ステップ
15130に移す。この検証は、振込口座登録処理12
82の処理ステップ11070の検証と同様に行う。処
理ステップ15080において、金融システム1400
は、振込口座指定データ4100の受取人署名4130
が正当な署名であるかを検証し、正しいと判断した場合
は処理フローを処理ステップ15090に移し、正しく
ないと判断した場合は処理フローを処理ステップ151
30に移す。この検証は、振込口座登録処理1282の
処理ステップ11080の検証と同様に行う。処理ステ
ップ15090において、金融システム1400は、支
払意図3100の支払期限3140が過ぎたかを判断
し、過ぎた場合は処理フローを処理ステップ15030
に移し、過ぎてない場合は処理フローを処理ステップ1
5100に移す。処理ステップ15100において、金
融システム1400は、支払意図3100の支払日31
30が過ぎたかを判断し、過ぎた場合は処理フローを処
理ステップ15110に移し、過ぎてない場合は処理フ
ローを処理ステップ15030に移す。処理ステップ1
5110において、金融システム1400は、支払意図
3100の支払口座3150から振込口座指定データ4
100の振込口座4120に支払意図3100の支払額
3120で示された金額を振込え振込処理II14400
を終了する。処理ステップ15130において、金融シ
ステム1400は、振込要求処理14300に対して受
益人ICカード1600に格納するよう、支払意図を暗
号化して送り返し振込処理II14400を終了する。
【0045】次に、本発明の第3の実施形態について、
図16〜19を用いて述べる。
図16〜19を用いて述べる。
【0046】第3の実施形態と第1の実施形態の違い
は、図16に示すように、受益人が受益人携帯端末16
700を用いて、携帯電話会社システム16300を介
して、決済仲介システム1200に接続する点である。
携帯電話会社システム16300は、ネットワーク15
00に接続されるネットワーク接続人システムである。
よって、第3の実施形態のシステム構成は、第1の実施
形態のシステム構成と以下の点において異なる。まずネ
ットワーク1500は、受益人システム1300の代わ
りに、携帯電話会社システム16300が接続される。
さらに携帯電話会社システム16300は、回線網16
800を介して、受益人携帯端末16700に接続され
る。携帯電話会社システム16300は、携帯電話会社
が使用するシステムであり、契約顧客への電話回線の提
供とネットワーク1500への接続サービスを提供す
る。回線網16800は、携帯電話会社システム163
00独自のネットワークであり、例えば、無線による電
話回線網である。決済仲介システム1200の記憶装置
2010は、支払意図登録通知処理1280の代わり
に、支払意図登録通知処理II16280を記憶する。携
帯電話会社システム16300のシステム構成は、図2
における保険庁システム1100のシステム構成と同じ
装置を有し、さらに回線網16800に接続された受益
人携帯端末16700と接続するための通信装置を有す
る。携帯電話会社システム16300の記憶装置201
0は、振込口座指定処理II16380および支払意図転
送処理16382および携帯電話会社の秘密鍵である携
帯電話会社秘密鍵16610を記憶する。また携帯電話
会社システム16300のバス2070は、契約者DB
16310が接続され、携帯電話会社システム1630
0内で実行する処理から契約者DB16310の内容へ
のアクセスを行う。受益人携帯端末16700は、図2
に示す保険庁システム1200と以下の点を除き同様の
システム構成を持つ。まず第3の実施形態は、ネットワ
ーク1500に接続される通信装置2020を持たず、
その代わりに回線網16800に接続される通信装置を
有する。通信装置16710の記憶装置2010は、端
末ID16710と入出力処理16780を記憶する。
端末ID16710は、携帯電話会社システム1630
0が受益人携帯端末16700を特定するために用い
る。
は、図16に示すように、受益人が受益人携帯端末16
700を用いて、携帯電話会社システム16300を介
して、決済仲介システム1200に接続する点である。
携帯電話会社システム16300は、ネットワーク15
00に接続されるネットワーク接続人システムである。
よって、第3の実施形態のシステム構成は、第1の実施
形態のシステム構成と以下の点において異なる。まずネ
ットワーク1500は、受益人システム1300の代わ
りに、携帯電話会社システム16300が接続される。
さらに携帯電話会社システム16300は、回線網16
800を介して、受益人携帯端末16700に接続され
る。携帯電話会社システム16300は、携帯電話会社
が使用するシステムであり、契約顧客への電話回線の提
供とネットワーク1500への接続サービスを提供す
る。回線網16800は、携帯電話会社システム163
00独自のネットワークであり、例えば、無線による電
話回線網である。決済仲介システム1200の記憶装置
2010は、支払意図登録通知処理1280の代わり
に、支払意図登録通知処理II16280を記憶する。携
帯電話会社システム16300のシステム構成は、図2
における保険庁システム1100のシステム構成と同じ
装置を有し、さらに回線網16800に接続された受益
人携帯端末16700と接続するための通信装置を有す
る。携帯電話会社システム16300の記憶装置201
0は、振込口座指定処理II16380および支払意図転
送処理16382および携帯電話会社の秘密鍵である携
帯電話会社秘密鍵16610を記憶する。また携帯電話
会社システム16300のバス2070は、契約者DB
16310が接続され、携帯電話会社システム1630
0内で実行する処理から契約者DB16310の内容へ
のアクセスを行う。受益人携帯端末16700は、図2
に示す保険庁システム1200と以下の点を除き同様の
システム構成を持つ。まず第3の実施形態は、ネットワ
ーク1500に接続される通信装置2020を持たず、
その代わりに回線網16800に接続される通信装置を
有する。通信装置16710の記憶装置2010は、端
末ID16710と入出力処理16780を記憶する。
端末ID16710は、携帯電話会社システム1630
0が受益人携帯端末16700を特定するために用い
る。
【0047】図16を用いて第3の実施形態の処理概要
について述べる。まず保険庁システム1100の支払意
図作成処理1180による要求を受けるて、支払意図登
録通知処理II16280が支払意図3100の登録を受
ける。このメッセージフローが支払意図の登録1810
である。支払意図登録通知処理II16280は、支払意
図到着通知転送処理16382に支払意図が到着した旨
を通知する。このメッセージフローが支払意図到着通知
1820である。支払意図到着通知転送処理16382
は、受益人携帯端末16700に支払意図3100が到
着した旨を転送する。このメッセージフローが支払意図
の到着通知II16810である。次に受益人携帯端末
は、振込口座4120の入力を受けて、振込口座指定処
理II16380に転送する。このメッセージフローが振
込口座の指定II16820である。振込振込指定処理II
16820は、振込口座指定データ4100を作成し
て、振込口座登録処理1282に送信する。このメッセ
ージフローが振込口座の指定1830である。以後の処
理は第1の実施形態と同じである。以下第1の実施形態
と異なる支払意図登録通知処理II16280、振込口座
指定処理II16380、支払意図到着通知転送処理16
382について述べる。
について述べる。まず保険庁システム1100の支払意
図作成処理1180による要求を受けるて、支払意図登
録通知処理II16280が支払意図3100の登録を受
ける。このメッセージフローが支払意図の登録1810
である。支払意図登録通知処理II16280は、支払意
図到着通知転送処理16382に支払意図が到着した旨
を通知する。このメッセージフローが支払意図到着通知
1820である。支払意図到着通知転送処理16382
は、受益人携帯端末16700に支払意図3100が到
着した旨を転送する。このメッセージフローが支払意図
の到着通知II16810である。次に受益人携帯端末
は、振込口座4120の入力を受けて、振込口座指定処
理II16380に転送する。このメッセージフローが振
込口座の指定II16820である。振込振込指定処理II
16820は、振込口座指定データ4100を作成し
て、振込口座登録処理1282に送信する。このメッセ
ージフローが振込口座の指定1830である。以後の処
理は第1の実施形態と同じである。以下第1の実施形態
と異なる支払意図登録通知処理II16280、振込口座
指定処理II16380、支払意図到着通知転送処理16
382について述べる。
【0048】支払意図登録処理II16280について述
べる。支払意図登録処理II16280と第1の実施形態
の支払意図登録処理1280との違いは、支払意図登録
処理II16280が、図10に示す支払意図登録処理1
280の処理ステップ10080における支払意図31
00が到着した旨の通知先が、支払意図到着通知転送処
理16382になる点、及び前記通知と共に支払意図3
100内の受取人ID3160を送信する点である。ま
た参加者DB1210内の取扱対象者ID5150が支
払意図3100内の受取人ID3160と同一の値を持
つ参加者情報5000の連絡先5400には、携帯電話
会社システム16300が登録される。
べる。支払意図登録処理II16280と第1の実施形態
の支払意図登録処理1280との違いは、支払意図登録
処理II16280が、図10に示す支払意図登録処理1
280の処理ステップ10080における支払意図31
00が到着した旨の通知先が、支払意図到着通知転送処
理16382になる点、及び前記通知と共に支払意図3
100内の受取人ID3160を送信する点である。ま
た参加者DB1210内の取扱対象者ID5150が支
払意図3100内の受取人ID3160と同一の値を持
つ参加者情報5000の連絡先5400には、携帯電話
会社システム16300が登録される。
【0049】次に支払意図到着通知転送処理16382
について述べる。支払意図到着通知転送処理16382
は、支払意図登録処理II16280より、支払意図31
00が到着した旨の通知受けると、受信した受取人ID
3160と同一の参加者ID5100を有する契約者情
報17000を契約者DB16310から検索する。契
約者DB16310の構造は、図17に示すように、契
約者情報17000が複数登録可能なテーブルである。
契約者情報17000は、参加者ID5100、端末I
D16710、振込口座4120の項目を有する。なお
振込口座4120については複数個存在してもよい。振
込口座4120には、例えば、受益人が過去に振込先と
して指定した振込口座や受益人が携帯電話会社へ携帯端
末の利用料金を支払う口座等を登録する。契約者情報1
7000の振込口座4120は、後述受益人携帯端末1
6700において振込先の口座を指定する処理におい
て、その振込先候補として列挙するのに用いられる。契
約者情報17000は、参加者ID5100の受取人
の、端末のID16710と前記受取人の振込口座41
20を関連づけるデータである。支払意図到着通知転送
処理16382は、検索した契約者情報17000の端
末ID16710に対して、受信した支払意図3100
の到着通知を転送する。
について述べる。支払意図到着通知転送処理16382
は、支払意図登録処理II16280より、支払意図31
00が到着した旨の通知受けると、受信した受取人ID
3160と同一の参加者ID5100を有する契約者情
報17000を契約者DB16310から検索する。契
約者DB16310の構造は、図17に示すように、契
約者情報17000が複数登録可能なテーブルである。
契約者情報17000は、参加者ID5100、端末I
D16710、振込口座4120の項目を有する。なお
振込口座4120については複数個存在してもよい。振
込口座4120には、例えば、受益人が過去に振込先と
して指定した振込口座や受益人が携帯電話会社へ携帯端
末の利用料金を支払う口座等を登録する。契約者情報1
7000の振込口座4120は、後述受益人携帯端末1
6700において振込先の口座を指定する処理におい
て、その振込先候補として列挙するのに用いられる。契
約者情報17000は、参加者ID5100の受取人
の、端末のID16710と前記受取人の振込口座41
20を関連づけるデータである。支払意図到着通知転送
処理16382は、検索した契約者情報17000の端
末ID16710に対して、受信した支払意図3100
の到着通知を転送する。
【0050】次に図19を用いて振込口座指定処理II1
6380について述べる。処理ステップ19010にお
いて、携帯電話会社システム16300は、入出力処理
16780から振込口座指定の開始要求を受ける。処理
ステップ19020において、携帯電話会社システム1
6300は、開始要求を送信した端末の端末ID167
10と一致する端末ID16710を有する契約者情報
17000を契約者DB16310から検索する。ここ
で受益人携帯端末16700から携帯電話会社システム
16380に送信するメッセージには、端末ID167
10が付与されており、送信元が判別できるものとす
る。また本処理において単に契約者情報17000と記
載した場合は、本処理ステップで検索した契約者情報1
7000を指すものとする。処理ステップ19030に
おいて、携帯電話会社システム16300は、図7に示
すログイン画面7100を作成し入出力処理16780
に送信し、表示するように要求する。ここで参加者ID
入力欄7110に、契約者情報17000の参加者ID
5100を挿入して送信しても良い。処理ステップ19
040において、携帯電話会社システム16300は、
入出力処理16780からパスワード5200を受信す
る。処理ステップ19050において、携帯電話会社シ
ステム16300は、検索した契約者情報17000の
参加者ID5100と受信したパスワード5200から
ログインデータ13100を作成し、振込口座登録処理
1282に送信し認証を要求する。携帯電話会社システ
ム16300は、ログインデータ13100の送信を、
図11に示す振込口座登録処理1282の処理ステップ
11020により実行する。決済仲介システム1300
は、認証結果を、処理ステップ11030あるいは処理
ステップ11110により返信する。処理ステップ19
060において、携帯電話会社システム16300は、
認証が成功したかを判断し、成功したと判断した場合は
処理ステップを19070に移し、成功してないと判断
した場合は振込口座指定処理II16380を終了する。
処理ステップ19070において、携帯電話会社システ
ム16300は、決済仲介システム1300(振込口座
登録処理1282)から支払意図3100を受信する。
携帯電話会社システム16300は、支払意図3100
の送信を、図11に示す振込口座登録処理1282の処
理ステップ11050により実行する。以後本処理の説
明において、単に支払意図3100と記した場合は、本
処理ステップで受信した支払意図3100を指すものと
する。処理ステップ19080において、携帯電話会社
システム16300は、受信した支払意図3100と契
約者情報17000に登録してある振込口座4120に
より、図18に示す振込口座指定画面II18100を作
成する。振込口座指定画面II18100は、振込口座指
定画面9100の内容に加えて、契約者情報17000
に登録してある振込口座4120と、さらにそれらの振
込口座4120と振込口座入力欄9120に対する選択
欄18110を含む。処理ステップ19090におい
て、携帯電話会社システム16300は、入出力処理1
6780に対して、振込口座指定画面II18100を送
信し表示するように要求する。処理ステップ19100
において、携帯電話会社システム16300は、入出力
処理16780から振込口座4120を受信する。処理
ステップ19110において、携帯電話会社システム1
6300は、振込口座指定データ4100を作成する。
振込口座指定データ4100の作成は、振込口座指定処
理1380の場合と同様に行う。但し本実施形態におい
ては、携帯電話会社が受益人に変わって署名を付与す
る。具体的には、携帯電話会社秘密鍵16610を用い
て受取人署名4130が付与される。また本実施形態に
おいては、参加者DB1210において取扱対象者ID
5150の値が支払意図3100の受益人ID3160
と同一の値をもつ参加者情報5000の公開鍵として、
携帯電話会社の公開鍵を登録しておく。これにより振込
口座登録処理1282において、携帯電話会社システム
16300が振込口座指定データ4100の受取人署名
4130を検証する際に、携帯電話会社秘密鍵1661
0によりなされた署名が正当のものと判断することがで
きる。なお受益人携帯端末16700に受益人秘密鍵1
610を記憶しておき、振込口座指定データ4100を
受益人携帯端末16700で作成し、受益人秘密鍵16
10で受取人署名4130を付与しても良い。処理ステ
ップ19120において、携帯電話会社システム163
00は、振込口座指定データ4100を振込口座登録処
理1282に送信して、登録が成功したかどうか返信を
受ける。携帯電話会社システム16300は、振込口座
指定データ4100の送信を、図11の振込口座登録処
理1282における処理ステップ11060により受信
する。携帯電話会社システム16300は、登録が成功
したかどうかの返信を、処理ステップ11100あるい
は処理ステップ11120によって実行する。処理ステ
ップ19130において、携帯電話会社システム163
00は、入出力処理16780に受信された返信内容を
送信し表示するように要求し、振込口座指定処理II16
380を終了する。
6380について述べる。処理ステップ19010にお
いて、携帯電話会社システム16300は、入出力処理
16780から振込口座指定の開始要求を受ける。処理
ステップ19020において、携帯電話会社システム1
6300は、開始要求を送信した端末の端末ID167
10と一致する端末ID16710を有する契約者情報
17000を契約者DB16310から検索する。ここ
で受益人携帯端末16700から携帯電話会社システム
16380に送信するメッセージには、端末ID167
10が付与されており、送信元が判別できるものとす
る。また本処理において単に契約者情報17000と記
載した場合は、本処理ステップで検索した契約者情報1
7000を指すものとする。処理ステップ19030に
おいて、携帯電話会社システム16300は、図7に示
すログイン画面7100を作成し入出力処理16780
に送信し、表示するように要求する。ここで参加者ID
入力欄7110に、契約者情報17000の参加者ID
5100を挿入して送信しても良い。処理ステップ19
040において、携帯電話会社システム16300は、
入出力処理16780からパスワード5200を受信す
る。処理ステップ19050において、携帯電話会社シ
ステム16300は、検索した契約者情報17000の
参加者ID5100と受信したパスワード5200から
ログインデータ13100を作成し、振込口座登録処理
1282に送信し認証を要求する。携帯電話会社システ
ム16300は、ログインデータ13100の送信を、
図11に示す振込口座登録処理1282の処理ステップ
11020により実行する。決済仲介システム1300
は、認証結果を、処理ステップ11030あるいは処理
ステップ11110により返信する。処理ステップ19
060において、携帯電話会社システム16300は、
認証が成功したかを判断し、成功したと判断した場合は
処理ステップを19070に移し、成功してないと判断
した場合は振込口座指定処理II16380を終了する。
処理ステップ19070において、携帯電話会社システ
ム16300は、決済仲介システム1300(振込口座
登録処理1282)から支払意図3100を受信する。
携帯電話会社システム16300は、支払意図3100
の送信を、図11に示す振込口座登録処理1282の処
理ステップ11050により実行する。以後本処理の説
明において、単に支払意図3100と記した場合は、本
処理ステップで受信した支払意図3100を指すものと
する。処理ステップ19080において、携帯電話会社
システム16300は、受信した支払意図3100と契
約者情報17000に登録してある振込口座4120に
より、図18に示す振込口座指定画面II18100を作
成する。振込口座指定画面II18100は、振込口座指
定画面9100の内容に加えて、契約者情報17000
に登録してある振込口座4120と、さらにそれらの振
込口座4120と振込口座入力欄9120に対する選択
欄18110を含む。処理ステップ19090におい
て、携帯電話会社システム16300は、入出力処理1
6780に対して、振込口座指定画面II18100を送
信し表示するように要求する。処理ステップ19100
において、携帯電話会社システム16300は、入出力
処理16780から振込口座4120を受信する。処理
ステップ19110において、携帯電話会社システム1
6300は、振込口座指定データ4100を作成する。
振込口座指定データ4100の作成は、振込口座指定処
理1380の場合と同様に行う。但し本実施形態におい
ては、携帯電話会社が受益人に変わって署名を付与す
る。具体的には、携帯電話会社秘密鍵16610を用い
て受取人署名4130が付与される。また本実施形態に
おいては、参加者DB1210において取扱対象者ID
5150の値が支払意図3100の受益人ID3160
と同一の値をもつ参加者情報5000の公開鍵として、
携帯電話会社の公開鍵を登録しておく。これにより振込
口座登録処理1282において、携帯電話会社システム
16300が振込口座指定データ4100の受取人署名
4130を検証する際に、携帯電話会社秘密鍵1661
0によりなされた署名が正当のものと判断することがで
きる。なお受益人携帯端末16700に受益人秘密鍵1
610を記憶しておき、振込口座指定データ4100を
受益人携帯端末16700で作成し、受益人秘密鍵16
10で受取人署名4130を付与しても良い。処理ステ
ップ19120において、携帯電話会社システム163
00は、振込口座指定データ4100を振込口座登録処
理1282に送信して、登録が成功したかどうか返信を
受ける。携帯電話会社システム16300は、振込口座
指定データ4100の送信を、図11の振込口座登録処
理1282における処理ステップ11060により受信
する。携帯電話会社システム16300は、登録が成功
したかどうかの返信を、処理ステップ11100あるい
は処理ステップ11120によって実行する。処理ステ
ップ19130において、携帯電話会社システム163
00は、入出力処理16780に受信された返信内容を
送信し表示するように要求し、振込口座指定処理II16
380を終了する。
【0051】次に入出力処理16780について述べ
る。まず受益人携帯端末16700は、受益人携帯端末
16700の入力装置2040により、振込口座指定処
理の開始要求を受け、それを振込口座指定処理II153
80に送信する。なお本処理の説明において、単に入力
装置2040あるいは出力装置2050と記載した場合
は受益人携帯端末16700の装置を指すこととする。
携帯電話会社システム16300は、振込口座指定処理
の開始要求の送信を、図19に示す振込口座指定処理II
16380の処理ステップ19010により受信する。
次に、受益人携帯端末16700は、振込口座指定処理
II16380から図7に示すログイン画面7100を受
信し、出力装置2050を用いて出力する。携帯電話会
社システム16300は、ログイン画面7100を、振
込口座指定処理II16380の処理ステップ19030
により送信する。次に受益人携帯端末16700は、入
力装置2040を用いて、パスワード入力欄7120の
入力を受ける。次に受益人携帯端末16700は、パス
ワード入力欄7120の値をパスワード5200として
振込口座指定処理II16380に送信する。携帯電話会
社システム16300は、送信されたパスワード520
0を、振込口座指定処理II16380の処理ステップ1
9019040により受信する。次に受益人携帯端末1
6700は、携帯電話会社システム16300(振込口
座指定処理II16380)から振込口座指定画面II18
100を受信し、出力装置2050を用いて表示する。
なお携帯電話会社システム16300は、振込口座指定
処理II16380は、振込口座指定画面II18100
を、振込口座指定処理II16380の処理ステップ19
090により送信する。次に受益人携帯端末16700
は、入力装置2040を用いて、選択欄18110のい
ずれかの選択を受ける。ここで受益人携帯端末1670
0は、振込口座4120に対応する選択欄18110が
選択された場合は、選択された選択欄18110に対応
する振込口座4120を振込口座指定処理II16380
の振込口座指定画面II18100に返信する。また受益
人携帯端末16700は、振込口座指定欄9120に対
応する選択欄18110が指定された場合は、入力装置
2040を用いて、振込口座入力欄9120への入力を
受けて、振込口座入力欄9120の内容を振込口座41
20として振込口座指定処理II16380の振込口座指
定画面II18100に返信する。携帯電話会社システム
16300は、振込口座指定画面II18100への返信
を、振込口座指定画面II18100の処理ステップ19
100により受信する。次に受益人携帯端末16700
は、登録が成功したかについて携帯電話会社システム1
6300の振込口座指定画面II18100から受信し、
出力装置2050を用いて出力し、入出力処理1678
0を終了する。携帯電話会社システム16300は、登
録が成功したかの情報は振込口座指定画面II18100
の処理ステップ19130にて送信する。
る。まず受益人携帯端末16700は、受益人携帯端末
16700の入力装置2040により、振込口座指定処
理の開始要求を受け、それを振込口座指定処理II153
80に送信する。なお本処理の説明において、単に入力
装置2040あるいは出力装置2050と記載した場合
は受益人携帯端末16700の装置を指すこととする。
携帯電話会社システム16300は、振込口座指定処理
の開始要求の送信を、図19に示す振込口座指定処理II
16380の処理ステップ19010により受信する。
次に、受益人携帯端末16700は、振込口座指定処理
II16380から図7に示すログイン画面7100を受
信し、出力装置2050を用いて出力する。携帯電話会
社システム16300は、ログイン画面7100を、振
込口座指定処理II16380の処理ステップ19030
により送信する。次に受益人携帯端末16700は、入
力装置2040を用いて、パスワード入力欄7120の
入力を受ける。次に受益人携帯端末16700は、パス
ワード入力欄7120の値をパスワード5200として
振込口座指定処理II16380に送信する。携帯電話会
社システム16300は、送信されたパスワード520
0を、振込口座指定処理II16380の処理ステップ1
9019040により受信する。次に受益人携帯端末1
6700は、携帯電話会社システム16300(振込口
座指定処理II16380)から振込口座指定画面II18
100を受信し、出力装置2050を用いて表示する。
なお携帯電話会社システム16300は、振込口座指定
処理II16380は、振込口座指定画面II18100
を、振込口座指定処理II16380の処理ステップ19
090により送信する。次に受益人携帯端末16700
は、入力装置2040を用いて、選択欄18110のい
ずれかの選択を受ける。ここで受益人携帯端末1670
0は、振込口座4120に対応する選択欄18110が
選択された場合は、選択された選択欄18110に対応
する振込口座4120を振込口座指定処理II16380
の振込口座指定画面II18100に返信する。また受益
人携帯端末16700は、振込口座指定欄9120に対
応する選択欄18110が指定された場合は、入力装置
2040を用いて、振込口座入力欄9120への入力を
受けて、振込口座入力欄9120の内容を振込口座41
20として振込口座指定処理II16380の振込口座指
定画面II18100に返信する。携帯電話会社システム
16300は、振込口座指定画面II18100への返信
を、振込口座指定画面II18100の処理ステップ19
100により受信する。次に受益人携帯端末16700
は、登録が成功したかについて携帯電話会社システム1
6300の振込口座指定画面II18100から受信し、
出力装置2050を用いて出力し、入出力処理1678
0を終了する。携帯電話会社システム16300は、登
録が成功したかの情報は振込口座指定画面II18100
の処理ステップ19130にて送信する。
【0052】第3の実施形態の例において、携帯電話会
社システム16380を双方向TVの情報提供会社のシ
ステムとしみなし、受益人携帯端末16700を双方向
TV及び操作端末(例えば、リモコン)とすることによ
り、双方向TVを用いて振込口座を指定しても良い。ま
た第3の実施形態の例において、携帯電話会社システム
16380をインターネット接続業者として、受益人携
帯端末16700をインターネット接続端末(例えば、
パーソナル・コンピュータ)とすることにより、インタ
ーネットを用いて振込口座を指定しても良い。
社システム16380を双方向TVの情報提供会社のシ
ステムとしみなし、受益人携帯端末16700を双方向
TV及び操作端末(例えば、リモコン)とすることによ
り、双方向TVを用いて振込口座を指定しても良い。ま
た第3の実施形態の例において、携帯電話会社システム
16380をインターネット接続業者として、受益人携
帯端末16700をインターネット接続端末(例えば、
パーソナル・コンピュータ)とすることにより、インタ
ーネットを用いて振込口座を指定しても良い。
【0053】次に、本発明の第4の実施形態について、
図20、21を用いて述べる。
図20、21を用いて述べる。
【0054】第4の実施形態のシステム構成は、第1の
実施形態のシステム構成と以下の点において異なる。ま
ずネットワーク1500に、受益人システム1300の
代わりに、ATM提供業者システム20300を接続す
る。ATM提供業者システム20300は、ATMを提
供する金融業者等のシステムである。決済仲介システム
1200には、支払意図登録通知処理1280の代わり
に、支払意図登録通知処理III20280を有する。A
TM提供業者システム20300のシステム構成は、図
2における保険庁システム1100のシステム構成と同
じである。通常は、ATM提供業者は、地理的に分散し
て配置されたATM端末と複数のATM端末からの入力
を統合するセンタを持つものと思われるが、本実施形態
ではATM端末とセンタの機能を一つにまとめ、簡略化
しATM提供業者システム20300とする。よって、
第4の実施形態は、ATM端末とセンタとが物理的に分
離したシステムにも適用可能である。ATM提供業者シ
ステム20300のバス2070は、契約者DBII20
310が接続され、ATM提供業者システム20300
の記憶装置2010が記憶する処理から契約者DBII2
0310の内容へのアクセスが可能である。ATM提供
業者システム20300の記憶装置2010は、振込口
座指定処理III20380、振込口座保存処理2038
2の処理、ATM提供業者ID20390、ATM提供
業者パスワード20392、およびATM提供業者秘密
鍵20320を記憶する。
実施形態のシステム構成と以下の点において異なる。ま
ずネットワーク1500に、受益人システム1300の
代わりに、ATM提供業者システム20300を接続す
る。ATM提供業者システム20300は、ATMを提
供する金融業者等のシステムである。決済仲介システム
1200には、支払意図登録通知処理1280の代わり
に、支払意図登録通知処理III20280を有する。A
TM提供業者システム20300のシステム構成は、図
2における保険庁システム1100のシステム構成と同
じである。通常は、ATM提供業者は、地理的に分散し
て配置されたATM端末と複数のATM端末からの入力
を統合するセンタを持つものと思われるが、本実施形態
ではATM端末とセンタの機能を一つにまとめ、簡略化
しATM提供業者システム20300とする。よって、
第4の実施形態は、ATM端末とセンタとが物理的に分
離したシステムにも適用可能である。ATM提供業者シ
ステム20300のバス2070は、契約者DBII20
310が接続され、ATM提供業者システム20300
の記憶装置2010が記憶する処理から契約者DBII2
0310の内容へのアクセスが可能である。ATM提供
業者システム20300の記憶装置2010は、振込口
座指定処理III20380、振込口座保存処理2038
2の処理、ATM提供業者ID20390、ATM提供
業者パスワード20392、およびATM提供業者秘密
鍵20320を記憶する。
【0055】次に同じく図20を用いて第4の実施形態
の処理概要について述べる。まずATM提供業者システ
ム20300は、受益人による受益人ICカード160
0の挿入を、ICカードR/W2060により受ける。
受益人ICカード1600の挿入を受けるとATM提供
業者システム20300は、振込口座保存処理2038
2を起動し、受益人の認証を行い振込口座4120の入
力を受け、それを契約者DBII20310に保存する。
一方、保険庁システム1100の支払意図登録処理11
80は、決済仲介システム1200の支払意図登録通知
処理II16280に、支払意図3100を登録する。こ
のメッセージフローは、支払意図の登録1810であ
る。次に支払意図登録通知処理III20380は、振込
口座指定処理III20380に対して、支払意図が到着
した旨を通知する。このメッセージフローが支払意図到
着通知1820である。振込口座指定処理III2038
0は、到着通知を受信すると、契約者DBII20310
に格納した振込口座4120から振込口座指定データを
作成し、振込口座登録処理1282へ送信する。このメ
ッセージフローが振込口座の指定1800である。以後
の処理は第1の実施形態と同様である。以下第1の実施
形態と異なる処理について述べる。
の処理概要について述べる。まずATM提供業者システ
ム20300は、受益人による受益人ICカード160
0の挿入を、ICカードR/W2060により受ける。
受益人ICカード1600の挿入を受けるとATM提供
業者システム20300は、振込口座保存処理2038
2を起動し、受益人の認証を行い振込口座4120の入
力を受け、それを契約者DBII20310に保存する。
一方、保険庁システム1100の支払意図登録処理11
80は、決済仲介システム1200の支払意図登録通知
処理II16280に、支払意図3100を登録する。こ
のメッセージフローは、支払意図の登録1810であ
る。次に支払意図登録通知処理III20380は、振込
口座指定処理III20380に対して、支払意図が到着
した旨を通知する。このメッセージフローが支払意図到
着通知1820である。振込口座指定処理III2038
0は、到着通知を受信すると、契約者DBII20310
に格納した振込口座4120から振込口座指定データを
作成し、振込口座登録処理1282へ送信する。このメ
ッセージフローが振込口座の指定1800である。以後
の処理は第1の実施形態と同様である。以下第1の実施
形態と異なる処理について述べる。
【0056】振込口座保存処理20382について述べ
る。最初にATM提供業者システム20300は、受益
人ICカードから参加者ID5100を読み取る。次に
ATM提供業者システム20300は、入力装置204
0を用いてパスワード5200の入力を受ける。次にA
TM提供業者システム20300は、読み取った参加者
ID5100と同一の値を有する契約者情報II2100
0を、契約者DBII20310から検索する。契約者D
BII20310は、契約者情報II21000を複数登録
可能なテーブルである。契約者情報II21000は、参
加者ID5100、パスワード5200、振込口座41
20の項目を有する。以後本処理の説明において契約者
情報II21000と記載した場合は、検索した契約者情
報II21000を指すものとする。次にATM提供業者
システム20300は、入力をうけたパスワード520
0と契約者情報II21000のパスワード5200が一
致するかを調べる。ATM提供業者システム20300
は、一致しない場合は振込口座登録処理20382を終
了する。次にATM提供業者システム20300は、入
力装置2040を用いて、振込口座4120の入力を受
ける。最後にATM提供業者システム20300は、入
力を受けた振込口座4120を契約者情報II2100
0の振込口座4120に記憶し、振込口座保存処理20
382を終了する。
る。最初にATM提供業者システム20300は、受益
人ICカードから参加者ID5100を読み取る。次に
ATM提供業者システム20300は、入力装置204
0を用いてパスワード5200の入力を受ける。次にA
TM提供業者システム20300は、読み取った参加者
ID5100と同一の値を有する契約者情報II2100
0を、契約者DBII20310から検索する。契約者D
BII20310は、契約者情報II21000を複数登録
可能なテーブルである。契約者情報II21000は、参
加者ID5100、パスワード5200、振込口座41
20の項目を有する。以後本処理の説明において契約者
情報II21000と記載した場合は、検索した契約者情
報II21000を指すものとする。次にATM提供業者
システム20300は、入力をうけたパスワード520
0と契約者情報II21000のパスワード5200が一
致するかを調べる。ATM提供業者システム20300
は、一致しない場合は振込口座登録処理20382を終
了する。次にATM提供業者システム20300は、入
力装置2040を用いて、振込口座4120の入力を受
ける。最後にATM提供業者システム20300は、入
力を受けた振込口座4120を契約者情報II2100
0の振込口座4120に記憶し、振込口座保存処理20
382を終了する。
【0057】次に支払意図登録処理III20280につ
いて述べる。支払意図登録処理III20280と支払意
図登録処理1280との違いは、支払意図登録処理III
20280は、図10に示す支払意図登録処理1280
の処理ステップ10080において、支払意図3100
が到着した旨の通知先が振込口座指定処理III2038
0になること、及び支払意図3100が到着した旨の通
知と共に支払意図3100内の受取人ID3160を送
信する点である。また参加者DB1210内の取扱対象
者ID5150が支払意図3100内の受取人ID31
60と同一の値を持つ参加者情報5000の連絡先54
00には、ATM提供業者システム20300を含む。
いて述べる。支払意図登録処理III20280と支払意
図登録処理1280との違いは、支払意図登録処理III
20280は、図10に示す支払意図登録処理1280
の処理ステップ10080において、支払意図3100
が到着した旨の通知先が振込口座指定処理III2038
0になること、及び支払意図3100が到着した旨の通
知と共に支払意図3100内の受取人ID3160を送
信する点である。また参加者DB1210内の取扱対象
者ID5150が支払意図3100内の受取人ID31
60と同一の値を持つ参加者情報5000の連絡先54
00には、ATM提供業者システム20300を含む。
【0058】次に振込口座指定処理III20380につ
いて述べる。最初にATM提供業者システム20300
は、支払意図登録処理III20280から支払意図の到
着通知と受取人ID3160を受信する。次にATM提
供業者システム20300は、受取人ID3160と一
致する参加者ID5100を有する契約者情報II210
00を、契約者DBII20310から検索する。以後本
処理の説明において、単に契約者情報II21000と記
載した場合は、検索した契約者情報II21000を指す
ものとする。次にATM提供業者システム20300
は、ATM提供業者ID20390とATM提供業者パ
スワード20392から、ログインデータ13100を
作成し、振込込口座登録処理1282に送信して認証要
求を受ける。以下、振込口座指定処理III20380の
うち、支払意図3100を受信するまでの処理は、振込
口座指定処理1380と同じである。次にATM提供業
者システム20300は、振込口座指定データ4100
を作成する。振込口座指定データ4100の作成は、受
信した支払意図3100のハッシュ値を計算し、それを
支払意図のハッシュ値4110とし、契約者情報II21
000の振込口座4120を振込口座指定データ410
0の振込口座4120とし、ATM提供業者秘密鍵20
320により、受取人署名4130を付与して作成す
る。振込口座指定データ4100の作成方法の詳細は第
1の実施形態の場合と同様である。また第4の実施形態
においても、第3の実施形態の場合と同様に、受益人に
変わってATM提供会社が署名を付与するものとする。
したがって参加者DB1210内の取扱対象者ID51
50が支払意図3100内の受取人ID3160と同一
の値を持つ参加者情報5000のの公開鍵5300に
は、ATM提供業者秘密鍵20320に対応する公開鍵
が登録される。次にATM提供業者システム20300
は、作成した振込口座指定データ4100を振込口座登
録処理1282に送信し、登録が成功したかの返信を受
けて振込口座指定処理III20380を終了する。
いて述べる。最初にATM提供業者システム20300
は、支払意図登録処理III20280から支払意図の到
着通知と受取人ID3160を受信する。次にATM提
供業者システム20300は、受取人ID3160と一
致する参加者ID5100を有する契約者情報II210
00を、契約者DBII20310から検索する。以後本
処理の説明において、単に契約者情報II21000と記
載した場合は、検索した契約者情報II21000を指す
ものとする。次にATM提供業者システム20300
は、ATM提供業者ID20390とATM提供業者パ
スワード20392から、ログインデータ13100を
作成し、振込込口座登録処理1282に送信して認証要
求を受ける。以下、振込口座指定処理III20380の
うち、支払意図3100を受信するまでの処理は、振込
口座指定処理1380と同じである。次にATM提供業
者システム20300は、振込口座指定データ4100
を作成する。振込口座指定データ4100の作成は、受
信した支払意図3100のハッシュ値を計算し、それを
支払意図のハッシュ値4110とし、契約者情報II21
000の振込口座4120を振込口座指定データ410
0の振込口座4120とし、ATM提供業者秘密鍵20
320により、受取人署名4130を付与して作成す
る。振込口座指定データ4100の作成方法の詳細は第
1の実施形態の場合と同様である。また第4の実施形態
においても、第3の実施形態の場合と同様に、受益人に
変わってATM提供会社が署名を付与するものとする。
したがって参加者DB1210内の取扱対象者ID51
50が支払意図3100内の受取人ID3160と同一
の値を持つ参加者情報5000のの公開鍵5300に
は、ATM提供業者秘密鍵20320に対応する公開鍵
が登録される。次にATM提供業者システム20300
は、作成した振込口座指定データ4100を振込口座登
録処理1282に送信し、登録が成功したかの返信を受
けて振込口座指定処理III20380を終了する。
【0059】第4の実施形態では、受益人がATM提供
業者システム20300に振込口座を登録しておけば、
ATM提供業者システム20300が振込口座の指定1
830を受信した場合に、自動的に支払意図通知システ
ム1200へ振込口座の指定1830を送信する。よっ
て、受益人は、決済毎に、支払意図通知システム120
0へ振込口座の指定1830を送信する手間が省けると
効果を有する。よって、ATM提供業者は、受益人から
決済の仲介を委託された者、即ち、被決済仲介者といえ
る。よって、ATM提供業者システム20300は、電
子決済を仲介する被電子決済仲介システムといえる。
業者システム20300に振込口座を登録しておけば、
ATM提供業者システム20300が振込口座の指定1
830を受信した場合に、自動的に支払意図通知システ
ム1200へ振込口座の指定1830を送信する。よっ
て、受益人は、決済毎に、支払意図通知システム120
0へ振込口座の指定1830を送信する手間が省けると
効果を有する。よって、ATM提供業者は、受益人から
決済の仲介を委託された者、即ち、被決済仲介者といえ
る。よって、ATM提供業者システム20300は、電
子決済を仲介する被電子決済仲介システムといえる。
【0060】本発明の第1〜第4の実施形態は、「個別
請求不要決済」(包括的な契約に基づき継続的に支払が
行われる決済方法)に適用するのが好ましい。支払人が
受取人に対し、予め支払人が受取人に対し定期に又は不
定期に金銭を支払う旨の契約を行う。そして、支払人
は、支払日前に、直接的に、又は支払意図通知人を介し
て間接的に、受取人へ支払意図を通知する。支払人は、
支払意図通知人に振込口座を指定した受取人に対しての
み、支払意図通知人を介して金銭を支払う。金銭の代わ
りに、商品やサービスを対象としてもよい。契約書がな
い場合にも、支払人と受取人との間で、口頭又は黙示的
に契約がなされる場合もあり得る。
請求不要決済」(包括的な契約に基づき継続的に支払が
行われる決済方法)に適用するのが好ましい。支払人が
受取人に対し、予め支払人が受取人に対し定期に又は不
定期に金銭を支払う旨の契約を行う。そして、支払人
は、支払日前に、直接的に、又は支払意図通知人を介し
て間接的に、受取人へ支払意図を通知する。支払人は、
支払意図通知人に振込口座を指定した受取人に対しての
み、支払意図通知人を介して金銭を支払う。金銭の代わ
りに、商品やサービスを対象としてもよい。契約書がな
い場合にも、支払人と受取人との間で、口頭又は黙示的
に契約がなされる場合もあり得る。
【0061】包括的な契約の内容は、例えば、「支払人
は毎月1日に受取人に対し金銭を支払う。」、「支払人
は4月1日から7月31日までの間に受取人に対し分割
して金銭を支払う。」等である。さらに、包括的な契約
の内容として、「支払日から5日の間に振込口座を通知
した場合に金銭を支払う。」、「支払人は受取人に対し
金銭の支払意図を通知したときに支払義務を履行したこ
ととする。」、「支払人は決済仲介人に対し金銭の支払
意図を通知したときに支払義務を履行したこととす
る。」等を加えてもよい。
は毎月1日に受取人に対し金銭を支払う。」、「支払人
は4月1日から7月31日までの間に受取人に対し分割
して金銭を支払う。」等である。さらに、包括的な契約
の内容として、「支払日から5日の間に振込口座を通知
した場合に金銭を支払う。」、「支払人は受取人に対し
金銭の支払意図を通知したときに支払義務を履行したこ
ととする。」、「支払人は決済仲介人に対し金銭の支払
意図を通知したときに支払義務を履行したこととす
る。」等を加えてもよい。
【0062】本発明の第1〜第4の実施形態は、新規な
決済モデルを、コンピュータやインターネット等を用い
て実現するものである。本発明の第1〜第4の実施形態
は、支払人が受取人に対して金銭を支払う意志があるこ
とを示すデータである支払意図を掲示する場(決済仲介
システム1200)を提供する。そして、支払人は、支
払意図を場(決済仲介システム1200)に登録するこ
とにより、支払義務を履行する。後は受取人が決済仲介
システムにアクセスし金銭の受け取る。本決済モデルに
より、支払人は受取人の口座の変更による振込の失敗を
意識する必要がなくなる。尚、支払意図とは、データの
持つ意味においては電子小切手と等価であるが、その使
用方法が異なるので、本発明の第1〜第4の実施形態に
おける支払意図から除外する。また本決済モデルは、こ
れまで支払人が行った事務コストを受取人へ移管するも
のとも考えられるが、本来決済が失敗した場合には金銭
を支払う支払者よりも金銭を受取る受取人の方がその決
済を完了したいという要求が高いのが一般的であり、ま
た受取人側の振込口座や連絡先の変更により生じる決済
の失敗のリスクやその解決のコストを受益人が負うべき
であるとするならば、前記前提にしたがい支払人と受取
人の役割分担が行える決済モデルである。これにより、
例えば、受取人の事情により金銭が受取人に受け取られ
なかった場合にも、支払人が受取人を探索するという手
間が省ける。
決済モデルを、コンピュータやインターネット等を用い
て実現するものである。本発明の第1〜第4の実施形態
は、支払人が受取人に対して金銭を支払う意志があるこ
とを示すデータである支払意図を掲示する場(決済仲介
システム1200)を提供する。そして、支払人は、支
払意図を場(決済仲介システム1200)に登録するこ
とにより、支払義務を履行する。後は受取人が決済仲介
システムにアクセスし金銭の受け取る。本決済モデルに
より、支払人は受取人の口座の変更による振込の失敗を
意識する必要がなくなる。尚、支払意図とは、データの
持つ意味においては電子小切手と等価であるが、その使
用方法が異なるので、本発明の第1〜第4の実施形態に
おける支払意図から除外する。また本決済モデルは、こ
れまで支払人が行った事務コストを受取人へ移管するも
のとも考えられるが、本来決済が失敗した場合には金銭
を支払う支払者よりも金銭を受取る受取人の方がその決
済を完了したいという要求が高いのが一般的であり、ま
た受取人側の振込口座や連絡先の変更により生じる決済
の失敗のリスクやその解決のコストを受益人が負うべき
であるとするならば、前記前提にしたがい支払人と受取
人の役割分担が行える決済モデルである。これにより、
例えば、受取人の事情により金銭が受取人に受け取られ
なかった場合にも、支払人が受取人を探索するという手
間が省ける。
【0063】従って、本発明の第1〜第4の実施形態に
よれば、一般に決済完了要求が高く、代金の受渡し方法
を決定する債権者が、債務者に代わり決済失敗時のリス
クやその解決のコストを負う決済モデルが実現される。
よれば、一般に決済完了要求が高く、代金の受渡し方法
を決定する債権者が、債務者に代わり決済失敗時のリス
クやその解決のコストを負う決済モデルが実現される。
【0064】本発明の第1〜第4の実施形態では、支払
ごとに決済仲介システムが受益人から振込口座の指定を
受けるまで、金銭が移動せず、決済仲介システムが金銭
の振込みを行わないことから、受益人が金銭を受け取り
にこない場合にも、払い戻し等の処理手続きの負担が軽
減される。
ごとに決済仲介システムが受益人から振込口座の指定を
受けるまで、金銭が移動せず、決済仲介システムが金銭
の振込みを行わないことから、受益人が金銭を受け取り
にこない場合にも、払い戻し等の処理手続きの負担が軽
減される。
【0065】本発明の第1〜第4の実施形態の各処理を
各システムに実行させるためのプログラムは、記憶媒体
(例えば、フロッピー(登録商標)ディスク、ハードデ
ィスク、メモリーカード、メモリースティック、MO、P
D、CD-ROM、CD-R/RW、DVD−ROM、DVD−RAM、サーバ)
に記憶されてもよい。各処理を各システムに実行させる
ためのプログラムを記憶するサーバは、インターネット
を通じて、各処理を各システムに実行させるためのプロ
グラムを配信してもよい。
各システムに実行させるためのプログラムは、記憶媒体
(例えば、フロッピー(登録商標)ディスク、ハードデ
ィスク、メモリーカード、メモリースティック、MO、P
D、CD-ROM、CD-R/RW、DVD−ROM、DVD−RAM、サーバ)
に記憶されてもよい。各処理を各システムに実行させる
ためのプログラムを記憶するサーバは、インターネット
を通じて、各処理を各システムに実行させるためのプロ
グラムを配信してもよい。
【0066】
【発明の効果】本発明によれば、決済毎に振込口座の指
定を受けた場合に限り又は決済毎に支払期限又は支払期
間内に振込口座の指定を受けた場合に金銭を支払うた
め、受取人の振込口座が変更又は喪失した場合に決済の
失敗を防止でき、支払人の決済手続きの負担を軽減する
ことができるという効果を有する。
定を受けた場合に限り又は決済毎に支払期限又は支払期
間内に振込口座の指定を受けた場合に金銭を支払うた
め、受取人の振込口座が変更又は喪失した場合に決済の
失敗を防止でき、支払人の決済手続きの負担を軽減する
ことができるという効果を有する。
【0067】本発明によれば、被決済仲介人が支払意図
の通知を受けた場合に自動的に振込口座の通知を行うた
め、受取人の被決済手続きの負担を軽減することができ
るという効果を有する。
の通知を受けた場合に自動的に振込口座の通知を行うた
め、受取人の被決済手続きの負担を軽減することができ
るという効果を有する。
【図1】本発明の第1の実施形態におけるシステム全体
のシステム構成図
のシステム構成図
【図2】本発明の第1の実施形態における各システムの
システム構成図
システム構成図
【図3】本発明の第1の実施形態における支払意図のデ
ータ構造図
ータ構造図
【図4】本発明の第1の実施形態における振込口座指定
データのデータ構成図
データのデータ構成図
【図5】本発明の第1の実施形態における参加者DBの
のデータ構造図
のデータ構造図
【図6】本発明の第1の実施形態における支払意図DB
のデータ構造図
のデータ構造図
【図7】本発明の第1の実施形態におけるログイン画面
のイメージ図
のイメージ図
【図8】本発明の第1の実施形態における支払意図入力
画面のイメージ図
画面のイメージ図
【図9】本発明の第1の実施形態における振込口座指定
画面のイメージ図
画面のイメージ図
【図10】本発明の第1の実施形態における支払意図登
録通知処理のフロー図
録通知処理のフロー図
【図11】本発明の第1の実施形態における振込口座登
録処理のフロー図
録処理のフロー図
【図12】本発明の第1の実施形態における定期処理の
フロー図
フロー図
【図13】本発明の第1の実施形態におけるログインデ
ータのデータ構造図
ータのデータ構造図
【図14】本発明の第2の実施形態におけるシステム全
体のシステム構成図
体のシステム構成図
【図15】本発明の第2の実施形態における定期処理II
のフロー図
のフロー図
【図16】本発明の第3の実施形態におけるシステム全
体のシステム構成図
体のシステム構成図
【図17】本発明の第3の実施形態における契約者DB
のデータ構造図
のデータ構造図
【図18】本発明の第3の実施形態における振込口座指
定画面IIのイメージ図
定画面IIのイメージ図
【図19】本発明の第3の実施形態における振込口座指
定処理IIのフロー図
定処理IIのフロー図
【図20】本発明の第4の実施形態におけるシステム全
体のシステム構成図
体のシステム構成図
【図21】本発明の第4の実施形態における契約者DB
IIのデータ構造図
IIのデータ構造図
1100…保険庁システム、1110…支払意図DB,
1180…支払意図作成処理、1200…決済仲介シス
テム、1210…参加者DB、1220…支払意図D
B、1280…支払意図登録通知処理、1282…振込
口座登録処理、1284…定期処理、1300…受益人
システム、1380…振込口座指定処理、1400…金
融システム、1480…振込処理、1500…ネットワ
ーク、1510…保険庁秘密鍵、1600…ICカー
ド、1610…受益人秘密鍵、2010…記憶装置、2
020…通信装置、2030…処理装置、2040…入
力装置、2050…出力装置、2060…ICカードR
/W、2070…バス、3100…支払意図、3110
…支払人ID、3120…支払額、3130…支払日、
3140…支払期限、3150…支払口座、3160…
受取人ID、3170…支払人署名、4100…振込口
座指定データ、4110…支払意図のハッシュ値、41
20…振込口座、4130…受取人署名、5000…参
加者情報、5100…参加者ID、5150…取扱対象
者ID、5200…パスワード、5300…公開鍵、5
400…連絡先、6000…支払意図情報、6100…
状態、7100…ログイン画面、7110…参加者ID
入力欄、7120…パスワード入力欄、7130…ログ
インボタン、8105…支払人ID入力欄、8110…
支払額入力欄、8120…支払日入力欄、8130…支
払期限入力欄、8140…支払口座入力欄、8150…
受取人入力欄、8160…登録ボタン、9100…振込
口座指定画面、9110…支払人表示欄、9120…振
込口座入力欄、8130…登録ボタン、10010〜1
0110、11010〜11120、12010〜12
080…処理ステップ、13100…ログインデータ、
14100…支払意図送信処理、14200…支払意図
要求処理、14300…振込要求処理、14400…振
込処理II、15010〜15130…処理ステップ、1
6280…支払意図登録通知処理II、16300…携帯
電話会社システム、16310…契約者DB、1638
0…振込口座指定処理II、16382…支払意図到着通
知転送処理、16390…携帯電話会社ID、1639
2…携帯電話会社パスワード、16610…携帯電話会
社秘密鍵、16700…受益人携帯端末、16710…
端末ID、16780…入出力処理、16800…回線
網、17000…契約者情報、18100…振込口座指
定画面II、18110…選択欄、19010〜1913
0…処理ステップ、20280…支払意図登録通知処理
III、20300…ATM提供業者システム、2031
0…契約者DB、20320…ATM提供業者秘密鍵、
20380…振込口座指定処理III、20382…振込
口座保存処理、20390…ATM提供業者ID、20
392…ATM提供業者パスワード、21000…契約
者情報II。
1180…支払意図作成処理、1200…決済仲介シス
テム、1210…参加者DB、1220…支払意図D
B、1280…支払意図登録通知処理、1282…振込
口座登録処理、1284…定期処理、1300…受益人
システム、1380…振込口座指定処理、1400…金
融システム、1480…振込処理、1500…ネットワ
ーク、1510…保険庁秘密鍵、1600…ICカー
ド、1610…受益人秘密鍵、2010…記憶装置、2
020…通信装置、2030…処理装置、2040…入
力装置、2050…出力装置、2060…ICカードR
/W、2070…バス、3100…支払意図、3110
…支払人ID、3120…支払額、3130…支払日、
3140…支払期限、3150…支払口座、3160…
受取人ID、3170…支払人署名、4100…振込口
座指定データ、4110…支払意図のハッシュ値、41
20…振込口座、4130…受取人署名、5000…参
加者情報、5100…参加者ID、5150…取扱対象
者ID、5200…パスワード、5300…公開鍵、5
400…連絡先、6000…支払意図情報、6100…
状態、7100…ログイン画面、7110…参加者ID
入力欄、7120…パスワード入力欄、7130…ログ
インボタン、8105…支払人ID入力欄、8110…
支払額入力欄、8120…支払日入力欄、8130…支
払期限入力欄、8140…支払口座入力欄、8150…
受取人入力欄、8160…登録ボタン、9100…振込
口座指定画面、9110…支払人表示欄、9120…振
込口座入力欄、8130…登録ボタン、10010〜1
0110、11010〜11120、12010〜12
080…処理ステップ、13100…ログインデータ、
14100…支払意図送信処理、14200…支払意図
要求処理、14300…振込要求処理、14400…振
込処理II、15010〜15130…処理ステップ、1
6280…支払意図登録通知処理II、16300…携帯
電話会社システム、16310…契約者DB、1638
0…振込口座指定処理II、16382…支払意図到着通
知転送処理、16390…携帯電話会社ID、1639
2…携帯電話会社パスワード、16610…携帯電話会
社秘密鍵、16700…受益人携帯端末、16710…
端末ID、16780…入出力処理、16800…回線
網、17000…契約者情報、18100…振込口座指
定画面II、18110…選択欄、19010〜1913
0…処理ステップ、20280…支払意図登録通知処理
III、20300…ATM提供業者システム、2031
0…契約者DB、20320…ATM提供業者秘密鍵、
20380…振込口座指定処理III、20382…振込
口座保存処理、20390…ATM提供業者ID、20
392…ATM提供業者パスワード、21000…契約
者情報II。
───────────────────────────────────────────────────── フロントページの続き (72)発明者 佐々木 良一 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 松木 武 神奈川県川崎市幸区鹿島田890番地 株式 会社日立製作所情報サービス事業部内 (72)発明者 竹内 國人 神奈川県川崎市幸区鹿島田890番地 株式 会社日立製作所金融システム事業部内 (72)発明者 酒井 瑞洋 神奈川県川崎市幸区鹿島田890番地 株式 会社日立製作所金融システム事業部内 (72)発明者 岩村 充 東京都練馬区中村2−14−17 Fターム(参考) 5B035 BB09 BC00 BC01 5B049 BB46 CC36 GG02 5B055 CB00 CB09
Claims (32)
- 【請求項1】電子データの送受信を利用した電子決済を
仲介する電子決済仲介方法において、 金銭の支払人の支払人システムから金銭の支払意図に間
する電子データを受信した場合に金銭の受取人の受取人
システムへ前記支払意図に関する電子データを送信し、 支払義務の発生毎に前記支払意図に間する電子データか
ら特定される支払期限又は支払期間内に前記受取人シス
テムから振込口座に関する電子データを受信した場合に
前記支払人が保有する財貨の中から前記指定口座へ金銭
を移動させる電子決済仲介方法。 - 【請求項2】コンピュータを用いて電子決済の仲介処理
を行う電子決済仲介方法において、 金銭の支払人から金銭の支払意図の通知を受けた場合
に、前記支払人が指定する受取人へ前記支払意図を送信
し、 前記決済毎に前記受取人からの振込口座の指定を受けた
場合に、前記支払人が指定する額の金銭を前記振込口座
に振り込む電子決済仲介方法。 - 【請求項3】ネットワーク又は放送電波を利用して電子
決済を行う電子決済方法において、 金銭の支払人から金銭の支払意図に関する電子データを
受けた場合に金銭の支払人が指定する受取人へ前記支払
意図に関する電子データを送信すると共に前記支払人が
指定する支払期限又は支払期間内に前記受取人から振込
口座の指定を受けた場合に前記振込口座に金銭を振り込
む決済仲介人に対し、前記支払義務の発生毎に前記支払
意図をネットワーク又は放送電波を介して送信したこと
をもって前記支払義務を履行する電子決済方法。 - 【請求項4】コンピュータを用いて電子決済を行う電子
決済方法において、 金銭の受取人又は決済仲介人に金銭の支払意図を通知
し、 決済毎に、前記受取人から振込口座の指定を直接的に又
は前記決済仲介人により間接的に受けた場合に、前記振
込口座に直接的に又は前記決済仲介人により間接的に金
銭を振り込む電子決済方法。 - 【請求項5】コンピュータを用いて電子決済を行う電子
決済方法において、 決済毎に、金銭の受取人へ直接的に又は決済仲介人を介
して間接的に、金銭の受け取りの際に受取人の正当性を
検証するための支払意図に関する電子データを送信し、 指定された支払期間又は支払期限までの間に前記受取人
から振込口座の指定を直接的に受けた場合又は前記決済
仲介人が受けた場合又は金融機関が受けた場合に、前記
振込口座に金銭を振り込む電子決済方法。 - 【請求項6】ネットワーク又は放送電波を利用して電子
決済を受ける被電子決済方法において、 金銭の支払人から金銭の支払意図を受けた場合に金銭の
受取人に前記支払意図を送信する決済仲介人からネット
ワーク又は放送電波を介して前記支払意図に関する電子
データを受信し、 今回の決済時に通知する振込口座が過去の決済時に通知
した振込口座と同一である場合にも、ネットワークを介
して前記振込口座に関する電子データを前記決済仲介人
又は金融機関へ送信した場合に、前記振込口座に金銭の
振り込みを受けることができる被電子決済方法。 - 【請求項7】コンピュータを用いて電子決済に関する仲
介処理を行う電子決済仲介システムにおいて、 前記仲介処理は、 金銭の支払人の支払人システムから、金銭の支払意図に
間する電子データを受信する支払意図登録通知処理部
と、 金銭の受取人の受取人システムへ前記支払意図に関する
電子データを送信し、前記受取人システムから振込口座
指定に関する電子データを受信する振込口座登録処理部
と、 前記支払意図に関する電子データから特定される支払期
限又は支払期間内に受信された振込口座指定に関する電
子データを特定し、前記支払人が保有する財貨の中から
特定された振込口座へ金銭を移動させる定期処理部とを
備えた電子決済仲介システム。 - 【請求項8】前記振込口座指定に間する電子データの受
信を受けて、前記振込口座指定に間する電子データから
特定された受取人の振込口座の有無を確認するための電
子データを、金融機関の金融機関システムへ送信する振
込口座確認処理部を備えた請求項7に記載の電子決済仲
介システム。 - 【請求項9】前記定期処理部は、前記振込口座が存在す
る旨の電子データを前記金融機関システムから受信され
たことを受けて、処理を開始する請求項8に記載の電子
決済仲介システム。 - 【請求項10】前記支払意図に関する電子データは、支
払額、支払日、支払期限、支払期間、支払人を特定する
ための支払人ID、受取人を特定するための受取人ID
のうち少なくとも1つを含む請求項7に記載の電子決済
仲介システム。 - 【請求項11】前記支払意図に関する電子データは、前
記支払意図に関する電子データに含まれる支払額、支払
日、支払期限、支払期間、支払人を特定するための支払
人ID、受取人を特定するための受取人IDのうち少な
くとも1つのビット列のハッシュ値を支払人の秘密鍵を
用いて暗号化された支払人署名を含む請求項10に記載
の電子決済仲介システム。 - 【請求項12】前記振込口座登録処理部は、前記支払意
図に関する電子データに含まれる支払額、支払日、支払
期限、支払期間、支払人を特定するための支払人ID、
受取人を特定するための受取人IDのうち少なくとも1
つのビット列のハッシュ値を計算すると共に前記支払人
署名を公開鍵を用いて復号化し、前記ハッシュ値と前記
復号化された支払人署名とを比較し一致することを判断
する請求項11に記載の電子決済仲介システム。 - 【請求項13】前記振込口座指定に間する電子データ
は、前記支払意図に関する電子データのハッシュ値を含
む請求項7に記載の電子決済仲介システム。 - 【請求項14】前記支払意図登録通知処理部は、前記支
払意図データベースに前記支払意図に間する電子データ
を登録し、 前記振込口座登録処理部は、前記支払意図データベース
に登録された前記支払意図に間する電子データのハッシ
ュ値と、前記振込口座指定に間する電子データに含まれ
る前記支払意図のハッシュ値とを比較する請求項13に
記載の電子決済仲介システム。 - 【請求項15】前記振込口座指定に関する電子データ
は、前記支払意図のハッシュ値と前記振込口座とに対す
る署名値が秘密鍵を用いて暗号化された受取人署名を含
む請求項13に記載の電子決済仲介システム。 - 【請求項16】前記振込口座登録処理部は、前記受取人
署名を公開鍵を用いて復号化し、復号化された受取人署
名と、前記振込口座指定に関する電子データに含まれる
前記支払意図のハッシュ値と振込口座とに対する署名値
とを比較し一致することを判断する請求項15に記載の
電子決済仲介システム。 - 【請求項17】前記定期処理部は、金融機関が管理又は
所有する金融システムに対し、前記支払人が保有する財
貨の中から前記振込口座へ振り込みを要求する請求項7
に記載の電子決済仲介システム。 - 【請求項18】前記支払意図登録通知処理部は、前記受
取人システムへ前記支払意図が到着した旨を送信する請
求項7に記載の電子決済仲介システム。 - 【請求項19】前記受取人システムは、前記支払意図に
関する電子データを前記受取人を認証するためのICカ
ードへ記録し、前期振込口座を送信した後に又は前記I
Cカードが当該受取人システムから取り出される前に前
記ICカード内の前記支払意図に関する電子データを削
除する請求項7に記載の電子決済仲介システム。 - 【請求項20】コンピュータを用いて電子決済に関する
仲介処理を行う電子決済仲介システムにおいて、 前記仲介処理は、 金銭の支払人の支払人システムから、金銭の支払意図に
間する電子データを受信する支払意図登録通知処理部
と、 金銭の受取人の受取人システムへ前記支払意図に関する
電子データを送信し、前記受取人システムから振込口座
指定に関する電子データを受信し、金銭が未払いである
旨の支払状態と前記振込口座とをデータベースに登録す
る振込口座登録処理部と、 前記データベースから前記金銭が未払いである旨の支払
状態に対応する振込口座を検索し、前記支払人が保有す
る財貨の中から前記振込口座へ金銭を移動させる定期処
理部とを備えた電子決済仲介システム。 - 【請求項21】前記定期処理部は、前記支払人が保有す
る財貨の中から前記振込口座へ金銭を移動させた場合
に、前記支払状態を支払済みである旨へ変更する請求項
7に記載の電子決済仲介システム。 - 【請求項22】前記定期処理部は、前記支払期限又は支
払期間内に前記振込口座指定に関する電子データの受信
がない場合に、前記支払状態を失効済みである旨へ変更
する請求項20に記載の電子決済仲介システム。 - 【請求項23】電子決済に関する決済処理をコンピュー
タによって実行する電子決済システムにおいて、 前記決済処理は、 受取人を特定するための受取人IDと支払額と支払期限
又は支払期間とを含む支払意図に関する電子データを作
成する作成処理部と、 前記支払意図に間する電子データを受信した場合に金銭
の受取人に前記支払意図に関する電子データを通知する
と共に前記支払期限又は支払期間内に前記受取人から振
込口座の指定を受けた場合に前記振込口座に金銭を振り
込む決済仲介システムに対し、前記支払意図に間する電
子データを送信する送信処理部とを備える電子決済シス
テム。 - 【請求項24】前記決済処理は、予め定められたスケジ
ュールに従って又は決済処理開始の指令の入力を受け
て、開始される請求項22に記載の電子決済システム。 - 【請求項25】電子決済に関する決済処理をコンピュー
タに実行させるためのプログラムを記録した記録媒体に
おいて、 前記決済処理は、 金銭の支払意図に間する電子データを作成し送信する支
払意図作成処理と、 前記支払意図に間する電子データを受信した場合に振込
口座の指定を受け付け振込口座指定に関する電子データ
を作成し送信する振込口座指定処理と、 前記支払意図に間する電子データに含まれる支払期限又
は支払期間内に前記振込口座指定に関する電子データを
受信した場合に前記振込口座へ金銭を振り込む定期処理
とを備える記録媒体。 - 【請求項26】電子決済に関する仲介処理をコンピュー
タにより実行するネットワーク接続人システムにおい
て、 前記仲介処理は、 金銭の支払意図に関する電子データを送信する処理と前
記支払意図に関する電子データから特定される支払期限
又は支払期間内に振込口座指定に関するデータを受信し
た場合に前記振込口座に金銭を振り込む処理とを実行す
る決済システムからネットワーク又は放送電波を介して
前記支払意図に関する電子データをを受信し、前記支払
意図に関する電子データから特定される受取人の受取人
端末へネットワーク又は放送電波又は電話回線を介して
前記支払意図に関する電子データを送信する支払意図到
着通知転送処理部と、 前記携帯端末からネットワーク又は電話回線を介して前
記振込口座指定に関する電子データを受信し、前記決済
システムへネットワークを介して前記振込口座指定に関
する電子データを送信する振込口座指定処理部とを備え
るネットワーク接続人システム - 【請求項27】電子決済に関する金銭の振込処理をコン
ピュータにより実行する振込処理システムにおいて、 金銭の受取人の電子署名を復号化する公開鍵を記憶する
記憶装置を備え、 前記電子署名は、前記支払義務の発生毎に金銭の支払人
が発行する支払意図に関する電子データを前記受取人の
秘密鍵によって暗号化されたものであり、 前記振込処理は、 前記電子署名が付与された振込口座の指定に関する電子
データを受ける処理部と、 前記支払意図に関する電子データにより特定される支払
期限又は支払期間内に前記振込口座の指定に関する電子
データを受けたことを判断する処理部と、 前記公開鍵を用いて前記電子署名を復号化する処理部
と、 支払意図に関する電子データに基づいて、復号化された
電子署名の正当性を判断する処理部とを有する振込処理
システム。 - 【請求項28】コンピュータを用いて電子決済を仲介す
る電子決済仲介方法において、 金銭の支払人から金銭の支払意図に間する電子データを
受けた場合に前記支払意図に関する電子データから特定
される受取人の振込口座の有無を金融機関システムへ問
い合わせ、 前記金融期間システムから前記振込口座が存在しない旨
の回答を受けた場合に前記受取人へ前記支払意図に関す
る電子データを送り、 支払義務の発生毎に前記支払意図に間する電子データか
ら特定される支払期限又は支払期間内に前記振込口座の
指定を含む支払意図に間する電子データを受けた場合に
前記支払人が保有する財貨の中から前記指定口座へ金銭
を移動させる電子決済仲介方法。 - 【請求項29】コンピュータを用いて電子決済を仲介す
る電子決済仲介方法において、 金銭の支払人から金銭の支払意図に間する電子データを
受けた場合に前記支払意図に関する電子データから特定
される受取人の振込口座の有無を金融機関システムへ問
い合わせ、 前記金融期間システムから前記振込口座が存在する旨の
回答を受けた場合に前記支払人が保有する財貨の中から
前記指定口座へ金銭を移動させる電子決済仲介方法。 - 【請求項30】コンピュータを用いて電子決済に関する
仲介処理を行う電子決済仲介システムにおいて、 前記仲介処理は、 金銭の支払人の支払人システムから、金銭の支払意図に
間する電子データを受信する支払意図登録通知処理部
と、 前記支払意図に間する電子データの受信を受けて、金融
機関の金融機関システムへ前記支払意図に間する電子デ
ータから特定される取人の振込口座が存在することを確
認するための電子データを送信する振込口座確認処理
と、 前記金融機関システムから振込口座が存在する旨の電子
データを受信したことを受けて、前記支払人が保有する
財貨の中から前記振込口座へ金銭を移動させる定期処理
部とを備えた電子決済仲介システム。 - 【請求項31】コンピュータを用いて電子決済に関する
仲介処理を行う被電子決済仲介方法において、 金銭の受取人から予め振込口座の指定を受け、 前記振込口座に関するデータをデータベースに保存し、 支払義務の発生毎に前記振込口座の指定を受けた場合に
前記振込口座に金銭を振り込む支払人又は決済仲介人か
ら金銭の支払意図の通知を受けた場合に、前記支払意図
から特定される受取人の振込口座を前記データベースか
ら検索し、検索された振込口座を前記支払人又は決済仲
介人へ通知する被電子決済仲介方法。 - 【請求項32】電子決済に関する仲介処理をコンピュー
タにより実行する被電子決済仲介システムにおいて、 前記仲介処理は、 振込口座に関するデータをデータベースに保存する振込
口座保存処理部と、 金銭の支払意図を通知すると共に前記支払意図から特定
される支払期限又は支払期間内に振込口座の指定を受け
た場合に前記振込口座に金銭を振り込む支払人又は決済
仲介人から前記支払意図の通知を受けた場合に、前記支
払意図から特定される受取人の振込口座を前記データベ
ースから検索し、検索された振込口座を前記支払人又は
決済仲介人へ通知する振込口座指定処理部とを備える被
電子決済仲介システム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000313119A JP2002117361A (ja) | 2000-10-06 | 2000-10-06 | 電子決済方法及び電子決済システム |
US09/803,208 US20020049670A1 (en) | 2000-10-06 | 2001-03-09 | Electronic payment method and system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000313119A JP2002117361A (ja) | 2000-10-06 | 2000-10-06 | 電子決済方法及び電子決済システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2002117361A true JP2002117361A (ja) | 2002-04-19 |
Family
ID=18792581
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000313119A Pending JP2002117361A (ja) | 2000-10-06 | 2000-10-06 | 電子決済方法及び電子決済システム |
Country Status (2)
Country | Link |
---|---|
US (1) | US20020049670A1 (ja) |
JP (1) | JP2002117361A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005524184A (ja) * | 2002-04-28 | 2005-08-11 | ペイクール インターナショナル リミテッド | 電気通信事業者の金融取引サービスを可能にするシステムおよびそのような取引を実施する方法 |
JP2007521542A (ja) * | 2003-11-10 | 2007-08-02 | イーベイ インク. | 複数の当事者間における少額決済の円滑化 |
CN112016893A (zh) * | 2020-08-27 | 2020-12-01 | 西安热工研究院有限公司 | 一种基于项目管理系统的到账认领系统及方法 |
Families Citing this family (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9252955B2 (en) * | 2000-08-18 | 2016-02-02 | United States Postal Service | Apparatus and methods for the secure transfer of electronic data |
US7302582B2 (en) * | 2000-08-21 | 2007-11-27 | United States Postal Service | Delivery point validation system |
US20060277146A1 (en) * | 2001-03-31 | 2006-12-07 | First Data Corporation | Electronic identifier payment systems and methods |
WO2002079939A2 (en) * | 2001-03-31 | 2002-10-10 | First Data Corporation | Electronic identifier payment system and methods |
US7664731B2 (en) * | 2002-03-21 | 2010-02-16 | United States Postal Service | Method and system for storing and retrieving data using hash-accessed multiple data stores |
AU2003213722A1 (en) * | 2002-03-21 | 2003-10-08 | David J. Payne | Method and system for storing and retrieving data using hash-accessed multiple data stores |
US7296154B2 (en) * | 2002-06-24 | 2007-11-13 | Microsoft Corporation | Secure media path methods, systems, and architectures |
US20040083169A1 (en) * | 2002-08-02 | 2004-04-29 | First Data Corporation | Method and systems to identify and control payment fraud |
US7159119B2 (en) | 2002-09-06 | 2007-01-02 | United States Postal Service | Method and system for efficiently retrieving secured data by securely pre-processing provided access information |
CA2498023C (en) * | 2002-09-06 | 2012-08-07 | United States Postal Service | Method and system for efficiently retrieving secured data by securely pre-processing provided access information |
US20040139016A1 (en) | 2002-11-01 | 2004-07-15 | Modasolutions Corporation | Internet payment systerm and method |
JP2004171130A (ja) * | 2002-11-18 | 2004-06-17 | Brother Ind Ltd | 通信システム、電子機器、及びプログラム |
US20050065876A1 (en) * | 2003-05-12 | 2005-03-24 | Pulkit Kumar | Airbank, pay to anyone from the mobile phone |
DE10347990A1 (de) * | 2003-10-15 | 2005-06-02 | Giesecke & Devrient Gmbh | Verfahren zur Abwicklung eines bargeldlosen Zahlungsvorgangs |
US7694143B2 (en) * | 2003-11-18 | 2010-04-06 | Oracle International Corporation | Method of and system for collecting an electronic signature for an electronic record stored in a database |
US7600124B2 (en) * | 2003-11-18 | 2009-10-06 | Oracle International Corporation | Method of and system for associating an electronic signature with an electronic record |
US7966493B2 (en) * | 2003-11-18 | 2011-06-21 | Oracle International Corporation | Method of and system for determining if an electronic signature is necessary in order to commit a transaction to a database |
US8782020B2 (en) * | 2003-11-18 | 2014-07-15 | Oracle International Corporation | Method of and system for committing a transaction to database |
US20050108211A1 (en) * | 2003-11-18 | 2005-05-19 | Oracle International Corporation, A California Corporation | Method of and system for creating queries that operate on unstructured data stored in a database |
US7650512B2 (en) * | 2003-11-18 | 2010-01-19 | Oracle International Corporation | Method of and system for searching unstructured data stored in a database |
US8306920B1 (en) * | 2004-07-28 | 2012-11-06 | Ebay Inc. | Method and system to securely store customer data in a network-based commerce system |
US7801925B2 (en) * | 2004-12-22 | 2010-09-21 | United States Postal Service | System and method for electronically processing address information |
JP2006185060A (ja) * | 2004-12-27 | 2006-07-13 | Fujitsu Ltd | パスワード入力方法 |
US8165909B2 (en) | 2005-05-17 | 2012-04-24 | The United States Postal Service | System and method for automated management of an address database |
US8290433B2 (en) * | 2007-11-14 | 2012-10-16 | Blaze Mobile, Inc. | Method and system for securing transactions made through a mobile communication device |
US8249985B2 (en) * | 2007-11-29 | 2012-08-21 | Bank Of America Corporation | Sub-account mechanism |
CA2659530A1 (en) * | 2008-03-20 | 2009-09-20 | Modasolutions Corporation | Risk detection and assessment of cash payment for electronic purchase transactions |
US8898086B2 (en) * | 2010-09-27 | 2014-11-25 | Fidelity National Information Services | Systems and methods for transmitting financial account information |
US20120239560A1 (en) * | 2011-03-04 | 2012-09-20 | Pourfallah Stacy S | Healthcare payment collection portal apparatuses, methods and systems |
US8645272B2 (en) | 2011-06-24 | 2014-02-04 | Western Union Financial Services, Inc. | System and method for loading stored value accounts |
US9792593B2 (en) | 2011-11-23 | 2017-10-17 | The Toronto-Dominion Bank | System and method for processing an online transaction request |
US20140337059A1 (en) * | 2013-05-08 | 2014-11-13 | Digital Life Holdings, LLC | System and method of incentivizing social media companies to honor the bequeathment requests |
US10037530B2 (en) * | 2013-06-13 | 2018-07-31 | Paypal, Inc. | Payment recipient verification |
US10013714B2 (en) | 2015-09-11 | 2018-07-03 | Bank Of America Corporation | System for simulation and implementation of dynamic state-dependent resource reconfiguration |
US10127551B2 (en) * | 2015-09-11 | 2018-11-13 | Bank Of America Corporation | System for modeling and implementing event-responsive resource allocation structures |
US10249002B2 (en) | 2015-09-11 | 2019-04-02 | Bank Of America Corporation | System for dynamic visualization of individualized consumption across shared resource allocation structure |
EP3340139A1 (en) * | 2016-12-22 | 2018-06-27 | Mastercard International Incorporated | Amount confirmation for visually impaired users |
US11233658B2 (en) * | 2019-08-14 | 2022-01-25 | OX Labs Inc. | Digital transaction signing for multiple client devices using secured encrypted private keys |
US20240152918A1 (en) * | 2022-11-03 | 2024-05-09 | Capital One Services, Llc | Distributed database with inter-related records relating to a vehicle |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5826241A (en) * | 1994-09-16 | 1998-10-20 | First Virtual Holdings Incorporated | Computerized system for making payments and authenticating transactions over the internet |
US6039250A (en) * | 1995-07-06 | 2000-03-21 | Hitachi, Ltd. | Electronic money sending system |
US5884288A (en) * | 1996-07-01 | 1999-03-16 | Sun Microsystems, Inc. | Method and system for electronic bill payment |
KR100213188B1 (ko) * | 1996-10-05 | 1999-08-02 | 윤종용 | 사용자 인증 장치 및 방법 |
CA2275574C (en) * | 1996-12-20 | 2003-07-29 | Financial Services Technology Consortium | Method and system for processing electronic documents |
US6049786A (en) * | 1997-07-22 | 2000-04-11 | Unisys Corporation | Electronic bill presentment and payment system which deters cheating by employing hashes and digital signatures |
US6173272B1 (en) * | 1998-04-27 | 2001-01-09 | The Clearing House Service Company L.L.C. | Electronic funds transfer method and system and bill presentment method and system |
US6401079B1 (en) * | 1999-10-01 | 2002-06-04 | Inleague, Inc. | System for web-based payroll and benefits administration |
US7870065B2 (en) * | 2000-01-05 | 2011-01-11 | Uniteller Financial Services, Inc. | Money-transfer techniques |
-
2000
- 2000-10-06 JP JP2000313119A patent/JP2002117361A/ja active Pending
-
2001
- 2001-03-09 US US09/803,208 patent/US20020049670A1/en not_active Abandoned
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005524184A (ja) * | 2002-04-28 | 2005-08-11 | ペイクール インターナショナル リミテッド | 電気通信事業者の金融取引サービスを可能にするシステムおよびそのような取引を実施する方法 |
JP2007521542A (ja) * | 2003-11-10 | 2007-08-02 | イーベイ インク. | 複数の当事者間における少額決済の円滑化 |
US8051007B2 (en) | 2003-11-10 | 2011-11-01 | Ebay Inc | Method and system to facilitate a payment in satisfaction of accumulated micropayment commitments to a vendor |
CN112016893A (zh) * | 2020-08-27 | 2020-12-01 | 西安热工研究院有限公司 | 一种基于项目管理系统的到账认领系统及方法 |
Also Published As
Publication number | Publication date |
---|---|
US20020049670A1 (en) | 2002-04-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2002117361A (ja) | 電子決済方法及び電子決済システム | |
US11373182B2 (en) | System and method for transferring funds | |
US20230351345A1 (en) | System and method for transferring funds | |
JP6727299B2 (ja) | 非金融機関システムでのセキュア取引を促進するシステム及び方法 | |
US8285640B2 (en) | System and methods for facilitating fund transfers over a network | |
US10318936B2 (en) | System and method for transferring funds | |
US20160132884A1 (en) | Real-time payments through financial institution | |
US20160042328A1 (en) | Systems and methods for facilitating sharing of expenses over a network | |
US20040088235A1 (en) | Technique for customizing electronic commerce user | |
US20040133509A1 (en) | Technique for making payments for a non-subscriber payor | |
US20040143546A1 (en) | Easy user activation of electronic commerce services | |
US20040133515A1 (en) | Distributed matching of consumers with billers having bills available for electronic presentment | |
JP2003536174A (ja) | インタネットの支払いを処理する方法および装置 | |
JP2004531813A (ja) | オンライン信用状および/またはオンライン契約履行保証により支持される安全な電子銀行為替手形を介して付帯事項依存の支払を実行するための方法およびシステム | |
US10970688B2 (en) | System and method for transferring funds | |
US20100280944A1 (en) | Paperless checking transactions | |
US20240078547A1 (en) | System and method for facilitating transferring funds | |
JP2002297916A (ja) | 為替取引処理方法及びそのシステム | |
JP2006215666A (ja) | 電子手形管理システム | |
CN112785380B (zh) | 交易处理方法及装置 | |
KR20100045098A (ko) | 복합계좌를 통한 기금지급 처리방법 및 시스템과 이를 위한기록매체 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050613 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050621 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050818 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060214 |