JP2010541311A - 伝送インフラストラクチャに接続された通信端末宛のアプリケーション通知の適合処理のデバイス - Google Patents

Abstract

デバイス（Ｄ）は、少なくとも１つの伝送インフラストラクチャ（ＲＣ）を介してユーザの通信端末（ＴＣ）に送信されなければならないアプリケーション通知の処理専用である。このデバイス（Ｄ）は、少なくとも１人のユーザ宛のアプリケーション通知が受信される時に必ず、ｉ）そのアプリケーション通知のコンテンツをその受信側ユーザの選択された端末（ＴＣ）にどのようにいつ送信しなければならないのか、ｉｉ）コンテンツのどの部分をその選択された端末（ＴＣ）によって使用しなければならないのか、およびｉｉｉ）その部分を選択された端末（ＴＣ）によってどのように使用しなければならないのかを定義する適合情報を、選択されたルール（１つまたは複数）および／またはポリシー（１つまたは複数）に依存して、ユーザおよび／またはコンテキスト情報ならびに／あるいはアプリケーション通知のパラメータ（１つまたは複数）ならびに／あるいは選択された端末の特性（１つまたは複数）を考慮に入れて判定し、さらに、判定された適合情報に基づいて、送信されるアプリケーション通知を適合させるように構成された処理手段（ＭＴ）を含む。

Description

本発明は、伝送インフラストラクチャに関し、より具体的には、アプリケーションから来るアプリケーション通知の、そのような伝送インフラストラクチャに接続された通信端末への伝送に関する。

本明細書では、用語「伝送インフラストラクチャ」は、通信ネットワークとブロードキャスト・ネットワークとの両方を指す。さらに、本明細書では、用語「ブロードキャスト・ネットワーク」は、通信端末への単一方向ダウンリンク経路に沿ってコンテンツ、潜在的にはマルチメディアを伝送することのできるすべてのタイプの地上および／または衛星ブロードキャスト・ネットワークを指す。さらに、本明細書では、用語「通信ネットワーク」は、有線であれ無線であれ、特に「ブロードキャスト」モードおよび／または「マルチキャスト」（ポイントツーマルチポイント）モードおよび／または「ユニキャスト」（ポイントツーポイント）モードで端末にコンテンツ、潜在的にはマルチメディアを伝送できる、すべてのタイプのブロードバンド両方向通信インフラストラクチャを指す。

その結果、伝送インフラストラクチャは、たとえばｘＤＳＬもしくはファイバもしくはケーブルなどの有線（または陸線）ネットワーク、Ｔ−ＤＭＢネットワーク、ＳＤＭＢ（「Ｓａｔｅｌｌｉｔｅ Ｄｉｇｉｔａｌ Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ」の略）もしくはＳ−ＵＭＴＳもしくはＳＤＲ（「Ｓａｔｅｌｌｉｔｅ Ｄｉｇｉｔａｌ Ｒａｄｉｏ」）ネットワークなどの衛星ネットワーク、移動体もしくはセルラ・ネットワーク（ＧＳＭ、ＧＰＲＳ／ＥＤＧＥ、ＵＭＴＳもしくはＣＤＭＡ２０００ならびにＬＴＥ（「Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ」）を含むすべての変形および同等物）もしくはＤＶＢ−Ｈ（「Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ − Ｈａｎｄｈｅｌｄｓ」の略、移動体テレビジョン）ネットワークなどの無線ベースの地上ネットワーク、または衛星テクノロジーから派生したテクノロジーを実施する地上ネットワーク（ＤＶＢ−Ｓ、ＤＶＢ−Ｓ２、もしくはＤＶＢ−ＲＣＳなど）、または無線ローカル・エリア・ネットワーク（ＷＬＡＮ（「無線ローカル・エリア・ネットワーク」−ＩＥＥＥ ８０２．１１、Ｗｉ−Ｆｉ、ＥＴＳＩ ＨｉｐｅｒＬＡＮ／２）、Ｂｌｕｅｔｏｏｔｈ（ＩＥＥＥ ８０２．１５）、ＷｉＭＡＸ（ＩＥＥＥ ８０２．１６、ＥＴＳＩ ＨｉｐｅｒＭＡＮ）、およびＺｉｇｂｅｅ標準規格））、あるいは、ＤＶＢ−ＳＨネットワーク（地上中継を有する衛星リンク）など、衛星と地上との両方であるネットワークを意味するハイブリッド・ネットワークとすることができる。

最後に、本明細書では、用語「通信端末」は、少なくともコンテンツ、潜在的にはマルチメディアを少なくとも１つの伝送インフラストラクチャ（潜在的には無線伝送インフラストラクチャ）から受信でき、潜在的にコンテンツを他の端末に送信できるすべての陸線または移動体（またはポータブルもしくはセルラ）の通信デバイスを指す。その結果、たとえば、通信端末を、コンテンツを受信することが（少なくとも）できる通信手段、潜在的には無線手段または衛星手段を備えるならば、陸線電話機または携帯（またはセルラ）電話機（潜在的にＩＰ電話機）、デスクトップ・コンピュータまたはポータブル・コンピュータ、携帯情報端末（すなわちＰＤＡ）、「スマートホン」（携帯電話機と組み合わされたＰＤＡ）、またはマルチメディア・コンテンツ・レシーバ（たとえば、デコーダ、住居ゲートウェイ、またはＳＴＢ（「セットトップ・ボックス」））とすることができる。

当業者に既知のとおり、アプリケーション通知によって、イベントが発生したことまたは新しい情報もしくは新しいコンテンツ（潜在的にマルチメディア）が使用可能であることをエンド・ユーザにシグナリングする（または通知する）ことを必要とする、ますます多数のアプリケーションが存在する。しかし、コンテンツのタイプの非常な多様性（テキスト、イメージ、オーディオ、ビデオ、データ）および通信端末のタイプの非常な多様性に起因して、ユーザに関する情報（ユーザ・プロファイル（プリファレンス）およびコンテンツの使用に関する制限（視覚障害または聴覚障害に起因するなど）など）、コンテキスト情報、通知のパラメータ（優先順位のレベル、機密性のレベル、クリティカリティのレベル、または送信されるコンテンツの意味（ｓｅｍａｎｔｉｃｓ）など）、または端末の特性（サポートされるコンテンツ・フォーマット、サポートされる保存機能、またはディスプレイ・スクリーンの寸法、および類似するものなど）など、エンド・ユーザの端末および／またはエンド・ユーザ自体に固有のコンテンツを提供するための判断基準とこれらの多様性との両方をアプリケーションが考慮に入れることは、ほとんど不可能ではないとしても、ますますむずかしくなりつつある。

この状況を改善する試みにおいて、ＩＢＭ社のＳｍａｒｔ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ（商標、以下同）、ＭＩＲ３社のＳｍａｒｔ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｓｏｌｕｔｉｏｎ（商標、以下同）、Ｎｅｗｖｏｉｃｅ社の「Ｍｏｂｉｃａｌｌ」（商標、以下同）と呼ばれるソリューションなど、複数のソリューションが提案されてきた。残念ながら、これらのソリューションは、上で述べたコンテンツの提供に関する判断基準の（非常に）小さい部分だけを考慮に入れるので、満足なものではない。具体的に言うと、ＩＢＭ社のＳｍａｒｔ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅは、通知の伝送チャネルを決定するために、主に、好まれる伝送チャネルのタイプ（インスタント・メッセージング（すなわちＩＭ）、電子メール、電話呼、ＳＭＳ、ＭＭＳ、および類似物）、ユーザ・コンテキスト（プレゼンス、電話に応じられること、および位置）、および通知の優先順位レベルだけを考慮に入れる。言い換えると、考慮に入れられるが、部分的にのみ考慮に入れられる質問は、エンド端末のユーザに通知を送信する形（「どのように」）である。さらに、通知をエンド・ユーザのグループにアドレッシングしなければならない時には、必ず、通知を、グループのユーザの全員に並列に送信することだけができる。したがって、エンド・ユーザのグループに関する他の伝送戦略はない。

さらに、既知のソリューションは、送信されるコンテンツの意味（ｓｅｍａｎｔｉｃｓ）、端末の能力（または特性）、またはエンド・ユーザの制限（またはハンディキャップ）などの適合判断基準を考慮に入れず、すべての異なるタイプの端末を考慮に入れてもいない。

したがって、本発明の目的は、この状況を改善することである。

そのために、少なくとも１つの伝送インフラストラクチャを介して（エンド）ユーザの通信端末に送信されなければならないアプリケーション通知（アプリケーション（１つまたは複数）から来る）の処理専用のデバイスであって、少なくとも１人のユーザ宛のアプリケーション通知が受信される時に必ず、
−ｉ）アプリケーション通知のコンテンツを受信側ユーザの選択された端末にどのようにいつ送信しなければならないのか、ｉｉ）そのコンテンツのどの部分をその選択された端末によって使用しなければならないのか、およびｉｉｉ）その部分を選択された端末によってどのように使用しなければならないのかを定義する適合情報を、選択されたルール（１つまたは複数）および／またはポリシー（１つまたは複数）に依存して、ユーザおよび／またはコンテキスト情報ならびに／あるいはアプリケーション通知のパラメータ（１つまたは複数）ならびに／あるいは選択された端末の特性（１つまたは複数）を考慮に入れて判定し、
−判定された適合情報に基づいて、送信されるアプリケーション通知を適合させる
ために、そのアプリケーション通知を分析することを課された処理手段を含むデバイスを開示する。

本発明のデバイスは、別々にまたは組み合わせて採用できる他の特性を含むことができ、具体的には、
−その処理手段には、ユーザのグループ宛のアプリケーション通知が受信される時に必ず、
・ｉ）アプリケーション通知のコンテンツをそのグループの受信側ユーザの端末にどのようにいつ送信しなければならないのか、ｉｉ）そのコンテンツのどの部分をこれらのユーザの端末によって使用しなければならないのか、およびｉｉｉ）その部分をユーザの端末によってどのように使用しなければならないのかを定義する適合情報を、選択されたルール（１つまたは複数）および／またはポリシー（１つまたは複数）に依存して、ユーザおよび／またはコンテキスト情報ならびに／あるいはアプリケーション通知のパラメータ（１つまたは複数）ならびに／あるいはユーザの端末の特性（１つまたは複数）ならびに／あるいはグループ内で各ユーザによって演じられる役割を考慮に入れて判定し、
・判定された適合情報に基づいて、送信されるアプリケーション通知を適合させる
ために、そのアプリケーション通知を分析することを課すことができ、
−その処理手段には、ユーザのグループ宛のアプリケーション通知が受信される時に必ず、（少なくとも）同時送信、完全なまたは制限された順次送信の中から選択される、そのアプリケーション通知を送信するモードを定義する１つの適合情報を判定することを課すことができ（たとえば、グループ内の各ユーザの役割および／またはグループのユーザの１人による適合されたアプリケーション通知の肯定応答に依存して（前のユーザが送信された適合されたアプリケーション通知を肯定応答しない場合に限ってアプリケーション通知を次の受信側ユーザに送信する））、
−ユーザ情報のそれぞれは、たとえば、（少なくとも）受信側ユーザ・プロファイル、アプリケーション通知を発したユーザのプロファイル、および受信側ユーザに関連するコンテンツ使用に対する少なくとも１つの制限の中から選択することができ、
−コンテキスト情報のそれぞれは、たとえば、受信側ユーザおよび／または受信側ユーザの選択された端末に関連することができ、（少なくとも）端末の近くでの受信側ユーザのプレゼンスに関連する１つの情報、受信側ユーザの地理的位置に関連する１つの情報、受信側ユーザの端末のそれぞれが見つかる状態に関連する１つの情報、および受信側ユーザの端末によって現在再生されつつある１つのマルチメディア・コンテンツに関連する１つの情報の中から選択することができ、
−アプリケーション通知の各パラメータは、たとえば、（少なくとも）優先順位のレベル、機密性のレベル、クリティカリティのレベル、送信されるコンテンツの意味（ｓｅｍａｎｔｉｃｓ）の中から選択することができ、
−各端末特性は、たとえば、少なくとも、サポートされるコンテンツ・フォーマット、サポートされる記憶容量、およびディスプレイ・スクリーンの寸法の中から選択することができ、
−その処理手段には、使用されるコンテンツ部分に最も適する受信側ユーザの端末を選択することを課すことができ、
−その処理手段には、（少なくとも）即時送信、受信側ユーザの端末による１つのマルチメディア・コンテンツの再生の終了まで遅延される送信、および受信側ユーザの端末による１つのマルチメディア・コンテンツの再生中の選択された瞬間まで遅延される送信の中からアプリケーション通知の送信に最も適する瞬間を選択することを課すことができ、
−その処理手段には、そのコンテンツの少なくとも１つの部分の利用規約（１つまたは複数）を定義する少なくとも１つのパラメータが欠けているアプリケーション通知が受信される時に必ず、ｉ）他のパラメータならびに選択されたルール（１つまたは複数）および／またはポリシー（１つまたは複数）に依存して、ユーザおよび／またはコンテキスト情報ならびに／あるいはアプリケーション通知のパラメータ（１つまたは複数）ならびに／あるいは選択された端末の特性（１つまたは複数）を考慮に入れて各欠けている定義パラメータを判定することと、ｉｉ）送信すべきアプリケーション通知を各判定された定義パラメータに追加することによって送信すべきアプリケーション通知を適合させることとを課すことができ、
コンテンツ部分の各利用規約は、たとえば、（少なくとも）判定されたコンテンツ部分を使用するための１つのマルチメディア・コンテンツの再生における瞬間的中断、判定されたコンテンツ部分のテキスト−サウンド変換、前記判定されたコンテンツ部分のサウンド−テキスト変換、第１言語から第２言語への変換、および適合されたアプリケーション通知の受信時の可聴アラート信号の発行の中から選択することができ、
−その処理手段には、それが依存するアプリケーションおよび／またはそれを各受信側ユーザに送信するのに使用される伝送インフラストラクチャの各タイプに依存して各アプリケーション通知を適合させることを課すことができ、
−ｉ）処理手段によって行われる適合判断を適用することと、ｉｉ）処理手段によって適合されたアプリケーション通知を端末に配送することと、ｉｉｉ）適合されたアプリケーション通知が実際に受信側端末に送信されたことを保証することと、ｉｖ）これらの端末が適合されたアプリケーション通知のコンテンツをそのパラメータによって定義される利用規約に従って使用したことを保証することとを課せられる制御手段を含むことができ、
制御手段には、ストレージ手段内に、端末に送信された、かつ／またはこれから送信される適合されたすべてのアプリケーション通知を格納することを課すこともでき、
制御手段には、適合されたアプリケーション通知のコンテンツの部分の使用の後に、選択された端末内でトリガされる少なくとも１つの対話動作を管理することを課すこともできる。

本発明は、通信ネットワークのサービス・プラットフォームの一部を形成することを意図された、上で説明した種類の処理デバイスを備えるサーバをも開示する。

本発明の他の特性および利益は、下の詳細な説明および添付図面を調べる時に明白になる。図面は、本発明を完成させるだけではなく、必要な場合に本発明を定義するのにも寄与することができる。

通信ネットワークに接続され、本発明の処理デバイスの例の実施形態を備えるサーバを概略的および機能的に示す。

本発明の目的は、多様なコンテンツ・タイプ、多様な通信端末タイプ、ならびにコンテンツおよび／または多様なコンテンツ情報および／または多様なアプリケーション通知パラメータおよび／または多様な端末特性の提供に関する多様な判断基準の存在下で、潜在的にはマルチメディア・コンテンツの、少なくとも１つのコンテンツ伝送インフラストラクチャに接続された通信端末宛のアプリケーション通知の適合を可能にすることである。

次では、非限定的な例として、伝送インフラストラクチャ（ＲＣ）が、移動体（またはセルラ）通信ネットワーク、たとえばＵＭＴＳ（またはＬＴＥ）またはＣＤＭＡ２０００ネットワークであると仮定する。しかし、本発明は、このタイプの伝送インフラストラクチャに限定はされない。そうではなく、本発明は、通信ネットワーク（有線であれ無線であれ）とブロードキャスト・ネットワーク（有線であれ無線であれ）との両方に関係する。その結果、本発明を、地上および／もしくは衛星単一方向ブロードキャスト・ネットワーク、またはｘＤＳＬもしくはファイバもしくはケーブル・ネットワークなどの有線（または陸線）ネットワーク、またはＴ−ＤＭＢネットワーク、またはＳＤＭＢ（「Ｓａｔｅｌｌｉｔｅ Ｄｉｇｉｔａｌ Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ」の略）もしくはＳ−ＵＭＴＳもしくはＳＤＲ（「Ｓａｔｅｌｌｉｔｅ Ｄｉｇｉｔａｌ Ｒａｄｉｏ」）ネットワークなどの衛星ネットワーク、または無線ローカル・エリア・ネットワーク（ＷＬＡＮ（「無線ローカル・エリア・ネットワーク」、−ＩＥＥＥ ８０２．１１、Ｗｉ−Ｆｉ、ＥＴＳＩ ＨｉｐｅｒＬＡＮ／２）、Ｂｌｕｅｔｏｏｔｈ（登録商標、以下同）（ＩＥＥＥ ８０２．１５）、ＷｉＭＡＸ（登録商標、以下同）（ＩＥＥＥ ８０２．１６、ＥＴＳＩ ＨｉｐｅｒＭＡＮ）およびＺｉｇｂｅｅ標準規格））、またはＤＶＢ−ＳＨネットワーク（地上中継を有する衛星リンク）など、衛星と地上との両方であるネットワークを意味するハイブリッド・ネットワークとすることもできる。

