| Title of Invention | "A MOBILE PHONE,A METHOD OPERATIONAL IN A MOBILE PHONE,A CONTENT PROVIDER AND A METHOD OPERATIONAL AT A CONTENT PROVIDER" |
|---|---|
| Abstract | A mobile phone comprising: a symmetric key (120); a processor (114); and control logic (110) executable by the processor (114) and configured to: receive non-requested encrypted content from a content provider via a broadcast transmission, wherein the encrypted content is received from the content provider using spare broadcast capacity; send a request to the content provider to access the previously received encrypted content, wherein the request includes a terminal identifier and a result of a cryptographic function having the symmetric key (120) and the encrypted content as inputs, the terminal identifier allowing the content provider to identify the symmetric key (120) associated with the mobile phone; receive a content key secured by the symmetric key (120) from the content provider if the content provider successfully verifies based on the request that the encrypted content has been correctly received by the mobile phone, the content key secured by the symmetric key (120) being an encrypted content key; decrypt the encrypted content key using the symmetric key (120); and decrypt the encrypted content using the content key. |
| Full Text | information to the terminal 102 so as to allow the terminal 102 to derive the content 108. The terminal 102 may then store the content 108 for future consumption by a user. The terminal 102' and the broadcast service provider 104 both have knowledge of a valid authentication symmetric key BK 120. The authentication symmetric key BK 120 is uniquely associated with the terminal 102 and its value is known only to the terminal 102 and the broadcast service provider 104. The authentication symmetric key BK 120 is used to facilitate user access to the content 108 stored on the terminal 102, as will be further described below. It should be understood that the broadcast service provider 104 is shown herein for illustrative purposes and may include any device or entity that is capable of delivering contents to another device or entity. [0022] Before the content 108 stored at the terminal 102 can be accessed, the content 108 is first provided by the broadcast service provider 104 to the terminal 102 as follows. Let the content 108 be denoted as "C". FIG. 2 illustrates the logic flow of operations of the broadcast service provider 104 with respect to providing the content 108 to the terminal 102. At block 200, the broadcast service provider 104 encrypts the content 108 using a randomly generated content key denoted as "K". The encrypted content 108 is denoted as "EK{C}". At block 202, the broadcast service provider 104 also assigns identifier IDC to the content 108. IDC identifies the content C. At block 204, the encrypted content EK{C} and the associated identifier 1DC are then transmitted by the broadcast service provider 104 to the terminal 102. Upon receipt, the terminal 102 stores the encrypted content EK{C} and the associated identifier IDC for subsequent access. As will be further described below, the content 108 can be derived from the encrypted content EK{C}. It should be noted that different content files may be encrypted with different randomly generated content keys. Alternatively, files might be grouped and encrypted with the same key. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate how to encrypt content files according to the present disclosure. [0023], Assuming that the content 108 has never been accessed or the plaintext version of the content 108 is no longer available on the terminal 102 (which means only the encrypted content EK(C) is accessible), the terminal 102 derives and accesses the content 108 as follows. FIG. 3 illustrates the logic flow of operations between the terminal 102 and the broadcast service provider 104 to effect content derivation and access. FIG. 4 further illustrates the logic flow of operations performed by the terminal 102 to effect content derivation and access. It should be noted that the operations performed by the terminal 102 and broadcast service provider 104 can be carried out by their respective control logic 110 and 118. [0024] First, at block 300, the terminal 102 identifies itself to the broadcast service provider 104 and requests access to the content 108 by forwarding a request to the broadcast service provider 104. Via the request, the terminal 102 also certifies to the broadcast service provider 104 that the terminal 102 actually has the content 108. The certification is performed to ensure that a user cannot subsequently deny that the content 108 was not successfully downloaded at the terminal 102. Referring to FIG. 4, in order to effect the foregoing certification, at block 400, the terrninal 102 generates the request. The request includes a terminal identifier EDT that identifies the terminal's 102 identity, the content identifier IDC and a cryptographic function F(BK, EK{C}) which accepts the authentication symmetric key BK 120 and the encrypted content EK{C} as inputs. The cryptographic function F can be either a collision-resistant hash function such as SHA-1 or an encryption function F(K,M) =EK{M}, where M is an input parameter. At block 402, the terminal 102 transmits the request to the broadcast service provider 104. At block 404, the terminal 102 waits to see if the request has been successfully verified by the broadcast service provider 104. [0025] Referring back to FIG. 3, at block 302, upon receiving the request from the terminal 102, the broadcast service provider 104 verifies the information that was received and logs any appropriate information. By examining the information contained in the request including the terminal's identifier IDT, the content identifier IDc and the cryptographic function F(BK, EK(CJ), the broadcast service provider 104 is able to determine that the terminal 102 correctly received the previously forwarded encrypted content EK(C}. At block 304, the broadcast service provider 104 determines if the verification is successful. At block 312, if the verification is not successful, then the broadcast service provider 104 invokes an error routine. The error routine may include, for example, forwarding an error message or notification to the terminal 102. Referring back to FIG. 4, at block 406, when the terminal 102 receives the. error message or notification, it takes appropriate corrective action, if any. WE CLAIM: 1. A mobile phone comprising: a symmetric key (120); a processor (114); and control logic (110) executable by the processor (114) and configured to: receive non-requested encrypted content from a content provider via a broadcast transmission, wherein the encrypted content is received from the content provider using spare broadcast capacity; send a request to the content provider to access the previously received encrypted content, wherein the request includes a terminal identifier and a result of a cryptographic function having the symmetric key (120) and the encrypted content as inputs, the terminal identifier allowing the content provider to identify the symmetric key (120) associated with the mobile phone; receive a content key secured by the symmetric key (120) from the content provider if the content provider successfully verifies based on the request that the encrypted content has been correctly received by the mobile phone, the content key secured by the symmetric key (120) being an encrypted content key; decrypt the encrypted content key using the symmetric key (120); and decrypt the encrypted content using the content key. 2. The mobile phone as claimed in claim 1, wherein the control logic (110) is further configured to store one or more access conditions in a memory (116) and allow a user to access the decrypted content in accordance with the one or more access conditions. 3. The mobile phone as claimed in claim 2, wherein the control logic (110) is further configured to include payment control logic configured to charge the user for access to the decrypted content. 4. A method operational in a mobile phone for use in authentication between a content provider and the mobile phone, the method comprising: receiving via a transceiver (112) non-requested encrypted content from a content provider via a broadcast transmission, wherein the encrypted content is received from the content provider using spare broadcast capacity; sending via the transceiver (112) a request to the content provider to access the previously received encrypted content, wherein the request includes a terminal identifier and a result of a cryptographic function having a symmetric key (120) and the encrypted content as inputs, the terminal identifier allowing the content provider to identify the symmetric key (120) associated with the mobile phone; receiving via the transceiver (112) a content key secured by the symmetric key (120) from the content provider if the content provider successfully verifies based on the request that the encrypted content has been correctly received by the mobile phone, the content key secured by the symmetric key (120) being an encrypted content key; decrypting at a processor (114) the encrypted content key using the symmetric key (120); and decrypting at the processor (114) the encrypted content using the content key. 5. The method as claimed in claim 4, further comprising: avoiding the involvement of a trusted third party in successfully verifying based on the request that the encrypted content has been correctly received by the mobile phone. 6. The method as claimed in claim 4, further comprising: receiving via the transceiver (112) the encrypted content at the mobile phone via a broadcast transmission capable of being received by a plurality of mobile phones that can each independently request access to the encrypted content using another symmetric key uniquely known to each of the plurality of mobile phones and the content provider. 7. The method as claimed in claim 4, further comprising: storing in a memory (116) one or more access conditions associated with the content; and allowing a user to access the decrypted content based on the one or more access conditions. 8. A method operational at a content provider for securely broadcasting content, the method comprising: encrypting content with a content key at a control logic (118) to generate encrypted content; broadcasting the encrypted content using the control logic (118) to at least one client without receiving a request for the encrypted content from the client, wherein the encrypted content is broadcast to the client using spare broadcast capacity; receiving via the control logic (118) a request from the client to access the previously broadcast encrypted content, the request including a terminal identifier and a result of a cryptographic function having a symmetric key (120) associated with the client and the encrypted content as inputs, the terminal identifier allowing the content provider to identify the symmetric key (120) associated with the client; examining at the control logic (118) the request to verify that the client has correctly received the encrypted content; and forwarding a content key secured by the symmetric key (120) from the control logic (118) of the content provider to the client in response to successful verification of the request. 9. The method as claimed in claim 8, further comprising: collecting payment at the control logic (118) from the client for accessing the content. 10. The method as claimed in claim 8, further comprising: sending via the control logic (118) one or more access conditions for the content to the client. 11. A content provider, comprising: a symmetric key (120); and a control logic (118) configured to: encrypt content using a content key to generate encrypted content; broadcast the encrypted content to at least one client without receiving a request for the encrypted content from the client, wherein the encrypted content is broadcast to the client using spare broadcast capacity; receive a request from the client to access the previously broadcast encrypted content, the request including a terminal identifier and a result of a cryptographic function having a symmetric key (120) associated with the client and the encrypted content as inputs, the terminal identifier allowing the content provider to identify the symmetric key (120) associated with the client; examine the request to verify that the client has correctly received the encrypted content; and forward a content key secured by the symmetric key (120) from the content provider to the client in response to successful verification of the request. 12. The content provider as claimed in claim 11, wherein the control logic (118) is further configured to: collect payment from the client for accessing the content. 13. The content provider as claimed in claim 11, wherein the control logic (118) is further configured to: send one or more access conditions for the content to the client. 14. An apparatus, comprising: means for encrypting (118) content using a content key to generate encrypted content; means for broadcasting (118) the encrypted content to at least one client without receiving a request for the encrypted content from the client, wherein the encrypted content is broadcast to the client using spare broadcast capacity; means for receiving (118) a request from the client to access the previously broadcast encrypted content, the request including a terminal identifier and a result of a cryptographic function having a symmetric key (120) associated with the client and the encrypted content as inputs, the terminal identifier allowing the apparatus to identify the symmetric key (120) associated with the client; means for examining (118) the request to verify that the client has correctly received the encrypted content; and means for forwarding (118) a content key secured by the symmetric key (120) from the apparatus to the client in response to successful verification of the request. 15. The apparatus as claimed in claim 14, further comprising: means for collecting payment from the client for accessing the content. 16. The apparatus as claimed in claim 14, further comprising: means for sending one or more access conditions for the content to the client. 17. A device, comprising: means for receiving (112) non-requested encrypted content from a content provider via a broadcast transmission, wherein the encrypted content is received from the content provider using spare broadcast capacity; means for sending (112) a request to the content provider to access the previously received encrypted content, wherein the request includes a terminal identifier and a result of a cryptographic function having a symmetric key (120) and the encrypted content as inputs, the terminal identifier allowing the content provider to identify the symmetric key (120) associated with the device; means for receiving (112) a content key secured by the symmetric key (120) from the content provider if the content provider successfully verifies based on the request that the encrypted content has been correctly received by the device, the content key secured by the symmetric key (120) being an encrypted content key; means for decrypting (114) the encrypted content key using the symmetric key (120); and means for decrypting (114) the encrypted content using the content key. 18. The device as claimed in claim 17, further comprising: means for storing (116) one or more access conditions and allowing a user to access the decrypted content in accordance with the one or more access conditions. 19. The device as claimed in claim 17, further comprising: means for charging (114) the user for access to the decrypted content. 20. The method as claimed in claim 8, further comprising: avoiding the involvement of a trusted third party in examining the request to verify that the client has correctly received the encrypted content. 21. The method as claimed in claim 8, further comprising: broadcasting the encrypted content with the control logic (118) to a plurality of clients, wherein each of the plurality of clients can independently request access to the encrypted content using another symmetric key uniquely known to each of the plurality of clients and the content provider. |
|---|
1820-delnp-2007-Abstract-(02-06-2014).pdf
1820-DELNP-2007-Abstract-(30-09-2011).pdf
1820-delnp-2007-Claims-(02-06-2014).pdf
1820-DELNP-2007-Claims-(30-09-2011).pdf
1820-delnp-2007-Correspondence Others-(01-05-2014).pdf
1820-delnp-2007-Correspondence Others-(02-05-2014).pdf
1820-delnp-2007-Correspondence Others-(02-06-2014).pdf
1820-delnp-2007-Correspondence Others-(16-04-2012).pdf
1820-DELNP-2007-Correspondence Others-(30-09-2011).pdf
1820-delnp-2007-correspondence-others-1.pdf
1820-delnp-2007-correspondence-others.pdf
1820-DELNP-2007-Description (Complete)-(30-09-2011).pdf
1820-delnp-2007-description (complete).pdf
1820-DELNP-2007-Drawings-(30-09-2011).pdf
1820-DELNP-2007-Form-1-(30-09-2011).pdf
1820-DELNP-2007-Form-13-(30-09-2011).pdf
1820-delnp-2007-Form-2-(02-06-2014).pdf
1820-DELNP-2007-Form-2-(30-09-2011).pdf
1820-DELNP-2007-Form-3-(30-09-2011).pdf
1820-delnp-2007-GPA-(02-05-2014).pdf
1820-DELNP-2007-GPA-(30-09-2011).pdf
1820-DELNP-2007-Petition-137-(30-09-2011).pdf
| Patent Number | 261057 | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Indian Patent Application Number | 1820/DELNP/2007 | |||||||||||||||
| PG Journal Number | 23/2014 | |||||||||||||||
| Publication Date | 06-Jun-2014 | |||||||||||||||
| Grant Date | 31-May-2014 | |||||||||||||||
| Date of Filing | 08-Mar-2007 | |||||||||||||||
| Name of Patentee | QUALCOMM INCORPORATED | |||||||||||||||
| Applicant Address | 5775 MOREHOUSE DRIVE, SAN DIEGO, CALIFORNIA 92121-1714, USA | |||||||||||||||
Inventors:
|
||||||||||||||||
| PCT International Classification Number | H04L 9/08 | |||||||||||||||
| PCT International Application Number | PCT/US2005/031451 | |||||||||||||||
| PCT International Filing date | 2005-09-02 | |||||||||||||||
PCT Conventions:
|
||||||||||||||||