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 .
Status of Claims
This is a first office action on the merits, in response to the claims filed on October 03, 2023.
Claims 59-73 are pending.
Claims 1-58 have been canceled.
Claim 73 has been withdrawn.
Claims 59-72 have been examined.
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 59-72 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 59-71 are directed to a method, and claim 72 is directed to a system comprising a key generator subsystem and one or more processors. Therefore, these claims fall within the four statutory categories of invention.
The claims recite an abstract idea of generating keys and encrypting and decrypting data with the generated keys. Specifically, the claims recite “(i) at […]: generating a public-private encryption key pair for a device, and transmitting the generated public key to be registered on a blockchain; (ii) at one or more […]: encrypting a digital asset via the public key of the device, and linking or associating the encrypted digital asset to a non-fungible token (NFT), in which the NFT is associated with a smart contract written on the blockchain; and (iii) at the device: requesting access to the NFT-linked digital asset; receiving the NFT-linked digital asset when the requirements of the smart contract are met; and decrypting the NFT-linked digital asset using the private key, wherein the public-private encryption key pair is automatically generated at the first boot or start-up of the device”, which is grouped within the “certain methods of organizing human activity”: fundamental economic principles (e.g., mitigating risk) grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP 2106.04(a)) because it describes a process for carrying out a fundamental economic principles between parties that involves communicating data needed to complete a transaction to the parties. Accordingly, the claims recite an abstract idea (See MPEP 2106.04).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106.04(a or d)), the additional element(s) of the claim(s) such as a key generator subsystem and one or more processors merely use(s) a computer as a tool to perform an abstract idea and generally link(s) the use of a judicial exception to a particular technological environment. Specifically, the key generator subsystem and one or more processors perform(s) the steps or functions of “(i) at a key generator subsystem: generating a public-private encryption key pair for a device, and transmitting the generated public key to be registered on a blockchain; (ii) at one or more processors: encrypting a digital asset via the public key of the device, and linking or associating the encrypted digital asset to a non-fungible token (NFT), in which the NFT is associated with a smart contract written on the blockchain; and (iii) at the device: requesting access to the NFT-linked digital asset; receiving the NFT-linked digital asset when the requirements of the smart contract are met; and decrypting the NFT-linked digital asset using the private key, wherein the public-private encryption key pair is automatically generated at the first boot or start-up of the device.” The use of a processor/computer as a tool to implement the abstract idea and generally linking the use of the abstract idea to a particular technological environment does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (See MPEP 2106.05(a)), the claims do not apply the abstract idea with, or by use of, a particular machine (See MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (See MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106.05), the additional element(s) of using a key generator subsystem and one or more processors to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of generating keys and encrypting and decrypting data with the generated keys. As discussed above, taking the claim elements separately, the key generator subsystem and one or more processors perform(s) the steps or functions of “(i) at a key generator subsystem: generating a public-private encryption key pair for a device, and transmitting the generated public key to be registered on a blockchain; (ii) at one or more processors: encrypting a digital asset via the public key of the device, and linking or associating the encrypted digital asset to a non-fungible token (NFT), in which the NFT is associated with a smart contract written on the blockchain; and (iii) at the device: requesting access to the NFT-linked digital asset; receiving the NFT-linked digital asset when the requirements of the smart contract are met; and decrypting the NFT-linked digital asset using the private key, wherein the public-private encryption key pair is automatically generated at the first boot or start-up of the device.” These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of generating keys and encrypting and decrypting data with the generated keys. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Claim 72 recites the abstract ideas subject matter similar to that discussed above in connection with claim 59. No new additional elements are identified in claim 72. Accordingly, claim 72 is rejected as being directed toward patent-ineligible subject matter.
Regarding dependent claims
Claim 60 recites: in which the device includes the key generator subsystem
Claim 61 recites: in which the digital asset is never sent unencrypted in the clear, such as on a cloud or internet, in which the NFT-linked digital asset can only be decrypted at the device, in which the decrypted digital asset can only be handled, such as reproduced or modified, at the device, in which the device cannot send the decrypted digital asset to an external device.
Claim 62 recites: in which the digital asset is encrypted via an asymmetric cryptography algorithm, such as RSA or ECC.
Claim 63 recites: in which the private key is never accessible or seen by the end-user of the device, in which the private key is stored on a non transitory storage medium, in which the private key cannot be transmitted externally to the device.
Claim 63 recites the abstract idea subject matter similar to that discussed above in connection with claim 59. The newly identified additional element of a non-transitory computer-readable medium also fails to recite a practical application or significantly more than the abstract ideas as it is instructions to apply the abstract ideas using computer components and generally link the use of the judicial exception to a particular technological environment or field of use.
Claim 64 recites: in which the public-private encryption key pair uniquely identifies the device.
Claim 65 recites: in which the public key of the device is associated with an asset token on the blockchain, in which the public key registered on the blockchain is associated with a digital signature identifying the device.
Claim 66 recites: in which the smart contract is configured to execute the requirements for trading the digital asset and is configured to define how the digital asset is managed, owned and/ or traded, in which the requirements for trading the digital asset include the maximum number of copies of the digital asset, in which the smart contract provides an audit trail or log of all the inputs and outputs of each transaction related to the digital asset, in which all the inputs and outputs of each transaction related to the digital asset are recorded in real time on the blockchain.
Claim 67 recites: wherein the digital asset is a firmware code, wherein the device is implemented in a single System on Chip (SoC), wherein the method includes the further step of creating chunks or blocks or any other form of batch of the digital asset before encrypting the digital asset, wherein the encrypted digital asset is stored into a permanent memory of the device, and wherein each chunk is decrypted and loaded on a RAM of the device on- the-fly at the SoC start up.
Claim 68 recites: in which the decrypted digital asset can be transmitted to peripherals inside the device.
Claim 69 recites: in which the maximum size of each chunk is determined by the encryption algorithm.
Claim 70 recites: in which the device includes a digital wallet subsystem, a storage subsystem and a decryption subsystem.
Claim 71 recites: in which each chunk of the digital asset is encrypted via the hybrid key.
Dependent claims further describe the abstract idea of generating keys and encrypting and decrypting data with the generated keys. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier.
Such claim limitation(s) is/are: a key generator subsystem, that is configured to generate a public- private encryption key pair for a device in claims 59 and 72.
As noted above, the claim limitations invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because they use generic placeholders such as “key generator subsystem” coupled with functional language “configured to” without reciting sufficient structure to achieve the function. Furthermore, the generic placeholder is not further modified by sufficient structure or material for performing the claimed function. The generic placeholders mentioned above are considered generic because the functions can be performed by either software or hardware or the combination of hardware and software, and equivalents thereof and the words themselves do not imply obvious structure. For example, the key generator subsystem, originally-filed specification discloses, see page 12, “As shown in Figure 1, the SoC may comprise one or more of the following blocks or subsystems”
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 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 59-72 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 pre-AIA the applicant regards as the invention.
The following claim limitations:
a key generator subsystem, that is configured to generate a public- private encryption key pair for a device in claims 59 and 72
Invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The disclosure is devoid of any structure that performs the function in the claim. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim 1 recites the phrases “wherein the public-private encryption key pair is automatically generated at the first boot or start-up of the device”. There is
insufficient antecedent basis for this limitation in the claim (e.g., the first boot). Appropriate correction is required.
Claim 71 recites the phrases “in which each chunk of the digital asset is encrypted via the hybrid key”. There is insufficient antecedent basis for this limitation in the claim (e.g., the hybrid key). Appropriate correction is required.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 59, 60, 62-66, 70 and 72 are rejected under 35 U.S.C. 103 as being unpatentable over Philip IANNACCONE (US 20210035090 A1, “IANNACCONE”) in view of Madhu Vijayan (US 20200005284 A1, “Vijayan”), and further in view of Kinshumann et al. (US 20160105280 A1, “Kinshumann”).
Regarding claims 59 and 72: IANNACCONE discloses: A computer implemented method, the method including the steps of (see paragraph [0004] and Fig. 1):
(i) at a key generator subsystem: generating a public-private encryption key pair for a device (IANNACCONE [0018]: Distributed ledger (e.g., blockchain, DAG) data can include one or more wallets (e.g., one or more wallets can be maintained on a distributed ledger), each wallet being associated with, but not limited to, a blockchain address, a public key, a private (e.g., secret) key, and tokens (e.g., cryptocurrency); [0023]: The function G produces a public/private (e.g., secret) key pair (“Pk” and “Sk”, respectively), and transmitting the generated public key to be registered on a blockchain (IANNACCONE [0024]: In some examples, encrypting the requested data with the subscriber's public key 309 (e.g., a public key associated with the subscriber's wallet on the distributed ledger)), (see also paragraph [0035]);
(ii) at one or more processors: encrypting a digital asset via the public key of the device (IANNACCONE [0024]: use public key for a first encryption of data (e.g., media content, a message) to be sent to one or more devices; encrypting the requested data with the subscriber's public key for delivery ensures that the data can only be deciphered by the intended recipient), and […]; and
(iii) at the device: requesting access to the [digital asset] (IANNACCONE [0027]: process detects a request for data);
receiving the [digital asset] when the requirements [are met] (IANNACCONE [0028]: At step 504, process 500 can retrieve the data from a server and/or database (e.g., server 102 and/or databases 103A of FIG. 1) using data information from the detected request (e.g., data ID) and encrypts the retrieved data with a public key associated with a wallet address corresponding to the requester to generate an inner ciphertext…In some examples, step 504 is only performed in accordance with a determination that the distributed ledger wallet contains a number of tokens above a threshold (e.g., an amount sufficient to include a minimum balance and/or a fee for the requested data) and/or that payment has been made (e.g. a signed cryptocurrency send transaction, mined on-chain cryptocurrency transfer transaction, wire transfer, credit card authorization)); and
decrypting the [digital asset] using the private key (IANNACCONE [0035]: At step 518, process 510 decrypts the inner ciphertext with a private key associated with a distributed ledger wallet corresponding to the requester (e.g., the user that invoked process 510) to obtain the requested data),
wherein the public-private encryption key pair is automatically generated [at the device] (see paragraph [0023]).
As indicated above, IANNACCONE discloses, receiving and decrypting the digital asset.
IANNACCONE does not specifically disclose: receiving and decrypting a NFT-linked digital asset. However, Vijayan, However, Vijayan discloses: receiving and decrypting a NFT-linked digital asset (see paragraphs [0011]-[0012], [0093] and [0096]).
IANNACCONE does not specifically disclose: linking or associating the encrypted digital asset to a non-fungible token (NFT), in which the NFT is associated with a smart contract written on the blockchain.
However, Vijayan discloses: linking or associating the encrypted digital asset to a non-fungible token (NFT), in which the NFT is associated with a smart contract written on the blockchain (Vijayan [0068]: In many embodiments, each NFT has a set of attributes that define its unique properties. These can be interpreted differently by various platforms in order to create platform specific user experiences. The metadata associated with an NFT may also include digital media assets such as (but not limited to) images, videos about the specific NFT or the context in which it was created (studio, film, band, company song etc.); [0011]: the processor is capable of being configured by the media wallet application to: securely store non-fungible tokens (NFTs), where each NFT is associated with a programmatically defined smart contract written to at least one immutable ledger), (see paragraph [0109]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify IANNACCONE with Vijayan to include another form of digital asset such as a non-fungible token (NFT) to enhance digital asset security and to enhance digital asset ownership security.
As indicated above, IANNACCONE discloses, the public-private encryption key pair is automatically generated (see paragraph [0023]).
IANNACCONE does not specifically disclose: the public-private encryption key pair is automatically generated at the first boot or start-up of the device.
However, Kinshumann discloses: the public-private encryption key pair is automatically generated at the first boot or start-up of the device (Kinshumann [0038]: Additionally, one or more modules of the boot system 106 generate a public/private key pair; [0040]: The point during the booting of the computing device 102 at which the security boundary 110 is to be generated and the point during the booting of the computing device 102 at which the public/private key pair is to be generated are known to the remote device).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of IANNACCONE and Vijayan with Kinshumann to include well-known technology/function of securing data/devices by implanting generation of keys during a device start-up to enhance data and device security.
Regarding claim 60: IANNACCONE, Vijayan and Kinshumann, discloses the limitations of claim 59 above.
IANNACCONE further discloses: The method of Claim 59, in which the device includes the key generator subsystem (IANNACCONE [0023]: These cryptosystems employ three main functions: key generation “G”, encryption “E”, and decryption “D”. The function G produces a public/private (e.g., secret) key pair (“Pk” and “Sk”, respectively)), (see paragraphs [0004] and [0023]).
Regarding claim 62: IANNACCONE, Vijayan and Kinshumann, discloses the limitations of claim 59 above.
IANNACCONE further discloses: The method of Claim 59, in which the digital asset is encrypted via an asymmetric cryptography algorithm, such as RSA or ECC (see paragraphs [0004] and [0023]).
Regarding claim 63: IANNACCONE, Vijayan and Kinshumann, discloses the limitations of claim 59 above.
IANNACCONE further discloses: The method of Claim 59, in which the private key is never accessible or seen by the end-user of the device (IANNACCONE [0023]: A system in accordance with the disclosure also utilizes public key cryptography, also known as asymmetrical cryptography. Asymmetric key cryptosystems, including those based on Diffie-Hellman, Rivest-Shamir-Adelman (RSA), Elliptic Curve Cryptography (ECC), or Digital Signature Algorithm (DSA) algorithms can be used in conjunction with the disclosed computer system…With this set of functions, secured information may be exchanged publicly between two or more parties without necessarily disclosing key secrets (e.g., without exchanging private keys) or other secrets among the parties involved in the exchange. Key pairs are split between public keys which may be disseminated freely (e.g., are publicly known), and private (e.g., secret) keys in which access is restricted (e.g., to the wallet owner)), (see paragraphs [0004] and [0023]),
in which the private key is stored on a non transitory storage medium (see paragraphs [0004] and [0023]),
in which the private key cannot be transmitted externally to the device, (see paragraphs [0022]-[0023] and [0049]).
Regarding claim 64: IANNACCONE, Vijayan and Kinshumann, discloses the limitations of claim 59 above.
IANNACCONE further discloses: The method of Claim 59, in which the public-private encryption key pair uniquely identifies the device (see paragraphs [0004], [0018] and [0023]).
Regarding claim 65: IANNACCONE, Vijayan and Kinshumann, discloses the limitations of claim 59 above.
IANNACCONE further discloses: The method of Claim 59, in which the public key of the device is associated with an asset token on the blockchain (IANNACCONE [0024]: In some examples, the public collateral key 309 could be a public address on the distributed ledger associated with a cryptocurrency or smart contract token found on a distributed ledger 306 (e.g., the public address of a distributed ledger wallet). In this way, the private collateral key representing ownership of the crypto-asset is the same key required to decode the delivered media. In some examples, the public address associated with a cryptocurrency or smart contract token found on a distributed ledger 306 (e.g., the public address of a distributed ledger wallet) can be derived from the public collateral key 309 (e.g., by performing a hash operation on all or part of the public collateral key). In some examples, any threshold payment and/or deposit amount of the crypto-asset collateral could be mandated to initiate (or continue) data transfer and staking of this amount by the consumer can be publicly verified on the distributed ledger 306), (see paragraphs [0018], [0004] and [0023]),
in which the public key registered on the blockchain is associated with a digital signature identifying the device (see paragraph [0004] and [0023]-[0024]).
Regarding claim 66: IANNACCONE, Vijayan and Kinshumann, discloses the limitations of claim 59 above.
IANNACCONE further discloses: The method of Claim 59, in which the smart contract is configured to execute the requirements for trading the digital asset and is configured to define how the digital asset is managed, owned and/ or traded (see paragraphs [0019] and [0040]),
in which the requirements for trading the digital asset include the maximum number of copies of the digital asset (see paragraph [0024]),
in which the smart contract provides an audit trail or log of all the inputs and outputs of each transaction related to the digital asset (see paragraphs [0018]-[0019]),
in which all the inputs and outputs of each transaction related to the digital asset are recorded in real time on the blockchain (see paragraphs [0018]-[0019]).
Alternatively, Vijayan also discloses: The method of Claim 59, in which the smart contract is configured to execute the requirements for trading the digital asset and is configured to define how the digital asset is managed, owned and/ or traded (see paragraphs [0023], [0066], [0073] and [0109]),
in which the requirements for trading the digital asset include the maximum number of copies of the digital asset (see paragraphs [0023], [0066], [0073] and [0109]),
in which the smart contract provides an audit trail or log of all the inputs and outputs of each transaction related to the digital asset (see paragraphs [0023], [0066], [0073] and [0109]),
in which all the inputs and outputs of each transaction related to the digital asset are recorded in real time on the blockchain (see paragraphs [0023], [0066], [0073] and [0109]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of IANNACCONE and Kinshumann with Vijayan to include another form of digital asset such as a non-fungible token (NFT) to enhance digital asset security and to enhance digital asset ownership security.
Regarding claim 70: IANNACCONE, Vijayan and Kinshumann, discloses the limitations of claim 59 above.
IANNACCONE further discloses: The method of Claim 59, in which the device includes a digital wallet subsystem, a storage subsystem and a decryption subsystem (see paragraphs [0014], [0018] and [0024]).
Claims 61 and 68 are rejected under 35 U.S.C. 103 as being unpatentable over IANNACCONE (US 20210035090 A1, “IANNACCONE”) in view of Madhu Vijayan (US 20200005284 A1, “Vijayan”), in view of Kinshumann et al. (US 20160105280 A1, “Kinshumann”), and further in view of Milazzo et al. (US 20170279783 A1, “Milazzo”).
Regarding claim 61: IANNACCONE, Vijayan and Kinshumann, discloses the limitations of claim 59 above.
IANNACCONE further discloses: The method of Claim 59, in which the digital asset is never sent unencrypted in the clear, such as on a cloud or internet (IANNACCONE [0024]: For example, the publishing computer system 302 can obtain public key 309 associated with the stored collateral data 307 (e.g., a distributed ledger wallet, a distributed ledger transaction) and use public key 309 for a first encryption of data (e.g., media content, a message) to be sent to one or more devices 304). Thus, IANNACCONE discloses, data is never sent unencrypted.
in which the [digital asset can only be decrypted at the device] (see paragraph [0024]),
in which the decrypted digital asset can only be handled, such as reproduced or modified, at the device (IANNACCONE [0024]: In some examples, encrypting the requested data with the subscriber's public key 309 (e.g., a public key associated with the subscriber's wallet on the distributed ledger) for delivery ensures that the data (e.g., media content, message) can only be deciphered (e.g., decrypted) by the intended recipient (e.g., subscriber) who is also in possession of the corresponding private key 310 that also unlocks the deposited collateral (e.g., enables a user to add one or more transactions to a distributed ledger transferring one or more tokens in and/or out of the distributed ledger wallet)),
in which the device cannot send the decrypted digital asset to an external device (IANNACCONE [0024]: For example, the publishing computer system 302 can obtain public key 309 associated with the stored collateral data 307 (e.g., a distributed ledger wallet, a distributed ledger transaction) and use public key 309 for a first encryption of data (e.g., media content, a message) to be sent to one or more devices 304). Thus, IANNACCONE discloses, device cannot send the decrypted digital asset. (See paragraphs [0004], [0017], [0023] and [0025]).
As indicated above, IANNACCONE discloses, receiving and decrypting the digital asset.
IANNACCONE does not specifically disclose: receiving and decrypting a NFT-linked digital asset. However, Vijayan, However, Vijayan discloses: receiving and decrypting a NFT-linked digital asset (see paragraphs [0011]-[0012], [0093] and [0096]).
Alternatively, Milazzo discloses: The method of Claim 59, in which the digital asset is never sent unencrypted in the clear, such as on a cloud or internet (see paragraphs [0073] and [0074]),
in which the [digital files e.g., digital asset] can only be decrypted at the device (Milazzo [0073]: At stage 418, the computing device associated with the consumer receives the encrypted secret key. At stage 420, the computing device associated with the consumer decrypts the secret key sent from the content provider, and in turn uses the secret key to decrypt the 3D model file), (see paragraphs [0073] and [0074]),
in which the decrypted digital asset can only be handled, such as reproduced or modified, at the device (see paragraphs [0073] and [0074]),
in which the device cannot send the decrypted digital asset to an external device (see paragraphs [0073] and [0074]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of IANNACCONE, Vijayan and Kinshumann with Milazzo to include well-known technology such as implementing additional functions of Public Key Infrastructure (PKI) and distributed ledger to enhance data and device security.
Regarding claim 68: IANNACCONE, Vijayan and Kinshumann, discloses the limitations of claim 59 above.
IANNACCONE further discloses: The method of Claim 59, in which the decrypted digital asset can be transmitted to peripherals inside the device (see paragraph [0022] and Fig. 2).
Alternatively, Milazzo discloses: The method of Claim 59, in which the decrypted digital asset can be transmitted to peripherals inside the device (see paragraphs [0073] and [0074]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of IANNACCONE, Vijayan and Kinshumann with Milazzo to include well-known technology such as implementing additional functions of Public Key Infrastructure (PKI) and distributed ledger to enhance data and device security.
Claim 67 is rejected under 35 U.S.C. 103 as being unpatentable over IANNACCONE (US 20210035090 A1, “IANNACCONE”) in view of Madhu Vijayan (US 20200005284 A1, “Vijayan”), in view of Kinshumann et al. (US 20160105280 A1, “Kinshumann”), in view of Milazzo et al. (US 20170279783 A1, “Milazzo”), and further in view of Joshua D. Hug (US 20060085352 A1, “Hug”).
Regarding claim 67: IANNACCONE, Vijayan and Kinshumann, discloses the limitations of claim 59 above.
IANNACCONE further discloses: The method of Claim 59, wherein the digital asset is a [code stored on a memory] code/file (see paragraph [0022] and Fig. 2),
wherein the device is implemented in a single System on Chip (SoC), (see paragraphs [0014], [0018] and [0024]),
[…],
wherein the encrypted digital asset is stored into a permanent memory of the device (see paragraphs [0014], [0018] and [0024]), and
[..].
Alternatively, Milazzo discloses: The method of Claim 59, wherein the digital asset is a firmware code (e.g., a tamper-resistant cryptographic module), (see paragraphs [0073]-[0074] and [0090]),
wherein the encrypted digital asset is stored into a permanent memory of the device (see paragraphs [0073]-[0074] and [0090]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of IANNACCONE, Vijayan and Kinshumann with Milazzo to include well-known technology such as implementing additional functions of Public Key Infrastructure (PKI) and distributed ledger to enhance data and device security.
IANNACCONE does not specifically disclose: creating chunks or blocks or any other form of batch of the digital asset. However, Hug discloses:
wherein the method includes the further step of creating chunks or blocks or any other form of batch of the digital asset before encrypting the digital asset (see claim 11 and paragraphs [0183]-[0184]),
wherein each chunk is decrypted and loaded on a RAM of the device on- the-fly at the SoC start up (see abstract, paragraph [0202])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of IANNACCONE, Vijayan, Kinshumann and Milazzo with Hug to include well-known technology such as implementing creating data blocks/chunks before encrypting to enhance data transmission and data security.
Claim 69 is rejected under 35 U.S.C. 103 as being unpatentable over IANNACCONE (US 20210035090 A1, “IANNACCONE”) in view of Madhu Vijayan (US 20200005284 A1, “Vijayan”), in view of Kinshumann et al. (US 20160105280 A1, “Kinshumann”), in view of Milazzo et al. (US 20170279783 A1, “Milazzo”), and further in view of Glen Alan Jaquette (US 20220182219 A1, “Jaquette”).
Regarding claim 69: IANNACCONE, Vijayan and Kinshumann, discloses the limitations of claim 59 above.
IANNACCONE does not specifically disclose, however, Jaquette discloses: The method of Claim 68, in which the maximum size of each chunk is determined by the encryption algorithm (Jaquette [0022]: a computer-implemented method includes determining that a size of a compressed instance of data is greater than a predetermined threshold; and encrypting an uncompressed instance of data utilizing wide-block encryption, without first compressing the uncompressed instance of data, to create a ciphertext string.) (see abstract and paragraphs [0022]-[0023]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of IANNACCONE, Vijayan, Kinshumann and Milazzo with Jaquette to include well-known technology such as implementing creating compressed instance of data before encrypting to enhance data transmission and data security.
Claim 71 is rejected under 35 U.S.C. 103 as being unpatentable over IANNACCONE (US 20210035090 A1, “IANNACCONE”) in view of Madhu Vijayan (US 20200005284 A1, “Vijayan”), in view of Kinshumann et al. (US 20160105280 A1, “Kinshumann”), in view of Milazzo et al. (US 20170279783 A1, “Milazzo”), in view of Glen Alan Jaquette (US 20220182219 A1, “Jaquette”), and further in view of Mohamed et al. (US 10952069 B1, “Mohamed”).
Regarding claim 71: IANNACCONE, Vijayan and Kinshumann, discloses the limitations of claim 59 above.
IANNACCONE further discloses: The method of Claim 68, in which [the digital asset] is encrypted via the [key] (see paragraphs [0004], [0014] and [0018]).
IANNACCONE does not specifically disclose, however, Mohamed discloses: digital asset is encrypted via the hybrid key (Mohamed [Col. 16, Lines 43-67]: The second scheme was suggested by Zhu and it was a hybrid algorithm that encrypts the data with AES).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of IANNACCONE, Vijayan, Kinshumann, Milazzo, Jaquette and Mohamed to include well-known cryptograph algorithm such as hybrid encryption scheme to encrypt data to enhance transmission of data and data security.
Response To: Reply To Restriction Requirement
With respect to Reply To Restriction Requirement
Applicant contends: "The Office Action is unclear. The examiner seems to identify two inventions and related groups of claims, i.e. Group I corresponding to claims 59-72 (Elected) and Group II corresponding to claim 73. However, in the last two lines of page 3, the examiner seems to indicate three possible inventions “Groups I-III”, which renders the requirement unclear. " (see pages 1-2).
The Examiner, however, respectfully disagrees. Firstly, with respect to prior arts arguments, please see the full 35 U.S.C. 103 rejection above.
Secondly, the Restriction Election Requirement Office Action (hereinafter, “Office Action”) clearly presented Group I corresponding to claims 59-72 (Elected) and Group II corresponding to claim 73 for election (see page 3, paragraph 3 of the Office Action). And with regards to the last two lines of page 3 of the Office Action, the language “Groups I-III”, it’s a typo and should have been Groups I-II. As the Groups I and II clearly presently in the Office Action for election.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAHED ALI whose telephone number is (571)270-1085. The examiner can normally be reached 8:00 - 5:00 M-F.
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, Neha Patel can be reached on (571) 270-1492. 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.
/JAHED ALI/
Examiner, Art Unit 3699
/NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699