JP7490131B1 - 本人確認支援システム及びプログラム - Google Patents

Abstract

【課題】ユーザ本人の意思に基づく手続きであることの確認を支援する。【解決手段】本人確認支援システム４００において、ユーザＡが、情報処理端末４０１を使って、ユーザＢに代金の支払いを申し出ると、アカウントアクティビティＡＰＩ（ＡＣＣＯＵＮＴ Ａｃｔｉｖｉｔｙ ＡＰＩ）がそれを検知し、ユーザＡに対してユーザＢのニックネームの確認を行い、ユーザＡのメッセージを、第１サービスサーバに送信する。第１サービスサーバは、前記ＡＰＩを介して受信したメッセージからユーザＢのニックネームを抽出して第２サービスサーバ４０４へ送信する。第２サービスサーバは、受信したユーザＢのニックネームからユーザＢのＩＤを導出し、それに基づいて、情報処理端末４０７に対して、前記申し出を承諾するか否かの問い合わせを行う。情報処理端末４０７は、第２サービスサーバから送信された申し出を承諾するか否かの判断を行い、回答する。【選択図】図４

Description

本発明は、広くユーザ本人による電子処理手続きであることの確認を支援するためのシ
ステム等に関し、より詳細には、ユーザ本人以外のユーザからの代理申請処理手続きを含
む処理がユーザ本人の意思に基づく処理であることの確認を支援するためのシステム等に
関する。

近年、申請処理手続きや決済処理手続きを含め、ユーザ本人の処理手続きであるかどう
かを確認したり認証したりするためのシステム等が運用されており、様々な改善が提案さ
れている。

例えば、システムを介した送金手続きにおいて、送金者が安心して送金をおこなうため
の送金支援装置、送金支援方法、および送金支援プログラムが提案されている（特許文献
１）。

特許文献１には、例えば、あらかじめ連絡先が登録された受取者に宛てて送金をおこな
う旨の依頼を送金者から受け付けた場合に、前記受取者に前記送金がおこなわれる旨の通
知をおこなう通知部と、前記通知により前記送金がおこなわれることの承諾を前記受取者
から受け付ける受付部と、前記受付部によって受け付けられた前記承諾に応じて、前記送
金を実行する送金制御部と、を備えたことを特徴とする送金支援装置が開示されている。
ここで、前記承諾は、前記受取者の認証を含むことがあり、また、前記通知部は、前記
送金を示す所定の文字列の入力を含む前記依頼を前記送金者から受け付けた場合に、前記
所定の文字列を含む前記通知をおこなうことを含む場合がある。

また、ＥメールまたはＳＮＳで商品の購入確認を行うメッセージ決済システム、メッセ
ージ決済装置、メッセージ決済方法及びメッセージ決済プログラムも提案されている（特
許文献２）。

すなわち、特許文献２には、入出力部を備えた端末装置、および、記憶部と制御部とを
備えたメッセージ決済装置を通信可能に接続したメッセージ決済システムであって、前記
記憶部は、商品の商品データを記憶する商品記憶手段と、前記端末装置でのオンライン決
済の登録者の登録者識別データとオンラインアカウントと決済方法データとを含む登録デ
ータを記憶する登録記憶手段と、を備え、前記制御部は、前記商品データを前記端末装置
に表示させるように制御する商品画面表示制御手段と、前記端末装置の前記入出力部を介
して購入商品が決定された場合、前記オンラインアカウントに基づいて、前記商品の購入
詳細データを含む購入確認通知を前記端末装置に送信する購入確認通知手段と、前記端末
装置の前記入出力部を介して前記購入確認通知に含まれる前記商品の購入確認表示が選択
された場合、前記商品の支払処理画面を前記端末装置に表示させるように制御する支払処
理画面表示制御手段と、前記端末装置の前記入出力部を介して支払承認が入力された場合
、前記商品の支払処理を実行する支払実行手段と、を備えたことを特徴とするメッセージ
決済システムが開示されている。

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

しかしながら、上記従来の技術においては、さらに多様なユーザニーズに応えることを
可能にするための更なる改善が期待される。

一方、本出願の出願時点においても、例えば、図９～図１１に示されるような従来技術
が提供されている。まず、図９及び図１０を参照して、ＲＦＣ６７４９で定義されている
ＯＡｕｔｈ２．０承認フレームワークをベースとした従来の認可システムにおける認可処
理フロー例を説明する。

図９には、ユーザの情報処理端末（同図において、不図示）のディスプレイ上にウェブ
ブラウザ９１０が表示されている。ウェブブラウザ９１０は、クライアントアプリケーシ
ョンから提供されるインタフェースである。
また、同図には、認可サーバとして９２０が表されている。同図に示されるように、認
可サーバ９２０は、認可エンドポイント９２１を備える。

ウェブブラウザ９１０は、タブ９１１を含み、タブ９１１は、ＵＲＬを入力するための
入力欄９１１１を備える。ユーザは、この入力欄に認可を申請したいサーバのＵＲＬを含
むリクエストを入力する。この入力は、必ずしも手動である必要はなく、例えば、図示し
ないボタンを押下することにより自動的に入力され、送信されることもできる。
本発明は、これに限定されるものではないが、入力欄９１１１に入力される事項は、次
表に例示されるとおりである。
本発明の一実施形態においては、これらの事項がＨＴＭＬフォーマットに従ったＵＲＬ
として入力される。

図９において、入力欄９１１１に認可リクエストを表すＵＲＬをウェブブラウザ９１０
に与えると、ウェブブラウザ９１０は、認可サーバ９２０の認可エンドポイント９２１に
向けてメッセージを送信する（ステップＳ９０１）。

次に、図１０に、図９においてウェブブラウザ９１０からのメッセージを受信した認可
サーバ９２０の処理フローを示す。ウェブブラウザ１０１０、認可サーバ１０２０、認可
エンドポイント１０２１は、ウェブブラウザ９１０、認可サーバ９２０、認可エンドポイ
ント９２１にそれぞれ対応する。

図１０において、認可エンドポイント１０２１は、受信したメッセージを処理し、認可
画面を示すＨＴＭＬをブラウザ１０１０へ返信する（ステップＳ１００１）。このとき、
一実施形態においては、いわゆる「リダイレクト機能」が利用される。
すると、ブラウザ１０１０では、認可画面がタブ１０１１として準備され、ブラウザ上
に同図に示されるような認可画面が表示される。

図１０において、タブ１０１１には、入力欄１０１１１のほか、認可画面を構成するア
イテムが表示されている。
まず、クライアントアプリケーションが権限を求めている旨のメッセージ１０１２と、
その権限の内容（プロフィール参照権限）１０１３とが表示されている。その下欄には、
承認を与えるユーザのログインＩＤとパスワードを入力するための入力欄１０１３及び１
０１４が表示され、承認ボタン１０１５及び拒否ボタン１０１６が表示されている。
一実施形態として、ユーザがクライアントアプリケーションに対してプロフィール参照
の権限を与える場合には、入力欄１０１３に自身のログインＩＤを入力し、入力欄１０１
４に自身のパスワードを入力して、承認ボタン１０１５を押下する。
すると、ユーザの承認の結果は、ＨＴＴＰリクエストとして、再び認可サーバ１０２０
へ送信される。

このように、図９及び図１０に示された従来の認可システムにおける認可処理フローの
１つの特徴は、ユーザの認可画面（タブ１０１１）は、認可申請を行った画面（タブ９１
１）を生成したブラウザと同一のブラウザ上に生成されることである。

次に、図１１に、従来の認可システムにおける他の認可処理フロー例を示す。この認可
処理フローは、ＣＩＢＡ（OpenID Connect Client Initiated Backchannel Authenticati
on Flow）に基づく処理例である。

図１１においては、まず、クライアントアプリケーション１１１０からは、認可サーバ
１１２０のバックチャネル認証エンドポイント１１２１に対して認証リクエストが送信さ
れる（ステップＳ１１０１）。このとき、認可サーバ１１２０では、受信した認証リクエ
ストに対してはすぐに応答する（ステップＳ１１０２）。

その後、認可サーバでは、受信された認証リクエストの内容を解析し、ユーザ認証を行
い、特定されたユーザに対して承認問合せ通知（または同意取得）を認証デバイス１１３
０に対して行う（ステップＳ１１０３）。

承認問合せ通知を受けた認証デバイス１１３０では、このデバイスの所有者であるユー
ザに対して、任意のＧＵＩを介して承認可否の問い合わせを行い、その結果を取得して認
可サーバ１１２０へ送信する（ステップＳ１１０４）。

このように、図１１に示された従来の認可システムにおける他の認可フローの特徴は、
ユーザ認証後の同意取得方法については、認証デバイスに一任されることである。この場
合、認証デバイス１１２０は、クライアントアプリケーション１１１０が動作するデバイ
スと必ずしも同一である必要はない。

本発明の一実施形態にかかるシステム等は、図９～図１１を参照して説明した従来技術
においても実現されていなかった技術、例えば、ユーザ本人以外のユーザからの代理申請
手続きを含む手続きがユーザ本人の意思に基づく手続きであることを確認するための改善
された技術を提供することを目的としている。

そこで、本発明の一実施形態にかかるシステム等は、第１のユーザのための第１情報処
理端末と、第２のユーザのための第２情報処理端末と、前記第１情報処理端末及び前記第
２情報処理端末から接続されるユーザ管理サーバとを少なくとも備えた本人確認支援シス
テムであって、前記ユーザ管理サーバは、前記第１情報処理端末から送信された前記第１
のユーザに関するプロフィール情報を登録するものであって、前記プロフィール情報には
少なくとも前記第１のユーザのユーザＩＤ及びニックネームが含まれ、前記第２情報処理
端末から送信された前記第１のユーザための処理の申請及び前記ニックネームを受信し、
前記第２情報処理端末から受信した前記ニックネームから前記第１のユーザの前記ユーザ
ＩＤへ変換し、前記変換された前記ユーザＩＤを有する前記第１のユーザに対し、前記第
２情報処理端末から送信された前記第１のユーザための処理の申請の承認可否の問い合わ
せを行うことを特徴とする。

また、決済処理サーバをさらに備え、前記第１のユーザのための処理は決済処理であり
、前記問い合わせの結果、前記第１のユーザから前記ユーザ管理サーバに対して承認通知
があったとき、前記ユーザ管理サーバは、前記決済サーバに決済処理を実行させるための
決済トークンを発行し、前記決済トークンを前記決済サーバへ送信することを特徴とする
。

本発明の一実施形態にかかるシステム等によれば、多様なユーザニーズに応えることのできるシステム等を提供することができる等の有利な効果を奏する。例えば、ユーザ本人以外のユーザからの代理申請手続きを含む手続きがユーザ本人の意思に基づく手続きであることを確認するための改善されたシステム等を提供することができる。

本発明の一実施形態にかかる本人確認支援システムの全体構成例を説明する説明図である。 本発明の一実施形態にかかる本人確認支援システムにおけるサーバの機能ブロック構成を説明する説明図である。 本発明の一実施形態にかかる本人確認支援システムにおける情報処理端末の機能ブロック構成を説明する説明図である。 本発明の一実施形態にかかる本人確認支援システムのシステム構成例及び処理フローの概念例を説明する説明図である。 本発明の一実施形態にかかる本人確認支援システムにおける詳細な処理フロー例を説明する説明図である。 本発明の一実施形態にかかる本人確認支援システムにおける詳細な処理フロー例を説明する説明図である。 本発明の一実施形態にかかる本人確認支援システムにおける情報処理端末の画面表示例を説明する説明図である。 本発明の一実施形態にかかる本人確認支援システムにおける情報処理端末の画面表示例を説明する説明図である。 本発明の一実施形態にかかる本人確認支援システムにおける情報処理端末の画面表示例を説明する説明図である。 従来の認可システムにおける認可処理フロー例を説明する説明図である。 従来の認可システムにおける認可処理フロー例を説明する説明図である。 従来の認可システムにおける他の認可処理フロー例を説明する説明図である。

以下、本発明の一実施形態にかかる本人確認支援システム等について、図面を参照しな
がら詳細に説明する。

図１に、本発明の一実施形態にかかる本人確認支援システムの全体構成例を示す。
図１に示されるように、本人確認支援システム１０は、その一実施形態における大別的
な構成として、サービスサーバ（群）１１と、店舗等の拠点に配置されて店員等に使用さ
れたり、顧客等が所持して使用したりする各種情報処理端末（図において、例示的に、Ｐ
Ｃ１４ａ～１４ｃ、ならびに、携帯情報端末、タブレット端末１５ａ～１５ｅが示されて
いる。以下、総称して「各種端末」あるいは単に「端末」とも言うこともある）で構成さ
れている。
サービスサーバ（群）には、ユーザ管理サーバ、認証サーバ、決済サーバ等の各種情報
処理サービスをサーバが含まれる。例示的に、図１においては、１１－１～１１－ｎまで
のｎ台のサービスサーバ群が想定されている（ｎは、１以上の自然数）。
なお、各種端末数は、図示されたものに限られず、任意である。例えば、顧客端末につ
いては、顧客数に応じた数が想定されることができる。また、拠点に配置される端末につ
いても、拠点ごとに１以上の端末が配置されてもよい。

本発明の一実施形態において、サービスサーバ（群）１１、各種端末間は、図１に示さ
れるように専用回線やインターネット等の公衆回線（有線の回線として、１７、１８－１
～１８－ｎ、３９）を介して相互に通信可能に接続されている。

また、回線は、有線であっても無線であってもよい。回線が無線の場合、各種端末１４
ａ～１４ｂ、１５ａ～１５ｅは、無線で図示しない基地局やアクセスポイント等を介して
インターネット１９に乗り入れ、さらに、サーバ１１－１～１１－ｎへ接続する回線１８
－１～１８－ｎを介してサービスサーバ（群）１１と相互に通信可能に接続される。

ここで、アクセスポイントとは、ＰＣやスマートフォンなどの無線端末を相互に接続し
たり、他のネットワークに接続させたりするための無線機である。典型的には、ＯＳＩ参
照モデルにおける第１層（物理層）及び第２層（データリンク層）の通信プロトコルで作
動するデバイスである。

また、本願の出願時点での携帯情報端末やタブレットは、パーソナルコンピュータ（Ｐ
Ｃ）と同等かそれ以上の処理能力（通信処理速度や画像処理能力等）を備えているものも
多く、小型の高性能コンピュータとも言うべきものである。

さらに、本発明の実施に必要なプログラムないしソフトウェアは、通常、ＰＣや携帯情
報端末の記憶部におけるＨＤＤ、ＳＳＤ等にインストールないし記憶され、プログラムな
いしソフトウェアの実行時には、必要に応じて記憶部内のメモリにその全部又は一部のソ
フトウェアモジュールとして読み出され、ＣＰＵにおいて演算実行される。

あるいは、ブラウザベースのコンピュータないし携帯情報端末を採用することもできる
。この場合は、必要に応じて他のサーバやコンピュータから端末にプログラムが配信され
、端末上のブラウザではこれを実行するという構成になる。

また、サービスサーバ（群）１１のハードウェア構成も、基本的にはＰＣを採用するこ
とができる（念のため、図２を参照して後述する）。なお、本発明はこれに限定されるも
のではないが、サービスサーバ（群）１１は、必要に応じてそのハードウェアスペックを
上げるにあたり、複数のＰＣ（一例として、数十台～数万台）を並列的に作動させること
によって大規模データの処理に適した構成をとることもできる。

図２に、本発明の一実施形態にかかる本人確認支援システムにおけるサーバ（サービス
サーバ（群）１１における１つのサーバに相当する。以下、「情報処理サーバ」ともいう
。）の機能ブロック図を示す。例示的に、サーバの動作は、以下に説明するハードウェア
の個々の動作、及びソフトウェアとこれらハードウェアとの連携動作によって実現されて
いる。

図２において、ハードウェアブロック全体としてのサーバ３００は、大別すると、各種
比較・演算処理を行うためのＣＰＵ２０１と、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の記
憶部２０２と、キーボードやポインティングデバイス等の入力部２０３と、ディスプレイ
やスピーカ等の出力部２０４と、各種信号制御のための制御部２０５と、通信（インタフ
ェース）部２０６（無線、有線を問わない）と、時刻等を計時するための計時部２０７と
、電源部２０８とからなる。

これらのモジュールは必要に応じて適宜通信バスや給電線（図２においては、便宜上こ
れらの通信バスや給電線といった各線が適宜含まれる結線２９９として表す）によって接
続されている。

また、本発明の実施に必要なサーバ２００上で実行されるプログラムないしソフトウェ
アは、通常、記憶部２０２を構成するハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ
Ｄｒｉｖｅ）、フラッシュメモリ等にインストールないし記憶され、プログラムないし
ソフトウェアの実行時には、必要に応じて記憶部２０２内のメモリにその全部又は一部の
ソフトウェアモジュールとして読み出され、ＣＰＵ２０１において演算実行される。

なお、演算実行は必ずしもＣＰＵ２０１等の中央処理部で行われる必要はなく、図示し
ないディジタルシグナルプロセッサ（ＤＳＰ）、ＧＰＵ（Graphics Processing Unit）や
ＴＰＵ（Tensor processing unit）等の補助演算装置を用いることもできる。

図３に、本発明の一実施形態にかかる顧客端末としてのタブレット端末１５ａを構成す
るハードウェアの機能ブロック図を例示する。タブレット端末１５ａの動作は、以下に説
明するハードウェアの個々の動作、及びソフトウェアとこれらハードウェアとの連携動作
によって実現されている。

図３において、ハードウェアブロック全体としてのタブレット端末３００は、大別する
と、ハードウェアボタン、ディスプレイに設けられたマルチタッチ入力パネル、マイク等
で構成される入力部３０１と、プログラムやデータ等を記憶するためのハードディスク、
ＲＡＭ及び／又はＲＯＭ等で構成される記憶部３０２と、プログラムによって様々な数値
計算や論理演算を行うＣＰＵによって構成される中央処理部３０３と、ディスプレイ等で
構成される表示部３０４と、チップや電気系統等の制御を行うための制御部３０５と、イ
ンターネットにアクセスするためのスロットや光通信を行うためのポート、及び通信イン
タフェースから構成される通信インタフェース部３０６と、スピーカやバイブレーション
、赤外線プロジェクター等の出力部３０７と、時刻等を計時するための計時部３０８と、
ＣＭＯＳ等のイメージセンサや赤外線センサ、慣性センサ等からなるセンサ部３０９と、
装置内の各モジュールに電源を供給するための電源部３１０とからなり、これらのモジュ
ールは必要に応じて適宜通信バスや給電線（図３においては、便宜上これらの通信バスや
給電線といった各線が適宜含まれる結線３９９として表す）によって接続されている。
なお、センサ部３０９には、タブレット端末３００（１５ａ）の位置を特定するための
ＧＰＳセンサモジュールを含めることとしても良い。センサ部３０９を構成するＣＭＯＳ
等のイメージセンサや赤外線センサ等によって検知された信号は、入力部３０１において
入力情報として処理することができる。

また、本発明の実施に必要なタブレット端末３００上で実行されるプログラムないしソ
フトウェアは、通常、記憶部３５２を構成するハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓ
ｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリ等にインストールないし記憶され、プログラ
ムないしソフトウェアの実行時には、必要に応じて記憶部３０２内のメモリにその全部又
は一部のソフトウェアモジュールとして読み出され、ＣＰＵ３０３において演算実行され
る。

なお、演算実行は必ずしもＣＰＵ等の中央処理部３０３で行われる必要はなく、図示し
ないディジタルシグナルプロセッサ（ＤＳＰ）、ＧＰＵ（Graphics Processing Unit）や
ＴＰＵ（Tensor processing unit）等の補助演算装置を用いることもできる。

（本発明の基本概念）
本発明は、次のような基本概念を有する。
（１）基本的に、３者間でのやり取りを支援する。代理申請者または代理注文者であるユ
ーザＡと、決済者または承認者であるユーザＢと、認証機関または決済機関である情報処
理サーバである。ユーザＡ及びユーザＢは、図１における携帯情報端末１４ａ～１４ｃ、
１５ａ～１５ｅのうち、それぞれ少なくとも１台を使用する。認証機関または決済機関は
、図１におけるサービスサーバ（群）１１における少なくとも１つのサーバである。

（２）基本的な動作の流れ
（Ａ）あらかじめ認証済のユーザＢの認証コード（ニックネームや合言葉など。以下、「
ニックネーム」という。）は、ユーザＡに開示されている。このコードは、ユーザＡとユ
ーザＢとの間のいわば秘密情報として共有されている。
ユーザＡは、認証サーバまたは決済サーバに対して、ユーザＢのための代理手続き承認
申請または代理決済申請を行う。このとき、ユーザＢの認証コード（ニックネーム）をサ
ーバに送信する。この申請処理は、必ずしもユーザＡが所持する情報処理端末から実行さ
れるとは限らない。例えば、店舗に設置された店舗端末などからユーザＡが申請処理を行
う場合もある。
（Ｂ）認証サーバまたは決済サーバは、ユーザＡから申請された内容（ユーザＢのための
手続きや決済）を実行するにあたり、まず、ユーザＡから送られてきたユーザＢの認証コ
ード（ニックネーム）からユーザＢ本人の情報を抽出する。次に、ユーザＢに対して確認
通知を行う（「いま、ユーザＡからあなたのための手続きのための申請がきています。承
認されますか？」など）。
（Ｃ）ユーザＢは、認証サーバまたは決済サーバからの通知内容に異存がなければ、承認
処理を行う。
（Ｄ）ユーザＢの承認に基づき、認証サーバまたは決済サーバは、ユーザＡから申請され
た手続き処理を許可したり実行したりする。

（本発明が実施されるシーン例）
本発明は、これらに制限されるものではないが、次のような実施のシーンが想定される
。

（シーン１）酒場でユーザＢがユーザＡにご馳走する場合
ユーザＡとユーザＢは、ともに酒場で飲んでいる。その日の会計はユーザＢが持つこと
となった。一方、ユーザＡはいま自分の情報処理端末を所持していない。また、ユーザＢ
はいま自分の情報処理端末を所持しているが、ネット決済について多くの知識を有してい
るわけではない。ただし、ユーザＢは、本件発明に基づく本人情報登録を認証サーバまた
は決済サーバに対して済ませており、その認証コードの一形態として自分の「ニックネー
ム」を覚えているだけである。
ユーザＢは、自身の「ニックネーム」をユーザＡに伝えて、ユーザＡに会計に行かせる
。ユーザＡはレジに行き、店員に対して本件発明にかかる支援システムによる決済処理を
申し出る。すると、店員は店舗端末に対し、２人の会計の金額の確認及びニックネームの
入力を求める。ユーザＡは、ユーザＢから聞いたニックネームを店員に伝え、店員はこれ
を入力する。
すると、認証サーバまたは決済サーバは、送信されてきた認証用の認証コード（ニック
ネーム）から本人（ユーザＢ）を割り出し、ユーザＢに対して決済処理申請及びその内容
の確認通知を行う。
ユーザＢは、自身が有する端末に送信されてきた確認通知から決済金額とニックニーム
を知らされ、異存がなければ承認処理を行う。
認証サーバまたは決済サーバは、決済処理を実行する。

（シーン２Ａ）店員が顧客情報を使って顧客の好みの品を提案する場合
ユーザＢは、ある靴店に買い物にきた。店員であるユーザＡが対応する。ユーザＢは、
本件発明に基づく支援システムの本人情報登録を認証サーバまたは決済サーバに対して済
ませており、その認証コードとして「ニックネーム」を知っている。また、ユーザＢは、
この靴店の常連客で自分の足型の採寸データを計測済みであり、個人情報とともに店舗サ
ーバに保管している。
ユーザＢは、この日も新しい靴を買い求めにきており、店員であるユーザＡのアドバイ
スに従って自分の足に無理のない範囲でデザイン性に富んだ靴を購入したいと申し出た。
あいにく、ユーザＡは新米店員で、ユーザＢの名前はおろか、個人情報も知らない（足型
の採寸データへアクセスする術もない）。さらに、ユーザＢも、自分のスマホは持ってき
ているがこの店の会員カードを忘れてきており、ただ「ニックネーム」だけは覚えている
という。
そこで、店員である新米ユーザＡは、ユーザＢからそのニックニームを聞き、店舗端末
に入力することで店舗サーバ上のユーザＢの顧客情報の参照を試みた。このとき、店舗サ
ーバとの間に入っている認証サーバまたは決済サーバが、ユーザＢに、個人情報照会があ
る旨を通知して許可してよいかの確認を行う。ユーザＢは、その通知内容（ニックネーム
を含む）を確認し、異存がなければ承認処理を行う。この承認を経たあと、店員である新
米ユーザＡは、店舗サーバ上のユーザＢの顧客情報を参照してユーザＢとの商談を円滑に
進めることができた。

（シーン２Ｂ）ＥＣサイトのオペレータが顧客に対してサービス提供する場合
ユーザＢは、本件発明に基づく支援システムの本人情報登録を認証サーバまたは決済サ
ーバに対して済ませており、その認証コードとして「ニックネーム」を知っている。また
、ユーザＢは、別途、ＥＣサイトの会員登録をしている。
ユーザＢは、ＥＣサイトで買い物をすべく、このサイトのコールセンターへ電話をかけ
て電話注文を行うこととした。ユーザＢがこのサイトのコールセンターへ電話をかけると
オペレータであるユーザＡが応答した。
ユーザＡ（オペレータ）は、ユーザＢに「ニックネーム」を訪ね、ユーザＢがこれに応
える。ユーザＡ（オペレータ）は、ユーザＢから聞き出した「ニックネーム」を認証サー
バまたは決済サーバへ入力し、ユーザＢの注文を行う権限の取得を試みる。
認証サーバまたは決済サーバは、ユーザＡ（オペレータ）による「ニックネーム」の入
力を受けて、この「ニックネーム」の所有者であるユーザＢに対し注文の代行処理をさせ
て良いかどうかの確認通知をする。ユーザＢは、その通知内容（ニックネームを含む）を
確認し、異存がなければ承認処理を行う。この承認を経たあと、ユーザＡは、ユーザＢの
注文処理を代行する権限を取得し、ユーザＢとの電話での口頭でのやり取りを経て、ＥＣ
サイトへの注文処理及び決済処理を進めることができた。

（シーン３）ＡＩが顧客にサービスする場合
ユーザＢは、本件発明に基づく支援システムの本人情報登録を認証サーバまたは決済サ
ーバに対して済ませており、その認証コードとして「ニックネーム」を知っている。また
、ユーザＢは、別途、ＥＣサイトの会員登録をしている。
ユーザＢは、ＥＣサイトで買い物をすべく、このサイトへ接続することができるスマー
トスピーカーを介して注文を行うこととした。ユーザＢは、ＡＩ搭載のスマートスピーカ
ーまたはスマートスピーカシステム（ユーザＡ）に向かって「いつもの水を注文して」と
語りかける。このときのユーザＡは、ＡＩ搭載デバイスである。
ユーザＡ（スマートスピーカーまたはスマートスピーカーシステム）は、ユーザＢに「
ニックネーム」を訪ね、ユーザＢがこれに応える。ユーザＡは、ユーザＢから聞き出した
「ニックネーム」を認証サーバまたは決済サーバへ伝達し、ユーザＢの注文を行う権限の
取得を試みる。
認証サーバまたは決済サーバは、ユーザＡによる「ニックネーム」の入力を受けて、こ
の「ニックネーム」の所有者であるユーザＢに対し注文の代行処理をさせて良いかどうか
の確認通知をする。ユーザＢは、その通知内容（ニックネームを含む）を確認し、異存が
なければ承認処理を行う。この承認を経たあと、ユーザＡは、ユーザＢの注文処理を代行
する権限を取得し、さらに、ユーザＢの過去の購入履歴を参照して、ユーザＢがいつも注
文する水を見つけ出す。ユーザＡは、ユーザＢに「○○社の天然水２Ｌ／６本入りでよろ
しいですか？」と問いかける。
ユーザＢがユーザＡに向かって「ＯＫ」と答えると、ユーザＡからＥＣサイトに対して
注文が出されるとともに、決済処理がなされる。

図４に、本発明の一実施形態にかかる本人確認支援システムのシステム構成例及び処理
フローの概念例を示す。

（システム構成例）
図４において、本人確認支援システム４００は、ユーザ端末である情報処理端末４０１
、４０７と、ソフトウェア機能としてのアカウントアクティビティＡＰＩ（Account Acti
vity API）４０２と、第１サービスサーバ４０３と、第２サービスサーバ４０４と、ソフ
トウェア機能としてのＡＰＩゲートウェイ４０５と、決済サーバ４０６とを含む。

ここで、アカウントアクティビティＡＰＩ４０２は、ユーザの行動履歴を確認できる機
能を実装しており、具体的には、情報処理端末４０１、４０７にインストールされたＳＮ
Ｓアプリケーションのウェブフック（Web Hook）機能として実現することができる。この
機能は、図９～図１１を参照して説明したウェブブラウザの機能を代替する、あるいは強
化する機能である。したがって、本発明の他の実施形態においては、アカウントアクティ
ビティＡＰＩ４０２の採用せずに、図９～図１１を参照して説明した従来のブラウザ機能
を利用することもできる。
また、図４に示された実施形態においては、サービスサーバを２つに分けているが、本
発明はこれに制限されるものではなく、１つのサーバでこれらの機能を実現することもで
きるし、３以上のサーバに機能を分散させることもできる。サービスサーバには、ユーザ
に関する情報を管理するためのユーザ管理サーバが含まれてもよい。
さらに、図４に示された実施形態においては、決済サーバ４０６を含むが、本発明はこ
れに制限されるものではなく、決済サーバ４０６に替えて、あるいは、決済サーバ４０６
に加えて、他の処理系（種々のデータベースなど）と接続させることもできる。図４にお
いては、ＡＰＩゲートウェイ４０５は、決済サーバ４０６に処理を要求するためのＡＰＩ
を処理するために設けられている。

本発明の他の実施形態においては、ＡＰＩゲートウェイ４０５及び決済サーバ４０６を
含まない構成も採用されうることに留意されたい。つまり、本発明の他の実施形態におい
ては、本人確認支援システムは、ユーザ端末である２以上の情報処理端末と、サービスサ
ーバ群とで構成される。

（処理フロー例）
図４において、ユーザＡは、情報処理端末４０１にインストールされたＳＮＳアプリケ
ーションを使って、ユーザＢに１０ドル分の飲食費あるいは商品代金の支払いを申し出る
とする。この支払は、店頭での支払いであってもネット上での決済であっても構わないが
、ここでは、ネット上での決済であるとする。
このユーザＡの具体的な申し出は、ＳＮＳで「Ｂさん、１０ドルの飲食をご馳走してく
ださい。」というようなメッセージとなる（ステップＳ４ａ）。このメッセージは、ユー
ザＢも自身の情報処理端末４０７にインストールされたＳＮＳアプリケーションによって
確認することはできるが、このままでは、ユーザＢはユーザＡの申し出に応じることはで
きない。

次に、ユーザＡの具体的な申し出（「Ｂさん、１０ドルの飲食をご馳走してください。
」というメッセージ）は、アカウントアクティビティＡＰＩ４０２によって検知され、図
示しないフローによって、ユーザＡに対してユーザＢのニックネームの確認が行われる（
あるいは、この確認処理を行う代わりに、最初のメッセージにおいてユーザＢのニックネ
ームが含まれていても良い）。
ユーザＡのメッセージは、第１サービスサーバ４０３に送信される（ステップＳ４ｂ）
。

次に、第１サービスサーバ４０３では、アカウントアクティビティＡＰＩ４０２を介し
て受信したメッセージからユーザＢのニックネームを抽出する（ステップＳ４ｃ）。そし
て、このニックネームを第２サービスサーバ４０４へ送信する（ステップＳ４ｄ）。

次に、第２サービスサーバ４０４では、第１サービスサーバ４０３から受信したユーザ
ＢのニックネームからユーザＢのＩＤを導出する（ステップＳ４ｅ）。典型的は、ユーザ
Ｂのプロフィール情報テーブルを参照してこの導出が可能となる。
第２サービスサーバ４０４は、ユーザＢのユーザＩＤに基づいて、ユーザＢの情報処理
端末４０７に対して、ユーザＡからの申し出を承諾するか否かの問い合わせを行う（ステ
ップＳ４ｆ）。

情報処理端末４０７では、第２サービスサーバ４０４から送信された、ユーザＡからの
申し出を承諾するか否かの判断を行い、承諾または拒否の回答を行う。ここでは、承諾の
回答を行うものとする。承諾の回答は、第２サービスサーバ４０４へ送信される（ステッ
プＳ４ｇ）。

次に、第２サービスサーバ４０４では、決済サーバ４０６に決済手続きをリクエストす
るためのＦＡＰＩ（Financial-grade API）トークンを発行する（ステップＳ４ｈ）。こ
のＦＡＰＩトークンは、第１サービスサーバ４０３へ送信される。
なお、本発明の一実施形態においては、金融ＡＰＩ向けのセキュリティ標準であるＦＡ
ＰＩを採用したが、本発明はこれに制限されず、他のセキュリティトークンを採用するこ
ともできる。

次に、第１サービスサーバ４０３は、ＡＰＩゲートウェイ４０５を介して決済サーバ４
０６へ決済のためのリクエストをするが（ステップＳ４ｊ）、このとき、ＦＡＰＩトーク
ンが送られる。また、ここでの決済は、ユーザＢによる決済として処理が進められる。
ＡＰＩゲートウェイ４０５では、送信されてきたＦＡＰＩトークンの検査を行い、決済
サーバ４０６へ決済処理を依頼する。

ＡＰＩゲートウェイ４０５を介して決済処理の依頼を受けた決済サーバ４０６は、この
依頼に基づき、ユーザＡが消費する飲食費用をユーザＢによる決済として処理する。
このようにして、ユーザＢがユーザＡに飲食代をご馳走するという一連の処理が実現さ
れる。

図５に、本発明の一実施形態にかかる本人確認支援システムにおける動作例を示す。な
お、図５及び図６に基づく説明におけるシステム構成は、図４を参照して説明したシステ
ム構成とは異なるが、これらの違いは実現手段の相違に過ぎず、機能的にはいずれも本発
明の一実施形態を説明するものとして、本発明の技術的概念の範囲内のものである。

図５において、「ユーザ端末」は、一例として図１における端末１５ａ～１５ｅ等に対
応し、「情報処理サーバ」は、図１におけるサービスサーバ（群）１１のうちの少なくと
も１サーバに対応する。また、図５中、ｔ１～ｔ１０は時系列の流れを示し、経時的に後
述する動作や処理が行われるものである。

なお、実施形態において例示される動作または処理時刻（ｔ１等）は、本発明の概念の
理解の容易のために例示されたものであり、本発明が実施形態において例示される個別の
時系列関係に制限されることはない。

まず、日時ｔ１において、ユーザ（顧客）は、ユーザ端末を介して情報処理サーバから
自身のユーザ端末を本発明にかかる情報処理端末として動作させるためのアプリケーショ
ンソフトウェアをダウンロードする（ステップＳ５０１）。このアプリケーションソフト
ウェアは、本発明にかかるプログラムの一部又は全部を処理するためのクライアントソフ
トウェアまたはアプリケーションソフトウェアである。そして、ダウンロードしたアプリ
ケーションソフトウェアをユーザ端末にインストールする（ステップＳ５０２）。このと
き、時刻ｔ２において、ユーザ端末からは、必要に応じてユーザ登録としてユーザ自身の
メールアドレスのほか、次表のようなプロフィール情報を情報処理サーバへアップロード
（ステップＳ５０３）して登録管理させることもできる（ステップＳ５０４）。
また、本発明の一実施形態においては、上表に掲げたプロフィール情報のほかに、ユー
ザに関する他の情報（クレジットカード番号を含む決済情報）を登録管理させることもで
きる。

以上のデータ項目は、ユーザデータとして情報処理サーバ上の記憶装置に保存される（
ステップＳ５０５）。時刻ｔ３以降は、ユーザ（顧客）が情報処理端末を操作することに
よりアプリを使用することができる。そして、サーバは、端末に対してサービスを提供す
る。

次に、ユーザ端末にアプリをダウンロード及びインストールしたユーザは、時刻ｔ４に
おいてアプリケーションソフトウェアを起動する（ステップＳ５０６）。一実施形態にお
いて、ユーザは、時刻ｔ４～時刻ｔ５まで、情報処理サーバから情報処理端末に対して提
供されるサービスを受けている。

時刻ｔ５になると、ユーザはいったん本発明の一実施形態にかかるアプリケーションソ
フトウェアを中断または終了する。このとき、必要に応じて、アプリケーションのステー
タス情報は情報処理サーバへ転送され（ステップＳ５０７）、サーバではこれを受信して
当該ユーザのユーザ情報としてのステータス情報を更新（ステップＳ５０８）及び保存（
ステップＳ５０９）する。図５においては、これらの処理は、時刻ｔ６までに完了してい
る。

なお、本発明の他の実施形態にかかるアプリケーションソフトウェアを情報処理端末に
インストールした後は、端末上で少なくとも一部をクローズドに実行可能な形態とするこ
とも可能である。この場合は、上述のステップＳ５０４～ステップＳ５０５、並びに、ス
テップＳ５０８～ステップＳ５０９を省略することができる。また、必要な情報は、適宜
端末上のメモリに保存管理される。

次に、図５において、時刻ｔ７～時刻ｔ１０における処理動作は、本発明の一実施形態
にかかるアプリケーションソフトウェアの少なくとも一部を情報処理サーバにおいて実施
する場合の実施形態例を示している。この場合、ユーザ（顧客）は、ログイン動作と、コ
マンド送信という２つの典型的なユーザ端末操作を行い、情報処理サーバから必要なデー
タ送信を受け、あるいは、サービス提供を受けることとなる。

例えば、図５の時刻ｔ７において、ユーザは自身の情報処理端末を介してサーバへのロ
グイン処理を行う（ステップＳ５１０）と、情報処理サーバでは必要な認証処理が適宜行
われ（ステップＳ５１１）、時刻ｔ８において、ユーザがサービス提供を受けられるため
のデータを送信する（ステップＳ５１２）。例えば、端末からのコマンドを受信可能に構
成されたトップメニュー画面や、アプリケーションの起動画面等である。

時刻ｔ９において、ユーザは、情報処理端末を介して何らかのコマンドを送信する（ス
テップＳ５１３）。このコマンドは、メニュー画面に表示されたメニューの選択でもよく
、アプリケーション起動画面であれば、アプリケーションを開始するための開始コマンド
の場合もある。サーバ側では、このコマンドを受けて、サービス処理を開始する（ステッ
プＳ５１４）。そして、時刻ｔ１０において、サーバから端末の要求に応じたサービスが
提供される（ステップＳ５１５）。

なお、図５には図示していないが、時刻ｔ１０以降も、端末からは随時コマンドを送信
することができ（例えば、メッセージ送信コマンドやメニュー選択コマンドなど）、都度
、サーバでは端末からのコマンド受信を受けてサービスを提供することができる（例えば
、受信したメッセージを他端末に転送したり、メッセージ解析をしてその結果を返信した
りするなど）。

図６に、本発明の一実施形態にかかる本人確認支援システムにおける詳細な動作例を示
す。図６において、「ユーザ端末（ユーザＡ）」及び「ユーザ端末（ユーザＢ）」は、一
例として図１における端末１４ａ～１４ｃ、１５ａ～１５ｅ等に対応し、「ユーザ管理サ
ーバ」は、一例として図１におけるサービスサーバ（群）１１のうちの少なくとも１サー
バに対応し、「決済処理サーバ」は、一例として図１におけるサービスサーバ（群）１１
のうちの少なくとも１サーバに対応する。
また、図６中、ｔ２１～ｔ２７は時系列の流れを示し、経時的に後述する動作や処理が
行われるものである。

特に、図６においては、ユーザＡが、インターネット等を介してユーザＢの決済の代理
申請処理を行い、この申請処理を受け付けたユーザ管理サーバが、ユーザＢに確認をとっ
て決済処理サーバと連携をとりながら決済処理を進めて行く様子を説明している。

図６において、ステップＳ６０１及びステップＳ６０２では、ユーザＡは自身の端末か
らユーザＢのための代理手続の内容とユーザＢのニックネームを入力する。
代理手続きの内容は、上述したシーン１～シーン３のような手続きが挙げられるが、こ
こでは、説明の便宜上、決済手続きを伴うものとして説明を進める。

次に、時刻ｔ２１において、ユーザＡは、ユーザＢのための決済手続きの代理申請をユ
ーザ管理サーバに対して行う（ステップＳ６０３）。

この代理申請の様子は、図７に例示されるようなユーザＡの端末画面に表れている。図
７において、ユーザＡの端末７００のディスプレイ上には、代理申請画面７１０が表示さ
れており、同画面のメッセージ７１１の下に代理申請する内容を入力するための入力欄７
１２が表示されている。本発明の一実施形態においては、ここには誰のための何の手続き
の代理申請を行いたいかを入力する。入力手段は、図示しない公知の入力手段（メニュー
アイテム、セレクトボックス、テキストボックス等）が利用されることができる。
ここで、本発明の他の実施形態においては、図示しない他の画面において代理申請の内
容が入力され、代理申請画面７１０では、その入力内容が表示されて確認するだけの場合
もある。その場合は、７１２は、入力内容確認欄７１２となる。
図７において、７１３は、ニックネーム入力欄である。ここには、ユーザＡがユーザＢ
と共有しているユーザＢのニックネームを入力する。そして、申請ボタン７１４を押下し
て代理申請を行う。

図６に戻り、時刻ｔ２１～ｔ２２において、ユーザ管理サーバでは、ユーザＡから受信
した代理申請からユーザＢのニックネームを抽出する（ステップＳ６０４）。時刻ｔ２２
～ｔ２３において、ユーザ管理サーバは、抽出したユーザＢのニックネームからユーザＢ
のＩＤへの変換処理を行う（ステップＳ６０５）。本発明の一実施形態において、この変
換処理は、上表で説明したようなユーザＢのプロフィールの情報テーブルを参照すること
によって実施される。

時刻ｔ２３において、ユーザ管理サーバからユーザＢの端末に対し、ユーザＡからの代
理申請があったこと、および、その承諾をするか否かの問い合わせが行われる（ステップ
Ｓ６０６）。

この問い合わせの様子は、図８Ａに例示されるようなユーザＢの端末画面に表れている
。図８Ａにおいて、ユーザＢの端末８００のディスプレイ上には、代理申請通知画面８１
０が表示されており、同画面のメッセージ８１１の下に代理申請された内容を確認するた
めの確認欄８１２が表示されている。
さらに、上記代理申請を許可するか否かのメッセージ８１３の下に、許可ボタン８１４
及び拒否ボタン８１５が表示されており、ユーザＢがその代理申請を許可する場合にはボ
タン８１４を押下し、拒否する場合にはボタン８１５を押下する。
なお、本発明の他の実施形態において、代理申請内容があらかじめ取り決められている
場合には、確認欄８１２の表示を割愛することもできる。

図６に戻り、時刻ｔ２３～ｔ２４において、ユーザＢは、代理申請内容を確認して許
可ボタンを押下し、この代理申請を承認する（ステップＳ６０７）。すると、時刻ｔ２４
において、承認通知がユーザ管理サーバへ送信される（ステップＳ６０８）。

時効ｔ２４～ｔ２５において、ユーザ管理サーバでは、決済サーバで決済を実行するた
めの決済トークンを発行し（ステップＳ６０９）、発行した決済トークンを決済処理サー
バへ送信する（ステップＳ６１０）。

時刻ｔ２５～ｔ２６において、決済処理サーバでは、ユーザＡの代理申請によるユーザ
Ｂのための決済処理が実行される（ステップＳ６１１）。

時刻ｔ２６において、決済処理サーバは、上記決済処理が完了したことをユーザ管理サ
ーバへ通知する（ステップＳ６１２）。時刻ｔ２７において、ユーザ管理サーバは、ユー
ザＡによるユーザＢのための代理決済申請及びユーザＢの決済が完了したことを通知する
（ステップＳ６１３、Ｓ６１４）。

（本発明のバリエーション）
本発明は、図８Ｂに示されるような次の機能をさらに実現できる。
図８Ｂに、図８ＡのバリエーションとしてのユーザＢの情報処理端末の画面表示例を示
す。図８Ｂにおいて、ユーザＢの端末８５０のディスプレイ上には、代理申請通知画面８
６０が表示されており、同画面のメッセージ８６１の下に代理申請された内容を確認する
ための確認欄８６２が表示されている。さらに、上記代理申請を許可するか否かのメッセ
ージ８６３の下に、許可ボタン８６４及び拒否ボタン８６５が表示されており、ユーザＢ
がその代理申請を許可する場合にはボタン８６４を押下し、拒否する場合にはボタン８６
５を押下する。なお、本発明の他の実施形態において、代理申請内容があらかじめ取り決
められている場合には、確認欄８６２の表示を割愛することもできる。

ここで、特徴的な機能が表れている部分は、メッセージ８６１中の日時表示８６１１及
び場所表示８６１２、そして、カウントダウン表示８６６である。

（１）日時及び場所の表示
日時表示８６１１及び場所表示８６１２には、ユーザＡが代理申請を行った際の日時及
び場所が表示される。例えば、図６のｔ２１のタイミングである。本発明の一実施形態に
おいて、ユーザＡが情報処理端末を介して代理申請を行うと、ユーザＡの情報処理端末は
、ＧＰＳ受信機から受信したユーザＡの現在位置と、ＧＰＳ受信機あるいは情報処理端末
の計時手段から抽出した日時情報とを取得し、代理申請メッセージデータにこれらの情報
を含めて代理申請を行う。
このようにして、図８における日時表示８６１１及び場所表示８６１２の表示が可能と
なる。

一方、代理申請通知画面８６０を見たユーザＢは、ユーザＡからの代理申請が何時どこ
からなされたものかを把握できるため、ユーザＢ自身がユーザＡにご馳走することを約束
した日時と場所等を想起することが容易となり、承諾をするか否かの判断がし易くなると
いう利点がある。

（２）カウントダウン表示
カウントダウン表示８６６には、本発明の一実施形態において、ユーザＢの情報処理端
末に代理申請通知画面８６０が表示されてからのカウントダウン表示が行われる。本発明
はこれに制限されるものではないが、２分から開始したカウントダウンがなされる（図８
Ｂには、１分５９秒が表示されており、カウントダウンが始まったばかりである）。もち
ろん、カウントダウンの制限時間は、６０秒でも、３０秒でも、５分でも任意の時間を設
定できる。

ユーザＢは、ユーザＡからの代理申請を承諾するか否かをカウントダウンの制限時間内
に回答する必要がある。本発明の一実施形態において、ユーザＢが制限時間内にユーザＡ
からの代理申請の承諾／拒否を回答しなかった場合には、ユーザＡからの代理申請は不受
理となる。この場合、ユーザＡは代理申請をやり直す必要がある。
このようにして、ユーザＡからの代理申請の取扱いを厳格にし、本発明の一実施形態に
かかる本人確認支援システム等のセキュリティを強化できる。

以上、具体例に基づき、本人確認支援システム等の実施形態を説明したが、本発明の実
施形態としては、システム又は装置を実施するための方法又はプログラムの他、プログラ
ムが記録された記憶媒体（一例として、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、Ｃ
Ｄ－Ｒ、ＣＤ－ＲＷ、磁気テープ、ハードディスク、メモリカード）等としての実施態様
をとることも可能である。

また、プログラムの実装形態としては、コンパイラによってコンパイルされるオブジェ
クトコード、インタプリタにより実行されるプログラムコード等のアプリケーションプロ
グラムに限定されることはなく、オペレーティングシステムに組み込まれるプログラムモ
ジュール等の形態であっても良い。

さらに、プログラムは、必ずしも制御基板上のＣＰＵにおいてのみ、全ての処理が実施
される必要はなく、必要に応じて基板に付加された拡張ボードや拡張ユニットに実装され
た別の処理ユニット（ＤＳＰ等）によってその一部又は全部が実施される構成とすること
もできる。

本明細書（特許請求の範囲、要約、及び図面を含む）に記載された構成要件の全て及び
／又は開示された全ての方法又は処理の全てのステップについては、これらの特徴が相互
に排他的である組合せを除き、任意の組合せで組み合わせることができる。

また、本明細書（特許請求の範囲、要約、及び図面を含む）に記載された特徴の各々は
、明示的に否定されない限り、同一の目的、同等の目的、または類似する目的のために働
く代替の特徴に置換することができる。したがって、明示的に否定されない限り、開示さ
れた特徴の各々は、包括的な一連の同一又は均等となる特徴の一例にすぎない。

さらに、本発明は、上述した実施形態のいずれの具体的構成にも制限されるものではな
い。本発明は、本明細書（特許請求の範囲、要約、及び図面を含む）に記載された全ての
新規な特徴又はそれらの組合せ、あるいは記載された全ての新規な方法又は処理のステッ
プ、又はそれらの組合せに拡張することができる。

１０ 本人確認支援システム
１１（１１－１～１１－ｎ） サービスサーバ（群）
１４ａ～１４ｃ ＰＣ（拠点端末あるいは顧客端末の一形態）
１５ａ～１５ｅ タブレット端末（拠点端末あるいは顧客端末の一形態）
１７、１８（１８－１～１８－ｎ） 通信回線
１９ 公衆回線（インターネット、公衆通信網、専用回線等）

Claims (9)

1. 第１のユーザのための第１情報処理端末と、
   第２のユーザのための第２情報処理端末と、
   前記第１情報処理端末及び前記第２情報処理端末から接続されるユーザ管理サーバと
   を少なくとも備えた本人確認支援システムであって、
   前記ユーザ管理サーバは、
   前記第１情報処理端末から送信された前記第１のユーザに関するプロフィール情報を登録管理するものであって、前記プロフィール情報には少なくとも前記第１のユーザのユーザＩＤ及び認証コードが含まれ、少なくとも前記認証コードは前記第１のユーザを認証する情報として管理されており、
   前記第２のユーザによって前記第２情報処理端末に入力されることにより前記第２情報処理端末から送信された、前記第１のユーザに対する、前記第２のユーザによる前記第１のユーザのための処理の申請、及び、前記第１のユーザから前記第２のユーザに対して開示された前記認証コードを受信し、
   前記第２情報処理端末から受信した前記認証コードから前記第１のユーザの前記ユーザＩＤへ変換し、
   前記変換された前記ユーザＩＤを有する前記第１のユーザに対し、前記第２情報処理端末から送信された、前記第２のユーザによる前記第１のユーザのための処理の申請の承認可否の問い合わせを行う
   ことを特徴とするシステム。
2. 決済処理サーバをさらに備え、
   前記第１のユーザのための処理は決済処理であり、前記問い合わせの結果、前記第１のユーザから前記ユーザ管理サーバに対して承認通知があったとき、
   前記ユーザ管理サーバは、
   前記決済処理サーバに決済処理を実行させるための決済トークンを発行し、
   前記決済トークンを前記決済処理サーバへ送信する
   ことを特徴とする請求項１に記載のシステム。
3. 前記第２のユーザのための第２情報処理端末は、ＡＩ搭載デバイスである、請求項１または２に記載のシステム。
4. 前記第２情報処理端末から前記第１のユーザための処理の申請が送信されるとき、その日時及び／または場所が取得され、前記取得された日時及び／または場所は、前記第１情報処理端末上での前記承認可否の問い合わせ時に提示される、請求項１または２に記載のシステム。
5. 前記第１情報処理端末上での前記承認可否の問い合わせ時にカウントダウン表示が行われる、請求項１または２に記載のシステム。
6. 第１のユーザのための第１情報処理端末と、
   第２のユーザのための第２情報処理端末と、
   前記第１情報処理端末及び前記第２情報処理端末から接続されるユーザ管理サーバと
   を少なくとも備えた本人確認支援システム上で実行されるコンピュータプログラムであって、
   前記ユーザ管理サーバに、
   前記第１情報処理端末から送信された前記第１のユーザに関するプロフィール情報を登録管理させるステップであって、前記プロフィール情報には少なくとも前記第１のユーザのユーザＩＤ及び認証コードが含まれ、少なくとも前記認証コードを前記第１のユーザを認証する情報として管理するステップと、
   前記第２のユーザによって前記第２情報処理端末に入力されることにより前記第２情報処理端末から送信された、前記第１のユーザに対する、前記第２のユーザによる前記第１のユーザのための処理の申請、及び、前記第１のユーザから前記第２のユーザに対して開示された前記認証コードを受信させるステップと、
   前記第２情報処理端末から受信した前記認証コードから前記第１のユーザの前記ユーザＩＤへ変換させるステップと、
   前記変換された前記ユーザＩＤを有する前記第１のユーザに対し、前記第２情報処理端末から送信された、前記第２のユーザによる前記第１のユーザのための処理の申請の承認可否の問い合わせを行わせるステップと
   を実行することを特徴とするプログラム。
7. 決済処理サーバをさらに備え、
   前記第１のユーザのための処理は決済処理であり、前記問い合わせの結果、前記第１のユーザから前記ユーザ管理サーバに対して承認通知があったとき、
   前記ユーザ管理サーバに、
   前記決済処理サーバに決済処理を実行させるための決済トークンを発行させるステップと、
   前記決済トークンを前記決済処理サーバへ送信させるステップと
   を実行することを特徴とする請求項６に記載のプログラム。
8. 前記第２のユーザのための第２情報処理端末は、ＡＩ搭載デバイスである、請求項６または７に記載のプログラム。
9. 第１のユーザのための第１情報処理端末と、
   第２情報処理端末と、
   前記第１情報処理端末及び前記第２情報処理端末から接続されるユーザ管理サーバと
   を少なくとも備えた本人確認支援システムであって、
   前記第２情報処理端末は、ＡＩ搭載デバイスであり、
   前記ユーザ管理サーバは、
   前記第１情報処理端末から送信された前記第１のユーザに関するプロフィール情報を登録管理するものであって、前記プロフィール情報には少なくとも前記第１のユーザのユーザＩＤ及び認証コードが含まれ、少なくとも前記認証コードは前記第１のユーザを認証する情報として管理されており、
   前記第２情報処理端末から送信された、前記第１のユーザに対する、前記第２情報処理端末による前記第１のユーザのための処理の申請、及び、前記第１のユーザから前記第２情報処理端末に対して開示された前記認証コードを受信し、
   前記第２情報処理端末から受信した前記認証コードから前記第１のユーザの前記ユーザＩＤへ変換し、
   前記変換された前記ユーザＩＤを有する前記第１のユーザに対し、前記第２情報処理端末から送信された、前記第２情報処理端末による前記第１のユーザのための処理の申請の承認可否の問い合わせを行う
   ことを特徴とするシステム。