Content state in media network environment
Abstract
[Subject] The method and equipment for managing a device and contents in network environment are offered. [Solution means] In 1 enforcement form, a network media system, The 1st hub network containing the 1st server and 1st client that were connected mutually, Have the 2nd hub network that overlaps with the 1st hub network including the 2nd server and 2nd client that were connected mutually, and the 1st client, While saving the 1st contents restrained by the 1st hub network, the 2nd contents restrained by the 2nd hub network are saved. [Selection figure] Fig. 17
Term
Projected expiry 22 December 2029.
- Priority
- Filed
- Published
- Today
- Projected expiry
220 claims: 39 independent, 181 dependent
- 1A first hub network that includes a first server and a first client connected to each other, and a second hub network that includes a second server and a second client connected to each other and overlaps the first hub network. A network including a hub network, wherein the first client stores the first content constrained by the first hub network and stores the second content constrained by the second hub network. Media system. 互いに接続された第1のサーバ及び第1のクライアントを含む第1のハブネットワークと、 互いに接続された第2のサーバ及び第2のクライアントを含み、上記第1のハブネットワークに重複する第2のハブネットワークとを備え、 上記第1のクライアントは、上記第1のハブネットワークに拘束された第1のコンテンツを保存するとともに、上記第2のハブネットワークに拘束された第2のコンテンツを保存するネットワークメディアシステム。
- 14The first client is connected to a terminal device for playing content, and the terminal device is neither a member of the first hub network nor a member of the second hub network. 1 The network media system described. 上記第1のクライアントは、コンテンツを再生する端末装置に接続され、 上記端末装置は、上記第1のハブネットワークのメンバではなく、上記第2のハブネットワークのメンバでもないことを特徴とする請求項1記載のネットワークメディアシステム。
- 15A first hub network that includes a first server, a first client connected to the first server, a second server connected to the first client, and the first client. A second hub network that overlaps with the first hub network, the first server stores content as a first source version of locked content data, and the first server Stores the first root license bound to the first hub network of the first source version, and the second server stores the content as the second source version of the locked content data. However, the second server stores the second root license bound to the second hub network of the second source version, and the first client is streamed by the first server. The first source version receives the first content, and the first client receives the second content via the second source version streamed by the second server. A network media system that features that. 第1のサーバと、該第1のサーバに接続された第1のクライアントとを含む第1のハブネットワークと、 上記第1のクライアントに接続された第2のサーバと、該第1のクライアントとを含み、上記第1のハブネットワークに重複する第2のハブネットワークとを備え、 上記第1のサーバは、ロックされたコンテンツデータの第1のソースバージョンとしてコンテンツを保存し、 上記第1のサーバは、上記第1のソースバージョンの上記第1のハブネットワークに拘束された第1のルートライセンスを保存し、 上記第2のサーバは、ロックされたコンテンツデータの第2のソースバージョンとしてコンテンツを保存し、 上記第2のサーバは、上記第2のソースバージョンの上記第2のハブネットワークに拘束された第2のルートライセンスを保存し、 上記第1のクライアントは、上記第1のサーバによってストリーミングされた上記第1のソースバージョンで上記第1のコンテンツを受信し、 上記第1のクライアントは、上記第2のサーバによってストリーミングされた上記第2のソースバージョンを介して上記第2のコンテンツを受信することを特徴とするネットワークメディアシステム。
- 16A second hub that includes a first hub network that includes a first server, a second server that is connected to the first server, and the first server, and that overlaps the first hub network. With a network, the first server stores the first version of the first licensed and locked content data, the first version stores the first content, and the first version. The server stores a second license and a second version of the locked content data, the second version stores the second content, and the first license is the first hub network. A network media system that is bound by and the second license is bound by the second hub network. 第1のサーバを含む第1のハブネットワークと、 上記第1のサーバに接続された第2のサーバと、該第1のサーバとを含み、上記第1のハブネットワークに重複する第2のハブネットワークとを備え、 上記第1のサーバは、第1のライセンス及びロックされたコンテンツデータの第1のバージョンを保存し、該第1のバージョンは、第1のコンテンツを保存し、 上記第1のサーバは、第2のライセンス及びロックされたコンテンツデータの第2のバージョンを保存し、該第2のバージョンは、第2のコンテンツを保存し、 上記第1のライセンスは、上記第1のハブネットワークに拘束され、上記第2のライセンスは、上記第2のハブネットワークに拘束されていることを特徴とするネットワークメディアシステム。
- 18A server that stores the root license and the source version of the locked content data, a first license connected to the above server, a first subcopy version of the locked content data, a second license, and a lock. It features a second subcopy version of the locked content data and a client to store, the source version of the locked content data stores the first content, and the root license is bound to the hub network. The first subcopy version stores the first content, the first license is bound by the hub network, the second subcopy version stores the second content, and the above. The second license is a hub network characterized by being bound by another hub network. ルートライセンス及びロックされたコンテンツデータのソースバージョンを保存するサーバと、 上記サーバに接続され、第1のライセンスと、ロックされたコンテンツデータの第1のサブコピーバージョンと、第2のライセンスと、ロックされたコンテンツデータの第2のサブコピーバージョンとを保存するクライアントとを備え、 上記ロックされたコンテンツデータのソースバージョンは、第1のコンテンツを保存し、 上記ルートライセンスは、ハブネットワークに拘束され、 上記第1のサブコピーバージョンは、上記第1のコンテンツを保存し、 上記第1のライセンスは、上記ハブネットワークに拘束され、 上記第2のサブコピーバージョンは、第2のコンテンツを保存し、 上記第2のライセンスは、他のハブネットワークに拘束されていることを特徴とするハブネットワーク。
- 21Claim 18 is characterized in that the client is an adaptive device, and an adaptive device that is a member of a hub network does not play constrained content that is not constrained to that hub network. Described hub network. 上記クライアントは、適応性を有するデバイスであり、 あるハブネットワークのメンバである適応性を有するデバイスは、そのハブネットワークに拘束されていない、拘束されたコンテンツを再生しないことを特徴とする請求項18記載のハブネットワーク。
- 22In the client addition method of adding a client as a member of the hub network, the step of detecting the client connected to the server of the above hub network, the step of authenticating the above client, the step of granting the authority to the above client, and the above client are added. A method of adding a client having a step of adding as a member of the hub network. ハブネットワークのメンバとしてクライアントを加えるクライアント追加方法において、 上記ハブネットワークのサーバに接続されたクライアントを検出するステップと、 上記クライアントを認証するステップと、 上記クライアントに権限を付与するステップと、 上記クライアントを上記ハブネットワークのメンバとして加えるステップとを有するクライアント追加方法。
- 3330. The step of sending the local environment confirmation request includes a step of issuing an IP packet to the client and confirming that the packet arrives correctly and a reply is made (pinging). How to add a client. 上記ローカル環境確認要求を送信するステップは、上記クライアントにIPパケットを発行し、そのパケットが正しく届いて返答が行われるかを確認する(pinging)ステップを含むことを特徴とする請求項30記載のクライアント追加方法。
- 39In the method of adding a client that adds a client as a member of the hub network, a step of sending a connection notification from the client to the server of the hub network, a step of sending identification information from the client to the server, and a step of sending the identification information from the client to the server of the above client. A client addition method comprising the step of receiving an additional confirmation from, wherein the additional confirmation indicates that the client has been added as a member of the hub network. ハブネットワークのメンバとしてクライアントを加えるクライアント追加方法において、 上記クライアントから上記ハブネットワークのサーバに接続通知を送信するステップと、 上記クライアントから上記サーバに識別情報を送信するステップと、 上記クライアントにおいて、上記サーバからの追加確認を受信するステップとを有し、 上記追加確認は、上記クライアントが上記ハブネットワークのメンバとして加えられたことを示すことを特徴とするクライアント追加方法。
- 47In the client addition method of adding a client as a member of the hub network, a step of authenticating the client via the intermediate device connected to the server of the hub network and a step of granting the authority to the client via the intermediate device. A method of adding a client, which comprises a step of adding the client as a member to the hub network via the intermediate device, and the client is not connected to the server. ハブネットワークのメンバとしてクライアントを加えるクライアント追加方法において、 上記ハブネットワークのサーバに接続された中間装置を介してクライアントを認証するステップと、 上記中間装置を介して、上記クライアントに権限を付与するステップと、 上記中間装置を介して、上記クライアントをメンバとして上記ハブネットワークに加えるステップとを有し、 上記クライアントは、上記サーバに接続されていないことを特徴とするクライアント追加方法。
- 50In the client addition method of adding a client as a member of the hub network, the step of transmitting a connection notification from the client to the server of the hub network via an intermediate device connected to the server, and the step of transmitting the connection notification from the client to the server, the above. The client has a step of transmitting identification information via an intermediate device and a step of receiving an additional confirmation from the server via the intermediate device in the client. In the additional confirmation, the client of the hub network A method of adding a client, characterized by indicating that it has been added as a member. ハブネットワークのメンバとしてクライアントを加えるクライアント追加方法において、 上記クライアントから上記ハブネットワークのサーバに、該サーバに接続された中間装置を介して接続通知を送信するステップと、 上記クライアントから上記サーバに、上記中間装置を介して識別情報を送信するステップと、 上記クライアントにおいて、上記中間装置を介して、上記サーバから追加確認を受信するステップとを有し、 上記追加確認は、上記クライアントが上記ハブネットワークのメンバとして加えられたことを示すことを特徴とするクライアント追加方法。
- 53In the client deletion method of deleting a client from a member of the hub network, the step of triggering the deletion of the client from the member of the hub network and the content data constrained to the hub network stored in the client are supported. A client deletion method comprising disabling all licenses to be granted and removing the client from a member of the hub network so that the client is no longer a member of the hub network. ハブネットワークのメンバからクライアントを削除するクライアント削除方法において、 上記ハブネットワークのメンバからの上記クライアントの削除をトリガするステップと、 上記クライアントに保存されている、上記ハブネットワークに拘束されたコンテンツデータに対応する全てのライセンスをディスエーブルにするステップと、 上記クライアントが上記ハブネットワークのメンバではなくなるように、該ハブネットワークのメンバから該クライアントを削除するステップとを有するクライアント削除方法。
- 67In the client reconnection method of reconnecting a client to the hub network, there are a step of detecting a client connected to the hub network, a step of authenticating the client as a member of the hub network, and a step of granting authority to the client. Client reconnection method with. クライアントをハブネットワークに再接続するクライアント再接続方法において、 ハブネットワークに接続されたクライアントを検出するステップと、 上記ハブネットワークのメンバとして上記クライアントを認証するステップと、 上記クライアントに権限を付与するステップとを有するクライアント再接続方法。
- 70Claim 67, wherein the step of authenticating the client includes sending a local environment confirmation request to the client, and the local environment is a limited area defined in relation to the server. Described client reconnection method. 上記クライアントを認証するステップは、該クライアントにローカル環境確認要求を送信するステップを含み、 上記ローカル環境は、上記サーバに関連して定義された限定的な領域であることを特徴とする請求項67記載のクライアント再接続方法。
- 72In the client disconnection method of disconnecting the client from the hub network, the step of disconnecting the client from the hub network, the step of setting the expiration date of the license stored in the client, and the expiration date and the clock of the client are compared. A method of disconnecting a client, characterized in that the license corresponds to the locked content data stored in the client and is bound to the hub network. ハブネットワークからクライアントを切断するクライアント切断方法において、 上記ハブネットワークから上記クライアントを切断するステップと、 上記クライアントに保存されたライセンスの期限を設定するステップと、 上記期限と上記クライアントのクロックとを比較するステップとを有し、 上記ライセンスは、上記クライアントに保存されているロックされたコンテンツデータに対応し、上記ハブネットワークに拘束されていることを特徴とするクライアント切断方法。
- 80In the content binding method of binding hub network content, the step of receiving a request to bind an independent version of content containing independent locked content data to a hub network containing servers and clients as members, and the above independent version. A step to disable, a step to create a source version of the above content stored on the above server, including source-locked content data, and a route stored on the above server, constrained by the above hub network. A content binding method that has steps to create a license. ハブネットワークコンテンツを拘束するコンテンツ拘束方法において、 独立したロックされたコンテンツデータを含むコンテンツの独立したバージョンを、サーバ及びクライアントをメンバとして含むハブネットワークに拘束する要求を受信するステップと、 上記独立したバージョンをディスエーブルにするステップと、 上記サーバに保存されている上記コンテンツの、ソースロックされたコンテンツデータを含むソースバージョンを作成するステップと、 上記ハブネットワークに拘束された、上記サーバに保存されるルートライセンスを作成するステップとを有するコンテンツ拘束方法。
- 100Releasing content bound to a hub network In a content release method that includes content data stored on a server and source-locked from a hub network that includes servers and clients as members, the corresponding content is constrained to the hub network. The step of receiving a request to release the source version of the content with the root license, the step of disabling the source version, and the step of creating an independent version of the content containing independent locked content data. Content release method to have. ハブネットワークに拘束されたコンテンツを解放するコンテンツ解放方法において、 サーバ及びクライアントをメンバとして含むハブネットワークから、該サーバに保存され、ソースロックされたコンテンツデータを含み、該ハブネットワークに拘束された対応するルートライセンスを有するコンテンツのソースバージョンを解放する要求を受信するステップと、 上記ソースバージョンをディスエーブルにするステップと、 独立したロックされたコンテンツデータを含む上記コンテンツの独立したバージョンを作成するステップとを有するコンテンツ解放方法。
- 102100. Claim 100, further comprising disabling a sub-copy version of the content stored on the client, wherein the sub-copy version includes a copy of the source-locked content data. Content release method. 上記クライアントに保存された上記コンテンツのサブコピーバージョンをディスエーブルにするステップを更に有し、 上記サブコピーバージョンは、上記ソースロックされたコンテンツデータのコピーを含むことを特徴とする請求項100記載のコンテンツ解放方法。
- 118Hub network content binding In a content binding method, a request to bind an independent instance containing independent locked content data, independent licenses, and independent licensing authority data to a hub network that includes servers and clients as members. Create a constrained instance containing the receiving step, disabling the independent instance, source-locked content data, the hub network-bound root license, and the bound licensing authority data. Content constraint method with steps. ハブネットワークコンテンツを拘束するコンテンツ拘束方法において、 独立したロックされたコンテンツデータ、独立したライセンス及び独立したライセンス付与機関データを含む独立したインスタンスを、サーバ及びクライアントをメンバとして含むハブネットワークに拘束する要求を受信するステップと、 上記独立したインスタンスをディスエーブルにするステップと、 ソースロックされたコンテンツデータ、上記ハブネットワークに拘束されたルートライセンス及び拘束されたライセンス付与機関データを含む拘束されたインスタンスを作成するステップとを有するコンテンツ拘束方法。
- 119In the content release method that releases the content bound to the hub network, the source-locked content data, the root license bound to the above hub network, and the bound licensing authority data from the hub network including the server and the client as members. Independent including independent locked content data, independent license and independent licensing authority data, the step of receiving a request to release the restrained instance including, and the step of disabling the restrained instance. Content release method including steps to create an instance. ハブネットワークに拘束されたコンテンツを解放するコンテンツ解放方法において、 サーバ及びクライアントをメンバとして含むハブネットワークから、ソースロックされたコンテンツデータ、上記ハブネットワークに拘束されたルートライセンス及び拘束されたライセンス付与機関データを含む拘束されたインスタンスを解放する要求を受信するステップと、 上記拘束されたインスタンスをディスエーブルにするステップと、 独立したロックされたコンテンツデータ、独立したライセンス及び独立したライセンス付与機関データを含む独立したインスタンスを作成するステップとを含むコンテンツ解放方法。
- 120The independent instance, which comprises locked content data, a key for decrypting the locked content data, a license, and licensing authority data, is an adaptive electronic storage medium that is readable and writable. The locked content data is stored in a medium having sex, and the locked content data is encrypted using a content encryption method, and the key is encrypted using a hub network encryption method different from the content encryption method. An independent instance of the encrypted content. ロックされたコンテンツデータと、 上記ロックされたコンテンツデータを復号するための鍵と、 ライセンスと、 ライセンス付与機関データとを備え、 上記独立したインスタンスは、読出及び書込可能な電子ストレージ媒体である適応性を有する媒体に保存されており、 上記ロックされたコンテンツデータは、コンテンツ暗号化方式を用いて暗号化され、 上記鍵は、上記コンテンツ暗号化方式とは異なるハブネットワーク暗号化方式を用いて暗号化されているコンテンツの独立したインスタンス。
- 121120. The hub network encryption method is different from the content encryption method in that the content encryption method uses a key different from the key used to encrypt the data. An independent instance of. 上記ハブネットワーク暗号化方式は、上記コンテンツ暗号化方式がデータを暗号化するために用いる鍵とは異なる鍵を用いるという点で、該コンテンツ暗号化方式とは異なることを特徴とする請求項120記載の独立したインスタンス。
- 128An adaptive medium that at least stores an independent set of data including locked content data, a key for decrypting the locked content data, a license, and licensing authority data. The locked content data is encrypted using a content encryption method, the key is encrypted using a hub network encryption method different from the content encryption method, and the medium having the adaptability is A readable and writable storage medium, at least a portion of the independent set of data is encrypted using adaptive encryption technology, and the adaptive device is the independent of the encrypted data. An adaptive medium that stores an adaptive key for decrypting at least a portion of a set. ロックされたコンテンツデータと、 上記ロックされたコンテンツデータを復号するための鍵と、 ライセンスと、 ライセンス付与機関データとを含むデータの独立した組を少なくとも保存する適応性を有する媒体であって、 上記ロックされたコンテンツデータは、コンテンツ暗号化方式を用いて暗号化され、 上記鍵は、上記コンテンツ暗号化方式とは異なるハブネットワーク暗号化方式を用いて暗号化され、 当該適応性を有する媒体は、読出及び書込可能なストレージ媒体であり、 上記データの独立した組の少なくとも一部は、適応性暗号化技術を用いて暗号化され、適応性を有するデバイスが上記暗号化されたデータの独立した組の少なくとも一部を復号するための適応性鍵を保存する適応性を有する媒体。
- 129Source-locked content data stored on a server that is a member of the hub network, a source key stored on the server and for decrypting the source-locked content data, and a root license stored on the server. And the licensing authority data stored in the server, the root license is bound to the hub network, the locked content data is encrypted using the content encryption method, and the source The key is a bound instance of content that is encrypted using a hub network encryption method that is different from the content encryption method described above. ハブネットワークのメンバであるサーバに保存されているソースロックされたコンテンツデータと、 上記サーバに保存され、上記ソースロックされたコンテンツデータを復号するためのソース鍵と、 上記サーバに保存されたルートライセンスと、 上記サーバに保存されたライセンス付与機関データとを有し、 上記ルートライセンスは、上記ハブネットワークに拘束され、 上記ロックされたコンテンツデータは、コンテンツ暗号化方式を用いて暗号化され、 上記ソース鍵は、上記コンテンツ暗号化方式とは異なるハブネットワーク暗号化方式を用いて暗号化されているコンテンツの拘束されたインスタンス。
- 130129. Claim 129, wherein the hub network encryption method is different from the content encryption method in that the content encryption method uses a key different from the key used for encrypting data. Contained instance of. 上記ハブネットワーク暗号化方式は、上記コンテンツ暗号化方式がデータを暗号化するために用いる鍵とは異なる鍵を用いるという点で、該コンテンツ暗号化方式とは異なることを特徴とする請求項129記載の拘束されたインスタンス。
- 133129. Claim 129, wherein the root license indicates that, when the bound instance is disabled, the bound instance is allowed to be released from the hub network. A restrained instance. 上記ルートライセンスは、上記拘束されたインスタンスがディスエーブルにされている場合、該拘束されたインスタンスを上記ハブネットワークから解放することが許可されていることを示すことを特徴とする請求項129記載の拘束されたインスタンス。
- 150In the content data playback method for playing content data, the hub network client confirms the step of receiving a playback request specifying the locked content data and the license corresponding to the locked content data, and the client confirms the license corresponding to the locked content data. The step of determining whether or not the license permits the reproduction of the locked content data, and the step of reproducing the locked content data via the reproduction component connected to the client. A content data reproduction method that is possessed and the license of the locked content data is bound to the hub network. コンテンツデータを再生するコンテンツデータ再生方法において、 ハブネットワークのクライアントにおいて、ロックされたコンテンツデータを指定する再生要求を受信するステップと、 上記ロックされたコンテンツデータに対応するライセンスを確認し、上記クライアントが該ロックされたコンテンツデータを再生することを上記ライセンスが許可しているか否かを判定するステップと、 上記クライアントに接続された再生コンポーネントを介して、上記ロックされたコンテンツデータを再生するステップとを有し、 上記ロックされたコンテンツデータのライセンスは、上記ハブネットワークに拘束されていることを特徴とするコンテンツデータ再生方法。
- 152The claim is characterized in that the step of reproducing the locked content data includes a step of decoding the locked content data, generating output content data, and supplying the output content data to the reproduction component. 151 Content data playback method described. 上記ロックされたコンテンツデータを再生するステップは、該ロックされたコンテンツデータを復号し、出力コンテンツデータを生成し、該出力コンテンツデータを上記再生コンポーネントに供給するステップを含むことを特徴とする請求項151記載のコンテンツデータ再生方法。
- 163In the content data reproduction method for reproducing the content data, the step of receiving the locked content data and the reproduction request specifying the client in the hub network on the server of the hub network, and the above-mentioned corresponding to the locked content data. By checking the license and determining whether the license allows the server to play the locked content data through the client, and by streaming the data to the client. A content data reproduction method comprising the step of reproducing the locked content data, wherein the license of the locked content data is bound to the hub network. コンテンツデータを再生するコンテンツデータ再生方法において、 ハブネットワークのサーバにおいて、ロックされたコンテンツデータ及び該ハブネットワーク内のクライアントを指定する再生要求を受信するステップと、 上記ロックされたコンテンツデータに対応する上記ライセンスを確認し、上記サーバが、上記クライアントを介して、上記ロックされたコンテンツデータを再生することを該ライセンスが許可しているか否かを判定するステップと、 上記クライアントにデータをストリーミングすることによって、上記ロックされたコンテンツデータを再生するステップとを有し、 上記ロックされたコンテンツデータのライセンスは、上記ハブネットワークに拘束されていることを特徴とするコンテンツデータ再生方法。
- 168In the content data copy method of copying the content data, in the hub network, the step of receiving the copy request specifying the locked content data and the above-mentioned locked content data are copied and the locked content data is copied. A content data copying method comprising a step of generating, wherein the locked content data has a corresponding license bound to the hub network. コンテンツデータをコピーするコンテンツデータコピー方法において、 ハブネットワークにおいて、ロックされたコンテンツデータを指定するコピー要求を受信するステップと、 上記ロックされたコンテンツデータをコピーし、該ロックされたコンテンツデータのコピーを生成するステップとを有し、 上記ロックされたコンテンツデータは、上記ハブネットワークに拘束された対応するライセンスを有することを特徴とするコンテンツデータコピー方法。
- 175In the content data distribution method for distributing content data, the receiving device receives a copy of the locked content data from the hub network providing device, and a step of requesting a new license for the locked content data copy. And a content data distribution method having the above-mentioned step of receiving a new license. コンテンツデータを配信するコンテンツデータ配信方法において、 受信装置において、ハブネットワークの提供装置からロックされたコンテンツデータのコピーを受信するステップと、 上記ロックされたコンテンツデータのコピーの新たなライセンスを要求するステップと、 上記新たなライセンスを受信するステップとを有するコンテンツデータ配信方法。
- 183175. The receiver is a member of a second hub network, and the new license for copying the locked content data is bound to the second hub network, claim 175. Content data distribution method. 上記受信装置は、第2のハブネットワークのメンバであり、 上記ロックされたコンテンツデータのコピーの新たなライセンスは、該第2のハブネットワークに拘束されていることを特徴とする請求項175記載のコンテンツデータ配信方法。
- 186In the content data distribution method of distributing content data, the step of receiving a request for a new license for copying the locked content data from the device on the server of the hub network and the route stored in the above server. Based on the steps of checking the license and determining whether the root license allows the server to provide a new license for the copy of the locked content data, and based on the new root license. A content data distribution method having a step of creating a new license and a step of transmitting the new license to the device. コンテンツデータを配信するコンテンツデータ配信方法において、 ハブネットワークのサーバにおいて、デバイスからロックされたコンテンツデータのコピーのための新たなライセンスのための要求を受信するステップと、 上記サーバに保存されているルートライセンスを確認し、該サーバが上記ロックされたコンテンツデータのコピーの新たなライセンスを提供することを該ルートライセンスが許可しているか否かを判定するステップと、 上記ルートライセンスに基づいて、上記新たなライセンスを作成するステップと、 上記新たなライセンスを上記デバイスに送信するステップとを有するコンテンツデータ配信方法。
- 190Acquiring a license in a hub network In a license acquisition method, a step of sending a license request from a client to a server, a step of sending a connection confirmation from the client to the server, and a step of receiving license data from the server in the client. The client and the server are connected in a hub network, the license request identifies the subcopy version stored in the client, and the subcopy version contains subcopy-locked content data. A license acquisition method including, wherein the license data is bound to the hub network. ハブネットワークにおいてライセンスを取得するライセンス取得方法において、 クライアントからサーバにライセンス要求を送信するステップと、 上記クライアントから上記サーバに接続確認を送信するステップと、 上記クライアントにおいて、上記サーバからライセンスデータ受信するステップとを有し、 上記クライアントと上記サーバは、ハブネットワークにおいて接続され、 上記ライセンス要求は、上記クライアントに保存されたサブコピーバージョンを特定し、 上記サブコピーバージョンは、サブコピーロックされたコンテンツデータを含み、 上記ライセンスデータは、上記ハブネットワークに拘束されていることを特徴とするライセンス取得方法。
- 204In the licensing method of granting a license to a client in a hub network, the server receives a license request from the client, a step of sending a connection confirmation request from the server to the client, and a license from the server to the client. It has a step of transmitting data, the client and the server are connected in a hub network, the license request identifies a subcopy version stored in the client, and the license data is sent to the hub network. A licensing method characterized by being tied up. ライセンスをハブネットワーク内のクライアントに付与するライセンス付与方法において、 サーバにおいて、クライアントからライセンス要求を受信するステップと、 上記サーバから上記クライアントに接続確認要求を送信するステップと、 上記サーバから上記クライアントにライセンスデータを送信するステップとを有し、 上記クライアントと上記サーバは、ハブネットワークにおいて接続され、 上記ライセンス要求は、上記クライアントに保存されたサブコピーバージョンを特定し、 上記ライセンスデータは、上記ハブネットワークに拘束されていることを特徴とするライセンス付与方法。
- 217In the license acquisition method of acquiring a license in a hub network, a step of transmitting a license request from a client to a server via an intermediate device and a step of transmitting a connection confirmation from the client to the server via the intermediate device. The client has a step of receiving license data from the server via the intermediate device, the client and the server are not connected in the hub network, and the license request is stored in the client. A license acquisition method characterized in that a subcopy version is specified, the subcopy version includes subcopy locked content data, and the license data is bound to the hub network. ハブネットワークにおいてライセンスを取得するライセンス取得方法において、 中間装置を介して、クライアントからサーバにライセンス要求を送信するステップと、 上記中間装置を介して、上記クライアントから上記サーバに接続確認を送信するステップと、 上記クライアントにおいて、上記中間装置を介して、上記サーバからライセンスデータを受信するステップとを有し、 上記クライアントと上記サーバは、ハブネットワーク内では接続されず、上記ライセンス要求は、上記クライアントに保存されているサブコピーバージョンを特定し、 上記サブコピーバージョンは、サブコピーロックされたコンテンツデータを含み、 上記ライセンスデータは、上記ハブネットワークに拘束されていることを特徴とするライセンス取得方法。
- 218In the licensing method of providing a license to the hub network, a step of receiving a license request from a client of a server via an intermediate device and a step of transmitting a connection confirmation request from the server to the client via the intermediate device. And the step of transmitting license data from the server to the client via the intermediate device, the client and the server are not connected in the hub network, and the license request is stored in the client. A licensing method characterized in that a subcopy version is specified and the above license data is bound to the above hub network. ライセンスをハブネットワークに提供するライセンス付与方法において、 中間装置を介して、サーバのクライアントからライセンス要求を受信するステップと、 上記中間装置を介して、上記サーバから上記クライアントに接続確認要求を送信するステップと、 上記中間装置を介して、上記サーバから上記クライアントにライセンスデータを送信するステップとを有し、 上記クライアントと上記サーバは、ハブネットワーク内では接続されず、 上記ライセンス要求は、上記クライアントに保存されているサブコピーバージョンを特定し、 上記ライセンスデータは、上記ハブネットワークに拘束されていることを特徴とするライセンス付与方法。
- 219In the license renewal method for renewing a license in a hub network, a step of sending a renewal request from a client to a server, a step of sending a connection confirmation from the client to the server, and a license renewed from the server in the client. It has a step of transmitting data and a step of renewing a subcopy license based on the updated license data stored in the client, and the client and the server are connected in a hub network and described above. The update request identifies the subcopy version stored in the client, the subcopy version contains subcopy locked content data, the subcopy license corresponds to the subcopy version, and the sub A copy license is a license renewal method characterized by being bound by the above hub network. ハブネットワークにおいて、ライセンスを更新するライセンス更新方法において、 クライアントからサーバに更新要求を送信するステップと、 上記クライアントから上記サーバに接続確認を送信するステップと、 上記クライアントにおいて、上記サーバから更新されたライセンスデータを送信するステップと、 上記クライアントに保存されている上記更新されたライセンスデータに基づいて、サブコピーライセンスを更新するステップとを有し、 上記クライアントと上記サーバは、ハブネットワークにおいて接続され、 上記更新要求は、上記クライアントに保存されているサブコピーバージョンを特定し、 上記サブコピーバージョンは、サブコピーロックされたコンテンツデータを含み、 上記サブコピーライセンスは、上記サブコピーバージョンに対応し、 上記サブコピーライセンスは、上記ハブネットワークに拘束されていることを特徴とするライセンス更新方法。
- 220In the license renewal method for renewing a license in a hub network, a step of receiving a renewal request from a client on a server, a step of sending a connection confirmation request from the server to the client, and a step of renewing from the server to the client. It has a step of sending license data, the client and the server are connected in a hub network, the update request identifies the subcopy version stored in the client, and the updated license data , The subcopy license corresponding to the subcopy version is renewed, and the subcopy license is bound to the hub network. ハブネットワークにおいて、ライセンスを更新するライセンス更新方法において、 サーバにおいて、クライアントから更新要求を受信するステップと、 上記サーバから上記クライアントに接続確認要求を送信するステップと、 上記サーバから上記クライアントに更新されたライセンスデータを送信するステップとを有し、 上記クライアントと上記サーバは、ハブネットワークにおいて接続され、 上記更新要求は、上記クライアントに保存されているサブコピーバージョンを特定し、 上記更新されたライセンスデータは、上記サブコピーバージョンに対応するサブコピーライセンスを更新し、 上記サブコピーライセンスは、上記ハブネットワークに拘束されていることを特徴とするライセンス更新方法。
Independent claims39
188 paragraphs, as filed
The present invention is a network media system, a hub network, a method of adding, deleting, reconnecting and disconnecting a client, a method of binding and releasing content, a method of playing, copying and distributing content data, and a method of acquiring, granting and updating a license.
[Related application] This application claims priority over US Provisional Patent Application No. 60 / 434,774 filed on December 17, 2002 and US Provisional Patent Application No. 60 / 471,823 filed on May 20, 2003. These patent documents are incorporated herein by reference.
Audio and video media content such as music and movies are used in a variety of digital formats, including electronic files stored on, for example, optical recording media (eg, CDs and DVDs) or magnetic recording media (eg, hard disks). There are many things. Digital content has the advantages of high playback quality and easy user access. Another advantage of digital content is that you can easily make high-quality copies of your content. Users can access and enjoy digital content through various devices in multiple locations. On the other hand, content owners are constantly plagued by problems such as uncontrolled, unauthorized copying and pirated copies resulting from them.
<p> The present invention provides methods and devices for managing devices and content in a network environment. In one embodiment, the network media system includes a first hub network that includes a first server and a first client connected to each other, and a second server and a second client that are connected to each other. The first hub network has a second hub network that overlaps with the first hub network, and the first client stores the first content bound to the first hub network and is bound to the second hub network. Save the contents of 2.</p><p> The network media system according to the present invention includes a first hub network including a first server, a first client connected to the first server, and a second server connected to the first client. The first server stores the content as the first source version of the locked content data, including the first client and the second hub network that overlaps the first hub network. One server stores the first root license bound to the first hub network of the first source version, and the second server stores the content as the second source version of the locked content data. However, the second server stores the second root license tied to the second hub network of the second source version, and the first client is the first source streamed by the first server. The first content is received via the version, and the first client receives the second content via the second source version streamed by the second server.</p><p> The network media system according to the present invention includes a first hub network including a first server, a second server connected to the first server, and a first server, and is included in the first hub network. With a second hub network that overlaps, the first server stores the first version of the first licensed and locked content data, the first version stores the first content, The first server stores the second license and the second version of the locked content data, the second version stores the second content, and the first license is the first hub network. The second license is bound to the second hub network.</p><p> The hub network according to the present invention includes a server that stores the root license and the source version of the locked content data, a first license connected to the server, and a first subcopy version of the locked content data. It features a second license and a client that stores a second subcopy version of the locked content data, the source version of the locked content data stores the first content, and the root license is the hub. Network-bound, the first subcopy version stores the first content, the first license is bound to the hub network, the second subcopy version stores the second content, the second The license of 2 is bound by other hub networks.</p><p> The client addition method according to the present invention is a client addition method of adding a client as a member of a hub network, in which a step of detecting a client connected to a server of the hub network, a step of authenticating the client, and a step of granting authority to the client are granted. It has a step and a step of adding a client as a member of the hub network.</p><p> The method of adding a client according to the present invention is a method of adding a client as a member of a hub network, in which a step of sending a connection notification from the client to a server of the hub network, a step of sending identification information from the client to the server, and a client. In, it has a step of receiving additional confirmation from the server, and the additional confirmation indicates that the client has been added as a member of the hub network.</p><p> The client addition method according to the present invention is a client addition method in which a client is added as a member of a hub network, in which a step of authenticating a client via an intermediate device connected to a server of the hub network and a step of authenticating the client via an intermediate device are used. It has a step of granting privileges and a step of adding the client as a member to the hub network via an intermediate device, and the client is not connected to the server.</p><p> The method of adding a client according to the present invention is a method of adding a client as a member of a hub network, in which a client sends a connection notification to a server of the hub network via an intermediate device connected to the server, and the client adds a connection notification. It has a step of transmitting identification information to the server via the intermediate device and a step of receiving additional confirmation from the server via the intermediate device on the client, and the additional confirmation is added by the client as a member of the hub network. Indicates that it was done.</p><p> The client deletion method according to the present invention is a client deletion method for deleting a client from a member of a hub network, in which a step that triggers the deletion of the client from a member of the hub network and a hub network stored in the client are constrained. It has a step of disabling all licenses corresponding to the content data and a step of removing the client from the members of the hub network so that the client is no longer a member of the hub network.</p><p> The client reconnection method according to the present invention includes a step of detecting a client connected to the hub network, a step of authenticating the client as a member of the hub network, and a client in the client reconnection method of reconnecting the client to the hub network. Has a step of empowering the client.</p><p> The client disconnection method according to the present invention is the client disconnection method for disconnecting from the client from the hub network, the step of disconnecting from the client from the hub network, the step of setting the expiration date of the license stored in the client, the expiration date and the client clock. The license corresponds to the locked content data stored on the client and is tied to the hub network.</p><p> The content binding method according to the present invention is a content binding method for binding hub network content, which requests that an independent version of content including independent locked content data be bound to a hub network including a server and a client as members. A step to receive, a step to disable an independent version, a step to create a source version of the content stored on the server that contains source-locked content data, and a hub network-bound server. It has a step of creating a root license to be saved.</p><p> The content release method according to the present invention is a content release method for releasing content bound to a hub network, which includes content data stored in a server and source-locked from a hub network including a server and a client as members, and is a hub. A step to receive a request to release a source version of content with a corresponding network-bound root license, a step to disable the source version, and an independent version of the content containing independent locked content data. Has steps to create.</p><p> The content binding method according to the present invention is a content binding method for binding hub network content, in which an independent instance including independent locked content data, an independent license, and an independent licensing authority data is used as a member of a server and a client. Includes the step of receiving a request to bind to the hub network, the step of disabling an independent instance, the source-locked content data, the root license bound to the hub network, and the bound licensing authority data. It has a step to create a constrained instance.</p><p> The content release method according to the present invention is a content release method for releasing content bound to a hub network, from a hub network including a server and a client as members, source-locked content data, and a root license bound to the hub network. And the step of receiving a request to release the bound instance containing the bound licensing authority data, the step of disabling the bound instance, independent locked content data, independent license and independent Includes steps to create an independent instance containing licensing authority data.</p><p> An independent instance of the content according to the invention comprises locked content data, a key for decrypting the locked content data, a license, and licensing authority data, and the independent instance is read and written. Stored on an adaptive medium that is an embeddable electronic storage medium, locked content data is encrypted using a content encryption method, and the key is a hub network encryption that is different from the content encryption method. It is encrypted using the encryption method.</p><p> The adaptive medium according to the present invention stores at least an independent set of data including locked content data, a key for decrypting the locked content data, a license, and licensing authority data. Locked content data, which is an adaptive medium, is encrypted using a content encryption method, and the key is encrypted using a hub network encryption method different from the content encryption method, and is adapted. The sexual medium is a readable and writable storage medium, at least a portion of an independent set of data is encrypted using adaptive encryption technology, and the adaptive device is encrypted. Stores an adaptive key for decrypting at least a portion of an independent set of data.</p><p> The constrained instance of the content according to the present invention is a source-locked content data stored in a server that is a member of the hub network, and a source key for decrypting the source-locked content data stored in the server. The root license is bound to the hub network, and the locked content data is encrypted using the content encryption method. The source key is encrypted using a hub network encryption method different from the content encryption method.</p><p> The content data reproduction method according to the present invention corresponds to a step of receiving a reproduction request for designating locked content data and a locked content data in a hub network client in the content data reproduction method for reproducing the content data. Play the locked content data through the steps to check the license to play and determine if the license allows the client to play the locked content data and through the playback component connected to the client. The license for locked content data is bound to the hub network.</p><p> The content data reproduction method according to the present invention is the content data reproduction method for reproducing the content data, in which the server of the hub network receives the locked content data and the reproduction request specifying the client in the hub network, and the lock. The step of checking the license corresponding to the content data that has been made, determining whether the license allows the server to play the locked content data through the client, and streaming the data to the client. Thereby having a step of replaying the locked content data, the license of the locked content data is bound to the hub network.</p><p> The content data copy method according to the present invention is a content data copy method for copying content data, in which a step of receiving a copy request for specifying locked content data in a hub network and a step of copying the locked content data are performed. It has a step of generating a copy of the locked content data and the locked content data has a corresponding license bound to the hub network.</p><p> The content data distribution method according to the present invention is a content data distribution method for distributing content data, in which a receiving device receives a copy of the locked content data from a hub network providing device, and the locked content data. It has a step of requesting a new license for copying and a step of receiving a new license.</p><p> The content data distribution method according to the present invention is a content data distribution method for distributing content data, in which a server of a hub network receives a request for a new license for copying locked content data from a device. And the steps to check the root license stored on the server and determine if the root license allows the server to provide a new license for the locked copy of the content data, and in the root license Based on this, it has a step of creating a new license and a step of sending the new license to the device.</p><p> The license acquisition method according to the present invention is the step of transmitting a license request from the client to the server, the step of transmitting the connection confirmation from the client to the server, and the step of transmitting the connection confirmation from the server to the server in the license acquisition method for acquiring the license in the hub network. Having a step of receiving license data, the client and server are connected in the hub network, the license request identifies the subcopy version stored on the client, and the subcopy version is the subcopy locked content data. Including, license data is tied to the hub network.</p><p> The license granting method according to the present invention is a license granting method for granting a license to a client in a hub network, in which the server receives a license request from the client, and the server sends a connection confirmation request to the client. It has a step of sending license data from the server to the client, the client and server are connected in the hub network, the license request identifies the subcopy version stored in the client, and the license data is bound to the hub network. Has been done.</p><p> The license acquisition method according to the present invention is a license acquisition method for acquiring a license in a hub network, in which a step of transmitting a license request from a client to a server via an intermediate device and a connection from a client to a server via an intermediate device. It has a step of sending a confirmation and a step of receiving license data from the server via an intermediate device at the client, the client and server are not connected within the hub network, and the license request is stored on the client. The subcopy version is identified, the subcopy version contains subcopy locked content data, and the license data is bound to the hub network.</p><p> The licensing method according to the present invention is a licensing method for granting a license to a client in a hub network, in which a step of receiving a license request from a client of a server via an intermediate device and a step of receiving a license request from a client via an intermediate device are used. It has a step of sending a connection confirmation request to the client and a step of sending license data from the server to the client via an intermediate device, the client and the server are not connected in the hub network, and the license request is a client. The subcopy version stored in is identified and the license data is tied to the hub network.</p><p> In the license renewal method for renewing a license in a hub network, the license renewal method according to the present invention includes a step of sending a renewal request from a client to a server, a step of sending a connection confirmation from a client to a server, and a server in the client. It has a step of sending the updated license data from and a step of updating the subcopy license based on the updated license data stored in the client, and the client and server are connected in the hub network. The update request identifies the subcopy version stored on the client, the subcopy version contains the subcopy locked content data, the subcopy license corresponds to the subcopy version, and the subcopy license is the hub. You are tied to the network.</p><p> The license renewal method according to the present invention is a license renewal method for renewing a license in a hub network, in which the server receives a renewal request from a client, the server sends a connection confirmation request to the client, and the server. It has a step of sending updated license data to the client, the client and server are connected in the hub network, the update request identifies the subcopy version stored on the client, and the updated license data is , Update the subcopy license corresponding to the subcopy version, and the subcopy license is bound to the hub network.</p>
<figref num="1">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="2">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="3">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="4">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="5">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="6">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="7">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="8">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="9">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="10">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="11">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="12">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="13">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="14">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="15">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="16">It is a figure which shows a specific example of the structure and operation of a media network environment.</figref><figref num="17">It is a figure which shows a specific example of a media network environment.</figref><figref num="18">It is a flowchart which shows a specific example of the procedure of adding a device as a member device to a hub network.</figref><figref num="19">It is a flowchart of a specific example of the procedure of deleting a device from a member device of a hub network.</figref><figref num="20">It is a flowchart explaining a specific example of the process for disconnecting a member device from a hub network.</figref><figref num="21">It is a flowchart explaining a specific example of the process for reconnecting a member device to a hub network.</figref><figref num="22">It is a figure which shows a specific example of an independent instance of a content.</figref><figref num="23">It is a figure which shows a specific example of a constrained instance and a subcopy.</figref><figref num="24">It is a flowchart which shows a specific example of the process which constrains an independent instance to a hub network.</figref><figref num="25">It is a flowchart which shows a specific example of the process of releasing a copy of content from a hub network.</figref><figref num="26">It is a flowchart which shows a specific example of the process of renewing a license and renewing.</figref><figref num="27">It is a figure explaining the specific example of the operation of disconnecting a device from a hub network and the operation of a validity period.</figref><figref num="28">It is a figure explaining the specific example of the operation of disconnecting a device from a hub network and the operation of a validity period.</figref><figref num="29">It is a figure explaining the specific example of the operation of disconnecting a device from a hub network and the operation of a validity period.</figref><figref num="30">It is a flowchart which shows a specific example of the process which a client device provides content data by the subcopy version stored in the client device.</figref><figref num="31">It is a flowchart which shows a specific example of the process of streaming content data from a server to a client.</figref><figref num="32">It is a flowchart which shows a specific example of making a subcopy.</figref>
The present invention provides methods and devices for managing devices and content in a network environment. In one specific example, a plurality of devices are interconnected in a media network environment that defines a plurality of hub networks having a client-server relationship. In a hub network, a server provides a client with access to the content by streaming the content to the client or sending a copy of the content to the client. Servers and clients work together to manage hub network membership, connectivity and disconnection to the hub network, content distribution within the hub network, and the state of content within the hub network.
Hereinafter, the meanings of the terms used in the present specification will be comprehensively described. "Content" represents audio and / or video information of an item of media, such as a movie or music. One item of content is one particular item of media, such as one movie. "Content data" refers to data representing an item of content. An "instance" is a logical collection of data that contains content data for an item of content. Therefore, the content data of a content instance is, for example, data that is moved and played (processed). "Playback" and "provide" mean processing and displaying content data of an instance of content, or providing content data depending on the type of content (eg, providing audio and video of a movie, or audio of a song). Means to provide information). Similarly, "providing an instance" means processing and displaying the content data of the instance. "License" refers to data that stores a permission to use the content data, for example, permitting the content data to be played or copied by a device. The description of what can and cannot be done on an instance or content data is based on a set of license grants associated with the instance or content data.
Illustrative concrete example 1 to 16 show a specific example of the configuration and operation of a specific example of the media network environment.
In the specific example shown in FIG. 1, a user, Jim, has a television 110 and a personal video recorder connected to the television 110. recorder: Hereafter, it is called PVR. ) A home media network environment 100 including two 105 devices has been established. The PVR105 is a media network compliant device, i.e., the PVR105 operates based on the processing defined for the devices that are members of the hub network. The PVR105 is equipped with a storage device for storing a copy of the content (for example, a hard disk for storing the content as an electronic file) and functions as a server device. That is, the PVR105 is a server device that functions as a server of the hub network, and can provide content to client devices that are members of the hub network. The PVR105 also defines a local environment as a server (not shown). In this example, the local environment of the PVR105 is related to the location of the PVR105 (eg, determined by packet round trip delay time or GPS information). Defined as a physical area to do. The PVR105 is also a client device. In addition, the PVR105 can directly process the content as a client device, and can also process the content via a connected terminal device, for example, a connected television 110. The PVR105 is a member of the hub network that acts as both a client device and a server device, i.e., a hub network server as well as a hub network client. In FIG. 1, the PVR105 is marked "HN1" to indicate that it is a client device for hub network 1 (HN1). Further, in FIG. 1, the PVR105 is marked with "HN1 *" to indicate that the PVR105 is a server device of the hub network HN1.
Television 110 is not a media network compliant device and therefore cannot be a member of a hub network. However, even a device that does not conform to such a media network can be a terminal device of a hub network, that is, it receives data and does not save the data of the content (it may be temporarily saved). , Content can be provided to the user (for example, displaying a movie image and outputting audio). In this case, the PVR 105 processes the content by supplying and displaying the data of the content to the connected television 110.
The PVR105 first sets up the hub network HN1 as a server device. The PVR105 checks to see if other adaptive devices are connected to the PVR105. Before adding the device as a member to the hub network HN1, the PVR105 authenticates the device, verifies the identity of the device, authorizes the authenticated device, and the device is adaptive. Confirm that. If the PVR105 authenticates the device and does not authorize it, the PVR105 does not add the device to the hub network HN1. In Figure 1, the PVR105 is the only adaptable device. The PVR105 adds itself to the hub network as a server and client. The PVR105 does not add the television 110 as a member because the television 110 is not an adaptive device.
In Figure 2, Jim has purchased movies A and B, as well as recorded television program C. In this embodiment, Jim purchases movie A and movie B and downloads movie A and movie B as electronic files from network 115 connected to PVR105. Jim is also recording TV program C as an electronic file from the broadcast signal received by the receiver built into the PVR105.
As described below, an instance that conforms to hub network behavior is in one of two exclusive states: an independent state or a constrained state. An independent instance is independent of any hub network and can be regenerated or provided (under a license for an independent instance) by any adaptive device. However, adaptive devices cannot make usable copies of independent instances. An independent instance contains locked content data and an independent license. The locked content data of an independent instance is called an "independent version" of the locked content data. Locked content data is locked, for example, by being protected from unauthorized access by encryption. Contained instances are constrained to one hub network. A bound instance is a logical instance represented by locked content data and corresponding licenses stored on hub network servers and zero or more hub network clients. The locked content data stored by the server is the source for a copy of the content data in the hub network and is the "source version". A copy of the source version of the content data is stored on the client and is called the "subcopy version" (provided that some or all of the data in the independent version, source version and / or any subcopy version is identical. May be). Contained instances are only regenerated or served through compatible and adaptable devices that are members of that hub network. Members of that hub network can make subcopies of the content data of the constrained instance.
The server device can change the state of an independent instance to a constrained state, i.e., it can disable the independent instance and enable the constrained instance. A disabled instance is processed into an unusable state (eg, by deleting or encrypting the instance's content data, or by revoking one or more licenses for the instance). The server device can also change the state of the constrained instance to an independent state, i.e. disable the constrained instance (including all corresponding subcopies) and enable the independent instance. can do.
In addition, the servers in the hub network manage the root responsibility of the bound instances. Root obligations include licensing and managing the content data of bound instances in the hub network. Therefore, the server provides a bound instance and holds a root license that defines permissions for managing content data and licenses for the bound instance in the hub network. When a new subcopy is created, a subcopy license is also created from the root license. Instances of content that are not adaptable to hub network behavior are called non-adaptive instances. The adaptive device regenerates or copies the non-adaptive instance based on the copy control information recognized as associated with the instance.
In FIGS. 2-16, the alphabetic label indicates the locked content data version of the content instance. The version of the locked content data and the state of the instance corresponding to the locked content data are indicated by variations of alphabetic characters. The underline shows the independent version of the content. For example, an independent version of movie A is "<u style="single">A</u>Is indicated by. Unlined uppercase letters indicate the source version of the locked content data stored on the server. For example, the source version of movie A is indicated by "A". Lowercase letters indicate the subcopy locked content data version. For example, a subcopy version of movie A is indicated by an "a". In addition, each version has a corresponding license (not shown in FIGS. 2 to 16). That is, the independent version has an independent license, the source version has a root license, and the subcopy version has a subcopy license.
In the example shown in Figure 2, Jim is an independent version.<u style="single">A</u>And version<u style="single">B</u>Is introduced into the hub network HN1 via the PVR105 by storing the movie A and the movie B in the PVR105. In addition, PVR105 is an independent version of TV program C.<u style="single">C</u>To save.
In Figure 3, Jim constrains an independent instance to hub network HN1. PVR105 is an independent version that changes the state of an independent instance<u style="single">A</u>、<u style="single">B</u>、<u style="single">C</u>Change the state of to a constrained instance, i.e. create source versions A, B, C. In this case, the PVR105 is an independent version<u style="single">A</u>、<u style="single">B</u>、<u style="single">C</u>To disable or delete.
In Figure 4, Jim purchases a car 120 that includes an adaptive device. The vehicle 120 is both a server device (eg, equipped with a storage device) and a client device (eg, equipped with an audio and video system). The vehicle 120 establishes a second hub network HN2 with the vehicle 120 as a server (indicated by "HN2 *") and a member client (indicated by "HN2"). The vehicle 120 defines a second local environment (not shown) based on the relative distance from the vehicle 120 (eg, the vehicle 120 defines the round-trip delay time or GPS information of the packet that defines the location of the vehicle 120). Has a device to determine). In FIG. 4, the vehicle 120 and the PVR 105 are physically close to each other, and therefore the local environment of the vehicle 120 substantially coexists with the local environment of the PVR 105.
In Figure 5, Jim connects two hub networks, HN1 and HN2. The PVR 105 and the automobile 120 each have a wireless network function. Jim establishes a wireless connection for the PVR 105 and the car 120. The PVR105 and the car 120 detect each other, authenticate and authorize each other, and add them as member devices. That is, the PVR105 adds the vehicle 120 as a member of the hub network HN1 (indicated by the label "HN1" added to the vehicle 120), and the vehicle 120 adds the PVR105 as a member of the hub network HN2 (label added to the PVR105). (Indicated by "HN2").
In Figure 6, Jim introduces more content into the second hub network, HN2. Jim purchases an adaptive instance of Movie X stored on an adaptive medium, such as an adaptive optical disc. The adaptive medium operates on the basis of the processing defined for the content that can be taken into the hub network (to be constrained) and released from the hub network (to be independent). Specifically, the adaptive medium disables the instance stored in the adaptive medium based on changes in the state of the instance (eg, changes between independent and constrained states). Can be set to or enabled. Further, the adaptive medium is configured to prevent any device from making a complete bit copy of the data stored on this adaptive medium without authorization. This instance is an independent instance because the instance stored on the adaptive optical disc is adaptable and is not yet constrained to any hub network. Jim inserts an adaptive optical disk into the server device of the car 120, which constrains the car 120 to an independent instance of Movie X on the hub network HN2. The car 120 creates a bound instance of Movie X and stores the locked content data and the source version of the root license as part of the bound instance in the storage device of the car 120 (eg, an optical disc). Disabling an independent instance on an optical disk that is adaptable (by storing data storage in). When an independent instance on an adaptive optical disc is disabled, an independent version of the locked content data of the disabled instance cannot be played or provided on other devices (see below). In another example, even if an independent instance is constrained to the hub network, A disabled independent instance can be regenerated by a member device in the hub network to which the independent instance is bound). In Figure 6, the source version of movie X is indicated by the label "X" added to car 120. Also, Jim bought an instance with the adaptability of Song Y and network 115?Downloaded from, which causes the car 120 to constrain this instance to the hub network HN2. In FIG. 6, the source version of song Y is indicated by the label "Y" added to car 120.
In Figure 7, Jim accesses content via a hub network. For example, suppose Jim decides to watch movie X via the PVR105 and the connected television 110. As a member device of hub network HN2, PVR105 can access movie X bound to hub network HN2. The PVR105 requests a copy of the movie X, and the car 120 plays a subcopy version of the movie X on the PVR105 as a server for the hub network HN2. The PVR105 stores a subcopy version of the movie X (indicated by the label "x" added to the PVR105) and displays the movie X via the connected television 110. Jim also decides to listen to song Y via PVR105, so PVR105 saves a subcopy version of song Y (indicated by the label "y" added to PVR105).
Later, Jim decides to watch movie A in a car 120. The PVR105 will supply a subcopy version of Movie A to the car 120 as a server for the hub network HN1. Car 120 stores a subcopy version of movie A (indicated by the label "a" added to car 120) and displays movie A.
In Figure 8, Jim purchases Television 125, an adaptive device. Television 125 is a client device but not a server device. Therefore, television 125 does not form another hub network.
In FIG. 9, Jim connects television 125 to hub networks HN1 and HN2. Television 125 supports both wired and wireless connections. Jim establishes a wired connection between the PVR 105 and the television 125 and a wireless connection between the car 120 and the television 125. When the PVR105 detects the television 125, the PVR105 authenticates the television 125 and authorizes it to participate as a member device. That is, the PVR105 adds television 125 as a member of hub network HN1 (indicated by the label "HN1" added to television 125). Similarly, vehicle 120 authenticates, authorizes, and adds as a member of hub network HN2 (indicated by the label "HN2" added to television 125).
In Figure 10, Jim accesses the content via television 125. Jim decides to watch recorded TV program C via television 125. Television 125 can access television program C constrained by hub network HN1 as a member device of hub network HN1. Television 125 requires the PVR 105 to stream television program C to television 125. The PVR105 streams the source version C of television program C to television 125 (indicated by the dashed line labeled "c" between PVR105 and television 125). Television 125 does not store a copy of television program C (although it may temporarily store data for the process of displaying streamed television program C). In addition, Jim decides to watch movie X via television 125, in which case car 120 streams the source version X of movie X to television 125 (label between car 120 and television 125). (Indicated by the dashed line with an "x").
In FIG. 11, Jim releases song Y from the hub network HN2, i.e., changes song Y from a restrained state to an independent state in order to allow song Y to be taken out. Jim requires Car 120 to create an independent instance of Song Y. Car 120 disables the constrained instance of song Y, i.e. disables the source version and all subcopy versions of song Y (removal of label "y" from PVR105 and label "y" from car 120. Shown by deleting "Y"). The car 120 creates an independent instance of song Y and stores an independent version on an adaptive medium (eg, an adaptive hard disk or an adaptive writable disk) (in addition to the car 120). Label "<u style="single">Y</u>).
In Figure 12, Jim removes song Y from hub network HN2. Jim connects a portable storage device 130 (eg, a removable memory card) to the car 120. Jim moved an independent version of Song Y from the car 120 to the portable storage device 130 (labeled "Label"<u style="single">Y</u>Is shown by removing from the car 120 and adding it to the portable storage device 130) Connect the portable storage device 130 to the portable music player 135. The portable music player 135 is an adaptive device and is not a member of the hub network, but the portable music player 135 is an independent version Y because an independent instance of an independent version Y is not constrained to the hub network. You can play song Y from.
In Figure 13, Jim decides to release Movie B from the hub network HN1 in order to pass Movie B to his friend Sally. Jim demands that the car 120 create an independent instance of the movie. The PVR105 has a source version B, so the car 120 passes the request to the PVR105. PVR105 disables a constrained instance of movie B (indicated by removing the label "B" from PVR105). The PVR105 creates an independent instance containing an independent version B of locked content data and moves the independent version B to vehicle 120 (indicated by the label "B" added to vehicle 120).
In Figure 14, Jim travels by car 120 to his friend Sally's house. When Jim leaves his home, the car 120 leaves the home media network environment 100 and enters Sally's home media network environment 140. In one embodiment, the hub network server device monitors the hub network member devices to determine when the member devices have left the local environment. As mentioned above, in this embodiment, the local environment of the PVR 105 and car 120 is defined by their physical location. When the vehicle 120 leaves, the vehicle 120 leaves the PVR105's local network environment, and the vehicle 120 disconnects the vehicle 120's local environment from the PVR105 and the television 125. If the vehicle 120 no longer reports the physical location to the PVR105, or if the vehicle 120 reports the physical location to the PVR105 outside the boundaries of the home media network environment 100, the PVR105 will be the server of the hub network HN1. Recognizes that the car 120 has left the local environment. Similarly, vehicle 120 recognizes that PVR105 and television 125 have "leaved" the local environment of vehicle 120 (due to their relative distance from vehicle 120) as a server for hub network HN2.
When the vehicle 120 leaves, the vehicle 120 disconnects the hub networks HN1 and HN2. As a client of the hub network HN1, the vehicle 120 monitors the validity period of each subcopy version received via the hub network HN1. This period is a mechanism within the subcopy version license that controls how long the subcopy version can be used without connecting between the client that stores the subcopy version and the server that manages the bound instance. Is. When it expires (for example, measured by the client's secure clock), the disconnected client that saves the subcopy version disables the subcopy version. In this example, the validity period is 15 days (car 120 label "a".<sup>-15</sup>Superscript ""<sup>-15</sup>). Similarly, the PVR105, as a client of the hub network HN2, monitors the lifetime of the subcopy version received through the hub network HN2 (PVR105 label "x".<sup>-15</sup>Superscript ""<sup>-15</sup>).
In Sally's media network environment 140, Sally has a game console 145 and a television 150 connected to it. The game console 145 is an adaptable device that functions as both a server device and a client device. The television 150 functions as a terminal device that displays content from the game console 145, rather than an adaptive device. The game console 145 defines the hub network HN3 and acts as a server for the hub network HN3 (indicated by the label "HN3 *" on the game console 145) and as a client for the hub network HN3 (label "game console 145"). HN3 "). Game console 145 defines a local environment (not shown) as a server in a hub network. Movies L, M and Song N are bound by the hub network HN3, and Game Console 145 stores the source versions of Movies L, M (indicated by the labels "L" and "M" on Game Console 145) and Save the source version of song N (indicated by the label "N" on game console 145).
The next day, Jim connects Car 120 to Sally's game console 145 and hands over an independent instance of Movie B to Sally, as shown in Figure 15. Jim and Sally do not allow the car 120 to participate as a member of the hub network HN3, or the game console 145 as a member of the hub network HN2. To hand over an independent instance of Movie B to Sally, Jim moves an independent version from Car 120 to Game Console 145 (labeled "Car 120".<u style="single">B</u>Shown by deleting). Sally binds an independent instance of Movie B to the hub network HN3 with Game Console 145. Game Console 145 disabling an independent instance of Movie B, creating a captive instance of Movie B, and storing the source version and root license in the memory of Game Console 145 (label added to Game Console 145). (Indicated by "B").
Here, one day has passed since the date described above, and since the car 120 has not been reconnected to the hub network HN1 or HN2, the clocks of the car 120 and PVR105 are due for subcopy versions a and x. Is approaching one day, and therefore the remaining days of validity are reduced by one day ("a" on the car 120 label.<sup>-14</sup>And the label "x" on the PVR105<sup>-14</sup>Shown by the change to).
In Figure 16, Jim returns home by car 120. When car 120 leaves Sally's house, car 120 is disconnected from the game console 145. When the car 120 enters the gym's home media network environment 100, the car 120 connects to the PVR 105 and the television 125. The vehicle 120 returns to the local environment of the PVR 105 and returns the local environment of the vehicle 120 to the PVR 105 and the television 125.
When vehicle 120 is reconnected to PVR105, PVR105 resets the validity period of subcopy version a of movie A stored in vehicle 120 as a server of hub network HN1 (label "a" of vehicle 120).<sup>-14</sup>By changing "" to "a"). Similarly, car 120 resets the validity period of the subcopy version x of movie X stored in PVR105 as a server of hub network HN2 (label "x" of PVR105).<sup>-14</sup>By changing the label "x").
In this example, Jim was able to obtain an instance of the content and bind the instance to the hub network of his home media network environment. Jim was also able to view the content and make copies within the media network environment. When Jim released the instance of content from the media network environment, the instance was deleted. In this way, Jim is free to use his content within the media network environment while constraining the content instance to the media network environment, and if Jim takes the content out of the media network environment, the content instance. Is removed from the media network environment.
Media network environment configuration and operation The configuration and operation of the hub network in the media network environment will be described with reference to FIGS. 17 to 33.
Network configuration The media network environment includes one or more hub networks, each hub network having its own local environment, and some or all of these local environments can overlap or coexist. The local environment is defined as a limited area, and an adaptive device can determine whether the device is inside or outside the local environment. For example, a local environment can be defined in relation to its physical location (eg, calculating the round-trip delay time of a packet between a server and a client, or geographically from a GPS system built into the device. Other local environments are associated with network address information (eg, using IP address and / or subnet information) or (eg, using the number of gateways or routers through which packets pass). It can be defined by a logical domain (determined by evaluating the configuration). The local environment is defined in association with the servers in the hub network (for example, within a circle with a radius of 100 meters around the server). As server conditions change (for example, when the server moves), so does the local environment. As will be described later, an adaptive device can join the hub network within the local environment of the hub network, and when the device leaves the local environment, the device is disconnected from the hub network (provided that this device is a member). May be left as). A device is considered disconnected while it is outside the local environment, even if it can maintain a network connection (eg, a wireless connection) after it leaves the local environment.
The media network environment includes one or more devices. In one embodiment, the device is self-contained software. It may be any of application), hardware components or a combination thereof. For example, one computer device may consist of multiple hardware and / or software devices. Each device in the media network environment may be a device that conforms to the media network (device having adaptability) or a device that does not conform to this (device that does not have adaptability). Adaptive devices operate according to the rules defined for the media network environment and hub network. An adaptive device can be a member of a hub network, such as a server or client device. For example, a non-adaptive device such as a terminal device cannot be a member of a hub network in a media network environment. The non-adaptive device can interact with the hub network and, for example, can receive content as output data from the hub network member device, as described below. However, non-adaptive devices cannot decrypt and process adaptive copies of the content.
A hub network contains one or more member devices. Each member device of the hub network acts as a server, client, or both. For example, a member device can include both server and client functions in the same physical system. Each hub network has one server. Each client is connected to the server either directly or via a network connection. In this way, the hub network forms a hub and spoke or star topology centered on the server. Multiple server devices may be members of the same hub network, in which case one of these server devices will act as a server in the hub network and the other server devices (depending on their client capabilities). Acts as a server client for the hub network.
The hub network server is the center of the hub network and manages many aspects of hub network control. The server manages the root obligations of the content's constrained instances and serves the content to client members in the hub network. The server stores the source version of the locked content data and the corresponding root license of the bound instance. The server supplies the client with a subcopy-locked content data version of the constrained instance, or supplies the client with stream data of the source version of the locked content data. The server manages instances, handles licensing, manages network membership, monitors device connections and disconnections to the hub network, and performs time management. The server defines the local environment of the hub network. As described below, the server transfers the instance state to the hub network by migrating the content instance from an independent state (outside the hub network) to a constrained state (inside the hub network). The server also releases the instance from the hub network by migrating the state of the instance from the constrained state to an independent state.
Clients in the hub network play or serve content data from an instance of content (eg, by decrypting and processing content data stored in a locked data version of the instance). The client device receives a subcopy-locked content data version and a subcopy license of the bound instance from the server, or receives streamed data from the server. The client device may include a storage device for storing the subcopy version (storage client device) or may not store the subcopy version (non-storage client device). The client device displays the content data either directly through the embedded component or through a connected terminal device. Also, in another embodiment, the client device can stream content data from the subcopy version to other client devices that are members of the same hub network.
The terminal device is simply a device for displaying content, not a member of the hub network. The terminal device is connected to a member device and receives data for display, such as output video and audio data. The terminal device may provide other functions and services unrelated to the media network environment.
If the media network environment includes more than one hub network, some or all of the hub networks may overlap. Overlapping two hub networks means that both hub networks contain the same device or devices. Devices that belong to two hub networks span the hub network and spanning. Also called device). The spanning device stores (or can) content data for instances constrained to each hub network. Therefore, the spanning device can play content that is constrained to each of multiple hub networks (constrained instances are constrained to only one hub network). However, in one specific example, the spanning device spans a plurality of hub networks only within the same local environment. In this case, when the device becomes a member of a hub network in a different local environment, the device will only play content from the hub network to which this device was most recently connected. In another embodiment, the spanning device spans different hub networks in different local environments and plays content on all hub networks to which the spanning device belongs (as described below, for example, based on a license request such as an update). To do.
Overlapping hub networks provide a flexible environment for managing content use and copying. Each server manages devices and content within the server's hub network. Each client operates according to the rules of the hub network. As a result, the user can easily display, move, and copy the content data through the media network environment, and the display, copy, and movement of the content data is performed by the licensing authority (eg, content ownership). It can be controlled to reflect the licensing guidelines set by the user. Furthermore, the management of each hub network is left to the server of the hub network.
FIG. 17 shows one configuration example of the media network environment 1700. The media network environment includes two overlapping hub networks HN1 and HN2 with two separate, substantially coexisting local environments (not shown).
The media network environment 1700 includes several devices including a server / client device 1705, a server device 1715, a storage client device 1720, a non-storage client device 1725, a storage device 1730, and a player device 1735 connected to the terminal device 1710. There is. The server / client device 1705, server device 1715, storage client device 1720, non-storage client device 1725, and storage device 1730 are adaptive devices. The terminal device 1710 and the player device 1735 are non-adaptive devices.
Server / client device 1705 and server device 1715 are servers in their respective hub networks. The server / client device 1705 functions as both a server and a client. Server device 1715 acts as a server but not as a client (eg, does not decrypt and process content).
The terminal device 1710 is a device for displaying content data from a connected device such as a television. Terminal equipment 1710 does not store content data constrained to the hub network.
The storage client device 1720 and the non-storage client device 1725 are client devices. The storage client device 1720 and the non-storage client device 1725 play content data as client devices via embedded media components (eg, audio and video output). As described above, the server / client device 1705, which is also a client device, reproduces the content data via the connected terminal device 1710. The storage client device 1720 includes a storage device for storing a subcopy version of the content data. The storage client device 1720 replays the subcopy version of the content data stored in the storage client device 1720 or the content data received as streaming data from a server (eg, server / client device 1705). Non-storage client device 1725 does not store a subcopy version of the provided content data. The non-storage client device 1725 replays content data received as streaming data from a server (eg, server device 1715). As another embodiment, all client devices may be non-storage client device devices. Here, if the device is equipped with a storage device for constrained content data, the device is a server or server / client device.
The server / client device 1705 is a server on the hub network HN1 as indicated by the label "HN1 *" on the server / client device 1705. The server / client device 1705 and storage client device 1720 are clients of the hub network HN1, as indicated by the label "HN1". The terminal device 1710 is connected to the server / client device 1705 and reproduces the content data from the server / client device 1705. Terminal device 1710 is not a member of hub network HN1. Server device 1715 is a server on the hub network HN2, as indicated by the label "HN2 *" on server device 1715.
The server / client device 1705, storage client device 1720, and non-storage client device 1725 are clients of the hub network HN2, as indicated by the label "HN2". The non-storage client device 1725 does not store a subcopy version of the content data and instead receives the data streamed from the server device 1715, as indicated by the dashed line from the server device 1715 to the non-storage client device 1725. To do.
The two hub networks HN1 and HN2 constitute an overlapping, overlapping or overlapping hub and spoke architecture. Hub network HN1 includes server / client device 1705 and storage client device 1720. Hub network HN2 includes server / client device 1705, server device 1715, storage client device 1720 and non-storage client device 1725. The server / client device 1705 and storage client device 1720 are members of both hub networks HN1 and HN2 and are therefore spanning devices.
The storage device 1730 is an adaptable device, and the connected player device 1735 is a non-adaptive device. Storage device 1730 and player device 1735 are not members of hub networks HN1 and HN2. The storage device 1730 is a portable storage device including an adaptable medium such as an adaptable flash memory card. The player device 1735 is a portable media player device such as an MP3 player. In other environments, non-portable non-adaptive devices may be connected to one or more adaptive devices.
The storage device 1730 is connected to the server device 1715 (for example, inserted into a port) and can exchange data with the server device 1715. That is, the storage device 1730 and the server device 1715 can exchange independent instances. The storage device 1730 is connected to the player device 1735, and the player device 1735 can play an incompatible copy of the content data stored in the storage device 1730. Since the player device 1735 is a non-adaptive device, the player device 1735 cannot play or display adaptive content data stored in the storage device 1730. Storage device 1730 cannot make a usable copy from an independent instance stored on storage device 1730.
Hub network membership The server manages membership of devices in the hub network. That is, the server adds and removes clients as members of the hub network. The server licenses only member devices. Upon approval by the user, the server confirms that the client device is an adaptive device and then adds the client device as a member. If the server is also a client device, the server first automatically adds itself as a client. In one embodiment, the server is also considered to be a member. Further, as another specific example, only the client may be regarded as a member. Once added as a member, the device remains a member until the server removes the device from the member. The server removes its client device from its members at the request of the user or when the conditions for revoking membership are met.
FIG. 18 is a flowchart 1800 of a specific example of a procedure for adding a device as a member device to the hub network, such as adding a storage client device 1720 to the hub network HN1 shown in FIG. First, in block 1805, the client device is connected to the hub network. The client may connect directly to the server via a wired or wireless connection, or may indirectly connect to the server via, for example, another network device. The server does not add the unconnected device as a member (although in an alternative example described below, an intermediate device is used to add the unconnected device to the member).
The server discovers connected client devices in block 1810. The adaptive device sends a message or connection notification to the device in the hub network indicating that the device is currently connected to the hub network. In another embodiment, the server periodically polls connected devices to detect new clients.
The server authenticates the detected client device in block 1815. The server sends a compliance confirmation request requesting information from the client device to check whether the client device is an adaptive device. For example, the server sends an encrypted confirmation request for an adaptive device. If the client device does not respond properly or, by other means, the server determines that the client device is not an adaptive device, authentication fails and the server does not add this client device to the hub network as a member. ..
After confirming that the client device is an adaptive device, the server sends an identification request for information from the client device that identifies the client device. The server is a minimum set of identification information required to authenticate a client device, such as a Media Access Control address (hereinafter referred to as a MAC address). Has set). In one embodiment, the adaptive device has a secure and unique device identifier for the hub network. If the client device does not respond or does not provide the proper information, authentication fails and the server does not add this client device to the hub network as a member. When the server authenticates a client device, the server checks the list of member devices to see if the authenticated client device is already in the list of member devices. If the authenticated client device is already on the list of member devices, the server does not need to add the client device as a member and notifies the user that the device has been reconnected. The server and the client perform the processing described later with reference to FIG. 21 (explaining the reconnection of the member devices). In one embodiment, the server adds the authenticated client device to the list of authenticated connected devices in the server's hub network.
After successfully authenticating the client device, the server receives an additional request from the user to add the client device to its members in block 1820. The server waits for a client device to be added until it receives a positive request from the user to add a particular client device. In another embodiment, instead of waiting for a request from the user, the server requests approval or confirmation from the user to add the authenticated device when the device is detected. In another embodiment, the server authenticates the client device by waiting until it receives a request or approval to add the client.
After receiving the request to add the client device, the server grants privileges to the client device in block 1825. In one embodiment, the client must be in the local environment of the hub network to be added. The server asks for information from the client to confirm that the client device is in the local environment of the hub network. request) is sent. In one embodiment, the server sends an inspection message and waits for a response from the client (eg, issues an IP packet to the client to see if the packet arrives correctly and is replied to). .. The server determines if the client is in the local environment based on the time between sending the inspection message and receiving the response (for example, a round-trip delay below the threshold causes the client to be in the local environment. Indicates that there is). In another embodiment, the server sends local environment information to the client device, and the client device itself determines whether the client device is in the local environment. If the server cannot verify that the client device is in the hub network's local environment, authentication fails and the server does not add this client device to the hub network as a member.
Also, in one embodiment, the server verifies that the client device is not in the server's revocation list before authenticating the client device. As described below, the revocation list shows the devices whose privileges have been revoked. In one embodiment, the server adds the privileged client device to the list of privileged devices.
Upon successful authorization of the client device, the server verifies in block 1830 that the number of member devices in the hub network does not exceed the member device limit. The server stores information about the device limit, which indicates the maximum number of member devices that the server can add as members of the hub network, for example up to 20 units. The server also maintains an incremented number of devices each time each device is added as a member. Once the number of devices has already reached the device limit, the server no longer adds client devices to the hub network as members. In an alternative embodiment, the server does not maintain a device count or device limit, in which case block 1830 is skipped. In another embodiment, the device limit can be changed at the request of an authorized external certification authority.
If the number of devices is below the device limit, the server adds the client device as a member and as a client of the hub network in block 1835. The server sends an additional confirmation message to the added client. The server also increments the number of devices by one. In one embodiment, the server adds client devices to the list of members and the list of clients (or the same list). Some or all of the list of connected devices, authenticated devices, privileged devices, member devices, client devices, and revoked devices may be integrated or related to each other (eg,). It may be cross-referenced) or omitted.
In an alternative embodiment, the server may attempt to automatically add the discovered client device to its members in response to client discovery, or use a set of rules to attach the connected client. You may decide when to add it to the members. In another embodiment, the server automatically authenticates and grants privileges on the detected client device, but adds the authenticated and privileged device as a member until it receives a user request or authorization. Absent.
In another embodiment, when the number of devices reaches the device limit, the server attempts to add other devices to the members, and the server communicates with the device registration server, for example, over an external network connection. .. The device registration server notifies the server if a client device is about to be added to the hub network. The device registration server maintains information about the hub network and the member devices of that hub network. The device registration server can use various criteria to determine whether to allow a client device to be added. In one embodiment, the device registration server compares the threshold with the number of hub networks to which the client device has already been added as a member. In another embodiment, the device registration server compares the number of devices already added to the hub network with the second device limit, and if the number of devices is below this second device limit, Allow the addition of client devices. In this case, the first device limit stored on the server acts as a constraint for adding devices that are not registered externally, and the second device limit is used as the maximum number of devices to be added. Be done. In another embodiment, the server always queries the device registration server before adding a device (for example, it behaves as if the first device limit is zero).
In other embodiments, unconnected devices or devices outside the local environment can be added as members. In this case, the intermediate device acts as a "conduit" for membership. Here, neither the server nor the potential client is connected, or the client is not in the server's local environment. The intermediate device is connected to both the server and the client (eg, directly or indirectly, or, for example, at different times if the intermediate device is a portable device that moves between the server and the client). The intermediate device requests permission from the hub network server to add clients to the hub network. The additional processing is performed in the same manner as in the above case, but here, instead of the server and the client communicating directly, the intermediate device passes a message between the server and the client, and in the local environment for the device, the additional processing is performed. Communicate with each device.
FIG. 19 is a flowchart 1900 of a specific example of deleting a device from a member device of the hub network, such as deleting the storage client device 1720 from the hub network HN1 shown in FIG. Initially, the device is connected to the hub network and is a member of the hub network. In block 1905, the removal of a member client device is triggered. In one embodiment, the deletion is triggered in two ways: by receiving a deletion request specifying the client device from the user, or when the server decides to revoke the privileges of the client device. If the server receives a revocation notice that identifies the client, or if the client device breaks or violates the rules of the hub network as an adaptive member device, for example, the state of the bound instance is independent. The server decides to remove the client device, for example, if the subcopy version cannot be disabled even if it is changed to. The server also revokes the privileges of the device if the server determines that the security of the device is compromised.
The server disables the license for the subcopy version of the bound instance bound to the server's hub network for the client device to be deleted in block 1910. In this case, the server sends a disable request to the client indicating the subcopy version to be disabled, and the client disables the corresponding license. In addition, the deleted client device will not be able to receive new licenses or renew existing licenses for instances bound to the hub network where the client device was deleted. In one embodiment, when the client is deleted, the adaptive client device will have the subcopy version stored on the client and all licenses of the bound instance that is bound to the hub network where the client was deleted. Is automatically disabled. However, even if you remove a client from one hub network, you do not need to disable the license for the subcopy version of the bound instance that is bound to another hub network.
The server removes the client device from the members of the hub network in block 1915. The server removes the client device from the list of member devices and decrements the number of member devices. The server maintains a device revocation list, which is a list of devices whose membership has been revoked. If the server deletes a device for cancellation, the server adds the device to the server's cancellation list. If a client device is on the cancel list, the server does not add it as a member. In one embodiment, when the revocation list is updated, the server publishes the revocation list to, for example, a client in the hub network, another server, or another device such as a central database. In another embodiment, the server renews one or more root licenses stored on the server to indicate that the client has been revoked.
In one embodiment, when a client is disconnected, the server does not remove the disconnected client from its members until all licenses for the subcopy stored on the client have expired. As described below, when the device is disconnected, the license from the disconnected hub network eventually expires. The server waits for all licenses to expire before removing the disconnected device.
Device disconnection and reconnection Once the device enters the hub network's local environment, the device can connect to the hub network. When the device leaves the hub network's local environment, the device disconnects from the hub network. When the device returns to its local environment, it can reconnect to the hub network. As mentioned above, if an adaptive non-member device is connected or reconnected to the hub network, the server will attempt to add this new device as a member after receiving a request or approval from the user.
FIG. 20 shows a flowchart 2000 illustrating a specific example of a process for disconnecting a member device from a hub network. First, in block 2005, the connected device is disconnected. The device is disconnected for various reasons. For example, when a device leaves the hub network's local environment, the device disconnects from the hub network. Also, if the physical connection (wireless or wired connection) between the device and the hub network fails, the device is disconnected from the hub network. For example, if the server and the client are unable to exchange packets of data, the client and the server are disconnected. In one embodiment, the server determines if a client is connected, if necessary (eg, before acting on the information about the connected client). In another embodiment, the server polls the client's connections on a regular basis and maintains a list of connected devices, and the client polls the server on a regular basis and does so when the client disconnects. recognize. In another embodiment, if the user positively requests the device to be disconnected, the device will be disconnected.
Since the local environment is defined for the location of the server (for example, within 100m from the server), when the server physically moves, the local environment moves with the server, so the server never leaves the local environment. .. Also, if the server moves and the client does not move, one or more clients of the hub network may "leave" the hub network's local environment as a result of the server move. In this case, the client left behind is disconnected from the hub network in order to leave the local environment.
In Block 2010, the client checks the validity period for all licenses of the subcopy version of the bound instance that is bound to the hub network. As will be described later, the subcopy version of the license has a validity period. When the client receives the license, the client sets an expiration date based on the validity period of the license. For example, if the license is valid for 15 days, the client sets the expiration date 15 days after the client receives the license. The client uses a secure clock to monitor how much time is left before the deadline and when it expires. Upon receiving the renewed license, the client requests the renewed license from the server and periodically renews the license by resetting the validity period and expiration date. The disconnected client device will not connect to the server and will not be able to renew its license. If the client is unable to renew the license, the expiration date will not change and therefore the time to expiration will gradually decrease. When it expires, it expires and the client disables the license. If the client can renew the license again, the client enables the license and resets the expiration date. If a client disconnects from the hub network that corresponds to the first license, the client will not be able to renew the first license, but this client will be connected to a different hub network that corresponds to the second license. If left unchecked, the second license can be renewed.
If any of the expiration dates expire, the client disables the expired license in block 2015. The client disables the license, thereby disabling the corresponding subcopy version. In another embodiment, the client otherwise disables the subcopy version, as described below.
At block 2020, the client periodically checks to see if the client is reconnected to the hub network. In one embodiment, the client requests an updated license and at the same time checks to see if a reconnection is taking place. In some configurations, such as those using a wired connection, the client quickly receives a signal indicating a reconnection, so the client needs to periodically check to see if a reconnection is taking place. Therefore, block 2020 can be omitted. When the client is reconnected to the hub network, the client performs the process shown in Figure 21.
FIG. 21 shows a flowchart 2100 of one specific processing procedure for reconnecting a member device to a hub network. Initially, the device here is a member device disconnected from the hub network. The device is reconnected to the hub network at block 2105. If the device is in the local environment of the hub network and the physical connection between the device and the hub network is restored or established, the device can be reconnected. In one embodiment, the client periodically polls the server to recognize that the client has reconnected. In one embodiment, the device will not reconnect until the user requests it.
At block 2110, the server detects devices reconnected to the hub network. In one embodiment, the client sends a reconnection notification to the server. As mentioned above in connection with block 1810 of FIG. 18, in another embodiment, the server periodically polls the hub network to detect newly connected or reconnected devices.
At block 2115, the server authenticates the detected device and checks if the reconnected device is a member client of the hub network. Also, as described above in connection with block 1815 of FIG. 18, the server authenticates the device at the time of connection and determines the identity of the device. The server maintains a list of member devices and can therefore determine that the newly connected device is already a member of the hub network and therefore does not need to be added again. In one embodiment, the server verifies that the reconnected device is in the local environment of the hub network. In addition, in one embodiment, the server also verifies that there are no reconnected devices in the revocation list.
After authenticating the device as a member device, the server renews the license for the block 2120 client. The server renews the license for a subcopy version of the content data stored on the client for the bound instance that is bound to the server's hub network. The server does not renew the license for the subcopy version of the bound instance that is bound to another hub network. Alternatively, the client may request a license renewal once the client has been reconnected to the hub network.
Time management The server is responsible for time management of the hub network. Time management includes relative time management and absolute time management. The server manages time and enforces time constraints on the licensing of independent or bound instances of hub network content, for example. The client also manages the time internally or by referring to the time management by the server. When the client receives a subcopy version of the license from the licensing authority, the client synchronizes the time information with the licensing authority before receiving the license. Servers and clients use secure mechanisms to manage their time.
Confidentiality In one embodiment, hub network devices are, but are not limited to, for example: data communication, request processing, transaction registration for transaction history, licensing and revocation, device authentication, etc. Use secure technology for a variety of operations, including authorization, disable and revoke, instance copy and key storage, creation and move, metadata maintenance for instances and copies, and display of streaming content. .. Adaptive devices are regularly centralized The security process from authority) can be updated or updated information can be received from the user or an automated source. The client device updates the security mechanism before receiving the license. This mechanism includes, for example, updating cryptographic keys, synchronizing client clock and time information with servers, exchanging and updating revocation lists, updating system security data and tools, and the like. In one embodiment, if the server determines that the key has been cracked, the server can revoke the key. In this case, the server requires the adaptive device to disable the revoked key, which makes it impossible to access secure media content with the revoked key.
Content Management Devices in the media network environment view, copy, and move content data for instances of content. As mentioned above, the instance contains media data, such as content data, which is audio and / or video data. As mentioned above, the hub network server manages the state of the constrained instances of content in the hub network. The server directly changes the state of the constrained instance and causes member clients in the hub network to take appropriate action based on these state changes.
Instances of content may be adaptive or non-adaptive. The adaptive instance contains the encoded data so that only the adaptive device can decode and replay the content data. Therefore, a non-adaptive device cannot play content data from an adaptive instance. The adaptive device (server) can constrain the adaptive instance to the hub network or release the adaptive instance from the hub network.
Non-adaptive instances or copies of content are not encoded at the request of the hub network, and therefore non-adaptive or adaptive devices are (other than present in the instance or copy). It is possible to play content data of non-adaptive instances or copies (based on the copy control mechanism of). Adaptive devices do not constrain non-adaptive instances or copies to the hub network, but non-adaptive content can be stored in other formats. In one embodiment, the non-adaptive instance has copy control information recognized by the adaptable device and is adaptable if it is certified for use in a hub network. The device can bind non-adaptive instances that define root licenses based on copy control information.
Content status Each adaptive instance of the hub network's content is in one of two exclusive states, an independent state and a constrained state. Independent instances of content are not tied to any hub network and can be moved from one device to another within or outside the hub network using adaptive media. Adaptive devices do not make copies of independent instances (although they may make temporary copies when playing content). Independent instances can have a variety of formats, eg, by downloading over one or more electronic files or (eg, a network connection) stored on an adaptive storage medium (eg, an optical disc). It may be one or more electronic files stored in the storage device of the (received) adaptive device. A medium that stores an independent instance of content is a medium that is media network adaptable. The adaptive medium allows the server to modify the independent instance as needed, for example, when binding content to the hub network, the independent instance can be disabled. In addition, the adaptive medium is configured so that the device cannot make a bit copy of any independent instance of data stored on the adaptive medium. That is, the adaptable medium is a secure read / write storage medium (eg, a writable optical disc or read-only medium that has or is associated with writable storage). It has a secure read / write storage medium. In one embodiment, the writable storage may be remote from the media itself, for example a database. Adaptive devices do not make a copy of a separate instance.
FIG. 22 shows a specific example of the independent instance 2205. Independent instance 2205 contains locked or secure (eg, encrypted) content data 2210. The locked content data of an independent instance is also referred to as an independent version of the locked content data of an independent instance. The locked content data 2210 is media content data of an independent instance of, for example, audio or video data (eg music, television programs, movies). In an alternative embodiment, the locked content data may be non-media data such as, for example, executable software (eg, computer game or video game). Locked content data 2210 (for example, public peer review) Encrypted (using one or more cryptographic algorithms issued and verified via review). The locked content data 2210 is encrypted using a content encryption method so that only adaptive devices can decrypt the locked content data 2210. Header information 2215 is associated with locked content data. The header information indicates, for example, a title identifier, an instance identifier (identifying a particular instance), coded data data (eg, a codec, resolution, coding entity used to encode the locked content data). ), Includes metadata such as licensing authority data. The licensing authority data indicates an external licensing authority that can be accessed to obtain further rights or licenses. Some specific examples of independent instances do not include licensing authority data (eg, all licenses used, along with locked content data, are provided). In another embodiment, part or all of the header information 2215 is encrypted, or the header information 2215 is included in the locked content data 2210. Independent instance 2205 contains protected area 2220 of encrypted data. The data in protected area 2220 is encrypted using a hub network encryption method so that only the adaptive device (for example, using the key held by the adaptive device) can decrypt the data in protected area 2220. Be transformed. Protected area 2220 contains key 2225, independent license 2230 and revocation list 2235. Key 2225 is used to unlock the locked content data 2210. In one embodiment, the adaptive device holds the key to decrypt protected area 2220, including key 2225 (encrypted using hub network encryption), and uses key 2225 (content). Locked content (encrypted using encryption) Decrypt data 2210. Independent License 2230 holds the current license for Locked Content Data 2210 for a particular Independent Instance 2205. License 2230 defines a set of permissions for properly playing, copying, and moving independent instances defined for the locked content data 2210 of a particular independent instance 2205 (eg,). Copying is not allowed). License 2230 also indicates what kind of license is available to the bound instance, based on independent instance 2205. In one embodiment, license 2230 includes a flag to indicate that independent instance 2205 is an independent instance. Revoke list 2235 shows the devices whose authorizations have been revoked. Adaptive devices maintain their own revocation list. When an adaptive device receives an independent instance, the device adds to the cancellation list all devices in the cancellation list of the independent instance that are not in the device cancellation list. An adaptive device does not provide or replay an independent instance if the device is on the device's revocation list. An adaptive server does not bind an independent instance if it is on the server's revocation list. In another embodiment, the independent instance does not have to include a revocation list. In another embodiment, the parts of independent instances may be saved as multiple files. , Not allowed). License 2230 also indicates what kind of license is available to the bound instance on the basis of independent instance 2205. In one embodiment, license 2230 includes a flag to indicate that independent instance 2205 is an independent instance. Revoke List 2235 shows the devices whose authorizations have been revoked. Adaptive devices maintain their own revocation list. When an adaptive device receives an independent instance, the device adds to the cancellation list all devices in the cancellation list of the independent instance that are not in the device cancellation list. An adaptive device does not provide or replay an independent instance if the device is on the device's revocation list. An adaptive server does not bind an independent instance if it is on the server's revocation list. In another embodiment, the independent instance does not have to include a revocation list. In another embodiment, the parts of independent instances may be saved as multiple files. , Not allowed). License 2230 also indicates what kind of license is available to the bound instance, based on independent instance 2205. In one embodiment, license 2230 includes a flag to indicate that independent instance 2205 is an independent instance. Revoke list 2235 shows the devices whose authorizations have been revoked. Adaptive devices maintain their own revocation list. When an adaptive device receives an independent instance, the device adds to the cancellation list all devices in the cancellation list of the independent instance that are not in the device cancellation list. An adaptive device does not provide or replay an independent instance if the device is on the device's revocation list. An adaptive server does not bind an independent instance if it is on the server's revocation list. In another embodiment, the independent instance does not have to include a revocation list. In another embodiment, the parts of independent instances may be saved as multiple files. Do not bind independent instances if they are on the erase list. In another embodiment, the independent instance does not have to include a revocation list. In another embodiment, the parts of independent instances may be saved as multiple files. Do not bind independent instances if they are on the erase list. In another embodiment, the independent instance does not have to include a revocation list. In another embodiment, the parts of independent instances may be saved as multiple files.
Contained instances are constrained to a particular hub network and managed by servers in that hub network. The data of the constrained instance is (at least partially) encrypted so that non-adaptive devices or devices outside the constrained hub network provide the content data of the constrained instance. Or it cannot be regenerated. The server that manages the constrained instance has a root obligation for the constrained instance. Root obligations include issuing and managing subcopy-locked content data versions of bound instances. In addition, the server that manages the constrained instance manages the source version of the locked content data of the constrained instance. The server uses the source version to create a subcopy-locked content data version within the hub network. The specified server is the local licensing authority for the subcopy version of the bound instance. The server can create a subcopy version from the source version and can provide the subcopy version to clients on the hub network. In one embodiment, the client can create a subcopy version from the subcopy version stored by the client, but the client that receives the new subcopy version can play the content on the hub network. Requires a license from the server. Devices that receive a subcopy version from a different hub network (for example, the device is not a member) will need to obtain a new license, for example, from the licensing authority indicated by the subcopy version. The adaptive server does not move the constrained instance to another adaptive server because of the root obligation, unless it changes the state of the constrained instance to an independent state. Other sir The server that transfers the root obligation to the server changes the bound instance to an independent instance and migrates the independent instance to a second server. The second server then migrates the received independent instance to the constrained instance, so that the second server bears the root obligation. In this case, the constrained instance is constrained to a different hub network with a second server as the server. In another embodiment, the source version is not stored on a server in the hub network, which stores and manages the root license and manages the source version remotely.
FIG. 23 shows a specific example of a constrained instance 2300 that includes components stored on server 2305 and client 2350. The structure of the constrained instance 2300 is similar to that of the independent instance 2205 in Figure 22, but can include data stored on the server and data stored on zero or more clients in the hub network. Server component 2305 includes locked content data 2310, header information 2315, protected area 2320 containing key 2325, root license 2330 and revocation list 2335. Locked content data 2310 for server component 2305 is the source version of the locked content data for constrained instance 2300. The server uses the source version to create a subcopy-locked content data version (eg, locked content data 2310 described below). The source version is the highest resolution version of the hub network content. If different devices request different resolution copies, you can make these copies from the source version. The licensing authority data in header information 2315 includes an external licensing authority (eg, the same agency indicated by the independent instance on which the bound instance depends) and the server as the local licensing authority. Shown. Some specific examples of constrained instances do not contain absolute licensing authority data (eg, all licenses used, along with locked content data, are provided). Root License 2330 defines a set of permissions for properly playing, copying, and moving a bound instance (for example, does not allow movement, but creates a subcopy version and provides it to other devices. Allow to do). Root license 2330 is bound to a specific server by encryption. Root rye Sense 2330 defines what types of licenses are available for subcopies of the hub network. In one embodiment, root license 2330 includes a flag indicating that the bound instance 2305 is a bound instance. In one embodiment, the root license will be different depending on whether the server is a server device or a server / client device. The revocation list shows the devices whose permissions have been revoked. As mentioned above, adaptive devices maintain their own revocation list (eg, the server maintains the server or device revocation list, and the client maintains the client revocation list). When the server receives a bound instance, the server adds all devices in the bound instance's cancellation list that are not in the server's cancellation list to the cancellation list. An adaptive server device cannot regenerate or provide a constrained instance if the device is on the server's revocation list. Also, an adaptive server cannot release a bound instance (cannot move to an independent state) if it is on the revocation list. Adaptive servers do not provide subcopy versions or licenses to devices on the server's revocation list. In another embodiment, the adaptive server can provide a subcopy version to a device on the revocation list, and does not license that device. .. As mentioned above, the adaptive device maintains its own revocation list (eg, the server maintains the server or device revocation list, and the client maintains the client revocation list). When the server receives a bound instance, the server adds all devices in the bound instance's cancellation list that are not in the server's cancellation list to the cancellation list. An adaptive server device cannot regenerate or provide a constrained instance if the device is on the server's revocation list. Also, an adaptive server cannot release a bound instance (cannot move to an independent state) if it is on the revocation list. The adaptive server does not provide subcopy versions or licenses to devices on the server's revocation list. In another embodiment, the adaptive server can provide a subcopy version to a device on the revocation list, and does not license that device. .. As mentioned above, the adaptive device maintains its own revocation list (eg, the server maintains the server or device revocation list, and the client maintains the client revocation list). When the server receives a bound instance, it adds all devices in the bound instance's cancellation list that are not in the server's cancellation list to the cancellation list. An adaptive server device cannot regenerate or provide a constrained instance if the device is on the server's revocation list. Also, an adaptive server cannot release a bound instance (cannot move to an independent state) if it is on the revocation list. The adaptive server does not provide subcopy versions or licenses to devices on the server's revocation list. In another embodiment, the adaptive server can provide a subcopy version to a device on the revocation list, and does not license that device.
The components stored on the client 2350 are similar to the components stored on the server 2305, but with different licenses. Client 2350 includes locked content data 2355, header information 2360, protected area 2365 containing key 2370, subcopy license 2375 and revocation list 2380. Header Information 2360's licensing authority data includes external licensing agencies (for example, the same agency indicated by the independent instance on which the bound instance depends) and the instance bound as a local licensing authority. Indicates the server corresponding to. As mentioned above, some specific examples of constrained instances do not include licensing authority data. Subcopy License 2375 is a set defined for specific Locked Content Data 2355 that contains rules for playing Content, for example, some time limit, based on the root license of the corresponding bound instance. Indicates permission. Subcopy license 2375 is bound to a particular client by encryption. Subcopy license 2375 includes a validity period until the client is unable to renew the license, as described below. As mentioned above, the client device maintains the revocation list and updates the revocation list based on the revocation list 2380. An adaptive client device may not play or provide a subcopy version if the device is on the client's revocation list. In one embodiment, neither the adaptive device nor the device on the client's cancellation list will be provided with a subcopy.
In one embodiment, the locked content data and protected areas of the constrained instance, as well as the independent instance, are encrypted using different techniques. Locked content data (source version and all subcopy versions) is encrypted using a content encryption method. The protected area is encrypted using a hub network encryption method. In one embodiment, the adaptive device holds a hub network key that decrypts the protected area (encrypted using hub network encryption) and uses the key decrypted from the protected area. To decrypt the locked content data (encrypted using content encryption).
In another embodiment, the locked content data and licenses (or the entire protected area) of the bound instance can be managed and distributed individually. Similarly, the locked content of independent instances may be delivered individually. In this case, the adaptive device cannot play the locked content data without first obtaining a valid license. The device can deliver locked content data outside the hub network, but again the receiver requires a new license. Further, for this purpose, as described below, the intermediate device can act as a conduit for renewing the license of the disconnected member device outside the local environment of the hub network by passing the license from the server to the disconnected client.
Multiple independent instances of the same content are treated as separate and independent instances and are not correlated with each other. Similarly, when multiple independent instances of the same content are bound to a hub network, each creates a separate bound instance. In another embodiment, the server recognizes that there are multiple independent instances of the same content (eg, based on the identity information in the content or header information), and the licensing information for the instances is these. You can handle bound instances in association with each other. For example, if there are multiple related instances, releasing one related instance does not require the locked content data of the remaining related bound instances to be disabled.
In another embodiment, the instance or copy of the content can have an unrestricted third state. Unconstrained instances and their copies can be freely moved, copied, and replayed within and outside the hub network. The adaptive device does not change the state of the unconstrained instance to a constrained or independent state. When the user requests that the content be added to the hub network, the server checks for copy control information and identifies the controlled state of the server (which defines the root license based on the copy control information). If so, add the content as a constrained instance. When the user requests to add an instance for which no copy control information or media network environment information is detected (eg, an instance that is neither an independent instance nor a constrained instance), the device will add the content as an unconstrained instance. Can be done.
In the specific example shown in FIG. 17, the two content items A and B are constrained to the hub network HN1. For each constrained instance of the content A, B, the server / client device 1705 stores the source version of the locked content data, labeled "A" and "B". The storage client device 1720 stores a subcopy-locked content data version of each of the two content items A and B, indicated by the labels "a" and "b", respectively.
One content item X is bound to the hub network HN2. Server device 1715 stores the source version of content X, which is labeled "X". The server / client device 1705 and storage client device 1720 each store a subcopy version of content item X, which is labeled "x". Server device 1715 also stores an independent version of the locked content data for an independent instance of content Y, which is labeled "Y".
Storage device 1730 stores an independent version of content Z, which is labeled "Z".
Content state transition The server manages the state of adaptive instances of content in the hub network. The server constrains the instance to the hub network by changing the state of the independent instance to the constrained state. The server removes or releases the instance from the hub network by changing the state of the constrained instance to an independent state, disabling the corresponding locked content data in the hub network.
FIG. 24 shows Flowchart 2400 as a specific example of the process of constraining an independent instance to a hub network. First, the server receives an independent instance in block 2405. As mentioned above, independent instances can have a variety of formats, eg, via one or more electronic files or (eg, network connections) stored on an adaptive storage medium (eg, an optical disk). It may be one or more electronic files stored in the storage device of an adaptive device (received by downloading). The server still makes a copy of the independent instance because the server cannot make a copy of the independent instance that is not tied to the hub network (although it can make a copy of the locked content data of the independent instance). Do not create.
At block 2410, the server receives a request from the user to bind an independent instance to the hub network. In one embodiment, the server waits for a request from the user. In another embodiment, when the server receives an independent instance, the server issues a query to the user asking if the server should bind the independent instance to the hub network.
When the server receives the constraint request, the server disables the independent instance block 2415. Disabling an independent instance prevents an adaptive device from playing or providing an independent instance. In one embodiment, the server disables an independent instance by disabling the license of the independent instance. In another embodiment, the server disables an independent instance by flagging the data of the independent instance so that the adaptive device does not replay the independent instance. In another embodiment, the server disables an independent instance by encrypting some or all of the independent instance with a server-specific key. In another embodiment, the server is an independent instance by registering the independent instance as disabled by a central database or institution (eg, checking before the device plays or provides content data). To disable. In another embodiment, the independent instance is only partially so that the device that is a member of the hub network to which the disabled independent instance is bound can provide or replay the independent instance as a subcopy. Be made disabled. If the server cannot disable an independent instance, the server does not constrain the independent instance to the hub network.
The server creates a constrained instance from an independent instance in block 2420. The server copies an independent instance. This copy includes locked content data, header information including licensing authority information, a key to unlock the locked content data, an independent license, and a copy of the revocation list (if any). The server stores a copy of the locked content data as a source version of the locked content data for the constrained instance. The server changes the independent license to the root license in order to properly manage the bound instance instead of the independent instance. Alternatively, the server may generate a new root license with the independent license instead of copying the independent license. Alternatively or additionally, in another embodiment, the server may access an external licensing authority as indicated by the licensing authority information to renew or generate a root license. In one embodiment, if the server is not a server / client device and therefore does not play content, the root license does not store licensing information about play permissions for the server.
In an alternative embodiment, the server disables the independent instance by deleting some or all of the independent instance. In this case, the server first establishes a constrained instance of the independent instance before deleting the independent instance.
In another embodiment, the server transforms an independent instance into a constrained instance. In this case, the server does not make a copy of the independent instance. Instead, the server modifies the licensing authority information and license as appropriate to indicate that the independent instance is now a bound instance.
In one embodiment, the server disables an independent instance and ensures that the server can constrain the independent instance before creating the constrained instance. The server verifies that the license for the independent instance allows the server to bind the independent instance. The server also confirms that the server is not registered in the server's cancellation list. Also, in another embodiment, the server verifies that there is a proper watermark in the locked content data of the independent instance. If the server cannot confirm that the independent instance is allowed to be bound, the server does not bind the independent instance.
In one embodiment, the server receives broadcast information, stores it as bound content, and establishes a root license. The server automatically creates a root license. In an alternative embodiment, the server uses the information in the broadcast information to define a root license, or uses the licensing agency information in the broadcast information to access an external licensing agency to obtain a root license. Get permission for. In another embodiment, the server records the broadcast content as an independent instance. In one embodiment, the broadcast information includes a key, licensing authority information, and licensing information for building an independent copy. In another embodiment, the server receives broadcast information, stores it as constrained content, and establishes a route. The server uses the licensing agency information in the broadcast information to access an external licensing agency and obtain a license to create a root copy. In one specific example, the server encrypts the media content of the broadcast information based on the copy control information provided by the broadcast information.
FIG. 25 is a flowchart 2500 of a specific example of the process of releasing a copy of the content from the hub network and making the content independent (discrimination). Initially, the constrained instance is stored on the server and any client that stores a subcopy version of the content.
In block 2505, the server receives a request from the user to release the bound instance from the hub network and creates an independent instance. In one embodiment, the server waits for a request from the user. In another embodiment, the server sends a query to the user when the server receives an action request that cannot be executed for the constrained instance, for example, taking the constrained instance out of the hub network. In this case, the query asks if the server releases the bound instance from the hub network and creates an independent instance.
After the server receives an independent request, the server disables the subcopy version of the corresponding constrained instance for clients in the hub network in block 2515. The server sends a disable request to each member of the hub network indicating that the bound instance subcopy version will be disabled. Alternatively, the server may send a disable request to a member with a subcopy version of the bound instance (eg, indicated by a license sent to the client). The client that receives the disable request disables all subcopy versions corresponding to the constrained instance. Disabling a sub-copy version prevents an adaptive device from providing or playing the disabled sub-copy version. In one embodiment, the client disables the subcopy version by disabling the license for the subcopy version. In another embodiment, the client removes the subcopy version that should be disabled. In another embodiment, the client disables the subcopy version by setting a flag in the subcopy version's data to indicate that the adaptive device does not play the subcopy version. In another embodiment, the client disables the subcopy version by encrypting the subcopy version with a client-specific key. In another embodiment, the client sub-registers the bound instance as disabled by a central database or agency (eg, confirming before the device plays or provides a sub-copy version). Disabling the copy version. At this time, if the client is disconnected from the hub network, the server will cause the client device to be hubbed.
After the server disables the subcopy version, the server disables the source version in block 2515. Adaptive devices will not be able to provide or play the source version by disabling the source version. Just as the server disables an independent instance, or the client disables a subcopy version, the server disables the source version, for example, by disabling the root license of the bound instance. Make it ABLE.
The server creates an instance in block 2520 that is independent of the constrained instance. The server copies the constrained instance. This copy includes locked content data, header information including licensing authority information, a key to unlock the locked content data, an independent license, and a copy of the revocation list (if any). The server stores an independent instance on an internal storage device or an external adaptive medium (eg, based on an independent request from the user). The server modifies the root license to suit a separate instance rather than a bound instance. Alternatively, the server may not copy the root license and instead use the root license to generate a new independent license. Alternatively or additionally, in other embodiments, the server may access an external licensing authority as indicated by the licensing authority information to renew or generate an independent license.
In one embodiment, the server ensures that the adaptive medium is available to store the new independent instance before creating the independent instance on the external adaptive medium. .. If adaptive media is not available, the server may create an independent instance within the internal storage device, or the server is authorized (eg, by root license or by hub network configuration). Recording techniques may be used to make non-adaptive copies. Specific examples of the approved recording technology in one specific example include 4C or D-VHS. Once the server makes a non-adaptive copy, the non-adaptive copy cannot be re-bound and the disabled subcopy (without purchasing a new license). Cannot be enabled. Therefore, the server requires confirmation before making a non-adaptive copy. Without the availability of externally adaptable media and approved recording techniques, the server may not create an independent instance on an external storage device. In one embodiment, the user can request the production of non-adaptive copies from independent instances, regardless of the presence of adaptive media (although approved recording techniques are required).
In another embodiment, the server transforms a constrained instance into an independent instance. In this case, the server does not need to make a copy of the constrained instance. Instead, the server appropriately modifies the licensing authority information and license to indicate that the bound instance is now an independent instance.
Also, in another embodiment, the storage client device can change the state of the constrained instance to an independent state. In this case, the client device sends a notification to the server, which disables the source version and all remaining subcopy versions (eg, by sending a disable request to other clients). In an alternative embodiment, the storage client device requires all member devices of the hub network (based on the license of the storage client device) to disable the subcopy content version. In one embodiment, when the client device saves a subcopy version, or other locked content data, the client device has the ability to change the state of the constrained instance to an independent state. ing.
In one embodiment, the server does not release a constrained instance that includes a time constraint on its use within the licensing information. In this case, when the server receives a request to migrate the bound instance to an independent instance, the server rejects the request and the bound instance with the corresponding subcopy version remains enabled. Remain.
In one embodiment, the server makes sure that the constrained instance can be disabled and that the constrained instance can be released before creating an independent instance. That is, the server verifies that the root license of the bound instance gives the server permission to release the bound instance. The server also confirms that the server is not registered in the server's cancellation list. If the server cannot confirm that it is allowed to release the constrained instance, the server will not release the constrained instance.
Content license management The server manages licenses for subcopy versions of bound instances that are bound to the server's hub network. As mentioned above, when the server binds an instance of content to the hub network, the server creates a bound instance with a root license. The server that has the root license for the bound instance is the local licensing authority for that bound instance in the hub network, and the server uses the root license to use that bound instance in the hub network. Controls the licensing of all subcopy versions of.
The adaptive device uses the locked content data of the content instance with a license to, for example, play, copy, or move the locked content data. In one embodiment, a license represents a set of grants defined for a particular locked content data. A license grant indicates a permission to play, copy, and move locked content data based on its type (eg, whether it is an independent instance or a bound instance). In addition, the license can indicate the conditions of permission based on, for example, time (eg, rental period), geographical information (eg, region code), user identity (eg, password), and the like. The license can also be changed or renewed by interaction with the licensing authority (eg, purchase with additional payment for rental). Adaptive devices cannot play locked content data without current, valid, and enabled licenses. If the adaptive device uses the initially locked content data, the adaptive device requests a new license or confirms the license of the locked content data. The server licenses only to member clients of the server's hub network that reside within the local environment of the hub network.
In another embodiment, the server uses an intermediate device (eg, another client device) to license a member client that is disconnected and / or outside the local environment of the hub network. The intermediate device acts as a "conduit" for licensing (similar to adding a remote device to a member as described above). In this case, the server and client are not connected or the client is not in the server's local environment. The intermediate device is connected to both the server and the client (eg, directly or indirectly, or, for example, at different times if the intermediate device is a portable device that moves between the server and the client). The intermediate device passes information between the server and the client, and finally (if the server licenses the client) passes the license from the server to the client.
In one embodiment, a client device can extend the license to other member clients on the same hub network at the time of transfer if both devices are in the same local environment. The extended license is the same (or more restrictive) license as the license held by the extended client device, and the extended client does not extend the license grant. The receiving client renews the license upon receipt. After the extension, both the extended client and the receiving client will have a license.
License renewal The license for the subcopy version of the bound instance has a validity period. When the client receives the license, the client sets an expiration date based on the validity period of the license and the current time of the client's secure clock. For example, for a license with a validity period of 15 days, the client sets the expiration date 15 days after the license is received. If it indicates that the clock has expired, the license will be invalidated. The client periodically renews the license for each subcopy version stored by the client by accessing the server that stores the root license for the subcopy version. When the license is renewed, the client resets the expiration date based on the validity period of the renewed license. If the license is not renewed, the expiration date will not change and therefore the remaining time of validity will continue to decrease until the expiration date is reached. The client also renews all licenses for the subcopy version corresponding to the hub network when the client is reconnected to the hub network.
FIG. 26 shows a flowchart 2600 of a specific example of the process of renewing and renewing the license. First, the client saves a subcopy-locked content data version of the constrained instance. The license for the subcopy version is bound to a particular hub network, so the hub network server manages the bound instance corresponding to the subcopy version stored by the client. When the client receives the subcopy version of the license, the client sets the license expiration date based on the validity period and the time of the client's clock. The client clock is a secure clock and travels at normal speed. If the client does not receive an enabled license for the subcopy, the client requests a new or updated license when it receives the subcopy.
The client requests an updated license from the server in block 2605. The client sends a request to the server to update the hub network in which the subcopy version of the constrained instance is constrained. The client periodically sends an update request to the server, for example, every minute or every hour. In one embodiment, the server or user can adjust the cycle at which the client requests an updated license. In one embodiment, the client requests temporal synchronization from the server before or in addition to requesting an renewed license.
At block 2610, the server receives the request and verifies that the client is properly configured to receive the renewed license. The server must be connected to the client (for example, by issuing an IP packet to the client and pinging the packet to arrive correctly and respond) and be within the local environment of the hub network. To confirm. If the client is not connected or is not in the local environment, the server will not send the renewed license. The server also verifies that the client has the appropriate security software and (eg, key) data. If the client does not have the appropriate security software and data, the server sends the security update information, including the updated software and data, to the client. If the server is unable to send security update information to the client, the server will not send the updated license to the client. Also, if the server does not receive the renewal request, the server will not send the renewed license to the client.
After confirming the client, the server confirms the client's license in block 2615. The server verifies that the client is not on the server's cancellation list. Also, in one embodiment, the server and client exchange and update the revocation list before the server sends a new license to the client. If the client is on the server's revocation list, the server will not send the renewed license. The server checks if the client is still available by checking the root license. If the root license indicates that the license is available to the client, the server sends the updated license to the client. The renewed license does not necessarily have to be the same license stored on the client. The server can update the characteristics of the client's license by sending a different license as the updated license. For example, in one embodiment, the server periodically requests an external licensing authority to renew the license and renews the root license accordingly. In another embodiment, the root license indicates different licensing permits based on, for example, changes in conditions such as time, payment, or client status. As described below, in one embodiment, when a new subcopy version is created, the license for the new subcopy version is disabled and the new device requires a specific new license. The server creates a new license with the root license in response to the initial renewal request for the new subcopy version.
If the root license indicates that the license is not available to the client, the server will not send the updated license to the client. If the root license indicates that the license for the content is no longer valid due to changes in circumstances (for example, due to expiration of rental or non-payment of usage fees), the license will not be available. Also, in one embodiment, the server queries an external licensing authority for some or all renewal requests. In one embodiment, the server sends a message to the client explaining why it is not sending the renewed license.
In another embodiment, the server does not send the renewed license, but instead sends a message or flag indicating whether the license can be renewed or any changes in the license.
At block 2620, the client determines if the server has sent an updated license. When the client disconnects from the server, the server does not respond to the update request and therefore the client does not receive the updated license. In another embodiment, the client checks all responses on the server. In another embodiment, when the client disconnects from the hub network, the client does not send a renewal request and behaves as if it had not received the renewed license. If the server is unavailable or disabled, the server will not send the renewed license. As mentioned above, if the server does not verify the client or license, the client will not be allowed to receive the updated license and the server will not send the updated license.
When the client receives the renewed license, the client renews the license in block 2625. The client replaces the saved license with the updated license. Then, the expiration date is reset by the maximum value of the validity period.
If the client does not receive the renewed license, the client determines in block 2630 whether the license has expired. If the validity period expires without receiving the renewed license, the license will expire. If the client clock indicates that it has expired, the license becomes invalid. In another embodiment, a different mechanism, such as a decremented timer, may be used to determine that the validity period has expired.
If the license expires, the client disables the license in block 2635. When the client disables the license, the client and other adaptive devices will not be able to play its subcopy version. In one embodiment, the client disables the subcopy version by alternative or in addition to, for example, encrypting the subcopy version or removing the subcopy version.
At the next period for requesting a renewed license, the client returns to block 2605. In one embodiment, the client may determine that the license has been revoked regardless of the renewed license request (eg, when the expiration date is between renewed license requests).
In one embodiment, if the client does not receive the renewed license from the server, the client requests a renewed or new license from an external licensing authority. As mentioned above, the server is the local licensing authority defined by the licensing authority information in the header information of the subcopy version. Further, the licensing authority information may indicate an external licensing authority such as a central server connected to a client via a network (for example, the Internet). In one embodiment, the client requests a license from an external agency when the server is unavailable or when the client is not a member of the server's hub network and requires a new license. In another embodiment, the licensing authority information indicates the hierarchy of institutions (eg, local, region, country and absolute).
Specific examples of the process of disconnecting the device from the hub network and the action of the validity period will be described with reference to FIGS. 27 to 29.
In Figure 27, the two media network environments 2700 and 2750 are in different local environments. The local environment is defined in relation to the location of the server (two neighboring servers are treated as defining a local environment that effectively coexists). The dashed line represents the boundary between the local environments. The first media network environment 2700 includes four devices, a server / client device 2705 connected to the terminal device 2710 (for displaying contents), a server device 2715, and a client device 2720. The server / client device 2705 is a server on the hub network HN1 as indicated by the label "HN1 *". The server / client device 2705 and client device 2720 are clients of the hub network HN1, as indicated by the label "HN1". Server device 2715 is a server on the hub network HN2, as indicated by the label "HN2 *". The server / client device 2705 and client device 2720 are clients of the hub network HN2, as indicated by the label "HN2".
Here, two content items A and B are bound to the hub network HN1. Server / client device 2705 stores the source versions of the two content items A and B, respectively, labeled "A" and "B", and manages root obligations. The client device 2720 stores a subcopy version of each of the two content items A and B indicated by the labels "a" and "b".
One content item X is bound to the hub network HN2. Server device 2715 stores the source version indicated by the label "X" and manages the root obligation of content item X. The server / client device 2705 and client device 2720 each store a subcopy version of the content item X indicated by the label "x". Also, the server device 2715 also has the label "<u style="single">Y</u>Saves an independent version of the content item Y indicated by.
The second media network environment 2750 includes one device, the server / client device 2755. The server / client device 2755 is a server on the hub network HN3, as indicated by the label "HN3 *". The server / client device 2755 is a client of the hub network HN3, as indicated by the label "HN3 *".
One content item M is bound to the hub network HN3. Server / client device 2755 stores the source version of content item M, which is labeled "M", and manages root obligations.
In Figure 28, the server / client device 2705 moves to the second media network environment 2750 and becomes a member of the hub network HN3 as a client, as indicated by the label "HN3". The server / client device 2705 remains a client, as indicated by the labels "HN1", "HN2" for both hub networks HN1 and HN2. The server / client device 2705 receives a subcopy version of the content item M indicated by the label "m". The server / client device 2755 joins the hub network HN1 as a client, as indicated by the label "HN1". The server / client device 2755 receives a subcopy version of each of the content items A and B indicated by the label "a" and the label "b".
The server / client device 2705 moves the local environment of the hub network HN1 to the second media network environment 2750 by moving it to the second media network environment 2750. As a result, the client device 2720 is no longer in the local environment of the hub network HN1 and is therefore disconnected from the client device 2720 hub network HN1. When the client device 2720 is disconnected, it will not be possible to renew the licenses for subcopy versions a and b of the two content items A and B, and therefore the label "a".<sup>-15</sup>, "B<sup>-15</sup>The deadline for subcopy versions a and b indicated by "will no longer be reset.
Further, when the server / client device 2705 leaves the media network environment 2700, the server / client device 2705 leaves the local environment of the hub network HN2, so that the server / client device 2705 is disconnected from the hub network HN2. When the server / client device 2705 is disconnected, it will not be possible to renew the license for subcopy version x of content item X, and therefore the label "x".<sup>-15</sup>The subcopy version x expiration date indicated by "will no longer be reset. In addition, the server / client device 2705 is a member of the hub network HN3, and this hub network HN3 is in a different local environment from the hub network HN2. As mentioned above, in one embodiment, if the spanning device is a member of two hub networks in different local environments, the client will see the hub network to which the device was most recently connected, in this case the hub network HN3. Play only the subcopy version from (and the hub network HN1 because the server / client device is the server of the hub network HN1). Therefore, the subcopy version x for content item X has the label "x".<sup>-15</sup>Temporarily disabled until the server / client device 2705 is reconnected to hub network HN2, as indicated by "Cancellation to". In an alternative embodiment, the spanning device client does not temporarily disable the subcopy version from the remote hub network and continues to monitor the lifetime of the unupdated subcopy version, as described above.
In FIG. 29, the server / client device 2705 returns to the first media network environment 2700, is connected to the server device 2715 and the client device 2720, and reconnects to the hub network HN2. As a result, the server / client device 2705 can renew the license for subcopy version x and the client device 2720 can renew the license for subcopy versions a and b, as indicated by the removal of the superscript. Can be done.
When the server / client device 2705 leaves the second media network environment 2750, the server / client device 2705 is disconnected from the hub network HN3 and the server / client device 2755 is disconnected from the hub network HN1. As a result, the server / client device 2705 will not be able to renew the license for subcopy version m, the expiration date will not be reset, and the subcopy version m will be labeled "m".<sup>-15</sup>Temporarily disabled, as indicated by the "Cancellation Line". In addition, the server / client device 2755 cannot renew the license of subcopy versions a and b, and the label "a"<sup>-15</sup>And "b<sup>-15</sup>As indicated by, the deadline will no longer be reset.
Content playback The client device plays or provides the content. Some client devices have built-in playback components that play content data directly. In addition, some client devices reproduce the content data via a connected device such as a terminal device. Also, some client devices reproduce the content data by one or both of the methods described above. The storage client device reproduces the content data by the subcopy stored in the client device or the content data streamed from the server. The non-storage client device plays the content data streamed from the server. In FIG. 17, the dashed line drawn from the server device 1715 to the non-storage client device 1725 shows the streaming of content data from the server device 1715 to the non-storage client device 1725. In one specific example, the displayed content data includes output control information that controls unauthorized copying (for example, data or processing for preventing or suppressing copying of output data). Some servers have both a server function and a client function, and this type of server plays the content as in the case of the client.
FIG. 30 shows a flowchart 3000 of a specific example of a process in which a client device provides content data by a subcopy version stored in the client device. First, the client device is a storage client device that stores a subcopy-locked content data version to be played.
At block 3005, the client receives a request to play the content. The request is issued by the user and specifies an item of content. In other embodiments, the request may be issued from another device or automatically.
The client confirms in block 3010 that the license allows playback of the subcopy version. When the license is renewed, the license may be changed or renewed, so the client checks the license before playing the subcopy version. If the license has expired, is invalid, or has been disabled, the client will not play the subcopy version. In one embodiment, if the client does not have current, valid and enabled licenses, the client requests a new license from the server and the server provides the root license for the corresponding bound instance. To do. If the server rejects this request (for example, because the client does not have the right to obtain a new license), the client will not be able to play the subcopy version.
The client also confirms in block 3015 that the client is not registered in all cancellation lists available to the client. If the client is on the cancellation list, the client does not display the subcopy version.
After checking the license and revocation list, the client plays the subcopy version of the content data in block 3020. The client reproduces the subcopy version of the content by decrypting the locked content data, generates output data, and outputs the output data to an embedded reproduction component, an external reproduction component, or a terminal device.
Adaptive devices play content data from independent instances in a similar manner.
As described above, the server having the client function reproduces the content data by the same method. In another embodiment, the server device and the client device coexist on the same physical device, in which case the server plays the content through the coexisting clients.
FIG. 31 shows a flowchart 3100 of a specific example of the process of streaming content data from the server to the client. First, the server creates a constrained instance of the content, and the client device is connected to the server.
At block 3105, the client receives a request to display the content. The request is issued by the user and specifies an item of content. In other embodiments, the request may be issued from another device or automatically. The client sends a streaming request to the server that manages the constrained instance indicated by the current request. In another embodiment, the server receives a replay request, and the request specifies a client device to replay the content.
At block 3110, the server verifies that the root license allows the content data to be played by streaming the content data to the specified client. When the license is renewed, the license may change or be renewed, so the server checks the license before streaming content data from the source version of its bound instance. If the license has expired, is invalid, or has been disabled, the server will not stream the content data. Also, the server does not stream content data to clients that are not members of the hub network.
The server also confirms in block 3115 that the client is not registered in the revocation list available to the server. If the client is on the available cancellation list, the server will not stream the content data.
After reviewing the license and revocation list, the server streams content data from the source version of its bound instance to the client in block 3120. In one embodiment, the server streams the source version of the locked content data to the client.
When the client receives the streamed content data, the client displays the content data in block 3125. The client does not save the streamed content data (although it may temporarily save the data for the process of displaying the streamed content data). The client reproduces the content data by outputting the content data to a built-in reproduction component, an external reproduction component, or a terminal device.
In another embodiment, the server encrypts locked content data (eg, using encryption techniques for data streaming) and streams the locked and encrypted content data to the client. The client decrypts the locked and encrypted content data, replays the locked content data, and generates output data by decrypting the locked content data. The client plays the output data. As an alternative embodiment, different combinations of encryption and decryption may be used between the server and the client. For example, the server may decrypt the locked content data, generate the output data, and then encrypt the output data. In this case, the server streams the encrypted output data to the client, and the client decrypts the encrypted output data.
In one embodiment, the adaptive device does not store the output data received by the terminal device (except temporarily), and whenever the connection and transmission to the terminal device is sufficiently secure. Data can be output to the connected terminal device. In one embodiment, when an adaptive device transmits output data to a terminal device, the adaptive device transmits the same data to all terminal devices that receive data from the adaptive device.
In one embodiment, the adaptive device streams independent content to other adaptive devices, but the receiving device does not store any of the streamed content data (provided that it is temporary during the playback process). Data may be saved).
The client device does not stream the subcopy version of the content data. In another embodiment, the storage client device streams a subcopy version of the content data to other member clients.
Copying and moving content Adaptive devices can create subcopy versions from source versions or copy subcopy versions. Adaptive devices are free to provide subcopy versions to other members of the hub network. An adaptive device can provide a subcopy version to an adaptive device whose constrained instance is not a member of the hub network to which it is constrained, but a non-member device plays the content data of the subcopy version. Before you can get a new valid license. The adaptive device can provide a subcopy version to the non-adaptive device, but the non-adaptive device cannot play the locked content data of the subcopy version. The non-adaptive device can move the subcopy version to the adaptive device, and the adaptive device can play the subcopy version after obtaining a new valid license. ..
Adaptive devices cannot copy independent instances (except for the process of moving an instance from an independent state to a hub network-bound state). Similarly adaptive devices cannot make backup copies of independent instances. Although an adaptive device can make an independent version of the locked content data of an independent instance (as well as a subcopy version), it can provide that copy to other devices. , The device receiving this must obtain a new valid license before playing the received copy of the locked content data.
The server does not move the source version and root obligations directly to another server. In one embodiment, in order to migrate root obligations from one server to another, the server transforms the constrained instance into an independent instance, migrates the independent instance to another second server, and so on. The second server transforms the independent instance into a constrained instance and establishes a new route. A spanning device is an independent instance of one hub network to another by allowing the server to transfer an independent instance through the spanning device to another adaptive server. Realize the transfer. In another embodiment, the server shifts root obligations directly to other adaptive servers that share a common client device.
The server does not migrate the source version or root obligation to the client (unless the client is also the server).
Adaptive devices can move independent instances using adaptive media, secure transmission, or adaptive recording techniques. As described above for the process of creating an instance independent of a constrained instance, in one embodiment, an adaptive device is adapted by an external medium before moving the independent instance to an external medium. Confirm that it is a medium to have. If an adaptive medium is not available, the adaptive device can use approved recording techniques to make a non-adaptive copy on the non-adaptive medium. Once the adaptive device has made a non-adaptive copy, the non-adaptive copy cannot be re-constrained. Therefore, adaptive devices require confirmation before making a non-adaptive copy. If no external adaptable medium is available and no approved recording technology is available, the adaptable device will not be able to move an independent instance to an external storage device.
The adaptive device supplies a subcopy version to other adaptive devices using secure transmission. As another embodiment, the adaptive device may transmit a subcopy version (without a license or key) over an insecure connection. Also, an adaptive device can use an adaptive physical medium to transfer the subcopy version to another adaptive device based on the constraints described above.
FIG. 32 shows a schematic diagram 3200 of a process of creating a subcopy-locked content data version for a member client. First, the server manages the bound instance of the content and stores the source version and root license of the bound instance. As mentioned above, the server uses the source version to create a subcopy version for the hub network.
At block 3205, the server receives a request to create a subcopy version. The request is issued by the user and specifies the item of content and the client that receives the subcopy version. Instead, the copy request does not have to specify the destination of the new subcopy version (for example, the copy request may follow the request to move the new subcopy version to the destination client). In other embodiments, the request may be issued from another device or automatically. In another embodiment, the client receives a copy request and passes the request to the server. In one embodiment, the copy request specifies the target resolution. If the target resolution is different from the resolution of the source version (or the subcopy version being copied), the conversion can be performed using the source version (or the subcopy version being copied) as the highest resolution copy in the hub network. .. In another embodiment, the copy request specifies the target format. The server may perform any transcoding with the subcopy version or source version to be copied as part of the copy process. Alternatively, the target resolution and target format may be converted and transcoded as requested by the client for reproduction.
The server verifies that in block 3210 it allows the licensed client to provide the subcopy version. When the license is renewed, the license may be changed or renewed, so the server checks the license before creating the subcopy version. If the license is invalid or disabled, the server will not create a subcopy version. In other embodiments, as described below, the server does not verify the license before creating the subcopy version. Instead, the server checks the license when it creates a new license for the subcopy version.
The server also confirms that the client is not registered in the server's cancellation list in block 3215. If the client is on the revocation list, the server does not create a subcopy version.
After checking the license and revocation list, the server creates a subcopy version in block 3220. The server creates a new subcopy version from the source version and saves the new subcopy version on the server. As shown in FIG. 23, the server creates a subcopy version of the locked content data 2355 from the source version of the locked content data 2310. The server also copies the header information including the licensing authority information. The server does not copy the root license, the key to unlock the locked content data, or the revocation list of the source version. The server creates a new subcopy license for the subcopy version based on the root license. However, the license for the new subcopy version is initially disabled. To enable a license or receive a new license, the receiving client accesses the server, renews the license, and receives a new license specific to the new subcopy version. In one embodiment, the server provides an enabled license with a new subcopy version. When the server provides the license to the client, the server provides a key to unlock the subcopy version and a revocation list based on the server's revocation list.
After creating the new subcopy version, the server moves the new subcopy version to the destination client in block 3225. In one embodiment, in order to move a new subcopy version, the server sends another copy of the new subcopy version and any associated data (eg, license) to the client, the first on the server. Remove the new subcopy version of. The client receives and saves the new subcopy version. In another embodiment, the server creates a new subcopy version directly on the client and therefore skips block 3225. In another embodiment, the server later creates and provides a subcopy license in response to a new license request from the client.
In another embodiment, the root license allows the creation of a limited number of subcopy versions. In this case, the server counts the number of subcopy versions created (for example, by counting the number of times a subcopy license is created from the root license) and stores the copy count in the root license. When this copy count reaches the limit, the server does not create any more subcopy versions from the source version of the constrained instance. The value of this copy count can also be decremented if the server has knowledge of deletion or disabling by deleting or disabling the subcopy version in the hub network.
In another embodiment, the number of licenses held by the client may be limited. When a client receives a new subcopy version and subcopy license (by copy or move), the client checks to see if the number of licenses has reached the maximum number of licenses for the client. If the number of licenses has reached the maximum number of licenses, the client disables the new subcopy version of the license until the other licenses are disabled, thereby maximizing the number of licenses. Make it as follows.
In one embodiment, the storage client device can also make a copy of the subcopy version stored on the client. In this case, the storage client device creates a subcopy version as described for the server with reference to FIG.
In one embodiment, the request to move the subcopy version is processed in a similar manner. The server or client receives the request and confirms that the license allows the subcopy version to be moved to the specified client. Further, the server or client confirms that the client is not registered in the server or client's cancellation list. If this verification is successful, the server or client moves the subcopy version and all corresponding data (eg, license) to the designated client.
In another embodiment, the client may move and copy the subcopy version without confirmation, except that the license is not moved or copied. Similarly, the server may create and deliver a subcopy version without first checking the root license and revocation list, in which case the server and client have adaptive devices and adaptability. Unlimited delivery of subcopy versions to non-devices. A non-adaptive device cannot play the locked content data, but a subcopy version can be passed to the adaptive device. The receiver-adaptive device will be able to play the locked content data of the subcopy version after obtaining the license (eg, indicated by the licensing authority information in the header of the subcopy version). In another embodiment, the client can move a copy of the license and provide the license to the disconnected member client.
When a server or client provides a subcopy version to an adaptive device that is not a member of the hub network, the server or client does not provide a valid license for the subcopy version. The recipient later obtains a valid license using the licensing authority information stored in the subcopy version. Devices with such adaptability can deliver subcopy versions to other hub networks.
In an alternative embodiment, the local environment is defined in absolute terms, for example, inside a circle with a radius of 100 m, centered on a defined geographical point. Media may be restricted to use in a particular physical location, for example, confidential documents that are restricted to viewing within a particular building. As mentioned above, when the device leaves the local environment, the device disconnects from the hub network (the device may remain as a member). In this case, the server may be disconnected from its own hub network, and all devices including the server cannot renew the hub network license while the server is disconnected. In other alternative embodiments, the hub network is not restricted by the local environment. In this case, if the device cannot communicate with the server (for example, if the physical or network connection has failed), the device cannot renew its license.
The present invention can be realized in various forms by means of electronic hardware, computer software, or a combination of these technologies. Many embodiments include one or more computer programs executed by a programmable computer. For example, as shown in FIG. 17, in one specific example, each of the server / client device 1705, server device 1715, storage client device 1720, and non-storage client device 1725 is software for realizing the above-mentioned client and server operations. Equipped with one or more computers to run. Typically, each computer has one or more processors and one or more data storage devices (eg, volatile or non-volatile memory modules, such as hard disk drives, floppy disk drives, CD-ROM drives, magnetic tape drives, etc. It comprises an optical and magnetic recording device), one or more input devices (eg, a mouse and a keyboard), and one or more output devices (eg, a display and a printer). In some embodiments, the computer is contained within a consumer electronic device.
Computer programs are typically recorded on a persistent storage medium and contain executable code that is copied into memory at run time. The processor executes this code by reading the instructions from memory in a predetermined order. When executing the program code, the computer receives data from the input device and / or the storage device, processes the data, and supplies the processed data to the output device and / or the storage device.
Although various embodiments of the present invention have been described, those skilled in the art can conceive of embodiments other than those described above without departing from the scope of the present invention. Some implementations may not necessarily include all and / or variations of the aspects described above. For example, the present invention has been described here with a focus on an example of application to copying content that is audio and / or video data, but for copying other types of data, such as numerical data or executable software code. The present invention can also be applied.
Therefore, the present invention is not limited to the above-described embodiments.
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| JP2001285283A | Cites | Japan | Examiner |
| JP2001519562A | Cites | Japan | Examiner |
| JP2002033724A | Cites | Japan | Examiner |
| JP2004534291A | Cites | Japan | Examiner |
| JP2004535623A | Cites | Japan | Examiner |
| JP2005129058A | Cites | Japan | Search report |
| JP2005514716A | Cites | Japan | Search report |
| JP2007312328A | Cites | Japan | Search report |
| JP2009529177A | Cites | Japan | Search report |
88 members in 8 offices
Priority claims35
| Document | Office | Kind | Date |
|---|---|---|---|
| 43477402 | United States of America | P | |
| 43477402 | United States of America | P | |
| 60434774 | United States of America | – | |
| 47182303 | United States of America | P | |
| 47182303 | United States of America | P | |
| 60471823 | United States of America | – | |
| 10686686 | United States of America | – | |
| 10686954 | United States of America | – | |
| 10686955 | United States of America | – | |
| 10686956 | United States of America | – | |
| 10687357 | United States of America | – | |
| 68668603 | United States of America | A | |
| 68668603 | United States of America | A | |
| 68695403 | United States of America | A | |
| 68695403 | United States of America | A | |
| 68695503 | United States of America | A | |
| 68695503 | United States of America | A | |
| 68695603 | United States of America | A | |
| 68695603 | United States of America | A | |
| 68735703 | United States of America | A | |
| 68735703 | United States of America | A | |
| 2002434774 | – | – | – |
| 2003471823 | – | – | – |
| 2003686686 | – | – | – |
| 2003686954 | – | – | – |
| 2003686955 | – | – | – |
| 2003686956 | – | – | – |
| 2003687357 | – | – | – |
| US20020434774P | – | – | – |
| US20030471823P | – | – | – |
| US20030686686 | – | – | – |
| US20030686954 | – | – | – |
| US20030686955 | – | – | – |
| US20030686956 | – | – | – |
| US20030687357 | – | – | – |
Members88
| Document | Office | Kind | |
|---|---|---|---|
| US2004117440A1 | United States of America | A1 | |
| US2004117483A1 | United States of America | A1 | |
| US2004117484A1 | United States of America | A1 | |
| US2004117619A1 | United States of America | A1 | |
| US2004117643A1 | United States of America | A1 | |
| WO2004057872A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2003301067A1 | Australia | A1 | |
| AU2003301067A8 | Australia | A8 | |
| US2004139022A1 | United States of America | A1 | |
| WO2004059559A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU2003301022A1 | Australia | A1 | |
| AU2003301022A8 | Australia | A8 | |
| WO2004059559A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1574062A2 | European Patent Office (EPO) | A2 | |
| EP1579693A1 | European Patent Office (EPO) | A1 | |
| KR20050112076A | Republic of Korea | A | |
| KR20050118158A | Republic of Korea | A | |
| CN1754387A | China | A | |
| JP2006514506A | Japan | A | |
| CN1817039A | China | A | |
| JP2006521713A | Japan | A | |
| EP1574062B1 | European Patent Office (EPO) | B1 | |
| DE60311874D1 | Germany | D1 | |
| US7203965B2 | United States of America | B2 | |
| KR20070040416A | Republic of Korea | A | |
| KR20070040417A | Republic of Korea | A | |
| KR20070050480A | Republic of Korea | A | |
| KR20070050481A | Republic of Korea | A | |
| US2007143782A1 | United States of America | A1 | |
| DE60311874T2 | Germany | T2 | |
| CN100459699C | China | C | |
| EP1579693B1 | European Patent Office (EPO) | B1 | |
| EP2028860A1 | European Patent Office (EPO) | A1 | |
| DE60326279D1 | Germany | D1 | |
| CN100539681C | China | C | |
| KR20100003303A | Republic of Korea | A | |
| US2010005172A1 | United States of America | A1 | |
| KR20100004117A | Republic of Korea | A | |
| CN101635625A | China | A | |
| CN101635626A | China | A | |
| CN101635725A | China | A | |
| KR100950354B1 | Republic of Korea | B1 | |
| JP2010093853A | Japan | A | |
| KR100956184B1 | Republic of Korea | B1 | |
| JP2010136391A | Japan | A | |
| JP2010146574AThis record | Japan | A | |
| JP2010148116A | Japan | A | |
| KR100969511B1 | Republic of Korea | B1 | |
| KR100969721B1 | Republic of Korea | B1 | |
| CN101778096A | China | A | |
| US7784100B2 | United States of America | B2 | |
| KR100997569B1 | Republic of Korea | B1 | |
| KR20100126865A | Republic of Korea | A | |
| JP2011003205A | Japan | A | |
| KR101014912B1 | Republic of Korea | B1 | |
| JP4637742B2 | Japan | B2 | |
| EP2290973A2 | European Patent Office (EPO) | A2 | |
| EP2290974A2 | European Patent Office (EPO) | A2 | |
| EP2290975A2 | European Patent Office (EPO) | A2 | |
| EP2290976A2 | European Patent Office (EPO) | A2 | |
| EP2312848A2 | European Patent Office (EPO) | A2 | |
| US7934263B2 | United States of America | B2 | |
| KR101031161B1 | Republic of Korea | B1 | |
| KR101035166B1 | Republic of Korea | B1 | |
| CN101635626B | China | B | |
| US8011015B2 | United States of America | B2 | |
| US2011231941A1 | United States of America | A1 | |
| KR101077751B1 | Republic of Korea | B1 | |
| EP2312848A3 | European Patent Office (EPO) | A3 | |
| CN101635625B | China | B | |
| EP2028860B1 | European Patent Office (EPO) | B1 | |
| EP2290975A3 | European Patent Office (EPO) | A3 | |
| EP2290976A3 | European Patent Office (EPO) | A3 | |
| US8191154B2 | United States of America | B2 | |
| EP2290973A3 | European Patent Office (EPO) | A3 | |
| EP2290974A3 | European Patent Office (EPO) | A3 | |
| US8230084B2 | United States of America | B2 | |
| JP5021800B2 | Japan | B2 | |
| JP5026501B2 | Japan | B2 | |
| CN101635725B | China | B | |
| JP2013042554A | Japan | A | |
| JP5266198B2 | Japan | B2 | |
| JP5301422B2 | Japan | B2 | |
| US8589546B2 | United States of America | B2 | |
| EP2312848B1 | European Patent Office (EPO) | B1 | |
| JP5438494B2 | Japan | B2 | |
| US2014344870A1 | United States of America | A1 | |
| US9813756B2 | United States of America | B2 |
11 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelR150 | R150 | |
| First payment of annual fees (during grant procedure)A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)A01 | A01 | |
| Written decision to grant a patent or to grant a registration (utility model)A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedA521 | A521 | |
| Written permission of extension of timeA602 | A602 | |
| Written request for extension of timeA601 | A601 | |
| Notification of reasons for refusalA131 | A131 |
Numbers
- Publication
- 2010146574
- Publication, DOCDB
- 2010146574
- Publication, EPODOC
- JP2010146574
- Application
- 290662
- Application, DOCDB
- 2009290662
- Application, EPODOC
- JP20090290662
Titles2
- Japanese
- メディアネットワーク環境におけるコンテンツの状況
- English
- Content status in a media network environment
Classification
- CPC, 10
- H04N21/4147
- G06F21/10
- H04L12/28
- H04N21/43615
- H04N21/4627
- H04L2463/103
- H04L65/611
- H04L67/568
- H04N21/6332
- H04N21/441
- IPC, 7
- G06F13 00
- H04N7 173
- H04N5 765
- G06F21 24
- H04L12 28
- H04N5 00
- H04N7 24