JP2009521747A - データパケットネットワークを経た要求ブロードキャスティングを介してサービス接続の位置を特定し、取得するためのシステムおよび方法 - Google Patents

Abstract

ダイナミックエンドノード応答機能を有するブロードキャストルーティングシステムは、ブロードキャスト要求を生成するための第１のノードと、要求をブロードキャストするため第１のノード上で動作する、または第１のノードにとって利用可能なブロードキャストアプリケーションと、ブロードキャストチャネルをモニタし、要求を受信できるようにされた１つまたは複数の宛先ノードと、１つを超える宛先ノードが存在する場合は、どの宛先ノードが要求をサービスするかを判定するために、１つまたは複数の各宛先ノード上で動作する、または１つまたは複数の各宛先ノードにとって利用可能なソフトウエアルーチンとを備える。

Description

本発明はデータパケットネットワークを経たピアツーピアネットワーキングの分野にあり、特にインタラクション要求を受信するようにされた１つまたは複数のターゲットエンドポイントシステムでのインタラクション要求にスキルおよびプロファイルの関連性を適合させることによって、ネットワーク化されたピア間のネットワーク接続を確立するための方法および装置に関する。

ピアツーピアネットワーキング技術は、データネットワークに接続された２つのノード間でのある種の通信またはデータ共有接続を確立することを含んでいる。それらの例にはピアツーピアメディア共有システムおよびこれらのシステムを作動可能にするソフトウエアが含まれる。インタラクティブなチャットシステムおよびソフトウエアは、例えば１つのノードが別のノードを２つのノードだけの間での個人的セッションに招待する場合に生ずるピアツーピア通信をも提供する。一般にピアツーピアネットワーキングはこの分野で良く確立され、知られている。インターネットネットワークはこのタイプのネットワーキング用のコンジットを備え、符号分割多元接続（ＣＤＭＡ）セルラ、および時分割多元接続（ＴＤＭＡ）セルラネットワーク、コーポレートＬＡＮネットワーク、ホームＬＡＮネットワーク他、などの多くのタイプの接続デジタルネットワークと共に実施されてもよい。

ピアツーピアネットワーキングの１つの主要目的は、多数のコンピュータまたは他のネットワーク対応デバイスを介してリソースを配分し、次いでこれらのデバイスを接続アドレス、およびこれらのデバイスを通して提供される関連するコンテンツまたはサービスによってディレクトリ内で検索可能にすることである。従来のピアツーピアネットワークアーキテクチャの制約の１つはシステムが、ネットワーク内のピアが互いに発見し、相互接続を確立できるようにするピアディレクトリサーバを使用する必要があることである。多くのピアツーピアディレクトリサーバは、インスタントメッセージング機能、オンラインプレゼンス（アクティブ、アウエーなど）他に関連する特定のピアプレゼンスに関するある特定のプレゼンスデータをも提供できる。したがって、１つのピアがディレクトリサーバを閲覧し、またはディレクトリの検索を行って、検索ピアの意図する目的を果たすことができるある特定のピア、すなわちピアが望むファイルを有し、オンラインでトランザクションの準備ができているピアを発見できる。例えばディレクトリサーバ内のピアエントリをクリックすることによって、要求ピアは接続内の他のピアからのダウンロードを、または場合によってはそこへのアップロードを即座に開始できる。別の場合は、トランザクションはＶｏＩＰ、ＩＭ、様々なチャットモード、およびインターネットベースのテレフォニーなどの簡単な通信である。

テレフォニーでは、プレゼンス情報を有するピアツーピア接続は２者間の簡単な電話接続と考えてもよく、その際、双方の端末機がオフフックされている限り、双方の加入者は存在するものと見なされる。しかし、他のピアツーピア接続の場合と同様に、これらの通信システムにはインタラクション要求を送るための中央ルーティングポイントおよびソフトウエアが必要である。これらのルーティングポイントはテレフォニールーティングスイッチおよびソフトウエア実装、ピアディレクトリサーバ、または要求を処理し、２者間の接続状態を促進するためにあるルーティングルーチンを実行するように構成された他のノードでもよいであろう。

発明者に知られており、本明細書で（当社整理番号（４６４３）と呼ばれるより高度のテレフォニーシステムは、企業のクライアントまたは通信センターが、センターに実際にコールする前に通信センターで働いているエージェントに関するプレゼンス情報にアクセスすることを可能にする。プレゼンス情報にはリアルタイムでアクセスされる。同様に、センターのエージェントはコールバックおよびコールのリダイレクトの目的でクライアントに関するプレゼンス情報にリアルタイムでアクセスする。このようなプレゼンス報告はリアルタイムのメッセージングプロトコルＲＴＭＰを含んでいてもよい。発明者に知られている別のシステムは、通信センターで働いているエージェントのマップ可能スキルプレゼンスオブジェクトを提供する。スキルプレゼンスオブジェクトは中央システムによってリアルタイムで発見できる。次いで中央システムはスキルプレゼンスの知識を利用して、プレゼンス情報に基づいて通信要求を送る。これらのより高度のテレフォニーシステムでは、ある場合はインテリジェントルーティングが増強され、別の場合にはクライアントは、通信要求の開始にコミットする前により多くのフレキシビリティを有している。しかし、これらのシステムは双方とも、中央サーバおよび通信のための加入者相互の接続を成功させる集中ルーティング戦略に依存している。

この分野で明らかに必要であるのは、中央ルーティングポイントから実行される動作ではなく、ピア自身によって実行される動作に基づいてピアツーピア接続状態を可能にするシステムおよび装置である。このようなシステムはピアが、ある中心ルーティングポイントまたはサーバから送られたインタラクション要求を待機するのではなく、判断基準に適合するインタラクションに参加することを可能にする。

ダイナミックエンドノード応答機能を有するブロードキャストルーティングシステムが提供される。このシステムは、ブロードキャスト要求を生成するための第１のノードと、要求をブロードキャストするため第１のノード上で動作し、または第１のノードにとって利用可能なブロードキャストアプリケーションと、ブロードキャストチャネルをモニタし、要求を受信できるようにされた１つまたは複数の宛先ノードと、１つを超える宛先ノードがある場合は、どの宛先ノードが要求をサービスできるかを決定するため、１つまたは複数の宛先ノード上で動作し、または宛先ノードにとって利用可能なソフトウエアルーチンとを備えている。

一実施形態では、第１のノードはデスクトップコンピュータ、ラップトップコンピュータ、携帯電話、音楽プレーヤ、携帯情報端末、またはハンドヘルドコンピューティングデバイスの１つである。一実施形態では、ブロードキャストアプリケーションは、ネットワークアクセスを介して第１のノードにとって利用可能なサーバノード上で動作する。一実施形態では、ネットワークはインターネットネットワークである。

好ましい実施形態では、要求はアドレスと、コンタクト情報と、要求のタイプとを備える送信者身元認証を含んでいる。一実施形態では、要求のタイプはコードまたは番号に相当する。一実施形態では、宛先ノードはコンピュータ、ラップトップ、携帯電話、携帯情報端末、またはインターネットプロトコル電話の１つまたはそれらの組み合わせである。一実施形態では、ソフトウエアルーチンは、データパケットネットワークを経て宛先ノードにアクセス可能なルータ上で利用可能である。

本発明のさらなる態様によれば、ブロードキャストルーティングシステムは、受信された要求の直接ルーティング、または受信された要求の再ブロードキャストが可能な中間宛先ノードとして構成された１つまたは複数のネットワークゲートウェイを含んでいる。この実施形態では、１つを超えるゲートウェイの場合は、各ゲートウェイ用に事前に割り当てられたトラフィック負荷の閾値を用いて負荷の平衡が行われる。

一実施形態では、１つまたは複数のゲートウェイを使用し、または使用せずに、第１のノードと１つまたは複数の宛先ノードとが要求をブロードキャストでき、ブロードキャストされた要求を受信できる。

本発明の別の態様によれば、コンピューティングノードが要求をブロードキャストし、これらの要求への応答を受信できるようにするソフトウエアユーティリティが提供される。ユーティリティはメッセージの準備および分類用モジュールと、アドレスタギング（ａｄｄｒｅｓｓ ｔａｇｇｉｎｇ）および送信スケジューリング用モジュールと、受信ノードからの応答を受信するためのモジュールとを備えている。

本発明のさらに別の態様によれば、コンピューティングノードがブロードキャストされた要求を受信し、受信された要求をサービスするかサービスしないかを決定できるようにするソフトウエアユーティリティが提供される。このユーティリティは、ブロードキャスティングネットワークチャネルをモニタするためのモジュールと、ブロードキャストメッセージを受信し、解析するためのモジュールと、受信された要求がノードによってサービスされてもよいか否かを決定するためのモジュールとを備えている。

ブロードキャストユーティリティの一実施形態では、コンピューティングノードは企業の顧客によって操作されるノードである。要求受信ユーティリティの一実施形態では、コンピューティングノードは企業の社員または従業員によって操作されるノードである。

本発明のさらに別の態様によれば、サービスの位置を特定し、データパケットネットワークを経てサービスとのサービス接続を確立するための方法が提供される。この方法は、（ａ）サービス接続を確立して要求のサービス要件の遂行を開始するための命令を含む要求のタイプをフォーマットする動作と、（ｂ）１つまたは複数のエンドノートが要求をサービスすることができる該エンドノードにアドレス指定された、フォーマットされた要求をネットワーク上の開始ノードからブロードキャストする動作と、（ｃ）要求を受信するようにアドレス指定されたエンドノードでブロードキャストされた要求を受信し、タイプと意図に関して要求を解析する動作と、（ｄ）受信された要求のタイプと意図を各受信ノードに保存されたサービスプロファイル情報と比較する動作と、（ｅ）要求のサービス要件といずれかの受信ノードでのサービスプロファイルとの適合が発見されると、サービス要求を受け入れる動作と、（ｆ）いずれかの受け入れノードについて要求の受け入れが承認されると、開始ノードまたは関連する実装と受け入れノードまたは関連する実装とのサービス接続を確立する動作とを含んでいる。

方法の一態様では、動作（ａ）で、タイプの要求がタイプのリストから選択され、要求をサービスするために必要な情報を追加することによって完了される。方法の一態様では、動作（ｂ）で、開始ノードはデスクトップコンピュータ、ラップトップコンピュータ、携帯情報端末、インターネットプロトコル電話、ネットワーク対応音楽プレーヤ、または携帯電話の１つである。別の態様では、動作（ｂ）で、開始ノードはネットワーク上でホストされるサーバノードである。

方法の一態様では、動作（ｂ）で、ブロードキャスティングは反復ブロードキャストバースト用にスケジューリングされる。一態様では、動作（ｅ）で、適合が発見されない場合は、要求を無視し、または次のブロードキャストに追加するための参照アドレス情報を有するか、または有さないサービス不能メッセージで応答する。

方法の一態様では、動作（ｆ）で、開始ノードで受け入れの承認が決定される。別の態様では、動作（ｆ）で、ナンバリングが１を超える場合は要求を受け入れるエンドノードの中で受け入れ承認が緩和される。さらに別の態様では、動作（ｆ）で、受け入れノードの承認は第三者ノードによって行われる。この態様では、第三者ノードはゲートウェイノードである。

ここで初めて、可能性のあるサービスノードによる要求の取り込み（ｇｒａｂｂｉｎｇ）、およびサービス受け入れ確認の承認を可能にするサービスのための、ネットワークを介したブロードキャスト要求によるサービスの位置の特定および取得のための新規のシステムおよび方法が提供される。

図１は、発明者に知られている典型的なピアツーピア通信ネットワーク１００のアーキテクチャ概要である。ピアツーピア（Ｐ２Ｐ）通信ネットワーク１００は、論理的説明の目的だけのために論理上は２つの別個のＰ２Ｐネットワークに分割される。パブリックＰ２Ｐ（ＰＰ２Ｐ）ネットワーク１０１と、カスタムＰ２Ｐ（ＣＰ２Ｐ）ネットワーク１０２とである。

ＰＰ２Ｐネットワーク１０１は、インターネットネットワーク上でホストされるなど、典型的には公衆が利用できるピアツーピア環境である。しかし、異なる多くの物理的アクセス方法およびネットワーク構成が可能であり、存在できることを当業者は理解しよう。ＰＰ２Ｐネットワーク１０１は、本明細書でクライアントデバイス１０３、クライアントデバイス１０４、およびクライアントデバイス１０５として示されている複数のクライアントデバイスに対応する。この例では、クライアントデバイス１０３はネットワークアクセスおよびＰ２Ｐの関与が可能なデジタル携帯電話である。クライアントデバイス１０４はワイヤレスラップトップコンピュータであり、クライアントデバイス１０５はパーソナルデスクトップコンピュータである。他のネットワーク対応デバイスも存在することを当業者は理解しよう。デバイス１０３−１０５はさらに、携帯情報端末（ＰＤＡ）および／またはＰ２Ｐネットワークにアクセスできるその他のハンドヘルドコンピューティングデバイスを含んでいてもよい。さらに、ネットワーク上のピアから音楽をダウンロード可能な音楽プレーヤが使用されてもよい。

ＰＰ２Ｐネットワーク１０１は、この分野で現在知られているように、ディレクトリサーバ１０６を使用する。ディレクトリサーバ１０６は、Ｐ２Ｐのクライアントが互いに発見し、双方間のある種のＰ２Ｐ接続を確立できるようにする多様なサーバタイプの１つでよい。この例では、ＰＰ２Ｐネットワーク１０１は、本明細書に示され、隣接するＣＰ２Ｐネットワーク内のあるノード宛の、中間ＰＰ２Ｐネットワークから出る要求を送るように構成されたネットワークゲートウェイ（ＧＷ）１０７を有している。ＧＷ１０７はマルチメディアメッセージング機能を有するエッジルータでよい。ＧＷ１０７はポリシーサーバ（ＰＳ）１０８、およびルーティングサーバ（ＲＳ）１０９と共に構成されている。サーバ１０８および１０９は、ポリシーおよびルーティング戦略に関してある情報をＧＷ１０７に提供するように構成されている。ＰＳ１０８およびＲＳ１０９は一態様では、本発明の趣旨と範囲から離れることなく、組み合わせてもよく、または各々が他方なしで自立してもよい。

ＣＰ２Ｐネットワーク１０２はサービスステーション１１０ａ−ｎを含んでいる。サービスステーション１１０ａ−ｎは、要求がＰＰ２Ｐネットワーク１０１から発し、ＧＷ１０７を経てサービスのためにＣＰ２Ｐネットワーク１０２へと送られる要求クライアント向けにある特定のサービスを行うように構成されたステーションでよい。別個の２つのＰ２Ｐネットワーク１０１および１０２は、説明目的だけのために、論理上はある企業サービス方式に従ってあるタイプのＰ２Ｐ対応クライアントによって分割される。正確なＰ２Ｐサービス方式はこの例には直接関連しない。

ステーション１１０ａ−１１０ｎはコールセンター内のサービスエージェントでよい。一実施形態では、ステーション１１０ａ−ｎは会社の従業員でよい。別の実施形態では、これらのステーションは特定の大学に所属する人物によって操作されるステーションでもよい。さらに別の実施形態では、これらのステーションは家庭の一般住民の誰かによって操作されてもよく、家庭はＣＣＰ２Ｐ １０２などのプライベートネットワークを有する集団によってサービスされる。各ステーション１１０ａ−１１０ｎはデスクトップコンピュータおよび携帯電話を組み入れている。例えば、デスクトップコンピュータ１１１ａ−１１１ｎはそれぞれのステーション１１０ａ−１１０ｎ内に各々一台ずつ設置されている。同様に、携帯電話１１２ａ−１１２ｎはそれぞれのステーション１１０ａ−１１０ｎに１台ずつ関連している。本発明の趣旨と範囲から離れることなく、ステーション１１０ａ−１１０ｎに関連する通信デバイスのその他の混合もあり得ることを当業者は理解しよう。それらの例にはラップトップ、インターネットプロトコル電話、ＰＤＡなどが含まれる。

ＧＷ１０７は２つのネットワーク１０１および１０２の間に継続性をもたらす。典型的な方法では、典型的なＰ２Ｐモデルで知られているように、ディレクトリ内にリストされている他のいずれかの適当なクライアントまたはステーションとのＰ２Ｐ接続を形成するため、どのクライアント１０３−１０５も現行のアクセスネットワークに接続されている間に、ディレクトリサーバ１０６にアクセスしてもよい。通信モードは、インスタントメッセージング、ファイル共有、チャット、ホワイトボードソフトウエア、ＶｏＩＰテレフォニー、およびネットワークによってサポートされるその他のアプリケーションおよび通信メディアを含んでもよい。すなわち、この例でのＰ２Ｐ要求の正確な目標は広範に変わってもよい。本モデルは、説明目的だけのために、ステーション１１０ａ−１１０ｎがクライアント１０３−１０５をサービスするためのものであると想定している。

典型的な使用の実施形態では、クライアント１０４は、ネットワーク内のどこかの適宜なピアの位置を特定して、そのピアとのＰ２Ｐ接続を構築するために、Ｐ２Ｐソフトウエア（図示せず）を介してディレクトリサーバ１０６にアクセスする。ディレクトリサーバ１０６は、ピアのプロファイル情報およびコンテンツまたはサービス記述子を含む典型的な情報を提供できる。サーバ１０６はさらに、ピアがオンラインであり、要求に応ずるか否かなどの特定のプレゼンス情報を提供できる。ほとんどの場合、ピアノードがディレクトリ内に見える場合は、ピアノードは現行のネットワークにログオンし、要求に応じるように待機する。

この例では、クライアント１０４はディレクトリ１０６にアクセスし、ディレクトリ内にリストされている特定のピアを選択する。この場合は、選択されるピアはステーション１１０ｂでよい。一実施形態では、クライアント１０４はディレクトリ１０６内のピアを選択せず、その代わりにピア１１０ａ−１１１ｎを含み得るサービスグループを選択してもよい。いずれの場合も、サーバ１０６は要求をＧＷ１０７に転送する。何故ならば、選択されたピアまたはピアグループはエッジノードとして別個のネットワークＣＰ２Ｐ １０２内に存在するからであり、それはこれらのピアまたはピアグループが、それ以上の子ノードを有していないネットワーク接続ツリー内のネットワーククラウドおよび最後に到達可能なノードのエッジ上にあることを意味している。

一実施形態では、ゲートウェイ１０７は、ノード１０６からそこに転送される要求の処理に際してポリシーサーバ１０８、および／またはルーティングサーバ１０９を使用してもよい。この場合は、要求はグループ１１０ａ−１１０ｎの１つからサービスを得ようとする要求でよい。ポリシーおよびルーティング戦略は、グループのどのステーションに要求を送るかを決定する際にＧＷ１０７を支援する。この場合は、要求はステーション１１０ｂに送られ、そこで要求はＰＣ１１１ｂまたはセル１１２ｂ上で受信されるであろう。

別の例では、サーバ１０６からゲートウェイ１０７に転送された要求は、特にステーション１１０ｂ向けの要求でよく、要求の意図された受け手としてこれを特定してもよい。この場合は、ディレクトリから特にステーション１１０ｂを選択するためにクライアントデバイス１０４が使用される。ステーション１１０ｂへの要求をＰＣ１１１ｂまたはセル１１２ｂのいずれかに転送するために、ＧＷ１０７は、ポリシーサーバ１０８またはルーティングサーバ１０９に諮る必要はない。

ステーション１１０ｂがゲートウェイ１０７から要求を受信すると、通信シナリオに応じて必要なある種の動作がなされてもよく、なされなくてもよい。ある場合は、要求はチャットに対する要求または招待またはリンクでよい。ステーション１１０ｂのオペレータは招待を受けるように要求されてもよい。ある場合は、ステーション１１０ｂ内のＰＣ１１１ｂが、コンテンツをそこからダウンロードできる共有フォルダを有していてもよい。この場合は、ステーション１１０ｂのオペレータ側でのそれ以上の動作は必要ない。オペレータはすでにコンテンツを共有することに合意しているので、選択されたコンテンツのダウンロードを許可することによって要求は自動的に処理される。多くのＰ２Ｐシナリオでは、それはディレクトリサーバ１０６内に本来リストされているコンテンツであり、そのコンテンツは、その資料の特定のバージョンのコピーを保存する１つまたは複数のピアと１つまたは複数のバージョンで関連付けられていることがある。例えば、ピア１１０ｎはピア１１０ｂと同じコンテンツを有し得るが、ピア１１０ｂは品質がより高いバージョン、またはより新しいバージョンを有し、または特定されたコンテンツのバージョンをより迅速に送信するためのより広い帯域幅を有していることがある。

背景技術の項でさらに記載したように、ディレクトリサーバ１０６は、必要とされる何らかの元の要求の意図を実現するために、クライアントがゲートウェイを介して選択されたピアとの接続を構築することを可能にする上で重要な役割を果たす。ディレクトリサーバ１０６がなければ、この例のシステムはいずれかの地理的な意義を伴って動作することは全くないであろう。

図２は、本発明の実施形態によるピアツーピア接続が確立されているピアツーピア通信ネットワーク２００のアーキテクチャ図である。この例に示されている要素の幾つかは図１の例にも示されている。既に説明されているこれらの要素は同じ要素番号を保持し、再度説明はされない。

本発明の実施形態によれば、クライアント１０３−１０５は、デバイス１０３にインストールされた適宜のブロードキャストテクノロジーソフトウエア（ＢＴＳ）２０３ａ、デバイス１０４にインストールされたＢＴＳ ２０４ａ、およびクライアントデバイス１０５にインストールされたＢＴＳ ２０５ａによってクライアントの特定のサービス要求をデジタルブロードキャスティングするように構成されている。ブロードキャスト機能に加えて、クライアント１０３−１０５は各々、内蔵式の、または外部から利用できる、アドレス指定情報を記憶し、保存するように構成された少なくとも１つのアドレスキャッシュを有しており、特定された各アドレスタプルは、キャッシュされた情報に基づいて要求タイプをそのピアに送信可能にするのに適するように頑健である。デバイス１０３はアドレスキャッシュ２０３ｂを有し、デバイス１０４はアドレスキャッシュ２０４ｂを有し、デバイス１０５はアドレスキャッシュ２０５ｂを有している。

説明目的のため、キャッシュ２０３ｂ、２０４ｂおよび２０５ｂは１つまたは複数の他のピアまたは宛先に適切なアドレス指定情報を保存し、供給するように構成されている。各キャッシュ内のデータはある期間にわたる過去のピアツーピア要求動作に基づいて存在し得る。この実施形態では、全ての要求は、要求者のキャッシュ内に列挙されているアドレス指定に基づいて、ネットワークを介して他のピアにブロードキャストされる。これは本発明を限定するものではなく、これらの要求を受け入れる可能性がある潜在的なピアに要求を伝えるために、クライアントがどのようにブロードキャスト技術を利用するかの一例に過ぎない。

ＧＷ１０７はブロードキャスト機能によって増強されてもよく、最近使用されたアドレス、または過去に使用されたアドレスのキャッシュ（図示せず）をさらに含んでいてもよい。ＧＷ１０７はこの例に示されるように、本発明の趣旨と範囲から離れることなく、直接ルーティングのためにＰＳ１０８およびＲＳ１０９をさらに保持してもよい。

この実施形態では、Ｐ２Ｐディレクトリサーバは必要なく、または使用されない。好ましい実施形態では、各クライアント１０３−１０５は、潜在的なサービスエンドポイントに要求を伝えるためにブロードキャスト技術を使用する。ネットワーク１０２内のステーション１１０ａ−１１０ｎは、ブロードキャストされた要求を受信し、これに作用し、またはこれを「取り込む」ための機能で増強され、さらにブロードキャストソフトウエア（図示せず）で増強されてもよい。この例では、各ステーション１１０ａ−１１０ｎは、要求が受信されると参照されることがある１つまたは複数の配布された規則として定義されるポリシーおよびルーティング許可（ＰＲＰ）によっても増強される。この場合は、いずれかのステーションがそこにアドレス指定された要求を受信するとＰＲＰ規則が参照され、参照の結果、ステーションが要求を受け入れ、または「取り込む」か否かを決定し、その結果、取り込みステーションと送信クライアントとのある通信タイプが引き続き直接Ｐ２Ｐ接続される。

この例では、クライアント１０４が要求を開始し、ブロードキャストバースト２０１内の要求をアドレスキャッシュ２０４ｂ内にリストされたアドレスの一部または全部にブロードキャストする。典型的なＰ２Ｐディレクトリサービスとは異なり、中央ディレクトリは使用されず、または必要ない。要求は送信ノード、および要求の意図または一般目標を最小限特定する。要求は中央ルーティングシステムへの従来のルーティング要求よりも少ない情報を含んでいてもよい。例えば、クライアント１０４によってブロードキャストされる要求は、送信者が一連の文献のフランス語から英語への翻訳サービスを購入したいことを伝達できる。要求は理解しやすいようにゲートウェイおよびエンドステーションによって符号化されることができる。例えば、タイプ「５０」の要求は、特定の製品に関する顧客サービス要求などの特定のサービスに対する要求でもよい。タイプ４０の要求は、企業から提供される別の製品に関する顧客サービス要求でもよい。

要求はクライアント１０３、１０５、およびゲートウェイ１０７にブロードキャストされる。ゲートウェイ１０７は、独自のブロードキャストバースト２０２、および特定された元のアドレスの代わりに、または元のアドレスを補完するように独自のアドレスセットを使用して、ＣＰ２Ｐネットワーク１０２を介して要求をステーション１１０ａ−１１０ｎに再ブロードキャストしてもよい。同様に、ＧＷ１０７は簡単に、ＣＰ２Ｐネットワーク１０２内に存在することが知られている元の要求のアドレスだけを使用して、ＣＰ２Ｐネットワーク１０２に要求を再ブロードキャストしてもよい。ゲートウェイ１０７は、本発明の趣旨と範囲から離れることなく、必要なら直接ルーティングを行ってもよい。

この例では、要求はＧＷ１０７を経て、ブロードキャストバースト２０２を介して各ステーション１１０ａ−１１０ｎに送信される。このようなブロードキャスティングにはクライアント１０４からの幾つかの結果が生ずる可能性がある。可能性がある結果の１つは、ネットワーク１０１内のローカルクライアントの１つが先着順で要求を受け入れ、または「取り込む」ことである。この場合は、受け入れステーションは要求の性質を理解し、独自のポリシーおよびルーティング規則があればそれを参照した後、要求を満たすことができることを決定できる。この受け入れは発明者によって「取り込み（ｇｒａｂ）」と名付けられ、現行のネットワークを介してトランザクションを継続する目的で、クライアント１０４とクライアント１０５との間で直接Ｐ２Ｐ接続が確立される結果をもたらし得る。一実施形態では、各ステーションが要求の独自のバージョンを既に受信している１つを超えるエンドステーションが要求バーストに応答してもよい。応答は元のクライアントに返信されてもよく、このクライアントはこれらの「入札」のどれにクライアントが合意するかに関する決定を下してもよい。正確なシナリオは使用されるビジネスモデルに大きく左右される。

一実施形態では、ローカルクライアントは要求の目標を果たすことができないが、その要求を独自のアドレスキャッシュ内の１つまたは複数のアドレスにリダイレクトすることができ、またはリダイレクトしてもよい誰かを「知っている」ことがあり、または要求のコピーを含む同じ要求をインポートされたアドレスに後にバーストする際に使用するため、要求の発信者のキャッシュにインポートされ得る独自のキャッシュからの１つまたは複数のアドレスを含むメッセージで要求に応答してもよい。一実施形態では、どの受信者も、要求の元のブロードキャストに含まれていなかった要求をノードに再ブロードキャストできるようにされてもよい。この実施形態では、第２層のノードが要求を受け入れ、元の送信者への接続を構築してもよい。可能性がある別の結果は、要求の宛先が要求を満たすのに適していない場合は、要求の受け手が要求を単に無視することである。

この例では、ネットワーク１０２への全てのブロードキャストはＧＷ１０７を介して達成されるが、それはＧＷ１０７がこれらのネットワークをブリッジするように構成されているからである。一実施形態では、ＧＷ１０７はワイヤレスファイデリティ（ＷｉＦｉ）ルータでよい。ステーション１１０ａ−１１０ｎの１つが要求を取り込む場合は、ＧＷ１０７はクライアント１０４とステーションとの間の直接Ｐ２Ｐ接続をホストしてもよく、またはクライアントとステーションとの接続が電話または並列ネットワークによるなどの何らかの別の方法で構築されてもよい。一実施形態では、ＧＷ１０７はクライアント１０４から要求を受信し、この要求を再ブロードキャストする代わりに、ＰＳ１０８および／またはＲＳ１０９に諮った後、要求を満たすことができることが分かっているステーションの１つに要求を直接送ることもできよう。要求の直接ルーティングは本明細書では、例えばステーション１１０ａへの直接接続２０６で表わされ得る。

実際どのステーションが要求を取り込み得るかを判定する方法は、配布されるルーティング許可、およびクライアントベースでサービスする企業によって提供され得るその他のポリシー規則に全面的に左右される。例えば、企業が翻訳サービスを提供する場合は、企業は幾つかのステーションのうちのどれが文書をある言語から別の言語に翻訳する任務を担うかを事前に決定できる。単純なポリシーの配布の場合は、ステーション１１０ａが英語からフランス語への、またフランス語から英語への翻訳、すなわち「タイプ２０」の要求を実行するものでよい。ステーション１１０ｂには、ドイツ語からスペイン語への、またスペイン語からドイツ語への翻訳、すなわち「タイプ３０」の要求が課せられてもよい。ステーション１１０ｃ−１１０ｎにはステーション１１０ａまたは１１０ｂによってカバーされないその他の言語間の翻訳が課せられてもよい。タイプ「５０」の要求は「言語翻訳サービス」全般を示し、要求は英語からフランス語への、またはフランス語から英語へのタイプ５０（ａ）など、これらのサービスのうちのどれが必要であるかを指定できる。実際の実務では、要求はＧＷ１０７から翻訳サービスを提供する全てのノードにブロードキャストされることができる。その場合は、スキル定義が要求タイプと一致することを発見するノードが要求を「取り込み」、または受け入れ、この場合はＧＷ１０７を介して応答をクライアント１０４に返信できる。一実施形態では、実際の直接Ｐ２Ｐ接続はコールバックでもよく、またはクライアントを自動的に起動し、クライアントを、アドレスにナビゲートして、恐らくは自動化されたメディアサーバ内でホストされる翻訳サービスに従事させる直接リンクを用いた応答でもよい。

このＰ２Ｐ環境では、適切かつサポートされたプロトコルを使用して、ファイル転送プロトコル（ＦＴＰ）、ＶｏＩＰ、ビデオチャット、テキストチャット、ホワイトボード、ブラウザベースのフォローミー、および従来からピアツーピアネットワーキングによってサポートされている他の形態の通信またはファイル転送接続を含む直接接続が実行されてもよい。さらには、このような接続は、本発明の趣旨と範囲から離れることなく、プロキシサーバによってホストされてもよく、別個のネットワークを介して構築されてもよい。

図３は、本発明の実施形態によりトラフィック負荷を分散するために複数のエッジゲートウェイが備えられている、ピアツーピア通信ネットワーク３００のアーキテクチャ図である。ネットワーク３００はネットワーク１０１および１０２を含んでいる。この例では、同じクライアント構成、すなわちクライアント１０３−１０５があり、同様に上述の図１および２に関して記載のように、同じエンドステーション構成１１０（ａ−ｎ）がある。この例ではＰＳ１０８およびＲＳ１０９を含むＧＷ１０７があり、前述のものと全く同様に構成されている。

