JP2008545355A - ネットワークにおける通信セッションを管理するシステム及び方法 - Google Patents

Abstract

１つの実施形態では、通信セッションを管理するためのシステムが提供される。本システムの実施形態は、着呼を受信するパケットネットワークに対するコネクションを含む。ステートフル層は、少なくとも１つの着呼に対して確立される通信セッションを管理する。１つ又はそれ以上のアプリケーションを含むステートレス層は、ステートフル層内の通信セッションに対するサービスを提供する。１つ又はそれ以上のサーバは、ステートフル層内で着呼に対して確立される通信セッションに対応する資源の割り当て及び／又は管理を行う。
【選択図】図１

Description

（優先権の主張）
２００５年６月３０日に出願された（代理人整理番号ＢＥＡＳ−０１７４４ＵＳ０）、Ｒｅｔｏ Ｋｒａｍｅｒ他による名称「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＭＡＮＡＧＩＮＧ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＳＥＳＳＩＯＮＳ ＩＮ Ａ ＮＥＴＷＯＲＫ」の米国仮出願６０／６９５，３２１号、及び２００６年３月１７日に出願された（弁理士事件番号ＢＥＡＳ−０１７４４ＵＳ１）、Ｒｅｔｏ Ｋｒａｍｅｒ他による名称「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＭＡＮＡＧＩＮＧ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＳＥＳＳＩＯＮＳ ＩＮ Ａ ＮＥＴＷＯＲＫ」の米国特許出願番号１１／３７８，１８８号。

（著作権の表示）
本特許文書の開示の一部は、著作権保護の適用対象となる内容を含む。著作権者は、特許商標庁の特許ファイル又はレコード内に表されるような特許文献又は特許開示物を正確にコピーすることについて異議を有さないが、それ以外は全ての著作権を留保する。

（技術分野）
本発明は、一般に、電気通信に関し、より詳細には、ネットワークにおける通信セッションを管理するための機構に関する。

従来、通信及びネットワーク・インフラストラクチャ・プロバイダは、ネットワークトラフィックに対するルーティングを行うために、多くの場合数１０年もの間旧来の交換技術に依存してきた。しかしながら、ビジネス及び消費者が、音声、データ及びビデオの統合された新規のサービスを求めていることによって産業上の転換が促進されている。このような要望を適える能力は、多くの場合、これらの次世代サービスをサポートするには閉鎖的、独占的、且つ余りに柔軟性に欠けた既存のＩＴ及びネットワーク・インフラストラクチャにより制限される可能性が高い。その結果、通信事業者は、ある電話機を別の電話機に接続するために世界中で使用されている伝統的な回線交換式公衆交換電話網（ＰＳＴＮ）である共通線電話システムから、ＩＰを介した音声プロトコル（ＶｏＩＰ）ネットワークに移行しつつある。ＶｏＩＰ技術は、公衆インターネットなどの「バニラ」ＩＰネットワークを介して音声通信を可能にする。更に、音声収益が着実に減少していることにより、これらのより高度なデータサービスの供給を通じてデータ／サービス収益の成長及び変動の低減を求めてキャリアが競い合うような、競争圧力を高める結果となった。強化された政府規制、セキュリティ、及びプライバシ問題、並びに新たに出現する規格により圧力の度合いが更に高くなる可能性がある。

しかしながら、これらのより高度なデータサービスを提供することは、当初想像していた以上に困難であることが明らかになった。既存のＩＴ及びネットワーク・インフラストラクチャ、閉鎖的な専用のネットワークベースの交換構造及び同様のものは、新しいサービスの提供の創成及び展開を可能にするには複雑過ぎて柔軟性に欠けることが分かってきた。１つの解決策として、サービス提供プラットフォーム（ＳＤＰ）、すなわち基礎を成すネットワークの複雑性からサービス開発者を切り離すことを意図したサービス開発プラットフォームが提案されている。このようなサービス提供プラットフォームは、こうしたサービスの開発プラットフォームを可能にする課題に取り組んでいるが、ユーザを満足させるのに充分な速度及び性能を有しながら、ネットワーク環境においてデータ、音声及び他のマルチメディアアプリケーションを供給する統合した解決策を提供することはできない場合が多い。

ネットワーク上でデータ、音声及び他のマルティメディアを供給可能なサービスに対する技術を改善することが求められている。

本発明は、同じ参照符号が同様の要素を示す添付図面の各図において限定ではなく例証として示される。本開示における実施形態への言及は、必ずしも同一の実施形態に対する言及ではなく、少なくとも１つを意味する。特定の実施について説明しているが、これは例証の目的で行われる点を理解されたい。当業者であれば、本発明の範囲及び精神を逸脱することなく他の構成要素及び構成を使用できることを認識するであろう。

以下の説明において、本発明の完全な説明を与えるために、多くの具体的な詳細が記載されている。しかしながら、本発明がこれらの具体的な詳細がなくとも実施することができる点は当業者には明らかであろう。場合によっては、公知の特徴は、本発明を曖昧にするのを避けるために詳細には説明していない。

図表は、構成要素を論理的に区別して表しているが、このような表現は単に説明のためのものに過ぎない。描かれた構成要素を組み合わせ、又は別個のソフトウェア、ファームウェア及び／又はハードウェア構成要素に分割することができる点は、当業者には理解することができるであろう。例えば、本明細書で説明される実施形態の１つ又はそれ以上は、ルータなどのネットワークアクセス装置／機器に実装することができる。更に、こうした構成要素は、どのように組み合わされ又は分割されるかに関係なく、同一のコンピュータ装置上で実行することができ、或いは１つ又はそれ以上のネットワーク又は他の適切な通信手段によって接続された異なるコンピュータ装置間に分散することができる点も明らかであろう。

実施形態に従って、ネットワーク内の通信セッションを管理するための機構及び方法が提供される。これらの機構及び方法は、実施形態が、ステートフル層を使用して通信セッションを管理し、ステートレス層を使用して通信セッションに関連したアプリケーションを管理することを可能にすることができる。ステートフル層及びステートレス層において通信セッション及び通信セッションに関連したアプリケーションの独立した管理を可能にする実施形態の能力により、該実施形態が可用性、スケーラビリティ及び信頼性を改善することが可能になる。

１つの実施形態では、通信セッションを管理するためのシステムが提供される。本システムの実施形態は、着呼を受信するパケットネットワークへの接続を含む。ステートフル層は、少なくとも１つの着呼に対して確立された通信セッションを管理する。１つ又はそれ以上のアプリケーションを含むステートレス層は、ステートフル層内の通信セッションにサービスを提供する。１つ又はそれ以上のサーバは、ステートフル層において着呼に対して確立された通信セッションに対応する資源の割り当て及び／又は管理を行う。サーバは、ステートフル層の通信セッションに対するサービスを提供するためステートレス層内のアプリケーションを維持する。

図１は、ネットワーク内の通信セッションを管理するための技術を具現化することができるシステムの機能的ブロック図である。例証として図１を参照すると、ネットワークシステム１は、完全統合ハイパーテキスト転送プロトコル（ＨＴＴＰ）、Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ（商標）Ｂｅａｎ（ＥＪＢ）、Ｓｅｒｖｌｅｔ及びネットワーク・セッション開始プロトコル（ＳＩＰ）コンテナを表すサービス提供プラットフォーム１００を含む。（Ｊａｖａ（商標）は、サンマイクロシステムズ社の商標である）サービス提供プラットフォームは、サービスプロバイダ１１４、エンドユーザ１１６、及びサードパーティサービスプロバイダ１１８間で使い勝手の良い統合された構成重視の介在物を提供し、これは、効率的且つ高い可用性、スケーラビリティ及び信頼性を有する以下のもの（限定ではないが）を達成する。
・新しい有線、無線及びケーブルサービスの迅速な創成及び／又は展開を促進するためのキャリアグレードのモバイル対応及びネットワーク対応プラットフォームを提供する。
・サービス論理を迅速且つ容易に構築し、プロセスにおける再利用を最大にし、グラフィカルで使い勝手の良い設計環境をもたらす能力を提供する。
・アプリケーションの旧バージョンのユーザを妨げることなく、提供中のサービスを更新する能力を提供する。

サービスプロバイダ１１４は、限定ではなく例証として、ネットワーク接続性、シンプル・メッセージング・サービス（ＳＭＳ）、マルチメディア・メッセージング・サービス（ＮＭＳ）、電子メール、Ｌｏｃａｔｉｏｎ Ｆｉｎｄｅｒ及び他のサービスなどのサービスを提供する。サードパーティサービスプロバイダ１１８は、限定ではなく例証として、着信音、ゲーム及び音楽、ニュース、天気、スポーツ並びに他のサービスなどのサービスを提供する。エンドユーザ１１６は、限定ではなく例証として、呼出、メッセージング、位置ベースのサービス、インターネット、娯楽、電子商取引、及びその他などのサービスを含むような、エンドユーザが利用可能なＩＴサービスを閲覧することになる。

図２は、１つの実施形態における例示的なサービス開発プラットフォームの機能ブロック図である。例証として図２に示されるように、サービス提供プラットフォーム１００の１つの実施形態は、サードパーティ・アクセス・レイヤ２００、サービスコンテナレイヤ２１０及びネットワークレイヤ２２０を含む。サードパーティ・アクセス・レイヤ２００は、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）、ＨＴＴＰ又は他のプロトコルを使用してプログラムへのアクセスを行うプログラム・インタフェース２０２を含む。デバイスインタフェース２０４は、様々なデバイス固有のプロトコルのいずれかを使用してデバイスへのアクセスを可能にする。

サービスコンテナレイヤ２１０は、ＪＳＲ１１６で定義されたＳＩＰサーブレット・コンテナ２１３とマージされた集中型Ｊａｖａ２ Ｅｘｅｃｕｔｉｖｅ Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）コンテナ２１４を備える通信用サービスプラットフォームを含む。ＳＩＰサーブレットは、ＳＩＰサーブレット・コンテナによって管理され、且つＳＩＰシグナリングを実行するＪａｖａベースのアプリケーション構成要素である。通信用サービスプラットフォーム２１６はまた、Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ Ｂｅａｎコンテナ２１１及びＨＴＴＰプロトコル２１２を含む。通信用サービスプラットフォーム２１６は、通信業界におけるアプリケーション統合の傾向を活用する。運用者は、通信用サービスプラットフォーム２１６を使用して、ＳＩＰプロトコル及びＳＩＰサーブレット・プログラミングモデルを利用するアプリケーションを構築することになる。通信用サービスプラットフォーム２１６は、基礎を成すネットワークが主にＳＩＰであり、ＳＩＰサーブレットがプログラミングモデルとして適当である状況での使用を意図している。
ポリシーエンジン２１５は、ネットワークインタフェースに対するポリシーの定義及び実施のためのネットワークにおける単一の論理ポイントである。ポリシーは、極めて一般的に作成することができ、プロトコル及びプログラミングモデルと独立している。ポリシーエンジン２１５は、例えば、顧客Ａが１時間に何通のメッセージを送信するかをモニタし、契約制限を超えた場合には、顧客Ａがそれ以上の支払いを始めるか、又は止めるかといった、サービスレベルの同意（ＳＬＡ）の実施を規定する。別の実施例では、ポリシーエンジン２１５は、支払額／予定、優先度及び同様のものに従ってトラフィックを優先順位付けすることができる。ポリシーエンジンが存在することにより、ネットワークの所有者が内部ＩＴ及びサードパーティ開発者両者へのアクセスのためのネットワークを開設するのにより好適になり、これによってより迅速な統合が可能となる。

ネットワークレイヤ２２０は、サードパーティ・アクセス・レイヤ２００及びポリシーエンジン２１５を介したサービスコンテナレイヤ２１０とのインタフェースを提供するＰａｒｌａｙ（プロトコル）ゲートウェイ２２２と、ＪＡＩＮ Ｓｅｒｖｉｃｅ Ｌｏｇｉｃ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ （ＪＡＩＮ ＳＬＥＥ）コンテナ２２７とを含む。ＪＡＩＮ ＳＬＥＥコンテナ２２７は、ＪＳＲ３２仕様を実装する。ＪＡＩＮ ＳＬＥＥ２２７は、非同期のイベントベースのアプリケーションを開発するための包括的プログラミングモデルを備え、特に通信アプリケーションに適している。ネットワークレイヤ２２０は、従来のクラス４又はクラス５スイッチに代わる後継ネットワーク素子、並びにソフトスイッチ及びＩＭＳ２２３、ＳＭＳＣ（ショート・メッセージ・サービス・センター）２２４及びＭＭＳＣ（マルチメディア・メッセージング・サービス・センター）２２５などのネットワークの最先端の「垂直アプリケーション」の開発を可能にする。

図３は、ネットワーク内の通信セッションを管理する技術を具現化することができるサービスコンテナの例示的な論理的アーキテクチャーの機能的ブロック図である。例証として図３のサービスコンテナ３００で示されるように、新しいシステムアーキテクチャは、状態を保持しないノードで実行されるサービスなどを実装したビジネス論理、及び状態を保持するノードで実行される通信接続管理論理の独立し協調した実行を実現する。ステートレス層３０２は、ステート層３０４中のストライプと関連したノードを含む。本明細書で使用される用語「ノード」は、ＳＩＰサーブレットＡＰＩ（ＪＳＲ１１６）上に構築されるＳＩＰアプリケーションを指す。ステートレス層３０４は、アプリケーションの開発及び実行をサポートするコンピュータ資源を備える。１つの実施形態では、ステートレス層３０２は、２８個のＣＰＵの中に２ギガバイトのブロックを割り当てた５６ギガバイトのメモリを含むことができる。

ステート層３０４は、状態が保持されている処理を実行するためのコンピュータ資源を備える。ステート層３０４は、「インメモリデータベース」を形成し、ここでは状態情報は、ディスク記憶装置上には記憶されない。１つの実施形態では、ステート層３０４は、主記憶領域とバックアップ記憶領域とに分割される。実施形態によっては、１つよりも多いバックアップ領域を設けることもある。１つの実施形態では、ステート層３０４は、４０個のＣＰＵの中に２ギガバイトのブロックを割り当てた８０ギガバイトのメモリを含むことができる。
１つの実施形態では、ステート層３０４は、ストライピング及び複製に共通パターンを使用して、複製法で状態情報を記憶する。本明細書で使用される「ストライピング」とは、例えば１０００未満の呼識別子が第１のストライプに割り当てられるなど、所与の呼識別子（コールｉｄ）に単一のストライプのみを割り当てることを意味する。割り当てられたストライプは、呼を追跡することだけを担う。１つの実施形態では、２つのプロセスが各ストライプをバックアップする。ストライププロセスは、これらのプロセスが高い信頼性を実現するために、電源を共用しない、又は単一のネットワークルータ故障に対して脆弱であるように分散することができる。構成制御プロセスは、ストライプをバックアップするプロセスが配置される場所を特定する。

１つの実施形態では、約２０のストライプが、４０の機械に割り当てられる。企業間ユーザエージェント（Ｂ２ＢＵＡ）は、ストライプ機構が隠蔽されるのでストライプを明示的に使用しない。

１つの実施形態では、ＳＩＰサーブレットは、ＳＩＰサーブレットのセッション状態に対して記述される。ＳＩＰサーブレットのセッション状態は、例えば、状態がストライプから読み出された後に制御がＳＩＰサーブレットに引き渡されるなど、呼識別子によって識別されたストライプから供される。ＳＩＰサーブレットが戻された後、変更された状態は、サーブレットの実行によって示されたメッセージの送信前にストライプに書き出される。

１つの実施形態では、ステート層３０４は、タイマを最適化するためにプロトコル状態と共にタイマを記憶する。１つの実施形態では、ステートレス層３０２及びステート層３０４は、新規のプロトコルを使用して同期させることができる。

図４は、１つの実施形態におけるサービスコンテナ内の着呼を処理する実施例の機能的ブロック図である。例証として図４で示されるように、ＳＩＰ開始ユーザエージェント４０２は、典型的な利用状況で顧客のＳＩＰ又はＨＴＴＰアプリケーション４０４にダイアルすることによってＳＩＰ終了ユーザエージェントに対する呼を開始する。顧客のＳＩＰ又はＨＴＴＰアプリケーション４０４は、ステート層３０２中に常駐する。ＳＩＰ Ｓｅｒｖｌｅｔ ＡＰＩ２１３は、「ダイアル」フェーズ中の通信呼に関与するようになる。

多くの機能では、呼が終了するまで何らかがループ内に残ることが必要とされるので、ステート層３０４は、呼についての情報を記憶している。例えば、通話中着信は、音声回線を中断する機能を必要とし、従って、プロセスは、再度音声回線を取り出す方法を認知する必要がある。更に、この情報は、メモリ中のユーザプロファイルと関連付けられる必要がある。通話中着信機能は、呼が持続している間メモリを消費する。例えば、通話中転送などの他の機能は、システムに同様の要件を引き起こす。これらの機能は、バックトゥバック・ユーザエージェント（Ｂ２ＢＵＡ）と呼ばれる。１つの実施形態では、Ｂ２ＢＵＡは、最初の送信者からの呼の受信者として、及び次の宛先又は最終宛先に向かう呼の送信者として動作する「中間者」として動作する。Ｂ２ＢＵＡは、発信元の送信者が関与している限り、呼を終端させて、発信元の送信者を妨げることなく、通話中転送などを行うことができる。

ＳＩＰサーブレット２１３は、ＳＩＰサーブレット・コンテナ中に組み込むことができる。１つの実施形態では、ＳＩＰサーブレット・コンテナは、カリフォルニア州サンノゼ所在のＢＥＡ ｓｙｓｔｅｍｓ製ＷｅｂＬｏｇｉｃ（登録商標）サーバなどのアプリケーションサーバ製品に組み込まれる。

新規のプロトコルは、図４に表された「ｒｅａｌ＿ｌｏｃｋ」及び「ｗｒｉｔｅ＿ｕｎｌｏｃｋ」矢印で示されるように、ステートレス層３０２中で実行されるアプリケーションによってステート層３０４内のロック及びアンロック情報を調整するために用いられる。

図５は、１つの実施形態におけるネットワーク内の通信セッションを管理するための技術の概要を示す動作フロー図である。図５に示されるネットワーク内の通信セッションを管理するための技術は、例えば、図２のサービスコンテナ２０２などのサービスコンテナと共に動作可能である。図５に示すように、ブロック（５０２）において、少なくとも１つの通信セッションを開始するためのリクエストが送信者から受信される。ブロック（５０４）において、少なくとも１つの通信セッションを管理するための資源がステートフル層内で割り当てられ、アプリケーション処理は、ステートレス層内の通信セッションと関連付けられる。ブロック（５０６）において、少なくとも１つの通信セッションは、ステートフル層を使用して管理され、少なくとも１つの通信セッションと関連したアプリケーションは、ステートレス層を使用して管理される。

コンピュータ技術の当業者には明らかなように、様々な実施形態は、本開示の教示に従ってプログラムされた汎用又は特定用途のデジタルコンピュータ及び／又はプロセッサを使用して実施することができる。ソフトウェア技術の当業者には明らかなように、適切なソフトウェアコーディングは、本開示の教示に基づいて熟練プログラマーによって容易に作成することができる。本発明はまた、当業者には容易に明らかなように、集積回路の作成によって、及び／又は従来の要素回路の適切なネットワークを相互接続することにより実装することができる。

実施形態は、限定ではなく例証として、以下の機能を限定ではなく含む、ＶｏＩＰサービスなどのサービスを提供することができる。
基本機能。これらは、音声メール、発信者番号通知、着信通知、及び着信転送（異なる番号に呼を転送する能力)などの標準サービスを含む。
拡張機能。拡張機能のリストは、オペレータ仕様である。以下は、拡張機能の概略的なリストである。

・通話履歴： 所与のオンライン時間期間になされた呼を閲覧する能力、電話番号に名称を関連付ける能力、ＩＭなどの他のアプリケーションに対する統合通信履歴情報。

・着信拒否：例えば、自動的に移動体端末へ転送される営業時間中の全ての呼、音声メールに向けられた夜間の全ての呼、その他の着呼についてのポリシーを指定する能力。

・ロケートミー：これは拡張着信転送である。呼出先がビジーの場合に単一の場所(例えば、音声メール)に全ての呼を転送するのではなく、ロケートミーは、順次又は並行して複数の端末を試みることができる。例えば、ユーザは、２つの事務所所在地、携帯電話、及びページャを保有する場合があり、最初に両方の事務所、次にページャ、次いで移動体端末に呼を転送することに意味がある場合がある。ロケートミーは、機能相互作用の別な実施例である。

・パーソナル会議：ユーザは、既存のアプリケーション（例えば、ＩＭクライアント）を使用して、ウェブ／音声会議を特定の時間に開始するように予定することができる。ＩＭクライアントは、既に個人プロファイル情報を有しているので、会議システムは、参加者に対してＩＭ及び／又は電子メールのいずれかを通じてウェブ会議のリンク情報を送出する。プロファイル中の電話連絡情報は、会議の時間に参加者を自動的に呼び出すのに使用される。

・ライフタイム番号：本機能は、単一の仮想番号が有効である限り顧客と共に移動できる能力である。顧客が移動した場合でも、古い番号は継続して有効であり、顧客の新しい場所で顧客に到達する。本機能は、まさに電話ネットワークにおける静的ＩＰアドレスの類似形である。

・スピードダイアル：本機能は、短縮キー及びアクセラレータの組合せによってダイアルすることができる番号リストを大幅に拡張する能力である。ユーザが、オペレータユーザポータル上で着信履歴を通じて動作する際にこの情報を設定する場合、更新情報は、実時間でネットワーク側に伝播される必要がある可能性が極めて高いので、本機能は、統合アプリケーションの別の実施例である。

限定ではないが、以下の機能を含むメディア配信サービス
・ユーザが契約しようとするサービスレベルの同意に応じて、配信されるメディア品質（例えば、毎秒当たりのフレーム数）は変化する。ポリシーエンジンは、収益水準によって顧客ベースを区分することができ、ネットワークにおいてなされる投資の利益を最大にすることができる。

限定ではないが、以下の機能を含むコンテクスト依存アプリケーション。
・この場合の典型的な実施例は、短期の有効期間、その有効期間内の極めて高い利用ピーク及び即時性を有する用途に対する必要性である。例えば、ショーの期間中又はその直後のアメリカ人アイドルへの投票は、極めて一般的な用途であることを証明している。

限定ではないが、以下の機能を含む統合アプリケーション。
・アプリケーションの最終クラスは、有線及び無線端末利用状況を組み合わせたものである。例示的統合アプリケーションは以下のものである。移動体端末ユーザは、仕事に行く途上で電話会議を行っている。自分の事務所に到着すると、特別のキーシーケンスを入力して、事務所の電話に通話を転送するようにする。転送は、ユーザが、再度ダイアルイン情報をダイアルするのを必要とせずに自動的に行われる。ここで、この能力は、ハンドセットからのどのような特別なサポート（例えば、転送ボタン）を用いることなく利用可能である点に留意することが重要である。

様々な実施形態は、本明細書に提示された機能のいずれかを実施するように、汎用又は特定用途向け計算プロセッサ／デバイスをプログラミングするのに使用することができる、命令が記憶された記憶媒体であるコンピュータプログラム製品を含む。記憶媒体は、限定ではないが、以下の１つ又はそれ以上を含むことができ、すなわち、フロッピーディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、磁気光ディスク、ホログラム記憶装置、ＲＯＭ、ＲＡＭ、ＰＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ装置、磁気又は光カード、ナノシステム（分子メモリＩＣを含む）を含む物理的媒体のいずれかのタイプ；紙又は紙ベースの媒体；並びに命令及び／又は情報を記憶するのに適した媒体又はデバイスのいずれかのタイプ。様々な実施形態は、全体又は一部を、１つ又はそれ以上の公衆及び／又は私設ネットワークを介して転送することができるコンピュータプログラム製品を含み、ここで、この転送は、本明細書に提示された機能のいずれかを実施するための１つ又はそれ以上のプロセッサによって使用することができる命令を含む。様々な実施形態において、転送は、複数の別個の転送を含むことができる。

１つ又はそれ以上のコンピュータ可読媒体を記憶する場合、本発明の開示は、汎用／特定用途コンピュータのハードウェア及び／又はプロセッサの両方を制御し、且つ本発明の結果を利用して、コンピュータ及び／又はプロセッサが人間のユーザ又は他の機構と対話することを可能にするためのソフトウェアを含む。このようなソフトウェアは、限定ではないが、デバイスドライバ、オペレーティングシステム、実行環境／コンテナ、ユーザインタフェース及びアプリケーションを含むことができる。

本発明の好ましい実施形態についての上記の説明は、例証及び説明の目的で提供されてきた。これは、包括的なものではなく、或いは開示された厳密な形態に本発明を限定することを意図するものではない。多くの修正及び変形形態が可能であることは、当業者には明らかである。実施形態は、本発明の原理及び実際のアプリケーションを最も良く説明し、これによって関連技術の当業者が本発明を理解できるようにするために選択され説明された。本発明の範囲は、添付の請求項及びその均等物によって定義されるものとする。

ネットワーク内の通信セッションを管理するための技術を実装することができる例示的なシステムの機能ブロック図である。 １つの実施形態における例示的なサービス開発プラットフォームの機能ブロック図である。 ネットワーク内の通信セッションを管理するための技術を具現化することができるサービスコンテナの例示的な論理的アーキテクチャーの機能ブロック図である。 １つの実施形態におけるサービスコンテナ内の着呼処理の実施例の機能ブロック図である。 １つの実施形態におけるネットワーク内の通信セッションを管理するための技術の概要を示す動作フロー図である。

符号の説明

１００ サービス提供プラットフォーム
１１４ サービスプロバイダ
１１６ エンドユーザサービス
１１８ サードパーティプロバイダ

Claims (27)

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. 通信を管理するための前記ステートフル層と前記通信セッションと関連したアプリケーションを管理するためのステートレス層とを使用して前記通信セッションを管理する段階が、
    通信セッションに対応した状態情報に対するリクエストを受信する段階と、
    前記ステートフル層によって管理されるストライプから取り出された前記状態情報を供給する段階と、
    を含む、
    ことを特徴とする請求項１１記載の方法。
26. 通信セッションに対応した状態情報に対するリクエストを受信する段階が、前記リクエストをセッション開始プロトコル（ＳＩＰ）サーブレットから受信する段階を含む、
    ことを特徴とする請求項２５記載の方法。
27. 通信セッションを管理するための１つ又はそれ以上の命令シーケンスを保持するコンピュータ可読媒体であって、前記命令が、１つ又はそれ以上のプロセッサによって実行される場合に、
    少なくとも１つの通信セッションを開始するためのリクエストを送信者から受信する段階と、
    ステートフル層内の少なくとも１つの通信セッションを管理するために資源を割り当て、アプリケーション処理をステートレス層内の前記通信セッションに関連付ける段階と、
    前記ステートフル層を使用して前記少なくとも１つの通信セッションを管理し、前記ステートレス層を使用して前記少なくとも１つの通信セッションと関連したアプリケーションを管理する段階と、
    を前記１つ又はそれ以上のプロセッサに実行させる、
    ことを特徴とするコンピュータ可読媒体。

Images