Prosecution Insights
Last updated: July 17, 2026
Application No. 18/755,005

System and Method for Improving Content Fetching by Selecting Tunnel Devices

Non-Final OA §103
Filed
Jun 26, 2024
Priority
Aug 28, 2017 — provisional 62/550,834 +7 more
Examiner
KHAN, AFTAB N
Art Unit
2454
Tech Center
2400 — Computer Networks
Assignee
Bright Data Ltd.
OA Round
1 (Non-Final)
80%
Grant Probability
Favorable
1-2
OA Rounds
1y 2m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 80% — above average
80%
Career Allowance Rate
366 granted / 456 resolved
+22.3% vs TC avg
Strong +50% interview lift
Without
With
+49.7%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
17 currently pending
Career history
477
Total Applications
across all art units

Statute-Specific Performance

§101
0.7%
-39.3% vs TC avg
§103
85.9%
+45.9% vs TC avg
§102
12.2%
-27.8% vs TC avg
§112
0.8%
-39.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 456 resolved cases

Office Action

§103
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-81 are presented for examination. Information Disclosure Statement The information disclosure statements (IDS) submitted on 06/26/2024, 08/14/2024, 12/29/2024, 05/20/2025 & 10/29/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Terminal Disclaimer A terminal disclaimer filed 02/05/2026 has effectively overcame a nonstatutory double patenting rejection over a reference patent (37 CFR 1.321(b) and (c)). 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 claim1, Claim 1 is objected to under 35 USC 112b as being indefinite because it recites that client device is “responsive to being in the “non-idle state”, and “responsive to being in the Idle-State” However, the claim does not set forth any objective or measurable criteria defining when the client device is considered to be in Idle or Non-Idle states. It is unclear what specific technical conditions distinguish the idle state from the non-idle state such as whether the states are determined by processor activity, application executions, network activity, display state, user interface focus or some operational parameters. Furthermore, Claim 1, recite “determining whether an idling criterion is met” Term idling criterion is undefined and it does not indicate any structure, no formula, no parameters and no examples. Applicant is requested to make changes to further define how the idling criterion functions into the claim language. An ordinary artisan cannot reasonably determine when the claimed method is operating in one state vs the other. Appropriate corrections are required. Referring to claims 15, 21, these claims enumerate a laundry list of RFCs without specifying selection criteria, operation sequence or interaction model. Referring to claims 18 and claims 22 basically are the same underly concepts of HTTP communication and are therefore redundant. Appropriate corrections are needed. Referring to claim 23, that recite part of earlier claim 18. Appropriate corrections are needed. Regarding claims 33-43, the claims recites limitations are directed laundry list of appliances that are directed to “intended use”. Claims 33-43 recite that the method is performed by various types of devices (e.g. mobile devices, appliances, wearable devices). These limitations merely specify the environment in which the method is performed and not change the steps of the claimed method. Accordingly these limitations are directed to intended use and do not patentably distinguish the claims over the prior art. For example these dependent claims starting with claim 33 recite house hold appliances (33), food appliance (34-36), HVAC (37-38), cleaning electronics (39-41) and portable device (42). These claims do not change networking steps, TCP communication, and messaging. It only specify what device runs the method and therefore are purely directed to classic field of use or intended use limitation. Appropriate corrections are required. Referring to claims 56 & 57 both recite comparing value to a above a threshold (56) and below a threshold (claim 57). The claims are mirror image that are binary alternatives and can be combined in one claim. Referring to claims 1, 15, 16, 17-21, 46,48,49, 51, 55-57, 68, 71, and 81 presents repeated compatibility phrasing that is overboard “based on/ uses/comprises” 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 claims 74, 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. Appropriate corrections are required. 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-81 are rejected under 35 U.S.C. § 103 as being unpatentable over Shribman et al (2016/0105530) in view of Gupta (US pub, 2015/0117425 A1). Referring to claim 1, Shribman teaches a method for obtaining a content using a first server, and a client device that is configured to be in one of idle and non-idle states (¶[020], client server model), that is addressable in the Internet by a first Internet Protocol (IP) address, and that is connectable by a network interface to the Internet via a first network, wherein the first network uses, or is based on, Asymmetric Digital Subscriber Line (ADSL) technology, Very High-Speed Subscriber Line (VDSL) technology, Data Over Cable Service Interface Specification (DOCSIS) technology, Third Generation (3G) cellular technology, Fourth Generation (4G) cellular technology, Wireless Local Area Network (WLAN) technology, or Wireless Personal Area Network (WPAN) technology (¶ [020]- [021], client sends a request to server – “The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client”), the method comprising: connecting, by the client device using the network interface, to the Internet via the first network (¶ [004]-[005], [589], connecting client device to the internet); establishing, by the client device with the first server over the Internet via the first network, a Transmission Control Protocol (TCP) connection (¶ [004]- [007], TCP/IP Protocol Suite, ¶[008-014], TCP connection establishment 3 way handshake, ¶ [021], HTTP over TCP connection); sending, by the client device to the first server over the established TCP connection ¶ [006], TCP packets includes destination IP address), and that comprises the first IP address (¶ [016], The IP header 16f contains the IP address of the source as Source IP Address field 16d and the Destination IP Address field 16c) determining whether an idling criterion is met (¶[543], The device monitors its resources and performance, and upon detecting a resource utilization that is above a set threshold, declares itself as congested & [547], A device monitors resource conditions (bandwidth, load, availability) and determined operational state, e.g. offline, online, congested etc.); responsive to being in the non-idle state and responsive to the determination that the idling criterion is met, shifting to the idle state (¶ [544], transition between devices states, e.g. online, congested and offline); responsive to being in the idle state and responsive to the determination that the idling criterion is not met, shifting to the non-idle state (¶ [543]-[548], teaches dynamic transitions between states based on changing conditions); sending, by the client device to the first server over the established TCP connection, a second message that is responsive to, or indicative of, the client device state (¶ [546]-[547], teaches sending state-indicative messages including heartbeat and congestion messages, device sends heartbeat message indicating availability, and send Non-congested or send congested message..); receiving, by the client device in the idle state over the Internet, in response to the sending of the second message, a request for the content (¶ [548], upon receiving the state message, another device or server determines whether to assign work or send request based on that state); obtaining, by the client device, in response to the receiving of the request, the content (¶ [021], [084]-[085], browser/client retrieves (fetches) content from server in response to request) and sending, by the client device over the Internet, the obtained content, in response to the obtaining of the content (¶ [021], [084]-[085], transmission of content between devices/servers/clients) Shribman teaches a client server communication framework in which client devices obtains content from server and operates within a TCP/IP based network but expressly lacks a first message that indicative that the first network uses, or is based on, ADSL, VDSL, DOCSIS, 3G cellular, 4G cellular, WLAN. However, Gupta teaches performing network type indication for WLAN connectivity discovery along with identifying wireless LAN access point. Furthermore, Gupta teaches sending a first message that indicative that the first network uses, or is based on, ADSL, VDSL, DOCSIS, 3G cellular, 4G cellular, WLAN (Gupta ¶ [142], Gupta teaches transmitting a network access identifier enables systems to determine the type of network being used – also see [104], [116]) It would have been obvious to an ordinary person skilled in the art at the time invention was made to modify system of Shribman to incorporate a mechanism for network access/connectivity identification as taught by Gupta because Shribman is already expressly teaches communication optimization, device condition monitoring and selective use of devices based on operational status. The modification would involve supplementing Shribman existing client-server signaling with Gupta’s known network access identification in order to provide optimal ability to perform network aware decisions while leaving the underlying client/server and state reporting architecture unchanged. Referring to claim 2, Shribman teaches the method according to claim 1, wherein the content comprises a web-page or a part thereof (see ¶ [507], A content, such as an URL (or a web-page, or a web-site) which is typically stored in a data server, such as the data server #1 22a, may be requested by the client device). Referring to claim 3, Shribman teaches the method according to claim 1, wherein the content is identified using a content identifier, and wherein the request comprises the content identifier (¶ [507], A content, such as an URL (or a web-page, or a web-site) which is typically stored in a data server, such as the data server #1 22a, may be requested by the client device). Referring to claim 4, Shribman teaches the method according to claim 3, wherein the content identifier comprises a Uniform Resource Identifier (URI) or a Uniform Resource Locator (URL) (see ¶ [022], [084] [085], URL/URI). Referring to claim 5, Shribman teaches the method according to claim 1, wherein the content is stored in a second server (see ¶ [226]-[228], intermediate node/tunnel + data server, [268]-[272] multiple peer serving content; [515], multiple source providing chunks). Referring to claim 6, Shribman teaches the method according to claim 5, wherein the second server comprises a web server (¶ [232], [236], [280], second server is webserver). Referring to claim 7, Shribman teaches The method according to claim 5, wherein the obtaining comprises: sending, by the client device to the second server over the Internet, the request (¶ [507], client send request including content identifier); and receiving, sending, by the client device from the second server over the Internet, the content, in response to the sending of the request to the second server (see ¶ [515], client send “request chunk” messages to peers). Referring to claim 8, Shribman teaches the method according to claim 1, wherein the receiving of the request comprises receiving of the request from the first server (¶ [021], client sends request to server and receives response [548], server/peer sends workload/request based on state). Referring to claim 9, Shribman teaches the method according to claim 1, wherein the sending of the content comprises sending of the content to the first server (¶ [021], bidirectional communication between client server [515], nodes exchange data where client act as provider). Referring to claim 10, Shribman teaches the method according to claim 1, wherein the receiving of the request comprises receiving of the request from a second server that is different from the first server (¶ [515], request handled by different nodes, i.e. request may originate from nodes other than the original server). Referring to claim 11, Shribman teaches the method according to claim 10, wherein the sending of the content comprises sending of the content to the second server ([473], content transferred between nodes). Referring to claim 12, Shribman teaches the method according to claim 1, wherein the determining is performed by the client device (see ¶ [543], device monitors its own resources, [544], device determines its own state). Referring to claim 13, Shribman teaches the method according to claim 1, wherein the TCP connection uses 'Active OPEN', 'Passive OPEN', or TCP keepalive mechanism (¶ [007]-[013], TCP handshake (active Open/ Passive Open) TCP keepalive = well known TCP feature). Referring to claim 14, Shribman teaches the method according to claim 1, further using a Network Address Translator (NAT) traversal scheme (see [268], peer/tunnel-based communication, [506], pre-connection logic ..Shribman peer/tunnel architecture inherently require NAT traversal to enable communication across networks). Referring to claim 15, Shribman teaches the method according to claim 14, wherein the NAT traversal scheme is according to, based on, 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 ([005], [015], [018], [020], Selection of specific RFC based NAT traversal mechanism is routine design choice). Referring to claim 16, Shribman teaches the method according to claim 14, 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) (see ¶ [268], peer/tunnel communication ¶[506] connection setup across networks) Referring to claim 17, Shribman teaches the method according to claim 1, wherein at least part of the communication over the Internet by the client device is based on, uses, or is compatible with, Transmission Control Protocol over Internet Protocol (TCP/IP) protocol or connection (see ¶ [004]-[016], TCP/IP stack). Referring to claim 18, Shribman teaches the method according to claim 17, wherein at least part of the communication over the Internet by the client device, is based on, uses, or is compatible with, HTTP or HTTPS protocol or connection, wherein the client device serves as an HTTP or HTTPS client (see ¶ [021], HTTP request-response [084], browser retrieves content). Referring to claim 19, Shribman teaches the method according to claim 17 and discloses communication between client device and servers over a TCP/IP based network (¶ [004]-[005], [021]), Shribman does not expressly mentions SOCKs protocol. However, Socks is well-known proxy protocol that operates over TCP/IP to facilitate communication between a client and a server. Shribman can be modified to wherein the at least part of the communication over the Internet by the client device, is based on, uses, or is compatible with, Socket Secure (SOCKS) protocol or connection, wherein the client device serves as a SOCKS client (TCP/IP communication). It would have been obvious to a person having ordinary skills in the art to implement the communication of Shribman using SOCKS protocol as one of many known transport or proxy-layer communication. Referring to claim 20, Shribman 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 (¶ [004]-[005], [021] same rationales as claim 19). Referring to claim 21, Shribman teaches the method according to claim 19, wherein the SOCKS protocol or connection is according to, based on, or is compatible with, IETF RFC 1928, IETF RFC 1929, IETF RFC 1961, or IETF RFC 3089 (¶ [004]-[005], [021] same rationales as claim 19 – Standard Socks specifications, selecting an implementation based on a particular RFC represent a routine design choice.). Referring to claim 22, Shribman teaches the method according to claim 1, wherein the request comprises a HyperText Transfer Protocol (HTTP) request (See ¶ [563], http://www.ip2 location.com). Referring to claim 23, Shribman teaches the method according to claim 22, wherein the request comprises a HTTP Secure (HTTPS) request (see ¶ [085], [561], see HTTP Secure request) Referring to claim 24, Shribman teaches the method according to claim 1, further comprising storing, operating, or using an operating system (see ¶ [030], [033], operating system). Referring to claim 25, Shribman teaches the method according to claim 24, wherein the operating system is a mobile operating system (see ¶[033], mobile operating system). Referring to claim 26, Shribman teaches the method according to claim 1, wherein the sending of the second message comprises periodically sending, by the client device, a second message that comprises a status of the client device, or is in response to the status of the client device (¶[546], heartbeat message indicating availability ¶[547], state/congestion messages). Referring to claim 27, Shribman teaches the method according to claim 1, further comprising sending, by the client device over the Internet, an 'heartbeat' message, and wherein a time period between two consecutive 'heartbeat' messages (¶[157], heartbeat messages) sent is at least 10 milliseconds, 20 milliseconds, 30 milliseconds, 50 milliseconds, 100 milliseconds, 1 second, 2 seconds, 3 seconds, 5 seconds, 10 seconds, 20 seconds, 30 seconds, 50 seconds, or 100 seconds, 1 minute, 2 minutes, 3 minutes, minutes 5, or 10 minutes (see ¶ [443], [472], [443]).. Referring to claim 28, Shribman teaches the method according to claim 1, wherein the content includes, consists of, or comprises, a part or whole of a computer files, audio data, voice data, multimedia data, video data, a computer program, or any combination thereof (see ¶[075], audio video data). Referring to claim 29, Shribman teaches the method according to claim 1, wherein the client device comprises a mobile device that is housed in a single enclosure that is a hand-held enclosure or a portable enclosure (see ¶ [089], handheld devices). Referring to claim 30, Shribman teaches the method according to claim 29, wherein the mobile device comprises, is part of, or is integrated with, at least one of a notebook-computer, a laptop computer, a media player, a Digital Still Camera (DSC), a Digital video Camera (DVC or digital camcorder), a Personal Digital Assistant (PDA), a cellular telephone, a digital camera, or a video recorder ([159], mobile device is PDA). Referring to claim 31, Shribman teaches the method according to claim 29, wherein the mobile device comprises, is part of, or is integrated with, a smartphone ([609], such as being a laptop, a desktop, a smartphone, or a mobile device). Referring to claim 32. Shribman teaches the method according to claim 31, wherein the smartphone comprises, or is based on, an Apple iPhone 6 or a Samsung Galaxy S6 (see ¶ [033], [282], Apple Iphone). Referring to claim 33, Shribman teaches the method according to claim 1, wherein the client device is part of, integrated with, or comprises, a household appliance ([030], [033], [282], Apple IOS on apple client devices). Referring to claim 34, Shribman teaches the method according to claim 33, wherein a primary functionality of the appliance is food storage, handling, or preparation (see ¶ [715], appliance is kitchen appliance). Referring to claim 35, Shribman teaches the method according to claim 34, wherein a primary function of the appliance is heating food, and wherein the appliance is a microwave oven, an electric mixer, a stove, an oven, or an induction cooker (¶ [715], microwave oven). Referring to claim 36, Shribman teaches the method according to claim 34, wherein the appliance is a refrigerator, a freezer, a food processor, a dishwasher, a food blender, a beverage maker, a coffeemaker, or an iced-tea maker (¶ [715], freezer). Referring to claim 37, Shribman teaches the method according to claim 33, wherein a primary function of the appliance is environmental control, and the appliance consists of, or is part of, an HVAC method (¶[572], cooling equipment (such as air conditioners)). Referring to claim 38, Shribman teaches the method according to claim 37, wherein a primary function of the appliance is temperature control, and wherein the appliance is an air conditioner or a heater (¶[572], cooling equipment (such as air conditioners)). Referring to claim 39, Shribman teaches the e method according to claim 33, wherein a primary function of the appliance with cleaning, wherein the primary function is associated with clothes cleaning, and the appliance is a washing machine or a clothes dryer, or wherein the appliance is a vacuum cleaner (see ¶ [715], washing machine). Referring to claim 40, Shribman teaches the method according to claim 33, wherein a primary function of the appliance is associated with water control or water heating (see ¶ [715], water heater) Referring to claim 41, Shribman teaches the method according to claim 33, wherein the appliance is an answering machine, a telephone set, a home cinema method, a HiFi method, a CD or DVD player, an electric furnace, a trash compactor, a smoke detector, a light fixture, or a dehumidifier (see ¶ [715], HiFi or home cinema). Referring to claim 42, Shribman teaches the method according to claim 33, wherein the appliance is a battery-operated portable electronic device, and the appliance is a notebook, a laptop computer, a media player, a cellular phone, a Personal Digital Assistant (PDA), an image processing device, a digital camera, a video recorder, or a handheld computing device (¶ [720], PDA devices). Referring to claim 43, Shribman teaches the method according to claim 1, wherein the client device is a wearable device that is shaped for permanently or releseably being attachable to, or be part of, a clothing piece of a person (client wearable device is inherent and obvious over Shribman [031). Referring to claim 44, Shribman teaches the method according to claim 1, for use with a Domain Name System (DNS) server, wherein the request comprises a content identifier that comprises a domain name, the method further comprising performing, by the client device using the DNS server, a DNS resolution for obtaining a numerical IP address (¶ [155], Domain name System (DNS) queries that contains a communication device for resolving DNS queries). Referring to claim 45, Shribman teaches the method according to claim 1, wherein the first network uses, or comprises, a Wireless Local Area Network (WLAN) (see [594], WLAN, [159], [160]). Referring to claim 46, Gupta teaches the method according to claim 45, wherein the WLAN is according to, compatible with, or is based on, a standard selected from the group consisting of IEEE 802.11-2012, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, and IEEE 802.11ac (see ¶[142], network access identifier indicate type of network e.g. WLAN where IEEE 802.11 variants = standard implementation of WLAN). Referring to claim 47, Gupta teaches the method according to claim 1, wherein the first network is a Third Generation (3G) network that uses UMTS W-CDMA, UMTS HSPA, UMTS TDD, CDMA2000 1xRTT, CDMA2000 EV-DO, or GSM EDGE-Evolution (see ¶ [142], network type identification). Referring to claim 48, Gupta teaches the method according to claim 1, wherein the first network is a Fourth Generation (4G) network that uses HSPA+, Mobile WiMAX, LTE, LTE-Advanced, MBWA, or is based on IEEE 802.20-2008 (see ¶ [142]). Referring to claim 49, Gupta teaches the method according to claim 1, wherein the first network is based on, or uses, IEEE 802.16, 802.16d, 802.16e, 802.20, or 802.21 standard (network identification, IEEE Standards = known implementation). Referring to claim 50, Shribman teaches the method according to claim 1, wherein the first network uses, or comprises, a Wireless Personal Area Network (WPAN) (see ¶[159], [594], WPAN). Referring to claim 51, Shribman teaches the method according to claim 50, wherein the WPAN is according to, compatible with, or based on, Bluetooth, Bluetooth Low Energy (BLE), or IEEE 802.15.1-2005 standard, or wherein the WPAN is a wireless control network that is according to, or based on, IEEE 802.15.4-2003 standards (see ¶[159], [594], WPAN). Referring to claim 52, Shribman teaches the method according to claim 1, further comprising storing, operating, or using, by the client device, a web browser (¶ [084]-[086], a web browser). Referring to claim 53, Shribman teaches the method according to claim 52, wherein the web browser is a mobile web browser ([030], mobile operating system has a mobile web browser). Referring to claim 54, Shribman teaches the method according to claim 53, wherein the mobile web browser consists of, comprises, or is based on, Android web browser (¶ [020],[031] web browser based on Android OS). Referring to claim 55, Shribman teaches the method according to claim 1, wherein the determining comprises sensing or metering, by the client device, a value associated with a resource in the client device, and wherein the idling criterion is met according to, or based on, the sensed or metered value (¶[543], device monitors resource usage). Referring to claim 56, Shribman teaches the method according to claim 55, wherein the determining further comprises comparing the value to a threshold, and wherein the idling criterion is met according to, or based on, the value being above the threshold (see ¶ [279], “over a certain threshold”). Referring to claim 57, Shribman teaches the method according to claim 55, wherein the determining further comprises comparing the value to a threshold, and wherein the idling criterion is met according to, or based on, the value being below the threshold (¶ [277], data paths estimated performance are below a threshold).. Referring to claim 58, Shribman teaches the method according to claim 55, wherein the sensing or metering respectively comprises periodically or continuously sensing or metering (see ¶ [547] the congestion state is periodically checked). Referring to claim 59, Shribman teaches the method according to claim 55, wherein the sensing or monitoring is at least every 10 milliseconds, 20 milliseconds, 30 milliseconds, 50 milliseconds, 100 milliseconds, 1 second, 2 seconds, 3 seconds, 5 seconds, 10 seconds, 20 seconds, 30 seconds, 50 seconds, or 100 seconds, 1 minute, 2 minutes, 3 minutes, 5 minutes, or 10 minutes (see ¶ [443], [472], [443]). Referring to claim 60, Shribman teaches the method according to claim 55, wherein the resource comprises an input device for obtaining an input from a human user or operator, and wherein the sensing comprises sensing an input from a human user or operator [668]. Referring to claim 61, Shribman teaches the method according to claim 60, wherein the input device comprises a touchscreen, a microphone, a pointing device, or a keyboard (see ¶ [030], [031], [033], other features, including a touchscreen). Referring to claim 62, Shribman teaches the method according to claim 60, wherein the sensing of the input device comprises periodically or continuously sensing of the input (see ¶ [547] the congestion state is periodically checked). Referring to claim 63, Shribman teaches the method according to claim 55, wherein the value comprises a utilization level of the resource (see ¶ [279], [543], utilization level of the resource). Referring to claim 64, Shribman teaches the method according to claim 63, wherein the resource comprises a processor or memory (see ¶ [038], processor [039], [041]). Referring to claim 65, Shribman teaches the method according to claim 55, wherein the resource comprises a motion sensor for sensing motion, acceleration, vibration, or location change of the client device (see ¶ [031], using vibration capabilities). Referring to claim 66, Shribman teaches the method according to claim 65, wherein the motion sensor comprises an accelerometer, gyroscope, vibration sensor, or a Global Positioning System (GPS) receiver (See ¶ [159], GPS [453], [564]). Referring to claim 67, Shribman teaches the method according to claim 55, wherein the resource comprises a rechargeable battery that powers the client device, and wherein the sensing or metering comprises sensing a charging level of the rechargeable battery (¶[070], IO Manager 435 capable of sensing power and charging level). Referring to claim 68, Shribman teaches the method according to claim 1, further comprising operating, by the client device, an operating system or a program process or thread, and 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 (see ¶ [543], device state based on conditions, OS process based Idling is standard). Referring to claim 69, Shribman teaches the method according to claim 68, wherein the process or thread comprises a low-priority or background task, an idle process, or a screensaver (¶ [722], executing in foreground and/or background, executing in the user and/or operating system address spaces). Referring to claim 70, Shribman teaches the method according to claim 68, wherein the process or thread comprises using an entire screen for displaying ( [071], displaying GUI to the user). Referring to claim 71, Shribman teaches the method according to claim 68, further comprising monitoring or metering, a resource utilization, and wherein the idling condition is determined to be met based on, or according to, the monitored or metered resource utilization being under a threshold (¶ [277], data paths estimated performance are below a threshold). Referring to claim 72, Gupta teaches the method according to claim 55, wherein the first network is provided by an Internet Service Provider (ISP) or an Autonomous System Number (ASN) (see ¶ [142] network identification), Referring to claim 73, Shribman teaches the method according to claim 72, wherein the value comprises a name or an identifier of the ISP or the ASN number (see ¶ [097], [098], [099], multiple ISP). Referring to claim 74, Shribman teaches the method according to claim 1, wherein at least part of steps are included in a Software Development Kit (SDK) that is provided as a non-transitory computer readable medium containing computer instructions, and wherein the method further comprising installing the SDK (¶[067], SDK that is provided as Non-transitory CRM). Referring to claim 75, Shribman teaches the method according to claim 1, further for use with a plurality of servers that includes the first server, each of the plurality of servers is connectable to the Internet and is addressable in the Internet using a respective IP address, the method further comprising selecting, by the client device, the first server from the plurality of servers ¶[268], multiple peers . Referring to claim 76, Shribman teaches the method according to claim 75, wherein the first server is randomly selected from the plurality of servers ([219], “The second device may be randomly selected out of the devices in the group”). Referring to claim 77, Shribman teaches the method according to claim 76, wherein the first server is randomly selected using one or more random numbers generated by a random number generator (see ¶ [108], [194], [201], [219], random number generator). Referring to claim 78, Shribman teaches the method according to claim 77, wherein the random number generator is hardware based (¶[234], “The random number generator may be hardware based”). Referring to claim 79, Shribman teaches the method according to claim 78, wherein the random number generator is using thermal noise, shot noise, nuclear decaying radiation, photoelectric effect, or quantum phenomena (¶ [108], [201], [234], such as thermal noise, shot noise, nuclear decaying radiation, photoelectric effect or other quantum phenomena). Referring to claim 80, Shribman teaches the method according to claim 77, wherein the random number generator is software based (¶[451], algorithm is software). Referring to claim 81, Shribman teaches the method according to claim 80, wherein the random number generator is based on, or comprises, executing an algorithm for generating pseudo-random numbers (see ¶ [108], [194], [201], [219],[451], executing an algorithm for generating pseudo-random numbers which approximates the properties of random numbers). 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 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
Read full office action

Prosecution Timeline

Jun 26, 2024
Application Filed
Apr 07, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12652330
System and Method for Improving Content Fetching by Selecting Tunnel Devices
2y 3m to grant Granted Jun 09, 2026
Patent 12621272
Systems and Methods for Locally Private Non-Interactive Communications
3y 4m to grant Granted May 05, 2026
Patent 12587579
SELECTING PROXY DEVICE BASED ON HARDWARE RESOURCE UTILIZATION
3y 3m to grant Granted Mar 24, 2026
Patent 12574440
MEDIA CONTENT MANAGEMENT
2y 2m to grant Granted Mar 10, 2026
Patent 12574356
BANDWIDTH CONTROLLED MULTI-PARTY JOINT DATA PROCESSING METHODS AND APPARATUSES
2y 5m to grant Granted Mar 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
80%
Grant Probability
99%
With Interview (+49.7%)
3y 2m (~1y 2m remaining)
Median Time to Grant
Low
PTA Risk
Based on 456 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month