DETAILED ACTION
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 04/16/2026, for application 19/097,790 has been entered.
This Office Action is in response to the Amendment filed on 04/16/2026. In the instant amendment: Claims 1, 4, 7, 10 17, 19-21 have been amended. Claims 1, 3-5, 7, 9-21 have been examined and are pending.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 01/23/2026, 02/04/2026 and 04/21/2026 are compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner.
Examiner’s Notes
To expediate prosecution, the Examiner contacted applicant’s representative, Michael Glenn (Reg. No. 30176), for an Examiner’s amendment. However, the Examiner and the applicant’s representative were able to reach an agreement.
Objection to Drawings:
The drawings (FIGs 1, 2, 3, 4, 8, 9A, 9B, 9C, 14 (incomplete labels), 15 (incomplete labels), 16, 22, 23, 24, 25, and 26) are objected to under 37 CFR 1.83(a) because they fail to show components as described in the specification.
For example, FIG. 1 lacks any labeling of components (e.g., labeling for components 12, 14, 16, 31, 33, 41, 43, 61, 62), as described in the Specification page 12, lines 1-14.
FIG. 2 lacks any labeling of components (e.g., labeling for components 11, 12, 16, 14, 20, 43, 63), as described in the Specification page 12, lines 19-32; page 13: lines 1-16.
FIG. 3 lacks any labeling of components (e.g., for components 33, 41 43, 45, 49), as described in the Specification page 14, lines 15-19.
Similarly, each of the remaining FIGs 4, 8, 9A, 9B, 9C, 14 (incomplete labels), 15 (incomplete labels), 16, 22, 23, 24, 25, and 26 lacks adequate labelling for components and/or steps as described in the corresponding sections of the Specification.
Any structural detail that is essential for a proper understanding of the disclosed invention should be shown in the drawing. MPEP § 608.02(d). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Correction is requested.
Claim Objections
Claims 17 is objected to because of the following informalities:
Regarding claim 17, claim 1 recites “Decoder according to claim 1.” When a term first appears, “a/an” should be used. Whenever referring back to such a previously mentioned term, article “the” should be used. The claim language should be amended to “The decoder according to claim 1.” Correction is requested.
Response to Arguments
Applicants' arguments in the instant Amendment, filed on 04/16/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant Argues: Jacobson fails to disclose “wherein the one or more processors are configured for locating the predetermined portion within the audio data stream by use of a first supplemental information message and a second supplemental information message interspersed into the audio data stream and determining the predetermined portion to be a section of the audio data stream extending between, or located between, the first and the second supplemental information messages,” and “wherein the one or more processors are configured for decoding the digital signature from the second supplemental information message of the audio data stream, the second supplemental information message being interspersed between coded audio packets of the audio data stream” of amended claim 1. See Remarks 12-13.
The examiner respectfully disagrees because these arguments are not persuasive.
Applicant first asserts that “Jacobson does not disclose decoding the digital signature to be used for verifying the predetermined portion of the audio data stream from a supplemental information message which is interspersed between coded audio packets of the audio data stream.” Id. at 10 (emphasis added). Applicant also explains that “supplemental information refers to information which supplements the coded media data of a data stream, which may also be referred to as metadata.” Id. at 9 (emphasis added).
In contrast to applicant’s assertions, Jacobson discloses a system that captures an audio session, generates a hash and digital signature for the audio session, defines a “start frame” and “end frame” for a multimedia data stream1 that includes both metadata and digital signature for an audio stream segment, extracts audio stream from a video recording (multimedia data stream), and verifies authentication of extracted audio stream against the audio digital signature:
In FIG. 2A is shown a flow chart of a typical method for encoding a SEDW. At 201, a user (for example a person speaking publicly) wears a SEDW in the form of a TrueBadge. At 202, the TrueBadge receives ambient audio. At 203, the TrueBadge displays encoded, time-stamped audio slices, and records at least a portion of the audio. At 204, the at least a portion of the audio is hashed and signed with the speaker's private key.
At 211, video to be authenticated is captured and at 212, is applied (e.g., uploaded) to a DeepAuthentic application (described in more detail below). At 213, the DeepAuthentic application reads and reproduces at least a portion of the audio from the video to be authenticated. At 214, the DeepAuthentic applications retrieves the TrueBadge encoded audio, and at 215 hashes the at least a portion of the audio from the video to be authenticated, decodes the TrueBadge encoded audio using a public key, and compares the hashed portion to the decoded audio to determine if the video is authentic.
StartFrame: First frame of a session. Can display metadata, encrypted and unencrypted data shown before immediately successive frames showing session media. In the case of video recordings of a speaker with a TrueBadge- a missing StartFrame or EndFrame raises suspicion against the purported video recording of a scene.
End Frame: An end of session frame which can be displayed for a prolonged period marking the end of a session and in some cases displaying meta-data, encrypted and unencrypted, such as a digital signature for the whole last session.
At 608 a number of extraction/verification processes occur (e.g., for error messages, applying public keys to extract encrypted data, verification of continuous sequence of frames and filling in of missing frames, verification of digital signatures, extraction of signed audio or hash of session audio, ….
Verification of the audio in a video of the scene is shown in FIG. 5B. Like FIG. 5A, at 511 scene information and metadata are input, and at 512 are hashed. At 513, the hashed value is encoded. At 514 the digital signature is displayed (e.g., the digital signature 506 of FIG. 5A) and at 515 decrypted with public key 516. At 517, the decrypted data (i.e., the hashed information or audio) are compared to signed, or private key encryption of the hash which is decrypted with a public key. AT 518, if the two match, the hashed audio is displayed.
See Jacobson FIGs 2A-2B, 5A-5B, 6, ¶¶ [0037]-[0038], Data units and User Option Charts (“start frame”, “end frame”), [0177], [0214] (emphasis added).
In Jacobson, a system can capture audio signals from a selected session, hash and then digitally sign the hashed session. To verify the authenticity of an audio clip, the system can locate a “start frame” and “end frame” for a multimedia session. Here, one of more of the “start frame” and “end frame” can include relevant metadata and digital signature (aka acts as a “supplemental information” message or digest). The system can extract audio signals from the multimedia session2 between the “start frame” and “end frame.” The system then hashes the extracted audio signals and compares it against the decrypted digital signature. If there is a match, the system verifies the authenticity of the audio session.
Accordingly, Jacobson teaches “wherein the one or more processors are configured for locating the predetermined portion within the audio data stream by use of a first supplemental information message and a second supplemental information message interspersed into the audio data stream and determining the predetermined portion to be a section of the audio data stream extending between, or located between, the first and the second supplemental information messages,” and “wherein the one or more processors are configured for decoding the digital signature from the second supplemental information message of the audio data stream, the second supplemental information message being interspersed between coded audio packets of the audio data stream” of amended claim 1.
Accordingly, Jacobson teaches the above amended limitations. In conclusion, applicant’s argument is unpersuasive and the rejection of amended claims 1 is maintained. Rejections of claims 19-21, which recite similar matters, is similarly maintained.
Applicant’s argument with respect to amended independent claims 1, 19-21 have been considered but are moot in view of the new ground(s) of rejection. Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action.
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 discloses as set forth in section 102 of this title, 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-5. 7, 9-21 are rejected under 35 U.S.C. 103 as being unpatentable over Jacobson (“Jacobson,” US 20240235847, filed July 22, 2022) in view of in view of Xu et al. (“Xu,” US 20170141926, published May 18, 2017).
Regarding claim 1, Jacobson discloses
A decoder for decoding an audio stream from an audio data stream, wherein the decoder comprises: a memory, and one or more processors configured for (Jacobson [0034], [0044]. As used herein, “display” as in a SEDW device may be a screen (e.g., as part of a smartwatch, smartphone, mobile device, etc.), or may be specialized SEDW device hardware. In their simplest form, embodiments of the present invention advantageously provide systems and methods for encoding a SEDW with audio data and metadata from an actual scene or occurrence, decoding such SEDWs, and verifying media data by comparing the media data with the decoded audio data and metadata. A TrueBadge may comprise a mobile computer (a processor) with a display and an audio detection component (e.g., a microphone). )
decoding, from the audio data stream, a digital signature to be subjected to a check of the audio data stream on trustworthiness by (Jacobson FIGs 2A-2B, [0037]-[0038]. In FIG. 2A is shown a flow chart of a typical method for encoding a SEDW. At 201, a user (for example a person speaking publicly) wears a SEDW in the form of a TrueBadge. At 202, the TrueBadge receives ambient audio. At 203, the TrueBadge displays encoded, time-stamped audio slices, and records at least a portion of the audio. At 204, the at least a portion of the audio is hashed and signed with the speaker's private key. At 211, video to be authenticated is captured and at 212, is applied (e.g., uploaded) to a DeepAuthentic application (described in more detail below). At 213, the DeepAuthentic application reads and reproduces at least a portion of the audio from the video to be authenticated. At 214, the DeepAuthentic applications retrieves the TrueBadge encoded audio, and at 215 hashes the at least a portion of the audio from the video to be authenticated, decodes the TrueBadge encoded audio using a public key, and compares the hashed portion to the decoded audio to determine if the video is authentic.);
subjecting a predetermined portion of the audio data stream, or data derived therefrom, to a hash function to acquire a hash value; and checking whether the hash value fits to the digital signature to determine whether the audio data stream is trustworthy (Jacobson Data units and User Option Charts (“start frame”, “end frame”), [0177], [0214]. StartFrame: First frame of a session. Can display metadata, encrypted and unencrypted data shown before immediately successive frames showing session media. In the case of video recordings of a speaker with a TrueBadge- a missing StartFrame or EndFrame raises suspicion against the purported video recording of a scene.End Frame: An end of session frame which can be displayed for a prolonged period marking the end of a session and in some cases displaying meta-data, encrypted and unencrypted, such as a digital signature for the whole last session. At 608 a number of extraction/verification processes occur (e.g., for error messages, applying public keys to extract encrypted data, verification of continuous sequence of frames and filling in of missing frames, verification of digital signatures, extraction of signed audio or hash of session audio, …. Verification of the audio in a video of the scene is shown in FIG. 5B. Like FIG. 5A, at 511 scene information and metadata are input, and at 512 are hashed. At 513, the hashed value is encoded. At 514 the digital signature is displayed (e.g., the digital signature 506 of FIG. 5A) and at 515 decrypted with public key 516. At 517, the decrypted data (i.e., the hashed information or audio) are compared to signed, or private key encryption of the hash which is decrypted with a public key. AT 518, if the two match, the hashed audio is displayed.);
deriving, from the audio data stream (Jacobson [0038]. At 213, the DeepAuthentic application reads and reproduces at least a portion of the audio from the video to be authenticated. At 214, the DeepAuthentic applications retrieves the TrueBadge encoded audio, and at 215 hashes the at least a portion of the audio from the video to be authenticated, decodes the TrueBadge encoded audio using a public key, and compares the hashed portion to the decoded audio to determine if the video is authentic.);
wherein the one or more processors are configured for locating the predetermined portion within the audio data stream by use of a first supplemental information message and a second supplemental information message interspersed into the audio data stream and determining the predetermined portion to be a section of the audio data stream extending between, or located between, the first and the second supplemental information messages (Jacobson Data units and User Option Charts (“start frame”, “end frame”), [0177], [0214]. StartFrame: First frame of a session. Can display metadata, encrypted and unencrypted data shown before immediately successive frames showing session media. In the case of video recordings of a speaker with a TrueBadge- a missing StartFrame or EndFrame raises suspicion against the purported video recording of a scene.End Frame: An end of session frame which can be displayed for a prolonged period marking the end of a session and in some cases displaying meta-data, encrypted and unencrypted, such as a digital signature for the whole last session. At 608 a number of extraction/verification processes occur (e.g., for error messages, applying public keys to extract encrypted data, verification of continuous sequence of frames and filling in of missing frames, verification of digital signatures, extraction of signed audio or hash of session audio, …. Verification of the audio in a video of the scene is shown in FIG. 5B. Like FIG. 5A, at 511 scene information and metadata are input, and at 512 are hashed. At 513, the hashed value is encoded. At 514 the digital signature is displayed (e.g., the digital signature 506 of FIG. 5A) and at 515 decrypted with public key 516. At 517, the decrypted data (i.e., the hashed information or audio) are compared to signed, or private key encryption of the hash which is decrypted with a public key. AT 518, if the two match, the hashed audio is displayed.);
wherein the one or more processors are configured for decoding the digital signature from the second supplemental information message of the audio data stream, the second supplemental information message being interspersed between coded audio packets of the audio data stream (Jacobson Data units and User Option Charts (“end frame”), [0177], [0214]. End Frame: An end of session frame which can be displayed for a prolonged period marking the end of a session and in some cases displaying meta-data, encrypted and unencrypted, such as a digital signature for the whole last session. At 608 a number of extraction/verification processes occur (e.g., for error messages, applying public keys to extract encrypted data, verification of continuous sequence of frames and filling in of missing frames, verification of digital signatures, extraction of signed audio or hash of session audio, …. Verification of the audio in a video of the scene is shown in FIG. 5B. Like FIG. 5A, at 511 scene information and metadata are input, and at 512 are hashed. At 513, the hashed value is encoded. At 514 the digital signature is displayed (e.g., the digital signature 506 of FIG. 5A) and at 515 decrypted with public key 516. At 517, the decrypted data (i.e., the hashed information or audio) are compared to signed, or private key encryption of the hash which is decrypted with a public key. AT 518, if the two match, the hashed audio is displayed.).
Jacobson does not explicitly disclose: deriving, from the audio data stream, a syntax element signaling a hash function indicator, which is indicative of the hash function.
However, in an analogous art, Xu discloses a decoder comprising: deriving, from the [audio] data stream, a syntax element signaling a hash function indicator, which is indicative of the hash function ( Xu [0123]. The signature token can be included in any suitable portion of the message. For instance, the signature token can included as a header field in the header portion of the message or inserted into the body of the message. In some other embodiments, the signature token may be appended at the end of the message or prepended to the beginning of the message. In various embodiments, the signed message includes information about the algorithm(s) used to transform or encode the message so as to help a receiver of the message to decode or authenticate the message. For example, the message can include information about the cryptographic algorithm used to generate the signature, the hash function used to generate the hashes of the message header and message body, and encryption algorithm used to encrypt the message, the order in which data objects are arranged, and the like. Such information may be included, for example, in the header fields of the message.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the embodiments of Xu and Jacobson to include: deriving, from the [audio] data stream, a syntax element signaling a hash function indicator, which is indicative of the hash function. One would have been motivated to provide users with a means for obtaining hash protocol for signature verification from a signature token. (See Xu [0123].)
Regarding claim 3, Jacobson and Xu disclose the decoder of claim 1. Jacobson further discloses wherein the check of the audio data stream on trustworthiness comprises decrypting the digital signature to acquire a check value; and checking whether the hash value matches the check value (Jacobson FIGs 4A-4B, [0069]-[0070]. Referring to FIGS. 4A-B therein are shown a diagram showing exemplary aspects of a system for encoding (FIG. 4A) and for decoding (FIG. 4B). [A] TrueBadge may receive ambient audio via a microphone 402, portions of ambient audio may be recorded 403, portions of audio are hashed 404, hashed portions of audio are then signed with the individual's private key 405. The system for decoding FIG. 4B may comprise an individual viewing media to be authenticated 411, … , the DeepAuthentic application reads and reproduces TrueBadge encoded audio 413, the TrueBadge present in the media displays images 414, the TrueBadge encoded audio is then hashed 415, the images produced in the media each have a unique signature that is decrypted using the media provider's public key 416, and the decrypted signature is compared with hashed audio portion 417 to determine if there is a match 418, and if so, the authentication may be displayed 419 on the user's mobile device.).
Regarding claim 4, Jacobson and Xu disclose the decoder of claim 1. Jacobson further discloses wherein the check of the audio data stream on trustworthiness comprises locating the predetermined portion within the audio data stream by use of one or more supplemental information messages interspersed into the audio data stream and determining the predetermined portion to be a section of the audio data stream extending between, or extending from, the one or more supplemental information messages (Jacobson’s Data units and User Option Charts (“start frame”, “end frame”), [0177]. StartFrame: First frame of a session. Can display metadata, encrypted and unencrypted data shown before immediately successive frames showing session media. In the case of video recordings of a speaker with a TrueBadge- a missing StartFrame or EndFrame raises suspicion against the purported video recording of a scene.End Frame: An end of session frame which can be displayed for a prolonged period marking the end of a session and in some cases displaying meta-data, encrypted and unencrypted, such as a digital signature for the whole last session. An end of session frame which can be displayed for a prolonged period marking the end of a session and in some cases displaying meta-data, encrypted and unencrypted, such as a digital signature for the whole last session. At 608 a number of extraction/verification processes occur (e.g., for error messages, applying public keys to extract encrypted data, verification of continuous sequence of frames and filling in of missing frames, verification of digital signatures, extraction of signed audio or hash of session audio, extraction of secure link to user profile page, and running an artificial intelligence program to match audio output from TrueBadge output or cloud stored recording with suspect video audio).).
Regarding claim 5, Jacobson and Xu disclose the decoder of claim 4. Jacobson further discloses configured for decoding the digital signature from one of the one or more supplemental information messages of the audio data stream (Jacobson’s “end frame,” [0177]. An end of session frame which can be displayed for a prolonged period marking the end of a session and in some cases displaying meta-data, encrypted and unencrypted, such as a digital signature for the whole last session. At 608 a number of extraction/verification processes occur (e.g., for error messages, applying public keys to extract encrypted data, verification of continuous sequence of frames and filling in of missing frames, verification of digital signatures, extraction of signed audio or hash of session audio, extraction of secure link to user profile page, and running an artificial intelligence program to match audio output from TrueBadge output or cloud stored recording with suspect video audio).).
Regarding claim 7, Jacobson and Xu disclose the Decoder of claim 1. Jacobson further discloses configured for locating the predetermined portion within the audio data stream by use of a first supplemental information message and a second supplemental information message interspersed into the audio data stream and determining the predetermined portion to be a section of the audio data stream extending between, or located between, the first supplemental information message and a point in the data stream which is located downstream the second supplemental information message (Jacobson’s “start frame” and “end frame,” [0177]. First frame of a session. Start Frame: Can display metadata, encrypted and unencrypted data shown before immediately successive frames showing session media. In the case of video recordings of a speaker with a TrueBadge- a missing StartFrame or EndFrame raises suspicion against the purported video recording of a scene. An end of session frame which can be displayed for a prolonged period marking the end of a session and in some cases displaying meta-data, encrypted and unencrypted, such as a digital signature for the whole last session. In many cases this can play a cryptographic role, because its absence can belie a video of the scene that purports to be complete. At 608 a number of extraction/verification processes occur (e.g., for error messages, applying public keys to extract encrypted data, verification of continuous sequence of frames and filling in of missing frames, verification of digital signatures, extraction of signed audio or hash of session audio, extraction of secure link to user profile page, and running an artificial intelligence program to match audio output from TrueBadge output or cloud stored recording with suspect video audio).).
Regarding claim 9, Jacobson and Xu disclose the decoder of claim 1. Jacobson further discloses configured for deriving from an overview supplemental information message of the audio data stream, the overview supplemental information message indicating one or more substreams of the audio data stream with respect to each of which the checking the audio data stream on trustworthiness is possible based on one or more portions in the respective substream (Jacobson’s “start frame” and “end frame,” [0080], [0177]. First frame of a session. Start Frame: Can display metadata, encrypted and unencrypted data shown before immediately successive frames showing session media. In the case of video recordings of a speaker with a TrueBadge- a missing StartFrame or EndFrame raises suspicion against the purported video recording of a scene. An end of session frame which can be displayed for a prolonged period marking the end of a session and in some cases displaying meta-data, encrypted and unencrypted, such as a digital signature for the whole last session. In many cases this can play a cryptographic role, because its absence can belie a video of the scene that purports to be complete. In some embodiments, the entire audio can be captured and rebroadcast as encrypted audio. To prevent splicing and reordering or insertions from other speeches, the start time, elapsed time and Session ID may also be encrypted with private keys. The encrypted data may be decrypted with public published ones. Unencrypted forward error correcting codes and encrypted and unencrypted metadata can be included in the broadcast. Again, in ordinary cases, public keys allow verifiers access to the protected audio. At 608 a number of extraction/verification processes occur (e.g., for error messages, applying public keys to extract encrypted data, verification of continuous sequence of frames and filling in of missing frames, verification of digital signatures, extraction of signed audio or hash of session audio, extraction of secure link to user profile page, and running an artificial intelligence program to match audio output from TrueBadge output or cloud stored recording with suspect video audio).).
Regarding claim 10, Jacobson and Xu disclose the decoder of claim 1. Jacobson further discloses wherein the check of the audio data stream on trustworthiness comprises
performing the checking the audio data stream on trustworthiness sequentially with respect to a plurality of portions of the audio data stream (Jacobson [0036], [0177]. FIG. 1 shows a graphical representation of a user wearing a SEDW (in the form of a display badge) 101, which displays encoded images 102, and authenticates a variety of aspects of a recorded video of the user (e.g., the badge itself, the user, time signatures, sequences, displayed audio, audio in the video, etc.), flags errors, and displays, for example, on a mobile device 103, the results of the authentication. At 608 a number of extraction/verification processes occur (e.g., for error messages, applying public keys to extract encrypted data, verification of continuous sequence of frames and filling in of missing frames, verification of digital signatures, extraction of signed audio or hash of session audio, extraction of secure link to user profile page, and running an artificial intelligence program to match audio output from TrueBadge output or cloud stored recording with suspect video audio).), and further by
checking whether the hash value and further data derived from subjecting a previous portion of the audio data stream to the hash function, fit to the digital signature (Jacobson [0070], [0177]. The system for decoding FIG. 4B may comprise an individual viewing media to be authenticated 411, … , the DeepAuthentic application reads and reproduces TrueBadge encoded audio 413, the TrueBadge present in the media displays images 414, the TrueBadge encoded audio is then hashed 415, the images produced in the media each have a unique signature that is decrypted using the media provider's public key 416, and the decrypted signature is compared with hashed audio portion 417 to determine if there is a match 418, and if so, the authentication may be displayed 419 on the user's mobile device. At 608 a number of extraction/verification processes occur (e.g., for error messages, applying public keys to extract encrypted data, verification of continuous sequence of frames and filling in of missing frames, verification of digital signatures, extraction of signed audio or hash of session audio, extraction of secure link to user profile page, and running an artificial intelligence program to match audio output from TrueBadge output or cloud stored recording with suspect video audio).), or whether a combined hash value derived by hashing the predetermined portion and a further hash value acquired by subjecting a previous portion of the audio data stream, or further data derived therefrom, to the hash function, fits to the digital signature.
Regarding claim 11, Jacobson and Xu disclose the decoder of claim 10. Jacobson further discloses wherein the check of the audio data stream on trustworthiness comprises subjecting the predetermined portion and the further hash value acquired by subjecting a previous portion of the audio data stream, or further data derived therefrom, to the hash function, to a combination to acquire a combined hash value and checking whether the combined hash value fits to the digital signature (Jacobson [0200], [0201]. Method for authenticating media data typically comprise: (i) capturing media data to be authenticated, where the media data includes video of a display badge containing an encoded first hash of one or more recorded portions of audio data of an actual event; (ii) identifying the encoded first hash; (iii) creating a second hash of some or all of the audio portion of the media data; (iv) comparing the first and second hashes; and (v) determining, based on the comparing, whether the audio has been manipulated or altered between a generation of the first hash and a generation of the second hash. In some embodiments, the first hash includes a digital signature generated using one or more private keys, and the method further comprises applying one or more public keys to verify the digital signature.).
Regarding claim 12, Jacobson and Xu disclose the decoder of claim 1. Jacobson further discloses wherein the check of the audio data stream on trustworthiness comprises further checking whether a parametrization of, or an identifier of, the hash function fits to the digital signature to determine whether the audio data stream is trustworthy (Jacobson FIG. 4B, [0069]-[0070]. Referring to FIGS. 4A-B therein are shown a diagram showing exemplary aspects of a system for encoding (FIG. 4A) and for decoding (FIG. 4B). [A] TrueBadge may receive ambient audio via a microphone 402, portions of ambient audio may be recorded 403, portions of audio are hashed 404, hashed portions of audio are then signed with the individual's private key 405. The system for decoding FIG. 4B may comprise an individual viewing media to be authenticated 411, … , the DeepAuthentic application reads and reproduces TrueBadge encoded audio 413, the TrueBadge present in the media displays images 414, the TrueBadge encoded audio is then hashed 415, the images produced in the media each have a unique signature that is decrypted using the media provider's public key 416, and the decrypted signature is compared with hashed audio portion 417 to determine if there is a match 418, and if so, the authentication may be displayed 419 on the user's mobile device.).
Regarding claim 13, Jacobson and Xu disclose the decoder of claim 1. Jacobson further discloses wherein the digital signature is fitted to by a predetermined value in case of an equality of the predetermined value with a check value acquired by decrypting the digital signature, or a predetermined portion of the check value associated with the predetermined value (Jacobson FIG. 4B, [0069]-[0070]. Referring to FIGS. 4A-B therein are shown a diagram showing exemplary aspects of a system for encoding (FIG. 4A) and for decoding (FIG. 4B). [A] TrueBadge may receive ambient audio via a microphone 402, portions of ambient audio may be recorded 403, portions of audio are hashed 404, hashed portions of audio are then signed with the individual's private key 405. The system for decoding FIG. 4B may comprise an individual viewing media to be authenticated 411, … , the DeepAuthentic application reads and reproduces TrueBadge encoded audio 413, the TrueBadge present in the media displays images 414, the TrueBadge encoded audio is then hashed 415, the images produced in the media each have a unique signature that is decrypted using the media provider's public key 416, and the decrypted signature is compared with hashed audio portion 417 to determine if there is a match 418, and if so, the authentication may be displayed 419 on the user's mobile device.), or
an equality with the check value in a further hashed domain, reached by a further hash function applied onto the predetermined value or a concatenation of value comprising the predetermined value.
Regarding claim 14, Jacobson and Xu disclose the decoder of claim 1. Jacobson further discloses wherein the check of the audio data stream on trustworthiness comprises a use of an asymmetric decryption scheme using a public key (Jacobson [0070]. The system for decoding FIG. 4B may comprise an individual viewing media to be authenticated 411, … , the DeepAuthentic application reads and reproduces TrueBadge encoded audio 413, the TrueBadge present in the media displays images 414, the TrueBadge encoded audio is then hashed 415, the images produced in the media each have a unique signature that is decrypted using the media provider's public key 416, and the decrypted signature is compared with hashed audio portion 417 to determine if there is a match 418, and if so, the authentication may be displayed 419 on the user's mobile device.).
Regarding claim 15, Jacobson and Xu disclose the decoder of claim 14. Jacobson further discloses configured for deriving the asymmetric decryption scheme using a first information derived from the data stream, wherein the first information comprises a decryption scheme indicator or a first pointer to a first location from which the asymmetric decryption scheme may be determined, or an identifier of the entity having encoded the audio into the audio data stream (Jacobson [0084]-[0085]. In an exemplary embodiment, the unencrypted text note sends the decoder to the appropriate public key repositories. If the public keys fails to decode a test token, which when properly decrypted says “Valid”, then the public keys will produce non-sense or unreadable information indicating the TrueBadge is fake or spoofed. Next, the decrypted test token will indicate this to the decoder. A second validity check can compare an encrypted public key repository index with the encrypted one. These repositories of public keys, which can be at well-known public key URLs, such as MIT, the speaker's website, or in the https information at the speaker's website, will allow the decoder to extract the Sigs information.).
Regarding claim 16, Jacobson and Xu disclose the decoder of claim 14. Jacobson further discloses configured for deriving the public key using a second information derived from the data stream, wherein the second information comprises a second pointer to a second location from which the public key may be retrieved, or an identifier of the entity having encoded the audio into the audio data stream (Jacobson [0084]-[0085]. In an exemplary embodiment, the unencrypted text note sends the decoder to the appropriate public key repositories. If the public keys fails to decode a test token, which when properly decrypted says “Valid”, then the public keys will produce non-sense or unreadable information indicating the TrueBadge is fake or spoofed. Next, the decrypted test token will indicate this to the decoder. A second validity check can compare an encrypted public key repository index with the encrypted one. These repositories of public keys, which can be at well-known public key URLs, such as MIT, the speaker's website, or in the https information at the speaker's website, will allow the decoder to extract the Sigs information.).
Regarding claim 17, Jacobson and Xu the decoder of claim 1.
Jacobson further discloses checking whether a parameter of, or identifier of the hash function fits to the digital signature to determine whether the audio data stream is trustworthy (Jacobson FIGs 2A-2B, [0037]-[0038]. In FIG. 2A is shown a flow chart of a typical method for encoding a SEDW. At 201, a user (for example a person speaking publicly) wears a SEDW in the form of a TrueBadge. At 202, the TrueBadge receives ambient audio. At 203, the TrueBadge displays encoded, time-stamped audio slices, and records at least a portion of the audio. At 204, the at least a portion of the audio is hashed and signed with the speaker's private key. At 211, video to be authenticated is captured and at 212, is applied (e.g., uploaded) to a DeepAuthentic application (described in more detail below). At 213, the DeepAuthentic application reads and reproduces at least a portion of the audio from the video to be authenticated. At 214, the DeepAuthentic applications retrieves the TrueBadge encoded audio, and at 215 hashes the at least a portion of the audio from the video to be authenticated, decodes the TrueBadge encoded audio using a public key, and compares the hashed portion to the decoded audio to determine if the video is authentic.).
Regarding claim 18, Jacobson and Xu disclose the decoder of claim 1. Jacobson further discloses providing the predetermined portion for being subject, along with further data derived from a portion of a media stream accompanying the audio data stream to a trustworthiness check of the audio data stream combined with the media stream (Jacobson [0200], [0201]. Method for authenticating media data typically comprise: (i) capturing media data to be authenticated, where the media data includes video of a display badge containing an encoded first hash of one or more recorded portions of audio data of an actual event; (ii) identifying the encoded first hash; (iii) creating a second hash of some or all of the audio portion of the media data; (iv) comparing the first and second hashes; and (v) determining, based on the comparing, whether the audio has been manipulated or altered between a generation of the first hash and a generation of the second hash. In some embodiments, the first hash includes a digital signature generated using one or more private keys, and the method further comprises applying one or more public keys to verify the digital signature.).
Regarding claim 19, Jacobson discloses
An apparatus for rendering an audio data stream having an audio stream encoded thereinto checkable on trustworthiness (Jacobson [0215]. For example, in one embodiment determined by the highly efficient audio codecs described, the TrueBadge displays both recorded audio information and a signed hash of metadata. Because the audio information is simultaneously displayed, and to prevent splicing the metadata, the successive audio data may optionally overlap with audio in the previous frames, and a simple program could render the audio data of the rebroadcast on the TrueBadge.),
wherein the apparatus comprises a memory and one or more processors configured for (Jacobson [0034], [0044]. As used herein, “display” as in a SEDW device may be a screen (e.g., as part of a smartwatch, smartphone, mobile device, etc.), or may be specialized SEDW device hardware. In their simplest form, embodiments of the present invention advantageously provide systems and methods for encoding a SEDW with audio data and metadata from an actual scene or occurrence, decoding such SEDWs, and verifying media data by comparing the media data with the decoded audio data and metadata. A TrueBadge may comprise a mobile computer (a processor) with a display and an audio detection component (e.g., a microphone). )
for subjecting a predetermined portion of the audio data stream, or data derived therefrom, to a hash function to acquire a hash value (Jacobson [0200], [0201]. Method for authenticating media data typically comprise: (i) capturing media data to be authenticated, where the media data includes video of a display badge containing an encoded first hash of one or more recorded portions of audio data of an actual event; (ii) identifying the encoded first hash; (iii) creating a second hash of some or all of the audio portion of the media data; (iv) comparing the first and second hashes; and (v) determining, based on the comparing, whether the audio has been manipulated or altered between a generation of the first hash and a generation of the second hash. In some embodiments, the first hash includes a digital signature generated using one or more private keys, and the method further comprises applying one or more public keys to verify the digital signature.);
computing a digital signature based on the hash value so as to digitally sign the hash function (Jacobson [0198]. Methods for encoding media data in a display badge typically comprise: (i) detecting, by an audio detection component operably connected to the display badge, at least a portion of ambient audio data of an event; (ii) encoding as all or part of one or more images, one or more digital representations of the at least a portion of the ambient audio data; (iii) hashing the at least a portion of the one or more digital representations; (iv) signing hashed data with a private key; and (v) displaying the one or more images and the signature on the display badge.); and
inserting the digital signature into the audio data stream, thereby allowing determining whether the audio data stream is trustworthy by checking whether the hash value fits to the digital signature (Jacobson FIGs 2A-2B, [0037]-[0038], Data units and User Option Charts (“start frame”, “end frame”). In FIG. 2A is shown a flow chart of a typical method for encoding a SEDW. At 201, a user (for example a person speaking publicly) wears a SEDW in the form of a TrueBadge. At 202, the TrueBadge receives ambient audio. At 203, the TrueBadge displays encoded, time-stamped audio slices, and records at least a portion of the audio. At 204, the at least a portion of the audio is hashed and signed with the speaker's private key. At 211, video to be authenticated is captured and at 212, is applied (e.g., uploaded) to a DeepAuthentic application (described in more detail below). At 213, the DeepAuthentic application reads and reproduces at least a portion of the audio from the video to be authenticated. At 214, the DeepAuthentic applications retrieves the TrueBadge encoded audio, and at 215 hashes the at least a portion of the audio from the video to be authenticated, decodes the TrueBadge encoded audio using a public key, and compares the hashed portion to the decoded audio to determine if the video is authentic. StartFrame: First frame of a session. Can display metadata, encrypted and unencrypted data shown before immediately successive frames showing session media. In the case of video recordings of a speaker with a TrueBadge- a missing StartFrame or EndFrame raises suspicion against the purported video recording of a scene.End Frame: An end of session frame which can be displayed for a prolonged period marking the end of a session and in some cases displaying meta-data, encrypted and unencrypted, such as a digital signature for the whole last session.);
wherein the one or more processors are configured for inserting, into the audio data stream, a first supplemental information message and a second supplemental information message, which indicate a location of the predetermined portion within the audio data stream, in a manner that the predetermined portion is a section of the audio data stream extending between, or located between, the first and the second supplemental information messages (Jacobson Data units and User Option Charts (“start frame”, “end frame”), [0177], [0214]. StartFrame: First frame of a session. Can display metadata, encrypted and unencrypted data shown before immediately successive frames showing session media. In the case of video recordings of a speaker with a TrueBadge- a missing StartFrame or EndFrame raises suspicion against the purported video recording of a scene. End Frame: An end of session frame which can be displayed for a prolonged period marking the end of a session and in some cases displaying meta-data, encrypted and unencrypted, such as a digital signature for the whole last session. At 608 a number of extraction/verification processes occur (e.g., for error messages, applying public keys to extract encrypted data, verification of continuous sequence of frames and filling in of missing frames, verification of digital signatures, extraction of signed audio or hash of session audio, …. Verification of the audio in a video of the scene is shown in FIG. 5B. Like FIG. 5A, at 511 scene information and metadata are input, and at 512 are hashed. At 513, the hashed value is encoded. At 514 the digital signature is displayed (e.g., the digital signature 506 of FIG. 5A) and at 515 decrypted with public key 516. At 517, the decrypted data (i.e., the hashed information or audio) are compared to signed, or private key encryption of the hash which is decrypted with a public key. AT 518, if the two match, the hashed audio is displayed.);
wherein the one or more processors are configured for inserting the digital signature into the second supplemental information message of the audio data stream, the second supplemental information message being interspersed between coded audio packets of the audio data stream (Jacobson Data units and User Option Charts (“start frame”, “end frame”), [0177], [0214]. StartFrame: First frame of a session. Can display metadata, encrypted and unencrypted data shown before immediately successive frames showing session media. In the case of video recordings of a speaker with a TrueBadge- a missing StartFrame or EndFrame raises suspicion against the purported video recording of a scene. End Frame: An end of session frame which can be displayed for a prolonged period marking the end of a session and in some cases displaying meta-data, encrypted and unencrypted, such as a digital signature for the whole last session. At 608 a number of extraction/verification processes occur (e.g., for error messages, applying public keys to extract encrypted data, verification of continuous sequence of frames and filling in of missing frames, verification of digital signatures, extraction of signed audio or hash of session audio, …. Verification of the audio in a video of the scene is shown in FIG. 5B. Like FIG. 5A, at 511 scene information and metadata are input, and at 512 are hashed. At 513, the hashed value is encoded. At 514 the digital signature is displayed (e.g., the digital signature 506 of FIG. 5A) and at 515 decrypted with public key 516. At 517, the decrypted data (i.e., the hashed information or audio) are compared to signed, or private key encryption of the hash which is decrypted with a public key. AT 518, if the two match, the hashed audio is displayed.).
Jacobson does not explicitly disclose: inserting, into the audio data stream, a syntax element signaling a hash function indicator, which is indicative of the hash function.
However, in an analogous art, Xu discloses an apparatus, comprising: inserting, into the [audio] data stream, a syntax element signaling a hash function indicator, which is indicative of the hash function ( Xu [0123]. The signature token can be included in any suitable portion of the message. For instance, the signature token can included as a header field in the header portion of the message or inserted into the body of the message. In some other embodiments, the signature token may be appended at the end of the message or prepended to the beginning of the message. In various embodiments, the signed message includes information about the algorithm(s) used to transform or encode the message so as to help a receiver of the message to decode or authenticate the message. For example, the message can include information about the cryptographic algorithm used to generate the signature, the hash function used to generate the hashes of the message header and message body, and encryption algorithm used to encrypt the message, the order in which data objects are arranged, and the like. Such information may be included, for example, in the header fields of the message.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the embodiments of Xu and Jacobson to include: inserting, into the audio data stream, a syntax element signaling a hash function indicator, which is indicative of the hash function. One would have been motivated to provide users with a means for obtaining hash protocol for signature verification from a signature token. (See Xu [0123].)
Regarding claim 20, claim 20 is directed to a method corresponding to the decoder of claim 1. Claim 20 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 21, claim 21 is directed to a non-transitory computer-readable storage medium corresponding to the apparatus of claim 19. Claim 21 is similar to claim 19 and is therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Luu Pham can be reached on 571 270 5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR.
Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDWARD LONG/
Examiner, Art Unit 2439
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439
1 The Specification describes a digital signature based verification of a multi-media data stream “comprising multiple media data streams, such as multiple out of a video data stream, an audio data stream and a text data stream.” Id. at p.119, lines 1-5 (emphasis added). Furthermore, the Specification explains that the system “derives, from the multi-media data stream 9, substream information 89 indicating that the multi-media data stream comprises, or is composed of, a plurality of media substreams… For example, the plurality of media substreams comprises one or more video data streams, one or more audio data streams and/or one or more text data streams.” Id. at 121, lines 10-30.
2 Specification explains that the system “derives, from the multi-media data stream 9, substream information 89 indicating that the multi-media data stream comprises, or is composed of, a plurality of media substreams… For example, the plurality of media substreams comprises one or more video data streams, one or more audio data streams and/or one or more text data streams.” Id. at 121, lines 10-30. The amended claims do not exclude this embodiment.
Prosecution Insights