DETAILED ACTON
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 1/16/2026 has been entered.
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 .
Response to Arguments
Applicant's arguments, see Remarks pg. 7 filed 1/16/2026, regarding the status of the claims have been fully considered and are hereby acknowledged. The examiner notes that a terminal disclaimer was filed on 12/23/2025 and has been considered. Therefore, the double patenting rejection is withdrawn.
Applicant's arguments, see Remarks pg. 7-8 filed 1/16/2026, regarding the rejection of the claims under 35 U.S.C. 103 have been fully considered. The examiner notes that the applicant’s arguments are directed to the limitations not previously presented. Therefore, the examiner will set forth a new grounds of rejection and rely on the prior art of record in order to take into consideration the newly amended limitations. In particular, with respect to the newly amended limitations, the applicant argues the following:
Applicant respectfully submits that Dimov in view of Logan, Maisenbacher, Packard and Cox fail to disclose, teach, or suggest inter alia "in response to the determining that the delay is greater than the threshold time: triggering analyzing, by a computing system, of content between the delayed portion of the live content stream and the live position of the live content stream to detect at least one event, wherein the analyzing by the computing system is triggered by the computing system determining that the delay is greater than the threshold time" as recited in Applicant's claim 51, as amended.
The Advisory Action at page 2 states "[t]he examiner agrees with Applicant with respect to "Cox teaches that transmitting notifications to a user device requires a minimum amount of time (threshold) for tagging and transmission plus an additional amount of time for "prelude" plus an amount of time to display an alert (see paragraph 93).""
The Advisory Action further states, at pages 2-3: "More importantly, the time-shifted or "delayed playback of content" of live content can be viewed during the time that the program is presented during a live broadcast," and, that "assuming arguendo, that a viewer watching a live program in a time-shifted manner which is only a couple seconds behind the live-point in the program, then Cox's appreciation of the threshold described in paragraph 93 is evident." The Advisory Action further reasons that "any viewer that was at least 14 seconds behind the live- point in the program would also not be able to get an alert notification in time" if Cox determines that a minimum amount of time is required to process and deliver alert notifications.
Applicant respectfully submits that Cox's "threshold" relates to whether an alert notification can be delivered to a user in time, not to triggering analysis of content by a computing system in response to determining that a playback delay exceeds a threshold, as recited in claim 51, as amended.
The examiner respectfully disagrees. First, in response to the applicant’s arguments, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). More importantly, on the issue of obviousness, the Supreme Court stated that when a patent simply arranges old elements with each performing the same function it had been known to perform and yields no more than one would expect from such an arrangement, the combination is obvious. KSR International Co. v. Teleflex Inc., 550 U.S. 398, 417, 82 USPQ2d 1385 (2007) (citing Sakraida v. AG Pro, Inc., 425 U.S. 273, 96 S. Ct. 1532, 47 L. Ed. 2d 784 (1976)). The Court further reiterated that in circumstances where the combination of two pre-existing elements did no more than they would in separate, sequential operation, the patent failed under 35 U.S.C. 103. See id. at 416-417 (citing Anderson's-Black Rock, Inc. v. Pavement Salvage Co., 396 U.S. 57, 90 S. Ct. 305, 24 L. Ed. 2d 258 (1969)). The analysis of a rejection on obviousness grounds need not seek out precise teachings directed to the specific subject matter of the challenged claim, for a court can take account of the inferences and creative steps that a person of ordinary skill in the art would employ. See id. at 418. The obvious analysis cannot be confined by a formalistic conception of the words teaching, suggestion, and motivation. Id. at 419. Further, the Court stated that common sense teaches, however, that familiar items may have obvious uses beyond their primary purposes, and in many cases a person of ordinary skill will be able to fit the teachings of multiple patents together like pieces of a puzzle. See id. at 420.
With respect to applicant’s arguments, the examiner did agree with the citation to Cox’s disclosure but the Advisory Action also states “[t]he examiner respectfully disagrees with the applicant’s characterization of the prior art with respect to the claimed limitation. Whereas the applicant’s argument states:
Applicant respectfully submits that Cox's "threshold" relates to whether an alert notification can be delivered to a user in time, not to triggering analysis of content by a computing system in response to determining that a playback delay exceeds a threshold, as recited in claim 51, as amended.
The applicant’s arguments do not appear to appreciate the significant teaching value of the prior art. Whereas the applicant’s argument states that “Cox's "threshold" relates to whether an alert notification can be delivered to a user in time, not to triggering analysis of content by a computing system in response to determining that a playback delay exceeds a threshold, as recited in claim 51…,” the “playback delay exceeds a threshold” appears to be synonymous with the point at which a viewer is watching the delayed playback of the live content. Again, for the sake of argument, if the viewer is watching a live program in a delayed manner (i.e., a time-shifted viewing of a live program of a certain amount of time) for example with a one minute time-shifted delay, then the combination of prior art renders obvious that the prior art inventions would have no problem processing the alert and providing the viewer with the alert in time for the viewer to switch to the portion referenced in the alert. On the contrary, assuming the viewer’s delayed time-shifted portion is only a few seconds behind the liver portion, for example 5 seconds, yet the computing system needs at least 15 seconds to process any alert, then the computing system would not be capable of triggering the processing of the alert and providing the viewer with the alert with sufficient time before the viewer gets to the portion in the live program that is referenced by the alert. A person of ordinary skill in the art would reasonably infer that live content would first need to be tagged after the alerted event happens which also adds to the processing time in addition to the time that the receiving device takes in processing any alert.
The applicant’s argument that “Cox’s delay threshold merely determines whether an alert can be successfully delivered and not whether analysis should be performed” goes against the common sense that a person of ordinary skill would utilize based on the teachings of the prior art and would appreciate that it is unnecessary to process alerts that could not be delivered to the viewer within sufficient time before the live broadcast has already been presented to the viewer. In order to find applicant’s arguments persuasive, then a person of ordinary skill would have not been able to see the problem with presenting the viewer with alerts after the viewer has already been presented with the portion of the live content that is referenced by the alert. To explain the examiner’s position different, assuming a viewer is watching a televised baseball game with a five second time-shifted viewing that includes a homerun play, then based on the applicant’s argument, the alert would be processed and presented to the viewer after the homerun has already occurred. Based on the examiner’s position, the homerun alert would not be processed (triggered) because there is not sufficient time to process the alert and present the alert to the viewer before the viewer catches up to the point at which the homerun occurred.
All things considered, the applicant’s arguments are not persuasive because the prior art renders obvious that at least a minimum amount of time is required to trigger the analyzing of received alert data in order to be able to provide the alert to a viewer before the viewer has already reached the point in the live broadcast, otherwise, it goes against common sense and would be pointless to deliver an alert to a viewer after the viewer has already reached and viewed the portion of the live broadcast related to the tagged alert data.
Again, the examiner incorporates the findings of fact made in the rejection of the claims. The rejection relies on the prior art of record to Cox for its significant teaching value relating to detecting a delay between the delayed portion of the live content stream and a live portion of the live content stream (para 64 indicator shown as "LIVE" and a corresponding time (i.e., -2:34 minutes) indicate the delay from the current playback point to real-time reception of the transmitted live stream.). More importantly, Cox teaches (para 0041 - When the playback device 14 receives this Event Metadata, it can assume (e.g., in accordance with a default setting or previously established convention, rule or policy implemented at the playback device 14) that the play action that leads to the Key Event corresponding to the Event Metadata occurs at some fixed time (e.g., 2 minutes) before the live broadcast point of the referenced channel. If the user elects to switch to an Alert Support Channel in response to an alert, the playback device 14 can then determine the playback point from which to start play from the buffered Alert Support Channel in the Content Buffer 112 as 2 minutes preceding the content that is being broadcast or otherwise transmitted when the Event Metadata that corresponds to the displayed alert is received. More importantly, Cox teaches para 59 - Event Metadata 116 can be transmitted on a one-way channel once or periodically or simply automatically resent once, provided sufficient delay exists between the last occurrence of the metadata and the content to be played back. In the case of a 2-way link for receiving metadata, the playback device 14 can periodically request or poll for Event Metadata from a metadata source.). Cox further teaches that the invention may require a certain amount of time in order to generate an alert to the viewer (e.g., para [0093] For example, if it takes (i) a maximum 30 seconds from the time an operator 104 hits the "tag" button to the time when all the metadata has been entered and the Event Metadata 116 is in the transmission; and (ii) at most 1 minute or 60 seconds of play action is to be aired as a prelude to an actual Key Event; and (iii) 5 seconds are needed to display an alert and give the user time to tune to the Alert Supported Channel, then the Content Buffer 112 must hold at least 95 seconds of content for each concurrently buffered Alert Supported Channel.). Therefore, a person of ordinary skill would have reasonably inferred that if the viewer’s position in the viewed content is delayed from the current playback point to real-time reception of the transmitted stream is LESS than the amount of time required to generate an alert to the viewer, then the invention will not generate an alert.
See also the teachings of Cox and further considering [0048] In accordance with illustrative embodiments of the present invention, multiple techniques can be used for establishing the Event Metadata 116 associated with a Key Event in a program or other delivered content, depending on metadata encoding/transmission objectives, the alert capabilities of the receivers/playback devices 14, and the acceptable levels of burden placed on an operator 104 entering the metadata. In an illustrative embodiment of the present invention, an operator or agent 104 who hears a Key Event during the game can press a button on a console or other device, thereby tagging the event. No other information need be entered by the operator. Event Metadata 116 generated using such a tag can, for example, be combined with the audio transmissions (or other content transmission, depending on the type of content and mode of delivery in use), with an assumed fixed timing relationship between the reception of the Event Metadata and the corresponding Alert Supported Channel broadcast when detected by the radio receiver, factoring in relative broadcast center processing, encoding, and uplink delays. The playback device 14 can alert the user of the impending Key Event, factoring in the known timing relationship, plus a fixed time before the event will occur that allows the user to hear the action building to the play (e.g., 15 seconds). Thus, the alert is generated by the playback device 14 some amount of time (e.g. 15 seconds) before the point in the delayed Alert Supported Channel that corresponds to when the operator 104 pressed the "tag" button (e.g., or a monitoring system designated the event as a Key Event). See also Cox [0049] In an alternate implementation, the operator 104 can supplement the "tag" entry with further information characterizing the Key Event, including but not limited to any of the following: [0050] Associated Channel Identifier, identifying the audio channel on which the Key Event occurs. [0051] Type of Key Event: for sports programs, key events can include, but are not limited to, score, stolen base, goal attempt, outstanding play, kickoff, field goal, interception, fumble, hit, penalty, and so on. For other types of programs, a key event can be a breaking news story, or an expected piece of a breaking news story such as a change in category level for a tropical storm or hurricane being covered by a weather channel, or a verdict or interview with prosecution or defense team members in a trial being covered by news media, for example. [0052] Time Duration before the "tag" event during which play action will be of interest to the user, e.g. 15 seconds, 1 minute, etc. Alternatively, this value can, for example, be automatically assigned, or assigned a default value that is based on the Type of Key Event or Type of Channel or genre of content (e.g., news, weather, and so on) or other factors such as the type of sport being played and that can be overridden. [0053] Time Duration after the "tag" event during which play action or commentary will be of interest to the user, e.g. 15 seconds, 1 minute, etc. Alternatively this value can, for example, be automatically assigned, or assigned a default value that is based on the Type of Key Event or other factors such as the type of sport being played and that can be overridden. [0054] Priority of Key Event, e.g., high (e.g., scoring events), medium (e.g., turnovers, penalties, etc.), and low (at bats, stolen base, failed goal kick, etc.) as classified by the broadcaster or content provider 20 (e.g., according to defined criteria). Alternatively, this value may be automatically assigned, or assigned a default value that is based on the Type of Key Event and that can be overridden.
Stated differently, based paragraphs 41 and 93 of Cox, Cox teaches that transmitting notifications to a user device requires a minimum amount of time (threshold) for tagging and transmission plus an additional amount of time for “prelude” plus an amount of time to display an alert (see paragraph 93). Additionally, a user may set a threshold time for receiving alerts (e.g., some fixed time before the live broadcast point). Based on the combination of prior art elements, any excitement event metadata that is provided because there was sufficient lead time for analyzing and processing would be made available immediately based in part on the teaching of Dimov col.9:7-36 teaching live content is recorded and may be placeshifted which is interpreted as comprising delayed presentation wherein available excitement data is available immediately.
Therefore, if a viewer is watching a delayed portion of live content by less than a minute, then based on the teachings of Cox, the delayed portion is less than a threshold of time that is required to 1) process the alerts of Cox in paragraph 93 and not within a threshold of time as set by the viewer in paragraph 41 of Cox. Therefore, a person of ordinary skill in the art would have understood that there is no need to trigger of the analyzing of the live event stream for alerts because they are not within the identified threshold (i.e., there is not sufficient lead time to allow the event metadata to be analyzed to generate alerts with sufficient lead time to allow the user to turn to the corresponding event wherein the DVR as taught in the prior art is only recording one program in Dimov col.9:7-36).
All things considered, the prior art teaches several windows of time required to properly process and timely deliver the event and related excitement level to the viewer device, including the amount of time between the current position to the live point in the live media content (see para 64 indicator shown as "LIVE" and a corresponding time (i.e., -2:34 minutes) indicate the delay from the current playback point to real-time reception of the transmitted live stream) and Packard teaching that an event excitement level has to be above a certain value for a specific amount of time, then the amount of the delay of Cox which identifies the amount of time to live, must greater than the threshold of time required to identify the event requirement of Packard.
See also prior art made of record and not relied upon to avoid duplicative references Gupta; Vikram Makam et al. US 9615124 B1 (hereafter Gupta) teaches providing a viewer with important portions in a video stream will be displayed in the near future based on a window of time (i.e., threshold) (col. 30:25-67 to col. 31:1-67 to col. 32:1-33 teaching comparing threshold to the weighting/ranking to determine important of event for the viewer). See also col. 32:50-67 to col. 33:1-51 look ahead a variable amount of time in the media based and/or compute a threshold amount of time to look ahead. Gupta recognizes that the benefit of utilizing a threshold of time, in part, is because a user may have a greater propensity to wait longer for an important scene based on the content and limiting the analyzing of the video content within the time window (i.e., threshold time). If the threshold of time is within the window, the Gupta’s invention will analyze the window of time to determine whether detected content is responsive to the viewer’s preferences and to determine whether based on the weight of the detected content, the viewer would be presented with the detected content (Gupta 30:25-67 to col. 31:1-67 to col. 32:1-33; See also col. 32:50-67 to col. 33:1-51; see also col. 26:23-67 to 29:1-67). More importantly, Gupta col. 33:5-51 teaches: In another example, control circuitry 304 may utilize a broadcast delay to determine whether important content corresponds to an upcoming segment. For example, control circuitry 304 may determine that a live media asset has a broadcast delay of seven seconds. Control circuitry 304 may utilize the broadcast delay to retrieve metadata corresponding to content seven seconds ahead of a current position in the media asset; or may retrieve frames corresponding to the broadcast delay and may perform an image processing algorithm on the frames to determine whether they contain important content, as described above. Therefore, the applicant’s arguments have been fully considered but are not persuasive and the rejections are maintained.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 51, 53, 57, 59-60, 62, 66, 68-73 rejected under 35 U.S.C. 103 as being unpatentable over Dimov; Dmitry et al. US 9788062 B2 (hereafter Dimov) and in further view of Logan, James D. et al. US 20030093790 A1 (hereafter Logan) and in further view of Maisenbacher; Mark Kikuya et al. US 10297287 B2 (hereafter Maisenbacher) and in further view of Packard; Warren Joseph et al. US 20180108380 A1 (hereafter Packard) and in further view of Cox; Stuart Anderson US 20140157307 A1 (hereafter Cox).
Regarding claim 51, “a method comprising: generating for display a delayed portion of a live content stream; detecting a delay between the delayed portion of the live content stream and a live position of the live content stream determining whether the delay is greater than a threshold time; in response to the determining that the delay is greater than the threshold time: triggering analyzing, by a computing system, of content between the delayed portion of the live content stream and the live position of the live content stream to detect at least one event; wherein the analyzing by the computing system is triggered by the computing system determining that the delay is greater than the threshold time; and generating for display a navigation menu comprising an option to play one of the detected at least one event and in response to the determining that the delay is not greater than the threshold time: preventing triggering analyzing of the content stream” Dimov teaches (col. 3:19-22 excitement data can be used to identify the most exciting programming in real time as the programs are being broadcast; col. 11:45-55 - as excitement data is received with respect to one or more programs (function 202), the server(s) 106 can generate a message, a notification, an alert, and the like indicating that particular digital video content associated with one or more programs of interest (or potential interest) to the viewer have become exciting. This message can be communicated to the viewer's media client 110 by the server(s) 106 via the network 108; col. 12:4-31 – DVR can perform an automated process that uses excitement data to improve the viewer experience. As such, Dimov teaches DVR presenting placeshifted content while providing excitement data in real-time to allow the viewer the ability to automatically switch to the content identified by excitement data determined from user preferences). Dimov col. 5:14-31, 54-58 based on excitement data indicating that the program selected by the viewer has become exciting, the viewer is presented with the exciting portion of the program; Dimov col. 9:25-36 – placeshifting device allows a viewer to immediately and automatically jump to the most exciting portions of the recorded content. Wherein Dimov does not use the term “delayed” when referencing a portion of the live content stream, as discussed above, Dimov does disclose a DVR for presenting placeshifted content while providing excitement data in real-time to allow the viewer the ability to automatically switch to the content identified by excitement data determined from user preferences as discussed above. Additionally, col. 6:13-18, teaches that data could be updated in real time so as the program becomes more interesting (e.g., scoring opportunities, player of interest involved in game, action sequence, musical number, etc.), the viewer is made aware of the current level of excitement shown in the live broadcast. All things considered, based in part on Dimov’s teachings, a person of ordinary skill in the art would have understood that a time shift buffer identifies a delay between the delayed portion of the live content stream and a live portion of the live content stream when viewed in light of the teachings.
Dimov does not reference the delay threshold as recited in the limitation “detecting a delay between the delayed portion of the live content stream and a live position of the live content stream determining whether the delay is greater than a threshold time; in response to the determining that the delay is greater than the threshold time: triggering analyzing, by a computing system, of content between the delayed portion of the live content stream and the live position of the live content stream to detect at least one event; wherein the analyzing by the computing system is triggered by the computing system determining that the delay is greater than the threshold time; and generating for display a navigation menu comprising an option to play one of the detected at least one event and in response to the determining that the delay is not greater than the threshold time: preventing triggering analyzing of the content stream” but Dimov discloses a DVR for presenting placeshifted content while providing excitement data in real-time to allow the viewer the ability to automatically switch to the content identified by excitement data determined from user preferences wherein col. 5:63-67 to col. 6:1-41 teaches excitement data is updated in real time for each event throughout the broadcasts so that the viewer is able to readily identify exciting levels of the program showing in the live broadcast; col. 12:24-56 a media client 110 can display a program timeline from beginning to end (i.e., first and second events to be displayed enabling a viewer to present the events in any order) (e.g., as a bar representing a time shift buffer or the like), and highlight exciting portions of the program. For example, as shown, a program may comprise a first exciting portion 304 at time span 1 (tl), a second exciting portion 306 at time span 2 (t2), and third exciting portion 308 at time span three (t3), and the like. Thus, in general terms, a program can be displayed along a timeline and one or more visual cues or indicators may be displayed to alert a viewer to exciting portions of the program. These indicators may be displayed in any style that is suitable.
Whereas Dimov teaches that the viewer is given the ability to switch to the content identified by excitement data and a person of ordinary skill in the art would have reasonably inferred that the viewer would be presented with either event first (e.g., later event in time before the earlier event in time), Dimov does not elaborate on how the later event in time is presented before the earlier event in time other than the viewer being able to present the events in any order by selecting the events.
In an analogous art, Logan teaches the term “delay” not referenced in Dimov and clarifies how the term would be understood to be covered in the teachings of Dimov wherein Logan teaches concurrently recording live broadcasting while replaying a delayed version of the previously recorded programming (para 18) and identifying live broadcast program metadata during the live broadcast which identify indicated preferences so that preferred program segments are identified and processed in order to enable a viewer to receive a playlist of default playback sequence of segments which can be reorganized and/or varied in accordance with preferences associated with each user (para 123, 209, and 267). Logan teaches the preferred system would let users indicate preferences for certain segment types. For instance, a sports fan might indicate a preference for jump balls (recognized by a whistle and characteristic picture composition), or applause lines on the Letterman show. This preference information is more form-based than content-based, the usual parameter used for personalizing. See id. Logan does not reference the delay threshold as recited in the limitation.
In an analogous art, Packard also teaches an invention for automatically generating excitement levels wherein a more current event will have a higher excitement level than an event that occurred earlier in time which is closer to the start of the media content (para 57-60) and Packard para 58-59 further teaches a second time-interval is measured from a point in time after the start of the event to a current point in time during the event and wherein the disclosed time-interval is one or a few seconds. Packard para 52, 53 also teaches that an excitement level of an event has to be above a certain value for a specific amount of time. [Note: see prior art made of record but not relied upon in order to avoid duplicative references Packard; Warren Joseph et al. US 20140067939 A1 disclosing amount of time required to trigger an event alert in para 94-109]. A person of ordinary skill in the art would have understood that a current play position in relation to a live point in a live broadcast is factored into whether an event alert can be timely delivered to a viewer. For example, wherein the applicant’s claims are directed to detecting a delay between the delayed portion of the live content stream and a live portion of the live content stream, it is important to note that as taught by the prior art, any amount of delay can be determined (e.g., 5 seconds to the length of the entire program). For example, see Dimov cited above teaching indicating time span of exciting portions (col. 5:63-67 to col. 6:1-41 – excitement data updated in real time throughout the broadcasts so that the viewer is able to readily identify exciting levels of the program showing in the live broadcast; col. 12:24-56 a media client 110 can display a program timeline from beginning to end (e.g., as a bar representing a time shift buffer or the like), and highlight exciting portions of the program. For example, as shown, a program may comprise a first exciting portion 304 at time span 1 (tl), a second exciting portion 306 at time span 2 (t2), and third exciting portion 308 at time span three (t3), and the like. Thus, in general terms, a program can be displayed along a timeline and one or more visual cues or indicators may be displayed to alert a viewer to exciting portions of the program. These indicators may be displayed in any style that is suitable.)
The motivation to modify Dimov, Logan, Maisenbacher, and Packard is further evidenced in an analogous art, Cox also teaches detecting a delay between the delayed portion of the live content stream and a live portion of the live content stream (para 64 indicator shown as "LIVE" and a corresponding time (i.e., -2:34 minutes) indicate the delay from the current playback point to real-time reception of the transmitted live stream.). More importantly, Cox teaches (para 0041 - When the playback device 14 receives this Event Metadata, it can assume (e.g., in accordance with a default setting or previously established convention, rule or policy implemented at the playback device 14) that the play action that leads to the Key Event corresponding to the Event Metadata occurs at some fixed time (e.g., 2 minutes) before the live broadcast point of the referenced channel. If the user elects to switch to an Alert Support Channel in response to an alert, the playback device 14 can then determine the playback point from which to start play from the buffered Alert Support Channel in the Content Buffer 112 as 2 minutes preceding the content that is being broadcast or otherwise transmitted when the Event Metadata that corresponds to the displayed alert is received. More importantly, Cox teaches para 59 - Event Metadata 116 can be transmitted on a one-way channel once or periodically or simply automatically resent once, provided sufficient delay exists between the last occurrence of the metadata and the content to be played back. In the case of a 2-way link for receiving metadata, the playback device 14 can periodically request or poll for Event Metadata from a metadata source.). Cox further teaches that the invention may require a certain amount of time in order to generate an alert to the viewer (e.g., para [0093] For example, if it takes (i) a maximum 30 seconds from the time an operator 104 hits the "tag" button to the time when all the metadata has been entered and the Event Metadata 116 is in the transmission; and (ii) at most 1 minute or 60 seconds of play action is to be aired as a prelude to an actual Key Event; and (iii) 5 seconds are needed to display an alert and give the user time to tune to the Alert Supported Channel, then the Content Buffer 112 must hold at least 95 seconds of content for each concurrently buffered Alert Supported Channel.). Therefore, a person of ordinary skill would have reasonably inferred that if the viewer is delayed from the current playback point to real-time reception of the transmitted stream is LESS than the amount of time required to generate an alert to the viewer, then the invention will not generate an alert.
See also the teachings of Cox and further considering [0048] In accordance with illustrative embodiments of the present invention, multiple techniques can be used for establishing the Event Metadata 116 associated with a Key Event in a program or other delivered content, depending on metadata encoding/transmission objectives, the alert capabilities of the receivers/playback devices 14, and the acceptable levels of burden placed on an operator 104 entering the metadata. In an illustrative embodiment of the present invention, an operator or agent 104 who hears a Key Event during the game can press a button on a console or other device, thereby tagging the event. No other information need be entered by the operator. Event Metadata 116 generated using such a tag can, for example, be combined with the audio transmissions (or other content transmission, depending on the type of content and mode of delivery in use), with an assumed fixed timing relationship between the reception of the Event Metadata and the corresponding Alert Supported Channel broadcast when detected by the radio receiver, factoring in relative broadcast center processing, encoding, and uplink delays. The playback device 14 can alert the user of the impending Key Event, factoring in the known timing relationship, plus a fixed time before the event will occur that allows the user to hear the action building to the play (e.g., 15 seconds). Thus, the alert is generated by the playback device 14 some amount of time (e.g. 15 seconds) before the point in the delayed Alert Supported Channel that corresponds to when the operator 104 pressed the "tag" button (e.g., or a monitoring system designated the event as a Key Event). See also Cox [0049] In an alternate implementation, the operator 104 can supplement the "tag" entry with further information characterizing the Key Event, including but not limited to any of the following: [0050] Associated Channel Identifier, identifying the audio channel on which the Key Event occurs. [0051] Type of Key Event: for sports programs, key events can include, but are not limited to, score, stolen base, goal attempt, outstanding play, kickoff, field goal, interception, fumble, hit, penalty, and so on. For other types of programs, a key event can be a breaking news story, or an expected piece of a breaking news story such as a change in category level for a tropical storm or hurricane being covered by a weather channel, or a verdict or interview with prosecution or defense team members in a trial being covered by news media, for example. [0052] Time Duration before the "tag" event during which play action will be of interest to the user, e.g. 15 seconds, 1 minute, etc. Alternatively, this value can, for example, be automatically assigned, or assigned a default value that is based on the Type of Key Event or Type of Channel or genre of content (e.g., news, weather, and so on) or other factors such as the type of sport being played and that can be overridden. [0053] Time Duration after the "tag" event during which play action or commentary will be of interest to the user, e.g. 15 seconds, 1 minute, etc. Alternatively this value can, for example, be automatically assigned, or assigned a default value that is based on the Type of Key Event or other factors such as the type of sport being played and that can be overridden. [0054] Priority of Key Event, e.g., high (e.g., scoring events), medium (e.g., turnovers, penalties, etc.), and low (at bats, stolen base, failed goal kick, etc.) as classified by the broadcaster or content provider 20 (e.g., according to defined criteria). Alternatively, this value may be automatically assigned, or assigned a default value that is based on the Type of Key Event and that can be overridden.
Stated differently, based paragraphs 41 and 93 of Cox, Cox teaches that transmitting notifications to a user device requires a minimum amount of time (threshold) for tagging and transmission plus an additional amount of time for “prelude” plus an amount of time to display an alert (see paragraph 93). Additionally, a user may set a threshold time for receiving alerts (e.g., some fixed time before the live broadcast point). Based on the combination of prior art elements, any excitement event metadata that is provided because there was sufficient lead time for analyzing and processing would be made available immediately based in part on the teaching of Dimov col.9:7-36 teaching live content is recorded and may be placeshifted which is interpreted as comprising delayed presentation wherein available excitement data is available immediately.
Therefore, if a viewer is watching a delayed portion of live content by less than a minute, then based on the teachings of Cox, the delayed portion is less than a threshold of time that is required to 1) process the alerts of Cox in paragraph 93 and not within a threshold of time as set by the viewer in paragraph 41 of Cox. Therefore, a person of ordinary skill in the art would have understood that there is no need to trigger of the analyzing of the live event stream for alerts because they are not within the identified threshold (i.e., there is not sufficient lead time to allow the event metadata to be analyzed to generate alerts with sufficient lead time to allow the user to turn to the corresponding event wherein the DVR as taught in the prior art is only recording one program in Dimov col.9:7-36).
All things considered, the prior art teaches several windows of time required to properly process and timely deliver the event and related excitement level to the viewer device, including the amount of time between the current position to the live point in the live media content (see para 64 indicator shown as "LIVE" and a corresponding time (i.e., -2:34 minutes) indicate the delay from the current playback point to real-time reception of the transmitted live stream) and Packard teaching that an event excitement level has to be above a certain value for a specific amount of time, then the amount of the delay of Cox which identifies the amount of time to live, must greater than the threshold of time required to identify the event requirement of Packard.
See also prior art made of record and not relied upon to avoid duplicative references Gupta; Vikram Makam et al. US 9615124 B1 (hereafter Gupta) teaches providing a viewer with important portions in a video stream will be displayed in the near future based on a window of time (i.e., threshold) (col. 30:25-67 to col. 31:1-67 to col. 32:1-33 teaching comparing threshold to the weighting/ranking to determine important of event for the viewer). See also col. 32:50-67 to col. 33:1-51 look ahead a variable amount of time in the media based and/or compute a threshold amount of time to look ahead. Gupta recognizes that the benefit of utilizing a threshold of time, in part, is because a user may have a greater propensity to wait longer for an important scene based on the content and limiting the analyzing of the video content within the time window (i.e., threshold time). If the threshold of time is within the window, the Gupta’s invention will analyze the window of time to determine whether detected content is responsive to the viewer’s preferences and to determine whether based on the weight of the detected content, the viewer would be presented with the detected content (Gupta 30:25-67 to col. 31:1-67 to col. 32:1-33; See also col. 32:50-67 to col. 33:1-51; see also col. 26:23-67 to 29:1-67). More importantly, Gupta col. 33:5-51 teaches: In another example, control circuitry 304 may utilize a broadcast delay to determine whether important content corresponds to an upcoming segment. For example, control circuitry 304 may determine that a live media asset has a broadcast delay of seven seconds. Control circuitry 304 may utilize the broadcast delay to retrieve metadata corresponding to content seven seconds ahead of a current position in the media asset; or may retrieve frames corresponding to the broadcast delay and may perform an image processing algorithm on the frames to determine whether they contain important content, as described above.
A person of ordinary skill in the art would have reasonably inferred from the teachings of the prior art and that common sense would appreciate that it is unnecessary to process alerts that could not be delivered to the viewer within sufficient time before the live broadcast has already been presented to the viewer. To find otherwise, then a person of ordinary skill would have not been able to readily see the problem with presenting the viewer with alerts after the viewer has already been presented with the portion of the live content that is referenced by the alert. To explain the examiner’s position different, assuming a viewer is watching a televised baseball game with a five second time-shifted viewing that includes a homerun play, the short delay would trigger the analyzing/processing of said homerun alert and presented to the viewer after the homerun has already occurred. Based on the examiner’s position, the homerun alert would not be processed (triggered) because there is not sufficient time to process the alert and present the alert to the viewer before the viewer catches up to the point at which the homerun occurred.
All things considered, the prior art renders obvious that at least a minimum amount of time is required to trigger the analyzing of received alert data in order to be able to provide the alert to a viewer before the viewer has already reached the point in the live broadcast, otherwise, it goes against common sense and would be pointless to deliver an alert to a viewer after the viewer has already reached and viewed the portion of the live broadcast related to the tagged alert data.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Dimov’s DVR for presenting time-shifted content while providing excitement data in real-time, on a time-shift buffer timeline, to provide the viewer with visual options to switch to the content identified by excitement data determined from user preferences by further incorporating known elements of Logan for concurrently recording live broadcasting while replaying a delayed version of the previously recorded programming and identifying live broadcast program metadata during the live broadcast which identify indicated preferences so that preferred program segments are identified and processed in order to enable a viewer to receive a playlist of default playback sequence of segments which can be reorganized and/or varied in accordance with preferences associated with each user. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Dimov and Logan by further incorporating known elements of Maisenbacher teaching an invention for identifying segments within media content item which identifies and specifies an excitement level wherein more exciting clips are listed ahead of less exciting clips because the prior art to Packard recognizes a solution to classifying the excitement level of events in media content wherein a more current event will have a higher excitement level than an event that occurred earlier in time which is closer to the start of the media content and the modification would facilitate the determination of which event to display first based on event identifying data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Dimov, Logan, Maisenbacher, and Packard by further incorporating known elements of Cox’s user device generating alerts to the user based on the metadata in sufficient lead time (threshold) to enable the user to not receive media content on which an event of interest is occurring, but to do so sufficiently in advance of an event of interest so as to hear and/or see relevant portions of the content leading up to and/or following such an event in relation to the (time shift buffer indicating the delay from the current playback point to real-time reception of the transmitted live stream) because the combination of known elements and rearranging the components according to their known features is predictable as Dimov recognizes a known problem in the art of accounting for delays inherent in processing, transmission and the like of excitement level data and Cox also recognizes accounting for a certain amount of time required in order to generate an alert to the viewer based and taking delayed viewing time into consideration.
Regarding claim 53, “wherein both: the triggering analyzing of content between the delayed portion of the live content stream and the live position of the live content stream, and (b) the generating for display a navigation menu comprising an option to play one of the detected at least one event instead of the delayed portion of the live content stream in response to both: (a) determining that the delay is greater than the threshold time, and (b) determining that an amount of time that has elapsed since a most recent analysis of the content stream is greater than a threshold content analysis repetition period” is further rejected on obviousness grounds as discussed in the rejection of claim 51 wherein the combination of Dimov, Logan, Maisenbacher, Packard, and Cox render obvious the presentation of events is based on their level of excitement that is determined when an event is detected and wherein the excitement level of two events is calculated to present the more exciting event first. For example, Packard para 52 teaches “[0052] In step 408, it is determined whether one or more of the excitement levels generated in step 402 are at or above one or more excitement thresholds. In accordance with the disclosed technology, in order to notify subscribers when an event begins to get sufficiently exciting, it is determined if an excitement level is at or above a certain value for a specific amount of time. This value is referred to herein as an excitement threshold. If, in step 408, it is determined that none of the excitement levels generated in step 402 are at or above one or more excitement thresholds and the event has not ended, then the process continues to monitor the event in real-time in step 400 if the live event is not over (step 414)” which corresponds to an amount of time that the detection of the event is detected before a determination is made that no excitement level is generated. See also the teachings of Cox discussed in the rejection of claim 51 and further considering [0049] In an alternate implementation, the operator 104 can supplement the "tag" entry with further information characterizing the Key Event, including but not limited to any of the following: [0050] Associated Channel Identifier, identifying the audio channel on which the Key Event occurs. [0051] Type of Key Event: for sports programs, key events can include, but are not limited to, score, stolen base, goal attempt, outstanding play, kickoff, field goal, interception, fumble, hit, penalty, and so on. For other types of programs, a key event can be a breaking news story, or an expected piece of a breaking news story such as a change in category level for a tropical storm or hurricane being covered by a weather channel, or a verdict or interview with prosecution or defense team members in a trial being covered by news media, for example. [0052] Time Duration before the "tag" event during which play action will be of interest to the user, e.g. 15 seconds, 1 minute, etc. Alternatively, this value can, for example, be automatically assigned, or assigned a default value that is based on the Type of Key Event or Type of Channel or genre of content (e.g., news, weather, and so on) or other factors such as the type of sport being played and that can be overridden. [0053] Time Duration after the "tag" event during which play action or commentary will be of interest to the user, e.g. 15 seconds, 1 minute, etc. Alternatively this value can, for example, be automatically assigned, or assigned a default value that is based on the Type of Key Event or other factors such as the type of sport being played and that can be overridden. [0054] Priority of Key Event, e.g., high (e.g., scoring events), medium (e.g., turnovers, penalties, etc.), and low (at bats, stolen base, failed goal kick, etc.) as classified by the broadcaster or content provider 20 (e.g., according to defined criteria). Alternatively, this value may be automatically assigned, or assigned a default value that is based on the Type of Key Event and that can be overridden.
Regarding claim 57, “comprising: generating event identifiers, ranks, and time segment information for each of the detected at least one event; and storing the event identifiers, ranks, and time segment information for each of the detected at least one event in memory for subsequent analysis of the detected at least one event” is further rejected on obviousness grounds as discussed in the rejection of claims 51, 53 wherein the combination of Dimov col. 5:14-62; col. 7:41-51; col. 12:32-67, col. 13:1-12 teaches storing exciting data information comprising timing, rating, and identifiers in conjunction with a program recorded in a DVR would allow a subsequent viewer to automatically "jump" to the most exciting portions of the recorded content and wherein excitement level is interpreted as a rank. See also Maisenbacher teaches an invention for identifying segments withing media content item which identifies and specifies an excitement level wherein more exciting clips are listed ahead of less exciting clips (col. 6:23-67 to col. 7:1-43); Packard also teaches an invention for automatically generating excitement levels wherein a more current event will have a higher excitement level than an event that occurred earlier in time which is closer to the start of the media content (para 57-60); See also Cox [0026] Continuing with reference to FIG. 1, a broadcaster or content provider 20 can receive a live audio feed 102 from the sports event. An operator 104 can, for example, monitor live audio feed 102, and when operator 104 hears an event that he or she considers a "Key Event" (using defined criteria for example), he can, for example, tag it as such by pressing a button or key on a console, for example. He can, for example, optionally also enter or select additional information that further characterizes the Key Event, such as, for example, (i) the type of play (e.g., hit, score, fumble, goal, etc.), (ii) how long before the play was tagged that related play action started (e.g., 15 seconds, 1 minute, etc.), and (iii) how long after the play was tagged that the broadcast content continued to cover the play with subsequent play action and/or announcer commentary. The information created by operator 104 is sometimes referred to herein as "Monitored Event Data", and in FIG. 1 it is shown as "game data." Some or all of the Monitored Event Data can be captured and encoded as Event Metadata 116 in, for example, binary or text form. Alternatively, for example, an agent other than broadcast operator 104, or, for example, an automated monitoring method, can be used to monitor either a live event 100 or prerecorded content, and automatically identify Key Events therein and generate Event Metadata 116 and/or generic play or event data. In addition, the agent can generate general event data and statistics without necessarily intending such data to be used only for determining Key Events. Subsequently, a subsystem (e.g., tag encoder 108) that receives such general event data can analyze it and the statistics to determine which data implies that a Key Event has occurred (e.g., using defined criteria).
See also prior art made of record but not relied upon: Packard ‘733 disclosing an invention for identifying events occurring in a media content including the excitement level and displaying the events in highlights that are displayed in either chronological order or a different order (para 142-143 user may navigate to individual events or to see the entire sequence via a “play all” function) and further teaches a user will be watching media content that is currently in progress (i.e., live) and instead of watching the event live, the user may wish to start watching the event in a delayed mode wherein the earlier portion of the event is displayed and then catch up to the live event (para 263-264 disclosing provides an option for real-time catch-up viewing, wherein a highlight sequence is presented for a first part of an event, transitioning to a full (unexpurgated) version from a certain point until the end of the event).
Note: See prior art made of record but not relied upon - More importantly, Gupta; Vikram Makam et al. US 9615124 B1 (hereafter Gupta) col. 33:41-51 teaches the frames are analyzed to determine whether they contain important content and wherein detected content is weighted (ranked) to determine presentation to the viewer: “In another example, control circuitry 304 may utilize a broadcast delay to determine whether important content corresponds to an upcoming segment. For example, control circuitry 304 may determine that a live media asset has a broadcast delay of seven seconds. Control circuitry 304 may utilize the broadcast delay to retrieve metadata corresponding to content seven seconds ahead of a current position in the media asset; or may retrieve frames corresponding to the broadcast delay and may perform an image processing algorithm on the frames to determine whether they contain important content, as described above.”
Regarding claim 59, “further comprising: detecting that an amount of time associated with a predetermined repetition period has elapsed since a most recent analysis of the content stream; and in response to detecting that the amount of time associated with the predetermined repetition period has elapsed, triggering the analyzing of content between the delayed portion of the live content stream and the live position of the live content stream to detect at least one event” is further rejected on obviousness grounds as discussed in the rejection of claims 51, 53, 57, wherein Packard para 52 teaches “[0052] In step 408, it is determined whether one or more of the excitement levels generated in step 402 are at or above one or more excitement thresholds. In accordance with the disclosed technology, in order to notify subscribers when an event begins to get sufficiently exciting, it is determined if an excitement level is at or above a certain value for a specific amount of time. This value is referred to herein as an excitement threshold. If, in step 408, it is determined that none of the excitement levels generated in step 402 are at or above one or more excitement thresholds and the event has not ended, then the process continues to monitor the event in real-time in step 400 if the live event is not over (step 414)” which corresponds to an amount of time that the detection of the event is detected before a determination is made that no excitement level is generated. See also the teachings of Cox discussed in the rejection of claim 51 and further considering [0049] In an alternate implementation, the operator 104 can supplement the "tag" entry with further information characterizing the Key Event, including but not limited to any of the following: [0050] Associated Channel Identifier, identifying the audio channel on which the Key Event occurs. [0051] Type of Key Event: for sports programs, key events can include, but are not limited to, score, stolen base, goal attempt, outstanding play, kickoff, field goal, interception, fumble, hit, penalty, and so on. For other types of programs, a key event can be a breaking news story, or an expected piece of a breaking news story such as a change in category level for a tropical storm or hurricane being covered by a weather channel, or a verdict or interview with prosecution or defense team members in a trial being covered by news media, for example. [0052] Time Duration before the "tag" event during which play action will be of interest to the user, e.g. 15 seconds, 1 minute, etc. Alternatively, this value can, for example, be automatically assigned, or assigned a default value that is based on the Type of Key Event or Type of Channel or genre of content (e.g., news, weather, and so on) or other factors such as the type of sport being played and that can be overridden. [0053] Time Duration after the "tag" event during which play action or commentary will be of interest to the user, e.g. 15 seconds, 1 minute, etc. Alternatively this value can, for example, be automatically assigned, or assigned a default value that is based on the Type of Key Event or other factors such as the type of sport being played and that can be overridden. [0054] Priority of Key Event, e.g., high (e.g., scoring events), medium (e.g., turnovers, penalties, etc.), and low (at bats, stolen base, failed goal kick, etc.) as classified by the broadcaster or content provider 20 (e.g., according to defined criteria). Alternatively, this value may be automatically assigned, or assigned a default value that is based on the Type of Key Event and that can be overridden.
Regarding the system claims 60, 62, 66, 68, 72 and the non-transitory computer readable media claims 69-70, 73 the claims are grouped and rejected with the method claims 51, 53 and 57, 59 because the steps of the method claims are met by the disclosure of the apparatus and methods of the reference(s) as discussed in the rejection of claims 51, 53, 57, 59, and 71 and because the steps of the method are easily converted into elements of computer implemented systems and methods by one of ordinary skill in the art.
Regarding claim 71, “further comprising: determining an event type for each of the detected at least one event; retrieving stored event rules which identify event ranks for each of the detected at least one event types including the event type for each of the detected at least one event; and determining a rank of each of the detected at least one event based on the stored event rules and the event type for each of the detected at least one event” is further rejected on obvious grounds as discussed in the rejection of claims 51, 53, 57, and 59 wherein the combination of prior art to Dimov, Logan, Maisenbacher, Packard, and Cox require the identification of the type of event, based on viewer stored preferences, in order to identify whether it is of particular interest to the viewer in order to provide a visual indicator to inform the viewer that an event of particular interest, and how it ranks to other events, has occurred in a broadcast.
CONCLUSION
Prior art made of record but not relied upon - Chipman; Leslie Eugene et al. US 20140282745 A1
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALFONSO CASTRO whose telephone number is (571)270-3950. The examiner can normally be reached on Monday to Friday from 10am to 6pm.
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, Nathan Flynn can be reached. 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.
/ALFONSO CASTRO/Primary Examiner, Art Unit 2421