DETAILED ACTION
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 .
This action is in response to application 18/992,585 filed 1/9/2025.
Claims 1-13 and 16-22 are presented for examination.
Claim Rejections - 35 USC § 101 (nonstatutory subject matter)
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 22 is rejected under 35 US.C. § 101 because the claimed invention is directed to nonstatutory subject matter. The claim is drawn to a “computer-readable storage medium”. The Specification is clear that the storage medium may be transitory. Paragraph 00135 of the specification cites “The readable medium may be a readable signal medium”. Paragraph 00136 of the specification cites “A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier ·wave carrying readable program code therein.”
. Thus, applying the broadest reasonable interpretation in light of the Specification and taking into account the meaning of the words in their ordinary usage as they would be understood by one of ordinary skill in the art (MPEP §2111.01), the claims as a whole covers a transitory signal, as such, does not fall within the definition of a process, machine, manufacture, or composition of matter (MPEP §2106.01). The Applicants specification does not preclude reading by signals.
Therefore, claim 22 is directed towards non-statutory subject matter (See MPEP section 2106, Seventh Edition, Revision No. dated February 2000, at page 2100-10 and 2100-11).
Examiner’s comment: A claim drawn to such a computer readable medium that covers both transitory and non-transitory embodiments may be amended to narrow the claim to cover only statutory embodiments to avoid a rejection under 35 US.C. § 101 by adding the limitation “non-transitory” to the claim term (Kappos memo dated January 26, 2010 available at http://www.uspto.gov/patents/law/notices/101_crm_20100127.pdf).
Objections to the claims
Claim 13 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The combination of MACINNIS, Van Brandenburg, and Lewis do not teach the feature of “determining a source code service handle corresponding to the to-be-deleted transcoding service handle based on a transcoding stream identifier comprised in the to-be-deleted transcoding service handle, and deleting the to-be-deleted transcoding service handle from the source code service handle.” Thus, the prior art of record fails to teach or suggest determining a source code service handle corresponding to a to-be-deleted transcoding service handle based on a transcoding stream identifier and deleting the transcoding service handle from the source code service handle in response to heartbeat timeout detection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 12, 16-19 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over MACINNIS et al., Pub No US 2014/0344443 (hereafter MACINNIS) in view of Van Brandenburg et al., Pub No US 2018/0242028 (hereafter Van Brandenburg) and further in view of Lewis et al., Pub No US 2012/0047542 (hereafter Lewis).
Regarding Claim 1, MACINNIS discloses a video stream processing method, comprising:
receiving a video playback request sent by a first terminal [para.0016: Discloses “The network interface 170 may transmit segments of the transcoded video stream to the client device 190 via the network 180, e.g. in response to requests therefor.” Thus, MACINNIS teaches receiving playback requests from a client terminal requesting video content.], and acquiring a to-be-played stream identifier, a network bandwidth [para.0014: Discloses “the network monitor module 140 may periodically send Hyper-Text Transport Protocol (HTTP) status requests… and measure metrics such as response time, availability, uptime, throughput, and latency, and based on the measurement results, estimate a current available bandwidth.” Thus, MACINNIS teaches acquiring network bandwidth information associated with the client/network.];
pushing the target video stream to the first terminal [claim 1: Discloses “providing the segments of the first transcoded video stream to the client device via the network in response to requests therefor”; and para.0016: Discloses “The network interface 170 may transmit segments of the transcoded video stream to the client device 190 via the network 180, e.g. in response to requests therefor.” Thus, MACINNIS teaches transmitting/pushing the video stream to the terminal.].
MACINNIS does not explicitly disclose acquiring, in a preset co-source stream dictionary, a source code service handle matching the to-be-played stream identifier, acquiring a target video stream corresponding to the target service handle; However, in analogous art, Van Brandenburg discloses the following:
acquiring, in a preset co-source stream dictionary [para.0206: Discloses “Such manifest file is characterized in that it defines a plurality of tile streams for one tile position… allowing a user to select different tile streams for one tile position.” Thus, Van Brandenburg teaches a predefined manifest structure storing associations between selectable stream identifiers and video content alternatives. Under the broadest reasonable interpretation, the manifest file storing selectable tile stream associations constitutes the claimed preset co-source stream dictionary.], a source code service handle matching the to-be-played stream identifier [paras.0210: Discloses that “a client device may select a particular combination 1050 of tiles”; and para.0243: Discloses that “This enables the client to request a desired tile stream … from a network node.” Thus, Van Brandenburg teaches selecting a stream identifier corresponding to requested video content.]; and
acquiring a target video stream corresponding to the target service handle [para.0211: Discloses that the manifest file “enables a client device to request tile streams for forming a desired video mosaic.”; and para.0243: Discloses “This enables the client to request a desired tile stream … from a network node.”; and Thus, Van Brandenburg teaches acquiring the video stream corresponding to the selected stream identifier.], and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify MACINNIS with the manifest-based stream selection techniques, as taught by Van Brandenburg, in order to enable flexible and efficient selection and acquisition of desired video streams corresponding to requested video content, yielding the predictable result of improving the composition and delivery of video content originating from different content sources, as motivated by the deficiencies and needs recognized in Van Brandenburg [paras.0012-0013].
The combined teaching of MACINNIS and Van Brandenburg do not explicitly disclose acquiring, in the source code service handle, a target service handle matching the screen resolution or the network bandwidth; and a screen resolution of the first terminal by parsing the video playback request. However, in analogous art, Lewis discloses the following:
acquiring, in the source code service handle [para.0039: Discloses that “step 430 may further reference ad video segments 145” and step 430 “may further direct processor 111 to process live video segments 175 for optimal video quality depending on the requesting client device.” Under the broadest reasonable interpretation, the claimed “source code service handle” encompasses server-side information used to identify, reference, or obtain video content responsive to a client request. Thus, under the broadest reasonable interpretation, Lewis teaches server-side information used to identify, reference, or obtain video content responsive to a client request, corresponding to the claimed source code service handle.],
a target service handle matching the screen resolution or the network bandwidth [para.0039: Discloses that “if the request received from step 410 identifies client device 150 … as a screen with a 960 by 640-pixel resolution, then live video segments 175 and ad video segments 145 may be correspondingly resized to optimally fit within the target 960 by 640-pixel resolution, manifest file 157 may be provided as a M3U8 file…” Thus, Lewis teaches selecting content corresponding to the screen resolution characteristics of the client device.];
and a screen resolution of the first terminal by parsing the video playback request [para.0037: Discloses that “parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically … may all be passed to rule resolution server 120 for further evaluation” and that “These parameters may include details such as the client IP address, browser or operating platform, device identifiers, browser cookies or login details, screen resolution of display 160, and other device, display, or user parameters…” Thus, Lewis teaches obtaining the screen resolution of the first terminal from parameters associated with the video playback request.].
Lewis does not explicitly disclose a “source code service handle” as recited in the claim. However, under the broadest reasonable interpretation, the claimed source code service handle encompasses server-side information used to identify, reference, or obtain video content responsive to a client request. As discussed above, Lewis discloses obtaining client-specific parameters, including screen resolution, from a video playback request (para.0037) and utilizing those parameters to generate and provide corresponding manifest files and processed video segments tailored to the requesting client device (para.0039). Thus, Lewis discloses using request-derived client characteristics within server-side manifest generation processes corresponding to the claimed source code service handle.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combined teachings of MACINNIS and Van Brandenburg with the client-specific manifest generation techniques, as taught by Lewis, in order to tailor manifest generation and video delivery according to characteristics of the requesting client device, thereby yielding the predictable result of improving client customization and device targeting in a flexible and cost effective manner, as recognized by Lewis [paras.0005-0007].
Regarding Claim 2, the combined teachings of MACINNIS, Van Brandenburg, and Lewis disclose the video stream processing method according to claim 1, and further discloses wherein acquiring the target video stream corresponding to the target service handle comprises:
acquiring, in response to that the target service handle matching the screen resolution or the network bandwidth is acquired in the source code service handle, the target video stream corresponding to the target service handle [Van Brandenburg – paras.0211 and 0243: Discloses that the manifest file “enables a client device to request tile streams for forming a desired video mosaic” and that “This enables the client to request a desired tile stream … from a network node.”; and Lewis – para.0039: Further discloses selecting content corresponding to client-specific characteristics including screen resolution. Thus, the combined teachings disclose acquiring the target video stream corresponding to the selected service handle when an appropriate stream matching the client characteristics is available.]; and
acquiring, in response to that the target service handle matching the screen resolution or the network bandwidth is not acquired in the source code service handle, a transcoded video stream by transcoding a source video stream corresponding to the to-be-played stream identifier, and using the transcoded video stream as the target video stream [MACINNIS – para.0014: Discloses that “The distributor 110 may feed the live stream to the first and second transcoders 120 and 122, which are configured to transcode the input streams and to generate transcoded video streams.”; and para.0029: Further discloses that “The ABR server 100 transcodes a video stream, e.g. by using the first transcoder 120, to generate a transcoded video stream (420).” Thus, MACINNIS teaches generating a transcoded video stream from a source video stream and providing the transcoded stream for delivery when needed.]. This claim is rejected on the same grounds as claim 1.
Regarding Claim 3, the combined teachings of MACINNIS, Van Brandenburg, and Lewis disclose the video stream processing method according to claim 1, and further discloses wherein the source code service handle is stored in form of key-value pairs;
a key of the source code service handle is a main stream identifier of a source video stream [Van Brandenburg – paras.0206, 0210, and 0243: Discloses that a manifest file defines selectable tile streams associated with video content alternatives, that “client device may select a particular combination 1050 of tiles,” and that “This enables the client to request a desired tile stream … from a network node.” Under the broadest reasonable interpretation, the selected tile stream identifier functions as the claimed main stream identifier used to retrieve corresponding video stream information. Thus, Van Brandenburg teaches a key corresponding to a source video stream identifier.]; and
a value of the source code service handle is an original resolution or an original bit rate of the source video stream [Van Brandenburg – para.0026: Discloses that the manifest file defines a plurality of tile streams for a tile position, allowing a user to select different tile streams for one tile position, thereby storing information associated with selectable stream alternatives; and Lewis – para.0039: Discloses selecting video segments based on client characteristics including screen resolution, stating that “if the request received from step 410 identifies client device 150 … as a screen with a 960 by 640 pixel resolution, then live video segments 175 and ad video segments 145 may be correspondingly resized to optimally fit within the target 960 by 640 pixel resolution.” Thus, the combined teachings disclose associating stream identifiers with stream characteristics including resolution and bitrate information corresponding to the source video stream. Applicant’s specification further explains that the claimed “key-value pairs” may be implemented such that a main stream identifier functions as a unique key facilitating retrieval, while the corresponding value may include the original resolution and/or original bit rate of the source video stream. See Spec. [para.0062[. Accordingly, under the broadest reasonable interpretation consistent with the specification, the claimed key-value pairs reasonably encompass an association between stream identifiers and corresponding stream characteristics disclosed by the cited references.]. This claim is rejected on the same grounds as claim 1.
Regarding Claim 4, the combined teachings of MACINNIS, Van Brandenburg, and Lewis disclose the video stream processing method according to claim 1, and further discloses wherein a value of the source code service handle further comprises one or more transcoding service handles [Van Brandenburg – para.0026: Discloses that a manifest file defines a plurality of tile streams for a tile position, thereby maintaining information associated with selectable stream alternatives; and MACINNIS – para.0029: Discloses generating and maintaining transcoded versions of source video streams. Under the broadest reasonable interpretation, the maintained information associated with alternative transcoded streams corresponds to the claimed transcoding service handles.];
a key of the transcoding service handle is a transcoding identifier of the source video stream [Van Brandenburg – paras.0026, 0210, and 243: Discloses selectable tile streams associated with video content alternatives, wherein a client device may select a particular combination of tiles and request the desired tile stream from a network node. Under the broadest reasonable interpretation, the URLs or stream identifiers corresponding to the selectable tile streams function as identifiers for the corresponding transcoded video streams. Thus, Van Brandenburg teaches a key corresponding to a transcoding identifier of a source video stream.], and a value of the transcoding service handle is a transcoding resolution or a transcoding bit rate of a transcoded video acquired through transcoding [Lewis – para.0039: Discloses selecting video segments based on client characteristics including screen resolution, stating that “if the request received from step 410 identifies client device 150 … as a screen with a 960 by 640 pixel resolution, then live video segments 175 and ad video segments 145 may be correspondingly resized to optimally fit within the target 960 by 640 pixel resolution”; and MACINNIS – para.0029: Discloses transcoding video streams into alternative versions for delivery. Thus, the combined teachings disclose associating identified transcoded video streams with transcoding characteristics including transcoding resolution or transcoding bit rate.]. This claim is rejected on the same grounds as claim 1.
Regarding Claim 12, the combined teachings of MACINNIS, Van Brandenburg, and Lewis disclose the video stream processing method according to claim 1, and further discloses further comprising:
receiving a source video stream sent by a second terminal, and configuring a main stream identifier for the source video stream [MACINNIS – para.0013: Disclose a content source 110, distributor 110, first and second transducers 120 and 122, and a storage device 130; and para.0014: Discloses that “The distributor 110 may feed the live stream to the first and second transcoders 120 and 122, which are configured to transcode the input streams and to generate transcoded video streams.’; and Van Brandenburg – para.0243: Discloses requesting and identifying desired tile streams and stream selections through identifiers associated with video content. Thus, the combined teachings disclose receiving a source video stream and utilizing identifiers associated with the received video stream, which corresponds to configuring a main stream identifier for the source video stream.];
generating a source code service handle of the source video stream according to an original resolution and an original bit rate of the source video stream and the main stream identifier [Lewis – para.0037: Discloses obtaining client and display parameters including screen resolution; and para.0039: Discloses processing video segments according to device characteristics and generating corresponding manifests and video content selections; and MACINNIS – para.0015: Discloses that “The one or more characteristic of the transcoded video stream may include, but is limited to, a compressed data rate, a frame size, a frame rate, or a video mode.” Under the broadest reasonable interpretation, the claimed “source code service handle” encompasses server-side information used to identify, reference, and manage video content according to stream characteristics, including bitrate, resolution, and stream identification information. Thus, the combined teachings disclose generating information structures corresponding to the claimed source code service handle according to stream characteristics including resolution, bitrate, and stream-identification information.]; and
constructing the preset co-source stream dictionary according to the source code service handle [Van Brandenburg – para.0206: Discloses “Such manifest file is characterized in that it defines a plurality of tile streams for one tile position...”; and paras.0211 and 0243: Discloses utilizing the manifest structure to identify and request corresponding video streams. Under the broadest reasonable interpretation, the manifest structure storing associations between stream identifiers and corresponding video content constitutes the claimed preset co-source stream dictionary. Thus, Van Brandenburg teaches constructing a stream association structure according to information corresponding to the claimed source code service handle.]. This claim is rejected on the same grounds as claim 1.
Regarding Claim 16, MACINNIS discloses an electronic device [FIG.3, para.0026: Discloses an “ABR server 300” including processor 310, storage device 320, network interface 330, bus 340, and memory 350. FIG.3 illustrates an example of an ABR server 300, thus MACINNIS teaches an electronic device.], comprising:
a processor [para.0026: Discloses “The ABR server 300 may include a processor 310…” and further discloses “The processor may include a number of hardware cores that can perform various functionalities…” Thus, MACINNIS teaches a processor.]; and
a memory, configured to store executable instructions of the processor [para.0026: Discloses “The memory 350 may include RAM, DRAM, static RAM (SRAM), flash memory, etc.”; and para.0027: Discloses “The memory 350 may include … a number of program modules that can be executed by the processor 310.” Thus, MACINNIS teaches memory storing instruction that are executed by the processor.];
wherein the processor is configured to, through executing the executable instructions, implement a video stream processing method [para.0027: Discloses ‘The program modules may include a network monitoring module 360, an adjusting module 362, a channel bonding module 364, an advertising module 366, and a chunk distributor module 368, which when executed by the processor 310 may perform the functionalities of the corresponding modules described above with respect to the ABR server 100 FIG.1.’ Thus, MACINNIS teaches a processor configured to execute instructions stored in memory to implement video stream processing operations.] comprising:
receiving a video playback request sent by a first terminal [para.0016: Discloses “The network interface 170 may transmit segments of the transcoded video stream to the client device 190 via the network 180, e.g. in response to requests therefor.” Thus, MACINNIS teaches receiving playback requests from a client terminal requesting video content.], and acquiring a to-be-played stream identifier, a network bandwidth [para.0014: Discloses “the network monitor module 140 may periodically send Hyper-Text Transport Protocol (HTTP) status requests… and measure metrics such as response time, availability, uptime, throughput, and latency, and based on the measurement results, estimate a current available bandwidth.” Thus, MACINNIS teaches acquiring network bandwidth information associated with the client/network.];
pushing the target video stream to the first terminal [claim 1: Discloses “providing the segments of the first transcoded video stream to the client device via the network in response to requests therefor”; and para.0016: Discloses “The network interface 170 may transmit segments of the transcoded video stream to the client device 190 via the network 180, e.g. in response to requests therefor.” Thus, MACINNIS teaches transmitting/pushing the video stream to the terminal.].
MACINNIS does not explicitly disclose acquiring, in a preset co-source stream dictionary, a source code service handle matching the to-be-played stream identifier, acquiring a target video stream corresponding to the target service handle; However, in analogous art, Van Brandenburg discloses the following:
acquiring, in a preset co-source stream dictionary [para.0206: Discloses “Such manifest file is characterized in that it defines a plurality of tile streams for one tile position… allowing a user to select different tile streams for one tile position.” Thus, Van Brandenburg teaches a predefined manifest structure storing associations between selectable stream identifiers and video content alternatives. Under the broadest reasonable interpretation, the manifest file storing selectable tile stream associations constitutes the claimed preset co-source stream dictionary.], a source code service handle matching the to-be-played stream identifier [paras.0210: Discloses that “a client device may select a particular combination 1050 of tiles”; and para.0243: Discloses that “This enables the client to request a desired tile stream … from a network node.” Thus, Van Brandenburg teaches selecting a stream identifier corresponding to requested video content.]; and
acquiring a target video stream corresponding to the target service handle [para.0211: Discloses that the manifest file “enables a client device to request tile streams for forming a desired video mosaic.”; and para.0243: Discloses “This enables the client to request a desired tile stream … from a network node.”; and Thus, Van Brandenburg teaches acquiring the video stream corresponding to the selected stream identifier.], and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify MACINNIS with the manifest-based stream selection techniques, as taught by Van Brandenburg, in order to enable flexible and efficient selection and acquisition of desired video streams corresponding to requested video content, yielding the predictable result of improving the composition and delivery of video content originating from different content sources, as motivated by the deficiencies and needs recognized in Van Brandenburg [paras.0012-0013].
The combined teaching of MACINNIS and Van Brandenburg do not explicitly disclose acquiring, in the source code service handle, a target service handle matching the screen resolution or the network bandwidth; and a screen resolution of the first terminal by parsing the video playback request. However, in analogous art, Lewis discloses the following:
acquiring, in the source code service handle [para.0039: Discloses that “step 430 may further reference ad video segments 145” and step 430 “may further direct processor 111 to process live video segments 175 for optimal video quality depending on the requesting client device.” Under the broadest reasonable interpretation, the claimed “source code service handle” encompasses server-side information used to identify, reference, or obtain video content responsive to a client request. Thus, under the broadest reasonable interpretation, Lewis teaches server-side information used to identify, reference, or obtain video content responsive to a client request, corresponding to the claimed source code service handle.],
a target service handle matching the screen resolution or the network bandwidth [para.0039: Discloses that “if the request received from step 410 identifies client device 150 … as a screen with a 960 by 640-pixel resolution, then live video segments 175 and ad video segments 145 may be correspondingly resized to optimally fit within the target 960 by 640-pixel resolution, manifest file 157 may be provided as a M3U8 file…” Thus, Lewis teaches selecting content corresponding to the screen resolution characteristics of the client device.];
and a screen resolution of the first terminal by parsing the video playback request [para.0037: Discloses that “parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically … may all be passed to rule resolution server 120 for further evaluation” and that “These parameters may include details such as the client IP address, browser or operating platform, device identifiers, browser cookies or login details, screen resolution of display 160, and other device, display, or user parameters…” Thus, Lewis teaches obtaining the screen resolution of the first terminal from parameters associated with the video playback request.].
Lewis does not explicitly disclose a “source code service handle” as recited in the claim. However, under the broadest reasonable interpretation, the claimed source code service handle encompasses server-side information used to identify, reference, or obtain video content responsive to a client request. As discussed above, Lewis discloses obtaining client-specific parameters, including screen resolution, from a video playback request (para.0037) and utilizing those parameters to generate and provide corresponding manifest files and processed video segments tailored to the requesting client device (para.0039). Thus, Lewis discloses using request-derived client characteristics within server-side manifest generation processes corresponding to the claimed source code service handle.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combined teachings of MACINNIS and Van Brandenburg with the client-specific manifest generation techniques, as taught by Lewis, in order to tailor manifest generation and video delivery according to characteristics of the requesting client device, thereby yielding the predictable result of improving client customization and device targeting in a flexible and cost effective manner, as recognized by Lewis [paras.0005-0007].
Regarding Claim 17, Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over MACINNIS in view of Van Brandenburg and further in view of Lewis for substantially the same reasons set forth with respect to Claim 2. Claim 17 recites corresponding limitations to those of Claim 2 in electronic-device form (e.g., electronic-device configured to perform the corresponding functions recited in Claim 2) and does not further distinguish over the applied references.
Regarding Claim 18, Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over MACINNIS in view of Van Brandenburg and further in view of Lewis for substantially the same reasons set forth with respect to Claim 3. Claim 18 recites corresponding limitations to those of Claim 3 in electronic-device form (e.g., electronic-device configured to perform the corresponding functions recited in Claim 3) and does not further distinguish over the applied references.
Regarding Claim 19, Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over MACINNIS in view of Van Brandenburg and further in view of Lewis for substantially the same reasons set forth with respect to Claim 4. Claim 19 recites corresponding limitations to those of Claim 4 in electronic-device form (e.g., electronic-device configured to perform the corresponding functions recited in Claim 4) and does not further distinguish over the applied references.
Regarding Claim 22, MACINNIS discloses a computer-readable storage medium storing a computer program thereon, wherein the computer program is used for, upon being executed by a processor, implementing a video stream processing method [para.0030: Discloses “Implementations within the scope of the present disclosure can be partially or entirely realized using a tangible computer-readable storage medium … encoding one or more instructions.”; and para.0031: Discloses processor executing the instruction; and para.0027: Discloses ‘The program modules may include a network monitoring module 360, an adjusting module 362, a channel bonding module 364, an advertising module 366, and a chunk distributor module 368, which when executed by the processor 310 may perform the functionalities of the corresponding modules described above with respect to the ABR server 100 FIG.1.’ Thus, MACINNIS teaches a processor configured to execute instructions stored in memory to implement video stream processing operations.] comprising:
receiving a video playback request sent by a first terminal [para.0016: Discloses “The network interface 170 may transmit segments of the transcoded video stream to the client device 190 via the network 180, e.g. in response to requests therefor.” Thus, MACINNIS teaches receiving playback requests from a client terminal requesting video content.], and acquiring a to-be-played stream identifier, a network bandwidth [para.0014: Discloses “the network monitor module 140 may periodically send Hyper-Text Transport Protocol (HTTP) status requests… and measure metrics such as response time, availability, uptime, throughput, and latency, and based on the measurement results, estimate a current available bandwidth.” Thus, MACINNIS teaches acquiring network bandwidth information associated with the client/network.];
pushing the target video stream to the first terminal [claim 1: Discloses “providing the segments of the first transcoded video stream to the client device via the network in response to requests therefor”; and para.0016: Discloses “The network interface 170 may transmit segments of the transcoded video stream to the client device 190 via the network 180, e.g. in response to requests therefor.” Thus, MACINNIS teaches transmitting/pushing the video stream to the terminal.].
MACINNIS does not explicitly disclose acquiring, in a preset co-source stream dictionary, a source code service handle matching the to-be-played stream identifier, acquiring a target video stream corresponding to the target service handle; However, in analogous art, Van Brandenburg discloses the following:
acquiring, in a preset co-source stream dictionary [para.0206: Discloses “Such manifest file is characterized in that it defines a plurality of tile streams for one tile position… allowing a user to select different tile streams for one tile position.” Thus, Van Brandenburg teaches a predefined manifest structure storing associations between selectable stream identifiers and video content alternatives. Under the broadest reasonable interpretation, the manifest file storing selectable tile stream associations constitutes the claimed preset co-source stream dictionary.], a source code service handle matching the to-be-played stream identifier [paras.0210: Discloses that “a client device may select a particular combination 1050 of tiles”; and para.0243: Discloses that “This enables the client to request a desired tile stream … from a network node.” Thus, Van Brandenburg teaches selecting a stream identifier corresponding to requested video content.]; and
acquiring a target video stream corresponding to the target service handle [para.0211: Discloses that the manifest file “enables a client device to request tile streams for forming a desired video mosaic.”; and para.0243: Discloses “This enables the client to request a desired tile stream … from a network node.”; and Thus, Van Brandenburg teaches acquiring the video stream corresponding to the selected stream identifier.], and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify MACINNIS with the manifest-based stream selection techniques, as taught by Van Brandenburg, in order to enable flexible and efficient selection and acquisition of desired video streams corresponding to requested video content, yielding the predictable result of improving the composition and delivery of video content originating from different content sources, as motivated by the deficiencies and needs recognized in Van Brandenburg [paras.0012-0013].
The combined teaching of MACINNIS and Van Brandenburg do not explicitly disclose acquiring, in the source code service handle, a target service handle matching the screen resolution or the network bandwidth; and a screen resolution of the first terminal by parsing the video playback request. However, in analogous art, Lewis discloses the following:
acquiring, in the source code service handle [para.0039: Discloses that “step 430 may further reference ad video segments 145” and step 430 “may further direct processor 111 to process live video segments 175 for optimal video quality depending on the requesting client device.” Under the broadest reasonable interpretation, the claimed “source code service handle” encompasses server-side information used to identify, reference, or obtain video content responsive to a client request. Thus, under the broadest reasonable interpretation, Lewis teaches server-side information used to identify, reference, or obtain video content responsive to a client request, corresponding to the claimed source code service handle.],
a target service handle matching the screen resolution or the network bandwidth [para.0039: Discloses that “if the request received from step 410 identifies client device 150 as … as a screen with a 960 by 640-pixel resolution, then live video segments 175 and ad video segments 145 may be correspondingly resized to optimally fit within the target 960 by 640-pixel resolution, manifest file 157 may be provided as a M3U8 file…” Thus, Lewis teaches selecting content corresponding to the screen resolution characteristics of the client device.];
and a screen resolution of the first terminal by parsing the video playback request [para.0037: Discloses that “parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically … may all be passed to rule resolution server 120 for further evaluation” and that “These parameters may include details such as the client IP address, browser or operating platform, device identifiers, browser cookies or login details, screen resolution of display 160, and other device, display, or user parameters…” Thus, Lewis teaches obtaining the screen resolution of the first terminal from parameters associated with the video playback request.].
Lewis does not explicitly disclose a “source code service handle” as recited in the claim. However, under the broadest reasonable interpretation, the claimed source code service handle encompasses server-side information used to identify, reference, or obtain video content responsive to a client request. As discussed above, Lewis discloses obtaining client-specific parameters, including screen resolution, from a video playback request (para.0037) and utilizing those parameters to generate and provide corresponding manifest files and processed video segments tailored to the requesting client device (para.0039). Thus, Lewis discloses using request-derived client characteristics within server-side manifest generation processes corresponding to the claimed source code service handle.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combined teachings of MACINNIS and Van Brandenburg with the client-specific manifest generation techniques, as taught by Lewis, in order to tailor manifest generation and video delivery according to characteristics of the requesting client device, thereby yielding the predictable result of improving client customization and device targeting in a flexible and cost effective manner, as recognized by Lewis [paras.0005-0007].
Claims 5-10 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over MACINNIS et al., Pub No US 2014/0344443 (hereafter MACINNIS) in view of Van Brandenburg et al., Pub No US 2018/0242028 (hereafter Van Brandenburg) and further in view of Lewis et al., Pub No US 2012/0047542 (hereafter Lewis) and further in view of Charles A. Hasek, Pub No US 2009/0083279 (hereafter Hasek).
Regarding Claim 5, the combined teachings of MACINNIS, Van Brandenburg, and Lewis disclose the video stream processing method according to claim 2, and the combined teachings do not explicitly disclose wherein acquiring the transcoded video stream by transcoding the source video stream corresponding to the to-be-played stream identifier comprises:
acquiring a source picture group comprised in the source video stream corresponding to the to-be-played stream identifier, and acquiring a source key frame comprised in the source picture group; acquiring an instantaneous decoding refresh (IDR) frame in the source key frame, and acquiring a sequence parameter set and a picture parameter set comprised in the IDR frame by parsing the IDR frame; and initializing a preset transcoding function based on the sequence parameter set and the picture parameter set, and acquiring the transcoded video stream by transcoding the source video stream based on the initialized transcoding function.
However, in analogous art, Hasek discloses the following:
acquiring a source picture group comprised in the source video stream corresponding to the to-be-played stream identifier, and acquiring a source key frame comprised in the source picture group [para.0148: Discloses “Intra (I)-frames and Instantaneous Decoder Refresh (IDR) frames serve as the reference for all frames in a GOP” and “A so-called "key" frame is transmitted.” Hasek further discloses identifying key frames within a video stream and utilizing such key frames as reference frames as associated with a group of pictures (GOP). Under the broadest reasonable interpretation, Hasek teaches acquiring a source picture group (GOP) from a video stream and acquiring a source key frame comprised within that picture group.];
acquiring an instantaneous decoding refresh (IDR) frame in the source key frame, and acquiring a sequence parameter set and a picture parameter set comprised in the IDR frame by parsing the IDR frame [para.0148: Discloses that “Intra (I)-frames and Instantaneous Decoder Refresh (IDR) frames serve as the reference for all frames in a GOP”; and para.0149: Discloses that “information necessary for decoding…can be included in the key frame,” including “Sequence Parameter Set (SPS) and Picture Parameter Set (PPS) for MPEG-4 part-I 0/H.264,” and further teaches that “key frame may be identified as such using the header of the coded video information without fully decoding the encoded data.” Under the broadest reasonable interpretation, Hasek teaches obtaining an IDR frame within a key frame and obtaining SPS and PPS information by examining/parsing the key-frame information associated with the IDR frame.];
initializing a preset transcoding function based on the sequence parameter set and the picture parameter set, and acquiring the transcoded video stream by transcoding the source video stream based on the initialized transcoding function [para.0260: Discloses a Session Create message sent to a transcoder/transrater; and para.0264: Discloses “output video CODEC: indicates the video CODEC for output video stream”; and para.0271: Discloses “output horizontal resolution”; and para.0272: Discloses “output vertical resolution”; and para.273: Discloses “output bit-rate.” Thus, Hasek teaches initializing a transcoding function using specified transcoding parameters because that Session Create message provides output codec, resolution, and bit-rate settings to the transcoder/transrater before generation of the output stream, and further teaches acquiring a transcoded video stream by transcoding the source video stream according to those initialized settings.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combined teachings of MACINNIS, Van Brandenburg, and Lewis with the IDR-frame and SPS/PPS-based transcoding techniques, as taught by Hasek, in order to identify stream configuration information contained within key-frame structures and utilize such information to initialize transcoding operations for generation of a transcoded output stream. Such modification would have yielded the predictable result of efficiently generating transcoded video streams according to parameters already present within the source video stream while improving compatibility with target playback devices [Hasek - paras.0004, 0013].
Regarding Claim 6, the combined teachings of MACINNIS, Van Brandenburg, Lewis, and Hasek disclose the video stream processing method according to claim 5, and MACINNIS further discloses wherein acquiring the transcoded video stream by transcoding the source video stream based on the initialized transcoding function comprises:
acquiring encapsulated format data by decapsulating the source video stream based on the initialized transcoding function, and acquiring compressed audio data and compressed video data by decapsulating the encapsulated format data [para.014: Discloses that “The distributor 110 may feed the live stream to the first and second transcoders 120 and 122, which are configured to transcode the input streams and to generate transcoded video streams”; and para,0029: Discloses that “The ABR server 100 transcodes a video stream … to generate a transcoded video stream (420).” Under the broadest reasonable interpretation, a transcoder receives an encoded input stream and processes the constituent compressed audio/video data before generation of a transcoded output stream. Thus, MACINNIS teaches obtaining compressed media data from an input video stream for transcoding.];
acquiring original audio data and original video data by performing audio decoding and video decoding on the compressed audio data and the compressed video data, and acquiring transcoded audio data and transcoded video data by transcoding the original audio data and the original video data [para.014: Discloses transcoders configured to transcode input streams; and para.0029: Discloses transcoding a video stream to generate a transcoded video stream. Under the broadest reasonable interpretation, transcoding encoded media necessarily includes decoding source media data and re-encoding/transcoding the media data into a different output representation. Thus, MACINNIS teaches obtaining original media data through decoding and generating transcoded media data through transcoding operation.]; and
acquiring the transcoded video stream by encapsulating the transcoded audio data and the transcoded video data [para,0029: Discloses generating a “transcoded video stream (420)”; and para.0016: Discloses transmitting segments of the transcoded video stream to the client device. Thus, MACINNIS teaches generating a formatted transcoded output stream for delivery, which reasonably encompasses encapsulating transcoded media data into the transcoded video stream.].
Regarding Claim 7, the combined teachings of MACINNIS, Van Brandenburg, Lewis, and Hasek disclose the video stream processing method according to claim 6, and further discloses further comprising:
generating a transcoding identifier corresponding to the transcoded video stream, and generating a to-be-added transcoding service handle of the transcoded video stream based on the transcoding identifier, a transcoding resolution and a transcoding bit rate of the transcoded audio data and the transcoded video data [MACINNIS – para.0029: Discloses that “The ABR server 100 transcodes a video stream … to generate a transcoded video stream (420),” thereby generating identifiable transcoded versions of a source stream; and Lewis – para.0039: Discloses selecting and providing video content according to client characteristics including screen resolution, stating that “if the request received from step 410 identifies client device 150 … as a screen with a 960 by 640 pixel resolution, then live video segments 175 and ad video segments 145 may be correspondingly resized to optimally fit within the target 960 by 640 pixel resolution”; and MACINNIS – para.0014: Discloses generating transcoded video streams for delivery at alternative stream representations. Under the broadest reasonable interpretation, the generated transcoded stream is associated with identifying information and transcoding characteristics including resolution and bitrate used to distinguish one transcoded representation from another. Thus, the combined teachings disclose generating a transcoding identifier and generating information corresponding to a transcoding service handle based on a transcoded stream and associate transcoding characteristics.]; and
updating the source code service handle of the source video stream using the to-be-added transcoding service handle [Van Brandenburg – para.0206: Discloses that a manifest file “defines a plurality of tile streams for one tile position,” Thereby maintaining associations between available stream alternatives; para.0243: Discloses that “This enables the client to request a desired tile stream … from a network node]”; and Lewis – para.0039: Discloses generating and providing client-specific manifest information corresponding to available video streams. Under the broadest reasonable interpretation, updating a manifest or stream association structure to include an additional transcoded stream representation corresponds to updating the claimed source code service handle using the generated transcoding service handle. Thus, the combined teachings disclose updating stored stream association information to include an additional transcoded stream representation.] This claim is rejected on the same grounds as claim 6.
Regarding Claim 8, the combined teachings of MACINNIS, Van Brandenburg, Lewis, and Hasek disclose the video stream processing method according to claim 5, and Hasek further discloses wherein a transcoded keyframe comprised in each transcoded picture group of the transcoded video stream with different transcoding resolutions and transcoding bit rates is same as a source keyframe comprised in the source code picture group [para.0148: Discloses that “Intra (I)-frames and Instantaneous Decoder Refresh (IDR) frames serve as the reference for all frames in a GOP” and further explains that a so-called “key” frame is transmitted; and para.0149: Discloses that information necessary for decoding, including SPS and PPS information, may be identified from the key frame associated with the video stream. Under the broadest reasonable interpretation, Hasek teaches utilizing the same source key frame as the reference frame for generation and management of transcoded stream representations because the key frame/IDR frame contains the stream configuration information used for transcoding operations. Thus, Hasek teaches a transcoded picture group utilizing the same source key frame corresponding to the source picture group despite generation of transcoded streams having different resolutions or but rates.]. This claim is rejected on the same grounds as claim 5.
Regarding Claim 9, the combined teachings of MACINNIS, Van Brandenburg, Lewis, and Hasek disclose the video stream processing method according to claim 8, and Hasek further discloses wherein, before acquiring the transcoded video stream by transcoding the source video stream corresponding to the to-be-played stream identifier, and pushing the transcoded video stream to the first terminal, the video stream processing method further comprises:
reading the transcoded picture group or the source code picture group, and placing the transcoded picture group or the source code picture group into a preset cache channel [para.0200: Discloses that content segments may be stored in cache memory for subsequent delivery; and para.0203: Discloses retrieving cached content and managing content placement within cache resources. Under the broadest reasonable interpretation, the cached content segments correspond to the claimed transcoded picture group or source picture group, and the cache memory corresponds to the claimed preset cache channel. Thus, Hasek teaches reading a transcoded picture group or source picture group and placing the picture group into a cache channel for later delivery.]; and
pushing, based on a placement order of the transcoded picture group or the source code picture group in the cache channel, the transcoded picture group or the source code picture group to the first terminal [para.0203: Discloses retrieving cached content for delivery to requesting device; and para.0204: Discloses transmitting cached content from the cache toward client devices. Under the broadest reasonable interpretation, delivery of cached content according to its stored organization within the cache corresponds to pushing picture groups based on their placement order within the cache channel. Thus, Hasek teaches pushing the transcoded picture group or source picture group from the cache channel to the first terminal.]. This claim is rejected on the same grounds as claim 8.
Regarding Claim 10, the combined teachings of MACINNIS, Van Brandenburg, Lewis, and Hasek disclose the video stream processing method according to claim 9, and further discloses wherein reading the transcoded picture group or the source code picture group comprises:
acquiring one or more transcoding resolutions, or one or more transcoding bit rates, or a source code resolution and a source code bit rate comprised in the source code service handle [Lewis – para.0039: Discloses that “if the request received from step 410 identifies client device 150 … as a screen with a 960 by 640 pixel resolution, then live video segments 175 and ad video segments 145 may be correspondingly resized to optimally fit within the target 960 by 640 pixel resolution”; and further discloses selecting video content based on client device characteristics. Under the broadest reasonable interpretation, the disclosed video resolutions and corresponding stream characteristics constitute the claimed transcoding resolutions, transcoding bit rates, source code resolution, and source code bit rate comprised in the source code service handle. Thus, Lewis teaches acquiring transcoding resolutions and/or bit rates associated with a video stream.];
acquiring a first difference calculation result by calculating a difference between the network bandwidth and the source code bit rate or the transcoding bit rate, and acquiring a second difference calculation result by calculating a difference between the screen resolution and the source code resolution or the transcoding resolution [MACINNIS – para.0014: Discloses measuring network metrics including “throughput” and estimating “a current available bandwidth”; and Lewis – para.0039: Discloses selecting video segments based on screen resolution characteristics of the client device. Under the broadest reasonable interpretation, comparing available network bandwidth to stream bit rates and comparing device screen resolution to available stream resolutions requires determining differences between the respective values for stream selection purposes. Thus, the combined teachings teach acquiring first and second difference calculation results based on bandwidth and resolution comparisons.]; and
determining the target service handle based on the first difference calculation result and the second difference calculation result, and reading the transcoded picture group or the source code picture group corresponding to a target stream identifier comprised in the target service handle [Van Brandenburg – paras.0210-0211, 0243: Discloses selecting a desired tile stream from a manifest and requesting the desired tile stream from a network node; and Lewis – para.0039: Discloses selecting content according to client-device display characteristics. Under the broadest reasonable interpretation, the selected stream identifier corresponds to the claimed target service handle, and the requested tile stream corresponds to the claimed transcoded picture group or source code picture group corresponding to the target stream identifier. Thus, the combined teachings teach determining a target service handle based on bandwidth and resolution considerations and reading the corresponding picture group for delivery.]. This claim is rejected on the same grounds as claim 9.
Regarding Claim 20, Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over MACINNIS in view of Van Brandenburg and further in view of Lewis for substantially the same reasons set forth with respect to Claim 5. Claim 20 recites corresponding limitations to those of Claim 5 in electronic-device form (e.g., electronic-device configured to perform the corresponding functions recited in Claim 5) and does not further distinguish over the applied references.
Regarding Claim 21, Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over MACINNIS in view of Van Brandenburg and further in view of Lewis for substantially the same reasons set forth with respect to Claim 6. Claim 21 recites corresponding limitations to those of Claim 6 in electronic-device form (e.g., electronic-device configured to perform the corresponding functions recited in Claim 6) and does not further distinguish over the applied references.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over MACINNIS et al., Pub No US 2014/0344443 (hereafter MACINNIS) in view of Van Brandenburg et al., Pub No US 2018/0242028 (hereafter Van Brandenburg) and further in view of Lewis et al., Pub No US 2012/0047542 (hereafter Lewis) and further in view of SHI et al., Pub No US 2020/0394414 (hereafter SHI).
Regarding Claim 11, the combined teachings of MACINNIS, Van Brandenburg, and Lewis disclose the video stream processing method according to claim 8, and the combined teachings do not explicitly disclose wherein the transcoded picture group or the source code picture group comprises a current key frame, a first predicted frame obtained by performing prediction on the current key frame, and a second predicted frame obtained by performing prediction on the current key frame and the first predicted frame; and wherein the video stream processing method further comprises: acquiring the current key frame by performing calculation on the source video stream based on a preset image recognition model, wherein the image recognition model comprises any one or more of a convolutional neural network model, a recurrent neural network model, and a deep neural network model.
However, in analogous art, SHI discloses the following:
wherein the transcoded picture group or the source code picture group comprises a current key frame, a first predicted frame obtained by performing prediction on the current key frame, and a second predicted frame obtained by performing prediction on the current key frame and the first predicted frame [claim 1 of SHI: Discloses “determining whether the current frame is scheduled as a key frame”; and para.0074: Discloses determining whether other frames are scheduled as key frames based on the low-level feature of the key frame; and para.0080: Discloses determining whether frames after the current key frame are scheduled key frames; and paras.097-0100: Discloses processing adjacent frames using features derived from the current key frame. Thus, Shi teaches a current key frame and subsequent frames determined using information derived from the current key frame, which under the broadest reasonable interpretation corresponds to first and second predicted frames obtained based on the current key frame.]; and
wherein the video stream processing method further comprises: acquiring the current key frame by performing calculation on the source video stream based on a preset image recognition model, wherein the image recognition model comprises any one or more of a convolutional neural network model, a recurrent neural network model, and a deep neural network model [para.0060: Discloses performing feature extraction on a current frame via a first network layer of a neural network; and para.0069: Discloses performing feature extraction on a current key frame via a second network layer of the neural network; and para.0072: Discloses that the neural network included two or more network layers having different depths; and para.0073: Discloses a Pyramid Scene Parsing Network (PSPN) including multiple convolutional network layers. Thus, SHI teaches acquiring a current key frame using calculations performed by a multi-layer neural network including convolutional layers, which under broadest reasonable interpretation corresponds to the claimed image recognition model.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combined teachings of MACINNIS, Van Brandenburg, and Lewis with the neural-network-based key frame determination techniques, as taught by SHI, in order to identify and process key frames using learned image features, thereby improving frame selection accuracy and video processing efficiency while yielding the predictable result of enhanced video stream analysis and processing [SHI, paras.0003, 0074, and 0091].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wang et al., (US 2023/0104270) – Discloses video compression schemes that break images and frames into smaller portions and generating a compressed bitstream using techniques to limit the information included for respective blocks in the output. The compressed bitstream can be decoded to re-create the source images from the limited information [para.0035]. Further discloses transcode uploaded video content into multiple target resolutions before serving the video content to platform users [para.0036]. Discloses a transcoding stage 706 that transcodes the video stream 602 using the transcoding parameters selected at the parameter selection stage 704 for each resolution to produce output transcoded video streams, such as the transcoded video stream I 708 through the transcoded video stream M 710. In this way, the video stream 602 can be optimally transcoded into multiple different resolutions using the selected transcoding parameters, such as to maximize the delivered quality of the video stream 602 at each of a number of different resolutions [para.0092].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ADIL OCAK whose telephone number is (571) 272-2774. The examiner can normally be reached on M-F 8:00 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nasser Goodarzi can be reached on 571-272-4195. 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.
/ADIL OCAK/Primary Examiner, Art Unit 2426
Prosecution Insights