JP2022010422A - プログラム、情報処理方法、端末 - Google Patents
プログラム、情報処理方法、端末 Download PDFInfo
- Publication number
- JP2022010422A JP2022010422A JP2021189023A JP2021189023A JP2022010422A JP 2022010422 A JP2022010422 A JP 2022010422A JP 2021189023 A JP2021189023 A JP 2021189023A JP 2021189023 A JP2021189023 A JP 2021189023A JP 2022010422 A JP2022010422 A JP 2022010422A
- Authority
- JP
- Japan
- Prior art keywords
- remittance
- terminal
- user
- display
- information
- 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.)
- Pending
Links
- 230000010365 information processing Effects 0.000 title description 8
- 238000003672 processing method Methods 0.000 title description 3
- 238000004891 communication Methods 0.000 claims abstract description 113
- 238000000034 method Methods 0.000 claims description 225
- 230000008569 process Effects 0.000 claims description 193
- 238000012545 processing Methods 0.000 abstract description 136
- 238000012986 modification Methods 0.000 description 99
- 230000004048 modification Effects 0.000 description 99
- 230000000694 effects Effects 0.000 description 69
- 230000005540 biological transmission Effects 0.000 description 67
- 230000006870 function Effects 0.000 description 62
- 238000012790 confirmation Methods 0.000 description 29
- 238000010586 diagram Methods 0.000 description 21
- 230000004044 response Effects 0.000 description 15
- 238000004364 calculation method Methods 0.000 description 13
- 238000010079 rubber tapping Methods 0.000 description 12
- 238000012546 transfer Methods 0.000 description 8
- 238000001514 detection method Methods 0.000 description 5
- 239000000725 suspension Substances 0.000 description 5
- 230000007704 transition Effects 0.000 description 5
- 230000003203 everyday effect Effects 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 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 3
- 230000001133 acceleration Effects 0.000 description 3
- 230000007423 decrease Effects 0.000 description 3
- 239000010432 diamond Substances 0.000 description 3
- 238000005259 measurement Methods 0.000 description 3
- 101150080339 BTS1 gene Proteins 0.000 description 2
- 238000000151 deposition Methods 0.000 description 2
- 229910003460 diamond Inorganic materials 0.000 description 2
- 238000005401 electroluminescence Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 102100027675 Guanine nucleotide exchange factor subunit RIC1 Human genes 0.000 description 1
- 101000581349 Homo sapiens Guanine nucleotide exchange factor subunit RIC1 Proteins 0.000 description 1
- 101150048508 RIC2 gene Proteins 0.000 description 1
- 241000872198 Serjania polyphylla Species 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
- 230000003111 delayed effect Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Description
本発明の第2の態様によると、端末の情報処理方法は、第1ユーザによる送金依頼に関する第1情報を端末の通信部によって受信することと、第1情報に基づく第1表示を端末の表示部に表示することと、送金依頼に基づく、第1表示とは異なる第2表示を表示部に表示することと、端末のユーザによる、表示部に表示された第2表示に対する入力に基づいて、送金依頼に基づく、端末のユーザから第1ユーザへの送金に関する送金処理を端末の制御部によって実行することとを含む。
本発明の第3の態様によると、端末は、第1ユーザによる送金依頼に関する第1情報を受信する通信部と、第1情報に基づく第1表示と、送金依頼に基づく、第1表示とは異なる第2表示とを表示する表示部と、表示部に表示された第2表示に対する入力に基づいて、送金依頼に基づく、端末のユーザから第1ユーザへの送金に関する送金処理を実行する制御部とを備える。
本発明の第4の態様によると、端末は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、第1ユーザによる送金依頼に関する第1情報を端末の通信部によって受信することと、第1情報に基づく第1表示を端末の表示部に表示することと、送金依頼に基づく、第1表示とは異なる第2表示を表示部に表示することと、端末のユーザによる、表示部に表示された第2表示に対する入力に基づいて、送金依頼に基づく、端末のユーザから第1ユーザへの送金に関する送金処理を行うこととを実行する。
本発明の第5の態様によると、端末と通信するサーバによって実行されるプログラムは、第1ユーザによる送金依頼に関する第1情報を端末にサーバの通信部によって送信することと、送金依頼に基づく第2情報を端末に通信部によって送信することと、端末の表示部に表示された、第2情報に基づく第2表示に対する入力に基づいて、送金依頼に基づく、端末のユーザから第1ユーザへの送金に関する送金処理をサーバの制御部によって実行することとを含む。
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
図1-1は、本実施例における通信システム1のシステム構成の一例を示す図である。
通信システム1では、限定ではなく例として、ネットワーク30を介して、サーバ10と、複数の端末20(端末20A,端末20B,端末20C,・・・)とが接続される。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
なお、ネットワーク30に接続されるサーバ10の数や端末20の数は限定されない。
通信システム1に含まれる各装置の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、時計部19を備える。サーバ10のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、サーバ10のHWは、サーバ10のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ10のHWは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部11に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入力部は、限定ではなく例として、タッチパネルやカメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含んでいてもよいし、そうでなくてもよい。
サーバ10は、プログラムPを記憶部15に記憶し、このプログラムPを実行することで、制御部11が、制御部11に含まれる各部としての処理を実行する。つまり、記憶部15に記憶されるプログラムPは、サーバ10に、制御部11が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
他の装置についても同様である。
他の装置についても同様である。
他の装置についても同様である。
他の装置についても同様である。
サーバ10および/または端末20における処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末20における処理の少なくとも一部を、サーバ10により行う構成としてもよいし、そうでなくてもよい。この場合、端末20の制御部21の各機能部の処理のうち少なくとも一部の処理を、サーバ10で行う構成としてもよいし、そうでなくてもよい。
サーバ10における処理の少なくとも一部を、端末20により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ10の制御部11の各機能部の処理のうち少なくとも一部の処理を、端末20で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
・サーバの機能を端末20に持たせるシステム(分散システム)。これは、限定ではなく例として、ブロックチェーン(チェイン)の技術を用いて実現することが可能である。
・端末20同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース等の近距離無線通信技術を用いてP2P(ピアツーピア)方式等で通信を行うことで実現可能である。
近年、ネットワークサービスに関連するアプリケーション(アプリケーションソフトウェア)として、電子貨幣による支払いを行うためのアプリケーション(支払いアプリケーション)、電子貨幣による決済を行うためのアプリケーション(決済アプリケーション)、電子貨幣による送金/受取を行うためのアプリケーション(送金アプリケーション)といったアプリケーションや、これらのアプリケーションの一部の機能または全部の機能を集約したアプリケーションが普及しつつあり、端末20のユーザが、これらのアプリケーションを用いて、電子貨幣(電子マネー)を用いた各種のサービスを受けることが可能になってきている。
また、「電子貨幣(電子マネー)」や「デジタル通貨(デジタル貨幣)」として、法定通貨を用いてもよいし、仮想通貨を用いてもよい。
また、「電子貨幣(電子マネー)」や「デジタル通貨(デジタル貨幣)」には、暗号通貨(暗号資産)を含めてもよい。
また、仮想通貨には、クーポンなどの物的貨幣を含めてもよい。
送金を依頼することを「送金リクエストする」、「送金リクエストを行う」等のように表現する場合がある。
また、送金を依頼されることを「送金リクエストされる」、「送金リクエストが行われる」、等のように表現する場合がある。
送金をリマインドすることを「送金リマインドする」、「送金リマインドを行う」等のように表現する場合がある。
また、送金をリマインドされることを「送金リマインドされる」、「送金リマインドが行われる」等のように表現する場合がある。
送金マスターユーザは、「送金リクエスト元ユーザ」や「送金リクエスト主ユーザ」等のように表現することもできる。
チャットルームとは、コンピュータネットワーク上のデータ通信回線を用いて端末20の1以上のユーザがコミュニケーションを行うための仮想的な部屋である。
メッセージングサービスでは、チャットルームを「トークルーム」と称する場合がある。
このため、メッセージングサービス:MSと、ソーシャルネットワーキングサービス:SNSとは区別してもよいし、区別しなくてもよい。
第1実施例は、送金リクエスト先ユーザの端末20が、受け取り済みの送金リクエストに基づいて、自動で送金リマインド表示を行う実施例である。以下、この手法を「端末リマインド」と称する。
第1実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
(1)サーバ
図1-2は、本実施例においてサーバ10の制御部11によって実現される機能の一例を示す図である。
サーバ10の制御部11は、限定ではなく例として、記憶部15に記憶されている支払いアプリケーション管理処理プログラム151に従って、支払いアプリケーションによる各種の支払いサービスを端末20、または端末20のユーザに提供するための処理を行う支払いアプリケーション管理処理部111を機能部として含む。
記憶部15には、限定ではなく例として、制御部11によって読み出され、支払いアプリケーション管理処理として実行される支払いアプリケーション管理処理プログラム151と、ユーザ登録データ153と、ユーザ管理データベース155と、送金リクエスト管理データ157とが記憶される。
ユーザ登録データ153には、限定ではなく例として、ユーザ名と、アプリケーションIDと、端末電話番号と、その他登録情報とが関連付けて記憶される。
このアプリケーションIDは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ10によってアカウントごとに一意な値(固有の値)が設定されて記憶される。
アプリケーションIDは、端末20、またはその端末20のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
また、端末20のユーザを識別するための識別情報は、限定ではなく例として、アプリケーションIDとすることができる。なお、これを「ユーザID」としてもよいし、しなくてもよい。
各々のユーザ管理データには、限定ではなく例として、アプリケーションIDと、そのアプリケーションIDによって識別されるユーザの電子マネー口座残高と、送金履歴データと、受金履歴データとが記憶される。
第1送金リクエスト管理データ157Aには、限定ではなく例として、日時と、送金リクエスト管理IDと、送金マスターIDと、送金リクエスト先IDと、送金リクエスト金額と、送金済みフラグとが関連付けて記憶される。
送金リクエスト先IDには、送金リクエスト先ユーザのアプリケーションIDが記憶される。
「パターンA」:送金済み(送金済みフラグON)となった送金リクエストを削除せずに残す。
「パターンB」:送金済み(送金済みフラグON)となった送金リクエストを削除する。
つまり、サーバ10は、送金済みフラグを「ON」に設定した送金リクエストについても、そのデータを削除せずに残すものとする。
図1-7は、本実施例において端末20の制御部21によって実現される機能の一例を示す図である。
制御部21は、限定ではなく例として、記憶部28に記憶されている支払いアプリケーション処理プログラム281に従って、支払いアプリケーション処理を実行する支払いアプリケーション処理部211を機能部として含む。
記憶部28には、限定ではなく例として、制御部21によって読み出され、支払いアプリケーション処理として実行される支払いアプリケーション処理プログラム281と、自己の端末20またはそのユーザに関連付けられたアプリケーションID283とが記憶される。
以下では、限定ではなく例として、端末20が、縦長のディスプレイの表示部24を備えるスマートフォンである場合を例示する。
タップ(タップ操作)とは、限定ではなく例として、ユーザが、タッチパネルが一体的に構成された表示部24(タッチスクリーン)を指やペン先などで軽く叩くように触れる動作、触れてから離す動作である。
表示部24には、端末20により実行される支払いアプリケーションの機能に基づいて、端末20のユーザ(支払いアプリケーションのユーザ)に対して、送金リクエスト情報を受信したことを通知する送金リクエスト表示MS1が表示されている。
限定ではなく、送金リクエスト表示MS1とボタンBT1は、第1ユーザ(本例ではA.A)による送金リクエストに関する第1情報(限定ではなく例として、送金リクエスト情報)を端末20が受信したことに基づいて表示される第1表示の一例である。
ユーザが「開く」の文字が示されたボタンBT1をタップすることで、支払いアプリケーションの機能に基づいて、送金リクエストの詳細が表示される。
画面最上部中央には、この画面が支払いアプリケーションの機能に基づくことを示す「Payment App」の文字が表示されている。その右側には、この端末20の支払いアプリケーションにおけるユーザのアイコン画像およびユーザ名(本例では「B.B」)が表示されている。
さらに下方には、送金リクエストの詳細を示す送金リクエスト表示MS2が表示されている。
限定ではなく、送金リクエスト表示MS2は、第1ユーザ(本例ではA.A)による送金依頼に関する第1情報に基づいて表示される第1表示の一例である。
端末20のユーザB.Bが、送金確認画面において確認ボタンBT6をタップすることで、送金リクエストにより指定された金額(送金リクエスト金額:送金リクエスト表示MS2により示されている金額)が、端末20のユーザB.Bの電子マネー口座から第1ユーザ(A.A)の電子マネー口座に送金される。
ユーザが「開く」の文字が示されたボタンBT3をタップすることで、支払いアプリケーションの機能に基づいて、送金リマインドの詳細が表示される。
すなわち、送金リマインド表示MS4において、送金リクエストに対する送金処理が未だ実行されていないことに対しての送金リマインドが行われたことが、メッセージの内容または表示態様によって通知されている。
限定ではなく、送金リマインド表示MS4は、送金依頼に基づく、第1表示とは異なる第2表示の一例である。
端末20のユーザ(B.B)が、送金確認画面において確認ボタンBT6をタップすることで、送金リマインド表示MS4により指定された金額が、端末20のユーザ(B.B)の電子マネー口座から第1ユーザ(A.A)の電子マネー口座に送金される。
図1-13~図1-14は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
また、以下説明する処理に、別のステップを追加してもよいし、一部のステップを省略(削除)してもよい。
これは、以下説明する各フローチャート(処理)について同様である。
限定ではなく例として、端末20AのユーザA.Aを送金マスターユーザとし、端末20BのユーザB.Bを送金リクエスト先ユーザとする場合を例示する。
また、送金リマインドは1回に限らず2回以上行うことも可能であるが、ここでは簡単のため、処理の終了判定を省略して、送金リマインドが1回だけ行われる場合の処理として図示・説明する。送金リマインドを2回以上行う場合も同様である。
送金リクエスト実行入力は、限定ではなく例として、送金リクエストの実行を要求するための操作(以下、「送金リクエスト実行操作」と称する。)とすることができる。
送金リクエスト表示は、受信した送金リクエスト情報に含まれる一部または全部の情報の表示の他、受信した送金リクエスト情報に関連する情報の表示や、受信した送金リクエスト情報に基づき送金を実現するための情報(限定ではなく例として、送金ボタン、送金アイコン等の操作用画像)の表示を含むようにすることができる。
送金を実行すると判定したならば(B120:YES)、端末20Bの制御部21は、送金の決済を要求するための送金決済要求情報を、通信I/F22によってサーバ10に送信する(B130)。
送金予定金額とは、送金する金額として入力された金額であって、未だ送金が行われていない状態の金額である。
具体的には、限定ではなく例として、ユーザB.Bの電子マネー口座残高から送金予定金額分の金額を送金金額として減算して更新するとともに、ユーザA.Aの電子マネー口座残高に送金金額を加算して更新する。
送金金額とは、送金リクエスト先ユーザから送金マスターユーザに対して送金された金額である。
また、第1送金リクエスト管理データ157Aにおける、受信した送金リクエスト管理IDに対応する送金済みフラグを「ON」に設定する。
送金済みフラグが「ON」となった送金リクエスト管理IDについては、以降、送金を行わない。
なお、この場合に、サーバ10の制御部11が、端末20Bに対して、電子マネー口座残高にチャージするように促す情報を送信する。そして、チャージを要求する情報を端末20Bから受信したことに基づいて、電子マネー口座残高にチャージした上で、送金を行うようにしてもよいし、しなくてもよい。
送金情報には、限定ではなく例として、送金が完了したことを通知するための送金完了通知の情報等が含まれる。
受金情報には、限定ではなく例として、受金が完了したことを通知するための受金完了通知の情報等が含まれる。
ただし、これとは異なり、送金リクエストに基づく送金が実行されたか否かに関わらず、送金リマインドを行うようにすることもできる。
「入力」は、限定ではなく例として入力部(操作部)に対する操作、限定ではなく例として、タップ(タップ操作)とすることができる。
また、この入力には、前述した各種の送金リマインド表示MSに対する入力を含めることができる。送金ボタンのタップに限らず、限定ではなく例として、前述した各種の送金リマインド表示MSのうちのいずれかの送金リマインド表示MSについて、その表示領域がタップされたことを入力として、送金を実現するようにすることもできる。
この場合も、限定ではなく例として、先に受信した送金リクエスト情報の送金リクエスト管理IDと、送金予定金額とを送金決済要求情報に含めることができる。
また、サーバ10の制御部11は、前述した受金情報を、通信I/F14によって端末20Aに送信する(S150)。
そして、サーバ10の制御部11は、処理を終了する。
また、通信I/F22によってサーバ10から受金情報を受信すると(A140:YES)、端末20Aの制御部21は、受信した受金情報を表示部24に表示させる(A150)。そして、端末20Aの制御部21は、処理を終了する。
端末20(限定ではなく例として、送金リクエスト先ユーザの端末20)が制御部21によって実行する処理には、送金処理(以下、この端末が実行する送金処理を「第1送金処理」と称する。)が含まれる。
第1送金処理は、端末20が実行する処理であって、送金リクエスト(送金依頼)に基づく、送金リクエスト先ユーザ(端末のユーザ)から送金マスターユーザ(第1ユーザ)への送金に関する処理である。
(1)送金決済要求情報を通信I/F22によってサーバ10に送信する処理
(2)送金情報を通信I/F22によってサーバ10から受信する処理
(3)受信した送金情報を表示部24に表示する処理
上記の処理では、送金リクエスト実行入力や、送金リマインド表示に対する入力などの、端末に対する入力または端末のユーザによる入力を、入力部(操作部)に対する操作入力としたが、これに限定されない。
これは、端末に対する他の入力や端末のユーザによる他の入力についても同様である。
本実施例は、端末20が、送金マスターユーザ(限定ではなく、第1ユーザの一例)による送金リクエスト情報(限定ではなく、送金依頼に関する第1情報の一例)を通信I/F22によって受信する。そして、端末20は、送金リクエスト表示(限定ではなく、第1表示の一例)を表示部24に表示する。
また、端末20は、送金リクエストに基づく、送金リクエスト情報とは異なる送金リマインド表示(限定ではなく、第2表示の一例)を表示部24に表示する。そして、端末20は、表示部24に表示された送金リマインド表示に対する入力(限定ではなく、第2表示に対する入力の一例)に基づいて、送金リクエストに基づく第1送金処理(限定ではなく、端末のユーザから第1ユーザへの送金に関する送金処理の一例)を制御部21によって実行する構成を示している。
このような構成により得られる実施例の効果の一例として、端末の表示部に表示された第2表示に対する入力に基づいて、送金処理を端末の制御部によって実行して、端末のユーザから第1ユーザへの送金を簡単に実現することができる。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく金額を、第1表示と第2表示とによって端末のユーザに確実に知らせることができる。
このような構成により得られる実施例の効果の一例として、送金の依頼元のユーザの情報を、第1表示と第2表示とによって端末のユーザに確実に知らせることができる。
このような構成により得られる実施例の効果の一例として、端末にインストールされたアプリケーションによって、第1表示と第2表示とを端末のユーザに簡単に認識させることができる。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく送金の処理が実行されたことを端末のユーザに知らせることができる。
このような構成により得られる実施例の効果の一例として、第1ユーザからの送金依頼に基づく送金の処理を外部に依頼することができる。
送金リクエスト先ユーザの端末20において、第1送金処理が実行されていない場合(未実行の場合)、送金マスターユーザからの送金リクエストに基づく送金が行われていないことに関する表示(限定ではなく、第4表示の一例)を表示部24に表示する。一方、送金リクエスト先ユーザの端末20において、第1送金処理が実行されている場合(実行済みである場合)、送金マスターユーザからの送金リクエストに基づく送金が行われていることに関する表示(限定ではなく、第5表示の一例)を表示部24に表示するようにしてもよいし、しなくてもよい。
同様に、送金マスターユーザからの送金リクエストに基づく送金が行われていることに関する表示には、限定ではなく例として、「既に送金されています」、「送金済みです」といったテキストや、送金済みの状態であることを示す画像(マークやアイコン等)を含めることができる。
このような構成により得られる変形例の効果の一例として、送金依頼に基づく送金の状況(行われている/行われてない)を、端末のユーザに適切に知らせることができる。
第1実施例では、送金リクエスト先ユーザの端末20において、リマインド表示の1つとして、プッシュ通知を行うことができることとした。このプッシュ通知は、リマインド表示の一種とも言えるし、リマインド通知の一種とも言える。
・制御部21が、音出力部26に所定の音を出力させるように制御する。
・制御部21が、不図示の振動部を制御して端末20の筐体を振動させる。
・制御部21が、不図示の発光部に所定の発光を行わせるように制御する。
このようにすることで、これらの設定時間帯では、リマインド通知条件が成立せず、リマインド通知処理が実行されないため、ユーザが就寝している可能性の高い時間帯にリマインド通知が行われないようにすることができる。
このような構成により得られる変形例の効果の一例として、設定された条件に基づいて、端末リマインドの実行を、端末のユーザに適切なタイミングで通知することができる。
第1実施例において、送金リクエスト先ユーザの端末20で送金リクエストに基づく送金を実行する際に、限定ではなく例として、送金リマインドに基づく送金を実行する場合と同様に、表示部24に表示された送金リクエスト表示に対する入力に基づいて、送金を実行するようにすることができる。
このフローチャートは、図1-13~図1-14のフローチャートにおける図1-14の処理部分に対応するフローチャートである。
この場合における入力は、前述した送金リマインド表示に対する入力と同様に、タップ(タップ操作)等の操作入力や、音入力等とすることができる。
入力がなされたと判定したならば(B125:YES)、端末20Bの制御部21は、B130に処理を移す。
このような構成により得られる実施例の効果の一例として、端末のユーザによる第1表示に対する入力に基づいて、送金依頼に基づく送金を簡単に実現することができる。
第1実施例では、第1ユーザを、一般ユーザである端末20のユーザ(上記の例ではユーザA.A)として説明したが、これに限定されない。
第1ユーザを、一般ユーザではなく、店舗等の事業者のユーザとしてもよいし、しなくてもよい。この場合における事業者には、限定ではなく例として、商品の販売(サービスの提供を含む。)を行う事業者や貸金業を営む事業者など、送金依頼によって端末20のユーザに対して金銭の請求を行うことが想定される事業者(店舗)が含まれる。
このような構成により得られる変形例の効果の一例として、一般のユーザばかりでなく、店舗のユーザも、端末のユーザに対して送金依頼を行うことのできるユーザ(第1ユーザ)とすることができる。
端末20のユーザによっては、送金リクエスト先ユーザに対して送金リクエストや送金リマインドを行うことに気まずさを感じ、躊躇してしまう場合が想定される。限定ではなく例として、送金リクエスト先ユーザが自分よりも目上の人であったり、送金リクエスト先ユーザが親友である場合等である。
業務用アカウントは、限定ではなく例として、そのサービス(上記の例では支払いサービス)において公式のアカウント(以下、「公式アカウント」と称し、適宜「OA:Official Account」と表現する。)を有するユーザである。
このような構成により得られる変形例の効果の一例として、送金依頼を行うことを希望するユーザに代わって、業務用アカウントを利用するユーザに送金依頼を行わせることが可能となり、ユーザの利便性を向上させることができる。
第2実施例は、送金リクエスト先ユーザの端末20が、サーバ10から送金リマインド情報を受信したことに基づいて、送金リマインド表示を行う実施例である。以下、この手法を「サーバリマインド」と称する。
第2実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図2-1は、サーバ10の記憶部15に記憶される、前述した送金リクエスト管理データ157の別例である第2送金リクエスト管理データ157Bの構成例を示す図である。
第2送金リクエスト管理データ157Bには、第1送金リクエスト管理データ157Aにおける、日時と、送金リクエスト管理IDと、送金マスターIDと、送金リクエスト先IDと、送金リクエスト金額と、送金済みフラグとに加えて、限定ではなく例として、情報種別が関連付けて記憶される。
限定ではなく例として、図中黒枠で囲ったレコードのデータが、対応関係にある送金リクエストおよび送金リマインドのデータである。
図2-2は、第1ユーザ(A.A)の端末20で支払いアプリケーションが実行されている場合の、表示部24に表示される情報の一例を示している。
表示部24には、第1ユーザ(A.A)の電子マネー口座残高(本例では「25,000円」)が表示されるとともに、支払いアプリケーションにおいて実行可能な各機能のそれぞれに対応したアイコンが表示されている。
第1ユーザ(A.A)は、自分の口座に関する入金履歴を表示部24に表示させることにより、送金が行われたか否か、並びに、送金が行われた場合における送金を行ったユーザおよび送金額を確認することができる。すなわち、送金依頼に応じて送金が行われたか否かを確認することが可能である。
第1ユーザ(A.A)が、このアイコンを選択して、送金依頼対象のユーザ(本例ではB.B)を指定し、送金依頼金額(送金リクエスト金額)(本例では「3,000円」)を入力することで、指定されたユーザ(B.B)の端末20に対して送金リクエスト情報が送信され、指定されたユーザの端末20の表示部24には、送金リクエスト表示MS1、MS2が表示される。
図2-2の例では、送金依頼履歴の閲覧機能に対応したアイコンIC2とともに「送信リクエスト一覧」の文字が表示されている。
第1ユーザ(A.A)が、このアイコンを選択することで、過去に送金依頼の対象となったユーザと、そのユーザに対する送金依頼金額とを、個別に確認することができる。
本例では、送金依頼の対象となったユーザのアイコン画像およびユーザ名(本例では、B.B)と、そのユーザの端末20が送金リクエスト情報を受信した日時(本例では、2020.04.20 21:30)と、そのユーザに対する送金依頼金額(本例では、「3,000円」)と、第1ユーザ(A.A)が、その送金依頼金額を受け取る立場であることを示すアイコン(本例では「受取」の文字のアイコン)と、が矩形状の領域R1内に関連付けて表示されている。
そして、送金リマインド情報を受信した端末20の表示部24には、送金リマインド表示が表示される。
送金リマインド完了表示MS5には、送金依頼の対象であったユーザのユーザ名(本例ではB.B)が含まれる。
図1-11に示した送金リマインド表示MS3では、自端末の機能に基づく送金リマインド表示であることに応じて「端末リマインド」と表示されているのに対して、送金リマインド表示MS3Aでは、受信した送金リマインド情報に基づく送金リマインド表示であることに応じて「リマインド受信」と表示される点が異なる。
限定ではなく、送金リマインド表示MS3AとボタンBT3Aは、送金依頼に基づく、第1表示とは異なる第2表示の一例である。
限定ではなく、送金リマインド表示MS3AとボタンBT3Aは、送金依頼に基づく第2情報を端末20が受信したことに基づいて表示部24に表示される第2表示の一例である。
図2-5において、ユーザ(B.B)が、ボタンBT3Aをタップした結果、図2-6に示す画面に移行し、送金リマインドの詳細を示す送金リマインド表示MS4Aが表示される。
また、図2-6の送金リマインド表示MS4Aでは、第1ユーザのユーザ名(A.A)の前に、送金リマインド情報に基づく送金リマインド表示であることに対応して[リマインド受信]という表示があるのに対して、図1-12に示した送金リマインド表示MS4では、このような表示が無い点も異なる。
図2-7の画面では、送金リマインド表示MS4Aによりリマインドされた送金依頼が、どのようなイベントにより生じたものであるか(本例では、4/20に行われたイベントの会費であること)が通知される。また、端末20のユーザ(B.B)が、支払いを行う立場であること(本例では、「支払い」の文字のアイコン)と、支払うべき金額(本例では、「3,000円」)とが通知される。
送金画面には、送金相手となる第1ユーザのアイコン画像およびユーザ名(A.A)と、第1ユーザに送金すべき送金額(本例では「3,000円」)と、端末20のユーザ(B.B)が支払いを行う立場であることを通知するアイコン(本例では「支払い」の文字のアイコン)と、現在の端末20のユーザ(B.B)の送金可能額(本例では「5,000円」)が表示されている。
限定ではなく例として、送金確認画面は、送金画面上に重畳表示される画面であり、送金相手となる第1ユーザのアイコン画像およびユーザ名(A.A)と、支払いアプリケーションを使用して第1ユーザに送金する予定の送金額(本例では3,000円)と、「確認」という文字が表示された確認ボタンBT6を含む。
送金が完了すると、ユーザ(B.B)の端末20には、図2-10に示す送金完了画面が表示される。
限定ではなく例として、送金完了画面は、送金画面上に重畳表示される画面であり、送金相手となる第1ユーザのユーザ名(A.A)と、送金処理が完了したことを通知するメッセージが表示される。
(1)処理の一例
図2-11は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
このフローチャートは、図1-13~図1-14のフローチャートにおける図1-14の処理部分に対応するフローチャートであり、サーバ10が、送金リクエスト先ユーザの端末20(この例では端末20B)に対して、自動で送金リマインド情報を送信する処理を示すフローチャートである。
図2-12は、本実施例において各装置が実行する処理の流れの別例を示すフローチャートである。
このフローチャートは、図1-13~図1-14のフローチャートにおける図1-14の処理部分に対応するフローチャートであり、サーバ10が、送金マスターユーザの端末20(この例では端末20A)から送信される送金リマインド送信要求情報を受信したことに基づいて、送金リクエスト先ユーザの端末20(この例では端末20B)に対して送金リマインド情報を送信する処理を示すフローチャートである。
送金リマインド実行入力は、前述した送金リクエスト実行入力と同様に、限定ではなく例として、操作入力や音入力によって実現することができる。
サーバ10が制御部11によって実行する処理には、送金処理(以下、このサーバが実行する送金処理を「第2送金処理」と称する。)が含まれる。
第2送金処理は、サーバ10が実行する処理であって、送金リクエスト(送金依頼)に基づく、送金リクエスト先ユーザ(端末のユーザ)から送金マスターユーザ(第1ユーザ)への送金に関する処理である。
(1)送金決済要求情報を通信I/F14によって端末20から受信する処理
(2)送金決済処理(電子マネー口座残高のバランス調整の処理等を含む。)
(3)送金情報/受金情報を通信I/F14によって端末20に送信する処理
本実施例は、送金マスターユーザ(限定ではなく、第1ユーザの一例)による送金リクエストに関する送金リクエスト情報(限定ではなく、第1情報の一例)は、送金マスターユーザ(限定ではなく、第1ユーザの一例)による送金マスターユーザの端末20への入力に基づいて、サーバ10を介して送金リクエスト先ユーザの端末20に送信される。
一方、送金リマインド情報(限定ではなく、第2情報の一例)は、サーバ10によって、送金リクエスト先ユーザの端末20に送信され、送金リマインド表示(限定ではなく、第2表示の一例)は、送金リマインド情報に基づいて、送金リクエスト先ユーザの端末20の表示部24に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼元の第1ユーザの意向に応じて、第1情報がサーバを介して端末に送信されるようにすることができる。また、第2情報がサーバから端末に送信された上で、その第2情報に基づいて、第2表示が端末の表示部に表示されるようにすることができる。
このような構成により得られる変形例の効果の一例として、端末の表示部に表示された第2表示に対する入力に基づいて、送金処理をサーバの制御部によって実行して、端末のユーザから第1ユーザへの送金を簡単に実現することができる。
第2実施例で説明した支払いアプリケーションにおける表示画面のユーザインターフェイスや、支払いアプリケーションの機能等については、適宜設計変更可能である。
この送金リクエスト一覧画面には、限定ではなく例として、「送金リクエスト一覧」のタイトルの下方に、端末のユーザ(B.B)に対する過去の送金依頼のうち送金処理が未完了であるものについての送金依頼履歴が表示されている。
図2-13で示した送金依頼履歴が表示されている画面において、ユーザによって空白領域がタップされたことに伴い、図2-14に示すように、ソート項目選択領域SRが表示される。
その下方には、送金リクエスト情報または送金リマインド情報の受信日時に基づくソートを実行するためのボタンBTS1と、送金額(限定ではなく例として、送金リクエスト情報または送金リマインド情報により送金を要求されている金額)に基づくソートを実行するためのボタンBTS2と、支払いアプリケーションまたは支払いアプリケーションと連携しているメッセージングアプリケーションにおいて友だち登録されているユーザ名に基づくソートを実行するためのボタンBTS3が表示されている。
本例では、領域R21に、第1ユーザであるA.Aのアイコン画像およびユーザ名が表示され、領域R22に、第1ユーザであるB.Bのアイコン画像およびユーザ名が表示されている。
図2-15に示す画面では、少なくとも送金依頼を行った第1ユーザを把握することが可能な態様となっている。
画面上部の領域R20には、選択された第1ユーザ(A.A)の送金依頼に関する履歴であることを通知する情報(限定ではなく例として、「A.Aの送金リクエスト一覧」という文字)が表示され、その下方には、選択された第1ユーザ(A.A)の送金依頼に関する詳細な履歴が、図2-13に示された態様で表示される。
なお、選択されていない他の第1ユーザ(D.D)の送金依頼に関する履歴は表示されていない。
次に新しい履歴が、他の第1ユーザであるB.Bによる500円の送金依頼に対応した送金リクエスト情報(受信日時 2020.04.21 08:42)に基づく履歴であるため、上から2番目の領域R22には、B.Bのアイコン画像およびユーザ名とともに、「リクエスト受信」のアイコンが表示される。
次に新しい履歴が、第1ユーザであるA.Aによる3,000円の送金依頼に対応した送金リクエスト情報(受信日時 2020.04.20 21:30)に基づく履歴であるため、上から3番目の領域R23には、A.Aのアイコン画像およびユーザ名とともに、「リクエスト受信」のアイコンが表示される。
しかしながら、一方の第1ユーザ(A.A)の第1送金依頼に基づく送金リクエスト情報の受信後に、他方の第1ユーザ(D.D)の第2送金依頼に基づく送金リクエスト情報を受信し、その後に、一方の第1ユーザ(A.A)の第1送金依頼に基づく送金リマインド情報を受信しているため、第1送金依頼に対応した情報が表示される領域R21と、第1送金依頼に対応した情報が表示される領域R23との間の領域である領域R22に、第2送金依頼に対応した情報が表示されている。
限定ではなく例として、友だち登録確認画面は、図2-7の画面上に重畳表示される画面であり、送金しようとしている相手(限定ではなく例として、RM1に表示されているユーザ名(A.A)の第1ユーザ)が、友だち登録されている相手かどうかを端末20のユーザ(B.B)に確認させるためのメッセージ(限定ではなく例として、「送金をリクエストした人が友だちかどうか再度ご確認ください。送金を行いますか?」)が表示される。
このように、送金用のリンク情報がタップされた場合でも、送金画面に移行する前に、送金リマインドを行った第1ユーザが友だち登録されているユーザであるか否かを確認させる画面を表示することで、友だち登録されていないユーザに対して不用意に送金してしまうことを防止できる。
第1変形例(2)に関連するが、送金リクエスト先ユーザの端末20が、送金リマインド情報を受信したことに基づいて、リマインド通知処理を実行するようにすることができる。このリマインド通知処理は、限定ではなく例として、以下のいずれかの手法によって実現することができる。
・制御部21が、音出力部26に所定の音を出力させるように制御する。
・制御部21が、不図示の振動部を制御して端末20の筐体を振動させる。
・制御部21が、不図示の発光部に所定の発光を行わせるように制御する。
このような構成により得られる変形例の効果の一例として、第2情報が受信されたことを、第2条件に基づいて、端末のユーザに適切なタイミングで通知することができる。
第3実施例は、送金リマインド情報の表示・送信の手法・タイミングに関する実施例である。
第3実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
ここでは、第1実施例で説明した端末リマインドの手法を適用する場合における、送金リクエスト先ユーザの端末20で送金リマインド表示を行うタイミングについて説明する。
この設定では、送金リクエスト先ユーザの端末20は、限定ではなく例として、送金リクエスト表示を行ってから設定時間tmが経過するごとに、送金リマインド表示を行う。
本実施例は、送金リクエスト情報(限定ではなく、第1情報の一例)は、送金マスターユーザ(限定ではなく、第1ユーザの一例)による送金マスターユーザの端末20への入力に基づいて、サーバ10を介して送金リクエスト先ユーザの端末20に送信される。
また、送金リマインド表示(限定ではなく、第2表示の一例)は、送金リクエスト表示(限定ではなく、第1表示の一例)が送金リクエスト先ユーザの端末20の表示部24に表示された時刻、または送金リクエスト情報(限定ではなく、第1情報の一例)が送金リクエスト先ユーザの端末20によって受信された時刻に基づいて、送金リクエスト先ユーザの端末20の表示部24に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、第1表示が端末の表示部に表示された時刻、または第1情報が端末によって受信された時刻に基づいて、適切なタイミングで第2表示が端末の表示部に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第3表示が端末の表示部に表示されたことに基づいて、第4表示が端末の表示部に表示されるようにすることができる。
第3実施例の手法は、第2実施例で説明したサーバリマインドの手法についても同様に適用可能である。
図の見方は図3-1と同様であるが、マニュアルで送信する送金リマインド情報に対応するダイヤは「灰色」で示し、オートで送信する送金リマインド情報に対応するダイヤは「白色」で示している。
また、送金リマインド情報(限定ではなく、第2情報の一例)は、サーバ10によって、送金リクエスト先ユーザの端末20に送信され、送金リマインド表示(限定ではなく、第2表示の一例)は、送金リマインド情報に基づいて、送金リクエスト先ユーザの端末20の表示部24に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼元の第1ユーザの意向に応じて、第1情報がサーバを介して端末に送信されるようにすることができる。また、第2情報がサーバから端末に送信された上で、その第2情報に基づいて、第2表示が端末の表示部に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1情報が端末に送信された時刻、または第1情報が端末によって受信された時刻に基づいて、適切なタイミングで第2情報が端末に送信されるようにすることができる。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく第3情報が端末に送信されることに基づいて、送金依頼に基づく第2情報が適切に端末に送信されるようにすることができる。
第3実施例で説明した端末リマインドの方法(設定:オート)について、1回目の送金リマインド情報の表示と、2回目以降の送金リマインド情報の表示とで、設定時間を異ならせるようにすることも可能である。
また、送金リクエスト先ユーザの端末20は、1回目の表示から第2設定時間が経過したタイミングで、2回目の送金リマインド表示を行う。
また、送金リクエスト先ユーザの端末20は、2回目の表示から第3設定時間が経過したタイミングで、3回目の送金リマインド表示を行う。
以下同様である。
具体的には、限定ではなく例として、第1設定時間を「24時間」、第2設定時間を「18時間」、第3設定時間を「12時間」、・・・、等のようにすることができる。
このようにすることで、送金リクエストに関する表示の時間間隔(表示時間間隔)が段階的に短くなっていくため、未だ送金が行われていないことを送金リクエスト先ユーザに認識させ、送金を早く行うように注意喚起することができる。
第4実施例は、送金リマインドを行う条件に関する実施例である。
第4実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
このフローチャートは、図1-13~図1-14のフローチャートにおける図1-14の処理部分に対応するフローチャートである。
送金リマインド条件データには、限定ではなく例として、カテゴリと、送金リマインド条件とが関連付けて定められている。
(1)カテゴリ「時間」
条件No「PA-1」については、送金リマインド条件の内容として「時刻が設定時刻となった」が定められている。設定時刻には、毎日の任意の時刻(限定ではなく例として深夜0時や昼12時)を設定しておくことができる。
この条件は、現在の時刻が毎日の設定時刻となったタイミングで送金リマインド表示を表示部24に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。
この条件は、端末リマインドを行うタイミングとなった場合に、現在の時刻が設定時間帯に含まれれば、送金リマインド表示を表示部24に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。
この場合、端末20の制御部21は、端末リマインドを行うタイミングであるか否かを判定する。そして、端末リマインドを行うタイミングである場合は、時計部29Aによる計時時刻が第1設定時間帯に含まれているか否かを判定し、含まれていると判定した場合に、送金リマインド表示を表示部24に表示させるようにすることができる。
この条件は、端末リマインドを行うタイミングとなった場合に、現在の時刻が設定時間帯に含まれなければ、送金リマインド表示を表示部24に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。
この場合、端末20の制御部21は、端末リマインドを行うタイミングであるか否かを判定する。そして、端末リマインドを行うタイミングである場合は、時計部29Aによる計時時刻が第2設定時間帯に含まれるか否かを判定し、含まれないと判定した場合に、送金リマインド表示を表示部24に表示させるようにすることができる。
この条件は、現在の日付が設定されている日付となったタイミングで送金リマインド表示を表示部24に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。
条件No「PB-1」については、送金リマインド条件の内容として「電子マネー口座残高が設定金額以上」が定められている。設定金額には、任意の金額(限定ではなく例として「30,000円」)を設定しておくことができる。
この条件は、電子マネーの口座残高が設定金額以上となったタイミングで送金リマインド表示を表示部24に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。
そして、端末20の制御部21は、受信した電子マネー口座残高の情報に基づき、電子マネー口座残高が設定金額以上となったか否かを判定し、なったと判定した場合に、送金リマインド表示を表示部24に表示させるようにすることができる。
この条件は、ユーザによって端末20に入力された所持残高が設定金額以上となったタイミングで送金リマインド表示を表示部24に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。
条件No「PC-1」については、送金リマインド条件の内容として「ローンを借りることにより入金」が定められている。
この条件は、限定ではなく例として、ユーザがローンサービス、限定ではなく例として、ロークサービスの事業者によって提供されるサービスであって、ローンアプリケーション等の物的貨幣や電子貨幣に関するアプリケーションによってユーザがローンを借りることのできるサービスを利用して、銀行や電子マネーの口座残高に入金されたタイミングで送金リマインド表示を表示部24に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。
異なる事業者とするのであれば、ローンサービスの事業者は、支払いアプリケーションの事業者やメッセージングサービスの事業者と提携し、端末20のユーザのローンの金額等に関する情報を、サーバ10に送信するなどして、支払いアプリケーションの事業者やメッセージングアプリケーションの事業者に提供するようにすることができる。
この条件は、限定ではなく例として、ユーザがフリーマーケットサービス、限定ではなく例として、フリーマーケットサービスの事業者によって提供されるサービスであって、フリーマーケットアプリケーション(以下、「フリマアプリケーション」と称する。)等のアプリケーションによって商品を出品・購入することのできるサービスを利用して、出品した商品が購入されるなどして電子マネー口座残高に入金されたタイミングで送金リマインド表示を表示部24に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。
条件No「PD-1」については、送金リマインド条件の内容として「出品した商品が購入された(未入金)」が定められている。
この条件は、限定ではなく例として、ユーザがフリマアプリケーション等によって出品した商品が購入されたタイミング(電子マネーの口座残高に入金されていないタイミング)で送金リマインド表示を表示部24に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。
この条件は、ユーザが求職サービス(求職アプリケーション)等のサービスにおいて、求職を行っている期間の所定のタイミング(求職アプリケーションで、限定ではなく例として、企業にエントリーしたタイミングや企業から内定通知がきたタイミング等)で送金リマインド表示を表示部24に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。
この条件は、ユーザがフリマアプリケーション等のサービスにおいて、出品された商品を購入したタイミングで送金リマインド表示を表示部24に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。
図4-3は、限定ではなく例として、送金リクエスト情報を受信したが、未だ送金を完了していないユーザ(B.B)が、前述したフリマアプリケーションを利用して取引を行い、そのユーザ(B.B)の口座に売上金額に応じた入金があった例を示している。
限定ではなく例として、このメッセージMS25には、取引が完了したことを示す「取引完了」の文字と、その取引による売上金額(本例では「1,600円」)と、ユーザ(B.B)がその売上金額を受け取る立場であることを示す「受取」の文字のアイコンと、取引が完了した日時(本例では、2020.0423 20:59)等が含まれる。
限定ではなく例として、このメッセージMS26の表示によって、ユーザ(B.B)の口座に入金があったことに基づいて、その直後に送金を行うように促すことができる。
本実施例は、送金リマインド表示(限定ではなく、第2表示の一例)は、送金リマインド条件(限定ではなく、第1条件の一例)に基づいて、送金リクエスト先ユーザの端末20に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、設定された第1条件に基づいて、送金依頼に基づく第2表示を端末の表示部に適切に表示させることができる。
このような構成により得られる実施例の効果の一例として、時間に関する条件に基づいて、送金依頼に基づく第2表示を端末の表示部に適切に表示させることができる。
このような構成により得られる実施例の効果の一例として、送金依頼先のユーザの意向に応じた適切なタイミングで、送金依頼に基づく第2表示が端末の表示部に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、送金依頼元の第1ユーザの意向に応じた適切なタイミングで、送金依頼に基づく第2表示が端末の表示部に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、送金依頼を受ける側のユーザの残高に応じた適切なタイミングで、送金依頼に基づく第2表示が端末の表示部に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザへの送金に関する条件に基づいて、送金依頼に基づく第2表示が端末の表示部に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザがローンを借りることで、端末のユーザの金銭に余裕が生じた可能性が高いタイミングで、送金依頼に基づく第2表示が端末の表示部に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザが出品した商品が購入されて購入者によって入金(送金)され、端末のユーザの金銭に余裕が生じた可能性が高いタイミングで、送金依頼に基づく第2表示が端末の表示部に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザが出品した商品が購入されたことで、端末のユーザの金銭に余裕が生ずる見込みができたことに基づいて、送金依頼に基づく第2表示が端末の表示部に表示されるようにすることができる。
第2実施例で説明したサーバリマインドの手法を適用し、サーバ10が送金リマインド条件の成否を判定して、サーバリマインドを行うようにすることもできる。
この場合、条件No「PA-2」または条件「PA-3」を適用する場合におけるリマインドのタイミングについては、限定ではなく例として、第3変形例(1)(図3-2)で説明したサーバリマインドのタイミングを適用することができる。
また、フリマサービスを提供する事業者が支払いサービスを提供する事業者と異なる場合は、サーバ10の制御部11が、フリマサービスを提供する事業者のサーバ等の装置から、端末20のユーザが出品した商品が購入されたことを示す情報を取得できるように構成しておくことで、判定することができる。
また、求職サービスを提供する事業者が支払いサービスを提供する事業者と異なる場合は、サーバ10の制御部11が、求職サービスを提供する事業者のサーバ等の装置から、端末20のユーザが求職サービスを利用していることを示す情報を取得できるように構成しておくことで、判定することができる。
また、フリマサービスを提供する事業者が支払いサービスを提供する事業者と異なる場合は、サーバ10の制御部11が、フリマサービスを提供する事業者のサーバ等の装置から、出品されている商品を端末20のユーザが購入したことを示す情報を取得できるように構成しておくことで、判定することができる。
このフローチャートは、図4-1の処理部分を書き換えたフローチャートである。
このような構成により得られる実施例の効果の一例として、第1条件に基づいて、送金依頼に基づく第2情報を端末が受信して表示することができる。また、第1条件の成否を端末側で判定せずに済むため、端末の処理負荷を軽減することができる。
第4変形例(1)において、サーバ10の制御部11が判定する送金リマインド条件に、「送金マスターユーザの端末から送金リマインド送信要求情報を受信したこと」を含めるようにしてもよいし、しなくてもよい。
この場合の処理は、図2-12の処理と、図4-5の処理とを組み合わせることによって実現可能である。
第5実施例は、前述した送金リクエスト表示や送金リマインド表示を、チャットサービスによって利用可能なチャットルームに表示する実施例である。
第5実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
また、メッセージンサービス(メッセージングアプリケーション)を適用する場合のチャットルームとして、以下ではトークルームを例示する。
以下の例では、メッセージングアプリケーションのユーザであるとともに支払いアプリケーションのユーザでもあるA.Aと、B.Bと、C.Cが、何れもグループXに属しており、友だち登録されているものとする。
この例では、A.Aが、B.BとC.Cに対して、メッセージにより送金を依頼しており、そのメッセージをB.BとC.Cは確認している(既読2)。
すなわち、A.Aは、送金依頼を行った第1ユーザの一例であり、B.Bと、C.Cが、送金リクエスト情報を受信した端末20のユーザの一例である。
A.Aが、トークルームの下部に表示されたアイコンのうち、右下の送金アイコンをタップすると、トークルーム上に送金項目選択領域SMRが表示される。
その下方には、他のユーザに送金するためのボタンBTM1と、他のユーザに送金リクエスト情報を送信するためのボタンBTM2と、送金依頼履歴を表示するためのボタンBTM3が表示されている。
この状態で領域RRがタップされることで、領域R1内に表示されていた情報に基づく送金リマインド情報が、送金リクエスト情報の送信対象となっていたユーザ(B.B)の端末20に送信される。
ここで、仮に、第1ユーザ(A.A)が、送金ボタンBT11aをタップしたとしても、このメッセージMS11に関して送金先となっているのは自分(A.A)であるため、送金画面には移行せず、送金処理は実行されない。
従って、送金ボタンBT11aは、操作に応じて送金処理が実行されないことから、選択不能態様で表示されている。
従って、ボタンBT11bは、操作に応じてメッセージが送信されないことから、選択不能態様で表示されている。
端末20のユーザ(B.B)が、送金ボタンBT21aをタップすると、前述した送金画面に移行し、送金処理を実行可能となる。
従って、送金ボタンBT21aは、操作に応じて送金処理が実行されることから、前述した送金ボタンBT11aおよび後述する送金ボタン31aとは異なる選択可能態様で表示されている。
従って、ボタンBT21bは、操作に応じてメッセージが送信されることから、前述したボタンBT11bおよび後述するボタン31bとは異なる選択可能態様で表示されている。
送金リマインドの対象となっているユーザ(B.B)が送金ボタンBT21aをタップしたことに基づいて、第1ユーザ(A.A)への送金処理が完了すると、図5-3に示すように、第1ユーザ(A.A)の端末20には、送金を完了したユーザ(B.B)のメッセージとしてメッセージMS12が表示される。
限定ではなく例として、メッセージMS13には、[Payment App]の文字とともに、送金リマインドの対象となったユーザのユーザ名と、そのユーザから送金依頼金額を受け取ったことを示すメッセージ(本例では、「送金受け取り」、「B.Bから送金を受け取りました。」)と、送金依頼金額(本例では3,000円)と、その送金依頼金額を自分(A.A)が受け取った立場であることを示す「受取」の文字のアイコンが含まれる。
限定ではなく例として、メッセージMS22の内容は、メッセージMS12の内容と同様である。
限定ではなく例として、メッセージMS32の内容は、メッセージMS12の内容と同様である。
図5-4~図5-5は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
これらのフローチャートは、図1-13~図1-14のフローチャートを、送金リクエスト情報、送金リマインド情報をトークルームに表示するように書き換えたフローチャートである。
これを受けて、端末20A、端末20B、端末20Cは、それぞれの制御部21によって、受信した送金リクエストメッセージを、グループトークルームにそれぞれ表示させる(A520、B520、C520)。
これを受けて、端末20A、端末20B、端末20Cは、それぞれの制御部21によって、受信した送金メッセージまたは受金メッセージを、グループトークルームにそれぞれ表示させる(A550、B550、C550)。
これを受けて、端末20A、端末20B、端末20Cは、それぞれの制御部21によって、受信した送金リマインドメッセージを、グループトークルームにそれぞれ表示させる(A580、B580、C580)。
本実施例は、送金リクエスト先ユーザの端末20において、送金リクエストメッセージの表示(限定ではなく、第1情報に基づく第1表示の一例)と、送金リマインドメッセージの表示(限定ではなく、送金依頼に基づく、第1表示とは異なる第2表示の一例)とは、端末20にインストールされたメッセージングアプリケーション(限定ではなく、アプリケーションの一例)によって、表示部24に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、端末にインストールされたアプリケーションによって、第1情報と第2情報とを、端末のユーザに認識させることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザと、第1ユーザとを少なくとも含むチャットルームへの表示によって、第1情報と第2情報とを、端末のユーザに効果的に認識させることができる。
第5実施例では、グループに含まれる全てのグループユーザの端末20に表示されるグループトークルームに、送金リクエストメッセージや送金リマインドメッセージが表示されることとしたが、これに限定されない。
一部のグループユーザの端末20に表示されるグループトークルームに、送金リクエストメッセージや送金リマインドメッセージが表示されないようにすることも可能である。
図5-6に示す例は、図5-2の変形例である。
第1ユーザ(A.A)の端末20では、トークルーム上で自分(A.A)のメッセージMS11を見ることができる。
また、送金リマインドの対象となったユーザ(B.B)の端末20では、トークルーム上で、第1ユーザ(A.A)のメッセージMS21を見ることができる。
送金リマインドの対象となったユーザ(B.B)の端末20では、トークルーム上で、第1ユーザ(A.A)のメッセージMS21を見ることができる。
また、第1ユーザ(A.A)でもなく、送金リマインドの対象にもならなかった他のユーザ(C.C)の端末20でも、トークルーム上で、第1ユーザ(A.A)のメッセージMS31を見ることができない。
図5-8は、本変形例における送金リクエストメッセージや送金リマインドメッセージの表示方法を説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、設定Noと、表示フラグとが関連付けて定められている。
設定No「1」には、送金マスターユーザと、送金リクエスト先ユーザと、他のグループユーザとについて、全て表示フラグを「ON」とすることが定められている。
これは、送金依頼の当事者であるか否かに関係なく、同じグループに含まれる全てのユーザの端末20に表示されるグループトークルームに、送金リクエストメッセージ・送金リマインドメッセージを表示させることを意味する。
これは、送金依頼の当事者である送金マスターユーザおよび送金リクエスト先ユーザの端末20に表示されるグループトークルームには送金リクエストメッセージ・送金リマインドメッセージを表示させるが、当事者ではない他のグループユーザの端末20に表示されるグループトークルームには送金リクエストメッセージ・送金リマインドメッセージを表示させないことを意味する。
これは、送金依頼の当事者である送金マスターユーザおよび送金リクエスト先ユーザの端末20には送金リクエストメッセージ・送金リマインドメッセージを表示させるが、当事者ではない他のグループユーザの端末20には、送金リクエストメッセージ・送金リマインドメッセージを表示させないことを意味する。
図5-9~図5-10は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
このフローチャートは、図5-4~図5-5のフローチャートを、上記のテーブルに従って処理するように書き換えたフローチャートである。
ここでは、送金マスターユーザの端末20に対する入力に基づいて、サーバ10が表示フラグを設定する場合を例示する。
これを受けて、表示フラグが「ON」に設定された端末20は、受信した送金リクエストメッセージを、表示部24のグループトークルームに表示させる。
これを受けて、表示フラグが「ON」に設定された端末20は、受信した送金メッセージ/受金メッセージを、表示部24のグループトークルームに表示させる。
これを受けて、表示フラグが「ON」に設定された端末20は、受信した送金リマインドメッセージを、表示部24のグループトークルームに表示させる。
これに代えて、送金リクエスト先ユーザの端末20に対する入力に基づいて、サーバ10が表示フラグを設定するようにしてもよいし、しなくてもよい。
これに代えて、送金リクエストメッセージと、送金リマインドメッセージとについて、個別に表示フラグを設定するようにしてもよいし、しなくてもよい。
この場合、あくまでも一例として、送金リクエストメッセージについては、設定No「1」の表示フラグの設定を適用し、送金リマインドメッセージについては、設定No「2」または設定No「3」の表示フラグの設定を適用するなどしてもよい。
このような構成により得られる変形例の効果の一例として、送金依頼に関係ないユーザ、つまり、当事者ではないユーザに、送金依頼に基づく第2情報が知られないようにすることができる。
第1ユーザは、送金依頼を行う側のユーザであり、少なくとも第1情報によって端末のユーザに送金依頼を行ったことを、自分で認識している。このため、送金依頼に基づく第2表示が、第1ユーザの端末に表示されるチャットルームに表示されないようにすることで、第1ユーザにとって必要のない情報が第1ユーザの端末に表示されることを防止することができる。
第5実施例でグループトークルームに表示させる送金リマインド情報に基づくメッセージが、第1ユーザのメッセージとしてではなく、支払いアプリケーションの公式アカウントのメッセージとして表示されるようにしてもよいし、しなくてもよい。
図5-2および図5-3の例では、第1ユーザ(A.A)から送金リマインドの対象となったユーザ(B.B)に対するメッセージMS11、MS21、MS31が、それぞれ第1ユーザ(A.A)のメッセージとして表示された。
すなわち、送金リマインド情報に基づくメッセージが、送金リマインド情報を送信するための操作を行った第1ユーザ(A.A)のメッセージとして表示された。
メッセージMS11a、MS21a、およびMS31aは、ボタンの表示態様を除いて同じ内容であり、何れも、支払いアプリケーションの公式アカウントのアイコン画像に関連付けられている。
メッセージMS11に含まれていた「受取」の文字のアイコンや、メッセージMS21に含まれていた「支払い」の文字のアイコンは含まれていない。
限定ではなく例として、メッセージMS11aには、選択不能態様の送金ボタンBT11aおよびボタンBT11bが含まれる。また、メッセージMS21aには、選択可能態様の送金ボタンBT21aおよびボタンBT21bが含まれる。また、メッセージMS31aには、選択不能態様の送金ボタンBT31aおよびボタンBT31bが含まれる。
また、他のユーザ(C.C)の端末20には、送金を完了したユーザ(B.B)のメッセージとしてメッセージMS32が表示され、第1ユーザ(A.A)のメッセージとしてメッセージMS33が表示される。
第1ユーザ(A.A)の端末20では、トークルーム上で公式アカウントのメッセージMS11aを見ることができる。
また、送金リマインドの対象となったユーザ(B.B)の端末20では、トークルーム上で、公式アカウントのメッセージMS21aを見ることができる。
送金リマインドの対象となったユーザ(B.B)の端末20では、トークルーム上で公式アカウントのメッセージMS21aを見ることができる。
また、第1ユーザ(A.A)でもなく、送金リマインドの対象にもならなかった他のユーザ(C.C)の端末20でも、トークルーム上で公式アカウントのメッセージMS31aを見ることができない。
第5実施例でグループトークルームに表示させる送金リクエストメッセージと、送金リマインドメッセージとの少なくともいずれか一方を、メッセージングアプリケーションのメンション機能に基づくメッセージとしてもよいし、しなくてもよい。
限定ではなく例として、トークルームに送金リマインド情報に基づくメッセージ(限定ではなく送金リマインド表示の一例)が表示される場合、自動的にメッセージングアプリケーションにおけるメンション機能が働き、「@ユーザ名」という下線で強調される表記がなされる。
なお、メンション機能によってメッセージを受信するユーザの端末では、メッセージを受信したことを強調して示す通知が表示されるようにしてもよいし、そうしなくてもよい。
このユーザ名は、限定ではなく例として、送金リマインド表示(限定ではなく例として、メッセージMS11b、MS21b、MS31b)に含まれるユーザ名である。
メッセージMS11b、MS21b、およびMS31bの先頭には、それぞれ、メンション機能に基づいて、そのメッセージがB.Bに対してのメッセージであることを示す「@B.B」という表記がなされている。
このような構成により得られる変形例の効果の一例として、端末のユーザを示す情報を含む第2表示によって、その表示が自分を指定した表示であることを、端末のユーザに確実に認識させることができる。
送金リクエスト先ユーザの端末20の表示部24に表示されるグループトークルームに表示される送金リマインドメッセージの表示態様と、送金リクエスト先ユーザおよび送金マスターユーザを除く他のグループユーザの端末20の表示部24に表示されるグループトークルームに表示される送金リマインドメッセージの表示態様とを、異ならせて表示させるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第1表示態様と第2表示態様との表示態様の相違によって、端末のユーザに対しては自分が送金依頼の当事者であることを、第2ユーザに対しては自分が送金依頼の当事者ではないことを、それぞれ認識させることができる。
送金リクエスト先ユーザが支払いを行わなかった場合に、メッセージングアプリケーションの機能の一部を制限するようにしてもよいし、しなくてもよい。
メッセージMS14、MS24、およびMS34の先頭には、それぞれ、メンション機能に基づいて、そのメッセージがB.B(本例では、送金リマインドの対象となっているユーザ)に対してのメッセージであることを示す「@B.B」という表記がなされている。
送金が完了していないユーザの端末20に表示させるリマインド表示に、既に送金が完了しているユーザに関する情報を含めるようにしてもよいし、しなくてもよい。
限定ではなく例として、第1ユーザであるA.Aが、ボタンBTM3をタップすると、A.Aの過去の送金依頼のうち、複数のユーザ(B.BおよびC.C)を対象としたものであって、少なくとも1のユーザに関して支払い処理が完了していないものに関する履歴が、トークルーム上に表示される。
その下方には、送金依頼の対象となったユーザの数を示す情報(本例では「メンバー 2」)が表示され、さらに、送金を未だ行っていない一方のユーザ(B.B)に関する情報と、既に送金を行った他方のユーザ(C.C)に関する情報の両方が表示されている。
また、限定ではなく例として、第1ユーザ(A.A)が、他方のユーザ(C.C)に送金リクエスト情報を送信し、この送金依頼に対しての送金処理が完了していることに基づいて、他方のユーザ(C.C)のアイコン画像およびユーザ名に関連付けて、送金が完了していることを示す情報(本例では、「送金済」の文字)が表示されている。
第1ユーザ(A.A)が、領域R10のチェックボックスをチェックした状態とすることで、領域R10内に表示されている各情報が選択された状態となる。
この状態で領域RRがタップされることで、領域R10内に表示されていた情報に基づく送金リマインド情報が、送金を行っていないユーザ(B.B)の端末20に送信される。
メッセージMS11c、MS21c、MS31cの何れに関しても、共通のイベントに基づく送金依頼の対象となったユーザの数を示す情報(本例では「メンバー 2」)が表示され、さらに、送金を未だ行っていない一方のユーザ(B.B)に関する情報と、既に送金を行った他方のユーザ(C.C)に関する情報の両方が表示されている。
図5-19および図5-20に関しては、限定ではなく例として、送金リクエスト情報の送信対象となった複数のユーザ(B.B、C.C)に関して、それぞれ、送金リマインドの対象となった回数(限定ではなく例として、そのユーザを対象とした送金リマインド表示がそのユーザの端末20に表示された回数)が示される点で、図5-17及び図5-18とは異なる。
この送金リマインドの停止を実現するための手法としては、大きく分けて、
・サーバ10が送金リマインド情報の送信を停止する
・端末20が送金リマインド表示の表示を停止する
の2つの手法が考えられる。以下、それぞれの手法について説明する。
第6実施例は、サーバ10が、送金リクエスト先ユーザの端末20への送金リマインド情報の送信を停止する実施例である。
第6実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
「パターンA」を適用する場合、サーバ10は、送金済みとなった送金リクエストを削除せずに残し、送金リクエスト先ユーザの端末20への、その送金リクエストに対応する送金リマインド情報の送信を停止する。
「パターンB」を適用する場合、サーバ10は、送金済みとなった送金リクエストを削除する。送金リクエストそのものが削除されるため、結果的に、送金リマインド情報の送信が停止される。
図6-1~図6-2は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
このフローチャートは、限定ではなく例として、図1-13から図2-11に続くサーバリマインドの処理に基づくフローチャートである。
この場合は、サーバ10から端末20Bに対して送金リマインド情報が送信されるように制御される。
この場合は、サーバ10から端末20Bに対して送金リマインド情報が送信されないように制御される。
本実施例は、サーバ10が、送金マスターユーザ(限定ではなく、第1ユーザの一例)による送金リクエスト情報(限定ではなく、決済依頼に関する第1情報の一例)を通信I/F14によって送金マスターユーザの端末20から受信する。そして、サーバ10は、送金リクエストに基づく第2送金処理(限定ではなく、第1ユーザへの送金に関する送金処理の一例)の実行に基づいて、送金リクエストに基づく送金リマインド情報(限定ではなく、送金依頼に基づく第2情報の一例)を送金リクエスト先ユーザの端末20に送信する制御に関する送信制御を制御部11によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく、第1ユーザへの送金に関する送金処理の実行に基づいて、送金依頼に基づく第2情報を端末に送信する制御に関する送信制御を行うことで、第1ユーザへの送金を端末のユーザに適切に行わせることができる。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく金額を、第1情報と第2情報とによって端末のユーザに確実に知らせることができる。
このような構成により得られる実施例の効果の一例として、送金処理が実行されない場合は、第2情報が端末に送信されるようにする一方、送金処理が実行された場合は、第2情報が端末に送信されないようにすることができる。
このような構成により得られる実施例の効果の一例として、第1情報に基づく第1表示が端末に表示され、端末のユーザによる第1表示に対する入力に基づいて、送金処理が簡単に実行されるようにすることができる。また、この場合、上記の構成と相まって、第1表示に対する入力に基づいて送金処理が実行されたことに基づいて、サーバが、第2情報を端末に送信しないように制御することができる。
このような構成により得られる実施例の効果の一例として、第3情報に基づく第3表示に対する入力に基づいて、送金処理を実行することができる。また、この場合、上記の構成と相まって、第3表示に対する入力に基づいて送金処理が実行された場合は、第2情報が端末に送信されないようにすることができる。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく第2情報がサーバから端末に送信された場合であっても、この第2情報とは別に、送金依頼に基づく第4情報がサーバから端末に送信されるようにすることができる。また、送金依頼に基づく第4情報がサーバから端末に送信された場合であっても、端末のユーザによる、端末に表示された第2情報に基づく第2表示に対する入力に基づいて、第1ユーザへの送金を端末のユーザに行わせることができる。
このような構成により得られる実施例の効果の一例として、サーバが、送金処理によって、端末のユーザから第1ユーザへの送金を実現することができる。
第6実施例において、パターンB(送金リクエストを削除する)を適用するようにすることもできる。
この場合、サーバ10は、限定ではなく例として、送金決済処理によって送金を行った場合に、第2送金リクエスト管理データ157Bのうち、送金を行った送金リクエスト管理IDに対応するレコードを削除する。その結果、送金リクエストのみならず、この送金リクエストに対応する送金リマインドも削除される。
パターンA(送金リクエストを削除せずに残す)を適用する場合、サーバ10で記憶・管理している送金リクエストは削除されない。このため、端末20からサーバ10に対して送金リクエストの閲覧要求がなされた場合、送金済みの送金リクエストに関する情報も、端末20で閲覧可能となる。
そこで、送金済みの送金リクエストに関する情報については、未送金の送金リクエストに関する情報とは異なる表示態様に変更するようにしてもよいし、しなくてもよい。
この場合、サーバ10の制御部11は、第2送金リクエスト管理データ157Bにおいて、対応する送金リクエスト管理IDに関連付けられて設定されている送金済みフラグに基づいて、端末20Bに送信する送金リクエスト一覧ページを設定して送信する。
この例では、領域R21に示される送金リクエスト情報と、この送金リクエストに対応して領域R22に示される送金リマインド情報とのそれぞれについて、送金済みであることを示す情報として、「DONE」の文字を含む完了マークMK1が表示されている。
限定ではなく例として、図6-3のレイアウトの送金リクエスト一覧画面において、図6-4に示すように、領域R21と領域R22とをグレーアウト表示することによって、未送金の状態の送金リクエストや送金リマインドと区別するようにしてもよい。
また、これらの領域をグレーアウト表示するなどしてもよい。
前述したように、端末20が送金リマインド表示の表示を停止することによって、送金リマインドを停止することも可能である。
ここでは、端末リマインドの手法を適用する場合を例示する。
このフローチャートは、限定ではなく例として、図1-13~図1-14の端末リマインドの処理に基づくフローチャートである。
この場合は、端末20Bの制御部21によって、送金リマインド表示を表示部24に表示する制御が実行される。
この場合は、端末20Bの制御部21によって、送金リマインド表示を表示部24に表示しない制御が実行される。
この場合、上記の処理において、端末20の表示部24に表示されたいずれかの送金リマインド表示に対する入力に基づいて送金が実行されると、それ以降、送金リマインド情報は、端末20Bの表示部24に表示されないように制御されることになる。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく、第1ユーザへの送金に関する送金処理の実行に基づいて、送金依頼に基づく第2表示を端末の表示部に表示する制御に関する表示制御を実行することで、第1ユーザへの送金を端末のユーザに適切に行わせることができる。
このような構成により得られる実施例の効果の一例として、送金処理が実行されたか否かに基づいて、第2情報を表示させるか否かを適切に切り替えることができる。
このような構成により得られる変形例の効果の一例として、第1情報に基づく第1表示が端末に表示され、端末のユーザによる第1表示に対する入力に基づいて、送金処理が簡単に実行されるようにすることができる。また、この場合、上記の構成と相まって、第1表示に対する入力に基づいて送金処理が実行されたことに基づいて、端末が、第2表示を表示部に表示しないように制御することができる。
第6変形例(3)に関連するが、サーバリマインドの手法について、端末20が送金リマインド表示の表示を停止することによって、送金リマインドを停止することも可能である。つまり、サーバ10は送金リマインド情報の送信を停止しないが、端末20が送金リマインド表示の表示を停止するようにすることも可能である。
B240においてサーバ10から送金リマインド情報を受信したと判定したならば(B240:YES)、端末20Bの制御部21は、対応する送金リクエストに基づく送金を実行済みであるか否かを判定する(B455)。
この場合は、送金リマインド情報がサーバ10から送信され、端末20Bの制御部21によって、その送金リマインド情報に基づく送金リマインド表示を表示部24に表示する制御が実行される。
この場合は、送金リマインド情報がサーバ10から送信されるが、端末20Bの制御部21によって、その送金リマインド情報に基づく送金リマインド表示を表示部24に表示しないように制御される。
さらに、送金リクエスト先ユーザの端末20からの要求に基づいて、サーバ10が送金リマインド情報の送信を停止するようにすることも可能である。
具体的には、限定ではなく例として、図6-8に示すように、送金リクエスト先ユーザであるユーザB.Bの端末20Bの表示部24に送金リクエスト一覧が表示された状態で、限定ではなく例として、ユーザA.Aからの送金リマインドをタップすると、図6-9に示すような送金画面が表示される。
サーバ10は、端末20Bから送金リマインド確認情報を受信したことに基づいて、送金リマインド情報の送信を停止する。
第7実施例は、第6実施例において、送金リクエスト表示や送金リマインド表示をチャットルームに表示する実施例である。
第7実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図7-1~図7-2は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
なお、ここでは簡明化のため、追加されたメッセージが端末20Bで表示されるトークルームに表示される場合に着目した処理として図示・説明し、端末20Aでのトークルームの表示については省略する。
そして、サーバ10の制御部11は、追加した送金リクエストメッセージを、通信I/F14によって端末20Bに送信する(S620)。
このリクエスト通知処理は、限定ではなく例として、前述したリマインド通知処理と同様の手法によって実現することができる。
そして、サーバ10の制御部11は、追加した送金リマインドメッセージを、通信I/F14によって端末20Bに送信する(S680)。
このリマインド通知処理は、限定ではなく例として、前述した手法を適用することができる。
本実施例は、端末20における送金リクエスト表示(限定ではなく、第1情報に基づく第1表示の一例)は、送金リクエスト先ユーザ(限定ではなく、端末のユーザの一例)と送金マスターユーザ(限定ではなく、第1ユーザの一例)とを少なくとも含むトークルーム(限定ではなく、チャットルームの一例)に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、チャットルームへの表示によって、少なくとも端末のユーザと第1ユーザとに、第1情報を簡易かつ適切に知らせることができる。
第6変形例(1)と同様に、前述したパターンAを適用する場合に、送金済みの送金リクエストに関する情報については、未送金の送金リクエストに関する情報とは異なる表示態様に変更するようにしてもよいし、しなくてもよい。
限定ではなく例として、サーバ10で保存されるメッセージは、メッセージを端末20に送信してから一定時間(限定ではなく例として、数週間)が経過すると自動的に削除されるが、端末20で保存されるメッセージは、ユーザが削除しない限り、そのまま残るようなものである。
そこで、本変形例では、以下の手法によって、送金リクエストに関連する情報の表示態様を変更する。
このテーブルには、限定ではなく例として、送金済みフラグと、情報種別と、メッセージとが関連付けて定められている。
(1)送金済みフラグ「OFF」
情報種別「リクエスト」には、メッセージとして「第1種送金リクエストメッセージ(未送金)」が定められている。これは、送金済みフラグが「OFF」である場合、つまり、未送金の状態である場合は、トークルームに表示する送金リクエストメッセージを、第1種送金リクエストメッセージとすることを示している。
情報種別「リクエスト」には、メッセージとして「第2種送金リクエストメッセージ(送金済み)」が定められている。これは、送金済みフラグが「ON」である場合、つまり、送金済みの状態である場合は、トークルームに表示する送金リクエストメッセージを、第2種送金リクエストメッセージとすることを示している。
具体的には、送金リクエストメッセージとして、第1種送金リクエストメッセージをトークルームに表示させる。
一方、サーバ10から送金情報を受信済みの状態である場合は、対応する送金リクエストメッセージ・送金リマインドメッセージとして、第2種送金リクエストメッセージ・第2種送金リマインドメッセージを表示する。
第8実施例は、送金リクエストや送金リマインドを経由せずに送金が実行された場合に関する実施例である。
このようなケースでは、サーバ10は、いずれの送金リクエスト管理IDについて送金リマインドを停止すべきかを判定(特定)することができない。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
第3送金リクエスト管理データ157Cには、第2送金リクエスト管理データ157Bにおける、日時と、送金リクエスト管理IDと、送金マスターIDと、送金リクエスト先IDと、送金リクエスト金額と、送金済みフラグと、情報種別とに加えて、限定ではなく例として、リマインド停止フラグが関連付けて記憶される。
このテーブルには、限定ではなく例として、設定Noと、対象端末と、判定用情報と、判定結果とが関連付けて定められている。
設定No「S1」には、対象端末として「送金リクエスト先ユーザの端末」が、判定用情報として「選択された送金マスターユーザ」が、判定結果として「選択された送金マスターユーザからの送金リマインド」がそれぞれ定められている。
これは、送金リクエスト先ユーザの端末20の表示部24に表示される画面(限定ではなく例として、送金用画面)において、限定ではなく例として、送金リクエストを受けているユーザ(送金マスターユーザ)の一覧を表示させるなどして、いずれかの送金マスターユーザを選択させる。そして、送金マスターユーザが選択されたことに基づいて、選択された送金マスターユーザからの送金リマインドが停止されることを示している。
具体的には、サーバ10は、限定ではなく例として、第3送金リクエスト管理データ157Cにおいて、選択された送金マスターユーザから、その送金リクエスト先ユーザへの全ての送金リクエストの送金リクエスト管理IDに対応するリマインド停止フラグを「ON」に設定する。
ただし、この設定では、送金リクエストを一意に特定することはできないため、送金済みフラグは「OFF」のままとされるようにすることができる。
これは、限定ではなく例として、送金リクエスト先ユーザの端末20の表示部24に表示される画面(限定ではなく例として、送金用画面)において、送金リクエスト先ユーザによって送金先のユーザ(以下、「送金先ユーザ」と称する。)が選択され、その送金先ユーザからの送金リマインドを停止させることが選択されたことに基づいて、選択された送金先ユーザからの送金リマインドが停止されることを示している。
具体的には、サーバ10は、限定ではなく例として、第3送金リクエスト管理データ157Cにおいて、選択された送金先ユーザから、その送金リクエスト先ユーザへの全ての送金リクエストの送金リクエスト管理IDに対応するリマインド停止フラグを「ON」に設定する。
ただし、この設定でも、送金リクエストを一意に特定することはできないため、送金済みフラグは「OFF」のままとされるようにすることができる。
これは、限定ではなく例として、送金リクエスト先ユーザの端末20の表示部24に表示される画面(限定ではなく例として、送金用画面)において、送金リクエスト先ユーザによって送金先ユーザが選択され、その送金先ユーザに対する送金金額が入力されたことに基づいて、選択された送金先ユーザからの送金リマインドであって、入力された送金金額と送金リクエスト金額が同じ送金リマインドが停止されることを示している。
そして、サーバ10は、送金リクエスト先ユーザからの送金を、特定した送金リクエスト管理IDの送金リクエストに基づく送金とみなして送金を実行する。そして、サーバ10は、その送金リクエスト管理IDの送金リクエストを対象として、送金リマインドを停止する。具体的には、サーバ10は、限定ではなく例として、第3送金リクエスト管理データ157Cにおいて、特定した送金リクエスト管理IDに対応する送金済みフラグを「ON」に設定するとともに、リマインド停止フラグも「ON」に設定する。
これは、限定ではなく例として、送金リクエスト先ユーザの端末20の表示部24に表示される画面(限定ではなく例として、グループリクエスト一覧画面)において、送金リクエスト先ユーザによって、自分に対する送金リクエストに加えて、他のグループユーザへの送金リクエストが一緒に選択されると、それらの送金リクエストに対応する送金リマインドが停止されることを示している。
具体的には、サーバ10は、限定ではなく例として、第3送金リクエスト管理データ157Cにおいて、これらの送金リクエストの送金リクエスト管理IDに対応する送金済みフラグを「ON」に設定するとともに、リマインド停止フラグも「ON」に設定する。
以下、一例として、上記の設定No「S2」の設定と設定No「S4」の設定とをそれぞれ適用した場合の表示画面例について説明する。
図8-3は、端末20Bの表示部24に表示される支払いアプリケーションのメインメニュー画面であり、図2-2に対応する画面である。そして、ここでは「送金」のアイコンIC3がタップされた状態が示されている。この場合、限定ではなく例として、図8-4に示す送金先ユーザ選択画面が表示される。
この画面では、送金予定金額として「3,000円」が入力されており、この状態で画面下部の送金領域RM2がタップされることで、図8-6に示すように、送金リマインド停止情報として、限定ではなく例として、ユーザA.Aのアイコン画像およびユーザ名と、「このユーザからのリマインドを停止しますか?」というテキストと、OKボタンBT10と、キャンセルボタンとを含む送金リマインド停止情報RS1が、画面中央部にポップアップ表示される。
このメインメニュー画面は、図2-2に対応しており、ここでは「送金」のアイコンIC3がタップされた状態が示されている。この場合、限定ではなく例として、図8-4に示す送金先ユーザ選択画面が表示される。
グループトークルームの下部に表示されたアイコンのうち、右下の送金アイコンIC4がタップされると、前述したように、トークルーム上に送金項目選択領域SMRが表示される。
端末20Aに表示されるグループトークルームには、ユーザC.CからユーザA.Aに対して2名分の送金があったことを示すメッセージMS71が表示され、その下に、その金額をユーザA.Aが受け取ったことを示すメッセージM72が表示されている。
図8-10は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
ここでは、端末20Bの処理を左側に、サーバ10の処理を右側にそれぞれ示し、端末20Aの処理については図示を省略する。
これらの処理は、限定ではなく例として、図6-1~図6-2の処理のサブルーチンの処理として、端末20Bの制御部21およびサーバ10の制御部11によってそれぞれ実行される処理である。
具体的には、限定ではなく例として、図8-2のテーブルで説明した手法に従って、送金リマインドを停止する送金リクエスト管理IDを判定(特定)する。
一方、処理を終了すると判定したならば(B890:YES)、端末20Bの制御部21は、処理を終了する。
一方、処理を終了すると判定したならば(S890:YES)、サーバ10の制御部11は、処理を終了する。
本実施例は、サーバ10によって実行される第2送金処理(限定ではなく、送金処理の一例)は、送金リクエスト先ユーザの端末20の表示部24に表示された送金マスターユーザ(限定ではなく、第1ユーザの一例)の選択に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、端末の表示部に表示された第1ユーザが選択されることに基づいて、その第1ユーザからの送金依頼に基づく送金とみなして、送金処理が実行されるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザにより、第1ユーザの選択と、第2情報の送信を行わないことを示す情報の選択とに基づいて、送金処理が適切に実行されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1ユーザの選択と、送金依頼に基づく金額と、端末のユーザによって入力された金額とに基づいて、送金処理が適切に実行されるようにすることができる。
このような構成により得られる実施例の効果の一例として、送金依頼された端末のユーザとは異なる第2ユーザによる第1ユーザへの送金に基づいて、送金処理が適切に実行されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第2ユーザによる、第2ユーザの端末に表示された第1情報に基づく第1表示に対する入力に基づいて、送金処理が簡易かつ適切に実行されるようにすることができる。
このような構成により得られる実施例の効果の一例として、端末のユーザによる、表示部に表示された第1ユーザ情報に対する入力という、ユーザにとって分かり易い表示に対する入力に基づいて、送金処理が実行されるようにすることができる。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、送金依頼に基づく金額と、ユーザに送金する金額とが同じ金額であるような場合に、そのユーザからの送金依頼に基づく送金とみなして、送金が行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく第1ユーザへの送金であることを示す入力に基づいて、送金処理が簡易かつ適切に実行されるようにすることができる。
第8実施例では、サーバ10が、送金リマインド情報の送信を停止するか否かを、送金リクエスト管理データ157のリマインド停止フラグによって管理することとしたが、これに限定されない。
限定ではなく例として、送金リクエスト管理データとは異なるデータによって、送金リマインド情報の送信を停止するか否かを管理するようにしてもよいし、しなくてもよい。
リマインド停止管理データには、限定ではなく例として、縦に送金リマインド情報を受信する側(受信側)のユーザのアプリケーションIDが、横に送金リマインド情報を送信する側(送信側)のユーザのアプリケーションIDがそれぞれ記憶され、送信側から受信側への送金リマインド情報の送信の有無(送信有/送信無)が、マトリックス形式で記憶されている。
限定ではなく例として、送金マスターユーザをユーザA.Aとし、送金リクエスト先ユーザをユーザB.Bとし、ユーザA.AからユーザB.Bへの送金リマインドを停止すると判定された場合は、送信側「U001(ユーザA.A)」と、受信側「U002(ユーザB.B)」とが交差する欄が「送信無」に更新される。
第9実施例は、上記の実施例とは異なる例外的なケースによって、送金リマインドを停止する実施例である。
第9実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
(A)送金リクエストに基づく送金は未だ行われていないが、送金リマインドを停止することが希望されるケース
(B)支払いアプリケーションを利用せずに送金リクエストに対応する金額が支払われるなどして、送金リマインドを停止することが希望されるケース
また、送金マスターユーザが送金リクエストを放棄するようなケースも考えられる。
このテーブルには、限定ではなく例として、設定Noと、対象端末と、判定用情報と、判定結果と、送金マスターユーザの承認要否とが関連付けて定められている。
設定No「T1」には、対象端末として「送金マスターユーザの端末」が、判定用情報として「選択された送金リクエスト先ユーザ&送金リマインドの停止選択有無」が、判定結果として「選択された送金リクエスト先ユーザへの送金リマインド」が、送金マスターユーザの承認要否として「否」がそれぞれ定められている。
これは、限定ではなく例として、送金マスターユーザの端末20の表示部24に表示される画面(限定ではなく例として、送金リクエスト先ユーザ一覧画面)において、送金マスターユーザによって送金リクエスト先ユーザが選択され、送金リマインドを停止させることが選択されたことに基づいて、選択された送金リクエスト先ユーザへの送金リマインドが停止されることを示している。
また、送金マスターユーザの希望で送金リマインドを停止するため、送金マスターユーザの承認要否には「否」が定められている。
具体的には、サーバ10は、限定ではなく例として、第3送金リクエスト管理データ157Cにおいて、その送金マスターユーザから、選択された送金リクエスト先ユーザへの全ての送金リクエストの送金リクエスト管理IDに対応するリマインド停止フラグを「ON」に設定する。
これは、限定ではなく例として、送金マスターユーザの端末20の表示部24に表示される画面(限定ではなく例として、送金リクエスト一覧画面)において、送金マスターユーザによって送金リクエストが選択され、送金リマインドを停止させることが選択されたことに基づいて、選択された送金リクエストに対応する送金リマインドが停止されることを示している。
また、送金マスターユーザの希望で送金リマインドを停止するため、送金マスターユーザの承認要否には「否」が定められている。
そこで、送金済みである場合は、送金マスターユーザの端末20からサーバ10に対して送金済み情報を送信することによって、サーバ10によって送金済みフラグが「ON」に設定されるようにしてもよい。
これは、限定ではなく例として、送金リクエスト先ユーザの端末20の表示部24に表示される画面(限定ではなく例として、送金マスターユーザ一覧画面)において、送金リクエスト先ユーザによって送金マスターユーザが選択され、送金リマインドを停止させることが選択されたことに基づいて、選択された送金マスターユーザからの送金リマインドが停止されることを示している。
また、送金リクエスト先ユーザの希望で送金リマインドを停止するため、送金マスターユーザの承認要否には「要」が定められている。
送金マスターユーザの端末20から承認することを示す情報(以下、「承認情報」と称する。)を受信すると、サーバ10は、その送金マスターユーザから、送金リクエスト先ユーザへの送金リマインドを停止する。具体的には、第3送金リクエスト管理データ157Cにおいて、受信したアプリケーションIDによって識別される送金マスターユーザから、その送金リクエスト先ユーザへの全ての送金リクエストの送金リクエスト管理IDに対応するリマインド停止フラグを「ON」に設定する。
一方、上記の送金マスターユーザの端末20から承認情報を受信しなかった場合、サーバ10は、送金リマインドを停止しない。つまり、リマインド停止フラグを「OFF」のままとする。
これは、限定ではなく例として、送金リクエスト先ユーザの端末20の表示部24に表示される画面(限定ではなく例として、送金リクエスト一覧画面)において、送金リクエスト先ユーザによって送金リクエストが選択され、送金リマインドを停止させることが選択されたことに基づいて、選択された送金リクエストに対応する送金リマインドが停止されることを示している。
また、送金リクエスト先ユーザの希望で送金リマインドを停止するため、送金マスターユーザの承認要否には「要」が定められている。
そこで、送金済みである場合は、送金リクエスト先ユーザの端末20からサーバ10に対して送金済み情報を送信することによって、サーバ10によって送金済みフラグが「ON」に設定されるようにしてもよい。
これは、限定ではなく例として、送金の当事者以外のユーザ(限定ではなく例として、同じグループに含まれる送金マスターユーザおよび送金リクエスト先ユーザ以外のユーザ)の端末20の表示部24に表示される画面(限定ではなく例として、グループリクエスト一覧画面)において、そのユーザによって、当事者の送金リクエストが選択され、送金リマインドを停止させることが選択されたことに基づいて、選択された当事者の送金リクエストに対応する送金リマインドが停止されることを示している。
当事者以外のユーザの希望で送金リマインドを停止するため、送金マスターユーザの承認要否には「要」が定められている。
逆に、1回目の承認確認処理を実行してから設定期間が経過しても送金マスターユーザの端末20から承認情報を受信しない場合、サーバ10は、送金マスターユーザによって否認されたとみなして、送金リマインドを停止しないようにすることもできる。
一例として、上記の設定No「T2」の設定と、設定No「T4」の設定とをそれぞれ適用した場合の表示画面例について説明する。
この例では、送金マスターユーザをユーザA.Aとし、送金リクエスト先ユーザをユーザB.Bとして、ユーザA.Aが、ユーザB.Bに対して送った送金リクエストに対応する送金リマインドを停止する場合を説明する。
リマインド停止アイコンIC10は、限定ではなく例として、デフォルトの状態(送金リマインドを停止しない状態)ではスピーカの画像部分が白抜きされた黒色で表示されている。
そして、第1リマインド停止確認情報に含まれるOKボタンBT10がタップされると、送金リクエスト選択情報と、第1送金リマインド停止要求情報とが端末20Aからサーバ10に対して送信されて、選択された送金リクエストに対応する送金リマインドが停止される。
また、送金リマインドが停止されたことに基づき、限定ではなく例として、図9-4に示すように、上記の送金リクエストに対応する送金リマインドの表示領域が退色して表示されている。
この場合、サーバ10は、リマインド停止フラグを「ON」に設定するばかりでなく、送金済みフラグも「OFF」に設定する。
これにより、限定ではなく例として、図9-5に示すように、端末20Aの表示部24に表示される送金リクエスト一覧画面では、送金リクエストおよびそれに対応する送金リマインドの各々について、「DONE」の文字を含む完了マークMK1が表示される。
この例では、送金マスターユーザをユーザA.Aとし、送金リクエスト先ユーザをユーザB.Bとして、ユーザB.Bが、ユーザA.Aから受け取った送金リクエストに対応する送金リマインドを停止するように依頼する場合を説明する。
送金リクエストの表示領域において、ユーザA.Aのアイコン画像およびユーザ名の横には、前述したリマインド停止アイコンIC10が表示されている。
そして、第2リマインド停止確認情報に含まれるOKボタンBT10がタップされると、送金リクエスト選択情報と、第2送金リマインド停止要求情報とが端末20Bからサーバ10に対して送信される。この場合、サーバ10は、ユーザA.Aの端末20Aに対して、
送金リマインドの停止を承認するか否かを確認するための情報を送信する。
端末20Aの表示部24には、送金リクエスト一覧画面の中央部に、サーバ10から受信した送金リマインドの停止を承認するか否かを確認するための停止承認確認情報が表示されている。そして、承認確認情報に含まれるOKボタンBT10がタップされると、端末20Aからサーバ10に対して、承認情報が送信される。そして、サーバ10において、この送金リクエストに対応する送金リマインドが停止される。
その結果、端末20Bの表示部24には、限定ではなく例として、図9-9に示すような送金リクエスト一覧画面が表示される。
本実施例は、サーバ10による送金リマインド情報(限定ではなく、第2情報の一例)の送信制御は、送金マスターユーザ(限定ではなく、第1ユーザの一例)の端末20による入力(限定ではなく、第1入力の一例)に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼元の第1ユーザの意向に応じて、送金依頼先のユーザの端末への第2情報の送信制御を行うことができる。
このような構成により得られる実施例の効果の一例として、送金依頼元の第1ユーザの意向に応じて、送金依頼先のユーザの端末に対して第2情報を送信しないように制御することができる。
このような構成により得られる実施例の効果の一例として、送金依頼先のユーザの意向に応じて、この送金依頼先のユーザの端末への第2情報の送信制御を行うことができる。
このような構成により得られる実施例の効果の一例として、送金依頼先のユーザの意向に応じて、この送金依頼先のユーザの端末に対して第2情報を送信しないように制御することができる。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、第2入力があった場合であっても、送金依頼元の第1ユーザによる第2入力に対する承認がなければ、送金依頼先のユーザの端末に対して第2情報が送信されるようにすることができる。また、これとは逆に、限定ではなく例として、第2入力があった場合に、送金依頼元の第1ユーザによる第2入力に対する承認があれば、送金依頼先のユーザの端末に対して第2情報が送信されないようにすることができる。
上記の実施例では、本発明における送金依頼に関する第1情報を「送金リクエスト情報」とし、送金依頼に基づく第2情報を「送金リマインド情報」としたが、これらに限定されない。
(1)第1の組合せ
・第1情報:送金リクエスト情報
・第2情報:送金リマインド情報
この組合せは、上記の実施例で説明した組合せである。
・第1情報:送金リクエスト情報
・第2情報:送金免除情報
送金免除情報は、限定ではなく例として、送金マスターユーザが送金リクエスト先ユーザに対して送金を免除することを通知するための情報(送金を行う必要がないことを通知するための情報)である。
この組合せは、送金マスターユーザが、送金リクエスト先ユーザに対して一旦は送金リクエストを行ったものの、何らかの事情により、送金を行う必要がないことを送金リクエスト先ユーザに知らせたいような場合に適用可能である。
・第1情報:送金免除情報
・第2情報:送金免除リマインド情報
送金免除リマインド情報は、限定ではなく例として、送金マスターユーザが送金リクエスト先ユーザに対して送金を免除することを再確認させるための情報(送金を行う必要がないことを念押しするための情報)である。
この組合せは、送金マスターユーザが、送金リクエスト先ユーザに対して送金を免除することを通知した後、そのことを念押ししたいような場合に適用可能である。
・第1情報:送金免除情報
・第2情報:送金リクエスト情報
この組合せは、送金マスターユーザが、送金リクエスト先ユーザに対して一旦は送金を免除することを通知したものの、何らかの事情により、送金を行ってもらう必要が生じ、送金を依頼する場合に適用可能である。
10 サーバ
20 端末
30 ネットワーク
Claims (1)
- 端末によって実行されるプログラムであって、
第1ユーザによる送金依頼に関する第1情報を前記端末の通信部によって受信することと、
前記第1情報に基づく第1表示を前記端末の表示部に表示することと、
前記送金依頼に基づく、前記第1表示とは異なる第2表示を前記表示部に表示することと、
前記端末のユーザによる、前記表示部に表示された前記第2表示に対する入力に基づいて、前記送金依頼に基づく、前記端末のユーザから前記第1ユーザへの送金に関する送金処理を前記端末の制御部によって実行することとが前記端末によって実行される。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021189023A JP2022010422A (ja) | 2020-06-17 | 2021-11-19 | プログラム、情報処理方法、端末 |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020104382A JP2022001970A (ja) | 2020-06-17 | 2020-06-17 | プログラム、情報処理方法、端末 |
JP2021189023A JP2022010422A (ja) | 2020-06-17 | 2021-11-19 | プログラム、情報処理方法、端末 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2020104382A Division JP2022001970A (ja) | 2020-06-17 | 2020-06-17 | プログラム、情報処理方法、端末 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2022010422A true JP2022010422A (ja) | 2022-01-14 |
JP2022010422A5 JP2022010422A5 (ja) | 2022-10-19 |
Family
ID=79244712
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2020104382A Ceased JP2022001970A (ja) | 2020-06-17 | 2020-06-17 | プログラム、情報処理方法、端末 |
JP2021189023A Pending JP2022010422A (ja) | 2020-06-17 | 2021-11-19 | プログラム、情報処理方法、端末 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2020104382A Ceased JP2022001970A (ja) | 2020-06-17 | 2020-06-17 | プログラム、情報処理方法、端末 |
Country Status (1)
Country | Link |
---|---|
JP (2) | JP2022001970A (ja) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2018113012A (ja) * | 2017-01-13 | 2018-07-19 | デルタ ピーディーエス カンパニー,リミテッド | 業務客体基盤の業務活動処理装置及び方法 |
JP2019185767A (ja) * | 2018-04-03 | 2019-10-24 | LINE Pay株式会社 | 送金機能が搭載されたメッセンジャーでメッセージ内容を認識して送金機能を提供する方法およびシステム |
JP2019204536A (ja) * | 2014-10-27 | 2019-11-28 | フェイスブック,インク. | メッセージベースのコンテキスト・プロンプトを使用した支払いの送信および受信の促進 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005267387A (ja) * | 2004-03-19 | 2005-09-29 | Nomura Research Institute Ltd | 電子決済システム |
JP6959113B6 (ja) * | 2017-11-20 | 2023-12-15 | ヤフー株式会社 | 情報処理装置、情報処理方法及び情報処理プログラム |
-
2020
- 2020-06-17 JP JP2020104382A patent/JP2022001970A/ja not_active Ceased
-
2021
- 2021-11-19 JP JP2021189023A patent/JP2022010422A/ja active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2019204536A (ja) * | 2014-10-27 | 2019-11-28 | フェイスブック,インク. | メッセージベースのコンテキスト・プロンプトを使用した支払いの送信および受信の促進 |
JP2018113012A (ja) * | 2017-01-13 | 2018-07-19 | デルタ ピーディーエス カンパニー,リミテッド | 業務客体基盤の業務活動処理装置及び方法 |
JP2019185767A (ja) * | 2018-04-03 | 2019-10-24 | LINE Pay株式会社 | 送金機能が搭載されたメッセンジャーでメッセージ内容を認識して送金機能を提供する方法およびシステム |
Also Published As
Publication number | Publication date |
---|---|
JP2022001970A (ja) | 2022-01-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2019204536A (ja) | メッセージベースのコンテキスト・プロンプトを使用した支払いの送信および受信の促進 | |
US20110313897A1 (en) | Pay group | |
US20220353640A1 (en) | System and Method for Appointment Scheduling | |
JP2015512541A (ja) | グループの支出の追跡および管理 | |
JP6977127B1 (ja) | プログラム、情報処理方法、端末、サーバ | |
JP7089551B2 (ja) | プログラム、情報処理方法、サーバ、端末 | |
KR20180013699A (ko) | 메신저 서비스를 기반으로 공동계좌를 관리하는 방법 및 시스템 | |
JP6977096B2 (ja) | プログラム、情報処理方法、端末 | |
JP6931245B2 (ja) | 役務マッチング支援サーバ及びプログラム | |
WO2021255949A1 (ja) | プログラム、情報処理方法、端末、サーバ | |
JP7064046B1 (ja) | アプリケーションプログラム、サービス提供システム、および端末装置 | |
JP2022010422A (ja) | プログラム、情報処理方法、端末 | |
KR102572825B1 (ko) | 정보처리 방법, 프로그램, 단말 | |
JP6977095B2 (ja) | プログラム、情報処理方法、端末 | |
JP2021089683A (ja) | プログラム、情報処理方法、端末 | |
JP7034226B1 (ja) | プログラム、情報処理方法、端末 | |
WO2022004339A1 (ja) | プログラム、情報処理方法、端末 | |
WO2022070453A1 (ja) | プログラム、情報処理方法、端末、サーバ | |
JP7357591B2 (ja) | プログラム、情報処理方法、端末 | |
JP7417482B2 (ja) | プログラム、情報処理方法、端末 | |
JP6914315B2 (ja) | プログラム、情報処理方法、端末 | |
JP7492942B2 (ja) | プログラム、情報処理方法、情報処理装置 | |
WO2021111660A1 (ja) | プログラム、情報処理方法、端末 | |
JP2022011963A (ja) | プログラム、情報処理方法、端末 | |
JP2022171914A (ja) | プログラム、情報処理方法、端末、サーバ |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20221010 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20221012 |
|
A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20221012 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20230124 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20230324 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20230718 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20231006 |
|
A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20231017 |
|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20231027 |
|
RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20231108 |
|
A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20231208 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20240621 |