JP2023118032A - 情報処理プログラム - Google Patents

Abstract

【課題】コード決済の信頼性を高める情報処理装置、情報処理方法及び情報処理プログラムを提供する。【解決手段】利用者端末、店舗端末及び決済サーバが、ネットワークＮを介して有線又は無線により相互に通信可能に接続される情報処理システムにおいて、情報処理装置である決済サーバは、受付部と、実行部と、を有する。受付部は、利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と決済取引による店舗の売上額とを含む取引情報を受け付ける。実行部は、売上額が所定の条件を満たす場合、決済取引に対応する取引処理を実行する。【選択図】図４

Description

本発明は、情報処理装置、情報処理方法及び情報処理プログラムに関する。

従来、キャッシュレス決済の１つとして、バーコードなどの１次元コードやＱＲコード（登録商標）などの２次元コードを用いた決済（以下、「コード決済」と称する。）が広く利用されている（たとえば、特許文献１参照）。たとえば、店舗に設置された店舗端末が、ユーザ端末に表示される２次元コードからユーザＩＤを読み取り、読み取ったユーザＩＤに対して店舗ＩＤおよび利用金額を付与し、これらの決済情報をサーバに送信することで決済処理が行われる。

特開２０２０－４１２２号公報

しかしながら、上記の従来技術では、コード決済の信頼性を高める上で改善の余地がある。たとえば、店舗ロケーションなどの環境的な要因により通信状況が悪い場合、上述の決済情報をサーバに送信することができず、結果として、コード決済の利用が難しくなる。このように、コード決済の信頼性が高いとは言い切れない状況が起こり得る。

本願は、上記に鑑みてなされたものであって、コード決済の信頼性を高めることができる情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。

本願に係る情報処理装置は、受付部と、実行部とを有する。受付部は、利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と決済取引による店舗の売上額とを含む取引情報を受け付ける。実行部は、売上額が所定の条件を満たす場合、決済取引に対応する取引処理を実行する。

実施形態の一態様によれば、コード決済の信頼性を高めることができるという効果を奏する。

図１は、実施形態に係る情報処理（その１）の一例を示す図である。 図２は、実施形態に係る情報処理（その２）の一例を示す図である。 図３は、実施形態に係る情報処理（その３）の一例を示す図である。 図４は、実施形態に係る決済サーバの構成例を示す図である。 図５は、実施形態に係る口座情報記憶部に記憶される情報の一例を示す図である。 図６は、実施形態に係る店舗情報記憶部に記憶される情報の一例を示す図である。 図７は、実施形態に係る利用者情報記憶部に記憶される情報の一例を示す図である。 図８は、実施形態に係る処理の流れ（その１）の一例を示すシーケンス図である。 図９は、実施形態に係る処理の流れ（その２）の一例を示すシーケンス図である。 図１０は、実施形態に係る決済サーバによる処理手順の一例を示すフローチャートである。 図１１は、実施形態に係る決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に本願に係る情報処理装置、情報処理方法及び情報処理プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法及び情報処理プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．実施形態〕
図１を用いて、実施形態の情報処理装置などにより実現される情報処理について説明する。図１は、実施形態に係る情報処理（その１）の一例を示す図である。なお、図１では、実施形態に係る情報処理装置の一例である決済サーバ１００によって、実施形態に係る情報処理などが実現されるものとする。

（１－１．システム構成）
図１に示すように、実施形態に係る情報処理システム１は、利用者端末１０と、店舗端末２０と、決済サーバ１００とを含む。利用者端末１０、店舗端末２０、及び決済サーバ１００は、ネットワークＮ（例えば、図４参照）を介して有線または無線により相互に通信可能に接続される。ネットワークＮは、例えば、インターネットなどのＷＡＮ（Wide Area Network）である。なお、図１に示した情報処理システム１には、複数の利用者端末１０や、複数の店舗端末２０や、複数の決済サーバ１００が含まれていてもよい。

図１に示す決済サーバ１００は、実施形態に係る情報処理を実行する情報処理装置であり、サーバ装置やクラウドシステムなどにより実現される。たとえば、決済サーバ１００は、コード決済による電子マネーのやり取りを制御する所定の取引手段を提供するサービスに関する情報処理を実行する。

具体的には、決済サーバ１００は、店舗端末用のアプリケーションプログラム（以下、適宜「店舗アプリ」と称する。）を取引対象の提供者である店舗（事業者）に配布する。決済サーバ１００は、店舗アプリ専用のインターフェイスを介して、店舗アプリからの取引要求を受け付けた場合は、その取引要求に従って、口座間における電子マネーの送金処理などを含む情報処理を実行する。なお、電子マネーとは、各種企業が独自に用いるポイントや通貨等であってもよく、日本円やドルなどの国家により提供される貨幣を電子的に取引可能としたものであってもよい。

店舗アプリは、決済先（店舗側）、決済元（利用者側）、及び決済額（店舗側の売上額）などの情報を含む取引情報を決済サーバ１００に送信する。なお、取引情報には、上述の各情報の他、取引を個別に特定するための取引コードや、取引が行われた日時を特定するための日時情報（タイムスタンプ）などの情報が含まれていてもよい。

また、決済サーバ１００は、利用者端末用のアプリケーションプログラム（以下、適宜「ユーザアプリ」と称する。）を、店舗から取引対象の提供を受ける利用者（一般消費者）に配布する。決済サーバ１００は、ユーザアプリ専用のインターフェイスを介して、ユーザアプリからの取引要求を受け付けた場合は、その取引要求に従って、口座間における電子マネーの送金処理などを含む情報処理を実行する。ユーザアプリは、決済先（店舗側）、決済元（利用者側）、及び決済額（店舗側の売上額）などの情報を含む取引情報を決済サーバ１００に送信する。なお、取引情報には、上述の各情報の他、取引を個別に特定するための取引コードや、取引が行われた日時を特定するための日時情報（タイムスタンプ）などの情報が含まれていてもよい。

図１に示す利用者端末１０は、店舗から取引対象の提供を受ける一般消費者である利用者ＵＹによって利用される情報処理装置である。利用者端末１０は、たとえば、スマートフォンや、タブレット型端末、ノート型ＰＣ（Personal Computer）、デスクトップＰＣ、携帯電話機、ＰＤＡ（Personal Digital Assistant）などにより実現される。また、利用者端末１０は、決済サーバ１００によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図１では、利用者端末１０としてスマートフォンを例示している。

図１に示す店舗端末２０は、取引対象を提供する事業を営む事業者ＵＸによって利用される情報処理装置である。店舗端末２０は、たとえば、スマートフォンや、タブレット型端末、ノート型ＰＣ（Personal Computer）、デスクトップＰＣ、携帯電話機、ＰＤＡ（Personal Digital Assistant）などにより実現される。また、店舗端末２０は、決済サーバ１００によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図１では、店舗端末２０としてタブレット型端末を例示している。

なお、利用者端末１０および店舗端末２０は、所定の情報処理を実現する制御情報を決済サーバ１００から受け取った場合には、制御情報に従って情報処理を実現する。ここで、制御情報は、たとえばＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプト言語やＣＳＳ（Cascading Style Sheets）などのスタイルシート言語、Ｊａｖａ（登録商標）などのプログラミング言語、ＨＴＭＬ（HyperText Markup Language）などのマークアップ言語などにより記述される。なお、決済サーバ１００から配信される所定のアプリケーションそのものを制御情報とみなしてもよい。

（１－２．利用者端末１０を用いた決済について）
ここで、決済サーバ１００により実行される情報処理の説明に先立ち、利用者端末１０を用いたコード決済（電子決済）の一例について説明する。なお、以下の説明では、店舗Ｘに配置された２次元コード（ＱＲコード（登録商標））であって、店舗Ｘを識別する店舗識別情報を示す２次元コードＣ－Ｘを用いて、利用者ＵＹが利用者端末１０を用いた決済を行う例について説明するが、実施形態は、これに限定されるものではない。以下に説明するコード決済の一例は、任意の利用者が任意の利用者端末１０を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗識別情報を示す２次元コードＣ－Ｘは、ＱＲコードのみならず、バーコードや所定のマーク、番号などであってもよい。また、２次元コードＣ－Ｘは、紙などの媒体に印字された印刷物により物理的に構成される例に限られず、店舗端末２０に表示される画像情報により構成されていてもよい。

例えば、利用者ＵＹが店舗Ｘにて各種の商品やサービスといった取引対象の購入や利用に伴う決済を行う場合、利用者ＵＹは、利用者端末１０に予めインストールされたユーザアプリ１０ＡＰ（たとえば、図４参照）を起動する。そして、利用者ＵＹは、ユーザアプリ１０ＡＰを介して、店舗Ｘに設置された２次元コードＣ－Ｘを撮影する。このような場合、利用者端末１０は、取引対象の価格を入力するための画面を表示し、利用者ＵＹあるいは店舗Ｘの店員から決済金額の入力を受け付ける。そして、利用者端末１０は、利用者ＵＹを識別する利用者識別情報と、店舗識別情報（もしくは、店舗識別情報が示す情報、すなわち、店舗Ｘを示す情報（たとえば、店舗ＩＤ））と、決済額とを含む取引情報を決済サーバ１００へと送信する。

決済サーバ１００は、利用者端末１０から取引情報を受け付けると、利用者識別情報が示す利用者ＵＹの口座から、店舗識別情報が示す店舗Ｘの口座へと、決済額に相当する分の電子マネーを移行させる。このとき、決済サーバ１００は、決済額に相当する分の電子マネーから店舗Ｘに課金する所定の手数料を差し引いてから、店舗Ｘの口座へ移行させてもよい。そして、決済サーバ１００は、取引が完了した旨の通知を利用者端末１０へと送信する。このような場合、利用者端末１０は、取引が完了した旨の画面や所定の音声を出力することで、電子マネーによる取引が完了した旨を利用者ＵＹに通知する。あるいは、決済サーバ１００は、利用者識別情報が示す利用者ＵＹの口座から決済額に相当する分の電子マネーを引き出して店舗Ｘの売り上げ情報として管理し、所定のタイミングで売上に相当する額の現金を店舗Ｘが保有する銀行口座に振り込んでもよい。この場合、決済サーバ１００は、利用者ＵＹの口座から決済額に相当する分の電子マネーを引き出したタイミングで、電子マネーによる取引が完了した旨を利用者ＵＹに通知してもよい。

なお、利用者端末１０を用いた決済は、上述した処理に限定されるものではない。たとえば、利用者端末１０を用いた決済は、店舗Ｘに設置された店舗端末２０を用いたものであってもよい。具体的には、まず、利用者端末１０は、利用者ＵＹを識別するための利用者識別情報を示すコード情報を画面上に表示させる。このような場合、店舗Ｘに設置された店舗端末２０は、利用者端末１０に表示されたコード情報から利用者識別情報を読み取り、読み取った利用者識別情報（もしくは、利用者識別情報が示す情報、すなわち、利用者ＵＹを示す情報（たとえば、利用者ＩＤ））と、決済額と、店舗Ｘを識別する情報とを含む取引情報を決済サーバ１００へと送信する。

決済サーバ１００は、店舗端末２０から取引情報を受け付けると、利用者識別情報が示す利用者ＵＹの口座から、店舗Ｘの口座へと、決済額に相当する分の電子マネーを移行させる。そして、決済サーバ１００は、店舗端末２０あるいは利用者端末１０に対し、取引が完了した旨の通知を送信する。店舗端末２０あるいは利用者端末１０は、取引が完了した旨の画面や所定の音声を出力することで、電子マネーによる取引が完了した旨を利用者ＵＹに通知する。また、決済サーバ１００は、利用者識別情報が示す利用者ＵＹの口座から決済額に相当する分の電子マネーを引き出して店舗Ｘの売り上げ情報として管理し、所定のタイミングで売上に相当する額の現金を店舗Ｘが保有する銀行口座に振り込んでもよい。この場合、決済サーバ１００は、利用者ＵＹの口座から決済額に相当する分の電子マネーを引き出したタイミングで、電子マネーによる取引が完了した旨を事業者ＵＸあるいは利用者ＵＹに通知してもよい。

また、利用者端末１０を用いた決済は、利用者ＵＹが予め電子マネーをチャージした口座から店舗Ｘの口座へと電子マネーを移行させる処理のみならず、たとえば、利用者ＵＹが予め登録したクレジットカードを用いた決済であってもよい。このような場合、たとえば、利用者端末１０は、店舗Ｘの口座に対して決済金額が示す額の電子マネーを移行させるとともに、利用者ＵＹのクレジットカードの運用会社に対し、決済金額が示す額を請求してもよい。

（１－３．実施形態の概要について）
（１－３－１．情報処理（その１））
従来、店舗ロケーションなどの環境的な要因により、利用者端末１０や店舗端末２０が圏外となり、データ通信ができない状況となった場合、コード決済が利用できなくなってしまう。このように、コード決済の利用は通信状況に左右され、必ずしも信頼性が高いとは言い切れない。

そこで、決済サーバ１００を有する情報処理システム１は、実施形態に係る情報処理（その１）を実行する。以下、図１を用いて、決済サーバ１００を有する情報処理システム１が実行する情報処理（その１）について説明する。図１に示す情報処理（その１）は、利用者端末１０が店舗Ｘに設置された２次元コードＣ－Ｘを読み取ることにより、利用者端末１０を主体としてオフラインで行われる決済に関する取引処理の一例を示している。

なお、以下の説明では、利用者端末１０が利用者ＵＹにより利用される例を示す。また、以下の説明では、利用者端末１０を利用者ＵＹと同一視する場合がある。すなわち、以下では、利用者ＵＹを利用者端末１０と読み替えることもできる。

また、以下の説明では、店舗端末２０が事業者ＵＸにより利用される例を示す。また、以下の説明では、店舗端末２０を事業者ＵＸと同一視する場合がある。すなわち、以下では、事業者ＵＸを店舗端末２０と読み替えることもできる。

また、以下の説明において、店舗Ｘに設置されている２次元コードＣ－Ｘは、店舗識別情報に加えて、オフラインでの決済取引（以下、適宜「オフライン決済」と略称する。）である旨を示す情報を有しているものとする。ここで、実施形態におけるオフライン決済とは、オフライン環境下で行われる予備的な（仕掛りの）決済の取引である。オフライン決済は、事後的に決済サーバ１００において処理される。

まず、店舗端末２０は、決済サーバ１００に対して、オフライン設定の有効化を要求する（ステップＳ１１）。すなわち、事業者ＵＸは、決済サーバ１００に対して、オフラインでの売上処理の有効化を要求する。たとえば、事業者ＵＸは、店舗アプリ上でオフラインでの売上処理を有効化するためのオフライン動作モードを選択する。店舗端末２０は、事業者ＵＸによるオフライン動作モードの選択に応じて、オフライン設定の有効化に関するリクエストを決済サーバ１００に送信する。

決済サーバ１００は、店舗アプリ専用のインターフェイスを介して、店舗端末２０からオフライン設定の有効化に関するリクエストを受け付けると、オフラインでの売上処理における上限金額を設定する（ステップＳ１２）。この上限金金額は、決済サーバ１００により提供されるサービスを営むサービス事業者が、サービス利用者である事業者ＵＸに対してオフラインでの売上を許容する金額の上限である。たとえば、上限金額は、店舗Ｘの過去の取引履歴に基づいて規定される。そして、決済サーバ１００は、オフライン設定の承認通知を店舗端末２０に送信する（ステップＳ１３）。

店舗Ｘのオフライン設定が完了した後、利用者ＵＹが店舗Ｘにより提供される各種の商品やサービスといった取引対象の購入や利用に伴う決済を行う場合、利用者端末１０に予めインストールされたユーザアプリ１０ＡＰを起動する。そして、利用者ＵＹは、ユーザアプリ１０ＡＰを介して、店舗Ｘに設置された２次元コードＣ－Ｘを撮影し、２次元コードＣ－Ｘを読み取る（ステップＳ１４）。

また、利用者端末１０で動作するユーザアプリ１０ＡＰは、２次元コードＣ－Ｘから読み取った情報の中にオフライン決済である旨が含まれる場合、２次元コードＣ－Ｘの読取に連動して、コード決済（以下、単に「決済」と称する。）の取引が完了した旨を利用者ＵＹに通知する（ステップＳ１５）。これにより、利用者ＵＹは、実際の決済が行われていないオフライン環境下であっても、オンライン環境下である場合と同様に、違和感なくコード決済を利用できる。

そして、ユーザアプリ１０ＡＰは、オフライン決済である旨を示す情報に関連付けて、オフライン決済が行われた店舗Ｘを示す店舗識別情報と、オフライン決済が行われた日時（２次元コードＣ－Ｘの読取が行われた日時）を示す日時情報と、オフライン決済による店舗Ｘの売上額を示す情報とを含む取引データ（「取引情報」の一例）を記録する（ステップＳ１６）。図１に示す例では、ユーザアプリ１０ＡＰが記録する取引データとして、オフライン決済である旨に関連付けられた店舗識別情報：「Ｓ＃Ｘ－１」、日時情報：「２０２２／１／１１ １２：３４」、及び売上額：「１，０００円」が示されている。これにより、オフライン環境下で行われた仕掛りの決済に対応する実際の取引処理が決済サーバ１００において事後的に処理可能な状態に連携させることができる。

その後、利用者ＵＹが店舗Ｘから退店する。利用者端末１０を取り巻く環境が、オフライン決済が行われた日時（２次元コードＣ－Ｘの読取が行われた日時）から所定時間以内にオンライン環境となると、ユーザアプリ１０ＡＰは、ステップＳ１６で記録した取引データを決済サーバ１００に伝送する（ステップＳ１７）。たとえば、一実施形態では、オフライン決済が行われた日時から２４時間以内に利用者端末１０がオンライン環境下となった場合に、ステップＳ１６で記録した取引データを決済サーバ１００に伝送する。オフライン決済が行われた日時から２４時間以内に利用者端末１０がオンライン環境下とならなかった場合、オフライン決済（ステップＳ１４～ステップＳ１６）は無効となり、後述の取引処理（ステップＳ１８）は行われない。この場合、決済サーバ１００の管理者である決済サービスの提供事業者が、オフライン決済にかかる売上額を店舗Ｘの口座に補填してもよいし、保険サービス等によって店舗Ｘの売上額を補償してもよい。なお、ユーザアプリ１０ＡＰは、オフライン決済が行われた日時から所定時間以内であれば、任意のタイミングで取引データを決済サーバ１００に伝送できる。たとえば、ユーザアプリ１０ＡＰは、オンライン環境の検出後、即時に取引データを伝送してもよいし、オンライン環境の検出後、一定時間の経過後、取引データを伝送してもよい。また、ユーザアプリ１０ＡＰは、取引データを任意の単位で決済サーバ１００に伝送してもよい。たとえば、ユーザアプリ１０ＡＰは、取引データの履歴を時系列で所定数取りまとめて伝送してもよいし、店舗ごとに取りまとめて伝送してもよい。

決済サーバ１００は、利用者端末１０から取引データを受信すると、受信した取引データに従って、取引データに対応する取引処理を実行する（ステップＳ１８）。たとえば、決済サーバ１００は、オフライン決済による店舗Ｘの売上額が所定の条件を満たす場合、取引データに対応する取引処理を実行する。具体的には、決済サーバ１００は、店舗Ｘの売上額の合計が店舗（事業者）ごとに個別に割り当てられる所定の上限金額に満たないことを条件として、取引データに対応する取引処理を実行する。すなわち、決済サーバ１００は、取引データの送信元である利用者ＵＹ（決済元）の口座から、取引データに示される店舗Ｘ（決済先）の口座へと、店舗Ｘの売上額に相当する分の電子マネーを移行させる。このようにして、決済サーバ１００は、オフライン環境下にある店舗Ｘであっても、利用者ＵＹによるコード決済の利用を実現できる。

なお、上述の情報処理（その１）において、店舗Ｘに設置されている２次元コードＣ－Ｘには、オフライン決済である旨を示す情報を有していなくてもよい。この場合、決済サーバ１００は、利用者端末１０から受信した取引データに含まれる日時情報を参照する。そして、決済サーバ１００は、店舗Ｘにおけるオンライン決済が有効な状態である期間内に２次元コードＣ－Ｘの読取日時が含まれる場合、取引データに対応する取引処理を実行する。これにより、決済サーバ１００は、オフライン決済用の２次元コードの設置などの特段の準備を要することなく、オフライン環境下であっても、オンライン環境下と同様の手続でコード決済を利用できる。

（１－３－２．情報処理（その２））
以下、図２を用いて、決済サーバ１００を有する情報処理システム１が実行する情報処理（その２）について説明する。図２は、実施形態に係る情報処理（その２）の一例を示す図である。図２に示す情報処理（その２）は、店舗端末２０が利用者端末１０に表示されたコード情報を読み取ることにより、店舗端末２０を主体としてオフラインで行われる決済に関する取引処理の一例を示している。なお、図２に示す情報処理（その２）は、ステップＳ３１～ステップＳ３３までの処理が図１に示すステップＳ１１～ステップＳ１３までの処理と同一であるが、ステップＳ３４～ステップＳ３９までの処理が図１に示す情報処理（その１）とは相違する。以下では、図２に示す情報処理（その２）について、図１に示す情報処理（その１）と相違する部分を説明する。

すなわち、利用者ＵＹが各種の商品やサービスといった取引対象の購入や利用に伴う決済を店舗Ｘにて行う場合、利用者ＵＹはユーザアプリ１０ＡＰを起動する。そして、利用者ＵＹは、ユーザアプリ１０ＡＰを操作して、利用者ＵＹを識別するための利用者識別情報を含む２次元コードＣ－Ｙを利用者端末１０に表示させ（ステップＳ３４）、店舗Ｘの店員に提示する。

店舗端末２０で動作する店舗アプリ２０ＡＰ（たとえば、図４参照）は、利用者端末１０に表示された２次元コードＣ－Ｙを読み取る（ステップＳ３５）。たとえば、店舗Ｘの店員は、店舗端末２０に予めインストールされた店舗アプリ２０ＡＰを起動する。そして、店舗Ｘの店員は、店舗アプリ２０ＡＰを介して、利用者端末１０に表示された２次元コードＣ－Ｙを撮影し、２次元コードＣ－Ｙを読み取る。

また、店舗アプリ２０ＡＰは、２次元コードＣ－Ｙの読取を行った際、オフライン設定が有効な状態であることを条件として、２次元コードＣ－Ｙの読取に連動して、決済の取引が完了した旨を示す情報を利用者端末１０に送信する（ステップＳ３６）。たとえば、店舗アプリ２０ＡＰは、利用者端末１０と店舗端末２０との間でデータの送受信が可能な近距離無線通信を用いて、決済の取引が完了した旨を示す情報を利用者端末１０に送信する。また、店舗アプリ２０ＡＰは、オンライン環境下でコード決済を行った場合と同様の画面や所定の音声を店舗端末２０から出力してもよい。これらにより、利用者ＵＹは、実際には決済の取引に関する処理が行われていないオフライン環境下であっても、オンライン環境下である場合と同様に、違和感なくコード決済を利用できる。

そして、店舗アプリ２０ＡＰは、オフライン決済である旨を示す情報に関連付けて、オフライン決済を行った利用者を識別するための利用者識別情報と、オフライン決済が行われた日時（２次元コードＣ－Ｙの読取が行われた日時）を示す日時情報と、オフライン決済による店舗Ｘの売上額を示す情報とを含む取引データ（「取引情報」の一例）を記録する（ステップＳ３７）。図２に示す例では、店舗アプリ２０ＡＰが記録する取引データとして、オフライン決済である旨に関連付けられた利用者識別情報：「Ｕ＃Ｙ－１」、日時情報：「２０２２／１／１１ １２：３４」、及び売上額：「１，０００円」が示されている。

また、利用者端末１０で動作するユーザアプリ１０ＡＰは、店舗端末２０から決済の取引が完了した旨を示す情報を受信した場合、この情報の受信に連動して、決済の取引が完了したことを示す画面や所定の音声を出力して、利用者ＵＹに通知する（ステップＳ３８）。たとえば、ユーザアプリ１０ＡＰは、オンライン環境下でコード決済を行った場合と同様の画面や所定の音声を利用者端末１０から出力できる。

