DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 7, 9, 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Aabye et al(US 20150220917 A1) in view of Van Cleve et al(US 12341891 B2 ).
With regards to claim 1, Aabye discloses, A method, comprising: receiving, by a first entity, a request to establish a secure connection between the first entity and a second entity ([0108] At step 801, a transaction request is received including a token and a token certificate.), wherein the request comprises: (a) a first security token issued to the second entity by a trust anchor ([0108] At step 801, a transaction request is received including a token and a token certificate. [0105] At step 707, a token response is transmitted to the user device including the token and the signed token certificate. In various embodiments, the token can be transmitted separately from the signed token certificate or in a same message.), and (b) a first digital certificate, associated with the second entity ([0108] At step 801, a transaction request is received including a token and a token certificate. [0105] At step 707, a token response is transmitted to the user device including the token and the signed token certificate. In various embodiments, the token can be transmitted separately from the signed token certificate or in a same message.), comprising a first digital signature generated using a first private key, wherein the first public key and the first private key represent a first key pair ([0104] At step 706, the token certificate is signed. Signing the token certificate may involve hashing some or all of the contents of the token certificate. The resulting hash may then be encrypted using a private key of a trusted entity, such as a token provider, payment processing network, or issuer, to generate a digital signature. The digital signature may then be included in the token certificate. In other embodiments, algorithms such as the Digital Signature Algorithm (DSA) and the Elliptic-Curve Digital Signature Algorithm (ECDSA) may be used. Note: ECDSA suggest PKI used.);
validating, by the first entity, the first security token ([0112] At step 803, the token is verified using the token certificate. For example, in some embodiments, a token certificate may include a token identifier such as a hash of the token. In such cases, verifying the token may include ensuring a hash of the token matches the token identifier of the token certificate.), wherein validation of the first security token issued by the trust anchor establishes trust between the first entity and the second entity ([0033] Embodiments can provide systems and methods for conducting transaction using tokens without requiring a connection to a validating server. The use of tokens to conduct transactions provides several advantages. For example, since a token may identify an account without using an account number, tokens can be used to protect sensitive information and/or identity of a user from unscrupulous parties.);
validating, by the first entity, the first digital signature of the first digital certificate using the first public key of the first key pair corresponding to the first security token ([0111] At step 802, the token certificate is verified using a digital signature included in the certificate. In some embodiments, verifying the digital signature may include decrypting the digital signature using a trusted entity's public key and comparing the result to an expected value.), wherein based on the trust established by the first security token, the first entity trusts the first digital certificate associated with the second entity upon validating the first digital signature ([0111] At step 802, the token certificate is verified using a digital signature included in the certificate. In some embodiments, verifying the digital signature may include decrypting the digital signature using a trusted entity's public key and comparing the result to an expected value. The expected value may be, for example, a hash of part or all of the certificate. In some embodiments, one or more trusted certificates and/or trusted public keys corresponding to trusted entities may be maintained.)
responsive at least in part to validating the first digital signature of the first digital certificate, establishing, at least in part by the first entity, the secure connection between the first entity and the second entity (FIG 8 805 and associated text; );
wherein the method is performed by at least one device including a hardware processor ([0129] FIG. 11 is a high level block diagram of a computer system that may be used to implement any of the entities or components described above….The interconnection via system bus 1175 allows the central processor 1102 to communicate with each subsystem and to control the execution of instructions from system memory 1101 or the fixed disk 1107, as well as the exchange of information between subsystems. The system memory 1101 and/or the fixed disk may embody a computer-readable medium.).
Aabye does not exclusively but Van Cleve teaches, validating, by the first entity, the first security token using public key(col 27 line 5-15; The attestation token issuing server 320 validates the attestation token (323). For example, the attestation token issuing server 320 can validate the attestation token by verifying the signature of the attestation token using the public key of the attestation token issuing server. This similarly ensures that the content of the attestation token has not changed since the attestation token was issued by the attestation token issuing server. If the attestation token includes the device public key, the validation of the attestation token can also include a confirmation that the device public key included with the attestation token matches the device public key that is included within the attestation token.)
wherein the first security token is associated with a first public key (col 6 line 35-40; In some approaches, the attestation token can be digitally signed using a private key of a trusted program. The trusted program can confidentially maintain the private key. The attestation token can include, among other things, a public key that corresponds to the private key, a payload, and an attestation token. Col 4 line 15-25; The techniques described in this document can enhance privacy against such correlation by using multiple attestation tokens, each including a unique public key of the client device. For example, the client device can generate a batch of N public/private key pairs, and then send the N public keys to the third-party device analyzer to receive a batch of N corresponding attestation tokens;), digital signature generated using the private key corresponding to the first security token issued to the second entity by the trust anchor (col 2line 60-67; In some implementations, the second digital signature is created using a private key maintained by the attestation token issuing system, and the third digital signature can be verified using a public key (i) corresponding to the private key and (ii) published by the attestation token issuing system. Col 4 line 15-25; The techniques described in this document can enhance privacy against such correlation by using multiple attestation tokens, each including a unique public key of the client device. For example, the client device can generate a batch of N public/private key pairs, and then send the N public keys to the third-party device analyzer to receive a batch of N corresponding attestation tokens.); It would have been obvious to a person of ordinary skill in the art at the time of the invention was made to modify Aabye’s method with teaching of Van Cleve in order to protect privacy information in communication (Van Cleve Col 1 line 20-40;)
With regards to claim 2, Aabye in view of Van Cleve discloses, wherein validating the first digital signature using the first public key of the first key pair corresponding to the first security token (Aabye [0111] At step 802, the token certificate is verified using a digital signature included in the certificate. In some embodiments, verifying the digital signature may include decrypting the digital signature using a trusted entity's public key and comparing the result to an expected value. The expected value may be, for example, a hash of part or all of the certificate. In some embodiments, one or more trusted certificates and/or trusted public keys corresponding to trusted entities may be maintained.) comprises: extracting the first public key from the first security token, wherein the first public key is embedded within the first security token (Van Cleve col 2line 60-67; In some implementations, the second digital signature is created using a private key maintained by the attestation token issuing system, and the third digital signature can be verified using a public key (i) corresponding to the private key and (ii) published by the attestation token issuing system. col 6 line 35-40; In some approaches, the attestation token can be digitally signed using a private key of a trusted program. The trusted program can confidentially maintain the private key. The attestation token can include, among other things, a public key that corresponds to the private key, a payload, and an attestation token.).
With regards to claim 3, Aabye further discloses, wherein validating the first digital signature using the first public key of the first key pair corresponding to the first security token ([0068]; In some embodiments, verifying the digital signature may include decrypting the digital signature using a trusted entity's public key and comparing the result to an expected value) further comprises: prior to extracting the first public key from the first security token, extracting the first security token from the first digital certificate, wherein the first security token is embedded within the first digital certificate ([0027] A "token certificate" may include a digital certificate or other data that authenticates a token using a digital signature. The digital signature may be generated by a token provider or other authorized entity. In some cases, the token certificate may include a token identifier (e.g., a hash of the token), and the digital signature of the token certificate may be generated using the token identifier.).
With regards to claim 4, Aabye further discloses, wherein validating the first security token using the second public key corresponding to the trust anchor comprises: extracting, from the first security token, a trust anchor signature generated by the trust anchor utilizing a second private key; and validating the trust anchor signature utilizing the second public key, wherein the second public key and the second private key represent a second key pair corresponding to the trust anchor ([0021] The term "public/private key pair" may include a pair of linked cryptographic keys generated by an entity. The public key may be used for public functions such as encrypting a message to send to the entity or for verifying a digital signature which was supposedly made by the entity. The private key, on the other hand may be used for private functions such as decrypting a received message or applying a digital signature. The public key will usually be authorized by a body known as a Certification Authority (CA) which stores the public key in a database and distributes it to any other entity which requests it. [0068] Certificate verification module 312 may include any software and/or hardware configured to verify digital certificates, such as token certificates. For example, in some embodiments, certificate verification module 312 may include code operable to verify a digital signature included in a token certificate. In some embodiments, verifying the digital signature may include decrypting the digital signature using a trusted entity's public key and comparing the result to an expected value. The expected value may be, for example, a hash of part or all of the certificate. In some embodiments, certificate verification module 312 may maintain one or more trusted certificates and/or trusted public keys corresponding to trusted entities, such as token providers. If a token certificate is signed by one of the stored trusted certificates or trusted public keys, then the token certificate may be verified offline (i.e., without any communication with other devices).).
With regards to claim 7, Aabye further discloses, wherein the first digital certificate is issued by one of: the second entity, or a certificate generation service associated with the second entity (Aabye [0005] In some embodiments, a user device can send a token request to a token provider computer, and receive in response a token and a token certificate associated with the token.); wherein a chain of trust for the first digital certificate is based on the first security token being embedded in the first digital certificate ([0027] A "token certificate" may include a digital certificate or other data that authenticates a token using a digital signature. The digital signature may be generated by a token provider or other authorized entity. In some cases, the token certificate may include a token identifier (e.g., a hash of the token), and the digital signature of the token certificate may be generated using the token identifier.).
With regards to claim 9, Aabye further discloses, generating, by the second entity, the first digital certificate ([0005] In some embodiments, a user device can send a token request to a token provider computer, and receive in response a token and a token certificate associated with the token. The token certificate may include, for example, a hash of the token and a digital signature by the token provider computer or another trusted entity.), at least by: initializing a certificate data structure, embedding the first security token in the certificate data structure; generating the first digital signature utilizing the first private key, and appending the first digital signature to the certificate data structure (FIG 7 706 and associated text; ).
With regards to claim 14, Aabye in view of Van Cleve discloses, wherein the first entity comprises a server resource executing in a cloud environment operated by a cloud service provider (Van Cleve FIG 1A 170 and associated text; ), wherein the trust anchor is operated by the cloud service provider (Van Cleve FIG 1A 150 and associated text;), and wherein the second entity comprises a client resource executing in the cloud environment (Van Cleve FIG 1A 110 and associated text;).
With regards to claim 15, Aabye in view of Van Cleve discloses, wherein the first entity comprises a server resource executing in a cloud environment (Van Cleve FIG 1A 170 and associated text;), wherein the second entity comprises a client resource executing in the cloud environment(Van Cleve FIG 1A 110 and associated text;), and wherein the trust anchor comprises an identity service executing in the cloud environment (Van Cleve FIG 1A 180 and associated text;).
With regards to claim 16, Examiner taking official notice that wherein the first security token is a JavaScript Object Notation web token is well known in the art and not an inventive step.
With regards to claim 17, Aabye in view of Van Cleve discloses, wherein the first security token is a proof of possession token (Van Cleve Col 1line 50-60; receiving, by the application and from the attestation token issuing system in response to the second request, a redemption result representing whether the attestation token was successfully redeemed and is signed by the attestation token issuing system using a digital signature, wherein the redemption result is operable to verify, to the second content provider, that the user is authenticated to the second content provider). Motivation would be same as stated in claim 1.
With regards to claim 18, Examiner taking official notice that wherein the secure connection is established at least in part in accordance with one of: a transport layer security protocol, or a mutual transport layer security protocol is well known in the art and not an inventive step.
Claim 19, is the medium claim with one or more non-transitory computer-readable media comprising instructions that, when executed by one or more hardware processors, cause performance of operations ([0133] Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.), perform similar steps of claim 1, also rejected with same rational.
Claim 20, is a system comprising: at least one device including a hardware processor (FIG 4 200, 300 and associated text; [0052] FIG. 2 shows an example of a user device 200 in accordance with some embodiments. Examples of user devices 200 may include mobile phones, tablets, desktop and laptop computers, wearable devices (e.g., smart watches, fitness bands, ankle bracelets, rings, earrings, etc.), or any other computing device suitable for receiving, storing, and transmitting tokens. User device 200 may include a processor 201 communicatively coupled to a network interface 202, a memory 203, and a computer readable medium 210. ) and the system perform similar steps of claim 1, also rejected with same rational.
Claims 8 is rejected under 35 U.S.C. 103 as being unpatentable over Aabye et al(US 20150220917 A1) in view of Van Cleve et al(US 12341891 B2 ) and further in view of MICHAEL et al(EP 3484097 A1).
With regards to claim 89, Aabye in view of Van Cleve do not but MICHAEL teaches, wherein the first digital certificate is issued by a certificate authority corresponding to the certificate generation service, wherein the certificate authority is untrusted by the first entity (Page 3 1st para; In particular, the approval information makes it possible to determine whether the certificate to be verified is admissible. With the approval information, e.g. determine whether a certificate is in principle inadmissible. This is the case, for example, if the certificate was created by a certification authority that is untrusted, or if the certificate's validity period has expired. The approval information thus makes it possible in particular to predetermine the admissibility of the certificate.). It would have been obvious to a person of ordinary skill in the art at the time of the invention was made to modify Aabye in view of Van Cleve’s method with teaching of MICHAEL in order to provide an improved validation of a predetermined digital certificate. (MICHAEL Page 2 2nd para)
Allowable Subject Matter
Claims 5-6, 10-13 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20160294809 A1, US 20160021116 A1
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMED WALIULLAH whose telephone number is (571)270-7987. The examiner can normally be reached 8.30 to 430 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yin-Chen Shaw can be reached at 1-571-272-8878. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MOHAMMED WALIULLAH/Primary Examiner, Art Unit 2498
Prosecution Insights