特許 7474347 プログラム再生方法及び装置

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

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

(11)【特許番号】

(24)【登録日】2024-04-16

(45)【発行日】2024-04-24

(54)【発明の名称】プログラム再生方法及び装置

(51)【国際特許分類】

   H04N 21/436 20110101AFI20240417BHJP

   H04N 21/637 20110101ALI20240417BHJP

   H04L 65/611 20220101ALI20240417BHJP

   H04L 65/65 20220101ALI20240417BHJP

【ＦＩ】

H04N21/436

H04N21/637

H04L65/611

H04L65/65

【請求項の数】 10

(21)【出願番号】P 2022558011

(86)(22)【出願日】2021-03-19

(65)【公表番号】

(43)【公表日】2023-05-10

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

(87)【国際公開番号】W WO2021190401

(87)【国際公開日】2021-09-30

【審査請求日】2022-10-20

(31)【優先権主張番号】202010231153.2

(32)【優先日】2020-03-27

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．

【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】スン，ハオ

(72)【発明者】

【氏名】ダイ，ウエンレイ

【審査官】大西 宏

(56)【参考文献】

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

【文献】特表２０１２－５０３９０７（ＪＰ，Ａ）

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

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

【文献】国際公開第２００７／１０２５４７（ＷＯ，Ａ１）

【文献】中国特許出願公開第１０１４１５０８２（ＣＮ，Ａ）

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

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

Ｈ０４Ｌ ６１／００ －６５／８０

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

【請求項1】

プログラム再生方法であって、
第１の伝送プロトコルを使用することにより送信されたプログラム再生要求メッセージを受信するステップであり、前記プログラム再生要求メッセージは、ターゲットプログラムチャネルに関連づけられたメディアファイル識別子を含み、前記第１の伝送プロトコルは、デジタルリビングネットワークアライアンスＤＬＮＡプロトコルである、ステップと、
前記メディアファイル識別子に基づいて対応するターゲットプログラムチャネルを決定するステップと、
第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにデータストリーム要求メッセージを送信するステップであり、前記データストリーム要求メッセージは、前記ターゲットプログラムチャネルの識別子を含み、前記ターゲットプログラムチャネルのデータストリームを送信するように前記ＩＰＴＶプラットフォームに要求するために使用され、前記第２の伝送プロトコルは、インターネットプロトコルテレビジョンＩＰＴＶプロトコルである、ステップと、
前記第２の伝送プロトコルを使用することにより前記ＩＰＴＶプラットフォームにより送信された前記データストリームを受信するステップと、
前記第１の伝送プロトコルを使用することにより、前記データストリームを再生のために再生デバイスに送信するステップと、
前記第１の伝送プロトコルを使用することにより送信されたプログラムクローズ命令メッセージを受信するステップであり、前記プログラムクローズ命令メッセージは、クローズされる必要がある前記ターゲットプログラムチャネルに関連づけられた前記メディアファイル識別子を含む、ステップと、
前記メディアファイル識別子に基づいて対応するターゲットプログラムチャネルを決定するステップと、
前記第２の伝送プロトコルを使用することにより前記ＩＰＴＶプラットフォームにプログラムクローズ要求メッセージを送信するステップであり、前記プログラムクローズ要求メッセージは、前記ターゲットプログラムチャネルの前記識別子を含み、前記ターゲットプログラムチャネルの前記データストリームのマルチキャストグループを去ることを要求するために使用される、ステップと
を含む方法。

【請求項2】

前記メディアファイル識別子が受信される前に、当該方法は、
前記第２の伝送プロトコルを使用することにより前記ＩＰＴＶプラットフォームにより送信されたチャネル情報リストを受信するステップであり、前記チャネル情報リストは、少なくとも２つのプログラムチャネルの識別子を含む、ステップと、
前記チャネル情報リスト内の各プログラムチャネルの識別子のためのメディアファイル識別子を追加するステップと、
各プログラムチャネルの前記識別子と前記メディアファイル識別子との間の対応表を記憶するステップと、
をさらに含む、請求項１に記載の方法。

【請求項3】

前記チャネル情報リストは、各プログラムチャネルのサーバアドレスをさらに含み、前記対応表も、各プログラムチャネルの前記サーバアドレスを含み、前記データストリーム要求メッセージは、前記ターゲットプログラムチャネルのサーバアドレスを含み、それにより、前記ＩＰＴＶプラットフォームは前記サーバアドレスにアクセスし、データストリームを取得する、請求項２に記載の方法。

【請求項4】

前記第２の伝送プロトコルは、インターネットグループ管理プロトコルＩＧＭＰプロトコルを含む、請求項１乃至３のうちいずれか１項に記載の方法。

【請求項5】

プログラム再生装置であって、
第１の伝送プロトコルを使用することにより送信されたプログラム再生要求メッセージを受信するように構成された通信ユニットであり、前記プログラム再生要求メッセージは、ターゲットプログラムチャネルに関連づけられたメディアファイル識別子を含み、前記第１の伝送プロトコルは、デジタルリビングネットワークアライアンスＤＬＮＡプロトコルである、通信ユニットと、
前記メディアファイル識別子に基づいて対応するターゲットプログラムチャネルを決定するように構成された処理ユニット、
を含み、
前記通信ユニットはさらに：第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにデータストリーム要求メッセージを送信し、前記データストリーム要求メッセージは、前記ターゲットプログラムチャネルの識別子を含み、前記ターゲットプログラムチャネルのデータストリームを送信するように前記ＩＰＴＶプラットフォームに要求するために使用され、前記第２の伝送プロトコルは、インターネットプロトコルテレビジョンＩＰＴＶプロトコルであり；前記第２の伝送プロトコルを使用することにより前記ＩＰＴＶプラットフォームにより送信された前記データストリームを受信し；前記第１の伝送プロトコルを使用することにより、前記データストリームを再生のために再生デバイスに送信する；ように構成されており、
前記第１の伝送プロトコルを使用することにより、前記データストリームが再生のために再生デバイスに送信された後、前記通信ユニットはさらに、
前記第１の伝送プロトコルを使用することにより送信されたプログラムクローズ命令メッセージを受信するように構成されており、前記プログラムクローズ命令メッセージは、クローズされる必要がある前記ターゲットプログラムチャネルに関連づけられた前記メディアファイル識別子を含み、
前記処理ユニットはさらに、前記メディアファイル識別子に基づいて対応するターゲットプログラムチャネルを決定するように構成されており、
前記通信ユニットはさらに、前記第２の伝送プロトコルを使用することにより前記ＩＰＴＶプラットフォームにプログラムクローズ要求メッセージを送信するように構成されており、前記プログラムクローズ要求メッセージは、前記ターゲットプログラムチャネルの前記識別子を含み、前記ターゲットプログラムチャネルの前記データストリームのマルチキャストグループを去ることを要求するために使用される、装置。

【請求項6】

前記メディアファイル識別子が受信される前に、前記通信ユニットはさらに、
前記第２の伝送プロトコルを使用することにより前記ＩＰＴＶプラットフォームにより送信されたチャネル情報リストを受信するように構成されており、前記チャネル情報リストは、少なくとも２つのプログラムチャネルの識別子を含み、
前記処理ユニットはさらに、前記チャネル情報リスト内の各プログラムチャネルの識別子のためのメディアファイル識別子を追加し、各プログラムチャネルの前記識別子と前記メディアファイル識別子との間の対応表を記憶する、ように構成されている、
請求項５に記載の装置。

【請求項7】

前記チャネル情報リストは、各プログラムチャネルのサーバアドレスをさらに含み、前記対応表も、各プログラムチャネルの前記サーバアドレスを含み、前記データストリーム要求メッセージは、前記ターゲットプログラムチャネルのサーバアドレスを含み、それにより、前記ＩＰＴＶプラットフォームは前記サーバアドレスにアクセスし、データストリームを取得する、請求項６に記載の装置。

【請求項8】

前記第２の伝送プロトコルは、インターネットグループ管理プロトコルＩＧＭＰプロトコルを含む、請求項５乃至７のうちいずれか１項に記載の装置。

【請求項9】

プログラム再生装置であって、
コンピュータプログラムを記憶するように構成されたメモリと、
前記メモリに記憶された前記コンピュータプログラムを実行して、当該装置が請求項１乃至４のうちいずれか１項に記載の方法を実行することを可能にするように構成されたプロセッサと、
を含む装置。

【請求項10】

コンピュータ読取可能媒体であって、コンピュータ実行可能命令を記憶し、前記コンピュータ実行可能命令は、コンピュータが請求項１乃至４のうちいずれか１項に記載の方法を実行することを可能にするために使用される、コンピュータ読取可能媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、2020年3月27日に中国国家知識産権局に出願され「PROGRAM PLAYING METHOD AND APPARATUS」と題された中国特許出願第202010231153.2号に対する優先権を主張しており、該出願はその全体を参照により本明細書に組み込まれている。

【0002】

［技術分野］
本出願は通信技術の分野に関し、特にプログラム再生方法及び装置に関する。

【背景技術】

【0003】

現在、事業者がインターネットプロトコルテレビジョン（internet protocol television、ＩＰＴＶ）サービスを運営するとき、ホームゲートウェイデバイスとセットトップボックス（set-top box、ＳＴＢ）端末が必要とされる。ユーザが初めてＩＰＴＶサービスに加入するとき、事業者はＳＴＢ端末を無料で提供する。しかしながら、ＳＴＢ端末が損傷した場合、ユーザは新しいＳＴＢ端末を購入する必要がある。さらに、事業者は、ＩＰＴＶサービスの配信及び小売のためにＳＴＢ製造業者から大量のＳＴＢ端末を収集する必要がある。

【0004】

したがって、現在のＩＰＴＶサービスは、事業者の比較的高いコストと、ユーザによりＩＰＴＶサービスに加入し及び維持するための比較的高いコストをもたらす。

【発明の概要】

【0005】

本出願は、従来の技術におけるＩＰＴＶサービスの事業者の比較的高いコストと、ユーザによりＩＰＴＶサービスに加入し及び維持するための比較的高いコストの問題を解決するためのプログラム再生方法及び装置を提供する。

【0006】

第１の態様によれば、本出願の一実施形態はプログラム再生方法を提供する。この方法は、本出願の一実施形態で提供される通信デバイスにより実行されてもよい。通信デバイスは、ＳＴＢ機能モジュールとＤＭＳ機能モジュールとを含むデバイスでもよい。例えば、この方法は、ＳＴＢ機能を有するゲートウェイデバイスに適用されてもよい。この方法において、通信デバイスは、第１の伝送プロトコルを使用することにより送信されたプログラム再生要求メッセージを受信する。プログラム再生要求メッセージは、ターゲットプログラムチャネルに関連づけられたメディアファイル識別子を含む。第１の伝送プロトコルは、ＤＬＮＡプロトコルでもよい。通信デバイスは、メディアファイル識別子に基づいて対応するターゲットプログラムチャネルを決定し、第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにデータストリーム要求メッセージを送信することができる。データストリーム要求メッセージは、ターゲットプログラムチャネルの識別子を含み、ターゲットプログラムチャネルのデータストリームを送信するようにＩＰＴＶプラットフォームに要求するために使用することができる。第２の伝送プロトコルは、インターネットプロトコルテレビジョンＩＰＴＶプロトコルでもよい。データストリーム要求メッセージを受信した後、ＩＰＴＶプラットフォームは、ターゲットプログラムチャネルのサーバにアクセスしてデータストリームを取得し、取得されたデータストリームを通信デバイスに送信することができる。通信デバイスは、第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにより送信されたデータストリームを受信し、第１の伝送プロトコルを使用することにより、データストリームを再生のために再生デバイスに送信する。

【0007】

一例において、第２の伝送プロトコルは、リアルタイムトランスポートプロトコル（real-time transport protocol、ＲＴＰ）、リアルタイムストリーミングプロトコル（real-time streaming protocol、ＲＴＳＰ）、及びインターネットグループ管理プロトコル（internet group management protocol、ＩＧＭＰ）を含んでもよい。

【0008】

この解決策に基づき、通信デバイスを使用することにより、ゲートウェイの機能及びＩＰＴＶプラットフォームにアクセスする機能を実現することができるため、ユーザは、ＳＴＢ端末を別個に申し込む必要がなく、それにより、ＩＰＴＶ事業者のコスト、及びユーザによりＩＰＴＶサービスに加入し及び維持するためのコストを削減することができる。

【0009】

可能な一実装において、通信デバイスは、開始された後、第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにより送信されたチャネル情報リストを受信してもよい。チャネル情報リストは、ＩＰＴＶサービスにより提供されるプログラムチャネルの識別子を含むことができる。通信デバイスは、チャネル情報リスト内の各プログラムチャネルの識別子のためのメディアファイル識別子を追加し、プログラムチャネルの識別子とメディアファイル識別子との間の対応表を記憶してもよい。したがって、通信デバイスは、対応表に基づいて、プログラム再生要求メッセージに含まれるメディアファイル識別子に対応するターゲットプログラムチャネルを決定することができる。

【0010】

この解決策に基づいて、通信デバイスは、ＩＰＴＶ伝送プロトコルを使用することによりチャネル情報リストを受信し、チャネル情報リスト内の各プログラムチャネルの識別子のためのメディアファイル識別子を追加し、各プログラムチャネルの識別子とメディアファイル識別子との間の対応表を記憶して、ＩＰＴＶプラットフォームへのアクセスを実現することができる。

【0011】

可能な一実装において、チャネル情報リストは、各プログラムチャネルのサーバアドレスをさらに含み、対応表も、各プログラムチャネルのサーバアドレスを含む。通信デバイスによりＩＰＴＶプラットフォームに送信されるデータストリーム要求メッセージは、ターゲットプログラムチャネルのサーバアドレスを含むこともでき、それにより、ＩＰＴＶプラットフォームはサーバアドレスにアクセスし、ターゲットプログラムチャネルのデータストリームを取得する。

【0012】

この解決策に基づいて、通信デバイスは、第１の伝送プロトコルを使用することにより送信されたチャネル情報リストに基づいて各プログラムチャネルのサーバアドレスを決定し、データストリーム要求メッセージにターゲットプログラムチャネルのサーバアドレスを追加することができ、それにより、ＩＰＴＶプラットフォームは、サーバアドレスに基づいてターゲットプログラムチャネルのデータストリームを取得することができる。

【0013】

可能な一実装において、第１の伝送プロトコルを使用することにより、データストリームを再生のために再生デバイスに送信した後、通信デバイスは、さらに、第１の伝送プロトコルを使用することにより送信されたプログラムクローズ命令メッセージを受信してもよい。プログラムクローズ命令メッセージは、クローズされる必要があるターゲットプログラムチャネルに関連づけられたメディアファイル識別子を含むことができる。通信デバイスは、メディアファイル識別子に基づいて対応するターゲットプログラムチャネルを決定してもよい。例えば、通信デバイスは、対応表に基づいて、メディアファイル識別子に対応するターゲットプログラムチャネルを決定することができる。通信デバイスは、第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにプログラムクローズ要求メッセージを送信してもよい。プログラムクローズ要求メッセージは、ターゲットプログラムチャネルの識別子を含むことができ、プログラムクローズ要求メッセージは、ターゲットプログラムチャネルのデータストリームのマルチキャストグループを去ることを要求するために使用することができる。プログラムクローズ要求メッセージを受信した後、ＩＰＴＶプラットフォームは、ターゲットプログラムチャネルのデータストリームのマルチキャストグループから通信デバイスを除去してもよく、それにより、通信デバイスは、ＩＰＴＶプラットフォームにより送信されるターゲットプログラムチャネルのデータストリームを受信しない。

【0014】

この解決策に基づいて、通信デバイスは、ＤＬＮＡ伝送プロトコルを使用することにより受信したプログラムクローズ命令メッセージ内のメディアファイル識別子に基づいて、クローズされる必要があるターゲットプログラムチャネルを決定し、ＩＰＴＶ伝送プロトコルを使用することによりＩＰＴＶプラットフォームにプログラムクローズ要求メッセージを送信して、ターゲットプログラムチャネルをクローズすることができる。

【0015】

第２の態様によれば、本出願の一実施形態は、第１の態様及び第１の態様の可能な実装のいずれか１つにおける動作を実行するように構成され得るプログラム再生装置をさらに提供する。例えば、この装置は、第１の態様及び第１の態様の可能な実装のいずれか１つにおける動作を実行するように構成されたモジュール又はユニットを含んでもよい。例えば、この装置は、通信ユニットと処理ユニットを含む。

【0016】

第３の態様によれば、本出願の一実施形態は、別のプログラム再生装置をさらに提供する。この装置は、トランシーバと、トランシーバに結合されたプロセッサとを含んでもよく、第１の態様及び第１の態様の可能な実装のいずれか１つにおける動作を実行するように構成されてもよい。

【0017】

第４の態様によれば、本出願の一実施形態は、コンピュータプログラム製品を提供する。コンピュータプログラム製品は、コンピュータプログラムコードを含み、コンピュータプログラムコードが、プログラム再生装置の通信ユニット及び処理ユニット、又はトランシーバ及びプロセッサにより実行されると、プログラム再生装置は、第１の態様及び第１の態様の可能な実装のいずれか１つにおける方法を実行する。

【0018】

第５の態様によれば、本出願の一実施形態は、コンピュータ読取可能記憶媒体を提供する。コンピュータ読取可能記憶媒体は、プログラムを記憶し、プログラムは、プログラム再生装置が第１の態様及び第１の態様の可能な実装のいずれか１つにおける方法を実行することを可能にする。

【0019】

第２の態様から第５の態様のいずれか１つ、又は態様のうちいずれか１つのいずれかの設計で達成することができる技術的効果については、第１の態様のいずれか１つ及び第１の態様の設計で達成することができる技術的効果を参照する。詳細はここで再度説明されない。

【図面の簡単な説明】

【0020】

【図1】本出願によるテレビジョンプログラム再生システムの概略図である。

【図2】本出願によるプログラム再生方法の一例示的なフローチャートである。

【図3】本出願によるユーザ装置のインターフェースの概略図である。

【図4】本出願によるプログラム再生方法の一例示的なフローチャートである。

【図5】本出願によるユーザ装置のインターフェースの概略図である。

【図6】本出願によるプログラム再生装置のブロック図である。

【図7】本出願によるプログラム再生装置のブロック図である。

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

【0021】

以下では、添付の図面を参照して本出願の技術的な解決策について説明する。

【0022】

現在、事業者がインターネットプロトコルテレビジョン（internet protocol television、ＩＰＴＶ）サービスを運営するとき、ホームゲートウェイデバイスとセットトップボックス（set-top box、ＳＴＢ）端末が必要とされる。ユーザが初めてＩＰＴＶサービスに加入するとき、事業者はＳＴＢ端末を無料で提供する。しかしながら、ＳＴＢ端末が損傷した場合、ユーザは新しいＳＴＢ端末を購入する必要がある。さらに、事業者は、ＩＰＴＶサービスの配信及び小売のためにＳＴＢ製造業者から大量のＳＴＢ端末を収集する必要がある。したがって、現在のＩＰＴＶサービスは、事業者の比較的高いコストと、ユーザによりＩＰＴＶサービスに加入し及び維持するための比較的高いコストをもたらす。

【0023】

ユーザが自宅でＩＰＴＶサービスに加入していない場合、ユーザは、スマートテレビジョンを使用することにより対応するオーバー・ザ・トップ（over the top、ＯＴＴ）プラットフォームテレビジョンプログラムを視聴し、あるいはＯＴＴクライアントを介してモバイル端末又はＰＣを使用することによりネットワークビデオを視聴することができる。前述の２つの方法では、ビデオはネットワークを介して伝送され、明らかなフリーズがしばしば発生する。さらに、スマートテレビジョンとＯＴＴクライアントの双方がＯＴＴプラットフォームに結びつけられて（bound）おり、著作権制限に起因して、スマートテレビジョン及びＯＴＴクライアントにより提供することができるプログラムコンテンツは、ＩＰＴＶプラットフォームにより提供されるプログラムコンテンツと大きく異なる場合がある。主な差は次のとおりである。ＯＴＴプラットフォームは、より少ないオンデマンドのビデオ及びライブビデオを提供し、ビデオがＯＴＴプラットフォーム上で初めて公開される（goes live）とき、より大きい遅延を有する。さらに、モバイル端末は画面サイズにより制限されるため、ユーザは、大画面再生によりもたらされる視覚的な楽しみを享受できない場合がある。

【0024】

本出願は、前述の問題を解決するために、事業者のコストと、ユーザによりＩＰＴＶサービスに加入し及び維持するためのコストを削減するためのプログラム再生方法を提供する。本出願では、複数のデバイス、コンポーネント、モジュールなどを含み得るシステムを説明することにより、全ての態様、実施形態、又は特徴が提示される。各システムが別のデバイス、コンポーネント、モジュールなどを含んでもよく、かつ／あるいは添付の図面を参照して論じられる全てのデバイス、コンポーネント、モジュールなどを含まなくてもよいことを認識及び理解されたい。さらに、これらの解決策の組み合わせが使用されてもよい。

【0025】

本出願の実施形態の理解を容易にするために、最初に、図１に示すテレビジョンプログラム再生システムを一例として用いて、本出願の実施形態に適用可能なネットワークシステムを詳細に説明する。図１は、本出願の実施形態で提供されるプログラム再生方法に適用可能なネットワークシステムのフレームワークの図である。ネットワークシステム１００は、ＩＰＴＶプラットフォーム１０１、再生デバイス１０２、及び通信デバイス１０３を含む。通信デバイス１０３は、信号の送信及び受信に関連する複数のコンポーネント（例えば、プロセッサ、変調器、マルチプレクサ、復調器、又はデマルチプレクサ）をさらに含んでもよいことを理解されたい。

【0026】

再生デバイス１０２は、ビデオファイル又はオーディオファイルを再生する機能を有するデバイス、又はデバイス内に配置され得るチップであり、このデバイスには、これらに限られないが、テレビジョン（television、ＴＶ）、モバイルフォン（mobile phone）、タブレットコンピュータ（Ｐａｄ）、無線トランシーバ機能を有するコンピュータ、仮想現実（virtual reality、ＶＲ）デバイス、拡張現実（augmented reality、ＡＲ）デバイスなどが含まれる。本出願の再生デバイス１０２は、デジタルリビングネットワークアライアンス（digital living network alliance、ＤＬＮＡ）技術及びプロトコルをサポートすることができることに留意されたい。

【0027】

ネットワークシステム１００において、ＩＰＴＶプラットフォーム１０１は、複数の通信デバイス（例えば、図に示す通信デバイス１０３）と通信することができる。通信デバイス１０３は、複数の再生デバイス（例えば、図に示す再生デバイス１０２）と通信することができる。通信デバイス１０３は、ゲートウェイデバイス、ＳＴＢなどでもよい。

【0028】

本出願の実施形態の図１に記載されるネットワークアーキテクチャ及びサービスシナリオは、本出願の実施形態における技術的解決策をより明確に説明することを意図しているが、本出願の実施形態で提供される技術的解決策を制限することを意図していない。当業者は、ネットワークアーキテクチャが進化し、新しいサービスシナリオが出現すると、本出願の実施形態で提供される技術的解決策が別の同様のネットワークシステムフレームワークにさらに適用される場合があることが分かり得る。

【0029】

以下の説明における語「例」は、例、例示、又は説明を示すために使用される。本出願において「例」として記載される実施形態又は設計スキームは、別の実施形態又は設計スキームよりもより好ましいか又はより多くの利点を有するものとして説明されるべきではない。正確に、語「例」は、特定の方法で概念を提示するために用いられる。

【0030】

本出願の実施形態において、「情報（information）」、「信号（signal）」、「メッセージ（message）」、及び「チャネル（channel）」は、時に互換的に使用されることがある。差が強調されないとき、表現される意味は一貫していることに留意されたい。「の（of）」、「関連する（corresponding又はrelevant）」、及び「対応する（corresponding）」は、時に互換的に使用されることがある。差が強調されないとき、表現される意味は一貫していることに留意されたい。

【0031】

図１は、理解を容易にするための一例示的な簡略化された概略図に過ぎないことを理解されたい。ネットワークシステムは、図１に描かれていない別の通信デバイス又は別の再生デバイスをさらに含んでもよい。

【0032】

本出願の実施形態における通信デバイスは、セットトップボックス（set-top box、ＳＴＢ）機能モジュール及びデジタルメディアサーバ（Digital Media Server、ＤＭＳ）機能モジュールを含むことができるデバイスである。ＳＴＢ機能モジュールは、再生デバイスにビデオストリーム又は信号ソースを提供するように構成される。ＤＭＳ機能モジュールは、メディア共有能力を提供する。具体的には、ＤＭＳ機能モジュールは、特定のメカニズムを使用することにより、ネットワーク上にあり、かつＤＭＳ機能モジュールとマッチすることができる、ＤＭＳ装置又はインターフェースモジュールを探索する。接続が成功した後、後続のメディアデータ伝送アクションが実行され得る。ゲートウェイデバイスは、通常、ＤＭＳ機能モジュールを含む。したがって、本出願における通信デバイスは、ＳＴＢ機能を有するゲートウェイデバイスでもよい。例えば、ＳＴＢ機能は、ゲートウェイ、又はゲートウェイ様デバイスに統合されてもよい。例えば、ＳＴＢ機能と統合されたプラグインがゲートウェイデバイスにロードされ、あるいは、ＳＴＢ機能がコンピュータプログラムの形態でゲートウェイデバイスにロードされてもよい。

【0033】

本出願の実施形態で提供される技術的解決策を明確に理解するために、以下では、まず、各プログラムチャネルの識別子とメディアファイル識別子との間の対応表を生成する方法について説明する。

【0034】

一例において、ユーザがＩＰＴＶサービスに加入するとき、通信デバイスは、起動された後、ＩＰＴＶプラットフォームに対する認証手順を開始する。具体的には、認証手順は以下のステップを含んでもよい。

【0035】

（１）通信デバイスが、セットトップボックスバージョンサーバからのバージョンアップデートを要求する。

【0036】

（２）セットトップボックスバージョンサーバが、通信デバイスの現在のバージョンが更新される必要があるかどうかをチェックし、バージョンが更新される必要がある場合、最新バージョンを返し、それにより通信デバイスのバージョンが更新され、そうでない場合、バージョンが更新される必要がないことを通信デバイスに通知する。

【0037】

（３）通信デバイスが、Ｐ－ＣＳＣＦへのログイン要求を開始し、アカウント及びパスワードを入力し、プロキシコールセッション制御機能（proxy-call session control function、Ｐ－ＣＳＣＦ）にサービス認証要求をサブミットして、アカウント及びパスワードをインターネットプロトコルマルチメディアサブシステム（internet protocol multimedia subsystem、ＩＭＳ）コアネットワークに送信するようにＰ－ＣＳＣＦに要求する。

【0038】

（４）ＩＭＳコアネットワークが、関連する機能エンティティと相互作用し、アカウント及びパスワードにおける認証が成功した後、一時的アイデンティティ証明書及び認可情報を生成し、認証が成功したことをＩＰＴＶ ＡＳユーザに通知する。

【0039】

（５）ＩＭＳコアネットワークが、認証結果、一時的アイデンティティ証明書、及び認可情報をＰ－ＣＳＣＦに返し、Ｐ－ＣＳＣＦは、認証結果、一時的アイデンティティ証明書、及び認可情報に基づいて新しいページを生成し、認証結果、一時的アイデンティティ証明書、及び認可情報を通信デバイスに返す。

【0040】

（６）通信デバイスが、新しいページに基づいて電気プログラムガイド（electrical program guide、ＥＰＧ）を更新し、認可情報及び一時的アイデンティティ証明書を記録する。

【0041】

本出願の実施形態における認証手順は、通信デバイスにおけるＳＴＢ機能モジュールにより実行されてもよいことを理解されたい。

【0042】

認証手順が実行された後、通信デバイスにおけるＳＴＢ機能モジュールは、更新されたＥＰＧからチャネル情報リストを抽出することができる。チャネル情報リストは、少なくとも２つのプログラムチャネルの識別子、及び対応するサーバアドレスを含むことができる。例えば、チャネル情報リストは、表１に示すように、ＩＰＴＶプラットフォームにより提供されるチャネル（例えば、ＣＣＴＶ－１）と、チャネルのサーバアドレスを含んでもよい。

【表1】

【0043】

チャネル情報リストは、第２の伝送プロトコルを使用することにより受信されてもよいことを理解されたい。ＳＴＢ機能モジュールは、通信デバイスにおけるＤＭＳ機能モジュールにチャネル情報リストを送信することができる。ＤＭＳ機能モジュールは、各プログラムチャネルの識別子のためのメディアファイル識別子を追加することができる。

【0044】

一実施形態において、メディアファイル識別子は、各プログラムチャネルのメディアファイルの名前でもよい。例えば、ＤＭＳ機能モジュールは、各プログラムチャネルの識別子のメディアファイルを作成及び記憶することができる。ここではメディアファイルにデータが記憶されないことに留意されたい。ＤＭＳ機能モジュールは、メディアファイルを記憶するためのアドレスに基づいて、メディアファイルにアクセスするためのユニフォームリソースロケータ（uniform resource locator、ＵＲＬ）アドレスを生成することができる。ＤＭＳ機能モジュールは、各プログラムチャネルの識別子とメディアファイル識別子との間の対応表を記憶することができる。対応表は、表２に示すように、各プログラムチャネルのメディアファイル識別子、プログラムチャネルの識別子、サーバアドレス、及びＵＲＬアドレスを含むことができる。

【表2】

【0045】

対応表を生成した後、ＤＭＳ機能モジュールは、対応表を再生デバイス及び／又はユーザ装置（user equipment、ＵＥ）に送信することができる。

【0046】

本出願の実施形態で提供される技術的解決策を、添付の図面を参照して以下で説明する。図２は、本出願の一実施形態で提供され、かつデバイス相互作用の観点から示される、プログラム再生方法の例示的なフローチャートである。図２に示すように、この方法は以下のステップを含むことができる。

【0047】

ステップ２０１：通信デバイスが、第１の伝送プロトコルを使用することにより送信されたプログラム再生要求メッセージを受信する。

【0048】

本明細書における第１の伝送プロトコルは、ＤＬＮＡプロトコルでもよい。通信デバイスは、プログラム再生要求メッセージを受信すると、プログラム再生要求メッセージをパースして（parse）、プログラム再生要求メッセージ内の情報を取得することができる。プログラム再生要求メッセージは、ターゲットプログラムチャネルに関連づけられたメディアファイル識別子を含むことができる。プログラム再生要求メッセージ内のターゲットプログラムチャネルは、ユーザが再生することを要求するプログラムチャネルである。

【0049】

本出願のこの実施形態において、プログラム再生要求メッセージは、以下の２つの方法で送信される。

【0050】

方法１：ユーザが、再生デバイスを使用することによりプログラム再生要求メッセージを送信する。

【0051】

本明細書における再生デバイスは、デジタルメディアコントローラ（digital media controller、ＤＭＣ）の関連機能と統合されてもよい。

【0052】

一例において、ユーザは、リモートコントロールを使用することにより、プログラム再生要求メッセージを送信するように再生デバイスを制御することができる。例えば、ユーザは、リモートコントロール上のキーを使用することにより、ユーザが視聴したいチャネルを選択してもよく、リモートコントロールは、押されたキーを検出することができ、次いで、モールス符号と似た形式でキー情報を符号化し、次いで、無線周波数信号を再生デバイスに送信することができる。再生デバイスは、無線周波数信号とプログラムチャネルとの間の対応に基づいて、無線周波数信号に対応するプログラムチャネルを決定することができ、あるいはプログラムチャネルの識別子とメディアファイル識別子との間の対応表に基づいて、プログラムチャネルのメディアファイル識別子を決定することができる。したがって、再生デバイスは、決定されたメディアファイル識別子をＤＭＳ機能モジュールに送信することができる。

【0053】

一実施形態において、プログラム再生要求メッセージは、ハイパーテキストトランスファープロトコル（hypertext transfer protocol、ＨＴＴＰ）要求で搬送されてもよい。例えば、再生デバイスは、プログラムチャネルの識別子とメディアファイル識別子との間の対応表に基づいてプログラムチャネルのＵＲＬアドレスを取得し、このＵＲＬアドレスを搬送するＨＴＴＰ要求を通信デバイスにおけるＤＭＳモジュールに送信して、対応するメディアファイルにアクセスすることを要求することができる。

【0054】

別の例において、ユーザは、再生デバイスのキーを使用することにより、プログラム再生要求メッセージを送信するように再生デバイスを制御することができる。例えば、ユーザは、キーを使用することにより、ユーザが視聴したいチャネルを選択する。再生デバイスは、選択されたプログラムチャネルの識別子を識別し、プログラムチャネルの識別子とメディアファイル識別子との間の対応表に基づいてプログラムチャネルのメディアファイル識別子を決定することができる。したがって、再生デバイスは、識別されたメディアファイル識別子を通信デバイスにおけるＤＭＳ機能モジュールに送信することができる。

【0055】

一実施形態において、プログラム再生要求メッセージは、ＨＴＴＰ要求で搬送されてもよい。例えば、再生デバイスは、プログラムチャネルのメディアファイル識別子を決定した後、対応表に基づいてプログラムチャネルのＵＲＬアドレスを決定し、このＵＲＬアドレスを搬送するＨＴＴＰ要求を通信デバイスにおけるＤＭＳ機能モジュールに送信して、対応するメディアファイルにアクセスすることを要求してもよい。

【0056】

方法２：ユーザが、ＵＥのアプリケーションを使用することによりプログラム再生要求メッセージを送信する。

【0057】

ＵＥのアプリケーションは、ＤＭＣの機能を実現することができる。一例において、ＵＥは、ユニバーサルプラグアンドプレイ（universal plug and play、ＵＰＮＰ）プロトコルを使用することにより同じネットワーク環境内の通信デバイス及び再生デバイスを探索してもよく、それにより、通信デバイス、再生デバイス、及びＵＥは、互いに通信することができる。

【0058】

ＤＭＳ機能モジュールにより送信された対応表を受信した後、ＵＥのアプリケーションは、図３に示すプログラムリストを表示することができ、この場合、ユーザは、プログラムリストを使用することにより、ユーザが視聴したいプログラムを選択することができる。ＵＥのアプリケーションは、選択されたプログラムチャネルを識別し、選択されたプログラムチャネルの識別子に基づいて対応表からメディアファイル識別子を取得することができる。ＵＥは、ＵＰＮＰメッセージを使用することにより、メディアファイル識別子を搬送するプログラム再生要求メッセージを再生デバイスに送信することができ、再生デバイスは、プログラム再生要求メッセージを通信デバイスに送信することができる。

【0059】

一実施形態において、プログラム再生要求メッセージは、ＨＴＴＰ要求で搬送されてもよい。例えば、プログラム再生要求メッセージを受信した後、再生デバイスは、対応表からＵＲＬアドレスを取得することができる。代替的に、ＵＥが、選択されたプログラムチャネルの識別子に基づいて対応表からＵＲＬアドレスを取得してもよい。ＵＥは、ＵＰＮＰメッセージを使用することによりＵＲＬアドレスを再生デバイスに送信することができる。再生デバイスは、ＵＲＬアドレスを搬送するＨＴＴＰ要求を通信デバイスにおけるＤＭＳ機能モジュールに送信して、対応するメディアファイルにアクセスすることを要求することができる。

【0060】

一般に、通信デバイスのストレージは限られているため、通信デバイスは、プログラムに対応する完全なメディアデータをローカルに記憶しないことを理解されたい。したがって、方法１及び方法２で提供されるメディアファイルは、空のファイルでもよく、換言すれば、特定のメディアデータを含まない。あるいは、メディアファイルは、仮想ファイルでもよく、メディアファイル名のみが存在し、実際のファイルはローカルに存在しない。メディアファイルは、メディアファイル識別子と１対１対応していてもよい。

【0061】

ステップ２０２：通信デバイスが、受信したメディアファイル識別子に基づいて対応するターゲットプログラムチャネルを決定する。

【0062】

通信デバイスは、対応表（表２）に基づいて、メディアファイル識別子に対応するターゲットプログラムチャネルを決定してもよい。ＤＭＳ機能モジュールは、ターゲットプログラムチャネルの識別子をＳＴＢ機能モジュールに送信することができる。

【0063】

ステップ２０３：通信デバイスが、第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにデータストリーム要求メッセージを送信する。

【0064】

本明細書におけるデータストリーム要求メッセージは、ターゲットチャネルの識別子を含み、データストリーム要求メッセージは、ターゲットプログラムチャネルのデータストリームを送信するようにＩＰＴＶプラットフォームに要求するために使用される。第２の伝送プロトコルは、ＩＰＴＶプロトコルでもよく、ＩＰＴＶプロトコルは、ＲＴＰプロトコル、ＲＴＳＰプロトコル、ＩＧＭＰプロトコルなどを含んでもよい。

【0065】

一例において、通信デバイスは、データストリーム要求メッセージにターゲットプログラムチャネルのサーバアドレスをさらに追加し、データストリーム要求メッセージをＩＰＴＶプラットフォームに送信してもよい。データストリーム要求メッセージを受信した後、ＩＰＴＶプラットフォームは、サーバアドレスに基づいてターゲットプログラムチャネルのサーバにアクセスし、ターゲットプログラムチャネルのデータストリームを取得し、データストリームを通信デバイスに送信することができる。ターゲットプログラムチャネルのデータストリームを複数の通信デバイスが要求する場合があるため、ＩＰＴＶプラットフォームは、ターゲットプログラムチャネルのデータストリームを要求する通信デバイスのリストを記憶してもよい。例えば、ターゲットプログラムチャネルの識別子を搬送するデータストリーム要求メッセージを受信した後、ＩＰＴＶプラットフォームは、データストリーム要求メッセージを送信する通信デバイスのアイデンティティ情報を通信デバイスのリストに記憶し、通信デバイスのリスト内の各通信デバイスにデータストリームを送信してもよい。

【0066】

別の例において、データストリーム要求メッセージは、ＩＧＭＰレポート（report）パケットでもよい。ＳＴＢ機能モジュールは、ＩＧＭＰレポートパケットをＩＰＴＶプラットフォームに送信することができる。ＩＧＭＰプロトコルでは、サーバアドレスはマルチキャストグループを識別することができる。マルチキャストグループ内のメンバは、マルチキャストデータストリームを受信することができ、マルチキャストグループ内のメンバ以外のデバイスは、マルチキャストデータストリームを受信することができない。したがって、通信デバイスは、対応表に基づいてターゲットプログラムチャネルのサーバアドレスを決定し、ターゲットプログラムチャネルの識別子及びサーバアドレスをレポートパケットに追加することができる。レポートパケットを受信した後、ＩＰＴＶプラットフォームは、通信デバイスのアイデンティティ情報をマルチキャストグループ内のメンバに追加し、ターゲットプログラムチャネルのデータストリームを通信デバイスにプッシュすることができる。

【0067】

ステップ２０４：通信デバイスが、第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにより送信されたデータストリームを受信する。

【0068】

ステップ２０５：通信デバイスが、第１の伝送プロトコルを使用することにより、データストリームを再生のために再生デバイスに送信する。

【0069】

一実施形態において、ＩＰＴＶプラットフォームにより送信されたデータストリームを受信した後、ＳＴＢ機能モジュールは、ＳＴＢ機能モジュールとターゲットプログラムチャネルのメディアファイルとの間のパイプ（pipe）を確立し、そのパイプにデータストリームを送信することができる。パイプの書き込み端は、ＳＴＢ機能モジュールがパイプに接続されている側であり、パイプの読み取り端は、パイプがメディアファイルに接続されている側である。

【0070】

ＩＰＴＶプラットフォームにより送信されたデータストリームを受信した後、通信デバイスは、データストリームをパイプの書き込み端に書き込む。ＤＭＳ機能モジュールは、パイプの読み取り端からデータストリームを読み取り、第１の伝送プロトコルを使用することにより、データストリームを再生のために再生デバイスに送信することができる。

【0071】

一例において、再生デバイスは、データストリームを復号及び再生することができる。ＤＬＮＡプロトコルをサポートする再生デバイスは復号機能を有することを理解されたい。

【0072】

別の例において、通信デバイスが、データストリームを復号し、第１の伝送プロトコルを使用することにより再生デバイスに復号した後に得られたデータを送信してもよい。本明細書における再生デバイスは、復号機能を有さない場合がある。

【0073】

この解決策に基づき、通信デバイスを使用することにより、ゲートウェイの機能及びＩＰＴＶプラットフォームにアクセスする機能を実現することができるため、ユーザは、ＳＴＢ端末を別個に申し込む必要がなく、それにより、ＩＰＴＶ事業者のコスト、及びユーザによりＩＰＴＶサービスに加入し及び維持するためのコストを削減することができる。

【0074】

本出願の実施形態において、再生デバイス上で再生されるプログラムは、さらにクローズされ得る。図４は、本出願の一実施形態における、デバイス相互作用の観点から示された、再生されているプログラムをクローズするための例示的なフローチャートである。この方法は、以下のステップを含むことができる。

【0075】

ステップ４０１：通信デバイスが、第１の伝送プロトコルを使用することにより送信されたプログラムクローズ命令メッセージを受信する。

【0076】

本明細書におけるプログラムクローズ命令メッセージは、クローズされる必要があるターゲットプログラムチャネルに関連づけられたメディアファイル識別子を含むことができる。メディアファイル識別子及び第１の伝送プロトコルについては、前述の方法の実施形態における関連する説明を参照する。詳細はここで再度説明されない。

【0077】

本出願のこの実施形態において、プログラムクローズ命令メッセージは、以下の２つの方式で送信されてもよい。

【0078】

方法１：ユーザが、再生デバイスを使用することによりプログラムクローズ命令メッセージを送信する。

【0079】

本明細書における再生デバイスは、ＤＭＣの関連機能と統合されてもよい。

【0080】

一例において、ユーザは、リモートコントロール上のクローズキーを使用することにより、再生されているターゲットプログラムチャネルをクローズすることができる。この場合、リモートコントロールは、対応する無線周波数信号を再生デバイスに送信することができる。再生デバイスは、ターゲットプログラムチャネルのメディアファイル識別子及び／又はターゲットプログラムチャネルの識別子を識別し、メディアファイル識別子及び／又はターゲットプログラムチャネルの識別子をプログラムクローズ命令メッセージに追加し、第１の伝送プロトコルを使用することによりプログラムクローズ命令メッセージを通信デバイスに送信することができる。再生デバイスは、さらに、無線周波数信号に基づいて電源オフされてもよい。

【0081】

方式２：ユーザが、ＵＥのアプリケーションを使用することによりプログラムクローズ命令メッセージを送信する。

【0082】

ＵＥのアプリケーションは、ＤＭＣの機能を実現することができる。ユーザが、ステップ２０１からステップ２０５を通じて選択されたプログラムを再生した後、再生されているプログラムは、図５に示すように、ＵＥに表示されてもよい。ユーザは、インターフェース内で、再生されているプログラムをクローズする。例えば、ユーザは、クローズキーを使用することにより、再生されているプログラムをクローズしてもよく、あるいは、ユーザは、再生されているプログラム上でダブルタップし又はスライド操作を実行して、プログラムをクローズしてもよい。これは、本出願において具体的に限定されない。ＵＥは、プログラムのメディアファイル識別子を識別することができ、したがって、ＵＥは、ＵＰＮＰメッセージを使用することにより、メディアファイル識別子を搬送するプログラムクローズ命令メッセージを通信デバイスにおけるＤＭＳ機能モジュールに送信することができる。