この例では、ブロードキャストされた要求を受信し、同様にＧＷ１０７でブロードキャストバーストを送信するように構成されてもよい追加の２つのＧＷ３０１および３０２がある。同様に、ＧＷ３０１および３０２にもＰＳ１０８およびＲＳ１０９の独自のバージョンがインストールされてもよい。上記の実施形態のこのバージョンでは、ＧＷ１０７、３０１および３０２は互いに諮って、しきい値として定義され、かつ関与する各ＧＷについて予め定められてもよい現在の負荷状態に基づいて、どのＧＷが要求を受け入れ、処理できるかを決定できる。同様に、大企業は、各ゲートウェイがスキル能力によって分類される専用のサービスノードを含むある特定のネットワーク区分またはセグメントをカバーする、プライベートＰ２Ｐネットワークへの複数の専用ゲートウェイを使用できよう。

クライアント１０５は、前述したのと同様に、本明細書で要求バースト３０４として示されている要求バーストをネットワーク１０１に送信してもよい。この場合は、両方のＧＷ３０１および３０２が元のバーストに含まれている。ＧＷ１０７はクライアント１０５からブロードキャストされた元の要求バースト内には含まれていない。この場合、各ＧＷは本発明を実施するように構成されたネットワーク１０１内の他のＧＷの知識を有している。同様に、各ＧＷは、所定のいずれかの時間での現在のトラフィック輻輳状態を反映する報告可能な「負荷状態」を有している。このような情報は関与する全てのＧＷによって共有される周期的に更新されるテーブル内に提供されてもよい。そうでない場合は、ＧＷは情報を共有するために互いに諮ってもよい。

バースト３０４に関しては、ＧＷ３０１が要求を受信するが、現在の要求を処理するにはビジー状態であることを内部で判断することがある。すなわち、現在のトラフィック輻輳または負荷状態が所定のしきい値にあるか、それを超えており、その時点ではどのような新たな要求をも取り込むことができないことがある。その場合は、ＧＷ３０１は要求を他のゲートウェイに送り（リダイレクト）、他のゲートウェイはその要求を受信すると、それ自体の負荷レベルをチェックするであろう。別の実施形態では、ＧＷ３０１はＧＷ１０７を含む他の全てのＧＷに諮り、元のバーストに受け手としてリストされていなかったＧＷ１０７が要求を処理する余地があるか否かを判定してもよい。一実施形態では、ＧＷ３０１はクライアント１０５に応答を返信して、同じ要求の次のブロードキャストバーストに含めるためのＧＷ１０７のアドレス情報をアドレスキャッシュに追加してもよい。次いでＧＷ１０７は次のバーストで要求を受信し、要求を取り込むことができる。別の実施形態では、他のＧＷと諮り、ＧＷ１０７が要求を処理する余地があるものと判定した後、ＧＷ３０１は要求を処理のためにＧＷ１０７に引き渡してもよい。

上記のどのシナリオでもＧＷ１０７は、ＰＳ１０８および／またはＲＳ１０９に諮った後、適切なエンドステーションまたはサービスノードに要求を直接送ることができる。代替として、ＧＷ１０７は、外部へネットワーク１０２を介してエンドステーション１１０ａ−１１０ｎへ本明細書にバースト３０５として示されている要求の独自のブロードキャストバーストを開始してもよい。元の要求の再ブロードキャストバーストの場合は、ステーション１１０ａは要求を受け入れてもよく、応答メッセージ３０６によって本明細書に示されているＧＷ１０７に応答してもよい。ＧＷ１０７は元の要求を有していることによって、本明細書に実線で示されている、エンドステーション１１０ａとＧＷ１０７との間、およびＧＷ１０７とクライアント１０５との間の双方向リンクによる、エンドステーション１１０ａとクライアント１０５との間の後のＰ２Ｐ接続をホストすることができる。要求が取り込まれ、認可されると、要求の性質に応じて同じネットワークを介して、または別の通信パスを介してＰ２Ｐ通信を行うことができる。例えば、ブロードキャスト要求メッセージはエンドステーションが電話で要求者をコールすることを指定してもよい。その場合は、取り込みには、元の要求で指定された連絡先番号に間もなく電話コールバックが行われるという応答メッセージが含まれてもよいであろう。

エンドステーション１１０ａ−ｎは、この例ではＧＰＬ３０７ａ−３０７ｄとして示されている取り込み優先度設定またはレベル（ＧＰＬ）テーブルで増強されてもよい。ＧＰＬ３０７ａはエンドステーション１１０ｎでインストールされ、ＧＰＬ３０７ｂはステーション１１０ｃでインストールされ、ＧＰＬ３０７ｃはステーション１１０ｂでインストールされ、ＧＰＬ３０７ｄはステーション１１０ａでインストールされる。ＧＰＬは資格がある各エンドステーションでの重み値として実装されてもよく、この値は例えば、ＧＰＬが分析し、許可ポリシーに適合するいずれかの特定の要求の取り込みにステーション１１０ａ−ｎが失敗するたびに増分または加算されてもよい。したがって、同様に、または同一に要求をサービスするように構成されたエンドステーションの場合は、より高い優先度レベルを有する要求は、要求の時点でＧＰＬの評価がより低い競合するノードを介して要求を取り込むことが認可される確率が高いであろう。このようにして、グループによって処理される要求を生ずる通信タスクはグループの中でより均等に分散される。ＧＰＬ方式は、競合するノードを介して次の要求をサービスするために、要求をサービスしてから最も時間が経過したステーションを使用可能にするようなある時間窓に基づくものでもよいであろう。

負荷の平衡をとるために、各ＧＷでも同様の優先方式を使用してもよいことが当業者には理解されよう。本明細書では、本発明の趣旨と範囲から離れることなく、ローカルネットワーク内で要求を受信するクライアントは同様に構成されてもよいことにも留意されたい。発明者は、論理的に説明する目的だけのために、論理上はクライアント１０３−１０５を要求ノードとして、またステーション１１０ ９ａ０ｎ）をサービスノードとして示している。実際の実践では、クライアントノードとサービスノードとはいずれかの物理的ネットワーク内のどこに配置されてもよい。本明細書の例では、ＧＷノードは、別個のネットワーク領域をブリッジするエッジルータまたはノードである。しかし、本発明を実施するためにはその必要は特にない。どのＧＷが同じネットワーク内に存在してもよく、クライアントをサービスステーションまたはサービスノードから単に分離するために使用してもよいためである。同様に、本明細書に示されているゲートウェイは別個の２つのワイアレスセルアイランド間のインフラストラクチャゲートウェイ、すなわちアイランド間のコンジットとして使用されるインターネットでよい。

本発明の一実施形態では、ゲートウェイは本発明を実施するために特に必要ではない。そのような場合は、全てのノード（クライアントノードおよびサービスノード）がローカルに同じアドホックのワイアレスネットワーク上に存在してもよく、全てのノードが同じネットワーク上で動作する他のノードを「見ても」よい。その例は、プロジェクトの全体的な成功のためにグループ内のこれらのノードのうちのある特定の１つどうしの協力が必要な、グループプロジェクト全体に関連する、異なっていて、かつ専用の責務を有する複数のノードであろう。この実施形態での要求は、グループ内のアーキテクチャ設計ノードによって得られる第三者建設サービスに関連するコストデータを探しているグループ内の経理ノードから発するものであり得る。全てのノードが要求を受信してもよいが、アーキテクチャノードは、要求タイプがそのプロファイルに適合することを認識し、データを経理ノードフォルダに入れることによって、またはその他の何らかの機構によってデータを提供するであろう。

図４は、本発明の実施形態によるピアツーピア通信アプリケーション４００の層とコンポーネントとを示すブロック図である。本発明の一実施形態では、本明細書に記載の実施形態による本発明を実施するために増強されるように、関与するどのノードも単一のソフトウエアまたはアプリケーション４００に適応させることができる。アプリケーション４００は異なるタイプのノードへの様々なバージョンで提供されてもよく、これらのノードは、含まれている本発明の趣旨と範囲から離れることなく機能の一部または全部を利用できる。同様に、アプリケーション４００は、いずれかの特定のバージョンで配布されるフィーチャがノードの機能を規定するため、異なるタイプのノードへの専用バージョンで配布されてもよい。

フルバージョンでは、アプリケーション４００は通信アプリケーションＡＰＩ層４０１を含んでいる。ＡＰＩ層４０１は、アプリケーションが本発明を実施できるようにする目的のため、ホストノードにインストールされ、ホストノードから実行可能な常駐通信アプリケーションに参加するように構成されている。ＡＰＩ層４０１は複数のＡＰＩ４０７（ａ−ｎ）を含んでいる。インターネットプロトコルテレフォニー（ＩＰＴ）ＡＰＩ４０７ａはＩＰＴ接続の要求を促進する。インスタントメッセージ（ＩＭ）ＡＰＩ４０７ｂはＩＭインタラクションの要求を促進する。さらに、この例に示されているＡＰＩはｅメールＡＰＩ４０７ｃ、携帯電話ＡＰＩ４０７ｄ、およびＦＴＰ ＡＰＩ４０７ｎを含んでいる。一実施形態では、クライアントはサービスノードへのブロードキャスト要求を生成するために、個々の通信アプリケーションを使用してもよい。さらに、最終的にはクライアントとサービスノードとの間に確立されるＰ２Ｐメディア通信を介してインタラクトするために望ましいタイプのメディアに応じてキャッシュされたアドレスが編成されてもよい。

アプリケーション４００はブロードキャストメッセージング層４０２を含んでいる。ブロードキャストメッセージング層４０２は要求を準備し、ネットワークを介して要求をブロードキャストするように構成されている。メッセージング層４０２はＡＰＩ層４０１と相互運用される。一実施形態では、層４０１からの生の（ｒａｗ）要求が層４０２によって受信され、次いでブロードキャスト用に準備されてもよい。層４０２は、要求の意図または目標を解析するように構成された要求コンテンツパーサ４０８を含んでいる。要求コンパイラ４０９が層４０２内に備えられ、現行のブロードキャストメッセージプロトコルに従って要求を編成し、コンパイルするように構成されている。アドレスモジュール４１０が層４０２内に備えられ、ブロードキャストメッセージの視聴者を規定するのに適切なアドレスを取り出すように構成されてもよい。層４０２は層４０２内に備えられてもよいブロードキャストスケジューラ４１１を含み、ブロードキャストバースト、または一連のブロードキャストバーストをスケジューリングするように構成されてもよい。要求がアプリケーション内で生成された場合、例えば受信ノードでの迅速な解析のために、その要求を要求タイプ５０などの特定の要求「タイプ」に変換する中間ステップはあってもよい。要求タイプのアーキテクチャは企業によって生成されてもよく、企業のクライアントが直接または間接的に利用できるようにされてもよい。

上記の「要求タイプ」アーキテクチャをさらに説明するため、企業はクライアントが要求タイプを選択し、要求とともにブロードキャストされる優先度およびプレゼンス情報を入力できるようにするため、ウエブサーバに指定の要求タイプを提供してもよい。この場合は、ウエブサーバまたはプロキシが実際のブロードキャスティングを行ってもよい。この機能はさらにクライアントステーションにダウンロードされてもよい。上記の例は、要求のブロードキャスティングに現在責務があるポータル、およびこれらのブロードキャストバースト用のアドレスの割り当てをクライアントが共用できる可能性を含んでいる。

アプリケーション４００は、１つまたは複数のアドレス帳、または本明細書でキャッシュ４１２（ａ−ｎ）と表記されているアドレスキャッシュにアクセスするように構成されたリソースアドレス層４０３を含んでいる。一実施形態では、要求の性質に応じて複数の別個のキャッシュがある。例えば、１つのキャッシュは、ごく最近に使用されたアドレスであるアドレスを含んでいてもよいであろう。別のキャッシュはＩＭまたはｅメールアドレスなどの特定のタイプのアドレスを含んでいてもよいであろう。さらに別のキャッシュは音声サービス端末、またはファイルまたはフォルダを共有するノードへのＩＰアドレスを含んでいてもよい。多くの可能性が存在する。特定のＰ２Ｐサービス企業は、提供される製品またはサービスを中心に展開するどのタイプのクライアント／サーバサービスのシナリオを準備してもよい。

本発明の一実施形態では、層４０１−４０３は、企業の潜在的なクライアントの誰でも利用できる専用のクライアントアプリケーションを備えている。この場合は、サービスノードへのアドレスのキャッシュがさらに備えられてもよいであろう。例えば、１つのキャッシュまたはグループ内に備えられた複数のアドレスは、企業の顧客サービスグループのアドレスでもよく、グループ内の誰でもがそのグループにブロードキャストされたどの顧客サービス要求をもサービスすることができる。別のキャッシュまたはアドレスグループは、そのグループ内のいずれか１つのノードがクライアントからの注文を処理するのに必要なスキルを有するようにする発注処理グループであってよい。

アプリケーション４００は、ブロードキャスト要求取り込みおよび処理層４０４を含んでいる。層４０４はブロードキャストされた要求を受信することを意図するどのノードに供給または配布されてもよい。層４０４は、ホストノードにアドレス指定された要求のブロードキャストチャネルをモニタするように構成されている接続層４１３を備えている。ホストノードがネットワークに接続されている間、アプリケーション４００はそれにアドレス指定されるどの要求をも聴いている。層４０４はこれに備えられたポリシー許可処理層（ＰＰＰＬ）ＡＰＩ４１４を有しており、ホストノードが許可、および要求されるスキルの基盤、および受信された特定の要求を満たすその他のリソースを有しているか否かを判定するために、ポリシー許可処理層４０５と通信するように構成されている。好ましい実施形態では、このような妥当性の確認は、要求をサービスすることが認可された後に遂行する目的で、要求が取り込まれ、Ｐ２Ｐ直接接続が確立される前に行われる。

層４０４は、図３に関して記載したテーブル３０７（ａ−ｄ）と類似したものでよいＧＰＬレジスタ４１５を含んでいてもよい。ＧＰＬレジスタは、競合するノードと比較して優先度があるいずれかの値に重みを加えるために増分されてもよい。この情報は、要求が受信された時点でより優先度が高いグループ内の別のノードを認識しているいずれかのノード自体が要求自体を取り込むのではなく、該別のノードが要求を取り込むことを可能にするように、要求を処理する過程で競合するノード間で共有されてもよい。このようにして、同じサービスまたは機能を実行するサービスノードのグループが要求の負荷をグループの中で均等に分散させてもよい。

ここで、ある実施形態では、異なるスキルレベルを提供するためにサービスノードが確保されてもよく、異なるタスク定義を有していてもよいことに留意されたい。この場合は、グループ全体にブロードキャストされたかもしれない特定のタイプの要求を処理できるノードグループ内のノードが１つしかないことがある。さらに別の可能性は、ノードグループはアドレスを共有するかもしれず、定義されたサービス機能、スキル、許可、およびその他の規則に適合する要求内容に従って、特定の要求が取り込まれることである。要求内容に適合しないプロファイルを有するノードは要求を取り込まない。さらに別の実施形態では、正確なサービスとの何らかの正確な適合ではなく、最も近い適合基準が用いられる。層４０４にはさらにプレゼンスリポータ４１６が備えられ、要求の時点でノードまたはノードのオペレータがどのプレゼンス状態にあるかを要求者に判断させるように構成されてもよい。この場合は、要求者がノードとのＰ２Ｐセッションを受け入れる前に、オンライン／オフライン、レディまたはアウェー、ビジーまたは非ビジー状態などの何らかのプレゼンス情報がリポートされてもよい。

上記にさらに説明された層４０５はスキルベース４１７、許可ベース４１８、状態リポートモジュール４１９、および１つまたは複数の企業規則４２０を含んでいる。スキルベース４１７はノードのオペレータがどのスキルを持っているかをチェックするためにアクセスを提供する。許可ベース４１８は操作および権限付与に関するポリシー許可を含んでいる。例えば、あるノードは、要求を満たすスキルを有し得る場合でも、ある送信者からのいずれかの要求を処理し、または取り込むことを禁止されることがある。状態モジュール４１９は単に、アプリケーションの実行、待ち行列の要求の数、予測待機時間、どのアプリケーションまたは待ち行列が起動されているか、などの現在状態をリポートする。

アプリケーション４００は、Ｐ２Ｐ直接接続層４０６を含んでいる。層４０６は、要求業務の目的で要求されたＰ２Ｐセッションを準備するか、または別の方法でクライアントとステーションとを互いに接続するように構成されている。一実施形態では、ルータまたはゲートウェイを全く必要とせずにＷｉＦｉネットワークなどの同じネットワーク上のローカルノード間で直接接続が確立されてもよい。別の実施形態では、２つ以上のネットワークセグメントを接続するメディアゲートウェイを介して接続が確立されてもよい。さらに別の実施形態では、プロキシサーバ、ルータ、またはテレフォニー交換機が、エンドポイント宛先ノードによって取り込まれたブロードキャスト要求から生ずるＰ２Ｐ通信をホストしてもよい。

ある実施形態では、接続層４０６は電話コールを確立するためのコールバックモジュール４２１のようなオプションのフィーチャを含んでいてもよい。オペレータの人員の補助なく即時的情報との接続をサービスするため、自動リスポンダ４２２が備えられてもよい。現在のトランザクションがノード上で行われている間に、１つを超える待機中の接続タスクを待ち行列するため、層４０６内で待ち行列モジュール４２３へのリングを利用してもよいであろう。一実施形態では、アプリケーション層４０４は、ノードオペレータに対して要求の発信元にコールバックまたはある通信事象の返信を開始することを通知する視覚的警報を提供する要求取り込み警報モジュール（図示せず）を含んでいてもよく、警報には連絡先電話番号、ｅメールアドレス、またはメディアタイプに応じたその他のアドレスが含まれる。前述のように、これらの通信アプリケーションに参加し、それに従って接続を開始するために前述のようにＡＰＩが備えられてもよい。多くの可能性が存在する。

図５は、本発明の実施形態による要求をゲートウェイユニットで受信し、処理するための動作を示す工程のフローチャート５００である。動作５０１で、ゲートウェイユニットは、そこにアドレス指定されたいずれかの要求についてブロードキャストチャネルまたはネットワークをモニタする。動作５０２で、ゲートウェイユニットはブロードキャストされた要求を受信する。

動作５０３で、ゲートウェイユニットは、それが要求を処理できるか否かを判定するためにポリシー規則をチェックする。この動作では、ゲートウェイは要求のタイプまたは意図を既に解析したものと想定されている。動作５０４で、ゲートウェイユニットはポリシー規則が要求の処理を許可するか否かを決定する。動作５０４で、ポリシーが特定の要求の処理を許可しない場合は、要求は無視され、工程は動作５０１に帰着してもよい。ゲートウェイが起動され、ネットワークへとログされている間、動作５０１は進展状態にある。

動作５０４で、要求タイプが現在のポリシーに適合する場合は、ゲートウェイは、要求をエンドステーションに送るための直接ルーティング戦略があるか否かを判定するため、利用できるルーティング規則を動作５０５でチェックする。動作５０６で、要求を処理するために利用できるルーティング戦略がないものと判定されると、要求は取り下げられ、別の入り要求をモニタするために工程は動作５０１に帰着する。しかし、動作５０６で直接ルーティング規則を利用できる場合は、ゲートウェイユニットは、動作５０７で要求を適切なエンドステーションに直接送ってもよく、ステーションは恐らくはルーティング方式で特定される。

この工程の１つの変形形態では、その要求のタイプ用に直接ルーティングの方式または規則を利用できない場合は、ゲートウェイユニットは、要求を受信するステーションの少なくとも１つがその要求を取り込むことが認可される場合には、要求をそのネットワーク内の複数のエンドステーションに再ブロードキャストしてもよい。さらに別の変形形態では、ゲートウェイユニットがポリシーをチェックし、要求を処理できないものと判定すると、ゲートウェイユニットは要求を１つまたは複数の追加のゲートウェイに再送し、そこで、１つのゲートウェイが要求を適切なターゲットまたはエッジユニットに送ることができるまで、受信するゲートウェイが要求を処理できるか否かの判定が各ゲートウェイに関して繰り返される。要求を受信する追加のゲートウェイのそれぞれの場合、直接ルーティング方式の代わりに要求を潜在的なターゲットに再ブロードキャストするというオプションは依然として存在する。

図６は、本発明の一実施形態による、受信された要求をゲートウェイで処理するための動作を示す工程のフローチャート６００である。動作６０１で、ゲートウェイは、そこにアドレス指定されたいずれかの要求へのブロードキャストネットワークまたはチャネルをモニタする。動作６０２で、ゲートウェイはクライアントからの要求を受信する。動作６０３で、ゲートウェイは、それが要求を処理する余地があるか否かを判定するためにゲートウェイを通るトラフィック負荷をチェックする。動作６０４で、トラフィック負荷がその特定のゲートウェイについてプリセットされた限度を超える場合は、そのゲートウェイは動作６０５で要求を他のゲートウェイに送る。工程はそのゲートウェイで循環し、動作６０４に戻る。どのゲートウェイも要求を処理できない場合は、要求は取り下げられてもよい。

動作６０４で、要求を受信した時点でゲートウェイがプリセットされた負荷のしきい値未満にある場合は、動作６０６でそのゲートウェイは要求を適切なエンドステーションに再ブロードキャストしてもよく、または、ルーティングを利用できる場合は、代替として要求をエッジユニットに直接送ってもよい。再ブロードキャストの場合は、動作６０７でエンドステーションは、ゲートウェイからそこにアドレス指定された要求を受信する。動作６０８で、受信ステーションは、受信された要求のタイプのスキルおよびサービスの定義を含む独自のポリシーまたは許可とのプロファイルの適合性があるか否かを判定または確認する。動作６０８で適合性がない場合は、工程は動作６０９での要求の無視で終了してもよい。

動作６０８で、受信ユニットのプロファイルが要求のタイプと適合する場合は、動作６１０で、ステーションは元の送信者に要求をサービスできる旨の応答を送信して要求を取り込んでもよい。一実施形態では、それ以上の認可を必要としない自動的な取り込みがあってもよい。別の実施形態では、ノードが要求を実際にサービスする前に、１つを超えるサービスノードの中で準備された何らかの優先方式がノード間で確実に緩和されるように待機時間窓があってもよい。動作６１１で、ステップ６１０で要求を受け入れたエンドステーションは、要求の優先度があればそれに基づき、かつ確立された通信プロトコルに基づいて要求の発信元に関わってもよい。動作６１１は、本発明の趣旨と範囲から離れることなく、多くのタイプの通信接続の１つを含んでいてもよい。例えば、取り込みはエンドステーションの電話番号または待ち行列への事象を介したリング、すなわち要求者によってなされたコールから生ずる元の要求を伴っていてもよい。他の例においては、取り込みはゲートウェイを介してピア間の直接的なファイル共有接続の開始を伴っていてもよい。さらに別の例では、取り込みはエンドステーションから発信元の電話番号へのコールバックを伴っていてもよい。利用できる接続および通信方法によってのみ範囲が限定される多くの可能性が存在する。

