JP2023011081A - 決済システム、決済方法、及びプログラム - Google Patents

Abstract

【課題】利便性を維持しつつ、決済手段の不正利用を防止する決済システム、決済方法及びプログラムを提供する。【解決手段】決済システムにおいて、サーバは、所定の決済手段が不正に利用された場合に、決済手段を利用可能な複数の店舗又は複数の端末の中から選択された対象店舗又は対象端末で利用可能な決済手段に関する上限を設定する設定部と、対象店舗又は対象端末における決済手段の利用に関する利用要求を受け付ける受付部と、利用要求が受け付けられた場合に、上限に基づいて、決済手段を利用するための利用処理を実行する実行部と、を含む。【選択図】図４

Description

本開示は、決済システム、決済方法、及びプログラムに関する。

従来、ポイントやクレジットカード等の決済手段に関する不正を防止する技術が知られている。特許文献１には、ポイントカードにポイントを付与する操作に不正が疑われる場合に、ポイントを付与しないようにする技術が記載されている。特許文献２には、所定のルールに基づいてクレジットカードを利用した決済の不正を検知し、不正が検知された決済を実行しないようにする技術が記載されている。特許文献３には、電子マネーの不正利用が発生した回数に応じて、電子マネーの利用を禁止する店舗を決定する技術が記載されている。特許文献４には、ユーザのウォレットを家族で共有する場合に、家族が利用可能な総額を制限する技術が記載されている。

特開２０１９－８２８９２号公報 再公表２０１９－２３０９８６号公報 特開２００８－１８６４１９号公報 特開２００１－１５５１０７号公報

しかしながら、特許文献１の技術では、ポイントの付与を制限するだけであり、ポイントの不正利用は防止できない。特許文献２の技術では、ルールに合致しない決済は実行されるため、ルールに合致しない不正利用は防止できない。特許文献３の技術では、電子マネーの利用が禁止された店舗では、電子マネーを一切利用できなくなるので、利便性が損なわれる。特許文献４の技術では、家族が利用可能な総額を制限するだけであり、ウォレットの不正利用は防止できない。このため、従来の技術では、利便性を維持しつつ、決済手段の不正利用を防止できなかった。

本開示の目的の１つは、利便性を維持しつつ、決済手段の不正利用を防止することである。

本開示に係る決済システムは、所定の決済手段が不正に利用された場合に、前記決済手段を利用可能な複数の店舗又は複数の端末の中から選択された対象店舗又は対象端末で利用可能な前記決済手段に関する上限を設定する設定手段と、前記対象店舗又は前記対象端末における前記決済手段の利用に関する利用要求を受け付ける受付手段と、前記利用要求が受け付けられた場合に、前記上限に基づいて、前記決済手段を利用するための利用処理を実行する実行手段と、を含む。

本開示によれば、利便性を維持しつつ、決済手段の不正利用を防止できる。

第１実施形態に係る決済システムの全体構成の一例を示す図である。 第三者が他人のポイントを不正に利用する様子の一例を示す図である。 第１実施形態の概要を示す図である。 第１実施形態の決済システムで実現される機能の一例を示す機能ブロック図である。 第１実施形態のユーザデータベースの一例を示す図である。 第１実施形態の店舗データベースの一例を示す図である。 第１実施形態の決済システムで実行される処理の一例を示すフロー図である。 第２実施形態のユーザデータベースの一例を示す図である。 第２実施形態の店舗データベースの一例を示す図である。 第２実施形態の決済システムで実行される処理の一例を示すフロー図である。 第１実施形態に係る変形例の機能ブロック図である。 第２実施形態に係る変形例の機能ブロック図である。

［１．第１実施形態］
本開示に係る決済システムの実施形態の一例である第１実施形態を説明する。

［１－１．決済システムの全体構成］
図１は、第１実施形態に係る決済システムの全体構成の一例を示す図である。決済システムＳは、図１の各構成を含む。ネットワークＮは、インターネット等の任意のネットワークである。決済システムＳは、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。

サーバ１０は、サーバコンピュータである。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、ハードディスク等の不揮発性メモリと、を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。

ユーザ端末２０は、ユーザのコンピュータである。例えば、ユーザ端末２０は、スマートフォン、タブレット端末、ウェアラブル端末、又はパーソナルコンピュータである。制御部２１、記憶部２２、及び通信部２３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様である。操作部２４は、タッチパネル等の入力デバイスである。表示部２５は、液晶ディスプレイ又は有機ＥＬディスプレイである。ＩＣチップ２６は、ＦｅｌｉＣａ（登録商標）、又は、非接触型規格におけるＴｙｐｅＡ若しくはＴｙｐｅＢといった任意の規格のチップである。

店舗端末３０は、店舗のコンピュータである。例えば、店舗端末３０は、ＰＯＳ端末、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。制御部３１、記憶部３２、通信部３３、操作部３４、及び表示部３５の物理的構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部２４、及び表示部２５と同様である。店舗端末３０には、コードリーダ、リーダライタ、又はカメラである読取装置３６が接続される。読取装置３６は、店舗端末３０の内部に含まれてもよい。店舗端末３０は、店舗ごとに配置される。１つの店舗に複数の店舗端末３０が配置されることもある。店舗は、任意の種類であってよく、例えば、家電量販店、ディスカウントストア、百貨店、コンビニエンスストア、スーパーマーケット、貴金属店、又はレストラン等であってよい。

管理者端末４０は、決済サービスの管理者のコンピュータである。例えば、管理者端末４０は、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。制御部４１、記憶部４２、通信部４３、操作部４４、及び表示部４５の物理的構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部２４、及び表示部２５と同様である。

なお、記憶部１２，２２，３２，４２の各々に記憶されるプログラム及びデータの少なくとも一方は、ネットワークＮを介して供給されてもよい。また、コンピュータ読み取り可能な情報記憶媒体に記憶されたプログラム及びデータの少なくとも一方が、情報記憶媒体を読み取るための読取部（例えば、光ディスクドライブ又はメモリカードスロット）、又は、外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）を介して供給されてもよい。

［１－２．第１実施形態の概要］
決済システムＳは、ユーザに、決済サービスを提供する。決済サービスは、電子決済を提供するサービスである。電子決済は、キャッシュレス決済と呼ばれることもある。決済サービスで利用可能な決済手段は、任意の種類であってよい。例えば、決済手段は、クレジットカード、デビットカード、電子マネー、電子キャッシュ、ポイント、銀行口座、ウォレット、仮想通貨、又はこれらの組み合わせであってもよい。バーコード又は二次元コード等のコードを利用した電子決済は、コード決済と呼ばれることがあるので、コードが決済手段に相当してもよい。決済手段は、支払手段又は充当手段ということもできる。

第１実施形態では、決済手段の一例として、ポイントを説明する。このため、ポイントと記載した箇所は、決済手段と読み替えることができる。ポイント自体は、公知の種々のポイントを利用可能である。例えば、ユーザは、商品の購入時、特定のサービスの利用時、又は特定のクレジットカードの利用時に、ポイントを獲得する。ユーザは、現金等の他の決済手段を利用した支払時に、ポイントを利用できる。ユーザは、ポイントだけで支払を完了してもよい。

第１実施形態では、現実の店舗における商品の購入時に、ユーザがポイントを利用する場合を例に挙げる。ポイントの利用方法自体も、公知の種々の方法を利用可能である。第１実施形態では、ポイントの利用方法の一例として、ユーザ端末２０にインストールされたアプリを利用する方法を説明する。例えば、ユーザがアプリから所定の利用登録を済ませると、ユーザＩＤ及びパスワードが発行される。ユーザは、アプリを起動し、操作部２４からユーザＩＤ及びパスワードを入力して決済サービスにログインする。

ユーザが決済サービスにログインすると、ポイントを利用するためのコードが表示部２５に表示される。ユーザは、店舗における商品の購入時に、店員にコードを提示する。店員が読取装置３６でコードを読み取ると、店舗端末３０とサーバ１０との間で、ポイントを利用するための処理が実行される。ポイントを利用した支払が完了すると、ユーザは、商品を受け取り退店する。以上のように、第１実施形態では、アプリから決済サービスにログインすると表示されるコードによって、ポイントを利用できる。

近年、悪意のある第三者が、フィッシング等によって、他人のユーザＩＤ及びパスワードを不正に入手することが問題になっている。第三者は、不正に入手した他人のユーザＩＤ及びパスワードで、決済サービスに不正にログインする可能性がある。この場合、第三者のユーザ端末２０の表示部２５には、他人のポイントを利用するためのコードが表示される。第三者は、他人になりすまして店員にコードを提示し、他人のポイントを不正に利用する可能性がある。

図２は、第三者が他人のポイントを不正に利用する様子の一例を示す図である。図２に示すように、第三者は、自身のユーザ端末２０の表示部２５に、他人のポイントを利用するためのコードＣを表示部２５に表示させる。店員は、ポイントの利用時に本人確認をしないことが多いので、第三者のなりすましに気付くことはできない。第三者は、店員にコードＣを提示し、ポイントを不正に利用して商品を購入する。例えば、第三者は、多くのポイントを保有する他人のユーザＩＤ及びパスワードを不正に入手した場合、不正に利用したポイントだけで、高額の商品を購入できる。

第三者は、複数のユーザのユーザＩＤ及びパスワードを不正に入手している場合、近隣の店舗を移動しながら、ポイントを不正に利用することがある。図２に示すように、第三者は、ユーザＸになりすまして店舗１でユーザＸのポイントを不正に利用した後に、ユーザＹになりすまして、近隣の店舗２でユーザＹのポイントを不正に利用する。更に、第三者は、ユーザＺになりすまして、近隣の店舗３でユーザＺのポイントを不正に利用する。その後も同様に、第三者は、近隣の店舗を移動しながら、他人になりすましてポイントを不正に利用する可能性がある。このようなポイントの不正利用を防止する必要がある。

この点、ある店舗でポイントが不正に利用された場合に、この店舗と、近隣の店舗と、の各々で、ポイントを一切利用できないように制限したとする。この場合、ポイントの不正利用は防止できるが、第三者だけではなく、正当なユーザもポイントを一切利用できなくなるので、利便性が低下する。不正が発生したユーザＩＤのポイントの利用を停止することも考えられるが、図２で説明したように、第三者は、種々のユーザＩＤのポイントを不正に利用する可能性があるので、ポイントの不正利用を十分に防止できない。そこで、第１実施形態の決済システムＳは、ポイントが不正に利用された店舗と、近隣の店舗と、の各々に、利用可能なポイントの上限を設定する。

図３は、第１実施形態の概要を示す図である。図３の例では、店舗１でポイントが不正に利用された場合を示す。管理者は、ユーザからの通報等によって、ポイントが不正に利用されたことを把握する。管理者は、管理者端末４０を操作し、店舗１と、店舗１の近隣店舗である店舗２－３等と、の各々に、上限として１０００ポイントを設定する。第１実施形態では、店舗１－３等で共通の上限が設定される場合を説明するが、店舗ごとに、上限の値が異なってもよい。近隣店舗ではない店舗１００等には、上限は設定されない。上限は、０よりも大きい値であればよく、任意の値であってよい。ポイントの利用単位が１ポイント単位なのであれば、上限は１以上の任意の値である。

店舗１－３等に設定された上限は、店舗１－３等を訪れた全てのユーザに適用される。第三者は、不正に利用したポイントだけで、高額の商品の支払を完了することが多いので、上限を設定することによって、第三者による不正利用を防止できる。正当なユーザは、支払金額の端数をポイントで利用することが多いので、上限を設定しても、利便性の低下を最低限に抑えることができる。第１実施形態の決済システムＳは、図３のような上限を設定することによって、利便性を維持しつつ、ポイントの不正利用を防止するようにしている。以降、第１実施形態の詳細を説明する。

［１－３．第１実施形態の決済システムで実現される機能］
図４は、第１実施形態の決済システムＳで実現される機能の一例を示す機能ブロック図である。第１実施形態では、図４の各機能が実現される。

［１－３－１．サーバで実現される機能］
データ記憶部１００は、記憶部１２を主として実現される。設定部１０１、受付部１０２、及び実行部１０３の各々は、制御部１１を主として実現される。

［データ記憶部］
データ記憶部１００は、決済サービスの提供に必要なデータを記憶する。例えば、データ記憶部１００は、ユーザデータベースＤＢ１と、店舗データベースＤＢ２と、を記憶する。

図５は、第１実施形態のユーザデータベースＤＢ１の一例を示す図である。図５に示すように、ユーザデータベースＤＢ１は、ユーザに関する情報が格納されたデータベースである。例えば、ユーザデータベースＤＢ１には、ユーザＩＤ、パスワード、ユーザの氏名、ユーザが保有するポイント、コードＩＤ、及び有効期限が格納される。あるユーザが利用登録を完了すると、ユーザデータベースＤＢ１に新たなレコードが作成され、このユーザのユーザＩＤ等の情報が格納される。

ユーザＩＤは、ユーザを識別可能なユーザ識別情報である。このため、ユーザＩＤと記載した箇所は、ユーザ識別情報と読み替えることができる。ユーザ識別情報は、任意の情報であってよく、例えば、メールアドレス又は電話番号等の他の情報が利用されてもよい。ユーザＩＤは、アカウントと呼ばれることもある。パスワードは、利用登録後に変更可能である。あるユーザがポイントを獲得すると、このユーザのユーザＩＤに関連付けられたポイントが増加する。あるユーザがポイントを利用すると、このユーザのユーザＩＤに関連付けられたポイントが減少する。ポイントは、有効期限が設定されてもよい。

コードＩＤは、コードＣに含まれる情報である。例えば、コードＩＤは、数値、文字、又はこれらの組み合わせで表現される。コードＩＤは、任意のタイミングで発行される。例えば、アプリの起動時、有効期限の経過時、又はユーザが再発行を指示した時に、コードＩＤが発行される。コードＩＤの発行方法自体は、任意の発行方法であってよい。コードＩＤは、有効期限内の他のコードＩＤと重複しないように発行される。例えば、コードＩＤは、ランダムに発行される。

第１実施形態では、ユーザＩＤごとにコードＩＤが発行される。このため、ユーザＩＤとコードＩＤは、１対１で対応する。コードＩＤは、ユーザを識別可能な情報なので、コードＩＤもユーザ識別情報の１つである。コードＩＤではなく、ユーザＩＤがコードＣに含まれてもよい。有効期限は、コードＩＤが発行された時点から所定時間（例えば、５分～数時間程度）だけ後の時点となる。有効期限の長さは、任意であってよい。有効期限が経過したコードＩＤは、無効になる。有効期限が経過したコードＩＤを含むコードＣでは、ポイントは利用できない。コードＩＤには、有効期限が設定されなくてもよい。

図６は、第１実施形態の店舗データベースＤＢ２の一例を示す図である。図６に示すように、店舗データベースＤＢ２は、店舗に関する情報が格納されたデータベースである。例えば、店舗データベースＤＢ２には、店舗ＩＤ、店舗名、店舗に配置された店舗端末３０の端末ＩＤ、店舗に設定された上限、及び上限の設定日時が格納される。店舗データベースＤＢ２は、管理者によって編集可能である。

店舗ＩＤは、店舗を識別可能な店舗識別情報である。このため、店舗ＩＤと記載した箇所は、店舗識別情報と読み替えることができる。店舗識別情報は、任意の情報であってよく、例えば、店舗名、メールアドレス、又は電話番号等の他の情報が利用されてもよい。端末ＩＤは、店舗端末３０を識別可能な端末識別情報である。このため、端末ＩＤと記載した箇所は、端末識別情報と読み替えることができる。端末識別情報は、任意の情報であってよく、例えば、端末名、ＩＰアドレス、個体識別情報、又はメールアドレス等の他の情報が利用されてもよい。

上限は、後述の設定部１０１により設定される。第１実施形態では、１回の支払で利用可能なポイントの上限額が上限に相当する場合を例に挙げるが、他の上限であってもよい。例えば、所定回数の支払で利用可能な総額の上限、所定期間の支払で利用可能な総額の上限、所定期間の支払で利用可能な回数の上限、又はこれらの組み合わせが上限に相当してもよい。設定日時は、上限が設定された日時である。上限には、有効期限が設定されてもよい。有効期限は、設定日時から所定時間（例えば、数時間～数週間程度）だけ後の時点となる。

［設定部］
設定部１０１は、ポイントが不正に利用された場合に、ポイントを利用可能な複数の店舗の中から選択された対象店舗で利用可能なポイントに関する上限を設定する。第１実施形態では、管理者が、ユーザの通報等に基づいて、ポイントが不正に利用されたか否かを判定する場合を説明する。決済システムＳは、管理者端末４０からの管理者の操作によって、ポイントが不正に利用されたことを特定する。後述の変形例のように、所定の不正検知方法に基づいて、ポイントが不正に利用されたことが自動的に検知されてもよい。

対象店舗は、上限の設定対象となる店舗である。対象店舗は、少なくとも１つの店舗であればよく、複数の対象店舗に上限が設定されてもよい。対象店舗は、ポイントが不正に利用された店舗である不正利用店舗であってもよいし、不正利用店舗ではなくてもよい。第１実施形態では、管理者が対象店舗を手動で指定する場合を説明するが、後述の変形例のように、対象店舗は、自動的に選択されてもよい。

第１実施形態では、他の決済手段を利用した支払に充当可能なポイントが決済手段に相当するので、上限は、ポイントの充当に関する上限である。他の決済手段は、任意の決済手段であってよく、現金であってもよいし、先述した電子的な決済手段であってもよい。例えば、他の決済手段は、支払における主たる決済手段である。充当とは、ポイントを利用することである。充当は、他の決済手段の支払との併用ということもできる。

例えば、管理者は、ポイントが不正に利用された場合に、管理者端末４０を操作して、対象店舗の店舗ＩＤと、上限と、を指定する。設定部１０１は、管理者端末４０から、管理者が指定した対象店舗の店舗ＩＤと、管理者が指定した上限と、を取得する。設定部１０１は、当該取得された店舗ＩＤ及び上限を関連付けて店舗データベースＤＢ２に格納することによって、対象店舗で利用可能なポイントの上限を設定する。管理者が複数の対象店舗の各々の店舗ＩＤを指定した場合には、設定部１０１は、個々の対象店舗の店舗ＩＤごとに、上限を設定する。設定部１０１は、上限を設定した時の現在日時を、設定日時として店舗データベースＤＢ２に格納する。なお、ポイントの上限は、予め定められた方法で設定されるようにすればよく、管理者が指定するのではなく、固定値であってもよい。例えば、店舗ごとにポイントの上限が予め指定されていてもよい。例えば、ポイントの不正利用の額に応じた上限が設定されてもよい。例えば、店舗の客単価やポイントの平均利用額に応じた額が上限として設定されてもよい。

［受付部］
受付部１０２は、対象店舗におけるポイントの利用に関する利用要求を受け付ける。利用要求は、ポイントを利用するための要求である。利用要求は、ポイントの充当に関する要求である。利用要求は、ポイントの利用そのものの要求であってもよいし、ポイントの利用に必要な前処理の要求であってもよい。例えば、利用要求は、ユーザが保有するポイントを減少させるための要求に限られず、利用可能なポイントの参照だけを要求するものであってもよい。

利用要求は、所定形式のデータが送信されることによって行われる。例えば、利用要求は、利用対象のポイントを識別可能なポイント識別情報を含む。第１実施形態では、ポイント識別情報がコードＩＤである場合を説明する。このため、コードＩＤと記載した箇所は、ポイント識別情報と読み替えることができる。ポイント識別情報は、コードＩＤに限られず、例えば、ユーザＩＤであってもよい。個々のポイントを識別可能なＩＤ又は番号が存在する場合には、このＩＤ又は番号がポイント識別情報に相当してもよい。

利用要求は、ポイント識別情報以外の他の情報を含んでもよく、例えば、利用要求を送信した店舗端末３０が配置された店舗の店舗ＩＤと、この店舗端末３０の端末ＩＤと、の少なくとも一方を含んでもよい。利用要求を受け付けるとは、利用要求に相当するデータを受信することである。第１実施形態では、受付部１０２は、店舗端末３０から、利用要求を受け付ける。受付部１０２は、ユーザ端末２０から利用要求を受け付けてもよいし、他の端末から利用要求を受け付けてもよい。

［実行部］
実行部１０３は、利用要求が受け付けられた場合に、ポイントを利用するための利用処理を実行可能である。利用処理は、ポイントを利用するための処理である。利用処理は、決済処理、支払処理、又は充当処理ということもできる。第１実施形態では、利用処理は、ポイントの充当に関する処理である。利用処理は、ポイントの利用そのものを行う処理であってもよいし、ポイントの利用に必要な前処理であってもよい。利用処理は、利用要求に応じて実行される処理であればよい。例えば、利用処理は、ユーザが保有するポイントを減少させる処理であってもよいし、利用可能なポイントを参照する処理であってもよい。

例えば、実行部１０３は、利用要求が受け付けられた場合に、上限に基づいて、利用処理を実行する。上限が適用されるのは、上限が設定された店舗におけるポイントの利用要求が受け付けられた場合であり、上限が設定されていない店舗におけるポイントの利用要求が受け付けられた場合には、上限は適用されない。実行部１０３は、上限の範囲内でポイントが利用されるように、利用処理を実行する。即ち、実行部１０３は、上限を超えないように、利用処理を実行する。上限を超えるような利用処理は実行されない。

第１実施形態では、利用可能なポイントを参照する処理が利用処理に相当する場合を例に挙げる。実行部１０３は、利用要求が受け付けられた場合に、ユーザデータベースＤＢ１を参照し、利用要求に含まれるコードＩＤに関連付けられた、ユーザが保有するポイントを取得する。実行部１０３は、利用要求に含まれる店舗ＩＤに上限が関連付けられている場合には、この上限の範囲内となるように、利用可能なポイントを決定する。

例えば、実行部１０３は、ユーザが保有するポイントが上限以上であれば、利用可能なポイントとして、上限を決定する。実行部１０３は、ユーザが保有するポイントが上限未満であれば、利用可能なポイントとして、ユーザが保有するポイントを決定する。実行部１０３は、店舗端末３０に利用可能なポイントを送信することによって、利用処理を実行する。店舗では、利用可能なポイントの範囲内でポイントが利用される。実行部１０３は、上限が設定されていない店舗であれば、ユーザが保有するポイントを、そのまま利用可能なポイントとして決定する。

なお、ユーザが保有するポイントを減少させる処理が利用処理に相当する場合には、実行部１０３は、上限の範囲内で、ユーザが保有するポイントを減少させるようにすればよい。この場合、利用要求には、ポイントの利用額も含まれるものとする。例えば、実行部１０３は、利用要求が受け付けられた場合に、利用要求に含まれるポイントの利用額を取得する。実行部１０３は、利用要求に含まれる店舗ＩＤに上限が関連付けられている場合には、この上限の範囲内でポイントが利用されるように、ポイントを減少させる。

例えば、実行部１０３は、ポイントの利用額が上限以上であれば、ポイントの利用を禁止する。実行部１０３は、店舗端末３０に、ポイントの利用が禁止されたことを送信する。店舗端末３０では、エラーメッセージ等が表示される。実行部１０３は、ポイントの利用額が上限以上の場合に、ポイントの利用を禁止するのではなく、上限の範囲内で、ポイントの利用を許可してもよい。この場合、実行部１０３は、ポイントの利用額が上限以下となるように変更したうえで、ポイントを減少させる。実行部１０３は、店舗端末３０に、ポイントの利用額が変更されることを通知し、店舗端末３０で所定の操作が行われた場合に、ポイントの利用額を変更してもよい。実行部１０３は、ポイントの利用額が上限未満であれば、そのままの利用額でポイントを減少させる。

［１－３－２．ユーザ端末で実現される機能］
データ記憶部２００は、記憶部２２を主として実現される。表示制御部２０１は、制御部２１を主として実現される。データ記憶部２００は、決済サービスの提供に必要なデータを記憶する。例えば、データ記憶部２００は、アプリ、コードＩＤ、及び有効期限を記憶する。表示制御部２０１は、アプリに基づいて、コードＩＤを含むコードＣを表示する。

［１－３－３．店舗端末で実現される機能］
データ記憶部３００は、記憶部３２を主として実現される。利用要求送信部３０１は、制御部３１を主として実現される。データ記憶部３００は、決済サービスの提供に必要なデータを記憶する。例えば、データ記憶部３００は、店舗端末３０が配置された店舗の店舗ＩＤと、店舗端末３０の端末ＩＤと、を記憶する。データ記憶部３００は、コードＣに含まれるコードＩＤを取得するプログラムも記憶する。

利用要求送信部３０１は、サーバ１０に、利用要求を送信する。例えば、読取装置３６がコードＣを読み取ると、利用要求送信部３０１は、コードＣに含まれるコードＩＤを取得する。利用要求送信部３０１は、サーバ１０に、店舗ＩＤ、端末ＩＤ、及びコードＩＤを含む利用要求を送信する。利用要求がポイントを減少させることの要求である場合には、利用要求には、ポイントの利用額が含まれる。

なお、コードＩＤは、光学的に取得されなくてもよく、通信によって取得されてもよい。例えば、店舗端末３０は、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、又は赤外線通信を利用してコードＩＤを取得してもよいし、公知のＩＣカードで採用されている近距離無線通信を利用してコードＩＤを取得してもよい。コードＩＤは、店舗端末３０の操作部３４から入力されてもよい。

［１－３－４．管理者端末で実現される機能］
データ記憶部４００は、記憶部４２を主として実現される。設定送信部４０１は、制御部４１を主として実現される。データ記憶部４００は、決済サービスの提供に必要なデータを記憶する。例えば、データ記憶部４００は、管理者が上限を設定するための管理ツールを記憶する。設定送信部４０１は、サーバ１０に、管理者が管理ツールから指定した設定内容を送信する。例えば、設定送信部４０１は、サーバ１０に、管理者により指定された対象店舗の店舗ＩＤと、管理者により指定された上限と、を送信する。

［１－４．第１実施形態の決済システムで実行される処理］
図７は、第１実施形態の決済システムＳで実行される処理の一例を示すフロー図である。図７に示す処理は、制御部１１，２１，３１，４１の各々が記憶部１２，２２，３２，４２の各々に記憶されたプログラムに従って動作することによって実行される。

図７に示すように、管理者端末４０は、ポイントが不正に利用された場合に、管理者による、対象店舗の店舗ＩＤ及び上限の指定を受け付ける（Ｓ１００）。管理者端末４０は、管理者により指定された対象店舗の店舗ＩＤ及び上限に基づいて、サーバ１０に、所定の設定要求を送信する（Ｓ１０１）。サーバ１０は、設定要求を受信すると（Ｓ１０２）、設定要求に基づいて、対象店舗に上限を設定する（Ｓ１０３）。Ｓ１０３では、サーバ１０は、設定要求に含まれる店舗ＩＤと、設定要求に含まれる上限と、が関連付けられるように、店舗データベースＤＢ２を更新する。Ｓ１００～Ｓ１０３により、上限の設定が完了する。

ユーザ端末２０は、ユーザの操作に基づいて、アプリを起動してコードＣを表示部２５に表示させる（Ｓ１０４）。アプリの起動時には、サーバ１０との間でログイン処理が実行されてもよい。ログイン処理では、ユーザＩＤ及びパスワードの入力が要求されてもよいし、ログイン済みのユーザ端末２０であれば、ログイン済みであることを示す情報をユーザ端末２０に記録しておき、この情報を利用して、ユーザＩＤ及びパスワードの入力を省略してもよい。

ユーザは、Ｓ１０４で表示させたコードＣを店員に提示する。店員は、読取装置３６でコードＣを読み取る。店舗端末３０は、読取装置３６の読取結果に基づいてコードＩＤを取得し、サーバ１０に、ポイントの利用要求を送信する（Ｓ１０５）。サーバ１０は、利用要求を受信すると（Ｓ１０６）、店舗データベースＤＢ２に基づいて、利用要求を送信した店舗端末３０が配置された店舗に上限が設定されているか否かを判定する（Ｓ１０７）。

上限が設定されていると判定された場合（Ｓ１０７；Ｙ）、サーバ１０は、上限に基づいて、利用処理を実行し（Ｓ１０８）、本処理は終了する。上限に基づく利用処理は、先述した通りである。上限が設定されていないと判定された場合（Ｓ１０７；Ｎ）、サーバ１０は、店舗端末３０との間で、上限に基づかずに、利用処理を実行し（Ｓ１０９）、本処理は終了する。上限に基づかない利用処理も、先述した通りである。

第１実施形態の決済システムＳによれば、ポイントが不正に利用された場合に、対象店舗で利用可能なポイントに関する上限を設定し、利用要求が受け付けられた場合に、上限に基づいて、利用処理を実行する。これにより、対象店舗であったとしても、上限の範囲内であればポイントを利用可能なので、一定程度の利便性を維持できる。また、上限を超える範囲のポイントの利用は制限されるので、ポイントの不正利用を防止できる。例えば、正当なユーザは、一度に大量にポイントを利用することは少なく、少額のポイントをこまめに利用することが多い。一方、悪意のある第三者は、一度に大量のポイントを利用することが多く、少額のポイントをこまめに利用することは少ない。このため、上限の設定により、正当なユーザの利用を妨げることなく、かつ、第三者による不正利用を防止できるので、利便性を維持しつつ、ポイントの不正利用を防止できる。

また、決済システムＳは、他の決済手段を利用した支払に充当可能なポイントが決済手段に相当し、ポイント利用時の利便性を維持しつつ、ポイントの不正利用を防止できる。

［２．第２実施形態］
次に、決済システムＳの第２実施形態を説明する。第１実施形態では、対象店舗に設定された上限が全てのユーザに適用される場合を説明した。対象店舗を訪れるユーザの中には、正当である確率が非常に高いユーザもいれば、悪意のある第三者なのか見分けがつかないユーザもいる。第２実施形態では、正当である確率が非常に高いユーザについては、対象店舗に設定された上限を適用しないようにする。即ち、悪意のある第三者なのか見分けがつかないユーザに対し、対象店舗に設定された上限が適用される。

例えば、悪意のある第三者は、不正に入手したユーザＩＤが示す他人の普段の行動を意識せずにポイントを不正に利用することが多い。このため、第三者がポイントを不正に利用としている店舗と、第三者がなりすましている他人（正当なユーザ）が普段から利用している店舗と、が同じである確率は極めて低い。第三者が何らかの形で他人が普段利用している店舗を特定したとしても、わざわざこの店舗まで移動して不正利用をすることは考えにくい。

そこで、第２実施形態では、ユーザが普段から利用している店舗であれば、正当なユーザによる利用である確率が高いので、この店舗が対象店舗だったとしても上限を適用しないようにする。これにより、正当である確率が非常に高いにもかかわらず、上限が適用されてしまうといった利便性の低下を防止する。逆に、ユーザが普段は利用していない店舗であれば、悪意のある第三者がなりすましているのか見分けがつきにくいので、この店舗が対象店舗だった場合には上限が適用される。これにより、ポイントの不正利用を防止する。以降、第２実施形態の詳細を説明する。なお、第１実施形態と同様の点は説明を省略する。

［２－１．第２実施形態の決済システムで実現される機能］
第２実施形態では、第１実施形態で説明した図４と同様の機能が実現される。ただし、一部の内容は、第１実施形態とは異なる。例えば、ユーザデータベースＤＢ１及び店舗データベースＤＢ２の内容は、第１実施形態とは異なる。

図８は、第２実施形態のユーザデータベースＤＢ１の一例を示す図である。図８に示すように、ユーザデータベースＤＢ１は、第１実施形態と概ね同様であるが、ユーザが普段利用する店舗の店舗ＩＤが格納される点で異なる。サーバ１０は、ユーザの利用履歴に基づいて、ユーザが普段利用する店舗を特定する。この利用履歴は、決済サービスにおける利用履歴であってもよいし、決済サービスと連携する他のサービス（例えば、電子マネー等の他の決済サービス等）における利用履歴であってもよい。

利用履歴には、ユーザが訪れた店舗の店舗ＩＤと、この店舗の利用日時と、が含まれる。利用履歴には、ポイントの利用額等の他の情報が含まれてもよい。第２実施形態では、利用履歴がユーザＩＤに関連付けられてユーザデータベースＤＢ１に格納されている場合を説明するが、利用履歴は、他のデータベースに格納されていてもよい。利用履歴は、ユーザの利用に応じて適宜更新される。

サーバ１０は、ユーザＩＤごとに、このユーザＩＤに関連付けられた利用履歴に基づいて、このユーザＩＤが示すユーザが普段利用する店舗を特定する。例えば、サーバ１０は、過去の全期間又は一部の期間（例えば、直近の数日～数ヶ月程度の期間）の利用履歴に含まれる店舗ＩＤを集計し、利用回数が閾値以上の店舗を、ユーザが普段利用する店舗として特定する。他にも例えば、サーバ１０は、利用回数が多い順に所定数の店舗を、ユーザが普段利用する店舗として特定してもよい。サーバ１０は、ユーザが普段利用する店舗の店舗ＩＤを、このユーザのユーザＩＤに関連付けてユーザデータベースＤＢ１に格納する。

なお、ユーザが普段利用する店舗の特定方法は、上記の例に限られない。例えば、ユーザ自身が普段利用する店舗を指定してもよい。この場合、ユーザデータベースＤＢ１には、ユーザが指定した店舗の店舗ＩＤが格納される。例えば、利用額が閾値以上の店舗のみが、ユーザが普段利用する店舗となってもよい。例えば、ユーザ端末２０のＧＰＳセンサを利用した位置情報に基づいて、ユーザが普段利用する店舗が特定されてもよい。他にも例えば、ユーザ端末２０と接続した通信基地局又はアクセスポイントに基づいて、ユーザが普段利用する店舗が特定されてもよい。ユーザＩＤに関連付けられた住所等によって、ユーザが普段利用する店舗が特定されてもよい。ユーザが普段利用する店舗は、予め定められた方法によって特定されるようにすればよい。

図９は、第２実施形態の店舗データベースＤＢ２の一例を示す図である。図９に示すように、店舗データベースＤＢ２は、第１実施形態と概ね同様であるが、設定部１０１の設定は、ポイントの上限ではなくてもよい。例えば、設定部１０１は、ポイントの利用自体を禁止するような設定をしてもよい。第２実施形態では、上限が設定されるとは限らないので、図９では、設定部１０１の設定内容を利用制限と記載する。図９の例では、対象店舗ごとに、異なる利用制限が設定されている場合を示している。例えば、店舗１には、１０００ポイントの上限が設定されている。店舗２には、ポイントの利用自体が禁止されている。店舗３には、５００ポイントの上限が設定されている。

設定部１０１は、ポイントが不正に利用された場合に、ポイントを利用可能な複数の店舗の中から選択された対象店舗におけるポイントの利用制限に関する設定を行う。設定内容が第１実施形態とは異なるだけであり、設定方法自体は、第１実施形態と同様である。即ち、管理者は、管理者端末４０から、対象店舗の店舗ＩＤと、利用制限の内容と、を指定する。利用制限として上限が設定される場合には、管理者は、上限の値を指定する。利用制限としてポイントの利用自体を禁止する設定が行われる場合には、管理者は、ポイントの利用自体を禁止することを指定する。設定部１０１は、管理者端末４０から管理者の指定内容を取得し、店舗データベースＤＢ２に格納する。

実行部１０３は、利用要求が受け付けられた場合に、利用処理を実行可能である。ただし、利用処理を実行するか否かは、利用制限の設定次第である。実行部１０３は、所定の条件に基づいて、設定部１０１の設定を適用するか否かを決定する。この条件は、利用制限の設定を適用するか否かの基準となる条件である。この条件が満たされた場合に、利用制限の設定が適用されてもよい。逆に、この条件が満たされなかった場合に、利用制限の設定が適用されてもよい。以降、この条件を、適用条件と記載する。

適用条件は、正当なユーザと、悪意のある第三者と、ある程度の確率で見分けられる条件であればよい。第２実施形態では、適用条件は、利用要求に対応するユーザが対象店舗を普段から利用しているか否かである場合を例に挙げる。他の適用条件の例は、後述の変形例で説明する。利用要求に対応するユーザとは、ポイントを利用しようとしているユーザＩＤが示すユーザである。ここでは、利用要求に含まれるコードＩＤによってユーザが特定されるので、コードＩＤに関連付けられたユーザＩＤが示すユーザは、利用要求に対応するユーザに相当する。

実行部１０３は、利用要求が受け付けられた場合に、ユーザデータベースＤＢ１を参照し、利用要求に含まれるコードＩＤに関連付けられた、普段利用する店舗の店舗ＩＤを取得する。実行部１０３は、利用要求に含まれる店舗ＩＤと、当該取得された普段利用する店舗の店舗ＩＤと、が一致する場合、設定部１０１の設定を適用しないと決定する。実行部１０３は、利用要求に含まれる店舗ＩＤと、当該取得された普段利用する店舗の店舗ＩＤと、が一致しない場合、設定部１０１の設定を適用すると決定する。

なお、設定部１０１の設定を適用しないとは、利用制限の設定に基づかずに利用処理を実行することである。設定部１０１の設定を適用するとは、利用制限の設定に基づいて、利用処理を実行することである。利用制限として、ポイントの利用禁止が設定されている場合には、利用処理は実行されない。

［２－２．第２実施形態の決済システムで実行される処理］
図１０は、第２実施形態の決済システムＳで実行される処理の一例を示すフロー図である。図１０に示す処理は、制御部１１，２１，３１，４１の各々が記憶部１２，２２，３２，４２の各々に記憶されたプログラムに従って動作することによって実行される。

図１０に示すように、Ｓ２００～Ｓ２０６の処理は、それぞれＳ１００～Ｓ１０６の処理と同様であるが、Ｓ２００で指定されるのは、上限に限られない点でＳ１００とは異なる。同様に、Ｓ２０３で設定されるのは、上限に限られない点でＳ１０３とは異なる。Ｓ２０６で利用要求が受け付けられた場合、サーバ１０は、店舗データベースＤＢ２に基づいて、利用要求を送信した店舗端末３０の店舗に利用制限が設定されているか否かを判定する（Ｓ２０７）。Ｓ２０７では、サーバ１０は、利用要求に含まれる店舗ＩＤに利用制限の設定が関連付けられているか否かを判定する。

利用制限が設定されていると判定された場合（Ｓ２０７；Ｙ）、サーバ１０は、ユーザデータベースＤＢ１に基づいて、利用要求を送信した店舗端末３０の店舗が、ユーザが普段利用する店舗であるか否かを判定する（Ｓ２０８）。ユーザが普段利用する店舗であると判定されない場合（Ｓ２０８；Ｎ）、サーバ１０は、店舗端末３０との間で、利用制限の設定に基づいて、利用処理を実行し（Ｓ２０９）、本処理は終了する。利用制限の設定に基づく利用処理は、先述した通りである。

ユーザが普段利用する店舗であると判定された場合（Ｓ２０８；Ｙ）、サーバ１０は、店舗端末３０との間で、利用制限の設定に基づかずに、利用処理を実行し（Ｓ２１０）、本処理は終了する。利用制限の設定に基づかない利用処理も、先述した通りである。利用制限が設定されていないと判定された場合（Ｓ２０７；Ｎ）も同様に、Ｓ２１０の処理が実行される。

第２実施形態の決済システムＳによれば、ポイントが不正に利用された場合に、対象店舗におけるポイントの利用制限に関する設定を行い、所定の条件に基づいて、設定を適用するか否かを決定する。これにより、対象店舗であったとしても、設定を適用しないと決定された場合には、ポイントの利用制限が課されないので、ユーザの利便性を維持できる。設定を適用すると決定された場合には、ポイントの利用制限が課されるので、ポイントの不正利用を防止できる。このため、利便性を維持しつつ、ポイントの不正利用を防止できる。第１実施形態では、ポイントの利用を禁止するのではなく上限を設定することによって利便性を維持したが、第２実施形態では、正当な確率が極めて高いユーザについては、利用制限の対象から除外することによって利便性を維持できるので、利用制限として、ポイントの利用を禁止する設定がなされてもよい。

また、決済システムＳは、適用条件が、利用要求に対応するユーザが対象店舗を普段から利用しているか否かである。例えば、正当なユーザは、特定の店舗でポイントを利用することが多い。一方、悪意のある第三者は、不正にログインした他人が普段利用しない店舗でポイントを不正利用することが多い。このため、ユーザが対象店舗を普段から利用しているか否かを条件にすることによって、利便性を確実に維持しつつ、ポイントの不正利用を防止できる。

また、決済システムＳは、他の決済手段を利用した支払に充当可能なポイントが決済手段に相当し、ポイント利用時の利便性を維持しつつ、ポイントの不正利用を防止できる。

［３．変形例］
なお、本開示は、以上に説明した実施の形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。

［３－１．第１実施形態に係る変形例］
まず、第１実施形態に係る変形例を説明する。図１１は、第１実施形態に係る変形例の機能ブロック図である。第２実施形態に係る変形例では、図１１の各機能が実現される。

［変形例１－１］
例えば、第１実施形態では、管理者が対象店舗を指定する場合を説明したが、対象店舗は、所定の条件に基づいて選択されてもよい。変形例１－１では、ポイントが不正に利用された不正利用店舗の近隣店舗が対象店舗として選択される場合を例に挙げる。変形例１－１の店舗データベースＤＢ２には、個々の店舗の位置に関する位置情報が格納されているものとする。位置情報は、任意の形式であってよく、例えば、緯度経度、住所、又は座標であってよい。

変形例１－１の決済システムＳは、第１選択部１０４を含む。第１選択部１０４は、ポイントが不正に利用された不正利用店舗の位置と、複数の店舗の各々の位置と、に基づいて、対象店舗を選択する。変形例１－１では、管理者が管理者端末４０から不正利用店舗を指定するものとする。例えば、管理者は、ユーザからの連絡を受けたり、ポイントの利用状況を確認したりすることによって、不正利用店舗を特定する。管理者は、管理者端末４０を操作して、不正利用店舗の店舗ＩＤを指定する。

なお、不正利用店舗は、決済システムＳで自動的に特定されてもよい。例えば、サーバ１０は、ある店舗におけるポイントの利用要求を受け付けた場合に、このポイントを保有するユーザの普段の利用中心地からの距離、普段の利用時間との時間差、普段の利用額との違い、普段購入する商品との違い、又はこれらの組み合わせに基づいて、ポイントの不正な利用であるか否かを判定してもよい。不正利用の判定は、任意のタイミングであってよく、例えば、ポイントの利用後であってもよい。

不正を検知する方法自体は、公知の種々の方法を利用可能である。例えば、クレジットカードの不正検知で利用されている方法を、ポイントの不正利用の判定に流用してもよい。例えば、サーバ１０は、機械学習を利用して過去に発生した不正利用の特徴を学習させた学習モデルを利用して、ポイントの不正な利用が発生したか否かを判定してもよい。例えば、サーバ１０は、過去に発生したポイントの不正利用の特徴に基づいて定義したルールを利用して、ポイントの不正な利用が発生したか否かを判定してもよい。

例えば、第１選択部１０４は、店舗データベースＤＢ２に格納された各店舗の位置情報に基づいて、不正利用店舗から所定距離以内の店舗を、対象店舗として選択する。第１選択部１０４は、不正利用店舗から近い順に所定数の店舗を、対象店舗として選択してもよい。対象店舗の数は、固定値であってもよいし、不正利用の利用額等に応じた可変値であってもよい。第１選択部１０４は、不正利用店舗と同じエリアの店舗を対象店舗として選択してもよい。対象店舗が選択された後の処理は、第１実施形態で説明した通りである。第１選択部１０４により選択された対象店舗が管理者に通知され、管理者は、対象店舗を確認したうえで、上限を指定してもよい。この点は、後述の第２選択部１０５又は第３選択部１０６により対象店舗が選択された場合も同様である。

変形例１－１によれば、不正利用店舗の位置と、複数の店舗の各々の位置と、に基づいて、対象店舗を選択することによって、ポイントが不正に利用される恐れのある対象店舗を自動的に選択できる。管理者が手動で対象店舗を指定する場合に比べて、ポイントの上限をより迅速に設定し、ポイントの不正利用を効果的に防止できる。管理者が手動で対象店舗を指定する必要もないので、管理者の手間も軽減できる。

［変形例１－２］
例えば、対象店舗は、不正利用店舗と同業種又は似た業種（業態）の店舗であってもよい。変形例１－２の店舗データベースＤＢ２には、個々の店舗の業種に関する業種情報が格納されているものとする。業種は、店舗で取り扱う商品のジャンル又はカテゴリに応じたものであればよい。業種は、店舗自身が指定してもよいし、管理者が指定してもよい。変形例１－２の決済システムＳは、第２選択部１０５を含む。

第２選択部１０５は、ポイントが不正に利用された不正利用店舗の業種と、複数の店舗の各々の業種と、に基づいて、対象店舗を選択する。例えば、第２選択部１０５は、店舗データベースＤＢ２に格納された各店舗の業種情報に基づいて、不正利用店舗と同業種又は似た業種の店舗を、対象店舗として選択する。類似する業種を定義した類似業種情報は、予めデータ記憶部１００に定義されているものとする。類似業種情報は、管理者が作成してもよいし、国税局等の公的機関が定義した類似業種に基づいて作成されてもよい。第２選択部１０５は、不正利用店舗と同業種又は似た業種の全ての店舗を、対象店舗として選択してもよいし、所定数の店舗だけを、対象店舗として選択してもよい。対象店舗が選択された後の処理は、第１実施形態で説明した通りである。

変形例１－２によれば、不正利用店舗の業種と、複数の店舗の各々の業種と、に基づいて、対象店舗を選択することによって、ポイントが不正に利用される恐れのある対象店舗を自動的に選択できる。管理者が手動で対象店舗を指定する場合に比べて、ポイントの上限をより迅速に設定し、ポイントの不正利用を効果的に防止できる。管理者が手動で対象店舗を指定する必要もないので、管理者の手間も軽減できる。

［変形例１－３］
例えば、対象店舗は、不正利用店舗と客単価が似た店舗であってもよい。変形例１－３の店舗データベースＤＢ２には、個々の店舗の客単価に関する客単価情報が格納されているものとする。客単価は、過去の全期間又は一部の期間における利用額から算出されるようにすればよい。客単価は、店舗自身が指定してもよいし、管理者が指定してもよい。変形例１－３の決済システムＳは、第３選択部１０６を含む。

第３選択部１０６は、ポイントが不正に利用された場合の利用額と、複数の店舗の各々に関連付けられた利用額と、に基づいて、対象店舗を選択する。変形例１－３では、利用額の一例として客単価を説明するが、利用額は、客単価に限られない。ポイントの平均的な利用額であってもよい。例えば、第３選択部１０６は、店舗データベースＤＢ２に格納された各店舗の客単価情報に基づいて、不正利用店舗と同程度の客単価の店舗を、対象店舗として選択する。

同程度の客単価の店舗とは、不正利用店舗の客単価との違いが閾値未満の店舗である。第３選択部１０６は、不正利用店舗と同程度の客単価の全ての店舗を、対象店舗として選択してもよいし、所定数の店舗だけを、対象店舗として選択してもよい。第３選択部１０６は、不正利用店舗の客単価との違いが小さい順に所定数の店舗を、対象店舗として選択してもよい。第３選択部１０６は、不正に利用されたポイント数と同程度の客単価の店舗を、対象店舗として選択してもよい。対象店舗が選択された後の処理は、第１実施形態で説明した通りである。

変形例１－３によれば、ポイントが不正に利用された場合の利用額と、複数の店舗の各々に関連付けられた利用額と、に基づいて、対象店舗を選択することによって、ポイントが不正に利用される恐れのある対象店舗を自動的に選択できる。管理者が手動で対象店舗を指定する場合に比べて、ポイントの上限をより迅速に設定し、ポイントの不正利用を効果的に防止できる。管理者が手動で対象店舗を指定する必要もないので、管理者の手間も軽減できる。

［変形例１－４］
例えば、第１実施形態のように、対象店舗における支払は、ポイントと、他の決済手段と、の併用が可能である場合に、上限は、対象店舗における支払の総額に対するポイントの割合であってもよい。総額をＸ（Ｘは自然数）円として、ポイントの利用額をＹ（ＹはＸ以下の自然数）円とすると、この割合は、Ｘ／Ｙの値である。上限は、第１実施形態と同様に管理者が指定してもよいし、過去の不正利用における割合から算出されてもよい。割合は、パーセンテージ等の任意の形式で表現可能である。

上限が割合を示す点で第１実施形態とは異なるだけであり、他の点は、第１実施形態で説明した通りである。ただし、変形例１－４では、利用要求に、支払の総額と、ポイントの利用額と、が含まれるものとする、ポイントの利用額は、支払の総額以下の任意の数値が店舗端末３０に入力される。実行部１０３は、利用要求に含まれる総額に対するポイントの利用額の割合を計算し、上限として設定された割合以上であるか否かを判定する。実行部１０３は、上限として設定された割合未満であれば、上限に基づかずに利用処理を実行する。実行部１０３は、上限として設定された割合以上であれば、上限に基づいて、利用処理を実行する。

変形例１－４によれば、対象店舗における支払の総額に対するポイントの割合を上限として設定することによって、利便性を効果的に維持しつつ、ポイントの不正利用を効果的に防止できる。例えば、正当なユーザは、支払の端数をポイントで充当するといったように、支払の総額に対して低い割合でポイントを利用することが多い。一方、第三者は、自分で一切の負担をしたくないため、１０割又はそれに近い割合でポイントを利用する。このため、上限としての割合は、７割～１０割程度の高い割合で設定しても、正当なユーザの利便性を損なわず、ポイントの不正利用を効果的に防止できる。

［変形例１－５］
例えば、第１実施形態では、全ての対象店舗の上限が同じである場合を説明したが、設定部１０１は、複数の対象店舗の各々に、当該対象店舗に応じた上限を設定してもよい。例えば、管理者が上限を指定する場合には、管理者は、個々の対象店舗ごとに上限を指定する。設定部１０１は、対象店舗ごとに、当該対象店舗に対して管理者が指定した上限を設定する。

決済システムＳで自動的に上限が設定される場合には、設定部１０１は、対象店舗ごとに、当該対象店舗に関する店舗情報に基づいて、当該対象店舗の上限を設定する。この店舗情報としては、任意の情報を利用可能である。例えば、設定部１０１は、対象店舗ごとに、当該対象店舗における過去の利用額の平均に基づいて、当該対象店舗の上限を設定してもよい。他にも例えば、設定部１０１は、対象店舗ごとに、当該対象店舗の業種、売上、利益、客数、客単価、ポイントの平均利用額、又はこれらの組み合わせに基づいて、当該対象店舗の上限を設定してもよい。

受付部１０２は、複数の対象店舗の各々から、利用要求を受け付け可能である。実行部１０３は、利用要求をした対象店舗に応じた上限に基づいて、利用処理を実行する。対象店舗に応じた上限が設定される点で第１実施形態とは異なるだけであり、他の点は、第１実施形態で説明した通りである。第２実施形態で説明した図９の店舗データベースＤＢ２も、対象店舗に応じた上限が設定された一例を示すものである。

変形例１－５によれば、複数の対象店舗の各々に、当該対象店舗に応じた上限を設定することによって、対象店舗に応じた最適な上限を設定し、利便性を効果的に維持しつつ、ポイントの不正利用も効果的に防止できる。

［変形例１－６］
例えば、実行部１０３は、利用要求に対応するユーザが対象店舗を普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定してもよい。利用要求に対応するユーザが対象店舗を普段から利用しているか否かを判定する方法は、第２実施形態で説明した通りである。実行部１０３は、利用要求に対応するユーザが対象店舗を普段から利用していると判定された場合に、上限には基づかずに、利用処理を実行すると決定する。実行部１０３は、利用要求に対応するユーザが対象店舗を普段は利用していないと判定された場合に、上限に基づいて、利用処理を実行すると決定する。

変形例１－６によれば、利用要求に対応するユーザが対象店舗を普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例１－７］
例えば、受付部１０２は、ユーザ端末２０にインストール可能な複数のアプリの各々を利用して、利用要求を受け付け可能であってもよい。変形例１－７では、コードＣを表示可能なアプリが複数存在するものとする。ユーザは、複数のアプリのうちの少なくとも１つをユーザ端末２０にインストールする。個々のアプリで表示されるコードＣは、異なってもよい。例えば、あるアプリでは、コードＣにコードＩＤが含まれており、他のアプリでは、コードＣにユーザＩＤが含まれてもよい。更に、個々のアプリで別々のコードＩＤが含まれてもよい。

個々のアプリは、ポイントを利用するためだけに開発されたものでなくてもよい。例えば、クレジットカードを利用するためのアプリ、銀行口座を利用するためのアプリ、オンラインショッピングモールを利用するためのアプリ、旅行予約をするためのアプリ、及びオークションを利用するためのアプリの各々で、共通のポイントを利用可能であってもよい。個々のアプリでポイントを利用する流れは、第１実施形態と同様であってもよいし、アプリごとに異なってもよい。アプリからポイントを利用する方法自体は、公知の種々の方法を利用可能である。

実行部１０３は、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定してもよい。利用要求に対応するアプリとは、利用要求をするために利用されたアプリである。ここでは、読取装置３６によって読み取られたコードＣを表示させたアプリは、利用要求に対応するアプリに相当する。

変形例１－７では、ユーザデータベースＤＢ１に、ユーザが普段利用するアプリに関するアプリ情報が格納されているものとする。過去におけるポイントの利用時にユーザが利用したアプリに基づいて、アプリ情報が示すアプリが決定される。例えば、サーバ１０は、過去に最も利用した回数の多いアプリを、ユーザが普段利用するアプリとして決定する。サーバ１０は、直近に利用したアプリを、ユーザが普段利用するアプリとして決定する。ユーザが、普段利用するアプリを自分で指定してもよい。

変形例１－７では、コードＣに、アプリを識別可能なアプリ識別情報が含まれているものとする。更に、利用要求には、コードＣから読み取られたアプリ識別情報が含まれる。実行部１０３は、利用要求に含まれるアプリ識別情報に基づいて、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用しているか否かを判定すればよい。実行部１０３は、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用していると判定された場合に、上限には基づかずに、利用処理を実行すると決定する。実行部１０３は、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用していないと判定された場合に、上限に基づいて、利用処理を実行すると決定する。例えば、利用要求に対応するアプリの利用が初めてである場合は、不正利用の可能性が高いことから、そのようなユーザについては、利用処理を実行しない。更に、利用要求に対応するアプリの利用が初めてであり、かつ、一定時間が経過しない場合に、不正利用の可能性が高いと推定し、そのようなユーザについては、利用処理を実行しないようにしてもよい。

変形例１－７によれば、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例１－８］
例えば、受付部１０２は、複数のユーザ端末２０の各々を利用して、利用要求を受け付け可能であってもよい。変形例１－８では、同じユーザＩＤだったとしても、複数のユーザ端末２０からログイン可能であり、複数のユーザ端末２０でコードＣを表示可能である。このため、あるユーザＩＤに関連付けられたポイントの利用要求は、複数のユーザ端末２０の各々に表示されたコードＣを利用して行うことができる。例えば、正当なユーザだったとしても、スマートフォンであるユーザ端末２０と、タブレット端末であるユーザ端末２０と、を利用し、両方のユーザ端末２０から自身のポイントを利用することがあるので、複数のユーザ端末２０の各々を利用した利用要求が可能である。

実行部１０３は、利用要求に対応するユーザが利用要求に対応するユーザ端末２０を普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定する。利用要求に対応するユーザ端末２０とは、利用要求をするために利用されたユーザ端末２０である。ここでは、読取装置３６によって読み取られたコードＣを表示させたユーザ端末２０は、利用要求に対応するユーザ端末２０に相当する。

変形例１－８では、ユーザデータベースＤＢ１に、ユーザが普段利用するユーザ端末２０を識別可能なユーザ端末情報が格納されているものとする。ユーザ端末２０は、任意の情報によって識別可能であり、例えば、ＩＰアドレス、ユーザ端末２０の個体識別情報、サーバ１０側で生成した端末ＩＤ、ＳＩＭカードに格納されたＩＤ、又はこれらの組み合わせであってもよい。

過去におけるポイントの利用時にユーザが利用したユーザ端末２０に基づいて、ユーザ端末情報が示すユーザ端末２０が決定される。例えば、サーバ１０は、過去に最も利用した回数の多いユーザ端末２０を、ユーザが普段利用するユーザ端末２０として決定する。サーバ１０は、直近に利用したユーザ端末２０を、ユーザが普段利用するユーザ端末２０として決定する。ユーザが、普段利用するユーザ端末２０を自分で指定してもよい。

変形例１－８では、コードＣに、ユーザ端末情報が含まれているものとする。更に、利用要求には、コードＣから読み取られたユーザ端末情報が含まれる。実行部１０３は、利用要求に含まれるユーザ端末情報に基づいて、利用要求に対応するユーザが利用要求に対応するユーザ端末２０を普段から利用しているか否かを判定すればよい。実行部１０３は、利用要求に対応するユーザが利用要求に対応するユーザ端末２０を普段から利用していると判定された場合に、上限には基づかずに、利用処理を実行すると決定する。実行部１０３は、利用要求に対応するユーザが利用要求に対応するユーザ端末２０を普段は利用していないと判定された場合に、上限に基づいて、利用処理を実行すると決定する。

変形例１－８によれば、利用要求に対応するユーザが利用要求に対応するユーザ端末２０を普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例１－９］
例えば、受付部１０２は、所定の認証を実行可能な複数のユーザ端末２０の各々を利用して、利用要求を受け付け可能であってもよい。この認証は、正当なユーザであることを一定程度保証できる認証であればよく、任意の認証であってよい。例えば、クレジットカード又は身分証明書等のＩＣチップをユーザ端末２０で読み取ることによって実行される所持認証、クレジットカード又は身分証明書等をユーザ端末２０のカメラで撮影することによって実行される所持認証、ユーザＩＤ及びパスワード以外の認証情報をユーザ端末２０に入力させることによって実行される知識認証、又はユーザ端末２０を利用して実行される指紋認証若しくは顔認証等の生体認証であってもよい。認証の実行方法自体は、公知の種々の方法を利用可能である。

変形例１－９では、ユーザデータベースＤＢ１に、ユーザのユーザ端末２０で所定の認証が実行されたか否かを識別可能な認証識別情報が格納されているものとする。この認証識別情報は、変形例１－８で説明したユーザ端末情報に関連付けられて格納される。サーバ１０は、あるユーザ端末２０で所定の認証が実行されると、このユーザ端末２０のユーザ端末情報に関連付けられた認証識別情報を更新する。

実行部１０３は、利用要求に対応するユーザ端末２０が所定の認証を実行済みであるか否かに基づいて、上限に基づく利用処理を実行するか否かを決定する。変形例１－９では、変形例１－８と同様に、コードＣにユーザ端末情報が含まれており、利用要求にユーザ端末情報が含まれるものとする。実行部１０３は、利用要求に含まれるユーザ端末情報に関連付けられた認証識別情報に基づいて、所定の認証を実行済みであるか否かを判定すればよい。

実行部１０３は、利用要求に対応するユーザ端末２０が所定の認証を実行済みであると判定された場合に、上限には基づかずに、利用処理を実行すると決定する。実行部１０３は、利用要求に対応するユーザ端末２０が所定の認証を実行済みではないと判定された場合に、上限に基づいて、利用処理を実行すると決定する。

変形例１－９によれば、利用要求に対応するユーザ端末２０が所定の認証を実行済みであるか否かに基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例１－１０］
例えば、実行部１０３は、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、に基づいて、上限に基づく利用処理を実行するか否かを決定してもよい。利用内容とは、ポイントの利用額、総額に対する利用額の割合、利用時間、利用店舗、購入する商品等である。変形例１－１０では、ユーザデータベースＤＢ１に、ユーザの普段の利用内容を識別可能な利用内容情報が格納されているものとする。例えば、過去におけるポイントの利用時にユーザが利用した利用内容に基づいて、利用内容情報が決定される。利用内容情報は、ポイントが利用されずに購入された商品に対応する利用内容を示してもよい。

変形例１－１０では、利用要求に利用内容が含まれるものとする。例えば、店舗端末３０は、店舗端末３０に入力された利用額、商品の総額に対する利用額の割合、利用時間、利用店舗、購入する商品等の利用内容を利用要求に含めてサーバ１０に送信する。実行部１０３は、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、が対応する場合に、上限には基づかずに、利用処理を実行すると決定する。実行部１０３は、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、が対応しない場合に、上限に基づいて、利用処理を実行すると決定する。

なお、利用内容が対応するとは、利用内容が一致又は類似することである。例えば、ポイントの利用額の違いが閾値未満であること、総額に対する利用額の割合の違いが閾値未満であること、利用時間の違いが所定時間未満であること、利用店舗が同じ又は近いこと、購入する商品が同じ又は同様のジャンルであることは、利用内容が対応することに相当する。これらの複数の要素が総合的に考慮されて、利用内容が対応するか否かが判定されてもよい。

変形例１－１０によれば、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、に基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例１－１１］
例えば、ポイントを利用可能な複数のユーザの各々には、当該ユーザの利用に応じたランクが設定されてもよい。この場合に、実行部１０３は、利用要求に対応するユーザのランクに基づいて、上限に基づく利用処理を実行するか否かを決定してもよい。なお、ランクごとに、ユーザが利用可能なポイントの上限が設定されていてもよい。設定部１０１により設定された上限が、ランクに応じた上限よりも多い場合には、ランクに応じた上限が適用される。

変形例１－１１では、ユーザデータベースＤＢ１に、ユーザのランクが格納されているものとする。例えば、過去におけるユーザの利用額が多いほど、ユーザのランクが高くなる。この利用額は、ポイントの利用額に限られず、他のサービスの利用額であってもよい。例えば、電子商取引サービスにおける購入額であってもよい。ランクは、利用額以外の他の条件が存在してもよい。例えば、利用回数であってもよいし、特定のクレジットカードを発行したり、特定の銀行口座を開設したりすることがランクの条件になってもよい。

例えば、低ランクのユーザは、保有するポイントが少ないことが予測されるので、悪意のある第三者に狙われにくい。このため、実行部１０３は、利用要求に対応するユーザのランクが所定ランク未満の場合に、上限には基づかずに、利用処理を実行すると決定する。一方、高ランクのユーザは、保有するポイントが多いことが予測されるので、悪意のある第三者に狙われやすい。このため、実行部１０３は、利用要求に対応するユーザのランクが所定ランク以上の場合に、上限に基づいて、利用処理を実行すると決定する。

変形例１－１１によれば、利用要求に対応するユーザのランクに基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例１－１２］
例えば、受付部１０２は、ユーザ端末２０に表示されたコードＣと、カード又はＩＣチップ２６と、の各々を利用して、利用要求を受け付け可能であってもよい。コードＣを利用して利用要求を受け付ける方法は、第１実施形態で説明した通りである。利用要求は、ポイントを識別可能なポイント識別情報が記憶されたカード又はＩＣチップ２６を利用して受け付けられてもよい。カードは、ＩＣカードに限られず、磁気カードであってもよい。ポイント識別情報は、ユーザデータベースＤＢ１に格納されているものとする。読取装置３６は、カード又はＩＣチップ２６に記憶されたポイント識別情報を読み取る。店舗端末３０は、当該読み取られたポイント識別情報を含む利用要求を送信する。

実行部１０３は、利用要求にコードＩＤが含まれる場合には、コードＣを利用して利用要求が受け付けられたと判定する。実行部１０３は、利用要求にポイント識別情報が含まれる場合には、カード又はＩＣチップ２６を利用して利用要求が受け付けられたと判定する。実行部１０３は、利用要求に含まれる情報に基づいて、コードＣで利用要求が受け付けられたか、カード又はＩＣチップ２６で利用要求が受け付けられたか、を判定すればよい。

例えば、カード又はＩＣチップ２６は、原則として第三者に盗まれにくいので、実行部１０３は、カード又はＩＣチップ２６を利用して利用要求が受け付けられた場合には、上限に基づかずに、利用処理を実行してもよい。コードＣは、ユーザＩＤ及びパスワードを入手すれば表示できてしまうので、実行部１０３は、コードＣを利用して利用要求が受け付けられた場合に、上限に基づいて、利用処理を実行してもよい。

変形例１－１２によれば、カード又はＩＣチップ２６を利用して利用要求が受け付けられた場合には、上限に基づかずに、利用処理を実行し、コードを利用して利用要求が受け付けられた場合に、上限に基づいて、利用処理を実行する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例１－１３］
例えば、受付部１０２は、所定のユーザＩＤでログインした状態のユーザ端末２０を利用して、利用要求を受け付け可能であってもよい。第１実施形態の例であれば、利用要求に必要なコードＣは、ユーザＩＤでログインした状態で表示されるので、受付部１０２は、ユーザＩＤでログインした状態のユーザ端末２０に表示されたコードＣを利用して、利用要求を受け付ける。

変形例１－１３では、ユーザデータベースＤＢ１に、個々のユーザＩＤでログインしたユーザ端末２０のユーザ端末情報が格納されているものとする。例えば、サーバ１０は、あるユーザＩＤで、あるユーザ端末２０からのログインが発生した場合に、このユーザＩＤと、このユーザ端末２０のユーザ端末情報と、を関連付ける。あるユーザＩＤで、複数のユーザ端末２０からログインが発生した場合には、１つのユーザＩＤに複数のユーザ端末情報が関連付けられる。あるユーザ端末２０で、複数のユーザＩＤでログインが発生した場合には、１つのユーザ端末情報に、複数のユーザＩＤが関連付けられる。

実行部１０３は、利用要求に対応するユーザ端末２０からログインされたことがあるユーザＩＤの数に基づいて、上限に基づく利用処理を実行するか否かを決定してもよい。例えば、正当なユーザは、多数のユーザＩＤでログインすることは考えにくいので、実行部１０３は、利用要求に対応するユーザ端末２０からログインされたことがあるユーザＩＤの数が閾値未満の場合に、上限には基づかずに、利用処理を実行すると決定する。一方、悪意のある第三者は、多数のユーザＩＤを不正に入手してログインすることがあるので、実行部１０３は、利用要求に対応するユーザ端末２０からログインされたことがあるユーザＩＤの数が閾値以上の場合に、上限に基づいて、利用処理を実行すると決定する。

変形例１－１３によれば、利用要求に対応するユーザ端末２０からログインされたことがあるユーザＩＤの数に基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例１－１４］
例えば、実行部１０３は、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、に基づいて、上限に基づく利用処理を実行するか否かを決定する。利用内容の意味は、変形例１－１０で説明した通りである。ポイントが不正に利用された場合の利用内容とは、不正に利用されたポイントで購入された場合の利用額、総額に対する利用額の割合、利用時間、利用店舗、購入された商品等である。

正当なユーザは、悪意のある第三者と利用内容が異なることが多いので、実行部１０３は、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、が対応しない場合に、上限には基づかずに、利用処理を実行すると決定する。悪意のある第三者は、同様の利用内容で連続してポイントを不正に利用することが多いので、実行部１０３は、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、が対応する場合に、上限に基づいて、利用処理を実行すると決定する。なお、利用内容が対応するといった言葉の意味は、変形例１－１０で説明した通りである。

変形例１－１４によれば、決済手段が不正に利用された場合の利用内容と、利用要求に対応する利用内容と、に基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例１－１５］
例えば、決済システムＳは、上限が設定された場合に、時間経過に応じて上限を徐々に解除する解除部１０７を含んでもよい。解除部１０７は、一定時間が経過するたびに、上限を段階的に解除する。解除とは、上限を増やすこと、又は、上限自体を無くすことである。上限を解除するための時間間隔は、固定であってもよいし、個々の時間間隔で異なってもよい。例えば、解除部１０７は、１０００ポイントの上限が設定された設定時間から３日経過した場合に、上限を２０００ポイントに増やす。解除部１０７は、更に３日経過した場合に、上限を３０００ポイントに増やす、といったように、上限を徐々に解除する。上限の増加量は、同じであってもよいし、異なってもよい。

変形例１－１５によれば、上限が設定された場合に、時間経過に応じて上限を徐々に解除することによって、利便性を効果的に維持しつつ、ポイントの不正利用を効果的に防止できる。

［変形例１－１６］
例えば、決済システムＳは、ユーザに、上限が設定された対象店舗に関する対象情報を通知する通知部１０８を含んでもよい。対象情報は、対象店舗を識別可能な情報である。例えば、対象情報は、対象店舗の店舗名、住所、電話番号、又はこれらの組み合わせである。通知部１０８は、任意の方法で対象情報を通知可能である。例えば、通知部１０８は、電子メール、ＳＮＳ、ＳＭＳ、メッセージアプリ、又はポイントのアプリ内の通知を利用して、対象情報を通知すればよい。対象情報の通知は、上限が設定された後の任意のタイミングであってよい。例えば、通知部１０８は、上限が設定されてすぐに対象情報を通知してもよいし、上限が設定されてから一定時間が経過した場合に対象情報を通知してもよい。

変形例１－１６によれば、ユーザに対象情報を通知することによって、ユーザは、事前にどの店舗でポイントの上限が設定されたのかを把握できるので、利便性が高まる。

［変形例１－１７］
例えば、第１実施形態では、対象店舗ごとに上限が設定される場合を説明したが、対象端末ごとに上限が設定されてもよい。対象端末は、上限が設定された店舗端末３０である。同じ店舗であったとしても、上限が設定される店舗端末３０と、上限が設定されない店舗端末３０と、が混在してもよい。他にも例えば、同じ店舗であったとしても、１０００ポイントの上限が設定される店舗端末３０と、５００ポイントの上限が設定される店舗端末３０と、が混在してもよい。対象端末は、管理者が管理者端末４０から指定してもよいし、下記のように自動的に選択されてもよい。

例えば、変形例１－１において、第１選択部１０４は、ポイントが不正に利用された不正利用端末の位置と、複数の店舗端末３０の各々の位置と、に基づいて、対象端末を選択してもよい。変形例１－２において、第２選択部１０５は、ポイントが不正に利用された不正利用端末の業種と、複数の店舗端末３０の各々の業種と、に基づいて、対象端末を選択してもよい。変形例１－３において、第３選択部１０６は、ポイントが不正に利用された場合の利用額と、複数の店舗端末３０の各々に関連付けられた利用額と、に基づいて、対象端末を選択してもよい。これらの処理は、変形例１－１～１－３で対象店舗と記載した箇所を、対象端末と読み替えればよい。

変形例１－４において、対象端末における支払は、ポイントと、他のポイントと、の併用が可能であり、上限は、対象端末における支払の総額に対するポイントの割合であってもよい。変形例１－５において、設定部１０１は、複数の対象端末の各々に、当該対象端末に応じた上限を設定してもよい。受付部１０２は、複数の対象端末の各々から、利用要求を受け付け可能であってもよい。実行部１０３は、利用要求をした対象端末に応じた上限に基づいて、利用処理を実行してもよい。変形例１－６において、実行部１０３は、利用要求に対応するユーザが対象端末を普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定してもよい。変形例１－１６において、通知部１０８は、ユーザに、上限が設定された対象端末に関する対象情報を通知してもよい。これらの処理は、変形例１－１～１－３で対象店舗と記載した箇所を、対象端末と読み替えればよい。

［３－２．第２実施形態に係る変形例］
次に、第２実施形態に係る変形例を説明する。図１２は、第２実施形態に係る変形例の機能ブロック図である。第２実施形態に係る変形例では、図１２の各機能が実現される。

［変形例２－１］
例えば、変形例１－７と同様に、第２実施形態の受付部１０２は、ユーザ端末２０にインストール可能な複数のアプリの各々を利用して、利用要求を受け付け可能であってもよい。更に、第２実施形態で説明した適用条件は、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用しているか否かであってもよい。この判定方法は、変形例１－７と同様であってよい。

実行部１０３は、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用していると判定された場合に、設定を適用しない。この場合、実行部１０３は、設定には基づかずに、利用処理を実行する。実行部１０３は、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用していないと判定された場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部１０３は、利用処理を実行しない。第１実施形態のような上限の設定であれば、実行部１０３は、上限に基づいて、利用処理を実行する。

変形例２－１によれば、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用しているか否かを適用条件にすることによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例２－２］
例えば、変形例１－８と同様に、第２実施形態の受付部１０２は、複数のユーザ端末２０の各々を利用して、利用要求を受け付け可能であってもよい。更に、第２実施形態で説明した適用条件は、利用要求に対応するユーザが利用要求に対応するユーザ端末２０を普段から利用しているか否かであってもよい。この判定方法は、変形例１－８と同様であってよい。

実行部１０３は、利用要求に対応するユーザが利用要求に対応するユーザ端末２０を普段から利用していると判定された場合に、設定を適用しない。この場合、実行部１０３は、設定には基づかずに、利用処理を実行する。実行部１０３は、利用要求に対応するユーザが利用要求に対応するユーザ端末２０を普段は利用していないと判定された場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部１０３は、利用処理を実行しない。第１実施形態のような上限の設定であれば、実行部１０３は、上限に基づいて、利用処理を実行する。

変形例２－２によれば、利用要求に対応するユーザが利用要求に対応するユーザ端末２０を普段から利用しているか否かを適用条件にすることによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例２－３］
例えば、変形例１－９と同様に、第２実施形態の受付部１０２は、所定の認証を実行可能な複数のユーザ端末２０の各々を利用して、利用要求を受け付け可能であってもよい。更に、第２実施形態で説明した適用条件は、利用要求に対応するユーザ端末２０が認証を実行済みであるか否かであってもよい。この判定方法は、変形例１－９と同様であってよい。

実行部１０３は、利用要求に対応するユーザ端末２０が所定の認証を実行済みであると判定された場合に、設定を適用しない。この場合、実行部１０３は、設定には基づかずに、利用処理を実行する。実行部１０３は、利用要求に対応するユーザ端末２０が所定の認証を実行済みであると判定されない場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部１０３は、利用処理を実行しない。第１実施形態のような上限の設定であれば、実行部１０３は、上限に基づいて、利用処理を実行する。

変形例２－３によれば、利用要求に対応するユーザ端末２０が認証を実行済みであるか否かを適用条件にすることによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例２－４］
例えば、変形例１－１０と同様に、第２実施形態で説明した適用条件は、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、が対応するか否かであってもよい。この判定方法は、変形例１－１０と同様であってよい。

実行部１０３は、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、が対応する場合に、設定を適用しない。この場合、実行部１０３は、設定には基づかずに、利用処理を実行する。実行部１０３は、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、が対応しない場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部１０３は、利用処理を実行しない。第１実施形態のような上限の設定であれば、実行部１０３は、上限に基づいて、利用処理を実行する。

変形例２－４によれば、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、が対応するか否かを適用条件にすることによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例２－５］
例えば、変形例１－１１と同様に、第２実施形態でも、ポイントを利用可能な複数のユーザの各々には、当該ユーザの利用に応じたランクが設定されてもよい。更に、第２実施形態で説明した適用条件は、利用要求に対応するユーザのランクに関する条件であってもよい。ランク等の説明は、変形例１－１１と同様であってよい。

実行部１０３は、利用要求に対応するユーザのランクが所定ランク未満の場合に、設定を適用しない。この場合、実行部１０３は、設定には基づかずに、利用処理を実行する。実行部１０３は、利用要求に対応するユーザのランクが所定ランク以上の場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部１０３は、利用処理を実行しない。第１実施形態のような上限の設定であれば、実行部１０３は、上限に基づいて、利用処理を実行する。

変形例２－５によれば、利用要求に対応するユーザのランクに関する適用条件を利用することによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例２－６］
例えば、変形例１－１２と同様に、第２実施形態の受付部１０２は、ユーザ端末２０に表示されたコードと、カード又はＩＣチップ２６と、の各々を利用して、利用要求を受け付け可能であってもよい。更に、第２実施形態で説明した適用条件は、コードを利用して利用要求が受け付けられたか、カード又はＩＣチップ２６を利用して利用要求が受け付けられたか、であってもよい。この判定方法は、変形例１－１２と同様であってよい。

実行部１０３は、カード又はＩＣチップ２６を利用して利用要求が受け付けられた場合には、設定を適用しない。この場合、実行部１０３は、設定には基づかずに、利用処理を実行する。実行部１０３は、コードＣを利用して利用要求が受け付けられた場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部１０３は、利用処理を実行しない。第１実施形態のような上限の設定であれば、実行部１０３は、上限に基づいて、利用処理を実行する。

変形例２－６によれば、コードＣを利用して利用要求が受け付けられたか、カード又はＩＣチップ２６を利用して利用要求が受け付けられたか、を適用条件とすることによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例２－７］
例えば、変形例１－１３と同様に、第２実施形態の受付部１０２は、所定のユーザＩＤでログインした状態のユーザ端末２０を利用して、利用要求を受け付け可能であってもよい。更に、第２実施形態で説明した適用条件は、利用要求に対応するユーザ端末２０がログインしたことがあるユーザＩＤの数に関する適用条件であってもよい。この数の特定方法は、変形例１－１３で説明した通りである。

実行部１０３は、利用要求に対応するユーザ端末２０からログインされたことがあるユーザＩＤの数が閾値未満の場合には、設定を適用しない。この場合、実行部１０３は、設定には基づかずに、利用処理を実行する。実行部１０３は、利用要求に対応するユーザ端末２０からログインされたことがあるユーザＩＤの数が閾値以上の場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部１０３は、利用処理を実行しない。第１実施形態のような上限の設定であれば、実行部１０３は、上限に基づいて、利用処理を実行する。

変形例２－７によれば、利用要求に対応するユーザ端末２０がログインしたことがあるユーザＩＤの数に関する適用条件を利用することによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例２－８］
例えば、変形例１－１４と同様に、第２実施形態で説明した適用条件は、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、が対応するか否かであってもよい。この判定方法は、変形例１－１４と同様であってよい。

実行部１０３は、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、が対応しない場合に、設定を適用しない。この場合、実行部１０３は、設定には基づかずに、利用処理を実行する。実行部１０３は、実行部１０３は、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、が対応する場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部１０３は、利用処理を実行しない。第１実施形態のような上限の設定であれば、実行部１０３は、上限に基づいて、利用処理を実行する。

変形例２－８によれば、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、が対応するか否かを適用条件とすることによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。

［変形例２－９］
例えば、変形例１－１５と同様に、第２実施形態の決済システムＳは、設定が行われた場合に、時間経過に応じて設定を徐々に解除する解除部１０７を含んでもよい。この解除方法は、変形例１－１５と同様であってよい。ポイントの利用自体を禁止する設定については、何らかの上限の設定に変更された後に、上限の額が徐々に増えるようにすればよい。

変形例２－９によれば、設定が行われた場合に、時間経過に応じて設定を徐々に解除することによって、利便性を効果的に維持しつつ、ポイントの不正利用を効果的に防止できる。

［変形例２－１０］
例えば、変形例１－１６と同様に、第２実施形態の決済システムＳは、ユーザに、設定が行われた対象店舗に関する対象情報を通知する通知部１０８を含んでもよい。通知の内容は、変形例１－１６で説明した通りである。

変形例２－１０によれば、ユーザに対象情報を通知することによって、ユーザは、事前にどの店舗でポイントの上限が設定されたのかを把握できるので、ユーザの利便性が高まる。

［変形例２－１１］
例えば、第２実施形態では、対象店舗ごとに利用制限が設定される場合を説明したが、変形例１－１７と同様に、対象端末ごとに利用制限が設定されてもよい。変形例１－１７の説明における上限を、利用制限に読み替えることができる。

［３－３．その他の変形例］
例えば、上記説明した変形例を組み合わせてもよい。

例えば、店舗は、現実の店舗に限られず、オンライン上の店舗であってもよい。決済システムＳは、オンライン上のある店舗でポイントが不正に利用された場合に、オンライン上の店舗を対象店舗として、ポイントの利用制限を設定してもよい。決済システムＳは、適用条件に基づいて、オンライン上の対象店舗に設定された利用制限を適用するか否かを決定してもよい。

例えば、対象端末は、店舗に配置される端末ではなく、自動販売機であってもよい。決済システムＳは、ある自動販売機でポイントが不正に利用された場合に、この自動販売機、又は、近くの自動販売機を対象端末として、ポイントの利用制限を設定してもよい。決済システムＳは、適用条件に基づいて、自動販売機に設定された利用制限を適用するか否かを決定してもよい。対象端末は、自動販売機ではなく、駅の自動改札機又はホテルのチェックイン機といった他の端末であってもよい。対象端末は、ポイント等の決済手段を何らか利用可能な端末であればよい。

例えば、決済手段は、ポイントに限られず、先述した任意の決済手段であってよい。例えば、決済システムＳは、クレジットカードが不正に利用された場合に、対象店舗又は対象端末に、クレジットカードの上限又は利用制限を設定してもよい。例えば、店舗端末３０又は読取装置３６にユーザ端末２０をかざすことによって決済が実行される態様に限られず、ユーザ端末２０の操作だけで決済が実行される場合にも、決済システムＳを適用可能である。この場合、ユーザ端末２０からサーバ１０に利用要求が送信される。例えば、主な機能がサーバ１０で実現される場合を説明したが、各機能は、複数のコンピュータで分担されてもよい。例えば、サーバ１０で実現されるものとして説明した機能は、ユーザ端末２０、店舗端末３０、又は管理者端末４０で実現されてもよい。サーバ１０に記憶されるものとして説明したデータは、データベースサーバ等の他のコンピュータに記憶されてもよい。

Ｓ 決済システム、Ｎ ネットワーク、１０ サーバ、１１，２１，３１，４１ 制御部、１２，２２，３２，４２ 記憶部、１３，２３，３３，４３ 通信部、２０ ユーザ端末、２４，３４，４４ 操作部、２５，３５，４５ 表示部、２６ ＩＣチップ、３０ 店舗端末、３６ 読取装置、４０ 管理者端末、１００ データ記憶部、１０１ 設定部、１０２ 受付部、１０３ 実行部、１０４ 第１選択部、１０５ 第２選択部、１０６ 第３選択部、１０７ 解除部、１０８ 通知部、２００ データ記憶部、２０１ 表示制御部、３００ データ記憶部、３０１ 利用要求送信部、４００ データ記憶部、４０１ 設定送信部、ＤＢ１ ユーザデータベース、ＤＢ２ 店舗データベース。

Claims (20)

1. 所定の決済手段が不正に利用された場合に、前記決済手段を利用可能な複数の店舗又は複数の端末の中から選択された対象店舗又は対象端末で利用可能な前記決済手段に関する上限を設定する設定手段と、
   前記対象店舗又は前記対象端末における前記決済手段の利用に関する利用要求を受け付ける受付手段と、
   前記利用要求が受け付けられた場合に、前記上限に基づいて、前記決済手段を利用するための利用処理を実行する実行手段と、
   を含む決済システム。
2. 前記決済システムは、前記決済手段が不正に利用された不正利用店舗又は不正利用端末の位置と、前記複数の店舗又は前記複数の端末の各々の位置と、に基づいて、前記対象店舗又は前記対象端末を選択する第１選択手段を更に含む、
   請求項１に記載の決済システム。
3. 前記決済システムは、前記決済手段が不正に利用された不正利用店舗又は不正利用端末の業種と、前記複数の店舗又は前記複数の端末の各々の業種と、に基づいて、前記対象店舗又は前記対象端末を選択する第２選択手段を更に含む、
   請求項１又は２に記載の決済システム。
4. 前記決済システムは、前記決済手段が不正に利用された場合の利用額と、前記複数の店舗又は前記複数の端末の各々に関連付けられた利用額と、に基づいて、前記対象店舗又は前記対象端末を選択する第３選択手段を更に含む、
   請求項１～３の何れかに記載の決済システム。
5. 前記対象店舗又は前記対象端末における支払は、前記決済手段と、他の決済手段と、の併用が可能であり、
   前記上限は、前記対象店舗又は前記対象端末における前記支払の総額に対する前記決済手段の割合である、
   請求項１～４の何れかに記載の決済システム。
6. 前記設定手段は、複数の前記対象店舗又は複数の前記対象端末の各々に、当該対象店舗又は当該対象端末に応じた前記上限を設定し、
   前記受付手段は、前記複数の前記対象店舗又は前記複数の対象端末の各々から、前記利用要求を受け付け可能であり、
   前記実行手段は、前記利用要求をした前記対象店舗又は前記対象端末に応じた前記上限に基づいて、前記利用処理を実行する、
   請求項１～５の何れかに記載の決済システム。
7. 前記実行手段は、前記利用要求に対応するユーザが前記対象店舗又は対象端末を普段から利用しているか否かに基づいて、前記上限に基づく前記利用処理を実行するか否かを決定する、
   請求項１～６の何れかに記載の決済システム。
8. 前記受付手段は、ユーザ端末にインストール可能な複数のアプリの各々を利用して、前記利用要求を受け付け可能であり、
   前記実行手段は、前記利用要求に対応するユーザが前記利用要求に対応するアプリを普段から利用しているか否かに基づいて、前記上限に基づく前記利用処理を実行するか否かを決定する、
   請求項１～７の何れかに記載の決済システム。
9. 前記受付手段は、複数のユーザ端末の各々を利用して、前記利用要求を受け付け可能であり、
   前記実行手段は、前記利用要求に対応するユーザが前記利用要求に対応するユーザ端末を普段から利用しているか否かに基づいて、前記上限に基づく前記利用処理を実行するか否かを決定する、
   請求項１～８の何れかに記載の決済システム。
10. 前記受付手段は、所定の認証を実行可能な複数のユーザ端末の各々を利用して、前記利用要求を受け付け可能であり、
    前記実行手段は、前記利用要求に対応するユーザ端末が前記認証を実行済みであるか否かに基づいて、前記上限に基づく前記利用処理を実行するか否かを決定する、
    請求項１～９の何れかに記載の決済システム。
11. 前記実行手段は、前記利用要求に対応する利用内容と、前記利用要求に対応するユーザの普段の利用内容と、に基づいて、前記上限に基づく前記利用処理を実行するか否かを決定する、
    請求項１～１０の何れかに記載の決済システム。
12. 前記決済手段を利用可能な複数のユーザの各々には、当該ユーザの利用に応じたランクが設定され、
    前記実行手段は、前記利用要求に対応するユーザの前記ランクに基づいて、前記上限に基づく前記利用処理を実行するか否かを決定する、
    請求項１～１１の何れかに記載の決済システム。
13. 前記受付手段は、ユーザ端末に表示されたコードと、カード又はＩＣチップと、の各々を利用して、前記利用要求を受け付け可能であり、
    前記実行手段は、前記カード又は前記ＩＣチップを利用して前記利用要求が受け付けられた場合には、前記上限に基づかずに、前記利用処理を実行し、前記コードを利用して前記利用要求が受け付けられた場合に、前記上限に基づいて、前記利用処理を実行する、
    請求項１～１２の何れかに記載の決済システム。
14. 前記受付手段は、所定のユーザ識別情報でログインした状態のユーザ端末を利用して、前記利用要求を受け付け可能であり、
    前記実行手段は、前記利用要求に対応するユーザ端末からログインされたことがある前記ユーザ識別情報の数に基づいて、前記上限に基づく前記利用処理を実行するか否かを決定する、
    請求項１～１３の何れかに記載の決済システム。
15. 前記実行手段は、前記決済手段が不正に利用された場合の利用内容と、前記利用要求に対応する利用内容と、に基づいて、前記上限に基づく前記利用処理を実行するか否かを決定する、
    請求項１～１４の何れかに記載の決済システム。
16. 前記決済システムは、前記上限が設定された場合に、時間経過に応じて前記上限を徐々に解除する解除手段を更に含む、
    請求項１～１５の何れかに記載の決済システム。
17. 前記決済システムは、ユーザに、前記上限が設定された前記対象店舗又は前記対象端末に関する対象情報を通知する通知手段を更に含む、
    請求項１～１６の何れかに記載の決済システム。
18. 前記決済手段は、他の決済手段を利用した支払に充当可能なポイントであり、
    前記上限は、前記ポイントの充当に関する上限であり、
    前記利用要求は、前記ポイントの充当に関する要求であり、
    前記利用処理は、前記ポイントの充当に関する処理である、
    請求項１～１７の何れかに記載の決済システム。
19. 所定の決済手段が不正に利用された場合に、前記決済手段を利用可能な複数の店舗又は複数の端末の中から選択された対象店舗又は対象端末で利用可能な前記決済手段に関する上限を設定する設定ステップと、
    前記対象店舗又は前記対象端末における前記決済手段の利用に関する利用要求を受け付ける受付ステップと、
    前記利用要求が受け付けられた場合に、前記上限に基づいて、前記決済手段を利用するための利用処理を実行する実行ステップと、
    を含む決済方法。
20. 所定の決済手段が不正に利用された場合に、前記決済手段を利用可能な複数の店舗又は複数の端末の中から選択された対象店舗又は対象端末で利用可能な前記決済手段に関する上限を設定する設定手段、
    前記対象店舗又は前記対象端末における前記決済手段の利用に関する利用要求を受け付ける受付手段、
    前記利用要求が受け付けられた場合に、前記上限に基づいて、前記決済手段を利用するための利用処理を実行する実行手段、
    としてコンピュータを機能させるためのプログラム。

Images