JP2002007344A - 複数のサービスのための認証システムおよび方法 - Google Patents

Abstract

(57)【要約】 【課題】 ネットワーク上の複数のサービスのための認
証処理において、ユーザの負担を軽減することが課題で
ある。 【解決手段】 ユーザ３１は、共通証明書をサービスＡ
のサーバ３２に提示し（Ｐ２１）、サーバ３２は、提示
された共通証明書のシリアル番号を認証局３４に通知す
る。認証局３４は、証明書管理ＤＢ３５を参照して、通
知されたシリアル番号が登録されており、かつ、サービ
スＡが利用可能であれば、ＯＫを返す。これを受けて、
サーバ３２は、サービスＡをユーザ３１に提供する（Ｐ
２２）。同様にして、ユーザ３１が共通証明書をサービ
スＢのサーバ３３に提示すると（Ｐ２３）、サーバ３３
は、サービスＢをユーザ３１に提供する（Ｐ２４）。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、インターネット等
のネットワークを介したサービスに係り、ユーザが複数
のサービスを利用する際に、ユーザ認証を行う認証シス
テムおよびその方法に関する。

【０００２】

【従来の技術】ネットワーク上のサービスを提供する提
供者は、サービス料金の課金等のために、アクセスして
きたユーザの認証を行う必要がある。従来のサービスシ
ステムでは、１人のユーザが複数のサービスを利用する
場合、各サービスが指定する認証方法をユーザ自らが使
い分けていた。

【０００３】図１４は、このような従来のサービスシス
テムを示している。２つのサービスＡ、Ｂを利用すると
き、ユーザ１１は、まず、サービスＡ用の識別情報（Ｉ
Ｄ）とパスワード（ＰＷＤ）をサービスＡのサーバ１２
に送る。サーバ１２は、ユーザ管理データベース（ユー
ザ管理ＤＢ）１３を参照してユーザ認証を行った後、ユ
ーザ１１にサービスＡを提供する。

【０００４】次に、ユーザ１１は、サービスＢ用のＩＤ
およびパスワードをサービスＢのサーバ１４に送る。サ
ーバ１４は、ユーザ管理ＤＢ１５を参照してユーザ認証
を行った後、ユーザ１１にサービスＢを提供する。こう
して、ユーザ１１は、ネットワークサービスＡ、Ｂを利
用することができる。

【０００５】

【発明が解決しようとする課題】しかしながら、上述し
た従来のサービスシステムには、次のような問題があ
る。

【０００６】１人のユーザが複数のネットワークサービ
スを利用する場合、各サービスが発行するＩＤおよびパ
スワードを使い分ける必要があり、非常に不便である。
特に、サービス毎に異なるＩＤおよびパスワードを用い
る場合、ユーザは複数のＩＤおよびパスワードを記憶し
ておき、サービス利用時に端末から入力しなければなら
ない。したがって、利用サービスの数が多くなると、ユ
ーザの負担が増大する。

【０００７】また、従来のＩＤおよびパスワードによる
認証方法に基づいて、１つのサービスがユーザのＩＤお
よびパスワードを登録し、ユーザがそれらを用いて他の
サービスを利用することも考えられる。しかし、各サー
ビスの事業体が異なれば、異なる事業体間で互いにパス
ワードを教え合うことになり、このような認証方法は、
セキュリティの観点から、事実上、実現が困難である。

【０００８】本発明の課題は、複数のサービスのための
認証処理において、各サービスが発行しているパスワー
ド等を互いに知らせることなく、ユーザの負担を軽減す
る認証システムおよびその方法を提供することである。

【０００９】

【課題を解決するための手段】図１は、本発明の認証シ
ステムの原理図である。図１の認証システムは、登録手
段２１、受信手段２２、判定手段２３、および許可手段
２４を備える。

【００１０】登録手段２１は、複数のサービスに共通の
証明書情報を登録する。受信手段２２は、ユーザがそれ
らの複数のサービスのうちの１つのサービスにアクセス
するとき、そのユーザの証明書情報を受け取る。判定手
段２３は、受け取ったユーザの証明書情報が、登録され
た共通の証明書情報に対応するか否かを判定する。許可
手段２４は、ユーザの証明書情報が共通の証明書情報に
対応するとき、アクセスされたサービスの利用を許可す
る。

【００１１】ユーザは、あらかじめ発行された、複数の
サービスに共通の証明書情報を保持しており、それらの
サービスのうちの１つを利用するとき、ユーザ端末から
証明書情報を送出する。

【００１２】受信手段２２は、送られた証明書情報を受
け取ると、その情報を判定手段２３に渡し、判定手段２
３は、受け取った証明書情報を、登録手段２１に登録さ
れた証明書情報と比較して、両者が互いに対応するか否
かを判定する。判定結果は許可手段２４に渡され、許可
手段２４は、判定結果が２つの証明書情報が互いに対応
することを示していれば、ユーザに対してサービスの利
用を許可する。

【００１３】このような認証システムによれば、ユーザ
は、各サービス固有のＩＤおよびパスワードの代わり
に、単一の証明書情報を用いて、複数のサービスを利用
することができる。したがって、複数のＩＤおよびパス
ワードを扱う必要がなくなり、ユーザの負担が軽減され
る。

【００１４】例えば、図１の登録手段２１は、後述する
図２のユーザ情報管理テーブル３６、３７に対応し、図
１の受信手段２２、判定手段２３、および許可手段２４
は、図２のサーバ３２、３３に対応する。あるいはま
た、図１の登録手段２１は、図２の証明書管理ＤＢ３５
に対応し、図１の受信手段２２、判定手段２３、および
許可手段２４は、図２の認証局３４に対応する。

【００１５】

【発明の実施の形態】以下、図面を参照しながら、本発
明の実施の形態を詳細に説明する。本実施形態の認証シ
ステムでは、独立した複数のネットワークサービスに対
して、ユーザが１つのデジタル証明書を提示すること
で、それらのサービスの利用が許可される。このデジタ
ル証明書は、所定の認証方法により認証されたユーザの
みに対して発行され、そのユーザが複数のサービスを利
用可能であることを表す。

【００１６】デジタル証明書は、ＩＴＵ−Ｔ（Internat
ional Telecommunication Union Telecommunication St
andardization Sector）の仕様Ｘ．５０９に基づき、ユ
ーザ名、証明書発行者名、シリアル番号、ユーザの公開
鍵等の情報を統合したデータに、認証局（Certificate
Authority ）のデジタル署名を施すことで生成される。
この証明書は、中に収められている公開鍵がそこに記さ
れたユーザのものであることを証明している。

【００１７】図２は、このような認証システムにおける
デジタル証明書の発行と審査を示している。図２におい
て、サービスＡ、Ｂは、ＩＤおよびパスワードを用いる
会員制サービスに対応し、それぞれ、サーバ３２、３３
からユーザ３１に対して提供される。認証局３４は、こ
れらのサービスの事業体とは独立した証明書発行機関で
あり、ユーザ３１に対して、サービスＡ、Ｂに共通のデ
ジタル証明書（共通証明書）を発行する。

【００１８】共通証明書を用いた認証を可能にするため
には、あらかじめ、認証局３４がユーザ３１に対してそ
の共通証明書を発行する必要がある。ここでは、認証局
３４は、サービスＡを介して共通証明書を発行し、サー
ビスＢに対する最初のアクセス時に、サーバ３３がその
共通証明書を審査する。サーバ３２、３３は、それぞ
れ、ユーザ情報管理テーブル３６、３７を保持してお
り、これらのテーブルには、あらかじめ、ユーザ３１の
ＩＤ、パスワード等が登録されている。この場合、以下
のシーケンスに従って処理が行われる。

【００１９】Ｐ１：ユーザ３１は、サービスＡ用のＩＤ
およびパスワードをサーバ３２に送る。サーバ３２は、
ユーザ情報管理テーブル３６を参照してユーザ認証を行
い、認証結果がＯＫであれば、認証局３４に共通証明書
の発行を依頼する。

【００２０】Ｐ２：サーバ３２は、認証局３４から共通
証明書を受け取り、それをユーザ３１に対して発行す
る。この段階では、ユーザ３１が保持する共通証明書
は、サービスＡを利用する資格のみを有し、認証局３４
の証明書管理ＤＢ３５には、共通証明書の識別情報（例
えば、シリアル番号）とともに、対応するユーザ名と、
サービスＡが利用可能であることを示す情報が登録され
る。また、ユーザ情報管理テーブル３６には、ＩＤおよ
びパスワードとともに、その共通証明書のシリアル番号
（Ｓｅｒ．Ｎｏ．）が登録される。

【００２１】Ｐ３：ユーザ３１は、発行された共通証明
書をサーバ３３に提示する。 Ｐ４：サーバ３３は、提示された共通証明書ではサービ
スＢが利用できないと判断し、ユーザ３１にサービスＢ
用のＩＤおよびパスワードを要求する。

【００２２】Ｐ５：ユーザ３１は、サービスＢ用のＩＤ
およびパスワードをサーバ３３に送る。 Ｐ６：サーバ３３は、ユーザ情報管理テーブル３７を参
照してユーザ認証を行い、認証結果がＯＫであれば、サ
ービスＢをユーザ３１に提供する。これ以降、ユーザが
保持する共通証明書でも、サービスＢの利用が可能とな
る。この段階では、ユーザが保持する共通証明書は、サ
ービスＡとサービスＢを利用する資格を有し、証明書管
理ＤＢ３５には、サービスＡ、Ｂが利用可能であること
を示す情報が登録される。また、ユーザ情報管理テーブ
ル３７には、ＩＤおよびパスワードとともに、共通証明
書のシリアル番号が登録される。

【００２３】ここでは、Ｐ１およびＰ５の処理におい
て、ＩＤおよびパスワードによるユーザ認証を行ってい
るが、指紋情報、声紋情報、画像情報等による他の認証
方法を用いてもよい。また、ユーザは、サービスの利用
中止を希望する場合、共通証明書の失効またはサービス
の利用禁止の手続きを行う。共通証明書の失効手続きを
行う場合、図３に示すように、以下のシーケンスに従っ
て処理が行われる。

【００２４】Ｐ１１：ユーザ３１は、サービスＡ用のＩ
Ｄおよびパスワード、あるいは共通証明書を、サーバ３
２に送る。 Ｐ１２：ＩＤおよびパスワードを受け取った場合、サー
バ３２は、ユーザ情報管理テーブル３６を参照してユー
ザ認証を行い、認証結果がＯＫであれば、その旨をユー
ザ３１に通知する。また、共通証明書を受け取った場
合、サーバ３２は、後述する認証方法でユーザ認証を行
い、認証結果をユーザ３１に通知する。

【００２５】Ｐ１３：ユーザ３１は、サーバ３２に対し
て、保持している共通証明書の失効依頼を行う。サーバ
３２は、認証局３４に共通証明書のシリアル番号を通知
し、失効処理を依頼する。認証局３４は、証明書管理Ｄ
Ｂ３５からその共通証明書の情報を削除し、サーバ３２
は、ユーザ情報管理テーブル３６からその共通証明書の
シリアル番号を削除する。

【００２６】Ｐ１４：その後、ユーザ３１は、保持して
いる共通証明書を、認証情報としてサーバ３３に提示す
る。サーバ３３は、提示された共通証明書のシリアル番
号を認証局３４に通知し、その共通証明書の正当性を問
い合わせる。

【００２７】Ｐ１５：認証局３４は、通知されたシリア
ル番号が証明書管理ＤＢ３５に登録されていないため、
チェック結果がＮＧであることをサーバ３３に通知す
る。サーバ３３は、ユーザ情報管理テーブル３７からそ
の共通証明書のシリアル番号を削除し、サービスＢが利
用不可であることをユーザ３１に通知する。

【００２８】図４は、発行された共通証明書を用いたユ
ーザ認証を示している。この場合、以下のシーケンスに
従ってサービスが提供される。 Ｐ２１：ユーザ３１は、保持している共通証明書を、認
証情報としてサーバ３２に提示する。サーバ３２は、提
示された共通証明書のシリアル番号を認証局３４に通知
し、その共通証明書のチェックを依頼する。認証局３４
は、証明書管理ＤＢ３５を参照して、通知されたシリア
ル番号が登録されているか否かをチェックする。そし
て、そのシリアル番号が登録されており、かつ、サービ
スＡが利用可能であれば、チェック結果としてＯＫを返
す。

【００２９】Ｐ２２：サーバ３２は、認証局３４からＯ
Ｋが返されると、サービスＡをユーザ３１に提供する。 Ｐ２３：ユーザ３１は、保持している共通証明書を、認
証情報としてサーバ３３に提示する。サーバ３３は、サ
ーバ３２と同様にして、認証局３４からチェック結果を
受け取る。

【００３０】Ｐ２４：サーバ３３は、認証局３４からＯ
Ｋが返されると、サービスＢをユーザ３１に提供する。
ここでは、ユーザが２つのサービスを利用する場合につ
いて説明したが、３つ以上のサービスを利用する場合も
同様である。また、サーバ３２、３３は、提示された共
通証明書が失効しているか否かを確認するために、認証
局３４に対して共通証明書のチェックを依頼している
が、このチェックを省略することも可能である。

【００３１】この場合、失効処理において、認証局３４
は、失効した共通証明書のシリアル番号を、関連するす
べてのサービスのサーバに通知し、各サーバは、ユーザ
情報管理テーブルからそのシリアル番号を削除する。そ
して、ユーザから共通証明書が提示されたとき、そのシ
リアル番号が対応するユーザ情報管理テーブルに登録さ
れていれば、認証結果をＯＫとし、それが登録されてい
なければ、認証結果をＮＧとする。

【００３２】図２、３、および４に示した認証システム
によれば、ユーザは、各サービス固有のＩＤおよびパス
ワードを使用することなく、単一の証明書を提示するだ
けで、複数のサービスを利用することができる。したが
って、複数のＩＤおよびパスワードを暗記したり、サー
ビス利用時に毎回ＩＤおよびパスワードを入力したりす
る必要がなくなり、ユーザの負担が大きく軽減される。

【００３３】ところで、証明書管理ＤＢ３５には、例え
ば、図５のような証明書管理テーブルと、図６のような
利用サービス管理テーブルが格納される。図５の証明書
管理テーブルには、共通証明書のシリアル番号、ユーザ
の氏名、住所、およびｅメールアドレスが登録されてお
り、図６の利用サービス管理テーブルには、共通証明書
のシリアル番号および利用可能サービスＩＤが登録され
ている。証明書管理テーブルおよび利用サービス管理テ
ーブルは、共通証明書毎に生成される。

【００３４】また、図７は、ユーザ情報管理テーブル３
６、３７の例を示している。図７のユーザ情報管理テー
ブルには、ユーザＩＤ、パスワード、ユーザの氏名、住
所、および共通証明書のシリアル番号が登録されてい
る。ユーザ情報管理テーブルは、ユーザ毎に生成され
る。

【００３５】図８は、ユーザ３１がサービスＡのサーバ
３２に対して、共通証明書の発行または失効を依頼する
場合の処理のフローチャートである。まず、ユーザ３１
は、サーバ３２にアクセスし（ステップＳ１）、サーバ
３２は、ユーザ端末にログイン画面を表示する（ステッ
プＳ２）。次に、ユーザ３１は、サービスＡ用のＩＤお
よびパスワードを入力し（ステップＳ３）、サーバ３２
は、ユーザ情報管理テーブル３６を参照して、入力され
たＩＤおよびパスワードをチェックする（ステップＳ
４）。

【００３６】ＩＤおよびパスワードが正しくなければ、
サーバ３２は、ステップＳ２以降の処理を繰り返す。Ｉ
Ｄおよびパスワードが正しければ、次に、ユーザ情報管
理テーブル３６を参照して、対応するユーザに対して共
通証明書が発行されているか否かをチェックする（ステ
ップＳ５）。

【００３７】ユーザ情報管理テーブル３６に、そのユー
ザの共通証明書のシリアル番号が登録されていなけれ
ば、共通証明書が発行されていないと判断し、認証局３
４に共通証明書の発行を依頼する（ステップＳ６）。

【００３８】これを受けて、認証局３４は、共通証明書
を発行する（ステップＳ７）。このとき、認証局３４
は、共通証明書のシリアル番号とユーザ情報を記録した
証明書管理テーブルを生成し、共通証明書のシリアル番
号とサービスＡのＩＤを記録した利用サービス管理テー
ブルを生成する。そして、それらのテーブルを証明書管
理ＤＢ３５に格納する。

【００３９】次に、サーバ３２は、発行された共通証明
書をユーザ３１に配布し、ユーザ情報管理テーブル３６
に、共通証明書のシリアル番号を記録して（ステップＳ
８）、処理を終了する。

【００４０】ステップＳ５において、ユーザ情報管理テ
ーブル３６に共通証明書のシリアル番号が登録されてい
れば、共通証明書が発行済みであることをユーザ３１に
通知し、失効を希望するか否かを問い合わせる（ステッ
プＳ９）。ユーザ３１が失効を希望しなければ、そのま
ま処理を終了する。

【００４１】ユーザ３１が失効を希望すれば、登録され
ている共通証明書のシリアル番号を認証局３４に通知
し、失効処理を依頼する（ステップＳ１０）。これを受
けて、認証局３４は、通知されたシリアル番号に対応す
る証明書管理テーブルおよび利用サービス管理テーブル
を削除し、処理結果をサーバ３２に通知する。そして、
サーバ３２は、ユーザ情報管理テーブル３６からその共
通証明書のシリアル番号を削除し、共通証明書が失効し
たことをユーザ３１に通知して、処理を終了する。

【００４２】次に、図９は、ユーザ３１がサービスＢの
サーバ３３に対して、保持している共通証明書の審査を
依頼する場合の処理のフローチャートである。まず、ユ
ーザ３１は、サーバ３３にアクセスし（ステップＳ１
１）、共通証明書を提示する（ステップＳ１２）。

【００４３】次に、サーバ３３は、提示された共通証明
書のシリアル番号がユーザ情報管理テーブル３７に登録
されているか否かをチェックする（ステップＳ１３）。
そして、そのシリアル番号が登録されていなければ、ス
テップＳ１４〜Ｓ１６において、図８のステップＳ２〜
Ｓ４と同様の処理を行う。

【００４４】ステップＳ１６において、ＩＤおよびパス
ワードが正しければ、次に、サーバ３３は、提示された
共通証明書のシリアル番号を認証局３４に通知し、その
共通証明書によるサービスＢの利用許可を要請する（ス
テップＳ１７）。

【００４５】これを受けて、認証局３４は、通知された
シリアル番号に対応する利用サービス管理テーブルにサ
ービスＢのＩＤを追加し、サービスＢが利用可能になっ
たことをサーバ３３に通知する（ステップＳ１８）。そ
して、サーバ３３は、ユーザ情報管理テーブル３７に、
共通証明書のシリアル番号を記録して（ステップＳ１
９）、処理を終了する。

【００４６】ステップＳ１３において、共通証明書のシ
リアル番号がユーザ情報管理テーブル３７に登録されて
いれば、次に、サービスＢの利用を禁止するか否かをユ
ーザ３１に問い合わせる（ステップＳ２０−１）。そし
て、ユーザ３１が利用禁止を希望しなければ、そのまま
処理を終了する。

【００４７】ユーザ３１が利用禁止を希望すれば、次
に、提示された共通証明書のシリアル番号をユーザ情報
管理テーブル３７から削除し（ステップＳ２０−２）、
その共通証明書の利用可能サービスからサービスＢを抹
消するように、認証局３４に依頼する（ステップＳ２０
−３）。

【００４８】これを受けて、認証局３４は、対応する利
用サービス管理テーブルからサービスＢのサービスＩＤ
を削除し、サービスＢを抹消したことをサーバ３３に通
知する（ステップＳ２０−４）。そして、サーバ３３
は、サービスＢの利用が禁止されたことをユーザ３１に
通知して、処理を終了する。

【００４９】以上の説明では、証明書管理テーブルと利
用サービス管理テーブルを別々に設けているが、これら
のテーブルの情報を１つのテーブルにまとめて格納して
もよい。

【００５０】次に、図１０および図１１を参照しなが
ら、インターネット上の会員制サービスであるｎｉｆｔ
ｙにおいて、本発明の認証システムを適用した例を説明
する。現在、ｎｉｆｔｙと連動して各種分野のポータル
サイト（portal site ）を構築し、多くの企業のサービ
スを提供する動きが見られる。ポータルサイトは、イン
ターネットの入口となる巨大なＷｅｂサイトであり、様
々なサービスサイトへのリンクを保持している。しか
し、複数の独立したサービスをポータルサイトに集中さ
せると、認証の煩雑さが大きな問題となる。これは、ｎ
ｉｆｔｙに限らず、どのポータルサイトでも起こり得る
問題である。このような場合に、上述した共通認証の仕
組みを用いれば、複数のサービスによる認証が簡便化さ
れる。

【００５１】図１０は、金融関連サービスを提供するポ
ータルサイトＦｉｎａｎｃｅ＠ｎｉｆｔｙを含むサービ
スシステムの構成図である。図１０のサービスシステム
は、インターネット４１、認証局のサーバ４２、＠ｎｉ
ｆｔｙ会員サービスのサーバ４３、銀行のサーバ４４、
クレジット会社のサーバ４５、保険会社のサーバ４６、
インターネットショップのサーバ４７、電力会社のサー
バ４８、ガス会社のサーバ４９、およびユーザ端末５０
を含む。

【００５２】ここで、＠ｎｉｆｔｙ、銀行、クレジット
会社、保険会社、インターネットショップ、電力会社、
およびガス会社は、それぞれ、独立した会員制サービス
を提供する事業体に相当する。

【００５３】認証局のサーバ４２は、証明書管理ＤＢ３
５、証明書管理部５１、およびサービス管理ＤＢ５２を
備える。証明書管理ＤＢ３５は、各共通証明書の証明書
管理テーブルおよび利用サービス管理テーブルを格納
し、証明書管理部５１は、証明書管理ＤＢ３５を用い
て、共通証明書の発行、チェック、失効等の処理を行
う。また、サービス管理ＤＢ５２は、各サービスに関す
る情報を格納し、証明書管理部５１は、サービス管理Ｄ
Ｂ５２を用いて、各サービスの入会審査に関する処理を
行う。

【００５４】また、＠ｎｉｆｔｙ会員サービスのサーバ
４３は、会員画面制御部６１、請求管理部６２、ユーザ
管理ＤＢ６３、画面レイアウトＤＢ６４、および請求情
報ＤＢ６５を備える。ユーザ管理ＤＢ６３は、各ユーザ
のユーザ情報管理テーブルを格納し、画面レイアウトＤ
Ｂ６４は、会員サービス画面のデータを格納し、請求情
報ＤＢ６５は、サーバ４７、４８、４９等から収集され
る請求金額のデータを格納する。

【００５５】会員画面制御部６１は、ユーザ管理ＤＢ６
３および画面レイアウトＤＢ６４を用いて、ユーザ端末
５０上の画面表示を制御し、請求管理部６２は、請求情
報ＤＢ６５を用いて、請求金額の表示を制御する。

【００５６】例えば、ユーザ端末５０の画面に表示され
たＦｉｎａｎｃｅ＠ｎｉｆｔｙのページ７１は、会員サ
ービス８１および証明書８２の項目を含む。そして、ユ
ーザがこれらの項目を指定すると、ユーザ端末５０が保
持している共通証明書が自動的にサーバ４３に送られ、
認証が行われて、会員メニューのページ７２が表示され
る。このページ７２には、公共料金決済サービス８３、
明細表示サービス８４、転居手続きサービス８５、およ
び会員設定８６の項目が含まれている。

【００５７】このうち、ユーザが公共料金決済サービス
８３を選択すると、共通証明書がサーバ４４に送られ、
認証が行われて、公共料金決済のページ７３が表示され
る。このページ７３には、口座振替申込み８７、インタ
ーネット個別払い８８、および銀行決済申込み８９の項
目が含まれている。

【００５８】また、ユーザが明細表示サービス８４を選
択すると、ユーザの金融情報の明細を示すページ７４が
表示される。このとき、必要に応じて、共通証明書がサ
ーバ４４、４５等にも送られ、認証が行われる。

【００５９】このページ７４のレイアウトデータは、会
員画面制御部６１から提供され、請求金額のデータは、
請求管理部６２から提供される。さらに、銀行口座の残
高データは、銀行のサーバ４４から提供され、クレジッ
トカードの請求明細のデータは、クレジット会社のサー
バ４５から提供される。

【００６０】図１１は、図１０のサービスシステムにお
いて、ユーザが明細表示サービス８４を利用する場合の
シーケンスを示している。この処理においては、以下の
シーケンスに従って、＠ｎｉｆｔｙ、銀行、クレジット
会社等の複数の事業体のサービスが複合的に提供され
る。

【００６１】Ｐ３１：ユーザは、共通証明書を提示し
て、ユーザ端末５０からＦｉｎａｎｃｅ＠ｎｉｆｔｙの
サイトにアクセスする。 Ｐ３２：＠ｎｉｆｔｙのサーバ４３は、提示された共通
証明書のシリアル番号を、認証局のサーバ４２に通知す
る。

【００６２】Ｐ３３：サーバ４２は、証明書管理ＤＢ３
５の対応する利用サービス管理テーブルを参照し、その
共通証明書で＠ｎｉｆｔｙ会員サービスが利用可能であ
れば、チェック結果としてＯＫを返す。

【００６３】Ｐ３４：サーバ４３は、会員メニュー７２
を表示する。 Ｐ３５：ユーザは、会員メニュー７２から明細表示サー
ビスを選択する。 Ｐ３６：サーバ４３は、共通証明書のシリアル番号を認
証局のサーバ４２に通知して、利用可能サービスを問い
合わせる。

【００６４】Ｐ３７：サーバ４２は、対応する利用サー
ビス管理テーブルを参照して、通知されたシリアル番号
に対応する利用可能サービスＩＤを取得し、それをサー
バ４３に返す。

【００６５】Ｐ３８：サーバ４３は、受け取った各サー
ビスＩＤに対応する表示領域を含む、画面描画用のレイ
アウトデータをユーザ端末５０に送る。このレイアウト
データは、ＨＴＭＬ（hypertext markup language ）、
ＸＭＬ（extensible markuplanguage）等で記述され
る。

【００６６】Ｐ３９：ユーザ端末５０は、共通証明書を
提示して、Ａ銀行のサーバに明細情報を問い合わせる。 Ｐ４０：Ａ銀行のサーバは、提示された共通証明書のシ
リアル番号を、認証局のサーバ４２に通知する。

【００６７】Ｐ４１：サーバ４２は、証明書管理ＤＢ３
５の対応する利用サービス管理テーブルを参照し、その
共通証明書でＡ銀行のサービスが利用可能であれば、チ
ェック結果としてＯＫを返す。

【００６８】Ｐ４２：Ａ銀行のサーバは、ユーザ口座の
残高データを、明細情報としてユーザ端末５０に送る。 Ｐ４３〜Ｐ４６：Ｂ銀行のサーバも、Ａ銀行のサーバと
同様にして、共通証明書による認証に基づいて、ユーザ
口座の残高データをユーザ端末５０に送る。

【００６９】こうして、ユーザ端末５０の画面に、明細
ページ７４が表示される。クレジット会社のサーバ４５
や保険会社のサーバ４６も、同様のシーケンスで、明細
ページ７４に明細情報を提供することができる。

【００７０】図１０のサービスシステムによれば、各サ
ービスが別々に保持している口座残高や請求金額等の明
細情報を、１つのレイアウト画面上に統合して表示する
ことができ、複数のサービスの横断利用が可能になる。
図１０においては、認証局の機能が各サービスから独立
しているが、この機能を＠ｎｉｆｔｙ会員サービスの中
に取り込んでもよい。

【００７１】図１０のサーバ４２〜４９およびユーザ端
末５０は、例えば、図１２に示すような情報処理装置
（コンピュータ）を用いて構成することができる。図１
２の情報処理装置は、ＣＰＵ（中央処理装置）９１、メ
モリ９２、入力装置９３、出力装置９４、外部記憶装置
９５、媒体駆動装置９６、およびネットワーク接続装置
９７を備え、それらはバス９８により互いに接続されて
いる。

【００７２】メモリ９２は、例えば、ＲＯＭ（read onl
y memory）、ＲＡＭ（random access memory）等を含
み、処理に用いられるプログラムとデータを格納する。
ＣＰＵ９１は、メモリ９２を利用してプログラムを実行
することにより、必要な処理を行う。

【００７３】例えば、図１０の証明書管理部５１、会員
画面制御部６１、および請求管理部６２は、プログラム
により記述されたソフトウェアコンポーネントとしてメ
モリ９２に格納される。

【００７４】入力装置９３は、例えば、キーボード、ポ
インティングデバイス、タッチパネル等であり、オペレ
ータ（サービス運用者またはユーザ）からの指示や情報
の入力に用いられる。出力装置９４は、例えば、ディス
プレイ、プリンタ、スピーカ等であり、オペレータへの
問い合わせや処理結果の出力に用いられる。

【００７５】外部記憶装置９５は、例えば、磁気ディス
ク装置、光ディスク装置、光磁気ディスク（magneto-op
tical disk）装置、テープ装置等である。情報処理装置
は、この外部記憶装置９５に、上述のプログラムとデー
タを保存しておき、必要に応じて、それらをメモリ９２
にロードして使用する。また、外部記憶装置９５は、図
１０の証明書管理ＤＢ３５、サービス管理ＤＢ５２、ユ
ーザ管理ＤＢ６３、画面レイアウトＤＢ６４、および請
求情報ＤＢ６５としても利用される。

【００７６】媒体駆動装置９６は、可搬記録媒体９９を
駆動し、その記録内容にアクセスする。可搬記録媒体９
９としては、メモリカード、フロッピー（登録商標）デ
ィスク、ＣＤ−ＲＯＭ（compact disk read only memor
y ）、光ディスク、光磁気ディスク等、任意のコンピュ
ータ読み取り可能な記録媒体が用いられる。オペレータ
は、この可搬記録媒体９９に上述のプログラムとデータ
を格納しておき、必要に応じて、それらをメモリ９２に
ロードして使用する。

【００７７】ネットワーク接続装置９７は、インターネ
ット４１等の任意の通信ネットワークに接続され、通信
に伴うデータ変換を行う。また、情報処理装置は、上述
のプログラムとデータをネットワーク接続装置９７を介
して他の装置から受け取り、必要に応じて、それらをメ
モリ９２にロードして使用する。

【００７８】図１３は、図１２の情報処理装置にプログ
ラムとデータを供給することのできるコンピュータ読み
取り可能な記録媒体を示している。可搬記録媒体９９や
外部のデータベース１００に保存されたプログラムとデ
ータは、メモリ９２にロードされる。そして、ＣＰＵ９
１は、そのデータを用いてそのプログラムを実行し、必
要な処理を行う。

【００７９】以上説明した実施形態においては、ＩＴＵ
−Ｔの仕様Ｘ．５０９に基づくデジタル証明書を認証情
報として用いているが、必要に応じて、他の仕様の証明
書情報を用いてもよい。

【００８０】

【発明の効果】本発明によれば、複数のサービスに共通
の１つの認証情報により、各サービスによる認証が可能
になる。このため、ユーザは、各サービスが発行するＩ
Ｄおよびパスワードを使い分ける必要がなくなり、ユー
ザの負担が軽減される。また、異なるサービス間でパス
ワード等を互いに知らせる必要がなく、セキュリティが
保持される。

【図面の簡単な説明】

【図１】本発明の認証システムの原理図である。

【図２】証明書の発行と審査を示す図である。

【図３】証明書の失効を示す図である。

【図４】証明書による認証を示す図である。

【図５】証明書管理テーブルを示す図である。

【図６】利用サービス管理テーブルを示す図である。

【図７】ユーザ情報管理テーブルを示す図である。

【図８】証明書の発行／失効処理のフローチャートであ
る。

【図９】証明書の審査処理のフローチャートである。

【図１０】サービスシステムの構成図である。

【図１１】複数サービスの利用例を示す図である。

【図１２】情報処理装置の構成図である。

【図１３】記録媒体を示す図である。

【図１４】従来のサービスシステムを示す図である。

【符号の説明】

１１、３１ ユーザ １２、３２ サービスＡのサーバ １３、１５ ユーザ管理ＤＢ １４、３３ サービスＢのサーバ ２１ 登録手段 ２２ 受信手段 ２３ 判定手段 ２４ 許可手段 ３４ 認証局 ３５ 証明書管理ＤＢ ３６、３７ ユーザ情報管理テーブル ４１ インターネット ４２ 認証局のサーバ ４３ ＠ｎｉｆｔｙ会員サービスのサーバ ４４ 銀行のサーバ ４５ クレジット会社のサーバ ４６ 保険会社のサーバ ４７ インターネットショップのサーバ ４８ 電力会社のサーバ ４９ ガス会社のサーバ ５０ ユーザ端末 ５１ 証明書管理部 ５２ サービス管理ＤＢ ６１ 会員画面制御部 ６２ 請求管理部 ６３ ユーザ管理ＤＢ ６４ 画面レイアウトＤＢ ６５ 請求情報ＤＢ ７１ ｆｉｎａｎｃｅ＠ｎｉｆｔｙのページ ７２ 会員メニューのページ ７３ 公共料金決済のページ ７４ 明細ページ ８３ 公共料金決済サービス ８４ 明細表示サービス ８５ 転居手続きサービス ８６ 会員設定 ８７ 口座振替申込み ８８ インターネット個別払い ８９ 銀行決済申込み ９１ ＣＰＵ ９２ メモリ ９３ 入力装置 ９４ 出力装置 ９５ 外部記憶装置 ９６ 媒体駆動装置 ９７ ネットワーク接続装置 ９８ バス ９９ 可搬記録媒体 １００ データベース

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5B085 AE02 AE03 BA07 BC01 5J104 AA07 AA09 EA05 KA01 MA01 NA05 PA07 PA10

Claims (8)

【特許請求の範囲】
1. 【請求項１】 複数のサービスに共通の証明書情報を登
   録する登録手段と、 ユーザが前記複数のサービスのうちの１つのサービスに
   アクセスするとき、該ユーザの証明書情報を受け取る受
   信手段と、 前記ユーザの証明書情報が前記共通の証明書情報に対応
   するか否かを判定する判定手段と、 前記ユーザの証明書情報が前記共通の証明書情報に対応
   するとき、前記１つのサービスの利用を許可する許可手
   段とを備えることを特徴とする認証システム。
2. 【請求項２】 前記１つのサービスのための識別情報と
   パスワード情報を格納する格納手段と、該識別情報とパ
   スワード情報に基づいて前記ユーザを認証する認証手段
   と、該ユーザが認証されたとき、前記共通の証明書情報
   を該ユーザに発行する発行手段とをさらに備えることを
   特徴とする請求項１記載の認証システム。
3. 【請求項３】 前記１つのサービスのための識別情報と
   パスワード情報を格納する格納手段と、該識別情報とパ
   スワード情報に基づいて前記ユーザを認証する認証手段
   と、該ユーザが認証されたとき、前記共通の証明書情報
   を失効させる失効手段とをさらに備えることを特徴とす
   る請求項１記載の認証システム。
4. 【請求項４】 前記複数のサービスを、前記共通の証明
   書情報により利用可能なサービスとして登録する利用サ
   ービス管理手段をさらに備えることを特徴とする請求項
   １記載の認証システム。
5. 【請求項５】 ユーザが１つのサービスにアクセスする
   とき、該１つのサービスを含む複数のサービスに共通の
   証明書情報を送出する送信手段と、 前記共通の証明書情報に基づいて前記ユーザが認証され
   たとき、前記１つのサービスの提供を受けるサービス利
   用手段とを備えることを特徴とする端末装置。
6. 【請求項６】 コンピュータのためのプログラムを記録
   した記録媒体であって、 前記プログラムは、 ユーザが１つのサービスにアクセスするとき、該ユーザ
   の証明書情報を受け取り、 前記ユーザの証明書情報が、あらかじめ登録された、前
   記１つのサービスを含む複数のサービスに共通の証明書
   情報に対応するか否かを判定し、 前記ユーザの証明書情報が前記共通の証明書情報に対応
   するとき、前記１つのサービスの利用を許可する処理を
   前記コンピュータに実行させることを特徴とするコンピ
   ュータ読み取り可能な記録媒体。
7. 【請求項７】 複数のサービスに共通の証明書情報をあ
   らかじめ登録し、 ユーザが前記複数のサービスのうちの１つのサービスに
   アクセスするとき、該ユーザの証明書情報が前記共通の
   証明書情報に対応するか否かを判定し、 前記ユーザの証明書情報が前記共通の証明書情報に対応
   するとき、該ユーザに対して前記１つのサービスの利用
   を許可することを特徴とする認証方法。
8. 【請求項８】 ユーザが１つのサービスにアクセスする
   とき、該ユーザの証明書情報を受け取り、 前記ユーザの証明書情報が、あらかじめ登録された、前
   記１つのサービスを含む複数のサービスに共通の証明書
   情報に対応するか否かを判定し、 前記ユーザの証明書情報が前記共通の証明書情報に対応
   するとき、前記１つのサービスの利用を許可する処理を
   コンピュータに実行させるためのプログラム。