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 . Claims 1-29 are presented for examination.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 10/29/2025, 05/20/2025, 12/29/2024, 08/14/2024, 06/26/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Title Objection
The title of the invention is not descriptive relevant to the subject of this continuation according to its own specific inventive concept. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claims Objections
Regarding claim 1 , the limitations “a message that comprises the first IP address and that is responsive to, or comprises, the metered charging level”. The limitation presents two alternative conditions (“responsive to” or “comprises”) that are claimed without clarifying: what responsive to technically means (temporal? causal? conditional?), or whether the charging level must be included as data. The phrase “responsive to” is subjective and relational, failing to define a clear structural or operational boundary. The applicant can remedy this concern by replacing with a single, objective relationship, e.g. “wherein the message includes a data field encoding the metered charging level.”
the limitations “a first server”, “a second server”, “the web server”. Claim 1 fails to establish whether these servers are distinct or may overlap, whether “first server” and “web server” may be the same physical or logical entity. Appropriate clarification is required.
Referring to claims 17-21, presents repeated compatibility phrasing that is overboard “based on/ uses/compatible with” language. These phrases define capability not actual operation. Compatible with does not require that the protocol to used. The claims fail to specify whether the recited protocols are actually employed, optionally supported or merely theoretically compatible.
Referring to claim 17-21, these claims enumerate a laundry list of RFCs without specifying selection criteria, operation sequence or interaction model.
Referring to claim 23, the recitation “At least part of steps” wherein at least part of steps of claim 1 are included in a Software Development Kit (SDK)”. The office in unclear Which steps? How many? Or Which combination applicant is referring to? The phrase “at least part” fails to delineate claim boundaries and renders the scope indeterminate.
Referring to claim 26-27, measurement and timing vagueness because it covers all possible sampling rate without any relationship to the system behavior or URL triggering. The limitation fails to meaningfully constrain the claim and introduces ambiguity as to operative conditions.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements are auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-29 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-85 of US pat 11115230 related Application No. 16/826206. Although the conflicting claims are not identical, they are not patentably distinct from each other because claims 1-29 are anticipated by claims 1-85 of the issued US patent.
Instant Application: 18754980
Claims: 1
Issued US pat 11115230 B2
Claims: 1
1. A method for obtaining a first content that comprises a first web page or a part thereof, that is identified by a first Uniform Resource Locator (URL), and that is stored in a web server, and for obtaining a second content that comprises a second web page or a part thereof, that is identified by a second URL, and that is stored in the web server, by using a hand-held mobile device that is connectable to the Internet via a cellular network, that is addressable in the Internet using a first Internet Protocol (IP) address, and that is powered by a rechargeable battery, the method comprising:
metering, by the mobile device, a charging level of the battery;
sending, by the mobile device via the cellular network over the Internet, a message that comprises the first IP address and that is responsive to, or comprises, the metered charging level;
receiving, by the mobile device from a first server via the cellular network over the Internet, the first URL, in response to the sending of the message;
sending, by the mobile device to the web server via the cellular network over the Internet, a first HyperText Transfer Protocol (HTTP) request that comprises the received first URL, in response to the receiving of the first URL;
receiving, by the mobile device from the web server via the cellular network over the Internet, the first content, in response to the sending of the first HTTP request;
sending, by the mobile device via the cellular network over the Internet to the first server, the received first content;
receiving, by the mobile device from a first server via the cellular network over the Internet, the second URL, in response to the sending of the message;
sending, by the mobile device to the web server via the cellular network over the Internet, a second HyperText Transfer Protocol (HTTP) request that comprises the received second URL, in response to the receiving of the second URL;
receiving, by the mobile device from the web server via the cellular network over the Internet, the second content, in response to the sending of the second HTTP request; and
sending, by the mobile device via the cellular network over the Internet to the first server, the received second content.
1. A method for fetching a content identified by a content identifier from a web server by using an appliance that serves as an HTTP Proxy client and that is operating in multiple states that includes an idle state and non-idle states, for use with a plurality of HTTP Proxy servers, that includes first and second servers, each of the plurality of servers is connectable to the Internet and is addressable in the Internet using a respective IP address, the first server stores a list of IP addresses, and the appliance that are each connected to the Internet and are each addressable in the Internet using a respective IP address, the method by the appliance comprising:
storing, operating, or using an operating system, a program process, or a thread;
monitoring or metering, a resource utilization;
responsive to being in one of the non-idle states, determining, if an idling condition is met; responsive to the determination that the idling condition is met, shifting to the idle state; responsive to being in the idle state, determining if an idling condition is met; and responsive to the determination that the idling condition is not met, shifting to one of the non-idle states; receiving, from the first or second server using HTTP Proxy protocol or connection, a first message that comprises the content identifier; in response to the receiving of the first message, initiating a communication, with the second server; randomly selecting the first server from the plurality of servers using one or more random numbers generated by a random number generator; sending, to the selected first server, a second message; sending, to the web server, a content request that comprises the content identifier; receiving, from the web server, the content, in response to the content request; and sending, to the first or second server using HTTP Proxy protocol or connection, the content, in response to the first message, wherein the communication over the Internet with the first or second server uses Socket Secure (SOCKS) protocol or connection, wherein the first or second server serves as an SOCKS server and the appliance serves as an SOCKS client, wherein the idling condition is determined to be met based on, or according to, activating or executing the process or thread by the operating system or the program, wherein the idling condition is determined to be met based on, or according to, the monitored or metered resource utilization being under a threshold, wherein the appliance is associated with a first value that comprises a first numeric value or a first identifier of a feature, a characteristic, or a property of a first attribute type, and wherein the appliance is associated with a second value that comprises a second numeric value or a second identifier of a feature, a characteristic, or a property of a second attribute type.
These claims are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1 of U.S. Patent 11115230. Claims 1-29 of instant application are analogous to the issue the issued application and thus anticipate it. This is a non-provisional type double patenting.
Claim Rejections - 35 USC § 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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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.
Claims 1-29 are rejected under 35 U.S.C. 103 as being unpatentable over Stockwell (US pub, 2014/0189061) in view of Khorashadi (US pub, 2013/0031459 A1).
Referring to claim 1, Stockwell teaches a method for obtaining a first content that comprises a first web page or a part thereof, that is identified by a first Uniform Resource Locator (URL), and that is stored in a web server, and for obtaining a second content that comprises a second web page or a part thereof, that is identified by a second URL, and that is stored in the web server, by using a hand-held mobile device that is connectable to the Internet via a cellular network, that is addressable in the Internet using a first Internet Protocol (IP) address, and that is powered by a rechargeable battery (Stockwell: ¶ [011], [016] Stockwell discloses a handheld mobile device with a rechargeable battery communicating via cellular and internet networks), the method comprising:
metering, by the mobile device, a charging level of the battery (Stockwell ¶ [004], explicitly teaches receiving & monitoring battery information of mobile device – [abs]);
sending, by the mobile device via the cellular network over the Internet, a message that comprises the first IP address and that is responsive to, or comprises, the metered charging level (Stockwell (¶¶ [0004], [0011]) teaches sending mobile device operating information, including battery level, from the mobile device to a server);
sending, by the mobile device via the cellular network over the Internet to the first server, the received first content (Stockwell teaches uploading content from a mobile device to a server when battery criteria are satisfied (¶¶ [0004], [0011])
Stockwell expressly teaches regulated uploading of content from the mobile devices to a server based on battery state ([004], [011]), but expressly lacks receiving, by the mobile device from a first server via the cellular network over the Internet, the first URL, in response to the sending of the message and lacks sending, by the mobile device to the web server via the cellular network over the Internet, a second HyperText Transfer Protocol (HTTP) request that comprises the received second URL, in response to the receiving of the second URL.
Khorashadi teaches server-directed URL-based web browsing and return of retrieved content to a server. Furthermore, Khorashadi teaches receiving, by the mobile device from a first server via the cellular network over the Internet, the first URL, in response to the sending of the message (Khorashadi teaches that a server assists mobile browsing by supplying information identifying web resources requested by the mobile device (¶¶ [0004]–[0006], [0090]);
Khorashadi teaches receiving, by the mobile device from the web server via the cellular network over the Internet, the first content, in response to the sending of the first HTTP request (discloses receiving webpage content including HTML, JavaScript, CSS, and media from web servers (¶¶ [0089]–[0091]);
Khorashadi teaches sending, by the mobile device to the web server via the cellular network over the Internet, a first HyperText Transfer Protocol (HTTP) request that comprises the received first URL, in response to the receiving of the first URL (explicitly teaches sending HTTP requests for webpages identified by URLs from a mobile browser (¶¶ [0084]–[0085]);
Khorashadi teaches sending, by the mobile device to the web server via the cellular network over the Internet, a second HyperText Transfer Protocol (HTTP) request that comprises the received second URL, in response to the receiving of the second URL (Khorashadi: ¶ [084]-[085], teaches repeated HTTP requests for multiple web resources as a part of normal web browsing behavior);
Khorashadi teaches receiving, by the mobile device from the web server via the cellular network over the Internet, the second content, in response to the sending of the second HTTP request (Khorashadi: [089]-[091], teaches retrieval of multiple web pages or webpage portions during browsing); and
Khorashadi teaches sending, by the mobile device via the cellular network over the Internet to the first server, the received second content (Khorashadi ¶ [099], teaches returning browsing results or content to a server)
It would have been obvious to one of ordinary skill in the art at the time of the invention to include battery-based regulation of uploads from mobile devices of Stockwell to incorporate condition based server-directed web content retrieval as taught by Khorashadi for performing optimal uploading of content in order to conserve battery life and manage mobile device resources. Combining these teachings merely applies known battery-aware control techniques to a known cloud-assisted web browsing architecture to achieve predictable results.
Referring to claim 2, Stockwell teaches the method according to claim 1, wherein the sending of the message comprises sending of the message to the first server (Stockwell discloses transmitting mobile device operating information, including battery information, from the mobile device to a server that regulates uploads .. see Abstract; paragraphs [0004]–[0005], [0011]).
Referring to claim 3, Khorashadi teaches the method according to claim 1, wherein the sending of the message comprises sending of the message to a second server that is different from the first server (Khorashadi discloses architectures involving multiple servers, including a browser assistance server and a web server, which may be distinct entities (see paragraphs [0004]–[0006], [0080]–[0082]). It would have been obvious to transmit battery or operating information to a server other than the web server in a multi-server system).
Referring to claim 4, Khorashadi teaches the method according to claim 1, wherein the first or second HTTP request comprises a HTTP Secure (HTTPS) request (Khorashadi teaches HTTP-based web requests, and the use of HTTPS is a well-known security variant of HTTP. The substitution of HTTPS for HTTP is an obvious design choice).
Referring to claim 5, Stockwell teaches the method according to claim 1, wherein the message comprises the metered charging level or a value that is based on the metered charging level Stockwell expressly teaches transmitting battery level information and using that information to regulate uploads (paragraphs [0004], [0011])..
Referring to claim 6, Stockwell teaches the method according to claim 1, further comprising comparing the metered charging level to a threshold level (Stockwell explicitly teaches comparing battery level information against one or more battery threshold criteria to regulate uploads see…paragraphs [0004]–[0005]).
Referring to claim 7, Stockwell teaches the method according to claim 6, wherein the sending of the message is in response to the charging level being above a threshold level Stockwell teaches enabling uploads when battery level exceeds a predetermined threshold (paragraph [0004]).
Referring to claim 8, Stockwell teaches the method according to claim 6, wherein the threshold level is above 40%, 50%, 60%, 70%, 80%, or 90% of the battery defined full charge capacity Stockwell teaches battery threshold levels and ranges (paragraph [0004]) - Selecting particular percentage values within known battery threshold ranges would have been an obvious matter of routine optimization).
Referring to claim 9, Stockwell teaches the method according to claim 6, wherein the comparing is performed by the mobile device (Stockwell teaches mobile device monitoring of battery information prior to upload decisions ..paragraphs [0004], [0011]).
Referring to claim 10, Stockwell teaches the method according to claim 6, wherein the comparing is performed by the first server. (Stockwell explicitly teaches server-side comparison of battery information to determine whether uploads are enabled or regulated see paragraphs [0004], [0011]).
Referring to claim 11, Stockwell teaches the method according to claim 1, wherein the metering comprises monitoring total voltage, a voltage of an individual cell, a minimum and maximum cell voltage, an average temperature, a coolant intake temperature, a coolant output temperature, a temperature of an individual cell, State of Charge (SOC), Depth of Discharge (DOD), State of Health (SOH), or any combination thereof (Stockwell teaches monitoring battery information and mobile device operating information, which inherently includes such battery parameters as known in the art. Selection of particular battery metrics would have been obvious).
Referring to claim 12, Stockwell teaches the method according to claim 1, wherein the metering uses a Battery Management System (BMS) (Use of a BMS to obtain battery information is well known in mobile devices and would have been an obvious implementation detail.
Referring to claim 13, Stockwell teaches the method according to claim 1, wherein the battery comprises a smart battery that includes plus and minus terminals, and a communication interface. (Smart batteries with communication interfaces were well known, and their use to obtain battery information in Stockwell’s system would have been obvious).
Referring to claim 14. Stockwell and Khorashadi teaches the method according to claim 1, further comprising establishing, by the mobile device via the cellular network over the Internet, a connection with the first server, in response to a connecting to the Internet of the mobile device (Stockwell and Khorashadi both disclose establishing network connections between mobile devices and servers upon network connectivity).
Referring to claim 15, Stockwell teaches the method according to claim 14, wherein any communication between the mobile device and the first server is over the established connection (see ¶ [018], client server connection is over the internet).
Referring to claim 16, Stockwell teaches the method according to claim 14, wherein the established connection is a Transmission Control Protocol (TCP) connection using ‘Active OPEN’, ‘Passive OPEN’, or TCP keepalive mechanism, or wherein the established connection uses, or is based on, Virtual Private Network (VPN) (Use of TCP connections and VPNs for Internet communication is well known and would have been obvious for implementing the disclosed systems).
Referring to claim 17, Khorashadi teaches the method according to claim 1, wherein the communication by the mobile device uses a Network Address Translator (NAT) traversal scheme that is according to, or uses, Internet Engineering Task Force (IETF) Request for Comments (RFC) 2663, IETF RFC 3715, IETF RFC 3947, IETF RFC 5128, IETF RFC 5245, IETF RFC 5389, or IETF RFC 7350 (Khorashadi discloses mobile devices communicating over cellular networks and the Internet, environments in which NAT traversal techniques are routinely employed. Selecting a known NAT traversal mechanism would have been obvious).
Referring to claim 18, Khorashadi discloses the method according to claim 17, wherein the NAT traversal scheme is according to, based on, or uses, Traversal Using Relays around NAT (TURN), Socket Secure (SOCKS), NAT ‘hole punching’, Session Traversal Utilities for NAT (STUN), Interactive Connectivity Establishment (ICE), UPnP Internet Gateway Device Protocol (IGDP), or Application-Level Gateway (ALG) Khorashadi discloses mobile devices communicating over cellular networks and the Internet, environments in which NAT traversal techniques are routinely employed. Selecting a known NAT or UPnP devices for traversal mechanism would have been obvious.)
Referring to claim 19, Khorashadi teaches the method according to claim 1, wherein a communication over the Internet by the mobile device with the first server, is based on, uses, or is compatible with, Socket Secure (SOCKS) protocol or connection, where the first server serves as a SOCKS server and the mobile device serves as a SOCKS client Use of SOCKS proxies for Internet communication is well known and represents an obvious networking implementation choice.
Referring to claim 20, Stockwell and Khorashadi teaches the method according to claim 19, wherein the SOCKS protocol or connection is according to, based on, or is compatible with, SOCKS4, SOCKS4a, or SOCKS5 that is according to, based on, or is compatible with, IETF RFC 1928, IETF RFC 1929, IETF RFC 1961, or IETF RFC 3089 (Use of SOCKS proxies for Internet communication is well known and represents an obvious networking implementation choice).
Referring to claim 21, Khorashadi teaches the method according to claim 1, wherein a communication by the mobile device via the cellular network over the Internet with the first server, is based on, uses, or is compatible with, a Transmission Control Protocol over Internet Protocol (TCP/IP) protocol or connection, or wherein the communication over the Internet by the mobile device with the first server, is based on, uses, or is compatible with, HTTP or HTTPS protocol or connection, where the first server serves as an HTTP or HTTPS server and the mobile device serves as an HTTP or HTTPS client (Khorashadi [132], [137] explicitly teaches HTTP-based web browsing, and TCP/IP is inherent in Internet communication).
Referring to claim 22, Khorashadi teaches the method according to claim 1, wherein the mobile device comprises, or consists of, a smartphone (see [024], mobile phone is smart phone).
Referring to claim 23, Stockwell teaches the method according to claim 1, wherein at least part of steps of claim 1 are included in a Software Development Kit (SDK) that is provided as a non-transitory computer readable medium containing computer instructions (Stockwell: [012], [013], [018], Providing the disclosed methods in software or SDK form is an obvious software distribution choice).
Referring to claim 24, Stockwell teaches the method according to claim 1, wherein the first or second content comprises, a part or whole of a computer file, audio data, voice data, multimedia data, video data, image data, music data, or a computer program (see Stockwell [006], [011], [016], [018], see a list of files).
Referring to claim 25, Stockwell teaches the method according to claim 1, wherein the cellular network comprises or uses a Third Generation (3G) network that uses a protocol selected from the group consisting of UMTS W-CDMA, UMTS HSPA, UMTS TDD, CDMA2000 1×RTT, CDMA2000 EV-DO, and GSM EDGE-Evolution, or wherein the cellular network comprises or uses a Fourth Generation (4G) network that uses HSPA+, Mobile WiMAX, LTE, LTE-Advanced, MBWA, or is based on IEEE 802.20-2008 (Stockwell Cellular networks [016] that these mobile devices operating over cellular networks. Selection of particular cellular standards would have been obvious.)
Referring to claim 26, Stockwell teaches the method according to claim 1, wherein the metering of the charging level comprises periodically or continuously measuring of the charging level (Stockwell teaches ongoing monitoring of battery information (paragraph [0011] & Selecting a particular sampling either periodically or continuous interval is an obvious matter of design choice)
Referring to claim 27, Stockwell teaches the method according to claim 26, wherein the measuring is at least every 10 milliseconds, 20 milliseconds, 30 milliseconds, 50 milliseconds, 100 milliseconds, 1 second, 2 seconds, 3 seconds, 5 seconds, 10 seconds, 30 seconds, 50 seconds, or 100 seconds, 1 minute, 2 minutes, 3 minutes, 5 minutes, or 10 minutes (Stockwell teaches ongoing monitoring of battery information see… paragraph [0011] Selecting a particular sampling interval is an obvious matter of design choice)
Referring to claim 28, Khorashadi teaches the method according to claim 1, further comprising storing, operating, or using, by the mobile device, a web browser Khorashadi explicitly teaches use of a web browser on a mobile device ..[abs], [004], [005], [007]).
Referring to claim 29, Khorashadi teaches the method according to claim 28, wherein the web browser is a mobile web browser Khorashadi explicitly teaches mobile web browsers operating on mobile computing devices (see paragraph… [140], mobile browser).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The examiner also requests, when responding to this office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application. Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111 (c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AFTAB N. KHAN whose telephone number is (571) 270-5172. The examiner can normally be reached on Monday-Friday 8AM-5PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Glenton Burgess can be reached on 571-272-3949. 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.
/AFTAB N. KHAN/
Primary Examiner, Art Unit 2454