JP2020126292A - 情報処理方法、情報処理装置、及び、プログラム - Google Patents

Abstract

【課題】決済サービスの安全性を向上させる情報処理方法、情報処理装置、及び、プログラムを提供することを目的とする。【解決手段】情報処理装置に、ユーザが使用する情報処理端末から、代金の決済指示を受信する処理と、前記ユーザの信用度、および、前記代金の支払い先となる事業者の信用度の少なくとも１つに基づいて、決済を承認する際の前記ユーザの認証方法を決定する処理と、を実行させる情報処理方法である。【選択図】図６

Description

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

近年では、スマートフォンなどを用いて現金を用いずに決済を行う新しい決済サービスが急速に普及してきている（例えば、特許文献１）。

この決済では、例えば、スマートフォンなどのユーザは、決済サービスを提供する決済事業者からの要求に応じて認証情報を入力し、決済事業者は、入力された認証情報に基づき決済を承認する。

特許第６４３８６２０号公報

上述した従来の手法では、認証情報の要求を含めた決済の手順は、決済額の支払い先となる店舗に関する評価とは無関係に決められている。このため、従来の手法では、例えば、決済の不正利用に用いられやすい商材などを販売している店舗であっても、決済が行われることになり、不正利用を抑制することが困難である。

本開示は、決済サービスの安全性を向上させる情報処理方法、情報処理装置、及び、プログラムを提供することを目的とする。

本開示の一実施形態に係る情報処理方法は、情報処理装置に、ユーザが使用する情報処理端末から、代金の決済指示を受信する処理と、前記ユーザの信用度、および、前記代金の支払い先となる事業者の信用度の少なくとも１つに基づいて、決済を承認する際の前記ユーザの認証方法を決定する処理と、を実行させる。

図１は、実施形態の一態様に係る通信システムの構成を示す。 図２は、本開示に係る情報処理装置のハードウェア構成の一例を示す。 図３は、第１実施形態に係る情報処理装置の機能的な構成を示すブロック図の一例を示す。 図４は、第１の実施形態のユーザ情報データベースの一例を示す図である。 図５は、第１の実施形態の事業者情報データベースの一例を示す図である。 図６は、第１実施形態に係る通信システムの処理のシーケンスの一例を示す。 図７は、第１実施形態の認証方法決定部の処理を説明するフローチャートである。 図８は、第１実施形態の端末１２０の表示例を説明する第一の図である。 図９は、第１実施形態の端末１２０の表示例を説明する第二の図である。 図１０は、第１実施形態の第１実施例の認証方法決定部の処理を説明するフローチャートである。 図１１は、第２実施形態に係る通信システムの処理のシーケンスの一例を示す。 図１２は、第２実施形態の認証方法決定部の処理を説明するフローチャートである。 図１３は、第１実施形態の送金元となる端末の表示例を説明する第一の図である。 図１４は、第２実施形態の送金元となる端末の表示例を説明する第二の図である。 図１５は、第２実施形態の第１実施例の認証方法決定部の処理を説明するフローチャートである。

＜法令遵守＞
本明細書に記載の開示は、実施される場合、本開示を実施する各国の法令を遵守のうえで実施される。また、本明細書に記載の開示は、各国の法令を遵守するために必要な、当業者が成し得る全ての変更、置換、変形、改変、および修正をもって実施される。

本開示に係る決済サービスを実施するための形態について、図面を参照して説明する。
＜システム構成＞
図１は、本開示の一実施形態に係る通信システム１の構成を示す。図１に開示されるように、通信システム１では、ネットワーク１３０を介してサーバ１１０Ａ、サーバ１１０Ｂと、端末１２０Ａ、端末１２０Ｂ、端末１２０Ｃとが接続される。

本開示において、サーバ１１０Ａと、サーバ１１０Ｂとをそれぞれ区別する必要がない場合は、サーバ１１０Ａとサーバ１１０Ｂとは、それぞれサーバ１１０と表現されてもよい。

本開示において、端末１２０Ａと、端末１２０Ｂと、端末１２０Ｃとをそれぞれ区別する必要がない場合は、端末１２０Ａと端末１２０Ｂと端末１２０Ｃとは、それぞれ端末１２０と表現されてもよい。

本開示において、サーバ１１０と、端末１２０とをそれぞれ区別する必要がない場合は、サーバ１１０と端末１２０とは、それぞれ情報処理装置２００と表現されてもよい。なお、ネットワーク１３０に接続される情報処理装置２００の数は限定されない。

サーバ１１０は、ネットワーク１３０を介してユーザが利用する端末１２０に、所定のサービスを提供する。所定のサービスは、限定でなく例として、決済サービス、金融サービス、電子商取引サービス、インスタントメッセンジャーを代表とするＳＮＳ（Social Networking Service）、楽曲・動画・書籍などのコンテンツ提供サービス等を含む。ユーザが端末１２０を介して所定のサービスを利用することで、サーバ１１０は１以上の端末１２０に所定のサービスを提供することができる。

本開示において、決済サービスとは１以上のユーザが金銭または金銭相当物の授受ができるサービスを意味する。限定でなく例として、一次元コード（バーコードなど）、二次元コード（ＱＲコード（登録商標）など）（以下で、一次元コードおよび二次元コードをまとめて「二次元コード等」と総称する。）、近距離無線通信（ＮＦＣ (Near Field Communication)、ＢＬＥ（Bluetooth（登録商標） Low Energy）、Wi-Fi（登録商標）、超音波通信、赤外線通信など）を利用して決済を行うサービスを含む。また、代金の支払いを行うユーザ（支払者）の端末１２０が二次元コード等を読み取ることで決済を行うことを「ユーザ読取型コード決済」または「ＭＰＭ（Merchant Presented Mode）」と表現し、支払いを行うユーザの端末１２０が二次元コード等を表示し、表示された二次元コード等を、代金を請求する店舗側等のユーザ（販売者、請求者）の端末１２０が読み取ることで決済を行うことを「店舗読取型コード決済」または「ＣＰＭ（Consumer Presented Mode）」と表現する。なお、ＭＰＭおよびＣＰＭは、動的であってもよいし、静的であってもよい。

必要に応じて、ユーザＸが利用する端末を端末１２０Ｘと表現し、ユーザＸまたは端末１２０Ｘに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報、ユーザに対応付けられた電子バリュー（電子マネー）の残高情報、ユーザに対応付けられたクレジットカード情報（クレジットカード番号など）を含み、これらのいずれか一つまたは、組み合わせであってもよい。

ネットワーク１３０は、２以上の情報処理装置２００を接続する役割を担う。ネットワーク１３０は、端末１２０がサーバ１１０に接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。

ネットワーク１３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよい。ネットワーク１３０は、限定でなく例として、アドホック・ネットワーク（Ad Hoc Network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（Virtual Private Network：ＶＰＮ）、ローカル・エリア・ネットワーク（Local Area Network：ＬＡＮ）、ワイヤレスＬＡＮ（Wireless LAN：ＷＬＡＮ）、広域ネットワーク（Wide Area Network：ＷＡＮ）、ワイヤレスＷＡＮ（Wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（Metropolitan Area Network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮｓ（Integrated Service Digital Networks）、無線ＬＡＮｓ、ＬＴＥ（Long Term Evolution）、ＣＤＭＡ（Code Division Multiple Access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク１３０は、１つまたは複数のネットワーク１３０を含むことができる。

情報処理装置２００は、本開示に記載される機能および方法を実現できる情報処理装置であればどのような情報処理装置であってもよい。

情報処理装置２００は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、サーバ装置、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダなど）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ（Personal Digital Assistant）、電子メールクライアントなど）、ウェアラブル端末（限定でなく例として、メガネ型デバイス、時計型デバイスなど）、他種のコンピュータ、またはコミュニケーションプラットホームを含む。

＜ハードウェア構成＞
図２を用いて、通信システム１に含まれる情報処理装置２００のハードウェア構成について説明する。

情報処理装置２００は、プロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力インタフェース（入出力Ｉ／Ｆ）２０４と、通信インタフェース（通信Ｉ／Ｆ）２０５とを含む。情報処理装置２００のハードウェアの各構成要素は、限定でなく例として、バスＢを介して相互に接続される。

情報処理装置２００は、プロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により、本開示に記載される機能、および／または、方法を実現する。

プロセッサ２０１は、ストレージ２０３に記憶されるプログラムに含まれるコードまたは命令によって実現する機能および方法を実行する。プロセッサ２０１は、限定でなく例として、中央処理装置（ＣＰＵ）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（Application-Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等を含み、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各実施形態に開示される各処理を実現してもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。

メモリ２０２は、ストレージ２０３からロードしたプログラムを一時的に記憶し、プロセッサ２０１に対して作業領域を提供する。メモリ２０２には、プロセッサ２０１がプログラムを実行している間に生成される各種データも一時的に格納される。メモリ２０２は、限定でなく例として、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）などを含む。

ストレージ２０３は、プログラムを記憶する。ストレージ２０３は、限定でなく例として、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリなどを含む。

通信Ｉ／Ｆ２０５は、ネットワーク１３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２０５は、ネットワーク１３０を介して、他の情報処理装置との通信を実行する機能を有する。通信Ｉ／Ｆ２０５は、各種データをプロセッサ２０１からの指示に従って、他の情報処理装置に送信する。また、通信Ｉ／Ｆ２０５は、他の情報処理装置から送信された各種データを受信し、プロセッサ２０１に伝達する。

入出力Ｉ／Ｆ２０４は、情報処理装置２００に対する各種操作を入力する入力装置、および、情報処理装置２００で処理された処理結果を出力する出力装置を含む。入出力Ｉ／Ｆ２０４は、入力装置と出力装置が一体化していてもよいし、入力装置と出力装置とに分離していてもよい。

入力装置は、ユーザからの入力を受け付けて、当該入力に係る情報をプロセッサ２０１に伝達できる全ての種類の装置のいずれか、または、その組み合わせにより実現される。入力装置は、限定でなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（画像を介した操作入力）、マイク（音声による操作入力）を含む。

出力装置は、プロセッサ２０１で処理された処理結果を出力することができる全ての種類の装置のいずれか、または、その組み合わせにより実現される。当該処理結果を映像または動画像として出力する場合、出力装置は、フレームバッファに書き込まれた表示データに従って、当該表示データを表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力装置は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ（限定でなく例として、液晶ディスプレイ、ＯＥＬＤ（Organic Electroluminescence Display）など）、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよい）に画像やテキスト情報等を表示可能な装置、スピーカ（音声出力）、プリンターなどを含む。なお、これらの出力装置は、３Ｄで表示データを表示可能であってもよい。

本開示の各実施形態のプログラムは、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムを記憶可能である。プログラムは、限定でなく例として、ソフトウェアプログラムやコンピュータプログラムを含む。

記憶媒体は適切な場合、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定でなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カードもしくはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。

また、本開示のプログラムは、当該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して、情報処理装置２００に提供されてもよい。

また、本開示の各実施形態は、プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

なお、本開示のプログラムは、限定でなく例として、JavaScript（登録商標）、Pythonなどのスクリプト言語、Ｃ言語、Ｇｏ言語、Swift Koltin、Java（登録商標）など
を用いて実装される。

情報処理装置２００における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよい。

情報処理装置２００における処理の少なくとも一部を、他の情報処理装置により行う構成としてもよい。この場合、プロセッサ２０１により実現される各機能部の処理のうち少なくとも一部の処理を、他の情報処理装置で行う構成としてもよい。

＜その他＞
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよい。

本開示では、明記されていない限り、または文脈によって示されない限り、「AおよびBの少なくとも一方」は、「Ａ、Ｂ、またはその両方」を意味する。さらに、明記されない限り、または文脈によって示されない限り、「ａ」、「ａｎ」、または「ｔｈｅ」は「１つまたは複数」を意味するものとする。したがって、本明細書では、別段に明記されない限り、または文脈によって示されない限り、「ａｎ Ａ」または「ｔｈｅ Ａ」は「１つまたは複数のＡ」を意味する。

本開示は、本開示の実施形態および実施例に対して、当業者が成し得る全ての変更、置換、変形、改変、または修正を包含する。また、添付の特許請求の範囲は、本開示の実施形態および実施例に対して、当業者が成し得る全ての変更、置換、変形、改変、または修正を包含する。さらに、本開示は、当業者が成し得る、本開示における実施形態または実施例の１以上の特徴と、本開示における他の実施形態または実施例の１以上の特徴との任意の組合せを包含する。

加えて、特定の機能を実施するように適合される、配置される、能力を有する、構成される、使用可能である、動作可能である、または動作できる装置またはシステムあるいは装置またはシステムの構成要素に対する添付の特許請求の範囲での参照は、その装置、システム、または構成要素がそのように適合される、配置される、能力を有する、構成される、使用可能にされる、動作可能にされる、または動作できる限り、その装置、システム、構成要素またはその特定の機能がアクティベートされ、オンにされ、またはロック解除されているか否かに関わらず、その装置、システム、構成要素を包含する。

本開示は、明示されない限り、いずれの実施形態または実施例を実施するに際して、事前に、または、実施の直前にユーザからの同意を取得してもよい。また、取得する同意は、包括的なものでもよく、都度取得するものでもよい。

＜第１実施形態＞
第１実施形態は、店舗を出店している事業者の信用度を参照して、決済の承認する際の認証方法を決定する実施形態である。

第１実施形態により、事業者の信用度に応じた認証方法で決済を承認することができ、決済サービスの安全性の向上を図ることができるという効果が得られる。

＜第１実施形態の機能構成＞
図３を用いてサーバ１１０および端末１２０の機能構成を説明する。図３に開示の機能部は、情報処理装置２００が備えるプロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により実現される。
（１）サーバの機能構成
サーバ１１０は、送受信部３１２と、制御部３１３と、記憶部３１４と、を有する。なお、各機能部の機能または処理は、実現可能な範囲において、機械学習またはＡＩ（Ａｒｔｉｆｉｃａｉｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）により実現されてもよい。

送受信部３１２は、制御部３１３の指示に従い、端末１２０などとのデータの送受信を行う。なお、送受信部３１２は、例えば、端末１２０からのログイン要求に含まれるユーザＩＤ、及びパスワードにより端末１２０のユーザが認証された際、端末１２０とのＨＴＴＰＳなどを用いた通信用のセッションを接続する。そして、接続した通信用のセッションのＩＤに対応付けて、端末１２０の通信用のアドレス、及びユーザＩＤなどを記憶しておく。そして、接続した通信用のセッションを用いて、端末１２０にデータを送信する。

制御部３１３は、決済サービス、金融サービス、及び電子商取引サービスなどの所定のサービスを、端末１２０のユーザに提供する処理を行う。制御部３１３の詳細は後述する。

記憶部３１４は、ユーザ情報データベース３１４１と、事業者情報データベース３１４２を有し、端末１２０のユーザ情報と、ＥＣ（electronic commerce）サイトを運営する事業者に関する情報と、を記憶する。ユーザ情報データベース３１４１と、事業者情報データベース３１４２の詳細は後述する。また、記憶部３１４は、サーバ１１０において実行されるプログラムなどが格納される。

なお、本実施形態の事業者は、ＥＣサイト以外の実店舗を有している事業者であっても良いし、ＥＣサイトと実店舗との両方を有している事業者であっても良い。

制御部３１３は、表示処理部３１５と、認証方法決定部３１６と、認証部３１７と、決済部３１８と、出力部３１９と、信用度更新部３２０と、を有する。

表示処理部３１５は、端末１２０に対して各種の画面を表示させる。

認証方法決定部３１６は、ユーザ情報データベース３１４１に格納されたユーザ情報から、参照すべきユーザの信用度を特定する。また、認証方法決定部３１６は、事業者情報データベース３１４２に格納された事業者情報から、参照すべき事業者の信用度を特定する。

また、認証方法決定部３１６は、特定された信用度に基づき、端末１２０から受信した決済要求に応じた決済を承認の認証方法を決定する。具体的には、認証方法決定部３１６は、例えば、商品代金の支払い先となる事業者の信用度に基づき、決済の承認に際してユーザに要求する認証情報を決定する。

例えば、認証方法決定部３１６は、事業者の信用度に応じて、ユーザに対して、認証の難度を高くする認証情報を要求する。

認証情報は、例えば、ユーザを特定するための情報であり、ユーザＩＤと対応付けられたパスコードや、ユーザの生体情報等を含む。生体情報は、例えば、ユーザの指紋を示す指紋情報、ユーザの顔の動画像を示す動画像データ、ユーザの手のひらの静脈のパターンを示す情報、瞳の中の虹彩を示す情報を含む。

例えば、認証情報として、パスコードが要求される場合と、生体情報が要求される場合とを比較すると、生体情報が要求される場合の方が、認証の難度は、高くなる。

また、認証の難度は、認証情報として要求される生体情報の種類によって変化してもよい。例えば、瞳の中の虹彩を示す情報が認証情報として要求される場合と、顔画像の画像データが認証情報として要求される場合とでは、前者の方が認証の難度が高くなる。

認証部３１７は、端末１２０から受信した認証情報に基づき、ユーザの認証を行う。具体的には、認証部３１７は、端末１２０から受信した認証情報が、ユーザ情報データベース３１４１に格納されたユーザの認証情報と一致する場合に、認証情報を送信した端末１２０のユーザを認証する。

決済部３１８は、端末１２０からの支払い代金の決済要求と、認証部３１７による認証結果に応じて、決済を行う。出力部３１９は、送受信部３１２を介して、サーバ１１０から各種の情報を端末１２０へ出力する。

信用度更新部３２０は、ユーザ情報に含まれるユーザの信用度を更新する。また、信用度更新部３２０は、事業者情報に含まれる信用度を更新する。具体的には、信用度更新部３２０は、ユーザの信用度を、ユーザの属性や行動履歴などに応じて更新しても良い。また、信用度更新部３２０は、事業者の信用度を、この事業者が有するＥＣサイトや店舗で商品を購入したユーザの信用度に応じて更新しても良い。さらに、信用度更新部３２０は、事業者の信用度を、この事業者が有するＥＣサイトや店舗で取り扱っている商品の種類などに応じて更新しても良い。

（２）端末の機能構成
端末１２０は、受付部３２１と、送受信部３２２と、制御部３２３と、記憶部３２４と、を有する。なお、各機能部の機能または処理は、実現可能な範囲において、機械学習またはＡＩ（Ａｒｔｉｆｉｃａｉｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）により実現されてもよい。

受付部３２１は、端末１２０のユーザからの各種の操作などを受け付ける。

送受信部３２２は、制御部３２３の指示に従い、サーバ１１０などとのデータの送受信を行う。なお、送受信部３２２は、例えば、サーバ１１０にログインした際、サーバ１１０とのＨＴＴＰＳなどを用いた通信用のセッションを接続する。そして、接続した通信用のセッションのＩＤに対応付けて、サーバ１１０の通信用のアドレスなどを記憶しておく。そして、接続した通信用のセッションを用いて、サーバ１１０にデータを送信する。

制御部３２３は、サーバ１１０により提供される決済サービス、金融サービス、及び電子商取引サービスなどのサービスを利用する処理を行う。

記憶部３２４は、端末１２０で実行されるプログラムなどが格納される。

（３）ユーザ情報データベースの例
以下に、図４を参照して、本実施形態のユーザ情報データベース３１４１について説明する。図４は、第１の実施形態のユーザ情報データベースの一例を示す図である。

本実施形態のユーザ情報データベース３１４１は、情報の項目として、ユーザＩＤ、ユーザ名、住所、保有残高、借入限度額、借入額、ポイント、決済履歴、決済方法、属性、信用度、認証情報などを有する。ユーザ情報データベース３１４１において、項目「ユーザＩＤ」と、その他の項目とは対応付けられている。

項目「ユーザＩＤ」の値は、サーバ１１０が提供する決済サービスのユーザを特定するためのユーザ識別情報を示す。項目「ユーザ名」の値は、ユーザの名称を示す。項目「住所」の値は、ユーザの住所を示す。

項目「保有残高」の値は、ユーザが決済に利用可能な金額の残高を示す。具体的には、項目「保有残高」の値は、ユーザがサーバ１１０に入金している金額である。ユーザがサーバ１１０に入金している金額には、例えば、当該ユーザがサーバ１１０により提供される電子商取引サービスを用いて商品などを販売した際の当該商品などの代金が含まれてもよい。また、例えば、銀行、クレジットカード、及び店舗のレジなどを用いてチャージされた金額が含まれてもよい。

項目「借入限度額」の値は、所定期間（例えば、１か月）において当該ユーザが決済に用いるためにサーバ１１０の運用者から借り入れ可能な金額の上限額である。言い換えれば、借入限度額とは、ユーザが所定期間においてサーバ１１０の運用者から借り入れによって決済することができる決済上限額である。

項目「借入額」の値は、当該所定期間において当該ユーザが各決済に用いるためにサーバ１１０の運用者から借り入れた金額の総額である。なお、借り入れた金額の総額は毎月に決済されてもよい。

項目「ポイント」の値は、例えば、当該ユーザがサーバ１１０から付与された、代金の支払いに利用可能なポイントである。なお、１ポイントで１円分の支払いができるようにしてもよい。

項目「決済履歴」の値は、対応するユーザの決済履歴を示す。具体的には、項目「決済履歴」の値は、例えば、対応するユーザが、サーバ１１０が提供する決済サービスを用いて決済を行った店舗（ＥＣサイト）を特定する情報や、決済サービスを用いてユーザが購入した商品に関する情報が含まれてもよい。

項目「決済方法」の値は、サーバ１１０が提供する決済サービスにおいて、ユーザが使用した決済方法を示す。具体的には、決済方法とは、例えば、後払いサービスによって代金を支払う方法や、チャージ払いサービスによって代金を支払う方法などがある。

後払いサービスは、サーバ１１０により提供される決済サービスでの後払いサービスであり、例えば、サーバ１１０により提供される取引サービスで商品を購入した代金等とまとめて、翌月末まで等の所定期間内に一括して支払うことができるサービスでもよい。また、後払いサービスによって、一括で支払うことができる金額の上限額は、借入限度額であってもよい。

チャージ払いサービスとは、例えば、銀行、クレジットカード、及び店舗のレジなどをから、保有残高に入金（チャージ）し、入金した金額から代金を支払う方法である。

項目「属性」の値は、ユーザの属性を示す。具体的には、項目「属性」は、項目「年齢」、「職業」、「商品部類」などと対応付けられている。項目「年齢」の値は、ユーザの年齢を示し、項目「職業」は、ユーザの職業を示す。項目「商品分類」の値は、ユーザが購入した商品の分類を示す。項目「商品分類」の値は、例えば、ユーザが購入した商品の分類が、電子商材であるか否かを示す情報や、商品の分類が書籍や服飾品、雑貨などであることを示す情報などであってもよい。

項目「信用度」の値は、例えば、ユーザの決済履歴や属性などを含む個人情報から得られる値であり、信用度が大きい値であるほど、優良なユーザであることを示す。

具体的には、例えば、項目「信用度」の値は、ユーザが商品を購入した店舗の事業者の信用度や、ユーザが購入した商品の金額や商品分類、ユーザが決済サービスを利用した回数などに応じて決められる。

項目「認証情報」の値は、ユーザによって入力された認証情報を示す。項目「認証情報」の値は、例えば、ユーザによって入力されたパスコード（パスワード）や、生体情報であってよい。

（４）事業者情報データベースの例
以下に、図５を参照して、本実施形態の事業者情報データベース３１４２について説明する。図５は、第１の実施形態の事業者情報データベースの一例を示す図である。

本実施形態の事業者情報データベース３１４２は、情報の項目として、事業者ＩＤ、事業者名、商品分類１、商品分類２、・・・、商品分類Ｎ、販売履歴、信用度などを有する。事業者情報データベース３１４２において、項目「事業者ＩＤ」とその他の項目とは対応付けられている。

項目「事業者ＩＤ」の値は、事業者を特定するための識別情報を示す。項目「事業者名」の値は、事業者の名称を示す。項目「商品分類１」、「商品分類２」、・・・、「商品分類Ｎ」のそれぞれの値は、事業者が取り扱っている商品の分類を示す。項目「販売履歴」の値は、事業者が販売した商品の履歴を示す。具体的には、項目「販売履歴」の値は、商品を購入したユーザのユーザ情報、販売した商品、商品の代金を含む販売履歴情報であっても良い。

項目「信用度」の値は、事業者の信用度を示す。項目「信用度」の値は、例えば、事業者が取り扱っている商品の分類や、販売履歴に示される実際にユーザに販売した商品の分類に応じて決められてもよい。また、項目「信用度」の値は、事業者の店舗から商品を購入したユーザの信用度に応じて、算出されてもよい。

例えば、事業者の信用度は、商品の販売履歴において、商品を購入しているユーザのうち、信用度が一定の値よりも高いユーザの割合または人数に応じて、決められてもよい。この場合、この事業者から商品を購入しているユーザのうち、信用度の高いユーザが多いほど、事業者の信用度は高くなる。ユーザの信用度は、ユーザの決済履歴と属性に応じて決定される。したがって、本実施形態の事業者の信用度は、言い換えれば、項目「信用度」の値は、事業者の店舗から商品を購入したユーザの行動履歴と属性に応じて、算出される。

また、事業者の信用度は、取り扱っている商品のうち、金額が一定の金額以上である商品の割合に応じて決められてもよいし、商品や商品の製造元の知名度などに応じて決められてもよい。

例えば、販売している商品のうち、金額が一定額以上であり、かつ、知名度の高いブランドの商品が占める割合が高い事業者は、信用度が一定値よりも高くなるようにしてもよい。

＜第１実施形態の動作処理＞
図６を参照し、実施形態に係る通信システム１の処理について説明する。図６は、第１実施形態に係る通信システムの処理のシーケンスの一例を示す。

本実施形態の通信システム１において、端末１２０は、サーバ１１０が提供するサービスを介して販売されている商品の中から、ある商品が購入予定の商品に選択されると（ステップＳ６０１）、選択された商品の決済画面の表示要求をサーバ１１０へ送信する（ステップＳ６０２）。この表示要求には、端末１２０のユーザのユーザＩＤが含まれる。

サーバ１１０は、ユーザＩＤを含む表示要求を受信すると、表示処理部３１５により、決済画面の表示指示を端末１２０へ送信する（ステップＳ６０３）。この決済画面は、サユーザＩＤと対応する保有残高を含む画面であってよい。具体的には、サーバ１１０は、ユーザ情報データベース３１４１を参照し、表示要求に含まれるユーザＩＤと対応する保有残高を表示指示と共に端末１２０に送信してもよい。

端末１２０は、表示指示を受け付けて、決済画面を表示させる（ステップＳ６０４）。続いて、端末１２０は、決済画面において、ユーザの操作により、商品の購入指示を受け付けると、端末１２０は、サーバ１１０に対して、決済指示を送信する（ステップＳ６０５）。

サーバ１１０は、決済指示を受信すると、認証方法決定部３１６により、決済を承認する際のユーザの認証方法を決定する（ステップＳ６０６）。つまり、認証方法決定部３１６は、決済の承認に際し、使用する認証情報を決定し、認証情報の取得要求を端末１２０へ送信する。ステップＳ６０６の処理の詳細は後述する。

続いて、サーバ１１０は、要求される認証情報を示す通知を端末１２０へ送信する（ステップＳ６０７）。言い換えれば、サーバ１１０は、認証情報の取得要求を端末１２０に送信する。なお、このときサーバ１１０は、端末１２０に対して、要求される認証情報を示す通知と共に、ユーザに対して、決済の意志を確認させるためのメッセージなどを送信してもよい。

端末１２０は、通知に従って、ユーザの操作により、通知に示される認証情報を取得する（ステップＳ６０８）。そして、端末１２０は、取得した認証情報と、決済要求とをサーバ１１０へ送信する（ステップＳ６０９）。

サーバ１１０は、認証情報と決済要求とを受けて、認証部３１７により、認証情報に基づく認証を行う（ステップＳ６１０）。

続いて、サーバ１１０は、認証情報によってユーザが認証されると、決済部３１８によって決済を行う（ステップＳ６１１）。そして、サーバ１１０は、決済が完了したことを示す決済完了通知を端末１２０へ送信する（ステップＳ６１２）。

次に、サーバ１１０は、信用度更新部３２０により、決済を行った端末１２０のユーザの信用度に応じて、決済された代金の支払先である事業者の信用度を更新する（ステップＳ６１３）。

具体的には、信用度更新部３２０は、例えば、この決済によって、この事業者から商品を購入したユーザのうち、ユーザの信用度が一定の値以上であるユーザの割合または人数が増えた場合には、事業者の信用度を現時点よりも高くしても良い。また、信用度更新部３２０は、この決済によって販売された商品が所定の条件を満たす場合に、この事業者の信用度を現時点よりも高くしても良い。所定の条件とは、例えば、商品の金額が所定の金額以上であることや、商品の知名度が高いことなどとしても良い。

また、信用度更新部３２０は、ユーザの信用度と、販売した商品の金額や分類とを用いて、事業者の信用度を更新してもよい。言い換えれば、信用度更新部３２０は、ユーザの信用度と、行動履歴とに応じて、事業者の信用度を更新しても良い。

また、信用度更新部３２０は、ユーザによって入力される、事業者に対するレビューや評価などに基づき、事業者の信用度を更新してもよい。具体的には、信用度更新部３２０は、例えば、事業者に対する苦情の回数や、商品の到着に関する問い合わせの回数などが、所定回数よりも多い場合などには、事業者の信用度を下げるように更新しても良い。

また、図６の例では、サーバ１１０が提供する決済サービスにより、事業者に対して代金を支払ったユーザの信用度に基づき、事業者の信用度が更新されるものとしたが、これに限定されない。

事業者の信用度は、事業者に対して代金を支払うための決済指示を行ったユーザの信用度に応じて更新されてもよい。つまり、事業者の信用度は、決済指示を行ったが、実際に決済まで行わなかったユーザの信用度に基づき更新されてもよい。

また、図６の例では、認証方法決定部３１６によって決済の承認に際し、認証情報を端末１２０に要求するものとしたが、これに限定されない。本実施形態では、例えば、端末１２０が認証情報を入力しない設定としており、且つ、事業者の信用度が所定値より多い場合には、サーバ１１０は、端末１２０から認証情報を取得しなくてもよい。

次に、図７を参照して、第１実施形態の認証方法決定部３１６の処理について説明する。図７は、第１実施形態の認証方法決定部の処理を説明するフローチャートである。図７の処理は、図６のステップＳ６０６の詳細を示している。

サーバ１１０の認証方法決定部３１６は、端末１２０から決済指示を受け付けると、事業者情報データベース３１４２を参照し、購入予定とされた商品を販売している事業者の信用度を参照する（ステップＳ７０１）。

続いて、認証方法決定部３１６は、参照した事業者の信用度が、所定値以下であるか否かを判定する（ステップＳ７０２）。この所定値は、予め、決済サービス事業者などによって決められていてもよい。

ステップＳ７０２において、事業者の信用度が所定値より大きい場合には、認証方法決定部３１６は、処理を終了する。

ステップＳ７０２において、事業者の信用度が所定値以下である場合、認証方法決定部３１６は、決済の承認の際に、認証の難度を高くする認証情報を要求する（ステップＳ７０３）。

具体的には、例えば、サーバ１１０は、端末１２０のユーザが決済を行う際にパスコードを認証情報として要求していたとする。このとき、端末１２０のユーザが、信用度が所定値以下の事業者ＡのＥＣサイトから商品を購入したとする。

すると、サーバ１１０は、認証方法決定部３１６により、端末１２０のユーザに対して、認証の難度を上げる認証情報として、顔画像の画像データを要求する。なお、顔画像の画像データとは、顔の動画像を示す動画像データを含む。

本実施例では、このように、事業者の信用度が低いほど、決済を行うための認証の難度を高くする。言い換えれば、本実施例では、事業者の信用度が低いほど、ユーザの認証が難しくなる。

したがって、本実施例によれば、信用度の低い事業者に対して、容易に決済が承認されることを抑制することができ、決済サービスの安全性を向上させることができる。

なお、本実施形態では、認証の難度と、事業者の信用度の閾値とを対応させて、段階的に認証の難度を上げるようにしても良い。具体的には、例えば、事業者の信用度が、第一の所定値以下の場合には、認証情報を、パスコードから顔画像の画像データとして難度をあげてもよい。また、事業者の信用度が、第一の所定値よりもさらに低い第二の所定値よりも低い以下の場合には、認証情報を、パスコードから、顔画像の画像データよりもさらに認証の難度を上げる指紋情報としても良い。

＜第１実施形態の端末１２０の表示態様＞
次に、図８及び図９を参照して、端末１２０の表示例について説明する。図８は、第１実施形態の端末１２０の表示例を説明する第一の図である。

