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 .
This is a Final Office Action in response to application 18/489,673 entitled "SYSTEM AND METHOD WITH REAL TIME MESSAGING" filed on July 6, 2026, with Claims 1, 3, 4, 6, 9-11, 13-16, and 19-26 pending.
Status of Claims
Claims 1, 6, 15, and 16 have been amended and are hereby entered.
Claims 2, 5, 7, 8, 12, 17, and 18 were previously cancelled.
Claims 1, 3, 4, 6, 9-11, 13-16, and 19-26 are pending and have been examined.
Response to Amendment
The amendment filed July 6, 2026, has been entered. Claims 1, 3, 4, 6, 9-11, 13-16, and 19-26 remain pending in the application. Applicant’s amendments to the Specification, Drawings, and/or Claims have been noted in response to the Non-Final Office Action mailed April 6, 2026.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on December 30, 2025, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the Examiner.
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, 3, 4, 6, 9-11, 13-16, and 19-26 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Please see MPEP 2106 for additional information regarding Patent Subject Matter Eligibility Guidance.
Claims 1, 3, 4, 6, 9-11, 13-16, and 19-26 are directed to a system, method/process, machine/apparatus, or composition of matter, which are/is one of the statutory categories of invention. (Step 1: YES).
The claimed invention is directed to an abstract idea without significantly more.
Independent Claim 1 recites:
“receiving, by a … messaging … from a receiver institution computer via a network interface using a secure communications protocol, an electronic message comprising an encrypted request payload, the electronic message comprising an interaction request message for an interaction comprising a sender identifier associated with a sender and interaction details comprising an amount for the interaction, wherein the sender identifier is an alias;
determining, by the … messaging .., a data metrics score based on data in the interaction request message and evaluating whether the data metrics score satisfies an acceptable threshold condition, wherein further transmission of the interaction request message is blocked if the acceptable threshold condition is exceeded
performing, …, a lookup on an alias directory to determine that the alias is not stored in the alias directory,
and querying a rules … to evaluate a message instantiation condition based on a result of the lookup, wherein downstream …of subsequent message traffic is suppressed if the lookup indicates the alias is stored, wherein the alias directory comprises … storing aliases mapped to real credentials and network addresses of corresponding sender institution …;
based on determining that the alias is not stored in the alias directory and that the message instantiation condition is met, generating a plurality of notifications comprising the sender identifier and…, by the … messaging …, the plurality of notifications to a plurality of sender institution ;
receiving, … a plurality of responses from the plurality of sender institution …, one or more responses indicating that the sender identifier is stored at the sender institution… and mapping the sender identifier to the one or more sender institution …, such that the interaction can proceed without the alias being available in the alias directory
providing, …the interaction details and/or additional interaction details to one or more of the sender institution … that store the sender identifier,
wherein one or more of the sender institution …initiate a real time transaction by transferring the amount of funds from one of the one or more sender institution computers to the receiver institution … after the real time messaging … provides the interaction details and/or additional interaction details to the one of the one or more sender institution ….”
These limitations clearly relate to managing interactions between a sender and a recipient. These limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity. Specific instances include instructing to “receiving… an interaction request message for an interaction” and “providing…the interaction details” recite managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. (Step 2A-Prong 1: YES. The claims recite an abstract idea).
This judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of:
[by a/the real time messaging computer] [computers]:
merely applying computer processing, storage, and networking technology as tools to perform an abstract idea
[transmission] [transmitting] :
insignificant extra-solution activity to the judicial exception of data gathering
[real-time] :
insignificant extra-solution activity to the judicial exception
are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer components and/or electronic processes. For example, the Applicant’s Specification reads:
[0024] server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server.
[0036] Receiver institution computer 104 may be a computing device associated with a receiver institution at which the receiver may have an account
[0038] A payment processing network may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™.
Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. Therefore, Claim 1 is directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, the additional elements, do not change the outcome of the analysis, when considered separately and as an ordered combination. The claim further defines the abstract idea and hence is abstract for the reasons presented above. The claim does not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
For causing the transmission, MPEP 2106.05(d)(II) indicates that the courts have recognized receiving or transmitting data over a network as well-understood, routine and conventional functions when claimed in a merely generic manner: Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
Therefore, the claim is directed to an abstract idea. Thus, the claim is not patent eligible. (Step 2B: NO. The claim does not provide significantly more)
Dependent Claims recite additional elements.
This judicial exception is not integrated into a practical application. In particular, the recited additional elements of
Claim 3:
“real time”: insignificant extra-solution activity to the judicial exception
Claim 4:
“computer”, “API”: merely applying computer processing, networking, and display technologies as a tool to perform an abstract idea
“real time”: insignificant extra-solution activity to the judicial exception
Claim 6: (none found: does not include additional elements and merely narrows the abstract idea)
Claim 9:
“computer”: merely applying computer processing and display technologies as a tool to perform an abstract idea
Claim 10:
“computer”: merely applying computer processing and display technologies as a tool to perform an abstract idea
“encrypted”: merely applying encryption technologies as a tool to perform an abstract idea
“real time”: insignificant extra-solution activity to the judicial exception
Claim 11: (none found: does not include additional elements and merely narrows the abstract idea)
Claim 13: (none found: does not include additional elements and merely narrows the abstract idea)
Claims 14 and 23:
“computer”: merely applying computer processing and display technologies as a tool to perform an abstract idea
“transmits”: insignificant extra-solution activity to the judicial exception
Claim 26:
“computer”, “graphical user interface (GUI) of a user device”: merely applying computer processing and display technologies as a tool to perform an abstract idea
“transmitted”: insignificant extra-solution activity to the judicial exception
are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer components and/or electronic processes. For example, the Applicant’s Specification reads:
[0024] server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server.
[0036] Receiver institution computer 104 may be a computing device associated with a receiver institution at which the receiver may have an account
[0038] A payment processing network may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™.
The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. Therefore, the claim is directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, these additional elements, do not change the outcome of the analysis, when considered separately and as an ordered combination. Dependent claims further define the abstract idea that is present in their respective independent claims and hence are abstract for the reasons presented above. The dependent claims do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
For causing the transmission, MPEP 2106.05(d)(II) indicates that the courts have recognized receiving or transmitting data over a network as well-understood, routine and conventional functions when claimed in a merely generic manner: Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
Therefore, the dependent claims are directed to an abstract idea. Thus, the dependent claims are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Independent Claim 15 is rejected on the same basis as Claim 1 with “a processor; and a non-transitory computer readable medium comprising code, executable by the processor” as an additional element.
Dependent Claims recite additional elements.
This judicial exception is not integrated into a practical application. In particular, the recited additional elements of
Claim 21:
“computer”: merely applying computer processing and display technologies as a tool to perform an abstract idea
Claim 24:
“computer”: merely applying computer processing and display technologies as a tool to perform an abstract idea
“transmits”: insignificant extra-solution activity to the judicial exception
are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer components and/or electronic processes. For support from the Applicant’s Specification, see the analysis as applied to Independent Claim 1 earlier. The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. Therefore, the claim is directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, these additional elements, do not change the outcome of the analysis, when considered separately and as an ordered combination. Dependent claims further define the abstract idea that is present in their respective independent claims and hence are abstract for the reasons presented above. The dependent claims do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
For causing the transmission, MPEP 2106.05(d)(II) indicates that the courts have recognized receiving or transmitting data over a network as well-understood, routine and conventional functions when claimed in a merely generic manner: Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
Therefore, the dependent claims are directed to an abstract idea. Thus, the dependent claims are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Independent Claim 16 is rejected on the same basis as Claim 1.
Dependent Claims recite additional elements.
This judicial exception is not integrated into a practical application. In particular, the recited additional elements of
Claim 19: (none found: does not include additional elements and merely narrows the abstract idea)
Claim 20:
“computer”, “device”: merely applying computer processing and display technologies as a tool to perform an abstract idea
“transmitting”: insignificant extra-solution activity to the judicial exception
Claim 22: (none found: does not include additional elements and merely narrows the abstract idea)
Claim 25:
“computer”: merely applying computer processing and display technologies as a tool to perform an abstract idea
“transmits”: insignificant extra-solution activity to the judicial exception
are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer components and/or electronic processes. For example, the Applicant’s Specification reads:
[0024] server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server.
[0036] Receiver institution computer 104 may be a computing device associated with a receiver institution at which the receiver may have an account
[0038] A payment processing network may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™.
The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. Therefore, the claim is directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, these additional elements, do not change the outcome of the analysis, when considered separately and as an ordered combination. Dependent claims further define the abstract idea that is present in their respective independent claims and hence are abstract for the reasons presented above. The dependent claims do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
For causing the transmission, MPEP 2106.05(d)(II) indicates that the courts have recognized receiving or transmitting data over a network as well-understood, routine and conventional functions when claimed in a merely generic manner: Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
Therefore, the dependent claims are directed to an abstract idea. Thus, the dependent claims are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-4, 9-11, 13-16, 19, 20, and 23-25 are rejected under 35 U.S.C. 103 as being unpatentable over Herz ("SECURE DATA INTERCHANGE", U.S. Publication Number: 20090254971 A1) in view of Vanhouten (“DIRECT EXTENDED REACH SYSTEM AND METHOD”, U.S. Publication Number: 20220172209 A1),in view of Tomimo (“COMMUNICATION DEVICE”, Japanese Publication Number: JP 2007148858 A),in view of Rabinovich (“EMAIL CONSUMER REPUTATION”, U.S. Publication Number: 20090259725 A1)
Regarding Claim 1,
Herz teaches,
receiving, by a real time messaging computer from a receiver institution computer,
(Herz [0027] a user might prefer to use a number of different pseudonyms ...A user might maintain a number of different aliases
Herz [0141] As with the SUBMIT command, first the SDI data warehouse checks that the alias exists, and challenges the agent that submits the CHANGE request
Herz [0133] We use “agent” to refer to the computer system that interacts with the central SDI data warehouse, submitting data and requesting payment from the eBank. Agents may represent individuals, vendors, or other self-interested parties.
Here the "real time messaging computer from a receiver institution computer" is the “agent” computer system of "vendors, or other self-interested parties.")
via a network interface using a secure communications protocol, an electronic message comprising an encrypted request payload, the electronic message comprising
(Herz [0053] Information can be submitted...built on top of a secure communications platform, for example via a SSL-encrypted TCP/IP session...within a particular network protocol
Herz [0041] XML messages are included in the body of standard HTTP Post/Response messages)
an interaction request message for an interaction comprising a sender identifier associated with a sender and interaction details comprising an amount for the interaction, wherein the sender identifier is an alias;
(Herz [0112] An agent can use a different public key for each alias that it maintains within SDI. The SDI identity code is a unique code, generated by SDI for each agent alias
Herz [0134] Data records can be submitted under multiple aliases by a single agent, to provide an additional level of control and flexibility in managing data submitted to SDI.
Herz [0158] on-line vendors to collect information about a single individual via “cookies” (identifying codes which are left on a user's client machine)
Herz [0027] Data owners can submit data to the central data warehouse with different degrees of identification, for example anonymously, pseudonymously...A user might maintain a number of different aliases within the database
Herz [0026] The pricing model allows a data owner to specify a price for different types and amounts of information access
Herz [0576] data any that vendor collects in the course of doing business (especially e-commerce); generally, it links customer codes to purchase items, dates, quantities, and prices )
determining, by the real time messaging computer, a data metrics score based on data in the interaction request message and evaluating whether the data metrics score satisfies an acceptable threshold condition, wherein further transmission of the interaction request message is blocked if the acceptable threshold condition is exceeded
(Herz [0695] communication may be either email, real-time text communications
Herz [0587] when a database describes its customers using a combination of numerical values, categories, and text, customer i can be represented by the vector Ci=(x1, . . . , xn, y1, . . . , ym, z1, . . . , zp).
Herz [0658] recommendations will take the form of a list of items with corresponding numbers that indicate the strength of each recommendation
Herz [0659] Because the result of this type of validation is a quantitative score, it is possible to automate the model selection process.
Herz [0737] the system is able to classify email... Based upon certain desirable confidence threshold settings, the system may automatically delete “span”
Herz [0657] The goal of validation, in this context, is to measure how successfully SDI makes a prediction, most commonly a recommendation...If several different combinations are under consideration, there is a need to gauge the relative predictive accuracy of one approach over another. This can be accomplished by holding out part of the data set)
performing, by the real time messaging computer, a lookup on an alias directory to determine that the alias is not stored in the alias directory,… wherein the alias directory comprises a database storing aliases mapped to real credentials …based on determining that the alias is not stored in the alias directory
(Herz [0139] SDI first checks the alias against its record of existing aliases. .... if the alias is not found, then a new SDI identity code is created.
Herz [0178] Second, the querying agent specifies whether it is required that the information be provided along with the identity of the owner of the information. Assume that the agent's identity is either revealed (with a real ... identity)
Herz [0546] The vendor then passes the letter X and the signed ID code to a trusted mailer....The physical address authority verifies that the trusted mailer is a valid service, and releases the real address of the user to the mailer.
Herz [0808] An application of SDI is that vendors can use the centrally stored information)
and network addresses of corresponding sender institution computers; ‘ (Herz [0524] An ISP level proxy server can contain the user profile generation module, profile processing module
Herz [0071] In another variation of SDI personalization is not performed at the client, but either at the ISP-level SDI proxy server or the vendor's server.
Herz [0539] A user can receive electronic mail through the PID and associated IP address of the ISP-level proxy server.)
that the message instantiation condition is met,
(Herz [0369] This rule is passed to the threshold testing module. This is where a decision is taken... If the rule provides sufficiently well personalized information then the processor instructs the control module to process the information with the rule)
to discover a routing path for the interaction without requiring prior enrollment of the alias in the alias directory;
(Herz [1144] allow the system to fully automate the activation of the recommended actions (or do so only if the confidence threshold is above a certain level). Or for example bypass user authorization of a recommended action if it falls within a certain margin of confidence
Herz [0067] messages can be routed through a common gateway or random "forwarders")
and mapping the sender identifier to the one or more sender institution computers,
(Herz [0542] Another variation, that relies on the user placing trust in the ISP-level proxy server, provides the ISP-level proxy with the e-mail address for each pseudonym.)
such that the interaction can proceed without the alias being available in the alias directory;
(Herz [0139] SDI first checks the alias against its record of existing aliases. .... if the alias is not found, then a new SDI identity code is created.
Herz [0803] As the trend to disintermediation continues (whereby we have informational middlemen, but not middlemen that physically hold products) we can allow vendors to notify portal intermediaries of product location within SDI,)
providing, by the real time messaging computer, the interaction details and/or additional interaction details to one or more of the sender institution computers that store the sender identifier
(Herz [0715] The central SDI data warehouse can be used by vendors that provide services of buyer infomediaries, for example providing buyers in B2C e-commerce applications with historical information about previous purchases of users.
Herz [0354] to support a personalized session with another agent ...To also support data mining by agents of a shared database, the client-side data records could useful push data
Herz [0365] A central application of SDI is a system where users submit profile information to the shared SDI data base, and receive personalized information and possible cash payments in return.)
wherein one or more of the sender institution computers initiate a real time transaction by transferring the amount of funds from one of the one or more sender institution computers to the receiver institution computer after the real time messaging computer provides the interaction details and/or additional interaction details to the one of the one or more sender institution computers.
(Herz [0043] The system allows for payments to be received by the providers of information
Herz [1113] the transfer of funds from the users account to the vendor's
Herz [0259] Given this information the agent can then decide whether to proceed with a query, and how much money to allocate.
Herz [0767] these electronic transfers of money and passed back through the interchange
Herz [0259] Given this information the agent can then decide whether to proceed with a query, and how much money to allocate.)
Herz does not teach querying a rules database to evaluate a message instantiation condition based on a result of the lookup, wherein downstream transmission of subsequent message traffic is suppressed if the lookup indicates the alias is stored; generating a plurality of notifications comprising the sender identifier and transmitting, by the real time messaging computer, the plurality of notifications to a plurality of sender institution computers; receiving, by the real time messaging computer, a plurality of responses from the plurality of sender institution computers, one or more responses indicating that the sender identifier is stored at the sender institution computers;
Herz alludes to a lookup on an alias directory to determine that the alias is not stored in the alias directory, … based on determining that the alias is not stored in the alias directory
Vanhouten more explicitly teaches,
a lookup on an alias directory to determine that the alias is not stored in the alias directory, … based on determining that the alias is not stored in the alias directory
(Vanhouten [0036] an account alias
Vanhouten [0039] A return notifications API
Vanhouten [Claim 4] wherein the received response comprises a code indicating a reason for a payout return including...an account not found; a bank could not be located using bank information provided;
...an identification number provided to identify the beneficiary does not match an owner of the account; missing sender data;
Vanhouten [page 5, Table 7] a validation failure (missing mandatory fields, etc.)
Vanhouten [0015] connects with application program interfaces (APIs) ...A database 120 that stores lookup information)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the real-time messaging of Herz to incorporate the API messaging teachings of Vanhouten for an “a second push API 116 associated with the PSP to populate a push message.” (Vanhouten [0019]). The modification would have been obvious, because it is merely applying a known technique (i.e. API messaging) to a known concept (i.e. real-time messaging) ready for improvement to yield predictable result (i.e. “push funds to card accounts may be expanded to include additional fields supporting transfers to non-card accounts via PSPs to provide the send payouts API” Vanhouten [0026])
Vanhouten does not teach querying a rules database to evaluate a message instantiation condition based on a result of the lookup, wherein downstream transmission of subsequent message traffic is suppressed if the lookup indicates the alias is stored; generating a plurality of notifications comprising the sender identifier and transmitting, by the real time messaging computer, the plurality of notifications to a plurality of sender institution computers; receiving, by the real time messaging computer, a plurality of responses from the plurality of sender institution computers, one or more responses indicating that the sender identifier is stored at the sender institution computers;
Tomimo teaches,
generating a plurality of notifications comprising the sender identifier and transmitting, by the real time messaging computer, the plurality of notifications to a plurality of sender institution computers;
(Tomimo [Abstract] notification message information for notifying other address information stored in an other address storage part of the change of its own address information is automatically created and transmitted. When the notification is not received by the destination but a reception error occurs (Yes at S72), another address information (alternate address information) of the owner of the address information (error address information) which has caused the reception error is automatically created (S75) and enquiry message information is automatically transmitted (S77) to other address information belonging to the same group as the error address information according to grouping information stored in the other address storage part.)
receiving, by the real time messaging computer, a plurality of responses from the plurality of sender institution computers, one or more responses indicating that the sender identifier is stored at the sender institution computers;
(Tomimo [Abstract] to other address information belonging to the same group as the error address information according to grouping information stored in the other address storage part. When the alternate address information is acquired as a reply to the enquiry message information, the notification message information is transmitted anew to the alternate address information.)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the real-time messaging of Herz to incorporate the missing alias notification teachings of Tomimo for an “notification message information for notifying other address information.” (Tomimo [Abstract]). The modification would have been obvious, because it is merely applying a known technique (i.e. missing alias notification) to a known concept (i.e. real-time messaging) ready for improvement to yield predictable result (i.e. “another address information … is automatically created (S75) and enquiry message information is automatically transmitted” Tomimo [Abstract])
Tomimo does not teach querying a rules database to evaluate a message instantiation condition based on a result of the lookup, wherein downstream transmission of subsequent message traffic is suppressed if the lookup indicates the alias is stored.
Rabinovich teaches,
querying a rules database to evaluate a message instantiation condition based on a result of the lookup, wherein downstream transmission of subsequent message traffic is suppressed if the lookup indicates the alias is stored.
(Rabinovich [0048] comprise storing data linking the alias email address and the email address consumer to a memory (e.g., a database).
Rabinovich [0053] receiving a block signal ...distinguishing entity identifying the alias email address. The restrictive action may include configuring an email filter associated with the alias email address, blocking an incoming signal associated with the alias email address, modifying a routing setting to block an incoming signal associated with the alias email address... the restrictive action may attempt to prevent future undesirable emails that identify the alias email address from arriving)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the real-time messaging of Herz to incorporate the data suppression teachings of Rabinovich for a “restrictive action.” (Rabinovich [0053]). The modification would have been obvious, because it is merely applying a known technique (i.e. data suppression) to a known concept (i.e. real-time messaging) ready for improvement to yield predictable result (i.e. “block an incoming signal” Rabinovich [0053])
Regarding Claim 3,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 1 as described earlier.
Herz does not teach wherein the real time transaction is an original credit transaction (OCT) transaction.
Vanhouten teaches,
wherein the real time transaction is an original credit transaction (OCT) transaction.
(Vanhouten [0026] The receive-side Original Credit Transaction (OCT) API that enables push funds to card accounts may be expanded)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the real-time messaging of Herz to incorporate the Original Credit Transaction teachings of Vanhouten for a “receive-side Original Credit Transaction (OCT) API.” (Vanhouten [0026]). The modification would have been obvious, because it is merely applying a known technique (i.e. Original Credit Transaction) to a known concept (i.e. real-time messaging) ready for improvement to yield predictable result (i.e. “push funds to card accounts may be expanded to include additional fields supporting transfers to non-card accounts via PSPs to provide the send payouts API” Vanhouten [0026])
Regarding Claim 4,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 1 as described earlier.
Herz does not teach wherein the receiver institution computer communicates with the real time messaging computer via a first application programming interface (API) and the plurality of sender institution computers communicate with the real time messaging computer via a second API.
Vanhouten teaches,
wherein the receiver institution computer communicates with the real time messaging computer via a first application programming interface (API) and the plurality of sender institution computers communicate with the real time messaging computer via a second API.
(Vanhouten [0005] A set of application program interfaces (APIs) allow non-card payment instructions to be generated and routed between endpoints over networks
Vanhouten [0010] various application program interfaces (APIs) of the extended reach payments system
Vanhouten [0015] the “originator” is the requestor/payor 104 (or the acquirer 118 if the same entity) that connects with application program interfaces (APIs) of the transaction processor
Vanhouten [0025] real-time transport protocol (RTP) networks)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the real-time messaging of Herz to incorporate the API teachings of Vanhouten for an “API.” (Vanhouten [0026]). The modification would have been obvious, because it is merely applying a known technique (i.e. API) to a known concept (i.e. real-time messaging) ready for improvement to yield predictable result (i.e. “push funds to card accounts may be expanded to include additional fields supporting transfers to non-card accounts via PSPs to provide the send payouts API” Vanhouten [0026])
Regarding Claim 9,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 1 as described earlier.
Herz teaches,
wherein the interaction request message is signed using a private key associated with the receiver institution computer.
(Herz [0076] The SDI system supplies a private key to trusted SDI client software, that enables only SDI-enabled clients to access profile information...A client can only access embedded information once enabled with a relevant key. Finally, profile ...information is signed with a digital certificate, to prevent third parties from tampering )
Regarding Claim 10,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 9 as described earlier.
Herz teaches,
wherein the interaction request message is encrypted using a public key of the real time messaging computer.
(Herz [0520] RSA encryption-decryption function. It is not necessary for all agents to use the same private/public keys.)
Regarding Claim 11,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 1 as described earlier.
Herz does not teach wherein the one or more responses is two or more responses.
Vanhouten teaches,
wherein the one or more responses is two or more responses.
(Vanhouten [0024] Return messages sent 3 to the transaction processor 106 and sent 4 to the PSP 108 may confirm the return transaction)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the real-time messaging of Herz to incorporate the API teachings of Vanhouten for an “API.” (Vanhouten [0026]). The modification would have been obvious, because it is merely applying a known technique (i.e. API) to a known concept (i.e. real-time messaging) ready for improvement to yield predictable result (i.e. “push funds to card accounts may be expanded to include additional fields supporting transfers to non-card accounts via PSPs to provide the send payouts API” Vanhouten [0026])
Regarding Claim 13,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 11 as described earlier.
Herz does not teach wherein the additional interaction details comprise a credential, the credential being an account identifier of the receiver.
Vanhouten teaches,
wherein the additional interaction details comprise the credential, a credential being an account identifier of the receiver.
(Vanhouten [Claim 18] wherein the request to transfer funds includes fields to communicate: a payment amount; a sending account; a recipient account;)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the real-time messaging of Herz to incorporate the account identifier teachings of Vanhouten for an “a sending account; a recipient account” (Vanhouten [Claim 18]). The modification would have been obvious, because it is merely applying a known technique (i.e. account identifiers) to a known concept (i.e. real-time messaging) ready for improvement to yield predictable result (i.e. “a tokenized bank identification number for use in routing the transfer through existing financial processing networks” Vanhouten [Abstract])
Regarding Claim 14,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 1 as described earlier.
Herz does not teach wherein the receiver institution computer transmits a notification message to a receiver device of a receiver indicating that the interaction has completed.
Vanhouten teaches,
wherein the receiver institution computer transmits a notification message to a receiver device of a receiver indicating that the interaction has completed.
(Vanhouten [Claim 14] wherein the response received from the payouts service provider comprises a response code indicating one or more of the following: approved and completed successfully)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the real-time messaging of Herz to incorporate the completion notification teachings of Vanhouten for a “a response code indicating … completed successfully.” (Vanhouten [Claim 14]). The modification would have been obvious, because it is merely applying a known technique (i.e. completion notification ) to a known concept (i.e. real-time messaging) ready for improvement to yield predictable result (i.e. “If the policy evaluation indicates a successful result, then the transaction has satisfied the compliance policy … and transmitted to the consensus system for inclusion on the ledger” Vanhouten [0274])
Claim 15 is rejected on the same basis as Claim 1.
Claim 16 is rejected on the same basis as Claim 1.
Regarding Claim 19,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 16 as described earlier.
Herz teaches,
wherein the alias is a username, phone number, or e-mail address.
(Herz [0357] user's log-in user name and password can be derived from a user's pseudonymous identity, and computed within a cryptographic framework.)
Regarding Claim 20,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 16 as described earlier.
Herz teaches,
transmitting, by the receiver institution computer, a notification message to the receiver device.
(Herz [0072] information in transit between servers and clients can be assured through standard end-to-end cryptographic solutions
Herz [0139] Once validated, the SDI identity code is returned to the agent
Herz [0141] If everything checks out, then SDI returns TRUE)
Regarding Claim 23,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 1 as described earlier.
Herz teaches,
wherein the real time messaging computer transmits …in a prioritized order based on prior sender financial institution behaviors.
(Herz [0088] whether the identity of the owner of the information is revealed to the requesting agent.
Herz [1390] A simple but useful application of LEIA involves on an opt-in basis real time transmission of a sample of driver's location information to a regional traffic-reporting bureau
Herz [0012] When analyzed with the proper statistical tools these data sets can reveal fundamental patterns in the behavior of users, and enable a vendor to provide appropriate information to a user.
Herz [0339] single employee has sent out a signal indicating the need for a meeting and its priority (standard or emergency)...an emergency meeting would be given priority status
Herz [0747] classify users as “experts” that receive priority in the position of their current and future comments
Herz [0081] eBank module in SDI collects payments, and allows those payments to be transferred to external bank accounts, or used in part payment for products and services to SDI-enabled vendors)
Herz does not teach the plurality of notifications to the plurality of sender institution computers.
Tomimo teaches,
the plurality of notifications to the plurality of sender institution computers
(Tomimo [Abstract] notification message information for notifying other address information stored in an other address storage part of the change of its own address information is automatically created and transmitted. When the notification is not received by the destination but a reception error occurs (Yes at S72), another address information (alternate address information) of the owner of the address information (error address information) which has caused the reception error is automatically created (S75) and enquiry message information is automatically transmitted (S77) to other address information belonging to the same group as the error address information according to grouping information stored in the other address storage part.)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the real-time messaging of Herz to incorporate the missing alias notification teachings of Tomimo for an “notification message information for notifying other address information.” (Tomimo [Abstract]). The modification would have been obvious, because it is merely applying a known technique (i.e. missing alias notification) to a known concept (i.e. real-time messaging) ready for improvement to yield predictable result (i.e. “another address information … is automatically created (S75) and enquiry message information is automatically transmitted” Tomimo [Abstract])
Claim 24 is rejected on the same basis as Claim 23.
Claim 25 is rejected on the same basis as Claim 23.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable overHerz, Vanhouten, Tomimo, and Rabinovich in view of Jakobsson ("DETECTION OF BUSINESS EMAIL COMPROMISE", U.S. Publication Number: 20170230323 A1).
Regarding Claim 6,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 1 as described earlier.
Herz does not teach wherein the data metrics score comprises a fraud score calculated based on a fraud analysis using data in the interaction request message, and wherein blocking further transmission of the interaction request message comprises declining the interaction request message if the fraud score satisfies the acceptable threshold condition.
Jakobsson teaches,
wherein the data metrics score comprises a fraud score calculated based on a fraud analysis using data in the interaction request message, and wherein blocking further transmission of the interaction request message comprises declining the interaction request message if the fraud score satisfies the acceptable threshold condition.
(Jakobsson [0060] a policy operating on the identified type of threat and the risk score of the email.
Jakobsson [0036] if any filter outputs a “higher” detection score, that means that it is more likely that the email will be blocked, as individual scores from different detection components are combined in a way in which each score contributes toward reaching a threshold
Jakobsson [0062] on analysis of trust
Jakobsson [0064] detected by analyzing trust relationships and determining whether the sender names are deceptive
Jakobsson [0261] where traffic from the sender of the scanned email would simply be blacklisted, and all email from this sender rejected onwards)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the real-time messaging of Herz to incorporate the fraud scoring teachings of Jakobsson to “risk score of the email.” (Jakobsson [0060]). The modification would have been obvious, because it is merely applying a known technique (i.e. fraud scoring) to a known concept (i.e. real-time messaging) ready for improvement to yield predictable result (i.e. “email will be blocked, as individual scores from different detection components are combined” Jakobsson [0036])
Claims 21, 22, and 26 are rejected under 35 U.S.C. 103 as being unpatentable overHerz, Vanhouten, Tomimo, and Rabinovich in view of Katzin ("MERCHANT-CONSUMER BRIDGING PLATFORM APPARATUSES, METHODS AND SYSTEMS", U.S. Publication Number: US 20120303425 A1).
Regarding Claim 21,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 15 as described earlier.
Herz does not teach wherein the real time transaction is an original credit transaction (OCT) transaction.
Katzin teaches,
wherein the real time transaction is an original credit transaction (OCT) transaction.
(Katzin [0137] the processing request message 326 may take a form similar to the Visa Single Message System (SMS) format, Visa Original Credit Transaction (OCT) format, and/or the like.
Katzin [0160] In further implementations, interacting with the wallet in real time)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the real-time messaging of Herz to incorporate the transaction formatting of Katzin for “a variety of consumer merchant checkout formats.” (Katzin [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. transaction formatting) to a known concept (i.e. real-time messaging) ready for improvement to yield predictable result (i.e. “may further facilitate data collection such as, but not limited to web claws, merchant statistics, dollar ranges of merchant products, card history, and/or the like” Katzin [0125])
Claim 22 is rejected on the same basis as Claim 21.
Regarding Claim 26,
Herz, Vanhouten, Tomimo, and Rabinovich teach the real-time messaging of Claim 1 as described earlier.
Herz does not teach causing display, in a graphical user interface (GUI) of a user device, a list of contacts, wherein a user of the user device selects a contact from the list; and causing display, in the GUI, of interface elements to configure request details, wherein the user enters the request details, thereby causing the interaction request message to be generated and transmitted to the receiver institution computer.
Katzin teaches,
causing display, in a graphical user interface (GUI) of a user device, a list of contacts, wherein a user of the user device selects a contact from the list; and causing display, in the GUI, of interface elements to configure request details, wherein the user enters the request details, thereby causing the interaction request message to be generated and transmitted to the receiver institution computer.
(Katzin [0394] a graphical user interface (“GUI”) element
Katzin [0364] a user may select the address book option 3917 to view the address book 3917a which includes a list of contacts 3917b and make any money transfers or payments. ...the address book may identify each contact using their names and available and/or preferred modes of payment. For example, a contact Amanda G. may be paid
Katzin [0229] MCB-Platform may populate an automatic message on the consumer's social media profile
Katzin [0351] may populate a data/command object
Katzin [0247] may generate a transfer request
Katzin [0084] may be associated with an electronic wallet 203, which may comprise one or more of a bank account)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the real-time messaging of Herz to incorporate the list of contacts of Katzin to “select the address book.” (Katzin [0364]). The modification would have been obvious, because it is merely applying a known technique (i.e. list of contacts) to a known concept (i.e. real-time messaging) ready for improvement to yield predictable result (i.e. “e address book may identify each contact using their names and available and/or preferred modes of payment.” Katzin [0364])
Response to Remarks
Applicant's arguments filed on July 6, 2026, have been fully considered and Examiner’s remarks to Applicant’s amendments follow.
Response Remarks on Claim Rejections - 35 USC § 101
The Applicant states:
“Here, the claims recite specific technical operations for filtering, blocking, suppressing, and routing electronic payloads across network interfaces via a secure communications protocol. These steps are inherently computer-rooted and cannot be executed by human activity or mental processes. Humans cannot receive encrypted payloads over a network interface, calculate automated system "data metrics scores" to block transmission, or query a rules database to dynamically suppress downstream electronic message traffic."
Examiner responds:
The Examiner never rejected the claims under Mental Processing. So, the argument is moot.
The claims at issue do not require any nonconventional computer, network, or display components, or even a “non-conventional and non-generic arrangement of known, conventional pieces,” but merely call for performance of the claimed information collection, analysis, and display functions on a set of generic computer components and display devices.
Nothing in the claims, understood in light of the specification, requires anything other than “merely applying” off-the-shelf, conventional computer, network, and display technology for gathering, synthesizing, sending, and presenting the desired information.
For example, the Applicant’s Specification reads:
[0024] server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server.
[0038] A payment processing network may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™.
The additional elements amount to no more than "merely applying " instructions to implement an abstract idea on a computer. Using a generic computer to implement an abstract idea does not integrate that abstract idea into a practical application. The claims invoke computers or other machinery merely as a tool to perform an existing process or to automate a manual or mental process. See MPEP 2106.05(f)(2) - Mere Instructions To Apply An Exception: Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).
The Applicant states:
“Prior systems suffer from architectural shortcomings: "For example, if an alias is not in the alias directory, then the request for interaction is declined. . . . This can . .. result in the use of additional computing resources. Additionally, registration of aliases can be cumbersome and also results in the use of additional computing resources." (Specification [0003]).
The claimed techniques solve these resource-drain and transmission-decline problems by implementing a distinct multi-gated, ad-hoc routing recovery architecture.
The conditional data-gating steps recited in Claim 1 directly mirror the patent-eligible."
Examiner responds:
The act of “data-gating” amounts to gathering, sharing, and manipulation of data which expresses an Abstract Idea [Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017) “collecting, displaying, and manipulating data” was considered part of the abstract idea], and Selecting A Particular Data Source or Type Of Data To Be Manipulated [Selecting information, based on types of information and availability of information in a power-grid environment, for collection, analysis and display, Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354-55, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016)]
One abstract idea cannot integrate another abstract idea into a practical application.
The focus of the claims is not on an improvement in computers as tools, but on certain independently abstract ideas that use computers as tools.
Nothing in the claims, understood in light of the specification, requires anything other than “merely applying” off-the-shelf, conventional computer, network, and display technology for gathering, synthesizing, sending, and presenting the desired information. See MPEP 2106.05(d) well-understood, routine, and conventional.
The Applicant states:
“The conditional data-gating steps recited in Claim 1 directly mirror the patent-eligible
framework established in USPTO Subject Matter Eligibility Guidance Example 40."
Examiner responds:
Example 40 states technical limitations of collecting network delay, packet loss, network traffic jitter, protocol data relating to the network, and packet loss. That claimed invention provides a specific improvement over prior systems, resulting in improved network monitoring and its technical ramifications are far reaching across all industries. Whereas, the Applicant’s does not contain similar technical elements.
The Applicant states:
“This technological paradigm is consistent with other landmark Federal Circuit decisions. In Enfish, LLC v. Microsoft Corp., the Court found data structures designed to improve memory
retrieval eligible because they were "directed to a specific implementation of a solution to a problem in the software arts." (822 F.3d 1327, 1339 (Fed. Cir. 2016)).
Examiner responds:
In Enfish, LLC v. Microsoft Corp., 822 F. 3d 1327, 1330 (Fed. Cir, 2016)….the court explained that "the claims are directed to an improvement of an existing technology is bolstered by the specification's teachings that the claimed invention achieves other benefits over conventional databases, such as increased flexibility, faster search times, and smaller memory requirements…. the self-referential table recited in (that case) …. is a specific type of data structure designed to improve the way a computer stores and retrieves data in memory. The specification's disparagement of conventional data structures, combined with language describing the ‘present invention’ as including the features that make up a self-referential table, confirm that our characterization of the ‘invention’ for purposes of the § 101… the claims are directed to a specific implementation of a solution to a problem in the software arts. Accordingly, we find the claims at issue are not directed to an abstract idea"
The Applicant’s present invention may plausibly solve a business problem; but does not solve a technology problem. The functioning of the computer itself is not improved. The computer only performs transmitting of data over network, receiving/processing/storing data, and performing calculation (manipulating data based on model/algorithm). Covered by MPEP 2106.5(d).
The Applicant states:
“Even Were the Claims Directed to an Abstract Idea, They Would Include "Significantly More" … the claims recite inventive concepts, providing significantly more than any alleged abstract idea."
Examiner responds:
The Examiner asserts the focus of the claims is not on an improvement in computers as tools, but on certain independently abstract ideas that use computers as tools. All technological components (additional elements) are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer components and/or electronic processes. For example, the Applicant’s Specification reads:
[0022] A “user device” may be any suitable device that a user can interact with (e.g., a payment card or mobile phone). User devices may be in any suitable form. Some examples of user devices include …cellular phones, PDAs, personal computers (PCs), tablet computers, and the like. In some embodiments, where a user device is a mobile device, the mobile device may include a display, a memory, a processor, a computer-readable medium, and any other suitable component.
[0038] A payment processing network may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™.
[0024] A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit.
Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. Therefore, the claims are directed to an abstract idea without a practical application.
Response Remarks on Claim Rejections - 35 USC § 103
Applicant's amendments required the application of new/additional prior art.
New prior art includes:
Rabinovich (“EMAIL CONSUMER REPUTATION”, U.S. Publication Number: 20090259725 A1)
Excised prior art includes:
Azgad-Tromer (US-20240104521-A1)
Applicant’s remarks regarding the rejection made under 35 USC § 103 are rendered moot by the introduction of additional prior art.
Therefore, the rejection under 35 USC § 103 remains.
Prior Art Cited But Not Applied
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Modi (“MONEY TRANSFER SERVICE WITH AUTHENTICATION”, U.S. Publication Number: 20060006224 A1) proposes an online money transfer service (or "portal"). A sender logs into the portal and enters payment card and money transfer details and then submits the transaction. An authentication window appears displaying the sender's transaction details and the sender is prompted to enter his or her password. Upon successful authentication, the bank seeks authorization from the card issuer. Upon successful authorization, the bank credits the recipient's local bank account or existing payment card. The recipient can also receive a check, a draft, a prepaid card or cash. The money transfer service is used both cross-border and domestic to effect person-to-person money transfer. The money transfer service uses the "Verified by Visa" authentication service and VisaNet for authorization. Messages over VisaNet are used to deliver funds to a recipient.
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 CHINEDU EKECHUKWU whose telephone number is (571)272-4493. The examiner can normally be reached on Mon-Fri 9 AM ET to 3:30 PM ET.
Examiner interviews are available via telephone 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, Christine Tran, can be reached on (571) 272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov.
Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.E./Examiner, Art Unit 3695 /CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights