[1.第1実施形態]
本開示に係る決済システムの実施形態の一例である第1実施形態を説明する。
[1-1.決済システムの全体構成]
図1は、第1実施形態に係る決済システムの全体構成の一例を示す図である。決済システムSは、図1の各構成を含む。ネットワークNは、インターネット等の任意のネットワークである。決済システムSは、少なくとも1つのコンピュータを含めばよく、図1の例に限られない。
サーバ10は、サーバコンピュータである。制御部11は、少なくとも1つのプロセッサを含む。記憶部12は、RAM等の揮発性メモリと、ハードディスク等の不揮発性メモリと、を含む。通信部13は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。
ユーザ端末20は、ユーザのコンピュータである。例えば、ユーザ端末20は、スマートフォン、タブレット端末、ウェアラブル端末、又はパーソナルコンピュータである。制御部21、記憶部22、及び通信部23の物理的構成は、それぞれ制御部11、記憶部12、及び通信部13と同様である。操作部24は、タッチパネル等の入力デバイスである。表示部25は、液晶ディスプレイ又は有機ELディスプレイである。ICチップ26は、FeliCa(登録商標)、又は、非接触型規格におけるTypeA若しくはTypeBといった任意の規格のチップである。
店舗端末30は、店舗のコンピュータである。例えば、店舗端末30は、POS端末、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。制御部31、記憶部32、通信部33、操作部34、及び表示部35の物理的構成は、それぞれ制御部11、記憶部12、通信部13、操作部24、及び表示部25と同様である。店舗端末30には、コードリーダ、リーダライタ、又はカメラである読取装置36が接続される。読取装置36は、店舗端末30の内部に含まれてもよい。店舗端末30は、店舗ごとに配置される。1つの店舗に複数の店舗端末30が配置されることもある。店舗は、任意の種類であってよく、例えば、家電量販店、ディスカウントストア、百貨店、コンビニエンスストア、スーパーマーケット、貴金属店、又はレストラン等であってよい。
管理者端末40は、決済サービスの管理者のコンピュータである。例えば、管理者端末40は、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。制御部41、記憶部42、通信部43、操作部44、及び表示部45の物理的構成は、それぞれ制御部11、記憶部12、通信部13、操作部24、及び表示部25と同様である。
なお、記憶部12,22,32,42の各々に記憶されるプログラム及びデータの少なくとも一方は、ネットワークNを介して供給されてもよい。また、コンピュータ読み取り可能な情報記憶媒体に記憶されたプログラム及びデータの少なくとも一方が、情報記憶媒体を読み取るための読取部(例えば、光ディスクドライブ又はメモリカードスロット)、又は、外部機器とデータの入出力をするための入出力部(例えば、USBポート)を介して供給されてもよい。
[1-2.第1実施形態の概要]
決済システムSは、ユーザに、決済サービスを提供する。決済サービスは、電子決済を提供するサービスである。電子決済は、キャッシュレス決済と呼ばれることもある。決済サービスで利用可能な決済手段は、任意の種類であってよい。例えば、決済手段は、クレジットカード、デビットカード、電子マネー、電子キャッシュ、ポイント、銀行口座、ウォレット、仮想通貨、又はこれらの組み合わせであってもよい。バーコード又は二次元コード等のコードを利用した電子決済は、コード決済と呼ばれることがあるので、コードが決済手段に相当してもよい。決済手段は、支払手段又は充当手段ということもできる。
第1実施形態では、決済手段の一例として、ポイントを説明する。このため、ポイントと記載した箇所は、決済手段と読み替えることができる。ポイント自体は、公知の種々のポイントを利用可能である。例えば、ユーザは、商品の購入時、特定のサービスの利用時、又は特定のクレジットカードの利用時に、ポイントを獲得する。ユーザは、現金等の他の決済手段を利用した支払時に、ポイントを利用できる。ユーザは、ポイントだけで支払を完了してもよい。
第1実施形態では、現実の店舗における商品の購入時に、ユーザがポイントを利用する場合を例に挙げる。ポイントの利用方法自体も、公知の種々の方法を利用可能である。第1実施形態では、ポイントの利用方法の一例として、ユーザ端末20にインストールされたアプリを利用する方法を説明する。例えば、ユーザがアプリから所定の利用登録を済ませると、ユーザID及びパスワードが発行される。ユーザは、アプリを起動し、操作部24からユーザID及びパスワードを入力して決済サービスにログインする。
ユーザが決済サービスにログインすると、ポイントを利用するためのコードが表示部25に表示される。ユーザは、店舗における商品の購入時に、店員にコードを提示する。店員が読取装置36でコードを読み取ると、店舗端末30とサーバ10との間で、ポイントを利用するための処理が実行される。ポイントを利用した支払が完了すると、ユーザは、商品を受け取り退店する。以上のように、第1実施形態では、アプリから決済サービスにログインすると表示されるコードによって、ポイントを利用できる。
近年、悪意のある第三者が、フィッシング等によって、他人のユーザID及びパスワードを不正に入手することが問題になっている。第三者は、不正に入手した他人のユーザID及びパスワードで、決済サービスに不正にログインする可能性がある。この場合、第三者のユーザ端末20の表示部25には、他人のポイントを利用するためのコードが表示される。第三者は、他人になりすまして店員にコードを提示し、他人のポイントを不正に利用する可能性がある。
図2は、第三者が他人のポイントを不正に利用する様子の一例を示す図である。図2に示すように、第三者は、自身のユーザ端末20の表示部25に、他人のポイントを利用するためのコードCを表示部25に表示させる。店員は、ポイントの利用時に本人確認をしないことが多いので、第三者のなりすましに気付くことはできない。第三者は、店員にコードCを提示し、ポイントを不正に利用して商品を購入する。例えば、第三者は、多くのポイントを保有する他人のユーザID及びパスワードを不正に入手した場合、不正に利用したポイントだけで、高額の商品を購入できる。
第三者は、複数のユーザのユーザID及びパスワードを不正に入手している場合、近隣の店舗を移動しながら、ポイントを不正に利用することがある。図2に示すように、第三者は、ユーザXになりすまして店舗1でユーザXのポイントを不正に利用した後に、ユーザYになりすまして、近隣の店舗2でユーザYのポイントを不正に利用する。更に、第三者は、ユーザZになりすまして、近隣の店舗3でユーザZのポイントを不正に利用する。その後も同様に、第三者は、近隣の店舗を移動しながら、他人になりすましてポイントを不正に利用する可能性がある。このようなポイントの不正利用を防止する必要がある。
この点、ある店舗でポイントが不正に利用された場合に、この店舗と、近隣の店舗と、の各々で、ポイントを一切利用できないように制限したとする。この場合、ポイントの不正利用は防止できるが、第三者だけではなく、正当なユーザもポイントを一切利用できなくなるので、利便性が低下する。不正が発生したユーザIDのポイントの利用を停止することも考えられるが、図2で説明したように、第三者は、種々のユーザIDのポイントを不正に利用する可能性があるので、ポイントの不正利用を十分に防止できない。そこで、第1実施形態の決済システムSは、ポイントが不正に利用された店舗と、近隣の店舗と、の各々に、利用可能なポイントの上限を設定する。
図3は、第1実施形態の概要を示す図である。図3の例では、店舗1でポイントが不正に利用された場合を示す。管理者は、ユーザからの通報等によって、ポイントが不正に利用されたことを把握する。管理者は、管理者端末40を操作し、店舗1と、店舗1の近隣店舗である店舗2-3等と、の各々に、上限として1000ポイントを設定する。第1実施形態では、店舗1-3等で共通の上限が設定される場合を説明するが、店舗ごとに、上限の値が異なってもよい。近隣店舗ではない店舗100等には、上限は設定されない。上限は、0よりも大きい値であればよく、任意の値であってよい。ポイントの利用単位が1ポイント単位なのであれば、上限は1以上の任意の値である。
店舗1-3等に設定された上限は、店舗1-3等を訪れた全てのユーザに適用される。第三者は、不正に利用したポイントだけで、高額の商品の支払を完了することが多いので、上限を設定することによって、第三者による不正利用を防止できる。正当なユーザは、支払金額の端数をポイントで利用することが多いので、上限を設定しても、利便性の低下を最低限に抑えることができる。第1実施形態の決済システムSは、図3のような上限を設定することによって、利便性を維持しつつ、ポイントの不正利用を防止するようにしている。以降、第1実施形態の詳細を説明する。
[1-3.第1実施形態の決済システムで実現される機能]
図4は、第1実施形態の決済システムSで実現される機能の一例を示す機能ブロック図である。第1実施形態では、図4の各機能が実現される。
[1-3-1.サーバで実現される機能]
データ記憶部100は、記憶部12を主として実現される。設定部101、受付部102、及び実行部103の各々は、制御部11を主として実現される。
[データ記憶部]
データ記憶部100は、決済サービスの提供に必要なデータを記憶する。例えば、データ記憶部100は、ユーザデータベースDB1と、店舗データベースDB2と、を記憶する。
図5は、第1実施形態のユーザデータベースDB1の一例を示す図である。図5に示すように、ユーザデータベースDB1は、ユーザに関する情報が格納されたデータベースである。例えば、ユーザデータベースDB1には、ユーザID、パスワード、ユーザの氏名、ユーザが保有するポイント、コードID、及び有効期限が格納される。あるユーザが利用登録を完了すると、ユーザデータベースDB1に新たなレコードが作成され、このユーザのユーザID等の情報が格納される。
ユーザIDは、ユーザを識別可能なユーザ識別情報である。このため、ユーザIDと記載した箇所は、ユーザ識別情報と読み替えることができる。ユーザ識別情報は、任意の情報であってよく、例えば、メールアドレス又は電話番号等の他の情報が利用されてもよい。ユーザIDは、アカウントと呼ばれることもある。パスワードは、利用登録後に変更可能である。あるユーザがポイントを獲得すると、このユーザのユーザIDに関連付けられたポイントが増加する。あるユーザがポイントを利用すると、このユーザのユーザIDに関連付けられたポイントが減少する。ポイントは、有効期限が設定されてもよい。
コードIDは、コードCに含まれる情報である。例えば、コードIDは、数値、文字、又はこれらの組み合わせで表現される。コードIDは、任意のタイミングで発行される。例えば、アプリの起動時、有効期限の経過時、又はユーザが再発行を指示した時に、コードIDが発行される。コードIDの発行方法自体は、任意の発行方法であってよい。コードIDは、有効期限内の他のコードIDと重複しないように発行される。例えば、コードIDは、ランダムに発行される。
第1実施形態では、ユーザIDごとにコードIDが発行される。このため、ユーザIDとコードIDは、1対1で対応する。コードIDは、ユーザを識別可能な情報なので、コードIDもユーザ識別情報の1つである。コードIDではなく、ユーザIDがコードCに含まれてもよい。有効期限は、コードIDが発行された時点から所定時間(例えば、5分~数時間程度)だけ後の時点となる。有効期限の長さは、任意であってよい。有効期限が経過したコードIDは、無効になる。有効期限が経過したコードIDを含むコードCでは、ポイントは利用できない。コードIDには、有効期限が設定されなくてもよい。
図6は、第1実施形態の店舗データベースDB2の一例を示す図である。図6に示すように、店舗データベースDB2は、店舗に関する情報が格納されたデータベースである。例えば、店舗データベースDB2には、店舗ID、店舗名、店舗に配置された店舗端末30の端末ID、店舗に設定された上限、及び上限の設定日時が格納される。店舗データベースDB2は、管理者によって編集可能である。
店舗IDは、店舗を識別可能な店舗識別情報である。このため、店舗IDと記載した箇所は、店舗識別情報と読み替えることができる。店舗識別情報は、任意の情報であってよく、例えば、店舗名、メールアドレス、又は電話番号等の他の情報が利用されてもよい。端末IDは、店舗端末30を識別可能な端末識別情報である。このため、端末IDと記載した箇所は、端末識別情報と読み替えることができる。端末識別情報は、任意の情報であってよく、例えば、端末名、IPアドレス、個体識別情報、又はメールアドレス等の他の情報が利用されてもよい。
上限は、後述の設定部101により設定される。第1実施形態では、1回の支払で利用可能なポイントの上限額が上限に相当する場合を例に挙げるが、他の上限であってもよい。例えば、所定回数の支払で利用可能な総額の上限、所定期間の支払で利用可能な総額の上限、所定期間の支払で利用可能な回数の上限、又はこれらの組み合わせが上限に相当してもよい。設定日時は、上限が設定された日時である。上限には、有効期限が設定されてもよい。有効期限は、設定日時から所定時間(例えば、数時間~数週間程度)だけ後の時点となる。
[設定部]
設定部101は、ポイントが不正に利用された場合に、ポイントを利用可能な複数の店舗の中から選択された対象店舗で利用可能なポイントに関する上限を設定する。第1実施形態では、管理者が、ユーザの通報等に基づいて、ポイントが不正に利用されたか否かを判定する場合を説明する。決済システムSは、管理者端末40からの管理者の操作によって、ポイントが不正に利用されたことを特定する。後述の変形例のように、所定の不正検知方法に基づいて、ポイントが不正に利用されたことが自動的に検知されてもよい。
対象店舗は、上限の設定対象となる店舗である。対象店舗は、少なくとも1つの店舗であればよく、複数の対象店舗に上限が設定されてもよい。対象店舗は、ポイントが不正に利用された店舗である不正利用店舗であってもよいし、不正利用店舗ではなくてもよい。第1実施形態では、管理者が対象店舗を手動で指定する場合を説明するが、後述の変形例のように、対象店舗は、自動的に選択されてもよい。
第1実施形態では、他の決済手段を利用した支払に充当可能なポイントが決済手段に相当するので、上限は、ポイントの充当に関する上限である。他の決済手段は、任意の決済手段であってよく、現金であってもよいし、先述した電子的な決済手段であってもよい。例えば、他の決済手段は、支払における主たる決済手段である。充当とは、ポイントを利用することである。充当は、他の決済手段の支払との併用ということもできる。
例えば、管理者は、ポイントが不正に利用された場合に、管理者端末40を操作して、対象店舗の店舗IDと、上限と、を指定する。設定部101は、管理者端末40から、管理者が指定した対象店舗の店舗IDと、管理者が指定した上限と、を取得する。設定部101は、当該取得された店舗ID及び上限を関連付けて店舗データベースDB2に格納することによって、対象店舗で利用可能なポイントの上限を設定する。管理者が複数の対象店舗の各々の店舗IDを指定した場合には、設定部101は、個々の対象店舗の店舗IDごとに、上限を設定する。設定部101は、上限を設定した時の現在日時を、設定日時として店舗データベースDB2に格納する。なお、ポイントの上限は、予め定められた方法で設定されるようにすればよく、管理者が指定するのではなく、固定値であってもよい。例えば、店舗ごとにポイントの上限が予め指定されていてもよい。例えば、ポイントの不正利用の額に応じた上限が設定されてもよい。例えば、店舗の客単価やポイントの平均利用額に応じた額が上限として設定されてもよい。
[受付部]
受付部102は、対象店舗におけるポイントの利用に関する利用要求を受け付ける。利用要求は、ポイントを利用するための要求である。利用要求は、ポイントの充当に関する要求である。利用要求は、ポイントの利用そのものの要求であってもよいし、ポイントの利用に必要な前処理の要求であってもよい。例えば、利用要求は、ユーザが保有するポイントを減少させるための要求に限られず、利用可能なポイントの参照だけを要求するものであってもよい。
利用要求は、所定形式のデータが送信されることによって行われる。例えば、利用要求は、利用対象のポイントを識別可能なポイント識別情報を含む。第1実施形態では、ポイント識別情報がコードIDである場合を説明する。このため、コードIDと記載した箇所は、ポイント識別情報と読み替えることができる。ポイント識別情報は、コードIDに限られず、例えば、ユーザIDであってもよい。個々のポイントを識別可能なID又は番号が存在する場合には、このID又は番号がポイント識別情報に相当してもよい。
利用要求は、ポイント識別情報以外の他の情報を含んでもよく、例えば、利用要求を送信した店舗端末30が配置された店舗の店舗IDと、この店舗端末30の端末IDと、の少なくとも一方を含んでもよい。利用要求を受け付けるとは、利用要求に相当するデータを受信することである。第1実施形態では、受付部102は、店舗端末30から、利用要求を受け付ける。受付部102は、ユーザ端末20から利用要求を受け付けてもよいし、他の端末から利用要求を受け付けてもよい。
[実行部]
実行部103は、利用要求が受け付けられた場合に、ポイントを利用するための利用処理を実行可能である。利用処理は、ポイントを利用するための処理である。利用処理は、決済処理、支払処理、又は充当処理ということもできる。第1実施形態では、利用処理は、ポイントの充当に関する処理である。利用処理は、ポイントの利用そのものを行う処理であってもよいし、ポイントの利用に必要な前処理であってもよい。利用処理は、利用要求に応じて実行される処理であればよい。例えば、利用処理は、ユーザが保有するポイントを減少させる処理であってもよいし、利用可能なポイントを参照する処理であってもよい。
例えば、実行部103は、利用要求が受け付けられた場合に、上限に基づいて、利用処理を実行する。上限が適用されるのは、上限が設定された店舗におけるポイントの利用要求が受け付けられた場合であり、上限が設定されていない店舗におけるポイントの利用要求が受け付けられた場合には、上限は適用されない。実行部103は、上限の範囲内でポイントが利用されるように、利用処理を実行する。即ち、実行部103は、上限を超えないように、利用処理を実行する。上限を超えるような利用処理は実行されない。
第1実施形態では、利用可能なポイントを参照する処理が利用処理に相当する場合を例に挙げる。実行部103は、利用要求が受け付けられた場合に、ユーザデータベースDB1を参照し、利用要求に含まれるコードIDに関連付けられた、ユーザが保有するポイントを取得する。実行部103は、利用要求に含まれる店舗IDに上限が関連付けられている場合には、この上限の範囲内となるように、利用可能なポイントを決定する。
例えば、実行部103は、ユーザが保有するポイントが上限以上であれば、利用可能なポイントとして、上限を決定する。実行部103は、ユーザが保有するポイントが上限未満であれば、利用可能なポイントとして、ユーザが保有するポイントを決定する。実行部103は、店舗端末30に利用可能なポイントを送信することによって、利用処理を実行する。店舗では、利用可能なポイントの範囲内でポイントが利用される。実行部103は、上限が設定されていない店舗であれば、ユーザが保有するポイントを、そのまま利用可能なポイントとして決定する。
なお、ユーザが保有するポイントを減少させる処理が利用処理に相当する場合には、実行部103は、上限の範囲内で、ユーザが保有するポイントを減少させるようにすればよい。この場合、利用要求には、ポイントの利用額も含まれるものとする。例えば、実行部103は、利用要求が受け付けられた場合に、利用要求に含まれるポイントの利用額を取得する。実行部103は、利用要求に含まれる店舗IDに上限が関連付けられている場合には、この上限の範囲内でポイントが利用されるように、ポイントを減少させる。
例えば、実行部103は、ポイントの利用額が上限以上であれば、ポイントの利用を禁止する。実行部103は、店舗端末30に、ポイントの利用が禁止されたことを送信する。店舗端末30では、エラーメッセージ等が表示される。実行部103は、ポイントの利用額が上限以上の場合に、ポイントの利用を禁止するのではなく、上限の範囲内で、ポイントの利用を許可してもよい。この場合、実行部103は、ポイントの利用額が上限以下となるように変更したうえで、ポイントを減少させる。実行部103は、店舗端末30に、ポイントの利用額が変更されることを通知し、店舗端末30で所定の操作が行われた場合に、ポイントの利用額を変更してもよい。実行部103は、ポイントの利用額が上限未満であれば、そのままの利用額でポイントを減少させる。
[1-3-2.ユーザ端末で実現される機能]
データ記憶部200は、記憶部22を主として実現される。表示制御部201は、制御部21を主として実現される。データ記憶部200は、決済サービスの提供に必要なデータを記憶する。例えば、データ記憶部200は、アプリ、コードID、及び有効期限を記憶する。表示制御部201は、アプリに基づいて、コードIDを含むコードCを表示する。
[1-3-3.店舗端末で実現される機能]
データ記憶部300は、記憶部32を主として実現される。利用要求送信部301は、制御部31を主として実現される。データ記憶部300は、決済サービスの提供に必要なデータを記憶する。例えば、データ記憶部300は、店舗端末30が配置された店舗の店舗IDと、店舗端末30の端末IDと、を記憶する。データ記憶部300は、コードCに含まれるコードIDを取得するプログラムも記憶する。
利用要求送信部301は、サーバ10に、利用要求を送信する。例えば、読取装置36がコードCを読み取ると、利用要求送信部301は、コードCに含まれるコードIDを取得する。利用要求送信部301は、サーバ10に、店舗ID、端末ID、及びコードIDを含む利用要求を送信する。利用要求がポイントを減少させることの要求である場合には、利用要求には、ポイントの利用額が含まれる。
なお、コードIDは、光学的に取得されなくてもよく、通信によって取得されてもよい。例えば、店舗端末30は、Wi-Fi(登録商標)、Bluetooth(登録商標)、又は赤外線通信を利用してコードIDを取得してもよいし、公知のICカードで採用されている近距離無線通信を利用してコードIDを取得してもよい。コードIDは、店舗端末30の操作部34から入力されてもよい。
[1-3-4.管理者端末で実現される機能]
データ記憶部400は、記憶部42を主として実現される。設定送信部401は、制御部41を主として実現される。データ記憶部400は、決済サービスの提供に必要なデータを記憶する。例えば、データ記憶部400は、管理者が上限を設定するための管理ツールを記憶する。設定送信部401は、サーバ10に、管理者が管理ツールから指定した設定内容を送信する。例えば、設定送信部401は、サーバ10に、管理者により指定された対象店舗の店舗IDと、管理者により指定された上限と、を送信する。
[1-4.第1実施形態の決済システムで実行される処理]
図7は、第1実施形態の決済システムSで実行される処理の一例を示すフロー図である。図7に示す処理は、制御部11,21,31,41の各々が記憶部12,22,32,42の各々に記憶されたプログラムに従って動作することによって実行される。
図7に示すように、管理者端末40は、ポイントが不正に利用された場合に、管理者による、対象店舗の店舗ID及び上限の指定を受け付ける(S100)。管理者端末40は、管理者により指定された対象店舗の店舗ID及び上限に基づいて、サーバ10に、所定の設定要求を送信する(S101)。サーバ10は、設定要求を受信すると(S102)、設定要求に基づいて、対象店舗に上限を設定する(S103)。S103では、サーバ10は、設定要求に含まれる店舗IDと、設定要求に含まれる上限と、が関連付けられるように、店舗データベースDB2を更新する。S100~S103により、上限の設定が完了する。
ユーザ端末20は、ユーザの操作に基づいて、アプリを起動してコードCを表示部25に表示させる(S104)。アプリの起動時には、サーバ10との間でログイン処理が実行されてもよい。ログイン処理では、ユーザID及びパスワードの入力が要求されてもよいし、ログイン済みのユーザ端末20であれば、ログイン済みであることを示す情報をユーザ端末20に記録しておき、この情報を利用して、ユーザID及びパスワードの入力を省略してもよい。
ユーザは、S104で表示させたコードCを店員に提示する。店員は、読取装置36でコードCを読み取る。店舗端末30は、読取装置36の読取結果に基づいてコードIDを取得し、サーバ10に、ポイントの利用要求を送信する(S105)。サーバ10は、利用要求を受信すると(S106)、店舗データベースDB2に基づいて、利用要求を送信した店舗端末30が配置された店舗に上限が設定されているか否かを判定する(S107)。
上限が設定されていると判定された場合(S107;Y)、サーバ10は、上限に基づいて、利用処理を実行し(S108)、本処理は終了する。上限に基づく利用処理は、先述した通りである。上限が設定されていないと判定された場合(S107;N)、サーバ10は、店舗端末30との間で、上限に基づかずに、利用処理を実行し(S109)、本処理は終了する。上限に基づかない利用処理も、先述した通りである。
第1実施形態の決済システムSによれば、ポイントが不正に利用された場合に、対象店舗で利用可能なポイントに関する上限を設定し、利用要求が受け付けられた場合に、上限に基づいて、利用処理を実行する。これにより、対象店舗であったとしても、上限の範囲内であればポイントを利用可能なので、一定程度の利便性を維持できる。また、上限を超える範囲のポイントの利用は制限されるので、ポイントの不正利用を防止できる。例えば、正当なユーザは、一度に大量にポイントを利用することは少なく、少額のポイントをこまめに利用することが多い。一方、悪意のある第三者は、一度に大量のポイントを利用することが多く、少額のポイントをこまめに利用することは少ない。このため、上限の設定により、正当なユーザの利用を妨げることなく、かつ、第三者による不正利用を防止できるので、利便性を維持しつつ、ポイントの不正利用を防止できる。
また、決済システムSは、他の決済手段を利用した支払に充当可能なポイントが決済手段に相当し、ポイント利用時の利便性を維持しつつ、ポイントの不正利用を防止できる。
[2.第2実施形態]
次に、決済システムSの第2実施形態を説明する。第1実施形態では、対象店舗に設定された上限が全てのユーザに適用される場合を説明した。対象店舗を訪れるユーザの中には、正当である確率が非常に高いユーザもいれば、悪意のある第三者なのか見分けがつかないユーザもいる。第2実施形態では、正当である確率が非常に高いユーザについては、対象店舗に設定された上限を適用しないようにする。即ち、悪意のある第三者なのか見分けがつかないユーザに対し、対象店舗に設定された上限が適用される。
例えば、悪意のある第三者は、不正に入手したユーザIDが示す他人の普段の行動を意識せずにポイントを不正に利用することが多い。このため、第三者がポイントを不正に利用としている店舗と、第三者がなりすましている他人(正当なユーザ)が普段から利用している店舗と、が同じである確率は極めて低い。第三者が何らかの形で他人が普段利用している店舗を特定したとしても、わざわざこの店舗まで移動して不正利用をすることは考えにくい。
そこで、第2実施形態では、ユーザが普段から利用している店舗であれば、正当なユーザによる利用である確率が高いので、この店舗が対象店舗だったとしても上限を適用しないようにする。これにより、正当である確率が非常に高いにもかかわらず、上限が適用されてしまうといった利便性の低下を防止する。逆に、ユーザが普段は利用していない店舗であれば、悪意のある第三者がなりすましているのか見分けがつきにくいので、この店舗が対象店舗だった場合には上限が適用される。これにより、ポイントの不正利用を防止する。以降、第2実施形態の詳細を説明する。なお、第1実施形態と同様の点は説明を省略する。
[2-1.第2実施形態の決済システムで実現される機能]
第2実施形態では、第1実施形態で説明した図4と同様の機能が実現される。ただし、一部の内容は、第1実施形態とは異なる。例えば、ユーザデータベースDB1及び店舗データベースDB2の内容は、第1実施形態とは異なる。
図8は、第2実施形態のユーザデータベースDB1の一例を示す図である。図8に示すように、ユーザデータベースDB1は、第1実施形態と概ね同様であるが、ユーザが普段利用する店舗の店舗IDが格納される点で異なる。サーバ10は、ユーザの利用履歴に基づいて、ユーザが普段利用する店舗を特定する。この利用履歴は、決済サービスにおける利用履歴であってもよいし、決済サービスと連携する他のサービス(例えば、電子マネー等の他の決済サービス等)における利用履歴であってもよい。
利用履歴には、ユーザが訪れた店舗の店舗IDと、この店舗の利用日時と、が含まれる。利用履歴には、ポイントの利用額等の他の情報が含まれてもよい。第2実施形態では、利用履歴がユーザIDに関連付けられてユーザデータベースDB1に格納されている場合を説明するが、利用履歴は、他のデータベースに格納されていてもよい。利用履歴は、ユーザの利用に応じて適宜更新される。
サーバ10は、ユーザIDごとに、このユーザIDに関連付けられた利用履歴に基づいて、このユーザIDが示すユーザが普段利用する店舗を特定する。例えば、サーバ10は、過去の全期間又は一部の期間(例えば、直近の数日~数ヶ月程度の期間)の利用履歴に含まれる店舗IDを集計し、利用回数が閾値以上の店舗を、ユーザが普段利用する店舗として特定する。他にも例えば、サーバ10は、利用回数が多い順に所定数の店舗を、ユーザが普段利用する店舗として特定してもよい。サーバ10は、ユーザが普段利用する店舗の店舗IDを、このユーザのユーザIDに関連付けてユーザデータベースDB1に格納する。
なお、ユーザが普段利用する店舗の特定方法は、上記の例に限られない。例えば、ユーザ自身が普段利用する店舗を指定してもよい。この場合、ユーザデータベースDB1には、ユーザが指定した店舗の店舗IDが格納される。例えば、利用額が閾値以上の店舗のみが、ユーザが普段利用する店舗となってもよい。例えば、ユーザ端末20のGPSセンサを利用した位置情報に基づいて、ユーザが普段利用する店舗が特定されてもよい。他にも例えば、ユーザ端末20と接続した通信基地局又はアクセスポイントに基づいて、ユーザが普段利用する店舗が特定されてもよい。ユーザIDに関連付けられた住所等によって、ユーザが普段利用する店舗が特定されてもよい。ユーザが普段利用する店舗は、予め定められた方法によって特定されるようにすればよい。
図9は、第2実施形態の店舗データベースDB2の一例を示す図である。図9に示すように、店舗データベースDB2は、第1実施形態と概ね同様であるが、設定部101の設定は、ポイントの上限ではなくてもよい。例えば、設定部101は、ポイントの利用自体を禁止するような設定をしてもよい。第2実施形態では、上限が設定されるとは限らないので、図9では、設定部101の設定内容を利用制限と記載する。図9の例では、対象店舗ごとに、異なる利用制限が設定されている場合を示している。例えば、店舗1には、1000ポイントの上限が設定されている。店舗2には、ポイントの利用自体が禁止されている。店舗3には、500ポイントの上限が設定されている。
設定部101は、ポイントが不正に利用された場合に、ポイントを利用可能な複数の店舗の中から選択された対象店舗におけるポイントの利用制限に関する設定を行う。設定内容が第1実施形態とは異なるだけであり、設定方法自体は、第1実施形態と同様である。即ち、管理者は、管理者端末40から、対象店舗の店舗IDと、利用制限の内容と、を指定する。利用制限として上限が設定される場合には、管理者は、上限の値を指定する。利用制限としてポイントの利用自体を禁止する設定が行われる場合には、管理者は、ポイントの利用自体を禁止することを指定する。設定部101は、管理者端末40から管理者の指定内容を取得し、店舗データベースDB2に格納する。
実行部103は、利用要求が受け付けられた場合に、利用処理を実行可能である。ただし、利用処理を実行するか否かは、利用制限の設定次第である。実行部103は、所定の条件に基づいて、設定部101の設定を適用するか否かを決定する。この条件は、利用制限の設定を適用するか否かの基準となる条件である。この条件が満たされた場合に、利用制限の設定が適用されてもよい。逆に、この条件が満たされなかった場合に、利用制限の設定が適用されてもよい。以降、この条件を、適用条件と記載する。
適用条件は、正当なユーザと、悪意のある第三者と、ある程度の確率で見分けられる条件であればよい。第2実施形態では、適用条件は、利用要求に対応するユーザが対象店舗を普段から利用しているか否かである場合を例に挙げる。他の適用条件の例は、後述の変形例で説明する。利用要求に対応するユーザとは、ポイントを利用しようとしているユーザIDが示すユーザである。ここでは、利用要求に含まれるコードIDによってユーザが特定されるので、コードIDに関連付けられたユーザIDが示すユーザは、利用要求に対応するユーザに相当する。
実行部103は、利用要求が受け付けられた場合に、ユーザデータベースDB1を参照し、利用要求に含まれるコードIDに関連付けられた、普段利用する店舗の店舗IDを取得する。実行部103は、利用要求に含まれる店舗IDと、当該取得された普段利用する店舗の店舗IDと、が一致する場合、設定部101の設定を適用しないと決定する。実行部103は、利用要求に含まれる店舗IDと、当該取得された普段利用する店舗の店舗IDと、が一致しない場合、設定部101の設定を適用すると決定する。
なお、設定部101の設定を適用しないとは、利用制限の設定に基づかずに利用処理を実行することである。設定部101の設定を適用するとは、利用制限の設定に基づいて、利用処理を実行することである。利用制限として、ポイントの利用禁止が設定されている場合には、利用処理は実行されない。
[2-2.第2実施形態の決済システムで実行される処理]
図10は、第2実施形態の決済システムSで実行される処理の一例を示すフロー図である。図10に示す処理は、制御部11,21,31,41の各々が記憶部12,22,32,42の各々に記憶されたプログラムに従って動作することによって実行される。
図10に示すように、S200~S206の処理は、それぞれS100~S106の処理と同様であるが、S200で指定されるのは、上限に限られない点でS100とは異なる。同様に、S203で設定されるのは、上限に限られない点でS103とは異なる。S206で利用要求が受け付けられた場合、サーバ10は、店舗データベースDB2に基づいて、利用要求を送信した店舗端末30の店舗に利用制限が設定されているか否かを判定する(S207)。S207では、サーバ10は、利用要求に含まれる店舗IDに利用制限の設定が関連付けられているか否かを判定する。
利用制限が設定されていると判定された場合(S207;Y)、サーバ10は、ユーザデータベースDB1に基づいて、利用要求を送信した店舗端末30の店舗が、ユーザが普段利用する店舗であるか否かを判定する(S208)。ユーザが普段利用する店舗であると判定されない場合(S208;N)、サーバ10は、店舗端末30との間で、利用制限の設定に基づいて、利用処理を実行し(S209)、本処理は終了する。利用制限の設定に基づく利用処理は、先述した通りである。
ユーザが普段利用する店舗であると判定された場合(S208;Y)、サーバ10は、店舗端末30との間で、利用制限の設定に基づかずに、利用処理を実行し(S210)、本処理は終了する。利用制限の設定に基づかない利用処理も、先述した通りである。利用制限が設定されていないと判定された場合(S207;N)も同様に、S210の処理が実行される。
第2実施形態の決済システムSによれば、ポイントが不正に利用された場合に、対象店舗におけるポイントの利用制限に関する設定を行い、所定の条件に基づいて、設定を適用するか否かを決定する。これにより、対象店舗であったとしても、設定を適用しないと決定された場合には、ポイントの利用制限が課されないので、ユーザの利便性を維持できる。設定を適用すると決定された場合には、ポイントの利用制限が課されるので、ポイントの不正利用を防止できる。このため、利便性を維持しつつ、ポイントの不正利用を防止できる。第1実施形態では、ポイントの利用を禁止するのではなく上限を設定することによって利便性を維持したが、第2実施形態では、正当な確率が極めて高いユーザについては、利用制限の対象から除外することによって利便性を維持できるので、利用制限として、ポイントの利用を禁止する設定がなされてもよい。
また、決済システムSは、適用条件が、利用要求に対応するユーザが対象店舗を普段から利用しているか否かである。例えば、正当なユーザは、特定の店舗でポイントを利用することが多い。一方、悪意のある第三者は、不正にログインした他人が普段利用しない店舗でポイントを不正利用することが多い。このため、ユーザが対象店舗を普段から利用しているか否かを条件にすることによって、利便性を確実に維持しつつ、ポイントの不正利用を防止できる。
また、決済システムSは、他の決済手段を利用した支払に充当可能なポイントが決済手段に相当し、ポイント利用時の利便性を維持しつつ、ポイントの不正利用を防止できる。
[3.変形例]
なお、本開示は、以上に説明した実施の形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。
[3-1.第1実施形態に係る変形例]
まず、第1実施形態に係る変形例を説明する。図11は、第1実施形態に係る変形例の機能ブロック図である。第2実施形態に係る変形例では、図11の各機能が実現される。
[変形例1-1]
例えば、第1実施形態では、管理者が対象店舗を指定する場合を説明したが、対象店舗は、所定の条件に基づいて選択されてもよい。変形例1-1では、ポイントが不正に利用された不正利用店舗の近隣店舗が対象店舗として選択される場合を例に挙げる。変形例1-1の店舗データベースDB2には、個々の店舗の位置に関する位置情報が格納されているものとする。位置情報は、任意の形式であってよく、例えば、緯度経度、住所、又は座標であってよい。
変形例1-1の決済システムSは、第1選択部104を含む。第1選択部104は、ポイントが不正に利用された不正利用店舗の位置と、複数の店舗の各々の位置と、に基づいて、対象店舗を選択する。変形例1-1では、管理者が管理者端末40から不正利用店舗を指定するものとする。例えば、管理者は、ユーザからの連絡を受けたり、ポイントの利用状況を確認したりすることによって、不正利用店舗を特定する。管理者は、管理者端末40を操作して、不正利用店舗の店舗IDを指定する。
なお、不正利用店舗は、決済システムSで自動的に特定されてもよい。例えば、サーバ10は、ある店舗におけるポイントの利用要求を受け付けた場合に、このポイントを保有するユーザの普段の利用中心地からの距離、普段の利用時間との時間差、普段の利用額との違い、普段購入する商品との違い、又はこれらの組み合わせに基づいて、ポイントの不正な利用であるか否かを判定してもよい。不正利用の判定は、任意のタイミングであってよく、例えば、ポイントの利用後であってもよい。
不正を検知する方法自体は、公知の種々の方法を利用可能である。例えば、クレジットカードの不正検知で利用されている方法を、ポイントの不正利用の判定に流用してもよい。例えば、サーバ10は、機械学習を利用して過去に発生した不正利用の特徴を学習させた学習モデルを利用して、ポイントの不正な利用が発生したか否かを判定してもよい。例えば、サーバ10は、過去に発生したポイントの不正利用の特徴に基づいて定義したルールを利用して、ポイントの不正な利用が発生したか否かを判定してもよい。
例えば、第1選択部104は、店舗データベースDB2に格納された各店舗の位置情報に基づいて、不正利用店舗から所定距離以内の店舗を、対象店舗として選択する。第1選択部104は、不正利用店舗から近い順に所定数の店舗を、対象店舗として選択してもよい。対象店舗の数は、固定値であってもよいし、不正利用の利用額等に応じた可変値であってもよい。第1選択部104は、不正利用店舗と同じエリアの店舗を対象店舗として選択してもよい。対象店舗が選択された後の処理は、第1実施形態で説明した通りである。第1選択部104により選択された対象店舗が管理者に通知され、管理者は、対象店舗を確認したうえで、上限を指定してもよい。この点は、後述の第2選択部105又は第3選択部106により対象店舗が選択された場合も同様である。
変形例1-1によれば、不正利用店舗の位置と、複数の店舗の各々の位置と、に基づいて、対象店舗を選択することによって、ポイントが不正に利用される恐れのある対象店舗を自動的に選択できる。管理者が手動で対象店舗を指定する場合に比べて、ポイントの上限をより迅速に設定し、ポイントの不正利用を効果的に防止できる。管理者が手動で対象店舗を指定する必要もないので、管理者の手間も軽減できる。
[変形例1-2]
例えば、対象店舗は、不正利用店舗と同業種又は似た業種(業態)の店舗であってもよい。変形例1-2の店舗データベースDB2には、個々の店舗の業種に関する業種情報が格納されているものとする。業種は、店舗で取り扱う商品のジャンル又はカテゴリに応じたものであればよい。業種は、店舗自身が指定してもよいし、管理者が指定してもよい。変形例1-2の決済システムSは、第2選択部105を含む。
第2選択部105は、ポイントが不正に利用された不正利用店舗の業種と、複数の店舗の各々の業種と、に基づいて、対象店舗を選択する。例えば、第2選択部105は、店舗データベースDB2に格納された各店舗の業種情報に基づいて、不正利用店舗と同業種又は似た業種の店舗を、対象店舗として選択する。類似する業種を定義した類似業種情報は、予めデータ記憶部100に定義されているものとする。類似業種情報は、管理者が作成してもよいし、国税局等の公的機関が定義した類似業種に基づいて作成されてもよい。第2選択部105は、不正利用店舗と同業種又は似た業種の全ての店舗を、対象店舗として選択してもよいし、所定数の店舗だけを、対象店舗として選択してもよい。対象店舗が選択された後の処理は、第1実施形態で説明した通りである。
変形例1-2によれば、不正利用店舗の業種と、複数の店舗の各々の業種と、に基づいて、対象店舗を選択することによって、ポイントが不正に利用される恐れのある対象店舗を自動的に選択できる。管理者が手動で対象店舗を指定する場合に比べて、ポイントの上限をより迅速に設定し、ポイントの不正利用を効果的に防止できる。管理者が手動で対象店舗を指定する必要もないので、管理者の手間も軽減できる。
[変形例1-3]
例えば、対象店舗は、不正利用店舗と客単価が似た店舗であってもよい。変形例1-3の店舗データベースDB2には、個々の店舗の客単価に関する客単価情報が格納されているものとする。客単価は、過去の全期間又は一部の期間における利用額から算出されるようにすればよい。客単価は、店舗自身が指定してもよいし、管理者が指定してもよい。変形例1-3の決済システムSは、第3選択部106を含む。
第3選択部106は、ポイントが不正に利用された場合の利用額と、複数の店舗の各々に関連付けられた利用額と、に基づいて、対象店舗を選択する。変形例1-3では、利用額の一例として客単価を説明するが、利用額は、客単価に限られない。ポイントの平均的な利用額であってもよい。例えば、第3選択部106は、店舗データベースDB2に格納された各店舗の客単価情報に基づいて、不正利用店舗と同程度の客単価の店舗を、対象店舗として選択する。
同程度の客単価の店舗とは、不正利用店舗の客単価との違いが閾値未満の店舗である。第3選択部106は、不正利用店舗と同程度の客単価の全ての店舗を、対象店舗として選択してもよいし、所定数の店舗だけを、対象店舗として選択してもよい。第3選択部106は、不正利用店舗の客単価との違いが小さい順に所定数の店舗を、対象店舗として選択してもよい。第3選択部106は、不正に利用されたポイント数と同程度の客単価の店舗を、対象店舗として選択してもよい。対象店舗が選択された後の処理は、第1実施形態で説明した通りである。
変形例1-3によれば、ポイントが不正に利用された場合の利用額と、複数の店舗の各々に関連付けられた利用額と、に基づいて、対象店舗を選択することによって、ポイントが不正に利用される恐れのある対象店舗を自動的に選択できる。管理者が手動で対象店舗を指定する場合に比べて、ポイントの上限をより迅速に設定し、ポイントの不正利用を効果的に防止できる。管理者が手動で対象店舗を指定する必要もないので、管理者の手間も軽減できる。
[変形例1-4]
例えば、第1実施形態のように、対象店舗における支払は、ポイントと、他の決済手段と、の併用が可能である場合に、上限は、対象店舗における支払の総額に対するポイントの割合であってもよい。総額をX(Xは自然数)円として、ポイントの利用額をY(YはX以下の自然数)円とすると、この割合は、X/Yの値である。上限は、第1実施形態と同様に管理者が指定してもよいし、過去の不正利用における割合から算出されてもよい。割合は、パーセンテージ等の任意の形式で表現可能である。
上限が割合を示す点で第1実施形態とは異なるだけであり、他の点は、第1実施形態で説明した通りである。ただし、変形例1-4では、利用要求に、支払の総額と、ポイントの利用額と、が含まれるものとする、ポイントの利用額は、支払の総額以下の任意の数値が店舗端末30に入力される。実行部103は、利用要求に含まれる総額に対するポイントの利用額の割合を計算し、上限として設定された割合以上であるか否かを判定する。実行部103は、上限として設定された割合未満であれば、上限に基づかずに利用処理を実行する。実行部103は、上限として設定された割合以上であれば、上限に基づいて、利用処理を実行する。
変形例1-4によれば、対象店舗における支払の総額に対するポイントの割合を上限として設定することによって、利便性を効果的に維持しつつ、ポイントの不正利用を効果的に防止できる。例えば、正当なユーザは、支払の端数をポイントで充当するといったように、支払の総額に対して低い割合でポイントを利用することが多い。一方、第三者は、自分で一切の負担をしたくないため、10割又はそれに近い割合でポイントを利用する。このため、上限としての割合は、7割~10割程度の高い割合で設定しても、正当なユーザの利便性を損なわず、ポイントの不正利用を効果的に防止できる。
[変形例1-5]
例えば、第1実施形態では、全ての対象店舗の上限が同じである場合を説明したが、設定部101は、複数の対象店舗の各々に、当該対象店舗に応じた上限を設定してもよい。例えば、管理者が上限を指定する場合には、管理者は、個々の対象店舗ごとに上限を指定する。設定部101は、対象店舗ごとに、当該対象店舗に対して管理者が指定した上限を設定する。
決済システムSで自動的に上限が設定される場合には、設定部101は、対象店舗ごとに、当該対象店舗に関する店舗情報に基づいて、当該対象店舗の上限を設定する。この店舗情報としては、任意の情報を利用可能である。例えば、設定部101は、対象店舗ごとに、当該対象店舗における過去の利用額の平均に基づいて、当該対象店舗の上限を設定してもよい。他にも例えば、設定部101は、対象店舗ごとに、当該対象店舗の業種、売上、利益、客数、客単価、ポイントの平均利用額、又はこれらの組み合わせに基づいて、当該対象店舗の上限を設定してもよい。
受付部102は、複数の対象店舗の各々から、利用要求を受け付け可能である。実行部103は、利用要求をした対象店舗に応じた上限に基づいて、利用処理を実行する。対象店舗に応じた上限が設定される点で第1実施形態とは異なるだけであり、他の点は、第1実施形態で説明した通りである。第2実施形態で説明した図9の店舗データベースDB2も、対象店舗に応じた上限が設定された一例を示すものである。
変形例1-5によれば、複数の対象店舗の各々に、当該対象店舗に応じた上限を設定することによって、対象店舗に応じた最適な上限を設定し、利便性を効果的に維持しつつ、ポイントの不正利用も効果的に防止できる。
[変形例1-6]
例えば、実行部103は、利用要求に対応するユーザが対象店舗を普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定してもよい。利用要求に対応するユーザが対象店舗を普段から利用しているか否かを判定する方法は、第2実施形態で説明した通りである。実行部103は、利用要求に対応するユーザが対象店舗を普段から利用していると判定された場合に、上限には基づかずに、利用処理を実行すると決定する。実行部103は、利用要求に対応するユーザが対象店舗を普段は利用していないと判定された場合に、上限に基づいて、利用処理を実行すると決定する。
変形例1-6によれば、利用要求に対応するユーザが対象店舗を普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例1-7]
例えば、受付部102は、ユーザ端末20にインストール可能な複数のアプリの各々を利用して、利用要求を受け付け可能であってもよい。変形例1-7では、コードCを表示可能なアプリが複数存在するものとする。ユーザは、複数のアプリのうちの少なくとも1つをユーザ端末20にインストールする。個々のアプリで表示されるコードCは、異なってもよい。例えば、あるアプリでは、コードCにコードIDが含まれており、他のアプリでは、コードCにユーザIDが含まれてもよい。更に、個々のアプリで別々のコードIDが含まれてもよい。
個々のアプリは、ポイントを利用するためだけに開発されたものでなくてもよい。例えば、クレジットカードを利用するためのアプリ、銀行口座を利用するためのアプリ、オンラインショッピングモールを利用するためのアプリ、旅行予約をするためのアプリ、及びオークションを利用するためのアプリの各々で、共通のポイントを利用可能であってもよい。個々のアプリでポイントを利用する流れは、第1実施形態と同様であってもよいし、アプリごとに異なってもよい。アプリからポイントを利用する方法自体は、公知の種々の方法を利用可能である。
実行部103は、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定してもよい。利用要求に対応するアプリとは、利用要求をするために利用されたアプリである。ここでは、読取装置36によって読み取られたコードCを表示させたアプリは、利用要求に対応するアプリに相当する。
変形例1-7では、ユーザデータベースDB1に、ユーザが普段利用するアプリに関するアプリ情報が格納されているものとする。過去におけるポイントの利用時にユーザが利用したアプリに基づいて、アプリ情報が示すアプリが決定される。例えば、サーバ10は、過去に最も利用した回数の多いアプリを、ユーザが普段利用するアプリとして決定する。サーバ10は、直近に利用したアプリを、ユーザが普段利用するアプリとして決定する。ユーザが、普段利用するアプリを自分で指定してもよい。
変形例1-7では、コードCに、アプリを識別可能なアプリ識別情報が含まれているものとする。更に、利用要求には、コードCから読み取られたアプリ識別情報が含まれる。実行部103は、利用要求に含まれるアプリ識別情報に基づいて、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用しているか否かを判定すればよい。実行部103は、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用していると判定された場合に、上限には基づかずに、利用処理を実行すると決定する。実行部103は、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用していないと判定された場合に、上限に基づいて、利用処理を実行すると決定する。例えば、利用要求に対応するアプリの利用が初めてである場合は、不正利用の可能性が高いことから、そのようなユーザについては、利用処理を実行しない。更に、利用要求に対応するアプリの利用が初めてであり、かつ、一定時間が経過しない場合に、不正利用の可能性が高いと推定し、そのようなユーザについては、利用処理を実行しないようにしてもよい。
変形例1-7によれば、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例1-8]
例えば、受付部102は、複数のユーザ端末20の各々を利用して、利用要求を受け付け可能であってもよい。変形例1-8では、同じユーザIDだったとしても、複数のユーザ端末20からログイン可能であり、複数のユーザ端末20でコードCを表示可能である。このため、あるユーザIDに関連付けられたポイントの利用要求は、複数のユーザ端末20の各々に表示されたコードCを利用して行うことができる。例えば、正当なユーザだったとしても、スマートフォンであるユーザ端末20と、タブレット端末であるユーザ端末20と、を利用し、両方のユーザ端末20から自身のポイントを利用することがあるので、複数のユーザ端末20の各々を利用した利用要求が可能である。
実行部103は、利用要求に対応するユーザが利用要求に対応するユーザ端末20を普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定する。利用要求に対応するユーザ端末20とは、利用要求をするために利用されたユーザ端末20である。ここでは、読取装置36によって読み取られたコードCを表示させたユーザ端末20は、利用要求に対応するユーザ端末20に相当する。
変形例1-8では、ユーザデータベースDB1に、ユーザが普段利用するユーザ端末20を識別可能なユーザ端末情報が格納されているものとする。ユーザ端末20は、任意の情報によって識別可能であり、例えば、IPアドレス、ユーザ端末20の個体識別情報、サーバ10側で生成した端末ID、SIMカードに格納されたID、又はこれらの組み合わせであってもよい。
過去におけるポイントの利用時にユーザが利用したユーザ端末20に基づいて、ユーザ端末情報が示すユーザ端末20が決定される。例えば、サーバ10は、過去に最も利用した回数の多いユーザ端末20を、ユーザが普段利用するユーザ端末20として決定する。サーバ10は、直近に利用したユーザ端末20を、ユーザが普段利用するユーザ端末20として決定する。ユーザが、普段利用するユーザ端末20を自分で指定してもよい。
変形例1-8では、コードCに、ユーザ端末情報が含まれているものとする。更に、利用要求には、コードCから読み取られたユーザ端末情報が含まれる。実行部103は、利用要求に含まれるユーザ端末情報に基づいて、利用要求に対応するユーザが利用要求に対応するユーザ端末20を普段から利用しているか否かを判定すればよい。実行部103は、利用要求に対応するユーザが利用要求に対応するユーザ端末20を普段から利用していると判定された場合に、上限には基づかずに、利用処理を実行すると決定する。実行部103は、利用要求に対応するユーザが利用要求に対応するユーザ端末20を普段は利用していないと判定された場合に、上限に基づいて、利用処理を実行すると決定する。
変形例1-8によれば、利用要求に対応するユーザが利用要求に対応するユーザ端末20を普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例1-9]
例えば、受付部102は、所定の認証を実行可能な複数のユーザ端末20の各々を利用して、利用要求を受け付け可能であってもよい。この認証は、正当なユーザであることを一定程度保証できる認証であればよく、任意の認証であってよい。例えば、クレジットカード又は身分証明書等のICチップをユーザ端末20で読み取ることによって実行される所持認証、クレジットカード又は身分証明書等をユーザ端末20のカメラで撮影することによって実行される所持認証、ユーザID及びパスワード以外の認証情報をユーザ端末20に入力させることによって実行される知識認証、又はユーザ端末20を利用して実行される指紋認証若しくは顔認証等の生体認証であってもよい。認証の実行方法自体は、公知の種々の方法を利用可能である。
変形例1-9では、ユーザデータベースDB1に、ユーザのユーザ端末20で所定の認証が実行されたか否かを識別可能な認証識別情報が格納されているものとする。この認証識別情報は、変形例1-8で説明したユーザ端末情報に関連付けられて格納される。サーバ10は、あるユーザ端末20で所定の認証が実行されると、このユーザ端末20のユーザ端末情報に関連付けられた認証識別情報を更新する。
実行部103は、利用要求に対応するユーザ端末20が所定の認証を実行済みであるか否かに基づいて、上限に基づく利用処理を実行するか否かを決定する。変形例1-9では、変形例1-8と同様に、コードCにユーザ端末情報が含まれており、利用要求にユーザ端末情報が含まれるものとする。実行部103は、利用要求に含まれるユーザ端末情報に関連付けられた認証識別情報に基づいて、所定の認証を実行済みであるか否かを判定すればよい。
実行部103は、利用要求に対応するユーザ端末20が所定の認証を実行済みであると判定された場合に、上限には基づかずに、利用処理を実行すると決定する。実行部103は、利用要求に対応するユーザ端末20が所定の認証を実行済みではないと判定された場合に、上限に基づいて、利用処理を実行すると決定する。
変形例1-9によれば、利用要求に対応するユーザ端末20が所定の認証を実行済みであるか否かに基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例1-10]
例えば、実行部103は、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、に基づいて、上限に基づく利用処理を実行するか否かを決定してもよい。利用内容とは、ポイントの利用額、総額に対する利用額の割合、利用時間、利用店舗、購入する商品等である。変形例1-10では、ユーザデータベースDB1に、ユーザの普段の利用内容を識別可能な利用内容情報が格納されているものとする。例えば、過去におけるポイントの利用時にユーザが利用した利用内容に基づいて、利用内容情報が決定される。利用内容情報は、ポイントが利用されずに購入された商品に対応する利用内容を示してもよい。
変形例1-10では、利用要求に利用内容が含まれるものとする。例えば、店舗端末30は、店舗端末30に入力された利用額、商品の総額に対する利用額の割合、利用時間、利用店舗、購入する商品等の利用内容を利用要求に含めてサーバ10に送信する。実行部103は、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、が対応する場合に、上限には基づかずに、利用処理を実行すると決定する。実行部103は、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、が対応しない場合に、上限に基づいて、利用処理を実行すると決定する。
なお、利用内容が対応するとは、利用内容が一致又は類似することである。例えば、ポイントの利用額の違いが閾値未満であること、総額に対する利用額の割合の違いが閾値未満であること、利用時間の違いが所定時間未満であること、利用店舗が同じ又は近いこと、購入する商品が同じ又は同様のジャンルであることは、利用内容が対応することに相当する。これらの複数の要素が総合的に考慮されて、利用内容が対応するか否かが判定されてもよい。
変形例1-10によれば、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、に基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例1-11]
例えば、ポイントを利用可能な複数のユーザの各々には、当該ユーザの利用に応じたランクが設定されてもよい。この場合に、実行部103は、利用要求に対応するユーザのランクに基づいて、上限に基づく利用処理を実行するか否かを決定してもよい。なお、ランクごとに、ユーザが利用可能なポイントの上限が設定されていてもよい。設定部101により設定された上限が、ランクに応じた上限よりも多い場合には、ランクに応じた上限が適用される。
変形例1-11では、ユーザデータベースDB1に、ユーザのランクが格納されているものとする。例えば、過去におけるユーザの利用額が多いほど、ユーザのランクが高くなる。この利用額は、ポイントの利用額に限られず、他のサービスの利用額であってもよい。例えば、電子商取引サービスにおける購入額であってもよい。ランクは、利用額以外の他の条件が存在してもよい。例えば、利用回数であってもよいし、特定のクレジットカードを発行したり、特定の銀行口座を開設したりすることがランクの条件になってもよい。
例えば、低ランクのユーザは、保有するポイントが少ないことが予測されるので、悪意のある第三者に狙われにくい。このため、実行部103は、利用要求に対応するユーザのランクが所定ランク未満の場合に、上限には基づかずに、利用処理を実行すると決定する。一方、高ランクのユーザは、保有するポイントが多いことが予測されるので、悪意のある第三者に狙われやすい。このため、実行部103は、利用要求に対応するユーザのランクが所定ランク以上の場合に、上限に基づいて、利用処理を実行すると決定する。
変形例1-11によれば、利用要求に対応するユーザのランクに基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例1-12]
例えば、受付部102は、ユーザ端末20に表示されたコードCと、カード又はICチップ26と、の各々を利用して、利用要求を受け付け可能であってもよい。コードCを利用して利用要求を受け付ける方法は、第1実施形態で説明した通りである。利用要求は、ポイントを識別可能なポイント識別情報が記憶されたカード又はICチップ26を利用して受け付けられてもよい。カードは、ICカードに限られず、磁気カードであってもよい。ポイント識別情報は、ユーザデータベースDB1に格納されているものとする。読取装置36は、カード又はICチップ26に記憶されたポイント識別情報を読み取る。店舗端末30は、当該読み取られたポイント識別情報を含む利用要求を送信する。
実行部103は、利用要求にコードIDが含まれる場合には、コードCを利用して利用要求が受け付けられたと判定する。実行部103は、利用要求にポイント識別情報が含まれる場合には、カード又はICチップ26を利用して利用要求が受け付けられたと判定する。実行部103は、利用要求に含まれる情報に基づいて、コードCで利用要求が受け付けられたか、カード又はICチップ26で利用要求が受け付けられたか、を判定すればよい。
例えば、カード又はICチップ26は、原則として第三者に盗まれにくいので、実行部103は、カード又はICチップ26を利用して利用要求が受け付けられた場合には、上限に基づかずに、利用処理を実行してもよい。コードCは、ユーザID及びパスワードを入手すれば表示できてしまうので、実行部103は、コードCを利用して利用要求が受け付けられた場合に、上限に基づいて、利用処理を実行してもよい。
変形例1-12によれば、カード又はICチップ26を利用して利用要求が受け付けられた場合には、上限に基づかずに、利用処理を実行し、コードを利用して利用要求が受け付けられた場合に、上限に基づいて、利用処理を実行する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例1-13]
例えば、受付部102は、所定のユーザIDでログインした状態のユーザ端末20を利用して、利用要求を受け付け可能であってもよい。第1実施形態の例であれば、利用要求に必要なコードCは、ユーザIDでログインした状態で表示されるので、受付部102は、ユーザIDでログインした状態のユーザ端末20に表示されたコードCを利用して、利用要求を受け付ける。
変形例1-13では、ユーザデータベースDB1に、個々のユーザIDでログインしたユーザ端末20のユーザ端末情報が格納されているものとする。例えば、サーバ10は、あるユーザIDで、あるユーザ端末20からのログインが発生した場合に、このユーザIDと、このユーザ端末20のユーザ端末情報と、を関連付ける。あるユーザIDで、複数のユーザ端末20からログインが発生した場合には、1つのユーザIDに複数のユーザ端末情報が関連付けられる。あるユーザ端末20で、複数のユーザIDでログインが発生した場合には、1つのユーザ端末情報に、複数のユーザIDが関連付けられる。
実行部103は、利用要求に対応するユーザ端末20からログインされたことがあるユーザIDの数に基づいて、上限に基づく利用処理を実行するか否かを決定してもよい。例えば、正当なユーザは、多数のユーザIDでログインすることは考えにくいので、実行部103は、利用要求に対応するユーザ端末20からログインされたことがあるユーザIDの数が閾値未満の場合に、上限には基づかずに、利用処理を実行すると決定する。一方、悪意のある第三者は、多数のユーザIDを不正に入手してログインすることがあるので、実行部103は、利用要求に対応するユーザ端末20からログインされたことがあるユーザIDの数が閾値以上の場合に、上限に基づいて、利用処理を実行すると決定する。
変形例1-13によれば、利用要求に対応するユーザ端末20からログインされたことがあるユーザIDの数に基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例1-14]
例えば、実行部103は、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、に基づいて、上限に基づく利用処理を実行するか否かを決定する。利用内容の意味は、変形例1-10で説明した通りである。ポイントが不正に利用された場合の利用内容とは、不正に利用されたポイントで購入された場合の利用額、総額に対する利用額の割合、利用時間、利用店舗、購入された商品等である。
正当なユーザは、悪意のある第三者と利用内容が異なることが多いので、実行部103は、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、が対応しない場合に、上限には基づかずに、利用処理を実行すると決定する。悪意のある第三者は、同様の利用内容で連続してポイントを不正に利用することが多いので、実行部103は、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、が対応する場合に、上限に基づいて、利用処理を実行すると決定する。なお、利用内容が対応するといった言葉の意味は、変形例1-10で説明した通りである。
変形例1-14によれば、決済手段が不正に利用された場合の利用内容と、利用要求に対応する利用内容と、に基づいて、上限に基づく利用処理を実行するか否かを決定する。これにより、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例1-15]
例えば、決済システムSは、上限が設定された場合に、時間経過に応じて上限を徐々に解除する解除部107を含んでもよい。解除部107は、一定時間が経過するたびに、上限を段階的に解除する。解除とは、上限を増やすこと、又は、上限自体を無くすことである。上限を解除するための時間間隔は、固定であってもよいし、個々の時間間隔で異なってもよい。例えば、解除部107は、1000ポイントの上限が設定された設定時間から3日経過した場合に、上限を2000ポイントに増やす。解除部107は、更に3日経過した場合に、上限を3000ポイントに増やす、といったように、上限を徐々に解除する。上限の増加量は、同じであってもよいし、異なってもよい。
変形例1-15によれば、上限が設定された場合に、時間経過に応じて上限を徐々に解除することによって、利便性を効果的に維持しつつ、ポイントの不正利用を効果的に防止できる。
[変形例1-16]
例えば、決済システムSは、ユーザに、上限が設定された対象店舗に関する対象情報を通知する通知部108を含んでもよい。対象情報は、対象店舗を識別可能な情報である。例えば、対象情報は、対象店舗の店舗名、住所、電話番号、又はこれらの組み合わせである。通知部108は、任意の方法で対象情報を通知可能である。例えば、通知部108は、電子メール、SNS、SMS、メッセージアプリ、又はポイントのアプリ内の通知を利用して、対象情報を通知すればよい。対象情報の通知は、上限が設定された後の任意のタイミングであってよい。例えば、通知部108は、上限が設定されてすぐに対象情報を通知してもよいし、上限が設定されてから一定時間が経過した場合に対象情報を通知してもよい。
変形例1-16によれば、ユーザに対象情報を通知することによって、ユーザは、事前にどの店舗でポイントの上限が設定されたのかを把握できるので、利便性が高まる。
[変形例1-17]
例えば、第1実施形態では、対象店舗ごとに上限が設定される場合を説明したが、対象端末ごとに上限が設定されてもよい。対象端末は、上限が設定された店舗端末30である。同じ店舗であったとしても、上限が設定される店舗端末30と、上限が設定されない店舗端末30と、が混在してもよい。他にも例えば、同じ店舗であったとしても、1000ポイントの上限が設定される店舗端末30と、500ポイントの上限が設定される店舗端末30と、が混在してもよい。対象端末は、管理者が管理者端末40から指定してもよいし、下記のように自動的に選択されてもよい。
例えば、変形例1-1において、第1選択部104は、ポイントが不正に利用された不正利用端末の位置と、複数の店舗端末30の各々の位置と、に基づいて、対象端末を選択してもよい。変形例1-2において、第2選択部105は、ポイントが不正に利用された不正利用端末の業種と、複数の店舗端末30の各々の業種と、に基づいて、対象端末を選択してもよい。変形例1-3において、第3選択部106は、ポイントが不正に利用された場合の利用額と、複数の店舗端末30の各々に関連付けられた利用額と、に基づいて、対象端末を選択してもよい。これらの処理は、変形例1-1~1-3で対象店舗と記載した箇所を、対象端末と読み替えればよい。
変形例1-4において、対象端末における支払は、ポイントと、他のポイントと、の併用が可能であり、上限は、対象端末における支払の総額に対するポイントの割合であってもよい。変形例1-5において、設定部101は、複数の対象端末の各々に、当該対象端末に応じた上限を設定してもよい。受付部102は、複数の対象端末の各々から、利用要求を受け付け可能であってもよい。実行部103は、利用要求をした対象端末に応じた上限に基づいて、利用処理を実行してもよい。変形例1-6において、実行部103は、利用要求に対応するユーザが対象端末を普段から利用しているか否かに基づいて、上限に基づく利用処理を実行するか否かを決定してもよい。変形例1-16において、通知部108は、ユーザに、上限が設定された対象端末に関する対象情報を通知してもよい。これらの処理は、変形例1-1~1-3で対象店舗と記載した箇所を、対象端末と読み替えればよい。
[3-2.第2実施形態に係る変形例]
次に、第2実施形態に係る変形例を説明する。図12は、第2実施形態に係る変形例の機能ブロック図である。第2実施形態に係る変形例では、図12の各機能が実現される。
[変形例2-1]
例えば、変形例1-7と同様に、第2実施形態の受付部102は、ユーザ端末20にインストール可能な複数のアプリの各々を利用して、利用要求を受け付け可能であってもよい。更に、第2実施形態で説明した適用条件は、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用しているか否かであってもよい。この判定方法は、変形例1-7と同様であってよい。
実行部103は、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用していると判定された場合に、設定を適用しない。この場合、実行部103は、設定には基づかずに、利用処理を実行する。実行部103は、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用していないと判定された場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部103は、利用処理を実行しない。第1実施形態のような上限の設定であれば、実行部103は、上限に基づいて、利用処理を実行する。
変形例2-1によれば、利用要求に対応するユーザが利用要求に対応するアプリを普段から利用しているか否かを適用条件にすることによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例2-2]
例えば、変形例1-8と同様に、第2実施形態の受付部102は、複数のユーザ端末20の各々を利用して、利用要求を受け付け可能であってもよい。更に、第2実施形態で説明した適用条件は、利用要求に対応するユーザが利用要求に対応するユーザ端末20を普段から利用しているか否かであってもよい。この判定方法は、変形例1-8と同様であってよい。
実行部103は、利用要求に対応するユーザが利用要求に対応するユーザ端末20を普段から利用していると判定された場合に、設定を適用しない。この場合、実行部103は、設定には基づかずに、利用処理を実行する。実行部103は、利用要求に対応するユーザが利用要求に対応するユーザ端末20を普段は利用していないと判定された場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部103は、利用処理を実行しない。第1実施形態のような上限の設定であれば、実行部103は、上限に基づいて、利用処理を実行する。
変形例2-2によれば、利用要求に対応するユーザが利用要求に対応するユーザ端末20を普段から利用しているか否かを適用条件にすることによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例2-3]
例えば、変形例1-9と同様に、第2実施形態の受付部102は、所定の認証を実行可能な複数のユーザ端末20の各々を利用して、利用要求を受け付け可能であってもよい。更に、第2実施形態で説明した適用条件は、利用要求に対応するユーザ端末20が認証を実行済みであるか否かであってもよい。この判定方法は、変形例1-9と同様であってよい。
実行部103は、利用要求に対応するユーザ端末20が所定の認証を実行済みであると判定された場合に、設定を適用しない。この場合、実行部103は、設定には基づかずに、利用処理を実行する。実行部103は、利用要求に対応するユーザ端末20が所定の認証を実行済みであると判定されない場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部103は、利用処理を実行しない。第1実施形態のような上限の設定であれば、実行部103は、上限に基づいて、利用処理を実行する。
変形例2-3によれば、利用要求に対応するユーザ端末20が認証を実行済みであるか否かを適用条件にすることによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例2-4]
例えば、変形例1-10と同様に、第2実施形態で説明した適用条件は、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、が対応するか否かであってもよい。この判定方法は、変形例1-10と同様であってよい。
実行部103は、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、が対応する場合に、設定を適用しない。この場合、実行部103は、設定には基づかずに、利用処理を実行する。実行部103は、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、が対応しない場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部103は、利用処理を実行しない。第1実施形態のような上限の設定であれば、実行部103は、上限に基づいて、利用処理を実行する。
変形例2-4によれば、利用要求に対応する利用内容と、利用要求に対応するユーザの普段の利用内容と、が対応するか否かを適用条件にすることによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例2-5]
例えば、変形例1-11と同様に、第2実施形態でも、ポイントを利用可能な複数のユーザの各々には、当該ユーザの利用に応じたランクが設定されてもよい。更に、第2実施形態で説明した適用条件は、利用要求に対応するユーザのランクに関する条件であってもよい。ランク等の説明は、変形例1-11と同様であってよい。
実行部103は、利用要求に対応するユーザのランクが所定ランク未満の場合に、設定を適用しない。この場合、実行部103は、設定には基づかずに、利用処理を実行する。実行部103は、利用要求に対応するユーザのランクが所定ランク以上の場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部103は、利用処理を実行しない。第1実施形態のような上限の設定であれば、実行部103は、上限に基づいて、利用処理を実行する。
変形例2-5によれば、利用要求に対応するユーザのランクに関する適用条件を利用することによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例2-6]
例えば、変形例1-12と同様に、第2実施形態の受付部102は、ユーザ端末20に表示されたコードと、カード又はICチップ26と、の各々を利用して、利用要求を受け付け可能であってもよい。更に、第2実施形態で説明した適用条件は、コードを利用して利用要求が受け付けられたか、カード又はICチップ26を利用して利用要求が受け付けられたか、であってもよい。この判定方法は、変形例1-12と同様であってよい。
実行部103は、カード又はICチップ26を利用して利用要求が受け付けられた場合には、設定を適用しない。この場合、実行部103は、設定には基づかずに、利用処理を実行する。実行部103は、コードCを利用して利用要求が受け付けられた場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部103は、利用処理を実行しない。第1実施形態のような上限の設定であれば、実行部103は、上限に基づいて、利用処理を実行する。
変形例2-6によれば、コードCを利用して利用要求が受け付けられたか、カード又はICチップ26を利用して利用要求が受け付けられたか、を適用条件とすることによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例2-7]
例えば、変形例1-13と同様に、第2実施形態の受付部102は、所定のユーザIDでログインした状態のユーザ端末20を利用して、利用要求を受け付け可能であってもよい。更に、第2実施形態で説明した適用条件は、利用要求に対応するユーザ端末20がログインしたことがあるユーザIDの数に関する適用条件であってもよい。この数の特定方法は、変形例1-13で説明した通りである。
実行部103は、利用要求に対応するユーザ端末20からログインされたことがあるユーザIDの数が閾値未満の場合には、設定を適用しない。この場合、実行部103は、設定には基づかずに、利用処理を実行する。実行部103は、利用要求に対応するユーザ端末20からログインされたことがあるユーザIDの数が閾値以上の場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部103は、利用処理を実行しない。第1実施形態のような上限の設定であれば、実行部103は、上限に基づいて、利用処理を実行する。
変形例2-7によれば、利用要求に対応するユーザ端末20がログインしたことがあるユーザIDの数に関する適用条件を利用することによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例2-8]
例えば、変形例1-14と同様に、第2実施形態で説明した適用条件は、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、が対応するか否かであってもよい。この判定方法は、変形例1-14と同様であってよい。
実行部103は、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、が対応しない場合に、設定を適用しない。この場合、実行部103は、設定には基づかずに、利用処理を実行する。実行部103は、実行部103は、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、が対応する場合に、設定を適用する。この場合、ポイントの利用を制限する設定であれば、実行部103は、利用処理を実行しない。第1実施形態のような上限の設定であれば、実行部103は、上限に基づいて、利用処理を実行する。
変形例2-8によれば、ポイントが不正に利用された場合の利用内容と、利用要求に対応する利用内容と、が対応するか否かを適用条件とすることによって、正当なユーザの利便性が損なわれることを防止し、利便性を効果的に維持できる。
[変形例2-9]
例えば、変形例1-15と同様に、第2実施形態の決済システムSは、設定が行われた場合に、時間経過に応じて設定を徐々に解除する解除部107を含んでもよい。この解除方法は、変形例1-15と同様であってよい。ポイントの利用自体を禁止する設定については、何らかの上限の設定に変更された後に、上限の額が徐々に増えるようにすればよい。
変形例2-9によれば、設定が行われた場合に、時間経過に応じて設定を徐々に解除することによって、利便性を効果的に維持しつつ、ポイントの不正利用を効果的に防止できる。
[変形例2-10]
例えば、変形例1-16と同様に、第2実施形態の決済システムSは、ユーザに、設定が行われた対象店舗に関する対象情報を通知する通知部108を含んでもよい。通知の内容は、変形例1-16で説明した通りである。
変形例2-10によれば、ユーザに対象情報を通知することによって、ユーザは、事前にどの店舗でポイントの上限が設定されたのかを把握できるので、ユーザの利便性が高まる。
[変形例2-11]
例えば、第2実施形態では、対象店舗ごとに利用制限が設定される場合を説明したが、変形例1-17と同様に、対象端末ごとに利用制限が設定されてもよい。変形例1-17の説明における上限を、利用制限に読み替えることができる。
[3-3.その他の変形例]
例えば、上記説明した変形例を組み合わせてもよい。
例えば、店舗は、現実の店舗に限られず、オンライン上の店舗であってもよい。決済システムSは、オンライン上のある店舗でポイントが不正に利用された場合に、オンライン上の店舗を対象店舗として、ポイントの利用制限を設定してもよい。決済システムSは、適用条件に基づいて、オンライン上の対象店舗に設定された利用制限を適用するか否かを決定してもよい。
例えば、対象端末は、店舗に配置される端末ではなく、自動販売機であってもよい。決済システムSは、ある自動販売機でポイントが不正に利用された場合に、この自動販売機、又は、近くの自動販売機を対象端末として、ポイントの利用制限を設定してもよい。決済システムSは、適用条件に基づいて、自動販売機に設定された利用制限を適用するか否かを決定してもよい。対象端末は、自動販売機ではなく、駅の自動改札機又はホテルのチェックイン機といった他の端末であってもよい。対象端末は、ポイント等の決済手段を何らか利用可能な端末であればよい。
例えば、決済手段は、ポイントに限られず、先述した任意の決済手段であってよい。例えば、決済システムSは、クレジットカードが不正に利用された場合に、対象店舗又は対象端末に、クレジットカードの上限又は利用制限を設定してもよい。例えば、店舗端末30又は読取装置36にユーザ端末20をかざすことによって決済が実行される態様に限られず、ユーザ端末20の操作だけで決済が実行される場合にも、決済システムSを適用可能である。この場合、ユーザ端末20からサーバ10に利用要求が送信される。例えば、主な機能がサーバ10で実現される場合を説明したが、各機能は、複数のコンピュータで分担されてもよい。例えば、サーバ10で実現されるものとして説明した機能は、ユーザ端末20、店舗端末30、又は管理者端末40で実現されてもよい。サーバ10に記憶されるものとして説明したデータは、データベースサーバ等の他のコンピュータに記憶されてもよい。