JP2013218724A - 加入者にサービス混合を提供する方法およびネットワーク - Google Patents

Abstract

【課題】通信ネットワークの１つまたは複数のサービスおよびサーバブローカ機能を使用してネットワークと通信するＴＶ配信システムの１つまたは複数のサービスの加入者にサービス混合を提供するための方法および通信ネットワークの提供。
【解決手段】発呼者からメッセージを受信するとサービスブローカ機能は、発呼者の発呼者ＩＤ情報を取得し配信することを含むＴＶ配信システム加入のサービスに関連したサービスパッケージ情報を実行するように構成されることができる。サービスブローカ機能は、表示のためにＴＶ配信システムのアプリケーションに発呼者の発呼者ＩＤ情報を送信すると同時に、加入者の電話のアラートを変更するために加入者の電話に送信される変更されたメッセージ要求を生成するためにメッセージ要求内の情報を変更するように構成されることができる。
【選択図】図１

Description

本発明は概して、ネットワークおよびＴＶ配信システムの加入者にサービス混合を提供する通信ネットワークおよび方法に関する。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、ＩＥＴＦインターネットプロトコルに基づいて３ＧＰＰおよび３ＧＰＰ２規格および組織によって定義されるＩＰマルチメディアおよび電話コアネットワークである。３ＧＰＰ／ＩＭＳネットワークは、それがＧＳＭ／ＥＤＧＥ／ＵＭＴＳおよび他のパケットデータアプリケーションと共にＩＰ対ＩＰセッションオーバワイヤラインＩＰ、８０２．１１、８０２．１５、ＣＤＭＡ、パケットデータをサポートするのでアクセス独立型である。

３ＧＰＰ／ＩＭＳサービスアーキテクチャは、セッション確立プロトコル（ＳＩＰ）の自由度によって可能とされる広範囲のサービスをサポートする統合アーキテクチャである。ＳＩＰは、インターネット会議、電話、イベント通知およびインスタントメッセージング用のシグナリングプロトコルである。ＳＩＰは、インターネット技術タスクフォース（ＩＥＴＦ）のマルチパーティマルチメディアセッションコントロール作業部会内で開発された。ＳＩＰは、マルチキャスト会議などの既存のセッションに参加者を招くこともできる。メディアが既存のセッションに追加される（既存のセッションから除去される）ことができる。ＳＩＰは、名前マッピングおよび転送サービスをトランスペアレントにサポートし、それは個人のモビリティ、すなわち、ユーザがそれらのネットワーク位置にかかわらず単一の外部に見える識別子を維持することができることをサポートする。

ＩＭＳサービスインフラストラクチャへの投資を利用し、通信ネットワークおよびＴＶ配信システムへの加入者などの様々なプラットフォームのサービスの加入者に「混合した」サービスを提供することによって新しいサービス提供を行うことが望まれる。例えば、サービスプロバイダは、３ＧＰＰ／ＩＭＳネットワークおよびインターネットプロトコルテレビ（ＩＰＴＶ）などの他のプラットフォームまたはサービスインフラストラクチャの加入者に混合したサービス（例えば、電話、マルチキャスト、テレビ／ビデオなど）を提供することができることを望みうる。典型的にはＩＰＴＶサービスは、ユーザ／視聴者が発呼者ＩＤ情報、インスタントメッセージ、電子メール、またはショートメッセージサービス（ＳＭＳ）をＴＶ上に表示することができる能力を含む。

本発明の例示の実施形態は、通信ネットワークの１つまたは複数のサービスおよびサーバブローカ機能を使用してネットワークと通信するＴＶ配信システムの１つまたは複数のサービスの加入者にサービス混合を提供する方法および通信ネットワークに関する。発呼者からメッセージを受信するとサービスブローカ機能は、発呼者の発呼者ＩＤ情報を取得し配信することを含むＴＶ配信システム加入のサービスに関連したサービスパッケージ情報を実行するように構成されることができる。サービスブローカ機能は、表示のために発呼者の発呼者ＩＤ情報をＴＶ配信システムのアプリケーションに送信すると同時に、加入者の電話のアラートを変更するために加入者の電話に送信される変更されたメッセージ要求を生成するためにメッセージ要求内の情報を変更するように構成されることができる。

本発明の例示の実施形態は本明細書で下記に示された詳細な説明および添付図面からより完全に理解されることになり、添付図面では同様の要素は同様の参照番号によって表され、それらは単なる図として示され、したがって本発明の例示の実施形態を限定するものではない。

本発明の例示の実施形態によるＩＭＳサービスアーキテクチャの構成図である。 本発明の例示の実施形態による加入者にサービス混合を提供する方法を示す流れ図である。 通信ネットワークのサービスアーキテクチャおよびＴＶ配信システムのサービスアーキテクチャとの間の関係を示す図である。 通信ネットワークのサービスアーキテクチャおよびＴＶ配信システムのサービスアーキテクチャとの間の関係を示す図である。

例示の実施形態によれば、通信ネットワークのＩＭＳサービスアーキテクチャなどのサービス配信アーキテクチャおよびＩＰＴＶシステムなどのＴＶ配信システムのコンテンツストリーミングアーキテクチャなどの他のプラットフォームのサービスアーキテクチャが、加入者に混合したサービスを提供するために使用されることができる。

図１は、本発明の例示の実施形態によるＩＭＳサービスアーキテクチャの構成図である。サービス混合のための例示の方法およびシステムに関するコンテキストを提供するためにＩＭＳ通信ネットワーク用の例示のＩＭＳサービスアーキテクチャが下記で説明される。

図１に示されるように、３ＧＰＰ／ＩＭＳコアネットワークなどの通信ネットワークのＩＭＳサービスアーキテクチャ１００は、従来の電話サービスおよびインスタントメッセージング、プッシュツートーク、ビデオストリ―ミング、マルチメディアメッセージングなどの非電話サービスを提供する複数のアプリケーションサーバをサポートすることができる。サービスアーキテクチャ１００は、３つの層（トランスポートエンドポイント層１１０、セッション制御層１２０、およびアプリケーションサーバ層１３０）に分割されることができる論理機能の集合体である。

トランスポートエンドポイント層
トランスポートエンドポイント層１１０は、セッションを設定し、リアルタイムトランスポートプロトコル（ＲＴＰ）を使用してアナログ形式またはデジタル形式からＩＰパケットへの音声の変換などのベアラサービスを提供するためにＳＩＰシグナリングを開始し終了する。この層は、インターネットプロトコル（ＶｏＩＰ）ベアラストリームの音声をＰＳＴＮのＴＤＭ形式に変換するためのメディアゲートウェイを提供する。メディアサーバは、会議、アナウンスメントの再生、インバンドシグナリングトーンの収集、音声認識、音声合成などを含む多くのメディア関連サービスを提供する。

メディアサーバリソースはすべてのアプリケーションにわたって共用される。その結果、アナウンスメントの再生またはディジットの収集を必要とする各アプリケーションは、例えば共通のサーバを使用することができる。これらのアプリケーションは、特にボイスメール、アドバンスト８００インタラクティブＶｏｉｃｅＸＭＬ（ＶＸＭＬ）サービスを含む。メディアサーバは、プッシュツートーク（ＰＴＴ）サービス用メディアの複製などの非電話機能もサポートすることができる。複数のサービスにわたってメディアサーバの共通のプールを使用することによってサービスプロバイダは、アプリケーションごとにメディアリソースを予測し処理する必要がない。

セッション制御層
セッション制御層１２０は、適切なアプリケーションサーバにＳＩＰシグナリングメッセージのエンドポイントおよびルーティングの登録を行う呼セッション制御機能（ＣＳＣＦ）１２７を含む。したがって、（ＣＳＣＦ）１２７は、ＩＭＳ内でサービスにアクセスする加入者のためにセッション制御を提供するプロキシサーバである。ＣＳＣＦ１２７はＳＩＰサーバと呼ばれることもできる。

ＣＳＣＦ１２７は、すべてのサービスにわたってサービス品質（ＱｏＳ）を保証するためにトランスポートエンドポイント層１１０と相互動作する。セッション制御層１２０は、エンドユーザごとに固有のサービスプロフィールを維持するホーム加入者サーバ（ＨＳＳ）データベース１２６などのユーザデータベースと通信することができる。ＨＳＳ１２６は、セッション制御層１２０によってアクセス可能であり、例えば、ユーザプロフィールデータおよびまたは加入されたサービスに関してアプリケーションサーバ層１１０（点線）によってもアクセス可能である。エンドユーザのサービスプロフィールは、中央の位置にユーザサービス情報および好みのすべてを格納する。これは、エンドユーザの現在の登録情報（すなわちＩＰアドレス）、ローミング情報、電話サービス（すなわち呼転送情報）、インスタントメッセージングサービス情報（すなわち友達リスト）、ボイスメールボックスのオプション（すなわち、あいさつ）などを含む。この情報を集中化することによってアプリケーションは、統合された個人辞書、マルチクライアント型プレゼンス情報および混合サービスを生成するために情報を共用することができる。この集中化された構成はまた、ユーザデータの管理を大幅に簡略化し、すべてのサービスにわたってアクティブな加入者の一貫したビューを保証する。

セッション制御層１２０は、ＳＩＰシグナリングをメディアゲートウェイ（すなわち、Ｈ．２４８）によって使用されるシグナリングと相互動作するメディアゲートウェイ制御機能（ＭＧＣＦ）１２８を含む。ＭＧＣＦ１２８は、複数のメディアゲートウェイにわたってセッションの配信を管理する。メディアサーバ機能制御（ＭＳＦＣ）１２９はメディアサーバに対して類似の機能を提供する。

アプリケーションサーバ層
アプリケーションサーバ層１３０は、エンドユーザのサービス論理を提供するアプリケーションサーバを含む。アプリケーションサーバ層１３０は、ユーザプロフィールデータにアクセスするためにＨＳＳ１２６とも通信することができる。例示のサーブは、パーレイアプリケーションサーバおよびＳＩＰアプリケーションサーバを含む。ＩＭＳアーキテクチャおよびＳＩＰシグナリングは、様々な電話および非電話アプリケーションサーバをサポートするために自由度がある。例えば、ＳＩＰ規格は、電話サービスおよびインスタントメッセンジャ（ＩＭ）サービスのために開発された。

サービスブローカ
サービスの豊富なセットをサポートするためにＩＭＳアーキテクチャに対する拡張が望まれている。現在、ＳＩＰシグナリングをサポートしない多くのＶｏＩＰエンドポイントがある。例えば、典型的にはＩＰ−ＰＢＸはＨ．３２３を使用する。ＤＳＬを介してＶｏＩＰをサポートする統合アクセス装置（ＩＡＤ）はしばしばＭＧＣＰを使用する。その結果、ＩＭＳネットワーク内のこれらの一般的なエンドポイントをサポートするために非ＳＩＰシグナリングをＳＩＰと相互動作することが望ましい。新しい境界シグナリングゲートウェイはこの相互動作を提供するために提案された。

顧客は、シームレスな形で互いに動作するリアルタイム通信サービスを望む。これによってサービスプロバイダは、新しい混合した能力を提供するためにサービスを一括し相互動作することができる。例えば、長いＩＭセッション内のエンドユーザは、電話番号を調べ、個別の音声セッションを再確立することの面倒なしに音声セッションを生成することを望みうる。エンドユーザがＰＴＴセッションに従事しているとき、着信する音声呼はコールウェイティングサービスを求めるべきである。

標準的なＩＭＳサービスアーキテクチャは多くの異なるリアルタイム通信アプリケーションを同時にサポートすることができるが、追加のサービス相互動作またはサービスブローカリングがこれらの混合したサービスを提供するために必要とされうる。より拡張的な機能競合管理を可能にするためにＩＭＳ規格は、呼／接続制御と機能競合管理に適切なサービス層との間のサービス層のサブレイヤ内で機能を定義する。この機能は、「サービス協調競合マネジャ」（ＳＣＩＭ）と呼ばれる。ＳＣＩＭの正確な動作および能力は規格では定義されておらず、ＳＣＩＭが構成される手段も定義されていない。

その結果、例示の実施形態によれば、例示のＩＭＳサービスアーキテクチャ１００は、アプリケーション間でアプリケーション状態および状況情報を共用することができるサービスブローカ１２５（またはサービスブローカ機能）として本明細書で呼ばれるサービス能力競合マネジャ（ＳＣＩＭ）を含むことができる。サービスブローカ１２５は、セッション制御層１２０に存在し、相互動作アプリケーションへの対応するインターフェースを有する。したがって、サービスブローカ１２５は、重要なサービス提供に複数のアプリケーションを統合することなどの重要な機能を提供して、関与するアプリケーションが互いに知らないことが可能であり、サービスを結合するためにプログラマビリティにアプリケーションプログラミングインターフェース（ＡＰＩ）を提供する。

サービスブローカ１２５の内部の構成および機能のより詳細な説明について、同時係属で本願の譲受人に譲渡され、２００５年９月２０日に出願された、Ｋｏｃａｎらの「ＥＮＨＡＮＣＥＤ ＳＹＳＴＥＭ ＦＯＲ ＣＯＮＴＲＯＬＬＩＮＧ ＳＥＲＶＩＣＥ ＩＮＴＥＲＡＣＴＩＯＮ ＡＮＤ ＦＯＲ ＰＲＯＶＩＤＩＮＧ ＢＬＥＮＤＩＮＧ ＯＦ ＳＥＲＶＩＣＥＳ」と題する米国特許出願第１１／２３１１６６号明細書を参照することができ、その全体の内容は、本明細書で参照することによってここに組み込まれている。

ＩＭＳアーキテクチャは無線、有線、および融合されたネットワークに同様に適しているので、サービスブローカ１２５は、本来、それがエンドポイント／アクセスに中立であるときにＩＭＳアーキテクチャのこの態様と完全に一致している。サービスブローカ１２５は、サービス競合を制御するおよび／または豊富なエンドユーザの経験を提供するためにサービスの統合および協調を管理する。さらにサービスブローカ１２５は、アナログ、ソフトフォン、または無線電話などの様々なエンドポイントにまたぐことができるユーザに対応し、音声のみ、音声／データ、または音声／データ／マルチメディアなどのユーザのエンドポイント能力に基づいてサービス提示をカスタマイズすることができる。サービスブローカ１２５は、マルチセッション認識を実現し、同時および順次コンテキスト依存競合を管理するために可変のユーザデータおよびセッションコンテキストデータを保存し使用することができる。

したがって、「サービス混合」能力に加えてサービスブローカ１２５は、ＩＭＳアーキテクチャ内の他の要素がこの種の共用を提供することができるがメディアサーバの命令を傍受し、それらを選択されたメディアサーバ命令インターフェースに適合させることによって複数のアプリケーションにわたるメディアサーバなどのネットワークサービスを共用するために使用されることができる。さらにサービスブローカ１２５は、メンテナンスインフラストラクチャ内の他のシステムと共に課金および動作サポートシステムに関する情報ならびに通信ネットワーク内の他の要素に対する抽象化されたビューの統合をもたらすことができる。

図２は、本発明の例示の実施形態による加入者にサービス混合を提供する方法を示す流れ図である。概して、図２を参照して３ＧＰＰ／ＩＭＳなどの通信ネットワークおよびＩＰＴＶなどのＴＶ配信システムによって提供されるサービスの加入者は、サービス混合を利用するためにこれらの２つのプラットフォームのサービスアーキテクチャを使用することができる。したがって、図２では例示の方法（２００）で加入者の通信ネットワークは発呼者からメッセージ要求を受信する（２１０）。一例では、ネットワークは３ＧＰＰ／ＩＭＳネットワークであり、メッセージ要求は発呼者からのＳＩＰ ＩＮＶＩＴＥメッセージである。

ＳＩＰは、ＨＴＴＰのような要求／応答トランザクションモデルに基づいている。各トランザクションは、サーバ上で特定の方法または機能を求める要求および少なくとも１つの応答から成る。一例ではトランザクションは、「Ａｌｉｃｅの」ソフトフォン（ソフトフォンは、ユーザが自らのＰＣまたはラップトップから直接電話をかけることができるＶｏＩＰ技術に関連して動作するマルチメディアアプリケーションである）が「Ｂｏｂ」の統一資源識別子（ＵＲＩ）にアドレス指定されたメッセージ要求（ＳＩＰ−ＩＮＶＩＴＥ）を送信することで始まる。ＩＮＶＩＴＥ要求メッセージ（ＳＩＰ−ＩＮＶＩＴＥ）は、要求者（Ａｌｉｃｅ）はサーバ（Ｂｏｂ）がとって欲しい行動を規定するＳＩＰ方法の例である。

ＳＩＰ−ＩＮＶＩＴＥは、メッセージについての追加の情報を提供する属性を指定される複数のヘッダフィールドを含む。ＳＩＰ−ＩＮＶＩＴＥ内に存在するヘッダフィールドは、少なくとも呼に関する固有の識別子、宛先アドレス、Ａｌｉｃｅのアドレス、およびＡｌｉｃｅがＢｏｂと確立することを望むセッションの種類についての情報を含むことができる。

したがって、メッセージ要求は、通信ネットワーク内のサービスブローカ機能によって直接受信されることができる。一例では、セッション制御層１２０内のサービスブローカ１２５はメッセージ要求を受信することができる。他の例では、通信ネットワーク内のサーバは、発呼者からメッセージ要求を受信し、メッセージ要求を３ＧＰＰ／ＩＭＳネットワーク内のサービスブローカ機能に伝える。例えば、これは、図１でのＣＳＣＦ１２７などのＳＩＰプロキシサーバであってよい。

加入者がＴＶ配信システム上で発呼者ＩＤサービスの表示を含む混合したサービスに加入しているとき、サービスブローカ機能は、発呼者ＩＤ情報をＴＶ配信システムに提供するためにメッセージ要求に基づいてサービスパッケージ情報を実行することに加えて、メッセージ要求内の情報を変更または修正し（２２０）、変更されたメッセージ要求を加入者の電話に送信し（２３０）（直接またはプロキシサーバを介してのいずれか）、その結果、加入者の電話のアラートが変更され、発呼者の発呼者ＩＤ情報が加入者のＴＶ配信システム上に表示される。メッセージ要求がＳＩＰ−ＩＮＶＩＴＥとして具現化される場合、サービスブローカ機能は、加入者の電話のアラート（呼び出し、音、視覚的表示または他の方法で）を変えるためにＳＩＰ−ＩＮＶＩＴＥヘッダ内の「Ａｌｅｒｔ Ｉｎｆｏ」ヘッダフィールドを変更する能力を有する。サービスブローカ機能がＡｌｅｒｔ Ｉｎｆｏヘッダフィールドを「０」に設定する例では、加入者によって見られるプログラムの音を妨害しないように加入者の電話でのアラートは抑制されることができ、発呼者ＩＤ情報は加入者のＴＶ配信システム上に表示されている。

したがって、サービスブローカ１２５などのサービスブローカ機能は、通信ネットワーク内でＳＣＩＭとして働き、ＴＶ配信システムのアーキテクチャなどの他のサービス配信アーキテクチャを使用するサービスを混合する能力を提供する。サービスブローカ１２５がプログラム可能な要素であり、ＡＰＩを有するとき、２つの例示のシナリオが、サービスブローカ１２５の能力およびエンドユーザの経験を豊かにするその可能性の範囲を伝達するために様々なサービスアーキテクチャ間の対応する関係に対して説明した。

図３Ａおよび３Ｂは、通信ネットワークのサービスアーキテクチャとＴＶ配信システムのサービスアーキテクチャとの間の関係を示す。この例では無線通信ネットワークは３ＧＰＰ／ＩＭＳコアネットワークであってよく、ＴＶ配信システムはＩＰＴＶシステムであってよく、例示の方法はサービス混合のためにＩＰＴＶ以外の他のプラットフォームに適用されることができることは理解されよう。図３Ａおよび３Ｂのそれぞれでは、ＩＰＴＶ配信システムのストリーミングアーキテクチャ部３００および通信ネットワークのＩＭＳ３５０のセッション制御層が示されている。

図１で上述されたように、ＩＭＳ３５０のセッション制御層はサーバ３５７と通信するサービスブローカ３５５を含み、サーバ３５７は、例えばＳＩＰサーバ（ＣＳＣＦ１２７）または他のプロキシサーバであってよい。サービスブローカ３５５は、加入者データベース３５６内に反映されるように加入者が加入したサービスに基づいてＩＰＴＶサービスパッケージ３５２を実行するように構成される。加入者データベース３５６はホーム加入者サーバ（ＨＳＳ）であってよく、ホーム加入者サーバは複数の物理的データベースであってよい。これは、加入者の数およびサポートされる必要があるサービスの範囲に依存する。ＨＳＳは、加入者によって行われる呼およびセッションのサポート、確立およびメンテナンスに関する変数および識別情報を保持する。サーバ３５７および／またはサービスブローカ３５５は、ＩＭＳに登録されたＷｉＦｉ／ＧＳＭ送受話器でありうる加入者の送受話器３０４および加入者の携帯電話３５４などのエンドポイントに対するインターフェースを有することができる。

ＩＰＴＶ側でのコンテンツストリーミングアーキテクチャ３００は、ＩＰＴＶ３１０で表示のためにＴＶストリームデータを処理することができ、ＴＶ制御データを処理するためにリモート制御またはブラウザインターフェースなどの加入者入力装置（図示せず）と通信するＩＰＴＶサーバ３０５を含む。ＩＰＴＶシステムは、ＩＰＴＶ３１０上に表示するための発呼者ＩＤデータを受け入れるためにＩＰＴＶサーバ３０５とサービスブローカ３５５との間のインターフェースをサポートすることができるか、またはできないかである。

したがって、アーキテクチャ間の関係の概要が説明され、２つのシナリオがサービスブローカの能力の範囲およびエンドユーザの経験を豊かにするその可能性の範囲を示すために説明される。これらのシナリオは２つの加入者（ＡｌｉｃｅおよびＢｏｂ）を含む。Ａｌｉｃｅは、ＩＰＴＶサービスを用いて発呼者ＩＤに任意選択の「サイレントアラート」を与える提供に加入している。Ｂｏｂは、ＶｏＩＰに加入しているが、ウィンドウのような環境をサポートすることができるセットトップボックスを使用する独立したＩＰＴＶ配信システムを有する。Ｂｏｂは、発呼者ＩＤに任意選択の「サイレントアラート」およびＴＶリモート制御装置から呼処理を制御する能力を与える提供に加入している。

