DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Applicant’s RCE filed 12/29/2025 is acknowledged.
Claims 1,11, and 17 are amended.
Claims 1-20 are pending.
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 12/29/2025 has been entered.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-3,5,8-12,14, 16, 17, and 20 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Medina (US 20100077440) in view of Sloo (US 20090222520), Hasek (US 20090083279) and Cholas (US 20090207866).
Re claim 1:
Medina discloses receiving, by a multicast server and from a multicast controller, a multicast setup request (Para.[0065] When users issue requests for VoD content via the set-top box devices 316, 324, the requests can be transmitted over the access network 366 to the VoD server 336, via the CFT switch 330 and Para.[0035] In an illustrative embodiment, the subscriber and system store 348 can store subscriber or customer data and create subscriber or customer profiles that are associated with IP addresses, stock-keeping unit (SKU) numbers, other identifiers, or any combination thereof, of corresponding set-top box devices 316, 324 and Para.[0055] The service provider can distribute the main profile of the media content to viewers, such as through multicast protocol or other distribution techniques including VoD);
selecting, based on a plurality of profiles associated with one or more versions of content and (Para.[0061] In one embodiment, the presenting of a lower profile version of the media content to a viewer, such as for VoD, can be based on a user profile and/or monitored behavior of the user. For example, a user profile can designate a fault threshold for switching to the lower profile version of the media content and/or can designate a lower limit of resolution before presenting an audio-only signal and Para.[0051] In one embodiment, the lower profile copies have lower resolution and higher error correction data, such as more FEC symbols in the data stream. In another embodiment, the main profile of the media content can be generated in MPEG-2 format while the lower profiles can be generated in H264 and/or VC1 format);
generating, a multicast stream based on a version of the content provided (Para.[0041] Upon receiving such requests, the VoD server 336 can retrieve the requested VoD content and transmit the content to the set-top box devices 316, 324 across the access network 366, via the CFT switch 330. The set-top box devices 316, 324 can transmit the VoD content to the television monitors 318, 326. In an illustrative embodiment, video or audio portions of VoD content can be streamed to the set-top box devices 316, 324);
sending, to the one or more computing devices, the multicast stream (Para.[0041] Upon receiving such requests, the VoD server 336 can retrieve the requested VoD content and transmit the content to the set-top box devices 316, 324 across the access network 366, via the CFT switch 330. The set-top box devices 316, 324 can transmit the VoD content to the television monitors 318, 326. In an illustrative embodiment, video or audio portions of VoD content can be streamed to the set-top box devices 316, 324 and Para.[0055] The service provider can distribute the main profile of the media content to viewers, such as through multicast protocol or other distribution techniques including VoD); and
sending, to the multicast controller, status information of the multicast stream, wherein the status information comprises a parameter identifying a information associated with the sending of the multicast stream to the one or more computing devices (Para.[0057] For example, metric data can be provided to the STB for presentation with the technical difficulty image, such as available resolution, expected time until the video of the media content will again be presented, and so forth).
Medina does not explicitly disclose selecting a streamer to provide the content; content provided by the streamer.
Sloo discloses selecting a streamer to provide the content; content provided by the streamer (Para.[0034] A content request may then be received from client 110 by network server 160 at step 320. Requests may be received in several ways known in the art, such as for example in a SOAP message, or some other message format. The request will contain an identification of the client device making the request and the content requested. After receiving a content request, network server 160 may retrieve the content from a content source at step 330. Retrieving the content may include looking up the location of the content using content source lookup table 165 and requesting the content from the corresponding content source. The corresponding content source receives the request, retrieves the content and sends the retrieved content to network server 160 and Para.[0044] A viewing group is managed by synchronization server 170 for each group of contacts playing a particular content element. If there is not currently a viewing group for synchronized viewing of the content requested by the user, a new viewing group is created for the content viewed by the user and at least one contact at step 535 and the method continues to step 550. If a viewing group does exist, the user is added to the existing viewing group for the selected content).
Medina and Sloo are analogous because they both pertain to content distribution.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Medina to include selecting a streamer to provide content, as taught by Sloo, in order to synchronize playback of content downloaded or streamed from a network service for users at different client locations (Sloo Para.[0003]).
Medina does not explicitly disclose based on a bitrate associated with one or more computing devices.
Hasek discloses based on a profile and a bitrate associated with one or more computing devices (Para.[0218] establishes a profile for the CPE 106 in terms of the capabilities of interest. In one embodiment, the capabilities of interest comprise the video codec, bitrate, and encryption/DRM support of the CPE (or the client device) and Fig.3D ref. 376 Use profile in selecting content version).
Medina and Hasek are analogous because they both pertain to content distribution.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Medina to use a bitrate associated with a computing device in performing a selection, as taught by Hasek, in order to maximize network efficiency (Hasek Para.[0004]).
As shown above, Medina sending, to the multicast controller, status information about the multicast stream. Medina does not explicitly disclose the status information identifies a bitrate.
Cholas discloses the status information identifies a bitrate (Para.[0104] The statistical multiplexer in this embodiment signals the consumer premises equipment (e.g., settop box) regarding characteristics of the transmitted video stream and the descriptive parameters such as minimum/maximum/average bitrates, jitter/delay, or anything that would affect QoS (or that relates to the properties of the relevant transport generally) and Para.[0187]).
Medina and Cholas are analogous because they both pertain to content distribution.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Medina to include bitrate in status information, as taught by Cholas, in order to maintain and enforce QoS policy (Cholas Para.[0104]).
Re claim 2:
Medina discloses wherein each of the plurality of profiles comprises one or more characteristics associated with each of the one or more versions of the content (Para.[0051] In one embodiment, the lower profile copies have lower resolution and higher error correction data, such as more FEC symbols in the data stream. In another embodiment, the main profile of the media content can be generated in MPEG-2 format while the lower profiles can be generated in H264 and/or VC1 format).
Re claim 3:
Medina discloses wherein the one or more characteristics associated with each of the one or more versions of the content comprises at least one of: a bitrate for the version of the content; an encoding type for the version of the content; a resolution for the version of the content; a compression ratio for the version of the content; or an encryption type for the version of the content (Para.[0051] In one embodiment, the lower profile copies have lower resolution and higher error correction data, such as more FEC symbols in the data stream. In another embodiment, the main profile of the media content can be generated in MPEG-2 format while the lower profiles can be generated in H264 and/or VC1 format).
Re claim 5:
Medina discloses wherein the selecting a version of content from the one or more version of content comprises: comparing one or more first parameters associated with each one of the plurality of profiles with one or more second parameters; and selecting the version of content based on the one or more first parameters matching the one or more second parameters (Para.[0061] In one embodiment, the presenting of a lower profile version of the media content to a viewer, such as for VoD, can be based on a user profile and/or monitored behavior of the user. For example, a user profile can designate a fault threshold for switching to the lower profile version of the media content and/or can designate a lower limit of resolution before presenting an audio-only signal and Para.[0062] For instance, the server can detect faults above a pre-determined threshold and transmit a lower profile of the media content and then can transmit the main profile once the detected faults are no longer above the threshold).
Re claim 8:
Medina discloses wherein the one or more computing devices comprise one or more gateways (Fig.1 ref. 104 G and Para.[0015] The VHS then distributes multimedia broadcast programs via an access network, such as a local area network (LAN), to commercial and/or residential buildings 102 housing a gateway 104, such as a residential gateway or RG).
Re claim 9:
Medina discloses wherein the one or more computing devices comprise one or more user devices (Fig.2 ref. 202-212).
Re claim 10:
Medina discloses selecting, based on the plurality of profiles, a version of content from the one or more versions of content; generating, based on the version of content, a second multicast stream; and sending, to one or more second computing devices, the second multicast stream (Para.[0061] In one embodiment, the presenting of a lower profile version of the media content to a viewer, such as for VoD, can be based on a user profile and/or monitored behavior of the user. For example, a user profile can designate a fault threshold for switching to the lower profile version of the media content and/or can designate a lower limit of resolution before presenting an audio-only signal and Para.[0057-0058] show various conditions and different version and Para.[0059] In another embodiment, the main and lower profiles of the media content and the capability to switch therebetween to maintain video continuity for the viewer, can be utilized as a secondary signal and can be employed where a primary signal has faulted).
Re claim 11:
Claim 11 is rejected on the same grounds of rejection set forth in claim 1. Medina further discloses one or more processors and memory storing instructions (Fig.8).
Re claim 12:
Claim 12 is rejected on the same grounds of rejection set forth in claims 2 and 3.
Re claim 14:
Claim 14 is rejected on the same grounds of rejection set forth in claim 5.
Re claim 16:
Claim 16 is rejected on the same grounds of rejection set forth in claim 10.
Re claim 17:
Claim 17 is rejected on the same grounds of rejection set forth in claim 1.
Re claim 20:
Claim 20 is rejected on the same grounds of rejection set forth in claim 5.
Claims 4 and 13 rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Medina (US 20100077440) in view of Sloo (US 20090222520), Hasek (US 20090083279) and Cholas (US 20090207866) as applied to claims 1 and 11 above, and further in view of Stern (US 20070282959).
Re claim 4:
As discussed above, Medina in view of Sloo, Hasek, and Cholas teaches the limitations of the parent claim.
Medina does not explicitly disclose wherein each of the plurality of profiles comprises a location associated with each of the one or more versions of the content.
Stern discloses wherein each of the plurality of profiles comprises a location associated with each of the one or more versions of the content (Para.[0087] Where several different re-formatted versions of the content exist, such as where there are several user's subscribed to the content all having different device profiles, the content source list 325 will contain the location information for the appropriately formatted content for each user, based on the user profiles).
Medina and Stern are analogous because they both pertain to content distribution.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Medina to include location of the content as taught by Stern in order to provide rich content to a device (Stern Para.[0003]).
Re claim 13:
Claim 13 is rejected on the same grounds of rejection set forth in claim 4.
Claims 6,7,15,18, and 19 rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Medina (US 20100077440) in view of Sloo (US 20090222520), Hasek (US 20090083279) and Cholas (US 20090207866) as applied to claims 1,11, and 17 above, and further in view of Brueck (US 20110058675).
Re claim 6:
As discussed above, Medina in view of Sloo, Hasek, and Cholas teaches the limitations of the parent claim.
Medina does not explicitly disclose sending, from a content server and based on the selecting, a request for the version of content; and receiving, from the content server, the version of content.
Brueck discloses sending, (Para.[0031] Typically, the CDN is configured in a hierarchy so that a client device requests the data from an edge cache, for example, and if the edge cache does not contain the requested data, the request is sent to a parent cache, and so on up to the origin content server and Para.[0025] Media content stored at the content server 102 may be replicated to other web servers 116; or alternatively, to proxy cache servers 118. Replicating may occur by deliberate forwarding from the content server 102, or by a web, cache, or proxy server outside of the content server 102 asking for content on behalf of the client device 104. For example, the client device 104 may request and receive content from any of the multiple web servers 116, or proxy cache servers 118. In a further embodiment, the media content may be forwarded directly to the web servers 116 or proxy cache 118 servers through direct communication channels 120 without the need to traverse the Internet 106 – where Medina discloses the selecting).
Medina and Brueck are analogous because they both pertain to content distribution.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Medina to include receive content from a content server as taught by Stern in order to control access to copies of media content (Brueck Para.[0001]).
Re claim 7:
As discussed above, Medina in view of Perlman teaches the limitations of the parent claim.
Medina does not explicitly disclose requesting the version of content by sending an HTTP GET to a content server.
Brueck discloses requesting the version of content by sending an HTTP GET to a content server (Para.[0031] One type of request in pull technology is a HTTP request (e.g., HTTP GET request)…In pull-based technology, a CDN may be used to deliver the media to multiple client devices. The CDN is a system of computers networked together across the Internet 106 that cooperates transparently to deliver content, and may include, for example, an origin content server, web servers, cache servers, etc and Para.[0071] For example, one subscription level allows the media player to request only copies of the lower quality levels, while another subscription level allows the media player to request all copies at all quality levels.).
Medina and Brueck are analogous because they both pertain to content distribution.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Medina to include location of the content as taught by Stern in order to control access to copies of media content (Brueck Para.[0001]).
Re claim 15:
Claim 15 is rejected on the same grounds of rejection set forth in claim 6.
Re claim 18:
Claim 18 is rejected on the same grounds of rejection set forth in claim 6.
Re claim 19:
Claim 19 is rejected on the same grounds of rejection set forth in claim 7.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1,11, and 17 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD SAJID ADHAMI whose telephone number is (571)272-8615. The examiner can normally be reached 8:30-5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sujoy Kundu can be reached at (571) 272-8586. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MOHAMMAD S ADHAMI/Primary Examiner, Art Unit 2471