(57)【要約】【課題】複数の通信事業者のいずれかが保持している契約者情報を用いて、効率的にユーザの属性情報の認証を行うための制御装置、制御方法及び制御プログラムを提供すること。【解決手段】ＡＰＩ変換装置１０は、ユーザ端末２０の端末情報のグループそれぞれに対して、ユーザが複数の通信事業者のそれぞれと契約している確率を示す信頼度データを記憶する通信事業者ＤＢ１１と、端末情報を伴い、複数の通信事業者のいずれかの有するユーザの属性情報が指定条件を満たすか否かの認証要求を、標準ＡＰＩで受信し、認証結果を返信するサービス実行制御部１３と、端末情報に基づいて信頼度データによって推定される通信事業者の順位を判定する判定部１５と、順位が高い通信事業者から順に、認証要求を当該通信事業者の認証サーバ４０の固有ＡＰＩへ変換し、認証結果を標準ＡＰＩに変換するＡＰＩ変換部１６とを備える。【選択図】図１
2015053007.tif 000002
【特許請求の範囲】
【請求項１】
通信端末の識別データのグループそれぞれに対して、当該グループ内の通信端末のユーザが複数の通信事業者のそれぞれと契約している確率を示す第１の信頼度データを記憶する記憶部と、
ユーザが利用している通信端末の識別データを伴い、前記複数の通信事業者のいずれかの有する当該ユーザの属性情報が指定条件を満たすか否かの認証要求を、所定の共通フォーマットで受信する受信部と、
前記識別データに基づいて、前記第１の信頼度データによって前記ユーザが契約していると推定される通信事業者の順位を判定する判定部と、
前記属性情報を有する通信事業者から認証結果が得られるか、又は前記複数の通信事業者の全てに対して認証要求を行うまで、前記判定部により算出された順位が高い通信事業者から順に、前記認証要求を当該通信事業者に固有のフォーマットに変換して当該通信事業者の認証システムへ送信し、前記認証結果を受信すると当該認証結果を所定の共通フォーマットに変換する変換部と、
前記共通フォーマットに変換された認証結果を、前記認証要求の送信元へ返信する送信部と、を備える制御装置。
【請求項２】
前記認証結果に応じて前記第１の信頼度データを更新する更新部を備える請求項１に記載の制御装置。
【請求項３】
前記更新部は、前記通信端末が属するグループに対する前記第１の信頼度データによって判定された最上位の通信事業者とは異なる通信事業者から、前記属性情報を有すると判定される認証結果が得られた場合、当該通信端末に対する第２の信頼度データを、前記第１の信頼度データとは別に記憶する請求項２に記載の制御装置。
【請求項４】
前記更新部は、前記第２の信頼度データが所定量を超えた場合、当該第２の信頼度データを削除すると共に、前記第１の信頼度データを更新する請求項３に記載の制御装置。
【請求項５】
前記認証要求は、当該認証要求の送信元であるサービス事業者を識別する事業者データを含み、
前記事業者データが前記認証要求への返答を許可された所定のデータであることを認証する認証部を備える請求項１から請求項４のいずれかに記載の制御装置。
【請求項６】
前記識別データは、電話番号、ＩＰアドレス及びＨＴＴＰユーザエージェントのいずれかを含む請求項１から請求項５のいずれかに記載の制御装置。
【請求項７】
コンピュータによる認証要求の制御方法であって、
前記コンピュータは、通信端末の識別データのグループそれぞれに対して、当該グループ内の通信端末のユーザが複数の通信事業者のそれぞれと契約している確率を示す第１の信頼度データを記憶し、
ユーザが利用している通信端末の識別データを伴い、前記複数の通信事業者のいずれかの有する当該ユーザの属性情報が指定条件を満たすか否かの認証要求を、所定の共通フォーマットで受信する受信ステップと、
前記識別データに基づいて、前記第１の信頼度データによって前記ユーザが契約していると推定される通信事業者の順位を判定する判定ステップと、
前記属性情報を有する通信事業者から認証結果が得られるか、又は前記複数の通信事業者の全てに対して認証要求を行うまで、前記判定ステップにおいて算出された順位が高い通信事業者から順に、前記認証要求を当該通信事業者に固有のフォーマットに変換して当該通信事業者の認証システムへ送信し、前記認証結果を受信すると当該認証結果を所定の共通フォーマットに変換する変換ステップと、
前記共通フォーマットに変換された認証結果を、前記認証要求の送信元へ返信する送信ステップと、を前記コンピュータが実行する制御方法。
【請求項８】
コンピュータに認証要求を制御させるための制御プログラムであって、
前記コンピュータは、通信端末の識別データのグループそれぞれに対して、当該グループ内の通信端末のユーザが複数の通信事業者のそれぞれと契約している確率を示す第１の信頼度データを記憶し、
ユーザが利用している通信端末の識別データを伴い、前記複数の通信事業者のいずれかの有する当該ユーザの属性情報が指定条件を満たすか否かの認証要求を、所定の共通フォーマットで受信する受信ステップと、
前記識別データに基づいて、前記第１の信頼度データによって前記ユーザが契約していると推定される通信事業者の順位を判定する判定ステップと、
前記属性情報を有する通信事業者から認証結果が得られるか、又は前記複数の通信事業者の全てに対して認証要求を行うまで、前記判定ステップにおいて算出された順位が高い通信事業者から順に、前記認証要求を当該通信事業者に固有のフォーマットに変換して当該通信事業者の認証システムへ送信し、前記認証結果を受信すると当該認証結果を所定の共通フォーマットに変換する変換ステップと、
前記共通フォーマットに変換された認証結果を、前記認証要求の送信元へ返信する送信ステップと、を前記コンピュータに実行させるための制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証要求を変換する制御装置、制御方法及び制御プログラムに関する。
【背景技術】
【０００２】
近年、ＳＮＳ（Ｓｏｃｉａｌ  Ｎｅｔｗｏｒｋｉｎｇ  Ｓｅｒｖｉｃｅ）又は他のコミュニティサイト等、ＣＧＭ（Ｃｏｎｓｕｍｅｒ  Ｇｅｎｅｒａｔｅｄ  Ｍｅｄｉａ）が普及している。ＣＧＭによるサービスは、例えば年齢に応じて一部機能を制限して提供される場合がある。そこで、サービスの利用に際して年齢認証の確実性が求められている。
ところが、オンラインでの年齢確認では、年齢の詐称が比較的容易であり、また、個人情報であることから扱いが難しいという課題がある。
【０００３】
このような状況において、免許証又はＩＣカード等のユーザ識別情報と、ユーザの個人情報を紐付けることで年齢認証を行う手段が提案されている（例えば、特許文献１参照）。
また、通信事業者がＣＧＭサイトへ利用者の年齢情報を通知することにより、利用者がユーザ識別情報を意識的に提示することなく年齢認証を行えるサービスが提供されている（例えば、非特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−２５２８５号公報
【非特許文献】
【０００５】
【非特許文献１】ａｕ携帯電話の利用者情報を活用した「年齢確認サービス」の提供および「ａｕ  ｏｎｅ  ＧＲＥＥ」の本サービスへの対応について、２０１１年１月１９日、［ｏｎｌｉｎｅ］、［平成２５年８月１９日検索］、インターネット＜ｈｔｔｐ：／／ｗｗｗ．ｋｄｄｉ．ｃｏｍ／ｃｏｒｐｏｒａｔｅ／ｎｅｗｓ＿ｒｅｌｅａｓｅ／２０１１／０１１９ａ／ｉｎｄｅｘ．ｈｔｍｌ＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に示されているユーザ識別情報を提示する方法では、年齢等の属性情報を認証する際に、ユーザ識別情報を都度入力する必要があるため、ユーザの利便性が低下する。
【０００７】
また、非特許文献１に示されている方法では、複数の通信事業者それぞれにおける契約者情報の保持の仕方、及びキーとなる情報の仕様が異なると、ＣＧＭの運営事業者は、サービス利用者の属する通信事業者毎に、それぞれ異なるプログラムロジックでユーザの属性情報の認証を行う必要がある。このため、システムの保守性が低下し、運用コストが高まる。
さらに、ユーザの端末がいずれの通信事業者に属しているかを判別できない場合、認証要求を複数の通信事業者へ送信し、無駄なトランザクションが発生してしまう。
【０００８】
本発明は、複数の通信事業者のいずれかが保持している契約者情報を用いて、効率的にユーザの属性情報の認証を行うために認証要求を変換する制御装置、制御方法及び制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係る制御装置は、通信端末の識別データのグループそれぞれに対して、当該グループ内の通信端末のユーザが複数の通信事業者のそれぞれと契約している確率を示す第１の信頼度データを記憶する記憶部と、ユーザが利用している通信端末の識別データを伴い、前記複数の通信事業者のいずれかの有する当該ユーザの属性情報が指定条件を満たすか否かの認証要求を、所定の共通フォーマットで受信する受信部と、前記識別データに基づいて、前記第１の信頼度データによって前記ユーザが契約していると推定される通信事業者の順位を判定する判定部と、前記属性情報を有する通信事業者から認証結果が得られるか、又は前記複数の通信事業者の全てに対して認証要求を行うまで、前記判定部により算出された順位が高い通信事業者から順に、前記認証要求を当該通信事業者に固有のフォーマットに変換して当該通信事業者の認証システムへ送信し、前記認証結果を受信すると当該認証結果を所定の共通フォーマットに変換する変換部と、前記共通フォーマットに変換された認証結果を、前記認証要求の送信元へ返信する送信部と、を備える。
【００１０】
前記制御装置は、前記認証結果に応じて前記第１の信頼度データを更新する更新部を備えてもよい。
【００１１】
前記更新部は、前記通信端末が属するグループに対する前記第１の信頼度データによって判定された最上位の通信事業者とは異なる通信事業者から、前記属性情報を有すると判定される認証結果が得られた場合、当該通信端末に対する第２の信頼度データを、前記第１の信頼度データとは別に記憶してもよい。
【００１２】
前記更新部は、前記第２の信頼度データが所定量を超えた場合、当該第２の信頼度データを削除すると共に、前記第１の信頼度データを更新してもよい。
【００１３】
前記認証要求は、当該認証要求の送信元であるサービス事業者を識別する事業者データを含み、前記制御装置は、前記事業者データが前記認証要求への返答を許可された所定のデータであることを認証する認証部を備えてもよい。
【００１４】
前記識別データは、電話番号、ＩＰアドレス及びＨＴＴＰユーザエージェントのいずれかを含んでもよい。
【００１５】
本発明に係る制御方法は、コンピュータによる認証要求の制御方法であって、前記コンピュータは、通信端末の識別データのグループそれぞれに対して、当該グループ内の通信端末のユーザが複数の通信事業者のそれぞれと契約している確率を示す第１の信頼度データを記憶し、ユーザが利用している通信端末の識別データを伴い、前記複数の通信事業者のいずれかの有する当該ユーザの属性情報が指定条件を満たすか否かの認証要求を、所定の共通フォーマットで受信する受信ステップと、前記識別データに基づいて、前記第１の信頼度データによって前記ユーザが契約していると推定される通信事業者の順位を判定する判定ステップと、前記属性情報を有する通信事業者から認証結果が得られるか、又は前記複数の通信事業者の全てに対して認証要求を行うまで、前記判定ステップにおいて算出された順位が高い通信事業者から順に、前記認証要求を当該通信事業者に固有のフォーマットに変換して当該通信事業者の認証システムへ送信し、前記認証結果を受信すると当該認証結果を所定の共通フォーマットに変換する変換ステップと、前記共通フォーマットに変換された認証結果を、前記認証要求の送信元へ返信する送信ステップと、を前記コンピュータが実行する。
【００１６】
本発明に係る制御プログラムは、コンピュータに認証要求を制御させるための制御プログラムであって、前記コンピュータは、通信端末の識別データのグループそれぞれに対して、当該グループ内の通信端末のユーザが複数の通信事業者のそれぞれと契約している確率を示す第１の信頼度データを記憶し、ユーザが利用している通信端末の識別データを伴い、前記複数の通信事業者のいずれかの有する当該ユーザの属性情報が指定条件を満たすか否かの認証要求を、所定の共通フォーマットで受信する受信ステップと、前記識別データに基づいて、前記第１の信頼度データによって前記ユーザが契約していると推定される通信事業者の順位を判定する判定ステップと、前記属性情報を有する通信事業者から認証結果が得られるか、又は前記複数の通信事業者の全てに対して認証要求を行うまで、前記判定ステップにおいて算出された順位が高い通信事業者から順に、前記認証要求を当該通信事業者に固有のフォーマットに変換して当該通信事業者の認証システムへ送信し、前記認証結果を受信すると当該認証結果を所定の共通フォーマットに変換する変換ステップと、前記共通フォーマットに変換された認証結果を、前記認証要求の送信元へ返信する送信ステップと、を前記コンピュータに実行させる。
【発明の効果】
【００１７】
本発明によれば、複数の通信事業者のいずれかが保持している契約者情報を用いて、効率的にユーザの属性情報の認証が行える。
【図面の簡単な説明】
【００１８】
【図１】実施形態に係る認証システムの構成を示す図である。
【図２】実施形態に係る標準ＡＰＩのデータフォーマットを例示する図である。
【図３】実施形態に係るユーザテーブルを示す図である。
【図４】実施形態に係るネットワークテーブルを示す図である。
【図５】実施形態に係る処理の流れを示すシーケンス図である。
【図６】実施形態に係る判定処理を示すフローチャートである。
【図７】実施形態に係る認証代行処理を示すフローチャートである。
【図８】実施形態に係る第１の更新処理を示す図である。
【図９】実施形態に係る第２の更新処理を示す図である。
【発明を実施するための形態】
【００１９】
以下、本発明の実施形態の一例について説明する。
図１は、本実施形態に係る認証システム１の構成を示す図である。
【００２０】
本実施形態の認証システム１は、ＡＰＩ変換装置１０（制御装置）と、サービス利用者が操作するユーザ端末２０（通信端末）と、ＣＧＭ事業者のコンテンツサーバ３０と、複数の通信事業者のそれぞれが有する認証サーバ４０とがネットワークを介して接続されている。
【００２１】
ここで、ネットワークは、インターネット、電話回線網、衛星通信網等の公衆回線網、及びイーサネット（登録商標）を含む各種ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、並びにＩＰ−ＶＰＮ等の専用回線網を含んでよい。
【００２２】
ＡＰＩ変換装置１０は、コンテンツサーバ３０とのインタフェースを標準化し、認証サーバ４０に依存したユーザ属性情報の認証に係る処理を代行する。
なお、ユーザの属性情報とは、例えば、年齢、性別、住所等の通信事業者において管理される契約者情報である。以下では、年齢認証を例として説明する。
【００２３】
ユーザ端末２０は、サービス利用者がＣＧＭ事業者の提供するコンテンツを利用するために、いずれかのコンテンツサーバ３０へサービス要求を行う。
ユーザ端末２０は、例えば、携帯端末、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）、ゲーム機器等であってよく、ソフトウェア処理によって回線情報等を含む端末情報（識別データ）を取得可能な情報処理装置である。
【００２４】
コンテンツサーバ３０は、ユーザ端末２０からのサービス要求に応じて、ＣＧＭ事業者のコンテンツを利用するユーザの年齢認証を要求する。例えば、コンテンツサーバ３０は、新規登録者に対して、登録者所有のユーザ端末２０の識別子と共に年齢認証クエリをＡＰＩ変換装置１０に対して送信する。
このとき、コンテンツサーバ３０は、ユーザ端末２０が属している通信事業者によらず共通のフォーマットで規定されている標準ＡＰＩを呼び出すことにより、認証要求を行う。
【００２５】
図２は、本実施形態に係る標準ＡＰＩのデータフォーマットを例示する図である。
標準ＡＰＩは、パラメータとして、ＣＧＭ事業者の識別データ、認証年齢、電話番号、ＩＰアドレス、ＨＴＴＰユーザエージェントに関するクエリを指定することで、クエリにマッチした契約者の年齢情報を取得する。
【００２６】
ここで、クエリとは、定数（””で囲んだ文字列）、範囲演算子（［ｆｒｏｍ，ｔｏ］）及びワイルドカードから構成される検索式である。
具体的には、「ｓｅｎｄｅｒ」は、ＡＰＩの要求元を保証するための文字列であり、ＣＧＭ事業者を一意に識別可能であればよい。「ａｇｅ」は、認証条件であり、範囲演算子によって年齢領域を指定することによって表現される。
「ｕｓｅｒ」は、被認証者を一意に識別するための文字列であり、電話番号又はＳＩＭに記載された回線情報等である。「ｎｅｔｗｏｒｋ」は、ＩＰアドレスを表す文字列である。「ａｇｅｎｔ」は、ＨＴＴＰユーザエージェントを表す文字列である。
【００２７】
使用例は、電話番号が「０８０−１１１１−１１１１」のユーザの年齢が２０歳以上であるか否かを認証するためのものである。ＣＧＭ事業者は、文字列「ｎａｎａｓｈｉ．ｃｏｒｐ」により識別される。また、端末情報として、電話番号の他、ＩＰアドレス「１７２．１９．７０．１６２」及びＨＴＴＰユーザエージェント「ｘｘｘｘ」が指定されている。
【００２８】
ＡＰＩ変換装置１０は、標準ＡＰＩによって集約された認証要求に対して、ユーザ端末２０が属する通信事業者を後述の処理により推定する。そして、ＡＰＩ変換装置１０は、推定された通信事業者の認証サーバ４０に固有のＡＰＩに合わせて認証要求のフォーマットを変換し、認証サーバ４０に固有のＡＰＩを呼び出す。
【００２９】
認証サーバ４０は、ネットワーク通信機能、認証機能、契約者情報ＤＢ（データベース）等を有し、固有ＡＰＩの呼び出しに応じて、パラメータに含まれる端末情報を契約者情報と照合し、年齢認証を行う。
具体的には、各通信事業者の認証サーバ４０は、通信事業者の契約者情報と契約端末情報とを紐付けており、端末情報をキーとして契約者情報を参照し、例えば、未成年か否かといった認証結果を返す。
【００３０】
ここで、認証のキーとなる端末情報は、電話番号等の回線情報の他、端末識別情報、通信事業者内での利用者識別ＩＤ等、ユーザ端末２０と契約者情報とを一意に対応付け可能な識別データであればよい。
【００３１】
ＡＰＩ変換装置１０は、認証サーバ４０から認証結果を得ると、この認証サーバ４０に固有の認証結果を標準ＡＰＩのフォーマットへ逆変換し、認証要求元のコンテンツサーバ３０へ応答する。
【００３２】
次に、ＡＰＩ変換装置１０の構成を詳述する。
ＡＰＩ変換装置１０は、通信事業者ＤＢ１１（記憶部）と、マッピングＤＢ１２と、サービス実行制御部１３（受信部、送信部）と、認証部１４と、判定部１５（更新部）と、ＡＰＩ変換部１６（変換部）とを備える。
【００３３】
通信事業者ＤＢ１１は、ユーザ端末２０の端末情報に含まれる識別データのグループそれぞれに対して、このグループ内のユーザが複数の通信事業者のそれぞれと契約している確率を示す信頼度データ（第１の信頼度データ）を記憶する。
【００３４】
具体的には、通信事業者ＤＢ１１は、標準ＡＰＩのパラメータ（例えば、電話番号、ＩＰアドレス、ＨＴＴＰユーザエージェント）それぞれと各通信事業者との関係を定義する。例えば、電話番号等の回線情報は、各通信事業者において管理されているため、電話番号から通信事業者が推定される。同様に、ＩＰアドレス等のネットワーク情報、及びＨＴＴＰユーザエージェントに含まれる端末若しくは通信事業者の識別情報からも、通信事業者を推定可能である。
【００３５】
ここで、各パラメータに基づく通信事業者の識別精度は、パラメータの種類及び値によって異なる。したがって、この識別精度に基づいて、パラメータと通信事業者との関係を確率値として、例えば所定のテーブルに記憶する。
【００３６】
具体的には、上記パラメータとなる端末情報は、再割り当てされて、通信事業者をまたいで更新される場合がある。この場合、再割り当てに対応してＤＢが更新されない限り、通信事業者を一意に識別することはできない。
例えば、ＭＮＰ（Ｍｏｂｉｌｅ  Ｎｕｍｂｅｒ  Ｐｏｒｔａｂｉｌｉｔｙ）により、ユーザは電話番号を変えずに通信事業者を変更できるため、電話番号又は電話番号のグループから通信事業者を一意に指定できなくなる。
また、ＪＰＮＩＣ（Ｊａｐａｎ  Ｎｅｔｗｏｒｋ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｅｒ）へのＩＰアドレスの返還及び再割り当ての処理がある。これにより、返還されたＩＰアドレスが別の通信事業者に割り当てられる場合もあるため、ＩＰアドレスから通信事業者を一意に指定できなくなる。
また、ＨＴＴＰユーザエージェントは、認証用インタフェースがＨＴＴＰで作成されていない場合には空白になる等、通信事業者を識別することが難しい場合がある。
【００３７】
図３は、本実施形態に係る通信事業者ＤＢ１１に格納されるユーザテーブルを示す図である。
ユーザテーブルは、標準ＡＰＩのパラメータである電話番号（ｕｓｅｒ）のグループそれぞれ（キー情報）に対して、ユーザが通信事業者Ａ、Ｂ及びＣに属する確率を示す信頼度データを記憶する。
例えば、各信頼度データは０以上１以下の実数であり、キー情報に対する信頼度データの総和が１となるように分配される。
【００３８】
ここで、電話番号の下位数桁のみの違いは同一グループとして管理される。例えば、下位４桁の違いを無視し、上位７桁で区別されるグループの場合、このブループには１００００個の電話番号が含まれる。また、下位３桁の違いを無視し、上位８桁で区別されるグループの場合、このブループには１０００個の電話番号が含まれる。テーブルに含まれる各グループは、それぞれ異なる粒度であってもよく、適宜設定可能である。
【００３９】
図４は、本実施形態に係る通信事業者ＤＢ１１に格納されるネットワークテーブルを示す図である。
ネットワークテーブルは、標準ＡＰＩのパラメータであるＩＰアドレス（ｎｅｔｗｏｒｋ）のグループそれぞれに（キー情報）対して、ユーザテーブル（図３）と同様、ユーザが通信事業者Ａ、Ｂ及びＣに属する確率を示す信頼度データを記憶する。
【００４０】
ここで、キー情報には、グループを示すＩＰアドレスと共に、グループの粒度を示すプレフィックスが含まれる。例えば、プレフィックスが２４の場合、このグループは、２４ビットのネットワークアドレスが共通のＩＰアドレスのグループを示しており、下位８ビットの違いが無視される。また、プレフィックスが３０の場合、このグループは、３０ビットのネットワークアドレスが共通のＩＰアドレスのグループを示しており、下位２ビットの違いが無視される。テーブルに含まれる各グループは、それぞれ異なる粒度であってもよく、適宜設定可能である。
【００４１】
図３及び図４に示したように、信頼度データがグループで管理されることにより、通信事業者ＤＢ１１の項目数が大幅に削減される。
なお、データが大規模になる場合、又はグループの粒度が小さい場合、ＤＢサイズ及び検索時間の増加を抑制するために、テーブルを複数のサーバに分散して保持してもよい。この分散処理により、処理付加が低減される。また、処理の効率化のため、互いに近い空間を含むテーブルを同一サーバに配置する等、局所性を考慮した分散処理が好ましい。
【００４２】
マッピングＤＢ１２は、標準ＡＰＩのデータフォーマットと、各通信事業者の認証サーバ４０に固有のＡＰＩのデータフォーマットとの変換規則を記憶する。
固有の認証ＡＰＩは、例えば、ある通信事業者ではＳＯＡＰ形式が用いられ、他の通信事業者ではＲＥＳＴ形式が用いられる等、各通信事業者のプログラムロジックに強く依存して作られる。そこで、変換規則は、通信事業者毎に決定される。
【００４３】
マッピングＤＢ１２に格納されるマッピングテーブルにおいて、標準ＡＰＩは標準スキーマによって定義され、固有ＡＰＩは固有スキーマによって定義される。ここで、固有スキーマは、ＸＭＬスキーマの他、ＳＯＡＰ形式サービスの仕様が記述されたＷＳＤＬ及びＲＥＳＴ形式サービスの仕様が記述されたＷＡＤＬ等も含む。
【００４４】
サービス実行制御部１３は、プロトコルに対応したインタフェースの保持、又は外部装置とのメッセージの送受信を実施する。具体的には、コンテンツサーバ３０からの標準ＡＰＩ要求に係る送受信を実行するため、各Ｗｅｂサービスプロトコル（例えば、ＳＯＡＰ形式又はＲＥＳＴ形式等）に対応したインタフェースを保持する。
【００４５】
また、ＡＰＩの呼び出し代行に際して、サービス実行制御部１３は、ユーザ端末２０の端末情報を伴い、複数の通信事業者のいずれかが有するユーザの属性情報（年齢）が指定条件を満たすか否かの認証要求を、標準ＡＰＩのフォーマットで受信する。これに応じて、サービス実行制御部１３は、呼び出し元の認証認可、及び呼び出し先の選定等、逐次的に発生する処理シーケンスを把握し、各処理部へ処理依頼を実施する一連の制御を行う。
そして、サービス実行制御部１３は、標準ＡＰＩのフォーマットに変換された認証結果を、認証要求の送信元であるコンテンツサーバ３０へ返信する。
【００４６】
認証部１４は、ＡＰＩ要求元のＣＧＭ事業者に対して身元保証を実施する。通信事業者が有する年齢等の契約者情報は、個人情報であり不特定のＣＧＭ事業者へ提供できないため、予め認証要求への返答を許可された公式のＣＧＭ事業者の識別データが記憶される。
具体的には、認証要求は、送信元であるＣＧＭ事業者を識別する事業者データを含み、認証部１４は、この事業者データが、記憶されている所定の識別データの中に存在すれば認証成功とし、存在しなければ認証失敗として、要求元にエラーを返す。
【００４７】
判定部１５は、標準ＡＰＩのパラメータである端末情報に基づいて、通信事業者ＤＢ１１の信頼度データを用いた後述の判定処理によってユーザが契約していると推定される通信事業者の順位を判定する。
また、判定部１５は、認証サーバ４０から得た認証結果に応じて、後述の更新処理により信頼度データを更新する。
【００４８】
ＡＰＩ変換部１６は、マッピングテーブルの変換規則に従って、標準ＡＰＩのデータフォーマットを、通信事業者の固有ＡＰＩのデータフォーマットへ変換する。さらに、ＡＰＩ変換部１６は、変換されたデータフォーマットを用いて該当の通信事業者の認証サーバ４０に対して固有ＡＰＩの呼び出しを行う。また、ＡＰＩ変換部１６は、固有ＡＰＩの戻り値である認証結果を受信すると、この認証結果を標準ＡＰＩのデータフォーマットへ逆変換する。
【００４９】
ここで、ＡＰＩ変換部１６は、実際にユーザの年齢情報を含む契約者情報を有する通信事業者の認証サーバ４０から認証結果が得られるか、又は通信事業者ＤＢ１１及びマッピングＤＢ１２にある複数の通信事業者の全てに対して認証要求を行うまで、判定部１５により算出された順位が高い通信事業者から順に、認証要求を送信する。
【００５０】
図５は、本実施形態に係る認証システム１における処理の流れを示すシーケンス図である。
ユーザ端末２０からのコンテンツ要求に応じて、コンテンツサーバ３０が標準ＡＰＩを呼び出すと（ステップＳ１）、サービス実行制御部１３は、まず、認証部１４によりＣＧＭ事業者の認証をさせる（ステップＳ２）。
【００５１】
ＣＧＭ事業者が認証されると、サービス実行制御部１３は、判定部１５によりユーザの属する通信事業者を判定させる（ステップＳ３）。続いて、サービス実行制御部１３は、ＡＰＩ変換部１６により標準ＡＰＩのデータフォーマットを、判定された通信事業者の固有ＡＰＩのデータフォーマットへ変換させる（ステップＳ４）。
【００５２】
ＡＰＩ変換部１６は、変換されたデータフォーマットにより固有ＡＰＩを呼び出し（ステップＳ５）、認証サーバ４０に年齢認証を行わせる（ステップＳ６）。ＡＰＩ変換部１６は、認証サーバ４０から固有ＡＰＩの戻り値として認証結果を受け取ると（ステップＳ７）、この認証結果を、固有ＡＰＩのデータフォーマットから標準ＡＰＩのデータフォーマットへ変換する（ステップＳ８）。
サービス実行制御部１３は、ＡＰＩ変換部１６から受け取った認証結果を、標準ＡＰＩの戻り値として、コンテンツサーバ３０へ応答する（ステップＳ９）。
【００５３】
その後、サービス実行制御部１３は、判定部１５により、認証結果に応じた通信事業者ＤＢ１１の更新処理を行わせる（ステップＳ１０）。
【００５４】
次に、シーケンス中の判定部１５による判定処理（Ａ）、ＡＰＩ変換部１６による認証代行処理（Ｂ）、及び判定部１５による更新処理（Ｃ）について詳述する。
【００５５】
図６は、本実施形態に係る判定部１５による判定処理を示すフローチャートである。
ステップＳ１１において、判定部１５は、端末情報の数（例えば、「ｕｓｅｒ」、「ｎｅｔｗｏｒｋ」、「ａｇｅｎｔ」の３つ）だけループを行い（ｉ＝０，１，２）、ステップＳ１２において、通信事業者ＤＢ１１から、各端末情報に対する通信事業者毎の信頼度データを取得する。
例えば、「ｉ＝０」のとき、「ｕｓｅｒ＝０８０−１１１１−１１１１」に対して、ユーザテーブル（図３）から信頼情報として、配列ｒｅｓｐｏｎｓｉｂｉｌｉｔｙ［０］［］＝（０．８，０．１，０．１）が得られる。
【００５６】
ステップＳ１３において、判定部１５は、通信事業者の数（Ｎ）だけループを行い（ｊ＝０，…，Ｎ−１）、ステップＳ１４において、端末情報の数だけ更にループを行う（ｋ＝０，１，２）。ステップＳ１５において、判定部１５は、ユーザがいずれの通信事業者と契約しているかを推定する指標として、通信事業者毎に信頼度データの総乗（Ｎｊ＝「ｕｓｅｒ」に対する信頼度×「ｎｅｔｗｏｒｋ」に対する信頼度×「ａｇｅｎｔ」に対する信頼度）を計算する。
【００５７】
ステップＳ１６において、判定部１５は、通信事業者の順位付けを行う。例えば、判定部１５は、ステップＳ１５で計算された総乗（Ｎｊ）を大きい順にソートし、並べ替えられた通信事業者のリスト「Ｓ’ｊ＝Ｓｏｒｔ（Ｓｊ）」を得る。
なお、通信事業者間で総乗（Ｎｊ）が等しい場合、判定部１５は、端末情報の優先度に応じて、例えば、「ｕｓｅｒ」に対する信頼度を比較し、等しい場合には「ｎｅｔｗｏｒｋ」に対する信頼度を比較し、更に等しい場合には「ａｇｅｎｔ」に対する信頼度を順に比較し、大きい方を優先する。
【００５８】
ステップＳ１７において、判定部１５は、順位付けされた結果（Ｓ’ｊ）を戻り値として出力する。
なお、順位付け結果の出力形態は、これには限られない。例えば、判定部１５は、各通信事業者に対して順位付けの値を付与して出力してもよい。
【００５９】
図７は、本実施形態に係るＡＰＩ変換部１６による認証代行処理を示すフローチャートである。
ステップＳ２１において、ＡＰＩ変換部１６は、判定処理（図６）により出力された順位付け結果から、固有ＡＰＩを呼び出す通信事業者の順序を読み込む。なお、初期値「ｉ＝０」である。
【００６０】
ステップＳ２２において、ＡＰＩ変換部１６は、マッピングＤＢ１２において対象の通信事業者の固有スキーマを参照し、固有ＡＰＩのデータフォーマットへ認証要求を変換する。
【００６１】
ステップＳ２３において、ＡＰＩ変換部１６は、変換されたデータフォーマットで、対象の認証サーバ４０の固有ＡＰＩを呼び出す。
【００６２】
ステップＳ２４において、ＡＰＩ変換部１６は、戻り値（ｒｅｓｕｌｔ）がエラーであるか否かを判定する。この判定がＹＥＳの場合、対象の通信事業者に契約者情報が存在しない、すなわちユーザは別の通信事業者に属していると判断し、処理はステップＳ２５に移る。一方、判定がＮＯの場合、契約者情報が存在し正しく年齢認証の結果が得られたので、処理はステップＳ２７に移る。
【００６３】
ステップＳ２５において、ＡＰＩ変換部１６は、認証要求を行っていない通信事業者が残っているか（ｉ＜Ｎ）否かを判定する。この判定がＹＥＳの場合、処理はステップＳ２６に移り、判定がＮＯの場合、処理はステップＳ２７に移る。
【００６４】
ステップＳ２６において、ＡＰＩ変換部１６は、次の通信事業者を選定するため、「ｉ＝ｉ＋１」とし、処理は、ステップＳ２１に戻る。
【００６５】
ステップＳ２７において、ＡＰＩ変換部１６は、固有ＡＰＩの戻り値（ｒｅｓｕｌｔ）を、標準ＡＰＩのデータフォーマットに変換する。この戻り値は、年齢認証の結果、又はエラーを含む。
【００６６】
ステップＳ２８において、ＡＰＩ変換部１６は、標準ＡＰＩの戻り値として、認証結果を返答する。
【００６７】
図８は、本実施形態に係る判定部１５（更新部）による第１の更新処理を示す図である。
本処理は、例えば、ＭＮＰ等により特定の契約者情報が別の通信事業者へ移動し、固有ＡＰＩの呼び出し先が想定と異なる場合に生じる。この場合、特定の端末情報に対する信頼度データに誤りが存在する。
【００６８】
判定部１５は、ユーザ端末２０が属するグループに対する第１の信頼度データによって判定された最上位の通信事業者とは異なる通信事業者から、契約者情報を有すると判定される認証結果が得られた場合、このユーザ端末２０に対する固有の新たな信頼度データ（第２の信頼度データ）を、グループに対する第１の信頼度データとは別に通信事業者ＤＢ１１に記憶する。
【００６９】
例えば、判定部１５は、端末情報として「ｕｓｅｒ」＝「０８０−１１１１−１１１１」のみが入力された場合、更新前のユーザテーブルによれば、呼び出し順序をＡ、Ｂ、Ｃの順とする。ところが、実際には、「ｕｓｅｒ」＝「０８０−１１１１−１１１１」，「０８０−１１１１−２２２２」に該当するユーザの契約者情報が通信事業者Ａから通信事業者Ｂへ移っている。したがって、ＡＰＩ変換部１６は、通信事業者Ａからは契約者情報に基づく認証結果は得られず、通信事業者Ｂから認証結果を得ることになる。
【００７０】
このとき、判定部１５は、ユーザテーブルにおいて、キー情報を「０８０−１１１１−１１１１」とする例外レコードを追加する。追加されるレコードの信頼度データ（第２の信頼度データ）は、例えば、認証結果を得た通信事業者Ｂが「１」で、その他が「０」である。
同様に、「ｕｓｅｒ」＝「０８０−１１１１−２２２２」の認証要求があると、キー情報を「０８０−１１１１−２２２２」とする例外レコードが追加される。
【００７１】
図９は、本実施形態に係る判定部１５（更新部）による第２の更新処理を示す図である。
本処理は、例えば、ＩＰアドレス空間の再割り当てにより特定の契約者情報のグループが別の通信事業者へ移動し、固有ＡＰＩの呼び出し先が想定と異なる場合に生じる。この場合、特定の端末情報のグループに対する信頼度データに誤りが存在する。
【００７２】
判定部１５は、前述の第１の更新処理を繰り返し、元々同一グループに属していた例外レコードが所定量を超えた場合、元のグループ全体が別の通信事業者へ移動したと判断し、例外レコードを削除すると共に、グループに対する第１の信頼度データを更新する。
【００７３】
例えば、判定部１５は、キー情報「０８０−１１１２−ｘｘｘｘ」に属するユーザの認証要求があると、更新前のユーザテーブルによれば、呼び出し順序をＡ、Ｂ、Ｃの順とする。ところが、実際には、「ｕｓｅｒ」＝「０８０−１１１２−ｘｘｘｘ」に該当するユーザの契約者情報が通信事業者Ａから通信事業者Ｂへ移っている。したがって、判定部１５は、第１の更新処理により、例外レコードを作成していく。
【００７４】
この例外レコードが一定数を超えた場合、判定部１５は、キー情報「０８０−１１１２−ｘｘｘｘ」に対する信頼度データを更新する。信頼度データは、例えば、認証結果を得た通信事業者Ｂが最上位となるように値の入れ替え、又は一定値の加減算が行われてもよいし、認証結果を得た通信事業者Ｂが「１」で、その他が「０」に初期化されてもよい。
【００７５】
また、判定部１５は、例外レコードが追加される度に、誤った通信事業者の値を一定値（例えば、１／グループに属する数）小さくし、正しい通信事業者の値を大きくしてもよい。この場合、判定部１５は、最上位の通信事業者の値が所定値より小さくなった場合に、第１の信頼度データが誤っていると判断し、上述の入れ替え、加減算又は初期化等のデータ更新を行う。
【００７６】
以上のように、本実施形態によれば、ＡＰＩ変換装置１０は、通信事業者毎に仕様が異なる複数の固有ＡＰＩが存在する場合において、各通信事業者に対応するようにデータフォーマットを変換できるので、ＣＧＭ事業者に対しては、共通の標準ＡＰＩを提供できる。これにより、ＣＧＭ事業者は、サービス利用者が契約している通信事業者を意識することなく、いずれかの通信事業者が保持している契約者情報を利用して認証を行える。この結果、ＣＧＭ事業者は、サービス実装時に、通信事業者に依存しないロジック構築が可能となり、また、ソフトウェアの保守性が高まるため運用コストも低減する。
このように、ＣＧＭ事業者は、複数の通信事業者のいずれかが保持している契約者情報を用いて、効率的にユーザの属性情報の認証が行える。
【００７７】
さらに、ＡＰＩ変換装置１０は、ユーザの端末情報から通信事業者が一意に識別できない状況において、信頼度データに基づく順位付けができるため、契約者情報を有していない通信事業者との無駄なトランザクションの発生を抑制し、認証の処理を効率化できる。
【００７８】
また、ＡＰＩ変換装置１０は、認証結果に応じて信頼度データを更新できるので、呼び出し順序を適正化できる。
ＡＰＩ変換装置は、通信事業者の推定に誤りがあった場合、例外として第２の信頼度データを追加するので、推定精度を向上し、認証の処理を効率化できる。
さらに、例外データが所定量を超えた場合に、例外を削除すると共に第１の信頼度データを更新するので、推定精度を向上しつつ、処理負荷の増大を抑制できる。
【００７９】
また、ＡＰＩ変換装置１０は、認証要求元のＣＧＭ事業者の正当性を認証できるので、通信事業者が有する契約者情報を特定の範囲のみで安全に利用できる。
【００８０】
ＡＰＩ変換装置１０は、通信事業者を推定する際に、識別精度が高い端末情報として電話番号、ＩＰアドレス及びＨＴＴＰユーザエージェントを用い、それぞれの信頼度データを管理することで、推定精度を向上し、処理を効率化できる。
【００８１】
以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、本実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本実施形態に記載されたものに限定されるものではない。
【００８２】
前述の実施形態では、年齢認証を例に説明したが、本発明は、通信事業者が有する他の契約者情報（例えば、年齢、性別、住所等）に基づく認証にも適用可能である。
【００８３】
ＡＰＩ変換装置１０は、情報処理装置（コンピュータ）により構成される。ＡＰＩ変換装置１０は、概念的に１つのコンピュータとして構成されるものであってよく、物理的実体としては、複数のコンピュータにより構成されてもよい。
【００８４】
コンピュータにより実行される制御方法は、ソフトウェアにより実現される。ソフトウェアによって実現される場合には、このソフトウェアを構成するプログラムが、コンピュータにインストールされる。また、これらのプログラムは、ＣＤ−ＲＯＭのようなリムーバブルメディアに記録されてユーザに配布されてもよいし、ネットワークを介してユーザのコンピュータにダウンロードされることにより配布されてもよい。
【符号の説明】
【００８５】
１  認証システム
１０  ＡＰＩ変換装置（制御装置）
１１  通信事業者ＤＢ（記憶部）
１２  マッピングＤＢ
１３  サービス実行制御部（受信部、送信部）
１４  認証部
１５  判定部（更新部）
１６  ＡＰＩ変換部（変換部）
２０  ユーザ端末（通信端末）
３０  コンテンツサーバ
４０  認証サーバ
【図１】
2015053007.tif 000003
【図２】
2015053007.tif 000004
【図３】
2015053007.tif 000005
【図４】
2015053007.tif 000006
【図５】
2015053007.tif 000007
【図６】
2015053007.tif 000008
【図７】
2015053007.tif 000009
【図８】
2015053007.tif 000010
【図９】
2015053007.tif 000011