DETAILED ACTION
Acknowledgements
This Non-Final Office Action is in reply to Applicant’s response filed February 18, 2026.
Claims 1, 3, 14, 15 are currently amended.
Claims 1–18 are currently pending.
Claims 1–18 have been examined.
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
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on February 18, 2026 has been entered.
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-15 are rejected under 35 U.S.C. 103 as being unpatentable over Wikipedia “HMAC”, 9/28/2021 revision, in view of Wikipedia “Digital Signature”, 10/5/2021 revision, in view of Chien (US 20210377008 A1).
Regarding claim 1
HMAC teaches:
A method of signing video data to be shared with a recipient, the method comprising:
obtaining video data representing a video sequence; {page 1 “In cryptography, an HMAC (sometimes expanded as either keyed-hash message authentication code or hash-based message authentication code) is a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key. As with any MAC, it may be used to simultaneously verify both the data integrity and the authenticity of a message. HMAC can provide message [data] authentication using a shared secret instead of using digital signatures with asymmetric cryptography. It trades off the need for a complex public key infrastructure by delegating the key exchange to the communicating parties, who are responsible for establishing and using a trusted channel to agree on the key prior to communication.”}
HMAC teaches a message authentication code for generic data. HMAC does not specifically teach applying the code to video data. However, the type of data is not given patentable weight because it is merely an intended use which has no functional effect on how the method is performed.
generating a first fingerprint, wherein generating the first fingerprint comprises forming, in a memory:
a combination of the salt and a first portion of the video data, or
a combination of the salt and a hash of a first portion of the video data; and
hashing the combination in the memory; {page 1 “Parties with the secret key [salt] will hash the message [data] again themselves [regeneratable], and if it is authentic, the received and computed hashes [fingerprint] will match.”; page 1 “HMAC does not encrypt the message. Instead, the message (encrypted or not) must be sent alongside the HMAC hash. Parties with the secret key will hash the message again themselves, and if it is authentic, the received and computed hashes will match.”; HMAC Definition, screenshot below}
PNG
media_image1.png
494
1006
media_image1.png
Greyscale
HMAC(K, m) reads on fingerprint. K reads on salt. M reads on data.
The broadest reasonable interpretation of the term “a combination” is any expression which includes both elements. The above therefore reads on at least the first alternative because the expression includes K (salt) and m (data). It also reads on the second alternative because m is separately hashed.
HMAC does not teach, however Digital Signature teaches:
generating, using a private key of an asymmetric key pair, a digital signature value over at least the first fingerprint; and {page 1 figure shown below; page 1 figure caption “Alice signs a message—"Hello Bob!"—by appending to the original message a version encrypted with her private key. Bob receives both the message and signature. He uses Alice's public key to verify the authenticity of the message”}
PNG
media_image2.png
938
960
media_image2.png
Greyscale
providing, to the recipient, a signature of the video data, the signature comprising the first fingerprint and the digital signature value, {page 1 figure shown above}
wherein the digital signature value is verifiable using a corresponding public key of the asymmetric key pair and which enables the recipient to validate the authenticity of the video data. {page 1 figure shown above}
Bob reads on recipient. The alphanumeric string “BE459576785039E8” reads on digital signature. The message signed by Alice reads on the claimed first fingerprint and data.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to apply the digital signature scheme of Digital Signature to the message (data) and hash (fingerprint) of HMAC because, in the method of HMAC, the message and hash are what is sent to a recipient (HMAC page 1 “the message (encrypted or not) must be sent alongside the HMAC hash”), and applying the digital signature would allow the recipient to verify the authenticity and integrity of what is received (Digital Signature page 1 “A valid digital signature, where the prerequisites are satisfied, gives a recipient very strong reason to believe that the message was created by a known sender (authentication), and that the message was not altered in transit (integrity).”).
The difference between the method of HMAC in view of Digital Signature and the claimed method is that HMAC in view of Digital Signature does not teach the key K (salt) being obtained by hashing a bitstring not extracted from the data. However Chien further teaches a key generation method:
obtaining a bitstring not extracted from the video data;
providing a salt by hashing the bitstring; {[0029] “For example, at 7:00 AM, each system obtains and uses a timestamp to select a key generation process. Each system uses the timestamp [bitstring] (or portion thereof) as the seed to the random number generator to create the index into the key generation process table 120. The selected key generation process is used to generate a key [salt]. Then, supposing system 10 starts communicating at 7:15, system 10 will use the key generated at 7:00 AM to encrypt data transmitted to system 60. Since system 60 will have performed the same process, it will have generated the same key, and thus be able to decrypt data received from system 10.”; [0031] “In typical embodiments, key generation processes 120 take as input a timestamp and output a number based on the timestamp. This number is the shared key generated.”}
The above process of transforming the timestamp into a key reads on hashing because a hash is any function which takes an arbitrary input and transforms it into a fixed length output.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the key generation method of Chien with the keyed-hash message authentication code of HMAC because one is a method of generating a cryptographic key while the other is a method which employs a cryptographic key. Therefore, each serves the same function in the combination as it does separately, and the combination is suggested by the references themselves.
Regarding claim 2
HMAC teaches:
The method of claim 1, wherein the salt and the first fingerprint are generated using different hash functions, the method further comprising: {page 1 “Any cryptographic hash function, such as SHA-2 or SHA-3, may be used in the calculation of an HMAC;”}
The hash function in HMAC reads on the hash used to generate the first fingerprint, while the key generation method of Chien reads on the hash used to generate the claimed salt. Chien, as cited above with respect to claim 1, teaches a method of transforming a timestamp into a key which is not SHA-2 or SHA-3.
HMAC in view of Digital Signature does not teach, however Chien teaches:
sharing, over a private communication path, a definition of the hash function for generating the salt with a recipient of the signed video data. ([0023] “Since system 60 will have performed the same process, it will have generated the same key”; [0026] “When each participant computing system is initially configured (e.g., when it is unboxed and configured for its user), an administrator or other privileged user stores or otherwise configures each computing system with the illustrated modules, including the key generation process table 120 [definition of the hash function]. This may be done manually, such as by loading the modules and data via a thumb drive or other media. In other embodiments, modules and data may be transmitted to each participant computing system over a secure channel [private communication path]”)
The reasons for combining the key generation process of Chien with the authentication code of HMAC in view of Digital Signature are given above with respect to claim 1.
Regarding claim 3
HMAC in view of Digital Signature in view of Chien teaches:
The method of claim 1, further comprising:
generating a second fingerprint by hashing:
a combination of the salt and a second portion of the video data, or
a combination of the salt and a hash of a second portion of the video data,
wherein the signature of the video data further includes the second fingerprint.
This is merely repeating the steps of HMAC in view of Digital Signature in view of Chien with additional data. There is no unexpected result from doing so and therefore it would have been obvious.
Regarding claim 4
The method of claim 3, wherein the first and second portions represent respective time segments of the video sequence.
As stated above with respect to claim 1, the content of the data is not given patentable weight because it has no effect on the performance of the method.
Regarding claim 5
The method of claim 4, wherein the first and second portions represent respective frames of the video sequence.
As stated above with respect to claim 1, the content of the data is not given patentable weight because it has no effect on the performance of the method.
Regarding claim 6
The method of claim 4, wherein the first and second portions represent respective independently decodable groups of pictures, GOPs, of the video sequence.
As stated above with respect to claim 1, the content of the data is not given patentable weight because it has no effect on the performance of the method.
Regarding claim 7
HMAC in view of Digital Signature does not teach, however Chien teaches:
The method of claim 3, further comprising:
caching the salt, wherein generating the second fingerprint includes using the cached salt. {[0029] “For example, at 7:00 AM, each system obtains and uses a timestamp to select a key generation process. Each system uses the timestamp (or portion thereof) as the seed to the random number generator to create the index into the key generation process table 120. The selected key generation process is used to generate a key. Then, supposing system 10 starts communicating at 7:15, system 10 will use the key generated at 7:00 AM to encrypt data transmitted to system 60.”; [0030] “using 7:00 AM as the truncated timestamp”}
Storing the key generated at 7am for use later at 7:15am reads on caching. Since the system generates a new key only once at the bottom of each hour, re-using the key for a second fingerprint is implied.
The reasons for combining the references are the same as given above with respect to claim 1.
Regarding claim 8
The method of claim 1, wherein the first portion of the video data is all the obtained video data.
As stated above with respect to claim 1, the content of the data is not given patentable weight because it has no effect on the performance of the method.
Regarding claim 9
The method of claim 1, wherein at least one of the following holds:
the bitstring includes reproducible information relating to the acquisition of the video sequence; (Chien abstract “Since the computing systems have synchronized variable-time clocks, they both select and use the same key generation process, thereby generating the same encryption key without the need to communicate the key from one system to another.”)
This is not given patentable weight. This is not a step in the method and does not affect the performance of any step. Reproducing the bitstring is not part of the method and the ability to do so is merely an intended result.
However, this is taught by Chien. Chien teaches using a timestamp (bitstring) which can be reproduced by all parties because they have synchronized clocks. Additionally, it is noted that a current time is given as an example of reproducible information relating to the acquisition of the video sequence at paragraph [0028] of the specification.
at least part of the bitstring is extracted from metadata associated with the video data; or
This is not given patentable weight. This is not a method step. An association can exist purely in the human mind. Metadata associated with the video data is interpreted as merely a label for data.
information, from which the bitstring is uniquely derivable, is inserted into metadata associated with the video data.
This is not given patentable weight. There are no method steps involving metadata. Metadata associated with the video data is interpreted as a label for data. Said data is not used in the method.
Regarding claim 10
The method of claim 1, wherein the video sequence is a streaming video sequence.
As stated above with respect to claim 1, the content of the data is not given patentable weight because it has no effect on the performance of the method.
Regarding claim 11
HMAC teaches:
The method of claim 10, wherein the video data has a time-sequential structure, and the signature is composed of multiple sub-signatures relating to respective segments of the video data, wherein the signature is provided by inserting said sub-signatures into or near the respective segments of the video data. {page 1 “HMAC does not encrypt the message. Instead, the message (encrypted or not) must be sent alongside the HMAC hash.”}
A sub-signature is interpreted referring to a signature of some piece of data. The above is read upon by merely repeating the steps of HMAC for additional messages. Each piece of data / message will have its own signature alongside it. There is no unexpected result from repeating the method and therefore it would have been obvious to do and generate multiple messages, each with its own signature.
Regarding claim 12
HMAC teaches:
The method of claim 1, wherein the signature of the video data is included in metadata associated with the video data. {page 1 “the message [data] (encrypted or not) must be sent alongside the HMAC hash [signature].”}
Regarding claim 13
HMAC teaches:
The method of claim 1, wherein the signature of the video data is cryptographically signed. {page 1 “In cryptography, an HMAC (sometimes expanded as either keyed-hash message authentication code or hash-based message authentication code) is a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key.”}
Regarding claims 14-15
Claims 14 and 15 are substantially similar to claim 1 and are treated the same with respect to prior art rejections.
Claims 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over HMAC in view of Digital Signature in view of Chien as applied to claims 1, 14-15 above, and further in view of Takagi (US 20110006818 A1).
Regarding claims 16-18
HMAC in view of Digital Signature in view of Chien teaches two parties with synchronized clocks using a timestamp (bitstring) as part of a symmetric key generation algorithm. HMAC in view of Digital Signature in view of Chien does not teach, however Takagi teaches:
The method of claim 1, wherein at least the signature of the video data further includes the bitstring. {[0099] “The master node 10 periodically transmits to the slave node 20 a packet with a timestamp [bitstring] for clock synchronization.”}
It is noted that “signature of the video data” is interpreted as a label for data which is provided. The prior art data which reads on “signature of the video data” is the computed hashes plus the timestamp.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have the signing party transmit a timestamp to the verifying party in order to synchronize their clocks since synchronized clocks are required by HMAC in view of Digital Signature in view of Chien, and Takagi teaches a clock synchronization method.
Response to Arguments
35 USC § 103
Applicant argues the cited art does not teach the amended limitations which now recite generating a signature using a private key of an asymmetric key pair. The cited art does not teach this. However, a new reference, Wikipedia “Digital Signature”, has been added. Amended claim 1 is read upon by substantially the same prior art as before, except with a conventional digital signature now applied to the output (message + hash) of HMAC.
Applicant argues Chien does not teach “providing a salt by hashing a bitstring”. Applicant states Chien’s teachings are directed to generating a shared key between systems having synchronized clocks. Applicant argues “Chien does not disclose applying a hash function to the timestamp/bitstring to generate a salt, and Chien does not describe the generated index or generated key as a ‘salt’”.
It is true that the terminology used by the claim and the reference is not the same. However, the concept is the same. Regarding the term ‘hash’, a hash is a term for any function which takes arbitrary data as input and generates a fixed length output. The process of Chien transforms a timestamp into a key, which is a fixed length output. The language that Chien uses to refer to that process is irrelevant.
Regarding the term ‘salt’, the claim uses this term as a label for data which is input to a hash function along with video data to be sent. HMAC describes inputting a ‘key’ to a hash function along with data to be sent. Therefore, the ‘key’ of HMAC and the ‘key’ of Chien have both been mapped to the claimed ‘salt’. The prior art references are therefore consistent with each other, and the prior art ‘key’ satisfies all of the requirements of the claimed ‘salt’.
Applicant argues “HMAC presumes a secret key input and does not disclose generating a salt by hashing a ‘bitstring not extracted from the video data’ as recited in the independent claims.” However, Chien outputs a secret key because the method of transforming the timestamp into a key is secret, and there is no reason this poses an issue.
Applicant argues HMAC does not disclose hashing a first portion of the message/video data by itself to obtain “a hash of a first portion” and then combining that hash with the salt and hashing the combination. Applicant points to the pseudocode in HMAC which discloses an inner hash and outer hash. However, the inner hash of HMAC is being mapped to the claimed hash applied to the data, and the outer hash of HMAC is being mapped to the claimed hash applied to the combination. Additionally, this particular limitation is claimed as an alternative, and therefore is not necessary to be taught by the prior art.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT MICHAEL DIROMA whose telephone number is (571)272-6430. The examiner can normally be reached Monday - Friday 12:30 pm - 8:30 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, Patrick McAtee can be reached on (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S.M.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698