DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
Claims 1-24 are presented for examination. Examiner has established objections for claims 1, 4, 5, 8, 14, 17, 18, 20, and 21; § 101 rejection for claims 1-24; and grounds of prior art rejection for claims 1-24 in the instant Office action.
Claim Objections
Claims 1, 4, 5, 8, 14, 17, 18, 20, and 21, are objected to because of the informalities in the following recitations where Examiner has marked the suggested modifications with usual markings and bolded the appropriate parts of the claims:
Claim 1: A system, comprising:
. . .
via an execution module communicating with said security and permissioning module and said unified permission layer, validating transactions within constraints of said unified permissions layer and between each of said validator nodes, and reading and initiating state changes to said current state across said various blockchains to thereby form an updated state and propose valid blocks for said various blockchains; and
via a consensus module communicating with said execution module, determining a consensus networking topology across any of said validator nodes participating so a consensus can be reached and so said updated state can be propagated,[[;]] whereby said platform bridges one or more of [[said]] assets or [[said]] services with existing public and private versions of said various blockchains using said unified permission layer, thereby allowing an asset issuer to issue compliant versions of said assets or said services, and access liquidity and user participation across said various blockchains.
Claim 4: The system of claim 1, wherein said assets are fungible tokens selected from the group consisting of layer 1 tokens, layer 2 tokens, stablecoins, wrapped tokens, governance tokens, utility tokens, security tokens, tokenized fungible real word assets (RWAs) and liquid staking tokens (LSTs).
Claim 5: The system of claim 1, wherein said assets are non-fungible tokens (NFTs) selected from the group consisting of real word assets (RWAs) and NFTs.
Claim 8: The system of claim 7, wherein said preconfigured security settings include at least one required signature, and wherein a number of [[said]] signatures is tailored and updated by said asset issuer solely within said platform.
Claim 14: A system, comprising:
. . .
via a consensus module communicating with said execution module, determining networking between all of said validator nodes so consensus can be reached and so said updated state can be propagated; and[[,]]
via a staking security module communicating with said consensus module and said security and permissioning module, (i) staking [[said]] assets across validator networks, wherein the staking modifies validator participation dynamically across said various blockchains, (ii) enforcing institutional-grade staking compliance policies such that an issuer can issue permissioned and institutional-grade versions of said assets or said service,[[;]] and[[,]] (iii) bridging said permissioned and institutional-grade versions of said assets or said service with existing public and private versions of said various blockchains, thereby enabling and enhancing liquidity access and user participation across a plurality of available ecosystems.
Claim 17: The system of claim 14, wherein said assets are fungible tokens selected from the group consisting of layer 1 tokens, layer 2 tokens, stablecoins, wrapped tokens, governance tokens, utility tokens, security tokens, tokenized fungible real world-assets and liquid staking tokens (LSTs).
Claim 18: The system of claim 14, wherein said assets are non-fungible tokens (NFTs) selected from the group consisting of non-fungible real word assets (RWAs) and NFTs.
Claim 20: The system of claim 14, wherein said security and permissioning module further comprises pre-configured security settings fit for purpose of [[said]] asset issuer, [[said]] preconfigured security settings determining how to securely communicate and give or receive instructions to or from said various blockchains.
Claim 21: The system of claim 20, wherein said preconfigured security settings include at least one required signature, and wherein a number of [[said]] signatures is tailored and updated by said asset issuer solely within said platform.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-24 are rejected under 35 USC § 101 because they are directed to non-statutory subject matter. The rationale for this finding is explained below.
The Supreme Court in Mayo laid out a framework for determining whether an applicant is seeking to patent a judicial exception itself or a patent-eligible application of the judicial exception. See Alice Corp., 134 S. Ct. at 2355,110 USPQ2d at 1981 (citing Mayo, 566 U.S. 66, 101 USPQ2d 1961). This framework, which is referred to as the Mayo test or the Alice/Mayo test (“the test”), is described in detail in Manual of Patent Examining Procedure (”MPEP”) (see MPEP § 2106(III) for further guidance). The step 1 of the test: It need to be determined whether the claims are directed to a patent eligible (i.e., statutory) subject matter under 35 USC § 101. Step 2A of the test: If the claims are found to be directed to a statutory subject matter, the next step is to determine whether the claims are directed to a judicial exception i.e., law of nature, natural phenomenon, and abstract idea (Prong 1). If the claims are found to be directed to an abstract idea, it needs to be determined whether the claims recite additional elements that integrate the judicial exception into a practical application (Prong 2). Step 2B of the test: If the claims are directed to a judicial exception, the next and final step is to determine whether the claims recite additional elements that amount to significantly more than the judicial exception.
Step 1 of the Test:
When considering subject matter eligibility under 35 USC § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. Here, the claimed invention of claims 1-23 is a system and, thus, one of the statutory categories of invention. Further, the claimed invention of claim 24 is a series of steps, which is method (i.e., a process), which is also one of the statutory categories of invention.
Conclusion of Step 1 Analysis: Therefore, claims 1-24 are statutory under 35 USC § 101 in view of step 1 of the test.
Step 2A of the Test:
Prong 1: Claims 1-24, however, recite an abstract idea of real world asset tokenization. The creation of real world asset tokenization, as recited in the independent claims 1, 14, and 24, belongs to certain methods of organizing human activity (i.e., fundamental economic practices) that are found by the courts to be abstract ideas. The limitations in independent claims 1, 14, and 24, which set forth or describe the recited abstract idea, are found in the following steps:
“enabling secure communication between said platform and various blockchains, each said blockchain including a plurality of validator nodes for participating thereon, each said blockchain having a required permission and in a current state, said permission being for an asset or a service, and, (ii) establishing a unified permission layer across said various blockchains such that modifications of said permission on said various blockchains are received and executed solely from said platform, thereby governing and dynamically adjusting access to said various blockchains, wherein said unified permission layer enables protocol-level enforcement of access control for said various blockchains, and, (iii) propagating said modifications across said various blockchains” (claim 1);
“validating transactions within constraints of said unified permissions layer and between each of said validator nodes, and reading and initiating state changes to said current state across said various blockchains to thereby form an updated state and propose valid blocks for said various blockchains” (claim1);
“determining a consensus networking topology across any of said validator nodes participating so a consensus can be reached and so said updated state can be propagated, whereby said platform bridges one or more of said assets or said services with existing public and private versions of said various blockchains using said unified permission layer, thereby allowing an asset issuer to issue compliant versions of said assets or said services, and access liquidity and user participation across said various blockchains” (claim 1);
“enabling secure communication between said platform and various blockchains, each said blockchain including validator nodes participating thereon, each said blockchain having a required permission and in a current state, said permission being for an asset or a service” (claim 14);
“validating transactions between said validator nodes, and reading and initiating state changes to said current state across said various blockchains to thereby form an updated state and propose valid blocks for said various blockchains” (claim 14);
“determining networking between all of said validator nodes so consensus can be reached and so said updated state can be propagated” (claim 14);
“(i) staking said assets across validator networks, wherein the staking modifies validator participation dynamically across said various blockchains, (ii) enforcing institutional-grade staking compliance policies such that an issuer can issue permissioned and institutional-grade versions of said assets or said service; and (iii) bridging said permissioned and institutional-grade versions of said assets or said service with existing public and private versions of said various blockchains, thereby enabling and enhancing liquidity access and user participation across a plurality of available ecosystems” (claim 14);
“enabling secure communication between a platform and various blockchains, each said blockchain including a plurality of validator nodes for participating thereon, each said blockchain having a required permission and in a current state” (claim 24);
“establishing a unified permission layer across said various blockchains such that modifications of said permission on said various blockchains are received and executed solely from said platform, thereby governing and dynamically adjusting access to said various blockchains, wherein said unified permission layer enables protocol-level enforcement of access control for said various blockchains” (claim 24);
“propagating said modifications across said various blockchains” (claim 24);
“validating transactions within constraints of said unified permissions layer and between each of said validator nodes, and reading and initiating state changes to said current state across said various blockchains to thereby form an updated state and propose valid blocks for said various blockchains” (claim 24);
“determining a consensus networking topology across any of said validator nodes participating so a consensus can be reached and so said updated state can be propagated” (claim 24);
“staking said assets across validator networks, wherein the staking modifies validator participation dynamically across said various blockchains” (claim 24);
“enforcing institutional-grade staking compliance policies such that said asset issuer can issue permissioned and institutional-grade versions of said assets” (claim 24); and
“bridging said permissioned and institutional-grade versions of said assets with existing public and private versions of said various blockchains, thereby enabling and enhancing liquidity access and user participation across a plurality of available ecosystems” (claim 24).
Prong 2: In addition to abstract steps recited above in Prong 1, independent claims 1 and 14 recite additional elements (NOTE: independent claim 24 does not contain additional elements):
“a platform, said platform including a memory and a processing device operatively coupled to said memory, said memory having executable instructions stored thereon, and said processing device configured to execute the executable instructions” (claims 1 and 14);
“a security and permissioning module” (claims 1 and 14);
“an execution module communicating with said security and permissioning module and said unified permission layer” (claim 1);
“an execution module communicating with said security and permissioning module” (claim 14);
“a consensus module communicating with said execution module” (claims 1 and 14); and
“a staking security module communicating with said consensus module and said security and permissioning module” (claim 14).
These additional elements are recited at a high level of generality (e.g., as a generic processor performing a generic computer functions) such that they amount to no more than mere instructions to apply the exception using a generic computer components. Thus, these additional elements do not integrate the abstract idea into a practical application because they do not impose a meaningful limit on the judicial exception. The additional elements of independent claims 1 and 14 here do not render improvements to the functioning of a computer or to any other technology or technical field (see MPEP § 2106.05(a)), nor do they integrate the abstract idea into a practical application under MPEP § 2106.05(b) (particular machine); MPEP § 2106.05(c) (particular transformations); or MPEP § 2106.05(e) (other meaningful limitations). Further, the combination of these additional elements is no more than mere instructions to apply the exception using a generic device. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Conclusion of Step 2A Analysis: Therefore, independent claims1, 7, and 14, are non-statutory under 35 USC § 101 in view of step 2A of the test.
Step 2B of the Test: The additional elements of independent claims 1 and 14 (see above under Step 2A – Prong 2) are described by Applicant’s Specification in following terms:
[0029] Referencing then FIGs. 1-6, embodiments and the operations shown in the drawings and described in this specification are computer-implemented systems and methods. This means it can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification or in combinations of one or more of them. The operations can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources. A data processing apparatus, computer, or computing device may encompass apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing. The apparatus can include special purpose logic circuitry, for example, a central processing unit (CPU), a parallel graphics processing unit (GPU), a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC). The apparatus can also include code that creates an execution environment for the computer program in question, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system (for example, an operating system or a combination of operating systems), a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The apparatus and execution environment can realize various different computing model infrastructures, such as web services, distributed computing and grid computing infrastructures. Thus, it should be known a computer program is an executable program of instructions which can be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network. Generally, a computer will also include or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data. A computer, or node, can be embedded in another device, for example, a mobile device, a personal digital assistant (PDA), a game console, a Global Positioning System (GPS) receiver, or a portable storage device. Devices suitable for storing computer program instructions and data include non-volatile memory, media and memory devices, including, by way of example, semiconductor memory devices, magnetic disks, and magneto-optical disks. The processor and the memory can be supplemented by, or incorporated in, special-purpose logic circuitry. Additionally, processors for execution of a computer program include, by way of example, both general- and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory or both. The essential elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data.
This is a description of general-purpose computing system. Thus, individually, the additional elements of independent claims 1 and 14 are well-understood, routine, and conventional elements that amount to no more than implementing the abstract idea with a computerized system. Therefore, the additional limitations of independent claims 1 and 14 are well-understood, routine, and conventional. Further, taken as combination, the additional elements add nothing more than what is present when the additional elements are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
Conclusion of Step 2B Analysis: Therefore, independent claims 1, 14, and 24, are non-statutory under 35 USC § 101 in view of step 2B of the test.
Dependent Claims: Dependent claims 2-13 depend on independent claim 1; and dependent claims 15-23 depend on independent claim 14. The elements in dependent claims 2-13 and 15-23, which set forth or describe the abstract idea, are:
“via a staking security module, communicating with said consensus module and said security and permissioning module, wherein said staking security module stakes said assets” (claim 2: further narrowing the recited abstract idea);
“for the step of validating transactions by said execution module, said assets are delegated to a permissioned validator set, said permissioned validator set further validating said transactions and also publishing prices and posting proof of reserves” (claim 3: further narrowing the recited abstract idea);
“said assets are fungible tokens selected from the group consisting of layer 1 tokens, layer 2 tokens, stablecoins, wrapped tokens, governance tokens, utility tokens, security tokens, tokenized fungible real world assets (RWAs) and liquid staking tokens (LSTs)” (claim 4: further narrowing the recited abstract idea);
“said assets are non-fungible tokens (NFTs) selected from the group consisting of real world assets (RWAs) and NFTs” (claim 5: further narrowing the recited abstract idea);
“said assets are financialized assets selected from the group consisting of synthetics, cross-chain liquidity tokens and security tokens” (claim 6: further narrowing the recited abstract idea);
“said security and permissioning module further comprises pre-configured security settings fit for purpose of said asset issuer, said preconfigured security settings determine how to securely communicate and give or receive instructions to or from said various blockchains” (claim 7: further narrowing the recited abstract idea);
“said preconfigured security settings include at least one required signature, and wherein a number of said signatures is tailored and updated by said asset issuer solely within said platform” (claim 8: further narrowing the recited abstract idea);
“said security and permissioning module permissions a developer of said services on said platform, said service providing utility of said asset” (claim 9: further narrowing the recited abstract idea);
“a contract for said services on said platform is natively omnichain” (claim 10: further narrowing the recited abstract idea);
“using messaging protocols, said assets are adapted to be used as collateral for a loan even when said loan is on a different blockchain of said various blockchains relative to said assets” (claim 11: further narrowing the recited abstract idea);
“using messaging protocols, said assets are adapted to be redeemed natively on said platform” (claim 12: further narrowing the recited abstract idea);
“institutional compliance requirements are built into said messaging protocols” (claim 13: further narrowing the recited abstract idea);
“for the step of validating transactions by said execution module, said assets are delegated to a permissioned validator set, said permissioned validator set further validating said transactions and also publishing prices and posting proof of reserves” (claim 15: further narrowing the recited abstract idea);
“said security and permissioning module establishing a unified permission layer across said various blockchains such that modifications of said permission on said various blockchains are received and executed solely from said platform, thereby governing and dynamically adjusting access to said various blockchains, wherein said unified permission layer enables protocol-level enforcement of access control for said various blockchains” (claim 16: further narrowing the recited abstract idea);
“said assets are fungible tokens selected from the group consisting of layer 1 tokens, layer 2 tokens, stablecoins, wrapped tokens, governance tokens, utility tokens, security tokens, tokenized fungible real world-assets and liquid staking tokens (LSTs) ” (claim 17: further narrowing the recited abstract idea);
“said assets are non-fungible tokens (NFTs) selected from the group consisting of non-fungible real world assets (RWAs) and NFTs” (claim 18: further narrowing the recited abstract idea);
“said assets are financialized assets selected from the group consisting of synthetics, cross-chain liquidity tokens and security tokens” (claim 19: further narrowing the recited abstract idea);
“said security and permissioning module further comprises pre-configured security settings fit for purpose of said asset issuer, said preconfigured security settings determining how to securely communicate and give or receive instructions to or from said various blockchains” (claim 20: further narrowing the recited abstract idea);
“said preconfigured security settings include at least one required signature, and a number of said signatures is tailored and updated by said asset issuer solely within said platform” (claim 21: further narrowing the recited abstract idea);
“using messaging protocols, said assets are adapted to be used as collateral for a loan even when said loan is on a different blockchain of said various blockchains relative to said assets, and, using said messaging protocols, said assets are adapted to be redeemed natively on said platform” (claim 22: further narrowing the recited abstract idea); and
“institutional compliance requirements are built into said messaging protocols” (claim 23: further narrowing the recited abstract idea).
Conclusion of Dependent Claims Analysis: Dependent claims 2-13 and 15-23 do not correct the deficiencies of independent claims 1 and 14 and they are, thus, rejected on the same basis.
Conclusion of the 35 USC § 101 Analysis: Therefore, claims 1-24 are rejected as directed to an abstract idea without “significantly more” under 35 USC § 101.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under § 151, or in an application for patent published or deemed published under § 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3, 7, 14-16, 20, and 24, are rejected under 35 U.S.C. § 102(a)(2) as being anticipated by Treat (US 2019/0253422 A1).
As to independent claim 1
Treat shows:
a platform, said platform including a memory and a processing device operatively coupled to said memory, said memory having executable instructions stored thereon, and said processing device configured to execute the executable instructions (Treat: page 2, ¶ 20; and pages 3-4, ¶¶ 34-35) to cause the processing device to perform operations comprising the steps of:
via a security and permissioning module: (i) enabling secure communication between said platform and various blockchains, each said blockchain including a plurality of validator nodes for participating thereon, each said blockchain having a required permission and in a current state, said permission being for an asset or a service, and, (ii) establishing a unified permission layer across said various blockchains such that modifications of said permission on said various blockchains are received and executed solely from said platform, thereby governing and dynamically adjusting access to said various blockchains, wherein said unified permission layer enables protocol-level enforcement of access control for said various blockchains, and, (iii) propagating said modifications across said various blockchains (Treat: page 2, ¶¶ 20-24);
via an execution module communicating with said security and permissioning module and said unified permission layer, validating transactions within constraints of said unified permissions layer and between each of said validator nodes, and reading and initiating state changes to said current state across said various blockchains to thereby form an updated state and propose valid blocks for said various blockchains (Treat: page 4, ¶ 39; page 6, ¶¶ 57-58; and page 8, ¶¶ 88-89); and
via a consensus module communicating with said execution module, determining a consensus networking topology across any of said validator nodes participating so a consensus can be reached and so said updated state can be propagated, whereby said platform bridges one or more of said assets or said services with existing public and private versions of said various blockchains using said unified permission layer, thereby allowing an asset issuer to issue compliant versions of said assets or said services, and access liquidity and user participation across said various blockchains (Treat: page 2, ¶¶ 20-22; and page 3, ¶ 29).
As to claim 2: Treat shows all the elements of claim 1. Treat also shows via a staking security module, communicating with said consensus module and said security and permissioning module, wherein said staking security module stakes said assets (Treat: page 2, ¶¶ 20-22; and page 3, ¶ 29).
As to claims 3 and 15: Treat shows all the elements of claims 2 and 14. Treat also shows that for the step of validating transactions by said execution module, said assets are delegated to a permissioned validator set, said permissioned validator set further validating said transactions and also publishing prices and posting proof of reserves (Treat: page 1, ¶ 16; and page 9, ¶ 97).
As to claims 7 and 20: Treat shows all the elements of claim 1. Treat also shows that said security and permissioning module further comprises pre-configured security settings fit for purpose of said asset issuer, said preconfigured security settings determine how to securely communicate and give or receive instructions to or from said various blockchains (Treat: page 3, ¶ 34).
As to independent claim 14
Treat shows:
a platform, said platform including a memory and a processing device operatively coupled to the memory, said memory having executable instructions stored thereon; and said processing device configured to execute the executable instructions to cause the processing device to perform operations (page 2, ¶ 20; and pages 3-4, ¶¶ 34-35) comprising the steps of:
via a security and permissioning module, enabling secure communication between said platform and various blockchains, each said blockchain including validator nodes participating thereon, each said blockchain having a required permission and in a current state, said permission being for an asset or a service (Treat: page 2, ¶¶ 20-22);
via an execution module communicating with said security and permissioning module, validating transactions between said validator nodes, and reading and initiating state changes to said current state across said various blockchains to thereby form an updated state and propose valid blocks for said various blockchains (Treat: page 4, ¶ 39; page 6, ¶¶ 57-58; and page 8, ¶¶ 88-89);
via a consensus module communicating with said execution module, determining networking between all of said validator nodes so consensus can be reached and so said updated state can be propagated (Treat: page 2, ¶¶ 20-22; and page 3, ¶ 29); and
via a staking security module communicating with said consensus module and said security and permissioning module, (i) staking said assets across validator networks, wherein the staking modifies validator participation dynamically across said various blockchains, (ii) enforcing institutional-grade staking compliance policies such that an issuer can issue permissioned and institutional-grade versions of said assets or said service, and (iii) bridging said permissioned and institutional-grade versions of said assets or said service with existing public and private versions of said various blockchains, thereby enabling and enhancing liquidity access and user participation across a plurality of available ecosystems (Treat: page 2, ¶¶ 20-22; and page 3, ¶¶ 29-31).
As to claim 16: Treat shows all the elements of claim 14. Treat also shows said security and permissioning module establishing a unified permission layer across said various blockchains such that modifications of said permission on said various blockchains are received and executed solely from said platform, thereby governing and dynamically adjusting access to said various blockchains, wherein said unified permission layer enables protocol-level enforcement of access control for said various blockchains (Treat: page 2, ¶¶ 20-24).
As to independent claim 24
Treat shows:
enabling secure communication between a platform and various blockchains, each said blockchain including a plurality of validator nodes for participating thereon, each said blockchain having a required permission and in a current state (Treat: page 2, ¶¶ 20-22);
establishing a unified permission layer across said various blockchains such that modifications of said permission on said various blockchains are received and executed solely from said platform, thereby governing and dynamically adjusting access to said various blockchains, wherein said unified permission layer enables protocol-level enforcement of access control for said various blockchains (Treat: page 2, ¶¶ 20-24);
propagating said modifications across said various blockchains (Treat: page 2, ¶¶ 20-24);
validating transactions within constraints of said unified permissions layer and between each of said validator nodes, and reading and initiating state changes to said current state across said various blockchains to thereby form an updated state and propose valid blocks for said various blockchains (Treat: page 2, ¶¶ 20-24);
determining a consensus networking topology across any of said validator nodes participating so a consensus can be reached and so said updated state can be propagated (Treat: page 2, ¶¶ 20-24);
staking said assets across validator networks, wherein the staking modifies validator participation dynamically across said various blockchains (Treat: page 2, ¶¶ 20-22; and page 3, ¶¶ 29-31);
enforcing institutional-grade staking compliance policies such that said asset issuer can issue permissioned and institutional-grade versions of said assets (Treat: page 2, ¶¶ 20-22; and page 3, ¶¶ 29-31); and
bridging said permissioned and institutional-grade versions of said assets with existing public and private versions of said various blockchains, thereby enabling and enhancing liquidity access and user participation across a plurality of available ecosystems (Treat: page 2, ¶¶ 20-22; and page 3, ¶¶ 29-31).
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 § 102 of this title, 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 4-6 and 17-19 are rejected under 35 U.S.C. § 103 as being unpatentable over Treat in view of Doney (US 2025/0342528 A1).
As to claims 4 and 17: Treat shows all the elements of claims 1 and 14. Treat does not show that said assets are fungible tokens selected from the group consisting of Layer 1 tokens, Layer 2 tokens, stablecoins, wrapped tokens, governance tokens, utility tokens, security tokens, tokenized fungible Real World Assets (RWAs) and Liquid Staking Tokens (LSTs). Doney shows that said assets are fungible tokens selected from the group consisting of Layer 1 tokens, Layer 2 tokens, stablecoins, wrapped tokens, governance tokens, utility tokens, security tokens, tokenized fungible Real World Assets (RWAs) and Liquid Staking Tokens (LSTs) (Doney: page 19, ¶ 148). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Treat by said assets being fungible tokens selected from the group consisting of Layer 1 tokens, Layer 2 tokens, stablecoins, wrapped tokens, governance tokens, utility tokens, security tokens, tokenized fungible Real World Assets (RWAs) and Liquid Staking Tokens (LSTs) of Doney in order to facilitate scalable compliance for transactions of tokenized assets (Doney: page 5, ¶ 36).
As to claims 5 and 18: Treat shows all the elements of claims 1 and 14. Treat does not show that said assets are non-fungible tokens selected from the group consisting of Real World Assets (RWAs) and NFTs. Doney shows that said assets are non-fungible tokens selected from the group consisting of Real World Assets (RWAs) and NFTs (Doney: page 20, ¶ 152). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Treat by said assets being non-fungible tokens selected from the group consisting of Real World Assets (RWAs) and NFTs of Doney in order to facilitate scalable compliance for transactions of tokenized assets (Doney: page 5, ¶ 36).
As to claims 6 and 19: Treat shows all the elements of claims 1 and 14. Treat does not show that said assets are financialized assets selected from the group consisting of synthetics, cross-chain liquidity tokens and security tokens. Doney shows that said assets are financialized assets selected from the group consisting of synthetics, cross-chain liquidity tokens and security tokens (Doney: page 3, ¶ 24; and page 4, ¶ 27). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Treat by said assets being financialized assets selected from the group consisting of synthetics, cross-chain liquidity tokens and security tokens of Doney in order to facilitate scalable compliance for transactions of tokenized assets (Doney: page 5, ¶ 36).
Claims 8 and 21 are rejected under 35 U.S.C. § 103 as being unpatentable over Treat in view of Davis (AU 2022/231732 A1).
As to claims 8 and 21: Treat shows all the elements of claims 7 and 20. Treat does not show that said preconfigured security settings include at least one required signature, and wherein a number of said signatures is tailored and updated by said asset issuer solely within said platform. Davis shows that said preconfigured security settings include at least one required signature, and wherein a number of said signatures is tailored and updated by said asset issuer solely within said platform (Davis: page 12, line 1 – page 14, line 9). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Treat by said preconfigured security settings including at least one required signature, and a number of said signatures being tailored and updated by said asset issuer solely within said platform of Davis in order to provide significantly increased defense against fraud (Davis: page 14, line 19).
Claims 9 and 10 are rejected under 35 U.S.C. § 103 as being unpatentable over Treat in view of Zarick (US 2023/0289791 A1).
As to claim 9: Treat shows all the elements of claim 1. Treat does not show that said security and permissioning module permissions a developer of said services on said platform, said service providing utility of said asset. Zarick shows that said security and permissioning module permissions a developer of said services on said platform, said service providing utility of said asset (Zarick: page 14, ¶ 130). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Treat by said security and permissioning module permissions a developer of said services on said platform, said service providing utility of said asset of Zarick in order to implement digital asset exchange protocols (Zarick: page 1, ¶ 16).
As to claim 10: Treat in view of Zarick shows all the elements of claim 9. Treat does not show that a contract for said services on said platform is natively omnichain. Zarick shows that a contract for said services on said platform is natively omnichain (Zarick: page 5, ¶ 43). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Treat by a contract for said services on said platform being natively omnichain of Zarick in order to implement digital asset exchange protocols (Zarick: page 1, ¶ 16).
Claims 11-13 and 22-23 are rejected under 35 U.S.C. § 103 as being unpatentable over Treat in view of Agbamu (US 2024/0346473 A1).
As to claim 11: Treat shows all the elements of claim 1. Treat does not show that using messaging protocols, said assets are adapted to be used as collateral for a loan even when said loan is on a different blockchain of said various blockchains relative to said assets. Agbamu shows that using messaging protocols, said assets are adapted to be used as collateral for a loan even when said loan is on a different blockchain of said various blockchains relative to said assets (Agbamu: page 8, ¶ 69). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Treat by using messaging protocols, said assets being adapted to be used as collateral for a loan even when said loan is on a different blockchain of said various blockchains relative to said assets of Agbamu in order to provide interoperable on-chain and off-chain banking and payment systems that may facilitate and streamline the interaction, issuance, execution, clearing, settlement, and of on-chain and off-chain accounts and assets (Agbamu: page 2, ¶ 20).
As to claim 12: Treat shows all the elements of claim 1. Treat does not show that using messaging protocols, said assets are adapted to be redeemed natively on said platform. Agbamu shows that using messaging protocols, said assets are adapted to be redeemed natively on said platform (Agbamu: page 1, ¶ 9). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Treat by using messaging protocols, said assets being adapted to be redeemed natively on said platform of Agbamu in order to provide interoperable on-chain and off-chain banking and payment systems that may facilitate and streamline the interaction, issuance, execution, clearing, settlement, and of on-chain and off-chain accounts and assets (Agbamu: page 2, ¶ 20).
As to claim 22: Treat shows all the elements of claim 14. Treat does not show that using messaging protocols, said assets are adapted to be used as collateral for a loan even when said loan is on a different blockchain of said various blockchains relative to said assets, and, wherein, using said messaging protocols, said assets are adapted to be redeemed natively on said platform. Agbamu shows that using messaging protocols, said assets are adapted to be used as collateral for a loan even when said loan is on a different blockchain of said various blockchains relative to said assets, and, wherein, using said messaging protocols, said assets are adapted to be redeemed natively on said platform (Agbamu: page 1, ¶ 9). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Treat by using messaging protocols, said assets being adapted to be used as collateral for a loan even when said loan is on a different blockchain of said various blockchains relative to said assets, and, using said messaging protocols, said assets being adapted to be redeemed natively on said platform of Agbamu in order to provide interoperable on-chain and off-chain banking and payment systems that may facilitate and streamline the interaction, issuance, execution, clearing, settlement, and of on-chain and off-chain accounts and assets (Agbamu: page 2, ¶ 20).
As to claims 13 and 23: Treat in view of Agbamu shows all the elements of claims 11 and 22. Treat does not show that institutional compliance requirements are built into said messaging protocols. Agbamu shows that institutional compliance requirements are built into said messaging protocols (Agbamu: pages 4-5, ¶ 39). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Treat by institutional compliance requirements having been built into said messaging protocols of Agbamu in order to provide interoperable on-chain and off-chain banking and payment systems that may facilitate and streamline the interaction, issuance, execution, clearing, settlement, and of on-chain and off-chain accounts and assets (Agbamu: page 2, ¶ 20).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Zhu (US 2024/0137208 A1) discloses: “This application provides an asset transferring method and apparatus based on multiple blockchains, a device, a medium, and a product. The method includes: obtaining a first cross-chain asset transfer-out request transmitted by a service object for a first cross-chain transfer-out transaction; writing transaction data of the first cross-chain transfer-out transaction carried in the first cross-chain asset transfer-out request into a first cross-chain bridge contract on a first chain; and invoking, when determining that the service object has a cross-chain asset transfer-out permission based on the first cross-chain bridge contract and service data information, a first asset contract on the first chain to lock a first asset, and generating a first cross-chain event corresponding to the first cross-chain transfer-out transaction. According to this application, the service stability of a service executed on a chain may be ensured based on a multi-blockchain architecture.”
Novotny (US 2021/0360031 A1) discloses: “An example operation includes one or more of connecting, by an identity provisioning node, a blockchain one to a blockchain two, creating, by an identity provisioning node, an interoperation identity network (IIN) for the blockchain one and for the blockchain two as an instance of a self-sovereign identity (SSI) network, executing a smart contract to: invoke an IIN access control policy, map attributes and permissions of the blockchain one to attributes and permissions of the blockchain two based on the IIN access control policy, and generate a valid verifiable credential (VC) of the IIN in the blockchain one and in the blockchain two based on the mapped attributes and the permissions.”
Kitzul-Varshney (WO 2024/216119 A1) discloses: “The present disclosure provides systems and methods for implementing blockchains using a global decentralized consensus node ecosystem that can be directly used for enterprise solutions, small business, WEB 3 and other types of blockchain projects that require on- and off-chain validation, mining, or related blockchain services. The consensus nodes are configured to validate transactions on custom blockchains within the blockchain network. An incentive framework provides compensation to consensus node operators in the main network's native currency, even when the consensus nodes are operating on the custom blockchains. The primary goal is to enable solutions that more directly connect businesses, organizations, and even individuals. This will create a new way of sharing information between two or more entities.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIRPI H. KANERVO whose telephone number is 571-272-9818. The examiner can normally be reached on Monday - Friday, 10 am - 6 pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Abhishek Vyas can be reached on 571-270-1836. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VIRPI H KANERVO/Primary Examiner, Art Unit 3691
Prosecution Insights