特許 6498213 公衆Ｗｉ−Ｆｉネットワークを介したインターネットプロトコルテレビジョン

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6498213

(24)【登録日】2019年3月22日

(45)【発行日】2019年4月10日

(54)【発明の名称】公衆Ｗｉ−Ｆｉネットワークを介したインターネットプロトコルテレビジョン

(51)【国際特許分類】

   H04N 21/6405 20110101AFI20190401BHJP

   H04W 4/06 20090101ALI20190401BHJP

   H04W 84/12 20090101ALI20190401BHJP

   H04N 21/2385 20110101ALI20190401BHJP

【ＦＩ】

   H04N21/6405

   H04W4/06 171

   H04W84/12

   H04N21/2385

【請求項の数】14

【全頁数】14

(21)【出願番号】特願2016-554333(P2016-554333)

(86)(22)【出願日】2015年2月16日

(65)【公表番号】特表2017-512426(P2017-512426A)

(43)【公表日】2017年5月18日

(86)【国際出願番号】US2015016006

(87)【国際公開番号】WO2015130500

(87)【国際公開日】20150903

【審査請求日】2016年10月21日

(31)【優先権主張番号】61/946,221

(32)【優先日】2014年2月28日

(33)【優先権主張国】US

(31)【優先権主張番号】14/229,098

(32)【優先日】2014年3月28日

(33)【優先権主張国】US

【前置審査】

(73)【特許権者】

【識別番号】391030332

【氏名又は名称】アルカテル−ルーセント

(74)【代理人】

【識別番号】110001173

【氏名又は名称】特許業務法人川口國際特許事務所

(72)【発明者】

【氏名】ワン，シュヨンチアン

(72)【発明者】

【氏名】シャルマ，ランジャン

【審査官】 川中 龍太

(56)【参考文献】

【文献】 米国特許出願公開第２００５／００８６４８１（ＵＳ，Ａ１）

【文献】 特開２００４−０３２７１１（ＪＰ，Ａ）

【文献】 特開２０１３−２０７４９６（ＪＰ，Ａ）

【文献】 特開２０１０−１６１５４８（ＪＰ，Ａ）

【文献】 特開２００７−０７４１６８（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００６／０２７１７８０（ＵＳ，Ａ１）

【文献】 Jong Sik Moon, et al.，Multicast Key Management in Multimedia Broadcasting Service Environment，Ubiquitous Information Technologies & Applications, 2009. ICUT '09. Proceedings of the 4th International Conference on，IEEE，２００９年１２月２０日，IEL Online (IEEE Xplore)，ＵＲＬ，http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5405668

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００ − ２１／８５８

Ｈ０４Ｎ ５／３８ − ５／４６

Ｈ０４Ｂ ７／２４ − ７／２６

Ｈ０４Ｗ ４／００ − ９９／００

Ｈ０４Ｌ ９／００ − ９／３８

Ｈ０４Ｌ １２／００ − １２／２６

Ｈ０４Ｌ １２／５０ − １２／９５５

(57)【特許請求の範囲】

【請求項1】

送受信機と、
非一時的記憶媒体と、
送受信機および非一時的記憶媒体と動作可能に結合されるプロセッサであって、非一時的記憶媒体に記憶される命令により、第１のグループテンポラルキー（ＧＴＫ）に関連づけられた第１のインターネットプロトコルテレビジョン（ＩＰＴＶ）チャネルを、公衆ＷｉＦｉネットワークを介してマルチキャストすることと、第２のＧＴＫに関連づけられた第２のＩＰＴＶチャネルを、公衆ＷｉＦｉネットワークを介して同時にマルチキャストすることとを行うように構成される、プロセッサと
を備える、装置。

【請求項2】

プロセッサが、第１のＧＴＫ交換メッセージ内で第１のＧＴＫを第１のＩＰＴＶチャネルと関連づけることと、第２のＧＴＫ交換メッセージ内で第２のＧＴＫを第２のＩＰＴＶチャネルと関連づけることとを行うようにさらに構成される、請求項１に記載の装置。

【請求項3】

プロセッサが、第１のＩＰＴＶチャネルを第１のクライアントデバイスへと、第２のＩＰＴＶチャネルを第２のクライアントデバイスへと、同時にマルチキャストするようにさらに構成される、請求項１に記載の装置。

【請求項4】

プロセッサが、１）第１のＩＰＴＶチャネルに参加するための第１の要求を第１のクライアントデバイスから受信したことに応答して、第１のＧＴＫを第１のクライアントデバイスに提供することと、２）第２のＩＰＴＶチャネルに参加するための第２の要求を第２のクライアントデバイスから受信したことに応答して、第２のＧＴＫを第２のクライアントデバイスに提供することと、３）第３のＩＰＴＶチャネルに参加するための要求を第１のクライアントデバイスから受信したことに応答して、第３のＧＴＫを第１のクライアントデバイスに、第４のＧＴＫを第２のクライアントデバイスに提供することとを行うようにさらに構成される、請求項１に記載の装置。

【請求項5】

プロセッサが、８０２．１１通信規格に準拠した動作を実行するようにさらに構成される、請求項１に記載の装置。

【請求項6】

送受信機と、
非一時的記憶媒体と、
送受信機および非一時的記憶媒体と動作可能に結合されるプロセッサであって、非一時的記憶媒体に記憶される命令により、第１のグループテンポラルキー（ＧＴＫ）を用いて、アクセスポイントによってマルチキャストされた第１のマルチキャストチャネルを復号することと、第１のマルチキャストチャネルの受信を終了させることなく、第２の異なるＧＴＫを用いて第１のマルチキャストチャネルを復号することとを行うように構成される、プロセッサと
を備える、装置。

【請求項7】

プロセッサが、ユーザへの第１のマルチキャストチャネルの出力を中断することなく、第１のマルチキャストチャネルを復号するように構成される、請求項６に記載の装置。

【請求項8】

メディアアクセスポイントにおいて実行される方法であって、
第１のグループテンポラルキー（ＧＴＫ）に関連づけられた第１のインターネットプロトコルテレビジョン（ＩＰＴＶ）チャネルを、公衆ＷｉＦｉネットワークを介してマルチキャストすることと、
第２のＧＴＫに関連づけられた第２のＩＰＴＶチャネルを、公衆ＷｉＦｉネットワークを介して同時にマルチキャストすることと
を含む、方法。

【請求項9】

第１のＧＴＫを第１のＩＰＴＶチャネルと関連づける第１のＧＴＫ交換メッセージを送信することと、第２のＧＴＫを第２のＩＰＴＶチャネルと関連づける第２のＧＴＫ交換メッセージを送信することとをさらに含む、請求項８に記載の方法。

【請求項10】

第１のＩＰＴＶチャネルに参加するための第１の要求を第１のクライアントデバイスから受信したことに応答して、第１のＧＴＫを第１のクライアントデバイスに提供することと、第２のＩＰＴＶチャネルに参加するための第２の要求を第２のクライアントデバイスから受信したことに応答して、第２のＧＴＫを第２のクライアントデバイスに提供することとをさらに含む、請求項８に記載の方法。

【請求項11】

クライアントデバイスにおいて実行される方法であって、
第１のグループテンポラルキー（ＧＴＫ）を用いて、アクセスポイントによってマルチキャストされた第１のマルチキャストチャネルを復号することと、
第１のマルチキャストチャネルの受信を終了させることなく、第２の異なるＧＴＫを用いて第１のマルチキャストチャネルを復号することと
を含む、方法。

【請求項12】

第１のグループテンポラルキー（ＧＴＫ）に関連づけられた第１のインターネットプロトコルテレビジョン（ＩＰＴＶ）チャネルを、公衆ＷｉＦｉネットワークを介してマルチキャストするようにプロセッサを構成することと、
第２のＧＴＫに関連づけられた第２のＩＰＴＶチャネルを、公衆ＷｉＦｉネットワークを介して同時にマルチキャストするようにプロセッサを構成することと
を含む、方法。

【請求項13】

第１のＩＰＴＶチャネルに参加するための第１の要求を第１のクライアントデバイスから受信したことに応答して、第１のＧＴＫを第１のクライアントデバイスに提供することと、第２のＩＰＴＶチャネルに参加するための第２の要求を第２のクライアントデバイスから受信したことに応答して、第２のＧＴＫを第２のクライアントデバイスに提供することとを行うようにプロセッサを構成することをさらに含む、請求項１２に記載の方法。

【請求項14】

第１のグループテンポラルキー（ＧＴＫ）を用いて、アクセスポイントによってマルチキャストされた第１のマルチキャストチャネルを復号するようにプロセッサを構成することと、
第１のマルチキャストチャネルの受信を終了させることなく、第２の異なるＧＴＫを用いて第１のマルチキャストチャネルを復号するようにプロセッサを構成することと
を含む、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１４年２月２８日に出願された、米国仮特許出願第第６１／９４６，２２１号の利益を主張するものである。本出願の主題は、２０１４年２月２８日に出願された、米国特許出願第１４／１９３，２１５号（’２１５出願）の主題に関連したものであり、同出願の全体が参照により本明細書に組み込まれる。

【0002】

本開示は全体として、テレビ放送のワイヤレス配信の分野に関する。

【背景技術】

【0003】

本項は、本発明の理解を深めるのに役立つ可能性がある、諸態様を紹介するものである。したがって、本項の記述は、こうした観点で読まれるべきであり、先行技術に何が含まれ、また何が含まれないかに関する自認として理解されるべきではない。

【0004】

ＷｉＦｉアクセスポイントの数は、急速に増加している。移動体通信事業者の一部は、モバイルネットワーク（たとえば、スマートフォン、タブレットコンピュータ、およびラップトップのもの）からデータトラフィックをオフロードするために、やはりＷｉＦｉアクセスポイントを設置し続けている。ＷｉＦｉアクセスポイントは、このような、ＩＥＥＥ８０２．１１規格で定義されたワイヤレスチャネルを使用するユーザエンドデバイスとの通信を行う。

【発明の概要】

【課題を解決するための手段】

【0005】

