Acknowledgements
This communication is in response to applicant’s response filed on 01/16/2026.
Claims 1, 3, 6-7, 12-13, 15, and 18-19 have been amended. Claims 2, 5, 14, and 17 have been cancelled.
Claims 1, 3-4, 6-13, 15-16, and 18-20 are pending and have been examined.
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
Regarding applicant’s arguments:
Applicant’s arguments, see pgs. 9-14, filed 01/16/2026, with respect to the rejection(s) of claims 1, 3-4, 6-13, 15-16, and 18-20 under Claim Rejections - 35 USC § 101 that the independent claims 1, 13, and 19 recite features that integrate the judicial exception into a practical application, have been fully considered and are persuasive. Therefore, the Claim Rejections - 35 USC § 101 rejection has been withdrawn.
Applicant’s arguments, see pgs. 14-16, filed 01/16/2026, with respect to the rejection(s) of claims 1, 13, and 19 under Claim Rejections - 35 USC § 102(a)(1) that Cervenka does not teach “automatically executing a blockchain network transfer of a first amount of one or more crypto tokens…based at least in part on the net change and satisfying the threshold percentage associated with the rebalancing rule,” in which the “rebalancing rule specifies that a first blockchain address associated with the first segregated entity is to hold at least a threshold percentage of an aggregated token amount attributed to the first plurality of user profiles associated with the first segregated entity,” have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is in view of Schorr (US 20240232869).
Claim Rejections - 35 USC § 102(a)(1)
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 3-4, 8-13, 15-16, and 19-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Schorr (US 20240232869).
Regarding Claims 1, 13, and 19, Schorr teaches monitoring a plurality of actions by a first plurality of user profiles at a custodial token platform based at least in part on the first plurality of user profiles being associated with a first segregated entity for which a rebalancing rule is configured (Paragraphs 0194, 0200, and 0205-0206 teach the processing, storage, networking and communications equipment performs functions including custody services that include execution of transactions, e.g., currency transaction(s) or token transaction(s), on behalf of account(s), including consumers, or on behalf of token buyer or token account(s); custody services may also include updating the blockchain ledger, distributed node(s), or other accounting of Transactions, in response to receiving a request to initiate a Transaction; the reserve platform includes a blockchain, security services, custody, and account management; the blockchain may be blockchain ledger or distributed node(s); the custody may be custody services; custody may include execution of Transactions, e.g., currency Transaction(s) or token Transaction(s), on behalf of account(s), including consumers, or on behalf of token buyer or token account(s); custody may also include updating the blockchain, blockchain ledger, distributed node(s), or other accounting of Transactions, in response to receiving a request to initiate a Transaction; account management may include fund intake, conversion, and/or reconversion; account management may also include reporting token ownership and dynamic token value on behalf of token buyer, consumers, or other stakeholders transacting with the central entity; the Reserve platform executes one or more of these operations through exchange system(s); a central entity stores respective quantities for a plurality of instruments; the respective quantities may be stored in storage equipment, token basket, processing, storage, networking and communications equipment, data source(s), or any combination thereof; each of the plurality of instruments may compose a token, e.g., token; the instruments of the plurality of instruments may be traded on crypto exchanges, foreign exchanges, commodity exchanges, market exchange(s), or any combination thereof; the central entity receives information about the plurality of instruments), wherein the rebalancing rule specifies that a first blockchain address associated with the first segregated entity is to hold at least a threshold percentage of an aggregated token amount attributed to the first plurality of user profiles associated with the first segregated entity, the threshold percentage of the aggregated token amount based at least in part on one or more rules specified for one or more entities associated with a geographic location, wherein the one or more entities comprise at least the first segregated entity (Paragraphs 0126, 0132-0133, 0135, and 0256-0257 teach a buyer can Exchange different financial instruments (e.g., US Dollars, Gold, Silver, Euros, Norwegian Krona, Swiss Francs, Australian Dollars, Singapore Dollars, British Pounds, other global currencies, asset-backed cryptocurrencies, or commodities) to purchase tokens created by the central entity and collateralized by Reserves held therein; the tokens may be transparently and dynamically valued based on an underlying basket of financial instruments; the basket can be rebalanced by the central entity at any time for any number of reasons, e.g., to protect against devaluations or quantitative easing by governments, to hedge against inflation, to stabilize the security of the central entity and tokens held therein, or for other reasons; reserves, transaction fees and processing fees can be stored to provide liquidity to ensure orderly conversions and reliable ownership; Reserve Requirement: in some embodiments, each unique type of token will be associated with a pre-designated “Reserve Requirement,” which is the pre-designated minimum Reserve assets that is required to be held in order to, among other functions, collateralize the central entity's obligations with respect to that token; one or more third-party stakeholders hold some or all of the Reserve assets; the Reserve Requirement for any given unique type of token may mandate that a predesignated percentage number (a “Reserve Percentage”) be applied to determine the number (or fractional number) of units of that token's Underlying Assets that must be held in Reserve; if, for example, the Reserve Requirement for any given unique type of token were to mandate a fixed Reserve Percentage of 25%, and that token's Asset Mix were to be as set forth above, then a minimum of 25 US Dollars (25% of 100 US Dollars), 16 Euros (25% of 64 Euros), and 0.011 ounces of Gold (25% of 0.044 ounces of Gold) would need to be held in Reserve, among other things, to collateralize the central entity's obligations with respect to that token; the Reserve Requirement may dynamically update according to real-time information from the multiple global market exchanges and real-time information regarding the token value and quantity of outstanding issued tokens, among other information; the Reserve Percentage may be 100%; different Reserve Percentages may also be applied to each Underlying Asset within the Asset Mix; the Reserve Requirement were to vary for each Underlying Asset within the Asset Mix as set forth above, a Reserve Percentage of 30% may be applied to the US Dollars, a Reserve Percentage of 17.5% may be applied to the Euros, and a Reserve Percentage of 5% may be applied to the Gold; each Unique Token may be associated with one or more third-party stakeholders acting as authorized custodial parties who are responsible for holding the Reserve Requirement assets collateralizing the Unique Token; for example, concurrent with a token Issuance, the custodial party may be a financial institution that is defined in the ledger and responsible for facilitating the token Issuance such as by issuing tokens to customers, purchasing collateral assets satisfying a Reserve Requirement, maintaining Transaction and reference numbers, and more; in some embodiments, a third-party stakeholder (e.g., acting as an authorized custodial party) may be a Reserve custodial party, the Reserve custodial party holds one or more sets of Reserves corresponding to each Reserve Requirement for each Unique Token held by the Reserve custodial party; in some embodiments, the Reserve custodial party holds one or more sets of Reserves corresponding to one or more Unique Tokens owned by a single Unique Token holder); determining, based at least in part on the rebalancing rule, a net change in token amounts attributed to the first plurality of user profiles associated with the first segregated entity during a first duration of time (Paragraphs 0031, 0048, 0201, and 0207-0208 teach the processing circuitry causes a change of the respective quantities of the plurality of instruments and, in response to changing the respective quantities of the plurality of instruments, causes an automatic change of the reserve assets collateralizing the token; the updated information received for a plurality of instruments causes a change of the respective quantities of the plurality of instruments and, in response to changing the respective quantities of the plurality of instruments, causes an automatic change of the reserve assets collateralizing the token; the token includes digital currency development and a cryptocurrency exchange; the digital currency development may include determining, rebalancing, or modifying the Asset Mix, Underlying Asset(s), Asset Pair, Exchange Pair, Fees, Reserve Requirement, and/or Reserve Percentage of Unique Token(s); the central entity calculates the value of a token; this value may be calculated using processing circuitry, pricing engine, processing, storage, networking and communications equipment, or any combination thereof; this value may be calculated using the methods 600 or 700, and may yield a token valuation, or an exchange rate; token values may be calculated toward executing token Issuance, Redemption, Exchange, or any combination thereof; token values may also be calculated toward establishing Reserve Requirements and/or Reserve Percentages; the central entity receives updated information about the plurality of instruments; the updated information may be received using transceivers; the updated information may be received from distributed node(s), account(s), blockchain ledger, data source(s), market exchange(s), or any combination thereof; the updated information may be received from sources in different time zones; the updated information may include details of an Underlying Asset, e.g., price, trading volume, market capitalization, or other financial information; the central entity may automatically receive the updated information at predetermined intervals, and the intervals may be very short (e.g., less than one second)); and automatically executing a blockchain network transfer of a first amount of one or more crypto tokens between the first blockchain address associated with the first segregated entity and a second blockchain address associated with the custodial token platform, wherein the first amount is based at least in part on the net change and satisfying the threshold percentage associated with the rebalancing rule (Paragraphs 0163-0164, 0209-0210 teach maintaining the Minimum Aggregate Reserve: in some embodiments, the system will, at all times, automatically determine and maintain the minimum aggregate Reserve of Underlying Assets that must be held in Reserve to, among other things, collateralize the central entity’s obligations with respect to entire outstanding float for any given Unique Token, in accordance with the Reserve Requirement for that Unique Token; the system will automatically determine and maintain the Reserve in response to the information that it is able to access, e.g., from the multiple global market exchanges; the Reserve Requirement for any Unique Token may depend on the entire outstanding float of that Unique Token, the entire outstanding float calculated as the product of (a) the Unique Token value times (b) the total number of outstanding Unique Tokens; the system may automatically purchase, on one or more global market exchanges, the additional Underlying Assets that must be held in Reserve, or may otherwise automatically ensure that the Reserve meets the Reserve Requirement (e.g., by specifically allocating Reserve assets already managed by the system); wherein a third-party stakeholder holds the Reserve, the system may automatically direct the third-party stakeholder to purchase the additional Underlying Assets that must be held in Reserve or otherwise ensure that the Reserve meets the Reserve Requirement; the central entity updates the value of a token; this updated value may be calculated using processing circuitry, pricing engine, processing, storage, networking and communications equipment, or any combination thereof; this updated value may be calculated using the methods 600 or 700, and may yield a token valuation, or an exchange rate; updated token values may be calculated toward executing token Issuance, Redemption, Exchange, or any combination thereof; updated token values may also be calculated toward establishing Reserve Requirements and/or Reserve Percentages; the updated token value may depend on the plurality of instruments, Underlying Assets, Asset Mix, or financial information thereof; upon receiving updated information, the central entity may automatically update a calculated token value 806 to an updated token value; the central entity provides a value of the token to one or more nodes; this process may include providing the value to distributed node(s), blockchain ledger, blockchain, or cryptocurrency exchanges using transceiver; this process may also include providing the value via replication of token Issuance on the public blockchain or Issuance of token on a private blockchain using the processing, storage, networking, and communications equipment).
Regarding Claim 1, Schorr teaches a method for segregating blockchain address actions (Paragraph 0205 teaches FIG. 8 is a flowchart 800 of a process for providing a tokenized platform with reserve, in accordance with some embodiments of the disclosure).
Regarding Claim 13, Schorr teaches an apparatus for segregating blockchain address actions, comprising: one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code to cause the apparatus to perform operations (Paragraphs 0020 and 0072 teach a system is provided for coordinating data exchange between entities on a distributed network of nodes that persistently store transaction data based on a value of a token associated with the distributed network, and the system is coupled to the distributed network; the system includes storage equipment for storing respective quantities for a plurality of instruments; the system also includes a transceiver for receiving, from a plurality of servers over one or more data communication channels, information about the plurality of instruments; the system also includes processing circuitry for calculating a value of the token based on the respective quantities of the plurality of instruments and on the information; the transceiver is also used for receiving, from the plurality of servers over the one or more data communication channels, updated information about the plurality of instruments; the processing circuitry is also used for updating the value of the token based on the updated information, and providing the value of the token to one or more nodes of the distributed network for use in a transaction; a system coupled to a distributed network of nodes is provided for persistently storing transaction data based on a token value associated with the distributed network; the system includes a transceiver for receiving a request associated with an account to issue or redeem at least a portion of a token having the token value, wherein the token value is based on a plurality of instruments and respective quantities; the system also includes processing circuitry configured for determining an amount of payment based on the token value, causing to be transferred the amount of payment to the account, and causing to be updated the distributed network of nodes based on the payment).
Regarding Claim 19, Schorr teaches a non-transitory computer-readable medium storing code for segregating blockchain address actions, the code comprising instructions executable by one or more processors to perform operations (Paragraphs 0037 and 0090 teach a non-transitory computer readable medium having instructions programmed thereon is provided for performing a method for coordinating data exchange between entities on a distributed network of nodes that persistently store transaction data based on a value of a token associated with the distributed network, with the central entity coupled to the distributed network; the method includes storing respective quantities for a plurality of instruments; the method also includes receiving, from a plurality of servers over one or more data communication channels, information about the plurality of instruments; the method also includes calculating the value of the token based on the respective quantities of the plurality of instruments and on the information; the method also includes receiving, from the plurality of servers over the one or more data communication channels, updated information about the plurality of instruments; the method also includes updating the value of the token based on the updated information; the method also includes providing the value of the token to one or more nodes of the distributed network for use in a transaction; a non-transitory computer readable medium having instructions stored thereon is provided that, when executed, performs a method by a central entity on a distributed network of nodes that persistently store transaction data based on a token value associated with the distributed network, and the central entity is coupled to the distributed network; the method includes receiving, by the central entity a request associated with an account to issue or redeem at least a portion of a token having a token value, wherein the token value is based on a plurality of instruments and respective quantities; the method also includes determining, an amount of payment based on the token value, causing to be transferred, the amount of payment to the account, and causing to be updated, the distributed network of nodes based on the payment).
Examiner Note: Examiner is interpreting “a first duration of time” as a trigger event or alert event. Paragraph 0031 of spec. states “The custodial token platform 110 may determine, based on the rebalancing rule, a net change in token amounts attributed to the first set of user profiles associated with the first segregated entity during a first duration of time (e.g., threshold time, periodic or aperiodic time and/or based on a trigger event).”
Regarding Claims 3 and 15, Schorr teaches all the limitations of claims 1 and 13 above; and Schorr further teaches wherein the rebalancing rule further specifies that a second aggregated token amount attributed to a second plurality of user profiles associated with a second segregated entity is to be held by the second blockchain address that is associated with the second segregated entity (Paragraphs 0126, 0132-0133, and 0135 teach a buyer can exchange different financial instruments (e.g., US Dollars, Gold, Silver, Euros, Norwegian Krona, Swiss Francs, Australian Dollars, Singapore Dollars, British Pounds, other global currencies, asset-backed cryptocurrencies, or commodities) to purchase tokens created by the central entity and collateralized by Reserves held therein; tokens may be converted back to these financial instruments, or other financial instruments; the tokens may be transparently and dynamically valued based on an underlying basket of financial instruments; the basket can be rebalanced by the central entity at any time for any number of reasons, e.g., to protect against devaluations or quantitative easing by governments, to hedge against inflation, to stabilize the security of the central entity and tokens held therein, or for other reasons; Reserves, transaction fees and processing fees can be stored to provide liquidity to ensure orderly conversions and reliable ownership; Reserve Requirement: in some embodiments, each unique type of token will be associated with a pre-designated “Reserve Requirement,” which is the pre-designated minimum Reserve assets that is required to be held in order to, among other functions, collateralize the central entity's obligations with respect to that token; one or more third-party stakeholders hold some or all of the Reserve assets; the Reserve Requirement for any given unique type of token may mandate that a predesignated percentage number (a “Reserve Percentage”) be applied to determine the number (or fractional number) of units of that token's Underlying Assets that must be held in Reserve; if, for example, the Reserve Requirement for any given unique type of token were to mandate a fixed Reserve Percentage of 25%, and that token's Asset Mix were to be as set forth above, then a minimum of 25 US Dollars (25% of 100 US Dollars), 16 Euros (25% of 64 Euros), and 0.011 ounces of Gold (25% of 0.044 ounces of Gold) would need to be held in Reserve, among other things, to collateralize the central entity's obligations with respect to that token; the Reserve Requirement may dynamically update according to real-time information from the multiple global market exchanges and real-time information regarding the token value and quantity of outstanding issued tokens, among other information; different Reserve Percentages may also be applied to each Underlying Asset within the Asset Mix; if, for example, the Reserve Requirement were to vary for each Underlying Asset within the Asset Mix as set forth above, a Reserve Percentage of 30% may be applied to the US Dollars, a Reserve Percentage of 17.5% may be applied to the Euros, and a Reserve Percentage of 5% may be applied to the Gold).
Regarding Claims 4 and 16, Schorr teaches all the limitations of claims 1 and 13 above; and Schorr further teaches detecting a lapse in the first duration of time, wherein the net change is determined based at least in part on detecting the lapse in the first duration of time (Paragraphs 0206 and 0208 teach the central entity receives information about the plurality of instruments; the information may be received using transceivers; the information may be received from distributed node(s), account(s), blockchain ledger, data source(s), market exchange(s), or any combination thereof; the information may be received from sources in different time zones and may include details of an Underlying Asset, e.g., price, trading volume, market capitalization, or other financial information; a central entity may automatically receive the information at predetermined intervals, and these intervals may be very short (e.g., less than one second); the central entity receives updated information about the plurality of instruments; the updated information may be received using transceivers; the updated information may be received from distributed node(s), account(s), blockchain ledger, data source(s), market exchange(s), or any combination thereof; the updated information may be received from sources in different time zones; the updated information may include details of an Underlying Asset, e.g., price, trading volume, market capitalization, or other financial information; the central entity may automatically receive the updated information at predetermined intervals, and the intervals may be very short (e.g., less than one second)).
Regarding Claim 8, Schorr teaches all the limitations of claim 1 above; and Schorr further teaches determining, using the plurality of actions, a respective net change for each crypto token of a plurality of crypto tokens supported by the custodial token platform; and combining the respective net changes for the plurality of crypto tokens (Paragraphs 0131, 0133, 0135, and 0162 teach Asset Mix: in some embodiments, each unique type of token will be associated with a distinctly preconfigured underlying basket comprised of a pre-designated mix of multiple highly-liquid and globally-traded currencies, commodities, asset-backed cryptocurrencies, and/or other assets (each, an “Underlying Asset”), with a pre-designated and potentially different (and potentially fractional) number of units of each such Underlying Asset being contained in the basket (“Asset Mix”); any financial instrument or other value-retaining asset may be an Underlying Asset; for example, the Asset Mix for a unique type of token might be 100 US Dollars, 64 Euros, and 0.044 ounces of Gold; the Asset Mix associated with each unique type of token may be modified, as discussed herein; if, for example, the Reserve Requirement for any given unique type of token were to mandate a fixed Reserve Percentage of 25%, and that token's Asset Mix were to be as set forth above, then a minimum of 25 US Dollars (25% of 100 US Dollars), 16 Euros (25% of 64 Euros), and 0.011 ounces of Gold (25% of 0.044 ounces of Gold) would need to be held in Reserve, among other things, to collateralize the central entity's obligations with respect to that token; the Reserve Requirement may dynamically update according to real-time information from the multiple global market exchanges and real-time information regarding the token value and quantity of outstanding issued tokens, among other information; different Reserve Percentages may also be applied to each Underlying Asset within the Asset Mix; if, for example, the Reserve Requirement were to vary for each Underlying Asset within the Asset Mix as set forth above, a Reserve Percentage of 30% may be applied to the US Dollars, a Reserve Percentage of 17.5% may be applied to the Euros, and a Reserve Percentage of 5% may be applied to the Gold; Modifying or Rebalancing the Asset Mix of any Unique Token: in some embodiments, the system may allow the central entity to modify or rebalance the Asset Mix of any Unique Token; in some embodiments, any such modifications or rebalancings will be done in such a manner as to maintain the aggregate market value of the Unique Token's Asset Mix, as denominated in the units of any Denominated Quoted Asset; in some embodiments, the modifications or rebalancings may serve to maintain Reserve Requirements of the Unique Token and/or the Reserve Percentages of the Underlying Assets; in some embodiments, rebalancing may automatically change the Reserve assets collateralizing the Unique Token).
Regarding Claim 9, Schorr teaches all the limitations of claim 1 above; and Schorr further teaches wherein determining the net change further comprises: combining amounts associated with one or more of a plurality of action types of the plurality of actions associated with the first plurality of user profiles (Paragraphs 0206-0207 teach the central entity receives information about the plurality of instruments; the information may be received using transceivers; the information may be received from distributed node(s), account(s), blockchain ledger, data source(s), market exchange(s), or any combination thereof; the information may be received from sources in different time zones; the information may include details of an Underlying Asset, e.g., price, trading volume, market capitalization, or other financial information; a central entity may automatically receive the information at predetermined intervals, and these intervals may be very short (e.g., less than one second); the central entity calculates the value of a token; this value may be calculated using processing circuitry, pricing engine, processing, storage, networking and communications equipment, or any combination thereof; this value may be calculated using the methods 600 or 700, and may yield a token valuation, or an exchange rate; token values may be calculated toward executing token Issuance, Redemption, Exchange, or any combination thereof; token values may also be calculated toward establishing Reserve Requirements and/or Reserve Percentages).
Regarding Claim 10, Schorr teaches all the limitations of claim 9 above; and Schorr further teaches wherein the plurality of action types comprises buying, selling, sending, receiving, converting, withdrawing, staking, earning, layer two network messages, or any combination thereof (Paragraph 0200 teaches custody may also include updating the blockchain, blockchain ledger, distributed node(s), or other accounting of Transactions, in response to receiving a request to initiate a Transaction; account management may include fund intake, conversion, and/or reconversion; account management may also include reporting token ownership and dynamic token value on behalf of token buyer, consumers, or other stakeholders transacting with the central entity; the Reserve platform executes one or more of these operations through exchange system(s)).
Regarding Claims 11 and 20, Schorr teaches all the limitations of claims 1 and 19 above; and Schorr further teaches determining whether respective amounts of a set of crypto tokens associated with the first plurality of user profiles are less than one or more target thresholds associated with the first segregated entity (Paragraphs 0126 and 0162 teach buyer can Exchange different financial instruments (e.g., US Dollars, Gold, Silver, Euros, Norwegian Krona, Swiss Francs, Australian Dollars, Singapore Dollars, British Pounds, other global currencies, asset-backed cryptocurrencies, or commodities) to purchase tokens created by the central entity and collateralized by Reserves held therein; tokens may be converted back to these financial instruments, or other financial instruments; the tokens may be transparently and dynamically valued based on an underlying basket of financial instruments; the basket can be rebalanced by the central entity at any time for any number of reasons, e.g., to protect against devaluations or quantitative easing by governments, to hedge against inflation, to stabilize the security of the central entity and tokens held therein, or for other reasons; Modifying or Rebalancing the Asset Mix of any Unique Token: in some embodiments, the system may allow the central entity to modify or rebalance the Asset Mix of any Unique Token; any such modifications or rebalancings will be done in such a manner as to maintain the aggregate market value of the Unique Token's Asset Mix, as denominated in the units of any Denominated Quoted Asset; the modifications or rebalancings may serve to maintain Reserve Requirements of the Unique Token and/or the Reserve Percentages of the Underlying Assets; in some embodiments, rebalancing may automatically change the Reserve assets collateralizing the Unique Token); and executing a second transfer of at least one of the set of crypto tokens (Paragraph 0209-0210 teach the central entity updates the value of a token; this updated value may be calculated using processing circuitry, pricing engine, processing, storage, networking and communications equipment, or any combination thereof; this updated value may be calculated using the methods 600 or 700, and may yield a token valuation, or an exchange rate; updated token values may be calculated toward executing token Issuance, Redemption, Exchange, or any combination thereof; updated token values may also be calculated toward establishing Reserve Requirements and/or Reserve Percentages; the updated token value may depend on the plurality of instruments, Underlying Assets, Asset Mix, or financial information thereof; upon receiving updated information, the central entity may automatically update a calculated token value to an updated token value).
Regarding Claim 12, Schorr teaches all the limitations of claim 11 above; and Schorr further teaches determining that the second transfer results in a second aggregated token amount attributed to the first plurality of user profiles being out of compliance with the rebalancing rule (Paragraphs 0126 and 0162 teach buyer can Exchange different financial instruments (e.g., US Dollars, Gold, Silver, Euros, Norwegian Krona, Swiss Francs, Australian Dollars, Singapore Dollars, British Pounds, other global currencies, asset-backed cryptocurrencies, or commodities) to purchase tokens created by the central entity and collateralized by Reserves held therein; tokens may be converted back to these financial instruments, or other financial instruments; the tokens may be transparently and dynamically valued based on an underlying basket of financial instruments; the basket can be rebalanced by the central entity at any time for any number of reasons, e.g., to protect against devaluations or quantitative easing by governments, to hedge against inflation, to stabilize the security of the central entity and tokens held therein, or for other reasons; Modifying or Rebalancing the Asset Mix of any Unique Token: in some embodiments, the system may allow the central entity to modify or rebalance the Asset Mix of any Unique Token; any such modifications or rebalancings will be done in such a manner as to maintain the aggregate market value of the Unique Token's Asset Mix, as denominated in the units of any Denominated Quoted Asset; the modifications or rebalancings may serve to maintain Reserve Requirements of the Unique Token and/or the Reserve Percentages of the Underlying Assets; in some embodiments, rebalancing may automatically change the Reserve assets collateralizing the Unique Token); and executing a third transfer of at least one other crypto token of the set of crypto tokens between the first blockchain address and the second blockchain address (Paragraph 0209-0210 teach the central entity updates the value of a token; this updated value may be calculated using processing circuitry, pricing engine, processing, storage, networking and communications equipment, or any combination thereof; this updated value may be calculated using the methods 600 or 700, and may yield a token valuation, or an exchange rate; updated token values may be calculated toward executing token Issuance, Redemption, Exchange, or any combination thereof; updated token values may also be calculated toward establishing Reserve Requirements and/or Reserve Percentages; the updated token value may depend on the plurality of instruments, Underlying Assets, Asset Mix, or financial information thereof; upon receiving updated information, the central entity may automatically update a calculated token value to an updated token value).
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.
Claims 6-7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Schorr (US 20240232869) in view of DeCastro (US 20150170112).
Regarding Claims 6 and 18, Schorr teaches all the limitations of claims 1 and 13 above; however, Schorr does not explicitly teach wherein executing the blockchain network transfer between the first blockchain address and the second blockchain address comprises: executing the blockchain network transfer between the first blockchain address associated with one or more first private keys stored in a first offline environment and the second blockchain address that is associated with one or more second private keys stored in a second offline environment.
DeCastro from same or similar field of endeavor teaches wherein executing the blockchain network transfer between the first blockchain address and the second blockchain address comprises: executing the blockchain network transfer between the first blockchain address associated with one or more first private keys stored in a first offline environment and the second blockchain address that is associated with one or more second private keys stored in a second offline environment (Paragraphs 0025, 0072, and 0050 teach transfers/transactions may be conducted between two devices/applications in cold to hot/hot to cold; in particular, cold storage may apply to storage on a hard drive not connected to the internet or other network; typically, cold storage manifests as a scenario in which a person prints the private keys or other data held in hot storage onto a paper medium while deleting the same data from its prior location within the system; at a future data, those data can be scanned back into the memory of a card or other module of the system and thus put back into hot storage; methods for using the apparatus of the present invention may consist as follows; in a first example, Homeowner wants to pay Serviceman for performing a home-maintenance task; Homeowner has a card device of the present invention and the transaction amount is already stored in cold storage on the device as crypto-currency; Homeowner receives the invoice from Serviceman which has the company name and payment information thereon and pushes a button on the front face of the card to issue an electronic check payable in US Dollars to the company of the Serviceman; crypto-currency is transferred directly to Serviceman's company account and the compatible devices recognize the transaction as completed).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Schorr to incorporate the teachings of DeCastro for executing the blockchain network transfer between the first blockchain address and the second blockchain address to comprise: executing the blockchain network transfer between the first blockchain address associated with one or more first private keys stored in a first offline environment and the second blockchain address that is associated with one or more second private keys stored in a second offline environment.
There is motivation to combine DeCastro into Schorr because the invention assists individuals who travel across national borders, because the invention preserves a digital manifestation of a first money such that it can be transformed into a second money via a digital currency means as appropriate for any given set of circumstances. For example, national and international humanitarian and relief agencies (e.g., Red Cross, Unicef, Doctors without Borders) advantageously use the device of the present invention to give and send financial aid directly to victims without any party needing either a live terminal or an electrical power grid to immediately receive, store or use aid money. Also, citizens can send aid directly to victims in disasters bypassing Governments, Banks, Exchanges, Financial Gateways and Aid Agencies and NGOs; Governments can distribute welfare, social security, food stamps directly to recipients without an intermediate repository or middle man (DeCastro Paragraph 0054).
Regarding Claim 7, Schorr teaches all the limitations of claim 1 above; however, the Schorr does not explicitly teach wherein executing the blockchain network transfer between the first blockchain address and the second blockchain address comprises: executing a first blockchain network transfer between the first blockchain address associated with one or more first private keys stored in a first offline environment and a third blockchain address associated with one or more third private keys stored in a first online environment; and executing a second blockchain network transfer between the third blockchain address and the second blockchain address that is associated with one or more second private keys stored in a second offline environment.
DeCastro from same or similar field of endeavors teaches wherein executing the blockchain network transfer between the first blockchain address and the second blockchain address comprises: executing a first blockchain network transfer between the first blockchain address associated with one or more first private keys stored in a first offline environment and a third blockchain address associated with one or more third private keys stored in a first online environment; and executing a second blockchain network transfer between the third blockchain address and the second blockchain address that is associated with one or more second private keys stored in a second offline environment (Paragraphs 0025, 0072, and 0050-0051 teach transfers/transactions may be conducted between two devices/applications in cold to hot/hot to cold; in particular, cold storage may apply to storage on a hard drive not connected to the internet or other network; typically, cold storage manifests as a scenario in which a person prints the private keys or other data held in hot storage onto a paper medium while deleting the same data from its prior location within the system; at a future data, those data can be scanned back into the memory of a card or other module of the system and thus put back into hot storage; methods for using the apparatus of the present invention may consist as follows; in a first example, Homeowner wants to pay Serviceman for performing a home-maintenance task; Homeowner has a card device of the present invention and the transaction amount is already stored in cold storage on the device as crypto-currency; Homeowner receives the invoice from Serviceman which has the company name and payment information thereon and pushes a button on the front face of the card to issue an electronic check payable in US Dollars to the company of the Serviceman; crypto-currency is transferred directly to Serviceman's company account and the compatible devices recognize the transaction as completed; later, when either or both parties connect to the network (if neither are presently connected) the central agency reconciles its records as reflected in the data from the two devices; both parties have an instruction on their devices but when either one connects then they all clear; serviceman's device may be a card device (dedicated to the present invention) equivalent to that of Homeowner, or alternatively the same outcome can be achieved if Serviceman were using his own personal electronic device running a software application of the present invention, such as on a laptop PC, tablet PC, smartphone, and the like).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Schorr to incorporate the teachings of DeCastro for executing the transfer between the first blockchain address and the second blockchain address to comprise: executing a first transfer between the first blockchain address associated with one or more first private keys stored in a first offline environment and a third blockchain address associated with one or more third private keys stored in a first online environment; and executing a second transfer between the third blockchain address and the second blockchain address that is associated with one or more second private keys stored in a second offline environment.
There is motivation to combine DeCastro into Schorr because of the same reasons listed above for claim 6.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
De Beer et al. (US 20190130487) teaches systems and methods for secure messaging and automation are disclosed herein. An example method includes providing a user-facing application secured through use of a security token cached on a web browser, establishing a security protocol or security token utilized between the application server layer and the web services layer that is different from the security token cached on the web browser; and performing asynchronous processing based on user interaction with a goal-based planning application that provides queries that are directed to assessing both risk willingness and goal ability, generates a risk willingness score and a goal ability score, selects a goal-based plan, and generating one or more instructions sets that are used to automatically reconfigure the plurality of user accounts to ensure that a goal is met within a specified time frame.
Calo et al. (US 20240232407) teaches an example operation may include one or more of receiving, via a proxy located in a first geographic jurisdiction, a request for data from a software program, wherein the data is stored in a database located in a second geographic jurisdiction, identifying a regulatory constraint that must be enforced on the data stored in the database in the second geographic jurisdiction based on a policy associated with the second geographic jurisdiction, retrieving, via the proxy in the first geographic jurisdiction, the data requested from a proxy located in the second geographic jurisdiction, delivering the data received from the proxy located in the second geographic jurisdiction to the software program, and executing, via the proxy in the first geographic jurisdiction, an additional action on the data to comply with the regulatory constraint of the second geographic jurisdiction.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
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, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699