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 .
Acknowledgments
The submission (RCE and Amendment) filed on 04/02/26 is acknowledged. (The instant submission was filed following the Examiner's Answer, which was filed on 02/02/26 in response to Applicant's Appeal Brief, which was filed on 11/17/25 following a Notice of Appeal, which was filed on 09/16/25.)
Status of Claims
Claims 1, 2, 4-15 and 17-20 are pending.
In the Amendment filed on 04/02/26, claims 1, 2, 4-6, 11-15 and 17-20 were amended, claims 3 and 16 were cancelled, and no claims were added.
Claims 1, 2, 4-15 and 17-20 are rejected.
Response to Arguments
Regarding the rejection under 35 U.S.C. 101
Applicant's arguments have been fully considered but are not persuasive.
The Office responds to Applicant's arguments below.
Applicant’s instant Amendment was filed with an accompanying Declaration. Below the Examiner responds first to the Remarks/Arguments in the Amendment ("Remarks") and then to the Declaration. Inasmuch as the Remarks cite the Declaration, the Examiner's response to the Remarks also addresses the Declaration as warranted.
I. Examiner's response to Applicant’s Remarks
In the discussion below, page numbers refer to Applicant's Amendment, unless otherwise indicated, and paragraph numbers refer to Applicant's specification, unless otherwise indicated.
Applicant asserts that the Examiner's Answer "mischaracterized the claims" and "made several statements that suggest a fundamental misunderstanding of Applicant's intended invention" (p. 14). The Examiner rejects and refutes this assertion, as explained below.
Applicant's Remarks are structured as "walk[ing] through several statements made in the [Examiner's] Answer that do not reflect the claimed subject matter" (p. 14). Thus, Applicant presents respective arguments against each of five statements from the Examiner's Answer. The Examiner’s response below is set forth according to this structure of Applicant's Remarks.
In the discussion below, for the reader's reference, each of Applicant's five arguments is quoted, followed by the Examiner's response to it. In some instances, bracketed numerals are inserted in Applicant's quoted argument, for reference to specific parts of Applicant's argument in the Examiner's response that follows Applicant's argument.
Statement/Argument #1
Applicant argues:
First, on page 12, the Answer states that the "putative improvement is a new data structure (namely, the UUEK) replacing old elements, that is used to represent sensitive payment credentials, and that is passed among parties to a transaction to authorize and execute the transaction, while protecting the sensitive payment credential." Answer, p. 12. The Answer further states that "the mere invention of a new data structure, to replace an old data structure, by its very nature, cannot in itself affect the physical machine that processes/ manipulates the data, or the functioning of such machine." Id. [1] The UUEK does not replace an old data structure. It is a completely different type of data structure that is used within a credential-less messaging scheme to implement a credential-less message. See e.g., Declaration ¶¶ 19-22 and 29-32; see also Specification ¶¶ 3-5 and 7-8. [2] The UUEK is made up of several data elements that improve the security of the messages when provided within the network including a partition that points to a partitioned environment and enables the exchange platform to route messages with UUEKs to different, isolated services within the exchange platform. Declaration ¶ 29. [3] This is significantly different than traditional networks, which use the most significant digits of the PAN in order to route messages and network tokenization, which ultimately still uses the PAN for routing purposes. Id., at ¶¶ 30 - 31. [4] Unlike these traditional approaches, the UUEK, when used within the credential-less messaging scheme recited by the claims, eliminates the use of persistent credentials, such as the PAN, in every network message. Id., at ¶ 32; see also Specification ¶¶ 7-8, 229, and 234. [5] As explained throughout the Specification and the Declaration, by eliminating persistent credentials, such as the PAN, in every network message, the UUEK and the claimed credential-less messaging scheme changes how these messages are transmitted over a network. [6] Specifically, instead of relying on ISO messaging standards, the UUEK enables the use of flexible APIs, including the claimed gRPC APIs. Id., at ¶ 22; see also Specification ¶ 5. (pp. 14-15 emphasis changed from original)
The Office responds:
Regarding [1]:
Applicant's argument contradicts Applicant's own specification. Specifically, 0025 states:
Some embodiments of the present disclosure present network-based exchange processing techniques for facilitating credential-less exchanges. To do so, some of the techniques of the present disclosure leverage new data structures, UUEKs, that may replace persistent credentials traditionally used to authorize a value-based exchange.
In other words: Applicant argues "The UUEK does not replace an old data structure." However, Applicant's specification says "UUEKs … may replace persistent credentials traditionally used." Thus, Applicant's argument contradicts Applicant's specification. Accordingly, Applicant's argument is not persuasive.
In addition, Applicant's argument appears to contradict Applicant's own Declaration. Specifically, ¶¶ 19-20 and 29-32 of the Declaration appear to assert that the credential-less message replaces the persistent credential, such as a PAN.
Applicant's assertion that the UUEK is "a completely different type of data structure" does not provide evidence that "[t]he UUEK does not replace an old data structure." Rather, this assertion is consistent with the fact, and indeed suggests, that the UUEK indeed replaces an old data structure.
The "credential-less message' is likewise a new data structure that replaces an old data structure. The Examiner reiterates (as per the Examiner's Answer and as quoted by Applicant above) that a data structure does not affect a machine or its functioning. Likewise, a messaging scheme, i.e., a way of sending (and/or formatting) messages, or the like, does not affect a machine or its functioning.
Regarding [2]:
The UUEK may indeed improve the security of messages by eliminating use of persistent credentials and may contain information indicating where to route messages. Any improvement alleged in this regard would be an alleged improvement in the abstract idea.
Regarding [3]:
Applicant points out that the claimed invention differs from the prior art by using a UUEK instead of the last four digits of the PAN to route messages. (This again shows that the UUEK replaces an old data structure (namely, the PAN), thus reconfirming that Applicant's argument contradicts Applicant's specification.) Thus, both the claimed invention and the prior art use message contents to route messages. The difference here between the claimed invention and the prior art is a matter of (a difference in) the abstract idea.
Regarding [4]:
This has been addressed at [2] above.
Regarding [5]:
The Office strenuously rejects Applicant's assertions. The elimination of persistent credentials, specifically, their replacement by a UUEK, and the credential-less messaging scheme does not change how messages are transmitted over a network. The only possible changes in this regard are to the content/format of the message and to the destination of the message. These changes do not constitute a change in how messages are transmitted over a network.
Regarding [6]:
Applicant's statement purports to explain how the claimed UUEK and messaging scheme change how messages are transmitted over a network. However, as best understood, Applicant's statement is unclear, does not make sense, and is false or misleading.
Applicant's statement purports to compare/contrast the use of "ISO messaging standards" with the use of "flexible APIs." This is comparing apples to oranges. ISO messaging standards, e.g., ISO 8583, define a data format.1 In contrast, an API is a set of rules or software code that enables different software applications to communicate with each other.2
Furthermore, ISO messaging standards can be used with APIs, including gRPC APIs. Therefore, it is not clear what Applicant means by saying that "the UUEK enables use of flexible APIs, including the claimed gRPC APIs," and this statement of Applicant is misleading by implying that ISO messaging standards do not permit the use of such APIs.3
Likewise, since ISO messaging standards can be used with APIs, including gRPC APIs, the UUEK is not understood to enable the use of APIs, including gRPC APIs, as a difference or improvement relative to the prior art.
Moreover, even assuming arguendo, contrary to fact, that the UUEK enabled the use of APIs, including gRPC APIs, while the prior art ISO messaging standards did not, this would still not amount to any improvement in technology/functioning of a computer, because the putative improvement is in the UUEK, a data structure (which is part of the abstract idea), not in any technology/functioning of a computer. Rather, the technology or computer elements, namely, the APIs, including gRPC APIs, are merely used as a tool off-the-shelf in their ordinary capacities, and recited at a high level of generality and not described; neither they nor their functioning is improved.
Statement/Argument #2
Applicant argues:
Second, on page 13, the Answer states that "the network, over which the messages are sent and received, is . .. merely a generic computer element." Answer, p. 13. The Answer continues by stating that the "computer or other technology work in exactly the same way regardless of what data (e.g., identifiers versus persistent credentials) they are processing" and that "it would appear far-fetched indeed to suggest that the data that a computer processes improves the actual computer hardware or its functioning." Id., pp. 15-16. [1] The MPEP requires an improvement "in the functioning of a computer, or an improvement to other technology or technical field." MPEP § 2106.04(d)(1). It does not require improvements in the actual computer hardware and there are numerous examples in which the data that a computer processes improves the functioning of that computer. See e.g., Finjan Inc. v. Blue Coat Systems, Inc., 879 F.3d 1299, 125 USPQ2d 1282 (Fed. Cir. 2018) (Finjan).
[2] Regardless, [a] the claimed network is formed by [b] gRPC APIs established between individual services executed within an exchange platform and a plurality of member platforms. See claims 1, 14, and 18; see also Declaration ¶¶ 22 - 23; see also Specification ¶¶ 71 and 184. This is not a generic network, and it does improve the functioning of a computer in several ways. [3] For example, the credential-less messaging scheme supports the use of APIs, including JSON-based APIs and gRPC APIs, providing increased flexibility in supported data elements and allowing larger message sizes without sacrificing security or performance. Declaration ¶ 22. [4] In at least this respect, the APIs enabled by the claimed invention are fundamentally different than traditional ISO messaging standards, and the distinctions between the ISO messaging standards and the claimed APIs enable an exchange request that carries both a UUEK (for routing and verification purposes) and a plurality of object identifiers that may be invalidated or validated at the network level. Declaration ¶¶ 4-10. [5] A traditional computer, not implementing the claimed network, cannot perform this functionality, and it is clearly an issue as [a] new ISO messaging standards were developed after the filing date of the present application to address this lack of functionality. See Declaration ¶ 10. (pp. 15-16 emphasis changed from original)
The Office responds:
Regarding [1]:
The Examiner interprets Applicant's remark "It [i.e., the MPEP] does not require improvements in the actual computer hardware" as an admission that the claimed invention does not improve computer hardware.
Regarding [2]:
Regarding [a]:
The Examiner notes that the claims do not explicitly claim a "network."4 Rather the claims claim a method comprising transmissions of data between platforms (processors) via APIs (claims 1, 19) and an exchange platform (processors) that performs such transmissions (claim 14).
Regarding [b]:
The "gRPC APIs established between individual services executed within an exchange platform and a plurality of member platforms" are merely generic computer elements used as tools off-the-shelf in their ordinary capacities, recited at a high level of generality and not described. As such, they merely apply the abstract idea.
Regarding [3]:
The assertion that "the credential-less messaging scheme supports the use of APIs" has been addressed above (Statement/Argument #1, [6]). As discussed, the use of APIs is not an improvement provided by the invention. As for "providing increased flexibility in supported data elements and allowing larger message sizes": insofar as it is being asserted that Applicant's new message format provides these advantages, any putative improvement in this respect would be a putative improvement in the abstract idea; insofar as it is being asserted that APIs provide these advantages5, any such advantage is due to the APIs (generic computer elements), which Applicant did not invent but has taken off-the-shelf and incorporated into its claims.
For the record, it is noted that Applicant's specification does not teach "JSON" or "JSON-based APIs."
Regarding [4]:
Regarding the putative distinction between prior art ISO standards and the invention's use of APIs, this has been addressed above (Statement/Argument #1, [6]). Regarding "an exchange request that carries both a UUEK (for routing and verification purposes) and a plurality of object identifiers that may be invalidated or validated at the network level," it is noted that ISO 8583 provides for customizable fields, and Applicant has not elaborated why those customizable fields could not accommodate the broadly claimed "object identifiers." Further, even assuming arguendo that ISO standards could not accommodate the recited "object identifiers," any putative improvement in this regard would be an improvement in a data structure or a rule implemented by a communication protocol (i.e., abstract idea), not in technology/functioning of a computer.
Regarding [5]:
Applicant asserts "A traditional computer, not implementing the claimed network, cannot perform this functionality." It is not clear what functionality Applicant is referring to. As best understood, Applicant is referring to "the claimed APIs enable an exchange request that carries both a UUEK (for routing and verification purposes) and a plurality of object identifiers that may be invalidated or validated at the network level." In any event, Applicant's disclosure does not disclose any non-traditional computer, any improvements to a traditional computer, or any differences between the disclosed computers and traditional computers. Therefore, if the functionality could not be carried out by a traditional computer, Applicant's claimed invention is inoperable, as no device capable of carrying out the functionality is disclosed. On the other hand, if Applicant's disclosed computer carries out the functionality (as is described in the specification), then the functionality can be performed by a traditional computer.
If Applicant is arguing that it is the “claimed network,” rather than a non-traditional computer, that is required to “perform this functionality,” then Applicant is arguing merely that the claimed functionality (e.g., of the gRPC APIs) cannot be performed without the claimed network (i.e., of the gRPC APIs). Such an argument is essentially a tautology, and does not demonstrate anything substantive.
Statement/Argument #3
Applicant argues:
Third, on page 28, the Answer states that "the Examiner finds there [i.e., in claim 1] no 'specific configuration of the service provider platform, the partner platform, and the intermediary platform."' The Answer says that the specific configuration is unclaimed. Claim 14, which is representative of independent claims 1 and 18, recites inter alia:
[content of claim 14 not reproduced here]
… As amended, the specific configuration recited by the claims includes (1) an exchange platform executing a plurality of services, the plurality of services comprising a separate service for each of a plurality of member platforms, (2) a service provider platform, service provider service, and a first gRPC API established between the service provider service and the service provider platform, and (3) a partner platform, partner service, and a second gRPC API established between the partner service and the partner platform. As explained in the Declaration and the Specification, this configuration provides an intermediary platform (i.e., the exchange platform) that is capable of routing sensitive messages between member platforms and services without becoming a security vulnerability. See Declaration ¶¶ 26-28. This is an improvement over traditional security approaches for various messaging systems, which traditionally operate outside of network communication protocols instead of within network communication protocols. See Declaration ¶¶ 11-18. (pp. 16-18)
The Office responds:
Applicant's argument asserting the putative "specific configuration" was thoroughly addressed in the Examiner's Answer, specifically, at pages 24-29 ("Point #1: Appellant alleges that 'specific configuration of service provider platform, partner platform and intermediary platform' integrates the judicial exception into a practical application, as an improvement to technology/functioning of a computer") and 42-48 ("Alleged unconventional configuration/combination of computers").
In light of the instant amendments, the "specific configuration" is now said to encompass, in addition to the specific platforms as indicated in the aforementioned "Point #1" from the Examiner's Answer, also the specific services for each platform, a first gRPC API between the service provider service and the service provider platform, and a second gRPC API between the partner service and the partner platform.
The addition of these elements does not fundamentally alter the analysis set forth in the Examiner's Answer and accordingly does not alter the determination regarding eligibility under 35 U.S.C. 101.
Notably, all of the elements of the putative "specific configuration" are still recited at a high level of generality and not recited, and used as tools off-the-shelf in their ordinary capacities. Nor is any synergy seen to arise from the collection of individual elements. (The duplication of specific APIs/services for respective specific platforms does not change the calculus.) As such, the elements of the putative "specific configuration" merely apply the abstract idea.
Statement/Argument #4
Applicant argues:
[1] Fourth, on page 31, the Answer distinguishes the previously recited claims from Finjan because the security profile in Finjan has an active capability and the UUEK allegedly does not. Answer, p. 31. It is unclear what makes something active versus passive as neither the MPEP, nor Finjan comment on this "active capability." However, based on the explanation given in the Answer, the UUEK does appear to have an active capability. As explained in the Specification, the Declaration, and as recited by the claims, the UUEK contains a partition, which is used to actively route the UUEK to the correct service within the exchange platform. See e.g., Claims 1, 14, and 18; see also Declaration ¶¶ 21 and 28-29; see also Specification ¶¶ 75-77, 104-106, 194, 201, 245- 247, and 278. In this sense, the UUEK is exactly like the security profile of Finjan as, like the security profile of Finjan, the UUEK has an active capability of identifying something (e.g., a correct service executed within the exchange platform) and, by identifying that thing, improves a computer functionality (e.g., computer security is improved by enabling a more secure message that is routed without persistent credentials). Like the security profile in Finjan, it is the UUEK, not some other actor, that does the "identifying." Id., at p. 31.
[2] The Answer further states that, unlike Finjan, the UUEK does not change how the computer operates. Id. However, as explained in the Declaration and the Specification, the UUEK does change how messages are transmitted by a computer, how they are routed by a computer, and how they are processed by a computer. See e.g., Declaration ¶¶ 29-32; see also Specification ¶¶ 7-8. These changes allow for more flexible APIs and enable in-network layers of security, which are improvements over traditional messaging systems and security approaches for those messaging systems. See e.g., Declaration ¶¶ 4-22; see also Specification ¶¶ 5 and 7-8. (pp. 18-19)
The Office responds:
Regarding [1]:
Applicant asserts that "the UUEK contains a partition, which is used to actively route the UUEK to the correct service within the exchange platform." As here stated by Applicant, the partition is used, i.e., by an actor (e.g., computer processor), to route the UUEK to the correct destination. As such, the action is performed by an actor (e.g., computer), not by a character string (i.e., the partition), which is not active. Again, this point was elaborated on in the Examiner's Answer (pp. 29-32).
Regarding [2]:
This part of Applicant's argument has been addressed above (Statement/ Argument #1, [5], [6]).
Statement/Argument #5
Applicant argues:
Finally, the Answer states that Applicant did not invent the "credential-less exchange" and compares the exchange platform to a payment administrator. Answer, pp. 34-35. As explained throughout the Specification, and further explained in the Declaration, Applicant contends that they did invent the "credential-less exchange" and the exchange platform is fundamentally different from a generic payment administrator. Most notably, unlike a generic payment administrator, the exchange platform is fully credential-less and therefore does not present a single attack vector. See Specification, as filed, ¶ 4; see also Declaration ¶¶ 11, 13, and 16-18. Moreover, all messages exchanged by the exchange platform specifically do not include persistent credentials usable by any party outside of the network, which unlike current messaging protocols, renders the messages impervious to "message skimming" and other attacks on the messaging channels themselves. Declaration ¶¶ 5. (p. 19)
The Office responds:
Applicant here references the argument in the Examiner's Answer pointing out that "the use of proxies or tokens, composed of arbitrary character strings or otherwise non-sensitive information, to represent sensitive account numbers or the like" is prior art. In effect, Applicant is here pointing out that its invention is even more credential-less than the traditional use of tokens or the like, insofar as Applicant's invention does not retain any persistent credentials usable outside of the network, but rather uses merely proxies representing relationships between internal entities (e.g., member, service provider, partner), which may also be ephemeral. See Declaration, ¶¶ 19-21.
The Examiner recognizes that, although the claims do not preclude the use of persistent credentials, as described by the Declaration Applicant's invention appears to provide advantages in respect of security over traditional tokenized transactions (which are on the surface credential-less), by virtue of the total elimination of the use of traditional persistent payment credentials. Nevertheless, this distinction over the prior art is a putative improvement in the abstract idea, not in any technology/functioning of a computer. As such, the claims are squarely ineligible.
II. Examiner's response to Applicant’s Declaration
In the discussion below, page, section, and paragraph numbers refer to Applicant's Declaration, unless otherwise indicated.
In section I., the Declarant indicates he is a co-inventor of the instant claims and provides additional facts supporting his status as a person having ordinary skill in the art (PHOSITA) to which the invention pertains.
In section II., the Declarant describes the prior art of ISO messaging standards, in particular ISO 8583.
In section III., the Declarant describes deficiencies of prior art ISO 8583 standards, including size limitations and predefined fields limiting modifiability (¶ 7) and limited interoperability due to different specifications (¶ 8). Declarant also describes ISO 20022 as addressing the aforementioned problems with ISO 8583 (e.g., re: interoperability; accommodating SKU data) but as still deficient (more expensive to operate; requires metadata for self-described fields, undermining standardization benefits) (¶¶ 9-10).
Note: Applicant asserts that "ISO 20022 was introduced as a next-generation, model-based standard in 2024, after the fling data of the present patent application" (p. 3). Based on this putative fact, ISO 20022 would not be prior art to the instant claims. If ISO 20022 is not prior art, it is reasonable to ask why discussion of it is provided in the Declaration. As best understood, in light of the Remarks (p. 16), the discussion of ISO 20022 is included in the Declaration for the purpose of demonstrating the significance of the putative problems Applicant's claimed invention is designed to overcome:
… and the distinctions between the ISO messaging standards and the claimed APIs enable an exchange request that carries both a UUEK (for routing and verification purposes) and a plurality of object identifiers that may be invalidated or validated at the network level. Declaration ¶¶ 4-10. A traditional computer, not implementing the claimed network, cannot perform this functionality, and it is clearly an issue as new ISO messaging standards [namely, ISO 20022] were developed after the filing date of the present application to address this lack of functionality [namely, functionality provided by the claimed invention]. See Declaration ¶ 10.
This being said, it is not clear what is meant by Applicant's assertion that ISO 20022 is not prior art, and it is not clear that this assertion is true. According to the literature, ISO 20022 was introduced in 20046 (or 20057) and has seen increasingly widespread adoption across the financial industry, such as being adopted by The Clearing House RTP network in 2017,8 and instant payment rails moving to ISO 20022 in 2020,9 among other major players. As noted above, Anantharaman (Mastercard) (US-20220100592-A1) taught the use of ISO 20022 with gRPC APIs in 2021.10
In section IV., the Declarant describes prior art security approaches of financial messaging systems, including encryption, tokenization, and vaulting. (¶¶ 11-12). All three are said to require storage of a persistent credential, e.g., a PAN, within a platform other than the originating platform, e.g., at an administrator, thereby shifting the risk of attack from end users to administrators (¶¶ 13-14).
In section V., the Declarant describes deficiencies of prior art security approaches of financial messaging systems, including operating outside of the ISO messaging protocol (¶ 16) and requiring the transmission of persistent credentials between administrator and issuer (¶¶ 17-18).
In section VI., the Declarant describes the credential-less messaging scheme (of the instant claimed invention), which includes specific messages at each of three stages (namely, registration, enrollment, and exchange/authorization), using keys, identifiers and references, which serve as proxies of a relationship with a member platform. Notably, the keys, identifiers and references are meaningless outside of the messaging scheme/exchange platform and are not stored in association with persistent credentials, and therefore, unlike persistent credentials, are not susceptible to misuse (¶¶ 19-20). In addition, the UUEK may be ephemeral and platform-specific, created for a specific exchange, time, and merchant-issuer combination, rendering it even less susceptible to misuse (¶ 21).
At ¶ 22, the Declarant states:
[1] The credential-less messaging scheme also supports the use of APIs, including JSON-based APIs and gRPC APIs, providing increased flexibility in supported data elements and allowing larger message sizes without sacrificing security or performance. [2] By default, gRPC messages support a four-megabyte limit per message, which may be increased to two gigabytes if necessary. gRPC supports up to 65,535 fields per message, which, for practical purposes, eliminates field-count limitations. (p. 5; bracketed numerals added for reference in discussion below)
Regarding [1], as discussed above in respect of the Remarks (Statement/ Argument #1, [6]; Statement/Argument #2, [3]), this statement is unclear and misleading. As for unclarity, the claim that the credential-less messaging scheme "supports" the use of APIs appears to mean merely that the credential-less messaging scheme can be used with APIs, or in other words, that APIs support the credential-less messaging scheme. As best understood, this is misleading because (1) it suggests that the credential-less messaging scheme (Applicant's claimed invention) somehow permits usage of APIs in the financial messaging context, as if Applicant had invented the use of APIs in the financial messaging context, and (2) it suggests that the prior art messaging systems and security approaches (e.g., ISO messaging standards) do not support, or cannot be used with APIs.
As explained above, however, the prior art (e.g., ISO messaging standards) can be used with APIs. Thus, the credential-less messaging scheme (Applicant's claimed invention) is not required in order to use APIs in the financial messaging context, and Applicant did not in any way invent the use of APIs in the financial messaging context.
Further, regarding [2], any benefits provided by APIs, such as gRPC APIs, are not a benefit provided by Applicant's claimed invention. Rather, they are benefits provided by the use of gRPC APIs, which Applicant in no way invented but merely uses off-the-shelf in conjunction with Applicant's invented message format(s)/scheme(s).
In sum, as best understood, ¶ 22 confuses the record, by suggesting that advantages provided by the prior art (namely, APIs, e.g., gRPC APIs, which are generic computer elements) are really provided by Applicant's claimed invention.
In section VII., the Declarant describes the exchange platform (Applicant's claimed invention), which is characterized similarly to the credential-less messaging scheme (section VI.). Specifically, the exchange platform executes interoperable microservices defined at the member-platform level, which connect to platforms through gRPC APIs, and which do not use or store any credentials/sensitive information, but rather record relationships within internal systems, using identifiers, references, and keys. (¶¶ 23-25).
In section VIII., the Declarant further describes the exchange platform (Applicant's claimed invention), as an intermediary providing connectivity between members/platforms, using platform-specific communication channels, keys, identifiers ("partitions"), etc., which isolates and secures each member platform and assists in routing. (¶¶ 26-28). It is noted that while the exchange platform comprises additional elements, these are described at a high level of generality and are not described. As such, they merely apply the abstract idea.
In section IX., the Declarant further describes the credential-less messaging scheme (of the instant claimed invention), specifically the UUEK thereof, which includes, inter alia, a partition that enables routing to a given platform, specifically, the service that the created the UUEK, and which is rendered inoperable after completion of the message, with subsequent processing performed using network-specific references. The use of the UUEK is contrasted with the prior art, which instead uses a PAN to route messages to issuers and to perform subsequent processing.
Summary/Conclusion regarding the Declaration
The Declaration establishes the state of the art at the time of filing, namely, the use of ISO messaging standards defining message format/content (in particular, ISO 8583), and the use and storage of persistent credentials (such as a PAN), to which tokens or the like are mapped, even where messaging is on the surface credential-less, thus rendering prior art messaging systems vulnerable to attackers desiring to acquire and misuse the persistent credentials. In addition, the ISO 8583 messaging standard is somewhat limited in content/size of its payload, as many of its fields are fixed and not customizable; and, to the extent customization is used, this reduces the benefits of standardization/interoperability that the ISO 8583 standard would otherwise provide more fully.
The Declaration describes the claimed invention and demonstrates its putative improvement over this prior art, namely, an entirely credential-less messaging scheme, which avoids all use/storage of any persistent credentials, instead using multiple identifiers, keys, references, partitions or the like, which record/represent relationships between members of the exchange platform and thus do not contain sensitive data that is of use outside of the exchange platform. Further, one of the identifiers, the UUEK, is ephemeral and specific to a given exchange (transaction) and to a given pair of platforms (e.g., merchant-issuer), rendering it even more useless outside of the exchange platform and outside of the given exchange. Further, the exchange uses the identifiers, keys, references, partitions or the like (e.g., a partition identifying its originating platform) to route messages to specific platforms/services, using platform/ service-specific channels, to isolate and secure each platform. Lacking persistent credentials or useful sensitive information, the exchange platform and credential-less messaging scheme is not susceptible to bad actors, as there is no valuable data for the bad actors to intercept/steal and use for fraudulent purposes (should data of the exchange platform be compromised, it can be retired/invalidated by the system).
In addition to the putative security advantages provided by the credential-less messaging scheme, the Declaration suggests that this scheme also provides advantages of reducing the limits (e.g., size/content limits) on message payloads. However, the Declaration is unclear as to whether these advantages come from the messaging scheme, the APIs, or both. (See related discussion below regarding APIs.)
As for the exchange platform and its components (namely, member platforms and APIs), the Declaration's account (-- like the specification, the claims, and all Applicant argument heretofore --) (1) recites these elements at a high level of generality and without description, and (2) describes these elements as being used as tools off-the -shelf in their ordinary functionalities/capacities. No difference is demonstrated between these off-the-shelf elements in the claims and the prior art.
In addition, in part, the Declaration obfuscates the differences between the claimed invention and the prior art. Specifically, the Declaration appears to suggest that Applicant's credential-less messaging scheme (in contrast to ISO messaging standards) and exchange platform somehow enable the use of APIs, in particular, gRPC APIs, in the financial messaging context, and thereby/therefore allow the inherent advantages of these APIs to be harvested/harnessed for the financial messaging context for the first time. However, the literature plainly teaches that these APIs are usable with the ISO messaging standards (e.g., ISO 8583, 20022). Accordingly, Applicant did not invent anything in this respect and cannot take credit for these advantages inherent to APIs/ gRPC APIs.
As per the foregoing, the Declarant has clearly demonstrated that Applicant's claimed credential-less messaging scheme provides a putative improvement (e.g., in security) compared to prior art ISO messaging schemes. This putative improvement is a putative improvement in the abstract idea. An improvement in the abstract idea does not render the claims eligible under 35 U.S.C. 101.
The Declarant has not demonstrated any improvement in the additional elements (e.g., exchange platform and its components), or in the combination of the additional elements and the abstract idea, as compared to the prior art. Rather, the Declarant has reconfirmed that the additional elements merely apply the abstract idea. As such, the Declarant has not shown any improvement in technology or functioning of a computer. Nor has the Declarant shown any other practical application, or 'significantly more', such as would render the claimed invention eligible under 35 U.S.C. 101.
Claim Objections
Claims 1, 14 and 19 are objected to because of the following informalities:
Claims 1, 14 and 19 recite:
(2)
…
(ii) generating, by the one or more processors and via the partner service, a universally unique ephemeral key (UUEK) by wrapping the exchange identifier with a partner partition, identifying the partner platform, wherein the partner partition and the exchange identifier are positioned in accordance with a key format to form the UUEK; and
As is understood from the previous version of the claims,11 the comma in the underlined portion above is a clerical error. It is understood that Applicant intended to recite "a partner partition identifying the partner platform" instead of the underlined portion above.
Claims 1, 14 and 19 are objected to because of the following informalities:
Claims 1, 14 and 19 recite:
(3)
…
(viii) …; and
(xi) providing, ….
The numbering underlined above is incorrect. That is, (viii) should be followed by (ix).
This is understood to be a clerical error. (xi) should be changed to (ix).
Claim 14 is objected to because of the following informalities:
Claim 14 recites:
(1)
…
(b) the plurality of services comprises the service provider platform and a partner service, and
The underlined word is incorrect, and is understood to be a clerical error. As understood from context and corresponding claim 1, the underlined word "platform" should be changed to "service."
Claim 19 is objected to because of the following informalities:
Claim 19 recites:
(1)
…
(c) the plurality of services comprises the service provider platform and a partner service, and
The underlined word is incorrect, and is understood to be a clerical error. As understood from context and corresponding claim 1, the underlined word "platform" should be changed to "service."
Claim 20 is objected to because of the following informalities:
Claim 20 recites:
… wherein the one or more processors are further configured to:
determining …; and
providing ….
The underlined text is not grammatical in context. This is understood to be a clerical error. To correct the grammar, the word "determining" should be changed to "determine," and the word "providing" should be changed to "provide."
Appropriate correction is required.
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, 2, 4-15 and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1, 2, 4-15 and 17-20 are directed to a method, exchange platform, or computer-readable storage media, which are/is one of the statutory categories of invention. (Step 1: YES)
Claims 1, 14 and 19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite a method, exchange platform, and computer-readable storage media for transaction (exchange) processing, including applying transaction rules (e.g., determining whether exchange objects are valid based on a policy) and avoiding disclosure of sensitive information. For claims 1, 14 and 19 (claim 1 being deemed representative), the limitations (indicated below in bold) of:
(1) at a first time, during a registration process:
(i) receiving, by one or more processors of an exchange platform and via a first remote procedure call (gRPC) application programming interface (API) established between a service provider platform and a service provider service executed by the exchange platform, an instrument reference that comprises a unique identifier for referencing a member instrument identifier for a service provider instrument maintained by the service provider platform, wherein:
(a) the exchange platform executes a plurality of services comprising a separate service for each of a plurality of member platforms,
(b) the plurality of member platforms comprises the service provider platform and a partner platform,
(c) the plurality of services comprises the service provider service and a partner service, and
(d) the instrument reference is a different value than the member instrument identifier and is mapped to the member instrument identifier;
(ii) generating, by the one or more processors and via the service provider service, an instrument key that corresponds to the service provider instrument by wrapping a universally unique identifier (UUID) with a service provider partition that corresponds to the service provider platform;
(iii) storing, by the one or more processors and via the service provider service, the UUID and the instrument reference within a system instrument data object; and
(iv) providing, by the one or more processors and via the service provider service, the instrument key to the service provider platform;
(2) at a second time, in response to a successful enrollment with the partner platform:
(i) generating, by the one or more processors and via the partner service, a partner-specific exchange data object and storing an exchange identifier and the instrument key within the partner-specific exchange data object;
(ii) generating, by the one or more processors and via the partner service, a universally unique ephemeral key (UUEK) by wrapping the exchange identifier with a partner partition,12 identifying the partner platform, wherein the partner partition and the exchange identifier are positioned in accordance with a key format to form the UUEK; and
(iii) providing, by the one or more processors and via a second gRPC API established between the partner service and the partner platform, the UUEK to the partner platform; and
(3) at a third time subsequent to the first time and the second time:
(i) receiving, by the one or more processors and through the second gRPC API, an exchange request comprising the UUEK and a plurality of object identifiers;
(ii) identifying, by the one or more processors and via the partner service, the partner-specific exchange data object based at least in part on the exchange identifier of the UUEK;
(iii) identifying, by the one or more processors and via the service provider service, the system instrument data object based at least in part on the instrument key within the partner-specific exchange data object;
(iv) identifying, by the one or more processors and via the service provider service, a member policy corresponding to the service provider platform based at least in part on the instrument key;
(v) determining, by the one or more processors and via the service provider service, a validated object and an invalidated object from the plurality of object identifiers based at least in part on the member policy;
(vi) providing, by the one or more processors, via the service provider service, and through the first gRPC API, an exchange authorization request to the service provider platform, wherein the exchange authorization request comprises the instrument key, the instrument reference, and the validated object for the exchange request;
(vii) receiving, by the one or more processors, via the service provider service, from the service provider platform, and through the first gRPC API, an exchange authorization response;
(viii) providing, by the one or more processors, via the service provider service, the exchange authorization response to the partner service; and
(xi) providing, by the one or more processors, via the partner service, to the partner platform, and through the second gRPC API, an exchange response based at least in part on the exchange authorization response.
as drafted, constitute a process that, under the broadest reasonable interpretation, covers "certain methods of organizing human activity," specifically, "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components. The Examiner notes that "fundamental economic practices" or "fundamental economic principles" describe concepts relating to the economy and commerce, including hedging, insurance, and mitigating risks, and "commercial interactions" or "legal interactions" include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. MPEP 2106.04(a)(2)II.A.,B. If a claim limitation, under its broadest reasonable interpretation, covers "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components, then it falls within the "certain methods of organizing human activity" grouping of abstract ideas. Accordingly, claims 1, 14 and 19 recite an abstract idea. (Step 2A - Prong 1: YES. The claims recite an abstract idea.)
This judicial exception is not integrated into a practical application. Claims 1, 14 and 19 recite the additional elements of one or more processors of an exchange platform; a first remote procedure call (gRPC) application programming interface (API) established between a service provider platform and a service provider service executed by the exchange platform; the service provider platform; (a) the exchange platform executes a plurality of services comprising a separate service for each of a plurality of member platforms, (b) the plurality of member platforms comprises the service provider platform and a partner platform, (c) the plurality of services comprises the service provider service and a partner service; the service provider service; the partner platform; the partner service; a second gRPC API established between the partner service and the partner platform (claim 1); an exchange platform executing a plurality of services, the plurality of services comprising a separate service for each of a plurality of member platforms, wherein the exchange platform comprises one or more memories and one or more processors communicatively coupled to the one or more memories, the one or more processors configured to:; a first remote procedure call (gRPC) application programming interface (API) established between a service provider platform and a service provider service of the plurality of services; the service provider platform; (a) the plurality of member platforms comprises the service provider platform and a partner platform, (b) the plurality of services comprises the service provider platform and a partner service; the service provider service; the partner platform; the partner service; a second gRPC API established between the partner service and the partner platform (claim 14); and one or more non-transitory computer-readable storage media including instructions that, when executed by one or more processors, cause the one or more processors to:; a first remote procedure call (gRPC) application programming interface (API) established between a service provider platform and a service provider service executed by an exchange platform; the service provider platform; (a) the exchange platform executes a plurality of services comprising a separate service for each of a plurality of member platforms, (b) the plurality of member platforms comprises the service provider platform and a partner platform, (c) the plurality of services comprises the service provider platform and a partner service; the service provider service; the partner platform; the partner service; a second gRPC API established between the partner service and the partner platform (claim 19), that implement the abstract idea. These additional elements are not described by the applicant and they are recited at a high level of generality (i.e., one or more generic computer elements performing generic computer functions), such that they amount to no more than mere instructions to apply the exception using generic computer elements. Accordingly, even in combination these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (Step 2A - prong 2: NO. The additional elements do not integrate the abstract idea into a practical application.)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of one or more processors of an exchange platform; a first remote procedure call (gRPC) application programming interface (API) established between a service provider platform and a service provider service executed by the exchange platform; the service provider platform; (a) the exchange platform executes a plurality of services comprising a separate service for each of a plurality of member platforms, (b) the plurality of member platforms comprises the service provider platform and a partner platform, (c) the plurality of services comprises the service provider service and a partner service; the service provider service; the partner platform; the partner service; a second gRPC API established between the partner service and the partner platform (claim 1); an exchange platform executing a plurality of services, the plurality of services comprising a separate service for each of a plurality of member platforms, wherein the exchange platform comprises one or more memories and one or more processors communicatively coupled to the one or more memories, the one or more processors configured to:; a first remote procedure call (gRPC) application programming interface (API) established between a service provider platform and a service provider service of the plurality of services; the service provider platform; (a) the plurality of member platforms comprises the service provider platform and a partner platform, (b) the plurality of services comprises the service provider platform and a partner service; the service provider service; the partner platform; the partner service; a second gRPC API established between the partner service and the partner platform (claim 14); and one or more non-transitory computer-readable storage media including instructions that, when executed by one or more processors, cause the one or more processors to:; a first remote procedure call (gRPC) application programming interface (API) established between a service provider platform and a service provider service executed by an exchange platform; the service provider platform; (a) the exchange platform executes a plurality of services comprising a separate service for each of a plurality of member platforms, (b) the plurality of member platforms comprises the service provider platform and a partner platform, (c) the plurality of services comprises the service provider platform and a partner service; the service provider service; the partner platform; the partner service; a second gRPC API established between the partner service and the partner platform (claim 19), to perform the noted steps amount to no more than mere instructions to apply the exception using generic computer elements. Mere instructions to apply an exception using generic computer elements cannot provide an inventive concept ("significantly more"). Accordingly, even in combination, these additional elements do not provide significantly more. As such, claims 1, 14 and 19 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more.)
Dependent claims 2, 4-13, 15, 17, 18 and 20 are similarly rejected because they further define/narrow the abstract idea of independent claims 1, 14 and 19 as discussed above, and/or do not integrate the abstract idea into a practical application or provide an inventive concept such as would render the claims eligible, whether each is considered individually or as an ordered combination.
As for further defining/narrowing the abstract idea:
Claims 2 and 15 merely describe wherein the exchange request comprises one or more request resolution flags that are indicative of a partial exchange authorization or a full exchange authorization, and wherein providing the exchange authorization request … comprises: determining that the one or more request resolution flags are indicative of the partial exchange authorization; and providing the exchange authorization request … in response to determining that the one or more request resolution flags are indicative of the partial exchange authorization.
Claims 4 and 17 merely describe wherein an object identifier of the plurality of object identifiers is a stock keeping unit.
Claims 5 and 18 merely describe wherein the member policy comprises a plurality of authorized object identifiers and determining the validated object and the invalidated object for the exchange request comprises: determining the validated object based at least in part on a comparison between the plurality of object identifiers and the plurality of authorized object identifiers; and determining the invalidated object based at least in part on a comparison between the validated object and the plurality of object identifiers.
Claim 6 merely describes wherein the member policy comprises a plurality of authorized object attributes and determining the validated object and the invalidated object for the exchange request comprises: identifying a plurality of recorded data objects corresponding to the plurality of object identifiers, wherein a recorded data object comprises a plurality of object attributes for an object; determining the validated object based at least in part on a comparison between the plurality of recorded data objects and the plurality of authorized object attributes; and determining the invalidated object based at least in part on a comparison between the validated object and the plurality of object identifiers.
Claim 7 merely describes wherein the plurality of object attributes comprises at least one of a spatial attribute, a count attribute, a value attribute, a source attribute, a composition attribute, or a categorical attribute.
Claim 8 merely describes further comprising incrementing the count attribute for the object in response to the exchange request.
Claim 9 merely describes wherein the member policy is identified based at least in part on … a location associated with the exchange request.
Claim 10 merely describes wherein the location comprises an exchange location and the exchange request is indicative of the exchange location.
Claim 11 merely describes wherein the location comprises a user location and the …-implemented method further comprises: determining a user identifier based at least in part on the UUEK; determining the user location based at least in part on a system user data object corresponding to the user identifier; and identifying the member policy based at least in part on … the user location.
Claim 12 merely describes wherein the exchange request is indicative of an exchange location and the member policy is indicative of one or more authorized locations, and wherein the …-implemented method further comprises: determining the validated object and the invalidated object for the exchange request based at least in part on a comparison between the exchange location and the one or more authorized locations.
Claims 13 and 20 merely describe wherein the exchange request comprises a plurality of object values corresponding to the plurality of object identifiers and an initial exchange value for the plurality of object identifiers, and wherein the …-implemented method further comprises (claim 13) / wherein … are further configured to (claim 20): determining an exchange value by modifying the initial exchange value based at least in part on one or more of the plurality of object values that correspond to the validated object; and providing the exchange authorization request …, wherein the exchange authorization request is indicative of the exchange value.
As for additional elements:
Claims 2 and 15 merely recite that a request is provided to “the service provider platform.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 9 merely recites that a policy is identified based on “the service provider platform.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 11 merely recites that a policy is identified based on “the service provider platform.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 13 and 20 merely recite that “the one or more processors” are further configured to perform operations (claim 20), and that a request is provided to “the service provider platform.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 4-8, 10, 12, 17 and 18 do not recite any additional elements, and accordingly, for the reasons provided above with respect to the independent claims, are not patent eligible.
Therefore, dependent claims 2, 4-13, 15, 17, 18 and 20 are not patent eligible.
Conclusion
The prior art made of record and not relied upon, as set forth in the accompanying Notice of References Cited (PTO-892), is considered pertinent to applicant's disclosure. Among the cited references:13
Fitzpatrick (US-20230208644-A1), Drunsic (US-20020147678-A1), Bennett (US-20060149626-A1) and Skiba (US-20150127476-A1) teach processing a transaction including determining whether transaction attributes conform to a policy (e.g., whether objects for purchase are valid or invalid based on a policy).
Mullaney (US-20190251565-A1) and Niehaus (US-20180047024-A1) teach the generation and use of identifiers/tokens (e.g., account number proxies) for use in transactions (e.g., for authorization), which promote security/privacy.
Fuentes (US-20130054468-A1) teaches a SYSTEM AND METHOD FOR CONDUCTING FINANCIAL TRANSACTIONS, comprising a system architecture that enables access to non-bank financial institutions (NFBIs) and banks through point-of-sale devices and mobile telephones, including one embodiment where the ISO 8583 standard is expanded so as to allow users to interface with a front end processing system directly from non-traditional devices (wherein a modified ISO 8583 message is created and communicated to an API, which converts the message to a standard ISO 8583 message); another embodiment where mobile banking with the NBFI or banks can be achieved through use of an application residing in a user's mobile telephone, which allows the encapsulation of user information as XML, for example, and the transmission of those over http while complying with the aforementioned ISO 8583 expansion, and further allowing encryption of certain user data; and a third embodiment where a POS application may run on top of the PCI standard to enable users to make purchases using funds pre-deposited in an NBFI account (to achieve this, the POS application may initiate a session with the NBFI or bank and use an encrypted message obtained through that first session to encrypt information as part of a second session which will then be used to finalize the transaction while the first session expires).
Anantharaman (US-20220100592-A1) teaches Systems And Methods For Use In Correlating Messages Across Disparate Interfaces, which implement an enhanced remote procedure call (RPC) (e.g., gRPC (as developed by Google®), etc.) to transport transaction messages for a transaction (e.g., transfer request messages for a fund transfer, etc.), whereby a unique identifier associated with the transaction is appended to each of the messages (e.g., to a header or wrapper on top of a payload, etc.) (regardless of format), and in connection therewith, for each of the messages for the transaction, a conventional transaction message (e.g., in accordance with ISO 8583, ISO 20022, etc.) is included as the payload of the given message, wherein the systems and methods may further rely on serialization of the data included in the transaction messages (e.g., in accordance with protocol buffers (protobuf), etc.) for data transfer, whereby, in this manner, the transaction messages from one end of a payment network (or beyond) (e.g., initiated through one interface (e.g., one channel or network, etc.), etc.) to the other end of the payment network (or banking institution, etc.) (e.g., handled/processed in another interface (e.g., via another channel or network, etc.), etc.) are identifiable (e.g., without altering the ISO standard, etc.), and whereby individual transactions are traceable for end-to-end visibility, for example, for reasons associated with status of the transactions, diagnosis, fraud scoring, insights, etc., see e.g., 0012, 0020.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS W PINSKY whose telephone number is (571)272-4131. The examiner can normally be reached on 8:30 am – 5:30 pm ET.
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, Jessica Lemieux can be reached on 571-270-3445. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR.
Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DOUGLAS W PINSKY/ /JESSICA LEMIEUX/Examiner, Art Unit 3626 Supervisory Patent Examiner, Art Unit 3626
1 See, e.g., Kumar, "Introduction to ISO 8583," p. 1 ("ISO 8583 specifies message structure, format and content, data element and values of data elements."), p. 13 ("ISO-8583 does not define any communication protocol"); IBM, "ISO8583 messaging standard," p. 1 ("The ISO8583 standard specifies a message format that describes credit card and debit card data that is exchanged between devices and card issuers.")
2 See, e.g., Poza, "What Is an API? How APIs Work (for Non-Developers)," p. 2 ("An application programming interface (API) is a piece of code that acts as an intermediary between two different pieces of software and enables them to communicate with each other."); Bock, "WTF is an API? How the Internet Works Behind the Scenes," p. 2 ("an API is a set of rules that dictate how one application communicates with another").
3 See, e.g., Fuentes (US-20130054468-A1) teaching the use of ISO 8583 messages with APIs, and Anantharaman (US-20220100592-A1) teaching the use of ISO 8583/ 20022 messages with APIs, including gRPC APIs, as discussed in Conclusion below.
4 The instant amendments delete "for executing a network based exchange" from the claims.
5 See Declaration, ¶ 22, second and third sentences, which suggests that these advantages are provided by the APIs, not by Applicant's message format.
6 Volante, "Demystifying ISO 20022 Migration," p. 1 (ISO 20022 "was introduced in 2004 ….").
7 Alacriti, "ISO 20022: Why After Almost 2 Decades it’s More Important than Ever," p. 1 (ISO 20022 "was introduced in 2005 ….").
8 Alacriti, "ISO 20022: Why After Almost 2 Decades it’s More Important than Ever," p. 3 ("In 2017, The Clearing House RTP network was the first new central clearing and settlement system introduced that adopted ISO 20022.").
9 Volante, "Demystifying ISO 20022 Migration," p. 1 ("Now [Dec. 2020] the movement is gathering steam, and major payment market infrastructures, instant payment rails, and SWIFT cross-border payments are making the move to ISO 20022.").
10 See footnote 3 above and "Conclusion" below.
11 The "previous version of the claims" refers to the Amendment filed on 05/27/25. See, e.g., claim 1, paragraph (2)(i).
Note while the Appeal Brief should contain the same claims as the Amendment filed on 05/27/25, the claims as set forth in the Appeal Brief do not match those of the Amendment and are generally not correct/reliable, as explained in the Examiner's Answer (filed on 02/02/26), p. 3 and Appendix 1, pp. 49-51.
For clarification of the record, it should also be noted that the marked-up version of the claims presented in the instant Amendment does not accurately "indicate the changes that have been made relative to the immediate prior version of the claims." 37 CFR 1.121(c)(2).
12 Note this comma is a typographical error and should be omitted. See "Claim Objections" above.
13 Note that WO-2014011691-A1 (SHRIVASTAVA ABHINAV) is enclosed as two separate parts because the document file size is too large; accordingly, it is required to list the two parts separately on the Notice of References Cited (PTO-892).