一実施形態は、たとえばワイヤレスメディアアクセスポイントとして、装置を提供する。この装置は、送受信機と、非一時的記憶媒体と、送受信機および記憶媒体と動作可能に結合されるプロセッサとを含む。プロセッサは、記憶媒体に記憶される命令により、第１のグループテンポラルキー（ＧＴＫ）に関連づけられた第１のマルチキャストチャネルを送信することと、第２のＧＴＫに関連づけられた第２のマルチキャストチャネルを同時に送信することとを行うように構成される。

【0006】

装置のいずれかの実施形態では、プロセッサが、第１のマルチキャストチャネルを第１のクライアントデバイスへと、第２のマルチキャストチャネルを第２のクライアントデバイスへと、同時に送信するようにさらに構成され得る。装置のいずれかの実施形態では、プロセッサが、ＩＥＥＥ８０２．１１通信規格を実装するようにさらに構成され得る。装置のいずれかの実施形態では、プロセッサが、第１のＧＴＫ交換メッセージ内で第１のＧＴＫを第１のマルチキャストチャネルと関連づけることと、第２のＧＴＫ交換メッセージ内で第２のＧＴＫを第２のマルチキャストチャネルと関連づけることとを行うようにさらに構成され得る。

【0007】

プロセッサのいずれかの実施形態では、プロセッサが、第１のマルチキャストチャネルに参加するための第１の要求を第１のクライアントデバイスから受信したことに応答して、第１のＧＴＫを第１のクライアントデバイスに提供することと、第２のマルチキャストチャネルに参加するための第２の要求を第２のクライアントデバイスから受信したことに応答して、第２のＧＴＫを第２のクライアントデバイスに提供することとを行うようにさらに構成され得る。このような実施形態において、プロセッサはまた、第３のマルチキャストチャネルに参加するための要求を第１のクライアントデバイスから受信したことに応答して、第３のＧＴＫを第１のクライアントデバイスに、第４のＧＴＫを第２のクライアントデバイスに提供するようにさらに構成され得る。

【0008】

別の実施形態は、たとえばクライアントデバイスとして、装置を提供する。この装置は、送受信機と、非一時的記憶媒体と、送受信機および記憶媒体と動作可能に結合されるプロセッサとを含む。プロセッサは、記憶媒体に記憶される命令により、第１のＧＴＫを用いて第１のマルチキャストチャネルを復号することと、第１のマルチキャストチャネルの受信を終了させることなく、第２の異なるＧＴＫを用いて第１のマルチキャストチャネルを復号することとを行うように構成される。

【0009】

直上の装置に関するいずれかの実施形態では、プロセッサが、ユーザへの出力を中断することなく、第１のマルチキャストチャネルを復号するように構成され得る。装置のいずれかの実施形態では、プロセッサが、８０２．１１通信規格を実装するようにさらに構成され得る。

【0010】

別の実施形態は、たとえばメディアアクセスポイントを製造する、ある方法を提供する。本方法は、第１のグループテンポラルキー（ＧＴＫ）に関連づけられた第１のマルチキャストチャネルを送信するようにプロセッサを構成することを含む。本方法は、第２のＧＴＫに関連づけられた第２のマルチキャストチャネルを同時に送信するようにプロセッサを構成することをさらに含む。

【0011】

本方法のいずれかの実施形態は、第１のマルチキャストチャネルを第１のクライアントデバイスへと、第２のマルチキャストチャネルを第２のクライアントデバイスへと、同時に送信するようにプロセッサを構成することをさらに含み得る。本方法のいずれかの実施形態は、第１のＧＴＫを第１のマルチキャストチャネルと関連づける第１のＧＴＫ交換メッセージを送信することと、第２のＧＴＫを第２のマルチキャストチャネルと関連づける第２のＧＴＫ交換メッセージを送信することとを行うようにプロセッサを構成することをさらに含み得る。

【0012】

本方法のいずれかの実施形態は、第１のマルチキャストチャネルに参加するための第１の要求を第１のクライアントデバイスから受信したことに応答して、第１のＧＴＫを第１のクライアントデバイスに提供することと、第２のマルチキャストチャネルに参加するための第２の要求を第２のクライアントデバイスから受信したことに応答して、第２のＧＴＫを第２のクライアントデバイスに提供することとを行うようにプロセッサを構成することをさらに含み得る。このような実施形態のいずれかは、第３のマルチキャストチャネルに参加するための要求を第１のクライアントデバイスから受信したことに応答して、第３のＧＴＫを第１のクライアントデバイスに、第４のＧＴＫを第２のクライアントデバイスに提供するようにプロセッサを構成することをさらに含み得る。

【0013】

別の実施形態は、たとえば、ラップトップコンピュータ、パッドコンピュータ、またはスマートフォンなどの、クライアントデバイスを製造する、ある方法を提供する。本方法は、第１のグループテンポラルキー（ＧＴＫ）を用いて第１のマルチキャストチャネルを復号するようにプロセッサを構成することを含む。本方法は、第１のマルチキャストチャネルの受信を終了させることなく、第２の異なるＧＴＫを用いて第１のマルチキャストチャネルを復号するようにプロセッサを構成することをさらに含む。本方法のいずれかの実施形態は、ユーザへの出力を中断することなく、第１のマルチキャストチャネルを復号するようにプロセッサを構成することをさらに含み得る。

【0014】

