JP6387742B2 - 情報処理装置、及びプログラム - Google Patents
情報処理装置、及びプログラム Download PDFInfo
- Publication number
- JP6387742B2 JP6387742B2 JP2014172572A JP2014172572A JP6387742B2 JP 6387742 B2 JP6387742 B2 JP 6387742B2 JP 2014172572 A JP2014172572 A JP 2014172572A JP 2014172572 A JP2014172572 A JP 2014172572A JP 6387742 B2 JP6387742 B2 JP 6387742B2
- Authority
- JP
- Japan
- Prior art keywords
- order
- amount
- billing amount
- actual
- billing
- 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.)
- Active
Links
Images
Description
本発明は、情報処理装置、及びプログラムに関する。
従来、金融機関では、多数の振込取引が処理されている。この振込取引では、振込依頼人の情報がなくても取引が可能であるので、振込依頼人を特定する作業を容易化するための技術が各種提案されている。例えば、特許文献１には、振込確認処理を容易にするために、個々の振込依頼人に対して異なる振込先口座を設ける技術が提案されている。
ところで、注文ごとの請求金額が支払われる場面では、支払われた金額がいずれの注文を対象とするかを容易に特定可能であることが望ましい。
このような場面に上記の特許文献１に記載の技術を適用することを想定すると、上記の技術では、同一の内容の注文では、同じ金額が請求される。このため、例えば、１人の人物により同一の内容の注文が２回なされ、かつ、一つの注文に対する支払がなされた場合には、上記の技術では、いずれの注文を対象とする支払がなされたかを特定することができない。すなわち、上記の技術では、支払対象の注文を特定することが容易ではない。
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、請求された金額が支払われる場面での支払対象の注文の特定を容易化することが可能な、新規かつ改良された情報処理装置、及びプログラムを提供することにある。
上記課題を解決するために、本発明のある観点によれば、発生済みの複数の注文のうち第１の注文と前記注文の対象商品に関する請求金額である基準請求金額が同一である第２の注文が記憶媒体に有るか否かをプロセッサにより確認する注文確認部と、前記注文確認部により前記第２の注文が有ることが確認された場合に、前記第１の注文の実際の請求金額である実請求金額を、前記基準請求金額よりも、所定の範囲内でランダムに決定された額だけ小さい金額に前記プロセッサにより決定する請求金額決定部と、を備え、前記注文確認部により確認される前記複数の注文の各々および、前記請求金額決定部により前記実請求金額を決定される前記第１の注文は、支払用の複数の口座のうち互いに異なる口座のいずれかに対応づけられている、情報処理装置が提供される。
前記請求金額決定部は、前記第１の注文の実請求金額を、さらに前記第２の注文の実請求金額と異なる金額に決定してもよい。
前記第１の注文は、前記第２の注文よりも後に発生した注文であり、前記請求金額決定部は、前記第１の注文の実請求金額を、前記第２の注文の実請求金額よりも小さい金額に決定してもよい。
前記注文確認部は、前記第２の注文が、前記第１の注文の発生時において未決済の注文であるか否かを確認してもよい。
前記注文確認部は、前記第２の注文が、前記第１の注文の注文日から所定の期間内に発生した注文であるか否かを確認してもよい。
前記情報処理装置は、前記請求金額決定部により決定された前記第１の注文の実請求金額を利用者に通知するためのイベントの表示制御をするイベント制御部をさらに備えてもよい。
また、上記課題を解決するために、本発明の別の観点によれば、コンピュータを、発生済みの複数の注文のうち第１の注文と前記注文の対象商品に関する請求金額である基準請求金額が同一である第２の注文が記憶媒体に有るか否かをプロセッサにより確認する注文確認部と、前記注文確認部により前記第２の注文が有ることが確認された場合に、前記第１の注文の実際の請求金額である実請求金額を、前記基準請求金額よりも、所定の範囲内でランダムに決定された額だけ小さい金額に前記プロセッサにより決定する請求金額決定部と、を備え、前記注文確認部により確認される前記複数の注文の各々および、前記請求金額決定部により前記実請求金額を決定される前記第１の注文は、支払用の複数の口座のうち互いに異なる口座のいずれかに対応づけられている、情報処理装置、として機能させるための、プログラムが提供される。
以上説明したように本発明によれば、請求された金額が支払われる場面での支払対象の注文の特定を容易化することができる。
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
また、本明細書及び図面において、実質的に同一の機能構成を有する複数の構成要素を、同一の符号の後に異なるアルファベットを付して区別する場合もある。例えば、実質的に同一の機能構成を有する複数の構成を、必要に応じて通信網２６ａおよび通信網２６ｂのように区別する。ただし、実質的に同一の機能構成を有する複数の構成要素の各々を特に区別する必要がない場合、同一符号のみを付する。例えば、通信網２６ａおよび通信網２６ｂを特に区別する必要が無い場合には、単に通信網２６と称する。
また、以下に示す項目順序に従って当該「発明を実施するための形態」を説明する。
１．情報処理システムの基本構成
１−１．基本構成
１−２．課題の整理
２．各実施形態の詳細な説明
２−１．第１の実施形態
２−２．第２の実施形態
３．ハードウェア構成
４．変形例
１．情報処理システムの基本構成
１−１．基本構成
１−２．課題の整理
２．各実施形態の詳細な説明
２−１．第１の実施形態
２−２．第２の実施形態
３．ハードウェア構成
４．変形例
＜＜１．情報処理システムの基本構成＞＞
＜１−１．基本構成＞
本発明は、一例として「２−１．第１の実施形態」〜「２−２．第２の実施形態」において詳細に説明するように、多様な形態で実施され得る。最初に、本発明の各実施形態に共通する情報処理システムの基本構成について、図１を参照して説明する。
＜１−１．基本構成＞
本発明は、一例として「２−１．第１の実施形態」〜「２−２．第２の実施形態」において詳細に説明するように、多様な形態で実施され得る。最初に、本発明の各実施形態に共通する情報処理システムの基本構成について、図１を参照して説明する。
図１に示したように、各実施形態に共通する情報処理システムは、請求金額決定サーバ１０、ＥＣ決済サーバ２０、口座管理ＤＢ２２、顧客端末２４、および通信網２６を含む。
なお、本情報処理システムは、金融機関により提供される仮想口座サービスを利用することを想定する。ここで、仮想口座サービスの内容について説明する。
［１−１−１．仮想口座サービス］
仮想口座サービスは、金融機関において開設されている個々の実口座に対応づけて複数の仮の口座（仮想口座）を設けることが可能なサービスである。なお、実口座の利用者は、例えば、後述するＥＣ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ）サイトで商品を出品している企業のような、多数の人物から振込みがなされる事業者などである。
仮想口座サービスは、金融機関において開設されている個々の実口座に対応づけて複数の仮の口座（仮想口座）を設けることが可能なサービスである。なお、実口座の利用者は、例えば、後述するＥＣ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ）サイトで商品を出品している企業のような、多数の人物から振込みがなされる事業者などである。
また、仮想口座は、実口座を有する事業者により、基本的には、当該事業者の顧客一人ひとりに対して一意に割り当てられる口座である。但し、各事業者が有する仮想口座の数は有限であるので、事業者は、例えば顧客の人数が増加した場合などには、仮想口座の口座番号を使い回すことにより、顧客に対して仮想口座を割り当てる。例えば、事業者は、顧客により注文がなされる度に、当該事業者が有するいずれかの仮想口座の口座番号を選択し、そして、選択した口座番号と当該注文とを対応づけて管理する。なお、事業者は、選択した口座番号を当該注文の振込用口座の口座番号として、当該注文を行った顧客に対して案内する。
［１−１−２．ＥＣ決済サーバ２０］
ＥＣ決済サーバ２０は、ＥＣ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ）サイトを管理するサーバである。このＥＣサイトでは、複数の事業者により商品が出品されており、また、顧客は、出品されている商品をＥＣサイト上で注文することが可能である。
ＥＣ決済サーバ２０は、ＥＣ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ）サイトを管理するサーバである。このＥＣサイトでは、複数の事業者により商品が出品されており、また、顧客は、出品されている商品をＥＣサイト上で注文することが可能である。
また、ＥＣ決済サーバ２０は、ＥＣサイトにおいて顧客により注文された内容に基づいて注文データを生成する。ここで、図２を参照して、注文データの構成例（注文データ３０）について説明する。図２に示したように、例えば、注文データ３０では、注文番号３００、商品名３０２、請求金額３０４、および顧客名３０６が対応づけて記録される。ここで、注文番号３００には、発生した各注文を識別するための注文番号が記録される。また、商品名３０２には、該当の注文番号で注文された商品の名前が記録される。また、請求金額３０４には、該当の注文番号で注文された商品に関して例えばＥＣサイト上で表示されている請求金額（以下、基準請求金額とも称する）が記録される。また、顧客名３０６には、該当の注文番号に対応する注文を行った顧客の名前が記録される。
なお、図２では、商品名３０２に１個の商品の名前だけが記録される例を示しているが、かかる例に限定されない。例えば、該当の注文番号で複数の商品が一括に注文された場合には、注文された全ての商品の名前が商品名３０２に記録される。また、複数の商品が一括に注文された場合には、請求金額３０４には、注文された全ての商品の合計の請求金額が記録される。
また、ＥＣ決済サーバ２０は、詳細については後述するように、口座管理ＤＢ２２を参照し、そして、発生した注文の注文番号と、当該注文の振込み先口座である仮想口座の口座番号とを所定のルールに沿って対応づける。
また、ＥＣ決済サーバ２０は、通信網２６ａを介して、請求金額決定サーバ１０、または口座管理ＤＢ２２との間で各種情報を送受信することが可能である。例えば、ＥＣ決済サーバ２０は、生成した注文データと、当該注文データが示す注文に対応づけた仮想口座の口座番号とを請求金額決定サーバ１０、または口座管理ＤＢ２２へ送信することが可能である。
［１−１−３．顧客端末２４］
顧客端末２４は、例えばＥＣサイトに会員登録している顧客により使用される情報処理端末である。この顧客端末２４は、例えばＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、タブレット端末、またはスマートフォンなどであってもよい。
顧客端末２４は、例えばＥＣサイトに会員登録している顧客により使用される情報処理端末である。この顧客端末２４は、例えばＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、タブレット端末、またはスマートフォンなどであってもよい。
顧客端末２４は、通信網２６ｂを介して、例えばＥＣサイトのＷｅｂページをＥＣ決済サーバ２０から受信し、そして、表示画面に表示することが可能である。また、顧客端末２４は、ＥＣサイトのＷｅｂページ上で顧客により入力された注文内容をＥＣ決済サーバ２０へ送信することが可能である。
［１−１−４．口座管理ＤＢ２２］
口座管理ＤＢ２２は、実口座および仮想口座を対応づけて管理するためのデータベースである。この口座管理ＤＢ２２は、注文データと、当該注文データが示す注文に対応づけられた仮想口座の口座番号とをＥＣ決済サーバ２０から受信した場合には、受信した注文データに含まれる注文番号と、仮想口座の口座番号とを対応づけて記憶する。
口座管理ＤＢ２２は、実口座および仮想口座を対応づけて管理するためのデータベースである。この口座管理ＤＢ２２は、注文データと、当該注文データが示す注文に対応づけられた仮想口座の口座番号とをＥＣ決済サーバ２０から受信した場合には、受信した注文データに含まれる注文番号と、仮想口座の口座番号とを対応づけて記憶する。
ここで、図３を参照して、口座管理ＤＢ２２の構成例について説明する。図３に示したように、例えば、口座管理ＤＢ２２では、実口座番号２２０、仮想口座番号２２２、注文番号２２４、および請求金額２２６が対応づけて記憶される。ここで、実口座番号２２０には、個々の実口座の口座番号が記録される。また、仮想口座番号２２２には、該当の実口座に対応づけられている複数の仮想口座の各々の口座番号が記録される。また、注文番号２２４には、該当の仮想口座に対応づけられた注文の注文番号が記録される。また、請求金額２２６には、該当の仮想口座に対応づけられた注文の請求金額が記録される。
［１−１−５．請求金額決定サーバ１０］
請求金額決定サーバ１０は、本発明における情報処理装置の一例である。請求金額決定サーバ１０は、後述するように、ＥＣ決済サーバ２０から受信される注文データが示す注文の実請求金額、つまり実際の請求金額を決定するための装置である。
請求金額決定サーバ１０は、本発明における情報処理装置の一例である。請求金額決定サーバ１０は、後述するように、ＥＣ決済サーバ２０から受信される注文データが示す注文の実請求金額、つまり実際の請求金額を決定するための装置である。
また、後述するように、請求金額決定サーバ１０は、決定した注文の実請求金額、および該当の注文の振込み先口座の口座番号が記載された払込票を、当該注文を行った顧客宛てに送付させることが可能である。
なお、各実施形態では、例えば図４に示したような流れで、注文された商品の決済が行われることを想定する。図４に示したように、まず、ＥＣサイトで注文を行った顧客は、注文後に送付される払込票を確認し、そして、例えばＡＴＭ（Ａｕｔｏｍａｔｅｄ Ｔｅｌｌｅｒ Ｍａｃｈｉｎｅ）、金融機関の窓口、またはインターネットバンキングなどの金融機関のサービスを介して、払込票に記載されている仮想口座の口座番号に対して、払込票に記載されている請求金額を振り込む。なお、仮想口座に対して振り込まれた金額は、仮想口座経由で実口座に入金される。そして、例えば事業者などの実口座の名義人は、該当の仮想口座に対する入金結果を確認することにより、該当の注文に対する支払いが正しくなされたか否かを確認する。
［１−１−６．通信網２６］
通信網２６は、通信網２６に接続されている装置から送信される情報の有線、または無線の伝送路である。例えば、通信網２６は、電話回線網、インターネット、衛星通信網などの公衆回線網や、Ｅｔｈｅｒｎｅｔ（登録商標）を含む各種のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などを含む。また、通信網２６は、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ−Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）などの専用回線網を含んでもよい。
通信網２６は、通信網２６に接続されている装置から送信される情報の有線、または無線の伝送路である。例えば、通信網２６は、電話回線網、インターネット、衛星通信網などの公衆回線網や、Ｅｔｈｅｒｎｅｔ（登録商標）を含む各種のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などを含む。また、通信網２６は、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ−Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）などの専用回線網を含んでもよい。
なお、本実施形態による情報処理システムは、上述した構成に限定されない。例えば、口座管理ＤＢ２２は独立した装置として構成される代わりに、請求金額決定サーバ１０、またはＥＣ決済サーバ２０に記憶されてもよい。また、請求金額決定サーバ１０とＥＣ決済サーバ２０は独立した装置として構成される代わりに、一体の装置として構成されてもよい。
＜１−２．課題の整理＞
ところで、上述したように、事業者が有する仮想口座の数は有限であるので、顧客一人ひとりに対して仮想口座を一意に割り当てることは難しい。このため、事業者は、仮想口座の口座番号を使い回すこと（プーリング）により、注文を行った顧客に対して仮想口座の口座番号を割り当てることが多い。
ところで、上述したように、事業者が有する仮想口座の数は有限であるので、顧客一人ひとりに対して仮想口座を一意に割り当てることは難しい。このため、事業者は、仮想口座の口座番号を使い回すこと（プーリング）により、注文を行った顧客に対して仮想口座の口座番号を割り当てることが多い。
その結果、例えば同じ顧客が同じ事業者が出品している同じ商品を注文する場合であっても、顧客に対して割り当てられる仮想口座の口座番号は、注文の度に異なる可能性がある。このため、特に複数回注文した顧客は、自己の注文の請求金額を振込み先口座を間違えて振り込んでしまう恐れがある。例えば、顧客は、今回の注文の請求金額を、前回注文時の振込み先口座に振込んでしまう恐れがある。
そして、顧客により口座番号を間違えて振込みが行われた場合には、例えば事業者などの振込受取人は、振込間違いの発生を検知できない恐れがある。
ここで、図５を参照して、上記の内容についてより詳細に説明する。なお、図５に示した例では、顧客Ａが同一の請求金額（つまり「３００，０００円」）の注文を２つ（「注文１」および「注文２」）行い、また、顧客Ｂが、「注文１」と同一の請求金額の注文を１つ（「注文３」）行った場合を前提とする。また、顧客Ａの２つの注文に対応づけられている仮想口座は、互いに異なっていることを前提とする。
この場合において、例えば顧客Ａが「注文１」の請求金額を、「注文２」に対応づけられた仮想口座４００ｂに誤って振り込んだ場合には、請求金額が同一であるので、振込受取人は振込間違いに気付くことができない。また、顧客Ｂが「注文３」の請求金額を、「注文１」に対応づけられた仮想口座４００ａに誤って振り込んだ場合にも、請求金額が同一であるので、振込受取人は振込間違いに気付くことができず、正しい振込みがなされたと判断してしまう。
そして、上記の理由により、振込依頼人が振込受取人に対して例えば「振込をしたにも関わらず商品が届かない」などのクレームを行わない限り、振込間違いが検知できないという問題が生じ得る。
そこで、上記事情を一着眼点にして本発明による請求金額決定サーバ１０を創作するに至った。本発明による請求金額決定サーバ１０は、注文の請求金額が振込依頼人により振り込まれる際に、振込依頼人が支払を意図した注文の特定を容易化することが可能である。以下、このような本発明の実施形態について順次詳細に説明する。
＜＜２．実施形態の詳細な説明＞＞
＜２−１．第１の実施形態＞
まず、第１の実施形態について説明する。後述するように、第１の実施形態によれば、新規の注文の基準請求金額と同一である注文が発生済みである場合には、新規の注文の実請求金額を基準請求金額からランダムに値引くことにより、各注文の実請求金額をできるだけ一意に決定することが可能である。
＜２−１．第１の実施形態＞
まず、第１の実施形態について説明する。後述するように、第１の実施形態によれば、新規の注文の基準請求金額と同一である注文が発生済みである場合には、新規の注文の実請求金額を基準請求金額からランダムに値引くことにより、各注文の実請求金額をできるだけ一意に決定することが可能である。
［２−１−１．構成］
最初に、第１の実施形態による構成について説明する。図６は、第１の実施形態による請求金額決定サーバ１０−１の構成を示した機能ブロック図である。図６に示したように、請求金額決定サーバ１０−１は、制御部１００−１、通信部１２０、および記憶部１２２を有する。
最初に、第１の実施形態による構成について説明する。図６は、第１の実施形態による請求金額決定サーバ１０−１の構成を示した機能ブロック図である。図６に示したように、請求金額決定サーバ１０−１は、制御部１００−１、通信部１２０、および記憶部１２２を有する。
（２−１−１−１．制御部１００−１）
制御部１００−１は、請求金額決定サーバ１０−１に内蔵される、後述するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１５０、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１５４などのハードウェアを用いて、請求金額決定サーバ１０−１の動作を全般的に制御する。また、図６に示したように、制御部１００−１は、注文確認部１０２−１、請求金額決定部１０４−１、イベント制御部１０６、および払込票生成部１０８を有する。
制御部１００−１は、請求金額決定サーバ１０−１に内蔵される、後述するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１５０、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１５４などのハードウェアを用いて、請求金額決定サーバ１０−１の動作を全般的に制御する。また、図６に示したように、制御部１００−１は、注文確認部１０２−１、請求金額決定部１０４−１、イベント制御部１０６、および払込票生成部１０８を有する。
（２−１−１−２．注文確認部１０２−１）
注文確認部１０２−１は、発生済みの複数の注文のうち、ＥＣ決済サーバ２０から新たに受信された注文データが示す注文（以下、新規の注文とも称する）と基準請求金額が同一である他の注文が有るか否かを、例えば値引状況管理ＤＢ１２４を参照することにより確認する。ここで、新規の注文は、本発明における第１の注文の一例であり、また、上記の「他の注文」は、本発明における第２の注文の一例である。
注文確認部１０２−１は、発生済みの複数の注文のうち、ＥＣ決済サーバ２０から新たに受信された注文データが示す注文（以下、新規の注文とも称する）と基準請求金額が同一である他の注文が有るか否かを、例えば値引状況管理ＤＢ１２４を参照することにより確認する。ここで、新規の注文は、本発明における第１の注文の一例であり、また、上記の「他の注文」は、本発明における第２の注文の一例である。
例えば、注文確認部１０２−１は、発生済みの複数の注文のうち、新規の注文と基準請求金額が同一であり、かつ、新規の注文の発生時において未決済である他の注文が有るか否かを値引状況管理ＤＢ１２４を参照することにより確認する。
‐値引状況管理ＤＢ１２４
ここで、図７を参照して、値引状況管理ＤＢ１２４の構成例について説明する。図７に示したように、例えば、値引状況管理ＤＢ１２４では、仮想口座番号１２４０、注文番号１２４２、基準請求金額１２４４、特別値引額１２４６、実請求金額１２４８、および決済状況１２５０が対応づけて記録される。ここで、仮想口座番号１２４０には、個々の仮想口座の口座番号が記録される。また、注文番号１２４２には、該当の仮想口座に対応づけられた注文の注文番号が記録される。また、基準請求金額１２４４には、該当の注文の基準請求金額が記録される。また、特別値引額１２４６には、該当の注文に関して、後述する請求金額決定部１０４−１により決定される値引き額が記録される。また、実請求金額１２４８には、該当の注文に関して、請求金額決定部１０４−１により決定される実請求金額が記録される。また、決済状況１２５０には、該当の注文に関する決済状況（「未決済」や「決済済み」など）が記録される。
ここで、図７を参照して、値引状況管理ＤＢ１２４の構成例について説明する。図７に示したように、例えば、値引状況管理ＤＢ１２４では、仮想口座番号１２４０、注文番号１２４２、基準請求金額１２４４、特別値引額１２４６、実請求金額１２４８、および決済状況１２５０が対応づけて記録される。ここで、仮想口座番号１２４０には、個々の仮想口座の口座番号が記録される。また、注文番号１２４２には、該当の仮想口座に対応づけられた注文の注文番号が記録される。また、基準請求金額１２４４には、該当の注文の基準請求金額が記録される。また、特別値引額１２４６には、該当の注文に関して、後述する請求金額決定部１０４−１により決定される値引き額が記録される。また、実請求金額１２４８には、該当の注文に関して、請求金額決定部１０４−１により決定される実請求金額が記録される。また、決済状況１２５０には、該当の注文に関する決済状況（「未決済」や「決済済み」など）が記録される。
例えば、図７に示した例において、注文番号が「１１１１１１」である注文の基準請求金額は「３００，０００円」であり、また、当該注文は現在「未決済」である。このため、注文確認部１０２−１は、仮に新規の注文の基準請求金額が「３００，０００円」である場合には、新規の注文と基準請求金額が同一であり、かつ未決済の注文が存在すると判定する。
なお、変形例として、注文確認部１０２−１は、新規の注文の注文日から所定の期間内において発生した複数の注文に限定して、新規の注文と基準請求金額が同一である他の注文が有るか否かを確認してもよい。
（２−１−１−３．請求金額決定部１０４−１）
‐請求金額の決定
請求金額決定部１０４−１は、注文確認部１０２−１により新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の実請求金額を基準請求金額と異なる金額に決定する。より具体的には、請求金額決定部１０４−１は、上記の場合には、新規の注文の実請求金額を基準請求金額よりも所定の範囲内で小さい金額にランダムに決定する。
‐請求金額の決定
請求金額決定部１０４−１は、注文確認部１０２−１により新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の実請求金額を基準請求金額と異なる金額に決定する。より具体的には、請求金額決定部１０４−１は、上記の場合には、新規の注文の実請求金額を基準請求金額よりも所定の範囲内で小さい金額にランダムに決定する。
例えば、請求金額決定部１０４−１は、上記の場合には、まず、新規の注文に関する基準請求金額からの値引き額を、例えば基準請求金額の１％以内などの所定の範囲内でランダムに決定する。そして、請求金額決定部１０４−１は、決定した値引き額を新規の注文の基準請求金額から減額することにより、新規の注文の実請求金額を決定する。
ここで、図８を参照して、上記の機能についてより詳細に説明する。なお、図８では、「注文１」が注文された後に、「注文２」または「注文３」が顧客により注文されたことを前提とする。
図８に示したように、「注文１」と「注文２」の基準請求金額は同一である。このため、「注文２」が顧客Ａにより注文された場合には、請求金額決定部１０４−１は、「注文２」の実請求金額を基準請求金額（「３００，０００円」）よりも小さい金額（例えば、「２９９，９９９円」）に決定する。
同様に、「注文１」と「注文３」の基準請求金額は同一である。このため、「注文３」が顧客Ｂにより注文された場合には、請求金額決定部１０４−１は、「注文３」の実請求金額を基準請求金額（「３００，０００円」）よりも小さい金額（例えば、「２９９，９９５円」）に決定する。
この決定例によれば、例えば、顧客Ａが「注文１」の請求金額を、「注文２」に対応づけられた仮想口座４００ｂに誤って振り込んだ場合には、請求金額が異なるので、決済システムにより振込誤りとして検知される。このため、振込受取人は、顧客Ａによる振込誤りに気付くことができる。
また、顧客Ｂが「注文３」の請求金額を、「注文１」に対応づけられた仮想口座４００ａに誤って振り込んだ場合にも、請求金額が異なるので、決済システムにより振込誤りとして検知される。このため、振込受取人は、振込誤りに気付くことができる。さらに、振込受取人は、振り込まれた金額（つまり、「２９９，９９５円」）から、当該振込の依頼人は「注文３」を注文した人物、つまり顧客Ｂである可能性が高いことを推測することができる。
‐請求金額の記録
また、請求金額決定部１０４−１は、決定した実請求金額を値引状況管理ＤＢ１２４に記録することが可能である。例えば、注文番号が「１１１１８８」である新規の注文の実請求金額が「２９９，９９７円」と決定されたとする。この場合、例えば図９において一点鎖線で示したように、請求金額決定部１０４−１は、決定した新規の注文の実請求金額を、対応する仮想口座の口座番号である「１０００００８」および当該注文の注文番号と対応づけて値引状況管理ＤＢ１２４に追加記録する。
また、請求金額決定部１０４−１は、決定した実請求金額を値引状況管理ＤＢ１２４に記録することが可能である。例えば、注文番号が「１１１１８８」である新規の注文の実請求金額が「２９９，９９７円」と決定されたとする。この場合、例えば図９において一点鎖線で示したように、請求金額決定部１０４−１は、決定した新規の注文の実請求金額を、対応する仮想口座の口座番号である「１０００００８」および当該注文の注文番号と対応づけて値引状況管理ＤＢ１２４に追加記録する。
（２−１−１−４．イベント制御部１０６）
イベント制御部１０６は、請求金額決定部１０４−１により決定された新規の注文の値引き額を顧客に通知するためのイベントの表示制御をする。例えば、イベント制御部１０６は、新規の注文に対して決定された値引き額を顧客に通知するためのゲーム画面を表示させる指示情報をＥＣ決済サーバ２０へ通信部１２０に送信させる。ここで、上記の指示情報は、ゲーム画面を構成する全ての表示情報を含んでいてもよいし、または、決定された値引き額だけを含んでいてもよい。
イベント制御部１０６は、請求金額決定部１０４−１により決定された新規の注文の値引き額を顧客に通知するためのイベントの表示制御をする。例えば、イベント制御部１０６は、新規の注文に対して決定された値引き額を顧客に通知するためのゲーム画面を表示させる指示情報をＥＣ決済サーバ２０へ通信部１２０に送信させる。ここで、上記の指示情報は、ゲーム画面を構成する全ての表示情報を含んでいてもよいし、または、決定された値引き額だけを含んでいてもよい。
なお、ＥＣ決済サーバ２０は、上記の指示情報を受信した場合には、例えば図１０に示したようなゲーム画面５０を顧客端末２４に表示させる。このゲーム画面５０は、３択ゲームの表示例である。
仮に、請求金額決定部１０４−１により新規の注文の値引き額が「３円」と決定されたとする。この場合、ゲーム画面５０において顧客によりいずれかのボタン５００が選択されると、顧客端末２４は、例えば「ご当選おめでとうございます。サイト表示金額から３円を値引きします。」、あるいは「３等当選おめでとうございます。サイト表示金額から３円を値引きします。」など、決定された値引き額を示すテキストを表示画面に表示する。
この表示例による効果として以下が挙げられる。上述したように、基準請求金額が同じであっても、通常、請求金額決定部１０４−１により決定される値引き額は注文ごとに異なる。つまり、顧客が同じ商品を複数回注文した場合や、複数の顧客が同じ商品を注文した場合では、注文の度に値引き額が異なり得る。このため、仮に何の事前通知もなく、決定された値引き額（あるいは、実請求金額）だけが顧客に通知され、かつ、同一の顧客の複数の注文間または複数の顧客の注文間で値引き額が異なっていることを顧客が知った場合には、値引き額の決定に関して顧客は違和感や、不公平感を抱く恐れがある。一方、上記の表示例によれば、ゲームなどのイベントの実行を通して値引き額が決定されたように顧客に認識される可能性が高いので、決定された値引き額に関して違和感や不公平感を顧客が抱く恐れはほとんど無いと考えられる。
（２−１−１−５．払込票生成部１０８）
払込票生成部１０８は、請求金額決定部１０４−１により決定された実請求金額が記録された払込票を生成する。
払込票生成部１０８は、請求金額決定部１０４−１により決定された実請求金額が記録された払込票を生成する。
ここで、図１１を参照して、払込票の構成例（払込票６０）について説明する。図１１に示したように、払込票６０は、例えば、振込み先口座番号６００、および振込金額６０２を含む。ここで、振込み先口座番号６００には、例えばＥＣ決済サーバ２０から受信される該当の注文に対応づけられた仮想口座の口座番号が記録される。また、振込金額６０２には、請求金額決定部１０４−１により決定された該当の注文の実請求金額が記録される。
また、払込票生成部１０８は、生成した払込票を、注文した顧客宛てに例えば電子メールや郵送などにより送付させる。なお、払込票が送付された顧客は、例えばＡＴＭなどの金融機関のサービスを利用して、払込票に記載されている口座番号に、払込票に記載されている振込金額を正確に振り込むことが要求される。
（２−１−１−６．通信部１２０）
通信部１２０は、例えば通信網２６を介して、他の装置との間で情報の送受信を行う。例えば、通信部１２０は、ＥＣ決済サーバ２０から注文データを受信する。また、通信部１２０は、払込票生成部１０８の制御により、生成された払込票を、当該払込票に対応する注文を行った顧客のメールアドレス宛てに送信する。
通信部１２０は、例えば通信網２６を介して、他の装置との間で情報の送受信を行う。例えば、通信部１２０は、ＥＣ決済サーバ２０から注文データを受信する。また、通信部１２０は、払込票生成部１０８の制御により、生成された払込票を、当該払込票に対応する注文を行った顧客のメールアドレス宛てに送信する。
（２−１−１−７．記憶部１２２）
記憶部１２２は、例えば値引状況管理ＤＢ１２４などの、各種のデータを記憶することが可能である。
記憶部１２２は、例えば値引状況管理ＤＢ１２４などの、各種のデータを記憶することが可能である。
なお、本実施形態による請求金額決定サーバ１０の構成は、上述した構成に限定されない。例えば、値引状況管理ＤＢ１２４は、記憶部１２２に記憶される代わりに、請求金額決定サーバ１０と通信可能な他の装置に記憶されることも可能である。
［２−１−２．動作］
以上、第１の実施形態による構成について説明した。続いて、第１の実施形態による動作について説明する。なお、ここでは、顧客がＥＣサイト上で商品の注文を行う場面における動作の例について説明する。
以上、第１の実施形態による構成について説明した。続いて、第１の実施形態による動作について説明する。なお、ここでは、顧客がＥＣサイト上で商品の注文を行う場面における動作の例について説明する。
（２−１−２−１．全体的な動作）
図１２は、第１の実施形態による全体的な動作を示したシーケンス図である。図１２に示したように、まず、顧客端末２４は、顧客の操作に基づいてＥＣ決済サーバ２０へ接続し、そして、ＥＣサイトのＷｅｂページをＥＣ決済サーバ２０から受信する。
図１２は、第１の実施形態による全体的な動作を示したシーケンス図である。図１２に示したように、まず、顧客端末２４は、顧客の操作に基づいてＥＣ決済サーバ２０へ接続し、そして、ＥＣサイトのＷｅｂページをＥＣ決済サーバ２０から受信する。
その後、顧客は、受信されたＷｅｂページにおいて商品の注文の入力を行う。そして、顧客端末２４は、入力された内容をＥＣ決済サーバ２０へ送信する（Ｓ１０１）。
その後、ＥＣ決済サーバ２０は、Ｓ１０１で受信された入力情報に基いて注文データを生成する（Ｓ１０２）。
そして、ＥＣ決済サーバ２０は、口座管理ＤＢ２２を参照し、そして、所定のルールに沿って、Ｓ１０１でなされた注文と対応づける仮想口座の口座番号を選出する。そして、ＥＣ決済サーバ２０は、Ｓ１０２で生成した注文データに含まれる注文番号と、選出した仮想口座の口座番号とを口座管理ＤＢ２２へ送信する。その後、口座管理ＤＢ２２は、受信された注文番号および口座番号を対応づけて記憶する（Ｓ１０３）。これにより、注文番号と仮想口座の口座番号とが対応づけられる。
その後、ＥＣ決済サーバ２０は、Ｓ１０３で対応づけられた注文番号および仮想口座の口座番号を請求金額決定サーバ１０−１へ送信する（Ｓ１０４）。
その後、請求金額決定サーバ１０−１は、後述する「請求金額の決定処理」を行う（Ｓ１０５）。
その後、請求金額決定サーバ１０−１のイベント制御部１０６は、Ｓ１０５で決定された値引き額を顧客に通知するためのゲーム画面を表示させる指示情報をＥＣ決済サーバ２０へ通信部１２０に送信させる（Ｓ１０６）。
その後、ＥＣ決済サーバ２０は、Ｓ１０６で受信された指示情報に応じたゲーム画面を顧客端末２４に送信する（Ｓ１０７）。
その後、顧客端末２４は、Ｓ１０７で受信されたゲーム画面を表示する。そして、表示されたゲーム画面において顧客によりゲームが実行されると、顧客端末２４は、Ｓ１０５で決定された値引き額を表示画面に表示する（Ｓ１０８）。
また、Ｓ１０６の後に、請求金額決定サーバ１０−１の払込票生成部１０８は、Ｓ１０４で受信された口座番号と、Ｓ１０５で決定された実請求金額とが記録された払込票を生成する（Ｓ１０９）。
その後、払込票生成部１０８は、生成した払込票を、注文した顧客宛てに例えば電子メールや郵送などにより送付させる（Ｓ１１０）。
（２−１−２−２．請求金額の決定処理）
ここで、図１３を参照して、Ｓ１０５における「請求金額の決定処理」について詳細に説明する。
ここで、図１３を参照して、Ｓ１０５における「請求金額の決定処理」について詳細に説明する。
まず、請求金額決定サーバ１０−１の注文確認部１０２−１は、発生済みの複数の注文のうち、ＥＣ決済サーバ２０から受信された注文データが示す新規の注文と基準請求金額が同一で、かつ未決済の他の注文が存在するか否かを値引状況管理ＤＢ１２４を参照することにより確認する（Ｓ２０１）。
他の注文が存在しない場合には（Ｓ２０１：Ｎｏ）、請求金額決定部１０４−１は、新規の注文の実請求金額を基準請求金額と同一の金額に決定する（Ｓ２０２）。そして、請求金額決定部１０４−１は、当該注文の注文番号と、決定した実請求金額とを対応づけて値引状況管理ＤＢ１２４に記録する（Ｓ２０５）。
一方、他の注文が存在する場合には（Ｓ２０１：Ｙｅｓ）、請求金額決定部１０４−１は、まず、新規の注文に関する基準請求金額からの値引き額を所定の範囲内でランダムに決定する（Ｓ２０３）。
続いて、請求金額決定部１０４−１は、Ｓ２０３で決定した値引き額を当該注文の基準請求金額から減額した金額を当該注文の実請求金額に決定する（Ｓ２０４）。その後、請求金額決定部１０４−１は、Ｓ２０５の動作を行う。
［２−１−３．効果］
以上、例えば図６、図１２、図１３等を参照して説明したように、第１の実施形態による請求金額決定サーバ１０は、発生済みの複数の注文のうち、新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の基準請求金額から所定の範囲内でランダムに減額した金額を当該注文の実請求金額に決定する。
以上、例えば図６、図１２、図１３等を参照して説明したように、第１の実施形態による請求金額決定サーバ１０は、発生済みの複数の注文のうち、新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の基準請求金額から所定の範囲内でランダムに減額した金額を当該注文の実請求金額に決定する。
このため、注文ごとの実請求金額が概ね一意に決定されるので、注文の請求金額が振込依頼人により振り込まれた場面での、振込依頼人が支払を意図した注文を振込受取人が特定する作業を容易化することができる。
例えば、振込依頼人が、注文の請求金額を、当該注文に対応づけられた仮想口座以外の他の仮想口座に誤って振り込んだ場合には、実際に振り込まれた仮想口座に対応づけられている注文の実請求金額と、振込依頼人が支払いを意図した注文の実請求金額とが一致する可能性が極めて低い。このため、決済システムにより振込誤りが検知されることにより、振込受取人は、振込依頼人が振込誤りをしたことに気付くことができる。そして、振込受取人は、振り込まれた金額を基にして注文履歴を検索することにより、当該振込を依頼した人物を推測することができる。また、振込受取人は、推測した人物に対して問い合わせることも可能である。
＜２−２．第２の実施形態＞
以上、第１の実施形態について説明した。次に、第２の実施形態について説明する。後述するように、第２の実施形態によれば、一人の事業者が受注している複数の注文のうちいずれかに対する振込みがなされた際に、当該事業者は、振り込まれた金額により、振込依頼人が支払いを意図した注文を特定することが可能である。
以上、第１の実施形態について説明した。次に、第２の実施形態について説明する。後述するように、第２の実施形態によれば、一人の事業者が受注している複数の注文のうちいずれかに対する振込みがなされた際に、当該事業者は、振り込まれた金額により、振込依頼人が支払いを意図した注文を特定することが可能である。
［２−２−１．構成］
まず、第２の実施形態による構成について詳細に説明する。なお、以下では、第１の実施形態と異なる機能を有する構成要素についてのみ説明を行う。
まず、第２の実施形態による構成について詳細に説明する。なお、以下では、第１の実施形態と異なる機能を有する構成要素についてのみ説明を行う。
図１４は、第２の実施形態による請求金額決定サーバ１０−２の構成を示した機能ブロック図である。図１４に示したように、請求金額決定サーバ１０−２は、第１の実施形態と比較して、制御部１００−１の代わりに、制御部１００−２を有する。
（２−２−１−１．制御部１００−２）
図１４に示したように、制御部１００−２は、注文確認部１０２−１の代わりに注文確認部１０２−２を、請求金額決定部１０４−１の代わりに請求金額決定部１０４−２を、それぞれ有する。なお、その他の機能については、制御部１００−１と同様である。
図１４に示したように、制御部１００−２は、注文確認部１０２−１の代わりに注文確認部１０２−２を、請求金額決定部１０４−１の代わりに請求金額決定部１０４−２を、それぞれ有する。なお、その他の機能については、制御部１００−１と同様である。
（２−２−１−２．注文確認部１０２−２）
注文確認部１０２−２は、新規の注文に対応する事業者が有する複数の仮想口座に対応づけられている複数の注文のうち、新規の注文と基準請求金額が同一であり、かつ、新規の注文の発生時において未決済である他の注文が有るか否かを値引状況管理ＤＢ１２４を参照することにより確認する。
注文確認部１０２−２は、新規の注文に対応する事業者が有する複数の仮想口座に対応づけられている複数の注文のうち、新規の注文と基準請求金額が同一であり、かつ、新規の注文の発生時において未決済である他の注文が有るか否かを値引状況管理ＤＢ１２４を参照することにより確認する。
‐値引状況管理ＤＢ１２４
図１５は、第２の実施形態による値引状況管理ＤＢ１２４の登録例を示した説明である。図１５は、ある事業者が３個の仮想口座（「１０００００１」〜「１０００００３」）を有しており、かつ、当該事業者に対して７個の注文がなされた際の値引状況管理ＤＢ１２４の登録例を示している。なお、図１５では記載を省略しているが、第２の実施形態による値引状況管理ＤＢ１２４は、各仮想口座を有する事業者の識別情報を示すための列をさらに有することが可能である。
図１５は、第２の実施形態による値引状況管理ＤＢ１２４の登録例を示した説明である。図１５は、ある事業者が３個の仮想口座（「１０００００１」〜「１０００００３」）を有しており、かつ、当該事業者に対して７個の注文がなされた際の値引状況管理ＤＢ１２４の登録例を示している。なお、図１５では記載を省略しているが、第２の実施形態による値引状況管理ＤＢ１２４は、各仮想口座を有する事業者の識別情報を示すための列をさらに有することが可能である。
（２−２−１−３．請求金額決定部１０４−２）
請求金額決定部１０４−２は、注文確認部１０２−２により新規の注文に対応する事業者が有する複数の仮想口座に対応づけられている複数の注文のうち、新規の注文と基準請求金額が同一であり、かつ、新規の注文の発生時において未決済である他の注文が有ることが確認された場合には、新規の注文の実請求金額を当該他の注文の実請求金額と異なる金額に決定する。より具体的には、請求金額決定部１０４−２は、上記の場合には、新規の注文の実請求金額を当該他の注文の実請求金額よりも小さい金額に決定する。
請求金額決定部１０４−２は、注文確認部１０２−２により新規の注文に対応する事業者が有する複数の仮想口座に対応づけられている複数の注文のうち、新規の注文と基準請求金額が同一であり、かつ、新規の注文の発生時において未決済である他の注文が有ることが確認された場合には、新規の注文の実請求金額を当該他の注文の実請求金額と異なる金額に決定する。より具体的には、請求金額決定部１０４−２は、上記の場合には、新規の注文の実請求金額を当該他の注文の実請求金額よりも小さい金額に決定する。
例えば、請求金額決定部１０４−２は、上記の場合には、まず、新規の注文に関する基準請求金額からの値引き額を当該他の注文の値引き額よりも大きい金額に決定する。そして、請求金額決定部１０４−２は、決定した値引き額を新規の注文の基準請求金額から減額することにより、新規の注文の実請求金額を決定する。
ここで、図１６を参照して、上記の機能についてより詳細に説明する。なお、図１６は、図１５に示した状態において、注文番号が「１１１１８８」である新規の注文がさらに発生し、そして、当該注文が口座番号「１０００００２」の仮想口座に対応づけられた場面における値引き状況管理ＤＢ１２４の更新例を示している。
図１６に示したように、新規の注文の基準請求金額（「３００，０００円」）は、同一の事業者が有する３個の仮想口座に対応づけられている他の４つの注文（つまり、注文番号が「１１１１１１」、「１１１１２２」、「１１１１４４」、または「１１１１５５」の注文）と同一である。このため、請求金額決定部１０４−２は、新規の注文の実請求金額を当該他の４つの注文の実請求金額よりも小さい金額（例えば、「２９９，９９６円」）に決定する。
この決定例によれば、一人の事業者が有する複数の仮想口座に対応づけられている複数の注文の各々の実請求金額が一意になるように各注文の実請求金額が決定される。このため、ある事業者が有する複数の仮想口座のうちいずれかに対して振込依頼人により振込みがなされた際に、振込受取人（つまり、当該事業者）は、自己が受注している複数の注文のうちいずれに対する振込みがなされたかを、振り込まれた金額により特定することが可能である。
［２−２−２．動作］
以上、第２の実施形態による構成について説明した。続いて、第２の実施形態による動作について説明する。なお、第２の実施形態による全体的な動作に関しては、図１２に示した第１の実施形態と概略同様である。
以上、第２の実施形態による構成について説明した。続いて、第２の実施形態による動作について説明する。なお、第２の実施形態による全体的な動作に関しては、図１２に示した第１の実施形態と概略同様である。
（２−２−２−１．請求金額の決定処理）
ここで、図１７を参照して、第２の実施形態による「請求金額の決定処理」（つまり、図１２に示したＳ１０５）について詳細に説明する。
ここで、図１７を参照して、第２の実施形態による「請求金額の決定処理」（つまり、図１２に示したＳ１０５）について詳細に説明する。
まず、請求金額決定サーバ１０−２の注文確認部１０２−２は、ＥＣ決済サーバ２０から受信された注文データが示す新規の注文に対応する事業者が有する複数の仮想口座に対応づけられている複数の注文のうち、新規の注文と基準請求金額が同一であり、かつ、新規の注文の発生時において未決済である他の注文が有るか否かを値引状況管理ＤＢ１２４を参照することにより確認する（Ｓ３０１）。
他の注文が存在しない場合には（Ｓ３０１：Ｎｏ）、請求金額決定部１０４−２は、Ｓ２０２と同様に、新規の注文の実請求金額を基準請求金額と同一の金額に決定する（Ｓ３０２）。そして、請求金額決定部１０４−２は、Ｓ２０５と同様に、当該注文の注文番号と、決定した実請求金額とを対応づけて値引状況管理ＤＢ１２４に記録する（Ｓ３０５）。
一方、他の注文が存在する場合には（Ｓ３０１：Ｙｅｓ）、請求金額決定部１０４−２は、まず、新規の注文に関する基準請求金額からの値引き額を当該他の注文の値引き額よりも大きい金額に決定する（Ｓ３０３）。
続いて、請求金額決定部１０４−２は、Ｓ３０３で決定した値引き額を新規の注文の基準請求金額から減額した金額を、新規の注文の実請求金額に決定する（Ｓ３０４）。その後、請求金額決定部１０４−２は、Ｓ３０５の動作を行う。
［２−２−３．効果］
以上、例えば図１４、図１７等を参照して説明したように、第２の実施形態による請求金額決定サーバ１０は、新規の注文に対応する事業者が有する複数の仮想口座に対応づけられている複数の注文のうち、新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の実請求金額を当該他の注文の実請求金額よりも小さい金額に決定する。
以上、例えば図１４、図１７等を参照して説明したように、第２の実施形態による請求金額決定サーバ１０は、新規の注文に対応する事業者が有する複数の仮想口座に対応づけられている複数の注文のうち、新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の実請求金額を当該他の注文の実請求金額よりも小さい金額に決定する。
このため、一人の事業者が有する複数の仮想口座に対応づけられている複数の注文の各々の実請求金額が一意になるように決定される。従って、ある事業者が有する複数の仮想口座のうちいずれかに対して振込みがなされた際に、当該事業者は、自己が受注している複数の注文のうちいずれに対する振込みがなされたかを、振り込まれた金額により特定することが可能である。
例えば一人の事業者が１００個の仮想口座の口座番号を有しており、かつ、１日に１００件超の注文がなされる場合などには、同一の仮想口座に対して同一の基準請求金額の複数の注文が対応づけられる。第２の実施形態は、このような複数の注文が対応づけられた仮想口座に対して振込みがなされた際に、振込依頼人および当該振込依頼人が支払いを意図した注文の両方を特定することができる。
＜＜３．ハードウェア構成＞＞
次に、各実施形態に共通する請求金額決定サーバ１０のハードウェア構成について、図１８を参照して説明する。図１８に示したように、請求金額決定サーバ１０は、ＣＰＵ１５０、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１５２、ＲＡＭ１５４、内部バス１５６、入出力インターフェース１５８、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１６０、およびネットワークインターフェース１６２を備える。
次に、各実施形態に共通する請求金額決定サーバ１０のハードウェア構成について、図１８を参照して説明する。図１８に示したように、請求金額決定サーバ１０は、ＣＰＵ１５０、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１５２、ＲＡＭ１５４、内部バス１５６、入出力インターフェース１５８、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１６０、およびネットワークインターフェース１６２を備える。
＜３−１．ＣＰＵ１５０＞
ＣＰＵ１５０は、演算処理装置および制御装置として機能し、各種プログラムに従って請求金額決定サーバ１０内の動作全般を制御する。また、ＣＰＵ１５０は、請求金額決定サーバ１０において制御部１００−１または制御部１００−２の機能を実現する。なお、ＣＰＵ１５０は、マイクロプロセッサなどのプロセッサにより構成される。
ＣＰＵ１５０は、演算処理装置および制御装置として機能し、各種プログラムに従って請求金額決定サーバ１０内の動作全般を制御する。また、ＣＰＵ１５０は、請求金額決定サーバ１０において制御部１００−１または制御部１００−２の機能を実現する。なお、ＣＰＵ１５０は、マイクロプロセッサなどのプロセッサにより構成される。
＜３−２．ＲＯＭ１５２＞
ＲＯＭ１５２は、ＣＰＵ１５０が使用するプログラムや演算パラメータ等を記憶する。
ＲＯＭ１５２は、ＣＰＵ１５０が使用するプログラムや演算パラメータ等を記憶する。
＜３−３．ＲＡＭ１５４＞
ＲＡＭ１５４は、ＣＰＵ１５０の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一時記憶する。
ＲＡＭ１５４は、ＣＰＵ１５０の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一時記憶する。
＜３−４．内部バス１５６＞
内部バス１５６は、ＣＰＵバスなどから構成される。この内部バス１５６は、ＣＰＵ１５０、ＲＯＭ１５２、およびＲＡＭ１５４を相互に接続する。
内部バス１５６は、ＣＰＵバスなどから構成される。この内部バス１５６は、ＣＰＵ１５０、ＲＯＭ１５２、およびＲＡＭ１５４を相互に接続する。
＜３−５．入出力インターフェース１５８＞
入出力インターフェース１５８は、ＨＤＤ１６０、およびネットワークインターフェース１６２を、内部バス１５６と接続する。例えばＨＤＤ１６０は、この入出力インターフェース１５８および内部バス１５６を介して、ＲＡＭ１５４などとの間でデータをやり取りする。
入出力インターフェース１５８は、ＨＤＤ１６０、およびネットワークインターフェース１６２を、内部バス１５６と接続する。例えばＨＤＤ１６０は、この入出力インターフェース１５８および内部バス１５６を介して、ＲＡＭ１５４などとの間でデータをやり取りする。
＜３−６．ＨＤＤ１６０＞
ＨＤＤ１６０は、記憶部１２２として機能する、データ格納用の装置である。このＨＤＤ１６０は、例えば、記憶媒体、記憶媒体にデータを記録する記録装置、記憶媒体からデータを読み出す読出し装置、および記憶媒体に記録されたデータを削除する削除装置などを含む。また、ＨＤＤ１６０は、ＣＰＵ１５０が実行するプログラムや各種データを格納する。
ＨＤＤ１６０は、記憶部１２２として機能する、データ格納用の装置である。このＨＤＤ１６０は、例えば、記憶媒体、記憶媒体にデータを記録する記録装置、記憶媒体からデータを読み出す読出し装置、および記憶媒体に記録されたデータを削除する削除装置などを含む。また、ＨＤＤ１６０は、ＣＰＵ１５０が実行するプログラムや各種データを格納する。
＜３−７．ネットワークインターフェース１６２＞
ネットワークインターフェース１６２は、例えばインターネットなどの通信網に接続するための通信デバイス等で構成された通信インターフェースである。このネットワークインターフェース１６２は、通信部１２０として機能する。なお、ネットワークインターフェース１６２は、無線ＬＡＮ対応通信装置、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）対応通信装置、または有線による通信を行うワイヤー通信装置であってもよい。
ネットワークインターフェース１６２は、例えばインターネットなどの通信網に接続するための通信デバイス等で構成された通信インターフェースである。このネットワークインターフェース１６２は、通信部１２０として機能する。なお、ネットワークインターフェース１６２は、無線ＬＡＮ対応通信装置、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）対応通信装置、または有線による通信を行うワイヤー通信装置であってもよい。
＜＜４．変形例＞＞
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
＜４−１．変形例１＞
例えば、上記の説明では、請求金額決定サーバ１０は、新規の注文に対して決定された値引き額を顧客に通知するためのゲーム画面を顧客端末２４に表示させる例について説明したが、かかる例に限定されない。例えば、請求金額決定サーバ１０は、新規の注文の実請求金額（あるいは、値引き額）を決定する前にゲーム画面を顧客端末２４に表示させてもよい。さらに、請求金額決定サーバ１０は、該当の注文の値引き額を決定する際に、表示されたゲーム画面において顧客により実行されたゲームの結果を反映させて決定してもよい。
例えば、上記の説明では、請求金額決定サーバ１０は、新規の注文に対して決定された値引き額を顧客に通知するためのゲーム画面を顧客端末２４に表示させる例について説明したが、かかる例に限定されない。例えば、請求金額決定サーバ１０は、新規の注文の実請求金額（あるいは、値引き額）を決定する前にゲーム画面を顧客端末２４に表示させてもよい。さらに、請求金額決定サーバ１０は、該当の注文の値引き額を決定する際に、表示されたゲーム画面において顧客により実行されたゲームの結果を反映させて決定してもよい。
＜４−２．変形例２＞
また、上述した各実施形態では、請求金額決定サーバ１０が、発生済みの複数の注文のうち、新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の実請求金額を基準請求金額と異なる金額に決定する例について説明したが、本発明はかかる例に限定されない。
また、上述した各実施形態では、請求金額決定サーバ１０が、発生済みの複数の注文のうち、新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の実請求金額を基準請求金額と異なる金額に決定する例について説明したが、本発明はかかる例に限定されない。
変形例として、例えば、請求金額決定サーバ１０は、発生済みの複数の注文のうち、新規の注文と基準請求金額が同一である他の注文が有ることが確認された場合には、新規の注文の請求金額の振込期間を当該他の注文の請求金額の振込期間と異ならせるように決定することも可能である。例えば、請求金額決定サーバ１０は、上記の場合には、注文時に顧客により指定された商品送付希望日が遅い注文ほど、注文の請求金額の振込期間が遅くなるように決定してもよい。
この変形例によれば、基準請求金額が同じである複数の注文の各々の振込期間が一意になるように決定される。このため、注文の請求金額が振込依頼人により振り込まれた際に、振込受取人は、振り込まれた金額および振り込まれた日時から、振込依頼人が支払を意図した注文の特定を容易化することができる。
＜４−３．変形例３＞
また、上記の各実施形態による請求金額決定サーバ１０は、ＥＣ決済の場面に適用される例を中心として説明したが、本発明はかかる例に限定されない。例えば、請求金額決定サーバ１０は、大学入学金の振込み、海外送金、または電子マネーチャージなどの資金移動や通貨変換の場面にも適用可能である。
また、上記の各実施形態による請求金額決定サーバ１０は、ＥＣ決済の場面に適用される例を中心として説明したが、本発明はかかる例に限定されない。例えば、請求金額決定サーバ１０は、大学入学金の振込み、海外送金、または電子マネーチャージなどの資金移動や通貨変換の場面にも適用可能である。
＜４−４．変形例４＞
また、本実施形態によれば、ＣＰＵ１５０、ＲＯＭ１５２、およびＲＡＭ１５４などのハードウェアを、上述した請求金額決定サーバ１０の各構成と同等の機能を発揮させるためのコンピュータプログラムも提供可能である。また、該コンピュータプログラムが記録された記録媒体も提供される。
また、本実施形態によれば、ＣＰＵ１５０、ＲＯＭ１５２、およびＲＡＭ１５４などのハードウェアを、上述した請求金額決定サーバ１０の各構成と同等の機能を発揮させるためのコンピュータプログラムも提供可能である。また、該コンピュータプログラムが記録された記録媒体も提供される。
１０−１、１０−２ 請求金額決定サーバ
２０ ＥＣ決済サーバ
２２ 口座管理ＤＢ
２４ 顧客端末
２６ 通信網
１００−１、１００−２ 制御部
１０２−１、１０２−２ 注文確認部
１０４−１、１０４−２ 請求金額決定部
１０６ イベント制御部
１０８ 払込票生成部
１２０ 通信部
１２２ 記憶部
１２４ 値引状況管理ＤＢ
１５０ ＣＰＵ
１５２ ＲＯＭ
１５４ ＲＡＭ
１５６ 内部バス
１５８ 入出力インターフェース
１６０ ＨＤＤ
１６２ ネットワークインターフェース
２０ ＥＣ決済サーバ
２２ 口座管理ＤＢ
２４ 顧客端末
２６ 通信網
１００−１、１００−２ 制御部
１０２−１、１０２−２ 注文確認部
１０４−１、１０４−２ 請求金額決定部
１０６ イベント制御部
１０８ 払込票生成部
１２０ 通信部
１２２ 記憶部
１２４ 値引状況管理ＤＢ
１５０ ＣＰＵ
１５２ ＲＯＭ
１５４ ＲＡＭ
１５６ 内部バス
１５８ 入出力インターフェース
１６０ ＨＤＤ
１６２ ネットワークインターフェース
Claims (7)
- 発生済みの複数の注文のうち第１の注文と前記注文の対象商品に関する請求金額である基準請求金額が同一である第２の注文が記憶媒体に有るか否かをプロセッサにより確認する注文確認部と、
前記注文確認部により前記第２の注文が有ることが確認された場合に、前記第１の注文の実際の請求金額である実請求金額を、前記基準請求金額よりも、所定の範囲内でランダムに決定された額だけ小さい金額に前記プロセッサにより決定する請求金額決定部と、
を備え、
前記注文確認部により確認される前記複数の注文の各々および、前記請求金額決定部により前記実請求金額を決定される前記第１の注文は、支払用の複数の口座のうち互いに異なる口座のいずれかに対応づけられている、
情報処理装置。 - 前記請求金額決定部は、前記第１の注文の実請求金額を、さらに前記第２の注文の実請求金額と異なる金額に決定する、請求項１に記載の情報処理装置。
- 前記第１の注文は、前記第２の注文よりも後に発生した注文であり、
前記請求金額決定部は、前記第１の注文の実請求金額を、前記第２の注文の実請求金額よりも小さい金額に決定する、請求項２に記載の情報処理装置。 - 前記注文確認部は、前記第２の注文が、前記第１の注文の発生時において未決済の注文であるか否かを確認する、請求項１〜３のいずれか一項に記載の情報処理装置。
- 前記注文確認部は、前記第２の注文が、前記第１の注文の注文日から所定の期間内に発生した注文であるか否かを確認する、請求項１〜４のいずれか一項に記載の情報処理装置。
- 前記情報処理装置は、前記請求金額決定部により決定された前記第１の注文の実請求金額を利用者に通知するためのイベントの表示制御をするイベント制御部をさらに備える、請求項１〜５のいずれか一項に記載の情報処理装置。
- コンピュータを、
発生済みの複数の注文のうち第１の注文と前記注文の対象商品に関する請求金額である基準請求金額が同一である第２の注文が記憶媒体に有るか否かをプロセッサにより確認する注文確認部と、
前記注文確認部により前記第２の注文が有ることが確認された場合に、前記第１の注文の実際の請求金額である実請求金額を、前記基準請求金額よりも、所定の範囲内でランダムに決定された額だけ小さい金額に前記プロセッサにより決定する請求金額決定部と、
を備え、
前記注文確認部により確認される前記複数の注文の各々および、前記請求金額決定部により前記実請求金額を決定される前記第１の注文は、支払用の複数の口座のうち互いに異なる口座のいずれかに対応づけられている、
情報処理装置、
として機能させるための、プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014172572A JP6387742B2 (ja) | 2014-08-27 | 2014-08-27 | 情報処理装置、及びプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014172572A JP6387742B2 (ja) | 2014-08-27 | 2014-08-27 | 情報処理装置、及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2016048419A JP2016048419A (ja) | 2016-04-07 |
| JP6387742B2 true JP6387742B2 (ja) | 2018-09-12 |
Family
ID=55649303
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2014172572A Active JP6387742B2 (ja) | 2014-08-27 | 2014-08-27 | 情報処理装置、及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6387742B2 (ja) |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4397518B2 (ja) * | 1999-10-05 | 2010-01-13 | 株式会社りそなホールディングス | 為替処理システム、及び、その制御方法 |
| JP2002175461A (ja) * | 2000-09-29 | 2002-06-21 | Fujitsu Ltd | 商品販売装置，商品販売情報提供方法，商品販売情報表示方法，コンピュータ読取可能な記録媒体 |
| JP2007128294A (ja) * | 2005-11-04 | 2007-05-24 | Ishida Co Ltd | 販促システム |
| JP5222902B2 (ja) * | 2010-06-29 | 2013-06-26 | 東芝テック株式会社 | 決済装置及びプログラム |
-
2014
- 2014-08-27 JP JP2014172572A patent/JP6387742B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2016048419A (ja) | 2016-04-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20230169586A1 (en) | Shared expense management | |
| US8615439B2 (en) | Processing online transactions | |
| US8676701B2 (en) | Credit card usage management system, credit card usage management method, program, and information storage medium | |
| JP4815540B1 (ja) | 金融商品取引管理装置、プログラム | |
| JP7208429B1 (ja) | 情報処理装置、情報処理方法及び情報処理プログラム | |
| US20160300232A1 (en) | Monitoring assistance device | |
| KR101799235B1 (ko) | 에스크로 서비스 보증 시스템 및 방법 | |
| KR102136976B1 (ko) | 토큰화된 모바일 상품권 서비스 방법 및 이를 이용한 서비스 제공 장치 | |
| KR20130014043A (ko) | 계좌번호가 연동되어 있는 전화 번호를 이용하여 주문 결제를 중계하는 시스템 및 방법 | |
| JP2008233989A (ja) | 証券売買注文管理装置および証券売買注文管理方法 | |
| JP6144110B2 (ja) | 支払処理システムおよびその方法 | |
| JP2016148970A (ja) | 情報処理システム、情報処理方法、及びプログラム | |
| WO2014175236A1 (ja) | 店舗用システム | |
| JP2007047999A (ja) | 証券決済残高管理システム及び証券決済残高管理プログラム | |
| JP5862144B2 (ja) | サーバ装置、およびプログラム | |
| JP6387742B2 (ja) | 情報処理装置、及びプログラム | |
| JP6058620B2 (ja) | 融資取引の自動実行システムおよび方法 | |
| JP2006277070A (ja) | 端株取引システム及び端株取引プログラム | |
| JP5793007B2 (ja) | 金融商品取引管理装置、金融商品取引管理方法、プログラム | |
| JP2021018796A (ja) | 金融商品取引管理装置、金融商品取引管理システム、プログラム | |
| US11461761B2 (en) | System for conducting transactions independent of point of sale system | |
| JP7395640B2 (ja) | 情報処理装置、情報処理方法及び情報処理プログラム | |
| JP5897883B2 (ja) | 資金を移動するためのデータを生成する方法、システム及びプログラム | |
| TWM552150U (zh) | 入帳管理服務系統 | |
| KR101138965B1 (ko) | 수수료 쿠폰을 이용한 금융 거래 시스템 및 그 동작방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20170515 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180508 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20180508 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180706 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20180717 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20180730 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6387742 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |