WO2016084822A1 - 複数のサービスシステムを制御するサーバシステム及び方法 - Google Patents

Abstract

サーバシステム（C^(j)）が保持する管理情報において、各ユーザについての１以上の情報要素群の各々が、mID（C^(j)とサービスシステム（S_i ^(j)）との間で共有されユーザ毎に異なるＩＤ）を含む。C^(j)が、リクエストをユーザ端末から受信する。C^(j)が、受信したリクエストを基に１以上のサービスシステムにそれぞれ対応した１以上のmIDを、そのユーザ端末のユーザについて管理情報から特定する。C^(j)が、１以上のS_i ^(j)の各々に、特定された１以上のmIDのうちそのS_i ^(j)に対応したmIDと、そのS_i ^(j)に対する制御内容とが関連付いたリクエストを送信する。

Description

複数のサービスシステムを制御するサーバシステム及び方法

　本発明は、概して、サービスシステムの制御に関する。

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

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

　ユーザＩＤ及びパスワードの漏えいやパスワードクラッキング等により、ネットワーク上でのなりすまし犯罪が増加している。その為、サービス企業は、ユーザに対して、パスワード（及びユーザＩＤ）の厳重管理とパスワードに関しては定期的な変更を依頼している。

　しかし、インターネット上で多くのサービスを受けるユーザが、多くのパスワード（及びユーザＩＤ）を管理し（例えば、サービス毎に、パスワードを管理し）、更に、パスワードを定期的に変更することは、容易ではない。

　多くのユーザは、利用している全てのサービスシステム（サービス）について全てのパスワード（及びユーザＩＤ）を記憶できない。このため、複数のサービスシステムで同一のパスワード（及びユーザＩＤ）を使用したりノートやパーソナルコンピュータ等にサービス毎のパスワード（及びユーザＩＤ）を記録したりしているのが実情である。しかし、この方法も安全とは言えない。

　以上のような問題は、パスワード（及びユーザＩＤ）に限らず、他種の識別符号（例えば、ワンタイムパスワード）についてもあり得る。

　また、１ユーザが複数のサービスシステムを利用するにあたり下記に示すような別の問題もあり得る。

　例えば、利便性の観点では、ユーザは、第１のサービスシステムに情報を提供するために第２のサービスシステムからその情報を取得しその取得した情報を第１のサービスシステムに提供しなければならないという煩わしさがあり得る。

　また、安全性の観点では、サービスシステムに対して他人により成り済まされることを心配するユーザも存在し得る。

　複数のユーザ端末及び複数のサービスシステムと通信可能なサーバシステム（１以上の計算機）が構築される。サーバシステム（例えば制御センタ）は、各ユーザについて１以上の情報要素群を含んだ管理情報を保持する。１以上の情報要素群の各々が、サーバシステムとサービスシステムとの間で共有されユーザ毎に異なるＩＤ（mID）を含む。サーバシステムが、リクエストをユーザ端末から受信する。サーバシステムが、そのリクエストを基に１以上のサービスシステムにそれぞれ対応した１以上のmIDを、そのユーザ端末のユーザについて管理情報から特定する。サーバシステムが、その１以上のサービスシステムの各々に、特定された１以上のmIDのうちそのサービスシステムに対応したmIDと、そのサービスシステムに対する制御内容とが関連付いたリクエストを送信する。

　複数のサービスシステムの利用について安全性を確保しつつ利便性を改善できる。

実施例１に係る認証プロセスの概略を示す。 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)の構成例を示す。 実施例８に係る認証／連携フローの一例を示す。 識別符号管理の概要の一例を示す。 シャッターシステムの構成例を示す。 認登録手続き１、登録手続き２、及び、認証シャッター操作手続きの各々のフローの一例を示す。 ログイン手続きのフローの一例を示す。 画面遷移の例を示す。 実施例８に係る登録フローの一例を示す。

　以下、幾つかの実施例を説明する。

　その際、複数のサービスステムに共通の識別符号として、パスワードを例に取る。共通のパスワードには、後述するように、使用期限及び使用回数のうちの少なくとも１つのような制限が関連付けられる。実施例では、共通のパスワードは、パスワードが発行された当日間だけ無制限に使用可能なワンタイムパスワードを例に取る（実施例において、「ワンタイム」とは、使用期間が一時的及び使用回数が１回限りのうちの少なくとも前者を意味する）。以下、そのようなパスワードを、「共通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)に固有のパスワードが使用されてもよい。また、少なくとも１つの実施例において、電子署名は必須でない。

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

Claims (20)

1. 　複数のユーザ端末及び複数のサービスシステムと通信可能なサーバシステムであって、
   　管理情報を記憶する記憶部と、
   　前記記憶部に接続されたプロセッサと
   を有し、
   　前記管理情報が、各ユーザについて１以上の情報要素群を含み、前記１以上の情報要素群の各々が、サーバシステムとサービスシステムとの間で共有されユーザ毎に異なるＩＤであるmIDを含み、
   　前記プロセッサが、
   　　（Ａ）リクエストをユーザ端末から受信し、
   　　（Ｂ）前記受信したリクエストを基に１以上のサービスシステムにそれぞれ対応した１以上のmIDを、そのユーザ端末のユーザについて前記管理情報から特定し、
   　　（Ｃ）前記１以上のサービスシステムの各々に、前記特定された１以上のmIDのうちそのサービスシステムに対応したmIDと、そのサービスシステムに対する制御内容とが関連付いたリクエストを送信する、
   サーバシステム。
2. 　各ユーザについて、前記１以上の情報要素群の各々が、
   　　そのユーザが利用し得るサービスシステムのＩＤであるsysIDと、
   　　サーバシステムとそのユーザのユーザ端末との間で共有されるＩＤであるaIDと
   を更に含み、
   　（Ａ）で受信したリクエストは、識別符号の制御のリクエストでありaIDが関連付けられた識別符号制御リクエストであり、
   　（Ｂ）において、前記プロセッサは、前記受信した識別符号制御リクエストに関連付けられているaIDに関連付いた１以上のmIDを前記管理情報から特定し、
   　（Ｃ）において、前記プロセッサは、前記１以上のサービスシステムの各々に、前記１以上のサービスシステムに共通の識別符号について、前記特定された１以上のmIDのうちそのサービスシステムに対応したmIDと、識別符号の制御内容とが関連付いたリクエストを送信する、
   請求項１記載のサーバシステム。
3. 　（Ａ）で受信したリクエストには、ユーザにより選択されたサービスシステムのsysIDが関連付けられており、
   　（Ｂ）において、前記プロセッサは、前記受信した識別符号制御リクエストに関連付けられているaID及びsysIDに関連付いた１以上のmIDを前記管理情報から特定する、
   請求項２記載のサーバシステム。
4. 　前記受信した識別符号制御リクエストに関連付いているaIDは、サービスシステムを登録するための登録フェーズにおいて前記ユーザ端末に発行された電子的な許可証に関連付けられており、
   　前記受信した識別符号制御リクエストには、前記ユーザ端末にユーザにより入力されたパスワード又はそのパスワードに基づくパスワードでありそのリクエストの認証に使用されるパスワードであるtReqPwが関連付けられており、
   　前記プロセッサは、前記受信した識別符号制御リクエストから特定されたtReqPwが正しいか否かの第１の判断と、前記受信した識別符号制御リクエストに関連付いている許可証が正しいか否かの第２の判断とを行い、いずれの判断の結果も肯定の場合に、（Ｂ）を行う、
   請求項２又は３記載のサーバシステム。
5. 　前記登録フェーズにおいて、前記プロセッサが、
   　　（ａ）サービスシステムから、そのサービスシステムのsysIDを受信し、そのユーザ及びそのサービスシステムに対応したmIDと、サーバシステムのＩＤであるcIDとを、そのサービスシステムに送信し、受信したsysIDと送信したmIDとを含んだ情報要素群を前記管理情報に登録し、
   　　（ｂ）前記ユーザ端末からのリクエストに応答して、aIDと、前記ユーザ端末にユーザにより入力されたパスワード又はそのパスワードを基に生成されたパスワードであるtReqPwとを、（ａ）で登録された情報要素群に追加し、（ａ）で登録された情報要素群のＩＤであるＳＮと、その情報要素群に追加されたaIDと、cIDとを含んだ許可証を、前記ユーザ端末に送信し、
   　前記第１の判断は、前記受信した識別符号制御リクエストに関連付いている許可証から特定される情報要素群内のtReqPwと、前記受信した識別符号制御リクエストから特定されたtReqPwとが適合するか否かの判断であり、
   　前記第２の判断は、前記受信した識別符号制御リクエストに関連付いている許可証から特定される情報要素群から得られる情報と、前記受信した識別符号制御リクエストに関連付いている許可証から得られる情報とが適合するか否かの判断である、
   請求項４記載のサーバシステム。
6. 　前記tReqPwは、前記ユーザにより入力されたパスワードと前記ユーザ端末又は前記プロセッサにより決定された乱数とを用いて生成されたパスワードである、
   請求項４又は５記載のサーバシステム。
7. 　同一のaIDを含んだ２以上の情報要素群のうちの少なくとも１つの情報要素群におけるaIDは、その情報要素群に対応した登録フェーズにおいて前記プロセッサにより生成されたaIDであり、前記プロセッサは、その登録フェーズにおいて生成したaIDを、前記ユーザ端末に送信し、
   　前記２以上の情報要素群のうちの少なくとも１つの他の情報要素群におけるaIDは、その情報要素群に対応した登録フェーズにおいて前記ユーザ端末から前記プロセッサが受信したaIDであって、前記ユーザ端末が既に記憶しているaIDである、
   請求項４乃至６のうちのいずれか１項に記載のサーバシステム。
8. 　前記受信した識別符号制御リクエストは、識別符号の発行のリクエストである識別符号発行リクエストであり、
   　（Ｃ）において、前記プロセッサが、前記１以上のサービスシステムに共通の識別符号を生成し、
   　（Ｃ）において送信されるリクエストには、更に前記共通の識別符号が関連付けられ、
   　（Ｃ）において送信されるリクエストの制御内容は、前記共通の識別符号の登録であり、
   　前記共通の識別符号は、前記１以上のサービスシステムのいずれのサービスシステムに対しても前記ユーザ端末又は別のユーザ端末により入力される識別符号である、
   請求項２乃至７のうちのいずれか１項に記載のサーバシステム。
9. 　前記プロセッサが、前記１以上のサービスシステムの各々から、そのサービスシステムに登録されているuID（ユーザＩＤ）がそのサービスシステムと前記ユーザ端末との間で共有されるsuKey（暗号／復号キー）で暗号化されたものである暗号化uIDを、（Ｃ）のリクエストの応答又はそれとは別のタイミングで受信し、
   　前記プロセッサが、前記１以上のサービスシステムからそれぞれ受信した１以上の暗号化uIDを前記ユーザ端末に送信する、
   請求項２乃至８のうちのいずれか１項に記載のサーバシステム。
10. 　前記記憶部及び前記プロセッサを有する第１の識別符号制御装置と、
    　前記第１の識別符号制御装置及び複数のサービスシステムと通信可能な第２の識別符号制御装置と
    を有し、
    　前記複数のサービスシステムは、前記第１の識別符号制御装置に登録されている第１のサービスシステムと前記第２の識別符号制御装置に登録されている第２のサービスシステムとを含み、
    　前記第１の識別符号制御装置が受信した識別符号制御リクエストは、識別符号の発行のリクエストである識別符号発行リクエストであり、
    　前記識別符号発行リクエストに関連付けられている１以上のsysIDは、少なくとも第２のサービスシステムのsysIDを含み、
    　前記第１又は第２の識別符号制御装置が、前記第１の識別符号制御装置により発行された共通の識別符号についてのリクエストを、前記識別符号発行リクエストに関連付けられているsysIDに対応した第２のサービスシステムに送信する、
    請求項２乃至９のうちのいずれか１項に記載のサーバシステム。
11. 　前記第１の識別符号制御装置が、前記識別符号発行リクエストに関連付けられているsysIDのうちの、第２のサービスシステムシステムに対応したsysIDを、前記第２の識別符号制御装置に送信し、その第２のサービスシステムに対応したmIDを前記第２の識別符号制御装置から受信し、受信したmIDと前記共通の識別符号とを関連付けたリクエストを、そのmIDに対応した第２のサービスシステムに送信する、
    請求項１０記載のサーバシステム。
12. 　前記第１の識別符号制御装置が、前記識別符号発行リクエストに関連付けられているsysIDのうちの、第２のサービスシステムシステムに対応したsysIDと、前記共通の識別符号とを、前記第２の識別符号制御装置に送信し、
    　前記第２の識別符号制御装置が、その第２のサービスシステムに対応したmIDと、前記共通の識別符号とを関連付けたリクエストを、そのmIDに対応した第２のサービスシステムに送信する、
    請求項１０記載のサーバシステム。
13. 　前記第１の識別符号制御装置が、前記識別符号発行リクエストに関連付けられているsysIDのうちの、第２のサービスシステムシステムに対応したsysIDを、前記第２の識別符号制御装置に送信し、
    　前記第２の識別符号制御装置が、その第２のサービスシステムに対応したmIDを含んだ情報であるアサーションを、その第２のサービスシステムに送信し、
    　前記第１の識別符号制御装置が、前記共通の識別符号を関連付けたリクエストを、その第２のサービスシステムに送信する、
    請求項１０記載のサーバシステム。
14. 　前記サービスシステムへ送信したリクエストに対し前記サービスシステムから受信した応答が、前記サービスシステムが保持する情報であって別のサービスシステムに公開することが許可されている情報要素を含む、
    請求項１乃至１３のうちのいずれか１項に記載のサーバシステム。
15. 　（Ａ）で受信したリクエストは、連携元サービスシステムの連携対象情報を連携先サービスシステムと共有することである情報連携を表しており、
    　（Ａ）で受信したリクエストが情報連携を表している場合、
    　　（Ｂ）において特定された１以上のmIDは、連携対象情報の連携先サービスシステムのmIDを含み、
    　　（Ｃ）において、前記プロセッサが、連携対象情報のリクエストであって、連携元サービスシステムのＩＤが関連付けられたリクエストを、連携元サービスシステムに送信する、
    請求項１乃至１４のうちのいずれか１項に記載のサーバシステム。
16. 　前記プロセッサが、
    　　（Ｐ）前記連携元サービスシステムから連携対象情報を受信し、
    　　（Ｑ）前記受信した連携対象情報を前記連携先サービスシステムが取得可能になる前に、前記連携対象情報を前記ユーザ端末に送信し、
    　　（Ｒ）前記受信した連携対象情報の連携ＮＧの回答を前記ユーザ端末から受信した場合、前記連携対象情報が前記連携先サービスシステムに取得されることを不可能にする、
    請求項１５記載のサーバシステム。
17. 　前記プロセッサが、
    　　前記受信した連携対象情報が暗号化されている場合、その連携対象情報を復号すること無しに、格納又は送信し、
    　　前記受信した連携対象情報が暗号化されていない場合、その連携対象情報のマルウェアの有無をチェックする、
    請求項１６記載のサーバシステム。
18. 　（Ｃ）で送信される１以上のリクエストの各々に関連付けられている制御内容は、認証シャッターのopen又はclosedである、
    請求項１乃至１７のうちのいずれか１項に記載のサーバシステム。
19. 　複数のサービスシステムと通信可能なサーバシステムと、
    　ユーザ端末で実行されるアプリケーションプログラムであり前記サーバシステムと通信するＡＰＰと
    を有し、
    　前記サーバシステムが、１以上の情報要素群を含む管理情報を記憶し、前記１以上の情報要素群の各々が、前記サーバシステムとサービスシステムとの間で共有されユーザ毎に異なるＩＤであるmIDを含み、
    　前記サーバシステムが、
    　　（Ａ）リクエストを前記ＡＰＰから受信し、
    　　（Ｂ）前記受信したリクエストを基に１以上のサービスシステムにそれぞれ対応した１以上のmIDを、そのユーザ端末のユーザについて前記管理情報から特定し、
    　　（Ｃ）前記１以上のサービスシステムの各々に、前記特定された１以上のmIDのうちそのサービスシステムに対応したmIDと、そのサービスシステムに対する制御内容とが関連付いたリクエストを送信する、
    システム。
20. 　各ユーザについて１以上の情報要素群を含んだ管理情報を保持し、前記１以上の情報要素群の各々が、サーバシステムとサービスシステムとの間で共有されユーザ毎に異なるＩＤであるmIDを含み、
    　リクエストをユーザ端末から受信し、
    　前記受信したリクエストを基に１以上のサービスシステムにそれぞれ対応した１以上のmIDを、そのユーザ端末のユーザについて前記管理情報から特定し、
    　前記１以上のサービスシステムの各々に、前記特定された１以上のmIDのうちそのサービスシステムに対応したmIDと、そのサービスシステムに対する制御内容とが関連付いたリクエストを送信する、
    方法。

Images