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 November 13, 2025. Claims 1, 4, 6, 8, 9, 12, 13, 15, 17, and 18 have been amended. Claims 1–20 are currently pending and have been examined.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1–20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1 :
The method of claim 1 is a process, the CRM of claim 9 is a manufacture, and the system of claim 17 is a machine. Claims 1, 9, and 17 are within the statutory categories of invention.
Step 2A, Prong One: Using the amended text of claim 1 as representative, claims 1, 9, and 17 recite:
A computer-implemented method for cross-border network messaging, the method comprising: receiving, by a gateway computing device of a payment system, from an institution, a transfer request for a real-time transfer, via a real-time payment (RPT) provider, from a sender user to a recipient user, the transfer request including an amount to be transferred and a proxy unique to the recipient user, the institution located in a first region, which is associated with a first currency, and the recipient user located in a second region, which is associated with a second currency; resolving, by the gateway computing device, the proxy into account data specific to an account of the recipient user; requesting, by the gateway computing device, from a liquidity host, a quote associated with conversion of the amount in the first currency to the second currency; directing, by the gateway computing device, the RTP provider to transfer funds, as defined by the quote, from the institution associated with the sender user to a liquidity receiver in the first region; submitting, by the gateway computing device, based on the resolved account data, the transfer request to a second gateway computing device in the second region; receiving, by the gateway computing device, from the second gateway computing device, a confirmation of the real-time transfer to the account of the recipient user identified by the resolved account data in the second region; and notifying, by the gateway computing device, the RTP provider of the real-time transfer to the recipient user in the second region.
Referring to the limitations above, independent claims 1, 9, and 17 recite an abstract idea enumerated in the MPEP. Specifically, claims 1, 9, and 17 recite the abstract idea of certain methods of organizing human activity. More specifically, as drafted, claims 1, 9, and 17 recite:
The commercial or legal interaction of facilitating a cross-border fund transfer agreement/contract from a sender in a first region with a first currency to a recipient in a second region with a second currency, including resolving a proxy identifier to account data, obtaining a currency conversion quote, directing intermediary fund movements, and confirming transfer completion. See MPEP 2106.04(a)(2)(II)(B).
The fundamental economic practice of cross-border money remittance/correspondent banking, which is a longstanding commercial practice long prevalent in our system of commerce. See MPEP 2106.04(a)(2)(II)(A); see also Alice Corp. v. CLS Bank, 573 U.S. 208 (2014) (intermediated settlement); Bilski v. Kappos, 561 U.S. 593 (2010) (hedging risk).
Step 2A, Prong Two: Do the claims recite additional elements that integrate the judicial exception into a practical application? Integration of the judicial exception into a practical application requires an additional element 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.
Regarding claims 1, 9, and 17, the claims recite the following additional elements: a gateway computing device, a payment system, a real-time payment (RTP) provider, a second gateway computing device, a liquidity host, a non-transitory computer-readable storage medium, a processor, and executable instructions.
These additional elements are recited at a high level of generality (i.e., as generic computing components performing generic computing functions of receiving, transmitting, storing, and processing data) such that they amount to no more than mere instructions to apply the exception using generic computer components. See MPEP 2106.05(f). Specifically:
The “gateway computing device” is described in Applicant’s specification at ¶[0044] as a generic computing device (e.g., servers, workstations, personal computers, etc.) and does not represent a particular machine with a specific architecture that imposes meaningful limits.
The “second gateway computing device” is similarly generic and merely represents another networked computer in a different geographic region.
The “RTP provider” and “liquidity host” are identified by their functional roles in the business process, not by any specific technical architecture or improvement.
The “non-transitory computer-readable storage medium” and “processor” are explicitly described in generic terms at ¶[0045]–[0046].
The claims do not recite:
An improvement to the functioning of a computer or to any other technology or technical field (see MPEP 2106.05(a));
Application of the judicial exception with, or by use of, a particular machine (see MPEP 2106.05(b));
A transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05©); or
Any other meaningful limitation beyond generally linking the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)).
The receiving, resolving, requesting, directing, submitting, receiving confirmation, and notifying steps represent insignificant extra-solution activity (data gathering and output) in the form of receiving a transfer request, querying for account data/quotes, and transmitting messages/notifications. See MPEP 2106.05(g).
The claims describe a result-oriented solution — i.e., what is accomplished (cross-border real-time transfer) — rather than how a specific technical improvement is achieved. See MPEP 2106.05(f)(1). The recitation of using a multi-gateway architecture to route messages between regions is merely the use of computers as tools to perform the fundamental economic practice of correspondent banking. See MPEP 2106.05(f)(2).
Accordingly, the additional elements do not integrate the abstract idea into a practical application. Claims 1, 9, and 17 are directed to an abstract idea.
Step 2B:
Regarding claims 1, 9, and 17, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a gateway computing device, payment system, RTP provider, second gateway computing device, liquidity host, processor, memory, and non-transitory computer-readable storage medium amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
The additional elements, when considered individually and in combination, are well-understood, routine, and conventional (WURC) activities:
Receiving data over a network (receiving a transfer request; receiving confirmation) — see Symantec, 838 F.3d 1307, 1321 (Fed. Cir. 2016); see also MPEP 2106.05(d)(II) (“Receiving or transmitting data over a network”).
Sending data/messages over a network (submitting the transfer request; notifying; directing) — see OIP Techs., Inc. v. Amazon.com, 788 F.3d 1359, 1363 (Fed. Cir. 2015).
Storing and retrieving information in memory/databases (resolving a proxy into account data, i.e., performing a database lookup) — see Versata Dev. Group v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015); see also MPEP 2106.05(d)(II) (“Storing and retrieving information in memory”).
Performing repetitive calculations/queries (requesting a conversion quote) — see MPEP 2106.05(d)(II).
The computing components implementing the abstract idea are generic in view of at least Applicant’s specification at ¶[0044]–[0046], which describes the computing devices using standard, commercially available hardware (servers, workstations, CPUs, RAM, ROM, network adapters, etc.).
The claimed combination of generic components performing conventional steps does not transform the abstract idea into patent-eligible subject matter. See Alice Corp., 573 U.S. at 224 (“the mere recitation of a generic computer cannot transform a patent-ineligible abstract idea into a patent-eligible invention”).
Accordingly, claims 1, 9, and 17 do not recite additional elements that amount to significantly more than the judicial exception and are not patent eligible.
Dependent Claims 2–8, 10–16, and 18–20 do not cure the deficiencies in their respective base claims as follows:
Dependent Claim(s)
Additional Limitation(s)
Analysis
2, 10, 18
Verifying reachability of institution and standing of account
Further defines the abstract idea (commercial verification step); no technological improvement. MPEP 2106.05(g) (extra-solution activity — data verification).
3, 11, 19
Quote includes conversion rate; proxy is a phone number
Further defines the abstract idea (specifies data content); field of use limitation. MPEP 2106.05(h).
4, 12
Second transfer to a third region with a third currency (duplication of process)
Repeats the same abstract process for a different transfer; no new technological element. MPEP 2144.04(VI)(B) (duplication of parts).
5
PD service and CT out service within gateway
Merely labels sub-components of the generic gateway; invokes computer as tool. MPEP 2106.05(f)(2).
6, 13
Multiple currency conversion providers; soliciting selection
Further defines the abstract idea (obtaining competing quotes, user selection — fundamental economic practice of comparison shopping).
7, 14
Liquidity receiver is one of the currency conversion providers
Further defines the abstract idea (identifies a business entity’s dual role).
8, 15
Regions are different countries
Field of use limitation. MPEP 2106.05(h).
16
Search proxy in local proxy directory
Generic database lookup; WURC. See Versata, 793 F.3d at 1334.
20
Search local directory; if not found, submit to second gateway
Conditional query routing — generic network communication; WURC. See Symantec, 838 F.3d at 1321.
Accordingly, claims 1–20 are not patent eligible under 35 U.S.C. § 101.
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.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Parkinson (US 2021/0374726) in view of Kapoor (US 2021/0035211).
Claim 1 recites:
A computer-implemented method for cross-border network messaging, the method comprising: (Parkinson, Fig. 4, [0044], method 400 for cross-border transaction)
receiving, by a gateway computing device of a payment system, from an institution, a transfer request for a real-time transfer, via a real-time payment (RPT) provider, from a sender user to a recipient user, the transfer request including an amount to be transferred and a proxy unique to the recipient user, the institution located in a first region, which is associated with a first currency, and the recipient user located in a second region, which is associated with a second currency; (Parkinson, Fig. 4, [0045], first entity desires to transfer funds via sender institution 102 to a second entity by way of beneficiary institution 104, payment network receives request at 402. Parkinson does not specifically disclose a proxy unique to the recipient user. Kapoor, [0015], discloses a token identifier such as the beneficiary’s mobile phone number or email address. It would have been obvious to a person of ordinary skill in the art before the time of effective filing to modify the second entity of Parkinson to be the token identifier of Kapoor so that the payer does not need to specify the beneficiary’s bank account as disclosed in Kapoor, [0015], and to comply with privacy rules and regulations as discussed in Parkinson, [0017]. Further, it would have been obvious to one of ordinary skill in the art before the time of effective filing to include the features as taught in Kapoor in Parkinson since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additionally, both are in the field of cross border banking transactions and one of ordinary skill in the art would recognize the combination to be predictable.)
“resolving, by the gateway computing device, the proxy into account data specific to an account of the recipient user;”
Parkinson, Fig. 4, ¶[0046], discloses verifying information about the beneficiary at step 406. Parkinson does not specifically disclose resolving the proxy into account data specific to an account of the recipient user.
Kapoor, ¶[0021], discloses validating, based on the beneficiary’s token included in the transaction’s message, that the beneficiary has a bank account that is registered, and resolving the token to specific account information for the beneficiary. See also Kapoor, ¶[0050]–[0053], disclosing lookup and resolution of the token to beneficiary account data.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the verification process of Parkinson to include token-to-account resolution as taught by Kapoor so that the system can identify the specific beneficiary account using only a proxy identifier, as disclosed in Kapoor ¶[0015], ¶[0021].
“requesting, by the gateway computing device, from a liquidity host, a quote associated with conversion of the amount in the first currency to the second currency;”
Parkinson, Fig. 4, ¶[0048], discloses that payment network 106 requests, at step 414, a currency conversion quote from FX provider 114. The FX provider 114 of Parkinson reads on the claimed “liquidity host” under BRI as the FX provider provides liquidity/conversion services. See also Parkinson, ¶[0030]–[0032], discussing the role of the FX provider and liquidity provider in providing quotes for conversion.
“directing, by the gateway computing device, the RTP provider to transfer funds, as defined by the quote, from the institution associated with the sender user to a liquidity receiver in the first region;”
Parkinson, Fig. 4, ¶[0045], discloses that sender institution 102 transfers, at step 404, funds for the transfer to the sponsor institution 108 in the first region. Parkinson, ¶[0048]–[0049], discloses the payment network 106 coordinates the movement of funds based on the accepted quote. The sponsor institution 108 of Parkinson reads on the “liquidity receiver” as it receives the transferred funds in the first region to facilitate the cross-border transfer.
“submitting, by the gateway computing device, based on the resolved account data, the transfer request to a second gateway computing device in the second region;”
Parkinson, Fig. 4, ¶[0049], discloses payment network 106 requests, at step 416, a liquidity quote from the liquidity provider 112 for the fund transfer in the second region, effectively routing the transfer to processing entities in the second/beneficiary region based on verified beneficiary information. See also Parkinson, ¶[0023]–[0025], discussing the multi-region network architecture.
Regarding the amendment “based on the resolved account data”: Kapoor, ¶[0021], ¶[0050]–[0053], teaches that once the beneficiary token is resolved to specific account data, the transaction proceeds using that resolved account data to route the payment to the correct beneficiary institution and account. It would have been obvious to a person of ordinary skill in the art that, having resolved the proxy to account data (per the combination above), the system would use that resolved data to route the transfer request to the appropriate second region processing entity, as this is the inherent purpose of resolving account data.
“receiving, by the gateway computing device, from the second gateway computing device, a confirmation of the real-time transfer to the account of the recipient user identified by the resolved account data in the second region; and” Parkinson, Fig. 4, ¶[0049]–[0050], discloses that the liquidity provider 112 transfers funds at step 418 to the sponsor institution 110, and sponsor institution 110 transfers, at step 420, funds to beneficiary institution 104 and confirms to the payment network 106 that the funds have been paid to the beneficiary.
“to the account of the recipient user identified by the resolved account data”: Kapoor, ¶[0021], ¶[0053]–[0055], teaches confirming that the funds have been transferred to the specific account associated with the resolved token/proxy. It would have been obvious that the confirmation would identify that the transfer reached the specific account resolved from the proxy, as this provides the sender with assurance that the intended recipient received the funds.
“notifying, by the gateway computing device, the RTP provider of the real-time transfer to the recipient user in the second region.”
Parkinson, Fig. 4, ¶[0050], discloses that sponsor institution 110 transfers, at step 420, funds to beneficiary institution 104 and confirms to the payment network 106 that the funds have been paid, completing notification of the transfer.
Claims 9 and 17 are directed to a non-transitory computer-readable storage medium and system, respectively, that recite substantially similar limitations as claim 1 and are rejected on the same grounds. Regarding CRM claim 9, see Parkinson, Fig. 3, ¶[0040], disclosing a non-transitory CRM. Regarding system claim 17, see Parkinson, Fig. 3, ¶[0037], disclosing system 100 including the gateway computing device.
Claim 2:
“The computer-implemented method of claim 1, further comprising, after resolving the proxy into the account data for the account of the recipient user, verifying, by the gateway computing device, a reachability of an institution holding the account of the recipient user and a standing of the account to receive the transfer.”
Parkinson, Fig. 4, ¶[0046], discloses verifying information at step 406. Parkinson does not specifically disclose verifying reachability of the institution and standing of the account after proxy resolution.
Kapoor, ¶[0021], discloses querying whether the beneficiary has a bank account that is registered and active by sending a validation message to the agent bank, which verifies the account standing. See also Kapoor, ¶[0050]–[0053], disclosing the validation process for determining if the beneficiary account is reachable and in good standing.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the verification process of Parkinson to include the reachability and standing verification of Kapoor to ensure the transfer can be completed before initiating fund movement, thereby reducing failed transaction costs and improving user experience, as suggested by Kapoor ¶[0021].
Claims 10 and 18 correspond to claim 2 and are rejected on the same grounds.
Claim 3:
Claim 3 recites:
“The computer-implemented method of claim 1, wherein the quote includes a conversion rate between the first currency and the second currency; and”
Parkinson, Fig. 4, ¶[0048], discloses a currency conversion quote including a rate.
“wherein the proxy including a phone number for the recipient user.”
Parkinson does not specifically disclose the proxy is a phone number.
Kapoor, ¶[0015], discloses a token identifier such as the beneficiary’s mobile phone number.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Parkinson to use a phone number as the proxy as taught by Kapoor so that the payer does not need to specify the beneficiary’s bank account, as disclosed in Kapoor ¶[0015].
Claims 11 and 19 correspond to claim 3 and are rejected on the same grounds.
Claim 4 (Currently Amended):
Claim 4 recites:
“The computer-implemented method of claim 1, further comprising: receiving, by the gateway computing device, from a second institution, a second transfer request for a second real-time transfer, via the RPT provider, from a second sender user to a second recipient user, the second transfer request including a second amount to be transferred and a second proxy unique to the second recipient user, the second recipient user located in a third region, which is associated with a third currency;”
Parkinson, Fig. 4, ¶[0045], discloses the payment network 106 receiving transfer requests. Parkinson, ¶[0020], discloses that multiple regions/countries may be involved. The processing of a second transfer from a second institution/sender to a second recipient in a third region represents a duplication of the process disclosed in claim 1 applied to a different regional pairing.
Kapoor, ¶[0015], discloses the proxy/token for the beneficiary. It would have been obvious to apply the same process to additional transfers involving additional regions. See MPEP 2144.04(VI)(B) regarding duplication of parts. See also Applicant’s specification ¶[0079] (“Although the terms first, second, third, etc. may be used herein to describe various features, these features should not be limited by these terms”).
“resolving, by the gateway computing device, the second proxy into second account data specific to an account of the second recipient user;”
Kapoor, ¶[0021], ¶[0050]–[0053], discloses resolving a token to specific account data. The same rationale applies as in claim 1.
“requesting, by the gateway computing device, a second quote associated with conversion of the second amount in the first currency to the third currency;”
Parkinson, Fig. 4, ¶[0048], discloses requesting a currency conversion quote. The same process applies for conversion to a third currency.
“directing the RTP provider to transfer funds, as defined by the second quote, from the second institution associated with the second sender user to the liquidity receiver in the first region;”
Parkinson, Fig. 4, ¶[0045], discloses directing fund transfers to the sponsor institution (liquidity receiver) in the first region.
“submitting, by the gateway computing device, the transfer request to a third gateway computing device in the third region;”
Parkinson, Fig. 4, ¶[0049], discloses routing the transfer to processing entities in the beneficiary’s region. A third gateway in a third region is an obvious extension of the multi-region architecture.
“receiving, from the third gateway computing device, a second confirmation of the second real-time transfer in the third region; and”
Parkinson, Fig. 4, ¶[0049]–[0050], discloses receiving confirmation.
“notifying, by the gateway computing device, the RTP provider of a transfer to the recipient user in the third region.”
Parkinson, Fig. 4, ¶[0050], discloses notification of transfer completion.
Claim 12 corresponds to claim 4 and is rejected on the same grounds.
Claim 5:
Claim 5 recites:
“The computer-implemented method of claim 1, wherein the gateway computing device includes a payment data (PD) service and a credit transfer (CT) out service; and”
Parkinson, Fig. 1, ¶[0021], [0023], [0029], discloses services provider 116 which provides various processing services within the payment network, reading on a PD service and CT out service under BRI in view of Applicant’s specification ¶[0023]–[0024]. See also Parkinson, Fig. 4, ¶[0047].
“wherein resolving the proxy includes resolving, by the PD service, the proxy; and”
Kapoor, ¶[0021], discloses validating the beneficiary’s token. It would have been obvious to a person of ordinary skill in the art to implement the proxy resolution function within the services provider 116 (PD service) of Parkinson as modified by Kapoor.
“wherein submitting the transfer request includes submitting, by the CT out service, the transfer request to a CT in service of the second gateway computing device.”
Parkinson, Fig. 4, ¶[0047], discloses the payment network 106 interacting with services provider 116 to route the transfer request to the beneficiary region, reading on a CT out service submitting to a CT in service of the second gateway.
Claim 6 (Currently Amended):
Claim 6 recites:
“The computer-implemented method of claim 1, wherein requesting the quote associated with conversion includes requesting the quote for the conversion from multiple different currency conversion providers; and further comprising soliciting a selection from the sender user of one of multiple quotes received from the multiple different currency conversion providers.”
Parkinson, Fig. 4, ¶[0048], discloses requesting a currency conversion quote and the sender institution accepting the quote. Parkinson does not specifically disclose multiple different currency conversion providers.
Kapoor, ¶[0023], discloses obtaining foreign exchange quotes from multiple foreign exchange providers and selecting among them.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the quote process of Parkinson to include quotes from multiple providers and soliciting user selection, as taught by Kapoor, in order to obtain the most acceptable/competitive rate, as suggested by Kapoor ¶[0023] and Parkinson ¶[0048].
Claim 13 corresponds to claim 6 and is rejected on the same grounds.
Claim 7:
Claim 7 recites:
“The computer-implemented method of claim 6, wherein at least one of the multiple currency conversion providers includes the liquidity receiver.”
Parkinson, Fig. 4, ¶[0049], discloses liquidity provider 112 provides a quote for the funds in the currency of the beneficiary region, thereby acting as both a liquidity entity and a currency conversion provider.
Claim 14 corresponds to claim 7 and is rejected on the same grounds.
Claim 8 (Currently Amended):
Claim 8 recites:
“The computer-implemented method of claim 1, wherein each of the first and second different regions is a different country.”
Parkinson, Fig. 1, ¶[0020], discloses that regions may be different countries (e.g., the United States and Thailand).
Claim 15 corresponds to claim 8 and is rejected on the same grounds.
Claim 16:
Claim 16 recites:
“The non-transitory computer-readable storage medium of claim 9, wherein the executable instructions, when executed by the at least one processor, cause the at least one processor, in resolving the proxy, to search for the proxy in a local proxy directory in the first region.”
Parkinson, Fig. 4, ¶[0046], discloses verification steps. Parkinson does not specifically disclose searching for the proxy in a local proxy directory in the first region.
Kapoor, ¶[0021], ¶[0050]–[0053], discloses validating the beneficiary’s token using a lookup table (directory) to resolve the token to account information.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the verification of Parkinson to include searching a local directory for the proxy as taught by Kapoor so that local resolution can be attempted first, reducing cross-border communications and improving efficiency, as suggested by Kapoor ¶[0050]–[0053].
Claim 20:
Claim 20 recites:
“The system of claim 17, wherein the gateway computing device is configured, by executable instructions, in resolving the proxy, to: search for the proxy a local proxy directory located in the first region; and in response to the proxy not being found in the local proxy directory, submit a proxy resolution request to a second gateway computing device located in the second region.”
Parkinson, Fig. 4, ¶[0046], discloses verification. Parkinson does not specifically disclose the two-step local-then-remote proxy resolution.
Kapoor, ¶[0050]–[0053], discloses routing the validate token request to a regional network lookup table 58, and if not found locally, forwarding the resolution request to another regional entity. The cascading lookup approach (local first, then remote) is a known and conventional network resolution technique.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Parkinson to search a local directory first and then submit to a remote gateway if not found, as taught by Kapoor, to reduce cross-border network traffic and improve resolution speed for locally-registered proxies, as suggested by Kapoor ¶[0050]–[0053].
Conclusion
THIS ACTION IS MADE FINAL. 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 MICHAEL W ANDERSON whose telephone number is (571)270-0508. The examiner can normally be reached Monday - Thursday 9am-4pm.
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, Tariq Hafiz can be reached at (571) 272-5350. 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.
Mike Anderson
Supervisor Patent Examiner
Art Unit 3693
/Mike Anderson/Supervisory Patent Examiner, Art Unit 3693
Prosecution Insights