JP6934343B2 - 情報処理装置および決済方法 - Google Patents

Description

本発明は、代金後払い決済又は代金先払い決済に係る処理を行う情報処理装置および決済方法に関する。

従来より、オンラインショッピング等においては、購入代金の支払い時期について、ユーザが先払い、後払い等を選択可能とされている。このうち例えば、後払いが選択された場合にユーザの信用度に基づいて、該ユーザに後払いの利用を許可するか否かを判断する技術が提案されている（下記の特許文献１参照）。

特開２０１０−１２２９５０号公報

しかし、上記の技術では、後払いの利用可否を厳格に判断するものの、利用を許可した場合に、サービス提供条件（例えばユーザが支払う代金、販売者が受け取る代金等）をユーザ等の信用度に応じて設定する、といった点まではあまり考慮されていなかった。そのため、先払い、後払いといった支払方法を問わず、ユーザ等の信用度に応じたサービス提供条件の設定に関しては、改善の余地が有った。

本発明は、上記課題を解決するために成されたものであり、ユーザ等の信用度に応じてサービス提供条件を適切に設定することを目的とする。

本発明の一実施形態に係る情報処理装置は、代金後払いの選択情報を含んだ、サービス提供に係る注文情報を、端末から受信する受信部と、前記端末のユーザに関する信用度を取得する取得部と、前記受信部により受信された注文情報に応じた既定の代金を、前記取得部により取得された信用度に基づいて増減させることで、前記ユーザの支払金額を算出する算出部と、前記算出部により算出された支払金額を前記端末へ提示する提示部と、前記提示部により提示された支払金額の承諾通知を前記端末から受信した場合に、前記注文情報に係るサービス提供を行うサービス提供部と、前記サービス提供後に、前記支払金額が支払われたことを確認する確認部と、を備える。なお、本件全般における「サービス提供」とは、商品の販売、商品の貸与、金銭の融資、サービスの供与などを広く含んだ、もろもろのサービスの提供を意味する。

上記一実施形態に係る情報処理装置では、受信部が、代金後払いの選択情報を含んだ、サービス提供に係る注文情報を、端末から受信すると、取得部が、端末のユーザに関する信用度を取得し、算出部が、注文情報に応じた既定の代金を、信用度に基づいて増減させることで、ユーザの支払金額を算出する。そして、提示部が、算出された支払金額を端末へ提示し、その後、当該提示された支払金額の承諾通知を端末から受信した場合、サービス提供部は、注文情報に係るサービス提供を行い、そして、確認部は、サービス提供後に、上記支払金額が支払われたことを確認する。代金後払いの場合、例えば、サービス提供後にユーザが所定期限までに支払金額を支払わないといったリスクが考えられるが、ユーザに関する信用度に基づいて代金を増減させることでユーザの支払金額が算出されるため、ユーザの信用度に応じてサービス提供条件（ユーザの支払金額）を適切に設定することができる。また、これにより、当該サービス提供条件の下で、代金後払いのサービス提供を円滑に行うことができる。なお、「信用度」とは、対象者が支払を行うかどうか、借りたものを返すかどうか等、信用できる度合いを示す指標である。「信用度」は、例えば、スコア、ランキングといった表現も適用される。

本発明によれば、サービス提供条件をより適切に設定することができる。

第１実施形態の通信システムのシステム構成図である。 第１実施形態の決済処理を示すフロー図である。 信用度と割増し料率との対応例を示す表である。 第２実施形態の通信システムのシステム構成図である。 第２実施形態の決済処理を示すフロー図である。 第３実施形態の通信システムのシステム構成図である。 第３実施形態の決済処理を示すフロー図である。 第４実施形態の通信システムのシステム構成図である。 第４実施形態の決済処理を示すフロー図である。 サーバのハードウェア構成例を示す図である。

以下、本発明に係る各種の実施形態を説明する。以下では、第１実施形態として、端末とサーバ間の代金後払いに係る決済処理を説明し、第２実施形態として、端末とサーバ間の代金先払いに係る決済処理を説明し、第３実施形態として、ユーザの端末と販売者サーバとの間で取引されたサービス提供が完了した後に決済事業者サーバにより実行される決済処理を説明し、さらに、第４実施形態として、代金先払いのサービス提供において販売者の信用度に応じたユーザ代金値引きを行う決済処理を説明する。

［第１実施形態］
（システム構成）
図１には、第１実施形態におけるユーザの端末２０とサーバ１０（本発明の「情報処理装置」に対応）とを含む通信システム１のシステム構成図を示す。図１に示すように、サーバ１０は、受信部１１、信用度ＤＢ１２、取得部１３、算出部１４、提示部１５、サービス提供部１６、および、確認部１７を備える。以下、各部の機能を概説する。

受信部１１は、サービス提供に係る注文情報を端末２０から受信する。第１実施形態では、端末２０から、代金後払いの選択情報を含んだ注文情報が受信される。

信用度ＤＢ１２は、端末２０のユーザに関する信用度をユーザごとに保管したデータベースである。なお、上記の信用度は、サーバ１０が備える図示しない機能部（例えば信用度算出部など）によって算出して信用度ＤＢ１２に予め保管してもよいし、サーバ１０の外部から受信して信用度ＤＢ１２に予め保管してもよい。もし、信用度を算出する際に通信秘密とされる情報を用いる場合には、予めユーザの同意を得ている場合に用いられる。

取得部１３は、注文情報の送信元の端末２０のユーザに関する信用度を信用度ＤＢ１２から取得する。ここでは、取得部１３が、サーバ１０が備えた信用度ＤＢ１２から信用度を取得する例を説明するが、サーバ１０が信用度ＤＢ１２を備えることは必須ではない。サーバ１０が信用度ＤＢ１２を備えない場合、取得部１３はサーバ１０の外部（例えば信用度ＤＢを備えた別のサーバ）から信用度を取得してもよい。

算出部１４は、注文情報に応じた既定の代金を、ユーザの信用度に基づいて増減させることで、ユーザの支払金額を算出する。算出部１４による支払金額の算出方法の詳細は、図２の処理説明において説明する。

提示部１５は、算出部１４により算出された支払金額を端末２０へ提示する。

サービス提供部１６は、提示された支払金額の承諾通知を端末２０から受信した場合に、注文情報に係るサービス提供を行う。

確認部１７は、サービス提供後に、支払金額が支払われたことを確認する。

（第１実施形態における処理）
以下、図２のフロー図に沿って、第１実施形態における処理を説明する。

端末が、後払い選択情報を含む注文情報をサーバへ送信すると（ステップＳ１）、サーバの受信部１１が上記注文情報を受信し、取得部１３がユーザの信用度を信用度ＤＢ１２から取得する（ステップＳ２）。そして、算出部１４が、後述する処理例のようにして、既定の代金を信用度に基づいて増減させることで支払金額を算出し（ステップＳ３）、提示部１５が、算出された支払金額を端末へ提示する（ステップＳ４）。その後、端末のユーザが支払金額を承諾したことを示す承諾通知が端末からサーバへ送信されると（ステップＳ５）、サービス提供部１６が、サービスを提供する（ステップＳ６）。そして、支払金額が後払いされ、確認部１７がその支払いを確認したことをもって、図２の処理を終了する。

上記ステップＳ３での支払金額の算出は、例えば、以下のように実行してもよい。
支払金額＝商品代金＋固定手数料＋手数料等増減費 （１）
上記式（１）のように、支払金額は、商品代金と固定手数料と手数料等増減費との和により算出し、ここでの「手数料等増減費」をユーザの信用度に基づいて、例えば以下のパターン１〜３のように増減させてもよい。

パターン１として、図３に示すユーザの信用度と割増し料率との対応情報を予め定め、算出部１４が、当該対応情報を予め記憶しておき、ユーザの信用度に対応する割増し料率を特定し、商品代金に割増し料率を乗算して得られた値を手数料等増減費（ここでは増加させる額）として求め、上記式（１）により支払金額を算出してもよい。例えば、信用度が２０であるユーザについては、図３より割増し料率５％が特定され、商品代金に割増し料率５％を乗算して得られた値が手数料等増減費（ここでは増加させる額）として求められる。上記ユーザよりも信用度が低いユーザ（例えば信用度が８であるユーザ）については、図３より割増し料率１０％が特定され、商品代金に割増し料率１０％を乗算して得られた値が手数料等増減費（ここでは増加させる額）として求められる。

パターン２として、算出部１４が、ユーザの信用度の一例として予測デフォルト率を取得し、商品代金に予測デフォルト率を乗算して得られた値を手数料等増減費（ここでは増加させる額）として求め、上記式（１）により支払金額を算出してもよい。例えば、ユーザの予測デフォルト率が３％で、商品代金が10000円の場合、これらを乗算して得られた値（300円）を手数料等増減費として求め、得られた値（300円）だけ増加させてもよい。

パターン３として、算出部１４は、上記パターン１又は２に加えて、さらに、サービス提供に係る商品の特性又はサービスの特性に応じた調整を加えてもよい。例えば、上記商品の特性としては、
・商品が非常に高額である点、
・商品が非常に低額である点、
・過去の事象から踏み倒されがちな商品である点、など
が挙げられる。上記パターン２に加え、上記特性に応じた調整を加える場合には、予め上記のような特性に応じた調整値を定めて、算出部１４が、当該特性に応じた調整値を予め記憶しておき、以下の式（２）又は式（３）により手数料等増減費として求め、上記式（１）により支払金額を算出してもよい。このとき、特性に応じた調整値は、正の値となることもあれば、負の値となることもある。
手数料等増減費＝予測デフォルト率×商品代金×特性に応じた調整値 （２）
手数料等増減費＝予測デフォルト率×商品代金＋特性に応じた調整値 （３）

以上の第１実施形態のような代金後払いの場合、例えば、サービス提供後にユーザが所定期限までに支払金額を支払わないといったリスクが考えられるが、ユーザに関する信用度に基づいて代金を増減させることでユーザの支払金額が算出されるため、ユーザの信用度に応じてサービス提供条件（ユーザの支払金額）を適切に設定することができ、当該サービス提供条件の下で、代金後払いのサービス提供を円滑に行うことができる。

［第２実施形態］
第２実施形態として、端末とサーバ間の代金先払いに係る決済処理を説明する。

（システム構成）
図４には、第２実施形態におけるユーザの端末２０とサーバ１０（本発明の「情報処理装置」に対応）とを含む通信システム１のシステム構成図を示す。図４に示すように、第２実施形態のシステム構成は、前述した第１実施形態のシステム構成（図１）とほぼ同様であるが、以下の点が異なる。

第２実施形態において、受信部１１は、端末２０から、代金先払いの選択情報を含んだ注文情報を受信する。確認部１７は、提示部１５により提示された支払金額が支払われたことを確認する。サービス提供部１６は、確認部１７により支払金額が支払われたことが確認された後に、注文情報に係るサービス提供を行う。

（第２実施形態における処理）
以下、図５のフロー図に沿って、第２実施形態における処理を説明する。

端末が、先払い選択情報を含む注文情報をサーバへ送信すると（ステップＳ１１）、サーバの受信部１１が上記注文情報を受信し、取得部１３がユーザの信用度を信用度ＤＢ１２から取得する（ステップＳ１２）。そして、算出部１４が、既定の代金を、信用度に基づいて増減させることで支払金額を算出し（ステップＳ１３）、提示部１５が、算出された支払金額を端末へ提示する（ステップＳ１４）。その後、提示された支払金額が先払いされ、確認部１７がその支払いを確認すると（ステップＳ１５）、サービス提供部１６がサービスを提供する（ステップＳ１６）。そして、サービス提供の完了をもって、図５の処理を終了する。

上記ステップＳ１３での支払金額の算出方法は、前述した第１実施形態の支払金額算出方法と同様であるため、ここでは重複した説明を省略する。

一般に、代金先払いは、代金後払いと比較すると、サービス提供を行う事業者からみると、代金の支払いを確認後にサービス提供を行うことができるため、より安全に事業を進めることができる。そのため、例えば、代金先払いの場合は、代金後払いの場合よりも、ユーザの支払金額を安く設定してユーザにインセンティブを与え、その際に、信用度が高いユーザに対し、ユーザの支払金額をより安く設定して手厚い優遇を与える、といった態様が考えられる。上述した第２実施形態に係る情報処理装置では、ユーザに関する信用度に基づいて代金を増減させることでユーザの支払金額が算出されるため、ユーザの信用度に応じてサービス提供条件（ユーザの支払金額）を適切に設定することができ、当該サービス提供条件の下で、代金先払いのサービス提供を円滑に行うことができる。

なお、上記第２実施形態に係るサーバ１０（情報処理装置）は、以下のように記述することができる。当該サーバ１０（情報処理装置）は、代金先払いの選択情報を含んだ、サービス提供に係る注文情報を、端末から受信する受信部と、前記端末のユーザに関する信用度を取得する取得部と、前記受信部により受信された注文情報に応じた既定の代金を、前記取得部により取得された信用度に基づいて増減させることで、前記ユーザの支払金額を算出する算出部と、前記算出部により算出された支払金額を前記端末へ提示する提示部と、前記提示部により提示された支払金額が支払われたことを確認する確認部と、前記確認部により前記支払金額が支払われたことが確認された後に、前記注文情報に係るサービス提供を行うサービス提供部と、を備える。

同様に、上記第２実施形態に係る決済方法は、以下のように記述することができる。当該決済方法は、ユーザの端末と販売者のサーバとを含む通信システムにより実行される決済方法であって、前記端末が、代金先払いの選択情報を含んだ、サービス提供に係る注文情報を、前記サーバへ送信するステップと、前記サーバが、前記注文情報の送信元の端末のユーザに関する信用度を取得するステップと、前記サーバが、前記注文情報に応じた既定の代金を、前記信用度に基づいて増減させることで、前記ユーザの支払金額を算出するステップと、前記サーバが、算出された支払金額を前記端末へ提示するステップと、前記サーバが、提示された支払金額が支払われたことを確認するステップと、前記サーバが、前記支払金額が支払われたことが確認された後に、前記注文情報に係るサービス提供を行うステップと、を備える。

［第３実施形態］
第３実施形態として、ユーザの端末と販売者サーバとの間で取引されたサービス提供が完了した後に決済事業者サーバにより実行される決済処理を説明する。

（システム構成）
図６には、第３実施形態における、ユーザの端末２０と、販売者サーバ４０と、決済事業者サーバ３０（本発明の「情報処理装置」に対応）とを含む通信システム１のシステム構成図を示す。図６に示すように、決済事業者サーバ３０は、提示部３１、信用度ＤＢ３２、取得部３３、算出部３４、処理部３５、および、確認部３６を備える。販売者サーバ４０は、販売処理部４１、および購入履歴ＤＢ４２を備える。以下、各部の機能を概説する。

提示部３１は、代金後払いに係るサービス提供に応じた既定の代金を請求する請求情報を端末２０へ提示する。

信用度ＤＢ３２は、端末２０のユーザに関する信用度をユーザごとに保管したデータベースである。

取得部３３は、端末２０のユーザに関する信用度を信用度ＤＢ３２から取得する。ここでは、取得部３３が、決済事業者サーバ３０が備えた信用度ＤＢ３２から信用度を取得する例を説明するが、決済事業者サーバ３０が信用度ＤＢ３２を備えることは必須ではなく、取得部３３は決済事業者サーバ３０の外部（例えば信用度ＤＢを備えた別のサーバ）から信用度を取得してもよい。

算出部３４は、前述した第１実施形態と同様の方法で、サービス提供に応じた既定の代金を、取得部３３により取得された信用度に基づいて増減させることで、販売者への支払金額を算出する。

処理部３５は、後述する確認部３６により代金の支払いが確認されたか否かに関わらず、算出部３４により算出された支払金額を販売者サーバへ支払う処理を行う。

確認部３６は、提示部３１により提示された代金が端末２０のユーザにより支払われたことを確認する。

一方、販売者サーバ４０に設けられた購入履歴ＤＢ４２は、端末２０のユーザにより実行された過去の購入履歴情報を保管したデータベースである。

販売処理部４１は、端末２０へのサービス提供処理、決済事業者への債権譲渡を含む所定の決済依頼処理、決済事業者サーバ３０の処理部３５による支払金額の支払いの確認等を実行する。

（第３実施形態における処理）
以下、図７のフロー図に沿って、第３実施形態における処理を説明する。

端末が、後払い選択情報を含む注文情報を販売者サーバへ送信すると（ステップＳ２１）、販売者サーバの販売処理部４１は、端末２０へのサービス提供処理を実行する（ステップＳ２２）。その後、販売処理部４１は、決済事業者サーバに対し、決済事業者への債権譲渡を含む所定の決済依頼処理を実行する（ステップＳ２３）。なお、上記決済依頼処理は、サーバ間の情報処理ではなく、販売者−決済事業者間の人為的な処理により実行されてもよい。

決済依頼を受けた決済事業者サーバの提示部３１は、代金後払いに係るサービス提供に応じた既定の代金を請求する請求情報を端末２０へ提示し（ステップＳ２４）、取得部３３は、端末２０のユーザに関する信用度を信用度ＤＢ３２から取得する（ステップＳ２５）。そして、算出部３４は、前述した第１実施形態と同様の方法で、サービス提供に応じた既定の代金を、取得部３３により取得された信用度に基づいて増減させることで、販売者への支払金額を算出する（ステップＳ２６）。

その後、確認部３６は、提示部３１により提示された代金が端末２０のユーザにより支払われたことを確認する（ステップＳ２８）が、処理部３５は、代金が支払われたことが確認部３６により確認されたか否かに関わらず、算出部３４により算出された支払金額を販売者サーバへ支払う処理を行う（ステップＳ２７）。ステップＳ２８、Ｓ２７の順序は任意であるが、実際の場面では、図７に示すように、販売者サーバへの支払金額の支払い（Ｓ２７）が先に実行され、その後、代金が端末２０のユーザにより支払われたことが確認される（Ｓ２８）と想定される。

以上説明した第３実施形態のように、サービス提供が完了した後の決済を行う場合、例えば、ユーザが所定期限までに代金を支払わず、決済事業者が損害を被るといったリスクが考えられるが、ユーザに関する信用度に基づいて代金を増減させることで販売者への支払金額を算出するため、決済事業者にとっては代金と支払金額との差分に応じた事業利益を得ることができる。このとき、ユーザの信用度に応じて、換言すれば、上記のようなリスクの発生確率に応じて、サービス提供条件（販売者への支払金額）を適切に設定することができ、当該サービス提供条件の下で決済を円滑に行うことができる。

より具体的には、ユーザ、販売者、決済を行う側（例えば決済事業者）の三者それぞれに、以下のような利点がある。ユーザにとっては、例えばクレジットカードを持てないユーザであってもサービス提供後の代金後払いを利用できるという利点があり、販売者にとっては代金がユーザにより支払われたか否かに関わらず、支払金額を通常より早いタイミングで確実に受け取ることができるという利点があり、さらに、決済を行う側（例えば決済事業者）にとってはユーザの信用度に応じて適切に設定されたサービス提供条件（販売者への支払金額）によって、上記のリスクを考慮した適切な事業利益を得ることができるという利点がある。

［第４実施形態］
第４実施形態として、代金先払いのサービス提供において販売者の信用度に応じたユーザ代金値引きを行う決済処理を説明する。

（システム構成）
図８には、第４実施形態における、ユーザの端末２０と、販売者サーバ４０と、決済事業者サーバ５０（本発明の「情報処理装置」に対応）とを含む通信システム１のシステム構成図を示す。図８に示すように、決済事業者サーバ５０は、受信部５１、信用度ＤＢ５２Ａ、取得部５２、算出部５３、提示部５４、送信部５５、請求処理部５６、支払確認部５７、支払処理部５８、および、完了確認部５９を備える。販売者サーバ４０は、販売処理部４１、および購入履歴ＤＢ４２を備える。以下、各部の機能を概説する。

受信部５１は、代金先払いのサービス提供に係る申し出情報を、販売者サーバ４０から受信する。

信用度ＤＢ５２Ａは、販売者サーバ４０を運営する販売者に関する信用度を販売者ごとに保管したデータベースである。

取得部５２は、販売者に関する信用度を信用度ＤＢ５２Ａから取得する。ここでは、取得部５２が、決済事業者サーバ５０が備えた信用度ＤＢ５２Ａから信用度を取得する例を説明するが、決済事業者サーバ５０が信用度ＤＢ５２Ａを備えることは必須ではなく、取得部５２は決済事業者サーバ５０の外部（例えば信用度ＤＢを備えた別のサーバ）から信用度を取得してもよい。

算出部５３は、サービス提供に係る申し出情報に応じた既定の代金を、取得部５２により取得された信用度に基づいて増減させることで、ユーザ向け代金を算出する。算出部５３によるユーザ向け代金の算出方法は、図９の処理説明において説明する。また、算出部５３は、さらに、上記ユーザ向け代金から所定手数料を引いた金額を、販売者への支払い額として算出してもよい。ここでの「所定手数料」は、後述する図９に示す先払いサービスの実現に係る決済事業者の労力に対する対価に相当し、予め定められた決済事業者と販売者間の取り決め等に基づき設定してもよい。所定手数料は、例えば、所定の金額であってもよいし、上記ユーザ向け代金に応じて定められる金額であってもよい。

提示部５４は、算出部５３により算出されたユーザ向け代金を販売者サーバ４０へ提示する。

送信部５５は、算出部５３により算出されたユーザ向け代金情報を含んだ、代金先払いのサービス提供に係る情報（例えば、当該代金先払いサービスに関する広告情報など）を端末２０へ送信する。

請求処理部５６は、代金先払いのサービス提供に係る注文情報を端末２０から受け付け、ユーザ向け代金の請求処理（例えば、端末２０へのユーザ向け代金の請求情報の送信など）を行う。

支払確認部５７は、ユーザ向け代金が端末２０のユーザにより支払われたことを確認する。

支払処理部５８は、支払確認部５７によりユーザ向け代金が支払われたことが確認された場合、前述した販売者への支払い額、即ち、ユーザ向け代金から所定手数料を引いた金額を、販売者へ支払う処理を行う。

完了確認部５９は、上記注文情報に応じたサービス提供（例えば、注文された商品の配送、注文されたサービスの提供など）が実行完了したことを確認する。本実施形態では、販売者サーバ４０から端末２０に対しサービス提供された後、販売者サーバ４０がサービス提供完了報告を決済事業者サーバ５０へ送信する。ここで、完了確認部５９は、販売者サーバ４０からサービス提供完了報告を受信したことをもってサービス提供が実行完了したことを確認することができる。

一方、販売者サーバ４０に設けられた購入履歴ＤＢ４２は、端末２０のユーザにより実行された過去の購入履歴情報を保管したデータベースである。

販売処理部４１は、代金先払いのサービス提供に係る申し出情報の送信、提示部５４により提示されたユーザ向け代金に関する了解応答、支払処理部５８による支払いの確認、端末２０へのサービス提供処理、サービス提供後のサービス提供完了報告の送信などを実行する。

（第４実施形態における処理）
以下、図９のフロー図に沿って、第４実施形態における処理を説明する。

決済事業者サーバ５０の受信部５１が、代金先払いのサービス提供に係る申し出情報を販売者サーバ４０から受信すると（ステップＳ３１）、取得部５２は、販売者サーバ４０を運営する販売者に関する信用度を信用度ＤＢ５２Ａから取得し（ステップＳ３２）、算出部５３は、後述するように、サービス提供に係る申し出情報に応じた既定の代金を、上記取得された信用度に基づいて増減させることで、ユーザ向け代金を算出し（ステップＳ３３）、そして、提示部５４は、上記算出されたユーザ向け代金を販売者サーバ４０へ提示する（ステップＳ３４）。

上記ステップＳ３３でのユーザ向け代金の算出は、例えば、以下のように実行してもよい。
ユーザ向け代金＝商品代金−先払いリスク料 （４）
上記式（４）のように、ユーザ向け代金は、商品代金から先払いリスク料を割り引くことにより算出してもよい。ここでの「先払いリスク料」は、販売者が提供するサービスに不備が有る又はサービスが提供されないリスク（つまり、ユーザにとっての先払いリスク）を加味した料金であり、販売者の信用度に基づいて定められる。

上記の先払いリスク料の定め方としては、第１実施形態で述べた「手数料等増減費」と同様の定め方を採用することができる。例えば、販売者の信用度と割引き料率との対応情報を予め定め、算出部５３が、当該対応情報を予め記憶しておき、販売者の信用度に対応する割引き料率を特定し、商品代金に割引き料率を乗算して得られた値を、先払いリスク料として求め、上記式（４）によりユーザ向け代金を算出してもよい。さらに、第１実施形態で述べたように、算出されたユーザ向け代金に対し、サービス提供に係る商品の特性又はサービスの特性に応じた調整を加えてもよい。

そして、上記提示されたユーザ向け代金に関する了解応答を販売者サーバ４０から受信すると（ステップＳ３５）、送信部５５は、上記ユーザ向け代金情報を含んだ、代金先払いのサービス提供に係る情報（例えば、当該代金先払いサービスに関する広告情報など）を端末２０へ送信する（ステップＳ３６）。

その後、代金先払いのサービス提供に係る注文情報が端末２０から送信されると（ステップＳ３７）、請求処理部５６は、当該注文情報を受け付け、ユーザ向け代金の請求処理（例えば、端末２０へのユーザ向け代金の請求情報の送信など）を行う（ステップＳ３８）。そして、ユーザ向け代金が端末２０のユーザにより先払いされると、支払確認部５７は、ユーザ向け代金が支払われたことを確認し（ステップＳ３９）、支払処理部５８は、販売者への支払い額（ユーザ向け代金から所定手数料を引いた金額）を販売者へ支払う処理を行う（ステップＳ４０）。さらに、支払いを受けた販売者サーバ４０により、端末２０に対し上記注文情報に応じたサービス提供（例えば、注文された商品の配送、注文されたサービスの提供など）が実行され（ステップＳ４１）、その後、販売者サーバ４０がサービス提供完了報告を決済事業者サーバ５０へ送信する。ここで、完了確認部５９は、販売者サーバ４０からサービス提供完了報告を受信したことをもってサービス提供が実行完了したことを確認する（ステップＳ４２）。

以上説明した第４実施形態のように、サービス提供が完了する前に決済を行う場合、例えば、販売者が提供するサービスに不備が有る、販売者が注文に応じたサービスを提供しない（例えば注文した商品を配送しない等）といった、ユーザから見たリスクが考えられるが、販売者に関する信用度に基づいて既定の代金を増減させる（実際には値引きをする）ことでユーザ向け代金を算出するため、上記のようなリスクの発生確率に応じて、サービス提供条件（ここではユーザ向け代金）を適切に設定することができ、当該サービス提供条件の下で決済を円滑に行うことができる。

より具体的には、ユーザにとっては、販売者に関する信用度がユーザ向け代金という形で明確化されていることにより、リスクが分かり易くなるとともに、サービス提供を通常よりも安価に受けることができる可能性がある。また、販売者にとっては、新規参入者である、現時点の信用度があまり高くない、業界内であまり有名でないといったマイナス要因が存在する場合であっても、客観的な信用度に基づいてユーザ向け代金が算出されるため、ある程度の需要が見込まれ、参入障壁が軽減され、ある程度の販売機会を得ることができる。また、サービス提供の実行よりも先に、支払い代金（ユーザ向け代金から所定手数料を引いた金額）を受け取ることができるため、受け取った代金を使って事業活動（例えば、商品の製造・研究開発、サービスの検討・拡充など）を行うことができる。

なお、上記の実施形態の説明で用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に(例えば、有線及び／又は無線)で接続し、これら複数の装置により実現されてもよい。

例えば、上記の実施形態におけるサーバ１０は、上述したサーバ１０の処理を行うコンピュータとして機能してもよい。図１０は、サーバ１０のハードウェア構成の一例を示す図である。上述のサーバ１０は、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。

なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。サーバ１０のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

サーバ１０における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信や、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。

プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。例えば、サーバ１０の各機能部は、プロセッサ１００１を含んで実現されてもよい。

また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュールやデータを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、サーバ１０の各機能部は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。上述の各種処理は、１つのプロセッサ１００１で実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。

メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ＲＯＭ）、ＲＡＭ（Random Access Memory）などの少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明の一実施形態に係る方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。

ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Compact Disc ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク)、スマートカード、フラッシュメモリ(例えば、カード、スティック、キードライブ)、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及び／又はストレージ１００３を含むデータベース、サーバその他の適切な媒体であってもよい。

通信装置１００４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。例えば、上述のサーバ１０の各機能部は、通信装置１００４を含んで実現されてもよい。

入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。

また、プロセッサ１００１やメモリ１００２などの各装置は、情報を通信するためのバス１００７で接続される。バス１００７は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。

また、サーバ１０は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。

以上、本実施形態について詳細に説明したが、当業者にとっては、本実施形態が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本実施形態は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本実施形態に対して何ら制限的な意味を有するものではない。

本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。

入出力された情報などは特定の場所(例えば、メモリ)に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報などは、上書き、更新、または追記され得る。出力された情報などは削除されてもよい。入力された情報などは他の装置へ送信されてもよい。

判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：trueまたはfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。

本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。

ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。

また、ソフトウェア、命令などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線（ＤＳＬ）などの有線技術及び／又は赤外線、無線及びマイクロ波などの無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び／又は無線技術は、伝送媒体の定義内に含まれる。

本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。

また、本明細書で説明した情報、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。

移動通信端末は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。

本明細書で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。

本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

「含む（include）」、「含んでいる（including）」、およびそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える(comprising)」と同様に、包括的であることが意図される。さらに、本明細書あるいは特許請求の範囲において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。

本明細書において、文脈または技術的に明らかに1つのみしか存在しない装置である場合以外は、複数の装置をも含むものとする。本開示の全体において、文脈から明らかに単数を示したものではなければ、複数のものを含むものとする。

１…通信システム、１０…サーバ、１１…受信部、１２…信用度ＤＢ、１３…取得部、１４…算出部、１５…提示部、１６…サービス提供部、１７…確認部、２０…端末、３０…決済事業者サーバ、３１…提示部、３２…信用度ＤＢ、３３…取得部、３４…算出部、３５…処理部、３６…確認部、４０…販売者サーバ、４１…販売処理部、４２…購入履歴ＤＢ、５０…決済事業者サーバ、５１…受信部、５２…取得部、５２Ａ…信用度ＤＢ、５３…算出部、５４…提示部、５５…送信部、５６…請求処理部、５７…支払確認部、５８…支払処理部、５９…完了確認部、１００１…プロセッサ、１００２…メモリ、１００３…ストレージ、１００４…通信装置、１００５…入力装置、１００６…出力装置、１００７…バス。

Claims (4)

1. ユーザの端末と販売者のサーバとの間で取引されたサービス提供が完了した後の決済を行う情報処理装置であって、
   前記サービス提供に応じた既定の代金を請求する請求情報を前記端末へ提示する提示部と、
   前記ユーザに関する信用度を取得する取得部と、
   前記既定の代金を、前記取得部により取得された信用度に基づいて増減させることで、前記販売者への支払金額を算出する算出部と、
   前記提示部により提示された代金が支払われたことを確認する確認部と、
   前記確認部により前記代金が支払われたことが確認されたか否かに関わらず、前記算出部により算出された支払金額を前記販売者へ支払う処理を行う処理部と、
   を備える情報処理装置。
2. 前記算出部は、前記信用度として、予測デフォルト率を用いて、前記既定の代金を増減させる、
   請求項１に記載の情報処理装置。
3. 前記算出部は、さらに、
   前記サービス提供に係る商品の特性又はサービスの特性に応じた調整を加えることで、前記既定の代金を増減させる、
   請求項２に記載の情報処理装置。
4. ユーザの端末と販売者のサーバとの間で取引されたサービス提供が完了した後の決済を行う情報処理装置、により実行される決済方法であって、
   前記サービス提供に応じた既定の代金を請求する請求情報を前記端末へ提示するステップと、
   前記ユーザに関する信用度を取得するステップと、
   前記既定の代金を、取得された信用度に基づいて増減させることで、前記販売者への支払金額を算出するステップと、
   提示された代金が支払われたことを確認するステップと、
   前記代金が支払われたことが確認されたか否かに関わらず、算出された支払金額を前記販売者へ支払う処理を行うステップと、
   を備える決済方法。

Images