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 .
Priority
2. Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Status of the Claims
This is a non-final rejection prepared in response to U.S. Patent Application 19/197,092 filed on
May 02, 2025.
Claims 1-20 are pending.
Continuation
This application is a continuation application of U.S. application no. 16/077,999 filed on August 14, 2018, now US Patent 11,308,486 ("Parent Application”). See MPEP §201.07. In accordance with
MPEP §609.02 A. 2 and MPEP §2001.06(b) (last paragraph), the Examiner has reviewed and considered
the prior art cited in the Parent Application. Also in accordance with MPEP §2001.06(b) (last paragraph),
all documents cited or considered 'of record' in the Parent Application are now considered cited or 'of
record' in this application. Additionally, Applicant(s) are reminded that a listing of the information cited
or 'of record' in the Parent Application need not be resubmitted in this application unless Applicant(s)
desire the information to be printed on a patent issuing from this application. See MPEP §609.02 A. 2.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 and 4-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-15, 20 and 22-23 of U.S. Patent No. 11,308,486.
Instant Application
U.S. Patent No. 11,308,486
Claim 1
Claim 1
A computer implemented method of offering an exchange of an entity, the method comprising:
generating, by a processor or group of processors, a first script, the first script comprising: a first set of metadata associated with a first invitation for the exchange of a first entity by a first user, the first set of metadata comprising an indication of the first entity to be offered for exchange and a first location condition for the exchange; and a first user public key (P1A) associated with the first user, wherein the first user public key (P1A) is part of an asymmetric cryptographic pair comprising the first user public key (PIA) and a first user private key (V1A);
hashing, by the processor or group of processors, the first script to generate a first script hash; and
transmitting, by the processor or group of processors, the first script and/or the first script hash to: a website for publishing the invitation on the website, another user directly, and/or a service provider.
A computer implemented method of offering an exchange of an entity, the method comprising:
generating, by a processor or group of processors, a first script, the first script comprising: a first set of metadata associated with a first invitation for the exchange of a first entity by a first user, the first set of metadata comprising an indication of the first entity to be offered for exchange and a first location condition for the exchange; and a first user public key (P1A) associated with the first user, wherein the first user public key (P1A) is part of an asymmetric cryptographic pair comprising the first user public key (P1A) and a first user private key (V1A);
hashing, by the processor or the group of processors, the first script to generate a first script hash; and
publishing, by the processor or the group of processors, the first script and the first script hash on a distributed hash table (DHT).
Claim 4
Claim 2
the first script further comprises a first third-party public key (P1T) associated with a first third-party, wherein the first third-party public key (P1T) is part of an asymmetric cryptographic pair comprising the first third-party public key (P1T) and a first third-party private key (V1T)
the first script further comprises. a first third-party public key (P1T) associated with a first third-party, wherein the first third-party public key (P1T) is part of an asymmetric cryptographic pair comprising the first third-party public key (P1T) and a first third-party private key (V1T).
Claim 5
Claim 3
generating, by the processor or group of processors, a first invitation transaction for inclusion on a peer-to-peer (P2P) distributed ledger, the first invitation transaction comprising an indication of a second entity to be transferred in exchange for the first entity, and the first script hash.
generating, by the processor or the group of processors, a first invitation transaction for inclusion on a peer-to-peer (P2P) distributed ledger, the first invitation transaction comprising an indication of a second entity to be transferred in exchange for the first entity, and the first script hash.
Claim 6
Claim 4
the P2P distributed ledger is a block chain used for recording transactions involving a cryptocurrency
the P2P distributed ledger is a block chain used for recording transactions involving a cryptocurrency
Claim 7
Claim 5
the first entity that is offered for exchange and/or the second entity to be transferred in exchange for the first entity may be one or more of the following: a) a cryptocurrency; b) a contract; c) goods; d) services.
the first entity that is offered for exchange and/or the second entity to be transferred in exchange for the first entity may be one or more of the following: a) a cryptocurrency; b) a contract; c) goods; and d) services.
Claim 8
Claim 6
the contract is for one or more of the following: a) a fiat currency; b) title deeds; c) goods; and d) services.
the contract is for one or more of the following: a) a fiat currency; b) title deeds; c) goods; and d) services.
Claim 9
Claim 7
the first location condition comprises one or more of the following:
a) location information indicative of a geographical location or area for the exchange of the first entity;
b) location format information indicative of a format of the location information;
c) range information indicative of a range limit on the geographical location or area relating to the exchange; and
d) range format information indicative of a format of the range information.
the first location condition comprises one or more of the following:
a) location information indicative of a geographical location or area for the exchange of the first entity;
b) location format information indicative of a format of the location information;
c) range information indicative of a range limit on the geographical location or area relating to the exchange; and
d) range format information indicative of a format of the range information.
Claim 10
Claim 8
matching, by the processor or group of processors, the first invitation of the first script to a second script by comparing at least the first entity specified in the first script with a second entity specified in the second script; wherein the second script comprises: a second set of metadata associated with a second invitation for an exchange of a second entity by a second user, the second set of metadata comprising an indication of the second entity to be offered in exchange for the first entity; a second user public key (P2A) associated with the second user, wherein the second user public key (P2A) is part of an asymmetric cryptographic pair comprising the second user public key (P2A) and a second user private key (V2A); and a second third-party public key (P2T) associated with a second third-party, wherein the second third-party public key (P2T) is part of an asymmetric cryptographic pair comprising the second third-party public key (P2T) and a second third-party private key (V2T).
matching, by the processor or the group of processors, the first invitation of the first script to a second script that is published on the DHT by comparing at least the first entity specified in the first script with a second entity specified in the second script; wherein the second script comprises a second set of metadata associated with a second invitation for an exchange of a second entity by a second user, the second set of metadata comprising an indication of the second entity to be offered in exchange for the first entity; a second user public key (P2A) associated with the second user, wherein the second user public key (P2A) is part of an asymmetric cryptographic pair comprising the second user public key (P2A) and a second user private key (V2A); and a second third-party public key (P2T) associated with a second third-party, wherein the second third-party public key (P2T) is part of an asymmetric cryptographic pair comprising the second third-party public key (P2T) and a second third-party private key (V2T).
Claim 11
Claim 9
determining whether the location condition is fulfilled by identifying a location of the first user and/or the second user.
determining whether the location condition is fulfilled by identifying a location of the first user and/or the second user.
Claim 12
Claim 10
the second third-party is the same as a first third-party associated with a first third-party public key of the first script.
the second third-party is the same as a first third-party associated with a first third-party public key of the first script.
Claim 13
Claim 11
generating the second script;
hashing the second script to generate a second script hash; and
at least one of: publishing the second script and/or the second script hash on a DHT, transmitting the second script and/or the second script hash to a website for publication on the website, transmitting the second script and/or the second script hash directly to a user, and/or transmitting the second script and/or the second script hash to a service provider.
generating the second script;
hashing the second script to generate a second script hash; and
publishing the second script and the second script hash on the DHT.
Claim 14
Claim 12
generating a second invitation transaction for inclusion on the P2P distributed ledger, the second invitation transaction comprising an indication of the first entity to be transferred in exchange for the second entity; and the second script hash.
generating a second transaction invitation for inclusion on the P2P distributed ledger, the second invitation transaction comprising an indication of the first entity to be transferred in exchange for the second entity; and the second script hash.
Claim 15
Claim 13
generating a first exchange transaction for inclusion on the P2P distributed ledger, the first exchange transaction comprising: the first script; the first user public key (P1A);a first third-party public key (P1T);a first input provided from an output of the first invitation transaction; and a first output indicating a first quantity of a first entity to be transferred to a second user; and
recording the first exchange transaction on the P2P distributed ledger.
generating a first exchange transaction for inclusion on the P2P distributed ledger, the first exchange transaction comprising: the first script; the first user public key (P1A); a first third-party public key (P1T); a first input provided from an output of the first invitation transaction; and a first output indicating a first quantity of a first entity to be transferred to a second user; and
recording the first exchange transaction on the P2P distributed ledger.
Claim 16
Claim 14
generating a second exchange transaction for inclusion on the P2P distributed ledger, the second exchange transaction comprising: a second script; a second user public key (P2A);a second third-party public key (P2T);a second input provided from an output of a second invitation transaction; and a second output indicating a second quantity of a second entity to be transferred to the first user; and
recording the second exchange transaction on the P2P distributed ledger.
generating a second exchange transaction for inclusion on the P2P distributed ledger, the second exchange transaction comprising: a second script; a second user public key (P2A); a second third-party public key (P2T); a second input provided from an output of a second invitation transaction; and a second output indicating a second quantity of a second entity to be transferred to the first user; and
recording the second exchange transaction on the P2P distributed ledger.
Claim 17
Claim 15
generating a first exchange transaction for inclusion on the P2P distributed ledger, the first exchange transaction comprising: the first script; the first user public key (P1A);a first third-party public key (P1T);the second script; the second user public key (P2A);the second third-party public key (P2T);a first input provided from an output of a first invitation transaction; a second input provided from an output of the second invitation transaction; a first output indicating a first quantity of a first entity to be transferred to the second user; and a second output indicating a second quantity of a second entity to be transferred to the first user; and
recording the first exchange transaction on the P2P distributed ledger.
generating a first exchange transaction for inclusion on the P2P distributed ledger, the first exchange transaction comprising: the first script; the first user public key (P1A); a first third-party public key (P1T); the second script; the second user public key (P2A); the second third-party public key (P2T); a first input provided from an output of a first invitation transaction; a second input provided from an output of the second invitation transaction; a first output indicating a first quantity of a first entity to be transferred to the second user; and a second output indicating a second quantity of a second entity to be transferred to the first user; and
recording the first exchange transaction on the P2P distributed ledger.
Claim 18
Claim 20
A computer system for offering an exchange of an entity, the computer system comprising:
a first processing device configured to: generate a first script comprising: a first set of metadata associated with a first invitation for the exchange of a first entity by a first user, the first set of metadata comprising an indication of the first entity to be offered for exchange and a first location condition for the exchange, a first user public key (P1A) associated with the first user, wherein the first user public key (PTA) is part of an asymmetric cryptographic pair comprising the first user public key (PTA) and a first user private key (V1A);hash the first script to generate a first script hash; and
transmit the first script and/or the first script hash to: a website for publishing the invitation on the website, another user directly, and/or a service provider.
A computer system for offering an exchange of an entity, the computer system comprising:
a first processing device configured to: generate a first script comprising: a first set of metadata associated with a first invitation for the exchange of a first entity by a first user, the first set of metadata comprising an indication of the first entity to be offered for exchange and a first location condition for the exchange; and a first user public key (P1A) associated with the first user, wherein the first user public key (P1A) is part of an asymmetric cryptographic pair comprising the first user public key (P1A) and a first user private key (V1A); hash the first script to generate a first script hash; and
publish the first script and the first script hash on a distributed hash table (DHT).
Claim 19
Claim 22
the first and/or second set of metadata is provided in the script at a location which is designated in a blockchain protocol as a location for a cryptographic key.
the first and/or second set of metadata is provided in the script at a location which is designated in a blockchain protocol as a location for a cryptographic key.
Claim 20
Claim 23
A processor or group of processors operable to perform the method of claim 1.
A processor or group of processors operable to perform the method of claim 1.
Although the claims at issue are not identical, they are not patentably distinct from each other because the patented application discloses much of the subject matter in the instant application. The only major differences between the applications is that the patented application recites on claim 1 and 20 “publish the first script and the first script hash on a distributed hash table (DHT)” whereas the instant application recites on claim 1 and 18 “transmit the first script and/or the first script hash to: a website for publishing the invitation on the website, another user directly, and/or a service provider”. However the above mentioned difference does not render the claims patentable distinct because transmitting a script and publishing a script merely represent a variation of the same concept of distributing script data.
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-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-17 and 20 are directed to computer-implemented method (i.e., process). Claims 18-19 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 1, 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 of offering an exchange of an entity, the method comprising:
generating, by a processor or group of processors, a first script, the first script comprising: a first set of metadata associated with a first invitation for the exchange of a first entity by a first user, the first set of metadata comprising an indication of the first entity to be offered for exchange and a first location condition for the exchange; and a first user public key (P 1A) associated with the first user, wherein the first user public key (P 1A) is part of an asymmetric cryptographic pair comprising the first user public key (PIA) and a first user private key (V1A);
hashing, by the processor or group of processors, the first script to generate a first script hash; and
transmitting, by the processor or group of processors, the first script and/or the first script hash to: a website for publishing the invitation on the website, another user directly, and/or a service provider.
Claim 1, recites (i.e., sets forth or describes) a method for generating and transmitting a script. The claim achieves this by generating a script containing metadata and a public key, hashing the script and transmitting the script or the hash of the script. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” and “mathematical concept” groupings of abstract ideas. Claim 18 is significantly similar to claim 1. As such claims 18 also recite an abstract idea.
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 processor or group of processors, a first processing device and a website for publishing the invitation on the website merely serve as tools 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-17 and 19-20 have also been analyzed for subject matter
eligibility. However, claims 2-17 and 19-20 also fail to recite patent eligible subject matter for the
following reasons:
Claim 2 recites the following bolded claim elements as abstract ideas according to MPEP 2106.04(a).
the service provider hosts a private auction in which only certain users can access the first user's invitation details.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “mental processes” grouping of abstract ideas.
Claim 3 recites the following bolded claim elements as abstract ideas according to MPEP 2106.04(a).
the first user's invitation details include at least one of: the first entity to be exchanged, the first location condition for the exchange, and/or a second entity to be transferred in exchange for the first entity.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “mental processes” grouping of abstract ideas.
Claim 4 recites the following bolded claim elements as abstract ideas according to MPEP 2106.04(a).
the first script further comprises a first third-party public key (P1T) associated with a first third-party, wherein the first third-party public key (P I T) is part of an asymmetric cryptographic pair comprising the first third-party public key (PIT) and a first third-party private key (V1T)
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “mental processes” and “mathematical concepts” grouping of abstract ideas.
Claim 5 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
generating, by the processor or group of processors, a first invitation transaction for inclusion on a peer-to-peer (P2P) distributed ledger, the first invitation transaction comprising an indication of a second entity to be transferred in exchange for the first entity, and the first script hash.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-bolded additional elements of a processor or group of processors and a peer-to-peer (P2P) distributed ledger fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. 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.
Claim 6 recites the following non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the P2P distributed ledger is a block chain used for recording transactions involving a cryptocurrency.
The non-bolded additional elements of a P2P distributed ledger fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. 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.
Claim 7 recites the following bolded claim elements as abstract ideas according to MPEP 2106.04(a).
the first entity that is offered for exchange and/or the second entity to be transferred in exchange for the first entity may be one or more of the following: a) a cryptocurrency; b) a contract; c) goods; d) services.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
Claim 8 recites the following bolded claim elements as abstract ideas according to MPEP 2106.04(a).
the contract is for one or more of the following: a) a fiat currency; b) title deeds; c) goods; and d) services.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “mental processes” grouping of abstract ideas.
Claim 9 recites the following bolded claim elements as abstract ideas according to MPEP 2106.04(a).
the first location condition comprises one or more of the following:
a) location information indicative of a geographical location or area for the exchange of the first entity;
b) location format information indicative of a format of the location information;
c) range information indicative of a range limit on the geographical location or area relating to the exchange; and
d) range format information indicative of a format of the range information.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “mental processes” grouping of abstract ideas.
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).
matching, by the processor or group of processors, the first invitation of the first script to a second script by comparing at least the first entity specified in the first script with a second entity specified in the second script; wherein
the second script comprises: a second set of metadata associated with a second invitation for an exchange of a second entity by a second user, the second set of metadata comprising an indication of the second entity to be offered in exchange for the first entity; a second user public key (P2A) associated with the second user, wherein
the second user public key (P2A) is part of an asymmetric cryptographic pair comprising the second user public key (P2A) and a second user private key (V2A); and a second third-party public key (P2T) associated with a second third-party, wherein the second third-party public key (P2T) is part of an asymmetric cryptographic pair comprising the second third-party public key (P2T) and a second third-party private key (V2T).
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “mental processes” and “mathematical concepts” groupings of abstract ideas. The non-bolded additional elements of a processor or group of processors fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. 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.
Claim 11 recites the following bolded claim elements as abstract ideas according to MPEP 2106.04(a).
determining whether the location condition is fulfilled by identifying a location of the first user and/or the second user.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “mental processes” grouping of abstract ideas.
Claim 12 recites the following bolded claim elements as abstract ideas according to MPEP 2106.04(a).
the second third-party is the same as a first third-party associated with a first third-party public key of the first script.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “mental processes” grouping of abstract ideas.
Claim 13 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
generating the second script;
hashing the second script to generate a second script hash; and
at least one of: publishing the second script and/or the second script hash on a DHT, transmitting the second script and/or the second script hash to a website for publication on the website, transmitting the second script and/or the second script hash directly to a user, and/or transmitting the second script and/or the second script hash to a service provider.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “mental processes” and “mathematical concepts” grouping of abstract ideas. The non-bolded additional elements of a website for publication on the website fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. 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.
Claim 14 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
generating a second invitation transaction for inclusion on the P2P distributed ledger, the second invitation transaction comprising an indication of the first entity to be transferred in exchange for the second entity; and the second script hash.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-bolded additional elements of a P2P distributed ledger fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. 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.
Claim 15 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
generating a first exchange transaction for inclusion on the P2P distributed ledger, the first exchange transaction comprising: the first script; the first user public key (P1A); a first third-party public key (P I T); a first input provided from an output of the first invitation transaction; and a first output indicating a first quantity of a first entity to be transferred to a second user; and
recording the first exchange transaction on the P2P distributed ledger.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-bolded additional elements of a P2P distributed ledger fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. 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.
Claim 16 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
generating a second exchange transaction for inclusion on the P2P distributed ledger, the second exchange transaction comprising: a second script; a second user public key (P2A);a second third-party public key (P2T); a second input provided from an output of a second invitation transaction; and a second output indicating a second quantity of a second entity to be transferred to the first user; and
recording the second exchange transaction on the P2P distributed ledger.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-bolded additional elements of a P2P distributed ledger fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. 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.
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).
generating a first exchange transaction for inclusion on the P2P distributed ledger, the first exchange transaction comprising: the first script; the first user public key (P1A); a first third-party public key (P1T);the second script; the second user public key (P2A);the second third-party public key (P2T); a first input provided from an output of a first invitation transaction; a second input provided from an output of the second invitation transaction; a first output indicating a first quantity of a first entity to be transferred to the second user; and a second output indicating a second quantity of a second entity to be transferred to the first user; and
recording the first exchange transaction on the P2P distributed ledger.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-bolded additional elements of a P2P distributed ledger fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. 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.
Claim 19 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 first and/or second set of metadata is provided in the script at a location which is designated in a blockchain protocol as a location for a cryptographic key.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-bolded additional elements of a blockchain protocol fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. 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.
Claim 20 recites the following non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A processor or group of processors operable to perform the method of claim 1
The non-bolded additional elements of a blockchain protocol fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. 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.
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, 10, 12-13, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Antonopoulos (Mastering Bitcoin, 2010) in view of Smith (US 20180247084 A1).
Regarding claims 1, 18 and 20, Antonopoulos discloses:
generating, by a processor or group of processors, a first script, the first script comprising: a first set of metadata associated with a first invitation for the exchange of a first entity by a first user, the first set of metadata comprising an indication of the first entity to be offered for exchange and a first location condition for the exchange; and a first user public key (P 1A) associated with the first user, wherein the first user public key (P 1A) is part of an asymmetric cryptographic pair comprising the first user public key (PIA) and a first user private key (V1A); (P.24 ¶2, A transaction output is created in the form of a script that creates an encumbrance on the value and can only be redeemed by the introduction of a solution to the script. In simpler terms, Alice’s transaction output will contain a script that says something like “This output is payable to whoever can present a signature from the key corresponding to Bob’s public address”. P.116 ¶2, A locking script, also known as an “encumbrance” that “locks” this amount by specifying the conditions that must be met to spend the output. P.123 ¶2, Today most transactions processed through the bitcoin network have the form “Alice pays Bob” and are based on the same script called a Pay-to-Public-Key-Hash script. However, the use of scripts to lock outputs and unlock inputs means that through use of the programming language, transactions can contain an infinite number of conditions. P.123 ¶4, Bitcoin transaction validation is not based on a static pattern, but instead is achieved through the execution of a scripting language. This language allows for a nearly infinite variety of conditions to be expressed. P.123 ¶6, A locking script is an encumbrance placed on an output, and it specifies the conditions that must be met to spend the output in the future. Historically, the locking script was called a scriptPubKey, because it usually contained a public key or bitcoin address. In this book we refer to it as a “locking script” to acknowledge the much broader range of possibilities of this scripting technology. In most bitcoin applications, what we refer to as a locking script will appear in the source code as “scriptPubKey”. P.124 ¶1, That UTXO contains a locking script defining the conditions required to spend it.)
hashing, by the processor or group of processors, the first script to generate a first script hash; and (P.99 ¶6, A pay-to-script-hash address is created from a transaction script, which defines who can spend a transaction output (for more detail, see “Pay to Script Hash (P2SH)” on page 134). Encoding a pay-to-script hash address involves using the same double-hash function as used during creation of a bitcoin address, only applied on the script instead of the public key.
script hash = RIPEMD160(SHA256(script)). The resulting “script hash” is encoded with Base58Check with a version prefix of 5, which results in an encoded address starting with a 3. An example of a P2SH address is 32M8ednmuyZ2zVbes4puqe44NZumgG92sM. P.136, ¶1, The entire script above can instead be represented by a 20-byte cryptographic hash, by first applying the SHA256 hashing algorithm and then applying the RIPEMD160 algorithm on the result. The 20-byte hash of the above script is: 54c557e07dde5bb6cb791c7a540e0a4796f5e97e
A P2SH transaction locks the output to this hash instead of the longer script, using the locking script: OP_HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e OP_EQUAL which, as you can see is much shorter.)
Antonopoulos does not disclose, however Smith teaches:
transmitting, by the processor or group of processors, the first script and/or the first script hash to: a website for publishing the invitation on the website, another user directly, and/or a service provider. (¶0147, If the two hash values match, cryptographic processor 352 indicates to general purpose processor 302 that login was successful, and waits to receive a script for execution. ¶0148, At 525, cryptographic processor 352 receives a script for execution. Optionally, cryptographic processor 352 may receive additional data to be used during execution of the script.)
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 teaching of Antonopoulos by incorporating Smith’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to communicate to other users or service providers the conditions and parameters necessary for processing/validating transactions.
Further, the claimed limitation “…associated with a first invitation for the exchange of a first entity by a first user…” only describe characteristics of the first set of metadata which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Regarding claim 4, the combination of Antonopoulos and Smith further disclose:
the first script further comprises a first third-party public key (P1T) associated with a first third-party, wherein (Antonopoulos P. 24 ¶2, A transaction output is created in the form of a script that creates an encumbrance on the value and can only be redeemed by the introduction of a solution to the script. In simpler terms, Alice’s transaction output will contain a script that says something like “This output is payable to whoever can present a signature from the key corresponding to Bob’s public address”. Since only Bob has the wallet with the keys corresponding to that address, only Bob’s wallet can present such a signature to redeem this output. Alice will therefore “encumber” the output value with a demand for a signature from Bob. P.135 ¶3, In P2SH transactions, the locking script that is replaced by a hash is referred to as the redeem script because it is presented to the system at redemption time rather than as a locking script. Table 5-5. Complex Script as P2SH
Redeem Script 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG
Locking Script OP_HASH160 <20-byte hash of redeem script> OP_EQUAL
Unlocking Script Sig1 Sig2 redeem script)
the first third-party public key (P1T) is part of an asymmetric cryptographic pair comprising the first third-party public key (P1T) and a first third-party private key (V1T). (Antonopoulos P.61 ¶2, Keys come in pairs consisting of a private (secret) and public key. P.62 ¶5 & 6, In bitcoin, we use public key cryptography to create a key pair that controls access to bitcoins. The key pair consists of a private key and — derived from it — a unique public key. The public key is used to receive bitcoins, and the private key is used to sign transactions to spend those bitcoins. There is a mathematical relationship between the public and the private key that allows the private key to be used to generate signatures on messages. This signature can be validated against the public key without revealing the private key.)
The claimed limitation “the first script further comprises a first third-party public key (P1T) associated with a first third-party, wherein the first third-party public key (P1T) is part of an asymmetric cryptographic pair comprising the first third-party public key (P1T) and a first third-party private key (V1T).” only describe characteristics of the first script which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Regarding claim 6, the combination of Antonopoulos and Smith further disclose:
the P2P distributed ledger is a block chain used for recording transactions involving a cryptocurrency. (Antonopoulos P.1 ¶4, Bitcoin is a fully-distributed, peer-to-peer system. As such there is no “central” server or point of control. P.3 ¶4, Bitcoin represents the culmination of decades of research in cryptography and distributed systems and includes four key innovations brought together in a unique and powerful combination. Bitcoin consists of: A de-centralized peer-to-peer network (the bitcoin protocol); A public transaction ledger (the blockchain); A de-centralized mathematical and deterministic currency issuance (distributed mining), and; A de-centralized transaction verification system (transaction script). P.15 ¶1, In this chapter we will examine bitcoin from a high-level by tracking a single transaction through the bitcoin system and watch as it becomes “trusted” and accepted by the bitcoin mechanism of distributed consensus and is finally recorded on the blockchain, the distributed ledger of all transactions. P.25 ¶1, Now, the transaction must be transmitted to the bitcoin network where it will become part of the distributed ledger, the blockchain. P.29 ¶2, Now that Alice’s transaction has been embedded in the blockchain as part of a block, it is part of the distributed ledger of bitcoin and visible to all bitcoin applications.)
The claimed limitation “the P2P distributed ledger is a block chain used for recording transactions involving a cryptocurrency” only describe characteristics of the P2P distributed ledger which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Regarding claim 10, the combination of Antonopoulos and Smith further disclose:
matching, by the processor or group of processors, the first invitation of the first script to a second script by comparing at least the first entity specified in the first script with a second entity specified in the second script; wherein the second script comprises: a second set of metadata associated with a second invitation for an exchange of a second entity by a second user, the second set of metadata comprising an indication of the second entity to be offered in exchange for the first entity; a second user public key (P2A) associated with the second user, wherein the second user public key (P2A) is part of an asymmetric cryptographic pair comprising the second user public key (P2A) and a second user private key (V2A); and a second third-party public key (P2T) associated with a second third-party, wherein the second third-party public key (P2T) is part of an asymmetric cryptographic pair comprising the second third-party public key (P2T) and a second third-party private key (V2T). (Antonopoulos P.129 ¶2, When executed, this combined script will evaluate to TRUE if, and only if, the unlocking script matches the conditions set by the locking script. In other words, the result will be TRUE if the unlocking script has a valid signature from the Cafe’s private key which corresponds to the public key hash set as an encumbrance. P.133 ¶1, When executed, this combined script will evaluate to TRUE if, and only if, the unlocking script matches the conditions set by the locking script. In this case, the condition is whether the unlocking script has a valid signature from the two private keys that correspond to two of the three public keys set as an encumbrance.
Further, the claimed limitation “…associated with a second invitation for the exchange of a second entity by a second user…” only describe characteristics of the second set of metadata which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Regarding claim 12, the combination of Antonopoulos and Smith do not disclose:
the second third-party is the same as a first third-party associated with a first third-party public key of the first script.
However, the claimed limitation only describe characteristics of the second third-party which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Regarding claim 13, the combination of Antonopoulos and Smith further discloses:
generating the second script; (Antonopoulos P.24 ¶2, A transaction output is created in the form of a script that creates an encumbrance on the value and can only be redeemed by the introduction of a solution to the script. P.117 ¶2, When Bob chooses to spend that amount, his transaction will release the encumbrance, unlocking the output by providing an unlocking script containing a signature from Bob’s private key. P.117 ¶3, To spend UTXO, a transaction input also includes unlocking-scripts that satisfy the spending conditions set by the UTXO. The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script. P.119 ¶2, Once the UTXO is selected, the wallet then produces unlocking scripts containing signatures for each of the UTXO, thereby making them spendable by satisfying their locking script conditions
hashing the second script to generate a second script hash; and at least one of: (Antonopoulos P.99 ¶6, A pay-to-script-hash address is created from a transaction script, which defines who can spend a transaction output (for more detail, see “Pay to Script Hash (P2SH)” on page 134). Encoding a pay-to-script hash address involves using the same double-hash function as used during creation of a bitcoin address, only applied on the script instead of the public key.
script hash = RIPEMD160(SHA256(script)). The resulting “script hash” is encoded with Base58Check with a version prefix of 5, which results in an encoded address starting with a 3. An example of a P2SH address is 32M8ednmuyZ2zVbes4puqe44NZumgG92sM. P.136, ¶1, The entire script above can instead be represented by a 20-byte cryptographic hash, by first applying the SHA256 hashing algorithm and then applying the RIPEMD160 algorithm on the result. The 20-byte hash of the above script is: 54c557e07dde5bb6cb791c7a540e0a4796f5e97e
A P2SH transaction locks the output to this hash instead of the longer script, using the locking script: OP_HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e OP_EQUAL which, as you can see is much shorter.)
publishing the second script and/or the second script hash on a DHT, transmitting the second script and/or the second script hash to a website for publication on the website, transmitting the second script and/or the second script hash directly to a user, and/or transmitting the second script and/or the second script hash to a service provider. (Smith ¶0147, If the two hash values match, cryptographic processor 352 indicates to general purpose processor 302 that login was successful, and waits to receive a script for execution. ¶0148, At 525, cryptographic processor 352 receives a script for execution. Optionally, cryptographic processor 352 may receive additional data to be used during execution of the script.)
Claims 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Antonopoulos and Smith as applied to claim 1 above, in view of Fakhrai (US 20120179516 A1).
Regarding claim 2, the combination of Antonopoulos and Smith do not disclose, however Fakhrai teaches:
the service provider hosts a private auction in which only certain users can access the first user's invitation details. (¶0142, The process in some embodiments also provides a `private wish list` (or `private shopping list`) option to a buyer or a corporation in order to limit the invitation and the auction to a controlled group. Claim 18, the first purchase list is a private purchase list that limits the invitation from the first buyer to a controlled group of users, wherein the controlled group of users comprises said set of users identified by the first buyer to join the auction.)
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 Antonopoulos and Smith by incorporating Fakhrai’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order restrict access and to improve security and privacy.
Further, the claimed limitation “the service provider hosts a private auction in which only certain users can access the first user's invitation details” only describe characteristics of the private auction which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Regarding claim 3, the combination of Antonopoulos, Smith and Fakhrai further teaches:
the first user's invitation details include at least one of: the first entity to be exchanged, the first location condition for the exchange, and/or a second entity to be transferred in exchange for the first entity. (claim 13, sending an invitation to the identified set of users to join the auction, the invitation comprising information about a first item in the first purchase list)
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 Antonopoulos, Smith and Fakhrai by incorporating Fakhrai’s additional teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to provide the user with the assets and requirements/conditions that must be met for the exchange.
Further, the claimed limitation “the first user's invitation details include at least one of: the first entity to be exchanged, the first location condition for the exchange, and/or a second entity to be transferred in exchange for the first entity.” only describe characteristics of the first user's invitation which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Claims 5 and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over Antonopoulos and Smith as applied to claim 1 and 18 above, in view of Fay (US 20160292672 A1).
Regarding claim 5, the combination of Antonopoulos and Smith do not disclose, however Fay teaches:
generating, by the processor or group of processors, a first invitation transaction for inclusion on a peer-to-peer (P2P) distributed ledger, the first invitation transaction comprising an indication of a second entity to be transferred in exchange for the first entity, and the first script hash. (¶0007, The data transaction requests are received (via the transceiver) from remote computing devices. ¶0008, When a new data transaction request is received at the computer system from a remote computing devices, the request is added to an ordered list that corresponds to the request's type identifier. ¶0038, At step 236, computer device A transmits an electronic data message to the exchange computing system 100. The electronic data message includes a data transaction request for the exchange computer system 100 to carry out one or more tasks based on the content of the electronic data message. In certain examples, the data transaction request may be or include an order to “buy” or “sell” certain assets.)
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 Antonopoulos and Smith by incorporating Fay’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to define the exchange terms and associate it with predetermined transaction conditions.
Further, the claimed limitation “the first invitation transaction comprising an indication of a second entity to be transferred in exchange for the first entity, and the first script hash.” only describe characteristics of the first invitation transaction which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Furthermore, the claimed limitation “for…” in “generating, by the processor or group of processors, a first invitation transaction for inclusion on a peer-to-peer (P2P) distributed ledger” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Regarding claim 14, the combination of Antonopoulos and Smith do not disclose, however Fay teaches:
generating a second invitation transaction for inclusion on the P2P distributed ledger, the second invitation transaction comprising an indication of the first entity to be transferred in exchange for the second entity; and the second script hash. (Fay ¶0026, Order book 106 stores electronic data messages that have been received from order submitting clients (such as clients controlling a remote computing device such as user device 1 or 2). In certain example embodiments, order book 106 stores a list of electronic data messages. In certain implementations, two separately ordered lists are stored and maintained per type identifier (e.g., per ticker symbol or other asset identifier). The two lists may correspond to the buy and sell or bid and ask “sides” of an order book for a ticker symbol. The messages may be sorted according to one or more of: price, size, order submitting entity, time, time in the order book, etc. In certain examples, an order book is divided into two sides (side x and side y, which may be buy and sell sides). As an example, in some embodiments, the order book 106 stores, for a given type identifier (e.g., “AAPL”), an ordered list of buy orders for that type identifier and an ordered list of sell orders for that type identifier, where the two ordered lists are ordered according to factors such as price, size, and/or time, etc. . . . . An electronic data message that includes a new data transaction request (also referred to as an order in this and other examples herein) is received by the exchange computer system 100 via network interface 108 from an order submitting client (e.g., user device 1 or user device 2). Upon reception of the message, the hardware processor 102 may attempt to match the order included in the newly received electronic data message to existing orders stored in the order book 106. Alternatively, or in addition (e.g., if no match is found), the received electronic data message and/or its order is stored to the order book 106 for matching against future incoming electronic data messages that include orders. ¶0042, In step 242, if the order is valid, and as part of the order booking process, the exchange computer system 100 saves the newly submitted order to the order book 106. ¶0045, In step 246, should the newly received order (or a current order in the order book) be identified to match another order stored in the order book (e.g., based upon order handling and matching rules implemented by the exchange computer system 100 for the asset(s) being traded for), then the exchange computer system 100 notifies (in steps 248 and 249) each trading party (e.g., a computer device associated with users that corresponds to the trading parties) that a match has been identified and a trade will/is going to take place.)
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 Antonopoulos and Smith by incorporating Fay’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to generate a counter invitation transaction to finalize or complete the exchange agreement.
Further, the claimed limitation “the second invitation transaction comprising an indication of the first entity to be transferred in exchange for the second entity; and the second script hash” only describe characteristics of the second invitation transaction which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Furthermore, the claimed limitation “for…” in “generating a second invitation transaction for inclusion on the P2P distributed ledger” consists of language disclosing an intended use, 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 Antonopoulos, Smith and Fay further discloses:
generating a first exchange transaction for inclusion on the P2P distributed ledger, the first exchange transaction comprising: the first script; the first user public key (P1A);a first third-party public key (P1T); a first input provided from an output of the first invitation transaction; and a first output indicating a first quantity of a first entity to be transferred to a second user; and recording the first exchange transaction on the P2P distributed ledger. (Fay ¶0052, In FIG. 2C and in step 256, computing device A 120A generates a blockchain transaction using the previously received trade and/or wallet information (e.g., that includes information of trading party B's digital wallet) and transmits the generated blockchain transaction to blockchain computer system 214 at step 257… For example, a transaction message is generated that specifies the transfer of assets (e.g., 100 shares of AAPL) from one trading party (e.g., A) to the hashed wallet information that is associated with the counter party (e.g., B)… The transaction and the counter-transaction make up the trade that was identified by the exchange computer system 100 in step 246. ¶0055, In step 260, the transactions submitted by computing device A 120A and computing device B 120B are “mined” by individual nodes that make up the blockchain computer system 214 to validate the submitted transactions and are eventually written to the blockchain 116 (e.g., the public or private ledger). Generally, once a blockchain transaction is submitted for verification it is received by one or more of the computer nodes (e.g., individual computers that may each correspond to the architecture shown in FIG. 5) within the blockchain computer system 214. Once received by a node, that node will propagate the blockchain transaction to other nodes within the blockchain computer system. Each node then performs a mining process on the transaction (or a group of transactions called “blocks”). The mining process is a process for solving a computationally difficult problem that is also easy to verify. In some embodiments, this includes solving a cryptographic hash algorithm or function. The solution to the problem is generally called a proof of work and is included with the transaction or block of transactions as a record that transaction has been “solved” or verified. Accordingly, once a new block for the submitted transactions is generated and verified into the blockchain it is part of the blockchain. ¶0076, In certain example embodiments, exchange computer system 100 may implement a multi-signature feature which would allow the exchange computer system 100 to “break the trade” should either party fail to deliver. In particular, a generated blockchain transaction may require two different keys to show “ownership” of the outputs for the transactions. For example, a transaction from A to B may require B's key and the key of another third party (e.g., the exchange, the company associated with the underlying asset, or a regulatory authority) before B can “spend” or further transact the asset associated with the transaction. In certain example embodiments, a generated blockchain transaction may require a threshold number of keys from a total number of possible keys to unlock a blockchain transaction (e.g., to spend the outputs of that transaction). For example, 4 different keys may be used unlock a transaction and the transaction may be unlocked by 2 or more of the 4 required keys. ¶0080, As indicated above, the transactions may be submitted to the blockchain 116 from exchange computer system 100 on behalf of computing devices from client1 and client 2. In other words, the clients may only be used for the initial order submission. ¶0095, In step 408, client computer system 401 generates a new blockchain transaction and uses an interface (e.g., a software application that is installed on client computer system 401) to generate and send a transaction to blockchain computer system 214. This generated blockchain transaction also includes a transaction fee (e.g., a mining fee) of 1000 Satoshi (e.g., a crypto-currency). The transaction includes reference to a colored coin that encapsulates 1 AAPL share (e.g., the colored coin includes an identifier for AAPL along with a quantity of 1). In certain example embodiments, the transaction is “sent” to the hashed walletID (or hashed ID of Bob's digital wallet or the contents thereof). ¶0097, In step 412, the two transactions are mined by nodes of the blockchain computer system 214 and then added to the blockchain 116.)
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 Antonopoulos, Smith and Fay by incorporating Fay’s additional teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to execute the previously agreed exchange (from the first invitation transaction).
Further, the claimed limitation “the first exchange transaction comprising: the first script; the first user public key (P1A);a first third-party public key (P1T); a first input provided from an output of the first invitation transaction; and a first output indicating a first quantity of a first entity to be transferred to a second user” only describe characteristics of the first exchange transaction which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Furthermore, the claimed limitation “for…” in “generating a first exchange transaction for inclusion on the P2P distributed ledger” consists of language disclosing an intended use, 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, the combination of Antonopoulos, Smith and Fay further discloses:
generating a second exchange transaction for inclusion on the P2P distributed ledger, the second exchange transaction comprising: a second script; a second user public key (P2A);a second third-party public key (P2T);a second input provided from an output of a second invitation transaction; and a second output indicating a second quantity of a second entity to be transferred to the first user; and recording the second exchange transaction on the P2P distributed ledger. (Fay ¶0052, Similarly, computing device B 120B (the counter party) generates a blockchain transaction at step 258 and transmits the transaction to blockchain computer system 214 at step 259… The counter-transaction (e.g., generated by computing device B 120AB) may specify the transfer of some other assets (e.g., USD, bitcoin, other asset types, etc. . . . ). The transaction and the counter-transaction make up the trade that was identified by the exchange computer system 100 in step 246. ¶0055, In step 260, the transactions submitted by computing device A 120A and computing device B 120B are “mined” by individual nodes that make up the blockchain computer system 214 to validate the submitted transactions and are eventually written to the blockchain 116 (e.g., the public or private ledger). Generally, once a blockchain transaction is submitted for verification it is received by one or more of the computer nodes (e.g., individual computers that may each correspond to the architecture shown in FIG. 5) within the blockchain computer system 214. Once received by a node, that node will propagate the blockchain transaction to other nodes within the blockchain computer system. Each node then performs a mining process on the transaction (or a group of transactions called “blocks”). The mining process is a process for solving a computationally difficult problem that is also easy to verify. In some embodiments, this includes solving a cryptographic hash algorithm or function. The solution to the problem is generally called a proof of work and is included with the transaction or block of transactions as a record that transaction has been “solved” or verified. Accordingly, once a new block for the submitted transactions is generated and verified into the blockchain it is part of the blockchain. ¶0076, In certain example embodiments, exchange computer system 100 may implement a multi-signature feature which would allow the exchange computer system 100 to “break the trade” should either party fail to deliver. In particular, a generated blockchain transaction may require two different keys to show “ownership” of the outputs for the transactions. For example, a transaction from A to B may require B's key and the key of another third party (e.g., the exchange, the company associated with the underlying asset, or a regulatory authority) before B can “spend” or further transact the asset associated with the transaction. In certain example embodiments, a generated blockchain transaction may require a threshold number of keys from a total number of possible keys to unlock a blockchain transaction (e.g., to spend the outputs of that transaction). For example, 4 different keys may be used unlock a transaction and the transaction may be unlocked by 2 or more of the 4 required keys. ¶0080, As indicated above, the transactions may be submitted to the blockchain 116 from exchange computer system 100 on behalf of computing devices from client1 and client 2. In other words, the clients may only be used for the initial order submission. ¶0095, In step 410, client computer system 2 403, like client1, generates a new blockchain transaction and uses an interface to blockchain computer system 214 to send the generated transaction that includes the 1000 Satoshi transaction fee. This transaction is to Alice's digital wallet and includes a colored coin that encapsulates the $127 that is part of the identified trade. In certain example embodiments, the transaction is “sent” to the hashed walletID of Alice. ¶0097, In step 412, the two transactions are mined by nodes of the blockchain computer system 214 and then added to the blockchain 116. )
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 Antonopoulos, Smith and Fay by incorporating Fay’s additional teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to finalize the exchange transaction after the first exchange transaction so the transaction is fully executed by all parties.
Further, the claimed limitation “the second exchange transaction comprising: a second script; a second user public key (P2A);a second third-party public key (P2T);a second input provided from an output of a second invitation transaction; and a second output indicating a second quantity of a second entity to be transferred to the first user” only describe characteristics of the second exchange transaction which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Furthermore, the claimed limitation “for…” in “generating a second exchange transaction for inclusion on the P2P distributed ledger” consists of language disclosing an intended use, 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 Antonopoulos, Smith and Fay further teaches:
generating a first exchange transaction for inclusion on the P2P distributed ledger, the first exchange transaction comprising: the first script; the first user public key (P1A); a first third-party public key (P1T); the second script; the second user public key (P2A);the second third-party public key (P2T); a first input provided from an output of a first invitation transaction; a second input provided from an output of the second invitation transaction; a first output indicating a first quantity of a first entity to be transferred to the second user; and a second output indicating a second quantity of a second entity to be transferred to the first user; and recording the first exchange transaction on the P2P distributed ledger. (¶0052, In FIG. 2C and in step 256, computing device A 120A generates a blockchain transaction using the previously received trade and/or wallet information (e.g., that includes information of trading party B's digital wallet) and transmits the generated blockchain transaction to blockchain computer system 214 at step 257… For example, a transaction message is generated that specifies the transfer of assets (e.g., 100 shares of AAPL) from one trading party (e.g., A) to the hashed wallet information that is associated with the counter party (e.g., B)… The transaction and the counter-transaction make up the trade that was identified by the exchange computer system 100 in step 246. ¶0055, In step 260, the transactions submitted by computing device A 120A and computing device B 120B are “mined” by individual nodes that make up the blockchain computer system 214 to validate the submitted transactions and are eventually written to the blockchain 116 (e.g., the public or private ledger). Generally, once a blockchain transaction is submitted for verification it is received by one or more of the computer nodes (e.g., individual computers that may each correspond to the architecture shown in FIG. 5) within the blockchain computer system 214. Once received by a node, that node will propagate the blockchain transaction to other nodes within the blockchain computer system. Each node then performs a mining process on the transaction (or a group of transactions called “blocks”). The mining process is a process for solving a computationally difficult problem that is also easy to verify. In some embodiments, this includes solving a cryptographic hash algorithm or function. The solution to the problem is generally called a proof of work and is included with the transaction or block of transactions as a record that transaction has been “solved” or verified. Accordingly, once a new block for the submitted transactions is generated and verified into the blockchain it is part of the blockchain. ¶0076, In certain example embodiments, exchange computer system 100 may implement a multi-signature feature which would allow the exchange computer system 100 to “break the trade” should either party fail to deliver. In particular, a generated blockchain transaction may require two different keys to show “ownership” of the outputs for the transactions. For example, a transaction from A to B may require B's key and the key of another third party (e.g., the exchange, the company associated with the underlying asset, or a regulatory authority) before B can “spend” or further transact the asset associated with the transaction. In certain example embodiments, a generated blockchain transaction may require a threshold number of keys from a total number of possible keys to unlock a blockchain transaction (e.g., to spend the outputs of that transaction). For example, 4 different keys may be used unlock a transaction and the transaction may be unlocked by 2 or more of the 4 required keys. ¶0080, As indicated above, the transactions may be submitted to the blockchain 116 from exchange computer system 100 on behalf of computing devices from client1 and client 2. In other words, the clients may only be used for the initial order submission. ¶0095, In step 408, client computer system 401 generates a new blockchain transaction and uses an interface (e.g., a software application that is installed on client computer system 401) to generate and send a transaction to blockchain computer system 214. This generated blockchain transaction also includes a transaction fee (e.g., a mining fee) of 1000 Satoshi (e.g., a crypto-currency). The transaction includes reference to a colored coin that encapsulates 1 AAPL share (e.g., the colored coin includes an identifier for AAPL along with a quantity of 1). In certain example embodiments, the transaction is “sent” to the hashed walletID (or hashed ID of Bob's digital wallet or the contents thereof). ¶0097, In step 412, the two transactions are mined by nodes of the blockchain computer system 214 and then added to the blockchain 116.)
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 Antonopoulos, Smith and Fay by incorporating Fay’s additional teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to execute the previously agreed exchange.
Further, the claimed limitation “the first exchange transaction comprising: the first script; the first user public key (P1A); a first third-party public key (P1T); the second script; the second user public key (P2A);the second third-party public key (P2T); a first input provided from an output of a first invitation transaction; a second input provided from an output of the second invitation transaction; a first output indicating a first quantity of a first entity to be transferred to the second user; and a second output indicating a second quantity of a second entity to be transferred to the first user” only describe characteristics of the first exchange transaction which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Furthermore, the claimed limitation “for…” in “generating a first exchange transaction for inclusion on the P2P distributed ledger” consists of language disclosing an intended use, 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.
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Antonopoulos and Smith as applied to claim 1 above, in view of Stapp (US 20150248735 A1).
Regarding claim 7, the combination of Antonopoulos and Smith do not disclose, however Stapp teaches:
the first entity that is offered for exchange and/or the second entity to be transferred in exchange for the first entity may be one or more of the following: a) a cryptocurrency; b) a contract; c) goods; d) services. (¶0001, More specifically, the present disclosure relates to online exchange sessions for the exchange of assets comprising goods, services and combinations thereof. ¶0021, As used herein, the terms "asset," and "assets" refer to goods, services, or combinations 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 the combination of Antonopoulos and Smith by incorporating Stapp’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to provide a system that is not limited to one type of entity and instead allows the exchange of different entities.
Regarding claim 8, the combination of Antonopoulos, Smith and Stapp teach all the limitations of claim 7. Therefore the combination of Antonopoulos, Smith and Stapp reads on claim 8 as claim 8 is directed to further limiting optional limitations in claim 7.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Antonopoulos and Smith as applied to claim 1 above, in view of Ritter (US 7395031 B1).
Regarding claim 9, the combination of Antonopoulos and Smith does not disclose, however Ritter teaches:
the first location condition comprises one or more of the following: a) location information indicative of a geographical location or area for the exchange of the first entity; b) location format information indicative of a format of the location information; c) range information indicative of a range limit on the geographical location or area relating to the exchange; and d) range format information indicative of a format of the range information. (col 3 lines 66-67 & col 4 lines 1-3, For example, the location parameters include geographic coordinates defining a particular stand on the grounds of a trade fair or an exhibition, or relating to a particular point of sale and/or sales agent for products and/or services.)
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 Antonopoulos and Smith by incorporating Ritter’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to define different location conditions and link the execution of the online trade with the real world location, therefore ensuring security and verification.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Antonopoulos and Smith as applied to claim 10 above, in view of Ritter (US 7395031 B1).
Regarding claim 11, the combination of Antonopoulos and Smith do not disclose, however Ritter teaches:
determining whether the location condition is fulfilled by identifying a location of the first user and/or the second user. (col 4 line 67 & col 5 lines 1-8, The filter module 37 accepts the received program-accompanying data from the radio receiver 38 as well as the determined current position from the position locating module 39, and compares the location parameters contained in the program-accompanying data, for example geographic coordinates, with the current position. If the location parameters and the current position agree, the respective program-accompanying data can be passed on as location-specific information to a processing module 36. See claim 6)
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 Antonopoulos and Smith by incorporating Ritter’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to verify eligibility and condition satisfaction to execute the transaction.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Antonopoulos and Smith as applied to claim 18 above, in view of Pour (Bitcoin multisig the hard way: Understanding raw P2SH multisig transactions, December 20, 2014, URL: https://www.soroushjp.com/2014/12/20/bitcoin-multisig-the-hard-way-understanding-raw-multisignature-bitcoin-transactions/).
Regarding claim 19, the combination of Antonopoulos and Smith do not disclose, however Pour teaches:
the first and/or second set of metadata is provided in the script at a location which is designated in a blockchain protocol as a location for a cryptographic key. (P.2 ¶3, instead of letting senders put in long scripts into their scriptPubKey (where spending conditions usually go), they would let each sender put in a hash of their spending conditions instead. These spending conditions are known as the redeem script) and a P2SH funding transaction simply contains a hash of this redeem script in the scriptPubKey of the funding transaction. Where metadata (i.e. spending conditions) is provided in the script (i.e. redeem script) at a location which is designated in a blockchain protocol as a location for a cryptographic key (i.e. scriptPubKey).)
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 Antonopoulos and Smith by incorporating Pour’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to allow users to put a hash of their spending conditions into a spending transaction.
Further, the claimed limitation “the first and/or second set of metadata is provided in the script at a location which is designated in a blockchain protocol as a location for a cryptographic key.” only describe characteristics of the first and/or second set of metadata which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's
disclosure:
US 20180253702 A1 to Dowding discloses: A system and a method for creating a holistic, flexible, scalable, confidential, low-latency, high-volume, immutable distributed ledger for the financial services and other industries. The system allows a scalable blockchain solution with respect to accessible memory requirements of distributed ledgers or distributed databases with confidentiality in the shared records as well as accommodating low-latency, high-capacity transaction capabilities. The method includes a fundamental, generic, logical representation of financial services life-cycles transactions in terms of variable sets of four simple, sequential components. The optimal process generates a self-validating, variable n-dimensional, multi-hash-linked, interdependent distributed ledger that allows the individual network participants to recreate the ledger without having to refer to or confirm with other network participants.
US 20070198399 A1 to Nguyen discloses: A system and method that includes web server or a newspaper ad that allows people to auction their monetary, goods or services for someone else monetary, goods, or services by depositing the variable value of the "monetary, goods, or services" in to a Deposit Bank. A System and method comprise of a posting on to the system, the seller a entity monetary, goods, or services willing to exchange for the winning bidder entity monetary, goods, or services in an auction. Monetary is then deposited or hold onto the system owner or third party Deposit Bank. The two entities will deliver monetary, goods, or services as agreed. The monetary is then returned or holds from both entities from the Deposit Bank.
US 20170091750 A1 to Maim discloses: A transaction system based on a distributed peer-to-peer computer architecture, said system involving transactions generated by users by means of wallets and allowing the transfer of units of account by feeding inputs from outputs, each transaction (called downstream transaction) having an input directly or indirectly referring to an output of an upstream transaction (or several inputs each referring to an output of a respective upstream transaction) and having an output specifying the number of units of account and an address of a recipient. The system comprises means for connecting an input of a downstream transaction to an output of an upstream transaction as a function of matching rules between a code computed on all or part of the content of the downstream transaction and a check code contained in the upstream transaction, or conversely, The system further comprises means for propagating a contract, predetermined at an upstream transaction, to a downstream transaction having an input connected to the output of said upstream transaction, said contract being executable on a context for establishing allocation constraints of the output(s) of the downstream transaction, such allocation being authorized only if the constraints are met.
US 9892460 B1 to Winklevoss discloses: Systems, methods, and program products for providing an exchange traded product holding digital math-based assets are disclosed. Shares based on digital math-based assets may be created using one or more computers by determining share price information based upon quantities of digital math-based assets held by a trust, electronically receiving a request from an authorized participant user device to purchase a quantity of shares, electronically transmitting a quantity of digital math-based assets to one or more destination digital asset accounts for receipt of digital math-based assets from the authorized participant based on the determined share price information and the requested quantity of shares, and electronically issuing shares to the authorized participant.
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
Prosecution Insights