(57)【特許請求の範囲】
【請求項１】
インターネットサービスを提供するための方法であって、
独立系ソフトウェアベンダー（ＩＳＶ）によって提供されたアプリケーションのユーザによって開始されたサービス要求メッセージを受信する工程と、前記サービス要求メッセージは、アプリケーションプログラミングインターフェース（ＡＰＩ）タイプに従って実装され、前記ＡＰＩタイプに適合する複数のプラットフォームレベルパラメータを含み、前記ＡＰＩタイプはサービスレベルに関連付けられていることと、
前記サービスレベルに応じて前記ＡＰＩタイプに適切な１組の認証チェックを決定し、
前記１組の認証チェックに従って、前記サービス要求メッセージの認証を実行し、
前記サービス要求メッセージが認証されると、インターネットサービスプロバイダ（ＩＳＰ）のサービスアドレスまで前記サービス要求メッセージをルーティングすること、
を備える、方法。
【請求項２】
請求項１に記載の方法であって、前記ＡＰＩタイプは、匿名アクセスタイプを含み、前記１組の認証チェックは、ゼロエレメントを含む、方法。
【請求項３】
請求項２に記載の方法であって、前記複数のプラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、および、サービス名である、方法。
【請求項４】
請求項１に記載の方法であって、前記ＡＰＩタイプは、許可サービスタイプを含み、前記１組の認証チェックは、署名チェックおよびタイムスタンプチェックを含む、方法。
【請求項５】
請求項４に記載の方法であって、前記プラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、および、署名である、方法。
【請求項６】
請求項１に記載の方法であって、前記ＡＰＩタイプは、ユーザ許可サービスタイプを含み、前記１組の認証チェックは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックを含む、方法。
【請求項７】
請求項６に記載の方法であって、前記プラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、署名、および、前記ＩＳＶのアプリケーションにおけるユーザセッションの一意のＩＤである、方法。
【請求項８】
請求項１に記載の方法であって、前記ＡＰＩタイプは、オプションユーザ許可サービスタイプを含み、前記１組の認証チェックは、署名チェック、タイムスタンプチェック、および、オプションでユーザＩＤチェックを含む、方法。
【請求項９】
請求項８に記載の方法であって、前記プラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、および、署名である、方法。
【請求項１０】
請求項１に記載の方法であって、前記１組の認証チェックは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックの内の１または複数を含む、方法。
【請求項１１】
請求項１に記載の方法であって、前記プラットフォームレベルパラメータは、前記独立系ソフトウェアベンダーのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、署名、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤ、および、戻り値のタイプの内の１または複数を含む、方法。
【請求項１２】
請求項１に記載の方法であって、さらに、ユーザバインディングエラー情報を返すことを備える、方法。
【請求項１３】
請求項１２に記載の方法であって、前記プラットフォームレベルパラメータは、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤを含み、前記サービス要求メッセージ認証が失敗すると、ユーザバインディングエラー情報が返される、方法。
【請求項１４】
請求項１に記載の方法であって、さらに、
前記プラットフォームレベルパラメータが、サービスのインターネットサービスプロバイダＩＤ、前記独立系ソフトウェアベンダーのサービスを呼び出すためのＩＤ証明、および、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤを含む場合に、キャッシュ内のトークンリストを取得し、
トークンが存在し、かつ、有効であるか否かを判定し、
トークンが存在しない、あるいは、前記トークンが無効である場合に、ユーザバインディングエラー情報を返すこと、
を備える、方法。
【請求項１５】
請求項１２に記載の方法であって、さらに、
前記ユーザバインディングエラー情報の受信後に前記ＩＳＰのログインアドレスに対して第２のサービス要求メッセージを開始することを備え、
前記第２のサービス要求メッセージは、自身のプラットフォームレベルパラメータとして、前記独立系ソフトウェアベンダーのサービスを呼び出すためのＩＤ証明、サービス名、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤ、および、ユーザバインディングにパスした後に前記独立系ソフトウェアベンダーのアプリケーションのリダイレクト先となるアドレスを含む、方法。
【請求項１６】
インターネットサービスを提供するためのサービス統合プラットフォームシステムであって、
独立系ソフトウェアベンダー（ＩＳＶ）によって提供されたアプリケーションのユーザによって開始されたサービス要求メッセージを受信するよう構成されたインターフェースと、前記サービス要求メッセージは、アプリケーションプログラミングインターフェース（ＡＰＩ）タイプに従って実装され、前記ＡＰＩタイプに適合する複数のプラットフォームレベルパラメータを含み、前記ＡＰＩタイプはサービスレベルに関連付けられていることと、
前記インターフェースに接続された１または複数のプロセッサと、
を備え、
前記１または複数のプロセッサは、
前記サービスレベルに応じて前記ＡＰＩタイプに適切な１組の認証チェックを位置特定し、
前記１組の認証チェックに従って、前記サービス要求の認証を実行し、
前記サービス要求が認証されると、インターネットサービスプロバイダ（ＩＳＰ）のサービスアドレスまで前記サービス要求をルーティングするよう構成されている、システム。
【請求項１７】
請求項１６に記載のシステムであって、前記ＡＰＩタイプは、匿名アクセスタイプを含み、前記１組の認証チェックは、ゼロエレメントを含む、システム。
【請求項１８】
請求項１７に記載のシステムであって、前記複数のプラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、および、サービス名である、システム。
【請求項１９】
請求項１６に記載のシステムであって、前記ＡＰＩタイプは、許可サービスタイプを含み、前記１組の認証チェックは、署名チェックおよびタイムスタンプチェックを含む、システム。
【請求項２０】
請求項１９に記載の方法であって、前記プラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、および、署名である、方法。
【請求項２１】
請求項１６に記載のシステムであって、前記ＡＰＩタイプは、ユーザ許可サービスタイプを含み、前記１組の認証チェックは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックを含む、システム。
【請求項２２】
請求項２１に記載のシステムであって、前記プラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、署名、および、前記ＩＳＶのアプリケーションにおけるユーザセッションの一意のＩＤである、システム。
【請求項２３】
請求項１６に記載のシステムであって、前記ＡＰＩタイプは、オプションユーザ許可サービスタイプを含み、前記１組の認証チェックは、署名チェック、タイムスタンプチェック、および、オプションでユーザＩＤチェックを含む、システム。
【請求項２４】
請求項２３に記載のシステムであって、前記プラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、および、署名である、システム。
【請求項２５】
請求項１６に記載のシステムであって、前記１組の認証チェックは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックの内の１または複数を含む、システム。
【請求項２６】
請求項１６に記載のシステムであって、前記プラットフォームレベルパラメータは、前記独立系ソフトウェアベンダーのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、署名、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤ、および、戻り値のタイプの内の１または複数を含む、システム。
【請求項２７】
請求項１６に記載のシステムであって、さらに、ユーザバインディングエラー情報を返すことを備える、システム。
【請求項２８】
請求項２７に記載のシステムであって、前記プラットフォームレベルパラメータは、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤを含み、前記サービス要求メッセージ認証が失敗すると、ユーザバインディングエラー情報が返される、システム。
【請求項２９】
請求項１６に記載のシステムであって、前記１または複数のプロセッサは、さらに、
前記プラットフォームレベルパラメータが、サービスのインターネットサービスプロバイダＩＤ、前記独立系ソフトウェアベンダーのサービスを呼び出すためのＩＤ証明、および、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤを含む場合に、キャッシュ内のトークンリストを取得し、
トークンが存在し、かつ、有効であるか否かを判定し、
トークンが存在しない、あるいは、前記トークンが無効である場合に、ユーザバインディングエラー情報を返すよう構成されている、システム。
【請求項３０】
請求項２７に記載のシステムであって、前記１または複数のプロセッサは、さらに、
前記ユーザバインディングエラー情報の受信後に前記ＩＳＰのログインアドレスに対して第２のサービス要求メッセージを開始するよう構成されており、
前記第２のサービス要求メッセージは、自身のプラットフォームレベルパラメータとして、前記独立系ソフトウェアベンダーのサービスを呼び出すためのＩＤ証明、サービス名、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤ、および、ユーザバインディングにパスした後に前記独立系ソフトウェアベンダーのアプリケーションのリダイレクト先になるアドレスを含む、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００８年６月２６日付けで出願され「A METHOD FOR PROVIDING INTERNET SERVICES AND SERVICE INTEGRATION PLATFORM SYSTEM（インターネットサービスを提供するための方法およびサービス統合プラットフォームシステム）」と題された中国特許出願第２００８１０１２６１１３．０号の優先権を主張する。この出願は、あらゆる目的のために参照によって本明細書に組み込まれる
【０００２】
本発明は、ネットワークアプリケーションに関し、特に、インターネットサービスおよびサービス統合プラットフォームシステムを提供するための方法に関する。
【背景技術】
【０００３】
サービス指向アーキテクチャ（ＳＯＡ）がますます成熟し、リプリゼンテーショナル・ステート・トランスファ（ＲＥＳＴ）スタイルがますます一般的になるにつれて、インターネットサービスの提供が増加している。また、従来のインターネットソフトウエア企業は、新たな役割を試み初めている。サービスプロバイダとしてのインターネットサービスプロバイダ（ＩＳＰ）は、ウェブサイトの開発のための新たなオープンモードを提供するために、自身のサービスリソースを公開し、内部のデータを一般に公開し始めている。また、一方で、ウェブ２．０の多様なアプリケーションにより、顧客要求を考慮して、ネットワークで利用可能なサービスリソースを活用して様々な対話型アプリケーションを設計し、様々なサービスプロバイダによって提供されるサービスを統合して革新的なソフトウェア製品を作り出す多くの独立系ソフトウェアベンダー（ＩＳＶ）が育っている。
【０００４】
このサービス指向の新しい開発モードは、また、急速に更新されることが多いインターネットアプリケーションの革新的な性質を理由に提案されている。いくつかの大規模なウェブサイトでの成功例において、ＩＳＶ開発者は、ユーザを惹きつけるために、オープンアプリケーションプログラムインターフェース（ＡＰＩ）を用いてそれらのウェブサイト向けのアプリケーションを開発している。オープンＡＰＩを提供する既存のウェブサイトは、たいてい単一のＩＳＰだけに対応しているため、一般的に、柔軟性のないセキュリティモデルを有する。
【図面の簡単な説明】
【０００５】
【図１】典型的なセキュリティ制御プログラムの一実装例を示す概略図。
【図２】インターネットサービスを提供するためのプロセスの一実施形態を示すフローチャート。
【図３】セキュリティ制御フローのプロセスの一実施形態を示すフローチャート。
【図４】ユーザをバインディングするためのプロセスの一実施形態を示すフローチャート。
【図５】インターネットサービスを提供するためのサービス統合プラットフォームシステムの一実施形態を示す概略図。
【発明を実施するための形態】
【０００６】
本発明は、処理、装置、システム、物質の組成、コンピュータ読み取り可能な格納媒体上に具現化されたコンピュータプログラム製品、および／または、プロセッサ（プロセッサに接続されたメモリに格納および／またはそのメモリによって提供される命令を実行するよう構成されたプロセッサ）を含め、様々な形態で実装されうる。本明細書では、これらの実装または本発明が取りうる任意の他の形態を、技術と呼ぶ。一般に、開示された処理の工程の順序は、本発明の範囲内で変更されてもよい。特に言及しない限り、タスクを実行するよう構成されるものとして記載されたプロセッサまたはメモリなどの構成要素は、ある時間にタスクを実行するよう一時的に構成された一般的な構成要素として、または、タスクを実行するよう製造された特定の構成要素として実装されてよい。本明細書では、「プロセッサ」という用語は、１または複数のデバイス、回路、および／または、コンピュータプログラム命令などのデータを処理するよう構成された処理コアを指すものとする。
【０００７】
以下では、本発明の原理を示す図面を参照しつつ、本発明の１または複数の実施形態の詳細な説明を行う。本発明は、かかる実施形態に関連して説明されているが、どの実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定されるものであり、多くの代替物、変形物、および、等価物を含む。以下の説明では、本発明の完全な理解を提供するために、多くの具体的な詳細事項が記載されている。これらの詳細事項は、例示を目的としたものであり、本発明は、これらの具体的な詳細事項の一部または全てがなくとも特許請求の範囲に従って実施可能である。簡単のために、本発明に関連する技術分野で周知の技術事項については、本発明が必要以上にわかりにくくならないように、詳細には説明していない。
【０００８】
図１は、典型的なセキュリティ制御プログラムの一実装例を示す概略図である。この例において、典型的なオープンアプリケーションプログラムインターフェース（オープンＡＰＩ）のためのセキュリティ制御プログラムは、アプリケーションプログラムインターフェース（ＡＰＩ）を介してユーザの情報を取得するためのＩＳＶアプリケーション要求を主に扱う。
【０００９】
工程１０１において、ウェブアプリケーションが、ＡｕｔｈＳｕｂハイパーテキストトランスポートプロトコル（ＨＴＴＰ）要求を、アカウント認証プロキシサーバに送信する。ウェブアプリケーションが、ユーザ情報に関連するサービスにアクセスする必要がある場合、ＡｕｔｈＳｕｂ要求が生成されてアカウント認証プロキシサーバに送られる。
【００１０】
工程１０２において、アカウント認証プロキシサーバは、ウェブアプリケーションのユーザにアクセス許諾ページを提示する。アプリケーションサーバは、アプリケーションがＡＰＩを介してユーザ情報を取得することを許可するか否か確認する。一方、ユーザがアプリケーションへのアクセスを試みるのが始めてである場合には、ログイン動作をするよう指示される。
【００１１】
工程１０３において、ユーザはログインデータを返す。アクセスが拒否された場合、アプリケーションページではなくデフォルトページが返される。
【００１２】
工程１０４において、アカウント認証プロキシサーバは、ウェブアプリケーションに固有のトークンと共にリダイレクトを返す。ユーザがアプリケーションへのアクセスを許可される場合、認証サービスはアプリケーションページにリダイレクトされ、トークンはユーザＩＤとして用いられる。
【００１３】
工程１０５において、ウェブアプリケーションは、トークンと共にサービス要求をサービスアクセスサーバに送信する。アプリケーションは、トークン／ユーザＩＤを用いて、サービスの要求を行う。サービスアクセスサーバは、トークンのチェック後、要求を受け入れる。
【００１４】
工程１０６において、サービスアクセスサーバは、処理後に、サービス呼び出しの結果（すなわち、サービスからの応答）をウェブアプリケーションに返す。
【００１５】
トークン管理に関して、サイトは、トークンに対する２種類の制限を有する。一方の種類の制限は、使用の範囲である。サービスごとに、独自のトークンが適用される。他方の種類の制限は、使用の有効期間である。トークンは、ワンタイムトークンおよびセッショントークンに分類される。前者は、１回だけ使用することができ、後者は複数回使用できる。
【００１６】
現在のところ、既存のセキュリティ戦略は、単一ＩＳＰの状況にのみ対処する。例えば、既存のウェブサイトは、専用のＡｕｔｈＳｕｂ要求の送信を必要とする。セキュリティ戦略は、単一のＩＳＰを含む状況にだけ対処するため、比較的柔軟性がなく、複数のＩＳＰに容易に対応することができない。
【００１７】
さらに、ＩＳＰの各サービスは、トークンを維持する必要があり、ＩＳＶアプリケーション開発の複雑さおよびコストが増大する。さらに、ＩＳＰセキュリティ戦略の全体を知る必要もあるため、ＩＳＶにかかる負担が増す。
【００１８】
一部の実施形態では、１組のセキュリティ戦略が、ＩＳＶアプリケーション開発の複雑さを軽減するように設計される。特に、ＩＳＰによって提供されるＡＰＩは、まずセキュリティレベルに基づいて分類され、次に、対応するセキュリティ認証コンテンツが、その分類に従って設定される。最後に、セキュリティ認証が、プラットフォームレベルのパラメータの内容に従って実行される。そのため、ＩＳＶがＩＳＰサービスを要求する必要がある場合、その要求は、対応するセキュリティサービスを取得するために、対応するパラメータを運ぶだけでよい。したがって、セキュリティ戦略はＩＳＶに対して透過的である。一方、ＩＳＰは、ＩＳＶ要求に対して、対応するセキュリティ認証を実行するためにＡＰＩおよびセキュリティ要件を提供するだけでよいため、その結果、ＩＳＰは、セキュリティ戦略アーキテクチャを考慮する必要なく、ビジネスサービスインターフェースの開発に集中することができる。ここで、添付の図面を参照しつつ、具体的な実施形態について説明する。
【００１９】
図２は、インターネットサービスを提供するためのプロセスの一実施形態を示すフローチャートである。プロセス２５０は、以下の図５のシステム５００などのシステムに実装されてよい。
【００２０】
２０１において、サービス要求メッセージが、例えば、ＩＳＶによって提供されたアプリケーションのユーザから、サービス統合プラットフォームサーバの通信インターフェースで受信される。サービス要求メッセージは、ＩＳＰに送信され、ＩＳＶアプリケーションを要求する。サービス要求メッセージは、ＡＰＩタイプに従って実装され、ＡＰＩタイプに適合する１組のプラットフォームレベルパラメータを備える。
【００２１】
２０２において、ＡＰＩタイプに適切な１組の認証チェックが決定される。いくつかの実施形態において、異なるＡＰＩタイプおよびそれらのそれぞれの認証チェックは、ＩＳＰによって定義される。情報は、ＳＩＰに格納され、それにより、ＳＩＰが、サービス要求のＡＰＩをルックアップして、サービス要求の受信時に適切な認証チェックの決定をすることが可能になる。
【００２２】
２０３において、サービス要求メッセージの認証が、決定された認証チェックのセットに従って実行される。
【００２３】
２０４において、サービス要求メッセージは、認証されると、インターネットサービスプロバイダ（ＩＳＰ）のサービスアドレスまでルーティングされる。
【００２４】
上記の工程の具体的な実装について、以下で説明する。本願におけるセキュリティ戦略の構築について説明する。すなわち、サービスセキュリティレベルの分類、プラットフォームレベルパラメータの定義、セキュリティ制御、および、それらの間の関係について説明する。
【００２５】
Ｉ．サービスセキュリティレベルの分類
セキュリティ戦略制御フローは、サービスセキュリティレベルを分類することに基づく。セキュリティは、２つの側面、すなわち、サービスアクセス制御およびサービスビジネスセキュリティレベルに関係する。
【００２６】
サービスアクセス制御は、特定のサービスの利用がＩＳＰによって認証されるべきか否かを判定する。ＩＳＰは、例えば、高いレベルのサービスの利用には認証が必要であると規定してよい。次いで、ＳＩＰは、認証結果に従って、この種のサービスにアクセスする要求のためにサービスをルーティングするか否かを判定してよい。
【００２７】
いくつかの実施形態では、セキュリティ要件に従って、工程２０１のサービスＡＰＩタイプは、以下のタイプの内の１または複数を含みうる。
【００２８】
匿名アクセスサービス：匿名アクセスサービスタイプは、いかなる認証も必要としない。
【００２９】
許可サービス：許可サービスタイプは、署名チェックおよびタイムスタンプチェックを必要とする。
【００３０】
ユーザ許可サービス：ユーザ許可サービスタイプは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックを必要とする。
【００３１】
オプションユーザ許可サービス：オプションユーザ許可サービスタイプは、署名チェック、タイムスタンプチェック、および、オプションユーザＩＤチェックを必要とする。
【００３２】
サービスＡＰＩは、ＩＳＰによって提供される。様々なサービスレベルを有するＡＰＩを示す一例を、以下の表に示す。
【００３３】
【表１】
0005567011.tif 000002
【００３４】
オプションユーザ許可サービスについては、サービスがユーザ情報をバインディングすることを必要とするか否かは、オプションである。ユーザ情報がバインディングされる場合、同じサービスインターフェースが、ユーザ固有のプライベート情報を返す。ユーザ情報がバインディングされない場合、公開情報だけが返される。
【００３５】
したがって、セキュリティ戦略制御フローを実現するために、工程２０２で決定された１組の認証チェックは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェック、または、それらのチェックの組み合わせを含んでよい。例えば、ＧｅｔＵｓｅｒサービス要求が、ユーザ許可サービスのＡＰＩタイプであると判定された場合、１組の認証チェックは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックを含む。
【００３６】
対応する認証要求が、上記のＡＰＩタイプと組み合わせて提供されうる。セキュリティ戦略における各種のサービスと認証との間の対応関係は、以下の表に示されるようであってよい。
【００３７】
【表２】
0005567011.tif 000003
【００３８】
ＩＩ．プラットフォームレベルパラメータの定義
サービスを呼び出すためのＩＳＶの要求は、２組のデータ、すなわち、プラットフォームレベルパラメータおよびビジネスパラメータを必要とする。ビジネスパラメータは、各ＩＳＰによって提供されるサービスインターフェースパラメータであり、アプリケーションに固有のものである。プラットフォームレベルパラメータは、ＩＳＰサービスの位置を特定するための構成パラメータであり、セキュリティフローによって必要とされる。プラットフォームレベルパラメータは、本願に記載された実装に関連し、例えば、ＩＳＶサービスを呼び出すためのＩＤ証明（キーまたは証明書など）、サービス名、サービス要求タイムスタンプ、署名、ＩＳＶアプリケーションにおけるユーザセッションの一意のＩＤ、および、戻り値のタイプ、または、それらのパラメータの組み合わせを含む。
【００３９】
セキュリティ制御および認証に関連するプラットフォームレベルパラメータの例を以下の表に示す。
【００４０】
【表３】
0005567011.tif 000004
【００４１】
「名称」列の文字列は、以下の実施形態において用いられ、プラットフォームレベルパラメータを表す。「Ｖａｒｃｈａｒ」は文字変数の長さを示す。「必要またはオプション」は、パラメータが、運ばれる必要のあるパラメータに属するか否かを意味する。「ｊｓｏｎ／ｘｍｌ」は、返されるコンテンツのフォーマットである。
【００４２】
表中のＩＳＶアプリケーションのＡｐｐｋｅｙは、ＩＳＶサービスを呼び出すためのＩＤの証明を指す。
【００４３】
したがって、サービスレベルに基づく分類と、上記のサービスＡＰＩタイプとを組み合わせると、運ぶ必要があるプラットフォームレベルパラメータを決定できる。すなわち、異なるプラットフォームレベルパラメータを運ぶことによって、異なるセキュリティレベルのサービスを決定できる。具体的には、これは以下の表に示されるようであってよい。
【００４４】
【表４】
0005567011.tif 000005
【００４５】
上の表によると、いくつかの実施形態において、サービス要求は、セキュリティ要件を満たすように、要求に含まれるプラットフォームレベルパラメータに従って認証されうる。具体的には：
【００４６】
匿名サービスについては、プラットフォームレベルパラメータは、ＩＳＶサービスを呼び出すためのＩＤ証明とサービス名である。署名チェックおよびユーザＩＤチェックは、このサービス要求に対しては実行されない。
【００４７】
ユーザバインディングを必要としない許可サービスについては、プラットフォームレベルパラメータは、ＩＳＶサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、および、署名である。サービス要求に対して実行されるチェックは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックである。
【００４８】
ユーザバインディングを必要とするユーザ許可サービスについては、プラットフォームレベルパラメータは、ＩＳＶサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、署名、および、ＩＳＶアプリケーションにおけるユーザセッションの一意のＩＤである。サービス要求に対して実行されるチェックは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックである。
【００４９】
オプションのユーザバインディングを有するオプションユーザ許可サービスについては、プラットフォームレベルパラメータは、ＩＳＶサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、および、署名であり、ユーザバインディングはオプションである。サービス要求に対して実行されるチェックは、署名チェック、タイムスタンプチェック、および、オプションのユーザＩＤチェックである。
【００５０】
ＩＩＩ．セキュリティ制御
いくつかの実施形態において、サービス統合プラットフォームシステム（ＳＩＰと呼ぶ）が、セキュリティ戦略制御を実装するために用いられる。ＳＩＰの一実施形態は、以下の機能を実装する：（１）ＩＳＶサービスを呼び出すためのＩＤ証明（Ａｐｐｋｅｙ）の発行；（２）署名計算；（３）タイムスタンプチェック；および（４）暗号化。実装例を以下で説明する。
【００５１】
（１）ＩＳＶサービスを呼び出すためのＩＤ証明（Ａｐｐｋｅｙ）の発行
【００５２】
具体的な実装例では、ＩＳＶを管理し、ＡｐｐｋｅｙおよびＡｐｐＳｅｃｒｅｔを発行するためのＩＳＶポータルが、サービス統合プラットフォーム（すなわちＳＩＰ）システム内に備えられる。ＩＳＶポータルにアプリケーションを登録した後、１組のＡｐｐｋｅｙおよびＡｐｐＳｅｃｒｅｔが、ＩＳＶに対して発行される。Ａｐｐｋｅｙは、ＩＳＰサービスを呼び出すためのＩＳＶのＩＤ証明であり、修正できない。一方、ＡｐｐＳｅｃｒｅｔは、ＡＰＩにアクセスするためのキーであり、ＩＳＶポータル内で自動的にＩＳＶによって修正されうる。ＡｐｐｋｅｙおよびＡｐｐＳｅｃｒｅｔの間の関係は、ログインアカウントおよびパスワードの間の関係と同様である。それらは両方とも、署名およびビジネスパラメータにおいて用いられる。
【００５３】
Ａｐｐｋｅｙのプロパティを示す一例については、上記の表におけるｓｉｐ＿ａｐｐｋｅｙを参照すること。ＡｐｐＳｅｃｒｅｔは、ユーザの要望に従って選択および修正される。
【００５４】
（２）署名の実装
【００５５】
署名は、サービス統合プラットフォームシステムによって認証されうる。ＩＳＰは、署名認証を行う必要がない。ＩＳＶは、ｓｉｐ＿ｓｉｇｎ以外のすべての提示されたパラメータに対して署名することが好ましい。署名されるパラメータは、プラットフォームレベルパラメータおよびビジネスパラメータを含み、デジタル署名を計算するために用いられてよい。
【００５６】
ＩＳＶアプリケーションがＳＩＰからＡＰＩを呼び出す前に、ｓｉｐ＿ｓｉｇｎパラメータが生成される。いくつかの実施形態では、ｓｉｐ＿ｓｉｇｎは、以下のように生成される：
ｓｉｐ＿ｓｉｇｎ＝ＭＤ５（ｓｉｇ＿ａｐｐｓｅｃｒｅｔと連結して１つの文字列にする（
配列を連結して文字列を生成する（
配列をアルファベット順にソートする（
ｓｉｐ＿ｓｉｇｎ以外のすべてのパラメータについての＜ｋｅｙ＞＜ｖａｌｕｅ＞の形態の非ＵＲＬ符号化文字列配列））））
ここで、
ｓｉｐ＿ｓｉｇｎ＝ＭＤ５（ｓｉｇ＿ａｐｐｓｅｃｒｅｔ＋［ｐａｒａｍ１＋ｖａｌｕｅ１・・・ｐａｒａｍｎ＋ｖａｌｕｅｎ］）。パラメータは、アルファベット順にソートされる。
【００５７】
例えば、ｓｉｐ＿ａｐｐｋｅｙ＝００１、および、ｓｉｐ＿ａｐｐｓｅｃｒｅｔ＝ａ３１２とすると、ＡＰＩは、ｇｅｔＵｓｅｒＬｉｓｔＢｙＣｏｎｄｉｔｉｏｎ（Ｓｔｒｉｎｇ  ｃｏｍｐａｎｙ、ｂｏｏｌｅａｎ  ｉｓｄｅｌｅｔｅｄ、ｉｎｔ  ｃｏｕｎｔ）と定義され、以下のように呼び出される：ｇｅｔＵｓｅｒＬｉｓｔＢｙＣｏｎｄｉｔｉｏｎ（”ａｌｉｓｏｒｔ”、ｆａｌｓｅ、１０）。そして、以下のアプローチにより、署名が決定される。
【００５８】
（ａ）パラメータ名に従ってアルファベット順にインターフェースアプローチパラメータ値をソートし、ソートされたパラメータを以下のように結合する：
Ｃｏｍｐａｎｙ＋ａｌｉｓｏｆｔ＋ｃｏｕｎｔ＋１０＋ｉｓｄｅｌｅｔｅｄ＋ｆａｌｓｅ
【００５９】
（ｂ）アプローチのｓｅｃｒｅｔＣｏｄｅの前に文字列を加えて、最終的な署名を得る（ここでは、ａｐｐＳｅｃｒｅｔはａ３１２とする）：
ｓｉｐ＿ｓｉｇｎ＝ＭＤ５（ａ３１２ｃｏｍｐａｎｙａｌｉｓｏｆｔｃｏｕｎｔ１０ｉｓｄｅｌｅｔｅｄｆａｌｓｅ）
【００６０】
（３）タイムスタンプチェックの実装
【００６１】
各要求は、署名関数を用いて現在時刻で署名され、その結果、サービス統合プラットフォームシステムは、署名の受信時にタイムスタンプをチェックして、情報が繰り返し送信されることを防ぐために要求がタイムアウトしたか否かを判定することができる。
【００６２】
（４）暗号化の実装
【００６３】
本明細書における暗号化関数は、ユーザトークンの生成の際に用いられる。トークンは、ＳＩＰプラットフォーム自体によって認証されるだけなので、より高効率の対称暗号化が用いられ、キーは周期的に変更される。一例において、ｓｉｐ＿ｕｓｅｒｔｏｋｅｎは、以下のように実装される：
ｓｉｐ＿ｕｓｅｒｔｏｋｅｎ＝ＤＥＳ（ａｐｐｋｅｙ＝＄ｓｉｐ＿ａｐｐｋｅｙ、ｉｓｐｉｄ＝＄ｉｓｐｉｄ、ｕｓｅｒｉｄ＝＄ｕｓｅｒｎａｍｅ、ｔｉｍｅｓｔａｍｐ＝＄ｔｉｍｅｓｔａｍｐ、ｔｙｐｅ＝（０｜１））
【００６４】
上記の式のパラメータの説明は、以下の通りである：
【００６５】
【表５】
0005567011.tif 000006
【００６６】
ＩＶ．セキュリティ制御フローの実装
図３は、セキュリティ制御フローのプロセスの一実施形態を示すフローチャートである。フローの実装をより明確に示すために、図３のフローは、時間だけでなく、プロセスに関与する動作主体に基づいて構成されている。関連する動作主体には、ユーザ、ＩＳＶアプリケーション、ＳＩＰ、および、ＩＳＰが含まれており、ＳＩＰは、サービス統合プラットフォームシステムを指す。図３は、さらに、トークンの管理に関する。この例において、トークンは、ある種のＩＤトークンである。ユーザがログインした時に、ＩＳＶシステムにおけるユーザのＩＤおよびＳＩＰにおけるユーザのＩＤは、関連づけられる。各要求のＩＳＶシステムにおけるユーザＩＤが、すでに生成されたＳＩＰのＩＤトークンと関連づけられてよい。ＳＩＰは、トークンを有するＩＳＶアプリケーションユーザが、ＩＳＰのユーザ関連情報の操作を許可されていると見なす。
【００６７】
３０１において、ユーザは、ＩＳＶアプリケーションを利用する。
【００６８】
３０２において、サービス要求メッセージが開始され、ＩＳＶのアプリケーションを介してＩＳＰに送信される。この工程で提供されるパラメータは、ａｐｐｋｅｙ、ｓｉｇｎ、ｔｉｍｅｓｔａｍｐ、ａｐｉｎａｍｅ、および、ｓｅｓｓｉｏｎＩＤを含みうる。その他の関連するビジネスパラメータも、この工程で提供されてよい。
【００６９】
ユーザは、ＩＳＶアプリケーションを用いて、サービス要求を開始する。ＩＳＶアプリケーションは、サービスレベルに従って、署名が必要か否かを判定し、要求をＳＩＰに送信する。次いで、ＳＩＰは、ＳＩＰに対して要求を行う。
【００７０】
３０３において、サービスが存在するか否かが判定される。イエスの場合、制御は３０４に移行され、ノーの場合、制御はエラー処理のための３１６に移行される。このメッセージで運ばれるパラメータｓｅｒｖｉｃｅｎａｍｅは、サービスが存在するか否かを判定するためにチェックされる。
【００７１】
３０４において、申し込みが必要か否かを判定するために、サービスアクセス制御タイプがチェックされる。イエスの場合、制御は３０５に移行され、ノーの場合、制御は３０６に移行される。いくつかの実施形態において、ＩＳＰによって提供される特定のサービスは、すべてのＩＳＶが自由に利用できるわけではなく、ＩＳＶは、この種のサービスを利用する前に、利用を申請するための要求をＩＳＰに送信する必要がある。ＩＳＰが要求を受け付けると、申し込み記録が生成される。この種のサービスが呼び出される前に、申し込み関係が、他のセキュリティ戦略のチェックの前に最初にチェックされる。この種の申し込み関係が存在するか否かは、この工程によってチェックできる。
【００７２】
３０５において、サービスへのアクセスが許可されているか否かが判定される。イエスの場合、制御は３０６に移行され、ノーの場合、制御は３１６に移行される。この判定は、申し込まれたａｐｐｋｅｙおよび申し込まれたＡＰＩの間の関係によってなされうる。
【００７３】
３０６において、セキュリティ認証が必要か否かが判定される。イエスの場合、制御は３０７に移行され、ノーの場合、制御は３１２に移行される。
【００７４】
３０７において、署名チェックが合格であるか否かが判定される。イエスの場合、制御は３０８に移行され、ノーの場合、制御は３１６に移行される。
【００７５】
３０８において、セッションがタイムアウトしたか否かが判定される。イエスの場合、制御は３１６に移行され、ノーの場合、制御は３０９に移行される。タイムアウトのチェックは、タイムスタンプパラメータ、トークンなどを用いてなされてよい。タイムアウトの設定時間長は、システムによって全世界的に構成されうる。
【００７６】
３０９において、サービスがユーザをバインディングする必要があるか否かが判定される。いくつかの実施形態では、ユーザバインディングが必要か否かは、サービスが登録される時に判定されるため、サービス要求は、バインディングが必要か否かに関する情報を含む。バインディングがオプションまたは必要である場合、制御は３１０に移行され、そうでない場合、制御は３１２に移行される。
【００７７】
この工程では、一部のサービスの呼び出しは、ＩＳＶアプリケーションを利用するユーザのプライベート情報を必要とするため、ユーザは、ＩＳＰのウェブサイトを通してログイン動作を実行する必要がある。次いで、ＩＳＰは、ユーザ情報とＳＩＰによって発行されたトークンとをバインディングすることをＳＩＰに通知する。ＩＳＶアプリケーションに対するその後のサービス要求は、ＳＩＰのユーザトークンに変更されうるｓｅｓｓｉｏｎＩＤを運ぶだけでよい。この種のサービスが呼び出される時には、ＩＳＶ  ＩＤだけでなくユーザバインディング状態もチェックされる。
【００７８】
３１０において、トークンが存在していて有効であるか否かが判定される。トークンが存在し、かつ、有効である場合、制御は３１２に移行され、そうでない場合、制御は３１１に移行される。この工程において、対応するトークンがすでに存在するか否か、および、トークンが有効であるか否かは、ｓｅｓｓｉｏｎＩＤ、サービスが必要とするトークンタイプ、および、ＩＳＰ  ＩＤに従って判定されうる。さらに、トークンが存在し、かつ、有効であり、このサービスが１回利用のユーザ認証モードを用いる場合、ワンタイムトークンは除去されうる、すなわち、このアプリケーションが利用済みであることが確認される。
【００７９】
この工程において、ＳＩＰは、ｓｅｓｓｉｏｎＩＤと複数のＩＳＰトークンリストとの間のキャッシュされた関係を維持しうる。どのＩＳＰも、キャッシュから構成を取得するためのトークンタイムアウト長を有するよう構成されうる。
【００８０】
３１１において、サービスがユーザをバインディングする必要があるか否かが判定される。イエスの場合、制御は３１６に移行され、ノーの場合、制御は３１２に移行される。この工程では、ユーザバインディングが必要か否かは、オプションのユーザバインディングおよび必要なユーザバインディングに対して他のセキュリティ処理を実行する前に判定される。
【００８１】
３１２において、ＳＩＰは、サービスへのアクセスの要求を処理する。この工程において、要求されたサービスは、サービス処理を実行するためにＩＳＰまでルーティングされる。
【００８２】
３１３において、ＩＳＰは、ユーザによって開始されたサービス要求を処理する。
【００８３】
３１４において、例えば、ログ情報の記録および応答の転送など、サービス後の応答処理が実行される。
【００８４】
３１５において、処理結果が取得され、情報がＩＳＶアプリケーションによって提示される。
【００８５】
３１６において、エラー処理が実行される。この工程において、異なるエラー情報に関して、異なる応答がなされうる。例えば、ユーザバインディングが必要である場合、対応するバインディングユーザアドレスおよび関連情報が返される。他のパラメータのチェックエラーでは、対応するプロンプトが返される。エラー処理において、ユーザバインディングが必要である場合、ログインページが、ＳＩＰによって提供されるログインユニフォームリソースロケータ（ｌｏｇｉｎ＿ｕｒｌ）にリダイレクトされうる。
【００８６】
３１７において、ＩＳＶアプリケーションは、ユーザのブラウザをウェブページに戻らせる。
【００８７】
したがって、ユーザは、ＩＳＶアプリケーションでサービス要求を開始する。ＩＳＶアプリケーションは、サービスレベルに従って、署名が必要か否かを判定し、要求をＳＩＰに送信する。要求を受信すると、ＳＩＰは、要求されたサービスの名称に従って有効性を判定し、サービスアクセス制御タイプに従って、サービスアクセス制御キャッシュをチェックするか否かを判定する。アクセスされたサービスのセキュリティレベルが判定されると、匿名アクセスサービスレベルについては、要求されたサービスが、ＩＳＰサービスアドレスに直接ルーティングされ、他のタイプのサービスレベルについては、要求によって運ばれたパラメータに従って、基本的なセキュリティ認証が実行される。
【００８８】
ＳＩＰは、署名情報およびタイムスタンプをチェックし、サービスレベルに従ってユーザ認証が必要か否かを判定する。ユーザ認証が必要である場合、ＳＩＰは、ユーザトークンのチェックを継続する。
【００８９】
関連するユーザバインディングが工程３０９で判定される次のプロセスにおいては、一部のサービスの呼び出しがユーザ情報および発行済みトークンのバインディングを必要とするため、この種のサービスが呼び出される時に、ＩＳＶ  ＩＤを検証するのに加えて、ユーザバインディング状態もチェックされる。したがって、トークンのチェックは、さらに、ユーザの一意性を特定するＩＳＶのｓｅｓｓｉｏｎＩＤがパラメータに含まれるか否かをチェックすることを含む。ノーの場合、ユーザＩＤは、バインディングされていないとみなされる。すなわち、ビジネスプラットフォームパラメータが、ＩＳＶアプリケーションにおけるユーザセッションの一意のＩＤを含むと判定されると、サービス要求認証にパスする前に、ユーザバインディングエラーが返される。
【００９０】
ビジネスプラットフォームパラメータが、サービスＩＳＰ  ＩＤ（ＩＳＰアイデンティティ）、ＩＳＶサービスを呼び出すためのＩＤ証明、および、ＩＳＶアプリケーションにおけるユーザセッションの一意のＩＤを含むと判定した場合、キャッシュ内のトークンリストが取得される。トークンが存在しないか無効であると判定された場合、ユーザバインディングエラー情報が返されうる。いくつかの実施形態では、サービスＩＳＰ  ＩＤ＋アプリケーションＡｐｐｋｅｙ＋ｓｅｓｓｉｏｎＩＤのプラットフォームパラメータが組み合わされて、ユーザトークンキャッシュキーになり、キャッシュされたトークンリストを用いて、トークンが存在するか否かを判定しうる。いくつかの実施形態では、アプリケーションが、異なるライフサイクルを有する２つのタイプのトークン、すなわち、同じＩＳＰの異なるレベルのサービスのためのワンタイムトークンおよびセッショントークンを格納する。トークンが存在しない場合、ユーザのＩＤがバインディングされていないことを意味する。
【００９１】
トークンが存在する場合、トークンのタイプが判定される。（１回限り用いることができる）要求トークンについては、トークンは、トークンキャッシュから除去され、成功したユーザＩＤチェックが返される。セッショントークンについては、タイムアウトを判定するために、トークンの生成時刻と現在時刻が再びチェックされる。
【００９２】
認証が失敗すると、ユーザバインディングを必要とする旨のエラープロンプトが、ＩＳＶアプリケーションに返され、対応するＩＳＰログインページアドレスが返される。
【００９３】
認証が成功すると、ユーザ名がパラメータ（ＩＳＰは、この情報に従って、さらなるビジネスロジックチェックを実行できる）として送り返され、ＩＳＰサービスアドレスまでルーティングされる。
【００９４】
図４は、ユーザをバインディングするためのプロセスの一実施形態を示すフローチャートである。プロセス３００の工程３１６におけるエラー処理において、ユーザバインディングが必要である場合、ログインページへのリダイレクトも必要である。図４に示すように、ユーザバインディングおよびリダイレクトの実装フローは、以下のようであってよい：
【００９５】
４０１において、ＩＳＶは、サービスにアクセスする際に、ユーザをバインディングすることを要求される。
【００９６】
４０２において、ＩＳＶは、ＳＩＰによって返されたユーザログインＵＲＬにリダイレクトされる。ａｐｐｋｅｙ、ａｐｉｎａｍｅ、ｒｅｄｉｒｅｃｔ＿ｕｒｌ、および、ｓｅｓｓｉｏｎＩＤが、パラメータとして送信される必要がある。ユーザのログインを行うＵＲＬは、工程３１６で返されたアドレスである。
【００９７】
４０３において、ＩＳＰのログインページへのリダイレクトを行う前に、ＳＩＰの転送ページにログインし、特定の処理を実行する。
【００９８】
４０４において、ユーザは、サービスアクセスの確認を行い、ログインする。この工程で、ユーザは、ａｐｐｋｅｙ、ａｐｉｎａｍｅ、および、ｓｅｓｓｉｏｎＩＤの入力を要求される。ここで、ｓｅｓｓｉｏｎＩＤは、ユーザセッションの一意のＩＤである。
【００９９】
４０５において、ＩＳＰは、ユーザＩＤをチェックする。チェックに合格すると、制御は４０７に移行され、そうでない場合、制御は４０６に移行される。
【０１００】
４０６において、エラー情報が返される。
【０１０１】
４０７において、要求は、ｒｅｄｉｒｅｃｔ＿ｕｒｌパラメータアドレスにリダイレクトされ、ＳＩＰログインを呼び出す。ＳＩＰは、ログインの成功を通知される。
【０１０２】
ｒｅｄｉｒｅｃｔ＿ｕｒｌパラメータ内のアドレスに従って、ログインされたインターフェースは、このアドレスにリダイレクトされ、それにより、ユーザは、ログインされたページを見た後にＩＳＶのアドレスに直接ジャンプできる。
【０１０３】
４０８において、ＳＩＰは、ｓｅｓｓｉｏｎＩＤが存在するか否かを判定し、イエスの場合、制御は４１０に移行され、そうでない場合、制御は４０９に移行される。
【０１０４】
具体的な実装において、ｉｓｐＩＤ＋ａｐｐｋｅｙ＋ｓｅｓｓｉｏｎＩＤが、システムにおける実際のｓｅｓｓｉｏｎＩＤとしてチェックされうる。この場合、チェックされる内容は、ｓｅｓｓｉｏｎＩＤと、ｉｓｐＩＤおよびａｐｐｋｅｙを含む。
【０１０５】
４０９において、ＳＩＰは、ｓｅｓｓｉｏｎＩＤをＳｅｓｓｉｏｎプール内の対応するＩＳＰに格納し、制御は４１０に移行される。
【０１０６】
４１０において、ＳＩＰは、ＡＰＩタイプに従って、トークンおよび追加の認証情報を生成し、ｓｅｓｓｉｏｎＩＤと関連づけ、バインディングの成功をＩＳＶに通知する。ｓｅｓｓｉｏｎＩＤ、ａｐｐｋｅｙ、および、ａｐｉｎａｍｅは、通知メッセージ内に含まれうる。
【０１０７】
４１１において、ＩＳＶは、自身の状態に従って、処理を行うか否かを選択する。例えば、ＩＳＶは、１つのｓｅｓｓｉｏｎＩＤが、ＩＳＶ自身のシステムにおけるユーザ情報とバインディングされていることをマークしうる。このｓｅｓｓｉｏｎＩＤは、バインディングＩＤを再び要求することなく、次のサービス要求においてサービスを要求するために直接転送されうる。
【０１０８】
したがって、ユーザバインディングが必要であることを示す返されたエラーを受信すると、ＩＳＶは、ＳＩＰによって返されたログインページアドレスにリダイレクトされる。ａｐｐｋｅｙ、ａｐｉｎａｍｅ（要求されたサービスの名称）、ｒｅｄｉｒｅｃｔｕｒｌ（ユーザバインディングにパスしたＩＳＶアプリケーションのリダイレクト先となるＵＲＬ）、および、ｓｅｓｓｉｏｎＩＤ（ユーザの一意のＩＤ）は、同時にセッション内に含まれる。
【０１０９】
ログイン要求を取得すると、ＳＩＰは、ａｐｉｎａｍｅに従って、対応するＩＳＰログインアドレスにリダイレクトを行って、パラメータを転送できる。
【０１１０】
ユーザは、ＩＳＰログインページにログインするか否かを選択することが可能であり、ＩＳＰログインページは、さらに、クッキーと同様の方法に従って、ユーザがログインしたか否か、および、ログイン工程を飛ばすか否かを判定できる。この工程は、主に、ログインフリーのスキームを提供する。例えば、ユーザは、ウェブサイトにログインし、ウェブサイトは、クライアント側でのＩＤとしてクッキーを割り当てる。ユーザが、サービス要求中に、再びログインページに移行されると、ログインページは、ログインしたことを示すかかる指標（すなわち、クッキー）がすでに存在するか否かをチェックして、ログインプロセスを直接飛ばすか否かを決定する。
【０１１１】
ユーザログインチェックを完了すると、ＩＳＰは、ＳＩＰプラットフォームシステムのトークン発行サービスを呼び出して、ａｐｐｋｅｙおよびｓｅｓｓｉｏｎＩＤを入力し、ＩＳＶアプリケーションによって転送されたｒｅｄｉｒｅｃｔ＿ｕｒｌアドレスにリダイレクトすることができる。
【０１１２】
ＳＩＰトークン発行サービスは、トークン生成ルールに従ってトークンを生成し、トークンのキーとしてｉｓｐＩＤ＋ａｐｐＫｅｙ＋ｓｅｓｓｉｏｎＩＤを用いて、キャッシュにトークンを格納する。
【０１１３】
ＳＩＰは、ＩＳＶアプリケーションのバック呼び出し通知ＵＲＬ（back-invoking notice URL）を呼び出し、ユーザバインディングの成功を通知する。ＩＳＶアプリケーションは、要求に従って、応答を処理するか否かを判定する。
【０１１４】
図５は、インターネットサービスを提供するためのサービス統合プラットフォームシステムの一実施形態を示す概略図である。説明を容易にするために、サービス統合プラットフォームシステムをＳＩＰと呼ぶこととする。この例に示すように、システムは、コンピュータ、ハンドヘルド／携帯デバイスなどのユーザデバイスと、ＩＳＶアプリケーションサーバ（または、サーバクラスタ）と、１または複数のサーバを備えたＳＩＰネットワークと、１または複数のサーバを備えたＩＳＰネットワークと、を備える。ＳＩＰネットワークは、ＩＳＶアプリケーションを用いてＩＳＰに対してユーザが開始したサービス要求メッセージを受信するよう構成された受信モジュール５０１（例えば、ポート、ケーブル、ワイヤライン、または、ワイヤレスネットワークインターフェースカードなどの通信インターフェース）を備えており、サービス要求メッセージには、サービスＡＰＩタイプを判定するためのプラットフォームレベルパラメータが含まれる。さらに、プラットフォームレベルパラメータに従ってサービス要求を認証するよう構成された認証モジュール５０２が備えられている。さらに、サービス要求認証の合格後に、ＩＳＶアプリケーションを用いてユーザが開始したサービス要求をＩＳＰのサービスアドレスまでルーティングするよう構成されたルーティングモジュール５０３が備えられている。これらのモジュールは、１または複数のコンピュータデバイス（サーバなど）が備えた１または複数のプロセッサ上で動作するコンピュータ実行可能な命令を備えるソフトウェアとして、プログラム可能な論理デバイス上で動作するマイクロコードなどの特別な命令を備えるファームウェアとして、特定用途向け集積回路（ＡＳＩＣ）などのハードウェアとして、または、それらの組み合わせとしてなど、様々な技術を用いて実装されてよい。
【０１１５】
具体的には、認証モジュールは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックのうちの１または複数を実行できる。プラットフォームレベルパラメータは、ＩＳＶサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、署名、ＩＳＶアプリケーションにおけるユーザセッションの一意のＩＤ、および、戻り値のタイプの内の１または複数を含んでよい。
【０１１６】
認証モジュールは、以下のように、プラットフォームレベルパラメータに従って、サービス要求を認証する。
【０１１７】
プラットフォームレベルパラメータが、ＩＳＶサービスを呼び出すためのＩＤ証明、および、サービス名である場合、サービス要求は、署名チェックおよびユーザＩＤチェックを受けない。
【０１１８】
プラットフォームレベルパラメータが、ＩＳＶサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、および、署名である場合、サービス要求は、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックを受ける。
【０１１９】
プラットフォームレベルパラメータが、ＩＳＶサービスを呼び出すためのＩＤ証明，サービス名、サービス要求タイムスタンプ、署名、および、ＩＳＶアプリケーションにおけるユーザセッションの一意のＩＤである場合、サービス要求は、署名チェック、タイムスタンプチェック、およびユーザＩＤチェックを受ける。
【０１２０】
プラットフォームレベルパラメータが、ＩＳＶサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、および、署名である場合、サービス要求は、署名チェック、タイムスタンプチェック、および、オプションのユーザＩＤチェックを受ける。
【０１２１】
ユーザバインディングが必要である場合、認証モジュール５０２は、さらに、第１のバインディングエラーリターンユニット５０２１、および／または、第２のバインディングエラーリターンユニット５０２２を備えうる。
【０１２２】
第１のバインディングエラーリターンユニット５２０１は、ビジネスプラットフォームパラメータが、ＩＳＶアプリケーションにおけるユーザセッションの一意のＩＤを含むことを決定するため、および、サービス要求認証が通過しなかった時にユーザバインディングエラー情報を返すためのものである。
【０１２３】
第２のバインディングエラーリターンユニット５０２２は、ビジネスプラットフォームパラメータが、サービスｉｓｐＩＤ、ＩＳＶサービスを呼び出すためのＩＤ証明、および、ＩＳＶアプリケーションにおけるユーザセッションの一意のＩＤを含む場合に、キャッシュ内のトークンリストを取得するため、および、トークンが存在しないか無効であると判定された場合に、ユーザバインディングエラー情報を返すためのものである。
【０１２４】
さらに、第１のバインディングエラーリターンユニットおよび／または第２のバインディングエラーリターンユニットは、ユーザバインディングエラー情報を返す時に、ＩＳＰログインアドレスも返しうる。
【０１２５】
バインディングエラー情報およびＩＳＰログインアドレスがユーザに返された場合、ユーザは、ユーザバインディングを再び実行できる。この場合、サービス統合プラットフォームシステムは、さらに、ユーザバインディングエラー情報の受信後に、ＩＳＰログインアドレスに対してＩＳＶが開始したサービス要求メッセージを受信した場合に、プラットフォームレベルパラメータ内のサービス名に従ってＩＳＰログインアドレスにリダイレクトし、プラットフォームレベルパラメータをＩＳＰに転送するためのリダイレクトモジュール５０４を備えうる。サービス要求メッセージ内のプラットフォームレベルパラメータは、ＩＳＶサービスを呼び出すためのＩＤ証明、サービス名、ＩＳＶアプリケーションにおけるユーザセッションの一意のＩＤ、および、ＩＳＶアプリケーションのユーザバインディング後のリダイレクト先となるアドレスを含む。
【０１２６】
この例において、ＳＩＰは、さらに、ＩＳＶサービスを呼び出すためのＩＤ証明に従ってトークンを発行するためのトークン発行サービスモジュール５０５を備えており、ユーザログイン後にＩＳＰによって転送されたＩＳＶアプリケーションにおけるユーザセッションの一意のＩＤは、ＩＳＶアプリケーションにおけるユーザセッションの一意のＩＤに従って、ＩＳＰによって検証される。
【０１２７】
複数のサービスプロバイダによって提供されたサービスを統合できるセキュリティ制御戦略が、いくつかの実施形態で提供されることが、上記の実施形態から理解できる。署名および暗号化論理設計に関するサービスレベルの細分化と、プラットフォームレベルパラメータ上での統合により、全体のセキュリティフロー設計が実現され、それにより、サービス格付けシステムが改善され、ユーザ情報のセキュリティおよびＩＳＰサービスアクセスのセキュリティが保証され、既存の単一ＩＳＰサービスセキュリティ戦略の欠点が克服される。このセキュリティ戦略は、ＩＳＶに対して透過的であるため、その結果、ＩＳＶの開発コストが削減され、ＩＳＶは、開発の際に特定のビジネスサービスに関与するだけでよい。一方、ＩＳＰは、ビジネスサービスインターフェースの開発に集中することができ、ビジネスサービスのセキュリティ戦略を再実装する必要はない。
【０１２８】
本発明の精神および範囲から逸脱することなく、本発明に対して様々な変形および修正を行うことができることは、当業者にとって明白である。したがって、特許請求の範囲および等価物の範囲内に含まれる場合、かかる変形例および修正例はすべて、本発明によって網羅される。
【０１２９】
上述の実施形態は、理解しやすいように少し詳しく説明されているが、本発明は、提供された詳細事項に限定されるものではない。本発明を実施する多くの代替方法が存在する。開示された実施形態は、例示であり、限定を意図するものではない。
適用例１：インターネットサービスを提供するための方法であって、独立系ソフトウェアベンダー（ＩＳＶ）によって提供されたアプリケーションのユーザによって開始されたサービス要求メッセージを受信する工程と、前記サービス要求メッセージは、アプリケーションプログラミングインターフェース（ＡＰＩ）タイプに従って実装され、前記ＡＰＩタイプに適合する複数のプラットフォームレベルパラメータを含むことと、前記ＡＰＩタイプに適切な１組の認証チェックを決定し、前記１組の認証チェックに従って、前記サービス要求メッセージの認証を実行し、前記サービス要求メッセージが認証されると、インターネットサービスプロバイダ（ＩＳＰ）のサービスアドレスまで前記サービス要求メッセージをルーティングすること、を備える、方法。
適用例２：適用例１に記載の方法であって、前記ＡＰＩタイプは、匿名アクセスタイプを含み、前記１組の認証チェックは、ゼロエレメントを含む、方法。
適用例３：適用例２に記載の方法であって、前記複数のプラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、および、サービス名である、方法。
適用例４：適用例１に記載の方法であって、前記ＡＰＩタイプは、許可サービスタイプを含み、前記１組の認証チェックは、署名チェックおよびタイムスタンプチェックを含む、方法。
適用例５：適用例４に記載の方法であって、前記プラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、および、署名である、方法。
適用例６：適用例１に記載の方法であって、前記ＡＰＩタイプは、ユーザ許可サービスタイプを含み、前記１組の認証チェックは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックを含む、方法。
適用例７：適用例６に記載の方法であって、前記プラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、署名、および、前記ＩＳＶのアプリケーションにおけるユーザセッションの一意のＩＤである、方法。
適用例８：適用例１に記載の方法であって、前記ＡＰＩタイプは、オプションユーザ許可サービスタイプを含み、前記１組の認証チェックは、署名チェック、タイムスタンプチェック、および、オプションでユーザＩＤチェックを含む、方法。
適用例９：適用例８に記載の方法であって、前記プラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、および、署名である、方法。
適用例１０：適用例１に記載の方法であって、前記１組の認証チェックは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックの内の１または複数を含む、方法。
適用例１１：適用例１に記載の方法であって、前記プラットフォームレベルパラメータは、前記独立系ソフトウェアベンダーのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、署名、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤ、および、戻り値のタイプの内の１または複数を含む、方法。
適用例１２：適用例１に記載の方法であって、さらに、ユーザバインディングエラー情報を返すことを備える、方法。
適用例１３：適用例１２に記載の方法であって、前記プラットフォームレベルパラメータは、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤを含み、前記サービス要求メッセージ認証が失敗すると、ユーザバインディングエラー情報が返される、方法。
適用例１４：適用例１に記載の方法であって、さらに、前記プラットフォームレベルパラメータが、サービスのインターネットサービスプロバイダＩＤ、前記独立系ソフトウェアベンダーのサービスを呼び出すためのＩＤ証明、および、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤを含む場合に、キャッシュ内のトークンリストを取得し、トークンが存在し、かつ、有効であるか否かを判定し、トークンが存在しない、あるいは、前記トークンが無効である場合に、ユーザバインディングエラー情報を返すこと、を備える、方法。
適用例１５：適用例１２に記載の方法であって、さらに、前記ユーザバインディングエラー情報の受信後に前記ＩＳＰのログインアドレスに対して第２のサービス要求メッセージを開始することを備え、前記第２のサービス要求メッセージは、自身のプラットフォームレベルパラメータとして、前記独立系ソフトウェアベンダーのサービスを呼び出すためのＩＤ証明、サービス名、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤ、および、ユーザバインディングにパスした後に前記独立系ソフトウェアベンダーのアプリケーションのリダイレクト先となるアドレスを含む、方法。
適用例１６：インターネットサービスを提供するためのサービス統合プラットフォームシステムであって、独立系ソフトウェアベンダー（ＩＳＶ）によって提供されたアプリケーションのユーザによって開始されたサービス要求メッセージを受信するよう構成されたインターフェースと、前記サービス要求メッセージは、アプリケーションプログラミングインターフェース（ＡＰＩ）タイプに従って実装され、前記ＡＰＩタイプに適合する複数のプラットフォームレベルパラメータを含むことと、前記インターフェースに接続された１または複数のプロセッサと、を備え、前記１または複数のプロセッサは、前記ＡＰＩタイプに適切な１組の認証チェックを位置特定し、前記１組の認証チェックに従って、前記サービス要求の認証を実行し、前記サービス要求が認証されると、インターネットサービスプロバイダ（ＩＳＰ）のサービスアドレスまで前記サービス要求をルーティングするよう構成されている、システム。
適用例１７：適用例１６に記載のシステムであって、前記ＡＰＩタイプは、匿名アクセスタイプを含み、前記１組の認証チェックは、ゼロエレメントを含む、システム。
適用例１８：適用例１７に記載のシステムであって、前記複数のプラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、および、サービス名である、システム。
適用例１９：適用例１６に記載のシステムであって、前記ＡＰＩタイプは、許可サービスタイプを含み、前記１組の認証チェックは、署名チェックおよびタイムスタンプチェックを含む、システム。
適用例２０：適用例１９に記載の方法であって、前記プラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、および、署名である、方法。
適用例２１：適用例１６に記載のシステムであって、前記ＡＰＩタイプは、ユーザ許可サービスタイプを含み、前記１組の認証チェックは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックを含む、システム。
適用例２２：適用例２１に記載のシステムであって、前記プラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、署名、および、前記ＩＳＶのアプリケーションにおけるユーザセッションの一意のＩＤである、システム。
適用例２３：適用例１６に記載のシステムであって、前記ＡＰＩタイプは、オプションユーザ許可サービスタイプを含み、前記１組の認証チェックは、署名チェック、タイムスタンプチェック、および、オプションでユーザＩＤチェックを含む、システム。
適用例２４：適用例２３に記載のシステムであって、前記プラットフォームレベルパラメータは、前記ＩＳＶのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、および、署名である、システム。
適用例２５：適用例１６に記載のシステムであって、前記１組の認証チェックは、署名チェック、タイムスタンプチェック、および、ユーザＩＤチェックの内の１または複数を含む、システム。
適用例２６：適用例１６に記載のシステムであって、前記プラットフォームレベルパラメータは、前記独立系ソフトウェアベンダーのサービスを呼び出すためのＩＤ証明、サービス名、サービス要求タイムスタンプ、署名、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤ、および、戻り値のタイプの内の１または複数を含む、システム。
適用例２７：適用例１６に記載のシステムであって、さらに、ユーザバインディングエラー情報を返すことを備える、システム。
適用例２８：適用例２７に記載のシステムであって、前記プラットフォームレベルパラメータは、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤを含み、前記サービス要求メッセージ認証が失敗すると、ユーザバインディングエラー情報が返される、システム。
適用例２９：適用例１６に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記プラットフォームレベルパラメータが、サービスのインターネットサービスプロバイダＩＤ、前記独立系ソフトウェアベンダーのサービスを呼び出すためのＩＤ証明、および、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤを含む場合に、キャッシュ内のトークンリストを取得し、トークンが存在し、かつ、有効であるか否かを判定し、トークンが存在しない、あるいは、前記トークンが無効である場合に、ユーザバインディングエラー情報を返すよう構成されている、システム。
適用例３０：適用例２７に記載のシステムであって、前記１または複数のプロセッサは、さらに、前記ユーザバインディングエラー情報の受信後に前記ＩＳＰのログインアドレスに対して第２のサービス要求メッセージを開始するよう構成されており、前記第２のサービス要求メッセージは、自身のプラットフォームレベルパラメータとして、前記独立系ソフトウェアベンダーのサービスを呼び出すためのＩＤ証明、サービス名、前記独立系ソフトウェアベンダーのアプリケーションにおけるユーザセッションの一意のＩＤ、および、ユーザバインディングにパスした後に前記独立系ソフトウェアベンダーのアプリケーションのリダイレクト先になるアドレスを含む、システム。
【図１】
0005567011.tif 000007
【図２】
0005567011.tif 000008
【図３】
0005567011.tif 000009
【図４】
0005567011.tif 000010
【図５】
0005567011.tif 000011