本発明が、少なくとも、コンテンツ、潜在的にはマルチメディア・コンテンツを伝送インフラストラクチャから受信するために、少なくとも１つの伝送インフラストラクチャ（おそらくは無線ベースの）に接続できる、陸線であれ移動体（またはポータブルもしくはセルラ）であれ、すべてのタイプの通信端末（ＴＣ）に関係することに留意されたい。その結果、通信端末（ＴＣ）は、コンテンツを受信（少なくとも）できる通信手段、潜在的には無線手段または衛星手段を備えるならば、陸線または移動体（またはセルラ）電話機（潜在的にＩＰ電話機）、スマートホン、デスクトップ・コンピュータまたはポータブル・コンピュータ、携帯情報端末（すなわち、ＰＤＡ）、マルチメディア・コンテンツ・レシーバ（たとえば、デコーダ、住居ゲートウェイ、またはＳＴＢ（「セットトップ・ボックス」））とすることができる。

唯一の図は、異なるタイプの（通信）端末ＴＣならびに端末ＴＣヘのアプリケーション通知の提供を制御すると同時にこれらの端末ＴＣによる前記アプリケーション通知の使用を制御すること専用のサーバＳＲが接続された通信ネットワーク（ＲＣ）、ここでは移動体ネットワーク（例として）を概略的かつ機能的に示す。図示されてはいないが、サーバＳＲが、サービス・プラットフォームの一部を形成できることに留意されたい。

図示されているように、一部の端末ＴＣは、エンド・ユーザ宛（より具体的には、彼らの端末宛）のアプリケーション通知を生成することができる組込みアプリケーションＡＴを備える。しかし、本発明は、図示されているように、複数の端末ＴＣおよび／またはネットワーク・デバイスにサービスを提供するためにネットワークのＲＣサーバに一般にインストールされる共有ネットワーク・アプリケーションＡＲにも関係する。アプリケーション通知を生成するすべてのタイプのアプリケーションが、本発明に関係する。したがって、非網羅的で非限定的な形で、メディア・アプリケーション（ターゲティングされた広告メッセージの送信またはニュースの送信など）、医療アラート・アプリケーション（薬物を摂取しなければならないこともしくは治療を行わなければならないことを思い出させるメッセージを与えるアラート（「ｅ−ｈｅａｌｔｈ」）または特殊な緊急支援）、およびビジネス関連アプリケーション（金融情報、市場情報、または技術情報の送信など）に言及することができる。これらのアプリケーションは、たとえば、サーバＳＲにアプリケーション通知要求を送信するために、ＳＯＡＰ（ウェブ・サービス）、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、またはＰＡＰ（Ｐｕｓｈ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）インターフェース、あるいは任意の他のインターフェースを使用することができる。

これには限定されない図示した例では、ＳＲは、本発明の処理デバイスＤを含み、この本発明の処理デバイスＤを、下で説明する。しかし、そのようなデバイスＤは、サーバＳＲの外部にあり、これに接続されるものとすることができる。

本発明の処理デバイスＤは、少なくとも、サーバＳＲがアプリケーションＡＴまたはＡＲから少なくとも１人のユーザ宛のアプリケーション通知ＮＴを受信するたびに介入することを課せられる処理モジュールＭＴを含む。アプリケーション通知ＮＴは、パラメータならびに、前記関連するパラメータを考慮に入れて各受信側端末ＴＣによって使用されなければならないコンテンツを含む。

各介入中に、処理モジュールＭＴは、第１にアプリケーション通知ＮＴのコンテンツをどのようにいつ各受信側ユーザの選択された端末ＴＣに送信しなければならないのか、第２にそのコンテンツのどの部分が各選択された端末ＴＣによって使用されなければならないのか、および第３にこの部分を各選択された端末ＴＣによってどのように使用しなければならないのかを定義することを意図された適合情報をまず判定するために、受信されたアプリケーション通知ＮＴを分析する。

この判定は、選択されたルール（１つまたは複数）および／またはポリシー（１つまたは複数）に依存して、ユーザ情報ＩＵおよび／またはコンテキスト情報ＩＣおよび／またはアプリケーション通知ＮＴ内に含まれるパラメータ、および／または選択された端末ＴＣの選択された特性ＣＴを考慮に入れて、行われる。

処理モジュールＭＴが、適合情報の判定を終了した時に、必ず、処理モジュールＭＴは、この適合情報に基づいて、送信されるアプリケーション通知を適合させる。

前述のルールおよび／またはポリシーは、個別に考慮されるユーザまたはユーザのグループに属するユーザのいずれかに関係する。

これらのルールおよび／またはポリシーは、ユーザごとまたはユーザのグループごとに、およびリストされた状況ごとに（使用される端末のタイプ、アプリケーションのタイプ、使用される伝送インフラストラクチャＲＣのタイプ、ユーザ・プロファイルまたはユーザ・グループ・プロファイルのタイプ、および潜在的にユーザまたはユーザ・グループ制限の少なくとも１つのタイプ（ハンディキャップなど）、ならびにユーザまたはユーザ・グループ・コンテキストＩＣのタイプ）、行うべきアプリケーション通知適合（１つまたは複数）のセットを定義する。

ここで、「アプリケーション通知適合」は、アプリケーション通知のコンテンツ（「何」）の少なくとも１つの部分の選択された利用規約に従う（「どのように」）所与の瞬間（「いつ」）での使用にそのアプリケーション通知の受信側端末ＴＣのそれぞれを制限するために、欠けているパラメータを潜在的に判定した後に、アプリケーション通知に利用規約（１つまたは複数）を追加することを指す。

思い出させるものとして、アプリケーション通知は、既知の個数のパラメータによって定義され、これらのパラメータは、その一部について、それらが少なくとも２つの「単純」パラメータを定義するので、「複雑」である場合がある。言い換えると、低水準と呼ばれる一部のアプリケーション通知は、単純パラメータだけを含み、したがって、適合フェーズ中に追加されるものを除いて他の単純パラメータによって完成される必要がないが、高水準と呼ばれる他のアプリケーション通知は、単純パラメータと複雑パラメータとの両方を含み、したがって、追加されるパラメータに加えて、後者が、単純パラメータのそのめいめいの組合わせによって置換されることを必要とする。

個々のユーザに関係する、高水準アプリケーション通知の２つの例を、下に与える。
−［Ｆｒｏｍ：ＶＯＤ−ＣＩＥ、Ｔｏ：Ｂｏｂ、Ｃｏｎｔｅｎｔ：「サーフィンに関連する新しいＶｏＤ」、Ｐｒｉｏｒｉｔｙ：ＩＮＦＯＲＭＡＴＩＯＮＡＬ］、これは、ビデオオンデマンド・アプリケーションが、サーフィンに関するビデオの形のマルチメディア・コンテンツがオンデマンドで使用可能であることと、このアプリケーション通知が優先順位の情報を与える（ｉｎｆｏｒｍａｔｉｏｎａｌ）レベルであることとをＢｏｂに知らせていることとを意味する。
−［Ｆｒｏｍ：Ｄｒ Ｐｅｔｅｒ、Ｔｏ：Ａｌｉｃｅ、Ｃｏｎｔｅｎｔ：「薬を飲んでください」、Ｐｒｉｏｒｉｔｙ：ＵＲＧＥＮＴ］、これは、医療アラート・アプリケーションが、Ａｌｉｃｅの医師（Ｄｒ．Ｐｅｔｅｒ）の要求時に、彼女が（即座に）薬を飲まなければならないことと、このアプリケーション通知が優先順位の緊急（ｕｒｇｅｎｔ）レベルを有することとを彼女に知らせていることとを意味する。

ユーザのグループに関連する、例の高水準アプリケーション通知を、下に与える。
−［Ｆｒｏｍ：Ｄｒ Ｐｅｔｅｒ、Ｔｏ：Ｈｏｓｐｉｔａｌ ｓｅｒｖｉｃｅ、Ｃｏｎｔｅｎｔ：「助けが必要」、Ｐｒｉｏｒｉｔｙ：ＵＲＧＥＮＴ］、これは、医療アラート・アプリケーションが、Ｄｒ．Ｐｅｔｅｒが即座に助けを必要とすることと、このアプリケーション通知が優先順位のｕｒｇｅｎｔレベルを有することとを病院業務に知らせていることとを意味する。

限定されない例として、図示されているように、ユーザに関するルールおよび／またはポリシーを、第１ストレージ手段Ｂ１内に格納することができ、ユーザのグループに関するルールおよび／またはポリシーを、第２ストレージ手段Ｂ２内に格納することができる。

これらの第１ストレージ手段Ｂ１および第２ストレージ手段Ｂ２は、任意の形とすることができる。その結果、これらを、メモリまたはデータベースとすることができる。第１ストレージ手段Ｂ１および第２ストレージ手段Ｂ２は、潜在的に、同一のストレージ手段の２つの部分を構成することができる。

これには限定されない図示の例では、処理モジュールＰＭが、単一ユーザ宛のアプリケーション通知の適合処理専用の第１サブモジュールＳＴ１と、ユーザのグループ宛のアプリケーション通知の適合処理専用の第２サブモジュールＳＴ２とを含むことに留意されたい。

第１サブモジュールＳＴ１は、たとえば、互いに結合された、第１ストレージ手段Ｂ１と、第１アプリケーション通知適合モジュールＭＡ１とを含む。

第２サブモジュールＳＴ２は、たとえば、互いに結合された、第２ストレージ手段Ｂ２と、第２アプリケーション通知適合モジュールＭＡ２とを含む。

第１アプリケーション通知適合モジュールＭＡ１は、たとえば、そのユーザ宛の受信したアプリケーション通知のコンテンツをそこに送信しなければならない端末ＴＣを判定した後に、介入し、その瞬間に、そのコンテンツは、受信した情報（ＩＵ、ＩＣ、およびＣＴ）に基づいて送信されなければならない。この使用可能な情報は、特に、次を含むことができる。
−受信側ユーザおよび／またはアプリケーション通知を発したユーザに関連する情報ＩＵ、たとえば、受信側ユーザのプロファイル（プリファレンス（１つまたは複数））、アプリケーション通知を発したユーザのプロファイル（プリファレンス（１つまたは複数））、または受信側ユーザ（視覚障害または聴覚障害など）に関連するコンテンツの使用に関する少なくとも１つの制限（ハンディキャップなど）、
−受信側ユーザおよび／またはそのユーザが選択した端末ＴＣに関連するコンテキスト情報ＩＣ、たとえば、自分の端末ＴＣのうちの１つの近くでの受信側ユーザのプレゼンスに関連する情報、受信側ユーザの地理的位置に関連する情報、受信側ユーザの各端末ＴＣが見つかる状態に関連する情報、または受信側ユーザの端末ＴＣの１つによって再生されつつあるマルチメディア・コンテンツのタイプを示す情報、
−アプリケーション通知ＮＴ内に含まれるパラメータ、たとえば、優先順位のレベル、クリティカリティのレベル、機密性のレベル、または送信されるコンテンツの意味（ｓｅｍａｎｔｉｃｓ）、
−選択された端末ＴＣの選択された特性ＣＴ、たとえば、それがサポートするコンテンツ・フォーマット、それがサポートする保存容量、またはそのディスプレイ・スクリーンの寸法。これらの特性ＣＴは、たとえば、サーバＳＲ内に含まれるゲートウェイＲＡによって提供される。このゲートウェイＰＡは、処理モジュールＭＴに端末ＴＣの特性を与え、選択された伝送チャネルのフォーマット（インスタント・メッセージング（すなわちＩＭ）、電子メール、電話呼、ＳＭＳ、ＭＭＳ、および類似物）に従ってアプリケーション通知を含むメッセージを生成することが意図されている。ゲートウェイＰＡが、集中化された形で端末ＴＣの特性を生成できることに留意されたい。これは、ゲートウェイＰＡが、端末の特性を格納し、自動的に（ネットワーク内で接続された端末の特性を自動的に発見することを可能にするＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）プロトコルを介するなど）または非ＵＰｎＰ端末の場合に手動で更新される、中央データベースを有することができることを意味する。非ＵＰｎＰ端末の場合に、ゲートウェイＰＡは、たとえば、処理モジュールＭＴに、ユニバーサルＷＵＲＦＬファイル（Ｗｉｒｅｌｅｓｓ Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｆｉｌｅ、移動体端末製造業者によって定期的に更新される、複数の移動体端末（現在までに５０００超）のすべての特性をリストしたＸＭＬフォーマットのファイル）の助けを得て端末ＴＣの特性を与えることができる。

選択される端末ＴＣは、受信された使用可能な情報および第１ストレージ手段Ｂ１に格納された情報を考慮して、最も適する端末である。

同様に、選択される送信の瞬間は、受信された使用可能な情報および第１ストレージ手段Ｂ１に格納された情報を考慮して、最も適する瞬間である。この瞬間は、適合されたアプリケーション通知の送信に最も適するが、たとえば、即座の送信、または選択された端末ＴＣが現在のマルチメディア・コンテンツの再生を終了するまで遅延される送信、または選択された端末ＴＣ内で現在再生されつつあるマルチメディア・コンテンツ内の選択された瞬間まで遅延される送信に対応することができる。

第１アプリケーション通知適合モジュールＭＡ１の介入は、受信した使用可能な情報ＩＵ、ＩＣ、およびＣＴ、選択された端末ＴＣ、送信の決定された瞬間、ならびに第１ストレージ手段Ｂ１に格納されたルールおよび／またはポリシーに基づいて受信されたアプリケーション通知ＮＴを適合させることからなる。

上で示したように、この適合は、適合されたアプリケーション通知のコンテンツの利用規約を選択された端末ＴＣに課すことが意図されている。可能で潜在的に組合せ可能な利用規約は、次を含むことができる。
−アプリケーション通知のコンテンツの選択された部分またはすべての使用、
−コンテンツの選択された部分（またはコンテンツのすべて）を使用するためのマルチメディア・コンテンツの１つの再生の一時的中断（より後の再開を伴う一時停止モード（または「タイムシフト」）、
−テキスト・コンテンツの存在下で、前記コンテンツの選択された部分（またはその全体）のテキスト−音声（オーディオ）変換。これは、たとえば、視覚障害または受信側ユーザのプリファレンス（１つまたは複数）に基づいて判断することができ、
−サウンド・コンテンツ（オーディオ）の存在下で、前記コンテンツの選択された部分（またはその全体）のサウンド−テキスト変換。これは、たとえば、聴覚障害または受信側ユーザのプリファレンス（１つまたは複数）に基づいて判断することができ、
−サウンド（オーディオ）またはテキスト・コンテンツの存在下で、第１言語から第２言語へのコンテンツの変換、
−アプリケーション通知が受信されたことをシグナリングするための可聴アラート信号（または「ビープ」）の発行、
−コンテンツの選択された部分（またはコンテンツのすべて）の特殊な表示、
−優先順位の情報のレベルを伴うアプリケーション通知または受信の肯定応答の送出を必要とするアプリケーション通知に関するものなど、対話性の実施。

第２アプリケーション通知適合モジュールＭＡ２は、たとえば、その第２サブモジュールＳＴ２が、ユーザのどのグループが受け取られたグループ・アプリケーション通知のコンテンツを送信されなければならないのか、および当該のグループにこのコンテンツを送信するのにどの戦略を使用しなければならないのかを、第３ストレージ手段Ｂ３（たとえば、メモリまたはデータベース）内に格納された情報、第２ストレージ手段Ｂ２内に格納されたルールおよび／またはポリシー、ならびに上で説明したタイプの潜在的に受信された情報（ＩＵ、ＩＣ、およびＣＴ）に基づいて判定した後に、介入する。

第３ストレージ手段Ｂ３（潜在的にデバイスＤまたはサーバＳＲの一部を形成することができる）に格納される情報は、グループ内で各ユーザが演じる役割およびユーザ・グループに関するすべての他の情報（潜在的に他のシステムによって提供され得る）を含むことができる。

あるグループについて、選択される端末ＴＣは、使用可能であり、最も適すると仮定される端末であり、各端末ＴＣについて選択される送信の瞬間は、それに関係する受信された使用可能な情報および第３ストレージ手段Ｂ３に格納された情報を考慮して最も適する瞬間である。

第２サブモジュールＳＴ２が、グループのユーザのすべての端末について送信の同一の瞬間（「同時」送信と呼ぶ）または送信の連続する瞬間（「順次」送信と呼ぶ）を選択できることに留意されたい。第２サブモジュールＳＴ２は、たとえばグループのユーザのめいめいの役割およびそのアプリケーション通知の優先順位のレベルを考慮して、適合されたアプリケーション通知をグループのユーザの一部にのみ送信することができると判断し、かつ／または同一グループ内の前の受信側ユーザがタイムアウト後に適合されたアプリケーション通知を肯定応答しなかった場合に限って、適合されたアプリケーション通知をグループ内の次の受信側ユーザに送信すると判断することもできる。

第２アプリケーション通知適合モジュールＭＡ２の介入は、グループ内の各ユーザにどのようにどの順番で通知するかを決定すること、ならびに、グループ内の各ユーザの役割と、第２ストレージ手段Ｂ２に格納されたルールおよび／またはポリシーと、受信された使用可能な情報ＩＵ、ＩＣ、およびＣＴとに基づいて受信されたアプリケーション通知ＮＴを適合させることからなる。

上で示したように、この適合は、適合されたアプリケーション通知のコンテンツの特定の利用規約を選択された端末ＴＣに課すことを意図されたものである。利用規約は、単一ユーザ宛のアプリケーション通知について上で説明したものに類似するものとすることができる。

アプリケーション通知適合が、潜在的に、それらを生成するアプリケーションに依存するアプリケーション通知テンプレートおよび／または受信側ユーザの端末ＴＣにそれらを送信するのに使用される伝送インフラストラクチャのタイプに基づいて行われることに留意されたい。そのために、唯一の図に示されているように、処理モジュールＭＴは、サブモジュールＳＴ１およびＳＴ２に結合された、オントロジ・ファイル（ＯＷＬ）またはＸＭＬファイルの形などのさまざまなアプリケーション通知テンプレートを格納するストレージ手段ＭＮ（たとえば、メモリ）を含むことができる。

唯一の図に示されているように、本発明のデバイスＤは、処理モジュールＭＴによって行われる適合判断を適用することと、処理モジュールＭＴによって適合されたアプリケーション通知を端末ＴＣに配送することと、適合されたアプリケーション通知が受信側端末ＴＣに実際に送信されたことを保証することと、これらの端末が適合されたアプリケーション通知のコンテンツをそのパラメータによって定義される利用規約に従って使用したことを保証することとを課せられる制御モジュールＭＣＵを含むことができる。

さらに、この制御モジュールＭＣＵは、端末ＴＣに送信されたおよび／またはこれから送信される（適合された後に）すべてのアプリケーション通知を、キューイング、ロギング、および／または請求のためなど、第４ストレージ手段Ｂ４内に格納するように優先的に構成される。

さらに、この制御モジュールＭＣＵは、エンドユーザから来る対話を管理するようにも優先的に構成される。

図示されているように、この制御モジュールＭＣＵは、たとえば、処理モジュールＭＴとゲートウェイＰＡとの間にインストールされ、２つの制御サブモジュールＭＣ１およびＭＣ２に副分割され得る。

第１制御サブモジュールＭＣ１は、たとえば、適合されたアプリケーション通知が実際に受信側端末ＴＣに送信されたかどうかをチェックし、これらの端末がコンテンツをそのパラメータによって定義される利用規約に従って使用したことを保証し、必要な場合に適合されたアプリケーション通知を再送信するために、処理モジュールＭＴによって判断された瞬間に処理モジュールＭＴによって判断された形で端末ＴＣにアプリケーション通知を配送することを課せられる。第１制御サブモジュールＭＣ１は、受信された適合されたアプリケーション通知（端末ＴＣに送信されたおよびこれから送信される）のすべてをストレージ手段Ｂ４に格納することも課せられる。

第２制御サブモジュールＭＣ２は、たとえば、アプリケーション通知コンテンツの一部の使用および／またはそのユーザからのアクションの後に受信側端末ＴＣによってトリガされ得る対話を管理することを課せられる。たとえば、対話型にされた１つのアプリケーション通知コンテンツが、ユーザがウェブページにアクセスするかウェブページを自分の端末ＴＣにロードすることを可能にし、あるいは、自分をアプリケーションにルーティングする（通信を確立するため、予約を記録するため、または通知の送出をトリガするためなど）ことを可能にする場合がある。

サーバＳＲを、他のプラットフォームに接続し、これによって、ユーザの要求を、要求されたサービスを管理するプラットフォームにルーティングすることを可能にすることができる。たとえば、ユーザが送信者に電話をかけることを可能にする「Ｃａｌｌ」ボタンが付随する通知を、ユーザに送信することができる。その場合に、ユーザがこのボタンをクリックする時に、必ず、第２制御サブモジュールＭＣ２は、ユーザの要求を受信し、これを電話プラットフォームに送信する。それを行うためには、第２制御サブモジュールＭＣ２が、サーバＳＲが中継器として働いている各サービス・プラットフォームへのカスタマ・インターフェースを有することで十分である。

本発明の処理デバイスＤ、ならびに特にその処理モジュールＭＴおよび潜在的にその制御モジュールＭＣＵを、電子回路、ソフトウェア（またはコンピューティング）モジュール、または回路およびソフトウェアの組合せで構成することができる。

本発明は、例としてのみ与えられる、上で説明した処理デバイスおよびサーバの実施形態に限定されず、当業者が下の特許請求の範囲の枠組の中で心に描くことのできるすべての変形形態を包含する。

Claims (15)

1. 少なくとも１つの伝送インフラストラクチャ（ＲＣ）を介してユーザの通信端末（ＴＣ）に送信されなければならないアプリケーション通知を処理するデバイス（Ｄ）であって、少なくとも１人のユーザ宛のアプリケーション通知が受信される時に必ず、
   −ｉ）前記アプリケーション通知のコンテンツを前記受信側ユーザの選択された端末（ＴＣ）にどのようにいつ送信しなければならないのか、ｉｉ）前記コンテンツのどの部分を前記選択された端末（ＴＣ）によって使用しなければならないのか、およびｉｉｉ）前記部分を前記選択された端末（ＴＣ）によってどのように使用しなければならないのかを定義する適合情報を、選択されたルール（１つまたは複数）および／またはポリシー（１つまたは複数）に基づき、ユーザおよび／またはコンテキスト情報ならびに／あるいは前記アプリケーション通知のパラメータ（１つまたは複数）ならびに／あるいは前記選択された端末（ＴＣ）の特性（１つまたは複数）を考慮に入れて判定し、
   −前記判定された適合情報に基づいて、送信される前記アプリケーション通知を適合させる、
   ために、そのアプリケーション通知を分析するように構成された処理手段（ＭＴ）を含むことを特徴とするデバイス。
2. 前記処理手段は、ユーザのグループ宛のアプリケーション通知が受信される時に必ず、
   −ｉ）前記アプリケーション通知のコンテンツを前記グループの前記受信側ユーザの端末（ＴＣ）にどのようにいつ送信しなければならないのか、ｉｉ）前記コンテンツのどの部分を前記ユーザの端末によって使用しなければならないのか、およびｉｉｉ）前記部分を前記ユーザの端末によってどのように使用しなければならないのかを定義する適合情報を、選択されたルール（１つまたは複数）および／またはポリシー（１つまたは複数）に依存して、ユーザおよび／またはコンテキスト情報ならびに／あるいは前記アプリケーション通知のパラメータ（１つまたは複数）ならびに／あるいは前記ユーザの端末の特性（１つまたは複数）ならびに／あるいは前記グループ内で各ユーザによって演じられる役割を考慮に入れて判定し、
   −前記判定された適合情報に基づいて、送信される前記アプリケーション通知を適合させる、
   ために、そのアプリケーション通知を分析するように構成されることを特徴とする、請求項１に記載のデバイス。
3. 前記処理手段（ＭＴ）は、ユーザのグループ宛のアプリケーション通知が受信される時に必ず、少なくとも、１つの同時送信および１つの完全なまたは制限された順次送信を含む群から選択される、そのアプリケーション通知を送信するモードを定義する１つの適合情報を判定するように構成されることを特徴とする、請求項２に記載のデバイス。
4. 前記順次送信は、前記グループ内の各ユーザの前記役割および／または前記グループのメンバの１つによる前記適合されたアプリケーション通知の肯定応答に基づくことを特徴とする、請求項３に記載のデバイス。
5. ユーザ情報のそれぞれは、少なくとも、前記受信側ユーザのプロファイル、前記アプリケーション通知を発したユーザのプロファイル、および前記受信側ユーザに関連する前記コンテンツの使用に対する少なくとも１つの制限を含む群から選択されることを特徴とする、請求項１乃至４のいずれか１項に記載のデバイス。
6. コンテキスト情報のそれぞれは、前記受信側ユーザおよびまたは前記受信側ユーザの選択された端末（ＴＣ）に関連し、少なくとも、端末（ＴＣ）の近くでの前記受信側ユーザのプレゼンスに関連する１つの情報、前記受信側ユーザの地理的位置に関連する１つの情報、前記受信側ユーザの端末（ＴＣ）のそれぞれが見つかる状態に関連する１つの情報、および前記受信側ユーザの端末（ＴＣ）によって現在再生されつつある１つのマルチメディア・コンテンツに関連する１つの情報を含む群から選択されることを特徴とする、請求項１乃至５のいずれか１項に記載のデバイス。
7. 前記アプリケーション通知のパラメータのそれぞれは、少なくとも、優先順位のレベル、クリティカリティのレベル、送信されるコンテンツのセマンティックを含む群から選択されることを特徴とする、請求項１乃至６のいずれか１項に記載のデバイス。
8. 各端末（ＴＣ）特性は、少なくとも、サポートされるコンテンツ・フォーマット、サポートされる保存容量、およびディスプレイ・スクリーン寸法を含む群から選択されることを特徴とする、請求項１乃至７のいずれか１項に記載のデバイス。
9. 前記処理手段（ＭＴ）は、コンテンツの使用される前記部分に最も適する前記受信側ユーザの前記端末（ＴＣ）を選択するように構成されることを特徴とする、請求項１乃至８のいずれか１項に記載のデバイス。
10. 前記処理手段（ＭＴ）は、（少なくとも）即時送信、前記受信側ユーザの端末（ＴＣ）による１つのマルチメディア・コンテンツの再生の終了まで遅延される送信、および前記受信側ユーザの端末（ＴＣ）による１つのマルチメディア・コンテンツの再生中の選択された瞬間まで遅延される送信の中から前記アプリケーション通知の送信に最も適する瞬間を選択するように構成されることを特徴とする、請求項１乃至９のいずれか１項に記載のデバイス。
11. 前記処理手段（ＭＴ）は、そのコンテンツの少なくとも１つの部分の利用規約（１つまたは複数）を定義する少なくとも１つのパラメータが欠けているアプリケーション通知が受信される時に必ず、ｉ）他のパラメータならびに選択されたルール（１つまたは複数）および／またはポリシー（１つまたは複数）に依存して、ユーザおよび／またはコンテキスト情報ならびに／あるいは前記アプリケーション通知のパラメータ（１つまたは複数）ならびに／あるいは前記選択された端末（ＴＣ）の特性（１つまたは複数）を考慮に入れて各欠けている定義パラメータを判定し、ｉｉ）送信すべき前記アプリケーション通知を各判定された定義パラメータに追加することによって送信すべき前記アプリケーション通知を適合させるように構成されることを特徴とする、請求項１乃至１０のいずれか１項に記載のデバイス。
12. コンテンツ部分の各利用規約は、少なくとも、前記判定されたコンテンツ部分を使用するための１つのマルチメディア・コンテンツの再生における瞬間的中断、前記判定されたコンテンツ部分のテキスト−サウンド変換、前記判定されたコンテンツ部分のサウンド−テキスト変換、第１言語から第２言語への変換、および前記適合されたアプリケーション通知の受信時の可聴アラート信号の発行を含む群から選択されることを特徴とする、請求項１１に記載のデバイス。
13. ｉ）前記処理手段（ＭＴ）によって行われる適合判断を適用することと、ｉｉ）前記処理手段（ＭＴ）によって適合された前記アプリケーション通知を前記端末（ＴＣ）に配送することと、ｉｉｉ）前記適合されたアプリケーション通知が実際に前記受信側端末（ＴＣ）に送信されたことを保証することと、ｉｖ）これらの端末が前記適合されたアプリケーション通知のコンテンツをそのパラメータによって定義される利用規約に従って使用したことを保証することとを課せられる制御手段（ＭＣＵ）を含むことを特徴とする、請求項１乃至１２のいずれか１項に記載のデバイス。
14. 前記制御手段（ＭＣＵ）は、ストレージ手段（Ｂ４）内に、前記端末ＴＣに送信されたかこれから送信される前記適合されたアプリケーション通知のすべてを格納するように構成されることを特徴とする、請求項１３に記載のデバイス。
15. 請求項１乃至１４のいずれか１項に記載の処理デバイス（Ｄ）を含むことを特徴とする、通信ネットワーク（ＲＣ）のサービス・プラットフォーム用のサーバ（ＳＲ）。

Images