JP2020187584A - 複数の支払・決済手段を用いた請求・決済システム、方法およびプログラム - Google Patents

Abstract

【課題】複数の支払・決済手段を用いた請求・決済システム、方法およびプログラムを提供する。【解決手段】請求・決済システムは、複数の支払・決済手段を登録し、請求者情報、被請求者情報、および請求金額を含む請求処理要求を受信し、複数の支払・決済手段および請求処理要求に基づいて、支払・決済手段の適用優先順位を決定し、請求処理要求、支払・決済手段の適用優先順位に基づいて、決済処理要求を送信し、決済処理が未完了となった場合、支払・決済手段の適用優先順位の高い順に決済処理要求の送信を繰り返す、ように構成されたプロセッサを備える。【選択図】図７

Description

本発明は、複数の支払・決済手段を用いた請求・決済に係るシステム、方法およびプログラムに関する。

近時、クレジットカードに加えて、リアルタイム口座振替サービスやウォレットアプリケーション、電子マネー等の普及に合わせて、リアルタイムベースの決済処理が急速に普及・進展している。リアルタイムベースの決済処理と比較して、決済リードタイムの大きい従来型の支払・決済手段としては、事後的・月次の口座引落や、手形・小切手、銀行振込・送金等が挙げられる。

決済処理の多様化が進んでいる一方で、例えば病院、診療所等の医療機関において、外来診療時の会計に関する待ち時間の長さがしばしば問題になっている。診療後の長い待ち時間を解消するために、従来から自動精算機の設置、事後的な月次の口座引落しによる診療費決済、または病院等の診察券と関連付けたクレジットカード決済が試みられている。

特開２００６−２９３７５２号公報 特開２００５−１８２７０９号公報 特開２００６−００４４０４号公報 特開２００３−０６７４８４号公報

しかしながら、例えば自動精算機は、自動精算機に長い行列ができる等根本的な改善には至っておらず、機器導入コストの高さの課題が残る。事後的な月次の口座引落しは、残高不足による督促のコスト・手間および診療費の回収不能リスクに加えて、月次処理であることから請求から資金回収までの期間が数週間から一か月程度必要となり、病院の資金繰りを悪化させる要因となる。

特許文献１に記載された発明は、医療機関にかかる経費を患者が支払う際に、診察券と各種カードを関連付けることによって、会計の長時間の待ち時間の解消を図る技術が開示されている。しかしながら、クレジットカード等による決済は、カード会社に支払う数パーセントの決済手数料による収益悪化、支払限度額の超過による督促のコスト・手間および診療費の回収不能リスクの課題が残る。また、診察券が増加するほど、各種カードと関連付ける手間も増加し、特定の医療機関のみに対応することから汎用的に使用できるものではない。

特許文献２に記載された発明は、医療機関等に予納口座を開設し、診療費を予納口座から都度引き落とすことによって、患者が診療終了後すぐに医療機関を退出可能とする技術が開示されている。また、特許文献３に記載された発明は、医療費が算出される前にオーソリを依頼し、オーソリの結果に応じて患者等の早帰りを判定する技術が開示されている。しかしながら、特許文献２および３に記載された発明は、残高不足等が発生した場合には使用できず、会計に係る長時間の待ち時間は解消されない、または督促事務が発生してしまう等の課題が残る。

特許文献４に記載された発明は、少額支払用口座の残高から優先的に支払を行い、残高不足の場合は、信用供与による所定金額の残高増額を行う技術が開示されている。特許文献４に記載された発明は、小額支払い用口座に残高不足が発生しても支払処理に移行することができるが、いわゆるチャージ処理を行うものであり、支払・決済手段の自由度が低い。

本発明はこのような課題に対し、残高不足等による診療費等の回収不能リスクを低減できるシステムを提供する。

本発明の一様態である、請求・決済システムは、複数の支払・決済手段を登録し、請求者情報、被請求者情報、および請求金額を含む請求処理要求を受信し、複数の支払・決済手段および請求処理要求に基づいて、支払・決済手段の適用優先順位を決定し、請求処理要求、支払・決済手段の適用優先順位に基づいて、決済処理要求を送信し、決済処理が未完了となった場合、支払・決済手段の適用優先順位の高い順に決済処理要求の送信を繰り返す、ように構成されたプロセッサを備える。

本発明によれば、複数の支払・決済手段を使用して、自動的に順次決済処理を試行することによって、残高不足等による督促のコスト・手間および診療費等の回収不能リスクが低減される。

また、決済処理は、請求者と被請求者とが非対面で処理可能であるため、被請求者（患者、サービスの利用者等）は会計手続きのために窓口、レジ等に立ち寄る必要がなく、会計にかかる時間を短縮できる。また、自動精算機等の高額な専用機器を導入する必要はなく、リアルタイム口座振替サービスやクレジットカード等のリアルタイムベースの支払・決済手段を用いることによって、病院等の請求者側への代金精算サイクルも短縮化することが可能である。

このような複数の支払・決済手段の登録をもとにした請求システム（以降、「複数番号預り決済システム」という）は、会計待ち時間を「０」にする病院診療費決済だけでなく、無人店舗・無人キオスクにおける決済、電力、水道等の公共料金の支払等、物品・サービスの提供と代金支払が非同期に行われる決済シーンに広く適用可能であり、更には、店頭決済やインターネットショッピング等にも適用可能である。

さらに、このような「複数番号預り決済システム」は、利用者にとって複数の支払・決済手段を登録する手間が発生等も考慮すると、特定の企業・団体が自身のためのシステムとして個別に構築し運用する方法以外に、より汎用的に使用される、独立した複数番号預り決済サービスとして構築・運用することも可能である。本明細書では、このように複数の企業・団体等によって共用される方式の決済サービスを「独立した複数番号預り決済サービス」という。

本発明の一実施形態に係る「複数番号預り決済システム」を含む構成を例示する図である。 本発明の一実施形態に係るエンドユーザー・デバイスの構成を例示する図である。 本発明の一実施形態に係る独立した複数番号預り決済サービスを例示する概念図である。 本発明の一実施形態に係る決済優先順位の決定方法など具体的な機能を例示する図である。 本発明の一実施形態に係る複数の支払・決済手段の登録に関する処理シーケンスを例示する図である。 本発明の一実施形態に係る複数の支払・決済手段の登録に関する処理シーケンスを例示する図である。 本発明の一実施形態に係る実際の決済処理に係る処理シーケンスを例示する図である。 本発明の一実施形態に係る請求者デバイスに表示される画面を例示する図である。 本発明の一実施形態に係るエンドユーザー・デバイスに決済通知の画面を例示する図である。 本発明の一実施形態に係るエンドユーザー・デバイスに決済明細の画面を例示する図である。

以下、図面を参照しながら本発明の実施形態について詳細に説明する。複数の図面において同一の符号は同一の要素を表し、重複した説明は省略する。

図１は、本発明の一実施形態に係る「複数番号預り決済システム」を含む構成を例示する図である。図１は概略的に、請求者デバイス１００が、ネットワーク１１０を介して管理サーバ１２０に接続されることを例示している。図１はまた、エンドユーザー・デバイス１４０が、ネットワーク１３０を介して管理サーバ１２０に接続され、また、管理サーバ１２０がネットワーク１５０を介して金融機関サーバ１６０に接続されることを例示している。

請求者デバイス１００は、請求者により操作されるデバイスであり、例えば、ＰＣ、タブレット、スマートフォン、またはサーバ等とすることができる。請求者デバイス１００は、請求者情報、被請求者情報、および請求金額を含む請求処理要求を管理サーバ１２０に送信することができる。請求者情報は、資金決済に必要な情報（金融機関名、本・支店名、口座番号、名義等）を含み得る。被請求者情報は、支払・決済を行う者を特定するための顧客ＩＤ、患者ＩＤ等を含み得る。

管理サーバ１２０は、１つまたは複数のサーバで構成され、請求者デバイス１００から請求処理要求を受信することができる。管理サーバ１２０は、登録されている複数の支払・決済手段から、適用優先順位を判定して、優先順位第一位の支払・決済手段を用いた決済処理を行う。決済処理は、金融機関サーバ１６０に口座番号やクレジットカード番号、請求者情報、および請求金額を含む決済処理要求等を含む決済処理要求を送信することにより行われ得る。決済処理が残高不足等の理由により処理未完了となった場合、所定の順番に従って次優先度をもつ支払・決済手段を用いて決済処理を実行する。管理サーバ１２０は、決済処理が完了するまで優先順位に基づいて決済処理の試行を繰り返す。また、管理サーバ１２０は、エンドユーザー・デバイス１４０から複数の支払・決済手段の登録を受付け、データベース１２１に記録することができる。

