JP2005536085A - シグナリング・イベントのためのサービス論理コンテキスト・キャッシュ - Google Patents

シグナリング・イベントのためのサービス論理コンテキスト・キャッシュ Download PDF

Info

Publication number
JP2005536085A
JP2005536085A JP2004514362A JP2004514362A JP2005536085A JP 2005536085 A JP2005536085 A JP 2005536085A JP 2004514362 A JP2004514362 A JP 2004514362A JP 2004514362 A JP2004514362 A JP 2004514362A JP 2005536085 A JP2005536085 A JP 2005536085A
Authority
JP
Japan
Prior art keywords
service
event
tcap
call
event context
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2004514362A
Other languages
English (en)
Other versions
JP4238212B2 (ja
Inventor
クリーマー、トーマス
ムーア、ヴィクター
ウォルターズ、グレン
ウィンターズ、スコット
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2005536085A publication Critical patent/JP2005536085A/ja
Application granted granted Critical
Publication of JP4238212B2 publication Critical patent/JP4238212B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0025—Provisions for signalling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0054—Service creation techniques

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephonic Communication Services (AREA)

Abstract

【課題】
【解決手段】電話システムにおいてシグナリング・イベント・データを共有するための方法は、第１のサービス論理コンポーネント内で、電話シグナリング・ネットワークからイベントを受信することを含み得る。当該イベントについて、イベント・コンテキストが判断され、また少なくとも前記第１サービス論理コンポーネントおよび第２のサービス論理コンポーネントに通信可能にリンクされたイベント・コンテキスト・キャッシュ内に、非同期で格納され得る。

Description

本発明は、電話の分野に関し、より詳細には、電話ネットワーク上のサービス論理コンポーネント間の情報交換に関する。
通信会社は、加入者に提供される、新しい電話サービスまたは機能あるいはその両方（以下、「サービス」）を、絶えず創出している。こうしたサービスはしばしば、複数のサービス論理コンポーネントが相互作用することを必要とする。ある一般的な例は、呼制御サービス論理とトランザクション・サービス論理である。呼制御サービス論理は、通話の音声通信の側面の設定に関連し、トランザクション・サービス論理は、８００番変換、データベース照会、ショート・メッセージ・サービス（ＳＭＳ：Short Message Service）、ローカル番号ポータビィティ、および他のトランザクション・ベースのサービスまたはサービス・コンポーネントなど、電話サービスの非音声処理面の基礎を提供する。したがって、所与の電話サービスを実施するために、呼制御サービス論理はしばしば、トランザクション・サービス論理と相互作用しなければならない。
たとえば、トランザクション・サービス論理によって実施された番号変換の結果として、通話が別の電話番号に転送される場合、呼制御サービス論理は、トランザクション・サービス論理から、通話の転送情報を取得できなければならない。すなわち、通話を受信したことに応答して、呼制御サービス論理は、発信側のサービス（originating service）、この場合、トランザクション・サービス論理に問い合わせして、どのように通話を処理するかを判断しなければならない。従来、それぞれ異なるサービス論理コンポーネント間のこうした相互作用は、サービス間メッセージング・プロトコルを使用することによって行われてきた。
受信側のサービスは、サービス間メッセージング・プロトコルを介して、所与の通話に関するコンテキスト情報を判断することができる。したがって、受信側サービス、この場合、呼制御サービス論理は、コンテキスト情報を参照して、通話を処理することができる。しかし、サービス間メッセージング機構には、欠点がある。その１つの欠点は、発信側サービスが、呼を完了するためにコンテキスト情報を必要とする、いずれかの受信側サービスに、複数のメッセージの形の情報を提供するために、アクティブ状態でいなければならないことである。発信側サービスは、「マスタ」になり、受信側サービスは、「スレーブ」になる。発信側サービスは、発信側サービスの一次機能が完了しているにも拘らず、受信側サービスに必要なメッセージング機能を提供するためだけにアクティブ状態のままでいる。したがって、サービス間の存続時間の間に、多くのメモリおよびプロセッサ・リソースが消費される。
別の欠点は、サービス間メッセージング・プロトコルを更新するコストが、非常に高くなり得ることである。特に、サービス間メッセージング・プロトコルを使用する各サービス論理コンポーネントは、プロトコル自体と一緒に更新しなければならない。したがって、所与のプロトコルを拡張するために、少なくとも２つのサービス論理コンポーネントを更新しなければならない。したがって、電話ネットワーク内の複数のノードは、整合の取れた（coordinated）更新処理を受けなければならないことがある。
こうしたタイプの問題によって、インテリジェント・ネットワーク（ＩＮ：IntelligentNetwork）および高度インテリジェント・ネットワーク（ＡＩＮ：Advanced Intelligent Network）の進歩が妨げられてきた。ＳＲ３５１１、１１２９コア（1129CORE）、コアＩＮＡＰなどの複数のプロトコルが開発されてきたが、国際標準は、生まれていない。さらに、サービス制御ポイント（ＳＣＰ：servicecontrol point）を維持するためのコスト・モデルは、電話交換機を維持するそれに比肩し始めている。さらに、ＳＣＰコスト・モデルを使用して実施されるサービスは、リソースを集約的に用いるので、サービス間の存続時間の間に、メモリおよびプロセッサ・リソースを使用する必要によって、サービスの実施、展開および維持のためのコストがさらに増大する。
本発明は、電話システム内の複数のサービス論理コンポーネントの間で、シグナリング・イベント・データを共有するための解決策を提供する。たとえば、本発明は、電話環境内で、呼処理システムとトランザクション処理システムの間のインターフェースとして使用することができる。具体的には、イベント・コンテキスト・キャッシュが、電話システムの複数のサービス論理コンポーネントに通信可能にリンクされ得る。したがって、本発明は、それぞれの電話サービス・コンポーネント内で、サービス間メッセージング・プロトコルの整合の取れた実装を行う必要をなくすことができる。サービス論理コンポーネントは、イベント・コンテキスト・キャッシュ内にエントリを作成し、次いで、他のイベントを処理することができる。たとえばサービス論理コンポーネントは、イベント・コンテキスト・キャッシュ内の情報にアクセスすることができる。したがって、発信側サービス論理コンポーネントは、他のサービス論理コンポーネントに、呼処理の命令メッセージを提供するためだけに集中しまたは実行し続ける必要はない。
本発明の一態様は、電話システム内で、シグナリング・イベント・データを共有するための方法を含み得る。この方法は、第１のサービス論理コンポーネント内で、電話シグナリング・ネットワークからイベントを受信すること、そのイベントについて、イベント・コンテキストを判断すること、ならびに第１サービス論理コンポーネントおよび少なくとも１つの第２のサービス論理コンポーネントに通信可能にリンクされた、イベント・コンテキスト・キャッシュ内に、イベント・コンテキストを格納することを含み得る。
第１サービス論理コンポーネントは、ＩＳＤＮまたはユーザ部インターフェース（ＩＳＵＰ：ISDN UserPart Interface）あるいはその両方のインターフェースを含む、呼処理システムであり得る。第２サービス論理コンポーネントは、トランザクション機能応用部（ＴＣＡＰ：transactioncapability application part）インターフェースを含む、トランザクション処理システムであり得る。電話シグナリング・ネットワークは、共通線信号Ｎｏ．７（ＳＳ７：SignalingSystem No.7）であり得る。イベントがＴＣＡＰイベントである場合、イベント・データ判断ステップは、受信されたＴＣＡＰイベントから、ダイヤルされた番号の受信サービス（inboundservice）、被呼側の電話番号、および実行される少なくとも１つの電話サービスを識別することを含み得る。
この方法はさらに、後続のＴＣＡＰイベントを受信すること、その後続のＴＣＡＰイベントのイベント・コンテキストが、イベント・コンテキスト・キャッシュ内に存在するかどうかを判断すること、およびそうでない場合は、後続のＴＣＡＰイベントのイベント・コンテキストを判断することを含み得る。後続ＴＣＡＰのイベントのイベント・コンテキストは、ダイヤルされた番号の受信サービス、被呼側の電話番号、実行される少なくとも１つの電話サービスを指定することができる。イベント・コンテキストは、イベント・コンテキスト・キャッシュ内に格納することができる。したがって、呼処理コンポーネントは、イベント・コンテキスト・キャッシュにアクセスして、転送された呼をどのように処理するかを判断することができる。
本発明の別の態様は、呼を受信すること、および受信された呼に関連するイベント・コンテキストがイベント・コンテキスト・キャッシュ内に存在するかどうかを判断することを含む、電話システム内でシグナリング・イベント・データを共有するための方法を含み得る。たとえば、判断ステップは、その呼から、ダイヤルされた番号の受信サービスおよび被呼側の電話番号を識別すること、ならびにダイヤルされた番号の受信サービスおよび被呼側の電話番号に従って、イベント・コンテキスト・キャッシュを検索することを含み得る。イベント・コンテキスト・キャッシュ内にエントリが存在する場合は、そのイベントが取り出され得る。たとえば、受信された呼を処理するために実行される、音声マークアップ言語スクリプトの位置が識別され得る。イベントが属性を指定する場合、その属性が識別され、実行時に、音声マークアップ言語スクリプトに提供され得る。受信された呼について、イベント・コンテキスト・キャッシュ内に、イベント・コンテキストが存在しない場合、呼回復機構が実行され得る。
本発明の別の態様は、第１のサービス論理コンポーネントと、第２のサービス論理コンポーネントと、第１サービス論理コンポーネントと第２サービス論理コンポーネントを通信可能にリンクする、イベント・コンテキスト・キャッシュとを含む、電話システムを含み得る。第１サービス論理コンポーネントは、ＩＳＵＰイベントを処理するように構成された呼処理システムであり得る。第２サービス論理コンポーネントは、ＴＣＡＰイベントを処理するように構成されたトランザクション処理システムであり得る。イベント・コンテキスト・キャッシュは、サービス間メッセージング・プロトコルを使用せずに、第１サービス論理コンポーネントと第２サービス論理コンポーネントの間の情報交換を実現することができる。
本発明の別の態様は、電話サービスの音声マークアップ言語スクリプト実装を実行するための分散論理環境を備えた呼処理コンポーネントと、電話サービスのＴＣＡＰマークアップ言語スクリプト実装を実行するための分散論理環境を備えたトランザクション処理コンポーネントとを含む、電話システムを含み得る。呼処理コンポーネントとトランザクション処理コンポーネントは、イベント・コンテキスト・キャッシュによって、通信可能にリンクされ得る。
呼処理コンポーネントは、呼を受信するように構成された呼処理装置を含み得る。呼処理装置は、電話番号に関連する電話サービスの音声マークアップ言語ドキュメント実装のアドレスを含み得る。呼処理コンポーネントは、呼の受信に応答して、アドレスから音声マークアップ言語ドキュメントを取り出し、また音声マークアップ言語を構文解析するように構成された、音声マークアップ言語パーサをも含み得る。呼処理コンポーネントはさらに、構文解析された音声マークアップ言語ドキュメントを実行して、電話サービスを実施するように構成されたサービス・プロセッサ、ならびに音声マークアップ言語パーサとサービス・プロセッサの動作を連携させるように構成された、少なくとも１つのセッション・マネージャを含み得る。
トランザクション処理コンポーネントは、電話番号に関連する電話サービスのＴＣＡＰマークアップ言語スクリプト実装のアドレスを含む、サービス・プロセッサを含み得る。トランザクション・サービス・プロセッサは、構文解析されたＴＣＡＰマークアップ言語を実行して、電話サービスを実施するように構成され得る。トランザクション処理コンポーネントは、ＴＣＡＰマークアップ言語パーサ、および少なくとも１つのトランザクション・セッション・マネージャをも含み得る。ＴＣＡＰマークアップ言語パーサは、アドレスから、電話サービスのＴＣＡＰマークアップ言語スクリプト実装を取り出し、ＴＣＡＰマークアップ言語スクリプトを構文解析するように構成され得る。トランザクション・セッション・マネージャは、ＴＣＡＰマークアップ言語パーサとトランザクション・サービス・プロセッサの動作を連携させるように構成され得る。
別の態様から見ると、本発明は、第１のサービス論理コンポーネント内で、電話シグナリング・ネットワークからイベントを受信するステップと、前記イベントのイベント・コンテキストを判断するステップと、前記第１サービス論理コンポーネント、および少なくとも１つの第２のサービス論理コンポーネントに通信可能に接続されたイベント・コンテキスト・キャッシュ内に、前記イベント・コンテキストを格納するステップとをマシンに実施させるために、マシンによって実行可能な複数のコード・セクションを含むコンピュータ・プログラムが格納された、マシン可読記憶装置を提供する。
好ましくは、本発明は、前記第１サービス論理コンポーネントが呼処理システムであり、前記第２サービス論理コンポーネントがトランザクション処理システムである、マシン可読記憶装置を提供する。
好ましくは、本発明は、前記呼処理システムが、ＩＳＤＮインターフェースおよびＩＳＵＰインターフェースのうちの少なくとも１つを含み、前記トランザクション処理システムが、ＴＣＡＰインターフェースを含み、前記電話シグナリング・ネットワークが共通線信号Ｎｏ．７ネットワークである、マシン可読記憶装置を提供する。
好ましくは、本発明は、前記イベントがＴＣＡＰイベントであり、前記イベント・データ判断ステップがさらに、前記受信されたＴＣＡＰイベントから、ダイヤルされた番号の受信サービス、被呼側の電話番号、および実行される少なくとも１つの電話サービスを識別することを含む、マシン可読記憶装置を提供する。
好ましくは、本発明は、後続のＴＣＡＰイベントを受信すること、前記後続のＴＣＡＰイベントのイベント・コンテキストが、前記イベント・コンテキスト・キャッシュ内に存在するかどうかを判断すること、およびそうでない場合は、ダイヤルされた番号の受信サービス、被呼側の電話番号、および実行される少なくとも１つの電話サービスを指定する、前記後続ＴＣＡＰイベントのためのイベント・コンテキストを判断し、また前記イベント・コンテキストを、前記イベント・コンテキスト・キャッシュ内に格納することをさらに含む、マシン可読記憶装置を提供する。
好ましくは、本発明は、前記呼処理コンポーネントが前記イベント・コンテキスト・キャッシュにアクセスして、転送された呼をどのように処理するかを判断することをさらに含む、マシン可読記憶装置を提供する。
別の態様から見ると、本発明は、呼を受信するステップと、前記受信された呼に関連するイベント・コンテキストが、イベント・コンテキスト・キャッシュ内に存在するかどうかを判断するステップと、そうである場合に、前記イベント・コンテキスト・キャッシュから、前記イベント・コンテキストを取り出すステップと、およびそうでない場合に、呼回復機構を実行するステップをマシンに実施させるために、マシンよって実行可能な複数のコード・セクションを含む、コンピュータ・プログラムが格納されたマシン可読記憶装置を提供する。
好ましくは、本発明は、前記判断ステップがさらに、前記呼から、ダイヤルされた番号の受信サービスおよび被呼側の電話番号を判断するステップと、前記ダイヤルされた番号の受信サービスおよび前記被呼側の電話番号に従って、前記イベント・コンテキスト・キャッシュを検索することを含む、マシン可読記憶装置を提供する。
好ましくは、本発明は、前記取出しステップがさらに、前記受信された呼を処理するために実行する、音声マークアップ言語スクリプトの位置を識別するステップを含む、マシン可読記憶装置を提供する。
好ましくは、本発明は、前記識別ステップがさらに、前記イベント・コンテキストによって指定される属性を識別するステップを含み、実行時に、前記属性が、前記マークアップ言語スクリプトに提供される、マシン可読記憶装置を提供する。
次に、本発明について、例示するためだけに、添付の図面を参照して説明する。
本発明は、電話システム内の複数のサービス論理コンポーネントの間で、シグナリング・イベント・データを共有するための解決策を提供する。たとえば、本発明は、電話環境内で、呼処理システムとトランザクション処理システムの間のインターフェースとして使用することができる。具体的には、イベント・コンテキスト・キャッシュが、電話システムの複数のサービス論理コンポーネントに、通信可能にリンクされ得る。サービス論理コンポーネントは、他のサービス論理コンポーネントに対し、受信された呼をどのように処理するかを示すことができるイベント・コンテキスト情報を格納することによって、イベント・コンテキスト・キャッシュを介して通信することができる。
図１は、本明細書で開示される本発明の構成による、イベント・コンテキスト・キャッシュ２５が２つのサービス論理コンポーネント１５と２０の間に配置された、システム１０を示す概略図である。イベント・コンテキスト・キャッシュ２５は、サービス論理コンポーネント１５および２０に通信可能にリンクされ得る、１つまたは複数の分散コンピュータ・システム、記憶装置および／またはメモリ装置として実装することができる。したがって、イベント・コンテキスト・キャッシュ２５は、サービス間メッセージング・プロトコルの代わりに使用され得る。したがって、様々なシグナリング・イベントが、たとえばサービス論理コンポーネント１５によって受信されるときに、受信されたイベントに関する情報を、イベント・コンテキスト・キャッシュ２５内に、エントリとして置くことができる。したがって、サービス論理コンポーネント２０からの後の問合わせに応答するために、サービス論理コンポーネント１５がアクティブのままで、または「有効範囲内」にとどまるのではなく、サービス論理コンポーネント２０がイベント・コンテキスト・キャッシュ２５に照会して、シグナリング・イベント情報を判断することができるので、サービス論理コンポーネント１５のリソースを、別のイベントまたはサービスあるいはその両方に充てることができる。特に、２つのサービス論理コンポーネントが示されているが、３つ以上のサービス論理コンポーネントが、イベント・コンテキスト・キャッシュ２５に通信可能に接続され得ることが当業者には理解されよう。
図２は、本明細書で開示される本発明の構成による、イベント・コンテキスト・キャッシュ６５が呼処理サービス・コンポーネント５５とトランザクション処理サービス・コンポーネント６０の間に配置された、システム５０を示す概略図である。呼処理サービス・コンポーネント５５は、ＩＳＤＮユーザ部（ＩＳＰＵ）インターフェースを含み得る。トランザクション処理サービス・コンポーネント６０は、トランザクション機能アプリケーション部（ＴＣＡＰ）インターフェースを含み得る。
動作において、トランザクション処理サービス・コンポーネント６０は、ＴＣＡＰイベントを受信することができる。トランザクション処理サービス・コンポーネント６０は、イベント・コンテキスト・キャッシュ６５にアクセスして、受信されたＴＣＡＰイベントに関連するイベント・コンテキストが、イベント・コンテキスト・キャッシュ６５内に存在するかどうかを判断することができる。そうである場合、トランザクション処理サービス・コンポーネント６０は、イベント・コンテキスト・キャッシュのエントリをリフレッシュすることができる。そうでない場合、トランザクション処理サービス・コンポーネント６０は、イベント・コンテキスト・キャッシュ６０内に、新しいエントリを置くことができる。たとえば、トランザクション処理サービス・コンポーネント６０は、イベント・コンテキスト・キャッシュ６５内に、ダイヤルされた番号の受信サービス（ＤＮＩＳ：dialed number inbound service）、被呼側の電話番号、ならびに呼処理アプリケーション、スクリプト、および／または呼処理アプリケーションおよびスクリプトの実行に必要な関連データを指定する、エントリを置くことができる。
トランザクション処理サービス・コンポーネント６０は、ＴＣＡＰイベントに応答して、呼がＤＮＩＳに関連する音声メールボックスに転送されるものであると判断することができる。したがって、トランザクション処理サービス・コンポーネント６０は、呼が転送される先の電話番号、ならびに転送された呼を処理するために実行されるいずれのアプリケーションをも判断することができる。したがって、この場合、トランザクション処理サービス・コンポーネントは、イベント・コンテキスト・キャッシュ内に、ＤＮＩＳ、発呼側の電話番号、呼が転送される先の電話番号、ならびにいずれかのアプリケーションおよびアプリケーション・パラメータを指定する、エントリを置くことができる。
呼処理サービス・コンポーネント５５は、呼を受信すると、着呼によって指定されるＤＮＩＳおよび発呼側電話番号を使用して、イベント・コンテキスト・キャッシュ６５に照会することができる。呼処理サービス・コンポーネント５５は、呼が転送される先の電話番号、ならびに実行されるいずれのアプリケーションおよびアプリケーション・パラメータをも取得することができる。イベント・コンテキスト・キャッシュのエントリは、受信側のサービス・コンポーネント、この場合、呼処理サービス・コンポーネント５５が受信された呼を処理するのに必要な情報にアクセスできるように、数秒間だけ保持される必要がある。そうではなく、イベント・コンテキスト・キャッシュ６５内に、受信された呼についてのエントリが置かれていない場合は、呼処理サービス・コンポーネントは、呼の廃棄、発呼者へのメッセージの再生、ＤＮＩＳに関連するボイス・メールに呼を転送するなど、回復機構を実施することができる。
図３は、本明細書で開示される本発明の構成による、電話サービスまたは機能あるいはその両方（以下「サービス」）を実施するための、例示的なシステム１００を示す概略図である。図３に示すように、システム１００は、呼制御コンポーネント１０２およびトランザクション処理コンポーネント１０４を含み得る。呼制御コンポーネント１０２とトランザクション処理コンポーネント１０４は、キャッシュ２６０を介して通信可能にリンクされ得る。
呼制御コンポーネント１０２は、メディア・ゲートウェイ１０５、Ｂｅａｎ／スクリプト・アプリケーション（サービス・プロセッサ）１１５、セッション・マネージャ１２０、ＶＸＭＬパーサ１２５、ハイパーテキスト転送プロトコル（ＨＴＴＰ：hyper-text transfer protocol）サーバ１３０、およびデータ・ストア１３５を含み得る。データ・ストア１３５は、ドキュメント、音声、テキストなどを指定する、１つまたは複数のＶＸＭＬスクリプトを含み得る。ＶＸＭＬスクリプト、たとえばスクリプト１０９は、電話サービスの呼制御の側面を指定するスクリプト実装である。データ・ストア１３５内のＶＸＭＬスクリプトは、ＨＴＴＰサーバ１３０を介してアクセスすることができる。データ・ストア１３５は、単一のデータ・ストアとして示されているが、１つまたは複数の分散されたデータ・ストアとして実装され得ることを理解されたい。
メディア・ゲートウェイ１０５は、Ｔ１回線またはＩＳＤＮ回線あるいはその両方など、１つまたは複数の通信トランク回線（図示せず）に通信可能にリンクされ得る。それぞれの入り通信トランク回線は、メディア・ゲートウェイ１０５と通信トランク回線の間のインターフェースとして働く、チャネル・プロセッサ１６０にインターフェースさせることができる。対応する電話交換機の各音声回線について、１つのチャネル・プロセッサ１６０が含まれ得る。メディア・ゲートウェイ１０５は、アプリケーション・テーブル１０７およびＢｅａｎ／スクリプト・インターフェース１１０をも含み得る。アプリケーション・テーブル１０７は、ＤＮＩＳと、データ・ストア１３５内に格納されている電話サービスのＶＸＭＬスクリプト実装との間の関連を指定することができる。より具体的には、アプリケーション・テーブル１０７は、ＤＮＩＳおよび、ＤＮＩＳが登録されている電話サービスのリストを維持する。アプリケーション・テーブル１０７はさらに、電話サービスの様々なＶＸＭＬ実装スクリプトが取り出され得る、ネットワーク位置を指定することができる。
したがって、着呼を受信すると、メディア・ゲートウェイ１０５は、着呼によって指定されるＤＮＩＳを判断することができる。ＤＮＩＳは、アプリケーション・テーブル１０７を使用して、１つまたは複数のＶＸＭＬスクリプトに一致させることができる。したがって、ＤＮＩＳが登録されている電話サービスの、ＶＸＭＬスクリプト実装の位置またはアドレスが識別され得る。電話サービスのＶＸＭＬスクリプトの位置は、セッション・マネージャ１２０に提供され得る。
メディア・ゲートウェイ１０５は、共通線信号Ｎｏ．７（ＳＳ７）インターフェース１６５をも含み得る。ＳＳ７インターフェース１６５は、メッセージ転送部（ＭＴＰ：Message Transfer Part）インターフェース、およびＩＳＤＮユーザ部インターフェース（ＩＳＵＰ）を含み得る。メディア・ゲートウェイ１０５のＳＳ７インターフェース１６５は、呼を設定し、切断するために必要なプロトコルをサポートし、また音声通信をサポートすることができる。たとえば、ＭＴＰインターフェースは、物理層、データ・リンク層、およびネットワーク層向けサービスをサポートすることができる。ＭＴＰインターフェースは、通信する２つのエンドポイント間の信頼性の高いシグナリング・メッセージ交換を容易にすることができる。ＭＴＰを使用することによって、フロー制御、エラー・チェック、およびエンドポイント間のメッセージ順序制御などのタスクを実施することができる。ＭＴＰインターフェースは、アドレッシング、ルーティングおよび輻輳制御を実施することによって、信号局間で確実に送達するために必要なサービスを提供することもできる。ＩＳＵＰインターフェースは、ＰＳＴＮを介して呼を確立し終了する間に使用され得る、必要な呼制御サービスを提供することができる。特に、ＩＳＵＰインターフェースを使用して、シグナリング・ネットワーク上で、長距離電話（trunkcall）を設定し、維持し、切断するのにどの手順が適しているかを判断することができる。
あるローカル・エリア・ネットワーク（ＬＡＮ：local area network）を、別のＬＡＮに接続するためのブリッジ・サービスまたは機能を含み得る、Ｂｅａｎ／スクリプト・インターフェース１１０は、メディア・ゲートウェイ１０５内に含まれ得る。Ｂｅａｎ／スクリプト・インターフェース１１０は、サービス・プロセッサ１１５と、チャネル・プロセッサ１６０および音声インターフェース１４０など、メディア・ゲートウェイ１０５の他のコンポーネントとの通信を円滑に進めることができる。Ｂｅａｎ／スクリプト・インターフェース１１０は、本明細書で以下に論じる、サービス・プロセッサ１１５によって解釈されるＶＸＭＬスクリプトを介して提供され得る、機能の範囲をサポートするように構成され得る。特に、ＶＸＭＬスクリプトが、拡張された呼制御およびＴＣＡＰ機能をサポートすることができるときは、Ｂｅａｎ／スクリプト・インターフェース１１０も同様に、その呼制御およびＴＣＡＰ機能をサポートするように構成され得る。音声インターフェース１４０は、音声認識、およびテキスト音声変換（ＴＴＳ：text-to-speech）機能を提供することができる。したがって、通信トランク回線を介して受信された音声は、テキストに変換されることができ、またテキスト・データは、通信トランク回線を介して１人または複数の加入者に提供するために、オーディオ・ストリームに変換されることができる。
サービス・プロセッサ１１５、セッション・マネージャ１２０、およびＶＸＭＬパーサ１２５は全体として見ると、分散音声ブラウザのコンポーネントを提供している。ＶＸＭＬパーサ１２５は、実行時に、インスタンス化されることができ、ＨＴＴＰサーバ１３０を介して、データ・ストア１３５からＶＸＭＬスクリプトを取り出すことができる。ＶＸＭＬパーサ１２５は、取り出されたＶＸＭＬを、サービス・プロセッサ１２５にマップされ、またそれによって解釈され得る中間フォーマットに変換することができる。特に、ＶＸＭＬスクリプトは、通話許可、通話阻止、通話転送、選択通話転送、電話会議システム（Bridge Call）など、ＴＣＡＰトランザクションを定義する新しいタグを含むように拡張され得る。したがって、ＶＸＭＬパーサ１２５は、ＶＸＭＬスクリプトへのどんな追加のタグ拡張をも識別するように構成することもできる。
サービス・プロセッサ１１５は、分散コンピューティング環境内の同じまたは異なるコンピュータ・システム上の他のコンポーネントと組み合わせることができる、再利用可能なコンポーネントであり得る。実行時に、それぞれのチャネル・プロセッサ１６０について、１つのサービス・プロセッサ１１５をインスタンス化することができ、したがって、それは、特定のチャネル・プロセッサに関連付けられ得る。サービス・プロセッサ１１５は事実上、構文解析されたＶＸＭＬスクリプトが、ＶＸＭＬスクリプトによって指定された電話サービスを実施するための実行環境を提供する、インタプリタとして働く。したがって、サービス・プロセッサ１１５は、メディア・ゲートウェイ１０５の内部機能を、電話サービスの構文解析されたＶＸＭＬスクリプト表現に一致させる。図示するように、サービス・プロセッサ１１５は、メディア・ゲートウェイ１０５の音声インターフェース１４０に通信可能にリンクされ得る。したがって、サービス・プロセッサ１１５は、構文解析されたＶＸＭＬスクリプトによって指定される、電話サービスを実施するためのＴＴＳおよび音声認識機能にアクセスすることができる。たとえば、テキストおよび認識された音声を使用して、ＶＸＭＬスクリプト、フォーム、および／またはドキュメントのフィールドを埋めることができる。
特に、サービス・プロセッサ１１５およびＶＸＭＬパーサ１２５は、Ｊａｖａ（Ｒ）仮想マシン１４５および１５５内でそれぞれ実行され得る。図３に、複数のサービス・プロセッサ１１５およびＶＸＭＬパーサ１２５が、個別のＪａｖａ（Ｒ）仮想マシン１４５および１５５内で実行されているのが示されているが、それぞれのサービス・プロセッサ１１５およびＶＸＭＬパーサ１２５を、個別のＪａｖａ（Ｒ）仮想マシン内で実行することができ、したがって、あるプログラム内で発生するエラーが、別のプログラムに悪影響を及ぼすリスクが最小限に抑えられる。
それぞれのサービス・プロセッサ１１５およびＶＸＭＬパーサ１２５は、セッション・マネージャ１２０に登録することができる。したがって、セッション・マネージャ１２０は、呼処理のために、どのサービス・プロセッサ１１５およびＶＸＭＬパーサ１２５を使用可能であるかを追跡することができる。セッション・マネージャ１２０はさらに、サービス・プロセッサ１１５／ＶＸＭＬパーサ１２５対の動作を連携させることができる。セッション・マネージャ１２０は、サービス・プロセッサ１１５とＶＸＭＬパーサ１２５の間で情報を渡すことができる。特に、メディア・ゲートウェイ１０５からセッション・マネージャ１２０に提供される要求は、被呼側の電話番号、電話サービスの１つまたは複数のＶＸＭＬスクリプト表現を指定する、ユニバーサル・リソース・ロケータ（ＵＲＬ：universal resource locator）を含めた１つまたは複数のユニバーサル・リソース識別子（ＵＲＩ：universalresource identifier）、および呼が受信される特定のチャネル・プロセッサを表す識別子を含み得る。セッション・マネージャ１２０は、ローカルのデータ・ストア内に情報を保存することができる。したがって、セッション・マネージャ１２０は、受信されたＵＲＩが提供され得る先の空きＶＸＭＬパーサ１２５を判断することができる。さらに、ＶＸＭＬパーサ１２５からの結果は、保存されたＵＲＩ、被呼側の電話番号、およびチャネル・プロセッサの識別子に従って、適切なサービス・プロセッサ１１５に提供することができる。
サービス・プロセッサ１１５およびＶＸＭＬパーサ１２５の場合と同様に、複数のセッション・マネージャ１２０を、単一のＪａｖａ（Ｒ）仮想マシン内で実行することができ、またはそれぞれのセッション・マネージャ１２０を、個別のＪａｖａ（Ｒ）仮想マシン内で実行することができる。いずれの場合も、上述したように、サービス・プロセッサ１１５、セッション・マネージャ１２０およびＶＸＭＬパーサ１２５は、コンピューティング・ネットワーク全体にわたって分散された別個のコンピューティング・マシン内に存在することができる。さらに、こうした様々なコンポーネントは、増加した処理負荷をサポートするために、必要に応じて、複製され得る。したがって、サービス・プロセッサ１１５、セッション・マネージャ１２０およびＶＸＭＬパーサ１２５は、全体として見ると、大量のシステム要求をサポートするようにスケーリングされ得る、分散型の音声ブラウザ・アーキテクチュアを提供している。キャッシュ・メモリ１７０は、セッション・マネージャ１２０とＶＸＭＬパーサ１２５の間に配置され得る。キャッシュ・メモリ１７０は、頻繁に使用されるＶＸＭＬスクリプトの複数のフェッチおよび構文解析を減らすことによって、システム・パフォーマンスを増加させることができる。
トランザクション処理コンポーネント１０４は、ＳＳ７ ＴＣＡＰサーバ２００、ＳＳ７ ＴＣＡＰクライアント２０５、ＴＣＡＰ Ｂｅａｎ／スクリプト・アプリケーション（トランザクション・サービス・プロセッサ）２１０、トランザクション・セッション・マネージャ２２０、ＴＣＡＰ ＸＭＬパーサ２２５、ハイパーテキスト転送プロトコル（ＨＴＴＰ：hyper-text transfer protocol）サーバ２３０およびデータ・ストア２３５を含み得る。データ・ストア２３５は、１つまたは複数の電話サービスに従って実施されるトランザクションを指定する、スクリプト２０９などの１つまたは複数のＴＣＡＰ ＸＭＬスクリプトを含み得る。たとえば、ＴＣＡＰ ＸＭＬスクリプトは、８００番変換、データベース照会、ショート・メッセージ・サービス（ＳＭＳ）、ローカル番号ポータビィティ、および他のトランザクション・ベースのサービスまたはサービス側面を実施することができる。たとえば、データ・ストア２３５内のＴＣＡＰ ＸＭＬスクリプトは、ＨＴＴＰサーバ２３０を介してアクセスすることができる。データ・ストア２３５は、単一のデータ・ストアとして示されているが、１つまたは複数の分散データ・ストアとしても実装され得ることを理解されたい。
ＳＳ７サーバ２００は、シグナリング・ネットワーク、この場合、ＳＳ７ネットワークとのインターフェースを提供することができる。ＳＳ７サーバ２００は、ＭＴＰインターフェース、シグナリング接続制御部インターフェース（ＳＣＣＰ：Signaling Connection Control Part Interface）およびＴＣＡＰインターフェースを含み得る。ＳＣＣＰインターフェースは、信号局内のアプリケーションに、アドレッシング機能を提供することができる。たとえば、ＳＣＣＰインターフェースを使用して、８００番電話処理、高度インテリジェント・ネットワーク（ＡＩＮ：advancedintelligent network）サービス、コーリングまたはクレジット・カード処理サービス、およびカスタム・ローカル・エリア・シグナリング・サービス（ＣＬＡＳＳ：customlocal area signaling service）を提供するアプリケーションをアドレッシングすることができる。ＳＳ７サーバ２００は、他のインターフェース、たとえば移動応用部（ＭＡＰ：mobileapplication part）インターフェース、インテリジェント・ネットワーク（ＩＮ）インターフェースおよび高度インテリジェント・ネットワーク（ＡＩＮ）インターフェース、またはＩＮ（ＩＴＵ−Ｔ／ＥＴＳＩ ＣＳ１／２）インターフェースを提供することができる。こうしたインターフェースを使用して、既存のサービスを向上させ、または新しいサービス機能または強化を提供することができる。
ＴＣＡＰインターフェースは、ネットワーク・エンティティ間のトランザクション関連情報の交換を含めて、非回線関連のアクティビティをサポートするのに必要なサービスを提供することができる、アプリケーション・ベースのインターフェースであり得る。ＴＣＡＰインターフェースは、たとえば、アプリケーションにメッセージを伝達するために、ＳＣＣＰインターフェースを使用することができる。特に、ＴＣＡＰインターフェースは、８００番トランザクション、コーリングまたはクレジット・カード・トランザクション、ならびにＡＩＮおよびＣＬＡＳＳトランザクションに必要なサービスを提供することができる。ＳＳ７クライアント２０５は、ＳＳ７サーバ２００と相互作用するために使用され得る、アプリケーション・プログラミング・インターフェース（ＡＰＩ：application programming interface）のライブラリを含み得る。さらに、ＳＳ７クライアント２０５は、Ｊａｖａ（Ｒ）対応ＴＣＡＰアプリケーション・プロトコル・インターフェースと称され得る、Ｊａｖａ（Ｒ）対応ＴＣＡＰインターフェースを介して、トランザクション・プロセッサ２１０との通信を円滑に進めることができる。
ＴＣＡＰ ＸＭＬパーサ２２５は、実行時に、インスタンス化されることができ、またＨＴＴＰサーバ２３０を介してデータ・ストア２３５から、ＴＣＡＰ ＸＭＬスクリプトを取り出すことができる。ＴＣＡＰ ＸＭＬパーサ２２５は、取り出されたＴＣＡＰ ＸＭＬスクリプトを、トランザクション・サービス・プロセッサ２１０にマップされ、またそれによって解釈され得る中間フォーマットに変換することができる。特に、ＴＣＡＰ ＸＭＬスクリプトは、通話許可、通話阻止、通話転送、選択通話転送および電話会議システムなど、ＴＣＡＰトランザクションを定義する新しいタグを含み得る。したがって、ＴＣＡＰ ＸＭＬパーサ２２５は、ＴＣＡＰ ＸＭＬスクリプト内のいずれのＴＣＡＰ関連タグをも識別するように構成することもできる。
トランザクション・サービス・プロセッサ２１０は、分散コンピューティング環境内の同じまたは異なるコンピュータ・システム上の他のコンポーネントと組み合わせることができる、再利用可能なコンポーネントであり得る。トランザクション・サービス・プロセッサ２１０は、Ｊａｖａ（Ｒ）対応のＴＣＡＰインターフェースを介して、ＳＳ７クライアント２０５と通信するように構成され得る。受信されたそれぞれのＴＣＡＰイベントについて、１つのトランザクション・サービス・プロセッサ２１０を、実行時に、インスタンス化することができ、あるいは、１つまたは複数のトランザクション・サービス・プロセッサ２１０が、ＴＣＡＰイベントを受信するために、動作状態のままであり得る。いずれの場合でも、追加のトランザクション・サービス・プロセッサ２１０が、追加のＴＣＡＰイベントを処理するために、必要に応じて、インスタンス化され得る。それぞれのトランザクション・サービス・プロセッサ２１０は、アプリケーション・テーブル２１５のコピーに関連付けられ得る。アプリケーション・テーブル２１５は、ＤＮＩＳと、データ・ストア２３５に格納されている電話サービスのＴＣＡＰ ＸＭＬスクリプト実装との間の関連を指定することができる。より具体的には、アプリケーション・テーブル２１５は、ＤＮＩＳおよび、ＤＮＩＳが登録されている電話サービスのリストを維持する。アプリケーション・テーブル２１５はさらに、電話サービスの様々なＴＣＡＰ ＸＭＬ実装スクリプトを取り出すことができるネットワーク位置を指定する。
ＴＣＡＰインターフェースを介して、ＳＳ７クライアント２０５からＴＣＡＰイベント受信すると、トランザクション・サービス・プロセッサ２１０が、インスタンス化され得る。トランザクション・サービス・プロセッサ２１０は、ＴＣＡＰクライアント２０５からの受信ＴＣＡＰイベントによって指定されるＤＮＩＳを受信することができる。トランザクション・サービス・プロセッサ２１０は、アプリケーション・テーブル２１５を使用して、ＤＮＩＳを、１つまたは複数のＴＣＡＰ ＸＭＬスクリプトに一致させ得る。したがって、ＤＮＩＳが登録されている、電話サービスのＴＣＡＰ ＸＭＬスクリプト実装の位置またはアドレスが、識別され得る。電話サービスのＴＣＡＰ ＸＭＬスクリプトの位置は、トランザクション・セッション・マネージャ２２０に提供され得る。トランザクション・サービス・プロセッサ２１０は、構文解析されたＴＣＡＰ ＸＭＬスクリプトが、電話サービスのトランザクション側面を実施するための実行環境を提供する、インタプリタとしても働く。トランザクション・サービス・プロセッサ２１０は、ＴＣＡＰインターフェースを介してＴＣＡＰスタックと相互作用して、ＴＣＡＰ ＸＭＬスクリプトによって定義された、トランザクション・ベースのサービスを実施することができる。
特に、トランザクション・サービス・プロセッサ２１０およびＴＣＡＰ ＸＭＬパーサ２２５は、Ｊａｖａ（Ｒ）仮想マシン２４０および２５０内でそれぞれ実行され得る。図３に、複数のトランザクション・サービス・プロセッサ２１０およびＴＣＡＰ ＸＭＬパーサ２２５が、個別のＪａｖａ（Ｒ）仮想マシン２４０および２５０内で実行されているのが示されているが、それぞれのトランザクション・サービス・プロセッサ２１０およびＴＣＡＰ ＸＭＬパーサ２２５を、個別のＪａｖａ（Ｒ）仮想マシン内で実行することができ、したがって、あるプログラム内で発生するエラーが、別のプログラムに悪影響を及ぼすリスクが最小限に抑えられる。
それぞれのトランザクション・サービス・プロセッサ２１０およびＴＣＡＰ ＸＭＬパーサ２２５は、トランザクション・セッション・マネージャ２２０に登録することができる。したがって、トランザクション・セッション・マネージャ２２０は、呼処理のために、どのトランザクション・サービス・プロセッサ２１０およびＴＣＡＰ ＸＭＬパーサ２２５が使用可能であるかを追跡することができる。トランザクション・セッション・マネージャ２２０はさらに、トランザクション・サービス・プロセッサ２１０／ＴＣＡＰ ＸＭＬパーサ２２５対の動作を連携させることができる。トランザクション・セッション・マネージャ２２０はさらに、トランザクション・サービス・プロセッサ２１０とＴＣＡＰ ＸＭＬパーサ２２５の間で情報を渡すことができる。
たとえば、トランザクション・サービス・プロセッサ２１０からトランザクション・セッション・マネージャ２２０に提供されたＴＣＡＰイベントは、アプリケーション・テーブル２１５からの適切なＴＣＡＰ ＸＭＬスクリプトにそれを一致させた後は、ＤＮＩＳ、電話サービスの１つまたは複数のＴＣＡＰ ＸＭＬスクリプト表現を指定する、ユニバーサル・リソース・ロケータ（ＵＲＬ）を含めた１つまたは複数のユニバーサル・リソース識別子（ＵＲＩ）、ＴＣＡＰ識別子、ならびにトランザクション・プロセッサ識別子を指定することができる。トランザクション・セッション・マネージャ２２０は、ローカル・データ・ストア内に、その情報を保存することができる。したがって、トランザクション・セッション・マネージャ２２０は、受信されたＵＲＩが提供され得る、空きＴＣＡＰ ＸＭＬパーサを判断することができる。さらに、ＴＣＡＰ ＸＭＬパーサ２２５からの結果は、保存されたＵＲＩ、ＤＮＩＳ、およびトランザクション・プロセッサ識別子に従って、適切なトランザクション・サービス・プロセッサ２１０に提供することができる。
トランザクション・サービス・プロセッサ２１０およびＴＣＡＰ ＸＭＬパーサ２２５の場合と同様に、複数のトランザクション・セッション・マネージャ２２０を、単一のＪａｖａ（Ｒ）仮想マシン内で実行することができ、またはそれぞれのトランザクション・セッション・マネージャ２２０を、個別のＪａｖａ（Ｒ）仮想マシン内で実行することができる。いずれの場合も、上述したように、トランザクション・サービス・プロセッサ２１０、トランザクション・セッション・マネージャ２２０およびＴＣＡＰ ＸＭＬパーサ２２５は、コンピューティング・ネットワーク全体にわたって分散された別個のコンピューティング・マシン内に存在することができる。さらに、こうした様々なコンポーネントは、増加した処理負荷をサポートするために、必要に応じて、複製され得る。したがって、トランザクション・サービス・プロセッサ２１０、トランザクション・セッション・マネージャ２２０およびＴＣＡＰ ＸＭＬパーサ２２５は、全体として見ると、大量のＴＣＡＰイベントをサポートするようにスケーリングされ得る、別個の論理コンポーネントを含む分散型ＴＣＡＰイベント処理アーキテクチュアを提供している。
キャッシュ・メモリ２５５は、セッション・マネージャ２２０とＴＣＡＰ ＸＭＬパーサ２２５の間に配置され得る。キャッシュ・メモリ２５５は、頻繁に使用されるＴＣＡＰ ＸＭＬスクリプトの複数のフェッチおよび構文解析を減らすことによって、システム・パフォーマンスを増加させることができる。本明細書で開示される本発明の構成はさらに、１つまたは複数のファイアウォール１７５、１８０および１８５を含み得る。ファイアウォールは、本明細書で開示されるシステム１００の動作には必要ないが、ファイアウォールを追加すると、ネットワークのセキュリティ強化がもたらされる。特に、ファイアウォール１７５、１８０によって、多くの通信企業が必要とする、二重のファイアウォール保護が提供される。ファイアウォール１８５によって、ＶＸＭＬパーサおよびＴＣＡＰ ＸＭＬパーサを、企業または他の私設ネットワークから分離することができる。
呼処理コンポーネント１０２とトランザクション処理コンポーネント１０４は、イベント・コンテキスト・キャッシュ２６０によって、通信可能にリンクされ得る。イベント・コンテキスト・キャッシュ２６０は、エントリが数秒しか存続しない、非同期キャッシュであり得る。トランザクション処理コンポーネント１０４は、呼、ＴＣＡＰイベントまたはサービスに関する情報を、コンテキスト・キャッシュ２６０内に格納することができる。トランザクション処理コンポーネント１０４によって、コンテキスト・キャッシュ内に格納された情報は、呼処理コンポーネント１０２からアクセスすることができる。したがって、その情報は、トランザクション処理コンポーネント１０４内で受信されたＴＣＡＰイベントの結果として、呼処理コンポーネント１０２によって転送されまたは受信される呼を、どのように処理するかに関する指示を、呼処理コンポーネント１０２に提供することができる。
たとえば、ＴＣＡＰ ＸＭＬスクリプトを実行するときに、トランザクション・サービス・プロセッサ２１０は、コンテキスト・キャッシュ２６０内にエントリを作成することができる。それぞれのエントリは、数秒間しか維持されないが、エントリは、ＤＮＩＳ、発呼側番号、およびサービス名またはＵＲＩ、たとえば実行されるＶＸＭＬスクリプトを含めた情報、ならびに実行のためにＶＸＭＬスクリプトによって必要とされ得るいずれのパラメータをも指定することができる。特に、受信されたＴＣＡＰイベントのイベント・コンテキストは、ＴＣＡＰ ＸＭＬスクリプトの実行によって判断され得る。呼処理コンポーネントは、転送された呼を受信すると、サービス間メッセージング・プロトコルを介してトランザクション処理コンポーネント１０４に問い合わせるのではなく、コンテキスト・キャッシュ２６０にアクセスして、呼処理のための適切な動作過程を判断することができる。
図４は、図３のシステムによって実施される電話サービスのトランザクション側面を実装する方法３００を示すフローチャートである。この方法は、図３のシステムが、少なくとも１つのトランザクション・サービス・プロセッサをインスタンス化している状態で開始することができる。さらに、トランザクション・サービス・プロセッサおよびパーサが、トランザクション・セッション・マネージャに登録できるように、ＴＣＡＰ ＸＭＬパーサなどの１つまたは複数のパーサが、インスタンス化され得る。特に、サービス・プロセッサとパーサの間に、１対１の対応関係がある必要はない。いずれにせよ、ステップ４０５で、ＳＳ７サーバは、シグナリング・ネットワークからＴＣＡＰイベントを受信することができる。ステップ４１０で、受信されたＴＣＡＰイベントが、ＩＰ接続を介してＳＳ７クライアントに送信され得る。
次いで、ステップ４１５で、ＴＣＡＰイベントが、トランザクション・サービス・プロセッサに提供され得る。ＴＣＡＰイベントは、ＤＮＩＳおよび発呼側の電話番号を指定することができる。したがって、ステップ４２０で、ＤＮＩＳに関連付けられる１つまたは複数のＴＣＡＰ ＸＭＬスクリプトが、識別され得る。たとえば、ＤＮＩＳおよび関連のＴＣＡＰ ＸＭＬスクリプトのリストに照会して、ＤＮＩＳが登録されている電話サービスの特定のＴＣＡＰ ＸＭＬスクリプト実装を判断することができる。
ステップ４２５で、受信されたＴＣＡＰイベントに関するエントリが、イベント・コンテキスト・キャッシュ内に作成されているかどうかが判断され得る。そうである場合、この方法は、ステップ４３５に進み得る。しかし、そうでない場合、この方法は、ステップ４３０に続き、イベント・コンテキスト・キャッシュ内に、エントリが作成され得る。イベント・コンテキスト・キャッシュ内のエントリは、ＤＮＩＳ、発呼側電話番号、関連する１つまたは複数のＶＸＭＬ呼処理スクリプト、ならびに指定されたＶＸＭＬ呼処理スクリプトによって必要とされ得るいずれのパラメータ・データをも含み得る。さらに、ＴＣＡＰ ＸＭＬスクリプトを実行することによって、後に判断される他のどんな情報もが、イベント・コンテキスト・キャッシュ内に書き込まれ得る。
ステップ４３５で、トランザクション・サービス・プロセッサは、ＴＣＰ／ＩＰ接続を介してトランザクション・セッション・マネージャに、少なくとも以下の情報、すなわちＤＮＩＳ、電話番号が登録されている電話サービスのＴＣＡＰ ＸＭＬ スクリプト実装を指定する１つまたは複数のＵＲＩ、ＴＣＡＰイベントが最初に割り当てられた先の特定のトランザクション・プロセッサを表す識別子、およびＴＣＡＰ識別子を送信することができる。図４には示されていないが、使用可能なパーサにＵＲＩを送信する前に、トランザクション・セッション・マネージャは、ＴＣＰ／ＩＰ接続を介してスクリプト・キャッシュ・メモリに問い合わせて、ＵＲＩによって指定されるＴＣＡＰ ＸＭＬスクリプトが、キャッシュ・メモリ内に含まれているかどうかを判断することができる。そうである場合、ＴＣＡＰ ＸＭＬスクリプトは、パーサによって既に構文解析されており、トランザクション・サービス・プロセッサによって実行することができる、中間フォーマットで存在する。したがって、構文解析されたＴＣＡＰ ＸＭＬスクリプトを、キャッシュ・メモリから取り出し、トランザクション・セッション・マネージャに提供することができ、それによって、ステップ４４０、４４５、４５０を飛ばして進み、ステップ４５５に続く。
ステップ４４０で、トランザクション・セッション・マネージャは、使用可能なパーサを識別し、ＴＣＰ／ＩＰ接続を介してパーサに、ＵＲＩを提供することができる。特に、トランザクション・セッション・マネージャは、トランザクション・プロセッサ識別子のローカル・コピーを保存することができる。ステップ４４５で、パーサは、ＵＲＩによって指定されるＴＣＡＰ ＸＭＬスクリプトを取り出すように求めるＨＴＴＰ要求を、ＨＴＴＰサーバに発行することができる。ＴＣＡＰ ＸＭＬスクリプトは、通話許可、通話阻止、通話転送、選択通話転送、電話会議システム、ならびにネットワーク・データベース照会を含めた他の機能などのサービスを実施することができる。ステップ４５０で、パーサは、ＨＴＴＰ接続を介して、要求したＴＣＡＰ ＸＭＬスクリプトを受信することができる。次いで、パーサは、ＴＣＡＰ ＸＭＬスクリプトを構文解析し、ＴＣＡＰ ＸＭＬスクリプトを、トランザクション・サービス・プロセッサによって解釈され実行され得る中間フォーマットに変換することができる。
ステップ４５５で、構文解析された呼処理スクリプトが、ＴＣＰ／ＩＰ接続を介して、パーサからトランザクション・セッション・マネージャに送信され得る。ステップ４５５で、トランザクション・プロセッサ識別子を保持しているセッション・マネージャは、ＴＣＡＰイベントの処理のため、元のＴＣＡＰイベントおよび受信された構文解析済みのＴＣＡＰ ＸＭＬスクリプトに関連する、トランザクション・サービス・プロセッサを識別することができる。ステップ４６０で、トランザクション・セッション・マネージャは、構文解析されたＴＣＡＰ ＸＭＬスクリプトを、識別されたトランザクション・サービス・プロセッサに送信することができる。したがって、トランザクション・サービス・プロセッサは、構文解析されたＴＣＡＰ ＸＭＬスクリプトを実行することによって、電話サービスを実施することができる。上述したように、ＴＣＡＰ ＸＭＬスクリプトを実行することによって、その後に判断される他のどんな情報をも、イベント・コンテキスト・キャッシュ内に書き込むこともできる。ステップ４６０の後、この方法は、次いで、円Ａに飛び、図５のステップ５０５に続く。
図５は、図３のシステムによって実施される呼処理の方法を示すフローチャートである。この方法は、図３の呼処理コンポーネントが、メディア・ゲートウェイの各チャネル・プロセッサについて、少なくとも１つのサービス・プロセッサをインスタンス化している状態で開始することができる。さらに、サービス・プロセッサおよびパーサが、トランザクション・セッション・マネージャに登録できるるように、ＶＸＭＬパーサなどの１つまたは複数のパーサが、インスタンス化され得る。特に、サービス・プロセッサとパーサの間に、１対１の対応関係がある必要はない。いずれにせよ、電話交換機が、呼を受信することができる。電話交換機は、メディア・ゲートウェイの空きチャネル・プロセッサを選択し、また呼の受付けのため、たとえば帯域内シグナリングまたはＩＳＤＮのＤチャネルを使用して、メディア・ゲートウェイに問い合わせすることができる。メディア・ゲートウェイが呼を受け付けたことに応答して、電話交換機は、選択されたチャネル・プロセッサに、呼を向けることができる。したがって、ステップ５０５で、たとえば、トランザクション処理コンポーネント内で受信されたＴＣＡＰイベントによって開始された呼転送の結果として、呼が、メディア・ゲートウェイによって受信され得る。ステップ５１０で、受信された呼のＤＮＩＳおよび被呼側電話番号が判断され得る。
ステップ５１５で、受信された呼について、イベント・コンテキスト・キャッシュ内にエントリが存在するかどうかが判断され得る。たとえば、イベント・コンテキスト・キャッシュ内のエントリは、ハッシュ・テーブルを使用して格納され得る。したがって、受信された呼のＤＮＩＳおよび被呼側電話番号を使用して、受信された呼についてのエントリを見つけるためのハッシュ・キーを判断することができる。イベント・コンテキスト・キャッシュ内に、エントリが存在しない場合、この方法は、ステップ５２０に続き、回復手順が実施され得る。上述したように、回復手順には、発呼側へのメッセージの再生、呼の廃棄、ＤＮＩＳに関連する既定のボイス・メール・アドレスへの呼の転送が含まれ得る。回復手順が実施された後に、この方法は、終了することができる。
受信された呼についてのエントリが、イベント・コンテキスト・キャッシュ内に存在する場合、この方法は、ステップ５２５に進み得る。ステップ５２５で、イベント・コンテキスト・キャッシュのエントリによって指定される情報が、イベント・コンテキスト・キャッシュから取り出され得る。ステップ５３０で、ＤＮＩＳに関連する１つまたは複数の呼処理スクリプトが、識別され得る。たとえばＤＮＩＳおよび関連するＶＸＭＬスクリプトのリストに照会して、特定の呼処理スクリプト、すなわちＤＮＩＳが登録されている電話サービスのＶＸＭＬスクリプト表現を判断することができる。特に、ＤＮＩＳおよび関連するＶＸＭＬスクリプトのリストは、ＤＮＩＳ、またはイベント・コンテキスト・キャッシュのエントリによって指定される、電話番号を含めた他の情報を使用して検索され得る。たとえば、イベント・コンテキスト・キャッシュのエントリは、１つまたは複数のＶＸＭＬスクリプト、または実行されるＶＸＭＬスクリプトの位置を指定することができる。
ステップ５３５で、メディア・ゲートウェイは、ＴＣＰ／ＩＰ接続を介してセッション・マネージャに、以下の情報、すなわち被呼側の電話番号、電話番号が登録されている電話サービスの呼処理スクリプト表現を指定する、１つまたは複数のＵＲＩ、ならびに呼が受信された特定のチャネル・プロセッサを表す識別子を送信することができる。
図５には示されていないが、使用可能なパーサにＵＲＩを送信する前に、セッション・マネージャは、ＴＣＰ／ＩＰ接続を介してスクリプト・キャッシュ・メモリに問い合わせて、ＵＲＩによって指定される呼処理スクリプトが、キャッシュ・メモリ内に含まれているかどうかを判断することができる。そうである場合、呼処理スクリプトは、パーサによって既に構文解析されており、トランザクション・サービス・プロセッサによって実行することができる、中間フォーマットで存在する。したがって、構文解析された呼処理スクリプトを、キャッシュ・メモリから取り出し、セッション・マネージャに提供することができ、それによって、ステップ５４０、５４５、５５０を飛ばして進み、ステップ５５５に続く。
ステップ５４０で、セッション・マネージャは、使用可能なパーサを識別し、ＴＣＰ／ＩＰ接続を介してパーサに、ＵＲＩを提供することができる。特に、セッション・マネージャは、チャネル・プロセッサ識別子のローカル・コピーを保存することができる。ステップ５４５で、パーサは、ＵＲＩによって指定される呼処理スクリプトを取り出すように求めるＨＴＴＰ要求を、ＨＴＴＰサーバに発行することができる。呼処理スクリプトは、たとえば、ＶＸＭＬドキュメント、テキスト、スクリプトなどの音声マークアップ言語スクリプト、ならびに音声の選択された部分を含み得る。パーサは、ＨＴＴＰ接続を介して、要求した呼処理スクリプトを受信することができる。したがって、次いで、ステップ５５０で、パーサは、呼処理スクリプトを解析して、呼処理スクリプトを、サービス・プロセッサによって解釈され得る中間フォーマットに変換することができる。
ステップ５５５で、構文解析された呼処理スクリプトが、ＴＣＰ／ＩＰ接続を介して、パーサからセッション・マネージャに送信され得る。ステップ５６０で、チャネル・プロセッサ識別子を保持しているセッション・マネージャは、呼を受信したチャネル・プロセッサに関連するサービス・プロセッサ（スクリプト／Ｂｅａｎ）を識別することができる。ステップ５６５で、セッション・マネージャは、構文解析された呼処理スクリプトを、識別されたサービス・プロセッサに送信することができる。したがって、ステップ５７０で、サービス・プロセッサは、構文解析された呼処理スクリプトを実行することによって、電話サービスを実施することができる。サービス・プロセッサは、Ｂｅａｎ／スクリプト・インターフェースを介して、メディア・ゲートウェイの音声プロセッサなど、電話サービスを実施するために必要などんな機能にもアクセスすることができる。
以下は、呼のルーティングのため、転送電話番号を要求するのに使用され得る例示的なＴＣＡＰ ＸＭＬスクリプトである。
<?xml version=1.0"?>
<txml version=1.0">
<catchevent="jain.protocol.ss7.tcap.component.InvokeIndEvent"
name="request">
<var name="number"
expr="Onlinecalendar.getForwardNumber(request.getDigits(
).new Date())" />
<object name="provider"
expr="request.getProvider()">/
<script>
<![CDATA[
provider.sendResults(number);
]]>
</script>
</catch>
</txml>
この例示的なＴＣＡＰ ＸＭＬスクリプトは、Ｌｏｔｕｓ Ｎｏｔｅｓ（商標）などのオンライン・カレンダ・アプリケーション内で指定された被呼者の番号の取出しに基づいて、通話を別の電話番号に転送することができるサービスを示している。オンライン・カレンダ・アプリケーションは、１日の様々な時間で、ある者にどこで連絡を取ることができるかを指定することができる。ＴＣＡＰ ＸＭＬスクリプトは、オンライン・カレンダ・アプリケーションに、転送電話番号を要求することができ、またＴＣＡＰフォーマットされたメッセージとして、その転送番号を返すことができる。換言すると、ＴＣＡＰ ＸＭＬスクリプトは、受信されたＴＣＡＰイベントを使用して、被呼側の番号および現在の日時に基づいて、カレンダ・アプリケーション内の現在アクティブな電話番号を調べることができる。次いで、ＴＣＡＰ ＸＭＬスクリプトは、要求からＴＣＡＰプロバイダを取得し、そのオブジェクトを使用して、結果を返すことができる。
イベント・コンテキストは、イベント・コンテキスト・キャッシュ内に書き込むことができる。上述したように、イベント・コンテキスト・キャッシュのエントリは、音声マークアップ言語スクリプト、スクリプトのパラメータ、ならびに所与の呼を処理するために実行される、１つまたは複数の音声マークアップ言語スクリプトを判断するために、呼処理コンポーネントによって使用され得るいずれの電話番号をも指示することができる。
本発明は、電話システム内の複数のサービス論理コンポーネントの間で、イベント・コンテキスト・データを共有するための解決策を提供する。呼処理とトランザクション処理などのサービス論理コンポーネント間のインターフェースとして働く、イベント・コンテキスト・キャッシュを提供することによって、本発明は、それぞれの電話サービス・コンポーネント内で、サービス間メッセージ・プロトコルの整合の取れた実装を行う必要をなくす。複数のサービス論理コンポーネント内で、整合の取れたサービス間メッセージ・プロトコルを作成し維持する必要を取り除くことに加えて、本発明は、大いに必要とされる電話コンピューティング・リソースをも解放し、それによって、電話サービスの開発、展開および維持のコストを削減する。
本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実現することができる。本発明は、１つのコンピュータ・システム内での集中方式でも、また様々な要素が、複数の相互接続されたコンピュータ・システムに渡って分散される分散方式でも実現することができる。本明細書で述べた方法を実施するように適応された、任意の種類のコンピュータ・システムまたは他の装置が適している。ハードウェアとソフトウェアの典型的な組合せは、ロードされ実行されるときに、コンピュータ・システムが本明細書で述べた方法を実施するようにそれを制御する、コンピュータ・プログラムを含む汎用コンピュータ・システムであり得る。
本発明は、本明細書で述べた方法の実施を可能にするすべての特徴を含み、またコンピュータ・システム内にロードされるときに、こうした方法を実施することができるコンピュータ・プログラム製品内に組み込むこともできる。コンピュータ・プログラムは、この文脈では、情報処理能力を有するシステムに、特定の機能を、直接に、あるいはａ）別の言語、コードまたは表記への変換、ｂ）別の材料の形での複製のいずれかまたは両方を行った後に実施させるための、１組の命令の任意の言語、コードまたは表記での任意の表現を意味する。
本発明の好ましい一実施形態による、２つのサービス論理コンポーネントの間に配置されたイベント・コンテキスト・キャッシュを示す概略図である。 本発明の好ましい一実施形態による、電話サービス・システムの呼処理コンポーネントとトランザクション処理コンポーネントの間に配置された、イベント・コンテキスト・キャッシュを示す概略図である。 本発明の好ましい一実施形態による、呼処理コンポーネントおよびトランザクション処理コンポーネントを含むシステムを示す概略図である。 本発明の好ましい一実施形態による、図３のシステムによって実施される、シグナリング・ネットワークから受信されたトランザクション・イベントを処理する方法を示すフローチャートである。 本発明の好ましい一実施形態による、図３のシステムによって実施される呼処理の方法を示すフローチャートである。

Claims (15)

  1. 電話システム内でシグナリング・イベント・データを共有するための方法であって、
    第１のサービス論理コンポーネント内で、電話シグナリング・ネットワークからイベントを受信すること、
    前記イベントについて、イベント・コンテキストを判断すること、および
    前記イベント・コンテキストを、前記第１サービス論理コンポーネントおよび少なくとも１つの第２のサービス論理コンポーネントに通信可能に接続された、イベント・コンテキスト・キャッシュ内に格納することを含む方法。
  2. 前記第１サービス論理コンポーネントが呼処理システムであり、前記第２サービス論理コンポーネントがトランザクション処理システムである、請求項１に記載の方法。
  3. 前記呼処理システムが、ＩＳＤＮインターフェースおよびＩＳＵＰインターフェースのうちの少なくとも１つを含み、前記トランザクション処理システムがＴＣＡＰインターフェースを含み、また前記電話シグナリング・ネットワークが共通線信号Ｎｏ．７ネットワークである、請求項２に記載の方法。
  4. 前記イベントがＴＣＡＰイベントであり、前記イベント・コンテキスト判断ステップがさらに、
    前記受信されたＴＣＡＰイベントから、ダイヤルされた番号の受信サービス、被呼側の電話番号、および実行される少なくとも１つの電話サービスを識別することを含む、請求項３に記載の方法。
  5. 後続のＴＣＡＰイベントを受信すること、
    前記後続のＴＣＡＰイベントのイベント・コンテキストが、前記イベント・コンテキスト・キャッシュ内に存在するかどうかを判断すること、および
    そうでない場合は、ダイヤルされた番号の受信サービス、被呼側の電話番号、および実行される少なくとも１つの電話サービスを指定する、前記後続のＴＣＡＰイベントのイベント・コンテキストを判断することおよび当該イベント・コンテキストを前記イベント・コンテキスト・キャッシュ内に格納することをさらに含む、請求項４に記載の方法。
  6. 転送された呼をどのように処理するかを判断するために、前記呼処理コンポーネントが前記イベント・コンテキスト・キャッシュにアクセスすることをさらに含む、請求項４に記載の方法。
  7. 前記イベント・コンテキスト判断ステップがさらに、
    呼を受信すること、
    前記受信された呼に関連するイベント・コンテキストが、前記イベント・コンテキスト・キャッシュ内に存在するかどうかを判断すること、
    そうである場合は、前記イベント・コンテキスト・キャッシュから前記イベント・コンテキストを取り出すこと、および
    そうでない場合は、呼回復機構を実行することを含む、請求項１に記載の方法。
  8. 前記判断ステップがさらに、
    前記呼から、ダイヤルされた番号の受信サービス、被呼側の電話番号を識別すること、および
    前記ダイヤルされた番号の受信サービス、および前記被呼側の電話番号に従って、前記イベント・コンテキスト・キャッシュを検索することを含む、請求項７に記載の方法。
  9. 前記取出しステップがさらに、
    前記受信された呼を処理するために実行される、音声マークアップ言語スクリプトの位置を識別することを含む、請求項８に記載の方法。
  10. 前記識別ステップがさらに、
    前記イベント・コンテキストによって指定される属性を識別することを含み、前記属性は、実行時に前記音声マークアップ言語スクリプトに提供される、請求項９に記載の方法。
  11. 第１のサービス論理コンポーネントと、
    第２のサービス論理コンポーネントと、
    前記第１サービス論理コンポーネントと前記第２サービス論理コンポーネントを通信可能にリンクする、イベント・コンテキスト・キャッシュとを含む電話システム。
  12. 前記イベント・コンテキスト・キャッシュが、サービス間メッセージング・プロトコルを使用せずに、前記第１サービス論理コンポーネントと前記第２サービス論理コンポーネントの間の情報交換を実現する、請求項１１に記載のシステム。
  13. 前記第１サービス論理コンポーネントが呼処理システムであり、前記第２サービス論理コンポーネントがトランザクション処理システムである、請求項１２に記載のシステム。
  14. 前記呼処理システムがＩＳＵＰイベントを処理するように構成され、前記トランザクション処理システムがＴＣＡＰイベントを処理するように構成される、請求項１３に記載のシステム。
  15. コンピュータ上で実行されるときに、請求項１ないし１０のいずれか一項に記載のステップを実施するためのソフトウエア・コード部分を含む、デジタル・コンピュータの内部メモリ内に直接ロード可能なコンピュータ・プログラム製品。
JP2004514362A 2002-06-14 2003-06-11 シグナリング・イベントのためのサービス論理コンテキスト・キャッシュ Expired - Fee Related JP4238212B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/172,410 US7130408B2 (en) 2002-06-14 2002-06-14 Service logic context cache for signaling events
PCT/GB2003/002518 WO2003107691A1 (en) 2002-06-14 2003-06-11 Service logic context cache for signaling events

Publications (2)

Publication Number Publication Date
JP2005536085A true JP2005536085A (ja) 2005-11-24
JP4238212B2 JP4238212B2 (ja) 2009-03-18

Family

ID=29733050

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004514362A Expired - Fee Related JP4238212B2 (ja) 2002-06-14 2003-06-11 シグナリング・イベントのためのサービス論理コンテキスト・キャッシュ

Country Status (5)

Country Link
US (1) US7130408B2 (ja)
JP (1) JP4238212B2 (ja)
CN (1) CN1706204B (ja)
AU (1) AU2003232365A1 (ja)
WO (1) WO2003107691A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7257215B2 (en) * 2002-08-16 2007-08-14 Siemens Aktiengesellschaft Load sharing in SS7 networks
US20050229048A1 (en) * 2004-03-30 2005-10-13 International Business Machines Corporation Caching operational code in a voice markup interpreter
US20070168872A1 (en) * 2006-01-19 2007-07-19 Raytheon Company Multi-monitor, multi-JVM java GUI infrastructure with layout via XML
US20080159515A1 (en) * 2006-12-29 2008-07-03 Rines Clark C Communication system for remotely updating a registered user's status
CN103440279A (zh) * 2013-08-13 2013-12-11 江苏华大天益电力科技有限公司 一种数据采集过程中的数据适配器及其数据适配方法
CN106155794B (zh) * 2016-07-21 2019-11-19 浙江大华技术股份有限公司 一种应用于多线程系统中的事件分配方法及装置

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5572583A (en) * 1992-04-17 1996-11-05 Bell Atlantic Advanced intelligent network with intelligent peripherals interfaced to the integrated services control point
DE59305284D1 (de) 1992-08-25 1997-03-06 Siemens Ag Call-processing-system zur steuerung von verbindungen in einem vermittlungssystem
US5590181A (en) 1993-10-15 1996-12-31 Link Usa Corporation Call-processing system and method
US5721729A (en) 1996-01-24 1998-02-24 Klingman; Edwin E. Universal input call processing system
US6047308A (en) 1996-07-25 2000-04-04 Cisco Technology, Inc. Modem with integrated control processor and digital signal processor sessions
US6101242A (en) * 1997-03-28 2000-08-08 Bell Atlantic Network Services, Inc. Monitoring for key words with SIV to validate home incarceration
CN1097931C (zh) * 1997-07-04 2003-01-01 华为技术有限公司 Stp机的sccp控制处理方法
US6047061A (en) 1997-12-23 2000-04-04 Alcatel Usa Sourcing Lp Routing call processing communications in a telecommunications system
FI107857B (fi) * 1998-07-06 2001-10-15 Ericsson Telefon Ab L M Signalointi telekommunikaatioverkossa
FI990348A (fi) * 1999-02-18 2000-08-19 Ericsson Telefon Ab L M Reititys telekommunikaatioverkossa
AU2001253043A1 (en) 2000-03-31 2001-10-15 Coppercom, Inc. Telecommunications system and methods

Also Published As

Publication number Publication date
CN1706204B (zh) 2010-05-26
CN1706204A (zh) 2005-12-07
AU2003232365A1 (en) 2003-12-31
WO2003107691A1 (en) 2003-12-24
JP4238212B2 (ja) 2009-03-18
US7130408B2 (en) 2006-10-31
US20030231756A1 (en) 2003-12-18

Similar Documents

Publication Publication Date Title
US7496054B2 (en) Networked computer telephony system driven by web-based applications
US7212623B2 (en) Method for telecommunications service-to-service asynchronous communications using a context cache
AU2008288853B2 (en) Dynamic routing of telephone calls to one out of a plurality of computer telephony servers comprising premises- and network-based servers
US20110282672A1 (en) Distributed voice browser
US20070036315A1 (en) Platform for rapid development of telecommunication services
US7266182B2 (en) Method and system for implementing a telephony services feature using voice XML
JP4238212B2 (ja) シグナリング・イベントのためのサービス論理コンテキスト・キャッシュ
US7085821B2 (en) TCAP event processing environment
US6791971B1 (en) Method and apparatus for providing a communications service, for communication and for extending packet network functionality
CA2486435A1 (en) Voice browser with integrated tcap and isup interfaces
US20030103493A1 (en) Terminal supervising device
MXPA00005961A (en) Architecture independent application invocation over a telephony network

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060606

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080220

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080226

RD12 Notification of acceptance of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7432

Effective date: 20080317

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20080317

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080523

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20081209

RD14 Notification of resignation of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7434

Effective date: 20081209

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20081219

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111226

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees