JP2020109671A - 本人認証のための方法及び装置 - Google Patents

Abstract

【課題】決済認証工程についての本人認証の成功率を上げる本人認証のための方法及び装置を提供する。【解決手段】本人認証の方法において、端末装置は、専用タイプのサービスアプリケーションに対応するサーバから送信された本人認証要求メッセージを、プリセットされた標準インターフェースを介して受信するＳ１０１。本人認証要求メッセージを受診した端末装置は、本人認証要求メッセージ内の署名を専用タイプのサービスアプリケーションの公開鍵に従って検証する。検証に成功した場合、端末装置は、ローカルに事前に格納されているサービス認証情報から、本人認証要求メッセージに対応するアカウントのサービス認証情報を取得するＳ１０３。さらに、端末装置は、取得したサービス認証情報を検証応答メッセージ内に含め、この検証応答メッセージを、プリセットされた標準インターフェースを介してサーバへ返すＳ１０４。【選択図】図１

Description

本願は、２０１５年９月１４日に出願された「本人認証のための方法及び装置」と題された中国特許出願第２０１５１０５８３９６８．６号の優先権を主張し、上記中国特許出願は参照によってその全体が本明細書に組み込まれる。

本願はコンピュータ技術の分野に関し、特には、本人認証のための方法及び装置に関する。

ウェアラブル装置は、ユーザの身体へ直接装用される、又はユーザの衣類やアクセサリに一体化されるポータブル装置である。現在、主流の製品形態として、手首に装用する腕時計の範疇（腕時計及びリストストラップのような製品を含む）、足に装用する靴の範疇（靴、靴下、又、将来登場するだろう脚に装用する製品を含む）、頭部に装用する眼鏡の範疇（眼鏡、ヘルメット、ヘッドバンド等を含む）などがあり、主流ではない様々な製品形態として、スマート衣類、スクールバッグ、クラッチバッグ、アクセサリなどがある。
身体に装用する携帯ウェアラブル装置は、本人認証に対する関与を深め、多くのサービスにおいて対応処理工程を操作して、ユーザとの間に、より密接な相互作用を達成し、セキュリティを高めることが期待されている。

そのため、決済認証又は本人認証の操作を、ウェアラブル装置に基づく別の操作工程でどのように実施するかは、コンピュータ技術分野における中心的な研究課題の１つとなっている。
本人認証の特殊なタイプである決済認証とは、ユーザが現在実行している資金移動に関連する決済行動の正当性を判断する操作行動を意味する。資金に関して言えば、こうした本人認証は、特にセキュリティ及び便宜性の点で問題を抱えている。

従来技術における、ウェアラブル装置に基づく、本人認証を実施する従来の手順（特に決済認証操作工程）は、実質的に以下である。
ウェアラブル装置に紐付けされた（関連付けられた）モバイル端末が決済認証要求を受信すると、その決済認証要求の正当性の認証を担うのはモバイル端末である。認証に成功し、料金引き落としが完了した後、モバイル端末は、対応する料金引き落とし成功情報をウェアラブル装置へ送信する。そうでなければ、モバイル端末は、対応する料金引き落とし失敗情報をウェアラブル装置へ送信し、ウェアラブル装置は、この料金引き落とし結果を表示する。

出願人は、本願を実施する中で、従来のウェアラブル装置に基づく本人認証方法、特に決済認証方法、には少なくとも以下の課題のあることを見つけた。
従来技術では、決済認証要求の正当性の認証に関する演算はすべてモバイル端末上でなされ、ウェアラブル装置が担うのは料金引き落としの結果を表示するだけである。
更に、関連する演算をモバイル端末上で実施する場合、ユーザが感じる決済工程への参加感覚が弱いため、決済工程のセキュリティは低下し、決済の成功率に影響が出る。
そのため、当業者は、本人認証工程へのユーザの参加感覚を強め、認証工程のセキュリティを高め、認証成功率を上げる方法を早急に見つける必要がある。

本願の実施の形態は、本人認証工程へのユーザの参加感覚を強め、本人認証工程のセキュリティを高め、特に決済認証工程についての本人認証の成功率を上げる、本人認証のための方法及び装置を提供する。

上記技術的課題を達成するために、本願は、専用タイプのサービスアプリケーションと通信するように構成された、プリセット（予め設定）された標準インターフェースを備える端末装置に実装される本人認証方法を提供し、前記方法は、具体的に：
前記端末装置により、前記専用タイプの前記サービスアプリケーションに対応するサーバにより送信される本人認証要求メッセージを、前記プリセットされた標準インターフェースを介して受信するステップであって、前記本人認証要求メッセージは、前記サーバが前記専用タイプの前記サービスアプリケーションのサービス要求を受信した後に、前記サーバによって前記端末装置へ送信される、受信するステップと；
前記専用タイプの前記サービスアプリケーションの公開鍵に従って、前記端末装置により、前記本人認証要求メッセージ内の署名を検証するステップと；
前記検証に成功した場合に、ローカルに事前に格納されているサービス認証情報から、前記本人認証要求メッセージに対応するアカウントのサービス認証情報を、前記端末装置により取得するステップと；
前記端末装置により、前記取得したサービス認証情報を含む検証応答メッセージを、前記プリセットされた標準インターフェースを介して前記サーバへ返すステップと；を備える。

加えて、本願の実施の形態は、更に専用タイプのサービスアプリケーションに対応するサーバに実装される本人認証方法を提供し、前記サーバは、前記端末装置に含まれプリセットされた標準インターフェースを介して、端末装置と通信し、前記方法は、具体的に：
前記サーバにより、前記専用タイプの前記サービスアプリケーションのサービス要求を受信するステップと；
前記端末装置に含まれプリセットされた前記標準インターフェースを介して、前記サーバにより、前記端末装置へ本人認証要求メッセージを送信するステップと；
本人認証要求に成功した場合に、前記プリセットされた標準インターフェースを介して前記端末装置から返されサービス認証情報を含む検証応答メッセージを、前記サーバにより受信するステップと；
前記サービス認証メッセージに従って、前記サーバにより前記サービス要求を処理するステップと；を備える。

加えて、本願の実施の形態は、更に端末装置を提供し、前記装置は、具体的に：
専用タイプのサービスアプリケーションと通信するように構成されプリセットされた標準インターフェースと；
前記専用タイプのサービスアプリケーションに対応するサーバにより送信された本人認識要求メッセージを、前記プリセットされた標準インターフェースを介して受信するように構成された受信モジュールであって、前記本人認証要求メッセージは、前記サーバが前記専用タイプの前記サービスアプリケーションのサービス要求を受信した後に、前記サーバにより前記端末装置へ送信される、受信モジュールと：
前記受信モジュールにより受信された前記本人認証要求メッセージ内の署名を、前記専用タイプの前記サービスアプリケーションの公開鍵に従って検証するように構成された検証モジュールと；
前記検証モジュールによる前記検証に成功した場合に、前記端末装置へ事前に格納されているサービス認証情報から、前記本人認証要求メッセージに対応するアカウントのサービス認証情報を取得するように構成された取得モジュールと；
前記取得モジュールにより取得され前記サービス認証情報を含む検証応答メッセージを、前記プリセットされた標準インターフェースを介して前記サーバへ返すように構成されたフィードバックモジュールと；を備える。

加えて、本願の実施の形態は、更に専用タイプのサービスアプリケーションに対応するサーバを提供し、前記サーバは、具体的に：
前記専用タイプの前記サービスアプリケーションのサービス要求を受信すると、端末装置に含まれプリセットされた標準インターフェースを介して、前記端末装置へ本人認証要求メッセージを送信するように構成された送信モジュールと；
本人認証要求に成功した場合に、プリセットされた前記標準インターフェースを介して前記端末装置から返されサービス認証情報を含む検証応答メッセージを受信するように構成された受信モジュールと；
前記サービス要求を、前記受信モジュールにより受信された前記サービス認証メッセージに従って処理するように構成された処理モジュールと；を備える。

従来技術と比較して、本願の実施の形態で提案される技術的解決策は、以下の有益な技術的効果を含む。
本願の実施の形態では、サーバと端末装置とで構成されるシステムに実装される本人認証のための方法及び装置を開示する。ここで、端末装置には、専用タイプのサービスアプリケーションと通信するように構成されプリセットされた標準インターフェースが含まれる。本願で提案する技術的解決策により、本人認証操作が必要なときに、サーバは、プリセットされた標準インターフェースを介して、専用タイプのサービスアプリケーションのサービス認証情報を端末装置に要求することができ、又、端末装置は、対応する検証規則に従って、この工程でのセキュリティ検証を実行し、更に、検証に成功した場合に限り、後の処理のために、ローカルに事前に保存されているサービス認証情報をサーバへフィードバックできる。このように、本人認証工程のセキュリティを、専用タイプのサービスアプリケーションに紐付けされプリセットされた標準インターフェースと、端末装置のセキュリティ検証とによって確保することができ、端末装置操作者のこの工程への参加感覚を、端末装置に現在保存されている本人認証情報を用いることにより強めることができる。端末装置が具体的にウェアラブル装置である場合には、ユーザの本人認証工程への参加感覚が強まり、本人認証工程のセキュリティが高まり、特に決済認証工程の場合の本人認証の成功率が上がる。

本願の技術的解決策をより明確に説明するために、実施の形態を説明するための添付図面を以下に簡単に紹介する。明らかに、以下の説明における図面は、本願のいくつかの実施の形態を示すに過ぎず、当業者は創造的な努力なしにこれらの添付図面に基づいて他の図面を導き出すことができる。

本願の実施の形態による本人認証方法の概略フローチャートである。 本願の実施の形態による本人認証方法の紐付け（関連付け）工程の概略フローチャートである。 本願の実施の形態による本人認証方法における認証工程の概略フローチャートである。 本願の実施の形態による端末装置の概略構造図である。 本願の実施の形態によるサーバの概略構造図である。

本願の背景技術で述べたように、従来技術では、本人認証要求、特には決済認証要求、の正当性の認証に関連する演算は全てモバイル端末上で実施され、関連するウェアラブル装置が担うのは処理結果の表示だけである。そのため、ユーザは、このような操作工程、特には決済工程、においてユーザが感じる本人認証工程への参加感覚は希薄であり、この工程のセキュリティが低下することで、サービス成功率が影響を受けかねない。

しかし、本願の発明者はモバイル端末に比べ、ウェアラブル装置には処理中において以下の利点のあることを見つけた。
１．ウェアラブル装置は操作が簡便であり、ユーザの、対応処理工程への参加感覚を強める。
２．安全性は、ウェアラブル装置で操作する方が高い。例えば、操作のプライベート性が高く、簡単にピーピング（覗き見）ができず、対応の決済処理のセキュリティも高まる。
上の２つの利点に基づき、ウェアラブル装置での処理により、決済工程の成功率を上げることができるといえる。

上記の分析に基づき、先に述べた技術的課題を解決するために、本願の実施の形態は、ウェアラブル装置で実施される本人認証方法を開示する。当然ながら、本方法を、別のタイプの端末装置に実装することもできるが、そのような変更が本願の保護範囲に影響を及ぼすことはない。

図１は、本願の第１の実施の形態による本人認証方法の概略フローチャートである。同図に示すように、本方法は、専用タイプのサービスアプリケーションと通信するように構成されプリセットされる標準インターフェースを含む端末装置に実装され、具体的に以下を含む。

ステップＳ１０１ 端末装置が、専用タイプのサービスアプリケーションに対応するサーバから送信された本人認証要求メッセージを、プリセットされた標準インターフェースを介して受信する。
本人認証要求メッセージは、サーバが専用タイプのサービスアプリケーションのサービス要求を受信した後に、サーバから端末装置へ送信される。

特定のアプリケーションシナリオにおいて、ここで述べる専用タイプのサービスアプリケーションとは、主に、プリセットされた標準インターフェースに合致するタイプのサービスアプリケーションであり、特定のサービス実行中に本人認証操作を必要とするサービスアプリケーションを指す。プリセットされた標準インターフェース（インターフェースで定義されてもよく、標準的なプロトコルで定義されてもよい）にタイプが合致した後に、タイプが合致したサービスアプリケーションによりトリガされたメッセージのみが、プリセットされた標準インターフェースを介して送信される。このような限定により、異なるタイプのサービスアプリケーションの情報交換工程は効果的に排除され、他の情報が専用タイプのサービスアプリケーションの情報交換工程に干渉することを防ぎ、対応する情報処理効率が上がる。加えて、専用タイプに限定することで、プリセットされた標準インターフェースを介して起こる他の偽造されたパケットや信号通信の来入又はこれらによる攻撃も、効果的に遮断できるため、本人認証工程のセキュリティが高まる。

後続の処理では、端末装置と専用タイプのサービスアプリケーションとの間における情報交換はプリセットされた標準インターフェースを介して実施されるが、これについては対応する後続のステップにおいてそれに応じて述べているため、ここでは詳細な説明を省くことに留意されたい。

プリセットされた標準インターフェースに限定することにより、異なるサービスアプリケーションにより送信されたメッセージは、プリセットされた標準インターフェースを介して端末装置で受信されることはないので、当然、この実施の形態で提案される技術的解決策がトリガされることはない。よって、本人認証工程で情報フィルタリングをすることができ、別のメッセージからの干渉を防ぐことができ、本人認証工程のセキュリティを高めることができる。

ステップＳ１０２ 端末装置は、専用タイプのサービスアプリケーションの公開鍵に従って、本人認証要求メッセージ内の署名を検証する。
検証に成功した場合は、本人認証要求メッセージが、専用タイプのサービスアプリケーションにより送信され、安全で正当なメッセージであるとみなされ、次のステップＳ１０３を実行できる。
検証に失敗した場合は、本人認証要求メッセージが、専用タイプのサービスアプリケーションにより送信された正当なメッセージではないとみなされ、本人認証要求メッセージは即座に破棄される。

ステップＳ１０３ 端末装置が、ローカルに事前に格納されているサービス認証情報から、本人認証要求メッセージに対応するアカウントのサービス認証情報を取得する。
具体的には、この実施の形態では、このステップを実行する前に、端末装置がサービス認証情報を予めローカルに保存する操作工程は、具体的に以下である。
まず、端末装置が、専用タイプのサービスアプリケーションにより送信されたアカウントについての紐付け登録要求メッセージを、プリセットされた標準インターフェースを介して受信する。
次に、端末装置がこの紐付け登録要求メッセージの正当性を検証する。すなわち、紐付け登録要求メッセージ内の署名を、専用タイプのサービスアプリケーションの公開鍵に従って検証する。
検証に成功した場合は、端末装置が紐付け登録要求メッセージ内に含まれるサービス認証情報を取得し、このサービス認証情報とアカウントの本人識別情報とを以降の認証操作のために対応付けてローカルに保存する。ここで、本人識別情報は、サービス認証情報が属するアカウントを示すために用いられる。
検証に失敗した場合は、紐付け登録要求メッセージが、専用タイプのサービスアプリケーションにより送信された正当なメッセージではなく、無効であるとみなされるため、紐付け登録要求メッセージは即座に破棄される。
最後に、サービス認証情報と本人識別情報との保存を完了したら、端末装置が、端末装置の識別子情報に従って登録応答メッセージを生成し、この登録応答メッセージを、プリセットされた標準インターフェースを介して、専用タイプのサービスアプリケーションへ返す。

特定のアプリケーションシナリオにおいて、前記登録応答メッセージを生成する工程は、具体的に以下である。
一意の識別子情報と、前記端末装置の装置モデル情報とを前記端末装置により取得する；
前記専用タイプの前記サービスアプリケーションが指定したデータ形式に従って、前記一意の識別子情報と前記装置モデル情報とを、前記端末装置によりアセンブルする；
前記端末装置により、ローカルの秘密鍵を用いて、前記アセンブルされた情報に署名し、前記登録応答メッセージを生成する。

当然ながら、アカウントユーザがサービス認証情報（例えば、決済パスワード、決済を行うジェスチャ等）を変更できる点を考慮すると、現在保存されている情報を、後に、以下の手順で更に更新することができる。
ステップＡ 端末装置が、専用タイプのサービスアプリケーションにより送信された、アカウントに関するサービス認証情報更新要求メッセージを、プリセットされた標準インターフェースを介して受信する。
ステップＢ 端末装置が、専用タイプのサービスアプリケーションの公開鍵に従って、サービス認証情報更新要求メッセージ内の署名を検証する。
検証に失敗した場合に、サービス認証情報更新要求メッセージは、専用タイプのサービスアプリケーションにより送信された正当なメッセージではなく、無効であるとみなされ、それによって、サービス認証情報更新要求メッセージは即座に破棄される。
検証に成功した場合は、ステップＣを実行する。
ステップＣ 端末装置は、ローカルに保存されているサービス認証情報に対応する本人識別情報が、サービス認証情報更新要求メッセージに含まれている本人識別情報と一致するかどうかを判断する。
一致する場合に、同一アカウントのサービス認証情報が端末装置に保存されていると判定され、サービス認証情報更新要求メッセージと合致するゆえ、続いての操作であるステップＤがトリガされる。
反対に、一致しない場合に、同一アカウントのサービス認証情報が端末装置に保存されていないと判定され、サービス認証情報更新要求メッセージと合致しないゆえ、更新対象は無く、以降の処理は実際の必要性に従って判定されることになる。
ステップＤ 端末装置が、サービス認証情報更新要求メッセージ内に含まれているサービス認証情報を取得する。
ステップＥ 取得したサービス認証情報のバージョン情報は、ローカルに保存されている最新の対応サービス認証情報のバージョン情報よりも新しいかどうかを、端末装置が判断する。
このステップにより、端末装置に現在格納されているサービス認証情報の更新が必要であるかどうか判定することができる。
判断結果が肯定である場合は、ローカルのサービス認証情報が最新バージョンのものではなく、更新が必要であることを示し、端末装置は、現在保存されている対応サービス認証情報を、取得したサービス認証情報と置き換える。
判断結果が否定である場合、すなわち、取得したサービス認証情報のバージョン情報が、現在、ローカルに保存されている対応するサービス認証情報のバージョン情報と同じ又はこれよりも旧い場合は、ローカルのサービス認証情報を更新する必要がない旨を示すため、現在の更新操作を終了する。

ステップＳ１０４ 端末装置は、取得したサービス認証情報を検証応答メッセージ内に含め、この検証応答メッセージを、プリセットされた標準インターフェースを介してサーバへ返す。

特定のアプリケーションシナリオでは、セキュリティ上の理由から、このステップにおいて決済信用情報が返されるときに、サービス認証情報を暗号化し、応答データパケットとして保存することができる。サーバは、応答データパケットを受信すると、後続のサービス処理操作を完了するために、応答データパケットを復号化してサービス認証情報を入手する。

特定のアプリケーションシナリオでは、このステップが完了した後、対応する確認（アクノリッジメント）工程を更に含んでもよい。この確認工程は具体的に以下である。
専用タイプのサービスアプリケーションに対応するサーバにより送信された確認要求を、端末装置により、プリセットされた標準インターフェースを介して受信する；
端末装置により、確認要求に含まれている確認方式タイプ情報を取得する；
端末装置により、確認方式タイプ情報に従って、対応の確認操作を完了する。
具体的に、この実施の形態では、確認要求に含まれている確認方式タイプ情報は、次の確認方式のうち任意の１つ又は任意の組み合わせを含んでよい：
テキストによる確認、音声による確認、及び振動による確認。

これに対応して、例えば、テキストによる確認では、端末装置に文字列「あなたの決済は成功しました」、「サービス処理は成功しました」等を直接に表示できる。当然ながら、これには、端末装置が表示画面を有することが前提条件となる。音声による確認では、事前設定された「着信音」を発することができる。振動による確認では、事前設定された回数又は連続時間だけ振動を発することができる。

この確認操作の主たる目的は、ユーザがサービス処理結果を正確に知ることができるようにすることである。当然ながら、サービス処理に成功した場合は更なる操作が不要となる、と設定してもよい。こうした設定は実際の必要性に応じて調整でき、本願の保護範囲に影響を及ぼすことはない。

先の記載は、端末装置側での解決策の実施工程の説明である。これに対応し、本願の実施の形態はサーバ側での解決策の実施手順を更に提案する。この方法は、専用タイプのサービスプリケーションに対応するサーバに実装される。ここで、サーバは、端末装置に含まれプリセットされた標準インターフェースを介して、端末装置と通信する。この方法は具体的に以下のステップを含む。
まず、サーバが、専用タイプのサービスアプリケーションのサービス要求を受信する。
次に、サーバが、端末装置に含まれプリセットされた標準インターフェースを介して、本人認証要求メッセージを、端末装置へ送信する。
本人認証要求に成功した場合は、サーバが、プリセットされた標準インターフェースを介して端末装置により返された、サービス認証情報を含む検証応答メッセージを受信する。
サーバは、サービス認証メッセージに従ってサービス要求を処理する。

特定のアプリケーションシナリオでは、サーバが専用タイプのサービスアプリケーションのサービス要求を受信する前に、サービス認証情報を事前に保存する工程、すなわち以下が更に含まれる。
端末装置に内蔵されプリセットされた標準インターフェースを介して、サーバにより、アカウントについての紐付け登録要求メッセージを端末装置へ送信する、ここで、紐付け登録要求メッセージはアカウントのサービス認証情報を含む；
登録の紐付けに成功した場合は、プリセットされた標準インターフェースを介して端末装置から返された登録応答メッセージをサーバにより受信し、更に、端末装置とアカウントとの紐付けが成功したことをサーバにより確認する、ここで、登録応答メッセージは端末装置の識別子情報を含む。
この事前保存工程は、ステップＳ１０３で端末装置がサービス認証情報をローカルに事前保存する操作工程に対応しているため、ここではその詳細を再び説明しない。

更に、本方法は、端末装置がアカウントに成功裏に紐付けされたことをサーバにより確認した後に、更に以下を含む。
アカウントのサービス認証情報を更新する必要がある場合に、サーバが、アカウントのためのサービス認証情報更新要求メッセージを、端末装置に含まれプリセットされた標準インターフェースを介して、サーバにより端末装置へ送信する、ここで、サービス認証情報更新要求メッセージは、アカウントの、更新が必要なサービス認証情報を含む。
この工程も、ステップ１０３におけるステップＡ乃至ステップＥの処理工程に対応するため、ここではその詳細を再び説明しない。

別の態様によれば、サーバがサービス認証メッセージに従ってサービス要求を処理した後に、対応する確認工程を更に含むことができる。この確認工程は具体的に以下である。
サービス要求処理が完了した後に、端末装置に含まれプリセットされた標準インターフェースを介して、確認方式タイプ情報を含む確認要求を、サーバにより端末装置へ送信し、これにより、端末装置が、確認方式タイプ情報に従って、対応の確認操作を完了することができる。
確認要求後の工程は、後続のステップＳ１０４での確認工程に対応するので、ここではその詳細を再び説明しない。

先行する各ステップにおいて、プリセットされた標準インターフェースを介して端末装置により受信される各メッセージは、少なくとも操作タイプ情報とそのメッセージの署名情報とを含む点に留意すべきである。
署名情報は、プリセットされた標準インターフェースに対応する専用タイプのサービスアプリケーションに合致する必要があるため、専用タイプのサービスアプリケーションの公開鍵に従って検証できる。検証に失敗した場合は、当然、現在のメッセージは専用タイプに合致しないと判定される。よって、関連性のないメッセージを除外できるので、セキュリティは高まる。

本願の実施の形態で提案する技術的解決策の有利な技術的効果を、従来技術と比較して以下に述べる。
本願のこの実施の形態は、サーバと端末装置とにより構成されるシステムに実装される、本人認証のための方法及び装置を開示する。端末装置は、専用タイプのサービスアプリケーションと通信するように構成されプリセットされる標準インターフェースを含む。本願で提案する技術的解決策により、本人認証操作が必要な場合は、サーバは、専用タイプのサービスアプリケーションのアカウントのサービス認証情報を、プリセットされた標準インターフェースを介して端末装置に要求でき、端末装置は、対応する検証規則に従って、この工程にセキュリティ検証を実行し、検証に成功した場合に限って、後続の処理のために、ローカルに事前に保存されているサービス認証情報をサーバへフィードバックできる。よって、本人認証工程のセキュリティを、専用タイプのサービスアプリケーションに紐付けされプリセットされた標準インターフェースと、端末装置のセキュリティ検証とによって確保することができ、端末装置に現在保存されている本人認証情報を用いることで、端末装置の操作者の工程への参加感覚を強めることができる。端末装置が具体的にウェアラブル装置である場合は、ユーザの、本人認証工程への参加感覚が強まり、本人認証工程のセキュリティは高まり、特に決済認証工程については本人認証の成功率が上がる。

本願におけるこの技術的解決策について、本願の添付の図面を参照にして明確且つ十分に以下説明する。記載の実施の形態は、本願の全ての実施の形態のうちのいくつかにすぎないことは明らかである。本願の実施の形態に基づいて当業者が創作的な努力なしに得られる他の実施の形態は全て本願の保護範囲に含まれる。

後に続く本願の実施の形態では、ウェアラブル装置はユーザと一緒に運ばれ、セキュリティが確保され、決済タイプのサービスにおける高いセキュリティ要件を有する点を考慮しながら、ウェアラブル装置が決済認証工程を実施する実施例を使って技術的解決策について説明する。これに応じ、先に述べた端末装置は、以降ではウェアラブル装置であり、先に述べた専用タイプのサービスアプリケーションは、以降では決済タイプのサービスアプリケーションであり、対応の専用タイプは決済である。

これは単に好ましい実施の形態であり、本願における技術的解決策は、別のタイプの端末装置及び別のタイプのサービスの本人認証工程でも実施できるが、そのような変更が本願の保護範囲に影響を及ぼすことはない。

まず、本願のこの実施の形態で提案される技術的解決策のアプリケーションシナリオは以下である。
（１）ウェアラブル装置：装用可能で、決済機能を有する装置であり、例えばスマートウォッチ、スマットバッジ、スマートグラスが挙げられる。ウェアラブル装置は、それ自体が決済機能を搭載しているものと、決済機能を持つアプリケーションをインストールして、関連するアカウントについて対応する決済操作を実行できるようにするものとがある。ウェアラブル装置は、プリセットされた標準インターフェースを介して、決済タイプアプリケーションのサーバとの間、及び、決済タイプアプリケーションがインストールされた決済対応端末との間で通信する。ここで、プリセットされた標準インターフェースは、決済プロトコルに準拠する標準インターフェースであってよい。

（２）決済対応端末：例えば、スマートフォン、スマートタブレットコンピュータ（パッド）であって、それ自体が決済機能を搭載しているもの、又は、決済機能を持つアプリケーションがインストールされたものがある。この端末はウェアラブル装置と同一のユーザアカウントに関連付けられる。ユーザによって要求又は設定された場合、端末はウェアラブル装置を用いて決済操作を承認する必要がある。更に、装置は、プリセットされた標準インターフェースを介して、ウェアラブル装置及び決済サーバとも通信する。プリセットされた標準インターフェースは、決済プロトコルに準拠する標準インターフェースであってよい。

（３）決済サーバ：決済処理機能と検証機能を搭載するサーバであり、検証に成功した後、最終的に決済操作を実行する。
上述のサービスアーキテクチャに基づけば、プリセットされた標準インターフェースを、対応するプロトコルに従って構成することができる。本願の実施の形態で提案される特定の実施例の場合、インターフェースは例えばコンテンツプロトコル（content protocol）を用いて構成することができる。
ＡＴＴ形式の構成プロトコル標準を採用し、ＵＵＩＤを用いて一意の専用タイプの属性を識別する。

特定の本人認証工程では、プリセットされた標準インターフェースのプロトコルを、具体的に１つのサービスと４つの特性を含むものとして構成してよい。
サービスＵＵＩＤ：０ｘ０００１０００（対応するサービスアプリケーションの専用タイプを判定するためのもの）
特性：４つの特性、即ち、登録、検証、鍵更新、承認（バイブレーション）がある。対応する特性ＵＵＩＤ：０ｘ００００００１１、０ｘ００００００１２、０ｘ００００００１３、０ｘ００００００１４であり、これにより特定のインターフェース間で機能の違いを識別できる。

当然ながら、このような設定は単なる特定の実施例にすぎない。実際の適用においては、上記の機能の違いを区別できない場合があり、その代わりに、メッセージの識別子のタイプに従って異なる処理がトリガされる。当然ながら、サービスコンテンツの違いに従って更に多くの特性を設定してもよい。こうした変更は本願の保護範囲に影響を及ぼすことはない。

上述のシステムシナリオに基づき、そしてウェアラブル装置の演算能力及び保存能力は限られていて、しかも電力を消費しなければならない点を考慮すると、ウェアラブル装置が担う処理操作は極力少なくなる。

本願で提案される技術的解決策では、決済操作がスムーズに完了するように、ウェアラブル装置は鍵検証情報（すなわちサービス認証情報）を保存し、識別が正当であると検証された場合に限って、検証情報を決済サーバへフィードバックする。

様々な段階における操作手順を、順に以下説明する。
１．紐付け段階
この段階では、ウェアラブル装置と特定のアカウントとの間の紐付け関係の確立が要求され、紐付けされたアカウントの決済信用情報（すなわち、サービス認証情報の特殊ケース。類似の設定についての記述が後に続くので、ここでは１つ１つ列挙しない）がウェアラブル装置へ同期して保存される。

図２は、本願の実施の形態による本人認証方法における紐付け工程の概略フローチャートである。具体的に同図で示すように、この実施の形態では、ウェアラブル装置は、対応する専用タイプのサービスアプリケーションのアカウントへの紐付けを完成するために、事前設定された登録方針に従ってサービス認証情報をローカルに保存する。具体的な手順は以下である。

ステップＳ２０１ ウェアラブル装置が、プリセットされた標準インターフェースを介して登録要求を受信する。
特定のアプリケーションシナリオでは、ネットワーク側に基づくアカウント同一性検証が必要な場合には、決済サーバを用いて前出の登録工程をトリガすることができ、ローカルな識別情報（例えば、ローカルな鍵ネゴシエーション）のマッチングを実行する場合には、決済対応端末上の決済タイプのサービスアプリケーションは、ウェアラブル装置への登録工程を直接開始するようにしてもよい。しかし、どの開始方式を実装するかには関わらず、処理されるサービスのタイプは決済タイプのサービスであるため、全ての操作はプリセットされた標準インターフェースを介して完了させる必要がある。よって、異なるタイプのサービスメッセージからのインターフェースを遮断でき、現タイプのサービス操作のセキュリティを高めることができる。

この紐付け工程の最終的な目的が検証情報（すなわち、サービス認証情報）を同期して保存することであることを考えると、決済対応端末上の決済タイプのサービスアプリケーションがウェアラブル装置への登録工程を直接開始させる場合には、決済対応端末上の決済タイプのサービスアプリケーションが、対応する検証情報を直接的に提供する必要がある。

どの処理解決策を実装するかということに関係なく、紐付けが同一の決済アカウントに基づく紐付けであることを考慮すると、特定のトリガ形式間の違いは後続の工程で除外され、決済アカウントの決済タイプのサービスアプリケーションをトリガエンティティとして直接的に用いて対応の紐付け操作を実行する。

ステップＳ２０２ ウェアラブル装置が、事前設定されたデータ形式標準に従って登録要求をパースし（parse、解析する）、登録要求内に含まれている情報を取得する。
決済タイプのサービスアプリケーションが、ウェアラブル装置のプリセットされた標準インターフェースへの登録要求を開始する（例えば、決済対応端末上の決済タイプのアプリケーションにより直接開始された紐付け工程の場合には、Ｂｌｕｅｔｏｏｔｈ（登録商標）により登録要求を直接送信でき、決済サーバを用いて開始された紐付け工程の場合は、決済サーバを用いて、登録要求を、ウェアラブル装置のプリセットされた標準インターフェースへ送信できる）。ウェアラブル装置はデータを受信すると、事前設定されたデータ送信形式に従ってデシリアライズ（deserialization、デシリアライズ操作はパース操作である）処理を実行して登録要求に含まれている検証情報を入手する。

登録要求と、プリセットされた標準インターフェースへその後で送信される別のメッセージとを用いて対応の正当性検証操作を完了し、検証タイプの情報及び特定の署名情報（これらの情報は必然的に含まれる鍵検証情報である）を含む必要があることに更に留意されたい。ここでは具体的に説明するが、その他のメッセージもこれと類似するため、それらについての説明を１つ１つ繰り返さない。

Ａ．検証タイプ情報：
現時点で利用できる検証解決策は２つである。一方は比較的安全な検証解決策であって、暗号化と署名検証のためにＲＳＡとを採用する解決策であり、他方は、プログラミング性能が高くなく、セキュリティも比較的低く、対称暗号化を採用する検証解決策である。

Ｂ．署名情報：特定の署名アルゴリズムに従って生成される署名情報である。これ以降の他のメッセージもこれに類似する。そのため、署名情報は、これに個別に含める必要がある情報を用いて、特定の署名アルゴリズムに従って生成されることができる。
特定のアプリケーションシナリオでは、主たる署名アルゴリズムタイプとして、ｓｈａ２５６及びｒｓａｗｉｔｈｓｈａ２５６がある。

特定のアプリケーションシナリオでは、上述の鍵検証情報に加え、登録要求はコンテンツの以下に示すいくつかの部分を含んでよい。当然ながら、登録の紐付け操作を実施できるという前提であれば、登録要求に含まれる情報のタイプが本願の保護範囲に影響を及ぼすことはない。
（１）パケット関連情報：登録要求の識別に用いられる情報であり、署名されたデータの長さと署名されたデータとを含む。
（２）本人関連情報：登録要求の正当性を検証するために用いられる。決済サービスの署名情報（すなわち、本人識別情報）と、決済サービスの署名情報の長さ情報と、チャレンジ情報と、チャレンジ情報の長さ情報とを含む。
（３）アルゴリズム関連情報：署名をパース又は生成するために用いられる。署名アルゴリズムタイプ情報と署名アルゴリズムの長さ情報とを含む。
加えて、この実施の形態では、署名アルゴリズムはセキュアハッシュアルゴリズムＳＨＡ２５６、又は、非対称ハッシュアルゴリズムＲＳＡｗｉｔｈＳＨＡ２５６であってよいことに留意すべきである。特定の環境では、署名アルゴリズムは別の署名アルゴリズムであってもよいが、ここではその詳細な説明をしない。
（４）決済信用関連情報：後続の工程において決済操作を検証するために用いられる。決済対応端末によって生成され、決済サーバをサポートして料金引き落とし操作を完了するために用いられる共有鍵（すなわち、決済信用情報）と、共有鍵の長さ情報とを含む。

ステップＳ２０３ ウェアラブル装置が登録要求の正当性を検証する。
特定のアプリケーションシナリオでは、情報デシリアライズ操作に成功した後に、ウェアラブル装置が、事前設定された検証情報に従って検証操作を実行する。具体的には、ウェアラブル装置は、決済サービス用のビルトイン公開鍵に従って、ステップＳ２０２でデシリアライズ操作が実行された後に入手された署名関連情報に検証操作を実行できる。
検証に成功した場合は、ステップＳ２０４を実行する。検証に失敗した場合は、ウェアラブル装置が、登録要求は無効又は不当であると判定し、登録要求を即座に破棄する。

ステップＳ２０４ ウェアラブル装置が決済信用情報と本人識別情報とを取得して、これを保存する。
ウェアラブル装置は、ビルトイン秘密鍵に従って、ステップ２０２でデシリアライズ操作が実行された後に入手された決済信用関連情報に復号化操作を実行して決済信用情報を取得する。
ウェアラブル装置は、ステップ２０２でデシリアライズ操作が実行された後に入手した装置識別子関連情報を取得する。
ウェアラブル装置は、取得した決済信用情報と本人識別情報とをローカルに保存する。例えばこの情報を、ローカルな読み取り専用メモリ（ＲＯＭ）に保存する。
これまでに、ウェアラブル装置側での紐付け関係の保存が完了しており、後続の操作では、ピアの決済対応端末上の決済タイプのサービスアプリケーションへ、紐付け状態をフィードバックする必要がある。紐付け操作は、両側での紐付け関係の処理に成功した後に限り、真に完了する。

ステップＳ２０５ ウェアラブル装置が、事前設定されたフィードバック規則に従って、本人識別情報と他の紐付け関連情報とをフィードバックする。
ウェアラブル装置が、一意のＩＤ（本人識別情報）、装置モデル、及び他の情報を用い、事前設定されたフィードバック情報アセンブリ規則に従って、対応する登録応答メッセージを生成し、このメッセージを登録要求の送信者へ送信する。すなわち、決済対応端末が登録要求を直接開始すると、登録応答メッセージは決済対応端末へ直接フィードバックされ、ネットワーク側の決済サーバを用いて登録要求が開始されると、登録応答メッセージが決済サーバへフィードバックされ、次に、決済サーバが後続の紐付け承認フィードバックを実行する。

上述の暗号化／復号化法はセキュリティのための保証作業であり、セキュリティが確保されるという前提であれば、暗号化／復号化法のどちらを用いても、別のセキュリティ保護処置を講じても、本願の保護範囲に影響しないことに留意されたい。

特定のアプリケーションシナリオでは、鍵検証情報に加えて、登録応答メッセージはコンテンツの以下のいくつかの部分を含んでよい。当然ながら、登録紐付け操作を実行できるという前提であれば、登録応答メッセージに含まれる情報のタイプによって本願の保護範囲が影響を受けることはない。
（１）パケット関連情報：登録要求の識別に用いられる情報。署名されたデータの長さと署名されたデータとを含む。
（２）本人関連情報：登録要求の正当性を検証するために用いられる。決済サービスの署名情報（すなわち、本人識別情報）と、決済サービスの署名情報の長さ情報と、チャレンジ情報と、チャレンジ情報の長さ情報とを含む。
（３）アルゴリズム関連情報：署名をパース又は生成するために用いられる。署名アルゴリズムタイプ情報と署名アルゴリズムの長さ情報とを含む。
加えて、この実施の形態では、署名アルゴリズムはＳＨＡ２５６又はＲＳＡｗｉｔｈＳＨＡ２５６であってよいことに留意されたい。特定の環境では、署名アルゴリズムは別の署名アルゴリズムであってもよく、ここではその詳細な説明をしない。
（４）ウェアラブル装置関連情報：登録イニシエータが登録に成功したウェアラブル装置を取得できるようにするために用いられる情報である。ウェアラブル装置の一意のＩＤ情報と、一意のＩＤ情報の長さ情報と、装置モデル情報と、装置モデル情報の長さ情報とを含む。
前出の処理により、ウェアラブル装置は、ウェアラブル装置に紐付けされた決済タイプのサービスアプリケーションのアカウントの決済認証情報及び本人識別情報の格納に成功する。しかし、ユーザが決済信用情報（例えば、決済パスワード、決済ジェスチャ等）を変更できる点を考慮すると、現在格納されている情報を、後で以下の手順を用いて更に更新できる。特定の更新操作については上述の登録工程を参照できるが、ここで、決済認証情報の更新が決定される前に、本人識別情報比較工程（同一ユーザの更新操作であることを判定するため）と、決済認証情報バージョン比較工程（決済認証情報の高位バージョンのみを保存する）とを追加で実行する必要がある点のみが異なる。ここでは詳細な説明を繰り返さない。

２．認証段階
この段階では、ウェアラブル装置が、本願で提案される技術的解決策の核心的な処理を実行する。すなわち、ウェアラブル装置が決済要求工程に認証操作を実行する。決済要求工程は、この認証操作の実行に成功した場合に限って継続できる。
図３は、本願の実施の形態による本人認証方法における認証工程の概略フローチャートである。具体的に、この実施の形態では、同図に示すように、ウェアラブル装置が、事前設定された認証方針に従って、決済対応端末から送信された決済認証要求に正当性認証操作を実行する。具体的な手順は以下である。

ステップＳ３０１ ウェアラブル装置が、プリセットされた標準インターフェースを介して、決済サーバにより送信された決済認証要求を受信する。
特定のアプリケーションシナリオでは、決済操作は概して決済対応端末によって開始される。ここで、決済対応端末は、決済サーバへ決済要求を送信して決済操作を要求する。決済サーバは、決済要求を受信すると決済認証工程をトリガし、ウェアラブル装置へ決済認証要求を送信する。
決済認証要求は、ウェアラブル装置のプリセットされた標準インターフェースを介して受信されてよい。

ステップＳ３０２ ウェアラブル装置は、事前設定されたデータ形式標準に従って決済認証要求をパースし、決済認証要求に含まれている情報を取得する。
決済タイプのサービスアプリケーションがユーザによって開始された決済工程を受信すると、決済タイプのサービスアプリケーションが、ウェアラブル装置のプリセットされた標準インターフェースへの決済認証要求を開始する。このデータを受信したウェアラブル装置は、事前設定されたデータ送信形式に従って、デシリアライズ（デシリアライズ操作はパース操作である）処理を実行し、これにより、決済認証要求に含まれている検証情報を入手する。

特定のアプリケーションシナリオでは、鍵検証情報に加えて、決済認証要求はコンテンツの以下のいくつかの部分を含むことができる。又、当然ながら、決済認証操作を実施できるという前提であれば、決済認証要求に含まれている情報のタイプは本願の保護範囲に影響しない。
（１）パケット関連情報：決済認証要求を識別するために用いられる情報であって、署名されたデータの長さと、署名されたデータとを含む。
（２）本人関連情報：決済認証要求とウェアラブル装置に紐付けされたアカウントとの間の合致を検証するために用いられる情報であって、決済サービスの署名情報（すなわち、本人識別情報）と、決済サービスの署名情報の長さ情報と、チャレンジ情報と、チャレンジ情報の長さ情報とを含む。
（３）アルゴリズム関連情報：署名をパースするために又は生成するために用いられる情報であって、署名アルゴリズムタイプ情報と、署名アルゴリズムの長さ情報とを含む。
加えて、この実施の形態では、署名アルゴリズムは、ＳＨＡ２５６又はＲＳＡｗｉｔｈＳＨＡ２５６であってよいことに留意されたい。特定の環境では、署名アルゴリズムは別の署名アルゴリズムであってもよく、ここではその詳細の説明を省く。

ステップＳ３０３ ウェアラブル装置が、決済認証要求に対応するアカウントとローカルに格納されている決済信用情報に対応するアカウントとの間の紐付け関係を検証する。
特定のアプリケーションシナリオでは、ウェアラブル装置は、デシリアライズ化によって入手した情報をローカルな情報と比較し、決済認証要求に対応する決済タイプのサービスアプリケーションのアカウントが、ウェアラブル装置に紐付けされた決済タイプのサービスアプリケーションのアカウントであるかどうかを判断する必要がある。
特定のアプリケーションシナリオでは、メッセージに含まれている本人識別情報が、ローカルに格納されている決済信用情報に対応する本人識別情報に合致するかどうかを検証することができる。
検証に成功した場合は、ステップＳ３０４を実行する。検証に失敗した場合は、決済認証要求が、ウェアラブル装置に関連していない別のアカウントに対応するとみなすことができるので、決済認証要求は即座に破棄される。

ステップＳ３０４ ウェアラブル装置が、格納されている決済対応端末の決済信用情報に従って識別鍵を生成する。
前出の紐付け工程において、識別鍵が、ＲＯＭに格納されている決済信用情報を用いて生成される。
特定のアプリケーションシナリオでは、決済タイプのサービスアプリケーションの公開鍵を用いて識別鍵を暗号化し、データを認証出力パラメータに従ってシリアライズして、フィードバック可能なフィードバックデータ（すなわち、応答データパケット）を生成する。

特定のアプリケーションシナリオでは、鍵検証情報に加えて、フィードバックデータは以下のコンテンツのいくつかの部分を含むことができる。当然ながら、識別鍵をフィードバックする操作を実施できるという前提であれば、フィードバックデータに含まれる情報のタイプによって本願の保護範囲が影響されることはない。
（１）パケット関連情報：フィードバックデータを識別するために用いられる情報であって、署名されたデータの長さと、署名されたデータとを含む。
（２）本人関連情報：フィードバックデータの正当性を検証するために用いられる情報であって、決済サービスの署名情報（すなわち、本人識別情報）と、決済サービスの署名情報の長さ情報と、チャレンジ情報と、チャレンジ情報の長さ情報とを含む。
（３）アルゴリズム関連情報：署名をパースするために又は生成するために用いられる情報であって、署名アルゴリズムタイプ情報と、署名アルゴリズムの長さ情報とを含む。
加えて、この実施の形態では、署名アルゴリズムはＳＨＡ２５６又はＲＳＡｗｉｔｈＳＨＡ２５６であってよいことに留意されたい。特定の環境では、署名アルゴリズムは別の署名アルゴリズムであってもよく、ここではその詳細の説明をしない。
（４）決済信用関連情報：検証イニシエータが決済信用情報を取得できるようにするために用いられる情報であって、紐付け中にローカルＲＯＭに恒久的に格納されている決済信用情報を暗号化して入手した識別文字列の長さと、識別文字列データとを含む。

ステップＳ２０５ 決済サーバが料金引き落とし操作を完了できるように、ウェアラブル装置が、事前設定されたフィードバック規則に従って、フィードバックデータを送信する。
決済サーバは、フィードバックデータの受信後に、復号化を行って決済信用情報を入手し、後続の料金引き落とし操作を完了する。
上述の暗号化／復号化法はセキュリティのための保証作業であり、セキュリティが確保されるという前提であれば、暗号化／復号化法のどちらを用いても、又は、別のセキュリティ保護処置を講じても、本願の保護範囲には影響しないことに留意されたい。

３．確認段階
この段階では、ウェアラブル装置が、決済サーバによりフィードバックされた決済工程操作結果に従って確認応答をユーザへ返す。
ウェアラブル装置は、プリセットされた標準インターフェースを介して、決済サーバにより送信された確認要求を受信する。
ウェアラブル装置は確認要求に含まれている確認方式タイプ情報を取得する。
ウェアラブル装置は、確認方式タイプ情報に従って、対応する確認操作を完了する。

具体的には、この実施の形態において、確認要求に含まれている確認方式タイプ情報は、以下の確認方式のうち任意の１つ又は任意の組み合わせを含んでよい：
テキストによる確認、音声による確認、振動による確認。

これに対応して、例えば、テキストによる確認は文字列「決済が成功しました」をウェアラブル装置上へ直接表示してよい。これには、当然ながら、ウェアラブル装置に表示画面が装備されていることが前提条件となる。音声による承認は事前設定された「着信音」を発することができる。振動による確認は、事前設定された回数又は持続時間だけ振動を発することができる。

この確認操作は、主にユーザが決済結果を正確に知ることができるようにするために実行される。当然ながら、決済に成功した場合には更なる操作が不要であると設定してもよい。こうした設定は実際の必要性に応じて調整でき、本願の保護範囲に影響することはない。

本願の実施の形態で提案する技術的解決策の有利な技術的効果を、従来技術と比較して以下に述べる。
本願のこの実施の形態は、サーバと端末装置とで構成されたシステムへ実装される、本人認証のための方法及び装置を開示する。端末装置は、専用タイプのサービスアプリケーションと通信するように構成され、プリセットされた標準インターフェースを内蔵する。本願で提案する技術的解決策により、本人認証操作が必要な場合には、サーバが、プリセットされた標準インターフェースを介し、専用タイプのサービスアプリケーションのアカウントのサービス認証情報を端末装置に要求でき、端末装置は、対応する検証規則に従ってこの処理にセキュリティ検証を実行し、検証に成功した場合に限って、後続の処理のために、ローカルに事前に格納されているサービス認証情報をサーバへフィードバックできる。よって、本人認証工程のセキュリティを、専用タイプのサービスアプリケーションに紐付けされプリセットされた標準インターフェースと、端末装置のセキュリティ検証とによって確保できる。そして、端末装置に現在格納されている本人認証情報を用いることで、端末装置操作者のこの工程への参加感覚を強めることができる。端末装置が具体的にウェアラブル装置である場合は、ユーザの本人認証工程への参加感覚が高まり、本人認証工程のセキュリティが高まり、特に決済認証工程においては本人認証の成功率が上がる。

本願の前出の実施の形態で提供された解決策を、前出の方法と同じ発明概念に基づいてより明瞭に説明するために、本願の実施の形態は更に端末装置を提案する。図４には、この端末装置の概略構造図が示され、この端末装置は具体的に以下を含む。
専用タイプのサービスアプリケーションと通信するように構成された、プリセットされた標準インターフェース４１；
プリセットされた標準インターフェース４１を介して、専用タイプのサービスアプリケーションに対応するサーバから送信された本人認証要求メッセージを受信するように構成された受信モジュール４２であって、ここで、本人認証要求メッセージは、サーバが専用タイプのサービスアプリケーションのサービス要求を受信した後に、サーバから端末装置へ送信される、受信モジュール４２；
専用タイプのサービスアプリケーションの公開鍵に従って、受信モジュール４２が受信した本人認証要求メッセージ内の署名を検証するように構成された検証モジュール４３；
検証モジュール４３による検証に成功した場合に、本人認証要求メッセージに対応するアカウントのサービス認証情報を、端末装置に事前に格納されているサービス認証情報から取得するように構成された取得モジュール４４；
取得モジュール４４が取得したサービス認証情報を含む検証応答メッセージを、プリセットされた標準インターフェース４１を介してサーバへ返すように構成されたフィードバックモジュール４５。

特定のアプリケーションシナリオにおいて：
受信モジュール４２は、専用タイプのサービスアプリケーションにより送信されたアカウントについての紐付け登録要求メッセージを、プリセットされた標準インターフェース４１を介して受信するように更に構成され；
検証モジュール４３は、専用タイプのサービスアプリケーションの公開鍵に従って、受信モジュール４２により受信された紐付け登録要求メッセージ内の署名を検証するように更に構成され；
取得モジュール４４は、検証モジュール４３による検証に成功した場合に、紐付け登録要求メッセージに含まれているサービス認証情報を取得して、このサービス認証情報と、アカウントの本人認証情報とを対応付けて端末装置に保存するように更に構成され；
フィードバックモジュール４５は、端末装置の識別子情報に従って登録応答メッセージを生成し、この登録応答メッセージを、プリセットされた標準インターフェース４１を介して、専用タイプのサービスアプリケーションへ返すように更に構成される。

更に、端末装置は更新モジュール４６を更に含み、
受信モジュール４２は、専用タイプのサービスアプリケーションにより送信された、アカウントについてのサービス認証情報更新要求メッセージを、プリセットされた標準インターフェース４１を介して受信するように更に構成され；
検証モジュール４３は、専用タイプのサービスアプリケーションの公開鍵に従って、受信モジュール４２により受信されたサービス認証情報更新要求メッセージ内の署名を検証し、検証に成功した場合に、端末装置に格納されているサービス認証情報に対応する本人識別情報がサービス認証情報更新要求メッセージに含まれる本人識別情報と一致するかどうかを判断するように更に構成され；
取得モジュール４４は、検証モジュール４３の判断結果が肯定である場合に、サービス認証情報更新要求メッセージに含まれているサービス認証情報を取得するように更に構成され；
更新モジュール４６は、取得モジュール４４により取得されたサービス認証情報のバージョン情報が端末装置にローカルに格納されている現在の対応するサービス認証情報のバージョン情報よりも新しいかどうかを判断し、判断結果が肯定の場合には、端末装置に現在格納されている対応するサービス認証情報を、取得モジュール４４により取得されたサービス認証情報で置き換えるように構成される。

特定のアプリケーションシナリオでは、
受信モジュール４２は、専用タイプのサービスアプリケーションに対応するサーバにより送信された確認要求を、プリセットされた標準インターフェース４１を介して受信するように更に構成され；
取得モジュール４４は、確認要求に含まれている確認方式タイプ情報を取得し、端末装置が、この確認方式タイプ情報に従って、対応する確認操作を完了させられるように更に構成される。

別の態様によれば、本願の実施の形態は、図５の概略構造図で示されるサーバを更に提案する。図５において、サーバは、専用タイプのサービスアプリケーションにサービスを提供する。サーバは具体的に以下を含む。
専用タイプのサービスアプリケーションのサービス要求が受信されると、端末装置に含まれプリセットされた標準インターフェースを介して、端末装置へ本人認証要求メッセージを送信するように構成された送信モジュール５１；
本人認証要求が成功した場合に、プリセットされた標準インターフェースを介して端末装置により返された、サービス認証情報を含む検証応答メッセージを受信するように構成された受信モジュール５２；
受信モジュール５２により受信されたサービス認証メッセージに従って、サービス要求を処理するように構成された処理モジュール５３。

特定のアプリケーションシナリオでは：
送信モジュール５１は、端末装置に含まれプリセットされた標準インターフェースを介して、アカウントについての紐付け登録要求メッセージを端末装置へ送信するように更に構成され、ここで、紐付け登録要求メッセージは当該アカウントのサービス認証情報を含み；
受信モジュール５２は、登録の紐付けに成功した場合に、プリセットされた標準インターフェースを介して端末装置により返された登録応答メッセージを受信し、端末装置がアカウントへの紐付けに成功したことを確認するように更に構成され、ここで、登録応答メッセージは端末装置の識別子情報を含む。

具体的に、送信モジュール５１は更に：
アカウントのサービス認証情報を更新する必要がある場合に、端末装置に含まれるプリセットされた標準インターフェースを介して、アカウントについてのサービス認証情報更新要求メッセージを端末装置へ送信し、ここで、サービス認証情報更新要求メッセージは、更新が必要な、アカウントのサービス認証情報を含み；及び／又は、
処理モジュール５３がサービス要求の処理を完了した後に、端末装置に含まれるプリセットされた標準インターフェースを介して、確認方式タイプ情報を含む確認要求を端末装置へ送信し、これにより、端末装置が、この確認方式タイプ情報に従って、対応する確認操作を完了する；ように構成される。

本願の実施の形態で提案する技術的解決策の有利な技術的効果を、従来技術と比較して以下に述べる。
本願の実施の形態は、サーバと端末装置とによって構成されたシステムへ実装される、本人認証のための方法及び装置を開示する。ここで、端末装置は、専用タイプのサービスアプリケーションと通信するように構成されプリセットされた標準インターフェースを含む。本願で提案する技術的解決策により、本人認証操作が必要な場合にサーバは、プリセットされた標準インターフェースを介して、専用タイプのサービスアプリケーションのアカウントのサービス認証情報を端末装置に要求することができる。端末装置は、対応する検証規則に従って、この工程にセキュリティ検証を実行し、更に、セキュリティ検証に成功した場合に限って、後続の処理のために、ローカルに事前に格納されているサービス認証情報をサーバへフィードバックすることができる。このように、本人認証工程のセキュリティを、専用タイプのサービスアプリケーションに紐付けされているプリセットされた標準インターフェースと、端末装置のセキュリティ検証とによって確保することができ、この工程への端末装置操作者の参加感覚を、端末装置に現在格納されている本人認証情報を用いることで強めることができる。端末装置が具体的にウェアラブル装置である場合には、ユーザの本人認証工程への参加感覚が強められ、本人認証工程のセキュリティが高まり、特に決済認証工程の場合の本人認証の成功率が上がる。

上述の実装手段の説明から、当業者は、本発明の実施の形態がハードウェアによって実装され得ること、又はソフトウェアと必要な汎用ハードウェアプラットフォームとによって実装され得ることを明確に理解することができる。このような理解に基づいて、本発明の実施の形態における技術的解決策は、ソフトウェア製品の形態で実施することができる。ソフトウェア製品は、不揮発性記憶媒体（ＣＤ-ＲＯＭ、ＵＳＢフラッシュディスク、リムーバブルハードディスクなどであってもよい）に格納されてもよく、コンピュータ装置（パーソナルコンピュータ、サーバ、ネットワーク側装置など）を指示するためのいくつかの命令を含み、本発明の実施の形態の様々な実装シナリオで説明した方法のステップのすべて又は一部を実行する。

当業者であれば、添付の図面は、単に好ましい実装シナリオの概略図であり、添付の図面におけるモジュール又は手順は、本発明の実施の形態を実施するために必ずしも必須ではないことを理解することができる。

当業者であれば、実装シナリオにおける装置内のモジュールは、実装シナリオの記述に従って実装シナリオにおいて装置内に分散されてもよく、実装シナリオとは異なる１つ以上の装置に対応付けて変更して配置されてもよいことを理解することができる。実装シナリオのモジュールは、１つのモジュールに結合されてもよく、複数のサブモジュールに分割されてもよい。

本発明の前述の実施の形態のシーケンス番号は、単に説明のためのものであり、実装シナリオの中での優先を暗示するものではない。

上記は、本発明の実施の形態のいくつかの具体的な実装シナリオにすぎない。しかしながら、本発明の実施の形態はこれに限定されるものではない。当業者が想到し得る任意の変更は、本発明の実施の形態のサービス限定範囲内に含まれるものとする。

上記は、本発明の実施の形態のいくつかの具体的な実装シナリオにすぎない。しかしながら、本発明の実施の形態はこれに限定されるものではない。当業者が想到し得る任意の変更は、本発明の実施の形態のサービス限定範囲内に含まれるものとする。
［第１の局面］
専用タイプのサービスアプリケーションと通信するように構成されプリセットされた
標準インターフェースを備える端末装置に実装される本人認証方法であって、前記方法は、具体的に：
前記端末装置により、前記専用タイプの前記サービスアプリケーションに対応するサーバにより送信される本人認証要求メッセージを、前記プリセットされた標準インターフェースを介して受信するステップであって、前記本人認証要求メッセージは、前記サーバが前記専用タイプの前記サービスアプリケーションのサービス要求を受信した後に、前記サーバによって前記端末装置へ送信される、受信するステップと；
前記専用タイプの前記サービスアプリケーションの公開鍵に従って、前記端末装置により、前記本人認証要求メッセージ内の署名を検証するステップと；
前記検証に成功した場合に、ローカルに事前に格納されているサービス認証情報から、前記本人認証要求メッセージに対応するアカウントのサービス認証情報を、前記端末装置により取得するステップと；、
前記端末装置により、前記取得したサービス認証情報を含む検証応答メッセージを、前記プリセットされた標準インターフェースを介して前記サーバへ返すステップと；を備える、
本人認証方法。
［第２の局面］
前記端末装置は：
前記専用タイプの前記サーバアプリケーションにより送信されたアカウントについての紐付け登録要求メッセージを、前記プリセットされた標準インターフェースを介して、前記端末装置により受信するステップと；
前記専用タイプの前記サービスアプリケーションの前記公開鍵に従って、前記紐付け登録要求メッセージ内の署名を、前記端末装置により検証するステップと；
前記検証に成功した場合に、前記端末装置により、前記紐付け登録要求メッセージ内に含まれたサービス認証情報を取得し、及び、前記端末装置により、前記サービス認証情報と前記アカウントの本人識別情報とを対応付けてローカルに保存するステップと；
前記端末装置の識別子情報に従って、前記端末装置により、登録応答メッセージを生成し、及び、前記登録応答メッセージを、前記プリセットされた標準インターフェースを介して、前記端末装置により前記専用タイプの前記サービスアプリケーションへ返すステップと；を用いてサービス認証情報をローカルに事前に保存する、
第１の局面に記載の方法。
［第３の局面］
前記端末装置の前記識別子情報に従って、前記端末装置により前記登録応答メッセージを生成する前記ステップは、具体的に：
一意の識別子情報と、前記端末装置の装置モデル情報とを前記端末装置により取得するステップと；
前記専用タイプの前記サービスアプリケーションが指定したデータ形式に従って、前記一意の識別子情報と前記装置モデル情報とを、前記端末装置によりアセンブルするステップと；
前記端末装置により、ローカルの秘密鍵を用いて、前記アセンブルされた情報に署名し、前記登録応答メッセージを生成するステップと；を備える、
第２の局面に記載の方法。
［第４の局面］
前記紐付け登録要求メッセージに含まれている前記サービス認証情報を前記端末装置により取得し、及び、前記サービス認証情報と前記アカウントの前記本人識別情報とを、前記端末装置により対応付けてローカルに保存する前記ステップの後に：
前記専用タイプの前記サービスアプリケーションにより送信されたアカウントについてのサービス認証情報更新要求メッセージを、前記プリセットされた標準インターフェースを介して前記端末装置により受信するステップと；
前記サービス認証情報更新要求メッセージ内の署名を、前記端末装置により、前記専用タイプの前記サービスアプリケーションの前記公開鍵に従って検証するステップと；
前記検証に成功した場合に、前記端末装置によりローカルに格納されているサービス認証情報に対応する本人識別情報が前記サービス認証情報更新要求メッセージに含まれている本人識別情報と一致するかどうかを、前記端末装置により判断するステップと；
前記判断の結果が肯定であれば、前記サービス認証情報更新要求メッセージに含まれている前記サービス認証情報を取得するステップと；
前記取得したサービス認証情報のバージョン情報が、現在の前記ローカルに格納されている対応するサービス認証情報のバージョン情報よりも新しいかどうかを、前記端末装置により判断するステップと；
前記判断の結果が肯定であれば、前記端末装置により、現在の前記格納されている対応するサービス認証情報を、前記取得したサービス認証情報で置き換えるステップと；を更に備える、
第２の局面に記載の方法。
［第５の局面］
前記取得したサービス認証情報を含む前記検証応答メッセージを、前記プリセットされた標準インターフェースを介して前記端末装置により前記サーバへ返すステップの後に：
前記専用タイプの前記サービスアプリケーションに対応する前記サーバにより送信された確認要求を、前記プリセットされた標準インターフェースを介して前記端末装置により受信するステップと；
前記確認要求に含まれている確認方式タイプ情報を、前記端末装置により取得するステップと；
前記確認方式タイプ情報に従って、前記端末装置により、対応する確認操作を完了するステップと；を更に備える、
第１の局面に記載の方法。
［第６の局面］
専用タイプのサービスアプリケーションに対応するサーバに実装される本人認証方法であって、前記サーバは、端末装置に含まれプリセットされた標準インターフェースを介して、前記端末装置と通信し、前記方法は、具体的に：
前記サーバにより、前記専用タイプの前記サービスアプリケーションのサービス要求を受信するステップと；
前記端末装置に含まれプリセットされた前記標準インターフェースを介して、前記サーバにより、前記端末へ本人認証要求メッセージを送信するステップと；
本人認証要求に成功した場合に、前記プリセットされた標準インターフェースを介して前記端末装置から返されサービス認証情報を含む検証応答メッセージを、前記サーバにより受信するステップと；
サービス認証メッセージに従って、前記サーバにより前記サービス要求を処理するステップと；を備える、
本人認証方法。
［第７の局面］
前記専用タイプの前記サービスアプリケーションの前記サービス要求を、前記サーバにより受信するステップの前に：
アカウントについての紐付け登録要求メッセージを、前記端末装置に含まれプリセットされた前記標準インターフェースを介して前記サーバにより前記端末装置へ送信するステップであって、前記紐付け登録要求メッセージは前記アカウントのサービス認証情報を含む、送信するステップと；
前記登録の紐付けに成功した場合に、プリセットされた前記標準インターフェースを介して前記端末装置により返される登録応答メッセージを、前記サーバにより受信し、及び、前記端末装置の、前記アカウントへの紐付けが成功したことを前記サーバにより確認するステップと；を備え、
前記登録応答メッセージは、前記端末装置の識別子情報を含む、
第６の局面に記載の方法。
［第８の局面］
前記端末装置の、前記アカウントへの紐付けが成功したことを前記サーバにより確認した後に、前記方法は：
前記アカウントの前記サービス認証情報を更新する必要がある場合に、前記アカウントについてのサービス認証情報更新要求メッセージを、前記端末装置に含まれプリセットされた前記標準インターフェースを介して、前記サーバにより前記端末装置へ送信するステップを更に備え、
前記サービス認証情報更新要求メッセージは、前記アカウントの、更新が必要な前記サービス認証情報を含む、
第７の局面に記載の方法。
［第９の局面］
前記サービス認証メッセージに従ってなされる、前記サーバによる、前記サービス要求の前記処理の後に、前記方法は：
前記端末装置が確認方式タイプ情報に従って対応の確認操作を完了できるようにするために、前記サービス要求の処理が完了した後に、前記確認方式タイプ情報を含む確認要求を、前記端末装置に含まれプリセットされた前記標準インターフェースを介して、前記サーバにより前記端末装置へ送信するステップを更に備える、
第６の局面に記載の方法。
［第１０の局面］
端末装置であって、具体的に：
専用タイプのサービスアプリケーションと通信するように構成されプリセットされた標準インターフェースと；
前記専用タイプのサービスアプリケーションに対応するサーバにより送信された本人認識要求メッセージを、前記プリセットされた標準インターフェースを介して受信するように構成された受信モジュールであって、前記本人認証要求メッセージは、前記サーバが前記専用タイプの前記サービスアプリケーションのサービス要求を受信した後に、前記サーバにより前記端末装置へ送信される、受信モジュールと；
前記受信モジュールにより受信された前記本人認証要求メッセージ内の署名を、前記専用タイプの前記サービスアプリケーションの公開鍵に従って検証するように構成された検証モジュールと；
前記検証モジュールによる前記検証に成功した場合に、前記端末装置へ事前に格納されているサービス認証情報から、前記本人認証要求メッセージに対応するアカウントのサービス認証情報を取得するように構成された取得モジュールと；
前記取得モジュールにより取得され前記サービス認証情報を含む検証応答メッセージを、前記プリセットされた標準インターフェースを介して前記サーバへ返すように構成されたフィードバックモジュールと；を備える、
端末装置。
［第１１の局面］
前記受信モジュールは、前記専用タイプの前記サービスアプリケーションにより送信されたアカウントについての紐付け登録要求メッセージを、前記プリセットされた標準インターフェースを介して受信するように更に構成され；
前記検証モジュールは、前記受信モジュールにより受信された前記紐付け登録要求メッセージ内の署名を、前記専用タイプの前記サービスアプリケーションの前記公開鍵に従って検証するように更に構成され；
前記取得モジュールは、前記検証モジュールによる前記検証に成功した場合に、前記紐付け登録要求メッセージに含まれているサービス認証情報を取得し、前記サービス認証情報と、前記アカウントの本人識別情報とを対応付けて前記端末装置に保存するように更に構成され；
前記フィードバックモジュールは、前記端末装置の識別子情報に従って登録応答メッセージを生成し、前記登録応答メッセージを、前記プリセットされた標準インターフェースを介して、前記専用タイプの前記サービスアプリケーションへ返すように更に構成された；
第１０の局面に記載の端末装置。
［第１２の局面］
更新モジュールを更に備え；
前記受信モジュールは、前記専用タイプの前記サービスアプリケーションにより送信されるアカウントについてのサービス認証情報更新要求メッセージを、プリセットされた前記標準インターフェースを介して受信するように更に構成され；
前記検証モジュールは、前記受信モジュールにより受信される前記サービス認証情報更新要求メッセージ内の署名を、前記専用タイプの前記サービスアプリケーションの前記公開鍵に従って検証し、前記検証に成功した場合に、前記端末装置に格納されている前記サービス認証情報に対応する本人識別情報が前記サービス認証情報更新要求メッセージに含まれている本人識別情報と一致するかどうかを判断するように更に構成され；
前記取得モジュールは、前記検証モジュールの前記判断の結果が肯定である場合に、前記サービス認証情報更新要求メッセージに含まれている前記サービス認証情報を取得するように更に構成され；
前記更新モジュールは、前記取得モジュールが取得する前記サービス認証情報のバージョン情報が、前記端末装置へローカルに格納されている現在の前記対応サービス認証情報のバージョン情報よりも新しいかどうかを判断し、前記判断の結果が肯定である場合には、前記端末装置に現在格納されている前記対応サービス認証情報を、前記取得モジュールにより取得された前記サービス認証情報と置き換えるように構成された、
第１１の局面に記載の端末装置。
［第１３の局面］
前記受信モジュールは、前記専用タイプの前記サービスアプリケーションに対応する前記サーバにより送信される確認要求を、プリセットされた前記標準インターフェースを介して受信するように更に構成され；
前記取得モジュールは、前記確認要求に含まれている確認方式タイプ情報を取得し、これにより、前記端末装置が前記確認方式タイプ情報に従って、対応する確認操作を完了するように更に構成された、
第１０の局面に記載の端末装置。
［第１４の局面］
専用タイプのサービスアプリケーションに対応するサーバであって、具体的に：
前記専用タイプの前記サービスアプリケーションのサービス要求を受信すると、端末装置に含まれプリセットされた標準インターフェースを介して、前記端末装置へ本人認証要求メッセージを送信するように構成された送信モジュールと；
本人認証要求に成功した場合に、プリセットされた前記標準インターフェースを介して前記端末装置から返されサービス認証情報を含む検証応答メッセージを受信するように構成された受信モジュールと；
前記サービス要求を、前記受信モジュールにより受信されたサービス認証メッセージに従って処理するように構成された処理モジュールと；を備える、
サーバ。
［第１５の局面］
前記送信モジュールは、アカウントについての紐付け登録要求メッセージを、前記端末装置に含まれプリセットされた前記標準インターフェースを介して、前記端末装置へ送信するように更に構成され、前記紐付け登録要求メッセージは前記アカウントのサービス認証情報を含み；
前記受信モジュールは、前記登録の紐付けに成功した場合に、プリセットされた前記標準インターフェースを介して、前記端末装置により返された登録応答メッセージを受信し、前記端末装置による前記アカウントへの紐付けに成功したことを確認するように更に構成され、前記登録応答メッセージは、前記端末装置の識別子情報を含む；
第１４の局面に記載のサーバ。
［第１６の局面］
前記送信モジュールは：
前記アカウントの前記サービス認証情報を更新する必要がある場合に、前記アカウントについてのサービス認証情報更新要求メッセージを、前記端末装置に含まれプリセットされた前記標準インターフェースを介して、前記端末装置へ送信し、前記サービス認証情報更新要求メッセージは、前記アカウントの更新が必要な前記サービス認証情報を含む；
及び／又は、
前記処理モジュールが前記サービス要求の処理を完了した後に、確認方式タイプ情報を含む確認要求を、前記端末装置に含まれプリセットされた前記標準インターフェースを介して前記端末装置へ送信し、これにより、前記端末装置が、前記確認方式タイプ情報に従って対応の確認操作を完了する：ように更に構成された、
第１４の局面に記載のサーバ。

Claims (16)

1. 専用タイプのサービスアプリケーションと通信するように構成されプリセットされた標準インターフェースを備える端末装置に実装される本人認証方法であって、前記方法は、具体的に：
   前記端末装置により、前記専用タイプの前記サービスアプリケーションに対応するサーバにより送信される本人認証要求メッセージを、前記プリセットされた標準インターフェースを介して受信するステップであって、前記本人認証要求メッセージは、前記サーバが前記専用タイプの前記サービスアプリケーションのサービス要求を受信した後に、前記サーバによって前記端末装置へ送信される、受信するステップと；
   前記専用タイプの前記サービスアプリケーションの公開鍵に従って、前記端末装置により、前記本人認証要求メッセージ内の署名を検証するステップと；
   前記検証に成功した場合に、ローカルに事前に格納されているサービス認証情報から、前記本人認証要求メッセージに対応するアカウントのサービス認証情報を、前記端末装置により取得するステップと；、
   前記端末装置により、前記取得したサービス認証情報を含む検証応答メッセージを、前記プリセットされた標準インターフェースを介して前記サーバへ返すステップと；を備える、
   本人認証方法。
2. 前記端末装置は：
   前記専用タイプの前記サーバアプリケーションにより送信されたアカウントについての紐付け登録要求メッセージを、前記プリセットされた標準インターフェースを介して、前記端末装置により受信するステップと；
   前記専用タイプの前記サービスアプリケーションの前記公開鍵に従って、前記紐付け登録要求メッセージ内の署名を、前記端末装置により検証するステップと；
   前記検証に成功した場合に、前記端末装置により、前記紐付け登録要求メッセージ内に含まれたサービス認証情報を取得し、及び、前記端末装置により、前記サービス認証情報と前記アカウントの本人識別情報とを対応付けてローカルに保存するステップと；
   前記端末装置の識別子情報に従って、前記端末装置により、登録応答メッセージを生成し、及び、前記登録応答メッセージを、前記プリセットされた標準インターフェースを介して、前記端末装置により前記専用タイプの前記サービスアプリケーションへ返すステップと；を用いてサービス認証情報をローカルに事前に保存する、
   請求項１に記載の方法。
3. 前記端末装置の前記識別子情報に従って、前記端末装置により前記登録応答メッセージを生成する前記ステップは、具体的に：
   一意の識別子情報と、前記端末装置の装置モデル情報とを前記端末装置により取得するステップと；
   前記専用タイプの前記サービスアプリケーションが指定したデータ形式に従って、前記一意の識別子情報と前記装置モデル情報とを、前記端末装置によりアセンブルするステップと；
   前記端末装置により、ローカルの秘密鍵を用いて、前記アセンブルされた情報に署名し、前記登録応答メッセージを生成するステップと；を備える、
   請求項２に記載の方法。
4. 前記紐付け登録要求メッセージに含まれている前記サービス認証情報を前記端末装置により取得し、及び、前記サービス認証情報と前記アカウントの前記本人識別情報とを、前記端末装置により対応付けてローカルに保存する前記ステップの後に：
   前記専用タイプの前記サービスアプリケーションにより送信されたアカウントについてのサービス認証情報更新要求メッセージを、前記プリセットされた標準インターフェースを介して前記端末装置により受信するステップと；
   前記サービス認証情報更新要求メッセージ内の署名を、前記端末装置により、前記専用タイプの前記サービスアプリケーションの前記公開鍵に従って検証するステップと；
   前記検証に成功した場合に、前記端末装置によりローカルに格納されているサービス認証情報に対応する本人識別情報が前記サービス認証情報更新要求メッセージに含まれている本人識別情報と一致するかどうかを、前記端末装置により判断するステップと；
   前記判断の結果が肯定であれば、前記サービス認証情報更新要求メッセージに含まれている前記サービス認証情報を取得するステップと；
   前記取得したサービス認証情報のバージョン情報が、現在の前記ローカルに格納されている対応するサービス認証情報のバージョン情報よりも新しいかどうかを、前記端末装置により判断するステップと；
   前記判断の結果が肯定であれば、前記端末装置により、現在の前記格納されている対応するサービス認証情報を、前記取得したサービス認証情報で置き換えるステップと；を更に備える、
   請求項２に記載の方法。
5. 前記取得したサービス認証情報を含む前記検証応答メッセージを、前記プリセットされた標準インターフェースを介して前記端末装置により前記サーバへ返すステップの後に：
   前記専用タイプの前記サービスアプリケーションに対応する前記サーバにより送信された確認要求を、前記プリセットされた標準インターフェースを介して前記端末装置により受信するステップと；
   前記確認要求に含まれている確認方式タイプ情報を、前記端末装置により取得するステップと；
   前記確認方式タイプ情報に従って、前記端末装置により、対応する確認操作を完了するステップと；を更に備える、
   請求項１に記載の方法。
6. 専用タイプのサービスアプリケーションに対応するサーバに実装される本人認証方法であって、前記サーバは、端末装置に含まれプリセットされた標準インターフェースを介して、前記端末装置と通信し、前記方法は、具体的に：
   前記サーバにより、前記専用タイプの前記サービスアプリケーションのサービス要求を受信するステップと；
   前記端末装置に含まれプリセットされた前記標準インターフェースを介して、前記サーバにより、前記端末へ本人認証要求メッセージを送信するステップと；
   本人認証要求に成功した場合に、前記プリセットされた標準インターフェースを介して前記端末装置から返されサービス認証情報を含む検証応答メッセージを、前記サーバにより受信するステップと；
   サービス認証メッセージに従って、前記サーバにより前記サービス要求を処理するステップと；を備える、
   本人認証方法。
7. 前記専用タイプの前記サービスアプリケーションの前記サービス要求を、前記サーバにより受信するステップの前に：
   アカウントについての紐付け登録要求メッセージを、前記端末装置に含まれプリセットされた前記標準インターフェースを介して前記サーバにより前記端末装置へ送信するステップであって、前記紐付け登録要求メッセージは前記アカウントのサービス認証情報を含む、送信するステップと；
   前記登録の紐付けに成功した場合に、プリセットされた前記標準インターフェースを介して前記端末装置により返される登録応答メッセージを、前記サーバにより受信し、及び、前記端末装置の、前記アカウントへの紐付けが成功したことを前記サーバにより確認するステップと；を備え、
   前記登録応答メッセージは、前記端末装置の識別子情報を含む、
   請求項６に記載の方法。
8. 前記端末装置の、前記アカウントへの紐付けが成功したことを前記サーバにより確認した後に、前記方法は：
   前記アカウントの前記サービス認証情報を更新する必要がある場合に、前記アカウントについてのサービス認証情報更新要求メッセージを、前記端末装置に含まれプリセットされた前記標準インターフェースを介して、前記サーバにより前記端末装置へ送信するステップを更に備え、
   前記サービス認証情報更新要求メッセージは、前記アカウントの、更新が必要な前記サービス認証情報を含む、
   請求項７に記載の方法。
9. 前記サービス認証メッセージに従ってなされる、前記サーバによる、前記サービス要求の前記処理の後に、前記方法は：
   前記端末装置が確認方式タイプ情報に従って対応の確認操作を完了できるようにするために、前記サービス要求の処理が完了した後に、前記確認方式タイプ情報を含む確認要求を、前記端末装置に含まれプリセットされた前記標準インターフェースを介して、前記サーバにより前記端末装置へ送信するステップを更に備える、
   請求項６に記載の方法。
10. 端末装置であって、具体的に：
    専用タイプのサービスアプリケーションと通信するように構成されプリセットされた標準インターフェースと；
    前記専用タイプのサービスアプリケーションに対応するサーバにより送信された本人認識要求メッセージを、前記プリセットされた標準インターフェースを介して受信するように構成された受信モジュールであって、前記本人認証要求メッセージは、前記サーバが前記専用タイプの前記サービスアプリケーションのサービス要求を受信した後に、前記サーバにより前記端末装置へ送信される、受信モジュールと；
    前記受信モジュールにより受信された前記本人認証要求メッセージ内の署名を、前記専用タイプの前記サービスアプリケーションの公開鍵に従って検証するように構成された検証モジュールと；
    前記検証モジュールによる前記検証に成功した場合に、前記端末装置へ事前に格納されているサービス認証情報から、前記本人認証要求メッセージに対応するアカウントのサービス認証情報を取得するように構成された取得モジュールと；
    前記取得モジュールにより取得され前記サービス認証情報を含む検証応答メッセージを、前記プリセットされた標準インターフェースを介して前記サーバへ返すように構成されたフィードバックモジュールと；を備える、
    端末装置。
11. 前記受信モジュールは、前記専用タイプの前記サービスアプリケーションにより送信されたアカウントについての紐付け登録要求メッセージを、前記プリセットされた標準インターフェースを介して受信するように更に構成され；
    前記検証モジュールは、前記受信モジュールにより受信された前記紐付け登録要求メッセージ内の署名を、前記専用タイプの前記サービスアプリケーションの前記公開鍵に従って検証するように更に構成され；
    前記取得モジュールは、前記検証モジュールによる前記検証に成功した場合に、前記紐付け登録要求メッセージに含まれているサービス認証情報を取得し、前記サービス認証情報と、前記アカウントの本人識別情報とを対応付けて前記端末装置に保存するように更に構成され；
    前記フィードバックモジュールは、前記端末装置の識別子情報に従って登録応答メッセージを生成し、前記登録応答メッセージを、前記プリセットされた標準インターフェースを介して、前記専用タイプの前記サービスアプリケーションへ返すように更に構成された；
    請求項１０に記載の端末装置。
12. 更新モジュールを更に備え；
    前記受信モジュールは、前記専用タイプの前記サービスアプリケーションにより送信されるアカウントについてのサービス認証情報更新要求メッセージを、プリセットされた前記標準インターフェースを介して受信するように更に構成され；
    前記検証モジュールは、前記受信モジュールにより受信される前記サービス認証情報更新要求メッセージ内の署名を、前記専用タイプの前記サービスアプリケーションの前記公開鍵に従って検証し、前記検証に成功した場合に、前記端末装置に格納されている前記サービス認証情報に対応する本人識別情報が前記サービス認証情報更新要求メッセージに含まれている本人識別情報と一致するかどうかを判断するように更に構成され；
    前記取得モジュールは、前記検証モジュールの前記判断の結果が肯定である場合に、前記サービス認証情報更新要求メッセージに含まれている前記サービス認証情報を取得するように更に構成され；
    前記更新モジュールは、前記取得モジュールが取得する前記サービス認証情報のバージョン情報が、前記端末装置へローカルに格納されている現在の前記対応サービス認証情報のバージョン情報よりも新しいかどうかを判断し、前記判断の結果が肯定である場合には、前記端末装置に現在格納されている前記対応サービス認証情報を、前記取得モジュールにより取得された前記サービス認証情報と置き換えるように構成された、
    請求項１１に記載の端末装置。
13. 前記受信モジュールは、前記専用タイプの前記サービスアプリケーションに対応する前記サーバにより送信される確認要求を、プリセットされた前記標準インターフェースを介して受信するように更に構成され；
    前記取得モジュールは、前記確認要求に含まれている確認方式タイプ情報を取得し、これにより、前記端末装置が前記確認方式タイプ情報に従って、対応する確認操作を完了するように更に構成された、
    請求項１０に記載の端末装置。
14. 専用タイプのサービスアプリケーションに対応するサーバであって、具体的に：
    前記専用タイプの前記サービスアプリケーションのサービス要求を受信すると、端末装置に含まれプリセットされた標準インターフェースを介して、前記端末装置へ本人認証要求メッセージを送信するように構成された送信モジュールと；
    本人認証要求に成功した場合に、プリセットされた前記標準インターフェースを介して前記端末装置から返されサービス認証情報を含む検証応答メッセージを受信するように構成された受信モジュールと；
    前記サービス要求を、前記受信モジュールにより受信されたサービス認証メッセージに従って処理するように構成された処理モジュールと；を備える、
    サーバ。
15. 前記送信モジュールは、アカウントについての紐付け登録要求メッセージを、前記端末装置に含まれプリセットされた前記標準インターフェースを介して、前記端末装置へ送信するように更に構成され、前記紐付け登録要求メッセージは前記アカウントのサービス認証情報を含み；
    前記受信モジュールは、前記登録の紐付けに成功した場合に、プリセットされた前記標準インターフェースを介して、前記端末装置により返された登録応答メッセージを受信し、前記端末装置による前記アカウントへの紐付けに成功したことを確認するように更に構成され、前記登録応答メッセージは、前記端末装置の識別子情報を含む；
    請求項１４に記載のサーバ。
16. 前記送信モジュールは：
    前記アカウントの前記サービス認証情報を更新する必要がある場合に、前記アカウントについてのサービス認証情報更新要求メッセージを、前記端末装置に含まれプリセットされた前記標準インターフェースを介して、前記端末装置へ送信し、前記サービス認証情報更新要求メッセージは、前記アカウントの更新が必要な前記サービス認証情報を含む；
    及び／又は、
    前記処理モジュールが前記サービス要求の処理を完了した後に、確認方式タイプ情報を含む確認要求を、前記端末装置に含まれプリセットされた前記標準インターフェースを介して前記端末装置へ送信し、これにより、前記端末装置が、前記確認方式タイプ情報に従って対応の確認操作を完了する：ように更に構成された、
    請求項１４に記載のサーバ。

Images