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 . See 35 U.S.C. § 100 (note).
Art Rejections
Anticipation
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 21–24, 26–32 and 34–40 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US Patent Application Publication 2018/0132011 (published 10 May 2018) (“Shichman”).
Claim 21 is drawn to “a computer-implemented method for identifying a highlight boundary.” The following table illustrates the correspondence between the claimed method and the Shichman reference.
Claim 21
The Shichman Reference
“21. A computer-implemented method for identifying a highlight boundary, the computer-implemented method comprising:
The Shichman reference describes a corresponding computer-implemented method that uses a server computer 210 to analyze video content and identify the boundaries (e.g., start time and end time) of highlight events (i.e., events that meet a criteria). Shichman at Abs., ¶¶ 7, 8, 49, 166, FIG.3. Server computer 210 includes a controller 105 (e.g., CPU), memory 120 with executable code 125 that is executed by the controller. Id. at ¶¶ 28–37, 39, FIG.1.
“receiving, by one or more processors, an audiovisual stream via a computer server;
Shichman’s server computer 210 likewise receives audiovisual content 215 from other servers, such as IP digital video broadcasters and HLS archives. Id. at ¶¶ 38–42, 47, FIG.2.
“processing, by the one or more processors, audio data corresponding to the audiovisual stream using one or more digital signal processing techniques to detect one or more high-energy audio events;
Shichman’s server computer 210 performs an analysis of input 215 to detect events. The analysis includes applying a DSP 310 to the audio. Id. at ¶¶ 37, 49, 63, 65, 72, 133, 135, FIG.3. Server further applies several criteria to the detected events to detect highlights, such as sports highlights characterized by the presence of high-volume, or high-energy, audio, like the roar of a crowd (i.e., cheering). Id. at ¶¶ 83, 85.
“extracting, by the one or more processors, data corresponding to the one or more high-energy audio events; and
Server computer 210 extracts data corresponding to a detected highlight event. Id. at ¶¶ 43, 60, 63, 135. For instance, server computer 210 extracts the event’s boundaries (i.e., start time and end time) and other metadata about the event. Id.
“appending, by the one or more processors, the extracted data as metadata to the corresponding one or more high-energy audio events.”
Server computer 210 then appends the extracted data as metadata into metadata objects 440 and event objects 450 for the event. Id.
Table 1
For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 22 depends on claim 21, and further requires the following:
“the computer-implemented method further comprising:
“determining, by the one or more processors, at least one boundary based on the extracted data.
Shichman describes extracting the start and end times of events. Shichman at ¶ 65. Shichman also uses the extracted times in a fine-tuning process to produce fine-tuned boundaries that define each event that will later be extracted and stored as a video clip in video archive 230 by server 210. Id. at ¶¶ 39, 65, 104–106. For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 23 depends on claim 22, and further requires the following:
“the computer-implemented method further comprising:
“utilizing, by the one or more processors, the at least one boundary for determining a segment boundary in a highlight.”
Shichman describes using fine-tuned event boundaries to create segments with segment boundaries that define highlighted events. Shichman at ¶¶ 65, 104–106. Shichman then uses the boundaries of the video clip to determine a segment boundary for a video clip. For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 24 depends on claim 22, and further requires the following:
“wherein the at least one boundary includes a start time or an end time.”
Shichman describes extracting the start and end times of events. Shichman at ¶ 65. For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 26 depends on claim 21, and further requires the following:
“the computer-implemented method further comprising:
“outputting, by the one or more processors, the metadata to a user device.”
Shichman describes outputting metadata, such as metadata objects 440 and event objects 450 to a user’s device so the user may view and select highlight video clips. Shichman at ¶¶ 73–75, 98–102, FIG.5 (depicting a GUI for displaying and editing metadata associated with events within a video). For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 27 depends on claim 21, and further requires the following:
“the computer-implemented method further comprising:
“sorting, by the one or more processors, the one or more high-energy audio events.”
Shichman’s server 210 similarly sorts detected events to determine and display their importance. Shichman at ¶ 73, 74, 82. For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 28 depends on claim 21, and further requires the following:
“the computer-implemented method further comprising:
“storing, by the one or more processors, the one or more high-energy audio events in a data store.”
Shichman describes storing important sports highlight events as video clips in a database 220 and video archive 230, or data store. Shichman at ¶¶ 39, 55, 97, 122, 170, FIG.3. For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 29 is drawn to “a non-transitory computer-readable medium.” The following table illustrates the correspondence between the claimed medium and the Shichman reference.
Claim 29
The Shichman Reference
“29. A non-transitory computer-readable medium comprising one or more sequences of instructions, which, when executed by one or more processors, causes a computing system to perform operations comprising:
The Shichman reference describes a corresponding computer system that uses a server computer 210 to analyze video content and identify the boundaries (e.g., start time and end time) of highlight events (i.e., events that meet a criteria). Shichman at Abs., ¶¶ 7, 8, 49, 166, FIG.3. Server computer 210 includes a controller 105 (e.g., CPU), memory 120 (i.e., non-transitory computer-readable medium) with executable code 125 (i.e., one or more sequences of instructions) that is executed by the controller. Id. at ¶¶ 28–37, 39, FIG.1.
“receiving, by the computing system, an audiovisual stream via a computer server;
Shichman’s server computer 210 likewise receives audiovisual content 215 from other servers, such as IP digital video broadcasters and HLS archives. Id. at ¶¶ 38–42, 47, FIG.2.
“processing, by the computing system, audio data corresponding to the audiovisual stream using one or more digital signal processing techniques to detect one or more high-energy audio events;
Shichman’s server computer 210 performs an analysis of input 215 to detect events. The analysis includes applying a DSP 310 to the audio. Id. at ¶¶ 37, 49, 63, 65, 72, 133, 135, FIG.3. Server further applies several criteria to the detected events to detect highlights, such as sports highlights characterized by the presence of high-volume, or high-energy, audio, like the roar of a crowd (i.e., cheering). Id. at ¶¶ 83, 85.
“extracting, by the computing system, data corresponding to the one or more high-energy audio events; and
Server computer 210 extracts data corresponding to a detected highlight event. Id. at ¶¶ 43, 60, 63, 135. For instance, server computer 210 extracts the event’s boundaries (i.e., start time and end time) and other metadata about the event. Id.
“appending, by the computing system, the extracted data as metadata to the corresponding one or more high-energy audio events.”
Server computer 210 then appends the extracted data as metadata into metadata objects 440 and event objects 450 for the event. Id.
Table 2
For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 30 depends on claim 29, and further requires the following:
“the operations further comprising:
“determining, by the computing system, at least one boundary based on the extracted data.”
Shichman describes extracting the start and end times of events. Shichman at ¶ 65. Shichman also uses the extracted times in a fine-tuning process to produce fine-tuned boundaries that define each event that will later be extracted and stored as a video clip in video archive 230 by server 210. Id. at ¶¶ 39, 65, 104–106. For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 31 depends on claim 30, and further requires the following:
“the operations further comprising:
“utilizing, by the computing system, the at least one boundary for determining a segment boundary in a highlight.”
Shichman describes using fine-tuned event boundaries to create segments with segment boundaries that define highlighted events. Shichman at ¶¶ 65, 104–106. Shichman then uses the boundaries of the video clip to determine a segment boundary for a video clip. For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 32 depends on claim 31, and further requires the following:
“wherein the at least one boundary includes a start time or an end time.”
Shichman describes extracting the start and end times of events. Shichman at ¶ 65. For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 34 depends on claim 29, and further requires the following:
“the operations further comprising:
“outputting, by the computing system, the metadata to a user device.
Shichman describes outputting metadata, such as metadata objects 440 and event objects 450 to a user’s device so the user may view and select highlight video clips. Shichman at ¶¶ 73–75, 98–102, FIG.5 (depicting a GUI for displaying and editing metadata associated with events within a video). For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 35 is drawn to “a computer system for generating a video stream highlight.” The following table illustrates the correspondence between the claimed system and the Shichman reference.
Claim 35
The Shichman Reference
“35. A computer system for generating a video stream highlight, comprising:
“a processor and a memory having programming instructions stored thereon, which, when executed by the processor, causes the system to perform operations comprising:
The Shichman reference describes a corresponding computer system that uses a server computer 210 to analyze video content and identify the boundaries (e.g., start time and end time) of highlight events (i.e., events that meet a criteria). Shichman at Abs., ¶¶ 7, 8, 49, 166, FIG.3. Server computer 210 includes a controller 105 (e.g., CPU), memory 120 with executable code 125 that is executed by the controller. Id. at ¶¶ 28–37, 39, FIG.1.
“receiving, by the processor, an audiovisual stream via a computer server;
Shichman’s server computer 210 likewise receives audiovisual content 215 from other servers, such as IP digital video broadcasters and HLS archives. Id. at ¶¶ 38–42, 47, FIG.2.
“processing, by the processor, audio data corresponding to the audiovisual stream using one or more digital signal processing techniques to detect one or more high-energy audio events;
Shichman’s server computer 210 performs an analysis of input 215 to detect events. The analysis includes applying a DSP 310 to the audio. Id. at ¶¶ 37, 49, 63, 65, 72, 133, 135, FIG.3. Server further applies several criteria to the detected events to detect highlights, such as sports highlights characterized by the presence of high-volume, or high-energy, audio, like the roar of a crowd (i.e., cheering). Id. at ¶¶ 83, 85.
“extracting, by the processor, data corresponding to the one or more high-energy audio events; and
Server computer 210 extracts data corresponding to a detected highlight event. Id. at ¶¶ 43, 60, 63, 135. For instance, server computer 210 extracts the event’s boundaries (i.e., start time and end time) and other metadata about the event. Id.
“appending, by the processor, the extracted data as metadata to the corresponding one or more high-energy audio events.”
Server computer 210 then appends the extracted data as metadata into metadata objects 440 and event objects 450 for the event. Id.
Table 3
For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 36 depends on claim 35, and further requires the following:
“the operations further comprising:
“outputting, by the processor, the metadata to a user device.”
Shichman describes outputting metadata, such as metadata objects 440 and event objects 450 to a user’s device so the user may view and select highlight video clips. Shichman at ¶¶ 73–75, 98–102, FIG.5 (depicting a GUI for displaying and editing metadata associated with events within a video). For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 37 depends on claim 35, and further requires the following:
“the operations further comprising:
“sorting, by the processor, the one or more high-energy audio events.”
Shichman’s server 210 similarly sorts detected events to determine and display their importance. Shichman at ¶ 73, 74, 82. For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 38 depends on claim 35, and further requires the following:
“the operations further comprising:
“storing, by the processor, the one or more high-energy audio events in a data store.”
Shichman describes storing important sports highlight events as video clips in a database 220 and video archive 230, or data store. Shichman at ¶¶ 39, 55, 97, 122, 170, FIG.3. For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 39 depends on claim 35, and further requires the following:
“the operations further comprising:
“determining, by the processor, at least one boundary based on the extracted data.”
Shichman describes extracting the start and end times of events. Shichman at ¶ 65. Shichman also uses the extracted times in a fine-tuning process to produce fine-tuned boundaries that define each event that will later be extracted and stored as a video clip in video archive 230 by server 210. Id. at ¶¶ 39, 65, 104–106. For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Claim 40 depends on claim 39, and further requires the following:
“the operations further comprising:
“utilizing, by the processor, the at least one boundary for determining a segment boundary in a highlight.”
Shichman describes using fine-tuned event boundaries to create segments with segment boundaries that define highlighted events. Shichman at ¶¶ 65, 104–106. Shichman then uses the boundaries of the video clip to determine a segment boundary for a video clip. For the foregoing reasons, the Shichman reference anticipates all limitations of the claim.
Obviousness
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 25 and 33 are rejected under 35 U.S.C. § 103 as being unpatentable over Shichman.
Claim 25 depends on claim 21, and further requires the following:
“wherein the processing the audio data corresponding to the audiovisual stream using the one or more digital signal processing techniques to detect the one or more high-energy audio events further comprises:
“receiving, by the one or more processors, a compressed audio signal from the audiovisual stream; and
“decoding, by the one or more processors, the compressed audio signal.”
Shichman describes input 215 as including compressed audio. Shichman at ¶¶ 38–42, 47, FIG.2. Shichman further describes transcoding input 215 into any known format as needed. Id. at ¶¶ 41, 125, 129. This suggests decoding compressed audio for the purposes of processing and storage, as desired. See MPEP § 2143(I)(applying the known processes of decoding and transcoding to Shichman’s server, which is configured to process and store audio, in order to enable the server to process audio coded in any format with a single algorithm instead of an algorithm tailored to every known audio format). For the foregoing reasons, the Shichman reference makes obvious all limitations of the claim.
Claim 33 depends on claim 29, and further requires the following:
“wherein the processing the audio data corresponding to the audiovisual stream using the one or more digital signal processing techniques to detect the one or more high-energy audio events further comprises:
“receiving, by the computing system, a compressed audio signal from the audiovisual stream; and
“decoding, by the computing system, the compressed audio signal.”
Shichman describes input 215 as including compressed audio. Shichman at ¶¶ 38–42, 47, FIG.2. Shichman further describes transcoding input 215 into any known format as needed. Id. at ¶¶ 41, 125, 129. This suggests decoding compressed audio for the purposes of processing and storage, as desired. See MPEP § 2143(I)(applying the known processes of decoding and transcoding to Shichman’s server, which is configured to process and store audio, in order to enable the server to process audio coded in any format with a single algorithm instead of an algorithm tailored to every known audio format). For the foregoing reasons, the Shichman reference makes obvious all limitations of the claim.
Summary
Claims 21–40 are rejected under 35 U.S.C. §§ 102 and 103 as being unpatentable over the cited prior art. 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 C.F.R. § 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. § 102(b)(2)(C) for any potential 35 U.S.C. § 102(a)(2) prior art against the later invention.
Double Patenting
Legal Basis
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
Obviousness-Type Double Patenting
Claims 21, 29 and 35 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 17 of US Patent 11,264,048. Although the claims at issue are not identical, they are not patentably distinct from each other.
The following table illustrates correspondence between claim 21 of this Application and claims 1 and 17 of US Patent 11,264,048 (the ‘048 Patent).
Claim 21
The ‘048 Patent
“21. A computer-implemented method for identifying a highlight boundary, the computer-implemented method comprising:
1. A method for identifying a boundary of a highlight of audiovisual content depicting an event, the method comprising:
“receiving, by one or more processors, an audiovisual stream via a computer server;
“at a data store, storing audio data depicting at least part of the event
“processing, by the one or more processors, audio data corresponding to the audiovisual stream using one or more digital signal processing techniques to detect one or more high-energy audio events;
“at a processor, automatically analyzing the audio data to detect one or more audio events representing one or more occurrences to be included in the highlight, wherein each audio event is characterized by a high-energy audio burst of limited duration…
“wherein automatically analyzing the audio data to detect the one or more audio events comprises:
“performing digital filtering of the audio data for at least one of a time-domain analysis and a frequency-domain analysis;
“performing the time-domain analysis and the frequency-domain analysis to detect occurrences of high energy audio events in the audio data and to detect time spacing between the high energy audio events; and
“skipping the detected occurrences of the high energy audio events with time spacing below a minimum time threshold.”
“extracting, by the one or more processors, data corresponding to the one or more high-energy audio events; and
“at the processor, designating a time index, within the audiovisual content, defining the boundary, the boundary comprising one of a beginning of the highlight and an end of the highlight”.
“appending, by the one or more processors, the extracted data as metadata to the corresponding one or more high-energy audio events.”
“17. The method of claim 1, further comprising automatically appending at least one of the audio events, the time index, and an indicator of each occurrence to metadata associated with the highlight.”
Table 4
The differences between the claims of the ‘048 Patent and claim 1 of this Application are not patentably significant. First, claim 1 of the ‘048 Patent does not use the phrase “computer-implemented method”, but because each step of the method uses a computer component (e.e.,g a processor or data store), it effectively is drawn to a computer-implemented method.
Second, claim 1 of the ‘048 Patent does not receive by a processor audiovisual stream via a computer server. Rather, the method begins with audio data already present in a data store. The receipt of an audiovisual stream from a computer server, however, is a conventional technique used to populate a data store. See Shichman at ¶¶ 38–42, 47, FIG.2. It would have been obvious to modify the method of claim 1 to likewise perform the claimed receiving step. See MPEP § 2143(I)(D) (applying Shichman’s mechanism of using a processor to receive and store an audiovisual stream in a database to the computer of the ‘048 Patent claim 1 that needs to store an audiovisual stream).
Third, claim 1 of the ‘048 does not use the term “extracting”, but effectively extracts data by designating a time index within audiovisual content to define the boundary of a highlight. For the foregoing reasons, claim 25 is not patentably distinct from claims 1 and 17 of the Shichman reference. Similar findings and rationale also apply to claims 29 and 35 of this Application.
Summary
Claims 21, 29 and 35 are rejected for nonstatutory, obviousness-type double patenting. A timely filed terminal disclaimer in compliance with 37 C.F.R. § 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 C.F.R. § 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 C.F.R. § 1.111(a). For a reply to final Office action, see 37 C.F.R. § 1.113(c). A request for reconsideration while not provided for in 37 C.F.R. § 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WALTER F BRINEY III whose telephone number is (571)272-7513. The examiner can normally be reached M-F 8 am-4: 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, Carolyn Edwards can be reached at 571-270-7136. 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.
/Walter F Briney III/
Walter F Briney IIIPrimary ExaminerArt Unit 2692
8/19/2026
Prosecution Insights