JP2022099174A - プログラム、情報処理方法、端末、サーバ - Google Patents
プログラム、情報処理方法、端末、サーバ Download PDFInfo
- Publication number
- JP2022099174A JP2022099174A JP2020212995A JP2020212995A JP2022099174A JP 2022099174 A JP2022099174 A JP 2022099174A JP 2020212995 A JP2020212995 A JP 2020212995A JP 2020212995 A JP2020212995 A JP 2020212995A JP 2022099174 A JP2022099174 A JP 2022099174A
- Authority
- JP
- Japan
- Prior art keywords
- information
- terminal
- account
- payment
- user
- 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.)
- Granted
Links
- 230000010365 information processing Effects 0.000 title claims abstract description 14
- 238000003672 processing method Methods 0.000 title claims abstract description 6
- 238000004891 communication Methods 0.000 claims abstract description 198
- 238000012545 processing Methods 0.000 claims description 192
- 238000000034 method Methods 0.000 description 418
- 238000012546 transfer Methods 0.000 description 278
- 230000008569 process Effects 0.000 description 243
- 230000004048 modification Effects 0.000 description 153
- 238000012986 modification Methods 0.000 description 153
- 230000006870 function Effects 0.000 description 113
- 230000000694 effects Effects 0.000 description 57
- 238000010586 diagram Methods 0.000 description 56
- 230000007704 transition Effects 0.000 description 16
- 238000004364 calculation method Methods 0.000 description 13
- 238000012790 confirmation Methods 0.000 description 13
- 230000004044 response Effects 0.000 description 11
- 230000005540 biological transmission Effects 0.000 description 10
- 230000008859 change Effects 0.000 description 8
- 238000013475 authorization Methods 0.000 description 7
- 102100024452 DNA-directed RNA polymerase III subunit RPC1 Human genes 0.000 description 6
- 101000689002 Homo sapiens DNA-directed RNA polymerase III subunit RPC1 Proteins 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 238000001514 detection method Methods 0.000 description 5
- 238000004519 manufacturing process Methods 0.000 description 4
- 230000001133 acceleration Effects 0.000 description 3
- 230000001186 cumulative effect Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000005259 measurement Methods 0.000 description 3
- 230000006855 networking Effects 0.000 description 3
- 101100365087 Arabidopsis thaliana SCRA gene Proteins 0.000 description 2
- 101100438139 Vulpes vulpes CABYR gene Proteins 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000005401 electroluminescence Methods 0.000 description 2
- 235000013305 food Nutrition 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 238000010079 rubber tapping Methods 0.000 description 2
- 239000007787 solid Substances 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
- 238000003491 array Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 239000013078 crystal Substances 0.000 description 1
- 239000003814 drug Substances 0.000 description 1
- 235000013410 fast food Nutrition 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 239000000825 pharmaceutical preparation Substances 0.000 description 1
- 229940127557 pharmaceutical product Drugs 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
Images
Landscapes
- Telephonic Communication Services (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
本発明の第2の態様によると、端末の情報処理方法は、端末のユーザにより、後払いで購入された商品またはサービスの購入情報を端末の通信部によって受信することと、購入情報と、端末のユーザに関連する複数の口座情報とを端末の表示部に表示することと、端末のユーザにより、複数の口座情報のうちの第1口座情報が選択されたことに基づき、購入情報の少なくとも一部の支払いを第1口座情報に関連する第1口座で支払うことに関する第1情報を表示部に表示することとを含む。
本発明の第3の態様によると、端末は、端末のユーザにより、後払いで購入された商品またはサービスの購入情報を受信する通信部と、購入情報と、端末のユーザに関連する複数の口座情報とを表示する表示部と、端末のユーザにより、複数の口座情報のうちの第1口座情報が選択されたことに基づき、購入情報の少なくとも一部の支払いを第1口座情報に関連する第1口座で支払うことに関する第1情報を表示部に表示する制御を行う制御部とを備える。
本発明の第4の態様によると、端末は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、端末のユーザにより、後払いで購入された商品またはサービスの購入情報を端末の通信部によって受信することと、購入情報と、端末のユーザに関連する複数の口座情報とを端末の表示部に表示することと、端末のユーザにより、複数の口座情報のうちの第1口座情報が選択されたことに基づき、購入情報の少なくとも一部の支払いを第1口座情報に関連する第1口座で支払うことに関する第1情報を表示部に表示することとを実行する。
本発明の第5の態様によると、端末と通信するサーバは、端末のユーザにより後払いで購入された購入情報を受信し、購入情報を端末に送信し、購入情報の少なくとも一部を、端末のユーザに関連する複数の口座のうちの第1口座によって支払うことに関する情報を端末から受信する通信部を備える。
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
(1)端末&サーバ
(2)サーバ
(3)端末
この場合、システムの制御部は、端末の制御部とサーバの制御部とのうちの少なくともいずれか一方とすることができる。つまり、限定ではなく例として、(1A)端末の制御部のみ、(1B)サーバの制御部のみ、(1C)端末の制御部とサーバの制御部との両方、のうちのいずれかを、システムの制御部とすることができる。
また、(1C)では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにしてもよい。この場合、制御等の割り当て(割り振り)は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
また、(2C)では、限定ではなく例として、サーバシステムが行う制御等のうちの一部の制御等を一のサーバが行うようにし、残りの制御等を他のサーバが行うようにしてもよい。この場合、制御等の割り当て(割り振り)は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
このシステムは、限定ではなく例として、以下のようなシステムとすることができる。
・サーバの機能を端末に持たせるシステム(分散システム)。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース等の近距離無線通信技術を用いてP2P(ピアツーピア)方式等で通信を行うことで実現可能である。
なお、サーバとして、上記(2)のサーバシステムを適用することも可能である。
この場合の実施形態は、前述したブロックチェーンの技術等に基づいて構成することが可能である。具体的には、限定ではなく例として、以下の実施形態で説明するサーバに記憶されて管理されるデータを、ブロックチェーン上に保管(格納)する。そして、端末が、ブロックチェーンへのトランザクションを生成し、トランザクションがブロックチェーン上で承認されると、ブロックチェーン上に保管されたデータが更新されるようにすることができる。
限定ではなく例として、第1情報と第2情報とを送信するという場合、第1情報と第2情報とをタイミングを合わせて送信するものと、第1情報と第2情報とをタイミングをずらして送信するものとの両方の概念を含めてよいものとする。
なお、ラグ(タイムラグ)を考慮し、「同時」には「ほぼ同時」を含めてよいものとする。
限定ではなく例として、上記のように第1情報と第2情報とを送信するという場合、第1情報と第2情報とを送信しさえすればよく、同じ目的で第1情報と第2情報とを送信する場合の他、異なる目的で第1情報と第2情報とを送信する場合も含めてよいものとする。
クレジットカードを利用した決済(以下、「クレジットカード決済」と称する。)等による支払いが日常的に利用されている。
本実施形態は、このクレジットカード決済を含む後払いの決済に関する実施形態である。
(1)クレジットカード決済
(2)ツケ払い
(2-1)一括ツケ払いは、限定ではなく例として、設定期間(限定ではなく例として、ひと月の期間)に行われた取引について、一括的に(まとめて)ツケ払いによる支払いを行う方法である。
(2-2)都度ツケ払いは、限定ではなく例として、取引が行われる都度、ツケ払いによる支払いを行う方法である。
・後払いで商品またはサービスが購入されたことを示す情報
・後払いで購入された商品またはサービスの概要や細目を示す情報
・後払いの請求情報
第1実施例は、本開示の手法を、限定ではなく例として、前述した(1)クレジットカード決済によって実現するための基本的な実施例である。
第1実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
銀行には、店舗を有する銀行(郵政グループの銀行等も含む。)の他、限定ではなく例として、インターネット銀行(ネット銀行)も含めることができる。
なお、金融機関として、銀行ではなく、中央金庫、信用金庫等の金融機関を適用することも可能である。
また、支払い口座は、引き落とし口座や振替口座等と称してもよい。
図1-1は、本実施例における通信システム1Aのシステム構成の一例を示す図である。
通信システム1Aでは、限定ではなく例として、ネットワーク30を介して、クレジットカード会社サーバ10と、1以上の端末20(端末20A,端末20B,端末20C,・・・)と、1以上の店舗端末40(店舗端末40A,店舗端末40B,店舗端末40C,・・・)と、2以上の銀行サーバ50(銀行サーバ50A,銀行サーバ50B,銀行サーバ50C)とが接続される。
クレジットカード会社サーバ10は、クレジットカードサービスサーバ、クレジット支払い管理サーバ、クレジット決済サービスサーバ、クレジット決済管理サーバ、クレジット決済システムサーバ、クレジットサービスサーバ等のように表現することもできる。
本実施形態では、限定ではなく例として、クレジットカード会社サーバ10のユーザを、クレジットカード会社(クレジット決済サービスの事業者)とする。
本実施形態では、簡明化のため、カード発行会社と加盟店管理会社とを包括して「クレジットカード会社」と称する。
なお、カード発行会社と加盟店管理会社とは同じ会社としてもよいし、異なる会社としてもよい。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
通信システム1Aに含まれる各装置のHW構成について説明する。
図1-1には、端末20のHW構成の一例を示している。
端末20は、制御部21(CPU:central processing unit(中央処理装置))、記憶部28、通信I/F22(インタフェース)、入出力部23、時計部29A、位置算出用情報検出部29Bを備える。端末20のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、端末20のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末20は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
音出力部26は、音データの出力に利用される。音出力部26は、スピーカなどを含む。
撮像部27は、画像データ(静止画像データ、動画像データを含む。以下同様。)の取得に利用される。撮像部27は、カメラなどを含む。
なお、限定ではなく例として、UWB測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域RF信号を送信することで、端末20を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。
図1-1には、クレジットカード会社サーバ10のHW構成の一例を示している。
クレジットカード会社サーバ10は、制御部11(CPU)、記憶部15、通信I/F14(インタフェース)、入出力部12、表示部13、時計部19を備える。クレジットカード会社サーバ10のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、クレジットカード会社サーバ10のHWは、クレジットカード会社サーバ10のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、クレジットカード会社サーバ10のHWは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
店舗端末40は、店舗の事業者(以下、「店舗事業者」と称する。)が使用・管理する装置である。店舗端末40は、限定ではなく例として、サーバ、パソコン、端末(限定ではなく例として、携帯端末(スマートフォン、PDA等))等によって実現される。
店舗事業者は、本開示における事業者の一例である。
銀行サーバ50のHW構成や、各機能部を構成する部品や回路等は、限定ではなく例として、クレジットカード会社サーバ10等と同様に構成することができるため、図示・説明を省略する。
クレジットカード会社サーバ10は、プログラムPを記憶部15に記憶し、このプログラムPを実行することで、制御部11が、制御部11に含まれる各部としての処理を実行する。つまり、記憶部15に記憶されるプログラムPは、クレジットカード会社サーバ10に、制御部11が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
他の装置についても同様である。
他の装置についても同様である。
他の装置についても同様である。
他の装置についても同様である。
クレジットカード会社サーバ10および/または端末20における処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末20における処理の少なくとも一部、または全部を、クレジットカード会社サーバ10により行う構成としてもよいし、そうでなくてもよい。この場合、端末20の制御部21の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、クレジットカード会社サーバ10で行う構成としてもよいし、そうでなくてもよい。
クレジットカード会社サーバ10における処理の少なくとも一部、または全部を、端末20により行う構成としてもよいし、そうでなくてもよい。この場合、クレジットカード会社サーバ10の制御部11の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末20で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
(1)クレジットカード会社サーバの機能構成
図1-2は、本実施例においてクレジットカード会社サーバ10の制御部11によって実現される機能の一例を示す図である。
制御部11は、限定ではなく例として、記憶部15に記憶されたクレジットカード決済管理処理プログラム151に従ってクレジットカード決済管理処理を実行するためのクレジットカード決済管理処理部111を機能部として含む。
記憶部15には、限定ではなく例として、クレジットカード決済管理処理として実行されるクレジットカード決済管理処理プログラム151と、ユーザ登録データ153と、提携銀行データ155と、提携店舗データ157と、ユーザ管理データベース159とが記憶される。
ユーザ登録データ153には、限定ではなく例として、氏名と、契約者IDと、認証パスワードと、クレジットカード情報と、その他登録情報とが関連付けて記憶される。
この契約者IDは、好ましくはユーザごとに一意な値であり、限定ではなく例として、クレジットカード会社サーバ10によってユーザごとに一意な値(固有の値)が設定されて記憶される。
契約者IDは、端末のユーザに関連付けられた情報であり、端末のユーザに関する情報の一例である。
・住所(または居所):このユーザの住所(または居所)。ユーザがクレジットカード決済サービスを利用する際に登録する住所(または居所)が記憶される。
・電話番号:このユーザの電話番号。限定ではなく例として、端末20のユーザがクレジットカード決済サービスを利用する際に登録する電話番号(限定ではなく例として、端末20の電話番号である端末電話番号)が記憶される。
・メールアドレス:このユーザのメールアドレス。限定ではなく例として、端末20のユーザがクレジットカード決済サービスを利用する際に登録するメールアドレス(限定ではなく例として、端末20のメールアドレスである端末メールアドレス)が記憶される。
提携銀行データ155には、限定ではなく例として、提携銀行IDと、提携銀行名と、提携銀行サーバURIと、その他提携銀行情報とが関連付けて記憶される。
ユーザ管理データベース159Aには、ユーザ登録データ153に記憶されている契約者IDごとの管理データとしてユーザ管理データが記憶される。
なお、この他にも、与信照会結果の情報等を記憶させるようにすることも可能である。
しかし、これはあくまでも一例であり、この他に、購入された商品やサービスの名称、購入数等の情報も店舗から取得可能とし、これらの情報も併せて購入情報として記憶させるようにしてもよいし、しなくてもよい。
口座IDは、銀行口座を識別するための識別番号の他、限定ではなく例として、銀行コード、支店コード、口座番号等の情報を含めてもよい。口座IDによって、この契約者IDのユーザのクレジットカードと紐づけられた銀行口座が特定される。
クレジットカード会社サーバ10は、あらかじめ銀行サーバ50によって発行されて銀行サーバ50から通知された口座振替トークンと、口座振替を要求・依頼する金額(以下、「振替要求金額」と称する。)とに基づいて、この口座IDの銀行口座による口座振替を銀行サーバ50に要求・依頼する。
なお、口座振替トークンは、引き落としトークンやアクセストークン等のように表現してもよい。
そこで、限定ではなく例として、登録銀行口座のうちユーザによってあらかじめ指定された銀行口座を、デフォルトの支払い口座として設定するようにしてもよい。
この場合、デフォルトの支払い口座とは異なる銀行口座が支払い口座として選択されると、その口座IDで支払い口座IDが更新されるようにすることができる。
図1-7は、本実施例における端末20の制御部21により実現される機能の一例を示す図である。
制御部21は、主要な機能部として、限定ではなく例として、端末メイン処理部211を含む。
記憶部28には、限定ではなく例として、端末メイン処理として実行される端末メイン処理プログラム281が記憶される。
図1-9は、本実施例におけるクレジットカード決済サービスの原理を説明するための図であり、クレジットカード決済の流れを図示したものである。
(A-1)端末20のユーザ(客)が、店舗において店舗端末40を用いてクレジットカードによる決済を行う場合
(A-2)端末20のユーザ(客)が、ECサイト(限定ではなく例として、商品やサービスを販売するウェブサイト)において店舗端末40を用いてクレジットカードによる決済を行う場合
与信照会の結果がクレジットカード会社により「承認」された場合(以下では、「与信照会結果:承認」と称する。)、決済金額は一時的に(仮に)確保される。また、与信照会の結果がクレジットカード会社により「否認」された場合(以下では、「与信照会結果:否認」と称するものとする。)、決済金額は確保されない。
与信照会の結果の情報を端末20のみに送信してもよいし、与信照会の結果の情報を店舗端末40と端末20との両方に送信してもよい。
次いで、(4)与信照会結果の情報(与信照会結果:承認)を受信した店舗端末40のユーザ(店員)は、(1)で購入された商品またはサービスを端末20のユーザ(客)に提供する。
ここで、クレジットカード会社サーバ10が店舗に決済金額を支払う手法として、クレジットカード会社が、店舗または店舗端末40に紐づいている銀行の口座に振り込みを行う手法や、クレジットカード会社またはクレジットカード会社サーバ10に紐づいている銀行の口座から店舗または店舗端末40に紐づいている銀行の口座への振替を行う手法等が考えられる。
以下では、限定ではなく例として、端末20が、縦長のディスプレイの表示部24を備えるスマートフォンである場合を例示する。
タップ(タップ操作)とは、限定ではなく例として、ユーザが、タッチパネルが一体的に構成された表示部24(タッチスクリーン)を指やペン先などで軽く叩くように触れる動作、触れてから離す動作である。
図1-10左は、限定ではなく例として、クレジットカード会社(クレジットカード決済サービスの事業者)(限定ではなく例として、「Xクレジットカード会社」、以下、この事業者名を適宜「Xカード」と称する。)から、請求情報として、商品購入情報と、クレジットカード会社のwebページ(限定ではなく例として、支払い口座の設定ページ)へのリンク情報とを含む電子メール(以下、適宜「Eメール」と称する。)を受信した場合に、ユーザA.Aの端末20Aの表示部24に表示される受信Eメール画面である。
また、その下には、受信Eメールの差出人(送信元)を示す差出人表示領域が構成されており、この例では、「From:」の文字と、差出人(この例では「Xカード」)の文字とが差出人表示領域内に表示されている。
本例では、本文表示領域には、限定ではなく例として、本文の見出しとして「ご利用情報」の文字が表示されている。
また、その下には、このクレジットカード決済の商品購入情報が表示されており、限定ではなく例として、購入日を示す「ご利用日」の欄と、購入店舗を示す「ご利用先」の欄と、購入金額を示す「ご利用金額」の欄とが設けられている。この例では、「ご利用日」の欄には「2020/10/28」が、「ご利用先」の欄には「店舗A」が、「ご利用金額」の欄には「10,000円」がそれぞれ表示されている。
具体的には、その下には、クレジットカードに紐づいている銀行口座情報(限定ではなく例として、銀行名、口座番号等)を表示するための銀行口座情報表示領域が構成されており、この例では、A銀行に対応する銀行名として「A銀行」の文字が、その口座番号として「XXXXXXX」の数字が表示されている。また、「B銀行」に対応する銀行名として「B銀行」の文字が、その口座番号として「XXXXXXX」の数字が表示されている。
この「詳細」の欄のリンク情報とは、商品購入情報の詳細な情報を含むクレジットカード会社のwebページへのリンクが張られたリンク情報である。商品購入情報の詳細な情報には、限定ではなく例として、購入日時、購入商品または購入サービスの名称、購入数、購入金額、購入店舗等の情報を含めることができる。
なお、第2アイコンIC2は、第2ボタンとしてもよい。以下同様である。
また、その右には、設定した支払い口座を表示するための領域が構成されており、この例では、「支払い口座」の文字と、A銀行に対応する「A銀行」の文字とが表示されている。
図1-11,図1-12は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、店舗端末40A(店舗Aの店舗端末40)の制御部(不図示)が実行する処理、クレジットカード会社サーバ10の制御部11が実行する処理、A銀行サーバ50A(A銀行の銀行サーバ50)の制御部(不図示)が実行する処理、B銀行サーバ50B(B銀行の銀行サーバ50)の制御部(不図示)が実行する処理の一例を示している。
なお、店舗端末40の制御部が実行する処理については図示を省略する。これは、以下同様である。
なお、実際には、クレジットカードに紐づいている銀行口座は2つとは限らないが、3つ以上とする場合も同様であるため、ここでは図示・説明を省略する。
これは、以下説明する各フローチャート(処理)について同様である。
この場合、通信I/F22によってクレジットカード会社サーバ10から与信照会結果情報を受信すると、制御部21は、受信された与信照会結果情報に基づいて、与信照会結果を表示部24に表示させるようにすることができる。
この場合における「支払い口座設定」とは、限定ではなく例として、取引が行われる都度、その取引について支払い口座を設定することを意味する。
一方、支払い口座設定を行うための入力がなされたと判定した場合(A140:YES)、制御部21は、限定ではなく例として、支払い口座の設定ページに移動するための支払い口座設定要求情報を、通信I/F22によってクレジットカード会社サーバ10に送信する(A150)。この場合、支払い口座設定要求情報には、限定ではなく例として、支払い口座設定ページに移動するための情報として、少なくとも請求情報のうちの取引IDの情報を含めることができる。
支払い口座設定要求情報を受信しなかったと判定した場合(C140:NO)、制御部11は、ステップC180に処理を進める。
限定ではなく例として、商品購入情報(購入日時、購入店舗、購入金額等)や、クレジットカードに紐づいている銀行口座情報(銀行名、口座番号等)、支払い口座を設定するために必要な他の情報(第1アイコン、第2アイコン等)等の情報を含む支払い口座設定画面を表示部24に表示させるなどすることができる。
つまり、本実施例では、クレジットカード会社サーバ10が支払い口座を設定する。
限定ではなく例として、商品購入情報や、支払い口座情報(支払い口座としていずれかの銀行口座が設定されたことを報知する情報等)などの情報を含む支払い口座設定完了画面を表示部24に表示させるなどすることができる。
一方、処理を終了すると判定したならば(A195:YES)、制御部21は、処理を終了する。
口座振替要求条件とは、口座振替を銀行サーバ50に要求(依頼)するための条件であり、限定ではなく例として、「クレジットカード決済における口座振替(引き落とし)日時(限定ではなく例として、毎月25日の24時)になったこと」とすることができる。
具体的には、支払い口座設定データを参照し、支払い口座IDごとに、その支払い口座IDに関連付けて記憶されている取引IDを特定する。そして、取引データを参照し、特定した取引IDに関連付けて記憶されている購入金額を合算した金額を、その支払い口座の振替要求金額として算出する。そして、提携銀行データ155を参照し、支払い口座IDごとに、対応する提携銀行サーバURIを取得し、算出した振替要求金額と、その支払い口座IDに関連付けて記憶されている口座振替トークンとを含む口座振替要求情報を、通信I/F14によって、対応する提携銀行サーバURIをアクセス先として、対応する銀行サーバ50に送信する。
そして、制御部11は、最新の支払い口座設定データを、当月分の支払い口座設定データとして保存する、または消去やリセットする。
一方、処理を終了すると判定したならば(C195:YES)、制御部11は、処理を終了する。
限定ではなく例として、C180のステップを省略し、クレジットカード会社サーバ10の制御部11が、C170の後、C190のステップを実行するようにする。つまり、支払い口座設定処理を行う都度、その取引に対応する購入金額を含む口座振替要求情報を銀行サーバ50に送信するようにする。
同様に、クレジットカードも、必ずしも端末20のユーザを名義人とするクレジットカードである必要はなく、端末20のユーザに関連するクレジットカードであればよい。
詳細は後述するが、限定ではなく例として、(A)法人クレジットカード、(B)家族クレジットカード、等のクレジットカードを適用する場合が、これらの一例である。
また、この場合、購入情報と複数の口座情報とが、同時に表示されるようにしてもよいし、非同時に表示されるようにしてもよい。
また、この場合、購入情報と複数の口座情報とが、両者を各々視認可能な位置関係や態様で表示されるようにしてもよいし、いずれか一方の情報のみを視認可能な位置関係や態様で表示されるようにしてもよい。
限定ではなく例として、一の画面に購入情報を表示した後、この購入情報に重畳(オーバーラップ)するように複数の口座情報を表示するなどしてもよい。
本実施例は、端末20が、自己の端末20のユーザにより、クレジットカード決済やツケ払い等による支払い(限定ではなく、後払いの一例)で購入された商品またはサービスに関する請求情報(限定ではなく、購入情報の一例)を通信I/F22によって受信する。そして、端末20は、受信した請求情報と、自己の端末20のユーザの登録銀行口座情報(限定ではなく、端末のユーザに関連する複数の口座情報の一例)とを表示部24(限定ではなく、端末の表示部の一例)に表示する。そして、端末20は、自己の端末20のユーザにより、登録銀行口座情報に基づき一の口座(限定ではなく、第1口座情報に関連する第1口座の一例)が支払い口座として選択されたことに基づき、支払い口座設定完了情報(限定ではなく、購入情報の少なくとも一部の支払いを第1口座情報に関連する第1口座で支払うことに関する第1情報の一例)を表示部24に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザにより後払いで購入された商品またはサービスを端末のユーザに確認させることができる。また、複数の口座情報のうちの第1口座情報が選択されたことに基づき、購入情報の少なくとも一部の支払いを第1口座情報に関連する第1口座で支払うことを端末のユーザに確認させるとともに、後払いで購入された商品またはサービスの支払いが第1口座から行われるようにすることができる。
また、詳細は後述するが、他のサービスの事業者のサーバ等から受信するようにすることもできる。
このような構成により得られる実施例の効果の一例として、後払いでの購入の各々について、その支払いを、複数の口座情報のうちの端末のユーザによって選択された口座情報に関連する口座から行うことを端末のユーザに確認させるとともに、その支払いが、対応する口座から行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、購入情報のうちの第1購入情報に対して、複数の口座情報のうちから少なくとも一つの口座情報を選択可能であることを、端末のユーザに報知することができる。
このような構成により得られる実施例の効果の一例として、複数の口座情報が、端末のユーザに関連するクレジットカードの情報と関連付けられるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザにより後払いで購入された商品またはサービスの購入情報の少なくとも一部に対する支払いが、端末のユーザによって選択された第1口座情報に関連する第1口座から行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、設定された日、または設定された期日までに、端末のユーザによって選択された口座から後払いの支払いが行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザにより後払いで購入された購入情報を受信した上で、その購入情報を端末に送信して、端末のユーザに通知することができる。また、購入情報の少なくとも一部を、端末のユーザに関連する複数の口座のうちの第1口座によって支払うことに関する情報を端末から受信することで、支払いを行う口座を第1口座に設定するなどすることができる。
上記の実施例において、クレジットカード会社サーバ10の制御部11が、支払い口座選択情報を端末20から受信した場合に、選択された銀行口座を支払い口座として設定して問題ないかどうかをユーザに確認する情報(以下、「支払い口座設定確認情報」と称する。)を端末20に送信する。そして、端末20が、この支払い口座設定確認情報を表示部24に表示するようにしてもよい。この場合、制御部11は、端末20から「確認OK」の情報を受信した場合に、支払い口座設定処理を行うようにすることができる。
上記の実施例の手法を、クレジットカード会社(クレジットカード会社サーバ10)が提供するアプリケーション(以下、「クレジットカードアプリケーション」と称する。)によって実現することも可能である。
この場合、あらかじめ、端末20がクレジットカードアプリケーションをクレジットカード会社サーバ10から取得してインストールしておき、記憶部28に記憶されたクレジットカードアプリケーションを実行するようにすることができる。
上記の実施例において支払い口座が設定された後、端末20のユーザによって支払い口座を変更する入力がなされたことに基づいて、支払い口座を別の銀行口座に変更するようにすることもできる。
以下では、これを「支払い口座の変更」と称する。
上記の実施例の手法は、前述した(2)ツケ払いについても同様に適用可能である。
この場合の処理については、クレジットカード会社サーバ10が行う処理を、ツケ払い事業者のサーバ等の装置が行う処理に書き換えることによって、上記の実施例と同様に構成することが可能である。
そこで、以下では、(2)ツケ払いのうち、(2-2)都度ツケ払いを適用する場合の処理を例示する。
この処理は、都度ツケ払いを適用する場合の処理例であり、クレジットカード決済と同様に、ツケ払い事業者のwebページ等からユーザ入力に基づいて支払い口座を設定し、設定した支払い口座から口座振替を行う処理例として記載したものである。
なお、この与信照会に相当する処理を行わないようにしてもよい。また、ツケ払いの契約時等のタイミングで与信の審査を行うようにしてもよい。
クレジットカード決済の場合とは異なり、都度ツケ払いでは、限定ではなく例として、端末20のユーザによる取引の都度(商品やサービスの購入の都度)、口座振替が行われるようにすることができる。この場合、G190における口座振替要求情報の送信先の銀行サーバ50は、その取引について支払い口座として択一的に設定した1つの銀行口座に対応する銀行サーバとなる。
一方、処理を終了すると判定したならば(G195:YES)、ツケ払い事業者サーバの制御部は、処理を終了する。
クレジットカード会社のwebページやクレジットカードアプリケーションを介して支払い口座が設定されるようにする手法に限らず、クレジットカード会社とは異なる事業者が提供する、クレジットアプリケーションとは異なるアプリケーションを介して支払い口座が設定されるようにしてもよい。
(A)チャットアプリケーション
(B)電子マネーアプリケーション(支払いアプリケーション、電子マネー決済アプリケーション)
限定ではなく例として、メッセージングサービスの事業者によって提供されるメッセージングアプリケーションがこれに含まれる。
また、本変形例では、チャットアプリケーションの一例として、メッセージングアプリケーションを例示する。つまり、端末20にインストールされたメッセージングアプリケーションによって、本開示に係る各種の処理が実行されることとして説明する。
なお、テキストは、上記の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくとも1つを含まなくてもよく、その他のテキストを含んでもよい。
この場合は、コンテンツに、限定ではなく例として、テキスト、画像情報(静止画像情報、動画像情報の少なくともいずれか一方を含む。)、音情報(音声情報を含む。)、操作用情報(ボタン、アイコン等を含む。)、特定情報・通信情報・リンク情報(URL、URI等)など、装置間で送受信可能な各種の情報を含めることができる。
また、限定ではなく例として、メッセージをテキストとし、「コンテンツ」の中に、メッセージと、メッセージ以外の情報とが含まれるようにしてもよい。
メッセージングサービスでは、ユーザが、チャットルームを利用してチャットを行うことができるように構成されている。
以下の説明では、適宜、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるUI(User Interface)やGUI(Graphical User Interface)を「トークルーム」と称する。
なお、トークルームをチャットルームと称してもよいし、しなくてもよい。
それに対し、メッセージングサービスを利用する不図示の事業者装置や事業者端末のユーザのことを「公式アカウント(OA:Official Account)事業者」と称し、この事業者のアカウントのことを「公式アカウント」と称する。
つまり、本明細書において、メッセージングサービスのアカウントには、一般アカウントと公式アカウントとが含まれる。
その一方で、端末20の記憶部28に記憶されるトーク情報のデータは、端末20のユーザによって入力部を介して消去の入力がなされない限り、保持されるようにすることができる。
限定ではなく例として、端末20ではトーク情報は保持されないようにし、サーバ60で記憶・管理されるトーク情報を、端末20が取得して表示等するようにしてもよいし、そのようにしなくてもよい。
図1-14は、本変形例における通信システム1Bのシステム構成の一例を示す図である。
通信システム1Bは、図1-1の通信システム1Aに、構成要素としてサーバ60を追加したシステムである。
サーバ60は、本変形例において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ60は、限定ではなく例として、サーバ装置、コンピュータ(限定ではなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定ではなく例として、PDA、電子メールクライアントなど)、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ60は情報処理装置と表現されてもよい。サーバ60と端末20とを区別する必要がない場合は、サーバ60と端末20とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
(X)端末20のユーザがメッセージングアプリケーションのアカウント情報(限定ではなく例として、後述するメッセージングアプリケーションID等)をクレジットカード会社に通知する。限定ではなく例として、端末20からクレジットカード会社サーバ10にアカウント情報を送信する。そして、クレジットカード会社サーバ10において、ユーザ情報に紐づけてアカウント情報が登録されるようにする手法
(Y)端末20のユーザがクレジットカード情報をメッセージングサービス事業者に通知する。限定ではなく例として、端末20からサーバ60にクレジットカード情報を送信する。そして、サーバ60において、メッセージングサービスのアカウント情報に紐づけてクレジットカード情報が登録されるようにする手法
(1)クレジットカード会社サーバ10
図1-15は、本変形例においてクレジットカード会社サーバ10の記憶部15に記憶されるユーザ管理データベース159の一例であるユーザ管理データベース159Bのデータ構成例を示す図である。
各々のユーザ管理データには、前述した契約者ID、取引データ、登録銀行口座データ、支払い口座設定データの他に、限定ではなく例として、この契約者IDのユーザのメッセージングアプリケーションIDが記憶される。
または、サーバ60からクレジットカード会社サーバ10にメッセージングアプリケーションIDを送信するようにする。そして、クレジットカード会社サーバ10は、受信したメッセージングアプリケーションIDを、契約者IDと紐づけてユーザ管理データに記憶させて登録するようにすることができる。
図1-16は、本変形例においてサーバ60の制御部61によって実現される機能の一例を示す図である。
制御部61は、記憶部65に記憶されるメッセージングアプリケーション管理処理プログラム651に従って、メッセージングアプリケーション管理処理を実行するメッセージングアプリケーション管理処理部611を機能部として含む。
記憶部65には、限定ではなく例として、メッセージングアプリケーション管理処理として実行されるメッセージングアプリケーション管理処理プログラム651と、アカウント登録データ653と、アカウント管理データベース655とが記憶される。
アカウント登録データ653には、限定ではなく例として、ユーザ名と、メッセージングアプリケーションIDと、その他登録情報とが関連付けて記憶される。
このメッセージングアプリケーションIDは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ60によってアカウントごとに一意な値(固有の値)が設定されて記憶される。
メッセージングアプリケーションIDは、端末20、またはその端末20のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
また、端末20のユーザを識別するための識別情報は、限定ではなく例として、メッセージングアプリケーションIDとすることができる。
なお、メッセージングアプリケーションIDに代えて「ユーザID」としてもよいし、しなくてもよい。
この場合、アプリケーションID等のIDの情報をアカウント登録データ653に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ653に記憶させるようにすることができる。
アカウント管理データベース655Aには、アカウント登録データ653に記憶されたメッセージングアプリケーションIDごとの管理データとして、アカウント管理データが記憶される。
サーバ60は、限定ではなく例として、メッセージ情報の送信元の端末20から送信されたメッセージ情報を受信し、受信したメッセージ情報を、対応するアカウントのトークルームに追加する処理を行う。具体的には、アカウント管理データベース655Aのうちの対応するアカウントのアカウント管理データにおいて、対応するトークルームのトーク情報に、受信したメッセージ情報を追加して更新する。そして、サーバ60は、トークルームへの追加内容(トークルームに追加したメッセージ情報)を、送信先のユーザの端末20に送信する。これにより、端末20の表示部24に表示されるトークルームにおけるメッセージ情報が更新される。
なお、このアカウント管理データに記憶される取引データは、クレジットカード会社サーバ10のユーザ管理データに記憶される取引データに記憶される情報のうちの少なくとも一部の情報を含むデータであればよい。
図1-20は、本変形例において端末20の制御部21によって実行される機能の一例を示す図である。
制御部21は、前述した端末メイン処理部211の他に、限定ではなく例として、記憶部28に記憶されるメッセージングアプリケーションプログラム283に従ってメッセージングアプリケーション処理を実行するメッセージングアプリケーション処理部213を機能部として含む。
記憶部28には、前述した端末メイン処理プログラム281の他に、限定ではなく例として、メッセージングアプリケーションプログラム283と、メッセージングアプリケーションのアカウントのデータであるメッセージングアプリケーションID285とが記憶される。
図1-22は、本変形例におけるクレジットカード決済サービスの原理を説明するための図であり、クレジットカード決済の流れを図示したものである。
なお、図1-9と同様の部分については説明を省略する。
・クレジットカード会社サーバ10
・サーバ60
それに対し、サーバ60によって支払い口座が設定される場合は、(7-1)支払い口座選択情報が端末20からサーバ60に送信される。そして、サーバ60によって支払い口座が設定された後、(7-2)支払い口座設定情報がサーバ60からクレジットカード会社サーバ10に送信される。
この詳細については後述する。
図1-23は、本変形例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図1-23左は、メッセージングアプリケーションのトークルーム画面の一例であり、画面最上部中央には、メッセージングアプリケーションの名称として「Messaging App」の文字が表示されている。また、画面最上部右には、この端末20のユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名(この例ではユーザA.A)が表示されている。
以降は、図1-10と同様である。
図1-24,図1-25は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。本処理は、サーバ60を、メッセージングサービス事業者のサーバとする場合の処理の一例である。
この図では、左側から順に、端末20Aの制御部21が実行する処理、サーバ60の制御部61が実行する処理、クレジットカード会社サーバ10の制御部11が実行する処理、A銀行サーバ50Aの制御部が実行する処理、B銀行サーバ50Bの制御部が実行する処理の一例を示している。
つまり、この処理では、端末20は、メッセージングアプリケーションからクレジットカード会社のwebページに遷移して支払い口座の設定のための入力を行い、クレジットカード会社サーバ10によって支払い口座設定処理が行われる(C160)。
なお、別の手法として、メッセージングアプリケーションのトークルームからメッセージングアプリケーションの支払い口座設定用のページに遷移させて支払い口座を選択させるようにしてもよい。
しかし、前述したように、端末20に送信されたメッセージ情報が端末20の記憶部28に記憶されて保存される形態を適用することも可能であるため、この場合は、上記のように別のページに遷移させて支払い口座を選択させるようにするとよい。
これに関連して、ユーザによる支払い口座を変更する入力に基づいて、支払い口座を別の銀行口座に変更した場合に、支払い口座が変更されたことを示す支払い口座変更メッセージ情報がサーバ60から端末20に送信されるようにしてもよい。
図1-26は、本変形例においてサーバ60の記憶部65に記憶されるアカウント管理データベース655の別例であるアカウント管理データベース655Bのデータ構成例を示す図である。
このアカウント管理データベース655Bでは、各々のアカウント管理データにおいて、友だちデータと、トーク情報データと、取引データとの他に、限定ではなく例として、登録銀行口座データと、支払い口座設定データとが記憶される。
限定ではなく例として、サーバ60は、何らかのタイミングで登録銀行口座データをクレジットカード会社サーバ10から取得して、アカウント管理データに記憶させるようにすることができる。
そこで、サーバ60が、限定ではなく例として締め日(締め日時)にクレジットカード会社サーバ10に必要な情報を送信した後、上記のアカウント管理データから、限定ではなく例として、登録銀行口座データを消去するようにしてもよい。同様に、支払い口座設定データを消去するようにしてもよい。
図1-27左には、図1-23と同様のOAトークルームを示しているが、表示される請求メッセージ情報の内容が一部異なっている。
具体的には、請求メッセージ情報の下部には、自分(この例ではユーザA.A)が支払い口座として設定可能な銀行口座の一覧が表示されており、この例では、「A銀行」のアイコンIC3Aと、「B銀行」のアイコンIC3Bとが表示されている。
この確認情報には、限定ではなく例として、「支払い口座をA銀行に設定しますか?」のテキストとともに、承認するための「はい」のボタンと、承認しないための「いいえ」のボタンとが表示されている。
通信I/F64によってクレジットカード会社サーバ10から請求情報を受信すると、制御部61は、受信した請求情報に含まれるアカウント情報から特定されるアカウント管理データに記憶されている登録銀行口座データに基づき、登録銀行口座情報を含む請求メッセージ情報を生成する。そして、制御部61は、生成した請求メッセージ情報を、トーク相手のアカウントをクレジットカード会社の公式アカウントとするOAトークルームに追加し、追加した請求メッセージ情報を通信I/F64によって端末20Aに送信する(B132)。
具体的には、アカウント管理データベース655Bの端末20Aのユーザのアカウント管理データのうち、支払い口座設定データの対応する取引IDの取引について、受信した支払い口座選択情報から特定される銀行口座に対応する口座IDを、支払い口座IDに記憶させる。
つまり、本処理では、クレジットカード会社サーバ10ではなく、メッセージングサービス事業者のサーバ60が支払い口座設定処理を行う。
支払い口座設定情報送信条件は、支払い口座設定情報をクレジットカード会社サーバ10に送信する条件であり、限定ではなく例として、「提携銀行に口座振替を依頼する日にち(期日)になったこと」とすることができる。
支払い口座設定情報は、支払い口座設定処理で設定した支払い口座に関する情報である。
この場合は、通信システム1Bにおいて、サーバ60を電子マネーサービス事業者のサーバとし、メッセージングアプリケーションのアカウント(限定ではなく例として、メッセージングアプリケーションID)を、電子マネーアプリケーションのアカウント(限定ではなく例として、電子マネーアプリケーションID)として、上記の実施例と同様の処理を行うようにすることができる。
この場合、チャージする手法としては、限定ではなく例として、プリペイドカードを用いてチャージを行う手法や、ユーザが銀行口座の登録をサーバ60に要求して自身のアカウント(電子マネーアプリケーションID)に銀行口座の情報が関連付けられるようにし、登録された銀行口座からチャージを行うようにする手法等を適用することができる。
この身分証明は、運転免許証等の公的な証明書の提示をユーザに要求して行う手法の他、クレジットカード情報の提示をユーザに要求して行うようにすることも可能である。
各々のアカウント管理データには、限定ではなく例として、電子マネーアプリケーションIDと、電子マネー口座残高と、取引データと、登録銀行口座データと、支払い口座設定データとが記憶される。
この電子マネーアプリケーションIDは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ60によってアカウントごとに一意な値(固有の値)が設定されて記憶される。
電子マネーアプリケーションIDは、端末20、またはその端末20のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
限定ではなく例として、サーバ60は、登録銀行口座データをクレジットカード会社サーバ10に要求し、クレジットカード会社サーバ10から登録銀行口座データを取得して、アカウント管理データに記憶させるようにすることができる。
B150の後、制御部61は、支払い口座設定処理を行う(B160)。
具体的には、アカウント管理データベース655Cの端末20Aのユーザのアカウント管理データのうち、支払い口座設定データの対応する取引IDの取引について、端末20Aから受信した支払い口座選択情報から特定される銀行口座に対応する口座IDを、支払い口座IDに記憶させる。
つまり、本処理では、クレジットカード会社サーバ10ではなく、電子マネーサービス事業者のサーバ60が支払い口座設定処理を行う。
そして、制御部61は、B170に処理を進める。
前述した(A)チャットアプリケーション(メッセージングアプリケーション)を適用する場合や(B)電子マネーアプリケーションを適用する場合の他に、限定ではなく例として、チャットと支払いとの両方を行うことができるアプリケーションを適用することも可能である。この形態としては、限定ではなく例として、以下のいずれかの形態が考えられる。
(a)チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
(b)電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
(c)チャットサービスの機能と電子マネーサービスの機能とを有する複合的(統合的)なアプリケーションを構成する形態
以下、これらの形態を適用する場合について説明する。
なお、これとは異なり、通信システム1Bにおいて、サーバ60を、メッセージングサービス用のサーバ(第1サーバ)と、電子マネーサービス用のサーバ(第2サーバ)との2つに分けてもよい。
図1-31左には、図1-23左と同様のメッセージングアプリケーションのOAトークルーム画面を示している。
この画面において「支払い口座の設定はこちら>」の文字を含むリンクボタンBT2がタップされると、限定ではなく例として、端末20において電子マネーアプリケーションが起動され、限定ではなく例として、図1-31中央の画面が表示される。
また、その下には、支払い口座を設定するための情報が表示されている。
A131の後、制御部21は、支払い口座設定を行うための入力がなされたか否かを判定する(A141)。具体的には、限定ではなく例として、OAトークルームに表示された請求メッセージ情報に含まれるリンクボタンがタップされるなどして、支払い口座設定を行うための入力がなされたか否かを判定する。
これを受けて(B151:YES)、制御部61は、電子マネーアプリケーションの支払い口座設定ページを、通信I/F64によって端末20Aに送信する(B153)。
このような構成により得られる実施例の効果の一例として、端末のユーザにより後払いで購入された購入情報を受信した上で、その購入情報を端末に送信して、端末のユーザに通知することができる。また、購入情報の少なくとも一部を、端末のユーザに関連する複数の口座のうちの第1口座によって支払うことに関する情報を端末から受信することで、支払いを行う口座を第1口座に設定するなどすることができる。
上記の変形例では、通信システム1Bにおいて、クレジットカード会社サーバ10とサーバ60とを異なるサーバとして構成する例を示したが、これに限定されない。
クレジットカード会社サーバ10とサーバ60とを、1つのサーバ(同じサーバ)として構成することも可能である。
第1実施例では、ユーザが商品やサービスをクレジットカード決済で購入するごと、つまり取引ごとに、支払い口座設定を行う実施例を示した。
第2実施例は、1または複数の取引に対して、まとめて支払い口座設定を行うことを可能にする実施例である。
第2実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
なお、「当月」は、「今月」、「現在の月」、「決済対象月」等のように表現してもよいし、しなくてもよい。
図2-1は、本実施例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図2-1は、ユーザが、今月度(本例では10月度)の複数のクレジットカード取引に対してまとめて支払い口座設定を行う場合の表示画面の一例を示す図である。
また、その下には、今月度(10月度)の当月決済情報が表示されており、限定ではなく例として、決済月を示す「ご利用月」の欄と、合計決済金額を示す「ご利用合計金額」の欄とが設けられている。この例では、「ご利用月」の欄には「2020/10」が、「ご利用合計金額」の欄には「50,000円」がそれぞれ表示されている。
また、その他には、図1-10左の画面と同様の情報が表示されている。
また、その他には、図2-1中央の画面と同様の情報が表示されている。
また、その右には、設定した支払い口座を表示するための領域が構成されており、この例では、「支払い口座」の文字と、各クレジットカード取引別に上から順に、A銀行に対応する「A銀行」の文字と、B銀行に対応する「B銀行」の文字と、A銀行に対応する「A銀行」の文字とが表示されている。
図2-2,図2-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図2-2は、第1実施例で説明したフローチャートのうちの図1-12に対応する部分であり、C120までの処理については、図1-11と共通であるため図示を省略している。
この図では、左側から順に、端末20Aの制御部21が実行する処理、クレジットカード会社サーバ10の制御部11が実行する処理、A銀行サーバ50Aの制御部が実行する処理、B銀行サーバ50Bの制御部が実行する処理の一例を示している。
当月確定請求情報送信条件とは、後述する当月確定請求情報を送信する条件であり、限定ではなく例として、「クレジットカード決済における締め日(締め日時)、限定ではなく例として月末日の翌営業日(翌営業日の特定の時刻)になったこと」とすることができる。
ここでの「取引別支払い口座設定」とは、取引の一覧(取引の履歴)から取引別に支払い口座を設定することを意味する。
一方、取引別支払い口座設定を行うための入力がなされたと判定した場合(A240:YES)、制御部21は、限定ではなく例として、当月の取引別の支払い口座の設定ページ(webページ)に移動するための取引別支払い口座設定要求情報を、通信I/F22によってクレジットカード会社サーバ10に送信する(A250)。
取引別支払い口座設定要求情報を受信しなかったと判定した場合(C240:NO)、制御部11は、C180に処理を進める。
限定ではなく例として、当月商品購入情報(購入日時、購入金額等)や、クレジットカードに紐づいている銀行口座情報(銀行名、口座番号等)、支払い口座を設定するために必要な他の情報(第1アイコン、第2アイコン等)等の情報を含む今月度支払い口座設定画面を表示部24に表示させるなどすることができる。
限定ではなく例として、当月商品購入情報や、支払い口座情報(支払い口座としていずれかの銀行口座が設定されたことを報知する情報等)などの情報を含む今月度支払い口座設定完了画面を表示部24に表示させるなどすることができる。
本実施例は、端末20が、自己の端末20のユーザにより、後払いで購入された商品またはサービスの購入履歴に関する情報を含む商品購入情報を受信し、受信した商品購入情報と、自己の端末20のユーザの登録銀行口座情報とを表示部24に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザにより後払いで購入された商品またはサービスの購入履歴を端末のユーザに確認させることができるとともに、その支払いをいずれの口座から行うかをユーザに選択させることができる。
このような構成により得られる実施例の効果の一例として、購入履歴のうちの少なくとも一部の支払いを第1口座情報に関連する第1口座で支払うことを端末のユーザに確認させるとともに、その支払いが第1口座から行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザにより後払いで購入された商品またはサービスの合計金額を端末のユーザに確認させることができるとともに、その支払いをいずれの口座から行うかをユーザに選択させることができる。
第2実施例の手法は、第1変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、支払い口座を設定するようにすることも可能である。
(a)チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
(b)電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
(c)チャットサービスの機能と電子マネーサービスの機能とを有する複合的(統合的)なアプリケーションを構成する形態
を適用することも可能である。
図2-4は、本変形例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図2-4左は、メッセージングアプリケーションのトークルーム画面の一例である。
この画面のトーク領域には、ユーザA.Aによる今月度のクレジットカード取引に関する情報(画面では「10月度ご利用情報」)を含む後述する当月確定請求メッセージ情報がXカードを送信元として送信され、サーバ60を介して、端末20Aが当月確定請求メッセージ情報を受信したことに基づいて、このOAトークルームの画面向かって左側に、Xカードのアイコン画像と関連付けて、当月確定請求メッセージ情報が表示されている。
また、その下には、図2-1中央の画面と同様の情報が表示されている。
また、その下には、図2-1右の画面と同様の情報が表示されている。
本変形例における処理は、限定ではなく例として、図2-2~図2-3の処理を、図1-24~図1-25、図1-28、図1-30、図1-32等の処理に基づいて書き換えることで同様に構成可能であるため、詳細な説明は省略する。
第3実施例は、支払い口座を設定する手法として、ユーザによる支払い口座の選択とは異なる方法によって支払い口座を設定することを可能にする実施例である。
第3実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図3-1は、本実施例においてクレジットカード会社サーバ10の記憶部15に記憶されるユーザ管理データベース159の一例であるユーザ管理データベース159Cのデータ構成例を示す図である。
具体的には、ユーザ管理データベース159Cでは、支払い口座設定データには、限定ではなく例として、振替金額と、支払い口座IDとが関連付けて記憶される。
図3-2は、本実施例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図3-2は、ユーザが金額入力方式を用いて支払い口座を設定する場合の表示画面の一例を示す図である。
つまり、この例では、ユーザが、A銀行の銀行口座から「30,000円」の口座振替を行い、B銀行の銀行口座から「20,000円」の口座振替を行うことを選択したことを示している。
また、その他には、図2-1中央の画面と同様の情報が表示されている。
詳細は後述するが、(A)振替金額固定方式、(B)割合設定方式、等の方式で、振替金額が設定されるような表示画面・UIとすることも可能である。
図3-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図3-3は、第2実施例のフローチャートのうちの図2-3に対応する部分を示したものである。
一方、金額入力方式で支払い口座設定を行うための入力がなされたと判定した場合(A340:YES)、制御部21は、限定ではなく例として、金額入力方式による支払い口座の設定ページ(webページ)に移動するための金額入力方式支払い口座設定要求情報を、通信I/F22によってクレジットカード会社サーバ10に送信する(A350)。
本実施例は、端末20が、自己の端末20のユーザによって後払いで購入された商品またはサービスの合計金額のうちのユーザによって入力(指定)された振替金額(限定ではなく、第1金額の一例)を、ユーザによって選択された第1銀行口座(第1口座)に基づいて支払うことに関する情報を受信して表示部24に表示する。そして、端末20は、自己の端末20のユーザにより、振替金額が入力されたことに基づき、第1銀行口座が支払い口座として設定されたことを示す支払い口座設定完了情報(限定ではなく、第1情報の一例)を表示部24に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによって後払いで購入された商品またはサービスの合計金額のうちの第1金額を、端末のユーザによって選択された第1口座情報に関連する第1口座で支払うことができる。
このような構成により得られる実施例の効果の一例として、端末のユーザによって後払いで購入された商品またはサービスの合計金額のうちの第2金額を、端末のユーザによって選択された第2口座情報に関連する第2口座で支払うことができる。
第3実施例の手法は、第1変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、金額入力方式で支払い口座を設定するようにすることも可能である。
(a)チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
(b)電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
(c)チャットサービスの機能と電子マネーサービスの機能とを有する複合的(統合的)なアプリケーションを構成する形態
を適用することも可能である。
本変形例における処理は、限定ではなく例として、図3-3の処理を、図1-24~図1-25、図1-28、図1-30、図1-32等の処理に基づいて書き換えることで同様に構成可能であるため、詳細な説明は省略する。
クレジットカード決済では、口座振替の日にちが決まっている性質上、支払い口座を設定できる期間は有限である。しかしながら、クレジットカード決済を利用して商品やサービスを購入してから、実際に口座振替が行われるまで一定の期間が経過するクレジットカード決済において、ユーザがその期限を忘れてしまう可能性がある。
第4実施例は、支払い口座をユーザが選択可能な時期または日にちに関する情報(期間、期限、期日等の情報を含む。)をユーザに報知する実施例である。
第4実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
なお、支払い口座設定期限を「日時」として設定するようにしてもよいし、しなくてもよい。
「期限報知情報」は、支払い口座設定期限と何らかの関係性を有する情報であればよく、限定ではなく例として、以下の少なくともいずれか1つの情報がこれに含まれる。
・支払い口座設定期限を直接的に報知する情報(限定ではなく例として、後述する「支払い口座設定期限情報」)
・支払い口座設定期限を間接的に報知する情報(限定ではなく例として、後述する「支払い口座設定残り期間情報」)
・支払い口座設定期限までの残り期間(残り時間)が所定期間(所定時間)以上ある場合(限定ではなく例として、一週間以上ある場合):第1表示態様(限定ではなく例として、丸型のアイコンを表示、第1アイコンの周りに青色の枠を表示、等)
・支払い口座設定期限までの残り期間(残り時間)が所定期間(所定時間)以上ない場合(限定ではなく例として、一週間以内の場合):第2表示態様(限定ではなく例として、三角形型のアイコンを表示、第1アイコンの周りに黄色の枠を表示、等)
・端末20で請求情報や当月確定請求情報が表示されたタイミング(限定ではなく例として、請求情報や当月確定請求情報に関連する受信Eメール画面が表示されたタイミング)
・端末20で支払い口座設定用情報や取引別支払い口座設定用情報が表示されたタイミング(限定ではなく例として、支払い口座設定画面や今月度支払い口座設定画面が表示されたタイミング)
以下では、期限報知情報が表示されるタイミングを、端末20で今月度支払い口座設定画面が表示されたタイミングとする場合を例示する。
・支払い口座設定期限を超過したこと報知する情報(限定ではなく例として、後述する「支払い口座設定期限超過情報」)
・支払い口座設定期限までの残り期間がない(超過したこと)を報知する情報(限定ではなく例として、後述する「支払い口座設定残り期間超過情報」)
支払い口座設定残り期間超過情報には、限定ではなく例として、支払い口座設定の残り期間がないことを画像等によって示唆する情報(以下、「支払い口座設定残り期間超過示唆情報」と称する。)を含めることができる。
・支払い口座設定期限までの残り期間がない場合:第3表示態様(限定ではなく例として、バツ型(×)のアイコンを表示、第1アイコンの周りに赤色の枠を表示、等)
具体的には、期限報知情報を含む支払い口座設定用情報とは、限定ではなく例として、「X月Y日まで設定可能」の文字が含まれる支払い口座設定画面であり、期限超過報知情報を含む支払い口座設定用情報とは、限定ではなく例として、「X月Y日で設定期間終了」の文字が含まれる支払い口座設定画面である。
具体的には、期限報知情報を含む取引別支払い口座設定用情報とは、限定ではなく例として、「X月Y日まで設定可能」の文字が含まれる今月度支払い口座設定画面であり、期限超過報知情報を含む支払い口座設定用情報とは、限定ではなく例として、「X月Y日で設定期間終了」の文字が含まれる今月度支払い口座設定画面である。
図4-1は、本実施例においてクレジットカード会社サーバ10の記憶部15に記憶される支払い口座設定用情報種別判定データのデータ構成例を示す図である。
支払い口座設定用情報種別判定データには、限定ではなく例として、現在の計時情報(現在の日時)が支払い口座設定期限以内であるか否かの判定結果と、支払い口座設定用情報の種別とが関連付けて記憶される。
取引別支払い口座設定用情報種別判定データには、限定ではなく例として、現在の計時情報が支払い口座設定期限以内であるか否かの判定結果と、取引別支払い口座設定用情報の種別とが関連付けて記憶される。
図4-3は、本実施例において端末20Aの表示部24に表示される画面の一例を示す図である。図4-3は、支払い口座設定期限情報が表示される場合の表示画面の一例を示す図である。
また、その他には、図2-1中央の画面と同様の情報が表示されている。
また、その他には、図2-1中央の画面と同様の情報が表示されている。
本実施例の処理は、限定ではなく例として、図1-11、図2-2、図2-3に基づいて構成することができる。
なお、C150およびA160、並びにC250およびA260以外のステップについては、図1-11、図2-2、図2-3と同様であるため、説明を省略する。
本実施例は、端末20が、請求情報のうちの一の請求情報(限定ではなく、第1購入情報の一例)に対して、複数の登録銀行口座情報のうちから支払い口座とする口座情報をユーザが選択可能な時期または日にちに関する情報(限定ではなく、複数の口座情報のうちから少なくとも一つの口座情報を選択可能であることに関する第3情報の一例)を表示部24に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、購入情報のうちの第1購入情報に対して、複数の口座情報のうちから少なくとも一つの口座情報を選択可能であることや、口座情報を選択することができる時期や日にちなどの情報を、端末のユーザに報知することができる。
このような構成により得られる実施例の効果の一例として、複数の口座情報のうちから少なくとも一つの口座情報を選択可能な日にちに関する情報を、端末のユーザに報知することができる。
このような構成により得られる実施例の効果の一例として、複数の口座情報のうちから少なくとも一つの口座情報を選択可能な時期または日にちではない場合、そのことを端末のユーザに確実に認識させることができる。
第4実施例の手法は、第1変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、支払い口座設定期限等の情報をユーザに報知するようにすることも可能である。
(a)チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
(b)電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
(c)チャットサービスの機能と電子マネーサービスの機能とを有する複合的(統合的)なアプリケーションを構成する形態
を適用することも可能である。
本変形例における処理は、限定ではなく例として、図1-24~図1-25、図1-28、図1-30、図1-32等の処理に基づいて同様に構成可能であるため、詳細な説明は省略する。
上記の実施例では、クレジットカード決済に基づく、取引別の請求情報や、ひと月分の当月確定請求情報等が、クレジットカード会社サーバ10から端末20に送信される例を示した。
第5実施例は、請求情報や当月確定請求情報とは異なる支払い口座設定リマインド情報が、クレジットカード会社サーバ10から端末20に送信されることを可能にする実施例である。
第5実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
具体的には、本実施例では、クレジットカード会社サーバ10の制御部11が、記憶部15に記憶済みの各種の情報を取得し、取得した情報に基づいて、後述する支払い口座設定リマインド条件の成否を判定する。そして、支払い口座設定リマインド条件が成立した場合、支払い口座設定リマインド情報を送信することに決定し、支払い口座設定リマインド条件が成立しなかった場合、支払い口座設定リマインド情報を送信しないことに決定する。
図5-1は、本実施例においてクレジットカード会社サーバ10の記憶部15に記憶される支払い口座設定リマインド条件データのデータ構成例を示す図である。
支払い口座設定リマインド条件データには、限定ではなく例として、支払い口座設定リマインド条件の番号(No)と、この番号に対応する支払い口座設定リマインド条件とが関連付けて記憶されている。
上記の全ての情報を関連付けて記憶させる必要はなく、一部の情報を記憶させないようにしてもよい。
また、支払い口座設定リマインド条件の成否の判定を上記のデータを参照することによって実現するのではなく、プログラムによって実現してもよい。
これは、他の実施例で説明するデータについても同様である。
No「SP01」には、支払い口座設定リマインド条件として「設定された時間間隔の時間が経過した、または設定された日時になった」が定められている。
「設定された時間間隔」は、限定でなく例として、端末20側またはクレジットカード会社サーバ10側であらかじめ任意の時間間隔を設定可能とすることができる。
限定ではなく例として、「毎週日曜日の朝10時」等のタイミングでリマインドが行われるように条件を設定することができる。これは、週末である日曜日は比較的時間に余裕のある可能性があるためである。
No「SP02」には、支払い口座設定リマインド条件として「支払い口座の設定,変更がされていない状態で設定時間が経過した」が定められている。
「設定時間」は、限定でなく例として、端末20側またはクレジットカード会社サーバ10側であらかじめ任意の設定時間を設定可能とすることができる。
限定ではなく例として、支払い口座設定画面や今月度支払い口座設定画面の第1アイコンを選択した後に、その情報を保存・決定するための第2アイコンが操作されていない状態や、ユーザが端末20に表示される請求情報や当月確定請求情報を閲覧していない状態等がこれに含まれる。
限定ではなく例として、クレジットカード決済における支払い口座が、一の銀行口座(限定ではなく例として、A銀行の銀行口座)に初期設定される構成が採用される場合(この場合の初期設定される銀行口座を以下、適宜「初期支払い口座」と称する。)、いずれのクレジットカード決済も支払い口座が初期支払い口座のまま変更されていない状態や、クレジットカード決済における支払い口座が、いずれかの銀行口座に自動設定される構成が採用される場合(この方式を、以下、適宜「支払い口座自動設定方式」と称する。)、いずれのクレジットカード決済も支払い口座自動設定方式で設定された支払い口座のまま変更されていない状態等がこれに含まれる。
No「SP03」には、支払い口座設定リマインド条件として「クレジットカード決済の取引数が設定数を超えた」が定められている。
「設定数」は、限定でなく例として、端末20側またはクレジットカード会社サーバ10側であらかじめ任意の数を設定可能とすることができる。
限定ではなく例として、取引数がある程度大きい数(限定ではなく例として、「20件」や「30件」)である場合、支払い口座の設定をしていないクレジットカード決済が溜まってしまい、後にユーザの負担となる可能性がある。そこで、支払い口座設定リマインドを行うようにすることができる。
No「SP04」には、支払い口座設定リマインド条件として「決済金額が設定金額を超えた」が定められている。
「設定金額」は、限定でなく例として、端末20側またはクレジットカード会社サーバ10側であらかじめ任意の金額を設定可能とすることができる。
なお、これとは異なり、この条件における「決済金額」を、クレジットカード決済毎(取引毎)の決済金額としてもよいし、しなくてもよい。
図5-2は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
なお、図1-11、図2-2、図2-3に示したA290およびC270までの処理と、A195およびC180以降の処理とは同様であるため、図示・説明は省略する。
この支払い口座設定リマインド条件判定処理では、制御部11は、前述した支払い口座設定リマインド条件データに基づいて支払い口座設定リマインド条件の成否を判定する。
一方、支払い口座設定リマインド条件が成立していると判定した場合(C520:YES)、制御部11は、限定ではなく例として、支払い口座設定リマインドに関連する支払い口座設定リマインド情報を、通信I/F14によって端末20に送信し(C530)、図2-3のC180に処理を進める。
一方、支払い口座設定リマインド情報を受信したと判定した場合(A530:YES)、制御部21は、受信された支払い口座設定リマインド情報(またはこれに基づく情報)(限定ではなく例として、支払い口座設定リマインド画面)を表示部24に表示させ(A540)、図2-3のA195に処理を進める。
本実施例は、端末20が、請求情報のうちの少なくとも一の請求情報(限定ではなく、購入情報の少なくとも一部の一例)に基づく支払い口座設定リマインド情報(限定ではなく、購入情報の少なくとも一部に基づく通知情報の一例)を通信I/F22によって受信することに基づき、支払い口座設定用情報を表示部24に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、購入情報の少なくとも一部に基づく通知情報を通信部によって受信することに基づいて、複数の口座情報を表示部に表示して、端末のユーザに確認させることができる。
このような構成により得られる実施例の効果の一例として、購入情報の少なくとも一部に基づく通知情報が設定された時間間隔で端末に送信されるため、複数の口座情報を定期的にユーザに確認させることが可能となる。
このような構成により得られる実施例の効果の一例として、購入情報の少なくとも一部に対して、複数の口座情報のうちから少なくとも一つの口座情報を選択可能な期間または日にちに基づいて、適切なタイミングで通知情報が端末に送信されるようにすることができる。
このような構成により得られる実施例の効果の一例として、購入情報に含まれる決済数に基づいて、適切なタイミングで通知情報が端末に送信されるようにすることができる。
このような構成により得られる実施例の効果の一例として、購入情報に基づく合計金額がある程度大きいような場合に、通知情報が端末に送信されるようにすることができる。
第5実施例の手法は、第1変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、支払い口座設定リマインドを行うようにすることも可能である。
(a)チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
(b)電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
(c)チャットサービスの機能と電子マネーサービスの機能とを有する複合的(統合的)なアプリケーションを構成する形態
を適用することも可能である。
本変形例における処理は、限定ではなく例として、図5-2の処理を、図1-24~図1-25、図1-28、図1-30、図1-32等の処理に適用することで同様に構成可能であるため、詳細な説明は省略する。
第6実施例は、クレジットカード決済におけるクレジットカード会社への支払い方法をユーザが選択可能にする実施例である。
第6実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例では、画像情報の別例として、第3アイコンを表示する。
(A)分割払い
(B)リボ払い
(C)ローン払い
本実施例におけるクレジットカード決済の分割払いは、クレジットカード会社からの請求金額のうちユーザが指定した分割回数で割った分割金額を、月に1回などの設定された日、または設定された期日に紐づけられた銀行口座から支払いを行う。
本実施例におけるクレジットカード決済のリボ払いは、クレジットカード会社からの請求金額のうちユーザが指定した毎月の支払い金額を、月に1回などの設定された日、または設定された期日に紐づけられた銀行口座から支払いを行う。
本実施例におけるローン払いは、クレジットカード会社からの請求金額をローン会社が代わりに支払ったローン支払い金額を、ローン会社に月に1回などの設定された日、または設定された期日に紐づけられた銀行口座から支払いを行う。
(A)分割払いに対応する第3アイコン(限定ではなく例として、「分割払い」の文字を含む第3アイコン)
(B)リボ払いに対応する第3アイコン(限定ではなく例として、「リボ払い」の文字を含む第3アイコン)
(C)ローン払いに対応する第3アイコン(限定ではなく例として、「ローン」の文字を含む第3アイコン)
図6-1は、本実施例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図6-1は、支払い口座設定画面に第3アイコンが表示される場合の表示画面の一例を示す図である。
また、その他には、図1-10中央の画面と同様の情報が表示されている。
また、その他には、図1-10中央の画面と同様の情報が表示されている。
また、その他には、図1-10右の画面と同様の情報が表示されている。
本実施例における処理は、図1-11、図2-2、図2-3に示したフローチャートに倣って同様に構成することができる。
なお、図1-11、図2-2、図2-3に示したフローチャートのうちのC150およびA160、並びにC250およびA260以外の処理とは同様であるため、説明を省略する。
限定ではなく例として、商品購入情報(決済日時、決済店舗、決済金額等)や、クレジットカードに紐づいている銀行口座情報(銀行名、口座番号等)、支払い口座を設定するために必要な他の情報(第1アイコン、第2アイコン等)や、支払い方法を設定するための情報(第3アイコン等)等の情報を含む支払い口座設定画面を表示部24に表示させるなどすることができる。
限定ではなく例として、当月商品購入情報(購入日時、購入金額等)や、クレジットカードに紐づいている銀行口座情報(銀行名、口座番号等)、支払い口座を設定するために必要な他の情報(第1アイコン、第2アイコン等)や、支払い方法を設定するための情報(第3アイコン等)等の情報を含む今月度支払い口座設定画面を表示部24に表示させるなどすることができる。
本実施例は、端末20が、少なくとも1つの取引の支払いに対して、ローン支払いを選択・設定するための情報(限定ではなく、ローンで支払うことに関する第4情報の一例)を表示部24に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、後払いによる購入情報の少なくとも一部の支払いに対して、ローンでの支払いが可能であることを端末のユーザに報知することができる。
このような構成により得られる実施例の効果の一例として、端末のユーザによって選択された第1口座によって、ローンによる支払いを可能とすることができる。
第6実施例の手法は、第1変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、クレジットカード会社への支払い方法を設定するようにすることも可能である。
(a)チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
(b)電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
(c)チャットサービスの機能と電子マネーサービスの機能とを有する複合的(統合的)なアプリケーションを構成する形態
を適用することも可能である。
本変形例における処理は、限定ではなく例として、図1-24~図1-25、図1-28、図1-30、図1-32等の処理に基づいて同様に構成可能であるため、詳細な説明は省略する。
上記の実施例では、支払い口座設定画面や取引別支払い口座設定画面に、クレジットカードに紐づいている銀行口座情報として、銀行名や口座番号等の情報が表示される実施例を示した。
第7実施例は、支払い口座設定画面や取引別支払い口座設定画面に、クレジットカードに紐づいている銀行口座情報として、銀行名や口座番号とは異なる情報(限定ではなく例として、銀行口座の残高に関連する残高情報)が表示される実施例である。
第7実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図7-1は、本実施例においてクレジットカード会社サーバ10の記憶部15に記憶されるユーザ管理データベース159の一例であるユーザ管理データベース159Hのデータ構成例を示す図である。
具体的には、ユーザ管理データベース159Hでは、支払い口座設定データには、限定ではなく例として、口座IDと、口座振替トークンと、残高照会トークンとが関連付けて記憶される。
クレジットカード会社サーバ10は、あらかじめ銀行サーバ50によって発行されて銀行サーバ50から通知された残高照会トークンと、前述した口座振替トークンとに基づいて、この契約者IDのユーザの口座残高の情報を取得する処理を、その銀行サーバ50との間で行う。
なお、残高照会トークンは、アクセストークン等のように表現してもよい。
なお、記憶している残高情報は、その月の口座振替が行われたタイミング等で消去するようにしてもよいし、しなくてもよい。
図7-2は、本実施例において端末20Aの表示部24に表示される画面の一例を示す図である。図7-2は、支払い口座設定画面に残高情報が表示される場合の表示画面の一例を示す図である。
また、その他には、図1-10中央の画面と同様の情報が表示されている。
図7-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
なお、図1-11、図1-12に示したA150およびC140までの処理と、A170、C160、D190、およびE190以降の処理とは同様であるため、図示・説明は省略する。
具体的には、制御部11は、限定ではなく例として、ユーザ管理データベース159Hのうちの、支払い口座設定要求情報に含まれる取引IDが記憶されているユーザ管理データにおける登録銀行口座データから、口座IDに関連付けられた口座振替トークンと残高照会トークンとを取得する。
また、制御部11は、提携銀行データ155から、このユーザ管理データに含まれる口座ID(提携銀行ID)に関連付けられた提携銀行サーバURIを取得する。そして、制御部11は、その口座振替トークンと残高照会トークンとを含み、端末20のユーザの口座に関する情報の照会・参照を要求するための残高照会要求情報(残高参照要求情報)を、通信I/F14によって、その提携銀行サーバURIをアクセス先として、対応する銀行サーバ50(A銀行サーバ50AやB銀行サーバ50B)に送信する(B820)。
限定ではなく例として、商品購入情報(決済日時、決済店舗、決済金額等)や、クレジットカードに紐づいている銀行口座情報(銀行名、口座番号、残高情報等)、支払い口座を設定するために必要な他の情報(第1アイコン、第2アイコン等)等の情報を含む支払い口座設定画面を表示部24に表示させるなどすることができる。
本実施例は、端末20が、ユーザによって支払い口座として選択された銀行口座の残高情報を表示部24に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによって選択された第1口座情報に関連する第1口座の残高をユーザが確認可能となるため、第1口座からの支払いが可能であるかどうかの判断が容易になる。
第7実施例の手法は、第1変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、残高情報を表示するようにすることも可能である。
(a)チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
(b)電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
(c)チャットサービスの機能と電子マネーサービスの機能とを有する複合的(統合的)なアプリケーションを構成する形態
を適用することも可能である。
図7-4は、本変形例において端末20Aの表示部24に表示される画面の一例を示す図である。図7-4は、端末20の電子マネーアプリケーションにおける支払い口座設定画面に残高情報が表示される場合の表示画面の一例を示す図である。
また、その他には、図1-31中央の画面と同様の情報が表示されている。
本変形例における処理は、限定ではなく例として、図7-3の処理を、図1-24~図1-25、図1-28、図1-30、図1-32等の処理に適用することで同様に構成可能であるため、詳細な説明は省略する。
第8実施例は、装置(端末またはサーバ)側で支払い口座を決定する(自動で決定する)実施例である。
第8実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
ここで、「支払い口座の決定」には、限定ではなく例として、支払い口座設定処理で支払い口座に設定する銀行口座を決めることと、支払い口座に設定する銀行口座の候補を端末20のユーザに提案(サジェスト)することと、のいずれかを含む概念とすることができる。
前者の場合は、決められた銀行口座が自動的に支払い口座に設定される。
一方、後者の場合は、決められた銀行口座が端末20のユーザに提案され、その上で、端末20のユーザが同意した場合には、その銀行口座が支払い口座に設定される。
図8-1は、本実施例においてクレジットカード会社サーバ10の記憶部15に記憶される支払い口座決定用データのデータ構成例を示す図である。
このデータは、限定ではなく例として、前述した端末20AのユーザA.Aについて設定されるデータである。
上記の全ての情報を関連付けて記憶させる必要はなく、一部の情報を記憶させないようにしてもよい。
また、条件の成否の判定を上記のデータを参照することによって実現するのではなく、プログラムによって実現してもよい。
これは、他の実施例で説明するデータについても同様である。
以下、「口座決定条件」の一例について詳細に説明する。
No「SP11」には、口座決定条件として「購入した商品またはサービスの種別」が定められており、これに関連付けて、複数の商品またはサービスの種別が定められている。この例では、商品の種別として、「食料品」、「衣料品」、「医薬品」などの複数の種別が記憶されている。
No「SP12」には、口座決定条件として「商品またはサービスを購入した店舗の種別」が定められており、これに関連付けて、複数の店舗の種別が設定されている。この例では、店舗の種別として、「スーパーマーケット」、「百貨店」、「レストラン」などの複数の種別が記憶されている。
No「SP13」には、口座決定条件として「商品またはサービスを購入した購入金額」が定められており、これに関連付けて、複数の購入金額の範囲が設定されている。この例では、購入金額の範囲として、「10万円未満」、「10万円以上50万円未満」、「50万円以上100万円未満」などの複数の範囲が記憶されている。
または、端末20のユーザの入力に基づいて、クレジットカード会社サーバ10の制御部11が生成して記憶部15に記憶しておくようにすることができる。
端末20が判定を行うのであれば、上記の通信によって、特定の人物の端末20が近傍に位置しているか否かを判定可能である。
クレジットカード会社サーバ10が判定を行うのであれば、端末20が上記の通信結果の情報をクレジットカード会社サーバ10に送信することで、クレジットカード会社サーバ10側で判定可能となる。
図8-2は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
ここでは、クレジットカード会社サーバ10の制御部11が、支払い口座を決定する場合の処理を例示する。また、ここでは、支払い口座に設定する銀行口座の候補を端末20のユーザに提案(サジェスト)する場合の処理を例示する。
なお、図1-11、図1-12に示したA130およびC130までの処理は同様であるため、図示・説明は省略する。
なお、支払い口座が定まらない場合とは、上記の支払い口座決定用データの条件に当てはまるものがないような場合である。
この場合、A130では、受信した請求情報が端末20Aの表示部24に表示されるが、この際、決定された支払い口座の情報が併せて表示されることで、支払い口座とする銀行口座がユーザに提案される。
これにより、ユーザは、その銀行口座を支払い口座として設定して問題ないかを検討することができる。
第8実施例の手法は、第1変形例で説明した各種の内容について同様に適用することが可能である。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、支払い口座自動設定方式で支払い口座を設定するようにすることも可能である。
(a)チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
(b)電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
(c)チャットサービスの機能と電子マネーサービスの機能とを有する複合的(統合的)なアプリケーションを構成する形態
を適用することも可能である。
本変形例における処理は、限定ではなく例として、図8-2の処理を、図1-24~図1-25、図1-28、図1-30、図1-32等の処理に適用することで同様に構成可能であるため、詳細な説明は省略する。
第9実施例は、クレジットカードの銀行口座に関連付けられた特典情報をユーザに報知するとともに、その特典情報に対応する特典をユーザが受けられるようにする実施例である。
第9実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図9-1は、本実施例において端末20Aの表示部24に表示される画面の一例を示す図であり、クレジットカード会社のwebページに対応する支払い口座設定画面の一例を示している。
また、クレジットカードに紐づけられたB銀行のキャッシュカードを模式化した画像の下には、このB銀行の銀行口座から口座振替を行った場合の特典情報として、「B銀行 クーポン配布中」の文字を含むキャンペーン画像G1Bが表示されている。
また、その他には、図1-10中央の画面と同様の情報が表示されている。
本実施例における処理は、図1-11、図1-12に示したフローチャートに倣って同様に構成することができる。
なお、図1-11、図1-12に示したフローチャートのうちのC150およびA160以外の処理とは同様であるため、説明を省略する。
また、B銀行の銀行口座を支払い口座とする支払いが行われた場合、B銀行サーバ50Bによる口座振替処理が行われた後、クレジットカード会社サーバ10は、その特典として、クーポン提供処理(限定ではなく例として、クーポン情報を端末20Aに送信する処理)を行うようにすることができる。
本実施例は、端末20が、自己の端末20のユーザによって支払い口座として選択された銀行口座情報に関連付けられた割引、キャンペーン、クーポン等の情報(限定ではなく、第1口座情報に関連付けられた特典情報の一例)を表示部24に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、選択された第1口座情報に関連する第1口座により支払いを行うことによって特典を取得可能であることや、取得可能な特典を、端末のユーザが認識できるようにすることができる。
このような構成により得られる実施例の効果の一例として、選択された第1口座情報に関連する第1口座による支払いに基づいて端末のユーザが取得した特典を確認させることができる。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、クレジットカードに紐づけられた銀行口座に関連付けられた特典情報を表示するようにすることも可能である。
(a)チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
(b)電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
(c)チャットサービスの機能と電子マネーサービスの機能とを有する複合的(統合的)なアプリケーションを構成する形態
を適用することも可能である。
また、クレジットカードに紐づけられたB銀行のキャッシュカードを模式化した画像の下には、このB銀行の銀行口座から口座振替を行った場合の特典情報として、「B銀行 クーポン配布中」の文字を含むキャンペーン画像G1Bが表示されている。
また、その他には、図1-31中央の画面と同様の情報が表示されている。
本変形例における処理は、限定ではなく例として、図1-24~図1-25、図1-28、図1-30、図1-32等の処理に基づいて同様に構成可能であるため、詳細な説明は省略する。
上記の実施例において、新規銀行に関する情報(限定ではなく例として、新規銀行情報)や、その新規銀行に対応する画像情報(限定ではなく例として、新規銀行の口座開設を行う銀行口座を選択するための情報)を表示させるようにしてもよい。
また、新規銀行の口座開設に伴いユーザに付与される特典情報を表示させるようにしてもよい。
限定ではなく例として、新規銀行の銀行名、その新規銀行のキャンペーン情報等を含めることができる。
図9-3は、本実施例において端末20Aの表示部24に表示される画面の一例を示す図であり、クレジットカード会社のwebページに対応する支払い口座設定画面の一例を示している。
また、その他には、図1-10中央の画面と同様の情報が表示されている。
本実施例における処理は、図1-11、図1-12に示したフローチャートに倣って同様に構成することができる。
なお、図1-11、図1-12に示したフローチャートのうちのC150およびA160以外の処理とは同様であるため、説明を省略する。
限定ではなく例として、メッセージングアプリケーションや電子マネーアプリケーション等のアプリケーションによって、新規銀行情報等の情報を表示するようにすることも可能である。
(a)チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
(b)電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
(c)チャットサービスの機能と電子マネーサービスの機能とを有する複合的(統合的)なアプリケーションを構成する形態
を適用することも可能である。
図9-4は、本実施例において端末20Aの表示部24に表示される画面の一例を示す図であり、電子マネーアプリケーションにおける支払い口座設定画面の一例を示している。
また、その他には、図1-31中央の画面と同様の情報が表示されている。
本変形例における処理は、限定ではなく例として、図1-24~図1-25、図1-28、図1-30、図1-32等の処理に基づいて同様に構成可能であるため、詳細な説明は省略する。
(1)上記の実施例では、合計決済金額のうちの各決済金額(取引別)の口座振替をいずれの銀行口座から行うかを取引ごとに設定する例を示したが、このような形態に限らず、合計決済金額のうちの各決済金額(取引別)の口座振替をいずれの銀行口座から行うかをまとめて設定できるようにしてもよい。
そして、この第1アイコン(限定ではなく例として、A銀行に対応する第1アイコン)がタップされた後、第2アイコンがタップされると、限定ではなく例として、今月度の支払い口座の設定がまとめて行われるようにする。
具体的には、限定ではなく例として、クレジットカード決済におけるクレジットカード会社への支払い方法として、電子マネーまたは電子マネーに変換可能なポイントを用いた方法で支払いを行う。この場合、支払い口座設定画面や取引別支払い口座設定画面の第1アイコン表示領域に、電子マネーまたは電子マネーに変換可能なポイントを用いた方法で支払いを行うための第5アイコン(限定ではなく例として、「pay払い」の文字を含むアイコン、「ポイント払い」の文字を含むアイコン等)が表示されるようにすることができる。
(A)振替金額固定方式
(B)割合設定方式
具体的には、限定ではなく例として、合計決済金額が「10万円」であり、一の銀行口座から口座振替を行う振替金額としてユーザによって「6万円」が指定されると、「6万円」が一の銀行口座から口座振替され、残りの振替金額である「4万円」が他の銀行口座から口座振替されるように設定される。
具体的には、限定ではなく例として、合計決済金額が「10万円」であり、ユーザによって一の銀行口座から口座振替を行う振替金額と、他の銀行口座から口座振替を行う振替金額との割合が「8:2」に指定されると、合計決済金額の「10万円」のうち「8万円」が一の銀行口座から口座振替され、残りの振替金額の「2万円」が他の銀行口座から口座振替されるように設定される。
(A)法人クレジットカード
(B)家族クレジットカード
「法人クレジットカード」では、口座振替を行う銀行口座として法人の銀行口座やユーザ個人の銀行口座を設定することができる。
「法人クレジットカード」は、「会社クレジットカード」や、「コーポレートカード」、「ビジネスカード」等と称してもよい。
「家族クレジットカード」では、口座振替を行う銀行口座として契約者の銀行口座を設定することができる。
「家族クレジットカード」は、「ファミリーカード」等と称してもよい。
具体的には、限定ではなく例として、前述した「法人クレジットカード」や「家族クレジットカード」を利用した場合、これらのクレジットカード決済における取引に関する情報(請求情報、当月確定請求情報)が、上記のようなクレジットカードのユーザとは異なる人の端末20に送信されるようにすることができる。
また、限定ではなく例として、「家族クレジットカード」を利用した場合、このクレジットカード決済における取引に関する情報(請求情報、当月確定請求情報)が、このクレジットカードのユーザとは異なる契約者である人(限定ではなく例として、契約者である親等)の端末20に送信されるようにすることができる。
具体的には、法人クレジットカードの場合、限定ではなく例として、「仕事上ではない私的な種別の商品・サービスの購入があったタイミング」等を適用することができる。また、家族クレジットカードの場合、限定ではなく例として、「高額な購入金額の商品・サービスの購入があったタイミング」等を適用することができる。
(A)分割払い支払い口座固定方式
(B)分割払い支払い口座変動方式
具体的には、ユーザによって3回払いの分割払いが選択され、最初の支払いにおいて銀行口座(限定ではなく例として、A銀行に対応する銀行口座)が支払い口座として選択されると、この銀行口座が分割払いの毎月の支払いにおける支払い口座として設定される。
具体的には、ユーザによって3回払いの分割払いが選択され、毎月の支払いにおいて一の銀行口座(限定ではなく例として、1回目の支払い:A銀行に対応する銀行口座、2回目の支払い:B銀行に対応する銀行口座、3回目の支払い:A銀行に対応する銀行口座)が支払い口座として選択されると、これらの銀行口座が分割払いの毎月の支払いにおける支払い口座として設定される。
具体的には、限定ではなく例として、請求情報や当月確定請求情報に、クレジットカードに紐づいている銀行口座情報として、銀行名や口座番号とともに、限定ではなく例として、銀行口座の残高に関連する残高情報が表示されるようにしてもよい。
具体的には、ユーザ(預金者)の銀行口座の残高に関連する情報として、限定ではなく例として、少なくとも以下のいずれかを含めることができる。
(A)予想残高情報
(B)残高オブジェクト情報
具体的には、限定ではなく例として、ユーザの銀行口座の残高が10万円であり、決済金額が4万円である場合、予想残高情報として「60,000円」を表示させるようにすることができる。
具体的には、限定ではなく例として、ユーザの給与支給日の残高(限定ではなく例として、30万円)を100%とした円グラフや棒グラフ(ゲージ)をオブジェクトとし、最新の銀行口座の残高(限定ではなく例として、10万円)が、この例では「33%」の円グラフや棒グラフ(ゲージ)として表示されるようにすることができる。
具体的には、限定ではなく例として、決済金額が銀行口座の残高を超えることをユーザに報知する方法として、限定ではなく例として、少なくとも以下のいずれかを含めることができる。
(A)予想残高情報の表示態様を変化させる
(B)アラート情報を表示させる
具体的には、限定ではなく例として、決済金額が銀行口座の残高を超えない場合は、予想残高情報がデフォルトの第1表示態様(限定ではなく例として、黒文字)で表示される。一方、決済金額が銀行口座の残高を超える場合は、予想残高情報が第1表示態様とは異なる第2表示態様(限定ではなく例として、赤文字)で表示されるようにすることができる。
「アラート情報」とは、決済金額が銀行口座の残高を超えることをユーザに報知するための情報であり、限定ではなく例として、請求情報や当月確定請求情報に含めることができる。
具体的には、限定ではなく例として、決済金額が銀行口座の残高を超えない場合は、アラート情報は表示されないが、決済金額が銀行口座の残高を超える場合は、アラート情報(限定ではなく例として、「残高が不足しています。」の文字やマーク等)が表示されるようにすることができる。
なお、このアラート情報のみが、請求情報や当月確定請求情報とは異なる情報として端末20に送信されて表示されるようにしてもよい。
具体的には、サーバが、支払い口座として設定された銀行口座の残高が、その支払い口座からの支払い金額に満たないと判定した場合に、現時点では支払い口座の残高が不足していることを示す残高不足情報や、支払いができないことを示す支払い不可情報を含む支払い口座設定リマインド情報を、端末20に送信するようにすることができる。
このような構成により得られる変形例の効果の一例として、少なくとも第1口座の残高の情報に基づいて、購入情報の少なくとも一部に基づく通知情報が端末に送信されるようにすることができる。
具体的には、限定ではなく例として、「支払い口座の残高が設定金額を下回った」、「決済金額が支払い口座の残高を超えた」等の条件を設定することができる。
この条件が成立しない場合は、クレジットカード決済におけるクレジットカード会社への支払い方法をユーザが選択することを不可とする。一方、この条件が成立する場合は、クレジットカード決済におけるクレジットカード会社への支払い方法をユーザが選択することを可能とする。
このような構成により得られる実施例の効果の一例として、端末のユーザによって選択された第1口座情報に関連する第1口座の残高が支払いを行うのに不足しているような場合に、ローンの情報を端末のユーザに報知することができる。
この場合、複数の銀行口座の中から支払い口座として設定する銀行口座をユーザに選択させるのではなく、デフォルトの支払い口座とは異なる銀行口座から支払いを希望する取引をユーザに選択させるようにしてもよい。
限定ではなく例として、A銀行の銀行口座とB銀行の銀行口座とが登録されており、A銀行の銀行口座がデフォルトの支払い口座として設定されている場合、B銀行の銀行口座から支払いを希望する取引をユーザに選択させるようにする。そして、選択された取引について、支払い口座をB銀行の銀行口座に更新するようにすることができる。
第10実施例は、前述した実施例とは異なる手法によって、後払いを実現する実施例である。後払いとしては、前述したように、(1)クレジットカード決済、(2)ツケ払い、のいずれを適用することも可能である。
前述した実施例では、端末20のユーザに関連するクレジットカードに、複数の銀行口座が紐づけられていた。
それに対し、以下説明する実施例では、端末20のユーザに関連するクレジットカードに、1つの銀行口座のみが紐づけられる。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
これにより、ユーザにより選択された取引について、実際には、そのユーザのメイン銀行口座から購入金額が引き落とされてクレジットカード会社に支払われるが、ユーザにとっては、あたかもサブ銀行口座からクレジットカード会社への支払いが行われたように見えることになる。
このようにして送金を行うことを「口座間送金」と称する。
(1)取引ごとに送金(電子マネー振替・チャージ&出金)を行う手法
(2)取引ごとに電子マネー振替・チャージを行い、複数の取引についてまとめて出金を行う手法
(3)複数の取引についてまとめて送金(電子マネー振替・チャージ&出金)を行う手法
(3-1)取引ごとに送金設定を行い、複数の取引についてまとめて送金を行う手法
(3-2)複数の取引についてまとめて送金設定を行い、複数の取引についてまとめて送金を行う手法
本実施例では、システム構成として、限定ではなく例として、図1-14に示した通信システム1Bを適用する。
また、本実施例では、図1-14で説明したサーバ60を、電子マネーサービス事業者のサーバとして説明する。
図10-1は、本実施例においてクレジットカード会社サーバ10の記憶部15に記憶されるユーザ管理データベース159の一例であるユーザ管理データベース159Eのデータ構成例を示す図である。
各々のユーザ管理データには、契約者IDと、電子マネーアプリケーションIDと、取引データと、第1登録銀行口座データとが記憶される。
各々のアカウント管理データには、限定ではなく例として、電子マネーアプリケーションIDと、電子マネー口座残高と、取引データと、第2登録銀行口座データと、支払い口座設定データとが記憶される。
口座振替トークンは、この口座IDに対応する口座振替トークンが記憶される。
具体的には、前述した第1登録銀行口座データに記憶されている口座ID、つまり、ユーザのクレジットカードに紐づけられた銀行口座をメイン銀行口座とし、これに対応する口座IDには「メイン」が関連付けて記憶される。一方、前述した第1登録銀行口座データに記憶されていない口座ID、つまり、ユーザのクレジットカードに紐づけられていない銀行口座をサブ銀行とし、これに対応する口座IDには「サブ」が関連付けて記憶される。
図10-3は、本実施例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図10-3は、端末20Aの電子マネーアプリケーションにおいて支払い口座を設定する場合の表示画面の一例を示す図である。
この画面最上部には、電子マネーアプリケーションの名称である「Payment App」の文字が表示されている。
また、その下には、支払い口座を設定するための情報が表示されている。
また、その他には、図1-31右の画面と同様の情報が表示されている。
つまり、本実施例では、サブ銀行口座(上記の例では、B銀行の銀行口座)から支払い金額は引き落とされず、実際にはメイン銀行口座(上記の例では、A銀行の銀行口座)から支払い金額が引き落とされるのであるが、上記のような表示を行うことにより、あたかもサブ銀行口座から支払い金額が引き落とされるかのようにユーザに見せることができる。つまり、ユーザは口座間送金が行われることを意識する必要はなく、支払い口座を選択すれば済む。
図10-4,図10-5は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。この処理は、前述した(1)の手法を適用する場合の処理の一例である。
この図では、左側から順に、端末20Aの制御部21が実行する処理、サーバ60の制御部21が実行する処理、クレジットカード会社サーバ10の制御部11が実行する処理、A銀行サーバ50Aの制御部が実行する処理の一例を示している。
具体的には、この請求情報について、ユーザがサブ銀行口座(B銀行の銀行口座(口座ID:BB001))から支払うことを希望する場合、サブ銀行口座の選択の入力を受け付ける。そして、制御部21は、サブ銀行口座が選択された旨を示す支払い口座選択情報を、通信I/F22によってサーバ60に送信する(A680)。
また、この場合、制御部61は、B660a,B670のステップをスキップするようにすることができる。
そして、B銀行サーバ50Bの制御部は、処理を終了する。
そして、A銀行サーバ50Aの制御部は、処理を終了する。
そして、制御部61は、処理を終了する。
ただし、この場合であっても、制御部61は、B660a,B670のステップはスキップするようにすることができる。
一例として、電子マネー振替の手数料と、入金の手数料との両方を電子マネーサービス事業者が負担するようにし、対応する提携銀行(上記の例では、A銀行およびB銀行)に手数料をそれぞれ支払うようにすることができる。
また、別例として、電子マネー振替の手数料は、電子マネーサービス事業者が負担するようにし、入金の手数料は、出金先の銀行(上記の例では、A銀行)が受け持つようにすることができる。
本実施例は、サーバ60(限定ではなく、端末と通信するサーバの一例)が、端末20のユーザにより、クレジットカード決済やツケ払い(限定ではなく、後払いの一例)での購入に関する請求情報(限定ではなく、購入情報の一例)をクレジットカード会社サーバ10から受信する。そして、サーバ60は、端末20のユーザがメイン銀行口座(限定ではなく、第1口座の一例)から支払う金額(限定ではなく、第1金額の一例)の情報を含む支払い口座選択情報(限定ではなく、第1情報の一例)と、端末20のユーザがサブ銀行口座(限定ではなく、第2口座の一例)から支払う金額(限定ではなく、第2金額の一例)の情報を含む支払い口座選択情報(限定ではなく、第2情報の一例)とのうち、少なくともサブ銀行口座に関する支払い口座選択情報を端末20から受信する。そして、サーバ60は、受信した口座間送金依頼情報に基づいて、口座間送金処理(限定ではなく、第2口座から第1口座に第2金額を送金することに関する処理の一例)を制御部61によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第2口座から第1口座に第2金額を送金させた上で、第1口座から後払いによる支払いが行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、第2購入情報について、あたかも第2口座から支払われるかの如く、実際には、第1口座から支払いが行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、設定された期日までに、第2口座から第1口座への第2金額の送金が行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、第2口座から第1口座に第2金額を送金させた上で、第1口座からクレジットカードによる支払いが行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、第3口座を介して、第2口座から第1口座に第2金額を適切に送金することができる。
このような構成により得られる実施例の効果の一例として、送金することに関する処理の処理主体であるサーバによって第3口座が管理されるため、第3口座を介した送金が確実に行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1口座の残高から第3口座にチャージする処理によって、第2口座から第3口座への第2金額の送金を実現することができる。
このような構成により得られる実施例の効果の一例として、電子貨幣で第2金額が適切にチャージされるようにすることができる。
前述した(2)の手法を適用することも可能である。
この手法では、複数の取引についてまとめて出金を行うため、前述した手数料を削減することができるという利点がある。
B650の後、通信I/F64によって端末20Aから支払い口座選択情報を受信すると、制御部61は、電子マネー振替&チャージ処理を行う(B661)。
具体的には、電子マネー振替を依頼する銀行サーバ50(この例では、B銀行サーバ50B)との間で、限定ではなく例として、図10-6のB6610~B6640、E6610~E6620と同様の処理を行う。
出金条件は、限定ではなく例として、「出金日時になったこと」とすることができる。
一方、出金条件が成立したと判定したならば(B663:YES)、制御部61は、出金処理を行う(B665)。
具体的には、出金を行う銀行サーバ50(この例では、A銀行サーバ50A)との間で、限定ではなく例として、図10-6のB6650~B6660、D6650~D6660と同様の処理を行う。
そして、サーバ60の制御部61は、電子マネー振替&チャージ処理において第2の電子マネー口座にチャージし、出金処理において第2の電子マネー口座から出金するようにすることができる。
前述した(3)の手法を適用することも可能である。
この手法も、複数の取引についてまとめて送金(チャージ&出金)を行うため、前述した手数料を削減することができるという利点がある。
各々のアカウント管理データには、限定ではなく例として、電子マネーアプリケーションIDと、電子マネー口座残高と、取引データと、第2登録銀行口座データと、支払い口座設定データとが記憶される。
具体的には、限定ではなく例として、端末20Aから受信した支払い口座選択情報に基づき、アカウント管理データの支払い口座設定データにおいて、この請求情報に対応する取引IDに関連付けられた支払い口座IDに、ユーザA.Aのサブ銀行口座の口座ID(この例では、B銀行の口座ID:BB001)を記憶させるとともに、送金フラグを「ON」に設定する。
口座間送金条件は、限定ではなく例として、「口座間送金日時になったこと」とすることができる。口座間送金日時は、限定ではなく例として、出金日時と同様に、支払い口座設定期限よりも後であって、口座振替日よりも前の日時として設定しておくことができる。
この口座間送金処理は、図10-6と同様の手順で行うことができるが、制御部61は、アカウント管理データの支払い口座設定データにおいて、送金フラグが「ON」に設定されている取引IDの購入金額を合計した金額を送金金額として、図10-6と同様の処理を行う。そして、制御部61は、送金フラグを全て「OFF」に戻す。
図10-10は、前述した(3-2)の手法を適用した場合において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。図10-10は、端末20の電子マネーアプリケーションにおいて支払い口座を設定する場合の表示画面の一例を示す図である。
また、その下には、図2-4中央の画面と同様の情報が表示されている。
また、その下には、図2-4右の画面と同様の情報が表示されている。
このうち、図10-11は、図10-9に対応する部分を示している。
一方、入力がなされたと判定したならば(A740:YES)、制御部21は、支払い口座設定を要求するための支払い口座設定要求情報を、通信I/F22によってサーバ60に送信する(A750)。
その後、制御部21は、入力部を介して、ユーザによる支払い口座の選択を受け付ける(A770)。具体的には、当月度請求情報に含まれる各々の取引情報について、ユーザがメイン銀行口座から支払う取引情報(以下、「第1取引情報」と称する。)と、ユーザがサブ銀行口座から支払う取引情報(以下、「第2取引情報」と称する。)とのうち、少なくとも第2取引情報の選択を受け付ける。
第1取引情報は、1または複数の取引情報とすることができる。同様に、第2取引情報も、1または複数の取引情報とすることができる。
具体的には、限定ではなく例として、端末20Aから受信した支払い口座選択情報に基づき、アカウント管理データの支払い口座設定データにおいて、ユーザによって選択された各々の第2取引情報について、対応する取引IDに関連付けられた支払い口座IDに、ユーザA.Aのサブ銀行口座の口座ID(この例では、B銀行の口座ID:BB001)を記憶させるとともに、送金フラグを「ON」に設定する。
そして、制御部61は、B664に処理を進める。
このような構成により得られる変形例の効果の一例として、設定された日にちに、または設定された期日までに、第2口座から第1口座への第2金額の送金が行われるようにすることができる。
このような構成により得られる変形例の効果の一例として、第2購入情報と第3購入情報との合計の金額を含む第2金額を、第2口座から第1口座に送金させることができる。
このような構成により得られる変形例の効果の一例として、クレジットカードの支払い日に基づいて、第2口座から第1口座への第2金額の送金が行われるようにすることができる。
サーバ60が、ユーザによってメイン銀行口座から支払うことが選択された取引情報に対応する購入金額と、ユーザによってサブ銀行口座から支払うことが選択された取引情報に対応する購入金額とを含む金額の情報を、クレジットカード会社サーバ10に送信して、クレジットカード会社に通知するようにしてもよいし、しなくてもよい。
しかし、サーバ60が、上記の金額の情報をクレジットカード会社サーバ10に送信することで、クレジットカード会社は、ユーザが複数の銀行口座をどのように使い分けているかなどの分析を行うことができる。
このような構成により得られる実施例の効果の一例として、端末のユーザに関連する第2口座によって支払う第2金額の情報を含む第2情報ばかりでなく、端末のユーザに関連する第1口座によって支払う第1金額の情報を含む第1情報も受信した上で、第1情報と第2情報とに基づいて、第1金額と第2金額とを含む金額を第1口座から支払うことに関する処理を行うことができる。
このような構成により得られる実施例の効果の一例として、端末のユーザに関連する第1口座によって支払う第1金額と、端末のユーザに関連する第2口座によって支払う第2金額とを含む金額の情報を、クレジットカードの情報を管理する第1サーバのユーザ(クレジットカード会社等)に通知することができる。これにより、第1サーバのユーザは、受信した金額の情報に基づいて、ユーザが第1口座と第2口座とをどのように使い分けているかなどの分析を行うことができる。
クレジットカード決済によるユーザの支払い金額を、電子マネーサービス事業者が立て替える、つまり、一時的に負担するようにする。そして、電子マネーサービス事業者が、立て替えた金額(以下、「立替金額」と称する。)を、ユーザのメイン銀行口座(第1口座)から口座振替等によって引き落とすようにすることも可能である。
B666の後、制御部61は、立替支払い条件が成立したか否かを判定する(B792)。立替支払い条件は、ユーザに立て替えてクレジットカード決済の支払い金額を、電子マネーサービス事業者がクレジットカード会社に支払う条件である。
この立替支払い条件は、限定ではなく例として、「立替支払い日時になったこと」とすることができる。立替支払い日時は、限定ではなく例として、クレジットカード会社によって設定される日時とすることができる。
具体的には、限定ではなく例として、アカウント管理データの取引データに基づき、ユーザA.Aの当月分の支払い金額を算出する。そして、算出した支払い金額を「立替金額」とし、振込処理等を行って、電子マネーサービス事業者の銀行口座からクレジットカード会社の銀行口座に立替金額を送金する。
口座振替要求条件は、サーバ60が口座振替を銀行サーバ50に要求(依頼)するための条件であり、限定ではなく例として、「電子マネーサービス事業者が設定した口座振替日時(限定ではなく例として、毎月25日の24時)になったこと」とすることができる。
この口座振替処理により、振替要求金額(=立替金額)が電子マネーサービス事業者に支払われる。
・第1金額の情報と、第2金額の情報
・第1金額と第2金額とを合計した合計金額の情報(第1口座から支払う金額の情報)
・第1金額と第2金額とを合計した合計金額の情報(第1口座から支払う金額の情報)と、第2金額の情報(第2口座から支払う金額の情報)
そして、サーバ60は、第1金額と第2金額とを含む金額を端末20のユーザのメイン銀行口座から支払うことに関する処理として、振替要求金額(=立替金額)の情報を含む口座振替要求情報(限定ではなく、第1金額と第2金額とを含む金額の情報の一例)を、通信I/F64によってユーザのメイン銀行口座を管理する銀行サーバ50(限定ではなく、第1口座を管理する第2サーバの一例)に送信する処理を行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに関連する第1口座によって支払う第1金額と、端末のユーザに関連する第2口座によって支払う第2金額とを含む金額の情報を、端末のユーザの第1口座を管理する第2サーバのユーザ(金融機関等)に通知することができる。これにより、第2サーバのユーザは、受信した情報に基づく金額を、サーバのユーザ(電子マネーサービス事業者等)に支払うなどすることができる。
上記の実施例では、サーバのユーザ(事業者)を、電子マネーサービス事業者(電子マネーアプリケーションの事業者)としたが、これに限定されない。
限定ではなく例として、銀行等の金融機関をサーバのユーザ(事業者)としてもよい。
この場合、ユーザのメイン銀行口座とサブ銀行口座とが同一銀行(または、同一銀行同一支店)の銀行口座である場合は、この銀行の銀行サーバ50が、サブ銀行口座からメイン銀行口座への振替(振替処理)を行って送金を実現すればよい。
一方、ユーザのメイン銀行口座とサブ銀行口座とが異なる銀行の銀行口座である場合は、限定ではなく例として、サブ銀行口座の銀行の銀行サーバ50が、サブ銀行口座から他行のメイン銀行口座への振込(振込処理)を行って送金を実現すればよい。
この場合、限定ではなく例として、前述した電子マネーサービス事業者等の資金移動業者をサーバのユーザとすることができるが、前述した以下の形態のいずれかの形態を適用し、上記の実施例において、チャットサービス(チャットアプリケーション)を介在させることもできる。
(a)チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
(b)電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
(c)チャットサービスの機能と電子マネーサービスの機能とを有する複合的(統合的)なアプリケーションを構成する形態
第11実施例は、ユーザがクレジットカード決済を行った後、その支払いをサブ銀行口座から行う金額(第2金額)等の情報をサーバ60が銀行サーバ50に送信する。そして、メイン銀行口座を管理する銀行サーバ50と、サブ銀行口座を管理する銀行サーバ50との間で口座間送金を実現する実施例である。
以下では、この手法を「銀行方式口座間送金」と称する。
第11実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
(A)取引ごとに送金(振込)を行う手法
(B)取引ごとに振替要求金額を設定する処理を行い、複数の取引についてまとめて送金を行う手法
(C)複数の取引についてまとめて送金(振込)を行う手法
(C-1)取引ごとに送金設定を行い、複数の取引についてまとめて送金を行う手法
(C-2)複数の取引についてまとめて送金設定を行い、複数の取引についてまとめて送金を行う手法
本実施例では、あらかじめ、サーバ60によって、アカウント管理データにおける対象とするユーザ(ここでは「ユーザA.A」として説明する。)の電子マネーアプリケーションIDと、この電子マネーアプリケーションIDが記憶されたアカウント管理データの第2登録銀行口座データに含まれる種別が「メイン」である銀行口座(ここでは「A銀行の銀行口座」として説明する。)の口座IDに関連付けられた口座振替トークンとを含む情報が、通信I/F64によってA銀行サーバ50Aに送信される。
そして、A銀行サーバ50Aによって、ユーザA.Aの電子マネーアプリケーションIDと、ユーザA.AのA銀行の銀行口座に関連付けられた口座振替トークンとが関連付けて記憶される。
そして、B銀行サーバ50Bによって、ユーザA.Aの電子マネーアプリケーションIDと、ユーザA.AのB銀行の銀行口座に関連付けられた口座振替トークンとが関連付けて記憶される。
電子マネーアプリケーションIDとは異なる識別情報を介して銀行方式口座間送金を実現してもよい。
また、提携銀行の同意を得た上で、口座振替トークンを介して銀行方式口座間送金を実現してもよい。
なお、図10-4、図10-5に示したB650までの処理と、B670以降の処理とは同様であるため、図示・説明は省略する。
この図では、左側から順に、端末20Aの制御部21が実行する処理、サーバ60の制御部21が実行する処理、クレジットカード会社サーバ10の制御部11が実行する処理、A銀行サーバ50Aの制御部が実行する処理の一例を示している。
銀行方式口座間送金情報は、銀行方式口座間送金を依頼する情報であり、この例では、A銀行サーバ50Aに対して、B銀行サーバ50Bからお金を引き出すように依頼する情報である。
具体的には、不図示の記憶部に記憶された口座管理データベースのうち、受信した振込要求情報に含まれる電子マネーアプリケーションIDと関連付けられた口座振替トークンに対応する口座管理データに記憶された口座残高から、振込要求情報に含まれる送金金額を減算するとともに、振込要求情報の送信元であり、振込先であるA銀行サーバ50Aに、その送金金額を送金する。
本実施例は、サーバ60が、端末20のユーザがサブ銀行口座から支払いを行うことを予定している支払い予定金額(限定ではなく、第2金額の一例)の情報を、メイン銀行口座(第1口座)を管理する銀行サーバ50(限定ではなく、第2サーバの一例)に送信する処理を含む銀行方式口座間送金処理を行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに関連する第2口座によって支払う第2金額を、端末のユーザに関連する第1口座を管理する第2サーバに通知することができる。
前述した(B)の手法を適用することも可能である。
この手法では、複数の取引についてまとめて送金を行うため、前述した手数料を削減することができるという利点がある。
B650の後、通信I/F64によって端末20Aから支払い口座選択情報を受信すると、制御部61は、第2の銀行方式口座間送金処理を行う(B660d)。
具体的には、限定ではなく例として、A銀行サーバ50Aから受信した振込要求情報に含まれる電子マネーアプリケーションIDと関連付けて、受信した振込要求情報に含まれる送金金額を加算して更新し、送金フラグを「ON」に設定する。
振込条件は、限定ではなく例として、「振込日時になったこと」とすることができる。振込日時は、限定ではなく例として、前述した送金日時や出金日時と同様に、支払い口座設定期限よりも後であって、口座振替日よりも前の日時として設定しておくことができる。
これを受けて、B銀行サーバ50Bの制御部は、振込処理を行う(E6615)。
具体的には、不図示の記憶部に記憶された口座管理データベースのうち、受信した振込要求情報に含まれる電子マネーアプリケーションIDと関連付けられた口座振替トークンに対応する口座管理データに記憶された口座残高から、この電子マネーアプリケーションIDと関連付けて記憶されている最新の送金金額(累積的な送金金額)を減算するとともに、振込要求情報の送信元であり、振込先であるA銀行サーバ50Aに、その送金金額を送金する。
そして、B銀行サーバ50Bの制御部は、E6617に処理を進める。
この場合、B銀行サーバ50Bは、受信した振込要求情報に含まれる累積的な送金金額を、振込処理によってA銀行サーバ50Aに送金する。
前述した(C)の手法を適用することも可能である。
この手法では、複数の取引についてまとめて送金を行うため、前述した手数料を軽減することができるという利点がある。
具体的には、限定ではなく例として、端末20Aから受信した支払い口座選択情報に基づき、アカウント管理データの支払い口座設定データにおいて、この請求情報に対応する取引IDに関連付けられた支払い口座IDに、ユーザA.Aのサブ銀行口座の口座ID(この例では、B銀行の口座ID:BB001)を記憶させるとともに、送金フラグを「ON」に設定する。
銀行方式口座間送金条件は、限定ではなく例として、「銀行方式口座間送金日時になったこと」とすることができる。銀行方式口座間送金日時は、限定ではなく例として、出金日時と同様に、支払い口座設定期限よりも後であって、口座振替日よりも前の日時として設定しておくことができる。
この第3の銀行方式口座間送金処理は、図11-2の第1の銀行方式口座間送金処理と同様の手順で行うことができるが、制御部61は、アカウント管理データの支払い口座設定データにおいて、送金フラグが「ON」に設定されている取引IDの購入金額を合計した金額を送金金額として、B6615のステップを実行する。そして、制御部61は、送金フラグを全て「OFF」に戻す。
第10変形例(3)と同様に、サーバ60が、ユーザによってメイン銀行口座から支払うことが選択された取引情報に対応する購入金額と、ユーザによってサブ銀行口座から支払うことが選択された取引情報に対応する購入金額とを含む金額の情報を、クレジットカード会社サーバ10に送信して、クレジットカード会社に通知するようにしてもよいし、しなくてもよい。
このような構成により得られる実施例の効果の一例として、端末のユーザに関連する第2口座によって支払う第2金額の情報を含む第2情報ばかりでなく、端末のユーザに関連する第1口座によって支払う第1金額の情報を含む第1情報も受信した上で、第1情報と第2情報とに基づいて、第1金額と第2金額とを含む金額を第1口座から支払うことに関する処理を行うことができる。
このような構成により得られる実施例の効果の一例として、端末のユーザに関連する第1口座によって支払う第1金額と、端末のユーザに関連する第2口座によって支払う第2金額とを含む金額の情報を、クレジットカードの情報を管理する第1サーバのユーザ(クレジットカード会社等)に通知することができる。これにより、第1サーバのユーザは、受信した金額の情報に基づいて、ユーザが第1口座と第2口座とをどのように使い分けているかなどの分析を行うことができる。
第10変形例(4)と同様に、クレジットカード決済によるユーザの支払い金額を、電子マネーサービス事業者が立て替え、その立替金額を、ユーザのメイン銀行口座(第1口座)から口座振替等によって引き落とすようにすることも可能である。
この場合は、限定ではなく例として、図10-13,図10-14の処理を、第11実施例で説明した銀行方式口座間送金に適用することで実現可能である。
・第1金額の情報と、第2金額の情報
・第1金額と第2金額とを合計した合計金額の情報(第1口座から支払う金額の情報)
・第1金額と第2金額とを合計した合計金額の情報(第1口座から支払う金額の情報)と、第2金額の情報(第2口座から支払う金額の情報)
そして、サーバ60は、第1金額と第2金額とを含む金額を端末20のユーザのメイン銀行口座から支払うことに関する処理として、振替要求金額(=立替金額)の情報を含む口座振替要求情報(限定ではなく、第1金額と第2金額とを含む金額の情報の一例)を、通信I/F64によってユーザのメイン銀行口座を管理する銀行サーバ50(限定ではなく、第1口座を管理する第2サーバの一例)に送信する処理を行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに関連する第1口座によって支払う第1金額と、端末のユーザに関連する第2口座によって支払う第2金額とを含む金額の情報を、端末のユーザの第1口座を管理する第2サーバのユーザ(金融機関等)に通知することができる。これにより、第2サーバのユーザは、受信した情報に基づく金額を、サーバのユーザ(電子マネーサービス事業者等)に支払うなどすることができる。
上記の実施例では、サーバ60からA銀行サーバ50Aに対して、B銀行サーバ50Bからお金を引き出すように依頼する情報を送信することによって、A銀行サーバ50AからB銀行サーバ50Bに対して振込要求情報が送信され、B銀行サーバ50BからA銀行サーバ50Aに振込が行われることとしたが、これに限定されない。
第10変形例(5)と同様に、サーバのユーザを、銀行等の金融機関としてもよい。
この場合、ユーザのメイン銀行口座(第1口座)とサブ銀行口座(第2口座)とが同一銀行(または、同一銀行同一支店)の銀行口座である場合は、この銀行の銀行サーバ50が、サブ銀行口座からメイン銀行口座への振替(振替処理)を行って、口座間送金を実現すればよい。
一方、ユーザのメイン銀行口座とサブ銀行口座とが異なる銀行の銀行口座である場合は、限定ではなく例として、サブ銀行口座の銀行の銀行サーバ50が、サブ銀行口座から他行のメイン銀行口座への振込(振込処理)を行って送金を実現すればよい。
この場合、限定ではなく例として、前述した電子マネーサービス事業者等の資金移動業者をサーバのユーザとすることができるが、前述した以下の形態のいずれかの形態を適用し、上記の実施例において、チャットサービス(チャットアプリケーション)を介在させることもできる。
(a)チャットアプリケーションの一機能として電子マネーサービスの機能を構成する形態
(b)電子マネーアプリケーションの一機能としてチャットサービスの機能を構成する形態
(c)チャットサービスの機能と電子マネーサービスの機能とを有する複合的(統合的)なアプリケーションを構成する形態
(1)第1実施例~第9実施例やこれらの実施例に対応する変形例に記載した内容、第1実施例~第9実施例に関連する他の実施例に記載した内容は、第10実施例,第11実施例についても同様に適用可能である。以下、その一部を例示する。
具体的には、限定ではなく例として、銀行口座情報のうち銀行名や口座番号とは異なる情報として、ユーザの銀行口座の残高、またはこれに関連する情報を表示させるようにすることも可能である。
図12-1は、本実施例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図12-1は、端末20の電子マネーアプリケーションにおける支払い口座設定画面に残高情報が表示される場合の表示画面の一例を示す図である。
また、その他には、図1-31中央の画面と同様の情報が表示されている。
しかし、第10実施例,第11実施例の口座間送金の手法では、口座振替が行われるのはメイン銀行口座のみであるため、メイン銀行口座から口座振替が行われた後であっても、支払い口座を変更できるようにすることも可能である。
この場合は、通信システム1Bの構成要素からサーバ60を除外し、図1-1の通信システム1Aを適用することが可能である。
この場合、複数の銀行口座の中から支払い口座として設定する銀行口座をユーザに選択させるのではなく、サブ銀行口座から支払いを希望する取引をユーザに選択させるようにしてもよい。
限定ではなく例として、A銀行の銀行口座がメイン銀行口座であり、B銀行の銀行口座がサブ銀行口座である場合、B銀行の銀行口座から支払いを希望する取引をユーザに選択させるようにする。そして、選択された取引について、支払い口座をB銀行の銀行口座に更新するようにすることができる。
10 クレジットカード会社サーバ
20 端末
30 ネットワーク
40 店舗端末
50 銀行サーバ
60 サーバ
Claims (29)
- 端末によって実行されるプログラムであって、
前記端末のユーザにより、後払いで購入された商品またはサービスの購入情報を前記端末の通信部によって受信することと、
前記購入情報と、前記端末のユーザに関連する複数の口座情報とを前記端末の表示部に表示することと、
前記端末のユーザにより、前記複数の口座情報のうちの第1口座情報が選択されたことに基づき、前記購入情報の少なくとも一部の支払いを前記第1口座情報に関連する第1口座で支払うことに関する第1情報を前記表示部に表示することとが前記端末によって実行される。 - 請求項1に記載のプログラムであって、
前記端末のユーザにより、前記複数の口座情報のうちの前記第1口座情報と、前記購入情報のうちの第1購入情報とが選択された場合、前記第1購入情報の支払いを前記第1口座で支払うことに関する前記第1情報を前記表示部に表示し、前記端末のユーザにより、前記複数の口座情報のうちの第2口座情報と、前記購入情報のうちの第2購入情報とが選択された場合、前記第2購入情報の支払いを前記第2口座情報に関連する第2口座で支払うことに関する第2情報を前記表示部に表示することが前記端末によって実行される。 - 請求項1または請求項2に記載のプログラムであって、
前記購入情報は、前記端末のユーザによって前記後払いで購入された商品またはサービスの購入履歴に関する情報である。 - 請求項3に記載のプログラムであって、
前記第1情報は、前記購入履歴のうちの少なくとも一部の支払いを前記第1口座に基づいて支払うことに関する情報を含む。 - 請求項1に記載のプログラムであって、
前記購入情報は、前記端末のユーザによって前記後払いで購入された商品またはサービスの合計金額に関する情報である。 - 請求項5に記載のプログラムであって、
前記第1情報は、前記合計金額のうちの第1金額を、前記端末のユーザによって選択された前記第1口座に基づいて支払うことに関する情報を含む。 - 請求項6に記載のプログラムであって、
前記端末のユーザにより、前記複数の口座情報のうちの第2口座情報が選択されたことに基づき、前記合計金額のうちの第2金額を前記第2口座情報に関連する第2口座で支払うことに関する第2情報?を前記表示部に表示することが前記端末によって実行される。 - 請求項1から請求項7のいずれか一項に記載のプログラムであって、
前記購入情報のうちの第1購入情報に対して、前記複数の口座情報のうちから少なくとも一つの口座情報を選択可能であることに関する第3情報を前記表示部に表示することが前記端末によって実行される。 - 請求項8に記載のプログラムであって、
前記第3情報は、前記複数の口座情報のうちから少なくとも一つの口座情報を選択可能な日にちに関する情報を含む。 - 請求項8または請求項9に記載のプログラムであって、
前記第3情報は、前記選択可能な時期または日にちではない場合、前記選択可能な時期または日にちとは異なる表示態様で前記表示部に表示される。 - 請求項1から請求項10のいずれか一項に記載のプログラムであって、
前記購入情報の少なくとも一部の支払いに対して、ローンで支払うことに関する第4情報を前記表示部に表示することが前記端末によって実行される。 - 請求項11に記載のプログラムであって、
前記ローンは、前記端末のユーザによって選択された前記第1口座情報に関連する第1口座によって支払いが行われる。 - 請求項1から請求項12のいずれか一項に記載のプログラムであって、
前記第1口座の残高の情報を前記表示部に表示することが前記端末によって実行される。 - 請求項13に記載のプログラムであって、
前記残高の情報に基づいて、ローンに関連する情報を前記表示部に表示することが前記端末によって実行される。 - 請求項1から請求項14のいずれか一項に記載のプログラムであって、
前記複数の口座情報は、前記端末のユーザに関連するクレジットカードの情報と関連付けられて記憶される。 - 請求項15に記載のプログラムであって、
前記後払いは、前記クレジットカードによって行われ、
前記クレジットカードによって行われた、前記購入情報の少なくとも一部に対する支払いは、前記端末のユーザによって選択された前記第1口座情報に関連する前記第1口座から行われる。 - 請求項1から請求項16のいずれか一項に記載のプログラムであって、
前記後払いは、設定された日、または設定された期日までに支払うことを含む。 - 請求項1から請求項17のいずれか一項に記載のプログラムであって、
前記第1口座情報に関連付けられた特典情報を前記表示部に表示することが前記端末によって実行される。 - 請求項18に記載のプログラムであって、
前記第1口座による支払いに基づいて、前記端末のユーザに関連付けられた前記特典情報を前記表示部に表示することが前記端末によって実行される。 - 請求項1から請求項19のいずれか一項に記載のプログラムであって、
前記複数の口座情報は、前記購入情報の少なくとも一部に基づく通知情報を前記通信部によって受信することに基づき、前記表示部に表示される。 - 請求項20に記載のプログラムであって、
前記通知情報は、設定された時間間隔で前記端末に送信される。 - 請求項20または請求項21に記載のプログラムであって、
前記通知情報は、前記購入情報の少なくとも一部に対して、前記複数の口座情報のうちから少なくとも一つの口座情報を選択可能な期間または日にちに基づいて前記端末に送信される。 - 請求項20から請求項22のいずれか一項に記載のプログラムであって、
前記通知情報は、前記購入情報に含まれる決済数に基づいて前記端末に送信される。 - 請求項20から請求項23のいずれか一項に記載のプログラムであって、
前記通知情報は、前記購入情報に基づく合計金額が設定された金額よりも大きい場合、前記端末に送信される。 - 請求項20から請求項24のいずれか一項に記載のプログラムであって、
前記通知情報は、少なくとも前記第1口座の残高の情報に基づいて前記端末に送信される。 - 端末の情報処理方法であって、
前記端末のユーザにより、後払いで購入された商品またはサービスの購入情報を前記端末の通信部によって受信することと、
前記購入情報と、前記端末のユーザに関連する複数の口座情報とを前記端末の表示部に表示することと、
前記端末のユーザにより、前記複数の口座情報のうちの第1口座情報が選択されたことに基づき、前記購入情報の少なくとも一部の支払いを前記第1口座情報に関連する第1口座で支払うことに関する第1情報を前記表示部に表示することとを含む。 - 端末であって、
前記端末のユーザにより、後払いで購入された商品またはサービスの購入情報を受信する通信部と、
前記購入情報と、前記端末のユーザに関連する複数の口座情報とを表示する表示部と、
前記端末のユーザにより、前記複数の口座情報のうちの第1口座情報が選択されたことに基づき、前記購入情報の少なくとも一部の支払いを前記第1口座情報に関連する第1口座で支払うことに関する第1情報を前記表示部に表示する制御を行う制御部とを備える。 - 端末であって、
メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサーを備え、
前記プロセッサーは、
前記端末のユーザにより、後払いで購入された商品またはサービスの購入情報を前記端末の通信部によって受信することと、
前記購入情報と、前記端末のユーザに関連する複数の口座情報とを前記端末の表示部に表示することと、
前記端末のユーザにより、前記複数の口座情報のうちの第1口座情報が選択されたことに基づき、前記購入情報の少なくとも一部の支払いを前記第1口座情報に関連する第1口座で支払うことに関する第1情報を前記表示部に表示することとを実行する。 - 端末と通信するサーバであって、
前記端末のユーザにより後払いで購入された購入情報を受信し、前記購入情報を前記端末に送信し、前記購入情報の少なくとも一部を、前記端末のユーザに関連する複数の口座のうちの第1口座によって支払うことに関する情報を前記端末から受信する通信部を備える。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020212995A JP7266019B2 (ja) | 2020-12-22 | 2020-12-22 | プログラム、情報処理方法、端末、サーバ |
PCT/JP2021/046544 WO2022138448A1 (ja) | 2020-12-22 | 2021-12-16 | プログラム、情報処理方法、端末、サーバ |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020212995A JP7266019B2 (ja) | 2020-12-22 | 2020-12-22 | プログラム、情報処理方法、端末、サーバ |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2022099174A true JP2022099174A (ja) | 2022-07-04 |
JP7266019B2 JP7266019B2 (ja) | 2023-04-27 |
Family
ID=82261935
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2020212995A Active JP7266019B2 (ja) | 2020-12-22 | 2020-12-22 | プログラム、情報処理方法、端末、サーバ |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP7266019B2 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7269429B1 (ja) | 2022-08-19 | 2023-05-08 | PayPay株式会社 | サービス提供装置、サービス提供方法、およびプログラム |
JP7320155B1 (ja) | 2022-12-23 | 2023-08-02 | PayPay株式会社 | サービス提供装置、サービス提供方法、およびプログラム |
JP7506805B1 (ja) | 2023-07-12 | 2024-06-26 | 株式会社三井住友銀行 | 銀行システム、及び銀行システムによって実行される方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002083145A (ja) * | 2000-06-29 | 2002-03-22 | Hitachi Ltd | 決済用カードを用いた決済システムにおけるセンタ装置、決済方法、コンピュータシステム、決済用カード、及び、処理方法 |
WO2004010356A1 (ja) * | 2002-07-19 | 2004-01-29 | Fujitsu Limited | 決済システム、決済装置、決済プログラム、および決済プログラム記憶媒体 |
JP2004062233A (ja) * | 2002-07-24 | 2004-02-26 | Nri & Ncc Co Ltd | クレジットカードの利用代金振込のためのサービス提供システム |
-
2020
- 2020-12-22 JP JP2020212995A patent/JP7266019B2/ja active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002083145A (ja) * | 2000-06-29 | 2002-03-22 | Hitachi Ltd | 決済用カードを用いた決済システムにおけるセンタ装置、決済方法、コンピュータシステム、決済用カード、及び、処理方法 |
WO2004010356A1 (ja) * | 2002-07-19 | 2004-01-29 | Fujitsu Limited | 決済システム、決済装置、決済プログラム、および決済プログラム記憶媒体 |
JP2004062233A (ja) * | 2002-07-24 | 2004-02-26 | Nri & Ncc Co Ltd | クレジットカードの利用代金振込のためのサービス提供システム |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7269429B1 (ja) | 2022-08-19 | 2023-05-08 | PayPay株式会社 | サービス提供装置、サービス提供方法、およびプログラム |
JP2024028085A (ja) * | 2022-08-19 | 2024-03-01 | PayPay株式会社 | サービス提供装置、サービス提供方法、およびプログラム |
JP7320155B1 (ja) | 2022-12-23 | 2023-08-02 | PayPay株式会社 | サービス提供装置、サービス提供方法、およびプログラム |
JP2024028100A (ja) * | 2022-12-23 | 2024-03-01 | PayPay株式会社 | サービス提供装置、サービス提供方法、およびプログラム |
JP7506805B1 (ja) | 2023-07-12 | 2024-06-26 | 株式会社三井住友銀行 | 銀行システム、及び銀行システムによって実行される方法 |
Also Published As
Publication number | Publication date |
---|---|
JP7266019B2 (ja) | 2023-04-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7266019B2 (ja) | プログラム、情報処理方法、端末、サーバ | |
JP7354089B2 (ja) | サーバ、プログラム、情報処理方法 | |
US11468466B2 (en) | Social-financial network systems and methods | |
US20140337188A1 (en) | Electronic invoicing and payment | |
US20120221403A1 (en) | Merchant interface for online coupon system | |
JP2016532979A (ja) | 共同金融管理 | |
AU2021341692A1 (en) | Application integration for contactless payments | |
CN105960654A (zh) | 用于对网页内容、虚拟商品和小额物品付费的方法和装置 | |
US20220172194A1 (en) | Cryptocurrency rewards for a virtual cash card | |
US20200126052A1 (en) | Transfers using credit accounts | |
JP7086923B2 (ja) | プログラム、情報処理方法、端末 | |
WO2022085579A1 (ja) | プログラム、情報処理方法、端末、サーバ | |
JP2021192260A (ja) | プログラム、情報処理方法、端末 | |
JP7175877B2 (ja) | プログラム、表示方法、端末 | |
WO2022138448A1 (ja) | プログラム、情報処理方法、端末、サーバ | |
KR101415457B1 (ko) | 등록금 대납 방법, 기부자와 학생을 연계하는 방법, 근로장학제도와 학생을 연계하는 방법 및 이들을 수행하기 위한 서버 | |
JP6941666B2 (ja) | プログラム、情報処理方法、端末 | |
US20190197521A1 (en) | Merchant-centric gift card processing | |
JP7183217B2 (ja) | プログラム、情報処理方法、端末 | |
JP7250186B2 (ja) | サーバ、プログラム、情報処理方法 | |
JP7271851B1 (ja) | サーバ、コンピュータプログラム、方法 | |
JP7342791B2 (ja) | 決済プログラム、決済システムおよび決済サーバ | |
JP7357591B2 (ja) | プログラム、情報処理方法、端末 | |
JP7417482B2 (ja) | プログラム、情報処理方法、端末 | |
JP2022176304A (ja) | サーバ、プログラム、情報処理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20210412 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20220804 |
|
A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20220804 |
|
RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20220804 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20221108 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20221228 |
|
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: 20230322 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20230417 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 7266019 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |