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 .
Continuation Application
This application was filed as a divisional of Application 18/050,003. However, claims 1-15 were canceled and claims 16-27 were newly introduced. Accordingly, this application may constitute a continuation of US Application No. 18/050,003 filed on 10/26/2022 now patent US 12,406,252 B2 (“Parent Application”). See MPEP § 201.07. In accordance with MPEP § 609.02 (II)(A)(2) and MPEP § 2001.06(b) (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also, in accordance with MPEP § 2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) is/are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicant(s) desires the information to be printed on a patent issuing from this application. See MPEP § 609.02 (II)(A)(2).
Information Disclosure Statement
The Information Disclosure Statement filed 07/24/2025 was considered. An initialed copy of the Form PTO-1449 is enclosed herewith.
Acknowledgements
This Office Action addresses the response filed on 07/24/2025.
Claims 1-15 were canceled.
Claims 16-27 were newly introduced.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitations use a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
“merchant payment system” followed by the function “configured to generate / communicate” (Claim 22)
“issuing financial institution backend” followed by the function “configured to match/validate/authorize/communicate” (Claim 22)
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitations to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 22-27 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 22 recites language interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, such as “merchant payment system configured to generate / communicate”. Since the disclosure is inadequate to support the limitation interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, the claim is being rejected for lack of written description as the disclosure is devoid of any structure for performing the claimed function. Dependent claims 23-27 are also rejected since they depend on claim 22.
Claim 22 recites language interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, such as “issuing financial institution backend configured to match/validate/authorize/communicate”. Since the disclosure is inadequate to support the limitation interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, the claim is being rejected for lack of written description as the disclosure is devoid of any structure for performing the claimed function. Dependent claims 23-27 are also rejected since they depend on claim 22.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 22-27 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 22 recites the claim limitation “merchant payment system configured to generate / communicate”, which invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The disclosure is devoid of any structure for performing the claimed function. Specifically, while the specification as filed discloses a "Merchant payment System" (see, for instance, Figs. 3A and 3B and paragraphs [0011],[0018], [0068], [0069], [0072], [0073] and [0082]-[0086], the disclosure does not recite the corresponding structure for performing the entire claimed functions. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim 22 recites the claim limitation “issuing financial institution backend configured to match/validate/authorize/communicate”, which invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The disclosure is devoid of any structure for performing the claimed function. Specifically, while the specification as filed discloses a "Financial Institution Backend (160)" (see, for instance, Fig. 1 and paragraphs [0011],[0016]-[0018], [0041], [0043], [0045], [0069]-[0072] and [0081]-[0085], the disclosure does not recite the corresponding structure for performing the entire claimed functions. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph; (b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or (c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or (b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function.
For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181. Dependent claims 23-27 are also rejected since they depend on claim 22.
Claim 22 recites: “a user electronic device for a user executing a digital wallet application”. It is unclear by the claim language whether the language “executing a digital wallet application” refers to “user electronic device” (i.e. “a user electronic device… executing a digital wallet application”), or whether it refers to “a user” (i.e. “a user executing a digital wallet application”). Specifically, it is unclear whether the "digital wallet application" is part of the "user electronic device" or not. For purposes of Examination, Examiner considers the application as being comprised by the user electronic device. If this is the intent, Examiner suggests rewording the sentence to clearly recite the relationship between the device and the application in order to avoid claim clarity issues. This duality renders the scope of the claims unclear. Dependent claims 23-27 are also rejected since they depend on claim 22.
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.
Claims 16-27 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Kamal et al. (US 2021/0049588 A1), hereinafter Kamal, in view of Kalaboukis et al. (US 10,929,841 B1), hereinafter Kalaboukis.
With respect to claims 16 and 22, Kamal teaches a system and a method for digital wallet payments (Systems and methods for use in provisioning tokens associated with digital identities) comprising:
a user electronic device for a user executing a digital wallet application (claim 22) (see Fig. 1, communication device 108, virtual wallet application, paragraph [0019]: “With continued reference to FIG. 1, the communication device 108 is associated with the user 114 and may include, for example, a portable communication device, such as a tablet, smartphone, personal computers, etc. The communication device 108 includes a transaction interface 118, which may include, in turn, a virtual wallet application installed and active in the communication device 108, or a network-enable interface associated with a merchant (e.g., a merchant website, a merchant specific application, etc.), or another suitable interface, through which a transaction may be initiated or requested. It should be appreciated that the user 114 is associated with a payment account (e.g., credit account, debit account, prepaid account, etc.) (as provided to the user 114 by an issuer of payment accounts, etc.), which may then be used to fund such transactions with one or more merchants through the transaction interface 118.”);
a distributed ledger network comprising a distributed ledger (claim 22) (see Fig. 1, ledger data structure 115, paragraph [0034]: “The IDP 102 is configured to then store the ZKP parameter in a ledger data structure 116 (which, in this embodiment, is a Blockchain data structure or other suitable type of data structure, etc.). The ZKP parameter is referenced, in the ledger data structure 116, by the identifier associated with the user 114 (e.g., at a node in the ledger data structure 116 defined by the identifier, etc.). The ledger data structure 116 may be a public data structure, in this example, whereby one or more additional entities may have access thereto. As such, it is apparent that the ZKP parameter is not revisable into the underlying data and not PII (e.g., the ZKP parameter may include a one-way hash of a one-way hash, etc.));
a merchant payment system (claim 22) (see Fig. 1, commerce platform 106, paragraph [0017]: “... In connection therewith, the commerce platform 106 is configured to facilitate initiation of the payment account transactions. The transactions may be initiated, by the users, at websites of the merchants, via mobile wallets, where the commerce platform 106 (rather than the merchants) initiate the transactions by submitting the appropriate messaging to the authorization network 104 (directly, or via a third party (e.g., via a payment gateway, an acquiring bank, etc.)). In this exemplary embodiment, the commerce platform 106 includes a secure remote commerce (SRC) service and a digital enablement service (e.g., the Mastercard® MDES, etc.), etc., which are configured to cooperate to allow the commerce platform 106 to operate as described herein.”);
a payment network (claim 22) (see Fig. 1, authorization network, paragraph [0017]: “The authorization network 104 in the system 100 is configured to facilitate authorization of payment account transactions (broadly, network transactions) performed by consumers (including the user 114) at merchants. Specifically, in this exemplary embodiment, the authorization network 104 is configured to pass authorization messages (e.g., ISO 8583 messages, etc. via payment rails, etc.) between banking institutions, whereby the banking institutions are permitted to authorize the transactions. In connection therewith, the commerce platform 106 is configured to facilitate initiation of the payment account transactions..."); and
an issuing financial institution comprising an issuing financial institution backend (claim 22) (see Fig. 1, relying party 112, paragraph [0021]: “And, finally in the system 100, the relying party 112 includes a company, a business or another entity through which the user 114 is able to transfer, hold and/or manage financials, etc.; paragraph [0047]; "; relying party 112 (i.e., the issuer of the payment account issued to the user 114)");
receiving, by a digital wallet application executed by a user electronic device, a selection of a good or service offered by a merchant (Claim 16) / the digital wallet application is configured to receive a selection of a good or service offered by a merchant (Claim 22) (see paragraph [0019]: “With continued reference to FIG. 1, the communication device 108 is associated with the user 114 and may include, for example, a portable communication device, such as a tablet, smartphone, personal computers, etc. The communication device 108 includes a transaction interface 118, which may include, in turn, a virtual wallet application installed and active in the communication device 108, or a network-enable interface associated with a merchant (e.g., a merchant website, a merchant specific application, etc.), or another suitable interface, through which a transaction may be initiated or requested..."; paragraph [0030]: “Referring again to FIG. 1, the user 114 may request that a payment token be provisioned to the communication device 108 for use with his/her payment account in connection with performing a transaction with a merchant (not shown). For example, as part of performing the transaction, the user 114 may not want to provide a primary account number (PAN) for his/her payment account to the merchant. As such, the user 114 may request that a token be provisioned to his/her communication device 108 (as associated with the payment account) (e.g., by the commerce platform 106, etc.), whereby the user 114 can then instead provide the token to the merchant to initiate the transaction (e.g., through use of the transaction interface 118, etc.). In connection with generating such a payment token, for example, the user 114 may initially interact with the merchant, via the transaction interface 118, at his/her communication device 108...”; paragraph [0042]: “Initially in the method 300, the user 114 seeks to provision a payment token to the communication device 108 for use in transactions initiated through the transaction interface 118 at a merchant (and/or at multiple other merchants). This may be done as part of a current transaction at the merchant, or it may be done by the user 114 as a separate interaction with the transaction interface 118 in advance of any transaction with the merchant. In either case, as explained above, the transaction interface 118 may include a merchant website or network-enabled application, or a wallet application associated with a payment network and/or banking institution...");
receiving, by the digital wallet application, authentication information from a user (Claim 16) / the digital wallet application is configured to receive authentication information from the user (Claim 22) (see paragraph [0030]: “...As part of this interaction (e.g., upon accessing the transaction interface 118, etc.), the communication device 108, as configured by the transaction interface 118, captures a biometric of the user 114 and generates a hashed biometric template (based on the captured biometric and a signature/fingerprint stored in the communication device 108)”);
authenticating, by the digital wallet application, the authentication information (Claim 16) / the digital wallet application is configured to authenticate the authentication information (Claim 22) (see paragraph [0037]: “...The authentication request may, potentially, further include a newly generated hashed biometric template for the user 114 which is accessible based on the user 114 being biometrically authenticated again at the communication device 108 (whereby the communication device 108 may require biometric authentication of the user 114 at the start of each transaction and generate a hashed biometric template for each transaction)..." );
retrieving, by the digital wallet application, a digital identity identifier for the user, wherein the digital identity identifier comprises a digital identity identifier token that is stored in secure storage of the user electronic device or a pointer to the digital identity identifier that is stored on a distributed ledger in a distributed ledger network (Claim 16) / the digital wallet application is configured to retrieve a digital identity identifier for the user, wherein the digital identity identifier comprises a digital identity identifier token that is stored in secure storage of the user electronic device or a pointer to the digital identity identifier that is stored on the distributed ledger (Claim 22) (see paragraph [0031]: “The communication device 108 is configured to then transmit a tokenization request to the commerce platform 106 for the token prior to initiating the transaction (e.g., as a specified operation of the transaction interface 118 when performing such transaction, etc.). The tokenization request includes the hashed biometric template generated by the communication device 108 as well as device data unique to the communication device 108 (e.g., a MAC address, an ESN, a digital device identifier (DDI), etc.), the PAN for the user's payment account (as issued by the relying party 112 in this example), and additional personal identifying information (PII) or identity attributes for the user 114 (e.g., a mailing address, an email address, a phone number, a birthdate, etc.).”; paragraph [0013]: “Uniquely, the systems and methods herein enable payment tokens to be provisioned to users in connection with (or through use of) their digital identities. In particular, in response to a tokenization request by a user for a payment account, a digital identity provider receives a hashed biometric template for the user, via an enhanced authentication platform, and verifies the user associated with the hashed biometric template. When verified, the digital identity provider derives and stores one or more zero-knowledge proof parameters as an entry in a ledger data structure (e.g., a Blockchain data structure in memory, etc.), and then provides an identifier associated with the entry, whereby a token may be provisioned to a communication device associated with the user or to a transaction interface (e.g., a merchant website, etc.)...");
communicating, by the digital wallet application, a payment token for the selected payment mechanism to a merchant payment system, wherein the merchant payment system is configured to generate a transaction authorization message and to communicate the transaction authorization message and the payment token to an issuing financial institution backend over a payment network (Claim 16) / the digital wallet application is configured to communicate a payment token for the selected payment mechanism to the merchant payment system; the merchant payment system is configured to generate a transaction authorization message; the merchant payment system is configured to communicate the transaction authorization message and the payment token to the issuing financial institution backend over the payment network (Claim 22) (see paragraph [0036]: “Upon receipt of the identifier associated with the user 114, the commerce platform 106 is configured to generate a token, which binds the device data (i.e., the data indicative of the communication device 108), the identifier of the user 114, and the PAN for the user's payment account. The commerce platform 106 is configured to then transmit the token to the communication device 108, which is configured, in turn, to store the token in connection with the transaction interface 118 (e.g., in a secure element (SE) associated with a virtual wallet application of communication device 108, a merchant specific application, or a merchant website, etc.), for use in subsequent transactions (including the transaction currently being initiated) to identify the user's payment account, via the transaction interface 118.”; paragraph [0037]: “Subsequently, in connection with the current payment account transaction by the user 114 at the merchant, the communication device 108 is configured, by the transaction interface 118, to transmit an authentication request including the payment token (or a part thereof) along with the identifier of the user 114 (separately or as bound in the token), to the commerce platform 106 (through which the transaction is initiated). The authentication request may, potentially, further include a newly generated hashed biometric template for the user 114 which is accessible based on the user 114 being biometrically authenticated again at the communication device 108 (whereby the communication device 108 may require biometric authentication of the user 114 at the start of each transaction and generate a hashed biometric template for each transaction). Alternatively, the authentication request may include the hashed biometric template for the user 114 as previously generated for the user 114 (and stored either at the communication device 108 or at the commerce platform 106), yet still protected by a biometric authentication of the user 114 (e.g., where the hashed biometric is a reference, etc.) (whereby the same biometric template may be reused for the current transaction and subsequent transactions, indefinitely or for a defined interval, etc.)”);
communicating, by the digital wallet application, the digital identity identifier token or the pointer to the digital identity identifier on the distributed ledger to the issuing financial institution backend over a payment network (Claim 16) / the digital wallet application is configured to communicate the digital identity identifier token or the pointer to the digital identity identifier on the distributed ledger to the issuing financial institution backend over a payment network (Claim 22) (see paragraph [0031]: “The communication device 108 is configured to then transmit a tokenization request to the commerce platform 106 for the token prior to initiating the transaction (e.g., as a specified operation of the transaction interface 118 when performing such transaction, etc.). The tokenization request includes the hashed biometric template generated by the communication device 108 as well as device data unique to the communication device 108 (e.g., a MAC address, an ESN, a digital device identifier (DDI), etc.), the PAN for the user's payment account (as issued by the relying party 112 in this example), and additional personal identifying information (PII) or identity attributes for the user 114 (e.g., a mailing address, an email address, a phone number, a birthdate, etc.)”);
matching, by the issuing financial institution backend, the transaction authorization message and the payment token to the digital identity identifier token or the pointer to the digital identity identifier on the distributed ledger (Claim 16) / the issuing financial institution backend is configured to match the transaction authorization message and the payment token to the digital identity identifier token or the pointer to the digital identity identifier on the distributed ledger (Claim 22) (see paragraph [0038]: “In either case, the commerce platform 106, in turn, is configured to validate the token and to transmit the identifier, and potentially, the hashed biometric template for the user 114 (either received from the communication device 108 as part of the instant transaction or retrieved from memory 204 of the commerce platform 106 based on the prior interaction with the user 114 in connection with the tokenization request, etc.) to the authorization network 104, and specifically, the 3DS platform 120. It should be appreciated that, in some embodiments, the token or a part of the token may be maintained at the communication device 108, and not therefore transmitted as part of the authentication request to the commerce platform 106 (whereby the token may be maintained at the communication device 108, etc.).”; paragraph [0039]: “In turn, the 3DS platform 120 is configured to transmit the identifier, and potentially, the hashed biometric template for the user 114, to the IDP 102. The IDP 102 is configured to generate at least one subsequent ZKP for the user 114 based on the identifier and the hashed biometric template for the user 114 (as included in the transmission from the 3DS platform 120 or retrieved from memory 204, when necessary). The IDP 102 is further configured to check or validate the generated subsequent ZKP against (or with) the previously generated ZKP parameter from the ledger data structure 116 (as located at a node in the ledger data structure 116 defined by the identifier, etc.). The IDP 102 is configured to verify the transmission from the 3DS platform 120 and/or the user 114 when the subsequent ZKP is validated or confirmed against the ledger data structure 116. When validated, the IDP 102 is configured to then transmit the identifier of the user 114 as verified (i.e., as a verified identifier) back to the 3DS platform 120 (generally, in response to the authentication request)”);
validating, by the issuing financial institution backend, the digital identity identifier token or the digital identity identifier pointer (Claim 16) / the issuing financial institution backend is configured to validate the digital identity identifier token or the digital identity identifier pointer (Claim 22) (see paragraph [0040]: “The 3DS platform 120, in turn, is configured to transmit the verified identifier to the relying party 112 (and specifically, an ACS associated therewith). The relying party 112 is configured to determine at least one further ZKP and to check, via an application programming interface (API) call, to the IDP 102, the immutability of the at least one further ZKP again based on the ZKP parameter in the ledger data structure 116 (again, at a node in the ledger data structure 116 defined by the identifier)...”);
authorizing, by the issuing financial institution backend, the transaction authorization message (Claim 16) / the issuing financial institution backend is configured to authorize the transaction authorization message (Claim 22) (see paragraph [0040]: “... The relying party 112 is configured to confirm the verification to the 3DS platform 120, which, in turn, is configured to indicate the strong verification in an accountholder authentication value (AAV) back to the commerce platform 106 (based on verification by the IDP 102 and by the relying party 112). Once received at the commerce platform 106, the transaction authorization may proceed with interactions between the commerce platform 106, the authorization network 104 and the relying party 112. In connection therewith, the relying party 112 is able to rely, at least in part, on the indication of the strong verification to permit the transaction to be authorized”); and
communicating, by the issuing financial institution, authorization to the merchant payment system (Claim 16) / the issuing financial institution backend is configured to communicate authorization to the merchant payment system (Claim 22) (see paragraph [0040]: “... Once received at the commerce platform 106, the transaction authorization may proceed with interactions between the commerce platform 106, the authorization network 104 and the relying party 112. In connection therewith, the relying party 112 is able to rely, at least in part, on the indication of the strong verification to permit the transaction to be authorized”).
Although Kamal discloses including the PAN for the user's payment account in the tokenization request (see paragraph [0031]), Kamal does not explicitly disclose a method and system comprising: wherein a plurality of payment mechanisms that are onboarded to the digital wallet application (Claim 22); selecting, by the digital wallet application, a payment mechanism out of a plurality of payment mechanisms onboarded to the digital wallet application (Claim 16) / the digital wallet application is configured to select one of the plurality of payment mechanisms onboarded to the digital wallet application (Claim 22).
However, Kalaboukis discloses a method and system (Systems and methods for providing an adaptable mobile wallet with sub-wallets) comprising:
wherein a plurality of payment mechanisms that are onboarded to the digital wallet application (Claim 22) (see col. 3, lines 50-59: “The user then creates one or more sub-wallets with the mobile wallet computing system. As used herein, a “sub-wallet” is a subset of the items stored in the master wallet and may be centered around a particular theme or category. For example, the user may create a travel sub-wallet that includes a travel credit card held by the user, the user's passport, and boarding passes for upcoming flights. Alternatively, the mobile wallet computing system suggests one or more sub-wallet configurations to the user based on, for example, the items stored in the user's master wallet”);
selecting, by the digital wallet application, a payment mechanism out of a plurality of payment mechanisms onboarded to the digital wallet application (Claim 16) / the digital wallet application is configured to select one of the plurality of payment mechanisms onboarded to the digital wallet application (Claim 22) (see col. 25 lines 41-58: “In some embodiments, when a payment vehicle selection is necessary for a sub-wallet that has been tokenized as a whole, the mobile wallet computing system 104 may select the payment vehicle with the most rules matching the transaction. For example, referring to FIG. 7, if the transaction is for groceries, printer paper, and a blender, the mobile wallet computing system 104 may determine that the transaction is for groceries, office supplies, and kitchen items. The mobile wallet computing system 104 may accordingly use the personal credit card for the transaction, as the transaction predominantly matches the rules for the personal credit card, as shown in section 704. In other embodiments, the mobile wallet computing system 104 may split the transaction into multiple payments for multiple payment vehicles. Referring back to the previous example, the mobile wallet computing system 104 may charge the groceries and the blender to the personal credit card and the printer paper to the business credit card”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the payment selection mechanism as disclosed by Kalaboukis in the method and system of Kamal, the motivation being to select the payment vehicle with the most rules matching the transaction (see Kalaboukis, col. 25 lines 41-58).
With respect to claims 17 and 23, the combination of Kamal and Kalaboukis teaches all the subject matter of the method and system as described above with respect to claims 16 and 22. Furthermore, Kamal discloses a method and system wherein the authentication information comprises a login credential, a passcode, a personal identification number, and /or biometric (see paragraph [0043]: “In connection with the tokenization request, the communication device 108 also transmits, at 304, a hashed biometric template for the user 114 to the commerce platform 106. As part thereof, the communication device 108 prompts the user 114 to capture a biometric, such as a selfie or facial image or other biometric (via the input device 208), whereupon the communication device 108 captures the image (in this example) and converts the image to a biometric template. The communication device 108 further hashes the biometric template, by encoding the biometric template with a signature or fingerprint (e.g., stored in memory of the communication device 108 or provided by the user 114 as part of capturing the biometric, etc.). In this exemplary embodiment, the hash is a one-way hash, whereby the biometric template is not able to be reconstructed by another device from the hashed biometric template. With that said, the hashed biometric template may be included in (e.g., as part of, etc.) the tokenization request or it may be transmitted to the commerce platform 106 separate therefrom, yet still identified to (or linked to) the communication device 108, whereby it may also be identified to the tokenization request received from the communication device 108.”). Regarding the BRI of the claims, Examiner notes that claims 17 and 23 recite “wherein the authentication information comprises a login credential, a passcode, a personal identification number, and /or biometric”, language directed to non-functional descriptive material. See MPEP 2111.05. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claims 18 and 24, the combination of Kamal and Kalaboukis teaches all the subject matter of the method and system as described above with respect to claims 16 and 22. Furthermore, Kamal discloses a method and system wherein the digital identity identifier comprises user information for the user, the authentication information, and /or an attestation issued by an attestation issuing authority (see paragraph [0030]: "...hashed biometric template (based on the captured biometric and a signature/fingerprint stored in the communication device 108)"). Regarding the BRI of the claims, Examiner notes that claims 18 and 24 recite “wherein the digital identity identifier comprises user information for the user, the authentication information, and /or an attestation issued by an attestation issuing authority”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claims 19 and 25, the combination of Kamal and Kalaboukis teaches all the subject matter of the method and system as described above with respect to claims 18 and 24. Furthermore, Kamal discloses a method and system wherein the user information comprises a user name and user contact information for the user (see paragraph [0020]: “In addition in the system 100, the user 114 is associated with an identity, which includes one or more identity attributes, such as a name, a mailing address, a government ID number, an email address, a phone number, a birthdate, biometric (e.g., facial images, fingerprints, palm prints, etc.), a gender, an age, an eye color, account numbers, an employee identifier, and/or other information sufficient to distinguish the user 114 from other users. The identity of the user 114 may further include a digital identity of a device associated with the user 114, in some embodiments (e.g., electronic serial number (ESN), mac address, IP address, etc. of the communication device 108, etc.)..."). Regarding the BRI of the claims, Examiner notes that claims 19 and 25 recite “wherein the user information comprises a user name and user contact information for the user”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claims 20 and 26, the combination of Kamal and Kalaboukis teaches all the subject matter of the method and system as described above with respect to claims 16 and 22. Furthermore, Kalaboukis discloses a method and system wherein the digital wallet application selects the payment mechanism based on a merchant type, a transaction amount, and a type of transaction (see col. 25 lines 41-58: “In some embodiments, when a payment vehicle selection is necessary for a sub-wallet that has been tokenized as a whole, the mobile wallet computing system 104 may select the payment vehicle with the most rules matching the transaction. For example, referring to FIG. 7, if the transaction is for groceries, printer paper, and a blender, the mobile wallet computing system 104 may determine that the transaction is for groceries, office supplies, and kitchen items. The mobile wallet computing system 104 may accordingly use the personal credit card for the transaction, as the transaction predominantly matches the rules for the personal credit card, as shown in section 704. In other embodiments, the mobile wallet computing system 104 may split the transaction into multiple payments for multiple payment vehicles. Referring back to the previous example, the mobile wallet computing system 104 may charge the groceries and the blender to the personal credit card and the printer paper to the business credit card”). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claims 21 and 27, the combination of Kamal and Kalaboukis teaches all the subject matter of the method and system as described above with respect to claims 16 and 22. Furthermore, Kalaboukis discloses a method and system wherein the selected payment mechanism comprises a credit card, a debit card, a demand deposit account (DDA) transfer, a line of credit, a payment with reward points, a cryptocurrency, or a payment via a third-party payment provider (see col. 3, lines 18-27: “As used herein, the term “payment vehicle” refers to any card, account, or any other currency-attached object, virtual file, or database from which a user can transfer funds to another entity. Example payment vehicles include bank accounts, (e.g., checking accounts and savings accounts), other user accounts (e.g., flexible spending accounts, IRA accounts, health savings accounts, investment accounts, and the like), transaction cards (e.g., gift cards, credit cards, debit cards), and financial rewards (e.g., cash back, rewards points, and the like)”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Basak et al. (US 2021/0349882 A1) disclose establishing decentralized identifiers for algorithms, data schemas, data sets, and algorithm execution requests, including a resolvable link to a protected service endpoint at an attestation provider where high-assurance vetted attribute information about the subject can be obtained.
Radu (US 2017/0017957 A1) discloses authentication system and method for server-based payments, including a device authentication phase and a user authentication phase for each payment transaction. The device authentication phase includes cryptographically hidden presentation of a session key from a preceding transaction from the user device to the wallet server and verification of the session key by the wallet service. The user authentication phase includes provision of the device authentication session key for the next transaction from the wallet server to the user device as well as the provision of the user authentication session key for the current transaction. The user authentication phase further includes entry of a secret PIN by the user.
Kadiwala et al. (US 2021/0065156 A1) disclose methods and systems for enhancing online payment transaction experience, including receiving, by a server system associated with a payment network, a tokenization request based on selecting a payment card of a plurality of payment cards of a user from a payment application running on a user device for processing an online payment transaction using the selected payment card at a merchant payment interface on the user device.
Patterson (US 2012/0079581 A1) discloses method and system using universal id and biometrics, including a "first identifier" as any suitable type of account information that can be used to identify an account or a person associated with that account. Examples of first identifiers can include a BIN (Bank Identification Number), a CVV (Card Verification Value), expiration date, phone number, address, etc. and a "second identifier" including any suitable biometric data for a payment transaction.
Healy et al. (US 2016/0260090 A1) disclose system and method for mobile checkout, including displaying payment cards in a payment option screen of a mobile device to appear as digital representations of an actual payment card, including any logos, banking names, and the like.
Pillai et al. (US 2017/0103388 A1) disclose multi-path communication of electronic device secure element data for online payments, including at least one commerce credential securely provisioned on a secure element of an electronic device.
Rao et al. (US 2023/0259918 A1) disclose decentralized identity on blockchain for a multi-sided network, including allowing a holder entity to provide a minimal set of PII to a verifier to satisfy the requirements of the verifying entity while providing the least amount of information possible (e.g., without oversharing private user data).
Robinson-Morgan et al. (US 2023/0073938 A1) disclose systems and methods for use in implementing self-sovereign credentials, including self-sovereign credentials indicative of identities of users, which are provisioned to the users and controlled by the users. In particular, an identity provider participates (e.g., as an issuer or as service, etc.) for the issuing of the self-sovereign (or verifiable) credentials for users, to mobile devices of the users. The credentials may then be leveraged by relying parties, in interacting with the users, where the credentials are verified by the identity provider, or through service(s) associated with the identity provider, to thereby verify identities of the users.
Dalit et al. (US 8,577,810 B1) disclose secure mobile payment authorization, including sending account information stored in the mobile device along with biometrics to a verification server to verify the identity of the consumer for authorizing the mobile payment.
Mathew (US 2016/0110529 A1) discloses methods, apparatus and systems for securely authenticating a person depending on context, including generating a token that can identify and connect a user to any particular system or systems required to validate and/or authenticate and/or exchange information or data for purposes of authenticating the user. Tokens generated in such scenarios can act as a common link or unique identifier to connect a particular consumer with any of his or her wallets in the meta-wallet architecture.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDUARDO D CASTILHO whose telephone number is (571)270-1592. The examiner can normally be reached Mon-Fri 8-5.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/EDUARDO CASTILHO/Primary Examiner, Art Unit 3698
Prosecution Insights