Source: http://www.google.com/patents/US20030233542?dq=5842224
Timestamp: 2016-10-25 04:08:07
Document Index: 477844086

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

Patent US20030233542 - Selectively disclosable digital certificates - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsAn authentication mechanism uses a selectively disclosable digital certificate that gives the user strong control over what authenticated data is released to whom without allowing even a third-party certifying authority to determine precisely what data is being disclosed. In one implementation, the selectively...http://www.google.com/patents/US20030233542?utm_source=gb-gplus-sharePatent US20030233542 - Selectively disclosable digital certificatesAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS20030233542 A1Publication typeApplicationApplication numberUS 10/175,198Publication dateDec 18, 2003Filing dateJun 18, 2002Priority dateJun 18, 2002Also published asEP1376925A2, EP1376925A3Publication number10175198, 175198, US 2003/0233542 A1, US 2003/233542 A1, US 20030233542 A1, US 20030233542A1, US 2003233542 A1, US 2003233542A1, US-A1-20030233542, US-A1-2003233542, US2003/0233542A1, US2003/233542A1, US20030233542 A1, US20030233542A1, US2003233542 A1, US2003233542A1InventorsJosh BenalohOriginal AssigneeBenaloh Josh D.Export CitationBiBTeX, EndNote, RefManPatent Citations (25), Referenced by (49), Classifications (8), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetSelectively disclosable digital certificates
DETAILED DESCRIPTION [0019] The following discussion assumes that the reader is familiar with cryptography. For a basic introduction of cryptography, the reader is directed to a text written by Bruce Schneier and entitled “Applied Cryptography: Protocols, Algorithms, and Source Code in C,” published by John Wiley & Sons with copyright 1994 (with a second edition in 1996) or the text written by Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone and entitled “Handbook of Applied Cryptography,” published by CRC Press with copyright 1997, which are hereby incorporated by reference. [0020] Exemplary Authentication Environment [0021] Third-party authentication can be described as occurring in two phases. In the first phase, a user or requester obtains a digital certificate from a third-party authenticator, which is also referred to as a certifying authority. In the second phase, the user submits the digital certificate to transacting party for purposes of authenticating oneself to the transacting party. These phases are described separately below. [0022] [0022]FIG. 1 shows a simple computer network system 100 during the first phase of the authentication process when a user computing device 102 requests a digital certificate from a certifying authority 104 and the certifying authority generates and returns a selectively disclosable digital certificate. The user computing device 102 communicates with the certifying authority 104 via a network 106, which can be implemented in a variety of ways. For instance, the network 106 might be implemented as a LAN (local area network) and/or a WAN (wide area network), such as the Internet, using a wide variety of technologies, including wire-based technologies (e.g., wire, cable, fiber optic, etc.) and/or wireless technologies (e.g., satellite, radio, microwave, etc.). [0023] The user computing device 102 may be implemented in many ways including, for example, as a general-purpose desktop computer (as shown), a portable computer, a handheld computer, a cellular phone, a portable digital assistant, an email client, a set-top box, electronic gaming device, consumer electronics device, or any other type of device that is capable of digital communication to request and receive digital certificates. The certifying authority or authenticator 104 is illustrated as having one or more computer servers 108(1), 108(2), . . . 108(S) configured to receive requests from multiple user computing devices and return digital certificates. One example of a computing device that may be used to implement the user computing device 102 and/or the server 108 is described below in more detail with reference to FIG. 8. [0024] In FIG. 1, the user computing device 102 submits a request 110 for a digital certificate. The request 110 contains personal information pertaining to the user who is requesting the certificate. Essentially any information can be included in the request. Such information may be sensitive and/or non-sensitive, and can vary widely depending upon the purpose or intended use of the digital certificate. Examples of possible personal data items that might be provided in the request 110 include information such as the requestor's name, email address, physical address, telephone number, gender, driver's license, social security number, name of employer, credit report, requestor's income and assets, purchase histories, club memberships, affiliations, and so on. [0025] The certifying authority 104 receives the request 110 and generates a selectively disclosable digital certificate 120 for return to the user computing device 102. The selectively disclosable digital certificate 120 contains and authenticates the personal information submitted by the user, but formats the certificate in such a manner that enables the user to control what authenticated data is released to whom without allowing even the certifying authority to determine precisely what data is being disclosed. [0026] The selectively disclosable digital certificate 120 has multiple fields 122(1), 122(2), 122(3), . . . , 122(N) to hold associated items of personal information. The certifying authority 104 populates every field 122(1)-122(N) with an associated data item received from in the request 110 from the user. But, instead of populating each of these fields 122(1)-122(N) with the actual data to be authenticated, each field is populated with an obfuscated version of the data. That is, each data field is separately obfuscated using independent mechanisms to render the personal data item contained in each field unreadable unless the user also provides corresponding unlock capabilities to open the field. The data in the fields may be obfuscated in different ways including, for example, using encryption techniques and/or digital hashing techniques. Two examples are described below with respect to FIGS. 3 and 4. [0027] The certifying authority 104 digitally signs the certificate with a digital signature 124, inclusive of the obfuscated data fields 122(1)-122(N), thereby attesting to the authenticity of the contents of the certificate. The certifying authority returns the signed certificate 120 and an unlock capabilities packet 130 containing corresponding unlock capabilities 132(1), 132(2), 132(3), . . . , 132(N) for each respective field 122(1), 122(2), 122(3), . . . , 122(N). The unlock capabilities may be, for example, the various keys used for encryption or computation of keyed hash values. The user computing device 102 stores the selectively disclosable digital certificate 120 and unlock capabilities 130 in memory for use in subsequent third-party transactions. [0028] In an alternative implementation, the user computing device may supply the unlock capabilities to the certifying authority 104 for use in obfuscating the corresponding fields. For instance, the user computing device may provide the random values used to encrypt or hash the data to be placed in the certificate fields. In this case, the certifying authority 104 does not return the unlock capabilities packet 130 because the user computing device 102 presumably has the capabilities. [0029] Another possible implementation is for the user computing device 102 to submit values that, once at the certifying authority, are replaced by values derived in an agreed upon way from the submitted values, such as by using a shared key. Here, the certifying authority 104 would not need to return an unlock capabilities packet 130 containing the replacement values derived from the user-submitted values since these values could be derived independently by the user computing a <device 102. [0030] [0030]FIG. 2 shows the computer network system 100 during the second transaction phase in which the user computing device 102 submits the selectively disclosable certificate 120 to a transacting party 202 over network 106 as part of an authentication protocol. The transacting party 202 is representative of essentially any type of party with which the user may be interested in communicating and providing the certificate. The transacting party might be a financial institution, a gaming website, a merchant, a news organization, a government agency, a potential recipient of encrypted email, and so on. The transacting party 202 is illustrated as having one or more computers 204(1), . . . 204(M) configured to receive certificates 120 from various user computing devices 102 and use the certificates to authenticate the users and/or their devices. The computing device described with respect to FIG. 8 may be used, for example, to implement a server computer 204. [0031] When the user submits the certificate 120, the user also selects which of his/her personal data should be revealed for purposes of this transaction. For instance, the user may decide that the transacting party 202 only needs to see a name, public key, and expiration date. Accordingly, the user computing device 102 identifies the data fields in the certificate that hold the disclosable data items. The user computing device 102 then submits the entire certificate 120 along with a packet 210 of selected unlock capabilities for the data fields identified as containing the disclosable data items. In the illustration of FIG. 2, the packet 210 contains the unlock capabilities 132(1) and 132(3) for data fields 1 and 3. The transacting party 202 first verifies the signature 124 as belonging to the certifying authority. The transacting party 202 then uses the selected unlock capabilities 210 to open the selected data fields in the certificate 120, retrieves the data items from the opened fields, and uses the data items to authenticate the user for the requested transaction. [0032] In a typical setting, a user may obtain multiple certificates at one time from the certifying authority. Multiple uses of a single certificate may, in some situations, create privacy risks by allowing multiple transacting parties to combine their data to create associations. By requesting multiple certificates at once, the user may then, at any subsequent time, take a fresh certificate from the previously issued set, select the fields that are to be disclosed in a given transaction, disclose exactly those fields to the transacting party, and then discard the certificate. [0033] The communication between the user computing device and the transacting part may be over a secure channel, or an open channel. With the secure channel, additional cryptographic ciphers are used to protect the communicated content. [0034] Selectively Disclosable Certificates [0035] [0035]FIG. 3 shows one implementation of a selectively disciosable digital certificate 120 and corresponding unlock capabilities packet 130. The certificate has a content section 302 to hold certificate information describing what is being certified by the certifying authority. Multiple obfuscated fields 304(1), 304(2), 304(3), . . . 304(N) are also included in the certificate. Each field contains an associated data item related to the user. In this example, there is a data field 304(1) for the user's name, a data field 304(2) for the user's public key from a public/private key pair, a data field 304(3) for the user's age, a data field 304(4) for the user's income, a data field 304(5) for the user gender, a data field 304(6) for the user's social security number, a data field 304(7) for the user's drivers license, a data field 304(8) for the user's email address, a data field 304(9) for the user's phone number. Other fields might include name of employer, credit report, income and asset information, purchase histories, and club memberships, single-use or ephemeral keys, and so on. [0036] In this implementation, the certifying authority encrypts the data item prior to placing the data item in each field. The certifying authority uses a different encryption key K1-KN for each respective data item in corresponding field 304(1)304(N). That is, the name data in field 304(1) is encrypted with a first key K1, the public key data in field 304(2) is encrypted with a second key K2, and so on. Standard encryption algorithms (e.g., RSA, DES, etc.) may be used to encrypt the field contents. Each key can be generated as a random value at the time of certificate creation, so that the keys are random and unique. As a result, the contents of every individual field are obfuscated with a different key and can only be recovered by a party who is given possession of the corresponding key. [0037] The certifying authority digitally signs the selectively disclosable certificate 120, inclusive of the encrypted fields, to attach the signature 124. That is, the signature is computed using the signing function “SCA” as follows: [0038] Signature=SCA (field1, field2, . . . . fieldN) [0039] where, field1=EK1(Name), [0040] field2=EK2(PubKey), [0041] . . . [0042] fieldN=EKN(data item N). [0043] The certificate can be made smaller by first computing a hash digest of the concatenated fields prior to signing, as follows: [0044] Signature=SCA (Hash(field1, field2 . . . fieldN)) [0045] The unlock capabilities packet 130 contains the randomly generated keys K1-KN. The certifying authority returns both the certificate 120 and corresponding unlock capabilities packet 130 to the user computing device. Then, when the user 21 wishes to submit a certificate for authentication purposes, the user computing 22 device 102 submits the selectively disclosable certificate 120 and selected ones of the keys K1-KN to control which fields can be opened. The transacting party 202 evaluates the certificate signature 124 and if valid, uses the submitted keys to open the selected data fields. The recovered data is then used in the authentication process. In this manner, the user has strong control over what authenticated data is released to whom without allowing even the certifying authority to determine precisely what data is being disclosed. [0046] [0046]FIG. 4 shows another implementation of a selectively disclosable digital certificate 120′ and corresponding unlock capabilities packet 130′. The certificate has a content section 402 with contents describing that the certifying authority vouches for the authenticity of the data in the accompanying fields. Multiple obfuscated fields 404(1), 404(2), 404(3), . . . 404(N) are included in the certificate. Each field contains an associated data item related to the user, but formatted to hide the data item. [0047] In this implementation, a keyed hash technique is employed to obfuscate the data contained in the fields. The certifying authority populates each field with a cryptographic hash of the data item together with an independently chosen random value. More specifically, the certifying authority concatenates the data item for the field with a random key, and then computes a hashing function of the concatenated result. This produces a hash digest derived as a function of the data and the random value. For example, field 404(1) contains a hash digest H(K1, Name) derived from computing a hashing function H of a randomly generated key K1 and the user's name. Field 404(2) contains a hash digest H(K2, PubKey) derived from computing a hashing function H of a random key K2 and the user's public key, and so on. Each key can be randomly generated at the time of certificate creation. The keys can be randomly generated using independent random generation processes and/or pseudo-random generation processes. [0048] As a result, the contents of every individual field are obfuscated with separate keys. The certifying authority digital signs the selectively disclosable certificate 120, inclusive of the obfuscated fields 404, to attach the signature 124. The signature is computed using the signing function “SCA” as follows: [0049] Signature=SCA (field1, field2, . . . . fieldN) [0050] where, field1=H(K1, Name), [0051] field2=H(K2, PubKey), [0052] . . . [0053] fieldN=H(KN, data item N). [0054] The unlock capabilities packet 130′ contains the randomly generated keys K1-KN. The certifying authority returns both the certificate 120′ and corresponding unlock capabilities packet 130′ to the user computing device. When the user wishes to submit a certificate for authentication purposes, the user computing device 102 submits the selectively disclosable certificate 120′, selected ones of the keys K1-KN for chosen fields to be disclosed, and the data items that are in those fields. [0055] The transacting party 202 evaluates the certificate signature 124 and if valid, computes a hash digest as a hash function of the submitted keys and data items. If the computed hash digest matches the hash digest in the corresponding obfuscated field of the certificate, the transacting party 202 is assured that the submitted data is authentic. The recovered data is then used in the authentication process. Thus, once again the user has strong control over what authenticated data is released to whom. [0056] The keyed hashed implementation of FIG. 4 allows the certificates 120′ to be smaller in comparison to the certificate 120 of FIG. 3, because the hashed digests in fields 404 can be smaller than the encrypted data fields 304. With the keyed hash implementation, however, the user submits the actual data to the transacting party for verification purposes. To protect this data, it is desirable to use this type of selectively disclosable certificate within the context of secured communications between the user computing device and the transacting party. [0057] Authentication Protocol [0058] [0058]FIGS. 5 and 6 illustrate the two phases of the authentication protocol. FIG. 5 shows a first phase process 500 in which the user requests and obtains a digital certificate from the certifying authority. FIG. 6 shows a second phase process 600 in which the user submits the digital certificate to the transacting party for authentication. The processes 500 and 600 will be described with reference to the architecture of FIGS. 1 and 2. [0059] The processes 500 and 600 may be implemented in software as computer-executable instructions that direct various computing devices to perform the operations illustrated in blocks. The operations may additionally, or alternatively, be performed in hardware, firmware, or a combination of hardware, firmware, and software. Additionally, for discussion purposes, the operations are aligned beneath headings to represent which entities might perform the operations. [0060] With reference to FIG. 5, the user computing device 102 submits a request 110 for one or more digital certificates (block 502). The request 110 contains personal data that can be used to uniquely identify the user. Such data might include name, public key, age, email address, physical address, telephone number, gender, driver's license, social security number, name of employer, credit report, requestor's income and assets, purchase histories, club memberships, affiliations, and so on. At block 504, the user computing device may optionally submit random values that are used to obfuscate the data as they are placed in the certificate fields. [0061] At block 506, the certifying authority receives the request 110 with the personal data. The certifying authority creates one or more certificates, each with multiple fields to hold corresponding items of the personal data (block 508). The number of fields corresponds to the number of data items to be individually or independently selectable by the user. Alternatively, multiple data items may be stored in individual fields. [0062] At block 510, the certifying authority obfuscates the data destined for the individual fields and populates the fields with the obfuscated data. Obfuscating the data fields may be done in many ways. For instance, the certifying authority may encrypt the data using randomly generated key values, and then place the encrypted data in the fields. This approach results in a certificate 120, as illustrated in FIG. 3. Another approach is to use the random values to compute a cryptographic hash of the data items and then place the hash digest in the certificate fields. This approach results in a certificate 120′, as illustrated in FIG. 4. The key values may be generated at the certifying authority, or received from the user computing device, or derived from the user-submitted values. [0063] At block 512, the certifying authority digitally signs the certificate(s) with the obfuscated fields. The certifying authority then returns the signed certificate(s) and the unlock capabilities packet (if any) to the user computing device (block 514). [0064] With reference to FIG. 6, the user computing device 102 submits a selectively disclosable certificate to a transacting party 202 (block 602). The user computing device 102 also submits selected unlock capabilities that are associated with the certificate fields that the user wishes to reveal to the transacting party. For instance, the user computing device may submit selected keys to help decrypt the contents, or selected keys together with the data items to verify hash digests in the certificate. [0065] At block 604, the transacting party 202 initially verifies the signature on the certificate as belonging to the certifying authority. If the signature is valid, the transacting party 202 uses the selected unlock capabilities to open selected data fields of the certificate (block 606). The transacting party 202 evaluates the data items from the selected opened fields within the authentication procedures (block 608). Based on this evaluation, the transacting party 202 may continue or reject the transaction (block 610). [0066] Third-Party Authentication Protocol [0067] [0067]FIG. 7 shows another implementation for generating and issuing a selectively disclosable digital certificate. In this implementation, one or more third party signatories signs individual fields of the digital certificate. More specifically, a user computing device 102 submits a request (not shown) to the certifying authority 104. In response, the certifying authority 104 generates a selectively disciosable digital certificate 702 having multiple fields 704(1), 704(2), 704(3), . . . , 704(N) to hold associated items of personal information submitted by the user. The certifying authority 104 populates every field with an associated data item received in the user's request. [0068] The certifying authority 104 submits the certificate to one or more third party signatories, as represented by signatory 706. Representative signatories include government agencies, trusted financial institutions, trusted signing entities, and so on. The third party signatory 706 has one or more server computers 708(1), . . . , 708(K) that receives the certificate and verifies the data in one or more fields 704(1)-704(N). The third party signatory 706 then digitally signs the fields that it verifies as accurate. As illustrated, every field, or a subset of fields, are independently and individually signed by the third party signatory 706, as represented by third-party signatures 710(1), 710(2), 710(3), . . . , 710(N) for associated fields 704(1), 704(2), 704(3), . . . , 704(N). The third party signatory 706 returns the certificate 702 to the certifying authority. If the certificate is passed to more than one third party signatory, the certificate will have fields with signatures from multiple different signatories. [0069] With this approach, the contents of every individual field are verified and signed by one or more third party signatories. The certifying authority may then optionally sign the selectively disclosable certificate 702, inclusive of the individually-signed fields 704, to attach the signature 712. The signature is computed using the certifying authority's signing function “SCA” as follows: [0070] Signature=SCA(field1, field2, . . . . fieldN) [0071] where, field1=STP(data1), [0072] field2=STP(data2), [0073] . . . [0074] fieldN=STP(dataN), [0075] and STP is the signing function used by the one or more third party signatories. [0076] The signed certificate 702 is returned to the user computing device 102. [0077] In an alternate embodiment, the user computing device 102 may correspond directly with one or more third party signatories 706 to obtain signed data fields that it submits to the certifying authority 104. [0078] Exemplary Computer [0079] [0079]FIG. 8 illustrates an example of a suitable computing environment 800 that may be used to implement the user computing device 102, the certifying authority's server computer 108, the transacting party's computer 204, and/or the third-party signatory's computer 708. Although one specific configuration is shown, the various computing devices may be implemented in other computing configurations. [0080] The computing environment 800 includes a general-purpose computing device in the form of a computer 802. The components of computer 802 can include, by are not limited to, one or more host processors or processing units 804, a system memory 806, and a system bus 808. The system bus 808 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures can include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus. [0081] Computer 802 typically includes a variety of computer readable media. Such media can be any available media that are accessible by the computer and includes both volatile and non-volatile media, removable and non-removable media. The system memory 806 includes computer readable media in the form of volatile memory, such as random access memory (RAM) 810, and/or non-volatile memory, such as read only memory (ROM) 812. A basic input/output system (BIOS) 814, containing the basic routines that help to transfer information between elements within computer 802, such as during start-up, is stored in ROM 812. RAM 810 typically contains data and/or program modules that are immediately accessible to and/or presently operated on by the processing unit 804. [0082] Computer 802 may also include other removable/non-removable, volatile/non-volatile computer storage media. By way of example, FIG. 8 illustrates a hard disk drive 816 for reading from and writing to a non-removable, non-volatile magnetic media (not shown), a magnetic disk drive 818 for reading from and writing to a removable, non-volatile magnetic disk 820 (e.g., a “floppy disk”), and an optical disk drive 822 for reading from and/or writing to a removable, non-volatile optical disk 824 such as a CD-ROM, DVD-ROM, or other optical media. The hard disk drive 816, magnetic disk drive 818, and optical disk drive 822 are each connected to the system bus 808 by one or more data media interfaces 826, or alternatively by one or more interfaces (not shown). [0083] The disk drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules, and other data for computer 802. By way of example, and not limitation, computer readable media may comprise “computer storage media” (e.g., the volatile and non-volatile, removable and non-removable media described above) and “communications media”, which typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as carrier wave or other transport mechanism. Communication media also includes any information delivery media. It is to be appreciated that other types of computer readable media can be utilized, such as magnetic cassettes or other magnetic storage devices, flash memory cards, CD-ROM, digital versatile disks (DVD) or other optical storage, random access memories (RAM), read only memories (ROM), electrically erasable programmable read-only memory (EEPROM), and the like. [0084] Any number of program modules can be stored on the various memories including, by way of example, an operating system 827, one or more application programs 828, other program modules 830, and program data 832. For purposes of illustration, application programs and other executable program components such as the operating system are illustrated as discrete blocks stored in memory, although it is recognized that such programs and components reside at various times in different storage components of the computing device 802, and are executed by the data processor(s) of the computer. [0085] A user can enter commands and information into computer 802 via input devices such as a keyboard 834 and a pointing device 836 (e.g., a “mouse”). Other input devices 838 (not shown specifically) may include a microphone, joystick, game pad, satellite dish, serial port, scanner, and/or the like. These and other input devices are connected to the processing unit 804 via input/output interfaces 840 that are coupled to the system bus 808, but may be connected by other interface and bus structures, such as a parallel port, game port, or a universal serial bus (USB). [0086] A monitor 842 or other type of display device can also be connected to the system bus 808 via an interface, such as a video adapter 844. In addition to the monitor 842, other output peripheral devices can include components such as speakers (not shown) and a printer 846 which can be connected to computer 802 via the input/output interfaces 840. [0087] Computer 802 can operate in a networked environment using logical connections to one or more remote computers, such as a remote computing device 848. By way of example, the remote computing device 848 can be a personal computer, portable computer, a server, a router, a network computer, a peer device or other common network node, and the like. The remote computing device 848 is illustrated as a portable computer that can include many or all of the elements and features described herein relative to computer 802. [0088] Logical connections between computer 802 and the remote computer 848 are depicted as a local area network (LAN) 850 and a general wide area network (WAN) 852. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. [0089] When implemented in a LAN networking environment, the computer 802 is connected to a local network 850 via a network interface or adapter 854. When implemented in a WAN networking environment, the computer 802 typically includes a modem 856 or other means for establishing communications over the wide network 852. The modem 856, which can be internal or external to computer 802, can be connected to the system bus 808 via the input/output interfaces 840 or other appropriate mechanisms. It is to be appreciated that the illustrated network connections are exemplary and that other means of establishing communication link(s) between the computers 802 and 848 can be employed. [0090] In a networked environment, such as that illustrated with computing environment 800, program modules depicted relative to the computer 802, or portions thereof, may be stored in a remote memory storage device. By way of example, remote application programs 858 reside on a memory device of remote computer 848. For purposes of illustration, application programs and other executable program components such as the operating system are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various times in different storage components of the computing device 802, and are executed by the data processor(s) of the computer. [0091] Conclusion [0092] Although the invention has been described in language specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary on forms of implementing the claimed invention. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5420927 *Feb 1, 1994May 30, 1995Micali; SilvioMethod for certifying public keys in a digital signature schemeUS5659616 *Jul 16, 1996Aug 19, 1997Certco, LlcMethod for securely using digital signatures in a commercial cryptographic systemUS5903651 *May 14, 1996May 11, 1999Valicert, Inc.Apparatus and method for demonstrating and confirming the status of a digital certificates and other dataUS5960083 *Mar 24, 1997Sep 28, 1999Micali; SilvioCertificate revocation systemUS5982898 *Mar 7, 1997Nov 9, 1999At&T Corp.Certification processUS6044462 *Apr 2, 1997Mar 28, 2000ArcanvsMethod and apparatus for managing key revocationUS6108788 *Dec 8, 1997Aug 22, 2000Entrust Technologies LimitedCertificate management system and method for a communication security systemUS6189097 *Mar 24, 1997Feb 13, 2001Preview Systems, Inc.Digital CertificateUS6260145 *Jul 29, 1997Jul 10, 2001Fujitsu LimitedSystem and method of authentication of digital informationUS6292897 *Nov 3, 1997Sep 18, 2001International Business Machines CorporationUndeniable certificates for digital signature verificationUS6301658 *Sep 9, 1998Oct 9, 2001Secure Computing CorporationMethod and system for authenticating digital certificates issued by an authentication hierarchyUS6304974 *Nov 6, 1998Oct 16, 2001Oracle CorporationMethod and apparatus for managing trusted certificatesUS6367012 *Dec 6, 1996Apr 2, 2002Microsoft CorporationEmbedding certifications in executable files for network transmissionUS6532540 *Jun 23, 1998Mar 11, 2003Valicert, Inc.Apparatus and method for demonstrating and confirming the status of a digital certificates and other dataUS6622247 *Dec 19, 1997Sep 16, 2003Hewlett-Packard Development Company, LpMethod for certifying the authenticity of digital objects by an authentication authority and for certifying their compliance by a testing authorityUS6636975 *Dec 15, 1999Oct 21, 2003Identix IncorporatedAccessing a secure resource using certificates bound with authentication informationUS6802002 *Jan 14, 2000Oct 5, 2004Hewlett-Packard Development Company, L.P.Method and apparatus for providing field confidentiality in digital certificatesUS6988196 *Dec 22, 2000Jan 17, 2006Lenovo (Singapore) Pte LtdComputer system and method for generating a digital certificateUS20020032857 *Aug 29, 2001Mar 14, 2002Masashi KonPerson identification certificate link system, information processing apparatus, information processing method, and program providing mediumUS20020116610 *Feb 22, 2001Aug 22, 2002Holmes William S.Customizable digital certificatesUS20020144110 *Sep 4, 2001Oct 3, 2002Ramanathan RamanathanMethod and apparatus for constructing digital certificatesUS20030037234 *Aug 17, 2001Feb 20, 2003Christina FuMethod and apparatus for centralizing a certificate revocation list in a certificate authority clusterUS20030051134 *Aug 28, 2001Mar 13, 2003International Business Machines CorporationSecure authentication using digital certificatesUS20040049675 *Apr 8, 2003Mar 11, 2004Silvio MicaliPhysical access controlUS20040250062 *Jun 10, 1998Dec 9, 2004Daniel Graham DouglasMethod and system for the digital certificate generation and distribution* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7353499Sep 25, 2003Apr 1, 2008Sun Microsystems, Inc.Multiple instruction dispatch tables for application program obfuscationUS7363620Sep 25, 2003Apr 22, 2008Sun Microsystems, Inc.Non-linear execution of application program instructions for application program obfuscationUS7415618Sep 25, 2003Aug 19, 2008Sun Microsystems, Inc.Permutation of opcode values for application program obfuscationUS7424620 *Sep 25, 2003Sep 9, 2008Sun Microsystems, Inc.Interleaved data and instruction streams for application program obfuscationUS7774270Aug 10, 2010Maccloskey RandyCredit report lock systemUS7805289Jul 10, 2006Sep 28, 2010Microsoft CorporationAligning hierarchal and sequential document trees to identify parallel dataUS7877798Dec 9, 2008Jan 25, 2011Legal Igaming, Inc.System and method for connecting gaming devices to a network for remote playUS7895640Feb 22, 2011Knobbe, Martens, Olson & Bear LlpMethod for control of gaming systems and for generating random numbersUS8001607Aug 16, 2011Direct Computer Resources, Inc.System and method for obfuscation of data across an enterpriseUS8023657Aug 20, 2007Sep 20, 2011Atwater Ventures LimitedCryptography and certificate authorities in gaming machinesUS8073679Dec 6, 2011Microsoft CorporationAligning hierarchial and sequential document trees to identify parallel dataUS8191131May 29, 2012International Business Machines CorporationObscuring authentication data of remote userUS8220058Jul 10, 2012Oracle America, Inc.Rendering and encryption engine for application program obfuscationUS8332649 *Oct 26, 2006Dec 11, 2012Panasonic CorporationAuthentication system, signature creating device, and signature verifying deviceUS8397305 *Mar 12, 2013Atwater Ventures LimitedSystem and method for connecting gaming devices to a network for remote playUS8412948 *Mar 3, 2006Apr 2, 2013Samsung Electronics Co., Ltd.Method and apparatus for digital signature generation and validationUS8571991Apr 14, 2008Oct 29, 2013Zynga Inc.System and method for connecting gaming devices to a network for remote playUS8700902Feb 13, 2006Apr 15, 2014At&T Intellectual Property I, L.P.Methods and apparatus to certify digital signaturesUS8732846Aug 15, 2007May 20, 2014Facebook, Inc.Platform for providing a social context to software applicationsUS8886718Dec 26, 2013Nov 11, 2014Facebook, Inc.Providing personalized platform application contentUS8959154Dec 9, 2008Feb 17, 2015Zynga Inc.System and method for connecting gaming devices to a network for remote playUS8972735Apr 3, 2014Mar 3, 2015At&T Intellectual Property I, L.P.Methods and apparatus to certify digital signaturesUS9092932Dec 9, 2008Jul 28, 2015Zynga Inc.System and method for connecting gaming devices to a network for remote playUS9251649Mar 15, 2013Feb 2, 2016Zynga Inc.System and method for connecting gaming devices to a network for remote playUS9426157Apr 4, 2014Aug 23, 2016Facebook, Inc.Platform for providing a social context to software applicationsUS20050069131 *Sep 25, 2003Mar 31, 2005Sun Microsystems, Inc., A Delaware CorporationRendering and encryption engine for application program obfuscationUS20050069138 *Sep 25, 2003Mar 31, 2005Sun Microsystems, Inc., A Delaware CorporationApplication program obfuscationUS20050071652 *Sep 25, 2003Mar 31, 2005Sun Microsystems, Inc., A Delaware CorporationMultiple instruction dispatch tables for application program obfuscationUS20050071653 *Sep 25, 2003Mar 31, 2005Sun Microsystems, Inc., A Delaware CorporationNon-linear execution of application program instructions for application program obfuscationUS20050071655 *Sep 25, 2003Mar 31, 2005Sun Microsystems, Inc., A Delaware CorporationPermutation of opcode values for application program obfuscationUS20050071664 *Sep 25, 2003Mar 31, 2005Sun Microsystems, Inc., A Delaware CorporationInterleaved data and instruction streams for application program obfuscationUS20060085454 *Oct 6, 2005Apr 20, 2006Blegen John LSystems and methods to relate multiple unit level datasets without retention of unit identifiable informationUS20060146686 *Dec 12, 2005Jul 6, 2006Kim Byung JMethod for securing content on a recording medium and a recording medium storing content secured by the methodUS20070180256 *Mar 3, 2006Aug 2, 2007Samsung Electronics Co., Ltd.Method and apparatus for digital signature generation and validationUS20070198832 *Feb 13, 2006Aug 23, 2007Novack Brian MMethods and apparatus to certify digital signaturesUS20080010056 *Jul 10, 2006Jan 10, 2008Microsoft CorporationAligning hierarchal and sequential document trees to identify parallel dataUS20080032788 *Aug 20, 2007Feb 7, 2008Legal Igmaing, Inc.Cryptography and certificate authorities in gaming machinesUS20080072304 *Aug 23, 2006Mar 20, 2008Jeffrey Bart JenningsObscuring authentication data of remote userUS20080098214 *Oct 24, 2006Apr 24, 2008Antonio Rodriguez MartinezEncryption/decryption method, method for safe data transfer across a network, computer program products and computer readable mediaUS20080275829 *Apr 21, 2007Nov 6, 2008Direct Computer Resources, Inc.System and method for obfuscation of data across an enterpriseUS20080319902 *Nov 17, 2006Dec 25, 2008Mark Mervyn ChazanMethod and Apparatus for Facilitating a Secure TransactionUS20090049525 *Aug 15, 2007Feb 19, 2009D Angelo AdamPlatform for providing a social context to software applicationsUS20090106788 *Apr 4, 2006Apr 23, 2009Alain NochimowskiProcedure for Authenticating a Digital-Content UserUS20090193250 *Oct 26, 2006Jul 30, 2009Kaoru YokotaAuthentication system, signature creating device, and signature verifying deviceUS20110029778 *Apr 10, 2009Feb 3, 2011Koninklijke Philips Electronics N.V.Method for distributed identification, a station in a networkUS20130339740 *Mar 8, 2012Dec 19, 2013Omer Ben-ShalomMulti-factor certificate authorityWO2007056808A1 *Nov 17, 2006May 24, 2007Ewise Systems Pty LtdA method and apparatus for facilitating a secure transactionWO2008154648A1 *Jun 12, 2008Dec 18, 2008Facebook, Inc.Personalized social networking application contentWO2015058243A1 *Oct 22, 2014Apr 30, 2015Eteam Software Pty LtdA system and method for certifying information* Cited by examinerClassifications U.S. Classification713/156International ClassificationH04L9/32, H04L9/08Cooperative ClassificationH04L9/3263, H04L9/321, H04L2209/56, H04L2209/60European ClassificationH04L9/32TLegal EventsDateCodeEventDescriptionJun 18, 2002ASAssignmentOwner name: MICROSOFT CORPORATION, WASHINGTONFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BENALOH, JOSH D.;REEL/FRAME:013042/0545Effective date: 20020618Jan 15, 2015ASAssignmentOwner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTONFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0001Effective date: 20141014RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services