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 . This office action is in response to the amendment filed on 11/27/2024. Claims 8-26 are currently pending in the filing of 11/27/2024, claims 1-7 from the PCT were cancelled and replaced with claims 8-26 in the present filing of 11/27/2024.
Information Disclosure Statements
The information disclosure statement(s) (IDS) submitted on 11/27/2024 have been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) have been considered by the examiner.
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.
Claims 8-21 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent claim 8 recites, “allowing decryption and consumption of the encrypted user data based on comparison of the NFT access credential and the credential string meeting a matching threshold,” and independent claim 15 recites, “allowing decryption and consumption of the encrypted asset based on a comparison of the credential indication and credential string meeting a matching threshold” (emphasis added) The examiner notes that the specification describes the “credential string” as corresponding to a web token, cookie, and/or JSON web token (JWT), (applicant’s printed publication at [0033]) which is provided to a user, after a challenge response authentication, so that the user can access content.
However, the “NFT access credential” is only described as being used to unlock the encrypted file, at [0041] of the applicant’s printed publication. Second, the term “threshold” is only described in [0006] of the applicant’s printed publication and provides no further description even when searching for the term “credential indication” which includes no further description, other than the fact that it is compared to the credential string. This leads the examiner to lack an understanding of what the NFT access credential and/or credential indication are relative to the credential string.
Thus, the examiner is unable to distinguish between 1) the “NFT access credential” and/or the “credential indication” from 2) the “credential string” and will therefore interpret the “NFT access credential” and the “credential indication” as being the same as the value “credential string” so that a comparison may be performed by the blockchain between the user’s “credential string” and the server’s “NFT access credential” and/or “credential indication”.
The examiner encourages the applicant to contact the examiner to schedule a telephone interview to discuss this matter at any time for the purpose of advancing prosecution, if the applicant wishes. Alternatively, the applicant may call the examiner at any time to briefly discuss this issue and the examiner’s interview policy, which the applicant may find helpful.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 8-11, 15-18, and 22-24 are rejected under 35 U.S.C. 103 as being unpatentable over US 20230275751 to Sneider et al. (hereinafter Sneider), in view of US 20230259640 to Metzler et al. (hereinafter Metzler).
Regarding claim 8, Sneider teaches,
A method for managing access control to a digital asset, the method comprising: ([0003-8] teach access control using blockchains and NFTs.)
receiving an indication that a non-fungible token (NFT) on a blockchain is selected to act as an authentication credential; ([0005-8] teaches blockchains using NFTs. Claim 12 explicitly teaches non-fungible token (NFT))
receiving, via a centralized node, user data; ([0007-8] teaches decentralized web that provides encryption services, permissions, to decrypt the content, such as videos, images, and music behind chain conditions such as NFTs. Abstract, teaches that the decentralized nodes are multiple nodes. [0046] teaches centralized servers. Fig. 1 teaches invention nodes 102 \ “centralized node” that connect between user and blockchain, while [0029-30] teaches a Lit node.)
causing, using the user data, the generation of encrypted user data, wherein the encrypted user data is only unlocked using an NFT access credential associated with the NFT; ([0007-8] teaches decentralized web that provides encryption services, permissions, to decrypt the content, such as videos, images, and music behind chain conditions such as NFTs. See also [0012] teaching on-chain access control conditions to encrypt and lock content behind on-chain conditions.)
causing ([0007-8] teaches decentralized web that provides encryption services, permissions, to decrypt the content, such as videos, images, and music behind chain conditions such as NFTs. Abstract, teaches that the decentralized nodes are multiple nodes, and also teaches encryption services provided by the decentralized web / blockchains. While removal / deletion is not explicitly taught in Sneider, this feature would be well known in the art of encryption where unencrypted data is erased once encryption is performed.)
receiving, via the centralized node and from a user device, an access request for the encrypted user data, wherein the access request is associated with a cryptographic wallet, ([0008] teaches a request to obtain the JWT that provisions access to dynamic content. [0012] teaches request a network signed JWT. [0022] teaches a user wanting access to a resource 104 of fig. 1, where the user signs a message using their wallet to prove ownership of the wallet, where a decryption key or network signature / JWT is provided to the user. Fig. 14 & [0064] teach requests a network signature, which signs JWT. ) Applicant’s printed publication at [0044-45] describes a string / cookie / JSON web token (JWT) that is matched to allow unlocking of streaming.)
causing a challenge request to be presented via the user device; (fig. 14 & [0069-71] teach wallet signatures are supplied using EIP 4361, which is a challenge-response where the challenge that includes a nonce is issued by the server to the user, also teaches presenting a wallet signature and AuthSig and the use of checkAndSignAuthMessage( ) function. See also [0063-67] for further description of fig. 14 and JWT acquisition including requests a network signature, which signs JWT. See also [0046] teaching “user requests and obtains a JWT using the requesting network signature process”.)
receiving a signature to the challenge, wherein the signature is generated using the cryptographic wallet; ([0070] teaches wallet signature. See discussion above of fig. 14 and [0069-71].)
providing, based on validation that the cryptographic wallet owns the NFT, a credential string to the user device; and ([0008] teaches a request to obtain the JWT that provisions access to dynamic content. [0022] teaches that [0022] teaches a user wanting access to a resource 104 of fig. 1, where the user signs a message using their wallet to prove ownership of the wallet, where a decryption key or network signature / JWT is provided to the user. See discussion above of fig. 14 & [0069-71] teaching the challenge-response using signatures. [0074] & [0082-83] teach the signed JWT errors. See also fig. 12 & [0047] example of owner Alice renting to Bob.) (See discussion above of applicant’s printed publication at [0044-45] describes a string being a JSON token / JWT)
allowing decryption and consumption of the encrypted user data based on a comparison of the NFT access credential and the credential string meeting a matching threshold. ([0008] & [0012] teach decryption of static content locked by chain conditions, where the chain conditions are NFTs and JWT provides access to content behind the chain conditions. [0058] & [0063] teach decryption based on NFT possession or ownership. [0097] teaches the use of threshold cryptographic functions in the Lit protocol)
Sneider fails to explicitly teach deletion of unencrypted data,
However, Metzler teaches,
causing removal or deletion of the unencrypted user data from the centralized node; ([0343] teaches once file has been encrypted, the encryption module 222 may delete any unencrypted copies of the file located on the client computing device 102 and/or the primary storage device 104.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Sneider, which teaches non-fungible tokens (NFTs) that are used to control access to encrypted content and JTWs that provide access to the encrypted content ([0005-9]), with Metzler, which also teaches non-fungible tokens (NFTs) being used to control access to encrypted content (Abstract), and additionally teaches once file has been encrypted, the encryption module 222 may delete any unencrypted copies of the file located on the client computing device 102 and/or the primary storage device 104 ([0343]). One of ordinary skill in the art would have been motivated to perform such an addition to provide Sneider with the added ability to delete un-encrypted content after encryption, as taught by Metzler, for the purpose of increasing security by eliminating un-encrypted content and increasing computational efficiency by removing unnecessary content from the system to preserve memory.
Regarding claim 9, Sneider and Metzler teach,
The method of claim 8, wherein the user device comprises a web browser and the credential string is stored as a token on the web browser. (Sneider, [0035] teaches that the web browser is used to delegate access using the JWT. [0067] teaches the JWT is a token.)
Regarding claim 10, Sneider and Metzler teach,
The method of claim 8, wherein the credential string comprises a first party object. (Sneider, [0029] teaches ownership being delegated by the smart contract that is identified with ETH token contract address and token id. Fig. 12 & [0047] teaches example of owner renting an asset. [0012-13] teaches JWT / “credential string” provisioning that provides access and authorization to dynamic content, including access where owners can create locked NFTs and provisioning access given only to NFT owners. [0023] teaches the JWT being used to access or grant access and update content.) (Examiner asserts that first party objects is data owned firsthand that is different than the consumer / audience.)
Regarding claim 11, Sneider and Metzler teach,
The method of claim 8, wherein the credential string comprises a first party cookie. (Sneider, [0029] teaches the token being used for authentication.) (Examiner asserts that first party cookies are well known as those used for logging into an account, such as cookies that maintain passwords or other credentials)
Regarding claim 15, Sneider and Metzler teach,
A method for managing access control to a digital asset, the method comprising:
receiving, via a node associated with a digital rights management system, an indication of a select non-fungible token (NFT) on a blockchain; (Metzler, [0003] teaches intellectual property rights in copyrighted material being controlled by NFTs)
receiving, via the node, a digital asset;
encrypting the digital asset to form an encrypted asset, wherein decryption of the encrypted asset is based on the select NFT;
storing a credential indication that the select NFT is representative of an authentication credential for the encrypted asset; ([0007-8] teaches storing of permissions and encrypted resources on a public network where NFT conditions and JWT tokens are used to access the encrypted resources.)
receiving, from a user device associated with a cryptographic wallet, a request to access the encrypted asset;
causing a challenge request to be presented via the user device;
receiving a signature to the challenge, wherein the signature is based on the cryptographic wallet;
providing, based on validation that the cryptographic wallet owns the select NFT, a credential string to the user device; and
allowing decryption and consumption of the encrypted asset based on a comparison of the credential indication and credential string meeting a matching threshold.
Claim 15 is rejected using the same basis of arguments used to reject claim 8 above.
Regarding claim 16, Sneider and Metzler teach,
The method of claim 15, wherein the user device comprises a web browser and the credential string is stored as a token on the web browser.
Claim 16 is rejected using the same basis of arguments used to reject claim 9 above.
Regarding claim 17, Sneider and Metzler teach,
The method of claim 15, wherein the credential string comprises a first party object.
Claim 17 is rejected using the same basis of arguments used to reject claim 10 above.
Regarding claim 18, Sneider and Metzler teach,
The method of claim 15, wherein the credential string comprises a first party cookie.
Claim 18 is rejected using the same basis of arguments used to reject claim 11 above.
Regarding claim 22, Sneider and Metzler teach,
A method for managing access control to a digital asset, the method comprising:
receiving, via a node associated with a digital rights management system, an indication of a select encrypted asset that is encrypted based on a select non-fungible token (NFT) on a blockchain;
receiving, from a user device associated with a cryptographic wallet, a request to access the encrypted asset;
causing a challenge request to be presented via the user device;
receiving a signature to the challenge, wherein the signature is based on the cryptographic wallet;
validating, based on the signature, that a user owns a select non-fungible token; and
allowing decryption and consumption of the encrypted digital asset based on the validating that a user owns a select non-fungible token.
Claim 22 is rejected using the same basis of arguments used to reject claim 8 & 15 above.
Regarding claim 23, Sneider and Metzler teach,
The method of claim 22, wherein the user device comprises a web browser and the credential string is stored as a token on the web browser.
Claim 23 is rejected using the same basis of arguments used to reject claim 9 above.
Regarding claim 24, Sneider and Metzler teach,
The method of claim 22, wherein the credential string comprises a first party cookie.
Claim 24 is rejected using the same basis of arguments used to reject claim 11 above.
Claims 12-14, 19-21, and 25-26 are rejected under 35 U.S.C. 103 as being unpatentable over Sneider, in view of Metzler, in view of US 20230368296 to Hara (hereinafter Hara).
Regarding claim 12, Sneider and Metzler teach,
The method of claim 8,
wherein the user device comprises a web browser and wherein causing a challenge request to be presented via the user device . (Sneider, [0068-69] teaches the use of HTML and scripts, where SKD uses the JWT. [0069-71] teach the signature authentication request / “challenge request”. [0025] teaches the use of browsers. See also rejection of claim 8 above.)
Sneider and Metzler fail to explicitly teach the use of browser extensions,
However, Hara teaches,
wherein the user device comprises a web browser and wherein causing a challenge request to be presented via the user device is implemented via a browser extension. ([0002] teaches user may enable a third-party extension to a web browser, where the third-party extension is used to process a blockchain transaction on web content rendered by the web browser. Fig. 1 & [0095-97] teaches digital asset holder 102 is a browser extension, where the user initiates a transaction that is authenticated with a signature by the digital asset holder. [0126] teaches the digital asset holder / “browser extension” that holds lists of assets / NFTs and signs to authenticate the transaction.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Sneider, which teaches non-fungible tokens (NFTs) that are used to control access to encrypted content and JTWs that provide access to the encrypted content ([0005-9]), with Metzler, which also teaches non-fungible tokens (NFTs) being used to control access to encrypted content (Abstract), and additionally teaches once file has been encrypted, the encryption module 222 may delete any unencrypted copies of the file located on the client computing device 102 and/or the primary storage device 104 ([0343]), with Hara, which also teaches performing the NFT blockchain transactions including signature authentication ([0002-4]), and additionally teaches the use of browser extensions to perform the NFT blockchain transactions including signature authentication ([0002-4]). One of ordinary skill in the art would have been motivated to perform such an addition to provide Sneider and Metzler with the added ability to utilize browser extensions to perform NFT transactions on a blockchains including authentication using signatures, as taught by Hara, for the purpose of increasing security and computational efficiency by utilizing browser extensions for blockchain transactions.
Regarding claim 13, Sneider and Metzler teach,
The method of claim 8,
wherein the user device comprises a web browser and wherein receiving a signature to the challenge . (Sneider, [0068-69] teaches the use of HTML and scripts, where SKD uses the JWT. [0069-71] teach the signature authentication request / “challenge request”. [0025] teaches the use of browsers. See also rejection of claim 8 above.)
Sneider and Metzler fail to explicitly teach the use of browser extensions,
However, Hara teaches,
wherein the user device comprises a web browser and wherein receiving a signature to the challenge is implemented via a browser extension. ([0002] teaches user may enable a third-party extension to a web browser, where the third-party extension is used to process a blockchain transaction on web content rendered by the web browser. Fig. 1 & [0095-97] teaches digital asset holder 102 is a browser extension, where the user initiates a transaction that is authenticated with a signature by the digital asset holder. [0126] teaches the digital asset holder / “browser extension” that holds lists of assets / NFTs and signs to authenticate the transaction.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Sneider, which teaches non-fungible tokens (NFTs) that are used to control access to encrypted content and JTWs that provide access to the encrypted content ([0005-9]), with Metzler, which also teaches non-fungible tokens (NFTs) being used to control access to encrypted content (Abstract), and additionally teaches once file has been encrypted, the encryption module 222 may delete any unencrypted copies of the file located on the client computing device 102 and/or the primary storage device 104 ([0343]), with Hara, which also teaches performing the NFT blockchain transactions including signature authentication ([0002-4]), and additionally teaches the use of browser extensions to perform the NFT blockchain transactions including signature authentication ([0002-4]). One of ordinary skill in the art would have been motivated to perform such an addition to provide Sneider and Metzler with the added ability to utilize browser extensions to perform NFT transactions on a blockchains including authentication using signatures, as taught by Hara, for the purpose of increasing security and computational efficiency by utilizing browser extensions for blockchain transactions.
Regarding claim 14, Sneider and Metzler teach,
The method of claim 8,
wherein the user device comprises a web browser and wherein providing, based on validation that the cryptographic wallet owns the NFT, a credential string to the user device. (Sneider, [0068-69] teaches the use of HTML and scripts, where SKD uses the JWT. [0069-71] teach the signature authentication request / “challenge request”. [0025] teaches the use of browsers. See also rejection of claim 8 above.)
Sneider and Metzler fail to explicitly teach the use of browser extensions,
However, Hara teaches,
wherein the user device comprises a web browser and wherein providing, based on validation that the cryptographic wallet owns the NFT, a credential string to the user device is implemented via a browser extension. ([0002] teaches user may enable a third-party extension to a web browser, where the third-party extension is used to process a blockchain transaction on web content rendered by the web browser. Fig. 1 & [0095-97] teaches digital asset holder 102 is a browser extension, where the user initiates a transaction that is authenticated with a signature by the digital asset holder. [0126] teaches the digital asset holder / “browser extension” that holds lists of assets / NFTs and signs to authenticate the transaction. [0062-63] teaches the use of a wallets to protect user information while performing blockchain transactions, and also teaches the use of JTW as credentials. [0144] teaches the use of JSON messages with the extension.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Sneider, which teaches non-fungible tokens (NFTs) that are used to control access to encrypted content and JTWs that provide access to the encrypted content ([0005-9]), with Metzler, which also teaches non-fungible tokens (NFTs) being used to control access to encrypted content (Abstract), and additionally teaches once file has been encrypted, the encryption module 222 may delete any unencrypted copies of the file located on the client computing device 102 and/or the primary storage device 104 ([0343]), with Hara, which also teaches performing the NFT blockchain transactions including signature authentication ([0002-4]), and additionally teaches the use of browser extensions to perform the NFT blockchain transactions including signature authentication ([0002-4]) and wallets ([0062-63]). One of ordinary skill in the art would have been motivated to perform such an addition to provide Sneider and Metzler with the added ability to utilize browser extensions to perform NFT transactions on a blockchains including authentication using signatures and wallets, as taught by Hara, for the purpose of increasing security and computational efficiency by utilizing browser extensions for blockchain transactions.
Regarding claim 19, Sneider, Metzler, and Hara teach,
The method of claim 15, wherein the user device comprises a web browser and wherein causing a challenge request to be presented via the user device is implemented via a browser extension.
Claim 19 is rejected using the same basis of arguments used to reject claim 12 above.
Regarding claim 20, Sneider, Metzler, and Hara teach,
The method of claim 15, wherein the user device comprises a web browser and wherein receiving a signature to the challenge is implemented via a browser extension.
Claim 20 is rejected using the same basis of arguments used to reject claim 13 above.
Regarding claim 21, Sneider, Metzler, and Hara teach,
The method of claim 15, wherein the user device comprises a web browser and wherein providing, based on validation that the cryptographic wallet owns the NFT, a credential string to the user device is implemented via a browser extension.
Claim 21 is rejected using the same basis of arguments used to reject claim 14 above.
Regarding claim 25, Sneider, Metzler, and Hara teach,
The method of claim 22, wherein the user device comprises a web browser and wherein causing a challenge request to be presented via the user device is implemented via a browser extension.
Claim 25 is rejected using the same basis of arguments used to reject claim 12 above.
Regarding claim 26, Sneider, Metzler, and Hara teach,
The method of claim 22, wherein the user device comprises a web browser and wherein receiving a signature to the challenge is implemented via a browser extension.
Claim 26 is rejected using the same basis of arguments used to reject claim 13 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRIAN WILLIAM AVERY whose telephone number is (571) 272-3942. The examiner can normally be reached on 9AM-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on (571) 272-3739.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/B.W.A./
/JASON K GEE/Primary Examiner, Art Unit 2495