JP6377789B1 - サーバー、認証方法およびコンピュータプログラム - Google Patents

Abstract

【課題】一定のセキュリティレベルを担保しつつ、ユーザーと小売り企業等のスマホアプリを提供する企業との双方にとって容易な認証方法を実現する。【解決手段】本実施形態に係るサーバーは、ユーザーの購買履歴データに基づき、前記ユーザーに対する質問を含む質問情報を生成する質問生成部と、ユーザー端末に前記質問情報を送信する送信部と、前記質問に対する回答を含む回答情報を受信する受信部と、前記購買履歴データに基づき前記回答の正誤を判定し、正解か否かを表す判定結果を取得する正誤判定部と、前記質問生成部、前記送信部、前記受信部および前記正誤判定部による一連の処理を繰り返すことにより複数の判定結果を取得し、前記複数の判定結果に基づき前記ユーザーによる回答の正解および不正解の順序を把握し、前記順序に基づいて、前記ユーザーの本人認証を行う認証部と、を備える。【選択図】図１

Description

本発明は、サーバー、認証方法およびコンピュータプログラムに関する。

小売り業界や、サービス業界（例えば外食業界）等の消費者向けにビジネスを行う企業では、各社のマーケティング活動の一環として、会員向けにスマートフォン用のアプリケーション（スマホアプリ）を提供しているケースが増えている。会員向けのスマホアプリでは、主にチラシ閲覧および店舗検索等のサービスや、クーポン獲得メニュー等が提供されている。しかしながら、消費者にとっては利便性が限られており、スマホアプリのダウンロード数や利用率等に課題を抱えている企業が多い。

スマホアプリの魅力度向上のため、会員が自身の購入履歴（購買実績）等を閲覧できるメニューを提供している企業も存在するが、一般的に、スマホアプリと会員番号を紐付けるための認証基盤を実現する事が難しく、当該機能を提供している企業は限定的である。

特許第４９３９１２１号

一般的に、企業が発行する会員カードは、申込み時に、氏名や生年月日、住所、電話番号等を記入してもらうものの、消費者の申告制であり、公的文書との突合せ等による本人確認は実施されていないケースが多い。企業が、会員向けスマホアプリの一つのメニューとして、例えば購買履歴の閲覧サービスを提供しようとする場合、購買履歴は個人の趣味嗜好に関わるデータとなるため、その取り扱いには一層の注意が必要となる。

この場合、スマホアプリを利用する消費者（ユーザー）が、スマホアプリ上で、ある会員番号を登録しただけで、サーバー側で当該会員番号と購買履歴を紐付けて、購買履歴を閲覧できるようにすると、悪意を持った第三者が、自分の会員カードではない会員番号をスマホアプリに登録すれば、第三者の購買履歴を閲覧できるようになる。このため、（なりすましをスマホアプリの利用規約で禁止していたとしても）企業としては、なりすまし対策を実装する必要があると考えられる。

ユーザーが申込み時に記入した情報を、紐付けのための認証情報としてスマホアプリにユーザーに入力して貰う方法も一案ではある。しかしながら、記入した情報が不正確である可能性がある事、記入していない会員も多い事、また、システム化の規模もそれなりに大きい事から、実現のハードルが高い。

そこで、本発明は、一定のセキュリティレベルを担保しつつ、スマホアプリを提供する企業とユーザーの双方にとって容易な認証方法を実現することを目的とする。

本実施形態に係るサーバーは、ユーザーの購買履歴データに基づき、前記ユーザーに対する質問を含む質問情報を生成する質問生成部と、ユーザー端末に前記質問情報を送信する送信部と、前記質問に対する回答を含む回答情報を受信する受信部と、前記購買履歴に基づき前記回答の正誤を判定し、正解か否かを表す判定結果を取得する正誤判定部と、前記質問生成部、前記送信部、前記受信部および前記正誤判定部による一連の処理を繰り返すことにより複数の判定結果を取得し、前記複数の判定結果に基づき前記ユーザーによる回答の正解および不正解の順序を把握し、前記順序に基づいて、前記ユーザーの本人認証を行う認証部と、を備える。

実施形態に係る購買履歴提供システムの一例を示す図。 ユーザー端末の設定状態を示す図。 会員別ファイルデータベースにおける会員Ａのファイル例を示す図。 購入商品リストと売れ筋商品リストの例を示す図。 ユーザーに対する質問の例を示す図。 Ｗｅｂサーバーにおける本人認証処理のフローチャート。 ユーザー端末における本人認証要求の処理の例を示すフローチャート。 Ｗｅｂサーバーにおける購買履歴提供処理のフローチャート。 ユーザー端末の購買履歴閲覧要求の処理の一例のフローチャート。 実施形態に係るシステムの動作シーケンス例を示す図。

以下、図面を参照して、本発明の実施形態について説明する。本実施形態では、小売り業界やサービス業界（例えば外食業界）等の消費者向けにビジネスを行う企業のうち、小売り企業を想定した商品の購買履歴提供システムを例に挙げて説明するが、本発明の適用対象は小売り企業に限定されず、サービス業界（例えば外食業界）など、消費者向けにビジネスを行う企業全般に適用可能である。この場合、以下の説明における“商品”を“サービス”に読み替えることによって、同様にしてサービスの購買履歴提供システムが実現できる。

図１は、本実施形態に係る購買履歴提供システム（以下、本システムと呼ぶ）の全体構成を示す。本システムは、Ｗｅｂサーバー１０１と、Ｗｅｂサーバー１０１に接続された記憶装置５１、６１と、ユーザー端末Ａ、ユーザー端末Ｂ、ユーザー端末Ｃとを備える。ユーザー端末の台数は、これより多くても少なくてもかまわない。

Ｗｅｂサーバー１０１は、通信ネットワーク２０１を介して、ユーザー端末Ａ、Ｂ、Ｃに接続されている。通信ネットワーク２０１は、有線ネットワーク、無線ネットワーク、これらの混合ネットワーク等、どのようなネットワークでもかまわない。ここでは、通信ネットワーク２０１はインターネットであることを想定する。通信ネットワーク２０１では、例えば、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）に基づく通信が行われる。

ユーザー端末Ａ〜Ｃは、会員Ａ、会員Ｂ、会員Ｃが保有する端末である。ユーザー端末Ａ〜Ｃは、プロセッサ、メモリ、記憶装置、入力手段、表示手段、通信手段等を備えた一般的なコンピューターである。ユーザー端末Ａ〜Ｃは、パーソナルコンピュータ、ノート型パソコン、スマートフォン、タブレット装置といった装置である。ここでは、ユーザー端末Ａ〜Ｃは、スマートフォンであることを想定する。

入力手段は、ユーザーが指示またはデータを入力する手段であり、タッチパネル、マウス、キーボード等である。表示手段は、液晶表示装置、有機ＥＬ表示装置等の表示装置である。通信手段は、有線または無線で通信を行う通信回路または通信インターフェースである。使用する通信方式は、携帯電話方式、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、イーサーネット（登録商標）など、通信ネットワーク２０１の構成に応じて、種々可能である。

メモリまたは記憶装置には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、およびＷｅｂブラウザ等のアプリケーション（コンピュータプログラム）が格納されている。プロセッサが、ＯＳおよびアプリケーションを読み出して、メモリ上に展開して実行する。Ｗｅｂブラウザは、ＯＳ上で実行される。以下、アプリケーションをスマホアプリと呼ぶことがある。

ユーザー端末Ａ〜Ｃは、スマホアプリを用いて、Ｗｅｂサーバー１０１と通信することで、Ｗｅｂサーバー１０１との処理を行う。なお、本実施形態ではスマホアプリを利用するが、一般的なＷｅｂブラウザを用いる形態も可能である。

Ｗｅｂサーバー１０１は、一例として、所謂ＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）により提供されるクラウドサービス上のサーバーに相当する。小売り企業等のスマホアプリを提供する企業（以下、小売り企業に統一）、もしくは小売り企業から委託を受けた企業が、小売り企業の会員（ユーザー）に対して、ユーザーの購買実績を含む購買履歴を提供するサービスを、Ｗｅｂサーバー１０１とスマホアプリを用いて実現する。本実施形態では、委託を受けた企業が本サービスを提供する場合を想定する。本サービスは、例えばユーザーの指定した年月の購買履歴を、ユーザーに提供するものである。会員Ａ〜Ｃは、本サービスを受けることで、スマホアプリの画面上で、所望の年月の自身の購買履歴を閲覧することができる。

ここで、ユーザーに購買履歴を提供しようとする場合、購買履歴は個人の趣味嗜好に関わるデータとなるため、その取り扱いには一層の注意が必要となる。このため、購買履歴を提供するに際して、相手がユーザー本人であることを認証（本人認証）することで、なりすましを防止する必要がある。本実施形態のＷｅｂサーバー１０１は、本人認証をユーザーの購買履歴を利用して行うとともに、簡素で柔軟性の高いアルゴリズムを採用することで、一定のセキュリティレベルを担保しつつ、ユーザーと小売り企業との双方にとって容易な認証方法を実現する。

本サービスの提供を受けるために、ユーザーは、小売り企業の会員になって、自身の会員番号を、ユーザー端末におけるスマホアプリに登録しておく。会員番号は、ユーザー端末内のメモリ等に記憶される。ユーザー端末Ａに会員Ａ（ユーザＡ）の会員番号を登録した状態を、図２（Ａ）に模式的に示す。また、スマホアプリには、小売り企業の企業コードが事前に登録されていてもよいし、ユーザーが自分で設定してもよい。

Ｗｅｂサーバー１０１は、通信部１１と、認証部２１と、購買履歴提供部３１と、データ処理部４１とを備える。Ｗｅｂサーバー１０１は、一例として、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等のプロセッサや、メモリ等の記憶装置により構成される。Ｗｅｂサーバー１０１は、図示しないインターフェース（ＩＦ）を介して、記憶装置５１と記憶装置６１に接続されている。

記憶装置５１には、ＰＯＳデータベースと会員マスタとが記憶されている。ＰＯＳデータベースは、ＰＯＳにより収集されたデータを格納する。具体的に、購買者の会員番号や性別、年齢とともに、購買した商品の名称・識別子等やその商品の属するカテゴリーといった商品データや、購買店舗、購買日付、購買時刻といった地理的ないし時刻のデータが、テーブル形式で記録されている。ＰＯＳデータベースは、人での作業等により静的に設定されてもよいし、自動的に更新されるようになっていてもよい。例えば、小売り企業の各店舗に配置されたＰＯＳ端末からデータを自動的に収集して、記憶装置５１に格納してもよい。

会員マスタには、小売り企業の会員に関する情報が設定されている。例えば会員の会員番号、氏名、性別、年齢、住所、電話番号、電子メールアドレス、会員登録日等が設定されている。複数の企業を対象とする場合、企業ごとに、ＰＯＳデータベースと会員マスタが存在してもよいし、一つのＰＯＳデータベースと会員マスタとしてもよい。

記憶装置６１には、会員別ファイルデータベースが格納されている。会員別ファイルデータベースには、会員別に種々のファイルが格納されている。図３に、会員Ａのファイルの例として、各月の購買履歴ファイルと、認証用ファイルとが格納されている。複数の企業を対象とする場合は、企業別かつ会員別に、これらのファイルが存在する。これらのファイルは、ＣＳＶファイル等のファイル形式で格納されてもよいし、データベース形式で格納されてもよい。本実施形態では、ファイル形式で格納されている場合を想定する。

ある月の購買履歴ファイルは、当該月における会員Ａの購買履歴のデータを含む。購買履歴の例として、購入日時、店舗名、購入商品（商品名、メーカー、カテゴリなど）、数量、商品単価、支払金額（会計単位など）がある。なお購買の対象がサービスの場合、サービス名は、対象となるサービス業に応じて適宜定義すればよい。例えば外食業界の場合、購入サービスのサービス名は、料理名でもよい。

認証用ファイルは、後述する本人認証に利用するファイルである。認証用ファイルは、購入商品リストと、売れ筋商品リストと、認証判別数列データとを含む。

購入商品リストは、所定の対象期間内にユーザーが購入した商品のリストである。所定の対象期間は、例えば先月でもよいし、直前の過去Ｘ（Ｘは２以上の整数）ヶ月でもよいし、その他の方法で指定した期間でもよい。会員Ａの購入商品リストの例を、図４（Ａ）に模式的に示す。

売れ筋商品リストは、一定期間内において、小売り企業においてよく売れた商品のリストである。例えば最も多く売れた商品の上位ｙ個の商品の情報を含む。商品の情報は、例えば商品名、メーカー、カテゴリー、販売数量、商品単価などを含む。一定期間は、上記所定の対象期間と同じ期間でもよいし、これとは異なる期間でもよい。売れ筋商品リストの例を、図４（Ｂ）に模式的に示す。

認証判別数列データは、ユーザーが本人である確度が高いと考えられる回答パターン（認証判別数列）を保持している。回答パターン（認証判別数列）は、正解の場合“１”、不正解（間違い）の場合“０”とすると、１と０の配置パターンとして表される。なお、“１”と“０”の関係は、反対でもよい。例えば、“１１０１”は、回答回数が４の場合のパターンであり、１回目の回答が正解、２回目の回答が正解、３回目の回答が不正解、４回目の回答が正解である。回答パターン（認証判別数列）は、回答回数ごとに、１つまたは複数用意される。

通信部１１は、送信部１２と受信部１３とを備える。

送信部１２は、認証部２１または購買履歴提供部３１の指示に従って、データまたは情報を、ユーザー端末に送信する。一例として、データまたは情報を、ＴＣＰ／ＩＰによりＩＰパケットに整形し、ＩＰパケットを送信する。ＩＰパケットは、実際には、データリンク層（ＭＡＣ層等）および物理層の処理を経て、物理パケットとして送信される。データリンク層および物理層の処理は、送信部１２に含まれてもよいし、通信部１１内の図示しない機能部において行ってもよい。

受信部１３は、ユーザー端末からＩＰパケットを受信し、ＩＰパケットに含まれるデータまたは情報を、その宛先（宛先ＩＰアドレスまたは宛先ポート番号など）に応じて、認証部２１または購買履歴提供部３１に渡す。実際には、通信ネットワーク２０１を介して受信された物理パケットが物理層の処理、データリンク層の処理を経て、ＩＰパケットが受信される。これらの物理層およびデータリンク層の処理は、受信部１３で行ってもよいし、通信部１１内の図示しない機能部において行ってもよい。

認証部２１は、ユーザー端末から本人認証要求を受け、ユーザーの本人認証（ユーザーが本人かどうか、すなわち、なりすましでないかどうかの検証）を行う。ユーザーは、購買履歴提供サービスの提供を受けるために、事前に本人確認を受ける必要がある。このため、ユーザーは、スマホアプリの認証ボタンをクリックすることで、認証要求の送信を行う。認証要求は、一例として企業コードと会員番号とを含む。企業コードは、例えば事前にスマホアプリに登録されている。

認証部２１は、質問生成部２２と、正誤判定部２３を備える。

質問生成部２２は、認証要求を行ったユーザーの購入商品リストと、売れ筋商品リストとを用いて、当該ユーザーに対する質問を生成する。認証部２１は、生成された質問を含む質問情報を、送信部１２を介して、ユーザー端末に送信する。スマホアプリの画面には、質問情報に含まれる質問が表示される。ユーザーは、スマホアプリに質問に対する回答を入力する。スマホアプリは、入力された回答を含む回答情報を、Ｗｅｂサーバー１０１に送信する。

質問の生成方法について説明する。質問生成部２２は、ユーザーの購入商品リストから１つの商品（正解商品と呼ぶ）を選択する。売れ筋商品リストから、正解データと異なるＮ個（Ｎは１以上の整数）の商品（誤り商品と呼ぶ）を選択する。正解商品とＮ個の誤り商品とをまとめ、これらの中からユーザーが、所定の対象期間内に購入した商品を選択させる質問を生成する。例えば、ユーザーＡの購入商品リストが図４（Ａ）、売れ筋商品リストが図４（Ｂ）の場合に、図５に示すような内容の質問を生成する。この内容を含む画面が、ユーザー端末Ａのスマホアプリの画面に表示される。この場合、ユーザーは、商品を選択し、ＯＫボタンをクリックすることで、選択した商品を示す回答を含む回答情報が送信される。

ここでは、正解商品の個数は１としたが、複数でもよいし、正解商品が存在しない、つまり、正解商品の個数が０でもよい。０の場合、ユーザーの回答は必ず誤ることになる。ユーザーには事前に、正解商品が質問の選択肢中に含まれない場合もあり得ることを通知しておいてもよい。正解が無いという選択肢が増える事により、なりすまし者にとって、質問の難易度が上がる利点がある。また、正解商品の個数が複数の場合、回答としていずれか１つをユーザーが選択すれば正解としてもよいし、すべてを選択した場合のみ正解としてもよい。
また、誤り商品の選択方法は任意でよい。一例として、ランダムに選択してもかまわないし、売れ行き上位Ｙ（例えばＹは１００）までの商品の中から選択してもよい。この際、選択した商品について、正解商品との類似度を計算し、類似度が高い場合、その商品は除外し、別の商品を選択しなおしてもよい。すなわち、正解商品との類似度が低い商品を選択するようにする。類似度が高い場合、ユーザーが、自分で実際に購入した商品と混同する可能性が高くなるためである。ここで類似度の定義として、例えば商品名の文字列同士の類似度を用いることができる。この場合、文字列同士の異なり具合、または重なり具合などを定量化した値を、類似度として用いてもよい。例えば、最小編集距離またはレーベンシュタイン距離を２つの文字列の類似度として用いてもよい。

なお、類似度の定義に依存して、値が小さいほど、類似度が高い（または低い）場合、または、値が大きいほど、類似度が高い（または低い）場合があり得る。前者の場合、類似度が高い（または低い）とは、類似度が一定値以下（または一定値以上）のことを意味し、後者の場合、類似度が一定値以上（または一定値以下）のことを意味する。

ユーザーは、スマホアプリの画面に表示された質問に対して回答する。ユーザー端末は、ユーザーの回答を含む回答情報をＷｅｂサーバー１０１に送信する。

認証部２１は、受信部１３を介して、ユーザー端末から、回答情報を受信する。正誤判定部２３は、回答情報に含まれる回答が正解かどうかの判定を行い、正解か否かを表す判定結果を取得する。本実施形態では、判定結果を表す値として、正解を“１”、不正解（間違い）を“０”によって表す。

認証部２１は、判定結果の取得回数（すなわち、ユーザーの回答回数）が予め定めた最低回数に達するまで、質問情報の生成、質問情報の送信、回答情報の受信、判定結果の取得と、を繰り返し行う。すなわち、質問生成部２２、送信部１２、受信部１３および正誤判定部２３による一連の処理を繰り返し行う。繰り返しの処理においては、各回で、異なる質問が生成されるようにする。ただし、同じ質問が生成されることを排除しない。

認証部２１は、取得した判定結果を、当該判定結果が何回目に取得されたかを示す回答順番に関連づけて、内部のバッファに記憶する。具体的には、判定結果を取得順に並べた判定結果数列を生成する。内部のバッファは、具体的にはメモリやファイルなどの記憶装置により実現される。

例えば、１回目の判定結果（回答）が正解であれば、このときの判定結果数列は、“１”である。
２回目の判定結果が不正解であれば、このときの判定結果数列は“１０”である。
３回目の判定結果が正解であれば、このときの判定結果数列は、“１０１”である。
４回目の判定結果が正解であれば、このときの判定結果数列は、“１０１１”である。
判定結果数列における数値（１または０）の位置は、回答順番に対応し、例えば、一番左が１番目の回答、左から２番目が２番目の回答に対応する。

認証部２１は、判定結果の取得回数（回答の回答回数）が最低回数に達したら、取得した判定結果に基づき、ユーザーによる回答の正解および不正解の順序を把握し、把握した順序に基づき、認証を行う。より詳細には、取得した判定結果を表す値を取得順に並べた判定結果数列を、最低回数に対応づけられた１つまたは複数の認証判別数列と比較し、判定結果数列が、いずれかの認証判別数列に一致する場合は、ユーザーは本人であると判定する。すなわち認証は成功したと判定する。

いずれの認証判別数列にも一致しない場合は、質問生成部２２、送信部１２，受信部１３、および正誤判定部２３の一連の処理を再度行い、判定結果を取得する。そして、取得した判定結果を追加することにより、判定結果数列を更新する。更新後の判定結果数列、すなわち、すなわち、（最低回数＋１）個の判定結果を表す値を並べた判定結果数列を、（最低回数＋１）の回数に対応づけられた１つまたは複数の認証判別数列と比較する。判定結果数列が、認証判別数列のいずれかに一致する場合は、ユーザーは本人である確度が高い（認証は成功した）と判定する。いずれの認証判別数列にも一致しない場合は、回答回数が上限値に達するまで同様の処理を繰り返す。

回答回数が上限値に達しても、一致しない場合は、認証は失敗（ユーザーは本人である確度は低い）と判断し、エラー通知を、ユーザー端末に送信する。

なお、回答回数（質問回数または判定結果の取得回数）の上限値は、すべてのユーザーに対して共通の値でもよいし、ユーザーごとに上限値が異なってもよい。また、回答の最低回数もすべてのユーザーに対して共通でもよいし、ユーザーごとに最低回数が異なってもよい。

ここで、認証判別数列の作成方法について説明する。

一例として、経験則に基づいて認証判別数列を作成する。例えば３回数連続して正解した場合に、本人である確からしさが高いとの経験則がある場合に、認証判別数列は、“１１１”（回答回数が３の場合）、“０１１１”（回答回数が４の場合）、“００１１１”（回答回数が５の場合）、“０００１１１”（回答回数が６の場合）などが考えられる。この例の場合、回答回数ごとに、認証判別数列は１つ作成される。“０１１１”、“００１１１”、“０００１１１”は、正解の判定結果を表す値（“１）と同じ値を少なくとも１つ含み、不正解の判定結果を表す値（“０”）と同じ値を少なくとも１つ含む数列の一例である。

別の例として、３問中、２回以上正解した場合に、本人である確からしさが高いとの経験則がある場合に、認証判別数列として、“１１１”，“１１０”，“１０１”，“０１１”が考えられる。この場合、回答回数３に対して、４つの認証判別数列が作成される。

同様に、５問中、３回以上正解した場合に、本人である確からしさが高いとの経験則がある場合に、認証判別数列として、“１１００１”，“１００１１”，・・・・などが考えられる。

さらに別の例として、確率計算に基づいて、認証判別数列を作成してもよい。例えば、 本人が正解する確率を８０％、本人でない人が正解する確率を２０％、なりすまし確率を２０％とすると、ベイズ更新により、本人推定確率が９５％を超えた場合に、認証成功とする。この場合の認証判別数列の例としては、“１１”，“１０１１”、“０１１１”がある（具体的な確率計算は省略する）。前述した回答例（１回目の回答が正解、２回目の回答が不正解、３回目の回答が正解、４回目の回答が正解）の場合、“１０１１”が一致するため、４回目の回答で認証成功となる。

認証部２１は、本人認証が成功した場合は、認証キーを生成し、認証キーを含む認証完了通知を、ユーザー端末に送信する。認証キーは、企業ごとかつ会員ごとにユニークな値となるように生成する。例えば、対象となる小売り企業の企業コードと、ユーザーの会員番号と、企業に割り当てられたパスワード（同じ企業の会員では共通）とを並べた数値列のハッシュ値を用いることができる。ハッシュ値は、数値列を所定のハッシュ関数により変換した値である。パスワードは、例えば本サービスの提供主体が企業に割り当てたものである。

ユーザー端末は、認証完了通知を受けた場合、そこに含まれる認証キーを取り出して、スマホアプリに登録する。ユーザー端末Ａに認証キーを登録した状態を、図２（Ｂ）に模式的に示す。ユーザーは、認証キーの登録が完了すると、Ｗｅｂサーバー１０１に、購買履歴閲覧要求を行うことができる。必要に応じて、ユーザーが閲覧年月等の条件を入力し、購買履歴確認ボタンをクリックすると、スマホアプリは、購買履歴閲覧要求を生成して、Ｗｅｂサーバー１０１に送信する。購買履歴閲覧要求は、一例として、企業コードと、会員番号と、認証キーと、閲覧年月とを含む。閲覧年月は複数指定してもよい。ユーザーが閲覧年月を指定しない場合、自動的に先月など、予め定められた特定の年月が指定されてもよい。なお、年月の指定ではなく、日単位で期間を指定してもよい。

Ｗｅｂサーバー１０１の購買履歴提供部３１は、受信部１３を介して、購買履歴閲覧要求を受信すると、認証キーに基づき認証処理を行い、認証に成功すると、指定された年月の購買履歴データを会員別ファイルデータベースまたはＰＯＳデータベースから読み出し、送信部１２を介して、ユーザー端末に送信する。認証処理の具体的として、例えば、当該要求に含まれる企業コードおよび会員番号と、企業のパスワード（認証キーを生成する際に用いたものと同じ。Ｗｅｂサーバー１０１側で保持している）とに基づき、認証キーを生成したときと同じ計算方法で、コード（例えばハッシュ値）を生成する。または、予めコードを生成したものを会員別ファイルデータベース等に格納しておいてもよい。生成したコードが、購買履歴閲覧要求に含まれる認証キーと一致した場合、認証は成功し、対象となる購買履歴ファイルのデータ（購買履歴データ）を、会員別ファイルデータベース等から読み出して、ユーザー端末のスマホアプリに送信する。コードが認証キーと一致しない場合は、エラー通知をスマホアプリに送信する。

図１のデータ処理部４１は、ＰＯＳデータベースと、会員マスタとに基づき、購入履歴ファイルと認証用ファイルとを生成（更新）する。ただし、認証用ファイルにおける認証判別数列データは、予め与えられたものを用いることとし、生成または更新の対象外としてもよい。または、データ処理部４１は、サーバー担当者から更新の指示があった場合にのみ、認証判別数列データを更新してもよい。本実施形態では、認証判別数列データは、ユーザーごとに用意されているが、すべてのユーザーで共通のデータを用いる場合は、認証用ファイルに格納せずに、すべてのユーザーに共通用のファイルに格納し、当該ファイルにアクセスすることで、認証判別数列データを取得してもよい。ユーザーの属性（性別など）で、認証判別数列データを異ならせることも考えられる。また、認証判別数列データは、すべての企業で共通でもよいし、企業ごとに異なってもよい。

データ処理部４１は、一例として、日次処理として、会員毎に、ＰＯＳデータベースから、本日の購買実績を取得し、該当月の購買履歴ファイルを更新する。日次で更新することで、ユーザーは前日までの購買履歴を確認できる。ただし、日次処理でなく、リアルタイムに更新する方法も可能である。この場合、更新のタイミングにも依存するが、同日の購買履歴もユーザーは確認できる。購買履歴ファイルは月単位で生成し、月が変わったら、新しいファイルを生成してもよいし、任意の期間単位で生成してもよい。購買履歴ファイルは、データベース形式にて格納してもよい。購買履歴ファイルの保存期間は、例えば過去２５ヶ月など事前に定めておき、保存期間が経過した購買履歴ファイルは消去してもよい。

データ処理部４１は、月次処理として、前月の購買履歴ファイルから商品を選択して、選択した商品の情報によって、前々月の購入商品リストを更新する（つまり購入商品リストを月次で更新する。前々月の情報は消去する）。例えば１月３１日が終わったら、１月の購買履歴ファイルから商品を選択して、１２月分の情報が反映された購入商品リストを、1月分の商品情報によって、更新する（１２月分の情報は消去される）。購買履歴ファイル内のすべての商品を購入商品リストに反映させてもよいし、ユーザーが自分で購入した商品かを思い出すのを容易にするため、商品名が一定の文字数以上からなる商品のみを選択してもよい。本実施形態では、一ヶ月単位で処理する事を想定しているが、任意の期間単位で処理してもよい。

同様に、データ処理部４１は、月次処理として、ＰＯＳデータベースに基づき、売れ筋商品リストも更新する。本実施形態では、売れ筋商品リストは、会員毎に個別に用意されているが、全ての会員に共通である場合、会員毎の認証用ファイルに格納するのではなく、すべてのユーザーに共通用のファイルに格納し、当該ファイルにアクセスすることで、売れ筋商品リストを取得してもよい。なお、ユーザーの属性（性別など）で、売れ筋商品リストを異ならせることも考えられる。つまりＰＯＳデータベースの属性を利用して、ユーザーの該当する属性に合致するＰＯＳデータのみを用いて、売れ筋商品リストを生成してもよい。なお、売れ筋商品リストについても、商品名が一定の文字数以上の商品のみを選択してもよい。本実施形態では、一ヶ月単位で処理する事を想定しているが、任意の期間単位で処理してもよい。

なお、ファイルのデータ形式は何でも良く、一例としてＪＳＯＮ形式を用いることができる。また、ファイル形式ではなく、データベース形式にて格納してもよい。

図６は、Ｗｅｂサーバー１０１の本人認証処理の一例のフローチャートである。

受信部１３が、ユーザー端末から、企業コードと会員番号とを含む本人認証要求を受信する（Ｓ１０１）。認証部２１は、企業コードが示す企業における当該会員番号のユーザーに対して認証処理を行うことが可能かどうかを判断する（Ｓ１０２）。例えば、その企業に関して、ユーザーの認証用ファイル（例えば購買商品リストなど）が存在しない場合、または、ユーザーに対してロック（認証ロック）がかかっている場合（以前に回答回数が上限値を超えた場合）など、所定の条件を満たす場合、認証処理を行うことができないと判断する。この場合、認証部２１は、送信部１２を介して、ユーザー端末にエラー通知を送信する（Ｓ１０９）。

認証部２１が認証処理可能と判断した場合は、質問生成部２２が、ユーザーに対する質問を含む質問情報を生成し、送信部１２を介してユーザー端末に送信する（Ｓ１０３）。受信部１３が、ユーザー端末から、質問に対する回答を含む回答情報を受信すると、正誤判定部２３が、回答の正誤を判定して、判定結果数列を更新する（Ｓ１０４）。判定結果数列は１回目の回答から順番に判定結果の値（１または０）を並べた数列である。１回目の回答では、判定結果数列は１つの値となる。正誤判定部２３は、判定結果数列を、１つまたは複数の認証判別数列と比較し、判定結果数列がいずれか１つの認証判別数列と一致するかを判断する（Ｓ１０５）。一致する場合は、ステップＳ１１０に進み、一致しない場合はステップＳ１０６に進む。ここで、認証判別数列は、回答回数に応じて、１つまたは複数存在する。すべての回答回数に対して、認証判別数列が存在するとは限らない。本実施形態では、少なくとも２以上の回答回数に対して、認証判別数列が用意されているとする。１回目に対する認証判別数列は存在しないため、一致しない場合と同じステップＳ１０６に進む。

ステップＳ１０６では、認証部２１は、回答回数（判定結果の取得数または質問回数）が上限値に達したかを判断し、達していない場合は、ステップＳ１０３に戻る。質問生成部２２は、再度、質問を生成し、質問を含む質問情報を送信する。質問生成部２２は、前回までに作成したのとは異なる質問を作成する。正誤判定部２３で２回目の回答の正誤を判定し、判定結果数列を更新する（Ｓ１０４）。２回目の回答のため、判定結果数列は２つの値の列となる。判定結果数列を、回答回数（ここでは２）に対応する１つまたは複数の認証判別数列と比較し、いずれか１つと一致する場合は、ステップＳ１１０に進む。一致しない場合は（当該回答回数に対応する認証判別数列が存在しない場合も含む）、認証部２１は、回答回数が上限値に達したかを判断する（Ｓ１０６）。回答回数が上限値に達していない場合は、ステップＳ１０３に戻り、以降同様のステップを繰り返す。ステップＳ１０６で上限値に達したと判断された場合は、エラー通知をユーザー端末に送信し（Ｓ１０７）、当該ユーザーに対して認証ロックをかける（Ｓ１０８）。認証ロックをかけられたユーザーに対しては、本人認証要求を受けたとしても、一定期間の間は、要求を拒否する。認証ロックの解除方法は、一定期間が経過すると自動解除する方法でもよいし、例えば、ユーザーからの要望に基づき、任意に解除する方法でもよい。

ステップＳ１０５で判定結果数列が、いずれかの認証判別数列に一致すると判断された場合、認証部２１は、当該ユーザーの本人認証の成功を決定し、認証キーを生成する（Ｓ１１０）。例えば企業コードと、会員番号と、企業に事前に付与されたパスワードとからハッシュ値を計算し、これを認証キーとする。認証部２１は、送信部１２を介して、認証キーを含む認証完了通知を送信する（Ｓ１１１）。

図７は、ユーザー端末における本人認証要求の処理の一例のフローチャートである。

ユーザー端末におけるスマホアプリは、ユーザーにより認証ボタンがクリックされたことを検知すると、企業コードと会員番号とを含む本人認証要求を送信する（Ｓ２０１）。なお、本サービスが特定の企業向けの場合や、スマホアプリが特定の企業向け用になっている場合など、企業コードを本人認証要求に含めない形態も可能である。

スマホアプリは、Ｗｅｂサーバー１０１からエラー通知を受信した場合は（Ｓ２０２のＹＥＳ）、エラーの内容を画面に表示して（Ｓ２０３）、処理を終了する。

スマホアプリは、Ｗｅｂサーバー１０１から質問情報を受信した場合は（Ｓ２０４のＹＥＳ）、質問情報に示される質問を画面に表示し（Ｓ２０５）、ユーザーからの回答の入力を待機する。ユーザーが回答を入力し、ＯＫボタンのクリックなどにより、これを検知すると、ユーザーの回答を含む回答情報を生成して、Ｗｅｂサーバー１０１に送信する（Ｓ２０６）。エラー通知を受けること無く、質問情報を再度受信した場合は（Ｓ２０４のＹＥＳ）、同様にして、質問をスマホ画面に表示し（Ｓ２０５）、ユーザーの回答に基づく回答情報を送信する（Ｓ２０６）。

回答情報の送信後、スマホアプリがエラー通知を受信した場合（Ｓ２０２）、エラーの内容を画面に表示して、処理を終了する（Ｓ２０３）。エラーの内容が、認証ロックを示す場合、一定期間、本人認証処理を受けることができないことをユーザーは把握する。

回答情報の送信後、ユーザー端末が、Ｗｅｂサーバー１０１から質問情報を受信せず（Ｓ２０４のＮＯ）、認証完了通知を受信した場合、認証完了通知に含まれる認証コードをスマホアプリに登録する（Ｓ２０７）。また、ユーザー端末は、認証完了の旨を画面に表示する（Ｓ２０８）。これにより、ユーザーは、本人認証が無事完了したことを認識する。

図８は、Ｗｅｂサーバー１０１の購買履歴提供処理の一例のフローチャートである。

購買履歴提供部３１は、受信部１３を介して、ユーザー端末から購買履歴閲覧要求を受信する（Ｓ３０１）。購買履歴提供部３１は、購買履歴閲覧要求から企業コードと会員番号と認証キーとを読み出し、認証処理を行う（Ｓ３０２）。例えば、企業コードと会員番号と、企業のパスワードとからハッシュ値（コード）を計算し、ハッシュ値が認証キーに一致する場合は、認証成功と判断する（Ｓ３０３）。

認証成功の場合（Ｓ３０３のＹＥＳ）、購買履歴提供部３１は、購買履歴閲覧要求に含まれる閲覧年月や閲覧期間から、要求された購買履歴ファイルを会員別ファイルデータベースから特定し、購買履歴ファイルのデータ（購買履歴データ）を、ユーザー端末のスマホアプリに送信する（Ｓ３０４）。

購買履歴提供部３１は、計算したコードが認証キーに一致しない場合は（Ｓ３０３のＮＯ）、認証の失敗を決定し、エラー通知を、ユーザー端末に送信する（Ｓ３０５）。この場合、ユーザーに対する購買履歴の提供を、一定期間、ロックしてもよい。認証失敗の他、要求された年月の購買履歴ファイルが存在しない場合（例えばユーザーが当該年月に購買していない場合）、ユーザーに当該ロックがかかっている場合も、エラー通知を送信する。

図９は、ユーザー端末の購買履歴閲覧要求の処理の一例のフローチャートである。

ユーザー端末のスマホアプリは、ユーザーによる購買履歴確認ボタンのクリックの検知などにより、企業コードと会員番号と認証キーと閲覧要求年月や閲覧要求期間とを含む購買履歴閲覧要求を生成し、生成した購買履歴閲覧要求を、Ｗｅｂサーバー１０１に送信する（Ｓ４０１）。スマホアプリは、Ｗｅｂサーバー１０１から応答を受信すると、応答内容を確認し（Ｓ４０２）、エラー通知の場合は、エラーの内容を画面に表示して（Ｓ４０４）、処理を終了する。購買履歴データの場合、購買履歴データを画面に表示する（Ｓ４０３）。これにより、ユーザーは、該当企業について、要求した年月や期間の購買履歴を確認できる。

図１０は、本実施形態におけるユーザー端末ＡおよびＷｅｂサーバー１０１間の動作シーケンスの一例を示す。この例では、ユーザー端末Ａのユーザー（会員）Ａが、Ｗｅｂサーバー１０１から逐次質問を受け、それぞれに回答を行って、５回回答した時点で本人認証が成功した場合のシーケンスを示す。なお、回答の上限回数は、例えば６に設定されている。また、２回目、３回目、５回目、６回目の回答に対して、１つまたは複数の認証判別数列が保存されており、１回目、４回目に対しては、認証判別数列は保存されていないとする。

ユーザー端末Ａは、ユーザーの操作に基づき事前にスマホアプリに会員番号を登録しておく。ユーザー端末Ａは、企業コードと会員番号とを含む本人認証要求を送信し（Ａ１０１）、Ｗｅｂサーバー１０１は、１回目の質問を含む質問情報を送信する（Ａ１０２−１）。ユーザー端末Ａは、ユーザーの回答に基づく回答情報を送信する（Ａ１０３−１）。Ｗｅｂサーバー１０１は、回答の正誤を判定し、判別結果数列を更新する。Ｗｅｂサーバー１０１は、１回目に対応する認証判別数列は保持していないため、判別結果数列がどの認証判別数列にも一致しない場合と同様の判定（不一致判定）を行う。

Ｗｅｂサーバー１０１は、２回目の質問を含む質問情報を送信し（Ａ１０２−２）、ユーザー端末Ａから２回目の回答情報を受信する（Ａ１０３−２）。Ｗｅｂサーバー１０１は、回答の正誤を判定し、判別結果数列を更新する。更新後の判別結果数列は、２回目に対応する１つまたは複数の認証判別数列のいずれにも一致しないと判断し、不一致判定を行う。以降同様にして処理を継続し、３回目でも、更新後の判別結果数列は、３回目に対応する１つまたは複数の認証判別数列のいずれにも一致しないと判断し、不一致判定を行う。４回目では、４回目に対応する認証判別数列が保持されていないため、不一致判定を行う。

Ｗｅｂサーバー１０１は、５回目の質問を含む質問情報を送信し（Ａ１０２−５）、回答情報を受信する（Ａ１０３−５）。Ｗｅｂサーバー１０１は、回答の正誤を判定し、判別結果数列を更新する。Ｗｅｂサーバー１０１は、判別結果数列が、５回目に対応する１つまたは複数の認証判別数列のいずれか１つに合致するため、認証成功を決定する。Ｗｅｂサーバー１０１は、企業コードと会員番号と企業用パスワードとに基づき認証キーを生成し、認証キーを含む認証完了通知を送信する（Ａ１０４）。ユーザー端末Ａは、認証キーをスマホアプリに保存する。その後、ユーザー端末Ａは、ユーザーＡの指示に基づき、企業コードと会員番号と認証キーと閲覧要求年月や閲覧要求期間とを含む購買履歴閲覧要求を送信し（Ａ１０５）、Ｗｅｂサーバー１０１から、指定した企業および指定した年月や期間について、自身の購買履歴データを受信する（Ａ１０６）。

上述した実施形態では、ユーザーの購買商品リストと、売れ筋商品リストからユーザー質問を生成したが、ユーザーの購買商品リストと、購買履歴ファイルとからユーザーへの質問を生成してもよい。例えば、購買商品リストが、ユーザーが先月購入した商品のリストの場合、２月以上前の月の購買履歴ファイルから、ユーザーが先月購入していない商品を誤り商品として選択してもよい。ユーザーが回答を誤る可能性が高くなる懸念はあるものの、認定判別数列を工夫することにより、本人認証の精度の低下を防止できる。

以上、本実施形態によれば、本人認証をユーザーの購買履歴を利用しつつ、簡素で柔軟性の高いアルゴリズムで行うことで、一定のセキュリティレベルを担保しつつ、ユーザーと小売り企業等のスマホアプリを提供する企業との双方にとって容易な認証方法を実現できる。本実施形態の効果を、特許文献１と対比して述べる。

背景技術として挙げた特許文献１では、ユーザーを“逐次”認証するという観点で、本実施形態と共通している。しかしながら、本実施形態は、以下の点で、特許文献１の手法と大きく異なっている。

特許文献１が開示するアルゴリズムは、「誤承認および誤拒絶誤り確率」から計算される「中間認証結果」を集約した累積認証結果を、一つ以上の基準と比較するものである。これに対して、本実施形態のアルゴリズムは、回答の判定結果を数列化したものと、事前に準備された認証判別数列とを比較するものである。認証判別数列は、確率計算だけでなく、経験則で作成してもよく、特許文献１の手法よりも、柔軟性が高い。

また、特許文献１の手法では、回答（チャレンジ）の都度、「中間認証結果」の計算、並びに、「累積認証結果」の計算が必要である。これに対して，本実施形態のアルゴリズムでは、回答の判定結果を０／１で表す数列（プログラミング上は文字列）を作成し、事前に
準備された認証判別数列（一つまたは複数個の文字列）と比較するだけで、本人認証を行うことができる。したがって、計算コストが非常に少ない。これは、スマホアプリ等、数万〜百万ユーザーが同時にアクセスする環境においては、特に大きな利点となる。

本実施形態における用語“プロセッサ”は汎用目的プロセッサまたは中央処理装置（ＣＰＵ）でもよいし、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）やＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等の回路でもよいし、これらの組合せでもよい。汎用目的プロセッサまたはＣＰＵの場合、命令コードを記述したプログラムを、汎用目的プロセッサまたはＣＰＵに実行させることにより、本実施形態のＷｅｂサーバーの機能を実現できる。

また、用語“記憶装置”は、ハードディスク装置、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等、データを永続的に記憶可能なストレージ装置でもよいし、メモリでもよい。メモリは、ＤＲＡＭ（Ｄｙｎａｍｉｃ ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ））、ＳＲＡＭ（Ｓｔａｔｉｃ ＲＡＭ）等の揮発性メモリでもよいし、ＭＲＡＭ（Ｍａｇｎｅｔｏｒｅｓｉｓｔｉｖｅ ＲＡＭ）、ＮＡＮＤ（ｉｎｖｅｒｔｅｄ ＡＮＤ）型フラッシュメモリ等の不揮発性メモリでもよいし、これらの両方でもよい。これらのメモリは、プロセッサによって読み出しおよび書き込みの少なくとも一方が可能である。

本発明は、上述した実施形態に限定されるものではなく、本発明の構成要素を種々に具体化できる。また、上記実施形態における各構成要素を適宜、拡張し、変更し、削除し、または組み合わせて、本発明を形成することも可能である。また、別の構成要素を新たに追加して、本発明を形成することも可能である。

１０１：Ｗｅｂサーバー
２０１：通信ネットワーク
１１：通信部
１２：送信部
１３：受信部
２１：認証部
２２：質問生成部
２３：正誤判定部
３１：購買履歴提供部
４１：データ処理部
５１、６１：記憶装置

Claims (11)