また、管理サーバ１２０は、エンドユーザーによって登録された支払・決済手段の内容、および金融機関サーバ１６０に対して発行した決済処理の結果を、データベース１２１に記録することができる。これらの記録内容は、ネットワーク１１０を介して請求者デバイス１００から、またはネットワーク１３０を介してエンドユーザー・デバイス１４０から参照することができる。データベース１２１はまた、支払・決済手段ごとのポイント付与額やキャッシュバック率、手数料、キャンペーン等の情報、請求者が受入可能な支払・決済手段等の任意の情報を記録することができる。

エンドユーザー・デバイス１４０は、エンドユーザーにより操作されるデバイスであり、例えば、ＰＣ、タブレット、スマートフォン等とすることができる。エンドユーザーは、エンドユーザー・デバイス１４０を用いて、支払に用いる複数の支払・決済手段を管理サーバ１２０に送信することができる。複数の支払・決済手段は、例えば銀行口座、クレジットカード、電子マネー、ウォレットアプリケーションのアカウント等を含む。エンドユーザーはまた、エンドユーザー・デバイス１４０を用いて、支払・決済手段の適用優先順位の設定、決済処理結果照会要求等、任意の情報を管理サーバ１２０に送信することができる。

また、エンドユーザーは、エンドユーザー・デバイス１４０を用いて、ネットワーク１３０を介して、管理サーバ１２０において処理された決済処理の結果を受信するか、または参照できる。

金融機関サーバ１６０は、管理サーバ１２０からの決済処理要求を受付け、決済処理を実行し、決済処理の結果を管理サーバ１２０に送信する。決済処理は、請求者と被請求者とが非対面で処理可能であるため、被請求者（患者、サービスの利用者等）は会計手続きのために窓口、レジ等に立ち寄る必要がなく、会計にかかる時間を短縮できる。

ネットワーク１１０は、例えばインターネット等、請求者デバイス１００と管理サーバ１２０との間で相互通信可能な周知のネットワークとすることができ、特に限定されることはない。ネットワーク１３０は、例えばインターネット等、管理サーバ１２０とエンドユーザー・デバイス１４０との間で相互通信可能な周知のネットワークとすることができ、特に限定されることはない。ネットワーク１５０は、例えばインターネット等、管理サーバ１２０と金融機関サーバ１６０との間で相互通信可能な周知のネットワークとすることができ、特に限定されることはない。

図２は、本発明の一実施形態に係るエンドユーザー・デバイス１４０の構成を例示する図である。エンドユーザー・デバイス１４０は、概略的に、ＩＦ部１４１、表示部１４２、入力受付部１４３を備える。

ＩＦ部１４１は、管理サーバ１２０から、エンドユーザー・デバイス１４０に表示する為の登録済支払・決済手段に関する情報、または決済処理結果に関する情報を受信するインタフェースである。また、エンドユーザー・デバイス１４０は、ＩＦ部１４１を介して、エンドユーザーが登録する複数の支払・決済手段等を管理サーバ１２０に送信することができる。

表示部１４２は、ディスプレイ装置であり、エンドユーザーが登録した複数の支払・決済手段に関する情報、決済処理結果に関する情報等を表示することができる。

入力受付部１４３は、エンドユーザーによる入力を受け付けることができる。入力内容は、複数の支払・決済手段を登録する操作、決済処理結果の範囲を指定する操作等である。

図３は、本発明の一実施形態に係る独立した複数番号預り決済サービスを例示する概念図である。図３は、「複数番号預り決済システム」を特定の企業・団体が自身のために構築し運用するものではなく、汎用的なサービス（「独立した複数番号預り決済サービス」）として運営する場合の概念図を示している。

一般に、銀行口座、クレジットカード、電子マネー、ウォレットアプリケーションのアカウント等を含む複数の支払・決済手段を登録する作業は、エンドユーザーにとって手間のかかる作業である。また、クレジットカード番号等、これらの支払・決済手段に係る情報の管理には、高度なセキュリティ対策を要するため、多くの管理サーバに散在するかたちで管理するのは好ましくなく、単一のセキュアな管理サーバで集中管理する方式が望ましい。

３０１は、現状の一般的な支払・決済手段登録の方式を例示している。３０１で例示するように、エンドユーザーは、クレジットカード番号等を様々なＥＣ（electronic commerce）ショップに登録している。ここでは同一のクレジットカード番号が複数のＥＣショップに登録されている場合等も含まれる。また、支払・決済用スマートフォンアプリケーションにも複数の支払・決済手段を登録している場合がある。このように、現状、エンドユーザーは複数の支払い・決済手段を多くのサイトやサーバに散在させたかたちで登録している。

３０２は、複数の支払・決済手段を登録し、これらをまとめて一つの仮想的なアカウントとして設定する方式を例示している。このような複数の支払・決済手段をまとめて登録する方法には（１）支払・決済手段の登録が一箇所（一回）で済むことにより登録の手間が省ける、（２）クレジットカード番号等の重要情報をセキュアに集中管理することができる、（３）クレジットカード番号、口座番号、クレジットカード有効期限等の支払・決済手段の決済情報の属性情報の変更時も一箇所（一回）で済む、といったメリットがある。

図４は、「独立した複数番号預り決済サービス」が備え得る機能を例示している。

４０１で例示するように、エンドユーザーが「独立した複数番号預り決済サービス」を利用する場合、エンドユーザーは、複数の支払・決済手段を集合的に管理する仮想的な一つのアカウントを特定するために、アカウントごとにアカウントＩＤ番号、またはこれに相当する情報（以下、総称して「アカウントＩＤ番号」という）を設定することが考えられる。また、アカウントＩＤ番号等を、ＥＣショップや病院の会計システム等の個別のシステム／サービスに登録する際には、アカウントに関連付けられたパスワード等の認証手段を用いることが想定される。さらに、このアカウントに対してカード等を発行してもよい。

４０２は、「独立した複数番号預り決済サービス」を用いて、決済を行う際の優先順位を適用するパターンを例示している。

４０２Ａは「独立した複数番号預り決済サービス」を利用して決済を行う際に、エンドユーザーが、優先する支払・決済手段の優先順を予め設定し、設定された順番で支払・決済手段の適用優先順位が決定される方式である。

４０２Ｂは、「独立した複数番号預り決済サービス」を利用して決済を行う際に、クレジットカード等のポイントの付与額、エンドユーザーが支払う手数料金額等の、エンドユーザー側のメリットを最優先で判定し、優先する支払・決済手段を決定する方式である。具体的にはモール型ＥＣショップで買い物をする際、当該ＥＣモール自身が発行するクレジットカードが登録されている場合は、ポイント付与率の高さを評価して、当該クレジットカードを支払・決済手段として優先適用することが挙げられる。

なお、支払先ごとに異なる場合があるクレジットカード等のポイントの付与額やエンドユーザーが支払う手数料の額等のエンドユーザーにとってのメリットは、一般にエンドユーザーが調べれば分かる情報であるが、手間と時間がかかるため現実的ではない。４０２Ｂの方式は、エンドユーザーの手間や時間をかけずに、エンドユーザーにとって最もメリットの大きい支払・決済手段を自動選択できるため、エンドユーザーはこの方式を選好する可能性がある。

４０２Ｃは、「独立した複数番号預り決済サービス」を利用して決済を行う際に、請求者が支払う必要のある手数料の金額等について、請求者側のメリットを最優先で判定して、支払・決済手段を決定する方式である。

一般に、支払・決済手段には、金融機関等に支払う決済手数料が固定金額となっているものと料率（パーセンテージ）で決定されるものがあり、それぞれの金額や料率も支払・決済手段ごとに一様ではない。

例えば、手数料金額が固定で１５０円の場合、価格３００円等の少額商品であれば請求者である商品・サービスの提供者等には粗利益がマイナスとなるケースも考えられる。このような少額商品の場合は、例えば料率が３％（パーセンテージ型）である支払・決済手段が請求者にとって有利であり、価格が３００円の場合の手数料金額が９円となる。

一方、商品・サービスの価格は高額の場合は、一般に手数料金額が固定の支払・決済手段が、請求者にとって有利となる。例えば３万円の商品の場合、手数料率が３％の場合は、請求者が金融機関等に支払う手数料は９００円となるが、決済手数料が１５０円で固定の場合は、請求者にとっては固定手数料の方が大幅に有利となる。

このように、どの支払・決済手段で支払われるかは商品・サービスの提供者等である請求者にとっては重要な問題である一方で、従来、どの支払・決済手段で支払うかは消費者である支払者に委ねられてきた。このような支払・決済手段の選択権を請求者側が持てるようになるということは従来の慣習を打破する大きな転換点になる。

一方で、このように支払・決済手段の選択を請求者に委ねるということは商慣習に反するものであり、また支払者側が意図しない支払・決済手段から支払われる可能性があるという点から、支払者から忌避される可能性がある。しかしながら、多くの場合決済手数料は商品・サービスの提供者等である請求者側から徴収されるため、支払者にとって直接的な金銭損害にはなりにくく、また、この方式４０２Ｃをとった場合は、支払者である消費者に別途のポイント付与等のメリットを提供することによって、支払者の忌避感、デメリットを緩和する方法等が考えられる。

４０２Ｄの方式は、４０２Ａ〜４０２Ｃ以外の方式、または、４０２Ａ〜４０２Ｃの方式を複合化させたものである。

具体的には、消費者の支払・決済手段の使い分けにより、高額商品にはクレジットカードを選択し、少額商品には銀行口座を用いるなど、金額階層別に支払・決済手段の優先度を設定する方式等が考えられる。

また、４０２Ｃで例示するような「請求者のメリットを優先」する方式を基礎として、支払者に手数料負担が生じ得る場合に限り、他の方式を設定する方式が考えられる。

また、ネットショッピング、店頭決済、病院における診療費の支払等、使途・支払先種別ごとに、４０２Ａ〜４０２Ｃの方法を設定する等の方法等も考えられるが、これらに限定されない。

４０３は、第一の支払・決済手段等優先選択された支払・決済手段が残高不足等の理由により決済不能となった場合の次の処理のパターンを例示したものである。

４０３Ａの「全額決済型」は、優先する支払・決済手段が残高不足等の事由により決済できなかった場合は、決済を行わず次の優先度をもつ支払・決済手段で全額支払いを行う方式である。

４０３Ｂの「分割決済型」は、優先する支払・決済手段が残高不足等の事由により決済できなかった場合は、この支払・決済手段の残高の範囲内で決済を行い、残額を次の支払・決済手段で支払う方式である。なお、この場合、各支払・決済手段の残高が照会できれば効率的に処理が実行できるが、この残高照会機能がなくても、減額して決済を試みる等の処理を繰り返すことによって、この４０３Ｂの「分割決済型」の処理を実現できる。

なお、４０３Ａの「全額決済型」、４０３Ｂの「分割決済型」には一定の残高を残して次の優先度をもつ支払・決済手段で決済を行う等様々な中間的な方式があり得る。一定の残高は、請求金額の所定の割合から算出された額としてもよい。エンドユーザーによって、それぞれの支払・決済手段の支払限度額が指定されている場合、支払限度額に達した請求金額を他の支払・決済手段で支払いを行うようにしてもよい。

４０４は、「独立した複数番号預り決済サービス」が備える、その他の機能を例示したものである。

４０４で例示するように、「独立した複数番号預り決済サービス」を運営する場合は、銀行口座、クレジットカード、クレジットカードのブランド、電子マネーブランド等、商品・サービスの提供者等である企業・店舗が受入可能な支払・決済手段の判定を行い、これに応じて支払・決済手段を絞り込む機能等が必要になるといった例を示しているが、これらに限定されない。

図５は、本発明の一実施形態に係る複数の支払・決済手段の登録に関する処理シーケンスを例示する図である。図５は、エンドユーザーが、エンドユーザー・デバイス１４０を用いて、「複数番号預り決済システム」に対して複数の支払・決済手段を登録するシーケンスを例示するものである。図５のシーケンスは、「複数番号預り決済システム」が病院を含め特定の企業・団体等が、自身のために個別に当該システムを構築され運用される場合、または「独立した複数番号預り決済サービス」のいずれにも適用できる。

Ｓ５０１：エンドユーザーは、エンドユーザー・デバイス１４０を用いて、商品・サービスの代金決済に用いる第一の支払・決済手段の登録指示を送信する。この場合の支払・決済手段の種類は、銀行口座、クレジットカード、電子マネー、ウォレットアプリケーションのアカウント等があり得るが、これらに限定されない。

Ｓ５０２：管理サーバ１２０は、エンドユーザー・デバイス１４０からの第一の支払・決済手段の登録指示を受けて、第一の支払・決済手段の情報を登録する。なお、図５では明記していないが、管理サーバ１２０は、登録された支払・決済手段の有効性、正当性を確認するため、ネットワーク１５０を通じて、登録された支払・決済手段の口座番号、クレジットカード番号、有効期限、セキュリティコード、暗証番号、パスワード等を用いて金融機関サーバ１６０に問合せ電文／確認電文を送出し、その応答電文の内容を確認してもよい。

Ｓ５０３：エンドユーザーは、エンドユーザー・デバイス１４０を用いて、商品・サービスの代金決済に用いる第二の支払・決済手段の登録指示を送信する。第二の支払・決済手段の支払・決済手段の種類は「Ｓ５０１」と同様である。

Ｓ５０４：管理サーバ１２０は、エンドユーザー・デバイス１４０からの第二の支払・決済手段の登録指示を受けて、第二の支払・決済手段の情報を登録する。登録された支払・決済手段の有効性、正当性の確認処理は「Ｓ５０２」と同様である。

Ｓ５０Ｎ：エンドユーザーは、エンドユーザー・デバイス１４０を用いて、商品・サービスの代金決済に用いる第ｎ番目以降の支払・決済手段の登録指示を送信する。第ｎ番目の支払・決済手段の種類は「Ｓ５０１」と同様である。

Ｓ５０Ｎ＋１：管理サーバ１２０は、エンドユーザー・デバイス１４０からの第ｎ番目以降の支払・決済手段の登録指示を受けて、第ｎの支払・決済手段の情報を登録する。登録された支払・決済手段の有効性、正当性の確認処理は「Ｓ５０２」と同様である。

なお、図５には表記していないが、このエンドユーザーによる支払・決済手段の登録の段階で、図４の４０２、４０３で例示したような支払・決済手段の適用優先順位の論理、および全額決済、分割決済等の決済処理方法の登録を行ってもよい。

図６は、本発明の一実施形態に係る複数の支払・決済手段の登録に関する処理シーケンスを例示する図である。

図６のシーケンスは、図５で例示したような複数の支払・決済手段を個別に登録する場合とは異なり、登録された複数の支払・決済手段を集合的に一つのアカウントとして登録するシーケンスを例示している。

「独立した複数番号預り決済サービス」では、複数の支払・決済手段をまとめて、これらに対して一つのアカウントＩＤ番号等が付与されるため、図６では、このアカウントＩＤ番号等を、商品・サービスの提供者等である請求者のシステムに登録するシーケンスを例示している。

Ｓ６０１：エンドユーザーは、エンドユーザー・デバイス１４０を用いて、商品・サービスの対価の代金決済に用いる「独立した複数番号預り決済サービス」のアカウントＩＤ番号等を含む登録指示を送信する。

エンドユーザーが「独立した複数番号預り決済サービス」のアカウントＩＤ番号等を登録する場合は、他者による悪用を防止するためにパスワード等の入力を必須としてもよい。

Ｓ６０２：管理サーバ１２０は、エンドユーザー・デバイス１４０からの「独立した複数番号預り決済サービス」のアカウントＩＤ番号等、およびパスワード等の入力を受付け、正当性を確認し、データベース１２１に記録する。

Ｓ６０３：管理サーバ１２０は、登録の結果をエンドユーザー・デバイス１４０に送信する。エンドユーザーは、エンドユーザー・デバイス１４０を用いて登録の結果を確認する。

なお、図６には表記していないが、このエンドユーザーによる「独立した複数番号預り決済サービス」のアカウントＩＤ番号等の登録の段階で、図４の４０２、４０３で例示したような支払・決済手段の適用優先順位の論理、および全額決済、分割決済等の決済処理方法の登録を行ってもよい。

図７は、本発明の一実施形態に係る実際の決済処理に係る処理シーケンスを例示する図である。

図７は、特定の企業・団体等が自身のために構築した「複数番号預り決済システム」の場合、または汎用的な「独立した複数番号預り決済サービス」の場合のいずれでも、ほぼ同様のシーケンスになる。

Ｓ７０１：商品・サービスの提供者等である請求者は、請求者デバイス１００を用いて、請求者情報、被請求者情報を特定する情報、および請求金額（決済額）を含む請求明細を入力する。ネットショッピング等でプロセスが自動化されている場合、請求明細の登録処理は、人手を介することなくサーバ等によって自動的に実行されてもよい。

Ｓ７０２：請求者デバイス１００は、請求明細を含む請求処理要求を管理サーバ１２０に送信する。ネットショッピング等でプロセスが自動化されている場合、請求者デバイス１００による処理は、サーバ等によって自動的に実行されてもよい。

Ｓ７０３：管理サーバ１２０は、請求者デバイス１００から受信した請求処理要求、および登録されている支払・決済手段の情報に基づいて、優先順位第一位の支払・決済手段を判定する。優先順位の判定は、図４で例示した４０２Ａから４０２Ｄの論理に基づいてもよい。管理サーバ１２０は、判定された支払・決済手段を管理する金融機関の金融機関サーバ１６０に対して口座番号やクレジットカード番号、請求者情報、および請求金額を含む決済処理要求を送信する。

Ｓ７０４：金融機関サーバ１６０は、受信した決済処理要求に基づいて、指定された口座、クレジットカード番号等から決済処理を試み、決済処理結果をデータベース１６１に記録する。Ｓ７０４では、残高不足等により支払処理が不能に終わった状態を示している。

