JP2017146596A - 機器内の情報を移行するシステム及び方法 - Google Patents

Abstract

【課題】バックアップされた情報は、以前の機器に固有の情報で暗号化されたままであるため、新たな機器に情報が引き継がれても、その引き継がれた情報を新たな機器において復号することができない。【解決手段】第１の機器が、第１の機器の所有者に固有の情報でありその所有者について異なる機器で同じ情報である所有者固有情報を用いたキーで、第１の機器内の情報である機器情報を暗号化し、その暗号化機器情報を出力する。第２の機器が、暗号化機器情報を、所有者固有情報を用いたキーで復号する。【選択図】図３２

Description

本発明は、概して、機器内の情報の移行に関する。

機器内の情報は、例えば、認証のようなアクセス制御で使用される。アクセス制御では、一般に、識別符号が使用される。「識別符号」には、認証等のアクセス制御に用いられるあらゆるデータが該当し得る。本明細書で言う「識別符号」は、不正アクセス禁止法（正確には、不正アクセス行為の禁止等に関する法律）で使用される「識別符号」の意味を含んでよい。識別符号の一例として、ワンタイムパスワードのようなパスワードが知られている。パスワードを用いた認証技術として、例えば特許文献１が知られている。

特許第３６７８４１７号明細書

機器内の情報が、その機器に固有の情報、例えば、個体識別番号（IMEI（International Mobile Equipment Identity））、ＭＡＣアドレス、製造番号及びＳＩＭ（Subscriber Identity Module）カードの製造番号で暗号化されることを仮定する。この場合、その機器内の情報が外部に漏洩しても、その機器に固有の情報が漏洩しない限り、漏洩した情報が解読されることはない。

また、ユーザは、機器内の情報をサーバ等の外部装置にバックアップすることがある。情報漏洩に備えて、バックアップ先の装置でも、情報は、機器に固有の情報で暗号化されたままとなっていることが好ましいと考えられる。

機器を紛失した又は機種を変更した等の理由で、ユーザは、新たな機器を使用することがある。その場合、新たな機器に、バックアップされた情報を引き継ぐことができれば、ユーザにとって便利である。

しかし、バックアップされた情報は、以前の機器に固有の情報で暗号化されたままであるため、新たな機器に情報が引き継がれても、その引き継がれた情報を新たな機器において復号することができない。

第１の機器が、第１の機器の所有者に固有の情報であり所有者に関して異なる機器で同じ情報である所有者固有情報を用いたキーで、第１の機器内の情報である機器情報を暗号化し、その暗号化機器情報を出力（例えば、保存又は送信）する。所有者固有情報は、暗号化の都度に手動で第１の機器に入力されてもよいが、第１の機器（例えば第１の機器で実行されるアプリケーション）に所有者固有情報が設定されていて、暗号化の際、第１の機器が、所有者固有情報を自動的にキーに用いることが好ましい。暗号化機器情報の出力先は、第１の機器内の記憶装置（例えば、内蔵されている又は取外し可能なメモリ）と、第１の機器外の記憶装置（例えば、複数の機器と通信可能なサーバ）とのうちの少なくとも１つでよい。出力先が、第１の機器外の記憶装置の場合、その記憶装置は、タグが関連付けられた暗号化機器情報を保管する。タグには、手動で所有者に入力された情報（例えば情報の名前）が含まれてもよいし、機器情報の暗号化に使用されたキーに用いられた所有者固有情報が自動で含まれてもよい。

第２の機器は、暗号化機器情報を、所有者固有情報を用いたキーで復号する。例えば、第２の機器は、第１の機器、又は、第１の機器外の記憶装置から、暗号化機器情報を受信する。後者の場合、第２の機器は、記憶装置に、タグに含まれている情報が関連付いたリクエスト（例えば所有者固有情報が自動で関連付けられたリクエスト）を送信し、そのリクエストに応答して、その関連付いている情報を用いて特定されたタグが関連付いている暗号化機器情報を記憶装置から受信する。

機器間で、情報を、暗号化したままの状態で移行することができる。

実施例１に係る認証プロセスの概略を示す。 U_Mの構成例を示す。 U_Pの構成例を示す。 S_i ^(j)（S₁ ⁽¹⁾）の構成例を示す。 C^(j)（C⁽¹⁾）の構成例を示す。 uList_i ^(j)（uList₁ ⁽¹⁾）の構成例を示す。 aList^(j)（aList⁽¹⁾）の構成例を示す。 pListの構成例を示す。 sList^(j)（sList⁽¹⁾）の構成例を示す。 cList^(j)（cList⁽¹⁾）の構成例を示す。 C⁽¹⁾によるtpw提供を示す。 初回登録のフローの一例を示す。 ２回目以降登録のフローの一例を示す。 実施例１に係るtpw発行フローの一例を示す。 実施例２に係る認証システムの一例を示す。 pListの一例を示す。 実施例２に係るtpw発行フローの一例を示す。 実施例３に係るtpw発行フローの一例を示す。 図１８の具体例を示す。 実施例４に係るtpw発行フローの一例を示す。 実施例５に係るtpw発行フローの一例を示す。 実施例６に係るtpw削除フローの一例を示す。 実施例７に係るuList_i ^(j)の構成例を示す。 実施例７に係るaList^(j)の構成例を示す。 実施例８に係る認証／連携フローの一例を示す。 識別符号管理の概要の一例を示す。 シャッターシステムの構成例を示す。 認登録手続き１、登録手続き２、及び、認証シャッター操作手続きの各々のフローの一例を示す。 ログイン手続きのフローの一例を示す。 画面遷移の例を示す。 実施例８に係る登録フローの一例を示す。 pListの保管及び復元のフローの一例を示す。 クローン対策のフローの一例を示す。

本発明の一実施形態の一例として、本出願後に公表予定の論文（本願発明の発明者多田・糸井両名による論文）の記載を引用する。なお、下記の記載では、「発行センタ」は、図１以降を参照して説明する「制御センタ」の別の呼び名に相当する。また、「ユーザ」は、所有者の一例である。

概要

ワンタイムパスワード(OTP)認証は、(固定)パスワード認証が抱える安全性の問題を解決するための1つの手段として、金融関係サイトなど一部のシステムで採用されている。しかし、通常のパスワード認証と比べて、安全性においては優位であるものの、その利便性については解決すべき問題が多い。我々の研究グループは、2011年開催のコンピュータセキュリティシンポジウム(CSS2011)以降、2要素3者間によるOTP認証システムに取り組み、必要となる各処理に対するプロトコルを構築、その安全性の解析を行うと共に、システムの機能を拡張することが可能であることを示した。しかし、それらを実際構築しサービスとして提供するためには、ユーザから見た利便性も重要な要素となる。本稿では、他のOTP認証方式と比較しつつ、我々の提案システムの利便性、およびその改良可能性について述べる。

1. はじめに

現在、ネットワーク上には様々なサービスシステムが存在し、ユーザはその恩恵を受けている。個々のユーザに対応したサービスを提供するシステムの場合、ユーザがアクセスしたときにログインの処理をさせ、アクセスしてきた者が(サービスシステムに登録されている)どのアカウントに対するユーザなのかを識別・認証している。その際利用されている認証方法として最も普及しているのが「ユーザID&(固定)パスワード」によるもの((固定)パスワード認証)である。

固定パスワード認証は「記憶情報による認証(SYK)」であり、IPAが2014年8月に公開した「オンライン本人認証方式の実態調査報告書」[1]によれば、調査したサイトの全てで採用されている。確かに、固定パスワードによる認証システムは、導入が容易であり、ユーザにも馴染み深く、非常に便利な認証方法であることには間違いないが、総当たり(ブルートフォース)攻撃や辞書攻撃、いわゆるリバースブルートフォース攻撃やリスト型アカウントハッキングなどのパスワードクラッキングの脅威に晒されていることも事実である。

固定パスワード認証の弱点は、ユーザ自身にパスワードの設定を任せていることに起因する。つまりユーザ自身が、単純な文字列をパスワードとして設定したり、同一のパスワードを複数のサービスシステムで設定したりすることによって、クラックされやすくなるのである。

ワンタイムパスワード(OTP)認証は、(固定)パスワード認証の弱点を克服し安全性を高めるための手段の1つとして、一部のサービスシステム、特に金融サービスシステムで比較的高い割合で採用されている[1]。

我々の研究グループは、2011年[3]以来、OTP認証システムに関する研究発表を行ってきた[4][7]。これは、従来のOTP認証システムとは違い、ユーザ、サービスシステムの他に、OTPの発行を行う発行センタが登場する3者間認証であり、ユーザが所有する携帯電話機器を利用し発行センタに対して(記憶および使用機器の)2要素認証を行うことにより、発行センタにより発行されたOTPがユーザの携帯電話機器(およびサービスシステム)に通知されるというものである。提案システムは、OTP認証システムとして比較的普及している(第2章で紹介する)ハード/ソフトトークンによる方式とは違い、OTPを生成するエンティティとして登場するのが発行センタのみなので、システム全体としては発行センタの運用コストがかかるものの、OTP生成ロジックを秘匿にするのが容易であり、ロジック更新の際にユーザが行わなければならない作業は特にないなどの利点を持つ。

しかし、我々のシステムも含め、一般的にOTP認証は、ユーザから見ると面倒/手間のかかる/解りづらいものである。特に、OTP生成トークン紛失の際には、ほぼ再登録に近い処理が必要となる。ハードトークンの場合は、新しい機器の用意、その機器に対する処理、および、その機器の安全な配付は、サービスシステムが行わなければならないことであり、そのコストは決して無視できない。

本論文では、ユーザがOTPを取得するための携帯電話機器を、ユーザの意思、または意思とは関係なく、紛失/盗難/故障/破損等の理由により機種変更する場合に、アカウント情報を再設定する必要なく、ユーザにとって手間のかからない方法を述べる。これにより、OTP認証システムの利便性の向上が期待できる。

本論文は以下の通り構成される。第2章では現在普及しているOTP認証方法を紹介し、第3 章で我々が発表してきた方法の概略を述べる。ここれは、表記を簡潔にするため、オプション扱いできるパラメータ等はなるべく省略して記述している。第4 章において、ユーザにとって手間のかからない機種変更方法を述べる。第5章では、本提案手法が他のOTP認証システムに適用できるかどうかを述べ、さらに、第4章で登場するユーザパラメータの選択・設定方法について述べ、第6 章で本論文をまとめる。

2. ワンタイムパスワード認証

ワンタイムパスワードは、文字通り、一度きりの使い捨てのパスワードであるが、パスワードであるため、どのようにしてユーザ⇔サービスシステム間で正しく共有し認証できるようにするかが問題になる。それを解決する手段に
より、OTP認証を下記のように分類することができる。

2.1 マトリクス認証方式

マトリクス認証は、ユーザがログインしようとするとき、サービスシステムが碁盤目状の数字の列を提示し、予めユーザが登録している盤面上の位置に従ってパスワード文字列を定めるというものである。しかし、固定パスワード方式と同様、記憶のみの認証になっているという弱点はあるが、以下で述べる「乱数表方式」「トークン方式」とは違い、配付物もクライアントソフトも必要としないという利点をもつ。

2.2 乱数表方式

乱数表方式は、登録時にサービスシステムが個別に配付した乱数表を使ったものである。ユーザがログインするとき、サービスシステムが表の行と列を指定し、ユーザはその乱数表に記載されている数値を入力するというものである。所有物認証の1つと考えることができるものの、その乱数表の複製や共有は容易であり、また、ログイン時にユーザが紙媒体である表を見ながら行と列を辿りながら数値を入力しなければならないという欠点もあるが、導入コストは一般的に低く抑えることができるという利点もある。

2.3 ハード/ソフトトークン方式

ユーザがサービスシステムに登録されるときに、サービスシステムがOTPの生成を行うプログラムを個別に配付し、ユーザはログインする際、そのプログラムを実行することによりOTP を入手するというものである。プログラムが専用デバイスに実装されたものや、スマートデバイス上で動作するアプリとして配付されたりするものがある。前者の場合、そのデバイスをハードトークンといい、後者の場合、そのアプリをソフトトークンという。ハードトークンの場合、ユーザはサービスを利用するとき、その専用デバイスが必要となるが、紛失や更新に伴う運用コストは無視できない。ソフトトークンの場合、そのようなコストは発生しにくい。

3. 3者間OTP認証システム[3]

本章では、[3]で示されている2 要素3 者間によるOTP認証方式の概略を述べる。登場するエンティティはユーザ(U)、サービスシステム(S)および発行センタ(C)の3者である。我々が発表した[2]では、複数のサービスシステムをS_i ^(j) のように表したが、本論文では表記を簡単にするため、サービスシステムは1つ(S)のみとする。ユーザは、サービスシステムを利用するための端末U_Pと、発行センタにOTP発行等のリクエストを送るための携帯電話機器U_Mを持つ^*1。

ユーザは、まずサービスシステムSにユーザ登録する。これは、一般に普及しているサービスシステムで行っているのと同様の手続きで行ってもよい。この時点でユーザUとサービスシステムSの間で、UがSを利用する際のID情報(ユーザID、uID)、およびその識別符号fPwを共有しているものとする。また、サービスシステムSは、サービスシステムID(sysID)を持ち、sysIDは当該サービスシステムに関する情報と共にCに登録されているものとする。

Uが本3者間認証システムに登録を済ませると、以下の状態になる。
(C1) SにおけるUのアカウント(uID)に紐付けられたID情報(管理マスタID、mID)が、SとCの間に共有される。
(C2) Uが所有するU_MとCの間にID情報(アプリケーションID、aID)が共有され、CにおいてaIDは前項(C1)におけるmIDと紐付けられる。
(C3) U_Mには、Cが生成したパラメータ(pass)が暗号化された状態で保存され、正しく復号するためにはU_Mを用いることが必要である。
以上の状態を作り出すため、UはSおよびCに対して、以下に示す2つのフェーズからなる登録手続きを行う。

3.1 登録手続き(その1)

Sが(Sに)登録されているユーザに紐付けられるためのアカウントをCに追加するリクエストを送り、その(Cにおける)アカウントに対してUが紐付け登録できるようにするための登録チケットを(Cが)発行する手続きである。
(R1) Uは、Sに、3者間認証登録リクエストとして、uIDを送る。
(R2) Sは、Cに、アカウント追加リクエストとして、sysIDを送る。
(R3) Cは、そのデータベースに1つアカウントを追加し、それに対して一意的な管理マスタID(mID)を生成し、sysIDも併せて割り当てる。さらにCは、登録チケットticket、および、ticketの正しさを検証するのに必要な情報verTicketを生成^*2し、verTicketを当該アカウントに割り当てる。なお、ticketには、それがCにおけるどのアカウントに対応するかを示す情報^*3が含まれているものとする。
(R4) Cは、mIDおよびticketを、Sに返す^*4。
(R5) Sは、mIDとuIDを自身のデータベースに紐付けし、ticketをUに渡す。

3.2 登録手続き(その2)

前節においてCが発行したticketを用いて、UがCに登録する手続きである。
(R6) Uは、OTP発行依頼パスワードreqPwを定め、U_Mを用いて、ticketと共にreqPwをCに送る。
(R7) Cは、送られてきたticketに該当するアカウントを探し、当該アカウントに対するverTicket を用いてticket の正しさを検証する。
(R8) 前項が正しい場合は、一意的なアプリケーションID aID、reqPwを検証するのに必要な情報verReqPw、リクエスト依頼パスpass、および、passを検証するのに必要な情報verPassを生成し、verReqPwおよびverPassを当該アカウントに登録する。なお、passには、aIDなど、Cに登録されているどのアカウントに対するものかを示す情報が含まれているものとする。
(R9) Cは、当該アカウントにaIDおよびverPassを登録し、passをU_Mに返す^*5。
(R10) U_Mは、それ自身の機器固有情報を鍵としてpassを暗号化し保存する。なお、暗号化の鍵にreqPwを含めてもよい。

以上の手続きにより、前述の(C1)〜(C3)の状態を作り出すことができる。実際、U⇔S間でuID、SとC間でmID、CとU(U_M)間でaIDが共有されており、passは、Uが登録手続きに使用した携帯電話機器以外では正しく復号されない。

3.3 OTP発行手続き

ユーザは以下の手続きにより、CにOTPを発行してもらう。
(O1) Uは、reqPwをU_Mに入力する。
(O2) U_Mは、自身の機器固有情報を用いてpassを入手し、reqPwと共にCに送る。
(O3) Cは、passから対応するアカウントを割り出し、当該アカウントのverReqPwおよびverPassを用いて、reqPwおよびpassの正しさを検証する。
(O4) 前項が正しい場合、Cはワンタイムパスワードotpを生成し、当該アカウントに登録されているサービスシステムID(sysID)に、mIDおよびotpを送る。ここで、sysIDに対するサービスシステムをSとする。
(O5) Sは、mIDに対応するユーザアカウントに対してotp、および、その有効期限等(info)を設定し、infoをCに返す^*6。
(O6) Cは、otpおよびinfoをU_Mに送り、Uはotpとそれに関する情報を知ることができる。

以上の手続きによりotpを入手したUは、uIDおよびotp(&fPw)を用いてSにログインすることができる。

4. 機器認証における機器更新手法

本システムではOTPの発行依頼には、ユーザ所有の携帯電話機器を用いる。ユーザの携帯電話なので、機種変更、場合によっては紛失/盗難/故障/破損などにより、機器を変更せざるを得ない場合がある。しかし、passは携帯電話機器固有の情報を用いて暗号化されるため、たとえU_M内の情報を新機器に移すことができたとしても、異なる機器で処理されるので、正しいpassが得られなくなる。

4.1 基本的なアイデア

我々の研究グループは、[7]において機種変更方法を述べたが、その方法は全く新規登録するものではないにしろ、プロトコルにSが含まれるため、ユーザが利用しているサービスシステムの個数分だけ手続きを行う必要があり、ユーザにとって多少面倒なものになっている。

そこで、U_M内の情報(passを含むテーブル、pListとする)を機器外に保存し、新しい機器にその情報を取り込むことを考える。安全性および完全性を満たすためには、最低限、以下の条件が必要であると考えられる。
(1) pListは、何かしらの鍵Kで暗号化された状態で(つまり、EncK(pList)として) エクスポートされなければならない。
(2) 前項で用いる鍵Kは、機器自体ではなく、所有者に紐付いた情報(uInfo)で生成する必要がある。つまり、機器が変更されても、同一ユーザの所有物であるならば、同一のuInfoが割り当てられなければならない。
(3) 前項のuInfo は、悪意のあるユーザによるなりすましが困難でなければならない。
これらを満たす処理により、ユーザが適切にバックアップを取っていれば、機器が変更されても、SやCの助けがなくとも、使用し続けることができる。しかし、バックアップを取ることはユーザの負担ともなるため、次節において、保管システムを用いた自動バックアップのための手続きを述べる。バックアップが行われるタイミングは、ユーザの指示があったときの他、登録/削除などによりpListが変更されたときが考えられる。

4.2 保管システム（サーバの一例）を用いた保管方法

ここでは保管システムを用いた保管(バックアップ)プロトコルについて述べる。Uが所有する携帯電話機器U_Mには、Uに紐付いた情報(uInfo)が組み込まれており、Uが機器をU’_M に変更した場合でも、同じuInfoが組み込まれるものとする。以下に述べるプロトコルにおいて、hは衝突困難な一方向性ハッシュ関数とする^*7。
(D1) U_Mは自身の機器固有情報を用いてpassを復号し、pListを入手する。
(D2) U_MはuInfoを用いて、鍵Kおよびタグt = h(uInfo)を計算する^*8。
(D3) U_Mは、dInfo(= (t, Enc_K(pList))を保管リクエストとしてDへ送り、DはdInfoを保管する。
また、Uが機器を変更したとき、バックアップから以前のpListを新しい携帯電話機器U’_Mに復元するために、以下の引き出し手続きを行う。
(W1) U’_MはuInfo(および、ある場合はdPw)を用いて、鍵Kおよびタグtを計算し、引き出しリクエストとしてtをDに送る。
(W2) DはタグtをもつエントリdInfo= (t、 E)が存在するならば、dInfoをU’_Mに返す。
(W3) U’_MはKを用いてpList(= Dec_K(E))を計算し、自身の機器固有情報を用いてpList の一部または全部を適切に暗号化して保存する。

しかし、この引き出し手続きにより、同一ユーザであればクローン携帯電話機器を無制限に作成することができてしまう。それを防ぐためには、passに生成回数Tを記載し、TがC内の当該アカウントに登録されるようにし、引き出し手続きが行われる度に、pListに含まれる各passを再発行するようにすればよい。そうすることにより、引き出し手続きが行われるとTがカウントアップされ、たとえ旧機器にpassが残っていたとしても、それは無効化されることになる。

5. 考察

本章では、まず、第4章で述べた機種変更手法が、他のワンタイムパスワード認証システムでも適用できるか考え、その後、第4章に登場するuInfoの設定方法例について述べる。

5.1 他手法との比較

比較対象は、OTP取得のために「機器」を用いる方式なので、ハードトークン方式およびソフトトークン方式とする^*9。

ハードトークンは一般に通信機能を持たない。また、サービスシステムにおいて適切に設定され、各ユーザに個別配付されるものであるため、紛失等により機器を変更しなければならない場合は、例えば[6]のように、サービスシステムに相応の認証を経た安全な方法で処理してもらう必要がある。

ソフトトークン方式の場合、一般に普及しているシステムにおいては、OTPを得る機器はユーザの所有物であることが多い。その機器上で動作する専用アプリはサービスシステムが配布するものであり、ユーザはそれを自身用に設定するのである。機器におけるアプリ領域内にユーザ固有の情報が保存されるので、これを前章におけるpListのように扱い機器変更することが可能である。とはいえ、実際のソフトトークン方式においては、[5]のように再登録するものが多い。つまり、ユーザが利用するサービスシステム数が多くなると、機種変更はそのシステム数に応じた作業量を発生させる。

本システムの場合、ユーザが利用する各サービスシステムが同一の発行センタに接続されているのであれば、機種変更に伴うユーザの作業量はサービスシステム数に依存しない。また、同一の発行センタでない場合も、[2]の方法等により、単一の発行センタの場合と同じ作業量で機種変更が可能となる。

5.2 uInfoの設定方法

uInfo は、第4.1節の(2)および(3)を満たす情報にする必要がある。携帯電話機器の場合には、その候補として電話番号などが考えられる。携帯電話機器上で動作するアプリが、その機器に割り当てられている電話番号を直接取得できない場合は、アプリの初回起動時に電話帳から自身の番号を選択させたり、その番号にSMSを送信したりすることにより、所有者確認ができる。その他にも、初回起動時に契約者ID(具体的な例としては、GmailアドレスやApple ID)に対して認証させることも考えられる。

6. まとめ

本論文では、我々の研究グループが2011年より発表している2要素3者間OTP認証システムにおいて、保管システムを設置することにより、ユーザがOTP発行依頼に使用する携帯電話機器を容易に変更できる方法を示した。保管システムは、秘密なパラメータを用いた特別な計算をするわけではないので、必ずしもネットワーク上のクラウドシステム等である必要はなく、ユーザの携帯電話機器とローカル接続されているPCやストレージなどでもよい。また、この方法は、ソフトトークンによるOTP認証システムにも適用可能であると考えられる。

参考文献
[1] IPA：オンライン本人認証方式の実態調査報告書、 2014.
https://www.ipa.go.jp/security/fy26/reports/ninsho/
[2] 糸井、 多田：”共通1-dayパスワード認証システム”、 2015年暗号と情報セキュリティシンポジウム(SCIS2015)、 2C1-1、 2015.
[3] 垣野内、 木下、 多田、 糸井、 山岸：”発行センタを介したワンタイムパスワード認証システムの実装”、 コンピュータセキュリティシンポジウム(CSS)2011、 3C4-2、 2011.
[4] 垣野内、 木下、 多田、 糸井、 山岸：”プライバシーを考慮したワンタイムパスワード認証システムの実装”、 2012年暗号と情報セキュリティシンポジウム(SCIS2012)、 1E2-5、 2012.
[5] 京都銀行：「ワンタイムパスワード」サービス.
http://www.kyotobank.co.jp/directb/onetimepass.html
[6] 三菱東京UFJ銀行：ワンタイムパスワード.
http://direct.bk.mufg.jp/secure/otp/info.html
[7] 佐々木、 多田：”発行センタを介したワンタイムパスワード認証システムの安全性に関する考察”、 2014年暗号と情報セキュリティシンポジウム(SCIS2014)、 3B1-4、 2014.

脚注
1. ここでは、ユーザが2つの機器を用いるように記述しているが、U_PはU_Mと同一の機器でも差し支えない。
2. verTicketはticketをどのように定めるかによって決まる。例えば、ticketがCによるMACであれば、verTicketはそのMACを検証するのに必要なメッセージおよび秘密鍵となり、公開鍵に基づく電子署名を用いて作成されたものであれば、verTicketはメッセージおよび署名検証鍵になる。また、ticketが単なる乱数列であれば、verTicketはその文字列を照合するのに必要となる、その文字列そのもの、または、そのハッシュ値等になる。
3. 連番や、一時的に生成された(一意的な)文字列でよい。
4. Cは、登録チケットに有効期限や独自パスワード等を定めて、それも併せてSに通知してもよいが、ここではそれらの表記は省略する。
5. 実際には、ユーザがU_Mを操作するとき、passがどのサービスシステムに対応するものかを識別できる必要があるため、passの他、当該サービスシステムの名称等も送信する必要があるが、ここでは表記の簡単のため、それらの表記を省略する。
6. infoをCに知られないようにするためには、登録手続きにおいて、U_M⇔S間で鍵を共有するなどの処理を行う必要があり、実際、そうすることにより、SはUに種々の情報を通知することができるが、本論文ではそれに関する記述は省略する。
7. ユーザがそれぞれの携帯電話機器に導入するアプリに共通である。また、それらの関数はDやC、Sを含め、外部には秘匿であることが望ましい。
8. 鍵Kおよびタグtは、uInfoのみではなく、Uが一時的に定めた保管パスワードdPwを用いて算出されてもよい。この場合、保管データの安全性は高まるが、dPwを忘れるとバックアップからpListを復元できなくなる。
9. マトリクス方式は機器を用いないので、機器変更そのものが起こりえない。なお、盤面上のパターンは記憶情報であるため、その変更は、(固定) パスワードの変更と同様の手法を取ることができると考えられる。乱数表は、サービスシステムから個別配付されるものであり、ユーザはそれに対して何の処理も行わない。したがって、乱数表を紛失した、または、その内容を他者に知られたなどの理由で、乱数表を更新する場合は、サービスシステムに相応の認証を経た安全な方法で再発行依頼する必要がある。

以上が、論文の記述である。pListは、機器内の情報の一例であり、機器内の情報は、pListに代えて又は加えて他の情報を含んでもよい。機器の一例が、スマートフォンのような携帯電話機器である。

なお、pListを使用する幾つかの例を含んだ記述は、下記である。下記は、本出願の発明者と同一の発明者による発明の国際出願（国際出願番号：PCT/JP2015/082991、本出願の基礎出願の出願時点では未公開）の記述の一部である。本出願に係る発明は、その国際出願に係る発明に適用することができる。

複数のサービスステムに共通の識別符号として、パスワードを例に取る。共通のパスワードには、後述するように、使用期限及び使用回数のうちの少なくとも１つのような制限が関連付けられる。実施例では、共通のパスワードは、パスワードが発行された当日間だけ無制限に使用可能なワンタイムパスワードを例に取る（実施例において、「ワンタイム」とは、使用期間が一時的及び使用回数が１回限りのうちの少なくとも前者を意味する）。以下、そのようなパスワードを、「共通1-dayパスワード」と呼ぶことがある。なお、後述するように、一部の実施例では、パスワードは、tpw（共通1-dayパスワード）でなくてもよい。例えば、一部の実施例では、パスワードは、tpwとは異なるタイプの一時的パスワード（例えばワンタイムパスワード）でもよいし、１つのサービスシステムでのみ使用可能な一般的な固定のパスワードでもよい。

以下の説明では、「ＡＡＡリスト」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ＡＡＡリスト」を「ＡＡＡ情報」と呼ぶことができる。また、リスト（テーブル又はテーブルを含んだデータベース）の構成は一例であり、２以上のリストが１つのリストにまとめられたり、１つのリストが複数のリストに分割されたりしてもよい。

以下の説明では、「記憶部」は、メモリを含んだ１以上の記憶デバイスでよい。例えば、記憶部は、主記憶デバイス（典型的には揮発性のメモリ）及び補助記憶デバイス（典型的には不揮発性の記憶デバイス）のうちの少なくとも主記憶デバイスでよい。補助記憶デバイスは、例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive)でよい。

以下の説明では、「プロセッサ」は、典型的にはマイクロプロセッサ（例えばＣＰＵ（Central Processing Unit））でよく、処理の一部（例えば暗号化又は復号化）を行う専用ハードウェア回路（例えばＡＳＩＣ（Application Specific Integrated Circuit））を含んでもよい。

少なくとも１つの実施例では、サービスシステムとユーザ端末の２者間に、共通1-dayパスワードを発行する制御センタが介入して、３者間での認証が行われる。実施例の説明では、下記の表記ルールを採用する。なお、ユーザは、１以上存在するが、実施例ではユーザ同士の通信は必須ではないので、説明を分かり易くするために、１人のユーザを例に取る。
・tpw：共通1-dayパスワード
・C^(j)：制御センタ（jは１以上の整数（j＝１，２，３，…））（制御センタを管理する又は所有する者は、個人でも私企業でも官公庁でもよい）
・S_i：サービスシステム（iは１以上の整数（i＝１，２，３，…））（サービスシステムを管理する又は所有する者は、個人でも私企業でも官公庁でもよい）
・S_i ^(j)：C^(j)に登録されているS_i
・U：ユーザ
・U_P：第１のユーザ端末（S_i ^(j)の利用のためのユーザ端末（例えばパーソナルコンピュータ））
・U_M：第２のユーザ端末（tpwの発行リクエストのためのユーザ端末であり、例えばデバイス認証可能なユーザ端末（例えばスマートフォンのような携帯端末））
・APP：tpw発行リクエストなどC^(j)との通信のために実行されるアプリケーションプログラム
・suKey _i ^(j)：U（例えばU_M）とS_i ^(j)とに共有される鍵
・cID^(j)：C^(j)の制御センタＩＤ
・sysID_i ^(j)：S_i ^(j)のサービスシステムＩＤ
・mID_i ^(j)：S_i ^(j)の管理用ＩＤであり、C^(j)とS_i ^(j)との間で共有される情報（U毎（具体的にはアカウント毎）に異なる）
・tReqPw^(j)：tpwの発行リクエストのパスワード
・reqPw：tReqPw^(j)のシードとなる情報（ユーザが記憶する第１の情報）
・uID_i ^(j)：S_i ^(j)の利用のためのユーザＩＤ（ユーザが記憶する第２の情報）であり、UとS_i ^(j)との間で共有される情報
・aID^(j)：APPのＩＤ（但し、後述するように、関連付けを避けるために１つのC^(j)及び１つのAPPにつき異なる複数のaID^(j)が存在することもある）
・uList_i ^(j)：S_i ^(j)が記憶する管理リスト（Uに関する情報を保持するリスト）
・aList^(j)：C^(j)が記憶する第１の管理リスト（U_M等に関する情報を保持するリスト）
・sList^(j)：C^(j)が記憶する第２の管理リスト（S_i ^(j)等に関する情報を保持するリスト）
・cList^(j)：C^(j)が記憶する第３の管理リスト（C^(j)等に関する情報を保持するリスト）
・pList：U_Mが記憶する管理リスト（C^(j)及びS_i ^(j)等に関する情報を保持するリスト）
・tpwInfo_i ^(j)：tpwの使用制限を表す情報を含むことができS_i ^(j)により決定されtpwに関連付けられる情報（以下の実施例では、tpwが共通1-dayパスワードのため、使用制限として、使用期限「tpwの発行日の00:00の直前まで」及び使用回数「無制限」をいずれのtpwInfo_i ^(j)も含む）
・Ticket：C^(j)にUを登録することの電子的な許可証でありC^(j)により発行される情報
・Pass_i ^(j)：tpwを発行することの電子的な許可証でありC^(j)により発行される情報

以下の実施例では、１ユーザにつきユーザ端末は２つであるが（又はそれより多いが）、１ユーザにつきユーザ端末は１つであってもよい。後者の場合、例えばU_Mが、第２ユーザ端末と第１ユーザ端末を兼ねてよい。

また、以下の説明では、C^(j)が１つであるか複数であるかに関わらず、reqPw、APP又はpListは、１つでもよいし、C^(j)毎にreqPw、APP又はpListが存在してもよい。以下の説明では、reqPw、APP及びpListのいずれも、C^(j)の数に関わらず１つであるとする。

また、以下の説明では、APP等のプログラムを主語として処理を説明する場合があるが、プログラムがプロセッサ（例えばＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理が、適宜に記憶部（例えばメモリ）及び／又はインターフェース部（例えば通信ポート）等を用いながら行われるため、処理の主語は、プロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置又はシステムが行う処理としてもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサ（例えばＣＰＵ）と記憶部を含み、記憶部はさらに配布プログラムと配布対象であるプログラムとを記憶してよい。そして、プログラム配布サーバのプロセッサが配布プログラムを実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布してよい。
［実施例１］

以下、実施例１を説明する。実施例１では、制御センタが１つ（C⁽¹⁾のみ）である。

図１は、実施例１に係る認証プロセスの概略を示す。

サービスシステム１０３（図１ではS₁ ⁽¹⁾のみ図示）とユーザ端末１０５（第１のユーザ端末１０５Ａ（U_P）、第２のユーザ端末１０５Ｂ（U_M））の２者間に、tpwを発行する制御センタ１０１（C⁽¹⁾）が介入して、３者間での認証が行われる。

ユーザ（U）は、自分が所有しているU_Mで実行されるAPPが表示する画面にreqPw（例えば値“xxxx”）を入力し、U_M（APP）が、入力されたreqPwを基にtReqPw⁽¹⁾を生成し、tpw発行リクエストをC⁽¹⁾に送信する（ステップ５０）。tpw発行リクエストには、生成されたtReqPw⁽¹⁾と、事前登録においてC⁽¹⁾により発行されU_Mに格納されたPass₁ ⁽¹⁾とが関連付いている（含まれている）。

C⁽¹⁾は、tpw発行リクエストを受信し、そのtpw発行リクエストに関連付いているtReqPw⁽¹⁾が、事前に登録されたtReqPw⁽¹⁾と適合するか否かと、tpw発行リクエストに関連付いているPass₁ ⁽¹⁾が正しいか否かとを判断する（ステップ５１）。いずれの判断の結果も肯定の場合、C⁽¹⁾は、tpw（例えば値“1234”）を決定し、U（U_M）とS₁ ⁽¹⁾に、決定したtpwを発行する（ステップ５３及び５４）。その際、C⁽¹⁾は、S₁ ⁽¹⁾に、S₁ ⁽¹⁾とC⁽¹⁾間の共通のmID₁ ⁽¹⁾と、決定したtpwとを含んだ情報セットを送信する（ステップ５３）。

U_M（APP）が、tpwをC⁽¹⁾から受信し、受信したtpw（例えば値“1234”）を出力（例えば表示）する（ステップ５５）。tpwの出力は、表示に代えて又は加えて、音声出力等の他種の出力でもよい。

U（U_P）は、S₁ ⁽¹⁾に対して、U_Mが受信した情報セット内のtpwと同じtpwと、Uが記憶しているuID₁ ⁽¹⁾（例えば値“yyyy”）とを、入力する（ステップ５６）。

S₁ ⁽¹⁾は、C⁽¹⁾から受信したmID₁ ⁽¹⁾に対応するUを特定する。そして、S₁ ⁽¹⁾は、入力されたuID₁ ⁽¹⁾が、事前に登録されたuID₁ ⁽¹⁾に適合し、且つ、入力されたtpwが、C⁽¹⁾から受けたtpwに適合するか否かを判断する（ステップ５７）。その判断結果が肯定の場合、S₁ ⁽¹⁾は、Uに対してサービス提供を行う。

Uを特定する為に下記の３つのパラメータ（キー）がある。
・C⁽¹⁾とUとの間で共有されるtReqPw⁽¹⁾
・S₁ ⁽¹⁾とUとの間で共有されるuID₁ ⁽¹⁾
・C⁽¹⁾とS₁ ⁽¹⁾との間で共有されるmID₁ ⁽¹⁾

上記３つのＩＤは、それぞれ２者間でしか知りえない。すなわち、
・tReqPw⁽¹⁾を、S₁ ⁽¹⁾は知らない。
・uID₁ ⁽¹⁾を、C⁽¹⁾は知らない。
・mID₁ ⁽¹⁾を、Uは知らない。

このように、意図的に三すくみを作ることにより、どこから情報漏えいが生じても、同時に２箇所から漏えいしなければ、なりすまし犯罪が成立しないようになっている。

tpwを取得するために、U本人が所有するU_Mを使用するため、専用ハードが不要である。また、後述するように、U_Mの個体識別番号を送信することなく、U_MであることをC⁽¹⁾が確認できる。本実施例では、記憶情報の認証（Uが記憶しているreqPwに基づき生成されたtReqPw⁽¹⁾の認証であるユーザ認証）と所有物の認証（登録において使用されたU_Mに格納されているPass₁ ⁽¹⁾の認証であるデバイス認証）の２要素認証が可能となる。

以下、U_M、U_P、S_i ^(j)（S₁ ⁽¹⁾）、C^(j)（C⁽¹⁾）、uList _i ^(j)（uList₁ ⁽¹⁾）、aList^(j)（aList⁽¹⁾）、pList、sList^(j)（sList⁽¹⁾）及びcList^(j)（cList⁽¹⁾）の構成例を説明する。

図２は、U_Mの構成例を示す。

U_Mは、モバイル端末であり、例えば、スマートフォンである。スマートフォンは、スマートデバイスの一種である。スマートデバイスは、単なる計算処理だけではなく、多種多様な用途に使用可能な多機能のデバイスであり、典型的には、スマートフォン、又は、タブレットＰＣである。U_Mは、タッチパネル型ディスプレイ２１１と、記憶部２１３と、Ｉ／Ｆ（通信インターフェイスデバイス）２１４と、それらに接続されたプロセッサ２１２とを有する。タッチパネル型ディスプレイ２１１は、入力デバイスと表示デバイスの一例であり、入力デバイスと表示デバイスが一体になったデバイスである。記憶部２１３は、APP等のプログラムとpList等の情報とを記憶する。プロセッサ２１２は、APPを実行する。APPは、pListを参照又は更新したり、Ｉ／Ｆ２１４を介してC^(j)（C⁽¹⁾）等の外部装置と通信したりする。APPは、pListの少なくとも一部をタッチパネル型ディスプレイ２１１に表示してもよいし、受信したtpwを、無線等でU_Pに送信（入力）してもよい。

図３は、U_Pの構成例を示す。

U_Pは、記憶部３１１と、Ｉ／Ｆ３１３と、入力デバイス３１５と、表示デバイス３１４と、それらに接続されたプロセッサ３１２とを有する。入力デバイス３１５は、ユーザが情報を入力するために使用するデバイスであり、例えば、キーボード及びポインティングデバイスである。表示デバイス３１４は、情報を表示するデバイスであり、例えば液晶表示デバイスである。記憶部３１１は、Ｗｅｂブラウザ等のプログラムと、情報とを記憶する。プロセッサ３１４は、Ｗｅｂブラウザ等のプログラムを実行することで、Ｉ／Ｆ３１３を介してS_i ^(j)（S₁ ⁽¹⁾）等の外部装置と通信する。

図４は、S_i ^(j)（S₁ ⁽¹⁾）の構成例を示す。

S_i ^(j)（S₁ ⁽¹⁾）は、ユーザ端末（例えばU_P）にサービスを提供するコンピュータシステムであり、典型的には、サービス企業のコンピュータシステムである。S_i ^(j)（S₁ ⁽¹⁾）は、１以上の計算機であり、記憶部４１１と、Ｉ／Ｆ４１３と、それらに接続されたプロセッサ４１２とを有する。記憶部４１１が、プログラムと、uList _i ^(j)（uList₁ ⁽¹⁾）等の情報とを記憶する。プロセッサ４１２が、記憶部４１１内のプログラムを実行することで、uList _i ^(j)（uList₁ ⁽¹⁾）を参照又は更新したり、Ｉ／Ｆ４１３を介してU_P等の外部装置と通信したりする。

図５は、C^(j)（C⁽¹⁾）の構成例を示す。

C^(j)（C⁽¹⁾）は、tpwを発行するコンピュータシステムである。C^(j)（C⁽¹⁾）は、１以上の計算機であり、記憶部５１１と、Ｉ／Ｆ５１３と、それらに接続されたプロセッサ５１２とを有する。記憶部５１１が、プログラムと、aList^(j)（aList⁽¹⁾）、sList^(j)（sList⁽¹⁾）及びcList^(j)（cList⁽¹⁾）等の情報とを記憶する。プロセッサ５１２が、記憶部５１１内のプログラムを実行することで、aList^(j)（aList⁽¹⁾）、sList^(j)（sList⁽¹⁾）又はcList^(j)（cList⁽¹⁾）を参照又は更新したり、Ｉ／Ｆ５１３を介してU_M又はS_i ^(j)（S₁ ⁽¹⁾）等の外部装置と通信したりする。

図６は、uList _i ^(j)（uList₁ ⁽¹⁾）の構成例を示す。なお、以下、図６〜図１０において、リストにおける情報要素の名称は、アルファベット大文字で表記する。また、以下、リストにおける１行（レコード）を、「アカウント」と呼ぶ。

uList_i ^(j)（uList₁ ⁽¹⁾）は、Uに関する情報を保持する。uList _i ^(j)の各アカウントが保持する情報要素は、例えば、UID、MID、TPW、TPWINFO、SUKEY及びOTHERSである。UIDは、登録されたuID_i ^(j)である。MIDは、登録されたmID _i ^(j)である。TPWは、登録されたtpwである。TPWINFOは、登録されたtpwInfo_i ^(j)である。SUKEYは、登録されたsuKey_i ^(j)である。OTHERSは、他の情報要素であり、例えば、Uのユーザ名等を含んでよい。

図７は、aList^(j)（aList⁽¹⁾）の構成例を示す。

aList^(j)（aList⁽¹⁾）は、U_M等に関する情報を保持する。aList^(j)の各アカウントが保持する情報要素は、例えば、SN、SYSID、MID、TREQPW、AID及びOTHERSである。SNは、登録されたシリアル番号（sn）である。SYSIDは、登録されたsysID _i ^(j)である。MIDは、登録されたmID_i ^(j)である。TREQPWは、登録されたtReqPw^(j)である。AIDは、登録されたaID^(j)である。aID^(j)は、１つのAPP及び１つのC^(j)につき１つであるが、１つのAPP及び１つのC^(j)につき異なる複数のaID^(j)が生成されてもよい。OTHERSは、他の情報要素であり、例えば、C^(j)による運用等に必要な情報を含んでよい。

図８は、pListの構成例を示す。

pList（pList）は、C^(j)及びS_i ^(j)等に関する情報を保持する。pListの各アカウントが保持する情報要素は、例えば、SYSID、CID、RAND、AID、PASS、SUKEY及びOTHERSである。SYSIDは、登録されたsysID _i ^(j)である。CIDは、登録されたcID^(j)である。RANDは、登録された乱数（以下、Randと表記）である。Randは、後述するように、tReqPw^(j)の生成（算出）に使用される。AIDは、登録されたaID^(j)である。PASSは、登録されたPass_i ^(j)である。Pass_i ^(j)は、tpw発行の電子的な許可証である。Pass_i ^(j)の詳細は後述する。SUKEYは、登録されたsuKey_i ^(j)である。OTHERSは、他の情報要素であり、例えば、C^(j)との通信等に関する情報を含んでよい。

図９は、sList^(j)（sList⁽¹⁾）の構成例を示す。

sList^(j)（sList⁽¹⁾）は、S_i ^(j)等に関する情報を保持する。sList^(j)の各アカウントが保持する情報要素は、例えば、SYSID及びOTHERSである。SYSIDは、登録されたsysID_i ^(j)である。OTHERSは、他の情報要素であり、例えば、S_i ^(j)の名称、S_i ^(j)との通信に必要な情報（例えば、ＦＱＤＮ（Fully Qualified Domain Name）及びネットワークアドレス）等を含んでよい。

図１０は、cList^(j)（cList⁽¹⁾）の構成例を示す。

cList^(j)（cList⁽¹⁾）は、他のC^(j)等に関する情報を保持する（本実施例では、C^(j)は１つなので、cList^(j)はブランクである）。cList^(j)の各アカウントが保持する情報要素は、例えば、CID及びOTHERSである。CIDは、登録されたcID^(j)である。OTHERSは、他の情報要素であり、例えば、他のcID^(j)の名称、他のcID^(j)との通信に必要な情報（例えば、ＦＱＤＮ及びネットワークアドレス）等を含んでよい。

図１１は、C⁽¹⁾によるtpw提供を示す。

C⁽¹⁾は、U（U_M）から１つのS_i ⁽¹⁾についてtpw発行リクエストを受けた場合、ユーザが契約している全てのS_i ^(j)（特定されたユーザについてaList⁽¹⁾から特定された全てのsysID _i ⁽¹⁾にそれぞれ対応したS_i ⁽¹⁾）に、tpw（例えば値“1234”）（及びmID _i ⁽¹⁾）の提供を行う。図１１の例によれば、ユーザが契約しているS_i ⁽¹⁾は、S₁ ⁽¹⁾、S₂ ⁽¹⁾及びS₃ ⁽¹⁾である。C⁽¹⁾は、S_i ⁽¹⁾からのtpw問合せ無しにtpwをS_i ⁽¹⁾に提供してもよいし、S_i ⁽¹⁾からのtpw問合せに応答してtpwをS_i ⁽¹⁾に提供してもよい。U（U_P）は、同じtpwで、tpwに関連付けられているtpwInfo_i ⁽¹⁾が示す期限まで（例えばその日１日（必ずしも２４時間であったり、当日の23:59（翌日の00:00の直前の一例）であったりする必要はない））、契約しているいずれのS_i ⁽¹⁾に対してもログインできる。tpwInfo_i ⁽¹⁾は、S_i ⁽¹⁾毎に異なっていてもよいし、複数のS_i ⁽¹⁾においてtpwInfo_i ⁽¹⁾が同一であってもよい。

以下、本実施例で行われる処理のフローを説明する。

＜事前登録＞

＜＜初回登録＞＞

図１２は、初回登録のフローの一例を示す。

初回登録とは、C⁽¹⁾に登録されていないUについてS_i ⁽¹⁾を利用するための事前登録である。初回登録は、２段階の手続きを含む。第１段階が、UとS_i ⁽¹⁾との間で行われる手続きであり、第２段階が、UとC⁽¹⁾との間で行われる手続きである。

第１段階（UとS_i ⁽¹⁾との間で行われる手続き）は下記ステップ１２０１〜ステップ１２０７である。ここでは、UがS₁ ⁽¹⁾に利用申請するものとする。

（ステップ１２０１）U（U_P）は、S₁ ⁽¹⁾に利用申請を送信する。その際、U（U_P）は、S₁ ⁽¹⁾で使用するuID₁ ⁽¹⁾を決める。

（ステップ１２０２）S₁ ⁽¹⁾は、U（U_P）から利用申請を受信し、その申請に応答して、UとのsuKey₁ ⁽¹⁾を決定し、uList₁ ⁽¹⁾にアカウントを追加する。S₁ ⁽¹⁾は、追加したアカウントに、UIDとして、決定されたuID₁ ⁽¹⁾を登録し、SUKEYとして、決定されたsuKey₁ ⁽¹⁾を登録する。

（ステップ１２０３）S₁ ⁽¹⁾は、sysID₁ ⁽¹⁾を関連付けたユーザ追加リクエストをC⁽¹⁾に送信する。

（ステップ１２０４）C⁽¹⁾は、ユーザ追加リクエストを受信し、そのリクエストに応答して、sysID₁ ⁽¹⁾と追加されるUとの両方に対応付けるmID₁ ⁽¹⁾を決定し、aList⁽¹⁾にアカウントを追加する。C⁽¹⁾は、追加したアカウントに、SNとして、決定したsn（例えばアカウントの通し番号）を登録し、SYSIDとして、ユーザ追加リスクエストに関連付いているsysID₁ ⁽¹⁾を登録し、MIDとして、決定したmID₁ ⁽¹⁾を登録する。ここで決定されたsnを、以下、「sn1」と記載することがある。

（ステップ１２０５）C⁽¹⁾は、登録チケット（以下、Ticket）を生成し、生成したTicketと、ステップ１２０４で決定したmID₁ ⁽¹⁾とを、S₁ ⁽¹⁾に送信する。Ticketは、第１の電子署名（以下、Sign1）と、cID⁽¹⁾と、登録したsn1及びsysID₁ ⁽¹⁾とに基づいている。具体的には、例えば、Ticketは、Sign1と、cID⁽¹⁾と、sn1と、sysID₁ ⁽¹⁾とを含む（Ticket = (sn1, cID⁽¹⁾, sysID₁ ⁽¹⁾, Sign1)）。Sign1は、cID⁽¹⁾と、登録したsn1及びsysID₁ ⁽¹⁾とに基づいている。なお、Ticketにおいて、snは、C⁽¹⁾がユーザを特定するために使用される情報要素（例えば通し番号）である。cID⁽¹⁾は、どのC^(j)に登録にすればよいかをAPPが特定するために使用される情報要素である（cID^(j)がC^(j)との通信に必要な情報を含む等、何らかの方法でC^(j)との通信に必要な情報とcID^(j)とがAPPにおいて関連付けられればよい）。TicketにsysID₁ ⁽¹⁾は無くてもよい。例えば、Sign1は、cID⁽¹⁾と、sn1と、sysID₁ ⁽¹⁾とを含む（Sign1 = sign(sn1, cID⁽¹⁾, sysID ₁ ⁽¹⁾, aux)）。TicketにsysID₁ ⁽¹⁾が含まれていなければ、Sign1にsysID₁ ⁽¹⁾が含まれていなくてもよい。Sign1は、C⁽¹⁾がその正しさを検証できさえすればよい。なお、aux（補助的な情報）は、uList₁ ⁽¹⁾内の何らかの情報要素（例えばOTHERSの少なくとも一部）を含んでよい。Sign1にauxは無くてもよい。

（ステップ１２０６）S₁ ⁽¹⁾は、TicketとmID₁ ⁽¹⁾とをC⁽¹⁾から受信する。S₁ ⁽¹⁾は、ステップ１２０２で登録されたuID₁ ⁽¹⁾と、受信したmID₁ ⁽¹⁾とを関連付ける。具体的には、S₁ ⁽¹⁾は、受信したmID₁ ⁽¹⁾を、ステップ１２０２で登録されたuID₁ ⁽¹⁾があるアカウントにMIDとして登録する。

（ステップ１２０７）S₁ ⁽¹⁾は、受信したTicketと、ステップ１２０２で登録したsuKey₁ ⁽¹⁾とを、U（U_P）に送信する。

第２段階（UとC⁽¹⁾との間で行われる手続き）は下記ステップ１２０８〜ステップ１２１１である。

（ステップ１２０８）Uが、reqPwを決定し、決定したreqPwと、U_Pで受信したTicket及びsuKey₁ ⁽¹⁾とを、U_Mに入力する。U_MのAPPが、その入力に応答して、乱数（Rand）を決定し、tReqPw⁽¹⁾を生成する。tReqPw⁽¹⁾は、決定されたRandと、入力されたreqPwとに基づいている（ここで決定されたRandを、以下、「Rand1」と記載することがある。）。具体的には、例えば、tReqPw⁽¹⁾は、衝突困難一方向性関数（ハッシュ関数）及びRand1を用いて不可逆変換されたreqPwである（tReqPw^(j) = h_j (Rand1, reqPw））。tReqPw^(j) は、パスワードの役割を果たすが、衝突困難一方向性関数等によりreqPwが解読不能に暗号化されたものなので、reqPwの秘密性を維持できる。tReqPw生成のための関数hが、h_jの表記の通り、制御センタ毎に異なっていてよい。これにより、Uは、１つのreqPwを覚えるだけで、制御センタ毎に異なるtReqPwを登録できる。U_M（APP）は、Ticket及びtReqPw⁽¹⁾を、Ticket内のcID⁽¹⁾から特定されたC⁽¹⁾に、送信する。なお、秘密性が落ちるが、U_Mが、(Rand及びreqPwをC⁽¹⁾に送信し、C⁽¹⁾が、U_MからのRand1及びreqPwを用いて、tReqPw⁽¹⁾を生成してもよい。また、Randは無くてもよいが、Randがあることで、C⁽¹⁾のaList⁽¹⁾において同一UについてtReqPw⁽¹⁾が同じ値になってしまうことを避けることができる。

（ステップ１２０９）C⁽¹⁾は、Ticket及びtReqPw⁽¹⁾をU_M（APP）から受信する。C⁽¹⁾は、受信したTicket内のSign1が正しいか否かを判断することで、Ticketが正しいか否かを判断する。その判断結果が肯定の場合、C⁽¹⁾は、Ticket内のsnに適合するSNを含んだアカウントをaList⁽¹⁾から特定する。C⁽¹⁾は、Ticketの送信元のAPP（U_M）についてのaID⁽¹⁾を生成し、特定したアカウントに、AIDとして、生成したaID⁽¹⁾を登録し、TREQPWとして、受信したtReqPw⁽¹⁾を登録する。tReqPw^(j)は、パスワードの役割を果たすが、衝突困難一方向性関数等によりreqPwが解読不能に暗号化されたものなので、aList⁽¹⁾からtReqPw^(j)が漏洩したとしても、reqPwの秘密性を維持できる。

（ステップ１２１０）C⁽¹⁾は、Pass₁ ⁽¹⁾を生成し、生成したPass₁ ⁽¹⁾をU_M（APP）に送信する。Pass₁ ⁽¹⁾は、aList⁽¹⁾に既に登録されているsn1、cID⁽¹⁾及びsysID₁ ⁽¹⁾と、ステップ１２０９で登録したaID⁽¹⁾と、第２の電子署名（以下、Sign2）とに基づいている。具体的には、例えば、Pass₁ ⁽¹⁾は、sn1と、cID⁽¹⁾と、sysID ₁ ⁽¹⁾と、aID⁽¹⁾と、Sign2とを含む（Pass₁ ⁽¹⁾ = (sn1, cID⁽¹⁾, sysID ₁ ⁽¹⁾, aID⁽¹⁾, Sign2)）。Pass₁ ⁽¹⁾内のaID⁽¹⁾は、後にU_Mからtpw依頼リクエストを受信した場合にtpwの発行先となる全ての（又は一部の）S_i ⁽¹⁾を特定するために使用される情報要素である（aList⁽¹⁾において同一のaID⁽¹⁾に複数のsysID_i ⁽¹⁾が関連付けられている）。Sign2は、sn1、cID⁽¹⁾及びsysID ₁ ⁽¹⁾と、ステップ１２０９で登録したaID⁽¹⁾とに基づいている。具体的には、例えば、Sign2は、sn1と、cID⁽¹⁾と、sysID ₁ ⁽¹⁾と、aID⁽¹⁾とを含む（Sign2 = sign(sn1, cID⁽¹⁾, sysID ₁ ⁽¹⁾, aID⁽¹⁾, aux)）。

（ステップ１２１１）U_M（APP）は、Pass₁ ⁽¹⁾をC⁽¹⁾から受信し、pListにアカウントを追加する。U_M（APP）は、追加したアカウントに、SYSIDとして、Pass₁ ⁽¹⁾（又はTicket）内のsysID₁ ⁽¹⁾を登録し、CIDとして、Pass₁ ⁽¹⁾（又はTicket）内のcID⁽¹⁾を登録し、RANDとして、ステップ１２０８で決定したRand1を登録し、AIDとして、Pass₁ ⁽¹⁾内のaID₁ ⁽¹⁾を登録しPASSとして、受信したPass₁ ⁽¹⁾を登録し、SUKEYとして、ステップ１２０８で入力されたsuKey₁ ⁽¹⁾を登録する。なお、pListのアカウントに登録される情報要素のうち、例えばcID⁽¹⁾及びsysID₁ ⁽¹⁾以外の情報要素は、U_Mが記憶している情報（例えば、個体識別情報及び将来的にはマイナンバー（及びそれに付随する情報）のうちの少なくとも１つ）とUが記憶している情報（例えばreqPw）とのうちの少なくとも１つを暗号鍵として暗号化されてよい（cID⁽¹⁾及びsysID₁ ⁽¹⁾はオープンな情報要素のため暗号化されないでよい）。

＜＜２回目以降の登録＞＞

図１３は、２回目以降登録のフローの一例を示す。

既にC⁽¹⁾に登録されているUが、別のサービスシステム（例えばS₂ ⁽¹⁾）を利用するときは、初回登録時に入手されたaID⁽¹⁾を使用できる。具体的には、第１段階は、初回登録の第１段階と同じである（ステップ１３０１〜ステップ１３０７は、ステップ１２０１〜ステップ１２０７とそれぞれ同じである）。第２段階（UとC⁽¹⁾との間で行われる手続き）は下記である。主に、初回登録の第２段階との相違点を記載し、初回登録の第２段階との共通点については説明を省略又は簡略する。

（ステップ１３０８）Uが、Uが初回登録で使用したreqPw（Uが記憶している情報）と、U_Pで受信したTicket及びsuKey₂ ⁽¹⁾とを、U_Mに入力する。U_M（APP）が、pListをタッチパネル型ディスプレイ２１１に表示し、Uから、利用するアカウントの選択を受ける。U_M（APP）は、Uにより選択されたアカウントからRand1、cID⁽¹⁾、sysID ₁ ⁽¹⁾、aID⁽¹⁾及びPass₁ ⁽¹⁾を取得する。U_M（APP）は、入力されたTicket内のcID⁽¹⁾が、選択されたアカウントから取得されたcID⁽¹⁾と同じか否かを判断する。この判断結果が否定の場合、U_M（APP）は、登録失敗として停止してよい。一方、この判断結果が肯定の場合、U_M（APP）は、tReqPw⁽¹⁾（＝h₁ (取得されたRand1, 入力されたreqPw）を生成し、生成したtReqPw⁽¹⁾と、アカウントから取得されたPass₁ ⁽¹⁾と、入力されたTicketとを、C⁽¹⁾に送信する。

（ステップ１３０９）C⁽¹⁾は、Ticket、Pass₁ ⁽¹⁾及びtReqPw⁽¹⁾をU_M（APP）から受信する。C⁽¹⁾は、受信したTicket内のSign1を検証することで、Ticketが正しいか否かを判断する。その判断結果が肯定の場合、C⁽¹⁾は、Ticket内のsn（以下、sn2）に適合するSNを含んだアカウントをaList⁽¹⁾から特定し、また、受信したPass₁ ⁽¹⁾からaID⁽¹⁾を取得する。C⁽¹⁾は、特定したアカウントに、SNとして、Ticket内のsn2を登録し、AIDとして、取得したaID⁽¹⁾を登録し、TREQPWとして、受信したtReqPw⁽¹⁾を登録する。

（ステップ１３１０）C⁽¹⁾は、Pass₂ ⁽¹⁾（= (sn2, cID⁽¹⁾, sysID ₂ ⁽¹⁾, aID⁽¹⁾, Sign2)）を生成し、生成した生成したPass₂ ⁽¹⁾をU_M（APP）に送信する。Pass₂ ⁽¹⁾内のSign2は、Sign2 = sign(sn2, cID⁽¹⁾, sysID ₂ ⁽¹⁾, aID⁽¹⁾, aux)である。

（ステップ１３１１）U_M（APP）は、Pass₂ ⁽¹⁾をC⁽¹⁾から受信し、pListにアカウントを追加する。U_M（APP）は、追加したアカウントに、SYSIDとして、Pass₂ ⁽¹⁾（又はTicket）内のsysID₂ ⁽¹⁾を登録し、CIDとして、Pass₂ ⁽¹⁾（又はTicket）内のcID⁽¹⁾（又は、ステップ１３０８で取得したcID⁽¹⁾）を登録し、RANDとして、ステップ１３０８で取得したRand1を登録し、PASSとして、受信したPass₂ ⁽¹⁾を登録し、SUKEYとして、ステップ１３０８で入力されたsuKey₂ ⁽¹⁾を登録する。

以上のように、事前登録では、初回登録と２回目以降の登録とがある。初回登録であるか２回目以降の登録であるかは、UがU_M（APP）に明示してよい。例えば、APPが、初回登録と２回目以降登録のいずれであるかの選択をUから受け付ける画面（例えば、初回登録ボタンと２回目以降登録ボタンとを有するＧＵＩ（Graphical User Interface）を表示し、いずれのボタンが押されたかによって、初回登録と２回目以降登録のいずれの処理を実行するかを決定してよい。また、Uは、C⁽¹⁾に対して初回登録が済んだ後にいずれかのS_i ⁽¹⁾を初めて利用する場合に、初回登録を選択してもよい。この場合、同一のUについて異なる複数のaID⁽¹⁾がC⁽¹⁾に登録されることになる。初回登録とするか２回目以降の登録とするかは、異なる複数のS_i ⁽¹⁾に同一のaID⁽¹⁾を関連付けるか否かである。関連付けがされていれば、U_Mを紛失した又はreqPwを忘れた等の場合に、復旧が比較的容易である。なぜなら、Uは、いずれかのS_i ⁽¹⁾にその旨を伝えれば、S_i ⁽¹⁾が、そのUに対応したmID_i ⁽¹⁾をC⁽¹⁾に送信し、C^(j)が、そのmID_i ⁽¹⁾に対応したaID⁽¹⁾を特定し、特定したaID⁽¹⁾に関連付いている全てのsysID _i ⁽¹⁾をaList⁽¹⁾から特定できるためである。また、Uにとっても、pListにおいて同一のaID⁽¹⁾に複数の異なる複数のsysID _i ⁽¹⁾が関連付いているので、UにとってのS_i ⁽¹⁾のグループを特定できる。一方、関連付けがされていなければ、Uがどの複数のS_i ⁽¹⁾を利用しているかをC⁽¹⁾によりaList⁽¹⁾から特定されることを避けることができる。実施例１では、関連付けをするか否かをUが選択できる。

＜tpw（共通1-dayパスワード）の発行＞

以下、Uが利用登録しているsysID_i ⁽¹⁾の全て（または一部）で利用できるtpwの発行のフローを説明する。

図１４は、実施例１に係るtpw発行フローの一例を示す。なお、以下の説明では、複数のSYSID（ここでは、pListに登録されている全てのSYSID）のグループを、「SYSIDGroup」と表記する。また、SYSIDGroupのうちの少なくとも１つのSYSIDを、「SYSIDPart」と表記する。従って、SYSIDPartは、SYSIDPart⊂SYSIDGroupである（「SYSIDPart⊂SYSIDGroup」は、SYSIDPart＝SYSIDGroupであることも含む）。そして、SYSIDPart⊂SYSIDGroupについてのPass_SYSIDPartを、{Pass_i ⁽¹⁾}_Kとする。Kは、sysID_i ⁽¹⁾∈SYSIDPartである。つまり、Pass_SYSIDPartの意味は、SYSIDPartを構成するsysID_i ⁽¹⁾にそれぞれ対応したPass_i ⁽¹⁾の集合である。UがSYSIDPart⊂SYSIDGroupの全てに使用できるtpwの発行のフローは、以下の通りである。

（ステップ１４０１）U_M（APP）が、例えばpListの少なくとも一部の情報を表示し、pListのSYSIDGroupのうちのSYSIDPartの選択と、reqPwの入力とを、Uから受ける。U_M（APP）は、Pass_SYSIDPartから１つのPass_i ⁽¹⁾を選択する。また、U_M（APP）は、選択したPass_i ⁽¹⁾が登録されているアカウントからRandを取得し、取得したRandと入力されたreqPwとを用いてtReqPw⁽¹⁾を生成する。U_M（APP）は、Uにより選択されたSYSIDPartと、生成されたtReqPw⁽¹⁾と、選択したPass_i ⁽¹⁾とを関連付けたtpw発行リクエストを、選択されたPass_i ⁽¹⁾に対応したcID⁽¹⁾から特定されたC⁽¹⁾に送信する。なお、SYSIDPartの選択は、Uに代えて、U_M（APP）により行われてもよい。

（ステップ１４０２）C⁽¹⁾は、tpw発行リクエストをU_M（APP）から受信し、そのリクエストに応答して、そのリクエストに関連付いているtReqPw⁽¹⁾が正しいか否かの第１の判断と、そのリクエストに関連付いているPass_i ⁽¹⁾が正しいか否かの第２の判断とを行う。第１の判断は、例えば、そのPass_i ⁽¹⁾内のsnと一致するsnを保持したアカウント（aList⁽¹⁾内のアカウント）内のTREQPWと、リクエストに関連付いているtReqPw⁽¹⁾とが一致するか否かの判断である。第２の判断は、Pass_i ⁽¹⁾内のsnと一致するsnを保持したアカウント（aList⁽¹⁾内のアカウント）内の情報要素（CID、SYSID、AID）と、Pass_i ⁽¹⁾内の情報要素（cID⁽¹⁾, sysID ₁ ⁽¹⁾, aID⁽¹⁾）とを用いて、Pass_i ⁽¹⁾内のSign2が正しいか否かを判断することにより行われる。第１の判断の結果及び第２の判断の結果のうちの少なくとも１つが否定の場合、C⁽¹⁾は処理を中止してよい。第１の判断の結果及び第２の判断の結果のいずれも肯定の場合、C⁽¹⁾はステップ１４０３を行う。

（ステップ１４０３）C⁽¹⁾は、aList⁽¹⁾を参照し、正しいと判断されたPass_i ⁽¹⁾内のaID⁽¹⁾と一致するAIDを有し、且つ、tpw発行リクエストに関連付いているSYSIDPart内のいずれかのsysID_i ⁽¹⁾と一致するSYSIDを有するアカウントを全て特定する。C⁽¹⁾は、特定された全てのアカウントからそれぞれMID（mID _i ⁽¹⁾）を取得する。ここで取得されたmID _i ⁽¹⁾の集合を、「MIDGroup」と表記する。MIDGroupは、{mID _i ⁽¹⁾}_Lである。Lは、sysID _i ^(j)∈SYSIDPart, AID=aID⁽¹⁾である。

（ステップ１４０４）C⁽¹⁾は、tpwを決定する。tpwは、例えばランダムな値でよい。C⁽¹⁾は、各sysID _i ⁽¹⁾（∈SYSIDPart）について、以下を行う。ステップ１４０４〜ステップ１４０７の説明において、１つのsysID _i ⁽¹⁾を例に取る。C⁽¹⁾は、sysID _i ⁽¹⁾にに対応したS_i ⁽¹⁾に、そのS_i ⁽¹⁾に対応するmID_i ⁽¹⁾と、決定されたtpwとを送信する（mID_i ⁽¹⁾とtpwとを関連付けたtpw登録リクエストをS_i ⁽¹⁾に送信する）。ここでは、C⁽¹⁾は、tpwを、S_i ⁽¹⁾からの問合せ無しに送信するが、上述したように、S_i ⁽¹⁾からの問合せに応答してtpwを送信するようにしてもよい。

（ステップ１４０５）S_i ⁽¹⁾が、そのS_i ⁽¹⁾に対応するmID _i ⁽¹⁾と、決定されたtpwとをC⁽¹⁾から受信する。S_i ⁽¹⁾は、受信したmID_i ⁽¹⁾と一致するMIDが登録されているアカウントをuList _i ⁽¹⁾から特定する。S_i ⁽¹⁾は、特定したアカウントに、TPWとして、受信したtpwを登録する。また、S_i ⁽¹⁾は、そのtpwについてtpwInfo_i ⁽¹⁾を決定し、そのアカウントに、TPWINFOとして、決定したtpwInfo_i ⁽¹⁾を登録する。tpwInfo_i ⁽¹⁾は、そのtpwの使用期限及び使用可能回数等のtpw制限を表す情報を含んでよい。本実施例では、上述したように、tpwは、共通1-dayパスワードを意味するため、使用制限として、使用期限「tpwの発行日の00:00の直前まで」及び使用回数「無制限」を、tpwInfo_i ^(j)が含む。

（ステップ１４０６）S_i ⁽¹⁾は、ステップ１４０５で特定したアカウントからSUKEY（suKey_i ⁽¹⁾）を取得する。S_i ⁽¹⁾は、登録したtpwInfo_i ⁽¹⁾を含んだ情報mes_i ^(j)（mes_i ⁽¹⁾）を、取得したsuKey_i ⁽¹⁾で暗号化する。結果として、eMes_i ⁽¹⁾（mes_i ⁽¹⁾の暗号化情報）、すなわち、Enc_SUKEY(mes_i ⁽¹⁾)が得られる（SUKEY=suKey_i ⁽¹⁾）。S_i ⁽¹⁾は、得られたeMes_i ⁽¹⁾を、C⁽¹⁾に送信する。なお、mes_i ^(j)は、tpwInfo_i ⁽¹⁾に加えて、そのS_i ⁽¹⁾に関する情報を含んでよい。そのS_i ⁽¹⁾に関する情報は、UのuID_i ⁽¹⁾（ステップ１４０５で特定したアカウントから取得されたUID）を含んでよい。暗号化関数（Enc）は、例えば、事前に定められた共通鍵暗号方式の暗号化関数でよい。eMes_i ⁽¹⁾は、後述するように、C⁽¹⁾を通じてU_M（APP）に届く情報である。そして、eMes_i ⁽¹⁾は、U_M（APP）により、暗号化に使用されたsuKey_i ⁽¹⁾と同一のsuKey_i ⁽¹⁾を用いて復号化される。つまり、mes_i ^(j)が得られる。U_M（APP）は、得られたmes_i ^(j)内の情報の少なくとも一部（例えばuID_i ⁽¹⁾）を、タッチパネル型ディスプレイ２１１に表示する。これにより、UがuID_i ⁽¹⁾を忘れてしまっていても、tpw発行リクエストの応答時という適切なタイミングで（uID_i ⁽¹⁾の問合せをU_M（APP）がわざわざ発行すること無しに）、uID_i ⁽¹⁾を知ることができる。

（ステップ１４０７）C⁽¹⁾は、sysID_i ⁽¹⁾（∈SysysIDPart）にそれぞれ対応した全てのS_i ⁽¹⁾から応答（eMes_i ⁽¹⁾）を受信した場合に、それらすべてのeMes_i ⁽¹⁾（= {eMes_i ⁽¹⁾}_M）と、ステップ１４０４で決定したtpwとを、U_M（APP）に送信する（M = sysID _i ⁽¹⁾∈SYSIDPart）。

（ステップ１４０８）U_M（APP）が、{eMes_i ⁽¹⁾}_Mと、tpwとをC⁽¹⁾から受信する。U_M（APP）は、{eMes_i ⁽¹⁾}_Mに含まれる各eMes_i ⁽¹⁾について、以下を行う。１つのeMes_i ⁽¹⁾を例に取る。U_M（APP）は、eMes_i ⁽¹⁾に対応するアカウントをpListから特定する。U_M（APP）は、特定したアカウントからSUKEY（suKey_i ⁽¹⁾）を取得し、取得したsuKey_i ⁽¹⁾）を用いて、eMes_i ⁽¹⁾を復号化する。それにより、mes_i ⁽¹⁾が得られる。U_M（APP）は、得られたmes_i ⁽¹⁾内の情報要素の少なくとも一部を、表示及び上記特定したアカウントに登録のうちの少なくとも一方を行う。U_M（APP）は、そのアカウントに、受信したtpwも登録してよい。U_M（APP）は、受信したtpwをタッチパネル型ディスプレイ２１１に表示してよい。

＜S_i ⁽¹⁾の利用＞

フローは、図１を参照して説明したフローと同様である。具体的には、例えば下記である。以下、１つのS_i ⁽¹⁾を例に取る（なお、S_i ⁽¹⁾の利用段階では、既に、そのS_i ⁽¹⁾のuList _i ^(j)に、Uに提供されたtpwが設定されている）。Uは、U_Pに、uID_i ⁽¹⁾とtpwとを入力する。S_i ⁽¹⁾は、U（U_P）から、サービス提供リクエストを受信する。サービス提供リクエストには、U_Pに入力されたuID_i ⁽¹⁾及びtpwが関連付いている。S_i ⁽¹⁾は、そのuID_i ⁽¹⁾及びtpwの照合を行う。具体的には、S_i ⁽¹⁾は、そのuID_i ⁽¹⁾及びtpwにそれぞれ一致するUID及びTPWが登録されているアカウントがuList _i ⁽¹⁾にあるか否かを判断する。その判断結果が肯定の場合、S_i ⁽¹⁾は、U（U_P）にサービスを提供する（例えばログインを許可する）。

複数のS_i ⁽¹⁾に、その日１日は、同じtpwを使用できる（S_i ⁽¹⁾に対するtpwの使用期限は、そのS_i ⁽¹⁾に対応しtpwに関連付けられているtpwInfo_i ⁽¹⁾に従う）。なお、tpwの使用期限（tpwに関連付けられるtpwInfo_i ⁽¹⁾が表す使用期限）は、必ずしも２４時間であったり、当日の23:59であったりする必要はない。また、tpwの制限として、使用期限に加えて、使用回数（Ｎ回（Ｎは１以上の整数のうちの任意の値））も定義されていてよい。tpwInfo_i ^(j)は、S_i ^(j)毎に異なっていてもよい。

また、U_M（APP）は、Uが利用している全て（又は一部）のS_i ⁽¹⁾でそれぞれ使用するuID_i ⁽¹⁾を表示することができる。例えば、U_M（APP）は、Uからのリクエストに応答して、ユーザID問合せをC⁽¹⁾に発行してよい。ユーザID問合せの発行から応答までのフローは、tpw発行リクエストの発行から応答までのフローと同様でよい。その応答には、S_i ⁽¹⁾からC⁽¹⁾を通じた暗号化ユーザＩＤ（suKey_i ⁽¹⁾で暗号化されたuID_i ⁽¹⁾）が含まれていてよい。また、その応答には、Uが利用している全て（又は一部）にそれぞれ対応した１以上の暗号化ユーザＩＤが含まれていてよい。U_M（APP）は、suKey_i ⁽¹⁾を用いて暗号化ユーザＩＤを復号化し、復号化されたユーザＩＤを表示してよい。

また、C⁽¹⁾が、少なくとも１つのS_i ⁽¹⁾については、S_i ⁽¹⁾からの問合せ無しにtpwを送信するのではなく、C⁽¹⁾自身が保持してもよい（例えば、そのS_i ⁽¹⁾に対応するアカウント（aList⁽¹⁾におけるアカウント）に、tpwを登録してよい）。この場合は、S_i ⁽¹⁾が、U（U_P）からサービス提供リクエストを受信した場合に、C⁽¹⁾に、そのUについてのmID _i ⁽¹⁾を関連付けたtpw問合せを送信してよい。C⁽¹⁾は、そのtpw問合せを受信した場合、そのtpw問合せに関連付いているmID _i ⁽¹⁾に対応したtpwを特定し、特定したtpwを、tpw問合せの送信元S_i ⁽¹⁾に送信してよい。

以上、実施例１によれば、例えば下記のうちの少なくとも１つの効果を奏することができる。

（１）UがID及びパスワード管理の煩わしさから解放される。
１日１回tpw（共通1-dayパスワード）を取得すれば、その日１日は、同じtpwを使用して、Uが利用する全て（又は一部）のS_i ⁽¹⁾へのログインが可能になる。このため、管理の煩わしさから解放される。また、uID_i ⁽¹⁾を忘れても、uID_i ⁽¹⁾がU_Mに表示される。この点も、管理の煩わしさの解放に貢献している。

（２）安全性が高まる。
tpwは、１日（tpwInfo_i ⁽¹⁾が表す使用期限）で使えなくなる。このため、たとえ、tpwが盗まれても、そのtpwを翌日に使うことはできない。故に、安全性が高まる。また、tpwの使用期限に加えて使用可能回数を制限することで、更に安全性を高めることが期待できる。また、事前登録で使用したU_M以外のユーザ端末からではtpwを取得できない。なぜなら、U_M以外のユーザ端末には、事前登録のときに取得された情報要素が登録されているpListが存在しないためである。この点も、安全性の向上に貢献している。また、たとえ他人にU_Mが拾われても、tpw発行のリクエストの際にはUが記憶しているreqPwが必要なので、reqPwを他人に知られなければ、他人にtpwが取得されることが無い。

（３）情報漏えいに強い。
Uは、C⁽¹⁾とS_i ⁽¹⁾との間で共有されるmID_i ⁽¹⁾を知らない。C⁽¹⁾は、S_i ⁽¹⁾とUとの間で共有されるuID_i ⁽¹⁾を知らない。S_i ⁽¹⁾は、C⁽¹⁾とU間で共有されるtReqPw⁽¹⁾を知らない。このように、意図的な三すくみにより、三者のいずれで情報漏えいが生じても、なりすましが成立しない。

（４）S_i ⁽¹⁾との利用が高まることが期待できる。
Uにとって、インターネット上のサービス利用は、ID及びパスワードを調べることから始まる。利用しているサービスが多ければ多いほど、ID及びパスワードの管理はUにとって億劫である。この煩わしさから解放されることにより、インターネットの活用が更に広がると期待できる。
［実施例２］

以下、実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略又は簡略する。

実施例２では、２以上のC^(j)が存在する。例えば、図１５に示すように、C⁽¹⁾及びC⁽²⁾が存在するとする。また、C⁽¹⁾に、S₁ ⁽¹⁾及びS₂ ⁽¹⁾が登録されており、C⁽²⁾に、S₁ ⁽²⁾及びS₂ ⁽²⁾が登録されているとする。そして、Uが、それら４つのサービスシステム（S₁ ⁽¹⁾、S₂ ⁽¹⁾、S₁ ⁽²⁾及びS₂ ⁽²⁾）に登録したとする。その際、Uは、S₂ ⁽¹⁾の登録ではS₁ ⁽¹⁾の登録の際にpListに登録された情報を利用し、S₂ ⁽²⁾の登録ではS₁ ⁽²⁾の登録の際にpListに登録された情報を利用しなかったとする。言い換えれば、S₁ ⁽¹⁾については初回登録が行われ、S₂ ⁽¹⁾については２回目以降の登録が行われたとする。また、S₁ ⁽²⁾についてもS₂ ⁽²⁾についても初回登録が行われたとする。AIDが同じ値であればRANDも同じ値である。また、AIDが同じ値であれば、CIDも同じ値である。

この結果、pListは、図１６に示す通りとなる。すなわち、S₂ ⁽¹⁾に対応付けられるAIDは、aID⁽¹⁾、すなわち、S₁ ⁽¹⁾に対応付けられたAIDと同じである。一方、S₂ ⁽²⁾に対応付けられるAIDは、aID^(2’)、すなわち、S₂ ⁽¹⁾に対応付けられたAIDと異なる。２以上のC^(j)が存在する場合、U_M（APP）がC^(j)毎に実施例１に係るtpw発行フローを行うことが考えられる。しかし、そうすると、C^(j)毎にtpwが異なってしまい、Uにとっての利便性が低い。

そこで、実施例２では、tpwを２以上のC^(j)で共通にすることができる。

図１７は、実施例２に係るtpw発行フローの一例を示す。

U_M（APP）とC⁽¹⁾（その日初めてのtpw発行リクエストの送信先）との間に関して、実施例１に係るtpw発行フローが行われる。これにより、U_M（APP）は、C⁽¹⁾からtpwを受信する。

tpwを受信したU_M（APP）は、Uが登録されている他のC^(J)（ここではJは２以上の整数）の各々との間で、以下の処理を行う。U_M（APP）は、C⁽¹⁾から受信したtpwを関連付けたtpw発行リクエストをC^(J)に送信する。C^(J)は、tpwが関連付けられたtpw発行リクエストを受信する。C^(J)は、tpwを発行せず、受信したtpw発行リクエストに関連付けられているtpwを、そのC^(J)に登録されている各S_i ^(j)に送信する。C^(J)は、各S_i ^(J)から、eMes_i ^(J)を含んだ応答を受信する。そして、C^(J)は、{eMes_i ^(J)}_Mを含んだ応答（M = sysID _i ^(J)∈SYSIDPart）を、U_M（APP）に送信し、U_M（APP）が、その応答を受信する。

このように、U_M（APP）が、C⁽¹⁾以外の全てのC^(j)の各々にtpwを通知し（tpwを関連付けたtpw発行リクエストを送信し）、C⁽¹⁾以外の全てのC^(j)の各々から（つまり各C^(J)から）、{eMes_i ^(J)}_Mを含んだ応答を受信する。この一連の処理が終わった場合に、Uは、その日１日、同じtpwを使用して、いずれのC^(j)（ここではjは１以上の整数）に登録されているいずれのS_i ^(j)にもログイン可能である（サービスを受けることができる）。なお、Uが登録されている制御センタのうちC⁽¹⁾以外のいずれかのC^(j)との通信にエラーが生じた場合、U_M（APP）とC⁽¹⁾とのtpw発行フローから処理がやり直されてもよい。
［実施例３］

以下、実施例３を説明する。その際、実施例１及び２との相違点を主に説明し、実施例１及び２との共通点については説明を省略又は簡略する。

実施例２では、U_M（APP）が各C^(j)に対してtpw発行リクエストを送信する必要があるため、U_M（APP）が行う通信の回数が多くなる。

そこで、実施例３では、C^(j)が情報をやり取りすることで、U_M（APP）が行う通信の回数を減らすことができる（例えば、U_M（APP）は２以上のC^(j)のうちC⁽¹⁾とのみ通信を行なえばよい）。

以下、実施例３を詳細に説明する。その際、記載を簡単にするため、以下の表記ルールを採用する。
・SYSIDGroup^(j) _{SYSIDPart, aID}：pListにおいて、AIDがaIDとなる全てのsysID_x ^(j)（∈SYSIDPart）からなる集合（xは、iの値がいずれでもよいことを意味する）
・AID_SYSIDPart：pListにおける各sysID_x ^(x)∈SYSIDPart⊂SYSIDGroupに対するAIDの集合（下付きのxは、iの値がいずれでもよいことを意味し、上付きのxは、jの値がいずれでもよいことを意味する）
・Pass_{SYSIDPart, aID}：SYSIDがSYSIDPartの元であり、AIDがaIDとなる全てのアカウントのPASSからなる集合

図１８は、実施例３に係るtpw発行フローの一例を示す。

（ステップ１８０１）Uは、SYSIDPart（⊂SYSIDGroup）を選択し、U_M（APP）にreqPw及びSYSIDPartを入力する。このとき、AID_SYSIDPartは、{aID1, …, aIDN}であるとする。以下、１つのaIDWを例に取る（1≦W≦N）である。aIDWに対応したjを、「JW」であるとする。U_M（APP）は、aIDWを保持したアカウントを１つ選び、tReqPwW（= h_JW (Rand, pSYSID)）を計算し（ただし、そのアカウントのSYSID=sysID_IW ^(JW)としRAND＝RandWとする）、PASS（Pass_IW ^(JW)∈Pass_{SYSIDPart, aIDW}）を取得する。取得されたPASSを、PassWとする。その後、U_M（APP）は、SYSIDPart及び{tReqPwW, PassW}_1≦W≦NをいずれかのC^(JW)（ここではC^(J1)とする）に送信する。

（ステップ１８０２）C^(J1)は、PassWが正しいか否かを判断する。

（ステップ１８０３）ステップ１８０２の判断結果が肯定の場合、C^(J1)は、aList^(J1)を参照し、Pass1に含まれるaID1と同一のAIDを保持し且つSYSID（sysID_i ^(J1)）がSYSIDPartの元となる各アカウントに対して、そのMID（mID_i ^(J1)）を取得する。ステップ１８０２の判断結果が否定の場合、C^(J1)は、全てのsysID_i ^(J1)∈SYSIDGroup^(J1) _{SYSIDPart, aID1}に各々について、状態st_i ^(J1)の値を“false”とする。C^(J1)が、S_i ^(j)毎にst_i ^(J1)を管理する。st_i ^(J1)は、tpwの登録が成功したか（true）か否か（false）を意味する。

（ステップ１８０４）C^(J1)は、tpwを発行し、ステップ１８０２の判断結果が肯定の場合に特定された各S_i ^(J1)に、tpw及びmID_i ^(J1)を送信する。

（ステップ１８０５）tpw及びmID_i ^(J1)を受信したS_i ^(J1)は、mID_i ^(J1)が登録されているアカウントをuList_i ^(J1)から特定し、tpwInfo_i ^(J1)を定め、そのtpwInfo_i ^(J1）を含んだmes_i ^(J1)を生成する。S_i ^(J1)は、特定したアカウントに、TPWとして、受信したtpwを登録し、TPWINFOとして、定めたtpwInfo_i ^(J1)を登録する。また、S_i ^(J1)は、st_i ^(J1)の値を“true”とする。なお、S_i ^(J1)における当該Uが存在しない等の場合、st_i ^(J1)の値を“false”とする。

（ステップ１８０６）各S_i ^(J1)（∈SYSIDPart）は、当該アカウントに登録されているSUKEY（suKey_i ^(J1)）を取得し、状態st_i ^(J1)の値と、eMes_i ^(J1)=Enc_SUKEY(mes_i ^(J1))をC^(J1)に送信する（SUKEY= suKey_i ^(J1)）。この段階で、C^(J1)は、C^(J1)に登録されている全てのS_i ^(J1)（∈SYSIDPart）からst_x ^(x)の値およびmes_x ^(x)を受け取ったことになる。この後、C^(J1)は、2≦W≦Nに対して以下を実行する。ここでは、各W（≠１）に対してJW≠J1とする。JW＝J1となるWが存在する場合は、C^(J1)自身が、各S_i ^(JW)（＝S_i ^(J1)）に対して、tpwを新たに発行せず同一tpwを使い、ステップ１８０２〜ステップ１８０６までと同様の処理をすればよい。

（ステップ１８０７）C^(J1)は、SYSIDGroup^(JW) _{SYSIDPart, aIDJW}、tReqPwW及びPassWを、C^(JW)に送信する。

（ステップ１８０８）C^(JW)は、PassWが正しいか否かを判断する。この判断結果が肯定の場合、C^(JW)は、PassWに含まれるaIDWを用いてaList^(JW)からアカウントを特定し、MID（{mID_i ^(JW)}_B）を取得し（B= SYSID∈SYSIDGroup^(JW) _{SYSIDPart, aIDJW}）、一時的にst_i ^(JW)の値を“true”とする。PassWが正しくない場合は全てのサービスシステムについて（何らかの理由でMIDが取得できない場合は、MIDを取得できないサービスシステムについて）、C^(JW)は、st_i ^(JW)の値を“false”とする。

（ステップ１８０９）C^(JW)は、st_i ^(JW)＝trueとなる各S_i ^(JW)∈SYSIDGroup^(JW) _aIDwに対するアクセストークン（token_i ^(JW)）を生成する。C^(JW)は、token_i ^(JW)と、st_i ^(JW)と、mID_i ^(JW)とを、C^(J1)に送信する（token_i ^(JW)が、st_i ^(JW)、mID_i ^(JW)を含んでもよい）。この段階で、C^(J1)は、C^(J2),…., C^(JW)の各々から、{st_i ^(JW), mID_i ^(JW), token_i ^(JW)}_Bから受け取っている（B= SYSID∈SYSIDGroup^(JW) _{SYSIDPart, aIDJW}）。

（ステップ１８１０）C^(J1)は、st_i ^(JW)＝trueとなるS_i ^(JW)に対してのみ、mID_i ^(JW)、tpw及びtoken_i ^(JW)を送信する。

（ステップ１８１１）mID_i ^(JW)、tpw及びtoken_i ^(JW)を受信した各S_i ^(JW)は、token_i ^(JW)が正しいか否かを判断する。この判断結果が肯定の場合、S_i ^(JW)は、mID_i ^(JW)が登録されているアカウントをuList_i ^(JW)から特定し、tpwInfo_i ^(JW)を定め、そのtpwInfo_i ^(JW)を含んだmes_i ^(JW)を生成する。S_i ^(JW)は、特定したアカウントに、TPWとして、受信したtpwを登録し、TPWINFOとして、定めたtpwInfo_i ^(JW)を登録する。S_i ^(JW)は、eMes_i ^(JW)=Enc_SUKEY(mes_i ^(JW))を生成する（SUKEY=suKey_i ^(JW)）。S_i ^(JW)は、st_i ^(JW)の値を“true”とする。S_i ^(JW)は、st_i ^(JW)とeMes_i ^(JW)とをC^(J1)に返す。なお、token_i ^(JW)が正しくない等の場合、S_i ^(JW)は、st_i ^(JW)の値を“false”とし、そのst_i ^(JW)をC^(J1)に返してよい。

（ステップ１８１２）C^(J1)は、S_i ^(JW)から、st_i ^(JW)とeMes_i ^(JW)とを含んだ応答を受信する。

（ステップ１８１３）C^(J1)は、各S_i ^(JW)∈SYSIDGroup^(JW) _aIDw（2≦w≦N）から、st_i ^(JW)とeMes_i ^(JW)とを含んだ応答を受信した場合、ステップ１８０４で発行したtpwと、全ての（st_i ^(JW), eMes_i ^(JW)）を、U_M（APP）に返す。

U_M（APP）が各eMes_i ^(JW)を復号化することにより、Uは、全てのS_i ^(JW)⊂SYSIDPartで使用できるtpwと、各S_i ^(JW)⊂SYSIDPartから送られてきたtpwInfo_i ^(JW)（tpw使用期限等を含んだ情報）を得ることができる。

図１８に示したtpw発行フローの具体例を、図１９に示す。すなわち、Uが、S₁ ⁽¹⁾、S₂ ⁽¹⁾、S₁ ⁽²⁾、及びS₂ ⁽²⁾に登録されており、Uが、S₁ ⁽¹⁾及びS₂ ⁽²⁾についてのtpw（共通1-dayパスワード）の発行リクエストを送信するとき（SYSIDPart＝{S₁ ⁽¹⁾, S₂ ⁽²⁾｝のとき）、U_M（APP）、C⁽¹⁾、C⁽²⁾、S₁ ⁽¹⁾、S₂ ⁽²⁾間のやり取りは、図１９の通りである（図１８に記載のステップ番号と同じステップ番号を使用）。図１９では、C^(J1)をC⁽¹⁾とし、C^(JW)をC⁽²⁾としている。
［実施例４］

以下、実施例４を説明する。その際、実施例１〜３との相違点を主に説明し、実施例１〜３との共通点については説明を省略又は簡略する。

実施例４では、複数のC^(JW)に登録されている複数のS_i ^(JW)に共通のパスワード（tpw）の発行に関し、C^(J1)が、他のC^(JW)に登録されているS_i ^(JW)に関する登録処理をそのC^(JW)に任せる。

図２０は、実施例４に係るtpw発行フローの一例を示す。図１９との相違点を主に説明する。その際、C^(J1)をC⁽¹⁾とし、C^(JW)をC⁽²⁾とする。

ステップ１８０１〜ステップ１８０６と同じ処理が行われる（ステップ２００１〜ステップ２００６）。C⁽¹⁾が、sysID₂ ⁽²⁾、tReqPw⁽²⁾及びPass₂ ⁽²⁾に加えてtpwをC⁽²⁾に送信し（ステップ２００７）、C⁽²⁾が、tpw、sysID₂ ⁽²⁾、tReqPw⁽²⁾及びPass₂ ⁽²⁾をC⁽¹⁾から受信し、Pass₂ ⁽²⁾が正しいか否かを判断する（ステップ２００８）。その判断結果が肯定の場合、C⁽²⁾が、tpw及びmID₂ ⁽²⁾を、S₂ ⁽²⁾に送信する（ステップ２００９）。S₂ ⁽²⁾が、tpw及びtpwInfo₂ ⁽²⁾をuList₂ ⁽²⁾に登録し（ステップ２０１０）、st₂ ⁽²⁾とeMes₂ ⁽²⁾をC⁽²⁾に返す（ステップ２０１１）。C⁽²⁾が、そのst₂ ⁽²⁾とeMes₂ ⁽²⁾をC⁽¹⁾に送信する（ステップ２０１２）。つまり、st₂ ⁽²⁾とeMes₂ ⁽²⁾が、S₂ ⁽²⁾からC⁽²⁾を通じてC⁽¹⁾に送られる。その後、C⁽¹⁾は、tpwと、S₁ ⁽¹⁾及びS₂ ⁽²⁾からそれぞれ受信した（st₁ ⁽¹⁾, eMes₁ ⁽¹⁾）及び（st₂ ⁽²⁾, eMes₂ ⁽²⁾）とを、U_M（APP）に返す（ステップ２０１３）。

S_i ^(JW)（JW≠J1）は、C^(J1)に登録されたサービスシステムではないので、本来、C^(J1)はS_i ^(JW)に対してtpwを登録できない。そこで、上述の実施例３では、C^(JW)が、自身のsList_i ^(JW)に登録されているS_i ^(JW)に対して、tpw登録できるためのアクセストークン（token_i ^(JW)）を発行し、S_i ^(JW)におけるmID_i ^(JW)と共にC^(J1)に送信する。C^(JW)と各S_i ^(JW)との間に秘密鍵ckey _i ^(JW)が共有されていることで、mID_i ^(JW)を暗号化してC^(J1)に送信できる。token_i ^(JW)は、使い捨ての署名でもよいが、token_i ^(JW)の使用期限や権限の制限等がtoken_i ^(JW)に関連付けられていてよく、その場合、C^(J1)は、最初に受けたsysID _i ^(JW)、mID_i ^(JW)、token_i ^(JW)を次回以降も使うことができる。このため、C^(J1)とC^(JW)間の通信、及び、C^(JW)とS _x ^(JW)間の通信を、省略できる。
［実施例５］

以下、実施例５を説明する。その際、実施例１〜４との相違点を主に説明し、実施例１〜４との共通点については説明を省略又は簡略する。

実施例３及び４は、いわゆるＩＤ連携をベースとした方式が採用されるが（mIDが制御センタ間で連携される）、実施例５では、ＳＡＭＬ（Security Assertion Markup Language）のようなシングルサインオンをベースとした方式が採用される。S₂ ⁽²⁾（S_i ^(JW)）が、ポリシー実行ポイント２１００としての機能を有する。

図２１は、実施例５に係るtpw発行フローの一例を示す。図１９との相違点を主に説明する。

ステップ１８０１〜ステップ１８０６と同じ処理が行われる（ステップ２１０１〜ステップ２１０６）。C⁽¹⁾が、sysID₂ ⁽²⁾、tReqPw⁽²⁾及びPass₂ ⁽²⁾をC⁽²⁾に送信する（ステップ２１０７）。C⁽²⁾が、tpw、sysID₂ ⁽²⁾、tReqPw⁽²⁾及びPass₂ ⁽²⁾をC⁽¹⁾から受信し、Pass₂ ⁽²⁾が正しいか否かを判断する（ステップ２１０８）。

ステップ２１０８の判断結果が肯定の場合、C⁽²⁾は、認証状態、属性（mID₂ ⁽²⁾等）、利用権限（パスワード登録）などのアサーション（mID₂ ⁽²⁾等を含んだ情報）を、S₂ ⁽²⁾へ送信する（ステップ２１０９）。言い換えれば、C⁽²⁾（C^(JW)）は、uList₂ ⁽²⁾（uList_i ^(JW)）に登録されているmID ₂ ⁽²⁾（mID_i ^(JW)）を、C⁽¹⁾（C^(J1)）に通知する必要が無い。

S₂ ⁽²⁾が、ポリシー実行ポイント２１００によりアサーションが正しいか否かを判断する（ステップ２１１０）。S₂ ⁽²⁾は、その判断結果が肯定の場合、その判断結果（OK）をC⁽¹⁾に通知してもよいし、その判断結果をC⁽¹⁾に通知せず保持しておいてもよい。

C⁽¹⁾が、tpwを、S₂ ⁽²⁾に通知する（ステップ２１１１）。例えば、C⁽¹⁾が、sysID₂ ⁽²⁾に対応したS₂ ⁽²⁾との通信に必要な情報を知っていてその情報を使用してS₂ ⁽²⁾に通知を送信してもよいし、C⁽²⁾が、S₂ ⁽²⁾にアサーションを送信するとき等のタイミングで、S₂ ⁽²⁾との通信に必要な情報をC⁽¹⁾に通知してもよい。また、C⁽¹⁾からS₂ ⁽²⁾へのtpw通知は、S₂ ⁽²⁾からの上記判断結果に応答して行われてもよいし、S₂ ⁽²⁾からの上記判断結果無しに例えば定期的に行われてもよい。S₂ ⁽²⁾が、C⁽¹⁾からtpwを受信した場合、tpwInfo₂ ⁽²⁾を決定し、tpwとtpwInfo₂ ⁽²⁾をuList₂ ⁽²⁾に登録する（ステップ２１１２）。この登録は、ステップ２１１０の判断結果が肯定の場合に行われる。

その後、S₂ ⁽²⁾が、st₂ ⁽²⁾とeMes₂ ⁽²⁾をC⁽¹⁾に返す（ステップ２１１３）。C⁽¹⁾は、tpwと、S₁ ⁽¹⁾及びS₂ ⁽²⁾からそれぞれ受信した（st₁ ⁽¹⁾, eMes₁ ⁽¹⁾）及び（st₂ ⁽²⁾, eMes₂ ⁽²⁾）とを、U_M（APP）に返す（ステップ２１１３）。
［実施例６］

以下、実施例６を説明する。その際、実施例１〜５との相違点を主に説明し、実施例１〜５との共通点については説明を省略又は簡略する。

実施例１〜５では、tpw発行が行われる。実施例６では、tpw発行に代えて又は加えて、tpwに関する他種の制御、例えば、tpw変更、tpw削除等が行われる。具体的には、例えば、tpw発行リクエストは、tpw制御リクエストの一例である。tpw制御の一例が、tpw発行であり、制御センタ（識別符号制御装置又は識別符号制御システム）の一例が、制御センタである。tpw制御リクエストに関連付けられる情報要素は、tpw発行リクエストに関連付けられる情報要素と同じでよい。ＡＰＰは、tpw発行に加えてtpw発行以外のtpw制御にも使用される。以下、tpw制御リクエストの別の一例として、tpw削除を例に取り、tpw制御を説明する。なお、「tpw削除」とは、「tpw認証を無効化して、次にtpw発行依頼するまで、Uを含め誰もログインできないようにすること」を意味する。

図６は、実施例６に係るtpw削除フローの一例を示す。

（ステップ２２０１）U_M（APP）が、図１４のステップ１４０１と同様の処理を行う。但し、本実施例では、tpw発行リクエストに代えてtpw削除リクエストが送信される。

（ステップ２２０２）C⁽¹⁾は、tpw削除リクエストをU_M（APP）から受信し、そのリクエストに応答して、そのリクエストに関連付いているPass_i ⁽¹⁾が正しいか否かを判断する。

（ステップ２２０３）C⁽¹⁾は、ステップ２２０２の判断結果が肯定の場合、aList⁽¹⁾を参照し、正しいと判断されたPass_i ⁽¹⁾内のaID⁽¹⁾と一致するAIDを有し、且つ、tpw削除リクエストに関連付いているSYSIDPart内のいずれかのsysID_i ⁽¹⁾と一致するSYSIDを有するアカウントを全て特定する。C⁽¹⁾は、特定された全てのアカウントからそれぞれMID（mID_i ⁽¹⁾）を取得する。

（ステップ２２０４）C⁽¹⁾は、各sysID _i ⁽¹⁾（∈SYSIDPart）について、以下を行う。ステップ２２０４〜ステップ２２０７の説明において、１つのsysID_i ⁽¹⁾を例に取る。C⁽¹⁾は、sysID_i ⁽¹⁾にに対応したS_i ⁽¹⁾に、そのS_i ⁽¹⁾に対応するmID_i ⁽¹⁾を関連付けたtpw削除リクエストを送信する。

（ステップ２２０５）S_i ⁽¹⁾が、mID_i ⁽¹⁾が関連付いたtpw削除リクエストをC⁽¹⁾から受信する。S_i ⁽¹⁾は、受信したリクエストに関連付いているmID_i ⁽¹⁾と一致するMIDが登録されているアカウントをuList _i ⁽¹⁾から特定する。S_i ⁽¹⁾は、特定したアカウント上の認証要素tpw及びtpwInfoを削除する。

（ステップ２２０６）S_i ⁽¹⁾は、削除完了の応答を、C⁽¹⁾に送信する。

（ステップ２２０７）C⁽¹⁾は、sysID_i ⁽¹⁾（∈SYSIDPart）にそれぞれ対応した全てのS_i ⁽¹⁾から応答を受信した場合に、tpw削除リクエストに対する応答を、U_M（APP）に送信する。U_M（APP）が、応答をC⁽¹⁾から受信する。

実施例６によれば、選択されたPass_i ⁽¹⁾に対応するaID^(j)と同一のaID^(j)を保持する全てのアカウントにそれぞれ対応した全てのS_i ^(j)に対し、tpwについての制御を行うことができる。例えば、tpwの削除は、tpwに代えて使用期限及び使用回数に制限の無いパスワードが共通パスワードとして採用されている場合に有効であると考えられる（つまり、実施例では、採用されるパスワードは、共通1-dayパスワードであるが、そのような制限パスワードに限らず、使用期限及び使用回数等の制限の無いパスワードが採用されてもよい）。
［実施例７］

以下、実施例７を説明する。その際、実施例１〜６との相違点を主に説明し、実施例１〜６との共通点については説明を省略又は簡略する。

実施例７では、少なくとも１つのS_i ^(j)は、特定の制御センタに、Info_i ^(j)を送信する。「特定の制御センタ」は、例えば、そのS_i ^(j)が登録されている制御センタ、所定種類の情報要素（例えばtpw又はmID _i ^(j)）の送信元の制御センタ、又は、U_M（APP）からtpw制御リクエストを受信した制御センタである。「Info_i ^(j)」は、Info _i ^(j)の発行元のS_i ^(j)から出力された情報でありそのS_i ^(j)以外のサービスシステムに公開されてよい情報を含んだ情報である（Info_i ^(j)に含まれる情報は、Uにより公開が許可された情報でよい）。Info_i ^(j)は、例えば事前登録においてS_i ^(j)からの応答（例えば、図１２のステップ１２０３の応答、図１３のステップ１３０３の応答）に含まれてもよいし、tpw発行等の制御においてS_i ^(j)からの応答（例えば、図１４のステップ１４０６の応答、図１８のステップ１８１２の応答、図２０のステップ２０１１及びステップ２０１２のうちの少なくとも１つの応答、図２１のステップ２１１３）に含まれてもよい。これにより、図２３に示すように、Info_i ^(j)を発行したS_i ^(j)のuList _i ^(j)には、その発行されたInfo _i ^(j)が登録される（INFO）。また、特定の制御センタに、Info _i ^(j)が集まり、図２４に示すように、その制御センタのaList^(j)に、Info_i ^(j)が登録される。Info_i ^(j)は、公開が許可された情報に関する情報として、許可された公開先サービスシステムに関する情報（例えば、sysID _i ^(j)、サービスシステムを提供する企業の名称）、公開されている期間等を含んでよい。

Uから申請を受けたS_i ^(j)は、その申請の処理に所定種類の情報を必要とする場合、上記特定の制御センタ（又は、申請を受けたS_i ^(j)が登録されているC^(j)）に、その所定種類の情報の問合せ（例えば、申請元のUに対応したmID _i ^(j)が関連付けられた問合せ）を送信してよい（その問合せは、その問合せをS_i ^(j)から受けたC^(j)から、上記特定の制御センタに転送されてもよい）。その問合せを受けた制御センタが、その問合せ応答して、mID _i ^(j)に対応したInfo _i ^(j)内の情報であり公開が許可されている情報（例えば、履歴書、住民票）を、問合せ元のS_i ^(j)に送信してよい。
［実施例８］

以下、実施例８を説明する。その際、実施例１〜７との相違点を主に説明し、実施例１〜７との共通点については説明を省略又は簡略する。なお、実施例８は、実施例７の変形例又は具体例でよい。

Uが登録されている個々のサービスシステムは、Uの個人情報（例えば、卒業証明書、資格証明書、履歴書、カルテ、マイナンバー（及びそれに付随する情報）等）を管理している。少なくともUが許可する範囲で、Uの個人情報が、サービスシステム間で連携されるようになっていると、利便性の向上が期待される。また、連携される情報は、Uの個人情報に代えて又は加えて、Uに関する他種の情報も考えられるが、少なくとも連携対象の情報の種類によっては、連携対象の情報の少なくとも一部が、不特定者（例えば、U及びUが許可する者（例えば、連携元と連携先）以外の者）に閲覧されてはならない。

実施例８では、不特定者に情報が閲覧されること無しにその情報をサービスシステム間で連携できる。

また、実施例８では、登録フローにおいて、Uは、S_i ^(j)に情報が登録されたことを知ることができる。

また、実施例８では、C^(j)とS_i ^(j)に、認可情報の委譲に関する既存の仕様、例えばOAuthを適用可能である。

以下、実施例８に係る登録フロー及び情報連携（Information Sharing）フローの各々の一例を説明する。

図３１は、実施例８に係る登録フローの一例を示す。なお、以下、説明を分かり易くするため、C^(j)として、C⁽¹⁾のみが存在することとする（図３１は、複数のS_i ⁽¹⁾のうちS₁ ⁽¹⁾のみを示す）。

登録フローが終了した時点において、下記の情報要素がU_Mに保存されている。下記の情報要素は、pListに登録される。また、下記の情報要素のうちの少なくとも１つが、U_M固有の情報を含む情報を鍵として暗号化されてから保存されてよい。
・Pass_i ⁽¹⁾：C⁽¹⁾に送信するリクエストの承認を依頼する情報（リクエスト依頼パス）。
・suKey_i ⁽¹⁾：S_i ⁽¹⁾と通信する際に必要な共有鍵。

登録フローが終了した時点において、下記の情報要素がS_i ⁽¹⁾に保存されている。下記の情報要素は、uList_i ⁽¹⁾に登録される。下記の情報要素のうちの少なくとも１つは暗号化されてから保存されてもよい。
・uID_i ⁽¹⁾：S_i ⁽¹⁾の利用のためのユーザＩＤでありUとS_i ⁽¹⁾との間で共有される情報。
・authInfo_i ⁽¹⁾：Uの認証情報（例えばTempPw以外のパスワード（例えば固定パスワード）。
・verAuthInfo_i ⁽¹⁾：authInfo_i ⁽¹⁾を検証するための情報。
・mID_i ⁽¹⁾：S_i ⁽¹⁾の管理用ＩＤであり、C⁽¹⁾とS_i ⁽¹⁾との間で共有される情報（U毎に異なる）。なお、情報連携の際には、連携元又は連携先のmID_i ⁽¹⁾が保存される。
・suKey_i ⁽¹⁾：U_Mと通信する際に必要な共有鍵。
・verRegToken：登録完了チェックトークン（regToken）を検証するための情報。
・TempPw：一時的なパスワード（例えばtpw）。
・TempPwInfo：TempPwの制限に関する情報であり、例えば、有効期限（period）、使用回数（TempPwTimes）及び使用可能回数（TempPwTimesMax）のうちの少なくとも１つを含む。
・sID：連携ＩＤ。情報連携の際に使用されるＩＤであり連携を一意に識別するためのＩＤである。
・AttList_i ⁽¹⁾：情報属性（att）のリスト（詳細は後述）。

登録フローが終了した時点において、下記の情報要素がC⁽¹⁾に保存されている。下記の情報要素は、aList⁽¹⁾、sList⁽¹⁾及びcList⁽¹⁾のうちの少なくともaList⁽¹⁾に登録される。下記の情報要素のうちの少なくとも１つは暗号化されてから保存されてもよい。
・mID_i ⁽¹⁾：S_i ⁽¹⁾の管理用ＩＤであり、C⁽¹⁾とS_i ⁽¹⁾との間で共有される情報（U毎に異なる）。なお、情報連携の際には、連携元のmID_i ⁽¹⁾と連携先のmID_i ⁽¹⁾とが保存される。
・verTicket：aList⁽¹⁾のアカウントに対する登録チケット（ticket）の検証に必要な情報である。
・aID⁽¹⁾：APPのＩＤ。上述したように、１つのC^(j)及び１つのAPPにつき異なる複数のaID⁽¹⁾が存在することもある。
・tReqPw：リクエストパスワード。
・verPass_i ⁽¹⁾：Pass_i ⁽¹⁾の検証（U_Mの機器認証）に必要な情報。
・sID：連携ＩＤ。
・sysID_i ⁽¹⁾：S_i ⁽¹⁾のサービスシステムＩＤ。
・att：情報属性（例えば氏名、電子メールアドレス等）。attとして、提供可能なattと受入可能なattとが保存されている。１以上のatt値（attに従う値）を含んだ情報が連携対象情報（Info）である。
・eInfo：暗号化された連携対象情報（Info）。
・AccessToken：OAuthのアクセストークンであって、C⁽¹⁾とS_i ⁽¹⁾との間での通信に使用されるトークン。

実施例８に係る登録フローは、図３１に示す通り、下記の通りである。

登録フローは、UとS_i ⁽¹⁾間の手続きである第１の登録手続きと、UとC⁽¹⁾間の手続きである第２の登録手続きとで構成される。第１の登録手続きは、下記の（Ｒ１）〜（Ｒ６）で構成され、第２の登録手続きは、下記の（Ｒ７）〜（Ｒ１０）で構成される。

（Ｒ１）U_M（例えばAPP）は、S_i ⁽¹⁾の方針に従うユーザ情報をS_i ⁽¹⁾に送信し、S_i ⁽¹⁾にログインするためのuID_i ⁽¹⁾及びauthInfo_i ⁽¹⁾を定める。

（Ｒ２）S_i ⁽¹⁾は、（Ｒ１）で受け取ったユーザ情報を、必要に応じて変換し保存する。

（Ｒ３）S_i ⁽¹⁾は、sysID_i ⁽¹⁾及び登録パスワード（rpw）が関連付けられたアカウント追加リクエストをC⁽¹⁾に送信する。なお、rpwは、U自身が決めてU_M（又はU_P）によりS_i ⁽¹⁾に知らせた情報もよいし、S_i ⁽¹⁾により決められた情報でもよい。C⁽¹⁾は、sysID_i ⁽¹⁾及びrpwが関連付けられているアカウント追加リクエストを受信する。

（Ｒ４）C⁽¹⁾は、アカウント追加リクエストに応答して、次の処理を行う。すなわち、C⁽¹⁾は、アカウントを１つ作成し（例えばaList⁽¹⁾にアカウントを追加し）、そのアカウントに対して、mID_i ⁽¹⁾を割り当てる（登録する）。更に、C⁽¹⁾は、そのアカウントに対する登録チケット（ticket）を生成する。その後、C⁽¹⁾は、割り当てたmID_i ⁽¹⁾、受信したsysID_i ⁽¹⁾、及び、verTicket（登録チケットの正当性を検証するために必要な情報）を、自身のデータベース（例えばaList⁽¹⁾）に登録する。ticketには、該当するアカウントを特定する情報が含まれている。C⁽¹⁾は、割り当てたmID_i ⁽¹⁾、及び、生成したticketを、S_i ⁽¹⁾に送信する。S_i ⁽¹⁾は、mID_i ⁽¹⁾及びticketを受信する。

（Ｒ５）S_i ⁽¹⁾は、アカウントを１つ追加し（uList_i ⁽¹⁾にアカウントを１つ追加し）、U_Mとの暗号化通信に必要な鍵suKey_i ⁽¹⁾を定め、uID_i ⁽¹⁾、mID_i ⁽¹⁾及びsuKey_i ⁽¹⁾をそのアカウントに登録する。さらに、S_i ⁽¹⁾は、登録完了チェックトークン（regToken）を生成し，それを検証するために必要な情報（verRegToken）を、当該アカウントに登録する。

（Ｒ６）S_i ⁽¹⁾は、ticket、suKey_i ⁽¹⁾及びregTokenをU_Mに送信する。U_Mは、ticket、suKey_i ⁽¹⁾及びregTokenを受信する。なお、U自身がrpwを設定していない場合、S_i ⁽¹⁾は、更にrpwもU_Mに送信する。また、regTokenの設定及び送信は必須ではない。

（Ｒ７）U_Mは、ticket、suKey_i ⁽¹⁾、rpw、regToken及びreqPwを関連付けた登録リクエストをC⁽¹⁾に送信する。C⁽¹⁾は、ticket、suKey_i ⁽¹⁾、rpw、regToken及びreqPwが関連付いている登録リクエストを受信する。ticket、suKey_i ⁽¹⁾、rpw及びregTokenは、S_i ⁽¹⁾から受信した情報でもよいし、Uにより入力された情報でもよい。reqPwは、U又はAPPにより定められた情報でよい。

（Ｒ８）C⁽¹⁾は、登録リクエストに応答して、次の処理を行う。すなわち、C⁽¹⁾は、verTicket（及びrpw）を用いて、ticketの正当性を検証する。そのticketが正しい場合、C⁽¹⁾は、ticketからアカウントを識別し、識別されたアカウントに対して、aID⁽¹⁾及びPass_i ⁽¹⁾を生成し登録する。また、C⁽¹⁾は、そのaID⁽¹⁾及びPass_i ⁽¹⁾と、登録リクエストに関連付いているreqPwとの検証に必要な情報（verTReqPw（tReqPwの検証に必要な情報）及びverPass_i ⁽¹⁾（Pass_i ⁽¹⁾の検証に必要な情報）を、識別されたアカウントに登録する。Pass_i ⁽¹⁾には、C⁽¹⁾におけるアカウントを識別できる情報（例えばaID⁽¹⁾）、及び、Uが登録先S_i ⁽¹⁾を識別できるための情報（例えばsysID_i ⁽¹⁾）が含まれる。なお、C⁽¹⁾は、（Ｒ８）において、UにOAuth認証をさせて、その認証結果に基づくAccessTokenを暗号化してそのアカウントに登録してもよい。

（Ｒ９）C⁽¹⁾は、mID_i ⁽¹⁾及びregTokenをS_i ⁽¹⁾に送信する。S_i ⁽¹⁾は、mID_i ⁽¹⁾及びregTokenを受信し、受信したmID_i ⁽¹⁾が登録されているアカウントにおけるverRegTokenを用いることにより、regTokenを検証する。regTokenが正当な場合、S_i ⁽¹⁾は、そのアカウントが３者間認証を利用できる状態になったと認識する。

（Ｒ１０）C⁽¹⁾は、Pass_i ⁽¹⁾をU_Mに送信する。U_Mは、Pass_i ⁽¹⁾を受信し、Pass_i ⁽¹⁾及びsuKey_i ⁽¹⁾を保存する。

以上が、実施例８に係る登録フローの説明である。なお、実施例８において、登録フローは、図３１を参照して説明した登録フローに代えて、他の実施例での登録フローが適用されてもよい。或いは、実施例８に係る登録フローは、他の実施例で適用されてもよい。また、実施例８に代えて又は加えて他の実施例でもOAtuthが適用されてもよいが、少なくともOAtuthは本発明に必須ではない。

図２５は、実施例８に係る認証／連携フローの一例を示す。なお、以下の説明では、S_i ^(j)として、S₁ ⁽¹⁾及びS₂ ⁽¹⁾を含む複数のS_i ⁽¹⁾が存在することとする。また、以下の説明では、Uが、S₁ ⁽¹⁾（サービスＡ）の利用にあたり、S₁ ⁽¹⁾が所望する情報がS₂ ⁽¹⁾（サービスＢ）に保持されている情報と同じため、S₂ ⁽¹⁾に保持されている情報をS₁ ⁽¹⁾に提供したいとする。従って、S₂ ⁽¹⁾が、連携元サービスシステムであり、S₁ ⁽¹⁾が、連携先サービスシステムである。また、以下の説明では、冒頭に「（認証）」が付いている処理は、tpwのようなTempPw発行の場合のみ実行される処理である。冒頭に「（連携）」が付いている処理は、情報連携の場合のみ実行される処理である。冒頭に「（認証）」も「（連携）」も付いていない処理は、TempPw発行の場合と情報連携の場合のいずれの場合も実行される処理である。

（Ｐ１）
U_M（APP）は、opの選択をUから受ける。「op」は、リクエスト対象のオペレーション種類であり、具体的には、例えば、認証、情報連携、又はその両方である。「認証」が選択された場合、以降、冒頭に「（認証）」が付いている処理が行われることになる。「情報連携」が選択された場合、以降、冒頭に「（連携）」が付いている処理が行われることになる。「両方」が選択された場合、以降、冒頭に「（認証）」が付いている処理も「（連携）」が付いている処理も行われることになる。なお、冒頭に「（認証）」が付いている処理と冒頭に「（連携）」が付いている処理の重複部分は、一方の処理で行われたならば他方の処理では行われないでもよい。
U_M（APP）は、U_Mに保存されている全てのPass_i ⁽¹⁾から特定されるsysID_i ⁽¹⁾のリストを表示する。
（認証）：U_M（APP）は、表示したリストから、aID^(1)A（又はsysID₁ ⁽¹⁾）の選択を受ける。aID^(1)Aは、Uがログイン先とするS₁ ⁽¹⁾（サービスＡ）のsysID₁ ⁽¹⁾が登録されているアカウントにおけるaID⁽¹⁾である。
（連携）：U_M（APP）は、表示したリストから、aID^(1)A（又はsysID₁ ⁽¹⁾）及びaID^(1)B（又はsysID₂ ⁽¹⁾）の選択を受ける。aID^(1)Aは、情報の連携先S₁ ⁽¹⁾のsysID₁ ⁽¹⁾が登録されているアカウントにおけるaID⁽¹⁾である。aID^(1)Bは、情報の連携元S₂ ⁽¹⁾のsysID₂ ⁽¹⁾が登録されているアカウントにおけるaID⁽¹⁾である。
U_M（APP）は、選択されたopと、選択されたアカウントに対するPass（Pass₁ ⁽¹⁾及びPass₂ ⁽¹⁾のうちの少なくともPass₁ ⁽¹⁾）と、tReqPwとを関連付けたリクエストを、C⁽¹⁾に送信する。tReqPwは、（Ｐ１）においてUから入力されたreqPw又はそれに基づく情報である。C⁽¹⁾は、op、Pass及びtReqPwが関連付いているリクエストを受信する。

（Ｐ２）
C⁽¹⁾は、受信したリクエストに応答して、次の処理を行う。すなわち、C⁽¹⁾は、受信したPass及びtReqPwが登録されているアカウント（以下、対象アカウント）におけるverPass及びverTReqPwを用いてtReqPw及びPassの正当性を検証する。それらが正当な場合、C⁽¹⁾は、Passを基に特定されるaID^(1)A（及びaID^(1)B)に対応するmID₁ ⁽¹⁾（及びmID₂ ⁽¹⁾）をアカウント（例えばaList⁽¹⁾）から見つける。
（連携）：C⁽¹⁾は、aID^(1)A（mID₁ ⁽¹⁾）に対応するS₁ ⁽¹⁾に対して、受け入れ可能な情報属性（att）のリスト（AttList₁ ⁽¹⁾）を照会し、且つ、aID^(1)B（mID₂ ⁽¹⁾）に対応するS₂ ⁽¹⁾に対して、提供可能な情報属性の属性リスト（AttList₂ ⁽¹⁾）を照会する。「AttList_i ⁽¹⁾」は、情報属性（att）のリストであり、受け入れ可能なattと提供可能なattとのうちの少なくとも一方を含む。AttList_i ⁽¹⁾は、受け入れ可能なattと提供可能なattとのうちの両方を含んでいて、C⁽¹⁾からの照会に応答して提供される際に、受け入れ可能なattと提供可能なattとのうちの一方に絞られてもよい。AttList_i ⁽¹⁾は、S_i ⁽¹⁾から事前に登録されたリストでもよく、その場合、照会手続きは省略されてよい。S_i ⁽¹⁾は、上述したように、提供可能なatt及び受け入れ可能なattを予め保存している。

（Ｐ３）
（連携）：C⁽¹⁾は、AttList₁ ⁽¹⁾及びAttList₂ ⁽¹⁾の共通部分（att）をU_Mに送信し、U_Mが、共通部分（att）を表示する。U_Mは、Uから、その共通部分のうちの、連携する情報属性attの選択を受け、選択されたattを、C⁽¹⁾に送信する。C⁽¹⁾は、選択されたattを受信する。

（Ｐ４）
（認証）：C⁽¹⁾は、対象アカウントに対するtpwを生成する。ここでは、tpwが生成されることとするが、tpw以外の種類のTempPwが生成されてもよい。
（連携）：C⁽¹⁾は、この認証／連携フローで実行される情報連携に対して一意的なsIDを生成する。

（Ｐ５）
（連携）：C⁽¹⁾は、（Ｐ４）で生成したsID、mID₂ ⁽¹⁾、（Ｐ３）で受信したatt、及び、連携先S₁ ⁽¹⁾のsysID₁ ⁽¹⁾を関連付けたリクエスト（情報提供リクエスト）を、連携元S₂ ⁽¹⁾に送る。その際、C⁽¹⁾は、OAuthのAccessTokenも、連携元S₂ ⁽¹⁾に送信してよい。OAuthのAccessTokenには、authInfo₁ ⁽¹⁾無しに連携先S₁ ⁽¹⁾に送信されてよい情報属性（att）が記述されていてよい。連携元S₂ ⁽¹⁾が、sID、mID₂ ⁽¹⁾、att、及びsysID₁ ⁽¹⁾（及びAccessToken）が関連付いているリクエストを受信する。

（Ｐ６）
（連携）：連携元S₂ ⁽¹⁾は、そのリクエストに応答して、次の処理を行う。すなわち、連携元S₂ ⁽¹⁾は、mID₂ ⁽¹⁾に対応するUに対するatt値（受信したattに従う値）を含んだ連携対象情報Infoを、連携先S₁ ⁽¹⁾が復号可能な鍵で暗号化する。ここでは、サービスＢ（S₂ ⁽¹⁾）から連携される情報という意味で、Infoを、「InfoB」と表記し、暗号化されたInfoBを、サービスＡ（S₁ ⁽¹⁾）に連携される情報という意味で、「eInfoBA」と表記する。連携元S₂ ⁽¹⁾は、InfoBをsuKey₂ ⁽¹⁾で暗号化する。その暗号化されたInfoBを、Uと共有される鍵で暗号化されたという意味で、「eInfoUB」と表記する。S₂ ⁽¹⁾は、sID、eInfoBA、及び、eInfoUBを、C⁽¹⁾に送る。C⁽¹⁾は、sID、eInfoBA、及び、eInfoUBを受信する。C⁽¹⁾は、受信したsID、eInfoBA、及び、eInfoUBを記憶部５１１に格納してよい。

（Ｐ７）
（認証）：C⁽¹⁾は、mID₁ ⁽¹⁾及びtpwを関連付けたリクエストを、S₁ ⁽¹⁾に送信する。S₁ ⁽¹⁾は、mID₁ ⁽¹⁾及びtpwが関連付いているリクエストを受信する。
（連携）：C⁽¹⁾は、mID₁ ⁽¹⁾及びsIDを関連付けたリクエストを、連携先S₁ ⁽¹⁾に送信する。その際、C⁽¹⁾は、OAuthのAccessTokenも連携先S₁ ⁽¹⁾に送信してよい。連携先S₁ ⁽¹⁾は、mID₁ ⁽¹⁾及びsID（及びAccessToken）が関連付いているリクエストを受信する。

（Ｐ８）
（認証）：S₁ ⁽¹⁾は、mID₁ ⁽¹⁾に該当するアカウントに、tpwと、そのtpwについてのtpwInfo（例えば、period、tpwTimesMax）とを登録し、tpw及びtpwInfoを含んだ情報をsuKey₁ ⁽¹⁾で暗号化し、暗号化された情報であるeTpwInfoをC⁽¹⁾に返す。
（連携）：S₁ ⁽¹⁾は、sID及びmID₁ ⁽¹⁾を、データベース（例えばuList₁ ⁽¹⁾）における該当アカウントに登録する。

（Ｐ９）
（認証）：C⁽¹⁾は、eTpwInfo（暗号化されたtpwを含む）をU_Mに送る。
（連携）：C⁽¹⁾は、eInfoUBをU_Mに送る。

（Ｐ１０）

U_Mは、（Ｐ９）で受け取った情報（eTpwInfo及びeInfoUBのうちの少なくとも一方）を、suKey₂ ⁽¹⁾を用いて復号し、復号化された情報を表示する。
（連携）：表示された情報は、連携対象情報である。U_M（APP）は、連携対象情報の連携を承認する（OK）かキャンセルするか（NG）の回答を受け付け、受け付けた回答を、C⁽¹⁾に通知してよい。Uは、連携対象情報の少なくとも一部に誤りがある、或いは連携したくなくなった等の場合に、「NG」を回答すればよい。回答が「NG」（キャンセル）を意味する場合、C⁽¹⁾は、連携をキャンセルする、すなわち、連携対象情報が連携先S₁ ⁽¹⁾に取得されることを不可能とする。具体的には、例えば、C⁽¹⁾は、回答「NG」を受信した場合に、記憶部５１１に格納されたeInfoUB（及びeInfoBA及びsID）を記憶部５１１から削除する、又は、連携対象情報のアクセス権限から連携先S₁ ⁽¹⁾を除外する。

（Ｐ１１）

U_Pは、S₁ ⁽¹⁾にアクセスし、例えばログインのために、uID₁ ⁽¹⁾及びauthInfo₁ ⁽¹⁾をS₁ ⁽¹⁾に入力する。
（認証）：U_Pは、更にtpwをS₁ ⁽¹⁾に入力する。

（Ｐ１２）

入力された情報（uID₁ ⁽¹⁾及びauthInfo₁ ⁽¹⁾）が正しい場合、S₁ ⁽¹⁾は、U_Pのログインを許可する。

（Ｐ１３）
（連携）：S₁ ⁽¹⁾は、S₁ ⁽¹⁾に登録されているmID₁ ⁽¹⁾宛ての連携処理に対するsIDをC⁽¹⁾に送信する。C⁽¹⁾は、そのsIDに関連付けられているeInfo（例えばeInfoBA）を、S₁ ⁽¹⁾に送信する。S₁ ⁽¹⁾は、そのeInfo（例えばeInfoBA）を受信し復号化する（これにより、InfoBが得られる）。

上述した情報連携フローによれば、情報の連携は、Uからのリクエスト（許可）により可能となる。また、連携対象の情報、連携元及び連携先のいずれもUが指定可能である。このため、連携対象情報、連携元及び連携先を、Uの許可した範囲に制限できる。

また、上述した情報連携フローによれば、連携対象の情報は、暗号化された状態で、連携元及び連携先以外の者により管理される記憶部５１１に格納され、その情報は、連携先であるS₂ ⁽¹⁾により復号される。このため、連携対象の情報が不特定者に閲覧されることを防ぐことができる。

なお、上述した情報連携フローにおいて、C⁽¹⁾が、eInfoBAに加えて、そのeInfoBAがサービスＢ（S₂ ⁽¹⁾）からの情報であることの証明書も記憶部５１１に格納してよい。それに代えて又は加えて、C⁽¹⁾が、eInfoBAに加えて、そのeInfoBAがサービスＢ（S₂ ⁽¹⁾）からの情報であることの証明書も、S₁ ⁽¹⁾に送信してもよい。

また、連携される情報の少なくとも一部は、ユーザ端末（U_P及びU_Mのうちの少なくとも１つ）に表示される情報に代えて又は加えて、情報連携先のサービスシステムへのアクセスキー（例えばURL等）のようなリンクであってもよい。また、そのリンクも、表示される情報の少なくとも一部であってよい。

また、連携元と連携先は、上記例のような１：１に限らず、１：N（Nは２以上の整数）でも、M：１（Mは２以上の整数）でもよい。

また、eInfoは、S₂ ⁽¹⁾からC⁽¹⁾（記憶部５１１）経由でS₁ ⁽¹⁾に送られるが、それに代えて、下記の（ａ）〜（ｃ）のうちのいずれかが採用されてもよい。
（ａ）C⁽¹⁾が、InfoBをサービスＡ（S₁ ⁽¹⁾）に送ることをS₂ ⁽¹⁾にリクエストする。S₂ ⁽¹⁾が、そのリクエストに応答して、eInfo（又はInfoB（暗号化されていない連携対象情報））をS₁ ⁽¹⁾に送る。
（ｂ）C⁽¹⁾が、InfoをサービスＢ（S₂ ⁽¹⁾）から取得することをS₁ ⁽¹⁾にリクエストする。S₁ ⁽¹⁾が、そのリクエストに応答して、eInfoBA（又はInfoB）をS₂ ⁽¹⁾から取得する。
（ｃ）S₂ ⁽¹⁾が、eInfoBA（又はInfoB）の存在する場所（S₂ ⁽¹⁾の中又は外のストレージ装置）を表すリンクをC⁽¹⁾に送る。C⁽¹⁾が、そのリンクに従い、eInfoBA（又はInfoB）を取得し、そのeInfoBA（又はInfoB）をS₁ ⁽¹⁾に送るか、或いは、C⁽¹⁾が、そのリンクをS₁ ⁽¹⁾に送り、S₁ ⁽¹⁾が、そのリンクに従い、eInfoBA（又はInfoB）を取得する。

実施例８に係る情報連携は、Uの証明資料（例えば、卒業証明書、資格証明書、納税証明書、不動産登記簿等）をその証明資料を管理している大学又は団体等から企業等に提出することや、医療関係のカルテ等を病院間で受け渡しすることや、マイナンバー（及びそれに付随する情報）を企業間で受け渡しすること等、様々なケースに適用することが期待できる。

実施例８によれば、情報連携をUが安心して任せられることが期待できる。なぜなら、S_i ⁽¹⁾は、C⁽¹⁾から信用度等の観点から認められた場合にC⁽¹⁾に登録されることが期待されるからである。

実施例７及び８のうちの少なくとも１つにおいて、下記の（０１）〜（０５）のうちの少なくとも１つが採用されてよい。

（０１）連携対象情報の少なくとも一部は暗号化されないでもよい。連携対象情報の少なくとも一部を暗号化するか否かは、ユーザにより選択されてもよいし（例えば、ステップ２５０１で、連携対象情報毎に暗号化するか否かをユーザが指定してもよいし）、連携対象情報の重要度又は種別に応じて連携元サービスシステムにより暗号化するか否かが制御されてもよい。

（０２）連携対象情報のEK₁ ⁽¹⁾（暗号鍵）は、S₁ ⁽¹⁾の公開鍵でよく、連携対象情報のDK₁ ⁽¹⁾（復号鍵）は、S₁ ⁽¹⁾の秘密鍵でよい。また、その暗号鍵／復号鍵は、公開鍵／秘密鍵に代えて、共通鍵等の他種の鍵でもよい。また、その鍵は、S₁ ⁽¹⁾及びS₂ ⁽¹⁾間でユーザ端末経由で受け渡しされてもよいし（具体的には、例えば、S₂ ⁽¹⁾からC⁽¹⁾に送信され、C⁽¹⁾からU_Mに送信され（U_MによりU_Mの画面に表示され）、U_Pに入力され、U_PからS₁ ⁽¹⁾に送信されてもよいし）、S₁ ⁽¹⁾及びS₂ ⁽¹⁾間でユーザ端末非経由で受け渡しされてもよいし（具体的には、例えば、S₂ ⁽¹⁾からC⁽¹⁾経由（又は非経由）でS₁ ⁽¹⁾に送信されてもよいし）、S₁ ⁽¹⁾及びS₂ ⁽¹⁾間で事前に共有されてもよい。

（０３）例えば連携対象情報の少なくとも一部が暗号化されていない場合、C⁽¹⁾は、連携対象情報が無害であるか否か（例えば表示させてよいか否か）のチェック、つまり、マルウェア（例えば、ウィルス又は遠隔操作プログラム等）の有無のチェックを行ってよい。

（０４）実施例８では、tpw発行リクエストが、情報連携リクエスト（情報をサービスシステム間で共有することのリクエスト）を兼ねることができるが、情報連携リクエストは、tpw発行リクエストから独立していてよい。すなわち、U_Mは、tpw発行リクエストの発行とは別のタイミングで、情報連携リクエスト（例えば、サービスA（S₁ ⁽¹⁾）からサービスC（S₂ ⁽¹⁾）に情報を連携することのリクエスト）をC⁽¹⁾に送信してもよい。その場合、その情報連携リクエストに応答して、上述の情報連携が行われてよい。

（０５）実施例８では、連携元も連携先もUにより選択されるが、連携元と連携先のうちの少なくとも１つが、Uが利用し得る全てのサービスシステム（C⁽¹⁾がUについてaList⁽¹⁾から特定できる全てのサービスシステム）であってもよい。

以下、上述した実施例１〜８を総括する。なお、総括の説明において、適宜、実施例１〜８のうちの少なくとも１つの実施例の変形例等の新たな記載を追加することができる。

実施例１〜８によれば、S_i ^(j)は、C^(j)からmID_i ^(j)及びtpwを受信した場合に、Uからサービスのリクエスト（例えばログインのリクエスト）を受け付け可能な状態になり、tpwの使用期限（有効期限）が過ぎた場合に、Uからサービスのリクエスト（例えばログインのリクエスト）を受け付け不可能な状態になる。前者の状態は、認証シャッターがopenの状態であり、後者の状態は、認証シャッターがclosedの状態である。「認証シャッター」とは、認証リクエストの受け付けを制御するための論理的なシャッターである。S_i ^(j)は、認証シャッターがopenであれば、uID_i ^(j)及びtpwと共に認証リクエストを受けた場合に、そのuID_i ^(j)及びtpwが正しいか否かの判断（認証）を行う。一方、S_i ^(j)は、認証シャッターがclosedであれば、uID_i ^(j)及びtpwが正しいか否かの判断を行うこと無しにその認証リクエストを拒否する。tpwの使用期限が過ぎたことが、認証シャッターの状態がopenからclosedに変わった意味するが、認証シャッターのopenからclosedの変更は、Uからのリクエストに応答して行われてもよい。

図２６は、識別符号管理の概要の一例を示す。

図２６において、「TempPw」とは、上述したように一時的なパスワードの意味であり、tpwに限らず、一般的なotp（ワンタイムパスワード）を含む概念である。図２６によれば、TempPwと制御方式の関係がわかる。

TempPwが必要なケースでは、TempPwの使用可能期間（使用期限までの期間）が短い（例えば数分）か長い（例えば「短い」に該当する期間より長い）かと、TempPwの使用可能回数が固定か無制限かによって、使用されるTempPwの種類が異なる。具体的には、例えば、TempPwの使用可能期間が「短い」であり、TempPwの使用可能回数が「固定」の場合、使用されるTempPwは、一般的なotp（例えば使用可能回数が１回に制限されたotp）でよい。TempPwの使用可能期間が「長い」であり、TempPwの使用可能回数が「無制限」の場合、使用されるTempPwは、上述したtpwであることが好ましい。

TempPwは必ずしも必要ではない。TempPwが不要なケースもある。そのケースでは、上述した認証シャッターを用いた制御だけでもよい。認証シャッターとTempPwの併用も可能である。

以下、TempPw（例えばtpw）が使用されない認証シャッター制御を説明する。なお、以下、説明を分かり易くするため、C^(j)として、C⁽¹⁾のみが存在し、S_i ^(j)として、S₁ ⁽¹⁾及びS₂ ⁽¹⁾を含む複数のS_i ⁽¹⁾が存在することとする。

図２７の参照符号２７００−１に示すように、S_i ⁽¹⁾は、認証シャッターの開閉を制御するシャッター管理サーバ２７０１−ｉと、認証に成功した場合にサービスを提供するサービス提供サーバ２７０２−ｉと、認証を行う認証サーバ２７０３−ｉという複数の機能を有する。すなわち、S_１ ⁽¹⁾は、シャッター管理サーバ２７０１−１、サービス提供サーバ２７０２−１、及び、認証サーバ２７０３−１を有し、S₂ ⁽¹⁾は、シャッター管理サーバ２７０１−２、サービス提供サーバ２７０２−２、及び、認証サーバ２７０３−２を有する。

シャッター管理サーバ２７０１−ｉ、サービス提供サーバ２７０２−ｉ、及び、認証サーバ２７０３−ｉのうち、シャッター管理サーバ及び認証サーバ２７０３−ｉのいずれも、複数のS_i ⁽¹⁾で共有とすることができる。

具体的には、例えば、図２７の参照符号２７００−２に示すように、認証サーバ２７０３が、S₁ ⁽¹⁾及びS₂ ⁽¹⁾の外部に存在し、且つ、認証サーバ２７０３が、S₁ ⁽¹⁾及びS₂ ⁽¹⁾に共有されてよい。更に、図２７の参照符号２７００−３に示すように、シャッター管理サーバ２７０１も、S₁ ⁽¹⁾及びS₂ ⁽¹⁾の外部に存在し、且つ、シャッター管理サーバ２７０１が、S₁ ⁽¹⁾及びS₂ ⁽¹⁾に共有されてよい。

以下、参照符号２７００−１が示す構成を例に取り、認証シャッター制御を説明する。なお、以下の説明では、S₁ ⁽¹⁾及びS₂ ⁽¹⁾のうち、S₁ ⁽¹⁾を例に取る。

認証シャッター制御では、登録手続き１、登録手続き２、認証シャッター操作手続き、ログイン手続きが行われる。

登録手続き１では、図２８の参照符号２８００−１に示すフローが行われる。

すなわち、U_Pは、リクエスト（Req_S）を、サービス提供サーバ２７０２−１に送信する（ステップ２８０１）。サービス提供サーバ２７０２−１は、そのリクエストに応答して、sysID₁ ⁽¹⁾を関連付けたユーザ追加リクエストをC⁽¹⁾に送信する（ステップ２８０２）。

C⁽¹⁾は、一意的なmID（mID₁ ⁽¹⁾）を生成し、sysID₁ ⁽¹⁾と当該アカウント（Uのアカウント）に関する情報（例えば、アカウント作成日時等、当該アカウントに関する不変の情報でC⁽¹⁾が保持するリストに保存される情報）とに対する電子署名Signを生成し、認証シャッター制御アプリケーションパス（Pass = (mID, sysID, Sign))を生成する。更に、C⁽¹⁾は、鍵を生成し、その鍵を用いてPassを暗号化する。暗号化されたPassを、E(Pass)と言う。なお、C⁽¹⁾がPassを暗号化するのはこのときの一度きりであり、そのPassを復号するのはC⁽¹⁾自身であり、かつ、Pass自体はそれほど大きなサイズにはならないので、鍵は使い捨ての鍵としてVernam暗号が採用されてもよい。

また、C⁽¹⁾が、当該アカウントに対して、ust（Uの状態）の値を、「halfway」（登録中）とする。ust（Uの状態）は、例えば、aList⁽¹⁾のOTHERSに含まれてよい。C⁽¹⁾が、snに関連付けてmID、鍵、及びustを、例えばaList⁽¹⁾に保持する。C⁽¹⁾が、sn、mID及びE(Pass)をサービス提供サーバ２７０２−１に送る（ステップ２８０３）。

サービス提供サーバ２７０２−１は、uList₁ ⁽¹⁾に、uID₁ ⁽¹⁾及びmIDを登録し、sst（認証シャッターの状態）の値を「closed」（閉の状態を意味する値）とし、period（認証シャッターがclosedの状態になる時刻）の値を、「Undefined」とする。sst及びperiodは、uList₁ ⁽¹⁾のTPWINFO及びOTHERSのうちの少なくとも一方に含まれている。その後、サービス提供サーバ２７０２−１は、sn及びE(Pass)をU_Pに送る（ステップ２８０４）。

登録手続き２では、図２８の参照符号２８００−２に示すフローが行われる。

U_Pが受信したsn及びE(Pass)は、Uにより、U_Mに入力される。U_Pが受信した情報のU_Mへの入力は、二次元バーコード等が利用されてもよいし、マニュアルでの入力が利用されてもよい。Sn及びE(Pass)は、U_Mの例えばAPPに入力される。

その後、Uにより、U_Mに、認証シャッター制御パスワード(reqPw)が入力される。ここの説明では、簡単のため、制御センタ（C）を１つとし、tReqPw = reqPwとする。U_Mは、sn、reqPw及びE(Pass)をC⁽¹⁾に送信する（ステップ２８１１）。C⁽¹⁾が、snからアカウントを特定し、そのアカウント情報として登録されているustが「halfway」の場合に限り、当該アカウントの鍵を用いてE(Pass)を復号しPassを得る。その後、C⁽¹⁾が、そのPassの正当性を検証し、正しい場合は、hreqPwの値を「h(reqPw)」（reqPwに対して不可逆変換処理を施した値）とし、ustの値を「active」（登録済を意味する値）とする（ステップ２８１２）。ustに加えて、hreqPwも、例えば、aList⁽¹⁾のOTHERSに含まれてよい。なお、ustが既に「active」の場合や、Passが正しくない場合、C⁽¹⁾が、登録失敗としてその時点で手続きを停止してよい。

Passが正しい場合、C⁽¹⁾が、そのPassをU_Mに送信する（ステップ２８１３）。U_Mは、受け取ったPassを、U_M固有情報（例えば、MACアドレス、UUID等）を鍵として暗号化した上で保存する（ステップ２８１４）。

認証シャッター操作手続き（Uが認証シャッターを開けるとき又は閉じるとき）では、図２８の参照符号２８００−３に示すフローが行われる。

U_Mが、U_M固有情報を用いて、Pass等の暗号化されている情報を復号する。U_Mは、sysID₁ ⁽¹⁾（認証シャッターを操作するサービスシステム（S₁ ⁽¹⁾）のシステムID）、操作内容（open又はclose（O/C））及びreqPwの入力をUから受け、それらの情報とPassとをC⁽¹⁾に送信する（ステップ２８２１）。

C⁽¹⁾は、Passに含まれているmIDからアカウントを特定し、Pass及びreqPwの正しさを検証する。正しい場合、C⁽¹⁾は、シャッター管理サーバ２７０１−１に、mIDおよび操作内容（O/C）を送信する（ステップ２８２２）。

シャッター管理サーバ２７０１−１は、操作内容がopenであれば、認証シャッターを閉める時刻tを決定し、Uに対応したperiod（mIDをキーに特定されるperiod）の値を「t」とする。認証シャッターを開けるタイミングは、UがこれからS₁ ⁽¹⁾を利用しようとしているときと考えられるので、「t」は、操作内容を受信してから数分先の時刻でよい。シャッター管理サーバ２７０１−１は、操作内容がcloseであれば、Uに対応したperiodの値を「Undefined」とする。

その後、シャッター管理サーバ２７０１−１は、Uに対応したsst及びperiodを更新し、periodをC⁽¹⁾に返す（ステップ２８２３）。C⁽¹⁾は、そのperiodをU_Mに送信する（ステップ２８２４）。

ログイン手続きでは、図２９に示すフローが行われる。

U_Pが、Uからの指示に応答して、uID₁ ⁽¹⁾及びpwをサービス提供サーバ２７０２−１に送信する（ステップ２９０１）。pwは、固定パスワードでもTempPwでもよい。サービス提供サーバ２７０２−１は、uID₁ ⁽¹⁾を関連付けた照会（Uに対する認証シャッターの状態の照会）をシャッター管理サーバ２７０１−１に送信する（ステップ２９０２）。

シャッター管理サーバ２７０１−１は、uID₁ ⁽¹⁾をキーとしてsst及びperiodを特定する。時刻がperiodを過ぎていない場合は、シャッター管理サーバ２７０１−１は、sstの値（「open」又は「closed」)を、サービス提供サーバ２７０２−１に返す（ステップ２９０３）。時刻がperiodを過ぎている場合は、シャッター管理サーバ２７０１−１は、sstの値として「closed」をサービス提供サーバ２７０２−１に返す。また、uID₁ ⁽¹⁾が存在しない場合、又は、periodの値が「Undefined」となっている場合は、シャッター管理サーバ２７０１−１は、sstの値として「closed」をサービス提供サーバ２７０２−１に返す。

サービス提供サーバ２７０２−１は、sstの値として「open」が返ってきた場合のみ、(uID₁ ⁽¹⁾, pw)を、認証サーバ２７０３−１に照会する（ステップ２９０４）。sstの値として「open」が返ってこなかった場合、サービス提供サーバ２７０２−１は、ログイン認証失敗として、手続きを終了してよい。

認証サーバ２７０３−１は、(uID₁ ⁽¹⁾, pw)に応じて、Yes又はNoを、サービス提供サーバ２７０２−１に返す（ステップ２９０５）。

サービス提供サーバ２７０２−１は、Yesが返ってきた場合のみ、U_Pにサービスを提供する（例えばログイン認証成功とする）。

多くのWebアプリケーションが、認証が成功した際、UのブラウザにCookieを渡すように、認証シャッター制御の場合も、認証が成功した際にサービス提供サーバ２７０２−１がU_PにCookieを渡せば、U_Pがサイト内を移動する度に認証手続きを実行する必要はない。認証成功の場合（Yesが返ってきた場合）、サービス提供サーバ２７０２−１がシャッター管理サーバ２７０１−１に認証シャッターを閉じるリクエスト(CloseShutter)を送ることにより、Uがログインした後は他者によるなりすましログインを防ぐこともできる。

図３０は、U_M又はU_Pでの画面遷移の例を示す。

参照符号３０００−１は、tpwの使用可能期間が短く使用可能回数が固定のケースの画面遷移例である。このケースでは、上述したように、一般的なotpが使用可能である。このため、例えば、Uが、U_Mの画面に、tReqPw⁽¹⁾（正確にはreqPw⁽¹⁾）と所望のサービスシステム（サービスA）を入力すれば、C⁽¹⁾により、サービスAに対してのみ使用可能なOTP「1234」が発行され、そのOTPがU_Mに表示される。

参照符号３０００−２は、tpwの使用可能期間が長く使用可能回数が無制限のケースの画面遷移例である。このケースでは、上述したように、共通のtpwが使用されるが、参照符号３０００−２は、サービス毎に異なるパスワードが発行された例を示す。例えば、Uが、U_Mの画面に、tReqPw⁽¹⁾と所望の１以上のサービスシステム（サービスA及びサービスC）を入力すれば、C⁽¹⁾により、サービスA及びサービスCにそれぞれ対応したパスワード「1234」及び「5678」が発行され、それらのパスワードがU_Mに表示される。

参照符号３０００−３は、tpwの使用可能期間が長く使用可能回数が無制限のケースの画面遷移例である。このケースでは、上述したように、pwが使用される。例えば、Uが、U_Mの画面に、tReqPw⁽¹⁾とtpwを共有する所望の１以上のサービスシステム（サービスA及びサービスC）を入力すれば、C⁽¹⁾により、サービスA及びサービスCに共通のtpw「1234」が発行され、そのtpwがU_Mに表示される。その際、図示のように、tpwに関連付けられているtpwInfoが含むperiodが表す使用期限や、そのtpwInfoが含むuID（Uにより選択されたサービスシステム毎のuID）も表示されてよい。

参照符号３０００−４は、認証シャッターの開閉のケースの画面遷移例である。例えば、Uが、U_Mの画面に、操作内容（例えばClose）と所望の１以上のサービスシステム（サービスA及びサービスC）を入力すれば、C⁽¹⁾により、サービスA及びサービスCの各々の認証シャッターの状態（sst）がUについて操作内容通りの状態にされ、その結果が、U_Mに表示される。その際、図示のように、periodの他にユーザが選択したサービスシステム毎のuIDを含んだtpwInfoがU_Mに送られ、そのtpwInfoが含むuID（Uにより選択されたサービスシステム毎のuID）も表示されてよい。

参照符号３０００−５は、認証／連携の画面遷移例である。例えば、参照符号３０００−５に示すように、Uが、U_Mの画面に、連携元サービスシステム（From）（例えば図２５のS₂ ⁽¹⁾）、連携先サービスシステム（To）（例えば図２５のS₁ ⁽¹⁾）、及び連携対象情報（例えば「X証明書」）を入力（例えば選択）し、U_M（APP）が、それらをC⁽¹⁾に送信する。ここでは、「X証明書」が、連携対象情報でもあり、情報連携において、att値でもある。つまり、この図の例では、連携対象情報は１つのatt値である。このように、Uにより所望のattが指定され、そのattについて、提供可能か受け入れ可能かの双方のチェックが行われてもよい。U_M（APP）が、C⁽¹⁾からのtpwの他に、uIDと、連携対象情報の少なくとも一部と、回答ボタン（OKボタン及びNGボタン）とを表示する。連携対象情報の鍵がユーザ端末経由で受け渡しされる場合、鍵もU_M（APP）により表示されてよい。OKボタンが押された場合、Uが、U_Pを用いて、連携先サービスシステムにアクセスしてよい。

以上、幾つかの実施例を説明したが、本発明はそれらの実施例に限定されない。

例えば、携帯端末の生体情報による認証が一般化した場合は、それとの連携を行うことにより、記憶情報を用いない２要素認証、又は、３要素認証が期待できる。例えば、U_Mの生体認証（例えば、指紋認証又は虹彩認証）を経てU_Mが使用可能になった場合、U_MからのtReqPw⁽¹⁾の生成に、Uの生体情報（例えば、指紋情報又は虹彩情報）が利用されてよい。例えば、reqPwに代えて又は加えて、Uの生体情報が利用されてよい。利用される生体情報は、U_Mにより検出された情報であってもよいし、U_Mに予め登録されている情報でもよい。

また、tpwInfo_i ^(j)は、S_i ^(j)がUに提供する画面（例えば、ログイン画面等の申請受付画面、銀行口座番号等の入力受付画面）に表示される電子的な身元証明オブジェクト（例えば、テキスト又は画像）を含んでよい。tpwInfo_i ^(j)内の身元証明オブジェクトは、U_M（APP）によりディスプレイ２１１に表示されてよい。Uは、S_i ^(j)から提供された画面に情報を入力する前に、その画面上の身元証明オブジェクトと、U_M（APP）によりディスプレイ２１１に表示された身元証明コード（tpwInfo_i ^(j)内の身元証明オブジェクト）とを比較する。それらが一致していれば、Uに提供された画面は確かにS_i ^(j)から提供された画面であることがわかる。これにより、不正なシステムに対してUが情報を提供してしまうこと（例えばフィッシングの被害に合うこと）を避けることができる。

また、tpw発行リクエスト等のtpw制御リクエストに関連付けられるsysID _i ^(j)は、Uに手動で選択されたサービスシステムのsysID _i ^(j)に代えて、pListに登録されておりU_M（APP）により自動で選択された全て（又は一部）のsysID _i ^(j)でよい。

また、tpwの制限の少なくとも１つ（例えばtpwの使用期限及び使用回数のうちの少なくとも１つ）は、サービスシステムに代えて、tpwを発行する制御センタにより決められてもよい。tpwの使用期限を例に取ると、次の通りである。すなわち、tpwの使用期限が、制御センタにより決定され、制御センタに決定された使用期限が、サービスシステムに、別の制御センタ経由で又は非経由で、送信される。具体的には、例えば、C⁽¹⁾は、tpwの使用期限を、SYSIDPart内の各々のsysID_i ^(j)について決定する（例えばステップ１４０２〜１４０４のいずれかにおいて）。使用期限は、SYSIDPart内の全てのsysID_i ^(j)について同じでもよいし、SYSIDPart内のsysID_i ^(j)毎に異なっていてよい。例えば、tpw使用期限を決定したC⁽¹⁾の配下にあるS₁ ⁽¹⁾に対応したtpw使用期限（Period₁ ⁽¹⁾）は、C⁽¹⁾からS₁ ⁽¹⁾に送信される。また、例えば、C⁽¹⁾とは別の制御センタC⁽²⁾の配下にあるS₁ ⁽²⁾に対応したtpw使用期限（Period₁ ⁽²⁾）は、C⁽¹⁾からC⁽²⁾経由又は非経由でS₁ ⁽²⁾に送信される。S_i ^(j)は、受信したtpw使用期限（Period_i ^(j)）を、tpwInfo_i ^(j)の少なくとも一部としてuList _i ^(j)に登録する（例えばステップ１４０５）。以上の処理は、tpwの使用期限以外の制限（例えば使用回数）についても適用されてよい。

また、tpwの制限の少なくとも１つ（例えばtpwの使用期限及び使用回数のうちの少なくとも１つ）は、サービスシステムに代えて、ユーザにより決められてもよい。tpwの使用期限を例に取ると、次の通りである。tpwの使用期限が、UによりU_M（APP）に入力され、U_M（APP）から制御センタに送信され、制御センタからサービスシステムに、別の制御センタ経由で又は非経由で、送信される。具体的には、例えば、U_M（APP）が、SYSIDPart内の各々のsysID_i ^(j)について、tpwの使用期限（Period_i ^(j)）の入力をUから受ける（例えばステップ１４０１）。使用期限は、SYSIDPart内の全てのsysID_i ^(j)について同じでもよいし、SYSIDPart内のsysID_i ^(j)毎に異なっていてよい。SYSIDPart内の各々のsysID_i ^(j)のtpw使用期限（Period_i ^(j)）が、U_M（APP）からC⁽¹⁾に送信される（例えばステップ１４０１）。その後、例えば、tpw使用期限をU_Mから受信したC⁽¹⁾の配下にあるS₁ ⁽¹⁾に対応したtpw使用期限（Period₁ ⁽¹⁾）は、C⁽¹⁾からS₁ ⁽¹⁾に送信される。また、例えば、C⁽¹⁾とは別の制御センタC⁽²⁾の配下にあるS₁ ⁽²⁾に対応したtpw使用期限（Period₁ ⁽²⁾）は、C⁽¹⁾からC⁽²⁾経由又は非経由でS₁ ⁽²⁾に送信される。S_i ^(j)は、受信したtpw使用期限（Period_i ^(j)）を、tpwInfo_i ^(j)の少なくとも一部としてuList _i ^(j)に登録する（例えばステップ１４０５）。以上の処理は、tpwの使用期限以外の制限（例えば使用回数）についても適用されてよい。

また、C^(j)、S_i ^(j)、U_P及びU_Mの各々が行う上述した処理の少なくとも一部は、上述したように、コンピュータプログラムをプロセッサが実行することにより行われる。また、上述した「サーバ」は、コンピュータシステムで実行される機能（例えば仮想サーバ）に代えて、物理的なサーバマシンであってもよい。C^(j)及びS_i ^(j)は、典型的には、異なる者（エンティティ）により所有又は管理されるが、同一の者により所有又は管理されてもよい。

また、少なくとも登録フェーズでのUとS_i ^(j)間のやり取りは、Webベースに限らず、紙ベースで行われてもよい。なお、上述の説明において、U_PからC^(j)へのリクエストに応答して行われる処理におけるテーブル操作によれば、テーブルにレコード（アカウント）が追加され、U_MからC^(j)へのリクエストに応答して行われる処理におけるテーブル操作によって、そのレコードに情報が登録される。

また、aID^(j)のように複数のサービスシステムを統合するキーは、U_MとC^(j)のうちの少なくとも１つに保持されてよい。

また、aID^(j)は必須ではない。例えば、S_i ^(j)が同一でもUが異なればmID_i ^(j)は異なるため、mID_i ^(j)がaID^(j)として使用されてもよい。しかし、Uが利用するS_i ^(j)の数が多い場合、Uが利用する２以上のS_i ^(j)に同一のaID^(j)を関連付けることができるので、aID^(j)の存在により効率化が期待できる。

また、U_Mが受信するtpwInfo_i ^(j)には、サービスシステム毎に（例えば、tpwの発行先のサービスシステム毎に、又は、連携対象情報の連携先サービスシステム毎に）、そのサービスシステムへのリンク（例えばURL）が含まれていてよい。U_M（又はU_P）は、tpwInfo_i ^(j)内のリンクを指定することでサービスシステムへアクセスしてもよい。なお、tpwInfo_i ^(j)に含まれるリンク（URL）には、ユーザを識別する情報が含まれていてもよい。そのリンクを指定してU_M（又はU_P）からアクセスされたサービスシステムは、入力欄に情報（例えばuIDと認証情報）が入力された画面をアクセス元のU_M（又はU_P）に提供してよい。

また、tpwが使用される少なくとも１つの実施例において、U_P（又はU_M）からS_i ^(j)に送信されるリクエスト（例えばログインリクエスト）には、tpwに加えて、そのS_i ^(j)に固有のパスワードが使用されてもよい。また、少なくとも１つの実施例において、電子署名は必須でない。

以上が、pListを使用した例を含んだ記述の一例である。制御センタ１０１が、保管システムの一例でよい。保管システムは、制御センタ１０１及びサービスシステム１０３とは別に存在してもよい。

以上の説明によれば、第１の機器（例えば、第１の機器のプロセッサで実行されるアプリケーションプログラム）が、第１の機器の所有者に固有の情報でありその所有者に関して異なる機器でも同じ情報である所有者固有情報を用いたキーで、第１の機器内の情報である機器情報を暗号化し、その暗号化機器情報を出力（例えば保存）する。所有者固有情報は、暗号化の都度に第１の機器に手動で入力されてもよいが、第１の機器（例えば第１の機器で実行されるアプリケーション）に所有者固有情報が設定されていて、暗号化の際、第１の機器が、所有者固有情報を自動的にキーに用いることが好ましい。暗号化機器情報の出力先は、第１の機器内の記憶装置（例えば、内蔵されている又は取外し可能なメモリ）でもよいし、第１の機器外の記憶装置（例えば、複数の機器と通信可能なサーバ）でもよい。出力先が、第１の機器外の記憶装置の場合、その記憶装置は、タグが関連付けられた暗号化機器情報を保管する。タグには、手動で入力された情報（例えば何らかの名前）が含まれてもよいし、機器情報の暗号化に使用されたキーに用いられた所有者固有情報が自動で含まれてもよい。

第２の機器（例えば、第２の機器のプロセッサで実行されるアプリケーションプログラム）は、暗号化機器情報を、所有者固有情報を用いたキーで復号する。例えば、第２の機器は、第１の機器、又は、第１の機器外の記憶装置から、暗号化機器情報を受信する。後者の場合、第２の機器は、記憶装置に、タグに含まれている情報が関連付いたリクエスト（例えば所有者固有情報が自動で関連付けられたリクエスト（例えばダウンロードリクエスト））を送信し、そのリクエストに応答して、その関連付いている情報を用いて特定されたタグが関連付いている暗号化機器情報を記憶装置から受信する。第２の機器は、復号した情報を、第２の機器内の記憶装置及び第２の機器外の記憶装置のうちの少なくとも１つに出力（例えば保存）してよい。

なお、所有者固有情報は、上述したように、所有者に固有の情報でありその所有者に関して異なる機器で同じ情報である。所有者固有情報は、例えば、契約者ＩＤ（例えば、キャリア（電気通信事業者）から所有者（契約者）に割り振られたＩＤ）、携帯電話番号及びメールアドレスのうちの少なくとも１つでよい。オプションとして、例えば、パスワードを含んでもよい。メールアドレスは、機器のＯＳのベンダが提供するアドレスであって機器に紐付けられたアドレスであり、例えば、Gmailアドレス（Gmailは登録商標）やAppleID（Appleは登録商標）でよい。また、所有者固有情報（uInfo）は、Uの生体情報（例えば、指紋情報又は虹彩情報）でもよい。

以下、具体例を、図３２及び図３３を参照して説明する。

図３２に示すように、Uが所有する携帯電話機器U_M（第１の機器の一例）にも、新しい携帯電話機器U’_M（第２の機器の一例）にも、所有者固有情報（uInfo）から鍵Kおよびタグtを生成するアルゴリズムを実行するバックアップAPP３２０１がインストールされている。U_M及びU’_Mの各々において、バックアップAPP３２０１は、プロセッサ２１２（図２参照）により実行される。U_M及びU’_Mにおいて、バックアップAPP３２０１（鍵Kおよびタグtを生成するアルゴリズム）は同じである。また、U_Mにおいて、pListに含まれるpass（リクエストを承認してもらうための電子的な許可証）が、機器固有情報を用いて暗号化された状態で格納されているとする。機器固有情報は、上述したように、機器に固有の情報であって、例えば、上述したように、個体識別番号（IMEI（International Mobile Equipment Identity））、ＭＡＣアドレス、製造番号及びＳＩＭ（Subscriber Identity Module）カードの製造番号である。

＜保管＞

（ステップ１）U_M（バックアップAPP３２０１）は、U_Mの機器固有情報を用いて、pList（aIDを含んだリスト）に含まれるpass（リクエスト依頼パス）を復号し、（全ての要素が機器固有情報で暗号化されていない）pListを入手する。U_M（バックアップAPP３２０１）は、入手したpListを、uInfo（又は、uInfoから計算された鍵K(=h1(uInfo))）を用いて、暗号化する。h1は、衝突困難な一方向性ハッシュ関数とするが、鍵Kの生成に使用可能な情報であれば、ハッシュ関数以外の関数であってもよいし、関数以外の情報であってもよい。

（ステップ２）U_M（バックアップAPP３２０１）は、uInfoを用いて、タグt（= h2(uInfo)）を計算する。h2は、h1と同様の変換である。

（ステップ３）U_M（バックアップAPP３２０１）は、dInfo(= (t, Enc_K(pList))を保管リクエストとして、保管システムDへ送信する。なお、dInfoは、鍵Kで暗号化されたpListと、そのpListに紐付けられたタグtとを含んだ情報である。

（ステップ４）Dは、保管リクエストに応答して、dInfoを保管（D内の記憶装置に格納）する。

＜復元＞

U_Mから保管システムDに保管されたpListを新しい携帯電話機器U’_Mに復元するために、以下の処理が行われる。

（ステップ５）U’_M（バックアップAPP３２０１）は、uInfoを用いて、鍵Kおよびタグtを計算する。

（ステップ６）U’_M（バックアップAPP３２０１）は、uInfoを用いて、引出しリクエストとしてタグtをDに送信する。

（ステップ７）Dは、引出しリクエストに応答して、タグtをもつエントリdInfoを検索する。

（ステップ８）Dは、ステップ７の検索により見つかったdInfoを、U’_Mに返す。

（ステップ９）U’_M（バックアップAPP３２０１）は、uInfo（又は、uInfoから計算された鍵K）を用いて、暗号化されたpListを復号する。

（ステップ１０）U’_M（バックアップAPP３２０１）は、復号されたpListに含まれるpassを、U’_Mの機器固有情報を用いて暗号化し、暗号化されたpassを保存する。

しかし、この復元（引出し手続き）により、同一Uであれば、クローン携帯電話機器を無制限に作成することができてしまう。

そこで、図３３に示すようなクローン対策を実施することができる。具体的には、例えば、下記の通りである。

（ステップ１０´）図３２に示したステップ９が実施された場合、ステップ１０に代えて又は加えて、このステップ１０´が実施される。ステップ１０´の実施は、ステップ９が実施された場合に自動的に（Uの指示無しに）開始される。U’_M（バックアップAPP３２０１）は、復号されたpListに含まれるpassに対するpass再発行リクエスト（reqPw）を、制御センタCに送信する。

（ステップ１１）Cは、reqPw に応答して、reqPwから特定されるpassを無効化し、reqPwに紐付いている新たなpassを生成する。

（ステップ１２）Cは、生成した新たなpassを、U’_Mに送信する。

（ステップ１３）U’_M（バックアップAPP３２０１）は、新たなpassを受信し、その新たなpassを、U’_Mの機器固有情報を用いて暗号化し、暗号化された新たなpassを保存する。なお、ステップ１０´がステップ１０に加えて実施されたものであるならば、U’_M（バックアップAPP３２０１）は、ステップ１０で保存したpassに代えて（そのpassを削除して）、暗号化された新たなpassを保存する。

以上、実施形態を説明したが、本発明はその実施形態に限定されない。

例えば、第１の機器及び第２の機器の各々は、スマートフォンのような携帯電話機器でもよいしその他の種類の機器でもよい。

また、第１の機器（例えば、紛失前又は機種変更前の携帯電話機器）から第２の機器（例えば、新たに携帯電話機器）への情報移行は、自動で行われてもよいし手動で行われてもよい。自動の場合、暗号化及び復号化のためのキーに用いられる情報として、少なくとも所有者固有情報が使用されるが、更に、第１又は第２の機器に設定されている特定の情報が使用されてもよい。手動の場合、暗号化及び復号化のためのキーに用いられる情報として、少なくとも所有者固有情報が使用され、更に、特定の情報に代えて又は加えて、手動で入力される情報（例えばパスワード）が使用されてもよい。

また、移行される情報は、pListに代えて又は加えて、機器内のいずれの情報でもよい。

１０１…制御センタ、１０３…サービスシステム、１０５…ユーザ端末

Claims (5)

1. 第１の機器で実行される第１のプログラムと、
   第２の機器で実行される第２のプログラムと
   を有し、
   前記第１のプログラムが、
   前記第１の機器の所有者に固有の情報であり前記所有者について異なる機器で同じ情報である所有者固有情報を用いたキーで、前記第１の機器内の情報である機器情報を暗号化し、
   前記暗号化された機器情報である暗号化機器情報を出力し、
   前記第２のプログラムが、
   前記暗号化機器情報を、前記所有者固有情報を用いたキーで復号する、
   機器情報移行システム。
2. 前記暗号化機器情報の出力先が、前記第１の機器外の記憶装置であり、
   前記記憶装置が、
   タグが関連付けられた前記暗号化機器情報を保管し、
   前記第２のプログラムからリクエストを受信した場合、前記リクエストに関連付いた情報と一致する情報を含んだタグが関連付いている前記暗号化機器情報を前記第２の機器に送信する、
   請求項１記載の機器情報移行システム。
3. 前記第２のプログラムが、
   前記復号により得られた機器情報が得られた場合、自動的に、その機器情報を含んだ情報であってリクエストを承認してもらうための電子的な許可証を、その電子的な許可証を発行したサーバである制御センタに、その許可証を無効化してもらうために送信し、
   前記制御センタから、前記許可証に代えて発行された新たな許可証を受信し、
   前記受信した新たな許可証を前記機器情報と共に前記第２の機器に保存する、
   請求項１又は２記載の機器情報移行システム。
4. 前記第１の機器において、前記機器情報は、前記第１の機器の機器固有情報を用いて暗号化された状態で保存されており、
   前記第２の機器において、前記第２のプログラムが、前記第２の機器の機器固有情報を用いて前記機器情報を暗号化して保存する、
   請求項１乃至３のうちのいずれか１項に記載の機器情報移行システム。
5. 第１の機器が、
   前記第１の機器の所有者に固有の情報であり前記所有者について異なる機器で同じ情報である所有者固有情報を用いたキーで、前記第１の機器内の情報である機器情報を暗号化し、
   前記暗号化された機器情報である暗号化機器情報を出力し、
   第２の機器が、
   前記暗号化機器情報を、前記所有者固有情報を用いたキーで復号する、
   機器情報移行方法。