(57)【要約】  ネットワーク上でＥＰＰリクエストに対して経路指定を行う方法およびシステムを提供する。ＥＰＰリクエストはＸＭＬネームスペース情報および、オプションとしてＸＭＬサブプロダクト情報を含み得る。ゲートウェイは、リクエストの対象となるサービスを特定するためにリクエストを受信し、ネームスペースおよび、時にサブプロダクト情報を分析し得る。それから、ゲートウェイは、全ての利用可能なサービスに対する状態および接続性の情報を有し得るルーティングテーブルを参照することによってリクエストに対して適切なサービスへ経路指定を行える。
2013502824.tif 000002
【特許請求の範囲】
【請求項１】
拡張プロビジョニングプロトコル（ＥＰＰ）を使用し受信されたリクエストに対して経路指定を行うコンピュータにより実施される方法であって、
依頼者からＥＰＰを介しサービスに接続するリクエストを受信することであって、リクエストがＸＭＬを含み、そのＸＭＬはリクエストの対象となるサービスに関する情報を含む、受信することと、
ＸＭＬネームスペース情報を特定するためにＸＭＬを分析することと、
少なくとも部分的にＸＭＬネームスペース情報に基づいてリクエストの対象となるサービスを特定することと、
サービスへの経路指定をリクエストに対して行うことによって依頼者にサービスへアクセスを提供することとを含む方法。
【請求項２】
リクエストに対して経路指定を行う前に、
サービスが有効かどうかを判定することと、
サービスが有効な場合のみにリクエストに対してサービスへの経路指定を行うこととを含む請求項１に記載の方法。
【請求項３】
サービスが無効であると判定した場合、サービスが利用不可能であることを示す通知を依頼者に送信することを含む請求項１に記載の方法。
【請求項４】
ＸＭＬサブプロダクト情報の有無を判定するためにリクエストを分析することと、
ＸＭＬサブプロダクト情報が存在する場合に少なくとも部分的にＸＭＬネームスペース情報およびＸＭＬサブプロダクト情報に基づいてリクエストの対象となるサービスを特定することとを更に含む請求項１に記載の方法。
【請求項５】
ＸＭＬネームスペースがサービスカテゴリに対応する請求項４に記載の方法。
【請求項６】
リクエストに関連する業務が完了する時にサービスから応答を受信することと、
前記応答を依頼者に通信することとを更に含む請求項１に記載の方法。
【請求項７】
サービス内容合意書に対応する一つ以上のパラメータに関連するメタデータを受信することであって、前記メタデータは応答に含まれる受信することと、
前記サービス内容合意書に関連するレポートを発生することであって、前記レポートは少なくとも部分的にメタデータに基づいた、発生することとを更に含む請求項６に記載の方法。
【請求項８】
前記メタデータがリクエストの実行時間に関する情報を含むことを含む請求項７に記載の方法。
【請求項９】
サービスに関連する状態および接続性の情報を受信することと、
サービスに関連する状態および接続性で参照テーブルを更新することとを更に含む請求項１に記載の方法。
【請求項１０】
前記接続性の情報がサービスに関連するＥＰＰハンドラ、ＥＰＰポルハンドラおよびＥＰＰ拡張に関する情報を含む請求項９に記載の方法。
【請求項１１】
リクエストに対して複数のサービスへ経路指定を行う装置であって、
拡張プロビジョニングプロトコル（ＥＰＰ）を介し前記複数のサービスの中で一つのサービスにアクセスするリクエストを受信するように構成された受信モジュールであって、前記リクエストはＸＭＬコードを含み、前記ＸＭＬコードはアクセスするサービスに関する情報を含む、受信モジュールと、
前記受信モジュールに結合され、前記ＸＭＬコードを分析しＸＭＬネームスペース情報を抽出するように構成される分析モジュールであって、前記ＸＭＬネームスペース情報はアクセスするサービスを示す、分析モジュールと、
前記分析モジュールに結合され、少なくとも部分的にルーティングテーブルに含まれた情報に基づいて前記サービスの状態を判定するように構成され、前記リクエストに対して前記サービスへ経路指定を行うルーティングモジュールとを含む、装置。
【請求項１２】
前記ルーティングテーブルが前記複数のサービスの状態および接続性に関連する情報を含む、請求項１１に記載の装置。
【請求項１３】
前記状態および接続性の情報は動的に更新される、請求項１２に記載の装置。
【請求項１４】
前記受信モジュールがハイパーテキストトランスファープロトコル（ＨＴＴＰ）の運搬方法上でリクエストを受信するように構成される、請求項１１に記載の装置。
【請求項１５】
前記受信モジュールがトランスミッションコントロールプロトコル（ＴＣＰ）の運搬方法上でリクエストを受信するように構成される、請求項１１に記載の装置。
【請求項１６】
前記分析モジュールがＸＭＬサブプロダクト情報の有無を判定するためにＸＭＬコードを分析するように更に構成される、請求項１１に記載の装置。
【請求項１７】
前記分析モジュールが前記ＸＭＬサブプロダクト情報を抽出し、前記ＸＭＬサブプロダクト情報に関連するサブサービスを特定するように構成される、請求項１６に記載の装置。
【請求項１８】
リクエストに対して複数のサービスへ経路指定を行うシステムであって、
前記複数のサービスに関連する情報を含むサービス管理サーバと、
前記管理サーバに結合され、前記複数のサービスの中で一つのサービスにアクセスする一つ以上のリクエストを受信するように構成されるゲートウェイであって、前記リクエストは拡張プロビジョニングプロトコル（ＥＰＰ）を使用し受信される、ゲートウェイと、
前記サービス管理サーバおよび前記ゲートウェイと結合され、前記複数のサービスに対してホストとなるように構成される一つ以上のサービスホスティングサーバとを含む、システム。
【請求項１９】
前記サービス管理サーバが前記複数のサービスの各自からデータを受信するように構成され、前記データは前記複数のサービスの各自に関して状態、種類および接続性の情報を示す、請求項１８に記載のシステム。
【請求項２０】
前記サービス管理サーバが前記ゲートウェイに前記状態、種類および接続性の情報を通信する、請求項１９に記載のシステム。
【請求項２１】
前記ゲートウェイがルーティングテーブルを含み、前記ルーティングテーブルは前記複数のサービスの各自に関して状態、種類および接続性の情報を含む、請求項１８に記載のシステム。
【請求項２２】
前記ルーティングテーブルがサービスに関する状態および／または接続性の情報の変化を反映させるために動的に更新される、請求項２１に記載のシステム。
【請求項２３】
装置内のプロセッサにより実行される時に、一つ以上のサービスにアクセスするリクエストに対して経路指定を行う方法をプロセッサに実行させる命令を含むコンピュータ読み込み可能なストレージ媒体であって、
前記方法は、
拡張プロビジョニングプロトコル（ＥＰＰ）を介しサービスにアクセスするリクエストを受信することであって、前記リクエストはＸＭＬコードを含み、前記ＸＭＬコードはＸＭＬネームスペース情報を含む、受信することと、
ＸＭＬネームスペース情報を抽出するために前記ＸＭＬコードを分析することであって、前記ＸＭＬネームスペース情報は前記リクエストの対象となるサービスを示す、分析することと、
少なくとも部分的に前記ＸＭＬネームスペース情報に基づいて前記リクエストの対象となるサービスを特定することと、
前記サービスへリクエストに対して経路指定を行うこととを含む、コンピュータ読み込み可能なストレージ媒体。
【請求項２４】
方法は、
受信されたリクエストからＸＭＬサブプロダクト情報を特定することと、
前記サブプロダクト情報に関連するサービスを特定することとを更に含む、請求項２３に記載のコンピュータ読み込み可能なストレージ媒体。
【請求項２５】
方法は、前記リクエストに対して経路指定を行う前に、
前記一つ以上のサービスの各自に関連する状態および接続性の情報を特定することと、
少なくとも部分的に前記状態および接続性の情報に基づいて前記一つ以上のサービスへ、リクエストに対して経路指定を行うことと、を更に含む、請求項２３に記載のコンピュータ読み込み可能なストレージ媒体。
【請求項２６】
前記状態情報はサービスが有効か無効かを示すことを含む、請求項２５に記載のコンピュータ読み込み可能なストレージ媒体。
【請求項２７】
前記状態および接続性の情報がルーティングテーブル内に保存される請求項２５に記載のコンピュータ読み込み可能なストレージ媒体。
【請求項２８】
前記ルーティングテーブルが前記一つ以上のサービスの各自に関する状態および接続性の情報の変化を反映させるために動的に更新される、請求項２７に記載のコンピュータ読み込み可能なストレージ媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はＥＰＰ上でリクエストの知的経路指定における方法およびシステムに関する。
【背景技術】
【０００２】
本開示は、概にネットワーク上でのリクエストの経路指定に関する。インターネット使用の急成長に伴い、インターネットに関連するサービスにおける需要も急速に伸びている。インターネット使用が増加した結果として、ドメイン名における需要も急速に伸びている。よって、ドメインに関連するサービスの需要も伸びている。そういったドメインに関連するサービスは、ドメイン名作成、ドメイン名登録の更新等を含み得る。典型的に、ウェブサイトはドメイン名に対応するオンライン上の実体を確立させる一次手段の役割を果たす。益々増加するドメイン名に関連するサービスにおける需要を満たすために、これらのサービスを提供するエンティティがその効率および費用効果を高める必要がある。
【０００３】
ドメインネームシステム（ＤＮＳ）は、ヒトが読み取り可能なドメイン名を、インターネット上でのＴＣＰ／ＩＰ通信を確立するために必要とされるインターネットプロトコル（ＩＰ）番号に翻訳する、インターネット基盤の一部である。即ち、ＤＮＳによって、ユーザは、ウェブサイトに関連する、インターネットでコンピュータに割り当てられる「１２３．４．５６．７８」のような数字のＩＰアドレスではなく、「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」のような覚えやすいドメイン名を使用して、ウェブサイトおよび他のリソースを参照することが可能になる。各ドメイン名は、ドットによって区切られる一連の文字列（ラベル）から構成される。ドメイン名の右端のラベルは、「トップレベルドメイン」（ＴＬＤ）として知られる。公知のＴＬＤの例には、「．ｃｏｍ」、「．ｎｅｔ」、「．ｏｒｇ」等がある。各ＴＬＤは、例えば、「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」の「ｅｘａｍｐｌｅ」レベルといった、ＴＬＤのすぐ左に列記される、セカンドレベルドメインをサポートする。各セカンドレベルドメインは、例えば、「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」の「ｗｗｗ」レベルといった、セカンドレベルドメインのすぐ左にあるいくつかのサードレベルドメインを含むことができる。
【０００４】
各ＴＬＤの操作（ＴＬＤ内におけるセカンドレベルドメインのレジストリの維持を含む）に対する責任は、ドメイン名レジストリ（「レジストリ」）として知られる、特定の組織に委譲される。レジストリは、主に、典型的に大規模なデータベースにおいてかかる情報を維持するＤＮＳサーバを介して、ドメインに関連するＩＰアドレスに対するクエリーに回答（「解決」）することと、そのトップレベルドメインを操作することとを担う。
【０００５】
Ｉｎｔｅｒｎｅｔ  Ｃｏｒｐｏｒａｔｉｏｎ  ｆｏｒ  Ａｓｓｉｇｎｅｄ  Ｎａｍｅｓ  ａｎｄ  Ｎｕｍｂｅｒｓ  （ＩＣＡＮＮ）はドットコムおよびドットネットのような一般的なＴＬＤに対して権限を有する。ドメイン名を取得するには、そのドメイン名はＩＣＡＮＮに登録しなければならない。ドメイン名の登録は、とりわけドメイン名登録機関を介して行われる。登録機関はＩＣＡＮＮまたは国家のｃｃＴＬＤ（カントリーコードＴＬＤ）管理者により、インターネットドメイン名を登録するために認定されたエンティティである。または、エンドユーザーは一つ以上のリセラー層を介して間接的にドメイン名を登録することも可能である。
【０００６】
登録機関は、ドメイン関係のサービス、例えばドメイン名作成または更新に、アクセスするために、普段はレジストリとの専用サービス接続を有する。登録機関は、ドメイン名を登録するまたは更新するためにレジストリと通信する際に、典型的に拡張可能プロビジョニングプロトコルの仕組みを使用する。ＥＰＰはインターネット上でレジストリ内にオブジェクトを割り当てるように設計されたプロトコルである。ＥＰＰプロトコルは構造化されたテキストベースの形式であるＸＭＬに基づいたものである。基礎をなす運搬方法は決まっていないが、現在指定された方法は、トランスミッションコントロールプロトコル（ＴＣＰ）上で行うものである。
【発明の概要】
【課題を解決するための手段】
【０００７】
本発明の幾つかの実施形態は、ネットワーク上でＥＰＰリクエストに対して経路指定を行うためのシステムおよび方法に関する。具体的に一実施形態において、拡張プロビジョニングプロトコル（ＥＰＰ）を使用し受信したリクエストの経路指定方法が提供される。リクエストは依頼者より受信することができる。リクエストは、ＥＰＰを介し、サービスプロバイダーが提供するサービスに接続するものでありえる。リクエストはＸＭＬネームスペース情報を含むＸＭＬコードを含むことができる。ＸＭＬネームスペースはリクエストの対象であるサービスに関する情報を示し得る。システムはＸＭＬネームスペース情報を抽出するためにＸＭＬコードを分析することができる。ＸＭＬネームスペース情報を抽出した後、システムはリクエストの対象であるサービスを特定し、リクエストに対してそのサービスへの経路指定を行え、それによって依頼者にサービスへのアクセスを提供し得る。
【０００８】
幾つかの実施形態においては、リクエストはＥＰＰ拡張サブプロダクト情報も含むことができる。その場合、ネームスペース情報はサービスカテゴリに対応し得、そしてサブプロダクト情報はサービスカテゴリ内の特別のサービスに対応し得る。本実施形態おいてシステムはネームスペース情報を抽出しリクエストの対象であるサービスを特定し得る。それからシステムはリクエストが更にサブプロダクト情報を含むかを判定し得、またリクエストがサブプロダクト情報を含む場合システムはそのサブプロダクト情報に関連するサービスを特定し、ネームスペース情報が個別のサービスではなくサービスのクラスに対応することを判定し得る。
【０００９】
幾つかの実施形態においては、システムはネームスペース情報および、利用可能な場合にサブプロダクト情報を抽出し得る。システムは、ネームスペース情報がサービスカテゴリに対応し、サービスカテゴリが複数のサービスをまとめて有することを判定した場合、システムはサブプロダクト情報を使用し、リクエストの対象となる、サービスカテゴリ内の個別サービスを判定し得る。
【００１０】
更に別の実施形態においては、ＥＰＰリクエストの経路指定に使用するゲートウェイが提供される。ゲートウェイはＥＰＰを介しリクエストを受信するように構成されるモジュールを含むことが出来る。リクエストはサービスプロバイダーが提供する複数のサービスの中のサービスにアクセスするものであり得る。リクエストはサービスに対応するＸＭＬネームスペース情報を含むＸＭＬを含み得る。ゲートウェイは受信モジュールに結合され、リクエストの対象であるサービスを特定するためにＸＭＬを分析しＸＭＬネームスペース情報を抽出するように構成された分析モジュールを更に含み得る。ゲートウェイは、ルーティングテーブルに含まれた情報に、少なくとも部分的に、基づいてサービスのステータスを判定し、それから分析モジュールにより特定されたサービスへリクエストの経路指定を行うように構成されたルーティングモジュールを更に含み得る。
【００１１】
図面とともに下記の詳細な説明は本発明の性質および利点によって、より良い理解が可能であろう。
【図面の簡単な説明】
【００１２】
【図１】は、本発明の一実施形態によるリクエストの経路指定を行うシステムのブロック図である。
【図２】は、本発明の一実施形態によるゲートウェイを示すブロック図である。
【図３】は、本発明の一実施形態によるルーティングテーブルを示す。
【図４】は、本発明の一実施形態によるリクエストの経路指定を行う方法を示すフロー図である。
【発明を実施するための形態】
【００１３】
ＥＰＰを使用してネットワーク上でリクエストおよびメッセージの経路指定を行うことが有利であろう。上記のように各登録機関はドメイン名を登録したり更新したりするためにレジストリとのＥＰＰ接続を有する。レジストリがドメインプロビジョニングサービスに加えて、例えばドメイン名提案サービスといった他のドメイン名関係のサービスも提供する場合、登録機関はその更なるサービスにアクセスするためにレジストリと更なる通信形態を使用する必要があるかもしれない。これは、登録機関は典型的に複数のレジストリと通信するので登録機関側のインフラストラクチャーが更に複雑になってしまうであろう。単一のＥＰＰ接続を使用して全ての提供されたサービスにアクセス可能なことによって登録機関の費用を大幅に削減する。この削減された費用はエンドユーザーと分割可能で、それによって登録機関の競争上の優位性を高める。
【００１４】
レジストリ側においては各登録機関と単一のＥＰＰ接続を有することによって各登録機関と別々の複数通信チャンネルを保持する費用を大幅に削減する。更に単一の接続を介しアクセス可能な複数のサービスを統合し提供する能力を有することはレジストリによる新規サービス開発および展開へ勢いを与え、それによってレジストリの収入源を増加させる。
【００１５】
本発明におけるいくつかの実施形態はネットワーク上でＥＰＰで受信された適切なサービスへのルーティングリクエストに関するものである。いくつかの実施形態において受信ＥＰＰリクエストはＸＭＬネームスペース情報を含む。ＸＭＬネームスペース情報はあるサービス、例えばドメイン名の提案、ドメイン名の作成などに対応し得る。システムはこのＸＭＬネームスペース情報を抽出し分析することによってサービスを判定しリクエストに対して適切なサービスへ経路指定を行える。
【００１６】
本発明における別の実施形態はＸＭＬネームスペース情報に加えてＸＭＬサブプロダクト情報を含むＥＰＰリクエストに関するものである。その場合ＸＭＬネームスペース情報はサービスカテゴリに対応し、ＸＭＬサブプロダクト情報はそのサービスカテゴリ内の特定のサービスに対応し得る。
【００１７】
図１ネットワーク上でＥＰＰで受信されたリクエストに対して適切なサービスへ経路指定を行うシステム１００を示す。システム１００はＥＰＰによってリクエストを受信可能なゲートウェイ１０１を含み得る。ゲートウェイ１０１は受信リクエストを受信し各リクエストの対象サービスを判定し得る。対象サービスを判定した上でゲートウェイ１０１はリクエストをそのサービスへ誘導可能である。ゲートウェイ１０１はＥＰＰを使用しリクエストを送信可能な外部システムおよびネットワークと通信可能である。上記の説明のようにＥＰＰのデフォルト運搬方法はＴＣＰであるがいくつかの実施形態においてゲートウェイ１０１はハイパーテキストトランスファープロトコル（ＨＴＴＰ）上でＥＰＰメッセージを送受信するように構成可能である。本発明における一実施形態によるゲートウェイ１０１の構造および機能を下記説明する。
【００１８】
サービスプラットフォーム１０４は一つ以上のサービスを提供することを可能にする拡大縮小可能でフォールトトレラントであり得る。サービスプラットフォーム１０４はデータベース、ユーザーインターフェイスを有しゲートウェーおよび管理サーバと通信するために一つ以上のプロトコルを使用し得る。サービスプラットフォーム１０４は一つ以上のサービス１０３Ａ−Ｃに対してホストとなり得る。サービスプラットフォーム１０４は他にも機能性を有し得るが本発明の内容においてはそれらを理解する必要はない。サービスプラットフォーム１０４はサービスに関する情報を保存するデータベースを有し、メンテナンス、アップグレードなどの活動のために管理サーバへユーザーによる入力を可能にするユーザーインターフェイスを有し得る。サービスプラットフォーム１０４はゲートウェーおよび管理サーバと津新するために一つ以上のプロトコルを使用し得る。サービス１０３Ａ−Ｃはレジストリから提供される個別サービス、例えばドメイン名提案、または各カテゴリに含まれる個別サービスを含むサービスカテゴリのいずれかであり得る。各サービスはゲートウェイ１０１および管理サーバ１０２と通信可能であり得る。各サービス１０３は独自の情報が付属されることができる。そういう情報はサービス名、接続性の情報およびそのサービスと交流可能で様々なアプリケーションを含み得るがこれらに限定されない。いくつかの実施形態においてはサービスプラットフォームおよび別のサービスの正常な機能に影響を及ぼさず更にサービスを追加可能である。サービスプラットフォーム１０４は必要な機能性および能力を有する一つ以上の一般的なサーバを使用し実施可能である。
【００１９】
幾つかの実施形態において、サービスプラットフォーム１０４は、クラスタ構成として実施可能であり、各サービスクラスタサーバは複数のサービスまたはサービスカテゴリを含み得る。例えば、Ｊ２ＥＥクラスタはサービスの整理に使用可能である。その場合、サービスクラスタサーバのＵＲＬは希望のサービスを含むサービスクラスタサーバに指し得、サービスオブジェクト識別子はサーバがホストとなる特定のサービスを識別するために使用されることができる。
【００２０】
管理サーバ１０２はサービス１０３の管理に使用可能であり、全ての利用可能サービスに関連する情報を含み得る。幾つかの実施形態において、各利用可能サービスはそれぞれの独自の情報を管理サーバ１０２に通信し得る。管理サーバ１０２は各サービスに関連する情報のリポジトリであり得る。幾つかの実施形態においては、各サービスに提供された情報は動作状態、接続性の情報、名称、等を含み得る。幾つかの実施形態においては、管理サーバ１０２は、この情報をゲートウェイ１０１に通信し得る。ゲートウェイ１０１は、この情報を一つ以上の、下記説明するルーティングテーブルに保存し得る。ゲートウェイ１０１および管理サーバ１０２は、サービスプラットフォーム１０４がホストとなる一つ以上のサービス１０３Ａ−Ｃと結合し得る。幾つかの実施形態においては、管理サーバ１０２は、各サービスに対して有効化、無効化、追加、削除、変更等、様々な過程を行える。管理サーバ１０２は、必要な機能性および能力を有するいかなるコンピュータシステムでもあり得る。
【００２１】
幾つかの実施形態において、管理サーバ１０２は、幾つかの関連するサービスを一つのサービスグループにまとめることが可能である。例えば、ｃＴＬＤは、ｄｏｔｊｏｂｓ、ｄｏｔｔｖおよびｄｏｔｂｉｚに対して個別のサービスをサービスグループの一部として含むサービスグループであり得る。システム管理者は、一つのエンティティとしてサービスグループを制御し、グループ全体に対して有効化、無効化、アップグレード等の操作を行う能力を有し得る。
【００２２】
幾つかの実施形態において、各サービスは、サービスの起動の際、そのサービスに関する情報を管理サーバ１０２に通信し得る。管理サーバ１０２は、情報を外部システムに配信するために使用できる複数のインターフェースを提供可能である。幾つかの実施形態において、一つ以上のゲートウェイは複数のインターフェースを使用し管理サーバに接続し得る。ゲートウェイはサービスに関する情報を収集するために管理サーバをポルし得る。一実施形態において、サービスに関する情報はそのサービスの動作状態、接続性の情報等を含み得る。幾つかの実施形態において、更なるサービス関係の情報も利用可能であり得る。例えば、各サービスに関連する情報はＥＰＰハンドラ、ＥＰＰポルハンドラおよびＥＰＰ拡張に関する情報を含み得る。システム管理者は管理サーバ上の管理者ユーザーインターフェースアプリケーションを使用し様々なサービスを更新可能である。一度システム管理者がサービスを変更すると、管理サーバ１０２は、サービスに対して行われた更新／変更を自動的にゲートウェイ１０１に通信する。
【００２３】
また、システム１００は、本明細書において特定のブロックを参照しながら説明されているが、このブロックは説明の都合により定義され、構成部分の特定の物理的な配置を示唆する意図はない。更に、システム１００は本明細書において具体的に説明されない能力も有し得る。
【００２４】
図２は本発明の一実施形態によるゲートウェイ２００を示す。ゲートウェイ２００は、ネットワークインターフェースモジュール（ＮＩＭ）２０１を含み得る。幾つかの実施形態において、ＮＩＭ２０１は、従来の有線または無線の媒体のいずれかを使用し外部システムおよびネットワークに通信するように構成されることが可能である。更に、ＮＩＭ２０１は、ＴＣＰまたはＨＴＴＰ上でＥＰＰを介し運搬された、外部システムからのリクエストを受け取ることも可能である。ＮＩＭ２０１は受信モジュール２０２に結合し得る。
【００２５】
受信モジュール２０２は入来するＥＰＰリクエストを受信し得る。幾つかの実施形態において、受信モジュール２０２は入来するリクエストがＥＰＰリクエストであることを、リクエストの構造を判定し標準ＥＰＰ構造と比較することによって確認可能である。受信モジュールは分析モジュール２０３と結合してもよい。分析モジュール２０３は受信モジュール２０２から入来するリクエストを受信しリクエストの対象サービスを特定するためにリクエストを分析し得る。幾つかの実施形態において、ＥＰＰリクエストはＸＭＬネームスペース情報を含み得る。ＸＭＬネームスペースは、ユニフォームリソース識別子（ＵＲＩ）の参照により識別されたネームスペースに関連付けを行うことによってＸＭＬ書類に使用された要素名および属性名を明確にする簡単な方法を提供し得る。ＸＭＬネームスペースはＸＭＬインスタンスにおいて固有の要素名および属性名を提供するために使用可能である。幾つかの実施形態において、リクエストの対象となるサービスの名称を要素および／または属性情報の一部として含み得る。分析モジュール２０３は、ＸＭＬを解析し、ＸＭＬネームスペース情報を抽出し、ネームスペース情報に基づいて特定のリクエストの対象となるサービスを特定し得る。例えば、ネームスペース情報は、名称提案サービスに関連し得る。その場合、リクエストに含まれたＸＭＬの解析はリクエストの対象が名称提案サービスであると示す。
【００２６】
別の実施形態においては、ＸＭＬコードはＸＭＬネームスペース情報に加えてＥＰＰサブプロダクト情報も含み得る。その場合、ＸＭＬネームスペース情報はサービスカテゴリ、例えばドメイン名サービスに対応してもよく、サブプロダクト情報はサービスカテゴリの中で特定のサービス、例えばｄｏｔｔｖドメインサービスまたは名称提案サービスを特定し得る。分析モジュール２０３はネームスペース情報およびＥＰＰ拡張サブプロダクト要素を特定するためにリクエストに含まれたＸＭＬを解説する能力も有し得る。
【００２７】
ルーティングモジュール２０４はアクセスが依頼されたサービスを示す、解析されたＸＭＬを分析モジュールから受信し得る。ルーティングモジュール２０４は、サービスが現在有効であるかを判定するためにサービスの状態を確認し得る。幾つかの実施形態において、ルーティングモジュールは、ルーティングテーブル２０５を参照することによって状態の情報を確認可能である。
ルーティングテーブル２０５の詳細な説明は下記の通りである。ルーティングテーブル２０５は、ルーティングモジュール２０４の内部または外部であってもよい。幾つかの実施形態においては、状態の情報に加えて、ルーティングモジュール２０４は、リクエストに対して正確に経路指定を行うために、サービスに関する他の情報、例えば接続性の情報も判定可能である。また、ルーティングモジュール２０４は対象サービスを特定した上でリクエストに対して経路指定を行うように構成してもよい。
【００２８】
ストレージ装置２０６は、例えばディスク、フラッシュメモリ、または他にいかなる不揮発性ストレージを使用し実現してもよい。幾つかの実施形態において、ストレージ装置２０６はルーティングテーブル２０５を保存し得る。ストレージ装置２０６は、ＸＭＬコード分析を行うこと、分析に基づいてリクエストに対して経路指定を行うことのプログラム命令のように他の情報も保存可能である。
【００２９】
一つ以上の集積回路（例えば従来のマイクロプロセッサまたはマイクロコントローラ）として実施可能であるＣＰＵ２０７は、ゲートウェイ２００の動作を制御可能である。幾つかの実施形態において、ＣＰＵ２０７は、ストレージ装置２０６に保存されたプログラム命令を実行して、分析モジュール２０３および／またはルーティングモジュール２０４に指示して、ある機能を実行させてもよい。
【００３０】
また、ゲートウェイ２００は本明細書において特定のブロックに対して説明されるが、それらのブロックは説明の都合により定義され、構成部分の特定の物理的な配置を示唆する意図はない。更に、ブロックは必ずしも物理的に別の構成部分に対応する必要はない。ブロックは、例えばプロセッサをプログラムすることまたは適切な制御回路を提供することによって、様々な動作を行うように構成してもよく、様々なブロックは最初の構成をどのように取得したかによって再構成可能または不可能であり得る。本発明の実施形態は、回路およびソフトウェアのいかなる組み合せを使用し実施された電子装置を含めて様々な装置として実現可能である。
【００３１】
本明細書に記載されたシステム構成および構成部分は例として挙げられ、変化および変更は可能であると理解すべきである。ゲートウェイ、管理サーバおよびサービスプラットフォームは具体的に本明細書に記載されていない能力を有し得る。
【００３２】
図３は本発明の一実施形態によるルーティングテーブル３００を示す。上記のように、ルーティングテーブルは一つ以上の利用可能なサービスに関連する情報を有し得る。ルーティングテーブル３００はサービスＩＤ情報３０１を含み得る。幾つかの実施形態において、サービスＩＤはリクエスト命令に含まれたＸＭＬネームスペース情報であり得る。ルーティングテーブル３００は、サブプロダクト情報３０２も含み得る。上記のようにサブプロダクト情報はサービスのグループの中で個別サービスであってもよく、サービスグループ内のカテゴリを指してもよい。例えば、図３に示すようにサブプロダクトｄｏｔＴＶはサービスグループｃｔｌｄの一部である。この情報はサービスグループ内の特定のサービスまたはカテゴリにリクエストを誘導するには有用であり得る。上記のように、グループに所属するサービスは関連するサブプロダクト情報を有し得る。ルーティングテーブル３００は、例えばＣＴＬＤドメイン作成、または名称提案というサービス名３０３も含み得る。幾つかの実施形態において、ルーティングテーブル３００は図３の項目３０４が示すようにサービスのバージョン番号も含み得る。この情報は、同時に動作しなければならない、サービスに複数のバージョンがある場合に必要であり得る。その場合、バージョン情報３０４は、サービスの適切なバージョンにリクエストを誘導するには有用であり得る。ルーティングテーブルは接続性の情報３０５も含み得る。幾つかの実施形態において、接続性の情報は上記のように、サービスまたはサービスクラスタサーバーに関連するＵＲＬを含み得る。上記のルーティングモジュールはＵＲＬ情報を使用し入来するリクエストに対して経路指定を行える。別の実施形態においては、接続性の情報は命令を送信する必要のあるサービス内のオブジェクトに対する経路指定情報を更に含み得る。項目３０６はサービスの状態、例えば有効または無効を含み得る。幾つかの実施形態において、ルーティングモジュールはリクエストを送信する前にサービスの状態を確認し得る。幾つかの実施形態において、「有効」および「無効」に加えて、状態は「故障」、「オフライン」、「一時的に利用不可能」等のように他の状態も含み得る。ルーティングテーブルはグループＩＤ情報３０７も含み得る。グループＩＤ情報はサービスが所属するグループ／カテゴリの名称を示し得る。例えば、ｃｔｌｄは、ｄｏｔｔｖ、ｄｏｔｊｏｂｓ、ｄｏｔｃｃ等に対してドメイン、ホスト、契約サービスを含むグループであってもよい。
【００３３】
幾つかの実施形態において、ルーティングテーブル３００をサービスまたはサービスグループ／カテゴリを変更する度に動的に更新し得る。別の実施形態においては、ルーティングテーブル３００を定期的に更新し得る。幾つかの実施形態において、ルーティングテーブル３００に含まれた全ての情報は管理サーバに供給可能である。別の実施形態においては、ルーティングテーブル３００は、例えば管理サーバやサービスプラットフォーム、様々な情報源から情報を取得可能である。幾つかの実施形態において、ルーティングテーブルに含まれた一つ以上のサービスおよび／またはサービスカテゴリにおける内容は固定であり手動でしか更新できない。
【００３４】
ルーティングテーブル３００はある一定の情報に対して説明されたが、示した情報は例として挙げたものだけだと理解すべきである。当業者は、ルーティングテーブル３００が図３に示した情報の代わりに、またはそれに加えて、他の情報を有し得ると理解するであろう。
【００３５】
図４はネットワーク上でＥＰＰを介し受信したリクエストに対してあるサービスへ経路指定を行う過程４００のフロー図である。過程４００は、例えば図２に示すゲートウェイ２００を使用し実施可能である。ステップ４０１では、ゲートウェイは利用可能なサービスの一つにアクセスするリクエストを依頼者から受信し得る。リクエストはアクセスするサービスに関する情報を有し得るＸＭＬを含み得る。ステップ４０２では、入来するリクエストをリクエストに含まれたＸＭＬネームスペース情報および、オプションとしてサブプロダクト情報を抽出するために解析可能である。幾つかの実施形態において、ＸＭＬネームスペース情報はアクセスするサービスに関する情報を含み得る。
【００３６】
ステップ４０３では、ＸＭＬネームスペース情報はリクエストの対象となるサービスを特定するために使用可能である。一度アクセスするサービスを特定すると過程はステップ４０４に進み、そこで依頼されたサービスが個別サービスかサービスカテゴリかを判定可能である。幾つかの実施形態においてこの判定はＸＭＬネームスペース情報に基づいて行い、その際ルーティングテーブルを参照してネームスペース情報が個別サービスかサービスカテゴリに所属するかを確認可能である。
【００３７】
ステップ４０４でネームスペース情報が個別サービスに対応すると判定した場合、ステップ４０５ではサービスが有効であるかを確認可能である。サービスが無効である場合、ステップ４０６ではシステムはサービスが利用不可能というメッセージを依頼者に送信可能である。幾つかの実施形態において、メッセージは、例えばサービスがオフラインとなった時刻、再有効化の見込み時刻等、システム管理者が依頼者に伝えたい更なる情報を含み得る。ステップ４０５でサービスが有効であると判定された場合、ステップ４０７でリクエストに対してサービスへ経路指定を行う。幾つかの実施形態において、ステップ４０８でサービスはリクエストを処理した後でリクエスト完了メッセージを発生させてもよい。リクエスト完了メッセージはリクエストが処理されたことを示すメッセージであり得る。ステップ４０９で完了メッセージを依頼者に通信可能である。一実施形態においてサービスは完了メッセージをゲートウェイに送信し、次にゲートウェイは完了メッセージを依頼者に転送する。幾つかの実施形態において、完了メッセージは依頼者に通信しない可能性がある更なる情報を含み得る。例えば、完了メッセージは、例えばリクエストの実行時間、リクエストに関する更なる情報を特定するメタデータを含み得る。そのような情報はサービスプロバイダーにより交渉されたサービス内容合意書（ＳＬＡ）の一部として必要となり得る。メタデータ情報は、例えばリクエストの実行時間、約束されたＳＬＡ基準を満たしていることをサービスプロバイダーにより確認するために使用可能である。幾つかの実施形態において、ゲートウェイは、メタデータを含む完了メッセージを受信した上で、将来的な使用のためにメタデータ情報を記録し、完了メッセージのみを依頼者に転送し得る。
【００３８】
一方ステップ４０４でネームスペース情報がサービスカテゴリに対応すると判定した場合、ステップ４１０でシステムは、リクエストの対象となるサービスカテゴリ内のサービスを特定するためにＸＭＬに含まれたサブプロダクト情報を使用し得る。一度サービスを特定すると、過程はステップ４０５から続行可能である。
【００３９】
幾つかの実施形態において、リクエストはＸＭＬネームスペースおよびサブプロダクト情報を含むがステップ４０４ではネームスペース情報に関連するサービスが個別サービスであると判定した場合、システムはサブプロダクト情報を無視しＸＭＬサブプロダクト情報を使用しリクエストに対して特定サービスへ経路指定を行える。別の実施形態においては、システムはリクエストの経路指定が失敗したことおよび失敗の理由を示すエラーメッセージを返し得る。
【００４０】
幾つかの実施形態において、リクエストがサブプロダクト情報を含まずステップ４０４でＸＭＬネームスペース情報があるサービスカテゴリに関連すると判定された場合、システムはメッセージの経路指定が失敗したことおよび失敗の理由を示すエラーメッセージを返し得る。
【００４１】
本明細書において説明された過程４００は例として挙げられ、変化および変更が可能であると理解すべきである。順次と記載された行動は並行に実行してもよく、行動の順番を変更してもよく、行動自体も更新するか組み合わせてもよい。例えば、ステップ４０５を省略しサービスの現状を確認せずリクエストをサービスに送信してもよい。幾つかの実施形態において、ステップ４０２および４０３を組み合わせ、ＸＭＬを解析し、アクセスするサービスおよび／またはサービスカテゴリを特定するためにネームスペース情報および／またはサブプロダクト情報を同時に抽出することも可能である。
【００４２】
本発明は具体的な実施形態に対して説明されたが、当業者は多数の変更が可能であると理解するであろう。例えば、ゲートウェイおよびサービス管理サーバは本明細書に記載されていない更なる機能性を有し得る。また、リクエストは一つ以上のサブプロダクトに対応する情報を含み、各サブプロダクト情報はサービスグループ／カテゴリの階層内のレベルに対応し得る。よって、サービスグループ／カテゴリ内では複数のレベルのサービスがあってもよく、リクエストは一つ以上のＸＭＬネームスペースおよび／またはサブプロダクト情報を含むことによってサービスを特定可能である。
【００４３】
更に、本発明の実施形態は、専用構成部分および／またはプログラマブルプロセッサおよび／または他のプログラマブル装置のいかなる組み合せにより実現してもよい。上記説明された実施形態は具体的なハードウェアおよびソフトウェアの構成部分を参照することがあるが、当業者はハードウェアおよび／またはソフトウェアの他の組み合せも使用可能であり、ハードウェアにより実施されると説明された特定の動作はソフトウェアにより実施してもよく、また逆の場合も同様である。
【００４４】
本発明の様々な特徴を実現するコンピュータプログラムはストレージおよび／または送信のために様々なコンピュータ読み取り可能な媒体に暗号化してもよく、適切な媒体は磁気ディスクまたはテープ、コンパクトディスク（ＣＤ）やＤＶＤ（デジタルバーサタイルディスク）のような光学ストレージ媒体、フラッシュメモリ等を含む。プログラムコードが暗号化されたコンピュータ読み取り可能な媒体は互換性のある装置と梱包するか、または他の装置と別に提供すること（例えばインターネットダウンロードによる）も可能である。
【００４５】
よって、本発明は具体的な実施形態に対して説明されたが、本発明が下記の請求項の範囲内の全ての変更および均等物を網羅すると理解すべきである。
【符号の説明】
【００４６】
１００  システム
１０１  ゲートウェイ
１０２  管理サーバ
１０３  サービス
１０４  サービスプラットフォーム
【図１】
2013502824.tif 000003
【図２】
2013502824.tif 000004
【図３】
2013502824.tif 000005
【図４】
2013502824.tif 000006
【国際調査報告】
2013502824.tif 000007