別の実施形態は、たとえばメディアアクセスポイントにおいて実行される、ある方法を提供する。本方法は、第１のグループテンポラルキー（ＧＴＫ）に関連づけられた第１のマルチキャストチャネルを送信することを含む。本方法は、第２のＧＴＫに関連づけられた第２のマルチキャストチャネルを同時に送信することをさらに含む。

【0015】

本方法のいずれかの実施形態は、第１のマルチキャストチャネルを第１のクライアントデバイスへと、第２のマルチキャストチャネルを第２のクライアントデバイスへと、同時に送信することをさらに含み得る。

【0016】

本方法のいずれかの実施形態は、第１のマルチキャストチャネルに参加するための第１の要求を第１のクライアントデバイスから受信したことに応答して、第１のＧＴＫを第１のクライアントデバイスに提供することと、第２のマルチキャストチャネルに参加するための第２の要求を第２のクライアントデバイスから受信したことに応答して、第２のＧＴＫを第２のクライアントデバイスに提供することとをさらに含み得る。このような実施形態のいずれかは、第３のマルチキャストチャネルに参加するための要求を第１のクライアントデバイスから受信したことに応答して、第３のＧＴＫを第１のクライアントデバイスに、第４のＧＴＫを第２のクライアントデバイスに提供することをさらに含み得る。

【0017】

別の実施形態は、たとえばクライアントデバイスにおいて実行される、ある方法を提供する。本方法は、第１のグループテンポラルキー（ＧＴＫ）を用いて第１のマルチキャストチャネルを復号することを含む。本方法は、第１のマルチキャストチャネルの受信を終了させることなく、第２の異なるＧＴＫを用いて第１のマルチキャストチャネルを復号することをさらに含む。本方法のいずれかの実施形態は、ユーザへの出力を中断することなく、第１のマルチキャストチャネルを復号することをさらに含み得る。

【0018】

以下の詳細な説明を添付図面と併せて参照することにより、本発明のより完全な理解を得ることができる。

【図面の簡単な説明】

【0019】

【図1】メディアアクセスポイントが、複数のモバイルクライアントデバイス（たとえば、コンピュータ、スマートフォン、およびタブレット）とワイヤレスで通信する、従来のシステムを示す図である。

【図2】種々の実施形態に従って動作するように構成された、メディアアクセスポイントの例示的上位レベル概略図である。

【図3】種々の実施形態に従って動作するように構成された、モバイルクライアントデバイスの例示的上位レベル概略図である。

【図4】メディアアクセスポイントが複数のクライアントデバイスとワイヤレスで通信する、従来のシステムにおいて実施されるステップを示す図である。

【図5】メディアアクセスポイントが、複数のモバイルクライアントデバイス（たとえば、コンピュータ、スマートフォン、およびタブレット）とワイヤレスで通信し、これらのデバイスのうちの少なくともいくつかが、複数のマルチキャストチャネルの送信に同時対応するようアクセスポイントによって構成される、本開示の実施形態によるシステムを示す図である。

【図6】本開示の実施形態による、図５のメディアアクセスポイントおよびクライアントデバイスを操作する方法のステップを示す図である。

【発明を実施するための形態】

【0020】

本開示が対象とするのは、たとえば、インターネットプロトコル（ＩＰ）メッセージングを介してテレビ（ＴＶ）コンテンツを配信するために、８０２．１１（ＷｉＦｉ）規格により部分的に規定されたワイヤレスインフラを利用する、方法およびシステムの改良である。

【0021】

図１は、システム１００の例示的実施形態（たとえば、相互にワイヤレスで関連づけられたデバイスのグループ）を、上位レベルで示している。システム１００は、アクセスポイント１１０と、３つのクライアントデバイス（たとえば、コンピュータ１２０ａ、タブレット１２０ｂ、およびスマートフォン１２０ｃ）とを含んでいる。アクセスポイント１１０、クライアント１２０ａ、１２０ｂ、１２０ｃの各々は、マルチキャスティング動作に関するパラメータを格納するための、ＭＩＢを含む。アクセスポイント１１０、およびすべてのクライアントのＭＩＢには、関連情報（ｐｅｒｔｉｎｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ）が含まれる。たとえば、アクセスポイント１１０に関連するＭＩＢは、キーＩＤを備えた最大４つのＧＴＫキー、およびクライアント（マルチキャストストリームに参加している、たとえばクライアント１２０ａと１２０ｂ）の識別子を格納することができる。

【0022】

本開示の範囲に含まれる実施形態は、特定の数の、または特定の型のクライアントデバイスに限定されない。クライアントデバイス間の区別が不要な場合、任意の数のクライアントデバイスが、クライアントデバイス１２０として表現されてよい。種々の実施形態の動作は、アクセスポイント１１０およびクライアントデバイス１２０を基準として説明することが可能であり、これらのアクセスポイントおよび／またはクライアントデバイスは、特定の構成に限定されない。クライアントデバイス１２０は、一般性を失うことなく、クライアント１２０と略して呼ぶこともできる。

【0023】

当業者であれば、アクセスポイント１１０およびクライアント１２０を、メディアアクセス制御（ＭＡＣ）層の構成要素と考えてよいことは認められよう。したがって、システム１００はＭＡＣ層１００とも呼ぶことができ、アクセスポイント１００およびクライアント１２０は、ＭＡＣ層１００の構成要素と呼ぶことができる。

