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 .
Drawings
The drawings submitted on January 26, 2026 are objected to because:
In Fig. 1, elements and texts in the figure are illegible.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Continuation
This application is a continuation application of U.S. application no. 17/498,622 filed on October 11, 2021, now U.S. Patent 11,935,052, U.S. application no. 18/596,273 filed on March 05, 2024, now U.S. Patent 12,346,905, U.S. application no. 19/197,841 filed on May 6, 2026 no U.S. Patent 12,536,533. See MPEP §201.07. In accordance with MPEP §609.02 A. 2 and MPEP §2001.06(b) (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also in accordance with MPEP §2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicant(s) desire the information to be printed on a patent issuing from this application. See MPEP §609.02 A. 2.
Claim Interpretation
Intended use/ Result language
Regarding claim 1 and 11:
The phrase “to complete an asset transfer to transfer an asset from a source DLT-based client account of the plurality of DLT-based client accounts hosted through the distributed ledger to a destination DLT-based client account of the plurality of DLT-based client accounts hosted through the distributed ledger” is the intended use of the request received.
The phrase “to complete the asset transfer to transfer the asset from the source DLT-based client account hosted through the…” is the intended use of why the matching instruction is received.
The phrase “to transfer the asset from the source DLT-based client account to the destination DLT-based client account within the stored plurality of DLT-based client accounts” is the intended use of why instructions are generated. For example, applicant does not positively recite the steps of transferring an asset.
Regarding claims 10 and 20:
The phrase “wherein any external transfers originating at one of plurality of DLT client-based accounts are only permitted to be initiated by the distributed ledger technology application” is the intended use of the DLT application (e.g., the manner in which the system should be used e.g. the users of conventional accounts linked to DLT accounts are expected to use the DLT application for external transfers). Applicant is not positively reciting the step(s) of how external transfers from linked conventional accounts can only be initiated by the application and how it would reject other attempts. This phrase does not affect how the positively recited steps are performed nor does it provide an operational connection to the rest of the claim.
The applicant is reminded that these portions, i.e., intended use/result, do not further limit the scope of the claim as the limitations, or portions thereof, do not claim the functions as being positively recited actions or functions, and/or they do not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being "for ... [performing a specific functionality]", etc. does not mean that the functions are required to be performed, or are actually performed.
Non-Functional Language:
Regarding claims 1 and 11:
The phrase “with which client devices can route messages through the distributed ledger technology application” is non-functional descriptive material because it describes, at least in part, the first communication protocol.
Regarding claims 5 and 15:
The phrase “wherein the distributed ledger technology application is configured to require matching instructions for the asset transfer unless the second client device associated with second DLT-based client account of the asset transfer has previously specified a preference to accept incoming transfers if one or more conditions are met and the one or more conditions are met” is non-functional descriptive material that describes, at least in part, characteristics of the DLT application (e.g., what the DLT application is configured for).
It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Examiner has provided prior art, where available, for these intended use and/or non-functional phrases/limitations, however, these phrases/limitations will not distinguish the invention from the prior art in terms of patentability. Accordingly, the prior art is only provided in the interest of compact prosecution.
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 §§ 706.02(l)(1) - 706.02(l)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,536,533. Although the claims at issue are not identical, they are not patentably distinct from each other. In this instance, claim 1 of the ‘533 patent corresponds to claim 1 of the instant application. Independent claim 1 differs from claim 1 of the ‘533 patent, in part, because the instant claim does not positively recite a step of determining that an identification of the asset and identifiers of the source and identifiers of the destination in the transaction request match the matching instruction. Instead, the claims recites, generating the transfer instructions “responsive to determining…”. In contrast, claim 1 of the ‘533 patent expressly requires the distributed ledger technology application to perform the determining step (i.e.,” determining, by the distributed ledger technology application…”) before generating the transfer instructions, making the determining step a positively recited step.
It would have been obvious to a person of ordinary skill in the art to modify claims 1 and 11 of U.S. Patent No. 12,536,533 to achieve the recited functions and/or structure found in independent claims 1 and 11 of Application no. 19/460,108 (i.e., the instant application) because it is well settled that the omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karlson, 136 USPQ 184 (CCPA 1963). Also note Ex parte Rainu, 168 USPQ 375 (Bd. App. 1969). Omission of a reference element whose function is not needed would be obvious to one of ordinary skill in the art.
Dependent claims 2-10 and 12-20 corresponds to features found in claims 2-10 and 12-20 of the ’533 patent. Accordingly, claims 2-10 and 12-20 are not patentably distinct from claim 2-10 and 12-20 of the ‘533 patent.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20, are rejected under 35 U.S.C. 103 as being unpatentable over Fay et al. (US 2016/0292672 A1) hereinafter “Fay” in view of Arora et al. (US 2021/0158312 A1) hereinafter “Arora”.
Regarding claims 1 and 11: Fay disclose:
Claim 1: A method for seamlessly processing transactions using distributed ledger technology, comprising:
Claim 11: A system for seamlessly processing transactions using distributed ledger technology, the
system comprising:
an application server comprising a processor executing or hosting a distributed ledger technology (DLT) application, the processor configured to execute or host the distributed ledger technology application to:
establishing, by a distributed ledger technology (DLT) application executed or hosted by one or more processors, (i) a first connection with a first client device, using an address configured to be used in communication with [network interface] with which client devices can route messages through the distributed ledger technology application (ii) a second connection with a second client device using the routing address configured to be used in communication with [network interface] with which client devices can route messages through the distributed ledger technology application, and (iii) a third connection with one or more nodes hosting a distributed ledger via a second communication protocol; (See at least Fay, [0020]; [0023]; [0030 - 0033] where a DLT application executed on one processor (i.e., exchange computing system) establishing communication with first and second user devices (i.e., device A & B), and a third connection with one or more nodes hosting a distributed ledger (i.e., blockchain computing system include nodes)
storing, by the distributed ledger technology application, a plurality of DLT-based client
accounts hosted through the distributed ledger; (See at least Fay, [0022]; [0024]; [0036]; [0042]; [0073] Digital wallet 104 stores blockchain wallet information for users of user device 1 and user device 2 (and other clients or users that user the functionality provided by exchange computer system 100).
receiving, by the distributed ledger technology application from the first client device through the first connection and the first communication protocol, a transaction request to complete an asset transfer to transfer an asset from a source DLT-based client account of the plurality of DLT-based client accounts hosted through the distributed ledger to a destination DLT-based client account of the plurality of DLT-based client accounts hosted through the distributed ledger, the transaction request comprising; (See at least Fay, [0033-0036]; [0038]; [0040]; [0042]. The electronic data message includes a data transaction request for the exchange computer system 100 to carry out one or more tasks based on the content of the electronic data message. In certain examples, the data transaction request may be or include an order to "buy" or "sell" certain assets. The order may also include information that indicates the trading party (i.e., the trading party account on whose behalf the order is submitted); this information may be or include a reference to a particular digital wallet of the trading party)
receiving, by the distributed ledger technology application from the second client device through the second connection and the first communication protocol, a matching instruction to complete the asset transfer to transfer the asset from the source DLT-based client account hosted through the distributed ledger to the destination DLT-based client account hosted through the distributed ledger, and; (See at least Fay, [0044-0045]; For example, a new received order "A" that is of size 10 may be matched against two contra-side orders that are each of size 5. In certain examples, each of the three parties to the identified trade may construct and submit a blockchain traction to the blockchain for validation).
responsive to determining at least an identification of the asset in the transaction request and the matching instruction match, generating, by the distributed ledger technology application, instructions to transfer the asset from the source D LT-based client account to the destination DLT-based client account within the stored plurality of DLT-based client accounts; and (See at least Fay, [0045-0046]; In certain examples, the trade information includes an asset identifier and a quantity. The asset identifier and quantity may be included in the generated blockchain transaction. In certain example embodiments, the trade information may be associated with a unique identifier (a GUID) that is used to identify the trade that has been identified between A and B ( e.g., a trade identifier). This information may be used by the exchange computer system 100 to subsequently correlate ( e.g., as part of step 262) verified blockchain transactions to records stored by the exchange that the trade is pending or awaiting verification).
generating, by the distributed ledger technology application, an instruction to cause, over the established third connection and via the second communication protocol, the one or more nodes maintaining the distributed ledger to add a record of the asset transfer to the distributed ledger. (See at least t Fay, [0045] In certain example embodiments, the electronic exchange computer system 100 transmits additional information to each of computing device A 120B and computing device B 120B that may include, for example, pending trade information regarding the trade agreed to by the trading parties. The information that is transmitted to computing device A 120B and computing device B 120B may then cause the corresponding computing device to generate and submit a blockchain transaction based on the received information.)
Fay disclose transferring in a blockchain between device A and device B using account information and asset identifier. Additionally, Fay disclose; an electronic data message that includes a new data transaction request (also referred to as an order in this and other examples herein) is received by the exchange computer system 100 via network interface 108 from an order submitting client (e.g., user device 1 or user device 2). Fay, [0026]. However, Fay does not specifically disclose the use of a routing address of the distributed ledger application, the use of identifiers of source and destination accounts and using a common communication protocol.
Arora, on the other hand teaches the use of a routing address of the distributed ledger application, the use of identifiers of source and destination accounts and using a common communication protocol in a similar system for transferring assets between accounts. (See at least Arora, [0016]; [0027]; [0033]; The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some instances, the receiving device 202 may be configured to receive data from recipient devices 106, blockchain nodes 110, issuing institutions 114, payer devices 116, and other systems and entities via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks; In some configurations, transactions recorded in the blockchain may include a destination address and a currency amount, such that the blockchain records how much currency is attributable to a specific address. In some instances, the transactions are financial and others not financial, or might include additional or different information, such as a source address).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings on Arora into Fay’s system of ledger transactions. One of ordinary skill in the art would have been motivated to include such features in order to reducing fees and overall payment network traffic. (Arora, [0006])
The phrase “to complete an asset transfer to transfer an asset from a source DLT-based client account of the plurality of DLT-based client accounts hosted through the distributed ledger to a destination DLT-based client account of the plurality of DLT-based client accounts hosted through the distributed ledger” is the intended use of the request received.
The phrase “to complete the asset transfer to transfer the asset from the source DLT-based client account hosted through the…” is the intended use of why a matching instruction is received the matching instruction.
The phrase “to transfer the asset from the source D LT-based client account to the destination DLT-based client account within the stored plurality of DLT-based client accounts” is the intended use of why instructions are generated. For example, applicant does not positively recite the steps of transferring an asset.
The applicant is reminded that these portions, i.e., intended use/result, do not further limit the scope of the claim as the limitations, or portions thereof, do not claim the functions as being positively recited actions or functions, and/or they do not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being "for ... [performing a specific functionality]", etc. does not mean that the functions are required to be performed, or are actually performed.
The phrase “with which client devices can route messages through the distributed ledger technology application” is non-functional descriptive material because it describes, at least in part, the first communication protocol.
It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Examiner has provided prior art, where available, for these intended use and/or non-functional phrases/limitations, however, these phrases/limitations will not distinguish the invention from the prior art in terms of patentability. Accordingly, the prior art is only provided in the interest of compact prosecution.
Regarding claims 2 and 12: The combination of Fay and Arora disclose method of claim 1 and the system of claim 11. The combination further disclose; wherein a wallet owner of the source DLT-based client account is authorized to instruct a transferor/transferee account of a banking computing infrastructure and instructs the transferor/transferee account via the distributed ledger technology application. (See at least Arora, [0026-0027] The payer 112 may then submit a credit request to the processing server 102. The credit request may be submitted using any suitable communication network and method, such as via an application program executed by the payer device 116 that may use an application programming interface of the processing server 102. In some cases, the processing server 102 may notify the issuing institution 114 using the account identifier included in the credit request.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings on Arora into Fay’s system of ledger transactions. One of ordinary skill in the art would have been motivated to include such features in order to reducing fees and overall payment network traffic. (Arora, [0006])
Regarding claims 3 and 13: The combination of Fay and Arora disclose method of claim 1 and the system of claim 11. The combination further disclose; determining, by the distributed ledger application, one or more transaction conditions have been met; and executing, by the distributed ledger application, the asset transfer in response to the determination that the one or more transaction conditions have been met. (See at least Fay, [0044] match process may be run against orders in the order book. The matching
process identifies if there is a match between two or more orders in the order book. For example, a new received order "A" that is of size 10 may be matched against two contra-side orders that are each of size 5.)
Regarding claims 4 and 14: The combination of Fay and Arora disclose method of claim 3 and the system of claim 13. The combination further disclose comprising transmitting, by the distributed ledger technology application, debit or credit confirmations to each account involved in the asset transfer. (See at least Fay, [0045] each trading party (e.g., a computer device associated with users that corresponds to the trading parties) that a match has been identified and a trade will/is going to take place. This information may then cause (e.g., by using application software installed on the corresponding device) the client computer system ( or other computer system) to generate and submit a blockchain transaction to the blockchain based on the received information. The notification includes details of the trade or transaction that is to be recorded (e.g., where one transaction represents a transaction from A to B, another transaction represents a transaction from B to A, and a trade is a collection or group of transactions, such as, B sends A quantity X of an asset and A sends B digital currency or another asset).
Regarding claims 5 and 15: The combination of Fay and Arora disclose method of claim 1 and the system of claim 11. However, the combination does not specifically disclose wherein the distributed ledger technology application is configured to require matching instructions for the asset transfer unless the second client device associated with second DLT-based client account of the asset transfer has previously specified a preference to accept incoming transfers if one or more conditions are met and the one or more conditions are met. However, this difference is only found in the non-functional descriptive material that describes, at least in part, characteristics of the DLT application (e.g., what the DLT application is configured for). It has been held the nonfunctional descriptive material will not distinguish the invention from the prior art in term of patentability.
Regarding claims 6 and 16: The combination of Fay and Arora disclose method of claim 1 and the system of claim 11. The combination further disclose; wherein a wallet owner of the source DLT-based client account is authorized to instruct a transferor/transferee account and instructs the transferor/transferee account via the distributed ledger technology application. (See at least Arora, [0026-0027] The payer 112 may then submit a credit request to the processing server 102. The credit request may be submitted using any suitable communication network and method, such as via an application program executed by the payer device 116 that may use an application programming interface of the processing server 102. In some cases, the processing server 102 may notify the issuing institution 114 using the account identifier included in the credit request.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings on Arora into Fay’s system of ledger transactions. One of ordinary skill in the art would have been motivated to include such features in order to reducing fees and overall payment network traffic. (Arora, [0006])
Regarding claims 7 and 17: The combination of Fay and Arora disclose method of claim 1 and the system of claim 11. The combination further disclose; receiving, by the distributed ledger technology application, a message initiating the asset transfer from the first client device via the first communication protocol; and transmitting, by the distributed ledger technology application, subsequent messages with the first client device or the second client device via the second communication protocol. (See at least Arora, [0007]; [0032]; [0036]; [0051]; [0059]) In step 414, a notification message may be transmitted by a transmitter (e.g., the transmitting device 224) of the processing server to an issuing financial institution ( e.g., an issuing institution 114) associated with the payer identifier included in the selected credit value, the notification message including at least the debit amount. In step 416, an updated balance data value may be generated by the processor of the processing server, the updated data balance value including at least the account identifier and an updated balance, the updated balance being based on the current balance, the credit amount included in the two or more credit values, and the debit amount.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings on Arora into Fay’s system of ledger transactions. One of ordinary skill in the art would have been motivated to include such features in order to reducing fees and overall payment network traffic. (Arora, [0006])
Regarding claims 8 and 18: The combination of Fay and Arora disclose method of claim 1 and the system of claim 11. The combination further disclose; updating, by the distributed ledger technology application, the distributed ledger as an intermediate step while exchanging a sequence of messages to execute the asset transfer. (See at least Arora, [0042] The transmitting device 224 may be configured to electronically transmit data signals to recipient devices 106, which may be superimposed or otherwise encoded with balance update notifications.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings on Arora into Fay’s system of ledger transactions. One of ordinary skill in the art would have been motivated to include such features in order to reducing fees and overall payment network traffic. (Arora, [0006])
Regarding claims 9 and 19: The combination of Fay and Arora disclose method of claim 1 and the system of claim 11. The combination further disclose; exchanging, by the distributed ledger technology application, a sequence of messages with one or more financial institutions via the first communication protocol. (See at least Arora, [0007]; [0032]; [0036]; [0051]; [0059])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings on Arora into Fay’s system of ledger transactions. One of ordinary skill in the art would have been motivated to include such features in order to reducing fees and overall payment network traffic. (Arora, [0006])
Regarding claims 10 and 20: The combination of Fay and Arora disclose method of claim 1 and the system of claim 11. However, the combination does not specifically disclose; wherein any external transfers originating at one of plurality of DLT client-based accounts are only permitted to be initiated by the distributed ledger technology application. However, this is found as the intended use of the DLT application (e.g., the manner in which the system should be used e.g. the users of conventional accounts linked to DLT accounts are expected to use the DLT application for external transfers). Applicant is not positively reciting the step(s) of how external transfers from linked conventional accounts can only be initiated by the application and how it would reject other attempts. This phrase does not affect how the positively recited steps are performed nor does it provide an operational connection to the rest of the claim.
The applicant is reminded that these portions, i.e., intended use/result, do not further limit the scope of the claim as the limitations, or portions thereof, do not claim the functions as being positively recited actions or functions, and/or they do not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being "for ... [performing a specific functionality]", etc. does not mean that the functions are required to be performed, or are actually performed.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Karame (US 20180025435 A1): Embodiments of the present invention provide the following advantages and advancements over known systems: [0063] Using different consensus layers and access scopes to increase privacy and reduce the number of transactions in the network and in the ledgers, [0064] Creating and interconnecting a large set of participants using small and fast private interconnected ledgers, [0065] Combining the use of tokens, or unspent transactions, with the smart contract account model to decrease the number of effective payment transactions to fulfill interbank payments and allow the transfer of assets from one private ledger to another, [0066] Using a REPLY message with f+1 merged signatures from an EBFT consensus protocol as a finality proof of transactions, [0067] Relying on a Byzantine fault tolerant system coupled with trusted computing anchors in order to reduce the communication rounds and thus increase the system performance, [0068] Increasing the robustness of the banking system with a distributed ledge, [0069] Increasing the scalability of Byzantine fault tolerant consensus protocols by creating small, but interconnected private ledgers which individually can be effectively handled, for example, by EBFT consensus protocols (which, for example, could otherwise be limited to around 10-20 nodes for a ledger), [0070] Decreasing the load of transaction messages in the system using private ledgers, and facilitating cross-ledger transactions, [0071] Enabling the central bank CB to publish/enforce financial regulations on all interbank transactions in a flexible manner, and/or [0072] Decreasing the number of necessary transactions to resolve a settlement, thereby resulting in reduced transaction fees. [0062].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARLYANNIE M GARCIA whose telephone number is (571)272-6950. The examiner can normally be reached Monday - Friday 7:30am - 4:30-pm.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/K.G.M/Examiner, Art Unit 3698
/EDUARDO CASTILHO/Primary Examiner, Art Unit 3698
Prosecution Insights