(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-05-23
(45)【発行日】2024-05-31
(54)【発明の名称】本人確認支援システム及びプログラム
(51)【国際特許分類】
G06Q 20/42 20120101AFI20240524BHJP
【ＦＩ】
G06Q20/42
【請求項の数】
10
(21)【出願番号】P 2022199987
(22)【出願日】2022-12-15
【審査請求日】2023-01-12
【審判番号】
【審判請求日】2023-11-10
【早期審査対象出願】
(73)【特許権者】
【識別番号】500183607
【氏名又は名称】藤沢 和則
(74)【代理人】
【識別番号】100092783
【弁理士】
【氏名又は名称】小林 浩
(74)【代理人】
【識別番号】100136744
【弁理士】
【氏名又は名称】中村 佳正
(72)【発明者】
【氏名】藤沢 和則
【合議体】
【審判長】伏本 正典
【審判官】佐藤 智康
【審判官】松田 直也
(56)【参考文献】
【文献】特開２０２１－２６４９４（ＪＰ，Ａ）
【文献】特開２０１６－１７０５６５（ＪＰ，Ａ）
【文献】特開２０１３－２０６２００（ＪＰ，Ａ）
【文献】特開２００９－５３８０４（ＪＰ，Ａ）
【文献】特開２０２０－５２７６１（ＪＰ，Ａ）
【文献】特開２０２１－８６２５３（ＪＰ，Ａ）
【文献】特開２０２１－１１７８３５（ＪＰ，Ａ）
【文献】特開２０２１－１７７２９８（ＪＰ，Ａ）
【文献】特開２０２１－１１７６６７（ＪＰ，Ａ）
【文献】特表２０１９－５０９５７８（ＪＰ，Ａ）
【文献】特表２０１４－５２７２２６（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
第１のユーザのための第１情報処理端末と、第２のユーザのための第２情報処理端末と、
前記第１情報処理端末及び前記第２情報処理端末から接続されるユーザ管理サーバと
を少なくとも備えた本人確認支援システムであって、
前記ユーザ管理サーバは、
前記第１情報処理端末から送信された前記第１のユーザに関するプロフィール情報を登録管理するものであって、前記プロフィール情報には少なくとも前記第１のユーザのユーザＩＤ及び認証コードが含まれ、少なくとも前記認証コードは前記第１のユーザを認証する情報として管理されており、
前記第２のユーザによって前記第２情報処理端末に入力されることにより前記第２情報処理端末から送信された、前記第１のユーザに対する前記第２のユーザ自身の支払いのための処理の申請、及び、前記第１のユーザから前記第２のユーザに対して開示された前記認証コードを受信し、
前記第２情報処理端末から受信した前記認証コードから前記第１のユーザの前記ユーザＩＤへ変換し、
前記変換された前記ユーザＩＤを有する前記第１のユーザに対し、前記第２情報処理端末から送信された前記第１のユーザに対する前記第２のユーザ自身の支払いのための処理の申請の承認可否の問い合わせを行う
ことを特徴とするシステム。
【請求項2】
決済処理サーバをさらに備え、前記第１のユーザのための処理は決済処理であり、前記問い合わせの結果、前記第１のユーザから前記ユーザ管理サーバに対して承認通知があったとき、
前記ユーザ管理サーバは、
前記決済処理サーバに決済処理を実行させるための決済トークンを発行し、
前記決済トークンを前記決済処理サーバへ送信する
ことを特徴とする請求項１に記載のシステム。
【請求項3】
前記第２のユーザのための第２情報処理端末は、ＡＩ搭載デバイスである、請求項１または２に記載のシステム。
【請求項4】
前記第２情報処理端末から前記第１のユーザための処理の申請が送信されるとき、その日時及び／または場所が取得され、前記取得された日時及び／または場所は、前記第１情報処理端末上での前記承認可否の問い合わせ時に提示される、請求項１または２に記載のシステム。
【請求項5】
前記第１情報処理端末上での前記承認可否の問い合わせ時にカウントダウン表示が行われる、請求項１または２に記載のシステム。
【請求項6】
第１のユーザのための第１情報処理端末と、第２のユーザのための第２情報処理端末と、
前記第１情報処理端末及び前記第２情報処理端末から接続されるユーザ管理サーバと
を少なくとも備えた本人確認支援システム上で実行されるコンピュータプログラムであって、
前記ユーザ管理サーバに、
前記第１情報処理端末から送信された前記第１のユーザに関するプロフィール情報を登録管理させるステップであって、前記プロフィール情報には少なくとも前記第１のユーザのユーザＩＤ及び認証コードが含まれ、少なくとも前記認証コードを前記第１のユーザを認証する情報として管理するステップと、
前記第２のユーザによって前記第２情報処理端末に入力されることにより前記第２情報処理端末から送信された、前記第１のユーザに対する前記第２のユーザ自身の支払いのための処理の申請、及び、前記第１のユーザから前記第２のユーザに対して開示された前記認証コードを受信させるステップと、
前記第２情報処理端末から受信した前記認証コードから前記第１のユーザの前記ユーザＩＤへ変換させるステップと、
前記変換された前記ユーザＩＤを有する前記第１のユーザに対し、前記第２情報処理端末から送信された前記第１のユーザに対する前記第２のユーザ自身の支払いのための処理の申請の承認可否の問い合わせを行わせるステップと
を実行することを特徴とするプログラム。
【請求項7】
決済処理サーバをさらに備え、前記第１のユーザのための処理は決済処理であり、前記問い合わせの結果、前記第１のユーザから前記ユーザ管理サーバに対して承認通知があったとき、
前記ユーザ管理サーバに、
前記決済処理サーバに決済処理を実行させるための決済トークンを発行させるステップと、
前記決済トークンを前記決済処理サーバへ送信させるステップと
を実行することを特徴とする請求項６に記載のプログラム。
【請求項8】
前記第２のユーザのための第２情報処理端末は、ＡＩ搭載デバイスである、請求項６または７に記載のプログラム。
【請求項9】
前記第２情報処理端末から前記第１のユーザための処理の申請が送信されるとき、その日時及び／または場所が取得され、前記取得された日時及び／または場所は、前記第１情報処理端末上での前記承認可否の問い合わせ時に提示される、請求項６または７に記載のプログラム。
【請求項10】
前記第１情報処理端末上での前記承認可否の問い合わせ時にカウントダウン表示が行われる、請求項６または７に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、広くユーザ本人による電子処理手続きであることの確認を支援するためのシステム等に関し、より詳細には、ユーザ本人以外のユーザからの代理申請処理手続きを含む処理がユーザ本人の意思に基づく処理であることの確認を支援するためのシステム等に関する。
【背景技術】
【0002】
近年、申請処理手続きや決済処理手続きを含め、ユーザ本人の処理手続きであるかどうかを確認したり認証したりするためのシステム等が運用されており、様々な改善が提案されている。
【0003】
例えば、システムを介した送金手続きにおいて、送金者が安心して送金をおこなうための送金支援装置、送金支援方法、および送金支援プログラムが提案されている（特許文献１）。
【0004】
特許文献１には、例えば、あらかじめ連絡先が登録された受取者に宛てて送金をおこなう旨の依頼を送金者から受け付けた場合に、前記受取者に前記送金がおこなわれる旨の通知をおこなう通知部と、前記通知により前記送金がおこなわれることの承諾を前記受取者から受け付ける受付部と、前記受付部によって受け付けられた前記承諾に応じて、前記送金を実行する送金制御部と、を備えたことを特徴とする送金支援装置が開示されている。
ここで、前記承諾は、前記受取者の認証を含むことがあり、また、前記通知部は、前記送金を示す所定の文字列の入力を含む前記依頼を前記送金者から受け付けた場合に、前記所定の文字列を含む前記通知をおこなうことを含む場合がある。
ここで、前記承諾は、前記受取者の認証を含むことがあり、また、前記通知部は、前記送金を示す所定の文字列の入力を含む前記依頼を前記送金者から受け付けた場合に、前記所定の文字列を含む前記通知をおこなうことを含む場合がある。
【0005】
また、ＥメールまたはＳＮＳで商品の購入確認を行うメッセージ決済システム、メッセージ決済装置、メッセージ決済方法及びメッセージ決済プログラムも提案されている（特許文献２）。
【0006】
すなわち、特許文献２には、入出力部を備えた端末装置、および、記憶部と制御部とを備えたメッセージ決済装置を通信可能に接続したメッセージ決済システムであって、前記記憶部は、商品の商品データを記憶する商品記憶手段と、前記端末装置でのオンライン決済の登録者の登録者識別データとオンラインアカウントと決済方法データとを含む登録データを記憶する登録記憶手段と、を備え、前記制御部は、前記商品データを前記端末装置に表示させるように制御する商品画面表示制御手段と、前記端末装置の前記入出力部を介して購入商品が決定された場合、前記オンラインアカウントに基づいて、前記商品の購入詳細データを含む購入確認通知を前記端末装置に送信する購入確認通知手段と、前記端末装置の前記入出力部を介して前記購入確認通知に含まれる前記商品の購入確認表示が選択された場合、前記商品の支払処理画面を前記端末装置に表示させるように制御する支払処理画面表示制御手段と、前記端末装置の前記入出力部を介して支払承認が入力された場合、前記商品の支払処理を実行する支払実行手段と、を備えたことを特徴とするメッセージ決済システムが開示されている。
【先行技術文献】
【特許文献】
【0007】
【文献】特開２０１９－０２８８６３号公報
【文献】特開２０２０－０３８５７８号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
しかしながら、上記従来の技術においては、さらに多様なユーザニーズに応えることを可能にするための更なる改善が期待される。
【0009】
一方、本出願の出願時点においても、例えば、図９～図１１に示されるような従来技術が提供されている。まず、図９及び図１０を参照して、ＲＦＣ６７４９で定義されているＯＡｕｔｈ２．０承認フレームワークをベースとした従来の認可システムにおける認可処理フロー例を説明する。
【0010】
図９には、ユーザの情報処理端末（同図において、不図示）のディスプレイ上にウェブブラウザ９１０が表示されている。ウェブブラウザ９１０は、クライアントアプリケーションから提供されるインタフェースである。
また、同図には、認可サーバとして９２０が表されている。同図に示されるように、認可サーバ９２０は、認可エンドポイント９２１を備える。
また、同図には、認可サーバとして９２０が表されている。同図に示されるように、認可サーバ９２０は、認可エンドポイント９２１を備える。
【0011】
ウェブブラウザ９１０は、タブ９１１を含み、タブ９１１は、ＵＲＬを入力するための入力欄９１１１を備える。ユーザは、この入力欄に認可を申請したいサーバのＵＲＬを含むリクエストを入力する。この入力は、必ずしも手動である必要はなく、例えば、図示しないボタンを押下することにより自動的に入力され、送信されることもできる。
本発明は、これに限定されるものではないが、入力欄９１１１に入力される事項は、次表に例示されるとおりである。
本発明の一実施形態においては、これらの事項がＨＴＭＬフォーマットに従ったＵＲＬとして入力される。
本発明は、これに限定されるものではないが、入力欄９１１１に入力される事項は、次表に例示されるとおりである。
【表1】
【0012】
図９において、入力欄９１１１に認可リクエストを表すＵＲＬをウェブブラウザ９１０に与えると、ウェブブラウザ９１０は、認可サーバ９２０の認可エンドポイント９２１に向けてメッセージを送信する（ステップＳ９０１）。
【0013】
次に、図１０に、図９においてウェブブラウザ９１０からのメッセージを受信した認可サーバ９２０の処理フローを示す。ウェブブラウザ１０１０、認可サーバ１０２０、認可エンドポイント１０２１は、ウェブブラウザ９１０、認可サーバ９２０、認可エンドポイント９２１にそれぞれ対応する。
【0014】
図１０において、認可エンドポイント１０２１は、受信したメッセージを処理し、認可画面を示すＨＴＭＬをブラウザ１０１０へ返信する（ステップＳ１００１）。このとき、一実施形態においては、いわゆる「リダイレクト機能」が利用される。
すると、ブラウザ１０１０では、認可画面がタブ１０１１として準備され、ブラウザ上に同図に示されるような認可画面が表示される。
すると、ブラウザ１０１０では、認可画面がタブ１０１１として準備され、ブラウザ上に同図に示されるような認可画面が表示される。
【0015】
図１０において、タブ１０１１には、入力欄１０１１１のほか、認可画面を構成するアイテムが表示されている。
まず、クライアントアプリケーションが権限を求めている旨のメッセージ１０１２と、その権限の内容（プロフィール参照権限）１０１３とが表示されている。その下欄には、承認を与えるユーザのログインＩＤとパスワードを入力するための入力欄１０１３及び１０１４が表示され、承認ボタン１０１５及び拒否ボタン１０１６が表示されている。
一実施形態として、ユーザがクライアントアプリケーションに対してプロフィール参照の権限を与える場合には、入力欄１０１３に自身のログインＩＤを入力し、入力欄１０１４に自身のパスワードを入力して、承認ボタン１０１５を押下する。
すると、ユーザの承認の結果は、ＨＴＴＰリクエストとして、再び認可サーバ１０２０へ送信される。
まず、クライアントアプリケーションが権限を求めている旨のメッセージ１０１２と、その権限の内容（プロフィール参照権限）１０１３とが表示されている。その下欄には、承認を与えるユーザのログインＩＤとパスワードを入力するための入力欄１０１３及び１０１４が表示され、承認ボタン１０１５及び拒否ボタン１０１６が表示されている。
一実施形態として、ユーザがクライアントアプリケーションに対してプロフィール参照の権限を与える場合には、入力欄１０１３に自身のログインＩＤを入力し、入力欄１０１４に自身のパスワードを入力して、承認ボタン１０１５を押下する。
すると、ユーザの承認の結果は、ＨＴＴＰリクエストとして、再び認可サーバ１０２０へ送信される。
【0016】
このように、図９及び図１０に示された従来の認可システムにおける認可処理フローの１つの特徴は、ユーザの認可画面（タブ１０１１）は、認可申請を行った画面（タブ９１１）を生成したブラウザと同一のブラウザ上に生成されることである。
【0017】
次に、図１１に、従来の認可システムにおける他の認可処理フロー例を示す。この認可処理フローは、ＣＩＢＡ（OpenID Connect Client Initiated Backchannel Authentication Flow）に基づく処理例である。
【0018】
図１１においては、まず、クライアントアプリケーション１１１０からは、認可サーバ１１２０のバックチャネル認証エンドポイント１１２１に対して認証リクエストが送信される（ステップＳ１１０１）。このとき、認可サーバ１１２０では、受信した認証リクエストに対してはすぐに応答する（ステップＳ１１０２）。
【0019】
その後、認可サーバでは、受信された認証リクエストの内容を解析し、ユーザ認証を行い、特定されたユーザに対して承認問合せ通知（または同意取得）を認証デバイス１１３０に対して行う（ステップＳ１１０３）。
【0020】
承認問合せ通知を受けた認証デバイス１１３０では、このデバイスの所有者であるユーザに対して、任意のＧＵＩを介して承認可否の問い合わせを行い、その結果を取得して認可サーバ１１２０へ送信する（ステップＳ１１０４）。
【0021】
このように、図１１に示された従来の認可システムにおける他の認可フローの特徴は、ユーザ認証後の同意取得方法については、認証デバイスに一任されることである。この場合、認証デバイス１１２０は、クライアントアプリケーション１１１０が動作するデバイスと必ずしも同一である必要はない。
【0022】
本発明の一実施形態にかかるシステム等は、図９～図１１を参照して説明した従来技術においても実現されていなかった技術、例えば、ユーザ本人以外のユーザからの代理申請手続きを含む手続きがユーザ本人の意思に基づく手続きであることを確認するための改善された技術を提供することを目的としている。
【課題を解決するための手段】
【0023】
そこで、本発明の一実施形態にかかるシステム等は、第１のユーザのための第１情報処理端末と、第２のユーザのための第２情報処理端末と、前記第１情報処理端末及び前記第２情報処理端末から接続されるユーザ管理サーバとを少なくとも備えた本人確認支援システムであって、前記ユーザ管理サーバは、前記第１情報処理端末から送信された前記第１のユーザに関するプロフィール情報を登録するものであって、前記プロフィール情報には少なくとも前記第１のユーザのユーザＩＤ及びニックネームが含まれ、前記第２情報処理端末から送信された前記第１のユーザための処理の申請及び前記ニックネームを受信し、前記第２情報処理端末から受信した前記ニックネームから前記第１のユーザの前記ユーザＩＤへ変換し、前記変換された前記ユーザＩＤを有する前記第１のユーザに対し、前記第２情報処理端末から送信された前記第１のユーザための処理の申請の承認可否の問い合わせを行うことを特徴とする。
【0024】
また、決済処理サーバをさらに備え、前記第１のユーザのための処理は決済処理であり、前記問い合わせの結果、前記第１のユーザから前記ユーザ管理サーバに対して承認通知があったとき、前記ユーザ管理サーバは、前記決済サーバに決済処理を実行させるための決済トークンを発行し、前記決済トークンを前記決済サーバへ送信することを特徴とする。
【発明の効果】
【0025】
本発明の一実施形態にかかるシステム等によれば、多様なユーザニーズに応えることのできるシステム等を提供することができる等の有利な効果を奏する。例えば、ユーザ本人以外のユーザからの代理申請手続きを含む手続きがユーザ本人の意思に基づく手続きであることを確認するための改善されたシステム等を提供することができる。
【図面の簡単な説明】
【0026】
【図1】本発明の一実施形態にかかる本人確認支援システムの全体構成例を説明する説明図である。
【図2】本発明の一実施形態にかかる本人確認支援システムにおけるサーバの機能ブロック構成を説明する説明図である。
【図3】本発明の一実施形態にかかる本人確認支援システムにおける情報処理端末の機能ブロック構成を説明する説明図である。
【図4】本発明の一実施形態にかかる本人確認支援システムのシステム構成例及び処理フローの概念例を説明する説明図である。
【図5】本発明の一実施形態にかかる本人確認支援システムにおける詳細な処理フロー例を説明する説明図である。
【図6】本発明の一実施形態にかかる本人確認支援システムにおける詳細な処理フロー例を説明する説明図である。
【図7】本発明の一実施形態にかかる本人確認支援システムにおける情報処理端末の画面表示例を説明する説明図である。
【図8A】本発明の一実施形態にかかる本人確認支援システムにおける情報処理端末の画面表示例を説明する説明図である。
【図8B】本発明の一実施形態にかかる本人確認支援システムにおける情報処理端末の画面表示例を説明する説明図である。
【図9】従来の認可システムにおける認可処理フロー例を説明する説明図である。
【図10】従来の認可システムにおける認可処理フロー例を説明する説明図である。
【図11】従来の認可システムにおける他の認可処理フロー例を説明する説明図である。
【発明を実施するための形態】
【0027】
以下、本発明の一実施形態にかかる本人確認支援システム等について、図面を参照しながら詳細に説明する。
【0028】
図１に、本発明の一実施形態にかかる本人確認支援システムの全体構成例を示す。
図１に示されるように、本人確認支援システム１０は、その一実施形態における大別的な構成として、サービスサーバ（群）１１と、店舗等の拠点に配置されて店員等に使用されたり、顧客等が所持して使用したりする各種情報処理端末（図において、例示的に、ＰＣ１４ａ～１４ｃ、ならびに、携帯情報端末、タブレット端末１５ａ～１５ｅが示されている。以下、総称して「各種端末」あるいは単に「端末」とも言うこともある）で構成されている。
サービスサーバ（群）には、ユーザ管理サーバ、認証サーバ、決済サーバ等の各種情報処理サービスをサーバが含まれる。例示的に、図１においては、１１－１～１１－ｎまでのｎ台のサービスサーバ群が想定されている（ｎは、１以上の自然数）。
なお、各種端末数は、図示されたものに限られず、任意である。例えば、顧客端末については、顧客数に応じた数が想定されることができる。また、拠点に配置される端末についても、拠点ごとに１以上の端末が配置されてもよい。
図１に示されるように、本人確認支援システム１０は、その一実施形態における大別的な構成として、サービスサーバ（群）１１と、店舗等の拠点に配置されて店員等に使用されたり、顧客等が所持して使用したりする各種情報処理端末（図において、例示的に、ＰＣ１４ａ～１４ｃ、ならびに、携帯情報端末、タブレット端末１５ａ～１５ｅが示されている。以下、総称して「各種端末」あるいは単に「端末」とも言うこともある）で構成されている。
サービスサーバ（群）には、ユーザ管理サーバ、認証サーバ、決済サーバ等の各種情報処理サービスをサーバが含まれる。例示的に、図１においては、１１－１～１１－ｎまでのｎ台のサービスサーバ群が想定されている（ｎは、１以上の自然数）。
なお、各種端末数は、図示されたものに限られず、任意である。例えば、顧客端末については、顧客数に応じた数が想定されることができる。また、拠点に配置される端末についても、拠点ごとに１以上の端末が配置されてもよい。
【0029】
本発明の一実施形態において、サービスサーバ（群）１１、各種端末間は、図１に示されるように専用回線やインターネット等の公衆回線（有線の回線として、１７、１８－１～１８－ｎ、３９）を介して相互に通信可能に接続されている。
【0030】
また、回線は、有線であっても無線であってもよい。回線が無線の場合、各種端末１４ａ～１４ｂ、１５ａ～１５ｅは、無線で図示しない基地局やアクセスポイント等を介してインターネット１９に乗り入れ、さらに、サーバ１１－１～１１－ｎへ接続する回線１８－１～１８－ｎを介してサービスサーバ（群）１１と相互に通信可能に接続される。
【0031】
ここで、アクセスポイントとは、ＰＣやスマートフォンなどの無線端末を相互に接続したり、他のネットワークに接続させたりするための無線機である。典型的には、ＯＳＩ参照モデルにおける第１層（物理層）及び第２層（データリンク層）の通信プロトコルで作動するデバイスである。
【0032】
また、本願の出願時点での携帯情報端末やタブレットは、パーソナルコンピュータ（ＰＣ）と同等かそれ以上の処理能力（通信処理速度や画像処理能力等）を備えているものも多く、小型の高性能コンピュータとも言うべきものである。
【0033】
さらに、本発明の実施に必要なプログラムないしソフトウェアは、通常、ＰＣや携帯情報端末の記憶部におけるＨＤＤ、ＳＳＤ等にインストールないし記憶され、プログラムないしソフトウェアの実行時には、必要に応じて記憶部内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵにおいて演算実行される。
【0034】
あるいは、ブラウザベースのコンピュータないし携帯情報端末を採用することもできる。この場合は、必要に応じて他のサーバやコンピュータから端末にプログラムが配信され、端末上のブラウザではこれを実行するという構成になる。
【0035】
また、サービスサーバ（群）１１のハードウェア構成も、基本的にはＰＣを採用することができる（念のため、図２を参照して後述する）。なお、本発明はこれに限定されるものではないが、サービスサーバ（群）１１は、必要に応じてそのハードウェアスペックを上げるにあたり、複数のＰＣ（一例として、数十台～数万台）を並列的に作動させることによって大規模データの処理に適した構成をとることもできる。
【0036】
図２に、本発明の一実施形態にかかる本人確認支援システムにおけるサーバ（サービスサーバ（群）１１における１つのサーバに相当する。以下、「情報処理サーバ」ともいう。）の機能ブロック図を示す。例示的に、サーバの動作は、以下に説明するハードウェアの個々の動作、及びソフトウェアとこれらハードウェアとの連携動作によって実現されている。
【0037】
図２において、ハードウェアブロック全体としてのサーバ３００は、大別すると、各種比較・演算処理を行うためのＣＰＵ２０１と、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の記憶部２０２と、キーボードやポインティングデバイス等の入力部２０３と、ディスプレイやスピーカ等の出力部２０４と、各種信号制御のための制御部２０５と、通信（インタフェース）部２０６（無線、有線を問わない）と、時刻等を計時するための計時部２０７と、電源部２０８とからなる。
【0038】
これらのモジュールは必要に応じて適宜通信バスや給電線（図２においては、便宜上これらの通信バスや給電線といった各線が適宜含まれる結線２９９として表す）によって接続されている。
【0039】
また、本発明の実施に必要なサーバ２００上で実行されるプログラムないしソフトウェアは、通常、記憶部２０２を構成するハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリ等にインストールないし記憶され、プログラムないしソフトウェアの実行時には、必要に応じて記憶部２０２内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵ２０１において演算実行される。
【0040】
なお、演算実行は必ずしもＣＰＵ２０１等の中央処理部で行われる必要はなく、図示しないディジタルシグナルプロセッサ（ＤＳＰ）、ＧＰＵ（Graphics Processing Unit）やＴＰＵ（Tensor processing unit）等の補助演算装置を用いることもできる。
【0041】
図３に、本発明の一実施形態にかかる顧客端末としてのタブレット端末１５ａを構成するハードウェアの機能ブロック図を例示する。タブレット端末１５ａの動作は、以下に説明するハードウェアの個々の動作、及びソフトウェアとこれらハードウェアとの連携動作によって実現されている。
【0042】
図３において、ハードウェアブロック全体としてのタブレット端末３００は、大別すると、ハードウェアボタン、ディスプレイに設けられたマルチタッチ入力パネル、マイク等で構成される入力部３０１と、プログラムやデータ等を記憶するためのハードディスク、ＲＡＭ及び／又はＲＯＭ等で構成される記憶部３０２と、プログラムによって様々な数値計算や論理演算を行うＣＰＵによって構成される中央処理部３０３と、ディスプレイ等で構成される表示部３０４と、チップや電気系統等の制御を行うための制御部３０５と、インターネットにアクセスするためのスロットや光通信を行うためのポート、及び通信インタフェースから構成される通信インタフェース部３０６と、スピーカやバイブレーション、赤外線プロジェクター等の出力部３０７と、時刻等を計時するための計時部３０８と、ＣＭＯＳ等のイメージセンサや赤外線センサ、慣性センサ等からなるセンサ部３０９と、装置内の各モジュールに電源を供給するための電源部３１０とからなり、これらのモジュールは必要に応じて適宜通信バスや給電線（図３においては、便宜上これらの通信バスや給電線といった各線が適宜含まれる結線３９９として表す）によって接続されている。
なお、センサ部３０９には、タブレット端末３００（１５ａ）の位置を特定するためのＧＰＳセンサモジュールを含めることとしても良い。センサ部３０９を構成するＣＭＯＳ等のイメージセンサや赤外線センサ等によって検知された信号は、入力部３０１において入力情報として処理することができる。
なお、センサ部３０９には、タブレット端末３００（１５ａ）の位置を特定するためのＧＰＳセンサモジュールを含めることとしても良い。センサ部３０９を構成するＣＭＯＳ等のイメージセンサや赤外線センサ等によって検知された信号は、入力部３０１において入力情報として処理することができる。
【0043】
また、本発明の実施に必要なタブレット端末３００上で実行されるプログラムないしソフトウェアは、通常、記憶部３５２を構成するハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリ等にインストールないし記憶され、プログラムないしソフトウェアの実行時には、必要に応じて記憶部３０２内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵ３０３において演算実行される。
【0044】
なお、演算実行は必ずしもＣＰＵ等の中央処理部３０３で行われる必要はなく、図示しないディジタルシグナルプロセッサ（ＤＳＰ）、ＧＰＵ（Graphics Processing Unit）やＴＰＵ（Tensor processing unit）等の補助演算装置を用いることもできる。
【0045】
（本発明の基本概念）
本発明は、次のような基本概念を有する。
（１）基本的に、３者間でのやり取りを支援する。代理申請者または代理注文者であるユーザＡと、決済者または承認者であるユーザＢと、認証機関または決済機関である情報処理サーバである。ユーザＡ及びユーザＢは、図１における携帯情報端末１４ａ～１４ｃ、１５ａ～１５ｅのうち、それぞれ少なくとも１台を使用する。認証機関または決済機関は、図１におけるサービスサーバ（群）１１における少なくとも１つのサーバである。
本発明は、次のような基本概念を有する。
（１）基本的に、３者間でのやり取りを支援する。代理申請者または代理注文者であるユーザＡと、決済者または承認者であるユーザＢと、認証機関または決済機関である情報処理サーバである。ユーザＡ及びユーザＢは、図１における携帯情報端末１４ａ～１４ｃ、１５ａ～１５ｅのうち、それぞれ少なくとも１台を使用する。認証機関または決済機関は、図１におけるサービスサーバ（群）１１における少なくとも１つのサーバである。
【0046】
（２）基本的な動作の流れ
（Ａ）あらかじめ認証済のユーザＢの認証コード（ニックネームや合言葉など。以下、「ニックネーム」という。）は、ユーザＡに開示されている。このコードは、ユーザＡとユーザＢとの間のいわば秘密情報として共有されている。
ユーザＡは、認証サーバまたは決済サーバに対して、ユーザＢのための代理手続き承認申請または代理決済申請を行う。このとき、ユーザＢの認証コード（ニックネーム）をサーバに送信する。この申請処理は、必ずしもユーザＡが所持する情報処理端末から実行されるとは限らない。例えば、店舗に設置された店舗端末などからユーザＡが申請処理を行う場合もある。
（Ｂ）認証サーバまたは決済サーバは、ユーザＡから申請された内容（ユーザＢのための手続きや決済）を実行するにあたり、まず、ユーザＡから送られてきたユーザＢの認証コード（ニックネーム）からユーザＢ本人の情報を抽出する。次に、ユーザＢに対して確認通知を行う（「いま、ユーザＡからあなたのための手続きのための申請がきています。承認されますか？」など）。
（Ｃ）ユーザＢは、認証サーバまたは決済サーバからの通知内容に異存がなければ、承認処理を行う。
（Ｄ）ユーザＢの承認に基づき、認証サーバまたは決済サーバは、ユーザＡから申請された手続き処理を許可したり実行したりする。
（Ａ）あらかじめ認証済のユーザＢの認証コード（ニックネームや合言葉など。以下、「ニックネーム」という。）は、ユーザＡに開示されている。このコードは、ユーザＡとユーザＢとの間のいわば秘密情報として共有されている。
ユーザＡは、認証サーバまたは決済サーバに対して、ユーザＢのための代理手続き承認申請または代理決済申請を行う。このとき、ユーザＢの認証コード（ニックネーム）をサーバに送信する。この申請処理は、必ずしもユーザＡが所持する情報処理端末から実行されるとは限らない。例えば、店舗に設置された店舗端末などからユーザＡが申請処理を行う場合もある。
（Ｂ）認証サーバまたは決済サーバは、ユーザＡから申請された内容（ユーザＢのための手続きや決済）を実行するにあたり、まず、ユーザＡから送られてきたユーザＢの認証コード（ニックネーム）からユーザＢ本人の情報を抽出する。次に、ユーザＢに対して確認通知を行う（「いま、ユーザＡからあなたのための手続きのための申請がきています。承認されますか？」など）。
（Ｃ）ユーザＢは、認証サーバまたは決済サーバからの通知内容に異存がなければ、承認処理を行う。
（Ｄ）ユーザＢの承認に基づき、認証サーバまたは決済サーバは、ユーザＡから申請された手続き処理を許可したり実行したりする。
【0047】
（本発明が実施されるシーン例）
本発明は、これらに制限されるものではないが、次のような実施のシーンが想定される。
本発明は、これらに制限されるものではないが、次のような実施のシーンが想定される。
【0048】
（シーン１）酒場でユーザＢがユーザＡにご馳走する場合
ユーザＡとユーザＢは、ともに酒場で飲んでいる。その日の会計はユーザＢが持つこととなった。一方、ユーザＡはいま自分の情報処理端末を所持していない。また、ユーザＢはいま自分の情報処理端末を所持しているが、ネット決済について多くの知識を有しているわけではない。ただし、ユーザＢは、本件発明に基づく本人情報登録を認証サーバまたは決済サーバに対して済ませており、その認証コードの一形態として自分の「ニックネーム」を覚えているだけである。
ユーザＢは、自身の「ニックネーム」をユーザＡに伝えて、ユーザＡに会計に行かせる。ユーザＡはレジに行き、店員に対して本件発明にかかる支援システムによる決済処理を申し出る。すると、店員は店舗端末に対し、２人の会計の金額の確認及びニックネームの入力を求める。ユーザＡは、ユーザＢから聞いたニックネームを店員に伝え、店員はこれを入力する。
すると、認証サーバまたは決済サーバは、送信されてきた認証用の認証コード（ニックネーム）から本人（ユーザＢ）を割り出し、ユーザＢに対して決済処理申請及びその内容の確認通知を行う。
ユーザＢは、自身が有する端末に送信されてきた確認通知から決済金額とニックニームを知らされ、異存がなければ承認処理を行う。
認証サーバまたは決済サーバは、決済処理を実行する。
ユーザＡとユーザＢは、ともに酒場で飲んでいる。その日の会計はユーザＢが持つこととなった。一方、ユーザＡはいま自分の情報処理端末を所持していない。また、ユーザＢはいま自分の情報処理端末を所持しているが、ネット決済について多くの知識を有しているわけではない。ただし、ユーザＢは、本件発明に基づく本人情報登録を認証サーバまたは決済サーバに対して済ませており、その認証コードの一形態として自分の「ニックネーム」を覚えているだけである。
ユーザＢは、自身の「ニックネーム」をユーザＡに伝えて、ユーザＡに会計に行かせる。ユーザＡはレジに行き、店員に対して本件発明にかかる支援システムによる決済処理を申し出る。すると、店員は店舗端末に対し、２人の会計の金額の確認及びニックネームの入力を求める。ユーザＡは、ユーザＢから聞いたニックネームを店員に伝え、店員はこれを入力する。
すると、認証サーバまたは決済サーバは、送信されてきた認証用の認証コード（ニックネーム）から本人（ユーザＢ）を割り出し、ユーザＢに対して決済処理申請及びその内容の確認通知を行う。
ユーザＢは、自身が有する端末に送信されてきた確認通知から決済金額とニックニームを知らされ、異存がなければ承認処理を行う。
認証サーバまたは決済サーバは、決済処理を実行する。
【0049】
（シーン２Ａ）店員が顧客情報を使って顧客の好みの品を提案する場合
ユーザＢは、ある靴店に買い物にきた。店員であるユーザＡが対応する。ユーザＢは、本件発明に基づく支援システムの本人情報登録を認証サーバまたは決済サーバに対して済ませており、その認証コードとして「ニックネーム」を知っている。また、ユーザＢは、この靴店の常連客で自分の足型の採寸データを計測済みであり、個人情報とともに店舗サーバに保管している。
ユーザＢは、この日も新しい靴を買い求めにきており、店員であるユーザＡのアドバイスに従って自分の足に無理のない範囲でデザイン性に富んだ靴を購入したいと申し出た。あいにく、ユーザＡは新米店員で、ユーザＢの名前はおろか、個人情報も知らない（足型の採寸データへアクセスする術もない）。さらに、ユーザＢも、自分のスマホは持ってきているがこの店の会員カードを忘れてきており、ただ「ニックネーム」だけは覚えているという。
そこで、店員である新米ユーザＡは、ユーザＢからそのニックニームを聞き、店舗端末に入力することで店舗サーバ上のユーザＢの顧客情報の参照を試みた。このとき、店舗サーバとの間に入っている認証サーバまたは決済サーバが、ユーザＢに、個人情報照会がある旨を通知して許可してよいかの確認を行う。ユーザＢは、その通知内容（ニックネームを含む）を確認し、異存がなければ承認処理を行う。この承認を経たあと、店員である新米ユーザＡは、店舗サーバ上のユーザＢの顧客情報を参照してユーザＢとの商談を円滑に進めることができた。
ユーザＢは、ある靴店に買い物にきた。店員であるユーザＡが対応する。ユーザＢは、本件発明に基づく支援システムの本人情報登録を認証サーバまたは決済サーバに対して済ませており、その認証コードとして「ニックネーム」を知っている。また、ユーザＢは、この靴店の常連客で自分の足型の採寸データを計測済みであり、個人情報とともに店舗サーバに保管している。
ユーザＢは、この日も新しい靴を買い求めにきており、店員であるユーザＡのアドバイスに従って自分の足に無理のない範囲でデザイン性に富んだ靴を購入したいと申し出た。あいにく、ユーザＡは新米店員で、ユーザＢの名前はおろか、個人情報も知らない（足型の採寸データへアクセスする術もない）。さらに、ユーザＢも、自分のスマホは持ってきているがこの店の会員カードを忘れてきており、ただ「ニックネーム」だけは覚えているという。
そこで、店員である新米ユーザＡは、ユーザＢからそのニックニームを聞き、店舗端末に入力することで店舗サーバ上のユーザＢの顧客情報の参照を試みた。このとき、店舗サーバとの間に入っている認証サーバまたは決済サーバが、ユーザＢに、個人情報照会がある旨を通知して許可してよいかの確認を行う。ユーザＢは、その通知内容（ニックネームを含む）を確認し、異存がなければ承認処理を行う。この承認を経たあと、店員である新米ユーザＡは、店舗サーバ上のユーザＢの顧客情報を参照してユーザＢとの商談を円滑に進めることができた。
【0050】
（シーン２Ｂ）ＥＣサイトのオペレータが顧客に対してサービス提供する場合
ユーザＢは、本件発明に基づく支援システムの本人情報登録を認証サーバまたは決済サーバに対して済ませており、その認証コードとして「ニックネーム」を知っている。また、ユーザＢは、別途、ＥＣサイトの会員登録をしている。
ユーザＢは、ＥＣサイトで買い物をすべく、このサイトのコールセンターへ電話をかけて電話注文を行うこととした。ユーザＢがこのサイトのコールセンターへ電話をかけるとオペレータであるユーザＡが応答した。
ユーザＡ（オペレータ）は、ユーザＢに「ニックネーム」を訪ね、ユーザＢがこれに応える。ユーザＡ（オペレータ）は、ユーザＢから聞き出した「ニックネーム」を認証サーバまたは決済サーバへ入力し、ユーザＢの注文を行う権限の取得を試みる。
認証サーバまたは決済サーバは、ユーザＡ（オペレータ）による「ニックネーム」の入力を受けて、この「ニックネーム」の所有者であるユーザＢに対し注文の代行処理をさせて良いかどうかの確認通知をする。ユーザＢは、その通知内容（ニックネームを含む）を確認し、異存がなければ承認処理を行う。この承認を経たあと、ユーザＡは、ユーザＢの注文処理を代行する権限を取得し、ユーザＢとの電話での口頭でのやり取りを経て、ＥＣサイトへの注文処理及び決済処理を進めることができた。
ユーザＢは、本件発明に基づく支援システムの本人情報登録を認証サーバまたは決済サーバに対して済ませており、その認証コードとして「ニックネーム」を知っている。また、ユーザＢは、別途、ＥＣサイトの会員登録をしている。
ユーザＢは、ＥＣサイトで買い物をすべく、このサイトのコールセンターへ電話をかけて電話注文を行うこととした。ユーザＢがこのサイトのコールセンターへ電話をかけるとオペレータであるユーザＡが応答した。
ユーザＡ（オペレータ）は、ユーザＢに「ニックネーム」を訪ね、ユーザＢがこれに応える。ユーザＡ（オペレータ）は、ユーザＢから聞き出した「ニックネーム」を認証サーバまたは決済サーバへ入力し、ユーザＢの注文を行う権限の取得を試みる。
認証サーバまたは決済サーバは、ユーザＡ（オペレータ）による「ニックネーム」の入力を受けて、この「ニックネーム」の所有者であるユーザＢに対し注文の代行処理をさせて良いかどうかの確認通知をする。ユーザＢは、その通知内容（ニックネームを含む）を確認し、異存がなければ承認処理を行う。この承認を経たあと、ユーザＡは、ユーザＢの注文処理を代行する権限を取得し、ユーザＢとの電話での口頭でのやり取りを経て、ＥＣサイトへの注文処理及び決済処理を進めることができた。
【0051】
（シーン３）ＡＩが顧客にサービスする場合
ユーザＢは、本件発明に基づく支援システムの本人情報登録を認証サーバまたは決済サーバに対して済ませており、その認証コードとして「ニックネーム」を知っている。また、ユーザＢは、別途、ＥＣサイトの会員登録をしている。
ユーザＢは、ＥＣサイトで買い物をすべく、このサイトへ接続することができるスマートスピーカーを介して注文を行うこととした。ユーザＢは、ＡＩ搭載のスマートスピーカーまたはスマートスピーカシステム（ユーザＡ）に向かって「いつもの水を注文して」と語りかける。このときのユーザＡは、ＡＩ搭載デバイスである。
ユーザＡ（スマートスピーカーまたはスマートスピーカーシステム）は、ユーザＢに「ニックネーム」を訪ね、ユーザＢがこれに応える。ユーザＡは、ユーザＢから聞き出した「ニックネーム」を認証サーバまたは決済サーバへ伝達し、ユーザＢの注文を行う権限の取得を試みる。
認証サーバまたは決済サーバは、ユーザＡによる「ニックネーム」の入力を受けて、この「ニックネーム」の所有者であるユーザＢに対し注文の代行処理をさせて良いかどうかの確認通知をする。ユーザＢは、その通知内容（ニックネームを含む）を確認し、異存がなければ承認処理を行う。この承認を経たあと、ユーザＡは、ユーザＢの注文処理を代行する権限を取得し、さらに、ユーザＢの過去の購入履歴を参照して、ユーザＢがいつも注文する水を見つけ出す。ユーザＡは、ユーザＢに「○○社の天然水２Ｌ／６本入りでよろしいですか？」と問いかける。
ユーザＢがユーザＡに向かって「ＯＫ」と答えると、ユーザＡからＥＣサイトに対して注文が出されるとともに、決済処理がなされる。
ユーザＢは、本件発明に基づく支援システムの本人情報登録を認証サーバまたは決済サーバに対して済ませており、その認証コードとして「ニックネーム」を知っている。また、ユーザＢは、別途、ＥＣサイトの会員登録をしている。
ユーザＢは、ＥＣサイトで買い物をすべく、このサイトへ接続することができるスマートスピーカーを介して注文を行うこととした。ユーザＢは、ＡＩ搭載のスマートスピーカーまたはスマートスピーカシステム（ユーザＡ）に向かって「いつもの水を注文して」と語りかける。このときのユーザＡは、ＡＩ搭載デバイスである。
ユーザＡ（スマートスピーカーまたはスマートスピーカーシステム）は、ユーザＢに「ニックネーム」を訪ね、ユーザＢがこれに応える。ユーザＡは、ユーザＢから聞き出した「ニックネーム」を認証サーバまたは決済サーバへ伝達し、ユーザＢの注文を行う権限の取得を試みる。
認証サーバまたは決済サーバは、ユーザＡによる「ニックネーム」の入力を受けて、この「ニックネーム」の所有者であるユーザＢに対し注文の代行処理をさせて良いかどうかの確認通知をする。ユーザＢは、その通知内容（ニックネームを含む）を確認し、異存がなければ承認処理を行う。この承認を経たあと、ユーザＡは、ユーザＢの注文処理を代行する権限を取得し、さらに、ユーザＢの過去の購入履歴を参照して、ユーザＢがいつも注文する水を見つけ出す。ユーザＡは、ユーザＢに「○○社の天然水２Ｌ／６本入りでよろしいですか？」と問いかける。
ユーザＢがユーザＡに向かって「ＯＫ」と答えると、ユーザＡからＥＣサイトに対して注文が出されるとともに、決済処理がなされる。
【0052】
図４に、本発明の一実施形態にかかる本人確認支援システムのシステム構成例及び処理フローの概念例を示す。
【0053】
（システム構成例）
図４において、本人確認支援システム４００は、ユーザ端末である情報処理端末４０１、４０７と、ソフトウェア機能としてのアカウントアクティビティＡＰＩ（Account Activity API）４０２と、第１サービスサーバ４０３と、第２サービスサーバ４０４と、ソフトウェア機能としてのＡＰＩゲートウェイ４０５と、決済サーバ４０６とを含む。
図４において、本人確認支援システム４００は、ユーザ端末である情報処理端末４０１、４０７と、ソフトウェア機能としてのアカウントアクティビティＡＰＩ（Account Activity API）４０２と、第１サービスサーバ４０３と、第２サービスサーバ４０４と、ソフトウェア機能としてのＡＰＩゲートウェイ４０５と、決済サーバ４０６とを含む。
【0054】
ここで、アカウントアクティビティＡＰＩ４０２は、ユーザの行動履歴を確認できる機能を実装しており、具体的には、情報処理端末４０１、４０７にインストールされたＳＮＳアプリケーションのウェブフック（Web Hook）機能として実現することができる。この機能は、図９～図１１を参照して説明したウェブブラウザの機能を代替する、あるいは強化する機能である。したがって、本発明の他の実施形態においては、アカウントアクティビティＡＰＩ４０２の採用せずに、図９～図１１を参照して説明した従来のブラウザ機能を利用することもできる。
また、図４に示された実施形態においては、サービスサーバを２つに分けているが、本発明はこれに制限されるものではなく、１つのサーバでこれらの機能を実現することもできるし、３以上のサーバに機能を分散させることもできる。サービスサーバには、ユーザに関する情報を管理するためのユーザ管理サーバが含まれてもよい。
さらに、図４に示された実施形態においては、決済サーバ４０６を含むが、本発明はこれに制限されるものではなく、決済サーバ４０６に替えて、あるいは、決済サーバ４０６に加えて、他の処理系（種々のデータベースなど）と接続させることもできる。図４においては、ＡＰＩゲートウェイ４０５は、決済サーバ４０６に処理を要求するためのＡＰＩを処理するために設けられている。
また、図４に示された実施形態においては、サービスサーバを２つに分けているが、本発明はこれに制限されるものではなく、１つのサーバでこれらの機能を実現することもできるし、３以上のサーバに機能を分散させることもできる。サービスサーバには、ユーザに関する情報を管理するためのユーザ管理サーバが含まれてもよい。
さらに、図４に示された実施形態においては、決済サーバ４０６を含むが、本発明はこれに制限されるものではなく、決済サーバ４０６に替えて、あるいは、決済サーバ４０６に加えて、他の処理系（種々のデータベースなど）と接続させることもできる。図４においては、ＡＰＩゲートウェイ４０５は、決済サーバ４０６に処理を要求するためのＡＰＩを処理するために設けられている。
【0055】
本発明の他の実施形態においては、ＡＰＩゲートウェイ４０５及び決済サーバ４０６を含まない構成も採用されうることに留意されたい。つまり、本発明の他の実施形態においては、本人確認支援システムは、ユーザ端末である２以上の情報処理端末と、サービスサーバ群とで構成される。
【0056】
（処理フロー例）
図４において、ユーザＡは、情報処理端末４０１にインストールされたＳＮＳアプリケーションを使って、ユーザＢに１０ドル分の飲食費あるいは商品代金の支払いを申し出るとする。この支払は、店頭での支払いであってもネット上での決済であっても構わないが、ここでは、ネット上での決済であるとする。
このユーザＡの具体的な申し出は、ＳＮＳで「Ｂさん、１０ドルの飲食をご馳走してください。」というようなメッセージとなる（ステップＳ４ａ）。このメッセージは、ユーザＢも自身の情報処理端末４０７にインストールされたＳＮＳアプリケーションによって確認することはできるが、このままでは、ユーザＢはユーザＡの申し出に応じることはできない。
図４において、ユーザＡは、情報処理端末４０１にインストールされたＳＮＳアプリケーションを使って、ユーザＢに１０ドル分の飲食費あるいは商品代金の支払いを申し出るとする。この支払は、店頭での支払いであってもネット上での決済であっても構わないが、ここでは、ネット上での決済であるとする。
このユーザＡの具体的な申し出は、ＳＮＳで「Ｂさん、１０ドルの飲食をご馳走してください。」というようなメッセージとなる（ステップＳ４ａ）。このメッセージは、ユーザＢも自身の情報処理端末４０７にインストールされたＳＮＳアプリケーションによって確認することはできるが、このままでは、ユーザＢはユーザＡの申し出に応じることはできない。
【0057】
次に、ユーザＡの具体的な申し出（「Ｂさん、１０ドルの飲食をご馳走してください。」というメッセージ）は、アカウントアクティビティＡＰＩ４０２によって検知され、図示しないフローによって、ユーザＡに対してユーザＢのニックネームの確認が行われる（あるいは、この確認処理を行う代わりに、最初のメッセージにおいてユーザＢのニックネームが含まれていても良い）。
ユーザＡのメッセージは、第１サービスサーバ４０３に送信される（ステップＳ４ｂ）。
ユーザＡのメッセージは、第１サービスサーバ４０３に送信される（ステップＳ４ｂ）。
【0058】
次に、第１サービスサーバ４０３では、アカウントアクティビティＡＰＩ４０２を介して受信したメッセージからユーザＢのニックネームを抽出する（ステップＳ４ｃ）。そして、このニックネームを第２サービスサーバ４０４へ送信する（ステップＳ４ｄ）。
【0059】
次に、第２サービスサーバ４０４では、第１サービスサーバ４０３から受信したユーザＢのニックネームからユーザＢのＩＤを導出する（ステップＳ４ｅ）。典型的は、ユーザＢのプロフィール情報テーブルを参照してこの導出が可能となる。
第２サービスサーバ４０４は、ユーザＢのユーザＩＤに基づいて、ユーザＢの情報処理端末４０７に対して、ユーザＡからの申し出を承諾するか否かの問い合わせを行う（ステップＳ４ｆ）。
第２サービスサーバ４０４は、ユーザＢのユーザＩＤに基づいて、ユーザＢの情報処理端末４０７に対して、ユーザＡからの申し出を承諾するか否かの問い合わせを行う（ステップＳ４ｆ）。
【0060】
情報処理端末４０７では、第２サービスサーバ４０４から送信された、ユーザＡからの申し出を承諾するか否かの判断を行い、承諾または拒否の回答を行う。ここでは、承諾の回答を行うものとする。承諾の回答は、第２サービスサーバ４０４へ送信される（ステップＳ４ｇ）。
【0061】
次に、第２サービスサーバ４０４では、決済サーバ４０６に決済手続きをリクエストするためのＦＡＰＩ（Financial-grade API）トークンを発行する（ステップＳ４ｈ）。このＦＡＰＩトークンは、第１サービスサーバ４０３へ送信される。
なお、本発明の一実施形態においては、金融ＡＰＩ向けのセキュリティ標準であるＦＡＰＩを採用したが、本発明はこれに制限されず、他のセキュリティトークンを採用することもできる。
なお、本発明の一実施形態においては、金融ＡＰＩ向けのセキュリティ標準であるＦＡＰＩを採用したが、本発明はこれに制限されず、他のセキュリティトークンを採用することもできる。
【0062】
次に、第１サービスサーバ４０３は、ＡＰＩゲートウェイ４０５を介して決済サーバ４０６へ決済のためのリクエストをするが（ステップＳ４ｊ）、このとき、ＦＡＰＩトークンが送られる。また、ここでの決済は、ユーザＢによる決済として処理が進められる。
ＡＰＩゲートウェイ４０５では、送信されてきたＦＡＰＩトークンの検査を行い、決済サーバ４０６へ決済処理を依頼する。
ＡＰＩゲートウェイ４０５では、送信されてきたＦＡＰＩトークンの検査を行い、決済サーバ４０６へ決済処理を依頼する。
【0063】
ＡＰＩゲートウェイ４０５を介して決済処理の依頼を受けた決済サーバ４０６は、この依頼に基づき、ユーザＡが消費する飲食費用をユーザＢによる決済として処理する。
このようにして、ユーザＢがユーザＡに飲食代をご馳走するという一連の処理が実現される。
このようにして、ユーザＢがユーザＡに飲食代をご馳走するという一連の処理が実現される。
【0064】
図５に、本発明の一実施形態にかかる本人確認支援システムにおける動作例を示す。なお、図５及び図６に基づく説明におけるシステム構成は、図４を参照して説明したシステム構成とは異なるが、これらの違いは実現手段の相違に過ぎず、機能的にはいずれも本発明の一実施形態を説明するものとして、本発明の技術的概念の範囲内のものである。
【0065】
図５において、「ユーザ端末」は、一例として図１における端末１５ａ～１５ｅ等に対応し、「情報処理サーバ」は、図１におけるサービスサーバ（群）１１のうちの少なくとも１サーバに対応する。また、図５中、ｔ１～ｔ１０は時系列の流れを示し、経時的に後述する動作や処理が行われるものである。
【0066】
なお、実施形態において例示される動作または処理時刻（ｔ１等）は、本発明の概念の理解の容易のために例示されたものであり、本発明が実施形態において例示される個別の時系列関係に制限されることはない。
【0067】
まず、日時ｔ１において、ユーザ（顧客）は、ユーザ端末を介して情報処理サーバから自身のユーザ端末を本発明にかかる情報処理端末として動作させるためのアプリケーションソフトウェアをダウンロードする（ステップＳ５０１）。このアプリケーションソフトウェアは、本発明にかかるプログラムの一部又は全部を処理するためのクライアントソフトウェアまたはアプリケーションソフトウェアである。そして、ダウンロードしたアプリケーションソフトウェアをユーザ端末にインストールする（ステップＳ５０２）。このとき、時刻ｔ２において、ユーザ端末からは、必要に応じてユーザ登録としてユーザ自身のメールアドレスのほか、次表のようなプロフィール情報を情報処理サーバへアップロード（ステップＳ５０３）して登録管理させることもできる（ステップＳ５０４）。
また、本発明の一実施形態においては、上表に掲げたプロフィール情報のほかに、ユーザに関する他の情報（クレジットカード番号を含む決済情報）を登録管理させることもできる。
【表2】
【0068】
以上のデータ項目は、ユーザデータとして情報処理サーバ上の記憶装置に保存される（ステップＳ５０５）。時刻ｔ３以降は、ユーザ（顧客）が情報処理端末を操作することによりアプリを使用することができる。そして、サーバは、端末に対してサービスを提供する。
【0069】
次に、ユーザ端末にアプリをダウンロード及びインストールしたユーザは、時刻ｔ４においてアプリケーションソフトウェアを起動する（ステップＳ５０６）。一実施形態において、ユーザは、時刻ｔ４～時刻ｔ５まで、情報処理サーバから情報処理端末に対して提供されるサービスを受けている。
【0070】
時刻ｔ５になると、ユーザはいったん本発明の一実施形態にかかるアプリケーションソフトウェアを中断または終了する。このとき、必要に応じて、アプリケーションのステータス情報は情報処理サーバへ転送され（ステップＳ５０７）、サーバではこれを受信して当該ユーザのユーザ情報としてのステータス情報を更新（ステップＳ５０８）及び保存（ステップＳ５０９）する。図５においては、これらの処理は、時刻ｔ６までに完了している。
【0071】
なお、本発明の他の実施形態にかかるアプリケーションソフトウェアを情報処理端末にインストールした後は、端末上で少なくとも一部をクローズドに実行可能な形態とすることも可能である。この場合は、上述のステップＳ５０４～ステップＳ５０５、並びに、ステップＳ５０８～ステップＳ５０９を省略することができる。また、必要な情報は、適宜端末上のメモリに保存管理される。
【0072】
次に、図５において、時刻ｔ７～時刻ｔ１０における処理動作は、本発明の一実施形態にかかるアプリケーションソフトウェアの少なくとも一部を情報処理サーバにおいて実施する場合の実施形態例を示している。この場合、ユーザ（顧客）は、ログイン動作と、コマンド送信という２つの典型的なユーザ端末操作を行い、情報処理サーバから必要なデータ送信を受け、あるいは、サービス提供を受けることとなる。
【0073】
例えば、図５の時刻ｔ７において、ユーザは自身の情報処理端末を介してサーバへのログイン処理を行う（ステップＳ５１０）と、情報処理サーバでは必要な認証処理が適宜行われ（ステップＳ５１１）、時刻ｔ８において、ユーザがサービス提供を受けられるためのデータを送信する（ステップＳ５１２）。例えば、端末からのコマンドを受信可能に構成されたトップメニュー画面や、アプリケーションの起動画面等である。
【0074】
時刻ｔ９において、ユーザは、情報処理端末を介して何らかのコマンドを送信する（ステップＳ５１３）。このコマンドは、メニュー画面に表示されたメニューの選択でもよく、アプリケーション起動画面であれば、アプリケーションを開始するための開始コマンドの場合もある。サーバ側では、このコマンドを受けて、サービス処理を開始する（ステップＳ５１４）。そして、時刻ｔ１０において、サーバから端末の要求に応じたサービスが提供される（ステップＳ５１５）。
【0075】
なお、図５には図示していないが、時刻ｔ１０以降も、端末からは随時コマンドを送信することができ（例えば、メッセージ送信コマンドやメニュー選択コマンドなど）、都度、サーバでは端末からのコマンド受信を受けてサービスを提供することができる（例えば、受信したメッセージを他端末に転送したり、メッセージ解析をしてその結果を返信したりするなど）。
【0076】
図６に、本発明の一実施形態にかかる本人確認支援システムにおける詳細な動作例を示す。図６において、「ユーザ端末（ユーザＡ）」及び「ユーザ端末（ユーザＢ）」は、一例として図１における端末１４ａ～１４ｃ、１５ａ～１５ｅ等に対応し、「ユーザ管理サーバ」は、一例として図１におけるサービスサーバ（群）１１のうちの少なくとも１サーバに対応し、「決済処理サーバ」は、一例として図１におけるサービスサーバ（群）１１のうちの少なくとも１サーバに対応する。
また、図６中、ｔ２１～ｔ２７は時系列の流れを示し、経時的に後述する動作や処理が行われるものである。
また、図６中、ｔ２１～ｔ２７は時系列の流れを示し、経時的に後述する動作や処理が行われるものである。
【0077】
特に、図６においては、ユーザＡが、インターネット等を介してユーザＢの決済の代理申請処理を行い、この申請処理を受け付けたユーザ管理サーバが、ユーザＢに確認をとって決済処理サーバと連携をとりながら決済処理を進めて行く様子を説明している。
【0078】
図６において、ステップＳ６０１及びステップＳ６０２では、ユーザＡは自身の端末からユーザＢのための代理手続の内容とユーザＢのニックネームを入力する。
代理手続きの内容は、上述したシーン１～シーン３のような手続きが挙げられるが、ここでは、説明の便宜上、決済手続きを伴うものとして説明を進める。
代理手続きの内容は、上述したシーン１～シーン３のような手続きが挙げられるが、ここでは、説明の便宜上、決済手続きを伴うものとして説明を進める。
【0079】
次に、時刻ｔ２１において、ユーザＡは、ユーザＢのための決済手続きの代理申請をユーザ管理サーバに対して行う（ステップＳ６０３）。
【0080】
この代理申請の様子は、図７に例示されるようなユーザＡの端末画面に表れている。図７において、ユーザＡの端末７００のディスプレイ上には、代理申請画面７１０が表示されており、同画面のメッセージ７１１の下に代理申請する内容を入力するための入力欄７１２が表示されている。本発明の一実施形態においては、ここには誰のための何の手続きの代理申請を行いたいかを入力する。入力手段は、図示しない公知の入力手段（メニューアイテム、セレクトボックス、テキストボックス等）が利用されることができる。
ここで、本発明の他の実施形態においては、図示しない他の画面において代理申請の内容が入力され、代理申請画面７１０では、その入力内容が表示されて確認するだけの場合もある。その場合は、７１２は、入力内容確認欄７１２となる。
図７において、７１３は、ニックネーム入力欄である。ここには、ユーザＡがユーザＢと共有しているユーザＢのニックネームを入力する。そして、申請ボタン７１４を押下して代理申請を行う。
ここで、本発明の他の実施形態においては、図示しない他の画面において代理申請の内容が入力され、代理申請画面７１０では、その入力内容が表示されて確認するだけの場合もある。その場合は、７１２は、入力内容確認欄７１２となる。
図７において、７１３は、ニックネーム入力欄である。ここには、ユーザＡがユーザＢと共有しているユーザＢのニックネームを入力する。そして、申請ボタン７１４を押下して代理申請を行う。
【0081】
図６に戻り、時刻ｔ２１～ｔ２２において、ユーザ管理サーバでは、ユーザＡから受信した代理申請からユーザＢのニックネームを抽出する（ステップＳ６０４）。時刻ｔ２２～ｔ２３において、ユーザ管理サーバは、抽出したユーザＢのニックネームからユーザＢのＩＤへの変換処理を行う（ステップＳ６０５）。本発明の一実施形態において、この変換処理は、上表で説明したようなユーザＢのプロフィールの情報テーブルを参照することによって実施される。
【0082】
時刻ｔ２３において、ユーザ管理サーバからユーザＢの端末に対し、ユーザＡからの代理申請があったこと、および、その承諾をするか否かの問い合わせが行われる（ステップＳ６０６）。
【0083】
この問い合わせの様子は、図８Ａに例示されるようなユーザＢの端末画面に表れている。図８Ａにおいて、ユーザＢの端末８００のディスプレイ上には、代理申請通知画面８１０が表示されており、同画面のメッセージ８１１の下に代理申請された内容を確認するための確認欄８１２が表示されている。
さらに、上記代理申請を許可するか否かのメッセージ８１３の下に、許可ボタン８１４及び拒否ボタン８１５が表示されており、ユーザＢがその代理申請を許可する場合にはボタン８１４を押下し、拒否する場合にはボタン８１５を押下する。
なお、本発明の他の実施形態において、代理申請内容があらかじめ取り決められている場合には、確認欄８１２の表示を割愛することもできる。
さらに、上記代理申請を許可するか否かのメッセージ８１３の下に、許可ボタン８１４及び拒否ボタン８１５が表示されており、ユーザＢがその代理申請を許可する場合にはボタン８１４を押下し、拒否する場合にはボタン８１５を押下する。
なお、本発明の他の実施形態において、代理申請内容があらかじめ取り決められている場合には、確認欄８１２の表示を割愛することもできる。
【0084】
図６に戻り、時刻ｔ２３～ｔ２４において、ユーザＢは、代理申請内容を確認して許可ボタンを押下し、この代理申請を承認する（ステップＳ６０７）。すると、時刻ｔ２４において、承認通知がユーザ管理サーバへ送信される（ステップＳ６０８）。
【0085】
時効ｔ２４～ｔ２５において、ユーザ管理サーバでは、決済サーバで決済を実行するための決済トークンを発行し（ステップＳ６０９）、発行した決済トークンを決済処理サーバへ送信する（ステップＳ６１０）。
【0086】
時刻ｔ２５～ｔ２６において、決済処理サーバでは、ユーザＡの代理申請によるユーザＢのための決済処理が実行される（ステップＳ６１１）。
【0087】
時刻ｔ２６において、決済処理サーバは、上記決済処理が完了したことをユーザ管理サーバへ通知する（ステップＳ６１２）。時刻ｔ２７において、ユーザ管理サーバは、ユーザＡによるユーザＢのための代理決済申請及びユーザＢの決済が完了したことを通知する（ステップＳ６１３、Ｓ６１４）。
【0088】
（本発明のバリエーション）
本発明は、図８Ｂに示されるような次の機能をさらに実現できる。
図８Ｂに、図８ＡのバリエーションとしてのユーザＢの情報処理端末の画面表示例を示す。図８Ｂにおいて、ユーザＢの端末８５０のディスプレイ上には、代理申請通知画面８６０が表示されており、同画面のメッセージ８６１の下に代理申請された内容を確認するための確認欄８６２が表示されている。さらに、上記代理申請を許可するか否かのメッセージ８６３の下に、許可ボタン８６４及び拒否ボタン８６５が表示されており、ユーザＢがその代理申請を許可する場合にはボタン８６４を押下し、拒否する場合にはボタン８６５を押下する。なお、本発明の他の実施形態において、代理申請内容があらかじめ取り決められている場合には、確認欄８６２の表示を割愛することもできる。
本発明は、図８Ｂに示されるような次の機能をさらに実現できる。
図８Ｂに、図８ＡのバリエーションとしてのユーザＢの情報処理端末の画面表示例を示す。図８Ｂにおいて、ユーザＢの端末８５０のディスプレイ上には、代理申請通知画面８６０が表示されており、同画面のメッセージ８６１の下に代理申請された内容を確認するための確認欄８６２が表示されている。さらに、上記代理申請を許可するか否かのメッセージ８６３の下に、許可ボタン８６４及び拒否ボタン８６５が表示されており、ユーザＢがその代理申請を許可する場合にはボタン８６４を押下し、拒否する場合にはボタン８６５を押下する。なお、本発明の他の実施形態において、代理申請内容があらかじめ取り決められている場合には、確認欄８６２の表示を割愛することもできる。
【0089】
ここで、特徴的な機能が表れている部分は、メッセージ８６１中の日時表示８６１１及び場所表示８６１２、そして、カウントダウン表示８６６である。
【0090】
（１）日時及び場所の表示
日時表示８６１１及び場所表示８６１２には、ユーザＡが代理申請を行った際の日時及び場所が表示される。例えば、図６のｔ２１のタイミングである。本発明の一実施形態において、ユーザＡが情報処理端末を介して代理申請を行うと、ユーザＡの情報処理端末は、ＧＰＳ受信機から受信したユーザＡの現在位置と、ＧＰＳ受信機あるいは情報処理端末の計時手段から抽出した日時情報とを取得し、代理申請メッセージデータにこれらの情報を含めて代理申請を行う。
このようにして、図８における日時表示８６１１及び場所表示８６１２の表示が可能となる。
日時表示８６１１及び場所表示８６１２には、ユーザＡが代理申請を行った際の日時及び場所が表示される。例えば、図６のｔ２１のタイミングである。本発明の一実施形態において、ユーザＡが情報処理端末を介して代理申請を行うと、ユーザＡの情報処理端末は、ＧＰＳ受信機から受信したユーザＡの現在位置と、ＧＰＳ受信機あるいは情報処理端末の計時手段から抽出した日時情報とを取得し、代理申請メッセージデータにこれらの情報を含めて代理申請を行う。
このようにして、図８における日時表示８６１１及び場所表示８６１２の表示が可能となる。
【0091】
一方、代理申請通知画面８６０を見たユーザＢは、ユーザＡからの代理申請が何時どこからなされたものかを把握できるため、ユーザＢ自身がユーザＡにご馳走することを約束した日時と場所等を想起することが容易となり、承諾をするか否かの判断がし易くなるという利点がある。
【0092】
（２）カウントダウン表示
カウントダウン表示８６６には、本発明の一実施形態において、ユーザＢの情報処理端末に代理申請通知画面８６０が表示されてからのカウントダウン表示が行われる。本発明はこれに制限されるものではないが、２分から開始したカウントダウンがなされる（図８Ｂには、１分５９秒が表示されており、カウントダウンが始まったばかりである）。もちろん、カウントダウンの制限時間は、６０秒でも、３０秒でも、５分でも任意の時間を設定できる。
カウントダウン表示８６６には、本発明の一実施形態において、ユーザＢの情報処理端末に代理申請通知画面８６０が表示されてからのカウントダウン表示が行われる。本発明はこれに制限されるものではないが、２分から開始したカウントダウンがなされる（図８Ｂには、１分５９秒が表示されており、カウントダウンが始まったばかりである）。もちろん、カウントダウンの制限時間は、６０秒でも、３０秒でも、５分でも任意の時間を設定できる。
【0093】
ユーザＢは、ユーザＡからの代理申請を承諾するか否かをカウントダウンの制限時間内に回答する必要がある。本発明の一実施形態において、ユーザＢが制限時間内にユーザＡからの代理申請の承諾／拒否を回答しなかった場合には、ユーザＡからの代理申請は不受理となる。この場合、ユーザＡは代理申請をやり直す必要がある。
このようにして、ユーザＡからの代理申請の取扱いを厳格にし、本発明の一実施形態にかかる本人確認支援システム等のセキュリティを強化できる。
このようにして、ユーザＡからの代理申請の取扱いを厳格にし、本発明の一実施形態にかかる本人確認支援システム等のセキュリティを強化できる。
【0094】
以上、具体例に基づき、本人確認支援システム等の実施形態を説明したが、本発明の実施形態としては、システム又は装置を実施するための方法又はプログラムの他、プログラムが記録された記憶媒体（一例として、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＣＤ－ＲＷ、磁気テープ、ハードディスク、メモリカード）等としての実施態様をとることも可能である。
【0095】
また、プログラムの実装形態としては、コンパイラによってコンパイルされるオブジェクトコード、インタプリタにより実行されるプログラムコード等のアプリケーションプログラムに限定されることはなく、オペレーティングシステムに組み込まれるプログラムモジュール等の形態であっても良い。
【0096】
さらに、プログラムは、必ずしも制御基板上のＣＰＵにおいてのみ、全ての処理が実施される必要はなく、必要に応じて基板に付加された拡張ボードや拡張ユニットに実装された別の処理ユニット（ＤＳＰ等）によってその一部又は全部が実施される構成とすることもできる。
【0097】
本明細書（特許請求の範囲、要約、及び図面を含む）に記載された構成要件の全て及び／又は開示された全ての方法又は処理の全てのステップについては、これらの特徴が相互に排他的である組合せを除き、任意の組合せで組み合わせることができる。
【0098】
また、本明細書（特許請求の範囲、要約、及び図面を含む）に記載された特徴の各々は、明示的に否定されない限り、同一の目的、同等の目的、または類似する目的のために働く代替の特徴に置換することができる。したがって、明示的に否定されない限り、開示された特徴の各々は、包括的な一連の同一又は均等となる特徴の一例にすぎない。
【0099】
さらに、本発明は、上述した実施形態のいずれの具体的構成にも制限されるものではない。本発明は、本明細書（特許請求の範囲、要約、及び図面を含む）に記載された全ての新規な特徴又はそれらの組合せ、あるいは記載された全ての新規な方法又は処理のステップ、又はそれらの組合せに拡張することができる。
【符号の説明】
【0100】
１０ 本人確認支援システム
１１（１１－１～１１－ｎ） サービスサーバ（群）
１４ａ～１４ｃ ＰＣ（拠点端末あるいは顧客端末の一形態）
１５ａ～１５ｅ タブレット端末（拠点端末あるいは顧客端末の一形態）
１７、１８（１８－１～１８－ｎ） 通信回線
１９ 公衆回線（インターネット、公衆通信網、専用回線等）
１１（１１－１～１１－ｎ） サービスサーバ（群）
１４ａ～１４ｃ ＰＣ（拠点端末あるいは顧客端末の一形態）
１５ａ～１５ｅ タブレット端末（拠点端末あるいは顧客端末の一形態）
１７、１８（１８－１～１８－ｎ） 通信回線
１９ 公衆回線（インターネット、公衆通信網、専用回線等）
【要約】
【課題】 ユーザ本人の意思に基づく手続きであることを確認するための改善された技術を提供する。
【解決手段】 第１情報処理端末と、第２情報処理端末と、第１情報処理端末及び第２情報処理端末から接続されるユーザ管理サーバとを少なくとも備えた本人確認支援システムであって、ユーザ管理サーバは、第１情報処理端末から送信された第１のユーザに関するプロフィール情報を登録するものであって、プロフィール情報には少なくとも第１のユーザのユーザＩＤ及びニックネームが含まれ、第２情報処理端末から送信された第１のユーザための処理の申請及びニックネームを受信し、第２情報処理端末から受信したニックネームから第１のユーザのユーザＩＤへ変換し、変換されたユーザＩＤを有する第１のユーザに対し、第２情報処理端末から送信された第１のユーザための処理の申請の承認可否の問い合わせを行う。
【選択図】 図４
【解決手段】 第１情報処理端末と、第２情報処理端末と、第１情報処理端末及び第２情報処理端末から接続されるユーザ管理サーバとを少なくとも備えた本人確認支援システムであって、ユーザ管理サーバは、第１情報処理端末から送信された第１のユーザに関するプロフィール情報を登録するものであって、プロフィール情報には少なくとも第１のユーザのユーザＩＤ及びニックネームが含まれ、第２情報処理端末から送信された第１のユーザための処理の申請及びニックネームを受信し、第２情報処理端末から受信したニックネームから第１のユーザのユーザＩＤへ変換し、変換されたユーザＩＤを有する第１のユーザに対し、第２情報処理端末から送信された第１のユーザための処理の申請の承認可否の問い合わせを行う。
【選択図】 図４
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8A】
【図8B】
【図9】
【図10】
【図11】
