Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. The Preliminary Amendment filed December 7, 2024 has been entered. Claim 14 is cancelled according to the Preliminary Amendment. Claims 15-21 are newly added according to the Preliminary Amendment. Claims 1-13 and 15-21 are pending and are rejected for the reasons set forth below.
Claim Rejections - 35 USC §112
3. 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.
4. Claims 8 and 20 are rejected under 35 U.S.C. §112(b) or 35 U.S.C. §112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 8 recites the limitation, “inserting the HTML document component into a document object model (DOM) representing the webpage.” There is insufficient antecedent basis for this limitation in the claim. Specifically, claim 8, and claim 1 from which claim 8 depends, does not properly introduce the term “the HTML document component” before it is referred to in this limitation. Rather, this term is introduced in dependent claim 7. For the purpose of examination, claim 8 has been interpreted as if it depends from claim 7. Similarly, claim 20 has been interpreted as if it depends from claim 19.
Since claim 20 the substantially same issue as claim 8, claim 20 is rejected for the grounds and rationale used to reject claim 8. Appropriate correction or clarification of these claims is required. No new matter may be added.
Claim Rejections - 35 USC § 101
5. 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.
6. Claims 1-13 and 15-21 are rejected under 35 U.S.C. §101 because the claimed invention recites and is directed to a judicial exception to patentability (i.e., a law of nature, a natural phenomenon, or an abstract idea) and does not include an inventive concept that is “significantly more” than the judicial exception under the January 2019 and October 2019 patentable subject matter eligibility guidance (2019 PEG) analysis which follows.
Step 1
7. Under the 2019 PEG step 1 analysis, it must first be determined whether the claims are directed to one of the four statutory categories of invention (i.e., process, machine, manufacture, or composition of matter). Applying step 1 of the analysis for patentable subject matter to the claims, it is determined that the claims are directed to the statutory category of a process (claims 1-11 and 13) and a manufacture (claims 12 and 15-21). Therefore, we proceed to step 2A, Prong 1.
Step 2A, Prong 1
8. Under the 2019 PEG step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more designated categories of patent ineligible subject matter (i.e., organizing human activity, mathematical concepts, and mental processes) that amount to a judicial exception to patentability.
Claim 1 recites the abstract idea of:
accessing webpage component rendering instructions including instructions for generating [[a commercial interface]] associated with a decentralized creator, an asset of the decentralized creator offered using [[the commercial interface]]; and
in response to determining a user has requested to use [[the commercial interface]], querying [[a smart contract]] for metadata associated with the asset, wherein [[the smart contract]] is queried in accordance with the instructions for generating [[the commercial interface]].
Here, the recited abstract idea falls within one or more of the three enumerated 2019 PEG categories of patent ineligible subject matter, to wit: certain methods of organizing human activity, which includes commercial interactions (e.g., generating a commercial interface). While the claims do not explicitly recite the performance of a transaction, the claims recite limitations corresponding to the generation an interface that is used in a commercial interaction. It is clear in view of the specification that the interface is used to facilitate transactions between individuals (See Paragraph 3 of the specification).
Step 2A, Prong 2
9. Under the 2019 PEG step 2A, Prong 2 analysis, the identified abstract idea to which claim 1 is directed does not include limitations or additional elements that integrate the abstract idea into a practical application.
Besides reciting the abstract idea, the limitations of claim 1 also recite generic computer components (e.g., a commercial interface, a smart contract, a web element, and a device of the user). In particular, the recited features of the abstract idea are merely being applied on a computer or computing device or via software programming that is simply being used as a tool (“apply it”) to implement the abstract idea. (See e.g., MPEP §2106.05(f)). Therefore, these additional elements are recited at a high level of generality such that they amount to no more than mere instructions to apply the exception using generic computer components. In other words, the additional elements are simply used as tools to perform the abstract idea.
Claim 1 also recites the following limitations:
generating a web element using the metadata; and
rendering for display at a device of the user the commercial interface using the generated web element.
These limitations merely state that the method includes steps for generating and displaying a commercial interface on a device of the user. However, the claim does not provide significant technical detail regarding how the interface is displayed. Therefore, these limitations amount to no more than merely outputting/displaying data, which is a form of insignificant extra-solution activity (See MPEP 2016.05(g): OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)).
Thus, claim 1 does not include any limitations or additional elements that integrate the abstract idea into a practical application. As a result, claim 1 is directed to an abstract idea.
Step 2B
10. Under the 2019 PEG step 2B analysis, the additional elements of claim 1 are evaluated to determine whether they amount to something “significantly more” than the recited abstract idea. (i.e., an innovative concept). Here, the recited additional elements (e.g., a commercial interface, a smart contract, a web element, and a device of the user), do not amount to an innovative concept since, as stated above in the Step 2A, Prong 2 analysis, the claims are simply using the additional elements as a tool to carry out the abstract idea (i.e., “apply it”) on a computer or computing device and/or via software programming (See e.g., MPEP §2106.05(f)). The additional elements are specified at a high level of generality such that they are being used in the claims to simply implement the abstract idea and are not themselves being technologically improved (See e.g., MPEP 2106.05(I)(A)); (See also applicant’s Specification at least Paragraphs 42-45).
Additionally, the following limitation identified above as insignificant extra-solution activity (merely outputting/displaying data) has been revaluated in Step 2B:
generating a web element using the metadata; and
rendering for display at a device of the user the commercial interface using the generated web element.
As stated in MPEP 2106.05(d), a factual determination is required to support a conclusion that an additional element (or combination of additional elements) is well-understood, routine, conventional activity (Berkheimer v. HP, Inc., 881 F.3d 1360, 1368 (Fed. Cir. 2018)). In view of this requirement set forth by Berkheimer, this limitation does not integrate the abstract idea into a practical application, or amount to significantly more than the abstract idea, because the courts have found the concept of merely outputting/displaying data to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)).
Thus, claim 1 does not recite any additional elements that amount to “significantly more” than the abstract idea.
Additional Independent Claims
11. Independent claims 12 and 13 are similarly rejected under 35 U.S.C. 101 for the reasons described below:
Claim 12 recites limitations that are substantially similar to those recited in claim 1. However, the primary difference between claims 12 and 1 is that claim 12 is drafted as a non-transitory computer-readable medium rather than as a method. Similarly, as described above regarding claim 1, claim 12 recites generic computer components (e.g., a non-transitory computer readable medium, a processor, a commercial interface, a smart contract, a web element, and a device of the user) that are simply being used as a tool (“apply it”) to implement the abstract idea. Therefore, since the same analysis should be used for claims 1 and 12, claim 12 is not patent eligible (See Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 134 S. Ct. 2347, 2354 (2014)).
Claim 13 recites limitations that are substantially similar to those recited in claim 1. However, claim 13 recites slightly different processes for generating the user interface. However, these limitations (e.g., receiving a request for metadata form the user, and applying a rule to the request based on an identifier of the asset) similarly, fall under the category of commercial interactions, as described above regarding claim 1. Similarly, as described above regarding claim 1, claim 13 recites generic computer components (e.g., a client device, a smart contract, a web application at the client device, and a user interface) that are simply being used as a tool (“apply it”) to implement the abstract idea. Additionally, claim 13 recites the limitation, “providing the metadata associated with the asset to the client device, the metadata used by a web application at the client device to generate a user interface for offering the asset.” As described above regarding the limitations of claim 1, this limitation simply states that the system generates/displays a user interface. However, the claims do not provide significant technical detail regarding how the interface is displayed. Such limitations also amount to no more than merely outputting/displaying data as described above regarding claim 1. Therefore, since a similar analysis should be used for claims 1 and 13, claim 13 is not patent eligible (See Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 134 S. Ct. 2347, 2354 (2014)).
Dependent Claims
12. Dependent claims 2-11 and 15-21 are also rejected under 35 U.S.C. 101 for the reasons described below:
Claims 2 and 15 simply state that the method includes steps for displaying an option to use a fiat currency when it is determined that the webpage does not enable cryptocurrency transactions. However, the claims do not provide significant technical detail regarding how this option is displayed. Therefore, such limitations amount to no more than merely outputting/displaying data which is a form of insignificant extra-solution activity. In view of the requirement set forth by Berkheimer, this limitation does not integrate the abstract idea into a practical application, or amount to significantly more than the abstract idea, because the courts have found the concept of merely outputting/displaying data to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)).
Claims 3 and 16 simply further refine the abstract idea because they recite process steps (e.g., determining whether a cryptocurrency wallet is stored in a web browser, and determining that the ability to request cryptocurrency transactions based on the presence of the wallet) that fall under the category of organizing human activity, as described above regarding claim 1.
Claim 4 simply states that the method includes steps for displaying an input element for the user to opt-in or opt-out of cryptocurrency transactions. However, the claims do not provide significant technical detail regarding how this input element is displayed, or how the user interacts with the input element. Therefore, such limitations amount to no more than merely outputting/displaying data which is a form of insignificant extra-solution activity. In view of the requirement set forth by Berkheimer, this limitation does not integrate the abstract idea into a practical application, or amount to significantly more than the abstract idea, because the courts have found the concept of merely outputting/displaying data to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)).
Claims 5 and 17 simply state that the metadata is compressed and decompressed. However, the claims do not provide any technical detail regarding how the compression and decompression processes are performed. Therefore, such limitations amount to no more than merely applying generic computer-based technology and algorithms (e.g., compression and decompression technology) to implement the abstract idea on a computer.
Claims 6 and 18 simply state that the metadata is encrypted and decrypted. However, the claims do not provide any technical detail regarding how the encryption and decryption processes are performed. Therefore, such limitations amount to no more than merely applying generic computer-based technology and algorithms (e.g., encryption and decryption technology) to implement the abstract idea on a computer.
Claims 7, 8, 19, and 20 simply state that web element is an HTML document component, and that the HTML document component is insert into a document object model representing the webpage. However, simply stating that the web element and webpage are generated using generic webpage structuring technology does not amount to an improvement to any technology or technological field. Rather, this amounts to no more than merely applying generic webpage structuring technology to implement the abstract idea on a computer.
Claims 9 and 21 simply provide further definition to the “smart contract” recited in claim 1. Simply stating that the smart contract includes an identifier of the author of the metadata and the metadata does not provide an indication of an improvement to any technology or technological field. Rather, this merely defines the type of information included in the smart contract.
Claim 10 simply states that the smart contract performs identity verification using a signature generated by a private hey of the user. However, the claims do not provide any technical detail regarding the signature or the private key, and/or how they are implemented to perform the identity verification. Therefore, such limitations amount to no more than merely applying generic smart contract technology to implement the abstract idea on a computer.
Claim 11 simply provides further definition to the “smart contract” recited in claim 1. Simply stating that the smart contract is modifiable does not provide an indication of an improvement to any technology or technological field. The claims do not provide any technical detail regarding how the smart contract idea updated. Therefore, such limitations amount to no more that merely applying generic smart contract technology to implement the abstract idea on a computer.
Thus, the dependent claims do not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application) that results in the claims being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Claim Rejections - 35 USC § 102
13. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
14. Claims 1, 9, 10, 12, and 21 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Mancuso (U.S. Pre-Grant Publication No. 20230394466).
Claim 1
Regarding Claim 1, Mancuso teaches:
A method for generating a user interface, the method comprising (See at least Paragraphs 91-95: Describes a system/method for generating/displaying an interface for a tokenized asset marketplace via a client device):
accessing webpage component rendering instructions including instructions for generating a commercial interface associated with a decentralized creator, an asset of the decentralized creator offered using the commercial interface (See at least Paragraph 57: The client device comprises a client application. Based on instructions from the client application, the client device can present or display information in the form of user interfaces. For example, the client device may display a user interface comprising a plurality of tokenized assets associated with a creator [i.e., a commercial interface; See Paragraph 92 and Figure 6]. The tokenized assets are stored and transacted on a blockchain [i.e., the creator is a "decentralized creator" because they store/sell the tokenized assets using a blockchain or decentralized database; See Paragraph 47]);
in response to determining a user has requested to use the commercial interface, querying a smart contract for metadata associated with the asset, wherein the smart contract is queried in accordance with the instructions for generating the commercial interface (See at least Paragraph 67: The tokenized asset system stores tokenized asset data [i.e., metadata] reflecting the digital content items within a decentralized storage location such that smart contracts within the blockchain can reference the data to display, or otherwise provide, corresponding content. In other words, the smart contract may be accessed in order to retrieve and display the tokenized asset data [e.g., as described in Paragraph 92 and Figure 6]. The tokenized asset data may be retrieved and displayed in response to receiving a user interaction selecting a tokenized asset [i.e., the user requests to use the interface]);
generating a web element using the metadata; and rendering for display at a device of the user the commercial interface using the generated web element (See at least Paragraph 92: Based on receiving a user interaction selecting a tokenized asset from the set of tokenized assets, the tokenized asset system provides a purchase pane [i.e., a web element] that includes tokenized asset data [i.e., metadata]).
Claim 9
Regarding Claim 9, Mancuso teaches:
wherein the smart contract stores an identifier of the author of the metadata and the metadata (See at least Paragraph 92: The tokenized asset data may include creator information [i.e., an identifier of the author of the metadata] and a description of the asset [i.e., the metadata]).
Claim 10
Regarding Claim 9, Mancuso teaches:
providing a signature generated by a private key of the user to the smart contract, wherein the smart contract performs identity verification using the signature (See at least Paragraph 124: The tokenized asset may be associated with a "blockchain key." The blockchain key may be used to associate the tokenized asset with a user account, and verify ownership of the tokenized asset via a smart contract. The blockchain key refers to a private cryptographic key for a blockchain, and the key may be used to sign transactions for minting, transferring, purchasing, and trading the tokenized asset [See Paragraph 49]).
Claim 12
Regarding Claim 12, Mancuso teaches:
A non-transitory computer-readable medium storing instructions for generating a user interface, the instructions when executed by at least one processor cause the at least one processor to (See at least Paragraphs 91-95: Describes a system/method for generating/displaying an interface for a tokenized asset marketplace via a client device. tokenized asset system can include one or more instructions stored on a computer-readable storage medium and executable by processors of one or more computing devices [See Paragraph 156]):
access webpage component rendering instructions including instructions for generating a commercial interface associated with a decentralized creator, an asset of the decentralized creator offered using the commercial interface (See at least Paragraph 57: The client device comprises a client application. Based on instructions from the client application, the client device can present or display information in the form of user interfaces. For example, the client device may display a user interface comprising a plurality of tokenized assets associated with a creator [i.e., a commercial interface; See Paragraph 92 and Figure 6]. The tokenized assets are stored and transacted on a blockchain [i.e., the creator is a "decentralized creator" because they store/sell the tokenized assets using a blockchain or decentralized database; See Paragraph 47]);
in response to determining a user has requested to use the commercial interface, query a smart contract for metadata associated with the asset, wherein the smart contract is queried in accordance with the instructions for generating the commercial interface (See at least Paragraph 67: The tokenized asset system stores tokenized asset data [i.e., metadata] reflecting the digital content items within a decentralized storage location such that smart contracts within the blockchain can reference the data to display, or otherwise provide, corresponding content. In other words, the smart contract may be accessed in order to retrieve and display the tokenized asset data [e.g., as described in Paragraph 92 and Figure 6]. The tokenized asset data may be retrieved and displayed in response to receiving a user interaction selecting a tokenized asset [i.e., the user requests to use the interface]);
generate a web element using the metadata; and render for display at a device of the user the commercial interface using the generated web element (See at least Paragraph 92: Based on receiving a user interaction selecting a tokenized asset from the set of tokenized assets, the tokenized asset system provides a purchase pane [i.e., a web element] that includes tokenized asset data [i.e., metadata]).
Claim 21
Regarding Claim 21, Mancuso teaches:
wherein the smart contract stores an identifier of the author of the metadata and the metadata (See at least Paragraph 92: The tokenized asset data may include creator information [i.e., an identifier of the author of the metadata] and a description of the asset [i.e., the metadata]).
Claim Rejections - 35 USC § 103
15. 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.
16. Claims 2 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Mancuso (U.S. Pre-Grant Publication No. 20230394466) in view of Mathew (U.S. Pre-Grant Publication No. 20210142297).
Claim 2
Regarding Claim 2, Mancuso does not explicitly teach, but Mathew, however, does teach:
determining whether the webpage instructions enable the user to request a cryptocurrency transaction (See at least Paragraph 32: Describes a system for facilitating transactions with a merchant via a graphical user interface. The system may determine whether the merchant computer system accepts fiat or crypto currency); and
in response to determining that the webpage does not enable the user to request the cryptocurrency transaction, rendering the commercial interface with an option to use a fiat currency (See at least Paragraphs 32 and 33: If the merchant accepts fiat [i.e., the merchant does not accept cryptocurrency, the system may receive a selection from the user to pay with a fiat currency. Examiner's Note: While Mathew does not explicitly state that an option to pay with a fiat currency is "rendered" on the interface, it would have been obvious to one of ordinary skill in the art that in order to receive such a selection from the user, some form of interface element would be displayed to the user).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso and Mathew in order to provide an improved system that provides users the choice to pay with either fiat or crypto currency based on the capabilities of the merchant (Mathew: Paragraph 32).
Claim 15
Regarding Claim 15, Mancuso does not explicitly teach, but Mathew, however, does teach:
wherein the instructions when executed by the at least one processor further cause the at least one processor to: determine whether the webpage instructions enable the user to request a cryptocurrency transaction (See at least Paragraph 32: Describes a system for facilitating transactions with a merchant via a graphical user interface. The system may determine whether the merchant computer system accepts fiat or crypto currency); and
in response to determining that the webpage does not enable the user to request the cryptocurrency transaction, render the commercial interface with an option to use a fiat currency (See at least Paragraphs 32 and 33: If the merchant accepts fiat [i.e., the merchant does not accept cryptocurrency, the system may receive a selection from the user to pay with a fiat currency. Examiner's Note: While Mathew does not explicitly state that an option to pay with a fiat currency is "rendered" on the interface, it would have been obvious to one of ordinary skill in the art that in order to receive such a selection from the user, some form of interface element would be displayed to the user).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso and Mathew in order to provide an improved system that provides users the choice to pay with either fiat or crypto currency based on the capabilities of the merchant (Mathew: Paragraph 32).
17. Claims 3 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Mancuso (U.S. Pre-Grant Publication No. 20230394466) in view of Mathew (U.S. Pre-Grant Publication No. 20210142297), and in further view of Isaacson (U.S. Patent No. 10497037).
Claim 3
Regarding Claim 3, the combination of Mancuso and Mathew does not explicitly teach, but Isaacson, however, does teach:
wherein determining whether the webpage instructions enable the user to request the cryptocurrency transaction comprises: determining whether a cryptocurrency wallet is stored in a web browser associated with the user (See at least Col. 44, Line 37 – Col. 45, Line 17: Describes a system for initiating cryptocurrency payments via a wallet associated with the user. A browser associated with a merchant may receive information corresponding to a wallet of the buyer. The wallet may be web-based [i.e., the browser determines whether a wallet is stored in association with the user]),
wherein the presence of the cryptocurrency wallet corresponds to an ability to request the cryptocurrency transaction (See at least Col. 44, Line 37 – Col. 45, Line 17: The wallet may be used to transmit payment to the merchant [i.e., the merchant is able to receive payment from the user wallet]).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso, Mathew, and Isaacson in order to provide an improved system that removes the need for users to enter payment data when interacting with a merchant. This process is often cumbersome, tedious, slow and requires too many interactions by the user to be convenient (Isaacson: Col. 2, Line 65 – Col. 3, Line 27). Utilizing digital wallets provides allows this process to automated.
Claim 16
Regarding Claim 16, the combination of Mancuso and Mathew does not explicitly teach, but Isaacson, however, does teach:
wherein the instructions to determine whether the webpage instructions enable the user to request the cryptocurrency transaction comprises instructions that when executed by the at least one processor further cause the at least one processor to: determine whether a cryptocurrency wallet is stored in a web browser associated with the user (See at least Col. 44, Line 37 – Col. 45, Line 17: Describes a system for initiating cryptocurrency payments via a wallet associated with the user. A browser associated with a merchant may receive information corresponding to a wallet of the buyer. The wallet may be web-based [i.e., the browser determines whether a wallet is stored in association with the user]),
wherein the presence of the cryptocurrency wallet corresponds to an ability to request the cryptocurrency transaction (See at least Col. 44, Line 37 – Col. 45, Line 17: The wallet may be used to transmit payment to the merchant [i.e., the merchant is able to receive payment from the user wallet]).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso, Mathew, and Isaacson in order to provide an improved system that removes the need for users to enter payment data when interacting with a merchant. This process is often cumbersome, tedious, slow and requires too many interactions by the user to be convenient (Isaacson: Col. 2, Line 65 – Col. 3, Line 27). Utilizing digital wallets provides allows this process to automated.
18. Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Mancuso (U.S. Pre-Grant Publication No. 20230394466) in view of Mathew (U.S. Pre-Grant Publication No. 20210142297), and in further view of Battle (U.S. Pre-Grant Publication No. 20180232739).
Claim 4
Regarding Claim 4, the combination of Mancuso and Mathew does not explicitly teach, but Battle, however, does teach:
rendering for display at the device of the user, a graphical user interface (GUI) input element configured to enable the user to opt in or opt out of performing transactions using a cryptocurrency (See at least Paragraph 64: Describes a system for executing transactions comprising an exchange of cryptocurrency. The user may provide permission [i.e., opt-in] to execute transactions using cryptocurrencies by registering with the system. The user may provide this information via a user input in the user interface).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso, Mathew, and Battle in order to incentivize improved account access security (Battle: Paragraph 12). Requiring the user to provide permission/opt-in to engage in cryptocurrency transactions reduces the likelihood that the account will be used for fraudulent purposes.
19. Claims 5 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Mancuso (U.S. Pre-Grant Publication No. 20230394466) in view of Kraus (U.S. Pre-Grant Publication No. 20080162523).
Claim 5
Regarding Claim 5, Mancuso does not explicitly teach, but Kraus, however, does teach:
wherein the metadata is compressed, and further comprising applying a decompression algorithm to the metadata (See at least Paragraphs 34 and 35: Describes a system for selectively compressing information within a database. The system may compress a portion of the data and its associated metadata. The compressed data may be decompressed).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso and Kraus in order to provide a system that allows enterprises to decrease the size of their databases without impacting performance or usability (Kraus: Paragraphs 2-5).
Claim 17
Regarding Claim 17, Mancuso does not explicitly teach, but Kraus, however, does teach:
wherein the metadata is compressed, and wherein the instructions when executed by the at least one processor further cause the at least one processor to apply a decompression algorithm to the metadata (See at least Paragraphs 34 and 35: Describes a system for selectively compressing information within a database. The system may compress a portion of the data and its associated metadata. The compressed data may be decompressed).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso and Kraus in order to provide a system that allows enterprises to decrease the size of their databases without impacting performance or usability (Kraus: Paragraphs 2-5).
20. Claims 6 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mancuso (U.S. Pre-Grant Publication No. 20230394466) in view of Jacobs (U.S. Pre-Grant Publication No. 20170237554).
Claim 6
Regarding Claim 6, Mancuso does not explicitly teach, but Jacobs, however, does teach:
wherein the metadata is encrypted, and further comprising applying a decryption algorithm to the metadata (See at least Paragraph 98: Describes a method and system for transferring digital assets in a digital asset network. Metadata associated with the digital asset may be encrypted. The encrypted metadata may be decrypted by appropriate parties).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso and Jacobs in order to ensure that only the user and/or resource provider may be able view decrypt and view identification (or other) information in digital assets included in a ledger to which they were party (Jacobs: Paragraph 98). This improves the security of transactions involving digital assets.
Claim 18
Regarding Claim 18, Mancuso does not explicitly teach, but Jacobs, however, does teach:
wherein the metadata is encrypted, and wherein the instructions when executed by the at least one processor further cause the at least one processor to apply a decryption algorithm to the metadata (See at least Paragraph 98: Describes a method and system for transferring digital assets in a digital asset network. Metadata associated with the digital asset may be encrypted. The encrypted metadata may be decrypted by appropriate parties).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso and Jacobs in order to ensure that only the user and/or resource provider may be able view decrypt and view identification (or other) information in digital assets included in a ledger to which they were party (Jacobs: Paragraph 98). This improves the security of transactions involving digital assets.
21. Claims 7, 8, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mancuso (U.S. Pre-Grant Publication No. 20230394466) in view of Bura (U.S. Patent No. 10579227).
Claim 7
Regarding Claim 7, Mancuso does not explicitly teach, but Bura, however, does teach:
wherein the web element is an HTML document component (See at least Col. 3, Lines 14-50: Describes a system for displaying pages that describe products and services that are available from a company. An element of the display may be an individual component of an HTML document).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso and Bura in order to provide an appropriate method for displaying the webpage to the user, wherein the webpage includes a large amount of potentially diverse content, such as descriptive information, images, pricing, recommendations, ratings, or reviews (Bura: Col. 1, Line 17-33).
Claim 8
Regarding Claim 8, Mancuso does not explicitly teach, but Bura, however, does teach:
inserting the HTML document component into a document object model (DOM) representing the webpage (See at least Col. 3, Lines 14-50: Describes a system for displaying pages that describe products and services that are available from a company. An element of the display may be an individual component of an HTML document that has been parsed into a document object model [DOM] within the web browser).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso and Bura in order to provide an appropriate method for displaying the webpage to the user, wherein the webpage includes a large amount of potentially diverse content, such as descriptive information, images, pricing, recommendations, ratings, or reviews (Bura: Col. 1, Line 17-33).
Claim 19
Regarding Claim 19, Mancuso does not explicitly teach, but Bura, however, does teach:
wherein the web element is an HTML document component (See at least Col. 3, Lines 14-50: Describes a system for displaying pages that describe products and services that are available from a company. An element of the display may be an individual component of an HTML document).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso and Bura in order to provide an appropriate method for displaying the webpage to the user, wherein the webpage includes a large amount of potentially diverse content, such as descriptive information, images, pricing, recommendations, ratings, or reviews (Bura: Col. 1, Line 17-33).
Claim 20
Regarding Claim 20, Mancuso does not explicitly teach, but Bura, however, does teach:
wherein the instructions when executed by the at least one processor further cause the at least one processor to insert the HTML document component into a document object model (DOM) representing the webpage (See at least Col. 3, Lines 14-50: Describes a system for displaying pages that describe products and services that are available from a company. An element of the display may be an individual component of an HTML document that has been parsed into a document object model [DOM] within the web browser).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso and Bura in order to provide an appropriate method for displaying the webpage to the user, wherein the webpage includes a large amount of potentially diverse content, such as descriptive information, images, pricing, recommendations, ratings, or reviews (Bura: Col. 1, Line 17-33).
22. Claims 11 and 13 is rejected under 35 U.S.C. 103 as being unpatentable over Mancuso (U.S. Pre-Grant Publication No. 20230394466) in view of Ferenczi (U.S. Pre-Grant Publication No. 20230198760).
Claim 11
Regarding Claim 11, Mancuso does not explicitly teach, but Ferenczi, however, does teach:
wherein the smart contract is modifiable to update the metadata of the asset (See at least Paragraph 19: Describes a system for the presentation of media represented by non-fungible tokens. The NFT smart contract may be executed or invoked to update the metadata of the NFT [i.e., the asset]).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso and Ferenczi in order to provide an improved system for validating the ownership of a digital asset, such as an NFT (Ferenczi: Paragraphs 37 and 38). Allowing the smart contract to be modified provides the ability to transfer ownership of the digital asset or update information corresponding to the owner (Ferenczi: Paragraph 19).
Claim 13
Regarding Claim 13, Mancuso teaches:
A method for generating a user interface, the method comprising (See at least Paragraphs 91-95: Describes a system/method for generating/displaying an interface for a tokenized asset marketplace via a client device):
receiving, from a client device, a request for metadata associated with an asset of a decentralized creator (See at least Paragraph 92: The user may interact with the user interface to select a tokenized asset. Based on receiving the user interaction selecting a tokenized asset from the set of tokenized assets, the tokenized asset system provides a purchase pane that includes tokenized asset data [i.e., metadata]. In other words, the interaction with the tokenized asset corresponds to a request for the tokenized asset data);
applying a rule of a smart contract to the request (See at least Paragraphs 147-149: The tokenized asset system may allow the user to define "tokenized gating rules" for a tokenized asset. These rules may apply to, for example, conditions under which a tokenized asset may be accessed by a user [See Paragraph 151]. The gating rules may be reflected and enforced by the smart contract [See Paragraph 131]),
the smart contract storing the metadata associated with the asset (See at least Paragraph 67: The tokenized asset system generates tokenized data such as one or more smart contracts to include within or store on a blockchain and that represent or reference the one or more content items selected to include within the tokenized asset [i.e., the smart contract stores the data associated with the tokenized asset]), and
providing the metadata associated with the asset to the client device, the metadata used by a web application at the client device to generate a user interface for offering the asset (See at least Paragraph 92: Based on receiving a user interaction selecting a tokenized asset from the set of tokenized assets, the tokenized asset system provides a purchase pane [i.e., a web element] that includes tokenized asset data [i.e., metadata]).
Regarding Claim 13, Mancuso does not explicitly teach, but Ferenczi, however, does teach:
the rule mapping the stored metadata to an identifier of the asset (See at least Paragraph 37: Describes a system for the presentation of media represented by non-fungible tokens. The system may invoke a function exposed by an NFT smart contract that returns metadata of the NFT in response to the NFT identifier being provided as an argument or input to the function. Examiner's Note: The applicant's specification does not appear to define the term "mapping" in this context. However, this limitation has been interpreted according to Paragraph 45 of the applicant's specification which states, "For example, smart contract 111 includes a rule to return asset metadata in response to receiving an asset identifier." In other words, this limitation has been interpreted as stating that the metadata is received in response to receiving an asset identifier).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of Mancuso and Ferenczi in order to provide an improved system for validating the ownership of a digital asset, such as an NFT (Ferenczi: Paragraphs 37 and 38). Allowing the metadata of the NFT to be accessed provides the ability to transfer ownership of the digital asset or update information corresponding to the owner (Ferenczi: Paragraph 19).
Citation of Pertinent Prior Art
23. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Ayyagari (U.S. Pre-Grant Publication No. 20230385791): Describes systems and methods that relate generally to providing a software packet for generating an embedded non-fungible token purchase interface.
Ericson (U.S. Pre-Grant Publication No. 20190205932): Describes systems and methods that relate to providing content to a user through a webpage, and more particularly to enabling the provisioning of targeted content to a user through a webpage using smart contracts stored on a blockchain.
Madhusudhan (U.S. Pre-Grant Publication No. 20230071093): Describes a system and method for enabling an efficient and user-friendly way to list NFT assets across multiple marketplaces.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM D NEWLON whose telephone number is (571)272-4407. The examiner can normally be reached Mon - Fri 8:30 - 4:30.
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, Matthew Gart can be reached at (571) 272-3955. 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.
/WILLIAM D NEWLON/Examiner, Art Unit 3696
/John H. Holly/Primary Examiner, Art Unit 3696
Prosecution Insights