JP2020204882A - 情報処理方法、プログラム、端末 - Google Patents
情報処理方法、プログラム、端末 Download PDFInfo
- Publication number
- JP2020204882A JP2020204882A JP2019112042A JP2019112042A JP2020204882A JP 2020204882 A JP2020204882 A JP 2020204882A JP 2019112042 A JP2019112042 A JP 2019112042A JP 2019112042 A JP2019112042 A JP 2019112042A JP 2020204882 A JP2020204882 A JP 2020204882A
- Authority
- JP
- Japan
- Prior art keywords
- information
- terminal
- code
- payment
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000010365 information processing Effects 0.000 title claims abstract description 35
- 238000003672 processing method Methods 0.000 title claims abstract description 28
- 238000000034 method Methods 0.000 claims abstract description 250
- 238000004891 communication Methods 0.000 claims abstract description 176
- 238000012545 processing Methods 0.000 claims abstract description 159
- 230000008569 process Effects 0.000 claims description 191
- 238000012986 modification Methods 0.000 claims description 62
- 230000004048 modification Effects 0.000 claims description 62
- 230000000694 effects Effects 0.000 description 62
- 230000006870 function Effects 0.000 description 51
- 238000004364 calculation method Methods 0.000 description 40
- 238000010586 diagram Methods 0.000 description 31
- 238000012790 confirmation Methods 0.000 description 29
- 238000001514 detection method Methods 0.000 description 15
- 238000012937 correction Methods 0.000 description 14
- 230000004044 response Effects 0.000 description 13
- 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 8
- 230000005540 biological transmission Effects 0.000 description 6
- 230000008859 change Effects 0.000 description 6
- 238000005259 measurement Methods 0.000 description 5
- 102100024452 DNA-directed RNA polymerase III subunit RPC1 Human genes 0.000 description 4
- 101000689002 Homo sapiens DNA-directed RNA polymerase III subunit RPC1 Proteins 0.000 description 4
- 230000001133 acceleration Effects 0.000 description 4
- 238000003384 imaging method Methods 0.000 description 4
- 239000011159 matrix material Substances 0.000 description 4
- 238000013461 design Methods 0.000 description 3
- 230000005684 electric field Effects 0.000 description 3
- 230000009469 supplementation Effects 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 2
- 238000005401 electroluminescence Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 241000122205 Chamaeleonidae Species 0.000 description 1
- VSPBJCAGAJBGKS-UHFFFAOYSA-N Charine Chemical compound OC1=NC(N)=NC(N)=C1OC1C(O)C(O)C(O)CO1 VSPBJCAGAJBGKS-UHFFFAOYSA-N 0.000 description 1
- 238000009825 accumulation Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- WEXXMKKKIYDELC-UHFFFAOYSA-N charine Natural products Nc1nc(N)c(OC2OC(CO)C(O)C2O)c(O)n1 WEXXMKKKIYDELC-UHFFFAOYSA-N 0.000 description 1
- 208000013407 communication difficulty Diseases 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 239000013256 coordination polymer Substances 0.000 description 1
- 230000010485 coping Effects 0.000 description 1
- 239000013078 crystal Substances 0.000 description 1
- 230000004907 flux Effects 0.000 description 1
- 239000011521 glass Substances 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 235000012054 meals Nutrition 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 229920001690 polydopamine Polymers 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Landscapes
- Cash Registers Or Receiving Machines (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
【課題】電子貨幣による決済に関して使い勝手が悪い場合があった。【解決手段】コード画像による決済を行うための第１情報に基づいて決済に関する処理を実行する端末の情報処理方法は、サーバから送信された第１情報を、端末の通信部を介して受信することと、受信された第１情報を、端末の制御部によって端末の記憶部に記憶することと、第１情報と、時刻情報とに基づく第１コード画像を端末の表示領域に表示することとを含み、時刻情報は、第１コード画像の表示領域への表示に基づく時刻の情報を含み、決済は、第１コード画像の表示に基づきサーバが受信する第１情報と、時刻情報とに基づいてサーバによって実行される。【選択図】図１
Description
本開示は、情報処理方法、プログラム、端末に関する。
昨今、スマートフォン等の端末で実行可能なアプリケーションによって、端末、または端末のユーザの電子貨幣（電子マネー）の管理や、電子貨幣による決済等を実現するサービスが普及しつつある。例えば特許文献１には、商品の購買金額の決済を行う技術が開示されている。しかしながら、電子貨幣による決済は、例えば、端末の通信環境や通信状況によっては行うことができない場合もあるなど、使い勝手が悪い場合があった。
本発明の第１の態様によると、コード画像による決済を行うための第１情報に基づいて決済に関する処理を実行する端末の情報処理方法は、サーバから送信された第１情報を、端末の通信部を介して受信することと、受信された第１情報を、端末の制御部によって端末の記憶部に記憶することと、第１情報と、時刻情報とに基づく第１コード画像を端末の表示領域に表示することとを含み、時刻情報は、第１コード画像の表示領域への表示に基づく時刻の情報を含み、決済は、第１コード画像の表示に基づきサーバが受信する第１情報と、時刻情報とに基づいてサーバによって実行される。
本発明の第２の態様によると、コード画像による決済を行うための第１情報に基づいて決済に関する処理を実行する端末のコンピュータによって実行されるプログラムは、サーバから送信された第１情報を、端末の通信部を介して受信することと、受信された第１情報を端末の記憶部に記憶することと、第１情報と、時刻情報とに基づく第１コード画像を端末の表示領域に表示することとを含み、時刻情報は、第１コード画像の表示領域への表示に基づく時刻の情報を含み、決済は、第１コード画像の表示に基づきサーバが受信する第１情報と、時刻情報とに基づいてサーバによって実行される。
本発明の第３の態様によると、コード画像による決済を行うための第１情報に基づいて決済に関する処理を実行する端末は、サーバから送信された第１情報を受信する通信部と、受信された第１情報を端末の記憶部に記憶する制御を行う制御部と、第１情報と、時刻情報とに基づく第１コード画像を表示する表示部とを備え、時刻情報は、第１コード画像の表示部への表示に基づく時刻の情報を含み、決済は、第１コード画像の表示に基づきサーバが受信する第１情報と、時刻情報とに基づいてサーバによって実行される。
本発明の第４の態様によると、コード画像による決済を行うための第１情報に基づいて決済に関する処理を実行する端末は、プログラムを記憶するメモリからプログラムを読み出し、プログラムに基づいて処理を実行するプロセッサーを備え、プロセッサーは、サーバから送信された第１情報を、端末の通信部を介して受信することと、受信された第１情報を端末の記憶部に記憶することと、第１情報と、時刻情報とに基づく第１コード画像を端末の表示領域に表示することとを実行し、時刻情報は、第１コード画像の表示領域への表示に基づく時刻の情報を含み、決済は、第１コード画像の表示に基づきサーバが受信する第１情報と、時刻情報とに基づいてサーバによって実行される。
本発明の第５の態様によると、コード画像による決済を行うための第１情報に基づいて決済に関する処理を行う端末の決済を実行するサーバの情報処理方法は、第１情報をサーバの通信部を介して端末に送信することと、端末の表示領域に表示された第１情報と、時刻情報とに基づく第１コード画像がコード読み取り装置によって読み取られたことに基づき、コード読み取り装置から送信された、第１コード画像に基づく第１情報と、時刻情報とを通信部を介して受信することと、第１情報と、時刻情報と、コード読み取り装置による第１コード画像の読み取りに基づく時刻の情報とに基づいて、決済を行うこととを含み、時刻情報は、第１コード画像の表示領域への表示に基づく時刻の情報を含む。
本発明の第２の態様によると、コード画像による決済を行うための第１情報に基づいて決済に関する処理を実行する端末のコンピュータによって実行されるプログラムは、サーバから送信された第１情報を、端末の通信部を介して受信することと、受信された第１情報を端末の記憶部に記憶することと、第１情報と、時刻情報とに基づく第１コード画像を端末の表示領域に表示することとを含み、時刻情報は、第１コード画像の表示領域への表示に基づく時刻の情報を含み、決済は、第１コード画像の表示に基づきサーバが受信する第１情報と、時刻情報とに基づいてサーバによって実行される。
本発明の第３の態様によると、コード画像による決済を行うための第１情報に基づいて決済に関する処理を実行する端末は、サーバから送信された第１情報を受信する通信部と、受信された第１情報を端末の記憶部に記憶する制御を行う制御部と、第１情報と、時刻情報とに基づく第１コード画像を表示する表示部とを備え、時刻情報は、第１コード画像の表示部への表示に基づく時刻の情報を含み、決済は、第１コード画像の表示に基づきサーバが受信する第１情報と、時刻情報とに基づいてサーバによって実行される。
本発明の第４の態様によると、コード画像による決済を行うための第１情報に基づいて決済に関する処理を実行する端末は、プログラムを記憶するメモリからプログラムを読み出し、プログラムに基づいて処理を実行するプロセッサーを備え、プロセッサーは、サーバから送信された第１情報を、端末の通信部を介して受信することと、受信された第１情報を端末の記憶部に記憶することと、第１情報と、時刻情報とに基づく第１コード画像を端末の表示領域に表示することとを実行し、時刻情報は、第１コード画像の表示領域への表示に基づく時刻の情報を含み、決済は、第１コード画像の表示に基づきサーバが受信する第１情報と、時刻情報とに基づいてサーバによって実行される。
本発明の第５の態様によると、コード画像による決済を行うための第１情報に基づいて決済に関する処理を行う端末の決済を実行するサーバの情報処理方法は、第１情報をサーバの通信部を介して端末に送信することと、端末の表示領域に表示された第１情報と、時刻情報とに基づく第１コード画像がコード読み取り装置によって読み取られたことに基づき、コード読み取り装置から送信された、第１コード画像に基づく第１情報と、時刻情報とを通信部を介して受信することと、第１情報と、時刻情報と、コード読み取り装置による第１コード画像の読み取りに基づく時刻の情報とに基づいて、決済を行うこととを含み、時刻情報は、第１コード画像の表示領域への表示に基づく時刻の情報を含む。
＜法的事項の遵守＞
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
本開示に係る情報処理方法等を実施するための実施形態について、図面を参照して説明する。
［システム構成］
図１は、本開示の一実施形態に係る通信システム１の構成の一例を示す図である。
図１に開示されるように、通信システム１では、ネットワーク３０を介してサーバ１０と、端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）と、店舗ＰＯＳシステム４０とが接続される。
図１は、本開示の一実施形態に係る通信システム１の構成の一例を示す図である。
図１に開示されるように、通信システム１では、ネットワーク３０を介してサーバ１０と、端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）と、店舗ＰＯＳシステム４０とが接続される。
サーバ１０は、ネットワーク３０を介してユーザが所有する端末２０に、端末２０間でのメッセージ等を含むコンテンツの送受信を実現するサービスを提供する。また、サーバ１０は、端末２０と通信を行って電子決済（限定ではなく、決済の一例）を実現するサービス（以下、「決済サービス」と称する。）を提供する。なお、ネットワーク３０に接続される端末２０の数は限定されない。
ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０と、１以上の店舗ＰＯＳシステム４０とを接続する役割を担う。すなわち、ネットワーク３０は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定ではなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。
端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）（限定ではなく、端末、情報処理装置の一例）は、各実施形態において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定ではなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定ではなく例として、ＰＤＡ・（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。
端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は基本的には同一であるため、以下の説明においては、端末２０について説明する。また、必要に応じて、ユーザＸが利用する端末を端末２０Ｘと表現し、ユーザＸまたは端末２０Ｘに対応付けられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定ではなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応付けられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
サーバ１０（限定ではなく、サーバ、情報処理装置、情報管理装置の一例）は、端末２０に対して、所定のサービスを提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定ではなく例として、サーバ装置、コンピュータ（限定ではなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定ではなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
以下説明する実施形態では、サーバ１０は、決済アプリケーションによる決済サービスを提供する機能を有していることとして説明する。
店舗ＰＯＳシステム４０は、サーバ１０を運用する事業者と提携している店舗に導入されて使用されるＰＯＳシステムである。
この店舗ＰＯＳシステム４０には、限定ではなく例として、店舗コードリーダ装置５０と、コードレジ６０と、店舗サーバ７０とが含まれる。
この店舗ＰＯＳシステム４０には、限定ではなく例として、店舗コードリーダ装置５０と、コードレジ６０と、店舗サーバ７０とが含まれる。
［各装置のハードウェア（ＨＷ）構成］
通信システム１に含まれる各装置のＨＷ構成について説明する。
通信システム１に含まれる各装置のＨＷ構成について説明する。
（１）端末のＨＷ構成
図１には、端末２０のＨＷ構成の一例を示している。
端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、表示部２４、マイク２５、スピーカ２６、カメラ２７、時計部２９Ａ、位置算出用情報検出部２９Ｂを備える。端末２０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、マイク２５、カメラ２７等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
図１には、端末２０のＨＷ構成の一例を示している。
端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、表示部２４、マイク２５、スピーカ２６、カメラ２７、時計部２９Ａ、位置算出用情報検出部２９Ｂを備える。端末２０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、マイク２５、カメラ２７等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０等の各種装置に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０等の各種装置から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部２３は、端末２０に対する各種操作を入力する装置、および、端末２０で処理された処理結果を出力する装置を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含む。
出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ（音声出力）、レンズ（限定ではなく例として３D（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。
表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ（限定ではなく例として、液晶ディスプレイやOELD（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。
入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。
時計部２９Ａは、端末２０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部２９Ａは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部２９Ａは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
なお、時計部２９Ａは、ＮＩＴＺ（Network Identity and Time Zone）規格等を適用したクロックを有していてもよいし、有していなくてもよい。
位置算出用情報検出部２９Ｂは、制御部２１が自己の端末２０の位置を算出（測定）するために必要な情報（以下、「位置算出用情報」と称する。）を検出（計測）する機能部である。位置算出用情報検出部２９Ｂは、限定ではなく例として、位置算出用センサ部と表現することもできる。
位置算出用情報検出部２９Ｂは、限定ではなく例として、ＧＰＳ（Global Positioning System）等の衛星測位システムを利用して端末２０の位置を算出するためのセンサやユニットである衛星測位センサ（衛星測位ユニット）や、慣性航法システムを利用して端末２０の位置を算出するためのセンサやユニットである慣性計測センサ（慣性計測ユニット（ＩＭＵ（Inertial Measurement Unit）））等を含む。
衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むＲＦ（Radio Frequency）信号をデジタル信号に変換するＲＦ受信回路や、ＲＦ受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。
慣性計測ユニットは、慣性航法演算によって端末２０の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、３軸の加速度センサや３軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。
制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
制御部２１は、限定ではなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。
記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定ではなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。
端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
マイク２５は、音声データの入力に利用される。スピーカ２６は、音声データの出力に利用される。カメラ２７は、動画像データの取得に利用される。
（２）サーバのＨＷ構成
図１には、サーバ１０のＨＷ構成の一例を示している。
サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、ディスプレイ１３、時計部１９を備える。サーバ１０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のＨＷは、ディスプレイ１３を取り外すような構成であってもよいし、そうでなくてもよい。
図１には、サーバ１０のＨＷ構成の一例を示している。
サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、ディスプレイ１３、時計部１９を備える。サーバ１０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のＨＷは、ディスプレイ１３を取り外すような構成であってもよいし、そうでなくてもよい。
制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。
記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。
通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０等の各種装置に送信する。また、通信Ｉ／Ｆ１４は、端末２０等の各種装置から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部１２は、サーバ１０に対する各種操作を入力する装置により実現される。入出力部１２は、ユーザからの入力を受け付けて、入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部１２は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部１２、限定ではなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部１２は、これらに限定されない。
ディスプレイ１３は、代表的にはモニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））で実現される。なお、ディスプレイ１３は、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらのディスプレイ１３は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイ１３は、これらに限定されない。
時計部１９は、サーバ１０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部１９は、限定ではなく例として、ハードウェアクロックとしてのＲＴＣ（Real Time Clock）やシステムクロック等を有して構成される。時計部１９は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
（３）店舗ＰＯＳのシステム構成
図２には、店舗ＰＯＳシステム４０のシステム構成の一例を示している。
店舗ＰＯＳシステム４０は、サーバ１０を運用する事業者と提携している店舗に導入されて使用されるＰＯＳシステムであり、限定ではなく例として、店舗コードリーダ装置５０と、コードレジ６０と、店舗サーバ７０とを含む。
図２には、店舗ＰＯＳシステム４０のシステム構成の一例を示している。
店舗ＰＯＳシステム４０は、サーバ１０を運用する事業者と提携している店舗に導入されて使用されるＰＯＳシステムであり、限定ではなく例として、店舗コードリーダ装置５０と、コードレジ６０と、店舗サーバ７０とを含む。
店舗コードリーダ装置５０は、ＰＯＳ通信Ｉ／Ｆ５７（限定ではなく例として、店舗内の有線通信Ｉ／Ｆや無線通信Ｉ／Ｆ）によってコードレジ６０や店舗サーバ７０と通信接続され、コードレジ６０での会計の際に、端末２０の表示部２４に表示される端末表示用コード画像を読み取る。そして、端末表示用コード画像を読み取ったことに基づいて、決済要求情報を通信Ｉ／Ｆ５４によってサーバ１０に送信し、サーバ１０で決済が行われた後、決済結果に関する情報（例えば、後述する店舗用決済完了通知）を通信Ｉ／Ｆ５４によってサーバ１０から受信する。
店舗コードリーダ装置５０は、限定ではなく例として、制御部５１と、入出力部５２と、表示部５３と、通信Ｉ／Ｆ５４と、記憶部５５と、音出力部５６と、ＰＯＳ通信Ｉ／Ｆ５７と、コードリーダ５８、時計部５９とを有する。
コードリーダ５８は、二次元コードを読み取るためのコードリーダであり、本明細書では、端末２０の表示部２４に表示され、端末２０のユーザによって提示される二次元コード（例えばＱＲコード（登録商標））としての端末表示用コードを読み取るための二次元コードリーダ（例えばＱＲコードリーダ）を含む。
コードレジ６０は、限定ではなく例として、ＰＯＳ通信Ｉ／Ｆ５７によって店舗コードリーダ装置５０や店舗サーバ７０と通信接続され、店舗コードリーダ装置５０がサーバ１０から受信した店舗用決済完了通知に基づいて、販売した商品の総額や、端末２０のユーザの電子貨幣の残高等の情報を印字したレシートを発行する。また、限定ではなく例として、コードレジ６０と一体として、またはコードレジ６０と別体として設けられ、客側に表示面が向けられたディスプレイを構成するようにしてもよい。コードレジ６０は、決済アプリケーションに対応可能に構成されたレジであり、決済アプリケーション対応の据置端末と言うこともできる。
店舗サーバ７０は、限定ではなく例として、自店舗に関する店舗情報や、自店舗で販売される商品に関する情報や自店舗で提供されるサービスに関する情報、自店舗での商品の販売やサービスの提供に伴う売上げに関する情報等の各種の情報を管理する。店舗サーバ７０は、ＰＯＳ通信Ｉ／Ｆ５７によって店舗コードリーダ装置５０やコードレジ６０と通信可能に構成されているとともに、ネットワーク３０を介してサーバ１０等の外部装置と通信可能に構成されている。
なお、店舗サーバ７０は、必ずしも店舗コードリーダ装置５０と直接的に通信可能に構成されている必要はなく、コードレジ６０を介して店舗コードリーダ装置５０と通信可能に構成されていてもよい。例えば、店舗コードリーダ装置５０がサーバ１０から受信した店舗用決済完了通知はコードレジ６０に送られ、その後、コードレジ６０から店舗サーバ７０に送られるようにするなどすることもできる。
（４）その他
サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
本開示の各実施形態においては、端末２０および／またはサーバ１０のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。
他の装置についても同様である。
他の装置についても同様である。
なお、端末２０の制御部２１、および／または、サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
他の装置についても同様である。
他の装置についても同様である。
また、本開示の各実施形態のプログラムＰ(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムＰを記憶可能である。また、プログラムＰは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムＰとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。
記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。
サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
他の装置についても同様である。
他の装置についても同様である。
また、本開示のプログラムＰは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
他の装置についても同様である。
他の装置についても同様である。
また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末２０における処理の少なくとも一部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
サーバ１０における処理の少なくとも一部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末２０における処理の少なくとも一部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
サーバ１０における処理の少なくとも一部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML5などのマークアップ言語などを用いて実装される。
また、本明細書では、適宜「通信Ｉ／Ｆによって」という表現を使用する。これは、装置が、限定ではなく例として、制御部（プロセッサー等）の制御に基づいて、通信Ｉ／Ｆを介して（通信部を介して）、各種の情報やデータを送受信することを示す。
＜第１実施例＞
近年、ネットワークサービスに関連するアプリケーション（アプリケーションソフトウェア）として、電子貨幣による電子決済用のアプリケーション（決済アプリケーション）、電子貨幣の送金用のアプリケーション（送金アプリケーション）といったアプリケーションや、これらのアプリケーションの一部の機能または全部の機能を集約した決済アプリケーションが普及しつつあり、端末２０のユーザが、これらのアプリケーションを用いて、電子貨幣に関する各種のサービスを受けることが可能になってきている。
近年、ネットワークサービスに関連するアプリケーション（アプリケーションソフトウェア）として、電子貨幣による電子決済用のアプリケーション（決済アプリケーション）、電子貨幣の送金用のアプリケーション（送金アプリケーション）といったアプリケーションや、これらのアプリケーションの一部の機能または全部の機能を集約した決済アプリケーションが普及しつつあり、端末２０のユーザが、これらのアプリケーションを用いて、電子貨幣に関する各種のサービスを受けることが可能になってきている。
以下説明する実施例は、限定ではなく例として、端末２０のユーザが、端末２０に記憶されて実行される決済アプリケーションを利用して、決済を行う実施例である。具体的には、オフラインにおいても決済を適切に行うことができる手法を提案する。
以下では、決済アプリケーションによる決済サービスを提供する事業者のことを「決済サービスの事業者」と称する。なお、決済サービスの事業者は、決済アプリケーションを提供する事業者や、サーバ１０の事業者と表現してもよいし、しなくてもよい。
また、以下では、決済サービスの事業者によって、サーバ１０が運用・管理されることとして説明する。また、以下では、決済アプリケーションの名称を、適宜「Ｐａｙｍｅｎｔ Ａｐｐ」と称して図示・説明する。
また、決済アプリケーションは、いわゆるメッセージングサービス（ＭＳ：Messaging Service）の機能を有さない単体のアプリケーションとしてサーバ１０によって提供されるようにしてもよいし、ＭＳの機能を有する複合的なアプリケーションとしてサーバ１０によって提供されるようにしてもよい。また、メッセージングサービスには、端末２０間での簡単なメッセージ等のコンテンツの送受信を可能とするインスタントメッセージングサービス（ＩＭＳ：Instant Messaging Service）を含めてもよいし、含めなくてもよい。
また、決済アプリケーションは、いわゆるソーシャルネットワーキングサービス（ＳＮＳ：Social Networking Service）の機能を有さない単体のアプリケーションとしてサーバ１０によって提供されるようにしてもよいし、ＳＮＳの機能を有する複合的なアプリケーションとしてサーバ１０によって提供されるようにしてもよい。
なお、ＭＳ（ＩＭＳを含む。）は、ＳＮＳの１つの形態（一形態）と考えることもできる。このため、ＭＳとＳＮＳとは区別してもよいし、区別しなくてもよい。
また、決済サービスの事業者と提携している店舗を「加盟店（加盟店舗）」と称し、図１では「加盟店Ｓ１」、「加盟店Ｓ２」、・・・、のように示している。
また、「電子貨幣」とは、物理的貨幣と区別される電子的な貨幣であって、決済アプリケーションにおいて管理される端末２０または端末２０のユーザが所有する電子的な貨幣を意味し、「決済」とは、この電子貨幣を利用した電子決済を意味する。
なお、電子貨幣は、「電子マネー」や「デジタル通貨（デジタル貨幣）」と表現してもよいし、そのようにしなくてもよい。
また、「電子貨幣（電子マネー）」や「デジタル通貨（デジタル貨幣）」として、法定通貨を用いてもよいし、仮想通貨を用いてもよい。
また、「電子貨幣（電子マネー）」や「デジタル通貨（デジタル貨幣）」には、暗号通貨（暗号資産）を含めてもよい。
また、仮想通貨には、クーポンなどの物的貨幣を含めてもよい。
第１実施例に記載の内容は、他の各実施例のいずれにも適用可能である。
また、「電子貨幣（電子マネー）」や「デジタル通貨（デジタル貨幣）」として、法定通貨を用いてもよいし、仮想通貨を用いてもよい。
また、「電子貨幣（電子マネー）」や「デジタル通貨（デジタル貨幣）」には、暗号通貨（暗号資産）を含めてもよい。
また、仮想通貨には、クーポンなどの物的貨幣を含めてもよい。
第１実施例に記載の内容は、他の各実施例のいずれにも適用可能である。
＜決済方法＞
（１）オンライン決済
まず、一態様として、オンライン決済の手法についてフローチャートを参照して説明する。
（１）オンライン決済
まず、一態様として、オンライン決済の手法についてフローチャートを参照して説明する。
以下では、「オンライン」とは、端末２０がサーバ１０と通信可能であることを示し、「オンライン状態」とは、このオンラインの状態を示すものとする。また、「オンライン決済」とは、オンライン状態でサーバ１０によって決済が行われることを示すものとする。
なお、以下では、端末２０とサーバ１０との通信は、限定ではなく例として、通信会社（通信キャリア）が設置する基地局等を介在して実現される、無線ＬＡＮ通信とは異なる周波数帯を用いた第１通信方式によって実現されることとする。第１通信方式には、限定ではなく例として、パケット通信（いわゆる端末２０におけるモバイルデータ通信）が含まれる。
また、通信方式として、第１通信方式とは異なる第２通信方式を用いてもよいし、そのようにしなくてもよい。第２通信方式には、限定ではなく例として、無線ＬＡＮ（例えばＷｉＦｉ（登録商標））が含まれる。
また、第１通信方式と第２通信方式とのうちの少なくともいずれか一方の通信方式により端末２０とサーバ１０とが通信可能であることを「オンライン状態」と定義してもよいし、しなくてもよい。
図３−１は、この場合における各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末２０の制御部２１が実行する処理、店舗コードリーダ装置５０の制御部５１が実行する処理、サーバ１０の制御部１１が実行する処理の一例をそれぞれ示している。
各処理における各ステップをアルファベットの大文字と数字の組み合わせで示し、本明細書では「ステップ」の用語は省略する。
また、以下説明するフローチャートは、あくまでも本実施例における処理を例示するものであり、以下説明するフローチャートにおいて、一部のステップを実行しなくてもよいし、追加のステップを挿入してもよい。
これらは、本明細書における他のフローチャートについても同様である。
また、以下説明するフローチャートは、あくまでも本実施例における処理を例示するものであり、以下説明するフローチャートにおいて、一部のステップを実行しなくてもよいし、追加のステップを挿入してもよい。
これらは、本明細書における他のフローチャートについても同様である。
まず、制御部２１は、端末表示用コードの生成を依頼するためのコード生成依頼情報を、通信Ｉ／Ｆ２２によって（通信Ｉ／Ｆ２２を介して）サーバ１０に送信する（Ａ１１０）。
以下では、限定ではなく例として、「コード情報」とは、符号化（エンコード）等によってコード画像に格納される情報やコード画像に格納されている情報（以下、元の情報という意味で「元情報」と称する。）と、元情報が格納された「コード画像」とを含む概念として説明する。つまり、「コード情報」には、「元情報」と「コード画像」とが含まれる。
「元情報」は、「エンコード情報」や「格納情報」等のように表現してもよいし、そのように表現しなくてもよい。
「元情報」は、「エンコード情報」や「格納情報」等のように表現してもよいし、そのように表現しなくてもよい。
また、以下では、限定ではなく例として、「コード」といった場合、「コード情報」と実質的に同じ意味合いであるものとする。
ただし、これらの定義はあくまでも一例に過ぎず、これらに限定されるものではない。
例えば、「コード情報」の用語を「元情報」の意味で用いるようにしてもよいし、そのようにしなくてもよい。
また、例えば、「コード」の用語を「コード画像」の意味で用いるようにしてもよいし、そのようにしなくてもよい。
例えば、「コード情報」の用語を「元情報」の意味で用いるようにしてもよいし、そのようにしなくてもよい。
また、例えば、「コード」の用語を「コード画像」の意味で用いるようにしてもよいし、そのようにしなくてもよい。
本実施例では、上記の元情報の一例として、サーバ１０によってコード生成依頼情報の送信元の端末２０毎、または端末２０のユーザ毎にユニークに生成される番号であって、所定の桁数のランダムな番号である「決済用番号」を例示する。決済用番号は、端末２０、または端末２０のユーザと関連付けられた情報であって、サーバ１０による決済に用いられる情報とも言える。
以下では、コード生成依頼情報に基づきサーバ１０によって生成される決済用のコードを「端末表示用コード」と称し、この端末表示用コードのコード画像を「端末表示用コード画像」と称する。
詳細は後述するが、端末表示用コード画像には、上記の決済用番号が格納される。
決済用番号や端末表示用コード画像は、コード画像による決済を行うための「第１情報」の一例であり、サーバ１０から送信される。
決済用番号や端末表示用コード画像は、コード画像による決済を行うための「第１情報」の一例であり、サーバ１０から送信される。
以下では、上記の端末表示用コード画像の生成をサーバ１０に依頼する情報をコード生成依頼情報とする場合を例示する。つまり、本処理では、限定ではなく例として、端末表示用コード画像の生成を端末２０からサーバ１０に依頼することとし、Ａ１１０では、端末表示用コード画像の生成を依頼するコード生成依頼情報をサーバ１０に送信する。
また、本明細書において、「端末表示用コード」とは、決済種別「端末コード表示」での決済に使用されるコードとして説明する。
決済種別「端末コード表示」では、端末２０のユーザが店舗等で支払いを行う際に、端末２０に記憶されている決済アプリケーションを用いて、端末２０で表示される端末表示用コード画像を店舗のコードレジ６０で店員に提示する。そして、この端末表示用コード画像を店舗コードリーダ装置５０等で読み取ってもらうことで決済を実現する。
端末表示用コードは、端末２０のユーザによって店舗等の店員に提示されるコード（コード画像）であるため、「提示用コード」や「ユーザ提示用コード」と表現することもできる。
決済種別「端末コード表示」では、端末２０のユーザが店舗等で支払いを行う際に、端末２０に記憶されている決済アプリケーションを用いて、端末２０で表示される端末表示用コード画像を店舗のコードレジ６０で店員に提示する。そして、この端末表示用コード画像を店舗コードリーダ装置５０等で読み取ってもらうことで決済を実現する。
端末表示用コードは、端末２０のユーザによって店舗等の店員に提示されるコード（コード画像）であるため、「提示用コード」や「ユーザ提示用コード」と表現することもできる。
Ａ１１０で送信するコード生成依頼情報には、限定ではなく例として、端末２０、または端末２０のユーザを識別するための識別情報を含めることができる。例えば、自己の端末２０を識別するための端末識別情報（例えば端末ＩＤ）、自己の端末２０のユーザを識別するためのユーザ識別情報（例えばユーザＩＤ）、決済アプリケーションのアカウント情報（例えばアプリケーションＩＤ）等の情報がこれに含まれる。
通信Ｉ／Ｆ１４によって端末２０からコード生成依頼情報を受信すると（Ｃ１１０）、制御部１１は、端末表示用コード生成処理を行う（Ｃ１２０）。
具体的には、限定ではなく例として、所定の桁数（例えば１０桁〜１２桁程度の桁数）のランダムな数字を発生させる手法（アルゴリズム）を用いて、所定の桁数のランダムな数字を決済用番号として発生させる。そして、限定ではなく例として、少なくとも決済用番号を元情報として含む端末表示用コード画像を生成する。より具体的には、少なくとも決済用番号をエンコード（符号化）し、図形化（画像化）して、二次元コード（例えばＱＲコード）の画像で表される端末表示用コード画像を生成する。また、受信したコード生成依頼情報に含まれる端末２０または端末２０のユーザの識別情報と、発生させた決済用番号とを関連付けて記憶部１５に記憶させる。
次いで、制御部１１は、生成された端末表示用コード（この例では端末表示用コード画像）を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｃ１３０）。端末２０は、通信Ｉ／Ｆ２２によってサーバ１０から端末表示用コード（この例では端末表示用コード画像）を受信する（Ａ１３０）。この場合、制御部２１は、限定ではなく例として、受信された端末表示用コード画像を表示部２４に表示させる。
その後、表示部２４に表示された端末表示用コード画像が、端末２０のユーザによって店舗の店員等に提示されると、制御部５１は、端末２０の表示部２４に表示された端末表示用コード画像をコードリーダ５８に読み取らせる制御を行う（Ｂ１５０）。
その後、制御部５１は、決済サービスの事業者によって提供（配布）される、決済アプリケーションと関連付けられたアプリケーションインターフェイス（ＡＰＩ）等を用いて通信Ｉ／Ｆ５４によってサーバ１０にアクセスし、少なくとも、読み取った端末表示用コード画像からデコードによって取得した決済用番号と、店舗または店舗コードリーダ装置５０を識別するための識別情報（以下、「店舗識別情報」と称する。）と、決済予定の金額（以下、「決済予定金額」と称する。）とを含む決済要求情報を、通信Ｉ／Ｆ５４によってサーバ１０に送信する（Ｂ１６０）。
通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信すると（Ｃ１６０）、制御部１１は、決済処理を行う（Ｃ１７０）。具体的には、受信した決済要求情報に含まれる決済用番号が、端末２０または端末２０のユーザの識別情報と関連付けて記憶部１５に記憶されているか否かを判定する。そして、記憶されている場合は「決済可能」と判定し、その決済用番号と関連付けて記憶されている識別情報から識別される端末２０または端末２０のユーザの電子貨幣の残高（決済アプリケーションのアプリケーションＩＤに関連付けられた電子貨幣の残高）（以下、単に「残高」と称する。）から決済予定金額を減算して決済する。
その後、制御部１１は、店舗用の決済完了通知（以下、「店舗用決済完了通知」と称する。）を、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０に送信する（Ｃ１８０）。店舗用決済完了通知には、限定ではなく例として、決済が完了（成功）した旨と、決済した日時（決済日時）と、決済した金額（決済金額）等の店舗用決済情報とが含まれる。
また、制御部１１は、端末用の決済完了通知（以下、「端末用決済完了通知」と称する。）を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｃ１９０）。端末用決済完了通知には、限定ではなく例として、決済が完了（成功）した旨と、決済した日時（決済日時）、決済した店舗の店舗識別情報（決済店舗識別情報）、決済した金額（決済金額）等の端末用決済情報とが含まれる。そして、制御部１１は、処理を終了する。
なお、ここでは、サーバ１０による決済が成功した場合に、店舗用決済完了通知と端末用決済完了通知とがサーバ１０から送信されることとするが、残高の不足等により、サーバ１０が決済を行うことができない場合がある。この場合は、決済を行うことができなかった旨の通知（例えば決済エラー通知、決済ＮＧ通知）を、店舗コードリーダ装置５０と端末２０とに送信するようにすればよい。
他の処理においても同様である。
他の処理においても同様である。
通信Ｉ／Ｆ５４によってサーバ１０から店舗用決済完了通知を受信すると（Ｂ１８０）、制御部５１は、処理を終了する。
また、通信Ｉ／Ｆ２２によって端末用決済完了通知をサーバ１０から受信すると、制御部２１は、受信された端末用決済完了通知に基づき、決済アプリケーションのデータとして端末２０で記憶している残高を更新する。また、制御部２１は、決済結果を表示部２４に表示させる（Ａ１９０）。そして、制御部２１は、処理を終了する。
図３−２は、端末２０で実行される決済アプリケーションで表示されるトップ画面の一例を示す図である。
このトップ画面は、決済アプリケーションを起動した際に表示される表示画面であり、画面上部に、決済アプリケーションの名称である「Ｐａｙｍｅｎｔ ＡＰＰ」が表示されている。その下の枠内には、残高（ここでは「３０００円」）が表示されており、その横には、電子貨幣をチャージ（追加）するためのチャージボタンが表示されている。また、その下には、決済アプリケーションの各種の機能に対応する複数の機能アイコンが表示されている。
このトップ画面は、決済アプリケーションを起動した際に表示される表示画面であり、画面上部に、決済アプリケーションの名称である「Ｐａｙｍｅｎｔ ＡＰＰ」が表示されている。その下の枠内には、残高（ここでは「３０００円」）が表示されており、その横には、電子貨幣をチャージ（追加）するためのチャージボタンが表示されている。また、その下には、決済アプリケーションの各種の機能に対応する複数の機能アイコンが表示されている。
これらの機能アイコンのうち、「コード」と示されたアイコンは、限定ではなく例として、表示部２４にコード表示画面を表示させるための「コードアイコン」である。このコードアイコンが端末２０のユーザによりタッチ操作されると、限定ではなく例として、端末２０からサーバ１０にコード生成依頼情報が送信され、サーバ１０によって端末表示用コードが生成される。そして、生成された端末表示用コードがサーバ１０から端末２０に送信されて、図３−３に示すコード表示画面が端末２０の表示部２４に表示される。
図３−３は、コード表示画面の一例を示す図である。
このコード表示画面には、画面上部に「コード」の文字が表示され、その下に、決済方法と、ユーザが所有しているポイントと、そのポイントを利用して決済を行うか否かを設定するためのポイントタブとが表示されている。
このコード表示画面には、画面上部に「コード」の文字が表示され、その下に、決済方法と、ユーザが所有しているポイントと、そのポイントを利用して決済を行うか否かを設定するためのポイントタブとが表示されている。
また、その下には、サーバ１０から取得した端末表示用コードのコード画像として、バーコードで表される一次元端末表示用コード画像と、ＱＲコードで表される二次元端末表示用コード画像ＱＣ０とが、表示画面内の異なる領域にそれぞれ表示されている。また、バーコードの下には、一例として、１２桁の決済用番号が表示されている。
また、この例では、コード表示画面に表示される端末表示用コードには、そのコードを使用して決済を行うことのできる期限（以下、「コード使用期限」と称する。）が定められている。コード使用期限は、限定ではなく例として、「端末２０で端末表示用コードが表示された（表示が開始された）時刻（日時）から規定時間（例えば「５分」）が経過した日時」とすることができる。規定時間は、適宜設定変更可能である。
コード使用期限は、端末２０側のコード表示時刻（コード表示日時）に基づく期限であって、端末２０で端末表示用コードを表示する期限であるため、「コード表示期限」と表現することもできる。
また、規定時間は、「コード表示時間」と表現することもできる。
また、規定時間は、「コード表示時間」と表現することもできる。
そして、二次元端末表示用コード画像ＱＣ０の下には、コード使用期限までの残り時間がカウントダウン形式で表示されている。この残り時間は、端末２０の時計部２９Ａによって計時される情報に基づき表示される。残り時間が「０」になると、この端末表示用コードは使用できなくなり、決済を行う場合は、サーバ１０から端末表示用コードを再取得することが必要となる。
端末２０のユーザは、コード使用期限までに、図３−３のコード表示画面をコードレジ６０で店舗の店員に提示し、店舗コードリーダ装置５０で端末表示用コード画像を読み取ってもらうことで決済を行う。この場合、店舗コードリーダ装置５０は、前述したＡＰＩ等を用いて通信Ｉ／Ｆ５４によってサーバ１０にアクセスして、決済に必要な情報をサーバ１０に送信する。これにより、サーバ１０によって決済処理が行われる。
なお、上記のように、端末２０がサーバ１０から端末表示用コードを受信したタイミングで表示部２４にコード表示画面を表示する構成とするのであれば、限定ではなく例として、サーバ１０が、端末表示用コード画像を生成した際に、生成した端末表示用コード画像と関連付けてコード使用期限を記憶するとともに、関連付けたコード使用期限を端末２０に通知して、サーバ１０と端末２０とでコード使用期限の情報を共有するようにすることもできる。
ここまで、オンライン決済を実現するための処理を例示したが、上記の処理を適用するためには、端末２０とサーバ１０とが通信可能な状態（オンライン状態）であることが必要となる。勿論、店舗コードリーダ装置５０とサーバ１０とが通信可能な状態であることも必要である。
しかしながら、地下などの電波状況が悪い場所で決済を行う場合や、イベント会場などの回線が混雑している状況で決済を行う場合、端末２０の一定期間（例えばひと月）における通信量が一定量を超えるなどして通信制限や通信の速度制限かかけられている場合等において、端末２０とサーバ１０とが通信不能（または通信困難）となった結果、決済を行うのが困難になる場合が想定される。そこで、以下では、このような場合であっても決済を実現するための手法を例示する。
（２）オフライン決済
本開示の手法の一態様としてのオフライン決済の手法について、フローチャートを参照して説明する。
以下では、「オフライン」とは、端末２０がサーバ１０と通信することができないことをを示し、「オフライン状態」とは、このオフラインの状態を示すものとする。また、「オフライン決済」とは、オフライン状態においてサーバ１０によって決済が行われることを示すものとする。また、前提として、店舗コードリーダ装置５０はサーバ１０と通信することができるものとする。
本開示の手法の一態様としてのオフライン決済の手法について、フローチャートを参照して説明する。
以下では、「オフライン」とは、端末２０がサーバ１０と通信することができないことをを示し、「オフライン状態」とは、このオフラインの状態を示すものとする。また、「オフライン決済」とは、オフライン状態においてサーバ１０によって決済が行われることを示すものとする。また、前提として、店舗コードリーダ装置５０はサーバ１０と通信することができるものとする。
また、以下では、サーバ１０によって生成された端末表示用コードに基づき端末２０側で処理（加工・生成、表示等の処理を含む。）される決済用のコードを「拡張端末表示用コード」と称し、この拡張端末表示用コードのコード画像を「拡張端末表示用コード画像」と称する。
拡張端末表示用コードは、端末表示用コードと同様に、決済種別「端末コード表示」での決済に使用されるコードであるが、オンライン決済に限らず、オフライン決済にも使用可能なコードである。
なお、拡張端末表示用コードは、オフライン決済のみならず、オンライン決済にも使用可能とすることができる。つまり、端末２０側でオフライン状態であるか否かを判定（検出）することは必須ではなく、オンライン状態／オフライン状態を問わず、拡張端末表示用コードを用いて決済を行うようにすることが可能である。
これは、他の実施例においても同様である。
これは、他の実施例においても同様である。
図３−４は、この場合における各装置が実行する処理の流れの一例を示すフローチャートである。図の見方は、前述したフローチャートと同様である。
図３−４のフローチャートは、図３−１のフローチャートをオフライン仕様に書き換えたものである。図３−１のフローチャートとは、限定ではなく例として、オンライン状態での処理ステップ（例えばＡ２４０）、オフライン状態での処理ステップ（例えばＡ２５０、Ｂ２５０、Ｂ２８０）、オフライン状態からオンライン状態に復帰した場合の処理ステップ（例えばＡ２９０、Ｃ２９０）が異なる。
Ａ１３０の後、制御部２１は、受信された端末表示用コード（この例では端末表示用コード画像）を記憶部２８にストックする（Ａ２４０）。
ここで、「ストック」とは、受信された端末表示用コードを後で利用可能とするために、記憶部２８に記憶させることを意味する。
なお、本明細書では、「ストック」のことを、単に「記憶」と表現することもある。また、端末表示用コードをストックすることを、「端末表示用コードを端末表示用コードストックデータに記憶させる」と表現することもある。
なお、本明細書では、「ストック」のことを、単に「記憶」と表現することもある。また、端末表示用コードをストックすることを、「端末表示用コードを端末表示用コードストックデータに記憶させる」と表現することもある。
この処理では、オフライン決済を可能とするために、オンライン状態においてサーバ１０から取得した端末表示用コード（この例では端末表示用コード画像）を端末２０の記憶部２８にストック（記憶）させておく。そして、オフライン状態での決済が必要となった場合に、ストックされた端末表示用コードを用いて、サーバ１０と通信する必要なく決済ができるようにする。
具体的に説明する。Ａ２４０の後、オフライン状態になったとする。
ここで、端末２０は、限定ではなく例として、以下のいずれかの手法によってオフライン状態となったことを検出する。
ここで、端末２０は、限定ではなく例として、以下のいずれかの手法によってオフライン状態となったことを検出する。
（Ａ）端末２０での決済アプリケーションの実行中、定期的なタイミングや特定のタイミングで、サーバ１０から接続確認要求が端末２０に送信され、端末２０からは、その接続確認要求に対して、識別情報（例えばアプリケーションＩＤ）を含む接続応答がサーバ１０に送信されるようにする。この場合、端末２０の制御部２１は、サーバ１０から接続確認要求を受信しなくなった場合に、オフライン状態になったと判定する。
（Ｂ）端末２０での決済アプリケーションの実行中、定期的なタイミングや特定のタイミングで、端末２０から識別情報（例えばアプリケーションＩＤ）を含む接続通知がサーバ１０に送信され、サーバ１０からは、その接続通知に対して、接続確認が端末２０に送信されるようにする。オフライン状態では、端末２０からサーバ１０に接続通知を送信することができない。このため、限定ではなく例として、端末２０の制御部２１は、接続通知の送信エラーの発生を検知した場合に、オフライン状態となったと判定する。
なお、端末２０が、限定ではなく例として、ネットワークの接続状況を取得するライブラリやアプリケーション等を用いて、自己の端末２０の通信状況に関する情報を取得して、オフライン状態となったか否かを判定するようにしてもよいし、そのようにしなくてもよい。
オフライン状態において、Ａ２４０でストックされた端末表示用コード画像が表示部２４に表示されて（Ａ２５０）、ユーザによって店舗の店員等に提示されると、制御部５１は、端末２０の表示部２４に表示された端末表示用コード画像を、コードリーダ５８に読み取らせる制御を行う（Ｂ２５０）。そして、制御部５１は、Ｂ１６０へと処理を移す。
Ｂ１６０の後、通信Ｉ／Ｆ５４によってサーバ１０から店舗用決済完了通知を受信すると（Ｂ２８０）、受信された店舗用決済完了通知に基づき、店舗の店員等はオフライン決済が完了（成功）したことを端末２０のユーザに口頭で通知する。
Ｃ１８０の後、制御部１１は、端末用決済完了通知を端末２０に送信する（Ｃ２９０）。しかし、オフライン状態では、端末２０は端末用決済完了通知を受信できない。端末２０がオンライン状態に復帰すると、サーバ１０から送信された端末用決済完了通知が端末２０で受信される。そして、通信Ｉ／Ｆ２２によって端末用決済完了通知をサーバ１０から受信すると、制御部２１は、受信された端末用決済完了通知に基づき、決済結果を表示部２４に表示させる（Ａ２９０）。
以上説明した処理が、オフライン決済を行うための処理の一例である。
ここで、端末表示用コードはワンタイムのコードであるため、オンライン決済と同様に、オフライン決済についても端末表示用コードにコード使用期限を定めることが考えられる。
ここで、端末表示用コードはワンタイムのコードであるため、オンライン決済と同様に、オフライン決済についても端末表示用コードにコード使用期限を定めることが考えられる。
しかしながら、この手法はオフライン決済にはそのまま適用することができない。なぜならば、オンライン状態ではサーバ１０は端末２０と通信しており、端末２０で端末表示用コードが表示されたことを認識できるため、サーバ１０の時計部１９の計時情報に基づいてコード使用期限が経過しているか否かを判定することができる。しかしながら、オフライン状態ではサーバ１０は端末２０と通信できないため、端末２０で端末表示用コードが表示されたことを認識できないためである。
具体的には、オンライン状態において、端末２０で決済アプリケーションが起動されると、限定ではなく例として、端末２０、または端末２０のユーザを識別するための識別情報（例えばアプリケーションＩＤ）が端末２０からサーバ１０に送信される。これにより、サーバ１０は、端末２０で決済アプリケーションが起動されたと認識することができる。しかしながら、オフライン状態では、決済アプリケーションが起動されたとしても、端末２０からサーバ１０に識別情報を送信できない。このため、端末２０で端末表示用コードが表示されたとしても、サーバ１０はそのことを認識することができないため、コード使用期限を特定することもできない。
また、例えば、悪意のあるユーザが、自己の端末２０の決済アプリケーション内で表示された端末表示用コード画像を、自己の端末２０でスクリーンショット等によって保存しておき、保存しておいた端末表示用コード画像を用いて決済を行う可能性がある。
また、一のユーザの端末２０の決済アプリケーション内で表示された端末表示用コード画像が、他のユーザによってそのユーザの端末２０のカメラ等によって撮像されて決済が行われる可能性がある。
また、一のユーザの端末２０の決済アプリケーション内で表示された端末表示用コード画像が、他のユーザによってそのユーザの端末２０のカメラ等によって撮像されて決済が行われる可能性がある。
＜機能構成＞
（１）サーバの機能構成
図４−１は、本実施例におけるサーバ１０の制御部１１により実現される機能の一例を示す図である。
（１）サーバの機能構成
図４−１は、本実施例におけるサーバ１０の制御部１１により実現される機能の一例を示す図である。
以下では、端末２０のユーザが、端末２０に記憶されている決済アプリケーションを用いて、限定ではなく例として、前述した決済種別「端末コード表示」による決済を行う場合を例示する。
サーバ１０は、制御部１１により実現される機能として、決済管理処理部１１１を有する。
決済管理処理部１１１は、記憶部１５に記憶されている決済管理処理プログラム１５１に従って、端末２０で実行される決済アプリケーションに関する各種の情報やデータの管理や、端末２０または端末２０のユーザの電子貨幣による決済を管理するための決済管理処理を実行する機能を有している。
決済管理処理部１１１は、限定ではなく例として、端末表示用コード生成処理によって端末表示用コードを生成する端末表示用コード生成処理部１１１１と、決済処理によって決済を実行する決済処理部１１１３とを機能部として含む。
端末表示用コード生成処理部１１１１は、限定ではなく例として、二次元コードで表される端末表示用コード画像を生成する。二次元コードとは、水平方向と垂直方向とに情報を持つ表示方式のコードであり、小さな正方形を上下左右に配列させたマトリックス式のコード（以下、「マトリックスコード」と称す。）や、一次元コード（限定ではなく例としてバーコード）を上下に複数重ねたスタック式のコード（以下、「スタックコード」と称す。）等がある。
本実施例では、説明の簡明化のため、広く用いられているマトリックスコードの一例であるＱＲコード（登録商標）を、端末表示用コードの一例として説明する。
なお、本実施例とは異なり、ＱＲコード以外のマトリックスコードとして、ＳＰコードやベリコード、マキシコード、ＣＰコード、カメレオンコード等のコードを用いてもよいし、用いなくてもよい。また、マトリックスコードではなく、各種のスタックコードを用いてもよいし、用いなくてもよい。
また、端末表示用コード生成処理部１１１１が、端末表示用コードとして、二次元コード（限定ではなく例として、ＱＲコード）に加えて、一次元コード（限定ではなく例として、バーコード）を生成するようにしてもよいし、そのようにしなくてもよい。これは、店舗によっては、二次元コードの読み取りには対応していないが、一次元コードの読み取りには対応可能な場合があるためである。
決済処理部１１１３は、限定ではなく例として、店舗ＰＯＳシステム４０から送信される情報や、端末２０から送信される情報に基づいて、決済処理を行う機能を有している。
図４−２は、本実施例におけるサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、限定ではなく例として、プログラムとして、制御部１１により読み出され、決済管理処理として実行される決済管理処理プログラム１５１が記憶される。
記憶部１５には、限定ではなく例として、プログラムとして、制御部１１により読み出され、決済管理処理として実行される決済管理処理プログラム１５１が記憶される。
また、記憶部１５には、限定ではなく例として、データとして、ユーザ登録データ１５３と、店舗登録データ１５５と、決済管理データベース１５７と、コード管理データ１５９とが記憶される。
ユーザ登録データ１５３は、決済サービスを利用する端末２０および端末２０のユーザの登録データであり、そのデータ構成の一例を図４−３に示す。
ユーザ登録データ１５３には、限定ではなく例として、ユーザ名と、端末電話番号と、端末メールアドレスと、アプリケーションＩＤと、認証パスワードと、その他登録情報とが関連付けて記憶される。
ユーザ登録データ１５３には、限定ではなく例として、ユーザ名と、端末電話番号と、端末メールアドレスと、アプリケーションＩＤと、認証パスワードと、その他登録情報とが関連付けて記憶される。
ユーザ名は、決済サービスを利用する端末２０のユーザの名称であり、端末２０のユーザが決済サービスを利用する際に登録する名称が記憶される。
端末電話番号は、このユーザ名のユーザの端末２０の電話番号であり、端末２０のユーザが決済アプリケーションを利用する際に登録する端末２０の電話番号が記憶される。
端末メールアドレスは、このユーザ名のユーザの端末２０のメールアドレスであり、端末２０のユーザが決済アプリケーションを利用する際に登録する端末２０のメールアドレスが記憶される。
端末電話番号や端末メールアドレスは、端末２０を識別するための識別情報（以下、「端末識別情報」と称す。）の一例である。
端末メールアドレスは、このユーザ名のユーザの端末２０のメールアドレスであり、端末２０のユーザが決済アプリケーションを利用する際に登録する端末２０のメールアドレスが記憶される。
端末電話番号や端末メールアドレスは、端末２０を識別するための識別情報（以下、「端末識別情報」と称す。）の一例である。
アプリケーションＩＤは、決済アプリケーションのアカウント（アカウント情報）であって、端末２０、または端末２０のユーザを識別可能とするＩＤである。このアプリケーションＩＤは、限定ではなく例として、サーバ１０によって固有のＩＤが設定されて記憶される。
認証パスワードは、このユーザ名のユーザの端末２０において、決済用の認証処理（以下、単に「認証処理」と称す。）を行う際にユーザに入力を要求する認証用のパスワードであり、ユーザによって設定されたパスワードが記憶される。
なお、決済用の認証処理は、必ずしも行わなければならないわけではなく、行わないようにすることも可能である。この場合は、認証パスワードをユーザ登録データ１５３に記憶させておく必要はない。
その他登録情報は、このユーザ名のユーザのその他の登録情報であり、限定ではなく例として、決済アプリケーションにおいてユーザが使用するアイコンの画像データであるユーザアイコン画像やユーザのプロフィール等がこれに含まれる。
店舗登録データ１５５は、決済アプリケーションを提供する事業者（サーバ１０の事業者）と提携している店舗の登録データである。この店舗登録データ１５５の一例である店舗登録データ１５５Ａのデータ構成例を、図４−４に示す。
店舗登録データ１５５Ａには、限定ではなく例として、業種と、店舗名と、店舗位置情報と、店舗ＰＯＳシステム情報と、店舗ＩＤとが店舗情報として関連付けて記憶される。
店舗登録データ１５５Ａには、限定ではなく例として、業種と、店舗名と、店舗位置情報と、店舗ＰＯＳシステム情報と、店舗ＩＤとが店舗情報として関連付けて記憶される。
業種には、店舗の業種が記憶される。この業種には、限定ではなく例として、「コンビニエンスストア」、「スーパーマーケット」、「薬局」、「居酒屋」、「百貨店」、「レストラン」、「本屋」、「時計店」といった各種の業種が含まれる。
店舗名には、各業種それぞれについて、その業種に含まれる（属する）店舗の店舗名が記憶される。
店舗位置情報には、この店舗名の店舗の所在地の位置情報（以下、「店舗位置情報」と称す。）が記憶される。この店舗位置情報は、店舗の所在地を２次元または３次元の位置座標で表したものとしてもよいし、店舗の所在地を経緯度（緯度、経度、場合によっては高度）で表したものとしてもよい。
店舗ＰＯＳシステム情報には、この店舗で使用される店舗ＰＯＳシステム４０に関する情報が記憶される。この店舗ＰＯＳシステム情報には、限定ではなく例として、サーバ１０が、店舗コードリーダ装置５０や店舗サーバ７０と通信を行うために必要な情報が含まれる。
店舗ＰＯＳシステム４０は、サーバ１０と連携して処理を行うため、限定ではなく例として、サーバ１０から提供（配布）される決済アプリケーション用のソフトウェアパッケージをあらかじめ取得して店舗コードリーダ装置５０や店舗サーバ７０に記憶させておき、このソフトウェアパッケージを、店舗での決済処理用のプログラムから呼び出して使用するようにすることができる。アプリケーションプログラミングインターフェース（ＡＰＩ）が一例であり、店舗コードリーダ装置５０は、例えばＡＰＩを起動して、サーバ１０への情報の送信と、サーバ１０からの情報の受信とを実現する。
また、サーバ１０は、限定ではなく例として、店舗の業種、店舗名、店舗位置情報、店舗ＰＯＳシステム情報等の情報を、その店舗の店舗サーバ７０から受信して、店舗登録データ１５５に記憶させておくようにすることができる。
店舗ＩＤは、この店舗名の店舗を識別するための識別情報として機能するＩＤである。この店舗ＩＤは、限定ではなく例として、サーバ１０によって店舗ごとに固有のＩＤが設定されて記憶される。
店舗ＩＤは、店舗識別情報の一例である。
店舗ＩＤは、店舗識別情報の一例である。
決済管理データベース１５７は、各端末２０のユーザの決済に関する情報を管理するためのデータを蓄積的に記憶したデータベースであり、その一例である決済管理データベース１５７Ａの構成例を図４−５に示す。
決済管理データベース１５７Ａには、端末２０毎、または端末２０のユーザ毎に生成される決済管理データが記憶される。
決済管理データベース１５７Ａには、端末２０毎、または端末２０のユーザ毎に生成される決済管理データが記憶される。
各決済管理データには、限定ではなく例として、アプリケーションＩＤと、残高と、ポイントと、１日上限設定金額と、オートチャージ設定と、決済履歴データとが記憶される。
アプリケーションＩＤには、ユーザ登録データ１５３に記憶されているアプリケーションＩＤが記憶される。
残高には、このアプリケーションＩＤに関連付けられている残高が記憶される。
残高には、このアプリケーションＩＤに関連付けられている残高が記憶される。
ポイントには、決済アプリケーションと関連付けられた各種のサービスや、決済アプリケーションの事業者と提携している加盟店舗で貯めることのできるポイントが記憶される。ポイントは、限定ではなく例として、１ポイントあたり１円相当の価値を有し、ギフト券や商品等に交換することができる他、決済アプリケーションにおいて現金化して決済に利用することもできる。
１日上限設定金額には、このアプリケーションＩＤを所有する端末２０、または端末２０のユーザが決済に使用可能な金額の１日あたりの上限金額が記憶される。
オートチャージ設定は、残高が残り少ない金額（例えば「５００円」）や「０円」となった場合に、電子貨幣を自動的に補充（オートチャージ）するか否かの設定であり、端末２０のユーザによってオートチャージの設定がなされた場合は「ＯＮ」が記憶され、それ以外の場合は「ＯＦＦ」が記憶される。オートチャージは、限定ではなく例として、端末２０のユーザが登録している銀行口座等から行われるようにすることができる。
決済履歴データは、このアプリケーションＩＤのユーザの決済の履歴に関するデータであり、限定ではなく例として、このアプリケーションＩＤについて、サーバ１０によって決済が行われた日時である決済日時と、決済した店舗のＩＤである店舗ＩＤと、その店舗ＩＤの店舗の名称である決済店舗名と、決済した金額である決済金額とが関連付けて時系列に記憶される。
なお、上記の決済管理データには、必ずしも上記の全ての情報を記憶させるようにする必要はない。限定ではなく例として、ポイント、１日上限設定金額、オートチャージ設定のうちの一部または全部は、決済管理データに記憶させないようにしてもよい。
また、決済を行う度に、決済履歴の情報を端末２０に送信して端末２０に記憶させるようにして、サーバ１０には決済履歴データを記憶させないようにしてもよい。
また、決済を行う度に、決済履歴の情報を端末２０に送信して端末２０に記憶させるようにして、サーバ１０には決済履歴データを記憶させないようにしてもよい。
コード管理データ１５９は、コード（本実施例では端末表示用コード）を管理するためのデータであり、限定ではなく例として、ユーザ登録データ１５３に記憶されているアプリケーションＩＤと、このアプリケーションＩＤから識別される端末２０、または端末２０のユーザ用に生成した端末表示用コード画像の元情報（例えば決済用番号）とを関連付けたデータが記憶される。
なお、アプリケーションＩＤに代えて、または、これに加えて、ユーザ登録データ１５３に記憶されている端末電話番号等の端末識別情報を、コード管理データ１５９に記憶させるようにしてもよいし、しなくてもよい。
（２）端末の機能構成
図４−６は、本実施例において端末２０の制御部２１により実現される機能の一例を示す図である。
端末２０は、制御部２１により実現される機能として、決済アプリケーション処理部２１１を有する。
図４−６は、本実施例において端末２０の制御部２１により実現される機能の一例を示す図である。
端末２０は、制御部２１により実現される機能として、決済アプリケーション処理部２１１を有する。
決済アプリケーション処理部２１１は、記憶部２８に記憶されている決済アプリケーションソフトウェア２８１に基づいて、決済に関する処理を行うための決済アプリケーション処理を実行する機能を有している。
決済アプリケーション処理部２１１は、限定ではなく例として、拡張端末表示用コード生成処理を実行する拡張端末表示用コード生成処理部２１１１と、コード表示処理を実行するコード表示処理部２１１３とを機能部として含む。
本実施例において、決済に関する処理とは、限定ではなく例として、端末表示用コードをサーバ１０から取得する処理（端末表示用コードの生成をサーバ１０に依頼する処理や、生成された端末表示用コードをサーバ１０から受信する処理を含む。）、サーバ１０から取得した端末表示用コードをストックする処理、ストックした端末表示用コード画像を表示する処理、ストックした端末表示用コードに基づいて拡張端末表示用コード画像を生成する処理（拡張端末表示用コード生成処理）、拡張端末表示用コード画像を表示する処理（コード表示処理）、端末用決済完了通知をサーバ１０から取得する処理などの、決済を行う上で何らかの関連のある処理、より具体的には、決済を行う上で関連のある処理として端末２０で実行される処理全般を含む概念である。
図４−７は、本実施例における端末２０の記憶部２８に記憶される情報の一例を示す図である。
記憶部２８には、限定ではなく例として、サーバ１０からあらかじめダウンロードするなどして取得されるアプリケーションソフトウェアとして、決済アプリケーションソフトウェア２８１が記憶される。
記憶部２８には、限定ではなく例として、サーバ１０からあらかじめダウンロードするなどして取得されるアプリケーションソフトウェアとして、決済アプリケーションソフトウェア２８１が記憶される。
決済アプリケーションソフトウェア２８１には、限定ではなく例として、決済アプリケーションプログラム２８２と、決済アプリケーションデータ２８３とが含まれる。
決済アプリケーションデータ２８３には、決済アプリケーションソフトウェアで用いられる各種のデータが記憶される。この決済アプリケーションデータ２８３には、限定ではなく例として、端末表示用コードストックデータ２８３１と、決済用データ２８３２と、店舗データ２８３３とが記憶される。
端末表示用コードストックデータ２８３１には、オンライン状態においてサーバ１０から取得した端末表示用コードのデータが記憶される。
決済用データ２８３２は、端末２０で記憶される決済用のデータであり、その一例である決済用データ２８３２Ａの構成を図４−８に示す。
決済用データ２８３２Ａには、限定ではなく例として、アプリケーションＩＤと、ポイントと、残高と、１日上限設定金額と、オートチャージ設定と、決済履歴データとが記憶される。
決済用データ２８３２Ａには、限定ではなく例として、アプリケーションＩＤと、ポイントと、残高と、１日上限設定金額と、オートチャージ設定と、決済履歴データとが記憶される。
制御部２１は、オンライン状態に復帰した後にサーバ１０から受信した端末用決済完了通知に基づき、限定ではなく例として、サーバ１０によって決済された日時である決済日時と、サーバ１０によって決済された店舗のＩＤである店舗ＩＤと、その店舗ＩＤの店舗の名称である決済店舗名と、サーバ１０によって決済された金額である決済金額とを関連付けて決済履歴データに時系列に記憶させる。
店舗データ２８３３には、限定でなく例として、サーバ１０の店舗登録データ１５５Ａに記憶されている各種の店舗情報が記憶される。
店舗データ２８３３は、限定ではなく例として、決済アプリケーションソフトウェア２８１のアップデートのタイミングで、サーバ１０から最新の店舗情報が端末２０に配信されて更新されるようにすることができる。
また、記憶部２８には、限定ではなく例として、端末データ２８９が記憶される。
端末データ２８９は、この端末２０に関するデータであり、限定ではなく例として、端末電話番号や端末メールアドレス等の端末識別情報や、端末２０側での各種の設定情報等がこれに含まれる。
端末データ２８９は、この端末２０に関するデータであり、限定ではなく例として、端末電話番号や端末メールアドレス等の端末識別情報や、端末２０側での各種の設定情報等がこれに含まれる。
＜表示画面例＞
図４−９は、本実施例において端末２０の表示部２４に表示される決済アプリケーションのトップ画面の一例を示す図である。
このトップ画面の構成は、図３−２と同様であり、ここでは、端末２０のユーザによって「コードアイコン」がタッチされた状態が示されている。
図４−９は、本実施例において端末２０の表示部２４に表示される決済アプリケーションのトップ画面の一例を示す図である。
このトップ画面の構成は、図３−２と同様であり、ここでは、端末２０のユーザによって「コードアイコン」がタッチされた状態が示されている。
図４−１０は、本実施例において端末２０の表示部２４に表示されるコード表示画面の一例を示す図である。このコード表示画面は、限定ではなく例として、オフライン状態において、図４−９のように「コードアイコン」がタッチされることで表示される。
このコード表示画面では、本実施例における拡張端末表示用コードである第１の拡張端末表示用コードのコード画像として、バーコードで表される一次元の第１の拡張端末表示用コード画像と、ＱＲコードで表される二次元の第１の拡張端末表示用コード画像ＱＣ１とが、表示画面内の異なる領域にそれぞれ表示されている。また、一次元の第１の拡張端末表示用コード画像の下には、１２桁で表される決済用番号が表示されている。
第１の拡張端末表示用コード画像（限定ではなく、第１情報と、時刻情報とに基づく第１コード画像の一例）は、サーバ１０から受信して端末２０でストックされた端末表示用コード画像に格納されている元情報（この例では決済用番号）と、端末２０側で生成した時刻情報（この例ではタイムスタンプ情報）とがエンコードされたコード画像である。
ここで、タイムスタンプ情報とは、特定の事象（特定のイベント）が発生した日時、日付、時刻などを示す情報であるとともに、そのタイムスタンプ情報に関連付けられた情報やデータ（ここでは第１の拡張端末表示用コード）が、ある時刻に確実に存在していたことを証明するための電子的な時刻証明書として機能するものである。
この例では、「第１の拡張端末表示用コード画像が端末２０の表示部２４に表示されること」を特定の事象とし、端末２０の制御部２１は、第１の拡張端末表示用コード画像が表示された（表示が開始された）時刻（以下、「コード表示時刻」と称する。）を含むタイムスタンプ情報を生成する。コード表示時刻やタイムスタンプ情報は、「時刻情報」の一例であり、端末２０の時計部２９Ａによって計時される情報に基づき生成される。
コード表示時刻により、第１の拡張端末表示用コード画像を使用して決済を行うことのできる期限（以下、「第１のコード使用期限」と称する。）が定められる。本実施例では、限定ではなく例として、「コード表示時刻（コード表示日時）から第１の規定時間（例えば「５分」）が経過した日時」を第１のコード使用期限とする。第１の規定時間は、適宜設定変更可能である。
第１のコード使用期限は、端末２０側のコード表示時刻（コード表示日時）に基づく期限であって、端末２０で拡張端末表示用コードを表示する期限であるため、「第１のコード表示期限」と表現することもできる。
また、第１の規定時間は、「第１のコード表示時間」と表現することもできる。
また、第１の規定時間は、「第１のコード表示時間」と表現することもできる。
なお、コード使用期限やコード表示期限に代えて、または、これらに加えて、コード使用期間やコード表示期間を定めるようにしてもよいし、そのようにしなくてもよい。例えば、コード使用期間やコード表示期間内に拡張端末表示用コード画像が店舗コードリーダ装置５０等で読み取られた場合は決済を可能とする一方、コード使用期間やコード表示期間が経過した後に拡張端末表示用コードが店舗コードリーダ装置５０等で読み取られた場合は決済を不可とする。
また、コード使用期限（コード表示期限）を「期間」の意味で用いるようにしてもよいし、そのようにしなくてもよい。
例えば、上記の第１のコード使用期限を、限定ではなく例として、「コード表示時刻（コード表示日時）から第１の規定時間が経過するまでの期間」と定義してもよいし、そのようにしなくてもよい。
例えば、上記の第１のコード使用期限を、限定ではなく例として、「コード表示時刻（コード表示日時）から第１の規定時間が経過するまでの期間」と定義してもよいし、そのようにしなくてもよい。
オフライン決済を行う場合、端末２０のユーザは、第１のコード使用期限までに、図４−１０のコード表示画面をコードレジ６０で店舗の店員に提示し、第１の拡張端末表示用コード画像を店舗コードリーダ装置５０で読み取ってもらうことで決済を行う。この場合、店舗コードリーダ装置５０は、読み取った第１の拡張端末表示用コード画像からデコードによって取得した情報（この例では決済用番号およびタイムスタンプ情報）を含む決済要求情報をサーバ１０に送信して、サーバ１０に決済を行わせる。
図４−１１は、オフライン状態からオンライン状態に復帰した後、サーバ１０から受信した端末用決済完了通知に基づいて表示部２４に表示される決済結果画面の一例を示す図である。
この決済結果画面では、図４−１０のコード表示画面の画面中央部に「決済完了」の文字とともに「「決済履歴」から詳細が確認できます。」というメッセージと、決済履歴を確認するための「確認アイコン」とがポップアップ形式で表示されている。
この決済結果画面では、図４−１０のコード表示画面の画面中央部に「決済完了」の文字とともに「「決済履歴」から詳細が確認できます。」というメッセージと、決済履歴を確認するための「確認アイコン」とがポップアップ形式で表示されている。
上記の表示画面例では、端末２０のユーザが、オンライン状態／オフライン状態のいずれであるかを意識することなく、例えばコードアイコンをタッチすることでコード表示画面を表示させることができるため、ユーザの利便性を向上させることができる。
＜処理＞
図４−１２は、本実施例における各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末２０の制御部２１が実行する決済アプリケーション処理の一例である第１の決済アプリケーション処理、店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例である第１の店舗決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例である第１の決済管理処理をそれぞれ示している。
図４−１２は、本実施例における各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末２０の制御部２１が実行する決済アプリケーション処理の一例である第１の決済アプリケーション処理、店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例である第１の店舗決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例である第１の決済管理処理をそれぞれ示している。
図４−１２のフローチャートは、図３−４のフローチャートを一部書き換えたものである。図３−４のフローチャートとは、限定ではなく例として、オフライン状態での処理ステップ（例えば、Ａ３５０、Ｂ３５０、Ｂ３６０）が異なる。
この処理では、一例として、端末２０、または端末２０のユーザを識別するための識別情報を、前述したアプリケーションＩＤとする。
Ａ２４０では、制御部２１は、端末表示用コードを記憶部２８の端末表示用コードストックデータ２８３１に記憶させる。
オフライン状態において、限定ではなく例として、端末２０のユーザによってコード表示操作がなされると、拡張端末表示用コード生成処理部２１１１が、拡張端末表示用コード生成処理（Ｘ）を行うとともに、コード表示処理部２１１３が、コード表示処理（Ｘ）を行う（Ａ３５０）。
拡張端末表示用コード生成処理（Ｘ）では、限定ではなく例として、前述した第１の拡張端末表示用コード画像を生成する。具体的には、端末表示用コードストックデータ２８３１にストックされている端末表示用コード画像からデコードによって取得した決済用番号と、制御部２１が生成したタイムスタンプ情報とをエンコード（符号化）し、図形化（画像化）して、第１の拡張端末表示用コード画像を生成する。
なお、店舗によっては、二次元コードの読み取りには対応していないが、一次元コードの読み取りには対応可能な場合がある。そこで、端末表示用コード生成処理部１１１１が、二次元コード（限定ではなく例としてＱＲコード）に加えて、一次元コード（限定ではなく例としてバーコード）で表される第１の拡張端末表示用コード画像を生成するようにしてもよいし、そのようにしなくてもよい。
また、コード表示時刻に代えて、時刻に加えて日付の情報も含む「コード表示日時」を含むタイムスタンプ情報を生成するようにしてもよいし、そのようにしなくてもよい。
また、第三者が元情報を解読することができないようにするために、決済用番号やタイムスタンプ情報を暗号化した情報をエンコードするようにしてもよいし、そのようにしなくてもよい。
また、タイムスタンプ情報をエンコードするのではなく、コード表示時刻やコード表示日時そのものをエンコードするようにしてもよいし、そのようにしなくてもよい。
コード表示処理（Ｘ）では、限定ではなく例として、少なくとも、第１の拡張端末表示用コード画像を含むコード表示画面を表示部２４に表示させる。
なお、上記のように、拡張端末表示用コード生成処理（Ｘ）において二次元の第１の拡張端末表示用コード画像を生成した場合は、限定ではなく例として、二次元の第１の拡張端末表示用コード画像を表示させるようにすることができる。
また、拡張端末表示用コード生成処理（Ｘ）において、一次元の第１の拡張端末表示用コード画像も生成した場合は、限定ではなく例として、二次元の第１の拡張端末表示用コード画像の他に、一次元の第１の拡張端末表示用コード画像を表示させるようにすることができる。この場合、一次元の第１の拡張端末表示用コード画像の近傍に、決済用番号を併せて表示させてもよいし、そのようにしなくてもよい。
その後、表示部２４に表示された第１の拡張端末表示用コード画像が端末２０のユーザによって店舗の店員等に提示されると、制御部５１は、端末２０の表示部２４に表示された第１の拡張端末表示用コード画像を、コードリーダ５８に読み取らせる制御を行う（Ｂ３５０）。
制御部５１は、通信Ｉ／Ｆ５４によってサーバ１０にアクセスする。そして、制御部５１は、少なくとも、デコードによって取得した決済用番号およびタイムスタンプ情報と、店舗識別情報と、決済予定金額とを含む決済要求情報を、通信Ｉ／Ｆ５４によってサーバ１０に送信する（Ｂ３６０）。
店舗コードリーダ装置５０から通信Ｉ／Ｆ１４によって決済要求情報を受信すると（Ｃ１６０）、制御部１１は、決済処理を行う（Ｃ３７０）。
具体的には、受信した決済要求情報に含まれる決済用番号が、アプリケーションＩＤと関連付けてコード管理データ１５９に記憶されているか否かを判定する。また、サーバ１０の時計部１９によって計時されている現在の時刻（決済時の時刻）と、受信した決済要求情報に含まれるタイムスタンプ情報から特定されるコード表示時刻との差の時間が、第１の規定時間以下（未満としてもよい。以下同様。）であるか否かを判定する。そして、これらの条件が成立する場合は「決済可能」と判定し、決済管理データベース１５７Ａのうち、そのアプリケーションＩＤの決済管理データに記憶されている残高から決済予定金額を減算して決済する。
＜コード＞
上記の処理では、端末２０が、端末表示用コード画像の生成をサーバ１０に依頼することとし、サーバ１０によって生成された端末表示用コード画像が、端末２０に送信される例を示したが、これに限定されない。例えば、端末２０が、元情報（この例では決済用番号）の生成をサーバ１０に依頼することとし、サーバ１０によって生成された元情報が、端末２０に送信されるようにしてもよいし、そのようにしなくてもよい。
上記の処理では、端末２０が、端末表示用コード画像の生成をサーバ１０に依頼することとし、サーバ１０によって生成された端末表示用コード画像が、端末２０に送信される例を示したが、これに限定されない。例えば、端末２０が、元情報（この例では決済用番号）の生成をサーバ１０に依頼することとし、サーバ１０によって生成された元情報が、端末２０に送信されるようにしてもよいし、そのようにしなくてもよい。
具体的には、図３−１の処理では、Ａ１１０において、制御部２１は、元情報の生成をサーバ１０に依頼するコード生成依頼情報を送信する。そして、このコード生成依頼情報に基づき、Ｃ１２０において、制御部１１は元情報を生成し、Ｃ１３０において、生成した元情報を端末２０に送信する。
Ａ１３０において元情報をサーバ１０から受信すると、制御部２１は、受信された元情報に基づいて端末表示用コード画像を生成する。そして、制御部２１は、生成した端末表示用コード画像を表示部２４に表示させる。
同様に、図３−４の処理では、Ａ１３０において元情報をサーバ１０から受信すると、Ａ２４０において、制御部２１は、受信された元情報を端末表示用コードストックデータ２８３１に記憶させる。そして、制御部２１は、ストックされている元情報を端末表示用コードストックデータ２８３１から読み出し、読み出した元情報に基づいて端末表示用コード画像を生成する。そして、Ａ２５０において、制御部２１は、生成した端末表示用コード画像を表示部２４に表示させる。
同様に、図４−１２の処理では、Ａ１３０において元情報をサーバ１０から受信すると、Ａ２４０において、制御部２１は、受信された元情報を端末表示用コードストックデータ２８３１に記憶させる。そして、制御部２１は、Ａ３５０において、ストックされている元情報を端末表示用コードストックデータ２８３１から読み出し、読み出した元情報と、制御部２１が生成したタイムスタンプ情報とを含む第１の拡張端末表示用コード画像を生成する。
また、上記とは異なり、端末２０が、端末表示用コード画像の生成をサーバ１０に依頼し、サーバ１０によって生成された端末表示用コード画像が端末２０に送信されるが、端末２０側では、サーバ１０から受信した端末表示用コード画像をストックするのではなく、サーバ１０から受信した端末表示用コード画像からデコードによって取得した元情報をストックするようにしてもよいし、そのようにしなくてもよい。
＜第１実施例の効果＞
第１実施例によれば、限定ではなく例として、オフライン決済に際して、コード表示時刻等の時刻情報に基づいてサーバに決済を行わせることができる。また、端末２０に表示された端末表示用コード画像がスクリーンショット等によって保存されるなどして不正に決済が行われることを防止することができる。
第１実施例によれば、限定ではなく例として、オフライン決済に際して、コード表示時刻等の時刻情報に基づいてサーバに決済を行わせることができる。また、端末２０に表示された端末表示用コード画像がスクリーンショット等によって保存されるなどして不正に決済が行われることを防止することができる。
具体的には、第１実施例は、端末２０が、サーバ１０から送信された決済用番号（または決済用番号を含む端末表示用コード画像）（限定ではなく、第１情報の一例）を、通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、受信された決済用番号を、制御部２１によって記憶部２８に記憶する。また、端末２０は、記憶された決済用番号と、タイムスタンプ情報（限定ではなく、時刻情報の一例）とに基づく第１の拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）をコード表示画面の一の領域（限定ではなく、表示領域の一例）に表示する。タイムスタンプ情報は、コード表示時刻の情報を含み、決済は、第１の拡張端末表示用コード画像の表示に基づきサーバ１０が受信する決済用番号と、タイムスタンプ情報とに基づいてサーバ１０によって実行される構成を示している。
このような構成により得られる効果の一例として、サーバから送信された第１情報を端末の記憶部に記憶しておき、記憶された第１情報と、時刻情報とに基づく第１コード画像を端末の表示領域に表示する。時刻情報は、第１コード画像の表示領域への表示に基づく時刻の情報を含み、決済は、第１コード画像の表示に基づきサーバが受信する第１情報と、時刻情報とに基づいてサーバによって実行される。このため、例えば、時刻情報と、あらかじめ端末の記憶部に記憶させておいた第１情報とに基づいて、サーバにオフライン決済を行わせることが可能となり、端末のユーザの利便性を向上させることができる。
このような構成により得られる効果の一例として、サーバから送信された第１情報を端末の記憶部に記憶しておき、記憶された第１情報と、時刻情報とに基づく第１コード画像を端末の表示領域に表示する。時刻情報は、第１コード画像の表示領域への表示に基づく時刻の情報を含み、決済は、第１コード画像の表示に基づきサーバが受信する第１情報と、時刻情報とに基づいてサーバによって実行される。このため、例えば、時刻情報と、あらかじめ端末の記憶部に記憶させておいた第１情報とに基づいて、サーバにオフライン決済を行わせることが可能となり、端末のユーザの利便性を向上させることができる。
また、第１実施例は、第１の拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）は、決済用番号とタイムスタンプ情報とに基づく一つのコード画像である構成を示している。
このような構成により得られる効果の一例として、第１情報と時刻情報とに基づく一つのコード画像を表示することで、端末の表示領域に表示された一つのコード画像を外部のコードリーダに読み取らせるだけで、簡単に決済を行わせることができる。
このような構成により得られる効果の一例として、第１情報と時刻情報とに基づく一つのコード画像を表示することで、端末の表示領域に表示された一つのコード画像を外部のコードリーダに読み取らせるだけで、簡単に決済を行わせることができる。
また、第１実施例は、決済は、第１の拡張端末表示用コード画像が店舗等のコード読み取り装置に読み取られることに基づき、決済用番号とタイムスタンプ情報とがサーバ１０に送付され、決済用番号とタイムスタンプ情報とに基づいてサーバ１０によって実行される構成を示している。
このような構成により得られる効果の一例として、決済は、第１コード画像がコード読み取り装置に読み取られることに基づき、第１情報と時刻情報とがサーバに送付されることで、第１情報と時刻情報とに基づいてサーバによって実行されるため、端末の表示領域に表示された第１コード画像に基づいて、サーバに簡単に決済を行わせることができる。
このような構成により得られる効果の一例として、決済は、第１コード画像がコード読み取り装置に読み取られることに基づき、第１情報と時刻情報とがサーバに送付されることで、第１情報と時刻情報とに基づいてサーバによって実行されるため、端末の表示領域に表示された第１コード画像に基づいて、サーバに簡単に決済を行わせることができる。
また、第１実施例は、端末２０が、決済アプリケーションプログラム２８２（限定ではなく、プログラムの一例）を記憶するメモリから決済アプリケーションプログラム２８２を読み出し、決済アプリケーションプログラム２８２に基づいて決済アプリケーション処理を実行するプロセッサーを備える。そして、プロセッサーは、サーバ１０から送信された決済用番号（限定ではなく、第１情報の一例）を、通信Ｉ／Ｆ２２を介して受信し、受信された決済用番号を記憶部２８に記憶し、決済用番号と、タイムスタンプ情報（限定ではなく、時刻情報の一例）とに基づく第１の拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）をコード表示画面の一の領域（限定ではなく、端末の表示領域の一例）に表示する。タイムスタンプ情報は、コード表示時刻の情報を含み、決済は、第１の拡張端末表示用コード画像の表示に基づきサーバ１０が受信する決済用番号と、タイムスタンプ情報とに基づいてサーバ１０によって実行される構成を示している。
このような構成により得られる効果の一例として、例えば、時刻情報と、あらかじめ端末の記憶部に記憶させておいた第１情報とに基づいて、サーバにオフライン決済を行わせることが可能となり、端末のユーザの利便性を向上させることができる。
このような構成により得られる効果の一例として、例えば、時刻情報と、あらかじめ端末の記憶部に記憶させておいた第１情報とに基づいて、サーバにオフライン決済を行わせることが可能となり、端末のユーザの利便性を向上させることができる。
＜第１変形例（１）＞
第１実施例では、端末２０が、時刻情報がエンコードされた第１の拡張端末表示用コード画像を生成し、生成した第１の拡張端末表示用コード画像が店舗コードリーダ装置５０で読み取られることで、デコードによって取得された時刻情報が店舗コードリーダ装置５０からサーバ１０に送信されることとしたが、これに限定されない。
第１実施例では、端末２０が、時刻情報がエンコードされた第１の拡張端末表示用コード画像を生成し、生成した第１の拡張端末表示用コード画像が店舗コードリーダ装置５０で読み取られることで、デコードによって取得された時刻情報が店舗コードリーダ装置５０からサーバ１０に送信されることとしたが、これに限定されない。
具体的には、時刻情報を第１の拡張端末表示用コード画像にエンコードしないようにしてもよい。この場合、例えば、前述した第１通信方式によって通信を行うことができない場合であっても、第２通信方式によって通信を行うことができる場合は、第２通信方式によって、時刻情報を端末２０から店舗コードリーダ装置５０に送信する。または、ブルートゥースや赤外線通信等の近距離無線通信方式を利用可能であれば、これらの通信方式によって、時刻情報を端末２０から店舗コードリーダ装置５０に送信する。または、端末２０の表示部２４にコード画像とは別に時刻情報を表示させ、その表示画面を端末２０のユーザが店舗の店員等に提示することで、店舗の店員等が手動で店舗コードリーダ装置５０に時刻情報を入力する。そして、時刻情報が店舗コードリーダ装置５０からサーバ１０に送信されるようにすることもできる。
＜第１変形例（２）＞
第１実施例では、本開示における「時刻情報」を、端末２０で端末表示用コード画像が表示される時刻（コード表示時刻）や日時（コード表示日時）、またはこれらを含むタイムスタンプ情報としたが、これらに限定されない。
第１実施例では、本開示における「時刻情報」を、端末２０で端末表示用コード画像が表示される時刻（コード表示時刻）や日時（コード表示日時）、またはこれらを含むタイムスタンプ情報としたが、これらに限定されない。
まず、本開示における「時刻情報」とは、ある時刻や日時といったピンポイントのタイミングを示すものに限らず、一定の時間幅で表される時間（時間の長さ）を「時刻情報」としてもよいし、そのようにしなくてもよい。この場合は、限定ではなく例として、端末表示用コード画像が端末２０で表示される時間（時間の長さ）を時刻情報として、上記と同様の処理を行うようにしてもよいし、そのようにしなくてもよい。
また、限定ではなく例として、端末２０で端末表示用コード画像を生成した時刻（コード生成時刻）や日時（コード生成日時）、端末２０の内部処理として端末表示用コードを表示部２４に表示する準備を開始した時刻や日時、その準備が完了した時刻や日時を「時刻情報」として、上記と同様の処理を行うようにしてもよいし、そのようにしなくてもよい。
＜第１変形例（３）＞
第１実施例において、サーバ１０が、コード表示時刻と、店舗コードリーダ装置５０による端末表示用コード画像を読み取った時刻の情報とに基づいて、決済処理を行うようにしてよいし、そのようにしなくてもよい。
第１実施例において、サーバ１０が、コード表示時刻と、店舗コードリーダ装置５０による端末表示用コード画像を読み取った時刻の情報とに基づいて、決済処理を行うようにしてよいし、そのようにしなくてもよい。
この場合は、限定ではなく例として、図４−１２の処理において、店舗コードリーダ装置５０の制御部５１は、Ｂ３５０において第１の拡張端末表示用コード画像を読み取ると、Ｂ３６０において、通信Ｉ／Ｆ５４によってサーバ１０にアクセスする。そして、制御部５１は、少なくとも、デコードによって取得した決済用番号およびタイムスタンプ情報と、店舗コードリーダ装置５０で第１の拡張端末表示用コード画像を読み取った時刻（以下、「コード読み取り時刻」と称する。）と、店舗識別情報と、決済予定金額とを含む決済要求情報を、通信Ｉ／Ｆ５４によってサーバ１０に送信する。
店舗コードリーダ装置５０から通信Ｉ／Ｆ１４によって決済要求情報を受信すると（Ｃ１６０）、制御部１１は、決済処理を行う（Ｃ３７０）。この決済処理では、制御部１１は、限定ではなく例として、以下の処理を行う。
（Ａ）第１に、サーバ１０の時計部１９の計時時刻（現在時刻、決済時の時刻）と、受信した決済要求情報に含まれるタイムスタンプ情報から特定されるコード表示時刻との差の時間が、第１の規定時間以下であるか否かを判定する。
（Ｂ）第２に、受信した決済要求情報に含まれるコード読み取り時刻と、コード表示時刻との差が、第１の規定時間以下であるか否かを判定する。
（Ｂ）第２に、受信した決済要求情報に含まれるコード読み取り時刻と、コード表示時刻との差が、第１の規定時間以下であるか否かを判定する。
そして、制御部１１は、限定ではなく例として、上記の（Ａ）、（Ｂ）の両方の条件が成立する場合に「決済可能」と判定する。
なお、ここでは、サーバ１０が、店舗コードリーダ装置５０による第１の拡張端末表示用コード画像の読み取り時刻（コード読み取り時刻）に基づいて、決済が可能であるか否かを判定することとしたが、これに限定されない。
具体的には、限定ではなく例として、「コード読み取り装置によるコード画像の読み取りに基づく時刻の情報」として、サーバ１０が、店舗コードリーダ装置５０によって決済要求情報がサーバ１０に送信された時刻（決済要求情報送信時刻）に基づいて、決済が可能であるか否かを判定するようにしてもよいし、そのようにしなくてもよい。
また、限定ではなく例として、「コード読み取り装置によるコード画像の読み取りに基づく時刻の情報」として、サーバ１０が、店舗コードリーダ装置５０から決済要求情報を受信した時刻（決済要求情報受信時刻）に基づいて、決済が可能であるか否かを判定するようにしてもよいし、そのようにしなくてもよい。
また、限定ではなく例として、「コード読み取り装置によるコード画像の読み取りに基づく時刻の情報」として、サーバ１０が、店舗コードリーダ装置５０から決済要求情報が送信されたことを認識した時刻や、受信された決済要求情報に含まれる情報を識別した時刻に基づいて、決済が可能であるか否かを判定するようにしてもよいし、そのようにしなくてもよい。
＜第１変形例（３）の効果＞
本変形例は、決済は、端末２０側の時刻情報と、店舗コードリーダ装置５０による第１の拡張端末表示用コード画像の読み取り時刻の情報（限定ではなく、コード読み取り装置による第１コード画像の読み取りに基づく時刻の情報の一例）とに基づいて、サーバ１０によって実行される構成を示している。
このような構成により得られる効果の一例として、時刻情報と、コード読み取り装置による第１コード画像の読み取りに基づく時刻の情報とに基づいて、サーバによって適切に決済が行われるようにすることができる。
本変形例は、決済は、端末２０側の時刻情報と、店舗コードリーダ装置５０による第１の拡張端末表示用コード画像の読み取り時刻の情報（限定ではなく、コード読み取り装置による第１コード画像の読み取りに基づく時刻の情報の一例）とに基づいて、サーバ１０によって実行される構成を示している。
このような構成により得られる効果の一例として、時刻情報と、コード読み取り装置による第１コード画像の読み取りに基づく時刻の情報とに基づいて、サーバによって適切に決済が行われるようにすることができる。
また、本変形例は、決済は、端末２０側の時刻情報と、店舗コードリーダ装置５０による第１の拡張端末表示用コード画像の読み取り時刻の情報（限定ではなく、コード読み取り装置による第１コード画像の読み取りに基づく時刻の情報の一例）とが、サーバ１０で設定された有効期限内の場合、サーバ１０によって実行される構成を示している。
このような構成により得られる効果の一例として、例えば、時刻情報と、コード読み取り装置による第１コード画像の読み取りに基づく時刻の情報とにずれが生じている場合であっても、サーバで設定された有効期限に基づいて決済の可否がサーバで適切に判定された上で決済が行われるようにすることができる。
このような構成により得られる効果の一例として、例えば、時刻情報と、コード読み取り装置による第１コード画像の読み取りに基づく時刻の情報とにずれが生じている場合であっても、サーバで設定された有効期限に基づいて決済の可否がサーバで適切に判定された上で決済が行われるようにすることができる。
また、本変形例は、サーバ１０が、決済用番号（限定ではなく、第１情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信する。そして、サーバ１０は、決済用番号と、タイムスタンプ情報（限定ではなく、時刻情報の一例）とに基づく第１の拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）が店舗コードリーダ装置５０によって読み取られたことに基づき、店舗コードリーダ装置５０から送信された、第１の拡張端末表示用コード画像に基づく決済用番号と、タイムスタンプ情報とを通信Ｉ／Ｆ１４によって受信する。そして、サーバ１０は、決済用番号と、タイムスタンプ情報から特定されるコード表示時刻と、店舗コードリーダ装置５０によるコード読み取り時刻とに基づいて、決済を行う構成を示している。
このような構成により得られる効果の一例として、サーバは、第１情報と、時刻情報と、コード読み取り装置による第１コード画像の読み取りに基づく時刻の情報とに基づいて、誤りなく決済を行うことができる。
このような構成により得られる効果の一例として、サーバは、第１情報と、時刻情報と、コード読み取り装置による第１コード画像の読み取りに基づく時刻の情報とに基づいて、誤りなく決済を行うことができる。
なお、上記の決済処理において、サーバ１０の制御部１１が、以下のようにして決済を行うか否かを判定するようにしてもよいし、そのようにしなくてもよい。
（ａ）サーバ１０の時計部１９の計時時刻（現在時刻、決済時の時刻）と、受信した決済要求情報に含まれるタイムスタンプ情報から特定されるコード表示時刻との差の時間が、第１の規定時間以下であるか否かを判定する。
（ｂ）サーバ１０の時計部１９の計時時刻（現在時刻、決済時の時刻）と、受信した決済要求情報に含まれるコード読み取り時刻との差の時間が、第１の規定時間以下であるか否かを判定する。
（ｂ）サーバ１０の時計部１９の計時時刻（現在時刻、決済時の時刻）と、受信した決済要求情報に含まれるコード読み取り時刻との差の時間が、第１の規定時間以下であるか否かを判定する。
そして、サーバ１０は、上記の（ａ）の条件が成立する場合、または、上記の（ａ）の条件は成立しないが（ｂ）の条件は成立する場合に、「決済可能」と判定する。
このようにすることで、例えば、時刻情報から特定される時刻からは規定時間が経過しているが、コード読み取り装置による第１コード画像の読み取りの時刻からは規定時間が経過していないような場合に、サーバで決済が行われるようにすることができる。
＜第１変形例（４）＞
端末２０の記憶部２８の端末表示用コードストックデータ２８３１には、オンライン状態においてサーバ１０から取得した１つのコードを記憶させることとしてもよいが、オンライン状態においてサーバ１０から取得した複数（２以上）のコードを記憶させるようにすることも可能である。
端末２０の記憶部２８の端末表示用コードストックデータ２８３１には、オンライン状態においてサーバ１０から取得した１つのコードを記憶させることとしてもよいが、オンライン状態においてサーバ１０から取得した複数（２以上）のコードを記憶させるようにすることも可能である。
このようにすることで、複数のコードを端末２０でストックしておくことができるため、オフライン決済を複数回行う必要が生じた場合であっても、すぐに決済を行わせることが可能となり、ユーザの利便性を向上させることができる。
＜第１変形例（５）＞
第１実施例では、本開示における「第１情報」を、決済用番号や、決済用番号を含む端末表示用コード画像としたが、これに限定されない。例えば、認証情報の一種であるトークンや、トークンを含む端末表示用コード画像を、本開示における「第１情報」とすることもできる。
第１実施例では、本開示における「第１情報」を、決済用番号や、決済用番号を含む端末表示用コード画像としたが、これに限定されない。例えば、認証情報の一種であるトークンや、トークンを含む端末表示用コード画像を、本開示における「第１情報」とすることもできる。
この場合、決済用番号を拡張端末表示用コード画像に含めるのではなく、ランダムなトークンを発生させる手法（アルゴリズム）を用いて発行したトークンを拡張端末表示用コード画像に含めるようにしてもよいし、そのようにしなくてもよい。この場合は、サーバ１０側で、端末２０、または端末２０のユーザを識別するための識別情報と、発行したトークンとを関連付けて記憶部１５に記憶させておくようにすればよい。
「トークン」は、限定ではなく例として、サーバ１０が、端末２０、または端末２０のユーザが、正規の端末２０、または正規の端末２０のユーザであることを認証するための認証情報の一種である。「認証情報」は、認証局が発行する情報であり、上記のトークンは、サーバ１０が認証局となって、端末２０、または端末２０のユーザを認証するために発行する認証情報として機能する。
なお、トークンは、例えば、「ランダムトークン」、「アクセストークン」、「決済用トークン」などのように表現することもできる。トークンは、上記のようにランダムに発行されるため、端末表示用コードが生成される毎に異なるトークンとなる。このため、トークンは、いわばワンタイムパスワードとして機能する。
また、決済用番号やトークンの他に、端末表示用コード画像を読み取った店舗コードリーダ装置５０が、サーバ１０が提供するウェブサイトやウェブページにアクセスするためのアクセス情報の一例として、サーバ１０が提供するウェブページの一種である決済用ページにアクセスするためのＵＲＬ（Uniform Resource Locator）等の情報を含めるようにしてもよいし、そのようにしなくてもよい。
＜第１変形例（６）＞
図３−４の処理のＡ１３０において、端末２０がサーバ１０から端末表示用コードを受信したタイミングで、Ａ２４０およびＡ２５０の処理を行って、端末表示用コードを表示部２４に表示させるようにしてもよいし、そのようにしなくてもよい。
図３−４の処理のＡ１３０において、端末２０がサーバ１０から端末表示用コードを受信したタイミングで、Ａ２４０およびＡ２５０の処理を行って、端末表示用コードを表示部２４に表示させるようにしてもよいし、そのようにしなくてもよい。
また、図４−１２の処理のＡ１３０において、端末２０がサーバ１０から端末表示用コードを受信したタイミングで、Ａ２４０およびＡ３５０の処理を行って、第１の拡張端末表示用コードを表示部２４に表示させるようにしてもよいし、そのようにしなくてもよい。
この場合、限定ではなく例として、決済アプリケーションのトップ画面（例えば図３−２）においてコードアイコンがタッチされた場合、端末表示用コードのコード表示画面や、第１の拡張端末表示用コードのコード表示画面（例えば図４−１０）に表示が切り替わるようにすることができる。
＜第１変形例（７）＞
第１実施例で説明した決済アプリケーションの表示画面は、あくまでも一例に過ぎず、適宜設計変更可能である。
第１実施例で説明した決済アプリケーションの表示画面は、あくまでも一例に過ぎず、適宜設計変更可能である。
図４−１３は、本変形例において端末２０の表示部２４に表示される決済アプリケーションのトップ画面の一例を示す図である。
このトップ画面には、前述した「コードアイコン」とは別に、「コード（オフライン）」と示された「コード（オフライン）アイコン」が表示されている。
このトップ画面には、前述した「コードアイコン」とは別に、「コード（オフライン）」と示された「コード（オフライン）アイコン」が表示されている。
本変形例において、「コードアイコン」は、オンライン状態においてコード表示画面を表示させるためのアイコンであり、「コード（オフライン）アイコン」は、オフライン状態においてコード表示画面を表示させるためのアイコンである。
図４−１４は、本変形例において端末２０の表示部２４に表示されるコード表示画面の一例を示す図である。このコード表示画面は、上記のトップ画面においてコード（オフライン）アイコンがタッチされることで表示される。
このコード表示画面は、画面上部に「コード（オフライン）」と表示され、その下に、図４−１０のコード表示画面と同様の情報が表示されている。
このコード表示画面は、画面上部に「コード（オフライン）」と表示され、その下に、図４−１０のコード表示画面と同様の情報が表示されている。
この表示画面例では、端末２０がオフライン状態であることを検出した場合に、ユーザ操作に従って拡張端末表示用コードをコード表示画面に表示させ、この拡張端末表示用コードを用いてオフライン決済を行わせることができる。
＜第１変形例（８）＞
第１実施例で説明したコード表示画面は、あくまでも一例に過ぎず、適宜設計変更可能である。
第１実施例で説明したコード表示画面は、あくまでも一例に過ぎず、適宜設計変更可能である。
例えば、コード画像に格納可能な情報量の制約等によって、第１情報と時刻情報との両方の情報をエンコードすることが困難な場合もあり得る。そこで、これらの情報を別々にエンコードした２つの拡張端末表示用コード画像を生成して表示させるようにすることも可能である。
図４−１５は、本変形例におけるコード表示画面の一例を示す図である。
このコード表示画面では、本変形例における拡張端末表示用コード画像として、二次元の第２の拡張端末表示用コード画像ＱＣ２と、二次元の第３の拡張端末表示用コード画像ＱＣ３との２つのコード画像が並べて表示されている。
このコード表示画面では、本変形例における拡張端末表示用コード画像として、二次元の第２の拡張端末表示用コード画像ＱＣ２と、二次元の第３の拡張端末表示用コード画像ＱＣ３との２つのコード画像が並べて表示されている。
第２の拡張端末表示用コード画像ＱＣ２は、限定ではなく例として、サーバ１０から受信して端末２０でストックされた端末表示用コード画像に格納されている元情報（この例では決済用番号）がエンコードされたコード画像である。
第３の拡張端末表示用コード画像ＱＣ３は、限定ではなく例として、端末２０側で生成した時刻情報（この例ではタイムスタンプ情報）がエンコードされたコード画像である。
第３の拡張端末表示用コード画像ＱＣ３は、限定ではなく例として、端末２０側で生成した時刻情報（この例ではタイムスタンプ情報）がエンコードされたコード画像である。
なお、図４−１５のコード表示画面における第２の拡張端末表示用コード画像ＱＣ２と第３の拡張端末表示用コード画像ＱＣ３との配置は、あくまでも一例に過ぎず、適宜設定変更可能である。横方向に配置する他、縦方向や斜め方向に配置してもよい。また、２つのコード画像の表示位置を逆にしてもよい。
本変形例では、図４−１２の拡張端末表示用コード生成処理（Ｘ）において、端末表示用コード生成処理部１１１１は、第２の拡張端末表示用コード画像と、第３の拡張端末表示用コード画像とを生成する。
具体的には、端末表示用コードストックデータ２８３１に端末表示用コード画像がストックされている場合は、これをそのまま第２の拡張端末表示用コード画像とする。一方、端末表示用コードストックデータ２８３１に決済用番号がストックされている場合は、決済用番号をエンコード（符号化）し、図形化（画像化）して、第２の拡張端末表示用コード画像を生成する。
また、時計部２９Ａによって計時される情報に基づき、コード表示時刻を含むタイムスタンプ情報を生成する。そして、生成したタイムスタンプ情報をエンコード（符号化）し、図形化（画像化）して、第３の拡張端末表示用コード画像を生成する。
また、時計部２９Ａによって計時される情報に基づき、コード表示時刻を含むタイムスタンプ情報を生成する。そして、生成したタイムスタンプ情報をエンコード（符号化）し、図形化（画像化）して、第３の拡張端末表示用コード画像を生成する。
なお、店舗によっては、二次元コードの読み取りには対応していないが、一次元コードの読み取りには対応可能な場合がある。そこで、端末表示用コード生成処理部１１１１が、二次元コード（限定ではなく例としてＱＲコード）に加えて、一次元コード（限定ではなく例としてバーコード）で表される第２の拡張端末表示用コード画像と第３の拡張端末表示用コード画像とを生成するようにしてもよいし、そのようにしなくてもよい。
オフライン決済を行う場合、端末２０のユーザは、第１のコード使用期限までに、図４−１５のコード表示画面をコードレジ６０で店舗の店員に提示し、第２の拡張端末表示用コード画像と、第３の拡張端末表示用コード画像とを店舗コードリーダ装置５０で読み取ってもらうことで決済を行う。この場合、店舗コードリーダ装置５０は、読み取った第２の拡張端末表示用コード画像からデコードによって取得した情報（この例では決済用番号）と、読み取った第３の拡張端末表示用コード画像からデコードによって取得した情報（この例ではタイムスタンプ情報）とを含む決済要求情報をサーバ１０に送信して、サーバ１０に決済を行わせる。
なお、第２の拡張端末表示用コード画像と、第３の拡張端末表示用コード画像とは、店舗コードリーダ装置５０によって別々に読み取る方法に限らず、第２の拡張端末表示用コード画像と、第３の拡張端末表示用コード画像とがコードリーダ５８の１つの枠内に入ったことを検知したことに基づいて、２つの拡張端末表示用コード画像を一緒に（まとめて）読み取るようにしてもよいし、そのようにしなくてもよい。
＜第１変形例（８）の効果＞
本変形例は、拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）は、コード表示画面の一の領域（限定ではなく、第１領域の一例）に表示される第２の拡張端末表示用コード画像（限定ではなく、第２コード画像の一例）と、コード表示画面の他の領域（限定ではなく、第２領域の一例）に表示される第３の拡張端末表示用コード画像（限定ではなく、第３コード画像の一例）とを含む構成を示している。
このような構成により得られる効果の一例として、第１情報に基づく第２コード画像を第１領域に表示させ、時刻情報に基づく第３コード画像を第２領域に表示させることで、例えば、時刻情報をコード画像に含めることが困難な場合であっても、第３コード画像を外部の読み取り装置に読み取らせることで、時刻情報をサーバに送付して決済を行わせることができる。
本変形例は、拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）は、コード表示画面の一の領域（限定ではなく、第１領域の一例）に表示される第２の拡張端末表示用コード画像（限定ではなく、第２コード画像の一例）と、コード表示画面の他の領域（限定ではなく、第２領域の一例）に表示される第３の拡張端末表示用コード画像（限定ではなく、第３コード画像の一例）とを含む構成を示している。
このような構成により得られる効果の一例として、第１情報に基づく第２コード画像を第１領域に表示させ、時刻情報に基づく第３コード画像を第２領域に表示させることで、例えば、時刻情報をコード画像に含めることが困難な場合であっても、第３コード画像を外部の読み取り装置に読み取らせることで、時刻情報をサーバに送付して決済を行わせることができる。
なお、上記の他にも、限定ではなく例として、拡張端末表示用コード画像が表示される領域とは異なる領域に、端末２０の時計部２９Ａによって計時される情報に基づいて、第１のコード使用期限までの残り時間等の情報を表示させるようにしてもよいし、そのようにしなくてもよい。
＜第２実施例＞
第１実施例では、オフライン決済を実現するための手法の一例について説明した。しかしながら、端末２０の時計部２９Ａで計時される時刻と、サーバ１０の時計部１９で計時される時刻とにずれが生じているような場合には、上記の手法をそのまま適用することはできない可能性がある。
第１実施例では、オフライン決済を実現するための手法の一例について説明した。しかしながら、端末２０の時計部２９Ａで計時される時刻と、サーバ１０の時計部１９で計時される時刻とにずれが生じているような場合には、上記の手法をそのまま適用することはできない可能性がある。
具体的には、例えば、端末２０の時計部２９Ａで計時される時刻が誤差の累積によってサーバ１０の時計部１９で計時される時刻とずれているような場合や、ユーザが外国にいて端末２０の時刻が日本の標準時刻からずれているような場合には、上記の手法をそのまま適用することはできない可能性がある。
また、このような時刻のずれの他にも、悪意のあるユーザが自己の端末２０の時刻を過去の時刻に戻すなどの操作を行って、サーバ１０に決済を不正に行わせるようなリスクも想定される。
第２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図５−１は、本実施例において端末２０の記憶部２８に記憶される情報の一例を示す図である。
本実施例において、端末データ２８９には、端末設定データ２８９１が含まれる。また、端末設定データ２８９１には、限定ではなく例として、時刻調整設定データ２８９２が含まれる。
本実施例において、端末データ２８９には、端末設定データ２８９１が含まれる。また、端末設定データ２８９１には、限定ではなく例として、時刻調整設定データ２８９２が含まれる。
時刻調整設定データ２８９２は、端末２０の時計部２９Ａに関する設定データであり、限定ではなく例として、端末２０で時計部２９Ａの時刻を自動調整する設定（以下、「時刻自動調整」と称する。）がなされているか否かを示す情報（例えば、端末２０側の時刻自動調整の設定「ＯＮ」／「ＯＦＦ」）が記憶される。
時刻の自動調整の手法としては、限定ではなく例として、ＮＴＰ等の時刻同期用のプロトコルを用いる手法や、ＧＰＳ等の衛星測位システムを利用して時刻を同期させる手法等を適用することができる。
＜処理＞
図５−２は、本実施例における各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末２０の制御部２１が実行する決済アプリケーション処理の一例である第２の決済アプリケーション処理、店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例である第１の店舗決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例である第１の決済管理処理をそれぞれ示している。
図５−２は、本実施例における各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末２０の制御部２１が実行する決済アプリケーション処理の一例である第２の決済アプリケーション処理、店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例である第１の店舗決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例である第１の決済管理処理をそれぞれ示している。
図５−２のフローチャートは、図４−１２のフローチャートに、Ａ４４５のステップを追加したものである。
Ａ２４０の後、オフライン状態において、限定ではなく例として、端末２０のユーザによってコード表示操作がなされると、制御部２１は、記憶部２８の時刻調整設定データ２８９２を参照し、時刻自動調整の設定が「ＯＮ」となっているか否かを判定する（Ａ４４５）。そして、「ＯＮ」となっていると判定したならば（Ａ４４５：ＹＥＳ）、制御部２１は、Ａ３５０へと処理を移す。
一方、時刻自動調整の設定が「ＯＮ」となっていない（「ＯＦＦ」となっている）と判定したならば（Ａ４４５：ＮＯ）、制御部２１は、Ａ３５０以降の処理を行うことなく、第２の決済アプリケーション処理を終了する。
＜第２実施例の効果＞
第２実施例は、端末２０が、時計部２９Ａの時刻自動調整の設定（限定ではなく、端末の時刻の自動調整に関する設定の一例）を行う。そして、第１の拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）は、時刻自動調整の設定が「ＯＮ」となっている場合に、表示部２４に表示される構成を示している。
このような構成により得られる効果の一例として、端末の時刻の自動調整に関する設定を端末で行うことができる。また、第１コード画像は、自動調整に関する設定に基づいて、表示領域に表示される。このため、例えば、自動調整を行う設定が行われた場合は、第１コード画像を端末で表示して決済を可能とするが、自動調整を行う設定が行われなかった場合は、第１コード画像を端末で表示せず決済を不可とするといったことが可能となる。これにより、端末の時刻とサーバの時刻とがずれているような場合や、端末のユーザが不正を行ったような場合であっても、サーバに適切に決済を行わせることができる。
第２実施例は、端末２０が、時計部２９Ａの時刻自動調整の設定（限定ではなく、端末の時刻の自動調整に関する設定の一例）を行う。そして、第１の拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）は、時刻自動調整の設定が「ＯＮ」となっている場合に、表示部２４に表示される構成を示している。
このような構成により得られる効果の一例として、端末の時刻の自動調整に関する設定を端末で行うことができる。また、第１コード画像は、自動調整に関する設定に基づいて、表示領域に表示される。このため、例えば、自動調整を行う設定が行われた場合は、第１コード画像を端末で表示して決済を可能とするが、自動調整を行う設定が行われなかった場合は、第１コード画像を端末で表示せず決済を不可とするといったことが可能となる。これにより、端末の時刻とサーバの時刻とがずれているような場合や、端末のユーザが不正を行ったような場合であっても、サーバに適切に決済を行わせることができる。
＜第２変形例（１）＞
第２実施例において、オフライン決済を行う場合に、端末２０が、時刻自動調整が「ＯＮ」となっているか否かを端末２０のユーザに確認するための通知（報知）を行うようにしてもよいし、そのようにしなくてもよい。
第２実施例において、オフライン決済を行う場合に、端末２０が、時刻自動調整が「ＯＮ」となっているか否かを端末２０のユーザに確認するための通知（報知）を行うようにしてもよいし、そのようにしなくてもよい。
図５−３は、本変形例において端末２０の制御部２１によって実現される機能の一例を示す図である。
制御部２１の決済アプリケーション処理部２１１は、拡張端末表示用コード生成処理部２１１１と、コード表示処理部２１１３との他に、限定ではなく例として、時刻自動調整確認通知処理部２１１４を機能部として含む。
制御部２１の決済アプリケーション処理部２１１は、拡張端末表示用コード生成処理部２１１１と、コード表示処理部２１１３との他に、限定ではなく例として、時刻自動調整確認通知処理部２１１４を機能部として含む。
時刻自動調整確認通知処理部２１１４が、時計部２９Ａの設定が時刻自動調整となっているか否かを自己の端末２０のユーザに確認するための通知を行う機能を有している。
この場合、時刻自動調整確認通知処理部２１１４が、限定ではなく例として、図５−２の処理のＡ４４５の前に、時刻自動調整の設定が「ＯＮ」となっているか否かを端末２０のユーザに確認するためのメッセージ等を含む時刻自動調整確認画面を表示部２４に表示させる。
このようにすることで、オフライン決済を行う場合に、端末の時刻の自動調整に関する設定がどのようになっているかを端末のユーザに確認させることができる。この場合、端末のユーザは、例えば、時刻自動調整の設定が「ＯＦＦ」となっている場合は、時刻自動調整の設定を「ＯＮ」にする。これにより、第１コード画像を表示部２４に表示させ、コードリーダ装置に読み取らせることで、サーバ１０に決済を行わせることができる。
＜第２変形例（２）＞
第２実施例で説明した手法の他に、限定ではなく例として、以下の手法を用いるようにすることも可能である。
第２実施例で説明した手法の他に、限定ではなく例として、以下の手法を用いるようにすることも可能である。
図５−４は、本変形例において端末２０の記憶部２８に記憶される情報の一例を示す図である。
記憶部２８の決済アプリケーションデータ２８３には、端末表示用コードストックデータ２８３１の他に、限定ではなく例として、基準時刻データ２８３４と、算出時刻データ２８３５とが記憶される。
記憶部２８の決済アプリケーションデータ２８３には、端末表示用コードストックデータ２８３１の他に、限定ではなく例として、基準時刻データ２８３４と、算出時刻データ２８３５とが記憶される。
本変形例において、端末２０の制御部２１は、限定ではなく例として、決済アプリケーションの一機能として、オンライン状態において、サーバ１０側の時刻情報を送信するようにサーバ１０に要求して、サーバ１０から時刻情報を取得する。または、定期的なタイミング（例えば１日１回）や特定のタイミング（例えば決済アプリケーションの起動時）で、サーバ１０から端末２０に時刻情報を自動送信する。
制御部２１は、サーバ１０から取得した時刻情報を「基準時刻情報」として決済アプリケーションデータ２８３に基準時刻データ２８３４として記憶させる。つまり、基準時刻情報を決済アプリケーション内で記憶しておく。そして、制御部２１は、決済アプリケーション内で（決済アプリケーションの非起動時はバックグラウンドで）、基準時刻情報が示す時刻（以下、「基準時刻」と称する。）から時間をカウントしていくことで、現在の時刻を算出し、算出時刻情報として決済アプリケーションデータ２８３に算出時刻データ２８３５として記憶させる。
この場合、制御部２１は、オフライン状態となっても、基準時刻からの時間のカウントによって現在の時刻を算出する。そして、図４−１２の拡張端末表示用コード生成処理（Ｘ）（Ａ３５０）において、算出時刻データ２８３５に記憶されている最新の算出時刻情報を含む第１の拡張端末表示用コード画像を生成する。
ここで、決済アプリケーション内で時刻を算出するようにしているのは、前述したように、悪意のあるユーザが自己の端末２０の時刻を過去の時刻に戻すなどして決済を不正に行うような場合があり得るが、このような場合には、端末２０のオペレーティングシステム（ＯＳ）側の時計が操作され易いためである。つまり、本変形例では、オフライン決済を行う場合、ＯＳ側の時刻情報を用いるのではなく、決済アプリケーション内で基準時刻情報に基づいて算出した時刻情報に基づいて処理を行う。
なお、端末２０のユーザが外国にいる場合も想定されるため、限定ではなく例として、タイムゾーンの情報も含めて時刻情報をサーバ１０から端末２０に送信するようにしてもよいし、そのようにしなくてもよい。
また、ここでは決済アプリケーション内で基準時刻情報に基づいて現在の時刻を算出することとしたが、このようにするのではなく、基準時刻情報に基づいて時計部２９Ａで計時される時刻を補正したり、時計部２９Ａで計時される時刻をサーバ１０の時計部１９で計時される時刻に同期させる処理を行うなどするようにしてもよいし、そのようにしなくてもよい。
本変形例は、端末２０が、サーバ１０で管理されている時刻情報（限定ではなく、基準の時刻に関する情報の一例）を制御部２１によって取得する。そして、端末２０は、取得された時刻情報に基づき算出した時刻情報に基づいて、オフライン決済に関する処理を行う構成を示している。
このような構成により得られる効果の一例として、端末は、サーバから制御部によって取得した基準の時刻に関する情報に基づく情報を時刻情報として処理を行うことで、端末の時刻とサーバの時刻とがずれているような場合や、端末のユーザが不正を行ったような場合であっても、サーバに適切に決済を行わせることができる。
このような構成により得られる効果の一例として、端末は、サーバから制御部によって取得した基準の時刻に関する情報に基づく情報を時刻情報として処理を行うことで、端末の時刻とサーバの時刻とがずれているような場合や、端末のユーザが不正を行ったような場合であっても、サーバに適切に決済を行わせることができる。
＜第３実施例＞
前述したように、端末表示用コード画像は、端末２０の表示部２４に表示される画像である。このため、例えば、悪意のある第三者が、他人の端末２０の表示部２４に表示された端末表示用コード画像をカメラで撮影するなどして盗み取り、盗み取った端末表示用コード画像を用いて決済を行うなどの不正（悪用）が行われるリスクがある。
前述したように、端末表示用コード画像は、端末２０の表示部２４に表示される画像である。このため、例えば、悪意のある第三者が、他人の端末２０の表示部２４に表示された端末表示用コード画像をカメラで撮影するなどして盗み取り、盗み取った端末表示用コード画像を用いて決済を行うなどの不正（悪用）が行われるリスクがある。
また、オンライン決済では、端末表示用コードを決済に使用可能な時間（前述した規定時間）として短い時間（例えば「５分」）を設定しておけば、その短い時間しか端末表示用コードを使用することができないため、例えば、ハッカー等によって端末表示用コードを盗まれる可能性は低いと考えられる。
しかしながら、オフライン決済では、前述したように、オンライン状態においてサーバ１０から端末表示用コードを取得して端末２０にストックしておき、オフライン状態において決済を行う必要が生じた場合に、ストックしておいた端末表示用コードを読み出して利用することを可能とするものである。従って、端末表示用コードが端末２０に長時間記憶され得るため、ハッカー等によって端末表示用コードが盗まれて、不正に決済に利用されてしまうリスクがある。
また、ユーザによっては、自身の端末２０で表示された端末表示用コード画像をスクリーンショット等によって保存しておくことがあり得る。この場合、そのユーザ（第１のユーザ）が、端末表示用コードの更新（以下、適宜「リフレッシュ」と称する。）をサーバ１０に依頼したとする。すると、サーバ１０は、上記の端末表示用コードの決済用番号と、第１のユーザとの関連付けを削除する。
しかしながら、決済用番号は有限であるため、その後の何らかのタイミングで、他のユーザ（第２のユーザ）のアカウントと、上記の決済用番号と同じ決済用番号とが関連付けられる可能性がある。この場合、第１のユーザが、スクリーンショット等によって保存しておいた端末表示用コード画像を用いて決済を行ってしまうと、その決済用番号は既に第２のユーザのアカウントと関連付けられているため、第２のユーザのアカウントから決済が行われてしまう。このように、同じ決済用番号が設定されたコードに基づいて他のアカウントから決済が行われてしまうことを「コードの使い回し」と称する。
第３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図６−１は、本実施例において端末２０の表示部２４に表示される決済アプリケーションのトップ画面の一例を示す図である。
このトップ画面の構成は、図３−２と同様であり、ここでは、端末２０のユーザによって「コードアイコン」がタッチされた状態が示されている。
このトップ画面の構成は、図３−２と同様であり、ここでは、端末２０のユーザによって「コードアイコン」がタッチされた状態が示されている。
図６−２は、本実施例において端末２０の表示部２４に表示されるコード表示画面の一例を示す図である。
このコード表示画面には、本実施例における拡張端末表示用コード画像として、バーコードで表される一次元の第４の拡張端末表示用コード画像と、ＱＲコードで表される二次元の第４の拡張端末表示用コード画像ＱＣ４とが、表示画面内の異なる領域にそれぞれ表示されている。また、一次元の第４の拡張端末表示用コード画像の下には、１２桁で表される決済用番号が表示されている。
このコード表示画面には、本実施例における拡張端末表示用コード画像として、バーコードで表される一次元の第４の拡張端末表示用コード画像と、ＱＲコードで表される二次元の第４の拡張端末表示用コード画像ＱＣ４とが、表示画面内の異なる領域にそれぞれ表示されている。また、一次元の第４の拡張端末表示用コード画像の下には、１２桁で表される決済用番号が表示されている。
第４の拡張端末表示用コード画像（限定ではなく、第１情報と、第１情報とは異なる第２情報とに基づく第１コード画像の一例）は、サーバ１０から受信して端末２０でストックされた端末表示用コード画像に格納されている元情報（この例では決済用番号）と、端末２０、または端末２０のユーザを識別するための識別情報（この例ではアプリケーションＩＤ）とがエンコードされたコード画像である。
端末２０、または端末２０のユーザを識別するための識別情報は、第１情報とは異なる第２情報の一例である。
端末２０、または端末２０のユーザを識別するための識別情報は、第１情報とは異なる第２情報の一例である。
本実施例において、第４の拡張端末表示用コード画像は、オンライン状態においてサーバ１０から取得して記憶部２８にストックされた決済用番号と、記憶部２８に記憶されているアプリケーションＩＤとに基づいて、制御部２１の拡張端末表示用コード生成処理部２１１１によって生成される。
オフライン決済を行う場合、端末２０のユーザは、図６−２のコード表示画面をコードレジ６０で店舗の店員に提示し、店舗コードリーダ装置５０で第４の拡張端末表示用コード画像を読み取ってもらうことで決済を行う。この場合、店舗コードリーダ装置５０は、読み取った第４の拡張端末表示用コード画像からデコードによって取得した情報（この例では決済用番号およびアプリケーションＩＤ）を含む決済要求情報をサーバ１０に送信して、サーバ１０に決済を行わせる。
なお、第１実施例等で説明したように、コード使用期限（コード表示期限）を定めるのであれば、時刻情報も拡張端末表示用コード画像に含める必要がある。この場合は、限定ではなく例として、端末２０が、決済用番号と、アプリケーションＩＤとに加えて、時刻情報（タイムスタンプ情報、コード表示時刻等）をエンコードした第４の拡張端末表示用コード画像を生成するようにすればよい。
図６−３は、本実施例における各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末２０の制御部２１が実行する決済アプリケーション処理の一例である第３の決済アプリケーション処理、店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例である第１の店舗決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例である第１の決済管理処理をそれぞれ示している。
図６−３のフローチャートは、図４−１２のフローチャートにおけるＡ３５０のステップをＡ５５０に、Ｂ３５０のステップをＢ５５０に、Ｂ３６０のステップをＢ５６０に、Ｃ１２０のステップをＣ５２０に、Ｃ１６０のステップをＣ５６０に、Ｃ３７０のステップをＣ５７０にそれぞれ書き換えたものである。
Ｃ１１０の後、制御部１１は、端末表示用コード生成処理を行う（Ｃ５２０）。具体的には、制御部１１は、限定ではなく例として、少なくとも決済用番号を元情報として含む端末表示用コード画像を生成する。より具体的には、少なくとも決済用番号をエンコード（符号化）し、図形化（画像化）して、二次元コード（例えばＱＲコード）の画像で表される端末表示用コード画像を生成する。また、制御部１１は、受信したコード生成依頼情報に含まれる端末２０、または端末２０のユーザを識別するための識別情報（例えばアプリケーションＩＤ）と、発生させた決済用番号とを関連付けて記憶部１５に記憶させる。
Ａ２４０の後、オフライン状態において、限定ではなく例として、端末２０のユーザによってコード表示操作がなされると、拡張端末表示用コード生成処理部２１１１が、拡張端末表示用コード生成処理（Ｙ）を行うとともに、コード表示処理部２１１３が、コード表示処理（Ｙ）を行う（Ａ５５０）。
拡張端末表示用コード生成処理（Ｙ）では、限定ではなく例として、端末表示用コードストックデータ２８３１に記憶されている（ストックされている）端末表示用コード画像からデコードによって取得した情報に基づき、決済用番号と、アプリケーションＩＤとを含む第４の拡張端末表示用コード画像を生成する。この場合、前述したように、時刻情報（タイムスタンプ情報、コード表示時刻等）も含めるようにしてもよい。
なお、端末２０、または端末２０のユーザを識別するための識別情報は、アプリケーションＩＤに限らず、限定ではなく例として、自己の端末２０を識別するための端末識別情報（例えば端末ＩＤ）や、自己の端末２０のユーザを識別するためのユーザ識別情報（例えばユーザＩＤ）としてもよいし、そのようにしなくてもよい。
なお、第三者が第４の拡張端末表示用コード画像に格納される情報を解読することができないようにするために、決済用番号や識別情報を暗号化した情報をエンコードするようにしてもよいし、そのようにしなくてもよい。
また、コード表示処理（Ｙ）では、限定ではなく例として、決済用番号と、第４の拡張端末表示用コード画像とをそれぞれ異なる領域に表示させたコード表示画面を表示部２４に表示させる。
なお、拡張端末表示用コード生成処理（Ｙ）において二次元の第４の拡張端末表示用コード画像を生成した場合は、限定ではなく例として、二次元の第４の拡張端末表示用コード画像を表示させるようにすることができる。
また、拡張端末表示用コード生成処理（Ｙ）において一次元の第４の拡張端末表示用コードも生成した場合は、限定ではなく例として、二次元の第４の拡張端末表示用コード画像の他に、一次元の第４の拡張端末表示用コード画像を表示させるようにすることができる。
その後、表示部２４に表示された第４の拡張端末表示用コード画像が端末２０のユーザによって店舗の店員等に提示されると、制御部５１は、端末２０の表示部２４に表示された第４の拡張端末表示用コード画像を、コードリーダ５８に読み取らせる制御を行う（Ｂ５５０）。
その後、制御部５１は、通信Ｉ／Ｆ５４によってサーバ１０にアクセスする。そして、制御部５１は、少なくとも、デコードによって取得した決済用番号およびアプリケーションＩＤと、店舗識別情報と、決済予定金額とを含む決済要求情報を、通信Ｉ／Ｆ５４によってサーバ１０に送信する（Ｂ５６０）。
通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信すると（Ｃ５６０）、制御部１１は、決済処理を行う（Ｃ５７０）。
具体的には、受信した決済要求情報に含まれる決済用番号が、アプリケーションＩＤと関連付けてコード管理データ１５９に記憶されているか否かを判定する。そして、記憶されていると判定した場合、その関連付けられている決済用番号およびアプリケーションＩＤの組み合わせが、受信された決済要求情報に含まれる決済用番号およびアプリケーションＩＤの組み合わせと一致するか否かを判定する。そして、一致した場合は「決済可能」と判定し、そのアプリケーションＩＤの決済管理データに記憶されている残高から決済予定金額を減算して決済する。
なお、上記の決済処理において、記憶されている決済用番号およびアプリケーションＩＤの組み合わせが、受信された決済要求情報に含まれる決済用番号およびアプリケーションＩＤの組み合わせと一致した場合に「決済可能」と判定するのではなく、記憶されているアプリケーションＩＤと、受信された決済要求情報に含まれるアプリケーションＩＤとが一致した場合に「決済可能」と判定するようにしてもよいし、そのようにしなくてもよい。
＜第３実施例の効果＞
第３実施例によれば、例えば、端末表示用コードが端末２０に長時間記憶されることなどに起因して、ハッカー等によって端末表示用コードが盗まれて不正に決済に利用されてしまうことや、コードの使いまわしが発生することを防止することができる。
第３実施例によれば、例えば、端末表示用コードが端末２０に長時間記憶されることなどに起因して、ハッカー等によって端末表示用コードが盗まれて不正に決済に利用されてしまうことや、コードの使いまわしが発生することを防止することができる。
具体的には、第３実施例は、端末２０が、通信Ｉ／Ｆ２２によって、サーバ１０から送信された決済用番号（限定ではなく、第１情報の一例）を受信する。そして、端末２０は、制御部２１によって、少なくとも、受信された決済用番号を記憶部２８に記憶する。また、端末２０は、受信された決済用番号と、アプリケーションＩＤ（限定ではなく、第１情報とは異なる第２情報の一例）とに基づく第４の拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）をコード表示画面の一の領域（限定ではなく、表示領域の一例）に表示する。そして、決済は、第４の拡張端末表示用コード画像に基づきサーバ１０が受信する決済用番号と、アプリケーションＩＤとに基づいてサーバ１０によって実行される構成を示している。
このような構成により得られる効果の一例として、サーバから送信された第１情報を端末の記憶部に記憶しておき、この第１情報と、第１情報とは異なる第２情報とに基づく第１コード画像を端末の表示領域に表示する。そして、決済は、第１コード画像の表示に基づきサーバが受信する第１情報と、第２情報とに基づいてサーバによって実行される。このため、例えば、第２情報と、あらかじめ端末の記憶部に記憶させておいた第１情報とに基づいて、サーバにオフライン決済を行わせることができ、端末のユーザの利便性を向上させることができる。
このような構成により得られる効果の一例として、サーバから送信された第１情報を端末の記憶部に記憶しておき、この第１情報と、第１情報とは異なる第２情報とに基づく第１コード画像を端末の表示領域に表示する。そして、決済は、第１コード画像の表示に基づきサーバが受信する第１情報と、第２情報とに基づいてサーバによって実行される。このため、例えば、第２情報と、あらかじめ端末の記憶部に記憶させておいた第１情報とに基づいて、サーバにオフライン決済を行わせることができ、端末のユーザの利便性を向上させることができる。
また、第３実施例は、第４の拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）は、決済用番号とアプリケーションＩＤとに基づく一つのコード画像である構成を示している。
このような構成により得られる効果の一例として、第１情報と第２情報とに基づく一つのコード画像を表示することで、端末の表示領域に表示された一つのコード画像を外部のコードリーダに読み取らせるだけで、簡単に決済を行わせることができる。
このような構成により得られる効果の一例として、第１情報と第２情報とに基づく一つのコード画像を表示することで、端末の表示領域に表示された一つのコード画像を外部のコードリーダに読み取らせるだけで、簡単に決済を行わせることができる。
また、第３実施例は、決済は、第４の拡張端末表示用コード画像が店舗等のコード読み取り装置に読み取られることに基づき、決済用番号とアプリケーションＩＤとがサーバ１０に送付され、決済用番号とアプリケーションＩＤとに基づいて、サーバ１０によって実行される構成を示している。
このような構成により得られる効果の一例として、決済は、第１コード画像がコード読み取り装置に読み取られることに基づき、第１情報と第２情報とがサーバに送付されることで、第１情報と第２情報とに基づいてサーバで実行されるため、端末の表示領域に表示された第１コード画像に基づいて、サーバに簡単に決済を行わせることができる。
このような構成により得られる効果の一例として、決済は、第１コード画像がコード読み取り装置に読み取られることに基づき、第１情報と第２情報とがサーバに送付されることで、第１情報と第２情報とに基づいてサーバで実行されるため、端末の表示領域に表示された第１コード画像に基づいて、サーバに簡単に決済を行わせることができる。
また、第３実施例は、決済は、サーバ１０で受信されたアプリケーションＩＤ（限定ではなく、第２情報の一例）と、サーバ１０の記憶部１５に記憶され、決済用番号と関連付けられたアプリケーションＩＤ（限定ではなく例として、第３情報の一例）とに基づいてサーバ１０によって実行される構成を示している。
このような構成により得られる効果の一例として、第２情報と、サーバに記憶され、第１情報と関連付けられた第３情報とに基づいて、サーバに簡易かつ適切に決済を行わせることができる。
このような構成により得られる効果の一例として、第２情報と、サーバに記憶され、第１情報と関連付けられた第３情報とに基づいて、サーバに簡易かつ適切に決済を行わせることができる。
また、第３実施例は、決済は、サーバ１０で受信されたアプリケーションＩＤ（限定ではなく、第２情報の一例）と、サーバ１０の記憶部１５に記憶され、決済用番号と関連付けられたアプリケーションＩＤ（限定ではなく例として、第３情報の一例）とが一致した場合、サーバ１０によって実行される構成を示している。
このような構成により得られる効果の一例として、第２情報と第３情報とが一致した場合、サーバによって決済が実行されるため、誤りなくサーバに決済を行わせることができる。
このような構成により得られる効果の一例として、第２情報と第３情報とが一致した場合、サーバによって決済が実行されるため、誤りなくサーバに決済を行わせることができる。
また、第３実施例は、端末２０、または端末２０のユーザを識別するための識別情報は、アプリケーションＩＤや端末ＩＤ、ユーザＩＤである構成を示している。
このような構成により得られる効果の一例として、端末、または端末のユーザを識別するための識別情報を第２情報とすることで、決済予定の端末、または端末のユーザが、正当な端末、または正当な端末のユーザであるか否かをサーバに確認させることができる。
このような構成により得られる効果の一例として、端末、または端末のユーザを識別するための識別情報を第２情報とすることで、決済予定の端末、または端末のユーザが、正当な端末、または正当な端末のユーザであるか否かをサーバに確認させることができる。
また、第３実施例は、端末２０が、決済アプリケーションプログラム２８２（限定ではなく、プログラムの一例）を記憶するメモリから決済アプリケーションプログラム２８２を読み出し、決済アプリケーションプログラム２８２に基づいて決済アプリケーション処理を実行するプロセッサーを備える。そして、プロセッサーは、サーバ１０から送信された決済用番号（限定ではなく、第１情報の一例）を、通信Ｉ／Ｆ２２によって受信し、受信された決済用番号を記憶部２８に記憶し、決済用番号と、アプリケーションＩＤ（限定ではなく、第１情報とは異なる第２情報の一例）とに基づく第４の拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）をコード表示画面の一の領域（限定ではなく、端末の表示領域の一例）に表示する。そして、決済は、第４の拡張端末表示用コード画像の表示に基づきサーバ１０が受信する決済用番号と、アプリケーションＩＤとに基づいてサーバ１０によって実行される構成を示している。
このような構成により得られる効果の一例として、例えば、第２情報と、あらかじめ端末の記憶部に記憶させておいた第１情報とに基づいて、サーバにオフライン決済を行わせることが可能となり、端末のユーザの利便性を向上させることができる。
このような構成により得られる効果の一例として、例えば、第２情報と、あらかじめ端末の記憶部に記憶させておいた第１情報とに基づいて、サーバにオフライン決済を行わせることが可能となり、端末のユーザの利便性を向上させることができる。
また、第３実施例は、サーバ１０が、決済用番号（限定ではなく、第１情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信する。また、サーバ１０は、端末２０のコード表示画面の一の領域（限定ではなく、表示領域の一例）に表示された、決済用番号とアプリケーションＩＤ（限定ではなく、第１情報とは異なる第２情報の一例）とに基づく第４の拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）が店舗コードリーダ装置５０によって読み取られたことに基づき、店舗コードリーダ装置５０から送信された、第１コード画像に基づく決済用番号と、アプリケーションＩＤとを通信Ｉ／Ｆ１４によって受信する。そして、サーバ１０は、決済用番号と、アプリケーションＩＤと、コード管理データ１５９に記憶され、決済用番号と関連付けられたアプリケーションＩＤ（限定ではなく、サーバの記憶部に記憶され、第１情報と関連付けられた第３情報の一例）とに基づいて、決済を行う構成を示している。
このような構成により得られる効果の一例として、サーバは、第１情報と、第２情報と、サーバの記憶部に記憶され、第１情報と関連付けられた第３情報とに基づいて、誤りなく決済を行うことができる。
このような構成により得られる効果の一例として、サーバは、第１情報と、第２情報と、サーバの記憶部に記憶され、第１情報と関連付けられた第３情報とに基づいて、誤りなく決済を行うことができる。
＜第３変形例（１）＞
第３実施例では、本開示における「第２情報」を、端末２０を識別するための端末識別情報（例えば端末ＩＤ）や、端末２０のユーザを識別するためのユーザ識別情報（例えばユーザＩＤ）、決済アプリケーションのアカウント情報（例えばアプリケーションＩＤ）等の情報としたが、これらに限定されない。例えば、前述した決済用番号（第１情報）とは異なる番号であってランダムに発生させた番号（以下、「特別番号」と称する。）や、前述したトークンとは異なるトークン（以下、「特別トークン」と称する。）を端末２０側で発行することとし、これらの情報を「第２情報」としてもよいし、そのようにしなくてもよい。
第３実施例では、本開示における「第２情報」を、端末２０を識別するための端末識別情報（例えば端末ＩＤ）や、端末２０のユーザを識別するためのユーザ識別情報（例えばユーザＩＤ）、決済アプリケーションのアカウント情報（例えばアプリケーションＩＤ）等の情報としたが、これらに限定されない。例えば、前述した決済用番号（第１情報）とは異なる番号であってランダムに発生させた番号（以下、「特別番号」と称する。）や、前述したトークンとは異なるトークン（以下、「特別トークン」と称する。）を端末２０側で発行することとし、これらの情報を「第２情報」としてもよいし、そのようにしなくてもよい。
この場合は、限定ではなく例として、オンライン状態において端末２０からサーバ１０にコード生成依頼情報を送信する際に、上記の特別番号や特別トークンをサーバ１０に送信する。そして、サーバ１０が、端末表示用コード生成処理において、端末２０から受信した特別番号や特別トークンと、決済用番号とを関連付けて記憶するようにすればよい。または、アプリケーションＩＤと決済用番号とに加えて、端末２０から受信した特別番号や特別トークンを関連付けて記憶するようにすればよい。
また、限定ではなく例として、上記の特別番号や特別トークンをサーバ１０側で発行して端末２０に送信するようにしてもよいし、そのようにしなくてもよい。この場合は、サーバ１０が、端末表示用コード生成処理において、発行した特別番号や特別トークンと、決済用番号とを関連付けて記憶するようにすればよい。または、アプリケーションＩＤと決済用番号とに加えて、発行した特別番号や特別トークンを関連付けて記憶するようにすればよい。
この場合、サーバ１０は、特別番号や特別トークンをエンコードした端末表示用コード画像を生成して端末２０に送信するようにしてもよいし、そのようにしなくてもよい。
また、特別番号や特別トークンは端末表示用コード画像に含めないようにし、サーバ１０は、決済用番号がエンコードされた端末表示用コードとは別に、特別番号や特別トークンを端末２０に送信するようにしてもよいし、そのようにしなくてもよい。
また、特別番号や特別トークンは端末表示用コード画像に含めないようにし、サーバ１０は、決済用番号がエンコードされた端末表示用コードとは別に、特別番号や特別トークンを端末２０に送信するようにしてもよいし、そのようにしなくてもよい。
ここで、上記の特別番号は、決済用番号とは異なる番号となるようにする必要がある。そこで、限定ではなく例として、特別番号を、決済用番号よりも桁数が少ない番号とすることができる。例えば、決済用番号を１０桁〜１２桁とするのであれば、限定ではなく例として、特別番号は１０桁未満の番号（例えば６桁〜９桁）とすることができる。
また、前述したように、決済用番号に代えて、トークンを端末表示用コードや拡張端末表示用コードに含めるようにすることもできる。この場合は、端末表示用コードや拡張端末表示用コードに含めるトークンと、上記の特別トークンとは、異なるものとなるようにする必要がある。
＜第３変形例（１）の効果＞
本変形例は、特別番号や特別トークン（限定ではなく、第２情報の一例）は、端末２０によって生成されてサーバ１０に送信される構成を示している。
このような構成により得られる効果の一例として、端末は、生成した第２情報に基づいて、サーバに決済を行わせることができる。
本変形例は、特別番号や特別トークン（限定ではなく、第２情報の一例）は、端末２０によって生成されてサーバ１０に送信される構成を示している。
このような構成により得られる効果の一例として、端末は、生成した第２情報に基づいて、サーバに決済を行わせることができる。
また、本変形例は、特別番号や特別トークン（限定ではなく、第２情報の一例）は、サーバ１０から端末２０に送付される構成を示している。
このような構成により得られる効果の一例として、端末は、第２情報をサーバから簡単に取得することができる。
このような構成により得られる効果の一例として、端末は、第２情報をサーバから簡単に取得することができる。
また、本変形例は、特別番号（限定ではなく、第２情報の一例）は、決済用番号とは異なる番号のコード情報（限定ではなく、第１情報とは異なるコード情報の一例）であり、特別トークン（限定ではなく、第２情報の一例）は、トークンとは異なるコード情報（限定ではなく、第２情報とは異なるコード情報の一例）である構成を示している。
このような構成により得られる効果の一例として、第１情報とは異なるコード情報を第２情報とすることで、誤りなくサーバに決済を行わせることができる。
このような構成により得られる効果の一例として、第１情報とは異なるコード情報を第２情報とすることで、誤りなくサーバに決済を行わせることができる。
＜第３変形例（２）＞
第３実施例で説明した手法の他に、以下のような手法を用いるようにすることもできる。
具体的には、端末２０は、定期的なタイミング（例えば、３時間に１回、６時間に１回、１２時間に１回、１日１回）で、オンライン状態である場合、コード生成依頼情報をサーバ１０に送信して、サーバ１０から端末表示用コードを受信する。そして、受信された端末表示用コードで、端末表示用コードストックデータ２８３１に記憶済みの端末表示用コードを更新（リフレッシュ）する。
第３実施例で説明した手法の他に、以下のような手法を用いるようにすることもできる。
具体的には、端末２０は、定期的なタイミング（例えば、３時間に１回、６時間に１回、１２時間に１回、１日１回）で、オンライン状態である場合、コード生成依頼情報をサーバ１０に送信して、サーバ１０から端末表示用コードを受信する。そして、受信された端末表示用コードで、端末表示用コードストックデータ２８３１に記憶済みの端末表示用コードを更新（リフレッシュ）する。
また、特定のタイミングで、サーバ１０から端末表示用コードを取得してリフレッシュを行うようにすることもできる。具体的には、限定ではなく例として、端末２０で前回決済アプリケーションが実行されてからの経過時間が設定時間を超えている場合に、端末２０側で自動的にサーバ１０から端末表示用コードを取得してリフレッシュを行うようにする。
また、決済アプリケーションの表示画面にリフレッシュボタンやリフレッシュアイコン等の操作用画像を表示し、端末２０のユーザが、これらの操作用画像を操作することにより、オンライン状態であればいつでもサーバ１０から端末表示用コードを取得してリフレッシュさせることを可能としてもよい。この場合は、例えば、端末２０のユーザが危険を感じた場合に、操作用画像を操作して、リフレッシュを行わせることができる。
＜第３変形例（３）＞
第１実施例と第１変形例で説明した時刻情報を、アプリケーションＩＤ等の識別情報とともに、第２の拡張端末表示用コードに含めるようにしてもよいし、そのようにしなくてもよい。この場合は、第１実施例で記載した内容と、第１変形例（１）〜第１変形例（５）に記載した内容とをそれぞれ適用することができる。
第１実施例と第１変形例で説明した時刻情報を、アプリケーションＩＤ等の識別情報とともに、第２の拡張端末表示用コードに含めるようにしてもよいし、そのようにしなくてもよい。この場合は、第１実施例で記載した内容と、第１変形例（１）〜第１変形例（５）に記載した内容とをそれぞれ適用することができる。
＜第３変形例（４）＞
第３実施例で説明したコード表示画面は、あくまでも一例に過ぎず、適宜設計変更可能である。
第３実施例で説明したコード表示画面は、あくまでも一例に過ぎず、適宜設計変更可能である。
例えば、コード画像に格納可能な情報量の制約等によって、第１情報と第２情報との両方の情報をエンコードすることが困難な場合もあり得る。そこで、これらの情報を別々にエンコードした２つの拡張端末表示用コード画像を生成して表示させるようにすることも可能である。
図６−４は、本変形例におけるコード表示画面の一例を示す図である。
このコード表示画面では、拡張端末表示用コード画像として、二次元の第５の拡張端末表示用コード画像ＱＣ５と、二次元の第６の拡張端末表示用コード画像ＱＣ６との２つのコード画像が並べて表示されている。
このコード表示画面では、拡張端末表示用コード画像として、二次元の第５の拡張端末表示用コード画像ＱＣ５と、二次元の第６の拡張端末表示用コード画像ＱＣ６との２つのコード画像が並べて表示されている。
第５の拡張端末表示用コード画像ＱＣ５は、限定ではなく例として、サーバ１０から受信して端末２０でストックされた端末表示用コード画像に格納されている元情報（この例では決済用番号）がエンコードされたコード画像である。
第６の拡張端末表示用コード画像ＱＣ６は、限定ではなく例として、端末２０、または端末２０のユーザを識別するための識別情報（この例ではアプリケーションＩＤ）がエンコードされたコード画像である。
第６の拡張端末表示用コード画像ＱＣ６は、限定ではなく例として、端末２０、または端末２０のユーザを識別するための識別情報（この例ではアプリケーションＩＤ）がエンコードされたコード画像である。
なお、図６−４のコード表示画面における第５の拡張端末表示用コード画像ＱＣ５と第６の拡張端末表示用コード画像ＱＣ６との配置は、あくまでも一例に過ぎず、適宜設定変更可能である。横方向に配置する他、縦方向や斜め方向に配置してもよい。また、２つのコード画像の表示位置を逆にしてもよい。
本変形例では、図６−３の拡張端末表示用コード生成処理（Ｙ）において、端末表示用コード生成処理部１１１１は、第５の拡張端末表示用コード画像と、第６の拡張端末表示用コード画像とを生成する。
具体的には、端末表示用コードストックデータ２８３１に端末表示用コード画像がストックされている場合は、これをそのまま第５の拡張端末表示用コード画像とする。一方、端末表示用コードストックデータ２８３１に決済用番号がストックされている場合は、決済用番号をエンコード（符号化）し、図形化（画像化）して、第５の拡張端末表示用コード画像を生成する。
また、記憶部２８に記憶されているアプリケーションＩＤをエンコード（符号化）し、図形化（画像化）して、第６の拡張端末表示用コード画像を生成する。
また、記憶部２８に記憶されているアプリケーションＩＤをエンコード（符号化）し、図形化（画像化）して、第６の拡張端末表示用コード画像を生成する。
なお、店舗によっては、二次元コードの読み取りには対応していないが、一次元コードの読み取りには対応可能な場合がある。そこで、端末表示用コード生成処理部１１１１が、二次元コード（限定ではなく例としてＱＲコード）に加えて、一次元コード（限定ではなく例としてバーコード）で表される第５の拡張端末表示用コード画像と第６の拡張端末表示用コード画像とを生成するようにしてもよいし、そのようにしなくてもよい。
オフライン決済を行う場合、端末２０のユーザは、図６−４のコード表示画面をコードレジ６０で店舗の店員に提示し、第５の拡張端末表示用コード画像と、第６の拡張端末表示用コード画像とを店舗コードリーダ装置５０で読み取ってもらうことで決済を行う。この場合、店舗コードリーダ装置５０は、読み取った第５の拡張端末表示用コード画像からデコードによって取得した情報（この例では決済用番号）と、読み取った第６の拡張端末表示用コード画像からデコードによって取得した情報（この例ではアプリケーションＩＤ）とを含む決済要求情報をサーバ１０に送信して、サーバ１０に決済を行わせる。
なお、第５の拡張端末表示用コード画像と、第６の拡張端末表示用コード画像とは、店舗コードリーダ装置５０によって別々に読み取る方法に限らず、第５の拡張端末表示用コード画像と、第６の拡張端末表示用コード画像とがコードリーダ５８の１つの枠内に入ったことを検知したことに基づいて、２つの拡張端末表示用コード画像を一緒に（まとめて）読み取るようにしてもよいし、そのようにしなくてもよい。
＜第３変形例（４）の効果＞
本変形例は、拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）は、コード表示画面の一の領域（限定ではなく、第１領域の一例）に表示される第５の拡張端末表示用コード画像（限定ではなく、第２コード画像の一例）と、コード表示画面の他の領域（限定ではなく、第２領域の一例）に表示される第６の拡張端末表示用コード画像（限定ではなく、第３コード画像の一例）とを含む構成を示している。
このような構成により得られる効果の一例として、第１情報に基づく第２コード画像を第１領域に表示させ、第２情報に基づく第３コード画像を第２領域に表示させることで、例えば、第２情報をコード画像に含めることが困難な場合であっても、第３コード画像を外部の読み取り装置に読み取らせることで、第２情報をサーバに送付して決済を行わせることができる。
本変形例は、拡張端末表示用コード画像（限定ではなく、第１コード画像の一例）は、コード表示画面の一の領域（限定ではなく、第１領域の一例）に表示される第５の拡張端末表示用コード画像（限定ではなく、第２コード画像の一例）と、コード表示画面の他の領域（限定ではなく、第２領域の一例）に表示される第６の拡張端末表示用コード画像（限定ではなく、第３コード画像の一例）とを含む構成を示している。
このような構成により得られる効果の一例として、第１情報に基づく第２コード画像を第１領域に表示させ、第２情報に基づく第３コード画像を第２領域に表示させることで、例えば、第２情報をコード画像に含めることが困難な場合であっても、第３コード画像を外部の読み取り装置に読み取らせることで、第２情報をサーバに送付して決済を行わせることができる。
なお、上記の他にも、限定ではなく例として、拡張端末表示用コード画像が表示される領域とは異なる領域に、アプリケーションＩＤ等の識別情報を表示させるようにしてもよいし、そのようにしなくてもよい。
＜第４実施例＞
第４実施例は、サーバ１０から送信される端末表示用コードを端末２０の記憶部２８に記憶してストックする内容に関して、所定の条件の成立に応じて、端末表示用コードを補充することに関する実施例である。
第４実施例は、サーバ１０から送信される端末表示用コードを端末２０の記憶部２８に記憶してストックする内容に関して、所定の条件の成立に応じて、端末表示用コードを補充することに関する実施例である。
第４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図７−１は、本実施例において端末２０の記憶部２８に記憶される情報の一例を示す図である。
本実施例において、決済アプリケーションデータ２８３には、限定ではなく例として、コード補充条件データ２８３８が含まれる。
本実施例において、決済アプリケーションデータ２８３には、限定ではなく例として、コード補充条件データ２８３８が含まれる。
コード補充条件データ２８３８は、端末表示用コードを補充する条件（以下、「コード補充条件」と称する。）が設定されたデータであり、そのデータ構成の一例を図７−２に示す。
コード補充条件データ２８３８には、限定ではなく例として、条件種別と、条件Ｎｏと、コード補充条件とが関連付けて記憶される。
条件種別は、コード補充条件の種別であり、限定ではなく例として、「ＣＰ１（通信）」と「ＣＰ２（その他）」とがこれに含まれる。
条件Ｎｏは、その条件種別に含まれるコード補充条件の番号である。
コード補充条件は、その条件Ｎｏに対応するコード補充条件の内容である。
条件種別は、コード補充条件の種別であり、限定ではなく例として、「ＣＰ１（通信）」と「ＣＰ２（その他）」とがこれに含まれる。
条件Ｎｏは、その条件種別に含まれるコード補充条件の番号である。
コード補充条件は、その条件Ｎｏに対応するコード補充条件の内容である。
具体的に説明する。
（Ａ）条件種別「ＣＰ１（通信）」
条件種別「ＣＰ１（通信）」には、限定ではなく例として、「ＣＰ１−１」〜「ＣＰ１−３」の条件が定められている。
（Ａ）条件種別「ＣＰ１（通信）」
条件種別「ＣＰ１（通信）」には、限定ではなく例として、「ＣＰ１−１」〜「ＣＰ１−３」の条件が定められている。
「ＣＰ１−１」は、コード補充条件を「オフライン決済＆端末用決済完了通知受信」とする条件である。これは、サーバ１０によりオフライン決済が行われ、端末２０がオフライン状態からオンライン状態に復帰した後、サーバ１０から端末用決済完了通知を受信した場合に、端末表示用コードを補充することを示す条件である。つまり、先にサーバ１０から取得して端末表示用コードストックデータ２８３１に記憶しておいた端末表示用コードを用いて、サーバ１０によるオフライン決済が完了したことに基づいて、先にサーバ１０から取得した端末表示用コードとは異なる端末表示用コードを取得する。
この場合は、限定ではなく例として、サーバ１０によりオフライン決済が行われ、サーバ１０から端末用決済完了通知を受信した後、端末２０からサーバ１０に対して端末表示用コードを要求するリクエストを送信し、そのリクエストを受けてサーバ１０から送信された端末表示用コードを、端末表示用コードストックデータ２８３１に記憶させるようにすることができる。
なお、オフライン状態からオンライン状態に復帰した後、サーバ１０から端末用決済完了通知を受信した場合であっても、端末２０の通信状況が不安定な場合がある。そこで、サーバ１０から端末用決済完了通知を受信した後、通信「ＯＮ」となったタイミングや、通信状況が安定したタイミングで、端末表示用コードをサーバ１０に要求して取得するようにしてもよいし、そのようにしなくてもよい。
「ＣＰ１−２」は、コード補充条件を「決済アプリケーション起動＆サーバと通信接続」とする条件である。これは、端末２０で決済アプリケーションが起動された後、サーバ１０と通信接続された場合に、端末表示用コードを補充することを示す条件である。
この場合は、限定ではなく例として、端末２０で決済アプリケーションが起動され、サーバ１０と通信接続された場合に、端末２０からサーバ１０に対して端末表示用コードを要求するリクエストを送信する。そして、端末２０は、リクエストに応じてサーバ１０から送信される端末表示用コードを、端末表示用コードストックデータ２８３１に記憶させるようにすることができる。
なお、上記において、端末２０で決済アプリケーションが起動され、サーバ１０と通信接続された場合に、端末２０からサーバ１０に対して、端末表示用コードと、最新の残高とを要求するリクエストを送信する。そして、端末２０は、そのリクエストに応じてサーバ１０から送信される端末表示用コードを端末表示用コードストックデータ２８３１に記憶させるとともに、そのリクエストに応じてサーバ１０から送信される最新の残高に基づいて、端末２０の決済アプリケーションデータ２８３で記憶している残高を更新するようにしてもよいし、そのようにしなくてもよい。
「ＣＰ１−３」は、コード補充条件を「電磁波環境変化」とする条件である。
なお、一般的に通信には電波が使用されるため、「電波環境変化」としてもよい。また、「通信環境変化」としてもよい。これは、端末２０の電磁波環境等が変化した場合に、端末表示用コードを補充することを示す条件である。
なお、一般的に通信には電波が使用されるため、「電波環境変化」としてもよい。また、「通信環境変化」としてもよい。これは、端末２０の電磁波環境等が変化した場合に、端末表示用コードを補充することを示す条件である。
限定ではなく例として、電磁波の強さ（電波の強さ）に基づいて、端末２０の電磁波環境を「強電磁波環境」、「中電磁波環境」、「弱電磁波環境」の３つに分ける。ここで、電磁波の強さは、限定ではなく例として、電界強度、磁界強度、電力密度（電力束密度）等の指標値で表すことができる。これらの指標値は、端末２０で受信される信号の強度（信号強度、受信信号強度）と言うこともできる。
限定ではなく例として、電磁波の強さに基づき、端末２０の電磁波環境が「中電磁波環境」から「弱電磁波環境」に変化したことを検知した場合に、オフライン状態となる可能性があるため、端末表示用コードを補充するようにすることができる。この場合は、限定ではなく例として、電磁波環境の変化を検知した場合に、端末２０からサーバ１０に対して端末表示用コードを要求するリクエストを送信し、そのリクエストを受けてサーバ１０から送信された端末表示用コードを、端末表示用コードストックデータ２８３１に記憶させるようにすることができる。
なお、上記の電磁波環境の変化の判定は、例えば上記の指標値で表される電磁波の強さに基づいて行うようにしてもよいし、そのようにしなくてもよい。例えば、電磁波の強さに弱電界に対応する閾値強度を設定しておき、電磁波の強さが閾値強度以下（または閾値強度未満）となった場合に、電界環境が変化したと判定するようにしてもよいし、そのようにしなくてもよい。
（Ｂ）条件種別「ＣＰ２（その他）」
条件種別「ＣＰ２（その他）」には、限定ではなく例として、「ＣＰ２−１」〜「ＣＰ２−３」の条件が定められている。
条件種別「ＣＰ２（その他）」には、限定ではなく例として、「ＣＰ２−１」〜「ＣＰ２−３」の条件が定められている。
「ＣＰ２−１」は、コード補充条件を「プッシュ通知受信＆コード補充操作検知」とする条件である。プッシュ通知とは、限定ではなく例として、サーバ１０から定期的なタイミング等で送信される、端末表示用コードのストックをユーザに確認するための通知、または、端末表示用コードの取得を希望するか否かをユーザに確認するための通知を示す。これは、端末２０が、サーバ１０からプッシュ通知を受信し、受信したプッシュ通知に基づいて、端末２０のユーザによる入力部への端末表示用コードの補充を行うための操作（以下、「コード補充操作」と称する。）を検知した場合に、端末表示用コードを補充することを示す条件である。
「ＣＰ２−２」は、コード補充条件を「コード補充操作検知」とする条件である。これは、端末２０のユーザによる入力部へのコード補充操作を検知した場合に、端末表示用コードを補充することを示す条件である。
「ＣＰ２−３」は、コード補充条件を「残高更新操作検知」とする条件である。これは、端末２０のユーザによる、決済アプリケーションを利用した決済に使用可能な残高を更新するための操作（以下、「残高更新操作」と称する。）を検知した場合に、端末表示用コードを補充することを示す条件である。
オフライン状態では、端末２０はサーバ１０と通信することができない。このため、オフライン決済を行った場合、サーバ１０側で管理している残高は更新されるが、オンライン状態に復帰してサーバ１０から端末用決済完了通知を受信するまでの間は、端末２０側で記憶している残高は更新されない。このため、決済アプリケーションのアプリケーション画面に表示される残高は、最新の残高ではない可能性がある。
そこで、「ＣＰ２−３」の条件では、端末２０は、決済アプリケーションの実行中に、ユーザによる入力部への残高更新操作を検知した場合に、サーバ１０に対して端末表示用コードを要求するリクエストを送信する。そして、そのリクエストを受けてサーバ１０から送信された端末表示用コードを、端末表示用コードストックデータ２８３１に記憶させる。
なお、「ＣＰ２−３」のコード補充条件を「残高更新実行」とし、決済アプリケーション内で残高更新操作を検知したことに基づいて、端末２０がサーバ１０と通信を行って残高を更新したことを契機として、端末表示用コードを補充するようにしてもよいし、そのようにしなくてもよい。
また、前述したように、端末２０がオフライン状態からオンライン状態に復帰すると、サーバ１０から端末用決済完了通知を受信する。この場合、端末２０が、受信した端末用決済完了通知に基づいて残高を更新するようにし、この残高更新の実行を契機として、端末表示用コードを補充するようにしてもよいし、そのようにしなくてもよい。
端末２０の制御部２１は、コード補充条件データ２８３８に基づいて、限定ではなく例として、上記の複数のコード補充条件のうちの少なくともいずれか１つの条件が成立したか否かを判定する。そして、成立したと判定した場合は、サーバ１０に対して端末表示用コードを要求するリクエストを送信する。そして、そのリクエストを受けてサーバ１０から送信された端末表示用コードを、端末表示用コードストックデータ２８３１に記憶させる。
なお、上記のコード補充条件は、あくまでも一例を示したものに過ぎず、これら以外の条件を定めておくようにすることもできる。
また、限定ではなく例として、上記のコード補充条件のうちの２以上の条件を組み合わせた条件を、コード補充条件として定めておくようにすることもできる。
また、限定ではなく例として、上記のコード補充条件のうちのいずれの条件を適用するかを、端末２０のユーザに選択させるなどして設定しておくようにすることもできる。
また、限定ではなく例として、上記のコード補充条件のうちの２以上の条件を組み合わせた条件を、コード補充条件として定めておくようにすることもできる。
また、限定ではなく例として、上記のコード補充条件のうちのいずれの条件を適用するかを、端末２０のユーザに選択させるなどして設定しておくようにすることもできる。
＜第４実施例の効果＞
第４実施例は、端末２０は、あらかじめオフライン状態においてサーバ１０から取得した決済用番号（限定ではなく、第１情報の一例）に基づくサーバ１０による決済の完了に基づいて、上記の決済用番号とは異なる決済用番号（限定ではなく、第１情報とは異なる第２情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、受信された決済用番号を記憶部２８に記憶させる構成を示している。
このような構成により得られる効果の一例として、端末は、第１情報に基づく決済の完了によって第１情報が消費された場合であっても、第１情報とは異なる第２情報を受信して記憶部に記憶しておくことで、記憶しておいた第２情報に基づいて別の決済を行うことが可能となり、ユーザの利便性を向上させることができる。
第４実施例は、端末２０は、あらかじめオフライン状態においてサーバ１０から取得した決済用番号（限定ではなく、第１情報の一例）に基づくサーバ１０による決済の完了に基づいて、上記の決済用番号とは異なる決済用番号（限定ではなく、第１情報とは異なる第２情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、受信された決済用番号を記憶部２８に記憶させる構成を示している。
このような構成により得られる効果の一例として、端末は、第１情報に基づく決済の完了によって第１情報が消費された場合であっても、第１情報とは異なる第２情報を受信して記憶部に記憶しておくことで、記憶しておいた第２情報に基づいて別の決済を行うことが可能となり、ユーザの利便性を向上させることができる。
また、第４実施例は、端末２０が、通信Ｉ／Ｆ２２の通信状況に基づいて、上記の決済用番号とは異なる決済用番号を通信Ｉ／Ｆ２２によって受信する構成を示している。
このような構成により得られる効果の一例として、端末は、例えば、通信部の通信状況が改善された場合に、第１情報とは異なる第２情報を通信部を介して受信することができる。
このような構成により得られる効果の一例として、端末は、例えば、通信部の通信状況が改善された場合に、第１情報とは異なる第２情報を通信部を介して受信することができる。
また、第４実施例は、端末２０が、通信Ｉ／Ｆ２２による通信が行える場合、上記の決済用番号とは異なる決済用番号を要求するリクエストを通信Ｉ／Ｆ２２によってサーバ１０に送信する構成を示している。
このような構成により得られる効果の一例として、端末は、通信部による通信が行える場合、第２情報を取得するための情報を通信部を介してサーバに送信して、サーバから第２情報を受信することができる。
このような構成により得られる効果の一例として、端末は、通信部による通信が行える場合、第２情報を取得するための情報を通信部を介してサーバに送信して、サーバから第２情報を受信することができる。
また、第４実施例は、端末２０は、端末２０のユーザによる、残高更新操作（限定ではなく、決済に使用可能な電子貨幣の残高の更新に関する入力の一例）に基づいて、上記の決済用番号とは異なる決済用番号を通信Ｉ／Ｆ２２によって受信する構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる、決済に使用可能な電子貨幣の残高の更新に関する入力に基づいて、第１情報とは異なる第２情報を通信部を介して受信するため、端末のユーザによる入力を契機として第２情報を取得することが可能となり、ユーザの利便性を向上させることができる。
このような構成により得られる効果の一例として、端末のユーザによる、決済に使用可能な電子貨幣の残高の更新に関する入力に基づいて、第１情報とは異なる第２情報を通信部を介して受信するため、端末のユーザによる入力を契機として第２情報を取得することが可能となり、ユーザの利便性を向上させることができる。
＜第４変形例＞
第４実施例において、端末２０からのリクエストに応じてサーバ１０が端末表示用コードを端末２０に送信するようにするのではなく、端末２０からのリクエストなしにサーバ１０が端末表示用コードを端末２０に送信するようにしてもよいし、そのようにしなくてもよい。
第４実施例において、端末２０からのリクエストに応じてサーバ１０が端末表示用コードを端末２０に送信するようにするのではなく、端末２０からのリクエストなしにサーバ１０が端末表示用コードを端末２０に送信するようにしてもよいし、そのようにしなくてもよい。
本明細書では、端末２０からのリクエストなしにサーバ１０が情報（またはデータ）を端末２０に送信すること（サーバ１０が自発的に情報（またはデータ）を送信すること）を、「プッシュ送信」と称する。
この場合は、限定ではなく例として、定期的なタイミング（例えば１日１回）や特定のタイミング（例えば決済アプリケーションの起動時）で、サーバ１０から端末２０に端末表示用コード（端末表示用コード画像または決済用番号）をプッシュ送信する。そして、端末２０は、サーバ１０から送信された端末表示用コードを、端末表示用コードストックデータ２８３１に記憶させる。
本変形例は、決済用番号（限定ではなく、第１情報とは異なる第２情報の一例）がサーバ１０から端末２０にプッシュ送信される構成を示している。
このような構成により得られる効果の一例として、端末からサーバにリクエストを行う必要なく、第１情報とは異なる第２情報をサーバから取得することができる。
このような構成により得られる効果の一例として、端末からサーバにリクエストを行う必要なく、第１情報とは異なる第２情報をサーバから取得することができる。
＜第５実施例＞
第４実施例で説明したように、オフライン状態では、端末２０はサーバ１０と通信することができない。このため、オフライン決済を行った場合、サーバ１０側で管理している残高は更新されるが、少なくともオンライン状態に復帰してサーバ１０から端末用決済完了通知を受信するまでの間は、端末２０側で記憶している残高は更新されないことになる。つまり、決済アプリケーションのアプリケーション画面に表示される残高は、最新のものではない可能性がある。
第４実施例で説明したように、オフライン状態では、端末２０はサーバ１０と通信することができない。このため、オフライン決済を行った場合、サーバ１０側で管理している残高は更新されるが、少なくともオンライン状態に復帰してサーバ１０から端末用決済完了通知を受信するまでの間は、端末２０側で記憶している残高は更新されないことになる。つまり、決済アプリケーションのアプリケーション画面に表示される残高は、最新のものではない可能性がある。
第５実施例は、このような問題を解決するための手法に関する実施例である。
第５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
第５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
（１）示唆報知
端末２０の制御部２１は、限定ではなく例として、前述した各種の拡張端末表示用コードを表示部２４に表示させる場合、電子貨幣の使用の有無に関わらず残高が最新ではない可能性を示唆する報知を行う。
端末２０の制御部２１は、限定ではなく例として、前述した各種の拡張端末表示用コードを表示部２４に表示させる場合、電子貨幣の使用の有無に関わらず残高が最新ではない可能性を示唆する報知を行う。
具体的には、限定ではなく例として、コード表示画面において、「電子貨幣の残高が最新ではない可能性があります。」というメッセージや、「電子貨幣の残高を更新してください。」といったメッセージを表示させる。または、これらと同様の趣旨のメッセージをスピーカ２６から音出力させる。
また、他の例として、残高が正確ではない可能性を示唆する示唆報知として、端末２０の制御部２１が、オンライン状態からオフライン状態に変化してからの経過時間を計測しておく。そして、制御部２１が、計測した経過時間に基づいて、残高を表示させる際の態様を変化させる。
図８−１は、本実施例における端末２０の記憶部２８に記憶される情報の一例を示す図である。
本実施例において、決済アプリケーションデータ２８３には、表示態様設定データ２８３６が記憶される。
本実施例において、決済アプリケーションデータ２８３には、表示態様設定データ２８３６が記憶される。
表示態様設定データ２８３６は、決済アプリケーションにおける残高の表示態様が設定されたデータである。その一例である表示態様設定データ２８３６Ａのデータ構成例を図８−２に示す。
表示態様設定データ２８３６Ａには、限定ではなく例として、経過時間に対する条件である経過時間条件と、その経過時間条件が成立する場合に残高に付加的に表示されるマークの種別であるマーク種別とが関連付けて記憶されている。ここでは、経過時間を「ｔ」と表記し、経過時間に対する閾値を閾値時間「ｔ１、ｔ２」と表記している。
１つ目の経過時間条件は「ｔ＜ｔ１」であり、マーク種別として「なし」が定められている。これは、経過時間ｔが閾値時間ｔ１よりも短い場合は、残高が正確ではない可能性は低いとして、マークを表示させないことを示している。
２つ目の経過時間条件は「ｔ１≦ｔ≦ｔ２」であり、マーク種別として「クエスチョンマーク」が定められている。これは、経過時間ｔが閾値時間ｔ１以上であり、かつ、経過時間ｔが閾値時間ｔ２以下である場合は、残高が正確ではない可能性が中程度であるとして、残高に「クエスチョンマーク」を付加的に表示させることを示している。
３つ目の経過時間条件は「ｔ２＜ｔ」であり、マーク種別として「危険マーク」が定められている。これは、経過時間ｔが閾値時間ｔ２よりも長い場合は、残高が正確ではない可能性が高いとして、残高に「危険マーク」を付加的に表示させることを示している。
図８−３は、表示態様設定データ２８３６の別例である表示態様設定データ２８３６Ｂの構成例を示す図である。
表示態様設定データ２８３６Ｂには、限定ではなく例として、経過時間条件と、その経過時間条件が成立する場合の残高（残高の文字と値とのうちの少なくともいずれか一方）の表示色とが関連付けて記憶されている。図の見方は、図８−２と同様である。
表示態様設定データ２８３６Ｂには、限定ではなく例として、経過時間条件と、その経過時間条件が成立する場合の残高（残高の文字と値とのうちの少なくともいずれか一方）の表示色とが関連付けて記憶されている。図の見方は、図８−２と同様である。
１つ目の経過時間条件は「ｔ＜ｔ１」であり、残高の表示色として「青色」が定められている。これは、経過時間ｔが閾値時間ｔ１よりも短い場合は、残高が正確ではない可能性は低いとして、残高を「青色」で表示することを示している。
２つ目の経過時間条件は「ｔ１≦ｔ≦ｔ２」であり、残高の表示色として「黄色」が定められている。これは、経過時間ｔが閾値時間ｔ１以上であり、かつ、経過時間ｔが閾値時間ｔ２以下である場合は、残高が正確ではない可能性は中程度であるとして、残高を「黄色」で表示することを示している。
３つ目の経過時間条件は「ｔ２＜ｔ」であり、残高の表示色として「赤色」が定められている。これは、経過時間ｔが閾値時間ｔ２よりも長い場合は、残高が正確ではない可能性が高いとして、残高を「赤色」で表示することを示している。
なお、閾値時間は適宜設定可能であるが、限定ではなく例として、「ｔ１＝３０分」、「ｔ２＝３時間」といった時間を設定しておくことができる。
図８−４は、この場合におけるコード表示画面の一例を示す図である。ここでは、図８−２の表示態様設定データ２８３６Ａに基づいて表示を行う場合を例示する。
このコード表示画面は、オフライン状態において表示されるコード表示画面の一例である。この表示例では、残高が未確定であることを示唆するため、画面上部の決済方法の横の残高の表示として、「未確定残高」の文字が表示され、その横に残高の値が表示されている。
このコード表示画面は、オフライン状態において表示されるコード表示画面の一例である。この表示例では、残高が未確定であることを示唆するため、画面上部の決済方法の横の残高の表示として、「未確定残高」の文字が表示され、その横に残高の値が表示されている。
上段のコード表示画面は、経過時間条件「ｔ＜ｔ１」が成立する場合を示しており、経過時間ｔが閾値時間ｔ１よりも短いため、未確定残高にはマークが表示されていない。
中段のコード表示画面は、経過時間条件「ｔ１≦ｔ≦ｔ２」が成立する場合を示しており、経過時間ｔが閾値時間ｔ１以上であり、かつ、経過時間ｔが閾値時間ｔ２以下であるため、未確定残高の値の横にクエスチョンマーク（この例では、丸の中に？）が表示されている。
下段のコード表示画面は、経過時間条件「ｔ２＜ｔ」が成立する場合を示しており、経過時間ｔが閾値時間ｔ２よりも長いため、未確定残高の値の横に危険マーク（この例では、三角形の中に！）が表示されている。
なお、上記の他にも、限定ではなく例として、残高の表示色は同じとし、経過時間が長くなるほど、残高の表示色をより濃くするようにしてもよいし、そのようにしなくてもよい。
また、上記の他にも、限定ではなく例として、経過時間に基づいて、残高を表示させる文字の太さを変化させるなどしてもよいし、そのようにしなくてもよい。
（２）残高の更新タイミングの報知
残高が最後に更新されたタイミングを端末２０のユーザに報知するため、端末２０の制御部２１は、限定ではなく例として、決済アプリケーションにおいて残高を表示させる際に、残高が最後に更新された日付と、残高が最後に更新された時刻と、残高が最後に更新された日時とのうちのいずれかの情報を、残高と一緒に表示部２４の画面（例えばコード表示画面）に表示させる。
残高が最後に更新されたタイミングを端末２０のユーザに報知するため、端末２０の制御部２１は、限定ではなく例として、決済アプリケーションにおいて残高を表示させる際に、残高が最後に更新された日付と、残高が最後に更新された時刻と、残高が最後に更新された日時とのうちのいずれかの情報を、残高と一緒に表示部２４の画面（例えばコード表示画面）に表示させる。
（３）端末による残高の更新
残高を最新の値に更新するため、端末２０の制御部２１は、特定の条件が成立した場合に、サーバ１０から最新の残高を取得して、決済アプリケーションデータ２８３に記憶されている残高を更新する。
残高を最新の値に更新するため、端末２０の制御部２１は、特定の条件が成立した場合に、サーバ１０から最新の残高を取得して、決済アプリケーションデータ２８３に記憶されている残高を更新する。
具体的には、限定ではなく例として、オフライン状態において決済のための手続きを行った後、オンライン状態に復帰した場合に、端末２０の制御部２１は、最新の残高を要求するリクエストをサーバ１０に送信する。そして、このリクエストを受けてサーバ１０から送信される残高で、決済アプリケーションデータ２８３に記憶されている残高を更新する。
なお、オンライン状態に復帰して端末２０がサーバ１０から端末用決済完了通知を受信すると、受信された端末用決済完了通知に基づいて、決済アプリケーションデータ２８３に記憶されている残高を更新することが可能である。このため、上記の処理を行って残高を更新した場合は、制御部２１は、端末用決済完了通知を受信した場合に、残高を更新しないようにしてもよいし、そのようにしなくてもよい。
また、サーバ１０から端末用決済完了通知を受信するよりも前に、オンライン状態に復帰したタイミングで、上記の処理を行って残高を更新するようにしてもよいし、そのようにしなくてもよい。
また、コード補充条件データ２８３８（図７−２）の条件Ｎｏ「ＣＰ２−３」のコード補充条件と関連するが、制御部２１は、オンライン状態において、決済アプリケーション内で入力部に対する残高更新操作を検知した場合に、最新の残高を要求するリクエストをサーバ１０に送信する。そして、このリクエストを受けてサーバ１０から送信される残高で、決済アプリケーションデータ２８３に記憶されている残高を更新する。
また、制御部２１は、決済アプリケーションが起動されてサーバ１０と通信接続されたタイミングで、最新の残高を要求するリクエストをサーバ１０に送信する。そして、このリクエストを受けてサーバ１０から送信される残高で、決済アプリケーションデータ２８３に記憶されている残高を更新する。
なお、この場合に、定期的なタイミング（例えば１日１回）や特定のタイミング（例えば決済アプリケーションの起動時）で、サーバ１０から端末２０に対して、残高が最新ではない可能性があることをプッシュ通知等によって通知する。そして、この通知に基づき、決済アプリケーション内で入力部への残高更新操作を検知した場合に、最新の残高を要求するリクエストをサーバ１０に送信して、サーバ１０から残高を取得するようにしてもよいし、そのようにしなくてもよい。
また、限定ではなく例として、定期的なタイミング（例えば１日１回）や特定のタイミング（例えば決済アプリケーションの起動時）で、サーバ１０から端末２０に最新の残高をプッシュ送信するようにし、端末２０がプッシュ送信された残高を取得するようにしてもよいし、そのようにしなくてもよい。
（４）残高修正のＵＩ
次に、残高を修正するためのユーザインターフェイス（ＵＩ）について説明する。
次に、残高を修正するためのユーザインターフェイス（ＵＩ）について説明する。
制御部２１は、限定ではなく例として、決済アプリケーション内で残高が表示される画面（例えばコード表示画面）において、端末２０のユーザが操作可能な画像であって、残高を修正するために用いられる画像（以下、「残高修正用画像」と称する。）を表示させる。
図８−５は、この場合に端末２０に表示される表示画面の一例を示す図である。ここでは、図８−４に示したコード表示画面に対応する画面を示している。
このコード表示画面では、決済方法の未確定残高の下に、残高修正用画像の一例として、「表示残高を修正」と示された残高修正用ボタンが表示されている。
このコード表示画面では、決済方法の未確定残高の下に、残高修正用画像の一例として、「表示残高を修正」と示された残高修正用ボタンが表示されている。
この残高修正用ボタンが端末２０のユーザによってタッチされると、端末２０のユーザは、未確定残高の値を修正することができる。具体的には、限定ではなく例として、図８−５の下段のコード表示画面に対応する画面の表示中に、例えば図８−６の上段に示すように残高修正用ボタンが端末２０のユーザによってタッチされると、例えば図８−６の下段に示すように、端末２０のユーザが数字を入力するためのテンキーが表示されるとともに、テンキーから入力された残高の値が表示される入力残高表示欄が表示される。入力残高表示欄には、限定ではなく例として、「使用後の残高を入力してください」というメッセージと、入力された残高の値が表示される表示欄と、その残高の値で確定するためのＯＫボタンと、残高の修正をキャンセルするためのキャンセルボタンとが含まれる。
ＯＫボタンがタッチされると、制御部２１は、未確定残高の値の表示を修正する。例えば、図８−６に示すように未確定残高が「３，０００円」であり、端末２０のユーザがテンキーによって「２，６００」を入力してＯＫボタンをタッチすると、例えば図８−７の上段に示すように、未確定残高の値の表示が「２，６００円」に修正される。
オンライン状態に復帰すると、端末２０はサーバ１０から送信される情報（例えば端末用決済完了通知）に基づいて、未確定残高の値を確定する。この場合、端末２０のユーザが、決済したであろう金額を誤って認識していたなどの理由で、修正された未確定残高の値が、サーバ１０で管理している最新の残高の値とは異なるような場合もある。この場合は、制御部２１は、サーバ１０から送信される情報に基づいて、修正された未確定残高の値を正しい値に調整・更新する。
例えば図８−７の上段に示した「２，６００円」の残高が１００円ずれていたような場合は、例えば図８−７の下段に示すように、未確定残高の値が「２，５００円」に調整・更新されて表示され、これにより残高が確定したことで、「未確定残高」の文字が「残高」の文字に変更されて表示されるとともに、残高修正用ボタンの表示も消去される。
（５）残高更新のＵＩ
制御部２１は、限定ではなく例として、決済アプリケーション内で残高が表示される画面（例えばコード表示画面）において、端末２０のユーザが操作可能な画像であって、残高を更新するために用いられる画像（以下、「残高更新用画像」と称する。）を表示させることもできる。
制御部２１は、限定ではなく例として、決済アプリケーション内で残高が表示される画面（例えばコード表示画面）において、端末２０のユーザが操作可能な画像であって、残高を更新するために用いられる画像（以下、「残高更新用画像」と称する。）を表示させることもできる。
具体的には、限定ではなく例として、制御部２１は、上記のコード表示画面の決済方法の残高の表示の横に、残高修正用画像の一例として、残高を修正するための残高更新用ボタンを表示させるようにすることができる。
オンライン状態において残高更新用ボタンＭＢがタッチされると、制御部２１は、最新の残高を要求するリクエストをサーバ１０に送信する。そして、このリクエストを受けてサーバ１０から送信される残高で、決済アプリケーションデータ２８３に記憶されている残高を更新するとともに、サーバ１０から送信される残高の値に、残高更新用ボタンの横の残高の値を更新する。
コード表示画面には、残高の他にコード画像も表示されるが、残高更新用ボタンがタッチされても、コード生成依頼情報が端末２０からサーバ１０に送信されることはなく、表示中のコード画像は更新されない。つまり、コード表示画面中の一部分の領域（部分領域）のみを対象として表示が更新される。このようにすることで、表示中のコード画像をそのまま店舗コードリーダ装置５０に読み取らせてサーバ１０に決済を行わせることができるため、コードも更新する場合と比べて、決済に要する時間を短縮することができる。
（６）店舗による残高の提示
図４−１２のＣ１８０において、サーバ１０の制御部１１が、決済を行った端末２０または端末２０のユーザに関連付けられている最新の残高を、店舗用決済完了通知に含めて店舗コードリーダ装置５０に送信するようにする。そして、Ｂ２８０においてサーバ１０から店舗用決済完了通知を受信すると、店舗コードリーダ装置５０は、受信された店舗用決済完了通知（最新の残高を含む。）を表示部５３に表示させる。そして、店舗の店員等は、表示部５３に表示された店舗用決済完了通知をユーザに提示する。
図４−１２のＣ１８０において、サーバ１０の制御部１１が、決済を行った端末２０または端末２０のユーザに関連付けられている最新の残高を、店舗用決済完了通知に含めて店舗コードリーダ装置５０に送信するようにする。そして、Ｂ２８０においてサーバ１０から店舗用決済完了通知を受信すると、店舗コードリーダ装置５０は、受信された店舗用決済完了通知（最新の残高を含む。）を表示部５３に表示させる。そして、店舗の店員等は、表示部５３に表示された店舗用決済完了通知をユーザに提示する。
この場合、端末２０のユーザは、提示された店舗用決済完了通知を確認した上で、自己の端末２０の決済アプリケーション内で残高を修正する操作を行って、残高を最新の残高に修正する。
＜その他＞
決済アプリケーション内で残高の情報を表示させる画面は、コード表示画面に限られない。例えば、図３−２等に示したように、決済アプリケーションのトップ画面にも、残高の情報を表示させるようにすることができる。この場合、限定ではなく例として、コード表示画面に代えて、または、コード表示画面に加えて、上記の残高修正用画像や残高更新用画像をトップ画面に表示させるようにし、このトップ画面に表示された残高修正用画像や残高更新用画像に基づいて、残高の修正や残高の更新を行うことができるようにすることもできる。
決済アプリケーション内で残高の情報を表示させる画面は、コード表示画面に限られない。例えば、図３−２等に示したように、決済アプリケーションのトップ画面にも、残高の情報を表示させるようにすることができる。この場合、限定ではなく例として、コード表示画面に代えて、または、コード表示画面に加えて、上記の残高修正用画像や残高更新用画像をトップ画面に表示させるようにし、このトップ画面に表示された残高修正用画像や残高更新用画像に基づいて、残高の修正や残高の更新を行うことができるようにすることもできる。
＜第５実施例の効果＞
第５実施例は、端末２０が、決済に使用可能な電子貨幣の残高の情報を、決済アプリケーション内の画面に表示する構成を示している。
このような構成により得られる効果の一例として、決済に使用可能な電子貨幣の残高の情報を端末の表示領域に表示することで、決済に使用可能な電子貨幣の残高を端末のユーザに報知することができる。
第５実施例は、端末２０が、決済に使用可能な電子貨幣の残高の情報を、決済アプリケーション内の画面に表示する構成を示している。
このような構成により得られる効果の一例として、決済に使用可能な電子貨幣の残高の情報を端末の表示領域に表示することで、決済に使用可能な電子貨幣の残高を端末のユーザに報知することができる。
また、第５実施例は、端末２０は、通信Ｉ／Ｆ２２の通信状況に基づいて、制御部２１によって通信Ｉ／Ｆ２２を介して電子貨幣の残高の情報をサーバ１０から受信する。そして、端末２０は、受信された電子貨幣の残高の情報を、決済アプリケーション内の画面に表示する構成を示している。
このような構成により得られる効果の一例として、端末は、通信部の通信状況に基づいて、制御部によって通信部を介して残高の情報をサーバから適切に受信した上で、表示領域に表示して端末のユーザに報知することができる。
このような構成により得られる効果の一例として、端末は、通信部の通信状況に基づいて、制御部によって通信部を介して残高の情報をサーバから適切に受信した上で、表示領域に表示して端末のユーザに報知することができる。
また、第５実施例は、端末２０は、残高が最後に更新された日付の情報（限定ではなく、残高の情報が表示領域に表示された日付に関する情報の一例）、残高が最後に更新された時刻の情報（限定ではなく、残高の情報が表示領域に表示された時刻に関する情報の一例）、残高が最後に更新された日時の情報（限定ではなく、残高の情報が表示領域に表示された日時に関する情報の一例）のうちのいずれかを、決済アプリケーション画面に表示する構成を示している。
このような構成により得られる効果の一例として、端末は、残高の情報が表示領域に表示された日付に関する情報、または残高の情報が表示領域に表示された時刻に関する情報を表示領域への表示によってユーザに報知することができる。
このような構成により得られる効果の一例として、端末は、残高の情報が表示領域に表示された日付に関する情報、または残高の情報が表示領域に表示された時刻に関する情報を表示領域への表示によってユーザに報知することができる。
また、第５実施例は、端末２０が、残高修正用ボタン等の残高修正用画像へのユーザ操作（限定ではなく、残高の情報の修正に関する入力の一例）に基づいて、コード表示画面に表示された残高を修正する構成を示している。
このような構成により得られる効果の一例として、残高の情報の修正に関する入力に基づいて、端末の表示領域に表示された残高を簡易かつ適切に修正することができる。
このような構成により得られる効果の一例として、残高の情報の修正に関する入力に基づいて、端末の表示領域に表示された残高を簡易かつ適切に修正することができる。
また、第５実施例は、端末２０が、残高更新用ボタン等の残高更新用画像（限定ではなく、端末のユーザの入力により残高の情報の更新を行うための表示の一例）を表示する構成を示している。
このような構成により得られる効果の一例として、端末のユーザの入力により残高の情報の更新を行うための表示を端末の表示領域に表示することで、端末のユーザに簡単に残高を更新させることができ、ユーザの利便性を向上させることができる。
このような構成により得られる効果の一例として、端末のユーザの入力により残高の情報の更新を行うための表示を端末の表示領域に表示することで、端末のユーザに簡単に残高を更新させることができ、ユーザの利便性を向上させることができる。
また、第５実施例は、端末２０が、残高をコード表示画面に表示し、残高更新用画像（限定ではなく、端末のユーザの入力により残高の情報の更新を行うための表示の一例）をコード表示画面に表示する。この場合、端末２０は、コード表示画面の一の領域（限定ではなく、第３領域の一例）にコード表示（限定ではなく、第１表示の一例）を表示し、コード表示画面の他の領域（限定ではなく、第４領域の一例）に残高を表示する。そして、残高更新用画像に対するユーザ操作に基づいて、一の領域にコード表示が表示された状態で、他の領域に表示された残高を更新する構成を示している。
このような構成により得られる効果の一例として、残高の情報の更新を行うための表示に対する端末のユーザによる入力に基づいて、第３領域に第１表示が表示された状態で、第４領域に表示された残高の情報を更新することができるため、第３領域に表示された第１表示を更新する必要なく、第４領域に表示された残高の情報のみを更新することができる。
このような構成により得られる効果の一例として、残高の情報の更新を行うための表示に対する端末のユーザによる入力に基づいて、第３領域に第１表示が表示された状態で、第４領域に表示された残高の情報を更新することができるため、第３領域に表示された第１表示を更新する必要なく、第４領域に表示された残高の情報のみを更新することができる。
＜第５変形例＞
第５実施例で説明した残高の修正や変更に関して、端末２０がオフライン状態であっても、店舗ＰＯＳシステム４０はサーバ１０と通信可能である。このため、限定ではなく例として、コードレジ６０で発行されるレシートには、端末２０のユーザの最新の残高（正確な残高）が印字される。また、限定ではなく例として、コードレジ６０に入力される残高やコードレジ６０に表示される残高は、端末２０のユーザの最新の残高となる。
第５実施例で説明した残高の修正や変更に関して、端末２０がオフライン状態であっても、店舗ＰＯＳシステム４０はサーバ１０と通信可能である。このため、限定ではなく例として、コードレジ６０で発行されるレシートには、端末２０のユーザの最新の残高（正確な残高）が印字される。また、限定ではなく例として、コードレジ６０に入力される残高やコードレジ６０に表示される残高は、端末２０のユーザの最新の残高となる。
そこで、限定ではなく例として、店舗コードリーダ装置５０が、オフライン決済か否かを判定する。前述したように、端末表示用コード画像には決済用番号が含まれる一方、拡張端末表示用コード画像には決済用番号と時刻情報とが含まれる。このため、店舗コードリーダ装置５０は、限定ではなく例として、読み取ったコード画像からデコードによって取得した情報に決済用番号と時刻情報とが含まれる場合に、オフライン決済と判定することができる。
また、この他にも、限定ではなく例として、サーバ１０が、決済用番号と、時刻情報とを含む決済要求情報を店舗コードリーダ装置５０から受信したことに基づいて、オフライン決済と判定する。そして、サーバ１０が、決済処理を行った後、オフライン決済であることを示す情報を含む店舗用決済完了通知を店舗コードリーダ装置５０に送信するようにし、これによって、店舗コードリーダ装置５０がオフライン決済と判定するようにすることもできる。
オフライン決済と判定した場合、店舗コードリーダ装置５０は、限定ではなく例として、オフライン決済であることを示す情報をコードレジ６０に出力する。この場合、コードレジ６０は、限定ではなく例として、発行するレシートに、残高と、その残高が端末２０で表示されている残高とは異なることを示す情報とを印字するようにすることができる。
同様に、オフライン決済と判定した場合、店舗コードリーダ装置５０は、限定ではなく例として、オフライン決済であることを示す情報をコードレジ６０に出力する。この場合、コードレジ６０は、限定ではなく例として、客側に表示面が向けられたディスプレイ等に、残高と、その残高が端末２０で表示されている残高とは異なることを示す情報とを表示させるようにすることができる。
また、この場合、レシートに印字されている残高やディスプレイに表示されている残高が端末２０で表示されている残高とは異なる旨や、端末２０で表示されている残高が正確な残高ではない旨を、店舗の店員等が口頭で端末２０のユーザに通知（アナウンス）するようにしてもよいし、そのようにしなくてもよい。
＜第６実施例＞
第６実施例は、オフライン決済を行う際に、端末２０で認証処理を行う実施例である。また、この認証処理を行う際に、特定の条件が成立する場合は、認証処理をスキップさせる。
第６実施例は、オフライン決済を行う際に、端末２０で認証処理を行う実施例である。また、この認証処理を行う際に、特定の条件が成立する場合は、認証処理をスキップさせる。
本実施例において、「認証」とは、特に断りのない限り、決済を行うために端末２０のユーザが正規のユーザであることを認証することを意味し、「認証処理」とは、この決済用の認証を実現するための処理を意味する。
また、「認証スキップ条件」とは、特に断りのない限り、上記の決済用の認証処理をスキップする条件を意味し、「認証処理をスキップする」とは、認証処理の処理命令を無視して、次の命令を処理すること、つまり認証処理を省略することを意味する。
図９−１は、本実施例においてサーバ１０の記憶部１５に記憶される店舗登録データ１５５の一例である店舗登録データ１５５Ｂのデータ構成の一例を示す図である。
この店舗登録データ１５５Ｂは、前述した店舗登録データ１５５Ａ（図４−４）と同様に加盟店舗の登録データであるが、データ構成が一部異なっている。
この店舗登録データ１５５Ｂは、前述した店舗登録データ１５５Ａ（図４−４）と同様に加盟店舗の登録データであるが、データ構成が一部異なっている。
具体的には、店舗登録データ１５５Ｂには、業種と、店舗名と、店舗位置情報と、店舗ＰＯＳシステム情報と、店舗ＩＤとに加えて、第１特定業種フラグと、第２特定業種フラグとが関連付けて記憶されている。
第１特定業種フラグは、この業種が、あらかじめ設定された第１の種別の特定業種（以下、「第１特定業種」と称す。）であるか否かを示すフラグであり、第１特定業種に該当する業種には「ＯＮ」が記憶され、第１特定業種に該当しない業種には「ＯＦＦ」が記憶される。第１特定業種は、限定でなく例として、サーバ１０側であらかじめ設定しておくことができる。この例では、多くのユーザが日常的に利用する業種である「コンビニエンスストア」と「スーパーマーケット」とが、第１特定業種として設定されている。
第２特定業種フラグは、この業種が、あらかじめ設定された第２の種別の特定業種（以下、「第２特定業種」と称す。）であるか否かを示すフラグであり、第２特定業種に該当する業種には「ＯＮ」が記憶され、第２特定業種に該当しない業種には「ＯＦＦ」が記憶される。第２特定業種も、限定でなく例として、サーバ１０側であらかじめ設定しておくことができる。この例では、ユーザが端末２０を置き忘れるリスクの高い業種である「居酒屋」が、第２特定業種として設定されている。
図９−２は、本実施例における制御部２１によって実現される機能の一例を示す図である。
制御部２１の決済アプリケーション処理部２１１は、認証処理部２１１５と、認証スキップ判定処理部２１１７とを有する。また、制御部２１は、位置算出処理部２１７を有する。
制御部２１の決済アプリケーション処理部２１１は、認証処理部２１１５と、認証スキップ判定処理部２１１７とを有する。また、制御部２１は、位置算出処理部２１７を有する。
認証処理部２１１５は、オフライン決済を行うにあたり、端末２０のユーザが正規のユーザであるかを認証するための認証処理を実行する機能を有している。
認証処理では、限定ではなく例として、端末２０のユーザに対する認証の実行に関する表示処理として、端末２０のユーザに認証パスワードを入力させるための認証画面を表示部２４に表示させる処理を行い、この認証画面で入力された認証パスワードが、記憶部２８に登録済みの認証パスワードと一致するか否かを判定する。
本実施例では、認証処理部２１１５は、限定ではなく例として、図４−１２の処理におけるＡ３５０の処理を実行する前のタイミングや、図６−３の処理におけるＡ５５０の処理を実行する前のタイミングで、認証処理を実行する。
認証スキップ判定処理部２１１７は、認証処理部２１１５によって実行される認証処理をスキップさせるか否かを判定するための処理である認証スキップ判定処理を実行する機能を有している。
本実施例では、認証スキップ判定処理部２１１７は、限定ではなく例として、上記の認証処理部２１１５による認証処理が実行される前のタイミングで、認証スキップ判定処理を実行する。
位置算出処理部２１７は、位置算出用情報検出部２９Ｂから出力される位置算出用情報に基づいて、自己の端末２０の位置を算出する処理である位置算出処理を実行する機能を有している。位置算出処理部２１７は、例えば、位置算出用情報検出部２９Ｂに含まれる衛星測位センサ（衛星測位ユニット）から出力される衛星軌道データや時刻データ等に基づいて、衛星測位演算を行って、自己の端末２０の位置を算出する。また、位置算出処理部２１７は、位置算出用情報検出部２９Ｂに含まれる慣性計測センサ（慣性計測ユニット）から出力される加速度や角速度の情報に基づいて、慣性航法演算を行って、自己の端末２０の位置を算出する。
なお、本実施例とは異なり、限定ではなく例として、処理装置や演算装置（例えばＣＰＵやＤＳＰ）を位置算出用情報検出部２９Ｂに設けるようにし、端末２０の制御部２１ではなく、位置算出用情報検出部２９Ｂが端末２０の位置を算出して出力するようにしてもよいし、しなくてもよい。
また、限定ではなく例として、位置情報を端末２０で取得可能とするための無線装置、例えばビーコン信号（典型例としてはブルートゥース信号）を発信するビーコンを加盟店舗に設置するようにし、端末２０が、店舗に設置されたビーコンから発信されるビーコン信号に基づいて、位置情報を取得するようにしてもよいし、しなくてもよい。
図９−３は、本実施例における端末２０の記憶部２８に記憶される情報の一例を示す図である。
記憶部２８には、決済アプリケーションソフトウェア２８１と端末データ２８９との他に、限定ではなく例として、位置算出処理として実行される位置算出処理プログラム２８７と、算出端末位置履歴データ２８８とが記憶される。
記憶部２８には、決済アプリケーションソフトウェア２８１と端末データ２８９との他に、限定ではなく例として、位置算出処理として実行される位置算出処理プログラム２８７と、算出端末位置履歴データ２８８とが記憶される。
また、決済アプリケーションデータ２８３には、端末表示用コードストックデータ２８３１と、決済用データ２８３２と、店舗データ２８３３との他に、限定ではなく例として、認証スキップ条件データ２８３７が記憶される。
図９−４は、本実施例における決済用データ２８３２の一例である決済用データ２８３２Ｂのデータ構成の一例を示す図である。
決済用データ２８３２Ｂには、決済用データ２８３２Ａ（図４−８）に記憶されている情報の他に、認証パスワードと、決済アプリケーションロック解除パスワードとが記憶される。
決済用データ２８３２Ｂには、決済用データ２８３２Ａ（図４−８）に記憶されている情報の他に、認証パスワードと、決済アプリケーションロック解除パスワードとが記憶される。
また、本実施例において、店舗データ２８３３には、限定でなく例として、サーバ１０の店舗登録データ１５５Ｂ（図９−１）に記憶されている各種の店舗情報が記憶される。
算出端末位置履歴データ２８８には、限定ではなく例として、位置算出処理部２１７が所定時間毎（例えば、「1分毎」や「５分毎」、「１０分毎」）に位置算出処理を行うことで算出した端末２０の位置（以下、「算出端末位置」と称す。）の履歴が記憶される。
また、本実施例において、端末データ２８９には、限定ではなく例として、端末２０のＯＳ側のロック設定「ＯＮ／ＯＦＦ」、端末２０のＯＳ側のロックを解除するための端末ロック解除パスワード、端末側の認証設定「ＯＮ／ＯＦＦ」等の情報が含まれる。
認証スキップ条件データ２８３７は、認証スキップ条件が定められたデータであり、そのデータ構成の一例を図９−５に示す。
認証スキップ条件データ２８３７には、認証スキップ条件のカテゴリの番号である条件カテゴリＮｏと、この条件カテゴリＮｏのカテゴリに含まれる認証スキップ条件の番号である条件Ｎｏと、この条件Ｎｏの認証スキップ条件と、この認証スキップ条件を適用して判定を行うか否かを示す適用有無と、この認証スキップ条件の重要度（優先度）とが関連付けて記憶されている。以下、それぞれの認証スキップ条件、および、その判定方法について詳細に説明する。
認証スキップ条件データ２８３７には、認証スキップ条件のカテゴリの番号である条件カテゴリＮｏと、この条件カテゴリＮｏのカテゴリに含まれる認証スキップ条件の番号である条件Ｎｏと、この条件Ｎｏの認証スキップ条件と、この認証スキップ条件を適用して判定を行うか否かを示す適用有無と、この認証スキップ条件の重要度（優先度）とが関連付けて記憶されている。以下、それぞれの認証スキップ条件、および、その判定方法について詳細に説明する。
＜条件カテゴリＮｏ「ＳＰ１」＞
条件カテゴリＮｏ「ＳＰ１」は「時間」のカテゴリであり、限定ではなく例として、条件Ｎｏ「ＳＰ１−１」、「ＳＰ１−２」の認証スキップ条件がこれに含まれる。
条件カテゴリＮｏ「ＳＰ１」は「時間」のカテゴリであり、限定ではなく例として、条件Ｎｏ「ＳＰ１−１」、「ＳＰ１−２」の認証スキップ条件がこれに含まれる。
条件Ｎｏ「ＳＰ１−１」の認証スキップ条件として、「現在日時が最終決済日時から設定時間内」が定められている。
「最終決済日時」は、端末２０で認証処理がスキップされたか否かに関わらず、最後に決済が行われた日時（決済が行われた最新の日時）である。これは、現在日時が最終決済日時から設定時間内（例えば「１時間内」）であるということは、それほど時間が経過しない間に再び決済を行うことになるため、ユーザの利便性向上のため、認証を省略することを意味する。
「最終決済日時」は、端末２０で認証処理がスキップされたか否かに関わらず、最後に決済が行われた日時（決済が行われた最新の日時）である。これは、現在日時が最終決済日時から設定時間内（例えば「１時間内」）であるということは、それほど時間が経過しない間に再び決済を行うことになるため、ユーザの利便性向上のため、認証を省略することを意味する。
この認証スキップ条件の判定では、限定ではなく例として、認証スキップ判定処理部２１１７は、時計部２９Ａで計時している計時時刻に基づく現在日時と、決済用データ２８３２Ｂの決済履歴データに記憶されている最終決済日時とを取得して、現在日時が最終決済日時から設定時間内であるか否かを判定するようにすることができる。
条件Ｎｏ「ＳＰ１−２」の認証スキップ条件として、「現在時刻が設定時間帯に含まれる」が定められている。設定時間帯は、限定ではなく例として、端末２０のユーザがあらかじめ設定しておくようにすることができる。具体的には、例えば、端末２０のユーザが、自身が頻繁に決済を行う時間帯を設定時間帯として設定しておくことで、設定時間帯に決済を行う場合に認証を省略させることができる。
この認証スキップ条件の判定では、限定ではなく例として、認証スキップ判定処理部２１１７は、時計部２９Ａで計時している計時時刻に基づく現在時刻を取得して、現在時刻が設定時間帯に含まれるか否かを判定するようにすればよい。
＜条件カテゴリＮｏ「ＳＰ２」＞
条件カテゴリＮｏ「ＳＰ２」は「店舗・場所」のカテゴリであり、限定ではなく例として、条件Ｎｏ「ＳＰ２−１」〜「ＳＰ２−４」の認証スキップ条件がこれに含まれる。
条件カテゴリＮｏ「ＳＰ２」は「店舗・場所」のカテゴリであり、限定ではなく例として、条件Ｎｏ「ＳＰ２−１」〜「ＳＰ２−４」の認証スキップ条件がこれに含まれる。
オフライン状態では、位置算出処理部２１７が、衛星測位システムを利用した位置算出を行うことができない場合がある。そこで、オフライン状態では、位置算出処理部２１７は、限定ではなく例として、前述した慣性航法演算や、前述した加盟店舗に設置されるビーコンから発信されるビーコン信号等に基づいて、自己の端末２０の端末位置を算出・特定して、算出端末位置履歴データ２８８に記憶させる。そして、算出端末位置履歴データ２８８に記憶されている算出端末位置の履歴や、最新の算出端末位置に基づいて、以下の認証スキップ条件の成否を判定する。なお、ビーコン信号は、限定ではなく例として、端末２０でブルートゥース機能を「ＯＮ」にしておくことで受信可能である。
条件Ｎｏ「ＳＰ２−１」の認証スキップ条件として、「決済予定店舗で過去に決済または決済用の認証を行ったことあり」が定められている。
「決済予定店舗」とは、これから決済を行う予定の店舗（決済前の未確定の状態の店舗）を意味する。つまり、これから決済を行う店舗で過去に決済またはそのための認証を行ったことがある場合は、ユーザの利便性向上のため、認証を省略することを意味する。
「決済予定店舗」とは、これから決済を行う予定の店舗（決済前の未確定の状態の店舗）を意味する。つまり、これから決済を行う店舗で過去に決済またはそのための認証を行ったことがある場合は、ユーザの利便性向上のため、認証を省略することを意味する。
この認証スキップ条件の判定では、認証スキップ判定処理部２１１７は、限定ではなく例として、算出端末位置履歴データ２８８に記憶されている算出端末位置の履歴および最新の算出端末位置と、決済用データ２８３２Ｂの決済履歴データに記憶されている決済日時とを取得して、過去の決済日時と同じ日時に対応する算出端末位置の中に、最新の算出端末位置と一致する算出端末位置が存在するか否かを判定するようにすることができる。
条件Ｎｏ「ＳＰ２−２」の認証スキップ条件として、「決済予定店舗が設定店舗」が定められている。設定店舗は、基本的には、あらかじめサーバ１０側で設定しておくようにすることができる。限定ではなく例として、サーバ１０側で、統計的にユーザの利用頻度が高い店舗を集計して、設定店舗として設定しておくようにすることができる。これは、ユーザの利用頻度が高い店舗では、ユーザの利便性向上のため、認証を省略することを意味する。
なお、サーバ１０側ではなく、端末２０側で設定店舗の設定を行うことを可能としてもよい。例えば、端末２０のユーザが、自身の利用頻度が高い店舗を設定店舗として端末２０に設定させることができる。また、例えば、端末２０のユーザが、特定の業種の店舗（例えばコンビニエンスストア）について、自宅の近くの店舗は安全であるとして設定店舗として設定するが、それ以外の店舗はリスクがあるとして設定店舗として設定しないようにすることもできる。
この認証スキップ条件の判定では、認証スキップ判定処理部２１１７は、限定ではなく例として、算出端末位置履歴データ２８８に記憶されている算出端末位置の履歴と、決済用データ２８３２Ｂの決済履歴データに記憶されている決済店舗名と、店舗データ２８３３に記憶されている店舗情報とを取得して、過去の設定店舗での決済日時と同じ日時に対応する算出端末位置の中に、最新の算出端末位置と一致する算出端末位置が存在するか否かを判定するようにすることができる。
条件Ｎｏ「ＳＰ２−３」の認証スキップ条件として、「決済予定店舗が第１特定業種の店舗」が定められている。
第１特定業種は、限定ではなく例として、「コンビニエンスストア」や「スーパーマーケット」といった、多くのユーザが日常的に利用する業種を設定しておくことができる。これらの店舗で決済を行う場合は、ユーザの利便性向上のため、認証を省略することを意味する。
この認証スキップ条件の判定では、認証スキップ判定処理部２１１７は、限定ではなく例として、算出端末位置履歴データ２８８に記憶されている算出端末位置の履歴と、決済用データ２８３２Ｂの決済履歴データに記憶されている決済店舗名と、店舗データ２８３３に記憶されている第１特定業種フラグとを取得して、第１特定業種フラグ「ＯＮ」の店舗での過去の決済日時と同じ日時に対応する算出端末位置の中に、最新の算出端末位置と一致する算出端末位置が存在するか否かを判定するようにすることができる。
条件Ｎｏ「ＳＰ２−４」の認証スキップ条件として、「第２特定業種の店舗での決済日時から設定時間超」が定められている。第２特定業種は、前述したように、「居酒屋」といった、ユーザが端末２０を置き忘れるリスクが高い業種を設定しておくことができる。また、設定時間は、例えば「３時間」や「６時間」、「１２時間」といった時間を設定しておくことができる。端末２０を置き忘れるリスクが高い店舗で決済が行われた場合は、その決済日時から設定時間を超えるまでの間は認証を必須とするが、決済日時から設定時間を超えると、認証を省略することを意味する。
この認証スキップ条件の判定では、認証スキップ判定処理部２１１７は、限定ではなく例として、時計部２９Ａで計時している計時時刻に基づく現在日時と、決済用データ２８３２Ｂの決済履歴データに記憶されている決済日時と、店舗データ２８３３に記憶されている第２特定業種フラグとを取得して、現在日時が第２特定業種フラグ「ＯＮ」の店舗での決済日時から設定時間を超えているか否かを判定するようにすることができる。
＜条件カテゴリＮｏ「ＳＰ３」＞
条件カテゴリＮｏ「ＳＰ３」は「金額」のカテゴリであり、限定ではなく例として、条件Ｎｏ「ＳＰ３−１」、「ＳＰ３−２」の認証スキップ条件がこれに含まれる。
条件カテゴリＮｏ「ＳＰ３」は「金額」のカテゴリであり、限定ではなく例として、条件Ｎｏ「ＳＰ３−１」、「ＳＰ３−２」の認証スキップ条件がこれに含まれる。
条件Ｎｏ「ＳＰ３−１」の認証スキップ条件として、「１日上限設定金額を超えていない」が定められている。
「１日上限設定金額」は、その１日で既に決済された決済金額（決済済みの金額）の合計金額に対する閾値とされる上限の設定金額である。つまり、その１日で既に決済された決済金額の合計金額が１日上限設定金額を超えていない場合は、ユーザの利便性向上のため、認証を省略することを意味する。
「１日上限設定金額」は、その１日で既に決済された決済金額（決済済みの金額）の合計金額に対する閾値とされる上限の設定金額である。つまり、その１日で既に決済された決済金額の合計金額が１日上限設定金額を超えていない場合は、ユーザの利便性向上のため、認証を省略することを意味する。
また、逆に、その１日で既に決済された決済金額の合計金額が１日上限設定金額を超えている場合は、認証を行うようにすることで、決済でお金を使い過ぎていることを注意喚起することができる。また、未成年者等が決済を行う場合に、保護者が利用に制限をかけるようにすることができる。
この認証スキップ条件の判定では、認証スキップ判定処理部２１１７は、限定ではなく例として、決済用データ２８３２Ｂに記憶されている１日上限設定金額と、決済履歴データから特定されるその１日の決済金額の合計金額とを取得して、合計金額が１日上限設定金額を超えているか否かを判定するようにすることができる。
条件Ｎｏ「ＳＰ３−２」の認証スキップ条件として、「残高が設定金額以下（または設定金額未満）、かつ、オートチャージ設定ＯＦＦ」が定められている。設定金額は、限定ではなく例として、端末２０のユーザがあらかじめ設定しておくようにすることができる。これは、残高が設定金額以下（または設定金額未満）であれば、ユーザは高額の商品を決済で購入することができず、危険性は低いと考えられるため、ユーザの利便性向上のため、認証を省略することを意味する。
しかしながら、オートチャージ設定が「ＯＮ」であれば、電子貨幣が自動的に補充されるため、ユーザは高額の商品を決済で購入することが可能となり、リスクが生ずる。そこで、残高が設定金額以下（または設定金額未満）であることに加えて、オートチャージ設定が「ＯＦＦ」であることを、認証スキップの条件とする。
なお、この場合、オートチャージ設定が「ＯＮ」であれば、残高が設定金額以下（または設定金額未満）であっても、原則的には認証処理がスキップされないことになる。しかしながら、上記のようにユーザの利便性向上を考え、オートチャージ設定が「ＯＮ」であっても、認証処理をスキップさせるようにすることもできる。この場合は、限定ではなく例として、上記の条件Ｎｏ「ＳＰ３−２」の認証スキップ条件からオートチャージ設定ＯＦＦを除外し、「残高が設定金額以下（または設定金額未満）」とすればよい。つまり、オートチャージ設定が「ＯＮ」であっても、必ずしも認証処理を必須としなければならないわけではなく、あくまでもオートチャージが「ＯＮ」の場合、残高が設定金額以下（または設定金額未満）であれば、認証処理を行う場合があってもよいし、認証処理を行わない場合があってもよい。
この認証スキップ条件の判定では、認証スキップ判定処理部２１１７は、限定ではなく例として、決済用データ２８３２Ｂに記憶されている残高およびオートチャージ設定を取得して、残高が設定金額以下（または設定金額未満）であり、かつ、オートチャージ設定が「ＯＦＦ」であるか否かを判定するようにすることができる。
＜条件カテゴリＮｏ「ＳＰ４」＞
条件カテゴリＮｏ「ＳＰ４」は「商品」のカテゴリであり、限定ではなく例として、条件Ｎｏ「ＳＰ４−１」、「ＳＰ４−２」の認証スキップ条件がこれに含まれる。
条件カテゴリＮｏ「ＳＰ４」は「商品」のカテゴリであり、限定ではなく例として、条件Ｎｏ「ＳＰ４−１」、「ＳＰ４−２」の認証スキップ条件がこれに含まれる。
条件Ｎｏ「ＳＰ４−１」の認証スキップ条件として、「購入予定商品が日用消費財」が定められている。
「購入予定商品」は、これから決済を行って購入する予定の商品（決済前の未確定の状態の商品）を意味する。つまり、これから決済を行って購入する予定の商品が日用消費財である場合は、ユーザの利便性向上のため、認証を省略することを意味する。
「購入予定商品」は、これから決済を行って購入する予定の商品（決済前の未確定の状態の商品）を意味する。つまり、これから決済を行って購入する予定の商品が日用消費財である場合は、ユーザの利便性向上のため、認証を省略することを意味する。
条件Ｎｏ「ＳＰ４−２」の認証スキップ条件として、「購入予定商品の購入履歴あり」が定められている。これは、購入予定商品が端末２０のユーザが一度以上購入した商品と一致した場合、ユーザの利便性向上のため、認証を省略することを意味する。
＜条件カテゴリＮｏ「ＳＰ５」＞
条件カテゴリＮｏ「ＳＰ５」は「セキュリティ」のカテゴリであり、限定ではなく例として、条件Ｎｏ「ＳＰ５−１」の認証スキップ条件がこれに含まれる。
条件カテゴリＮｏ「ＳＰ５」は「セキュリティ」のカテゴリであり、限定ではなく例として、条件Ｎｏ「ＳＰ５−１」の認証スキップ条件がこれに含まれる。
条件Ｎｏ「ＳＰ５−１」の認証スキップ条件として、「端末ロック中、または、決済アプリケーションロック中」が定められている。これは、端末２０のＯＳ側にロックがかかっている状態や、決済アプリケーション側にロックがかかっている状態では、これらのロック状態を解除するために、それぞれ端末ロック解除パスワードや決済アプリケーションロック解除パスワードの入力等による認証が必要となる。このため、ユーザの利便性向上のため、決済用の認証は不要とすることを意味する。
この認証スキップ条件の判定では、認証スキップ判定処理部２１１７は、限定ではなく例として、端末データ２８９に記憶されている端末２０のＯＳ側のロック有無の情報と、決済アプリケーションデータ２８３に記憶されている決済アプリケーション側のロック有無の情報とを取得して、端末ロック中、または、決済アプリケーションロック中であるか否かを判定するようにすることができる。
＜条件カテゴリＮｏ「ＳＰ６」＞
条件カテゴリＮｏ「ＳＰ６」は「認証設定」のカテゴリであり、限定ではなく例として、条件Ｎｏ「ＳＰ６−１」の認証スキップ条件がこれに含まれる。
条件カテゴリＮｏ「ＳＰ６」は「認証設定」のカテゴリであり、限定ではなく例として、条件Ｎｏ「ＳＰ６−１」の認証スキップ条件がこれに含まれる。
条件Ｎｏ「ＳＰ６−１」の認証スキップ条件として、「端末側の認証設定ＯＦＦ、または、決済アプリケーション側の認証設定ＯＦＦ」が定められている。
端末側の認証は、ユーザの本人認証等を含む端末２０側でユーザに要求される各種の認証である。決済アプリケーション側の認証は、決済アプリケーションを利用して決済を行う際にユーザに要求される認証である。
これは、端末２０のユーザによって、端末２０側で認証を省略する設定がなされている場合、または、決済アプリケーション側で認証を省略する設定がなされている場合は、認証を省略することを意味する。
端末側の認証は、ユーザの本人認証等を含む端末２０側でユーザに要求される各種の認証である。決済アプリケーション側の認証は、決済アプリケーションを利用して決済を行う際にユーザに要求される認証である。
これは、端末２０のユーザによって、端末２０側で認証を省略する設定がなされている場合、または、決済アプリケーション側で認証を省略する設定がなされている場合は、認証を省略することを意味する。
この認証スキップ条件の判定では、認証スキップ判定処理部２１１７は、限定ではなく例として、端末データ２８９に記憶されている端末側の認証設定と、決済アプリケーションデータ２８３に記憶されている決済アプリケーション側の認証設定とを取得して、端末側の認証設定と、決済アプリケーション側の認証設定との少なくともいずれか一方が「ＯＦＦ」であるか否かを判定するようにすることができる。
ここまで複数の認証スキップ条件を例示したが、本実施例では、限定ではなく例として、これらの認証スキップ条件それぞれについて、その認証スキップ条件を適用可能であるか否かを示す適用有無が定められている。
本実施例では、条件Ｎｏ「ＳＰ４−１」、「ＳＰ４−２」の認証スキップ条件には、適用無し「×」が定められている。これは、これらの認証スキップ条件を判定するためには、端末２０が購入予定商品に関する情報を取得する必要がある。しかし、基本的に、端末２０は、購入予定商品に関する情報を取得できず、購入予定商品が日用消費財であるか否かを判定することも、購入予定商品の購入履歴があるか否かを判定することもできないためである。
但し、端末２０が購入予定商品に関する情報を取得することができれば、これらの認証スキップ条件は適用可能「○」となる。この詳細については、変形例で後述する。
但し、端末２０が購入予定商品に関する情報を取得することができれば、これらの認証スキップ条件は適用可能「○」となる。この詳細については、変形例で後述する。
また、本実施例では、限定ではなく例として、上記の認証スキップ条件それぞれについて、その認証スキップ条件の重要性の度合を示す指標値である「重要度」（認証スキップ条件を優先的に適用する度合を示す「優先度」とも言える。）が定められている。
重要度は、限定ではなく例として、「Ａ」〜「Ｃ」の３段階で表され、「Ａ」が最も重要性が高く、「Ｃ」が最も重要性が低くなるように重要度が定められている。
具体的には、限定ではなく例として、条件Ｎｏ「ＳＰ１−１」、「ＳＰ２−１」、「ＳＰ２−４」、「ＳＰ３−１」、「ＳＰ３−２」、「ＳＰ５−１」、「ＳＰ６−１」の認証スキップ条件には重要度「Ａ」が定められ、条件Ｎｏ「ＳＰ２−２」、「ＳＰ２−３」の認証スキップ条件には重要度「Ｂ」が定められ、条件Ｎｏ「ＳＰ１−２」の認証スキップ条件には重要度「Ｃ」が定められている。また、本実施例では、条件Ｎｏ「ＳＰ４−１」、「ＳＰ４−２」の認証スキップ条件は適用不可であるため、重要度には「−（なし）」が定められている。
なお、上記の重要度の設定はあくまでも一例を示したものに過ぎず、適宜設定変更可能であることは勿論である。また、この例では、認証スキップ条件毎（条件Ｎｏ毎）に適用有無や重要度が定められているが、これに代えて、認証スキップ条件のカテゴリ毎（条件カテゴリＮｏ）毎に適用有無や重要度を定めておくようにしてもよいし、しなくてもよい。
また、上記の認証スキップ条件データ２８３７において適用有無の欄を設けず、適用可能な認証スキップ条件のみ、認証スキップ条件データ２８３７に定めておくようにすることもできる。
また、この例では、認証スキップ条件に関連付けて重要度を設定しているが、この重要度の設定は必須の要件ではなく、重要度を設定しないようにすることもできる。つまり、上記の認証スキップ条件データ２８３７において重要度の欄は設けられていなくてもよい。
この場合は、認証スキップ判定処理において、限定ではなく例として、任意の順序で認証スキップ条件の成否を判定していき、いずれかの認証スキップ条件が成立する場合に、認証処理をスキップさせると判定するようにすればよい。
この場合は、認証スキップ判定処理において、限定ではなく例として、任意の順序で認証スキップ条件の成否を判定していき、いずれかの認証スキップ条件が成立する場合に、認証処理をスキップさせると判定するようにすればよい。
上記の認証スキップ条件データ２８３７における認証スキップ条件のカテゴリが示す情報や、各カテゴリに含まれる各認証スキップ条件の判定に使用される情報は、電子貨幣に関する情報に含まれる。
具体的には、例えば、「ＳＰ１（時間）」のカテゴリは、電子貨幣によって決済を行った時間に関する情報を含むが、この情報は、広義には電子貨幣に関する情報と言える。
また、例えば、「ＳＰ２（店舗・場所）」のカテゴリは、電子貨幣によって決済を行った場所に関する情報や、電子貨幣によって決済を行った店舗に関する情報を含むが、これらの情報は、広義には電子貨幣に関する情報と言える。
また、例えば、「ＳＰ３（金額）」のカテゴリは、電子貨幣の金額に関する情報を含むが、この情報は、広義には電子貨幣に関する情報と言える。
また、例えば、「ＳＰ４（商品）」のカテゴリは、電子貨幣によって購入する商品に関する情報を含むが、この情報は、広義には電子貨幣に関する情報と言える。
また、例えば、「ＳＰ２（店舗・場所）」のカテゴリは、電子貨幣によって決済を行った場所に関する情報や、電子貨幣によって決済を行った店舗に関する情報を含むが、これらの情報は、広義には電子貨幣に関する情報と言える。
また、例えば、「ＳＰ３（金額）」のカテゴリは、電子貨幣の金額に関する情報を含むが、この情報は、広義には電子貨幣に関する情報と言える。
また、例えば、「ＳＰ４（商品）」のカテゴリは、電子貨幣によって購入する商品に関する情報を含むが、この情報は、広義には電子貨幣に関する情報と言える。
なお、「〜に関する情報」という用語の意味合いは、他の例についても同様であるため、その都度の説明は省略する。
＜処理＞
図９−６は、本実施例における各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末２０の制御部２１が実行する決済アプリケーション処理の一例である第３の決済アプリケーション処理、店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例である第１の店舗決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例である第１の決済管理処理をそれぞれ示している。
図９−６は、本実施例における各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末２０の制御部２１が実行する決済アプリケーション処理の一例である第３の決済アプリケーション処理、店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例である第１の店舗決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例である第１の決済管理処理をそれぞれ示している。
図９−６のフローチャートは、図４−１２のフローチャートに、Ａ６４０〜Ａ６６０のステップを追加したものである。
なお、ここでは、図４−１２のフローチャートに６４０〜Ａ６６０のステップを追加する場合を例示するが、これらのステップは、他のフローチャート（例えば、図３−１のフローチャート、図３−４のフローチャート、図５−２のフローチャート、図６−３のフローチャート、図１０のフローチャート等）にも同様に追加することが可能である。
Ａ２４０の後、オフライン状態となり、例えば端末２０のユーザによってコード表示操作がなされると、認証スキップ判定処理部２１１７が、認証スキップ判定処理を行う（Ａ６４０）。
具体的には、限定ではなく例として、認証スキップ条件データ２８３７の適用有無に「〇」が関連付けて記憶されている認証スキップ条件のうち、限定ではなく例として、重要度に「Ａ」または「Ｂ」が関連付けられている認証スキップ条件を、適用する認証スキップ条件として決定する。そして、決定したそれぞれの認証スキップ条件の判定に必要な情報を取得して認証スキップ条件の成否を判定する。それぞれの認証スキップ条件の判定に必要な情報と判定方法とは、前述した通りである。そして、限定ではなく例として、少なくとも１つの認証スキップ条件が成立する場合は認証処理をスキップすると判定し、それ以外の場合は認証処理をスキップしないと判定する。
なお、上記の認証スキップ条件の決定方法や、認証スキップ条件の成否の判定方法は、あくまでも一例に過ぎず、これらに限定されない。
具体的には、限定ではなく例として、重要度に「Ａ」が関連付けられている認証スキップ条件のみを、適用する認証スキップ条件として決定するようにしてもよいし、そのようにしなくてもよい。また、重要度「Ｃ」の認証スキップ条件についても、適用する認証スキップ条件に含めるようにしてもよいし、そのようにしなくてもよい。
また、限定ではなく例として、重要度に「Ａ」が関連付けられている認証スキップ条件については、少なくとも１つの認証スキップ条件が成立すれば認証処理をスキップすると判定するが、重要度に「Ｂ」が関連付けられている認証スキップ条件については、全ての認証スキップ条件が成立する場合に認証処理をスキップすると判定するようにしてもよいし、そのようにしなくてもよい。
その後、制御部２１は、認証スキップ判定処理で認証処理をスキップすると判定されたか否かを判定する（Ａ６５０）。認証処理をスキップしないと判定されたならば（Ａ６５０：ＮＯ）、認証処理部２１１５が、認証処理を行う（Ａ６６０）。
具体的には、限定ではなく例として、認証画面を表示部２４に表示させ、ユーザに認証パスワードを入力させる。そして、入力された認証パスワードが、決済用データ２８３２Ｂに記憶されている認証パスワードと一致するか否かを判定する。そして、一致する場合は認証結果を「ＯＫ」とし、一致しない場合は認証結果を「ＮＧ」とする。
認証処理で認証結果が「ＮＧ」と判定されたならば、限定ではなく例として、制御部２１は、不図示のエラー処理を実行する。具体的には、限定ではなく例として、認証パスワードの再度の入力をユーザに促す報知を行い、再び認証処理を実行する。一方、認証処理で認証結果が「ＯＫ」と判定されたならば、制御部２１は、Ａ３５０へと処理を移す。
また、認証処理をスキップすると判定されたならば（Ａ６５０：ＹＥＳ）、制御部２１は、Ａ６６０の認証処理をスキップして、Ａ３５０へと処理を移す。
＜第６実施例の効果＞
第６実施例は、端末２０が、認証パスワード（限定ではなく、端末のユーザに関する情報の一例）を制御部２１によって取得する。そして、端末２０は、取得された認証パスワードに基づいて、認証処理を制御部２１によって実行する。そして、端末２０は、認証処理に基づいて、拡張端末表示用コード生成処理やコード表示処理（限定ではなく、決済に関する処理の一例）を制御部に２１によって実行する構成を示している。
このような構成により得られる効果の一例として、取得された端末のユーザに関する情報に基づいて、ユーザを認証する処理を実行した上で、決済に関する処理を行うことで、決済のセキュリティを高めることができる。
第６実施例は、端末２０が、認証パスワード（限定ではなく、端末のユーザに関する情報の一例）を制御部２１によって取得する。そして、端末２０は、取得された認証パスワードに基づいて、認証処理を制御部２１によって実行する。そして、端末２０は、認証処理に基づいて、拡張端末表示用コード生成処理やコード表示処理（限定ではなく、決済に関する処理の一例）を制御部に２１によって実行する構成を示している。
このような構成により得られる効果の一例として、取得された端末のユーザに関する情報に基づいて、ユーザを認証する処理を実行した上で、決済に関する処理を行うことで、決済のセキュリティを高めることができる。
また、第６実施例は、端末２０が、端末２０のユーザを認証するための認証処理をスキップするか否かを判定するための情報（限定ではなく、端末のユーザの認証に関する処理をスキップするための情報）を制御部２１によって取得する。そして、この情報を取得した場合、認証処理をスキップしてコード表示（限定ではなく、第１表示の一例）を一の領域に表示し、この情報を取得しなかった場合、認証処理を行い、コード表示を一の領域に表示する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザの認証に関する処理をスキップするための情報を制御部によって取得した場合、端末のユーザの認証に関する処理をスキップして第１表示を表示領域に表示するため、決済に要する時間を短縮することができる。一方、端末のユーザの認証に関する処理をスキップするための情報を制御部によって取得しなかった場合、端末のユーザの認証に関する処理を行い、第１表示を表示領域に表示することで、端末のユーザが正規のユーザであることを確認した上で、第１表示を表示領域に表示することができる。
このような構成により得られる効果の一例として、端末は、端末のユーザの認証に関する処理をスキップするための情報を制御部によって取得した場合、端末のユーザの認証に関する処理をスキップして第１表示を表示領域に表示するため、決済に要する時間を短縮することができる。一方、端末のユーザの認証に関する処理をスキップするための情報を制御部によって取得しなかった場合、端末のユーザの認証に関する処理を行い、第１表示を表示領域に表示することで、端末のユーザが正規のユーザであることを確認した上で、第１表示を表示領域に表示することができる。
本実施例では、オンライン状態に限らず、オフライン状態においても、端末２０で認証スキップ判定を行った上で、認証を行う、または、認証をスキップすることができる。また、サーバ側で認証スキップ判定や認証を行うのではなく、端末側で認証スキップ判定や認証を行うようにしているため、オフライン状態においても端末側で認証の実行／非実行を切り替えることができる。
また、本実施例では、オフライン状態ばかりでなく、オンライン状態においても、サーバ側で認証スキップ判定や認証を行うのではなく、端末側で認証スキップ判定や認証を行う。これにより、端末はサーバと不要な通信を行わずに済むため、素早くかつ円滑に決済を行わせることができる。
＜第６変形例（１）＞
第６実施例では、端末２０のユーザに対する認証の種類をパスワード認証とし、この認証の実行に関する表示処理を認証パスワード入力用の認証画面を表示する処理としたが、これに限定されない。この他にも、例えば、端末２０のユーザに対する認証の種類を顔認証、指紋認証、音声認証等の生体認証とし、これらの生体認証を行うために必要な認証画面を表示する処理を、端末のユーザに対する認証の実行に関する表示処理としてもよいし、しなくてもよい。
第６実施例では、端末２０のユーザに対する認証の種類をパスワード認証とし、この認証の実行に関する表示処理を認証パスワード入力用の認証画面を表示する処理としたが、これに限定されない。この他にも、例えば、端末２０のユーザに対する認証の種類を顔認証、指紋認証、音声認証等の生体認証とし、これらの生体認証を行うために必要な認証画面を表示する処理を、端末のユーザに対する認証の実行に関する表示処理としてもよいし、しなくてもよい。
また、限定ではなく例として、決済アプリケーションのアプリケーションＩＤ等のアカウントを取得するための認証処理における認証画面を表示する処理を、端末のユーザに対する認証の実行に関する表示処理とするようにしてもよいし、しなくてもよい。そして、この認証処理の結果が「ＯＫ」となった場合に、端末２０が、決済アプリケーションを利用するためのアカウントを、電子貨幣による決済に関する情報として、サーバ１０から受信するようにしてもよいし、しなくてもよい。
＜第６変形例（１）の効果＞
本変形例による効果の一例として、端末は、認証パスワードを用いた認証とは異なる認証についても同様に、端末のユーザに対する認証の実行に関する表示処理をすることなく、電子貨幣による決済に関する情報を簡単に受信することができる。
本変形例による効果の一例として、端末は、認証パスワードを用いた認証とは異なる認証についても同様に、端末のユーザに対する認証の実行に関する表示処理をすることなく、電子貨幣による決済に関する情報を簡単に受信することができる。
また、端末は、端末のユーザに対する認証の実行に関する表示処理をすることなく、決済サービスを利用するために必要な情報を、電子貨幣による決済に関する情報として簡単に取得することができる。
＜第６変形例（２）＞
第６実施例において、店舗データ２８３３に店舗位置情報を含めることとし、端末２０が、店舗データ２８３３に含まれる店舗位置情報が示す店舗位置と、位置算出処理部２１７によって算出された算出端末位置とに基づいて、認証スキップ判定を行うようにしてもよいし、しなくてもよい。
第６実施例において、店舗データ２８３３に店舗位置情報を含めることとし、端末２０が、店舗データ２８３３に含まれる店舗位置情報が示す店舗位置と、位置算出処理部２１７によって算出された算出端末位置とに基づいて、認証スキップ判定を行うようにしてもよいし、しなくてもよい。
具体的には、例えば、条件カテゴリＮｏ「ＳＰ２」に含まれる条件Ｎｏ「ＳＰ２−２」の「決済予定店舗が設定店舗」の認証スキップ条件を判定する際に、端末２０の最新の算出端末位置が、店舗データ２８３３に記憶されている設定店舗の位置と一致するか否かを判定するようにすることができる。
店舗・場所に関する他の認証スキップ条件についても同様である。
店舗・場所に関する他の認証スキップ条件についても同様である。
＜第６変形例（２）の効果＞
本変形例により得られる効果の一例として、端末は、自己の端末２０で算出した端末位置情報と、あらかじめ記憶された店舗位置情報とに基づいて、認証スキップ条件の成否を簡単に判定することができる。
本変形例により得られる効果の一例として、端末は、自己の端末２０で算出した端末位置情報と、あらかじめ記憶された店舗位置情報とに基づいて、認証スキップ条件の成否を簡単に判定することができる。
＜第６変形例（３）＞
第６実施例で説明した認証スキップ条件はあくまでも一例に過ぎず、適宜、追加や削除、変更することが可能である。
第６実施例で説明した認証スキップ条件はあくまでも一例に過ぎず、適宜、追加や削除、変更することが可能である。
具体的には、限定ではなく例として、条件Ｎｏ「ＳＰ１−１」の「現在日時が最終決済日時から設定時間内」とする認証スキップ条件を、「現在日時が最終認証日時から設定時間内」とすることもできる。これは、例えば、端末２０のユーザがある商品（例えば弁当）を購入する際に端末２０で認証を行った後、すぐに別の商品（例えばコーヒー）を購入するために端末２０での再度の認証が必要となるような場合が考えられるためである。
また、上記の「最終認証日時」は、必ずしも決済用の認証が最後に行われた日時に限られるわけではなく、限定ではなく例として、電子貨幣の個人間送金を行う場合における送金用の認証が最後に行われた日時や、端末２０のＯＳ側のロックを解除するための認証が最後に行われた日時、決済アプリケーション側のロックを解除するための認証が最後に行われた日時など、決済用の認証とは異なる種類の認証が最後に行われた日時を、上記の認証スキップ条件における「最終認証日時」とすることもできる。
また、限定ではなく例として、条件Ｎｏ「ＳＰ１−１」の認証スキップ条件における「最終決済日時」を、ユーザによって電子貨幣のチャージが行われた最新の日時である「最終チャージ日時」や、決済アプリケーション内で決済に関連するユーザ操作が行われた最新の日時である「最終決済関連操作日時」とすることもできる。電子貨幣が最後にチャージされてからそれほど時間が経過していなければ、決済のためにユーザが電子貨幣をチャージした可能性が高いため、認証処理をスキップさせるのは合理的である。また、決済アプリケーション内で決済に関連するユーザ操作が最後に行われてからそれほど時間が経過していなければ、ユーザが決済を行うことを予定して操作を行った可能性が高いため、認証処理をスキップさせるのは合理的である。
また、条件Ｎｏ「ＳＰ１−２」の認証スキップ条件における「設定時間帯」は、特定の曜日や特定の日付を含む概念とすることができる。限定ではなく例として、特定の曜日として、土曜日や日曜日を設定するなどしてもよい。土曜日や日曜日は、買い物や食事で外出するユーザが多く、決済が行われる機会が多くなる傾向があるためである。また、特定の日付として、クリスマス（クリスマスイブを含む。）や、正月の三が日、ゴールデンウィーク等を設定してもよい。クリスマスは、プレゼントの購入やディナーで外出するユーザが多い。また、三が日は、初売りで外出するユーザが多い。また、ゴールデンウィークは、行楽のために外出するユーザが多い。このため、それぞれ決済が行われる機会が増えると考えられるためである。
また、端末２０のユーザが、自身の端末２０を第三者に利用されて高額な商品を決済で購入され、それを換金されてしまうようなリスクも考えられる。そこで、限定ではなく例として、「決済予定店舗が換金性の高い商品を販売する店舗ではない」とする認証スキップ条件を追加することもできる。換金性の高い商品とは、例えば、宝飾品や腕時計といった商品であり、このような商品を販売する店舗（宝飾品店や腕時計店等）で決済が行われる予定である場合は、端末２０で認証処理をスキップさせないようにすることができる。
また、天気や天候に関連する認証スキップ条件を追加するようにすることもできる。例えば、雨の日や雪の日は、公共交通機関を利用するユーザが増えるため、端末２０の置き忘れが発生するリスクが高まる。このため、限定ではなく例として、「当日の天気が雨または雪ではない」とする認証スキップ条件を追加し、雨の日や雪の日には認証処理をスキップさせないようにすることもできる。
＜第６変形例（３）の効果＞
本変形例により得られる効果の一例として、端末は、電子貨幣による決済に際して、決済用の認証が最後に行われた日時から設定された時間内である場合ばかりでなく、決済用の認証とは異なる種類の認証が最後に行われた日時から設定された時間内である場合も、認証の実行に関する表示を行わないようにすることで、ユーザの利便性をより一層向上させることができる。
本変形例により得られる効果の一例として、端末は、電子貨幣による決済に際して、決済用の認証が最後に行われた日時から設定された時間内である場合ばかりでなく、決済用の認証とは異なる種類の認証が最後に行われた日時から設定された時間内である場合も、認証の実行に関する表示を行わないようにすることで、ユーザの利便性をより一層向上させることができる。
また、電子貨幣による決済に際して、電子貨幣の入金が最後に行われた日時から設定された時間内である場合や、アプリケーション内での決済に関する操作が最後に行われた日時から設定された時間内である場合に、認証の実行に関する表示を行わないようにすることで、ユーザの利便性をより一層向上させることができる。
また、特定の曜日や特定の日付である場合に、認証の実行に関する表示を行わないようにすることで、ユーザの利便性をより一層向上させることができる。
また、ユーザのリスクを考慮した情報に基づいて、端末のユーザに対する認証の実行に関する表示処理を行わないようにすることで、ユーザの利便性とリスクとのバランスを考慮した適切な決済を実現することができる。
＜第６変形例（４）＞
第６実施例では、端末２０が購入予定商品に関する情報を取得できないため、「ＳＰ４（商品）」の認証スキップ条件を適用できないこととしたが、例えば以下の手法によって適用可能とすることができる。
第６実施例では、端末２０が購入予定商品に関する情報を取得できないため、「ＳＰ４（商品）」の認証スキップ条件を適用できないこととしたが、例えば以下の手法によって適用可能とすることができる。
具体的には、限定ではなく例として、決済アプリケーションの機能として備えられたカメラ（以下、「アプリケーションカメラ」と称す。）、または、端末２０の機能として備えられたカメラ２７等の撮像装置（または撮像部）によって撮影された撮影画像に基づいて、商品の種別を識別可能とするためのソフトウェアを、あらかじめ端末２０の記憶部２８に記憶させておく。
端末２０は、ユーザ操作に従って、アプリケーションカメラまたはカメラ２７を起動して、購入予定の商品の画像を撮影する。つまり、端末２０のユーザは、店舗のコードレジ６０で、購入予定の商品の画像をアプリケーションカメラまたはカメラ２７で撮影する。そして、端末２０は、撮影画像から商品の種別を識別する商品種別識別処理を行う。
図９−７は、この場合における認証スキップ条件データ２８３７の一例を示す図である。このデータ構成は、図９−５の認証スキップ条件データ２８３７と同様であるが、黒色の太枠で囲った部分が異なっている。
具体的には、条件Ｎｏ「ＳＰ４−１」の「購入予定商品が日用消費財」の認証スキップ条件について適用有無に「〇」が定められている。これは、上記の手法を用いることで、端末２０で商品の種別を識別することが可能となるため、識別した商品の種別に基づいて、購入予定商品が日用消費財であるか否かを判定することができるためである。また、一例として、重要度には「Ｂ」が定められている。
また、条件Ｎｏ「ＳＰ４−２」の「購入予定商品の購入履歴あり」の認証スキップ条件について適用有無に「〇」が定められている。これは、上記の手法を用いることで、端末２０で商品の種別を識別することが可能となるため、識別した商品の種別の履歴を記憶部２８に記憶しておくことで、購入予定商品の購入履歴があるか否かを判定することができるためである。また、一例として、重要度には「Ｂ」が定められている。
また、上記のように端末２０のカメラで購入予定商品の画像を撮影する他にも、例えば店舗コードリーダ装置５０にカメラを備えておき、店舗コードリーダ装置５０のカメラで、端末２０のユーザの購入予定商品の画像を撮影するようにすることもできる。
この場合は、限定ではなく例として、店舗コードリーダ装置５０が、カメラで撮影した撮影画像に基づいて購入予定商品の種別を識別する。そして、識別した購入予定商品の種別の情報を端末２０に送信するようにすることができる。
また、他の手法として、店舗コードリーダ装置５０が、カメラで撮影した撮影画像のデータを端末２０に送信する。そして、端末２０が、店舗コードリーダ装置５０から受信した撮影画像のデータに基づいて購入予定商品の種別を識別するようにすることもできる。
この場合、例えば、前述した第１通信方式によって通信を行うことができない場合であっても、第２通信方式によって通信を行うことができる場合は、第２通信方式によって、商品に関する情報やデータを店舗コードリーダ装置５０から端末２０に送信することができる。または、ブルートゥースや赤外線通信等の近距離無線通信方式を利用可能であれば、これらの通信方式によって、商品に関する情報やデータを店舗コードリーダ装置５０から端末２０に送信することができる。
＜第６変形例（４）の効果＞
本変形例は、前述した認証パスワードとは異なる情報は、店舗で販売される商品の情報（限定ではなく、商品に関する情報の一例）を含む構成を示している。
このような構成により得られる効果の一例として、端末は、商品に関する情報に基づいて、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
本変形例は、前述した認証パスワードとは異なる情報は、店舗で販売される商品の情報（限定ではなく、商品に関する情報の一例）を含む構成を示している。
このような構成により得られる効果の一例として、端末は、商品に関する情報に基づいて、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
また、本変形例は、端末２０が、端末２０のアプリケーションカメラまたはカメラ２７（限定ではなく、撮像装置の一例）によって撮影された購入予定商品の撮影画像を取得し、取得した撮影画像に基づいて、認証処理を行わない構成を示している。
このような構成により得られる効果の一例として、端末は、撮像装置によって撮影された商品の画像に基づいて、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができる。例えば、撮像装置によって撮影された画像から識別される商品が、過去に購入履歴がある商品である場合や、特定の種別の商品である場合は、認証の実行に関する表示を行わないことで、ユーザの利便性を向上させることができる。
このような構成により得られる効果の一例として、端末は、撮像装置によって撮影された商品の画像に基づいて、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができる。例えば、撮像装置によって撮影された画像から識別される商品が、過去に購入履歴がある商品である場合や、特定の種別の商品である場合は、認証の実行に関する表示を行わないことで、ユーザの利便性を向上させることができる。
また、本変形例は、前述した認証パスワードとは異なる情報は、購入予定商品の情報（限定ではなく、端末のユーザが購入する商品に関する情報の一例）を含む構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザが購入する商品に関する情報に基づいて、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
このような構成により得られる効果の一例として、端末は、端末のユーザが購入する商品に関する情報に基づいて、端末のユーザに対する認証の実行に関する表示処理をせずに済むため、端末の処理負荷を軽減することができる。
また、本変形例は、端末２０のユーザの購入予定商品の情報を取得し、購入予定商品の購入履歴があると判定した場合に、認証処理を行わない構成を示している。
このような構成により得られる効果の一例として、端末は、商品が端末のユーザが一度以上購入した商品と一致した場合、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができる。また、同じ商品を購入するのであれば、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
このような構成により得られる効果の一例として、端末は、商品が端末のユーザが一度以上購入した商品と一致した場合、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができる。また、同じ商品を購入するのであれば、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
また、本変形例は、端末２０のユーザの購入予定商品の情報を取得し、購入予定商品が日用消費財であると判定した場合に、認証処理を行わない構成を示している。
このような構成により得られる効果の一例として、端末が、ユーザが購入する商品が日用消費財である場合、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができる。また、日用消費財を購入するのであれば、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
このような構成により得られる効果の一例として、端末が、ユーザが購入する商品が日用消費財である場合、認証の実行に関する表示を行わないため、端末の処理負荷を軽減することができる。また、日用消費財を購入するのであれば、危険性は低いと考えられるため、認証の実行に関する表示を行わないことで、安全性を確保しつつ、ユーザの利便性を向上させることができる。
なお、上記の他にも、端末２０のユーザが購入する商品やその商品種別を端末２０で識別する方法として、限定ではなく例として、非接触式通信を用いた手法を適用することもできる。
具体的には、限定ではなく例として、店舗で販売される商品毎または商品種別毎に、商品識別情報または商品種別識別情報が格納されたＲＦタグ（例えばＩＣタグ）を埋め込んでおく。また、端末２０には、ＲＦタグ対応のリーダライタを備えておく。そして、端末２０は、ユーザが購入する商品に埋め込まれたＲＦタグを電波でスキャンし、ＲＦタグに格納された商品識別情報や商品種別識別情報を取得することで、ユーザが購入する商品やその商品種別を識別する。
＜第７実施例＞
オフライン決済を行った場合、オンライン状態に復帰して端末２０がサーバ１０から端末用決済完了通知を受信しなければ、端末２０のユーザは、決済が無事に行われたことを知ることができない。このため、例えば、店舗コードリーダ装置５０によってサーバ１０から店舗用決済完了通知を受信したことによって、決済が無事に行われたことを認識しているにも関わらず、悪意のある店舗の店員等が、エラーが生じたなどと端末２０のユーザに口頭で指摘し、現金払いを迫るような詐欺を行うことも想定される。
オフライン決済を行った場合、オンライン状態に復帰して端末２０がサーバ１０から端末用決済完了通知を受信しなければ、端末２０のユーザは、決済が無事に行われたことを知ることができない。このため、例えば、店舗コードリーダ装置５０によってサーバ１０から店舗用決済完了通知を受信したことによって、決済が無事に行われたことを認識しているにも関わらず、悪意のある店舗の店員等が、エラーが生じたなどと端末２０のユーザに口頭で指摘し、現金払いを迫るような詐欺を行うことも想定される。
第７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図１０は、本実施例における各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末２０の制御部２１が実行する決済アプリケーション処理の一例である第３の決済アプリケーション処理、店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例である第２の店舗決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例である第１の決済管理処理をそれぞれ示している。
図１０のフローチャートは、図４−１２のフローチャートに、Ｂ３９０のステップを追加したものである。
Ｂ２８０において、通信Ｉ／Ｆ５４によってサーバ１０から店舗用決済完了通知を受信すると、制御部５１は、決済完了確認報知処理を行う（Ｂ３９０）。具体的には、例えば、決済が完了（成功）したことを示す音声や、なんらかの効果音（例えば、チャイムの音「ピンポーン」やレジの音「チャリーン」）を、音出力部５６から出力させる。このようにすることで、端末２０のユーザは、店舗コードリーダ装置５０から出力される音によって、無事に決済が完了したことを確認することができる。
また、この他にも、制御部５１が、決済が完了（成功）したことを示すメッセージを含む決済完了確認画面を表示部５３に表示させるようにすることもできる。この場合は、限定ではなく例として、店舗側で、店舗独自の決済完了確認画面を用意しておき、決済が完了した場合は、決済完了確認画面を客に提示するように義務付けておく。このようにすることで、端末２０のユーザは、店舗コードリーダ装置５０に表示される画面によって、無事に決済が完了したことを確認することができる。
なお、店舗コードリーダ装置５０の表示部５３に決済完了確認画面を表示させるようにするのではなく、限定ではなく例として、コードレジ６０と一体として、またはコードレジ６０と別体として設けられ、客側に表示面が向けられたディスプレイに決済完了確認画面を表示させるようにしてもよいし、そのようにしなくてもよい。
＜第７実施例の効果＞
第７実施例によれば、例えば、オフライン決済が行われたことを店舗側で端末２０のユーザに報知するため、店舗側の不正を防止することができるとともに、ユーザの利便性を向上させることができる。
第７実施例によれば、例えば、オフライン決済が行われたことを店舗側で端末２０のユーザに報知するため、店舗側の不正を防止することができるとともに、ユーザの利便性を向上させることができる。
＜第８実施例＞
第８実施例は、オフライン決済の結果に不審な点がある場合の対処法に関する実施例である。
第８実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
第８実施例は、オフライン決済の結果に不審な点がある場合の対処法に関する実施例である。
第８実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図１１−１は、本実施例においてサーバ１０の記憶部１５に記憶される決済管理データベース１５７の一例である決済管理データベース１５７Ｂの構成例を示す図である。
決済管理データベース１５７Ｂには、端末２０毎、または端末２０のユーザ毎に生成される決済管理データが記憶される。
決済管理データベース１５７Ｂには、端末２０毎、または端末２０のユーザ毎に生成される決済管理データが記憶される。
各決済管理データには、アプリケーションＩＤと、残高と、ポイントと、１日上限設定金額と、オートチャージ設定と、決済履歴データとの他に、限定ではなく例として、信用スコアが記憶される。
信用スコアは、端末２０のユーザの社会的な信用を数値やランク等で表したものである。
信用スコアは、限定ではなく例として、端末２０のユーザの支払い実績、年齢、勤務形態、年収等をもとに算出され、随時更新される。
信用スコアは、限定ではなく例として、端末２０のユーザの支払い実績、年齢、勤務形態、年収等をもとに算出され、随時更新される。
限定ではなく例として、信用スコアを「０点」〜「１００点」の点数方式で数値化し、信用スコア「１００点」がユーザの社会的な信用が最も高く、信用スコア「０点」がユーザの社会的な信用が最も低いことを示すようにすることができる。
図１１−２は、本実施例においてサーバ１０の記憶部１５に記憶されるコード管理データ１５９の一例であるコード管理データ１５９Ｂの構成例を示す図である。
コード管理データ１５９Ｂには、限定ではなく例として、コード生成日時と、アプリケーションＩＤと、決済用番号とが関連付けて時系列に記憶される。
コード管理データ１５９Ｂには、限定ではなく例として、コード生成日時と、アプリケーションＩＤと、決済用番号とが関連付けて時系列に記憶される。
本実施例において、サーバ１０は、オフライン状態において決済処理を行った後、そのアプリケーションＩＤに関連付けて決済管理データに記憶されている信用スコアを判定する。そして、限定ではなく例として、判定した信用スコアが、設定された閾値スコア以下（または所定の閾値スコア未満）である場合、決済に間違いかないかを端末２０のユーザに確認するための決済確認通知を端末２０に送信する。端末２０は、オンライン状態に復帰した後、この決済確認通知を受信する。
なお、この場合において、信用スコアと、決済金額との関係に基づいて、上記の閾値スコアを変更するようにしてもよいし、そのようにしなくてもよい。具体的には、限定ではなく例として、決済金額が大きいほど、閾値スコアを高くして、決済確認通知が端末２０に送信され易くなるようにする。逆に、決済金額が小さいほど、信用スコアを低くして、決済確認通知が端末２０に送信されにくくなるようにする。
また、サーバ１０は、オフライン状態において決済処理を行った後、コード管理データ１５９Ｂを参照し、決済処理を行ったアプリケーションＩＤおよび決済用番号に関連付けて記憶されているコード生成日時を判定する。そして、限定ではなく例として、判定したコード生成日時から決済処理を行った日時までの経過時間が、設定された閾値時間以上（または閾値時間超）である場合、決済に間違いかないかを端末２０のユーザに確認するための決済確認通知を端末２０に送信する。端末２０は、オンライン状態に復帰した後、この決済確認通知を受信する。
なお、この場合において、経過時間と、決済金額との関係に基づいて、上記の閾値時間を変更するようにしてもよいし、そのようにしなくてもよい。具体的には、限定ではなく例として、決済金額が大きいほど、閾値時間を短くして、決済確認通知が端末２０に送信され易くなるようにする。逆に、決済金額が小さいほど、閾値時間を長くして、決済確認通知が端末２０に送信されにくくなるようにする。
決済確認通知を受信すると、端末２０の制御部２１は、限定ではなく例として、受信された決済確認通知を表示部２４に表示させる。この場合、端末２０のユーザは、決済確認通知の内容を確認して、自身による適正な決済であるか否かを確認する。そして、適正な決済ではないと判断した場合は、自己の端末２０を用いて、決済の異議に関する連絡をサーバ１０に行う。
＜第８実施例の効果＞
第８実施例によれば、端末は、サーバによってオフライン決済が行われた場合、条件が成立したことに基づいて、オンライン状態に復帰した後、決済の確認に関する情報をサーバから受信して報知する。これにより、端末のユーザは、決済に不審な点がないかどうかを確認することができる。また、不審な点がある場合、ユーザは、自己の端末を用いて異議を申し立てることができる。
第８実施例によれば、端末は、サーバによってオフライン決済が行われた場合、条件が成立したことに基づいて、オンライン状態に復帰した後、決済の確認に関する情報をサーバから受信して報知する。これにより、端末のユーザは、決済に不審な点がないかどうかを確認することができる。また、不審な点がある場合、ユーザは、自己の端末を用いて異議を申し立てることができる。
１ 通信システム
１０ サーバ
２０ 端末
３０ ネットワーク
４０ 店舗ＰＯＳシステム
５０ 店舗コードリーダ装置
６０ コードレジ
７０ 店舗サーバ
１０ サーバ
２０ 端末
３０ ネットワーク
４０ 店舗ＰＯＳシステム
５０ 店舗コードリーダ装置
６０ コードレジ
７０ 店舗サーバ
Claims (25)
- コード画像による決済を行うための第１情報に基づいて前記決済に関する処理を実行する端末の情報処理方法であって、
サーバから送信された前記第１情報を、前記端末の通信部を介して受信することと、
受信された前記第１情報を、前記端末の制御部によって前記端末の記憶部に記憶することと、
前記第１情報と、時刻情報とに基づく第１コード画像を前記端末の表示領域に表示することとを含み、
前記時刻情報は、前記第１コード画像の前記表示領域への表示に基づく時刻の情報を含み、
前記決済は、前記第１コード画像の表示に基づき前記サーバが受信する前記第１情報と、前記時刻情報とに基づいて前記サーバによって実行される。 - 請求項１に記載の情報処理方法であって、
前記第１コード画像は、前記表示領域の第１領域に表示される前記第１情報に基づく第２コード画像と、前記表示領域の第２領域に表示される前記時刻情報に基づく第３コード画像とを含む。 - 請求項１に記載の情報処理方法であって、
前記第１コード画像は、前記第１情報と前記時刻情報とに基づく一つのコード画像である。 - 請求項１から請求項３のいずれか一項に記載の情報処理方法であって、
前記決済は、前記第１コード画像がコード読み取り装置に読み取られることに基づき、前記第１情報と前記時刻情報とが前記サーバに送付され、前記第１情報と前記時刻情報とに基づいて前記サーバによって実行される。 - 請求項４に記載の情報処理方法であって、
前記決済は、前記時刻情報と、前記コード読み取り装置による前記第１コード画像の読み取りに基づく時刻の情報とに基づいて前記サーバによって実行される。 - 請求項５に記載の情報処理方法であって、
前記決済は、前記時刻情報と、前記コード読み取り装置による前記第１コード画像の読み取りに基づく時刻の情報とが、前記サーバで設定された有効期限内の場合、前記サーバによって実行される。 - 請求項１から請求項６のいずれか一項に記載の情報処理方法であって、
前記端末の時刻の自動調整に関する設定を行うことを含み、
前記第１コード画像は、前記自動調整に関する設定に基づいて、前記表示領域に表示される。 - 請求項１から請求項６のいずれか一項に記載の情報処理方法であって、
前記サーバから、基準の時刻に関する情報を前記制御部によって取得することを含み、
前記時刻情報は、前記基準の時刻に関する情報に基づく情報である。 - 請求項１から請求項８のいずれか一項に記載の情報処理方法であって、
前記第１情報に基づく前記決済の完了に基づいて、前記第１情報とは異なる第２情報を前記通信部を介して受信することと、
受信された前記第２情報を前記記憶部に記憶することとを含む。 - 請求項９に記載の情報処理方法であって、
前記通信部の通信状況に基づいて、前記第２情報を前記通信部を介して受信することを含む。 - 請求項１０に記載の情報処理方法であって、
前記通信部による通信が行える場合、前記第２情報を取得するための情報を前記通信部を介して前記サーバに送信することを含む。 - 請求項１０に記載の情報処理方法であって、
前記第２情報は、前記サーバからプッシュ送信される。 - 請求項１から請求項１２のいずれか一項に記載の情報処理方法であって、
前記端末のユーザによる、前記決済に使用可能な電子貨幣の残高の更新に関する入力に基づいて、前記第１情報とは異なる第２情報を前記通信部を介して受信することと、
受信された前記第２情報を前記記憶部に記憶することとを含む。 - 請求項１から請求項１３のいずれか一項に記載の情報処理方法であって、
前記決済に使用可能な電子貨幣の残高の情報を前記表示領域に表示することを含む。 - 請求項１４に記載の情報処理方法であって、
前記通信部の通信状況に基づいて、前記制御部によって前記通信部を介して前記残高の情報を前記サーバから受信することと、
受信された前記残高の情報を前記表示領域に表示することとを含む。 - 請求項１４または請求項１５に記載の情報処理方法であって、
前記残高の情報が前記表示領域に表示された日付に関する情報、または前記残高の情報が前記表示領域に表示された時刻に関する情報を、前記表示領域に表示することを含む。 - 請求項１４から請求項１６のいずれか一項に記載の情報処理方法であって、
前記残高の情報の修正に関する入力に基づいて、前記表示領域に表示された前記残高を修正することを含む。 - 請求項１４から請求項１７のいずれか一項に記載の情報処理方法であって、
前記端末のユーザの入力により前記残高の情報の更新を行うための表示を前記表示領域に表示することを含む。 - 請求項１に記載の情報処理方法であって、
前記決済に使用可能な電子貨幣の残高の情報を前記表示領域に表示することと、
前記端末のユーザの入力により前記残高の情報の更新を行うための表示を前記表示領域に表示することと、
前記表示領域の第３領域に前記第１コード画像を表示し、前記表示領域の第４領域に前記残高の情報を表示することと、
前記残高の情報の更新を行うための表示に対する前記端末のユーザによる入力に基づいて、前記第３領域に前記第１コード画像が表示された状態で、前記第４領域に表示された前記残高の情報を更新することとを含む。 - 請求項１から請求項１９のいずれか一項に記載の情報処理方法であって、
前記端末のユーザに関する情報を前記制御部によって取得することと、
取得された前記端末のユーザに関する情報に基づいて、前記ユーザを認証する処理を前記制御部によって実行することと、
前記ユーザを認証する処理に基づいて、前記決済に関する処理を前記制御部によって実行することとを含む。 - 請求項１から請求項２０のいずれか一項に記載の情報処理方法であって、
前記端末のユーザの認証に関する処理をスキップするための情報を前記制御部によって取得することと、
前記スキップするための情報を取得した場合、前記端末のユーザの認証に関する処理をスキップして前記第１コード画像を前記表示領域に表示し、前記スキップするための情報を取得しなかった場合、前記端末のユーザの認証に関する処理を行い、前記第１コード画像を前記表示領域に表示することとを含む。 - コード画像による決済を行うための第１情報に基づいて前記決済に関する処理を実行する端末のコンピュータによって実行されるプログラムであって、
サーバから送信された前記第１情報を、前記端末の通信部を介して受信することと、
受信された前記第１情報を前記端末の記憶部に記憶することと、
前記第１情報と、時刻情報とに基づく第１コード画像を前記端末の表示領域に表示することとを含み、
前記時刻情報は、前記第１コード画像の前記表示領域への表示に基づく時刻の情報を含み、
前記決済は、前記第１コード画像の表示に基づき前記サーバが受信する前記第１情報と、前記時刻情報とに基づいて前記サーバによって実行される。 - コード画像による決済を行うための第１情報に基づいて前記決済に関する処理を実行する端末であって、
サーバから送信された前記第１情報を受信する通信部と、
受信された前記第１情報を前記端末の記憶部に記憶する制御を行う制御部と、
前記第１情報と、時刻情報とに基づく第１コード画像を表示する表示部とを備え、
前記時刻情報は、前記第１コード画像の前記表示部への表示に基づく時刻の情報を含み、
前記決済は、前記第１コード画像の表示に基づき前記サーバが受信する前記第１情報と、前記時刻情報とに基づいて前記サーバによって実行される。 - コード画像による決済を行うための第１情報に基づいて前記決済に関する処理を実行する端末であって、
プログラムを記憶するメモリから前記プログラムを読み出し、前記プログラムに基づいて処理を実行するプロセッサーを備え、
前記プロセッサーは、
サーバから送信された前記第１情報を、前記端末の通信部を介して受信することと、
受信された前記第１情報を前記端末の記憶部に記憶することと、
前記第１情報と、時刻情報とに基づく第１コード画像を前記端末の表示領域に表示することとを実行し、
前記時刻情報は、前記第１コード画像の前記表示領域への表示に基づく時刻の情報を含み、
前記決済は、前記第１コード画像の表示に基づき前記サーバが受信する前記第１情報と、前記時刻情報とに基づいて前記サーバによって実行される。 - コード画像による決済を行うための第１情報に基づいて前記決済に関する処理を行う端末の前記決済を実行するサーバの情報処理方法であって、
第１情報を前記サーバの通信部を介して前記端末に送信することと、
前記端末の表示領域に表示された前記第１情報と、時刻情報とに基づく第１コード画像がコード読み取り装置によって読み取られたことに基づき、前記コード読み取り装置から送信された、前記第１コード画像に基づく前記第１情報と、前記時刻情報とを前記通信部を介して受信することと、
前記第１情報と、前記時刻情報と、前記コード読み取り装置による前記第１コード画像の読み取りに基づく時刻の情報とに基づいて、前記決済を行うこととを含み、
前記時刻情報は、前記第１コード画像の前記表示領域への表示に基づく時刻の情報を含む。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2019112042A JP7493916B2 (ja) | 2019-06-17 | 2019-06-17 | プログラム、情報処理方法、端末 |
| PCT/JP2020/020257 WO2020255620A1 (ja) | 2019-06-17 | 2020-05-22 | 情報処理方法、プログラム、端末 |
| KR1020217039960A KR20220020267A (ko) | 2019-06-17 | 2020-05-22 | 정보 처리 방법, 프로그램, 단말 |
| CN202080043494.5A CN113950710A (zh) | 2019-06-17 | 2020-05-22 | 信息处理方法、程序、终端 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2019112042A JP7493916B2 (ja) | 2019-06-17 | 2019-06-17 | プログラム、情報処理方法、端末 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2020204882A true JP2020204882A (ja) | 2020-12-24 |
| JP2020204882A5 JP2020204882A5 (ja) | 2022-07-08 |
| JP7493916B2 JP7493916B2 (ja) | 2024-06-03 |
Family
ID=73837034
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2019112042A Active JP7493916B2 (ja) | 2019-06-17 | 2019-06-17 | プログラム、情報処理方法、端末 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP7493916B2 (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7440596B1 (ja) | 2022-11-21 | 2024-02-28 | 楽天グループ株式会社 | 決済サーバ、決済方法及びプログラム |
| JP7445055B1 (ja) | 2023-05-17 | 2024-03-06 | ＰａｙＰａｙ株式会社 | アプリケーションプログラム、決済制御方法、決済サーバ、プログラム、および決済システム |
| JP7446508B1 (ja) | 2023-05-17 | 2024-03-08 | ＰａｙＰａｙ株式会社 | アプリケーションプログラム、決済制御方法、決済サーバ、プログラム、および決済システム |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008250884A (ja) * | 2007-03-30 | 2008-10-16 | Cyber Coin Kk | 認証システム、認証システムに用いられるサーバ、移動体通信端末、プログラム |
| JP2018041118A (ja) * | 2014-12-16 | 2018-03-15 | 大日本印刷株式会社 | 店舗端末装置、会員管理サーバー、決済代行サーバー、および決済方法 |
| JP2018077639A (ja) * | 2016-11-08 | 2018-05-17 | 株式会社ブイシンク | 決済システム |
| JP2019500703A (ja) * | 2015-12-29 | 2019-01-10 | アリババ グループ ホウルディング リミテッド | バーコードベースのモバイル決済及びサービス処理の方法及び装置 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006039728A (ja) | 2004-07-23 | 2006-02-09 | Nec Corp | 認証システム及び認証方法 |
-
2019
- 2019-06-17 JP JP2019112042A patent/JP7493916B2/ja active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008250884A (ja) * | 2007-03-30 | 2008-10-16 | Cyber Coin Kk | 認証システム、認証システムに用いられるサーバ、移動体通信端末、プログラム |
| JP2018041118A (ja) * | 2014-12-16 | 2018-03-15 | 大日本印刷株式会社 | 店舗端末装置、会員管理サーバー、決済代行サーバー、および決済方法 |
| JP2019500703A (ja) * | 2015-12-29 | 2019-01-10 | アリババ グループ ホウルディング リミテッド | バーコードベースのモバイル決済及びサービス処理の方法及び装置 |
| JP2018077639A (ja) * | 2016-11-08 | 2018-05-17 | 株式会社ブイシンク | 決済システム |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7440596B1 (ja) | 2022-11-21 | 2024-02-28 | 楽天グループ株式会社 | 決済サーバ、決済方法及びプログラム |
| EP4372654A1 (en) | 2022-11-21 | 2024-05-22 | Rakuten Group, Inc. | Settlement server, settlement method, and program |
| JP7445055B1 (ja) | 2023-05-17 | 2024-03-06 | ＰａｙＰａｙ株式会社 | アプリケーションプログラム、決済制御方法、決済サーバ、プログラム、および決済システム |
| JP7446508B1 (ja) | 2023-05-17 | 2024-03-08 | ＰａｙＰａｙ株式会社 | アプリケーションプログラム、決済制御方法、決済サーバ、プログラム、および決済システム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP7493916B2 (ja) | 2024-06-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20210110383A1 (en) | Generation method, program and information processing device | |
| US20210110393A1 (en) | Authentication method, program, and terminal | |
| US20180103341A1 (en) | System for location based authentication | |
| KR20170097695A (ko) | 거래 승인 | |
| JP6815447B1 (ja) | プログラム、情報処理方法、端末 | |
| JP7493916B2 (ja) | プログラム、情報処理方法、端末 | |
| WO2020255621A1 (ja) | 情報処理方法、プログラム、端末、サーバ | |
| US11521192B2 (en) | Settlement system, user terminal and method executed thereby, settlement device and method executed thereby, and program | |
| JP2016136665A (ja) | 動的認証システム、動的認証方法、動的認証用読取装置、ユーザー端末装置、及び動的認証プログラム | |
| JP2020204883A (ja) | 情報処理方法、プログラム、端末 | |
| JP2021082307A (ja) | プログラム、情報処理方法、端末 | |
| US20230325827A1 (en) | Information processing apparatus, program, method and terminal | |
| JP7306770B2 (ja) | プログラム、情報処理方法、端末 | |
| WO2020255620A1 (ja) | 情報処理方法、プログラム、端末 | |
| WO2021014786A1 (ja) | 情報処理方法、プログラム、端末 | |
| JP6765483B1 (ja) | 情報処理方法、プログラム、端末 | |
| US20220108298A1 (en) | Information processing method, program, and terminal | |
| JP6825160B2 (ja) | プログラム、情報処理方法、端末 | |
| JP7343258B2 (ja) | プログラム、情報処理方法、情報処理装置 | |
| JP7306771B2 (ja) | プログラム、情報処理方法、端末 | |
| JP7506457B2 (ja) | プログラム、情報処理方法、サーバ | |
| JP2021092888A (ja) | 決済装置、制御方法、及びプログラム | |
| JP2020149081A (ja) | 情報処理方法、プログラム、端末、サーバ | |
| JP7364311B2 (ja) | プログラム、情報処理方法、端末 | |
| JP7466477B2 (ja) | プログラム、情報処理方法、端末、サーバ |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190731 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20220616 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20220630 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20230606 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20230712 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20231024 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20231225 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20231225 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20240219 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20240423 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20240522 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 7493916 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |