JP2006302323A - 入会審査のための処理システムおよび方法 - Google Patents

Abstract

【課題】ユーザが複数の会員制サービスを利用する場合に、各サービスの入会審査に関する処理を効率化することが課題である。
【解決手段】サーバ４２のサービス管理ＤＢ５２には、複数のサービスの加入条件が蓄積される。証明書管理部５１は、各サービスの加入条件に基づき、複数のサービスの中からユーザが利用できるサービスを選別して表示する。また、各サービスのサーバに代わって、入会希望ユーザが既に加入している他のサービスの情報を参照することで、そのユーザの入会審査を行う。さらに、各サービスの加入条件に基づいて、新たな加入条件とユーザ数の関係のシミュレーションを行う。
【選択図】 図１０

Description

本発明は、インターネット等のネットワークを介した会員制サービスに係り、ユーザが複数のサービスを利用する際、各サービスの入会審査に関する処理を行うシステムおよび方法に関する。

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

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

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

しかしながら、上述した従来のサービスシステムには、次のような問題がある。
１人のユーザが複数の会員制サービスを利用する場合、サービス毎に入会審査を受ける必要があり、そのために指定された個人情報を端末から入力しなければならない。したがって、利用サービスの数が多くなると、ユーザの負担が増大する。

また、各サービスを提供する事業体は、ユーザ毎に入会審査を行う必要があり、そのためにユーザから送られた個人情報を分析しなければならない。したがって、入会希望ユーザの数が多くなると、入会審査の負荷が増大する。

さらに、各事業体は、新たなサービスを開始するとき、どの程度の会員が集められるかを予測しながら、入会審査に用いる条件を設定する必要がある。このとき、設定条件と会員数の関係を効率良く分析するシステムが望まれる。

本発明の課題は、ユーザが複数の会員制サービスを利用する場合に、各サービスの入会審査に関する処理を効率化するシステムおよび方法を提供することである。

図１は、本発明の処理システムの原理図である。
本発明の第１の局面において、処理システムは、格納手段２１、選別手段２２、および提示手段２３を備える。格納手段２１は、複数のサービスの加入条件を格納する。選別手段２２は、複数のサービスの加入条件のうち、ユーザが加入済みのサービスの加入条件と未加入のサービスの加入条件とを比較して、ユーザが加入可能なサービスを選別する。提示手段２３は、得られた加入可能なサービスの情報をユーザに提示する。

ユーザが加入可能なサービスの情報を希望したとき、選別手段２２は、格納手段２１に格納された加入条件から、そのユーザが加入済みのサービスの加入条件と未加入のサービスの加入条件を抽出する。そして、それらを比較することにより、未加入のサービスから加入可能なサービスを選別して、選別結果を提示手段２３に渡す。提示手段２３は、受け取った選別結果に含まれる加入可能なサービスの一覧を、ユーザに提示する。

このような処理システムによれば、ユーザは、入会審査を受ける前に、加入可能なサービスの一覧を取得することができる。したがって、すべての未加入サービスの入会審査を受けなくても、加入可能サービスを絞り込むことができ、その中から加入サービスを効率良く選択することができる。

また、本発明の第２の局面において、処理システムは、格納手段２１、判定手段２４、および判断手段２５を備える。格納手段２１は、あるサービスの入会審査のための判断基準情報として、他のサービスの識別情報を格納する。判定手段２４は、ユーザがあるサービスへの入会を希望するとき、ユーザが他のサービスを利用しているか否かを判定する。判断手段２５は、ユーザが他のサービスを利用しているとき、そのユーザがあるサービスへの入会資格を有すると判断する。

ユーザがあるサービスへの入会を希望するとき、判定手段２４は、格納手段２１に格納された、そのサービスの入会審査のための判断基準情報を参照して、その判断基準情報に含まれる他のサービスの識別情報を取得する。そして、その識別情報に基づいて、ユーザが他のサービスを利用しているか否かを判定し、判定結果を判断手段２５に渡す。その判定結果が、ユーザが他のサービスを利用していることを表すとき、判断手段２５は、そのユーザが入会資格を有すると判断する。

