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 .
Status of Claims
• This action is in reply to the amendments filed on May 1, 2026
• Claims 1, 3, 7, 11-15, and 19 have been amended and are hereby entered.
• Claims 21-22 have been added.
• Claims 9-10 have been canceled.
• Claims 1-8 and 11-22 are currently pending and have been examined.
• This action is made FINAL.
Response to Arguments
Applicant’s arguments filed May 1, 2026 have been fully considered but they are not persuasive.
The Examiner is withdrawing the claim objections due to Applicant’s amendments.
New claim objections have been entered due to applicant’s amendments.
New 35 USC § 112 rejections have been entered due to applicant’s amendments.
Applicant’s arguments with respect to 35 USC § 101 have been fully considered and are not persuasive.
Regarding Applicant’s argument on pages 8-9, that the claims are directed to a technical solution, the Examiner respectfully disagrees. The pending claims do not describe a technical solution to a technical problem. The pending claims are directed to improving transaction processing by using a partial authorization scheme when a transaction amount exceeds a threshold such as an account balance or credit limit (see at least [0002] of the Specification). The claims of the instant application describe an improvement to a business process i.e., improving transaction processing by using a partial authorization scheme when a transaction amount exceeds a threshold such as an account balance or credit limit, not improvement in the functioning of the computer itself or an improvement to any other technology or technological field.
Regarding Applicant’s arguments on pages 9-10, that the claims integrate a practical application, the Examiner respectfully disagrees. Under the Patent Subject Matter Eligibility analysis, Step 2A, prong two, integration into a practical application requires an additional element(s) or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Limitations that are not indicative of integration into a practical application are those that generally link the use of the judicial exception into a particular technological environment or field of use-see MPEP 2106.05(h). Here the additional elements of claim 1 and 12 include: a receiver entity computer comprising: a processor; and a non-transitory computer readable medium comprising code executable by the processor, for performing operations; a network processing computer; and push messages. The additional elements of claim 15 include: a network processing computer; a sender entity computer; push messages; and a receiver entity computer. The additional elements are such that they amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network) (see MPEP 2106.05(h)).
Furthermore, and in response to Applicant’s arguments on page 9 regarding specific technical inefficiencies, in determining whether a claim integrates a judicial exception into a practical application, a determination is made of whether the claimed invention pertains to an improvement in the functioning of the computer itself or any other technology or technical field (i.e., a technological solution to a technological problem). Here, the claims recite generic computer components, i.e., a generic processor, a memory storing a computer program executable by the processor to perform the claimed method steps and system functions. The processor, memory and system are recited at a high level of generality and are recited as performing generic computer functions customarily used in computer applications.
Applicant further argues, on pages 9-10, that the claims allow a sender to send a value to a receiver with a minimal number of message steps, which saves computing resources and data processing steps. The argument has been considered and is not persuasive. In response to this argument, the Examiner notes “‘claiming the improved speed or efficiency inherent with applying the abstract idea on a computer’ [is] insufficient to render the claims patent eligible as an improvement to computer functionality.” Customedia, 951 F.3d at 1364 (quoting Intell. Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 1370 (Fed. Cir. 2015)); see also BSG Tech LLC v. BuySeasons, Inc., 899 F.3d 1281, 1288 (Fed. Cir. 2018) (“These benefits, however, are not improvements to database functionality. Instead, they are benefits that flow from performing an abstract idea in conjunction with a well-known database structure.”). The specification offers no explanation of how or why the claimed invention saves computing resources and data processing step, only an unexplained and unsupported conclusion on the subject.
The claims are not patent eligible.
Applicant’s arguments with respect to 35 USC § 103 have been fully considered and are not persuasive.
Regarding Applicant’s arguments on page 10, that the cited art of record does not teach “receiving, by the receiver entity computer from the network processing computer, a second push transfer message comprising the credit balance of the credit account or another value less than the credit balance of the credit account,” and “immediately crediting, by the receiver entity computer, the credit account in the amount of the record value or the another value less than the record value, thereby reducing the credit balance of the credit account,” the arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Regarding Applicant’s argument on pages 10-11 regarding push and pull transactions, the argument has been considered and is not persuasive. In response to the argument, the Examiner notes that the features upon which applicant relies (i.e., push and pull transactions) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Furthermore regarding this argument, Examiner respectfully contends that Venkat’s disclosure pertaining to debiting transactions does not wholly disqualify all possible combinations with references disclosing the claimed payment protocols. Under the broadest reasonable interpretations of the claims, e.g. payment protocols could be added or modified for different reasons without rendering the payment protocol method presented by Venkat inoperable. It is noted that "[t]he use of patents as references is not limited to what the patentees describe as their own inventions or to the problems with which they are concerned. They are part of the literature of the art, relevant for all they contain.” In re Heck, 699 F.2d 1331, 1332-33, 216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275, 277 (CCPA 1968))." MPEP §2123.
Furthermore, and in response to Applicant’s arguments on pages 10-11 where Applicant argues that there is no motivation to combine the references, the Examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, from the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify Venkat in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
For the reasons above, Applicant’s arguments are not persuasive.
Claim Objections
Claims 1, 12, and 15 are objected to because of the following informalities:
Claim 1 recites “the receiving entity computer.” For clarity and consistency, the Examiner recommends amending the claim to be consistent with the previously introduced “receiver entity computer” (emphasis added).
Claims 12 and 15 have similar limitations found in claim 1 above, and therefore is objected to under the same rationale.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-8 and 11-22 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, the term “immediately” is a relative term which renders the claim indefinite. The term “immediately” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The amount of time between the step of receiving and crediting is rendered indefinite by the term “immediately crediting.” For examination purposes, the Examiner is interpreting the claim limitation of “immediately crediting” as “crediting.”
Claims 12 and 15 have similar limitations found in claim 1 above, and therefore are rejected by the same rationale.
The rest of the dependent claims are rejected due to their dependency to a rejected claim.
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-8 and 11-22 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. Independent claims 1, 12, and 15 are directed to a method (claims 1 and 15), and an apparatus (claim 12). Therefore, on its face, each independent claim 1, 12, and 15 are directed to a statutory category of invention under Step 1 of the Patent Subject Matter Eligibility analysis (see MPEP 2106.03).
Under Step 2A, Prong One of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), claims 1, 12, and 15 recite, in part, a system, a method, and an apparatus of organizing human activity. Claim 1 recites a method comprising: receiving, by a receiver entity, a first transfer message comprising a credential and a value; determining, by the receiver entity, that the value exceeds a credit balance of a credit amount of a receiver, a credit account managed by the receiver entity computer and the credit balance being an amount owed to an issuing bank operating the receiving entity; transmitting, by the receiver entity, a first response message comprising the credit balance of the credit account, and an indicator declining the first transfer message; receiving, by the receiver entity, a second transfer message comprising the credit balance of the credit account or another value less than the credit balance of the credit account; immediately crediting, by the receiver entity, the credit account in the amount of the credit balance of the credit account or the another value less than the credit balance of the credit account, thereby reducing the credit balance of the credit account; and transmitting, by the receiver entity, a second response message comprising an approval indicator.
Claim 12 recites similar limitations as claim 1 above.
Claim 15 recites a method comprising: receiving, from a sender entity, a first transfer message comprising a value; transmitting, the first transfer message to a receiver entity, wherein the receiver entity determines that the value exceeds a credit balance of a credit amount of a receiver, a credit amount managed by the receiver entity computer and the credit balance being an amount owed to an issuing bank operating the receiving entity, and transmits, a first response message comprising the credit balance of a credit account, and an indicator declining the first transfer message; receiving, the first response message; transmitting, the first response message to the sender entity; receiving, a second transfer message comprising the credit balance of the credit account or another value less than the credit balance of the credit account; receiving, a second response message comprising an approval indicator; immediately crediting, by the receiver entity, the credit account in the amount of the credit balance of the credit account or the another value less than the credit balance of the credit account, thereby reducing the credit balance of the credit account; and transmitting, the second response message comprising the approval indicator to the sender entity.
The limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers fundamental economic principles or practices and commercial and legal interactions (certain methods of organizing human activity), but for the recitation of generic computer components. The claims as a whole recite a method of organizing human activity. The claimed inventions allows for transaction processing using a partial authorization scheme when a transaction amount exceeds a threshold such as an account balance or credit limit (see Specification at [0030]), which is a commercial and legal interaction including sales activities or behaviors. The mere nominal recitation of a computer comprising a processor; and a non-transitory computer readable medium comprising code executable by the processor, for performing operations do not take the claim out of the methods of organizing human activity grouping. Thus, the claims recite an abstract idea.
Under Step 2A, Prong Two of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), the judicial exception is not integrated into a practical application. In particular, the additional elements of claim 1 and 12 include: a receiver entity computer comprising: a processor; and a non-transitory computer readable medium comprising code executable by the processor, for performing operations; a network processing computer; and push messages. The additional elements of claim 15 include: a network processing computer; a sender entity computer; push messages; and a receiver entity computer. The additional elements are recited at a high-level of generality (i.e., as a generic computer components performing generic computer functions receiving a transfer message, determining a value exceeds a threshold, transmitting a response message, receiving a second transfer message, transmitting an approval) such that it amounts to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network).-see MPEP 2106.05(h).
Accordingly, the combination of the 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. The claims are directed to an abstract idea.
Under Step 2B of the Patent Subject Matter Eligibility analysis (see MPEP 2106.05), the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the claims amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)). Generally linking the use of the judicial exception to a particular technological environment or field of use using generic computer components cannot provide an inventive concept.
The claims are not patent eligible.
The dependent claims have been given the full two part analysis including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. Dependent claims 3-4, 6-8, 11, 13-14, and 16-22 simply help to define the abstract idea Dependent claims 2, 5, simply further describes the technological environment. Dependent claim 2 recites the additional element of a sender entity computer, which merely further describes an additional computer of the generally linked computer network. Dependent claim 5 recites the additional element of communication via an API, which merely further describes the communication protocol of the computers in the generally linked computer network. The additional limitations of the dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
Viewing the claim limitations as an ordered combination does not add anything further than looking at the claim limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea. Accordingly, claims 1-8 and 11-22 are ineligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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-8 and 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20200027087 A1 (“Venkatasubramanian”) in view of WO 2022061182 A1 (“Kozlov”), and in further view of US 20210042780 A1 (“Suresh”).
Regarding claim 1, Venkatasubramanian discloses a method comprising (see at FIG. 3.):
receiving, by a receiver entity computer from a network processing computer, a first transfer message comprising a value (The First authorization message sent from the Payment Network server to the Issuer Server. See at least [0065] and FIG. 3, step 310. The first authorization message comprises the transaction amount, see at least [0064]. The Examiner is interpreting the issuer server as the receiving entity computer. And, the Examiner is interpreting the Payment Network server as the network processing computer.);
determining, by the receiver entity computer, that the value exceeds a credit balance of a credit amount of a receiver (The issuer determines the account balance or available credit line does not cover the transaction amount. See at least [0066] and see also FIG. 3, step 312.),
a credit account managed by the receiver entity computer (A user performs a transaction for a transaction amount from their bank account that is maintained with an issuer bank. See at least [0029]. Issuer Server, see at least [0065].),
and the credit balance being an amount owed to an issuing bank operating the receiving entity computer (The issuer determines the account balance or available credit line does not cover the transaction amount. See at least [0066]. The Examiner interprets a payment amount that is to be paid via a credit line as an amount owed to an issuer bank.);
transmitting, by the receiver entity computer to the network processing computer, a first response message comprising the credit balance of the credit account, and an indicator declining the first transfer message (The issuer transmits a transaction decline notification to the payment network server, the notification indicates the transaction has been declined. The transaction decline notification includes a third data element that indicates the account balance or the available credit line of the user account. See at least [0066] and FIG. 3, step 312. Issuer server manages accounts of users and stores account details including account balance. See at least [0049].);
receiving, by the receiver entity computer from the network processing computer, a second transfer message (The payment network server modifies the first authorization request into the second authorization request by modifying the data element of the authorization request by replacing the transaction amount that exceeded the threshold with a transaction amount of the account balance indicated in the decline notification. The payment network server transmits this second authorization message to the issuer computer, see at least [0071]-[0072] and FIG. 3, step 320.); and
transmitting, by the receiver entity computer to the network processing computer, a second response message comprising an approval indicator (The issuer server transmits, to the payment network server, a transaction approval notification indicating the transaction is approved. See at least [0072] and FIG. 3, step 322.).
While Venkatasubramanian discloses a transfer message, Venkatasubramanian does not expressly disclose the message is a push message. Furthermore, while Venkatasubramanian discloses a message, Venkatasubramanian does not expressly disclose a message comprising a credential. Furthermore, while Venkatasubramanian discloses a second transfer message, Venkatasubramanian does not expressly disclose the second transfer message comprising the credit balance of the credit account or another value less than the credit balance of the credit account. Nor does Venkatasubramanian expressly disclose immediately crediting, by the receiver entity computer, the credit account in the amount of the credit balance of the credit account or the another value less than the credit balance of the credit account, thereby reducing the credit balance of the credit account.
However, Kozlov discloses the message is a push message (push transaction messages, see at least [0029], see also [0039] and [0060].);
a message comprising a credential (Transmitting a message including a credential, see at least [0039]. See also [0047].).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the message of Venkatasubramanian to be a push message, as taught by Kozlov, and to modify the message of Venkatasubramanian to include a credential, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
While Venkatasubramanian discloses a second transfer message, Venkatasubramanian does not expressly disclose the message comprising the credit balance of the credit account or another value less than the credit balance of the credit account. Nor does Venkatasubramanian expressly disclose immediately crediting, by the receiver entity computer, the credit account in the amount of the credit balance of the credit account or the another value less than the credit balance of the credit account, thereby reducing the credit balance of the credit account.
However, Suresh discloses the message comprising the credit balance of the credit account or another value less than the credit balance of the credit account (Portable computing device can then send a notification to wallet credit service indicating that the user would like to make a payment of a specified amount to pay down a credit card balance. See at least [0059]. See also [0063].);
immediately crediting, by the receiver entity computer, the credit account in the amount of the credit balance of the credit account or the another value less than the credit balance of the credit account, thereby reducing the credit balance of the credit account (Then wallet cash service can send a notification instructing cash payment service to transfer cash from the account associated with the user to an account associated with credit card. Notification can include information that identifies the user, that identifies the business entity associated with the credit card that will receive the funds, the transaction reference ID, the amount of the transaction, and a digital signature of wallet cash service. Upon receiving notification, cash payment service can verify the signature of wallet cash service in notification, can verify that there are enough funds in the user's account to cover the transaction, can transfer money from the user account to the business entity account associated with the credit card, and update account balances for both the user and the business entity. Cash payment service can send a notification informing wallet cash service of the successful transfer of funds. See at least [0065]-[0067].).
From the teaching of Suresh, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the message of Venkatasubramanian to comprise a value less than the credit value of the credit account, as taught by Suresh, and to modify the receiver entity computer of Venkatasubramanian to immediately credit the credit account in the another value less than the credit balance of the credit account, thereby reducing the credit balance of the credit account, as taught by Suresh, in order to improve credit card customer experience (see Suresh at least at [0015]-[0021]).
Regarding claim 2, the combination of Venkatasubramanian, Kozlov, and Suresh discloses the limitations of claim 1, as discussed above, and Venkatasubramanian further discloses before the receiver entity computer receives the first transfer message from the network processing computer, the network processing computer receives the first transfer message from a sender entity computer (The acquirer server routes the first authorization request to the payment network server. See at least [0091] and FIG. 5, step 508.),
which receives an origination message from a sender user device associated with a sender (To perform the online transaction for purchasing the product, the user inputs the transaction card details of the transaction card through an interface (such as an online payment gateway) presented on the user device. The online payment gateway is a gateway to the acquirer server that encrypts the transaction details of the transaction for communicating to the acquirer server. The acquirer server receives the encrypted transaction details. The encrypted transaction details include the transaction card details, the transaction amount, the merchant identification code of the merchant, a timestamp of the transaction, a transaction ID of the transaction, the authentication password, or the like. See at least [0090] and FIG. 5, step 502-506.).
While Venkatasubramanian discloses a transfer message, Venkatasubramanian does not expressly disclose the message is a push message.
However, Kozlov discloses the message is a push message (push transaction messages, see at least [0029], see also [0039] and [0060].).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the message of Venkatasubramanian to be a push message, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
Regarding claim 3, the combination of Venkatasubramanian, Kozlov, and Suresh discloses the limitations of claim 2, as discussed above, and Venkatasubramanian further discloses the credit account is associated with a receiver (The issuer determines the account balance or available credit line does not cover the transaction amount. See at least [0066]. The first amount is a nominal value defined by the authorization manager such that the user account has enough funds to cover the first amount. In one example, the first amount is the account balance or the available credit line of the user account. See at least [0058]. Account refers to a financial account that is used to fund transactions. Examples of the account include, but are not limited to….a credit account… See at least [0033].).
Regarding claim 4, the combination of Venkatasubramanian, Kozlov, and Suresh disclose the limitations of claim 1, as discussed above, and Venkatasubramanian further discloses transmit the first transfer message to the receiver entity computer (The issuer transmits a transaction decline notification to the payment network server, the notification indicates the transaction has been declined. The transaction decline notification includes a third data element that indicates the account balance or the available credit line of the user account. See at least [0066] and FIG. 3, step 312.).
Venkatasubramanian does not expressly disclose the network processing computer is programmed to analyze the credential, determine an address of the receiver entity computer using a portion of the credential. Furthermore, while Venkatasubramanian discloses transfer messages, Venkatasubramanian does not expressly disclose the message is a push message.
However, Kozlov discloses the network processing computer is programmed to analyze the credential, determine an address of the receiver entity computer using a portion of the credential (The sender device can generate and send an interaction request such as a payment request to the first transfer server computer. The interaction request may include data including an amount and an alias of the receiver. After the directory server computer receives the alias resolve request message comprising at least the alias of the receiver, the directory server computer can look up the addresses (e.g., server addresses) of the various mapping computers associated with the alias of the receiver. See at least [0047]-[0049].);
the message is a push message (push transaction messages, see at least [0029], see also [0039] and [0060].).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify Venkatasubramanian to the network processing computer is programmed to analyze the credential, determine an address of the receiver entity computer using a portion of the credential, as taught by Kozlov, and to modify the transfer message of Venkatasubramanian to be a push message, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
Regarding claim 5, the combination of Venkatasubramanian, Kozlov, and Suresh disclose the limitations of claim 4, as discussed above, and Venkatasubramanian further discloses the network processing computer and the sender entity computer communicate via an interface (communication via network interface, see at least [0038]-[0040] and [0107].).
While Venkatasubramanian discloses an interface, Venkatasubramanian does not expressly disclose an API (application programming interface).
However, Kozlov discloses API (application programming interface) (see at least [0071-[0076]. See also [0052]).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the interface of Venkatasubramanian to be an API, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
Regarding claim 6, the combination of Venkatasubramanian, Kozlov, and Suresh disclose the limitations of claim 4, as discussed above, and Venkatasubramanian further discloses the network processing computer receives the first transfer message from the sender entity computer (The acquirer server routes the first authorization request to the payment network server. See at least [0091] and FIG. 5, step 508.).
While Venkatasubramanian discloses a transfer message, Venkatasubramanian does not expressly disclose a push message. Furthermore, while Venkatasubramanian discloses a message, Venkatasubramanian does not expressly disclose a message comprising a token or alias. Furthermore, while Venkatasubramanian discloses the network processing computer (see Kozlov at least at [0065]), Venkatasubramanian does not expressly disclose the computer resolves the token or the alias into the credential, and replaces the token or alias with the credential in the first push transfer message.
However, Kozlov discloses a push message (push transaction messages, see at least [0029], see also [0039] and [0060].);
a message comprising a token or alias (an alias resolve request message comprising an alias from a transfer server. See at least [0037].);
the computer resolves the token or the alias into the credential, and replaces the token or alias with the credential in the first push transfer message (receiving, by a directory server computer, an alias resolve request message comprising an alias from a transfer server. The transfer server computer can be a first transfer server and can receive a message with an alias from a sender device at the start of an interaction such as a payment transaction. After receiving the alias resolve request message, the directory server computer can then transmit the alias resolve request message comprising the alias to plurality of mapping computers (e.g., in parallel or substantially in parallel). After receiving the alias resolve request messages, the mapping computers may search their databases to identify any credentials or tokens associated with the alias. The mapping computers can then return the credentials or the tokens to the transfer server computer in alias resolve response messages. A credential or token from the plurality of credentials or tokens is then determined (e.g., selected) by the directory server computer, and is then transmitted to the transfer server computer. The transfer server computer then conducts a transaction process using the determined credential or token. In some embodiments, the transfer server computer generates a push transaction message, such as an OCT message comprising the credential or token, and a transfer amount, and then transmits the push transaction message to a second transfer server computer for further processing of the push transaction. See at least [0037]-[0039].).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the message of Venkatasubramanian to be a push message, as taught by Kozlov, and to modify the message of Venkatasubramanian to comprise a token or alias, as taught by Kozlov, and to modify the computer of Venkatasubramanian to resolve the token or the alias into the credential and replace the token or alias with the credential in the first push transfer message, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
Regarding claim 7, the combination of Venkatasubramanian, Kozlov, and Suresh disclose the limitations of claim 3, as discussed above, and Venkatasubramanian further discloses the first transfer message is a first message (Acquirer server transmitting first authorization request to Payment Network server. See at least [0065] and FIG. 3, step 308.).
While Venkatasubramanian the first transfer message, Venkatasubramanian does not expressly disclose the message is a push message. Furthermore, while Venkatasubramanian discloses a first message, Venkatasubramanian does not expressly disclose the message is an original credit transaction (OCT) message.
However, Koslov discloses the message is a push message (push transaction messages, see at least [0029], see also [0039] and [0060].);
the message is an original credit transaction (OCT) message (messages may be a push message such as an OCT message. See at least [0039].).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the transfer message of Venkatasubramanian to be a push message, as taught by Kozlov, and to modify the message of Venkatasubramanian to be an OCT message, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
Regarding claim 8, the combination of Venkatasubramanian, Kozlov, and Suresh disclose the limitations of claim 7, as discussed above, and Venkatasubramanian further discloses the second transfer message is a second message (The credit score database transmits a credit score of the user to the payment network server. See at least [0070].).
While Venkatasubramanian the second transfer message, Venkatasubramanian does not expressly disclose the message is a push message. Furthermore, while Venkatasubramanian discloses a second message, Venkatasubramanian does not expressly disclose the message is an OCT message.
However, Koslov discloses the message is a push message (push transaction messages, see at least [0029], see also [0039] and [0060].);
the message is an OCT message (messages may be a push message such as an OCT message. See at least [0039].).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the transfer message of Venkatasubramanian to be a push message, as taught by Kozlov, and to modify the message of Venkatasubramanian to be an OCT message, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
Regarding claim 11, the combination of Venkatasubramanian, Kozlov, and Suresh disclose the limitations of claim 1, as discussed above, and Venkatasubramanian further discloses transmitting, by the receiver entity computer, a message to a receiver user device indicating that the credit account has been modified (The acquirer server then transmits the transaction approval notification to the user device by way of the online payment gateway. The user is thus notified that the transaction is successful and the order for the product is placed at the merchant application ‘M1’. See at least [0095] and FIG. 5, step 526, depicting the transaction approval notification transmitted from the acquirer server to the user device.)
While Venkatasubramanian discloses indicating the record has been modified, Venkatasubramanian does not expressly disclose indicating the credit account has been modified with an amount equal to the credit balance of the credit account or the another value less than the credit balance of the credit account.
However, Suresh discloses indicating the credit account has been modified with an amount equal to the credit balance of the credit account or the another value less than the credit balance of the credit account (Portable computing device can then send a notification to wallet credit service indicating that the user would like to make a payment of a specified amount to pay down a credit card balance. See at least [0059]. See also [0063].).
From the teaching of Suresh, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the indication that the record has been modified of Venkatasubramanian to be an indication that the credit account has been modified with an amount equal to the credit balance of the credit account or the another value less than the credit balance of the credit account, as taught by Suresh, in order to improve credit card customer experience (see Suresh at least at [0015]-[0021]).
Claim 12 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale.
Claim 13 has similar limitations found in claim 3 above, and therefore is rejected by the same art and rationale.
Regarding claim 14, the combination of Venkatasubramanian, Kozlov, and Suresh disclose the limitations of claim 12, as discussed above, and Venkatasubramanian further discloses and the second transfer message comprises data (The credit score database transmits a credit score of the user to the payment network server. See at least [0070].).
While Venkatasubramanian discloses a transfer message, Venkatasubramanian does not expressly disclose the message is a push message. Furthermore, while Venkatasubramanian discloses the message comprises data, Venkatasubramanian does not expressly disclose the message comprises the credential.
However, Kozlov discloses the transfer message is a push message (push transaction messages, see at least [0029], see also [0039] and [0060].);
the message comprises the credential (the mapping computers may search their databases to identify any credentials or tokens associated with the alias. The mapping computers can then return the credentials or the tokens to the transfer server computer in alias resolve response messages. See at least [0037]-[0039])
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the transfer message of Venkatasubramanian to be a push message, as taught by Kozlov, and to modify the message of Venkatasubramanian to comprise a credential, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
Regarding claim 15, Venkatasubramanian discloses a method comprising (see at least FIG. 3.):
receiving, by a network processing computer from a sender entity computer, a first transfer message comprising a value (Acquirer server transmitting first authorization request to Payment Network server. See at least [0065] and FIG. 3, step 308. The first authorization message comprises the transaction amount, see at least [0064]. The Examiner is interpreting the Payment Network server as the network processing computer. And the Examiner is interpreting the acquirer server as the sender entity computer.);
transmitting, by the network processing computer, the first transfer message to a receiver entity computer (The First authorization message sent from the Payment Network server to the Issuer Server. See at least [0065] and FIG. 3, step 310. The Examiner is interpreting the issuer server as the receiving entity computer.),
wherein the receiver entity computer determines that the value exceeds a credit balance of a credit account of a receiver (The issuer determines the account balance or available credit line does not cover the transaction amount. See at least [0066] and see also FIG. 3, step 312.),
a credit account managed by the receiver entity computer (A user performs a transaction for a transaction amount from their bank account that is maintained with an issuer bank. See at least [0029]. Issuer Server, see at least [0065].) and
the credit balance being an amount owed to an issuing bank operating the receiving entity computer (The issuer determines the account balance or available credit line does not cover the transaction amount. See at least [0066]. The Examiner interprets a payment amount that is to be paid via a credit line as an amount owed to an issuer bank.),
and transmits, to the network processing computer, a first response message comprising the credit balance of a credit account and an indicator declining the first transfer message (The issuer determines the account balance or available credit line does not cover the transaction amount. See at least [0066] and see also FIG. 3, step 312. The issuer transmits a transaction decline notification to the payment network server to indicate the transaction has been declined. The transaction decline notification includes a third data element that indicates the account balance or the available credit line of the user account. See at least [0066] and FIG. 3, step 312. Issuer server manages accounts of users and stores account details including account balance. See at least [0049].);
receiving, by the network processing computer, the first response message (The issuer transmits a transaction decline notification to the payment network server, the notification indicates the transaction has been declined. The transaction decline notification includes a third data element that indicates the account balance or the available credit line of the user account. See at least [0066] and FIG. 3, step 312);
transmitting, by the network processing computer, a message to an entity (the payment network server transmits a message to the credit score database, see at least [0070] and FIG. 3, step 314.);
receiving, by the network processing computer, a second transfer message (The credit score database transmits a credit score of the user to the payment network server. See at least [0070].);
receiving, by the network processing computer, a second response message comprising an approval indicator (The issuer server transmits, to the payment network server, a transaction approval notification indicating the transaction is approved. See at least [0072] and FIG. 3, step 322); and
transmitting, by the network processing computer, the second response message comprising the approval indicator to the sender entity computer (The payment network server transmits, to the acquirer server, the transaction approval notification indicating the transaction is approved. See at least [0073] and FIG. 3, step 326.).
While Venkatasubramanian discloses transfer messages, Venkatasubramanian does not expressly disclose the transfer messages are push messages. Furthermore, while Venkatasubramanian discloses transmitting a message, Venkatasubramanian does not expressly disclose transmitting the first response message. Furthermore, while Venkatasubramanian discloses transmitting to an entity, Venkatasubramanian does not expressly disclose transmitting to the sender entity. Furthermore, while Venkatasubramanian discloses a second transfer message, Venkatasubramanian does not expressly disclose the second transfer message comprising the credit balance of the credit account or another value less than the credit balance of the credit account. Nor does Venkatasubramanian expressly disclose immediately crediting, by the receiver entity computer, the credit account in the amount of the credit balance of the credit account or the another value less than the credit balance of the credit account, thereby reducing the credit balance of the credit account.
However, Kozlov discloses push messages (push transaction messages, see at least [0029], see also [0039] and [0060].).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the message of Venkatasubramanian to be a push message, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
While Venkatasubramanian discloses transmitting a message, Venkatasubramanian does not expressly disclose transmitting the first response message. Furthermore, while Venkatasubramanian discloses transmitting to an entity, Venkatasubramanian does not expressly disclose transmitting to the sender entity. Furthermore, while Venkatasubramanian discloses a second transfer message, Venkatasubramanian does not expressly disclose the second transfer message comprising the credit balance of the credit account or another value less than the credit balance of the credit account. Nor does Venkatasubramanian expressly disclose immediately crediting, by the receiver entity computer, the credit account in the amount of the credit balance of the credit account or the another value less than the credit balance of the credit account, thereby reducing the credit balance of the credit account.
However, Suresh discloses transmitting the first response message; transmitting to the sender entity (Rewards engine can further send a notification to transfer cash to cash disbursement service, and cash disbursement service can receive the notification. Notification to transfer cash to cash disbursement service can include a reference ID that establishes a reference number for the particular transfer of a cash back reward by cash disbursement service, and an identification of the credit card holder or cash account associated with the credit card holder, and an amount to be transferred. The notification can also be signed by rewards engine so that cash disbursement service can determine that the notification is authentic. In response to receiving the notification to transfer the cash back reward, cash disbursement service can transfer the amount from a cash account of the entity responsible for paying out cash back rewards to the cash account of the credit card holder. Cash disbursement service can then notify rewards engine of the successful transaction. See at least [0042]-[0043].);
the second transfer message comprising the credit balance of the credit account or another value less than the credit balance of the credit account (Portable computing device can then send a notification to wallet credit service indicating that the user would like to make a payment of a specified amount to pay down a credit card balance. See at least [0059]. See also [0063].);
immediately crediting, by the receiver entity computer, the credit account in the amount of the credit balance of the credit account or the another value less than the credit balance of the credit account, thereby reducing the credit balance of the credit account (Then wallet cash service can send a notification instructing cash payment service to transfer cash from the account associated with the user to an account associated with credit card. Notification can include information that identifies the user, that identifies the business entity associated with the credit card that will receive the funds, the transaction reference ID, the amount of the transaction, and a digital signature of wallet cash service. Upon receiving notification, cash payment service can verify the signature of wallet cash service in notification, can verify that there are enough funds in the user's account to cover the transaction, can transfer money from the user account to the business entity account associated with the credit card, and update account balances for both the user and the business entity. Cash payment service can send a notification informing wallet cash service of the successful transfer of funds. See at least [0065]-[0067].).
From the teaching of Suresh, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the transmitting of Venkatasubramanian to transmit the first response message, as taught by Suresh, and to modify the transmitting of Venkatasubramanian to transmit to the sender entity, as taught by Suresh, and to modify the message of Venkatasubramanian to comprise a value less than the credit value of the credit account, as taught by Suresh, and to modify the receiver entity computer of Venkatasubramanian to immediately credit the credit account in the another value less than the credit balance of the credit account, thereby reducing the credit balance of the credit account, as taught by Suresh, in order to improve credit card customer experience (see Suresh at least at [0015]-[0021]).
Regarding claim 16, the combination of Venkatasubramanian, Kozlov, and Suresh discloses the limitations of claim 15, and Venkatasubramanian further discloses the first transfer message comprising data (The first authorization message comprises the transaction amount, see at least [0064]).
While Venkatasubramanian discloses a transfer message, Venkatasubramanian does not expressly disclose the transfer message is a push transfer message. Furthermore, while Venkatasubramanian discloses the message comprising data, Venkatasubramanian does not expressly disclose the message comprises an alias or a token.
However, Kozlov discloses the transfer message is a push transfer message (push transaction messages, see at least [0029], see also [0039] and [0060].);
the message comprises an alias or a token (an alias resolve request message comprising an alias from a transfer server. See at least [0037].).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the transfer message of Venkatasubramanian to be a push message, as taught by Kozlov, and to modify the message of Venkatasubramanian to comprise an alias or token, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
Regarding claim 17, the combination of Venkatasubramanian, Kozlov, and Suresh discloses the limitations of claim 16, and Venkatasubramanian further discloses transmitting the first transfer message to the receiver entity computer (The First authorization message sent from the Payment Network server to the Issuer Server. See at least [0065] and FIG. 3, step 310).
While Venkatasubramanian discloses transmitting the first transfer message to the receiver entity computer, Venkatasubramanian does not expressly disclose resolving the alias or the token to a credential, and inserting the credential for the alias or token before transmitting. Furthermore, while Venkatasubramanian discloses a transfer message, Venkatasubramanian does not expressly disclose the transfer message is a push message.
However, Kozlov discloses resolving the alias or the token to a credential, and inserting the credential for the alias or token before transmitting (receiving, by a directory server computer, an alias resolve request message comprising an alias from a transfer server. The transfer server computer can be a first transfer server and can receive a message with an alias from a sender device at the start of an interaction such as a payment transaction. After receiving the alias resolve request message, the directory server computer can then transmit the alias resolve request message comprising the alias to plurality of mapping computers (e.g., in parallel or substantially in parallel). After receiving the alias resolve request messages, the mapping computers may search their databases to identify any credentials or tokens associated with the alias. The mapping computers can then return the credentials or the tokens to the transfer server computer in alias resolve response messages. A credential or token from the plurality of credentials or tokens is then determined (e.g., selected) by the directory server computer, and is then transmitted to the transfer server computer. The transfer server computer then conducts a transaction process using the determined credential or token. In some embodiments, the transfer server computer generates a push transaction message, such as an OCT message comprising the credential or token, and a transfer amount, and then transmits the push transaction message to a second transfer server computer for further processing of the push transaction. See at least [0037]-[0039].);
the transfer message is a push message (push transaction messages, see at least [0029], see also [0039] and [0060].).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the transmitting of Venkatasubramanian to occur after resolving the alias or the token to a credential, and inserting the credential for the alias or token, as taught by Kozlov, and to modify the transfer message of Venkatasubramanian to be a push message, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
Regarding claim 18, the combination of Venkatasubramanian, Kozlov, and Suresh discloses the limitations of claim 15, as discussed above, and Venkatasubramanian further discloses the second transfer message further comprises data (The first amount indicated by the first data element of the second authorization request. See at least [0072].).
While Venkatasubramanian discloses a transfer message, Venkatasubramanian does not expressly disclose the transfer message is a push message. Furthermore, while Venkatasubramanian discloses the message comprises data, Venkatasubramanian does not expressly disclose the message comprises a credential.
However, Kozlov discloses the transfer message is a push message (push transaction messages, see at least [0029], see also [0039] and [0060].);
the message comprises a credential (the mapping computers may search their databases to identify any credentials or tokens associated with the alias. The mapping computers can then return the credentials or the tokens to the transfer server computer in alias resolve response messages. See at least [0037]-[0039].).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the transfer message of Venkatasubramanian to be a push message, as taught by Kozlov, and to modify the message of Venkatasubramanian to comprise a credential, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
Regarding claim 19, the combination of Venkatasubramanian, Kozlov, and Suresh discloses the limitations of claim 15, as discussed above, and Venkatasubramanian further discloses the first transfer message and the second transfer message are messages (Acquirer server transmitting first authorization request to Payment Network server. See at least [0065] and FIG. 3, step 308. The credit score database transmits a credit score of the user to the payment network server. See at least [0070].).
While Venkatasubramanian discloses transfer messages, Venkatasubramanian does not expressly disclose the transfer messages are a push message. Furthermore, while Venkatasubramanian discloses messages, Venkatasubramanian does not expressly disclose the messages are original credit transaction (OCT) messages.
However, Kozlov discloses the transfer messages are a push message (push transaction messages, see at least [0029], see also [0039] and [0060].);
the messages are original credit transaction (OCT) messages (messages may be a push message such as an OCT message. See at least [0039].).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the transfer messages of Venkatasubramanian to be a push message, as taught by Kozlov, and to modify the message of Venkatasubramanian to be an OCT message, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
Regarding claim 20, the combination of Venkatasubramanian, Kozlov, and Suresh discloses the limitations of claim 15, as discussed above, and Venkatasubramanian further discloses the first transfer message comprises data (The first authorization message comprises the transaction amount, see at least [0064]);
transmit the first push transfer message to the receiver entity computer (The First authorization message sent from the Payment Network server to the Issuer Server. See at least [0065] and FIG. 3, step 310.).
While Venkatasubramanian discloses a transfer message, Venkatasubramanian does not expressly disclose the transfer message is a push message. Furthemore, while Venkatasubramanian discloses the message comprising data, Venkatasubramanian does not expressly disclose the message comprising a credential. Furthermore, while Venkatasubramanian discloses transmitting, the first push transfer message to the receiver entity computer, Venkatasubramanian does not expressly disclose analyzing, by the network processing computer, the credential to determine an address of the receiver entity computer using a portion of the credential and using the address to transmit.
However, Kozlov discloses the transfer message is a push message (push transaction messages, see at least [0029], see also [0039] and [0060].);
the message comprising a credential (the mapping computers may search their databases to identify any credentials or tokens associated with the alias. The mapping computers can then return the credentials or the tokens to the transfer server computer in alias resolve response messages. See at least [0037]-[0039]);
analyzing, by the network processing computer, the credential to determine an address of the receiver entity computer using a portion of the credential and using the address to transmit (After the directory server computer receives the alias resolve request message comprising the alias of the receiver, the directory server computer can look up the addresses (e.g., server addresses) of the various mapping computers associated with the alias of the receiver. The receiver of the receiver device may have previously registered the alias of the receiver and the identities and addresses of the various mapping computers which store the mappings of the alias of the receiver to any of the various tokens mapped to the alias of the receiver. After the directory server computer identifies the various mapping computers associated with the alias of the receiver, the directory service computer transmits the alias resolve request message to each of the first and second mapping computers. See at least [0101]-[0102].).
From the teaching of Kozlov, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the transfer message of Venkatasubramanian to be a push message, as taught by Kozlov, and to modify the message of Venkatasubramanian to comprise a credential, as taught by Kozlov, and to modify the transmitting of Venkatasubramanian to transmit by analyzing, by the network processing computer, the credential to determine an address of the receiver entity computer using a portion of the credential and using the address to transmit, as taught by Kozlov, in order to address security challenges associated with accessing secure data and to improve efficiency (see Kozlov at least at [0002]-[0005]), and to improve efficiency of conducting a transaction (see Kozlov at least at [0036]), and in order to improve data security and reduce impeding speed of transactions such as payment transactions (see Kozlov at least at [0110]).
No Prior Art Rejections
Based on the prior art search results, the prior art of record fails to anticipate or render obvious the claimed subject matter of claims 21-22. While some individual features of claims 21-22 may be shown in the prior art of record: no known reference, alone or in combination, would provide the invention of claims 21-22.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20110047045 A1 (“Brody”) discloses a system and method allows users to make purchases by charging or funding a prepaid debit card with their cell phone accounts by simulating a user roaming with their mobile device.
US 20250141687 A1 (“Glynn”) discloses transmission of information over a network. A validity token is generated based on a received contactless card identifier associated with a contactless card. The validity token is generated upon validating the contactless card using the contactless card identifier, and transmitted to a first computing device. A second computing device is identified based on an information request received from the first computing device. The information request includes a first public key associated with the first computing device and the validity token. An encrypted response to the request and a second public key associated with the second computing device are sent to the first computing device. The second computing device generates the encrypted response and encrypts it using a shared key generated using the first public key. The first computing device decrypts the response upon generation of the shared key using the second public key.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAVEN E YONO whose telephone number is (313)446-6606. The examiner can normally be reached Monday - Friday 8-5PM EST.
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, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/RAVEN E YONO/Primary Examiner, Art Unit 3694
Prosecution Insights