図８に示す画面８１Ａは、図６のステップＳ６０４で端末１２０に表示される決済画面の一例を示す。

画面８１Ａは、表示欄８２と表示欄８３を有する。表示欄８２は、購入予定とされた商品の画像が表示される。表示欄８３には、商品の代金、ユーザの保有残高などが表示される。

また、表示欄８３には、操作ボタン８４が表示されており、操作ボタン８４が操作されると、端末１２０は、サーバ１１０に対して、ユーザＩＤと共に決済指示を送信し、画面８１Ａを画面８１Ｂに遷移させる。

画面８１Ｂでは、表示欄８５が表示され、表示欄８５内に、サーバ１１０による処理が行われていることを示すメッセージ８６が表示される。

サーバ１１０において、認証方法決定部３１６による処理が完了すると、端末１２０の表示は、画面８１Ｂから画面８１Ｃに遷移する。

画面８１Ｃは、認証の難度を高くするための認証情報として、パスコードが要求された場合を示している。

画面８１Ｃには、パスコードの入力欄８７と、メッセージ８８とが表示される。メッセージ８８では、事業者が提供しているＥＣサイトでの商品の購入の意志を、端末１２０のユーザに確認させる内容のメッセージである。

図９は、第１実施形態の端末１２０の表示例を説明する第二の図である。図９の例では、認証の難度を高くするための認証情報として、生体情報の一つである指紋情報が要求された場合を示している。図９に示す画面８１Ａと画面８１Ｂは、図８と同様であるから説明を省略する。

図９の画面８１Ｄでは、指紋情報の入力を要求する通知９１と、メッセージ９２とが表示される。メッセージ９２は、メッセージ８８と同様に、事業者が提供しているＥＣサイトでの商品の購入の意志を、端末１２０のユーザに確認させる内容のメッセージである。

本実施形態では、このように、決済を承認する際に、事業者の信用度に応じて、認証の難度を変更する。また、本実施形態では、認証の難度を上げるための認証情報をユーザに要求する際に、ユーザに対し、この事業者からの商品の購入の意志の再確認を促すメッセージを表示させる。

このため、本実施形態では、例えば、ユーザが、信用度の低い事業者から商品を購入しようとしていた場合などに、ユーザに対して商品の販売元に対する警戒を促すことができる。

したがって、本実施形態によれば、決済サービスの安全性を向上させるという効果が得られる。

なお、本実施形態では、事業者の信用度に応じて、複数種類の認証情報を要求するようにしてもよい。例えば、最初に、認証情報としてパスコードを要求し、パスコードによってユーザが認証されると、次に認証情報として指紋情報を要求し、指紋情報によってユーザが認証されると、次に認証情報として瞳の中の虹彩を示す情報を要求して認証を行う、というようにしてもよい。

また、本実施形態の機能を端末１２０に適用するか否かは、端末１２０のユーザによって設定されてもよい。具体的には、例えば、端末１２０のユーザが、事業者の信用度に応じた難度の認証を行うことを、サーバ１１０に対して設定することで、サーバ１１０は、上述した機能を端末１２０に対して適用してもよい。

端末１２０に対して、この設定が行われているか否かを示す情報は、例えば、ユーザ情報データベース３１４１のユーザ情報の一部とされてもよい。

この場合、サーバ１１０は、端末１２０から決済指示を受信した際に、決済指示と共に受信したユーザＩＤと対応するユーザ情報を参照し、事業者の信用度に応じた難度の認証を行うことが設定されていた場合に、認証方法決定部３１６によって端末１２０に要求する認証情報を決定してもよい。

また、本実施形態では、例えば、ユーザが、事業者の信用度に応じた難度の認証を行う設定をしていた場合には、決済に関して損害を受けた際の決済事業者による補償の内容を、この設定を行っていないユーザと異ならせてもよい。具体的には、この設定を行っていたユーザに対する補償金額が、この設定を行っていないユーザに対する補償金額よりも大きくなるようにしてもよい。

＜＜第１実施例＞＞
第１実施例は、認証方法決定部３１６が、ユーザの信用度と事業者の信用度に応じて決済を承認する際の認証方法を決定する実施例である。

＜＜第１実施例の効果＞＞
第１実施例によれば、ユーザの信用度と事業者の信用度に応じて認証方法を決定することで、決済サービスの安全性を向上させるという効果が得られる。

＜＜第１実施例の認証方法決定部３１６の処理＞＞
以下に、図１０を参照して、本実施形態の認証方法決定部３１６の処理について説明する。図１０は、第１実施形態の第１実施例の認証方法決定部の処理を説明するフローチャートである。図１０の処理は、図６のステップＳ６０６の詳細を示している。

サーバ１１０の認証方法決定部３１６は、端末１２０から決済指示を受け付けると、ユーザ情報データベース３１４１と事業者情報データベース３１４２とを参照し、端末１２０のユーザの信用度と、購入予定とされた商品を販売している事業者の信用度を参照する（ステップＳ１００１）。

続いて、認証方法決定部３１６は、ユーザの信用度と、事業者の信用度との差が閾値以上であるか否かを判定する（ステップＳ１００２）。

このとき、ユーザの信用度の方が、事業者の信用度よりも高くても良いし、事業者の信用度の方がユーザの信用度よりも高くても良い。この閾値は、予め、決済サービス事業者などによって決められていてもよい。

ステップＳ１００２において、２つの信用度の差が閾値未満である場合には、認証方法決定部３１６は、処理を終了する。

ステップＳ１００２において、２つの信用度の差が閾値以上である場合、認証方法決定部３１６は、決済の承認の際に、認証の難度を高くする認証情報を要求する（ステップＳ１００３）。

このように、本実施例では、ユーザの信用度と事業者の信用度とを参照する。したがって、例えば、ユーザの信用度が、事業者の信用度と比較して十分に高い場合などには、このユーザが端末１２０を用いて、ユーザと属性が異なる事業者の店舗で決済を行おうとしていることが推測できる。この場合、端末１２０が、端末１２０と紐付けられたユーザ以外の第三者に、不正に利用されようとしている可能性が考えられる。

本実施例では、このような場合には、端末１２０に対して、例えば、生体情報のような、認証の難度を上げる認証情報が要求されるため、第三者により、端末１２０を用いた不正な決済が行われることを抑制できる。

また、例えば、事業者の信用度が、ユーザの信用度と比較して十分に高い場合、事業者は、事業者の他のユーザとは属性の異なるユーザに商品を販売しようとしていることになる。この場合、事業者は、事業者が希望している客層とは異なる属性のユーザに対して商品を販売したり、サービスを提供したりすることになる。

本実施例では、このような場合には、端末１２０に対して認証の難度を上げる認証情報が要求されるため、ユーザにとっては決済の操作が煩雑となり、結果として事業者が希望していない客層のユーザを顧客とすることの回避に繋がる。

このように、本実施例によれば、信用度の低い事業者に対して、容易に決済が承認されることを抑制することができ、決済サービスの安全性を向上させることができる。

＜第２実施形態＞
第２実施形態は、端末１２０が他の端末１２０に送金する際に、送金先となるユーザの信用度に基づき、送金の認証方法を決定する実施形態である。

第２実施形態により、個人間の送金の安全性を向上させることができるという効果が得られる。

＜第２実施形態の動作処理＞
図１１は、第２実施形態に係る通信システムの処理のシーケンスの一例を示す。図１１では、端末１２０ＡのユーザＡから、端末１２０ＢのユーザＢに対して送金を行う場合を示している。

本実施形態において、サーバ１１０は、端末１２０Ａから、端末１２０Ｂへの送金要求を受け付けると、端末１２０Ａに送金画面の表示指示を送信し、端末１２０Ａは、表示指示に応じて、送金画面を表示させる（ステップＳ１１０１）。

続いて、端末１２０Ａは、ユーザにより、端末１２０ＢのユーザＢを特定する情報と送金金額の入力が行われ、送金指示の操作が行われると、送金指示をサーバ１１０に送信する（ステップＳ１１０２）。

なお、送金指示には、ユーザＢを特定する情報と、送金金額を示す情報とが含まれてよい。

サーバ１１０は、送金指示を受信すると、認証方法決定部３１６により、送金指示に含まれる、ユーザＢを特定する情報に基づき、ユーザＢの信用度を参照し、送金を承認する際の認証方法を決定する（ステップＳ１１０３）。ステップＳ１１０３の処理の詳細は後述する。

続いて、サーバ１１０は、承認する際の認証情報の取得要求を端末１２０Ａに送信する（ステップＳ１１０４）。端末１２０Ａは、この取得要求を受信すると、要求された認証情報を取得する（ステップＳ１１０５）。

図１１のステップＳ１１０５からステップＳ１１０７までの処理は、図６のステップＳ６０８からステップＳ６１０までの処理と同様であるから、説明を省略する。

サーバ１１０は、ステップＳ１１０７において、ユーザＡが認証されると、送金金額を端末１２０Ｂに送金し（ステップＳ１１０８）、送金完了通知を端末１２０Ａへ送信する（ステップＳ１１０９）。

続いて、サーバ１１０は、信用度更新部３２０により、ユーザＢの信用度を更新する（ステップＳ１１１０）。

本実施形態では、信用度更新部３２０は、送金先となるユーザＢの信用度を、送金元となるユーザＡの信用度に応じて更新してもよい。また、信用度更新部３２０は、送金先となるユーザＢの信用度を、受け取った送金金額や、送金を受ける回数に応じて更新してもよい。

例えば、信用度更新部３２０は、送金元のユーザＡの信用度が所定値以上であり、送金金額が一定額以上である場合に、送金先となるユーザＢの信用度が現在の信用度よりも高くするように、ユーザＢの信用度を更新してもよい。

また、信用度更新部３２０は、ユーザＢが、所定期間内に一定回数以上の送金を受けた場合や、ユーザＢが所定期間内に一定回数以上の送金指示をサーバ１１０に送信した場合にはユーザＢの挙動を不審な挙動と捉え、ユーザＢの信用度を下げるように更新しても良い。

また、信用度更新部３２０は、ユーザＢの購入履歴において、不正に利用されやすい特定の分類の商材の購入履歴が所定の割合以上であった場合には、ユーザＢの信用度を下げるようにしても良い。

このように、ユーザの信用度は、ユーザの商品の購入履歴を含む行動履歴に応じて決められてもよい。

また、例えば、信用度更新部３２０は、ユーザＢが、一定期間以内に所定の回数以上、送金サービスを利用した送金を受けた場合に、ユーザＢの信用度が現在の信用度よりも高くするように、ユーザＢの信用度を更新してもよい。

また、信用度更新部３２０は、例えば、ユーザＢが、信用度が所定値未満の事業者の店舗から商品を購入した場合に、ユーザＢの信用度を下げるように更新しても良い。

次に、図１２を参照して、第２実施形態の認証方法決定部３１６の処理について説明する。図１２は、第２実施形態の認証方法決定部の処理を説明するフローチャートである。図１２の処理は、図１１のステップＳ１１０３の詳細を示している。

サーバ１１０の認証方法決定部３１６は、端末１２０から送金指示を受け付けると、ユーザ情報データベース３１４１を参照し、送金先に指定されたユーザＢの信用度を参照する（ステップＳ１２０１）。

続いて、認証方法決定部３１６は、参照したユーザＢの信用度が、所定値以下であるか否かを判定する（ステップＳ１２０２）。この所定値は、予め、決済サービス事業者などによって決められていてもよい。

ステップＳ１２０２において、ユーザＢの信用度が所定値より大きい場合には、認証方法決定部３１６は、処理を終了する。

ステップＳ１２０２において、ユーザＢの信用度が所定値以下である場合、認証方法決定部３１６は、決済の承認の際に、認証の難度を高くする認証情報を要求する（ステップＳ１２０３）。

＜第２実施形態の端末１２０の表示態様＞
次に、図１３及び図１４を参照して、端末１２０の表示例について説明する。図１３は、第１実施形態の送金元となる端末の表示例を説明する第一の図である。

図１３に示す画面１３１Ａは、図１１のステップＳ１１０１で端末１２０Ａに表示される決済画面の一例を示す。

画面１３１Ａには、送金先となるユーザＢを特定する情報と、送金金額を示す情報とを含むメッセージ１３２が表示されている。

また、画面１３１Ａには、操作ボタン１３３が表示されており、操作ボタン１３３が操作されると、端末１２０Ａは、サーバ１１０に対して、ユーザＩＤと共に送金指示を送信し、画面１３１Ａを画面１３１Ｂに遷移させる。

画面１３１Ｂでは、サーバ１１０による処理が行われていることを示すメッセージ１３４が表示される。

サーバ１１０において、認証方法決定部３１６による処理が完了すると、端末１２０Ａの表示は、画面１３１Ｂから画面１３１Ｃに遷移する。

画面１３１Ｃは、認証の難度を高くするための認証情報として、パスコードが要求された場合を示している。

画面１３１Ｃには、パスコードの入力欄１３５と、メッセージ１３６が表示される。メッセージ１３６では、ユーザＢへの送金の意志を、端末１２０ＡのユーザＡに確認させる内容のメッセージである。

図１４は、第２実施形態の送金元となる端末の表示例を説明する第二の図である。図１４の例では、認証の難度を高くするための認証情報として、生体情報の一つである指紋情報が要求された場合を示している。図１４に示す画面１３１Ａと画面１３１Ｂは、図１３と同様であるから説明を省略する。

図１４の画面１３１Ｄでは、指紋情報の入力を要求する通知１４１と、メッセージ１４２とが表示される。メッセージ１４２は、ユーザＢへの送信の意志を、端末１２０ＡのユーザＡに確認させる内容のメッセージである。

本実施形態では、このように、ユーザ間での送金を承認する際に、送金先となるユーザＢの信用度に応じて、認証の難度を変更する。また、本実施形態では、認証の難度を上げるための認証情報をユーザＡに要求する際に、ユーザＡに対し、ユーザＢへの送金の意志の再確認を促すメッセージを表示させる。

このため、本実施形態では、例えば、ユーザＡが、信用度の低いユーザＢに送金をしようとしていた場合などに、ユーザＡに対して、送金することに対する警戒を促すことができる。

したがって、本実施形態によれば、決済サービスの安全性を向上させるという効果が得られる。

＜＜第１実施例＞＞
第１実施例は、認証方法決定部３１６が、送金元のユーザＡの信用度と、送金先のユーザＢの信用度とに応じて決済を承認する際の認証方法を決定する実施例である。

＜＜第１実施例の効果＞＞
第１実施例によれば、送金元のユーザＡの信用度と、送金先のユーザＢの信用度とに応じて決済を承認する際の認証方法を決定するため、決済サービスの安全性を向上させるという効果が得られる。

＜＜第１実施例の認証方法決定部３１６の処理＞＞
以下に、図１５を参照して、本実施形態の認証方法決定部３１６の処理について説明する。図１５は、第２実施形態の第１実施例の認証方法決定部の処理を説明するフローチャートである。図１５の処理は、図１１のステップＳ１１０３の詳細を示している。

サーバ１１０の認証方法決定部３１６は、端末１２０Ａから送金指示を受け付けると、ユーザ情報データベース３１４１を参照し、端末１２０ＡのユーザＡの信用度と、端末１２０ＢのユーザＢの信用度とを参照する（ステップＳ１５０１）。

続いて、認証方法決定部３１６は、ユーザＡの信用度と、ユーザＢの信用度との差が閾値以上であるか否かを判定する（ステップＳ１５０２）。

このとき、ユーザＡの信用度の方が、ユーザＢの信用度よりも高くても良いし、ユーザＢの信用度の方がユーザＡの信用度よりも高くても良い。この閾値は、予め、決済サービス事業者などによって決められていてもよい。

ステップＳ１５０２において、２つの信用度の差が閾値未満である場合には、認証方法決定部３１６は、処理を終了する。

ステップＳ１５０２において、２つの信用度の差が閾値以上である場合、認証方法決定部３１６は、決済の承認の際に、認証の難度を高くする認証情報を要求する（ステップＳ１５０３）。

このように、本実施例では、ユーザＡの信用度とユーザＢの信用度とを参照する。したがって、例えば、ユーザＡの信用度が、ユーザＢの信用度と比較して十分に高い場合などには、このユーザＡが端末１２０Ａを用いて、ユーザＡとは挙動が異なるユーザＢに送金を行おうとしていることになる。この場合、端末１２０Ａが、端末１２０と紐付けられたユーザＡ以外の第三者に、不正に利用されようとしている可能性が考えられる。

本実施例では、このような場合には、端末１２０Ａに対して、例えば、生体情報のような、認証の難度を上げる認証情報が要求されるため、第三者により、端末１２０Ａを用いた不正な送金が行われることを抑制できる。

１ 通信システム
１１０ サーバ
１２０ 端末
３１３、３２３ 制御部
３１４、３２４ 記憶部
３１５ 表示処理部
３１６ 認証方法決定部
３１７ 認証部
３１８ 決済部
３１９ 出力部
３２０ 信用度更新部
３１４１ ユーザ情報データベース
３１４２ 事業者情報データベース

Claims (11)

1. 情報処理装置に、
   ユーザが使用する情報処理端末から、代金の決済指示を受信する処理と、
   前記ユーザの信用度、および、前記代金の支払い先となる事業者の信用度の少なくとも１つに基づいて、決済を承認する際の前記ユーザの認証方法を決定する処理と、を実行させる情報処理方法。
2. 前記情報処理装置に、
   前記決済指示を受信後に、前記事業者の信用度を更新させる処理を、さらに実行させる、請求項１記載の情報処理方法。
3. 前記情報処理装置に、
   前記事業者に対して代金を支払うための決済指示を行ったユーザの信用度、前記代金、前記事業者が取り扱う商品の属性、前記事業者の評価の少なくとも何れかに基づき、前記事業者の信用度を決定させる処理を、さらに実行させる請求項１又は２記載の情報処理方法。
4. 前記決定する処理は、
   前記事業者の信用度が所定値以下である場合に前記認証方法を変更する、請求項１から３のいずれか一項に記載の情報処理方法。
5. 前記決定する処理は、
   前記ユーザの信用度と、前記事業者の信用度との差が閾値以上である場合に、前記認証方法を変更する、請求項１から４のいずれか一項に記載の情報処理方法。
6. 前記決定する処理は、
   前記決済を承認する際に、前記情報処理端末に対して認証情報の取得要求を行う手順を含める、請求項１から５のいずれか一項に記載の情報処理方法。
7. 前記決定する処理は、
   前記情報処理端末に対して要求する認証情報を、認証の難度を高くする認証情報に変更する、請求項１から６の何れか一項に記載の情報処理方法。
8. 前記情報処理装置に、
   前記決定する処理で決定された認証方法に応じた認証情報の入力を促す通知を前記情報処理端末に表示させる処理を、さらに実行させる、請求項１から７のいずれか一項に記載の情報処理方法。
9. 前記情報処理装置に、
   前記情報処理端末に、前記決済を行うか否かの確認を促す通知を表示させる処理を、さらに実行させる、請求項８記載の情報処理方法。
10. ユーザが使用する情報処理端末から代金の決済指示を受信する受信部と、
    前記ユーザの信用度、および、前記代金の支払い先となる事業者の信用度の少なくとも１つに基づいて、決済を承認する際の前記ユーザの認証方法を決定する認証方法決定部と、を有する情報処理装置。
11. 情報処理装置に、
    ユーザが使用する情報処理端末から、代金の決済指示を受信する処理と、
    前記ユーザの信用度、および、前記代金の支払い先となる事業者の信用度の少なくとも１つに基づいて、決済を承認する際の前記ユーザの認証方法を決定する処理と、を実行させるプログラム。

Images