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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
DETAILED ACTION
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 11 June 2026 has been entered.
This communication is in response to Application No. 18/717,864 filed on 07 June 2024 and the Request for continued examination (RCE) presented on 11 June 2026, which amends claims 1 and 6 and presents arguments, is hereby acknowledged. Claims 1-10 are currently pending and subject to examination.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 03/19/2026 and 04/12/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Response to Arguments
5. On pages 2-6 of the response filed 11 June 2026, Applicant’s addresses the Double Patenting Rejections and 35 U.S.C. § 03 rejection made on the 19 December 2025 Final Rejection. Applicant’s arguments, regarding the Double Patenting Rejections and rejection under 35 U.S.C. § 103, have been fully considered.
Double patenting rejection should be withdrawn:
Applicants argue at pages 2-3 of the response filed 11 June 2026 that The claims (including specifically identified claims 1 and 4-5 of co-pending U.S. Application No. 18/553,110 do not teach or suggest the following limitations of independent claim 1 of the present application: "ii) deciding to join a multicast channel; then iii) requesting and receiving further segments from the unicast content source and an alternative unicast content source...." Claim 1 thus requires requesting and receiving further segments from two sources. Namely, claim 1 requires requesting and receiving further segments from (a) the unicast content source and (b) the alternative unicast content source. This recited step of requesting and receiving further segments from (a) the unicast content source and (b) the alternative unicast content source is performed after deciding to join a multicast channel. These features of claim 1 are not disclosed or suggested by the claims (including specifically identified claims 1 and 4-5) of co-pending U.S. Application No. 18/553,110. Claim 1. Applicant therefore requests that the double patenting rejection be withdrawn. As co-pending U.S. Application No. 18/553,110 issued US Patent No. 12,603,930 B2. Examiner agree with the Applicant that the DP rejections need to be reconsidered. As Applicant's amended claimed subject matter of issued US Patent No. 12,603,930 B2 (U.S. Application No. 18/553,110 ). Thus, Applicant respectfully requests that this rejection be withdrawn have been fully considered and are persuasive. Therefore, the rejection has been withdrawn.
II. Claims are patentable under 35 U.S.C. § 102 and 103:
On pages 4-6 of the response filed 18 May 2026, Applicant’s addresses the 35 U.S.C. 102103 rejection made on the 19 December 2025 Final Rejection.
Applicants argue at pages 4-5 of the remarks, as filed, that Mantin fails to disclose the following the specific sequence recited by independent claim 1 and its dependents:
“ii) deciding to join a multicast channel; then iii) requesting and receiving further segments by unicast from the unicast content source and by unicast from an alternative unicast content source that is distinct from the unicast content source, and storing the further segments until requested by the client device; and iv) joining a multicast channel and receiving segments over multicast, and storing the segments until requested by the client device”.
Applicants arguments are based on premises that Independent claim 1 requires a period where:
" multicast is available but not yet joined; and " the proxy is actively requesting and storing further unicast segments from two unicast sources ("the unicast content source and an alternative unicast
content source" in claim 1) before multicast reception begins. Mantin does not disclose a phase in which the network element has decided to transition to multicast while intentionally refraining from joining the multicast channel, and during that phase actively requesting and storing further content segments from both a unicast content source and an alternative unicast content source for later client request, as required by claim 1.
Examiner respectfully disagrees and finds this argument unpersuasive. The courts have explicitly stated that the prior art need not be solving the same problem as the applicant. SeeKSR Int'l Co. v. Teleflex, Inc., 550 U.S. 398 (2007). For example, one may arrive at identical claimed invention by solving a completely different problem. See in re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed.Cir. 1986).
Specifically, the examiner cited prior art “Mantin” teaches the above argued limitation “ii) deciding to join a multicast channel; then iii) ) requesting and receiving further segments by unicast from the unicast content source and by unicast from an alternative unicast content source that is distinct from the unicast content source, and storing the further segments until requested by the client device; iv) joining a multicast channel…” as recited by Independent claim 1.
Mantin teaches “ii) deciding to join a multicast channel” as recited by independent claim 1.
Mantin describes a multicast delivery system (MDS) 150 (e.g. network element) includes a controller 250 is configured to determine, based on the inputs received from the stream classifier 210 and the network topology analyzer 230, whether there is a unicast OTT stream which is currently being delivered in a unicast format that can be transmitted in a multicast format (Mantin: [paragraph 0042]). Mantin further describes the multicast delivery system (MDS) 150 (e.g. network element) includes stream handler 503 is configured to select the proper source (i.e., unicast or multicast) from the stream to the media player 510 that should be delivered. The multicast delivery system (MDS) 150 (e.g. network element) includes the streaming proxy 500 is further configured to switchover from a selected source to another source such as, e.g., from a unicast to multicast streaming source, or vice-versa (e.g. deciding to join a multicast channel). The switchover decision may be taken based on various parameters (Mantin: [paragraph 0055, 0057]). Thus, Mantin still teaches “ii) deciding to join a multicast channel” as recited by independent claim 1.
Mantin further teaches iii) ) requesting and receiving further segments by unicast from the unicast content source and by unicast from an alternative unicast content source that is distinct from the unicast content source, and storing the further segments until requested by the client device; ” as recited by Independent claim 1.
Mantin describes unicast stream sources (e.g. unicast content source and an alternate content source) (Mantin: [paragraph 0005, 0028]).Mantin further describes Thus, the proxy 500 is configured to adapt a received multicast stream to a unicast format. The streaming proxy 500 includes a unicast client 501, a multicast client 502, a stream handler 503, and unicast OTT content servers 504. The unicast and multicast clients 501 and 502, respectively, implement unicast and multicast protocols. The stream handler 503 is configured to select the proper sources (i.e., unicast sources or multicast sources) from the stream to the media player 510 that should be delivered. The multicast delivery system (MDS) (e.g. network element) or unicast server receives a stream's content in a unicast format from the handler 503 which is configured to select the proper sources (i.e., unicast stream sources e.g. unicast content source and an alternate content source) and streams the content to the media player 510. the streaming proxy 500 is further configured to switchover from a selected source to another source such as, e.g., from a unicast to multicast streaming source, or vice-versa. The switchover decision may be taken based on various parameters. In one embodiment, the switchover may be required if, for example, the number of users attempting to access the OTT content increases such that switching from several unicast streams to one multicast stream would decrease bandwidth and improve user experience. In such cases, the streaming proxy may be configured to temporarily retrieve both the multicast and unicast streams, thereby enabling the stream to continue uninterrupted as the UED 110 transitions from providing a unicast stream to providing a multicast stream (Mantin: [paragraph 0053-0057]). Thus, Mantin still teaches iii) requesting and receiving further segments from the unicast content source and an alternate content source, and storing the further segments until requested by the client device; ” as recited by Independent claim 1.
Mantin further teaches (iv) joining a multicast channel…” as recited by Independent claim 1.
Mantin describes the stream handler 503 is configured to select the proper source (i.e., unicast or multicast) from the stream to the media player 510 that should be delivered. The unicast server 504 receives a stream's content in a unicast format from the handler 503 and streams the content to the media player 510 , the streaming proxy 500 is further configured to switchover from a selected source to another source such as, e.g., from a unicast to multicast streaming source (e.g. joining multicast source), or vice-versa. The switchover decision may be taken based on various parameters. In one embodiment, the switchover may be required if, for example, the number of users attempting to access the OTT content increases such that switching from several unicast streams to one multicast stream would decrease bandwidth and improve user experience. In such cases, the streaming proxy may be configured to temporarily retrieve both the multicast and unicast streams, thereby enabling the stream to continue uninterrupted as the UED 110 transitions from providing a unicast stream to providing a multicast stream (Mantin: [paragraph 0053-0057]). Thus, Mantin still teaches (iv) joining a multicast channel…” as recited by Independent claim 1.
Therefore, the examiner cited prior art “Mantin” still teaches the above argued limitation “ii) deciding to join a multicast channel; then iii) ) requesting and receiving further segments by unicast from the unicast content source and by unicast from an alternative unicast content source that is distinct from the unicast content source, and storing the further segments until requested by the client device; iv) joining a multicast channel…” as recited by Independent claim 1.Therefore, Applicant’s arguments are unpersuasive. Therefore, the rejection of claim 1 is hereby maintained.
Applicants argue claim 6 based on the arguments presented for Claim 1 at page 6 of the remarks. The same explanation is applicable to claim 6 as mentioned above with respect to claim 1.
However, upon further consideration, a new ground(s) of rejection is made for claimed subject matter “ii) deciding to join a multicast channel; then iii) requesting and receiving further segments by unicast from the unicast content source and by unicast from an alternative unicast content source that is distinct from the unicast content source, and storing the further segments until requested by the client device; and iv) joining a multicast channel and receiving segments over multicast, and storing the segments until requested by the client device” as discussed below.
Dependent claims 2-5 and 7-10
Applicant argues these claims conditionally based upon arguments presented for their parent claim(s). Applicant’s arguments are persuasive. However, a new ground of rejections may appear below. See the detailed explanation and rejection below.
Claim Rejections - 35 USC § 103
6. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
7. The factual inquiries 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.
8. Claims 1-4 and 6-9 are rejected under 35 U.S.C. 103 as being unpatentable over Mantin (US 2015/0036526); in view of KARTHIKEYAN et al. (US 2016/0080446 A1).
Regarding Claim 1, Mantin teaches a method of managing content delivery to a client device by a network element, said content comprising a sequence of segments ([paragraph 0003-0004, 0010, 0025] describes managing content delivery to a client device such as a media player by a network system (e.g. network element) and content stream represent segments of the content), said method comprising:
receiving requests for segments from a client device, and transmitting the requested segments to the client device by unicast ([paragraph 0057, 0060-0062] describes receiving requests for content stream represent segments of the content from the client device such as the media player and transmitting the requested the content stream represent the segments of the content the client device such as the media player by unicast and the streaming proxy is further configured to switchover from a selected source to another source such as, e.g., from a unicast to multicast streaming source, or vice-versa),
wherein the transmitted segments are obtained by the network element by: i) requesting one or more of the requested segments from a unicast content source ([paragraph 0041, 0057-0058] describes the transmitted segments are obtained by the network system (e.g. network element) requesting the content stream represent the segments of the content from a unicast content source and the network system (e.g. network element) supports unicast OTT content stream);
Mantin doesn’t explicitly disclose to teach ii) deciding to join a multicast channel; then iii) requesting and receiving further segments by unicast from the unicast content source and by unicast from an alternative unicast content source that is distinct from the unicast content source, and storing the further segments until requested by the client device; and iv) joining a multicast channel and receiving segments over multicast, and storing the segments until requested by the client device.
However, in a similar field of endeavor, KARTHIKEYAN discloses ii) deciding to join a multicast channel([paragraph 0043-0044, 0050] describes Host: an end user device that requests some content from a source that can be delivered by unicast or multicast. Plurality of content servers or Sources: providers of some content that either sends to hosts via unicast or pushes it into the network via multicast [paragraph 0054-0056] describes Host: an end user device receives the advertisement and wishes to receive the multicast data and Host: an end user device sends to its H-DR 824 an IGMP Join request specifying the multicast address of the multicast stream that it wishes to join, as detailed in the advertisement message, together with its membership information);
iii) requesting and receiving further segments by unicast from the unicast content source and by unicast from an alternative unicast content source that is distinct from the unicast content source, and storing the further segments until requested by the client device ([paragraph 0077-0078, 0113-0118, 0128 ] describes piece of media content which is available on two content servers A and B (e.g. two distinct content source) and requesting and receiving further pieces of media contents (e.g. segments) by unicast from the unicast content source server A and a request that arrives at server A triggers a message to server B from A and by unicast from an alternative unicast content source server B that is distinct from the unicast content source server A and storing further pieces of media contents (e.g. segments) until requested by the Host: an end user device);
iv) joining a multicast channel and receiving segments over multicast, and storing the segments until requested by the client device [paragraph 0014, 0077-0078, 0100-0104] describes transitioning the plurality of unicast data streams to the multicast data stream may comprise: generating a group address system; creating session description information for the content to be switched to multicast and joining a host to the multicast channel providing multicast data stream data stream and storing further pieces of media contents (e.g. segments) until requested by the Host: an end user device).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the teachings of Mantin to include ii) deciding to join a multicast channel; then iii) requesting and receiving further segments by unicast from the unicast content source and by unicast from an alternative unicast content source that is distinct from the unicast content source, and storing the further segments until requested by the client device; and iv) joining a multicast channel and receiving segments over multicast, and storing the segments until requested by the client device as taught by KARTHIKEYAN. One ordinary skill in the art would be motivated to utilize the teachings of Mantin in the KARTHIKEYAN system in order to provide digital media, such as audio and/or video, can be streamed from a source to a host (end user) over a data communications network in either unicast or multicast transmission modes ([paragraph 0002] in KARTHIKEYAN).
Regarding Claim 2, the combination of Mantin and KARTHIKEYAN teaches a method, wherein the further content segments from the unicast content source are requested in response to corresponding requests received from the client device (Mantin: [paragraph 0057, 0060-0062] describes receiving requests for content stream represent segments of the content from the client device such as the media player [Mantin: paragraph 0041, 0057-0058] describes the transmitted segments are obtained by the network system (e.g. network element) requesting the content stream represent the segments of the content from a unicast content source and the network system (e.g. network element) supports unicast OTT content stream).
Regarding Claim 3, the combination of Mantin and KARTHIKEYAN teaches a method, wherein the further content segments from the alternative unicast content source are requested in advance of corresponding requests from the client device (Mantin: [paragraph 0041, 0057-0058] describes the switching from one source to the other is performed without stopping, delaying, or impacting the reception of a stream played by the media player. That is, from the viewer's perspective, the transition to a different OTT streaming source is seamless and would not impact the QoE provided to a viewer of the media player).
Regarding Claim 4, the combination of Mantin and KARTHIKEYAN teaches a method, wherein at any given time, there is segment data available by multicast and from the alternative unicast source that isn't yet available from the unicast content source (Mantin: [paragraph 0025, 0029-0030, 0041] describes segment data is available by multicast is a live, linear, or replicated OTT, or any other multicast-able streams when unicast stream is still not available from other source).
Regarding claims 6-9, these claims contain limitations found within that of claims 1-4 and the same rationale to rejections are used.
9. Claims 5 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Mantin (US 2015/0036526); in view of KARTHIKEYAN et al. (US 2016/0080446 A1); and further in view of CRABTREE et al. (US 2017/0118263 A1).
Regarding claim 5, Mantin and KARTHIKEYAN fails to teach a method, wherein the alternative unicast content source is a retransmission server.
However, CRABTREE teaches a method, wherein the alternative unicast content source is a retransmission server ([paragraph 0042-0043, 0052] describes other unicast source is a retransmission server).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the teachings of Mantin/ KARTHIKEYAN to include wherein the alternative unicast content source is a retransmission server as taught by CRABTREE. One ordinary skill in the art would be motivated to utilize the teachings of Mantin/ KARTHIKEYAN in the CRABTREE system in order to use a retransmission server to retransmit lost packets ([paragraph 0052] in CRABTREE).
Regarding claim 10, this claim contains limitations found within that of claim 5 and the same rationale to rejection is used.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
- Kazerani et al., US 2017/0366590 A1, Techniques for Some embodiments provide a multi-tenant over-the-top multicast solution that integrates the per user stream customizability of unicast with the large scale streaming efficiencies of multicast.
- Huang et al., US 2010/0153573 A1, Method and apparatus to provide media content are presented.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEHULKUMAR J SHAH whose telephone number is (571)272-1072. The examiner can normally be reached Mon-Fri, 6:05 am-3:55 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, TONIA DOLLINGER can be reached at 571-272-4170. 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.
/M.J.S/Examiner, Art Unit 2459
Prosecution Insights