(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023117871
(43)【公開日】2023-08-24
(54)【発明の名称】情報処理装置、情報処理方法及び情報処理プログラム
(51)【国際特許分類】
G06Q 20/36 20120101AFI20230817BHJP
【FI】
G06Q20/36
【審査請求】有
【請求項の数】7
【出願形態】OL
(21)【出願番号】P 2022020663
(22)【出願日】2022-02-14
(11)【特許番号】
(45)【特許公報発行日】2022-06-23
(71)【出願人】
【識別番号】519110124
【氏名又は名称】PayPay株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】馬場 一
(72)【発明者】
【氏名】松永 麻見
(72)【発明者】
【氏名】大塚 千壽子
【テーマコード(参考)】
5L055
【Fターム(参考)】
5L055AA68
(57)【要約】
【課題】コード決済の信頼性を高めること。
【解決手段】本願に係る情報処理装置は、受付部と、実行部とを有する。受付部は、利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と決済取引による店舗の売上額とを含む取引情報を受け付ける。実行部は、売上額が所定の条件を満たす場合、決済取引に対応する取引処理を実行する。
【選択図】
図4
【特許請求の範囲】
【請求項1】
利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と前記決済取引による店舗の売上額とを含む取引情報を受け付ける受付部と、
前記売上額が所定の条件を満たす場合、前記決済取引に対応する取引処理を実行する実行部と
を有することを特徴とする情報処理装置。
【請求項2】
前記実行部は、
前記売上額の合計が前記店舗ごとに個別に割り当てられる所定の上限金額に満たないことを条件として、前記取引処理を実行する
ことを特徴とする請求項1に記載の情報処理装置。
【請求項3】
前記所定の上限金額は、
前記店舗の過去の取引履歴に基づいて規定される
ことを特徴とする請求項2に記載の情報処理装置。
【請求項4】
前記受付部は、
前記店舗を識別するための店舗識別情報を含む前記取引情報を前記利用者端末から受け付け、
前記実行部は、
前記店舗識別情報に対応付けられている前記上限金額に基づいて、前記取引処理を実行する
ことを特徴とする請求項2または3に記載の情報処理装置。
【請求項5】
前記受付部は、
前記決済取引が行われた日時を示す日時情報を含む前記取引情報を前記利用者端末から受け付け、
前記実行部は、
前記店舗識別情報により識別される店舗において前記決済取引が有効な状態である期間内に前記決済取引が行われた日時が含まれていることを条件として、前記取引処理を実行する
ことを特徴とする請求項4に記載の情報処理装置。
【請求項6】
前記受付部は、
前記決済取引を行った利用者を識別するための利用者識別情報を含む前記取引情報を前記店舗端末から受け付け、
前記実行部は、
前記利用者識別情報により識別される前記利用者により前記決済取引の事実が承認されることを条件として、前記取引処理を実行する
ことを特徴とする請求項2または3に記載の情報処理装置。
【請求項7】
コンピュータが、
利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と前記決済取引による店舗の売上額とを含む取引情報を受け付ける受付工程と、
前記売上額が所定の条件を満たす場合、前記決済取引に対応する取引処理を実行する実行工程と
を実行することを特徴とする情報処理方法。
【請求項8】
コンピュータに、
利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と前記決済取引による店舗の売上額とを含む取引情報を受け付ける受付手順と、
前記売上額が所定の条件を満たす場合、前記決済取引に対応する取引処理を実行する実行手順と
を実行させることを特徴とする情報処理プログラム。
【請求項9】
コンピュータに、
コード情報から読み取った情報の中にオフラインでの決済取引である旨が含まれる場合、前記コード情報の読取に連動して決済取引が完了した旨を利用者に通知する手順を実行させる
ことを特徴とする情報処理プログラム。
【請求項10】
コンピュータに、
オフラインでの決済取引である旨を示す情報に関連付けて、前記決済取引が行われた店舗を示す店舗識別情報と、前記決済取引が行われた日時を示す日時情報と、前記決済取引による店舗の売上額を示す情報とを含む取引情報を記録する手順を実行させる
ことを特徴とする請求項9に記載の情報処理プログラム。
【請求項11】
コンピュータに、
利用者端末に表示されるコード情報を読み取った際、オフラインでの売上処理が有効な状態であることを条件として、前記コード情報の読取に連動してオフラインでの決済取引が完了した旨を利用者に通知する手順を実行させる
ことを特徴とする情報処理プログラム。
【請求項12】
コンピュータに、
オフラインでの決済取引である旨を示す情報に関連付けて、前記決済取引を行った利用者を識別するための利用者識別情報と、前記決済取引が行われた日時を示す日時情報と、前記決済取引による店舗の売上額を示す情報とを含む取引情報を記録する手順を実行させる
ことを特徴とする情報処理プログラム。
【請求項13】
コンピュータに、
近距離無線通信により、前記決済取引が完了した旨を示す情報を送信する手順を実行させる
ことを特徴とする請求項11または12に記載の情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、情報処理方法及び情報処理プログラムに関する。
【背景技術】
【0002】
従来、キャッシュレス決済の1つとして、バーコードなどの1次元コードやQRコード(登録商標)などの2次元コードを用いた決済(以下、「コード決済」と称する。)が広く利用されている(たとえば、特許文献1参照)。たとえば、店舗に設置された店舗端末が、ユーザ端末に表示される2次元コードからユーザIDを読み取り、読み取ったユーザIDに対して店舗IDおよび利用金額を付与し、これらの決済情報をサーバに送信することで決済処理が行われる。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、上記の従来技術では、コード決済の信頼性を高める上で改善の余地がある。たとえば、店舗ロケーションなどの環境的な要因により通信状況が悪い場合、上述の決済情報をサーバに送信することができず、結果として、コード決済の利用が難しくなる。このように、コード決済の信頼性が高いとは言い切れない状況が起こり得る。
【0005】
本願は、上記に鑑みてなされたものであって、コード決済の信頼性を高めることができる情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【0006】
本願に係る情報処理装置は、受付部と、実行部とを有する。受付部は、利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と決済取引による店舗の売上額とを含む取引情報を受け付ける。実行部は、売上額が所定の条件を満たす場合、決済取引に対応する取引処理を実行する。
【発明の効果】
【0007】
実施形態の一態様によれば、コード決済の信頼性を高めることができるという効果を奏する。
【図面の簡単な説明】
【0008】
【
図1】
図1は、実施形態に係る情報処理(その1)の一例を示す図である。
【
図2】
図2は、実施形態に係る情報処理(その2)の一例を示す図である。
【
図3】
図3は、実施形態に係る情報処理(その3)の一例を示す図である。
【
図4】
図4は、実施形態に係る決済サーバの構成例を示す図である。
【
図5】
図5は、実施形態に係る口座情報記憶部に記憶される情報の一例を示す図である。
【
図6】
図6は、実施形態に係る店舗情報記憶部に記憶される情報の一例を示す図である。
【
図7】
図7は、実施形態に係る利用者情報記憶部に記憶される情報の一例を示す図である。
【
図8】
図8は、実施形態に係る処理の流れ(その1)の一例を示すシーケンス図である。
【
図9】
図9は、実施形態に係る処理の流れ(その2)の一例を示すシーケンス図である。
【
図10】
図10は、実施形態に係る決済サーバによる処理手順の一例を示すフローチャートである。
【
図11】
図11は、実施形態に係る決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。
【発明を実施するための形態】
【0009】
以下に本願に係る情報処理装置、情報処理方法及び情報処理プログラムを実施するための形態(以下、「実施形態」と呼ぶ)について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法及び情報処理プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。
【0010】
〔1.実施形態〕
図1を用いて、実施形態の情報処理装置などにより実現される情報処理について説明する。
図1は、実施形態に係る情報処理(その1)の一例を示す図である。なお、
図1では、実施形態に係る情報処理装置の一例である決済サーバ100によって、実施形態に係る情報処理などが実現されるものとする。
【0011】
(1-1.システム構成)
図1に示すように、実施形態に係る情報処理システム1は、利用者端末10と、店舗端末20と、決済サーバ100とを含む。利用者端末10、店舗端末20、及び決済サーバ100は、ネットワークN(例えば、
図4参照)を介して有線または無線により相互に通信可能に接続される。ネットワークNは、例えば、インターネットなどのWAN(Wide Area Network)である。なお、
図1に示した情報処理システム1には、複数の利用者端末10や、複数の店舗端末20や、複数の決済サーバ100が含まれていてもよい。
【0012】
図1に示す決済サーバ100は、実施形態に係る情報処理を実行する情報処理装置であり、サーバ装置やクラウドシステムなどにより実現される。たとえば、決済サーバ100は、コード決済による電子マネーのやり取りを制御する所定の取引手段を提供するサービスに関する情報処理を実行する。
【0013】
具体的には、決済サーバ100は、店舗端末用のアプリケーションプログラム(以下、適宜「店舗アプリ」と称する。)を取引対象の提供者である店舗(事業者)に配布する。決済サーバ100は、店舗アプリ専用のインターフェイスを介して、店舗アプリからの取引要求を受け付けた場合は、その取引要求に従って、口座間における電子マネーの送金処理などを含む情報処理を実行する。なお、電子マネーとは、各種企業が独自に用いるポイントや通貨等であってもよく、日本円やドルなどの国家により提供される貨幣を電子的に取引可能としたものであってもよい。
【0014】
店舗アプリは、決済先(店舗側)、決済元(利用者側)、及び決済額(店舗側の売上額)などの情報を含む取引情報を決済サーバ100に送信する。なお、取引情報には、上述の各情報の他、取引を個別に特定するための取引コードや、取引が行われた日時を特定するための日時情報(タイムスタンプ)などの情報が含まれていてもよい。
【0015】
また、決済サーバ100は、利用者端末用のアプリケーションプログラム(以下、適宜「ユーザアプリ」と称する。)を、店舗から取引対象の提供を受ける利用者(一般消費者)に配布する。決済サーバ100は、ユーザアプリ専用のインターフェイスを介して、ユーザアプリからの取引要求を受け付けた場合は、その取引要求に従って、口座間における電子マネーの送金処理などを含む情報処理を実行する。ユーザアプリは、決済先(店舗側)、決済元(利用者側)、及び決済額(店舗側の売上額)などの情報を含む取引情報を決済サーバ100に送信する。なお、取引情報には、上述の各情報の他、取引を個別に特定するための取引コードや、取引が行われた日時を特定するための日時情報(タイムスタンプ)などの情報が含まれていてもよい。
【0016】
図1に示す利用者端末10は、店舗から取引対象の提供を受ける一般消費者である利用者UYによって利用される情報処理装置である。利用者端末10は、たとえば、スマートフォンや、タブレット型端末、ノート型PC(Personal Computer)、デスクトップPC、携帯電話機、PDA(Personal Digital Assistant)などにより実現される。また、利用者端末10は、決済サーバ100によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、
図1では、利用者端末10としてスマートフォンを例示している。
【0017】
図1に示す店舗端末20は、取引対象を提供する事業を営む事業者UXによって利用される情報処理装置である。店舗端末20は、たとえば、スマートフォンや、タブレット型端末、ノート型PC(Personal Computer)、デスクトップPC、携帯電話機、PDA(Personal Digital Assistant)などにより実現される。また、店舗端末20は、決済サーバ100によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、
図1では、店舗端末20としてタブレット型端末を例示している。
【0018】
なお、利用者端末10および店舗端末20は、所定の情報処理を実現する制御情報を決済サーバ100から受け取った場合には、制御情報に従って情報処理を実現する。ここで、制御情報は、たとえばJavaScript(登録商標)などのスクリプト言語やCSS(Cascading Style Sheets)などのスタイルシート言語、Java(登録商標)などのプログラミング言語、HTML(HyperText Markup Language)などのマークアップ言語などにより記述される。なお、決済サーバ100から配信される所定のアプリケーションそのものを制御情報とみなしてもよい。
【0019】
(1-2.利用者端末10を用いた決済について)
ここで、決済サーバ100により実行される情報処理の説明に先立ち、利用者端末10を用いたコード決済(電子決済)の一例について説明する。なお、以下の説明では、店舗Xに配置された2次元コード(QRコード(登録商標))であって、店舗Xを識別する店舗識別情報を示す2次元コードC-Xを用いて、利用者UYが利用者端末10を用いた決済を行う例について説明するが、実施形態は、これに限定されるものではない。以下に説明するコード決済の一例は、任意の利用者が任意の利用者端末10を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗識別情報を示す2次元コードC-Xは、QRコードのみならず、バーコードや所定のマーク、番号などであってもよい。また、2次元コードC-Xは、紙などの媒体に印字された印刷物により物理的に構成される例に限られず、店舗端末20に表示される画像情報により構成されていてもよい。
【0020】
例えば、利用者UYが店舗Xにて各種の商品やサービスといった取引対象の購入や利用に伴う決済を行う場合、利用者UYは、利用者端末10に予めインストールされたユーザアプリ10AP(たとえば、
図4参照)を起動する。そして、利用者UYは、ユーザアプリ10APを介して、店舗Xに設置された2次元コードC-Xを撮影する。このような場合、利用者端末10は、取引対象の価格を入力するための画面を表示し、利用者UYあるいは店舗Xの店員から決済金額の入力を受け付ける。そして、利用者端末10は、利用者UYを識別する利用者識別情報と、店舗識別情報(もしくは、店舗識別情報が示す情報、すなわち、店舗Xを示す情報(たとえば、店舗ID))と、決済額とを含む取引情報を決済サーバ100へと送信する。
【0021】
決済サーバ100は、利用者端末10から取引情報を受け付けると、利用者識別情報が示す利用者UYの口座から、店舗識別情報が示す店舗Xの口座へと、決済額に相当する分の電子マネーを移行させる。このとき、決済サーバ100は、決済額に相当する分の電子マネーから店舗Xに課金する所定の手数料を差し引いてから、店舗Xの口座へ移行させてもよい。そして、決済サーバ100は、取引が完了した旨の通知を利用者端末10へと送信する。このような場合、利用者端末10は、取引が完了した旨の画面や所定の音声を出力することで、電子マネーによる取引が完了した旨を利用者UYに通知する。あるいは、決済サーバ100は、利用者識別情報が示す利用者UYの口座から決済額に相当する分の電子マネーを引き出して店舗Xの売り上げ情報として管理し、所定のタイミングで売上に相当する額の現金を店舗Xが保有する銀行口座に振り込んでもよい。この場合、決済サーバ100は、利用者UYの口座から決済額に相当する分の電子マネーを引き出したタイミングで、電子マネーによる取引が完了した旨を利用者UYに通知してもよい。
【0022】
なお、利用者端末10を用いた決済は、上述した処理に限定されるものではない。たとえば、利用者端末10を用いた決済は、店舗Xに設置された店舗端末20を用いたものであってもよい。具体的には、まず、利用者端末10は、利用者UYを識別するための利用者識別情報を示すコード情報を画面上に表示させる。このような場合、店舗Xに設置された店舗端末20は、利用者端末10に表示されたコード情報から利用者識別情報を読み取り、読み取った利用者識別情報(もしくは、利用者識別情報が示す情報、すなわち、利用者UYを示す情報(たとえば、利用者ID))と、決済額と、店舗Xを識別する情報とを含む取引情報を決済サーバ100へと送信する。
【0023】
決済サーバ100は、店舗端末20から取引情報を受け付けると、利用者識別情報が示す利用者UYの口座から、店舗Xの口座へと、決済額に相当する分の電子マネーを移行させる。そして、決済サーバ100は、店舗端末20あるいは利用者端末10に対し、取引が完了した旨の通知を送信する。店舗端末20あるいは利用者端末10は、取引が完了した旨の画面や所定の音声を出力することで、電子マネーによる取引が完了した旨を利用者UYに通知する。また、決済サーバ100は、利用者識別情報が示す利用者UYの口座から決済額に相当する分の電子マネーを引き出して店舗Xの売り上げ情報として管理し、所定のタイミングで売上に相当する額の現金を店舗Xが保有する銀行口座に振り込んでもよい。この場合、決済サーバ100は、利用者UYの口座から決済額に相当する分の電子マネーを引き出したタイミングで、電子マネーによる取引が完了した旨を事業者UXあるいは利用者UYに通知してもよい。
【0024】
また、利用者端末10を用いた決済は、利用者UYが予め電子マネーをチャージした口座から店舗Xの口座へと電子マネーを移行させる処理のみならず、たとえば、利用者UYが予め登録したクレジットカードを用いた決済であってもよい。このような場合、たとえば、利用者端末10は、店舗Xの口座に対して決済金額が示す額の電子マネーを移行させるとともに、利用者UYのクレジットカードの運用会社に対し、決済金額が示す額を請求してもよい。
【0025】
(1-3.実施形態の概要について)
(1-3-1.情報処理(その1))
従来、店舗ロケーションなどの環境的な要因により、利用者端末10や店舗端末20が圏外となり、データ通信ができない状況となった場合、コード決済が利用できなくなってしまう。このように、コード決済の利用は通信状況に左右され、必ずしも信頼性が高いとは言い切れない。
【0026】
そこで、決済サーバ100を有する情報処理システム1は、実施形態に係る情報処理(その1)を実行する。以下、
図1を用いて、決済サーバ100を有する情報処理システム1が実行する情報処理(その1)について説明する。
図1に示す情報処理(その1)は、利用者端末10が店舗Xに設置された2次元コードC-Xを読み取ることにより、利用者端末10を主体としてオフラインで行われる決済に関する取引処理の一例を示している。
【0027】
なお、以下の説明では、利用者端末10が利用者UYにより利用される例を示す。また、以下の説明では、利用者端末10を利用者UYと同一視する場合がある。すなわち、以下では、利用者UYを利用者端末10と読み替えることもできる。
【0028】
また、以下の説明では、店舗端末20が事業者UXにより利用される例を示す。また、以下の説明では、店舗端末20を事業者UXと同一視する場合がある。すなわち、以下では、事業者UXを店舗端末20と読み替えることもできる。
【0029】
また、以下の説明において、店舗Xに設置されている2次元コードC-Xは、店舗識別情報に加えて、オフラインでの決済取引(以下、適宜「オフライン決済」と略称する。)である旨を示す情報を有しているものとする。ここで、実施形態におけるオフライン決済とは、オフライン環境下で行われる予備的な(仕掛りの)決済の取引である。オフライン決済は、事後的に決済サーバ100において処理される。
【0030】
まず、店舗端末20は、決済サーバ100に対して、オフライン設定の有効化を要求する(ステップS11)。すなわち、事業者UXは、決済サーバ100に対して、オフラインでの売上処理の有効化を要求する。たとえば、事業者UXは、店舗アプリ上でオフラインでの売上処理を有効化するためのオフライン動作モードを選択する。店舗端末20は、事業者UXによるオフライン動作モードの選択に応じて、オフライン設定の有効化に関するリクエストを決済サーバ100に送信する。
【0031】
決済サーバ100は、店舗アプリ専用のインターフェイスを介して、店舗端末20からオフライン設定の有効化に関するリクエストを受け付けると、オフラインでの売上処理における上限金額を設定する(ステップS12)。この上限金金額は、決済サーバ100により提供されるサービスを営むサービス事業者が、サービス利用者である事業者UXに対してオフラインでの売上を許容する金額の上限である。たとえば、上限金額は、店舗Xの過去の取引履歴に基づいて規定される。そして、決済サーバ100は、オフライン設定の承認通知を店舗端末20に送信する(ステップS13)。
【0032】
店舗Xのオフライン設定が完了した後、利用者UYが店舗Xにより提供される各種の商品やサービスといった取引対象の購入や利用に伴う決済を行う場合、利用者端末10に予めインストールされたユーザアプリ10APを起動する。そして、利用者UYは、ユーザアプリ10APを介して、店舗Xに設置された2次元コードC-Xを撮影し、2次元コードC-Xを読み取る(ステップS14)。
【0033】
また、利用者端末10で動作するユーザアプリ10APは、2次元コードC-Xから読み取った情報の中にオフライン決済である旨が含まれる場合、2次元コードC-Xの読取に連動して、コード決済(以下、単に「決済」と称する。)の取引が完了した旨を利用者UYに通知する(ステップS15)。これにより、利用者UYは、実際の決済が行われていないオフライン環境下であっても、オンライン環境下である場合と同様に、違和感なくコード決済を利用できる。
【0034】
そして、ユーザアプリ10APは、オフライン決済である旨を示す情報に関連付けて、オフライン決済が行われた店舗Xを示す店舗識別情報と、オフライン決済が行われた日時(2次元コードC-Xの読取が行われた日時)を示す日時情報と、オフライン決済による店舗Xの売上額を示す情報とを含む取引データ(「取引情報」の一例)を記録する(ステップS16)。
図1に示す例では、ユーザアプリ10APが記録する取引データとして、オフライン決済である旨に関連付けられた店舗識別情報:「S#X-1」、日時情報:「2022/1/11 12:34」、及び売上額:「1,000円」が示されている。これにより、オフライン環境下で行われた仕掛りの決済に対応する実際の取引処理が決済サーバ100において事後的に処理可能な状態に連携させることができる。
【0035】
その後、利用者UYが店舗Xから退店する。利用者端末10を取り巻く環境が、オフライン決済が行われた日時(2次元コードC-Xの読取が行われた日時)から所定時間以内にオンライン環境となると、ユーザアプリ10APは、ステップS16で記録した取引データを決済サーバ100に伝送する(ステップS17)。たとえば、一実施形態では、オフライン決済が行われた日時から24時間以内に利用者端末10がオンライン環境下となった場合に、ステップS16で記録した取引データを決済サーバ100に伝送する。オフライン決済が行われた日時から24時間以内に利用者端末10がオンライン環境下とならなかった場合、オフライン決済(ステップS14~ステップS16)は無効となり、後述の取引処理(ステップS18)は行われない。この場合、決済サーバ100の管理者である決済サービスの提供事業者が、オフライン決済にかかる売上額を店舗Xの口座に補填してもよいし、保険サービス等によって店舗Xの売上額を補償してもよい。なお、ユーザアプリ10APは、オフライン決済が行われた日時から所定時間以内であれば、任意のタイミングで取引データを決済サーバ100に伝送できる。たとえば、ユーザアプリ10APは、オンライン環境の検出後、即時に取引データを伝送してもよいし、オンライン環境の検出後、一定時間の経過後、取引データを伝送してもよい。また、ユーザアプリ10APは、取引データを任意の単位で決済サーバ100に伝送してもよい。たとえば、ユーザアプリ10APは、取引データの履歴を時系列で所定数取りまとめて伝送してもよいし、店舗ごとに取りまとめて伝送してもよい。
【0036】
決済サーバ100は、利用者端末10から取引データを受信すると、受信した取引データに従って、取引データに対応する取引処理を実行する(ステップS18)。たとえば、決済サーバ100は、オフライン決済による店舗Xの売上額が所定の条件を満たす場合、取引データに対応する取引処理を実行する。具体的には、決済サーバ100は、店舗Xの売上額の合計が店舗(事業者)ごとに個別に割り当てられる所定の上限金額に満たないことを条件として、取引データに対応する取引処理を実行する。すなわち、決済サーバ100は、取引データの送信元である利用者UY(決済元)の口座から、取引データに示される店舗X(決済先)の口座へと、店舗Xの売上額に相当する分の電子マネーを移行させる。このようにして、決済サーバ100は、オフライン環境下にある店舗Xであっても、利用者UYによるコード決済の利用を実現できる。
【0037】
なお、上述の情報処理(その1)において、店舗Xに設置されている2次元コードC-Xには、オフライン決済である旨を示す情報を有していなくてもよい。この場合、決済サーバ100は、利用者端末10から受信した取引データに含まれる日時情報を参照する。そして、決済サーバ100は、店舗Xにおけるオンライン決済が有効な状態である期間内に2次元コードC-Xの読取日時が含まれる場合、取引データに対応する取引処理を実行する。これにより、決済サーバ100は、オフライン決済用の2次元コードの設置などの特段の準備を要することなく、オフライン環境下であっても、オンライン環境下と同様の手続でコード決済を利用できる。
【0038】
(1-3-2.情報処理(その2))
以下、
図2を用いて、決済サーバ100を有する情報処理システム1が実行する情報処理(その2)について説明する。
図2は、実施形態に係る情報処理(その2)の一例を示す図である。
図2に示す情報処理(その2)は、店舗端末20が利用者端末10に表示されたコード情報を読み取ることにより、店舗端末20を主体としてオフラインで行われる決済に関する取引処理の一例を示している。なお、
図2に示す情報処理(その2)は、ステップS31~ステップS33までの処理が
図1に示すステップS11~ステップS13までの処理と同一であるが、ステップS34~ステップS39までの処理が
図1に示す情報処理(その1)とは相違する。以下では、
図2に示す情報処理(その2)について、
図1に示す情報処理(その1)と相違する部分を説明する。
【0039】
すなわち、利用者UYが各種の商品やサービスといった取引対象の購入や利用に伴う決済を店舗Xにて行う場合、利用者UYはユーザアプリ10APを起動する。そして、利用者UYは、ユーザアプリ10APを操作して、利用者UYを識別するための利用者識別情報を含む2次元コードC-Yを利用者端末10に表示させ(ステップS34)、店舗Xの店員に提示する。
【0040】
店舗端末20で動作する店舗アプリ20AP(たとえば、
図4参照)は、利用者端末10に表示された2次元コードC-Yを読み取る(ステップS35)。たとえば、店舗Xの店員は、店舗端末20に予めインストールされた店舗アプリ20APを起動する。そして、店舗Xの店員は、店舗アプリ20APを介して、利用者端末10に表示された2次元コードC-Yを撮影し、2次元コードC-Yを読み取る。
【0041】
また、店舗アプリ20APは、2次元コードC-Yの読取を行った際、オフライン設定が有効な状態であることを条件として、2次元コードC-Yの読取に連動して、決済の取引が完了した旨を示す情報を利用者端末10に送信する(ステップS36)。たとえば、店舗アプリ20APは、利用者端末10と店舗端末20との間でデータの送受信が可能な近距離無線通信を用いて、決済の取引が完了した旨を示す情報を利用者端末10に送信する。また、店舗アプリ20APは、オンライン環境下でコード決済を行った場合と同様の画面や所定の音声を店舗端末20から出力してもよい。これらにより、利用者UYは、実際には決済の取引に関する処理が行われていないオフライン環境下であっても、オンライン環境下である場合と同様に、違和感なくコード決済を利用できる。
【0042】
そして、店舗アプリ20APは、オフライン決済である旨を示す情報に関連付けて、オフライン決済を行った利用者を識別するための利用者識別情報と、オフライン決済が行われた日時(2次元コードC-Yの読取が行われた日時)を示す日時情報と、オフライン決済による店舗Xの売上額を示す情報とを含む取引データ(「取引情報」の一例)を記録する(ステップS37)。
図2に示す例では、店舗アプリ20APが記録する取引データとして、オフライン決済である旨に関連付けられた利用者識別情報:「U#Y-1」、日時情報:「2022/1/11 12:34」、及び売上額:「1,000円」が示されている。
【0043】
また、利用者端末10で動作するユーザアプリ10APは、店舗端末20から決済の取引が完了した旨を示す情報を受信した場合、この情報の受信に連動して、決済の取引が完了したことを示す画面や所定の音声を出力して、利用者UYに通知する(ステップS38)。たとえば、ユーザアプリ10APは、オンライン環境下でコード決済を行った場合と同様の画面や所定の音声を利用者端末10から出力できる。
【0044】
その後、事業者UX(あるいは店員)が店舗端末20を所持して店舗Xから移動することにより、店舗端末20を取り巻く環境が、オフライン決済が行われた日時(2次元コードC-Yの読取が行われた日時)から所定時間以内にオンライン環境になると、店舗アプリ20APは、ステップS36で記録した取引データを決済サーバ100に伝送する(ステップS39)。たとえば、一実施形態では、オフライン決済が行われた日時から24時間以内に店舗端末20がオンライン環境下となった場合に、ステップS37で記録した取引データを決済サーバ100に伝送する。オフライン決済が行われた日時から24時間以内に店舗端末20がオンライン環境下とならなかった場合、オフライン決済(ステップS35~ステップS37)は無効となり、後述の取引処理(ステップS40)は行われない。この場合、決済サーバ100の管理者である決済サービスの提供事業者が、オフライン決済にかかる売上額を店舗Xの口座に補填してもよいし、保険サービス等によって店舗Xの売上額を補償してもよい。なお、店舗アプリ20APは、オフライン決済が行われた日時から所定時間以内であれば、任意のタイミングで取引データを決済サーバ100に伝送できる。たとえば、店舗アプリ20APは、オンライン環境の検出後、即時に取引データを伝送してもよいし、オンライン環境の検出後、一定時間の経過後、取引データを伝送してもよい。また、店舗アプリ20APは、取引データを任意の単位で決済サーバ100に伝送してもよい。たとえば、店舗アプリ20APは、取引データの履歴を時系列で所定数取りまとめて伝送してもよい。
【0045】
決済サーバ100は、店舗端末20から取引データを受信すると、受信した取引データに従って、取引データに対応する取引処理を実行する(ステップS40)。たとえば、決済サーバ100は、取引データに基づいて、取引データに示される利用者UY(決済元)の口座から、取引データに示される店舗X(決済先)の口座へと、店舗Xの売上額に相当する分の電子マネーを移行させる。
【0046】
なお、上述の情報処理(その2)において、決済サーバ100は、店舗端末20から取引データを受信した場合、取引データに含まれる利用者識別情報に基づいて、利用者識別情報により識別される利用者UYに対し、実際にオフラインでの決済取引を行ったか否かの事実確認を行ってもよい。たとえば、決済サーバ100は、店舗端末20から取引データを受信した場合、利用者UYが使用する利用者端末10に対して確認通知を送信する。そして、決済サーバ100は、利用者UYにより、オフラインでの決済取引の事実が承認されることを条件として、取引データに対応する取引処理を実行する。これにより、決済サーバ100は、オフライン環境下であっても、コード決済の信頼性を担保できる。
【0047】
(1-3-3.情報処理(その3))
従来、利用者が予め自らのアカウントにチャージしたマネー残高を用いてコード決済を行う場合、残高を適宜チャージする必要があり、利用者に対して少なからず手間をかけさせることになる。また、事情により、電子マネーを即時チャージできない場合、コード決済そのものが利用できなくなってしまう。このように、従来のコード決済には、ユーザビリティを高める上で改善の余地がある。
【0048】
そこで、決済サーバ100を有する情報処理システム1は、実施形態に係る情報処理(その3)を実行する。たとえば、決済サーバ100は、利用者(たとえば、利用者UY)の置かれる状態が所定の条件を満たしているか否かを判定し、利用者の置かれる状態が所定の条件を満たしていると判定した場合、利用者に割り当てられたアカウントに対して電子マネーの自動チャージを実行する。
【0049】
以下、
図3を用いて、決済サーバ100を有する情報処理システム1が実行する情報処理(その3)について具体的に説明する。
図3は、実施形態に係る情報処理(その3)の一例を示す図である。
図3では、利用者UYの置かれる状態の一例として地震(「災害」の一例)の発生を例示しているが、地震に限らず、利用者UYによるチャージが困難となる可能性があるその他の災害の発生やイベントの発生を含み得る。なお、
図3に示す情報処理(その3)は、ステップS51~ステップS54までの処理が、
図1に示す情報処理(その1)や
図2に示す情報処理(その2)とは相違する。以下では、
図3に示す情報処理(その3)について、
図1に示す情報処理(その1)や
図2に示す情報処理(その2)と相違する部分を説明する。
【0050】
まず、利用者UYは、決済サーバ100に対して、自動チャージサービスの申込を行う(ステップS51)。自動チャージサービスは、利用者UYの置かれる状態が所定の条件を満たしていると判定した場合、利用者UYに割り当てられたアカウントに対して電子マネーを自動的にチャージするサービスである。サービス利用者は、たとえば、自動チャージサービスを利用するための利用代金を毎月支払う。決済サーバ100は、サービス利用者から毎月支払われる利用代金をサービス利用者ごとに積み立てる。決済サーバ100は、サービス利用者ごとに積み立てた金額を原資として、電子マネーの自動チャージを実行する。なお、自動チャージサービスの利用代金は、月賦払いに限られず、一時払いなどの任意の支払方法を選択可能に構成されてもよい。
【0051】
また、決済サーバ100は、自動チャージサービスの利用条件として、ユーザアプリ10APによる位置追跡の許可を含めることができる。これにより、決済サーバ100は、利用者UYが使用する利用者端末10の位置を特定できる。
【0052】
一方、決済サーバ100は、利用者UYからの自動チャージサービスの申込を受け付ける(ステップS52)。たとえば、決済サーバ100は、利用者UYに割り当てられたアカウントに対する自動チャージサービスの設定を有効化する。
【0053】
ここで、地震の発生を検知すると、決済サーバ100は、利用者UYの置かれる状態が所定の条件を満たしているか否かを判定する(ステップS53)。たとえば、決済サーバ100は、地震が発生した場合、利用者UYの位置と地震発生エリアとの間の距離が所定の距離範囲内にあるか否かを判定する。決済サーバ100は、利用者端末10から取得する位置情報に基づいて利用者UYの位置を特定する。
【0054】
そして、決済サーバ100は、利用者UYの位置と地震発生エリアとの間の距離が所定の距離範囲内にあると判定された場合、利用者UYに紐付くアカウントに対して電子マネーの自動チャージを実行する(ステップS54)。これにより、決済サーバ100は、地震の発生によりマネー残高のチャージが困難な状況となる可能性がある利用者UYについて、残高不足によりコード決済が利用できなくなる事態を回避できる。なお、電子マネーのチャージ額は、自動チャージサービスを利用する全てのサービス利用者に共通の金額であってもよいし、サービス利用者ごとに個別に決定された金額であってもよい。
【0055】
また、決済サーバ100は、利用者UYの置かれる状態として、利用者UYのマネー残高が所定額未満であるか否かを判定してもよい。この場合、決済サーバ100は、たとえば、マネー残高が所定値未満であると判定した場合、電子マネーの自動チャージを実行する。これにより、決済サーバ100は、コード決済の利用時にマネー残高が不足する可能性がある利用者UYについて、残高不足によりコード決済が利用できなくなる事態を回避できる。なお、決済サーバ100は、利用者UYの位置と地震発生エリアとの間の距離が所定の距離範囲内にあると判定された場合、さらに、利用者UYのマネー残高が所定額未満であるか否かを判定してもよい。
【0056】
また、決済サーバ100は、予め規定されているチャージ可能額に基づいて、電子マネーの自動チャージを実行する。決済サーバ100は、チャージ可能額に相当する額の電子マネーを自動チャージできる。たとえば、チャージ可能額は、サービス利用者ごとに個別に規定されてもよい。これにより、決済サーバ100は、チャージ可能額の範囲内でリスクヘッジを行いつつ、残高不足によりコード決済が利用できなくなる事態をできるだけ回避できる。
【0057】
〔2.決済サーバの構成〕
次に、
図4を用いて、決済サーバ100の構成について説明する。
図4は、実施形態に係る決済サーバの構成例を示す図である。
図4に示すように、決済サーバ100は、通信部110と、記憶部120と、制御部130とを有する。
【0058】
(通信部110について)
通信部110は、例えば、NIC(Network Interface Card)等によって実現される。そして、通信部110は、ネットワークNと有線または無線で接続され、利用者端末10や、店舗端末20などとの間で情報の送受信を行う。
【0059】
(記憶部120について)
記憶部120は、例えば、RAM(Random Access Memory)、フラッシュメモリ(Flash Memory)等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。
図4に示すように、記憶部120は、口座情報記憶部121と、店舗情報記憶部122と、利用者情報記憶部123とを有する。
【0060】
(口座情報記憶部121について)
口座情報記憶部121は、利用者(一般消費者)や店舗(事業者)などのサービス利用者が電子決済サービスにおいて所有する口座に関する各種の情報を記憶する。ここで、
図5を用いて、口座情報記憶部121が記憶する情報の一例を説明する。
図5は、実施形態に係る口座情報記憶部に記憶される情報の一例を示す図である。
図5の例において、口座情報記憶部121は、「口座ID」や、「所有者ID」や、「総残高(円)」などといった複数の項目を有する。
【0061】
「口座ID」の項目には、口座を識別するための識別情報が記憶される。「所有者情報」の項目は、口座を所有する所有者を識別するための識別情報が記憶される。なお、「所有者情報」の項目には、後述するユーザIDが記憶されてもよい。「口座残高(円)」の項目には、口座の残高を示す情報が記憶される。残高を示す情報として、たとえば、電子マネーに相当する現金の額が記憶される。
【0062】
すなわち、
図5では、口座ID「AC#1」によって識別される口座の所有者の情報が「S#X-1」であり、総残高が「1,150,000(円)」である例が示されている。
【0063】
(店舗情報記憶部122について)
店舗情報記憶部122は、店舗のオフライン設定に関する情報が記憶される。ここで、
図6を用いて、店舗情報記憶部122が記憶する情報の一例を説明する。
図6は、実施形態に係る店舗情報記憶部に記憶される情報の一例を示す図である。
図6の例において、店舗情報記憶部122は、「店舗ID」や、「オフライン設定」や、「上限金額(円)」などといった複数の項目を有する。
【0064】
「店舗ID」の項目には、商品やサービスなどの取引対象を一般消費者に提供する事業者により運営される店舗を識別するための店舗識別情報が記憶される。「オフライン設定」の項目には、オフライン決済(オフラインでの売上処理)が有効な状態か否かを示す情報が記憶される。「上限金額(円)」の項目には、オフライン環境上でコード決済を受け付けることが可能な上限金額を示す情報が記憶される。なお、決済サーバ100を通じて電子決済サービスを提供するサービス事業者は、店舗に対して上限金額の項目に設定されている金額を補償する。
【0065】
すなわち、
図6では、店舗ID「S#X-1」によって識別される店舗のオフライン設定は有効な状態であり、上限金額である「100,000(円)」までオフライン決済が可能であることが示されている。
【0066】
(利用者情報記憶部123について)
利用者情報記憶部123は、決済サーバ100が提供する電子決済サービスの利用者に関する各種の情報を記憶する。ここで、
図7を用いて、利用者情報記憶部123が記憶する情報の一例を説明する。
図7は、実施形態に係る利用者情報記憶部に記憶される情報の一例を示す図である。
図7の例において、利用者情報記憶部123は、「利用者ID」や、「自動チャージ設定」や、「チャージ可能額(円)」などといった複数の項目を有する。
【0067】
「利用者ID」の項目には、利用者を識別するための利用者識別情報が記憶される。「自動チャージ設定」の項目には、自動チャージサービスが有効な状態か否を示す情報が記憶される。「チャージ可能額(円)」の項目には、自動チャージサービスによるチャージ可能額を示す情報が記憶される。
【0068】
すなわち、
図7では、利用者ID「U#Y-1」によって識別される利用者について、自動チャージサービスが有効な状態であり、自動チャージサービスによるチャージ可能額が「30,000(円)」であることが示されている。
【0069】
(制御部130について)
制御部130は、コントローラ(controller)であり、例えば、CPU(Central Processing Unit)やMPU(Micro Processing Unit)などによって、決済サーバ100内部の記憶装置に記憶されている各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部130は、たとえば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)などの集積回路により実現され得る。実施形態に係る制御部130は、
図4に示すように、受付部131と、判定部132と、チャージ部133と、実行部134とを有し、これらの各部により、以下に説明する情報処理の機能や作用を実現または実行する。
【0070】
(受付部131について)
受付部131は、利用者端末10または店舗端末20からオフラインでの決済取引である旨を示す情報と、決済取引による店舗(たとえば、
図1または
図2に示す店舗X)の売上額とを含む取引データ(「取引情報」の一例)を受け付ける。受付部131は、利用者端末10または店舗端末20から受け付けた取引データを実行部134に受け渡す。
【0071】
また、受付部131は、店舗(たとえば、店舗X)を識別するための店舗識別情報を含む取引データを利用者端末10から受け付ける。また、受付部131は、決済取引が行われた日時を示す日時情報を含む取引データを利用者端末10から受け付ける。受付部131は、利用者端末10から受け付けた取引データを実行部134に受け渡す。
【0072】
また、受付部131は、決済取引を行った利用者(たとえば、
図2に示す利用者UY)を識別するための利用者識別情報を含む取引データを店舗端末20から受け付ける。受付部131は、利用者端末10から受け付けた取引データを実行部134に受け渡す。
【0073】
(判定部132について)
判定部132は、電子決済サービスのサービス利用者(たとえば、
図3に示す利用者UY)の置かれる状態が所定の条件を満たしているか否かを判定する。
【0074】
たとえば、判定部132は、災害が発生した場合、サービス利用者の位置と災害発生エリアとの間の距離が所定の距離範囲内にあるか否かを判定する。具体的には、判定部132は、地震の発生を検知すると、利用者情報記憶部123に記憶されている情報を参照して、自動チャージサービスのサービス利用者を抽出する。つまり、判定部132は、利用者情報記憶部123に記憶されている情報において、自動チャージ設定が有効な状態であるサービス利用者を特定する。次に、判定部132は、抽出したサービス利用者の中から、処理対象とするサービス利用者を選択する。次に、判定部132は、選択したサービス利用者の位置を特定し、特定した位置と地震発生エリアとの距離を推定する。なお、判定部132は、サービス利用者の位置と地震発生エリアとの距離を推定する場合、サービス利用者の位置と、地震発生エリアにおいて震度が最も高いエリアとの距離を推定してもよい。あるいは、判定部132は、サービス利用者の位置と地震発生エリアとの間の最短距離を推定してもよい。そして、判定部132は、推定した距離が予め規定される閾値以下であるか否かを判定する。
【0075】
また、たとえば、判定部132は、サービス利用者のマネー残高が所定額未満であるか否かを判定する。判定部132は、判定結果をチャージ部133に受け渡す。
【0076】
(チャージ部133について)
チャージ部133は、判定部132によりサービス利用者(たとえば、
図3に示す利用者UY)の置かれる状態が所定の条件を満たしていると判定された場合、サービス利用者に割り当てられたアカウントに対して電子マネーの自動チャージを実行する。
【0077】
たとえば、チャージ部133は、自動チャージ設定が有効であるサービス利用者について、予め規定された自動チャージサービスを利用するための月額料金から所定の手数料を控除した金額を、サービス利用者ごとに積み立てる。また、チャージ部133は、判定部132によりサービス利用者の位置と災害発生エリアとの間の距離が所定の距離範囲内にあると判定された場合、サービス利用者ごとに積み立てた積立金額の中から自動チャージを実行する。たとえば、チャージ部133は、積立金額の中から、予め規定されているチャージ可能額に基づいて自動チャージを実行できる。また、たとえば、チャージ部133は、判定部132によりマネー残高が所定値未満であると判定された場合、自動チャージを実行する。
【0078】
(実行部134について)
実行部134は、オフライン決済による店舗の売上額が所定の条件を満たす場合、オフライン決済に対応する取引処理を実行する。たとえば、実行部134は、店舗の売上額の合計が店舗ごとに個別に割り当てられる所定の上限金額に満たないことを条件として、オフライン決済に対応する取引処理を実行する。具体的には、実行部134は、該当店舗についてオフライン決済が有効な状態であり、かつ、オフライン決済における売上額の合計額が所定の上限金額未満であり、かつ、利用者端末10からの取引データが所定の時間内に受信された場合、オフライン決済に対応する取引処理を実行する。つまり、決済サーバ100は、オフライン決済が有効である場合、所定時間内に受信した取引データについて、所定の条件金額に達するまでオフライン決済を受け入れ可能である。
【0079】
なお、実行部134は、店舗の過去の取引履歴に基づいて、オフライン決済の上限金額を店舗ごとに決定できる。具体的には、実行部134は、店舗の過去の取引履歴から、所定期間における平均売上額を算出し、算出した平均売上額を上限金額に決定してもよいし、所定期間における売上額の中央値を特定し、特定した中央値を上限金額に決定してもよい。実行部134は、決定した上限金額を店舗識別情報に対応付けて店舗情報記憶部122に登録する。
【0080】
また、実行部134は、店舗情報記憶部122に記憶されている情報において、利用者端末10からの取引データに含まれる店舗識別情報に対応付けられている上限金額を参照し、この上限金額に基づいて取引処理を実行する。
【0081】
また、実行部134は、利用者端末10からの取引データに含まれる日時情報からオフライン決済が行われた日時を特定し、特定した日時が、取引データに含まれる店舗識別情報により識別される店舗においてオフライン決済が有効な状態である期間内に含まれていることを条件として、オフライン決済に対応する取引処理を実行してもよい。
【0082】
また、実行部134は、店舗端末20からの取引データに含まれる利用者識別情報により識別される利用者によりオフライン決済の事実が承認されることを条件として、オフライン決済に対応する取引処理を実行してもよい。
【0083】
〔3.処理手順例〕
(3-1.処理の流れ(その1))
以下、実施形態に係る決済サーバ100を有する情報処理システムにおける処理の流れを説明する。まず、
図8を用いて、実施形態に係る処理の流れ(その1)について説明する。
図8は、実施形態に係る処理の流れ(その1)の一例を示すシーケンス図である。
【0084】
図8に示すように、店舗端末20は、決済サーバ100に対して、オフライン設定要求を送信する(ステップS101)。
【0085】
一方、決済サーバ100は、店舗端末20からオフライン設定要求を受信すると、店舗端末20に紐付く店舗Xの上限金額を設定する(ステップS102)。そして、決済サーバ100は、店舗Xのオフライン設定をアクティベートし、オフライン設定の承認通知を店舗端末20に送信する(ステップS103)。
【0086】
その後、利用者端末10の利用者がオフライン環境下にある店舗Xに入店し、店舗Xから取引対象の提供を受けるために、利用者端末10を主体とするコード決済を行うと仮定する。この場合、利用者端末10は、利用者の操作に従って、たとえば店舗Xに設置されている2次元コードを読み取る(ステップS104)。
【0087】
また、利用者端末10は、2次元コードから読み取った情報の中にオフライン決済である旨が含まれる場合、2次元コードの読取に連動して、決済の取引が完了した旨を利用者UYに通知する(ステップS105)。
【0088】
また、利用者端末10は、オフライン決済である旨を示す情報に関連付けて、オフライン決済が行われた店舗Xを示す店舗識別情報と、2次元コードの読取日時を示す日時情報と、オフライン決済による店舗Xの売上額を示す情報とを含む取引データを記録する(ステップS106)。
【0089】
その後、利用者端末10の利用者が店舗Xから退店する。対象取引において2次元コードが読み取られた日時(ステップ106)から所定時間以内に利用者端末10を取り巻く環境がオンライン環境となると、利用者端末10は、ステップS106で記録した取引データを決済サーバ100に伝送する(ステップS107)。
【0090】
決済サーバ100は、利用者端末10から取引データを受信すると、受信した取引データに従って、取引データに対応する取引処理を実行する(ステップS108)。
【0091】
(3-2.処理の流れ(その2))
続いて、
図9を用いて、実施形態に係る処理の流れ(その2)について説明する。
図9は、実施形態に係る処理の流れ(その2)の一例を示すシーケンス図である。
【0092】
図9に示すように、店舗端末20は、決済サーバ100に対して、オフライン設定要求を送信する(ステップS201)。
【0093】
一方、決済サーバ100は、店舗端末20からオフライン設定要求を受信すると、店舗端末20に紐付く店舗Xの上限金額を設定する(ステップS202)。そして、決済サーバ100は、店舗Xのオフライン設定をアクティベートし、オフライン設定の承認通知を店舗端末20に送信する(ステップS203)。
【0094】
その後、利用者端末10の利用者がオフライン環境下にある店舗Xに入店し、店舗Xから取引対象の提供を受けるために、店舗端末20を主体とするコード決済を行うと仮定する。この場合、利用者端末10は、利用者の操作に従って、利用者を識別するための利用者識別情報を含むコード情報を利用者端末10に表示させ(ステップS204)、店舗Xの店員に提示する。
【0095】
店舗端末20は、利用者端末10に表示されたコード情報を読み取る(ステップS205)。
【0096】
また、店舗端末20は、利用者端末10に表示されたコード情報の読取を行った際、オフライン設定が有効な状態であることを条件として、コード情報の読取に連動して、決済の取引が完了した旨を示す取引完了通知を利用者端末10に送信する(ステップS206)。
【0097】
また、店舗端末20は、オフライン決済である旨を示す情報に関連付けて、オフライン決済を行った利用者を識別するための利用者識別情報と、コード情報の読取日時を示す日時情報と、オフライン決済による店舗Xの売上額を示す情報とを含む取引データを記録する(ステップS207)。
【0098】
一方、利用者端末10は、店舗端末20から決済の取引が完了した旨を示す取引完了通知を受信した場合、この通知の受信に連動して、決済の取引が完了したことを示す画面や所定の音声を出力して、利用者UYに通知する(ステップS208)。
【0099】
その後、店舗Xを運営する事業者UX(あるいは店員)が店舗端末20を所持して店舗Xから移動する。対象取引においてコード情報が読み取られた日時(ステップS207)から所定時間以内に、店舗端末20を取り巻く環境がオンライン環境になると、店舗端末20は、ステップS207で記録した取引データを決済サーバ100に伝送する(ステップS209)。
【0100】
決済サーバ100は、店舗端末20から取引データを受信すると、受信した取引データに従って、取引データに対応する取引処理を実行する(ステップS210)。
【0101】
(3-3.決済サーバによる処理手順例)
続いて、
図10を用いて、実施形態に係る決済サーバ100による処理手順の一例について説明する。
図10は、実施形態に係る決済サーバによる処理手順の一例を示すフローチャートである。
図10に示す処理手順は、決済サーバ100の制御部130により繰り返し実行される。
【0102】
図10に示すように、判定部132は、地震の発生を検知すると(ステップS301)、利用者情報記憶部123に記憶されている情報を参照して、自動チャージ設定が有効な状態であるサービス利用者を抽出する(ステップS302)。
【0103】
また、判定部132は、ステップS302で抽出したサービス利用者の中から、処理対象となるサービス利用者を選択する(ステップS303)。
【0104】
また、判定部132は、ステップS303で選択したサービス利用者の位置を特定し、特定した位置と地震発生エリアとの距離Dを推定する(ステップS304)。
【0105】
また、判定部132は、ステップS304で推定した距離Dが予め規定される閾値TH1以下であるか否かを判定する(ステップS305)。
【0106】
また、判定部132は、ステップS304で推定した距離Dが閾値TH1以下であると判定した場合(ステップS305:Yes)、口座情報記憶部121に記憶されている情報を参照して、ステップS303で選択したサービス利用者のマネー残高が閾値TH2以下であるか否かを判定する(ステップS306)。
【0107】
判定部132により、ステップS303で選択したサービス利用者のマネー残高が閾値TH2以下であると判定された場合(ステップS306:Yes)、チャージ部133は、ステップS303で選択したサービス利用者に紐付くアカウントに対し、予め規定されているチャージ可能額に基づいて電子マネーの自動チャージを実行する(ステップS307)。
【0108】
また、判定部132は、ステップS302で抽出したサービス利用者について処理を完了したか否かを判定する(ステップS308)。
【0109】
判定部132は、ステップS302で抽出したサービス利用者について処理を完了していないと判定した場合(ステップS308:No)、上述したステップS303の処理手順に戻って、次の処理対象とするサービス利用者を選択する。これとは反対に、判定部132は、ステップS302で抽出したサービス利用者について処理を完了していると判定した場合(ステップS308:Yes)、
図10に示す処理手順を終了する。
【0110】
また、上述のステップS306において、判定部132は、ステップS303で選択したサービス利用者のマネー残高が閾値TH2以下であると判定した場合(ステップS306:No)、上述のステップS308の処理手順に移行する。
【0111】
また、上述のステップS305において、判定部132は、ステップS304で推定した距離Dが閾値TH1以下ではないと判定した場合(ステップS305:No)、上述のステップS308の処理手順に移行する。
【0112】
なお、
図10に示す処理手順において、ステップS305の処理手順とステップS306の処理手順は、
図10に示す順序を実行する場合に限られず、ステップS306の処理手順を実行した後、ステップS305の処理手順を実行してもよい。また、
図10に示す処理手順は、ステップS306の処理手順を含まなくてもよい。また、
図10に示す処理手順は、ステップS304およびステップS305の処理手順を含まなくてもよい。
【0113】
〔4.変形例〕
(4-1.取引データの突合処理について)
上述の実施形態は一例を示したものであり、種々の変更及び応用が可能である。たとえば、上述の実施形態において、利用者端末10が主体となるオフライン決済(ユーザ決済)を行った場合も、店舗端末20が主体となって行うオフライン決済(ストア決済)を行った場合も、利用者端末10と店舗端末20との間で取引データをやり取りすることにより、互いに共有してもよい。この場合、決済サーバ100は、利用者端末10から取引データを先に受信した場合、取引データに含まれる利用者識別情報に対応するアカウントに紐づくマネー残高のうち、取引データに含まれる決済額に相当する分の電子マネーを取引保留状態として一時的に留保できる。その後、決済サーバ100は、店舗端末20から取引データを受信すると、利用者端末10から受信した取引データと、店舗端末20から受信した取引データとを突合することにより、取引内容に問題がない場合、取引保留状態を解除して、取引処理を実行する。
【0114】
(4-2.取引データの伝送期限について)
たとえば、上述の実施形態において、店舗Xにおいてオフライン決済が発生してから、所定時間内(たとえば、24時間以内)に決済サーバ100に伝送されなかった取引データは無効にしてもよい。この場合、決済サーバ100は、たとえば、店舗Xにおいてオフライン決済が発生してから所定時間を超えて店舗端末20から伝送された取引データを破棄する。そして、決済サーバ100は、取引保留状態として一時的に留保していた利用者の電子マネーを、該当の利用者に紐付くアカウントに返金する。
【0115】
(4-3.情報処理システム1の構成について)
上述の実施形態では、情報処理システム1に含まれる決済サーバ100が、オフライン決済に対応する取引処理を行うとともに、サービス利用者に対する自動チャージを実行する例を説明したが、実施形態に係る情報処理システム1の構成は、このような例には特に限定される必要はない。たとえば、実施形態に係る情報処理システム1は、オフライン決済に対応する取引処理を行うサーバと、サービス利用者に対する自動チャージを実行するサーバとは、それぞれ物理的に異なるサーバであってもよく、あるいは、それぞれのサーバが異なるシステムに属するサーバであってもよい。
【0116】
(4-4.処理態様について)
上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、逆に、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
【0117】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【0118】
また、上記してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【0119】
〔5.効果〕
上述してきたように、実施形態に係る決済サーバ100は、受付部131と、実行部134とを有する。受付部131は、利用者端末10または店舗端末20からオフラインでの決済取引である旨を示す情報と決済取引による店舗の売上額とを含む取引情報を受け付ける。実行部134は、売上額が所定の条件を満たす場合、決済取引に対応する取引処理を実行する。
【0120】
これにより、実施形態に係る決済サーバ100は、オフライン環境下にある店舗であっても、利用者UYによるコード決済の利用を実現できる。この結果、決済サーバ100は、コード決済の信頼性を高めることができる。
【0121】
また、実施形態に係る決済サーバ100において、実行部134は、売上額の合計が店舗ごとに個別に割り当てられる所定の上限金額に満たないことを条件として、取引処理を実行する。
【0122】
また、実施形態に係る決済サーバ100において、上限金額は、店舗の過去の取引履歴に基づいて規定される。
【0123】
これらにより、決済サーバ100は、リスクヘッジを行いつつ、コード決済の信頼性を高めることができる。
【0124】
また、実施形態に係る決済サーバ100において、受付部131は、店舗を識別するための店舗識別情報を含む取引情報を利用者端末10から受け付ける。実行部134は、店舗識別情報に対応付けられている上限金額に基づいて、取引処理を実行する。これにより、決済サーバ100は、利用者端末10を主体するオフライン決済に対応する取引処理を実行できる。
【0125】
また、実施形態に係る決済サーバ100において、受付部131は、決済取引が行われた日時を示す日時情報を含む取引情報を利用者端末10から受け付ける。実行部134は、店舗識別情報により識別される店舗において決済取引が有効な状態である期間内に決済取引が行われた日時が含まれていることを条件として、取引処理を実行する。これにより、決済サーバ100は、オフライン決済を利用する店舗にオフライン決済用の2次元コードの設置などの特段の準備を要することなく、オフライン環境下であっても、オンライン環境下と同様の手続でコード決済を利用できる。
【0126】
また、実施形態に係る決済サーバ100において、受付部131は、決済取引を行った利用者を識別するための利用者識別情報を含む取引情報を店舗端末20から受け付ける。実行部134は、利用者識別情報により識別される利用者により決済取引の事実が承認されることを条件として、取引処理を実行する。これにより、決済サーバ100は、店舗端末20を主体とするコード決済の信頼性を担保できる。
【0127】
また、実施形態に係る情報処理システム1において、利用者端末10で動作するユーザアプリは、利用者端末10に、コード情報から読み取った情報の中にオフラインでの決済取引である旨が含まれる場合、コード情報の読取に連動して決済取引が完了した旨を利用者に通知する手順を実行させる。
【0128】
また、実施形態に係る情報処理システム1において、ユーザアプリは、利用者端末10に、オフラインでの決済取引である旨を示す情報に関連付けて、決済取引が行われた店舗を示す店舗識別情報と、決済取引が行われた日時を示す日時情報と、決済取引による店舗の売上額を示す情報とを含む取引情報を記録する手順を実行させる。
【0129】
これらにより、ユーザアプリは、利用者に対して、実際には決済の取引に関する処理が行われていないオフライン環境下であっても、オンライン環境下である場合と同様に、違和感なくコード決済を利用させることができる。
【0130】
また、実施形態に係る情報処理システム1において、店舗端末20で動作する店舗アプリは、利用者端末10に表示されるコード情報を読み取った際、オフラインでの売上処理が有効な状態であることを条件として、コード情報の読取に連動してオフラインでの決済取引が完了した旨を利用者に通知する手順を実行させる。
【0131】
また、実施形態に係る情報処理システム1において、店舗アプリは、オフラインでの決済取引である旨を示す情報に関連付けて、決済取引を行った利用者を識別するための利用者識別情報と、決済取引が行われた日時を示す日時情報と、決済取引による店舗の売上額を示す情報とを含む取引情報を記録する。
【0132】
また、実施形態に係る情報処理システム1において、店舗アプリは、店舗端末に、近距離無線通信により、決済が完了した旨を示す情報を利用者端末10に送信する手順を実行させる。
【0133】
これらにより、店舗アプリは、利用者に対して、実際の決済が行われていないオフライン環境下であっても、オンライン環境下である場合と同様に、違和感なくコード決済を利用させることができる。
【0134】
〔6.ハードウェア構成〕
また、上述してきた本実施形態に係る決済サーバ100は、たとえば、
図11に示すような構成のコンピュータ1000によって実現される。
図11は、実施形態に係る決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。
【0135】
コンピュータ1000は、出力装置1010、入力装置1020と接続され、演算装置1030、一次記憶装置1040、二次記憶装置1050、出力IF(Interface)1060、入力IF1070、ネットワークIF1080がバス1090により接続された形態を有する。
【0136】
演算装置1030は、一次記憶装置1040や二次記憶装置1050に格納されたプログラムや入力装置1020から読み出したプログラムなどに基づいて動作し、各種の処理を実行する。一次記憶装置1040は、RAMなど、演算装置1030が各種の演算に用いるデータを一次的に記憶するメモリ装置である。また、二次記憶装置1050は、演算装置1030が各種の演算に用いるデータや、各種のデータベースが登録される記憶装置であり、ROM(Read Only Memory)、HDD、フラッシュメモリ等により実現される。
【0137】
出力IF1060は、モニタやプリンタといった各種の情報を出力する出力装置1010に対し、出力対象となる情報を送信するためのインターフェイスであり、たとえば、USB(Universal Serial Bus)やDVI(Digital Visual Interface)、HDMI(登録商標)(High Definition Multimedia Interface)といった規格のコネクタにより実現される。また、入力IF1070は、マウス、キーボード、およびスキャナなどといった各種の入力装置1020から情報を受信するためのインターフェイスであり、たとえば、USBなどにより実現される。
【0138】
なお、入力装置1020は、たとえば、CD(Compact Disc)、DVD(Digital Versatile Disc)、PD(Phase change rewritable Disk)等の光学記録媒体、MO(Magneto-Optical disk)などの光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリなどから情報を読み出す装置であってもよい。また、入力装置1020は、USBメモリなどの外付け記憶媒体であってもよい。
【0139】
ネットワークIF1080は、ネットワークNを介して他の機器からデータを受信して演算装置1030へ送り、また、ネットワークNを介して演算装置1030が生成したデータを他の機器へ送信する。
【0140】
演算装置1030は、出力IF1060や入力IF1070を介して、出力装置1010や入力装置1020の制御を行う。たとえば、演算装置1030は、入力装置1020や二次記憶装置1050からプログラムを一次記憶装置1040上にロードし、ロードしたプログラムを実行する。
【0141】
たとえば、コンピュータ1000が本実施形態に係る決済サーバ100として機能する場合、コンピュータ1000の演算装置1030は、一次記憶装置1040上にロードされたプログラム(たとえば、情報処理プログラム)を実行することにより、制御部130と同様の機能を実現する。すなわち、演算装置1030は、一次記憶装置1040上にロードされたプログラム(たとえば、情報処理プログラム)との協働により、本実施形態に係る決済サーバ100による処理を実現する。
【0142】
〔7.その他〕
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
【0143】
また、上述した決済サーバ100は、機能によっては外部のプラットフォームなどをAPI(Application Programming Interface)やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。
【0144】
また、特許請求の範囲に記載した「部」は、「手段」や「回路」などに読み替えることができる。例えば、制御部は、制御手段や制御回路に読み替えることができる。
【符号の説明】
【0145】
1 情報処理システム
10 利用者端末
20 店舗端末
100 決済サーバ
110 通信部
120 記憶部
121 口座情報記憶部
122 店舗情報記憶部
123 利用者情報記憶部
130 制御部
131 受付部
132 判定部
133 チャージ部
134 実行部
【手続補正書】
【提出日】2022-05-13
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と前記決済取引による店舗の売上額とを含む取引情報を受け付ける受付部と、
前記売上額が所定の条件を満たす場合、前記決済取引に対応する取引処理を実行する実行部と
を有し、
前記実行部は、
前記売上額の合計が前記店舗ごとに個別に割り当てられる所定の上限金額に満たないことを条件として、前記取引処理を実行する
ことを特徴とする情報処理装置。
【請求項2】
前記所定の上限金額は、
前記店舗の過去の取引履歴に基づいて規定される
ことを特徴とする請求項1に記載の情報処理装置。
【請求項3】
前記受付部は、
前記店舗を識別するための店舗識別情報を含む前記取引情報を前記利用者端末から受け付け、
前記実行部は、
前記店舗識別情報に対応付けられている前記上限金額に基づいて、前記取引処理を実行する
ことを特徴とする請求項1または2に記載の情報処理装置。
【請求項4】
前記受付部は、
前記決済取引が行われた日時を示す日時情報を含む前記取引情報を前記利用者端末から受け付け、
前記実行部は、
前記店舗識別情報により識別される店舗において前記決済取引が有効な状態である期間内に前記決済取引が行われた日時が含まれていることを条件として、前記取引処理を実行する
ことを特徴とする請求項3に記載の情報処理装置。
【請求項5】
前記受付部は、
前記決済取引を行った利用者を識別するための利用者識別情報を含む前記取引情報を前記店舗端末から受け付け、
前記実行部は、
前記利用者識別情報により識別される前記利用者により前記決済取引の事実が承認されることを条件として、前記取引処理を実行する
ことを特徴とする請求項1または2に記載の情報処理装置。
【請求項6】
コンピュータが、
利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と前記決済取引による店舗の売上額とを含む取引情報を受け付ける受付工程と、
前記売上額が所定の条件を満たす場合、前記決済取引に対応する取引処理を実行する実行工程と
を実行し、
前記実行工程は、
前記売上額の合計が前記店舗ごとに個別に割り当てられる所定の上限金額に満たないことを条件として、前記取引処理を実行する
ことを特徴とする情報処理方法。
【請求項7】
コンピュータに、
利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と前記決済取引による店舗の売上額とを含む取引情報を受け付ける受付手順と、
前記売上額が所定の条件を満たす場合、前記決済取引に対応する取引処理を実行する実行手順と
を実行させ、
前記実行手順は、
前記売上額の合計が前記店舗ごとに個別に割り当てられる所定の上限金額に満たないことを条件として、前記取引処理を実行する
ことを特徴とする情報処理プログラム。