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, 3, and 5-19 are pending.
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.
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 device (i.e., a machine) and claim 19 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 claims 1 and 19 (claim 1 being representative) is:
receive a rental request corresponding to a first token;
perform a procedure of generating a second token based on the rental request;
wherein the first token is generated based on a first smart contract configured to prove ownership of the digital asset,
wherein first metadata of the first token indicates an owner having the ownership of the digital asset,
wherein the second token is generated based on a second smart contract configured to prove a right of use of the digital asset,
wherein second metadata of the second token indicates a person having the right of use of the digital asset,
wherein generation information of the second token indicating a rental history of the digital asset is recorded in the first metadata of the first token, based on generation of the second token,
wherein the one or more processors are further configured to:
receive a usage log indicating a usage history of the digital asset; and
in response to reception of the usage log, perform (i) a recording procedure of recording the usage log for the first token in the first metadata of the first token and (ii) a procedure to transmit, as an incentive for the usage log, assets corresponding to at least a portion of assets recorded in the first token to a person having the right of use, and
wherein the recording procedure comprises an operation of transmitting, a recording request requesting to execute the first smart contract.
The abstract idea steps italicized above recite a rental transaction and transfer of usage rights based on licenses, implemented via smart contracts, which constitutes a process that, under its broadest reasonable interpretation (BRI), covers commercial activity. This is further supported by paragraph [0005 - 0008] of applicant’s specification as filed. If a claim limitation, under its BRI, 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 receiving a request, generating a record of ownership vs. usage rights, and updating data indicating rental or usage history, which could be performed mentally, including with pen and paper. This is further supported by paragraph [0005 - 0008] 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: electronic device; a communication interface configured to communicate with at least one node of a blockchain network and an external device; one or more memories configured to store at least one instruction; one or more processors communicatively coupled to the communication interface and to the one or more memories; from a user terminal of a user; digital asset; to an external webpage indicated by a link; virtual; wallet address; to the at least one node of the blockchain network.
Claim 19 recites the following additional elements: from a user terminal of a user; digital asset; to an external webpage indicated by a link; virtual; wallet address; to the at least one node of the blockchain network.
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 paragraph [0145] 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:
Regarding claims 3, 5, 7-14, and 16-18, 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.
Claim 6 includes further additional elements: from an external terminal distinguished from the user terminal; block. 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 15 includes further additional elements: from a user terminal of the owner of the digital asset. 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.
Accordingly, claims 1, 3, and 5-19 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, 3, 5-7, 10-14, and 16-18 are rejected under 35 U.S.C. § 103 as being unpatentable over Stephens (US 20220358450) in view of Tran (US 20220040557).
Claims 1 and 19
Regarding claims 1 and 19 Stephens discloses (claim 1 being representative):
(claim 1) An electronic device, comprising: a communication interface configured to communicate with at least one node of a blockchain network and an external device; {User devices can communicate with distributed ledgers (e.g., blockchain networks) and external components. These devices include network interfaces enabling communications with blockchain nodes and external devices (paragraphs 0035, 0039, 0100-0102).}
(claim 1) one or more memories configured to store at least one instruction; and {“The system includes a memory and one or more processors (e.g., implemented in circuitry) coupled to the memory.” These processors are configured to execute instructions. (paragraph 0006).}
(claim 1) one or more processors communicatively coupled to the communication interface and to the one or more memories, wherein the one or more processors are configured to execute the at least one instruction to: {User devices “may include standard hardware computing components such as, but not limited to network and media interfaces, non-transitory computer-readable storage (memory), and processors for executing instructions that may be stored in memory.” (paragraph 0039).}
(claim 19) A method performed by an electronic device, comprising: {“Aspects of the present technology include systems and methods for creating, modifying, tracking, authenticating, and/or transferring unique digital assets” (paragraph 0005). “The present methodologies described herein are fully intended to be operable on a variety of devices” (e.g. electronic devices) (paragraph 0161).}
receive, from a user terminal of a user, a rental request for a digital asset corresponding to a first token {The system allows for requesting a token rental (i.e., digital asset) (paragraph 0102).}
perform a procedure of generating a second token based on the rental request {The digital asset management engine may grant a provisional license to use the token by means of a token smart contract (paragraph 0102).}
wherein the first token is generated based on a first smart contract configured to prove ownership of the digital asset {The token is generated based on a smart contract, and the smart contract manages ownership of the corresponding digital asset. Ownership transfer and validation are also governed by the smart contract, which confirms that the token corresponds to a valid digital asset and manages transfer of ownership via blockchain ledger entries. (paragraphs 0061, 0099, 0103.}
wherein first metadata of the first token indicates an owner having the ownership of the digital asset {The token ownership element represents ownership of the associated digital asset, and this ownership data is part of the metadata structure stored with the token in the blockchain (paragraphs 0071, 0074).}
wherein the second token is generated based on a second smart contract configured to prove a right of use of the digital asset {The smart contract defines conditions under which a user may temporarily use the digital asset (i.e., right of use rather than ownership) (paragraphs 0071, 0102).}
wherein second metadata of the second token indicates a person having the right of use of the digital asset {The system enables assignment of a right to use a digital asset to a second user, and such assignment is recorded as part of the token’s metadata or as part of a transaction tracked in the distributed ledger. The person having the right of use is identifiable from the metadata of the token (paragraphs 0061, 0076, 0102).}
wherein generation information of the second token indicating a rental history of the digital asset is recorded in the first metadata of the first token, based on generation of the second token. {When a digital asset is rented via a second token (e.g., rental or license token), the corresponding transaction is recorded in the history of the original (first) token associated with that digital asset. The history, stored as metadata, includes past ownership and usage events linked to smart contract actions and token generation (paragraphs 0061, 0076, 0102).
Stephen does not disclose:
receive, from the user terminal of the user, a usage log indicating a usage history of the digital asset; and
in response to reception of the usage log, perform (i) a recording procedure of recording the usage log for the first token to an external webpage indicated by a link in the first metadata of the first token and (ii) a procedure to transmit, as an incentive for the usage log, virtual assets corresponding to at least a portion of virtual assets recorded in the first token to a wallet address of the person having the right of use, and
wherein the recording procedure comprises an operation of transmitting, to the at least one node of the blockchain network, a recording request requesting to execute the first smart contract.
However, Tran, in a similar field of endeavor directed to IoT devices security, teaches:
receive, from the user terminal of the user, a usage log indicating a usage history of the digital asset {The system receives and monitors usage and transaction information associated with a digital asset via ledger monitoring and lifecycle recording on the blockchain (paragraphs 0178 - 0180).}
in response to reception of the usage log, perform (i) a recording procedure of recording the usage log for the first token to an external webpage indicated by a link in the first metadata of the first token {The system records asset data to a public ledger by sending a transaction to a smart contract including metadata and generating an entry in the blockchain (paragraphs 0320, 0772 – 0774).}
(ii) a procedure to transmit, as an incentive for the usage log, virtual assets corresponding to at least a portion of virtual assets recorded in the first token to a wallet address of the person having the right of use {Blockchain value is transmitted as a reward or incentive by conducting transactions against a blockchain address and transferring funds or tokens to a wallet address (paragraphs 0183, 0201).}
wherein the recording procedure comprises an operation of transmitting, to the at least one node of the blockchain network, a recording request requesting to execute the first smart contract {The system transmits a transaction to blockchain network nodes for execution and validation of a smart contract (i.e., generating a ledger entry) (paragraphs 0320, 0774).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the non-fungible digital assets creation and management features of Stephen to include the IoT secure operation features of Tran, to more effectively manage the data generated by IoT devices and therefore reduce potential disruptions to the Internet. (See paragraph 0002 of Tran).
Claim 3
Regarding claim 3, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
wherein the second metadata of the second token further indicates a rental period of the digital asset, and {Tokens can be associated with rental terms and durations through smart contracts, and that digital asset rental may be implemented without transferring ownership or via temporary ownership transfer for a defined period. These terms are managed by token smart contracts, which govern conditions such as rental duration (paragraph 0102).}
wherein the one or more processors are further configured to perform the recording procedure of recording the usage log of the first token based on whether a time point at which the recording request is transmitted is within the rental period. {The system may enforce rental periods via token smart contracts and record actions or history tied to token usage. The system reverts ownership after the rental period expires (i.e., usage history is recorded while rental is valid) (paragraphs 0082, 0102).}
Claim 5
Regarding claim 5, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
wherein the usage log comprises at least one of information on the person having the right of use, information on content using the digital asset, information on an aspect of using the digital asset, or information on a time point at which the digital asset is used. {The token history includes entries identifying the user having the right of use, specific content involving the digital asset, aspects of usage, and timestamp of such usage. These entries are shown in the item history interface and are tracked in the distributed ledger via the token (paragraph 0082).}
Claim 6
Regarding claim 6, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
receive, from an external terminal distinguished from the user terminal, a verification request for the second token; {Computing devices other than the original user terminal may submit requests to validate tokens or transactions. These devices participate in verifying smart contract execution and token payloads by verifying token data (e.g., second token) on the distributed ledger. (paragraphs 0064-0065, 0105).}
compare the second metadata of the second token with information recorded in a block corresponding to the second token based on the verification request; and {A verifying device can compute a hash of off-chain metadata and compare it to a stored hash recorded on-chain to verify the accuracy of the metadata. This comparison is part of a verification process that confirms the token refers to a valid digital asset. The stored hash resides in a block corresponding to the token (i.e., “based on the verification request”) (paragraphs 0061, 0063, 0078).}
transmit, to the external terminal, based on the second metadata of the second token matching the information recorded in the block, at least one of a first address of the first token, a second address of the second token, an identifier of the second token, a signature of the person having the right of use, or a temporary value, {When the second metadata matches the on-chain information, verification is successful and may trigger transmission of associated token data. The system supports transmission of metadata, ownership, token identifiers, and related information through an API to external devices (paragraph 0061, 0072, 0100, 0101, 0127).}
wherein the temporary value is a randomly changed value based on reception of the verification request. {Each block header may include “one or more randomized nonce values, a counter identifying how many nonces have been tried”, which are generated based on payload elements and included during block generation. These nonce values are computed in response to receiving a request to verify and append a payload element (e.g., token) (paragraphs 0060, 0064).}
Claim 7
Regarding claim 7, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
wherein, based on the second metadata of the second token matching the information recorded in the block, information indicating the usage history of the digital asset is recorded in the first metadata of the first token as the usage log. {Metadata from different tokens can be matched to existing blockchain entries to verify access rights. Once validated, the usage of the digital asset may be recorded in the metadata of the original token as a usage log (paragraphs 0064-0065, 0076, 0105).}
Claim 10
Regarding claim 10, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
Regarding claim 10 Stephens further discloses:
wherein a representative image indicating the first token is determined as one of a plurality of sub digital assets comprised by the digital asset, based on whether at least one of the usage log recorded in the first metadata of the first token or the generation information satisfies a predetermined condition, and {The digital asset may be composed of images, and visual aspects can change based on gameplay activity or historical usage. These visual characteristics are derived from on-chain metadata and may be selected based on satisfying certain gameplay or usage conditions (paragraphs 0074, 0076).}
wherein the predetermined condition is related to at least one of:
information on the owner or the person having the right of use of the digital asset comprised by at least one of the usage log or the generation information; {Metadata associated with a digital asset (e.g., usage log or generation information) may include information about the asset’s ownership and history of use by different players. These points can drive conditions that affects the token’s appearance, depending on who used the asset or how many users interacted with it (paragraphs 0071, 0074, 0076)
information on content related to the use of the digital asset; or
information on an aspect of using the digital asset.
Claim 11
Regarding claim 11, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
perform the procedure of generating the second token based on an interaction with the at least one node of the blockchain network. {The minting (i.e. token generation) process is governed by a token smart contract, and the resulting token creation is recorded as a transaction on the distributed ledger, which requires communication with blockchain nodes (paragraphs 0064, 0071, 0105).}
Claim 12
Regarding claim 12, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
wherein the second metadata of the second token further indicates whether the digital asset is allowed to be subleased. {Token smart contracts can define and enforce licensing or rental terms, including permissible usage rights (i.e., restrictions or permissions on subleasing). These rights are programmable managed by smart contract logic and are embedded in the token metadata (paragraphs 0061, 0071, 0076).}
Claim 13
Regarding claim 13, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
wherein the generation information comprises at least one of information on a rental period of the digital asset, information on the person having the right of use, information on content scheduled to use the digital asset, information on an expected usage aspect of the digital asset, or information on a time point at which the digital asset is scheduled to be used. {When a rental or license token (i.e., second token) is generated, it includes information regarding the rental such as duration of the rental period. This information is reflected in the metadata of the token (paragraphs 0061, 0071, 0102).}
Claim 14
Regarding claim 14, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
wherein the rental request is accompanied with an operation of transmitting, to a wallet address of the electronic device, a virtual asset corresponding to a price for rental of the digital asset, based on receiving the rental request. {When a rental request is received, a payment transaction is transmitted to the owner’s device. This payment corresponds to the rental price of the digital asset and is handled as part of the transaction governed by a smart contract (paragraphs 0061, 0071, 0100).}
Claim 16
Regarding claim 16, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
receive, from the user terminal of the user, a transfer request requesting to transfer the second token {The system receives a transfer request from a user terminal to transfer a token (e.g., second token), and that this transfer is recorded on the distributed ledger. The transfer request originates from the user and is processed by the digital asset management engine or platform servers (paragraphs 0039, 0100).}
transmit, to the at least one node of the blockchain network, a change message requesting to change information indicating the person having the right of use of the second token, based on the transfer request. {Upon receiving a request, the system transmits a new transaction or block (i.e., a message) to the blockchain network to update the state of the token, including a change in the party holding usage rights (paragraphs 0064, 0100, 0105).}
Claim 17
Regarding claim 17, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
wherein the second metadata of the second token further indicates a rental period of the digital asset {Tokens issued under rental or license conditions include metadata that governs the duration of use (i.e., rental period). The token smart contracts specify temporary access terms and may revert access or ownership upon expiration of the rental term. This information is maintained in the token metadata (paragraphs 0071, 0102).}
wherein the one or more processors are further configured to change information indicating the person having the right of use of the second token based on whether the rental period has lapsed. {When the rental period expires, the system automatically reverts access rights (i.e., it changes the person with right of use). This is managed through smart contract logic executed on the blockchain, and the change of rights (i.e., rental license expiration) is reflected in token metadata (paragraphs 0071, 0102).}
Claim 18
Regarding claim 18, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
wherein the first smart contract comprises information for generating the second token comprising rental information of the digital asset as metadata, and {Smart contracts (e.g., the first smart contract) include logic and terms for generating tokens that represent rental or licensed use of a digital asset. These tokens (e.g., second tokens) include metadata such as rental rights and associated user information. The smart contract governs conditions for use, rental, and license of the token and, by extension, the associated digital asset (paragraphs 0061, 0071).}
wherein the rental information of the digital asset indicates the person having the right of use of the digital asset. {Rental or license metadata associated with a token identifies the user (i.e., person) who has the right to use the digital asset. This rental information is managed by token smart contracts and can be recorded in the token metadata and/or the distributed ledger to reflect temporary user permissions distinct from ownership (paragraphs 0071, 0076, 0102).}
Claims 8-9, and 15 are rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Stephens and Tran, in further view of Andon (US 20200184041).
Claim 8
Regarding claim 8, while the combination of Stephens and Tran teaches the limitations set forth above, it does not explicitly teach:
wherein a representative image of the first token is determined as one of a plurality of sub digital assets comprised by the digital asset, based on at least one of a first number of the usage log recorded in the first metadata of the first token or a second number of the generation information.
However, Andon, in a similar field of endeavor directed to the creation and distribution of cryptographically secured digital footwear and apparel, teaches:
wherein a representative image of the first token is determined as one of a plurality of sub digital assets comprised by the digital asset, based on at least one of a first number of the usage log recorded in the first metadata of the first token or a second number of the generation information. {A digital asset may evolve through various life stages, and its visual representation may change based on usage activity or generation events. One sub digital asset (i.e., an image at a certain life stage) may be selected as the current representative image based on such activity. Additionally, visual representations are determined from expressed traits derived from encoded usage and generation history (paragraphs 0045, 0047, 0049, 0067).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Stephen and Tran, to include the token visual evolution and metadata management based on traits features of Andon, to know, track, or authenticate a history of a particular instance of a digital asset. (see paragraph 0004 of Andon).
Claim 9
Regarding claim 9, the combination of Stephens, tran, and Andon teaches the limitations set forth above. Andon further teaches:
wherein the representative image of the first token is determined as one of the plurality of sub digital assets comprised by the digital asset, based on at least one of a first weighted sum of the first number and a usage period corresponding to the first number or a second weighted sum of the first number and a rental period corresponding to the first number. {The representative image is determined from a combination of usage data (e.g., count of uses or activity logs) and temporal measures (e.g., usage period or rental period) (paragraphs 0049, 0067, 0091, 0098).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Stephen, Tran, and Andon to include the token visual evolution and metadata management based on traits features of Andon, to know, track, or authenticate a history of a particular instance of a digital asset. (see paragraph 0004 of Andon).
Claim 15
Regarding claim 15, the combination of Stephens and Tran teaches the limitations set forth above. Stephens further discloses:
wherein the virtual asset are recorded in the first metadata of the first token, based on generation of the second token, and {The generation of a rental token (i.e., second token) and the associated transaction can result in an update to the metadata of the original token (i.e., first token) (paragraphs 0061, 0071, 0076).}
While the combination of Stephens and Tran teaches the limitations set forth above, it does not explicitly teach:
wherein the one or more processors are further configured to:
receive, from a user terminal of the owner of the digital asset, a withdrawing request requesting to withdraw the virtual asset from the first token; and
transmit, to the at least one node of the blockchain network, a transmit message requesting to transmit at least a portion of the virtual asset to a wallet address of the owner, based on the withdrawing request.
However, Andon, in a similar field of endeavor directed to the creation and distribution of cryptographically secured digital footwear and apparel, teaches:
wherein the one or more processors are further configured to:
receive, from a user terminal of the owner of the digital asset, a withdrawing request requesting to withdraw the virtual asset from the first token {A user device can send a request to the system that results in the withdrawal (i.e., deactivation, return, or removal) of the digital asset from the token or wallet (paragraphs 0073, 0076, 0093).}
transmit, to the at least one node of the blockchain network, a transmit message requesting to transmit at least a portion of the virtual asset to a wallet address of the owner, based on the withdrawing request. {Upon receiving a request, the system may trigger a smart contract or platform logic that causes the digital asset to be transmitted to or from a wallet address associated with the owner (paragraphs 0078, 0092-0093).}
Therefore, it would have been obvious to one of the ordinary skills in the art to modify the combination of Stephen and Tran to include the token visual evolution and metadata management based on traits features of Andon, to know, track, or authenticate a history of a particular instance of a digital asset. (see paragraph 0004 of Andon).
Response to Arguments
Applicant’s arguments filed on 11/17/2025 have been carefully considered.
Rejections under 35 U.S.C. §101
Under Step 2A, Prong One, the claims recite an abstract idea. When viewed under their BRI, independent claims 1 and 19 are directed to managing owner rights, rental transactions, and compensation. As such, the subject matter falls within certain methods of organizing human activity, specifically commercial or legal interactions. The use of tokens, metadata, and smart contracts does not change the economic nature of the activity.
Under Step 2A, Prong Two, the claims do not integrate the abstract idea into a practical application. The additional elements are described functionally and at a high level. The claims do not recite a specific improvement to blockchain technology or computer functionality. Instead, they use known technology as a tool to carry out a rental and tracking process.
Applicant’s assertion that that the claims increase token value or improve digital asset renting reflects, at best, a business improvement, not a technical one. There is no technical solution to a technological problem.
Under Step 2B, the claims do not include significantly more. The additional elements, individually and as a combination, amount to applying the abstract idea using generic computing and blockchain components performing their expected functions.
Accordingly, the rejection under 35 U.S.C. §101 is maintained.
Rejections under 35 U.S.C. §§102/103
Applicant’s arguments with respect to patentability under 35 U.S.C. §§ 102/103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Regarding any arguments concerning the dependent claims, examiner notes that they are predicated on the independent claims, which have been amended. For the same reason as above, these arguments are moot. Examiner directs applicant’s attention to the claim analysis above.
In summary, examiner has responded to all arguments and found them unpersuasive.
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