本発明の方法および装置は、ワイアレス、およびルータまたはゲートウェイによってブリッジされる有線デジタルネットワークおよびセグメントを含むブロードキャスト技術および双方向のデータフローをサポートするどのタイプのデータネットワークを介して実施されてもよい。クライアントは、本発明の趣旨と範囲から離れることなく、多様な方法で要求を発信してもよい。クライアントは要求をブロードキャストしてもよく、または本発明の趣旨と範囲から離れることなく、要求をブロードキャストするために中間ノードを利用してもよい。要求の取り込みの結果生ずる実際の接続は、本発明の趣旨と範囲から離れることなく、同じネットワークを介して、または並列ネットワークを介して行われてもよい。一例では、連携して共通に使用されるアプリケーションに内で機能するクライアントは、そのアプリケーションでのニーズを定義してもよく、この定義の結果、そのニーズを満たす要求が生ずる。例えば、表計算で作業する会計士は、ホストノードには即座に利用できない何らかのデータが必要であり、そのノードの外部のソースから供給されなければならないことを発見することがある。ユーザは要求タイプ、例えば「データ要求」、および「製品Ａ／２００５の売り上げ合計」としてニーズを定義してもよい。ブロードキャスト要求は、必要なデータ、またはデータを含むリポートを現在保存している別のノードにプロファイルを適合させてもよい。次いでそのノードが要求を取り込み、接続を構築し、必要なデータを転送してもよい。

顧客サービス、セールス、連携、データの同期化などで、本発明の方法および装置を使用できるビジネスモデルには多くの変形形態がある。本発明の方法および装置には、調査を受ける、可能な最も広い範囲が与えられよう。本発明の趣旨と範囲は本明細書で、添付の請求項以外によって限定されるものではない。

発明者に知られている典型的なピアツーピア通信ネットワークのアーキテクチャ概略図である。 本発明の実施形態により接続が確立される、ピアツーピア通信ネットワークのアーキテクチャ図である。 本発明の実施形態により複数のエッジゲートウェイが参照される、ピアツーピア通信ネットワークのアーキテクチャ図である。 本発明の実施形態による、ピアツーピア通信アプリケーションの層およびコンポーネントを示すブロック図である。 本発明の実施形態によるルーティングと組み合わせたピアツーピアブロードキャスティングを示す工程のフローチャートである。 本発明の一実施形態による受信された要求を処理する動作を示す工程のフローチャートである。

Claims (25)

1. ダイナミックエンドノード応答機能を有するブロードキャストルーティングシステムであって、
   ブロードキャスト要求を生成するための第１のノードと、
   要求をブロードキャストするため第１のノード上で動作する、または第１のノードにとって利用可能なブロードキャストアプリケーションと、
   ブロードキャストチャネルをモニタし、要求を受信できるようにされた１つまたは複数の宛先ノードと、
   １つを超える宛先ノードが存在する場合は、どの宛先ノードが要求をサービスできるかを判定するため、１つまたは複数の各宛先ノード上で動作する、または１つまたは複数の各宛先ノードにとって利用可能なソフトウエアルーチンとを備える、ブロードキャストルーティングシステム。
2. 第１のノードが、デスクトップコンピュータ、ラップトップコンピュータ、携帯電話、音楽プレーヤ、携帯情報端末、またはハンドヘルドコンピューティングデバイスの１つである、請求項１に記載のブロードキャストルーティングシステム。
3. ブロードキャストアプリケーションが、ネットワークアクセスを介して第１のノードにとって利用可能なサーバノード上で動作する、請求項１に記載のブロードキャストルーティングシステム。
4. ネットワークがインターネットネットワークである、請求項３に記載のブロードキャストルーティングシステム。
5. 要求が、アドレスと、コンタクト情報と、要求のタイプとを備える送信者身元認証を含む、請求項１に記載のブロードキャストルーティングシステム。
6. 要求のタイプがコードまたは番号に相当する、請求項５に記載のブロードキャストルーティングシステム。
7. 宛先ノードが、コンピュータ、ラップトップ、携帯電話、携帯情報端末、またはインターネットプロトコル電話の１つまたはそれらの組み合わせである、請求項１に記載のブロードキャストルーティングシステム。
8. ソフトウエアルーチンがデータパケットネットワークを経て宛先ノードにアクセス可能なルータ上で利用可能である、請求項１に記載のブロードキャストルーティングシステム。
9. 受信された要求の直接ルーティング、または受信された要求の再ブロードキャストが可能な中間宛先ノードとして構成された１つまたは複数のネットワークゲートウェイをさらに備える、請求項１に記載のブロードキャストルーティングシステム。
10. １つを超えるゲートウェイの場合は、各ゲートウェイ用に事前に割り当てられたトラフィック負荷の閾値を用いて負荷の平衡化が行われる、請求項９に記載のブロードキャストルーティングシステム。
11. 第１のノードと１つまたは複数の宛先ノードとが要求をブロードキャストでき、ブロードキャストされた要求を受信できる、請求項１に記載のブロードキャストルーティングシステム。
12. コンピューティングノードが要求をブロードキャストし、これらの要求への応答を受信できるようにされたソフトウエアユーティリティであって、
    メッセージの準備および分類用モジュールと、
    アドレスタギングおよび送信スケジューリング用モジュールと、
    受信ノードからの応答を受信するためのモジュールとを備える、ソフトウエアユーティリティ。
13. コンピューティングノードがブロードキャストされた要求を受信し、受信された要求をサービスするかサービスしないかを決定できるようにされたソフトウエアユーティリティであって、
    ブロードキャスティングネットワークチャネルをモニタするためのモジュールと、
    ブロードキャストメッセージを受信し、解析するためのモジュールと、
    受信された要求がノードによってサービスされてもよいか否かを決定するためのモジュールとを備える、ソフトウエアユーティリティ。
14. コンピューティングノードが企業の顧客によって操作されるノードである、請求項１２に記載のソフトウエアユーティリティ。
15. コンピューティングノードが企業の社員または従業員によって操作されるノードである、請求項１３に記載のソフトウエアユーティリティ。
16. サービスの位置を特定し、データパケットネットワークを経てサービスとのサービス接続を確立するための方法であって、
    （ａ）サービス接続を確立して要求のサービス要件の遂行を開始するための命令を含む要求のタイプをフォーマットする動作と、
    （ｂ）１つまたは複数のエンドノートが要求をサービスすることができる該エンドノードにアドレス指定された、フォーマットされた要求をネットワーク上の開始ノードからブロードキャストする動作と、
    （ｃ）要求を受信するようにアドレス指定されたエンドノードでブロードキャストされた要求を受信し、タイプと意図とに関して要求を解析する動作と、
    （ｄ）受信された要求のタイプと意図とを各受信ノードに保存されたサービスプロファイル情報と比較する動作と、
    （ｅ）要求のサービス要件とサービスプロファイルとの適合がいずれかの受信ノードで発見されると、サービス要求を受け入れる動作と、
    （ｆ）いずれかの受け入れノードについて要求の受け入れが承認されると、開始ノードまたは関連する実装と、受け入れノードまたは関連する実装とのサービス接続を確立する動作とを含む、方法。
17. 動作（ａ）で、タイプの要求がタイプのリストから選択され、要求をサービスするために必要な情報を追加することによって完了される、請求項１６に記載の方法。
18. 動作（ｂ）で、開始ノードがデスクトップコンピュータ、ラップトップコンピュータ、携帯情報端末、インターネットプロトコル電話、ネットワーク対応音楽プレーヤ、または携帯電話の１つである、請求項１６に記載の方法。
19. 動作（ｂ）で、開始ノードがネットワーク上でホストされるサーバノードである、請求項１６に記載の方法。
20. 動作（ｂ）で、ブロードキャスティングが反復ブロードキャストバースト用にスケジューリングされる、請求項１６に記載の方法。
21. 動作（ｅ）で、適合が発見されない場合は、要求を無視し、または次のブロードキャストに追加するための参照アドレス情報を有するか、または有さないサービス不能メッセージで応答する、請求項１６に記載の方法。
22. 動作（ｆ）で、開始ノードで受け入れの承認が決定される、請求項１６に記載の方法。
23. 動作（ｆ）で、ナンバリングが１を超える場合は要求を受け入れるエンドノードの中で受け入れ承認が緩和される、請求項１６に記載の方法。
24. 動作（ｆ）で、受け入れノードの承認が第三者ノードによって行われる、請求項１６に記載の方法。
25. 第三者ノードがゲートウェイノードである、請求項２４に記載の方法。

Images