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 .
Continued Examination Under 37 CFR 1.114
Receipt is acknowledged of a request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e) and a submission, filed on 31 March 2026. The submission, however, is not fully responsive to the prior Office action because Claim 1 previously had been canceled and now has a status of “Currently Amended”.
See 37 CFR 1.121(c)(5)—"(5) Reinstatement of previously canceled claim. A claim which was previously canceled may be reinstated only by adding the claim as a "new" claim with a new claim number.”
Since the submission appears to be a bona fide attempt to provide a complete reply to the prior Office action, and in the interest of compact prosecution, the examiner has examined the claims on the merit. However, an amendment to the claims is required so that claim 1 is canceled and, if desired, introduced as a new claim with a new claim number. Also note that claims dependent on claim 1 will also have to be canceled and introduced as new claims in order to comply with 35 U.S.C. 112(d).
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in the European Patent Office on 05 July 2024. It is noted, however, that a certified copy of the EP24186914.8 application has not been filed as required by 37 CFR 1.55.
Information Disclosure Statement
The Information Disclosure Statements filed on 10 February 2026 and 24 March 2026 comply with all applicable rules and regulations. Therefore, the information referred to therein has been considered.
Response to Arguments
Applicant’s arguments, see pages 13-14, filed 31 March 2026, with respect to the rejection(s) of claims 12 and 15-17 under 35 U.S.C. 103 have been fully considered and are persuasive in view of the new claim amendments. Note: claim 12 is now indicated as canceled and the previous claim 12 limitations with the new claim amendments have been included as previously-canceled claim 1 (see Continued Examination section above). The previous 35 U.S.C. 103 rejections of claims 15-17 have been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Lundberg et al. (US 2022/0368534 A1), Suter et al. (US 12,445,307 B1), Bruner (US 2020/0267521 A1), and Joshi et al. (US 2013/0051475 A1).
See the 35 U.S.C. 103 section below for a detailed analysis.
Claim Objections
Claim 9 is objected to because of the following informalities:
Regarding claim 9, line 3—“an indication of the hash function”, appears to be referring to “an indication of the hash function” of claim 1. This objection may be overcome by amending line 3 to state --the indication of the hash function--, for example.
Regarding claim 9, lines 4-5—“a digital signature”, appears to be referring to “a digital signature” of claim 1. This objection may be overcome by amending lines 4-5 to state --the digital signature--, for example.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 2, 5, 6, 8-11, and 14-23 are rejected under 35 U.S.C. 103 as being unpatentable over Lundberg et al. (US 2022/0368534 A1) in view of Suter et al. (US 12,445,307 B1) in view of Bruner (US 2020/0267521 A1) and further in view of Joshi et al. (US 2013/0051475 A1).
Regarding claim 1, Lundberg teaches an apparatus, e.g., decoder (Para. 31), for checking a video data stream, having a video encoded thereinto, on trustworthiness, e.g., at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Para. 31),
wherein the apparatus comprises one or more processors, e.g., decoder (Para. 31), configured for
…;
subjecting a predetermined portion of the video data stream, or data derived therefrom, to the hash function identified by the hash function identifier to obtain a hash value, e.g., a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Para. 31);
deriving a unique identifier from the video data stream, e.g., metadata MD—unique identifier-- may also be concatenated 310 with the frame hashes for each of the frames I, P1-P6 to produce the GOP hash for the GOP I, wherein the metadata MD may comprise at least one of: a unique identifier of a camera capturing the video segment, a time stamp for the video segment, a hardware type (camera type), a firmware version, a GPS position, a frame stamp, and a number of boots (Para. 37);
obtaining a digital signature based on the video data stream, e.g., the digitally signed GOP hash for each GOP is included in a subsequent GOP in the video segment, and at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Para. 31);
forming a verification…multiple pieces of information comprising the hash value, the unique identifier, and an indication of the hash function, e.g., the digitally signed GOP hash for each GOP is included in a subsequent GOP in the video segment, and at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Para. 31);
by also hashing metadata with the one or more frame hashes to produce the GOP hash, it may be determined whether or not the metadata has been tampered with (Para. 15);
metadata MD may also be concatenated 310 with the frame hashes for each of the frames I, P1-P6 to produce the GOP hash for the GOP I, and examples of cryptographic hash functions are MD5, SHA-1, SHA-2 (SHA-256/SHA-512), SHA-3, BLAKE-3 (Para. 37); and
comparing the verification…to the digital signature using a key to determine whether the video data stream is trustworthy, e.g., the digitally signed GOP hash for each GOP is included in a subsequent GOP in the video segment, and at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Para. 31);
by also hashing metadata with the one or more frame hashes to produce the GOP hash, it may be determined whether or not the metadata has been tampered with (Para. 15);
metadata MD may also be concatenated 310 with the frame hashes for each of the frames I, P1-P6 to produce the GOP hash for the GOP I, and examples of cryptographic hash functions are MD5, SHA-1, SHA-2 (SHA-256/SHA-512), SHA-3, BLAKE-3 (Para. 37);
wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream…, e.g., Each GOP comprises a number of frames, wherein a first frame is an intra frame I followed by six inter frames P1-P6 in the first three GOPs 101-103 and by four inter frames P1-P4 in the last GOP 104 of the video segment (Fig. 1, el. 101-104; Para. 34).
Lundberg does not clearly teach decoding a hash function identifier from the video data stream;
forming a verification string by concatenating multiple pieces of information comprising the hash value, the unique identifier, and an indication of the hash function; and
comparing the verification string to the digital signature using a key to determine whether the video data stream is trustworthy,
wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding and transform based residual coding.
Suter teaches wherein the apparatus, e.g., remote media server 112 that includes encryption signature verification component 114 (Fig. 1, el. 112, 114; Fig. 3, el. 114), comprises one or more processors, e.g., one or more processors 403 (Fig. 4, el. 403), configured for
decoding a hash function identifier from the video data stream, e.g., the process 600 may continue at operation 612, at which the electronic device 401 may generate synchronization data for the encryption signature, where the operation 612 may include generating, based on one or more of the hash data, the initialization vector, the authentication data, the flag or identifier for a hash function, and/or any additional data (identified from the encryption signature at the operation 610 as described above), synchronization data, wherein in some examples, the operation 612 may include performing one or more of the operations 502-534 of the process 500 (e.g., locally at the remote media server 112) in order to generate synchronization data comprising one or more recreated copies of the encryption signature (e.g., recreated copies of the hash data, authentication data, and/or the like) (Fig. 6, el. 612; Col. 46, line 60-Col. 47, line 7);
subjecting a predetermined portion of the video data stream, or data derived therefrom, to the hash function identified by the hash function identifier to obtain a hash value, e.g., the process 600 may continue at operation 612, at which the electronic device 401 may generate synchronization data for the encryption signature, where the operation 612 may include generating, based on one or more of the hash data, the initialization vector, the authentication data, the flag or identifier for a hash function, and/or any additional data (identified from the encryption signature at the operation 610 as described above), synchronization data, wherein in some examples, the operation 612 may include performing one or more of the operations 502-534 of the process 500 (e.g., locally at the remote media server 112) in order to generate synchronization data comprising one or more recreated copies of the encryption signature (e.g., recreated copies of the hash data, authentication data, and/or the like) (Fig. 6, el. 612; Col. 46, line 60-Col. 47, line 7);
deriving a unique identifier from the video data stream, e.g., the process 600 may continue at operation 612, at which the electronic device 401 may generate synchronization data for the encryption signature, where the operation 612 may include generating, based on one or more of the hash data, the initialization vector—unique identifier--, the authentication data—unique identifier--, the flag or identifier for a hash function, and/or any additional data (identified from the encryption signature at the operation 610 as described above), synchronization data, wherein in some examples, the operation 612 may include performing one or more of the operations 502-534 of the process 500 (e.g., locally at the remote media server 112) in order to generate synchronization data comprising one or more recreated copies of the encryption signature (e.g., recreated copies of the hash data, authentication data, and/or the like) (Fig. 6, el. 612; Col. 46, line 60-Col. 47, line 7);
obtaining a digital signature based on the video data stream, e.g., the process 600 may continue at operation 610, at which the electronic device 401 may access the encryption signature using a public key associated with the electronic camera (Fig. 6, el. 610; Col. 46, lines 29-32);
forming a verification…multiple pieces of information comprising the hash value, the unique identifier, and an indication of the hash function, e.g., the process 600 may continue at operation 612, at which the electronic device 401 may generate synchronization data for the encryption signature, where the operation 612 may include generating, based on one or more of the hash data, the initialization vector—unique identifier--, the authentication data—unique identifier--, the flag or identifier for a hash function, and/or any additional data (identified from the encryption signature at the operation 610 as described above), synchronization data, wherein in some examples, the operation 612 may include performing one or more of the operations 502-534 of the process 500 (e.g., locally at the remote media server 112) in order to generate synchronization data comprising one or more recreated copies of the encryption signature (e.g., recreated copies of the hash data, authentication data, and/or the like) (Fig. 6, el. 612; Col. 46, line 60-Col. 47, line 7);
comparing the verification…to the digital signature using a key to determine whether the video data stream is trustworthy, e.g., the process 600 may continue at operation 614, at which the electronic device 401 may determine whether the encryption signature matches the synchronization data, wherein the operation 614 may include comparing the synchronization data (e.g., generated at the operation 612 as described above), in whole or in part, to the encryption signature (e.g., identified at the operation 608 as described above) (Fig. 6, el. 614; Col. 47, lines 57-64);
using symmetric-key algorithms and/or symmetric encryption ciphers (e.g., instead of a public key and a private key pair, the same shared key (or symmetric key) is used for both encryption and decryption), generating synchronization data may comprise recreating at least the hash data and then encrypting the hash data with the same shared key (or symmetric key) in order to produce a recreated encryption signature, where the recreated encryption signature (encrypted with the shared or symmetric key) may be utilized as synchronization data as described below, where using asymmetric-key algorithms and/or asymmetric encryption ciphers (e.g., instead of a shared key (or symmetric key), a private key and a public key is used for encryption and decryption respectively), generating synchronization data may comprise recreating at least the hash data (Col. 47, lines 34-55),
wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding…, e.g., the data blocks 314A may be encoded using H.264 (or AVC) or H.265 (or HEVC) (Col. 16, lines 11-13).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lundberg to include decoding a hash function identifier from the video data stream; forming a verification with multiple pieces of information comprising the hash value, the unique identifier, and an indication of the hash function; and comparing the verification to the digital signature using a key to determine whether the video data stream is trustworthy, wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding, using the known method of signing hash data, authentication data, and an identifier that indicates the hash function used, as taught by Suter, in combination with the video encoding and video signature system of Lundberg, for the purpose of detecting modifications made to streaming data and detecting wholly forged streaming data (Suter-Col. 2, lines 56-64). Another benefit of the combination would be to provide a quicker method of matching video segments by not necessarily requiring the received signature to be decrypted into its components and then the components being compared for matching.
Lundberg in view of Suter does not clearly teach forming a verification string by concatenating multiple pieces of information comprising the hash value, the unique identifier, and an indication of the hash function; and
comparing the verification string to the digital signature using a key to determine whether the video data stream is trustworthy,
wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding and transform based residual coding.
Bruner teaches forming a verification string by concatenating multiple pieces of information comprising the hash value, the unique identifier, and an indication of the hash function, e.g., a temporary EID (TEID) may be defined as follows: TEID=alg∥nonce∥hash(alg∥nonce∥EID) (Para. 30);
where “alg” is a value that identifies a secure hash algorithm (e.g., SHA256), “nonce” is a random number (e.g., 128 bits), “EID” is the eUICC ID [0034] “∥” represents concatenation, and “hash” is the computation of the hash function identified by “alg”(Para. 31-35); and
comparing the verification string to the…to determine whether the…is trustworthy, e.g., If the profile is linked to a TEID, the download server examines the first part of the TEID to determine the “alg” and “nonce”, computes “hash(alg∥nonce∥EID)”, and compares them to the stored TEID value, and if they match, the EID is validated and the profile can be downloaded (Para. 38).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lundberg in view of Suter to include forming a verification string by concatenating multiple pieces of information comprising the hash value, the unique identifier, and an indication of the hash function; and comparing the verification string to the digital signature using a key to determine whether the video data stream is trustworthy, using the known method of generating a TEID that comprises a concatenation of an identification of the hash algorithm, a nonce, and EID, a hash value, and comparing the TEID to a stored TEID, as taught by Bruner, in combination with the video encoding and video signature system of Lundberg in view of Suter, for the purpose of utilizing a more unique video identification in order to provide a better idea of whether the video stream is trustworthy.
Lundberg in view of Suter in view of Bruner does not clearly teach wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding and transform based residual coding.
Joshi teaches wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding, e.g., during the encoding process, video encoder 20 receives a video picture or slice to be coded, wherein the picture or slice may be divided into multiple video blocks, and motion estimation unit 42 and motion compensation unit 44 perform inter-predictive coding of the received video block relative to one or more blocks in one or more reference pictures to provide temporal compression, and intra-prediction unit 46 may perform intra-predictive coding of the received video block relative to one or more neighboring blocks in the same picture or slice as the block to be coded to provide spatial compression (Fig. 1, el. 20; Fig. 2, el. 20, 42, 44; Para. 94), and
transform based residual coding, e.g., Mode select unit 40 may select one of the coding modes, intra or inter, and provides the resulting intra- or inter-coded block to summer 50 to generate residual block data and to summer 62 to reconstruct the encoded block for use in a reference picture (Fig. 2, el. 40, 50, 62; Para. 95);
video encoder 20 forms a residual block by subtracting the prediction data calculated by motion compensation unit 44 or intra-prediction unit 46 from the original video block being coded (Para. 100);
transform processing unit 52 may form one or more transform units (TUs) from the residual block, and transform processing unit 52 applies a transform, such as a discrete cosine transform (DCT), a directional transform, or a conceptually similar transform, to the TU, producing a video block comprising transform coefficients (Fig. 2, el. 52; Para. 101).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lundberg in view of Suter in view of Bruner to include wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding and transform based residual coding, using the known method of forming a residual block using the original video block being encoded, as taught by Joshi, in combination with the video encoding and video signature system of Lundberg in view of Suter in view of Bruner, for the purpose of providing a more accurate reconstruction for the video stream by utilizing the residual block.
Regarding claim 2, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 1, configured for, in checking whether the combination of the hash value and the unique identifier fits to the digital signature, decrypting the digital signature to obtain a check value; and checking whether the combination of the hash value and the unique identifier matches the check value, e.g., at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Lundberg-Para. 31); by also hashing metadata with the one or more frame hashes to produce the GOP hash, it may be determined whether or not the metadata has been tampered with (Lundberg-Para. 15); metadata MD may also be concatenated 310 with the frame hashes for each of the frames I, P1-P6 to produce the GOP hash for the GOP I (Lundberg-Para. 37).
Regarding claim 5, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 1, checking, whether the unique identifier matches a unique identifier associated with one or more further media components, e.g., at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Lundberg-Para. 31); by also hashing metadata with the one or more frame hashes to produce the GOP hash, it may be determined whether or not the metadata has been tampered with (Lundberg-Para. 15); metadata MD may also be concatenated 310 with the frame hashes for each of the frames I, P1-P6 to produce the GOP hash for the GOP I (Lundberg-Para. 37); producing S210 a GOP hash for GOP i, and digitally signing S220 the GOP hash for GOP i by means of a digital signature, thereby producing a signed GOP hash for each GOP i=1 to n S208, S222, C224 (i.e., for each GOP of the n GOPs) of a video segment (Lundberg-Para. 36).
Regarding claim 6, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 1, configured for deriving the digital signature from the video data stream, e.g., at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Lundberg-Para. 31).
Regarding claim 8, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 1.
Lundberg further teaches configured for deriving the unique identifier from…the video data stream, e.g., metadata MD—unique identifier-- may also be concatenated 310 with the frame hashes for each of the frames I, P1-P6 to produce the GOP hash for the GOP I, wherein the metadata MD may comprise at least one of: a unique identifier of a camera capturing the video segment, a time stamp for the video segment, a hardware type (camera type), a firmware version, a GPS position, a frame stamp, and a number of boots (Para. 37).
Lundberg does not explicitly teach configured for deriving the unique identifier from a payload packet signaled in the video data stream.
Suter further teaches deriving the unique identifier from a payload packet signaled in the video data stream, e.g., the process 600 may continue at operation 612, at which the electronic device 401 may generate synchronization data for the encryption signature, where the operation 612 may include generating, based on one or more of the hash data, the initialization vector—unique identifier--, the authentication data—unique identifier--, the flag or identifier for a hash function, and/or any additional data (identified from the encryption signature at the operation 610 as described above), synchronization data, wherein in some examples, the operation 612 may include performing one or more of the operations 502-534 of the process 500 (e.g., locally at the remote media server 112) in order to generate synchronization data comprising one or more recreated copies of the encryption signature (e.g., recreated copies of the hash data, authentication data, and/or the like) (Fig. 6, el. 612; Col. 46, line 60-Col. 47, line 7).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lundberg to include deriving the unique identifier from a payload packet signaled in the video data stream, using the known method of generating, based on one or more of the hash data, the initialization vector, the authentication data, the flag or identifier for a hash function, and/or any additional data, as taught by Suter, in combination with the video encoding and video signature system of Lundberg, using the same motivation as in claim 1.
Regarding claim 9, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 8, wherein the payload packet further comprises one or more of an indication of the hash function, an indication of a number of portions of the video data stream, for which a digital signature for verifying the trustworthiness of the video data stream is available, an indication, which indicates a manner for retrieving a public key for checking whether the combination of the hash value and the unique identifier fits to the digital signature, e.g., the process 600 may continue at operation 612, at which the electronic device 401 may generate synchronization data for the encryption signature, where the operation 612 may include generating, based on one or more of the hash data, the initialization vector, the authentication data, the flag or identifier for a hash function, and/or any additional data (identified from the encryption signature at the operation 610 as described above), synchronization data, wherein in some examples, the operation 612 may include performing one or more of the operations 502-534 of the process 500 (e.g., locally at the remote media server 112) in order to generate synchronization data comprising one or more recreated copies of the encryption signature (e.g., recreated copies of the hash data, authentication data, and/or the like) (Suter-Fig. 6, el. 612; Col. 46, line 60-Col. 47, line 7).
Regarding claim 10, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 1, the apparatus being a decoder configured for decoding the video from the video data stream, and decoding an indication of the digital signature from the video data stream, e.g., the digitally signed GOP hash for each GOP is included in a subsequent GOP in the video segment, and at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Lundberg-Para. 31).
Regarding claim 11, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 1.
Lundberg further teaches performing the checking the video data stream on trustworthiness sequentially with respect to a plurality of portions of the video data stream, e.g., a video segment 100 including a number of GOPs 101-104 that may be used in relation to embodiments of the disclosure (Fig. 1, el. 100, 101-104; Para. 34); producing S210 a GOP hash for GOP i, and digitally signing S220 the GOP hash for GOP i by means of a digital signature, thereby producing a signed GOP hash for each GOP i=1 to n S208, S222, C224 (i.e., for each GOP of the n GOPs) of a video segment (Para. 36); the digitally signed GOP hash for each GOP is included in a subsequent GOP in the video segment, and at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Para. 31), and
subjecting a further portion of the video data stream, or data derived therefrom, to the hash function to obtain a further hash value, e.g., a video segment 100 including a number of GOPs 101-104 that may be used in relation to embodiments of the disclosure (Fig. 1, el. 100, 101-104; Para. 34); producing S210 a GOP hash for GOP i, and digitally signing S220 the GOP hash for GOP i by means of a digital signature, thereby producing a signed GOP hash for each GOP i=1 to n S208, S222, C224 (i.e., for each GOP of the n GOPs) of a video segment (Para. 36); the digitally signed GOP hash for each GOP is included in a subsequent GOP in the video segment, and at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Para. 31); and
checking whether a combination of the hash value…and the unique identifier fits to the digital signature, e.g., at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Para. 31); by also hashing metadata with the one or more frame hashes to produce the GOP hash, it may be determined whether or not the metadata has been tampered with (Para. 15); metadata MD may also be concatenated 310 with the frame hashes for each of the frames I, P1-P6 to produce the GOP hash for the GOP I (Para. 37).
Lundberg does not clearly teach checking whether a combination of the hash value, the further hash value, and the unique identifier fits to the digital signature.
Suter further teaches checking whether a combination of the hash value, the further hash value, and the unique identifier fits to the digital signature, e.g., the process 600 may continue at operation 614, at which the electronic device 401 may determine whether the encryption signature matches the synchronization data, wherein the operation 614 may include comparing the synchronization data (e.g., generated at the operation 612 as described above), in whole or in part, to the encryption signature (e.g., identified at the operation 608 as described above), where the hash data (e.g., unencrypted hash data, encrypted hash data, and/or the like) recreated by a verifying peer (e.g., via the process 500) may be compared, at least in part, to the hash data (e.g., final hash data, any or all of hash data 208A-208N, and/or the like as described herein), such as by comparing one or more fixed-length hash values (e.g., string of bytes defining a binary code, numeric values, and/or alphanumeric values) from the recreated hash data to the received hash data (Fig. 6, el. 614; Col. 47, line 57-Col. 48, line 6).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lundberg to include checking whether a combination of the hash value, the further hash value, and the unique identifier fits to the digital signature, using the known method of matching synchronization data with the encryption signature, wherein any or all of a plurality of hash data may be compared, as taught by Suter, in combination with the video encoding and video signature system of Lundberg, using the same motivation as in claim 1.
Regarding claim 14, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 1, wherein the predetermined portion of the video data stream extends over more than one access unit of the video data stream so that the hash value depends on bits of the more than one access unit, or wherein the predetermined portion comprises video data of only one access unit, e.g., the digitally signed GOP hash for each GOP is included in a subsequent GOP in the video segment, and at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Lundberg-Para. 31).
Regarding claim 15, Lundberg teaches an apparatus, e.g., decoder (Para. 31), for checking a video data stream, having a video encoded thereinto, on trustworthiness, e.g., at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Para. 31),
wherein the apparatus comprises one or more processors, e.g., decoder (Para. 31), configured for
subjecting a predetermined portion of the video data stream, or data derived therefrom, to the hash function identified by the hash function identifier to obtain a hash value, e.g., a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Para. 31) and
…;
assigning a unique identifier to the predetermined portion and inserting the unique identifier into the video stream, e.g., metadata MD—unique identifier-- may also be concatenated 310 with the frame hashes for each of the frames I, P1-P6 to produce the GOP hash for the GOP I, wherein the metadata MD may comprise at least one of: a unique identifier of a camera capturing the video segment, a time stamp for the video segment, a hardware type (camera type), a firmware version, a GPS position, a frame stamp, and a number of boots (Para. 37);
forming a verification by…multiple pieces of information comprising the hash value, the unique identifier, and the hash function identifier, e.g., the digitally signed GOP hash for each GOP is included in a subsequent GOP in the video segment, and at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Para. 31);
by also hashing metadata with the one or more frame hashes to produce the GOP hash, it may be determined whether or not the metadata has been tampered with (Para. 15);
metadata MD may also be concatenated 310 with the frame hashes for each of the frames I, P1-P6 to produce the GOP hash for the GOP I, and examples of cryptographic hash functions are MD5, SHA-1, SHA-2 (SHA-256/SHA-512), SHA-3, BLAKE-3 (Para. 37); and
signing the verification…using a key to obtain a digital signature and inserting the digital signature into the video data stream, e.g., the digitally signed GOP hash for each GOP is included in a subsequent GOP in the video segment, and at a decoder side the digital signature for the GOP can be used to verify the origin of the GOP, wherein if the digital signature for the GOP has been created by encryption of the GOP hash by means of a private key of a public/private key pair, the signature origin can be verified by decryption using the public key of the public/private key pair, and a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Para. 31);
by also hashing metadata with the one or more frame hashes to produce the GOP hash, it may be determined whether or not the metadata has been tampered with (Para. 15);
metadata MD may also be concatenated 310 with the frame hashes for each of the frames I, P1-P6 to produce the GOP hash for the GOP I, and examples of cryptographic hash functions are MD5, SHA-1, SHA-2 (SHA-256/SHA-512), SHA-3, BLAKE-3 (Para. 37);
wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream…, e.g., Each GOP comprises a number of frames, wherein a first frame is an intra frame I followed by six inter frames P1-P6 in the first three GOPs 101-103 and by four inter frames P1-P4 in the last GOP 104 of the video segment (Fig. 1, el. 101-104; Para. 34).
Lundberg does not clearly teach inserting a hash function identifier, which identifies the hash function, into the video data stream;
forming a verification string by concatenating multiple pieces of information comprising the hash value, the unique identifier, and the hash function identifier;
signing the verification string using a key to obtain a digital signature and inserting the digital signature into the video data stream,
wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding and transform based residual coding.
Suter teaches wherein the apparatus, e.g., electronic device 401 (Fig. 4, el. 401), for rendering a video data stream having a video encoded thereinto checkable on trustworthiness, wherein the apparatus comprises one or more processors, e.g., one or more processors 403 (Fig. 4, el. 403), configured for
subjecting a predetermined portion of the video data stream, or of data from which the video data stream is derived, to a hash function to obtain a hash value, e.g., the process 500 may continue at operation 524, at which the electronic device 401 may generate final hash data, wherein as used herein the term “final hash data” may refer to hash data that comprises some or all hash data generated by one or more iterations of a hash algorithm (e.g., hash algorithm 207) associated with a data stream, where final hash data may be generated based, at least in part, on any hash data (e.g., first, second, and/or N.sup.th hash data) generated for each data block and/or each data block group of a data stream (Fig. 5B, el. 524; Col. 41, lines 11-20), and
inserting a hash function identifier, which identifies the hash function, into the video data stream, e.g., the process 500 may continue at operation 528, at which the electronic device 401 may encrypt the final hash data to produce an encryption signature, where the operation 528 may include encrypting, using the private key, the final hash data to produce an encryption signature (e.g., encryption signature 212), where the encryption signature may comprise the final hash data, the initialization vector, the authentication data, a flag or an identifier, and/or any other data described herein, wherein the flag or the identifier may indicate which hash algorithm (e.g., hash algorithm 207) or which hash function of the hash algorithm was used to produce the final hash (or any other hash data described for process 500 or the like) (Fig. 5B, el. 528; Col. 41, line 56-Col. 42, line 5);
the process 500 may continue at operation 530, at which the electronic device 401 may insert the encryption signature into the real-time (or near-real-time) video stream (Fig. 5B, el. 530; Col. 42, lines 59-62);
assigning a unique identifier to the predetermined portion and inserting the unique identifier into the video data stream, e.g., the process 500 may continue at operation 506, at which the electronic device 401 may generate authentication data (e.g., authentication data 204 or the like), where authentication data may comprise a byte code, timestamp data, a camera or electronic device identifier (e.g., serial number, unique ID, etc.), an abstraction of one or more identifiers, and/or any other authentication data as described herein (Fig. 5A, el. 506; Col. 37, lines 40-47);
the process 500 may continue at operation 512, at which the electronic device 401 may generate a first data input by prepending the initialization vector and/or the authentication data to the first data block (Fig. 5A, el. 512; Col. 38, lines 49-53);
the process 500 may continue at operation 528, at which the electronic device 401 may encrypt the final hash data to produce an encryption signature, where the operation 528 may include encrypting, using the private key, the final hash data to produce an encryption signature (e.g., encryption signature 212), where the encryption signature may comprise the final hash data, the initialization vector, the authentication data, a flag or an identifier, and/or any other data described herein, wherein the flag or the identifier may indicate which hash algorithm (e.g., hash algorithm 207) or which hash function of the hash algorithm was used to produce the final hash (or any other hash data described for process 500 or the like) (Fig. 5B, el. 528; Col. 41, line 56-Col. 42, line 5);
the process 500 may continue at operation 530, at which the electronic device 401 may insert the encryption signature into the real-time (or near-real-time) video stream (Fig. 5B, el. 530; Col. 42, lines 59-62);
forming a verification…multiple pieces of information comprising the hash value, the unique identifier, and an indication of the hash function, e.g., the process 500 may continue at operation 528, at which the electronic device 401 may encrypt the final hash data to produce an encryption signature, where the operation 528 may include encrypting, using the private key, the final hash data to produce an encryption signature (e.g., encryption signature 212), where the encryption signature may comprise the final hash data, the initialization vector, the authentication data, a flag or an identifier, and/or any other data described herein, wherein the flag or the identifier may indicate which hash algorithm (e.g., hash algorithm 207) or which hash function of the hash algorithm was used to produce the final hash (or any other hash data described for process 500 or the like) (Fig. 5B, el. 528; Col. 41, line 56-Col. 42, line 5);
signing the verification…using a key to obtain a digital signature and inserting the digital signature into the video data stream, e.g., the process 500 may continue at operation 528, at which the electronic device 401 may encrypt the final hash data to produce an encryption signature, where the operation 528 may include encrypting, using the private key, the final hash data to produce an encryption signature (e.g., encryption signature 212), where the encryption signature may comprise the final hash data, the initialization vector, the authentication data, a flag or an identifier, and/or any other data described herein, wherein the flag or the identifier may indicate which hash algorithm (e.g., hash algorithm 207) or which hash function of the hash algorithm was used to produce the final hash (or any other hash data described for process 500 or the like) (Fig. 5B, el. 528; Col. 41, line 56-Col. 42, line 5);
the process 500 may continue at operation 530, at which the electronic device 401 may insert the encryption signature into the real-time (or near-real-time) video stream (Fig. 5B, el. 530; Col. 42, lines 59-62);
wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding…, e.g., the data blocks 314A may be encoded using H.264 (or AVC) or H.265 (or HEVC) (Col. 16, lines 11-13).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lundberg to include inserting a hash function identifier, which identifies the hash function, into the video data stream; forming a verification using multiple pieces of information comprising the hash value, the unique identifier, and the hash function identifier; signing the verification using a key to obtain a digital signature and inserting the digital signature into the video data stream, wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding, using the known method of signing hash data, authentication data, and an identifier that indicates the hash function used, as taught by Suter, in combination with the video encoding and video signature system of Lundberg, for the purpose of detecting modifications made to streaming data and detecting wholly forged streaming data (Suter-Col. 2, lines 56-64). Another benefit of the combination would be to provide a quicker method of matching video segments by not necessarily requiring the received signature to be decrypted into its components and then the components being compared for matching.
Lundberg in view of Suter does not clearly teach forming a verification string by concatenating multiple pieces of information comprising the hash value, the unique identifier, and the hash function identifier; and
signing the verification string using a key to obtain a digital signature and inserting the digital signature into the video data stream,
wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding and transform based residual coding.
Bruner teaches forming a verification string by concatenating multiple pieces of information comprising the hash value, the unique identifier, and the hash function identifier, e.g., a temporary EID (TEID) may be defined as follows: TEID=alg∥nonce∥hash(alg∥nonce∥EID) (Para. 30);
where “alg” is a value that identifies a secure hash algorithm (e.g., SHA256), “nonce” is a random number (e.g., 128 bits), “EID” is the eUICC ID [0034] “∥” represents concatenation, and “hash” is the computation of the hash function identified by “alg”(Para. 31-35).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lundberg in view of Suter to include forming a verification string by concatenating multiple pieces of information comprising the hash value, the unique identifier, and the hash function identifier; and signing the verification string using a key to obtain a digital signature and inserting the digital signature into the video data stream, using the known method of generating a TEID that comprises a concatenation of an identification of the hash algorithm, a nonce, and EID, a hash value, and comparing the TEID to a stored TEID, as taught by Bruner, in combination with the video encoding and video signature system of Lundberg in view of Suter, for the purpose of utilizing a more unique video identification in order to provide a better idea of whether the video stream is trustworthy.
Lundberg in view of Suter in view of Bruner does not clearly teach wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding and transform based residual coding.
Joshi teaches wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding, e.g., during the encoding process, video encoder 20 receives a video picture or slice to be coded, wherein the picture or slice may be divided into multiple video blocks, and motion estimation unit 42 and motion compensation unit 44 perform inter-predictive coding of the received video block relative to one or more blocks in one or more reference pictures to provide temporal compression, and intra-prediction unit 46 may perform intra-predictive coding of the received video block relative to one or more neighboring blocks in the same picture or slice as the block to be coded to provide spatial compression (Fig. 1, el. 20; Fig. 2, el. 20, 42, 44; Para. 94), and
transform based residual coding, e.g., Mode select unit 40 may select one of the coding modes, intra or inter, and provides the resulting intra- or inter-coded block to summer 50 to generate residual block data and to summer 62 to reconstruct the encoded block for use in a reference picture (Fig. 2, el. 40, 50, 62; Para. 95);
video encoder 20 forms a residual block by subtracting the prediction data calculated by motion compensation unit 44 or intra-prediction unit 46 from the original video block being coded (Para. 100);
transform processing unit 52 may form one or more transform units (TUs) from the residual block, and transform processing unit 52 applies a transform, such as a discrete cosine transform (DCT), a directional transform, or a conceptually similar transform, to the TU, producing a video block comprising transform coefficients (Fig. 2, el. 52; Para. 101).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lundberg in view of Suter in view of Bruner to include wherein the video data stream has the video encoded thereinto by encoding the video into the video data stream by block based predictive coding and transform based residual coding, using the known method of forming a residual block using the original video block being encoded, as taught by Joshi, in combination with the video encoding and video signature system of Lundberg in view of Suter in view of Bruner, for the purpose of providing a more accurate reconstruction for the video stream by utilizing the residual block.
Regarding claim 16, the claim is analyzed with respect to claim 1.
Regarding claim 17, the claim is analyzed with respect to claim 15.
Regarding claim 18, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 1, wherein the indication of the hash function includes a syntax element indicating the hash function out of a plurality of hash functions including SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA- 512/224, SHA-512/256, the syntax element being combined with the hash value and the unique identifier by the combination, e.g., the encryption signature verification component 114 may utilize, at least in part, one or more of the initialization vector, the authentication data—unique identifier--, the hash data, one or more hash algorithms, and/or the like (e.g., as determined from data blocks 314B) to produce one or more encryption signatures for comparison to one or more of the encryption signatures contained in the data blocks 314B (Suter-Fig. 3, el. 314B; Col. 18, lines 59-65);
the encryption signature verification component 114 may input the data block group 316A and/or any associated (e.g., prepended) initialization vector, authentication data, and/or the like into one or more hash algorithms in order to re-create (or attempt to re-create) the one or more encryption signatures associated with data block 318A (Suter-Fig, 3, el. 314A; Col. 19, lines 11-17);
the data blocks 314B (via their encryption signature(s)) may include one or more of an initialization vector (e.g., initialization vector 202), authentication data (e.g., authentication data 204)—unique identifier--, hash data (e.g., any or all of hash data 208A-208N), a flag or an identifier indicating which hash algorithm—indication of the hash function-- (e.g., hash algorithm 207) was used to produce one or more encryption signatures (e.g., encryption signature 212), and/or any other data described herein (Suter-Fig. 2, el. 202, 204, 207, 208, 212; Col. 18, lines 20-27);
examples of authentication data—unique identifier-- may include, without limitation, a byte code, timestamp data, a camera or electronic device identifier (e.g., serial number, unique ID, etc.), an abstraction of one or more identifiers, and/or any other data that may be utilized by a verifying peer (e.g., remote media server 112 and/or any other computing device comprising the encryption signature verification component 114) to authenticate any or all of signed data blocks 214 (Suter-Col. 9, lines 8-16).
Regarding claim 19, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 15, wherein the indication of the hash function includes a syntax element indicating the hash function out of a plurality of hash functions including SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA- 512/224, SHA-512/256, the syntax element being combined with the hash value and the unique identifier by the combination, e.g., the encryption signature verification component 114 may utilize, at least in part, one or more of the initialization vector, the authentication data—unique identifier--, the hash data, one or more hash algorithms, and/or the like (e.g., as determined from data blocks 314B) to produce one or more encryption signatures for comparison to one or more of the encryption signatures contained in the data blocks 314B (Suter-Fig. 3, el. 314B; Col. 18, lines 59-65);
the encryption signature verification component 114 may input the data block group 316A and/or any associated (e.g., prepended) initialization vector, authentication data, and/or the like into one or more hash algorithms in order to re-create (or attempt to re-create) the one or more encryption signatures associated with data block 318A (Suter-Fig, 3, el. 314A; Col. 19, lines 11-17);
the data blocks 314B (via their encryption signature(s)) may include one or more of an initialization vector (e.g., initialization vector 202), authentication data (e.g., authentication data 204)—unique identifier--, hash data (e.g., any or all of hash data 208A-208N), a flag or an identifier indicating which hash algorithm—indication of the hash function-- (e.g., hash algorithm 207) was used to produce one or more encryption signatures (e.g., encryption signature 212), and/or any other data described herein (Suter-Fig. 2, el. 202, 204, 207, 208, 212; Col. 18, lines 20-27);
examples of authentication data—unique identifier-- may include, without limitation, a byte code, timestamp data, a camera or electronic device identifier (e.g., serial number, unique ID, etc.), an abstraction of one or more identifiers, and/or any other data that may be utilized by a verifying peer (e.g., remote media server 112 and/or any other computing device comprising the encryption signature verification component 114) to authenticate any or all of signed data blocks 214 (Suter-Col. 9, lines 8-16).
Regarding claim 20, the claim is analyzed with respect to claim 19.
Regarding claim 21, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 18, configured to derive the syntax element from the video data stream, e.g., the encryption signature verification component 114 may utilize, at least in part, one or more of the initialization vector, the authentication data—unique identifier--, the hash data, one or more hash algorithms, and/or the like (e.g., as determined from data blocks 314B) to produce one or more encryption signatures for comparison to one or more of the encryption signatures contained in the data blocks 314B (Suter-Fig. 3, el. 314B; Col. 18, lines 59-65).
Regarding claim 22, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 19, configured to write the syntax element into the video data stream, e.g., the encryption signature verification component 114 may utilize, at least in part, one or more of the initialization vector, the authentication data—unique identifier--, the hash data, one or more hash algorithms, and/or the like (e.g., as determined from data blocks 314B) to produce one or more encryption signatures for comparison to one or more of the encryption signatures contained in the data blocks 314B (Suter-Fig. 3, el. 314B; Col. 18, lines 59-65);
the encryption signature verification component 114 may comprise the encryption signature generation component 104 (Suter-Col. 18, lines 45-47);
the encryption signature generation component 104 may further prepend additional data to one or more of the unsigned data blocks 213 to produce input data (e.g., one or more of input data 206A-206N), wherein the additional data may include a flag or identifier indicating which hash algorithm 207 is used by the encryption signature generation component 104 to generate the encryption signature 212 (Suter-Col. 9, lines 58-65).
Regarding claim 23, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the non-transitory digital storage medium according to claim 20, wherein the syntax element is comprised by the video data stream, e.g., the encryption signature verification component 114 may utilize, at least in part, one or more of the initialization vector, the authentication data—unique identifier--, the hash data, one or more hash algorithms, and/or the like (e.g., as determined from data blocks 314B) to produce one or more encryption signatures for comparison to one or more of the encryption signatures contained in the data blocks 314B (Suter-Fig. 3, el. 314B; Col. 18, lines 59-65).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Lundberg in view of Suter in view of Bruner in view of Joshi and further in view of Buffard et al. (US 2023/0325473 A1).
Regarding claim 4, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 1.
Lundberg in view of Suter in view of Bruner in view of Joshi does not clearly teach deriving an indication of an external resource for retrieving the public key from the video data stream, and deriving the public key from the external resource; and
deriving the unique identifier from the external resource.
Buffard teaches deriving an indication of an external resource for retrieving the public key from the video data stream, and deriving the public key from the external resource, e.g., based on the embedded data for each segment of the plurality of segments, the content access device 140 determines whether the segment was signed by the content owner (operation 720), wherein for example, the content device 140 may send a request that includes the identifier—indication of an external resource-- to the identity authority 115, and in response, the content device 140 receives a public key of the identified content owner (Fig. 1, el. 115, 140; Fig. 7, el. 720; Para. 112);
the identity authority 115 registers the transmitted information, allowing the content distribution network 305, or any of the systems of FIG. 1 to request the identifier of the owner—unique identifier-- and the authorizations for modification, so long as the identifier of the media content item is known, wherein the identifier of the media content—indication of an external resource-- may be part of the data embedded in the media content item to facilitate queries to the identity authority 115 (Fig. 1, el. 115; Para. 119); and
deriving the unique identifier from the external resource, e.g., the identity authority 115 registers the transmitted information, allowing the content distribution network 305, or any of the systems of FIG. 1 to request the identifier of the owner—unique identifier-- and the authorizations for modification, so long as the identifier of the media content item is known, wherein the identifier of the media content may be part of the data embedded in the media content item to facilitate queries to the identity authority 115 (Fig. 1, el. 115; Para. 119);
FIG. 1 is a network diagram illustrating a network environment 100 suitable for implementing media authentication, wherein the network environment 100 includes an identity authority 115 and a content access device 140 (Fig. 1; Para. 27).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lundberg in view of Suter in view of Bruner in view of Joshi to include deriving an indication of an external resource for retrieving the public key from the video data stream, and deriving the public key from the external resource; and deriving the unique identifier from the external resource, using the known method of using an identifier embedded in the media content item to request and receive a public key from an identity authority and receiving the content owner identifier from identity authority, as taught by Buffard, in combination with the video encoding and video signature system of Lundberg in view of Suter in view of Bruner in view of Joshi, for the purpose of providing the system with the ability to determine if the media content item was manipulated after being distributed by the content owner (Buffard-Para. 24). Another benefit of the combination would be to enhance the security of the signature by having the device request the corresponding public key from a trusted identity authority server.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Lundberg in view of Suter in view of Bruner in view of Joshi and further in view of Levy et al. (US 2004/0091111 A1).
Regarding claim 13, Lundberg in view of Suter in view of Bruner in view of Joshi teaches the apparatus according to claim 1.
Lundberg further teaches wherein the hash value depends on…the predetermined portion of the video data stream in an encoded domain, e.g., a GOP hash can be produced from the content of the GOP as received at the decoder side and be compared to the (decrypted) digitally signed GOP hash (Lundberg-Para. 31).
Lundberg in view of Suter in view of Bruner in view of Joshi does not explicitly teach wherein the hash value depends on every bit of the predetermined portion of the video data stream in an encoded domain.
Levy teaches wherein the hash value depends on every bit of the predetermined portion of the video data stream in an encoded domain, e.g., the Digital Signature Standard (DSS), or any digital signature (by definition, including the private key encryption of a robust hash), can be used to authenticate the accuracy of every bit in each frame of surveillance video (Para. 113); the DSS, uses the secure hash algorithm (SHA-1) or any other digital signature based upon a robust hash and public key cryptography, is used to demonstrate that no bits in each frame have been modified (Para. 115); the authentication process includes using the public key to decrypt the digital signature and compare it to the robust hash calculation of the video frame data (Para. 120).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lundberg in view of Suter in view of Bruner in view of Joshi to include wherein the hash value depends on every bit of the predetermined portion of the video data stream in an encoded domain, using the known method of performing a robust hash calculation of the video frame data in order to verify that no bits in the frame have been modified, as taught by Levy, in combination with the video encoding and video signature system of Lundberg in view of Suter in view of Bruner in view of Joshi, for the purpose of verifying that no bits in the frame have been modified (Levy-Para. 113, 115).
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Segal et al. (US 2021/0329003 A1)—Segal discloses a hash of the concatenation of an application identifier and a function identifier (Para. 16).
Freed et al. (US 2015/0163545 A1)—Freed discloses while the first video stream is being presented for rendering on a display element, the process 300 continues by processing and analyzing the current segment of video content (task 304), wherein task 304 generates at least one characterizing signature for the current segment of video content (Fig. 3, el. 300, 304; Para. 58).
Lasserre et al. (US 2020/0267403 A1)—Lasserre discloses significance flags in advanced video compression systems are coded using contexts adaptive to the last N significance flags coded taken in a scanning order (Abstract).
Storelli et al. (US 2024/0205002 A1)—Storelli discloses at a first peer, receiving input data sent by a second peer connected to the first peer through a peer-to-peer network, wherein the input data comprises: a hash of a media segment, and metadata associated to a playback position of the media segment; at the first peer, receiving a digital signature sent by the second peer, wherein the digital signature results from signing the input data with a private key; and checking validity of the digital signature from the input data and a public key (Abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET).
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, Yin-Chen Shaw can be reached at (571) 272-8878. 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.
24 April 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498
Prosecution Insights