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 .
Acknowledgements
This Office Action addresses the response filed on 11/03/2025.
Claims 1, 3, 11 and 20 were amended.
Claim 13 was canceled.
Claims 1-12 and 14-20 are pending.
Claims 1-12 and 14-20 were examined.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-12 and 14-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
According to MPEP 2106 II, It is essential that the broadest reasonable interpretation (BRI) of the claim be established prior to examining a claim for eligibility. Further, MPEP 2103 I C establishes that the subject matter of a properly construed claim is defined by the terms that limit the scope of the claim when given their broadest reasonable interpretation. It is this subject matter that must be examined. Regarding the independent claims, claims 1, 11 and 20 recite “allow the commercial profile to be selected by a second party to initiate the transaction” , a statement of intended use or field use. See MPEP 2114 II. In the instant case, claims 1-10 are directed to a system, claims 11-19 are directed to a method, and claim 20 are directed to a system. 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. “creating a commercial profile for a first party to a transaction, wherein the commercial profile is configured according to a schema”;
b. “defining, according to the schema, multiple payment types configured to process transactions through distinct account methods and routing protocols”;c. “defining, according to the schema, different business action types configured to specify party roles for transaction processing”;d. “cryptographically securing the commercial profile”;
e. “allowing the commercial profile to be selected by a second party to initiate the transaction”;
f. “automatically selecting, by a computer system, payment processing parameters based on the multiple payment types and the different business action types”;
g. “facilitating, according to the payment processing parameters, the transaction between the first party and the second party using information in the commercial profile of the first party.”
Therefore, the portions highlighted in bold above recite profile management, 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 fundamental economic practice of defining rules and facilitating a rule-based transaction, and the commercial or legal interaction of creating and publishing profiles. In situations like this where a series of steps recite judicial exceptions, examiners should combine all recited judicial exceptions and treat the claim as containing a single judicial exception for purposes of further eligibility analysis. See MPEP 2106.04 and 2106.05(II). Thus, the language identified in the certain methods of organizing human activity groupings were considered as a single abstract idea. Accordingly, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the additional element(s) of the claims include: one or more processors; and non-transitory computer-readable storage media, cryptographically securing; and automatically selecting. Specifically, with respect to using one or more processors; and non-transitory computer-readable storage media to perform the recited steps/functions, these additional elements performs the steps or functions such as: “create… profile…”, “define… payment types…”, “define… business action types…”, “secure… profile…”, “allow… profile… to be selected…”, “selecting… parameters...”, “facilitate… transaction…”. 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. 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. The claims further recite the additional elements: cryptographically securing; automatically selecting. However, these elements merely serve to generally link the use of a 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 additional computer elements, such as one or more processors; and non-transitory computer-readable storage media, cryptographically securing, and automatically selecting. The one or more processors; and non-transitory computer-readable storage media perform the steps/functions of “create… profile…”, “define… payment types…”, “define… business action types…”, “secure… profile…”, “allow… profile… to be selected…”, “selecting… parameters...”, “facilitate… transaction…”, , 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 profile management. With respect to the remaining additional elements of cryptographically securing, and automatically selecting, these additional elements amount to more than generally linking the use of a 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 profile management. Therefore, the claims are not eligible.
Dependent claims 2-10, 12 and 14-19 further recite the following additional language, in which elements which merely further define the identified abstract idea are marked in bold below:
h) wherein the commercial profile includes a name and a payment type for the first party.
i) wherein the schema is centralized, normalized, and interoperable across the method.
j) further comprising receiving selection of the commercial profile by the second party through an application programming interface.
k) further comprising assigning a cryptographic identity token to the commercial profile;
l) further comprising automatically reconciling the transaction between the first party and the second party.
m) further comprising using identity keys associated with the commercial profile to commit a record to a repository.
n) further comprising generating a trend based upon a metric associated with the commercial profile.
o) wherein the metric is one of an industry type and a payment type.
p) further comprising: generating a user interface including a plurality of commercial profiles including the commercial profile of the first party; and allowing the second party to select the commercial profile of the first party from the plurality of commercial profiles on the user interface.
Examiner notes that, for elements recited in the dependent claims which were previously analyzed as additional elements of the independent claims above (i.e. one or more processors; and non-transitory computer-readable storage media, cryptographically securing; automatically selecting), 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.
With respect to the eligibility analysis of claims 2, 12 and 20, the claims recite item h) above, which do not introduce additional elements/functions. The additional language merely represents statements directed to non-functional descriptive material by describing what the profile includes (i.e. data description (name/payment type). Those statements are insufficient to significantly alter the eligibility analysis. Therefore, the additional language h) of dependent claims 2, 12, 20 do not alter the analysis provided with respect to independent claims 1, 11 and 20. In other words, the claims do not introduce additional elements that would alter the analysis with respect to Steps 2A or 2B above in any meaningful way. Therefore, these dependent claims are also ineligible.
With respect to claims 3 and 20, the claims include 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 is the manner the profile is configured (i.e. according to schema), followed by the description of the schema. Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of profile management identified in the analysis of independent claims 1, 11 and 20. 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 claims 4 and 14, the claims recite item j) above, which represents the additional elements/functions of receiving selection through an API. This language further elaborates the abstract idea of profile management identified in the analysis of independent claims 1, 11 and 20 The claims recite the additional element of an API. However, this element merely serve to generally link the use of a 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 claim does 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 element of an API, this additional element amounts to more than generally linking the use of a judicial exception to a particular technological environment or field of use. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of profile management. 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, the claims are not eligible.
With respect to the eligibility analysis of claims 5, 15 and 20, the claims recite item k) above, which represents the additional elements/functions of assigning token to profile. This language further elaborates the abstract idea of profile management identified in the analysis of independent claims 1, 11 and 20. 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 claims 6, 16 and 20, the claims recite item l) above, which represents the additional elements/functions of reconciling transaction. This language further elaborates the abstract idea of profile management identified in the analysis of independent claims 1, 11 and 20. 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 claims 7, 17 and 20, the claims recite item m) above, which represents the additional elements/functions of using keys. This language further elaborates the abstract idea of profile management identified in the analysis of independent claims 1, 11 and 20. 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 claims 8, 18 and 20, the claims recite item n) above, which represents the additional elements/functions of generating a trend based on a metric. This language further elaborates the abstract idea of profile management identified in the analysis of independent claims 1, 11 and 20. 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. Examiner notes generating a trend using metrics is encompassed by the mental process of collecting information, analyzing it, and displaying certain results of the collection and analysis.
With respect to claim 9, 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 metric is (i.e. description of the data as types). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of profile management identified in the analysis of independent claims 1, 11 and 20. 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 claims 10 and 19, the claims recite item p) above, which represents the additional elements/functions of generating interface and allowing a party to select profile. This language further elaborates the abstract idea of profile management identified in the analysis of independent claims 1, 11 and 20. 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 i)- p) of dependent claims 3-10, 12-19 and independent claim 20 slightly modify the analysis provided with respect to independent claims 1 and 11, these additional elements/functions are insufficient to render the dependent claims eligible, as detailed above. Therefore, these dependent claims are also ineligible.
Examiner notes independent claim 20 incorporates the same analysis with respect to additional languages h) - i) and k) - p). It is important to note these elements are disclosed in the dependent claims separately, in distinct embodiments. Therefore, while claim 20 presents language similar to the language of dependent claims 2-10 and 12-19, none of these embodiments is sufficiently narrow to mirror the scope of claim 20. Therefore, an analysis of claim 20 as a whole is still necessary. For instance, all these individual elements should be analyzed in combination. In claim 20, 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. Further, 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, claim 20 is also not eligible.
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 1-7, 10-12, 14-17 and 19 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Dolezal et al. (US 2024/0005318 A1) (hereinafter Dolezal) in view of Lynch et al. (US 2025/0190969 A1) (hereinafter Lynch).
With respect to claims 1 and 11, Dolezal teaches a computer system for facilitating transactions using commercial profiles, comprising: one or more processors; and non-transitory computer-readable storage media (see paragraph [0024]: “Cloud/server 110 includes at least one processor 111 and a non-transitory computer-readable storage medium 112. Medium 112 includes a resource modeler 113, resource manager 115, portal manager 116, and application programming interfaces (APIs) 117, each of which includes executable instructions, that when executed by processor 111, cause processor 111 to perform respective corresponding operations discussed herein and below with respect to 113 and 115-117. Medium 112 also includes data structures for resources 114.”;); and a method for facilitating transactions using commercial profiles (Resource modeling, access, and security) comprising:
creating a commercial profile for a first party to a transaction, wherein the commercial profile is configured according to a schema (see paragraph [0027], in which Resource Modeler 112 (via interface 123) lets users create/modify financial accounts 114 and aliases, which are enforced as independent rule-based accounts; see paragraphs [0028] and [0033] for example of transaction types; See paragraph [0022] for transaction examples.);
cryptographically securing the commercial profile (see paragraph [0029]: “It is noted that in the example introduced above, the owner never has to share anything other than the portal identifier for purposes of receiving funds into their financial account 114. Thus, the owner can be assured that sharing the portal identifier does not pose any security risks to the owner's financial account 114 because portal manager 116 enforces access rules that permit only deposit of funds by any given service 133. The portal identifier, without more information, does not provide a hacker any means to link the portal identifier back to the attribute value associated with the master account identifier for the financial account 114. Security of the financial account 114 is controlled by the owner since the owner need only provide the public-facing portal identifier attribute value to individuals or services 130 when the owner is expecting a payment to be made to the owner.”; paragraph [0057]: “In an embodiment, the parties exchange information between themselves with selective encryption to hide private account details of the parties. For example, a payer may provide a decrypted version of their financial institutions identifier and an encrypted version of the payer's private disbursement alias account identifier. The payee then sends the payer's encrypted private disbursement alias account identifier and the payee's public receipts-only alias account identifier to the bank using the non-encrypted plain text bank identifier provided by the payer. The bank is capable of decrypting the private disbursement alias account identifier to complete the transaction by moving funds from the payer's account to the receipts-only account of the payee. The encryption method used can be institution specific such as public-private key encryption; the payer encrypts the private account identifier with a public key of the bank and a private key of the payer, the bank decrypts using the private key of the bank and a public key of the payer.”;);
allowing the commercial profile to be selected by a second party to initiate the transaction (see Examiner notes claims 1 and 11 recite “allow the commercial profile to be selected by a second party to initiate the transaction”, a statement of intended use or field use. Statements of intended use or field of use do not serve to differentiate the claims from the prior art. See MPEP 2114 II. However, for compact prosecution purposes, see portal-based access, flexible data model for a resource, paragraph [0016]; paragraph [0029]: “...the owner never has to share anything other than the portal identifier for purposes of receiving funds into their financial account 114. Thus, the owner can be assured that sharing the portal identifier does not pose any security risks to the owner's financial account 114 because portal manager 116 enforces access rules that permit only deposit of funds by any given service 133...”; paragraph [0060]: “…Payee provides its public-facing account identifier (alias identifier) to the payer…”; Fig. 3, 310-330, paragraph [0095]: “At 310, resource portal manager provides an interface 123 to an owner of a resource for defining multiple portal access to the resource. Interface 123 is interactive, and each selection of attributes determine what options are next available for the owner to select.”; paragraph [0096]: “At 320, the resource portal manager associates a particular set of access rules to each portal. An attribute associated with an alias having a defined purpose, capability, or function will be assigned a set of specific access rules for its corresponding portal.”; paragraph [0097]: “At 330, the resource portal manager enforces a corresponding set of access rules on each portal during transactions associated with accessing the resource. The access rules are enforced for the corresponding portal during any attempt to access the resource.); and
facilitating... the transaction between the first party and the second party using information in the commercial profile of the first party. (see novel service 133, paragraphs [0058]-[0060]).
Although Dolezal discloses each portal defined in the data model via the corresponding set of portal attributes for the resource 114 represents its own set of unique access rules differentiated by purpose, function, currency denomination, and accessibility (see paragraph [0033]), Dolezal does not explicitly disclose a system and method comprising: defining, according to the schema, multiple payment types configured to process transactions through distinct account methods and routing protocols; defining, according to the schema, different business action types configured to specify party roles for transaction processing; automatically selecting, by a computer system, payment processing parameters based on the multiple payment types and the different business action types; [facilitating the transaction is performed] according to the payment processing parameters.
However, Lynch discloses a system and method (System, method, and computer program product for flexible transaction message routing) comprising:
defining, according to the schema, multiple payment types configured to process transactions through distinct account methods and routing protocols (see plurality of account identifiers associated with a user, paragraph [0089]: “As shown in FIG. 2, at step 204, process 200 may include determining a second account identifier. For example, system 100 (e.g., authorization system 102 and/or authorization rule database 104 thereof) may determine a second account identifier from a plurality of account identifiers based on at least one rule associated with the first account identifier. In some non-limiting embodiments or aspects, authorization system 102 and/or authorization rule database 104 may determine the second account identifier from the plurality of account identifiers based on at least one rule associated with the first account identifier. In some non-limiting embodiments or aspects, the at least one rule may be stored in authorization rule database 104. In some non-limiting embodiments or aspects, authorization rule database 104 may communicate the at least one rule (and/or rule data associated therewith) associated with the first account identifier to authorization system 102.”; paragraph [0143]: “In some non-limiting embodiments or aspects, transaction control database 624 may receive the rule data, as described herein. In some non-limiting embodiments or aspects, the rule data may include a first account identifier (e.g., Lead Account) and/or at least one second account identifier (e.g., a Consumer Funding Choice for each rule, such as a (virtual) credit account identifier, a (virtual) prepaid account identifier, a (virtual) debit account identifier, any combination thereof, and/or the like). Additionally or alternatively, the rule data may include data representing each rule in a specified format (e.g., Consumer Rules). Additionally or alternatively, the rule data may include a rule identification number for each rule (e.g., Rule No.), an account type associated with each rule (e.g., Prepaid, Credit, Debit, and/or the like), any combination thereof, and/or the like. In some non-limiting embodiments or aspects, the rule data may include at least one fallback rule (e.g., Default Payment), as described herein. In some non-limiting embodiments or aspects, transaction control database 624 may store the rule data and/or communicate the rule data to authorization system 622.”);
defining, according to the schema, different business action types configured to specify party roles for transaction processing (see paragraph [0090]: “In some non-limiting embodiments or aspects, authorization system 102 may receive rule data associated with the at least one rule. For example, authorization system 102 may receive the rule data associated with the at least one rule from authorization rule database 104. The rule data associated with the at least one rule may include a threshold value. For example, authorization system 102 and/or authorization rule database 104 may determine whether a transaction amount of the payment transaction (e.g., associated with the authorization request) satisfies the threshold value. Authorization system 102 and/or authorization rule database 104 may identify (e.g., select) a second account identifier (e.g., from a plurality of account identifiers associated with the first account identifier and/or the user) in response to determining that the payment transaction satisfies the threshold. Additionally or alternatively, authorization system 102 and/or authorization rule database 104 may identify (e.g., select) a third account identifier (e.g., from the plurality of account identifiers) in response to determining that the payment transaction does not satisfy the threshold.”; ; Fig. 6A, threshold value rules, issuer systems associated with account identifiers (e.g., one of the first issuer system 604a, the second issuer system 604b, and/or the third issuer system 604c based on which one of these issuer systems issued the account identifier), paragraphs [0146]-[0149]);
automatically selecting, by a computer system, payment processing parameters based on the multiple payment types and the different business action types (see Fig. 6A, paragraph [0146]: “In some non-limiting embodiments or aspects, authorization system 622 may receive the authorization request. Additionally or alternatively, authorization system 622 may determine a second account identifier (e.g., one of the Consumer Funding Choices) from a plurality of account identifiers based on at least one rule stored in transaction control database 624. For example, authorization system 622 may receive (e.g., retrieve, access, read, and/or the like) the rule data from transaction control database 624. Additionally or alternatively, authorization system 622 may determine a second account identifier based on the rule data.”);
[facilitating the transaction is performed] according to the payment processing parameters (see paragraph [0149]: “In some non-limiting embodiments or aspects, authorization system 622 may generate a modified authorization request message for the payment transaction. For example, the modified authorization request message may include the second account identifier (e.g., one of the Consumer Funding Choices). In some non-limiting embodiments or aspects, authorization system 622 may transmit the modified authorization request message to an issuer system associated with the second account identifier (e.g., one of the first issuer system 604a, the second issuer system 604b, and/or the third issuer system 604c based on which one of these issuer systems issued the second account identifier). In some non-limiting embodiments or aspects, authorization system 622 may store a transaction history record based on the payment transaction and/or the second account identifier in the transaction history database 626.”).
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 rules database and flexible transaction message routing as disclosed by Lynch in the system and method of Dolezal, the motivation being to allow a transaction to be settled with a different account and/or account type than the account associated with the payment device used to initiate a transaction (see Lynch, paragraph [0004]).
With respect to the BRI of the claims, Examiner notes that claims 1 and 11 recite “allow the commercial profile to be selected by a second party to initiate the transaction”, a statement of intended use or field use. See MPEP 2114 II.
With respect to claims 2 and 12, the combination of Dolezal and Lynch teaches all the subject matter of the system and method as described above with respect to claims 1 and 11. Furthermore, Dolezal disclose a system and method wherein the commercial profile includes a name and a payment type for the first party (see paragraph [0020]: “The operations of the system 100 are discussed within a context of a financial account (one type of resource) and a financial service, but it is to be understood that the type of resource and the type of service may include many different types, such as a social media account associated with a social media service, an entertainment account associated with an entertainment service, a retailer or travel-based account associated with a retailer or travel-based service, or any other service-based account and corresponding service-based account service that collects, retains, and/or performs transactions on information associated with a user of that service.”; Flexible data model, paragraph [0021]: “In an embodiment, the flexible data model represents a financial account (financial resource) data structure (as discussed above). The global attributes may include fields associated with a master account number or identifier, an owner name, an issuing entity, one or more current balances, an account history of transactions for both global and per-portal (per-alias) attributes, and capabilities (e.g., operation identifiers) for creating, editing, and deleting a portal (alias) of the financial account. Each portal or alias for access to the account is further defined within the data structure with per-portal attributes that include a portal identifier (account alias), text description of the portal, public/private characterization (owner-defined purpose—limits capabilities assigned to the portal), operational capabilities, enabled/disabled status, and a schedule of enablement (supports temporary aliases/portals and periodically enabled aliases/portals).”;). Regarding the BRI of the claims, Examiner notes that claims 2 and 12 recite “wherein the commercial profile includes a name and a payment type for the first party.”, 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 claim 3, the combination of Dolezal and Lynch teaches all the subject matter of the system as described above with respect to claim 2. Furthermore, Dolezal disclose a system wherein the schema is centralized, normalized, and interoperable across the method (see paragraph [0033]: “In an embodiment, each portal defined in the data model via the corresponding set of portal attributes for the resource 114 represents its own set of unique access rules differentiated by purpose, function, currency denomination, and accessibility. The unique access rules are assigned by resource manager 115 based on the corresponding portal-based attribute values set by the owner via interface 124. For example, one alias (portal identifier value) may be used for receiving payments only and freely provided with no concern of security to those individuals or entities that are paying the owner. Another alias may set specific limits on the amount of currency that can be disbursed per month or even the frequency of disbursements (e.g., to pay utility bills, etc.). Other aliases may have specialized purposes, such as authorizing credit checks of the owner (such that no deposits or withdrawals are permitted, and the alias may be configured to expire after a credit check is performed or after a specified amount of time elapses).”). Regarding the BRI of the claim, Examiner notes that claim 3 recites “wherein the schema is centralized, normalized, and interoperable across the method”, 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 4 and 14, the combination of Dolezal and Lynch teaches all the subject matter of the system and method as described above with respect to claims 1 and 11. Furthermore, Dolezal disclose a system and method further comprising receiving selection of the commercial profile by the second party through an application programming interface (see paragraph [0030]: “Portal manager 116 enforces rules set by resource manager 115 during access requests made by a service 133 through APIs 134 and 117. Portal manager 116 identifies the portal identifier (alias identifier) made in an access request by service 133 and obtains the corresponding access rules for the corresponding resource 114 through resource manager 115 using the portal identifier. Portal manager 116 ensures that any requested access operation made with the request by service 133 is constrained by the set of rules set on the portal-attribute values.”;). 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 5 and 15, the combination of Dolezal and Lynch teaches all the subject matter of the system and method as described above with respect to claims 1 and 11. Furthermore, Dolezal disclose a system and method further comprising assigning a cryptographic identity token to the commercial profile (see encrypted version of the payer's private disbursement alias account identifier, paragraph [0057]: “In an embodiment, the parties exchange information between themselves with selective encryption to hide private account details of the parties. For example, a payer may provide a decrypted version of their financial institutions identifier and an encrypted version of the payer's private disbursement alias account identifier. The payee then sends the payer's encrypted private disbursement alias account identifier and the payee's public receipts-only alias account identifier to the bank using the non-encrypted plain text bank identifier provided by the payer. The bank is capable of decrypting the private disbursement alias account identifier to complete the transaction by moving funds from the payer's account to the receipts-only account of the payee. The encryption method used can be institution specific such as public-private key encryption; the payer encrypts the private account identifier with a public key of the bank and a private key of the payer, the bank decrypts using the private key of the bank and a public key of the payer.”); 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 6 and 16, the combination of Dolezal and Lynch teaches all the subject matter of the system and method as described above with respect to claims 1 and 11. Furthermore, Dolezal disclose a system and method further comprising automatically reconciling the transaction between the first party and the second party (see paragraph [0037]: “In an embodiment, instead of requiring owners to perform cumbersome actions for inter-account operations, intra-institution operations, and inter-institution operations, attributes and attribute values can be assigned by the owner to automate these operations for typical, frequent, and recurring activities. For example, attributes may be set on a resource (account) that cause automatic operations to be performed for recurring bills, transfers between accounts, etc. As another example, a consumer (owner) may designate a direct deposit from an employer into a designated alias that has automated actions that cause one or more portions of each direct deposit to be further moved to a different alias account of the consumer and/or to an external account associated with a different financial institution.”; Examiner maps automatically reconciling the transaction as automating operations, such as recurring bills). 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 7 and 17, the combination of Dolezal and Lynch teaches all the subject matter of the system and method as described above with respect to claims 1 and 11. Furthermore, Dolezal disclose a system and method further comprising using identity keys associated with the commercial profile to commit a record to a repository (see paragraph [0057]: “In an embodiment, the parties exchange information between themselves with selective encryption to hide private account details of the parties. For example, a payer may provide a decrypted version of their financial institutions identifier and an encrypted version of the payer's private disbursement alias account identifier. The payee then sends the payer's encrypted private disbursement alias account identifier and the payee's public receipts-only alias account identifier to the bank using the non-encrypted plain text bank identifier provided by the payer. The bank is capable of decrypting the private disbursement alias account identifier to complete the transaction by moving funds from the payer's account to the receipts-only account of the payee. The encryption method used can be institution specific such as public-private key encryption; the payer encrypts the private account identifier with a public key of the bank and a private key of the payer, the bank decrypts using the private key of the bank and a public key of the payer.”; Examiner notes the identity keys are the public-private key pairs of each entity). Regarding the BRI of the claims, Examiner notes that claims 7 and 17 recite “using… keys… to commit…” , a statement of intended use or field use. See MPEP 2114 II. 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 10 and 19, the combination of Dolezal and Lynch teaches all the subject matter of the system and method as described above with respect to claims 1 and 11. Furthermore, Dolezal disclose a system and method further comprising:
generating a user interface including a plurality of commercial profiles including the commercial profile of the first party (see paragraph [0069]: “In an embodiment, cloud/server 110 is subsumed within a financial institution's server and provided as account service manager to customers of the financial institution. Here, 113-117 can be hosted by any given resource service server 130 associated with a corresponding resource service interface 124.”; paragraph [0070]: “In an embodiment, a financial institution utilizes cloud/server 110 for account service management of its accounts. In this embodiment, interface 123 may be provided as an enhancement or an embedded service to an existing financial application of the financial institution via customer-operated devices 120 of the financial institution. That is, the resources 114 managed by the financial institution are hosted and managed via cloud 110.”; paragraph [0071]: “In an embodiment, interface 123 is browser based such that interface 123 is delivered on device 120 through web pages hosted by cloud 110. Owner/user of resource 114 accesses resource 114 via any device 120 capable of processing a browser, such as a phone, a laptop, a desktop, etc.”; paragraph [0072]: “In an embodiment, interface 123 is a mobile application download and processed on device 120. Here, device 120 is any device 120 capable of processing a mobile application, such as a phone, a laptop, a desktop, a wearable processing device, etc.”); and Regarding the BRI of the claims, Examiner notes that claims 10 and 19 recite “allowing the second party to select the commercial profile of the first party from the plurality of commercial profiles on the user interface” , a statement of intended use or field use. See MPEP 2114 II. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
allowing the second party to select the commercial profile of the first party from the plurality of commercial profiles on the user interface (see paragraph [0085]: “In an embodiment, at 223 (shown in FIG. 2C), the resource manager presents a list of available attributes to the owner through an interface 123 based on a stated purpose for the resource, a stated access capability for the resource, or a stated access function for the resource as identified by the owner. So, a selection by the owner of a receipts only alias account causes resource manager to present options (via the attributes) for receipts-only accounts.”). Regarding the BRI of the claims, Examiner notes that claims 10 and 19 recite “allowing the second party to select the commercial profile of the first party from the plurality of commercial profiles on the user interface” , a statement of intended use or field use. See MPEP 2114 II. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
Claims 8, 9, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Dolezal (US 2024/0005318 A1), in view of Lynch (US 2025/0190969 A1), in view of Moreau, Jr. (US 2017/0004518 A1), hereinafter Moreau, Jr.
With respect to claims 8 and 18, the combination of Dolezal and Lynch teaches all the subject matter of the system and method as described above with respect to claims 1 and 11. The combination of Dolezal and Lynch does not explicitly teach a system and method further comprising generating a trend based upon a metric associated with the commercial profile.
However, Moreau, Jr. discloses a system and method (Method and system for providing integrated solutions) further comprising generating a trend based upon a metric associated with the commercial profile (see paragraph [0044]: “In yet another embodiment, data warehouse 200 stores, reviews, and/or analyzes information used in generating one or more insights into the business of the one or more merchants based on the microeconomic information and macroeconomic information, including the payment card holder transaction information at the one or more merchants. The one or more insights into the business of the one or more merchants can include, for example, one or more of spending patterns, customer profiles, competitor performance, market trends, and the like.”; paragraph [0045]: “In yet another embodiment, data warehouse 200 stores, reviews, and/or analyzes information used in identifying opportunities and/or recommendations for the business of the one or more merchants, based on the one or more insights. The opportunities and/or recommendations for the business of the one or more merchants can include, for example, implementing a marketing campaign to take advantage of a market trend, making targeted promotional offers to a plurality of payment card holders, and the like.”; paragraph [0046]: “In yet another embodiment, data warehouse 200 stores, reviews, and/or analyzes information used in performing operational aspects for implementing the opportunities and/or recommendations into the business of the one or more merchants. The operational aspects can include, for example, providing metrics to the one or more merchants for one or more of spending patterns, customer profiles, competitor performance, and market trends, including payment card usage trends, alerting the one or more merchants of changes in one or more of spending patterns, customer profiles, competitor performance, and market trends, including payment card usage trends, and the like”).
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 information analysis and performance metrics as disclosed by Moreau, Jr. in the system of Dolezal and Lynch, the motivation being to implement opportunities and/or recommendations into the business of the one or more merchants (see Moreau, Jr., paragraph [0046]).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 claim 9, the combination of Dolezal, Lynch and Moreau, Jr. teaches all the subject matter of the system as described above with respect to claim 8. Further, Moreau, Jr. discloses a system wherein the metric is one of an industry type and a payment type (see paragraph [0038]: “Among many potential uses, the systems and methods described herein can be used to: (1) identify for merchants where shopper volume is coming from; this identification can be geospatially from regions down to each individual store location; (2) compare and contrast payment card holder spend at a merchant relative to total payment card holder spend with competitors in the industry (or the competition); (3) determine how seasonality and special events impact purchasing behavior at the merchant; (4) develop insights and actions to enhance merchants in staffing/customer service, as well as inventory/stocking in their stores to reflect changing market trends; (5) advertise at the proper media and industry to promote their brand where opportunities exist; and (6) understand if the merchant is performing better or worse in their industry than the competition.”; paragraph [0082]: “The transaction payment card information 302 can include, for example, payment card transaction information, payment card holder information (e.g., payment card holder account identifier (likely anonymized), payment card holder geography (potentially modeled), payment card holder type (consumer/business), payment card holder demographics, and the like), and purchasing and payment activities attributable to payment card holders, that can be aggregated by payment card holder, merchant category and/or location, transaction date and time, and transaction amount. The transaction payment card information 302 can also include, for example, a transaction identifier, geolocation of payment card transaction, geolocation date on which payment card transaction occurred, geolocation time on which payment card transaction occurred, and the like. Information for inclusion in the information of 302 can be obtained, for example, from payment card companies known as MasterCard®, Visa®, American Express®, and the like (part of the payment card company network 150 in FIG. 1).”; paragraph [0083]: “The merchant information 302 can include, for example, categories of merchants, merchant name, merchant geography, merchant line of business, and the like. The merchant information 302 can also include, for example, a merchant identifier, geolocation of merchant, firmographics data, and the like.”; paragraphs [0084]-[0088] and [0102]: “A marketing campaign is an example of how the strategic framework of this disclosure can be implemented. Utilizing insights driven from payment card transaction data, metrics are delivered to a small business owner (SBO) on payment card usage trends and how competitors are performing relative to the business. From these insights, the SBO is alerted to changes in trends, which provides an opportunity to execute a marketing campaign, intended to take advantage of the trends. Rules, based on the insights, generate a selection of optimal campaign (channel, offer, audience, etc.). The SBO picks from the recommended selections or creates a campaign based on their own preferences, and determines campaign execution requirements from available options. Campaign requirements are executed and performance tracked, returning in-market and post campaign analytics. Rules, based on analytics, generate a new set of recommendations to take advantage of new opportunities created from new insights.”). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of independent claim 1 and dependent claim 8.
With respect to claim 20, Dolezal teaches a computer system for facilitating transactions using commercial profiles, comprising: one or more processors; andnon-transitory computer-readable storage media (Resource modeling, access, and security) comprising:
create a commercial profile for a first party to a transaction (see paragraph [0027], in which Resource Modeler 112 (via interface 123) lets users create/modify financial accounts 114 and aliases, which are enforced as independent rule-based accounts; see paragraphs [0028] and [0033] for example of transaction types; See paragraph [0022] for transaction examples.),
wherein the commercial profile includes a name and a payment type for the first party (see paragraph [0020]: “The operations of the system 100 are discussed within a context of a financial account (one type of resource) and a financial service, but it is to be understood that the type of resource and the type of service may include many different types, such as a social media account associated with a social media service, an entertainment account associated with an entertainment service, a retailer or travel-based account associated with a retailer or travel-based service, or any other service-based account and corresponding service-based account service that collects, retains, and/or performs transactions on information associated with a user of that service.”; Flexible data model, paragraph [0021]: “In an embodiment, the flexible data model represents a financial account (financial resource) data structure (as discussed above). The global attributes may include fields associated with a master account number or identifier, an owner name, an issuing entity, one or more current balances, an account history of transactions for both global and per-portal (per-alias) attributes, and capabilities (e.g., operation identifiers) for creating, editing, and deleting a portal (alias) of the financial account. Each portal or alias for access to the account is further defined within the data structure with per-portal attributes that include a portal identifier (account alias), text description of the portal, public/private characterization (owner-defined purpose—limits capabilities assigned to the portal), operational capabilities, enabled/disabled status, and a schedule of enablement (supports temporary aliases/portals and periodically enabled aliases/portals)”); and
wherein the commercial profile is configured according to a schema that is centralized, normalized, and interoperable across the computer system (see paragraph [0033]: “In an embodiment, each portal defined in the data model via the corresponding set of portal attributes for the resource 114 represents its own set of unique access rules differentiated by purpose, function, currency denomination, and accessibility. The unique access rules are assigned by resource manager 115 based on the corresponding portal-based attribute values set by the owner via interface 124. For example, one alias (portal identifier value) may be used for receiving payments only and freely provided with no concern of security to those individuals or entities that are paying the owner. Another alias may set specific limits on the amount of currency that can be disbursed per month or even the frequency of disbursements (e.g., to pay utility bills, etc.). Other aliases may have specialized purposes, such as authorizing credit checks of the owner (such that no deposits or withdrawals are permitted, and the alias may be configured to expire after a credit check is performed or after a specified amount of time elapses)”);
cryptographically securing the commercial profile (see paragraph [0029]: “It is noted that in the example introduced above, the owner never has to share anything other than the portal identifier for purposes of receiving funds into their financial account 114. Thus, the owner can be assured that sharing the portal identifier does not pose any security risks to the owner's financial account 114 because portal manager 116 enforces access rules that permit only deposit of funds by any given service 133. The portal identifier, without more information, does not provide a hacker any means to link the portal identifier back to the attribute value associated with the master account identifier for the financial account 114. Security of the financial account 114 is controlled by the owner since the owner need only provide the public-facing portal identifier attribute value to individuals or services 130 when the owner is expecting a payment to be made to the owner.”; paragraph [0057]: “In an embodiment, the parties exchange information between themselves with selective encryption to hide private account details of the parties. For example, a payer may provide a decrypted version of their financial institutions identifier and an encrypted version of the payer's private disbursement alias account identifier. The payee then sends the payer's encrypted private disbursement alias account identifier and the payee's public receipts-only alias account identifier to the bank using the non-encrypted plain text bank identifier provided by the payer. The bank is capable of decrypting the private disbursement alias account identifier to complete the transaction by moving funds from the payer's account to the receipts-only account of the payee. The encryption method used can be institution specific such as public-private key encryption; the payer encrypts the private account identifier with a public key of the bank and a private key of the payer, the bank decrypts using the private key of the bank and a public key of the payer.”;);
assign a cryptographic identity token to the commercial profile (see paragraph [0037]: “In an embodiment, instead of requiring owners to perform cumbersome actions for inter-account operations, intra-institution operations, and inter-institution operations, attributes and attribute values can be assigned by the owner to automate these operations for typical, frequent, and recurring activities. For example, attributes may be set on a resource (account) that cause automatic operations to be performed for recurring bills, transfers between accounts, etc. As another example, a consumer (owner) may designate a direct deposit from an employer into a designated alias that has automated actions that cause one or more portions of each direct deposit to be further moved to a different alias account of the consumer and/or to an external account associated with a different financial institution.”; Examiner maps automatically reconciling the transaction as automating operations, such as recurring bills);
use identity keys associated with the commercial profile to commit a record to a repository (see paragraph [0057]: “In an embodiment, the parties exchange information between themselves with selective encryption to hide private account details of the parties. For example, a payer may provide a decrypted version of their financial institutions identifier and an encrypted version of the payer's private disbursement alias account identifier. The payee then sends the payer's encrypted private disbursement alias account identifier and the payee's public receipts-only alias account identifier to the bank using the non-encrypted plain text bank identifier provided by the payer. The bank is capable of decrypting the private disbursement alias account identifier to complete the transaction by moving funds from the payer's account to the receipts-only account of the payee. The encryption method used can be institution specific such as public-private key encryption; the payer encrypts the private account identifier with a public key of the bank and a private key of the payer, the bank decrypts using the private key of the bank and a public key of the payer.”; Examiner notes the identity keys are the public-private key pairs of each entity);
allow the commercial profile to be selected by a second party to initiate the transaction; (see Examiner notes claim 20 recites “allow the commercial profile to be selected by a second party to initiate the transaction”, a statement of intended use or field use. Statements of intended use or field of use do not serve to differentiate the claims from the prior art. See MPEP 2114 II. However, for compact prosecution purposes, see portal-based access, flexible data model for a resource, paragraph [0016]; paragraph [0029]: “...the owner never has to share anything other than the portal identifier for purposes of receiving funds into their financial account 114. Thus, the owner can be assured that sharing the portal identifier does not pose any security risks to the owner's financial account 114 because portal manager 116 enforces access rules that permit only deposit of funds by any given service 133...”; paragraph [0060]: “…Payee provides its public-facing account identifier (alias identifier) to the payer…”; Fig. 3, 310-330, paragraph [0095]: “At 310, resource portal manager provides an interface 123 to an owner of a resource for defining multiple portal access to the resource. Interface 123 is interactive, and each selection of attributes determine what options are next available for the owner to select.”; paragraph [0096]: “At 320, the resource portal manager associates a particular set of access rules to each portal. An attribute associated with an alias having a defined purpose, capability, or function will be assigned a set of specific access rules for its corresponding portal.”; paragraph [0097]: “At 330, the resource portal manager enforces a corresponding set of access rules on each portal during transactions associated with accessing the resource. The access rules are enforced for the corresponding portal during any attempt to access the resource.);
facilitate... the transaction between the first party and the second party using information in the commercial profile of the first party (see novel service 133, paragraphs [0058]-[0060]);
automatically reconcile the transaction between the first party and the second party (see paragraph [0037]: “In an embodiment, instead of requiring owners to perform cumbersome actions for inter-account operations, intra-institution operations, and inter-institution operations, attributes and attribute values can be assigned by the owner to automate these operations for typical, frequent, and recurring activities. For example, attributes may be set on a resource (account) that cause automatic operations to be performed for recurring bills, transfers between accounts, etc. As another example, a consumer (owner) may designate a direct deposit from an employer into a designated alias that has automated actions that cause one or more portions of each direct deposit to be further moved to a different alias account of the consumer and/or to an external account associated with a different financial institution.”; Examiner maps automatically reconciling the transaction as automating operations, such as recurring bills).
Dolezal does not explicitly disclose a system comprising: define, according to the schema, multiple payment types configured to process transactions through distinct account methods and routing protocols; define, according to the schema, different business action types configured to specify party roles for transaction processing; automatically select, by the computer system, payment processing parameters based on the multiple payment types and the different business action types;; [facilitate the transaction is performed] according to the payment processing parameters. generate a trend based upon a metric associated with the commercial profile, wherein the metric is one of an industry type and the payment type.
However, Lynch discloses a system (System, method, and computer program product for flexible transaction message routing) comprising:
define, according to the schema, multiple payment types configured to process transactions through distinct account methods and routing protocols (see plurality of account identifiers associated with a user, paragraph [0089]: “As shown in FIG. 2, at step 204, process 200 may include determining a second account identifier. For example, system 100 (e.g., authorization system 102 and/or authorization rule database 104 thereof) may determine a second account identifier from a plurality of account identifiers based on at least one rule associated with the first account identifier. In some non-limiting embodiments or aspects, authorization system 102 and/or authorization rule database 104 may determine the second account identifier from the plurality of account identifiers based on at least one rule associated with the first account identifier. In some non-limiting embodiments or aspects, the at least one rule may be stored in authorization rule database 104. In some non-limiting embodiments or aspects, authorization rule database 104 may communicate the at least one rule (and/or rule data associated therewith) associated with the first account identifier to authorization system 102.”; paragraph [0143]: “In some non-limiting embodiments or aspects, transaction control database 624 may receive the rule data, as described herein. In some non-limiting embodiments or aspects, the rule data may include a first account identifier (e.g., Lead Account) and/or at least one second account identifier (e.g., a Consumer Funding Choice for each rule, such as a (virtual) credit account identifier, a (virtual) prepaid account identifier, a (virtual) debit account identifier, any combination thereof, and/or the like). Additionally or alternatively, the rule data may include data representing each rule in a specified format (e.g., Consumer Rules). Additionally or alternatively, the rule data may include a rule identification number for each rule (e.g., Rule No.), an account type associated with each rule (e.g., Prepaid, Credit, Debit, and/or the like), any combination thereof, and/or the like. In some non-limiting embodiments or aspects, the rule data may include at least one fallback rule (e.g., Default Payment), as described herein. In some non-limiting embodiments or aspects, transaction control database 624 may store the rule data and/or communicate the rule data to authorization system 622”);
define, according to the schema, different business action types configured to specify party roles for transaction processing (see paragraph [0090]: “In some non-limiting embodiments or aspects, authorization system 102 may receive rule data associated with the at least one rule. For example, authorization system 102 may receive the rule data associated with the at least one rule from authorization rule database 104. The rule data associated with the at least one rule may include a threshold value. For example, authorization system 102 and/or authorization rule database 104 may determine whether a transaction amount of the payment transaction (e.g., associated with the authorization request) satisfies the threshold value. Authorization system 102 and/or authorization rule database 104 may identify (e.g., select) a second account identifier (e.g., from a plurality of account identifiers associated with the first account identifier and/or the user) in response to determining that the payment transaction satisfies the threshold. Additionally or alternatively, authorization system 102 and/or authorization rule database 104 may identify (e.g., select) a third account identifier (e.g., from the plurality of account identifiers) in response to determining that the payment transaction does not satisfy the threshold.”; ; Fig. 6A, threshold value rules, issuer systems associated with account identifiers (e.g., one of the first issuer system 604a, the second issuer system 604b, and/or the third issuer system 604c based on which one of these issuer systems issued the account identifier), paragraphs [0146]-[0149]);
automatically select, by the computer system, payment processing parameters based on the multiple payment types and the different business action types; (see Fig. 6A, paragraph [0146]: “In some non-limiting embodiments or aspects, authorization system 622 may receive the authorization request. Additionally or alternatively, authorization system 622 may determine a second account identifier (e.g., one of the Consumer Funding Choices) from a plurality of account identifiers based on at least one rule stored in transaction control database 624. For example, authorization system 622 may receive (e.g., retrieve, access, read, and/or the like) the rule data from transaction control database 624. Additionally or alternatively, authorization system 622 may determine a second account identifier based on the rule data”);
[facilitate the transaction is performed] according to the payment processing parameters (see paragraph [0149]: “In some non-limiting embodiments or aspects, authorization system 622 may generate a modified authorization request message for the payment transaction. For example, the modified authorization request message may include the second account identifier (e.g., one of the Consumer Funding Choices). In some non-limiting embodiments or aspects, authorization system 622 may transmit the modified authorization request message to an issuer system associated with the second account identifier (e.g., one of the first issuer system 604a, the second issuer system 604b, and/or the third issuer system 604c based on which one of these issuer systems issued the second account identifier). In some non-limiting embodiments or aspects, authorization system 622 may store a transaction history record based on the payment transaction and/or the second account identifier in the transaction history database 626.”;).
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 rules database and flexible transaction message routing as disclosed by Lynch in the system of Dolezal, the motivation being to allow a transaction to be settled with a different account and/or account type than the account associated with the payment device used to initiate a transaction (see Lynch, paragraph [0004]).
The combination of Dolezal and Lynch does not explicitly disclose a system comprising: generate a trend based upon a metric associated with the commercial profile, wherein the metric is one of an industry type and the payment type.
However, Moreau, Jr. discloses a system (Method and system for providing integrated solutions) comprising:
generate a trend based upon a metric associated with the commercial profile, wherein the metric is one of an industry type and the payment type. (see paragraph [0038]: “Among many potential uses, the systems and methods described herein can be used to: (1) identify for merchants where shopper volume is coming from; this identification can be geospatially from regions down to each individual store location; (2) compare and contrast payment card holder spend at a merchant relative to total payment card holder spend with competitors in the industry (or the competition); (3) determine how seasonality and special events impact purchasing behavior at the merchant; (4) develop insights and actions to enhance merchants in staffing/customer service, as well as inventory/stocking in their stores to reflect changing market trends; (5) advertise at the proper media and industry to promote their brand where opportunities exist; and (6) understand if the merchant is performing better or worse in their industry than the competition.”; paragraph [0082]-[0088] and [0102]: “A marketing campaign is an example of how the strategic framework of this disclosure can be implemented. Utilizing insights driven from payment card transaction data, metrics are delivered to a small business owner (SBO) on payment card usage trends and how competitors are performing relative to the business. From these insights, the SBO is alerted to changes in trends, which provides an opportunity to execute a marketing campaign, intended to take advantage of the trends. Rules, based on the insights, generate a selection of optimal campaign (channel, offer, audience, etc.). The SBO picks from the recommended selections or creates a campaign based on their own preferences, and determines campaign execution requirements from available options. Campaign requirements are executed and performance tracked, returning in-market and post campaign analytics. Rules, based on analytics, generate a new set of recommendations to take advantage of new opportunities created from new insights.”).
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 information analysis and performance metrics as disclosed by Moreau, Jr. in the system of Dolezal and Lynch, the motivation being to implement opportunities and/or recommendations into the business of the one or more merchants (see Moreau, Jr., paragraph [0046]).
Response to Arguments/Amendments
Claim Objections
Applicant’s amendments and arguments (see remarks, page 7, filed on 11/03/2025), with respect to the objection of claim 20 have been fully considered. Examiner finds Applicant's arguments persuasive in view of the submitted amendments, therefore the objection was withdrawn.
Claim rejections - 35 USC § 101
Applicant’s amendments and arguments (see remarks, pages 7-9, filed on 11/03/2025), with respect to the rejection of claims 1-12 and 14-20 under 35 USC § 101 as being directed to an abstract idea have been fully considered but are not persuasive. With respect to step 2A , Applicant asserts “Amended claim 1 integrates any abstract idea into a practical application by improving payment processing technology through specific technical limitations that enable automatic optimization of payment execution. Amended claim 1 recites defining multiple payment types configured to process transactions through distinct account methods and routing protocols, defining different business action types configured to specify party roles for transaction processing, and automatically selecting payment processing parameters based on the multiple payment types and the different business action types. These limitations provide a specific technological solution to the technical problem that transactions between commercial parties are insecure and inefficient when one party must share transactional details with the other to consummate the transaction. Specification at [0001]. Amended claim 1 is analogous to claim 3 in United States Patent and Trademark Office Example 47”. Examiner respectfully disagrees. Examiner is in the position that the newly introduced language is part of the abstract idea, as detailed above. Examiner disagrees with Applicant's assertion that the claim is "analogous to claim 3 in United States Patent and Trademark Office Example 47". Specifically, this Example illustrates the application of the eligibility analysis to claims that recite limitations specific to artificial intelligence, particularly the use of an artificial neural network to identify or detect anomalies. Examiner disagrees with Applicant's interpretation that defining and applying rules is equivalent to using an artificial neural network to identify or detect anomalies.. The new and amended claims do not offer significantly more than the abstract idea itself, therefore the claims are still rejected under 35 USC § 101 as further detailed above.
Claim rejections - 35 USC § 102
Applicant’s amendments and arguments (see remarks, pages 10 and 11, filed on 11/03/2025), with respect to the rejection of claims 1-7, 10-12, 14-17 and 19 under 35 USC § 102 have been fully considered and the rejection withdrawn. Examiner notes Applicant’s arguments are moot because the arguments directed to the newly introduced language do not apply to the combination of references being used in the current rejection of the amended claims under 35 U.S.C. § 103.
Claim rejections - 35 USC § 103
Applicant’s amendments and arguments (see remarks, page 11, filed on 11/03/2025), with respect to the rejection of claims 8, 9, 18 and 20 under 35 USC § 103 have been fully considered , but are moot because the arguments directed to the newly introduced language do not apply to the combination of references being used in the current rejection of the amended claims under 35 U.S.C. § 103.
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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