DETAILED ACTION
Status of the Claims
1. Claims 9–14, 16–22, and 24 are pending. Claims 1–8, 15, 23, and 25 have been canceled. No claims have been withdrawn. No claims have been objected to. Claims 9, 13, and 16 have been amended. No claims are allowable. Claims 9–14, 16–22, and 24 are rejected under 35 U.S.C. § 103 as obvious, as set forth below.
Other Prior Art
2. Chen et al. (US 2009/0003600 A1) discloses a client-side container and communication protocol proxy that converts streamed content between a first and a second container and communication protocol before providing the content to a media player ([0046]).
3. Brueck et al. (US 2012/0151080 A1) discloses a client-side translator that progressively converts adaptive-streaming media from one format to another, such as from Apple HTTP Live Streaming to Adobe Flash, in real time at the playback device ([0032]).
Response to Arguments
4. The arguments of Applicant’s representative filed July 8, 2026 have been fully considered.
5. Rejection of Claims 13, 18–22, and 24 under 35 U.S.C. § 101.
6. Applicant’s representative argues that the recitation in claim 13 of “a client web browser that runs on a computing device” uses the active verb “runs” to require the browser to execute on physical hardware, placing claim 13 within a statutory category, and that claims 18–22 and 24 are eligible by virtue of their dependency on claim 13. Examiner agrees. The rejection of claims 13, 18–22, and 24 under 35 U.S.C. § 101 is withdrawn.
7. Rejection of Claims 9, 13, and 16 under 35 U.S.C. § 103 over Chen and Pardue.
8. Independent claims 9, 13, and 16 were amended to recite that converting the data communications maintains, in the converted data communications, at least some of the playback capabilities included in the data communications including digital rights management (DRM) criteria. Applicant’s representative argues that Chen, applied in the previous Office action in view of Pardue, does not teach this limitation because Chen decrypts and stores the container in a secure data store so that it is unavailable for improper usage, rather than maintaining the DRM criteria in the converted data communications. Examiner agrees. Nonetheless, Moorthy in view of Pardue teaches amended claim 9, as discussed in the rejection below.
9. Rejection of Claims 10, 11, 14, 17–21, and 24 under 35 U.S.C. § 103 over Chen and Pardue.
10. Applicant’s representative argues that these claims are allowable as depending from an allowable base claim, for the reasons given as to claims 9, 13, and 16. However, this argument is not persuasive for the reasons provided above with respect to claims 9, 13, and 16.
11. Rejection of Claims 12 and 22 under 35 U.S.C. § 103 over Chen, Pardue, and Brueck.
12. Applicant’s representative argues that these claims are allowable as depending from an allowable base claim, and that Brueck does not provide the feature missing from the base claims, for the reasons given as to claims 9, 13, and 16. However, this argument is not persuasive for the reasons provided above with respect to claims 9, 13, and 16.
Claim Rejections — 35 U.S.C. § 103
13. 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.
14. Claims 9–14, 16–22, and 24 are rejected under 35 U.S.C. § 103 as being unpatentable over Moorthy et al. (US 2014/0281009 A1; “Moorthy”) in view of the non-patent literature entitled “Scalable Media Delivery on the Web with HTTP Server Push” (“Pardue”).
15. Regarding claims 9, 13, 14, and 16, Moorthy teaches a computer-implemented method for streaming media in a client web application of a web browser that supports an operating streaming protocol, wherein the media is received in a native streaming protocol from a remote server, … wherein said method comprises:
16. intercepting … data communications between said remote server and said client web browser for streaming said media in a web page provided by said client web browser. Moorthy teaches a client-side converter placed between the DASH server and the HLS client that may be “included into the application code (e.g., as a software module) of the client device (e.g., at HLS client)” ([0065]; fig. 6); the converter receives and translates the HLS client’s requests to the DASH server and the DASH server’s responses to the client, i.e., it intercepts those data communications for streaming the media ([0071] and [0073]).
17. converting … said data communications into said operating streaming protocol when said data communications are implemented in the native streaming protocol different from said operating streaming protocol of said client web browser. Moorthy teaches that the converter/translator module builds an HLS manifest file from the DASH MPD and converts the media container format from MP4 to TS, delivering the HLS manifest and TS segments to the HLS client ([0071], [0084], and [0089]–[0090]).
18. converting … said data communications … respectively into said native streaming protocol when said data communications are implemented in the operating streaming protocol different from said native streaming protocol, thereby allowing said client web browser to stream said media. Moorthy performs the conversion bidirectionally, DASH to HLS “and vice versa” ([0001] and [0007]), translating the HLS client’s segment and trick-play requests into corresponding requests to the DASH server ([0071] and [0073]).
19. wherein the data communications include playback capabilities. Moorthy teaches that the DASH data communications carry playback capabilities that are handled through the conversion, including trick-play modes (pause, fast forward, rewind) and the digital rights management protection applied to the content ([0073], [0084], and [0089]).
20. converting the data communications maintains, in the converted data communications, at least some of the playback capabilities included in the data communications including digital right management (DRM) criteria. Moorthy teaches that the converter carries these playback capabilities through to the client in the converted stream rather than stripping them from it: the trick play module downloads the appropriate segments from the DASH server and makes the fast-forward and rewind capability available to the HLS client ([0084]), and the content’s DRM protection is preserved in the converted communications delivered to the client, the converter reusing the content’s existing encryption, or where the HLS client’s DRM support requires it re-encrypting and adjusting the DRM signaling, in each case so that the delivered HLS stream remains protected and “the HLS client will be able to play the content back” ([0089]–[0090]).
21. However, Moorthy does not teach wherein said method is implemented within a service worker implemented within said client web application comprised in said client web browser. Nonetheless, Pardue teaches a service worker implemented within a browser web application that runs alongside an in-page MPEG-DASH media player (dash.js) and carries out the streaming work of the client web application, supplying the client web application of a web browser in which the method is implemented (pg. 10, lines 9-11; pg.13, lines 11-12; fig. 7).
22. Pardue further teaches wherein the service worker has a lifecycle separate from the web page. Pardue’s service worker carries out its critical work “in the background of the media player,” is a separate component that the web page loads, and the web application falls back to a non-service-worker (unicast) path if “the Service Worker fails to load” (pg. 13, lines 9-15). A service worker’s separate lifecycle is in any event an inherent, well-known property of service workers (see Non-Final fn. 1; Pardue ref. [7], W3C “Service Worker 1”).
23. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Moorthy so that the method is implemented within a service worker having a lifecycle separate from the web page, as taught by Pardue, because doing so delivers and registers the converter with the web page with no separate installation, approval, or update path, runs it across modern desktop and mobile web browsers, and carries out its work in the background so that it persists across page loads independently of the web page.
24. In addition, the combination of Moorthy and Pardue teaches that the interception of the data communications, the conversion of the data communications into the operating streaming protocol, and, respectively, the conversion into the native streaming protocol are each performed by the service worker. Neither reference alone teaches these operations performed by a service worker: Moorthy’s client-side converter performs the interception and the bidirectional conversion ([0065], [0067], [0071], and [0073]) but is a software module or standalone server rather than a service worker, while Pardue supplies a service worker implemented within the client web application that is itself interposed between the media player and the network, intercepting the media player’s fetch requests, fetching resources from the media origin, rewriting the DASH media presentation description before returning it to the player, and servicing the player’s requests from its cache (pg. 13, lines 20-31; fig. 7), but staying within DASH and not itself converting the protocol or the DRM. In the combination, Moorthy’s converter, which performs the interception and the bidirectional conversion, is implemented within the service worker that Pardue provides and that already intercepts and mediates those same media-player requests, so that the interception and the conversion are carried out by the service worker.
25. 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 system of the combination of Moorthy and Pardue so that the interception and the conversion of the data communications are performed by the service worker, because doing so uses the service worker for the established purpose, shown by Pardue, of intercepting a web page’s fetch requests and returning substituted or rewritten responses to the media player, running the interception and the protocol conversion within the browser’s security sandbox alongside the media player and delivering a compatible stream without a separate client-side component.
26. Regarding claims 10 and 18, the combination of Moorthy and Pardue teaches the computer-implemented method according to claim 9, and Moorthy further teaches intercepting said data communications comprises intercepting a request generated in said operating streaming protocol to stream said media in said client web browser. Moorthy teaches that, when the HLS client requests media segments based on the URLs in the manifest file, the converter translates them into URL requests to the segments stored on the DASH server, i.e., the converter receives the client’s request generated in the operating (HLS) protocol to stream the media ([0071]).
27. Moorthy further teaches converting said data communications comprises converting said request into the native streaming protocol different from said operating streaming protocol of said client web browser. Moorthy teaches that the converter translates the incoming request in the HLS protocol into requests that match the DASH protocol, converting the operating-protocol request into the native DASH protocol ([0073]).
28. Regarding claims 11 and 20, the combination of Moorthy and Pardue teaches the computer-implemented method according to claim 10, and Moorthy further teaches intercepting said data communications comprises generating a response to said request to stream said media from said remote server in said client web browser. Moorthy teaches that the DASH server sends the requested media files to the converter, which in turn sends the corresponding media files to the HLS client, i.e., the converter generates a response to the client’s request to stream the media from the remote server ([0081]).
29. Moorthy further teaches converting said data communications corresponds to converting said response into said operating streaming protocol of said client web browser when said response is implemented in the native streaming protocol different from said operating streaming protocol of said client web browser, thereby allowing said media to be streamed in said client web browser. Moorthy teaches that the converter translates the responses from the DASH server into responses expected by the HLS client, converting the native DASH response into the operating HLS protocol ([0073]).
30. Regarding claims 12 and 22, the combination of Moorthy and Pardue teaches the computer-implemented method according to claim 9, and Moorthy further teaches wherein said operating streaming protocol is a HTTP Live Streaming protocol. Moorthy teaches that the operating protocol supported by the client is HTTP Live Streaming, as currently deployed end devices support the HLS protocol to play back the adaptive bitrate content ([0064]).
31. Regarding claims 17 and 24, the combination of Moorthy and Pardue teaches the computer-implemented method according to claim 9, and Pardue further teaches wherein the service worker further comprises a cache configured to manage a cache of requests and/or responses. Pardue teaches that the service worker maintains a Service Worker Cache in which it stores responses, including retrieved resources and modified media presentation descriptions, and services the media player’s requests from that cache (pg. 10, line 18; pg. 13, lines 30-31; fig. 7).
32. 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 system of the combination of Moorthy and Pardue so that the service worker comprises a cache configured to manage a cache of requests and/or responses, as taught by Pardue, because doing so allows the service worker to satisfy the media player’s requests from the cache and to avoid redundant retrievals from the remote server.
33. Regarding claim 19, the combination of Moorthy and Pardue teaches the service worker according to claim 18, and Moorthy further teaches wherein the service worker is configured to transmit the request converted into the native streaming protocol different from the operating streaming protocol of the client web browser to the remote server. Moorthy teaches that, after translating the HLS request, the converter requests the corresponding media files from the DASH server, i.e., it transmits the request converted into the native (DASH) protocol to the remote server ([0080]).
34. Regarding claim 21, the combination of Moorthy and Pardue teaches the service worker according to claim 20, and Moorthy further teaches wherein the service worker is further configured to transmit to the client web browser converted into the operating streaming protocol of the client web browser when the response is implemented in the native streaming protocol different from the operating streaming protocol of the client web browser. Moorthy teaches that the converter sends the requested media files, converted into the operating (HLS) protocol, to the HLS client ([0081]).
Conclusion
35. Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
36. A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
37. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Andrew Georgandellis whose telephone number is 571-270-3991. The examiner can normally be reached on Monday through Friday, 7:30-5:00 PM EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Tonia Dollinger, can be reached on 571-272-4170. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
38. 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.
/ANDREW C GEORGANDELLIS/Primary Examiner, Art Unit 2459
Prosecution Insights