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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/19/2026 has been entered.
Status of the Claims
This is a Non-FINAL Office Action rejection prepared in response to Applicant’s correspondence filed on 02/19/2026.
Claims 5 and 12 are cancelled.
Claims 1-3, 9-11, and 16 are amended.
Claims 1-4, 6-11 and 13-20 are pending and have been considered below.
Claim Objections
Claims 9 and 16 are objected to because of the following informalities:
Regarding claims 9 and 16 recite “the request comprising an public identifier…” should be amended to “the request comprising a public identifier…”.
Regarding claims 9 and 16, the recited “the user using a public identifier….” should be amended to “the user using the public identifier” as “a public identifier” was previously recited on the claim.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
"accessing from a blockchain, via a blockchain-based entitlement accessing component, a token associated..." , "determining, via a blockchain-based entitlement redemption component, the plurality of parameters...", and "verifying, via the blockchain-based entitlement redemption component the blockchain wallet of the user..." in claim 1, 9 and 16.
"based on verifying, via the blockchain-based entitlement redemption component, the blockchain wallet..." in claim 1.
“receiving, via a blockchain-based entitlement accessing component, a request for entitlement redemption…” and “providing, via the blockchain-based entitlement redemption component, at least a portion of the representation…” in claim 9 and 16.
“responsive to verifying, via the blockchain-based entitlement redemption component, the
“authenticating, via an authentication component, the public identifier…” in claim 16.
“verifying via the blockchain-based entitlement redemption component, a timeframe condition…” in claims 6-7, 13-14 and 18-19.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitations to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-4, 6-11 and 13-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 1, 9 and 16, the limitations "accessing from a blockchain, via a blockchain-based entitlement accessing component, a token associated..." , "determining, via a blockchain-based entitlement redemption component, the plurality of parameters...", and "verifying, via the blockchain-based entitlement redemption component the blockchain wallet of the user..." invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Here the claims and specifications are silent with respect to any structure corresponding to the generic placeholder. Therefore the claim is rejected under 35 U.S.C. 112(a) for lacking adequate written description.
Regarding claim 1, the limitation "based on verifying, via the blockchain-based entitlement redemption component, the blockchain wallet..." invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Here the claims and specifications are silent with respect to any structure corresponding to the generic placeholder. Therefore the claim is rejected under 35 U.S.C. 112(a) for lacking adequate written description.
Regarding claims 9 and 16, the limitations “receiving, via a blockchain-based entitlement accessing component, a request for entitlement redemption…” and “providing, via the blockchain-based entitlement redemption component, at least a portion of the representation…” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Here the claims and specifications are silent with respect to any structure corresponding to the generic placeholder. Therefore the claim is rejected under 35 U.S.C. 112(a) for lacking adequate written description.
Regarding claim 9, the limitation “responsive to verifying, via the blockchain-based entitlement redemption component, the
Regarding claim 16, the limitation “authenticating, via an authentication component, the public identifier…” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Here the claims and specifications are silent with respect to any structure corresponding to the generic placeholder. Therefore the claim is rejected under 35 U.S.C. 112(a) for lacking adequate written description.
Regarding claims 6-7, 13-14 and 18-19, the limitation “verifying via the blockchain-based entitlement redemption component, a timeframe condition…” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Here the claims and specifications are silent with respect to any structure corresponding to the generic placeholder. Therefore the claim is rejected under 35 U.S.C. 112(a) for lacking adequate written description.
Claims 2-4, 8, 10-11, 15, 17 and 20 are also rejected upon rejected parent independent claim 1, 9 or 16.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-4, 6-11 and 13-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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1, 9 and 16, limitations "accessing from a blockchain, via a blockchain-based entitlement accessing component, a token associated..." , "determining, via a blockchain-based entitlement redemption component, the plurality of parameters...", and "verifying, via the blockchain-based entitlement redemption component the blockchain wallet of the user..." invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification fails to disclose sufficient corresponding structure for the claimed limitations. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Regarding claim 1, limitation "based on verifying, via the blockchain-based entitlement redemption component, the blockchain wallet..." invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification fails to disclose sufficient corresponding structure for the claimed limitations. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Regarding claims 9 and 16, limitations “receiving, via a blockchain-based entitlement accessing component, a request for entitlement redemption…” and “providing, via the blockchain-based entitlement redemption component, at least a portion of the representation…”invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification fails to disclose sufficient corresponding structure for the claimed limitations. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Regarding claim 9, limitation “responsive to verifying, via the blockchain-based entitlement redemption component, the public identifier of the blockchain wallet,…” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification fails to disclose sufficient corresponding structure for the claimed limitations. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Regarding claim 16, limitation “authenticating, via an authentication component, the public identifier…” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification fails to disclose sufficient corresponding structure for the claimed limitations. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Regarding claims 6-7, 13-14 and 18-19, limitation “verifying via the blockchain-based entitlement redemption component, a timeframe condition…” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification fails to disclose sufficient corresponding structure for the claimed limitations. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claims 2-4, 8, 10-11, 15, 17 and 20 are also rejected upon rejected parent independent claim 1, 9 or 16.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-4, 6-11 and 13-20 are rejected under 35 U.S.C. 101 because they fail to claim statutory subject matter.
Claims 1-4, 6-11 and 13-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-4 and 6-8 are directed to one or more computer-readable media (i.e., manufacture). Claims 9-11 and 13-15 are directed to computer-implemented method (i.e., process). Claims 16-20 are directed to a system (i.e., machine, and manufacture). 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 9, recites (i.e., sets forth or describes) 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 computer-implemented method comprising:
receiving, via a blockchain-based entitlement accessing component, a request for entitlement redemption, the request comprising an public identifier of a blockchain wallet of a user;
accessing from a blockchain, via the blockchain-based entitlement accessing component, a token associated with the blockchain wallet of the user using a public identifier of the blockchain wallet,
the blockchain comprising a decentralized ledger maintained by a cryptographic protocol and a consensus mechanism, the token cryptographically computed using the cryptographic protocol based on a plurality of parameters of an entitlement stored in the token, the plurality of parameters comprising a representation of the entitlement, a user identity condition for redeeming the entitlement using a first or third-party identification service, a location condition defining a particular location for redeeming the entitlement and an indication of an application for redeeming the entitlement, the representation of the entitlement indicating a particular benefit for a particular product or service
based on verifying the token by validating that the token was cryptographically computed in accordance with the cryptographic protocol and confirmed by the consensus mechanism,
determining, via a blockchain-based entitlement redemption component, the plurality of parameters of the entitlement stored in the token,
verifying, via the blockchain-based entitlement redemption component, the blockchain wallet of the user, the user identity condition by authenticating the user the first or third-party identification service, and the location condition using detected location data; and
responsive to verifying, via the blockchain-based entitlement redemption component, the public identifier of the blockchain wallet, the user identity condition, and the location condition:
providing, via the blockchain-based entitlement redemption component, at least a portion of the representation of the entitlement to the application with an instruction to redeem the entitlement to cause the application to execute redeeming the entitlement in real-time in response to the request.
Claim 9, recites (i.e., sets forth or describes) a method for redeeming an entitlement by verifying user identification data of a customer and entitlement parameters. The claim achieves this by:
a) receiving a request to redeem an entitlement that includes a public identifier for the user,
b) obtaining a token associated to the public identifier,
c) verifying the token was cryptographically computed in accordance with the cryptographic protocol and confirmed by the consensus mechanism,
d) determining parameters stored in the token,
e) verifying the public identifier, user identity condition and location condition,
f) providing the entitlement to the user based on the verification.
Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas (i.e., fundamental economic practices). In regards to the “the token cryptographically computed using the cryptographic protocol based on a plurality of parameters of an entitlement stored in the token” and “verifying the token by validating that the token was cryptographically computed in accordance with the cryptographic protocol and confirmed by the consensus mechanism” the examiner finds this to be a mathematical concept. As such the subject further recites an abstract idea.
Claim 1 is similar to claim 9 but further includes the additional limitation of “causing the application to execute redeeming the entitlement by communicating the representation of the entitlement to the application with an instruction to redeem the entitlement”. This additional limitation still recites and abstract idea under “certain methods of organizing human activity” grouping of abstract ideas (i.e., fundamental economic practices).
Claim 16 is similar to claim 9 but further includes the additional limitation of “authenticating, via an authentication component, the public identifier of the blockchain wallet of the user using a device of the user”. This additional limitation still recites and abstract idea under “certain methods of organizing human activity” grouping of abstract ideas (i.e., fundamental economic practices).
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 blockchain-based entitlement redemption component, an identity verification application, a blockchain-based entitlement accessing component, a blockchain wallet, a blockchain, a device, an authentication component, and an application merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). 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-8, 10-15 and 17-20 are have also been analyzed for subject matter
eligibility. However, claims 2-8, 10-15 and 17-20 also fail to recite patent eligible subject matter for the
following reasons:
Claim 2 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving a request for entitlement redemption from a device of the user;
using the device of the user to authenticate the public identifier of the blockchain wallet of the user; and
causing the application to execute redeeming the entitlement in real-time in response to the request.
The claim further recites an abstract idea. 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)). The additional element of a device is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 3 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving, via the application, the public identifier of the blockchain wallet of the user from a device of the user; and
causing the application to execute redeeming the entitlement in real-time in response to receiving the public identifier of the blockchain wallet of the user.
The claim further recites an abstract idea. 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 they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). The additional elements of an application, a blockchain wallet and a device of the user are recited at a high level generally amounting to no more than tools to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 4 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
accessing the token associated with the blockchain wallet of the user at a scheduled interval in order to cause the application to execute redeeming the entitlement asynchronously.
The claim further recites an abstract idea. 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 they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). The additional elements of an application and a blockchain wallet are recited at a high level generally amounting to no more than tools to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claims 6-7, 13-14 and 18-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).
verifying via the blockchain-based entitlement redemption component, a timeframe condition for redeeming the entitlement before causing the application to execute redeeming the entitlement; and
receiving data from a device of the user to verify the user condition, the location condition and the timeframe condition.
The claim further recites an abstract idea. 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 they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). The additional elements of an application, a device and a blockchain-based entitlement redemption component are recited at a high level generally amounting to no more than tools to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claims 8, 15 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 application communicates with hardware associated with the application in order to execute redeeming the entitlement.
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 additional element of an application is recited at a high level generally amounting to no more than tools to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 10 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving a request for entitlement redemption from a device of the user;
using the device of the user to authenticate the public identifier of the blockchain wallet of the user.
The claim further recites an abstract idea. 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 they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). The additional elements of a device and a blockchain wallet are recited at a high level generally amounting to no more than tools to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 11 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving the request for entitlement redemption from the application; and using a device of the user to authenticate the public identifier of the blockchain wallet of the user before transmitting the request by the application.
The claim further recites an abstract idea. 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 they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). The additional elements of an application, a device and a blockchain wallet are recited at a high level generally amounting to no more than tools to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 17 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the request is received from at least one of the devices of the user or a corresponding device executing the application.
The claim further recites an abstract idea. 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 they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). The additional elements of an application and at least one of the devices are recited at a high level generally amounting to no more than tools to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
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-4, 6-11, and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Metnick (US 2023/0111668 A1) in view of Sliwka (US 2025/0156828 A1) in further view of Connor (US 2020/0328890 A1).
Regarding claim 1, Metnick discloses:
determining, via a blockchain-based entitlement redemption component, the plurality of parameters of the entitlement stored in the token, (Metnick ¶0214, EI rules, and use parameters. The establishing may include receiving a plurality of exchange items from the EI issuing server 920, where the plurality of exchange items includes the exchange item, and establishing the initial validity of the exchange item with the EI issuing server 920. For example, the set up processing 936 receives EI information 950 and an EI rule set 952 from the EI issuing server 920, where the EI issuing server 920 issues trust information 954 (e.g., a first contract block of the contract blockchain) to the EI trusted module 922 while generating the EI information 950 and the EI rule set 952. Having received the EI information 950 and the EI rule set 952, the set up processing 936 exchanges set up verification 956 with the EI trusted module 922 to validate the EI information 950 and the EI rule set 952. Metnick ¶0299, The method further includes step 1312, where the processing module sends use information regarding the redemption request to a marketplace server of the data communication system. The use information includes a representation of at least some of the information within the redemption request. For example, the use information includes a portion (e.g., particular bit pattern, last four digits, etc.) of a serial number (e.g., exchange item ID) associated with the exchange item. As another example, the use information includes the user computing device ID. As yet a further example, the user information includes a blockchain ID. As still a further example, the use information includes the portion of the serial number, the user computing device ID, and the representation of the public key. See claim 11)
verifying, via the blockchain-based entitlement redemption component, the blockchain wallet of the user, the user identity condition by authenticating the user using the first or third-party identification service, the location condition using detected location data (Metnick ¶0079, When a buyer desires to purchase an exchange item, the mobile application 198 of the buyer's computing device 16 sends a request to buy a selected exchange item to the MP server(s) 18. The server(s) 18 perform the buyer verification 208 functional block to determine whether the buyer is valid (e.g., the user and/or buyer computing device are valid). Metnick ¶0183, A condition of the conditions for the plurality of exchange items further includes one of a range of time, a range of dates, a geographic location, a building address, a list of items, a user tendency profile, and a user loyalty profile. Metnick ¶0269, Having received the buyer use information 976, the use processing 940 validates the buyer use information 976 to produce validated buyer use information. The validating includes one or more of validating the blockchain ledger (i.e., verifying that a signature is valid within the blockchain ledger), accessing the marketplace database 20 to verify that the El has sufficient remaining balance and that the El buyer computing device is associated with ownership of the El, and exchanging use verification 978 with the El trusted module 922 to validate the El (i.e., sufficient remaining balance for the transaction). Metnick ¶0271, The method includes step 1220 where a processing module (e.g., of a marketplace server) receives buyer use information from a buyer computing device, where the buyer use information indicates an item for direct purchase from a particular merchant by redemption of an exchange item) EI) held by the buyer computing device. For example, the buyer computing device obtains a merchant identifier (ID), generates the buyer use information to include one or more of the merchant ID, an identifier of the item, El information, and a blockchain ledger held in a digital wallet in accordance with a secure custody protocol, and transmits the buyer use information to the processing module. Metnick ¶0272, The method continues at step 1222 for the processing module validates the buyer use information. The validating includes one or more of validating the blockchain ledger (i.e., verifying that a signature is valid within the blockchain ledger), accessing the marketplace database to verify that the El has sufficient remaining balance and that the buyer computing devices associated with ownership of the EI, and exchanging use verification with an El trusted module to further validate El (i.e., sufficient remaining balance of the EI). Metnick ¶0288, the processing module indicates the high risk of the unfavorable redemption when the sensor summary information does not correlate to expected sensor information associated with a location of the buyer computing device. Metnick ¶0310, The El use information 949 includes one or more of identity of item for purchase, identity the merchant affiliated with the request, pricing information of the item for purchase, purchasing rules (e.g., El rules, conditions, use options, etc.), and the type of purchase (e.g., a direct purchase without aid of a point-of-sale terminal).)
based on verifying, via the blockchain-based entitlement redemption component, the blockchain wallet, the user identity condition and the location condition, causing the application to execute redeeming the entitlement by communicating the representation of the entitlement to the application with an instruction to redeem the entitlement. (Metnick abstract, The method further includes verifying the signature utilizing the extracted public key and when the signature is verified, authorizing the redemption request. Metnick ¶0305, Having verified the signature, the method further includes step 1320, where the processing module facilitates execution of the redemption request. For example, the processing module generates a secure transactions block to be added to the blockchain. In an example, the secure transactions block includes the exchange item ID, the ID for the item being acquired, the signature of the user computing device, payment information, a hash of a previous block of the blockchain, a hash of a transaction portion of the blockchain, and a nonce value. Metnick ¶0355, One or more functions associated with the methods and/or processes described herein can require data to be manipulated in different ways within overlapping time spans. The human mind is not equipped to perform such different data manipulations independently, contemporaneously, in parallel, and/or on a coordinated basis within a reasonable period of time, such as within a second, a millisecond, microsecond, a real-time basis or other high speed required by the machines that generate the data, receive the data, convey the data, store the data and/or use the data.)
Metnick further discloses:
having a plurality of executable instructions embodied thereon, which, when executed by one or more processors, cause the one or more processors to perform a method comprising: (Metnick ¶0148, The method described above in conjunction with one or more of the processing module, the seller device, the marketplace server, the buyer device, the merchant server, the second merchant server, can alternatively be performed by other modules of the exchange item marketplace network or by other devices. In addition, at least one memory section (e.g., a non-transitory computer readable storage medium, a computer readable memory) that stores operational instructions can, when executed by one or more processing modules of one or more computing devices of the exchange item marketplace network, cause the one or more computing devices to perform any or all of the method steps described above.)
Metnick does not disclose, however Sliwka teaches:
accessing from a blockchain, via a blockchain-based entitlement accessing component, a token associated with a blockchain wallet of a user using a public identifier of the blockchain wallet, (Sliwka ¶0218, In response to receiving the redemption request, the redemption system 404 may provide the token, the public address of the user attempting to redeem the token, and the public key used to digitally sign the token to the ledger management system 104. The ledger management system 104 may then either verify or deny the token/public address combination. The ledger management system 104 may deny the combination if the token is not a valid token and/or the user is not the listed owner of the token. The ledger management system 104 may verify the token/public address combination if the token is deemed valid and the requesting user is deemed to be the owner of the token.)
the blockchain comprising a decentralized ledger maintained by a cryptographic protocol and a consensus mechanism, (Sliwka ¶0004, Blockchain technology has revolutionized digital asset ownership and transactions through decentralized, immutable ledgers. ¶0130, In many implementations of distributed ledger technology, the management and extension of the distributed ledger is decentralized and distributed over computer systems operated by numerous unaffiliated entities who contribute their computing power to the system. ¶0146, In embodiments, the tokenization platform 100 manages one or more cryptographic ledgers (or “distributed ledgers”) and provides flexible functionality of virtual representations of items such as goods, services, and/or experiences with the fulfillment and satisfaction of said items. ¶1016, Techniques described herein solve these and other problems by providing a DRM NFT that may be used to securely store digital assets on cryptographic ledgers (e.g., distributed ledgers, distributed filesystems, etc.) using cryptographic techniques. ¶1064, It is noted that in embodiments, the CoC platform may be implemented using a distributed ledger that uses a proof-of-stake consensus mechanism, such that the environmental impact of such a distributed ledger is much less than counterpart proof-of-work consensus mechanisms. ¶1523, Entities recording transactions, such as in a blockchain, may reach consensus using an algorithm such as proof-of-stake, proof-of-work, and proof-of-storage.)
the plurality of parameters comprising a representation of the entitlement, a user identity condition for redeeming the entitlement using a first or third-party identification service, a location condition defining a particular location for redeeming the entitlement and an indication of an application for redeeming the entitlement, the representation of the entitlement indicating a particular benefit for a particular product or service; (Sliwka ¶0158, In some scenarios, the user may be redeeming a token corresponding to a digital item (e.g., a gift card, an mp3, a movie, a digital photograph)… In another scenario, the user may be redeeming a token corresponding to a physical good (e.g., clothing, food, electronics, etc.) or a physical service (e.g., maid service). Sliwka ¶0221, In some embodiments, certain tokens generated by the tokenization platform 100 may include temporal attributes that relate to the redeemability of the token. In these embodiments, the temporal attributes may define when a token becomes redeemable and/or when the token is no longer redeemable. The temporal attributes of a token may be implemented in a number of different ways. For example, in some embodiments the temporal attributes may be included in the mutable or immutable attributes of the token. Sliwka ¶0232, A tokenized token may refer to a non-fungible token that has attributes that define the type of currency and an amount of currency represented by the coin (e.g., an amount of bitcoin, Ethereum, dollars, pounds, or the like). In some of these embodiments, a tokenized token may refer to a non-fungible token that has a set of attributes defining characteristics of such token in addition to having a set of fungible and/or non-fungible tokens representing digital currency balance(s) enclosed within a tokenized token and/or other digital item(s). In addition, tokenized token can contain business rules governing redemption, transfer and other tokenized token lifecycle mechanisms. In some embodiments, the ledger bridging system 416 mints the new token by requesting the generation of a new token by the token generation system 302. The ledger bridging system 416 may provide the type of currency, the amount of currency, and ownership data (e.g., the account to which the new tokenized token will belong) to the token generation system 302. In response, the token generation system 302 generates a tokenized token, for example, in the manner described above. In this way, the token generation system 302 treats the currency as an “item.” In this way, a tokenized token may be exchanged (e.g., for other tokenized tokens or tokenized items), gifted, and/or redeemed. Sliwka ¶0296, At 904, one or more digital tokens are generated. In embodiments, the digital tokens are unique digital tokens. Each unique digital token may include a set of digital attributes that correspond to the set of item attributes. In embodiments, N digital tokens are generated and linked to an item or virtual representation thereof.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Metnick’s invention with Sliwka’s teaching. One of ordinary skills in the art would have been motivated to combine these elements because tokens are typical components of blockchain systems. Therefore it would be obvious to access a token that represent the entitlement in order to obtain data necessary to facilitate the redemption of the entitlement.
The combination of Metnick and Sliwka do not disclose, however Connor teaches:
the token cryptographically computed using the cryptographic protocol based on a plurality of parameters of an entitlement stored in the token, (Connor ¶0030, FIG. 2 shows a flow chart illustrating the steps of minting a token commitment on a ZKP-enabled DLN to represent a real world (e.g., off-chain) or physical asset on the ZKP-enabled DLN, according to an embodiment… In some implementations, the sender 110a can generate, using the computing node 102a, an alpha-numeric value that is uniquely associated with some identifying parameters (e.g., serial numbers, model numbers, etc.) of the asset, and the alpha-numeric value can be used as the asset identifier that hides the real identity of the non-fungible physical asset. As another example, a unique asset identifier can be generated by cryptographically hashing the identifying parameters of the non-fungible physical asset to generate an asset token that can serve as the unique asset identifier. ¶0031, In some implementations, the cryptographic hashing computation can include the application of a cryptographic hashing algorithm or function H such as but not limited to the SHA-256 algorithm or function, on the identifying parameters of the non-fungible physical asset. For instance, if the non-fungible physical asset is a vehicle, an asset token to represent the vehicle on the ZKP-enabled DLN 100 can be generated by applying a hashing function (e.g., SHA-256) on one or more of the identifying parameters of the vehicle such as the vehicle identification number, model type, model year, etc. As a non-limiting example, a unique asset identifier or asset token A for a vehicle can be generated by computing A=H(VIN), where VIN is the vehicle identification number of the vehicle and H is a hashing function or algorithm. Accordingly, the asset token can serve as a unique asset identifier without exposing or revealing to other participants of the ZKP-enabled DLN 100 any of the identifying parameters of the asset (e.g., vehicle). ¶0032, At 204, a non-fungible physical asset can be registered or represented on the ZKP-enabled DLN 100 for the first time by generating or minting a non-fungible token commitment that encodes at least some aspects of the non-fungible asset and/or the ownership of the asset on the ZKP-enabled DLN 100. ¶0035, In some embodiments, the minting of a non-fungible token commitment to represent an asset ZKP-enabled DLN 100 for the first time may include the computation of a token commitment Z.sub.s as follows: Z.sub.s=H(A{circle around (*)}Pk.sub.s{circle around (*)}S.sub.s{circle around (*)}CP.sub.A), where A is the asset token identifying the asset (e.g., obtained by hashing, off-chain, at least some identifying parameters of the asset), Pk.sub.s is the public key on the ZKP-enabled DLN 100 that is associated with the sender 110a (i.e., the current and rightful owner of the asset), S.sub.s is a random nonce selected or generated by the computing node 102a of the sender 110a, CPA is the counting parameter for the asset token A (e.g., the number of times a request for recovery has been made for the asset token A and approved by the arbitrator), H is a cryptographic hashing function or algorithm (e.g., SHA-256), and {circle around (*)} represents a combining operator (e.g., the concatenation operator |, etc.))
based on verifying the token by validating that the token was cryptographically computed in accordance with the cryptographic protocol and confirmed by the consensus mechanism, (¶0041, Upon receiving the token commitment Z.sub.s, the hash of the asset token H(A), and/or other public parameters, and/or the ZKPs, in some embodiments, the self-executing code or smart contract may verify the ZKPs… In some implementations, the smart contract may verify the ZKPs to verify statements included in the ZKPs, such as the statements that H(A) includes A (i.e., the statement that H(A) is obtained by applying a hashing function or algorithm on the asset token A) and the statement that the token commitment Z.sub.s also includes A (i.e., the statement that Z.sub.s is obtained by applying a hashing function or algorithm on the asset token A). Further, the smart contract may verify that there has never been an H(A) provided to the smart contract previously (e.g., if the asset has never been represented on the ZKP-enabled DLN 100). In addition, the smart contract may also verify that the initial value of CP.sub.A used in calculating Z.sub.s was determined or selected by the pre-determined or pre-approved algorithm.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Metnick and Sliwka with Connor’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to have a unique identifiable token that is derived from a plurality of parameters, thereby improving the ability of the system to uniquely identify the entitlements.
Further, the claimed limitation “for...” in “…for redeeming the entitlement”, “for…” in “the representation of the entitlement indicating a particular benefit for a particular product or service”, “to…” in “an instruction to redeem the entitlement” and “causing…” in “causing the application to execute redeeming the entitlement…” consists of language disclosing an intended use/result, 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 2, the combination of Metnick, Sliwka and Connor further discloses:
receiving a request for entitlement redemption from a device of the user; using the device of the user to authenticate the public identifier of the blockchain wallet of the user; and (Sliwka ¶0218, The redemption system 404 may receive a request to redeem (or “redemption request”) the token. The redemption request may include the token or an identifier of the token (e.g., an alphanumeric string) and may include a public address of the user attempting to redeem the token. In embodiments, the redemption request may further include the public key used to digitally sign the token. In response to receiving the redemption request, the redemption system 404 may provide the token, the public address of the user attempting to redeem the token, and the public key used to digitally sign the token to the ledger management system 104. The ledger management system 104 may then either verify or deny the token/public address combination. The ledger management system 104 may deny the combination if the token is not a valid token and/or the user is not the listed owner of the token. The ledger management system 104 may verify the token/public address combination if the token is deemed valid and the requesting user is deemed to be the owner of the token.)
causing the application to execute redeeming the entitlement in real-time in response to the request. (Sliwka ¶0219, In response to verifying the token/public address combination, the redemption system 206 may execute a workflow corresponding to the virtual representation to which the redeemed token corresponds. For example, in some scenarios, the user may be redeeming a token corresponding to a digital item (e.g., a gift card, an mp3, a movie, a digital photograph). In these scenarios, the redemption system 404 may determine a workflow for satisfying the digital item. For example, the redemption system 404 may request an email address from the user or may look up an email address of the user from the distributed ledger. In this example, the redemption system 404 may email a link to download the digital item to the user's email account or may attach a copy of the digital item in an email that is sent to the user's email account. In another scenario, the user may be redeeming a token corresponding to a physical good (e.g., clothing, food, electronics, etc.) or a physical service (e.g., maid service). In the case of a physical good, the redemption system 404 may determine a workflow for satisfying the physical item. For example, the redemption system 404 may present a GUI to the user that allows the user to enter shipping information of the user. Alternatively, the redemption system 404 may look up the shipping information of the user from, for example, the distributed ledger or a user database. The redemption system 404 may then initiate shipment of the physical good. For example, the redemption system 404 (or a logistics system) may transmit a shipping request to a warehouse that handles shipments of the good indicating the shipping information. The foregoing are examples of how a token may be redeemed.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Metnick, Sliwka and Connor with Sliwka’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements as it would be an obvious variation to provide automatic validation and real time redemption of entitlements to improve user experience.
Further, the claimed limitation “for…” in “receiving a request for entitlement redemption from a device of the user” and “causing…” in “…and causing the application to execute redeeming the entitlement in real-time in response to the request” consists of language disclosing an intended use/result, 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 3, the combination of Metnick, Sliwka and Connor further teaches:
receiving, via the application, the public identifier of the blockchain wallet of the user from a device of the user; and (Sliwka ¶0150, A user device may access the platform 100 via a website, a web application, a native application, or the like. In embodiments, the platform 100 may provide a first graphical user interface to user devices 190 associated with a seller and a second graphical user interface to a user device 190 associated with an end 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. Sliwka ¶0159, 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. If the token and ownership are verified, the platform 100 may transmit a confirmation of the verification to the client application.)
causing the application to execute redeeming the entitlement in real-time in response to receiving the public identifier of the blockchain wallet of the user. (Sliwka ¶0159, A clerk may then allow the user to complete the transaction (e.g., take possession of the item). Sliwka ¶0219, In response to verifying the token/public address combination, the redemption system 206 may execute a workflow corresponding to the virtual representation to which the redeemed token corresponds. For example, in some scenarios, the user may be redeeming a token corresponding to a digital item (e.g., a gift card, an mp3, a movie, a digital photograph). In these scenarios, the redemption system 404 may determine a workflow for satisfying the digital item. For example, the redemption system 404 may request an email address from the user or may look up an email address of the user from the distributed ledger. In this example, the redemption system 404 may email a link to download the digital item to the user's email account or may attach a copy of the digital item in an email that is sent to the user's email account. In another scenario, the user may be redeeming a token corresponding to a physical good (e.g., clothing, food, electronics, etc.) or a physical service (e.g., maid service). In the case of a physical good, the redemption system 404 may determine a workflow for satisfying the physical item. For example, the redemption system 404 may present a GUI to the user that allows the user to enter shipping information of the user. Alternatively, the redemption system 404 may look up the shipping information of the user from, for example, the distributed ledger or a user database. The redemption system 404 may then initiate shipment of the physical good. For example, the redemption system 404 (or a logistics system) may transmit a shipping request to a warehouse that handles shipments of the good indicating the shipping information. The foregoing are examples of how a token may be redeemed.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Metnick, Sliwka and Connor with Sliwka’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to provide automatic validation and real time redemption of entitlements which will improve user experience.
Further, the claimed limitation “causing…” in “…and causing the application to execute redeeming the entitlement in real-time in response …” consists of language disclosing an intended result, 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 4, the combination of Metnick, Sliwka and Connor further teaches:
accessing the token associated with the blockchain wallet of the user at a scheduled interval in order to cause the application to execute redeeming the entitlement asynchronously. (Sliwka ¶0999, At 9302, the redemption smart contract 9028 may receive one or more redemption parameters, redemption rules, and/or other redemption smart contract configuration data. The redemption parameters may include, for example, a schedule redemption date/time (e.g., a time after which redemptions may occur), an expiration date/time (e.g., a time after which redemptions may no longer occur), and/or other data for controlling redemption. The redemption rules may specify for example, which attributes of the received tokens to update during redemption, what data to store in a redemption log, and/or the like. In embodiments, some or all of this data may be specified as mutable configuration data that may be re-configured (e.g., in case the redemption date needs to be pushed back due to delays). Additionally or alternatively, some data may be specified as immutable (e.g., if redemption is required by a certain date, the redemption date may be unchangeable). At 9304, the redemption smart contract may store the data, configure various smart contract functions (e.g., redemption functions), and/or the like.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Metnick, Sliwka and Connor with Sliwka’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order reduce the need to require real-time user interaction to access and redeem the entitlement, enhancing the scalability and automation of the system.
Further, the claimed limitation “to…” in “…at a scheduled interval in order to cause the application …” consists of language disclosing an intended result, 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 claims 6-7, the combination of Metnick, Sliwka and Connor further discloses:
verifying via the blockchain-based entitlement redemption component, a timeframe condition for redeeming the entitlement before causing the application to execute redeeming the entitlement, and (Metnick ¶0163 The method continues to step 904 when the EI rule has not been changed where the processing module determines whether the EI rule has expired (e.g., detecting that an active timeframe associated with the EI rule has elapsed). The method loops back to step 890 when the EI rule has not expired. Metnick ¶0183, A condition of the conditions for the plurality of exchange items further includes one of a range of time, a range of dates, a geographic location, a building address, a list of items, a user tendency profile, and a user loyalty profile. For example, the marketplace server 18 obtains the condition from a corresponding condition source. Metnick ¶0271, The method includes step 1220 where a processing module (e.g., of a marketplace server) receives buyer use information from a buyer computing device, where the buyer use information indicates an item for direct purchase from a particular merchant by redemption of an exchange item) EI) held by the buyer computing device. For example, the buyer computing device obtains a merchant identifier (ID), generates the buyer use information to include one or more of the merchant ID, an identifier of the item, EI information, and a blockchain ledger held in a digital wallet in accordance with a secure custody protocol, and transmits the buyer use information to the processing module. Metnick ¶0272, The method continues at step 1222 for the processing module validates the buyer use information. The validating includes one or more of validating the blockchain ledger (i.e., verifying that a signature is valid within the blockchain ledger), accessing the marketplace database to verify that the EI has sufficient remaining balance and that the buyer computing devices associated with ownership of the EI, and exchanging use verification with an EI trusted module to further validate EI (i.e., sufficient remaining balance of the EI). Metnick ¶0310, The EI use information 949 includes one or more of identity of item for purchase, identity the merchant affiliated with the request, pricing information of the item for purchase, purchasing rules (e.g., EI rules, conditions, use options, etc.), and the type of purchase (e.g., a direct purchase without aid of a point-of-sale terminal). Purchasing rules are allowable values or ranges of values of parameters associated with an exchange item as a function of one or more conditions and of one or more use options. For example, a parent may purchase a digital exchange item (e.g., a gift card) for a child that can be used at a local coffee shop. During the purchase, the parent established a purchasing rule such that the exchange item can only be used on food and/or that a certain balance must be maintained on the exchange item.)
While Metnick does not explicitly state that a timeframe condition is verified, Metnick discloses that the EI information is verified. It also states that EI information includes conditions which encompass date ranges and range of time. Therefore, by verifying EI information, Metnick inherently verifies the timeframe condition contained within the EI information.
receiving data from a device of the user to verify the user identity condition, the location condition, and the timeframe condition (Metnick ¶0179, In an example of operation of the use of the EI, the EI buyer computing device 926 obtains EI info from the digital wallet 944 to issue buyer use information 976 to the marketplace server 18 when desiring to utilize the exchange item (e.g., EI serial number 005) with a merchant associated with the merchant server 924 for purchase of goods and/or services. Metnick ¶0268, In an example of operation of the redeeming of the exchange item, when the EI buyer computing device 926 initiates redemption of an exchange item (EI) held in the digital wallet 944, the use processing 940 receives buyer use information 976, where the buyer use information 976 indicates an item for direct purchase from a particular merchant utilizing the EI without aid of a point-of-sale terminal.)
Further, the claimed limitation “for…” in “…a timeframe condition for redeeming the entitlement…”, “causing…” in “…causing the application to execute redeeming the entitlement” and “to…” in “receiving data from a device of the user to verify the user identity condition, the location condition, and the timeframe condition” consists of language disclosing an intended result, 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 combination of Metnick, Sliwka and Connor further discloses:
the application communicates with hardware associated with the application in order to execute redeeming the entitlement. (Metnick ¶0277, For example, the EI buyer computing device 926 sends buyer use information 976, via the POS equipment 32, to the merchant server 924 in accordance with the one or more promotions. Metnick ¶0292, When the EI buyer computing device 926 initiates redemption of the EI, the use processing 940 receives merchant use information 1274 from the merchant server 924, where the merchant server receives buyer use information 1272 from the EI buyer computing device 926 via the POS equipment 32, where the buyer use information 1272 includes a signature from the EI buyer computing device, and where the EI buyer computing device 926 generates the signature utilizing a private key of a public/private key pair where the public key is included in the blockchain ledger. Metnick ¶0296, The method continues at step 1284 where the processing module issues authorization information to the POS equipment, where the authorization information is based on verification of the representation of the security aspect with regards to the security aspect. The issuing includes one or more of verifying the received computing device signature utilizing at least one of a public key extracted from the received blockchain ledger and a public key extracted from a copy of the blockchain ledger retrieved from the marketplace database; generating the further merchant use information and sending the further merchant use information to the merchant server, where at least one of the POS equipment and the merchant server may perform a further authorization of the redemption, where the further authorization includes at least one of interpreting a received marketplace server authorization information and verifying the received computing device signature utilizing the public key extracted from the received blockchain ledger.)
Further, the claimed limitation “to…” in “the application in order to execute redeeming the entitlement” consists of language disclosing an intended result, 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, Metnick discloses:
receiving, via a blockchain-based entitlement accessing component, a request for entitlement redemption, the request comprising an identification public identifier of a blockchain wallet of a user;(Metnick abstract, A method for execution by a point of sale device includes receiving a redemption request from a user computing device, the redemption request including a signature generated utilizing a private key of a public/private key pair associated with the user computing device. Metnick ¶0298, The redemption request includes one or more of a user computing device identifier associated with the user computing device, a representation of a public key of a public/private key pair associated with the user computing device, an identifier of an exchange item, a signature generated utilizing a private key of the public/private key pair, a copy of a blockchain associated with the exchange item, and an identifier of an item to acquire utilizing the exchange item. The copy of the blockchain is stored in a digital wallet of the user computing device and includes the representation of the public key and the blockchain is stored in one or more of a marketplace database of the data communication system, and a plurality of computing devices (e.g., mining computing devices, validating computing devices).)
determining, via a blockchain-based entitlement redemption component, the plurality of parameters of the entitlement stored in the token; (Metnick ¶0214, EI rules, and use parameters. The establishing may include receiving a plurality of exchange items from the EI issuing server 920, where the plurality of exchange items includes the exchange item, and establishing the initial validity of the exchange item with the EI issuing server 920. For example, the set up processing 936 receives EI information 950 and an EI rule set 952 from the EI issuing server 920, where the EI issuing server 920 issues trust information 954 (e.g., a first contract block of the contract blockchain) to the EI trusted module 922 while generating the EI information 950 and the EI rule set 952. Having received the EI information 950 and the EI rule set 952, the set up processing 936 exchanges set up verification 956 with the EI trusted module 922 to validate the EI information 950 and the EI rule set 952. Metnick ¶0299, The method further includes step 1312, where the processing module sends use information regarding the redemption request to a marketplace server of the data communication system. The use information includes a representation of at least some of the information within the redemption request. For example, the use information includes a portion (e.g., particular bit pattern, last four digits, etc.) of a serial number (e.g., exchange item ID) associated with the exchange item. As another example, the use information includes the user computing device ID. As yet a further example, the user information includes a blockchain ID. As still a further example, the use information includes the portion of the serial number, the user computing device ID, and the representation of the public key. See claim 11)
verifying, via the blockchain-based entitlement redemption component, the blockchain wallet of the user, the user identity condition by authenticating the user using the first or third-party identification service, and the location condition using detected location data; and (Metnick ¶0079, When a buyer desires to purchase an exchange item, the mobile application 198 of the buyer's computing device 16 sends a request to buy a selected exchange item to the MP server(s) 18. The server(s) 18 perform the buyer verification 208 functional block to determine whether the buyer is valid (e.g., the user and/or buyer computing device are valid). Metnick ¶0183, A condition of the conditions for the plurality of exchange items further includes one of a range of time, a range of dates, a geographic location, a building address, a list of items, a user tendency profile, and a user loyalty profile. Metnick ¶0269, Having received the buyer use information 976, the use processing 940 validates the buyer use information 976 to produce validated buyer use information. The validating includes one or more of validating the blockchain ledger (i.e., verifying that a signature is valid within the blockchain ledger), accessing the marketplace database 20 to verify that the El has sufficient remaining balance and that the El buyer computing device is associated with ownership of the El, and exchanging use verification 978 with the El trusted module 922 to validate the El (i.e., sufficient remaining balance for the transaction). Metnick ¶0271, The method includes step 1220 where a processing module (e.g., of a marketplace server) receives buyer use information from a buyer computing device, where the buyer use information indicates an item for direct purchase from a particular merchant by redemption of an exchange item) EI) held by the buyer computing device. For example, the buyer computing device obtains a merchant identifier (ID), generates the buyer use information to include one or more of the merchant ID, an identifier of the item, El information, and a blockchain ledger held in a digital wallet in accordance with a secure custody protocol, and transmits the buyer use information to the processing module. Metnick ¶0272, The method continues at step 1222 for the processing module validates the buyer use information. The validating includes one or more of validating the blockchain ledger (i.e., verifying that a signature is valid within the blockchain ledger), accessing the marketplace database to verify that the El has sufficient remaining balance and that the buyer computing devices associated with ownership of the EI, and exchanging use verification with an El trusted module to further validate El (i.e., sufficient remaining balance of the EI). Metnick ¶0288, the processing module indicates the high risk of the unfavorable redemption when the sensor summary information does not correlate to expected sensor information associated with a location of the buyer computing device. Metnick ¶0310, The El use information 949 includes one or more of identity of item for purchase, identity the merchant affiliated with the request, pricing information of the item for purchase, purchasing rules (e.g., El rules, conditions, use options, etc.), and the type of purchase (e.g., a direct purchase without aid of a point-of-sale terminal).
responsive to verifying, via the blockchain-based entitlement redemption component, the identification public identifier of the blockchain wallet, the user identity condition, and the location condition: providing, via the blockchain-based entitlement redemption component, at least a portion of the representation of the entitlement to the application with an instruction to redeem the entitlement to cause the application to execute redeeming the entitlement in real-time in response to the request. (Metnick abstract, The method further includes verifying the signature utilizing the extracted public key and when the signature is verified, authorizing the redemption request. Metnick ¶0305, Having verified the signature, the method further includes step 1320, where the processing module facilitates execution of the redemption request. For example, the processing module generates a secure transactions block to be added to the blockchain. In an example, the secure transactions block includes the exchange item ID, the ID for the item being acquired, the signature of the user computing device, payment information, a hash of a previous block of the blockchain, a hash of a transaction portion of the blockchain, and a nonce value. Metnick ¶0355, One or more functions associated with the methods and/or processes described herein can require data to be manipulated in different ways within overlapping time spans. The human mind is not equipped to perform such different data manipulations independently, contemporaneously, in parallel, and/or on a coordinated basis within a reasonable period of time, such as within a second, a millisecond, microsecond, a real-time basis or other high speed required by the machines that generate the data, receive the data, convey the data, store the data and/or use the data.)
Metnick does not disclose, however Sliwka teaches:
accessing from a blockchain, via the blockchain-based entitlement accessing component, a token associated with the blockchain wallet of the user using a public identifier of the blockchain wallet, (Sliwka ¶0218, In response to receiving the redemption request, the redemption system 404 may provide the token, the public address of the user attempting to redeem the token, and the public key used to digitally sign the token to the ledger management system 104. The ledger management system 104 may then either verify or deny the token/public address combination. The ledger management system 104 may deny the combination if the token is not a valid token and/or the user is not the listed owner of the token. The ledger management system 104 may verify the token/public address combination if the token is deemed valid and the requesting user is deemed to be the owner of the token.)
the blockchain comprising a decentralized ledger maintained by a cryptographic protocol and a consensus mechanism, (Sliwka ¶0004, Blockchain technology has revolutionized digital asset ownership and transactions through decentralized, immutable ledgers. ¶0130, In many implementations of distributed ledger technology, the management and extension of the distributed ledger is decentralized and distributed over computer systems operated by numerous unaffiliated entities who contribute their computing power to the system. ¶0146, In embodiments, the tokenization platform 100 manages one or more cryptographic ledgers (or “distributed ledgers”) and provides flexible functionality of virtual representations of items such as goods, services, and/or experiences with the fulfillment and satisfaction of said items. ¶1016, Techniques described herein solve these and other problems by providing a DRM NFT that may be used to securely store digital assets on cryptographic ledgers (e.g., distributed ledgers, distributed filesystems, etc.) using cryptographic techniques. ¶1064, It is noted that in embodiments, the CoC platform may be implemented using a distributed ledger that uses a proof-of-stake consensus mechanism, such that the environmental impact of such a distributed ledger is much less than counterpart proof-of-work consensus mechanisms. ¶1523, Entities recording transactions, such as in a blockchain, may reach consensus using an algorithm such as proof-of-stake, proof-of-work, and proof-of-storage.
the plurality of parameters comprising a representation of the entitlement, a user identity condition for redeeming the entitlement using a first or third-party identification service, a location condition defining a particular location for redeeming the entitlement and an indication of an application for redeeming the entitlement, the representation of the entitlement indicating a particular benefit for a particular product or service; (Sliwka ¶0158, In some scenarios, the user may be redeeming a token corresponding to a digital item (e.g., a gift card, an mp3, a movie, a digital photograph)… In another scenario, the user may be redeeming a token corresponding to a physical good (e.g., clothing, food, electronics, etc.) or a physical service (e.g., maid service). Sliwka ¶0221, In some embodiments, certain tokens generated by the tokenization platform 100 may include temporal attributes that relate to the redeemability of the token. In these embodiments, the temporal attributes may define when a token becomes redeemable and/or when the token is no longer redeemable. The temporal attributes of a token may be implemented in a number of different ways. For example, in some embodiments the temporal attributes may be included in the mutable or immutable attributes of the token. Sliwka ¶0232, A tokenized token may refer to a non-fungible token that has attributes that define the type of currency and an amount of currency represented by the coin (e.g., an amount of bitcoin, Ethereum, dollars, pounds, or the like). In some of these embodiments, a tokenized token may refer to a non-fungible token that has a set of attributes defining characteristics of such token in addition to having a set of fungible and/or non-fungible tokens representing digital currency balance(s) enclosed within a tokenized token and/or other digital item(s). In addition, tokenized token can contain business rules governing redemption, transfer and other tokenized token lifecycle mechanisms. In some embodiments, the ledger bridging system 416 mints the new token by requesting the generation of a new token by the token generation system 302. The ledger bridging system 416 may provide the type of currency, the amount of currency, and ownership data (e.g., the account to which the new tokenized token will belong) to the token generation system 302. In response, the token generation system 302 generates a tokenized token, for example, in the manner described above. In this way, the token generation system 302 treats the currency as an “item.” In this way, a tokenized token may be exchanged (e.g., for other tokenized tokens or tokenized items), gifted, and/or redeemed. Sliwka ¶0296, At 904, one or more digital tokens are generated. In embodiments, the digital tokens are unique digital tokens. Each unique digital token may include a set of digital attributes that correspond to the set of item attributes. In embodiments, N digital tokens are generated and linked to an item or virtual representation thereof. )
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Metnick’s invention with Sliwka’s teaching. One of ordinary skills in the art would have been motivated to combine these elements because tokens are typical components of blockchain systems. Therefore, it would be obvious to access a token that represent the entitlement in order to obtain data necessary to facilitate the redemption of the entitlement.
The combination of Metnick and Sliwka do not disclose, however Connor teaches:
the token cryptographically computed using the cryptographic protocol based on a plurality of parameters of an entitlement stored in the token (Connor ¶0030, FIG. 2 shows a flow chart illustrating the steps of minting a token commitment on a ZKP-enabled DLN to represent a real world (e.g., off-chain) or physical asset on the ZKP-enabled DLN, according to an embodiment… In some implementations, the sender 110a can generate, using the computing node 102a, an alpha-numeric value that is uniquely associated with some identifying parameters (e.g., serial numbers, model numbers, etc.) of the asset, and the alpha-numeric value can be used as the asset identifier that hides the real identity of the non-fungible physical asset. As another example, a unique asset identifier can be generated by cryptographically hashing the identifying parameters of the non-fungible physical asset to generate an asset token that can serve as the unique asset identifier. ¶0031, In some implementations, the cryptographic hashing computation can include the application of a cryptographic hashing algorithm or function H such as but not limited to the SHA-256 algorithm or function, on the identifying parameters of the non-fungible physical asset. For instance, if the non-fungible physical asset is a vehicle, an asset token to represent the vehicle on the ZKP-enabled DLN 100 can be generated by applying a hashing function (e.g., SHA-256) on one or more of the identifying parameters of the vehicle such as the vehicle identification number, model type, model year, etc. As a non-limiting example, a unique asset identifier or asset token A for a vehicle can be generated by computing A=H(VIN), where VIN is the vehicle identification number of the vehicle and H is a hashing function or algorithm. Accordingly, the asset token can serve as a unique asset identifier without exposing or revealing to other participants of the ZKP-enabled DLN 100 any of the identifying parameters of the asset (e.g., vehicle). ¶0032, At 204, a non-fungible physical asset can be registered or represented on the ZKP-enabled DLN 100 for the first time by generating or minting a non-fungible token commitment that encodes at least some aspects of the non-fungible asset and/or the ownership of the asset on the ZKP-enabled DLN 100. ¶0035, In some embodiments, the minting of a non-fungible token commitment to represent an asset ZKP-enabled DLN 100 for the first time may include the computation of a token commitment Z.sub.s as follows: Z.sub.s=H(A{circle around (*)}Pk.sub.s{circle around (*)}S.sub.s{circle around (*)}CP.sub.A), where A is the asset token identifying the asset (e.g., obtained by hashing, off-chain, at least some identifying parameters of the asset), Pk.sub.s is the public key on the ZKP-enabled DLN 100 that is associated with the sender 110a (i.e., the current and rightful owner of the asset), S.sub.s is a random nonce selected or generated by the computing node 102a of the sender 110a, CPA is the counting parameter for the asset token A (e.g., the number of times a request for recovery has been made for the asset token A and approved by the arbitrator), H is a cryptographic hashing function or algorithm (e.g., SHA-256), and {circle around (*)} represents a combining operator (e.g., the concatenation operator |, etc.))
based on verifying the token by validating that the token was cryptographically computed in accordance with the cryptographic protocol and confirmed by the consensus mechanism (¶0041, Upon receiving the token commitment Z.sub.s, the hash of the asset token H(A), and/or other public parameters, and/or the ZKPs, in some embodiments, the self-executing code or smart contract may verify the ZKPs… In some implementations, the smart contract may verify the ZKPs to verify statements included in the ZKPs, such as the statements that H(A) includes A (i.e., the statement that H(A) is obtained by applying a hashing function or algorithm on the asset token A) and the statement that the token commitment Z.sub.s also includes A (i.e., the statement that Z.sub.s is obtained by applying a hashing function or algorithm on the asset token A). Further, the smart contract may verify that there has never been an H(A) provided to the smart contract previously (e.g., if the asset has never been represented on the ZKP-enabled DLN 100). In addition, the smart contract may also verify that the initial value of CP.sub.A used in calculating Z.sub.s was determined or selected by the pre-determined or pre-approved algorithm.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Metnick and Sliwka with Connor’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to have a unique identifiable token that is derived from a plurality of parameters, thereby improving the ability of the system to uniquely identify the entitlements.
Further, the claimed limitation “for…” in “a request for entitlement redemption”, “for...” in “…for redeeming the entitlement”, “to…” in “an instruction to redeem the entitlement” and “to…” in “to cause the application…” consists of language disclosing an intended result, 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 10, the combination of Metnick, Sliwka and Connor further discloses:
receiving a request for entitlement redemption from a device of the user; using the device of the user to authenticate the public identifier of the blockchain wallet of the user. (Sliwka ¶0218, The redemption system 404 may receive a request to redeem (or “redemption request”) the token. The redemption request may include the token or an identifier of the token (e.g., an alphanumeric string) and may include a public address of the user attempting to redeem the token. In embodiments, the redemption request may further include the public key used to digitally sign the token. In response to receiving the redemption request, the redemption system 404 may provide the token, the public address of the user attempting to redeem the token, and the public key used to digitally sign the token to the ledger management system 104. The ledger management system 104 may then either verify or deny the token/public address combination. The ledger management system 104 may deny the combination if the token is not a valid token and/or the user is not the listed owner of the token. The ledger management system 104 may verify the token/public address combination if the token is deemed valid and the requesting user is deemed to be the owner of the token.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Metnick, Sliwka and Connor with Sliwka’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements as it would be an obvious variation to provide automatic validation and real time redemption of entitlements to improve user experience.
Further, the claimed limitation “for…” in “receiving a request for entitlement redemption from a device of the user” consists of language disclosing an intended result, 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 11, the combination of Metnick, Sliwka and Connor further discloses:
receiving the request for entitlement redemption from the application; and using a device of the user to authenticate the public identifier of the blockchain wallet of the user before transmitting the request by the application. (Sliwka ¶0150, A user device may access the platform 100 via a website, a web application, a native application, or the like. In embodiments, the platform 100 may provide a first graphical user interface to user devices 190 associated with a seller and a second graphical user interface to a user device 190 associated with an end 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. Sliwka ¶0159, 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. If the token and ownership are verified, the platform 100 may transmit a confirmation of the verification to the client application.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Metnick, Sliwka and Connor with Sliwka’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements as it would be an obvious variation to provide automatic validation and improve user experience.
Further, the claimed limitation “for…” in “receiving the request for entitlement redemption…” and “to…” in “using a device of the user to authenticate the identification” consists of language disclosing an intended result, 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 claims 13-14, the combination of Metnick, Sliwka and Connor further discloses:
verifying via the blockchain-based entitlement redemption component, a timeframe condition for redeeming the entitlement before causing the application to execute redeeming the entitlement, and (Metnick ¶0163 The method continues to step 904 when the EI rule has not been changed where the processing module determines whether the EI rule has expired (e.g., detecting that an active timeframe associated with the EI rule has elapsed). The method loops back to step 890 when the EI rule has not expired. Metnick ¶0183, A condition of the conditions for the plurality of exchange items further includes one of a range of time, a range of dates, a geographic location, a building address, a list of items, a user tendency profile, and a user loyalty profile. For example, the marketplace server 18 obtains the condition from a corresponding condition source. Metnick ¶0271, The method includes step 1220 where a processing module (e.g., of a marketplace server) receives buyer use information from a buyer computing device, where the buyer use information indicates an item for direct purchase from a particular merchant by redemption of an exchange item) EI) held by the buyer computing device. For example, the buyer computing device obtains a merchant identifier (ID), generates the buyer use information to include one or more of the merchant ID, an identifier of the item, EI information, and a blockchain ledger held in a digital wallet in accordance with a secure custody protocol, and transmits the buyer use information to the processing module. Metnick ¶0272, The method continues at step 1222 for the processing module validates the buyer use information. The validating includes one or more of validating the blockchain ledger (i.e., verifying that a signature is valid within the blockchain ledger), accessing the marketplace database to verify that the EI has sufficient remaining balance and that the buyer computing devices associated with ownership of the EI, and exchanging use verification with an EI trusted module to further validate EI (i.e., sufficient remaining balance of the EI). Metnick ¶0310, The EI use information 949 includes one or more of identity of item for purchase, identity the merchant affiliated with the request, pricing information of the item for purchase, purchasing rules (e.g., EI rules, conditions, use options, etc.), and the type of purchase (e.g., a direct purchase without aid of a point-of-sale terminal). Purchasing rules are allowable values or ranges of values of parameters associated with an exchange item as a function of one or more conditions and of one or more use options. For example, a parent may purchase a digital exchange item (e.g., a gift card) for a child that can be used at a local coffee shop. During the purchase, the parent established a purchasing rule such that the exchange item can only be used on food and/or that a certain balance must be maintained on the exchange item.)
While Metnick does not explicitly state that a timeframe condition is verified, Metnick discloses that the EI information is verified. It also states that EI information includes conditions which encompass date ranges and range of time. Therefore, by verifying EI information, Metnick inherently verifies the timeframe condition contained within the EI information.
receiving data from a device of the user to verify the user identity condition, the location condition, and the timeframe condition (Metnick ¶0179, In an example of operation of the use of the EI, the EI buyer computing device 926 obtains EI info from the digital wallet 944 to issue buyer use information 976 to the marketplace server 18 when desiring to utilize the exchange item (e.g., EI serial number 005) with a merchant associated with the merchant server 924 for purchase of goods and/or services. Metnick ¶0268, In an example of operation of the redeeming of the exchange item, when the EI buyer computing device 926 initiates redemption of an exchange item (EI) held in the digital wallet 944, the use processing 940 receives buyer use information 976, where the buyer use information 976 indicates an item for direct purchase from a particular merchant utilizing the EI without aid of a point-of-sale terminal.)
Further, the claimed limitation “for…” in “…a timeframe condition for redeeming the entitlement…”, “causing…” in “…causing the application to execute redeeming the entitlement” and “to…” in “receiving data from a device of the user to verify the user identity condition, the location condition, and the timeframe condition” consists of language disclosing an intended result, 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 15, the combination of Metnick, Sliwka and Connor further discloses:
the application communicates with hardware associated with the application in order to execute redeeming the entitlement. (Metnick ¶0277, For example, the EI buyer computing device 926 sends buyer use information 976, via the POS equipment 32, to the merchant server 924 in accordance with the one or more promotions. Metnick ¶0292, When the EI buyer computing device 926 initiates redemption of the EI, the use processing 940 receives merchant use information 1274 from the merchant server 924, where the merchant server receives buyer use information 1272 from the EI buyer computing device 926 via the POS equipment 32, where the buyer use information 1272 includes a signature from the EI buyer computing device, and where the EI buyer computing device 926 generates the signature utilizing a private key of a public/private key pair where the public key is included in the blockchain ledger. Metnick ¶0296, The method continues at step 1284 where the processing module issues authorization information to the POS equipment, where the authorization information is based on verification of the representation of the security aspect with regards to the security aspect. The issuing includes one or more of verifying the received computing device signature utilizing at least one of a public key extracted from the received blockchain ledger and a public key extracted from a copy of the blockchain ledger retrieved from the marketplace database; generating the further merchant use information and sending the further merchant use information to the merchant server, where at least one of the POS equipment and the merchant server may perform a further authorization of the redemption, where the further authorization includes at least one of interpreting a received marketplace server authorization information and verifying the received computing device signature utilizing the public key extracted from the received blockchain ledger.)
Further, the claimed limitation “to…” in “the application in order to execute redeeming the entitlement” consists of language disclosing an intended result, 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 16, Metnick discloses:
receiving, via a blockchain-based entitlement accessing component, a request for entitlement redemption, the request comprising an public identifier of a blockchain wallet of a user; (Metnick abstract, A method for execution by a point of sale device includes receiving a redemption request from a user computing device, the redemption request including a signature generated utilizing a private key of a public/private key pair associated with the user computing device. Metnick ¶0298, The redemption request includes one or more of a user computing device identifier associated with the user computing device, a representation of a public key of a public/private key pair associated with the user computing device, an identifier of an exchange item, a signature generated utilizing a private key of the public/private key pair, a copy of a blockchain associated with the exchange item, and an identifier of an item to acquire utilizing the exchange item. The copy of the blockchain is stored in a digital wallet of the user computing device and includes the representation of the public key and the blockchain is stored in one or more of a marketplace database of the data communication system, and a plurality of computing devices (e.g., mining computing devices, validating computing devices).)
authenticating, via an authentication component, the public identifier of the blockchain wallet of the user using a device of the user; (Metnick ¶0272, The method continues at step 1222 for the processing module validates the buyer use information. The validating includes one or more of validating the blockchain ledger (i.e., verifying that a signature is valid within the blockchain ledger), accessing the marketplace database to verify that the EI has sufficient remaining balance and that the buyer computing devices associated with ownership of the EI, and exchanging use verification with an EI trusted module to further validate EI (i.e., sufficient remaining balance of the EI).)
determining, via a blockchain-based entitlement redemption component, the plurality of parameters of the entitlement stored in the token, (Metnick ¶0214, EI rules, and use parameters. The establishing may include receiving a plurality of exchange items from the EI issuing server 920, where the plurality of exchange items includes the exchange item, and establishing the initial validity of the exchange item with the EI issuing server 920. For example, the set up processing 936 receives EI information 950 and an EI rule set 952 from the EI issuing server 920, where the EI issuing server 920 issues trust information 954 (e.g., a first contract block of the contract blockchain) to the EI trusted module 922 while generating the EI information 950 and the EI rule set 952. Having received the EI information 950 and the EI rule set 952, the set up processing 936 exchanges set up verification 956 with the EI trusted module 922 to validate the EI information 950 and the EI rule set 952. Metnick ¶0299, The method further includes step 1312, where the processing module sends use information regarding the redemption request to a marketplace server of the data communication system. The use information includes a representation of at least some of the information within the redemption request. For example, the use information includes a portion (e.g., particular bit pattern, last four digits, etc.) of a serial number (e.g., exchange item ID) associated with the exchange item. As another example, the use information includes the user computing device ID. As yet a further example, the user information includes a blockchain ID. As still a further example, the use information includes the portion of the serial number, the user computing device ID, and the representation of the public key. See claim 11)
verifying, via the blockchain-based entitlement redemption component, the user identity condition by authenticating the user using an identity verification application the first or third- party identification service and the location condition using detected location data; and (Metnick ¶0079, When a buyer desires to purchase an exchange item, the mobile application 198 of the buyer's computing device 16 sends a request to buy a selected exchange item to the MP server(s) 18. The server(s) 18 perform the buyer verification 208 functional block to determine whether the buyer is valid (e.g., the user and/or buyer computing device are valid). Metnick ¶0183, A condition of the conditions for the plurality of exchange items further includes one of a range of time, a range of dates, a geographic location, a building address, a list of items, a user tendency profile, and a user loyalty profile. Metnick ¶0269, Having received the buyer use information 976, the use processing 940 validates the buyer use information 976 to produce validated buyer use information. The validating includes one or more of validating the blockchain ledger (i.e., verifying that a signature is valid within the blockchain ledger), accessing the marketplace database 20 to verify that the El has sufficient remaining balance and that the El buyer computing device is associated with ownership of the El, and exchanging use verification 978 with the El trusted module 922 to validate the El (i.e., sufficient remaining balance for the transaction). Metnick ¶0271, The method includes step 1220 where a processing module (e.g., of a marketplace server) receives buyer use information from a buyer computing device, where the buyer use information indicates an item for direct purchase from a particular merchant by redemption of an exchange item) EI) held by the buyer computing device. For example, the buyer computing device obtains a merchant identifier (ID), generates the buyer use information to include one or more of the merchant ID, an identifier of the item, El information, and a blockchain ledger held in a digital wallet in accordance with a secure custody protocol, and transmits the buyer use information to the processing module. Metnick ¶0272, The method continues at step 1222 for the processing module validates the buyer use information. The validating includes one or more of validating the blockchain ledger (i.e., verifying that a signature is valid within the blockchain ledger), accessing the marketplace database to verify that the El has sufficient remaining balance and that the buyer computing devices associated with ownership of the EI, and exchanging use verification with an El trusted module to further validate El (i.e., sufficient remaining balance of the EI). Metnick ¶0288, the processing module indicates the high risk of the unfavorable redemption when the sensor summary information does not correlate to expected sensor information associated with a location of the buyer computing device. Metnick ¶0310, The El use information 949 includes one or more of identity of item for purchase, identity the merchant affiliated with the request, pricing information of the item for purchase, purchasing rules (e.g., El rules, conditions, use options, etc.), and the type of purchase (e.g., a direct purchase without aid of a point-of-sale terminal).
based on verifying the user identity condition and the location condition, providing, via the blockchain-based entitlement redemption component, the representation of the entitlement to the application with an instruction to redeem the entitlement to cause the application to execute redeeming the entitlement in real-time in response to the request. (Metnick abstract, The method further includes verifying the signature utilizing the extracted public key and when the signature is verified, authorizing the redemption request. Metnick ¶0305, Having verified the signature, the method further includes step 1320, where the processing module facilitates execution of the redemption request. For example, the processing module generates a secure transactions block to be added to the blockchain. In an example, the secure transactions block includes the exchange item ID, the ID for the item being acquired, the signature of the user computing device, payment information, a hash of a previous block of the blockchain, a hash of a transaction portion of the blockchain, and a nonce value. Metnick ¶0355, One or more functions associated with the methods and/or processes described herein can require data to be manipulated in different ways within overlapping time spans. The human mind is not equipped to perform such different data manipulations independently, contemporaneously, in parallel, and/or on a coordinated basis within a reasonable period of time, such as within a second, a millisecond, microsecond, a real-time basis or other high speed required by the machines that generate the data, receive the data, convey the data, store the data and/or use the data.)
Metnick further discloses:
a processor; and a non-transitory computer-readable medium having stored thereon instructions that when executed by the processor, cause the processor to perform operations including: (Metnick ¶0148, The method described above in conjunction with one or more of the processing module, the seller device, the marketplace server, the buyer device, the merchant server, the second merchant server, can alternatively be performed by other modules of the exchange item marketplace network or by other devices. In addition, at least one memory section (e.g., a non-transitory computer readable storage medium, a computer readable memory) that stores operational instructions can, when executed by one or more processing modules of one or more computing devices of the exchange item marketplace network, cause the one or more computing devices to perform any or all of the method steps described above.)
Metnick does not disclose, however Sliwka teaches:
accessing from a blockchain, via the blockchain-based entitlement accessing component, a token associated with the blockchain wallet of the user after authentication of the public identifier of the blockchain wallet, (Sliwka ¶0218, In response to receiving the redemption request, the redemption system 404 may provide the token, the public address of the user attempting to redeem the token, and the public key used to digitally sign the token to the ledger management system 104. The ledger management system 104 may then either verify or deny the token/public address combination. The ledger management system 104 may deny the combination if the token is not a valid token and/or the user is not the listed owner of the token. The ledger management system 104 may verify the token/public address combination if the token is deemed valid and the requesting user is deemed to be the owner of the token.)
the blockchain comprising a decentralized ledger maintained by a cryptographic protocol and a consensus mechanism, (Sliwka ¶0004, Blockchain technology has revolutionized digital asset ownership and transactions through decentralized, immutable ledgers. ¶0130, In many implementations of distributed ledger technology, the management and extension of the distributed ledger is decentralized and distributed over computer systems operated by numerous unaffiliated entities who contribute their computing power to the system. ¶0146, In embodiments, the tokenization platform 100 manages one or more cryptographic ledgers (or “distributed ledgers”) and provides flexible functionality of virtual representations of items such as goods, services, and/or experiences with the fulfillment and satisfaction of said items. ¶1016, Techniques described herein solve these and other problems by providing a DRM NFT that may be used to securely store digital assets on cryptographic ledgers (e.g., distributed ledgers, distributed filesystems, etc.) using cryptographic techniques. ¶1064, It is noted that in embodiments, the CoC platform may be implemented using a distributed ledger that uses a proof-of-stake consensus mechanism, such that the environmental impact of such a distributed ledger is much less than counterpart proof-of-work consensus mechanisms. ¶1523, Entities recording transactions, such as in a blockchain, may reach consensus using an algorithm such as proof-of-stake, proof-of-work, and proof-of-storage.)
the plurality of parameters comprising a representation of the entitlement, a user identity condition for redeeming the entitlement using a first or third-party identification service, a location condition defining a particular location for redeeming the entitlement and an indication of an application for redeeming the entitlement, the representation of the entitlement indicating a particular benefit for a particular product or service; (Sliwka ¶0158, In some scenarios, the user may be redeeming a token corresponding to a digital item (e.g., a gift card, an mp3, a movie, a digital photograph)… In another scenario, the user may be redeeming a token corresponding to a physical good (e.g., clothing, food, electronics, etc.) or a physical service (e.g., maid service). Sliwka ¶0221, In some embodiments, certain tokens generated by the tokenization platform 100 may include temporal attributes that relate to the redeemability of the token. In these embodiments, the temporal attributes may define when a token becomes redeemable and/or when the token is no longer redeemable. The temporal attributes of a token may be implemented in a number of different ways. For example, in some embodiments the temporal attributes may be included in the mutable or immutable attributes of the token. Sliwka ¶0232, A tokenized token may refer to a non-fungible token that has attributes that define the type of currency and an amount of currency represented by the coin (e.g., an amount of bitcoin, Ethereum, dollars, pounds, or the like). In some of these embodiments, a tokenized token may refer to a non-fungible token that has a set of attributes defining characteristics of such token in addition to having a set of fungible and/or non-fungible tokens representing digital currency balance(s) enclosed within a tokenized token and/or other digital item(s). In addition, tokenized token can contain business rules governing redemption, transfer and other tokenized token lifecycle mechanisms. In some embodiments, the ledger bridging system 416 mints the new token by requesting the generation of a new token by the token generation system 302. The ledger bridging system 416 may provide the type of currency, the amount of currency, and ownership data (e.g., the account to which the new tokenized token will belong) to the token generation system 302. In response, the token generation system 302 generates a tokenized token, for example, in the manner described above. In this way, the token generation system 302 treats the currency as an “item.” In this way, a tokenized token may be exchanged (e.g., for other tokenized tokens or tokenized items), gifted, and/or redeemed. Sliwka ¶0296, At 904, one or more digital tokens are generated. In embodiments, the digital tokens are unique digital tokens. Each unique digital token may include a set of digital attributes that correspond to the set of item attributes. In embodiments, N digital tokens are generated and linked to an item or virtual representation thereof.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Metnick’s invention with Sliwka’s teaching. One of ordinary skills in the art would have been motivated to combine these elements because tokens are typical components of blockchain systems. Therefore it would be obvious to access a token that represent the entitlement in order to obtain data necessary to facilitate the redemption of the entitlement.
The combination of Metnick and Sliwka do not disclose, however Connor teaches:
the token cryptographically computed using the cryptographic protocol based on a plurality of parameters of an entitlement stored in the token(Connor ¶0030, FIG. 2 shows a flow chart illustrating the steps of minting a token commitment on a ZKP-enabled DLN to represent a real world (e.g., off-chain) or physical asset on the ZKP-enabled DLN, according to an embodiment… In some implementations, the sender 110a can generate, using the computing node 102a, an alpha-numeric value that is uniquely associated with some identifying parameters (e.g., serial numbers, model numbers, etc.) of the asset, and the alpha-numeric value can be used as the asset identifier that hides the real identity of the non-fungible physical asset. As another example, a unique asset identifier can be generated by cryptographically hashing the identifying parameters of the non-fungible physical asset to generate an asset token that can serve as the unique asset identifier. ¶0031, In some implementations, the cryptographic hashing computation can include the application of a cryptographic hashing algorithm or function H such as but not limited to the SHA-256 algorithm or function, on the identifying parameters of the non-fungible physical asset. For instance, if the non-fungible physical asset is a vehicle, an asset token to represent the vehicle on the ZKP-enabled DLN 100 can be generated by applying a hashing function (e.g., SHA-256) on one or more of the identifying parameters of the vehicle such as the vehicle identification number, model type, model year, etc. As a non-limiting example, a unique asset identifier or asset token A for a vehicle can be generated by computing A=H(VIN), where VIN is the vehicle identification number of the vehicle and H is a hashing function or algorithm. Accordingly, the asset token can serve as a unique asset identifier without exposing or revealing to other participants of the ZKP-enabled DLN 100 any of the identifying parameters of the asset (e.g., vehicle). ¶0032, At 204, a non-fungible physical asset can be registered or represented on the ZKP-enabled DLN 100 for the first time by generating or minting a non-fungible token commitment that encodes at least some aspects of the non-fungible asset and/or the ownership of the asset on the ZKP-enabled DLN 100. ¶0035, In some embodiments, the minting of a non-fungible token commitment to represent an asset ZKP-enabled DLN 100 for the first time may include the computation of a token commitment Z.sub.s as follows: Z.sub.s=H(A{circle around (*)}Pk.sub.s{circle around (*)}S.sub.s{circle around (*)}CP.sub.A), where A is the asset token identifying the asset (e.g., obtained by hashing, off-chain, at least some identifying parameters of the asset), Pk.sub.s is the public key on the ZKP-enabled DLN 100 that is associated with the sender 110a (i.e., the current and rightful owner of the asset), S.sub.s is a random nonce selected or generated by the computing node 102a of the sender 110a, CPA is the counting parameter for the asset token A (e.g., the number of times a request for recovery has been made for the asset token A and approved by the arbitrator), H is a cryptographic hashing function or algorithm (e.g., SHA-256), and {circle around (*)} represents a combining operator (e.g., the concatenation operator |, etc.))
based on verifying the token by validating that the token was cryptographically computed in accordance with the cryptographic protocol and confirmed by the consensus mechanism, (¶0041, Upon receiving the token commitment Z.sub.s, the hash of the asset token H(A), and/or other public parameters, and/or the ZKPs, in some embodiments, the self-executing code or smart contract may verify the ZKPs… In some implementations, the smart contract may verify the ZKPs to verify statements included in the ZKPs, such as the statements that H(A) includes A (i.e., the statement that H(A) is obtained by applying a hashing function or algorithm on the asset token A) and the statement that the token commitment Z.sub.s also includes A (i.e., the statement that Z.sub.s is obtained by applying a hashing function or algorithm on the asset token A). Further, the smart contract may verify that there has never been an H(A) provided to the smart contract previously (e.g., if the asset has never been represented on the ZKP-enabled DLN 100). In addition, the smart contract may also verify that the initial value of CP.sub.A used in calculating Z.sub.s was determined or selected by the pre-determined or pre-approved algorithm.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Metnick and Sliwka with Connor’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to have a unique identifiable token that is derived from a plurality of parameters, thereby improving the ability of the system to uniquely identify the entitlements.
Further, the claimed limitation “for…” in “a request for entitlement redemption”, “for...” in “…for redeeming the entitlement”, “to…” in “an instruction to redeem the entitlement” and “to…” in “to cause the application…” consists of language disclosing an intended result, 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 17, the combination of Metnick, Sliwka and Connor further discloses:
the request is received from at least one of the device of the user or a corresponding device executing the application (Metnick abstract, A method for execution by a point of sale device includes receiving a redemption request from a user computing device, the redemption request including a signature generated utilizing a private key of a public/private key pair associated with the user computing device.)
Regarding claims 18-19, the combination of Metnick, Sliwka and Connor further discloses:
verifying via the blockchain-based entitlement redemption component, a timeframe condition for redeeming the entitlement before causing the application to execute redeeming the entitlement, and (Metnick ¶0163 The method continues to step 904 when the EI rule has not been changed where the processing module determines whether the EI rule has expired (e.g., detecting that an active timeframe associated with the EI rule has elapsed). The method loops back to step 890 when the EI rule has not expired. Metnick ¶0183, A condition of the conditions for the plurality of exchange items further includes one of a range of time, a range of dates, a geographic location, a building address, a list of items, a user tendency profile, and a user loyalty profile. For example, the marketplace server 18 obtains the condition from a corresponding condition source. Metnick ¶0271, The method includes step 1220 where a processing module (e.g., of a marketplace server) receives buyer use information from a buyer computing device, where the buyer use information indicates an item for direct purchase from a particular merchant by redemption of an exchange item) EI) held by the buyer computing device. For example, the buyer computing device obtains a merchant identifier (ID), generates the buyer use information to include one or more of the merchant ID, an identifier of the item, EI information, and a blockchain ledger held in a digital wallet in accordance with a secure custody protocol, and transmits the buyer use information to the processing module. Metnick ¶0272, The method continues at step 1222 for the processing module validates the buyer use information. The validating includes one or more of validating the blockchain ledger (i.e., verifying that a signature is valid within the blockchain ledger), accessing the marketplace database to verify that the EI has sufficient remaining balance and that the buyer computing devices associated with ownership of the EI, and exchanging use verification with an EI trusted module to further validate EI (i.e., sufficient remaining balance of the EI). Metnick ¶0310, The EI use information 949 includes one or more of identity of item for purchase, identity the merchant affiliated with the request, pricing information of the item for purchase, purchasing rules (e.g., EI rules, conditions, use options, etc.), and the type of purchase (e.g., a direct purchase without aid of a point-of-sale terminal). Purchasing rules are allowable values or ranges of values of parameters associated with an exchange item as a function of one or more conditions and of one or more use options. For example, a parent may purchase a digital exchange item (e.g., a gift card) for a child that can be used at a local coffee shop. During the purchase, the parent established a purchasing rule such that the exchange item can only be used on food and/or that a certain balance must be maintained on the exchange item.)
While Metnick does not explicitly state that a timeframe condition is verified, Metnick discloses that the EI information is verified. It also states that EI information includes conditions which encompass date ranges and range of time. Therefore, by verifying EI information, Metnick inherently verifies the timeframe condition contained within the EI information.
receiving data from a device of the user to verify the user identity condition, the location condition, and the timeframe condition (Metnick ¶0179, In an example of operation of the use of the EI, the EI buyer computing device 926 obtains EI info from the digital wallet 944 to issue buyer use information 976 to the marketplace server 18 when desiring to utilize the exchange item (e.g., EI serial number 005) with a merchant associated with the merchant server 924 for purchase of goods and/or services. Metnick ¶0268, In an example of operation of the redeeming of the exchange item, when the EI buyer computing device 926 initiates redemption of an exchange item (EI) held in the digital wallet 944, the use processing 940 receives buyer use information 976, where the buyer use information 976 indicates an item for direct purchase from a particular merchant utilizing the EI without aid of a point-of-sale terminal.)
Further, the claimed limitation “for…” in “…a timeframe condition for redeeming the entitlement…”, “causing…” in “…causing the application to execute redeeming the entitlement” and “to…” in “receiving data from a device of the user to verify the user identity condition, the location condition, and the timeframe condition” consists of language disclosing an intended result, 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 20, the combination of Metnick, Sliwka and Connor further discloses:
the application communicates with hardware associated with the application in order to execute redeeming the entitlement. (Metnick ¶0277, For example, the EI buyer computing device 926 sends buyer use information 976, via the POS equipment 32, to the merchant server 924 in accordance with the one or more promotions. Metnick ¶0292, When the EI buyer computing device 926 initiates redemption of the EI, the use processing 940 receives merchant use information 1274 from the merchant server 924, where the merchant server receives buyer use information 1272 from the EI buyer computing device 926 via the POS equipment 32, where the buyer use information 1272 includes a signature from the EI buyer computing device, and where the EI buyer computing device 926 generates the signature utilizing a private key of a public/private key pair where the public key is included in the blockchain ledger. Metnick ¶0296, The method continues at step 1284 where the processing module issues authorization information to the POS equipment, where the authorization information is based on verification of the representation of the security aspect with regards to the security aspect. The issuing includes one or more of verifying the received computing device signature utilizing at least one of a public key extracted from the received blockchain ledger and a public key extracted from a copy of the blockchain ledger retrieved from the marketplace database; generating the further merchant use information and sending the further merchant use information to the merchant server, where at least one of the POS equipment and the merchant server may perform a further authorization of the redemption, where the further authorization includes at least one of interpreting a received marketplace server authorization information and verifying the received computing device signature utilizing the public key extracted from the received blockchain ledger.)
Further, the claimed limitation “to…” in “the application in order to execute redeeming the entitlement” consists of language disclosing an intended result, 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.
Response to Arguments
Claim Interpretation
The applicant argues that “there is no support in the MPEP for the argument that the features above are non-functional material that do not move to distinguish over prior art and can therefore be ignored.” or that “there is no support in MPEP 2111 or MPEP 2114 for the argument that the features above consist of language disclosing an intended use/result, so they are considered but given no patentable weight.”. The applicant further asserts that “Under MPEP 2143.03, "Examiners must consider all claim limitations when determining patentability of an invention over the prior art."” The examiner respectfully disagrees. The examiner has considered all the limitations of the claim in accordance with MPEP 2143.03. However, in evaluating patentability over prior art, it is proper to evaluate whether the claim language merely recites an intended use or result or non-functional descriptive material, as set forth in the final rejection. Under MPEP 2111, claims are interpreted using the broadest reasonable interpretation in light of the specifications. When doing so, the identified language merely describes a result or purpose of the recited component or step. Furthermore, MPEP 2114 explains that apparatus and method claims are evaluated based on the structure or steps, rather than the intended use or result of the structure or step. In the limitations in question, the identified claim features merely recite informational content, intended use or desired results associated with the previously recited element and do not impose additional structural or functional limitations on the claimed invention.
Claim Rejections – 35 U.S.C. § 101
The applicant presents several assertions, i.e., “the claim elements do not recite an abstract idea”, “each claim as a whole integrates any purported judicial exception into a practical application because each claim as a whole is directed to a particular improvement to a technology/technical field”, and “each of Applicant's claims as a whole recites a combination of elements that provide an inventive concept”. The basis for these assertions are found on pages 14-25 of the applicants remarks.
Regarding the applicant assertion that “the claims do not recite an abstract idea” because they do not fall under one of the enumerated groups of abstract ideas (i.e. (1) fundamental economic principles or practices (including hedging, insurance, mitigating risk); (2) commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations); or (3) managing personal behavior or relationships or interactions between people, (including social activities, teaching, and following rules or instructions)”, and further compared the claims with those in USPTO examples 37 and 39 asserting that the presented claims do not recite a methods of organizing human activity. The examiner respectfully disagrees. While fundamental economic principles or practices might not be the best category for the claims as previously categorized on the final office action, the claims still remain directed towards commercial or legal interactions. Specifically, the claims are directed to redeeming an entitlement by receiving a redemption request, accessing a token associated with the user wallet, verifying the token was cryptographically computed, determining parameters associated with the entitlement stored in the token, verifying the conditions for redemption including user identity and location conditions, and authorizing the redemption of the entitlement upon successful verification. These steps mirror traditional commercial interactions such managing and authorizing the redemption of an entitlement for a product or service based on satisfaction of specified conditions (i.e. redeeming a coupon, validating a ticket, using a digital voucher, etc.). As per MPEP 2106.04(a), in step 2A prong one to determine whether a claim recites an abstract idea, the specific limitations in the claim under examination must be identified and analyzed to determine whether they fall within at least one of the recognize groupings of abstract ideas. If one of the limitations in the examined claim falls within one of the groups, it is reasonable to conclude that the claims recite an abstract idea and the examination continues to step 2A prong two.
Further, regarding the applicants assertion that “each claim as a whole integrates any purported judicial exception into a practical application because each claim as a whole is directed to a particular improvement to a technology/technical field”. The applicant further asserts that the claims improve computer technology by enabling efficient redemption of blockchain-based entitlements and reducing computational resources such as memory and network bandwidth as well as solving the problem of current conventional systems requiring manual analysis. The examiner is not persuaded by these assertions. Under step 2A prong two test, the claims must apply the judicial exception by improving the functioning of the computer or other technology. The present claims do not recite such improvement. As mentioned above, the claims recited the steps of “receiving a redemption request, accessing a token associated with the user wallet, determining parameters associated with the entitlement stored in the token, verifying the conditions for redemption including user identity and location conditions, and authorizing the redemption of the entitlement upon successful verification” which implement the abstract idea of commercial or legal interactions. The additional elements of a blockchain-based entitlement redemption component, an identity verification application, a blockchain-based entitlement accessing component, a blockchain wallet, a blockchain, a device, an authentication component, and an application are recited at a higher level of generality. The claim does not recite any specific improvement to blockchain technology, or network architecture. Instead, these elements are used to implement the underlining abstract idea. Further, the applicant comparison to manual process is not persuasive. Automating a process that could otherwise be performed manually using genetic computing components do not integrate the abstract ide into a practical application. Therefore, the claim does not recite any technological advancement or inventive integration beyond applying these tools to an abstract concept and thus fail to impose any meaningful limit that would transform the abstract idea into a practical application under the second prong of step 2A of the subject matter eligibility framework.
Finally, regarding the applicant’s assertion that “each of Applicant's claims as a whole recites a combination of elements that provide an inventive concept "in a non-conventional and non-generic way" to automate the redemption of customized blockchain-based entitlements”, the examiner also disagrees. The applicant further argues that inventive concept can be found in the non-conventional and non-generic arrangement of known, conventional pieces in the presented claims. However the rejection under 35 U.S.C. 101 was not based on the determination that the recited steps are routine or conventional. Rather, the claims are directed to an abstract idea and do not recite additional elements that integrate the abstract idea into a practical application. Therefore, whether the claimed steps are routine or unconventional does not overcome the rejection. Even assuming, arguendo, that the steps are not routine or conventional, the claim still recites the abstract idea implemented using generic computer components and do not amount to significantly more than the underlining abstract idea.
As such the claims remain within an abstract idea and rejection is maintained based on the
newly amended claims.
Claim Rejections – 35 U.S.C. § 103
Applicant’s arguments with respect to claim rejections under 35 U.S.C. § 103 have been considered but are moot because the new ground of rejection.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 8332290 B1 to Venturo et al. discloses: A method includes receiving, at a computing system, information regarding a transaction associated with a financial account of a customer. The method also includes determining, based at least in part on the information regarding the transaction, whether to provide a redemption alert to the customer. The method also includes providing the redemption alert to a mobile device of the customer if it is determined that the redemption alert is to be provided. The method further includes receiving a response to the redemption alert from the mobile device of the customer, where the response indicates whether at least a portion of accumulated loyalty rewards of the customer are to be used to pay for at least a portion of the transaction.
US 20240013199 A1 to Marshall et al. discloses: Methods and systems for blockchain token-based access control in which an access control rule sets an access condition that is satisfied if a wallet address holds one or more specified non-fungible tokens or tokens having specified attributes. To conduct in-person or on-location token-based gating, the system may employ pre-authentication of a wallet address. An identifier may be stored securely on both the system and a user device following pre-authentication. When seeking access, a user device provides identification data generated based on the identifier and the system verifies that the identification data was generated based on the identifier and, on that basis, retrieves a pre-authenticated wallet address. It then verifies using blockchain data that the wallet address holds the requisite token or tokens to satisfy the access condition.
US 20170286987 A1 to Carter et al. discloses: Methods and systems are disclosed for real-time calculation of rewards associated with a commercial transaction. A real-time calculation of rewards can be associated with card payment transactions occurring on a payment account. In an aspect, a customer swiping their bank card at a merchant point of sale to initiate an authorization for a purchase can trigger notification and deliver of rewards associated with the pending commercial transaction.
US 20220351192 A1 to McGregor et al. discloses: A method for execution by a computing device includes acquiring ownership of an exchange item associated with exchange item information. The method further includes receiving, from a marketplace server, exchange item security parameters associated with the exchange item. The method further includes determining to redeem at least a portion of the exchange item and generating dynamic exchange item information based on the exchange item security parameters. The method further includes determining a security code for the redeeming the exchange item based on the dynamic exchange item information. The method further includes sending a redemption request to the marketplace server and receiving a redemption response regarding the redeeming the exchange item that includes an indication of a verification process result performed by the marketplace server to verify the security code. When the redemption response is favorable, the method includes utilizing the exchange item in accordance with the redemption response.
US 20190325473 A1 to Swamidurai discloses: A system and method for the redemption of reward points for cryptocurrency is disclosed. The system may allow transaction account holders to redeem earned reward points for a selected cryptocurrency. The transaction account holders may establish a blockchain wallet to maintain and track the cryptocurrency. The system may interact with an exchange API of a cryptocurrency exchange platform to purchase the cryptocurrency for a blockchain wallet address associated with the blockchain wallet, or to initiate a transfer of pre-purchased cryptocurrency to the blockchain wallet. The system may provide additional authentication measures to ensure that the transaction is initiated by the transaction account holder and that the transaction account holder understands the potential risks of investing in cryptocurrencies.
US 20220051279 A1 to Czajka, II et el. discloses: A method includes receiving, from a user device, a request for a discount; identifying first vendors for providing first discounts responsive to the request; transmitting, to the user device, a first list of discounts; and receiving, from the user device, a second request to associate a selected matching discount with a user. The first vendors include a first vendor, a second vendor, and remaining vendors. The first vendor offers a first maximum discount that is a highest discount amongst the first vendors and the second vendor offers a second maximum discount that is a second highest discount amongst the first vendors after the first vendor. The first list of discounts includes a first discount, from the first vendor, that is higher than the second maximum discount of the second vendor by a first increment; and a second discount, from the second vendor, that corresponds to the second maximum discount.
US 20230297345 A1 to Khalfan et. Al discloses: According to one implementation, a system includes a hardware processor and a memory storing software code. The hardware processor executes the software code to receive ownership data identifying a unique digital identifier conferring ownership, by a user, of an asset awarded by a first entity, confirm, using the unique digital identifier, ownership of the asset by the user, and verify, using the unique digital identifier, that a second entity is an authorized asset redemption partner of the first entity. The hardware processor further executes the software code to enable, using the unique digital identifier and in response to confirming and verifying, the user to redeem the asset awarded by the first entity from the second entity via transfer from a first digital wallet linked to the first entity to a second digital wallet linked to the second entity, either automatically or in response to an authentication performed by the user.
US 20230360329 A1 to Esquivel et al. discloses: In some implementations, the disclosed systems and methods display content from a public network (e.g., the Internet) such as via a web host, content delivery network, etc. In some implementations, the disclosed systems and methods can issue an entitlement as a token, signed with a private key by an issuing authority. In some implementations, the disclosed systems and methods can determine caloric consumption attributable to both upper and lower body movements of the user throughout changes in pose.
US 20170289223 A1 to Kipp et al. discloses: Methods and systems for managing content are disclosed . As an example , a plurality of content fragment of a content asset may be generated and a plurality of time stamps may be associated with each of the plurality of fragments . A first time stamp may indicate a time a respective one of the plurality of fragments was generated and a second time stamp may represent an event time associated with one or more events of the network . As such , at least a portion of the plurality of content fragments may be transmitted to each of a plurality of content packagers , wherein at least the second time stamp associated with each of the plurality of fragments facilitates the alignment of the plurality of content packagers with each other.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/J.L./Examiner, Art Unit 3698 /STEVEN S KIM/Primary Examiner, Art Unit 3698