DETAILED ACTION
Introduction
Claims 9-14, 16-22, and 24-25 are pending. Claims 1-8, 15, and 23 are cancelled. Claims 9, 13, and 16 are amended. Claim 25 is new. This Office action is in response to Applicant’s request for continued examination (RCE) filed on 12/26/2025.
Relevant Prior Art
Brueck (cited with regard to claim 12 below) also appears to anticipate claims 9-11 and 13-16. However, Examiner does not include an additional rejection based on Brueck, as such a rejection would be merely cumulative. See MPEP 2120. Moreover, it is likely that any deficiencies in the teachings of Brueck could be cured by combining the teachings of Brueck with the teachings of Chen.
Response to Arguments
Examiner considers the arguments of Applicant’s representative below.
Rejection of claims 9, 13, and 16 under 35 U.S.C. 103
Applicant’s representative has amended claims 9, 13, and 16 to recite new limitations and now argues that the combination of Chen and Streaming Service Worker Prior Art does not teach the system of claims 9, 13, and 16, as amended. However, Examiner no longer relies on any of the Service Worker Prior Art references to reject claims 9, 13, or 16. Therefore, this argument is moot.
Applicant’s representative further argues that implementing a service worker in a web page is “contrary to having a separate lifecycle for the service worker….” However, Examiner respectfully disagrees. Claims 9, 13, and 16 recite that the service worker is “implemented within said client web application….” Applicant’s specification clearly indicates that the term “client web application” refers to a web page. For instance, the specification states that the client web application may be a multi-page web application such as an entire website, or a single-page application. See par. 14. Moreover, the specification indicates that “the service worker is comprised in the client web browser” such that “the service worker may be directly implemented within a web page of the client web browser.” See par. 37-38. Thus, claims 9, 13, and 16 recite a service worker that is both implemented in a web page and has a lifecycle that is separate from the web page, thereby demonstrating that implementing a service worker in a web page is not contrary to having a separate lifecycle for the service worker.
Applicant’s representative also argues that modifying Chen to utilize a media player that is integrated into a web page instead of a media player that is integrated directly into the browser (i.e., as a browser plug-in. See Chen, pg. 3) would require “restructuring Chen’s configuration beyond a simple replacement or addition of a component.” Examiner agrees that modifying Chen to use a media player integrated into a web page instead of a plug-in media player would require making some alterations to the system of Chen. However, the fact that Applicant’s representative perceives such changes to be complicated or difficult is merely an opinion and of no legal relevance.
Additionally, Applicant’s representative argues that the previous Office action does not articulate a reason why one of ordinary skill in the art would be motivated to modify the system of Chen to use a media player integrated into a web page instead of a plug-in media player. Examiner agrees that the previous Office action did not provide such a motivation. Nonetheless, the benefits of using a media player integrated into a web page over a plug-in media player are numerous. For instance:
A plug-in media player needs to be downloaded, installed, enabled, updated and updated by a user, whereas a media player integrated into a web page does not.
Web-integrated players work across most modern browsers and platforms (desktop, mobile, many embedded environments), whereas plug-ins are often unsupported on mobile and increasingly restricted on desktop.
Plug-ins historically introduced significant security vulnerabilities and required frequent patching. Web-native playback leverages the browser’s sandboxing and security model.
Eliminating plug-in processes/components can reduce memory and CPU usage and avoid “two stacks” (browser + plug-in runtime).
Lastly, Applicant’s representative argues that “the Office’s assertion that ‘a service worker [can be used] as a proxy for a web application’ contradicts the very position of the Office that it would be obvious to replace the media player of Chen with a web application. However, Examiner does not understand what Applicant’s representative is trying to say here. The issue of whether it is obvious to implement Chen’s media player as a client web application instead of a plug-in is distinct from the issue of whether it is obvious to implement Chen’s client-side proxy (i.e., the CCPP) as a service worker instead of a browser plug-in. Moreover, the newly cited Pardue reference teaches a service worker that functions as a proxy for a media player integrated into a web page, as discussed in the rejection below. Therefore, there is nothing contradictory about a service worker functioning as a proxy for a media player integrated into a web page. Nevertheless, Examiner is adjusting the Office action to clarify that Examiner is proposing two distinct modifications to the system of Chen:
First, Examiner proposes modifying the system of Chen so that the plug-in media player is replaced with a media player integrated into a web page, which is beneficial for the reasons discussed above.
Second, Examiner is proposing to modify the system of Chen so that the client-side proxy (i.e., the CCPP) is implemented using a service worker instead of a browser plug-in, which is beneficial for the reasons set forth in the rejection below.
Claim Rejections: 35 U.S.C. 101
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.
Claims 13, 18-22, and 24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 13 is directed to “a service worker implemented within a web application of a client web browser that runs on a computing device….” However, it is not clear whether the phrase “runs on” means that the web browser is actually running on the computing device or if it is merely configured to run on the computing device. While the former is statutory subject matter, the latter constitutes software per se and is therefore non-statutory subject matter.
Claims 18-22 and 24 are non-statutory subject matter for the above reasons and by virtue of their dependency on claim 13.
Claim Rejections: 35 U.S.C. 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, 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.
Claims 9-11, 13-14, 16-21, and 24 are rejected under 35 U.S.C. 103 because they are unpatentable over Chen (US 2009/0003600) in view of the non-patent literature entitled “Scalable Media Delivery on the Web with HTTP Server Push” (hereinafter, “Pardue”).
Regarding claims 9, 13, 14, and 16, Chen teaches a computer-implemented method for streaming media in a web browser that supports an operating streaming protocol, wherein the media is received in a native streaming protocol from a remote server (Chen discloses a system for streaming a media container in a media player of a browser that supports a first streaming protocol. See par. 66), wherein said method is implemented within client-side proxy (The method of Chen is implemented in a container and communication protocol proxy (CCPP). See par. 19), wherein said method comprises the following steps: intercepting, by the client-side proxy, 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 (The CCPP intercepts communications between the browser and a content server that are related to streaming a media container from the content server to the browser. See par. 66. The media container may be streamed by the browser when the user selects a link to the media container in a web page. See par. 25); and converting, by the client-side proxy, 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, and 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 (The CCPP converts communications (i.e., communications originating from the browser) from a second streaming protocol to a first streaming protocol, and converts inbound communications (i.e., communications originating from the content server) from the first streaming protocol to the second streaming protocol, thereby allowing the browser to stream the container from the content server even when the browser and the content server do not use the same streaming protocol. See par. 68-70), wherein converting the data communications maintains at least some of playback capabilities included in the data communications (The CCPP maintains digital rights management (DRM) playback by decrypting encrypted communications received from the content server and stores the decrypted communications in a secure data store, thereby making them unavailable for improper usage. See par. 75; see also par. 5).
However, Chen does not teach that the media is streamed by a media player that is integrated into a client web application of the browser. Instead, Chen teaches that the media container is streamed by a media player that is a plug-in of the browser. See par. 43. Nonetheless, Pardue teaches a system for streaming media whereby the media is streamed by an MPEG-DASH media player running in a web page. See pg. 10.
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 Chen so that the media player is integrated into a web page instead of being integrated into the browser as a plug-in, because doing so is beneficial for numerous reasons:
A plug-in media player needs to be downloaded, installed, enabled, updated and updated by a user, whereas a media player integrated into a web page does not.
Web-integrated players work across most modern browsers and platforms (desktop, mobile, many embedded environments), whereas plug-ins are often unsupported on mobile and increasingly restricted on desktop.
Plug-ins historically introduced significant security vulnerabilities and required frequent patching. Web-native playback leverages the browser’s sandboxing and security model.
Eliminating plug-in processes/components can reduce memory and CPU usage and avoid “two stacks” (browser + plug-in runtime).
In addition, Chen does not teach that the client-side proxy is a service worker implemented within the client web application, wherein the service worker has a lifecycle separate from the web page. Instead, Chen teaches that the client-side proxy (i.e., the CCPP) is implemented by a browser plug-in. See par. 48. Nonetheless, Pardue teaches a service worker that functions as a client-side proxy by intercepting streaming segment requests from an MPEG-DASH player running in a web page and provides the requested segments to the web page from a cache or origin server. See pg. 12; fig. 7.1
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 Chen so that the client-side proxy is implemented as a service worker instead of a browser plug-in, because doing so is beneficial for numerous reasons:
A service worker is delivered as part of a web page and registered by the web page, whereas a plug-in typically requires user installation, admin approval, and ongoing updates.
Service workers are part of the modern web platform and supported widely on current browsers, whereas plug-ins are largely disabled in modern browsers and often unsupported on mobile devices.
A service worker runs in a restricted execution environment governed by the browser’s security model, where as plug-ins have historically operated with broader privileges and introduced significant vulnerabilities.
A service worker is scoped to an origin (and usually to a path), which constraints where it can intercept traffic, whereas plug-ins can be global and therefore riskier.
Service workers do not require a separate plug-in process or legacy runtime layer.
Regarding claims 10 and 18, Chen and Pardue teach the computer-implemented method according to claim 9, wherein: intercepting said data communications comprises intercepting a request generated in said operating streaming protocol to stream said media in said client web browser (Chen teaches that the proxy may intercept a request for the container. See par. 66); and converting said data communications comprises converting said request into the native streaming protocol different from said operating streaming protocol of said client web browser (The proxy may convert the request from the second streaming protocol to the first streaming protocol. See par. 68).
Regarding claims 11 and 20, Chen and Pardue teach the computer-implemented method according to claim 10, wherein: intercepting said data communications comprises generating a response to said request to stream said media from said remote server in said client web browser; and 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 (Chen teaches that the proxy may convert the response from the content server from the first streaming protocol back to the second streaming protocol. See par. 70, 76).
Regarding claims 17 and 24, Chen and Pardue do not teach the computer-implemented method according to claim 9, wherein the service worker further comprise a cache configured to manage a cache of requests and/or responses (Pardue teaches that the service worker maintains a cache for caching streaming segments. See pg. 12; fig. 7. Thus, Pardue suggests further modifying the system of Chen and Pardue so that the service worker maintains a cache configured to cache streaming segments, because doing so reduces the latency perceived by the user when streaming content).
Regarding claim 19, Chen and Pardue teach the service worker according to claim 18, 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 (Chen teaches that the proxy may intercept a request for the container. See par. 66. The proxy may convert the request from the second streaming protocol to the first streaming protocol. See par. 68. The converted request is then forwarded to the content server. See par. 69; fig. 4, step 410).
Regarding claim 21, Chen and Pardue teach the service worker according to claim 20, wherein the service worker is further configured to transmit to the client web browser the response 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 (Chen teaches that the proxy may convert the response from the content server from the first streaming protocol back to the second streaming protocol. See par. 70, 76. The proxy transmits the converted response back to the browser-integrated media player. See par. 75; fig. 4, step 416).
Regarding claim 25, Chen and Pardue teach the computer-implemented method according to claim 9, wherein the certain playback capabilities include digital right management criteria included in the data communications (Chen teaches that the CCPP maintains digital rights management (DRM) playback by decrypting encrypted communications received from the content server and stores the decrypted communications in a secure data store, thereby making them unavailable for improper usage. See par. 75; see also par. 5).
Claims 12 and 22 are rejected under 35 U.S.C. 103 because they are unpatentable over Chen and Pardue, as applied to claims 9 and 13 above, in further view of Brueck (US 2012/0151080).
Regarding claims 12 and 22, Chen and Pardue do not teach the computer-implemented method according to claim 9, wherein said operating streaming protocol is a HTTP Live Streaming protocol (Chen teaches that the second streaming protocol may be selected from a list of streaming protocols including Real Time Messaging Protocol (RTMP), RTMPE, User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), Transmission Control Protocol (TCP)/Internet Protocol (TCP/IP, File Transfer Protocol (FTP), Secure Copy Protocol (SCP), Real-time Transport Protocol (or RTP) and Real Time Streaming Protocol (RTSP). See par. 15. Although Chen states that the list is non-exhaustive, the list nonetheless fails to include HTTP Live Streaming). Nonetheless, the HTTP Live Streaming protocol was well known to one of ordinary skill in the before the effective filing date of the claimed invention. See Brueck, par. 3, 43.
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 Chen and Pardue so that the second streaming protocol is the HTTP Live Streaming protocol because doing so allows the system to proxy additional streaming protocols that are not expressly listed by Chen.
Conclusion
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.
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
1 A service worker inherently has a lifecycle that is separate from that of a web page. For instance, once a service worker is started by a web page thread, it does not get killed even when that thread dies or when the browser is closed. See “Service Workers! Your first step towards Progressive Web Apps (PWA),” pg. 2. Moreover, unlike web workers, a service worker is not tied to a single web page thread, but can instead by shared by multiple web page threads (i.e., multiple web pages each running in a different browser tab). Id.