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 .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim 11, 13 and 14 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent No. 10,602,202 to Taylor et al.
As to claim 11, Taylor discloses a computer system comprising:
a processor system (Taylor: Fig 7; Processing unit); and
a storage system (Taylor: Fig 7; System memory) that includes instructions that are executable by the processor system to cause the computer system to:
access an electronic file (Taylor: Fig 2 – 210; Col 8. Lines 34-61; “FIG. 2 illustrates a flow chart of an example of a process for authenticating and modifying a media file utilizing the system example of FIG. 1. The operational example may include implementation of process 200 that may be from the viewpoint of a subscriber device, such as 101, or subscriber system that presents a copy of a media file for authentication to a digital data lineage verification service. The subscriber device or subscriber system may access a media file stored in the media repository, such as 145 of FIG. 1. For example, a processor of a subscriber device 101-103 or a subscriber system 120 may retrieve a media file from an assigned location within a media repository (at 210). In the example, the media file includes content and metadata. The content of the media file may be, for example, video content, which may include audio content as well as multiple encoded video frames. In other examples, the content may be a still image or still images, text (such as a document), numerical data (such as a financial database or results of an experiment), or the like. In a further example, the content of the media file may be one of: a surveillance video of a physical location related to an entity, a trusted document related to an entity, an image generated by a camera, a graphic image, a contract document, a manuscript, a bank record, a conversation transcript (audio and/or textual), an identification of a person, or the like. Identification of a person may include an image of the person, details that uniquely identify the person (i.e., fingerprints, retinal scan, voice print or the like), residence address information or the like);
trigger generation of a verification hash on the electronic file (Taylor: Fig 2; Col 9, Lines 42-56; “ At 225, the authenticity of the media file may be confirmed utilizing the retrieved hash value. For example, an authentication process may use the retrieved hash value to confirm the authenticity of the media file presented for authentication and/or the source of the media file. The authentication process may include processing the media file to retrieve the media file address in the blockchain. A hash function may be applied to the media file using an authentication key to produce an authentication hash value. The authentication hash value may be compared to the retrieved hash value. In response to the comparison yielding a match between the authentication hash function and the retrieved hash value, a message including an authentication result confirming the authenticity of the media file retrieved from the media repository may generate”);
use the verification hash to search a blockchain, wherein the verification hash supposedly corresponds with an authentication hash that was supposedly previously uploaded to the blockchain (Taylor: Fig 2; Col 9, Lines 42-56; “ At 225, the authenticity of the media file may be confirmed utilizing the retrieved hash value. For example, an authentication process may use the retrieved hash value to confirm the authenticity of the media file presented for authentication and/or the source of the media file. The authentication process may include processing the media file to retrieve the media file address in the blockchain. A hash function may be applied to the media file using an authentication key to produce an authentication hash value. The authentication hash value may be compared to the retrieved hash value. In response to the comparison yielding a match between the authentication hash function and the retrieved hash value, a message including an authentication result confirming the authenticity of the media file retrieved from the media repository may generate”);
in response to determining that the authentication hash, which supposedly corresponds with the verification hash, has not been found as a part of said search, trigger a first alert indicating that the electronic file is not verifiable (Taylor: Fig 2; Col 9, Line 57 – Col 10, Line 4; “Conversely, a request for confirmation of the authenticity of a media file presented as an original media file may be sent, via the data network, to a digital data lineage verification system. The request may include the media file to be confirmed. A signal may be received from the digital data lineage verification system that a match between the presented media file and media files stored in the media repository was not found. In response to receipt of the signal, an indication for presentation in the graphical user interface may be generated that the media file to be confirmed does not match any media file stored in the media repository. An indication may be presented via the graphical user interface provided by the application programming code, such as a data verification application instance executing on a subscriber device, on the display device of a subscriber device.’);
in response to determining that the authentication hash has been found as a part of said search, trigger a second alert indicating that the electronic file is authentic (Taylor: Fig 2; Col 10, Lines 5-24; In response to confirming the authenticity of the media file (230), the media file may be altered by modifying the content of or metadata parameters in the media file. For example, the subscriber may desire to modify the content of the previously-stored media file for some purpose, such as advertising or the like, or indicate in the metadata that ownership of the media file has been transferred to another entity or subscriber. After altering the content or metadata, a hash function may be applied to the altered media file to generate an altered data hash value. The altered data hash value may be based on the altered data of the media file, and, in some examples, the retrieved hash value may be used in the generation of the altered data hash value. The altered data hash value may be added to a message that is uploaded to the blockchain platform as the subsequent transaction. For example, the message may be uploaded as a subsequent transaction to the media file address in the blockchain platform (235). The message may include an indication of altered data within the media file); and
in response to determining that the authentication hash has been found as the part of said search, return metadata for the electronic file (Taylor: Fig 2; Col 10, Lines 5-24; In response to confirming the authenticity of the media file (230), the media file may be altered by modifying the content of or metadata parameters in the media file. For example, the subscriber may desire to modify the content of the previously-stored media file for some purpose, such as advertising or the like, or indicate in the metadata that ownership of the media file has been transferred to another entity or subscriber. After altering the content or metadata, a hash function may be applied to the altered media file to generate an altered data hash value. The altered data hash value may be based on the altered data of the media file, and, in some examples, the retrieved hash value may be used in the generation of the altered data hash value. The altered data hash value may be added to a message that is uploaded to the blockchain platform as the subsequent transaction. For example, the message may be uploaded as a subsequent transaction to the media file address in the blockchain platform (235). The message may include an indication of altered data within the media file).
As to claim 13, Taylor further discloses wherein determining that the authentication hash has not been found as a part of said search further includes: determining a file name of the electronic file; searching an index of the blockchain using the file name as a search parameter; identifying the file name in the index of the blockchain; and despite the file name being identified in the index of the blockchain, determining that the electronic file is not verifiable (Taylor: Fig 2; Col 8, Line 34 – Col 9, Line 56).
As to claim 14, Taylor further discloses wherein determining that the authentication hash has not been found as a part of said search further includes: obtaining an authentic version of the electronic file using the file name; comparing the authentic version of the electronic file against the electronic file; identifying one or more differences that exist between the authentic version of the electronic file and the electronic file; and triggering an alert that details the one or more differences (Taylor: Fig 2; Col 8, Line 34 – Col 9, Line 56).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-4, 6 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No.2020/0311721 by Ow et al. in view of U.S Patent No. 10,602,202 to Taylor et al.
As to claim 1, Ow discloses a computer system comprising:
a processor system (Ow: Page 31, Sec 351; “In one or more embodiments, a network node may be a computing device, such as a server, network appliance, or the like. A network node may comprise one or more processors and communication devices); and
a storage system that includes instructions that are executable by the processor system (Ow: Page 31, Sec 351; “One or more storage devices, memory devices, or both may be part of a network node as well, such as to provide long term (e.g., hard drive or solid state drive) or short term (e.g., random access memory or cache memory) data storage, respectively speaking.”) to cause the computer system to:
access an electronic file, wherein the electronic file is associated with metadata (Ow: Fig 13 -1320; Page 29, Sec 331; “With reference to FIG. 13, a user 1301 selects the file 1320 to be uploaded to the storage repository 1315. The user 1301 is then prompted 1325 to enter file descriptions, keywords, and any other metadata or defining information the user needs to be able to identify the file being uploaded to the distributed storage 1315.”);
as a part of a repository transaction, store the metadata in a repository (Ow: Fig 13 -1370; Page 29, Sec 336; “the distributed database 1310 now records 1370 the user generated file descriptions, keywords, and other metadata collected by the AXEL network gateway/UI 1305. The distributed database 1310 generates a hash 1375 to identify the user generated keywords and other metadata assigned to the stored file 1370 and reports this information hash 1375 to be recorded by the AXEL blockchain 1309. Once recorded by the AXEL blockchain 1309, the AXEL blockchain 1309 creates a hash 1379 of the newly stored information 1375 and returns the hash 1379 to the distributed database 1310.”);
trigger generation of a transaction hash on at least the repository transaction (Ow: Fig 13 -1370; Page 29, Sec 336; “the distributed database 1310 now records 1370 the user generated file descriptions, keywords, and other metadata collected by the AXEL network gateway/UI 1305. The distributed database 1310 generates a hash 1375 to identify the user generated keywords and other metadata assigned to the stored file 1370 and reports this information hash 1375 to be recorded by the AXEL blockchain 1309. Once recorded by the AXEL blockchain 1309, the AXEL blockchain 1309 creates a hash 1379 of the newly stored information 1375 and returns the hash 1379 to the distributed database 1310.”); and
cause the transaction hash to be stored in a blockchain while refraining from causing the electronic file and the repository transaction from being stored in the blockchain (Ow: Fig 13 -1375; Page 29, Sec 336; “the distributed database 1310 now records 1370 the user generated file descriptions, keywords, and other metadata collected by the AXEL network gateway/UI 1305. The distributed database 1310 generates a hash 1375 to identify the user generated keywords and other metadata assigned to the stored file 1370 and reports this information hash 1375 to be recorded by the AXEL blockchain 1309. Once recorded by the AXEL blockchain 1309, the AXEL blockchain 1309 creates a hash 1379 of the newly stored information 1375 and returns the hash 1379 to the distributed database 1310.”).
Ow does not expressly disclose triggering generation of an authentication hash on the electronic file; or
causing the authentication hash to be stored in a blockchain while refraining from causing the electronic file from being stored in the blockchain.
Taylor discloses expressly disclose triggering generation of an authentication hash on the electronic file (Taylor: Fig 3; Col 12; Lines 52-65; “A media file hash value may be generated by applying a hash function to the media file, including the metadata (330). When determining what data should be input into the applied hash function, the processor may, for example, determine that the received media file is a video file that may include a number of intra-frames and delta-frames. Some of the numbers of intra-frames or delta-frames may be extracted from the media file. If only intra-frames are exacted, the hash function may be applied to a respective intra-frame extracted from the media file to generate an intra-frame hash value for the respective intra-frame. The intra-frame hash value for the respective intra-frame may be inserted into the message to be uploaded as the subsequent transaction.”); or
causing the authentication hash to be stored in a blockchain while refraining from causing the electronic file from being stored in the blockchain (Taylor: Fig 3; Col 13, Lines 27-37; “At 335, the media file hash value may be uploaded to the assigned media file address in the blockchain platform as a transaction in the blockchain. For example, the delta-frame hash value for the respective delta-frame of the number of extracted delta-frames may be inserted into the message with the media file hash value to be uploaded as the transaction. Inputs to a graphical user interface provided by an instance of the data verification application may facilitate the uploading of step 335 as well as operations performed at other steps in the example of FIG. 3 as well as in other examples.”).
Ow and Taylor are analogous art because they are from the common area of blockchain based file management.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the file authentication of Taylor in the system of Ow. The rationale would have been to protect content and authenticate data lineage (Taylor: Col 1, Lines 34-38).
As to claim 3, the modified Ow/Taylor reference discloses all recited elements of claim 1 from which claim 3 depends.
The modified reference does not expressly disclose wherein the computer system generates the authentication hash on the electronic file.
Talyor discloses wherein the computer system generates the authentication hash on the electronic file (Taylor: Fig 3; Col 12; Lines 52-65; “A media file hash value may be generated by applying a hash function to the media file, including the metadata (330). When determining what data should be input into the applied hash function, the processor may, for example, determine that the received media file is a video file that may include a number of intra-frames and delta-frames. Some of the numbers of intra-frames or delta-frames may be extracted from the media file. If only intra-frames are exacted, the hash function may be applied to a respective intra-frame extracted from the media file to generate an intra-frame hash value for the respective intra-frame. The intra-frame hash value for the respective intra-frame may be inserted into the message to be uploaded as the subsequent transaction.”).
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the file authentication of Taylor in the system of Ow. The rationale would have been to protect content and authenticate data lineage (Taylor: Col 1, Lines 34-38).
As to claim 4, the modified Ow/Taylor reference further discloses wherein the computer system generates the transaction hash on at least the repository transaction (Ow: Fig 13 -1370; Page 29, Sec 336; “the distributed database 1310 now records 1370 the user generated file descriptions, keywords, and other metadata collected by the AXEL network gateway/UI 1305. The distributed database 1310 generates a hash 1375 to identify the user generated keywords and other metadata assigned to the stored file 1370 and reports this information hash 1375 to be recorded by the AXEL blockchain 1309. Once recorded by the AXEL blockchain 1309, the AXEL blockchain 1309 creates a hash 1379 of the newly stored information 1375 and returns the hash 1379 to the distributed database 1310.”).
As to claim 6, the modified Ow/Taylor reference further discloses wherein causing both the authentication hash and the transaction hash to be stored in the blockchain while refraining from causing the electronic file and the repository transaction from being stored in the blockchain is performed by a service, and wherein the service is an embedded service operating in an application that is also hosting the electronic file (Ow: Fig 13 -1370; Page 29, Sec 336; “the distributed database 1310 now records 1370 the user generated file descriptions, keywords, and other metadata collected by the AXEL network gateway/UI 1305. The distributed database 1310 generates a hash 1375 to identify the user generated keywords and other metadata assigned to the stored file 1370 and reports this information hash 1375 to be recorded by the AXEL blockchain 1309. Once recorded by the AXEL blockchain 1309, the AXEL blockchain 1309 creates a hash 1379 of the newly stored information 1375 and returns the hash 1379 to the distributed database 1310.”).
As to claim 19, the modified Ow/Taylor reference further discloses a method comprising:
accessing a first electronic file, wherein the first electronic file is associated with first metadata (Ow: Fig 13 -1320; Page 29, Sec 331; “With reference to FIG. 13, a user 1301 selects the file 1320 to be uploaded to the storage repository 1315. The user 1301 is then prompted 1325 to enter file descriptions, keywords, and any other metadata or defining information the user needs to be able to identify the file being uploaded to the distributed storage 1315.”);
as a part of a repository transaction, storing the first metadata in a repository (Ow: Fig 13 -1370; Page 29, Sec 336; “the distributed database 1310 now records 1370 the user generated file descriptions, keywords, and other metadata collected by the AXEL network gateway/UI 1305. The distributed database 1310 generates a hash 1375 to identify the user generated keywords and other metadata assigned to the stored file 1370 and reports this information hash 1375 to be recorded by the AXEL blockchain 1309. Once recorded by the AXEL blockchain 1309, the AXEL blockchain 1309 creates a hash 1379 of the newly stored information 1375 and returns the hash 1379 to the distributed database 1310.”);
triggering generation of an authentication hash on the first electronic file (Taylor: Fig 3; Col 12; Lines 52-65; “A media file hash value may be generated by applying a hash function to the media file, including the metadata (330). When determining what data should be input into the applied hash function, the processor may, for example, determine that the received media file is a video file that may include a number of intra-frames and delta-frames. Some of the numbers of intra-frames or delta-frames may be extracted from the media file. If only intra-frames are exacted, the hash function may be applied to a respective intra-frame extracted from the media file to generate an intra-frame hash value for the respective intra-frame. The intra-frame hash value for the respective intra-frame may be inserted into the message to be uploaded as the subsequent transaction.”);
triggering generation of a transaction hash on at least the repository transaction (Ow: Fig 13 -1370; Page 29, Sec 336; “the distributed database 1310 now records 1370 the user generated file descriptions, keywords, and other metadata collected by the AXEL network gateway/UI 1305. The distributed database 1310 generates a hash 1375 to identify the user generated keywords and other metadata assigned to the stored file 1370 and reports this information hash 1375 to be recorded by the AXEL blockchain 1309. Once recorded by the AXEL blockchain 1309, the AXEL blockchain 1309 creates a hash 1379 of the newly stored information 1375 and returns the hash 1379 to the distributed database 1310.”);
causing both the authentication hash and the transaction hash to be stored in a blockchain while refraining from causing the first electronic file and the repository transaction from being stored in the blockchain (Ow: Fig 13 -1375; Page 29, Sec 336; “the distributed database 1310 now records 1370 the user generated file descriptions, keywords, and other metadata collected by the AXEL network gateway/UI 1305. The distributed database 1310 generates a hash 1375 to identify the user generated keywords and other metadata assigned to the stored file 1370 and reports this information hash 1375 to be recorded by the AXEL blockchain 1309. Once recorded by the AXEL blockchain 1309, the AXEL blockchain 1309 creates a hash 1379 of the newly stored information 1375 and returns the hash 1379 to the distributed database 1310.” and Taylor: Fig 3; Col 13, Lines 27-37; “At 335, the media file hash value may be uploaded to the assigned media file address in the blockchain platform as a transaction in the blockchain. For example, the delta-frame hash value for the respective delta-frame of the number of extracted delta-frames may be inserted into the message with the media file hash value to be uploaded as the transaction. Inputs to a graphical user interface provided by an instance of the data verification application may facilitate the uploading of step 335 as well as operations performed at other steps in the example of FIG. 3 as well as in other examples.”);
The modified reference does not expressly disclose
accessing a second electronic file;
triggering generation of a verification hash on the second electronic file;
using the verification hash to search the blockchain, wherein the verification hash supposedly corresponds with the authentication hash associated with the first electronic file;
in response to determining that the authentication hash, which supposedly corresponds with the verification hash, has not been found as a part of said search, triggering a first alert indicating that the second electronic file is not verifiable;
in response to determining that the authentication hash has been found as a part of said search, triggering a second alert indicating that the second electronic file is authentic; and
in response to determining that the authentication hash has been found as the part of said search, returning the first metadata.
Taylor discloses accessing an electronic file (Taylor: Fig 2 – 210; Col 8. Lines 34-61; “FIG. 2 illustrates a flow chart of an example of a process for authenticating and modifying a media file utilizing the system example of FIG. 1. The operational example may include implementation of process 200 that may be from the viewpoint of a subscriber device, such as 101, or subscriber system that presents a copy of a media file for authentication to a digital data lineage verification service. The subscriber device or subscriber system may access a media file stored in the media repository, such as 145 of FIG. 1. For example, a processor of a subscriber device 101-103 or a subscriber system 120 may retrieve a media file from an assigned location within a media repository (at 210). In the example, the media file includes content and metadata. The content of the media file may be, for example, video content, which may include audio content as well as multiple encoded video frames. In other examples, the content may be a still image or still images, text (such as a document), numerical data (such as a financial database or results of an experiment), or the like. In a further example, the content of the media file may be one of: a surveillance video of a physical location related to an entity, a trusted document related to an entity, an image generated by a camera, a graphic image, a contract document, a manuscript, a bank record, a conversation transcript (audio and/or textual), an identification of a person, or the like. Identification of a person may include an image of the person, details that uniquely identify the person (i.e., fingerprints, retinal scan, voice print or the like), residence address information or the like);
triggering generation of a verification hash on the electronic file (Taylor: Fig 2; Col 9, Lines 42-56; “ At 225, the authenticity of the media file may be confirmed utilizing the retrieved hash value. For example, an authentication process may use the retrieved hash value to confirm the authenticity of the media file presented for authentication and/or the source of the media file. The authentication process may include processing the media file to retrieve the media file address in the blockchain. A hash function may be applied to the media file using an authentication key to produce an authentication hash value. The authentication hash value may be compared to the retrieved hash value. In response to the comparison yielding a match between the authentication hash function and the retrieved hash value, a message including an authentication result confirming the authenticity of the media file retrieved from the media repository may generate”);
using the verification hash to search a blockchain, wherein the verification hash supposedly corresponds with an authentication hash that was supposedly previously uploaded to the blockchain (Taylor: Fig 2; Col 9, Lines 42-56; “ At 225, the authenticity of the media file may be confirmed utilizing the retrieved hash value. For example, an authentication process may use the retrieved hash value to confirm the authenticity of the media file presented for authentication and/or the source of the media file. The authentication process may include processing the media file to retrieve the media file address in the blockchain. A hash function may be applied to the media file using an authentication key to produce an authentication hash value. The authentication hash value may be compared to the retrieved hash value. In response to the comparison yielding a match between the authentication hash function and the retrieved hash value, a message including an authentication result confirming the authenticity of the media file retrieved from the media repository may generate”);
in response to determining that the authentication hash, which supposedly corresponds with the verification hash, has not been found as a part of said search, trigger a first alert indicating that the electronic file is not verifiable (Taylor: Fig 2; Col 9, Line 57 – Col 10, Line 4; “Conversely, a request for confirmation of the authenticity of a media file presented as an original media file may be sent, via the data network, to a digital data lineage verification system. The request may include the media file to be confirmed. A signal may be received from the digital data lineage verification system that a match between the presented media file and media files stored in the media repository was not found. In response to receipt of the signal, an indication for presentation in the graphical user interface may be generated that the media file to be confirmed does not match any media file stored in the media repository. An indication may be presented via the graphical user interface provided by the application programming code, such as a data verification application instance executing on a subscriber device, on the display device of a subscriber device.’);
in response to determining that the authentication hash has been found as a part of said search, triggering a second alert indicating that the electronic file is authentic (Taylor: Fig 2; Col 10, Lines 5-24; In response to confirming the authenticity of the media file (230), the media file may be altered by modifying the content of or metadata parameters in the media file. For example, the subscriber may desire to modify the content of the previously-stored media file for some purpose, such as advertising or the like, or indicate in the metadata that ownership of the media file has been transferred to another entity or subscriber. After altering the content or metadata, a hash function may be applied to the altered media file to generate an altered data hash value. The altered data hash value may be based on the altered data of the media file, and, in some examples, the retrieved hash value may be used in the generation of the altered data hash value. The altered data hash value may be added to a message that is uploaded to the blockchain platform as the subsequent transaction. For example, the message may be uploaded as a subsequent transaction to the media file address in the blockchain platform (235). The message may include an indication of altered data within the media file); and
in response to determining that the authentication hash has been found as the part of said search, returning metadata for the electronic file (Taylor: Fig 2; Col 10, Lines 5-24; In response to confirming the authenticity of the media file (230), the media file may be altered by modifying the content of or metadata parameters in the media file. For example, the subscriber may desire to modify the content of the previously-stored media file for some purpose, such as advertising or the like, or indicate in the metadata that ownership of the media file has been transferred to another entity or subscriber. After altering the content or metadata, a hash function may be applied to the altered media file to generate an altered data hash value. The altered data hash value may be based on the altered data of the media file, and, in some examples, the retrieved hash value may be used in the generation of the altered data hash value. The altered data hash value may be added to a message that is uploaded to the blockchain platform as the subsequent transaction. For example, the message may be uploaded as a subsequent transaction to the media file address in the blockchain platform (235). The message may include an indication of altered data within the media file).
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the file authentication of Taylor in the system of Ow. The rationale would have been to protect content and authenticate data lineage (Taylor: Col 1, Lines 34-38).
Claims 2 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No.2020/0311721 by Ow et al. in view of U.S Patent No. 10,602,202 to Taylor et al. further in view of U.S. Patent Application Publication No. 2025/0016011 by Hamiel et al.
As to claim 2, the modified Ow/Taylor reference discloses all recited elements of claim 1 from which claim 2 depends.
The modified reference does not expressly disclose wherein the metadata includes at least one of provenance information for the electronic file, ownership information for the electronic file, or creator information for the electronic file..
Hamiel discloses wherein the metadata includes at least one of provenance information for the electronic file, ownership information for the electronic file, or creator information for the electronic file (Hamiel: Page 6, Sec 59; autyhenticity, creator credits and provenance in metadata file).
The modified reference and Hamiel are analogous art because they are from the common area of blockchain based file management.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the metadata of Hamiel in the system of the modified reference. The rationale would have been to provide information about a file in metadata (Hamiel: Page 6, Sec 59).
As to claim 20, the modified Ow/Taylor/Hamiel reference further discloses
wherein the first metadata includes author information. (Hamiel: Page 6, Sec 59).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over U.S Patent No. 10,602,202 to Taylor et al. in view of U.S. Patent Application Publication No. 2025/0016011 by Hamiel et al.
As to claim 18, Taylor discloses all recited elements of claim 11 from which claim 18 depends.
The modified reference does not expressly disclose wherein the metadata includes author information for the electronic file.
Hamiel discloses wherein the metadata includes author information for the electronic file. (Hamiel: Page 6, Sec 59; autyhenticity, creator credits and provenance in metadata file).
Taylor and Hamiel are analogous art because they are from the common area of blockchain based file management.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the metadata of Hamiel in the system of Taylor. The rationale would have been to provide information about a file in metadata (Hamiel: Page 6, Sec 59).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No.2020/0311721 by Ow et al. in view of U.S Patent No. 10,602,202 to Taylor et al. further in view of U.S. Patent Application Publication No. 2020/0279270 by Lieberman et al.
As to claim 5, the modified Ow/Taylor reference discloses all recited elements of claim 1 from which claim 5 depends.
The modified reference does not expressly disclose wherein a third-party process generates the authentication hash on the electronic file.
Lieberman discloses wherein a third-party process generates the authentication hash on the electronic file. (Lieberman: Page 5, Sec 55; “In some embodiments, the enrollment module 304 may maintain a hash of the user's sensitive data. The hash maintains the privacy of the user, while also being used to verify a user's sensitive data. For example, a third-party may use the same hashing algorithm to generate a hash of information provided by a user. The third-party service may then provide the hash to the authentication and authorization system 108, where it is compared to the stored hash to verify the information.”).
The modified reference and Lieberman are analogous art because they are from the common area of blockchain based file management.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the third party hash generation of Lieberman in the system of the modified reference. The rationale would have been to protect sensitive data (Lieberman: Page 5, Sec 55).
Claim 7, 8 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No.2020/0311721 by Ow et al. in view of U.S Patent No. 10,602,202 to Taylor et al. further in view of U.S. Patent No. 11,113,241 to Winarski.
As to claim 7, the modified Ow/Taylor reference discloses all recited elements of claim 1 from which claim 7 depends. The modified reference further discloses wherein the authentication hash is generated using a hash algorithm (Ow: Pages 5-6, Sec 58; hash function),
The modified reference does not expressly disclose wherein selection of the hash algorithm is based on information included in the metadata.
Winarski discloses wherein selection of the hash algorithm is based on information included in the metadata (Winarski: Col 31, Lines 9-32; “After accessing blockchain 153 and file 126 from a storage device within or external to computer 10, or from a storage node 72 on network 70, the blockchain application automatically accesses hashing metadata from blockchain 153 to determine what hash algorithm to use along with what types of hash digests to generate in order to produce blockchain block 158 that includes hash information from block 156 and file 126 as data per process 6000”).
The modified reference and Winarski are analogous art because they are from the common area of blockchain based file management.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the hash generation of Winarski in the system of the modified reference. The rationale would have been to protect automate blockchain management using metadata (Winarski: Col 31, Lines 9-32).
As to claim 8, the modified Ow/Taylor/Winarski reference further discloses wherein the authentication hash is generated using a hash algorithm (Ow: Pages 5-6, Sec 58; hash function), and wherein selection of the hash algorithm is based on information included in the electronic file (Winarski: Col 31, Lines 9-32; metadata a part of electronic file).
As to claim 12, the modified Ow/Taylor/Winarski reference further discloses wherein a hash algorithm used to generate the verification hash is identified using the metadata (Winarski: Col 31, Lines 9-32), which is stored in a repository ((Ow: Fig 13 -1370; Page 29, Sec 336).
Claims 15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over U.S Patent No. 10,602,202 to Taylor et al. in view of U.S. Patent No. 11,113,241 to Winarski.
As to claim 15, Taylor discloses all recited elements of claim 11 from which claim 15 depends.
Taylor does not expressly disclose wherein file metadata included with the electronic file is used to select a hash algorithm that generates the verification hash..
Winarski discloses wherein file metadata included with the electronic file is used to select a hash algorithm that generates the verification hash (Winarski: Col 31, Lines 9-32; “After accessing blockchain 153 and file 126 from a storage device within or external to computer 10, or from a storage node 72 on network 70, the blockchain application automatically accesses hashing metadata from blockchain 153 to determine what hash algorithm to use along with what types of hash digests to generate in order to produce blockchain block 158 that includes hash information from block 156 and file 126 as data per process 6000”).
Taylor and Winarski are analogous art because they are from the common area of blockchain based file management.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the hash generation of Winarski in the system of Taylor. The rationale would have been to protect automate blockchain management using metadata (Winarski: Col 31, Lines 9-32).
As to claim 17, the modified Taylor/Winarski reference further discloses wherein information included within the electronic file is used to select a hash algorithm that generates the verification hash (Winarski: Col 31, Lines 9-32; metadata a part of electronic file).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No.2020/0311721 by Ow et al. in view of U.S Patent No. 10,602,202 to Taylor et al. further in view of U.S. Patent Application Publication No. 2010/0325093 by Bates et al.
As to claim 9, the modified Ow/Taylor reference discloses all recited elements of claim 1 from which claim 9 depends. The modified reference further discloses wherein the authentication hash is generated using a hash algorithm (Ow: Pages 5-6, Sec 58; hash function),
The modified reference does not expressly disclose wherein selection of the hash algorithm is based on a determined type of the electronic file.
Bates discloses wherein selection of the hash algorithm is based on a determined type of the electronic file (Bates: Page 3, Sec 39-4; “[0039] In step 370, the method determines whether to select and utilize a hash algorithm based upon file type. In certain embodiments, step 370 is performed by a host computer. In certain embodiments, step 370 is performed by a storage controller. [0040] If the method elects to select and utilize a hash algorithm based upon file type, then the method transitions from step 370 to step 380 wherein the method provides two or more hash algorithms. The method transitions from step 380 to step 390.”).
The modified reference and Bates are analogous art because they are from the common area of file hashing.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the hash algorithm selection of Bates in the system of the modified reference. The rationale would have been to tailor hash functions to file types (Bates: Page 3, Sec 39-40).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over U.S Patent No. 10,602,202 to Taylor et al. in view of U.S. Patent Application Publication No. 2010/0325093 by Bates et al.
As to claim 16, Taylor discloses all recited elements of claim 11 from which claim 16 depends.
Taylor does not expressly disclose wherein a determined type of the electronic file is used to select a hash algorithm that generates the verification hash..
Bates discloses wherein a determined type of the electronic file is used to select a hash algorithm that generates the verification hash. (Bates: Page 3, Sec 39-40; “[0039] In step 370, the method determines whether to select and utilize a hash algorithm based upon file type. In certain embodiments, step 370 is performed by a host computer. In certain embodiments, step 370 is performed by a storage controller. [0040] If the method elects to select and utilize a hash algorithm based upon file type, then the method transitions from step 370 to step 380 wherein the method provides two or more hash algorithms. The method transitions from step 380 to step 390.”).
Taylor and Bates are analogous art because they are from the common area of file hashing.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the hash algorithm selection of Bates in the system of Taylor. The rationale would have been to fit hash functions to file types (Bates: Page 3, Sec 39-40).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No.2020/0311721 by Ow et al. in view of U.S Patent No. 10,602,202 to Taylor et al. further in view of U.S. Patent Application Publication No. 2018/0032910 by Shibahara.
As to claim 10, the modified Ow/Taylor reference discloses all recited elements of claim 1 from which claim 10 depends. The modified reference further discloses wherein the authentication hash is generated using a hash algorithm (Ow: Pages 5-6, Sec 58; hash function)
The modified reference does not expressly disclose wherein selection of the hash algorithm is based on a randomization factor.
Shibahara discloses wherein selection of the hash algorithm is based on a randomization factor (Shibahara: Page 5, Sec 82-83; “[0082] The a-bit hash function type selection field 603 is a field for selecting a hash algorithm, which is a type of the a-bit hash function. Examples of the hash algorithm include FNV, MurmurHash, MD5, SHA-2, and SHA-3, and the hash algorithm can be selected through user's operation. In FIG. 6, MurmurHash 631 is selected. Further, a random selection 632 is an option for selecting at random any one of the hash algorithms of the a-bit hash function described above. When the random selection 632 is selected, in processing (FIG. 8) described later, every time the hash pool count m is incremented, any one of the hash algorithms of the a-bit hash function described above is selected at random.
[0083] The b-bit hash function type selection field 604 is a field for selecting a hash algorithm, which is a type of the b-bit hash function. Examples of the hash algorithm include FNV, MurmurHash, MD5, SHA-2, and SHA-3, and the hash algorithm can be selected through user's operation. In FIG. 6, FNV 641 is selected. Further, a random selection 642 is an option for selecting at random any one of the hash algorithms of the b-bit hash function described above. When the random selection 642 is selected, in the processing (FIG. 8) described later, every time the hash pool count m is incremented, any one of the hash algorithms of the b-bit hash function described above is selected at random.”).
The modified reference and Shibahara are analogous art because they are from the common area of file hashing.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the hash algorithm selection of Shibahara in the system of the modified reference. The rationale would have been to tailor hash functions to file types (Shibahara: Page 5, Sec 82-83;).
Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Application Publication No. 2020/0351347 by Chang et al. discloses searching for files by name in an index
U.S. Patent Application Publication No. 2024/0113895 by Wang et al. discloses storing metadata associate with a file and storing a link to the metadata on the blockchain
“Validating data integrity with blockchain” by Kalis et al. discloses using hashes stored on a blockchain to validate date stored in a repository
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL S MCNALLY whose telephone number is (571)270-1599. The examiner can normally be reached Monday-Friday, 8:30 AM - 5:00 PM.
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, Jeffrey L Nickerson can be reached at (469)295-9235. 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.
MICHAEL S. MCNALLY
Primary Examiner
Art Unit 2432
/Michael S McNally/Primary Examiner, Art Unit 2432
Prosecution Insights