このような処理システムによれば、ユーザが新たなサービスに入会するとき、ユーザの個人情報の代わりに、同じような加入条件を設定している他のサービスへの入会状況に基づいて、入会資格の有無を判断することができる。したがって、入会審査が簡便化され、サービス運用者の負荷が軽減される。

また、本発明の第３の局面において、処理システムは、格納手段２１、設定手段２６、シミュレーション手段２７、および出力手段２８を備える。格納手段２１は、既存のサービスの加入条件を格納する。設定手段２６は、新たな加入条件を設定する。シミュレーション手段２７は、既存のサービスの加入条件と新たな加入条件とを比較して、新たな加入条件で加入可能なユーザの数に関する情報を求める。出力手段２８は、得られた情報を出力する。

サービス運用者は、サービスの加入条件とユーザ数の関係を分析したいとき、設定手段２６を用いて、新たな加入条件を設定する。シミュレーション手段２７は、格納手段２１に格納された既存のサービスの加入条件と、設定された加入条件とを比較して、設定された加入条件を有するサービスに加入可能なユーザの数等を求める。そして、出力手段２８は、設定された加入条件と得られたユーザの数の関係を出力する。

このような処理システムによれば、サービス運用者は、新たなサービスを開始するとき、あるいは、既存のサービスの加入条件を変更するときに、加入可能なユーザの数を考慮しながら、入会審査に用いる加入条件を効率良く設定することができる。したがって、サービス運用者の負荷が軽減される。

例えば、図１の格納手段２１は、後述する図１０のサービス管理ＤＢ５２に対応し、選別手段２２、提示手段２３、判定手段２４、判断手段２５、設定手段２６、シミュレーション手段２７、および出力手段２８は、図１０の証明書管理部５１に対応する。

また、本発明の別の局面において、処理システムは、格納手段２１、設定手段２６、シミュレーション手段２７、および出力手段２８を備える。格納手段２１は、既存のサービスの加入条件を含むサービステーブルを格納する。設定手段２６、新たな加入条件を設定する。シミュレーション手段２７は、サービステーブルを参照して既存のサービスの加入条件を取得し、取得した加入条件と新たな加入条件とを比較して、新たな加入条件で加入可能なユーザの数に関する情報を求める。出力手段２８は、得られた情報を出力する。

本発明によれば、ユーザが複数の会員制サービスから加入サービスを選択する際、加入可能なサービスを効率良く絞り込むことができる。また、サービス運用者による入会審査や加入条件設定の作業が効率化される。したがって、入会審査に関する処理において、ユーザおよびサービス運用者の負荷が軽減される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ｐ３７：サーバ４２は、対応する利用サービス管理テーブルを参照して、通知されたシリアル番号に対応する利用可能サービスＩＤを取得し、それをサーバ４３に返す。
Ｐ３８：サーバ４３は、受け取った各サービスＩＤに対応する表示領域を含む、画面描画用のレイアウトデータをユーザ端末５０に送る。このレイアウトデータは、ＨＴＭＬ（hypertext markup language ）、ＸＭＬ（extensible markup language）等で記述される。

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

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

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

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

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

次に、図１２から図２６までを参照しながら、図１０の認証局のサーバ４２により行われる、入会審査に関する処理について説明する。サーバ４２のサービス管理ＤＢ５２には、複数のサービスの入会審査基準情報が蓄積され、証明書管理部５１は、それらの入会審査基準情報を参照しながら、加入可能サービス表示処理、入会審査処理、および加入条件シミュレーション処理を行う。

加入可能サービス表示処理では、各サービスの入会審査基準情報に基づき、複数のサービスの中から特定ユーザが利用できるサービスを選別して表示する。入会審査処理では、各サービスのサーバに代わって、入会希望ユーザが既に加入している他のサービスの情報を参照することで、そのユーザの入会審査を行う。加入条件シミュレーション処理では、各サービスの入会審査基準情報に基づいて、新たな入会審査基準のシミュレーションを行う。

図１２は、サービス管理ＤＢ５２に格納されるサービステーブルの例を示しており、図１３は、サービス管理ＤＢ５２に格納される入会判断テーブルの例を示している。これらのテーブルは、サービス毎に生成される。

図１２のサービステーブルには、サービスＩＤ、会社ＩＤ、サービスに対するユーザの加入条件１〜ｔ、サービス分野、サービス名称、サービス概要、加入申込みＵＲＬ（uniform resource locator）、および加入問い合わせｅメールアドレスが登録されている。このうち、加入条件１〜ｔが入会審査基準情報に対応し、このサービスの場合は、性別、年令、年収、勤務先等が加入条件として設けられている。ここでは、４０才以下で年収６００万円以上の女性がサービスに加入することができる。

また、図１３の入会判断テーブルには、サービスＩＤと判断基準が登録されている。判断基準は、会社ＩＤと、その会社が提供しているサービスのサービスＩＤを含む。この入会判断テーブルは、入会希望ユーザによる他の会社のサービス加入状況に基づいて、そのユーザの入会可否を判断するために用いられる。

図１３の判断基準によれば、会社“ａａａａａ”のサービス“＊＊＊＊Ｂ”および“＊＊＊＊Ｃ”とともに、会社“ｂｂｂｂｂ”のいずれかのサービスを利用しているユーザ、または、会社“ｃｃｃｃｃ”のサービス“＊＊＊＊Ｄ”を利用しているユーザに対して、入会が許可される。

ただし、サービスＩＤの内容（番号配列）から会社を特定できる場合は、必ずしも会社ＩＤを保持する必要はない。また、入会判断テーブルの判断基準を満たさないユーザについては、サービステーブルの加入条件に基づいて、通常の入会審査が行われる。

図１４は、ユーザまたはサービス運用者が認証局のサーバ４２にアクセスしたときに表示されるメニュー画面の例を示している。図１４のメニューには、加入可能サービス表示９１、入会審査９２、および加入条件シミュレーション９３の項目が含まれている。ユーザが共通証明書を提示して、加入可能サービス表示９１を指定すると、サービス表示処理が行われる。また、サービス運用者が入会審査９２を指定すると、入会審査処理が行われ、加入条件シミュレーション９３を指定すると、加入条件シミュレーション処理が行われる。

ただし、メニュー画面は、加入者用画面とサービス運用者用画面に分類して表示することもあり得る。この場合、ユーザまたはサービス運用者が利用可能な項目のみが画面に表示される。

図１５および図１６は、サーバ４２の証明書管理部５１による加入可能サービス表示処理のフローチャートである。証明書管理部５１は、まず、ユーザから提示された共通証明書のシリアル番号に基づいて、証明書管理ＤＢ３５の対応する利用サービス管理テーブルを参照し、登録されているサービスＩＤを取得する（図１５のステップＳ２１）。

そして、取得したサービスＩＤの数を判定する（ステップＳ２２）。これらのサービスＩＤは、そのユーザが既に加入済みのサービスを表している。サービスＩＤが複数であれば、サービス管理ＤＢ５２を参照して、それらのサービスＩＤに対応するサービステーブルから加入条件を抽出し、複数のサービスの加入条件をＡＮＤ処理により合算する（ステップＳ２３）。そして、得られた条件を加入済みサービスの条件として記録する。また、サービスＩＤが１つの場合は、対応するサービステーブルの加入条件を、加入済みサービスの条件として記録する。

次に、加入済みサービス以外の未加入サービスのサービステーブルの１つを呼び出し（ステップＳ２４）、加入済みサービスの条件を、未加入サービスの対応する条件と比較する（ステップＳ２５）。加入済みサービスの条件が未加入サービスの条件を満たさなければ、ステップＳ２４の処理を繰り返す。

加入済みサービスの条件が未加入サービスの条件を満たせば、次に、呼び出されたサービステーブルに他の加入条件が設定されているか否かをチェックする（ステップＳ２６）。他の条件が設定されていなければ、すぐに加入可能と判断し、メモリ上のバッファ領域に設けられた、すぐに加入可能なサービスの一覧テーブルに、その未加入サービスの分野、名称、および概要を記録する（ステップＳ２７）。

次に、未加入サービスのサービステーブルが終了したか否かを判定し、そのようなサービステーブルが残っていれば、ステップＳ２４以降の処理を繰り返す。また、ステップＳ２６において、他の条件が設定されていれば、条件付きで加入可能と判断し、バッファ領域に設けられた、条件付きで加入可能なサービスの一覧テーブルに、その未加入サービスの分野、名称、概要、および設定されている他の条件を記録する（ステップＳ２９）。そして、ステップＳ２８以降の処理を行う。

そして、ステップＳ２８において、未加入サービスのサービステーブルが終了すると、ステップＳ２７およびＳ２９で生成された一覧テーブルの内容を、図１７のようなサービス選択画面として、ユーザ端末５０に表示する（ステップＳ３０）。

図１７のサービス選択画面には、ユーザが現在加入しているサービスと、新たに加入可能なサービスとが表示されている。このうち、新たに加入可能なサービスは、すぐに加入可能なサービスと、条件付きで加入可能なサービスとに分けて表示される。

このようなサービス選択画面において、ユーザがいずれかの未加入サービスを選択すると（図１６のステップＳ３１）、証明書管理部５１は、対応するサービステーブルを参照して、そのサービスの加入申込みＵＲＬを取得し、ユーザ端末５０に送信する（ステップＳ３２）。これにより、ユーザの画面は選択されたサービスのサイトにジャンプして、加入申込み画面が表示される（ステップＳ３３）。その後、ユーザは、加入申込み画面の指示に従って、申込みを行う。

ユーザは、加入申込み画面から申込みを行う代わりに、選択したサービスのサイトに加入問い合わせｅメールを送ることもできる。この場合、ステップＳ３２およびＳ３３において、証明書管理部５１は、対応するサービステーブルから加入問い合わせｅメールアドレスを取得し、ユーザ端末に表示する。

このような加入可能サービス表示処理によれば、ユーザは、入会審査を受ける前に、加入可能な未加入サービスの一覧を取得することができる。したがって、すべての未加入サービスの入会審査を受けなくても、加入可能サービスを絞り込むことができ、その中から加入サービスを選択することができる。

図１８および図１９は、証明書管理部５１による入会審査処理のフローチャートである。まず、証明書管理部５１は、図２０のような条件入力画面を、サービス運用者の端末（例えば、サービスを提供するサーバ）に表示し、入会審査判断情報の入力を促す（図１８のステップＳ４１）。これに応じて、サービス運用者は、入会希望ユーザの共通証明書のシリアル番号と、そのユーザが希望しているサービスのサービスＩＤを入力する。

次に、証明書管理部５１は、サービス管理ＤＢ５２を参照して、入力されたサービスＩＤに対応する入会判断テーブルを検索する（ステップＳ４２）。ここで、サービス事業体があらかじめ入会判断テーブルを登録していれば、その入会判断テーブルを呼び出す。

次に、証明書管理ＤＢ３５を参照して、入力されたシリアル番号に対応する利用サービス管理テーブルを検索する（ステップＳ４３）。そして、対応する利用サービス管理テーブルがなければ、ユーザが見つからないこと、または、ユーザが他のサービスを利用していないことを通知するメッセージを表示して（ステップＳ４４）、処理を終了する。

また、対応する利用サービス管理テーブルがあれば、それを呼び出し、次に、利用サービス管理テーブルに登録されたサービスＩＤと入会判断テーブルの判断基準とを比較する（ステップＳ４５）。そして、サービスＩＤが入会判断テーブルの判断基準を満たせば、入会資格ありと判断し、図２１のような判断結果画面を表示して（ステップＳ４６）、処理を終了する。

サービス事業体があらかじめ入会判断テーブルを登録していなければ、ステップＳ４２において、対応する入会判断テーブルが見つからないので、図１９の処理が行われる。また、ステップＳ４５において、サービスＩＤが判断基準を満たさない場合も、図１９の処理が行われる。

図１９のステップＳ４７およびＳ４８の処理は、図１８のステップＳ４３およびＳ４４の処理と同様である。また、図１９のステップＳ４９およびＳ５０の処理は、図１５のステップＳ２２およびＳ２３の処理と同様である。

ステップＳ４９およびＳ５０の処理により、加入済みサービスの条件が記録されると、次に、サービス運用者から提供されたサービスＩＤに対応する対象サービスのサービステーブルを呼び出し（図１９のステップＳ５１）、加入済みサービスの条件を、対象サービスの対応する条件と比較する（ステップＳ５２）。

加入済みサービスの条件が対象サービスの条件を満たさなければ、入会資格なしと判断し、図２２のような判断結果画面を表示して（ステップＳ５３）、処理を終了する。図２２の画面には、入会資格があるとは判断できないことを通知するメッセージが表示されている。さらに、入会審査を続行するにはユーザから個人情報を入手する必要があることを通知するメッセージを追加してもよい。

加入済みサービスの条件が対象サービスの条件を満たせば、次に、呼び出されたサービステーブルに他の加入条件が設定されているか否かをチェックする（ステップＳ５４）。他の条件が設定されていなければ、入会資格ありと判断し、図２１のような判断結果画面を表示して（ステップＳ５５）、処理を終了する。

他の条件が設定されていれば、その条件を取得する（ステップＳ５６）。そして、条件付きで入会資格ありと判断し、図２３のような判断結果画面を表示して（ステップＳ５７）、処理を終了する。図２３の画面には、設定された他の条件が、明確にすべき追加条件として表示されている。

このように、認証局がユーザの利用可能サービスを集中管理し、そのユーザが新たなサービスに加入するときに、サービス事業体に代わって入会審査を行うことで、入会審査のためのサービス運用者の負荷が軽減される。例えば、銀行サービスと保険サービスの利用資格があるユーザには、クレジットサービスの従来の入会審査を省略することが可能になる。

図２４は、証明書管理部５１による加入条件シミュレーション処理のフローチャートである。まず、証明書管理部５１は、図２５のようなシミュレーション画面を、サービス運用者の端末に表示し、シミュレーション対象となる加入条件の入力を促す（ステップＳ６１）。これに応じて、サービス運用者は、性別、年令、年収等の条件を入力し、試算ボタン１０１を押す。

次に、証明書管理部５１は、メモリ上のバッファ領域に、入力された加入条件を有する仮想サービステーブルを作成し（ステップＳ６２）、サービス管理ＤＢ５２から既存のサービステーブルの１つを呼び出す（ステップＳ６３）。そして、仮想サービステーブルの条件を、既存のサービステーブルの対応する条件と比較する（ステップＳ６４）。

仮想サービステーブルの条件が既存のサービステーブルの条件を満たさなければ、ステップＳ６３の処理を繰り返す。仮想サービステーブルの条件が既存のサービステーブルの条件を満たせば、次に、既存のサービステーブルに他の加入条件が設定されているか否かをチェックする（ステップＳ６５）。他の条件が設定されていれば、ステップＳ６３以降の処理を繰り返す。

他の条件が設定されていなければ、証明書管理ＤＢ３５を参照して、既存のサービステーブルに記録されたサービスＩＤを登録している利用サービス管理テーブルを検索する。そして、そのような利用サービス管理テーブルの１つから共通証明書のシリアル番号を取得し（ステップＳ６６）、メモリ上のバッファ領域に設けられた、図２６のような加入者カウントテーブルに、そのシリアル番号が登録されているか否かをチェックする（ステップＳ６７）。

シリアル番号が既に登録されていれば、ステップＳ６６以降の処理を繰り返し、それがまだ登録されていなければ、加入者カウントテーブルに追加する。次に、既存のサービステーブルが終了したか否かをチェックし（ステップＳ６９）、既存のサービステーブルが残っていれば、ステップＳ６３以降の処理を繰り返す。

そして、既存のサービステーブルが終了すると、次に、加入者カウントテーブルに登録されたシリアル番号の数をカウントし（ステップＳ７０）、その結果をシミュレーション画面に表示して（ステップＳ７１）、処理を終了する。

図２５の画面では、カウントされたシリアル番号の数が、入力された条件に対する加入可能ユーザの数として表示されており、発行済みの共通証明書の総数に対する加入可能ユーザの割合が、百分率として表示されている。サービス運用者は、入力条件を変更しながらシミュレーションを繰り返すことで、所望のユーザ数に対応する加入条件を決定することができる。ただし、加入可能ユーザの数と割合のうち、一方のみを画面に表示することもあり得る。

このような加入条件シミュレーション処理によれば、サービス運用者は、新たなサービスを開始するとき、あるいは、既存のサービスの加入条件を変更するときに、入会審査に用いる加入条件と会員数の関係をシミュレートしながら、加入条件を効率良く設定することができる。したがって、サービス運用者の負荷が軽減される。

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

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

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

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

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

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

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

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

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

本発明の処理システムの原理図である。 証明書の発行と審査を示す図である。 証明書の失効を示す図である。 証明書による認証を示す図である。 証明書管理テーブルを示す図である。 利用サービス管理テーブルを示す図である。 ユーザ情報管理テーブルを示す図である。 証明書の発行／失効処理のフローチャートである。 証明書の審査処理のフローチャートである。 サービスシステムの構成図である。 複数サービスの利用例を示す図である。 サービステーブルを示す図である。 入会判断テーブルを示す図である。 認証局のメニューを示す図である。 サービス表示処理のフローチャート（その１）である。 サービス表示処理のフローチャート（その２）である。 サービス選択画面を示す図である。 入会審査処理のフローチャート（その１）である。 入会審査処理のフローチャート（その２）である。 条件入力画面を示す図である。 第１の判断結果画面を示す図である。 第２の判断結果画面を示す図である。 第３の判断結果画面を示す図である。 シミュレーション処理のフローチャートである。 シミュレーション画面を示す図である。 加入者カウントテーブルを示す図である。 情報処理装置の構成図である。 記録媒体を示す図である。 従来のサービスシステムを示す図である。

符号の説明

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

Claims (4)

1. 既存のサービスの加入条件を含むサービステーブルを格納する格納手段と、
   新たな加入条件を設定する設定手段と、
   前記サービステーブルを参照して前記既存のサービスの加入条件を取得し、取得した加入条件と前記新たな加入条件とを比較して、該新たな加入条件で加入可能なユーザの数に関する情報を求めるシミュレーション手段と、
   得られた情報を出力する出力手段と
   を備えることを特徴とする処理システム。
2. 前記既存のサービスを利用している複数のユーザの証明書情報を登録する登録手段をさらに備え、前記シミュレーション手段は、前記新たな加入条件が前記既存のサービスの加入条件を満たすとき、該証明書情報の数をカウントして、前記加入可能なユーザの数を求めることを特徴とする請求項１記載の処理システム。
3. コンピュータのためのプログラムを記録した記録媒体であって、
   前記プログラムは、
   新たな加入条件を設定し、
   既存のサービスの加入条件を含むサービステーブルを格納する格納手段から、該既存のサービスの加入条件を取得し、
   取得した加入条件と前記新たな加入条件とを比較して、該新たな加入条件で加入可能なユーザの数に関する情報を求め、
   得られた情報を出力する
   処理を前記コンピュータに実行させることを特徴とするコンピュータ読み取り可能な記録媒体。
4. サービスの加入条件とユーザ数の関係のシミュレーションを行う処理方法であって、
   設定手段が、新たな加入条件を設定し、
   シミュレーション手段が、既存のサービスの加入条件を含むサービステーブルを格納する格納手段から、該既存のサービスの加入条件を取得し、
   前記シミュレーション手段が、取得した加入条件と前記新たな加入条件とを比較して、該新たな加入条件で加入可能なユーザの数に関する情報を求め、
   出力手段が、得られた情報を出力する
   ことを特徴とする処理方法。

Images