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
This Amendment filed on 09 March 2026 is acknowledged.
Status of Claims
Claims 1, 4-6, 8, 11-13, 15 and 18-20 are pending.
In the Amendment filed on 03/09/26, claims 1, 8 and 15 were amended, and no claims were cancelled or added (claims 2, 3, 7, 9, 10, 14, 16 and 17 were cancelled in previous papers).
Claims 1, 4-6, 8, 11-13, 15 and 18-20 are rejected.
Response to Arguments
Regarding the double patenting rejections
In view of the instant claim amendments, the rejection is withdrawn.
Regarding the rejection under 35 U.S.C. 101
Applicant's arguments have been fully considered but are not persuasive.
The Office responds to the arguments below, as per the headings used by Applicant in the Amendment. Page numbers indicated below refer to Applicant's Amendment unless otherwise indicated.
Step 2A, Prong 2 (pp. 13-15)
Applicant argues that claim 1 as amended
integrates [any judicial] exception into a practical application because the claim now recites how the system stores and retrieves decision data in a distributed cache in a way that is technically constrained and performance-oriented, i.e., it is no longer simply "use a cache" or "perform single-call retrieval." (pp. 13-14; emphasis in original) (quote #1)
More specifically, Applicant cites the instant amended claim language (p. 14, bullet points), which Applicant summarizes as:
storing into packets + specific compressed Protobuf format + specific decoding regime + single-call-enabling format[,] which is more than merely "apply it" with generic computing components. This directly addresses the Office's point that it previously saw no "improvement in computer technology" and only off-the- shelf use. (p. 14; emphasis added) (quote #2)
or again as:
a particular packet-based storage and retrieval workflow and a format specifically enabling single-call retrieval, which is not "high-level" in the way the Office criticized.(p. 14; emphasis added) (quote #3)
or again as:
storing the event into one or more packets, using a compressed Protobuf format, creating and decoding the packets using that format, and decoding the stored packets upon retrieval, with the overhead reduction tied to packet create/decode operations in the claim, not merely an intended result.(p. 15; emphasis added) (quote #4)1
Based on the above, Applicant thus argues that claim 1 represents an improvement in computer technology (as per quote #2 above, p. 14), that "the distributed cache/platform" is not generic and high level (in connection with quote #3 above, p. 14), that the "low latency / reduce computational overhead" are not intended use or intended result (in connection with quote #4 above, p. 15), and that
the amended additional elements are no longer "mere instructions to apply the exception" but instead recite a specific technical implementation for distributed cache persistence and retrieval that meaningfully limits the claim and integrates the concept into a practical application (computer/network performance via constrained data representation and packet handling) (p. 15; emphasis added) (quote #5)
In response to Applicant's arguments:
Without purporting to capture the entirety of the amended claim language, the amended claim language at its core covers subject matter comprising compressing data (changing the format of data), storing the compressed data, retrieving the compressed data, and decompressing the retrieved compressed data (changing the format of the data), as per the language underlined in quotes #2, #3, and #4 above (pp. 14-15)2. Among this subject matter, the compression/decompression/changing of the format of data amounts to part of the abstract idea, and the storing and retrieving are merely generic computer additional elements recited at a high level of generality and not described.
To the extent that the claim has been further specified (in Applicant's words, reciting the "how"), this further specifying is a matter of specifying the abstract idea. The improvement that Applicant here argues is a matter of using the Protobuf format -- reformatting/compressing the data into the Protobuf format and then reformatting/ decompressing the data out of the Protobuf format. The use of the Protobuf format is combined with (applied using) ordinary storing and retrieving operations (generic computer elements). But it is the use of the Protobuf format that achieves the putative improvement, i.e., that reduces computational overhead and latency/end-to-end delay, as conceded by Applicant in the amended claim language and in the argument:
persisting … the real-time event to the distributed cache by storing, the real-time event into one or more packets encoded in a format that enables querying and retrieving required values … in a single call to the distributed cache, the format comprising a compressed data format, the compressed data format comprising a Protobuf format, … by storing, in the distributed cache, the one or more packets for low latency access …, thereby enabling querying and retrieving, with a single call to the distributed cache, … by creating and decoding the one or more packets using the Protobuf format that reduces computational overhead to create and decode packets of the data, thereby providing less end-to-end delay; (claim 1, amended language)
storing the event into one or more packets, using a compressed Protobuf format, creating and decoding the packets using that format, and decoding the stored packets upon retrieval, with the overhead reduction tied to packet create/decode operations in the claim, not merely an intended result.(p. 15; emphasis added) (quote #4)
the amended additional elements are no longer "mere instructions to apply the exception" but instead recite a specific technical implementation for distributed cache persistence and retrieval that meaningfully limits the claim and integrates the concept into a practical application (computer/network performance via constrained data representation and packet handling) (p. 15; emphasis added) (quote #5)
In sum, the putative improvement is the use of the Protobuf format, that is to say, the putative improvement is a putative improvement of the abstract idea, which does not render a claim eligible under 35 U.S.C. 101.
Step 2B (pp. 15-16)
Applicant presents essentially the same content as in step 2A, prong 2, above, and alleges that it is an "ordered combination" and therefore "something more" under step 2B.
In response, it has been explained above with reference to step 2A, prong 2, that this content is merely an abstract idea applied using generic computer elements, and accordingly does not rise to the level of "something more" under step 2B.
Applicant further argues that this content provides a "synergy." This assertion is not persuasive. Specifically, Applicant argues:
… The cache is not used generically; it stores one or more packets in a specific format selected to enable single-call querying/retrieval of required values. The Protobuf format and packet create/decode operations are not generic "data storage"; they are explicitly part of the persistence/retrieval flow (store event into packets [Wingdings font/0xE0] store packets in distributed cache [Wingdings font/0xE0] single-call retrieve [Wingdings font/0xE0] decode packets from Protobuf), with a stated computational effect tied to packet create/decode.
That is precisely the type of functional interaction ("in combination to perform functions that are not generic computer functions") the Office said was absent. (p. 16; emphasis in original)
In response, the Office respectfully disagrees. While the Protobuf format may be specific and not generic, it is merely a part of the abstract idea, as explained above. The storing and retrieving are merely generic computer operations. The fact that storage (e.g., a cache) stores data that has a specific format does not mean that the storage, or use of the storage, is thereby somehow rendered specific.
Further, Applicant's argument does not present any synergy. By "synergy" is meant something beyond the sum of the individual parts. The "functional interaction" presented refers merely to the fact that data of a particular data format is stored in and retrieved from generic storage elements, by generic storage and retrieval operations. There is nothing in this presentation that is beyond the sum of the individual parts.
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, 4-6, 8, 11-13, 15 and 18-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, 4-6, 8, 11-13, 15 and 18-20 are directed to a method, system, or product, which are/is one of the statutory categories of invention. (Step 1: YES)
Claims 1, 8 and 15 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, system, and computer program product for suppressing application of a rule for processing a transaction (e.g., a fraud rule used in deciding whether to authorize/reject a transaction; e.g., in order to comply with local regulations, see specification 0003, 0065, 0087, 0094). For claims 1, 8 and 15 (claim 1 being deemed representative), the limitations (indicated below in bold) of:
storing, with at least one processor, in a database, a graph including a plurality of edges and a plurality of nodes for the plurality of edges, wherein the plurality of nodes is associated with a plurality of accounts in a Real-Time Payments (RTP) network, wherein the plurality of edges is associated with a plurality of prior transactions between the plurality of accounts in the RTP network, wherein the plurality of edges is further associated with one or more transaction chargebacks associated with one or more prior transactions of the plurality of prior transactions, and wherein the one or more transaction chargebacks are associated with a request to a first user associated with a first account to refund or return a payment made in the one or more prior transactions to a second user associated with a second account;
storing, with the at least one processor, in a distributed cache, at least one rule associated with the plurality of accounts in the RTP network, wherein the at least one rule is stored in association with account data associated with the plurality of accounts and determined based on the graph stored in the database, wherein the at least one rule is configured for use in processing transactions in the RTP network associated with the plurality of accounts, wherein the account data associated with the plurality of accounts is determined based on the graph, and wherein the account data associated with the plurality of accounts includes, for each account of the plurality of accounts, at least one of: a number of transaction chargebacks associated with that account, a total payment amount of transaction chargebacks associated with that account, or any combination thereof;
processing, with the at least one processor, using the at least one rule, the transactions, including denying, by the at least one processor, based on the at least one rule, the transactions in the RTP network for each account of the plurality of accounts that is an originating account for the transactions and is associated with at least one of: a number of transaction chargebacks greater than a threshold number, a total payment amount of chargebacks greater than a threshold total payment amount, or any combination thereof;
polling, with the at least one processor, an event streaming platform for a real-time event;
receiving, with the at least one processor, the real-time event associated with at least one account level exclusion directive associated with at least one account of the plurality of accounts, wherein the real-time event is generated by the event streaming platform and published in real-time to an endpoint including the at least one processor, and wherein application of the at least one account level exclusion directive is configured to exclude use of the at least one rule for processing transactions associated with the at least one account;
persisting, with the at least one processor, the real-time event to the distributed cache by storing, the real-time event into one or more packets encoded in a format that enables querying and retrieving required values for the at least one rule and/or the at least one account level exclusion directive in a single call to the distributed cache, the format comprising a compressed data format, the compressed data format comprising a Protobuf format, and storing, in the distributed cache, the at least one account level exclusion directive in association with the at least one account and the account data associated with the at least one account by storing, in the distributed cache, the one or more packets for low latency access of the at least one account level exclusion directive, thereby enabling querying and retrieving, with a single call to the distributed cache, the at least one rule, the at least one account level exclusion directive, and the account data associated with the at least one account by creating and decoding the one or more packets using the Protobuf format that reduces computational overhead to create and decode packets of the data, thereby providing less end-to-end delay;
receiving, with the at least one processor, transaction data associated with a transaction in the RTP network between the at least one account and at least one other account, wherein the transaction data includes an RTP payment or a request to transfer a payment amount from the at least one account to the at least one other account;
retrieving, with the at least one processor, from the distributed cache, with the single call to the distributed cache, the at least one rule, the at least one account level exclusion directive, and the account data associated with the at least one account, including decoding, from the Protobuf format, the one or more packets stored in the distributed cache to obtain the at least one account level exclusion directive and the account data associated with the at least one account, wherein whether to apply the at least one account level exclusion directive to the transaction is determined based on the at least one account being associated with the at least one account level exclusion directive in the distributed cache;
determining, with the at least one processor, to apply the at least one account level exclusion directive to the transaction based on the at least one account being associated with the at least one account level exclusion directive in the distributed cache;
in response to determining to apply the at least one account level exclusion directive to the transaction, excluding, with the at least one processor, use of the at least one rule for processing the transaction in the RTP network between the at least one account and the at least one other account; and
authorizing or denying, with the at least one processor, without applying the at least one rule, the transaction in the RTP network
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 and generally linking the use of a judicial exception to a particular technological environment or field of use. (Note: “for low latency access” is intended use, and ”that reduces computational overhead” is a necessary result of using the Protobuf format, and hence these limitations are part of the abstract idea, not additional elements.) 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 and generally linking the use of a judicial exception to a particular technological environment or field of use, then it falls within the "certain methods of organizing human activity" grouping of abstract ideas. Accordingly, claims 1, 8 and 15 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, 8 and 15 recite the additional elements of storing in a database (claims 1, 8 and 15), a processor (for performing various operations) (claims 1, 8 and 15), a Real-Time Payments (RTP) network (claims 1, 8 and 15), storing/persisting in/to, and querying/retrieving data from (by a call to), a distributed cache (claims 1, 8 and 15), a platform (which is the object and subject of performing operations) (claims 1, 8 and 15), a memory (claim 8), and a computer program product (claim 15), 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, or a field of use limitation), such that they amount to no more than mere instructions to apply the exception using generic computer elements, or, in the case of the Real-Time Payments (RTP) network, such that it amounts to no more than generally linking the use of a judicial exception to a particular technological environment or field of use (being merely an incidental or token addition to the claims that does not alter or affect how the claimed operations are performed). 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 storing in a database (claims 1, 8 and 15), a processor (for performing various operations) (claims 1, 8 and 15), a Real-Time Payments (RTP) network (claims 1, 8 and 15), storing/persisting in/to, and querying/retrieving data from (by a call to), a distributed cache (claims 1, 8 and 15), a platform (which is the object and subject of performing operations) (claims 1, 8 and 15), a memory (claim 8), and a computer program product (claim 15), to perform the noted steps amount to no more than mere instructions to apply the exception using generic computer elements, or amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use. Mere instructions to apply an exception using generic computer elements or generally linking the use of a judicial exception to a particular technological environment or field of use cannot provide an inventive concept ("significantly more"). Accordingly, even in combination, these additional elements do not provide significantly more. As such, claims 1, 8 and 15 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more.)
Dependent claims 4-6, 11-13 and 18-20 are similarly rejected because they further define/narrow the abstract idea of independent claims 1, 8 and 15 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 4, 11 and 18 merely describe wherein whether to apply the at least one account level exclusion directive is further determined based on at least one parameter associated with the transaction.
Claims 5, 12 and 19 merely describe wherein the at least one parameter associated with the transaction includes at least one of the following parameters: a date and/or timestamp associated with the transaction; a financial institution associated with the at least one account; a financial institution associated with the at least one other account; a geographic location associated with the at least one account; a geographic location associated with the at least one other account; an amount associated with the transaction; or any combination thereof.
Claims 6, 13 and 20 merely describe … at least one other rule associated with the at least one other account in …, wherein the at least one other rule … in association with account data associated with the at least one other account, wherein the at least one other rule is configured for use in processing transactions in … associated with the at least one other account, wherein the at least one other rule is configured … to authorize or deny transactions in … associated with the at least one other account based on a fraud level associated with the at least one other account, and wherein the account data associated with the at least one other account includes the fraud level.
As for additional elements:
Claims 6, 13 and 20 recite “storing, with the at least one processor, in the distributed cache, … the RTP network … is stored … the RTP network … to cause the at least one processor … the RTP network ….” 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 (storing, with the at least one processor, in the distributed cache; is stored; to cause the at least one processor) or generally linking the use of a judicial exception to a particular technological environment or field of use (the RTP network). 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 20 further recites “wherein the program instructions, when executed by the at least one processor, further cause the at least one processor to." 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, 5, 11, 12, 18 and 19 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 4-6, 11-13 and 18-20 are not patent eligible.
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 extension fee 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 date of this final action.
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/
Examiner, Art Unit 3626
/JESSICA LEMIEUX/Supervisory Patent Examiner, Art Unit 3626
1 or again see also the summaries of the amended language provided in the Step 2B argument, specifically, the bullet points at pp. 15-16 and "the persistence/retrieval flow (store event into packets --> store packets in distributed cache --> single-call retrieve --> decode packets from Protobuf), with a stated computational effect tied to packet create/decode" (p. 16; emphasis in original).
2 and as per the content of p. 16 indicated in footnote 1 above.
Prosecution Insights