その後、事業者ＵＸ（あるいは店員）が店舗端末２０を所持して店舗Ｘから移動することにより、店舗端末２０を取り巻く環境が、オフライン決済が行われた日時（２次元コードＣ－Ｙの読取が行われた日時）から所定時間以内にオンライン環境になると、店舗アプリ２０ＡＰは、ステップＳ３６で記録した取引データを決済サーバ１００に伝送する（ステップＳ３９）。たとえば、一実施形態では、オフライン決済が行われた日時から２４時間以内に店舗端末２０がオンライン環境下となった場合に、ステップＳ３７で記録した取引データを決済サーバ１００に伝送する。オフライン決済が行われた日時から２４時間以内に店舗端末２０がオンライン環境下とならなかった場合、オフライン決済（ステップＳ３５～ステップＳ３７）は無効となり、後述の取引処理（ステップＳ４０）は行われない。この場合、決済サーバ１００の管理者である決済サービスの提供事業者が、オフライン決済にかかる売上額を店舗Ｘの口座に補填してもよいし、保険サービス等によって店舗Ｘの売上額を補償してもよい。なお、店舗アプリ２０ＡＰは、オフライン決済が行われた日時から所定時間以内であれば、任意のタイミングで取引データを決済サーバ１００に伝送できる。たとえば、店舗アプリ２０ＡＰは、オンライン環境の検出後、即時に取引データを伝送してもよいし、オンライン環境の検出後、一定時間の経過後、取引データを伝送してもよい。また、店舗アプリ２０ＡＰは、取引データを任意の単位で決済サーバ１００に伝送してもよい。たとえば、店舗アプリ２０ＡＰは、取引データの履歴を時系列で所定数取りまとめて伝送してもよい。

決済サーバ１００は、店舗端末２０から取引データを受信すると、受信した取引データに従って、取引データに対応する取引処理を実行する（ステップＳ４０）。たとえば、決済サーバ１００は、取引データに基づいて、取引データに示される利用者ＵＹ（決済元）の口座から、取引データに示される店舗Ｘ（決済先）の口座へと、店舗Ｘの売上額に相当する分の電子マネーを移行させる。

なお、上述の情報処理（その２）において、決済サーバ１００は、店舗端末２０から取引データを受信した場合、取引データに含まれる利用者識別情報に基づいて、利用者識別情報により識別される利用者ＵＹに対し、実際にオフラインでの決済取引を行ったか否かの事実確認を行ってもよい。たとえば、決済サーバ１００は、店舗端末２０から取引データを受信した場合、利用者ＵＹが使用する利用者端末１０に対して確認通知を送信する。そして、決済サーバ１００は、利用者ＵＹにより、オフラインでの決済取引の事実が承認されることを条件として、取引データに対応する取引処理を実行する。これにより、決済サーバ１００は、オフライン環境下であっても、コード決済の信頼性を担保できる。

（１－３－３．情報処理（その３））
従来、利用者が予め自らのアカウントにチャージしたマネー残高を用いてコード決済を行う場合、残高を適宜チャージする必要があり、利用者に対して少なからず手間をかけさせることになる。また、事情により、電子マネーを即時チャージできない場合、コード決済そのものが利用できなくなってしまう。このように、従来のコード決済には、ユーザビリティを高める上で改善の余地がある。

そこで、決済サーバ１００を有する情報処理システム１は、実施形態に係る情報処理（その３）を実行する。たとえば、決済サーバ１００は、利用者（たとえば、利用者ＵＹ）の置かれる状態が所定の条件を満たしているか否かを判定し、利用者の置かれる状態が所定の条件を満たしていると判定した場合、利用者に割り当てられたアカウントに対して電子マネーの自動チャージを実行する。

以下、図３を用いて、決済サーバ１００を有する情報処理システム１が実行する情報処理（その３）について具体的に説明する。図３は、実施形態に係る情報処理（その３）の一例を示す図である。図３では、利用者ＵＹの置かれる状態の一例として地震（「災害」の一例）の発生を例示しているが、地震に限らず、利用者ＵＹによるチャージが困難となる可能性があるその他の災害の発生やイベントの発生を含み得る。なお、図３に示す情報処理（その３）は、ステップＳ５１～ステップＳ５４までの処理が、図１に示す情報処理（その１）や図２に示す情報処理（その２）とは相違する。以下では、図３に示す情報処理（その３）について、図１に示す情報処理（その１）や図２に示す情報処理（その２）と相違する部分を説明する。

まず、利用者ＵＹは、決済サーバ１００に対して、自動チャージサービスの申込を行う（ステップＳ５１）。自動チャージサービスは、利用者ＵＹの置かれる状態が所定の条件を満たしていると判定した場合、利用者ＵＹに割り当てられたアカウントに対して電子マネーを自動的にチャージするサービスである。サービス利用者は、たとえば、自動チャージサービスを利用するための利用代金を毎月支払う。決済サーバ１００は、サービス利用者から毎月支払われる利用代金をサービス利用者ごとに積み立てる。決済サーバ１００は、サービス利用者ごとに積み立てた金額を原資として、電子マネーの自動チャージを実行する。なお、自動チャージサービスの利用代金は、月賦払いに限られず、一時払いなどの任意の支払方法を選択可能に構成されてもよい。

また、決済サーバ１００は、自動チャージサービスの利用条件として、ユーザアプリ１０ＡＰによる位置追跡の許可を含めることができる。これにより、決済サーバ１００は、利用者ＵＹが使用する利用者端末１０の位置を特定できる。

一方、決済サーバ１００は、利用者ＵＹからの自動チャージサービスの申込を受け付ける（ステップＳ５２）。たとえば、決済サーバ１００は、利用者ＵＹに割り当てられたアカウントに対する自動チャージサービスの設定を有効化する。

ここで、地震の発生を検知すると、決済サーバ１００は、利用者ＵＹの置かれる状態が所定の条件を満たしているか否かを判定する（ステップＳ５３）。たとえば、決済サーバ１００は、地震が発生した場合、利用者ＵＹの位置と地震発生エリアとの間の距離が所定の距離範囲内にあるか否かを判定する。決済サーバ１００は、利用者端末１０から取得する位置情報に基づいて利用者ＵＹの位置を特定する。

そして、決済サーバ１００は、利用者ＵＹの位置と地震発生エリアとの間の距離が所定の距離範囲内にあると判定された場合、利用者ＵＹに紐付くアカウントに対して電子マネーの自動チャージを実行する（ステップＳ５４）。これにより、決済サーバ１００は、地震の発生によりマネー残高のチャージが困難な状況となる可能性がある利用者ＵＹについて、残高不足によりコード決済が利用できなくなる事態を回避できる。なお、電子マネーのチャージ額は、自動チャージサービスを利用する全てのサービス利用者に共通の金額であってもよいし、サービス利用者ごとに個別に決定された金額であってもよい。

また、決済サーバ１００は、利用者ＵＹの置かれる状態として、利用者ＵＹのマネー残高が所定額未満であるか否かを判定してもよい。この場合、決済サーバ１００は、たとえば、マネー残高が所定値未満であると判定した場合、電子マネーの自動チャージを実行する。これにより、決済サーバ１００は、コード決済の利用時にマネー残高が不足する可能性がある利用者ＵＹについて、残高不足によりコード決済が利用できなくなる事態を回避できる。なお、決済サーバ１００は、利用者ＵＹの位置と地震発生エリアとの間の距離が所定の距離範囲内にあると判定された場合、さらに、利用者ＵＹのマネー残高が所定額未満であるか否かを判定してもよい。

また、決済サーバ１００は、予め規定されているチャージ可能額に基づいて、電子マネーの自動チャージを実行する。決済サーバ１００は、チャージ可能額に相当する額の電子マネーを自動チャージできる。たとえば、チャージ可能額は、サービス利用者ごとに個別に規定されてもよい。これにより、決済サーバ１００は、チャージ可能額の範囲内でリスクヘッジを行いつつ、残高不足によりコード決済が利用できなくなる事態をできるだけ回避できる。

〔２．決済サーバの構成〕
次に、図４を用いて、決済サーバ１００の構成について説明する。図４は、実施形態に係る決済サーバの構成例を示す図である。図４に示すように、決済サーバ１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。

（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。そして、通信部１１０は、ネットワークＮと有線または無線で接続され、利用者端末１０や、店舗端末２０などとの間で情報の送受信を行う。

（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図４に示すように、記憶部１２０は、口座情報記憶部１２１と、店舗情報記憶部１２２と、利用者情報記憶部１２３とを有する。

（口座情報記憶部１２１について）
口座情報記憶部１２１は、利用者（一般消費者）や店舗（事業者）などのサービス利用者が電子決済サービスにおいて所有する口座に関する各種の情報を記憶する。ここで、図５を用いて、口座情報記憶部１２１が記憶する情報の一例を説明する。図５は、実施形態に係る口座情報記憶部に記憶される情報の一例を示す図である。図５の例において、口座情報記憶部１２１は、「口座ＩＤ」や、「所有者ＩＤ」や、「総残高（円）」などといった複数の項目を有する。

「口座ＩＤ」の項目には、口座を識別するための識別情報が記憶される。「所有者情報」の項目は、口座を所有する所有者を識別するための識別情報が記憶される。なお、「所有者情報」の項目には、後述するユーザＩＤが記憶されてもよい。「口座残高（円）」の項目には、口座の残高を示す情報が記憶される。残高を示す情報として、たとえば、電子マネーに相当する現金の額が記憶される。

すなわち、図５では、口座ＩＤ「ＡＣ＃１」によって識別される口座の所有者の情報が「Ｓ＃Ｘ－１」であり、総残高が「１，１５０，０００（円）」である例が示されている。

（店舗情報記憶部１２２について）
店舗情報記憶部１２２は、店舗のオフライン設定に関する情報が記憶される。ここで、図６を用いて、店舗情報記憶部１２２が記憶する情報の一例を説明する。図６は、実施形態に係る店舗情報記憶部に記憶される情報の一例を示す図である。図６の例において、店舗情報記憶部１２２は、「店舗ＩＤ」や、「オフライン設定」や、「上限金額（円）」などといった複数の項目を有する。

「店舗ＩＤ」の項目には、商品やサービスなどの取引対象を一般消費者に提供する事業者により運営される店舗を識別するための店舗識別情報が記憶される。「オフライン設定」の項目には、オフライン決済（オフラインでの売上処理）が有効な状態か否かを示す情報が記憶される。「上限金額（円）」の項目には、オフライン環境上でコード決済を受け付けることが可能な上限金額を示す情報が記憶される。なお、決済サーバ１００を通じて電子決済サービスを提供するサービス事業者は、店舗に対して上限金額の項目に設定されている金額を補償する。

すなわち、図６では、店舗ＩＤ「Ｓ＃Ｘ－１」によって識別される店舗のオフライン設定は有効な状態であり、上限金額である「１００，０００（円）」までオフライン決済が可能であることが示されている。

（利用者情報記憶部１２３について）
利用者情報記憶部１２３は、決済サーバ１００が提供する電子決済サービスの利用者に関する各種の情報を記憶する。ここで、図７を用いて、利用者情報記憶部１２３が記憶する情報の一例を説明する。図７は、実施形態に係る利用者情報記憶部に記憶される情報の一例を示す図である。図７の例において、利用者情報記憶部１２３は、「利用者ＩＤ」や、「自動チャージ設定」や、「チャージ可能額（円）」などといった複数の項目を有する。

「利用者ＩＤ」の項目には、利用者を識別するための利用者識別情報が記憶される。「自動チャージ設定」の項目には、自動チャージサービスが有効な状態か否を示す情報が記憶される。「チャージ可能額（円）」の項目には、自動チャージサービスによるチャージ可能額を示す情報が記憶される。

すなわち、図７では、利用者ＩＤ「Ｕ＃Ｙ－１」によって識別される利用者について、自動チャージサービスが有効な状態であり、自動チャージサービスによるチャージ可能額が「３０，０００（円）」であることが示されている。

（制御部１３０について）
制御部１３０は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などによって、決済サーバ１００内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、たとえば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの集積回路により実現され得る。実施形態に係る制御部１３０は、図４に示すように、受付部１３１と、判定部１３２と、チャージ部１３３と、実行部１３４とを有し、これらの各部により、以下に説明する情報処理の機能や作用を実現または実行する。

（受付部１３１について）
受付部１３１は、利用者端末１０または店舗端末２０からオフラインでの決済取引である旨を示す情報と、決済取引による店舗（たとえば、図１または図２に示す店舗Ｘ）の売上額とを含む取引データ（「取引情報」の一例）を受け付ける。受付部１３１は、利用者端末１０または店舗端末２０から受け付けた取引データを実行部１３４に受け渡す。

また、受付部１３１は、店舗（たとえば、店舗Ｘ）を識別するための店舗識別情報を含む取引データを利用者端末１０から受け付ける。また、受付部１３１は、決済取引が行われた日時を示す日時情報を含む取引データを利用者端末１０から受け付ける。受付部１３１は、利用者端末１０から受け付けた取引データを実行部１３４に受け渡す。

また、受付部１３１は、決済取引を行った利用者（たとえば、図２に示す利用者ＵＹ）を識別するための利用者識別情報を含む取引データを店舗端末２０から受け付ける。受付部１３１は、利用者端末１０から受け付けた取引データを実行部１３４に受け渡す。

（判定部１３２について）
判定部１３２は、電子決済サービスのサービス利用者（たとえば、図３に示す利用者ＵＹ）の置かれる状態が所定の条件を満たしているか否かを判定する。

たとえば、判定部１３２は、災害が発生した場合、サービス利用者の位置と災害発生エリアとの間の距離が所定の距離範囲内にあるか否かを判定する。具体的には、判定部１３２は、地震の発生を検知すると、利用者情報記憶部１２３に記憶されている情報を参照して、自動チャージサービスのサービス利用者を抽出する。つまり、判定部１３２は、利用者情報記憶部１２３に記憶されている情報において、自動チャージ設定が有効な状態であるサービス利用者を特定する。次に、判定部１３２は、抽出したサービス利用者の中から、処理対象とするサービス利用者を選択する。次に、判定部１３２は、選択したサービス利用者の位置を特定し、特定した位置と地震発生エリアとの距離を推定する。なお、判定部１３２は、サービス利用者の位置と地震発生エリアとの距離を推定する場合、サービス利用者の位置と、地震発生エリアにおいて震度が最も高いエリアとの距離を推定してもよい。あるいは、判定部１３２は、サービス利用者の位置と地震発生エリアとの間の最短距離を推定してもよい。そして、判定部１３２は、推定した距離が予め規定される閾値以下であるか否かを判定する。

また、たとえば、判定部１３２は、サービス利用者のマネー残高が所定額未満であるか否かを判定する。判定部１３２は、判定結果をチャージ部１３３に受け渡す。

（チャージ部１３３について）
チャージ部１３３は、判定部１３２によりサービス利用者（たとえば、図３に示す利用者ＵＹ）の置かれる状態が所定の条件を満たしていると判定された場合、サービス利用者に割り当てられたアカウントに対して電子マネーの自動チャージを実行する。

たとえば、チャージ部１３３は、自動チャージ設定が有効であるサービス利用者について、予め規定された自動チャージサービスを利用するための月額料金から所定の手数料を控除した金額を、サービス利用者ごとに積み立てる。また、チャージ部１３３は、判定部１３２によりサービス利用者の位置と災害発生エリアとの間の距離が所定の距離範囲内にあると判定された場合、サービス利用者ごとに積み立てた積立金額の中から自動チャージを実行する。たとえば、チャージ部１３３は、積立金額の中から、予め規定されているチャージ可能額に基づいて自動チャージを実行できる。また、たとえば、チャージ部１３３は、判定部１３２によりマネー残高が所定値未満であると判定された場合、自動チャージを実行する。

（実行部１３４について）
実行部１３４は、オフライン決済による店舗の売上額が所定の条件を満たす場合、オフライン決済に対応する取引処理を実行する。たとえば、実行部１３４は、店舗の売上額の合計が店舗ごとに個別に割り当てられる所定の上限金額に満たないことを条件として、オフライン決済に対応する取引処理を実行する。具体的には、実行部１３４は、該当店舗についてオフライン決済が有効な状態であり、かつ、オフライン決済における売上額の合計額が所定の上限金額未満であり、かつ、利用者端末１０からの取引データが所定の時間内に受信された場合、オフライン決済に対応する取引処理を実行する。つまり、決済サーバ１００は、オフライン決済が有効である場合、所定時間内に受信した取引データについて、所定の条件金額に達するまでオフライン決済を受け入れ可能である。

なお、実行部１３４は、店舗の過去の取引履歴に基づいて、オフライン決済の上限金額を店舗ごとに決定できる。具体的には、実行部１３４は、店舗の過去の取引履歴から、所定期間における平均売上額を算出し、算出した平均売上額を上限金額に決定してもよいし、所定期間における売上額の中央値を特定し、特定した中央値を上限金額に決定してもよい。実行部１３４は、決定した上限金額を店舗識別情報に対応付けて店舗情報記憶部１２２に登録する。

また、実行部１３４は、店舗情報記憶部１２２に記憶されている情報において、利用者端末１０からの取引データに含まれる店舗識別情報に対応付けられている上限金額を参照し、この上限金額に基づいて取引処理を実行する。

また、実行部１３４は、利用者端末１０からの取引データに含まれる日時情報からオフライン決済が行われた日時を特定し、特定した日時が、取引データに含まれる店舗識別情報により識別される店舗においてオフライン決済が有効な状態である期間内に含まれていることを条件として、オフライン決済に対応する取引処理を実行してもよい。

また、実行部１３４は、店舗端末２０からの取引データに含まれる利用者識別情報により識別される利用者によりオフライン決済の事実が承認されることを条件として、オフライン決済に対応する取引処理を実行してもよい。

〔３．処理手順例〕
（３－１．処理の流れ（その１））
以下、実施形態に係る決済サーバ１００を有する情報処理システムにおける処理の流れを説明する。まず、図８を用いて、実施形態に係る処理の流れ（その１）について説明する。図８は、実施形態に係る処理の流れ（その１）の一例を示すシーケンス図である。

図８に示すように、店舗端末２０は、決済サーバ１００に対して、オフライン設定要求を送信する（ステップＳ１０１）。

一方、決済サーバ１００は、店舗端末２０からオフライン設定要求を受信すると、店舗端末２０に紐付く店舗Ｘの上限金額を設定する（ステップＳ１０２）。そして、決済サーバ１００は、店舗Ｘのオフライン設定をアクティベートし、オフライン設定の承認通知を店舗端末２０に送信する（ステップＳ１０３）。

その後、利用者端末１０の利用者がオフライン環境下にある店舗Ｘに入店し、店舗Ｘから取引対象の提供を受けるために、利用者端末１０を主体とするコード決済を行うと仮定する。この場合、利用者端末１０は、利用者の操作に従って、たとえば店舗Ｘに設置されている２次元コードを読み取る（ステップＳ１０４）。

また、利用者端末１０は、２次元コードから読み取った情報の中にオフライン決済である旨が含まれる場合、２次元コードの読取に連動して、決済の取引が完了した旨を利用者ＵＹに通知する（ステップＳ１０５）。

また、利用者端末１０は、オフライン決済である旨を示す情報に関連付けて、オフライン決済が行われた店舗Ｘを示す店舗識別情報と、２次元コードの読取日時を示す日時情報と、オフライン決済による店舗Ｘの売上額を示す情報とを含む取引データを記録する（ステップＳ１０６）。

その後、利用者端末１０の利用者が店舗Ｘから退店する。対象取引において２次元コードが読み取られた日時（ステップ１０６）から所定時間以内に利用者端末１０を取り巻く環境がオンライン環境となると、利用者端末１０は、ステップＳ１０６で記録した取引データを決済サーバ１００に伝送する（ステップＳ１０７）。

決済サーバ１００は、利用者端末１０から取引データを受信すると、受信した取引データに従って、取引データに対応する取引処理を実行する（ステップＳ１０８）。

（３－２．処理の流れ（その２））
続いて、図９を用いて、実施形態に係る処理の流れ（その２）について説明する。図９は、実施形態に係る処理の流れ（その２）の一例を示すシーケンス図である。

図９に示すように、店舗端末２０は、決済サーバ１００に対して、オフライン設定要求を送信する（ステップＳ２０１）。

一方、決済サーバ１００は、店舗端末２０からオフライン設定要求を受信すると、店舗端末２０に紐付く店舗Ｘの上限金額を設定する（ステップＳ２０２）。そして、決済サーバ１００は、店舗Ｘのオフライン設定をアクティベートし、オフライン設定の承認通知を店舗端末２０に送信する（ステップＳ２０３）。

その後、利用者端末１０の利用者がオフライン環境下にある店舗Ｘに入店し、店舗Ｘから取引対象の提供を受けるために、店舗端末２０を主体とするコード決済を行うと仮定する。この場合、利用者端末１０は、利用者の操作に従って、利用者を識別するための利用者識別情報を含むコード情報を利用者端末１０に表示させ（ステップＳ２０４）、店舗Ｘの店員に提示する。

店舗端末２０は、利用者端末１０に表示されたコード情報を読み取る（ステップＳ２０５）。

また、店舗端末２０は、利用者端末１０に表示されたコード情報の読取を行った際、オフライン設定が有効な状態であることを条件として、コード情報の読取に連動して、決済の取引が完了した旨を示す取引完了通知を利用者端末１０に送信する（ステップＳ２０６）。

また、店舗端末２０は、オフライン決済である旨を示す情報に関連付けて、オフライン決済を行った利用者を識別するための利用者識別情報と、コード情報の読取日時を示す日時情報と、オフライン決済による店舗Ｘの売上額を示す情報とを含む取引データを記録する（ステップＳ２０７）。

一方、利用者端末１０は、店舗端末２０から決済の取引が完了した旨を示す取引完了通知を受信した場合、この通知の受信に連動して、決済の取引が完了したことを示す画面や所定の音声を出力して、利用者ＵＹに通知する（ステップＳ２０８）。

その後、店舗Ｘを運営する事業者ＵＸ（あるいは店員）が店舗端末２０を所持して店舗Ｘから移動する。対象取引においてコード情報が読み取られた日時（ステップＳ２０７）から所定時間以内に、店舗端末２０を取り巻く環境がオンライン環境になると、店舗端末２０は、ステップＳ２０７で記録した取引データを決済サーバ１００に伝送する（ステップＳ２０９）。

決済サーバ１００は、店舗端末２０から取引データを受信すると、受信した取引データに従って、取引データに対応する取引処理を実行する（ステップＳ２１０）。

（３－３．決済サーバによる処理手順例）
続いて、図１０を用いて、実施形態に係る決済サーバ１００による処理手順の一例について説明する。図１０は、実施形態に係る決済サーバによる処理手順の一例を示すフローチャートである。図１０に示す処理手順は、決済サーバ１００の制御部１３０により繰り返し実行される。

図１０に示すように、判定部１３２は、地震の発生を検知すると（ステップＳ３０１）、利用者情報記憶部１２３に記憶されている情報を参照して、自動チャージ設定が有効な状態であるサービス利用者を抽出する（ステップＳ３０２）。

また、判定部１３２は、ステップＳ３０２で抽出したサービス利用者の中から、処理対象となるサービス利用者を選択する（ステップＳ３０３）。

また、判定部１３２は、ステップＳ３０３で選択したサービス利用者の位置を特定し、特定した位置と地震発生エリアとの距離Ｄを推定する（ステップＳ３０４）。

また、判定部１３２は、ステップＳ３０４で推定した距離Ｄが予め規定される閾値ＴＨ１以下であるか否かを判定する（ステップＳ３０５）。

また、判定部１３２は、ステップＳ３０４で推定した距離Ｄが閾値ＴＨ１以下であると判定した場合（ステップＳ３０５：Ｙｅｓ）、口座情報記憶部１２１に記憶されている情報を参照して、ステップＳ３０３で選択したサービス利用者のマネー残高が閾値ＴＨ２以下であるか否かを判定する（ステップＳ３０６）。

判定部１３２により、ステップＳ３０３で選択したサービス利用者のマネー残高が閾値ＴＨ２以下であると判定された場合（ステップＳ３０６：Ｙｅｓ）、チャージ部１３３は、ステップＳ３０３で選択したサービス利用者に紐付くアカウントに対し、予め規定されているチャージ可能額に基づいて電子マネーの自動チャージを実行する（ステップＳ３０７）。

また、判定部１３２は、ステップＳ３０２で抽出したサービス利用者について処理を完了したか否かを判定する（ステップＳ３０８）。

判定部１３２は、ステップＳ３０２で抽出したサービス利用者について処理を完了していないと判定した場合（ステップＳ３０８：Ｎｏ）、上述したステップＳ３０３の処理手順に戻って、次の処理対象とするサービス利用者を選択する。これとは反対に、判定部１３２は、ステップＳ３０２で抽出したサービス利用者について処理を完了していると判定した場合（ステップＳ３０８：Ｙｅｓ）、図１０に示す処理手順を終了する。

また、上述のステップＳ３０６において、判定部１３２は、ステップＳ３０３で選択したサービス利用者のマネー残高が閾値ＴＨ２以下であると判定した場合（ステップＳ３０６：Ｎｏ）、上述のステップＳ３０８の処理手順に移行する。

また、上述のステップＳ３０５において、判定部１３２は、ステップＳ３０４で推定した距離Ｄが閾値ＴＨ１以下ではないと判定した場合（ステップＳ３０５：Ｎｏ）、上述のステップＳ３０８の処理手順に移行する。

なお、図１０に示す処理手順において、ステップＳ３０５の処理手順とステップＳ３０６の処理手順は、図１０に示す順序を実行する場合に限られず、ステップＳ３０６の処理手順を実行した後、ステップＳ３０５の処理手順を実行してもよい。また、図１０に示す処理手順は、ステップＳ３０６の処理手順を含まなくてもよい。また、図１０に示す処理手順は、ステップＳ３０４およびステップＳ３０５の処理手順を含まなくてもよい。

〔４．変形例〕
（４－１．取引データの突合処理について）
上述の実施形態は一例を示したものであり、種々の変更及び応用が可能である。たとえば、上述の実施形態において、利用者端末１０が主体となるオフライン決済（ユーザ決済）を行った場合も、店舗端末２０が主体となって行うオフライン決済（ストア決済）を行った場合も、利用者端末１０と店舗端末２０との間で取引データをやり取りすることにより、互いに共有してもよい。この場合、決済サーバ１００は、利用者端末１０から取引データを先に受信した場合、取引データに含まれる利用者識別情報に対応するアカウントに紐づくマネー残高のうち、取引データに含まれる決済額に相当する分の電子マネーを取引保留状態として一時的に留保できる。その後、決済サーバ１００は、店舗端末２０から取引データを受信すると、利用者端末１０から受信した取引データと、店舗端末２０から受信した取引データとを突合することにより、取引内容に問題がない場合、取引保留状態を解除して、取引処理を実行する。

（４－２．取引データの伝送期限について）
たとえば、上述の実施形態において、店舗Ｘにおいてオフライン決済が発生してから、所定時間内（たとえば、２４時間以内）に決済サーバ１００に伝送されなかった取引データは無効にしてもよい。この場合、決済サーバ１００は、たとえば、店舗Ｘにおいてオフライン決済が発生してから所定時間を超えて店舗端末２０から伝送された取引データを破棄する。そして、決済サーバ１００は、取引保留状態として一時的に留保していた利用者の電子マネーを、該当の利用者に紐付くアカウントに返金する。

（４－３．情報処理システム１の構成について）
上述の実施形態では、情報処理システム１に含まれる決済サーバ１００が、オフライン決済に対応する取引処理を行うとともに、サービス利用者に対する自動チャージを実行する例を説明したが、実施形態に係る情報処理システム１の構成は、このような例には特に限定される必要はない。たとえば、実施形態に係る情報処理システム１は、オフライン決済に対応する取引処理を行うサーバと、サービス利用者に対する自動チャージを実行するサーバとは、それぞれ物理的に異なるサーバであってもよく、あるいは、それぞれのサーバが異なるシステムに属するサーバであってもよい。

（４－４．処理態様について）
上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、逆に、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

また、上記してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

〔５．効果〕
上述してきたように、実施形態に係る決済サーバ１００は、受付部１３１と、実行部１３４とを有する。受付部１３１は、利用者端末１０または店舗端末２０からオフラインでの決済取引である旨を示す情報と決済取引による店舗の売上額とを含む取引情報を受け付ける。実行部１３４は、売上額が所定の条件を満たす場合、決済取引に対応する取引処理を実行する。

これにより、実施形態に係る決済サーバ１００は、オフライン環境下にある店舗であっても、利用者ＵＹによるコード決済の利用を実現できる。この結果、決済サーバ１００は、コード決済の信頼性を高めることができる。

また、実施形態に係る決済サーバ１００において、実行部１３４は、売上額の合計が店舗ごとに個別に割り当てられる所定の上限金額に満たないことを条件として、取引処理を実行する。

また、実施形態に係る決済サーバ１００において、上限金額は、店舗の過去の取引履歴に基づいて規定される。

これらにより、決済サーバ１００は、リスクヘッジを行いつつ、コード決済の信頼性を高めることができる。

また、実施形態に係る決済サーバ１００において、受付部１３１は、店舗を識別するための店舗識別情報を含む取引情報を利用者端末１０から受け付ける。実行部１３４は、店舗識別情報に対応付けられている上限金額に基づいて、取引処理を実行する。これにより、決済サーバ１００は、利用者端末１０を主体するオフライン決済に対応する取引処理を実行できる。

また、実施形態に係る決済サーバ１００において、受付部１３１は、決済取引が行われた日時を示す日時情報を含む取引情報を利用者端末１０から受け付ける。実行部１３４は、店舗識別情報により識別される店舗において決済取引が有効な状態である期間内に決済取引が行われた日時が含まれていることを条件として、取引処理を実行する。これにより、決済サーバ１００は、オフライン決済を利用する店舗にオフライン決済用の２次元コードの設置などの特段の準備を要することなく、オフライン環境下であっても、オンライン環境下と同様の手続でコード決済を利用できる。

また、実施形態に係る決済サーバ１００において、受付部１３１は、決済取引を行った利用者を識別するための利用者識別情報を含む取引情報を店舗端末２０から受け付ける。実行部１３４は、利用者識別情報により識別される利用者により決済取引の事実が承認されることを条件として、取引処理を実行する。これにより、決済サーバ１００は、店舗端末２０を主体とするコード決済の信頼性を担保できる。

また、実施形態に係る情報処理システム１において、利用者端末１０で動作するユーザアプリは、利用者端末１０に、コード情報から読み取った情報の中にオフラインでの決済取引である旨が含まれる場合、コード情報の読取に連動して決済取引が完了した旨を利用者に通知する手順を実行させる。

また、実施形態に係る情報処理システム１において、ユーザアプリは、利用者端末１０に、オフラインでの決済取引である旨を示す情報に関連付けて、決済取引が行われた店舗を示す店舗識別情報と、決済取引が行われた日時を示す日時情報と、決済取引による店舗の売上額を示す情報とを含む取引情報を記録する手順を実行させる。

これらにより、ユーザアプリは、利用者に対して、実際には決済の取引に関する処理が行われていないオフライン環境下であっても、オンライン環境下である場合と同様に、違和感なくコード決済を利用させることができる。

また、実施形態に係る情報処理システム１において、店舗端末２０で動作する店舗アプリは、利用者端末１０に表示されるコード情報を読み取った際、オフラインでの売上処理が有効な状態であることを条件として、コード情報の読取に連動してオフラインでの決済取引が完了した旨を利用者に通知する手順を実行させる。

また、実施形態に係る情報処理システム１において、店舗アプリは、オフラインでの決済取引である旨を示す情報に関連付けて、決済取引を行った利用者を識別するための利用者識別情報と、決済取引が行われた日時を示す日時情報と、決済取引による店舗の売上額を示す情報とを含む取引情報を記録する。

また、実施形態に係る情報処理システム１において、店舗アプリは、店舗端末に、近距離無線通信により、決済が完了した旨を示す情報を利用者端末１０に送信する手順を実行させる。

これらにより、店舗アプリは、利用者に対して、実際の決済が行われていないオフライン環境下であっても、オンライン環境下である場合と同様に、違和感なくコード決済を利用させることができる。

〔６．ハードウェア構成〕
また、上述してきた本実施形態に係る決済サーバ１００は、たとえば、図１１に示すような構成のコンピュータ１０００によって実現される。図１１は、実施形態に係る決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

コンピュータ１０００は、出力装置１０１０、入力装置１０２０と接続され、演算装置１０３０、一次記憶装置１０４０、二次記憶装置１０５０、出力ＩＦ（Interface）１０６０、入力ＩＦ１０７０、ネットワークＩＦ１０８０がバス１０９０により接続された形態を有する。

演算装置１０３０は、一次記憶装置１０４０や二次記憶装置１０５０に格納されたプログラムや入力装置１０２０から読み出したプログラムなどに基づいて動作し、各種の処理を実行する。一次記憶装置１０４０は、ＲＡＭなど、演算装置１０３０が各種の演算に用いるデータを一次的に記憶するメモリ装置である。また、二次記憶装置１０５０は、演算装置１０３０が各種の演算に用いるデータや、各種のデータベースが登録される記憶装置であり、ＲＯＭ（Read Only Memory)、ＨＤＤ、フラッシュメモリ等により実現される。

出力ＩＦ１０６０は、モニタやプリンタといった各種の情報を出力する出力装置１０１０に対し、出力対象となる情報を送信するためのインターフェイスであり、たとえば、ＵＳＢ（Universal Serial Bus）やＤＶＩ（Digital Visual Interface）、ＨＤＭＩ（登録商標）（High Definition Multimedia Interface）といった規格のコネクタにより実現される。また、入力ＩＦ１０７０は、マウス、キーボード、およびスキャナなどといった各種の入力装置１０２０から情報を受信するためのインターフェイスであり、たとえば、ＵＳＢなどにより実現される。

なお、入力装置１０２０は、たとえば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）などの光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリなどから情報を読み出す装置であってもよい。また、入力装置１０２０は、ＵＳＢメモリなどの外付け記憶媒体であってもよい。

ネットワークＩＦ１０８０は、ネットワークＮを介して他の機器からデータを受信して演算装置１０３０へ送り、また、ネットワークＮを介して演算装置１０３０が生成したデータを他の機器へ送信する。

演算装置１０３０は、出力ＩＦ１０６０や入力ＩＦ１０７０を介して、出力装置１０１０や入力装置１０２０の制御を行う。たとえば、演算装置１０３０は、入力装置１０２０や二次記憶装置１０５０からプログラムを一次記憶装置１０４０上にロードし、ロードしたプログラムを実行する。

たとえば、コンピュータ１０００が本実施形態に係る決済サーバ１００として機能する場合、コンピュータ１０００の演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラム（たとえば、情報処理プログラム）を実行することにより、制御部１３０と同様の機能を実現する。すなわち、演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラム（たとえば、情報処理プログラム）との協働により、本実施形態に係る決済サーバ１００による処理を実現する。

〔７．その他〕
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述した決済サーバ１００は、機能によっては外部のプラットフォームなどをＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。

また、特許請求の範囲に記載した「部」は、「手段」や「回路」などに読み替えることができる。例えば、制御部は、制御手段や制御回路に読み替えることができる。

１ 情報処理システム
１０ 利用者端末
２０ 店舗端末
１００ 決済サーバ
１１０ 通信部
１２０ 記憶部
１２１ 口座情報記憶部
１２２ 店舗情報記憶部
１２３ 利用者情報記憶部
１３０ 制御部
１３１ 受付部
１３２ 判定部
１３３ チャージ部
１３４ 実行部

本発明は、情報処理プログラムに関する。

本願は、上記に鑑みてなされたものであって、コード決済の信頼性を高めることができる情報処理プログラムを提供することを目的とする。

本願に係る情報処理プログラムは、コンピュータに、コード情報から読み取った情報の中にオフラインでの決済取引である旨が含まれる場合、前記コード情報の読取に連動して決済取引が完了した旨を利用者に通知する手順を実行させる。

以下に本願に係る情報処理プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

Claims (13)

1. 利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と前記決済取引による店舗の売上額とを含む取引情報を受け付ける受付部と、
   前記売上額が所定の条件を満たす場合、前記決済取引に対応する取引処理を実行する実行部と
   を有することを特徴とする情報処理装置。
2. 前記実行部は、
   前記売上額の合計が前記店舗ごとに個別に割り当てられる所定の上限金額に満たないことを条件として、前記取引処理を実行する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記所定の上限金額は、
   前記店舗の過去の取引履歴に基づいて規定される
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記受付部は、
   前記店舗を識別するための店舗識別情報を含む前記取引情報を前記利用者端末から受け付け、
   前記実行部は、
   前記店舗識別情報に対応付けられている前記上限金額に基づいて、前記取引処理を実行する
   ことを特徴とする請求項２または３に記載の情報処理装置。
5. 前記受付部は、
   前記決済取引が行われた日時を示す日時情報を含む前記取引情報を前記利用者端末から受け付け、
   前記実行部は、
   前記店舗識別情報により識別される店舗において前記決済取引が有効な状態である期間内に前記決済取引が行われた日時が含まれていることを条件として、前記取引処理を実行する
   ことを特徴とする請求項４に記載の情報処理装置。
6. 前記受付部は、
   前記決済取引を行った利用者を識別するための利用者識別情報を含む前記取引情報を前記店舗端末から受け付け、
   前記実行部は、
   前記利用者識別情報により識別される前記利用者により前記決済取引の事実が承認されることを条件として、前記取引処理を実行する
   ことを特徴とする請求項２または３に記載の情報処理装置。
7. コンピュータが、
   利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と前記決済取引による店舗の売上額とを含む取引情報を受け付ける受付工程と、
   前記売上額が所定の条件を満たす場合、前記決済取引に対応する取引処理を実行する実行工程と
   を実行することを特徴とする情報処理方法。
8. コンピュータに、
   利用者端末または店舗端末からオフラインでの決済取引である旨を示す情報と前記決済取引による店舗の売上額とを含む取引情報を受け付ける受付手順と、
   前記売上額が所定の条件を満たす場合、前記決済取引に対応する取引処理を実行する実行手順と
   を実行させることを特徴とする情報処理プログラム。
9. コンピュータに、
   コード情報から読み取った情報の中にオフラインでの決済取引である旨が含まれる場合、前記コード情報の読取に連動して決済取引が完了した旨を利用者に通知する手順を実行させる
   ことを特徴とする情報処理プログラム。
10. コンピュータに、
    オフラインでの決済取引である旨を示す情報に関連付けて、前記決済取引が行われた店舗を示す店舗識別情報と、前記決済取引が行われた日時を示す日時情報と、前記決済取引による店舗の売上額を示す情報とを含む取引情報を記録する手順を実行させる
    ことを特徴とする請求項９に記載の情報処理プログラム。
11. コンピュータに、
    利用者端末に表示されるコード情報を読み取った際、オフラインでの売上処理が有効な状態であることを条件として、前記コード情報の読取に連動してオフラインでの決済取引が完了した旨を利用者に通知する手順を実行させる
    ことを特徴とする情報処理プログラム。
12. コンピュータに、
    オフラインでの決済取引である旨を示す情報に関連付けて、前記決済取引を行った利用者を識別するための利用者識別情報と、前記決済取引が行われた日時を示す日時情報と、前記決済取引による店舗の売上額を示す情報とを含む取引情報を記録する手順を実行させる
    ことを特徴とする情報処理プログラム。
13. コンピュータに、
    近距離無線通信により、前記決済取引が完了した旨を示す情報を送信する手順を実行させる
    ことを特徴とする請求項１１または１２に記載の情報処理プログラム。

Images