(58)【調査した分野】(Int.Cl.,DB名)
前記情報処理装置は、前記請求金額決定部により決定された前記第1の注文の実請求金額を利用者に通知するためのイベントの表示制御をするイベント制御部をさらに備える、請求項1〜5のいずれか一項に記載の情報処理装置。
【発明を実施するための形態】
【0020】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【0021】
また、本明細書及び図面において、実質的に同一の機能構成を有する複数の構成要素を、同一の符号の後に異なるアルファベットを付して区別する場合もある。例えば、実質的に同一の機能構成を有する複数の構成を、必要に応じて通信網26aおよび通信網26bのように区別する。ただし、実質的に同一の機能構成を有する複数の構成要素の各々を特に区別する必要がない場合、同一符号のみを付する。例えば、通信網26aおよび通信網26bを特に区別する必要が無い場合には、単に通信網26と称する。
【0022】
また、以下に示す項目順序に従って当該「発明を実施するための形態」を説明する。
1.情報処理システムの基本構成
1−1.基本構成
1−2.課題の整理
2.各実施形態の詳細な説明
2−1.第1の実施形態
2−2.第2の実施形態
3.ハードウェア構成
4.変形例
【0023】
<<1.情報処理システムの基本構成>>
<1−1.基本構成>
本発明は、一例として「2−1.第1の実施形態」〜「2−2.第2の実施形態」において詳細に説明するように、多様な形態で実施され得る。最初に、本発明の各実施形態に共通する情報処理システムの基本構成について、
図1を参照して説明する。
【0024】
図1に示したように、各実施形態に共通する情報処理システムは、請求金額決定サーバ10、EC決済サーバ20、口座管理DB22、顧客端末24、および通信網26を含む。
【0025】
なお、本情報処理システムは、金融機関により提供される仮想口座サービスを利用することを想定する。ここで、仮想口座サービスの内容について説明する。
【0026】
[1−1−1.仮想口座サービス]
仮想口座サービスは、金融機関において開設されている個々の実口座に対応づけて複数の仮の口座(仮想口座)を設けることが可能なサービスである。なお、実口座の利用者は、例えば、後述するEC(Electronic Commerce)サイトで商品を出品している企業のような、多数の人物から振込みがなされる事業者などである。
【0027】
また、仮想口座は、実口座を有する事業者により、基本的には、当該事業者の顧客一人ひとりに対して一意に割り当てられる口座である。但し、各事業者が有する仮想口座の数は有限であるので、事業者は、例えば顧客の人数が増加した場合などには、仮想口座の口座番号を使い回すことにより、顧客に対して仮想口座を割り当てる。例えば、事業者は、顧客により注文がなされる度に、当該事業者が有するいずれかの仮想口座の口座番号を選択し、そして、選択した口座番号と当該注文とを対応づけて管理する。なお、事業者は、選択した口座番号を当該注文の振込用口座の口座番号として、当該注文を行った顧客に対して案内する。
【0028】
[1−1−2.EC決済サーバ20]
EC決済サーバ20は、EC(Electronic Commerce)サイトを管理するサーバである。このECサイトでは、複数の事業者により商品が出品されており、また、顧客は、出品されている商品をECサイト上で注文することが可能である。
【0029】
また、EC決済サーバ20は、ECサイトにおいて顧客により注文された内容に基づいて注文データを生成する。ここで、
図2を参照して、注文データの構成例(注文データ30)について説明する。
図2に示したように、例えば、注文データ30では、注文番号300、商品名302、請求金額304、および顧客名306が対応づけて記録される。ここで、注文番号300には、発生した各注文を識別するための注文番号が記録される。また、商品名302には、該当の注文番号で注文された商品の名前が記録される。また、請求金額304には、該当の注文番号で注文された商品に関して例えばECサイト上で表示されている請求金額(以下、基準請求金額とも称する)が記録される。また、顧客名306には、該当の注文番号に対応する注文を行った顧客の名前が記録される。
【0030】
なお、
図2では、商品名302に1個の商品の名前だけが記録される例を示しているが、かかる例に限定されない。例えば、該当の注文番号で複数の商品が一括に注文された場合には、注文された全ての商品の名前が商品名302に記録される。また、複数の商品が一括に注文された場合には、請求金額304には、注文された全ての商品の合計の請求金額が記録される。
【0031】
また、EC決済サーバ20は、詳細については後述するように、口座管理DB22を参照し、そして、発生した注文の注文番号と、当該注文の振込み先口座である仮想口座の口座番号とを所定のルールに沿って対応づける。
【0032】
また、EC決済サーバ20は、通信網26aを介して、請求金額決定サーバ10、または口座管理DB22との間で各種情報を送受信することが可能である。例えば、EC決済サーバ20は、生成した注文データと、当該注文データが示す注文に対応づけた仮想口座の口座番号とを請求金額決定サーバ10、または口座管理DB22へ送信することが可能である。
【0033】
[1−1−3.顧客端末24]
顧客端末24は、例えばECサイトに会員登録している顧客により使用される情報処理端末である。この顧客端末24は、例えばPC(Personal Computer)、タブレット端末、またはスマートフォンなどであってもよい。
【0034】
顧客端末24は、通信網26bを介して、例えばECサイトのWebページをEC決済サーバ20から受信し、そして、表示画面に表示することが可能である。また、顧客端末24は、ECサイトのWebページ上で顧客により入力された注文内容をEC決済サーバ20へ送信することが可能である。
【0035】
[1−1−4.口座管理DB22]
口座管理DB22は、実口座および仮想口座を対応づけて管理するためのデータベースである。この口座管理DB22は、注文データと、当該注文データが示す注文に対応づけられた仮想口座の口座番号とをEC決済サーバ20から受信した場合には、受信した注文データに含まれる注文番号と、仮想口座の口座番号とを対応づけて記憶する。
【0036】
ここで、
図3を参照して、口座管理DB22の構成例について説明する。
図3に示したように、例えば、口座管理DB22では、実口座番号220、仮想口座番号222、注文番号224、および請求金額226が対応づけて記憶される。ここで、実口座番号220には、個々の実口座の口座番号が記録される。また、仮想口座番号222には、該当の実口座に対応づけられている複数の仮想口座の各々の口座番号が記録される。また、注文番号224には、該当の仮想口座に対応づけられた注文の注文番号が記録される。また、請求金額226には、該当の仮想口座に対応づけられた注文の請求金額が記録される。
【0037】
[1−1−5.請求金額決定サーバ10]
請求金額決定サーバ10は、本発明における情報処理装置の一例である。請求金額決定サーバ10は、後述するように、EC決済サーバ20から受信される注文データが示す注文の実請求金額、つまり実際の請求金額を決定するための装置である。
【0038】
また、後述するように、請求金額決定サーバ10は、決定した注文の実請求金額、および該当の注文の振込み先口座の口座番号が記載された払込票を、当該注文を行った顧客宛てに送付させることが可能である。
【0039】
なお、各実施形態では、例えば
図4に示したような流れで、注文された商品の決済が行われることを想定する。
図4に示したように、まず、ECサイトで注文を行った顧客は、注文後に送付される払込票を確認し、そして、例えばATM(Automated Teller Machine)、金融機関の窓口、またはインターネットバンキングなどの金融機関のサービスを介して、払込票に記載されている仮想口座の口座番号に対して、払込票に記載されている請求金額を振り込む。なお、仮想口座に対して振り込まれた金額は、仮想口座経由で実口座に入金される。そして、例えば事業者などの実口座の名義人は、該当の仮想口座に対する入金結果を確認することにより、該当の注文に対する支払いが正しくなされたか否かを確認する。
【0040】
[1−1−6.通信網26]
通信網26は、通信網26に接続されている装置から送信される情報の有線、または無線の伝送路である。例えば、通信網26は、電話回線網、インターネット、衛星通信網などの公衆回線網や、Ethernet(登録商標)を含む各種のLAN(Local Area Network)、WAN(Wide Area Network)などを含む。また、通信網26は、IP−VPN(Internet Protocol−Virtual Private Network)などの専用回線網を含んでもよい。
【0041】
なお、本実施形態による情報処理システムは、上述した構成に限定されない。例えば、口座管理DB22は独立した装置として構成される代わりに、請求金額決定サーバ10、またはEC決済サーバ20に記憶されてもよい。また、請求金額決定サーバ10とEC決済サーバ20は独立した装置として構成される代わりに、一体の装置として構成されてもよい。
【0042】
<1−2.課題の整理>
ところで、上述したように、事業者が有する仮想口座の数は有限であるので、顧客一人ひとりに対して仮想口座を一意に割り当てることは難しい。このため、事業者は、仮想口座の口座番号を使い回すこと(プーリング)により、注文を行った顧客に対して仮想口座の口座番号を割り当てることが多い。
【0043】
その結果、例えば同じ顧客が同じ事業者が出品している同じ商品を注文する場合であっても、顧客に対して割り当てられる仮想口座の口座番号は、注文の度に異なる可能性がある。このため、特に複数回注文した顧客は、自己の注文の請求金額を振込み先口座を間違えて振り込んでしまう恐れがある。例えば、顧客は、今回の注文の請求金額を、前回注文時の振込み先口座に振込んでしまう恐れがある。
【0044】
そして、顧客により口座番号を間違えて振込みが行われた場合には、例えば事業者などの振込受取人は、振込間違いの発生を検知できない恐れがある。
【0045】
ここで、
図5を参照して、上記の内容についてより詳細に説明する。なお、
図5に示した例では、顧客Aが同一の請求金額(つまり「300,000円」)の注文を2つ(「注文1」および「注文2」)行い、また、顧客Bが、「注文1」と同一の請求金額の注文を1つ(「注文3」)行った場合を前提とする。また、顧客Aの2つの注文に対応づけられている仮想口座は、互いに異なっていることを前提とする。
【0046】
この場合において、例えば顧客Aが「注文1」の請求金額を、「注文2」に対応づけられた仮想口座400bに誤って振り込んだ場合には、請求金額が同一であるので、振込受取人は振込間違いに気付くことができない。また、顧客Bが「注文3」の請求金額を、「注文1」に対応づけられた仮想口座400aに誤って振り込んだ場合にも、請求金額が同一であるので、振込受取人は振込間違いに気付くことができず、正しい振込みがなされたと判断してしまう。
【0047】
そして、上記の理由により、振込依頼人が振込受取人に対して例えば「振込をしたにも関わらず商品が届かない」などのクレームを行わない限り、振込間違いが検知できないという問題が生じ得る。
【0048】
そこで、上記事情を一着眼点にして本発明による請求金額決定サーバ10を創作するに至った。本発明による請求金額決定サーバ10は、注文の請求金額が振込依頼人により振り込まれる際に、振込依頼人が支払を意図した注文の特定を容易化することが可能である。以下、このような本発明の実施形態について順次詳細に説明する。
【0049】
<<2.実施形態の詳細な説明>>
<2−1.第1の実施形態>
まず、第1の実施形態について説明する。後述するように、第1の実施形態によれば、新規の注文の基準請求金額と同一である注文が発生済みである場合には、新規の注文の実請求金額を基準請求金額からランダムに値引くことにより、各注文の実請求金額をできるだけ一意に決定することが可能である。
【0050】
[2−1−1.構成]
最初に、第1の実施形態による構成について説明する。
図6は、第1の実施形態による請求金額決定サーバ10−1の構成を示した機能ブロック図である。
図6に示したように、請求金額決定サーバ10−1は、制御部100−1、通信部120、および記憶部122を有する。
【0051】
(2−1−1−1.制御部100−1)
制御部100−1は、請求金額決定サーバ10−1に内蔵される、後述するCPU(Central Processing Unit)150、RAM(Random Access Memory)154などのハードウェアを用いて、請求金額決定サーバ10−1の動作を全般的に制御する。また、
図6に示したように、制御部100−1は、注文確認部102−1、請求金額決定部104−1、イベント制御部106、および払込票生成部108を有する。
【0052】
(2−1−1−2.注文確認部102−1)
注文確認部102−1は、発生済みの複数の注文のうち、EC決済サーバ20から新たに受信された注文データが示す注文(以下、新規の注文とも称する)と基準請求金額が同一である他の注文が有るか否かを、例えば値引状況管理DB124を参照することにより確認する。ここで、新規の注文は、本発明における第1の注文の一例であり、また、上記の「他の注文」は、本発明における第2の注文の一例である。
【0053】
例えば、注文確認部102−1は、発生済みの複数の注文のうち、新規の注文と基準請求金額が同一であり、かつ、新規の注文の発生時において未決済である他の注文が有るか否かを値引状況管理DB124を参照することにより確認する。
【0054】
‐値引状況管理DB124
ここで、
図7を参照して、値引状況管理DB124の構成例について説明する。
図7に示したように、例えば、値引状況管理DB124では、仮想口座番号1240、注文番号1242、基準請求金額1244、特別値引額1246、実請求金額1248、および決済状況1250が対応づけて記録される。ここで、仮想口座番号1240には、個々の仮想口座の口座番号が記録される。また、注文番号1242には、該当の仮想口座に対応づけられた注文の注文番号が記録される。また、基準請求金額1244には、該当の注文の基準請求金額が記録される。また、特別値引額1246には、該当の注文に関して、後述する請求金額決定部104−1により決定される値引き額が記録される。また、実請求金額1248には、該当の注文に関して、請求金額決定部104−1により決定される実請求金額が記録される。また、決済状況1250には、該当の注文に関する決済状況(「未決済」や「決済済み」など)が記録される。
【0055】
例えば、
図7に示した例において、注文番号が「111111」である注文の基準請求金額は「300,000円」であり、また、当該注文は現在「未決済」である。このため、注文確認部102−1は、仮に新規の注文の基準請求金額が「300,000円」である場合には、新規の注文と基準請求金額が同一であり、かつ未決済の注文が存在すると判定する。
【0056】
なお、変形例として、注文確認部102−1は、新規の注文の注文日から所定の期間内において発生した複数の注文に限定して、新規の注文と基準請求金額が同一である他の注文が有るか否かを確認してもよい。
【0057】
(2−1−1−3.請求金額決定部104−1)
‐請求金額の決定
請求金額決定部104−1は、注文確認部102−1により新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の実請求金額を基準請求金額と異なる金額に決定する。より具体的には、請求金額決定部104−1は、上記の場合には、新規の注文の実請求金額を基準請求金額よりも所定の範囲内で小さい金額にランダムに決定する。
【0058】
例えば、請求金額決定部104−1は、上記の場合には、まず、新規の注文に関する基準請求金額からの値引き額を、例えば基準請求金額の1%以内などの所定の範囲内でランダムに決定する。そして、請求金額決定部104−1は、決定した値引き額を新規の注文の基準請求金額から減額することにより、新規の注文の実請求金額を決定する。
【0059】
ここで、
図8を参照して、上記の機能についてより詳細に説明する。なお、
図8では、「注文1」が注文された後に、「注文2」または「注文3」が顧客により注文されたことを前提とする。
【0060】
図8に示したように、「注文1」と「注文2」の基準請求金額は同一である。このため、「注文2」が顧客Aにより注文された場合には、請求金額決定部104−1は、「注文2」の実請求金額を基準請求金額(「300,000円」)よりも小さい金額(例えば、「299,999円」)に決定する。
【0061】
同様に、「注文1」と「注文3」の基準請求金額は同一である。このため、「注文3」が顧客Bにより注文された場合には、請求金額決定部104−1は、「注文3」の実請求金額を基準請求金額(「300,000円」)よりも小さい金額(例えば、「299,995円」)に決定する。
【0062】
この決定例によれば、例えば、顧客Aが「注文1」の請求金額を、「注文2」に対応づけられた仮想口座400bに誤って振り込んだ場合には、請求金額が異なるので、決済システムにより振込誤りとして検知される。このため、振込受取人は、顧客Aによる振込誤りに気付くことができる。
【0063】
また、顧客Bが「注文3」の請求金額を、「注文1」に対応づけられた仮想口座400aに誤って振り込んだ場合にも、請求金額が異なるので、決済システムにより振込誤りとして検知される。このため、振込受取人は、振込誤りに気付くことができる。さらに、振込受取人は、振り込まれた金額(つまり、「299,995円」)から、当該振込の依頼人は「注文3」を注文した人物、つまり顧客Bである可能性が高いことを推測することができる。
【0064】
‐請求金額の記録
また、請求金額決定部104−1は、決定した実請求金額を値引状況管理DB124に記録することが可能である。例えば、注文番号が「111188」である新規の注文の実請求金額が「299,997円」と決定されたとする。この場合、例えば
図9において一点鎖線で示したように、請求金額決定部104−1は、決定した新規の注文の実請求金額を、対応する仮想口座の口座番号である「1000008」および当該注文の注文番号と対応づけて値引状況管理DB124に追加記録する。
【0065】
(2−1−1−4.イベント制御部106)
イベント制御部106は、請求金額決定部104−1により決定された新規の注文の値引き額を顧客に通知するためのイベントの表示制御をする。例えば、イベント制御部106は、新規の注文に対して決定された値引き額を顧客に通知するためのゲーム画面を表示させる指示情報をEC決済サーバ20へ通信部120に送信させる。ここで、上記の指示情報は、ゲーム画面を構成する全ての表示情報を含んでいてもよいし、または、決定された値引き額だけを含んでいてもよい。
【0066】
なお、EC決済サーバ20は、上記の指示情報を受信した場合には、例えば
図10に示したようなゲーム画面50を顧客端末24に表示させる。このゲーム画面50は、3択ゲームの表示例である。
【0067】
仮に、請求金額決定部104−1により新規の注文の値引き額が「3円」と決定されたとする。この場合、ゲーム画面50において顧客によりいずれかのボタン500が選択されると、顧客端末24は、例えば「ご当選おめでとうございます。サイト表示金額から3円を値引きします。」、あるいは「3等当選おめでとうございます。サイト表示金額から3円を値引きします。」など、決定された値引き額を示すテキストを表示画面に表示する。
【0068】
この表示例による効果として以下が挙げられる。上述したように、基準請求金額が同じであっても、通常、請求金額決定部104−1により決定される値引き額は注文ごとに異なる。つまり、顧客が同じ商品を複数回注文した場合や、複数の顧客が同じ商品を注文した場合では、注文の度に値引き額が異なり得る。このため、仮に何の事前通知もなく、決定された値引き額(あるいは、実請求金額)だけが顧客に通知され、かつ、同一の顧客の複数の注文間または複数の顧客の注文間で値引き額が異なっていることを顧客が知った場合には、値引き額の決定に関して顧客は違和感や、不公平感を抱く恐れがある。一方、上記の表示例によれば、ゲームなどのイベントの実行を通して値引き額が決定されたように顧客に認識される可能性が高いので、決定された値引き額に関して違和感や不公平感を顧客が抱く恐れはほとんど無いと考えられる。
【0069】
(2−1−1−5.払込票生成部108)
払込票生成部108は、請求金額決定部104−1により決定された実請求金額が記録された払込票を生成する。
【0070】
ここで、
図11を参照して、払込票の構成例(払込票60)について説明する。
図11に示したように、払込票60は、例えば、振込み先口座番号600、および振込金額602を含む。ここで、振込み先口座番号600には、例えばEC決済サーバ20から受信される該当の注文に対応づけられた仮想口座の口座番号が記録される。また、振込金額602には、請求金額決定部104−1により決定された該当の注文の実請求金額が記録される。
【0071】
また、払込票生成部108は、生成した払込票を、注文した顧客宛てに例えば電子メールや郵送などにより送付させる。なお、払込票が送付された顧客は、例えばATMなどの金融機関のサービスを利用して、払込票に記載されている口座番号に、払込票に記載されている振込金額を正確に振り込むことが要求される。
【0072】
(2−1−1−6.通信部120)
通信部120は、例えば通信網26を介して、他の装置との間で情報の送受信を行う。例えば、通信部120は、EC決済サーバ20から注文データを受信する。また、通信部120は、払込票生成部108の制御により、生成された払込票を、当該払込票に対応する注文を行った顧客のメールアドレス宛てに送信する。
【0073】
(2−1−1−7.記憶部122)
記憶部122は、例えば値引状況管理DB124などの、各種のデータを記憶することが可能である。
【0074】
なお、本実施形態による請求金額決定サーバ10の構成は、上述した構成に限定されない。例えば、値引状況管理DB124は、記憶部122に記憶される代わりに、請求金額決定サーバ10と通信可能な他の装置に記憶されることも可能である。
【0075】
[2−1−2.動作]
以上、第1の実施形態による構成について説明した。続いて、第1の実施形態による動作について説明する。なお、ここでは、顧客がECサイト上で商品の注文を行う場面における動作の例について説明する。
【0076】
(2−1−2−1.全体的な動作)
図12は、第1の実施形態による全体的な動作を示したシーケンス図である。
図12に示したように、まず、顧客端末24は、顧客の操作に基づいてEC決済サーバ20へ接続し、そして、ECサイトのWebページをEC決済サーバ20から受信する。
【0077】
その後、顧客は、受信されたWebページにおいて商品の注文の入力を行う。そして、顧客端末24は、入力された内容をEC決済サーバ20へ送信する(S101)。
【0078】
その後、EC決済サーバ20は、S101で受信された入力情報に基いて注文データを生成する(S102)。
【0079】
そして、EC決済サーバ20は、口座管理DB22を参照し、そして、所定のルールに沿って、S101でなされた注文と対応づける仮想口座の口座番号を選出する。そして、EC決済サーバ20は、S102で生成した注文データに含まれる注文番号と、選出した仮想口座の口座番号とを口座管理DB22へ送信する。その後、口座管理DB22は、受信された注文番号および口座番号を対応づけて記憶する(S103)。これにより、注文番号と仮想口座の口座番号とが対応づけられる。
【0080】
その後、EC決済サーバ20は、S103で対応づけられた注文番号および仮想口座の口座番号を請求金額決定サーバ10−1へ送信する(S104)。
【0081】
その後、請求金額決定サーバ10−1は、後述する「請求金額の決定処理」を行う(S105)。
【0082】
その後、請求金額決定サーバ10−1のイベント制御部106は、S105で決定された値引き額を顧客に通知するためのゲーム画面を表示させる指示情報をEC決済サーバ20へ通信部120に送信させる(S106)。
【0083】
その後、EC決済サーバ20は、S106で受信された指示情報に応じたゲーム画面を顧客端末24に送信する(S107)。
【0084】
その後、顧客端末24は、S107で受信されたゲーム画面を表示する。そして、表示されたゲーム画面において顧客によりゲームが実行されると、顧客端末24は、S105で決定された値引き額を表示画面に表示する(S108)。
【0085】
また、S106の後に、請求金額決定サーバ10−1の払込票生成部108は、S104で受信された口座番号と、S105で決定された実請求金額とが記録された払込票を生成する(S109)。
【0086】
その後、払込票生成部108は、生成した払込票を、注文した顧客宛てに例えば電子メールや郵送などにより送付させる(S110)。
【0087】
(2−1−2−2.請求金額の決定処理)
ここで、
図13を参照して、S105における「請求金額の決定処理」について詳細に説明する。
【0088】
まず、請求金額決定サーバ10−1の注文確認部102−1は、発生済みの複数の注文のうち、EC決済サーバ20から受信された注文データが示す新規の注文と基準請求金額が同一で、かつ未決済の他の注文が存在するか否かを値引状況管理DB124を参照することにより確認する(S201)。
【0089】
他の注文が存在しない場合には(S201:No)、請求金額決定部104−1は、新規の注文の実請求金額を基準請求金額と同一の金額に決定する(S202)。そして、請求金額決定部104−1は、当該注文の注文番号と、決定した実請求金額とを対応づけて値引状況管理DB124に記録する(S205)。
【0090】
一方、他の注文が存在する場合には(S201:Yes)、請求金額決定部104−1は、まず、新規の注文に関する基準請求金額からの値引き額を所定の範囲内でランダムに決定する(S203)。
【0091】
続いて、請求金額決定部104−1は、S203で決定した値引き額を当該注文の基準請求金額から減額した金額を当該注文の実請求金額に決定する(S204)。その後、請求金額決定部104−1は、S205の動作を行う。
【0092】
[2−1−3.効果]
以上、例えば
図6、
図12、
図13等を参照して説明したように、第1の実施形態による請求金額決定サーバ10は、発生済みの複数の注文のうち、新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の基準請求金額から所定の範囲内でランダムに減額した金額を当該注文の実請求金額に決定する。
【0093】
このため、注文ごとの実請求金額が概ね一意に決定されるので、注文の請求金額が振込依頼人により振り込まれた場面での、振込依頼人が支払を意図した注文を振込受取人が特定する作業を容易化することができる。
【0094】
例えば、振込依頼人が、注文の請求金額を、当該注文に対応づけられた仮想口座以外の他の仮想口座に誤って振り込んだ場合には、実際に振り込まれた仮想口座に対応づけられている注文の実請求金額と、振込依頼人が支払いを意図した注文の実請求金額とが一致する可能性が極めて低い。このため、決済システムにより振込誤りが検知されることにより、振込受取人は、振込依頼人が振込誤りをしたことに気付くことができる。そして、振込受取人は、振り込まれた金額を基にして注文履歴を検索することにより、当該振込を依頼した人物を推測することができる。また、振込受取人は、推測した人物に対して問い合わせることも可能である。
【0095】
<2−2.第2の実施形態>
以上、第1の実施形態について説明した。次に、第2の実施形態について説明する。後述するように、第2の実施形態によれば、一人の事業者が受注している複数の注文のうちいずれかに対する振込みがなされた際に、当該事業者は、振り込まれた金額により、振込依頼人が支払いを意図した注文を特定することが可能である。
【0096】
[2−2−1.構成]
まず、第2の実施形態による構成について詳細に説明する。なお、以下では、第1の実施形態と異なる機能を有する構成要素についてのみ説明を行う。
【0097】
図14は、第2の実施形態による請求金額決定サーバ10−2の構成を示した機能ブロック図である。
図14に示したように、請求金額決定サーバ10−2は、第1の実施形態と比較して、制御部100−1の代わりに、制御部100−2を有する。
【0098】
(2−2−1−1.制御部100−2)
図14に示したように、制御部100−2は、注文確認部102−1の代わりに注文確認部102−2を、請求金額決定部104−1の代わりに請求金額決定部104−2を、それぞれ有する。なお、その他の機能については、制御部100−1と同様である。
【0099】
(2−2−1−2.注文確認部102−2)
注文確認部102−2は、新規の注文に対応する事業者が有する複数の仮想口座に対応づけられている複数の注文のうち、新規の注文と基準請求金額が同一であり、かつ、新規の注文の発生時において未決済である他の注文が有るか否かを値引状況管理DB124を参照することにより確認する。
【0100】
‐値引状況管理DB124
図15は、第2の実施形態による値引状況管理DB124の登録例を示した説明である。
図15は、ある事業者が3個の仮想口座(「1000001」〜「1000003」)を有しており、かつ、当該事業者に対して7個の注文がなされた際の値引状況管理DB124の登録例を示している。なお、
図15では記載を省略しているが、第2の実施形態による値引状況管理DB124は、各仮想口座を有する事業者の識別情報を示すための列をさらに有することが可能である。
【0101】
(2−2−1−3.請求金額決定部104−2)
請求金額決定部104−2は、注文確認部102−2により新規の注文に対応する事業者が有する複数の仮想口座に対応づけられている複数の注文のうち、新規の注文と基準請求金額が同一であり、かつ、新規の注文の発生時において未決済である他の注文が有ることが確認された場合には、新規の注文の実請求金額を当該他の注文の実請求金額と異なる金額に決定する。より具体的には、請求金額決定部104−2は、上記の場合には、新規の注文の実請求金額を当該他の注文の実請求金額よりも小さい金額に決定する。
【0102】
例えば、請求金額決定部104−2は、上記の場合には、まず、新規の注文に関する基準請求金額からの値引き額を当該他の注文の値引き額よりも大きい金額に決定する。そして、請求金額決定部104−2は、決定した値引き額を新規の注文の基準請求金額から減額することにより、新規の注文の実請求金額を決定する。
【0103】
ここで、
図16を参照して、上記の機能についてより詳細に説明する。なお、
図16は、
図15に示した状態において、注文番号が「111188」である新規の注文がさらに発生し、そして、当該注文が口座番号「1000002」の仮想口座に対応づけられた場面における値引き状況管理DB124の更新例を示している。
【0104】
図16に示したように、新規の注文の基準請求金額(「300,000円」)は、同一の事業者が有する3個の仮想口座に対応づけられている他の4つの注文(つまり、注文番号が「111111」、「111122」、「111144」、または「111155」の注文)と同一である。このため、請求金額決定部104−2は、新規の注文の実請求金額を当該他の4つの注文の実請求金額よりも小さい金額(例えば、「299,996円」)に決定する。
【0105】
この決定例によれば、一人の事業者が有する複数の仮想口座に対応づけられている複数の注文の各々の実請求金額が一意になるように各注文の実請求金額が決定される。このため、ある事業者が有する複数の仮想口座のうちいずれかに対して振込依頼人により振込みがなされた際に、振込受取人(つまり、当該事業者)は、自己が受注している複数の注文のうちいずれに対する振込みがなされたかを、振り込まれた金額により特定することが可能である。
【0106】
[2−2−2.動作]
以上、第2の実施形態による構成について説明した。続いて、第2の実施形態による動作について説明する。なお、第2の実施形態による全体的な動作に関しては、
図12に示した第1の実施形態と概略同様である。
【0107】
(2−2−2−1.請求金額の決定処理)
ここで、
図17を参照して、第2の実施形態による「請求金額の決定処理」(つまり、
図12に示したS105)について詳細に説明する。
【0108】
まず、請求金額決定サーバ10−2の注文確認部102−2は、EC決済サーバ20から受信された注文データが示す新規の注文に対応する事業者が有する複数の仮想口座に対応づけられている複数の注文のうち、新規の注文と基準請求金額が同一であり、かつ、新規の注文の発生時において未決済である他の注文が有るか否かを値引状況管理DB124を参照することにより確認する(S301)。
【0109】
他の注文が存在しない場合には(S301:No)、請求金額決定部104−2は、S202と同様に、新規の注文の実請求金額を基準請求金額と同一の金額に決定する(S302)。そして、請求金額決定部104−2は、S205と同様に、当該注文の注文番号と、決定した実請求金額とを対応づけて値引状況管理DB124に記録する(S305)。
【0110】
一方、他の注文が存在する場合には(S301:Yes)、請求金額決定部104−2は、まず、新規の注文に関する基準請求金額からの値引き額を当該他の注文の値引き額よりも大きい金額に決定する(S303)。
【0111】
続いて、請求金額決定部104−2は、S303で決定した値引き額を新規の注文の基準請求金額から減額した金額を、新規の注文の実請求金額に決定する(S304)。その後、請求金額決定部104−2は、S305の動作を行う。
【0112】
[2−2−3.効果]
以上、例えば
図14、
図17等を参照して説明したように、第2の実施形態による請求金額決定サーバ10は、新規の注文に対応する事業者が有する複数の仮想口座に対応づけられている複数の注文のうち、新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の実請求金額を当該他の注文の実請求金額よりも小さい金額に決定する。
【0113】
このため、一人の事業者が有する複数の仮想口座に対応づけられている複数の注文の各々の実請求金額が一意になるように決定される。従って、ある事業者が有する複数の仮想口座のうちいずれかに対して振込みがなされた際に、当該事業者は、自己が受注している複数の注文のうちいずれに対する振込みがなされたかを、振り込まれた金額により特定することが可能である。
【0114】
例えば一人の事業者が100個の仮想口座の口座番号を有しており、かつ、1日に100件超の注文がなされる場合などには、同一の仮想口座に対して同一の基準請求金額の複数の注文が対応づけられる。第2の実施形態は、このような複数の注文が対応づけられた仮想口座に対して振込みがなされた際に、振込依頼人および当該振込依頼人が支払いを意図した注文の両方を特定することができる。
【0115】
<<3.ハードウェア構成>>
次に、各実施形態に共通する請求金額決定サーバ10のハードウェア構成について、
図18を参照して説明する。
図18に示したように、請求金額決定サーバ10は、CPU150、ROM(Read Only Memory)152、RAM154、内部バス156、入出力インターフェース158、HDD(Hard Disk Drive)160、およびネットワークインターフェース162を備える。
【0116】
<3−1.CPU150>
CPU150は、演算処理装置および制御装置として機能し、各種プログラムに従って請求金額決定サーバ10内の動作全般を制御する。また、CPU150は、請求金額決定サーバ10において制御部100−1または制御部100−2の機能を実現する。なお、CPU150は、マイクロプロセッサなどのプロセッサにより構成される。
【0117】
<3−2.ROM152>
ROM152は、CPU150が使用するプログラムや演算パラメータ等を記憶する。
【0118】
<3−3.RAM154>
RAM154は、CPU150の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一時記憶する。
【0119】
<3−4.内部バス156>
内部バス156は、CPUバスなどから構成される。この内部バス156は、CPU150、ROM152、およびRAM154を相互に接続する。
【0120】
<3−5.入出力インターフェース158>
入出力インターフェース158は、HDD160、およびネットワークインターフェース162を、内部バス156と接続する。例えばHDD160は、この入出力インターフェース158および内部バス156を介して、RAM154などとの間でデータをやり取りする。
【0121】
<3−6.HDD160>
HDD160は、記憶部122として機能する、データ格納用の装置である。このHDD160は、例えば、記憶媒体、記憶媒体にデータを記録する記録装置、記憶媒体からデータを読み出す読出し装置、および記憶媒体に記録されたデータを削除する削除装置などを含む。また、HDD160は、CPU150が実行するプログラムや各種データを格納する。
【0122】
<3−7.ネットワークインターフェース162>
ネットワークインターフェース162は、例えばインターネットなどの通信網に接続するための通信デバイス等で構成された通信インターフェースである。このネットワークインターフェース162は、通信部120として機能する。なお、ネットワークインターフェース162は、無線LAN対応通信装置、LTE(Long Term Evolution)対応通信装置、または有線による通信を行うワイヤー通信装置であってもよい。
【0123】
<<4.変形例>>
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
【0124】
<4−1.変形例1>
例えば、上記の説明では、請求金額決定サーバ10は、新規の注文に対して決定された値引き額を顧客に通知するためのゲーム画面を顧客端末24に表示させる例について説明したが、かかる例に限定されない。例えば、請求金額決定サーバ10は、新規の注文の実請求金額(あるいは、値引き額)を決定する前にゲーム画面を顧客端末24に表示させてもよい。さらに、請求金額決定サーバ10は、該当の注文の値引き額を決定する際に、表示されたゲーム画面において顧客により実行されたゲームの結果を反映させて決定してもよい。
【0125】
<4−2.変形例2>
また、上述した各実施形態では、請求金額決定サーバ10が、発生済みの複数の注文のうち、新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の実請求金額を基準請求金額と異なる金額に決定する例について説明したが、本発明はかかる例に限定されない。
【0126】
変形例として、例えば、請求金額決定サーバ10は、発生済みの複数の注文のうち、新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の請求金額の振込期間を当該他の注文の請求金額の振込期間と異ならせるように決定することも可能である。例えば、請求金額決定サーバ10は、上記の場合には、注文時に顧客により指定された商品送付希望日が遅い注文ほど、注文の請求金額の振込期間が遅くなるように決定してもよい。
【0127】
この変形例によれば、基準請求金額が同じである複数の注文の各々の振込期間が一意になるように決定される。このため、注文の請求金額が振込依頼人により振り込まれた際に、振込受取人は、振り込まれた金額および振り込まれた日時から、振込依頼人が支払を意図した注文の特定を容易化することができる。
【0128】
<4−3.変形例3>
また、上記の各実施形態による請求金額決定サーバ10は、EC決済の場面に適用される例を中心として説明したが、本発明はかかる例に限定されない。例えば、請求金額決定サーバ10は、大学入学金の振込み、海外送金、または電子マネーチャージなどの資金移動や通貨変換の場面にも適用可能である。
【0129】
<4−4.変形例4>
また、本実施形態によれば、CPU150、ROM152、およびRAM154などのハードウェアを、上述した請求金額決定サーバ10の各構成と同等の機能を発揮させるためのコンピュータプログラムも提供可能である。また、該コンピュータプログラムが記録された記録媒体も提供される。