DETAILED ACTION
Acknowledgements
This Office Action is in response to Applicant’s correspondence filed on 4/29/26.
The Examiner notes that citations to United States Patent Application Publication paragraphs are formatted as [####], #### representing the paragraph number.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Status of Claims
Claims 21-40 are currently pending.
Claims 21-40 are rejected as set forth below.
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 .
Response to Arguments
Claim Rejections - 35 U.S.C. § 103
Applicant’s arguments with respect to claim(s) 21, 28, 35 have been fully considered but are not persuasive. The rejection (and corresponding rejections to its dependent claims, if applicable) is maintained.
Applicant contends Reutov does not teach or suggest “determining a peak timeframe of a candidate destination payment processor of the one or more candidate destination payment processors by comparing the time of receipt of the response message to a threshold value; selecting the candidate destination payment processor as a final destination payment processor based on the routing directive associated with the request message and based on the time of receipt of the response message of the
retrieved contextual data being lower than the threshold value.” The Examiner respectfully disagrees. Reutov teaches receiving a confirmation response from a third party payment processor, determining if the confirmation response was received within a threshold period of time, concluding the transaction process if the confirmation response was received within a threshold period of time, and processing the payment transaction with another third party payment processor if the confirmation response was not received within the threshold period of time ([0062]).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 21-40 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 21-40 of copending Application No. 17936468 in view of United States Patent Application Publication No. 20150178708 to Reutov and United States Patent Application Publication No. 20050251568 to Zavgren.
As per claims 21-40, ‘468 substantially teach the claimed invention (claims 21-40). ‘468 does not explicitly teach, but Reutov teaches:
retrieving contextual data associated with the routing directive, wherein the contextual data indicates a condition of one or more candidate destination payment processors; determining a peak timeframe of a candidate destination payment processor of the one or more candidate destination payment processors by comparing the time of receipt of the response message to a threshold value; selecting the candidate destination payment processor as a final destination payment processor based on the routing directive associated with the request message and based on the time of receipt of the response message of the retrieved contextual data being lower than the threshold value; updating the request message based on the final destination payment processor and based on the routing directive being associated with only at least one of the one or more status code, and transmitting the updated request message to a downstream entity. ([0062], “Upon successful processing 708 of the payment transaction 1900 by the first third party payment processor 102, system 100 will receive a confirmation response 1700 (FIG. 17) back from the third party payment processor within a threshold period of time 707, transform or translate that response into a format accepted by the merchant's user payment module preferably using a code mapping engine (FIG. 18), and provide confirmation receipt 710 to the merchant's payment system 104 whereby merchant's payment system 104 may provide a confirmation receipt to the purchaser of the item and the process may end 711. A "threshold period of time" as used herein is generally a measure of time such as a "timeout value" which may be set by the user during the configuration of a third party payment processor 102 within the system. Non-limiting examples of threshold time periods or sometimes "a period of time" may be 1 second, 2, seconds, 3 seconds, 4 seconds, 5 seconds, 6 seconds, 7 seconds, 8 seconds, 9 seconds, 10 seconds, 15 seconds, 20 seconds, 30 seconds, 45 seconds, or any suitable amount of time. If the system does not receive a successful confirmation response message 709 from the third party payment processor within a threshold period of time, the payment gateway rules engine may next determine if any additional third party payment processors have been configured 712. This process may repeat for each additional third party payment processor that is configured within the system until a successful confirmation message 708 is received and the payment transaction has been successfully processed and the process may end 711.”)
One of ordinary skill in the art would have recognized that applying the known technique of Reutov to the known invention of ‘468 would have yielded predictable results and resulted in an improved invention. It would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such transaction routing features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the invention to include the steps of retrieving contextual data associated with the routing directive, wherein the contextual data indicates a condition of one or more candidate destination payment processors; determining a peak timeframe of a candidate destination payment processor of the one or more candidate destination payment processors by comparing the time of receipt of the response message to a threshold value; selecting the candidate destination payment processor as a final destination payment processor based on the routing directive associated with the request message and based on the time of receipt of the response message of the retrieved contextual data being lower than the threshold value; updating the request message based on the final destination payment processor and based on the routing directive being associated with only at least one of the one or more status code, and transmitting the updated request message to a downstream entity results in an improved invention because applying said technique ensures that a payment processor that can reliably return a response message within a threshold value is selected, thus improving the overall reliability of the invention.
‘468 as modified does not explicitly teach, but Zavgren teaches:
storing a time of transmission of the request message in the database; storing the time of receipt of the response message in the database; ([0029]-[0030], “FIG. 3 is an exemplary diagram of the database 250 in an implementation consistent with the present invention. Each of the message entries 330 includes a message information field 332 and a time stamp field 334. The message information field 332 stores information corresponding to a received or sent message. Each time that the node 110 receives or sends a message, it creates a new message entry 330. The time stamp field 334 stores the time upon which the message was received or sent.”)
One of ordinary skill in the art would have recognized that applying the known technique of Zavgren to the known invention of ‘468 as modified would have yielded predictable results and resulted in an improved invention. It would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such message logging features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the invention to store a time of transmission of the request message in the database and store the time of receipt of the response message in the database results in an improved invention because applying said technique ensures that contextual information regarding the status of a payment processor is saved, thus allowing the contextual information to be further analyzed for predictive purposes, i.e. predicting how the information influences error rates, thus improving the overall reliability of the invention.
This is a provisional nonstatutory double patenting rejection.
Claim Rejections - 35 USC § 103
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.
Claims 21-24, 27-31, 34-38 is/are rejected under 35 U.S.C. 103 as being unpatentable over United States Patent Application Publication No. 20150178708 to Reutov in view of United States Patent Application Publication No. 20050251568 to Zavgren.
As per claims 21, 28, 35, Reutov teaches:
A computer-implemented method for dynamic routing of electronic transactions while maintaining token compatibility, comprising: receiving a request message from a merchant system; (Fig 2, [0046], “Referring now to FIG. 2, a block diagram is provided as an exemplary overview the system 100 which comprises a payment gateway 1000 (FIG. 5). As shown by this example, a consumer cardholder 101a purchases goods or services online from a merchant 101b using their debit or credit card. In some embodiments of the present invention, merchant 101b receives the consumer's payment transaction 1900 through a merchant payment system 104 in a first API format or "first format". The system 100 may converts this data with an API conversion engine 800 (FIGS. 8 and 14) or local integration service 1300 (FIGS. 5, 13, and 15) to a "second format" readable by the payment gateway 1000 and rules engine 600 (FIGS. 5 and 6).”)
determining, by searching a database, that a routing directive is associated with the request message; ([0057], “In this example, the gateway rules engine 600 receives a transaction from the API conversion engine 800 or local integration service 1300 and is configured to run one or more logic based rules also known as a plurality of rules 603 (FIG. 6) which may be setup by a user in a rules configuration module (FIG. 11) to determine and select the appropriate third party payment processor 102 from a list of configured processors which may be configured using a payment processor configuration module (FIG. 10).”)
transmitting the request message to an initial destination payment processor; determining a time of transmission of the request message; receiving a response message from the initial destination payment processor, the response message including parameters that indicate the status of the initial destination payment processor; determining the time of receipt of the response message; determining the status of the initial destination payment processor based on the received response message; retrieving one or more status codes associated with the received response message and the time of receipt of the received response message associated with the one or more status codes; ([0057], “If selected first third payment processor is unresponsive or times out for a period of time (e.g. 100 ms, 500 ms, 1 s, 5 s, 10 s, 20 s, 30 s, 45 s, 60 s, etc.) or returns a processor failure result code 1702c (FIG. 17), then transaction may be routed back to the beginning of the process to try all the steps again and attempt to process the payment transaction with the next payment processor configured (FIG. 10) or according to a rank order 1101 (FIG. 11).”)
retrieving contextual data associated with the routing directive, wherein the contextual data indicates a condition of one or more candidate destination payment processors; determining a peak timeframe of a candidate destination payment processor of the one or more candidate destination payment processors by comparing the time of receipt of the response message to a threshold value; selecting the candidate destination payment processor as a final destination payment processor based on the routing directive associated with the request message and based on the time of receipt of the response message of the retrieved contextual data being lower than the threshold value; updating the request message based on the final destination payment processor and based on the routing directive being associated with only at least one of the one or more status code, and transmitting the updated request message to a downstream entity. ([0062], “Upon successful processing 708 of the payment transaction 1900 by the first third party payment processor 102, system 100 will receive a confirmation response 1700 (FIG. 17) back from the third party payment processor within a threshold period of time 707, transform or translate that response into a format accepted by the merchant's user payment module preferably using a code mapping engine (FIG. 18), and provide confirmation receipt 710 to the merchant's payment system 104 whereby merchant's payment system 104 may provide a confirmation receipt to the purchaser of the item and the process may end 711. A "threshold period of time" as used herein is generally a measure of time such as a "timeout value" which may be set by the user during the configuration of a third party payment processor 102 within the system. Non-limiting examples of threshold time periods or sometimes "a period of time" may be 1 second, 2, seconds, 3 seconds, 4 seconds, 5 seconds, 6 seconds, 7 seconds, 8 seconds, 9 seconds, 10 seconds, 15 seconds, 20 seconds, 30 seconds, 45 seconds, or any suitable amount of time. If the system does not receive a successful confirmation response message 709 from the third party payment processor within a threshold period of time, the payment gateway rules engine may next determine if any additional third party payment processors have been configured 712. This process may repeat for each additional third party payment processor that is configured within the system until a successful confirmation message 708 is received and the payment transaction has been successfully processed and the process may end 711.”)
Applicant attempts to further limit the method by describing characteristics of the business rules. However, this is representative of non-functional descriptive material as characteristics of the contextual data does not result in a functional relationship with the method and therefore cannot be used to differentiate Applicant's invention from the prior art invention. See MPEP 2111.05; In re Gulack, 217 USPQ 401 (Fed. Cir. 1983) (“When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from the prior art in terms of patentability.”). Specifically, the steps of retrieving the contextual data and determining a final destination payment processor based on the retrieved contextual data is carried out the same way regardless of the information included in the contextual data: there is no evidence the characteristics of the contextual data changes the efficiency or the accuracy or any other characteristic of the retrieving/determining. See Ex Parte Nehls, 88 USPQ2d 1883 (BPAI 2008) (“Here, the descriptive material (SEQ ID NOs) recited in the claims is not functional material like the data structures in Lowry. There is no evidence that SEQ ID NOs 9-1008 functionally affect the process of comparing a target sequence to a database by changing the efficiency or accuracy or any other characteristic of the comparison. Rather, the SEQ ID NOs are merely information being manipulated by a computer; the SEQ ID NOs are inputs used by a computer program that calculates the degree of similarity between a target sequence and each of the sequences in a database. The specific SEQ ID NOs recited in the claims do not affect how the method of the prior art is performed – the method is carried out the same way regardless of which specific sequences are included in the database (emphasis added).”)
Reutov does not explicitly teach, but Zavgren teaches:
storing a time of transmission of the request message in the database; storing the time of receipt of the response message in the database; ([0029]-[0030], “FIG. 3 is an exemplary diagram of the database 250 in an implementation consistent with the present invention. Each of the message entries 330 includes a message information field 332 and a time stamp field 334. The message information field 332 stores information corresponding to a received or sent message. Each time that the node 110 receives or sends a message, it creates a new message entry 330. The time stamp field 334 stores the time upon which the message was received or sent.”)
One of ordinary skill in the art would have recognized that applying the known technique of Zavgren to the known invention of Reutov would have yielded predictable results and resulted in an improved invention. It would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such message logging features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the invention to store a time of transmission of the request message in the database and store the time of receipt of the response message in the database results in an improved invention because applying said technique ensures that contextual information regarding the status of a payment processor is saved, thus allowing the contextual information to be further analyzed for predictive purposes, i.e. predicting how the information influences error rates, thus improving the overall reliability of the invention.
As per claims 22, 29, 36, Reutov teaches:
wherein updating the request message based on the final destination payment processor comprises: updating a message destination to the final destination payment processor by altering a message payload to update the message destination to the final destination payment processor, wherein altering the message payload to update the message destination to the final destination payment processor comprises updating an initial destination payment processor identifier to a final destination payment processor identifier; replacing an initial token with a token that is compatible with the final destination payment processor; ([0057], [0061], “Upon determining first third party payment processor to use 704 to process a given transaction, the payment gateway rule engine will send transaction details 705 to the appropriate translation engine 1602, 1603, etc. for that particular payment processor. Translation engine 1602, 1603, etc. is configured to create and translate payment transaction 1900 into an acceptable canonical formatted request 706 which can be received by the determined payment processor 102. Translation engine 1602, 1603, etc. may parse, format, transform, etc. payment details for a variety of third party payment processors 102. In this regard, the system 100 as presented in preferred embodiments is capable of sending payment transactions 1900 to be processed by more than one third party payment processors 102 in plurality of different orders or sequences that may be determined by custom rules created by a user.”)
As per claims 23, 30, 37, Reutov teaches:
wherein the one or more status codes and the time of receipt associated with the one or more status codes are associated with the routing directive based on determining the initial destination payment processor is unresponsive. ([0057])
As per claims 24, 31, 38, Reutov teaches:
wherein replacing the initial token with the token that is compatible with the final destination payment processor comprises: determining a token type compatible with the final destination payment processor; determining that the token type is different from that of the initial token; transmitting a primary token exchange request to a tokenization exchange service (TES) system; receiving a primary token exchange response from the TES system; and extracting the token that is compatible with the final destination payment processor from the primary token exchange response. ([0057], [0061])
As per claims 27, Reutov teaches:
wherein the routing directive is configured by a user via a web-based portal. ([0067], “FIG. 11 provides an example of a graphical user interface (GUI) of the rule creation module 1111 which may be employed by the system 100. The rule creation module allows a user (typically the merchant or merchant's system administrator) to create, make active, or make inactive one or more rules for use by the payment gateway rules engine 600.”)
As per claims 34, Reutov teaches:
wherein the downstream entity is a payment gateway. (Fig 13, [0077], “Right side of FIG. 13 outlines integration of merchant payment system 104 with the payment gateway 1000 using a novel local integration service 1300. Merchant payment system 104 can be integrated with payment gateway 1000 by replacing a third party payment processor url (tpp_url) with a url pointing to local integration service 1300 (url_local) installed on the merchant's server 300. Local integration service 1300 comprises computer implemented programs and processes responsible for accepting payment transaction requests intended for third party payment processors 102 and using a first/second translation engine module 1500 or similar processes to convert and transform the request which may come in a first format to a second format acceptable by the payment gateway 1000”)
Claims 25-26, 32-33, 39-40 is/are rejected under 35 U.S.C. 103 as being unpatentable over United States Patent Application Publication No. 20150178708 to Reutov in view of United States Patent Application Publication No. 20050251568 to Zavgren, and further in view of United States Patent Application Publication No. 20080189214 to Mueller.
As per claims 25, 32, 39, Reutov as modified does not explicitly teach, but Mueller teaches:
wherein the TES system is configured to generate an ancillary detokenization request and an ancillary tokenization request. ([0211], “In a Step 242, certain of the token data is selected for encryption. As already discussed, some or all of the token data can be selected for encryption depending on a number of factors including, for example, the level of security required, the desirability of having certain of the data in clear text for reporting, authentication, routing, etc., or to otherwise allow conformance with the transaction processing network.”; [0231], “In a step 448, the encrypted data is decrypted. For example, in this step, the data encrypted by encryption module 132 is decrypted to once again arrive at the originally encrypted token data that was read in step 442 (along with any clear text data that may have been on the token and read in step 442).”)
One of ordinary skill in the art would have recognized that applying the known technique of Mueller to the known invention of Reutov as modified would have yielded predictable results and resulted in an improved invention. It would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such tokenization features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the TES system to generate an ancillary detokenization request and an ancillary tokenization request results in an improved invention because applying said technique ensures that sensitive data corresponding to the initial token is protected, thus improving the overall security of the invention.
As per claims 26, 33, 40, Mueller teaches:
wherein the ancillary detokenization request comprises the initial token and the ancillary tokenization request comprises sensitive data corresponding to the initial token. ([0211]; [0231])
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
United States Patent Application Publication No. 20170213204 to Massoudi discloses an invention for reducing the losses associated with processing payments using credit card payment processing gateways. Payment processing gateways have different deposit success rates due to the gateways' varying arrangements with acquiring banks and the ability to process certain types of payments. A payment request related to a user may be received, wherein the request specifies a particular type of credit card, a transaction currency, and an amount. A payment application then routes, via a payment agent, the payment request to an adaptive gateway switching system (AGSS) in an attempt to complete a payment transaction. If in learning mode, the AGSS may randomly choose a payment processing gateway. Or the AGSS may choose the gateway based upon a learned gateway status based upon results learned through reinforcement learning. Upon receiving the result of a transaction attempt from the gateway, the agent reports the result to the AGSS. The result is used to update a reward function to inform future attempts to process payments. If the transaction attempt was unsuccessful, the AGSS provides an alternative gateway option for the agent to contact and attempt the transaction. This may continue until one of the following occurs: success; all gateways have been attempted; a predetermined number of gateways has been attempted; a predetermined penalty threshold has been exceeded; or another relevant criterion has been satisfied.
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 JAY HUANG whose telephone number is (408)918-9799. The examiner can normally be reached 9:00a - 5:30p PT.
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, Anita Coupe can be reached at (571) 270-3614. 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.
/JAY HUANG/Primary Examiner, Art Unit 3619
Prosecution Insights