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 .
Response to Arguments
In the remarks filed on 07/16/2026. The applicant amended claims 1-3, and 13-18 are amended. Claims 21-23 were added. Claims 4-12 and 19-20 are cancelled.
With respect to 112(f):
Applicant’ claim amendments and remarks filed on 07/16/2026 have been fully considered and overcome 112(f) as presented in the non-final office action filed 06/29/2026.
With respect to 112(b) rejections:
Applicant’ claim amendments and remarks filed on 07/16/2026 have been fully considered and have overcome some of the 112(b) rejections but not all of the 112(b) rejections as presented in the non-final office action filed 06/29/2026.
Regarding claim 3 112(b) rejection, Applicant argues that claim 3 need not recite the specific manner in which the depth information is used. However, the rejection is not based on a lack of implementation detail, but on the unclear meaning of when the content information is considered “valid”. The claim does not identify what relationship or result involving the depth information establishes validity. Accordingly, Applicant’s argument does not overcome the rejection.
With respect to 35 U.S.C. § 103 rejections:
Applicant's arguments filed on 07/16/2026 have been received and entered.
Applicant's arguments with respect to the newly amended independent claims, see Applicant Arguments 6-10, with respect to the rejection (s) of independent claims 1,13 and 21 have been fully considered.
Applicant argues that Testagrossa and Yantis alone or in combination fail to disclose or suggest generating an NFT issuance transaction that requests issuance of an NFT, executing the NFT issuance transaction, and supplying the NFT issuance transaction to device that requests issuance of the NFT. Applicant further contends that OA improperly treats general NFT minting or token management functionality as necessarily encompassing Applicant’s specifically recited NFT issuance transaction operations. Examiner understands applicant’s perspective, as an initial matter, the limitations now incorporated into amended claim 1 concerning generating, executing, and supplying an NFT issuance transaction were previously recited in dependent claims 4-6 and were separately considered and addressed in the prior Office Action. Thus, the amendment changes the scope of the claims and thus necessities the new ground of rejection as presented below.
Regarding applicant’s argument on claim 13, Applicant argues that Yantis and Goeringer fail to teach the limitation of claim 13 requiring “generating a content information file that stores the content information and a blockchain address corresponding to the user” In Particular, Applicant argues that Yantis merely describes generation of item information and virtual representations, while Goeringer separately describes various blockchain related concepts, and the office has improperly relied upon Applicant’s disclosure as a roadmap for combining these teachings. Applicant’s argument have been considered but are not persuasive. As set forth in the rejection, Yantis teaches generating content information according to an operation of a user. In particular, Yantis teaches that seller/user may provide item attributes and media content through a graphical user interface and, in response to the item management system, generates a virtual representation of the item. Yantis further teaches that the virtual representation may constitute a data record containing the attributes of the item, including media content, see Yantis [0838,0841,0869]. Thus, Yantis teaches generating the claimed content information to an operation of the user.
Although Yantis does not expressly teach storing a block chain address corresponding to the user in the generated contentment information record, Goeringer teaches the unknown technique of storing digital content together with identifying information associated with the user/owner and employing blockchain related information to establish the provenance and ownership of that content. Specifically, Goeringer [0157] teaches capturing contextual information associated with an image, including a “user or owner ID”, and storing such contextual information with image metadata. Goeringer [0158] further teaches saving a signed image “as a file package together with the image metadata.” Goeringer [0163] additionally teaches incorporating owner identifying information, including an “owner certificate or other account credentials” into the image hash, encoding that information into the image format, and adding the hash to the metadata. Goeringer further expressly teaches use of a blockchain address corresponding to a particular address corresponding to a particular content seller/user. Specifically, Goeringer, [0140] teaches that content purchase data may include “a blockchain address for the seller.” Thus, Goeringer does not merely disclose a generic network or hardware address, but expressly identifies a blockchain address associated with the seller of the content.
Accordingly, the rejection does not merely rely on an interpretation under which separately stored content information and a separately stored blockchain address, standing alone satisfy the claimed content information file. Rather, the rejection relies on the combined teachings of Yantis and Goeringer. Yantis supplies the generated virtual representation/data record containing the user provided content information, while Goeringer teaches the technique of incorporating user/owner identifying information with digital content and its metadata in a file package and expresses a blockchain address corresponding to the content seller. It would therefore have been obvious to one of ordinary skill in the art to modify Yantis generated virtual representation/data record to further store the blockchain address corresponding to the seller/user as taught by Goeringer, such that the resulting content information and the blockchain address corresponding to the user. Such modification would have constituted application of Goreringer’s known content identification and blockchain provenance technique to Yantis’s digital content record and would have yielded the predictable result of maintaining an identifiable association between the digital content as its creator, owner, or seller. Thus, the combination of Yantis and Goeringer teaches generating a content information file that stores the content information and a blockchain address corresponding to the user as recited in claim 13. Hence, Applicant’s argument do not overcome the rejection and 103 rejection has been maintained.
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.
Claim 3 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 3 recites “whether the content information is valid using depth information”. The phrase fails to provide objective boundaries for the claim. The claim does not specify what condition makes the content information “valid”. What comparison or test is performed using the depth information, or what result indicates validity. Although the specification describes using depth information to determine whether a captured image has been counterfeited, the claims do not recite that validity means non counterfeiting correspondence between a captured image and depth information. Examiner suggest applicant to clarify the scope of the claims. Dependent claims are also rejected for inheriting the deficiencies set forth above for independent claims. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, and 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Testagrossa (US 20220345316 A1) in view of Wentworth (US 20210103582 A1)in further view of Yantis (US 20220058636 A1).
Regarding claim 1, Testgrossa teaches an information processing device comprising: a memory storing a program, and at least one processor configured to execute the program to perform operations comprising (Testagrossa, one or more components of the system 100 are implemented on one or more digital devices…. Examples of digital devices include a computer, a tablet, a laptop, a desktop, a netbook.., [0037]):
performing a verification unit that performs verification of whether content information has been tampered with using an electronic signature (Testagrossa, obtain, via the metadata pointer, metadata associated with the physical asset, the metadata including a cryptographic signature.. authenticate the cryptographic signature against the public authentication key and verify whether the hash digest is a cryptographic hash of the metadata obtained via the metadata pointer to obtain an authentication result for the physical asset,[0010] Failure of the authentication of the digital signature 132 may indicate that the metadata 124 has been tampered with, [0049]) [Examiner interprets that system verifying whether that information has been tampered with by authenticating a cryptographic/digital signature and checking has digest as limitation above, The verification unit reads on trusted application 117/authentication page 119 authenticating cryptographic signature and hash of metadata]; and
furthering a request for ana request unit that requests issuance of a non-fungible token (NFT) corresponding to the content information in a case where it is determined as a result of the verification that the content information has not been tampered with (Testagrossa, the method further includes minting the NFT in response to the verification result indicating that the first computing device was located at the particular location, subject to the additional conditions, [0013] the second computing device is further configured to mint the NFT in response to the verification result indicating that the first computing device was located at the particular location, subject to the additional conditions, [0014] If both the authentication of the digital signature 132 and the verification of the hash digest 109 succeed, then the authentication result is affirmative. If either or both of the authentication of the digital signature 132 or the verification of the hash digest 109 fail, then the authentication result is negative. Failure of the authentication of the digital signature 132 may indicate that the metadata 124 has been tampered with, [0049]) [Examiner interprets that system minting NFT in response to the verification result being affirmative as limitation above, The requesting unit reads on smart contract /NFT minting functionality triggered after verification];
Testagrossa does not appear to explicitly teach:
generating an NFT issuance transaction that requests issuance of the NFT; executing the NFT issuance transaction; and supplying the NFT issuance transaction to a device that requests the issuance of the NFT. Verifying the content information (in light of specification, the content information being digital contents such as images) and requests issuance of a non- fungible token (NFT) corresponding to the content information
However, Wentworth teaches:
generating an NFT issuance transaction that requests issuance of the NFT (Wentworth, Write calls generate a blockchain transaction that must be signed, submitted to blockchain 120 through node module 254, and included in a block based on a consensus algorithm of blockchain 120). Once a transaction is included in blockchain 120, the state of blockchain 120 has been updated to reflect the effects of the write call, [0056] Decode the function call parameters and create an unsigned transaction, [0166] The following sample transaction calls the mint( ) smart contract function and requests MultiBaas to sign it with an HSM address. TABLE-US-00039 Request POST .../chains/ethereum/addresses/autotoken/contracts/mltitoken/methods/mint … }, ″submitted″: true, ″summarizedInputs″: [ null ] } }, [0179]) [examiner interprets that system requesting write calls mint () and generating blockchain transaction for executing the mint operation as limitation above];
executing the NFT issuance transaction (Wentworth, Write calls generate a blockchain transaction that must be signed, submitted to blockchain 120 through node module 254, and included in a block based on a consensus algorithm of blockchain 120). Once a transaction is included in blockchain 120, the state of blockchain 120 has been updated to reflect the effects of the write call, [0056] The following sample transaction calls the mint( ) smart contract function and requests MultiBaas to sign it with an HSM address. TABLE-US-00039 Request POST .../chains/ethereum/addresses/autotoken/contracts/mltitoken/methods/mint … }, ″submitted″: true, ″summarizedInputs″: [ null ] } }, [0179] Note in the response that “submitted: true” indicates that server(s) 202 has signed and submitted the transaction to the blockchain. The unsigned transaction is also returned as a convenience, [0180] When the last required signer submits their approval transaction, the resulting original transaction is executed, [0188]) [Examiner interprets that system generating mint transaction, signing transaction, submitting transaction to blockchain, including/processing transaction and ching the state of block chain as limitation above]; and
supplying the NFT issuance transaction to a device that requests the issuance of the NFT (Wentworth, Returning to FIG. 2, REST API module 250 is operative to create and execute a RESTful API for communications between a user device 110 (FIG. 1) and Server(s) 202 of interface platform 200….Write calls generate a blockchain transaction that must be signed, submitted to blockchain 120 through node module 254, and included in a block based on a consensus algorithm of blockchain 120). Once a transaction is included in blockchain 120, the state of blockchain 120 has been updated to reflect the effects of the write call, [0056] The response is an unsigned transaction which can be signed and submitted to the blockchain as shown below. TABLE-US-00014 { “status”: 200, “message”: “Success”, “result”:…, [0066] The following sample transaction calls the mint( ) smart contract function and requests MultiBaas to sign it with an HSM address. TABLE-US-00039 Request POST .../chains/ethereum/addresses/autotoken/contracts/mltitoken/methods/mint … }, ″submitted″: true, ″summarizedInputs″: [ null ] } }, [0179] Note in the response that “submitted: true” indicates that server(s) 202 has signed and submitted the transaction to the blockchain. The unsigned transaction is also returned as a convenience, [0180]) [Examiner interprets that system returning the transaction to a device that request the mint request as limitation above].
Examiner Notes: Testagrossa supplies the NFT context; Wentworth is being relied upon for the known transaction/API mechanism used to implement the smart contract mint operation.
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Testagrossa to include a concept of generating an NFT issuance transaction that requests issuance of the NFT; executing the NFT issuance transaction; and supplying the NFT issuance transaction to a device that requests the issuance of the NFT as taught by Wentworth for the purpose of improving the efficiency of a computing device creating an API in the manner [Wentworth:0051].
Although, Testagrossa teaches verifying metadata describing the physical asset with electronic signature and issuing NFT based on the verification result, Testagrossa and Wentworth do not explicitly teach:
Verifying the content information (in light of specification, the content information being digital contents such as images) and requests issuance of a non- fungible token (NFT) corresponding to the content information
However, Yantis teaches:
Verifying the content information and requests issuance of a non- fungible token (NFT) corresponding to the content information (Yantis, receiving, by a processing system, a request to tokenize an item, receiving, by the processing system, one or more photographs of the item, receiving, by the processing system, item information corresponding to the item includes a description of the item, generating, by the processing system, a virtual representation of the item based on the one or more photographs and the item information, requesting, by the processing system, an authentication of the item via a portal that is accessible by subject-matter authentication experts, wherein the portal displays the virtual representation of the item in the portal, receiving, by the processing system, an authentication report from a subject-matter authentication expert includes an opinion indicating whether the subject-matter authentication expert deemed the item authentic or not-authentic and one or more reasons for the opinion, and in response to an opinion indicating that the item is deemed authentic, generating a digital token based on a virtual representation of the item and assigning an ownership of the token to an owner of the item, [0472] he platform 100 generates a set of tokens corresponding to the number of items available for transaction. For example, if the seller indicates that there are 100 Model X widgets available for sale, the platform 100 may generate a virtual representation of the Model X widget and may generate 100 non-fungible tokens corresponding to the virtual representation, whereby each token corresponds to a respective instance of the virtual representation, [0847] a tokenization request is received from a user device. At 1404, item information is received. In some embodiments, the item information may be provided by a user or via an automated processes. At 1406, a virtual representation of the item is generated, [0978] the platform may generate a digital token in response to an opinion indicating that the item is deemed authentic, and ownership of the digital token assigned to an owner of the item. The digital token may be based on a virtual representation of the item, [0979]) [Examiner interprets that system receiving photograph and item information, generating virtual representation from that information, and authenticating the item through the authentication process as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Testagrossa and Wentworth to include a concept of Verifying the content information and requests issuance of a non- fungible token (NFT) corresponding to the content information as taught by Yantis for the purpose of generating a digital token in response to an opinion indicating that the item is deemed authentic, and ownership of the digital token assigned to an owner of the item [Yantis:0979].
Regarding claim 2, Testagrossa, Wentworth, and Yantis teaches the information processing device according to claim 1, wherein the operations further comprise: performing a verification of whether metadata of the content information has been tampered with using the electronic signature (Testagrossa, the asset metadata 124 may include a digital signature 132 associated with the physical asset 102 (e.g., a cryptographic signature of the unique identifier 130), [0034] If both the authentication of the digital signature 132 and the verification of the hash digest 109 succeed, then the authentication result is affirmative. If either or both of the authentication of the digital signature 132 or the verification of the hash digest 109 fail, then the authentication result is negative. Failure of the authentication of the digital signature 132 may indicate that the metadata 124 has been tampered with, [0049]0 [Examiner interprets system verifying metadata tampering using a digital/cryptographic signature as limitation above].
Regarding claim 3, Testagrossa, Wentworth, and Yantis teaches the information processing device according to claim 1, wherein the operations further comprise: performing a verification of whether the content information is valid using depth information corresponding to the content information (Yantis, the validation system includes an image capture system configured to capture a set of attributes of the item, [0510] the expert performs the authentication and/or appraisal based on the information uploaded by the user (e.g., one or more high resolution photographs of the virtual item, a 3D representation of the item, dimensions of the item, a weight of the item, and/or the like). The expert may provide an appraisal value and/or a determination indicating the authenticity of the item, [0943] the subject-matter expert may be presented with an image of the item, a description of the item (e.g., weight, dimensions, etc.), a video of the item, and/or the like. An authentication report may then be received by the processing system. The authentication report may be provided by a subject-matter authentication expert, which may include an opinion indicating whether the subject-matter authentication expert deemed the item authentic or not-authentic and one or more reasons for the opinion. In some embodiments, the platform may generate a digital token in response to an opinion indicating that the item is deemed authentic, and ownership of the digital token assigned to an owner of the item. The digital token may be based on a virtual representation of the item, [0979]) [Examiner interprets that system verifying authenticity using item such as images, 3D representations, dimensions, and other captured attributes as limitation above].
Regarding claim 21-23, Claims 21-23 recite commensurate subject matter as claims 1-3. Therefore, they are rejected for the same reasons.
Claims 13-18 are rejected under 35 U.S.C. 103 as being unpatentable over Yantis (US 20220058636 A1) in further view of Goeringer (US 20170206523 A1).
Regarding claim 13, Yantis teaches an information processing device comprising:
a memory storing a program, and at least one processor configured to execute the program to perform operations comprising (Yantis, The processor, or any machine utilizing one, may include non-transitory memory that stores methods, codes, [0992]):
generating content information according to an operation of a user (Yatis, the seller of an item (or any other suitable user) may access the platform 100 to define a virtual representation of the item that the seller is offering for transaction. The virtual representation of the item may include information that identifies the item (e.g., a serial number corresponding to the item, a model number of the item, and the like), information relating to the item (e.g., a classification of the item, textual descriptions, images, audio, video, virtual reality data, augmented reality data, and the like), and/or code that may be used to facilitate or verify transactions involving the item (e.g., smart contracts), [0838] The first graphical user interface may allow a user associated with a seller to offer items for sale and to create new virtual representations corresponding to the items for sale. The second user interface may allow users to purchase tokens corresponding to items for sale, to transfer tokens, and/or redeem tokens, [0841] In response to the seller providing the item attributes, the item management system 202 may generate a virtual representation of the item. In embodiments, the virtual representation may be a data record that includes the attributes of the item. In the scenario where the virtual representation was previously defined, the seller may select the previously defined item and may update one or more attributes. For example, the seller may provide additional media contents, may alter the price, and/or may update the number of items that are available. Whether an updated virtual representation or a newly defined virtual representation, the item management system 202 may output the virtual representation to the ledger management system 104, where the ledger management system 104 may tokenize instances of the virtual representation to obtain a set of tokens, [0869]) [Examiner interprets that system generating content information such as virtual representation/item information/media content when the seller/user enter item attributes/media through the GUI (i.e., operation of a user) through the GUI as limitation above]; and
Yatis does not appear explicitly teach:
generating a content information file that stores the content information and a blockchain address corresponding to the user
However, Goeringer teaches:
generating a content information file that stores the content information and a blockchain address corresponding to the user (Goeringer, Captured image 2206 is input to a signature subprocess 2208, which then outputs a signed image 2210 to storage subprocess 2212, which saves (or alternatively transmits) signed image 2210 as a file package together with the image metadata, [0158] In step S1314, content publisher 1302 transmits a blockchain address and/or currency cost to electronic device 1308. [0119] purchase transaction 1702 is created by user electronic device 1510 (e.g., through a software application) to purchase content from content creator 1502. Once purchase transaction and 1002 is initiated, a license server (not shown) of DRM 1512 verifies that user electronic device 1510 initiated purchase transaction 1702. Content creator 1502 then creates a purchaseToken, which may include one or more of an asset ID, content rights, a public key of user electronic device 1510, a user authentication token, a signature of content creator 1502, and a public key of content creator 1502, [0135] In step S1808, retailer 1508 receives content purchase data from content creator 1502. In an exemplary embodiment, the content purchase data includes one or more of a URL for CDN 1708, a URL for DRM 1512, a blockchain address for the seller, a purchase price for the packaged content, and the purchase token, [0140] image hash 2216 includes, without limitation, one or more of the hash of the unprocessed image, the hardware certificate of device 2202, the hardware address (e.g., in an embodiment where image capture device 2202 is networked), the owner certificate or other account credentials, a timestamp.. Once encoded, the hash is added to metadata, [0163] an image hash (e.g., hash 2216, 2218, or 2220, FIG. 22) is submitted as a transaction 2408 to registry 2404 for ID certification and/or image registration, [0179] registry 2404 further serves to function as a certification server, and is configured to associate registered images with an appropriate user or device certificate, [0180] a blockchain is implemented to cryptographically assure the authenticity of the asset, its time of commit/creation, its creator/owner, and rights associated with the asset, [0187]) [Examiner interprets that storing ownership/account credentials and certificates with image hash/metadata as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Yantis to include a concept of generating a content information file that stores the content information and a blockchain address corresponding to the user as taught by Goeringer for the purpose of integrating cryptographic processes to digital asset creation and processing systems (e.g., cameras, audio/audiovisual recorders, content creation and editing software, content processors, etc.) to provide more secure content distribution and stronger provenance to the digital content, [Goeringer :0152] and cryptographically assuring the authenticity of the asset, its time of commit/creation, its creator/owner, and rights associated with the asset, [Goeringer :0187].
Regarding claim 14, Yatis and Goeringer teaches the information processing device according to claim 13, wherein the operations further comprise: storing the content information and an electronic signature corresponding to the blockchain address in the content information file (Goeringer, Captured image 2206 is input to a signature subprocess 2208, which then outputs a signed image 2210 to storage subprocess 2212, which saves (or alternatively transmits) signed image 2210 as a file package together with the image metadata, [0158] a hash is used as a digital signature, utilized throughout process 2200, and which is also registered with a blockchain, for example, in order to for the owner of captured image 2206 to more demonstrably prove existence of a captured image, and still further more reliably assert ownership, [0159] one or more of the created digital signatures are embedded into the image file using encoding or steganography methods. In some embodiments, the digital signature(s) is also included in the metadata, [0165] An encryption subprocess 2312 then encrypts signed image 2310 and outputs encrypted image data 2314 to storage subprocess 2316, which saves (or alternatively transmits) encrypted image data 2314 as an encrypted file package together with the image metadata, [0168] the digital signing/cryptographic hashing of the asset onboard the digital asset capture/creation device prior to storage; (iii) the registration of the asset using a secure transactional database or distributed ledger such as a blockchain; (iv) the combination of metadata with the cryptographic hash that more reliably demonstrates ownership, [0200]) [Examiner interprets that system digitally signing the captured asst with cryptographic hash, outputting signed image to storage, saving signed image as a file package with metadata, and embedding the created digital signatures into the image file or including them in metadata, and the signatures/hash is registered with the blockchain and associated with the asset’s user/device/owner identity as limitation above] Same motivation applies as claim 13.
Regarding claim 15, Yatis and Goeringer teaches the information processing device according to claim 13, wherein the operations further comprise: storing a certificate including a public key corresponding to a private key unique to the information processing device in the content information file (Goeringer, Such cryptographic implementation may utilize certifications for the device, and/or for the user of the device, that assert strong device and/or personal identity, respectively… metadata may be registered using a secure transactional database or distributed ledger such as a blockchain, [0150] capture of contextual information relating to a captured image 2206, including without limitation, a time and date of capture, a camera ID (e.g., from a device certificate), a user or owner ID…[0157] Captured image 2206 is input to a signature subprocess 2208, which then outputs a signed image 2210 to storage subprocess 2212, which saves (or alternatively transmits) signed image 2210 as a file package together with the image metadata, [0158] the hardware ID is a cryptographic device certificate, such as X.509, or alternatively, a GSMA-based identity… the metadata, and image hash 2216 and/or signature hashes 2218, 2220 may include the location information from the GPS. Subsequent assertion of ownership rights may be further reinforced and/or strengthened if one or more of the hashes further includes an owner ID, which may also be a cryptographic certificate, [0162] one or more of the hash of the unprocessed image, the hardware certificate of device 2202, the hardware address (e.g., in an embodiment where image capture device 2202 is networked), the owner certificate or other account credentials.. image hash 2216 is created at the time of image capture (e.g., operation of image capture subprocess 2204), and may then be included, by hashing subprocess 2214, as a portion of the processing (e.g., signature subprocess 2208) by any and all of the processing components of image capture device 2202, to be encoded into the image format that is subsequently and/or transmitted in storage subprocess 2212. Once encoded, the hash is added to metadata., [0163] one or more of the created digital signatures are embedded into the image file using encoding or steganography methods, the digital signature(s) is also included in the metadata, [0165] the digital signature and encryption utilize certificate-based identity management (e.g., X.509), SHA-256, ECC based PKI, and AES-128 which may be enabled by one or more TPMs to better ensure security, [0194]) [Examiner interprets that system teaching signed image/content file package whose metadata /hash includes a hardware/device certificate, owner certificate/credentials, and PKI based cryptographic identity information where that certificate information is encoded into the image format/or metadata of the file as limitation above] Same motivation applies as claim 13.
Regarding claim 16, Yatis and Goeringer teaches the information processing device according to claim 13, wherein the operations further comprise: generating depth information corresponding to the content information, and storing the depth information in the content information file (Yatis generating a virtual representation of the item based on the item attributes, wherein the virtual representation is a data structure that stores the item attributes, [0006] the validation system includes an image capture system configured to capture a set of attributes of the item, [0510] the seller of an item (or any other suitable user) may access the platform 100 to define a virtual representation of the item that the seller is offering for transaction. The virtual representation of the item may include information that identifies the item (e.g., a serial number corresponding to the item, a model number of the item, and the like), information relating to the item (e.g., a classification of the item, textual descriptions, images, audio, video, virtual reality data, augmented reality data, and the like), and/or code that may be used to facilitate or verify transactions involving the item (e.g., smart contracts). In some embodiments, the platform may “tokenize” an item on behalf of a seller of the item by generating a set of tokens based on the virtual representation of the item and storing the tokens and associated metadata in a cryptographically secure distributed ledger, thereby making the tokens (and the virtual representation) verifiable, transferable, and trackable, [0838] The user may provide an item classification (e.g., a baseball card, vintage clothing, jewelry, artwork, or the like), and one or more of: one or more high resolution photographs of the virtual item; a 3D representation of the item; dimensions of the item; a weight of the item; and/or the like, Once an expert wins a bid, the expert performs the authentication and/or appraisal based on the information uploaded by the user (e.g., one or more high resolution photographs of the virtual item, a 3D representation of the item, dimensions of the item, a weight of the item, and/or the like). The expert may provide an appraisal value and/or a determination indicating the authenticity of the item. [0943]) [Examiner interprets that system generating /using 3D representations, images captured with its attributes, dimensions (i.e., depth related attributes) corresponding to the item/content as limitation above].
Regarding claim 17, Yatis and Goeringer teaches the information processing device according to claim 13, wherein the operations further comprise: requesting verification of the content information and issuance of a non-fungible token (NFT) corresponding to the content information by transmitting the content information file to another device (Yantis, generating, by the processing system, a virtual representation (i.e., the content information) of the item based on the one or more photographs and the item information, requesting, by the processing system, an authentication of the item via a portal that is accessible by subject-matter authentication experts, wherein the portal displays the virtual representation of the item in the portal, receiving, by the processing system, an authentication report from a subject-matter authentication expert includes an opinion indicating whether the subject-matter authentication expert deemed the item authentic or not-authentic and one or more reasons for the opinion, and in response to an opinion indicating that the item is deemed authentic, generating a digital token based on a virtual representation of the item and assigning an ownership of the token to an owner of the item, [0472] the platform 100 may generate a virtual representation of the Model X widget and may generate 100 non-fungible tokens corresponding to the virtual representation, [0847] the authentication system 804 presents a portal that allows a user (e.g., a seller or an employee of a facility that holds items) to upload a virtual representation of an item, The user may provide an item classification (e.g., a baseball card, vintage clothing, jewelry, artwork, or the like), and one or more of: one or more high resolution photographs of the virtual item; a 3D representation of the item; dimensions of the item; a weight of the item the expert performs the authentication and/or appraisal based on the information uploaded by the user [0943] At 1402, a tokenization request is received from a user device. At 1404, item information is received. In some embodiments, the item information may be provided by a user or via an automated processes. At 1406, a virtual representation of the item is generated. At 1408, the authenticity of the item is determined through suitable authentication process.. the platform may generate a digital token in response to an opinion indicating that the item is deemed authentic, and ownership of the digital token assigned to an owner of the item. The digital token may be based on a virtual representation of the item, [0978-0979]) [Examiner interprets that user/device uploading the virtual representation /data record/photos/item information to the tokenization/authentication platform, requesting authentication, and generating a token (NFT) in response to authenticity as limitation above].
Regarding claim 18, Yatis and Goeringer teaches the information processing device according to claim 13, wherein the operations further comprise: capturing an image of a subject according to an operation of the user; generating the captured image as the content information (Yatis, the seller of an item (or any other suitable user) may access the platform 100 to define a virtual representation of the item that the seller is offering for transaction. The virtual representation of the item may include information that identifies the item (e.g., a serial number corresponding to the item, a model number of the item, and the like), information relating to the item (e.g., a classification of the item, textual descriptions, images, audio, video, virtual reality data, augmented reality data, and the like), and/or code that may be used to facilitate or verify transactions involving the item (e.g., smart contracts), [0838] The first graphical user interface may allow a user associated with a seller to offer items for sale and to create new virtual representations corresponding to the items for sale. The second user interface may allow users to purchase tokens corresponding to items for sale, to transfer tokens, and/or redeem tokens, [0841] In response to the seller providing the item attributes, the item management system 202 may generate a virtual representation of the item. In embodiments, the virtual representation may be a data record that includes the attributes of the item. In the scenario where the virtual representation was previously defined, the seller may select the previously defined item and may update one or more attributes. For example, the seller may provide additional media contents, may alter the price, and/or may update the number of items that are available. Whether an updated virtual representation or a newly defined virtual representation, the item management system 202 may output the virtual representation to the ledger management system 104, where the ledger management system 104 may tokenize instances of the virtual representation to obtain a set of tokens, [0869]) [Examiner interprets that system generating content information such as virtual representation/item information/media content when the seller/user enter item attributes/media through the GUI (i.e., operation of a user) through the GUI as limitation above]; and
Yatis does not explicitly teach:
generating as the content information file, an image file that stores the captured image and the blockchain address
However, Goeringer teaches:
generating as the content information file, an image file that stores the captured image and the blockchain address (Goeringer, Captured image 2206 is input to a signature subprocess 2208, which then outputs a signed image 2210 to storage subprocess 2212, which saves (or alternatively transmits) signed image 2210 as a file package together with the image metadata, [0158] In step S1314, content publisher 1302 transmits a blockchain address and/or currency cost to electronic device 1308. [0119] purchase transaction 1702 is created by user electronic device 1510 (e.g., through a software application) to purchase content from content creator 1502. Once purchase transaction and 1002 is initiated, a license server (not shown) of DRM 1512 verifies that user electronic device 1510 initiated purchase transaction 1702. Content creator 1502 then creates a purchaseToken, which may include one or more of an asset ID, content rights, a public key of user electronic device 1510, a user authentication token, a signature of content creator 1502, and a public key of content creator 1502, [0135] In step S1808, retailer 1508 receives content purchase data from content creator 1502. In an exemplary embodiment, the content purchase data includes one or more of a URL for CDN 1708, a URL for DRM 1512, a blockchain address for the seller, a purchase price for the packaged content, and the purchase token, [0140] image hash 2216 includes, without limitation, one or more of the hash of the unprocessed image, the hardware certificate of device 2202, the hardware address (e.g., in an embodiment where image capture device 2202 is networked), the owner certificate or other account credentials, a timestamp.. Once encoded, the hash is added to metadata, [0163] an image hash (e.g., hash 2216, 2218, or 2220, FIG. 22) is submitted as a transaction 2408 to registry 2404 for ID certification and/or image registration, [0179] registry 2404 further serves to function as a certification server, and is configured to associate registered images with an appropriate user or device certificate, [0180] a blockchain is implemented to cryptographically assure the authenticity of the asset, its time of commit/creation, its creator/owner, and rights associated with the asset, [0187]) [Examiner interprets that storing ownership/account credentials and certificates with image hash/metadata as limitation above] Same motivation applies as claim 13.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20220229883 A1: “relates generally to a system and method for intellectual property protection, and more specifically, to a system and method for protecting, managing and monetizing creative works using blockchain”
US 11250111 B2 : “relates generally to media content files, and more particularly, some embodiments relate to containers for media content and associated content metadata”
US 20060117182 A1 : “relates generally to authenticating documents, and more particularly to methods, systems, and computer program products for generating document authentication indicia that can be verified both digitally and by non-electronic means”
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
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, SHEWAYE GELAGAY can be reached at (571)272-4219. 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.
/S.N.P./Examiner, Art Unit 2436 /MOEEN KHAN/Primary Examiner, Art Unit 2436
Prosecution Insights