【0083】

ステップ４０２：メディアファイル識別子に基づいて対応するターゲットプログラムチャネルを決定する。

【0084】

本明細書における通信デバイスは、プログラムチャネルの識別子とメディアファイル識別子との間の対応表に基づいて、メディアファイル識別子に対応するターゲットプログラムチャネルを決定することができる。通信デバイスは、さらに、対応表に基づいてターゲットプログラムチャネルのサーバアドレスを決定することができる。

【0085】

ステップ４０３：通信デバイスが、第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにプログラムクローズ要求メッセージを送信する。

【0086】

通信デバイスは、プログラムクローズ要求メッセージにターゲットプログラムチャネルの識別子を追加し、プログラムクローズ要求メッセージをＩＰＴＶプラットフォームに送信することができる。プログラムクローズ要求メッセージを受信した後、ＩＰＴＶプラットフォームは、通信デバイスのアイデンティティ情報を、ターゲットプログラムチャネルの通信デバイスのリストから削除することができる。この場合、ＩＰＴＶプラットフォームは、ターゲットプログラムチャネルのデータストリームを通信デバイスにもはや送信しなくなる。

【0087】

一例において、プログラムクローズ要求メッセージは、ＩＧＭＰリーブ（leave）パケットでもよい。ＳＴＢ機能モジュールは、ターゲットプログラムチャネルの識別子及びターゲットプログラムチャネルのサーバアドレスをリーブパケットに追加することができる。ＳＴＢ機能モジュールにより送信されたＩＧＭＰリーブパケットを受信した後、ＩＰＴＶプラットフォームは、通信デバイスのアイデンティティ情報を、サーバアドレスにより識別されたマルチキャストグループから削除することができ、それにより、ＩＰＴＶプラットフォームは、ターゲットプログラムチャネルのデータストリームを通信デバイスにもはや送信しなくなる。

【0088】

通信デバイスにおけるＳＴＢ機能モジュールは、ＳＴＢ機能モジュールとターゲットプログラムチャネルのメディアファイルとの間のパイプの書き込み端へのデータストリームの送信を停止することもでき、ＤＭＳ機能モジュールは、パイプの読み取り端からのデータストリームの読み取りを停止することができる。

【0089】

前述では、本出願の実施形態におけるプログラム再生方法について、図１～図５を参照して詳細に説明している。以下では、本出願の実施形態におけるプログラム再生装置について、図６及び図７を参照して詳細に説明する。

【0090】

プログラム再生装置６００は、１つ以上のプロセッサ６０１を含み、１つ以上のプロセッサ６０１は、図２又は図４に示す実施形態における方法を実施することができる。

【0091】

可能な一設計において、プログラム再生装置６００は、メディアファイル識別子に基づいて対応するターゲットプログラムチャネルを決定するように構成された手段（means）を含む。メディアファイル識別子及びターゲットプログラムチャネルについては、前述の方法の実施形態における関連する説明を参照する。例えば、ターゲットプログラムチャネルは、１つ以上のプロセッサを使用することにより決定されてもよい。任意で、プロセッサ６０１は、図２又は図４に示す実施形態における方法を実施することに加えて、別の機能を実施してもよい。

【0092】

任意で、一設計において、プロセッサ６０１は命令６０３を実行してもよく、それにより、プログラム再生装置６００は、前述の方法の実施形態で説明された方法を実行する。命令の全部又は一部がプロセッサに記憶されてもよく、あるいはプロセッサに結合されたメモリ６０２に記憶されてもよい。

【0093】

別の可能な設計において、プログラム再生装置６００は回路をさらに含んでもよく、回路は前述の方法の実施形態における機能を実施してもよい。

【0094】

さらに別の可能な設計において、プログラム再生装置６００は、１つ以上のメモリ６０２を含んでもよい。１つ以上のメモリ６０２は命令６０４を記憶し、命令はプロセッサ上で実行することができ、それにより、プログラム再生装置６００は前述の方法の実施形態で説明された方法を実行する。任意で、メモリはデータをさらに記憶してもよい。任意で、プロセッサが命令及び／又はデータを記憶してもよい。例えば、１つ以上のメモリ６０２は、前述の実施形態で説明したチャネル情報リストを記憶してもよい。プロセッサとメモリは別個に配置されてもよく、あるいは一緒に統合されてもよい。

【0095】

さらに別の可能な設計において、プログラム再生装置６００は、トランシーバユニット６０５とアンテナ６０６をさらに含んでもよい。プロセッサ６０１は、処理ユニットと呼ばれることもあり、プログラム再生装置を制御する。トランシーバユニット６０５は、トランシーバ、トランシーバ回路などと呼ばれることもあり、アンテナ６０６を使用することによりプログラム再生装置のトランシーバ機能を実施するように構成される。

【0096】

可能な一実装において、図７に示すプログラム再生装置７００が、前述の方法の実施形態における通信デバイスとして使用され、前述の方法の実施形態における通信デバイスにより実行されるステップを実行してもよい。図７に示すように、プログラム再生装置７００は処理ユニット７０１と通信ユニット７０２を含んでもよく、処理ユニット７０１と通信ユニット７０２は相互に結合される。処理ユニット７０１は、前述の方法の実施形態における処理動作を実行する際にプログラム再生装置７００をサポートするように構成され得る。

【0097】

前述の方法の実施形態におけるプログラム再生装置により実行されるアクションが実行されるとき、通信ユニット７０２は、第１の伝送プロトコルを使用することにより送信されたプログラム再生要求メッセージを受信するように構成されてもよく、あるいは、第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにデータストリーム要求メッセージを送信するように構成されてもよく、あるいは、第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにより送信されたデータストリームを受信し、第１の伝送プロトコルを使用することにより、データストリームを再生のために再生デバイスに送信するように構成されてもよい。第１の伝送プロトコル及び第２の伝送プロトコルについては、前述の方法の実施形態における関連する説明を参照する。

【0098】

処理ユニット７０１は、メディアファイル識別子に基づいて対応するターゲットプログラムチャネルを決定するように構成されてもよい。

【0099】

一設計において、通信ユニット７０２は、さらに、第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにより送信されたチャネル情報リストを受信するように構成されてもよい。チャネル情報リストについては、前述の方法の実施形態における関連する説明を参照する。

【0100】

処理ユニット７０１は、さらに、チャネル情報リスト内の各プログラムチャネルの識別子のためのメディアファイル識別子を追加し、各プログラムチャネルの識別子とメディアファイル識別子との間の対応表を記憶するように構成されてもよい。チャネル情報リストについては、前述の方法の実施形態における関連する説明を参照する。

【0101】

一設計において、通信ユニット７０２は、さらに、第１の伝送プロトコルを使用することにより送信されたプログラムクローズ命令メッセージを受信するように構成されてもよく、あるいは、第２の伝送プロトコルを使用することによりＩＰＴＶプラットフォームにプログラムクローズ要求メッセージを送信するように構成されてもよい。プログラムクローズ命令メッセージ及びプログラムクローズ要求メッセージについては、前述の方法の実施形態における関連する説明を参照する。

【0102】

