JP4874242B2 - 強化されたボイスメールシステム - Google Patents

Description

関連出願の相互参照
［０００１］
本出願は、参照することにより全体として本出願に組み込まれる、同時係属の米国仮出願、名称「ＶＸＭＬベース電話サービスシステム」、出願番号６０／５８４，４４４、出願日２００４年６月３０日、に対する優先権を主張する。

［０００２］
本出願は、参照することにより全体として本出願に組み込まれる、同時係属の米国特許出願、名称「電気通信システム用分散ＩＰアーキテクチャ」、出願日２００５年３月１５日、代理人事件整理番号０７００１．１０１０、に関連する。

技術分野
［０００３］
本発明は、電気通信システムに関し、より詳細には、ボイスメール等のサービスを提供する、強化されたＶＸＭＬベースの通信サービス提供システムに関する。

発明の背景
［０００４］
過去数十年間、通信産業は拡大を続け、著しい技術的成長を経験し続けた。最近の通信技術によって提供されるサービスの中で最も普及しているものの１つは、ボイスメールである。ボイスメールは、拡大と、殆どの企業の経営を成功させる重要な要素としての地位の確立を続けてきた。典型的な今日のボイスメールシステムは、さまざまな形態を取ることができ、その中には、企業電話システムに接続されたパーソナルコンピュータ内で動作できるコンピュータカード、又は、企業電話システム内に若しくは通信会社が提供するサービスとして直接統合されたコンピュータカードやコンピュータコンポーネント、が含まれる。

［０００５］
今日のボイスメールシステムのほとんどは、非常に複雑であり、一般にソフトウエアプログラミングに大きく依存している。これらのシステムは、単一のプラットフォームすなわちコンピュータ装置上で通常実行される、何千行ものコードを含んでいる。これらのボイスメール製品は、一般に高スキルのソフトウエアプログラマーとハードウエア開発者のチームによる多大な努力の結果として開発されるものであり、通常、ボイスメール製品を一つ発表するにも、開発、試験、デバッグ、仕上げに多くの工数が必要である。

［０００６］
しかしながら、ニーズと微妙な差異が常に拡大している現在の多様な社会では、潜在顧客のすべてのニーズを満足させる単一のビジネスモデルを開発するのは、困難である。顧客の中には、自分たちのボイスメールシステムからの基本サービスパッケージを欲するものがいるだろうし、また他の顧客達は、自分たちのボイスメールシステムからの上級サービスパッケージを欲するかもしれない。従って、開発者達は多くの事業セクタを目指して製品を開発するか、ニッチ市場に深く進出することを試みるかを強いられる。時には開発者達は、より大きなマーケットシェアを獲得しようとして複数バージョンの製品を発売するであろう。これは、開発者達（主にサポート分野の）に対し新たな問題を引き起こす。販売された製品の変形種が増えれば増えるほど、会社のサポート基盤は顧客のニーズにこたえる為により複雑にならざるを得ない。

［０００７］
従って、ボイスメールシステムの監視、とりわけ課金目的及びシステム目的での監視が可能な通信サービスプラットフォームに対する、技術的なニーズが存在する。更に、現代の電話ネットワーク及びボイスメールシステムは極めて複雑である。従って、ボイスメールシステムの監視、とりわけシステム障害を知らせる警報に対するニーズが存在する。本発明は、そのような解決策を提供する。

発明の概要
［０００８］
本発明は、ＶＸＭＬ（Ｖｏｉｃｅ ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ページを用いる分散型ボイスメールシステムを含む。本発明の一態様は、ＶＸＭＬ標準の機能ベースに対する拡張を生み出す、ＶＸＭＬ強化である。このＶＸＭＬ強化は、課金記録の創出、警報の送信、及び統計の集計及び報告をする機能を提供する。本発明のこの態様は、そのようなサービスを提供する上で用いることができるコールタグを含んでいる。本発明は、どの機能が最も一般的に用いられているかや、ボイスメールシステムへのコール数などの追跡に用いることができる。

［０００９］
簡単に説明すると、アーキテクチャとしては、本分散型ボイスメールシステムの一実施形態は、とりわけ次のように実践される。電話網と通信するメディアサーバは、分散型ボイスメールシステムのボイスメールサービスを開始するように適合しており、且つ、ＶＸＭＬ（Ｖｏｉｃｅ ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ページの少なくとも第１の部分をレンダリングするように適応されている。メディアサーバと通信するアプリケーションサーバは、ＶＸＭＬページを生成し、メディアサーバにそのＶＸＭＬページを提供するように適応されている。上記ＸＶＭＬページにタグが組み込まれており、メディアサーバがそのタグを処理する。ボイスメールシステムの少なくとも一部を監視するボイスメールアカウント・モニタは、タグを処理するメディアサーバにより起動される。

［００１０］
本発明の実施形態は、ボイスメールサービスを提供するための提供方法として見ることも出来る。この点において、そのような方法の一実施形態は、とりわけ次のステップにより概略的にまとめることができる。すなわち、電話網から来てメディアサーバで受け取られる発呼者からの電話コールを受信し、ボイスメールサービスに対するメディアサーバからの要求をアプリケーションサーバにて受信し、前記要求の受信に応答して前記アプリケーションサーバにおいてＶＸＭＬ（Ｖｏｉｃｅ ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ページを生成し、ここで前記ＶＸＭＬページの１つの部分の中にタグが組み込まれており、少なくとも前記組み込まれたタグを有する前記ＶＸＭＬページの前記１つの部分を処理し、前記組み込まれたタグを有する前記ＶＸＭＬページの前記１つの部分の処理に応答して、前記分散型ボイスメールシステムの少なくとも１つの部分を監視するステップとである。

［００１１］
本発明の他の、システム、方法、特徴、及び利点は、以下の図面及び詳細な説明を調べることにより、当業者には明白になるであろう。そのような更なるシステム、方法、特徴、利点は、本説明の中に含まれ、本発明の範囲の中にあり、添付の請求項により保護されることが意図されている。

発明の詳細な説明
［００１７］
本発明は、通信機器（例えばＰＢＸやボイスメールシステムなど）に対し、次世代通信プラットフォームとも表現される分散型ＩＰアーキテクチャを提供する。本発明のアーキテクチャを利用することにより、通信機器のさまざまな機能性を多数の物理的コンポーネントで分担することができ、且つこれらの物理的コンポーネントを地理的に散在させることができる。各コンポーネントは、ＩＰネットワークへの独立したインターフェースを介して、必要に応じて互いに通信する。電話網に接続する上での複雑さは、単一のゲートウエーコンポーネントを通して対処され、単純化されたプロトコルが通信機器の残りのコンポーネント間の、又はゲートウエーコンポーネントを介して電話網への通信を行うために用いられる。

［００１８］
図で例示され且つ説明される機能性の分散はそれ自身新規の態様を有してはいるが、それは唯一の受容可能な配置ではなく、また本発明の態様は、より少ない又は多いコンポーネントを有し且つコンポーネント間での異なる機能性の配置を含むシステムの中に組み込むことが出来る、ということを理解するべきである。

［００１９］
ここで、図を参照し、本発明の機能のさまざまな態様を説明する。ここでは、いくつもの図にわたって同様の標識が同様の要素を示している。

［００２０］
図１は、例示的な次世代通信プラットフォーム１００のコンポーネント及び接続性を例示しているシステム図である。本発明の一態様は、特にボイスメール、コール転送、及び他の通信特徴などの通信サービスを提供する、通信機器用分散型ＩＰベースアーキテクチャである。この例示された実施形態では、次世代通信プラットフォーム１００は、分散型ＩＰアーキテクチャを有し、電話網１１０に接続される。電話網１１０は、とりわけ、無線電話網又は公衆交換電話網（ＰＳＴＮ）であってもよい。通信プラットフォーム１００は、１またはそれ以上のメディアサーバ（ＭＳ）１２０、１またはそれ以上のシステム管理ユニット（ＳＭＵ）１３０、１またはそれ以上のアプリケーションサーバ（ＡＳ）１４０、及び１またはそれ以上の中央データ・メッセージ・ストア（ＣＤＭＳ）１５０を有し、それらがネットワーク１６０によって接続されるように例示されている。通常、ネットワーク１６０はインターネットプロトコル（ＩＰ）ネットワークであり、このＩＰネットワーク上での通信が、技術的に良く知られているインターネットプロトコル（ＩＰ）に準拠するようになっている。

［００２１］
実施形態の中には、通信プラットフォーム１００の加入者が、ネットワーク１８０（一般的にはインターネット）を通してアプリケーションサーバ１４０と通信するコンピュータ１７０を介して、通信プラットフォーム１００にアクセスすることができるものがある。アプリケーションサーバ１４０は、コンピュータ１７０にウエブページを提供し、それらは一般的にブラウザ（図示せず）を用いて加入者に表示される。アプリケーションサーバは、加入者が見ることが出来るアカウント情報を有するウエブページを提供することができる。一般に、通信プラットフォーム１００の加入者は、通信プラットフォームにボイスメールアカウントを持つことが出来、さらに一部の実施形態では、その加入者はアプリケーションサーバ１４０に情報すなわち加入者カスタマイザを提供することにより、自分のボイスメールアカウントをカスタマイズすることができる。通常、上記加入者はアプリケーションサーバ１４０により提供されたウエブページのフィールドの中に情報を入れるかオプションを選択することにより、アプリケーションサーバ１４０に情報を提供することができる。

［００２２］
メディアサーバ１２０は、簡単に記述すると、通信プラットフォーム１００のコンポーネントからのＩＰを終端し、及び／又は電話網１１０からの回線交換トラフィックを終端する。メディアサーバ１２０はまた、トランキング及びコール制御に対しても関与する。

［００２３］
アプリケーションサーバ１４０は、とりわけ、多様なアプリケーションに対する動的ボイスＸＭＬ（ＶＸＭＬ）ページを生成する。アプリケーションサーバ１４０は、このＶＸＭＬページをメディアサーバ１２０に提供し、メディアサーバ１２０はそのＶＸＭＬページを全部又は部分的にレンダリングする。アプリケーションサーバ１４０はまた、加入者コンピュータ１７０に提供されたウエブページを通して、通信プラットフォーム１００への外部インターフェースを提供する。

［００２４］
ＳＭＵ１３０は、サービスプロバイダーが、集中型ウエブインターフェースから、加入者アカウントを提供及び維持し且つネットワーク要素を管理することを可能とする、管理ポータルである。

［００２５］
ＣＤＭＳ１５０は、音声メッセージ及び加入者記録の格納と、通知を含む特定のアプリケーション機能の管理を行う。一部の実施形態では、ＣＤＭＳ１５０は、以下に詳細を説明する加入者カスタマイザ及び加入者属性を格納する。

［００２６］
次世代通信プラットフォーム１００内の各コンポーネントは、独立して拡張可能であり、また独立してネットワーク１６０に相互接続される。従って、上記コンポーネントは地理的に分散することができ、しかしそれでもなお、ネットワーク１６０上で互いに通信できる限りは、単一の通信プラットフォームとして機能する。これは最先端の通信システムでも不可能な、本発明の重要な利点である。通信プラットフォーム１００のコンポーネントの中から選択したいくつかについて、以下により詳細に説明する。

メディアサーバ（ＭＳ）
［００２７］
ＭＳ１２０は、電話網１１０からの回線交換トラフィックを終端させる。ＭＳ１２０は、本プラットフォームアーキテクチャ内のコールの始動及び制御に関与する。ＭＳ１２０は、声、ＤＴＭＦフォーマット、又は他の信号発生理論のいずれかによるユーザからの入力を処理する（キーボード及びマウスのクリック入力をユーザから集めるウエブクライアントに酷似）。ＭＳ１２０は、ユーザにコンテンツを音声形式で提示する（ＰＣクライアント上でユーザに返される図形やテキスト表示とおおむね類似）。このクライアント／サーバ方法論は、新たなアプリケーションを迅速に創造すること、及びワールドワイドウェブ上で利用可能なコンテンツをすばやく活用することを可能とする。

［００２８］
ＭＳ１２０は、ＡＳ１４０に要求を出すことを通して、入ってくるコールを処理する。このアプリケーションサーバへの要求は、一般に、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）又は他のインターネット標準を、ＡＳ１４０に送信することによりなされる。ＡＳ１４０に提供される情報の中でも、とりわけＭＳ１２０は到着コールの電話番号、すなわちその到着コールの発信者によってダイアルされた電話番号を通常含む。

［００２９］
負荷バランサ（図示せず）が、ＭＳ１２０に届いたトラフィックを複数のＡＳ１４０の内の１つに導くことが好ましい。この機能性は、トラフィックが稼動中のサーバ間で確実に均等配分されるようにする。ＭＳ１２０は、ＮｅｔｓｃａｐｅのようなクライアントがＨＴＭＬユーザに成り代わってＰＣ上で働くのと非常に似たような態様で、エンドユーザに代わってボイスＸＭＬクライアントとして動作する。これらのメディアサーバは、ユーザに提示するためにボイスＸＭＬをレンダリングするブラウザ１２２を備えている。

［００３０］
ボイスＸＭＬは、音声の利用が可能なソフトウエアアプリケーションの開発のための、標準ベースの記述言語である。これは、開発者達が、会話ベースの電話アプリケーションを開発するにあたって、ウエブベース（ＨＴＭＬ）の開発専門技術を使用・活用することを意味する。

［００３１］
加えて、好ましい一実施形態の中では、メディアサーバ１２０は民生品（ＣＯＴＳ：ｃｏｍｍｅｒｃｉａｌ−ｏｆｆ−ｔｈｅ−ｓｈｅｌｆ）のハードウエア、ソフトウエアコンポーネントで組み立てられており、且つ通信事業者向け級のサーバである。電話に特有のアプリケーション用の電話インターフェース及びリソースボードも追加される。例えば、ファクシミリカードやソフトウエアがメディアサーバ１２０に付加され、ファクシミリターミネーションを管理する。

アプリケーションサーバ（ＡＳ）
［００３２］
次世代通信プラットフォームをモジュラー式に設計することにより、音声ダイアリング及び音声ナビゲーション、一元化された通信ソリーション、マルチメディアメッセージングサービス、プレゼンス及びアベイラビリティ管理などの強化サービスを展開するのが容易であるという、更なる利点がある。アプリケーションのプラットフォームへの追加は、標準アプリケーションサーバ１４０を共通プラットフォームに追加することにより達成される。

［００３３］
各アプリケーションサーバ１４０は、アプリケーションドキュメント、例えばボイスＸＭＬページ、ＨＴＭＬページ（これらに限定されず）などを生成する。通常、ＶＸＭＬページはメディアサーバ１２０からの要求に応答して生成され、ＨＴＭＬページは加入者コンピュータ１７０からの要求に応答して生成される。アプリケーションサーバ１４０は、ウエブアプリケーション基盤をバックエンドのデータ記憶装置（例えば、ＣＤＭＳ１５０）とのインターフェースを取るために利用し、ＶＸＭＬページを生成する。

［００３４］
ウエブアプリケーション基盤は全体として、プレゼンテーションの詳細記述（ＶＸＭＬ）からコアサービスのロジック（すなわちビジネスロジックの提供）を分離し、より伸張性のあるアプリケーションアーキテクチャを提供している。一実施形態では、アプリケーションサーバ１４０はＪａｖａ(登録商標)２エンタープライズ・エディション（Ｊ２ＥＥ）環境及びＪａｖａ(登録商標)サーバページ（ＪＳＰ）を用い、メディアサーバのための動的ＶＸＭＬページを生成する。これらのテクノロジーを結合することにより、ＳＡＬＴ（Ｓｐｅｅｃｈ Ａｐｐｌｉｃａｔｉｏｎ Ｌａｎｇｕａｇｅ Ｔａｇｓ）を迅速に組み込むことができ、その結果、ＷＡＰ、ＨＴＭＬ、ＸＨＴＭＬ、音声などのアプリケーション間での相互運用性（多面的な）が可能となる。これにより、エンドユーザが音声コマンドを介してデータを入力することと、ＷＡＰ又はＨＴＭＬを介してプレゼンテーションを受け取ることが、同時にできるようになる。

［００３５］
アプリケーションを容易に開発するための環境を作り出すために、アプリケーションサーバ１４０はＴｅｍｐｌａｔｅ＋ＪＳＰをサポートするのが好ましい。アプリケーションは、メッセージング機能にアクセスするために、ＡＰＩを用いてＪＳＰの中に組み込まれる。これらのＪＳＰは容易に変更が可能であり、アプリケーション動作の変更及び新たなアプリケーションの創出を極めて容易にする。

［００３６］
メディアサーバ１２０とアプリケーションサーバ１４０が連携することにより、加入者に提供される特性、ボイスメール機能、及びユーザインターフェースのカスタマイズが可能となる。一実施形態では、アプリケーションサーバ１４０は、加入者カスタマイザをＣＤＭＳ１５０から取得し、その加入者カスタマイザをＶＸＭＬページを生成する時に使用する。この加入者カスタマイザを用いて生成されたＶＸＭＬページは、その加入者に指定されたカスタム特性、ボイスメール機能、及びユーザインターフェースに相当する。例えば、或る加入者は、発信者に提供されるメニュー項目の順番を変えることにより、又は或るオプションなどの選択によって呼び出されたボイスメール機能を変更することにより、自身のボイスメールアカウントをカスタマイズしたいと思うかもしれない。

共通データベース及びメッセージ・ストア（ＣＤＭＳ）
［００３７］
図２を参照すると、ＣＤＭＳ１５０は、充分な格納容量を有し、通信プラットフォーム１００が多数の加入者にサービスを提供できるようにしている。ＣＤＭＳ１５０に格納されるものの中には、とりわけボイス／オーディオメッセージ２０２、加入者記録２０４、加入者アカウント情報２０６、アカウント属性２０８、及び加入者カスタマイザ２１０がある。いくつかの実施形態の中では、各加入者が彼ら自身のアカウント属性２０８を有し、また他の実施形態では、アカウント属性は複数の加入者で共有することができる。

［００３８］
ＣＤＭＳ１５０は好ましくは、十分に冗長なコンポーネントを備えて設計され、且つフォールトトレランスつまり即時のフェールオーバ及び回復のために、リフレクティブメモリ及びＲＡＩＤ（Ｉｎｄｅｐｅｎｄｅｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋ）技術が用いられる。このことにより、関連するハードウエア及びソフトウエアコンポーネントに対するファイブナインのアベイラビリティが保証される。基幹ディスクドライブ及びＲＡＩＤコントローラのコンポーネントは、「ホットスワップ可能」で、交換のためにシステムの電源を落とす必要が無いことが好ましい。このＣＤＭＳ１５０によって、性能低下つまりｅメール格納箇所の検索及びソートに伴う不必要なｅメール中心のデータベース機能性が排除され、ボイスメールの固有の特性に対する性能が最大限に発揮される。

［００３９］
ＣＤＭＳ１５０は、シェルフ式ｅメール格納システムの標準を用いることができる。このメッセージ・ストアは、アプリケーションに対してトランスペアレントにこのメッセージ・ストアを選択することを可能とする、Ｊａｖａ(登録商標)ミドルウエアを用いることにより抽象化され、利用できる最も効率的なストアにそれぞれのメッセージタイプを格納することを可能としている。

［００４０］
ボイス／オーディオメッセージ２０２は、発信者が或る加入者に対しボイスメールメッセージを残した時にＣＤＭＳ１５０上に格納される。ボイス／オーディオメッセージ２０２はまた、加入者間で送信及び又は転送されるボイス／オーディオメッセージを含んでいる。ボイス／オーディオメッセージ２０２は更に、発信者に対して再生されるその加入者の「挨拶」も含むことができる。

［００４１］
それぞれの加入者に対する記録は、その加入者のための加入者記録２０４の中に格納される。加入者記録の中に含まれる情報には、特定の時間間隔におけるコール及び／又はファックスの回数、保存されたメッセージの数、記録されたメッセージの数、取り出されていないメッセージの数が含まれるが、これらには限定されない。

［００４２］
加入者アカウント情報２０６には、加入者名、アカウントに対する電話番号、配布リスト、（複数の）転送電話番号、及び課金情報が含まれる。

［００４３］
アカウント属性２０８には、メディアサーバ１２０でレンダリングされるＶＸＭＬページのコンテンツの増補、変更、又は制御に用いるか、又はＶＸＭＬページがレンダリングされる際の様式とすることができる、属性が含まれている。アカウント属性２０８の限定的でない例の中には、アプリケーションサーバ１４０により生成されるＶＸＭＬページの中で用いられる言語を指定することができる言語インディケータ、テンポラルインディケータ、発信番号トリガ、市外局番トリガを含むものがある。テンポラルインディケータは、時刻や曜日などに基づき加入者のボイスメールアカウントを変更するために用いることができる。市外局番トリガは、発信番号の市外局番に基づき、加入者のボイスメールアカウントを変更するために用いることができる。発信番号トリガは、発信番号に基づき、加入者のアカウントを変更するために用いることができる。実施形態の中には、加入者がコンピュータ１７０を用いてアカウント属性を提供することができるものもあり、また一部の実施形態の中では、加入者は属性によってどの様に自分のボイスメールアカウントを変更するかを指定することができる。上で説明された属性は限定的な例ではなく、他の属性も同様に用いることができることを、念頭におくべきである。

［００４４］
加入者カスタマイザ２１０は、加入者がコンピュータ１７０を用いて提供することができる。加入者は、加入者カスタマイザを提供して、カスタマイズされたＶＸＭＬページを用意することができる。通常、加入者は、コンピュータ１７０を用いて通信プラットフォーム１００にアクセスすることにより、加入者カスタマイザ２１０を提供する。アプリケーションサーバ１４０は、コンピュータ１７０上のブラウザのウインドウに表示されるウエブページを、加入者に提供する。その後、加入者はカスタマイズ可能なオプションを選択することができる。例えば、ＶＸＭＬページ内の各メニュー表示に対し、加入者カスタマイザは、オプションが提示される順序、オプションの選択に関連して押されるキー、及び、例えばコールの送信、メッセージの転送、ＣＤＭＳ１５０内に格納されたメッセージの削除、ＣＤＭＳ１５０内に格納されたメッセージの削除、加入者の挨拶の変更等（但しこれらに限らず）のボイスメール機能、を規定するために用いることができる。

システム管理ユニット（ＳＭＵ）
［００４５］
ＳＭＵ１３０は、サービスプロバイダーに対し、全てのネットワーク要素を管理する集中点を提供して、リモートアクセス、保守、及びバックアップ機能性を提供する。ＳＭＵ１３０は、プロビジョニング、警告、報告、及び加入者マイグレーションのための単一インターフェースを提供する。ＳＭＵ１３０は、新規のエレメント及びアプリケーションを有する複数のシステムの統合及びカスタマイズを行い、急激なネットワークの成長とトラフィック量の激増に悩んでいる通信事業者に対し、運用サポート及びネットワーク管理機能を提供する。

ボイスメールオペレーション
［００４６］
図３を参照すると、先ずサービス要求３００がメディアサーバ１２０にて受信される。このサービス要求は、さまざまな形態を取ることができ、また、例えば（これに限らず）、着信コールボイスコール、コール転送、着信ファクシミリ、着信テキストメッセージ、又は電話システムやボイスメールシステムに特有の各種の着信又は発信サービスなどの、多様なサービスを意味することができる。例示された実施例の中では、サービス要求３００は加入者番号に対する着信コールの受信である。メディアサーバ１２０は、例えば（これに限らず）、自動番号識別（ＡＮＩ：Ａｕｔｏｍａｔｉｃ Ｎｕｍｂｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）及びダイアル番号認識番号サービス（ＤＮＩＳ：Ｄｉａｌｅｄ Ｎｕｍｂｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ Ｓｅｒｖｉｃｅ）などの機能を用いて、発信番号及びダイアルされた番号など（これに限らず）の情報を収集することができる。更に、メディアサーバ１２０は、トランキング・グループなどの他の情報も収集することもできる。

［００４７］
メディアサーバ１２０は、通信プラットフォーム１００のサービスを起動することにより、上記着信コールに応答する。このメディアサーバは、サービス起動メッセージ３１０をアプリケーションサーバ１４０に送信することにより前記サービスを起動する。一般的に、サービス起動メッセージ３１０はインターネットプロトコルに準拠している。サービス起動メッセージ３１０は、通常、コールされた番号のような情報を含んでいる。サービス起動メッセージ３１０はまた、どのような種類のサービスをメディアサーバが起動しているのかを判断するためにアプリケーションサーバ１４０が用いる、サービスタグ又は他の識別子を有している。例えば、一部の実施形態では、メディアサーバ１２０は前記着信コールがボイスコールなのか又はファクシミリ送信なのかを判断し、この着信コールの種類の判断に応答して、メディアサーバ１２０が適切なサービスタグをサービス起動メッセージ３１０の中に盛り込むようになっている。

［００４８］
サービス要求により、そのサービスを起動する操作は大きく変わるであろう。本実施例では、メディアサーバ１２０は、そのサービスを起動する時に呼び出される番号を有してもよい。典型的な一実施形態では、メディアサーバ１２０は、アプリケーションサーバ１４０にＵＲＬを送信することにより上記要求を起動する。これは、典型的なウエブ指向のブラウザが、ＨＴＭＬタイプのページのロードを要求する時の動作と類似している。この場合、メディアサーバ１２０は、アプリケーションサーバ１４０から特定のＶＸＭＬページを呼び出している。ＵＲＬをアプリケーションサーバ１４０に送信するプロセスは、基本的には、アプリケーションサーバ１４０に、ＶＸＭＬページをメディアサーバ１２０へ提供するよう指示する。一部の実施形態の中には，このＵＲＬがアプリケーションに対しデフォルトのＶＸＭＬページを提供するよう指示するものもある。

［００４９］
アプリケーションサーバ１４０は、サービス起動メッセージ３１０の中の情報を使い、ＣＤＭＳ１５０内に格納された加入者情報を調べることができる。アプリケーションサーバ１４０は、アプリケーションサーバクエリ３２０をＣＤＭＳ１５０に送信する。通常、アプリケーションサーバクエリ３２０は、サービス起動メッセージ３１０が持っている情報を含む。例えば、アプリケーションサーバ１５０は、コールされた番号を、そのコールされた番号が割り当てられた加入者に関連する加入者情報を入手するために用いることができる。

［００５０］
ＣＤＭＳ１５０は、応答３３０をアプリケーションサーバ１４０に送信する。応答３３０は、前記コールされた番号に関連するアカウント属性２０８の一部又は全て、及び／又は前記コールされた番号に関連する加入者カスタマイザ２１０の一部又は全てを含んでもよい。

［００５１］
アプリケーションサーバ１４０は、自身がＶＸＭＬページを生成する時に、アカウント属性２０８の一部又は全て及び／又は加入者カスタマイザ２１０の一部又は全てを使用する。通常、アプリケーションサーバ１４０は、一部のアカウント属性２０８（及び／又は加入者カスタマイザ２１０）を一部のＶＸＭＬページで用い、他のアカウント属性２０８（及び／又は加入者カスタマイザ２１０）を他のＶＸＭＬページに用いることができる。

［００５２］
このようにして、アプリケーションサーバ１４０は、ＶＸＭＬページ３４０をＣＤＭＳ１５０から提供された上記情報に基づき形成する。この機能を実行する中で、アプリケーションサーバ１４０は、ＶＸＭＬページ３４０にユーザ固有の又は他の特定のデータを挿入し、そのＶＸＭＬページ３４０をメディアサーバ１２０に渡す。

［００５３］
場合によっては、メディアサーバ１２０は、ＶＸＭＬページ３４０の全てを発信者にレンダリングし、またある場合には、メディアサーバは、ＶＸＭＬページ３４０の少なくとも１つの部分をレンダリングする。例示されている実施形態では、メディアサーバ１２０はＶＸＭＬページ３４０の部分３５０をレンダリングする。レンダリングされた部分３５０は、発信者に提供される。

［００５４］
一旦、レンダリングされた部分３５０が発信者に提供されると、発信者は更なる入力３６０をメディアサーバ１２０に提供しても良く、そしてメディアサーバ１２０は異なる方法で入力３６０に応答するかもしれない。例えば、メディアサーバ１２０は、ＶＸＭＬページ３４０の同じ部分３５０を提供することにより入力３６０に応答するかもしれないし、ＶＸＭＬページ３４０の別な部分をレンダリングすることにより入力３６０に応答するかもしれない。例えば、ＶＸＭＬページ３４０は、メニュー選択であっても良い。発信者がボタンを押すか可聴メッセージを出すことにより１つの選択をする（入力３６０を提供する）と、メディアサーバ１２０がＶＸＭＬページ３４０上の特定のフォーム（すなわち部分）に移動する。メディアサーバ１２０は、次に、その特定のフォームをレンダリングし、そのレンダリングした部分３７０を発信者に提供するであろう。代わりに、もし更なる入力３６０がメニュー項目の内の１つに一致しなかった場合は、メディアサーバ１２０はレンダリングされた部分３５０を再度提供するであろう。

［００５５］
場合によっては、入力３６０は、メディアサーバ１２０が要求３８０をアプリケーションサーバ１４０に送る原因になる場合がある。この要求は、通信プラットフォーム１００の新規のサービスに対するものでもよく、他のＶＸＭＬページに対するものでもよい。メディアサーバ１４０は、別のＶＸＭＬページ３９０をメディアサーバ１２０に送信することにより要求３８０に応答するが、この別のＶＸＭＬページ３９０は通信プラットフォーム１００の他のサービスに関連するものかも知れないし、ボイスメールサービスに関する他のページに関連するものかも知れない。

［００５６］
例えば、この発信者が前記コールされた番号に対する通信プラットフォームの加入者で、最初のＶＸＭＬページ３４０がその発信者のためのボイスメールサービスの起動に関するものだと仮定する。その場合、入力３５０がＣＤＭＳ１５０内に格納されたメッセージを取得するためのオプションだと仮定すると、次に第２のＶＸＭＬページ３９０がＣＤＭＳ１５０内に格納されたメッセージに関連する情報を運ぶことになるであろう。

［００５７］
このようにして、好都合なことに、ロードされたＶＸＭＬページ内のさまざまな箇所にジャンプするメディアサーバによって単純なやり方や動作で処理することができ、同時に、アプリケーションサーバからの追加のページを要求することにより複雑な機能を満足させることができる。

［００５８］
加えて、本発明のＶＸＭＬシステムは、膨大な数のさまざまな様式で運用され、あたかもそれが各ユーザすなわち発信者にとってカスタムシステムであるかのように見えるシステムを可能にさせるが、実際はシステムは全く変更する必要などなく、むしろただ単に特定のトリガメカニズム（例えば、市外局番、発信者ＩＤ、ＡＮＩ、時刻など）に関連した制御属性をプログラムし且つ使用してシステムを増補することができるのである。

ボイスメールモニタ
［００５９］
図４を参照するが、いくつかの実施形態では、ＶＸＭＬページ４００は、アプリケーションサーバ１４０によってそのＶＸＭＬページ４００の中に組み込まれたタグ４０２を有している。タグ４０２は、通常、オブジェクトタグ、ＪＳＰタグ、又は当業者に既知の他のタグである。一実施形態では、タグ４０２は、ＶＸＭＬページ４００を要求するメディアサーバ１２０に応答してＶＸＭＬページ４００の中に組み込まれる、ということに留意すべきである。他の実施形態では、アプリケーションサーバ１４０がタグ４０２をＶＸＭＬページ４００の中に盛り込むように指示される。場合によっては、ＳＭＵ１３０がアプリケーションサーバ１４０にＶＸＭＬページ４００の中に１またはそれ以上のタグを組み込むように指示し、また他の場合には、ＳＭＵ１３０がアプリケーションサーバ１４０に、ＶＸＭＬページ４００の中にタグを組み込まないように指示する。このようにして、実施形態の一部では、ＶＸＭＬページ４００へのタグの組み込みはオン／オフされる。

［００６０］
メディアサーバ１２０は、ＶＸＭＬページ４００をアプリケーションサーバ１４０から受信し、そのＶＸＭＬページ４００をブラウザ１２２に提供する。ブラウザ１２２は、ＶＸＭＬページ４００を処理及び／又はレンダリングする。ブラウザ１２２は、タグ４０２をＶＸＭＬページ４００の処理及び／又はレンダリングの最中に処理し、タグ４０２の処理に応答して、ブラウザ１２２はボイスメールアカウント・モニタ４０４を起動する。通常、ボイスメールアカウント・モニタ４０４は、ブラウザ１２２内で実行される。しかしながら、実施形態の中には、ボイスメールアカウント・モニタ４０４がブラウザ１２２の外で実行されるものがある。その場合、ブラウザ１２２はトリガ４０６を送り、その結果、ボイスメールアカウント・モニタ４０４が起動される。例えば、一実施形態では、メディアサーバ１２０はトリガ４６０をブラウザ１２２から受け、メディアサーバ１２０がボイスメールアカウント・モニタ４０４を起動する。しかしながら、一部の実施形態では、ボイスメールアカウント・モニタ４０４は、例えばアプリケーションサーバ１４０やシステム管理ユニット１３０などのメディアサーバ１２０とは異なるコンポーネント上で実行され、その場合、そのコンポーネントがトリガ４０６をネットワーク１６０経由で受信してボイスメールアカウント・モニタ４０４を起動する。更に、一部の実施形態では、このボイスメールアカウント・モニタは通信プラットフォーム１００の複数のコンポーネント上で実行される。例えば、ボイスメールアカウント・モニタ４０４は、メディアサーバ１２０、アプリケーションサーバ１４０、及びシステム管理ユニット１３０上で実行されるサブモジュールを含むことができる。その結果として、一部の実施形態では、ブラウザ１２０はトリガ（又は複数のトリガ）を通信プラットフォーム１００の選択されたコンポーネントに送信し、その後その選択されたコンポーネントがボイスメールアカウント・モニタ４０４の各自のサブモジュールをそれぞれ起動する。単純にするために、ボイスメールアカウント・モニタ４０４はメディアサーバ１２０上で実行されるように記述されているが、これは限定しない例として意図されている。

