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 § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more.
Under the broadest reasonable interpretation, the following claim terms are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. MPEP § 2111.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03) Claim 1 and 18 recites a process, which is a statutory category of invention (Step 1: YES). Claim 11 recites an apparatus (product), which is a statutory category of invention (Step 1: YES).
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a)). Yes.
The claims are analyzed to determine whether it is directed to a judicial exception. The following claims identify the limitations that recite additional elements in bold and the abstract idea without bold. Underlined claim limitations denote newly added claim limitations:
Claim 1 and 11 recites a method comprising: receiving, by a processing network computer from a user device, account identifying information associated with a user account and a digital identity certificate including identity information; associating, by the processing network computer, a token representing the account identifying information with the digital identity certificate; and transmitting, by the processing network computer, a message to the user device indicating that the digital identity certificate provisioning is complete with respect to the user account, wherein the digital identity certificate provisioning transforms the digital identity certificate to be a proxy for the user account. These limitations, as drafted, under its broadest reasonable interpretation, covers performance via certain methods of organizing human activity, but for the recitation of generic computer components. Under human activity, the limitations are commercial interactions, such as business relations, as well as managing interactions involving people, such as following instructions. The claims also recite a fundamental economic practice, such as mitigating risk (Applicant specification, Para. 44). Lastly, the claims recite a mental process, capable of being performed in the human mind or by pen and paper. Accordingly, the claim recites an abstract idea. The mere recitation of generic computer components in the claims do not necessarily preclude that claim from reciting an abstract idea. (Step 2A-Prong 1: Yes. The claims recite an abstract idea).
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d)). No.
The above judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements of a processing network computer, user device, processors, instructions, and token. The additional elements of a processing network computer, user device, are just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)). The additional elements of a token are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of blockchain (MPEP 2106.05(h)). The computer components are recited at such a high-level of generality (i.e. as a generic computer components) such that it amounts to no more than mere instructions to apply the exception using generic computer components, and the claims fail to recite technological detail as to how the step of the judicial exception is accomplished. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. (Step 2A-Prong 2: NO. The judicial exception is not integrated into a practical application).
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05). No.
The claims are next analyzed to determine if there are additional claim limitations that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements of (processing network computer, user device, and token) in the claims amount to no more than mere instructions to apply the exception using a generic computer component and generally linking the use of blockchain to judicial exception. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer component and generally linking the use of blockchain to judicial exception cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea itself. Therefore, the claims do not amount to significantly more than the recited abstract idea (Step 2B: NO; The claims do not provide significantly more, and are not patent eligible).
Claim 2 recites further comprising: receiving, by the processing network computer, a transaction authorization request message from a resource provider computer, the transaction authorization request message including the digital identity certificate and a transaction amount associated with a transaction; retrieving, by the processing network computer, the token associated with the digital identity certificate; and processing, by the processing network computer, the transaction using the token. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of processing network computer and resource provider computer are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of a token are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of blockchain (MPEP 2106.05(h)). Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 3 recites wherein associating the token with the digital identity certificate comprises: retrieving, from an authorizing entity computer, account name information associated with the account identifying information; validating the identity information corresponds with the account name information provided by the authorizing entity computer; and authenticating a signature of the identity information using a public key associated with a certification authority and part of a key pair that includes a private key used to sign the identity information, wherein the certification authority manages the digital identity certificate on the user device. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of authorizing entity computer and user device are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 4 recites wherein authenticating the signature further comprises: identifying, by the processing network computer, the public key associated with the certification authority that issued the digital identity certificate; and authenticating, by the processing network computer, the digital identity certificate using the public key. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of a processing network computer are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 5 recites wherein validating the identity information corresponds with the account name information comprises determining if a first field included in the identity information matches a second field included in the account name information. These limitations are also part of the abstract idea identified in claim 1, and is similarly rejected under the same rationale as claim 1, supra.
Claim 6 recites further comprising: transmitting a request to an authorizing entity computer requesting account name information, the request including the account identifying information; receiving the account name information; and comparing the account name information to the identity information. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of an authorizing entity computer are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 7 recites wherein the digital identity certificate is stored by the user device. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the user device are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 8 recites wherein the digital identity certificate is received from a service provider application running on the user device, and wherein the message is transmitted to the service provider application. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the user device and a service provider application are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 9 recites further comprising: prior to receiving the account identifying information and the identity information from the user device: receiving, by the processing network computer, the digital identity certificate from the user device; authenticating, by the processing network computer, the digital identity certificate; and transmitting, by the processing network computer, an authentication result, generated by the authenticating, to the user device. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the user device and a user device and processing network computer are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 10 recites wherein authenticating the digital identity certificate further comprises: identifying, by the processing network computer, a public key associated with a certification authority that issued the digital identity certificate; and authenticating, by the processing network computer, the digital identity certificate using the public key by verifying a signature of the identity information using the public key associated with the certification authority and part of a key pair that includes a private key used to sign the identity information, wherein the certification authority manages the digital identity certificate on the user device. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the user device and a processing network computer and user device are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 12 recites wherein the processors execute the instructions, further causing the processing network computer to perform operations further comprising: receiving a transaction authorization request message from a resource provider computer, the transaction authorization request message including the identity information associated with the digital identity certificate and a transaction amount associated with a transaction; retrieving the token associated with the identity information; and processing the transaction using the token. These limitations are also part of the abstract idea identified in claim 11, and the additional elements of processing network computer, processors, and resource provider computer are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 11 analysis above. These limitations are also part of the abstract idea identified in claim 11, and the additional elements of a token are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of blockchain (MPEP 2106.05(h)). Therefore, this claim is similarly rejected under the same rationale as claim 11, supra.
Claim 13 recites wherein associating the token with the digital identity certificate comprises executing the instructions causing the processors to perform operations comprising: retrieving, from an authorizing entity computer, account name information associated with the account identifying information; validating the identity information corresponds with the account name information provided by the authorizing entity computer; and authenticating a signature of the identity information using a public key associated with a certification authority and part of a key pair that includes a private key used to sign the identity information, wherein the certification authority manages the digital identity certificate on the user device. These limitations are also part of the abstract idea identified in claim 11, and the additional elements of authorizing entity computer, processor and user device are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 11 analysis above. These limitations are also part of the abstract idea identified in claim 11, and the additional elements of a token are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of blockchain (MPEP 2106.05(h)). Therefore, this claim is similarly rejected under the same rationale as claim 11, supra.
Claim 14 recites wherein authenticating the signature comprises executing the instructions causing the processors to perform the operations comprising: identifying the public key associated with the certification authority that issued the digital identity certificate; and authenticating the digital identity certificate using the public key. These limitations are also part of the abstract idea identified in claim 11, and the additional elements of instructions and processors and user device are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 11 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 11, supra.
Claim 15 recites wherein validating the identity information corresponds with the account name information comprises determining if a first field included in the identity information at least partially matches a second field included in the account name information. These limitations are also part of the abstract idea identified in claim 11, and is similarly rejected under the same rationale as claim 11, supra.
Claim 16 recites wherein the processors execute the instructions, further causing the processing network computer to perform operations further comprising: transmitting a request to an authorizing entity computer requesting account name information, the request including the account identifying information; receiving the account name information; and comparing the account name information to the identity information. These limitations are also part of the abstract idea identified in claim 11, and the additional elements of the processors, instructions, processing network computer and authorizing entity computer are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 11 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 11, supra.
Claim 17 recites wherein the digital identity certificate provisioning transforms the digital identity certificate into a payment credential. These limitations are also part of the abstract idea identified in claim 11, and is similarly rejected under the same rationale as claim 11, supra.
Claim 18 recites a method comprising: receiving, by a processing network computer from a resource provider computer for a transaction, a first transaction authorization request message that includes a digital identity certificate including identity information and transaction information associated with the transaction; determining, by the processing network computer, a token associated with the identity information from a plurality of tokens associated with the identity information based at least in part on the transaction information and the digital identity certificate; retrieving, by the processing network computer, the token; generating, by the processing network computer, a second transaction authorization request that includes the token; transmitting, by the processing network computer and to an authorizing entity computer, the second transaction authorization request; receiving, by the processing network computer and from the authorizing entity computer, a first transaction authorization response message generated based at least in part on the token; and transmitting, by the processing network computer and to the resource provider computer, a second transaction authorization response message indicating whether the transaction was authorized.
Claim 19 recites wherein the token is associated with at least one of: an account for government benefits, a disaster relief account, a charitable assistance account, a health account, an account for disability disbursement, an account for education disbursement, an account for insurance disbursement, a pension account, or a personal bank account. These limitations are also part of the abstract idea identified in claim 18, and the additional elements of a token are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of blockchain (MPEP 2106.05(h)). Therefore, this claim is similarly rejected under the same rationale as claim 18, supra.
Claim 20 recites wherein determining the token comprises: searching for an identifier of the token included in a data structure storing a set of token identifiers using at least the identity information and the transaction information. These limitations are also part of the abstract idea identified in claim 18, and the additional elements of a token are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of blockchain (MPEP 2106.05(h)). Therefore, this claim is similarly rejected under the same rationale as claim 18, supra.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Arora US 20190236592, in view of Larson US 10693872 and Allen US 20180082290.
Regarding claims 1 and 11, Arora discloses a method comprising:
receiving, by a processing network computer from a user device, account identifying information associated with a user account and [identity information] (Para. 57, 108 receives request for payment token from 110 and generates payment token with amount and customer identifier; Payment network server receives a request for a payment token, including payment amount and transaction time, and generates a token comprising amount, time, and a tokenized PAN associated with customer identifier, Fig. 1, 108 receives from 110);
associating, by the processing network computer, a token representing the account identifying information and [identity information] (Para 19. Payment network server queries customer database to obtain personalized PAN associated with customer identifier with personal account number; Para. 57, Query database 112, where 108 transmits payment token to issuer application to upload into e-commerce site);
Arora fails to disclose a digital identity certificate including identity information in a transaction context. However, Allen discloses a digital certificate that presents the identification of a user (Para. 24; Para. 27, disclosing the identity of professionals; Para. 78, PII given certain visibility rights; Claim 4).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Arora with the digital identity certificate including identity information. Doing so allows the identification to be more narrowed to the particular transaction, and enhances the security of the authentication process by making the identification process digital.
Modified Arora also fails to discloses transmitting, by the processing network computer, a message to the user device indicating that the digital identity certificate provisioning is complete with respect to the user account, wherein the digital identity certificate provisioning transforms the digital identity certificate to be a proxy for the user account. However, Larson discloses an identity verification system using biometrics and a drivers license (Fig. 3 – 14), where once the user is verified, there is a message sent to the users device (Fig. 13, 13-5-1318; of Fig. Fig. 12, 1205 to 1210) and once verified, the user receives a unique passkey (fig. 3) .
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Arora with the provisioned user status of Larson that allows the user to use a digital identity for their user account. Doing so allows ease-of-use for permission to use a device, or gain entry, and creates greater efficiency in the system.
Claim(s) 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Arora US 20190236592, in view of Larson US 10693872 and Allen US 20180082290, as applied to claims 1 and 11 above, further in view of Hobson US 20020133467.
Regarding claims 2 and 12, modified Arora fails to disclose further comprising: receiving, by the processing network computer, a transaction authorization request message from a resource provider computer, the transaction authorization request message including the digital identity certificate and a transaction amount associated with a transaction; retrieving, by the processing network computer, the token associated with the digital identity certificate; and processing, by the processing network computer, the transaction using the token. However, Hobson disclose an online card payment transaction system where the host (processing network) receives a transaction initiation via a merchant (200 receives from user 1), with a digital certificate (14) for identity verification and transaction details (Para. 44), the host validates the certificate, retrieves the user’s account, and generates the STN token linked to the certified identity (Claim 11) and the host provides processes the transaction by substituting token for account during authorization/settlement (Settlement network 393; Para. 54, User account number is resubstituted for the STN and processed for payment and transaction).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Arora with the transaction processing of Hobson. Doing so increases security prior to the transaction to ensure proper identity of the user through enhanced tokenization.
Claim(s) 3, 4, 5, 13, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Arora US 20190236592, in view of Larson US 10693872 and Allen US 20180082290, as applied to claims 1 and 11 above, further in view of Nigriny US 20150326399.
Regarding claim 3 and 13, modified Arora fails to disclose wherein associating the token with the digital identity certificate comprises: retrieving, from an authorizing entity computer, account name information associated with the account identifying information; validating the identity information corresponds with the account name information provided by the authorizing entity computer; and authenticating a signature of the identity information using a public key associated with a certification authority and part of a key pair that includes a private key used to sign the identity information, wherein the certification authority manages the digital identity certificate on the user device. However, Nigriny discloses an email validation system with a certificate authority management system that uses a server-based Certificate Validation Protocol (SCVP) acting as a validation service for public key digital signature with email addresses and other identifiers, as well as account name information, bound to the certificates subject (Para. 25, such as drivers license information, name, address, etc.), with the SCVP calculating a degree of trust attributable to the user (Para. 63, “3” in the information; Fig. 5, 540, is signature “valid”; Para. 57, At 570, SCVP server determines if certification path is valid) and authenticating the signature using a public key and key paired with a private key to sign overseen by a certification authority (Nigriniy, Para. 17, discussing a public key certificate X.509 with different fields present; Para. 45, digital signature with private key of the email sender 105 to sign message or email; Public key 130 is used in order to encrypt message and the email recipients private key used o decrypt message; Para. 15, Digital signature produced by a signing algorithm that, given a message and a private key, produces the digital signature; Para. 16, discussing Subject may utilize certificates from a Certification Authority and PKI infrastructure).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Arora with the certificate authority management system of Nigriny. Doing so creates greater security over the public private key infrastructure and greater security over the system for identification of the user and greater identity proofing (Nigriny, Para. 18).
Regarding claims 4 and 14, Nigriny also discloses where authenticating the signature further comprises: identifying, by the processing network computer, the public key associated with the certification authority that issued the digital identity certificate; and authenticating, by the processing network computer, the digital identity certificate using the public key (SVCP validation server identifies which CA issued the certificate and obtains CA public key from trust store) and authenticates the digital certificate with public key infrastructure (Fig. 5 and 7).
Regarding claim 5, Larson discloses where validating the identity information corresponds with the account name information comprises determining if a first field included in the identity information matches a second field included in the account name information (Larson, “All returned primary biometric matches are associated with the applicant's identity session ID, and are then evaluated during the live interview. The live interviewer (either human or AI agent) will have the opportunity to determine if any of the potential matches are actual matches during the live interview portion 214A-B of the enrollment process”; Fig. 2A, Client app 110 using ID scan 208 for first field and Biographic data collection 209 for second field of study for matching purposes; Also, IVS 140 performs primary biometric match with a second biometric match 206).
Regarding claim 15, wherein validating the identity information corresponds with the account name information comprises determining if a first field included in the identity information at least partially matches a second field included in the account name information (Larson, “All returned primary biometric matches are associated with the applicant's identity session ID, and are then evaluated during the live interview. The live interviewer (either human or AI agent) will have the opportunity to determine if any of the potential matches are actual matches during the live interview portion 214A-B of the enrollment process”; Fig. 2A, Client app 110 using ID scan 208 for first field and Biographic data collection 209 for second field of study for matching purposes; Also, IVS 140 performs primary biometric match with a second biometric match 206).
Claim(s) 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Arora US 20190236592, in view of Larson US 10693872 and Allen US 20180082290, as applied to claims 1 and 11, further in view of Manepalli US 20200167862.
Regarding claim 6 and 16, modified Arora fails to disclose transmitting a request to an authorizing entity computer requesting account name information, the request including the account identifying information; receiving the account name information; and comparing the account name information to the identity information. However, Manepalli discloses an authorizing entity (Identity verification server 150) that verifies access to a restricted-access content (Para. 10, network verification IS of a mobile device associated with a mobile number and personal identifying information from accredit bureau) where a returned mobile account user name is an account name associated with a mobile account and is returned in response to a request (Para. 26, mobile carrier returns name of primary source; “Returns associated user name 206), and the identity verification server 150 compares the mobile device 120 with an associated restricted-access account associated with application server 130 (Para. 20 and 21; See also Fig. 2 and 3).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Arora with the identity verification server with comparison of Manepalli. Doing so adds greater security to the system prior to approval prior to transaction.
Claim(s) 7 is rejected under 35 U.S.C. 103 as being unpatentable over Arora US 20190236592, in view of Larson US 10693872 and Allen US 20180082290, as applied to claim 1 above, further in view of Kurian US 20170243208.
Regarding claim 7, modified Arora fails to disclose wherein the digital identity certificate is stored by the user device. However, Kurian teaches that a digital identity certificate can be stored in a user device (Para. 1, “The use of mobile devices for access to secure identity applications is an emerging market that leverages the functionality and security built into mobile devices. This typically includes establishing a digital identity certificate to be stored in the mobile device that represents a person, organization, application, or device associated with the mobile device for identity verification”).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Arora with the digital identity certificate being in the mobile device of Kurian. Doing so eliminates the need for multiple identification (Para. 1, Kurian).
Claim(s) 8 is rejected under 35 U.S.C. 103 as being unpatentable over Arora US 20190236592, in view of Larson US 10693872 and Allen US 20180082290, as applied to claim 1 above, further in view of Kapczynski US 9721147.
Regarding claim 8, modified Arora fails to disclose wherein the digital identity certificate is received from a service provider application running on the user device, and wherein the message is transmitted to the service provider application. However, Kapczynski discloses a digital identity system with an identification system (Fig. 1, 100) that validates identification, issues a validated ID token to the user after validation (Step 1 and Step 3, Showing users drivers license as part of validation) and upon validation displays on the users mobile device with confirmation that identity has been validated and the user receives a validation badge confirming validation (Fig. 2-3, showing validation on users mobile device; Fig. 3c, once “the request to validate the digital ID was a success...the pre-validation badge 310 has been replaced with a validation badge 315, Fig. 3a to 3c).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Arora with the digital identity certificate receipt and messaging of Kapczynski. Doing so gives the user comfort and confidence to know that the digital certificate has been downloaded on the users device, and creates efficiency in allowing the user to now transact with their mobile device.
Claim(s) 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Arora US 20190236592, in view of Larson US 10693872 and Allen US 20180082290, as applied to claim 1 above, further in view of McDorman US 20120066750.
Regarding claim 9, Arora does not explicitly disclose, but McDormand teaches prior to receiving the account identifying information and the identity information from the user device: receiving, by the processing network computer, the digital identity certificate from the user device; authenticating, by the processing network computer, the digital identity certificate; and transmitting, by the processing network computer, an authentication result, generated by the authenticating, to the user device (see para. 0019, wherein the digital certificate is validated before information is received).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have modified the method of Arora further to include the feature taught by McDormand to facilitate a secured means of transmitting data (see McDormand, para. 0019)
Regarding claim 10, McDormand further teaches wherein authenticating the digital identity certificate further comprises: identifying, by the processing network computer, a public key associated with a certification authority that issued the digital identity certificate; and authenticating, by the processing network computer, the digital identity certificate using the public key by verifying a signature of the identity information using the public key associated with the certification authority and part of a key pair that includes a private key used to sign the identity information, wherein the certification authority manages the digital identity certificate on the user device (see para. 0019, wherein the disclosed smartcard may employ, e.g. X.509 client certificate authentication, which includes public/private key validation).
Claim(s) 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Arora US 20190236592, in view of Larson US 10693872 and Allen US 20180082290, as applied to claim 1 above, further in view of Watkins US 20050149723.
Regarding claim 9, modified Arora fails to disclose further comprising:
prior to receiving the account identifying information and the identity information from the user device: receiving, by the processing network computer, the digital identity certificate from the user device; authenticating, by the processing network computer, the digital identity certificate; and transmitting, by the processing network computer, an authentication result, generated by the authenticating, to the user device. However, Watkins discloses the generation of a key pair 504 with a transmitted certificate (Fig. 5, 502 to 504) and a transmitted certificate (504 to 506) with a server storing the certificate 506 and a transmission of a stored compared certificate 506 to 504 (Fig. 5) (Examiner notes that the recitation of “prior to receiving the account identifying information and the identity information from the user device,” could be interpreted as identity information is never used in the authentication process)
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Arora with the key paid certificate transmission and authentication of Watkins. Doing so enhances the overall security of the authentication protocol and adds an extra layer of security protection before transaction.
Regarding claim 10, modified Arora further discloses wherein authenticating the digital identity certificate further comprises: identifying, by the processing network computer, a public key associated with a certification authority that issued the digital identity certificate; and authenticating, by the processing network computer, the digital identity certificate using the public key by verifying a signature of the identity information using the public key associated with the certification authority and part of a key pair that includes a private key used to sign the identity information, wherein the certification authority manages the digital identity certificate on the user device (Watkins, Para. 3, discussing handshake public and private key; Fig. 3, Block 302 where client generates public/private key; 306 is generated before identifying information; Fig. 5, Para. 58, storing process with 504 to generate public/private key pair; Fig. 5, “verify signature” with comparison of certificate).
Claim(s) 17 is rejected under 35 U.S.C. 103 as being unpatentable over Arora US 20190236592, in view of Larson US 10693872 and Allen US 20180082290, as applied to claim 11 above, further in view of Mardikar US 8417643.
Regarding claim 17, modified Arora fails to disclose wherein the digital identity certificate provisioning transforms the digital identity certificate into a payment credential. However, Mardikar discloses a digital certificate that is loaded onto users cell device and used for payment (“In an example, when a customer invokes pre-loaded app 450 (FIG. 4), SCEP/CRMF (Simple Certificate Enrolment Protocol/Certificate Request Message Format) is invoked. A user's TSM credential or certificate 424 is entered and associated with the Service Provider's user account”; “FIGS. 5 a and 5 b illustrate an exemplary system 500 for registering client device 400. In an example embodiment, a device user may be required to register their device with the trusted service manager 505 only one time. Such registration may unlock a payment credential or CA certificate 424 (FIG. 4) pre-loaded on the device 400”; Claim 1)
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Arora with the transformation of the digital certificate to payment ability. Doing so allows the user ease-of-use to be able to now make payment without having to reveal identification again, and expedites payment processes.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Peng US 20070288392 12/3/2007 H04L9/00 discloses a secure online payment system and online payment authentication with a request for payment over the internet, using digital certificates for authentication, where the gateway validates and generates token like authentication codes and processes the payment.
Li US 20150106882 4/16/2015 H04L29/06 discloses a authentication server with public PKI infrastructure that receives account identity information and a digital identity certificate, authenticates the certificate, and transmits the authentication to a user device (Fig. 4).
Sato US 20100122081 5/13/2010 H04L9/00 discloses a method of validation public key certificate and validation server that retrieves account information with identifying information, validates the information, and authenticates the information with a public-key infrastructure with identifying certification authority, and identifies the digital key certificate using a public key.
Gupta US 7395430 7/1/2008 H04L9/00 discloses a secure authentication using digital certificates that retrieves and validates through PKI infrastructure.
Tumminaro US 20070244811 10/18/2007 G06Q40/00 discloses a mobile client application for mobile payments where the user is identify and verified through their name and account information, and the ability to pay with credit card on mobile phone.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON M DUCK whose telephone number is (469)295-9049. The examiner can normally be reached 8am - 5pm.
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, Michael Anderson can be reached at 571-270-0508. 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.
/BRANDON M DUCK/Examiner, Art Unit 3693