DETAILED ACTION
Acknowledgements
This Non-Final Office Action is in reply to Applicant’s RCE filed August 17, 2026, and to Applicant’s supplemental amendment filed August 18, 2026.
Claim 2 is currently canceled. Claims 19–21 are new.
Claims 1, 9, 14, 15 are currently amended.
Claims 1, 3–21 are currently pending.
Claims 1, 3–21 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 submissions filed on August 17, 2026, and August 18, 2026 have been entered.
Response to Amendment
To clarify the record, the examiner notes that the RCE filed 8/17/2026 requests entry of the after-final amendment filed 7/20/2026. Applicant then filed a supplemental amendment on 8/18/2026, which is marked up as though the after-final amendment was never entered. The 8/18/2026 is therefore a non-complaint amendment.
However, the supplemental amendment contains the same changes as the after-final amendment, along with further additions. Because this application is not in condition for allowance, because the error noted above is considered an error that would not otherwise prevent the subsequent examination of this application, and to show a good faith effort by the examiner to advance prosecution, the 8/18/2026 claim amendments are being examined.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-15, 19-20 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) in view of Ligatti (US 20190013941 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 by:
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, using a second hash function different from the first one-way cryptographic hash function, 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 to enable the recipient to validate the authenticity of the video data; and {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;
generating a salt by hashing the bitstring using a first […] hash function; {[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.
sharing, over a private communication path, a definition of the first […] hash function with the recipient, wherein the first […] hash function is maintained as a shared secret between a signer and the recipient, and wherein the shared definition enables the recipient to regenerate the salt by hashing the bitstring using the first […] hash function. {[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]”}
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.
HMAC in view of Digital Signature in view of Chien does not teach, however Ligatti teaches the following bolded language:
generating a salt by hashing the bitstring using a first one-way cryptographic hash function;
sharing, over a private communication path, a definition of the first one-way cryptographic hash function with the recipient, wherein the first one-way cryptographic hash function is maintained as a shared secret between a signer and the recipient, and wherein the shared definition enables the recipient to regenerate the salt by hashing the bitstring using the first one-way cryptographic hash function.
{[0045] “FIG. 1 illustrates a flow diagram for generating cryptographic keys based on static and dynamic seeds. It may be desirable to implement the keygen function, which receives static seeds and dynamic seeds as inputs and then outputs a secret key, as a cryptographic hash function with high avalanche effect, such as SHA-3, to ensure that entirely new keys are generated even when static seeds do not change.” [0056] “Device A may identify particular auxiliary data X, such as a fresh timestamp obtained on Device A and therefore unknown and not immediately accessible to Device B, to use for the current communication's dynamic seed D. As shown in FIG. 2, this auxiliary data X is carried through the communications in the protocol, ultimately arriving at Device B and enabling Device B to use the same data X to generate its local copy of the same dynamic seed D.”; [0039] “if Device A is generating a new key to enable Host A to communicate with Host B, Device A may base the new key on […] a fresh dynamic seed, for example the current time.”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to implement one of Chien’s selectable key generation processes using the cryptographic hash derivation taught by Ligatti in the process of HMAC in view of Digital Signature in view of Chien because it would substantially change the derived key as the current time changes, thereby ensuring an unpredictable/secure key.
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;
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. It does not appear to be written as a claimed method step, and it has no effect on any of the claimed method steps. Metadata associated with the video data is not mentioned anywhere else in the claim.
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.
Regarding claim 19
HMAC in view of Digital Signature in view of Chien does not teach, however Ligatti teaches:
The method of claim 1, wherein sharing the definition of the first one-way cryptographic hash function comprises granting the recipient access to software configured in view of the first one-way cryptographic hash function, wherein the software is a signature verification application configured to execute the first one- way cryptographic hash function to regenerate the salt without exposing the definition of the first one-way cryptographic hash function in plaintext to the recipient, and wherein the definition of the first one-way cryptographic hash function is deposited in a secure element or trusted platform module (TPM) accessible to the signature verification application. {Fig. 2-4, Device A/B [granting the recipient access to software]; [0034] “Devices may store static seeds in an electronic memory, such as nonvolatile flash memory or a protected Trusted Platform Module (TPM) memory segment.”; [0039] “if Device A is generating a new key to enable Host A to communicate with Host B, Device A may base the new key on […] a fresh dynamic seed, for example the current time.”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to implement the recipient derivation operation of HMAC in view of Digital Signature in view of Chien in view of Ligatti using Ligatti’s TPM storage and devices A/B because it would increase security by making it impossible for the recipient to access the static key (and thus ensuring only a recipient in possession of device B can perform the verification process).
Regarding claim 20
HMAC teaches:
The method of claim 1, wherein generating the first fingerprint comprises:
generating a video hash by hashing the first portion of the video data using a third hash function;
forming, in the memory, a combination of the salt and the video hash; and
hashing the combination using the second hash function,
wherein the third hash function is different from the second hash function. {Page 1 Definition, shown below}
PNG
media_image3.png
46
593
media_image3.png
Greyscale
H’(m) =
PNG
media_image4.png
33
227
media_image4.png
Greyscale
reads on third hash function.
H() reads on second hash function.
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 in view of Ligatti 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 in view of Ligatti 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 in view of Ligatti 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 in view of Ligatti, and Takagi teaches a clock synchronization method.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over HMAC in view of Digital Signature in view of Chien in view of Ligatti as applied to claim 1 above, and further in view of Kreiner (US 20100146287 A1).
Regarding claim 21
HMAC in view of Digital Signature in view of Chien in view of Ligatti does not teach, however Kreiner teaches:
The method of claim 1, further comprising extracting, according to a pre-agreed extraction algorithm, a subset of a data structure encoding a video frame as the first portion of the video data, wherein the pre-agreed extraction algorithm is maintained as a shared secret between the signer and the recipient, and wherein the pre-agreed extraction algorithm determines which portion of the data structure encoding the video frame is fingerprinted in generating the first fingerprint. {[0032] “The processor 306 then analyzes each media segment of the media signals to attempt to verify the signature of each media segment.”; [0050] “In addition to the signatures of other media segments, select media content may also be included in the data to be signed. As discussed above, the first X bits, the last X bits, scattered bits, and so forth may be selected for inclusion. So long as the playback processor 306 knows the scheme that was used to select the media content, the processor 306 can thus compare what media content is present in a media segment to what media content should be present as is revealed during the verification of the signature.”}
HMAC in view of Digital Signature in view of Chien in view of Ligatti teaches an authentication code generation process which can be used in place of a digital signature to authenticate generic data. Kreiner teaches a specific use case for digital signatures where they are applied to segments of media data.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention that the authentication code scheme of HMAC in view of Digital Signature in view of Chien in view of Ligatti could be applied to the segments of media data of Kreiner because it is a generic process that can be applied to any data and Ligatti specifically calls for signatures of its segments of data for data authentication purposes.
Response to Arguments
35 USC § 103
Applicant has amended the independent claims to require that the hash function used to generate the salt be a one-way cryptographic hash function. Applicant has also added new claims 19-21 which contain new limitations. Applicant argues that the new features are not taught by the cited art.
In response, the rejection has been updated to incorporate new references. Ligatti teaches a method of generating a cryptographic key using a cryptographic hash function on a timestamp, where the function is executed by a TPM. Ligatti therefore supplies the missing limitations with respect to the independent claims as well as claim 19. Kreiner teaches a method of generating signatures for individual segments of media data, and therefore supplies the missing limitations with respect to claim 21.
New claim 20 is taught by the art of record. HMAC teaches a fingerprint generation method that looks like:
PNG
media_image3.png
46
593
media_image3.png
Greyscale
Applicant argues HMAC does not teach using two different hash functions, but instead teaches using “H()” twice. However, the inner hash is really defining a different hash function:
H’(m) =
PNG
media_image4.png
33
227
media_image4.png
Greyscale
And therefore, the fingerprint is of the form HMAC(K,m) = H(K || H’(m)) with two different hash functions as claimed.
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 at (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
Prosecution Insights