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 .
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-10 are directed to a method and claims 11-20 are directed to a system. Thus, each of claims 1-20 fall into fall into at least one category enumerated in 35 U.S.C. § 101.
However, claim 11 recites:
receiving an asset request from a requesting entity, wherein the asset request indicates an asset available
exchang[ing] assets privately-generated by an enterprise entity;
identifying an asset control associated with the asset indicated by the asset request, wherein the asset control is configured by a permissions system
and wherein the control parameter is configured using data derived from the enterprise entity that privately generated the asset;
determining whether the asset control is satisfied by at least one of the asset request or the requesting entity; and
in response to the asset control being satisfied, facilitating fulfillment of the asset request.
This is an abstract idea that falls under the category of commercial or legal interactions (marketing or sales activities or behaviors) at least because the claims recite an asset request, determining whether an asset control is satisfied by the asset request or requesting entity and facilitating fulfillment of the asset request if the asset control is satisfied. See MPEP § 2106.04(a)(2), subsection II.B.
The additional elements (beyond the abstract idea) of the claim include:
A system comprising: a network access layer including a processor and storage hardware in communication with the processor, wherein the storage hardware includes instructions that when executed by the processor perform operations;
at the network access layer
in a digital wallet system associated with the network access layer, and wherein the network access layer includes a data plane
of the network access layer and indicates a control parameter determined by an intelligence system of the network access layer
operating a control plane associated with the network access layer.
The additional claim elements are recited at a high-level of generality; and so, merely generally link the use of the judicial exception to a particular technological environment of networked computers and do not impose any meaningful limits on practicing the abstract idea. The claimed invention does not improve the functioning of a computer or improve another technology or technical field. Thus, the judicial exception is not integrated into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately or in combination, they do no more than limit the above-identified abstract idea to the particular technological environment of networked computers and graphical user interfaces. Limitations that merely confine the use of the abstract idea to a particular technological environment fail to add an inventive concept to the claims. See MPEP § 2106.05(h) discussing Affinity Labs of Texas v. DirecTV, LLC, 838 F.3d 1253, 120 USPQ2d 1201 (Fed. Cir. 2016) (particular technological environment of cellular telephones). The claims are not patent-eligible. Claim 1 recites substantially the same limitations and is rejected under 35 U.S.C. § 101 for the same reason.
Regarding claim(s) 2 and 12,
The claims specify that the asset is available in a hot wallet of the digital wallet system. A hot wallet merely implies a network connection to the wallet and this is merely specifying a generic computer networking feature and does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 3 and 13,
The claims specify that the asset is available in a cold wallet of the digital wallet system. A cold wallet merely implies that the asset is stored in a wallet offline and is merely specifying a technological environment or field of use and does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 4 and 14,
The claims specify that the asset is available in a custodial wallet of the digital wallet system. This suggests third party management of the wallet and is part of the abstract idea of organizing human activity is merely specifying a technological environment or field of use and does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 5 and 15,
The claims specify that facilitating fulfillment of the asset request includes transferring a set of keys for the cold wallet to a hot wallet. This is part of the abstract idea of mitigating risk – a fundamental economic principle or practice which is part of the abstract idea and does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 6 and 16,
The claims specify that facilitating fulfillment of the asset request includes wherein facilitating fulfillment of the asset request includes: signing a transaction involving the asset on the cold wallet; and relaying the signed transaction using a hot wallet of the digital wallet system that is associated with the cold wallet. This is insignificant extra-solution activity involving data gathering and outputting and does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 7 and 17,
The claims recite establishing a connection to the cold wallet and the requesting entity. This part of the abstract idea of fulfilling the request or a generic network function. In either case, it does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 8 and 18,
The claims recite the wherein the asset control matches an access control for an enterprise entity that submitted the asset to the digital wallet system. This is part of the abstract idea of fulfilling an asset request based on rules or conditions, and does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 9 and 19,
The claims recite a specific condition (security clearance level) for providing/fulfilling an asset request. This is part of the abstract idea of fulfilling an asset request based on rules or conditions, and does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 10 and 20,
The claims recites an additional rule or requirement related to fulfilling an asset request. This is part of the abstract idea of fulfilling an asset request based on rules or conditions, and does not integrate the abstract idea into a practical application or provide significantly more.
Thus each of claims 1-20 are rejected under 35 U.S.C. § 101 as being directed to an abstract idea without significantly more.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over NIETO (US 11487850 B1 to Nieto, A. et al.) in view of KATZ (US 20210312291 A1 to Katz, R.M. et al.).
Regarding claim(s) 1 and 11,
NIETO discloses:
A system comprising (NIETO: col. 1, ll. 50-55: a method, a system, and a non-transitory computer readable medium that includes operations for securely distributing a plurality of digital assets via a digital activation layer are claimed):
a network access layer including a processor and storage hardware in communication with the processor, wherein the storage hardware includes instructions that when executed by the processor perform operations, and wherein the operations include (NIETO: col. 5, ll. 57-60: Backend layer 110 may also be implemented with a processor to handle the calculations for receiving user requests for “customizing digital assets and purchasing digital assets”; NIETO: col. 1, ll. 50-55: a method, a system, and a non-transitory computer readable medium that includes operations for securely distributing a plurality of digital assets via a digital activation layer are claimed):
receiving, at the network access layer, an asset request from a requesting entity (NIETO: col. 23, ll. 14-20: (106) In 304, the digital activation layer 230A facilitates the purchase of a digital asset by the user device 240A. For example, the digital activation layer 230A may receive a request from user device 240A to purchase a digital asset of a group of digital assets being offered for sale via digital asset subsystem 235),
wherein the asset request indicates an asset available in a digital wallet system associated with the network access layer (NIETO: col. 2, ll. 2-6: The digital activation layer may further store the digital asset (e.g., in a database or other storage means outside the digital activation layer) subsequent to receiving the request for ownership of the digital asset in the digital wallet; col. 3, ll. 40-45: The architecture includes a digital activation layer that employs a distributed ledger that stores information about each user in a digital wallet in a secure manner and that allows for ownership of the digital assets to be traced; col. 23, ll. 14-26: (106) In 304, the digital activation layer 230A facilitates the purchase of a digital asset by the user device 240A. For example, the digital activation layer 230A may receive a request from user device 240A to purchase a digital asset of a group of digital assets being offered for sale via digital asset subsystem 235.[...] Purchasing of the digital asset may also result in storing the digital asset in the digital wallet.),
[…]
identifying an asset control associated with the asset indicated by the asset request (NIETO: col. 32, ll. 61-67: (152) In 904, the digital activation layer 230A may retrieve a smart contract associated with the digital asset where the smart contract includes information and conditions associated with the digital asset. Information can include components of the digital asset and characteristics of the digital asset. Conditions can specify actions that can be performed by on the digital asset and milestones associated with the digital asset. The conditions may be triggered based on information in the user request.; col. 13, ll. 20-25: The smart contract can specify that certain products or services (e.g., digital asset, […], early access to digital assets […]) can be made available to a customer based on a certain condition when performed by the customer; col. 26, ll. 8-15: The trigger conditions may be associated with generating digital assets […]. Examples of trigger conditions include a scheduled time to perform a digital asset drop to certain users in the enterprise network 205, a request from one or more users to customize or generate new digital assets,; col. 28, ll. 66-67 : (135) In 604, the digital activation layer 230A may analyze the customization request to determine conditions for customizing the digital asset),
wherein the asset control is configured by a permissions system of the network access layer and indicates a control parameter determined by an intelligence system of the network access layer (NIETO: col. 28, ll. 66-67 to col. 29, ll. 1-14: (135) In 604, the digital activation layer 230A may analyze the customization request to determine conditions for customizing the digital asset. In an embodiment, conditions may be a cost may be in form of the digital currency or actual currency. Other conditions may include any requirements imposed by a smart contract on the distributed ledger 231A associated with the digital asset. […] In an embodiment, conditions may be linked to the user requesting the customization which indicate whether the user has permission or is otherwise allowed to perform the customization; col. 27, ll. 46-51: In some embodiments, this may also include establishing permissions for operations that the user device 240A is capable of performing within the enterprise network 205. As previously discussed, establishing permissions for each user may be performed using smart contracts; col. 24, ll. 38-55: (70) In an embodiment, each generated digital asset is associated with its own smart contract […]. Because the smart contract and its associated information are stored in a blockchain, the digital activation layer 230A can validate the uniqueness of each digital asset and also provide a secure way for the digital assets be transferred between users. […] Smart contracts in digital activation layer 230A may provide the conditions for when the generated digital assets are communicated to the production subsystem 212. For example, a particular user may have a heightened membership status that grants him privileges such as access to the production subsystem 212 […]),
and wherein the control parameter is configured using data derived from the enterprise entity that privately generated the asset (NIETO: col. 9, ll. 11-22: (41) Digital assets may be generated based on one or more of the commercial attributes based on an algorithm implemented by the distributed ledger. For example, certain commercial attributes such as the country of origin, the manufacturing facility identifier, the manufacturing date, the shipping date, and the shipping route, may be used in generating a digital asset that captures the provenance of the physical product 116. In another example, the digital asset may also represent the commercial use of the physical product such as the number of the manufacturing units of the physical product (i.e., the rarity), the number of sales, and/or the number of social media mentions.);
determining whether the asset control is satisfied by at least one of the asset request or the requesting entity (NIETO: col. 13, ll. 20-25: The smart contract can specify that certain products or services (e.g., digital asset, physical product, early access to digital assets or physical products) can be made available to a customer based on a certain condition when performed by the customer; col. 13, ll. 44-50: (67) In an embodiment, smart contracts in digital activation layer 230A may include adjustment factors in the smart contracts that adjust the number of tokens to be rewarded. These adjustment factors can be based on tiered thresholds associated with the conditions for executing the smart contract; col. 14, ll. 40-54: the digital activation layer 230A can validate the uniqueness of each digital asset and also provide a secure way for the digital assets be transferred between users. In an embodiment, digital activation layer 230A may communicate generated digital assets to production subsystem […]; . Smart contracts in digital activation layer 230A may provide the conditions for when the generated digital assets are communicated to the production subsystem 212. For example, a particular user may have a heightened membership status that grants him privileges such as access to the production subsystem 212 […]); col. 33, ll. 35-45: Other examples of conditions include customizing the digital asset and transferring the digital asset for use in external systems 220; col. 34, ll. 1: securely transfer the digital asset);
and in response to the asset control being satisfied, facilitating fulfillment of the asset request (NIETO: col. 14, ll. 38-45: (70) In an embodiment, each generated digital asset is associated with its own smart contract that specifies the appearance, components, and other elements that are part of the digital asset. Because the smart contract and its associated information are stored in a blockchain, the digital activation layer 230A can validate the uniqueness of each digital asset and also provide a secure way for the digital assets be transferred between users; col. 24, ll. 38-55: (111) In 308, the digital activation layer 230A may determine the owner of the digital asset after the predetermined period of time has lapsed. […] if the requested action was to transfer the digital asset to another user, the digital activation layer 230A may update the ownership characteristic of the digital asset to reflect the transfer. In one embodiment, updating the ownership characteristic based on transferring the digital asset to a second user device comprises transferring the digital asset from the digital wallet to another digital wallet associated with the second user device. Similarly, if the requested action was to digitally hold the digital asset, the digital activation layer 230A may confirm that the ownership characteristic accurately reflects the current owner.).
NIETO does not expressly disclose the following limitations, which KATZ however, teaches:
and wherein the network access layer includes a data plane configured to exchange assets privately-generated by an enterprise entity operating a control plane associated with the network access layer (KATZ: ¶[0026]: Second, a control plane layer includes an adaptive control unit, such as a cognitive computing unit, an artificial intelligence unit or a machine-learning unit. Third, a data plane layer includes an input interface to receive data input from one or more data sources; ¶[0064]: Turning thirdly to the state data plane layer, it preferably includes main subcomponents and Functional Network Elements. Optionally, the functional network elements include some or all of the following: […] 2. Value/Title Transfer Network Element, ¶[0129]: Digital assets are anything that exists in digital, typically binary, format and comes with the right to use.; ¶[0116]: smart contract for asset swap; KATZ claim 1: the data plane layer being coupled to the control plane layer interface, the data plane layer including a title transfer network element to transfer digital assets via a blockchain; ¶[0062]: control plane layer preferably enforces behavior at a low level control in the data plane; The control plane advantageously includes cognitive computing, such as artificial intelligence (AI) and machine learning (ML));
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the digital access and control system/method of NIETO with the technique of KATZ, which, discloses architectures, systems and methods for program control utilizing cognitive computing involving wallets in order to decouple statements to provide improved modularity and flexible enforcement of policies (KATZ ¶[0059])).
Regarding claim(s) 2 and 12,
NIETO and KATZ teach the limitations of 1 and 11.
NIETO discloses a digital activation layer receiving a request for ownership of a digital asset in a digital wallet (NIETO: col. 2, ll. 2-6:) but does not expressly disclose the following limitations, which KATZ however, teaches:
wherein the asset is available in a hot wallet of the digital wallet system (KATZ [0318]: Hot Wallet: A bitcoin wallet that has an active connection to the Internet. These are used for “everyday” transactions and should never hold large amounts of bitcoin, since their connectivity reduces their security.)
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the digital access and control system/method of NIETO with the technique of KATZ, which, discloses architectures, systems and methods for program control utilizing cognitive computing involving wallets in order to effectual real-time wallet network transactions (KATZ [0318]) as contemplated in NIETO (see NIETO col. 2, ll. 2-6 discussing requests for ownership of digital assets in digital wallets and NIETO col. 4, ll. 50-57: generation of digital assets dropped into a digital wallet of a user ).
Regarding claim(s) 3 and 13,
NIETO and KATZ teach the limitations of 1 and 11.
NIETO discloses a digital activation layer receiving a request for ownership of a digital asset in a digital wallet (NIETO: col. 2, ll. 2-6:) but does not expressly disclose the following limitations, which KATZ however, teaches:
wherein the asset is available in a cold wallet of the digital wallet system (KATZ: ¶[00238]: Cold Storage: The safest way to store private keys is by keeping them offline in “cold storage”. This could be in the form of a hardware wallet, USB stick or paper wallet. These wallets are known as “cold wallets”; ¶[00387]: paper wallet: printed sheet containing bitcoin addresses and private keys – a form of cold bitcoin storage).
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the digital access and control system/method of NIETO with the technique of KATZ, which, discloses architectures, systems and methods for program control utilizing cognitive computing involving wallets in order to safely store keys related to assets in wallets (KATZ [0238]) contemplated in NIETO (see NIETO col. 2, ll. 2-6 discussing requests for ownership of digital assets in digital wallets and NIETO col. 4, ll. 50-57: generation of digital assets dropped into a digital wallet of a user ).
Regarding claim(s) 4 and 14,
NIETO and KATZ teach the limitations of 1 and 11.
NIETO discloses a digital activation layer receiving a request for ownership of a digital asset in a digital wallet (NIETO: col. 2, ll. 2-6) and importing digital assets to a third-party application (NIETO col. 31, ll. 34-40) but does not expressly disclose the following limitations, which KATZ however, teaches:
wherein the asset is available in a custodial wallet of the digital wallet system (KATZ: ¶[0483]: Web Wallet: These are usually gotten through exchanges, and stored on third-party servers via cloud computing. They can be accessed by any computing device.).
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the digital access and control system/method of NIETO with the technique of KATZ, which, discloses architectures, systems and methods for program control utilizing cognitive computing involving wallets in order to improve access to a wallet and provide additional access and security options (KATZ [0438]) to a user using a wallet contemplated in NIETO (see NIETO col. 2, ll. 2-6 discussing requests for ownership of digital assets in digital wallets and NIETO col. 4, ll. 50-57: generation of digital assets dropped into a digital wallet of a user ).
Regarding claim(s) 5 and 15,
NIETO and KATZ teach the limitations of 1, 3, 11 and 13, respectively.
NIETO discloses a digital activation layer receiving a request for ownership of a digital asset in a digital wallet (NIETO: col. 2, ll. 2-6:) but does not expressly disclose the following limitations, which KATZ however, teaches:
wherein facilitating fulfillment of the asset request includes transferring a set of keys for the cold wallet to a hot wallet of the digital wallet system (KATZ: ¶[0238]: The safest way to store private keys is by keeping them offline in “cold storage”. This could be in the form of a hardware wallet, USB stick or paper wallet. These wallets are known as “cold wallets”; ¶[0321]: Hybrid wallet that combines a software wallet stored on a local computer and a web wallet stored on a third-party server; ¶[0228]: importing a private key into a wallet ).
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the digital access and control system/method of NIETO with the technique of KATZ, which, discloses architectures, systems and methods for program control utilizing cognitive computing involving wallets in order to effectual real-time wallet network transactions (KATZ [0318]) as contemplated in NIETO (see NIETO col. 2, ll. 2-6 discussing requests for ownership of digital assets in digital wallets and NIETO col. 4, ll. 50-57: generation of digital assets dropped into a digital wallet of a user ) and to safely store data related to assets in wallets (KATZ [0238]) contemplated in NIETO (see NIETO col. 2, ll. 2-6 discussing requests for ownership of digital assets in digital wallets and NIETO col. 4, ll. 50-57: generation of digital assets dropped into a digital wallet of a user ).
Regarding claim(s) 6 and 16,
NIETO and KATZ teach the limitations of 1, 3, 11 and 13, respectively.
NIETO further discloses:
wherein facilitating fulfillment of the asset request includes: signing a transaction involving the asset on the cold wallet (NIETO col. 27, ll. 28-36: a user device digitally signs using another private key (cold wallet behavior); NIETO col. 27, ll. 37-46: authentication module validates the user in the network by verifying that the digital signature is authentic);
and relaying the signed transaction using a hot wallet of the digital wallet system that is associated with the cold wallet (NIETO: col. 12, ll. 8-15: User devices 122A-B may communicate with each other and digital activation layer 118 using a wired or wireless connection; NIETO col. 27, ll. 37-46: authentication module validates the user in the network by verifying that the digital signature is authentic); col. 14, ll. 40-46: the digital activation layer 230A can validate the uniqueness of each digital asset and also provide a secure way for the digital assets be transferred between users; col. 27, ll. 40-51: . If the digital signature is authentic, registration is completed with the authentication module 234 communicating with the digital wallet manager 233 to establish a digital wallet for the user for use in the enterprise network 205. In some embodiments, this may also include establishing permissions for operations that the user device 240A is capable of performing within the enterprise network 205. establishing permissions for each user may be performed using smart contracts in the distributed ledger 231A)
Although NIETO describes cold wallet/hot wallet behavior it does not explicitly disclose “hot” and “cold” wallets, which KATZ however teaches at ¶[0318]: hot wallet and ¶[0238]: cold wallets.
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the digital access and control system/method of NIETO with the technique of KATZ, which, discloses architectures, systems and methods for program control utilizing cognitive computing involving wallets in order to effectual real-time wallet network transactions (KATZ [0318]) as contemplated in NIETO (see NIETO col. 2, ll. 2-6 discussing requests for ownership of digital assets in digital wallets and NIETO col. 4, ll. 50-57: generation of digital assets dropped into a digital wallet of a user ) and to safely store data related to assets in wallets (KATZ [0238]) contemplated in NIETO (see NIETO col. 2, ll. 2-6 discussing requests for ownership of digital assets in digital wallets and NIETO col. 4, ll. 50-57: generation of digital assets dropped into a digital wallet of a user ).
Regarding claim(s) 7 and 17,
NIETO and KATZ teach the limitations of 1, 3, 11 and 13, respectively.
NIETO discloses a digital activation layer receiving a request for ownership of a digital asset in a digital wallet (NIETO col. 2, ll. 2-6:) but does not expressly disclose the following limitations, which KATZ however, teaches:
wherein facilitating fulfillment of the asset request includes connecting the cold wallet to the requesting entity (NIETO col. 27, ll. 28-36: a user device digitally signs using another private key (cold wallet behavior); NIETO col. 27, ll. 37-46: authentication module validates the user in the network by verifying that the digital signature is authentic; NIETO col. 5, ll. 46-51: (28) Backend layer 110 may include components (discussed in further detail in FIG. 2) for managing and providing user devices 122A and 122B access to a physical inventory 112 of physical products and digital asset marketplace 114 that provides users access to digital assets.; col. 5, ll. 40-46: (27) User devices 122A and 122B may communicate with backend layer 110 via digital activation layer 118. User devices 104 and 108, and backend layer 110 may connect to digital activation layer 118 through communication links; col. 12, ll. 39-41: . Enterprise network 205 includes backend layer 210 and digital activation layer 230A; col. 14, ll. 48-54: Smart contracts in digital activation layer 230A may provide the conditions for when the generated digital assets are communicated to the production subsystem 212. For example, a particular user may have a heightened membership status that grants him privileges such as access to the production subsystem 212 which can produce the corresponding physical product.).
Although NIETO describes cold wallet/hot wallet behavior it does not explicitly disclose “hot” and “cold” wallets, which KATZ however teaches at ¶[0318]: hot wallet and ¶[0238]: cold wallets.
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the digital access and control system/method of NIETO with the technique of KATZ, which, discloses architectures, systems and methods for program control utilizing cognitive computing involving wallets in order to effectual real-time wallet network transactions (KATZ [0318]) as contemplated in NIETO (see NIETO col. 2, ll. 2-6 discussing requests for ownership of digital assets in digital wallets and NIETO col. 4, ll. 50-57: generation of digital assets dropped into a digital wallet of a user ) and to safely store data related to assets in wallets (KATZ [0238]) contemplated in NIETO (see NIETO col. 2, ll. 2-6 discussing requests for ownership of digital assets in digital wallets and NIETO col. 4, ll. 50-57: generation of digital assets dropped into a digital wallet of a user ).
Regarding claim(s) 8 and 18,
NIETO and KATZ teach the limitations of 1 and 11.
NIETO further discloses:
wherein the asset control matches an access control for an enterprise entity that submitted the asset to the digital wallet system (NIETO: col. 13, ll. 10-26: In an embodiment, the smart contracts in the distributed ledger 231A also include states that track the progress of the smart contract as it is being executed. Smart contracts may be automatically executed when requirements associated with the digital assets are met. As one non-limiting example, a smart contract is a contract between a shoe manufacturer and its customers. The smart contract can specify that certain products or services (e.g., digital asset, physical product, early access to digital assets or physical products) can be made available to a customer based on a certain condition when performed by the customer.; col. 14, ll. 38-41: each generated digital asset is associated with its own smart contract that specifies the appearance, components, and other elements that are part of the digital asset.; col. 33, ll. 3-6: (153) One condition may be generating a physical product associated with the digital asset. In some embodiments, the enterprise may allow its customers to have direct access to control the production subsystem ; col. 16, ll. 20-26: Digital activation layer 230A may require a threshold amount of activity by a user in external systems 220 before being granted additional access to additional services such as backend layer 210 and production subsystem; col. 33, ll. 23-27: the enterprise may store different smart contracts on the blockchain related to direct access where each smart contract may be triggered based on conditions associated with the customer request and the customer; col. 33, ll. 35-45: Other examples of conditions include customizing the digital asset and transferring the digital asset for use in external systems 220. Customizing the digital asset may include updating the appearance of the digital asset based on real-world usage of a corresponding physical product, and on a user's online activities such as social media postings involving the digital asset. Transferring the digital asset for use with, for example, gamification component 222, may include allowing the digital asset to be digitally represented in video games on a user's device.; col. 33, ll. 45-51: (156) In 906, the digital activation layer 230A may determine the conditions of the smart contract that are triggered by the customer request such as the examples discussed above including direct access to production subsystem 212, customization of the digital asset, and transferring for use in external systems 22; col. 16, ll. 9-19: . Membership subsystem 232 may track each members interactions within the system, such as digital asset purchases, trades, burning, or any other activity with the digital activation layer 230A. Once a threshold level of activity is tracked by membership subsystem 232, digital activation layer 230A may provide the user access to backend layer 210 where it may then interact with the subsystems for producing physical products. This access may include enabling commands to be transmitted to backend layer 210).
Regarding claim(s) 9 and 19,
NIETO and KATZ teach the limitations of 1 and 11.
NIETO further discloses:
wherein the asset control indicates a security clearance level (NIETO: col. 22, ll. 6-21: (100) In some embodiments, certain components may be configured to perform operations with one or both of the private ledger 231B and the public ledger 231C based on the level of security required by the enterprise network 205. For example, digital wallet manager 233 may be configured to communicate only with the private ledger 231B because all transactions involving a digital wallet should be inaccessible to any users of the enterprise network. Similarly, authentication module 234 may also be configured to only communicate with the private ledger 231B. In contrast, membership subsystem 232 and digital asset subsystem 235 may be configured to communicate with public ledger 231C to perform operations that are accessible to users such as accessing their user information (via the membership subsystem 232) and their digital assets (via the digital asset subsystem 235).; col. 14, ll. 45-54: a particular user may have a heightened membership status that grants him privileges such as access to the production subsystem 212 which can produce the corresponding physical product.; col. 4, ll. 50-57: grant certain privileges to the user such as activities involving the digital asset (e.g., customization of digital assets, importation into third party applications; col. 16, ll. 55-61: Authentication module 234 may include components for authenticating users for joining and signing into the distributed ledger 231A as well as securing wallets associated with each user. In some embodiments, authentication module 234 may connect to an external authentication provider such as a provider that provides two-factor authentication in order to authenticate users.).
Regarding claim(s) 10 and 20,
NIETO and KATZ teach the limitations of 1 and 11.
NIETO further discloses:
wherein the asset control includes transactional detail requirements for the asset (NIETO: col. 32, ll. 60-67: 152) In 904, the digital activation layer 230A may retrieve a smart contract associated with the digital asset where the smart contract includes information and conditions associated with the digital asset. Information can include components of the digital asset and characteristics of the digital asset. Conditions can specify actions that can be performed by on the digital asset and milestones associated with the digital asset. The conditions may be triggered based on information in the user request.; col. 13, ll. 10-25: (65) In an embodiment, the smart contracts in the distributed ledger 231A also include states that track the progress of the smart contract as it is being executed. Smart contracts may be automatically executed when requirements associated with the digital assets are met. As one non-limiting example, a smart contract is a contract between a shoe manufacturer and its customers. The smart contract can specify that certain products or services (e.g., digital asset, physical product, early access to digital assets or physical products) can be made available to a customer based on a certain condition when performed by the customer. Examples of these conditions include performing certain activities with the digital or physical product, such as posting about the physical product or reaching a milestone with respect to number of followers or posts, or activities based on their user devices such as checking in to a physical store during a promotional period; col. 8, ll. 34-36: amount of funds in a user account meets a monetary threshold for a transaction).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20220253842 A1 to James; Daniel William Halley et al. discloses generating digital asset accounts and digital wallets and requests to transfer digital assets and hot and cold wallets.
US 20240129185 A1 to Shetye; Shruti Nitin et al. discloses assets in wallets that can be accessed and includes a control plane and data planet.
US 20220351188 A1 to FUKUHARA; Hiroshige et al. describes an asset transfer device 100 that may transmit the generated transaction data to the cold wallet 200, and the cold wallet 200 may sign the transaction data using the secret key. In this case, the cold wallet 200 transmits the signed transaction data to the digital asset transfer device 100.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BOLKO HAMERSKI whose telephone number is (571)270-7621. The examiner can normally be reached Monday-Friday 10:00 AM to 6:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, BENNETT SIGMOND can be reached at (303) 297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
BOLKO HAMERSKI
Examiner
Art Unit 3694
/BOLKO M HAMERSKI/ Examiner, Art Unit 3694
/BENNETT M SIGMOND/ Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights