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 .
Terminal Disclaimer
The terminal disclaimer filed on 5/21/2025 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of US 10535062 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Response to Amendment
This action is in response to the applicant’s communication received on 05/21/2025.
Status of the Claims
This is a FINAL Office Action rejection prepared in response to Applicant’s amendments filed on
08/20/2025.
Claims 1, 4-5, 7, 12, 15 and 18-20 are amended.
Claim 6 is cancelled.
Claims 1-5 and 7-20 are pending and have been considered below.
Claim Interpretation
Nonfunctional language:
Regarding claims 1and 15, the limitations “the ticket NFT corresponding to one of a plurality of ticket NFTs having associated ticket metadata” and “the secure real-time NFT repository is separate from the blockchain-based decentralized computer system” are non-functional material that do not move to distinguish over prior art as they do not affect the recited steps of the claim.
Regarding claim 13, the limitation “the ticket NFT includes transaction restrictions metadata indicating restrictions” is non-functional material that do not move to distinguish over prior art as they do not affect the recited steps of the claim.
Regarding claim 14, the limitation “the ticket NFT includes transaction restrictions data indicating use conditions” is non-functional material that do not move to distinguish over prior art as they do not affect the recited steps of the claim.
Intended Use/Result language:
Regarding claims 1 and 15, the claim limitations: “for a ticket transaction” in “receiving a ticket transaction request for a ticket transaction…”; “for identifying the…” in “the NFT metadata including NFT identification metadata…”; “for authenticating an authorized user…” in “the one of a plurality of ticket NFTs also associated with user authentication metadata for authenticating…”; and “associated with a user of the client” in “sending the transaction metadata to a wallet associated with a user of the client device,…” consist entirely of language disclosing an intended result/use, which imparts neither structure nor functionality to the claimed method, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Regarding claim 5 and 19, the claim limitation: “indicates ownership of the ticket NFT is verified” in “the ownership validation response indicates ownership of the ticket NFT is verified when the ticket NFT is authenticated based on the NFT authentication data” consist entirely of language disclosing an intended result/use, which imparts neither structure nor functionality to the claimed method, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Regarding claim 8, the claim limitation: “indicates whether or not ownership of the ticket NFT is verified” in “the ownership validation response indicates whether or not ownership of the ticket NFT is verified.” consist entirely of language disclosing an intended result/use, which imparts neither structure nor functionality to the claimed method, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Regarding claim 9, the claim limitation: “to facilitate the ticket transaction” in “ownership validation response includes credentials data to facilitate the ticket transaction when ownership of the ticket NFT is verified.” consist entirely of language disclosing an intended result/use, which imparts neither structure nor functionality to the claimed method, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Regarding claim 13, the claim limitation: “indicates ownership of the ticket NFT is verified” in “the ownership validation response indicates ownership of the ticket NFT is verified only when the restrictions are met.” consist entirely of language disclosing an intended result/use, which imparts neither structure nor functionality to the claimed method, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Regarding claim 14, the claim limitation: “indicates ownership of the ticket NFT is verified” in “the ownership validation response indicates ownership of the ticket NFT is verified only when the use conditions are met.” consist entirely of language disclosing an intended result/use, which imparts neither structure nor functionality to the claimed method, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Claim Rejections - 35 USC § 112
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 and 15 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1 and 15, the recited limitation “indicating approval of the ticket transaction based on the owner validation response, the user identification data and authentication of the user based on the user authentication metadata stored in the secure real-time NFT repository.” is indefinite. It is unclear whether the approval requires all three elements independently (ownership validation, user identification data and authentication), or whether some elements are dependent upon others. The modifying phrase “based on the user authentication metadata stored…” is ambiguous as it could apply only to the authentication of the user, to both the user identification data and authentication, or to the entire approval process. Additionally, the recited limitation mix data structures, a process, and a response which renders the scope of the limitation uncertain. One of ordinary skill in the art cannot determine with reasonable certainty the conditions required for the system to indicate approval of the ticket transaction.
Claims 1 and 15 recite the limitations "the NFT metadata", “the user of the client device” and “the client device”. There is insufficient antecedent basis for these limitation in the claim. Specifically, it is unclear whether the “NFT metadata” is intended to refer to the previously recited “ticket metadata” or to a different data element. Additionally, the claim recites “the user of the client device” on line 14, followed by the recitation of “a user of the client device” in line 20 which is inconsistent and creates uncertainty as to whether it introduces a new distinct user or is referring to the previously recited user. Without clear antecedent basis, the relationship between these recitations is unclear. Therefore the claim must be amended to recite proper antecedent basis.
Claims 2-14 and 16-20 are also rejected as they depend from either claims 1 or 15.
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-5 and 7-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-5 and 7-14 are directed to a system (i.e., machine, and manufacture). Claims 15-20 are directed to a method (i.e., process). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 15, recites (i.e., sets forth or describes) an abstract idea. Claim 1 is significantly similar to claim 15. As such claim 1 also recites an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A method comprising: receiving a ticket transaction request for a ticket transaction having a ticket NFT associated therewith;
the ticket NFT corresponding to one of a plurality of ticket NFTs having associated ticket metadata,
each of the plurality of ticket NFTs stored via a plurality of data blocks linked together using cryptography and spread over a blockchain-based decentralized computer system that contemporaneously performs geographically distinct calculations over a plurality of different nodes,
the NFT metadata including NFT identification metadata for identifying the one of the plurality of ticket NFTs,
the one of a plurality of ticket NFTs also associated with user authentication metadata for authenticating an authorized user of the one of a plurality of ticket NFTs,
the user authentication metadata associated with the user of the client device that includes a user device identifier associated with the client device, and wherein
the user authentication metadata is stored in a secure real-time NFT repository, wherein
the secure real-time NFT repository is separate from the blockchain-based decentralized computer system;
generating, in response to the ticket transaction request, transaction metadata that includes user identification data;
sending the transaction metadata to a wallet associated with a user of a client device, the wallet containing a private key associated with the ticket NFT;
receiving, from the wallet, a transaction response that is generated based on the private key and the transaction metadata;
generating, based on the transaction response, ownership check data;
sending the ownership check data to the blockchain-based decentralized computer system that stores the ticket NFT;
receiving, from the blockchain-based decentralized computer system, an ownership validation response based on the geographically distinct calculations over the plurality of different nodes; and
indicating approval of the ticket transaction based on the owner validation response, the user identification data and authentication of the user based on the user authentication metadata stored in the secure real-time NFT repository.
Claim 15, recites (i.e., sets forth or describes) a method to validate ticket transactions based on verifying ownership and ticket authentication data against ownership and ticket authentication data stored in a repository. Specifically, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas (i.e., managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to
determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. Here, the additional elements of a communication interface, a processor, and a memory in claim 1 , as well as a wallet, a client device, a blockchain-based decentralized computer system that contemporaneously performs geographically distinct calculations over a plurality of different nodes, NFT and a secure real-time NFT merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Further, the additional element “NFT” generally links the use of the judicial exception to a particular technological environment, that being of non-fungible tokens (MPEP § 2106.05(h)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claims 2-5, 7-14 and 16-20 have also been analyzed for subject matter
eligibility. However, claims 2-5, 7-14 and 16-20 also fail to recite patent eligible subject matter for the
following reasons:
Claims 2 and 16 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)).
the client device further includes a touch screen display, wherein the operations further include generating a graphical user interface in conjunction with the touch screen display, wherein the ticket transaction request is received via the graphical user interface, and wherein the approval of the ticket transaction is indicated via the graphical user interface.
Claims 3 and 17 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea a method to validate ticket transactions by verifying ownership before approving/allowing the transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of graphical user interface fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “NFT” generally links the use of the judicial exception to a particular technological environment, that being of non-fungible (MPEP § 2106.05(h)).
the operations further include indicating, via the graphical user interface, denial of the ticket transaction when ownership of the ticket NFT is not verified.
Claims 4 and 18 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea a method to validate ticket transactions by verifying ownership before approving/allowing the transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “NFT” generally links the use of the judicial exception to a particular technological environment, that being of non-fungible (MPEP § 2106.05(h)).
the ownership check data includes NFT identification data associated with the ticket NFT, NFT authentication data generated based on the private key .
Claims 5 and 19 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea a method to validate ticket transactions by verifying ownership before approving/allowing the transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “NFT” generally links the use of the judicial exception to a particular technological environment, that being of non-fungible (MPEP § 2106.05(h)).
the ownership validation response indicates ownership of the ticket NFT is verified when the ticket NFT is authenticated based on the NFT authentication data.
Claim 7 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea a method to validate ticket transactions by verifying ownership before approving/allowing the transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of a client device fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)).
the authentication metadata associated with the user of the client device includes user biometric data generated via the client device.
Claim 8 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea a method to validate ticket transactions by verifying ownership before approving/allowing the transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “NFT” generally links the use of the judicial exception to a particular technological environment, that being of non-fungible (MPEP § 2106.05(h)).
the ownership validation response indicates whether or not ownership of the ticket NFT is verified.
Claim 9 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea a method to validate ticket transactions by verifying ownership before approving/allowing the transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “NFT” generally links the use of the judicial exception to a particular technological environment, that being of non-fungible (MPEP § 2106.05(h)).
the ownership validation response includes credentials data to facilitate the ticket transaction when ownership of the ticket NFT is verified.
Claim 10 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea a method to validate ticket transactions by verifying ownership before approving/allowing the transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a blockchain system via wireless communications and a ticket reader fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)).
the ownership check data is sent to the blockchain system via wireless communications with a ticket reader and wherein the ownership validation response is received from the blockchain system via the ticket reader.
Claim 11 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea a method to validate ticket transactions by verifying ownership before approving/allowing the transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “NFT” generally links the use of the judicial exception to a particular technological environment, that being of non-fungible (MPEP § 2106.05(h)).
a ticket associated with the ticket NFT and the ticket NFT are both expended when the ticket transaction is approved.
Claims 12 and 20 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea a method to validate ticket transactions by verifying ownership before approving/allowing the transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “NFT” generally links the use of the judicial exception to a particular technological environment, that being of non-fungible (MPEP § 2106.05(h)).
a ticket associated with the ticket NFT is expended when the ticket transaction is approved and wherein the ticket NFT is not expended when the ticket transaction is not approved.
Claim 13 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea a method to validate ticket transactions by verifying ownership before approving/allowing the transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “NFT” generally links the use of the judicial exception to a particular technological environment, that being of non-fungible (MPEP § 2106.05(h)).
the ownership check data includes transaction data wherein the ticket NFT includes transaction restrictions metadata indicating restrictions, and wherein the ownership validation response indicates ownership of the ticket NFT is verified only when the restrictions are met.
Claim 14 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a). The claim further recites the abstract idea a method to validate ticket transactions by verifying ownership before approving/allowing the transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “NFT” generally links the use of the judicial exception to a particular technological environment, that being of non-fungible (MPEP § 2106.05(h)).
the ownership check data includes transaction data wherein the ticket NFT includes transaction restrictions data indicating use conditions, and wherein the ownership validation response indicates ownership of the ticket NFT is verified only when the use conditions are met.
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.
Claims 1-5 and 8-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sliwka (US 2021/0082044 A1) in view of Balasubramanian (US 2022/0229430 A1), and further in view of Pacella (US 2023/0055835 A1).
Regarding claims 1 and 15, Sliwka discloses:
receiving a ticket transaction request for a ticket transaction having a ticket NFT associated therewith; (Sliwka ¶0221, At 1604, a transaction request is received through a suitable process, such as those described above. At 1606, transaction of the item occurs. Sliwka ¶0226, At 1910, the processing system receives a transaction request from the instance of the video game. The transaction request is configured to request a transfer of the token provided to the instance of the video game to an account of a user of the instance of the video game. Sliwka ¶0121, In scenarios where the tokens are non-fungible tokens, the token generation system 302 may generate a unique identifier for each respective token corresponding to the virtual representation.)
the ticket NFT corresponding to one of a plurality of ticket NFTs having associated ticket metadata, each of the plurality of ticket NFTs stored via a plurality of data blocks linked together using cryptography and spread over a blockchain-based decentralized computer system that contemporaneously performs geographically distinct calculations over a plurality of different nodes, (Sliwka ¶0081, Once the platform 100 generates a token, the platform may update the distributed ledger to indicate the existence of a new token. As used herein, a distributed ledger may refer to an electronic ledger that records transactions. A distributed ledger may be public or private… In embodiments, the distributed ledger is a blockchain (e.g., an Ethereum blockchain)… By storing tokens on a distributed ledger, the status of that token can be verified at any time by querying the ledger and trust that it is correct.)
the NFT metadata including NFT identification metadata for identifying the one of the plurality of ticket NFTs, the one of a plurality of ticket NFTs also associated with user authentication metadata for authenticating an authorized user of the one of a plurality of ticket NFTs, the user authentication metadata associated with the user of a client device that includes a user device identifier associated with the client device; (Sliwka ¶0084, The platform 100 may then store the virtual representation and the corresponding tokens on the distributed ledger. For each token, the distributed ledger may store the token, ownership data relating to the token, media content corresponding to the token (or the virtual representation to which the token corresponds), and/or other suitable data relating to the token on the distributed ledger. Sliwka ¶0118, In embodiments, the distributed ledger 310 may store item related data. Item-related data may include, but is not limited to, item identifiers, expiration dates of items, conditions or restrictions placed on the items, item descriptions, media content related to items (e.g., photographs, logos, videos, and the like), documentation of the item, customization options, available sizes, available colors, available materials, functionality options, ingredients, prices, special offers or discounts relating to the item, location information ( e.g., where an item can be delivered/provided), hours available, owner/custodian data, reviews, item type, and the like. In embodiments, the distributed ledger 310 may store user data. User data may include, but is not limited to, identifying information (e.g., user ID, email address, name, and the like), public address, financial information ( e.g., credit card information), transaction history, location data ( e.g., a region of the user or country of the user), preferences, a wish list, subscriptions of the user, items belonging to the user, user connections or contacts, media content relating to the user (e.g., photos or videos of the user), an avatar of the user, and the like.)
generating, in response to the ticket transaction request, transaction metadata that includes user identification data; (Sliwka ¶0075, In some embodiments, the platform may "tokenize" an item on behalf of a seller of the item by generating a set of tokens based on the virtual representation of the item and storing the tokens and associated metadata in a cryptographically secure distributed ledger, thereby making the tokens ( and the virtual representation) verifiable, transferable, and trackable.)
sending the transaction metadata to a wallet associated with a user of a client device (Sliwka ¶0078, In some embodiments, the platform 100 may support a digital wallet that stores the tokens of a user. The digital wallet may be a client application that is provided and/or supported by the platform 100. In embodiments, the digital wallet stores any tokens that are owned by the user associated with the digital wallet and provides an interface that allows the user to redeem, transfer, sell, exchange, or otherwise participate in transactions involving the token.)
generating, based on the transaction response, ownership check data; (Sliwka ¶0085, The platform 100 may receive the request and may update the ownership record of the token in the distributed ledger)
sending the ownership check data to the blockchain-based decentralized computer system that stores the ticket NFT; (Sliwka ¶0084, For each token, the distributed ledger may store the token, ownership data relating to the token, media content corresponding to the token (or the virtual representation to which the token corresponds), and/or other suitable data relating to the token on the distributed ledger.)
receiving, from the blockchain-based decentralized computer system, an ownership validation response based on the geographically distinct calculations over the plurality of different nodes; and (Sliwka ¶0084, As such, the distributed ledger may indicate the existence of the token and that the seller owns the token… In response to the transaction, the platform 100 may update the distributed ledger to indicate an assignment of the token to the user (e.g., to a wallet associated with an account of the user).)
indicating approval of the ticket transaction based on the owner validation response, the user identification data and authentication of the user based on the user authentication metadata stored in the (Sliwka ¶0087, If the token and ownership are verified, the platform 100 may transmit a confirmation of the verification to the client application. A clerk may then allow the user to complete the transaction ( e.g., take possession of the item). Sliwka ¶0234, It is noted that in addition distributed ledgers 2016, event records 2052, ownership data 2054, and supporting data 2056 and other suitable data that supports the decentralized loan processes may be stored in non-distributed datastores, filesystems, databases, and the like.)
Sliwka further teaches:
a communication interface configured to engage in wireless communications; a processor; a memory configured to store operational instructions, that when executed by the processor, cause the processor to perform operations (Sliwka ¶0374, The server may include one or more of memories, processors, computer readable media, storage media, ports (physical and virtual), communication devices, and interfaces capable of accessing other servers, clients, machines, and devices through a wired or a wireless medium, and the like.)
Sliwka does not teach however Balasubramanian does:
storing the user authentication metadata in a secure real-time NFT repository, wherein the secure real-time NFT repository is separate from the blockchain-based decentralized computer system; (¶0040, The asset real time data repository 120 receives and stores real time data about each of the assets 110, 112 and 114 such as being monitored by the monitoring system 116. For example, the asset real time data repository 120 may include sensor data corresponding to each of the operational states of the assets 110, 112 and 114. The sensor data is indicative of health of each of the operational states of the assets 110, 112 and 114. Such data may be received via categorical and non-categorical signals. The signals may be representative of a change trigger, a change percentage or other change values. Other data may include product specification data such as data related to specific product grade being produced at a specific time, any change pattern in the values, product dimensions, and so forth. Based on a type of the connected system 102 and products manufactured in the system 102, a variety of data may be monitored and stored.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to combine the teaching of Sliwka with Balasubramanian’s teaching. One
of ordinary skills in the art would have been motivated to combine these features in order to allow authentication with real-time data and avoid overloading the blockchain with user identification data.
Sliwka does not teach however Pacella does:
the wallet containing a private key associated with the ticket NFT; receiving, from the wallet, a transaction response that is generated based on the private key and the transaction metadata; (Pacella abstract, Based on the signed message and the ownership information
stored in the distributed record, the access management system may verify that a user of the non-fungible digital asset is authorized to access the access-restricted resource. Pacella ¶0031, For example, such a digital wallet application may store keys ( e.g., a public/private key pair) associated with non-fungible digital asset 210, generate a nonce, maintain a list of non-fungible digital assets owned by user 208, and/or perform any other suitable operation(s). Pacella ¶0051, As shown in FIG. 4, at operation 402, user computer system 202 may access a non-fungible digital asset identifier associated with a nonfungible digital asset (e.g., non-fungible digital asset 210). For example, a digital wallet application implemented by user computer system 202 may access the non-fungible digital asset identifier from a storage device associated with user computer system 202. Pacella ¶0052, At operation 404, user computer system 202 may generate a nonce. Operation 404 may be performed in any suitable manner such as described herein. Pacella ¶0053, At operation 406, user computer system 202 may generate a message including the nonce and the non-fungible digital asset identifier. Operation 406 may be performed in any suitable manner such as described herein. Pacella ¶0054, At operation 408, user computer system 202 may sign the message with a private key associated with the non-fungible digital asset to generate a signed message. Operation 408 may be performed in any suitable manner.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modified the combination of Sliwka and Balasubramanian with Pacella’s teaching. One of ordinary skills in the art would have been motivated to combine these features in order to optimize the system to ensure that only a legit owner of the ticket NFT can authorize the processing of transactions related to the ticket NFT.
Regarding claims 2 and 16, Sliwka, Balasubramanian and Pacella disclose each and every element of claim 1 and 15, Pacella further teaches:
the client device further includes a touch screen display, wherein the operations further include generating a graphical user interface in conjunction with the touch screen display, (Pacella ¶0087, For example, I/O module 908 may include hardware and/or software for capturing user input, including, but not limited to, a keyboard or keypad, a touchscreen component (e.g., touchscreen display), a receiver ( e.g., an RF or infrared receiver), motion sensors, and/or one or more input buttons.)
wherein the ticket transaction request is received via the graphical user interface, (Pacella¶0056, As shown in FIG. 5, at operation 502, recipient computer system 204 may receive the signed message generated at operation 408 shown in FIG. 4.)
and wherein the approval of the ticket transaction is indicated via the graphical user interface. (Pacella ¶0049, In certain examples, system 100 may be configured to provide a notification indicating that user 208 of non fungible digital asset 210 is authorized to access restricted resource 212. Such a notification may be provided in any suitable manner such as described herein)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Sliwka, Balasubramanian and Pacella with Pacella’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to improve the usability and accessibility of the graphical user interface with the touchscreen technology.
Regarding claims 3 and 17, Sliwka, Balasubramanian and Pacella disclose each and every element of claim 2 and 16, Pacella further discloses:
the operations further include indicating, via the graphical user interface, denial of the ticket transaction when ownership of the ticket NFT is not verified. (Pacella ¶0047, If system 100 determines that user 208 is not the owner of non-fungible digital asset 210, system 100 may deny access to access-restricted resource 212. In certain examples, system 100 may provide a notification to user 208 indicating that access to access-restricted resource 212 has been denied. Such a notification may be provided in any suitable manner as may serve a particular implementation. For example, system 100 may provide a notification to user 208 by way of a text notification, an email notification, a banner message, etc. provided by way of user computer system 202.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Sliwka, Balasubramanian and Pacella with Pacella’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to improve the usability and efficiency. This is an obvious and straightforward implementation because Sliwka and Balasubramanian’s system already offer validation notifications.
Regarding claim 4 and 18, Sliwka, Balasubramanian and Pacella disclose each and every element of claim 1 and 15. Sliwka further discloses:
the ownership check data includes NFT identification data associated with the ticket NFT, NFT authentication data generated based on the private key. (Sliwka ¶0212, The verification can be made based on the plurality of public addresses, the sets of digital tokens, and the redemption request. For example, the redemption request may include a user id of a user wishing to redeem a token indicated by a token identifier. The platform 100 may validate the ownership of the token by checking that the ledger data links the token identifier indicated in the redemption request to the public address of the user indicated in the redemption request. If so, the ownership of the digital token is verified.)
Regarding claim 5 and 19, Sliwka, Balasubramanian and Pacella disclose each and every element of claim 4 and 18. Sliwka further discloses:
the ownership validation response indicates ownership of the ticket NFT is verified when the ticket NFT is authenticated based on the NFT authentication data. (Sliwka¶0086, The redeem request may include the token ( or an identifier thereof) and a public address of the user ( or any other suitable identifier of the user). The platform 100 receives the redeem request and verifies the validity of the token and/or the ownership of the token. Once verified, the user is granted permission to redeem the token.)
Regarding claim 8, Sliwka, Balasubramanian and Pacella disclose each and every element of claim 4. Sliwka further discloses:
the ownership validation response indicates whether or not ownership of the ticket NFT is verified. (Sliwka ¶0281, verifying the user that is attempting to redeem the collateral token 2042 is the rightful owner of the collateral token 2042 based on ownership data 2052 stored on distributed ledger 2016)
Regarding claim 9, Sliwka, Balasubramanian and Pacella disclose each and every element of claim 4. Sliwka further discloses:
the ownership validation response includes credentials data to facilitate the ticket transaction when ownership of the ticket NFT is verified. (Sliwka¶0129, In embodiments, the verification system 306 verifies data stored on the distributed ledger 310. In embodiments, the verification system 306 may verify the validity of tokens and/or may verify the ownership of a token. The verification system 306 may be configured to validate other types of data stored on the distributed ledger 310 as well.)
Regarding claim 10, Sliwka, Balasubramanian and Pacella disclose each and every element of claim 1. Sliwka further discloses:
the ownership check data is sent to the blockchain system via wireless communications with a ticket reader and wherein the ownership validation response is received from the blockchain system via the ticket reader. (Sliwka¶0087, In this way, the token may be verified by scanning the QR-code or barcode using a client application associated with the platform 100. The client application may provide the token and the public key to the platform 100, which may verify the validity of the token based on the token and the public key.)
Regarding claim 11, Sliwka, Balasubramanian and Pacella disclose each and every element of claim 1. Sliwka further discloses:
a ticket associated with the ticket NFT and the ticket NFT are both expended when the ticket transaction is approved. (Sliwka¶0173, The collateral item corresponding to the collateral token may be stored at the facility until the collateral token is redeemed. Once redeemed, the redeeming user (the borrower or a transferee of the collateral token) may pick up the collateral item from the facility or the collateral item may be shipped to thereto. Sliwka¶0173, The collateral item corresponding to the collateral token may be stored at the facility until the collateral token is redeemed. Once redeemed, the redeeming user (the borrower or a transferee of the collateral token) may pick up the collateral item from the facility or the collateral item may be shipped to thereto.)
Regarding claims 12 and 20, Sliwka, Balasubramanian and Pacella disclose each and every element of claim 1 and 15. Pacella further teaches:
a ticket associated with the ticket NFT is expended when the ticket transaction is approved and wherein the ticket NFT is not expended when the ticket transaction is not approved. (Pacella ¶0032, For example, access-restricted resource 212 may correspond to a virtual event such as a virtual red-carpet event or a virtual premier of a movie. In such an example, non-fungible digital 210 asset may be used to verify that user 208 is authorized to access to the virtual event and may not be reusable thereafter to access any event. However, in such an example, user 208 may keep non-fungible digital asset 210 as a digital collectable item that is associated with the virtual event and that may be sold or traded in any suitable manner such as described herein.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Sliwka, Balasubramanian and Pacella with Pacella’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to provide a different variation on how the system handles the ticket after approval.
Regarding claim 13, Sliwka, Balasubramanian and Pacella disclose each and every element of claim 1. Pacella further teaches:
the ownership check data includes transaction data wherein the ticket NFT includes transaction restrictions metadata indicating restrictions, and wherein (Pacella¶0018, Non-fungible digital assets such as described herein may include or otherwise be associated with metadata that specifies how a non-fungible digital asset may be configured to facilitate access to one or more access-restricted resources… For example, such metadata may include information specifying one or more access-restricted resources to which a non-fungible digital asset is configured to provide access, attributes of a non-fungible digital asset, parameters associated with use and/or transfer of the non-fungible digital asset, and/or any other suitable information.)
the ownership validation response indicates ownership of the ticket NFT is verified only when the restrictions are met. (Pacella¶0060, In certain examples, access to access-restricted resource 212 may be unlockable based on satisfaction of a predefined ownership condition. In such examples, the pre defined ownership condition may include any suitable predefined ownership condition as may serve a particular implementation. For example, a predefined ownership condition may require user 208 to own a threshold number of non-fungible digital assets, may require satisfaction of an interaction requirement ( e.g., a time requirement, a volume requirement, a value requirement, a number of social interactions with other users, a transaction requirement, a geo location visitation requirement, a viewing requirement ( e.g., to avoid spoilers), an event requirement ( e.g., an outcome of a championship game), etc.), and/or any other suitable predefined ownership condition).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Sliwka, Balasubramanian and Pacella with Pacella’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to add additional conditions that have to be met before retuning an ownership validation response.
Regarding claim 14, Sliwka, Balasubramanian and Pacella disclose each and every element of claim 1. Sliwka further discloses:
the ownership check data includes transaction data wherein the ticket NFT includes transaction restrictions data indicating use conditions, and wherein the ownership validation response indicates ownership of the ticket NFT is verified only when the use conditions are met. (Sliwka¶0080, In embodiments, each virtual representation of an item may include or be associated with a smart contract that, for example, provides a set of verifiable conditions that must be satisfied in order to self-execute a transaction ( e.g., transfer of ownership or expiration) relating to an item represented by the virtual representation… In embodiments, a smart contract corresponding to a virtual representation may define the conditions that must be verified to generate new tokens, conditions that must be verified in order to transfer ownership of tokens, conditions that must be verified to redeem a token, and/or conditions that must be met to destroy a token.)
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Sliwka, Balasubramanian and Pacella as applied to claim 1 above, and further in view of Chiarello (US 2021/0217024 A1).
Regarding claim 7, the combination of Sliwka, Balasubramanian and Pacella disclose each and every element of claim 4. They combination do not disclose, however Chiarello teaches:
the user authentication metadata associated with the user of the client device includes user biometric data generated via the client device. (Chiarello ¶0