DETAILED ACTION Claims 1-20 are pending in this application. 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. 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. Claim s 1-4, 8, 12, 16 , 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2009 / 0288012 A1 to Hertel et al. in view of U.S. Pat. No. 11,526,943 B1 issued to Donnelly et al. As to claim 1, Hertel teaches a method comprising: receiving, by a first computing platform of a system ( T ransaction A uthority 102 ) a first request ( I nstruction 112 ) for execution of a first transaction from a first client device ( B uyer E lectronic W allet 7 /U ser C omputer 100 ) , the first computing platform including a transaction service (“… FIG. 10 illustrates one embodiment of a configuration for initiating and conducting a transaction between a buyer and a seller in which transaction identification information flows in the opposite direction from the direction described in FIG. 1d. In this example case, a buyer has selected one or more goods or services for purchase. The buyer electronic wallet 7 on the user computer 100 transmits an instruction 112 over the communication channel 105 to the transaction authority 102 to register a pending transaction. The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100. The electronic wallet 7 on the user computer 100 transmits over communication channel 103 a message 114 containing the transaction identifier to the seller system 101 …” paragraph 0128) ; receiving, by the first computing platform, a second request ( M essage 115 ) for execution of the first transaction, from a second client device ( S eller S ystem 101 ) (“… The seller system 101 then transmits a message 115 containing the transaction identifier, details of the pending transaction and terms and conditions of the selected one or more goods or services to the transaction authority 102. The transaction system matches the transaction identifier with the pending transaction and associates the details, terms and conditions with the pending transaction. The transaction authority 102 transmits over communication channel a message 116 containing the details of the transaction and terms and conditions of the pending transaction to the electronic wallet 7 of the user computer 100 105 …” paragraph 0129) ; and determining, based on an execution status of the first transaction ( transaction identifier ) , whether to associate a result ( pending transaction ) of the first transaction with the second request ( The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100 ) (“… FIG. 10 illustrates one embodiment of a configuration for initiating and conducting a transaction between a buyer and a seller in which transaction identification information flows in the opposite direction from the direction described in FIG. 1d. In this example case, a buyer has selected one or more goods or services for purchase. The buyer electronic wallet 7 on the user computer 100 transmits an instruction 112 over the communication channel 105 to the transaction authority 102 to register a pending transaction. The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100. The electronic wallet 7 on the user computer 100 transmits over communication channel 103 a message 114 containing the transaction identifier to the seller system 101 … The seller system 101 then transmits a message 115 containing the transaction identifier, details of the pending transaction and terms and conditions of the selected one or more goods or services to the transaction authority 102. The transaction system matches the transaction identifier with the pending transaction and associates the details, terms and conditions with the pending transaction. The transaction authority 102 transmits over communication channel a message 116 containing the details of the transaction and terms and conditions of the pending transaction to the electronic wallet 7 of the user computer 100 105 … At this point the transaction proceeds between electronic wallet 7 on the user computer 100 and transaction authority 102 over communication channel 105 separate from the seller system 101. When transaction authority 102 determines that the electronic wallet 7 on the user system 100 has fulfilled the terms and conditions of the pending transaction, the transaction authority 102 transfers resources from one or more buyer accounts to one or more seller accounts. The transaction authority 102 also provides separate confirmations of the transfer of resources to electronic wallet 7 of the user computer 100 and seller system 101 over the respective communication channel 105, 104. Other details optionally can be provided that correspond to the transaction, for example shipping details provided by the buyer. The seller then provides the goods or services to according to the terms and conditions of the transaction …” paragraphs 0128-0130). Hertel is silent with reference to queuing, by the transaction service, the first request and the second request . Donnelly teaches queuing ( M atching Q ueue 130 ) , by the transaction service, the first request ( T ransaction A ) and the second request ( Transaction B ) (“… The matching queue 130 represents a simplified view of such a queue, including a transaction identifier (ID), a delayed field to indicate whether the given transaction request is delayed, and a metric (e.g., value) used to sort transactions in the matching queue 130. In the illustrated example, the value field orders the transactions. Thus, if transaction A were not delayed, as illustrated in entry 135 (e.g., record), transaction A would be matched, and thus completed, before transaction B, illustrated in entry 140. However, when transaction A is delayed, as illustrated in entry 145, the value field for entry 145 is modified to sort lower in the matching queue 130. Thus, the entry 145—the delayed transaction A—sorts lower than the entry 140 for transaction B, resulting in transaction A being matched after transaction B …” Col. 3 Ln. 33-51). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel with the teaching of Donnelly because the teaching of Donnelly would improve the system of Hertel by providing a queue data structure for storing and managing data in a specific order. As to clam 2 , Hertel teaches t he method of claim 1, further comprising associating the result of the first transaction with the second request based on the execution status of the first transaction being that the first transaction is currently executing ( The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100 ) (“… FIG. 10 illustrates one embodiment of a configuration for initiating and conducting a transaction between a buyer and a seller in which transaction identification information flows in the opposite direction from the direction described in FIG. 1d. In this example case, a buyer has selected one or more goods or services for purchase. The buyer electronic wallet 7 on the user computer 100 transmits an instruction 112 over the communication channel 105 to the transaction authority 102 to register a pending transaction. The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100. The electronic wallet 7 on the user computer 100 transmits over communication channel 103 a message 114 containing the transaction identifier to the seller system 101…The seller system 101 then transmits a message 115 containing the transaction identifier, details of the pending transaction and terms and conditions of the selected one or more goods or services to the transaction authority 102. The transaction system matches the transaction identifier with the pending transaction and associates the details, terms and conditions with the pending transaction. The transaction authority 102 transmits over communication channel a message 116 containing the details of the transaction and terms and conditions of the pending transaction to the electronic wallet 7 of the user computer 100 105…At this point the transaction proceeds between electronic wallet 7 on the user computer 100 and transaction authority 102 over communication channel 105 separate from the seller system 101. When transaction authority 102 determines that the electronic wallet 7 on the user system 100 has fulfilled the terms and conditions of the pending transaction, the transaction authority 102 transfers resources from one or more buyer accounts to one or more seller accounts. The transaction authority 102 also provides separate confirmations of the transfer of resources to electronic wallet 7 of the user computer 100 and seller system 101 over the respective communication channel 105, 104. Other details optionally can be provided that correspond to the transaction, for example shipping details provided by the buyer. The seller then provides the goods or services to according to the terms and conditions of the transaction …” paragraphs 0128-0130). As to claim 3 , Hertel teaches t he method of claim 2, further comprising sending the result of the first transaction to the first client device and the second client device (“… The transaction authority 102 transmits over communication channel a message 116 containing the details of the transaction and terms and conditions of the pending transaction to the electronic wallet 7 of the user computer 100 105 …” paragraph 0129). As to claim 4 , Hertel teaches t he method of claim 1, further comprising: executing the second request using a second transaction based on determining not to associate the result of the first transaction with the second request ( step fails ) (“… If at any time during the initialization of any of these transaction configurations a step fails, for example one party uses the conveyed transaction identifier with the transaction authority, but the authority has no record of the transaction, or the transaction is not in the correct pending state, or there are some other conditions on the transaction which cannot be met such as the transaction violating the conditions of parental controls put in place by the guardian of a user who is a minor, then the violations are stored at the transaction authority 102 for security and debugging purposes and appropriate messages are sent to the parties. If the failure occurs after the user has applied some payment instruments, the failure rolls back their application … ” paragraph 0148 ). As to claim 8 , Hertel teaches t he method of claim 1, further comprising: determining that the first transaction is queued as a pending transaction by the transaction service; and attaching the second request to the pending transaction ( The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100 ) (“… FIG. 10 illustrates one embodiment of a configuration for initiating and conducting a transaction between a buyer and a seller in which transaction identification information flows in the opposite direction from the direction described in FIG. 1d. In this example case, a buyer has selected one or more goods or services for purchase. The buyer electronic wallet 7 on the user computer 100 transmits an instruction 112 over the communication channel 105 to the transaction authority 102 to register a pending transaction. The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100. The electronic wallet 7 on the user computer 100 transmits over communication channel 103 a message 114 containing the transaction identifier to the seller system 101…The seller system 101 then transmits a message 115 containing the transaction identifier, details of the pending transaction and terms and conditions of the selected one or more goods or services to the transaction authority 102. The transaction system matches the transaction identifier with the pending transaction and associates the details, terms and conditions with the pending transaction. The transaction authority 102 transmits over communication channel a message 116 containing the details of the transaction and terms and conditions of the pending transaction to the electronic wallet 7 of the user computer 100 105…At this point the transaction proceeds between electronic wallet 7 on the user computer 100 and transaction authority 102 over communication channel 105 separate from the seller system 101. When transaction authority 102 determines that the electronic wallet 7 on the user system 100 has fulfilled the terms and conditions of the pending transaction, the transaction authority 102 transfers resources from one or more buyer accounts to one or more seller accounts. The transaction authority 102 also provides separate confirmations of the transfer of resources to electronic wallet 7 of the user computer 100 and seller system 101 over the respective communication channel 105, 104. Other details optionally can be provided that correspond to the transaction, for example shipping details provided by the buyer. The seller then provides the goods or services to according to the terms and conditions of the transaction …” paragraphs 0128-0130). As to claims 12 and 17, see the rejection of claim 1 above, expect for a processing device, memory and a computer program product comprising a computer readable storage medium. Hertel teaches a processing device ( Processor 2 ) , memory ( Memory 6 ) and a computer program product comprising a computer readable storage medium ( Storage Device 8 ) . As to claims 16 and 20, see the rejection of claim 8 above. Claim s 5, 6, 13, 14, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2009 / 0288012 A1 to Hertel et al. in view of U.S. Pat. No. 11,526,943 B1 issued to Donnelly et al. as applied to claims 1 . 12 and 1 7 above, and further in view of U.S. Pub. No. 2006 / 0080394 A1 to Goodman et al. As to claim 5 , Hertel as modified by Donnelly teaches t he method of claim 1, however it is silent with reference to routing, by the transaction service, a callback request associated with the first transaction to the first computing platform. Goodman teaches routing, by the transaction service ( server ), a callback request ( Requesting 103 /Callback Request 313 ) associated with the first transaction to the first computing platform ( Database/Disk 411 ) (“… FIG. 1 illustrates a flow diagram for a method of enabling asynchronous callback and broadcast notification between a server and a client software application in a web services network, in accordance with an embodiment of the invention. The method illustrated in FIG. 1 comprises processing (101) computer logic instructions in the network; requesting (103), by the client software application, a notification of a completion of the processing of the computer logic instructions; storing (105) the notification request in a registry; queuing (107) the notification request according to a response to the notification request and a list of system endpoints requesting the notification of a completion of the processing of the computer logic instructions; and notifying (109) a recipient system of the completion of the processing of the computer logic instructions upon execution of the queued notification request… The notification comprises a callback request, and wherein the recipient system comprises the client software application corresponding with the system endpoints. The requesting process (103) comprises sending the notification request to the server; identifying a system endpoint requiring notification of completion of the processing of the computer logic instructions; specifying computer logic instructions requiring notification for an identified system endpoint; generating a message of the specific computer logic instructions requiring notification; and sending the message to a register notification interface. In the identifying process, the system endpoint comprises a target Uniform Resource Identifier (URI)… A system running a callback has to know where to send the initial callback request to and where the callback event will be sent when and if the event occurs. Having identified the endpoints, the local application must identify (303) which events it requires notification of. Moreover, if this callback is in response to a message, it is possible that the message is submitting data for processing. Thereafter, an XML message is generated (305) representing the endpoints and the events that are required to complete the callback. The XML message format may be SOAP. The message is then sent (307) to the register callback interface (not shown). The bottom part of FIG. 3 shows that a client or another client is waiting (i.e., listening) (311) for callbacks of message events 309. The processing (313) of the callback request is further illustrated in FIG. 4…The flow process illustrated in FIG. 4 reads from left to right and from top to bottom. The callback request process begins with receiving (313) the callback request (from FIG. 3), which correspondingly identifies (303) events for notification, which identifies (301) the endpoints. This validates the message inputs and stores the information into persistent storage of a database/disk 411 … ” paragraphs 0034/0035). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel and Donnelly with the teaching of Goodman because the teaching of Goodman would improve the system of Hertel and Donnelly Hertel by providing a programming pattern in which a function reference is passed from one context (consumer) to another (provider) such that the provider can call the function . As to claim 6 , Hertel as modified by Donnelly teaches the method of claim 5, however it is silent with reference to sending, by a callback service of the first computing platform, a callback notification to one or more of the first client device or the second client device responsive to receiving the callback request. Goodman teaches sending, by a callback service of the first computing platform, a callback notification ( Notifying (109) /Message Events 309 ) to one or more of the first client device or the second client device responsive to receiving the callback request (“… and notifying (109) a recipient system of the completion of the processing of the computer logic instructions upon execution of the queued notification request… The bottom part of FIG. 3 shows that a client or another client is waiting (i.e., listening) (311) for callbacks of message events 309. The processing (313) of the callback request is further illustrated in FIG. 4 … ” paragraphs 0034 /0042 ). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel and Donnelly with the teaching of Goodman because the teaching of Goodman would improve the system of Hertel and Donnelly Hertel by providing a programming pattern in which a function reference is passed from one context (consumer) to another (provider) such that the provider can call the function . As to claims 13 and 18, see the rejection of claim 5 above. As to claims 14 and 1 9 , see the rejection of claim 6 above. Claim s 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2009 / 0288012 A1 to Hertel et al. in view of U.S. Pat. No. 11,526,943 B1 issued to Donnelly et al. as applied to claims 1 and 12 above, and further in view of U.S. Pub. No. 2015 / 0309837 A1 to Shen et al. As to claim 7 , Hertel as modified by Donnelly teaches the method of claim 6, however it is silent with reference to wherein the callback service resides in middleware of the first computing platform. Shen teaches wherein the callback service ( User Callback 110) resides in middleware ( Tuxedo ) of the first computing platform (“… Alternatively, the transaction server 103 can dynamically register the user callback 110, e.g. based on a shared library 105 associated with the data source 102. For example, Tuxedo can dynamically register the callback when a user connects to an Oracle Database using a non-XA server (e.g. via OCI or Pro*c/c++). Tuxedo can first load Oracle OCI library OCI API dynamically and obtain the related OCI environment handle. Then, Tuxedo can register a user callback via an OCIUserCallbackRegister in the OCISessionBegin function ….” Paragraph 0041). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel and Donnelly with the teaching of Shen because the teaching of Shen would improve the system of Hertel and Donnelly Hertel by providing a robust, enterprise-class middleware platform designed for managing distributed transaction processing (TP) and developing high-performance, scalable, mission-critical applications . As to claim 15, see the rejection of claim 7 above. Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2009 / 0288012 A1 to Hertel et al. in view of U.S. Pat. No. 11,526,943 B1 issued to Donnelly et al. as applied to claims 1 and 12 above, and further in view of C . N . No. 103843290 A Shi et al. As to claim 9 , Hertel as modified by Donnelly teaches the method of claim 1, however it is silent with reference to wherein the transaction service resides in middleware of the first computing platform. Shi teaches wherein the transaction service ( T ransaction S ervice 110 ) resides in middleware ( Tuxedo ) of the first computing platform (“… Picture 1 according to one embodiment of the present invention showing the support different message queue in a transactional middleware machine environment. As shown in FIG. 1, the transaction server 106 may be the notification table 101 (such as Tuxedo in the bulletin) publishing one or more transaction service 110. notification table adapted to be executed by one or more client terminal 104 and 105 used to locate transaction service provided by the server … Picture 6 is according to one embodiment of the present invention, instructions are for supporting different message queue structure of frame of the transaction server 610 in a transactional middleware machine environment. transaction server 610 blocks can be realized by hardware, software or a combination of hardware and software to perform the principles of the present invention. Those skilled in the art should understand, FIG. 6 described in the blocks may be combined or separated into sub block to realize the above principle of the present invention. Therefore, the description herein may support any possible combination or separation of the functional block or further defined …” paragraph 0021/0039). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel and Donnelly with the teaching of Sh i because the teaching of Sh i would improve the system of Hertel and Donnelly Hertel by providing a robust, enterprise-class middleware platform designed for managing distributed transaction processing (TP) and developing high-performance, scalable, mission-critical applications . Claim s 10 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2009 / 0288012 A1 to Hertel et al. in view of U.S. Pat. No. 11,526,943 B1 issued to Donnelly et al. as applied to claim 1 above, and further in view of U.S. Pub. No. 2023 / 0153826 A1 to Srivastava et al. As to claim 10 , Hertel as modified by Donnelly teaches the of claim 1, however it is silent with reference to wherein the first transaction comprises a configuration management transaction for the first computing platform. Srivastava teaches wherein the first transaction comprises a configuration management transaction for the first computing platform ( Configuration Interface 660) (“… FIG. 8 depicts a flowchart illustrating an example method 800 to dynamically reconfigure a transaction exchange platform, such as transaction exchange platform 320. Method 800 may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method 800 … At step 805, the configuration interface 660 may generate a configuration transaction object. The configuration transaction object may be configured to cause a reconfiguration of the transaction exchange platform, one or more workflows, one or more microservices, and/or one or more transactions. The configuration interface 660 may receive a request to generate the configuration transaction object from a user and/or other system processes, such as a watchdog microservice (discussed further below with respect to FIG. 9). The configuration transaction object may comprise transaction details and transaction metadata. The transaction metadata may indicate that the transaction object has a configuration workflow type and a current workflow stage of the configuration transaction object. In some embodiments, the workflow type of the configuration transaction object is a workflow that is modified by the configuration transaction object, and other aspects of the configuration transaction object indicate to a processing microservice that it includes an update to the processing of the microservice. The configuration transaction object may include instructions that, when processed by the microservice, cause the microservice to be reconfigured. Reconfiguration may include modifying which workflow/version/stage the microservice looks for on the SDP, and/or may include modifying the core processing logic employed by the microservice … At step 810, the configuration interface 660 may add the configuration transaction object to the SDP, where it may await processing by first microservice 820 and second microservice 830 … The configuration transaction object may be picked up by first microservice 820 and second microservice 830 in a similar fashion to that described above with respect to FIG. 5. At steps 821 and 831, first and second microservices 820 and 830 may poll the SDP to retrieve transactions matching their assigned workflow stages in corresponding workflow types. The configuration transaction objects may have a configuration workflow type, and the microservices may watch for a configuration workflow type object having the workflow stage corresponding to the microservice. At steps 823 and 833, the microservices may retrieve the configuration transaction object for processing …” paragraphs 0121-0123). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel and Donnelly with the teaching of Srivastava because the teaching of Srivastava would improve the system of Hertel and Donnelly Hertel by providing a method to dynamically reconfigure a transaction exchange platform to allow for automatic reconfiguration of the transaction exchange platform . As to claim 11 , Hertel as modified by Donnelly teaches the method of claim 10, however it is silent with reference to wherein the configuration management transaction includes a configuration change for the first computing platform. Srivastava teaches wherein the configuration management transaction includes a configuration change for the first computing platform ( Configuration Interface 660) (“… FIG. 8 depicts a flowchart illustrating an example method 800 to dynamically reconfigure a transaction exchange platform, such as transaction exchange platform 320. Method 800 may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method 800 … At step 805, the configuration interface 660 may generate a configuration transaction object. The configuration transaction object may be configured to cause a reconfiguration of the transaction exchange platform, one or more workflows, one or more microservices, and/or one or more transactions. The configuration interface 660 may receive a request to generate the configuration transaction object from a user and/or other system processes, such as a watchdog microservice (discussed further below with respect to FIG. 9). The configuration transaction object may comprise transaction details and transaction metadata. The transaction metadata may indicate that the transaction object has a configuration workflow type and a current workflow stage of the configuration transaction object. In some embodiments, the workflow type of the configuration transaction object is a workflow that is modified by the configuration transaction object, and other aspects of the configuration transaction object indicate to a processing microservice that it includes an update to the processing of the microservice. The configuration transaction object may include instructions that, when processed by the microservice, cause the microservice to be reconfigured. Reconfiguration may include modifying which workflow/version/stage the microservice looks for on the SDP, and/or may include modifying the core processing logic employed by the microservice…At step 810, the configuration interface 660 may add the configuration transaction object to the SDP, where it may await processing by first microservice 820 and second microservice 830…The configuration transaction object may be picked up by first microservice 820 and second microservice 830 in a similar fashion to that described above with respect to FIG. 5. At steps 821 and 831, first and second microservices 820 and 830 may poll the SDP to retrieve transactions matching their assigned workflow stages in corresponding workflow types. The configuration transaction objects may have a configuration workflow type, and the microservices may watch for a configuration workflow type object having the workflow stage corresponding to the microservice. At steps 823 and 833, the microservices may retrieve the configuration transaction object for processing …” paragraphs 0121-0123). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel and Donnelly with the teaching of Srivastava because the teaching of Srivastava would improve the system of Hertel and Donnelly Hertel by providing a method to dynamically reconfigure a transaction exchange platform to allow for automatic reconfiguration of the transaction exchange platform. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. U.S. Pub. No. 20190005582 A1 to Kapur et al. and directed to an optimization processor in a data transaction processing system receives an electronic data multiple transaction request message including multiple electronic data transaction requests, and determines whether some of the electronic data transaction requests should be routed through or bypass transaction integrity modules designed to detect and mitigate undesirable object conditions. U.S. Pub. No. 2021 / 0365935 A1 to Tripathy et al. and directed to mechanisms and methods for facilitating prevention of duplicate transactions across multiple transaction entities in database systems . U.S. Pub. No. 2018/0315104 A1 Golubovsky et al. and directed to a method for routing received data transaction requests from a first computer system to a second computer system for processing thereon. U . S . Pub. No. 2004 / 0158549 A1 to Matena et al. and directed to m ethod and apparatus for online transaction processing . Any inquiry concerning this communication or earlier communications from the examiner should be directed to FILLIN "Examiner name" \* MERGEFORMAT CHARLES E ANYA whose telephone number is FILLIN "Phone number" \* MERGEFORMAT (571)272-3757 . The examiner can normally be reached FILLIN "Work Schedule?" \* MERGEFORMAT Mon-Fir. 9-6pm . 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, FILLIN "SPE Name?" \* MERGEFORMAT KEVIN YOUNG can be reached at FILLIN "SPE Phone?" \* MERGEFORMAT 571-270-3180 . 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. /CHARLES E ANYA/ Primary Examiner, Art Unit 2194