受信器／デコーダの接続の管理のための機構
【課題】
【解決手段】
本発明は、通信装置に関し、変調および復調するための手段を有し、一方を通信ネットワークに接続し他方を少なくとの一つの受信器／デコーダに接続する通信装置であって、前記受信器／デコーダからの要求の受信に応答して、前記通信ネットワークの利用可能なバンド幅に基づき、以下の異なる可能性について選択するための手段：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること、
を有する通信装置である。
本発明は、通信方法にも関連する。
【解決手段】
本発明は、通信装置に関し、変調および復調するための手段を有し、一方を通信ネットワークに接続し他方を少なくとの一つの受信器／デコーダに接続する通信装置であって、前記受信器／デコーダからの要求の受信に応答して、前記通信ネットワークの利用可能なバンド幅に基づき、以下の異なる可能性について選択するための手段：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること、
を有する通信装置である。
本発明は、通信方法にも関連する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報通信技術の領域に関する。
【０００２】
本発明は、より詳細には受信器／デコーダに係る管理のための機構に関する。
【背景技術】
【０００３】
特許文献１（モトローラ）は、ＩＰサブネットワークのマルチキャスト・データの管理のための方法および装置を開示している。実施例の通信システムは、連結されるサブネットワークを監視する受信器／デコーダを有している。マルチキャスト・ルータは、受信器／デコーダの要請に応じて、一つ以上のグループ（例えばビデオ・プログラムグループ）に受信器／デコーダを連結する。例えば、受信器／デコーダが第１のグループを去る場合、ルーターに対して「切断」（ｌｅａｖｅ）メッセージを送信する。他の受信器／デコーダは、これを認識しているので、この第１のグループにサブスクライブ（ｓｕｂｓｃｒｉｂｅ）するためには、「参加」（ｊｏｉｎ）メッセージを送らなければならない。このため、ルーターは、それがこの第１のグループをサブネットワークに連結しなければならないということを直ちに知らされる。
【０００４】
特許文献２（Ｍａｒｃｏｎｉ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）は、帯域幅制御を有する会議のための方法および装置を開示している。この先行技術文献は、受信器／デコーダの要求の受信に応答して、通信ネットワーク上の利用可能帯域幅を考慮し、以下の異なる可能性について選択するための手段を有する装置を開示していない。
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること。
【０００５】
非特許文献１は、通信ネットワークのサービス品質を管理するための解決策を開示している。この先行技術文献は、受信器／デコーダの要求の受信に応答して、通信ネットワーク上の利用可能帯域幅を考慮した、以下の異なる可能性について選択するための手段を有する装置を開示していない。
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること。
【０００６】
特許文献３は、マルチキャスト受信器のためのアドミッション制御手段を開示している。この先行技術文献は、受信器／デコーダの要求の受信に応答して、通信ネットワーク上の利用可能帯域幅を考慮した、以下の異なる可能性について選択するための手段を有する装置を開示していない。
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】米国特許出願番号第２００３／０３５３７８号
【特許文献２】米国特許出願番号第２００５／２３７９５２号
【特許文献３】米国特許出願番号第２００６／１４６８５７号
【非特許文献】
【０００８】
【非特許文献１】「Ｍｕｌｔｉｃａｓｔｉｎｇ ｉｎ Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅ Ｄｏｍａｉｎｓ」 （Ｂａｉｊａｎ Ｙａｎｇ ｅｔ ａｌ， ＩＥＥＥ Ｇｌｏｂａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｎｆｅｒｅｎｃｅ， １７ Ｎｏｖｅｍｂｅｒ ２００３）
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明は、ＡＤＳＬ（非同期デジタル加入者回線）ゲートウェイに関連し、複数の受信器／デコーダまたは、セットトップボックス（ＳＴＢ： Ｓｅｔ Ｔｏｐ Ｂｏｘｅｓ）の技術に関する。他の受信器／デコーダによって伝送されるストリームによって使用されるＡＤＳＬバンド幅があまりに広い場合、受信器／デコーダをマルチキャスト・ストリームに接続することを拒否するメカニズムが実装されなければならない。
【００１０】
１つの解決策は、パケットが各受信器／デコーダによって送信されたＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）をゲートウェイが監視することである。そして、各ストリームの特性を定義しているサービス・プランを使用して、使用する総バンド幅を算出することである。マルチキャスト・ストリームを受信するためには、受信器／デコーダがマルチキャストにＩＧＭＰ「参加」（ｊｏｉｎ）パケットを送信しなければならない。このパケットはマルチキャスト・ルータのチェーンに反映され、一つのルーターが、要求されたストリームを、要求が受信された他のルーターのポートに要請する。「参加」パケットの受け取り通知は、受信器／デコーダに返送されない。
【００１１】
ゲートウェイがこのＩＧＭＰパケットを傍受し、かつバンド幅がオーバーロードを防止すると決めた場合、受信器／デコーダへのためのストリームの増加は行われない。従って、テレビスクリーンは、黒いままの状態となる。
【課題を解決するための手段】
【００１２】
本発明は、従来技術のようにバンド幅に負担をかすぎることのリスクを回避するために、受信器／デコーダにストリームが伝送されず、スクリーンが黒いままの状態になるという、欠点を解決するための手段を提供する。
【００１３】
この目的のために、その典型的な例として、本発明は、一方が通信ネットワークに対接続され、他方が少なくとも一つの受信器／デコーダに接続される通信装置に関する。そして、前記受信器／デコーダからの要求の受信に応答して、通信ネットワークのバンド幅に基づき、以下の異なる可能性について選択するための手段を有することを特徴とする：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること。
【００１４】
好ましくは、さらに前記装置は、すべてのマルチキャストアドレス、および少なくとも一つの対応するストリームの特徴、例えばプログラム名、使用するコーデックまたは使用するバンド幅、を含んでいるサービス・プランを操作するための手段を有する。
【００１５】
都合のよいことに、前記要求は、確認されたＩＧＭＰ要求によって確立し、前記装置は、当該通信装置に接続している受信器／デコーダの各々に受信されているストリームの表を操作するための手段を有する。
【００１６】
好ましくは、前記装置は、通信ネットワークに使用されているバンド幅を計算するための手段および、サービス・プランおよびストリームの表から、新しいＩＧＭＰ要求の新しいオンデマンドのストリームの受信のために必要とされる、通信ネットワークのバンド幅を計算するための手段を有する。
【００１７】
都合のよいことに、前記装置は、ＡＤＳＬ（非同期デジタル加入者回線）と互換性を持つ。
【００１８】
有利な変形例によれば、前記装置は、コンフィギュレーション表にＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を有し、かつ前記ＵＲＬから前記予め設定されたマルチメディア・ファイルを読み出すための手段、および前記マルチメディア・ファイルを前記受信器／デコーダにマルチキャスト・ストリームの状態で、およびループの状態で送信するための手段を有する。
【００１９】
好ましくは、マルチメディア・ファイルは、ＨＴＴＰプロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によって、前記ＵＲＬから読み出される。
【００２０】
実施例によれば、前記装置は、前記マルチメディア・ファイルをフォーマットするための手段を有する。
【００２１】
前記マルチメディア・ファイルは、ビデオ、アニメーションおよび／または音声のメッセージを含んでもよい。
【００２２】
好ましくは、前記装置は、変調および復調するための手段を有する。
【００２３】
本発明は通信装置を使用する通信の方法に関し、一方が通信ネットワークに接続され、他方が少なくとも一つの受信器／デコーダに接続される通信装置を使用した通信方法であって、前記受信器／デコーダからの要求の受信に応答して、前記通信ネットワークの利用可能なバンド幅に基づき、以下の異なる可能性について選択するステップ：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること、を有する方法である。
【００２４】
好ましくは、さらに前記方法は、すべてのマルチキャストアドレス、および少なくとも一つの対応するストリームの特徴、例えばプログラム名、使用するコーデックまたは使用するバンド幅、を含んでいるサービス・プランを操作するステップを有する。
【００２５】
都合のよいことに、前記方法は、確認されたＩＧＭＰ要求によって確立し、該通信装置に接続している受信器／デコーダの各々に受信されているストリームの表を操作するステップを有する。
【００２６】
好ましくは、前記方法は、通信ネットワークに使用されているバンド幅を計算するステップおよび、前記サービス・プランおよび前記ストリームの表から、新しいＩＧＭＰ要求の新しいオンデマンドのストリームの受信のために必要とされる、通信ネットワークのバンド幅を計算するステップを有する。
【００２７】
有利な変形例によれば、前記方法は、コンフィギュレーション表にＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を有し、かつ前記ＵＲＬから前記予め設定されたマルチメディア・ファイルを読み出すためのステップ、および前記マルチメディア・ファイルを前記受信器／デコーダにマルチキャスト・ストリームの状態で、およびループの状態で送信するステップを有する。
【００２８】
本発明は、図を参照することによって、事例として示されている実施例に係る以下の記述から、よりよく理解される。
【発明の効果】
【００２９】
本発明に係る装置および方法は以下のように多数の効果がある：
・それらは、ＳＴＢのいかなる修正も必要としない；
・それらは、受信器／デコーダ（ゲートウェイ）のいかなる付加的な計算機能も必要としない。なぜなら、ビデオ符号化を行わないからである；
・サービス拒否の各場合において、異なるＵＲＬを定めることが可能である；
・ゲートウェイによって送信されたＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コマンドのパラメータを追加することが可能である。そして、ＨＴＴＰサーバが、即座に（ｏｎ ｔｈｅ ｆｌｙ）、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）情報ファイルを生成することを可能にする；および、
・より低くされたビットレートおよび低い解像度を有する他のストリームにリダイレクションすることが可能である。
【図面の簡単な説明】
【００３０】
【図１】本発明の方法の実施例を例示した図である。
【図２】本発明の通信装置を例示した図である。
【図３】本発明の方法の実施例を例示した図である。
【図４】ＩＧＭＰパケットを例示した図である。
【発明を実施するための形態】
【実施例】
【００３１】
通信装置（または住宅用ゲートウェイ）（１）（図１および２に示される）は、次の部分を有する。
・プロセッサ（１１）、
・ランダム・アクセス・メモリ（３１）、
・記憶装置（３２）、
・外部通信ネットワークに対するインタフェース（１５）、例えばＤＳＬまたは光ファイバーネットワークとのインタフェース、
・ＷＬＡＮインタフェース（１４）、
・ＤＥＣＴインタフェース（１２）、
・ブルートゥース・インタフェース（１３）および、
・複数のイーサネット（登録商標）・インタフェース（２１、２２、２３、２４）。
【００３２】
通信装置（または住宅用ゲートウェイ）（１）は、マルチキャストアドレスの全ておよび対応するストリームの特徴（プログラム名、コーデックおよび使用するバンド幅）を含む「サービス・プラン」を読み出す。通信装置は、ＩＧＭＰ要求を確認して、受信されたストリームの表を維持する。このテーブルおよびサービス・プランから、これは、新しいＩＧＭＰ要求によって、使用するバンド幅、および必要とされる付加的なバンド幅を計算する。利用可能なバンド幅（例えばＡＤＳＬ）から、通信装置は、この要求が修正なしで送信するか、より低い品質のストリームにリダイレクトされなければならないかまたは、予め設定されたマルチメディア・ファイルを伝達することを拒否されなければならないかどうかを決める。
【００３３】
実施例において、サービス・プランは、ネットワークで利用するために、ユーザの住宅に、いくつかのデコーダを設置する申し込みを要求する場合がある。申し込みはユーザ毎に異なるか、ＩＰ当たり異なってもよい：ポートアドレスは、サービス毎にユニークである。
【００３４】
各サービスにかかわるパラメータのリストは、ゲートウェイの機能によって異ならせてもよい。
【００３５】
特定の実施例では、ゲートウェイに供給されるサービス・プランは、以下の形を有する：すなわち、サービス名、ＩＰ：ポート・サービスアドレス、ビデオ符号化タイプ、音声符号化タイプ、サービスビットレートＫｂｉｔ／ｓである。
【００３６】
本発明において、正しい符号化フォーマットの情報を送信するためには、ゲートウェイはビデオおよびおそらく音声（声のメッセージがユーザに提供される場合）のコーデックの形式を知っていることを必要とする。ゲートウェイは、接続したデコーダのキャパシティを知らない。しかし、デコーダがその復号の能力に対応しないストリームを要求しないと仮定してもよい。
【００３７】
サービス・プランの例を表１に示す。
【００３８】
【表１】
実際には、サービス・プランが、必ずしも表形式であるというわけではない。
【００３９】
デコーダ（セットトップボックス）とＩＧＭＰスイッチ／ルーターの間に通過しているＩＧＭＰプロトコルによって、ゲートウェイ（例えばＡＤＳＬ）は、ネットワークに接続されている装置が受け入れるストリームの全てを知ることができ、受信されたストリームからテーブルを作成する。
【００４０】
このストリームの表は、転送先の受信器のアドレスに係る受信されたストリームに対応するＩＰアドレスをパラメータとして有する。
【００４１】
ストリーム・テーブルは、ペアのリストである。したがって、このペアは、ソース・ストリームのＩＰアドレスと関連した転送先のＩＰアドレスのペアを含む。
【００４２】
例えば、その例を表２に示す。
【００４３】
【表２】
実際には、ストリーム・テーブルが、必ずしも表形式であるというわけではない。ゲートウェイは、前記受信器／デコーダからの要求の受信に応じて、低い品質のストリームの要求に変更してもよい。ＩＧＭＰパケットに行う修正は、本明細書において説明する。ＩＧＭＰプロトコルは、ＲＦＣ ２２３６によって定義される。
【００４４】
ＩＧＭＰパケットは、８つのオクテットで形成される。図４にその書式を示す。
・タイプ（Ｔｙｐｅ）には、送信されるコマンドが記述されている。
・最大応答時間（Ｍａｘ Ｒｅｓｐ Ｔｉｍｅ）には、プロトコルを実装するステートマシンにおいて使用するタイマーの値が記述されている。
・チェックサムは、パケットデータの完全性を補償する。
・グループアドレスには、ユーザが、サブスクライブあるいは離れる（ｌｅａｖｅ）グループのマルチキャストアドレスが記述されている。
【００４５】
ゲートウェイは、アクセスするネットワークに発信する前にセットトップボックス（ＳＴＢ）から受信するＩＧＭＰ要求を修正することを可能にするリソースを有する。
【００４６】
このため、例えば、ＳＴＢの要求より低い品質のストリームを受信するために、サービステーブルから、Ｔｙｐｅ Ｍｅｍｂｅｒｓｈｉｐ Ｒｅｐｏｒｔ（０ｘ１６）コマンドのグループアドレスのフィールドが修正される。
【００４７】
Ｔｙｐｅ Ｌｅａｖｅ Ｇｒｏｕｐ（０ｘ１７）の要求にも、同じ修正を行なわなければならない点に留意する必要がある。
【００４８】
同様に、操作がＳＴＢに対して透明であるようにするため、アクセスネットワークから受信されるＴｙｐｅ Ｍｅｍｂｅｒｓｈｉｐ Ｑｕｅｒｙ（０ｘ１１）に対しては、グループアドレスのフィールドを修正してＳＴＢに送信する。
【００４９】
ゲートウェイは、以下の通りに進行してもよい：すなわち、ＩＧＭＰ要求をアクセスすべきネットワークに発信せず、そして、それ自身が、ビデオストリームを作り出し、おそらくそれがマルチキャストパケットの形で静止画像（ｆｉｘｅｄ ｉｍａｇｅ）を表して、ＳＴＢに発信するようにしてもよい。
【００５０】
以下に、ＩＧＭＰ要求が拒否され、マルチメディア・ファイルが伝達される場合を詳述する。
【００５１】
図１に示されるように、住宅用ゲートウェイは、そのコンフィギュレーション表に、ビデオ・ファイルがＨＴＴＰによって読み出されるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を含む。このビデオ・ファイルは、フォーマッティングの後、ループした形で、マルチキャスト・ストリームとしてゲートウェイによってＳＴＢに発信される。このため、ＡＤＳＬバンド幅が、ループの配信の間、使われないこととなる。
【００５２】
このファイルは、要請されたチャネルが配信されない理由をユーザに説明している情報を含む（例えば：あなたのＡＤＳＬサブスクリプションは、２つの高精細ストリームの同時表示を許容しておりません。あなたの回線の要領を増加させるためには、次のＵＲＬにアクセスしてください：ｈｔｔｐ：／／ｗｗｗ．ｏｒａｎｇｅ−ｆｔ．ｃｏｍ）。それがビデオ・ファイルとして、アニメーション（および声のメッセージ）を含んでもよい。
【００５３】
「サービス・プラン」を検索することによって、マルチキャストアドレスごとに、ビデオおよび使用するコーデックを通信装置が知ることができる。送信されるこの予め設定されたマルチメディア・ファイルは、同様の方式でエンコードされている。
【００５４】
本発明は、上述した説明において例として記載されている。当業者は、特許の範囲を超えることなく、本発明の変形例を作り出すことができるものと理解される。
【技術分野】
【０００１】
本発明は情報通信技術の領域に関する。
【０００２】
本発明は、より詳細には受信器／デコーダに係る管理のための機構に関する。
【背景技術】
【０００３】
特許文献１（モトローラ）は、ＩＰサブネットワークのマルチキャスト・データの管理のための方法および装置を開示している。実施例の通信システムは、連結されるサブネットワークを監視する受信器／デコーダを有している。マルチキャスト・ルータは、受信器／デコーダの要請に応じて、一つ以上のグループ（例えばビデオ・プログラムグループ）に受信器／デコーダを連結する。例えば、受信器／デコーダが第１のグループを去る場合、ルーターに対して「切断」（ｌｅａｖｅ）メッセージを送信する。他の受信器／デコーダは、これを認識しているので、この第１のグループにサブスクライブ（ｓｕｂｓｃｒｉｂｅ）するためには、「参加」（ｊｏｉｎ）メッセージを送らなければならない。このため、ルーターは、それがこの第１のグループをサブネットワークに連結しなければならないということを直ちに知らされる。
【０００４】
特許文献２（Ｍａｒｃｏｎｉ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）は、帯域幅制御を有する会議のための方法および装置を開示している。この先行技術文献は、受信器／デコーダの要求の受信に応答して、通信ネットワーク上の利用可能帯域幅を考慮し、以下の異なる可能性について選択するための手段を有する装置を開示していない。
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること。
【０００５】
非特許文献１は、通信ネットワークのサービス品質を管理するための解決策を開示している。この先行技術文献は、受信器／デコーダの要求の受信に応答して、通信ネットワーク上の利用可能帯域幅を考慮した、以下の異なる可能性について選択するための手段を有する装置を開示していない。
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること。
【０００６】
特許文献３は、マルチキャスト受信器のためのアドミッション制御手段を開示している。この先行技術文献は、受信器／デコーダの要求の受信に応答して、通信ネットワーク上の利用可能帯域幅を考慮した、以下の異なる可能性について選択するための手段を有する装置を開示していない。
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】米国特許出願番号第２００３／０３５３７８号
【特許文献２】米国特許出願番号第２００５／２３７９５２号
【特許文献３】米国特許出願番号第２００６／１４６８５７号
【非特許文献】
【０００８】
【非特許文献１】「Ｍｕｌｔｉｃａｓｔｉｎｇ ｉｎ Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅ Ｄｏｍａｉｎｓ」 （Ｂａｉｊａｎ Ｙａｎｇ ｅｔ ａｌ， ＩＥＥＥ Ｇｌｏｂａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｎｆｅｒｅｎｃｅ， １７ Ｎｏｖｅｍｂｅｒ ２００３）
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明は、ＡＤＳＬ（非同期デジタル加入者回線）ゲートウェイに関連し、複数の受信器／デコーダまたは、セットトップボックス（ＳＴＢ： Ｓｅｔ Ｔｏｐ Ｂｏｘｅｓ）の技術に関する。他の受信器／デコーダによって伝送されるストリームによって使用されるＡＤＳＬバンド幅があまりに広い場合、受信器／デコーダをマルチキャスト・ストリームに接続することを拒否するメカニズムが実装されなければならない。
【００１０】
１つの解決策は、パケットが各受信器／デコーダによって送信されたＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）をゲートウェイが監視することである。そして、各ストリームの特性を定義しているサービス・プランを使用して、使用する総バンド幅を算出することである。マルチキャスト・ストリームを受信するためには、受信器／デコーダがマルチキャストにＩＧＭＰ「参加」（ｊｏｉｎ）パケットを送信しなければならない。このパケットはマルチキャスト・ルータのチェーンに反映され、一つのルーターが、要求されたストリームを、要求が受信された他のルーターのポートに要請する。「参加」パケットの受け取り通知は、受信器／デコーダに返送されない。
【００１１】
ゲートウェイがこのＩＧＭＰパケットを傍受し、かつバンド幅がオーバーロードを防止すると決めた場合、受信器／デコーダへのためのストリームの増加は行われない。従って、テレビスクリーンは、黒いままの状態となる。
【課題を解決するための手段】
【００１２】
本発明は、従来技術のようにバンド幅に負担をかすぎることのリスクを回避するために、受信器／デコーダにストリームが伝送されず、スクリーンが黒いままの状態になるという、欠点を解決するための手段を提供する。
【００１３】
この目的のために、その典型的な例として、本発明は、一方が通信ネットワークに対接続され、他方が少なくとも一つの受信器／デコーダに接続される通信装置に関する。そして、前記受信器／デコーダからの要求の受信に応答して、通信ネットワークのバンド幅に基づき、以下の異なる可能性について選択するための手段を有することを特徴とする：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること。
【００１４】
好ましくは、さらに前記装置は、すべてのマルチキャストアドレス、および少なくとも一つの対応するストリームの特徴、例えばプログラム名、使用するコーデックまたは使用するバンド幅、を含んでいるサービス・プランを操作するための手段を有する。
【００１５】
都合のよいことに、前記要求は、確認されたＩＧＭＰ要求によって確立し、前記装置は、当該通信装置に接続している受信器／デコーダの各々に受信されているストリームの表を操作するための手段を有する。
【００１６】
好ましくは、前記装置は、通信ネットワークに使用されているバンド幅を計算するための手段および、サービス・プランおよびストリームの表から、新しいＩＧＭＰ要求の新しいオンデマンドのストリームの受信のために必要とされる、通信ネットワークのバンド幅を計算するための手段を有する。
【００１７】
都合のよいことに、前記装置は、ＡＤＳＬ（非同期デジタル加入者回線）と互換性を持つ。
【００１８】
有利な変形例によれば、前記装置は、コンフィギュレーション表にＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を有し、かつ前記ＵＲＬから前記予め設定されたマルチメディア・ファイルを読み出すための手段、および前記マルチメディア・ファイルを前記受信器／デコーダにマルチキャスト・ストリームの状態で、およびループの状態で送信するための手段を有する。
【００１９】
好ましくは、マルチメディア・ファイルは、ＨＴＴＰプロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によって、前記ＵＲＬから読み出される。
【００２０】
実施例によれば、前記装置は、前記マルチメディア・ファイルをフォーマットするための手段を有する。
【００２１】
前記マルチメディア・ファイルは、ビデオ、アニメーションおよび／または音声のメッセージを含んでもよい。
【００２２】
好ましくは、前記装置は、変調および復調するための手段を有する。
【００２３】
本発明は通信装置を使用する通信の方法に関し、一方が通信ネットワークに接続され、他方が少なくとも一つの受信器／デコーダに接続される通信装置を使用した通信方法であって、前記受信器／デコーダからの要求の受信に応答して、前記通信ネットワークの利用可能なバンド幅に基づき、以下の異なる可能性について選択するステップ：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること、を有する方法である。
【００２４】
好ましくは、さらに前記方法は、すべてのマルチキャストアドレス、および少なくとも一つの対応するストリームの特徴、例えばプログラム名、使用するコーデックまたは使用するバンド幅、を含んでいるサービス・プランを操作するステップを有する。
【００２５】
都合のよいことに、前記方法は、確認されたＩＧＭＰ要求によって確立し、該通信装置に接続している受信器／デコーダの各々に受信されているストリームの表を操作するステップを有する。
【００２６】
好ましくは、前記方法は、通信ネットワークに使用されているバンド幅を計算するステップおよび、前記サービス・プランおよび前記ストリームの表から、新しいＩＧＭＰ要求の新しいオンデマンドのストリームの受信のために必要とされる、通信ネットワークのバンド幅を計算するステップを有する。
【００２７】
有利な変形例によれば、前記方法は、コンフィギュレーション表にＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を有し、かつ前記ＵＲＬから前記予め設定されたマルチメディア・ファイルを読み出すためのステップ、および前記マルチメディア・ファイルを前記受信器／デコーダにマルチキャスト・ストリームの状態で、およびループの状態で送信するステップを有する。
【００２８】
本発明は、図を参照することによって、事例として示されている実施例に係る以下の記述から、よりよく理解される。
【発明の効果】
【００２９】
本発明に係る装置および方法は以下のように多数の効果がある：
・それらは、ＳＴＢのいかなる修正も必要としない；
・それらは、受信器／デコーダ（ゲートウェイ）のいかなる付加的な計算機能も必要としない。なぜなら、ビデオ符号化を行わないからである；
・サービス拒否の各場合において、異なるＵＲＬを定めることが可能である；
・ゲートウェイによって送信されたＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コマンドのパラメータを追加することが可能である。そして、ＨＴＴＰサーバが、即座に（ｏｎ ｔｈｅ ｆｌｙ）、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）情報ファイルを生成することを可能にする；および、
・より低くされたビットレートおよび低い解像度を有する他のストリームにリダイレクションすることが可能である。
【図面の簡単な説明】
【００３０】
【図１】本発明の方法の実施例を例示した図である。
【図２】本発明の通信装置を例示した図である。
【図３】本発明の方法の実施例を例示した図である。
【図４】ＩＧＭＰパケットを例示した図である。
【発明を実施するための形態】
【実施例】
【００３１】
通信装置（または住宅用ゲートウェイ）（１）（図１および２に示される）は、次の部分を有する。
・プロセッサ（１１）、
・ランダム・アクセス・メモリ（３１）、
・記憶装置（３２）、
・外部通信ネットワークに対するインタフェース（１５）、例えばＤＳＬまたは光ファイバーネットワークとのインタフェース、
・ＷＬＡＮインタフェース（１４）、
・ＤＥＣＴインタフェース（１２）、
・ブルートゥース・インタフェース（１３）および、
・複数のイーサネット（登録商標）・インタフェース（２１、２２、２３、２４）。
【００３２】
通信装置（または住宅用ゲートウェイ）（１）は、マルチキャストアドレスの全ておよび対応するストリームの特徴（プログラム名、コーデックおよび使用するバンド幅）を含む「サービス・プラン」を読み出す。通信装置は、ＩＧＭＰ要求を確認して、受信されたストリームの表を維持する。このテーブルおよびサービス・プランから、これは、新しいＩＧＭＰ要求によって、使用するバンド幅、および必要とされる付加的なバンド幅を計算する。利用可能なバンド幅（例えばＡＤＳＬ）から、通信装置は、この要求が修正なしで送信するか、より低い品質のストリームにリダイレクトされなければならないかまたは、予め設定されたマルチメディア・ファイルを伝達することを拒否されなければならないかどうかを決める。
【００３３】
実施例において、サービス・プランは、ネットワークで利用するために、ユーザの住宅に、いくつかのデコーダを設置する申し込みを要求する場合がある。申し込みはユーザ毎に異なるか、ＩＰ当たり異なってもよい：ポートアドレスは、サービス毎にユニークである。
【００３４】
各サービスにかかわるパラメータのリストは、ゲートウェイの機能によって異ならせてもよい。
【００３５】
特定の実施例では、ゲートウェイに供給されるサービス・プランは、以下の形を有する：すなわち、サービス名、ＩＰ：ポート・サービスアドレス、ビデオ符号化タイプ、音声符号化タイプ、サービスビットレートＫｂｉｔ／ｓである。
【００３６】
本発明において、正しい符号化フォーマットの情報を送信するためには、ゲートウェイはビデオおよびおそらく音声（声のメッセージがユーザに提供される場合）のコーデックの形式を知っていることを必要とする。ゲートウェイは、接続したデコーダのキャパシティを知らない。しかし、デコーダがその復号の能力に対応しないストリームを要求しないと仮定してもよい。
【００３７】
サービス・プランの例を表１に示す。
【００３８】
【表１】
実際には、サービス・プランが、必ずしも表形式であるというわけではない。
【００３９】
デコーダ（セットトップボックス）とＩＧＭＰスイッチ／ルーターの間に通過しているＩＧＭＰプロトコルによって、ゲートウェイ（例えばＡＤＳＬ）は、ネットワークに接続されている装置が受け入れるストリームの全てを知ることができ、受信されたストリームからテーブルを作成する。
【００４０】
このストリームの表は、転送先の受信器のアドレスに係る受信されたストリームに対応するＩＰアドレスをパラメータとして有する。
【００４１】
ストリーム・テーブルは、ペアのリストである。したがって、このペアは、ソース・ストリームのＩＰアドレスと関連した転送先のＩＰアドレスのペアを含む。
【００４２】
例えば、その例を表２に示す。
【００４３】
【表２】
実際には、ストリーム・テーブルが、必ずしも表形式であるというわけではない。ゲートウェイは、前記受信器／デコーダからの要求の受信に応じて、低い品質のストリームの要求に変更してもよい。ＩＧＭＰパケットに行う修正は、本明細書において説明する。ＩＧＭＰプロトコルは、ＲＦＣ ２２３６によって定義される。
【００４４】
ＩＧＭＰパケットは、８つのオクテットで形成される。図４にその書式を示す。
・タイプ（Ｔｙｐｅ）には、送信されるコマンドが記述されている。
・最大応答時間（Ｍａｘ Ｒｅｓｐ Ｔｉｍｅ）には、プロトコルを実装するステートマシンにおいて使用するタイマーの値が記述されている。
・チェックサムは、パケットデータの完全性を補償する。
・グループアドレスには、ユーザが、サブスクライブあるいは離れる（ｌｅａｖｅ）グループのマルチキャストアドレスが記述されている。
【００４５】
ゲートウェイは、アクセスするネットワークに発信する前にセットトップボックス（ＳＴＢ）から受信するＩＧＭＰ要求を修正することを可能にするリソースを有する。
【００４６】
このため、例えば、ＳＴＢの要求より低い品質のストリームを受信するために、サービステーブルから、Ｔｙｐｅ Ｍｅｍｂｅｒｓｈｉｐ Ｒｅｐｏｒｔ（０ｘ１６）コマンドのグループアドレスのフィールドが修正される。
【００４７】
Ｔｙｐｅ Ｌｅａｖｅ Ｇｒｏｕｐ（０ｘ１７）の要求にも、同じ修正を行なわなければならない点に留意する必要がある。
【００４８】
同様に、操作がＳＴＢに対して透明であるようにするため、アクセスネットワークから受信されるＴｙｐｅ Ｍｅｍｂｅｒｓｈｉｐ Ｑｕｅｒｙ（０ｘ１１）に対しては、グループアドレスのフィールドを修正してＳＴＢに送信する。
【００４９】
ゲートウェイは、以下の通りに進行してもよい：すなわち、ＩＧＭＰ要求をアクセスすべきネットワークに発信せず、そして、それ自身が、ビデオストリームを作り出し、おそらくそれがマルチキャストパケットの形で静止画像（ｆｉｘｅｄ ｉｍａｇｅ）を表して、ＳＴＢに発信するようにしてもよい。
【００５０】
以下に、ＩＧＭＰ要求が拒否され、マルチメディア・ファイルが伝達される場合を詳述する。
【００５１】
図１に示されるように、住宅用ゲートウェイは、そのコンフィギュレーション表に、ビデオ・ファイルがＨＴＴＰによって読み出されるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を含む。このビデオ・ファイルは、フォーマッティングの後、ループした形で、マルチキャスト・ストリームとしてゲートウェイによってＳＴＢに発信される。このため、ＡＤＳＬバンド幅が、ループの配信の間、使われないこととなる。
【００５２】
このファイルは、要請されたチャネルが配信されない理由をユーザに説明している情報を含む（例えば：あなたのＡＤＳＬサブスクリプションは、２つの高精細ストリームの同時表示を許容しておりません。あなたの回線の要領を増加させるためには、次のＵＲＬにアクセスしてください：ｈｔｔｐ：／／ｗｗｗ．ｏｒａｎｇｅ−ｆｔ．ｃｏｍ）。それがビデオ・ファイルとして、アニメーション（および声のメッセージ）を含んでもよい。
【００５３】
「サービス・プラン」を検索することによって、マルチキャストアドレスごとに、ビデオおよび使用するコーデックを通信装置が知ることができる。送信されるこの予め設定されたマルチメディア・ファイルは、同様の方式でエンコードされている。
【００５４】
本発明は、上述した説明において例として記載されている。当業者は、特許の範囲を超えることなく、本発明の変形例を作り出すことができるものと理解される。
【特許請求の範囲】
【請求項１】
一方が通信ネットワークに接続され、他方が少なくとも一つの受信器／デコーダに接続される通信装置であって、前記受信器／デコーダからの要求の受信に応答して、前記通信ネットワークの利用可能なバンド幅に基づき、以下の異なる可能性について選択するための手段：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること、
を有する通信装置。
【請求項２】
すべてのマルチキャストアドレス、および少なくとも一つの対応するストリームの特徴、例えばプログラム名、使用するコーデックまたは使用するバンド幅、を含んでいるサービス・プランを操作するための手段、
を有する請求項１記載の通信装置。
【請求項３】
前記要求は、確認されたＩＧＭＰ要求によって確立し、当該通信装置に接続している受信器／デコーダの各々に受信されているストリームの表を操作するための手段、
を有する請求項１または２記載の通信装置。
【請求項４】
前記サービス・プランおよび前記ストリームの表から、通信ネットワークに使用されているバンド幅を計算するための手段および、新しいＩＧＭＰ要求の新しいオンデマンドのストリームの受信のために必要とされる、通信ネットワークのバンド幅を計算するための手段、
を有する請求項２または３に記載の通信装置。
【請求項５】
ＡＤＳＬ（非同期デジタル加入者回線）と互換性を持つ、請求項１、２、３または４のいずれか１項記載の通信装置。
【請求項６】
コンフィギュレーション表にＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を有し、かつ前記ＵＲＬから前記予め設定されたマルチメディア・ファイルを読み出すための手段、および前記マルチメディア・ファイルを前記受信器／デコーダにマルチキャスト・ストリームの状態で、およびループの状態で送信するための手段、
を有する請求項１ないし５のいずれか１項記載の通信装置。
【請求項７】
前記マルチメディア・ファイルは、ＨＴＴＰプロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によって、前記ＵＲＬから読み出される、請求項６記載の通信装置。
【請求項８】
前記マルチメディア・ファイルをフォーマットするための手段、を有する請求項６または７記載の通信装置。
【請求項９】
前記マルチメディア・ファイルは、ビデオを含む、請求項１ないし８のいずれか１項記載の通信装置。
【請求項１０】
前記マルチメディア・ファイルは、アニメーションを含む、請求項１ないし９のいずれか１項記載の通信装置。
【請求項１１】
前記マルチメディア・ファイルは、音声メッセージを含む、請求項１ないし１０のいずれか１項記載の通信装置。
【請求項１２】
変調および復調するための手段、を有する、請求項１ないし１１のいずれか１項記載の通信装置。
【請求項１３】
一方が通信ネットワークに接続され、他方が少なくとも一つの受信器／デコーダに接続される通信装置を使用した通信方法であって、前記受信器／デコーダからの要求の受信に応答して、前記通信ネットワークの利用可能なバンド幅に基づき、以下の異なる可能性について選択するステップ：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること、
を有する通信方法。
【請求項１４】
すべてのマルチキャストアドレス、および少なくとも一つの対応するストリームの特徴、例えばプログラム名、使用するコーデックまたは使用するバンド幅、を含んでいるサービス・プランを操作するステップ、
を有する請求項１３記載の通信方法。
【請求項１５】
前記要求は、確認されたＩＧＭＰ要求によって確立し、該通信装置に接続している受信器／デコーダの各々に受信されているストリームの表を操作するステップ、
を有する請求項１３または１４記載の通信方法。
【請求項１６】
前記サービス・プランおよび前記ストリームの表から、通信ネットワークに使用されているバンド幅を計算するステップおよび、新しいＩＧＭＰ要求の新しいオンデマンドのストリームの受信のために必要とされる、通信ネットワークのバンド幅を計算するステップ、
を有する請求項１４または１５に記載の通信方法。
【請求項１７】
コンフィギュレーション表にＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を有し、かつ前記ＵＲＬから前記予め設定されたマルチメディア・ファイルを読み出すためのステップ、および前記マルチメディア・ファイルを前記受信器／デコーダにマルチキャスト・ストリームの状態で、およびループの状態で送信するステップ、
を有する請求項１３ないし１６のいずれか１項記載の通信方法。
【請求項１】
一方が通信ネットワークに接続され、他方が少なくとも一つの受信器／デコーダに接続される通信装置であって、前記受信器／デコーダからの要求の受信に応答して、前記通信ネットワークの利用可能なバンド幅に基づき、以下の異なる可能性について選択するための手段：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること、
を有する通信装置。
【請求項２】
すべてのマルチキャストアドレス、および少なくとも一つの対応するストリームの特徴、例えばプログラム名、使用するコーデックまたは使用するバンド幅、を含んでいるサービス・プランを操作するための手段、
を有する請求項１記載の通信装置。
【請求項３】
前記要求は、確認されたＩＧＭＰ要求によって確立し、当該通信装置に接続している受信器／デコーダの各々に受信されているストリームの表を操作するための手段、
を有する請求項１または２記載の通信装置。
【請求項４】
前記サービス・プランおよび前記ストリームの表から、通信ネットワークに使用されているバンド幅を計算するための手段および、新しいＩＧＭＰ要求の新しいオンデマンドのストリームの受信のために必要とされる、通信ネットワークのバンド幅を計算するための手段、
を有する請求項２または３に記載の通信装置。
【請求項５】
ＡＤＳＬ（非同期デジタル加入者回線）と互換性を持つ、請求項１、２、３または４のいずれか１項記載の通信装置。
【請求項６】
コンフィギュレーション表にＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を有し、かつ前記ＵＲＬから前記予め設定されたマルチメディア・ファイルを読み出すための手段、および前記マルチメディア・ファイルを前記受信器／デコーダにマルチキャスト・ストリームの状態で、およびループの状態で送信するための手段、
を有する請求項１ないし５のいずれか１項記載の通信装置。
【請求項７】
前記マルチメディア・ファイルは、ＨＴＴＰプロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によって、前記ＵＲＬから読み出される、請求項６記載の通信装置。
【請求項８】
前記マルチメディア・ファイルをフォーマットするための手段、を有する請求項６または７記載の通信装置。
【請求項９】
前記マルチメディア・ファイルは、ビデオを含む、請求項１ないし８のいずれか１項記載の通信装置。
【請求項１０】
前記マルチメディア・ファイルは、アニメーションを含む、請求項１ないし９のいずれか１項記載の通信装置。
【請求項１１】
前記マルチメディア・ファイルは、音声メッセージを含む、請求項１ないし１０のいずれか１項記載の通信装置。
【請求項１２】
変調および復調するための手段、を有する、請求項１ないし１１のいずれか１項記載の通信装置。
【請求項１３】
一方が通信ネットワークに接続され、他方が少なくとも一つの受信器／デコーダに接続される通信装置を使用した通信方法であって、前記受信器／デコーダからの要求の受信に応答して、前記通信ネットワークの利用可能なバンド幅に基づき、以下の異なる可能性について選択するステップ：
・前記要求を変更せずに通信ネットワークに伝送すること；または、
・より低い品質のストリームを求めるために要求を変更すること；または、
・前記要求をネットワークに伝送することを拒否し、かつ受信器／デコーダに予め設定されたマルチメディア・ファイルを送ること、
を有する通信方法。
【請求項１４】
すべてのマルチキャストアドレス、および少なくとも一つの対応するストリームの特徴、例えばプログラム名、使用するコーデックまたは使用するバンド幅、を含んでいるサービス・プランを操作するステップ、
を有する請求項１３記載の通信方法。
【請求項１５】
前記要求は、確認されたＩＧＭＰ要求によって確立し、該通信装置に接続している受信器／デコーダの各々に受信されているストリームの表を操作するステップ、
を有する請求項１３または１４記載の通信方法。
【請求項１６】
前記サービス・プランおよび前記ストリームの表から、通信ネットワークに使用されているバンド幅を計算するステップおよび、新しいＩＧＭＰ要求の新しいオンデマンドのストリームの受信のために必要とされる、通信ネットワークのバンド幅を計算するステップ、
を有する請求項１４または１５に記載の通信方法。
【請求項１７】
コンフィギュレーション表にＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を有し、かつ前記ＵＲＬから前記予め設定されたマルチメディア・ファイルを読み出すためのステップ、および前記マルチメディア・ファイルを前記受信器／デコーダにマルチキャスト・ストリームの状態で、およびループの状態で送信するステップ、
を有する請求項１３ないし１６のいずれか１項記載の通信方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２０１０−５０２０７１（Ｐ２０１０−５０２０７１Ａ）
【公表日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【出願番号】特願２００９−５２５０９１（Ｐ２００９−５２５０９１）
【出願日】平成１９年８月１７日（２００７．８．１７）
【国際出願番号】ＰＣＴ／ＦＲ２００７／０５１８２７
【国際公開番号】ＷＯ２００８／０２３１３０
【国際公開日】平成２０年２月２８日（２００８．２．２８）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】４６ Ｑｕａｉ Ａ． Ｌｅ Ｇａｌｌｏ， Ｆ−９２１００ Ｂｏｕｌｏｇｎｅ−Ｂｉｌｌａｎｃｏｕｒｔ， Ｆｒａｎｃｅ
【出願人】（５０９０４７５０２）トムソン グラス バレー フランス ソシエテ アノニム (1)
【Ｆターム（参考）】
【公表日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【出願日】平成１９年８月１７日（２００７．８．１７）
【国際出願番号】ＰＣＴ／ＦＲ２００７／０５１８２７
【国際公開番号】ＷＯ２００８／０２３１３０
【国際公開日】平成２０年２月２８日（２００８．２．２８）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】４６ Ｑｕａｉ Ａ． Ｌｅ Ｇａｌｌｏ， Ｆ−９２１００ Ｂｏｕｌｏｇｎｅ−Ｂｉｌｌａｎｃｏｕｒｔ， Ｆｒａｎｃｅ
【出願人】（５０９０４７５０２）トムソン グラス バレー フランス ソシエテ アノニム (1)
【Ｆターム（参考）】
[ Back to top ]