1. ユーザーの商品またはサービスの購買履歴データに基づき、前記ユーザーに対する質問を含む質問情報を生成する質問生成部と、
   ユーザー端末に前記質問情報を送信する送信部と、
   前記質問に対する回答を含む回答情報を受信する受信部と、
   前記購買履歴データに基づき前記回答の正誤を判定し、正解か否かを表す判定結果を取得する正誤判定部と、
   前記質問生成部、前記送信部、前記受信部および前記正誤判定部による一連の処理を繰り返すことにより複数の判定結果を取得し、前記複数の判定結果に基づき前記ユーザーによる回答の正解および不正解の順序を把握し、前記順序に基づいて、前記ユーザーの本人認証を行う認証部とを備え、
   前記質問生成部は、複数回生成する前記質問情報の少なくとも１つとして、前記ユーザーが購入した第１商品と前記ユーザーが購入していない第２商品との中から前記ユーザーの購入した商品を選択させる質問を含む質問情報、または、前記ユーザーが購入した第１サービスと前記ユーザーが購入していない第２サービスとの中から前記ユーザーの購入したサービスを選択させる質問を含む質問情報を生成する
   サーバー。
2. 前記認証部は、前記複数の判定結果のそれぞれを表す値を前記判定結果の取得順に並べた判定結果数列を、前記判定結果の取得回数に対応づけられた１つ以上の認証判別数列と比較し、前記１つ以上の認証判別数列のいずれかに一致する場合に、前記本人認証の成功を決定する
   請求項１に記載のサーバー。
3. 前記認証判別数列は、正解の判定結果を表す値と同じ値を少なくとも１つ含み、不正解の判定結果を表す値と同じ値を少なくとも１つ含む
   請求項２に記載のサーバー。
4. 前記認証部は、前記判定結果数列が、前記１つ以上の認証判別数列のいずれにも一致しない場合、前記一連の処理を再度１回数以上行うことにより１つ以上の判定結果を取得し、取得した１つ以上の判定結果に基づき前記判定結果数列を更新し、更新後の判定結果数列を、前記判定結果の取得回数に対応づけられた１つ以上の認証判別数列と比較する
   請求項２または３に記載のサーバー。
5. 前記認証部は、前記判定結果の取得回数が上限値に達しても、前記判定結果数列が、前記１つ以上の認証判別数列のいずれにも一致しない場合に、前記本人認証の失敗を決定する
   請求項４に記載のサーバー。
6. 前記質問生成部は、
   前記購買履歴データから少なくとも１つの前記第１商品、または、少なくとも１つの前記第１サービスを選択し、
   予め与えられた商品リストから、前記ユーザーが購入しておらず、かつ、前記第１商品との類似度が低い、少なくとも１つの前記第２商品を選択し、または、予め与えられたサービスリストから、前記ユーザーが購入しておらず、かつ、前記第１サービスとの類似度が低い、少なくとも１つの前記第２サービスを選択する
   請求項１ないし５のいずれか一項に記載のサーバー。
7. 前記質問生成部は、前記第１商品として一定の文字数以上の商品名を有する商品を選択する、または前記第１サービスとして一定の文字数以上のサービス名を有するサービスを選択する
   請求項６に記載のサーバー。
8. 前記質問生成部は、前記複数回生成する前記質問情報の少なくとも１つとして、
   予め与えられた商品リストから前記ユーザーが購入していない複数の商品を選択し、または、予め与えられたサービスリストから前記ユーザーが購入していない複数のサービスを選択し、
   前記選択した複数の商品の中から前記ユーザーの購入した商品を選択させる質問を含む質問情報を生成する、または、前記選択した複数のサービスの中から前記ユーザーの購入したサービスを選択させる質問を含む質問情報をさらに生成する、
   請求項１ないし５のいずれか一項に記載のサーバー。
9. 購買履歴提供部をさらに備え、
   前記認証部は、前記ユーザーの本人認証が成功した場合に、前記ユーザーの会員番号と所定のパスワードとに基づき認証子を生成し、
   前記送信部は、前記認証子を前記ユーザー端末に送信し、
   前記受信部は、前記ユーザー端末から購買履歴閲覧要求を受信し、
   前記購買履歴提供部は、前記購買履歴閲覧要求に前記認証子が含まれる場合に、前記購買履歴閲覧要求で指定された期間または予め定められた期間の前記ユーザーの購買履歴データを所定のデータベースから読み出し、
   前記送信部は、前記期間の購買履歴データを前記ユーザー端末に送信する
   請求項１ないし８のいずれか一項に記載のサーバー。
10. ユーザーの商品またはサービスの購買履歴データに基づき、前記ユーザーに対する質問を含む質問情報を生成する生成ステップと、
    ユーザー端末に前記質問情報を送信する送信ステップと、
    前記質問に対する回答を含む回答情報を受信する受信ステップと、
    前記購買履歴データに基づき前記回答の正誤を判定し、正解か否かを表す判定結果を取得する判定ステップと、
    前記生成ステップ、前記送信ステップ、前記受信ステップおよび前記判定ステップによる一連の処理を繰り返すことにより複数の判定結果を取得し、前記複数の判定結果に基づき前記ユーザーによる回答の正解および不正解の順序を把握し、前記順序に基づいて、前記ユーザーの本人認証を行う認証ステップと
    をコンピューターが実行し、
    前記質問情報を生成するステップは、複数回生成する前記質問情報の少なくとも１つとして、前記ユーザーが購入した第１商品と前記ユーザーが購入していない第２商品との中から前記ユーザーの購入した商品を選択させる質問を含む質問情報、または、前記ユーザーが購入した第１サービスと前記ユーザーが購入していない第２サービスとの中から前記ユーザーの購入したサービスを選択させる質問を含む質問情報を生成する、認証方法。
11. ユーザーの商品またはサービスの購買履歴データに基づき、前記ユーザーに対する質問を含む質問情報を生成する生成ステップと、
    ユーザー端末に前記質問情報を送信する送信ステップと、
    前記質問に対する回答を含む回答情報を受信する受信ステップと、
    前記購買履歴データに基づき前記回答の正誤を判定し、正解か否かを表す判定結果を取得する判定ステップと、
    前記生成ステップ、前記送信ステップ、前記受信ステップおよび前記判定ステップによる一連の処理を繰り返すことにより複数の判定結果を取得し、前記複数の判定結果に基づき前記ユーザーによる回答の正解および不正解の順序を把握し、前記順序に基づいて、前記ユーザーの本人認証を行う認証ステップと
    をコンピューターに実行させ、
    前記質問情報を生成するステップは、複数回生成する前記質問情報の少なくとも１つとして、前記ユーザーが購入した第１商品と前記ユーザーが購入していない第２商品との中から前記ユーザーの購入した商品を選択させる質問を含む質問情報、または、前記ユーザーが購入した第１サービスと前記ユーザーが購入していない第２サービスとの中から前記ユーザーの購入したサービスを選択させる質問を含む質問情報を生成する、コンピュータプログラム。

Images