特許 7457197 情報処理装置、情報処理方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2024-03-18

(45)【発行日】2024-03-27

(54)【発明の名称】情報処理装置、情報処理方法、およびプログラム

(51)【国際特許分類】

   G06F 21/34 20130101AFI20240319BHJP

   H04L 9/32 20060101ALI20240319BHJP

【ＦＩ】

G06F21/34

H04L9/32 100E

【請求項の数】 11

(21)【出願番号】P 2023198657

(22)【出願日】2023-11-22

【審査請求日】2023-11-22

【早期審査対象出願】

(73)【特許権者】

【識別番号】519110124

【氏名又は名称】ＰａｙＰａｙ株式会社

(74)【代理人】

【識別番号】100149548

【弁理士】

【氏名又は名称】松沼 泰史

(74)【代理人】

【識別番号】100154852

【弁理士】

【氏名又は名称】酒井 太一

(74)【代理人】

【識別番号】100181124

【弁理士】

【氏名又は名称】沖田 壮男

(74)【代理人】

【識別番号】100194087

【弁理士】

【氏名又は名称】渡辺 伸一

(72)【発明者】

【氏名】近藤 優里栄

(72)【発明者】

【氏名】清水 啓輔

(72)【発明者】

【氏名】友添 祐一朗

(72)【発明者】

【氏名】國島 美紗子

【審査官】行田 悦資

(56)【参考文献】

【文献】特開２０１３－１０９７３６（ＪＰ，Ａ）

【文献】特開２０２１－１３１７９２（ＪＰ，Ａ）

【文献】特開２００３－２０８４０７（ＪＰ，Ａ）

【文献】特開２０１１－１４１７４０（ＪＰ，Ａ）

【文献】特開２００３－０３１５０１（ＪＰ，Ａ）

【文献】特開２００７－０８００９２（ＪＰ，Ａ）

【文献】特開２００３－３３１２２１（ＪＰ，Ａ）

【文献】特開２０１３－１０１５１３（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／３４

Ｈ０４Ｌ ９／３２

(57)【特許請求の範囲】

【請求項1】

在留カードの券面に記載された処理対象の情報である券面情報と、
前記在留カードのＩＣチップに記憶された処理対象の情報であるＩＣ情報と、
端末装置を介して申告された処理対象の情報である申告情報と、を取得する取得部と、
前記申告情報と前記券面情報とが、第１合致要求度合で合致するか否かを判定する第１処理と、
前記券面情報と前記ＩＣ情報とが、第２合致要求度合で合致するか否かを判定する第２処理と、
前記申告情報と前記ＩＣ情報とが、第３合致要求度合で合致するか否かを判定する第３処理と、を実行し、
前記第１処理、前記第２処理、および前記第３処理の判定が肯定的である場合、対象者の本人確認を承認する処理部と、を備え、
前記第１合致要求度合は、少なくとも前記第２合致要求度合または前記第３合致要求度合とは異なる、
情報処理装置。

【請求項2】

前記第１合致要求度合は、前記第２合致要求度合および前記第３合致要求度合とは異なる、
請求項１に記載の情報処理装置。

【請求項3】

前記第１合致要求度合は、前記第２合致要求度合または前記第３合致要求度合よりも合致要求度合が高い、
請求項１に記載の情報処理装置。

【請求項4】

前記第１合致要求度合は、前記第２合致要求度合および前記第３合致要求度合よりも合致要求度合が高い、
請求項１に記載の情報処理装置。

【請求項5】

前記第１処理は、前記申告情報に含まれる対象の項目の情報と、前記券面情報に含まれる対象の項目の情報とが、前記第１合致要求度合で合致するか否かを判定する処理であり、
前記第２処理は、前記券面情報に含まれる対象の項目の情報と、前記ＩＣ情報に含まれる前記対象の項目の情報とが、前記第２合致要求度合で合致するか否かを判定する処理であり、
前記第３処理は、前記申告情報に含まれる対象の項目の情報と、前記ＩＣ情報に含まれる対象の項目の情報とが、前記第３合致要求度合で合致するか否かを判定する処理であり、
合致要求度合が高いとは、前記合致が判定される項目の数が多いことである、
請求項３または４に記載の情報処理装置。

【請求項6】

前記券面情報、前記ＩＣ情報、および前記申告情報のそれぞれは、対象者の住所、氏名、生年月日、国籍、在留資格、在留期限、および顔が撮像された画像のうち複数の情報を含む、
請求項５に記載の情報処理装置。

【請求項7】

前記在留カードとは異なる本人確認用の証明書を利用した本人確認のリクエストが送信された場合、
前記処理部は、前記在留カードを利用した対象者の本人確認を行う処理と異なる処理を実行して、前記対象者の本人確認を行う、
請求項１から４のうちいずれか１項に記載の情報処理装置。

【請求項8】

前記異なる処理は、前記在留カードを利用した前記本人確認を行う処理よりも、前記処理部の処理負荷が小さい処理である、
請求項７に記載の情報処理装置。

【請求項9】

前記在留カードとは異なる本人確認用の証明書を利用した本人確認のリクエストが送信された場合、（１）または（２）の処理が実行され、
前記（１）は、
前記取得部が、
前記異なる本人確認用の証明書の券面に記載された処理対象の情報である券面情報と、
端末装置を介して申告された処理対象の情報である申告情報と、を取得し、
前記処理部が、前記申告情報と前記券面情報との合致を判定する処理であり、
前記（２）は、
前記取得部が、
前記異なる本人確認用の証明書のＩＣチップに記憶された処理対象の情報であるＩＣ情報と、
端末装置を介して申告された処理対象の情報である申告情報と、を取得し、
前記処理部が、前記申告情報と前記ＩＣ情報との合致を判定する処理である、
請求項８に記載の情報処理装置。

【請求項10】

コンピュータが、
在留カードの券面に記載された処理対象の情報である券面情報と、
前記在留カードのＩＣチップに記憶された処理対象の情報であるＩＣ情報と、
端末装置を介して申告された処理対象の情報である申告情報と、を取得し、
前記申告情報と前記券面情報とが、第１合致要求度合で合致するか否かを判定する第１処理と、
前記券面情報と前記ＩＣ情報とが、第２合致要求度合で合致するか否かを判定する第２処理と、
前記申告情報と前記ＩＣ情報とが、第３合致要求度合で合致するか否かを判定する第３処理と、を実行し、
前記第１処理、前記第２処理、および前記第３処理の判定が肯定的である場合、対象者の本人確認を承認し、
前記第１合致要求度合は、少なくとも前記第２合致要求度合または前記第３合致要求度合とは異なる、
情報処理方法。

【請求項11】

コンピュータに、
在留カードの券面に記載された処理対象の情報である券面情報と、
前記在留カードのＩＣチップに記憶された処理対象の情報であるＩＣ情報と、
端末装置を介して申告された処理対象の情報である申告情報と、を取得させる処理と、
前記申告情報と前記券面情報とが、第１合致要求度合で合致するか否かを判定する第１処理と、
前記券面情報と前記ＩＣ情報とが、第２合致要求度合で合致するか否かを判定する第２処理と、
前記申告情報と前記ＩＣ情報とが、第３合致要求度合で合致するか否かを判定する第３処理と、
前記第１処理、前記第２処理、および前記第３処理の判定が肯定的である場合、対象者の本人確認を承認する処理と、を実行させ、
前記第１合致要求度合は、少なくとも前記第２合致要求度合または前記第３合致要求度合とは異なる、
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置、情報処理方法、およびプログラムに関する。

【背景技術】

【0002】

従来、在留カードに記憶された在留カード情報の読み取りが完了した場合、自装置の撮影機能を起動して、ユーザを含む撮影画像を撮影し、読み取った在留カード情報に含まれる顔画像と、撮影した撮影画像とに基づいて、顔照合処理を行う情報処理装置が開示されている（例えば特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０２１－１４４６５７号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

従来の技術では、精度よく本人確認を行うことができない場合があった。

【0005】

本発明は、このような事情を考慮してなされたものであり、より精度よく本人確認を行うことができる情報処理装置、情報処理方法、およびプログラムを提供することを目的の一つとする。

【課題を解決するための手段】

【0006】

本発明の一態様は、在留カードの券面に記載された処理対象の情報である券面情報と、前記在留カードのＩＣチップに記憶された処理対象の情報であるＩＣ情報と、端末装置を介して申告された処理対象の情報である申告情報と、を取得する取得部と、前記申告情報と前記券面情報とが、第１合致要求度合で合致するか否かを判定する第１処理と、前記券面情報と前記ＩＣ情報とが、第２合致要求度合で合致するか否かを判定する第２処理と、前記申告情報と前記ＩＣ情報とが、第３合致要求度合で合致するか否かを判定する第３処理と、を実行し、前記第１処理、前記第２処理、および前記第３処理の判定が肯定的である場合、対象者の本人確認を承認する処理部と、を備え、前記第１合致要求度合は、少なくとも前記第２合致要求度合または前記第３合致要求度合とは異なる情報処理装置である。

【発明の効果】

【0007】

本発明の一態様によれば、より精度よく本人確認を行うことができる。

【図面の簡単な説明】

【0008】

【図1】電子決済サービスが実現されるための構成の一例を示す図である。

【図2】電子決済の大まかな流れを例示したシーケンス図（その１）である。

【図3】電子決済の大まかな流れを例示したシーケンス図（その２）である。

【図4】実施形態に係る決済サーバ１００の構成図である。

【図5】利用者情報１７２の内容の一例を示す図である。

【図6】加盟店／店舗情報１７６の内容の一例を示す図である。

【図7】申告情報、券面情報、およびＩＣ情報を含む確認情報１７８の内容の一例を示す図である。

【図8】決済サーバ１００により実行される処理の流れの一例を示すフローチャートである。

【図9】上記のＳ１０６およびＳ１０８の処理の詳細について説明するための図である。

【図10】合致要求度合について説明するための図である。

【図11】変形例の処理部１５０が実行する処理の流れの一例を示すフローチャートである。

【図12】特定処理（１）について説明するための図である。

【図13】特定処理（２）について説明するための図である。

【発明を実施するための形態】

【0009】

以下、図面を参照し、本発明の情報処理装置、情報処理方法、およびプログラムの実施形態について説明する。以下に登場する「決済サーバ（情報処理装置）」などの、利用者にサービスを提供したり内部解析を行ったりするための各種装置は、分散化された装置群によって実現されてよく、それぞれの装置を運用する事業者は異なってもよい。また装置のハードウェアの保有者（クラウドサーバの提供者）と実質的な運用を行う事業者も異なってよい。アプリケーションプログラムと決済サーバは、協働して電子決済サービスを提供する。以下の説明ではアプリケーションプログラムを決済アプリと称する。電子決済サービスは、店舗における商品やサービスの購買に係る決済をサポートするサービスである。店舗とは、例えば、現実空間に存在する物理的な店舗（実店舗）であるが、電子商取引の仮想店舗を含んでもよい。仮想店舗は、電子決済サービスの運営者とは異なる主体によって提供されるものを含んでもよい。その場合、仮想店舗における買い物の決済の際に、電子決済サービスのインターフェース画面に遷移するように制御される。電子決済サービスにおいて、店舗は、例えば加盟店（ブランド）に属するものとして扱われ、店舗において購買行動が行われた際の決済などの処理は、主として利用者と加盟店の間で行われる。これに代えて、決済などの処理が利用者と店舗との間で行われてもよい。

【0010】

［電子決済サービス］
図１は、電子決済サービスが実現されるための構成の一例を示す図である。電子決済サービスは、決済サーバ１００を中心として実現される。決済サーバ１００は、例えば、一以上の利用者端末装置１０、一以上の第１店舗端末装置５０、一以上の第２店舗端末装置７０のそれぞれとネットワークＮＷを介して通信する。ネットワークＮＷは、例えば、インターネット、ＬＡＮ（Local Area Network）、無線基地局、プロバイダ装置などを含む。

【0011】

［利用者端末装置］
利用者端末装置１０は、例えば、スマートフォンやタブレット端末等の可搬型端末装置である。利用者端末装置１０は、少なくとも、光学読取機能、通信機能、表示機能、入力受付機能、プログラム実行機能を有するコンピュータ装置である。以下の説明では、これらの機能を実現するための構成をそれぞれカメラ、通信装置、タッチパネル、ＣＰＵ（Central Processing Unit）等と称する。利用者端末装置１０では、ＣＰＵ等のプロセッサにより決済アプリ２０が実行されることで、決済サーバ１００と連携して電子決済サービスを利用者に提供するように動作する。決済アプリ２０は、例えば、アプリケーションストアから利用者端末装置１０にインストールされ、カメラ、通信装置、タッチパネルなどを制御する。

【0012】

［第１店舗端末装置］
第１店舗端末装置５０は、例えば、店舗に設置される。第１店舗端末装置５０は、少なくとも、商品価格取得機能、光学読取機能、プログラム実行機能、通信機能を有するコンピュータ装置である。第１店舗端末装置５０は、いわゆるＰＯＳ（Point of Sale）装置を含み、ＰＯＳ装置によって商品価格取得機能や光学読取機能を実現してもよい。店舗コード画像６０は、店舗に置かれ、ＱＲコード（登録商標）等のコード画像が紙やプラスチックの媒体に印刷されたものである。なお、店舗コード画像６０は、店舗に置かれたディスプレイ（スマートフォンなどの端末装置のディスプレイでもよい）によって表示されてもよい。

【0013】

［第２店舗端末装置］
第２店舗端末装置７０は、加盟店の運営者によって使用される。第２店舗端末装置７０は、スマートフォンやタブレット端末、パーソナルコンピュータ等である。第２店舗端末装置７０では、加盟店向けインターフェース７２が動作する。加盟店向けインターフェース７２は、加盟店向けアプリであってもよいし、ブラウザであってもよい。加盟店向けインターフェース７２は、加盟店の運営者によるクーポンの設定等を受け付け、決済サーバ１００に送信する。スマートフォンである第２店舗端末装置７０は、加盟店向けアプリを実行することで、店舗コード画像に相当するコード画像を表示したり、利用者端末装置１０が表示するコード画像を読み取ったりする機能を有する。

【0014】

決済サーバ１００は、利用者端末装置１０、第１店舗端末装置５０、または加盟店サーバ３００から受信した決済情報に基づいて電子決済を実現する。第１店舗端末装置５０は、ＰＯＳ装置を含む場合があり、その場合、ＰＯＳ装置から加盟店サーバを介して決済情報が決済サーバ１００に送信される。

【0015】

図２および図３は、電子決済の大まかな流れを例示したシーケンス図である。電子決済には、パターン１とパターン２の二つが存在してよい。

【0016】

図２に示すパターン１（以下、ユーザスキャンと称する）の場合、決済アプリ２０が起動した状態の利用者端末装置１０が、光学読取機能によって店舗コード画像６０をデコードする（Ｓ１）。店舗コード画像６０には、店舗ＵＲＬ（Uniform Resource Locator）の情報が含まれている。この店舗ＵＲＬは、電子決済サービスのドメインに対して店舗を識別可能な情報が付加されたものであり、決済サーバ１００において加盟店ＩＤや店舗ＩＤ等との対応付けがなされている（後述）。決済アプリ２０は、店舗ＵＲＬとアカウントＩＤを含む第１決済情報を決済サーバ１００に送信する（Ｓ２）。決済サーバ１００は、店舗ＵＲＬに対応する加盟店ＩＤ、店舗ＩＤから、店舗情報（後述）を検索して加盟店名と店舗名の情報を取得し（Ｓ３）、決済アプリ２０に送信する（Ｓ４）。利用者は、加盟店名や店舗名が表示された画面において、決済金額を利用者端末装置１０に入力する（Ｓ５）。そして、利用者端末装置１０は、少なくとも決済金額を含む第２決済情報を生成し、決済サーバ１００に送信する（Ｓ６）。決済サーバ１００は、受信した第２決済情報に基づいて電子決済を行う（Ｓ７）。そして、決済サーバ１００は、決済完了通知（決済完了画面を表示するための情報）を決済アプリ２０に送信し（Ｓ８）、決済アプリ２０は決済完了画面を表示する（Ｓ９）。なお、店舗コード画像６０が店舗に置かれたディスプレイによって表示される場合、店舗コード画像６０には、店舗ＵＲＬだけでなく決済金額の情報が含まれる場合がある。この場合、利用者が決済金額を入力する手順が省略され、第１決済情報に決済金額の情報が含められて決済サーバ１００に送信される。加盟店名や店舗名の情報は、決済完了画面に含めて表示されてよい。

【0017】

図３に示すパターン２（以下、ストアスキャンと称する）の場合、決済アプリ２０の起動時、決済アプリ２０において支払う操作が行われたとき、自動更新のタイミング（例えば１分おき）になったとき、およびその他のタイミングで、決済アプリ２０はワンタイムコードの発行要求を決済サーバ１００に送信する（Ｓ１１）。決済サーバ１００はワンタイムコードを生成し（Ｓ１２）、決済アプリ２０に送信する（Ｓ１３）。決済アプリ２０は、ワンタイムコードに基づいて生成した、ＱＲコードやバーコード等のコード画像を表示する（Ｓ１４）。利用者は利用者端末装置１０の表示面を第１店舗端末装置５０に翳し（提示し）、第１店舗端末装置５０は、光学読取機能によってコード画像をデコードし、ワンタイムコード等を取得する（Ｓ１５）。そして、第１店舗端末装置５０は、ワンタイムコード、決済金額、加盟店ＩＤ、店舗ＩＤ等を含む決済情報を生成し、決済サーバ１００に送信する（Ｓ１６）。決済金額の情報は、予めバーコード読み取りや手入力等によって取得されている。決済サーバ１００は、受信した情報に基づいて、ワンタイムコードに対応する利用者を特定し、電子決済を行う（Ｓ１７）。そして、決済サーバ１００は、決済完了通知を決済アプリ２０に送信し（Ｓ１８）、決済アプリ２０は決済完了画面を表示する（Ｓ１９）。

【0018】

なお、上記のいずれか一方のみのパターンで電子決済が行われてもよい。また、図２で説明した「アカウントＩＤ」は、利用者を識別するための識別情報として用いられ得る他の情報（例えば電話番号）であってもよい。また、ストアスキャンにおいてワンタイムコードの発行が省略され、決済アプリ２０は、利用者のアカウントＩＤに基づいて生成したコード画像を表示してもよい。その場合、決済サーバ１００は、ワンタイムコードに対応する利用者を特定するのに代えて、アカウントＩＤに対応する利用者を特定する。

【0019】

［決済サーバ］
図４は、実施形態に係る決済サーバ１００の構成図である。決済サーバ１００は、例えば、通信部１１０と、コンテンツ提供部１２０と、決済処理部１３０と、情報管理部１４０と、処理部１５０と、記憶部１７０とを備える。通信部１１０および記憶部１７０以外の構成要素は、例えば、ＣＰＵなどのハードウェアプロセッサがプログラム（ソフトウェア）を実行することにより実現される。これらの構成要素のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）、ＧＰＵ（Graphics Processing Unit）、ＳＯＣ（System On Chip）などのハードウェア（回路部；circuitryを含む）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。プログラムは、予めＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの記憶装置（非一過性の記憶媒体を備える記憶装置）に格納されていてもよいし、ＤＶＤやＣＤ－ＲＯＭなどの着脱可能な記憶媒体（非一過性の記憶媒体）に格納されており、記憶媒体がドライブ装置に装着されることで記憶装置にインストールされてもよい。情報管理部１４０は「取得部」の一例である。

【0020】

記憶部１７０は、ＨＤＤやフラッシュメモリ、ＲＡＭ（Random Access Memory）などである。記憶部１７０は、決済サーバ１００がネットワークを介してアクセス可能なＮＡＳ（Network Attached Storage）装置であってもよい。記憶部１７０には、利用者情報１７２、コンテンツ情報１７４、加盟店／店舗情報１７６、確認情報１７８などの情報が格納される。

【0021】

通信部１１０は、ネットワークＮＷに接続するための通信インターフェースである。通信部１１０は、例えばネットワークインターフェースカードである。

【0022】

コンテンツ提供部１２０は、例えば、Ｗｅｂサーバの機能を有し、電子決済サービスの各種画面を表示するための情報（コンテンツ）を利用者端末装置１０に提供する。コンテンツ提供部１２０は、コンテンツ情報１７４から適宜、必要なコンテンツを読み出して利用者端末装置１０に提供する。利用者端末装置１０は、決済アプリ２０によってコンテンツが再生された状態で利用者による各種入力を受け付け、前述した決済情報などを決済サーバ１００に送信する。上記のように、コンテンツ提供部１２０と、決済アプリ２０とは協働して利用者端末装置１０の表示部に電子決済サービスに係るコンテンツを表示させる。

【0023】

決済処理部１３０は、利用者端末装置１０または第１店舗端末装置５０により送信された決済情報に基づいて、決済処理を行う。決済処理部１３０は、利用者情報１７２を参照しながら決済処理を行う。

【0024】

図５は、利用者情報１７２の内容の一例を示す図である。利用者情報１７２は、利用者の登録情報の一例である。利用者情報１７２は、例えば、利用者ＵＲＬ、アカウントＩＤ、電話番号、パスワードの他、メールアドレス、利用者ＩＤ、氏名・住所・生年月日、登録日、チャージ残高、後払い設定、後払い枠、後払い利用額、後払い利用可能額、決済方法設定、銀行口座、クレジットカード番号、チャージ履歴情報、決済履歴情報、ｅＫＹＣ情報（electronic Know Your Customer情報）などの情報が対応付けられたものである。利用者ＵＲＬは、利用者間の送金処理に使用される。電子決済サービスへの新規登録時には、電話番号およびパスワードの登録が必須となる。アカウントＩＤは、決済サーバ１００によって利用者に発行されるものであり、利用者ＩＤは、利用者が任意に設定できる（設定しなくてもよい）ＩＤである。メールアドレス、および氏名・住所・生年月日も同様に、利用者が任意に設定できる（設定しなくてもよい）情報である。登録日とは利用者が電子決済サービスに登録した日（アカウントを作成した日）である。以下、これらの情報が対応付けられた利用者のインスタンス（電子決済口座）のことをアカウントと称する。

【0025】

チャージ残高は、利用者が予めアカウントに送金することで設定された電子マネーの残高を示す情報である。送金の手段としては、指定業者（銀行）のＡＴＭ（Automatic Teller Machine）からの送金、登録された銀行口座からの送金などがある。後払い設定は、後払いによる電子決済を可能とするための設定が済んでいるか否かを示す情報であり、「済」と「未」のいずれかに設定される。後払い枠は月ごとに利用可能な後払いの限度額であり、後払い利用額は、当月に既に利用された後払いの金額であり、後払い利用可能額は、後払い枠から後払い利用額を差し引いて求められる、当月に利用可能な後払いの金額である。図では後払い枠を一つだけ示しているが、実際には更に日ごとの上限額などが存在し、それらの低い方が後払い枠に設定されてよい。後払いの更なる詳細については後述する。決済方法設定は、その時点において利用者がチャージ残高による電子決済を行うのか、後払いによる決済を行うのかを示す設定情報である。銀行口座とクレジットカード番号のそれぞれは、電子決済サービスに入金可能な銀行口座またはクレジットカード番号の情報（口座番号、カード番号）である。チャージ履歴情報は、利用者が予め電子決済サービスに送金してチャージ残高を増加させた履歴である。決済履歴情報は、利用者が行った決済の内訳（日時、購買行動が行われた店舗の店舗ＩＤ、決済金額、決済方法など）を、決済ごとに示す情報である。

【0026】

ｅＫＹＣ情報は、利用者が本人確認済であるか否かを示す情報である。本人確認は、処理部１５０の処理結果に基づいて生成される情報である。処理部１５０が、本人確認を承認した場合に、対象の利用者に対する本人確認は「済」となる。本人確認が済である利用者は、本人確認が「未」の利用者が利用することができないサービスを利用することができる。サービスとは、電子決済サービスにおいて提供されているサービスである。例えば、本人確認済の利用者は、電子決済サービスを利用可能な加盟店が拡大したり、銀行口座からの出金が可能になったり、クレジット払い（後払い）の限度額が拡大したりする。

【0027】

図６は、加盟店／店舗情報１７６の内容の一例を示す図である。加盟店／店舗情報１７６は、例えば、店舗ＵＲＬに対して加盟店ＩＤと店舗ＩＤが対応付けられた第１テーブル１７６Ａと、加盟店ＩＤに対して加盟店名と売上金（前述）が対応付けられた第２テーブル１７６Ｂと、店舗ＩＤに対して店舗名が対応付けられた第３テーブル１７６Ｃとを含む。加盟店／店舗情報１７６には、これらの情報の他、加盟店または店舗のカテゴリ、店舗の所在地、決済パターン等の情報が含まれてもよい。

【0028】

情報管理部１４０は、利用者端末装置１０や第２店舗端末装置７０から取得した情報に基づいて、利用者情報１７２および加盟店／店舗情報１７６を管理する。情報管理部１４０は、利用者情報１７２および加盟店／店舗情報１７６について新規レコードの追加、編集、削除などを行う。

【0029】

情報管理部１４０は、利用者端末装置１０を介して利用者が入力した情報を取得したり、利用者端末装置１０が取得した情報を取得したりする。情報管理部１４０は、例えば、在留カードの券面に記載された処理対象の情報である券面情報や、在留カードのＩＣチップに記憶された処理対象の情報であるＩＣ情報、利用者端末装置１０を介して申告された処理対象の情報である申告情報などを取得する。これらの情報の詳細については後述する。

【0030】

［電子決済］
決済処理部１３０は、利用者端末装置１０または第１店舗端末装置５０から決済情報が取得されると、利用者情報１７２を参照して当該利用者の「決済方法設定」を取得する。決済処理部１３０は、「決済方法設定」が「チャージ残高」に設定されている利用者に関して、以下のように電子決済を行う。決済処理部１３０は、例えば、利用者ＩＤに対応付けて管理しているチャージ残高を減少させ、加盟店の売上金の項目値を増加させることで、電子決済を行う。加盟店の売上金の項目値は、例えば、それ自体が電子マネーとして使用されるものでは無く、加盟店と電子決済サービスとの取り決めに応じたサイクルで、売上金の項目値に対応する金額が銀行口座に送金される。

【0031】

決済処理部１３０は、「設定情報」が「後払い」に設定されている利用者に関して、以下のように電子決済を行う。後払いとは、電子決済サービスの運営者とは別主体であるクレジットカード会社との連携による「クレジット払い」とは別枠で設定されるものであり、電子決済サービスの運営者が与信者となって、後払い枠の範囲内でチャージ残高に依存しない電子決済を許容するものである。なお後払いサービスを受けるために、電子決済サービスの運営者が提供するクレジットカードの取得が要求されてよい。後払いで利用された金額は、一か月分まとめて翌月の支払日に、例えば銀行口座からの引き落としによって決済される。この場合、決済処理部１３０は、後払い利用額に決済金額を加算し、後払い利用可能額から同額を差し引くことで暫定決済を行い、締め日になると上記のように当月分の決済を翌月の支払い日に引き落とすための処理を行う、或いはクレジットカード会社の運営者に当該処理を依頼する。なお暫定決済の時点で決済金額が後払い利用可能額を超える場合は、エラー通知が決済アプリ２０に返信される。

【0032】

［処理部］
処理部１５０は、第１処理、第２処理、および第３処理を実行する。第１処理は、申告情報と券面情報とが、第１合致要求度合で合致するか否かを判定する処理である。第２処理は、券面情報とＩＣ情報とが、第２合致要求度合で合致するか否かを判定する処理である。第３処理は、申告情報とＩＣ情報とが、第３合致要求度合で合致するか否かを判定する処理である。処理部１５０は、第１処理、第２処理、および第３処理の判定が肯定的である場合、対象者の本人確認を承認する。この場合、利用者情報１７２のｅＫＹＣ情報が「済」となる。第１合致要求度合は、少なくとも第２合致要求度合または第３合致要求度合とは異なる。

【0033】

図７は、申告情報、券面情報、およびＩＣ情報を含む確認情報１７８の内容の一例を示す図である。申告情報は、利用者が本人確認のためのインターフェース画面において入力した情報である。券面情報は、利用者が本人確認のための処理において利用者端末装置１０の撮像部を利用して撮像した在留カードの券面を撮像した情報に基づいて得られた情報である。例えば、情報管理部１４０が、画像認識処理（例えばＯＣＲ：Optical Character Recognition/Reader）を実行して画像から券面情報に記載された項目および項目に対応する情報を取得する。ＩＣ情報は、在留カードのＩＣチップに記憶された情報であって利用者端末装置１０がＩＣチップと通信して得た情報である。決済サーバ１００は、利用者端末装置１０を介して申告情報、券面情報、およびＩＣ情報を取得する。

【0034】

申告情報、券面情報、およびＩＣ情報は、例えば、住所、氏名、生年月日、国籍、在留資格、在留期限、および顔が撮像された画像の一部または全部を含む。申告情報の顔が撮像された画像は、利用者が撮像部を利用して撮像した画像である。この画像は、インターフェース画面に表示されたモーション指示に対応する動作に応じた顔の画像である。例えば、決済サーバ１００は、正面を向いていた顔の画像や、斜め横を向いた顔の画像などを申請者に撮像させて、撮像させた画像を提供させる。決済サーバ１００において、モーション指示に応じた画像が撮像されているかが判定される。指示に応じた画像が提供されない場合、本人確認は否定される。

【0035】

［フローチャート］
図８は、決済サーバ１００により実行される処理の流れの一例を示すフローチャートである。まず、情報管理部１４０は、申告情報、券面情報、およびＩＣ情報を利用者端末装置１０から取得する（Ｓ１００、Ｓ１０２、Ｓ１０４）。申告情報、券面情報、ＩＣ情報が取得される順番は任意の順番であってもよい。次に、処理部１５０は、取得した３つの情報をそれぞれ比較して（Ｓ１０６）、情報が合致するか否かを判定する（Ｓ１０８）。上記の３つの情報の比較は任意の順番であってもよい。例えば、処理部１５０は、３つの情報の対応する項目の情報同士を突合して、情報が合致するか否かを判定する。

【0036】

情報が合致する場合、処理部１５０は、ｅＫＹＣ完了の処理に進む（Ｓ１１０）。処理部１５０は、例えば、ｅＫＹＣを完了するための処理に進んだり、ｅＫＹＣの完了させるためのインターフェース画面をコンテンツ提供部１２０に提供させたりする。情報が合致しない場合、処理部１５０は、利用者端末装置１０を介してｅＫＹＣが完了できないことを利用者に通知する（Ｓ１１２）。処理部１５０は、例えば、ｅＫＹＣを完了できないことを示すインターフェース画面をコンテンツ提供部１２０に提供させる。これにより、本フローチャートの１ルーチンの処理が終了する。

【0037】

図９は、上記のＳ１０６およびＳ１０８の処理の詳細について説明するための図である。処理部１５０は、申告情報の項目の情報と、券面情報の項目の情報とを比較して、合致するか否かを判定する。比較は、対応する項目の情報同士が比較される。合致とは、完全に同一でなくてもよく、一部が一致または所定の度合以上一致していることである（以下の合致についても同様である）。

【0038】

処理部１５０は、券面情報の項目の情報と、ＩＣ情報の項目の情報とを比較して、合致するか否かを判定する。処理部１５０は、申告情報の項目の情報と、ＩＣ情報の項目の情報とを比較して、合致するか否かを判定する。

【0039】

申告情報と券面情報との合致要求度合は第１合致要求度合であり、券面情報とＩＣ情報との合致要求度合は第２合致要求度合であり、申告情報とＩＣ情報との合致要求度合は第３合致要求度合である。例えば、第１合致要求度合は、第２合致要求度合および第３合致要求度合とは異なる合致要求度合である。どの合致要求度合が高いかは任意に設定されてもよい。合致要求度合が高いとは、合致が求められる要求の度合が高いことである。例えば、第１合致要求度合は、第２合致要求度合または第３合致要求度合よりも高い合致要求度合である。例えば、第１合致要求度合は、第２合致要求度合および第３合致要求度合よりも高い合致要求度合である。

【0040】

処理部１５０は、申告情報に含まれる対象の項目の情報と、券面情報に含まれる対象の項目の情報とが、第１合致要求度合で合致するか否かを判定する。処理部１５０は、券面情報に含まれる対象の項目の情報と、ＩＣ情報に含まれる対象の項目の情報とが、第２合致要求度合で合致するか否かを判定する。処理部１５０は、申告情報に含まれる対象の項目の情報と、ＩＣ情報に含まれる対象の項目の情報とが、第３合致要求度合で合致するか否かを判定する。合致要求度合が高いとは、合致が判定される項目の数が多いことである。

【0041】

図１０は、合致要求度合について説明するための図である。例えば、申告情報と券面情報とに対応する第１合致要求度合は、券面情報とＩＣ情報とに対応する第２合致要求度合よりも要求度合が高い。第１合致要求度合では、第２合致要求度合よりも、より多くの項目の情報同士の合致が要求される。

【0042】

上記の処理において、処理部１５０は、公知の手法を用いて複数の画像のそれぞれの顔が合致するか否かを判定する。例えば、処理部１５０は、画像の顔の特徴量を抽出し、抽出した特徴量同士を比較して画像における顔が合致するか否かを判定する。

【0043】

例えば、上述した申告情報、券面情報、およびＩＣ情報のうち一部は諸々の事情により、正しい情報でない場合がある。このような事情が存在する場合、合致要求度合を同一にしてしまうと、本来、スムーズに本人確認を承認することができるはずなのに、不備として扱われ、本人確認が否定されてしまうことがある。本実施形態では、上記のように処理部１５０が、対象の情報を比較する際に、比較する情報に応じた合致要求度合を利用することで、スムーズ、精度よく、且つ簡易に本人確認を行うことができる。

【0044】

以上説明した実施形態によれば、処理部１５０は、３つの情報を利用することで、より精度よく本人確認を行うことができる。更に、処理部１５０は、比較する情報に応じた合致要求度合に基づいて本人確認の判定を行うため、より簡易に本人確認の判定を行うことができる。

【0045】

＜変形例＞
上述した実施形態では、在留カードを対象としてが、変形例では、これに加えて（または代えて）、他の本人確認のための証明書が対象となる。以下、上述した実施形態との相違点を中心に説明する。

【0046】

在留カードとは異なる本人確認用の証明書を利用した本人確認のリクエストが送信された場合、処理部１５０は、在留カードを利用した対象者の本人確認を行う処理と異なる処理を実行して、対象者の本人確認を行う。異なる処理は、在留カードを利用した本人確認を行う処理よりも、処理部１５０の処理負荷が小さい処理である。

【0047】

処理部１５０は、在留カードとは異なる本人確認用の証明書を利用した本人確認のリクエストが送信された場合、（１）または（２）の処理を実行する。（１）は、情報管理部１４０が、異なる本人確認用の証明書の券面に記載された処理対象の情報である券面情報と、利用者端末装置１０を介して申告された処理対象の情報である申告情報と、を取得し、処理部１５０が、申告情報と前記券面情報との合致を判定する処理である。

【0048】

（２）は、情報管理部１４０が、異なる本人確認用の証明書のＩＣチップに記憶された処理対象の情報であるＩＣ情報と、利用者端末装置１０を介して申告された処理対象の情報である申告情報と、を取得し、処理部１５０が、申告情報とＩＣ情報との合致を判定する処理である。

【0049】

［フローチャート］
図１１は、変形例の処理部１５０が実行する処理の流れの一例を示すフローチャートである。まず、処理部１５０は、本人確認のためのインターフェース画面において、利用者が本人確認のための証明書として、在留カードを選択したか否かを判定する（Ｓ２００）。在留カードが選択された場合、処理部１５０は、前述した図８のＳ１００－Ｓ１１２の処理を実行する（Ｓ２０２）。在留カードとは異なる証明書を選択した場合、処理部１５０は、選択された証明書に応じた特定処理を実行する（Ｓ２０４）。特定処理については、後述する図１１および図１２を参照して説明する。これにより本フローチャートの１ルーチンの処理が終了する。

【0050】

図１２は、特定処理（１）について説明するための図である。例えば、本人確認のための証明書が、運転免許証またはマイナンバーカードである場合、処理部１５０は、申告情報と券面情報との合致度合が、第４合致要求度合である場合、本人確認の承認を行う。第４合致要求度合は、第１合致要求度合、第２合致要求度合、第３合致要求度合とは異なる合致要求度合であってもよいし、いずれかの合致要求度合と同様であってもよい。

【0051】

図１３は、特定処理（２）について説明するための図である。例えば、本人確認のための証明書が、運転免許証またはマイナンバーカードである場合、処理部１５０は、券面情報とＩＣ情報との合致度合が、第５合致要求度合である場合、本人確認の承認を行ってもよい。第５合致要求度合は、第４合致要求度合と同様であってもよいし、異なっていてもよい。第５合致要求度合は、第１合致要求度合、第２合致要求度合、第３合致要求度合とは異なる合致要求度合であってもよいし、いずれかの合致要求度合と同様であってもよい。

【0052】

以上説明した変形例によれば、処理部１５０が、本人確認のための利用する証明書の種別に応じた判定を行うため、簡易且つより精度よく本人確認を実施することができる。

【0053】

以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

【符号の説明】

【0054】

１０ 利用者端末装置
２０ 決済アプリ
１００ 決済サーバ
１２０ コンテンツ提供部
１３０ 決済処理部
１４０ 情報管理部
１５０ 処理部
１７８ 確認情報

【要約】

【課題】より精度よく本人確認を行うこと。
【解決手段】在留カードの券面に記載された処理対象の情報である券面情報と、前記在留カードのＩＣチップに記憶された処理対象の情報であるＩＣ情報と、端末装置を介して申告された処理対象の情報である申告情報と、を取得する取得部と、前記申告情報と前記券面情報とが、第１合致要求度合で合致するか否かを判定する第１処理と、前記券面情報と前記ＩＣ情報とが、第２合致要求度合で合致するか否かを判定する第２処理と、前記申告情報と前記ＩＣ情報とが、第３合致要求度合で合致するか否かを判定する第３処理と、を実行し、前記第１処理、前記第２処理、および前記第３処理の判定が肯定的である場合、対象者の本人確認を承認する処理部と、を備え、前記第１合致要求度合は、少なくとも前記第２合致要求度合または前記第３合致要求度合とは異なる情報処理装置である。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】