Method and apparatus for access control in an overlapping multiserver network environment
Abstract
Methods and apparatus for managing devices and content in a network environment. In one implementation, a network media environment includes: a first hub network including a first server and a first client, and said first server is connected to said first client; a second hub network including a second server and said first client, and said second server is connected to said first client, such that said first hub network and said second hub network overlap;wherein said first client stores first content bound to said first hub network and stores second content bound to said second hub network.
Term
Projected expiry 22 December 2029.
- Priority
- Filed
- Granted
- Today
- Projected expiry
19 claims: 11 independent, 8 dependent
- 1In the client addition method of adding a client as a member of the hub networkThe serverOf the above hub networkTheSteps to detect clients connected to the server,The above serverSteps to authenticate the above client and The steps that the above server communicates with the external device registration server, The step that the above device registration server compares the number of devices already added to the hub network with the device limit, The number of devices already added to the hub network is larger than the device limit, less than the maximum number of devices added to the hub network, and the client is not registered in another hub network. If the above device registration server is the above server,Add the above client as a member of the above hub networkDecide thatWith steps、HaveAnd In the hub network, the server is characterized in that it provides a license for content data bound to the hub network only to one or more clients added as members of the hub network.How to add a client. ハブネットワークのメンバとしてクライアントを加えるクライアント追加方法において、サーバが、上記ハブネットワークの該サーバに接続されたクライアントを検出するステップと、上記サーバが、上記クライアントを認証するステップと、 上記サーバが、外部のデバイス登録サーバと通信を行うステップと、 上記デバイス登録サーバが、既にハブネットワークに加えられているデバイス数とデバイス制限数とを比較するステップと、 上記既にハブネットワークに加えられているデバイス数が、上記デバイス制限数より大きく、さらに、上記ハブネットワークに追加されるデバイスの最大数より小さく、かつ、上記クライアントが他のハブネットワークに登録されていない場合、上記デバイス登録サーバは、上記サーバが、上記クライアントを上記ハブネットワークのメンバとして加えることを決定するステップと、を有し、 上記ハブネットワークにおいて、上記サーバは、上記ハブネットワークに拘束されたコンテンツデータに関するライセンスを上記ハブネットワークのメンバとして加えられた一又は二以上のクライアントのみに提供することを特徴とするクライアント追加方法。
- 8Claim that the local environment is a limited area defined in relation to the server.7How to add a client as described. 上記ローカル環境は、上記サーバに関連して定義された限定的な領域であることを特徴とする請求項7記載のクライアント追加方法。
- 9The presence of the client in the local environment is confirmed based on the time it takes for the server to send an inspection message to the client, send the inspection message, and receive a response from the client.Claims7How to add a client as described. 上記クライアントがローカル環境内にあることは、上記サーバが検査メッセージを上記クライアントに送信し、該検査メッセージを送信してから応答を該クライアントから受信するまでの時間に基づいて確認されることを特徴とする請求項7記載のクライアント追加方法。
- 12Claim that further has a step of incrementing the number of devices after adding the client as a member.2How to add a client as described. 上記クライアントをメンバとして加えた後に、上記デバイス数をインクリメントするステップを更に有する請求項2記載のクライアント追加方法。
- 13The above serverA claim further comprising a step of sending a device addition request to the device registration server and receiving a device addition permission from the device registration server.1How to add a client as described. 上記サーバが、上記デバイス登録サーバにデバイス追加要求を送信し、該デバイス登録サーバからデバイス追加許可を受信するステップを更に有する請求項1記載のクライアント追加方法。
- 14The above clientIsThe client is installed on the above server.To add to membersClaims having additional steps to submit additional requests1How to add a client as described. 上記クライアントは、上記サーバに、該クライアントをメンバに加えるための追加要求を送信するステップを更に有する請求項1記載のクライアント追加方法。
- 15The above clientBut,Claims further including a step of connecting to the server1How to add a client as described. 上記クライアントが、上記サーバに接続するステップを更に有する請求項1記載のクライアント追加方法。
- 16The above clientBut,It further has a step of transmitting adaptive information indicating that the client is an adaptive device to the server, and the adaptive device is sent to a hub network of which the adaptive device is a member. A claim characterized in that the locked content data is not decrypted without a bound license.1How to add a client as described. 上記クライアントが、上記サーバに、該クライアントが適応性を有するデバイスであることを示す適応性情報を送信するステップを更に有し、 上記適応性を有するデバイスは、該適応性を有するデバイスがメンバであるハブネットワークに拘束されたライセンスなしでは、ロックされたコンテンツデータを復号しないことを特徴とする請求項1記載のクライアント追加方法。
- 17The above clientBut the clientA claim further comprising a step of examining the cancellation list stored in the, and determining whether the client is registered in the cancellation list.1How to add a client as described. 上記クライアントが、該クライアントに保存されている取消リストを調べ、該クライアントが該取消リストに登録されているか否かを判定するステップを更に有する請求項1記載のクライアント追加方法。
- 18In the client addition method of adding a client as a member of the hub networkThe serverOf the above hub networkTheSteps to authenticate the client through an intermediate device connected to the server, The steps that the above server communicates with the external device registration server, The step that the above device registration server compares the number of devices already added to the hub network with the device limit, The number of devices already added to the hub network is larger than the device limit, less than the maximum number of devices added to the hub network, and the client is not registered in another hub network. If the above device registration server is the above serverAdd the client as a member to the hub network via the intermediate deviceDecide thatHave steps and In the hub network, the server provides a license for content data bound to the hub network only to one or more clients added as members of the hub network. The client addition method, characterized in that the above client is not connected to the above server. ハブネットワークのメンバとしてクライアントを加えるクライアント追加方法において、サーバが、上記ハブネットワークの該サーバに接続された中間装置を介してクライアントを認証するステップと、 上記サーバが、外部のデバイス登録サーバと通信を行うステップと、 上記デバイス登録サーバが、既にハブネットワークに加えられているデバイス数とデバイス制限数とを比較するステップと、 上記既にハブネットワークに加えられているデバイス数が、上記デバイス制限数より大きく、さらに、上記ハブネットワークに追加されるデバイスの最大数より小さく、かつ、上記クライアントが他のハブネットワークに登録されていない場合、上記デバイス登録サーバは、上記サーバが上記中間装置を介して上記クライアントをメンバとして上記ハブネットワークに加えることを決定するステップとを有し、 上記ハブネットワークにおいて、上記サーバは、上記ハブネットワークに拘束されたコンテンツデータに関するライセンスを上記ハブネットワークのメンバとして加えられた一又は二以上のクライアントのみに提供し、 上記クライアントは、上記サーバに接続されていないことを特徴とするクライアント追加方法。
- 19The claim is characterized in that the client is not in the local environment of the server, and the local environment is a limited area defined in relation to the server.18How to add a client as described. 上記クライアントは、上記サーバのローカル環境になく、該ローカル環境は、該サーバに関連して定義された限定的な領域であることを特徴とする請求項18記載のクライアント追加方法。
Independent claims11
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 num="0004"> 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 num="0005"> 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 num="0006"> 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 num="0007"> 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 num="0008"> 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 num="0009"> 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 num="0010"> 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 num="0011"> 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 num="0012"> 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 num="0013"> 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 num="0014"> 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, and 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 num="0015"> 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 num="0016"> 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 num="0017"> 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 num="0018"> 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 num="0019"> 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 num="0020"> 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 num="0021"> A constrained instance of the content according to the invention is a source-locked content data stored on a server that is a member of the hub network and a source key for decrypting the source-locked content data stored on the server. The root license has the root license stored in the server and the licensing authority 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 num="0022"> 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 num="0023"> 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 num="0024"> 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 num="0025"> 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 num="0026"> 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 num="0027"> 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 num="0028"> 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 server to 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 num="0029"> 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 num="0030"> 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 server 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 num="0031"> 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 num="0032"> 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 of binding 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 a 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 process of disconnecting a device from a hub network, and the action of the validity period.</figref><figref num="28">It is a figure explaining the specific example of the process of disconnecting a device from a hub network, and the action of the validity period.</figref><figref num="29">It is a figure explaining the specific example of the process of disconnecting a device from a hub network, and the action of the 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 an instance of content 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 permission to use content data, for example, permitting 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 movie video 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 an adaptive device. 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, that is, 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 to 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. PVR105 is also an independent version of TV show 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 PVR 105 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 disc into the server device of the car 120, which constrains the car 120 to an independent instance of the movie X on the hub network HN2. Car 120 creates a captive instance of Movie X and stores the locked content data and the source version of the root license as part of the captive instance in the storage device of 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 bound 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. Jim also purchases an instance with the adaptability of Song Y and downloads it from network 115, which causes car 120 to constrain this instance to 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 the recorded television show 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 its physical location to the PVR105, or if the vehicle 120 reports a physical location outside the boundaries of the home media network environment 100 to the PVR105, the PVR105 will be a server for 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, as a client of hub network HN2, PVR105 monitors the lifetime of subcopy versions received through hub network HN2 (labeled "x" on PVR105.<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 adaptive 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 the 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 car 120 returns to the local environment of the PVR105 and returns the local environment of the car 120 to the PVR105 and the television 125.
When car 120 is reconnected to PVR105, PVR105 resets the validity period of subcopy version a of movie A stored in car 120 as a server of hub network HN1 (car 120 label "a".<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 either an application), a hardware component, 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 (based on license requests, such as renewals, as described below). 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, it 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. Storage client device 1720 includes a storage device for storing subcopy versions of 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 content data provided. 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 adaptive 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 an 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 a number of devices that are incremented 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 (eg, 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 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 a client is deleted, the adaptive client device has a subcopy version stored on the client and all licenses for the bound instance that the client is bound to the deleted hub network. 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 the client device 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 disconnect and reconnect 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 untouched, 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.
The client periodically checks in block 2020 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, so non-adaptive or adaptive devices are (other than present in the instance or copy). It is possible to play content data of an instance or copy that is not adaptable (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 the copy control information recognized by the adaptive device and is adaptable if it is certified for use in the 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 games or video games). 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 the adaptive device 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). Also,License 2230 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.
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, 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. .. 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.
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. The licensing authority data for header information 2360 includes an external licensing authority (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 revocation 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 content encryption methods. 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 the 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, an independent instance can have a variety of formats, eg, via 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 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 regarding 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 authority information in the broadcast information to access an external licensing authority 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 license-granting institution information in the broadcast information to access an external license-granting institution and obtain a license to make a route 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 is sub-registered by registering the bound instance as disabled by a central database or institution (eg, checking before the device plays or provides a sub-copy version). Make the copy version disabled. At this time, if the client is disconnected from the hub network, the server will have the client device
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 a separate instance within the internal storage device, or the server is approved (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 disables the constrained instance and ensures 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 (for example, rental period), geographical information (for example, region code), user identity (for example, 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 first 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 client can use the license, 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 renewed 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 client is not available, 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 operation 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 servers (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, labeled "A" and "B", respectively, 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". 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 An adaptive device can create a subcopy version from the source version, or can copy a subcopy version. 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 to which the constrained instance is not a member of the hub network to which it is constrained, but a non-member device plays the subcopy version of the content data. 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 a subcopy version to another adaptive device based on the constraints described above.
FIG. 32 shows a flowchart 3200 of a specific example of the 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 made 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 a 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, a 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 license is 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 specified 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 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 |
|---|---|---|
| JP2000188725A | Cites | Japan |
| JP2001285284A | Cites | Japan |
| JP2002198957A | Cites | Japan |
| JP2002300162A | Cites | Japan |
| JP2002369169A | Cites | Japan |
| JP2002539724A | Cites | Japan |
| JP9331342A | Cites | Japan |
| WO0230054A1 | Cites | World Intellectual Property Organization (WIPO) |
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 | |
| JP2010146574A | 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 | |
| JP5301422B2This record | 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 |
9 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 | |
| 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 | |
| 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
- 5301422
- Publication, DOCDB
- 5301422
- Publication, EPODOC
- JP5301422B
- Application
- 290661
- Application, DOCDB
- 2009290661
- Application, EPODOC
- JP20090290661
Titles2
- Japanese
- ハブネットワークにおけるクライアント追加方法
- English
- How to add a client in a hub network
Classification
- CPC, 10
- H04N21/4147
- G06F21/10
- H04L12/28
- H04N21/43615
- H04N21/4627
- H04L2463/103
- H04L65/611
- H04L67/568
- H04N21/6332
- H04N21/441
- IPC, 5
- H04N7 173
- G06F21 62
- H04L12 28
- H04N5 00
- H04N7 24