［００６１］
いくつかの実施形態では、ボイスメールアカウント・モニタ４０４は、とりわけ警報を検出するためのロジックを含んでいる。典型的には、ボイスメールアカウント・モニタ４０４は、電話網１１０からの警報を検出するためのロジックを含んでいる。また、通常、ボイスメールアカウント・モニタ４０４は、検出された警報に対し消極的に又は積極的に応答するロジックを含んでいる。消極的応答には、通信プラットフォーム１００の１またはそれ以上のコンポーネントに警報通知を送信することが含まれている。例えば、警報を検出したことに応答してボイスメールアカウント・モニタ４０４は、アプリケーションサーバ１４０に警報通知を送信する。警報のタイプに基づき、通信プラットフォーム１００のコンポーネントは、単に警報通知を無視するか、積極的に反応する。検出された警報に対するボイスメールアカウント・モニタによる積極的応答の中には、コールを終了させることや、コールの転送をすることなどが含まれるが、これに限るものではない。例えば、もしボイスメールアカウント・モニタ４０４が警報を検出した場合、ボイスメールアカウント・モニタ４０４は、警報を持っていた着信コールに関連するサービスを終了させることにより、応答することができる。

［００６２］
一部の実施形態では、ボイスメールアカウント・モニタ４０４は、要求されたサービスに関連する及び／又は発信者に提供されるコンテンツに関連するデータを収集するロジックを含む。例えば、一実施形態では、ボイスメールアカウント・モニタ４０４はメディアサーバ１２０から要求されたサービスを表にし、各サービスに対して、それがメディアサーバ１２０により起動される回数をカウントする。もちろん、一部の実施形態では、ボイスメールアカウント・モニタ４０４は通信プラットフォームのサービスの内で選択されたものに対して表を作り、それらの選択されたサービスがメディアサーバ１２０により起動される回数をカウントすることができる。実施形態の中には、ボイスメールアカウント・モニタ４０４が、ブラウザ１２２に提供されるＶＸＭＬページのＵＲＬを用いて、データを一覧にするものもある。

［００６３］
他の実施形態では、ボイスメールアカウント・モニタ４０４は、特定のコンテンツがその発信者に提供される回数をカウントする。この場合、ボイスメールアカウント・モニタ４０４は、「フォーム」すなわちＶＸＭＬページ４００の一部分が、その発信者に提供される回数をカウントする。

［００６４］
コンテンツを表にすることに加え、ボイスメールアカウント・モニタ４０４は、とりわけ、ボイスメールシステムの特徴を表にし、且つそれらの特徴が呼び出される回数をカウントするためのロジックを含むことができる。例えば、ボイスメールアカウント・モニタ４０４は、ＣＤＭＳ１５０内に格納されたメッセージを通信プラットフォーム１００内の別の加入者に転送するメッセージ転送のようなボイスメール特徴を、加入者が呼び出す回数をカウントするロジックを含むことができる。

［００６５］
ボイスメールアカウント・モニタ４０４は、自らが集めたデータをＳＭＵ１３０に提供するようになっている。一部の実施形態では、ボイスメールアカウント・モニタ４０４は、着信コールが終了した時に、集めたデータをＳＭＵ１３０に提供する。他の実施形態では、ボイスメールアカウント・モニタ４０４は、ある期間に亘ってデータを蓄積し、あらかじめ定められた時点に蓄積されたデータをＳＭＵ１３０に提供する。

レポート生成部
［００６６］
図５を参照すると、システム管理ユニット１５０は、レポート生成部５０２を有している。レポート生成部５０２はデータ５０４をボイスメールアカウント・モニタ４０４から受け取る。レポート生成部５０２は、とりわけ、データ５０４の統計分析のためのロジックを含んでいる。レポート生成部５０２は、データ５０４を分析し、とりわけ通信プラットフォームの特徴が起動された相対的な頻度、通信プラットフォーム１００へのコール回数などを測定する。

［００６７］
いくつかの実施形態では、レポート生成部５０２は課金部５０６と通信している。課金部５０６は、レポート生成部５０２からのレポート５０８を使って、通信プラットフォーム１００の加入者にサービスに対して課金する。

［００６８］
本発明の上述の実施形態、特に「好ましい」又は「典型的な」実施形態のいずれもが、本発明の原理の明快な理解のためにのみ説明された単なる可能な実施例であることが、強調されなければならない。本発明の上述の（複数の）実施形態に対し、本発明の精神及び原理から実質的に離れることなく、多くの変形や変更が可能である。また、いかなる特定の実施形態も本発明の多様な態様の中の一部のみを含んでいるであろうことも、認識されるべきである。そのような変更及び変形は全て、この中の開示及び本発明の範囲内に含まれ、且つ以下の請求項により保護されるということが、意図されている。

電話網とやり取りする分散型ボイスメッセージングシステムの、典型的な実施形態を例示するブロック図である。 中央データ・メッセージ・ストアに格納されたコンテンツのブロック図である。 ボイスメールを実行するための典型的なフロー図である。 ボイスメールアカウント・モニタを有するメディアサーバのブロック図である。 レポート生成部を有するシステム管理ユニットのブロック図である。

Claims (20)

1. 分散型ボイスメールシステムであって、
   前記分散型ボイスメールシステムのボイスメールサービスを起動し、ＶＸＭＬ（Ｖｏｉｃｅ ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ページの少なくとも第１の部分をレンダリングするように適合しており、電話網と通信するメディアサーバと、
   ＶＸＭＬページを生成して、該ＶＸＭＬページを前記メディアサーバに提供するように適合しており、該ＶＸＭＬページの部分が該ＶＸＭＬページの中に組み込まれたタグを含む、前記メディアサーバと通信するアプリケーションサーバと、
   前記タグを処理する前記メディアサーバに応答して、前記ボイスメールシステムの少なくとも１つの部分を監視する、前記メディアサーバに設けられたボイスメールアカウント・モニタとを含む、分散型ボイスメールシステム。
2. 前記ボイスメールアカウント・モニタが、前記発信者による前記分散型ボイスメールシステムの利用に関連する情報を集める、請求項１に記載の分散型ボイスメールシステム。
3. 前記ボイスメールアカウント・モニタが、前記ＶＸＭＬページの少なくとも特定の部分がレンダリングされた回数を数えることによって情報を集める、請求項２に記載の分散型ボイスメールシステム。
4. 前記アプリケーションサーバが、少なくとも第２のＶＸＭＬページを生成し、該第２のＶＸＭＬページを前記メディアサーバに提供し、前記メディアサーバが前記第２のＶＸＭＬページの少なくとも特定の部分をレンダリングし、且つ前記ボイスメールアカウント・モニタが、前記第２のＶＸＭＬページの少なくとも前記特定の部分がレンダリングされた回数を計算することにより情報を集める、請求項２に記載の分散型ボイスメールシステム。
5. 前記アプリケーションサーバが、複数のＶＸＭＬページを生成して前記メディアサーバに提供するように適合し、且つ、前記ボイスメールアカウント・モニタが、該複数のＶＸＭＬページの少なくとも１つの部分がレンダリングされた回数を計算することにより情報を集める、請求項２に記載の分散型ボイスメールシステム。
6. 前記メディアサーバと通信するシステム管理ユニットを更に含み、該システム管理ユニットが、前記計算された前記複数のＶＸＭＬページの少なくとも１つの部分がレンダリングされた回数を用いて、ボイスメールシステム利用報告書を生成するように適合した、請求項５に記載の分散型ボイスメールシステム。
7. 前記メディアサーバと通信するシステム管理ユニットを更に含み、該システム管理ユニットが、前記集められた情報を用いて課金記録を生成するように適合した、請求項２に記載の分散型ボイスメールシステム。
8. 前記ボイスメールモニタリングシステムが、警報を検出し、警報通知を送信する、請求項１に記載の分散型ボイスメールシステム。
9. 前記タグが、外部ＶＸＭＬタグである、請求項１に記載の分散型ボイスメールシステム。
10. 前記タグが、ＪＳＰ（Ｊａｖａ(登録商標) Ｓｅｒｖｅｒ Ｐａｇｅ）ＶＸＭＬタグである、請求項１に記載の分散型ボイスメールシステム。
11. ボイスメールサービスを提供する方法であって、
    メディアサーバにおいて、電話網から受信される発呼者からの電話コールを受信するステップと、
    アプリケーションサーバにおいて、ボイスメールサービスに対する要求を前記メディアサーバから受信するステップと、
    前記要求の受信に応答して、前記アプリケーションサーバにおいてＶＸＭＬ（Ｖｏｉｃｅ ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ページを生成し、ここで該ＶＸＭＬページの１つの部分の中にタグが組み込まれているステップと、
    前記アプリケーションサーバにおいて、少なくとも前記組み込まれたタグを有する前記ＶＸＭＬページの前記部分を処理するステップと、
    前記メディアサーバに設けられたボイスメールアカウント・モニタにおいて、前記組み込まれたタグを有する前記ＶＸＭＬページの前記部分の処理に応答して、前記分散型ボイスメールシステムの少なくとも１つの部分を監視するステップとを含む、方法。
12. 前記監視するステップが、前記発呼者による前記分散型ボイスメールシステムの利用に関連する情報を収集することを含む、請求項１１に記載の方法。
13. 前記情報を収集するステップが、前記ＶＸＭＬページの少なくとも特定の部分が処理される回数を計算することを含む、請求項１２に記載の方法。
14. 前記アプリケーションサーバにおいて、少なくとも第２のＶＸＭＬページを生成するステップと
    前記第２のＶＸＭＬページを前記メディアサーバに提供するステップと、
    前記メディアサーバにおいて、前記第２のＶＸＭＬページの少なくとも特定の部分を処理するステップと、
    前記第２のＶＸＭＬページの少なくとも前記特定の部分がレンダリングされる回数を計算するステップとを更に含む、請求項１２に記載の方法。
15. 複数のＶＸＭＬページをメディアサーバに提供し、該複数のＶＸＭＬページが前記アプリケーションサーバにおいて生成されるステップと、
    前記複数のＶＸＭＬページの少なくとも１つの部分がレンダリングされる回数を計算するステップとを更に含む、請求項１２に記載の方法。
16. 前記計算された前記複数のＶＸＭＬページの少なくとも１つの部分がレンダリングされる回数を用いて、前記メディアサーバと通信するシステム管理ユニットが、ボイスメールシステム利用報告書を生成するステップを更に含む、請求項１５に記載の方法。
17. 前記メディアサーバと通信するシステム管理ユニットが、前記収集された情報を用いて課金記録を生成するステップを更に含む、請求項１２に記載の方法。
18. 前記メディアサーバにおいて警報を検出するステップと、
    前記メディアサーバから警報通知を送信するステップとを更に含む、請求項１１に記載の方法。
19. 前記タグが、外部ＶＸＭＬタグである、請求項１１に記載の方法。
20. 前記タグが、ＪＳＰ（Ｊａｖａ(登録商標) Ｓｅｒｖｅｒ Ｐａｇｅ）ＶＸＭＬタグである、請求項１１に記載の方法。

Images