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 .
Claim Objections
Claim 21 is objected to because of the following informalities: “the receiving device,” in line 10, should be written as “the wireless energy receiving device.” Appropriate correction is required.
Claim 21 is objected to because of the following informalities: “the transmitting device,” in line 10, should be written as “the wireless energy transmitting device.” Appropriate correction is required.
Claim 25 is objected to because of the following informalities: “the system of claim 25,” in line 1, should be written as “the method of claim 25.” Appropriate correction is required.
Claim 26 is objected to because of the following informalities: “the receiving device,” in line 3, should be written as “the wireless energy receiving device.” Appropriate correction is required.
Claim 26 is objected to because of the following informalities: “the transmitting device,” in line 3, should be written as “the wireless energy transmitting device.” Appropriate correction is required.
Claim 31 is objected to because of the following informalities: “the receiving device,” in line 28, should be written as “the wireless energy receiving device.” Appropriate correction is required.
Claim 31 is objected to because of the following informalities: “the transmitting device,” in line 27, should be written as “the wireless energy transmitting device.” Appropriate correction is required.
Claim 36 is objected to because of the following informalities: “the transmitting device,” in line 3, should be written as “the wireless energy transmitting device.” Appropriate correction is required.
Claim 36 is objected to because of the following informalities: “the receiving device,” in line 3, should be written as “the wireless energy receiving device.” Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 22 and 32 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 22 and 32 recite the limitation “proprietary two-part currency.” Specification, paragraph 131, recites that “in certain embodiments, a proprietary two-part currency is used.” However, the specification fails to describe what the “propriety two-part currency,” is composed, or what makes up the “proprietary” aspect of the “two-part currency,” in relation to other “two-part currencies.” For purposes of examination, examiner evaluates a “proprietary two-part currency” as a “two-part currency.”
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 22 and 32 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 22 and 32 fail to particularly point of and distinctly claim what a “proprietary two-part currency” is. For purposes of examination, examiner evaluates a “proprietary two-part currency” as a “two-part currency.”
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 21-40 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more.
Under the broadest reasonable interpretation, the following claim terms are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. MPEP § 2111.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03) Claim 21 recites a process, which is a statutory category of invention (Step 1: YES).
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a)). Yes.
The claims are analyzed to determine whether it is directed to a judicial exception. The following claims identify the limitations that recite additional elements in bold and the abstract idea without bold. Underlined claim limitations denote newly added claim limitations:
Claim 21 recites, a method for enabling wireless energy transfer transactions between at least one wireless energy receiving device or a buyer and at least one wireless energy transmitting device of a supplier, the method comprising: sending fiat currency to a first server, by the buyer; exchanging the fiat currency for a two-part currency comprising a first currency and a second currency, by the first server; sending the first currency to the buyer and retaining the second currency, by the first server; sending the first currency to the supplier to purchase wireless energy, by the buyer; providing wireless energy to the receiving device of the buyer, by the transmitting device of the supplier; sending the first currency to the first server by the supplier; combining the first currency and the second currency and sending the first currency and second currency to a trust server as two-part currency, by the first server; sending fiat currency to the first server, by the trust server; sending fiat currency to the supplier, by the first server. These limitations, as drafted, under its broadest reasonable interpretation, covers performance via certain methods of organizing human activity, but for the recitation of generic computer components. Under human activity, the limitations are commercial interactions, such as sales activities and business relations. Also, the limitations are also interactions between people, such as following instructions. The limitations are also a mental process, capable of being performed in the human mind or by pen and paper. Accordingly, the claim recites an abstract idea. The mere recitation of generic computer components in the claims do not necessarily preclude that claim from reciting an abstract idea. (Step 2A-Prong 1: Yes. The claims recite an abstract idea).
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d)). No.
The above judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements of a wireless energy receiving device, wireless energy transmitting device, first server, and trust server. The additional elements of a wireless energy receiving device, wireless energy transmitting device, first server, and trust server, are just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)). The computer components are recited at such a high-level of generality (i.e. as a generic computer components) such that it amounts to no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. (Step 2A-Prong 2: NO. The judicial exception is not integrated into a practical application).
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05). No.
The claims are next analyzed to determine if there are additional claim limitations that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements of (wireless energy receiving device, wireless energy transmitting device, first server, and trust server) in the claims amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea itself. Therefore, the claims do not amount to significantly more than the recited abstract idea (Step 2B: NO; The claims do not provide significantly more, and are not patent eligible).
Claim 22 recites wherein a proprietary two-part currency is used. These limitations are also part of the abstract idea identified in claim 21, and are similarly rejected under the same rationale as claim 21, supra.
Claim 23 recites wherein the transaction is initiated by scanning a QR code associated with the supplier, by the buyer. These limitations are also part of the abstract idea identified in claim 21, and the additional elements of the QR code are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 21 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 21, supra.
Claim 24 recites further comprising a wireless energy two-part blockchain currency. These limitations are also part of the abstract idea identified in claim 21, and are similarly rejected under the same rationale as claim 21, supra.
Claim 25 recites wherein the transaction is recorded on at least one blockchain ledger of at least one blockchain application. These limitations are also part of the abstract idea identified in claim 21, and the additional elements of a blockchain application are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 21 analysis above. These limitations are also part of the abstract idea identified in claim 21, and the additional elements of blockchain ledger are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of blockchain (MPEP 2106.05(h)), and the claim fails to recite technological detail as to how the step of the judicial exception is accomplished. Therefore, this claim is similarly rejected under the same rationale as claim 21, supra.
Claim 26 recites wherein the at least one blockchain application validates a correctness of the transfer of wireless energy, and wherein the two-way communication connection between the transmitting device and the receiving device is terminated upon validation of the correctness of the wireless energy transfer. These limitations are also part of the abstract idea identified in claim 21, and the additional elements of blockchain application, transmitting device and receiving device are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 21 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 21, supra.
Claim 27 recites wherein the wireless energy is transferred through: a plurality of devices configured as mobile transmitting or receiving power stations through which a plurality of devices can navigate, maneuver, beam ride, and/or recharge from point to point; wherein the plurality of devices are configured to transmit and receive power and data to and from a land-based, air-based, water-based, and/or space- based system to serve as power and data hubs, coupled to a plurality of tethers to further distribute power and/or data. These limitations are also part of the abstract idea identified in claim 21, and the additional elements of plurality of device, a land-based, air-based, water-based, and/or space- based system, and plurality of tethers are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 21 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 21, supra.
Claim 28 recites further comprising, generating, by the trust server, trust server data and providing the trust server data to a trust server approval module to approve the buyer and or supplier as a potential customer. These limitations are also part of the abstract idea identified in claim 21, and the additional elements of a trust server are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 21 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 21, supra.
Claim 29 recites wherein the trust server data includes buyer identity data for confirming the identity of at least the buyer and or supplier. These limitations are also part of the abstract idea identified in claim 21, and are similarly rejected under the same rationale as claim 21, supra.
Claim 30 recites wherein the trust server data includes approval data for confirming the buyer is eligible to receive wireless energy or the supplier is eligible to send wireless energy. These limitations are also part of the abstract idea identified in claim 21, and are similarly rejected under the same rationale as claim 21, supra.
Claim 31 –
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03) Claim 31 recites a system, which is a statutory category of invention (Step 1: YES).
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a)). Yes.
The claims are analyzed to determine whether it is directed to a judicial exception. The following claims identify the limitations that recite additional elements in bold and the abstract idea without bold. Underlined claim limitations denote newly added claim limitations:
Claim 31 recites a system for enabling wireless energy transfer transactions between a buyer and a supplier, the system comprising: a wireless energy receiving device of a buyer; a wireless energy transmitting device of a supplier; a computing device of the buyer; a computing device of the supplier; a first server, the first server configured to: receive fiat currency from the computing device of the buyer; and exchange the fiat currency for a two-part currency comprising a first currency and a second currency; send the first currency to the computing device of the buyer and retain the second currency, by the first server; wherein the computing device of the buyer is configured to: send the first currency to the computing device of the supplier to purchase wireless energy; the computing device of the supplier configured to: send the first currency by the computing device of the supplier to the first server; the first server further configured to: combine the first currency and the second currency and send the first currency and second currency to a trust server as two-part currency, by the supplier; the trust server configured to: sending fiat currency to the first server; the first server further configured to: send fiat currency to the supplier; and the at least one transmitting device configured to: provide wireless energy to the receiving device of the buyer. These limitations, as drafted, under its broadest reasonable interpretation, covers performance via certain methods of organizing human activity, but for the recitation of generic computer components. Under human activity, the limitations are commercial interactions, such as sales activities and business relations. Also, the limitations are also interactions between people, such as following instructions. The limitations are also a mental process, capable of being performed in the human mind or by pen and paper. Accordingly, the claim recites an abstract idea. The mere recitation of generic computer components in the claims do not necessarily preclude that claim from reciting an abstract idea. (Step 2A-Prong 1: Yes. The claims recite an abstract idea).
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d)). No.
The above judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements of system, wireless energy receiving device, wireless energy transmitting device, computing device of the buyer, computing device of the supplier, first server, trust server, transmitting device, and receiving device of the buyer. The additional elements of a system, wireless energy receiving device, wireless energy transmitting device, computing device of the buyer, computing device of the supplier, first server, trust server, transmitting device, and receiving device of the buyer, are just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)). The computer components are recited at such a high-level of generality (i.e. as a generic computer components) such that it amounts to no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. (Step 2A-Prong 2: NO. The judicial exception is not integrated into a practical application).
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05). No.
The claims are next analyzed to determine if there are additional claim limitations that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements of (system, wireless energy receiving device, wireless energy transmitting device, computing device of the buyer, computing device of the supplier, first server, trust server, transmitting device, and receiving device of the buyer) in the claims amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea itself. Therefore, the claims do not amount to significantly more than the recited abstract idea (Step 2B: NO; The claims do not provide significantly more, and are not patent eligible).
Claim 32 recites wherein a proprietary two-part currency is used. These limitations are also part of the abstract idea identified in claim 31, and are similarly rejected under the same rationale as claim 31, supra.
Claim 33 recites wherein the transaction is initiated by scanning a QR code associated with the supplier, by the computing device of the buyer. These limitations are also part of the abstract idea identified in claim 31, and the additional elements of the QR code are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 31 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 31, supra.
Claim 34 recites wherein the two-part currency is a wireless energy two-part blockchain currency. These limitations are also part of the abstract idea identified in claim 31, and are similarly rejected under the same rationale as claim 31, supra.
Claim 35 recites wherein the transaction is recorded on at least one blockchain ledger of at least one blockchain application. These limitations are also part of the abstract idea identified in claim 31, and the additional elements of a blockchain application are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 31 analysis above. These limitations are also part of the abstract idea identified in claim 31, and the additional elements of blockchain ledger are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of blockchain (MPEP 2106.05(h)), and the claim fails to recite technological detail as to how the step of the judicial exception is accomplished. Therefore, this claim is similarly rejected under the same rationale as claim 31, supra.
Claim 36 recites wherein the at least one blockchain application validates a correctness of the transfer of wireless energy, and wherein the two- way communication connection between the transmitting device and the receiving device is terminated upon validation of the correctness of the wireless energy transfer. These limitations are also part of the abstract idea identified in claim 31, and the additional elements of blockchain application, transmitting device and receiving device are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 31 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 31, supra.
Claim 37 recites wherein the wireless energy is transferred through: a plurality of devices configured as mobile transmitting or receiving power stations through which a plurality of devices can navigate, maneuver, beam ride, and/or recharge from point to point; wherein the plurality of devices are configured to transmit and receive power and data to and from a land-based, air-based, water-based, and/or space- based system to serve as power and data hubs, coupled to a plurality of tethers to further distribute power and/or data. These limitations are also part of the abstract idea identified in claim 31, and the additional elements of plurality of device, a land-based, air-based, water-based, and/or space- based system, and plurality of tethers are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 31 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 31, supra.
Claim 38 recites further comprising a trust server approval module, wherein the trust server generates trust server data and provides the trust server data to the trust server approval module to approve the buyer and or supplier as a potential customer. These limitations are also part of the abstract idea identified in claim 31, and the additional elements of a trust server are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 31 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 31, supra.
Claim 39 recites wherein the trust server data includes at least the buyer and or supplier identity data for confirming the identity of the buyer. These limitations are also part of the abstract idea identified in claim 31, and are similarly rejected under the same rationale as claim 31, supra.
Claim 40 recites wherein the trust server data includes approval data for confirming the buyer is eligible to receive wireless energy or the supplier is eligible to send wireless energy. These limitations are also part of the abstract idea identified in claim 31, and are similarly rejected under the same rationale as claim 31, supra.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 21, 22, 24, 25, 27, 31, 32, 34, 35, and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Power Ledger, “Power Ledger White Paper,” 2017, in view of Will US 20200169125 and Hertzog, et al., in “Bancor Protocol: Continuous Liquidity for Crypotgraphic Tokens through their Smart Contracts,” 2018.
Regarding claim 21, Power Ledger discloses sending fiat currency to a first server, by the buyer (Power Ledger, Section 1.8, Pg. 11, Buyers exchange fiat currency for Sparkz tokens through the platform, with the Power Core layer processing fiat payment; “The Power Ledger Platform (Platform) is a trustless, transparent and interoperable energy trading platform that supports an ever-expanding suite of energy applications, with an exchangeable frictionless energy trading token, Sparkz. The Power Ledger Token (POWR) is the fuel of the Power Ledger Ecosystem with bespoke private trading applications creating Sparkz in exchange for POWRs. Sparkz are currently purchased and redeemed using fiat currencies with individual trading platforms hosting closed-loop exchanges for energy and Sparkz.”; Applicant discloses “server” as a “server platform” throughout specification (“server platform 202”));
exchanging the fiat currency for a two-part currency comprising a first currency and a second currency, by the first server (Power Ledger, Section 4.3, Pg. 18, disclosing dual token ecosystem, with Sparkz tokens priced, issued and redeemed in the local currency of the Platform Participant; POWR tokens are required to generate Sparkz; Section 1.8, pg. 11; See also “Dual Token Ecosystem,” Section 4.3, “Purchasing a sufficient amount of POWR tokens allows Application Hosts access to the Ecosystem from where they can convert their POWR tokens to Sparkz and on-board their customer base.”; Section 1.8, “The Power Ledger Token (POWRTM) is the fuel of the Power Ledger Ecosystem with bespoke private trading applications creating Sparkz in exchange for POWRs. Sparkz are currently purchased and redeemed using fiat currencies with individual trading platforms hosting closed-loop exchanges for energy and Sparkz.”);
sending the first currency to the buyer and retaining the second currency, by the first server (Power Ledger, Fig. 4.1.1, Applicant buys POWR Token, generates Sparks and sells Sparkz; Section 4.3, Section 4.1, “To synchronize the Ecosystem globally and create cross-market electricity compatibility, a second token, Sparkz, is used for Ecosystem transactions. Sparkz tokens are priced, issued, and redeemed in the local currency of the Platform Participant. Purchasing a sufficient amount of POWR tokens allows Application Hosts access to the Ecosystem from where they can convert their POWR tokens to Sparkz and on-board their customer base”; Section 4.5, “POWR tokens will be escrowed for Sparkz in an Ethereum Smart Bond, and can only be unlocked from the Smart Bond upon the return of the Sparkz.”);
Power Ledger fails to disclose sending the first currency to the supplier to purchase wireless energy, by the buyer. However, Will discloses a wireless energy transfer system (Abstract, Fig. 4) where a wireless energy buyer (vehicle system 410) can purchase from a wireless energy seller (420) through a blockchain platform (430; See also Para. 38, discussing the ability of both systems to communicate for the transaction of power for currency, “The vehicle 110 may communicate 131 with the vehicle 121 to agree to exchange power for some value (e.g., money, credit, funds, securities, currency, virtual currency, goods, virtual goods, etc.). The communication 131 may include a negotiation over an amount of power, a time of power transfer, and a value to exchange for the power. Upon agreement to perform the exchange, and/or upon completion of the exchange, a record of the exchange may be generated and recorded in a decentralized database as, for example, a blockchain”).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the buyer sending a currency to purchase wireless energy by the supplier of Will. Doing so creates greater efficiency of the system allowing the buyer to purchase energy, and transforms the wireless energy into a market ready product to be bought and sold.
Power Ledger fails providing wireless energy to the receiving device of the buyer, by the transmitting device of the supplier. However, Will discloses providing transferring energy to the vehicle system 410 after acquisition through a blockchain platform (Fig. 2B; Fig. 4B; Element 454, from 420 to 410, following acceptance of 443 of 420’s offer).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the provision of wireless energy to the buyer from a supplier. Doing so creates a market for the exchange of necessary wireless energy, and increases the systems efficiency.
Modified Power Ledger discloses sending the first currency to the first server by the supplier (Power Ledger, after energy if provided, supplier’s Sparkz tokens are settled through the platform)
Modified Power Ledger fails to disclose combining the first currency and the second currency and sending the first currency and second currency to a trust server as two-part currency, by the first server. However, Hertzog et al., discloses a Bancor Protocol and Relay Token system with smart tokens that have one or more connectors to a network which allows the deposit of two different tokens (for example, BNT and ERC20) into a smart contract (with smart contract blockchains; Noting that blockchains have their own respective server), and where the smart mints a new “relay token” which represents the combined deposit, and the token can be sold or redeemed through the smart contract.
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the Hertzog. Doing so allows multiple currencies to interact, increasing the market potential for selling the energy while increasing the demand for the energy product, given more users being able to purchase with different currencies and increasing salability (Hertzog, Section 5.1, “More Scalable and Reliable Token Markets,” pg. 14).
Power Ledger fails to disclose sending fiat currency to the first server, by the trust server. However, Will discloses different servers (410, 420, and 430 all possess servers) where money is deployed through a blockchain platform with trust services (218) that sends money to 420 upon approval by changing upon on blockchain upon confirmation of the receipt of energy (455)(Para. 38, “Vehicles 110 and 121 may function as nodes in a blockchain system. The vehicle 110 may communicate 131 with the vehicle 121 to agree to exchange power for some value (e.g., money, credit, funds, securities, currency, virtual currency, goods, virtual goods, etc.). The communication 131 may include a negotiation over an amount of power, a time of power transfer, and a value to exchange for the power. Upon agreement to perform the exchange, and/or upon completion of the exchange, a record of the exchange may be generated and recorded in a decentralized database as, for example, a blockchain”; Para. 59, “The vehicle/system 410 may also, at 442, place a hold on the value (e.g., money, credit, funds, securities, currency, virtual currency, goods, virtual goods, etc.) to be used in exchange for the energy. The acceptance 443 may indicate a number or range of units of energy desired and a value for which the vehicle/system 410 is willing to exchange such units of energy, in some embodiments, reflecting the terms offered in offers 423 and 433”; Para. 62, “The blockchain platform 430 may, at 462, generate and store an update to the world state on the blockchain 463 with one or more data blocks reflecting the exchange represented by the update generated at 452”; Para. 64, “The device of method 500 may place an amount value (e.g., money, credit, funds, securities, currency, virtual currency, goods, virtual goods, etc.) on “hold,” thus reserving such value for use in the exchange. The device of method 500 may send an acceptance of the offer of exchange to the blockchain platform or associated system, which may include an indication of confirmation that the value has been placed on hold according to the terms of the exchange. This acceptance can be used to create a smart contract, or further the completion of a smart contract, by the blockchain platform and/or by the system supporting or associated with a blockchain platform”; Para. 67, “This information may confirm to the system of method 501 that value (e.g., money, credit, funds, securities, currency, virtual currency, goods, virtual goods, etc.) has been reserved for the exchange”)
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the transferring of money through a trust platform of blockchain from Will. Doing so ensures that the transaction officially was completed, enhancing security in the system to ensure transactions are completed.
Modified Power Ledger discloses a fiat payment processor integration (Section 5.3), a server platform, Sparkz being redeemable with fiat (Section 1.8; “The Power Ledger Token (POWRTM) is the fuel of the Power Ledger Ecosystem with bespoke private trading applications creating Sparkz in exchange for POWRs. Sparkz are currently purchased and redeemed using fiat currencies with individual trading platforms hosting closed-loop exchanges for energy and Sparkz”; Section 4.1, “Consumer and Prosumers buy and sell energy, which is settled with Sparkz tokens and may redeem the Sparkz for cash via their Application Host”), but fails to disclose sending fiat currency to the supplier, by the first server.
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the sending fiat currency to the supplier. Doing so is part of currency exchange between two different currencies and allows the supplier to be compensated in the preferred currency which enhances the tradability of the wireless energy between buyer and supplier.
Power Ledger discloses transacting energy between entities, but fails to disclose a method for enabling wireless energy transfer transactions between at least one wireless energy receiving device or a buyer and at least one wireless energy transmitting device of a supplier. However, Will discloses the transfer between one system that transmits energy supply and one system that receives energy supply in a wireless context (Fig. 4; Para. 38).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the transferring and receiving systems of wireless in an wireless energy context. Doing so enhances the energy market to consumers that can receive and transact wireless energy, while increasing profits for the energy producer by introducing energy to additional energy markets.
Claim 31 recites Power Ledger discloses a system for enabling wireless energy transfer transactions between a buyer and a supplier (Power Ledger, discloses powr token and sparz combined currency for use in wireless energy), the system comprising:
Power Ledger fails to disclose a wireless energy receiving device of a buyer; a wireless energy transmitting device of a supplier; a computing device of the buyer; and a computing device of the supplier. However, Will discloses two different mobiles phone devices for a user that supplies wireless energy and a user that consumed wireless energy (Fig. 1, 110 is a mobile device and 122 is a mobile device; Para. 39, “According to example embodiments, a mobile device or vehicle, such as the vehicle 110, may engage in wireless energy transfer and exchange with a mobile device, such as mobile device 122, a vehicle, such as vehicle 121, or a stationary system, such as building 123. Like the vehicles 110 and 121, the mobile device 122 and the building 123 may function as nodes in a blockchain system. For example, the vehicle 110 may communicate 132 with the mobile device 122 to agree to exchange power for a value”; Para. 40, Any of the communications 131, 132, and 133 may occur wirelessly. Such communications may utilize near field communications (NFC) for direct wireless communications);
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the sending and receiving devices for wireless energy transfer of Will. Doing so allows a market to be created between those entities that have energy to dispense of, and those entities that need energy, creating more efficiency.
Modified Power Ledger also discloses a first server, the first server (Power Ledger, Power Ledger, Section 1.8, Pg. 11, Buyers exchange fiat currency for Sparkz tokens through the platform, with the Power Core layer processing fiat payment; “The Power Ledger Platform (Platform) is a trustless, transparent and interoperable energy trading platform that supports an ever-expanding suite of energy applications, with an exchangeable frictionless energy trading token, Sparkz; Applicant discloses “server” as a “server platform” throughout specification (“server platform 202”) configured to:
Modified Power Ledger discloses receive fiat currency from the computing device of the buyer buyer (Power Ledger, Section 1.8, Pg. 11, Buyers exchange fiat currency for Sparkz tokens through the platform, with the Power Core layer processing fiat payment; “The Power Ledger Platform (Platform) is a trustless, transparent and interoperable energy trading platform that supports an ever-expanding suite of energy applications, with an exchangeable frictionless energy trading token, Sparkz. The Power Ledger Token (POWR) is the fuel of the Power Ledger Ecosystem with bespoke private trading applications creating Sparkz in exchange for POWRs. Sparkz are currently purchased and redeemed using fiat currencies with individual trading platforms hosting closed-loop exchanges for energy and Sparkz.”; Applicant discloses “server” as a “server platform” throughout specification (“server platform 202”));
and exchange the fiat currency for a two-part currency comprising a first currency and a second currency (Power Ledger, Section 4.3, Pg. 18, disclosing dual token ecosystem, with Sparkz tokens priced, issued and redeemed in the local currency of the Platform Participant; POWR tokens are required to generate Sparkz; Section 1.8, pg. 11; See also “Dual Token Ecosystem,” Section 4.3, “Purchasing a sufficient amount of POWR tokens allows Application Hosts access to the Ecosystem from where they can convert their POWR tokens to Sparkz and on-board their customer base.”; Section 1.8, “The Power Ledger Token (POWRTM) is the fuel of the Power Ledger Ecosystem with bespoke private trading applications creating Sparkz in exchange for POWRs. Sparkz are currently purchased and redeemed using fiat currencies with individual trading platforms hosting closed-loop exchanges for energy and Sparkz.”);
send the first currency to the computing device of the buyer and retain the second currency, by the first server (Power Ledger, Fig. 4.1.1, Applicant buys POWR Token, generates Sparks and sells Sparkz; Section 4.3, Section 4.1, “To synchronize the Ecosystem globally and create cross-market electricity compatibility, a second token, Sparkz, is used for Ecosystem transactions. Sparkz tokens are priced, issued, and redeemed in the local currency of the Platform Participant. Purchasing a sufficient amount of POWR tokens allows Application Hosts access to the Ecosystem from where they can convert their POWR tokens to Sparkz and on-board their customer base”; Section 4.5, “POWR tokens will be escrowed for Sparkz in an Ethereum Smart Bond, and can only be unlocked from the Smart Bond upon the return of the Sparkz.”);
Modified Power Ledger fails to disclose wherein the computing device of the buyer is configured to: send the first currency to the computing device of the supplier to purchase wireless energy. However, Will discloses a wireless energy transfer system (Abstract, Fig. 4) where a wireless energy buyer (vehicle system 410) can purchase from a wireless energy seller (420) through a blockchain platform (430; See also Para. 38, discussing the ability of both systems to communicate for the transaction of power for currency, “The vehicle 110 may communicate 131 with the vehicle 121 to agree to exchange power for some value (e.g., money, credit, funds, securities, currency, virtual currency, goods, virtual goods, etc.). The communication 131 may include a negotiation over an amount of power, a time of power transfer, and a value to exchange for the power. Upon agreement to perform the exchange, and/or upon completion of the exchange, a record of the exchange may be generated and recorded in a decentralized database as, for example, a blockchain”).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the buyer sending a currency to purchase wireless energy by the supplier of Will. Doing so creates greater efficiency of the system allowing the buyer to purchase energy, and transforms the wireless energy into a market ready product to be bought and sold.
the computing device of the supplier configured to: send the first currency by the computing device of the supplier to the first server (Power Ledger, after energy if provided, supplier’s Sparkz tokens are settled through the platform);
Modified Power Ledger fails to disclose the first server further configured to: combine the first currency and the second currency and send the first currency and second currency to a trust server as two-part currency, by the supplier. However, Hertzog et al., discloses a Bancor Protocol and Relay Token system with smart tokens that have one or more connectors to a network which allows the deposit of two different tokens (for example, BNT and ERC20) into a smart contract (with smart contract blockchains; Noting that blockchains have their own respective server), and where the smart mints a new “relay token” which represents the combined deposit, and the token can be sold or redeemed through the smart contract.
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the Hertzog. Doing so allows multiple currencies to interact, increasing the market potential for selling the energy while increasing the demand for the energy product, given more users being able to purchase with different currencies and increasing salability (Hertzog, Section 5.1, “More Scalable and Reliable Token Markets,” pg. 14).
Power Ledger fails to disclose the trust server configured to: sending fiat currency to the first server. However, Will discloses different servers (410, 420, and 430 all possess servers) where money is deployed through a blockchain platform with trust services (218) that sends money to 420 upon approval by changing upon on blockchain upon confirmation of the receipt of energy (455)(Para. 38, “Vehicles 110 and 121 may function as nodes in a blockchain system. The vehicle 110 may communicate 131 with the vehicle 121 to agree to exchange power for some value (e.g., money, credit, funds, securities, currency, virtual currency, goods, virtual goods, etc.). The communication 131 may include a negotiation over an amount of power, a time of power transfer, and a value to exchange for the power. Upon agreement to perform the exchange, and/or upon completion of the exchange, a record of the exchange may be generated and recorded in a decentralized database as, for example, a blockchain”; Para. 59, “The vehicle/system 410 may also, at 442, place a hold on the value (e.g., money, credit, funds, securities, currency, virtual currency, goods, virtual goods, etc.) to be used in exchange for the energy. The acceptance 443 may indicate a number or range of units of energy desired and a value for which the vehicle/system 410 is willing to exchange such units of energy, in some embodiments, reflecting the terms offered in offers 423 and 433”; Para. 62, “The blockchain platform 430 may, at 462, generate and store an update to the world state on the blockchain 463 with one or more data blocks reflecting the exchange represented by the update generated at 452”; Para. 64, “The device of method 500 may place an amount value (e.g., money, credit, funds, securities, currency, virtual currency, goods, virtual goods, etc.) on “hold,” thus reserving such value for use in the exchange. The device of method 500 may send an acceptance of the offer of exchange to the blockchain platform or associated system, which may include an indication of confirmation that the value has been placed on hold according to the terms of the exchange. This acceptance can be used to create a smart contract, or further the completion of a smart contract, by the blockchain platform and/or by the system supporting or associated with a blockchain platform”; Para. 67, “This information may confirm to the system of method 501 that value (e.g., money, credit, funds, securities, currency, virtual currency, goods, virtual goods, etc.) has been reserved for the exchange”)
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the transferring of money through a trust platform of blockchain from Will. Doing so ensures that the transaction officially was completed, enhancing security in the system to ensure transactions are completed.
Modified Power Ledger discloses a fiat payment processor integration (Section 5.3), a server platform, Sparkz being redeemable with fiat (Section 1.8; “The Power Ledger Token (POWRTM) is the fuel of the Power Ledger Ecosystem with bespoke private trading applications creating Sparkz in exchange for POWRs. Sparkz are currently purchased and redeemed using fiat currencies with individual trading platforms hosting closed-loop exchanges for energy and Sparkz”; Section 4.1, “Consumer and Prosumers buy and sell energy, which is settled with Sparkz tokens and may redeem the Sparkz for cash via their Application Host”), send fiat currency to the supplier, by the first server.
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the sending fiat currency to the supplier. Doing so is part of currency exchange between two different currencies and allows the supplier to be compensated in the preferred currency which enhances the tradability of the wireless energy between buyer and supplier.
Power Ledger discloses transacting energy between entities, but fails to disclose a method for enabling wireless energy transfer transactions between at least one wireless energy receiving device or a buyer and at least one wireless energy transmitting device of a supplier. However, Will discloses the transfer between one system that transmits energy supply and one system that receives energy supply in a wireless context (Fig. 4; Para. 38).
Power Ledger discloses transacting energy between entities, and also discloses the at least one transmitting device configured to: provide wireless energy to the receiving device of the buyer (Will, element 121 receiving wireless energy from any number of mobile phone or transports).
Regarding claims 22 and 32, modified Power Ledger discloses wherein a proprietary two-part currency is used (Herzog, disclosing two-part currency of both BNT and ERC20, with smart contract blockchains; Noting that blockchains have their own respective server).
Regarding claims 24 and 34, modified Power Ledger discloses wherein the two-part currency is a wireless energy two-part blockchain currency (Power Ledger, Two-part token system with POWR as the utility token for platform access and SPARKZ, as the energy-specific token representing kilowatt hours for transactions; Fig. 5.5.3.1 - Energy transfer is facilitated through smart cities and smart devices, on the grid, with grid being described throughout; “grid-supplied energy”; See also Section 2.3 describing “microgrids”; Grids are supplied with wireless energy; See also Section 5.5.5. describing grid development)
Regarding claims 25 and 35, modified Power Ledger discloses wherein the transaction is recorded on at least one blockchain ledger of at least one blockchain application (Will, Smart contracts are a type of “blockchain application”; Fig. 6C, smart contract; Para. 43, nodes 204-210 form a smart contract; Para. 44, smart contract created at high level application).
Regarding claims 27 and 37, modified Power Ledger discloses wherein the wireless energy is transferred through: a plurality of devices configured as mobile transmitting or receiving power stations through which a plurality of devices can navigate, maneuver, beam ride, and/or recharge from point to point (Will, Devices 110 and 121 are a plurality of devices; They are capable of recharging from point to point); wherein the plurality of devices are configured to transmit and receive power and data to and from a land-based, air-based, water-based, and/or space- based system to serve as power and data hubs, coupled to a plurality of tethers to further distribute power and/or data (Will, Fig. 4 410 and 410 transmit and receive power and data with blockchain platform).
Claim(s) 23 and 33 are rejected under 35 U.S.C. 103 as being unpatentable over Power Ledger, “Power Ledger White Paper,” 2017, in view of Will US 20200169125 and Hertzog, et al., in “Bancor Protocol: Continuous Liquidity for Cryptographic Tokens through their Smart Contracts,” 2018, as applied to claims 21 and 31, further in view of Tyler US 20140129428.
Regarding claims 23 and 33, modified Power Ledger fails to disclose wherein the transaction is initiated by scanning a QR code associated with the supplier, by the computing device of the buyer. However, Tyler discloses a QR code enabled P2P payment transaction where one party scans a QR code (Fig. 3, 206, 302 and 500) to initiate a transaction on their mobile phone that is associated with the sellers transfer (Para. 39, describing sender mobile device 110 and recipient mobile device 112, with sender financial account server 130 and recipient account server 140).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the QR code on the buyers device for the transaction. Doing so allows the buyer to enact the transacting and creates ease-of-use to finalize the transaction through the buyer’s mobile phone, while permitting supplier’s transaction to be finalized.
Claim(s) 24 and 34 are rejected under 35 U.S.C. 103 as being unpatentable over Power Ledger, “Power Ledger White Paper,” 2017, in view of Will US 20200169125 and Hertzog, et al., in “Bancor Protocol: Continuous Liquidity for Cryptographic Tokens through their Smart Contracts,” 2018, as applied to claims 21 and 31, further in view of Vieri US 20190172025.
Regarding claims 24 and 34, modified Power Ledger fails to disclose wherein the two-part currency is a wireless energy two-part blockchain currency. However, Vieri discloses a system for using kinetic energy to assign coins exchanged for cryptocurrency where a number of coins are calculated by a blockchain server, assigned to the blockchain server 260 and then exchanged for cryptocurrency at step 270, making a multi-part cryptocurrency to be exchanged in a wireless context (Para. 90 and 91).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the multi-part blockchain currency in a wireless context. Doing so allows different coin components to be later examined to understand what makes up the currency, if something needs to be examined a later date on the blockchain, and calculates coins in the exchange based on kinetic energy of the user (Para. 91).
Claim(s) 26 and 36 are rejected under 35 U.S.C. 103 as being unpatentable over Power Ledger, “Power Ledger White Paper,” 2017, in view of Will US 20200169125 and Hertzog, et al., in “Bancor Protocol: Continuous Liquidity for Cryptographic Tokens through their Smart Contracts,” 2018, as applied to claims 25 and 35, further in view of Chan US 20200160327.
Regarding Claims 26 and 36, modified Power Ledger discloses the transfer of wireless energy, but fails to disclose wherein the at least one blockchain application validates a correctness of the transfer of wireless energy, and wherein the two- way communication connection between the transmitting device and the receiving device is terminated upon validation of the correctness of the wireless energy transfer. However, Chan discloses a plurality of nodes (Fig. 1, 102) that posses two-way communication between each other (Fig. 1, see arrows running both ways between multiple 102’s),
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the energy transfer validation and termination upon completion. Doing so allows the system to ensure authenticity, and end the transfer to prevent any fraud post transfer the energy.
Claim(s) 28 -30, and 38-40 are rejected under 35 U.S.C. 103 as being unpatentable over Power Ledger, “Power Ledger White Paper,” 2017, in view of Will US 20200169125 and Hertzog, et al., in “Bancor Protocol: Continuous Liquidity for Cryptographic Tokens through their Smart Contracts,” 2018, as applied to claims 25 and 35, further in view of Borzilleri US 20190205881.
Regarding Claims 28 and 38, modified Power Ledger fails to disclose generating, by the trust server, trust server data and providing the trust server data to a trust server approval module to approve the buyer and or supplier as a potential customer. However, Borzilleri discloses a compliance platform (trust server) that generates compliance data and provides it to a rules engine (trust server approval module) to approve or reject buyers (Para. 13, rules engine determines compliance of the token purchaser for a specified token purchase), and the platform processes identity information (Know Your Customer process, with investor accreditation screening), while maintaining an approval database with records of compliance (Para. 13, “The approval database contains a records of compliance satisfaction for each token purchaser who completes a compliance process).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Power Ledger with the approval trust rules engine of Borzilleri. Doing so enhances security of the system, while maintaining proper records for compliance or future purchases.
Regarding Claims 29 and 39, modified Power Ledger discloses wherein the trust server data includes buyer identity data for confirming the identity of at least the buyer and or supplier (Borzilleri, Compliance platform generates compliance data by processing buyer information through rules information; Para. 13, “Rules engine determines compliance of the token purchaser”; Para. 13, “Approval database contains a record of compliance satisfaction for each token purchaser”)
Regarding Claims 30 and 40, modified Power Ledger discloses wherein the trust server data includes approval data for confirming the buyer is eligible to receive wireless energy or the supplier is eligible to send wireless energy (Borzilleri, Para. 20, Security token purchasers can be vetted through a compliance approval process, including…” know your customer (“KYC”) process, bad actor screening, investor accreditation, and regulation).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON M DUCK whose telephone number is (469)295-9049. The examiner can normally be reached 8am - 5pm.
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, Michael Anderson can be reached at 571-270-0508. 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.
/BRANDON M DUCK/Examiner, Art Unit 3693