ＩＰＴＶに関する発呼者ＩＤおよび変更されたアラート（シナリオ１）
このシナリオではＡｌｉｃｅのＩＰＴＶ配信システムは、発呼者ＩＤを受け入れ、発呼者ＩＤをユーザの（Ａｌｉｃｅの）ＴＶ上に表示する通信システムまたはネットワーク（例えば、ＩＭＳ３５０）に対するインターフェースをサポートする。さらにＩＰＴＶのセットトップボックス（図３Ａには図示せず）は、ブラウザ能力（ブラウザウィンドウ３１５を参照）などのアプリケーションをサポートし、それによってユーザは要望に応じてリンク上をクリックすることができる。ＩＭＳ３５０は、サービスブローカリングを開始し終了することを行うことができるサービスブローカ３５５を含む。サービスブローカ３５５は、Ａｌｉｃｅの自宅電話３０４（ＳＩＰをサポートし、ＳＩＰ電話とも呼ばれうる）に対する呼を終了するとき、およびＡｌｉｃｅのＷｉＦｉ／ＧＳＭ送受話器（モバイル電話）３５４（すなわち携帯電話）がＩＭＳ３５０内に登録されているときにＡｌｉｃｅのＷｉＦｉ／ＧＳＭ送受話器に対する呼を終了するとき、ＩＰＴＶサーバ３０５で発呼者ＩＤ情報をＩＰＴＶアプリケーションに提供する。サービスブローカ３５５は、終端装置に送信されるＳＩＰ ＩＮＶＩＴＥ内のＡｌｅｒｔ Ｉｎｆｏヘッダフィールドを変更することによってこれらの電話での通常のアラート（例えば、呼び出し）を変更するまたは抑制することができる。シナリオは、図３Ａを参照して下記でより詳細に説明される。アラートを完全に抑制することの代替として、Ａｌｅｒｔ Ｉｎｆｏヘッダは「ピング」または他の煩雑でないアラートをもたらすように設定されることができる。

Ａｌｉｃｅは、リラックスしＴＶを観ている。呼が入電するが、Ａｌｉｃｅは、彼女が発呼者ＩＤサービスに加入しているので呼が誰からであるかをＴＶセット上で理解することができる。Ａｌｉｃｅは、この例では彼女の電話がアラートすることを防ぐ「サイレントアラート」と呼ばれうる変更されたアラート機能をアクティブ化することもできる。Ａｌｉｃｅは、彼女が自宅にいるときにＡｌｉｃｅのＧＳＭ／ＷｉＦｉ携帯電話３５４がＩＭＳ３５０に登録されているのでＡｌｉｃｅのＧＳＭ／ＷｉＦｉ携帯電話３５４上のＡｌｉｃｅに連絡を取ろうとしている人さえも理解することができる。

Ａｌｉｃｅは、彼女のＴＶ３１０をオンにし、ＳＴＢ（図３Ａには図示せず）を介して提供されるＩＰＴＶプログラムガイドからプログラムを選択する。呼がＡｌｉｃｅの自宅電話３０４に関するＩＭＳ内に入電する。Ａｌｉｃｅは混合したサービスに加入しているのでサーバ３５７は、ＳＩＰ ＩＮＶＩＴＥメッセージをサービスブローカ３５５に伝える。

キャッシュされない場合、サービスブローカ３５５は、Ａｌｉｃｅの終端サービスパッケージ情報を加入者データベース３５６（ＨＳＳなど）から取り出し、ＩＰＴＶサービスパッケージ３５２を実行することを始める。呼名がＳＩＰ ＩＮＶＩＴＥメッセージ内に封入されていない場合（それはＰＳＴＮから入電する呼に関してありうるので）、サービスブローカ３５５は、この情報を得るために呼名のウェブサーバ（図示せず）に照会することができる。

サービスブローカ３５５は、ＳＩＰ ＩＮＶＩＴＥメッセージをＡｌｉｃｅの自宅電話３０４にサーバ３５７を介して送信し、呼名の情報（発呼者ＩＤ情報３２０）をＩＰＴＶサーバ３０５でのＩＰＴＶアプリケーションにその禁止されたインターフェース上で送信する。あるいは、サーバ３５７が存在しない場合、サービスブローカ３５５はＳＩＰ ＩＮＶＩＴＥメッセージを直接受信するように構成されることができる。一例では、インターフェースが追加のテキストを可能にすると仮定するとサービスブローカ３５５は、サイレントアラートをアクティブ化する勧誘を含むことができる。

電話３０４が鳴り、Ａｌｉｃｅは、サイレントアラートをアクティブ化する勧誘と共にＴＶ３１０上で発呼者ＩＤを同時に理解する。プログラムが非常に面白く、呼が緊急でないのでＡｌｉｃｅは、電話３０４がボイスメールに切り替えられるまで電話３０４が鳴ることを可能にする。呼び出しが気を散らすのでＡｌｉｃｅは、彼女の画面上のブラウザウィンドウ３１５を呼び出し、サイレントアラートをアクティブ化するために彼女のお気に入り内のリンクをクリックする。サイレントアラートがプログラムの開始前にまたは既定のオプションとして設定されていることもできるので勧誘は必要がないことを留意されたい。

リンクをクリックすることによってＨＴＴＰ要求がサービスブローカ３５５に送信され、サービスブローカ３５５は、Ａｌｉｃｅが非アクティブ化時間を選択するまたは既定の非アクティブ化（２時間など）を有効にさせることができるウェブページを送信する。Ａｌｉｃｅは、彼女の所望の非アクティブ化時間を選択する。ウィンドウ３１５上で送信クリックはこの情報と共にＨＴＴＰ要求をサービスブローカ３５５に送信する。サービスブローカ３５５は、今後の呼のために使用されるように加入者データベース３５６上のＡｌｉｃｅのユーザデータ内に適切な情報を入力する。

他の呼がＡｌｉｃｅの自宅電話３０４に関するＩＭＳ内に入電し、サーバ３５７はＳＩＰ ＩＮＶＩＴＥメッセージをサービスブローカ３５５に伝える。

サービスブローカ３５５は、サイレントアラートがアクティブであることを現在示すＡｌｉｃｅの終端サービスパッケージ情報を加入者データベース３５６から取り出し、サービスパッケージ３５２を実行することを始める。呼名がＳＩＰ ＩＮＶＩＴＥメッセージ内に封入されていない場合、サービスブローカ３５５は、この情報を得るために呼名のウェブサーバに照会する。

サイレントアラートがアクティブであるとき、サービスブローカ３５５は、フィールドを変えるためにＳＩＰ ＩＮＶＩＴＥメッセージ内のＡｌｅｒｔ−Ｉｎｆｏを「０」に設定する。次いで、サービスブローカ３５５は、変更されたＳＩＰ ＩＮＶＩＴＥメッセージをＡｌｉｃｅの自宅電話にサーバ３５７を介して（またはサーバ３５７が存在しない場合には直接）送信し、発呼者ＩＤ情報３２０をサーバ３０５でのＩＰＴＶアプリケーションにその禁止されたインターフェース上で送信する。

ＡｌｉｃｅはＴＶ３１０上で発呼者ＩＤを理解するが、Ａｌｉｃｅの電話３０４が変更されたＳＩＰ ＩＮＶＩＴＥを受信し、アラートがないことを示す「０」に設定されたＡｌｅｒｔ−Ｉｎｆｏを解釈するので電話３０４は鳴らない。呼が緊急であり、したがってＡｌｉｃｅは電話３０４を取り、呼に応答する。

他の呼がＡｌｉｃｅに関するＩＭＳ３５０に入電するが、今回はそれが彼女のモバイル（ＧＳＭ／ＷｉＦｉ）電話３５４に対してである。Ａｌｉｃｅが彼女のモバイル電話３５４と共に自宅におり、彼女のモバイル電話がＩＭＳに登録されていたので呼はＩＭＳ３５０に入電した。サーバ３５７は、ＳＩＰ ＩＮＶＩＴＥメッセージをサービスブローカ３５５に伝える。あるいは、サーバ３５７が存在しない場合、サービスブローカ３５５はこのＳＩＰ ＩＮＶＩＴＥメッセージを直接受信するように構成されることができる。

前述のように、サービスブローカ３５５は、サイレントアラートがアクティブであることを現在示すＡｌｉｃｅの終端サービスパッケージ情報を加入者データベース３５６から取り出し、サービスパッケージ３５２を実行することを始める。前述のように、呼名がＳＩＰ ＩＮＶＩＴＥ内に封入されていない場合、サービスブローカ３５５は、この情報を得るために呼名のウェブサーバに照会することができる。

サイレントアラートがアクティブであるとき、サービスブローカ３５５は、ＳＩＰ ＩＮＶＩＴＥのヘッダフィールド内のＡｌｅｒｔ Ｉｎｆｏを「０」に設定する。次いで、サービスブローカ３５５は、変更されたＳＩＰ ＩＮＶＩＴＥをＡｌｉｃｅのモバイル電話３５４にサーバ３５７を介して送信し、発呼者ＩＤ情報３２０をサーバ３０５のＩＰＴＶアプリケーションにその禁止されたインターフェース上で送信する。インターフェースが追加のテキストを可能にすると仮定するとサービスブローカ３５５は、呼び出されているのはＡｌｉｃｅのモバイル電話３５４であることの表示を含む。

Ａｌｉｃｅは、呼び出されているのがＡｌｉｃｅのモバイル電話３５４であることの表示と共に発呼者ＩＤをＴＶ３１０上で理解するが、電話３５４が変更されたＳＩＰ ＩＮＶＩＴＥを受信し、アラートがないことを示す「０」に設定されたＡｌｅｒｔ−Ｉｎｆｏを解釈するので電話３５４は鳴らない。呼が緊急であり、したがってＡｌｉｃｅはモバイル電話３５４を取り、呼に応答する。いくつかのＧＳＭ／ＷｉＦｉローミングアーキテクチャの場合、他の例では自宅電話３０４は、モバイル３５４がＩＭＳ３５０に登録され、自宅に存在するとき、変更されたＳＩＰ ＩＮＶＩＴＥメッセージも受信することができる。

したがって、シナリオ１は、ＳＩＰ Ａｌｅｒｔ−Ｉｎｆｏヘッダを利用する変更されたアラート（サイレントアラート）を有するＴＶ発呼者ＩＤの混合したサービスを示す。この例示のシナリオではＳＩＰ ＶｏＩＰは、Ａｌｅｒｔ−Ｉｎｆｏ設定をサポートし正しく解釈するように設計され、サービスブローカ３５５は、それがそのＨＴＴＰインターフェースを介してユーザから得る情報に基づいてＡｌｅｒｔ−Ｉｎｆｏヘッダを変更する。この混合したサービスのさらなる機能は、呼に関する発呼者ＩＤおよびサイレントアラートをモバイル電話３５４に提供することである。これはＧＳＭ／ＷｉＦｉローミングを用いて可能であり、サービスブローカ３５５に呼がモバイル電話３５４に対してであることの表示を送信させている。

図３Ａに関して説明されたように、通信／セッションサービスに関するＩＭＳアーキテクチャおよびＩＰＴＶコンテンツストリーミングアーキテクチャの両方がこの混合したサービスに関与した。ＩＰアドレス（ＤＳＬを使用する）は両方のアーキテクチャによって共用される。サービスブローカ３５５は、ＳＣＩＭの役割を果たし、ＩＭＳ３５０からＩＰ ＴＶシステム３００にイベントデータを送信することによって２つのサービスアーキテクチャを混合するように働く。したがって、サービスブローカ３５５は、ユーザから特定のアクティブ化要求を受信し、特定のアプリケーション混合論理（アクティブ化情報を含む）に基づいてＳＩＰメッセージを変更するように構成される。

ＩＰＴＶに関する発呼者ＩＤおよび変更されたアラート（シナリオ２）
図３Ｂを参照すると、この場合にはＴＶ配信システム３００は、発呼者ＩＤに関する通信システム（ＩＭＳ３５０）に対するインターフェースをサポートしない。しかし、ＴＶリモート制御からイベント（例えば、イベントはキーストロークイベントにマッピングすることができる）を受信するようにフォーカスウィンドウを設定することができるアプリケーション（クライアントソフトウェア３２５）を実行することができるウィンドウのような環境を有するセットトップボックス３２０が使用される。ネットワークのＩＭＳ３５０内のサービスブローカ３５５は、ＴＶリモート制御イベントに応じてＳＴＢ３１８内のクライアントソフトウェア３２５と通信し、着信するＳＩＰ ＩＮＶＩＴＥメッセージを処理することができる。シナリオは、図３Ｂを参照して下記でより詳細に説明される。

Ｂｏｂは、リラックスしＴＶを観ている。呼が入電するが、Ｂｏｂは、呼が誰からであるかをＴＶセット３１０上で理解することができる。Ｂｏｂは、この例では彼の電話がアラートすることを防ぐ「サイレントアラート」と呼ばれうる変更されたアラート機能もアクティブ化することができ、Ｂｏｂは、彼のＴＶリモート制御（図３Ｂには図示せず）からボイスメールに呼を送信するまたは呼を止めることさえできる。

Ｂｏｂは彼のＴＶ３１０をオンにし、ＳＴＢ３１８を介して提供されるＩＰ ＴＶプログラムガイドからプログラムを選択する。呼がＢｏｂの自宅電話３０４に関するＩＭＳ３５０に入電する。Ｂｏｂは混合したサービスに加入しているのでサーバ３５７は、ＳＩＰ ＩＮＶＩＴＥをサービスブローカ３５５に伝える。あるいは、サービスブローカ３５５はこのＳＩＰ ＩＮＶＩＴＥメッセージを直接受信するように構成されることができる。サービスブローカ３５５は、Ｂｏｂの終端サービスパッケージ情報を加入者データベース３５６（キャッシュされない場合）から取り出し、サービスパッケージ３５２を実行することを始める。呼名がＳＩＰ ＩＮＶＩＴＥ内に封入されていない場合（それはＰＳＴＮから入電する呼に関してありうるので）、サービスブローカ３５５は、この情報を得るために呼名のウェブサーバに照会する。

サービスブローカ３５５は、ＳＩＰ ＩＮＶＩＴＥメッセージをＢｏｂの自宅電話３０４にサーバ３５７を介して送信し、発呼者ＩＤ情報３２０’をクライアントソフトウェアアプリケーション３２５にＢｏｂのＳＴＢ３１８上で送信する。電話３０４が鳴り、Ｂｏｂは、呼を拒否し、ボイスメールに呼を送信し、所与の期間にサイレントアラートをアクティブ化するためのクリック可能な（ＴＶリモート制御を介して）リンクと共に発呼者ＩＤをＴＶ上で同時に理解する。

プログラムが非常に面白く、呼が緊急でなかったので、Ｂｏｂは呼をボイスメールに送信するためにリンクをクリックする。呼び出しが気を散らしたのでＢｏｂは、サイレントアラートをアクティブ化するためにクリックもする。リンクをクリックすることによってＨＴＴＰ要求が、サービスブローカ３５５に送信される。サービスブローカ３５５は、ＳＩＰ ＩＮＶＩＴＥメッセージをボイスメッセージシステムに送信し、次いで今後の呼のために使用されるように加入者データベース３５６上のＢｏｂのユーザデータ内に適切な情報を転送する。

他の呼がＢｏｂの自宅電話３０４に関するＩＭＳに入電し、サーバ３５７は、ＳＩＰ ＩＮＶＩＴＥメッセージをサービスブローカ３５５に伝える。あるいは、サービスブローカ３５５は、ＳＩＰ ＩＮＶＩＴＥメッセージを直接受信するように構成されることができる。サービスブローカ３５５は、サイレントアラートがアクティブであることを現在示すＢｏｂの終端サービスパッケージ情報を加入者データベース３５６から取り出し、サービスパッケージ３５２を実行することを始める。呼名がＳＩＰ ＩＮＶＩＴＥ内に封入されていない場合、サービスブローカ３５５は、この情報を得るために呼名のウェブサーバに照会する。

サイレントアラートがアクティブであるとき、サービスブローカ３５５は、ＳＩＰ ＩＮＶＩＴＥ内のＡｌｅｒｔ−Ｉｎｆｏを「０」に設定する。次いで、サービスブローカ３５５は、変更されたＳＩＰ ＩＮＶＩＴＥメッセージをＢｏｂの自宅電話３０４にサーバ３５７を介して（またはサーバ３５７が存在しない場合には直接）送信し、発呼者ＩＤ情報３２０’をクライアントソフトウェアアプリケーション３２５にＢｏｂのＳＴＢ３１８上で送信する。

Ｂｏｂは発呼者ＩＤをＴＶ上で理解するが、Ｂｏｂの電話３０４が変更されたＳＩＰ ＩＮＶＩＴＥを受信し、アラートがないことを示す「０」に設定されたＡｌｅｒｔ−Ｉｎｆｏを解釈するので電話３０４は鳴らない。呼が緊急であり、したがってＢｏｂは電話３０４を取り、呼に応答する。

シナリオ２では、ＴＶ発呼者ＩＤサービスは、つまりＩＰ ＴＶクライアントソフトウェアアプリケーション３２５がウィンドウのような環境で動作することができ、ＳＴＢ３１８がウィンドウのような環境をサポートする限りＩＰ ＴＶ配信システムの独立性を可能にする。このバージョンを用いて追加された能力は、呼の処理に影響を与えるためにＴＶリモートイベントを受信し、ＨＴＴＰメッセージをサービスブローカ３５５に送信するクライアントソフトウェア３２５に基づいていてよい。さらに、より高度な能力は、ＳＴＢ３１８上でのクライアントソフトウェア３２５がＡＰＩを提供する場合に可能でありえ、その結果、サービスブローカ３５５と競合するソフトウェアクライアントはより完全な情報を有することができる。一例は、どのようなプログラムが観られているかを示している可能性がある。このような場合、親のアラートおよび制御能力（着呼および発呼に関して説明されるなど）がある種のプログラムに対して実装されることができる。

したがって、本発明の例示の実施形態が説明されているが、同一のことが多くの方法で変えられることができることは明らかである。この種の変形形態は、本発明の例示の実施形態の精神および範囲から逸脱するものと見なされず、当業者に明らかであるようなすべての変更形態は、添付の特許請求の範囲内に含まれるものである。

Claims (10)

1. 通信ネットワーク（３５０）の１つまたは複数のサービスおよびネットワークと通信するＴＶ配信システム（３００、３０５、３１０）の１つまたは複数のサービスの加入者にサービス混合を提供する方法であって、
   発呼者からメッセージ要求（２１０）を受信することと、
   変更されたメッセージ要求を生成するためにメッセージ要求（２２０）内の情報を変更することと、
   加入者の電話（３０４、３５４）のアラートが変更され、発呼者の情報がＴＶ配信システム上に表示されるように変更されたメッセージ要求（２３０）を加入者の電話に送信することと
   を含む、方法。
2. メッセージ要求を受信するとＴＶ配信システムに関連したサービスパッケージ情報を実行することをさらに含む、請求項１に記載の方法。
3. 実行することが、
   発呼者の発呼者ＩＤ情報を得ることと、
   発呼者の名前および番号情報を表示するためにＴＶ配信システムのアプリケーション（３０５、３２５）に発呼者ＩＤ情報を送信することと
   をさらに含む、請求項２に記載の方法。
4. メッセージ要求がＳＩＰ ＩＮＶＩＴＥメッセージであり、変更することがＳＩＰ ＩＮＶＩＴＥメッセージのヘッダフィールドを変更することをさらに含む、請求項１に記載の方法。
5. ヘッダフィールドが加入者の電話に関するアラート音または呼び出し音を定めるアラート情報を含み、変更することが、加入者の電話上で現在選択された呼び出し音を変更するまたは呼び出し音を抑制するためにＳＩＰ ＩＮＶＩＴＥ内のアラート情報のヘッダフィールドを所与の値に設定することをさらに含む、請求項４に記載の方法。
6. ヘッダフィールドが加入者の電話に関するアラート音または呼び出し音を定めるアラート情報を含み、変更することが加入者の電話のアラートを抑制するためにＳＩＰ ＩＮＶＩＴＥ内のアラート情報のヘッダフィールドを「０」に設定することをさらに含む、請求項４に記載の方法。
7. ネットワークの１つまたは複数のサービスおよびネットワークと通信するＴＶ配信システム（３００）の１つまたは複数のサービスの加入者にサービス混合を提供する通信ネットワーク（３５０）であって、
   発呼者からメッセージ要求を受信し、メッセージ要求を伝えるためのサーバ（３５７）と、
   ネットワークのアプリケーションとＴＶ配信システムのアプリケーションとの間で情報を共用するためにサーバと通信するサービスブローカ機能（３５５）と
   を備え、
   サーバがメッセージ要求をサービスブローカ機能に伝え、
   サービスブローカ機能が、
   メッセージ要求を受信すると発呼者の発呼者ＩＤ情報を取得し配信することを含むＴＶ配信システム加入のサービスに関連したサービスパッケージ情報を実行し、
   加入者の電話のアラートを変更するために加入者の電話（３０４、３５４）にサーバを介して送信される変更されたメッセージ要求を生成するためにメッセージ要求内の情報を変更し、
   表示のために発呼者の発呼者ＩＤ情報をＴＶ配信システムのアプリケーション（３０５、３２５）に送信する、通信ネットワーク（３５０）。
8. メッセージ要求がＳＩＰ ＩＮＶＩＴＥメッセージであり、
   サービスブローカ機能が、加入者の電話上で現在選択された呼び出し音を変更するまたは呼び出し音を抑制するためにＳＩＰ ＩＮＶＩＴＥメッセージ内のアラート情報のヘッダフィールドを所与の値に変更するように構成される、請求項７に記載のネットワーク。
9. ヘッダフィールドが加入者の電話に関するアラート音または呼び出し音を定めるアラート情報を含み、
   サービスブローカが、加入者の電話のアラートを抑制するためにＳＩＰ ＩＮＶＩＴＥメッセージ内のアラート情報のヘッダフィールドを「０」に設定するように構成される、請求項８に記載のネットワーク。
10. ネットワークおよびＴＶ配信システムの加入者に提供されるべきサービス混合を容易にするために通信ネットワークのアプリケーションとＴＶ配信システムのアプリケーションとの間で情報を共用するための通信ネットワーク３５０内のサービスブローカ（１２５、３５５）であって、
    発呼者からメッセージ要求を受信すると、発呼者の発呼者ＩＤ情報を得ることを含むＴＶ配信システム加入のサービスに関連したサービスパッケージ情報（３５２）を実行し、
    変更されたメッセージ要求を生成するためにメッセージ要求内の情報を変更し、
    表示のために発呼者の発呼者ＩＤ情報をＴＶ配信システムのアプリケーション（３０５、３２５）に送信すると同時に、加入者の電話のアラートを変更するために加入者の電話（３０４、３５４）に変更されたメッセージ要求の送信を伝える、サービスブローカ（１２５、３５５）。

Images