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 . Claims 1-4, 6, 9-13, 15, and 18-20 are pending.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-4, 6, 9-13, 15, and 18-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 1 recites the limitation “the first IP Owner is allowed to sell the first IP token and the marketplace module is configured to list the IP token as available for purchase” on page 3. There is insufficient antecedent for “the marketplace module” in the claim. Appropriate correction is required.
Claim 12 recites the limitation “updating, by the backend application module, a token status field associated with the first IP token, wherein the token status field is stored on a blockchain ledger and dynamically updated by the server based on predefined token lifecycle rules”. There is insufficient antecedent for “the server” in the claim. Appropriate correction is required.
Dependent claims 2-4, 6, 9-11, 13, 15, and 18-20 are rejected by virtue of their dependency on claims 1 and 12 respectively.
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-4, 6, 9-13, 15, and 18-20 are rejected under 35 USC § 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture or composition of matter? MPEP 2106.03.
Per Step 1, claim 1 is directed to a system (i.e., a machine) and claim 12 is directed to a method (i.e., a process). Thus, the claims are directed to statutory categories of invention. However, the claims are rejected under 35 U.S.C. § 101 because they are directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The analysis proceeds to Step 2A Prong One.
Step 2A Prong One: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04.
The abstract idea of claim 1 is:
wherein the non- fungible IP token comprises metadata, including an IP identifier, usage duration, and token status field;
create a first IP license agreement template;
enable a first user to purchase a first IP token, wherein the first IP token is associated with a first IP Owner;
authenticate the first user using details associated with a first user crypto-wallet;
verify the presence of the first IP token in the first user crypto-wallet using a first IP token metadata;
receive first set of information from the first user;
create a Ready-to-Sign (RtS) first IP license agreement based on the first IP license agreement template, the first IP token metadata, and the first set of information;
request and receive signatures of the first IP Owner and the first user on the RtS first IP license agreement;
associate a dynamic token-status field with the first IP token, wherein the token-status field is automatically updated based on predefined on-chain rules triggered by token transfer events and usage duration conditions;
enforce status-dependent behavior as follows:
when the token-status field is set to "Available":
the first IP Owner is allowed to sell the first IP token and list the IP token as available for purchase;
the first user is allowed to purchase the first IP token and transfer of the IP token from the first IP Owner to a purchaser;
when the token-status field is set to "In-Use":
enables the first IP Owner to request a burn of the IP token;
transfer is permitted only to a verified second user, and the license agreement of the first user is terminated upon transfer; and
when the token-status field is set to "Expired”:
upon automated validation of expiration, transfer the IP to the first IP owner and terminates the associated IP license agreement.
The abstract idea of claim 12 is:
creating a first IP license agreement template;
enabling a first user to purchase a first IP token, wherein the first IP token is associated with a first IP Owner;
authenticating the first user using details associated with a first user crypto-wallet;
verifying the presence of the first IP token in the first user crypto-wallet using a first IP token metadata;
receiving first set of information from the first user;
creating a Ready-to-Sign (RtS) first IP license agreement based on the first IP license agreement template, the first IP token metadata, and the first set of information;
receiving signatures of the first IP Owner and the first user on the RtS first IP license agreement;
updating a token status field associated with the first IP token, based on predefined token lifecycle rules;
when the token-status field is set to "Available":
the first IP Owner is allowed to sell the first IP token and list the IP token as available for purchase;
the first user is allowed to purchase the first IP token and enables transfer of the IP token from the first IP Owner to a purchaser;
when the token-status field is set to "In-Use":
enables the first IP Owner to request a burn of the IP token;
transfer is permitted only to a verified second user, and the license agreement of the first user is terminated upon transfer; and
when the token-status field is set to "Expired":
restricts further transfers of the IP token to any wallet other than the first IP Owner's crypto-wallet; and
upon automated validation of expiration, transfers the IP to the first IP Owner and terminates the associated IP license agreement; and
recognizing the duly signed RtS first IP license agreement as the first IP license agreement.
The abstract idea steps italicized above recite tokenized contracting, purchasing, and licensing, which constitutes a process that, under its broadest reasonable interpretation (BRI), covers commercial activity. This is further supported by paragraphs 0002-0005 of applicant’s specification as filed. If a claim limitation, under its broadest reasonable interpretation, covers commercial interactions, including contracts, legal obligations, advertising, marketing, sales activities or behaviors, and/or business relations, then it falls within the Certain Methods of Organizing Human Activity – Commercial or Legal Interactions grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Additionally and alternatively, the claim recites data review and verification, as well as contract drafting which could be performed mentally, including with pen and paper. This is further supported by paragraphs 0002-0005 of applicant’s specification as filed. If a claim limitation, under its BRI, covers performance of the limitation in the mind, including observations, evaluations, judgements, and/or opinions, then it falls within the Mental Processes – Concepts Performed in the Human Mind grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong 2: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP §2106.04.
This judicial exception is not integrated into a practical application because the additional elements are merely instructions to apply the abstract idea to a computer, as described in MPEP §2106.05(f).
Claim 1 recites the following additional elements: server comprising one or more processors and a memory storing executable instructions that, when executed, causes the server to: invoke a licensing control module to: communicate with a blockchain network; and to mint, on a blockchain network, a non-fungible IP token; digital; stored immutably on the blockchain ledger; the marketplace module is configured to; the licensing module restricts further transfers of the IP token to any wallet other than the first IP Owner's crypto-wallet.
Claim 12 recites the following additional elements: backend application module; marketplace module; licensing module; document signing module, digital; wherein the token status field is stored on a blockchain ledger and dynamically updated by the server; executing, by the server and licensing module, token-status-based logic for enforcing the first IP license agreement; wallet; the server triggers a usage countdown timer associated with the IP token; crypto-wallet.
These elements are merely instructions to apply the abstract idea to a computer, per MPEP §2106.05(f). Applicant has only described generic computing elements in their specification, as seen in paragraphs 0031-0039 of applicant’s specification as filed, for example. Further, the combination of these elements is nothing more than a generic computing system.
Accordingly, these additional elements, alone and in combination, do not integrate the judicial exception into a practical application. The claim is directed to an abstract idea.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP §2106.05.
Step 2B involves evaluating the additional elements to determine whether they amount to significantly more than the judicial exception itself.
The examination process involves carrying over identification of the additional element(s) in the claim from Step 2A Prong Two and carrying over conclusions from Step 2A Prong Two on the considerations discussed in MPEP §2106.05(f).
The additional elements and their analysis are therefore carried over: applicant has merely recited elements that facilitates the tasks of the abstract idea, as described in MPEP §2106.05(f).
Further, the combination of these elements is nothing more than a generic computing system. When the claim elements above are considered, alone and in combination, they do not amount to significantly more.
Therefore, per Step 2B, the additional elements, alone and in combination, are not significantly more. The claims are not patent eligible.
Further, the analysis takes into consideration all dependent claims as well:
Claim 2 includes further additional elements with additional tasks that narrow the abstract idea: Licensing Control Module (LCM); backend application module; licensing module; marketplace module; document signing module; smart contract module. Similar to above, these additional elements do no more than apply the abstract idea to a computer, per MPEP 2106.05(f). When viewed alone or in combination, this does not integrate the abstract idea into practical application and is not significantly more.
Claim 3 includes further additional elements with additional tasks that narrow the abstract idea: file storage module. Similar to above, these additional elements do no more than apply the abstract idea to a computer, per MPEP 2106.05(f). When viewed alone or in combination, this does not integrate the abstract idea into practical application and is not significantly more.
Claims 6, 9, 15, and 18 include further additional elements with additional tasks that narrow the abstract idea: crypto-wallet. Similar to above, these additional elements do no more than apply the abstract idea to a computer, per MPEP 2106.05(f). When viewed alone or in combination, this does not integrate the abstract idea into practical application and is not significantly more.
Regarding claims 4, 10-11, 13, and 19-20, applicant further narrows the abstract idea with additional step(s). There are no further additional elements to consider, beyond those highlighted above. This further narrowing of the abstract idea, similar to above, is also not patent eligible.
Accordingly, claims 1-4, 6, 9-13, 15, and 18-20 are rejected under 35 USC § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 6, 9-13, 15, and 18-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Popham (US 20240313975) in view of Jakobsson (US 20230100422) in further view of Mackenzie (US 20210004923).
Claim 1
Regarding claim 1 Popham discloses:
A blockchain implemented system for facilitating the creation of an intellectual property (IP) license agreement associated with an IP token, the system comprising a server comprising one or more processors and a memory storing executable instructions that, when executed, causes the server to {“Systems and methods for generating and providing template contract agreements for transactions involving one or more assets are disclosed.” (paragraph 0011). “The distributed ledger system 106 utilizes blockchain technology to accept entries in a secure, verifiable manner, such as document obfuscation values associated with the licensing agreements.” (paragraph 0030). “The electronic devices 102 may include components such as, for example, one or more processors 112, one or more network interfaces 114, and/or memory 116 […] and/or one or more servers” (paragraph 0031).}
invoke a licensing control module to: communicate with a blockchain network {The system generates hash values and root hashes for licensing agreements and sends those values, along with signatures and smart contracts, to a blockchain system managing blockchains (paragraphs 0012-0014, 0024-0025, 0030).}
to mint, on a blockchain network, a non-fungible IP token {Digital tokens identified as non-fungible, bearing a unique token ID and smart contract address, are created (i.e., minted) and registered on a blockchain (paragraphs 0022, 0025, 0049).}
create a first IP license agreement template {The system enables the creation of template license agreements with predefined terms and allows providers to select and store these templates (paragraphs 0011, 0014, 0038, 0099, 0102).}
invoke the licensing control module to: enable a first user to purchase a first IP token, wherein the first IP token is associated with a first IP Owner {The system enables a user to purchase a digital asset (e.g., NFT) associated with an IP owner (i.e., provider/creator) (paragraphs 0016, 0037).}
authenticate the first user using details associated with a first user crypto-wallet {The system supports receiving and using wallet address and keypair data for user authentication (paragraphs 0015, 0058).}
verify the presence of the first IP token in the first user crypto-wallet using a first IP token metadata {The system may check metadata (e.g., tokenID) and ownership information from ERC-721 tokens to identify asset ownership (paragraph 0022).}
receive first set of information from the first user {Users can provide data via user interface for generating license agreements (paragraphs 0015, 0026, 0057, 0109).}
create a Ready-to-Sign (RtS) first IP license agreement based on the first IP license agreement template, the first IP token metadata, and the first set of information {The system generates licensing agreements using template terms, token metadata (e.g., collection ID, contract address), and data provided by a user. The user can review and agree to the terms of the contract (i.e., the contract is RtS) (paragraphs 0011, 0017, 0022, 0024, 0038).}
request and receive digital signatures of the first IP Owner and the first user on the RtS first IP license agreement {Signatures can be gathered via keypairs from both the user and the system (e.g., provider or IP owner) and storage them on the blockchain (paragraphs 0024, 0051-0052, 0117).}
enforce status-dependent behavior as follows: when the token-status field is set to "Available" {The system tracks token ownership and transaction lifecycle states via blockchain registration and smart contract data (paragraphs 0025, 0051).}
the first IP Owner is allowed to sell the first IP token and the marketplace module is configured to list the IP token as available for purchase {A provider selects assets and/or licensing agreements for sale and the system determines the transaction and/or listing (paragraphs 0037-0039).}
Popham does not disclose:
wherein the non- fungible IP token comprises metadata, including an IP identifier, usage duration, and token status field;
associate a dynamic token-status field with the first IP token, wherein the token- status field is stored immutably on the blockchain ledger and is automatically updated based on predefined on-chain rules triggered by token transfer events and usage duration conditions;
the first user is allowed to purchase the first IP token and the server enables transfer of the IP token from the first IP Owner to a purchaser wallet;
when the token-status field is set to "In-Use";
the server enables the first IP Owner to request a burn of the IP token;
transfer is permitted only to a verified second user wallet, and the license agreement of the first user is terminated upon transfer;
the server triggers a usage countdown timer associated with the IP token;
when the token-status field is set to "Expired";
the licensing module restricts further transfers of the IP token to any wallet other than the first IP Owner's crypto-wallet;
upon automated validation of expiration, the server transfers the IP token to the first IP Owner's crypto-wallet and terminates the associated IP license agreement.
However, Jakobsson, in a similar field of endeavor directed to enabling transactions surround the transfer and use of tokens, teaches:
associate a dynamic token-status field with the first IP token, wherein the token- status field is stored immutably on the blockchain ledger and is automatically updated based on predefined on-chain rules triggered by token transfer events and usage duration conditions {Non-fungible tokens are managed via smart contracts deployed on a blockchain, where predefined on-chain rules are automatically executed upon detection of token ownership transfer events, including enforcing restrictions on token use or transfer (paragraphs 0063-0065 ). NFTs are associated with rules and policies defining usage terms, royalty requirements, and transfer restrictions, and an identifier is linked to a blockchain entry to express ownership status (i.e., on-chain governance) (paragraph 0250). Further, the system applies time or license conditions to tokens, such that access to or use of a token is governed by predefined temporal constraints enforced by smart contract logic (paragraphs 0299-0301 ).}
the first user is allowed to purchase the first IP token and the server enables transfer of the IP token from the first IP Owner to a purchaser wallet {“the system may determine that the user has selected to purchase a digital asset from the provider” (paragraph 0016). The platform permits a user to engage in a purchase transaction and the server enables transfer of the token from an owner wallet to a purchaser wallet in accordance with smart contract rules (paragraphs 0280-0281 ).}
when the token-status field is set to "In-Use" {The concept of usage states that determine whether a token is active and whether specific actions are permitted is described by discussing temporary access rights (paragraphs 0280-0281 ).}
the server enables the first IP Owner to request a burn of the IP token {Burning tokens is possible by transferring the unusable addresses and details techniques to make such transfers verifiably irreversible (paragraph 0350).}
when the token-status field is set to "Expired" {The system supports token access control based on time (i.e., time-based status for token usability) (paragraph 0280).}
the licensing module restricts further transfers of the IP token to any wallet other than the first IP Owner's crypto-wallet {When abuse or unauthorized transfers are detected, ownership of tokens can be reversed to the original creator (paragraph 0350).}
upon automated validation of expiration, the server transfers the IP token to the first IP Owner's crypto-wallet and terminates the associated IP license agreement {The system may prevent the transfer of tokens based on policy conditions, including time-based triggers (i.e., expiration) (paragraph 0332).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the contract agreement generation for tokenized assets features of Popham to include the time-based token control features of Jakobsson, to streamline enforcement of agreements, thereby facilitating IP holders to obtain royalties for future sales of content they have created. (see paragraph 0003 of Jakobsson).
The combination of Popham and Jakobsson does not teach:
wherein the non- fungible IP token comprises metadata, including an IP identifier, usage duration, and token status field;
transfer is permitted only to a verified second user wallet, and the license agreement of the first user is terminated upon transfer; and
the server triggers a usage countdown timer associated with the IP token.
However, Mackenzie, in a similar field of endeavor directed to distributed ledger system for storing and providing information/data corresponding to managed assets, teaches:
wherein the non- fungible IP token comprises metadata, including an IP identifier, usage duration, and token status field {Smart contracts are executed on a blockchain distributed ledger to record, update, and manage IP asset information and associated metadata, including an IP asset identifier, time information (i.e., renewal and expiration dates), and status indicators (e.g., granted, licensed, expired) (paragraphs 00150-0151, 0195-0196).}
transfer is permitted only to a verified second user wallet, and the license agreement of the first user is terminated upon transfer {The system executes a smart contract to transfer an IP asset from a first user to a second user, with the transaction recorded on the distributed ledger and the asset status updated to reflect the new ownership (i.e., ending the prior license) (paragraphs 0172-0173).}
the server triggers a usage countdown timer associated with the IP token {A node generates and executes a smart contract for an IP license that includes temporal terms, and enforces those terms over time as the license is executed and recorded on the distributed ledger (paragraphs 0165, 0172-0173).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Popham and Jakobsson to include the intangible assets management using distributed ledgers features of Mackenzie, to improve visibility, transparency, and accuracy of IP data to facilitate and expedite IP asset management. (see paragraph 0003 of Mackenzie).
Claim 12
Regarding claim 1 Popham discloses:
A method for facilitating the creation of an intellectual property (IP) license agreement associated with an IP token, the method comprising the steps of: {“Systems and methods for generating and providing template contract agreements for transactions involving one or more assets are disclosed.” (paragraph 0011).}
creating, by a backend application module, a first IP license agreement template {The system enables the creation of template license agreements with predefined terms and allows providers to select and store these templates (paragraphs 0011, 0014, 0038, 0099, 0102).}
enabling, by a marketplace module, a first user to purchase a first IP token, wherein the first IP token is associated with a first IP Owner {The system enables a user to purchase a digital asset (e.g., NFT) associated with an IP owner (i.e., provider/creator) (paragraphs 0016, 0037).}
authenticating, by a licensing module, the first user using details associated with a first user crypto-wallet {The system supports receiving and using wallet address and keypair data for user authentication (paragraphs 0015, 0058).}
verifying, by the licensing module, the presence of the first IP token in the first user crypto-wallet using a first IP token metadata {The system may check metadata (e.g., tokenID) and ownership information from ERC-721 tokens to identify asset ownership (paragraph 0022).}
receiving, by the licensing module, first set of information from the first user {Users can provide data via user interface for generating license agreements (paragraphs 0015, 0026, 0057, 0109).}
creating, by the backend application module, a Ready-to-Sign (RtS) first IP license agreement based on the first IP license agreement template, the first IP token metadata, and the first set of information {The system generates licensing agreements using template terms, token metadata (e.g., collection ID, contract address), and data provided by a user. The user can review and agree to the terms of the contract (i.e., the contract is RtS) (paragraphs 0011, 0017, 0022, 0024, 0038).}
receiving, by a document signing module, digital signatures of the first IP Owner and the first user on the RtS first IP license agreement {Signatures can be gathered via keypairs from both the user and the system (e.g., provider or IP owner) and storage them on the blockchain (paragraphs 0024, 0051-0052, 0117).}
when the token-status field is set to "Available" {The system tracks token ownership and transaction lifecycle states via blockchain registration and smart contract data (paragraphs 0025, 0051).}
the first IP Owner is allowed to sell the first IP token and the marketplace module is configured to list the IP token as available for purchase {A provider selects assets and/or licensing agreements for sale and the system determines the transaction and/or listing (paragraphs 0037-0039).}
Popham does not disclose:
updating, by the backend application module, a token status field associated with the first IP token, wherein the token status field is stored on a blockchain ledger and dynamically updated by the server based on predefined token lifecycle rules;
executing, by the server and licensing module, token-status-based logic for enforcing the first IP license agreement, wherein;
the first user is allowed to purchase the first IP token and the server enables transfer of the IP token from the first IP Owner to a purchaser wallet;
when the token-status field is set to "In-Use";
the server enables the first IP Owner to request a burn of the IP token;
transfer is permitted only to a verified second user wallet, and the license agreement of the first user is terminated upon transfer;
the server triggers a usage countdown timer associated with the IP token;
when the token-status field is set to "Expired";
the licensing module restricts further transfers of the IP token to any wallet other than the first IP Owner's crypto-wallet;
upon automated validation of expiration, the server transfers the IP token to the first IP Owner's crypto-wallet and terminates the associated IP license agreement;
recognizing the duly signed RtS first IP license agreement as the first IP license agreement.
However, Jakobsson, in a similar field of endeavor directed to enabling transactions surround the transfer and use of tokens, teaches:
the first user is allowed to purchase the first IP token and the server enables transfer of the IP token from the first IP Owner to a purchaser wallet {“the system may determine that the user has selected to purchase a digital asset from the provider” (paragraph 0016). The platform permits a user to engage in a purchase transaction and the server enables transfer of the token from an owner wallet to a purchaser wallet in accordance with smart contract rules (paragraphs 0280-0281).}
when the token-status field is set to "In-Use": {The concept of usage states that determine whether a token is active and whether specific actions are permitted is described by discussing temporary access rights (paragraphs 0280-0281).}
the server enables the first IP Owner to request a burn of the IP token {Burning tokens is possible by transferring the unusable addresses and details techniques to make such transfers verifiably irreversible (paragraph 0350).}
when the token-status field is set to "Expired" {The system supports token access control based on time (i.e., time-based status for token usability) (paragraph 0280).}
the licensing module restricts further transfers of the IP token to any wallet other than the first IP Owner's crypto-wallet {When abuse or unauthorized transfers are detected, ownership of tokens can be reversed to the original creator (paragraph 0350).}
upon automated validation of expiration, the server transfers the IP token to the first IP Owner's crypto-wallet and terminates the associated IP license agreement {The system may prevent the transfer of tokens based on policy conditions, including time-based triggers (i.e., expiration) (paragraph 0332).}
recognizing the duly signed RtS first IP license agreement as the first IP license agreement {The smart contract system enforces rules and transactions based on agreements recorded on a blockchain. The smart contract execution includes the use of digital signatures and enforcement of terms programmatically. Digital signatures are used to validate transactions and contractual commitments (i.e., digitally signed agreements are treated as binding). (paragraphs 0160, 0179).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the contract agreement generation for tokenized assets features of Popham to include the time-based token control features of Jakobsson, to streamline enforcement of agreements, thereby facilitating IP holders to obtain royalties for future sales of content they have created. (see paragraph 0003 of Jakobsson).
The combination of Popham and Jakobsson does not teach:
updating, by the backend application module, a token status field associated with the first IP token, wherein the token status field is stored on a blockchain ledger and dynamically updated by the server based on predefined token lifecycle rules;
executing, by the server and licensing module, token-status-based logic for enforcing the first IP license agreement, wherein;
the server triggers a usage countdown timer associated with the IP token;
transfer is permitted only to a verified second user wallet, and the license agreement of the first user is terminated upon transfer.
However, Mackenzie, in a similar field of endeavor directed to distributed ledger system for storing and providing information/data corresponding to managed assets, teaches:
updating, by the backend application module, a token status field associated with the first IP token, wherein the token status field is stored on a blockchain ledger and dynamically updated by the server based on predefined token lifecycle rules {The system executes a smart contract and records transaction details on a blockchain ledger, including a status indicator associated with the IP asset to reflect changes such as licensing, assignment, renewal, or expiration (paragraphs 0173-0174). Because the smart contract is executed by the server based on predefined agreement terms, the asset status stored on the ledger is dynamically updated according to token lifecycle rules (paragraphs 0165-0166, 0199).}
executing, by the server and licensing module, token-status-based logic for enforcing the first IP license agreement, wherein: {A server executes a smart contract for an IP license agreement, where the smart contract enforces the license terms during execution (paragraphs 0164-0165, 0173). Enforcement is based on an updated status indicator of the I asset recorded on the blockchain, such that the server applies logic according to the current licensed status (paragraph 0173, 0199).}
the server triggers a usage countdown timer associated with the IP token {A node generates and executes a smart contract for an IP license that includes temporal terms, and enforces those terms over time as the license is executed and recorded on the distributed ledger (paragraphs 0165, 0172-0173).}
transfer is permitted only to a verified second user wallet, and the license agreement of the first user is terminated upon transfer {The system executes a smart contract to transfer an IP asset from a first user to a second user, with the transaction recorded on the distributed ledger and the asset status updated to reflect the new ownership (i.e., ending the prior license) (paragraphs 0172-0173).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Popham and Jakobsson to include the intangible assets management using distributed ledgers features of Mackenzie, to improve visibility, transparency, and accuracy of IP data to facilitate and expedite IP asset management. (see paragraph 0003 of Mackenzie).
Claim 2
Regarding claim 2, the combination of Popham, Jakobsson, and Mackenzie teaches the limitations set forth above. Popham further discloses:
a backend application module configured to:
create the first IP license agreement template; and create the RtS first IP license agreement; {A licensing agreement component of the system enables the creation of template licenses and the generation of RtS agreements with selected terms and metadata (paragraphs 0011, 0037-0038, 0108).}
a licensing module configured to:
authenticate the first user, using details associated with the first user crypto-wallet; verify the presence of the first IP token in the first user crypto-wallet using the first IP token metadata; and receive from the first user the first set of information; {A verification component authenticates via wallet/KYC, combined with the use of token metadata, and wizards 142 to receive user input (paragraphs 0015, 0022, 0057).}
a marketplace module configured to enable the first user to buy the first IP token, wherein the first IP token is associated with the first IP Owner; {A third-party marketplace system and its marketplace component allows users to acquire NFTs associated with IP, and is integrated with the licensing process (paragraphs 0013, 0016, 0039, 0061).}
a document signing module configured to receive digital signatures of the first IP Owner and the first user on the RtS first IP license agreement; and {An electronic signature component receives and applies signatures from both parties via keypairs/wallet addresses (paragraphs 0024, 0051-0052).}
a smart contract module configured to enforce the first IP license agreement, wherein duly signed RtS first IP license agreement is considered the first IP license agreement. {A smart contract generation and blockchain registration process via the hashing component, electronic component, and asset registry enforces signed IP license agreements (paragraphs 0024-0025, 0083, 0129).}
Claim 3
Regarding claim 3, the combination of Popham, Jakobsson, and Mackenzie teaches the limitations set forth above. Popham further discloses:
store the first IP license agreement template in a file storage module; and retrieve the first IP license agreement template from the file storage module. {Licensing agreement component is configured to generate and store license agreement templates, and later retrieve them for use in transactions (i.e., storage and retrieval through association with digital assets and the reuse of predefined templates) (paragraphs 0037, 0038, 0050, 0055, 0102).}
Claims 4 and 13
Regarding claims 4 and 13, the combination of Popham, Jakobsson, and Mackenzie teaches the limitations set forth above. Popham further discloses:
receive a first Intellectual Property (IP) along with an IP tokenization request from the first IP owner; {The system supports receiving creative works and preparing digital assets (e.g., NFTs) based on IP from providers (paragraphs 0011-0012).}
receive terms and conditions of usage from the first IP Owner; {“The licensing agreement component 134 of the system 104 may receive one or more licensing terms from a digital asset provider” (paragraph 0037).}
generate visuals and metadata for the received first IP; {The system supports the creation and management of token metadata through NFTs (paragraphs 0022, 0037, 0049).}
retrieve an IP license agreement template; {“the licensing agreement component 134 may enable the provider to select from a list of template license agreements that each have existing terms” (paragraph 0038).}
create first smart contract functionalities for the first IP;{The system generates smart contracts tie to the IP/license (paragraphs 0051, 0108).}
receive a usage duration and royalty parameters from the first IP Owner; {The system receives term length and compensation (i.e., royalty) data from the provider (paragraphs 0042-0043).}
setup a first smart contract metadata; {The metadata used in smart contracts includes license terms, blockchain ID, collection ID, and signature data (paragraph 0049).}
generate the first IP token; and {NFT/token generation is part of the overall system function (paragraph 0022).}
transfer the generated first IP token to a marketplace via the marketplace module, wherein the marketplace module is configured to enable the first user to purchase the generated first IP token that is transferred to the marketplace. {Marketplace integration is detailed using the third-party marketplace system and the marketplace component (paragraphs 0032, 0037, 0061).}
Claims 6 and 15
Regarding claims 6 and 15, the combination of Popham, Jakobsson, and Mackenzie teaches the limitations set forth above. Mackenzie further teaches:
retrieve the first IP token to a first IP Owner crypto-wallet; and {Stored data in the distributed ledger maintains transparency of ownership details throughout the lifecycle of the IP asset (paragraphs 0097-0098, 0108).}
update the first IP token status to Available from Expired. {The server updates the asset’s status indicator in the distributed ledger (paragraphs 0108, 0174).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Popham, Jakobsson, and Mackenzie to include the intangible assets management using distributed ledgers features of Mackenzie, to improve visibility, transparency, and accuracy of IP data to facilitate and expedite IP asset management. (see paragraph 0003 of Mackenzie).
Claims 9 and 18
Regarding claims 9 and 18, the combination of Popham, Jakobsson, and Mackenzie teaches the limitations set forth above. Jakobsson further teaches:
wherein the server, when the usage countdown ends, is configured to: transfer the first IP token to a first IP Owner crypto-wallet; and {The system supports transferring back tokens to their creators as a security action when conditions in time are not met (paragraphs 0329-0330).}
terminate the first IP license agreement. {Some security actions may be non-reversible regarding a token (i.e., license agreement) which include reverting ownership to the original creator, for example (paragraph 0350).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Popham, Jakobsson, and Mackenzie to include the time-based token control features of Jakobsson, to facilitate content creators to obtain royalties for future sales of content they have created. (see paragraph 0003 of Jakobsson).
Claims 10 and 19
Regarding claims 10 and 19, the combination of Popham, Jakobsson, and Mackenzie teaches the limitations set forth above. Jakobsson further teaches:
wherein the server is configured to receive a burn request, wherein upon receiving the burn request, the server is configured to:
transfer the first IP token to an inaccessible crypto-address; {Some irreversible security actions may include sending tokens to burn addresses (paragraph 0350).}
terminate the first IP license agreement. {Some security actions may be non-reversible regarding a token (i.e., license agreement) which include reverting ownership to the original creator, for example (paragraph 0350).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Popham, Jakobsson, and Mackenzie to include the time-based token control features of Jakobsson, to facilitate IP holders to obtain royalties for future sales of content they have created. (see paragraph 0003 of Jakobsson).
Claims 11 and 20
Regarding claims 11 and 20, the combination of Popham, Jakobsson, and Mackenzie teaches the limitations set forth above. Jakobsson further teaches:
transfer the first IP token to a first IP trader from the first IP Owner {Intermediaries (i.e., traders) can facilitate token transfers from one party to another (paragraph 0278).}
enable the first user to purchases the first IP token from the first IP trader {Intermediaries designate tokens for new users (i.e., buyers), which includes enabling purchases through approved marketplaces (paragraphs 0278-0279).}
request and receive digital signatures from the first IP Owner and the first user on the RtS first IP license agreement upon purchase of the first IP token from the first IP trader {Digital signatures are used to verify anchors and token identity during transactions. Signature verification forms part of the control logic tied to policy enforcement and token usage authorization (paragraphs 0269, 0276).}
begin a usage countdown upon receiving digital signatures from the first IP Owner and the first user on the RtS first IP license agreement. {The system may provide temporary authorization to access content (e.g., rentals or usage), with access controlled by expiration dates or usage counts (i.e., usage countdown) (paragraph 0280).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Popham, Jakobsson, and Mackenzie to include the time-based token control features of Jakobsson, to facilitate IP holders to obtain royalties for future sales of content they have created. (see paragraph 0003 of Jakobsson).
Response to Arguments
Applicant’s arguments filed on 10/22/2025 have been carefully considered.
Claim Objections
The original claim objections have been withdrawn in view of Applicant’s amendments to the respective claims.
Rejections under 35 U.S.C. §101
Applicant’s arguments are not persuasive. The recited blockchain components are invoked in support of managing license availability, usage, transfer, and termination (i.e., automating contractual relationships), rather than improving the operation of the blockchain itself. Accordingly, the claims recite an abstract idea.
While the claims recite execution on a blockchain and the use of smart contracts with token status fields, these elements are used as tools to implement and enforce licensing rules. These values function as business rule conditions, not as a technological improvement to the computer infrastructure. The claims do not recite a specific improvement the technology.
The claims use blockchain and smart contracts only as a general computing environment to carry out licensing and enforcing rules. The claims do not improve how a blockchain, smart contract, or consensus protocol operates, but merely rely on their known functions to automate contractual behavior. Using a blockchain as the platform for implementing licensing logic does not make the claims tied to a particular machine in a meaningful way under MPEP §2106.05 (c).
Examiner notes that the eligibility analysis on the alluded Office Action is based exclusively on MPEP §2106.05 (f), and not on a determination on whether the invention is tied to a particular machine, or on whether the additional elements are well-understood, routine, or conventional.
Assertions regarding novelty, unconventionality, or inventive arrangement do not overcome the rejection where the claims fail to integrate the abstract idea into a practical application. Accordingly, the eligibility analysis remains unaltered.
Therefore, the rejection under 35 U.S.C. §101 is maintained.
Rejections under 35 U.S.C. §103
Applicant’s arguments are not persuasive. Popham discloses ERC-721 metadata including tokenID, contract address, and owner stored on-chain (see [0022]). In ERC-721 systems, verifying that a token is present in a user wallet is performed by querying ownership using this metadata. The claim does not recite any specific verification logic beyond using token metadata. Applicant’s distinction between “passive storage” and “active verification” improperly imports limitations not recited in the claim.
Applicant’s arguments are unpersuasive when the references are considered in combination. Mackenzie teaches ledger IP asset lifecycle/status tracking, and Jakobsson teaches programmatic enforcement of transfer and access restriction based on token conditions and expiration. Popham teaches binding IP licensing terms to NFTs via smart contracts. Together, these references teach or suggest associating tokens with lifecycle states on-chain and enforcing licensing and transfer behavior based on those states. The specific labels (e.g., “Available”, “In-Use”, “Expired”) are non-limiting and represent predictable lifecycle states.
Automated termination of rights and prevention of further transfers upon expiration are taught by Jakobsson, and ledger ownership and status changes are taught by Mackenzie. Reverting control to the IP owner upon expiration is an obvious implementation once expiration enforcement is known.
Each reference addresses complementary aspects of blockchain IP NFT management. A POSITA would have been motivated to combine Popham’s licensing framework with Jakobsson’s enforcement mechanisms and Mackenzie’s lifecycle tracking to achieve automated IP license control, consistent with KSR.
Accordingly, the rejection under 35 U.S.C. §103 is maintained.
Conclusion
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 CARLOS F MONTALVO whose telephone number is (703)756-5863. The examiner can normally be reached Monday - Friday 8:00AM - 5:30PM; First Fridays OOO.
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, Sarah Monfeldt can be reached at 571-270-1833. 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.
/C.F.M./ Examiner, Art Unit 3629 /SARAH M MONFELDT/Supervisory Patent Examiner, Art Unit 3629