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 .
Information Disclosure Statement
The Information Disclosure Statement filed 11/21/2022 was considered. An initialed copy of the Form PTO-1449 is enclosed herewith.
Election/Restrictions
Applicant’s election without traverse of claims 1-13 in the reply filed on 11/07/2025 is acknowledged.
Claims 14 and 15 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected subcombination, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 11/07/2025.
Acknowledgements
This Office Action is in response to the amendment received on 11/14/2022.
Claims 14 and 15 were withdrawn.
Claims 1-13 are pending.
Claims 1-4, 6, 7, 9, 12 and 13 were treated on the merits (see claim objections below).
Claim Objections
Claims 5 and 8 are objected to under 37 CFR 1.75(c) as being in improper form because a multiple dependent claim cannot depend from any other multiple dependent claim. Claims 5 depends on claims 3 and 4 (both multiple dependent claims) and Claim 8 depends on claim 4, a multiple dependent claim. See MPEP § 608.01(n). Accordingly, the claims have not been further treated on the merits.
Claims 10 and 11 are objected to under 37 CFR 1.75(c) as being in improper form because a multiple dependent claim should refer to other claims in the alternative only. Claim 10 depends on a range of claims 1-9 and claim 11 depends on a range of claims 1-10, none of these ranges are in the alternative form. See MPEP § 608.01(n). Accordingly, the claims have not been further treated on the merits.
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.
Claim 13 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because claim 13 is directed to “a computer program product comprising instructions which, when the program is executed by a computer…”, which establishes that the claim is directed to software per se in the “product”. Software is defined as "Computer programs; instructions that make hardware work. Two main types of software are system software (operating systems), which control the workings of the computer, and applications, such as word processing programs, spreadsheets, and databases, which perform the tasks for which people use computers." - See Microsoft Computer Dictionary, Fifth Edition 2002, page 489. According to MPEP 2106 II IV, however, there are four categories of invention: process, machine, article of manufacture or composition of matter. Therefore, as “software” is neither a category of invention nor a subset of one of the categories it does not represent patent eligible subject matter, see In re Nuijten, 84 U.S.P.Q.2d 1495 (Fed. Cir. 2007).
Claims 1-4, 6, 7 9, 12 and 131 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-4, 6, 7 and 9 are directed to a method, claim 12 is directed to an apparatus. Therefore, these claims fall within the four statutory categories of invention. Specifically, the language of the claims that recite an abstract idea are marked in bold below:
a. “receiving a first electronic message comprising information indicative of the first party;”;b. “generating a first electronic token in response to receiving the information indicative of the first party;”;c. “sending the first electronic token to the first party;”;d. “receiving one or more second electronic messages from the second party, the one or more second electronic messages comprising the first electronic token and information indicative of the second party;”;e. “generating a second electronic token in response to receiving the first electronic token and the information indicative of the second party from the second party;”;f. “associating the information indicative of the first party, the second party and the second electronic token, the first party being identified on the basis of the first electronic token; and”;g. “sending the second electronic token to the first party.”
Therefore, the portions highlighted in bold above recite establishing a contractual relationship, which is an abstract idea grouped within the certain methods of organizing human activity grouping of abstract ideas in prong one of step 2A of the Alice/Mayo two-part test (see MPEP 2106.04). The claims are grouped within certain methods of organizing human activity because the steps recited describe the commercial or legal interaction of providing a transaction performance guaranty by collecting information and issuing guarantees (i.e. tokens). Accordingly, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application. Specifically, with respect to using circuitry, computer to perform the recited steps/functions, these additional elements performs the steps or functions such as: “receiving… message…”, “generating… token…”, “sending… token…”, “receiving… message…”, “generating… token…”, “sending… token…”. These additional elements are recited at a high-level of generality such that it represents no more than mere instructions to apply the exception using a generic computer component, which only serves to use computers as a tool to perform the abstract idea. Therefore, these elements do not integrate the abstract idea into a practical application because they require no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional element(s) of electronic message/token amount to generally linking the use of the judicial exception to a particular technological environment or field of use. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, following the analysis of step 2A, prong two, the claims are still directed to an abstract idea.
With respect to step 2B of the analysis, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the claims recite additional computer elements, such as circuitry, computer, electronic message/token. The circuitry, computer perform the steps/functions of “receiving… message…”, “generating… token…”, “sending… token…”, “receiving… message…”, “generating… token…”, “sending… token…”, and amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept beyond the abstract idea of establishing a contractual relationship. The additional element(s) of electronic message/token amount to generally linking the use of the judicial exception to a particular technological environment or field of use.. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions that correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of establishing a contractual relationship. Therefore, the claims are not eligible.
Dependent claims 2-4, 6, 7 and 9 further recite the following additional language, in which elements which merely further define the identified abstract idea are marked in bold below:
h) further comprising: receiving an electronic transaction request comprising information indicative of a transaction requesting party, an electronic token and a requested transaction between the transaction requesting party and the second party; authorizing the requested transaction when it is determined that the transaction requesting party and the received electronic token match, respectively, the first party and the second electronic token associated with the second party. i) wherein the one or more second electronic messages comprise: information indicative of one or more limits, and the method comprises associating the information indicative of the one or more limits with the associated information indicative of the first party, the second party and the second electronic token. j) further comprising: receiving an electronic transaction request comprising information indicative of a transaction requesting party, an electronic token and a requested transaction between the transaction requesting party and the second party; authorizing the requested transaction when it is determined that the transaction requesting party and the received electronic token match, respectively, the first party and the second electronic token associated with the second party and that the requested transaction conforms to the one or more limits associated with the first party, second party and second electronic token. k) further comprising: receiving a modification request from the second party; and modifying the association between the information indicative of the first party, the second party, the second electronic token and the one or more limits in accordance with the modification request. l) wherein the modification request comprises: at least one of a request to modify the information indicative of the one or more limits and a request to delete the association between the first party, the second party, the second electronic token and the information indicative of the one or more limits. m) further comprising: sending a fourth electronic message to the second party, the fourth electronic message comprising information requesting authorization of the requested transaction, when the transaction requesting party and the received electronic token match, respectively, the first party and the second electronic token associated with the second party and when the requested transaction does not conform to the one or more limits; receiving a fifth electronic message indicative of authorization information from the second party; and authorizing the requested transaction when the authorization information indicates that authorization has been granted by the second party.
Examiner notes that, for elements recited in the dependent claims which were previously analyzed as additional elements of the independent claims above (i.e. circuitry, computer), the assessment of these elements under step 2A and step 2B for the dependent claims is inherited from the analysis of the independent claims and omitted for brevity, unless noted by Examiner below. Examiner also notes the additional element “electronic transaction request” was treated in the same manner as electronic message/token above.
With respect to the eligibility analysis of claim 2, Examiner notes that claim 2 recites “authorizing the requested transaction when it is determined that the transaction requesting party and the received electronic token match, respectively, the first party and the second electronic token associated with the second party.” language directed to a contingent limitation. The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) (precedential) for an analysis of contingent claim limitations in the context of both method claims and system claims. See also MPEP 2111.04. Therefore, the broadest reasonable interpretation of claim 2 does not require the step of “authorizing”. Therefore, the claim recites item h) above, which represents the additional elements/functions of receiving a request. This language further elaborates the abstract idea of establishing a contractual relationship identified in the analysis of independent claim 1. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 3, Further, the claim recites item i) above, which represents the additional elements/functions of associating information. This language further elaborates the abstract idea of establishing a contractual relationship identified in the analysis of independent claim 1 and dependent claim 2. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 4, Examiner notes that claim 4 recites “authorizing the requested transaction when it is determined that the transaction requesting party and the received electronic token match, respectively, the first party and the second electronic token associated with the second party and that the requested transaction conforms to the one or more limits associated with the first party, second party and second electronic token” , language directed to a contingent limitation. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) (precedential) for an analysis of contingent claim limitations in the context of both method claims and system claims. See also MPEP 2111.04. Therefore, the claim recites item j) above, which represents the additional elements/functions of receiving a request. This language further elaborates the abstract idea of establishing a contractual relationship identified in the analysis of claims 1/2/3 and 1/3. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 6, the claim recites item k) above, which represents the additional elements/functions of receiving a request and modifying an association. This language further elaborates the abstract idea of establishing a contractual relationship identified in the analysis of independent claims 1/2/3 and 1/3. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to claim 7, the claim includes language which do not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what the request "comprises". Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of establishing a contractual relationship identified in the analysis of independent claims 1/2/3/6 and 1/3/6. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 9, Examiner notes that claim 9 recites “sending a fourth electronic message to the second party, the fourth electronic message comprising information requesting authorization of the requested transaction, when the transaction requesting party and the received electronic token match, respectively, the first party and the second electronic token associated with the second party and when the requested transaction does not conform to the one or more limits;”; “authorizing the requested transaction when the authorization information indicates that authorization has been granted by the second party” , language directed to contingent limitations. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) (precedential) for an analysis of contingent claim limitations in the context of both method claims and system claims. See also MPEP 2111.04. Therefore, the claim recites item m) above, which represents the additional elements/functions of sending and receiving messages. This language further elaborates the abstract idea of establishing a contractual relationship identified in the analysis of independent claims 1, 12 and 13. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
Therefore, while the additional language h)-m) of dependent claims 2-4, 6, 7 and 9 slightly modify the analysis provided with respect to independent claim 1, these additional elements/functions are insufficient to render the dependent claims eligible, as detailed above. Therefore, these dependent claims are also ineligible.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-4, 6, 7, 12 and 13 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Zagarese et al. (US 2018/0181964 A1).
With respect to claims 1, 12 and 13, Zagarese et al. teach an apparatus for associating a first party and a second party; a computer program product comprising instructions (see Fig. 1, memory 108, processor 114, paragraph [0131]); and a method of associating a first party and a second party, (Secure electronic payment) comprising:
receiving a first electronic message comprising information indicative of the first party (see paragraph [0140]: “To obtain the sharing token, the user provides to digital identity system 1 in an electronic sharing token request message his user key (in an encrypted form) along with the database key(s) of the attributes he wishes to be bound to the sharing token, and thus rendered available to a validator who subsequently receives the sharing token from the bearer.”; Fig. 5, paragraph [0220]: “In the transaction of FIG. 5 the merchant adopts the role of “bearer”, and the purchaser is the “validator” according to the terminology used above...");
generating a first electronic token in response to receiving the information indicative of the first party (see paragraph [0142]: “Provided the sharing token request is determined by the digital identity system 1 to be legitimate, the sharing token is generated and issued to the bearer…");
sending the first electronic token to the first party (see paragraph [0142]: “Provided the sharing token request is determined by the digital identity system 1 to be legitimate, the sharing token is generated and issued to the bearer…"; Fig. 5, sharing token 502, paragraph [0221]: “Initially, the merchant device 12M obtains a sharing token 502 (corresponding to sharing token S in FIG. 3) in accordance with steps S302 to S304c of FIG. 3...");
receiving one or more second electronic messages from the second party, the one or more second electronic messages comprising the first electronic token and information indicative of the second party; (see paragraph [0177]: “Preferably, the bearer and validator policies pB and pV are rendered on a display of the validator device 12v, so that the validator can see (i) the attribute(s) of the bearer that the bearer is willing to share and (ii) the attribute(s) of the validator that the validator must share in return. Assuming the validator is happy to proceed on this basis, at step S308 he causes a validation message to be sent to the validation service 14b. The validation message comprises the following: [0178] the sharing token S; [0179] the sharing key Sk; [0180] both of the policies pB and pV; Fig. 5, step 506, paragraph [0222]: “At step S506 which corresponds to step S306 in FIG. 3, the sharing token 502 is captured at the purchaser device 12P along with a copy of the validator policy pV (not shown in FIG. 5) so that the purchaser can see what it is that the merchant device 12M is requesting. Assuming that the purchaser is willing to proceed, then at step S408 (corresponding to S308) the captured sharing token 502 is transmitted to the digital identity system along with the purchaser credential 504 and the validator policy pV.);
generating a second electronic token in response to receiving the first electronic token and the information indicative of the second party from the second party; (see paragraph [0223]: “At this point, the transaction proceeds in exactly the way described in FIG. 3 in relation to the purchaser's identity attributes labelled 505 in FIG. 5. In addition, however, the digital identity system 1 decrypts the user's payment attribute (labelled 506) held in the secure store 24, which it submits to a token provider 508 to obtain a payment token 410 that can be used in place of the card details 506. The user's card details or other payment attribute(s) 506 can be captured during enrolment or added later. For a payee-specific payment token, the payee credential (to which the sharing token is linked; i.e., with reference to FIG. 3, the credential cB presented at step S302 in order to obtain the sharing token Sk captured by the payer at step S506) can be submitted with the payment attribute 506, and used to generate a token that is specific to the payee...”);
associating the information indicative of the first party, the second party and the second electronic token, the first party being identified on the basis of the first electronic token; and (see paragraph [0223]: “...That is, in this context the underlying payee credential serves as an identifier to which the payment token is bound, such that is can only be used by the payee. That is, the payee credential itself provides data that is unique to the payer for the purpose of generating the payee-specific payment token.”); and
sending the second electronic token to the first party. (see Fig. 5, p[payment token 510, paragraph [0224]: “The payment token 410 can for example be obtained via an API of the token provider 508. Although not shown in FIG. 5 the method proceeds in exactly the same way as in FIG. 3 with the payment token 510 being published and retrieved using the link in the receipt 32b issued to the merchant device 12M in exactly the same way as the shared identity attribute or attributes 505. Alternatively, rather than publishing the payment token 510, it could be rendered available to the merchant device directly along with (e.g. as part of) the receipt 32b. Either way, the upshot is that the merchant device 12M receives or is able to obtain the payment token 510 and the shared identity attributes 505 at the end of the transaction of FIG. 5...").
With respect to claim 2, Zagarese et al. teach all the subject matter of the method as described above with respect to claim 1. Furthermore, Zagarese et al. disclose a method further comprising:
receiving an electronic transaction request comprising information indicative of a transaction requesting party, an electronic token and a requested transaction between the transaction requesting party and the second party (see paragraph [0224]: “...Assuming the purchaser's identity is successfully verified at the merchant device 12M, the merchant can proceed with accepting the payment. This is done by the merchant device 12M submitting the payment token 510 back to the token provider 508, for example via a payment API provided by the token provider 508. In this example, the token provider 508 also acts as a payment processor. However, the payment could also be processed by a separate payment processing entity.”);
authorizing the requested transaction when it is determined that the transaction requesting party and the received electronic token match, respectively, the first party and the second electronic token associated with the second party (see Fig. A12, paragraph [0780]: “A uPass transaction can be conducted between three entities (such as bearer 20, validator 52, and validation service (authenticator) 14b), as shown in figure A12. In figure A12F represents a function to be executed. This may be a simple validation. It may also be an operation specific to the secure store 24 as expressed by a public API. A represents an authentication wrapper for F. The bearer 20 (e.g. customer) sends their credential Cc to the validator 52 (e.g. merchant) in a first electronic message. The validator sends its own credential Cm with the bearer credential Cc with an indicator of the function F to be executed to the authenticator 14b in a second electronic message (“CmF(Cc)”). The authenticator sends CmF(Cc) with an indicator of the authentication wrapper A and its own credential Ca to the secure store 24. A set of four receipts R1, R2, R3, R4 ({Ri}) is generated. A master receipt for the transaction is stored in the master receipt book 31, and bearer/validator receipts 32v/32b (R2/R3) are issued to the bearer and validator 20, 52. R1 is issued to the authenticator 14b, and R4 is logged in a secure access log 1202. All of the receipts R1, R2, R3,R4 and the master receipt share a transaction identifier which links them all together”).
Regarding the BRI of the claim, Examiner notes that claim 2 recites “authorizing the requested transaction when it is determined that the transaction requesting party and the received electronic token match, respectively, the first party and the second electronic token associated with the second party.” , language directed to contingent limitations. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) (precedential) for an analysis of contingent claim limitations in the context of both method claims and system claims. See also MPEP 2111.04.
With respect to claim 3, Zagarese et al. teach all the subject matter of the method as described above with respect to claims 1 and 1/2. Furthermore, Zagarese et al. disclose a method wherein the one or more second electronic messages comprise: information indicative of one or more limits, and the method comprises associating the information indicative of the one or more limits with the associated information indicative of the first party, the second party and the second electronic token (see paragraph [0167]: “The request Req also comprises a bearer policy pB. The bearer policy pB is defined by the bearer using his device 12b, and specifies one or more types of attribute types that he is willing to share. For example, the bearer specify, as a minimum, that he is willing to share a selfie and, optionally, that he is also willing to share his name and/or date of birth etc. To enable the sharing of these attributes, the request also comprises the set of database key(s) {KaB} for the identified attributes(s), so that they can be located in the secure store 24. Either policy may also specify a time for which the sharing token Sk is valid, after which it expires.”; paragraph [0168]: “The request Req also comprises a validator policy pV, which is also defined by the bearer. The bearer-defined validator policy pV specifies one or more types of attribute which the bearer expects the validator to share in return. The validator is only granted access to those bearer attribute(s) as defined the bearer policy pB if he grants the bearer access to his own attributes as defined by the validator policy pV. For example, by setting the bearer and validator policies pB, PV accordingly, the bearer may denote a willingness to grant the validator access to his selfie, name and date of birth provided the validator grants the bearer access to his own selfie.”; Examiner notes both policies pB and pV describe (maximum) limits of what the bearer is willing to share and (minimum) limits of what the bearer expects the validator to share in return).
With respect to claim 4, Zagarese et al. teach all the subject matter of the method as described above with respect to claims 1/3 and 1/2/3. Furthermore, Zagarese et al. disclose a method further comprising:
receiving an electronic transaction request comprising information indicative of a transaction requesting party, an electronic token and a requested transaction between the transaction requesting party and the second party (see paragraph [0224]: “...Assuming the purchaser's identity is successfully verified at the merchant device 12M, the merchant can proceed with accepting the payment. This is done by the merchant device 12M submitting the payment token 510 back to the token provider 508, for example via a payment API provided by the token provider 508. In this example, the token provider 508 also acts as a payment processor. However, the payment could also be processed by a separate payment processing entity.”);
authorizing the requested transaction when it is determined that the transaction requesting party and the received electronic token match, respectively, the first party and the second electronic token associated with the second party and that the requested transaction conforms to the one or more limits associated with the first party, second party and second electronic token (see Fig. A12, paragraph [0780]: “A uPass transaction can be conducted between three entities (such as bearer 20, validator 52, and validation service (authenticator) 14b), as shown in figure A12. In figure A12F represents a function to be executed. This may be a simple validation. It may also be an operation specific to the secure store 24 as expressed by a public API. A represents an authentication wrapper for F. The bearer 20 (e.g. customer) sends their credential Cc to the validator 52 (e.g. merchant) in a first electronic message. The validator sends its own credential Cm with the bearer credential Cc with an indicator of the function F to be executed to the authenticator 14b in a second electronic message (“CmF(Cc)”). The authenticator sends CmF(Cc) with an indicator of the authentication wrapper A and its own credential Ca to the secure store 24. A set of four receipts R1, R2, R3, R4 ({Ri}) is generated. A master receipt for the transaction is stored in the master receipt book 31, and bearer/validator receipts 32v/32b (R2/R3) are issued to the bearer and validator 20, 52. R1 is issued to the authenticator 14b, and R4 is logged in a secure access log 1202. All of the receipts R1, R2, R3,R4 and the master receipt share a transaction identifier which links them all together,”).
Regarding the BRI of the claim, Examiner notes that claim 4 recites “authorizing the requested transaction when it is determined that the transaction requesting party and the received electronic token match, respectively, the first party and the second electronic token associated with the second party and that the requested transaction conforms to the one or more limits associated with the first party, second party and second electronic token” , language directed to contingent limitations. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) (precedential) for an analysis of contingent claim limitations in the context of both method claims and system claims. See also MPEP 2111.04.
With respect to claim 6, Zagarese et al. teach all the subject matter of the method as described above with respect to claims 1/2/3 and 1/3. Furthermore, Zagarese et al. disclose a method further comprising:
receiving a modification request from the second party (see paragraph [0488]: “Device Revocation”; paragraph [0489]: “An uPass user may revoke authorization for any device currently enrolled for their account. This will invalidate any credential they currently have associated with the revoked device.”); and
modifying the association between the information indicative of the first party, the second party, the second electronic token and the one or more limits in accordance with the modification request (see paragraph [0637]: “A credential may be revoked at any time. When revocation occurs the credential's record is flagged as revoked in the secure store but the record is not processed at that time. This allows the uPass system to monitor the use of revoked credentials and use the resulting metadata to assist in fraud analysis and prevention.”; paragraph [0638]: “Once a credential is revoked or invalidated it cannot be reinstated as valid.”).
With respect to claim 7, Zagarese et al. teach all the subject matter of the method as described above with respect to claim 6. Furthermore, Zagarese et al. disclose a method wherein the modification request comprises: at least one of a request to modify the information indicative of the one or more limits and a request to delete the association between the first party, the second party, the second electronic token and the information indicative of the one or more limits (see paragraph [0637]: “A credential may be revoked at any time. When revocation occurs the credential's record is flagged as revoked in the secure store but the record is not processed at that time. This allows the uPass system to monitor the use of revoked credentials and use the resulting metadata to assist in fraud analysis and prevention.”; paragraph [0638]: “Once a credential is revoked or invalidated it cannot be reinstated as valid.”; [1456] Yuti will allow a profile of attributes to be not only share with multiple people but also be revoked as and when you wish it to be. [1457] As such users will not ultimately need to keep their own contact directories, rather a global address book will exist with dynamic up to date attributes with a nexus of permissions that exist between users. [1458] Sharing a user's contact information with others which gets updated when the user updates [1459] Being able to restrict access to your contact information).
Regarding the BRI of the claim, Examiner notes that claim 7 recites “wherein the modification request comprises: at least one of a request to modify the information indicative of the one or more limits and a request to delete the association between the first party, the second party, the second electronic token and the information indicative of the one or more limits”, language directed to non-functional descriptive material. Specifically, while the modification request is “used” in the modifying step of claim 6, the transitional term “comprising” is synonymous with “including,” “containing,” or “characterized by,” and is inclusive or open-ended and does not exclude additional, unrecited elements or method steps. Emphasis added. See, e.g., Mars Inc. v. H.J. Heinz Co., 377 F.3d 1369, 1376, 71 USPQ2d 1837, 1843 (Fed. Cir. 2004) and MPEP 2111.03. Since the modifying step is based upon the data as a whole, and the resulting data can be also based upon elements or method steps extraneous to “at least one of a request to modify the information indicative of the one or more limits and a request to delete the association between the first party, the second party, the second electronic token and the information indicative of the one or more limits”, the modifying step can be made using other unrecited matter than the modification request data contents recited in conjunction with claim 7. Therefore, the limitation “the modification request comprises… [data]” is directed to stored data. However, as the stored data is not functionally related to the memory in which it is stored it does not distinguish the claimed method from the prior art (In re Gulack, 217 USPQ 401 (Fed. Cir. 1983), In re Ngai, 70 USPQ2d (Fed. Cir. 2004), In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994); MPEP 2106.01). See MPEP 2111.05.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Zagarese et al. (US 2018/0181964 A1), in view of Belyi (US 2005/0080717 A1)
With respect to claim 9, Zagarese et al. teach all the subject matter of the method as described above with respect to claim 4. While Zagarese et al. recites calculating a confidence value, and that “The entity may be required to present a new data item when subsequently logging on to the system, and the confidence value may be changed based on the new data item” and receiving a message from one of the entities (see paragraphs [0966]-[0976]), Zagarese et al. do not explicitly teach a method further comprising: sending a fourth electronic message to the second party, the fourth electronic message comprising information requesting authorization of the requested transaction, when the transaction requesting party and the received electronic token match, respectively, the first party and the second electronic token associated with the second party and when the requested transaction does not conform to the one or more limits; receiving a fifth electronic message indicative of authorization information from the second party; and authorizing the requested transaction when the authorization information indicates that authorization has been granted by the second party.
However, Belyi discloses a method (Data validation systems and methods for financial transactions) further comprising:
sending a fourth electronic message to the second party, the fourth electronic message comprising information requesting authorization of the requested transaction, when the transaction requesting party and the received electronic token match, respectively, the first party and the second electronic token associated with the second party and when the requested transaction does not conform to the one or more limits (see Fig. 3, 214, paragraph [0060]: “In the state 214, the non-cash payment acceptance service 110 provides the merchant 106 with a notification for additional transaction information in a manner as previously described. Additionally, in the state 214, the risk system 150 performs the interactive authorization process in a manner that will be described in greater detail herein below in reference to FIG. 4..."; paragraph [0063]: “FIG. 4 illustrates one embodiment of an interactive authorization process flow that utilizes the risk system 150, as referenced by FIG. 2, to selectively re-assess moderate risk financial transactions by obtaining additional point of sale transaction information from the customer 100 and the merchant 106. The interactive authorization process, as described herein below, is one embodiment of a functional process flow description of the state 214 in FIG. 3. In one aspect, financial transactions that involve non-cash proffered payments and moderate risk assessments may require additional transaction information from the customer 100 and/or the merchant 106 for further risk evaluation including the verification of funds prior to the release of the goods, merchandise, and/or services 104...”; Fig. 4, decision state 238, paragraph [0064]: "...Following, in a state 238, the non-cash payment acceptance service 110 requests for additional transaction information from the customer 100 and/or the merchant 106 via the interactive POS device 136 in a manner as previously described...");
receiving a fifth electronic message indicative of authorization information from the second party (see Fig. 3, 216, paragraph [0060]: "If, based on the interactive authorization process, approval is authorized in still another decision state 216, then the non-cash payment verification and approval process advances to the state 208, where the non-cash payment acceptance service 110 authorizes the financial transaction between the merchant 106 and the customer 100. "; paragraph [0046]: “The interactive authorization module 168 may be utilized to prompt the merchant 106 with a notification of a requirement for additional transaction information, including personal identification information. In some cases, if the risk engine 152 determines that the financial transaction produces a borderline or moderate risk exception condition, then the interactive authorization module 168 may issue the notification for additional transaction information to be inputted by the merchant 106 via the interactive POS device 136. In one aspect, the notification for additional transaction information inform the merchant 106 that additional risk assessment and evaluation is necessary prior to transaction authorization. At this point, the merchant 106 inputs the additional transaction information into the interactive POS device 136 and then waits for the non-cash payment acceptance service 110 to issue authorization or declination for the financial transaction.”); and
authorizing the requested transaction when the authorization information indicates that authorization has been granted by the second party (see Fig. 3, 208-210, paragraph [0060]: "Then, in the state 210, the non-cash payment acceptance service 110 authorizes the financial transaction and notifies the merchant 106 with an applicable result via the interactive POS device 136."; Fig. 4, decision state 242, paragraph [0065]: “Subsequently, in a decision state 242, if the risk system 150 approves the financial transaction, which may be based at least in part on the additional transaction information, then the interactive authorization process advances to a state 244, where the financial transaction is authorized. Moreover, if the financial transaction is approved in the state 244, then the approved results are electronically transferred to the merchant 106 via the interface 146 and display the applicable results on the interactive POS device 136 in a manner as previously described with reference to FIGS. 1, 2. Following the transfer of the applicable results to the merchant 106, the interactive authorization process terminates in an end state 252. It should be appreciated that the merchant 106 may be notified of the applicable results of the financial transaction via the telephone, satellite relay, standard mail, or the internet without departing from the scope of the present invention”).
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 interactive authorization process as disclosed by Belyi in the method of Zagarese et al., the motivation being to increase the merchant's profitability by accepting some moderately risky financial transactions (see Belyi, paragraph [0063]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Non-Patent Literature
De et al. (NPL 2013, listed in PTO-892 as page 1, reference "U") disclose Towards an interoperable mobile wallet service, including the lifecycle of a token for an instant payment scenario. .
Patent Literature
Kallugudde (US 2021/0306312 A1) discloses merchant identification and secure data transfer, including generating a token to initiate the data transfer based at least on a first identifier and a second identifier..
Jones-McFadden (US 2017/0195879 A1) discloses system for authorizing access based on authentication via separate channel, including generating a merchant specific token coded for merchant input.
Venugopalan et al. (US 2016/0239833 A1) disclose methods and systems for processing an electronic payment, including (a) receiving, by a server, a first electronic request for a first token from a cardholder's device, the server being in communication with a database storing payment credentials for one or more payment cards associated with the cardholder; (b) generating the first token using an identity of the cardholder's device and transmitting the first token to the device; (c) receiving a second electronic request for processing the transaction from a merchant terminal, said second request comprising the first token and a merchant terminal identifier; (d) generating a second token using the first token and the merchant terminal identifier and transmitting the second token to the merchant terminal; (e) receiving a third token and a transaction authorization request from a merchant acquiring bank; (f) validating the third token using the second token; and (g) upon the validation operation (f) being successful, submitting the transaction authorization request to a card issuing bank.
Phalnikar (US 2020/0372509 A1) discloses detecting malicious transactions using multi-level risk analysis, including an online payment system taking one or more corrective actions, such as requiring the requesting user to perform an additional layer of authentication, flagging the transaction request for manual review, etc.
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
1 Examiner notes that, for compact prosecution purposes, claim 13 was incorporated into the analysis as if it was directed to statutory subject matter.
Prosecution Insights