Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Response to Amendments and Arguments
Applicant has amended independent claims 1, 9 & 16 and argued in remarks dated 7/24/2026 (page 07, last paragraph, page 08 & page 09 first paragraph) that Matsumoto and other cited arts does not teach alone or in combination teach “receiving, from a first computing device, an authentication request comprising: first authentication information associated with a credential; and second authentication information comprising a hash output of the credential that is encrypted using a private key”. Examiner has reviewed these arguments but found them to be moot as Examiner has changed ground.
Applicant further argued in page 09, last paragraph, that Matsumoto, and Sherman alone or in combination does not teach “verifying a path for the credential; and validating, based on the verifying the path, the credential." Examiner reviewed this argument but respectfully disagree for the following reasons:
As specification in para 0060 defines path verification “as authentication computing device 306 may verify a path for the credential. For instance, it may be verified that the credential was issued by a trusted authority (e.g., trusted authority 303, certificate authority, etc.)”. [0060] In some embodiments, a positive authentication is not indicated until the extracted credential (e.g., digital certificate) is validated. In an example, authentication computing device 306 may communicate with trusted authority 303 (e.g., certificate authority) to verify the validity of the extracted credential. The verification may include determining if the credential has been revoked. In an example, authentication computing device 306 may verify a path for the credential. For instance, it may be verified that the credential was issued by a trusted authority (e.g., trusted authority 303, certificate authority, etc.). In an example, authentication computing device 306 may consult with one or more outside sources to determine the validity of the credential. For instance, the other sources consulted may comprise directory 307, database 308, and any other suitable computing device (e.g., computing device 309). In an example, authentication computing device 306 may inspect fields and data in the credential to determine the validity of the credential. In some embodiments, if the credential is not properly validated, the authentication computing device 306 may indicate a failed authentication.
As Sherman discloses this teaching in para [0050- as shown below in this office action as well as in para 0047[0047] As discussed above, in other embodiments, the system 102 may rely on a third party certification authority 122 to issue the digital certificate 232. The third party certification authority 122 may prepare the digital certificate 232 at step 210 as described above. The third party certification authority 122 may sign a digital certificate by performing a mathematical operation on the digital certificate using, for example, the third party certification authority's private key. The system 102 may verify the digital signature by performing a similar mathematical operation on the digital certificate 232 using the third party certification authority's public key. If a known mathematical relationship is found, then the digital certificate 232 may be authenticated.(it is obvious to a skilled person that the source (certification authority-a trusted authority) of digital certificate is verified by verifying the said digital signature (digital signature created by signing the certificate by private key as mentioned above.) Please also see paras 0029-0030 of Sherman.]
Finally, as Matsumoto, Paatero and Sherman in combination teach “verifying a path for the credential; and validating, based on the verifying the path, the credential” as shown below in this instant office action.
Double Patenting rejection issued in the previous office action has been maintained.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper time-wise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 of instant Application US 18/829,500 are rejected on the ground of nonstatutory anticipatory type double patenting as being unpatentable over claims 1-48 of US patent 12120107 & claims 1-33 of US Patent US 11128615. Although the conflicting claims are not identical, they are not patentably distinct from each other because the claims both in the present application and the US patent discloses a method and systems of providing authentication to an unregistered device/user.
The table below shows the comparison of claims of the instant application with that of the US patents 12120107 & US Patent 11128615 respectively.
Claim No.
Limitations of Instant Application US 18/829,500
Limitations of US Patent US 12120107.
Claim No.
1
1. (Currently Amended) A method, implemented by one or more computing devices, comprising: receiving, from a first computing device, an authentication request comprising: first authentication information associated with a credential; and second authentication information comprising a hash output of the credential that is encrypted using a private key; decrypting the second authentication information; and determining, based on the decrypted second authentication information and based on one or more communications with a second computing device to validate the credential, whether to grant the authentication request.
1. A method comprising: receiving, from a computing device, an authentication request comprising first authentication information and second authentication information, wherein: the first authentication information is associated with a credential issued by a trusted authority; and the second authentication information is encrypted based on the credential; decrypting the second authentication information, based on a public key, to create a decrypted second authentication information; and determining, based on the decrypted second authentication information and a validity of the credential, whether to grant the authentication request.
1
9
9. (Currently Amended) An apparatus comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the apparatus to: receive, from a first computing device, an authentication request comprising: first authentication information associated with a credential; and second authentication information comprising a hash output of the credential that is encrypted using a private key; decrypt the second authentication information; and determine, based on the decrypted second authentication information and based on one or more communications with a second computing device to validate the credential, whether to grant the authentication request.
13. An apparatus comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the apparatus to: receive, from a computing device, an authentication request comprising first authentication information and second authentication information , wherein: the first authentication information is associated with a credential issued by a trusted authority; and the second authentication information is encrypted based on the credential; decrypt the second authentication information, based on a public key, to create a decrypted second authentication information; and determine, based on the decrypted second authentication information and a validity of the credential, whether to grant the authentication request.
13
16
16. (Currently Amended) A system comprising: a first computing device and a second computing device; wherein the first computing device comprises: one or more first processors; and memory storing first instructions that, when executed by the one or more first processors, cause the first computing device to: send an authentication request comprising: first authentication information associated with a credential; and second authentication information comprising a hash output of the credential that is encrypted using a private key; and wherein the second computing device comprises: one or more second processors; and memory storing second instructions that, when executed by the one or more second processors, cause the second computing device to: receive, from the first computing device, the authentication request; decrypt the second authentication information; and determine, based on the decrypted second authentication information and based on one or more communications with a third computing device to validate the credential, whether to grant the authentication request.
25. A system comprising: a first computing device and a second computing device; wherein the first computing device comprises: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the first computing device to: send an authentication request comprising first authentication information and second authentication information , wherein: the first authentication information is associated with a credential issued by a trusted authority; and the second authentication information is encrypted based on the credential; and wherein the second computing device comprises: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the second computing device to: receive, from the first computing device, the authentication request; decrypt the second authentication information, based on a public key, to create a decrypted second authentication information; and determine, based on the decrypted second authentication information and a validity of the credential, whether to grant the authentication request.
25
Claim No.
Limitations of Instant Application US 18/829,500
Limitations of US Patent US 11128615.
Claim No.
1
1. (Currently Amended) A method, implemented by one or more computing devices, comprising: receiving, from a first computing device, an authentication request comprising: first authentication information associated with a credential; and second authentication information comprising a hash output of the credential that is encrypted using a private key; decrypting the second authentication information; and determining, based on the decrypted second authentication information and based on one or more communications with a second computing device to validate the credential, whether to grant the authentication request.
1. A method comprising: receiving, from a computing device, an authentication request comprising a user name and a password associated with the user name, wherein: the user name is based on a digital certificate issued by a trusted authority; and the password is encrypted based on the digital certificate; decrypting the password, based on a public key, to create a decrypted password; and determining, based on the decrypted password and a validity of the digital certificate, whether to grant the authentication request.
1
9
9. (Currently Amended) An apparatus comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the apparatus to: receive, from a first computing device, an authentication request comprising: first authentication information associated with a credential; and second authentication information comprising a hash output of the credential that is encrypted using a private key; decrypt the second authentication information; and determine, based on the decrypted second authentication information and based on one or more communications with a second computing device to validate the credential, whether to grant the authentication request.
12. An apparatus comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the apparatus to: receive, from a computing device, an authentication request comprising a user name and a password associated with the user name, wherein: the user name is based on a digital certificate issued by a trusted authority; and the password is encrypted based on the digital certificate; decrypt the password, based on a public key, to create a decrypted password; and determine, based on the decrypted password and a validity of the digital certificate, whether to grant the authentication request
12
16
16. (Currently Amended) A system comprising: a first computing device and a second computing device; wherein the first computing device comprises: one or more first processors; and memory storing first instructions that, when executed by the one or more first processors, cause the first computing device to: send an authentication request comprising: first authentication information associated with a credential; and second authentication information comprising a hash output of the credential that is encrypted using a private key; and wherein the second computing device comprises: one or more second processors; and memory storing second instructions that, when executed by the one or more second processors, cause the second computing device to: receive, from the first computing device, the authentication request; decrypt the second authentication information; and determine, based on the decrypted second authentication information and based on one or more communications with a third computing device to validate the credential, whether to grant the authentication request.
23. A system comprising: a first computing device and a second computing device; wherein the first computing device comprises: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the first computing device to: send an authentication request comprising a user name and a password associated with the user name, wherein: the user name is based on a digital certificate issued by a trusted authority; and the password is encrypted based on the digital certificate; and wherein the second computing device comprises: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the second computing device to: receive, from the first computing device, the authentication request; decrypt the password, based on a public key, to create a decrypted password; and determine, based on the decrypted password and a validity of the digital certificate, whether to grant the authentication request.
23
Additionally, claims 1-20 of instant Application US 18/829,500 are also rejected on the ground of nonstatutory anticipatory type double patenting as being unpatentable over claims 1-37 of US Patent US 10484364. Although the conflicting claims are not identical, they are not patentably distinct from each other because the claims both in the present application and the US patent discloses a method and systems of providing authentication to an unregistered device/user.
Additionally, claims 1-20 instant Application US 18/829,500 are also rejected on the ground of nonstatutory anticipatory type double patenting as being unpatentable over claims 1, 3, 8,11 & 14 of US Patent US 9787669. Although the conflicting claims are not identical, they are not patentably distinct from each other because the claims both in the present application and the US patent discloses a method and systems of providing authentication to an unregistered device/user.
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 of this title, 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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-2, 5-7, 9, 12-14, 16 & 18-20 are rejected under 35 USC 103 as being unpatentable over Matsumoto (US 20010034836 A1) in view of Paatero (US 20030163700 A1)
Regarding claim 1, Matsumoto teaches a method, implemented by one or more computing devices, comprising: receiving, from a first computing device, an authentication request comprising: first authentication information associated with a credential; [0042] In the biometrics authentication station 20, to which the authentically request is sent from the resource providing server 80, the controller 28 requests a digital signature to the user terminal 60 (S10). In this case, data transmitted as the digital signature request includes a user ID as user information such as a name, address, or company, the serial number of the digital certificate 66, (values in the digital certificate- the credential received by the authentication station along with digital signature) and authentication information. The authentication information …., encrypts the digital certificate 66 with the private key 68, and generates a digital signature (S14). The user terminal 60 transmits this digital signature and the digital certificate 66 (credential) to the biometrics authentication station 20 (S16). [0042] In the biometrics authentication station 20, ….includes a user ID as user information such as a name, address, or company, the serial number of the digital certificate 66, and authentication information. The authentication …, encrypts the digital certificate 66 with the private key 68, and generates a digital signature (S14). The user terminal 60 transmits this digital signature and the digital certificate 66 to the biometrics authentication station 20 (S16).]
second authentication information comprising a digital signature of the credential that is encrypted based on the credential using a private key; [0043] The controller 28 in the biometrics authentication station 20 receives the digital signature (second authentication information) transmitted from the user terminal 60 (S18) and collates the digital signatures (S20). More specifically, the controller 28 decrypts the digital signature from the user terminal 60 with the user's public key (first authentication information) and compares the decrypted result with the digital certificate (credential) 66 transmitted together with the digital signature (second authentication information). If these signatures coincide with each other, it is authenticated that the user of the private key operates the user terminal 60.]
decrypting the second authentication information; and determining based on the decrypted second authentication information. and based on one or more communications with a second computing device to validate the credential, [0043] The controller 28 in the biometrics authentication station 20 receives the digital signature transmitted from the user terminal 60 (S18) and collates the digital signatures (S20). More specifically, the controller 28 decrypts the digital signature from the user terminal 60 with the user's public key and compares the decrypted result with the digital certificate 66 (credential) transmitted together with the digital signature. If these signatures coincide with each other, it is authenticated that the user of the private key operates the user terminal 60.[0044] The controller 28 transmits a CRL request to the directory server 24 (S22). Upon receiving the CRL request (S24), the directory server 24 (second computing device) acquires the CRL of the corresponding user from the digital certificate DB 26 (S26) and transmits it to the controller 28 (S28).[0045] The controller 28 receives the CRL from the directory server 24 (S30) and determines validity of the digital certificate 66 (credential) to check if the digital certificate 66 (credential) is invalidated or its valid dates expire (S32). According to this embodiment, information pertaining to the valid dates of biometrics data is stored in the CRL. The controller 28 refers to the CRL to determine whether the valid dates of the biometrics data expire (S32). If NO in step S32, a biometrics data request is transmitted to the user terminal 60 (S34)].
whether to grant authentication request; [0021] As described above, according to the authentication method of the present invention, the digital certificate and validity data representing the validity of the digital certificate, and the biometrics data of the user can be used at the time of issuance of the digital certificate stored in the user registration step when the authentication station authenticates the user, i.e., when the user validity determination step and biometrics collation step are performed. In this manner, when the digital certificate and biometrics data are checked, the third party who sets up for the authentic user can be discriminated, thereby performing highly reliable personal authentication. [ 0050] An accounting process (S5) performed between the biometrics authentication station 20 and the resource providing server 80 next to the authentication job (S3) will be described with reference to the flow chart in FIG. 6. When the authentication job (S3) is complete, the authentication result is transmitted from the biometrics authentication station 20 to the resource providing server 80 (S4) as described above. That is, the controller 28 in the biometrics authentication station 20 transmits the authentication result to the resource providing server 80 (S60), and the resource providing server 80 receives this (S62).]
Although Matsumoto teach the credential that is encrypted based on the credential using a private key as illustrated above, he does not teach explicitly, however, Paatero teaches information comprising a hash output of the credential that is encrypted using a private key; [0027] In practice this can be achieved by the user generated certificate being accepted by a third party if the certificate identifies the same entity as the entity identified by the certificate issued by the Certification Authority for the first system. Thus for instance, the user may have a private-public key issued by a Certification Authority for the wireless infrastructure which is stored in what is known as a Wireless Identity Module (WIM) 38 of the wireless device 36 (see FIG. 5). This private-key has an associated public-key and certificate containing the public-key issued by a Certification Authority for the wireless communication system. If the user generated certificate for the second system contains information concerning the identity of the user in the second system which corresponds to the identity of the user in the first system, the user of the second system can verify that identity through the certificate identified in the first system which forms part of the user generated certificate communicated between the user and the third party in the second system. To authenticate the user generated certificate, the user of the second system signs the user generated certificate using the private key of the first systems' private-public key pair. Such signing is typically performed by calculating a count hash value (e.g. using Secure Hashing Algorithm - 1 (SHA-1)), the data forming at least part of the user generated certificate (see e.g. X.509 v3 relating to certificates). This hash value is then signed by encrypting the hash value using the private key of the wireless device. This encrypted hash value is then typically appended to the end of the data in the user generated certificate.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Wheeler with the disclosure of Sherman. The motivation or suggestion would have been to implement a system that will provide efficient and improved techniques of public key infrastructure and in particular, the generation of keys and certificates and the use of certificates for purposes of authenticating a user. (abstract, para 0001-0005, Paatero)
Regarding claim 2, Matsumoto teaches wherein the credential comprises a value to authenticate the first computing device. [0042] In the biometrics authentication station 20, to which the authentically request is sent from the resource providing server 80, the controller 28 requests a digital signature to the user terminal 60 (S10). In this case, data transmitted as the digital signature request includes a user ID as user information such as a name, address, or company, the serial number of the digital certificate 66, (values in the digital certificate- the credential received by the authentication station along with digital signature) and authentication information. The authentication information …., encrypts the digital certificate 66 with the private key 68, and generates a digital signature (S14). The user terminal 60 transmits this digital signature and the digital certificate 66 (credential) to the biometrics authentication station 20 (S16). [0042] In the biometrics authentication station 20, ….includes a user ID as user information such as a name, address, or company, the serial number of the digital certificate 66, and authentication information. The authentication …, encrypts the digital certificate 66 with the private key 68, and generates a digital signature (S14). The user terminal 60 transmits this digital signature and the digital certificate 66 to the biometrics authentication station 20 (S16).]
Regarding claim 5, Matsumoto teaches verifying a validity of the credential by performing at least one of: determining whether the credential has been revoked; or inspecting one or more data fields of the credential. [0045] The controller 28 receives the CRL from the directory server 24 (S30) and determines validity of the digital certificate 66 (credential) to check if the digital certificate 66 (credential) is invalidated or its valid dates expire (S32). According to this embodiment, information pertaining to the valid dates of biometrics data is stored in the CRL. The controller 28 refers to the CRL to determine whether the valid dates of the biometrics data expire (S32). If NO in step S32, a biometrics data request is transmitted to the user terminal 60 (S34)].
Regarding claim 6, Matsumoto discloses wherein decrypting the second authentication information comprises: decrypting the second authentication information based on a public key associated with the first authentication information. [0043] The controller 28 in the biometrics authentication station 20 receives the digital signature transmitted from the user terminal 60 (S18) and collates the digital signatures (S20). More specifically, the controller 28 decrypts the digital signature from the user terminal 60 with the user's public key and compares the decrypted result with the digital certificate 66 (credential) transmitted together with the digital signature. If these signatures coincide with each other, it is authenticated that the user of the private key operates the user terminal 60.]
Regarding claim 7, Matsumoto teaches wherein the second authentication information comprises a digital signature of the first authentication information, as shown above in mapping of claim 1, however, Matsumoto does not teach explicitly, however, Paatero teaches wherein the digital signature comprises a hash output of the credential. [0027] In practice this can be achieved by the user generated certificate being accepted by a third party if the certificate identifies the same entity as the entity identified by the certificate issued by the Certification Authority for the first system. Thus for instance, the user may have a private-public key issued by a Certification Authority for the wireless infrastructure which is stored in what is known as a Wireless Identity Module (WIM) 38 of the wireless device 36 (see FIG. 5). This private-key has an associated public-key and certificate containing the public-key issued by a Certification Authority for the wireless communication system. If the user generated certificate for the second system contains information concerning the identity of the user in the second system which corresponds to the identity of the user in the first system, the user of the second system can verify that identity through the certificate identified in the first system which forms part of the user generated certificate communicated between the user and the third party in the second system. To authenticate the user generated certificate, the user of the second system signs the user generated certificate using the private key of the first systems' private-public key pair. Such signing is typically performed by calculating a count hash value (e.g. using Secure Hashing Algorithm - 1 (SHA-1)), the data forming at least part of the user generated certificate (see e.g. X.509 v3 relating to certificates). This hash value is then signed by encrypting the hash value using the private key of the wireless device. This encrypted hash value is then typically appended to the end of the data in the user generated certificate.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Wheeler with the disclosure of Sherman. The motivation or suggestion would have been to implement a system that will provide efficient and improved techniques of public key infrastructure and in particular, the generation of keys and certificates and the use of certificates for purposes of authenticating a user. (abstract, para 0001-0005, Paatero)
Regarding claim 9, this claim is interpreted to be similar as claim 1 and rejected for the same reasons as set forth for claim 1.
Regarding claims 12 & 18, these claims are interpreted to be similar to claim 5 and rejected for the same reasons as set forth for claim 5.
Regarding claims 13 & 19, these claims are interpreted to be similar as claim 6 and rejected for the same reasons as set forth for claim 6.
Regarding claims 14 & 20, these claims are interpreted to be similar as claim 7 and rejected for the same reasons set forth for claim 7.
Regarding claim 16, Matsumoto discloses a system comprising: a first computing device and a second computing device; wherein the first computing device comprises: one or more first processors; and memory storing first instructions that, when executed by the one or more first processors, cause the first computing device to: send an authentication request comprising: first authentication information associated with a credential; [0043] The controller 28 (residing in the second computing device) in the biometrics authentication station 20 receives the digital signature transmitted from the user terminal 60 (S18) (first computing device) and collates the digital signatures (S20). More specifically, the controller 28 decrypts the digital signature from the user terminal 60 with the user's public key (first authentication information) and compares the decrypted result with the digital certificate (credential) 66 transmitted together with the digital signature (second authentication information). If these signatures coincide with each other, it is authenticated that the user of the private key operates the user terminal 60]
second authentication information comprising ) the credential that is encrypted based on the credential using a private key; [0043] The controller 28 (second computing device) in the biometrics authentication station 20 receives the digital signature (second authentication information) transmitted from the user terminal 60 (S18) and collates the digital signatures (S20). More specifically, the controller 28 decrypts the digital signature (certificate encrypted with the private key) from the user terminal 60 with the user's public key and compares the decrypted result with the digital certificate (credential) 66 transmitted together with the digital signature (second authentication information). If these signatures coincide with each other, it is authenticated that the user of the private key operates the user terminal 60]
and wherein the second computing device comprises: one or more second processors; and memory storing second instructions that, when executed by the one or more second processors, cause the second computing device to: receive, from the first computing device, the authentication request; [0043] The controller 28 (second computing device) in the biometrics authentication station 20 receives the digital signature transmitted from the user terminal 60 (S18) and collates the digital signatures (S20). More specifically, the controller 28 decrypts the digital signature from the user terminal 60 with the user's public key and compares the decrypted result with the digital certificate 66 (credential) transmitted together with the digital signature. If these signatures coincide with each other, it is authenticated that the user of the private key operates the user terminal 60.
decrypt the second authentication information; and determine, based on the decrypted second authentication information and based on one or more communications with a third computing device to validate the credential, [0043] The controller 28 in the biometrics authentication station 20 receives the digital signature transmitted from the user terminal 60 (S18) and collates the digital signatures (S20). More specifically, the controller 28 decrypts the digital signature from the user terminal 60 with the user's public key and compares the decrypted result with the digital certificate 66 (credential) transmitted together with the digital signature. If these signatures coincide with each other, it is authenticated that the user of the private key operates the user terminal 60. [0044] The controller 28 transmits a CRL request to the directory server 24 (S22) (third computing device). Upon receiving the CRL request (S24), the directory server 24 (second computing device) acquires the CRL of the corresponding user from the digital certificate DB 26 (S26) and transmits it to the controller 28 (S28). [0045] The controller 28 receives the CRL from the directory server 24 (S30) and determines validity of the digital certificate 66 (credential) to check if the digital certificate 66 (credential) is invalidated or its valid dates expire (S32). According to this embodiment, information pertaining to the valid dates of biometrics data is stored in the CRL. The controller 28 refers to the CRL to determine whether the valid dates of the biometrics data expire (S32). If NO in step S32, a biometrics data request is transmitted to the user terminal 60 (S34)].
whether to grant the authentication request. [0021] As described above, according to the authentication method of the present invention, the digital certificate and validity data representing the validity of the digital certificate, and the biometrics data of the user can be used at the time of issuance of the digital certificate stored in the user registration step when the authentication station authenticates the user, i.e., when the user validity determination step and biometrics collation step are performed. In this manner, when the digital certificate and biometrics data are checked, the third party who sets up for the authentic user can be discriminated, thereby performing highly reliable personal authentication. [0050] An accounting process (S5) performed between the biometrics authentication station 20 and the resource providing server 80 next to the authentication job (S3) will be described with reference to the flow chart in FIG. 6. When the authentication job (S3) is complete, the authentication result is transmitted from the biometrics authentication station 20 to the resource providing server 80 (S4) as described above. That is, the controller 28 in the biometrics authentication station 20 transmits the authentication result to the resource providing server 80 (S60), and the resource providing server 80 receives this (S62).]
Although Matsumoto teach the credential that is encrypted based on the credential using a private key as illustrated above, he does not teach explicitly, however, Paatero teaches information comprising a hash output of the credential that is encrypted using a private key; [0027] In practice this can be achieved by the user generated certificate being accepted by a third party if the certificate identifies the same entity as the entity identified by the certificate issued by the Certification Authority for the first system. Thus for instance, the user may have a private-public key issued by a Certification Authority for the wireless infrastructure which is stored in what is known as a Wireless Identity Module (WIM) 38 of the wireless device 36 (see FIG. 5). This private-key has an associated public-key and certificate containing the public-key issued by a Certification Authority for the wireless communication system. If the user generated certificate for the second system contains information concerning the identity of the user in the second system which corresponds to the identity of the user in the first system, the user of the second system can verify that identity through the certificate identified in the first system which forms part of the user generated certificate communicated between the user and the third party in the second system. To authenticate the user generated certificate, the user of the second system signs the user generated certificate using the private key of the first systems' private-public key pair. Such signing is typically performed by calculating a count hash value (e.g. using Secure Hashing Algorithm - 1 (SHA-1)), the data forming at least part of the user generated certificate (see e.g. X.509 v3 relating to certificates). This hash value is then signed by encrypting the hash value using the private key of the wireless device. This encrypted hash value is then typically appended to the end of the data in the user generated certificate.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Wheeler with the disclosure of Sherman. The motivation or suggestion would have been to implement a system that will provide efficient and improved techniques of public key infrastructure and in particular, the generation of keys and certificates and the use of certificates for purposes of authenticating a user. (abstract, para 0001-0005, Paatero)
Claims 3-4, 10, 11 & 17 are rejected under 35 USC 103 as being unpatentable over Matsumoto (US 20010034836 A1) in view of Paatero (US 20030163700 A1) and Sherman (US20060059346 as mentioned in IDS dated 9/10/2024)
Regarding claim 3, although, Matsumoto and Paatero teach credential, he does not teach explicitly, however, Sherman teaches wherein the credential is used by a trusted authority, and wherein the second computing device is associated with the trusted authority. [0035] At step 204, the registration/authentication system 102 may enable a digital certification authority (trusted authority) to issue a digital certificate (credential) to the client 124. A digital certification authority is an entity that is established to issue digital certificates 232. In certain embodiments, the registration/authentication system 102 may include a digital certification authority to issue digital certificates 232 for clients 124. The registration/authentication system 102 may also rely on a third party digital certification authority 122 such as those offered by "Verisign" or "Thawte", for example, to issue digital certificates 232 for clients 124. Thus, in the case of a third party certification authority 122, step 204 involves notifying the third party digital certification authority 122 that a digital certificate 232 should be issued to the client 124. The registration/authentication system 102 and client access device 112 may communicate with the third-party digital certification authority 122 via the network 114, for example.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Matsumoto and Paatero with the disclosure of Sherman. The motivation or suggestion would have been to implement a system that will provide efficient and improved techniques to authenticate remote access clients with enhanced convenience while maintaining an acceptable level of security. (abstract, para 0001-0005, Sherman).
Regarding claim 4, although, Matsumoto and Paatero teaches credential, he does not teach explicitly, however, Sherman teaches verifying a path for the credential; and validating, based on the verifying the path, the credential. [0050] According to various embodiments, the system 102 may verify that a digital certificate 232 has been issued successfully. The system 102 may prompt an administrative user to contact the client 124 by telephone, for example, to inquire whether the client 124 is able to log into the client service system 110 using the digital certificate 232. Screen 604, as shown in FIG. 6C, is an exemplary communication to an administrative user prompting contact with the client 124 to verify that an issued digital certificate 232 operates correctly. The registration/authentication system 102 may automatically check the status of the client's digital certificate 232 by requesting the digital certificate 232 from the client 124 and verifying its validity and its binding 228 to the client representation 230.] [0047] As discussed above, in other embodiments, the system 102 may rely on a third party certification authority 122 to issue the digital certificate 232. The third party certification authority 122 may prepare the digital certificate 232 at step 210 as described above. The third party certification authority 122 may sign a digital certificate by performing a mathematical operation on the digital certificate using, for example, the third party certification authority's private key. The system 102 may verify the digital signature by performing a similar mathematical operation on the digital certificate 232 using the third party certification authority's public key. If a known mathematical relationship is found, then the digital certificate 232 may be authenticated.(it is obvious to a skilled person that the source (certification authority-a trusted authority) of digital certificate is verified by verifying the said digital signature (digital signature created by signing the certificate by private key as mentioned above.)
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Wheeler with the disclosure of Sherman. The motivation or suggestion would have been to implement a system that will provide efficient and improved techniques to authenticate remote access clients with enhanced convenience while maintaining an acceptable level of security. (abstract, para 0001-0005, Sherman)
Regarding claim 10, this claim is interpreted to be similar as claim 3 and rejected for the same reasons set forth for claim 3.
Regarding claims 11 & 17, this claim is interpreted to be similar as claim 4 and rejected for the same reasons set forth for claim 4.
Claims 8 & 15 are rejected under 35 USC 103 as being unpatentable over Matsumoto (US 20010034836 A1) in view of Paatero (US 20030163700 A1) and Buch (US 20030217165 A1 as mentioned in IDS dated 9/10/2024).
Regarding claim 8, although Matsumoto and Paatero teach decrypted second authentication information as shown above in the mapping of claim1, they do not teach explicitly, however, Buch teaches wherein the determining whether to grant the authentication request comprises: determining whether the decrypted second authentication information corresponds to the hash output. [[0028] When the callee SIP client 86 receives the SIP request message 82 containing the signature 100, it uses a certificate 102 of the sender associated with the private-public key pair of the sender to verify the digital signature 100 that came with the SIP request. Typically, the authentication process involves using the public key 110 of the sender 76 to decrypt the digital signature of the sender into a first hash value, generating a second hash value from those portions of the SIP message used by the sender to generate the digital signature, and comparing the two hash values. If they match, the recipient knows that the public key provided by the sender matches the private key used to generate the signature. If the request message includes a portion encrypted with the public key of the user 80, the SIP client 86 uses the private key 118 of the user to decrypt the encrypted data 120.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Matsumoto and Paatero with the disclosure of Buch. The motivation or suggestion would have been to implement a system that will provide efficient and improved techniques to authenticate received digital signature based on certificate. (abstract, para 0005-0007, Buch)
Regarding claim 15, this claim is interpreted to be similar as claim 8 and rejected for the same reasons set forth for claim 8.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHER A KHAN whose telephone number is (571)272-8574. The examiner can normally be reached M-F 8:00 am-500pm.
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, Eleni A Shiferaw can be reached at 571-272-3867. 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.
/SHER A KHAN/Primary Examiner, Art Unit 2497
Prosecution Insights