【0024】

アクセスポイント１１０およびクライアント１２０は、８０２．１１規格のもと、これを本明細書に記述される１つ以上の実施形態に従って増強する形で動作するように構成される。８０２．１１規格（本明細書では「Ｗｉ−Ｆｉ」と表現することもある）は、アクセスポイント１１０およびクライアント１２０に関する動作基準を規定する。８０２．１１規格には、非同期サービスの一部として、マルチキャスティングに関する規定が含まれている。

【0025】

図２は、アクセスポイント（たとえば、図１のアクセスポイント１１０）として動作可能な、装置２００を概略的に示している。装置２００は、メモリ２２０および送受信機２３０と動作可能に結合された、プロセッサ２１０を含んでいる。プロセッサ２１０、メモリ２２０、送受信機２３０の各々は、本明細書に記述される実施形態以外の点は、従来の、または今後開発される、あらゆる型のものであってよい。メモリ２２０は、それらの実施形態に従い、プロセッサ２３０によって実行される動作命令を保持する、物理的な非一時的命令スペースを含んでいる。これらの命令には、たとえば、８０２．１１規格に準拠した動作や、本明細書に記述される実施形態のさまざまなステップを実施する命令が含まれる。プロセッサ２１０は、送受信機２３０を制御して、アンテナ２４０を介し、１つ以上のクライアントデバイス（たとえば、図１のクライアントデバイス１２０）と通信するように構成される。アンテナ２４０は特定の型に限定されず、多入力多出力（ＭＩＭＯ）通信を実装する複数のアンテナ要素が含まれ得る。

【0026】

図３は、クライアントデバイス（たとえば、図１のクライアントデバイス１２０のいずれか）として動作可能な、装置３００を概略的に示している。装置３００は、メモリ３２０および送受信機３３０と動作可能に結合された、プロセッサ３１０を含んでいる。プロセッサ３１０、メモリ３２０、送受信機３３０の各々は、本開示の範囲内の実施形態に即した機能を提供するように構成されたものとなり得るが、そうでない場合には、従来の、または今後開発される任意の型のものであってもよい。メモリ３２０は、それらの実施形態に従い、プロセッサ３３０によって実行される動作命令を保持する、物理的な非一時的命令スペースを含んでいる。これらの命令には、たとえば、８０２．１１規格に準拠した動作や、本明細書に記述される実施形態のさまざまなステップを実施する命令が含まれる。プロセッサ３１０は、送受信機３３０を制御して、アンテナ３４０を介し、アクセスポイント（たとえば、図１のアクセスポイント１１０）と通信するように構成される。アンテナ３４０は特定の型に限定されず、ＭＩＭＯ通信を実装する複数のアンテナ要素が含まれ得る。

【0027】

グループテンポラルキー（ＧＴＫ）は、ＧＴＫ更新タイマが時間切れとなった場合や、クライアントがＷｉＦｉアクセスポイントの通信範囲外に出た場合など、さまざまな状況で、その時々に更新されてよい。ＧＴＫの更新時、アクセスポイント１１０は、更新されたＧＴＫを、クライアント１２０ａおよび１２０ｂへと送信することができる。この状況で、アクセスポイント１１０は、クライアント１２０ａおよび１２０ｂが、マルチキャストパケットの開始シーケンス番号（そこから新たなＧＴＫが使用される）を利用できるようにする。クライアント１２０ａと１２０ｂが２つの例となる各クライアントは、それらがこのパケットシーケンス番号を認識したときに、当該マルチキャストパケットを復号するために新たなＧＴＫの使用を開始できる、クライアントからなるメディアアクセス制御（ＭＡＣ）層を、集合的に形成する。

【0028】

ＭＡＣ層の管理情報ベース（ＭＩＢ）は、キーとともに、４つのキーＩＤを格納する。キーＩＤ ０は、ユニキャストペアワイズキーに対するものである。キーＩＤ １、２、および３は、ＧＴＫ更新処理中の、ＧＴＫ更新に対するものである。種々の実施形態において、少なくとも２つのＧＴＫキーが同時に利用可能であることが要求され得る。

【0029】

先行技術によるマルチキャスト実装では、すべてのマルチキャストストリームが、１つの同じＧＴＫキーを用いて暗号化される。これは、ＩＰマルチキャストインターネットプロトコルテレビジョン（ＩＰＴＶ）の配備のためには、不十分なものとなり得る。ＩＰマルチキャストＩＰＴＶの場合、クライアントは通常、さまざまなチャネル購読パッケージを持っている。現在の８０２．１１規格のもとでは、すべてのクライアントが、アクセスポイントからマルチキャストで送信される、すべてのチャネルを視聴することができてしまう。

【0030】

本発明者らは、現在のマルチキャスト規格（たとえば、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）８０２．１１規格）に有益な拡張を施し、以下で説明する種々の実施形態を実装することで、マルチキャスティング機能の改良が可能であると認識している。より具体的にいえば、各ＩＰＴＶチャネルが、マルチキャストストリームとして視聴可能となる。各チャネルは、当該チャネルに一意のＧＴＫを用いて暗号化され得る。特定のチャネルに認証されたクライアントだけが、そのチャネルに参加すること、およびそのチャネルに対応する一意のＧＴＫを受信することを許可される。更新タイマが時間切れとなる、またはクライアントがチャネルを離れるとき、そのチャネルの受信を認証された状態に留まっている、すべてのクライアントにより、ＧＴＫが更新されることになる。このようにすることで、異なるチャネルは異なるＧＴＫキーによって暗号化されるため、クライアントは、自身が購読しており、参加を許可されたチャネルのみが視聴できるように制限される。このような実施形態は、ディファレンシャルな購読パッケージが、公衆ＷｉＦｉを介して配備およびアクセスされることを可能にする。

【0031】

図４は、方法４００を示しており、この方法には、従来のマルチキャスティングを行う際の、アクセスポイント１１０と、２つのクライアントデバイス１２０ａおよび１２０ｂとの間の処理が含まれている。当業者であれば、図示された処理は、既存の８０２．１１規格に包含されるものであることが認められよう。

【0032】

ステップ４０５において、クライアント１２０ａは、アクセスポイント１１０の方向に、マルチキャスト参加要求（たとえば、８０２．１１ユニキャストデータフレーム内のパケット）を送信することにより、マルチキャスト配信セッションを開始する。ステップ４１０において、アクセスポイント１１０は、クライアント１２０ａに宛てた、確認応答（たとえば、８０２．１１確認応答フレーム）を用いて応答する。

【0033】

ステップ４１５において、アクセスポイント１１０とクライアント１２０ａが、キーハンドシェイクを行う。このキーハンドシェイクにおいて、アクセスポイント１１０は、グループテンポラルキー（ＧＴＫ）を、クライアント１２０ａに向けて送信する。ＧＴＫを送信した後、ステップ４２０において、アクセスポイント１１０は、クライアント１２０ａが要求するデータ（たとえば、クライアント１２０ａがマルチキャストしたいデータ）を、ＧＴＫで暗号化したマルチキャストフレームとして送信する。ステップ４２５において、クライアント１２０ａは、ステップ４１５で取得したＧＴＫを用いて、マルチキャストストリームの復号を開始する。

【0034】

マルチキャストフレームは、対象となる受信者（たとえば、クライアント１２０ａや、送信内容を受信するように構成可能な他のクライアント）の宛先として、グループアドレスを含む。宛先局の各々（たとえば、クライアント１２０ａおよび１２０ｂ）は、このフレームを受信することができる。ただし、マルチキャストフレームを復号できるのは、有効なＧＴＫを持つクライアントだけである。

【0035】

ステップ４３０において、クライアント１２０ｂは、マルチキャスト送信に参加するための要求を、アクセスポイント１１０へと送信する。クライアント１２０ａに関して説明したように、アクセスポイントは、ステップ４３５で確認応答を送信し、ステップ４４０でキーハンドシェイクを実行する。ステップ４４５において、クライアント１２０ｂは、マルチキャストストリームの復号を開始する。

【0036】

やがて、クライアント１２０ｂはネットワークを離れる。ステップ４５０において、アクセスポイント１１０は、このイベントを検出する。ステップ４５５において、アクセスポイント１１０およびクライアント１２０ａは、ＧＴＫ更新を遂行する。その結果、クライアント１２０ａは、マルチキャストストリームの復号を継続することができる。クライアント１２０ｂは、たとえネットワークに復帰したとしても、再度このマルチキャストストリームへの参加を要求することなしに、同マルチキャストストリームを復号することは不可能である。

【0037】

本開示は、メディアの商用配信の発展により、同一のアクセスポイントに接続された異なるクライアントが、許可するアクセスレベルの異なるメディアアクセスサブスクリプションを持ち得るということを認識している。図４の例を続けると、クライアント１２０ａおよび１２０ｂは、たとえばスポーツチャネルとドラマチャネルを含む、複数のマルチキャストチャネルを提供するメディア配信主体に対し、購読を申し込むことができる。クライアント１２０ａがスポーツチャネルを購読しながらもドラマチャネルは購読せず、一方でクライアント１２０ｂはドラマチャネルを購読しながらもスポーツチャネルは購読しない、という可能性もある。

【0038】

従来の方法４００では、すべてのマルチキャストストリームが、１つの同じＧＴＫキーを用いて暗号化される。そのため、既存の８０２．１１規格のもとでの従来の動作では、アクセスポイント１１０からマルチキャストされているすべてのチャネルを、すべてのクライアントが視聴することを可能にしてしまう。したがって、従来の動作のこうした態様は、アクセスポイント１１０を介してすべてのマルチキャストチャネルにアクセスする権限を個々のクライアントが持たないという、説明したシナリオに適したものではない。

【0039】

本開示の実施形態は、この欠点について、当該規格（たとえば、８０２．１１規格）に拡張を施して、一意のアクセス権限を伴うサブスクリプションを含むネットワーク内で、マルチキャストストリームのアクセス制御を実現することによって対処する。種々の実施形態では、ＭＩＢが以下のように拡張され得る：

【0040】

１．アクセスポイント１１０におけるＭＩＢのサイズが、より多数のＧＴＫキーおよびキーＩＤに対応するように拡大可能となる。たとえば、典型的なＩＰＴＶ配備では、最大２０４８チャネルをサポートすることが必要となる可能性がある。この例では、ステップ４５５のようなＧＴＫ更新中、サポートしている各チャネルについて、２つのＧＴＫキーが同時に利用可能となる必要があるため、４０９６個のＧＴＫキーおよびキーＩＤがサポートされなくてはならない。とはいえ、実際の運用では、クライアント１２０は、同時にいくつかのチャネルに参加するだけでよい。したがって、クライアント１２０におけるＭＩＢのサイズは、修正を必要としない場合もある。

【0041】

２．マルチキャスト中のマルチキャストチャネル／ストリームが記録可能となる。

【0042】

３．各マルチキャストチャネル／ストリームについて、現在そのチャネルを視聴しているクライアントのセットが記録可能となる。

【0043】

４．ＧＴＫ交換メッセージ（ＧＴＫ ＫＤＥ）の書式が、より多数（たとえば、４０９６個）のＧＴＫキーＩＤを伝達するとともに、各ＧＴＫキーが関連づけられているＩＰＴＶチャネルはどれかを伝達するように修正可能となる。何らかの適応がなければ、従来の規格のもとで動作しているクライアントは、いくつかの実施形態に従って修正されたＧＴＫ ＫＤＥの書式を理解できないおそれがある。種々の実施形態では、システムのコンポーネント（たとえば、アクセスポイント）は、このようなクライアントとの後方互換性を持つように構成される。

【0044】

前述のリストにおいて、１項目と２項目で言及されたデータは、アクセスポイント１１０およびクライアント１２０からなるＭＡＣ層によって作成および更新され得る。

【0045】

前述のリストにおいて、３項目で言及されたデータは、アクセスポイント１１０上で動作するＩＰＴＶアプリケーションによってプログラムされ得る。たとえば、’２１５出願を参照されたい。アクセスポイント１２０上のＭＡＣ層は、ＩＰＴＶアプリケーションとインターフェースするように拡張させることが可能であり、それにより、このアプリケーションに対し、いつクライアント１２０がＩＰＴＶチャネルへの参加、またはそこからの離脱を要求したかを通知する。ＩＰＴＶアプリケーションは、所与のチャネルを視聴しているクライアント１２０のリストを、ＭＡＣ層ＭＩＢテーブルに提供することができる。

【0046】

図５は、説明した本開示の実施形態に即して動作するように構成された、システム５００を示している。システム５００は、アクセスポイント５１０と、クライアント５２０ａおよび５２０ｂとを含んでいる。アクセスポイント５１０およびクライアント５２０ａ／ｂの各々は、マルチキャスティング動作に関するパラメータを格納するための、ＭＩＢを含む。アクセスポイント５１０およびクライアント５２０ａ／ｂは、言及しないアンテナを介して、ワイヤレスで通信することができる。アクセスポイント５１０は、インターネット５４０を介して、中央データベース５３０と通信することができる。システム５００には２つのクライアント５２０ａ／ｂのみが示されているが、当業者であれば、記述する実施形態は、たとえばアクセスポイント５１０内のストレージの制限のもと、任意の数のクライアントが含まれるように拡張可能であることは直ちに認められよう。

【0047】

図６は、上記の拡張型マルチキャスティング動作に即した、方法６００における、アクセスポイント５１０、クライアント５２０ａ、および第２のクライアント５２０ｂの間の処理を示している。各実施形態は３つ以上のクライアント５２０を含み得るが、簡潔なものとするため、その２つが示されている。いくつかの実施形態では、図示したステップの一部が省略されてもよく、図示したステップが図示した順序とは異なる順序で実行されてよく、かつ／または、図示したステップ以外のステップが図示したステップの一部もしくは全部と併せて実行されてもよい。より具体的にいえば、ＧＴＫ更新タイマが時間切れとなった場合およびクライアントがネットワークを離れた場合のＧＴＫ更新に関する細目は、簡潔なものとするため、同様に省略される。当業者であれば、以下の記述に照らして、これらの状況がどのようにして実現し得るかは、直ちに認識されよう。

【0048】

ステップ６０５において、クライアント５２０ａは、あるＩＰＴＶチャネル（非限定的な例において、チャネル１７と示す）への参加要求を、アクセスポイント５１０に向けて送信する。ステップ６１０において、アクセスポイント５１０は、クライアント５２０ａに向けて確認応答（Ａｃｋ）を送信する。種々の実施形態では、クライアント５２０ａは、Ａｃｋ信号の検出に失敗した場合、参加要求６０５を再送信する（図示なし）。種々の実施形態では、クライアント５２０ａからアクセスポイント５１０までのデータパス区間に、マルチキャストシグナリング規格に即した送信エラー回復が含まれる。たとえば、８０２．１１プロトコルは、ユニキャストデータフレーム送信の使用時、インフラおよびアドホック構成の両面において、各局間の信頼性を保証する。

【0049】

ステップ６１５において、アクセスポイント５１０とクライアント５２０ａの間で、グループテンポラルキー（ＧＴＫ）ハンドシェイクが実行される。このハンドシェイクでは、アクセスポイント５１０が、具体的にはチャネル１７のために、ＧＴＫをクライアント５２０ａへと送信する。

【0050】

いくつかの実施形態では、アクセスポイント５１０は、ステップ６１０で確認応答を送信する前に、クライアント５２０ａに関する許可をチェックし、クライアント５２０ａが要求されたチャネル（たとえば、チャネル１７）を視聴する許可を有しているかを確認する。このチェックには、アクセスポイント５１０が中央データベース５３０をクエリすることが含まれ得る。いくつかの実施形態では、確認応答は、ステップ６１５でのＧＴＫハンドシェイク中にクライアント５２０ａによって提供されるクッキーまたはクッキーに類似の要素を、アクセスポイント５１０が検証した後で送信され得る。このような実施形態では、ハンドシェイクは確認応答の前に行われる。ＧＴＫハンドシェイクにおいて、アクセスポイント５１０は、クライアント５２０にＧＴＫ（後の参照のために第１のＧＴＫと呼ぶ）を提供する。

【0051】

ステップ６２０において、アクセスポイントは、要求されたチャネル１７がそれまで流れていなければ、チャネル１７のマルチキャストストリームの送信を開始する。当然ながら、この送信は、ステップ６０５、６１０、および６１５の処理が成功していることを条件とする。ステップ６２０の矢印が引き伸ばされているのは、予め認証された、任意の数のクライアントが、チャネル１７のストリームを受信し得るということを反映している。ステップ６２５において、クライアント５２０ａは、チャネル１７のマルチキャストストリームの受信および復号を開始する。

【0052】

ステップ６３０において、クライアント５２０ｂは、チャネル１７のマルチキャストストリームへの参加要求を、アクセスポイント５１０に向けて送信する。アクセスポイント５１０は、クライアント５１０ａに関して説明したのと同様、クライアント５２０ｂを認証する。この認証には、確認応答６３５、および具体的にはチャネル１７のためのＧＴＫハンドシェイク６４０が含まれる。クライアント５２０ａに関して説明したように、アクセスポイントは、確認応答を送信する前に、中央データベース５３０をクエリするか、またはステップ６４０でのＧＴＫハンドシェイクにおいてクライアント５２０ｂによって提供されるクッキーを検証してよい。ステップ６４５において、クライアント５２０ｂは、進行中であるチャネル１７のストリームの復号を開始する。

【0053】

図５の例において、クライアント５２０ｂの視聴者は、進行中のチャネル１７のストリームから、別のストリーム（たとえば、チャネル５）へと変更することを望む可能性もある。この変更はステップ６５０に表されており、クライアント５２０ｂは、流れているＩＰＴＶチャネル５を視聴するための要求を、アクセスポイント５１０へと送信する。ステップ６５５において、アクセスポイント５１０は、クライアント５２０ｂへと確認応答を送信する。ステップ６６０において、アクセスポイント５１０とクライアント５２０ａが、ＧＴＫハンドシェイクを行う。このＧＴＫハンドシェイクは、新たな、すなわち第２のＧＴＫを用いて、チャネル１７用のアクセスクレデンシャルを更新するものである。よって、クライアント５２０ａは、チャネル１７への接続を終了させることなく、チャネル１７のコンテンツの続きを復号することができる。そのため、クライアント５２０ａはチャネル１７のストリームの継続視聴が可能であると同時に、クライアント５２０ｂはチャネル１７へのアクセスを拒否される。クライアント５２０ａのユーザがＧＴＫ更新に気づかないようにするため、クライアント５２０ｂのプロセッサ３１０は、このユーザに対し中断することなくチャネル１７のストリームを復号するように構成されることが好ましい。ステップ６６５において、クライアント５２０ｂによるチャネル５のＩＰＴＶストリームへのアクセスを許可するために、アクセスポイント５１０とクライアント５２０ｂが、ＧＴＫハンドシェイクを行う。このステップにおいて、アクセスポイント５１０は、新たな、すなわち第３のＧＴＫを、クライアント５２０ｂに発行する。ステップ６７０において、アクセスポイント５１０がチャネル５のストリーミングを開始し（既に流れている同チャネルがない場合）、ステップ６７５において、クライアント５２０がチャネル５のストリームの復号を開始する。よって、アクセスポイント５１０は、マルチキャストチャネル５と、マルチキャストチャネル１７とを、同時に送信する。本明細書では、複数のマルチキャスト送信の文脈における「同時」とは、第１のクライアントデバイスに向けた第１の送信の少なくとも一部が、第２のクライアントデバイスに向けた第２の送信と時間的に重複していることを意味する。

【0054】

既に説明したのと同様に、クライアント５２０ａが第３のマルチキャストチャネル（たとえば、チャネル１０）への変更を要求しようとするのであれば、アクセスポイントは新たな、すなわち第４のＧＴＫをクライアント５２０ｂに発行してチャネル５のストリーミングを継続し、新たな、すなわち第５のＧＴＫをクライアント５２０ａに発行してチャネル１０をストリーミングする。

【0055】

本発明の複数の実施形態について、添付の図面に図示するとともに、上記、発明を実施するための形態の項において説明してきたが、本発明は開示した実施形態に限定されるものではなく、続く特許請求の範囲に記載され、これにより定義されるような多数の再構成、修正、および置き換えが、本発明から逸脱することなく、実行可能であるということを理解されたい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】