Ｓ７０５：金融機関サーバ１６０は、決済処理の結果を管理サーバ１２０に送信する。

Ｓ７０６：管理サーバ１２０は、金融機関からの決済処理の結果通知（残高不足等による支払不能）を受けて、第二の優先順位の支払・決済手段を特定し、当該支払・決済手段を管理する金融機関の金融機関サーバ１６０に対して口座番号やクレジットカード番号、請求者情報、および請求金額を含む決済処理要求の電文を送信する。

また、この場合の金融機関は、優先順位第一位の支払・決済手段と同じ金融機関と同じでもよく、異なる金融機関でもよい。図４の４０３Ｂで例示した「分割決済型」の場合、優先順位第一と同じ支払・決済手段について、残高照会を行うか、または決済金額を減額する等により、再度同一の支払・決済手段について決済処理要求を送信してもよい。

Ｓ７０７：優先順位第二位の支払・決済手段に係る金融機関サーバ１６０は、受信した決済処理要求をもとに、指定された口座、クレジットカード番号等から決済処理を試み、決済処理結果をデータベース１６１に記録する。Ｓ７０７では、決済処理が完了した状態を示している。

Ｓ７０８：金融機関サーバ１６０は、決済処理の結果を管理サーバ１２０に送信する。

Ｓ７０９：管理サーバ１２０は、金融機関サーバ１６０から受信した決済処理の結果をデータベース１２１に記録する。

Ｓ７１０：管理サーバ１２０は、決済処理の結果に係る電文をエンドユーザー・デバイス１４０に送信する。エンドユーザーは、この通知によって支払処理の明細および結果を知ることができる。

Ｓ７１１：管理サーバ１２０は、決済処理の結果に係る電文を請求者デバイス１００に送信する。商品・サービスの提供者等である請求者は、この通知によって決済の結果を知ることができる。この通知手段は、ｅメール、ショートメール、プッシュ通知等が考えられるが、これらに限定されない。

Ｓ７１２：エンドユーザーは、Ｓ７１０で決済結果の通知を受け取った後、またはこの通知を受け取らなかった場合でも、エンドユーザー・デバイス１４０を用いて管理サーバ１２０に支払・決済状況を問い合わせることによって、決済結果の明細、履歴等を照会することができる。

図７で例示したように、エンドユーザーによって登録されている複数の支払・決済手段を用いて決済を試みることによって、残高不足等による決済不能、代金回収不能の発生確率を大きく低減させることができる。また、これらに関連する督促事務の手間、コストを低減させることができる。これは商品・サービスの提供者等である請求者にとってのメリットであるだけでなく、被請求者であるエンドユーザーにとっても、未払い代金の精算・送金等に係る手間や手数料が省ける等のメリットがある。さらに、図４の４０２で例示したような適用優先度判定の論理を用いれば、エンドユーザーにとってポイントや手数料等の面においてメリットのある支払・決済手段を自動適用することができ、また、請求者にとっても決済手数料の低減を実現しうる。

図７では、主にリアルタイムベースの決済処理を想定しているが、特に決済処理が不能に終わった場合等、翌日以降に再度決済処理を試みる、または事後的な口座引落し処理等によって精算処理を行うことも可能である。

また、これら一連の処理が、特定の企業・団体のための専用システムではなく、汎用的な「独立した複数番号預り決済サービス」を用いて実行される場合、Ｓ７０２、Ｓ７０３、Ｓ７０６、Ｓ７０９、Ｓ７１０、Ｓ７１２等で記載された管理サーバ１２０の処理が、利用する企業・団体等の外部に存在する汎用的な「独立した複数番号預り決済サービス」の管理サーバを主体に実行されることになる。

このような汎用的な「独立した複数番号預り決済サービス」を用いることにより、商品・サービスの提供者等である請求者は、導入・運営コストを低減させることができる。また同時に、商品・サービス等の利用であるエンドユーザーは、複数のシステムに支払・決済手段を登録する手間を省き、また複数の商品・サービスの提供者等に対する支払履歴を一元的に管理することができるようになる。

図８は、本発明の一実施形態に係る請求者デバイス１００に表示される画面を例示する図である。

８０１では、請求対象（被請求者）であるエンドユーザーの氏名、エンドユーザーのＩＤ番号、請求金額、エンドユーザー・デバイス１４０に表示する利用明細に加えて図４で示したような決済方法、およびエンドユーザーによって登録されている支払・決済手段の一覧が表示されている。また、画面８０１の下部にある「請求確定」ボタンを押下すると、エンドユーザーが登録した支払・決済手段を用いた決済処理が開始されるようにしてもよい。

ネットショップ等プロセスが自動化されている場合、請求者デバイス１００は図８で例示されるような画面を介さずに、サーバの自動処理によって請求処理が実行されてもよい。

図９は、本発明の一実施形態に係る決済完了画面を例示する図である。決済完了画面は、エンドユーザー・デバイス１４０に表示される。

決済完了画面９０１では、エンドユーザーの氏名、支払金額、支払日時、利用明細、支払・決済手段、および備考を表示した画面を例示している。備考は、優先度の高い支払・決済手段が使用されなかった場合の理由、決済履歴を確認可能なＷｅｂページのＵＲＬ等を含めてもよい。

図１０は、本発明の一実施形態に係る決済履歴画面を例示する図である。支払履歴画面は、エンドユーザー・デバイス１４０に表示される。

支払履歴画面１００１では、支払先、決済金額、支払日時、支払明細、支払・決済手段、および備考が表示され、次の明細を参照するためのボタン、支払履歴の一覧表を参照するためのボタンが配置されている画面を例示している。備考は、優先度の高い支払・決済手段が使用されなかった場合の理由等を含めてもよい。

また、「複数番号預り決済システム」は、会計待ち時間を「０」にする病院診療費決済だけでなく、無人店舗・無人キオスクにおける決済、電力、水道等の公共料金の支払等、物品・サービスの提供と代金支払が非同期に行われる決済シーンに広く適用可能であり、更には、店頭決済やインターネットショッピング等にも適用可能である。被請求者情報は、無人店舗・無人キオスクの店頭等に個人認証が可能な機器を設置して、購入前に個人認証を行うことにより得られる。個人認証は、例えばエンドユーザーが所持するスマートフォン等に二次元コードを表示させて、店頭で読み取ること等により行われてもよい。商品はＲＦタグ、バーコード読み取り等により請求金額が確定されてもよい。店頭決済やインターネットショッピング等においても、一回目の決済で残高不足等になった場合、適用優先順位の高い順に、支払・決済手段による決済を自動試行することにより、異なる決済情報の入力の手間がかからない。

１００ 請求者デバイス
１１０、１３０、１５０ ネットワーク
１２０ 管理サーバ
１２１ 管理サーバのデータベース
１４０ エンドユーザー・デバイス
１６０ 金融機関サーバ
１６１ 金融機関サーバのデータベース

Claims (8)

1. 複数の支払・決済手段を登録し、
   請求者情報、被請求者情報、および請求金額を含む請求処理要求を受信し、
   前記複数の支払・決済手段および前記請求処理要求に基づいて、支払・決済手段の適用優先順位を決定し、
   前記請求処理要求、前記支払・決済手段の適用優先順位に基づいて、決済処理要求を送信し、決済処理が未完了となった場合、前記支払・決済手段の適用優先順位の高い順に決済処理要求の送信を繰り返す、
   ように構成されたプロセッサを備えた、システム。
2. 前記決済処理要求を送信することは、決済処理が未完了となった場合、前記請求金額を分割して決済処理要求の送信を繰り返す、請求項１に記載のシステム。
3. 決済限度額、前記請求金額の所定の割合から算出された額、または被請求者により指定された支払限度額を上限として前記請求金額を分割した前記決済処理要求を送信する、請求項２に記載のシステム。
4. 前記支払・決済手段の適用優先順位は、被請求者により設定された順位、ポイント付与率の高さ、手数料の額、またはこれらの組み合わせによって決定される、請求項１に記載のシステム。
5. 前記支払・決済手段の適用優先順位は、請求者が支払うべき決済手数料の額の少ない順に決定される、請求項１に記載のシステム。
6. 前記複数の支払・決済手段を登録することは、独立したシステムにより集中管理される、請求項１から５のいずれか一項に記載のシステム。
7. コンピュータによって実施される方法であって、
   複数の支払・決済手段を登録することと、
   請求者情報、被請求者情報、および請求金額を含む請求処理要求を受信することと、
   前記複数の支払・決済手段および前記請求処理要求に基づいて、支払・決済手段の適用優先順位を決定することと、
   前記請求処理要求、前記支払・決済手段の適用優先順位に基づいて、決済処理要求を送信することであって、決済処理が未完了となった場合、前記支払・決済手段の適用優先順位の高い順に決済処理要求の送信を繰り返す、決済処理要求を送信することと、
   を含む、方法。
8. 請求項７に記載の方法をコンピュータに実行させるためのプログラム。

Images