処理ユニット７０１は、さらに、メディアファイル識別子に基づいて対応するターゲットプログラムチャネルを決定するように構成されてもよい。

【0103】

図７のユニットの１つ以上が、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組み合わせにより実装されてもよい。ソフトウェア又はファームウェアは、これらに限られないがコンピュータプログラム命令又はコードを含み、ハードウェアプロセッサにより実行されてもよい。ハードウェアは、これらに限られないが、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は特定用途向け集積回路（ＡＳＩＣ）などの様々な集積回路を含む。

【0104】

本出願の実施形態におけるプロセッサは集積回路チップでもよく、信号処理能力を有することに留意されたい。一実装プロセスにおいて、前述の方法の実施形態におけるステップは、プロセッサ内のハードウェア統合論理回路又はソフトウェアの形態の命令を使用することにより完了されてもよい。前述のプロセッサは、汎用プロセッサ、デジタル信号プロセッサ（digital signal processor、ＤＳＰ）、特定用途向け集積回路（application-specific integrated circuit、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（field programmable gate array、ＦＰＧＡ）若しくは別のプログラマブル論理デバイス、個別ゲート若しくはトランジスタ論理デバイス、又は個別ハードウェアコンポーネントでもよい。本出願の実施形態で開示される方法、ステップ、及び論理ブロック図は、実施又は実行され得る。汎用プロセッサはマイクロプロセッサでもよく、あるいは、プロセッサは任意の従来のプロセッサなどでもよい。本出願の実施形態を参照して開示された方法のステップは、ハードウェアデコードプロセッサにより直接実行され、完了されてもよく、あるいはデコードプロセッサのハードウェアとソフトウェアモジュールとの組み合わせを使用することにより実行され、完了されてもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、読取専用メモリ、プログラマブル読取専用メモリ、電気的消去可能プログラマブルメモリ、又はレジスタなどの、当該分野において成熟した記憶媒体に配置されてもよい。記憶媒体はメモリ内に配置され、プロセッサはメモリ内の情報を読み取り、プロセッサのハードウェアと組み合わせて前述の方法におけるステップを完了する。

【0105】

本出願の実施形態において、メモリは揮発性メモリ又は不揮発性メモリでもよく、あるいは揮発性メモリと不揮発性メモリの双方を含んでもよいことが理解され得る。不揮発性メモリは、読取専用メモリ（read-only memory、ＲＯＭ）、プログラマブル読取専用メモリ（programmable ROM、ＰＲＯＭ）、消去可能プログラマブル読取専用メモリ（erasable PROM、ＥＰＲＯＭ）、電気的消去可能プログラマブル読取専用メモリ（electrically EPROM、ＥＥＰＲＯＭ）、又はフラッシュメモリでもよい。揮発性メモリは、外部キャッシュとして使用されるランダムアクセスメモリ（random access memory、ＲＡＭ）でもよい。限定的でなく例示的な説明により、多くの形式のＲＡＭが使用されてもよく、例えば、スタティックランダムアクセスメモリ（static RAM、ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（dynamic RAM、ＤＲＡＭ）、同期ダイナミックランダムアクセスメモリ（synchronous DRAM、ＳＤＲＡＭ）、ダブルデータレート同期ダイナミックランダムアクセスメモリ（double data rate SDRAM、ＤＤＲ ＳＤＲＡＭ）、拡張同期ダイナミックランダムアクセスメモリ（enhanced SDRAM、ＥＳＤＲＡＭ）、シンクリンクダイナミックランダムアクセスメモリ（synchlink DRAM、ＳＬＤＲＡＭ）、及びダイレクトランバスランダムアクセスメモリ（direct rambus RAM、ＤＲ ＲＡＭ）である。システム内のメモリ及び本明細書に記載される方法は、これらのメモリ及び別の適切なタイプの任意のメモリを含むことを目的としているが、それに限定されないことに留意されたい。

【0106】

本出願の一実施形態は、コンピュータ読取可能媒体をさらに提供する。コンピュータ読取可能媒体はコンピュータプログラムを記憶し、コンピュータプログラムがコンピュータにより実行されると、前述の方法の実施形態のいずれか１つにおけるプログラム再生方法が実施される。

【0107】

本出願の一実施形態は、コンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータにより実行されると、前述の方法の実施形態のいずれか１つにおけるプログラム再生方法が実施される。

【0108】

前述の実施形態の全部又は一部は、ソフトウェア、ハードウェア、ファームウェア、又はこれらの任意の組み合わせを使用することにより実施することができる。実施形態を実施するためにソフトウェアが使用されるとき、実施形態の全部又は一部がコンピュータプログラム製品の形態で実施されてもよい。コンピュータプログラム製品は、１つ以上のコンピュータ命令を含む。コンピュータ命令がコンピュータにロードされ、実行されると、本出願の実施形態に従った手順又は機能が完全に又は部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、又は別のプログラマブル装置でもよい。コンピュータ命令は、コンピュータ読取可能記憶媒体に記憶されてもよく、あるいはコンピュータ読取可能記憶媒体から別のコンピュータ読取可能記憶媒体に送信されてもよい。例えば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバ、又はデータセンターから別のウェブサイト、コンピュータ、サーバ、又はデータセンターに、有線（例えば、同軸ケーブル、光ファイバ、又はデジタル加入者線（digital subscriber line、ＤＳＬ））又は無線（例えば、赤外線、ラジオ、マイクロ波）方式で送信されてもよい。コンピュータ読取可能記憶媒体は、コンピュータによりアクセス可能な任意の使用可能な媒体、又は、１つ以上の使用可能な媒体を統合したサーバ又はデータセンターなどのデータストレージデバイスでもよい。使用可能な媒体は、磁気媒体（例えば、フロッピーディスク、ハードディスク、又は磁気テープ）、光媒体（例えば、高密度デジタルビデオディスク（digital video disc、ＤＶＤ））、半導体媒体（例えば、ソリッドステートディスク（solid state disk、ＳＳＤ））等でもよい。

【0109】

本出願の一実施形態は、プロセッサとインターフェースとを含むプログラム再生装置をさらに提供する。プロセッサは、前述の方法の実施形態のいずれか１つにおけるプログラム再生方法を実行するように構成される。

【0110】

プログラム再生装置はチップでもよいことを理解されたい。プロセッサは、ハードウェアにより実現されてもよく、あるいはソフトウェアにより実現されてもよい。プロセッサがハードウェアにより実現されるとき、プロセッサは論理回路、集積回路などでもよい。プロセッサがソフトウェアにより実現されるとき、プロセッサは汎用プロセッサでもよい。汎用プロセッサは、メモリに記憶されたソフトウェアコードを読み込むことにより実施される。メモリは、プロセッサに統合されてもよく、あるいはプロセッサの外部に配置され、独立して存在してもよい。

【0111】

さらに、本出願の実施形態における機能ユニットは１つの処理ユニットに統合されてもよく、ユニットの各々が物理的に単独で存在してもよく、あるいは２つ以上のユニットが１つのユニットに統合されてもよい。統合されたユニットは、ハードウェアの形態で実現されてもよく、あるいはソフトウェア機能ユニットの形態で実現されてもよい。

【0112】

前述の説明は本出願の特定の実装にすぎず、本出願の保護範囲を制限することを意図するものではない。本出願で開示される技術的範囲内で当業者により容易に把握されるバリエーション又は置き換えは、本出願の保護範囲に含まれるものとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】