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 .
DETAILED ACTION
2. This action is in response to the amendment filed January 4, 2026.
3. Claims 1-31 have been examined and are pending with this action.
4. The Information Disclosure Statement filed October 29, 2025 have been considered.
Response to Arguments
5. Applicant’s arguments with respect to claims 1-18, and 22-31, previously rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Binder (US 2012/0166582 A1), 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.
In the arguments, the applicant’s seem to overlook well-established general knowledge in computer networking technologies and instead assumes the claims of the application must be mapped to the cited reference in an almost work-for-word manner. Claim interpretation and prior art analysis do not require such verbatim correspondence. During patent examination, the pending claims must be given their broadest reasonable interpretation consistent with the specification. See In re Hyatt, 211 F.3d 1367, 1372, 54 USPQ2d 1664, 1667 (Fed. Cir. 2000). Furthermore, while the claims of issued patents are interpreted in light of the specification, prosecution history, prior art and other claims, this is not the mode of claim interpretation to be applied during examination. During examination, the claims must be interpreted as broadly as their terms reasonably allow. See In re American Academy of Science Tech Center, F.3d 2004 WL 1067528 (Fed. Cir. May 13, 2004).
Even still, although the examiner does not acquiesce the assertions and arguments present by the applicant’s as Binder’s clearly and explicitly teaches or in the very least suggest the steps recited in independent claim 1, in the interest of compact prosecution, Denoual et al. (US 9,350,796 B2) has been cited to better map to the steps of the pending claims and aligns more closely to the same field of endeavor. For these reason and the rejections set forth below, claims 1-31 remain rejected and pending. This action is Non-Final.
Claim Rejections - 35 USC § 102
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
6. Claims 1-14, 18, and 22-31 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Denoual et al. (US 9,350,796 B2).
As per claim 1, Denoual teaches a method for use with a content that comprises a media data, and that comprises at least a first part that is stored in a first device and that is identified by a first content identifier, a second part that is stored in a second device and that is identified by a second content identifier, and a third part that is stored in a third device and that is identified by a third content identifier (see Denoual, FIG. 1A; and col.1, lines 26-30: “a multimedia mash up may be built from distributed pieces of multimedia, such as videos, located at different data sources such as Internet servers (e.g. video sharing site, personal Web site, Cloud services, company service, . . . ), by concatenation of different temporal video segments from the different data sources.”), the method comprising:
identifying, by a requesting device, the first, second, and third content parts (see Denoual, col.1, lines 31-39: “The various multimedia segments may be downloaded using an addressing scheme identifying the location of the data source. In 2008, W3C initiated a standardization process for specifying an addressing scheme based on a traditional uniform resource identifier (URI) mechanism. URI is an addressing scheme used to identify resources on the Internet and also provides features for addressing sub parts of a multimedia resource using what is often referred to as a “fragment identifier”.”);
identifying, by the requesting device, the first, second, and third devices by identifying their respective Internet Protocol (IP) addresses (see Denoual, col.1, lines 31-39: “The various multimedia segments may be downloaded using an addressing scheme identifying the location of the data source. In 2008, W3C initiated a standardization process for specifying an addressing scheme based on a traditional uniform resource identifier (URI) mechanism. URI is an addressing scheme used to identify resources on the Internet and also provides features for addressing sub parts of a multimedia resource using what is often referred to as a “fragment identifier”.”);
sending, by the requesting device to the first device over the Internet, using the identified IP address of the first device, a first request for the first part that comprises the first content identifier (see Denoual, Abstract: “Receiving and executing a first multimedia segment, requesting the data source of a subsequent multimedia data segment to transmit a portion of the subsequent multimedia data segment”; col.2, lines 39-43: “In an embodiment the transmission capability between the respective data source and the communication device is determined by requesting the data source to transmit a portion of the multimedia data segment during execution of the first multimedia segment.”; and col.7, line 60-col.8, line 4: “Next a request to receive the initial seconds, for example the initial 2 seconds of each active media segment is submitted to the different servers storing the media fragments of the video mash-up and the corresponding HTTP connections are left open. This is done using the Media Fragment URI stored in the media segments description list 1003 with “end_time” parameter (http://theServer/thevideo#t=start_time, end_time) of the temporal Media Fragments being modified (it may be noted that when the client already has a description of the different media resources, it can compute time ranges to byte ranges equivalences and then submit byte-ranges HTTP requests)”);
receiving, by the requesting device from the first device over the Internet, in response to the sending of the first request, the first part (see Denoual, Abstract: “Receiving and executing a first multimedia segment, requesting the data source of a subsequent multimedia data segment to transmit a portion of the subsequent multimedia data segment”; and col.2, lines 8-11: “receiving a first multimedia segment of the sequence of multimedia segments from the respective data source and executing said first multimedia segment on the communication device”);
sending, by the requesting device to the second device over the Internet, using the identified IP address of the second device, a second request for the second part that comprises the second content identifier (see Denoual, Abstract: “Receiving and executing a first multimedia segment, requesting the data source of a subsequent multimedia data segment to transmit a portion of the subsequent multimedia data segment”; and col.7, lines 39-48: “These video segments are then classified into 3 sets of requests: R0, R1, and R2 in step 302. R0 corresponds to a request for the current media segment being displayed, R1 corresponds to a request for the next media segment to display; and R3 corresponds to a request for subsequent media segments. R0 and R1 may each correspond to a request to download one media segment while R2 can be empty, contain a request for one media segment or several requests to download several media segments.”);
receiving, by the requesting device from the second device over the Internet, in response to the sending of the second request, the second part (see Denoual, Abstract: “Receiving and executing a first multimedia segment, requesting the data source of a subsequent multimedia data segment to transmit a portion of the subsequent multimedia data segment”; and col.3, lines 30-36: “A further aspect of the invention relates to a communication device, for receiving a multimedia data stream composed of a sequence of multimedia data segments from a plurality of data sources… ”);
sending, by the requesting device to the third device over the Internet, using the identified IP address of the third device, a third request for the third part that comprises the third content identifier (see Denoual, Abstract: “Receiving and executing a first multimedia segment, requesting the data source of a subsequent multimedia data segment to transmit a portion of the subsequent multimedia data segment”; and col.7, lines 39-48: “These video segments are then classified into 3 sets of requests: R0, R1, and R2 in step 302. R0 corresponds to a request for the current media segment being displayed, R1 corresponds to a request for the next media segment to display; and R3 corresponds to a request for subsequent media segments. R0 and R1 may each correspond to a request to download one media segment while R2 can be empty, contain a request for one media segment or several requests to download several media segments.”);
receiving, by the requesting device from the third device over the Internet, in response to the sending of the third request, the third part (see Denoual, Abstract: “Receiving and executing a first multimedia segment, requesting the data source of a subsequent multimedia data segment to transmit a portion of the subsequent multimedia data segment”; and col.3, lines 30-36: “A further aspect of the invention relates to a communication device, for receiving a multimedia data stream composed of a sequence of multimedia data segments from a plurality of data sources… ”); and
combining, by the requesting device, the received first, second, and third content parts to form at least part of the content (see Denoual, col.1, lines 26-30: “For example, a multimedia mash up may be built from distributed pieces of multimedia, such as videos, located at different data sources such as Internet servers (e.g. video sharing site, personal Web site, Cloud services, company service, . . . ), by concatenation of different temporal video segments from the different data sources.”; and col.5, lines 33-39: “In this example a user has built a video mash up 130 that may be shared with other users. The video mash up 130 is an aggregated video composed of different video segments described as a list of Media Fragments URIs 132 including, in some cases, surrounding mark-up information. The video segments composing the mash up 130 are provided by the distributed data sources 101, 102, 103.”; and col., lines: “For example, a multimedia mash up may be built from distributed pieces of multimedia, such as videos, located at different data sources such as Internet servers (e.g. video sharing site, personal Web site, Cloud services, company service, . . . ), by concatenation of different temporal video segments from the different data sources.”),
wherein the sending of the second request is performed at least in part during the receiving of the first content part, and wherein the sending of the third request is performed at least in part during the receiving of the second content part (see Denoual, Abstract: “Receiving and executing a first multimedia segment, requesting the data source of a subsequent multimedia data segment to transmit a portion of the subsequent multimedia data segment”; col.7, line 67-col.8, line 4: “it may be noted that when the client already has a description of the different media resources, it can compute time ranges to byte ranges equivalences and then submit byte-ranges HTTP requests”; col.9, lines 25-28: “Then, for each active connection, the next requests are issued by the client in step 207. This involves requesting the next few seconds e.g. 2 seconds (or corresponding byte-range) for each active media segment.”; and col.9, lines 39-42: “The different media segments of the video mash up may thus be downloaded at the computed downloading times for smooth execution during their respective execution time slot of the video mash up.”).
As per claim 2, which depends on claim 1, Denoual further teaches wherein the content comprises a streaming media data (see Denoual, col.1, lines 13-15: “The present invention concerns a method and a device for receiving a stream of multimedia data composed of a sequence of multimedia data segments”).
As per claim 3, which depends on claim 2, Denoual teaches further comprising playing, by a media player in a web browser at the requested device, the at least part of the combined content (see Denoual, col.1, lines 26-30: “For example, a multimedia mash up may be built from distributed pieces of multimedia, such as videos, located at different data sources such as Internet servers (e.g. video sharing site, personal Web site, Cloud services, company service, . . . ), by concatenation of different temporal video segments from the different data sources.”; and col.6, lines 45-50: “A first step of the initialisation process includes receiving the video mash up description 132 at the client terminal device 1000. The video mash up description 132 may be obtained, for example, by following a hyperlink to the XML description file (displayed on a Web page, sent by mail . . . ) provided by a user who defined and shared the video mash up.”).
As per claim 4, which depends on claim 2, Denoual further teaches wherein the receiving each of the respective first, second, and third content part by the requesting device, comprises streaming, from a respective device that stored the respective part, to the requesting device over the Internet, the respective first, second, and third content part (see Denoual, col.1, lines 13-15: “The present invention concerns a method and a device for receiving a stream of multimedia data composed of a sequence of multimedia data segments”).
As per claim 5, which depends on claim 4, Denoual further teaches wherein the streaming is based on, using, or according to, a Hypertext Transfer Protocol (HTTP), Real-time Transport Protocol (RTP), Real Time Streaming Protocol (RTSP), Real-Time Transport Control Protocol (RTCP), User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or any combination thereof (see Denoual, col.1, lines 40-47: “Streaming multimedia data by HTTP (hypertext transfer protocol) is becoming more popular for various reasons. Firstly, more and more video content is being stored on the Internet. Secondly, an HTTP communication server is easier to set up than an RTP/RTSP communication server traditionally used for video streaming. Another reason for the popularity of http for streaming multimedia is due to the success of portable devices such as smart phones and tablet devices that provide Internet and media experience to their mobile users.”).
As per claim 6, which depends on claim 4, Denoual further teaches wherein the streaming is based on, uses, or is according to, a progressive download (see Denoual, col.2, lines 34-38: “This enables enough data to be pre-buffered to enable playing to be started without display freeze or without waiting for data buffering the next multimedia segment following the current one being downloaded and displayed.”).
As per claim 7, which depends on claim 4, Denoual further teaches wherein the streaming is based on, uses, or is according to, an adaptive bit-rate streaming (see Denoual, col.3, lines 9-12: “In an embodiment, the transmission rate is increased by reducing the transmission rate of one or more multimedia segments being concurrently transmitted from their respective data sources.”; and col.9, lines 29-33: “the client terminal 1000 has the opportunity to periodically adapt the downloading rate allocated between the different media segments and thus to dynamically adjust the download deadlines to download the next media segments”).
As per claim 8, which depends on claim 7, Denoual further teaches wherein the streaming is based on, uses, or is according to, a Dynamic Adaptive Streaming over HTTP (DASH), HTTP Live Streaming (HLS), HTTP Dynamic Streaming (HDS), or any combination thereof (see Denoual, col.9, lines 29-33: “the client terminal 1000 has the opportunity to periodically adapt the downloading rate allocated between the different media segments and thus to dynamically adjust the download deadlines to download the next media segments”).
As per claim 9, which depends on claim 4, Denoual further teaches wherein each of the first, second, and third devices, responds to HTTP requests received over the Internet (see Denoual, col.,1 lines 35-39: “URI is an addressing scheme used to identify resources on the Internet and also provides features for addressing sub parts of a multimedia resource using what is often referred to as a “fragment identifier”.”; and Claim 1 rejection above).
As per claim 10, which depends on claim 9, Denoual further teaches wherein any communication of the requesting device with each of the first, second, and third devices is based on, or uses, a respective HTTP persistent connection (see Denoual, col.1, lines 48-52: “Current HTTP streaming is based on a pull model in which the client pulls a sequence of chunks of data, one after another, from a server, based on a manifest file (description) produced by the server describing currently available chunks or segments of data.”; and col.7, lines 60-64: “Next a request to receive the initial seconds, for example the initial 2 seconds of each active media segment is submitted to the different servers storing the media fragments of the video mash-up and the corresponding HTTP connections are left open… ”).
As per claim 11, which depends on claim 9, Denoual further teaches wherein any communication of the requesting device with each of the first, second, and third devices is based on, or uses, a respective TCP/IP protocol or connection (see Denoual, col.9, lines 5-8: “For example, the client can modify the TCP acknowledgements messages to artificially decrease the rate of one connection and to put more emphasis onto other active connections.”).
As per claim 12, which depends on claim 1, Denoual further teaches wherein the first, second, and third content parts are non-overlapping (see Denoual, Abstract: “… each multimedia data segment having an execution time slot relative to an execution time slot of an initial multimedia data segment of the sequence”).
As per claim 13, which depends on claim 1, Denoual teaches further comprising operating, by the requesting device, a web browser (see Denoual, col.1, lines 26-30: “For example, a multimedia mash up may be built from distributed pieces of multimedia, such as videos, located at different data sources such as Internet servers (e.g. video sharing site, personal Web site, Cloud services, company service, . . . ), by concatenation of different temporal video segments from the different data sources.”; and col.6, lines 45-50: “A first step of the initialisation process includes receiving the video mash up description 132 at the client terminal device 1000. The video mash up description 132 may be obtained, for example, by following a hyperlink to the XML description file (displayed on a Web page, sent by mail . . . ) provided by a user who defined and shared the video mash up.”).
As per claim 14, which depends on claim 13, Denoual further teaches wherein the identifying of the parts or of the devices is performed as part of the operating of the web browser (see Denoual, col.7, line 67-col.8, line 4: “it may be noted that when the client already has a description of the different media resources, it can compute time ranges to byte ranges equivalences and then submit byte-ranges HTTP requests”; and col.9, lines 25-28: “Then, for each active connection, the next requests are issued by the client in step 207. This involves requesting the next few seconds e.g. 2 seconds (or corresponding byte-range) for each active media segment.”).
As per claim 18, which depends on claim 13, Denoual further teaches wherein the content comprises a streaming media data, the method further comprising playing, by a media player that is part of the web browser, the combined at least part of the content (see Denoual, col.1, lines 40-44: “Streaming multimedia data by HTTP (hypertext transfer protocol) is becoming more popular for various reasons. Firstly, more and more video content is being stored on the Internet. Secondly, an HTTP communication server is easier to set up than an RTP/RTSP communication server traditionally used for video streaming.”; and col.2, lines 34-38: “This enables enough data to be pre-buffered to enable playing to be started without display freeze or without waiting for data buffering the next multimedia segment following the current one being downloaded and displayed.”).
As per claim 22, which depends on claim 1, Denoual further teaches wherein each of the content identifiers is in a format of XXX.YYY.com/ZZZ/UUU.mmm, wherein the XXX identifies a respective web server, the ZZZ identifies a directory including a requested content, and the UUU.mmm identifies a requested file in a directory (see Denoual, col.1, lines 48-52: “Current HTTP streaming is based on a pull model in which the client pulls a sequence of chunks of data, one after another, from a server, based on a manifest file (description) produced by the server describing currently available chunks or segments of data.”; and col.7, line 64-col.8, line 4: “This is done using the Media Fragment URI stored in the media segments description list 1003 with “end_time” parameter (http://theServer/thevideo#t=start_time, end_time) of the temporal Media Fragments being modified (it may be noted that when the client already has a description of the different media resources, it can compute time ranges to byte ranges equivalences and then submit byte-ranges HTTP requests).”).
As per claim 23, which depends on claim 1, Denoual teaches further comprising partitioning the content into at least the distinct first, second, and third content parts (see Denoual, col.2, lines 1-7: “According to a first aspect of the invention there is provided A method of receiving, at a communication device, a multimedia data stream composed of a sequence of multimedia data segments from a plurality of data sources, each multimedia data segment having an execution time slot relative to an execution time slot of an initial multimedia data segment of the sequence”).
As per claim 24, which depends on claim 1, Denoual further teaches wherein the content is partitioned into at least 3, 4, 5, 6, 7, 8, 9 or 10 distinct content parts (see Denoual, col.2, lines 1-7: “According to a first aspect of the invention there is provided A method of receiving, at a communication device, a multimedia data stream composed of a sequence of multimedia data segments from a plurality of data sources, each multimedia data segment having an execution time slot relative to an execution time slot of an initial multimedia data segment of the sequence”; and col.9, lines 39-42: “The different media segments of the video mash up may thus be downloaded at the computed downloading times for smooth execution during their respective execution time slot of the video mash up”).
As per claim 25, which depends on claim 24, Denoual further teaches wherein any byte of the content is included in at least one of the distinct content parts (see Denoual, col.7, line 67-col.8, line 4: “it may be noted that when the client already has a description of the different media resources, it can compute time ranges to byte ranges equivalences and then submit byte-ranges HTTP requests”; and col.9, lines 25-28: “Then, for each active connection, the next requests are issued by the client in step 207. This involves requesting the next few seconds e.g. 2 seconds (or corresponding byte-range) for each active media segment.”).
As per claim 26, which depends on claim 24, Denoual further teaches wherein any byte of the content is included in only one of the distinct content parts (see Claim 25 rejection above).
As per claim 27, which depends on claim 24, Denoual further teaches wherein the partitioning is sequential in the content (see Denoual, Abstract: “Receiving on a communication device a multimedia data stream composed of a sequence of multimedia data segments from a plurality of data sources, each multimedia data segment having an execution time slot relative to an execution time slot of an initial multimedia data segment of the sequence.”).
As per claim 28, which depends on claim 24, Denoual further teaches wherein the partitioning is non-sequential in the content (see Denoual, col.2, lines 1-7: “each multimedia data segment having an execution time slot relative to an execution time slot of an initial multimedia data segment of the sequence”).
As per claim 29, which depends on claim 24, Denoual further teaches wherein at least two of the content parts are of equal size (see Denoual, col.1, lines 48-52: “Current HTTP streaming is based on a pull model in which the client pulls a sequence of chunks of data, one after another, from a server, based on a manifest file (description) produced by the server describing currently available chunks or segments of data”).
As per claim 30, which depends on claim 1, Denoual further teaches wherein the first part comprises a first web page, wherein the first device is a first web server that stores the first web page, wherein the first content identifier comprises a first Uniform Resource Locator (URL) that identifies the first web page in the Internet, wherein the second part comprises a second web page, wherein the second device comprises a second web server that stores the second web page, wherein the second content identifier comprises a second Uniform Resource Locator (URL) that identifies the second web page in the Internet, wherein the third part comprises a third web page, wherein the third device comprises a third web server that stores the third web page, and wherein the third content identifier comprises a third Uniform Resource Locator (URL) that identifies the third web page in the Internet (see Denoual, col.1, lines 31-39: “The various multimedia segments may be downloaded using an addressing scheme identifying the location of the data source. In 2008, W3C initiated a standardization process for specifying an addressing scheme based on a traditional uniform resource identifier (URI) mechanism. URI is an addressing scheme used to identify resources on the Internet and also provides features for addressing sub parts of a multimedia resource using what is often referred to as a “fragment identifier”.”; and Claim 1 rejection above).
As per claim 31, which depends on claim 1, Denoual further teaches wherein the first, second, or third request comprises a Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTPS) request (see Denoual, col.7, line 60-col.8, line 9: “Next a request to receive the initial seconds, for example the initial 2 seconds of each active media segment is submitted to the different servers storing the media fragments of the video mash-up and the corresponding HTTP connections are left open. This is done using the Media Fragment URI stored in the media segments description list 1003 with “end_time” parameter (http://theServer/thevideo#t=start_time, end_time) of the temporal Media Fragments being modified (it may be noted that when the client already has a description of the different media resources, it can compute time ranges to byte ranges equivalences and then submit byte-ranges HTTP requests).”).
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 (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.
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. Claims 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Denoual et al. (US 9,350,796 B2) in view of Lockhart (US 2012/0259926 A1).
As per claim 15, which depends on claim 1, Denoual does not explicitly teach wherein the web browser consists of, comprises, or is based on, Microsoft Internet Explorer, Google Chrome, OperaTM, or Mozilla Firefox®.
Lockhart teaches wherein the web browser consists of, comprises, or is based on, Microsoft Internet Explorer, Google Chrome, OperaTM, or Mozilla Firefox® (see Lockhart, [0129]: “By selecting or clicking on the text, a viewer can cause the embedded script to be executed in order to access the linked content. In one embodiment, execution of the script may cause a browser (such as Firefox, Internet Explorer, Chrome, Safari, etc.) to be automatically opened and directed to the appropriate URL.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Denoual in view of Lockhart so that the web browser consists of, comprises, or is based on, Microsoft Internet Explorer, Google Chrome, OperaTM, or Mozilla Firefox®. One would be motivated to do so because Denoual clearly suggest the use of a browser application and these are well-known, widely-implemented, and conventionally-employed applications for accessing the Internet.
As per claim 16, which depends on claim 13, Denoual does not explicitly teach wherein the web browser is a mobile web browser.
Lockhart teaches wherein the web browser is a mobile web browser (see Lockhart, [0129]: “By selecting or clicking on the text, a viewer can cause the embedded script to be executed in order to access the linked content. In one embodiment, execution of the script may cause a browser (such as Firefox, Internet Explorer, Chrome, Safari, etc.) to be automatically opened and directed to the appropriate URL.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Denoual in view of Lockhart so that the web browser is a mobile web browser. One would be motivated to do so because such an implementation enables the user to be mobile while streaming.
As per claim 17, which depends on claim 16, Denoual does not explicitly teach wherein the mobile web browser consists of, comprises, or is based on, Safari, Opera MiniTM, or Android web browser.
Lockhart teaches wherein the web browser is a mobile web browser consists of, comprises, or is based on, Safari, Opera MiniTM, or Android web browser (see Lockhart, [0115]: “The IMMS may also be implemented in various forms including, for example, a client-based software application designed to reside on a user's computer, or an app configured for use on a mobile operating systems such as Android, iOs, Windows Mobile. In one embodiment, the IMMS system may also be implemented as a web-based application accessible via an internet browser. In this case, the IMMS system could be accessed and used by any internet-enabled device without requiring any installation of software or prior configuration.”; and [0129]: “By selecting or clicking on the text, a viewer can cause the embedded script to be executed in order to access the linked content. In one embodiment, execution of the script may cause a browser (such as Firefox, Internet Explorer, Chrome, Safari, etc.) to be automatically opened and directed to the appropriate URL.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Denoual in view of Lockhart so that the mobile web browser consists of, comprises, or is based on, Safari, Opera MiniTM, or Android web browser. One would be motivated to do so because these applications for accessing the Internet, are synonymous with a mobile user devices.
8. Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Denoual et al. (US 9,350,796 B2) in view of Lucco et al. (US 2013/0061128 A1).
As per claim 19, which depends on claim 1, Denoual does not explicitly teach wherein the requesting device executes instructions that include, or are based on, a client-side scripting.
Lucco teaches wherein the requesting device executes instructions that include, or are based on, a client-side scripting (see Lucco, [0007]: “As a trend, web browsers and web pages are tending to employ more and more client-side scripting, accounting for an improved user interface in which the user does not experience unfriendly "refreshing" of a web page”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Denoual in view of Lucco so that the requesting device executes instructions that include, or are based on, a client-side scripting. One would be motivated to do so because Lucco teaches such implementation accounts “for an improved user interface in which the user does not experience unfriendly "refreshing" of a web page”.
As per claim 20, which depends on claim 19, Denoual does not explicitly teach wherein the scripting uses a dynamic programming language that supports dynamic typing, first-class functions, functional programming, or any combination thereof.
Lucco teaches wherein scripting uses a dynamic programming language that supports dynamic typing (see Lucco, [0050]: “FIG. 5 illustrates another non-limiting example of code swapping during dynamic code generation and execution based on dynamic typing”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Denoual in view of Lucco so that the scripting uses a dynamic programming language that supports dynamic typing. One would be motivated to do so because such implementation increases flexibility, prototyping and development, and provides a more concise code making it easier to read and write.
9. Claims 21 are rejected under 35 U.S.C. 103 as being unpatentable over Denoual et al. (US 9,350,796 B2) in view of Farber et al. (US 2008/0215755 A1).
As per claim 21, which depends on claim 1, Denoual does not explicitly teach wherein each of the first, second, and third devices is a replica server that is part of a first Content Distribution Network (CDN) that is operated, controlled, or managed by a CDN operator.
Farber teaches wherein each of the first, second, and third devices is a replica server that is part of a first Content Distribution Network (CDN) that is operated, controlled, or managed by a CDN operator (see Farber, Abstract: “A plurality of repeater servers form a shared content delivery network (CDN) to serve resources to clients on behalf of a plurality of content providers… Responsive to the CDN server being requested to serve the second resource: if a copy of the second resource is available on the CDN server, the copy is served to the client from the CDN server; otherwise, the second resource is replicated on the CDN server and then served to the client from the CDN server”; and [0247]: “A resource change is identified at the reflector either manually by the operator, or through a script when files are installed on the server, or automatically through a change detection mechanism (e.g., a separate process that checks regularly for changes).”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Denoual in view of Farber so that each of the first, second, and third devices is a replica server that is part of a first Content Distribution Network (CDN) that is operated, controlled, or managed by a CDN operator. One would be motivated to do so because such an implementation drastically reduces latency and improves content delivery speed as processing occurs from the multiple replica servers rather than a single server.
Conclusion
10. For the reasons above, claims 1-31 have been rejected and remain pending.
11. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL Y WON whose telephone number is (571)272-3993. The examiner can normally be reached on Wk.1: M-F: 8-5 PST & Wk.2: M-Th: 8-7 PST.
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, Nicholas R Taylor can be reached on 571-272-3889. 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.
/Michael Won/Primary Examiner, Art Unit 2443