DETAILED ACTION
This is a non-final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 – 19 in application 18/554,541.
Examiner acknowledges “Preliminary Amendment” filed on 4/18/2024.
Claims 1 and amended.
Claims 9, 10, and 13 are canceled.
Claims 1-8, 11, 12, 14-19 are pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/17/2025 has been entered.
Response to Remarks
Regarding USC 101 Rejection
Applicant's arguments filed 12/17/2025 have been fully considered but they are not persuasive. Amended claim 1 is creating and enforcing conditional transactions for a “digital asset” including defining conditions, generating an “offer” and “request” authentication signatures, and recording the resulting transfer on a distributed ledger. This is directed to an abstract idea.
Applicant argues the claim is “technical” because it uses (i) multiple devices, (ii) a UICC, and (iii) sensors. However, the claim merely uses these elements as tools to perform the transaction flow. Accordingly, the claim does not recite a specific improvement; rather, it automates a transactional arrangement using generic computing components. Therefore, the additional elements does not integrate the abstract idea into a practical application. The 101 rejection is proper and will be maintained.
Regarding USC 103 Rejection
Applicant's arguments filed 12/17/2025 have been fully considered but they are not persuasive. In response to no. 1 on page 6 of applicant’s arguments, Salkintzis expressly discloses blockchain “subscription offer request” and “subscription offer” posted by a (first) network device to a smart contract. Salkintzis states that UE 205 is equipped with a eUICC that initially contains only a bootstrap profile and later uses device public/private keys in the blockchain workflow. The “secure applet” is implemented by Salkintzis device’s private key operations (the signature that underlies the on chain “offer” message/request) inside the UICC/secure element which is a predictable placement of cryptographic functionality that improves key protection hence an obvious design choice (KSR). The rejection to the limitation is updated.
In regards to no. 2 on page 6 of applicant’s arguments, Jentzsch discloses that the user device generates an electronically signed request/message and that the blockchain smart contract or the service/proxy device verifies the signature “through cryptographic signature verification.” The user device 105 electronically signs the request (¶ 0044). The smart contract 115 on the blockchain 120 receives and decrypts the electronically signed request (¶ 0045). The service device 110 receives the electronically signed message, verifies 610 the signature of the message request, and extracts the user identifier (¶ 0071). In Salkintzis, the “subscription offer” is a blockchain transaction/event emitted by smart contracts and blockchain interface nodes, the same environment where signatures are verified prior to state changes.
In regards to no. 3 on page 6 of applicant’s arguments, Jentzsch discloses that access/permission data (the on chain representation of the right/asset) is updated only after receipt and verification of a signed transaction/message from the user device. The service device 110 receives the electronically signed message and verifies 310 the signature of the electronically signed message. For example, the service device 110 may verify the signature through cryptographic signature verification. Additionally, the service device 110 may extract the user identifier by deriving it from the signed message. Here, the service device 110 can decrypt the electronically signed message using the public key and obtain the user identifier (¶ 0052). Salkintzis establishes the UE’s eUICC and device PKI in that same blockchain provisioning context. One of ordinary skilled in the art would of know the purpose of a UICC is tamper-resistant key storage and cryptographic operations to execute the signing operation for the on chain asset/transfer inside the UICC’s secure applet to harden key protection.
Jentzsch uses the same device for both an offer and a request. Salkintzis expressly supplies the complementary offer generated by a different device (blockchain interface function 224, transmits a second blockchain message containing a first subscription offer for the UE 205 (¶ 0062)).
A search was performed for the newly added claims. Therefore, new art is applied to the amended claim limitations.
See updated 103 rejection below.
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-8, 11, 12, 14-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1
Claims 1-8, 11, 12, 14-19 fall within at least one of the four categories of patent eligible subject matter, such as processes, machines, manufactures and compositions of matter, because the claims are respectively directed to a method and an apparatus (i.e., a system); therefore, the claims pass Step 1 of the Subject Matter Eligibility Test (see MPEP § 2106, subsection I).
The claims, however, are directed to an abstract idea without significantly more. The claim, as a whole, fall under the methods of organizing human activity grouping of the Subject Matter Groupings of Abstract Ideas enumerated in MPEP § 2106.04(a).
Step 2A, Prong 1
Claim 1 recites the following elements:
1. A method for generating transactions, the method comprising the steps of:
defining one or more conditions for a transaction;
adding the one or more conditions to blocks within a distributed ledger;
generating by a first device, an offer for a digital asset, wherein the offer is digitally signed by a secure applet executing within a UICC of the first device;
generating by a second device, a request for the digital asset, wherein the request is digitally signed by a secure applet executing within a UICC of the second device;
authenticating the digital signatures of the offer and of the request;
determining that the offer and request meet the one or more conditions added to the distributed ledger; and
when the one or more conditions are met by the offer and the request then:
digitally signing the digital asset by the secure applet executing within the UICC of the first device;
transmitting the signed digital asset from the first device to the second device;
authenticating the digital signature of the signed digital asset; and adding to a block on the distributed ledger, a transaction recording the transmission of the digital asset from the first device to the second device.
wherein the digital asset includes a package of data and wherein the package of data is derived from sensors on the first device.
(emphasis added on additional element(s) and/or intended use/result elements)
As drafted, the elements that are not bolded represent a process that, under its broadest reasonable interpretation, is directed to defining one or more conditions for a transaction, which is a form of commercial interaction related to manage interactions between people; therefore, the process falls under Certain Method of Organizing Human Activity. Accordingly, this Step 2A Prong 1 analysis concludes that claim 1 recites an abstract idea.
Step 2A, Prong 2
Claim 1 does not include additional elements (when considered individually, as an ordered combination, and/or within the claim as a whole) that are sufficient to integrate the abstract idea into a practical application. The additional elements are bolded above.
The first additional element is a first device. This element amounts to no more than using a generic computer component and/or system. Therefore, this element individually does not provide a practical application.
The second additional element is a second device. This element amounts to no more than using a generic computer component and/or system. Therefore, this element individually does not provide a practical application.
The additional elements does not provide a practical application of the abstract idea. Furthermore, the additional elements amount to a computer as a source of one input to the abstract idea
Step 2B
Claim 1 does not include additional elements, when considered individually and as an ordered combination, that are sufficient to amount to significantly more than the abstract idea explained above with respect to the integration of the abstract idea into a practical application, the additional elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment. Mere instructions to implement the abstract idea on a computer, or merely using the computer as a tool to perform an abstract idea to apply the exception using a generic computer component cannot provide an inventive concept. Looking at the limitations as a combination adds nothing that is not already present when looking at the elements taken individually.
Independent Claim 11 is similar to Claim 1. For the reasons above, the independent claims are rejected under 35 U.S.C. § 101 as being directed to non- statutory subject matter. Dependent claims 2-10 and 12-15 when analyzed are held to be patent ineligible under 35 U.S.C. §101 because the additional recited limitation(s) fail to establish that the claim(s) is/are not directed to an abstract idea.
Dependent claim 2 recites “wherein the step of determining when the conditions are met are determined by one or more smart contracts stored within the distributed ledger.” The additional element “smart contract” does not integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 3 recites “wherein the first device, the second device or a separate server adds the block to the distributed ledger recording the transmission of the digital asset from the first device to the second device.” The additional elements “first device” and “second device” does not integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 4 recites “wherein the signed digital asset is transmitted directly from the first device to the second device over a secure channel.” The additional elements “first device” and “second device” does not integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 5 recites “the step of recording a transaction of value on the distributed ledger between the second device and the first device in response to the conditions being met.” The additional elements “first device” and “second device” does not integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 6 recites “the step of the first device authenticating the digitally signed request.” The additional element “first device” does not integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 7 recites “the step of exchanging the digital asset for one or more goods or services.” There are no additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 8 recites “using the digital asset to access a service.” There are no additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 9 recites “wherein the digital asset includes a package of data.” There are no additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 10 recites “wherein the package of data is derived from sensors on the first device.” There are no additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 12 recites “wherein the UICCs of the first and second devices further comprise one or more secure storage locations configured to store cryptographic material for use in digitally signing.” There are no additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 13 recites “wherein the first device further comprises one or more sensors configured to generate sensor data and further wherein the digital asset is derived from those sensor data.” There are no additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 14 recites “comprising one or more service providers configured to provide a service in return for the digital asset.” There are no additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 15 recites “wherein the distributed ledger is further configured to store the conditions as one or more smart contracts.” The additional element “smart contracts” does not integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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) 1-8, 11, 12, 14 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jentzsch (US20180191714A1) in view of Salkintzis (WO2019158213A1) and in further view of Berti (US20190251575A1).
Regarding Claim 1. Jentzsch teaches (in BOLD): A method for generating transactions, the method comprising the steps of:
defining one or more conditions for a transaction;
Jentzsch - The service device's 110 condition of operations, triggered by a transaction from a user device 105, are stored and enforced in the smart contract 115. The smart contract 115 also may hold optional variables, such as a reference to the owner of the service device 110 and/or the parameters governing conditions for the operation of the service device 110 (e.g., deposit, cost of rental or sale, availability dates and/or times, etc.) (¶ 0030). one or more parameters related to a service provided by the service device (Claim 1).
adding the one or more conditions to blocks within a distributed ledger;
Jentzch - The smart contract 115 also may hold optional variables, such as a reference to the owner of the service device 110 and/or the parameters governing conditions for the operation of the service device 110 (e.g., deposit, cost of rental or sale, availability dates and/or times, etc.) (¶ 0030). Returning to FIG. 1A, the underlying blockchain 120 hosting the smart contract 115 can be public or private. The blockchain 120 may include a ledger in addition to the smart contract 115 (¶ 0034).
generating by a first device, an offer for a digital asset, wherein the offer is digitally signed by a secure applet executing within a UICC of the first device;
Jentzsch - The user uses his/her user device 105 to send 255 an electronically signed request to the smart contract 115 on the blockchain 120 to purchase permission to access the service device 110 (¶ 0043).
generating by a second device, a request for the digital asset, wherein the request is digitally signed by a secure applet executing within a UICC of the second device;
Jentzsch - receiving, from the user device, an electronically signed message requesting for the service to be provided by the service device, the signed message comprising the user identifier assigned to the user of the user device (Claim 2).
authenticating the digital signatures of the offer and of the request;
Jentzsch - The smart contract 115 on the blockchain 120 receives and decrypts the electronically signed request (¶ 0045). The service device 110 receives the electronically signed message and verifies 310 the signature of the electronically signed message (¶ 0052).
determining that the offer and request meet the one or more conditions added to the distributed ledger; and
Jentzsch - The smart contract 115 determines 260 whether the conditions for providing access are fulfilled. For example, the smart contract 115 on the blockchain 120 checks whether the correct funds that satisfy the variables of the smart contract 115 have been included in the electronically signed request. As another example, if the user device is sending an electronically signed request to rent a hotel room for a period of time, the smart contract 115 checks the parameters included in the request that specify the dates of stay requested by the user and compares the dates to dates of availability that are stored in the variables of the smart contract 115 which were previously set by the owner of the service device 130. If the specified dates are available (e.g., no one is renting the hotel room at that time), the smart contract 115 deems the conditions as fulfilled (¶ 0046).
when the one or more conditions are met by the offer and the request then: digitally signing the digital asset by the secure applet executing within the UICC of the first device;
Jentzsch - Given that the user device 105 has access to the blockchain 120 (e.g., the user device 105 is a node on the blockchain 120), the user device 105 continuously polls data from the blockchain 120 to update the local synchronized copy of the blockchain 120 and verifies 270 that the access rights to the service device 110 have been granted to the user identifier. Thus, the booking process is complete (¶ 0048).
transmitting the signed digital asset from the first device to the second device;
Jentzsch - Once the proxy device 550 has verified that the user device 105 has access to the service device 110, the proxy device 550 transmits an operational request to the service device 110. In response to the operational request, the service device provides 520 the service. The service device 110 transmits, back to the proxy device 550, a response to the operational request indicating that the service has been provided. The proxy device 550 may further transmit the response to the user device 105. The user device 105 can optionally provide for display 525 the outcome of the operation (¶ 0062).
authenticating the digital signature of the signed digital asset; and
Jentzsch - The user uses his/her user device 105 to send 255 an electronically signed request to the smart contract 115 on the blockchain 120 to purchase permission to access the service device 110 (¶ 0043). The trusted client sends (or transmits) 760 this signed message to the gateway 702 which then forwards 765 this response to the service device 110. The service device 110 verifies 770 the signature of the trusted client 704 in the received data package. This may be done by extracting the public key of the trusted client 704 from the message and comparing it to one stored in the service device's 110 whitelist (¶ 0091).
adding to a block on the distributed ledger, a transaction recording the transmission of the digital asset from the first device to the second device.
Jentzsch - an implementation of a smart contract on the decentralized blockchain that governs a particular service device ensures the secure exchange of services and payments. For example, as a distributed ledger, the blockchain can ensure that the payments are immutably recorded on the distributed ledger (¶ 0094).
Jentzsch does not teach, however Salkintzis discloses (in BOLD):
generating by a first device, an offer for a digital asset, wherein the offer is digitally signed by a secure applet executing within a UICC of the first device;
Salkintzis - The first blockchain interface function transmits a second blockchain message containing a first subscription offer for the remote unit (¶ 0010). The UE 205 is equipped with a eUICC that initially contains only a bootstrap profile (¶ 0060). provisioning data may be encrypted with a public key of the UE 205 (¶ 0065).
generating by a second device, a request for the digital asset, wherein the request is digitally signed by a secure applet executing within a UICC of the second device;
Salkintzis - The UE 205 is equipped with a eUICC that initially contains only a bootstrap profile. The UE 205 can establish communication via the wireless communication link 115 with any available mobile network (such as mobile network A 220) and can use its bootstrap profile to register with a mobile network. This registration with the bootstrap profile is then used in order to obtain an operational profile from a remote provisioning server, located inside a mobile network (¶ 0060).
if the one or more conditions are met by the offer and the request then: digitally signing the digital asset by the secure applet executing within the UICC of the first device;
Salkintzis - The UE 205 is equipped with a eUICC that initially contains only a bootstrap profile. The UE 205 can establish communication via the wireless communication link 115 with any available mobile network (such as mobile network A 220) and can use its bootstrap profile to register with a mobile network. This registration with the bootstrap profile is then used in order to obtain an operational profile from a remote provisioning server, located inside a mobile network (¶ 0060). the provisioning data may be encrypted with a public key of the UE 205 (¶ 0065).
Therefore, it would have been obvious to one of ordinary skill in the art of the claimed invention before the effective filing to date to modify the request of a digital service of Jentzch with the eUICC of Salkintzis because doing so allows the request and signature to be submitted securely.
The combination of Jentzch and Salkintzis does not disclose, however Berti discloses (in BOLD):
wherein the digital asset includes a package of data and wherein the package of data is derived from sensors on the first device.
Berti - usage data, such as IoT sensor readings associated with the physical asset (¶ 0051). a digital twin refers to a digital representation of a physical asset (¶ 0052). the digital twin stores and tracks information that describes the physical asset “a data package associated with a asset” (¶ 0055). information about one or more IoT devices, such as readings by IoT sensors (¶ 0057).
Therefore, it would have been obvious to one of ordinary skill in the art of the claimed invention before the effective filing to date to modify the request of a digital service of Jentzch and the eUICC of Salkintzis with the associating the sensor derived data of Berti because doing so provides the result of a digital asset whose contents include sensor derived data without changing the basic operation of the signed access or blockchain interaction.
Regarding Claim 2. The combination of Jentzch, Salkintzis, and Berti further teaches the method of claim 1, wherein the step of determining when the conditions are met are determined by one or more smart contracts stored within the distributed ledger.
Jentzsch - The smart contract 115 determines 260 whether the conditions for providing access are fulfilled. For example, the smart contract 115 on the blockchain 120 checks whether the correct funds that satisfy the variables of the smart contract 115 have been included in the electronically signed request (¶ 0046).
Regarding Claim 3. The combination of Jentzch, Salkintzis, and Berti further teaches the method of claim 1, wherein the first device, the second device or a separate server adds the block to the distributed ledger recording the transmission of the digital asset from the first device to the second device.
Jentzsch - By way of example, when the owner 130 of the service device desires to make the service device 110 available to provide a service, the owner 130 can provide a deposit amount and a price to access the service device 110 that is recorded as variables in the smart contract. When a user device 105 has sent enough funds (e.g., provided a deposit) that satisfies the variables stored by the smart contract 115 representing the service device 110, the user device 105 may in response transmit to the service device 110 operating commands (e.g., in the form of program code that comprises instructions) that may execute within the service device 110 to perform a particular action. In various embodiments the user device 105 and the service device 110 establish a state channel that enables the user device 105 to transmit more than one operating command to the service device 110. Further details entailing the logic behind the smart contract 115 and access to the service device 110 is described below (¶ 0032).
Regarding Claim 4. The combination of Jentzch, Salkintzis, and Berti further teaches the method according to claim 1, wherein the signed digital asset is transmitted directly from the first device to the second device over a secure channel.
Jentzsch - The gateway 702 may be any device and can support a communication channel (e.g., BLUETOOTH, NFC) with the service device 110. An example of the gateway 702 can be the user device 105. In some embodiments, the gateway 702 can hold a public/private key pair and signs messages with the public key. Therefore, the gateway 702 can initiate the validation-process by sending a signed message to the service device 110. The gateway 702 offers its internet connection to the service device 110 in order to connect to the blockchain 120 using trusted clients 710 (¶ 0075).
Regarding Claim 5. The combination of Jentzch, Salkintzis, and Berti further teaches the method according to claim 1 further comprising the step of recording a transaction of value on the distributed ledger between the second device and the first device in response to the conditions being met.
Jentzsch - By way of example, when the owner 130 of the service device desires to make the service device 110 available to provide a service, the owner 130 can provide a deposit amount and a price to access the service device 110 that is recorded as variables in the smart contract. When a user device 105 has sent enough funds (e.g., provided a deposit) that satisfies the variables stored by the smart contract 115 representing the service device 110, the user device 105 may in response transmit to the service device 110 operating commands (e.g., in the form of program code that comprises instructions) that may execute within the service device 110 to perform a particular action. In various embodiments the user device 105 and the service device 110 establish a state channel that enables the user device 105 to transmit more than one operating command to the service device 110. Further details entailing the logic behind the smart contract 115 and access to the service device 110 is described below (¶ 0032).
Regarding Claim 6. The combination of Jentzch, Salkintzis, and Berti further teaches the method according to claim 1 further comprising the step of the first device authenticating the digitally signed request.
Jentzsch - The trusted client sends (or transmits) 760 this signed message to the gateway 702 which then forwards 765 this response to the service device 110. The service device 110 verifies 770 the signature of the trusted client 704 in the received data package. This may be done by extracting the public key of the trusted client 704 from the message and comparing it to one stored in the service device's 110 whitelist (¶ 0091).
Regarding Claim 7. The combination of Jentzch, Salkintzis, and Berti further teaches the method according to claim 1 further comprising the step of exchanging the digital asset for one or more goods or services.
Jentzsch - By way of example, an implementation of a smart contract on the decentralized blockchain that governs a particular service device ensures the secure exchange of services and payments. For example, as a distributed ledger, the blockchain can ensure that the payments are immutably recorded on the distributed ledger (¶ 0094).
Regarding Claim 8. The combination of Jentzch, Salkintzis, and Berti further teaches the method according to claim 1 further comprising using the digital asset to access a service.
Jentzsch - FIG. 0.1B depicts underlying processes on a blockchain that enable the provision of a service from a service device, in accordance with an embodiment (¶ 0007).
Regarding Claim 9. The combination of Jentzch, Salkintzis, and Berti further teaches the method according to claim 1, wherein the digital asset includes a package of data.
Jentzsch - The trusted client sends (or transmits) 760 this signed message to the gateway 702 which then forwards 765 this response to the service device 110. The service device 110 verifies 770 the signature of the trusted client 704 in the received data package. This may be done by extracting the public key of the trusted client 704 from the message and comparing it to one stored in the service device's 110 whitelist (¶ 0091).
Regarding Claim 10. The combination of Jentzch, Salkintzis, and Berti further teaches the method of claim 9, wherein the package of data is derived from sensors on the first device.
Jentzsch - The computing device 200 also may include input device, for example, alphanumeric input device 212 (e.g., a keyboard), a cursor control device 214 (e.g., a mouse, a trackball, a joystick, a motion sensor, touch sensitive interface, or other pointing instrument) (¶ 0037).
Regarding Claim 11. Jentezsch teaches (in BOLD): A system comprising: a first device having a UICC, the first device configured to generate an offer for a digital asset and transmit the digital asset, the UICC storing in memory a secure applet containing program instructions to cause a processor to:
Jentzsch - The user uses his/her user device 105 to send 255 an electronically signed request to the smart contract 115 on the blockchain 120 to purchase permission to access the service device 110 (¶ 0043).
digitally sign the offer; and
Jentzsch - The user uses his/her user device 105 to send 255 an electronically signed request to the smart contract 115 on the blockchain 120 to purchase permission to access the service device 110 (¶ 0043).
digitally sign the digital asset; and
Jentzsch - The user uses his/her user device 105 to send 255 an electronically signed request to the smart contract 115 on the blockchain 120 to purchase permission to access the service device 110 (¶ 0043).
a second device having a UICC, the second device configured to generate a request, receive the digital asset transmitted by the first device, and authenticate the digital signature of the digital asset, the UICC storing in memory a secure applet containing program instructions to cause a processor to digitally sign the request; and
Jentzsch - receiving, from the user device, an electronically signed message requesting for the service to be provided by the service device, the signed message comprising the user identifier assigned to the user of the user device (Claim 2).
a distributed ledger having one or more nodes having one or more processors and memory, the memory containing program instructions to cause the one or more processor to: add one or more conditions to one or more blocks within a distributed ledger;
Jentzsch - Some or all of the example computing device components described may be within, for example, the user device 105, the service device 110, and/or any device that may be used by the user device 105 or service device 110 as a proxy to communicate with the blockchain 120. In other words, the computing device 200 is a node on the blockchain 120. The computing device 200 may be configured to read instructions from a machine-readable medium and execute them in at least one processor (or controller). Specifically, FIG. 1C shows a diagrammatic representation of a computing device 200 in the example form within which one or more instructions 224 (e.g., software or program or program product) for causing the computing device 200 to perform any one or more of the methodologies discussed herein may be executed (¶ 0036).
authenticate the digital signatures of the offer and of the request;
Jentzsch - The smart contract 115 on the blockchain 120 processes the request provided by the user device 105. The smart contract 115 on the blockchain 120 receives and decrypts the electronically signed request. For example, the electronically signed request is decrypted using the included public key of the user to obtain the content of the request (e.g., user identifier of the user, payments, and specified parameters) (¶ 0045). The smart contract 115 determines 260 whether the conditions for providing access are fulfilled. For example, the smart contract 115 on the blockchain 120 checks whether the correct funds that satisfy the variables of the smart contract 115 have been included in the electronically signed request. As another example, if the user device is sending an electronically signed request to rent a hotel room for a period of time, the smart contract 115 checks the parameters included in the request that specify the dates of stay requested by the user and compares the dates to dates of availability that are stored in the variables of the smart contract 115 which were previously set by the owner of the service device 130. If the specified dates are available (e.g., no one is renting the hotel room at that time), the smart contract 115 deems the conditions as fulfilled (¶ 0046).
determine that the offer and the request meet the one or more conditions added to the distributed ledger; and
Jentzsch - The smart contract 115 determines 260 whether the conditions for providing access are fulfilled. For example, the smart contract 115 on the blockchain 120 checks whether the correct funds that satisfy the variables of the smart contract 115 have been included in the electronically signed request. As another example, if the user device is sending an electronically signed request to rent a hotel room for a period of time, the smart contract 115 checks the parameters included in the request that specify the dates of stay requested by the user and compares the dates to dates of availability that are stored in the variables of the smart contract 115 which were previously set by the owner of the service device 130. If the specified dates are available (e.g., no one is renting the hotel room at that time), the smart contract 115 deems the conditions as fulfilled (¶ 0046).
allow the digitally signed asset to be transmitted from the first device to the second device
Jentzsch - Once the proxy device 550 has verified that the user device 105 has access to the service device 110, the proxy device 550 transmits an operational request to the service device 110. In response to the operational request, the service device provides 520 the service. The service device 110 transmits, back to the proxy device 550, a response to the operational request indicating that the service has been provided. The proxy device 550 may further transmit the response to the user device 105. The user device 105 can optionally provide for display 525 the outcome of the operation (¶ 0062).
when the digitally signed offer and request are determined to meet the one or more conditions.
Jentzsch - The smart contract 115 determines 260 whether the conditions for providing access are fulfilled. For example, the smart contract 115 on the blockchain 120 checks whether the correct funds that satisfy the variables of the smart contract 115 have been included in the electronically signed request. As another example, if the user device is sending an electronically signed request to rent a hotel room for a period of time, the smart contract 115 checks the parameters included in the request that specify the dates of stay requested by the user and compares the dates to dates of availability that are stored in the variables of the smart contract 115 which were previously set by the owner of the service device 130. If the specified dates are available (e.g., no one is renting the hotel room at that time), the smart contract 115 deems the conditions as fulfilled (¶ 0046).
digitally sign the offer;
Jentzsch - The smart contract 115 determines 260 whether the conditions for providing access are fulfilled. For example, the smart contract 115 on the blockchain 120 checks whether the correct funds that satisfy the variables of the smart contract 115 have been included in the electronically signed request. As another example, if the user device is sending an electronically signed request to rent a hotel room for a period of time, the smart contract 115 checks the parameters included in the request that specify the dates of stay requested by the user and compares the dates to dates of availability that are stored in the variables of the smart contract 115 which were previously set by the owner of the service device 130. If the specified dates are available (e.g., no one is renting the hotel room at that time), the smart contract 115 deems the conditions as fulfilled (¶ 0046).
Jentzsch does not teach, however Salkintzis discloses (in BOLD):
A system comprising: a first device having a UICC, the first device configured to generate an offer for a digital asset and transmit the digital asset, the UICC storing in memory a secure applet containing program instructions to cause a processor to:
Salkintzis - The UE 205 is equipped with a eUICC that initially contains only a bootstrap profile. The UE 205 can establish communication via the wireless communication link 115 with any available mobile network (such as mobile network A 220) and can use its bootstrap profile to register with a mobile network. This registration with the bootstrap profile is then used in order to obtain an operational profile from a remote provisioning server, located inside a mobile network (¶ 0060).
a second device having a UICC, the second device configured to generate a request, receive the digital asset transmitted by the first device, and authenticate the digital signature of the digital asset, the UICC storing in memory a secure applet containing program instructions to cause a processor to digitally sign the request; and
Therefore, it would have been obvious to one of ordinary skill in the art of the claimed invention before the effective filing to date to modify the request of a digital service of Jentzch with the eUICC of Salkintzis because doing so allows the request and signature to be submitted securely.
The combination of Jentzch, Salkintzis, and Berti does not disclose, however Berti discloses (in BOLD):
wherein the digital asset includes a package of data and wherein the package of data is derived from sensors on the first device.
Berti - usage data, such as IoT sensor readings associated with the physical asset (¶ 0051). a digital twin refers to a digital representation of a physical asset (¶ 0052). the digital twin stores and tracks information that describes the physical asset “a data package associated with a asset” (¶ 0055). information about one or more IoT devices, such as readings by IoT sensors (¶ 0057).
Therefore, it would have been obvious to one of ordinary skill in the art of the claimed invention before the effective filing to date to modify the request of a digital service of Jentzch and the eUICC of Salkintzis with the associating the sensor derived data of Berti because doing so provides the result of a digital asset whose contents include sensor derived data without changing the basic operation of the signed access or blockchain interaction.
Regarding Claim 12. The combination of Jentzch, Salkintzis, and Berti further teaches the system of claim 11, wherein the UICCs of the first and second devices further comprise one or more secure storage locations configured to store cryptographic material for use in digitally signing.
Jentzsch - The storage unit 216 includes a machine-readable medium 222 on which is stored instructions 224 (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions 224 (e.g., program code or software) may also reside, completely or at least partially, within the main memory 204 or within the processor 202 (e.g., within a processor's cache memory) during execution thereof by the computing device 200, the main memory 204 and the processor 202 also constituting machine-readable media. The instructions 224 (e.g., software) may be transmitted or received over a network 226 via the network interface device 220 (¶ 0038).
Regarding Claim 13. The combination of Jentzch, Salkintzis, and Berti further teaches the system of claim 11, wherein the first device further comprises one or more sensors configured to generate sensor data and further wherein the digital asset is derived from those sensor data.
Jentzsch - The computing device 200 also may include input device, for example, alphanumeric input device 212 (e.g., a keyboard), a cursor control device 214 (e.g., a mouse, a trackball, a joystick, a motion sensor, touch sensitive interface, or other pointing instrument).
Regarding Claim 14. The combination of Jentzch, Salkintzis, and Berti further teaches the system according to claim 11 further comprising one or more service providers configured to provide a service in return for the digital asset.
Jentzsch - FIG. 0.1B depicts underlying processes on a blockchain that enable the provision of a service from a service device, in accordance with an embodiment (¶ 0007).
Regarding Claim 15. The combination of Jentzch, Salkintzis, and Berti further teaches The combination of Jentzch, Salkintzis, and Berti further teaches the system according to claim 11 wherein the distributed ledger is further configured to store the conditions as one or more smart contracts.
Jentzsch - The user device 105 sends 450 the electronically signed message including its public key to the smart contract 115 on the blockchain 120 that represents the service device 110. The smart contract 115 on the blockchain 120 receives the electronically signed message, verifies the electronically signed message (e.g., through cryptographic signature verification methods), decrypts the electronically signed message using the public key, and extracts the user identifier. The smart contract 115 verifies 455 that the extracted user identifier has access rights to the service device 110. For example, the smart contract 115 accesses its permission data structure as part of its storage and compares the extracted user identifier to the user identifier that is listed in the permission data structure. The smart contract 115 queues up a service device request as part of its internal data store (¶ 0057).
Claim(s) 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jentzsch in view of Salkintzis and in further view of Berti and in further view of Theuss (US20150019165A1).
Regarding Claims 16 and 18. The combination of Jentzch, Salkintzis, and Berti does not discloses, however Theuss discloses:
The method according to claims 1 and 11, wherein the first device comprises a vehicle and wherein the sensors on the first device indicate a vehicle capacity.
Theuss - this disclosure is directed to weight detection of vehicles using vehicle sensors such as tire pressure sensors. Disclosed techniques include determining a weight of the vehicle or a change in weight of a vehicle according to tire pressure or a change in tire pressure of the vehicle, such as a change in tire pressure from a time prior to the loading or unloading of the vehicle to a time after the loading or unloading of a vehicle. The determined change in weight of the vehicle may then be added or subtracted to a predetermined weight of the vehicle to determine the total weight of the vehicle following the change in weight of the vehicle. In some examples, the techniques may include using additional data, such a tire temperature (¶ 0004).
Therefore, it would have been obvious to one of ordinary skill in the art of the claimed invention before the effective filing to date to modify the request of a digital service of Jentzch and the eUICC of Salkintzis and the associating the sensor derived data of Berti and the vehicle sensing of Theuss because doing so enriches the digital asset transaction record with objective, automatically captured physical asset information.
Regarding Claims 17 and 19. The combination of Jentzch, Salkintzis, and Berti does not discloses, however Theuss discloses:
The method according to claims 1 and 11, wherein the sensors on the first device comprise any one or more of location, GPS, temperature, light level, sound level, microphone, camera, video and pressure sensors.
Theuss - this disclosure is directed to weight detection of vehicles using vehicle sensors such as tire pressure sensors. Disclosed techniques include determining a weight of the vehicle or a change in weight of a vehicle according to tire pressure or a change in tire pressure of the vehicle, such as a change in tire pressure from a time prior to the loading or unloading of the vehicle to a time after the loading or unloading of a vehicle. The determined change in weight of the vehicle may then be added or subtracted to a predetermined weight of the vehicle to determine the total weight of the vehicle following the change in weight of the vehicle. In some examples, the techniques may include using additional data, such a tire temperature (¶ 0004).
Therefore, it would have been obvious to one of ordinary skill in the art of the claimed invention before the effective filing to date to modify the request of a digital service of Jentzch and the eUICC of Salkintzis and the associating the sensor derived data of Berti and the vehicle sensing of Theuss because doing so enriches the digital asset transaction record with objective, automatically captured physical asset information.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Mahajan et al. (US20190392511A1) - A bid matching for blockchain-based goods/assets system that allows users to participate in efficient and optimized auctions of blockchain-based assets/goods is disclosed. Instead of paying the current price for a blockchain-based item by signing and executing a transaction immediately, buyers pre-sign a crypto-transaction for a given future price of the item. The buyer sends the pre-signed crypto-transaction for future execution when the price of the blockchain-based good/asset matches (or falls below) a price that the buyer specified in the pre-signed transaction. Instead of executing bids on-chain, the bid matching for blockchain-based goods/assets system enables execution of an off-chain service that allows users to bid on one or more blockchain-based items with pre-signed transactions that are instantaneous and not dependent on network conditions. After an auction has ended, a winning bid is selected and executed automatically to consummate the purchase of the blockchain-based assets/goods.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINA C STEVENSON whose telephone number is (571)270-7280. The examiner can normally be reached on Monday to Friday to 8am-5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick Mcatee, can be reached at telephone number 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 an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698