Source: http://www.google.com/patents/US20110029780?dq=6,757,682
Timestamp: 2017-03-26 06:09:28
Document Index: 252501024

Matched Legal Cases: ['arty 304', 'arty 304', 'arty 304', 'arty 304', 'arty 304', 'arty 304', 'arty 304', 'arty 304', 'arty 304', 'arty 304', 'arty 304', 'arty 304', 'arty 304', 'arty 304']

Patent US20110029780 - Systems and Methods for Conducting Transactions and Communications Using a ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsSystems and methods are provided for managing the transfer of electronic files. In one embodiment, a sender transfers an encrypted version of a file (such as a digitally encoded audio track, movie, document, or the like) to someone who wishes to receive it. The receiver computes a hash of the encrypted...http://www.google.com/patents/US20110029780?utm_source=gb-gplus-sharePatent US20110029780 - Systems and Methods for Conducting Transactions and Communications Using a Trusted Third PartyAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS20110029780 A1Publication typeApplicationApplication numberUS 12/895,510Publication dateFeb 3, 2011Filing dateSep 30, 2010Priority dateApr 20, 2001Also published asUS7136840, US7827114, US8185478, US8577812, US9123043, US20030084003, US20070124247, US20130013493, US20140058952, US20160155119Publication number12895510, 895510, US 2011/0029780 A1, US 2011/029780 A1, US 20110029780 A1, US 20110029780A1, US 2011029780 A1, US 2011029780A1, US-A1-20110029780, US-A1-2011029780, US2011/0029780A1, US2011/029780A1, US20110029780 A1, US20110029780A1, US2011029780 A1, US2011029780A1InventorsBinyamin Pinkas, Tomas Sander, William G. HomeOriginal AssigneeIntertrust Technologies Corp.Export CitationBiBTeX, EndNote, RefManPatent Citations (75), Referenced by (2), Classifications (15), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetSystems and Methods for Conducting Transactions and Communications Using a Trusted Third Party
US 20110029780 A1Abstract
1. A method for providing a first party with data content, the method comprising:
receiving the data content from a second party, wherein the data content has been encrypted by a third party; computing a first hash of at least a portion of the received encrypted data content; sending the first hash to a fourth party, wherein the fourth party is operable to compare at least a portion of the first hash to at least a portion of a second hash; receiving a decryption key from the fourth party; and decrypting at least the portion of the received encrypted data content with the decryption key. 2. A method as in claim 1, wherein the step of receiving the data content from the second party further includes the second party receiving the data content from the third party.
in response to the step of sending the first hash, receiving an indication from the fourth party that the portion of the encrypted data content is valid. 13. A method as in claim 12, further including:
in response to receiving the indication from the fourth party that the encrypted data content is valid, submitting payment information to the fourth party, the payment information being sufficient to enable the fourth party to cause the first party to be charged for the data content. 14. A method as in claim 13, wherein the payment information is processed so that the fourth party is compensated for supplying the decryption key to the first party.
[0030] Assume now that the values [α, β] that escrow server 104 holds do not correspond to the encrypted content 105 and to the corresponding decryption key (for purposes of discussion, assume that the content is defined in the “setting terms” stage). If the receiver 102 receives a value that is not hashed to α, then receiver 102 is not required to pay, as described above. However, it might be the case that the receiver 102 receives a value which does hash to α, and later, after paying and receiving key 106, receiver 102 finds out that the decryption of this value with the key 106 is not content 105. In this case receiver 102 can present the escrow server 104 with the value that it received from sender 100 (which is hashed to α), and demonstrate that decrypting this value using key 106 does not yield the content. Since H is collision resistant, the sender 100 cannot confront this claim by presenting a different value that is hashed to α and is the encryption of content 105 with the key 106.
[0034] In a preferred embodiment, the protocol does not require that the content be revealed to the escrow server 104. The only information that escrow server 104 needs to know is the hash of the encryption of the content, and the decryption key 106. If the encryption algorithm E is deterministic, then knowledge of H(EK(C)) and the key releases some information about the content (for example, it enables one to verify whether the content is equal to a certain value). If it is desired to prevent even this leakage of information, the system could use a semantically secure encryption function E. Thus, the basic protocol can be used even if it is preferable that the escrow server 104 not know the content—for example, in cases where receiver 102 and sender 100 exchange some very valuable content and only require the help of escrow server 104 in case of a dispute.
[0042] The systems and methods of the present invention can also support many small content providers. In such a situation, each content provider can generate content, distribute it (or provide it to other peers for distribution), and use the escrow server to reduce the risk in interacting with peers who are interested in receiving the content. A number of variations could be made to the basic protocol in such scenarios. For example:
The system could support a single content author distributing its creations, or enable the content creator to use other peers as distributors. The escrow server could check the encrypted version of the content before it begins supporting its distribution, in order to verify that it indeed contains the encryption of the right content. Alternatively, it could store the hash of the encrypted content without checking it, and only request the encrypted content in case of a dispute. Content servers could send the hash of the encrypted content to the escrow server before beginning to use the system. Alternatively, the hash could be delivered to the escrow server via the receiver of the content, as explained below. The system might send the same encrypted copy of the content to every recipient, or it might support independent encryption of different copies of the content e.g., as is described below). [0047] In the basic protocol described in connection with FIG. 1, it was assumed that the escrow server 104 had knowledge of H(EK(C)) and K. Assuming that the content is generated by a different party, this information must be communicated (directly or indirectly) from that party to the escrow server. It makes most sense to assume that [H(EK(C)), K] should be sent from the server S to the escrow server, since server S is held responsible for the quality of the information it sends to the recipient R.
[0049] FIG. 3 (and Table 2) illustrate an embodiment in which S does not need to open a communication channel with the escrow server. Referring to FIG. 3:
The message 390 that the sender 100 sends to receiver 102 contains, in addition to EK(C), an additional part that contains an encryption of [H(EK(C)), K] that can only be decrypted by escrow server 104 (e.g., by encrypting it with the escrow server's public key; other exemplary embodiments of the encryption method will be discussed in more detail below) (step 1). The recipient 102 receives this message and forwards to escrow server 104 a message 391 containing the hash, H(EK(C)), as well as the encrypted version of [H(EK(C)), K]) (step 2). The escrow server decrypts the encrypted version of [H(EK(C)), K]) (step 3), and proceeds as in the basic protocol shown in FIG. 1 (step 4 et seq.). [0052] The method shown in FIG. 3 has the advantage of not requiring the sender 100 to send any message directly to the escrow server 104, and not requiring the escrow server 104 to keep large databases of hash values of encrypted content. The recipient 102 is essentially used by the system as a communication channel from sender 100 to the escrow server 104. This makes sense, since sender 100 needs to send a message to receiver 102, who then needs to send a message to the escrow server 104.
[0053] If the escrow server is desired or required to examine and/or certify the content before recipients pay for it (rather than simply comparing the hash that was sent from the sender to the hash sent from the recipient), then the schemes described above could, for example, be modified as follows:
1. In an initial stage, S sends the content, C, and the decryption key, K, to the escrow server. The escrow server examines the content, and if it approves of it, the escrow server signs a message [H(EK(C)), K] and returns it to S. 2. When S sends the encryption of C to R, it accompanies it with the above message, encrypted with the public key of the escrow server. 3. R sends this message to the escrow server together with the hash of the encrypted content it received. [0057] The escrow server decrypts the message using its private key and verifies the signature. If it is correct, it continues as in the protocols described above.
[0059] In one embodiment, a public key encryption scheme is used, the decryption key of which is preferably known only to the escrow server. The same public encryption key could be used by all servers to encrypt messages to the escrow server. An alternative approach is to use private key cryptography. The escrow server could generate a basic key K{ES} and give each potential server Si a personal key Ki which is generated as Ki=F(K{ES}, Si), where F is a pseudo-random function keyed by the key K{ES}. This function could be implemented by the using the encryption scheme E and computing E{K{ES}}(Si). The key Ki is only known to the escrow server and to server Si, which uses the key to encrypt messages to the escrow server. If the system employs this method, then servers could use private key encryption which is generally more efficient than public key encryption. A major drawback is that each server should first contact the escrow server in order to obtain its personal key. This is generally less convenient than publishing the public key of the escrow server in a way that makes it available to all potential servers.
[0060] As mentioned above, if servers in the system are willing to serve an encrypted version of the content without being paid, trusting that they will be paid when the recipient obtains the decryption key from the escrow server, then a group of dishonest recipients could take advantage of the system without paying the required fees. The source of the problem is that there is a single encrypted version of the content, while the decryption key can be obtained from different sources. For purposes of illustration, two examples are provided below showing how dishonest parties could make use of this feature:
Assume that the content is a video file and that distributing it requires considerable network resources. One user R′ can obtain the encrypted version of the file and pay for the decryption key. It might not be economical for R′ to distribute the plaintext version of the file to other users, but R′ might sell (or give for free) the corresponding decryption key. This enables other users to contact servers, obtain the encrypted version, and decrypt it with the key they obtain from R′ without having to contact the escrow server to pay for the decryption key. If this happens, then servers might spend considerable resources distributing encrypted versions of the files without ever being paid for their efforts. Assume that a dishonest server S′ is colluding with a user R′. This user can then obtain the encrypted content from a different server S, and then contact the ES, present it with the hash of the encrypted content and with a payment, but claim that the content was obtained from S′. In this case, S′ gets paid although S is the server that did the work. [0063] One way to solve these problems is to use a self-enforcement encryption scheme (such as the signets scheme of Dwork, Lotspiech and Naor). In these schemes, each user has a personal key that contains some personal information. A single ciphertext message is sent to all users, and the personal key enables each user to obtain a decryption key for the ciphertext. The drawback is that in order to have the self-enforcement property, the length of the decryption key should be of the same order as the content, since otherwise the parties could simply distribute that key.
[0068] Thus, in some preferred embodiments error correction techniques are used to improve the basic protocol. For example, the content can be divided into k blocks (e.g., each block containing one second, or some other suitable portion, of music or video). These k blocks are encoded using a suitable error-correcting code into n blocks, called the “encoded content”. The error correction property ensures that any t of the n encoded blocks enable the reconstruction of the original k content blocks. In general, the parameters must satisfy k≦t≦n. It is desirable, of course, to have t as close as possible to k. For example, assume that t=0.75n, and therefore if one obtains uncorrupted copies of at least 75% of the encoded blocks, it is possible to reconstruct the original content.
[0072] To analyze the system, note that it is sufficient for R to obtain t encoded blocks in order to decrypt the content. Since the ES checks l blocks that are randomly chosen by R, the probability that S can prevent R from retrieving the content while not being detected by the escrow server is at most (t/n)̂l. The value of l should be set to make this probability sufficiently small. For example, l=2n/(n−t) is sufficient in order to lower this probability to about 10%.
[0073] The scheme could either use error correction codes or use more efficient erasure codes. Error correction codes have the property that given n blocks, such that at least t of them are correct (although the receiver does not know which ones these are), the receiver can reconstruct the original message. The system could use the list decoding algorithm of Guruswami and Sudan which requires that t≧\sqrt{nk}. In particular, if it is desired that t=0.75n, then the system should set n≧16k/9. This means that the message from S to R is less than twice its original size, and R should send the escrow server 8 blocks in order to bound the error probability at 10%.
[0074] Erasure codes are more efficient but require the recipient to identify which blocks are correct and which blocks are corrupt. The system could use such codes if the escrow server was required to sign each encoded block, and S was required to send the signed blocks to R. The escrow server would then verify that the blocks it decrypts are correct and contain its signature. This test ensures that R will, with high probability, be able to recover at least t correct blocks that are signed by the escrow server. The reconstruction operation of R should therefore be to decrypt each block, examine its signature, and, if it is correct, use the block in the reconstruction of the original content. As for the choice of erasure code to be used, one could use Reed-Solomon codes, for which it suffices to set t=k, meaning that to get t=0.75n we should set n=1.33 k, reducing the communication overhead from S to R. A drawback of Reed-Solomon codes is that the computation overhead is essentially O(n̂2) (if one does not use FFT methods which are asymptotically more efficient in theory, but generally less efficient in practice). A better choice might be to use the Tornado codes of Luby et al. These codes have a slightly larger t, t=k(1+ε), but the reconstruction time is linear. For all practical purposes, one could set ε=5%, increasing the communication overhead by only 5%.
[0078] Another exemplary verification method makes use of message authentication codes, (“MACs”). First, an escrow server chooses a random key KM to key a MAC, and keeps this key secret. When the protocol is run, party S sends the escrow server the encoded blocks of content C, denoted B1, . . . , Bn. The escrow server verifies that these blocks encode C. If they do, it returns to S for every l≦i≦n, the output of the MAC function, keyed by KM, on the input (\hat{C}, i, Bi), where \hat{C} is an agreed upon description of the content (such as a name of a movie, etc.). Namely the escrow server sends S the set of values \{MAC_{K_M}(\hat{C}, i, Bi)\}_{i=1}̂n.
[0084] The only increase in overhead that is incurred by using this version is the additional log n hash values that should be sent with every block. This overhead is rather small since, for all practical purposes, log n could be smaller than 20 and each hash value can be, e.g., 16 bytes long, while the blocks themselves are much longer. The overhead can be reduced if S sends the whole hash tree separately from the blocks, encrypting each node separately. R should forward the escrow server the l log n nodes that enable it to verify the hashes of the l blocks that are chosen by R. The total number of hash values that S sends to R is reduced to 2n, compared to n*log n if each block contains the hash values that are needed in order to verify it. That is, the overhead per block is only two hash values, which are of negligible length.
[0087] As previously indicated, the system can be designed so that it does not depend on trusting a single escrow server, but rather a group of several such servers. More specifically, a system of n escrow servers could be used, such that a recipient must contact any k of them in order to obtain the key that decrypts the content. In terms of security, this has the following properties:
[0094] Suppose that S wants to send a message M to R, and wants to receive a receipt certifying that the message was received. S knows the public key of TP. In one embodiment, the protocol uses the cryptographic primitives that were defined above, and has the following steps (shown in FIG. 4):
Sender 300 chooses a random key K and uses it to encrypt M, obtaining EK(M). It then computes the hash, H(EK(M)), and computes the encryption of [H(EK(M)), K] using the public key of trusted party 304. The sender 300 then sends receiver 302 a message with two parts, the first being EK(M), and the second being the encryption of [H(EK(M)), K] with trusted party 304's public key (step 1). The receiver 302 computes the hash H of the first part of the message it received, and sends it to the trusted party 304 together with the second part of the message it received (i.e., the encryption of [H(EK(M)), K]) (step 2). The trusted party 304 decrypts the second part of the message and compares the hash it contains with the hash received from receiver 302. If the two hashes are different, the trusted party 304 sends receiver 302 a message saying that the message receiver 302 received from sender 300 is invalid. If the two hashes are equal, trusted party 304 sends the key K to receiver 302 (step 3), and sends sender 300 the receipt (e.g., an indication that the receiver received the key, K, and a message encrypted therewith, and possibly also including a hash of the encrypted message H(EK(M))) (step 4). Receiver 302 receives the key from trusted party 304 and uses it to decrypt the message. If the receiver 302 does not receive a message from trusted party 304 within a certain predefined time interval, it should contact trusted party 304 and complain that it did not receive the key. If it does not complain within this time frame, the system may, in some embodiments, assume that the receiver received the key. Since trusted party 304 is trusted, and receiver 302 might not be, it can be assumed that if trusted party 304 claims that it sent a message to receiver 302, then the message can safely be assumed to have been received unless receiver 302 complains that it did not receive it. [0100] An alternative design that puts more burden on the server, requires receiver to send a receipt to trusted party 304 immediately after receiving the key K. If it does not send the receipt within a certain time frame, then trusted party 304 contacts receiver 302 (possibly using a more reliable channel) and informs receiver 304 that: (1) the system assumes that receiver 302 received the key K, and (2) if receiver has not received the key, then trusted party 304 can resend it.
[0105] FIG. 5 shows an illustrative computer system 531 for practicing embodiments of the present invention. For example, a system such as that shown in FIG. 5 could be used to implement sender 100, receiver 102, and/or escrow server 104 in FIG. 1. It should be understood, however, that FIG. 5 is provided for purposes of illustration, not limitation, and that other computer systems with additional components and/or some suitable subset of the components illustrated in FIG. 5 could also be used to practice the present invention. Indeed one skilled in the art will appreciate that virtually any type of computing device can be used, including without limitation personal computers, mainframes, cellular telephones, personal digital assistants, and the like. Referring to FIG. 5, illustrative computer system 531 will typically include some or all of the following components:
a processor 502 for processing information; system memory 504, typically comprised of some combination of random access memory (RAM) and read only memory (ROM) for storing information and instructions to be executed or used by processor 502 and/or for storing temporary variables or other intermediate information during execution of instructions by processor 502; a data storage device 507 such as a magnetic disk or optical disc and its corresponding drive; one or more input/output devices 521, such as a cathode ray tube (CRT) or liquid crystal display (LCD) device; audio speakers; an alphanumeric input device such as a keyboard and/or a cursor control device such as a mouse or a trackball for communicating information and/or command selections to processor 502; a communication device 525, such as a modem, a network interface card, or other commercially available network interface device for accessing other computers (e.g., sender 100, receiver 102, and/or escrow server 104) via a network 530 such as the Internet, a private corporate network, a local-area network, a wide-area network, a wireless network, or the like; and one or more buses 501 for coupling the aforementioned elements together. [0112] The operation of computer 531 is controlled primarily by programs stored in memory 504 and executed by each computer's processor 502. These programs typically include an operating system, software for performing the communication/transaction protocols described above (e.g., in connection with FIGS. 1-4), one or more other application programs (e.g., an email program, content viewer/player, etc.), data, and the like.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4827508 *Oct 14, 1986May 2, 1989Personal Library Software, Inc.Database usage metering and protection system and methodUS4977594 *Feb 16, 1989Dec 11, 1990Electronic Publishing Resources, Inc.Database usage metering and protection system and methodUS5050213 *Aug 6, 1990Sep 17, 1991Electronic Publishing Resources, Inc.Database usage metering and protection system and methodUS5410598 *Sep 27, 1994Apr 25, 1995Electronic Publishing Resources, Inc.Database usage metering and protection system and methodUS5530235 *Feb 16, 1995Jun 25, 1996Xerox CorporationInteractive contents revealing storage deviceUS5534975 *May 26, 1995Jul 9, 1996Xerox CorporationDocument processing system utilizing document service cards to provide document processing servicesUS5566230 *Jan 4, 1995Oct 15, 1996Matthew J. CairoMethod of certifying an information content of a telephonic exchangeUS5629980 *Nov 23, 1994May 13, 1997Xerox CorporationSystem for controlling the distribution and use of digital worksUS5634012 *Nov 23, 1994May 27, 1997Xerox CorporationSystem for controlling the distribution and use of digital works having a fee reporting mechanismUS5638443 *Nov 23, 1994Jun 10, 1997Xerox CorporationSystem for controlling the distribution and use of composite digital worksUS5638446 *Aug 28, 1995Jun 10, 1997Bell Communications Research, Inc.Method for the secure distribution of electronic files in a distributed environmentUS5715403 *Nov 23, 1994Feb 3, 1998Xerox CorporationSystem for controlling the distribution and use of digital works having attached usage rights where the usage rights are defined by a usage rights grammarUS5809116 *Mar 25, 1997Sep 15, 1998Matthew J. CairoMethod and apparatus of certifying a telephonic transmissionUS5809144 *Aug 24, 1995Sep 15, 1998Carnegie Mellon UniversityMethod and apparatus for purchasing and delivering digital goods over a networkUS5815555 *Feb 11, 1997Sep 29, 1998Matthew J. CairoCertified telephonic transmissionsUS5892900 *Aug 30, 1996Apr 6, 1999Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS5910987 *Dec 4, 1996Jun 8, 1999Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS5915019 *Jan 8, 1997Jun 22, 1999Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS5917912 *Jan 8, 1997Jun 29, 1999Intertrust Technologies CorporationSystem and methods for secure transaction management and electronic rights protectionUS5920861 *Feb 25, 1997Jul 6, 1999Intertrust Technologies Corp.Techniques for defining using and manipulating rights management data structuresUS5940504 *Jun 29, 1992Aug 17, 1999Infologic Software, Inc.Licensing management system and method in which datagrams including an address of a licensee and indicative of use of a licensed product are sent from the licensee's siteUS5943422 *Aug 12, 1996Aug 24, 1999Intertrust Technologies Corp.Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channelsUS5949876 *Jan 8, 1997Sep 7, 1999Intertrust Technologies CorporationSystems and methods for secure transaction management and electronic rights protectionUS5956154 *Nov 17, 1995Sep 21, 1999Matthew J. CairoCertified facsimileUS5982891 *Nov 4, 1997Nov 9, 1999Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS5999949 *Mar 14, 1997Dec 7, 1999Crandall; Gary E.Text file compression system utilizing word terminatorsUS6112181 *Nov 6, 1997Aug 29, 2000Intertrust Technologies CorporationSystems and methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other informationUS6138119 *Apr 27, 1999Oct 24, 2000Intertrust Technologies Corp.Techniques for defining, using and manipulating rights management data structuresUS6157721 *Aug 12, 1996Dec 5, 2000Intertrust Technologies Corp.Systems and methods using cryptography to protect secure computing environmentsUS6185683 *Dec 28, 1998Feb 6, 2001Intertrust Technologies Corp.Trusted and secure techniques, systems and methods for item delivery and executionUS6237786 *Jun 17, 1999May 29, 2001Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS6240185 *Feb 10, 1999May 29, 2001Intertrust Technologies CorporationSteganographic techniques for securely delivering electronic digital rights management control information over insecure communication channelsUS6253193 *Dec 9, 1998Jun 26, 2001Intertrust Technologies CorporationSystems and methods for the secure transaction management and electronic rights protectionUS6263436 *Dec 17, 1996Jul 17, 2001At&T Corp.Method and apparatus for simultaneous electronic exchange using a semi-trusted third partyUS6292569 *Oct 4, 2000Sep 18, 2001Intertrust Technologies Corp.Systems and methods using cryptography to protect secure computing environmentsUS6363488 *Jun 7, 1999Mar 26, 2002Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS6381695 *Jul 14, 1998Apr 30, 2002International Business Machines CorporationEncryption system with time-dependent decryptionUS6389402 *Jun 9, 1999May 14, 2002Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS6427140 *Sep 3, 1999Jul 30, 2002Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS6449367 *Feb 23, 2001Sep 10, 2002Intertrust Technologies Corp.Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channelsUS6510513 *Jan 13, 1999Jan 21, 2003Microsoft CorporationSecurity services and policy enforcement for electronic dataUS6618484 *Jul 5, 2002Sep 9, 2003Intertrust Technologies CorporationSteganographic techniques for securely delivering electronic digital rights management control information over insecure communication channelsUS6640304 *Mar 25, 2002Oct 28, 2003Intertrust Technologies CorporationSystems and methods for secure transaction management and electronic rights protectionUS6658568 *Oct 26, 1999Dec 2, 2003Intertrust Technologies CorporationTrusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights managementUS6668325 *Jun 9, 1998Dec 23, 2003Intertrust TechnologiesObfuscation techniques for enhancing software securityUS6785815 *Jun 7, 2000Aug 31, 2004Intertrust Technologies Corp.Methods and systems for encoding and protecting data using digital signature and watermarking techniquesUS6820202 *Nov 9, 1998Nov 16, 2004First Data CorporationAccount authority digital signature (AADS) systemUS6832316 *Jan 6, 2000Dec 14, 2004Intertrust Technologies, Corp.Systems and methods for protecting data secrecy and integrityUS7559123 *Jan 11, 2008Jul 14, 2009Nifco Taiwan CorporationSide release buckleUS20010042043 *May 15, 1997Nov 15, 2001Intertrust Technologies Corp.Cryptographic methods, apparatus and systems for storage media electronic rights management in closed and connected appliancesUS20020023214 *Aug 6, 2001Feb 21, 2002Intertrust Technologies Corp.Systems and methods using cryptography to protect secure computing environmentsUS20020048369 *Sep 10, 2001Apr 25, 2002Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS20020087859 *May 21, 2001Jul 4, 2002Weeks Stephen P.Trust management systems and methodsUS20020112171 *Jan 19, 2001Aug 15, 2002Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS20020143710 *Apr 3, 2001Oct 3, 2002Gary LiuCertified transmission systemUS20020152173 *Apr 5, 2002Oct 17, 2002Rudd James M.System and methods for managing the distribution of electronic contentUS20030023856 *Jun 13, 2002Jan 30, 2003Intertrust Technologies CorporationSoftware self-checking systems and methodsUS20030041239 *Oct 18, 2002Feb 27, 2003Intertrust Technologies Corp.Systems and methods using cryptography to protect secure computing environmentsUS20030046244 *Oct 18, 2002Mar 6, 2003Intertrust Technologies Corp.Methods for matching, selecting, and/or classifying based on rights management and/or other informationUS20030069748 *Oct 18, 2002Apr 10, 2003Intertrust Technologies Corp.Methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other informationUS20030069749 *Oct 18, 2002Apr 10, 2003Intertrust Technologies Corp.Methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other informationUS20030105721 *May 30, 2002Jun 5, 2003Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS20030163431 *Sep 10, 2001Aug 28, 2003Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS20040054630 *Jun 1, 2001Mar 18, 2004Intertrust Technologies CorporationSystems and methods for secure transaction management and electronic rights protectionUS20040059951 *Apr 25, 2003Mar 25, 2004Intertrust Technologies CorporationSecure authentication systems and methodsUS20040073813 *Apr 25, 2003Apr 15, 2004Intertrust Technologies CorporationEstablishing a secure channel with a human userUS20040103305 *Oct 28, 2003May 27, 2004Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS20040107356 *Nov 19, 2003Jun 3, 2004Intertrust Technologies Corp.Methods and apparatus for persistent control and protection of contentUS20040123129 *Dec 2, 2003Jun 24, 2004Intertrust Technologies Corp.Trusted infrastructure support systems, methods and techniques for secure electronic commerce transaction and rights managementUS20040133793 *Jun 25, 2003Jul 8, 2004Intertrust Technologies Corp.Systems and methods for secure transaction management and electronic rights protectionUS20050027871 *Jun 7, 2004Feb 3, 2005William BradleyInteroperable systems and methods for peer-to-peer service orchestrationUS20050050332 *Jul 23, 2004Mar 3, 2005Intertrust Technologies CorporationMethods and systems for encoding and protecting data using digital signature and watermarking techniquesUS20050060560 *Sep 24, 2004Mar 17, 2005Intertrust Technologies CorporationSystems and methods for protecting data secrecy and integrityUS20050060584 *Jul 22, 2004Mar 17, 2005Intertrust Technologies Corp.Trusted infrastructure support systems, methods and techniques for secure electronic commerce, electronic transactions, commerce process control and automation, distributed computing, and rights managementUS20050108555 *Dec 2, 2004May 19, 2005Intertrust Technologies CorporationSystems and methods for protecting data secrecy and integrity* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS8499009 *Feb 13, 2012Jul 30, 2013Flexera Software LlcMethod and system for managing digital goodsUS20120144381 *Feb 13, 2012Jun 7, 2012James BrentanoMethod and system for managing digital goods* Cited by examinerClassifications U.S. Classification713/181, 713/168, 380/277International ClassificationG06Q20/40, G06Q20/38, G06Q30/06, H04L9/00Cooperative ClassificationG06Q2220/00, G06Q20/401, G06Q30/06, G06Q20/3829, G06Q20/02European ClassificationG06Q30/06, G06Q20/3829, G06Q20/401Legal EventsDateCodeEventDescriptionAug 14, 2012CCCertificate of correctionFeb 28, 2013ASAssignmentOwner name: NAKAMURA, MINORU, JAPANFree format text: CORRECTIVE ASSIGNMENT TO CORRECT THE COUNTRY OF THE SECOND ASSIGNEE, SANYO TECH CO., LTD. PREVIOUSLY RECORDED ON REEL 025055 FRAME 0350. ASSIGNOR(S) HEREBY CONFIRMS THE COUNTRY OF THE SECOND ASSIGNEE, SANYO TECH CO., LTD. SHOULD READ --REPUBLIC OF KOREA-- NOT "DEM REP OF KOREA";ASSIGNORS:NAKAMURA, MINORU;HA, KIM YONG;OK, DO HYUN;SIGNING DATES FROM 20100809 TO 20100907;REEL/FRAME:029900/0274Owner name: SANYO TECH CO., LTD., KOREA, REPUBLIC OFFree format text: CORRECTIVE ASSIGNMENT TO CORRECT THE COUNTRY OF THE SECOND ASSIGNEE, SANYO TECH CO., LTD. PREVIOUSLY RECORDED ON REEL 025055 FRAME 0350. ASSIGNOR(S) HEREBY CONFIRMS THE COUNTRY OF THE SECOND ASSIGNEE, SANYO TECH CO., LTD. SHOULD READ --REPUBLIC OF KOREA-- NOT "DEM REP OF KOREA";ASSIGNORS:NAKAMURA, MINORU;HA, KIM YONG;OK, DO HYUN;SIGNING DATES FROM 20100809 TO 20100907;REEL/FRAME:029900/0274Nov 23, 2015FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services