ユーザ端末認証プログラム
【課題】ネットワークシステムにおけるユーザ端末認証方式に係り、端末の性能を最大限に活用できる認証方式を、複数の認証方式候補の中から、簡単かつ動的に選択可能とする。
【解決手段】認証を行うプログラムが、端末からのサービスリクエストに対応して端末認証に関するデータを示し、機種に依存しない統一形式の端末情報オブジェクトを動的に作成する手順と、そのオブジェクトの内容に対応して、端末に適する認証方式を選択する手順と、選択された認証方式を用いて端末に対する認証手続きを実行する手順とを計算機に実行させる。
【解決手段】認証を行うプログラムが、端末からのサービスリクエストに対応して端末認証に関するデータを示し、機種に依存しない統一形式の端末情報オブジェクトを動的に作成する手順と、そのオブジェクトの内容に対応して、端末に適する認証方式を選択する手順と、選択された認証方式を用いて端末に対する認証手続きを実行する手順とを計算機に実行させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワークシステムにおけるユーザ端末の認証方式に係り、更に詳しくはインターネットシステムにおいて使用される様々な種類のユーザ端末からのサービスのリクエストのデータを用いて端末の能力を動的に判定し、リクエストを発行したユーザ端末に適した認証方式を選択することができるユーザ端末認証技術に関する。
【背景技術】
【０００２】
近年のインターネット技術の発展に伴ない、インターネットブラウザを搭載した様々な種類の端末が登場している。その種類は年々増加の一途をたどっている。
従来のウエブコンテンツ作成者は、パソコン端末だけを対象としてコンテンツを作成していたが、現在では能力の異なる様々な端末の出現によってその端末能力、例えば記述言語（マークアップ・ランゲージ）や認証方式などに応じて、プログラミング上で複雑な考慮を行うことが必要となっている。
【０００３】
すなわち、従来はインターネットの利用端末としてパソコンだけが用いられていて、複数の端末種別をサポートする必要がなかったが、近年ｉモードに代表されるウエブホン、カーナビ、パーソナル・ディジタル・アシスタンツ（ＰＤＡ）など、様々なモバイル端末の出現によって複数の端末種別をサポートする必要が生じてきた。
【０００４】
サーバ側で端末をサポートする方式として、基本的に２つの方式がある。第１の方式は単一端末サポートサーバ方式である。端末の種類によってその機能や能力が異なるため、端末機種ごとにウエブシステム（ウエブサーバ）を設ける方式であり、１つのサーバで１つの端末種別だけがサポートされる。
【０００５】
第２の方式は複数端末サポートサーバ方式であり、この方式ではウエブシステムのプログラム（サーブレット、ＣＧＩなど）において端末の機能、能力の相違が考慮され、１つのサーバで複数の端末種別がサポートされる。
【０００６】
次に端末の認証方式は最も端末の能力に左右されるものである。現在では基本認証、フォーム認証、端末固有ＩＤ認証、指紋認証、声紋認証、網膜認証など各種の認証方式が搭載、または開発され、それらの方式に対する迅速なサポートが求められている。また近年では複数の認証方式をサポートしている機種が一般的となっている。
【０００７】
ここで基本認証は端末の持っている基本認証機能を使用する認証方式であり、ウエブサーバからある特定のＨＴＴＰ（ハイパー・テキスト・トランスファー・プロトコル）のコードを端末側に返すことによって、端末（ブラウザ）側でユーザ名とパスサートの入力フィールドが画面上に表示され、ユーザが入力を行うことによって認証が行われる。
【０００８】
なおこの基本認証はインターネット関連技術の標準化をすすめているＩＥＴＦ（インターネット・エンジニアリング・タスク・フォース）によってまとめられたＲＦＣ（リクエスト・フォー・コメンツ）に規定され、全世界的に使用されている方式であるが、セキュリティの面での欠点も指摘されている。
【０００９】
次にフォーム認証は、ウエブアプリケーション側でユーザ名とパスワードの入力フィールドを持つフォーム（画面）を作成し、これを端末側に送ることによって端末側で入力が行われ、認証が実行される。基本認証との違いは、フォームの作成が端末（ブラウザ）側の機能ではないことにある。
【００１０】
端末固有ＩＤ認証は、端末に割り当てられた固有の識別子（ＩＤ）を用いて認証が行われるものであり、例えばユーザ端末からのサービスリクエスト内のＨＴＴＰヘッダなどから端末固有ＩＤ、すなわちサブスクリプトＩＤが抽出され、そのＩＤの値を用いて認証が行われる。
【００１１】
以上のように端末種別のサポートにおいては、単一端末をサポートする方式と、複数端末をサポートする方式とがあるが、前者では端末種別ごとにウエブシステムを構築する必要があり、システムの作成者にとって大きな負担となる。新しい端末種別が増えるたびに同様の作業が必要となり、資源的にも効率が悪く、多数の端末種別をサポートする場合には実用性に乏しく、ほとんど使うことができないという問題点があった。
【００１２】
第２の方式では、複数の端末種別の中で機能や性能の低い機種に引きずられ、個々の端末能力を十分に活用することができないという問題点があった。
認証方式については、従来では複数端末サポートサーバ方式を用いて、機能レベルの最も低い機種に合わせた１つだけの認証方式を採用するという方法が用いられていた。例えばほとんどの端末種別で利用可能なフォーム認証が採用されていたが、これではそれぞれの端末種別にあった最適な認証方式を採用することができず、端末の性能を最大限に活用した認証方式を端末種別毎に選択することができないという問題点があった。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明の課題は、上述の問題点に鑑み、端末の性能を最大限に活用できる認証方式を、複数の認証方式候補の中から簡単に、かつダイナミックに選択することができるユーザ端末認証プログラムを提供することである。
【課題を解決するための手段】
【００１４】
図１は本発明のユーザ端末認証プログラムの原理的な機能ブロック図である。同図はユーザ端末からのサービスのリクエストに対応して、ユーザ端末の認証を行う計算機によって使用されるユーザ端末認証プログラムの原理的な機能ブロック図である。
【００１５】
図１においてユーザ端末認証プログラムは３つの手順によって構成される。第１の手順は、ユーザ端末からのリクエストのデータを用いてユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成する手順である。
【００１６】
第２の手順は、作成された端末情報オブジェクトの内容に対応して複数の認証方式、例えば基本認証、フォーム認証、端末固有ＩＤ認証などの中から、ユーザ端末に適する認証方式を選択する手順である。
【００１７】
第３の手順は、選択された認証方式を用いてユーザ端末に対する認証手続きを実行する手順であり、これらの手順は第１〜第３の順序で実行される。
発明の実施の形態においては、ユーザ端末の認証を行う計算機が、機種に応じた端末の認証に関するデータを示す端末情報リポジトリの記憶手段を備え、端末情報オブジェクトの作成を行う第１の手順において、ユーザ端末からのリクエストのデータにおいて不足しているデータを端末情報リポジトリの内容を用いて充足し、端末情報オブジェクトを作成することもできる。
【００１８】
またユーザ端末の認証を行う計算機が、デフォルトの端末の認証に関するデータを示すデフォルト端末情報リポジトリの記憶手段を備え、ユーザ端末の機種が不明の時、端末情報オブジェクトを作成する第１の手順において、ユーザ端末からのリクエストのデータにおいて不足しているデータをデフォルト端末情報リポジトリの内容を用いて充足し、端末情報オブジェクトを作成することもできる。
【００１９】
実施の形態においては、ユーザ端末の認証を行う計算機が複数の認証方式の間の優先順位を記憶する手段を備え、認証方式を選択する第２の手順において、端末情報オブジェクトの内容に対応してユーザ端末に適用可能な認証方式のうちで、優先順位の高い認証方式を選択することもできる。
【００２０】
更に実施の形態においては、ユーザ端末の認証を行う計算機が、端末情報オブジェクトを作成する第１の手順において作成された端末情報オブジェクトを、同一ユーザ端末からの一連の通信における次回のサービスのリクエストに備えて記憶する手段を備え、ユーザ端末からの次のサービスのリクエストに対応して端末情報オブジェクトを作成する第１の手順において、端末情報オブジェクトの記憶オブジェクトの記憶手段の記憶内容を利用することもできる。
【００２１】
実施の形態において、ユーザ端末からのサービスのリクエストに対応してユーザ端末の認証を行う装置は、ユーザ端末からのリクエストのデータを用いて、ユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成する手段と、作成された端末情報オブジェクトの内容に対応して、複数の認証方式の中からユーザ端末に適する端末認証方式を選択する手段と、選択された認証方式を用いてユーザ端末に対する認証手続きを実行する手段とを備える。
【００２２】
また実施の形態において、ユーザ端末からのサービスのリクエストに対応してユーザ端末の認証を行う方法として、ユーザ端末からのリクエストのデータを用いて、ユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成し、作成された端末情報オブジェクトの内容に対応して、複数の認証方式の中からユーザ端末に適する認証方式を選択し、選択された認証方式を用いてユーザ端末に対する認証手続きを実行する方法が用いられる。
【００２３】
実施の形態においてユーザ端末からのサービスのリクエストに対応してユーザ端末の認証を行う計算機によって使用される記憶媒体として、ユーザ端末からのリクエストのデータを用いて、ユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成するステップと、作成された端末情報オブジェクトの内容に対応して、複数の認証方式の中からユーザ端末に適する認証方式を選択するステップと、選択された認証方式を用いてユーザ端末に対する認証手続きを実行するステップとを計算機に実行させるためのプログラムを格納した計算機読み出し可能可搬型記憶媒体が用いられる。
【発明の効果】
【００２４】
以上のように、本発明によれば、ユーザ端末からのサービスのリクエストのデータを用いて、端末の能力や認証に関するデータを示す統一形式の端末情報オブジェクトが作成され、ユーザ端末に適する認証方式が選択される。これによって各種の認証方式がサポートされ、端末種別のサポート範囲も広くなる。
【発明を実施するための最良の形態】
【００２５】
図２は本実施形態において、ユーザ端末の認証を動的に実行するモバイルエージェントを含む認証システムの構成ブロック図である。同図においてシステムは基本的にモバイルエージェントサーバ１０と、認証データベース（ＤＢ）１１とによって構成されている。
【００２６】
モバイルエージェントサーバ１０はオペレーティングシステム１２、ウエブサーバ１３、およびモバイルエージェント１４によって構成されており、モバイルエージェント１４は基本的にはユーザ端末の認証を動的に実行し、その結果ユーザ端末の正当性が判定された時点で、ウエブアプリケーション１５を起動するプログラムである。
【００２７】
すなわちウエブアプリケーション１５は利用可能ユーザを制限していることが多く、端末からリクエストが発行されるとそのユーザが利用可能であるかを認証するが、その処理をモバイルエージェント１４が実行することになる。
【００２８】
図２においてウエブフォン、ＰＣ（パソコン）、またはＰＤＡからのウエブアプリケーションのリクエストはウエブサーバ１３によって受け取られ、モバイルエージェント１４によって認証データベース１１の内容を用いて、複数の認証方式のうちでユーザ端末に適した認証方式が選択され、認証の結果、ユーザ端末の正当性が判定された時点で、ウエブアプリケーション１５が起動される。
【００２９】
図３はモバイルエージェントによる処理の基本的な説明図である。同図においてユーザ端末からのＨＴＴＰ（ハイパー・テキスト・トランスファー・プロトコル）のリクエスト、すなわちウエブアプリケーションの利用要求に対応して、ＨＴＴＰヘッダ・パラメータ解析２０、端末情報オブジェクトの作成２１、認証処理２２、ウエブアプリケーション起動２３の順序で処理が行われる。
【００３０】
まずＨＴＴＰヘッダ・パラメータ解析２０においては、ユーザ端末からのＨＴＴＰリクエストに含まれるＨＴＴＰヘッダとＨＴＴＰパラメータの解析が行われ、ＨＴＴＰ解析オブジェクトが作成される。ＨＴＴＰ解析オブジェクトの内容はアプリケーションのＵＲＬ（ユニフォーム・リソース・ロケータ）コンテンツの長さ、ＨＴＴＰプロトコルのバージョンなどのＨＴＴＰ基本情報に加えて、後述するＨＴＴＰヘッダ解析テーブル、ＨＴＴＰパラメータ解析テーブル、およびクッキー解析テーブルの内容を含むものである。
【００３１】
端末情報オブジェクトの作成２１の処理では、ＨＴＴＰ解析オブジェクトのデータを基にして、ＨＴＴＰリクエストを発行したユーザ端末のキャリア（通信事業者）と機種が特定される。そしてこのリクエストがユーザ端末とウエブサーバ１３との間で要求／応答が繰り返される一連の通信としてのセション内の初めてのリクエストの場合には、キャリアと機種に対応する端末情報リポジトリ格納ファイル２６の読み込みが行われる。この端末情報リポジトリは端末の能力や認証関連データなどを示すものであり、その詳細は後述する。読み込まれた端末情報リポジトリとＨＴＴＰ解析オブジェクトの情報とを用いて、端末情報オブジェクトが作成される。なおこの端末情報リポジトリの読み込みはＨＴＴＰ解析オブジェクトの内容によっては得られない情報を取得するためのものであり、充分な情報が得られる場合にはその読み込みは不要である。
【００３２】
ユーザ端末からのＨＴＴＰリクエストが、すでに開始されたセション内で、例えば次のリクエストである場合には、そのセションに対応する端末情報オブジェクトが端末情報オブジェクトキャッシュ２５にキャッシュされており、端末情報オブジェクトの作成２１においてはこのキャッシュ２５から端末情報オブジェクトが読み込まれ、ＨＴＴＰ解析オブジェクトの中の必要な情報がその端末情報オブジェクトに上書きされることによって、端末情報オブジェクトの作成が行われる。作成された端末情報オブジェクトは、次のＨＴＴＰリクエストの入力に備えてセションのＩＤをキーとして、端末情報オブジェクトキャッシュ２５に登録される。
【００３３】
認証処理２２においては、端末情報オブジェクトの内容に応じて複数の認証方式のうちのいずれかが選択され、ユーザ端末に対する認証が行われる。この時、設定ファイル２７に認証方式の優先順位が設定されており、優先順位の高い順に認証方式が評価され、認証方式が決定される。この優先順位は例えば図２のモバイルエージェントサーバ１０を含むウエブシステムの管理者によって設定されるものであり、管理者は例えばセキュリティレベルの大きい方式の優先順位を高くする。
【００３４】
決定された認証方式を用いて、認証に必要な各種のデータ、例えばユーザ名、パスワードなどが獲得され、認証データベース２８にアクセスが行われ、ユーザ端末の正当性がチェックされる。なお認証ＤＢ１１は、例えばネットワークを介してアクセス可能な他のサーバに接続されたデータベースでもよい。
【００３５】
認証が失敗した場合には、ユーザにその旨を知らせるエラーメッセージ、すなわち認証失敗を示すＨＴＴＰレスポンスが送られ、ユーザ端末側にエラーメッセージが表示され、必要に応じてユーザに対して各種認証データの再入力が要求される。
【００３６】
認証が成功した場合には、ウエブアプリケーション起動２３が行われ、ユーザ側に対してはウエブアプリケーションのＨＴＴＰレスポンスが返される。
図４は図３の設定ファイル２７の説明図である。同図においては、３つの認証方式として基本（ベーシック）認証、フォーム認証、および端末固有（サブスクライブ）ＩＤ認証が指定されている。先頭に“＃”のある行はコメントであり、処理には無関係の行である。最後の行が優先順位を定義しており、ここでは優先順位の第１位は端末固有ＩＤ認証、第２位は基本認証、第３位はフォーム認証であることが指定されている。
【００３７】
図５は認証処理の基本的なシーケンスの説明図である。同図において、まずユーザ端末からのリクエストに対してＨＴＴＰ解析３０が行われる。この解析は図３におけるＨＴＴＰヘッダ・パラメータ解析２０、および端末情報オブジェクトの作成２１の処理に対応する。
【００３８】
次に認証済みか否かの判定３１が行われる。前回までのアクセスですでに認証済みである場合には、直ちにアプリケーショ起動３７が行われ、認証済みでない場合には認証方法の決定３２に移行する。
【００３９】
認証方法の決定３２では、前述のように端末情報オブジェクトの内容や、図３の設定ファイル２７に設定されている優先順位などによって、複数の認証方式、ここでは４つの認証方式、すなわち基本認証３３、端末固有ＩＤ認証３４、フォーム認証またはフォーム認証と端末固有ＩＤ認証の組合わせとしてのフォームＩＤ認証３５、実際には認証処理がバイパスされるナン認証３６のいずれかが決定される。
【００４０】
認証処理のフェーズ、すなわち例えば基本認証３３においては、認証結果がＯＫであればアプリケーション起動３７が行われ、認証が失敗、すなわちＮＧであれば例えばＨＴＴＰステータス４０１のエラーメッセージがユーザ端末側に返される。
【００４１】
認証処理フェーズの端末固有ＩＤ認証３４で失敗した場合には、エラー画面作成３８が行われ、ＨＴＴＰステータス２００のエラーメッセージがユーザ端末側に返される。
更にフォーム認証またはフォームＩＤ認証３５で登録失敗、または未登録のセションと判定された場合には、ログイン画面作成３９が行われ、ユーザ端末側に認証に必要なデータの入力を促す画面がＨＴＴＰステータス２００として送られる。
【００４２】
図６は図５の認証方法の決定３２における認証方式判定用マトリックスを示す。図の左側は、ユーザ端末によって各認証方式がサポートされているかいないかを、基本認証、フォーム認証、およびサブスクライブＩＤ認証のそれぞれについて、サポートされている場合に○印、サポートされていない場合に×印の組合わせとして示されている。
【００４３】
右側では左側の組合わせに対応して、認証処理が可能であるか不可能であるかが各認証方式、すなわち基本認証、フォーム認証、端末固有ＩＤ認証、フォームＩＤ認証、およびナン認証のそれぞれに対して示されている。
【００４４】
図７は図５における認証処理フェーズ、例えば基本認証３３の処理フェーズの説明図である。認証処理フェーズは基本的に認証データ取得フェーズ４２と、認証手続きフェーズ４３とに分割される。ここで利用者４１からのリクエストは認証データ取得フェーズ４２に入力され、認証手続きフェーズ４３の結果に対応して認証ＯＫか否かの判定４４が行われ、ＯＫであればアプリケーション４５が起動され、認証失敗の場合には利用者４１にエラーメッセージなどが返される。
【００４５】
認証データ取得フェーズ４２は図５のＨＴＴＰ解析３０から認証方法の決定３２までに対応し、認証に必要なデータとして例えばユーザ名やパスワードなどが、利用者４１から入力されるリクエス内のＨＴＴＰヘッダ、ＨＴＴＰパラメータの解析によって取得される。
【００４６】
認証手続きフェーズ４３では、取得されたデータを使用してユーザ端末の正当性がチェックされる。このチェックにおいては、例えばＬＤＡＰ（ライトウェイト・ディレクトリ・アクセス・プロトコル）認証サービスなどのカセッタブルな構造の認証機構が呼び出されて認証が行われ、認証が成功すればＵＲＬで指定されるアプリケーションの画面が端末側で表示される。
【００４７】
図８〜図１２はそれぞれの認証方式に対応する認証処理フェーズの詳細説明図である。図８は基本認証３３の説明図であり、端末が持つ認証機能（画面）を利用して認証が行われる。
【００４８】
図８において、まずユーザ端末から送られたＨＴＴＰヘッダの中のオーソライゼーション情報が取り出され、ユーザ名やパスワードが取得される。オーソライゼーション情報、すなわちユーザ名やパスワードがない場合には、端末側に認証入力画面を出してもらうためにＨＴＴＰステータスコード４０１が端末側に返される。ユーザ名、パスワードなどが取得できた場合に、認証手続きフェーズが実行される。認証手続きフェーズにおいてユーザ名やパスワードが一致せず認証が失敗した場合には、オーソライゼーション情報がない場合と同様に、ＨＴＴＰステータス４０１を端末に返してユーザ名パスワードの再入力を求めることも可能である。
【００４９】
図９はサブスクライブＩＤ認証３４の説明図である。端末に割当てられたサブスクライブＩＤを利用して認証が行われるために、端末側での認証入力画面は必要がない。
図９においてＨＴＴＰヘッダの解析結果を格納するＨＴＴＰヘッダ解析テーブル（後述）からサブスクライブＩＤが取り出され、そのＩＤがない場合にはエラー画面が作成され、ＨＴＴＰステータス２００としてユーザ端末側に返される。サブスクライブＩＤが取り出された場合には、認証手続きフェーズが呼び出され、サブスクライブＩＤを用いた認証が行われる。この認証が失敗した場合には、ＩＤがない場合と同様に、例えばサブスクライブＩＤが有効でないことを示すエラー画面を端末側に表示させることもできる。
【００５０】
図１０はフォーム認証の説明図である。フォーム認証ではモバイルエージェントの持つログイン画面がユーザ端末側に表示され、認証が行われる。
図１０において、後述するＨＴＴＰパラメータ解析テーブルからユーザ名、パスワード、アプリケーションのＵＲＬが取り出され、ユーザ名やパスワードが取り出されたか否かが判定され、取り出されなかった場合にはログイン画面が作成されて、ＨＴＴＰステータス２００としてその画面がユーザ端末側で表示され、ユーザ名やパスワードの入力が要求される。ユーザ名やパスワードが取得できた場合には、認証手続きフェーズが実行され、認証が失敗した場合にはエラー画面が作成されて、ユーザ端末側に送られる。
【００５１】
図１１はフォームＩＤ、すなわちフォームアンドサブスクライブＩＤ認証の説明図である。ユーザ名の代わりに端末固有のサブスクライブＩＤが使用され、モバイルエージェントの持つログイン画面が必要に応じて利用されて認証が行われる。
【００５２】
図１１においてまずＨＴＴＰヘッダ解析テーブルとＨＴＴＰパラメータ解析テーブルとから、サブスクライブＩＤ、パスワード、およびアプリケーションのＵＲＬが取り出され、サブスクライブＩＤがない場合にはエラー画面が作成され、ＨＴＴＰステータス２００として端末に送られる。
【００５３】
サブスクライブＩＤが取得できた場合には、パスワードが取得できたか否かが判定され、取得できない場合にはパスワードの入力を要求するログイン画面が作成されて、ＨＴＴＰステータス２００としてパスワードの入力がユーザ端末側に要求される。パスワードが取得できた場合には、認証手続きフェーズが実行され、例えばサブスクライブＩＤやパスワードが有効でない場合には、エラー画面が作成されてユーザ端末側に送られることになる。
【００５４】
図１２はナン認証の説明図である。この認証方式は例えばゲストユーザに対する認証方式として用いられるもので、実質的に認証手続きなしでアプリケーションの利用を可能とさせるものである。すなわちこの方式では、認証データ取得フェーズ、認証手続きフェーズがバイパスされ、認証が成功したものとしてアプリケーションの起動が行われる。
【００５５】
次にＨＴＴＰ解析オブジェクト、および端末情報オブジェクトのデータ構造について説明する。まずＨＴＴＰ解析オブジェクトは、ユーザ端末から入力されたＨＴＴＰリクエスト情報を解析した結果の一まとまりのデータであり、前述のようにＨＴＴＰ基本情報、ＨＴＴＰヘッダ解析テーブル、ＨＴＴＰパラメータ解析テーブル、およびクッキー解析テーブルの内容によって構成される。このうちＨＴＴＰ基本情報は、前述のようにアプリケーションのＵＲＬ、コンテンツの長さ、ＨＴＴＰプロトコルのバージョンなどのデータであり、またクッキー解析テーブルも本実施形態に直接の関係がないため、それらの詳細な説明は省略する。
【００５６】
図１３はＨＴＴＰヘッダの例である。このＨＴＴＰヘッダはある通信キャリアに対応する例であるが、本実施形態において用いられるデータは１行目のユーザエージェント、５行目のｘ−ｕｐ−ｓｕｂｎｏ（サブスクライブＩＤに相当）、および１２行目の前述したオーソライゼーション情報である。
【００５７】
図１４は図１３のＨＴＴＰヘッダの情報を変換した結果としてのＨＴＴＰヘッダ解析テーブルのデータ構造の例である。同図のデータは実質的に図１３と同様であるが、パラメータの名称、データ型、およびパラメータの値の欄を持つテーブルに変換されている。
【００５８】
図１５はＨＴＴＰパラメータの例であり、図１６はこのＨＴＴＰパラメータを変換した結果としてのＨＴＴＰパラメータ解析テーブルのデータ形式の例である。図１６において本実施形態で使用されるデータは１行目のユーザ名、２行目のパスワード、３行目のアプリケーションのＵＲＬである。
【００５９】
図１７は端末情報オブジェクトのデータ形式の例である。図３の端末情報リポジトリと端末情報オブジェクトとは実質的に同一の形式である。それらの間の相違は、端末情報リポジトリはファイル内のデータとして提供されることであり、そのファイルの内容を読み込んでメモリに展開すれば端末情報オブジェクトと同じ形式となる。
【００６０】
従って端末情報オブジェクトも、端末の能力を示すデータのまとまりであり、本実施形態では上から３行のユーザ名、パスワード、およびサブスクライブＩＤが認証手続きで利用されるが、これらのデータに加えて各認証方式がサポートされているか否か、端末の能力としての表示可能な色の数、および画面サイズなどのデータが含まれている。
【００６１】
なお以上のＨＴＴＰヘッダ解析テーブル、ＨＴＴＰパラメータ解析テーブル、端末情報オブジェクトなどは図２ではモバイルエージェントサーバ１０内の図示しないメモリに格納され、モバイルエージェント１４によって使用される。
【００６２】
次に本実施形態における処理の詳細について図１８〜図２０を用いて説明する。図１８は図３のＨＴＴＰヘッダ・パラメータ解析２０、端末情報オブジェクトの作成２１の処理フローチャートであり、図１９は端末情報オブジェクトの作成２１の詳細フローチャートである。
【００６３】
図１８において端末からのリクエストに対応して処理が開始されると、まずステップＳ１でＨＴＴＰ情報の解析処理として、端末からのＨＴＴＰリクエストの中のＨＴＴＰヘッダとＨＴＴＰパラメータの解析が行われ、必要な情報がＨＴＴＰ解析オブジェクトとして保存される。
【００６４】
続いてステップＳ２で、ＨＴＴＰ解析オブジェクトの情報からユーザ端末と、例えば図２のウエブサーバ１３の間で行われる一連の通信に対応するセションを特定するためのセションＩＤの獲得が行われ、ステップＳ３でセションＩＤが獲得できたか否かが判定される。セションＩＤは図１４のテーブルの１１行目のクッキーに格納されている。
【００６５】
セションＩＤが獲得できなかった場合には、一連の通信の開始時におけるリクエストと判定され、その一連の通信に対応するセションＩＤがステップＳ４で生成された後に、またセションＩＤが獲得できた場合には直ちに、ステップＳ５の処理に移行する。
【００６６】
ステップＳ５では、ＨＴＴＰ解析オブジェクトと端末情報リポジトリの内容を使用して、端末情報オブジェクトの作成処理が行われる。この処理の詳細は図１９に示す。そしてステップＳ６で一連の通信におけるユーザ端末からの次のリクエストに備えて、端末情報オブジェクトが図３の端末情報オブジェクトキャッシュ２５にキャッシュされ、認証処理に移行する。このキャッシュ処理ではセションＩＤと、端末情報オブジェクトとがペアとして格納される。このキャッシングによって、次のリクエスト時における端末情報リポジトリの読み込みなどの処理を不要とし、性能・効率が向上する。
【００６７】
図１９は図１８のステップＳ５の端末情報オブジェクトの作成処理の詳細フローチャートである。同図において処理が開始されると、まずステップＳ１０でキャッシュ判定が行われる。すなわち端末情報オブジェクトが、図３の端末情報オブジェクトキャッシュ２５にキャッシュ済みかどうかが判定される。前述のように端末情報オブジェクトのキャッシングはセションＩＤをキーとして行われるために、例えば一連の通信としてのセションの開始時には端末情報オブジェクトはキャッシュされておらず、ステップＳ１１以降の処理が行われる。
【００６８】
ステップＳ１１では、リクエストを発行したユーザ端末に対するキャリアがサポートされているか否かが判定される。すなわちＨＴＴＰ解析オブジェクトの内容によって、キャリアのサポートが行われているか否かが判定される。この判定は図１４で説明したＨＴＴＰヘッダ解析テーブル内のデータの１行目の、キャリア毎に特徴のあるユーザエージェントの内容によって行われ、キャリアがサポートされている場合には、ステップＳ１２でキャリアと機種の特定が行われる。機種の特定についても、ユーザエージェントのデータを解析することによって行われる。
【００６９】
続いてステップＳ１３で、特定されたキャリアと機種に対応する端末情報リポジトリが図３の端末情報リポジトリ格納ファイル２６に格納されているか否かが判定され、格納されている場合にはステップＳ１４でその端末情報リポジトリが採用される。
【００７０】
また格納されていない場合には、ステップＳ１５ですでに特定されたキャリアのデフォルト機種に対応する端末情報リポジトリが採用される。更にステップＳ１１でキャリアがサポートされていないと判定された場合には、ステップＳ１６で例えば広範に使用されているパソコン用のインターネットアクセスプログラムに対応する端末情報リポジトリが採用される。
【００７１】
そしてステップＳ１８でステップＳ１４，Ｓ１５、またはＳ１６で採用された端末情報リポジトリをひな形として、ＨＴＴＰヘッダ解析テーブルの情報を用いて端末情報リポジトリ、すなわち端末情報オブジェクトの更新が行われて、ステップＳ１９でＨＴＴＰパラメータ解析テーブルの情報を用いて端末情報リポジトリ、すなわち端末情報オブジェクトの更新が行われて、端末情報オブジェクトの作成処理を終了する。
【００７２】
またステップＳ１０でキャッシュ判定の結果、リクエストを発行した端末に対する端末情報オブジェクトがキャッシュされていると判定された場合には、ステップＳ１７でその端末情報オブジェクトが採用されて、ステップＳ１８以降の処理が行われる。なお、ステップＳ１８，Ｓ１９で行われる更新処理では、例えば端末情報リポジトリがひな形として利用されるが、リクエスト毎に変更される可能性があるパスワードやユーザ名などの更新が行われる。
【００７３】
図２０は図１８の処理に続く認証処理の詳細フローチャートである。同図において処理が開始されると、まずステップＳ２１で認証方式候補リストが作成される。このリスト作成処理は図３の設定ファイル２７の内容、すなわち図４で説明した認証方式の優先順位に応じたリストを作成するものであり、この処理はモバイルエージェントシステムの初期化時に１回だけ行われてもよく、また認証方式候補リストを作成する代わりに、図４の認証方式の優先順位を読み込むだけでもよいことになる。
【００７４】
ステップＳ２２で認証方式決定処理ループの初期化処理として、認証方式を求めるためのカウンタのカウント値ｎが０に設定され、ステップＳ２３およびＳ２４によって構成されるループの処理が行われる。すなわちステップＳ２３ではカウンタｎの値がインクリメントされ、まずリストの１番目、すなわち優先順位の最も高い認証方式が取り出され、ステップＳ２４でその認証方式が使用可能か否かが判定される。この判定では、端末情報オブジェクトの内容によって、リクエストを発行したユーザ端末がその認証方式をサポートしているか否かが判定される。使用可能でない場合にはステップＳ２３に戻り、ｎの値をインクリメントし、２番目の認証方式以降についてステップＳ２３、およびＳ２４の処理が繰り返される。
【００７５】
ステップＳ２４で取り出されたｎ番目の認証方式が使用可能であると判定された場合には、ステップ２５でその認証方式の採用が決定され、ステップＳ２６でその認証方式に対応する認証手続きが呼び出され、認証に必要なユーザ名、パスワードなどの情報がＨＴＴＰ解析オブジェクトから獲得されて渡され、認証処理が実行される。
【００７６】
そしてステップＳ２７で認証が成功したか否かが判定され、認証が成功していればアプリケーションの呼び出し処理が行われる。この認証の成功の判定は、認証手続きからの復帰情報の参照によって判断される。
【００７７】
ステップＳ２３，ステップＳ２４の処理が認証方式候補リストにリストされているｎ個の認証方式の全てに対して繰り返され、使用可能な認証方式がないと判定された場合、およびステップＳ２７で認証が失敗したと判定された場合には、ステップＳ２８で認証失敗のメッセージが端末に通知され、処理を終了する。
【００７８】
以上において本発明のユーザ端末認証プログラムとしてのモバイルエージェントなどについてその詳細を説明したが、このモバイルエージェントは当然一般的なコンピュータシステムによって実現されることが可能である。図２１はそのようなコンピュータシステム、すなわちハードウェア環境の構成ブロック図である。
【００７９】
図２１においてコンピュータシステムは中央処理装置（ＣＰＵ）９０、リードオンリメモリ（ＲＯＭ）９１、ランダムアクセスメモリ（ＲＡＭ）９２、通信インタフェース９３、記憶装置９４、入出力装置９５、可搬型記憶媒体の読取り装置９６、およびこれらの全てが接続されたバス９７によって構成されている。
【００８０】
記憶装置９４としては、ハードディスク、磁気ディスクなど様々な形式の記憶装置を使用することができ、このような記憶装置９４、またはＲＯＭ９１に図５、図７、図１８〜図２０などのシーケンス図やフローチャートに示されたプログラムや、本発明の特許請求の範囲の請求項１〜５のプログラムなどが格納され、そのようなプログラムがＣＰＵ９０によって実行されることにより、本実施形態におけるユーザ端末の動的認証が可能となる。
【００８１】
このようなプログラムは、プログラム提供者９８側からネットワーク９９、および通信インタフェース９３を介して、例えば記憶装置９４に格納されることも、また市販され、流通している可搬型記憶媒体１００に格納され、読取り装置９６にセットされて、ＣＰＵ９０によって実行されることも可能である。可搬型記憶媒体１００としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスクなど様々な形式の記憶媒体を使用することができ、このような記憶媒体に格納されたプログラムが読取り装置９６によって読取られることにより、本実施形態における、あらかじめ設定されている認証方式の優先順位に対応した端末認証などが可能となる。
【００８２】
以上詳細に説明したように本発明によれば、１つのウエブシステムのみで複数の端末種別、および複数の認証方式をサポートすることが可能となり、ウエブシステムの作成メンテナンスの手間を減少させ、資源の利用を効率化させることができ、コンテンツ作成者は端末能力を意識せずに本来のコンテンツ作成作業に専念可能となる。
【００８３】
端末からのサービスクリエイトに対応して端末情報オブジェクトを作成することによって、端末の能力に応じた最適な認証方式をダイナミックに選択することができ、また認証方式の優先順位を変更することによって、選択される認証方式を簡単に変更することができる。端末種別が不明の場合にも、デフォルトの端末情報リポジトリを利用することによって、端末情報オブジェクトの作成が可能となり、未知の端末に対しても認証処理が可能となる。
【００８４】
（付記１）ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う計算機によって使用されるプログラムにおいて、
該リクエストのデータを用いて、前記ユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成する手順と、
該端末情報オブジェクトの内容に対応して、複数の認証方式の中から該ユーザ端末に適する認証方式を選択する手順と、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行する手順とを計算機に実行させるためのユーザ端末認証プログラム。
【００８５】
（付記２）前記計算機が、機種に応じた端末の認証に関するデータを示す端末情報リポジトリの記憶手段を備え、
前記端末情報オブジェクトの作成手順において、前記ユーザ端末からのリクエストのデータにおいて不足しているデータを該端末情報リポジトリの内容を用いて充足し、該端末情報オブジェクトを作成することを特徴とする付記１記載のユーザ端末認証プログラム。
【００８６】
（付記３）前記計算機が、デフォルトの端末の認証に関するデータを示すデフォルト端末情報リポジトリの記憶手段を備え、
前記ユーザ端末の機種が不明の時、前記端末情報オブジェクトの作成手順において、前記ユーザ端末からのリクエストのデータにおいて不足しているデータを該デフォルト端末情報リポジトリの内容を用いて充足し、該端末情報オブジェクトを作成することを特徴とする付記１記載のユーザ端末認証プログラム。
【００８７】
（付記４）前記計算機が、複数の認証方式の間の優先順位を記憶する手段を備え、
前記認証方式の選択手順において、前記端末情報オブジェクトの内容に対応して、前記ユーザ端末に適用可能な認証方式のうちで優先順位の高い認証方式を選択することを特徴とする付記１記載のユーザ端末認証プログラム。
【００８８】
（付記５）前記計算機が、前記端末情報オブジェクトの作成手順において作成された端末情報オブジェクトを、同一ユーザ端末からの一連の通信における次回のサービスのリクエストに備えて記憶する手段を備え、
ユーザ端末からの次のサービスのリクエストに対応して、前記端末情報オブジェクトの作成手順において該端末情報オブジェクトの記憶手段の記憶内容を利用することを特徴とする付記１記載のユーザ端末認証プログラム。
【００８９】
（付記６）ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う装置において、
該リクエストのデータを用いて、前記ユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成する手段と、
該端末情報オブジェクトの内容に対応して、複数の認証方式の中から該ユーザ端末に適する認証方式を選択する手段と、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行する手段とを備えることを特徴とするユーザ端末認証装置。
【００９０】
（付記７）ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う方法おいて、
該リクエストのデータを用いて、前記ユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成し、
該端末情報オブジェクトの内容に対応して、複数の認証方式の中から該ユーザ端末に適する認証方式を選択し、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行することを特徴とするユーザ端末認証方法。
【００９１】
（付記８）ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う計算機によって使用される記憶媒体において、
該リクエストのデータを用いて、前記ユーザ端末の認証に関するデータを示し 、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成するステップと、
該端末情報オブジェクトの内容に対応して、複数の認証方式の中から該ユーザ 端末に適する認証方式を選択するステップと、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行するステップとを計算機に実行させるためのプログラムを格納した計算機読み出し可能可搬型記憶媒体。
【図面の簡単な説明】
【００９２】
【図１】本発明の原理的な機能ブロック図である。
【図２】モバイルエージェントを含む認証システムの構成ブロック図である。
【図３】モバイルエージェントによる処理の基本的な説明図である。
【図４】設定ファイルの内容の例の説明図である。
【図５】認証処理の基本的なシーケンスの説明図である。
【図６】認証方式判定用マトリックスの説明図である。
【図７】認証処理フェーズの説明図である。
【図８】基本認証の説明図である。
【図９】サブスクライブＩＤ認証の説明図である。
【図１０】フォーム認証の説明図である。
【図１１】フォームアンドサブスクライブＩＤ認証の説明図である。
【図１２】ナン認証の説明図である。
【図１３】ＨＴＴＰヘッダの例を示す図である。
【図１４】ＨＴＴＰヘッダ解析テーブルのデータ形式を示す図である。
【図１５】ＨＴＴＰパラメータの例を示す図である。
【図１６】ＨＴＴＰパラメータ解析テーブルのデータ形式を示す図である。
【図１７】端末情報オブジェクトのデータ形式を示す図である。
【図１８】ＨＴＴＰヘッダ・パラメータ解析および端末情報オブジェクト作成処理のフローチャートである。
【図１９】端末情報オブジェクト作成処理の詳細フローチャートである。
【図２０】認証処理の詳細フローチャートである。
【図２１】本発明におけるプログラムのコンピュータへのローディングを説明する図である。
【符号の説明】
【００９３】
１０ モバイルエージェントサーバ
１１，２８ 認証データベース（ＤＢ）
１２ オペレーティングシステム
１３ ウエブサーバ
１４ モバイルエージェント
１５ ウエブアプリケーション
２０ ＨＴＴＰヘッダ・パラメータ解析
２１ 端末情報オブジェクトの作成
２２ 認証処理
２３ アプリケーション起動
２５ 端末情報オブジェクトキャッシュ
２６ 端末情報リポジトリ格納ファイル
２７ 設定ファイル
【技術分野】
【０００１】
本発明はネットワークシステムにおけるユーザ端末の認証方式に係り、更に詳しくはインターネットシステムにおいて使用される様々な種類のユーザ端末からのサービスのリクエストのデータを用いて端末の能力を動的に判定し、リクエストを発行したユーザ端末に適した認証方式を選択することができるユーザ端末認証技術に関する。
【背景技術】
【０００２】
近年のインターネット技術の発展に伴ない、インターネットブラウザを搭載した様々な種類の端末が登場している。その種類は年々増加の一途をたどっている。
従来のウエブコンテンツ作成者は、パソコン端末だけを対象としてコンテンツを作成していたが、現在では能力の異なる様々な端末の出現によってその端末能力、例えば記述言語（マークアップ・ランゲージ）や認証方式などに応じて、プログラミング上で複雑な考慮を行うことが必要となっている。
【０００３】
すなわち、従来はインターネットの利用端末としてパソコンだけが用いられていて、複数の端末種別をサポートする必要がなかったが、近年ｉモードに代表されるウエブホン、カーナビ、パーソナル・ディジタル・アシスタンツ（ＰＤＡ）など、様々なモバイル端末の出現によって複数の端末種別をサポートする必要が生じてきた。
【０００４】
サーバ側で端末をサポートする方式として、基本的に２つの方式がある。第１の方式は単一端末サポートサーバ方式である。端末の種類によってその機能や能力が異なるため、端末機種ごとにウエブシステム（ウエブサーバ）を設ける方式であり、１つのサーバで１つの端末種別だけがサポートされる。
【０００５】
第２の方式は複数端末サポートサーバ方式であり、この方式ではウエブシステムのプログラム（サーブレット、ＣＧＩなど）において端末の機能、能力の相違が考慮され、１つのサーバで複数の端末種別がサポートされる。
【０００６】
次に端末の認証方式は最も端末の能力に左右されるものである。現在では基本認証、フォーム認証、端末固有ＩＤ認証、指紋認証、声紋認証、網膜認証など各種の認証方式が搭載、または開発され、それらの方式に対する迅速なサポートが求められている。また近年では複数の認証方式をサポートしている機種が一般的となっている。
【０００７】
ここで基本認証は端末の持っている基本認証機能を使用する認証方式であり、ウエブサーバからある特定のＨＴＴＰ（ハイパー・テキスト・トランスファー・プロトコル）のコードを端末側に返すことによって、端末（ブラウザ）側でユーザ名とパスサートの入力フィールドが画面上に表示され、ユーザが入力を行うことによって認証が行われる。
【０００８】
なおこの基本認証はインターネット関連技術の標準化をすすめているＩＥＴＦ（インターネット・エンジニアリング・タスク・フォース）によってまとめられたＲＦＣ（リクエスト・フォー・コメンツ）に規定され、全世界的に使用されている方式であるが、セキュリティの面での欠点も指摘されている。
【０００９】
次にフォーム認証は、ウエブアプリケーション側でユーザ名とパスワードの入力フィールドを持つフォーム（画面）を作成し、これを端末側に送ることによって端末側で入力が行われ、認証が実行される。基本認証との違いは、フォームの作成が端末（ブラウザ）側の機能ではないことにある。
【００１０】
端末固有ＩＤ認証は、端末に割り当てられた固有の識別子（ＩＤ）を用いて認証が行われるものであり、例えばユーザ端末からのサービスリクエスト内のＨＴＴＰヘッダなどから端末固有ＩＤ、すなわちサブスクリプトＩＤが抽出され、そのＩＤの値を用いて認証が行われる。
【００１１】
以上のように端末種別のサポートにおいては、単一端末をサポートする方式と、複数端末をサポートする方式とがあるが、前者では端末種別ごとにウエブシステムを構築する必要があり、システムの作成者にとって大きな負担となる。新しい端末種別が増えるたびに同様の作業が必要となり、資源的にも効率が悪く、多数の端末種別をサポートする場合には実用性に乏しく、ほとんど使うことができないという問題点があった。
【００１２】
第２の方式では、複数の端末種別の中で機能や性能の低い機種に引きずられ、個々の端末能力を十分に活用することができないという問題点があった。
認証方式については、従来では複数端末サポートサーバ方式を用いて、機能レベルの最も低い機種に合わせた１つだけの認証方式を採用するという方法が用いられていた。例えばほとんどの端末種別で利用可能なフォーム認証が採用されていたが、これではそれぞれの端末種別にあった最適な認証方式を採用することができず、端末の性能を最大限に活用した認証方式を端末種別毎に選択することができないという問題点があった。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明の課題は、上述の問題点に鑑み、端末の性能を最大限に活用できる認証方式を、複数の認証方式候補の中から簡単に、かつダイナミックに選択することができるユーザ端末認証プログラムを提供することである。
【課題を解決するための手段】
【００１４】
図１は本発明のユーザ端末認証プログラムの原理的な機能ブロック図である。同図はユーザ端末からのサービスのリクエストに対応して、ユーザ端末の認証を行う計算機によって使用されるユーザ端末認証プログラムの原理的な機能ブロック図である。
【００１５】
図１においてユーザ端末認証プログラムは３つの手順によって構成される。第１の手順は、ユーザ端末からのリクエストのデータを用いてユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成する手順である。
【００１６】
第２の手順は、作成された端末情報オブジェクトの内容に対応して複数の認証方式、例えば基本認証、フォーム認証、端末固有ＩＤ認証などの中から、ユーザ端末に適する認証方式を選択する手順である。
【００１７】
第３の手順は、選択された認証方式を用いてユーザ端末に対する認証手続きを実行する手順であり、これらの手順は第１〜第３の順序で実行される。
発明の実施の形態においては、ユーザ端末の認証を行う計算機が、機種に応じた端末の認証に関するデータを示す端末情報リポジトリの記憶手段を備え、端末情報オブジェクトの作成を行う第１の手順において、ユーザ端末からのリクエストのデータにおいて不足しているデータを端末情報リポジトリの内容を用いて充足し、端末情報オブジェクトを作成することもできる。
【００１８】
またユーザ端末の認証を行う計算機が、デフォルトの端末の認証に関するデータを示すデフォルト端末情報リポジトリの記憶手段を備え、ユーザ端末の機種が不明の時、端末情報オブジェクトを作成する第１の手順において、ユーザ端末からのリクエストのデータにおいて不足しているデータをデフォルト端末情報リポジトリの内容を用いて充足し、端末情報オブジェクトを作成することもできる。
【００１９】
実施の形態においては、ユーザ端末の認証を行う計算機が複数の認証方式の間の優先順位を記憶する手段を備え、認証方式を選択する第２の手順において、端末情報オブジェクトの内容に対応してユーザ端末に適用可能な認証方式のうちで、優先順位の高い認証方式を選択することもできる。
【００２０】
更に実施の形態においては、ユーザ端末の認証を行う計算機が、端末情報オブジェクトを作成する第１の手順において作成された端末情報オブジェクトを、同一ユーザ端末からの一連の通信における次回のサービスのリクエストに備えて記憶する手段を備え、ユーザ端末からの次のサービスのリクエストに対応して端末情報オブジェクトを作成する第１の手順において、端末情報オブジェクトの記憶オブジェクトの記憶手段の記憶内容を利用することもできる。
【００２１】
実施の形態において、ユーザ端末からのサービスのリクエストに対応してユーザ端末の認証を行う装置は、ユーザ端末からのリクエストのデータを用いて、ユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成する手段と、作成された端末情報オブジェクトの内容に対応して、複数の認証方式の中からユーザ端末に適する端末認証方式を選択する手段と、選択された認証方式を用いてユーザ端末に対する認証手続きを実行する手段とを備える。
【００２２】
また実施の形態において、ユーザ端末からのサービスのリクエストに対応してユーザ端末の認証を行う方法として、ユーザ端末からのリクエストのデータを用いて、ユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成し、作成された端末情報オブジェクトの内容に対応して、複数の認証方式の中からユーザ端末に適する認証方式を選択し、選択された認証方式を用いてユーザ端末に対する認証手続きを実行する方法が用いられる。
【００２３】
実施の形態においてユーザ端末からのサービスのリクエストに対応してユーザ端末の認証を行う計算機によって使用される記憶媒体として、ユーザ端末からのリクエストのデータを用いて、ユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成するステップと、作成された端末情報オブジェクトの内容に対応して、複数の認証方式の中からユーザ端末に適する認証方式を選択するステップと、選択された認証方式を用いてユーザ端末に対する認証手続きを実行するステップとを計算機に実行させるためのプログラムを格納した計算機読み出し可能可搬型記憶媒体が用いられる。
【発明の効果】
【００２４】
以上のように、本発明によれば、ユーザ端末からのサービスのリクエストのデータを用いて、端末の能力や認証に関するデータを示す統一形式の端末情報オブジェクトが作成され、ユーザ端末に適する認証方式が選択される。これによって各種の認証方式がサポートされ、端末種別のサポート範囲も広くなる。
【発明を実施するための最良の形態】
【００２５】
図２は本実施形態において、ユーザ端末の認証を動的に実行するモバイルエージェントを含む認証システムの構成ブロック図である。同図においてシステムは基本的にモバイルエージェントサーバ１０と、認証データベース（ＤＢ）１１とによって構成されている。
【００２６】
モバイルエージェントサーバ１０はオペレーティングシステム１２、ウエブサーバ１３、およびモバイルエージェント１４によって構成されており、モバイルエージェント１４は基本的にはユーザ端末の認証を動的に実行し、その結果ユーザ端末の正当性が判定された時点で、ウエブアプリケーション１５を起動するプログラムである。
【００２７】
すなわちウエブアプリケーション１５は利用可能ユーザを制限していることが多く、端末からリクエストが発行されるとそのユーザが利用可能であるかを認証するが、その処理をモバイルエージェント１４が実行することになる。
【００２８】
図２においてウエブフォン、ＰＣ（パソコン）、またはＰＤＡからのウエブアプリケーションのリクエストはウエブサーバ１３によって受け取られ、モバイルエージェント１４によって認証データベース１１の内容を用いて、複数の認証方式のうちでユーザ端末に適した認証方式が選択され、認証の結果、ユーザ端末の正当性が判定された時点で、ウエブアプリケーション１５が起動される。
【００２９】
図３はモバイルエージェントによる処理の基本的な説明図である。同図においてユーザ端末からのＨＴＴＰ（ハイパー・テキスト・トランスファー・プロトコル）のリクエスト、すなわちウエブアプリケーションの利用要求に対応して、ＨＴＴＰヘッダ・パラメータ解析２０、端末情報オブジェクトの作成２１、認証処理２２、ウエブアプリケーション起動２３の順序で処理が行われる。
【００３０】
まずＨＴＴＰヘッダ・パラメータ解析２０においては、ユーザ端末からのＨＴＴＰリクエストに含まれるＨＴＴＰヘッダとＨＴＴＰパラメータの解析が行われ、ＨＴＴＰ解析オブジェクトが作成される。ＨＴＴＰ解析オブジェクトの内容はアプリケーションのＵＲＬ（ユニフォーム・リソース・ロケータ）コンテンツの長さ、ＨＴＴＰプロトコルのバージョンなどのＨＴＴＰ基本情報に加えて、後述するＨＴＴＰヘッダ解析テーブル、ＨＴＴＰパラメータ解析テーブル、およびクッキー解析テーブルの内容を含むものである。
【００３１】
端末情報オブジェクトの作成２１の処理では、ＨＴＴＰ解析オブジェクトのデータを基にして、ＨＴＴＰリクエストを発行したユーザ端末のキャリア（通信事業者）と機種が特定される。そしてこのリクエストがユーザ端末とウエブサーバ１３との間で要求／応答が繰り返される一連の通信としてのセション内の初めてのリクエストの場合には、キャリアと機種に対応する端末情報リポジトリ格納ファイル２６の読み込みが行われる。この端末情報リポジトリは端末の能力や認証関連データなどを示すものであり、その詳細は後述する。読み込まれた端末情報リポジトリとＨＴＴＰ解析オブジェクトの情報とを用いて、端末情報オブジェクトが作成される。なおこの端末情報リポジトリの読み込みはＨＴＴＰ解析オブジェクトの内容によっては得られない情報を取得するためのものであり、充分な情報が得られる場合にはその読み込みは不要である。
【００３２】
ユーザ端末からのＨＴＴＰリクエストが、すでに開始されたセション内で、例えば次のリクエストである場合には、そのセションに対応する端末情報オブジェクトが端末情報オブジェクトキャッシュ２５にキャッシュされており、端末情報オブジェクトの作成２１においてはこのキャッシュ２５から端末情報オブジェクトが読み込まれ、ＨＴＴＰ解析オブジェクトの中の必要な情報がその端末情報オブジェクトに上書きされることによって、端末情報オブジェクトの作成が行われる。作成された端末情報オブジェクトは、次のＨＴＴＰリクエストの入力に備えてセションのＩＤをキーとして、端末情報オブジェクトキャッシュ２５に登録される。
【００３３】
認証処理２２においては、端末情報オブジェクトの内容に応じて複数の認証方式のうちのいずれかが選択され、ユーザ端末に対する認証が行われる。この時、設定ファイル２７に認証方式の優先順位が設定されており、優先順位の高い順に認証方式が評価され、認証方式が決定される。この優先順位は例えば図２のモバイルエージェントサーバ１０を含むウエブシステムの管理者によって設定されるものであり、管理者は例えばセキュリティレベルの大きい方式の優先順位を高くする。
【００３４】
決定された認証方式を用いて、認証に必要な各種のデータ、例えばユーザ名、パスワードなどが獲得され、認証データベース２８にアクセスが行われ、ユーザ端末の正当性がチェックされる。なお認証ＤＢ１１は、例えばネットワークを介してアクセス可能な他のサーバに接続されたデータベースでもよい。
【００３５】
認証が失敗した場合には、ユーザにその旨を知らせるエラーメッセージ、すなわち認証失敗を示すＨＴＴＰレスポンスが送られ、ユーザ端末側にエラーメッセージが表示され、必要に応じてユーザに対して各種認証データの再入力が要求される。
【００３６】
認証が成功した場合には、ウエブアプリケーション起動２３が行われ、ユーザ側に対してはウエブアプリケーションのＨＴＴＰレスポンスが返される。
図４は図３の設定ファイル２７の説明図である。同図においては、３つの認証方式として基本（ベーシック）認証、フォーム認証、および端末固有（サブスクライブ）ＩＤ認証が指定されている。先頭に“＃”のある行はコメントであり、処理には無関係の行である。最後の行が優先順位を定義しており、ここでは優先順位の第１位は端末固有ＩＤ認証、第２位は基本認証、第３位はフォーム認証であることが指定されている。
【００３７】
図５は認証処理の基本的なシーケンスの説明図である。同図において、まずユーザ端末からのリクエストに対してＨＴＴＰ解析３０が行われる。この解析は図３におけるＨＴＴＰヘッダ・パラメータ解析２０、および端末情報オブジェクトの作成２１の処理に対応する。
【００３８】
次に認証済みか否かの判定３１が行われる。前回までのアクセスですでに認証済みである場合には、直ちにアプリケーショ起動３７が行われ、認証済みでない場合には認証方法の決定３２に移行する。
【００３９】
認証方法の決定３２では、前述のように端末情報オブジェクトの内容や、図３の設定ファイル２７に設定されている優先順位などによって、複数の認証方式、ここでは４つの認証方式、すなわち基本認証３３、端末固有ＩＤ認証３４、フォーム認証またはフォーム認証と端末固有ＩＤ認証の組合わせとしてのフォームＩＤ認証３５、実際には認証処理がバイパスされるナン認証３６のいずれかが決定される。
【００４０】
認証処理のフェーズ、すなわち例えば基本認証３３においては、認証結果がＯＫであればアプリケーション起動３７が行われ、認証が失敗、すなわちＮＧであれば例えばＨＴＴＰステータス４０１のエラーメッセージがユーザ端末側に返される。
【００４１】
認証処理フェーズの端末固有ＩＤ認証３４で失敗した場合には、エラー画面作成３８が行われ、ＨＴＴＰステータス２００のエラーメッセージがユーザ端末側に返される。
更にフォーム認証またはフォームＩＤ認証３５で登録失敗、または未登録のセションと判定された場合には、ログイン画面作成３９が行われ、ユーザ端末側に認証に必要なデータの入力を促す画面がＨＴＴＰステータス２００として送られる。
【００４２】
図６は図５の認証方法の決定３２における認証方式判定用マトリックスを示す。図の左側は、ユーザ端末によって各認証方式がサポートされているかいないかを、基本認証、フォーム認証、およびサブスクライブＩＤ認証のそれぞれについて、サポートされている場合に○印、サポートされていない場合に×印の組合わせとして示されている。
【００４３】
右側では左側の組合わせに対応して、認証処理が可能であるか不可能であるかが各認証方式、すなわち基本認証、フォーム認証、端末固有ＩＤ認証、フォームＩＤ認証、およびナン認証のそれぞれに対して示されている。
【００４４】
図７は図５における認証処理フェーズ、例えば基本認証３３の処理フェーズの説明図である。認証処理フェーズは基本的に認証データ取得フェーズ４２と、認証手続きフェーズ４３とに分割される。ここで利用者４１からのリクエストは認証データ取得フェーズ４２に入力され、認証手続きフェーズ４３の結果に対応して認証ＯＫか否かの判定４４が行われ、ＯＫであればアプリケーション４５が起動され、認証失敗の場合には利用者４１にエラーメッセージなどが返される。
【００４５】
認証データ取得フェーズ４２は図５のＨＴＴＰ解析３０から認証方法の決定３２までに対応し、認証に必要なデータとして例えばユーザ名やパスワードなどが、利用者４１から入力されるリクエス内のＨＴＴＰヘッダ、ＨＴＴＰパラメータの解析によって取得される。
【００４６】
認証手続きフェーズ４３では、取得されたデータを使用してユーザ端末の正当性がチェックされる。このチェックにおいては、例えばＬＤＡＰ（ライトウェイト・ディレクトリ・アクセス・プロトコル）認証サービスなどのカセッタブルな構造の認証機構が呼び出されて認証が行われ、認証が成功すればＵＲＬで指定されるアプリケーションの画面が端末側で表示される。
【００４７】
図８〜図１２はそれぞれの認証方式に対応する認証処理フェーズの詳細説明図である。図８は基本認証３３の説明図であり、端末が持つ認証機能（画面）を利用して認証が行われる。
【００４８】
図８において、まずユーザ端末から送られたＨＴＴＰヘッダの中のオーソライゼーション情報が取り出され、ユーザ名やパスワードが取得される。オーソライゼーション情報、すなわちユーザ名やパスワードがない場合には、端末側に認証入力画面を出してもらうためにＨＴＴＰステータスコード４０１が端末側に返される。ユーザ名、パスワードなどが取得できた場合に、認証手続きフェーズが実行される。認証手続きフェーズにおいてユーザ名やパスワードが一致せず認証が失敗した場合には、オーソライゼーション情報がない場合と同様に、ＨＴＴＰステータス４０１を端末に返してユーザ名パスワードの再入力を求めることも可能である。
【００４９】
図９はサブスクライブＩＤ認証３４の説明図である。端末に割当てられたサブスクライブＩＤを利用して認証が行われるために、端末側での認証入力画面は必要がない。
図９においてＨＴＴＰヘッダの解析結果を格納するＨＴＴＰヘッダ解析テーブル（後述）からサブスクライブＩＤが取り出され、そのＩＤがない場合にはエラー画面が作成され、ＨＴＴＰステータス２００としてユーザ端末側に返される。サブスクライブＩＤが取り出された場合には、認証手続きフェーズが呼び出され、サブスクライブＩＤを用いた認証が行われる。この認証が失敗した場合には、ＩＤがない場合と同様に、例えばサブスクライブＩＤが有効でないことを示すエラー画面を端末側に表示させることもできる。
【００５０】
図１０はフォーム認証の説明図である。フォーム認証ではモバイルエージェントの持つログイン画面がユーザ端末側に表示され、認証が行われる。
図１０において、後述するＨＴＴＰパラメータ解析テーブルからユーザ名、パスワード、アプリケーションのＵＲＬが取り出され、ユーザ名やパスワードが取り出されたか否かが判定され、取り出されなかった場合にはログイン画面が作成されて、ＨＴＴＰステータス２００としてその画面がユーザ端末側で表示され、ユーザ名やパスワードの入力が要求される。ユーザ名やパスワードが取得できた場合には、認証手続きフェーズが実行され、認証が失敗した場合にはエラー画面が作成されて、ユーザ端末側に送られる。
【００５１】
図１１はフォームＩＤ、すなわちフォームアンドサブスクライブＩＤ認証の説明図である。ユーザ名の代わりに端末固有のサブスクライブＩＤが使用され、モバイルエージェントの持つログイン画面が必要に応じて利用されて認証が行われる。
【００５２】
図１１においてまずＨＴＴＰヘッダ解析テーブルとＨＴＴＰパラメータ解析テーブルとから、サブスクライブＩＤ、パスワード、およびアプリケーションのＵＲＬが取り出され、サブスクライブＩＤがない場合にはエラー画面が作成され、ＨＴＴＰステータス２００として端末に送られる。
【００５３】
サブスクライブＩＤが取得できた場合には、パスワードが取得できたか否かが判定され、取得できない場合にはパスワードの入力を要求するログイン画面が作成されて、ＨＴＴＰステータス２００としてパスワードの入力がユーザ端末側に要求される。パスワードが取得できた場合には、認証手続きフェーズが実行され、例えばサブスクライブＩＤやパスワードが有効でない場合には、エラー画面が作成されてユーザ端末側に送られることになる。
【００５４】
図１２はナン認証の説明図である。この認証方式は例えばゲストユーザに対する認証方式として用いられるもので、実質的に認証手続きなしでアプリケーションの利用を可能とさせるものである。すなわちこの方式では、認証データ取得フェーズ、認証手続きフェーズがバイパスされ、認証が成功したものとしてアプリケーションの起動が行われる。
【００５５】
次にＨＴＴＰ解析オブジェクト、および端末情報オブジェクトのデータ構造について説明する。まずＨＴＴＰ解析オブジェクトは、ユーザ端末から入力されたＨＴＴＰリクエスト情報を解析した結果の一まとまりのデータであり、前述のようにＨＴＴＰ基本情報、ＨＴＴＰヘッダ解析テーブル、ＨＴＴＰパラメータ解析テーブル、およびクッキー解析テーブルの内容によって構成される。このうちＨＴＴＰ基本情報は、前述のようにアプリケーションのＵＲＬ、コンテンツの長さ、ＨＴＴＰプロトコルのバージョンなどのデータであり、またクッキー解析テーブルも本実施形態に直接の関係がないため、それらの詳細な説明は省略する。
【００５６】
図１３はＨＴＴＰヘッダの例である。このＨＴＴＰヘッダはある通信キャリアに対応する例であるが、本実施形態において用いられるデータは１行目のユーザエージェント、５行目のｘ−ｕｐ−ｓｕｂｎｏ（サブスクライブＩＤに相当）、および１２行目の前述したオーソライゼーション情報である。
【００５７】
図１４は図１３のＨＴＴＰヘッダの情報を変換した結果としてのＨＴＴＰヘッダ解析テーブルのデータ構造の例である。同図のデータは実質的に図１３と同様であるが、パラメータの名称、データ型、およびパラメータの値の欄を持つテーブルに変換されている。
【００５８】
図１５はＨＴＴＰパラメータの例であり、図１６はこのＨＴＴＰパラメータを変換した結果としてのＨＴＴＰパラメータ解析テーブルのデータ形式の例である。図１６において本実施形態で使用されるデータは１行目のユーザ名、２行目のパスワード、３行目のアプリケーションのＵＲＬである。
【００５９】
図１７は端末情報オブジェクトのデータ形式の例である。図３の端末情報リポジトリと端末情報オブジェクトとは実質的に同一の形式である。それらの間の相違は、端末情報リポジトリはファイル内のデータとして提供されることであり、そのファイルの内容を読み込んでメモリに展開すれば端末情報オブジェクトと同じ形式となる。
【００６０】
従って端末情報オブジェクトも、端末の能力を示すデータのまとまりであり、本実施形態では上から３行のユーザ名、パスワード、およびサブスクライブＩＤが認証手続きで利用されるが、これらのデータに加えて各認証方式がサポートされているか否か、端末の能力としての表示可能な色の数、および画面サイズなどのデータが含まれている。
【００６１】
なお以上のＨＴＴＰヘッダ解析テーブル、ＨＴＴＰパラメータ解析テーブル、端末情報オブジェクトなどは図２ではモバイルエージェントサーバ１０内の図示しないメモリに格納され、モバイルエージェント１４によって使用される。
【００６２】
次に本実施形態における処理の詳細について図１８〜図２０を用いて説明する。図１８は図３のＨＴＴＰヘッダ・パラメータ解析２０、端末情報オブジェクトの作成２１の処理フローチャートであり、図１９は端末情報オブジェクトの作成２１の詳細フローチャートである。
【００６３】
図１８において端末からのリクエストに対応して処理が開始されると、まずステップＳ１でＨＴＴＰ情報の解析処理として、端末からのＨＴＴＰリクエストの中のＨＴＴＰヘッダとＨＴＴＰパラメータの解析が行われ、必要な情報がＨＴＴＰ解析オブジェクトとして保存される。
【００６４】
続いてステップＳ２で、ＨＴＴＰ解析オブジェクトの情報からユーザ端末と、例えば図２のウエブサーバ１３の間で行われる一連の通信に対応するセションを特定するためのセションＩＤの獲得が行われ、ステップＳ３でセションＩＤが獲得できたか否かが判定される。セションＩＤは図１４のテーブルの１１行目のクッキーに格納されている。
【００６５】
セションＩＤが獲得できなかった場合には、一連の通信の開始時におけるリクエストと判定され、その一連の通信に対応するセションＩＤがステップＳ４で生成された後に、またセションＩＤが獲得できた場合には直ちに、ステップＳ５の処理に移行する。
【００６６】
ステップＳ５では、ＨＴＴＰ解析オブジェクトと端末情報リポジトリの内容を使用して、端末情報オブジェクトの作成処理が行われる。この処理の詳細は図１９に示す。そしてステップＳ６で一連の通信におけるユーザ端末からの次のリクエストに備えて、端末情報オブジェクトが図３の端末情報オブジェクトキャッシュ２５にキャッシュされ、認証処理に移行する。このキャッシュ処理ではセションＩＤと、端末情報オブジェクトとがペアとして格納される。このキャッシングによって、次のリクエスト時における端末情報リポジトリの読み込みなどの処理を不要とし、性能・効率が向上する。
【００６７】
図１９は図１８のステップＳ５の端末情報オブジェクトの作成処理の詳細フローチャートである。同図において処理が開始されると、まずステップＳ１０でキャッシュ判定が行われる。すなわち端末情報オブジェクトが、図３の端末情報オブジェクトキャッシュ２５にキャッシュ済みかどうかが判定される。前述のように端末情報オブジェクトのキャッシングはセションＩＤをキーとして行われるために、例えば一連の通信としてのセションの開始時には端末情報オブジェクトはキャッシュされておらず、ステップＳ１１以降の処理が行われる。
【００６８】
ステップＳ１１では、リクエストを発行したユーザ端末に対するキャリアがサポートされているか否かが判定される。すなわちＨＴＴＰ解析オブジェクトの内容によって、キャリアのサポートが行われているか否かが判定される。この判定は図１４で説明したＨＴＴＰヘッダ解析テーブル内のデータの１行目の、キャリア毎に特徴のあるユーザエージェントの内容によって行われ、キャリアがサポートされている場合には、ステップＳ１２でキャリアと機種の特定が行われる。機種の特定についても、ユーザエージェントのデータを解析することによって行われる。
【００６９】
続いてステップＳ１３で、特定されたキャリアと機種に対応する端末情報リポジトリが図３の端末情報リポジトリ格納ファイル２６に格納されているか否かが判定され、格納されている場合にはステップＳ１４でその端末情報リポジトリが採用される。
【００７０】
また格納されていない場合には、ステップＳ１５ですでに特定されたキャリアのデフォルト機種に対応する端末情報リポジトリが採用される。更にステップＳ１１でキャリアがサポートされていないと判定された場合には、ステップＳ１６で例えば広範に使用されているパソコン用のインターネットアクセスプログラムに対応する端末情報リポジトリが採用される。
【００７１】
そしてステップＳ１８でステップＳ１４，Ｓ１５、またはＳ１６で採用された端末情報リポジトリをひな形として、ＨＴＴＰヘッダ解析テーブルの情報を用いて端末情報リポジトリ、すなわち端末情報オブジェクトの更新が行われて、ステップＳ１９でＨＴＴＰパラメータ解析テーブルの情報を用いて端末情報リポジトリ、すなわち端末情報オブジェクトの更新が行われて、端末情報オブジェクトの作成処理を終了する。
【００７２】
またステップＳ１０でキャッシュ判定の結果、リクエストを発行した端末に対する端末情報オブジェクトがキャッシュされていると判定された場合には、ステップＳ１７でその端末情報オブジェクトが採用されて、ステップＳ１８以降の処理が行われる。なお、ステップＳ１８，Ｓ１９で行われる更新処理では、例えば端末情報リポジトリがひな形として利用されるが、リクエスト毎に変更される可能性があるパスワードやユーザ名などの更新が行われる。
【００７３】
図２０は図１８の処理に続く認証処理の詳細フローチャートである。同図において処理が開始されると、まずステップＳ２１で認証方式候補リストが作成される。このリスト作成処理は図３の設定ファイル２７の内容、すなわち図４で説明した認証方式の優先順位に応じたリストを作成するものであり、この処理はモバイルエージェントシステムの初期化時に１回だけ行われてもよく、また認証方式候補リストを作成する代わりに、図４の認証方式の優先順位を読み込むだけでもよいことになる。
【００７４】
ステップＳ２２で認証方式決定処理ループの初期化処理として、認証方式を求めるためのカウンタのカウント値ｎが０に設定され、ステップＳ２３およびＳ２４によって構成されるループの処理が行われる。すなわちステップＳ２３ではカウンタｎの値がインクリメントされ、まずリストの１番目、すなわち優先順位の最も高い認証方式が取り出され、ステップＳ２４でその認証方式が使用可能か否かが判定される。この判定では、端末情報オブジェクトの内容によって、リクエストを発行したユーザ端末がその認証方式をサポートしているか否かが判定される。使用可能でない場合にはステップＳ２３に戻り、ｎの値をインクリメントし、２番目の認証方式以降についてステップＳ２３、およびＳ２４の処理が繰り返される。
【００７５】
ステップＳ２４で取り出されたｎ番目の認証方式が使用可能であると判定された場合には、ステップ２５でその認証方式の採用が決定され、ステップＳ２６でその認証方式に対応する認証手続きが呼び出され、認証に必要なユーザ名、パスワードなどの情報がＨＴＴＰ解析オブジェクトから獲得されて渡され、認証処理が実行される。
【００７６】
そしてステップＳ２７で認証が成功したか否かが判定され、認証が成功していればアプリケーションの呼び出し処理が行われる。この認証の成功の判定は、認証手続きからの復帰情報の参照によって判断される。
【００７７】
ステップＳ２３，ステップＳ２４の処理が認証方式候補リストにリストされているｎ個の認証方式の全てに対して繰り返され、使用可能な認証方式がないと判定された場合、およびステップＳ２７で認証が失敗したと判定された場合には、ステップＳ２８で認証失敗のメッセージが端末に通知され、処理を終了する。
【００７８】
以上において本発明のユーザ端末認証プログラムとしてのモバイルエージェントなどについてその詳細を説明したが、このモバイルエージェントは当然一般的なコンピュータシステムによって実現されることが可能である。図２１はそのようなコンピュータシステム、すなわちハードウェア環境の構成ブロック図である。
【００７９】
図２１においてコンピュータシステムは中央処理装置（ＣＰＵ）９０、リードオンリメモリ（ＲＯＭ）９１、ランダムアクセスメモリ（ＲＡＭ）９２、通信インタフェース９３、記憶装置９４、入出力装置９５、可搬型記憶媒体の読取り装置９６、およびこれらの全てが接続されたバス９７によって構成されている。
【００８０】
記憶装置９４としては、ハードディスク、磁気ディスクなど様々な形式の記憶装置を使用することができ、このような記憶装置９４、またはＲＯＭ９１に図５、図７、図１８〜図２０などのシーケンス図やフローチャートに示されたプログラムや、本発明の特許請求の範囲の請求項１〜５のプログラムなどが格納され、そのようなプログラムがＣＰＵ９０によって実行されることにより、本実施形態におけるユーザ端末の動的認証が可能となる。
【００８１】
このようなプログラムは、プログラム提供者９８側からネットワーク９９、および通信インタフェース９３を介して、例えば記憶装置９４に格納されることも、また市販され、流通している可搬型記憶媒体１００に格納され、読取り装置９６にセットされて、ＣＰＵ９０によって実行されることも可能である。可搬型記憶媒体１００としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスクなど様々な形式の記憶媒体を使用することができ、このような記憶媒体に格納されたプログラムが読取り装置９６によって読取られることにより、本実施形態における、あらかじめ設定されている認証方式の優先順位に対応した端末認証などが可能となる。
【００８２】
以上詳細に説明したように本発明によれば、１つのウエブシステムのみで複数の端末種別、および複数の認証方式をサポートすることが可能となり、ウエブシステムの作成メンテナンスの手間を減少させ、資源の利用を効率化させることができ、コンテンツ作成者は端末能力を意識せずに本来のコンテンツ作成作業に専念可能となる。
【００８３】
端末からのサービスクリエイトに対応して端末情報オブジェクトを作成することによって、端末の能力に応じた最適な認証方式をダイナミックに選択することができ、また認証方式の優先順位を変更することによって、選択される認証方式を簡単に変更することができる。端末種別が不明の場合にも、デフォルトの端末情報リポジトリを利用することによって、端末情報オブジェクトの作成が可能となり、未知の端末に対しても認証処理が可能となる。
【００８４】
（付記１）ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う計算機によって使用されるプログラムにおいて、
該リクエストのデータを用いて、前記ユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成する手順と、
該端末情報オブジェクトの内容に対応して、複数の認証方式の中から該ユーザ端末に適する認証方式を選択する手順と、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行する手順とを計算機に実行させるためのユーザ端末認証プログラム。
【００８５】
（付記２）前記計算機が、機種に応じた端末の認証に関するデータを示す端末情報リポジトリの記憶手段を備え、
前記端末情報オブジェクトの作成手順において、前記ユーザ端末からのリクエストのデータにおいて不足しているデータを該端末情報リポジトリの内容を用いて充足し、該端末情報オブジェクトを作成することを特徴とする付記１記載のユーザ端末認証プログラム。
【００８６】
（付記３）前記計算機が、デフォルトの端末の認証に関するデータを示すデフォルト端末情報リポジトリの記憶手段を備え、
前記ユーザ端末の機種が不明の時、前記端末情報オブジェクトの作成手順において、前記ユーザ端末からのリクエストのデータにおいて不足しているデータを該デフォルト端末情報リポジトリの内容を用いて充足し、該端末情報オブジェクトを作成することを特徴とする付記１記載のユーザ端末認証プログラム。
【００８７】
（付記４）前記計算機が、複数の認証方式の間の優先順位を記憶する手段を備え、
前記認証方式の選択手順において、前記端末情報オブジェクトの内容に対応して、前記ユーザ端末に適用可能な認証方式のうちで優先順位の高い認証方式を選択することを特徴とする付記１記載のユーザ端末認証プログラム。
【００８８】
（付記５）前記計算機が、前記端末情報オブジェクトの作成手順において作成された端末情報オブジェクトを、同一ユーザ端末からの一連の通信における次回のサービスのリクエストに備えて記憶する手段を備え、
ユーザ端末からの次のサービスのリクエストに対応して、前記端末情報オブジェクトの作成手順において該端末情報オブジェクトの記憶手段の記憶内容を利用することを特徴とする付記１記載のユーザ端末認証プログラム。
【００８９】
（付記６）ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う装置において、
該リクエストのデータを用いて、前記ユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成する手段と、
該端末情報オブジェクトの内容に対応して、複数の認証方式の中から該ユーザ端末に適する認証方式を選択する手段と、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行する手段とを備えることを特徴とするユーザ端末認証装置。
【００９０】
（付記７）ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う方法おいて、
該リクエストのデータを用いて、前記ユーザ端末の認証に関するデータを示し、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成し、
該端末情報オブジェクトの内容に対応して、複数の認証方式の中から該ユーザ端末に適する認証方式を選択し、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行することを特徴とするユーザ端末認証方法。
【００９１】
（付記８）ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う計算機によって使用される記憶媒体において、
該リクエストのデータを用いて、前記ユーザ端末の認証に関するデータを示し 、端末の機種に依存しない統一形式の端末情報オブジェクトを動的に作成するステップと、
該端末情報オブジェクトの内容に対応して、複数の認証方式の中から該ユーザ 端末に適する認証方式を選択するステップと、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行するステップとを計算機に実行させるためのプログラムを格納した計算機読み出し可能可搬型記憶媒体。
【図面の簡単な説明】
【００９２】
【図１】本発明の原理的な機能ブロック図である。
【図２】モバイルエージェントを含む認証システムの構成ブロック図である。
【図３】モバイルエージェントによる処理の基本的な説明図である。
【図４】設定ファイルの内容の例の説明図である。
【図５】認証処理の基本的なシーケンスの説明図である。
【図６】認証方式判定用マトリックスの説明図である。
【図７】認証処理フェーズの説明図である。
【図８】基本認証の説明図である。
【図９】サブスクライブＩＤ認証の説明図である。
【図１０】フォーム認証の説明図である。
【図１１】フォームアンドサブスクライブＩＤ認証の説明図である。
【図１２】ナン認証の説明図である。
【図１３】ＨＴＴＰヘッダの例を示す図である。
【図１４】ＨＴＴＰヘッダ解析テーブルのデータ形式を示す図である。
【図１５】ＨＴＴＰパラメータの例を示す図である。
【図１６】ＨＴＴＰパラメータ解析テーブルのデータ形式を示す図である。
【図１７】端末情報オブジェクトのデータ形式を示す図である。
【図１８】ＨＴＴＰヘッダ・パラメータ解析および端末情報オブジェクト作成処理のフローチャートである。
【図１９】端末情報オブジェクト作成処理の詳細フローチャートである。
【図２０】認証処理の詳細フローチャートである。
【図２１】本発明におけるプログラムのコンピュータへのローディングを説明する図である。
【符号の説明】
【００９３】
１０ モバイルエージェントサーバ
１１，２８ 認証データベース（ＤＢ）
１２ オペレーティングシステム
１３ ウエブサーバ
１４ モバイルエージェント
１５ ウエブアプリケーション
２０ ＨＴＴＰヘッダ・パラメータ解析
２１ 端末情報オブジェクトの作成
２２ 認証処理
２３ アプリケーション起動
２５ 端末情報オブジェクトキャッシュ
２６ 端末情報リポジトリ格納ファイル
２７ 設定ファイル
【特許請求の範囲】
【請求項１】
ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う計算機によって使用されるプログラムにおいて、
前記リクエストを送信するパケットのヘッダを解析することにより、前記ユーザ端末が利用する通信キャリアを表すキャリア情報およびそのユーザ端末の機種を表す機種情報を取得する手順と、
前記ユーザ端末が利用可能な認証方式を表す認証方式情報が前記ヘッダに格納されている場合には、そのヘッダから前記ユーザ端末に係わる認証方式情報を取得し、前記認証方式情報が前記ヘッダに格納されていない場合には、前記ヘッダから取得したキャリア情報および機種情報を利用して機種毎に端末の能力および認証に係わる情報を格納する端末情報レポジトリから前記ユーザ端末に係わる認証方式情報を取得する手順と、
前記取得した認証方式情報を含む端末情報オブジェクトを動的に作成する手順と、
該端末情報オブジェクトに含まれている認証方式情報に基づいて、複数の認証方式の中から該ユーザ端末に適する認証方式を選択する手順と、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行する手順
を計算機に実行させるプログラムであり、
前記計算機が、複数の認証方式の間の優先順位を記憶する手段を備え、
前記認証方式の選択手順において、前記端末情報オブジェクトの内容に対応して、前記ユーザ端末に適用可能な認証方式のうちで優先順位の高い認証方式を選択する
ことを特徴とするユーザ端末認証プログラム。
【請求項２】
前記計算機が、未知の端末に対して実行すべき認証方式が定義されたデフォルト端末情報リポジトリの記憶手段を備え、
前記ユーザ端末の機種が不明の時、前記端末情報オブジェクトの作成手順において、前記ユーザ端末からのリクエストのデータにおいて不足しているデータを該デフォルト端末情報リポジトリの内容を用いて充足し、該端末情報オブジェクトを作成する
ことを特徴とする請求項１記載のユーザ端末認証プログラム。
【請求項３】
前記計算機が、前記端末情報オブジェクトの作成手順において作成された端末情報オブジェクトを、同一ユーザ端末からの一連の通信における次回のサービスのリクエストに備えて記憶する手段を備え、
ユーザ端末からの次のサービスのリクエストに対応して、前記端末情報オブジェクトの作成手順において該端末情報オブジェクトの記憶手段の記憶内容を利用する
ことを特徴とする請求項１記載のユーザ端末認証プログラム。
【請求項４】
ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う装置において、
前記リクエストを送信するパケットのヘッダを解析することにより、前記ユーザ端末が利用する通信キャリアを表すキャリア情報およびそのユーザ端末の機種を表す機種情報を取得する手段と、
前記ユーザ端末が利用可能な認証方式を表す認証方式情報が前記ヘッダに格納されている場合には、そのヘッダから前記ユーザ端末に係わる認証方式情報を取得し、前記認証方式情報が前記ヘッダに格納されていない場合には、前記ヘッダから取得したキャリア情報および機種情報を利用して機種毎に端末の能力および認証に係わる情報を格納する端末情報レポジトリから前記ユーザ端末に係わる認証方式情報を取得する手段と、
前記取得した認証方式情報を含む端末情報オブジェクトを動的に作成する手段と、
該端末情報オブジェクトに含まれている認証方式情報に基づいて、複数の認証方式の中から該ユーザ端末に適する認証方式を選択する手段と、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行する手段と、
複数の認証方式の間の優先順位を記憶する手段、を備え、
前記認証方式を選択する手段は、前記端末情報オブジェクトの内容に対応して、前記ユーザ端末に適用可能な認証方式のうちで優先順位の高い認証方式を選択する
ことを特徴とするユーザ端末認証装置。
【請求項５】
ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う方法おいて、
前記リクエストを送信するパケットのヘッダを解析することにより、前記ユーザ端末が利用する通信キャリアを表すキャリア情報およびそのユーザ端末の機種を表す機種情報を取得する手順と、
前記ユーザ端末が利用可能な認証方式を表す認証方式情報が前記ヘッダに格納されている場合には、そのヘッダから前記ユーザ端末に係わる認証方式情報を取得し、前記認証方式情報が前記ヘッダに格納されていない場合には、前記ヘッダから取得したキャリア情報および機種情報を利用して機種毎に端末の能力および認証に係わる情報を格納する端末情報レポジトリから前記ユーザ端末に係わる認証方式情報を取得する手順と、
前記取得した認証方式情報を含む端末情報オブジェクトを動的に作成する手順と、
該端末情報オブジェクトに含まれている認証方式情報に基づいて、複数の認証方式の中から該ユーザ端末に適する認証方式を選択する手順と、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行する手順、を備え、
前記認証方式の選択手順において、前記端末情報オブジェクトの内容に基づいて、複数の認証方式の間の優先順位を記憶する記憶手段を参照することにより、前記ユーザ端末に適用可能な認証方式のうちで優先順位の高い認証方式を選択する
ことを特徴とするユーザ端末認証方法。
【請求項６】
ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う計算機によって使用されるプログラムにおいて、
前記リクエストを送信するパケットのヘッダを解析することにより、前記ユーザ端末が利用する通信キャリアを表すキャリア情報およびそのユーザ端末の機種を表す機種情報を取得する手順と、
前記ユーザ端末が利用可能な認証方式を表す認証方式情報が前記ヘッダに格納されている場合には、そのヘッダから前記ユーザ端末に係わる認証方式情報を取得し、前記認証方式情報が前記ヘッダに格納されていない場合には、前記ヘッダから取得したキャリア情報および機種情報を利用して機種毎に端末の能力および認証に係わる情報を格納する端末情報レポジトリから前記ユーザ端末に係わる認証方式情報を取得する手順と、
前記取得した認証方式情報に基づいて、複数の認証方式の中から該ユーザ端末に適する認証方式を選択する手順と、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行する手順
を計算機に実行させるプログラムであり、
前記計算機が、複数の認証方式の間の優先順位を記憶する手段を備え、
前記認証方式の選択手順において、前記認証方式情報の内容に対応して、前記ユーザ端末に適用可能な認証方式のうちで優先順位の高い認証方式を選択する
ことを特徴とするユーザ端末認証プログラム。
【請求項１】
ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う計算機によって使用されるプログラムにおいて、
前記リクエストを送信するパケットのヘッダを解析することにより、前記ユーザ端末が利用する通信キャリアを表すキャリア情報およびそのユーザ端末の機種を表す機種情報を取得する手順と、
前記ユーザ端末が利用可能な認証方式を表す認証方式情報が前記ヘッダに格納されている場合には、そのヘッダから前記ユーザ端末に係わる認証方式情報を取得し、前記認証方式情報が前記ヘッダに格納されていない場合には、前記ヘッダから取得したキャリア情報および機種情報を利用して機種毎に端末の能力および認証に係わる情報を格納する端末情報レポジトリから前記ユーザ端末に係わる認証方式情報を取得する手順と、
前記取得した認証方式情報を含む端末情報オブジェクトを動的に作成する手順と、
該端末情報オブジェクトに含まれている認証方式情報に基づいて、複数の認証方式の中から該ユーザ端末に適する認証方式を選択する手順と、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行する手順
を計算機に実行させるプログラムであり、
前記計算機が、複数の認証方式の間の優先順位を記憶する手段を備え、
前記認証方式の選択手順において、前記端末情報オブジェクトの内容に対応して、前記ユーザ端末に適用可能な認証方式のうちで優先順位の高い認証方式を選択する
ことを特徴とするユーザ端末認証プログラム。
【請求項２】
前記計算機が、未知の端末に対して実行すべき認証方式が定義されたデフォルト端末情報リポジトリの記憶手段を備え、
前記ユーザ端末の機種が不明の時、前記端末情報オブジェクトの作成手順において、前記ユーザ端末からのリクエストのデータにおいて不足しているデータを該デフォルト端末情報リポジトリの内容を用いて充足し、該端末情報オブジェクトを作成する
ことを特徴とする請求項１記載のユーザ端末認証プログラム。
【請求項３】
前記計算機が、前記端末情報オブジェクトの作成手順において作成された端末情報オブジェクトを、同一ユーザ端末からの一連の通信における次回のサービスのリクエストに備えて記憶する手段を備え、
ユーザ端末からの次のサービスのリクエストに対応して、前記端末情報オブジェクトの作成手順において該端末情報オブジェクトの記憶手段の記憶内容を利用する
ことを特徴とする請求項１記載のユーザ端末認証プログラム。
【請求項４】
ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う装置において、
前記リクエストを送信するパケットのヘッダを解析することにより、前記ユーザ端末が利用する通信キャリアを表すキャリア情報およびそのユーザ端末の機種を表す機種情報を取得する手段と、
前記ユーザ端末が利用可能な認証方式を表す認証方式情報が前記ヘッダに格納されている場合には、そのヘッダから前記ユーザ端末に係わる認証方式情報を取得し、前記認証方式情報が前記ヘッダに格納されていない場合には、前記ヘッダから取得したキャリア情報および機種情報を利用して機種毎に端末の能力および認証に係わる情報を格納する端末情報レポジトリから前記ユーザ端末に係わる認証方式情報を取得する手段と、
前記取得した認証方式情報を含む端末情報オブジェクトを動的に作成する手段と、
該端末情報オブジェクトに含まれている認証方式情報に基づいて、複数の認証方式の中から該ユーザ端末に適する認証方式を選択する手段と、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行する手段と、
複数の認証方式の間の優先順位を記憶する手段、を備え、
前記認証方式を選択する手段は、前記端末情報オブジェクトの内容に対応して、前記ユーザ端末に適用可能な認証方式のうちで優先順位の高い認証方式を選択する
ことを特徴とするユーザ端末認証装置。
【請求項５】
ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う方法おいて、
前記リクエストを送信するパケットのヘッダを解析することにより、前記ユーザ端末が利用する通信キャリアを表すキャリア情報およびそのユーザ端末の機種を表す機種情報を取得する手順と、
前記ユーザ端末が利用可能な認証方式を表す認証方式情報が前記ヘッダに格納されている場合には、そのヘッダから前記ユーザ端末に係わる認証方式情報を取得し、前記認証方式情報が前記ヘッダに格納されていない場合には、前記ヘッダから取得したキャリア情報および機種情報を利用して機種毎に端末の能力および認証に係わる情報を格納する端末情報レポジトリから前記ユーザ端末に係わる認証方式情報を取得する手順と、
前記取得した認証方式情報を含む端末情報オブジェクトを動的に作成する手順と、
該端末情報オブジェクトに含まれている認証方式情報に基づいて、複数の認証方式の中から該ユーザ端末に適する認証方式を選択する手順と、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行する手順、を備え、
前記認証方式の選択手順において、前記端末情報オブジェクトの内容に基づいて、複数の認証方式の間の優先順位を記憶する記憶手段を参照することにより、前記ユーザ端末に適用可能な認証方式のうちで優先順位の高い認証方式を選択する
ことを特徴とするユーザ端末認証方法。
【請求項６】
ユーザ端末からのサービスのリクエストに対応して該ユーザ端末の認証を行う計算機によって使用されるプログラムにおいて、
前記リクエストを送信するパケットのヘッダを解析することにより、前記ユーザ端末が利用する通信キャリアを表すキャリア情報およびそのユーザ端末の機種を表す機種情報を取得する手順と、
前記ユーザ端末が利用可能な認証方式を表す認証方式情報が前記ヘッダに格納されている場合には、そのヘッダから前記ユーザ端末に係わる認証方式情報を取得し、前記認証方式情報が前記ヘッダに格納されていない場合には、前記ヘッダから取得したキャリア情報および機種情報を利用して機種毎に端末の能力および認証に係わる情報を格納する端末情報レポジトリから前記ユーザ端末に係わる認証方式情報を取得する手順と、
前記取得した認証方式情報に基づいて、複数の認証方式の中から該ユーザ端末に適する認証方式を選択する手順と、
該選択された認証方式を用いて該ユーザ端末に対する認証手続きを実行する手順
を計算機に実行させるプログラムであり、
前記計算機が、複数の認証方式の間の優先順位を記憶する手段を備え、
前記認証方式の選択手順において、前記認証方式情報の内容に対応して、前記ユーザ端末に適用可能な認証方式のうちで優先順位の高い認証方式を選択する
ことを特徴とするユーザ端末認証プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２００７−３０５１４０（Ｐ２００７−３０５１４０Ａ）
【公開日】平成１９年１１月２２日（２００７．１１．２２）
【国際特許分類】
【出願番号】特願２００７−１４６８２６（Ｐ２００７−１４６８２６）
【出願日】平成１９年６月１日（２００７．６．１）
【分割の表示】特願２００１−３５３７１０（Ｐ２００１−３５３７１０）の分割
【原出願日】平成１３年１１月１９日（２００１．１１．１９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ｉモード
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成１９年１１月２２日（２００７．１１．２２）
【国際特許分類】
【出願日】平成１９年６月１日（２００７．６．１）
【分割の表示】特願２００１−３５３７１０（Ｐ２００１−３５３７１０）の分割
【原出願日】平成１３年１１月１９日（２００１．１１．１９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ｉモード
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]