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-111 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 and 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.
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.
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)).
Claims Objections
Regarding claim 1, Claim 1 is objected to under 35 USC 112b as being indefinite because it recites that client device is configured to be in “Idle condition is met” and “Non-Idle” states and further recites shifting to or staying in such states based on whether user inputs is sensed during pre-determined time interval. 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. An ordinary artisan cannot reasonably determine when the claimed method is operating in one state vs the other. Appropriate corrections are required.
Claims 13 and Claim 77 are duplicate and refer to substantially Identical subject matter.
Claims 14, 78, are duplicate while claim 76 is partially overlapping.
Claims 15 and 79 both recite communication compatible with SOCKS…
Claim 16 and claim 80 both recite same subject matter are therefore duplicate.
Claim 17, and 81 are duplicate both recite same subject matter.
Claim 18 and claim 82 both recite same subject matter are therefore duplicate.
Claims 46, 86, 98 both recite same subject matter are therefore duplicate.
Claims tree 54-60 & Claim tree 61-67 both recite plurality of servers, random server selection, Hardware RNG, thermal noise, software RNG, Therefore claims 62-67 duplicate the structure of claims 55-60.
Claims 89-97, recite Food Appliance, HVAC, Cleaning, Water Control, Media Services, All depend from claim 1 and only vary by appliance category. Not exactly duplicate but are pure category padding without any patentable weight.
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-14, 18-84 and 86-111 are rejected under 35 U.S.C. § 103 as being unpatentable over Nirantar (US pub, 2015/0131438A1) in view of Shribman (US pub, 2016/0105530 A1)
Referring to claim 1, Nirantar teaches a method for fetching a content identified by a content identifier from a web server by using an appliance that comprises a network interface or a network transceiver for communication over a network, for use with first and second servers (Nirantar (¶[0032], ¶[0038]; Fig. 1B–1E architecture) teaches a mobile device including a network interface and client-side proxy communicating with server-side proxies and application servers over wireless and IP networks) and the appliance that are each connected to the Internet and are each addressable in the Internet using a respective IP address, the appliance is configured to be in at least an idle state and a non-idle state (Nirantar teaches radio and device operational states including idle and connected/high-power states, and transitions between them based on traffic and user activity (¶[0002], ¶[0036]), the method by the appliance comprising:
metering, an amount of data transmitted to, or received from, the network during a time interval (Nirantar ¶[0033]–¶[0035]), teaches observing TCP streams, detecting transactions, identifying keepalive and background traffic using periodicity, size thresholds, and traffic pattern analysis, which constitutes metering and evaluating transmitted data over time);
determining, if an idling condition is met, in response to being in the non-idle states (Nirantar: ¶[0032], ¶[0035], ¶[0039] teaches determining when sockets and applications are idle based on idle periods, timing thresholds, and keepalive periodicity parameters, and using such thresholds to trigger scheduling and blocking decisions);
shifting to the idle state in response to the determination that the idling condition is met (Nirantar : ¶[0036], teaches that the client-side proxy communicates user activity and traffic characteristics to server-side proxy components and adjusts communication frequency and behavior based on detected idle conditions ~ This constitutes sending state/traffic status information to a server when entering idle-type conditions);
sending, to the first server, a first status message in response to shifting to the idle state (¶[0038]–¶[0040] Client Proxy communicates activity characteristics to server side proxy; Adjust communication frequency based on idle behavior ~ This involves sending status/activity information to server when idle condition occurs);
determining if an idling condition is met in response to being in the idle state (Nirantar: ¶ [0034]-[0036] continues monitoring traffic even when in Idle)
shifting to the non-idle state in response to the determination that the idling condition is not met ([0036], [0038], Resumes communication when interactive traffic appears);
sending, to the first server, a second status message in response to shifting to a non-idle state (Nirantar: ¶[0036], ¶[0038]–¶[0040] teaches resuming or triggering communications when user-interactive or non-keepalive traffic appears and requesting server data delivery following idle periods, adjust communication when interactive activity resumes);
wherein the idling condition is determined to be met based on, or according to, the metered amount of data being over or under a threshold level (Nirantar: ¶[0035], see explicit threshold based logic)
Nirantar teaches traffic based idle determination, threshold based state transition and communication with a server in response to detected device state along with application level traffic between device and servers but does not emphasize URL based content identifier and lacks receiving, from the first or second server, a first message that comprises the content identifier;
However, Shribman teaches receiving, from the first or second server, a first message that comprises the content identifier (Fig. 28, see URL Column); Shribman teaches sending, to the web server, a content request that comprises the content identifier (¶[0004] – [006], client requests content via URL to server (i.e. HTTP over TCP/IP);
receiving, from the web server, the content, in response to the content request (Shribman see Figs, 6-7, Architecture teaches distributed content fetch, chunk slicing and server delivery); and
sending, to the first or second server, the content (see Shribman ¶ [0002], Intermediate node forwarding, tunnel based content relay),
It would have been obvious to an ordinary person skilled in the art at the time of the invention to implement the traffic aware proxy device of Nirantar using the distributed content retrieval and forwarding architecture of Shribman in order to enable efficient-server directed content retrieval and forwarding through intermediate nodes. Combining Nirantar’s idle-aware traffic management system with Shribman’s well known content retrieval and relay techniques would merely apply known intermediate content fetching functionality to a known traffic-optimized proxy device yielding results.
Referring to claim 2, Shribman teaches the method according to claim 1, wherein the first message is received from the first server, and the content is sent to the second server in response to the first message (Shribman: [002]-[006], Fig. 5a-7, Fig. 28, teaches client/server intermediate node receiving a request (e.g. URL or content identifier) from one server or endpoint and forwarding retrieved content to another endpoint -distributed content retrieval and forwarding architecture- Intermediate nodes relay content between network entities)
Referring to claim 3, Shribman teaches the method according to claim 1, wherein the appliance is addressable in the Internet using a first IP address, the method further comprising sending, to the first server, a second message that comprises at least one value with one attribute type associated with the appliance (Shribman: Fig. 28 table including IP, BW, RTT, Shribman explicitly teaches IP address field, Server IP, Tunnel IP, Bandwidth Values, RTT, values, Timestamps. It would have been obvious to transmit such device attribute information within Nirantar proxy communication framework).
Referring to claim 4, Shribman teaches the method according to claim 3, further comprising establishing a connection with the first server, and wherein the method further comprising responding, to a communication initiated by the first server using the established connection (see ¶ [007], [015], [022], [192], [204], establishing a connection to server and communicating over the established connection).
Referring to claim 5, Shribman teaches the method according to claim 4, wherein the established connection is a TCP connection that uses a three-way handshake that involves ‘Active OPEN’, ‘Passive OPEN’, or TCP keepalive mechanism (¶[009]- [010], [014], [237], [281], see multiple types connections, including ACTIVE OPEN, Passive Open)
Referring to claim 6, Shribman teaches the method according to claim 4, wherein the established connection uses a Virtual Private Network (VPN). (see ¶ [112], [113] [430], VPN network)
Referring to claim 7, Shribman teaches the method according to claim 1, wherein the sending, to the first or second server of the content comprises exclusively sending, to the first server, the content; or exclusively sending, to the second server, the content (Shribman [430], teaches forwarding content to selected endpoints, selection of one destination vs another in a routing decision. Choosing to send exclusively to one end point in a matter of routing configuration and would have been obvious).
Referring to claim 8, Shribman teaches the method according to claim 1, wherein the first message comprises the IP address of the second server (Shribman Fig. 28, showing IP address field including IP destination with a message header in a fundamental TCP/IP routing behavior).
Referring to claim 9, Shribman teaches the method according to claim 1, further comprising in response to the receiving of the first message, initiating a communication, with the second server (see ¶ [185], [188], [204], [232], [236], Shribman teaches receiving requests containing server addresses (URL/IP) then initiating communication with a data server to retrieve content thus reactive initiation of communication is expressly taught).
Referring to claim 10, Shribman teaches the method according to claim 9, wherein the initiating of the communication uses a Network Address Translator (NAT) traversal scheme (see ¶ [119], [186], Gateway performing Network address translation - NAT) .
Referring to claim 11, Shribman teaches the method according to claim 10, wherein the NAT traversal 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 ([119], use Simple Traversal of UDP over NAT (STUN), a protocol defined in RFC 3489 that allows a client behind a NAT router to find out its external IP address and the type of NAT device).
Referring to claim 12, Shribman teaches the method according to claim 10, wherein the NAT traversal 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 ¶ [119], use Simple Traversal of UDP over NAT (STUN), a protocol defined in RFC 3489 that allows a client behind a NAT router to find out its external IP address and the type of NAT device).
Referring to claim 13, Shribman teaches the method according to claim 1, wherein the communication over the Internet with the first or second server, is based on, uses, or is compatible with, Transmission Control Protocol over Internet Protocol (TCP/IP) protocol or connection (see ¶ [005], [008], [009], using TCP/IP)
Referring to claim 14, Shribman teaches the method according to claim 1, wherein the communication over the Internet with the first or the second server uses HTTP or HTTPS protocol or connection, and wherein the first or second server serves as an HTTP or HTTPS server and the appliance respectively serves as an HTTP or HTTPS client (see [561], [563], [568], HTTS communication connection).
Referring to claim 18, Shribman teaches the method according to claim 1, wherein the communication over the Internet with the first or second server, is based on, uses, or is compatible with, HTTP Proxy protocol or connection, wherein the first or second server serves as an HTTP Proxy server and the appliance serves as an HTTP Proxy client (see ¶ [022], HTTP proxy servers utilize communication over the internet with first or second sever).
Referring to claim 19, Nirantar teaches the method according to claim 1, further comprising operating, 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 ¶[034]-[035], Categorizing background vs. user-interactive traffic).
Referring to claim 20, Nirantar teaches the method according to claim 19, wherein the process or thread comprises a low-priority or background task, an idle process, or a screensaver (¶[032]-035], Background transaction optimization).
Referring to claim 21, Shribman teaches the method according to claim 19, wherein the process or thread comprises using an entire screen for displaying (see ¶ [084] [085], [087], [088],)
Referring to claim 22, Shribman teaches the method according to claim 1, 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 (¶[144], Bandwidth Definition, see ¶ RTT definition [145] – [146], BW/RTT Selection Logic).
Referring to claim 23, Nirantar teaches the method according to claim 22, wherein the resource utilization comprises the utilization or a processor in the appliance (see [002]-[003] – Resource conservation on mobile device).
Referring to claim 24, Nirantar teaches the method according to claim 1, wherein the appliance comprises an input device for obtaining an input from a human user or operator, the method further comprising sensing, using the input device, the input, and wherein the idling condition is determined to be met based on, or according to, not receiving an input from the input device for a pre-set time interval [033], Transaction identified based on idle periods).
Referring to claim 25, Shribman teaches the method according to claim 24, wherein the input device comprises a pointing device, a keyboard, a touchscreen, or a microphone (see ¶[039], [061], [063], [128], [129], Keyboard).
Referring to claim 26, Nirantar teaches the method according to claim 1, wherein the appliance comprises a motion sensor for sensing motion, acceleration, vibration, or location change of the appliance, the method further comprising sensing, using the motion sensor, an appliance motion, acceleration, vibration, or location change, and wherein the idling condition is determined to be met based on, or according to, respectively sensing the motion, the vibration, the acceleration, or the location change being under a threshold (see ¶ [036], [054] [058], Mobile device radio state/device state transitions).
Referring to claim 27, Shribman teaches the method according to claim 26, wherein the motion sensor comprises an accelerometer, gyroscope, vibration sensor, or a Global Positioning System (GPS) receiver (see ¶ [018], [159], [453], [672], GPS).
Referring to claim 28, Nirantar teaches the method according to claim 1, wherein the appliance comprises a battery, the method further comprising metering or sensing, a battery charging level, and wherein the idling condition is determined to be met based on, or according to, the metered or sensed charge level being over a threshold level (see ¶ [002]-[003], Battery charge level threshold ~ Battery consumption and radio state optimization) .
Referring to claim 29, Nirantar teaches the method according to claim 28, wherein the metering or sensing uses a Battery Management System (BMS) (see ¶ [053], [097],[100], Battery consumption based on BMS).
Referring to claim 30, Shribman teaches the method according to claim 28, wherein the threshold level of the metered or sensed charge level is above either 40%, 50%, 60%, 70%, 80%, or 90% of the battery defined full charge capacity ([0700], Threshold-based BW/RTT evaluation logic).
Referring to claim 31, Shribman teaches the method according to claim 1, wherein the appliance is associated with a first value relating to a first attribute type (¶ [701], [702], Database storing IP, BW, RTT attributes).
Referring to claim 32, Shribman teaches the method according to claim 31, wherein the first value comprises a numeric value or an identifier of a feature, a characteristic, or a property of the first attribute type (see [701]-[702], Client evaluating and using BW/RTT values).
Referring to claim 33, Shribman teaches the method according to claim 31, further comprising sending, to the first server, the first value to the first server ([196], “sending a first request to the first server”).
Referring to claim 34, Shribman teaches the method according to claim 31, further for use with a second attribute type, and wherein the appliance is associated with a second value relating to the second attribute type, and wherein the method further comprising, sending, to the first server, the second value (see ¶ [258], see attributes [219, [222], [701], Database storing IP addresses of sources)
Referring to claim 35, Shribman teaches the method according to claim 31, wherein the first attribute type comprises a geographical location, and wherein each of the first values comprises a name or an identifier of a continent, a country, a region, a city, a street, a ZIP code, or a time-zone (see ¶ [202], [219], [234], [257], [453], [563], [566])
Referring to claim 36, Shribman teaches the method according to claim 31, wherein the first value is based on IP geolocation (¶ [202], devices geolocation).
Referring to claim 37, Shribman teaches the method according to claim 36, wherein the geolocation is based on W3C Geolocation API (see ¶ [257], determining of the geographical location of each of the group devices may be based on a geolocation, such as based on W3C Geolocation API).
Referring to claim 38, Shribman teaches the method according to claim 36, for use with a database that associates IP addresses to geographical locations (see ¶[700], Source selection using BW/RTT evaluation).
Referring to claim 39, Shribman teaches the method according to claim 31, wherein the first attribute type comprises Internet Service Provider (ISP) or Autonomous System Number (ASN) (see ¶ [701], Database storing IP, BW, RTT Values).
Referring to claim 40, Shribman teaches the method according to claim 39, wherein the first value comprises a name or an identifier of the ISP or the ASN number (see ¶ [235], [701], IP sorted database).
Referring to claim 41, Shribman teaches the method according to claim 31, wherein the first attribute type corresponds to a hardware or software of the appliance (see ¶ [702]- ¶[703], Estimation of BW/RTT using adjacent entries)
Referring to claim 42, Shribman teaches the method according to claim 41, wherein the first attribute type comprises the hardware of the appliance (see ¶ [700], Comparison of P1 and P2 based on BW/RTT)
Referring to claim 43, Shribman teaches the method according to claim 42, wherein the first values comprise stationary or portable values, respectively based on the appliance being stationary or portable(see ¶ [701], client database stored on client device performs evaluation locally).
Referring to claim 44, Shribman teaches the method according to claim 41, wherein the first attribute type comprises a software application that is used by the appliance(see ¶ [002], [715], Using intermediate nodes for communication improvement) .
Referring to claim 45, Shribman teaches the method according to claim 44, wherein the first values comprise the type, make, model, or version of the software (see ¶ [065], versions & models [002], device functions as both end-user and intermediate node).
Referring to claim 46, Shribman teaches the method according to claim 44, wherein the software comprises an operating system (see ¶ [024], software includes operating system).
Referring to claim 47, Shribman teaches the method according to claim 31, wherein the first attribute type corresponds to a communication property, feature of a communication link of the appliance (see ¶ [144], bandwidth is a feature of communication link of the appliance).
Referring to claim 48, Shribman teaches the method according to claim 47, wherein the communication link corresponds to the connection to the Internet of the appliance (see ¶ [007] – [010], communication connection to the internet of the appliance).
Referring to claim 50, Shribman teaches the method according to claim 47, wherein the first attribute type corresponds to a bandwidth (BW) or Round-Trip delay Time (RTT) of the communication link, and the first value is the respective estimation or measurement of the BW or RTT (see ¶ [144], Bandwidth definition [145]-[146] RTT Definition, [700], BW/RTT estimation example).
Referring to claim 51, Shribman teaches the method according to claim 50, further comprising estimating or measuring, the BW or RTT of the communication link (see ¶ [700] – [703], client estimating BW/RTT before transaction).
Referring to claim 52, Shribman teaches the method according to claim 47, wherein the first attribute type corresponds to a technology or scheme used by the appliance for connecting to the Internet (see ¶ [004]-[006], see TCP/IP protocol description).
Referring to claim 53, Shribman teaches the method according to claim 52, wherein the first values comprise wired or wireless values, respectively based on the appliance being connected to the Internet using wired or wireless connection (see ¶ [004], Internet comprising various networking technologies)
Referring to claim 54, 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, addressable in the Internet using a respective IP address, the method further comprising selecting, the first server from the plurality of servers (see ¶ [700], client selecting between multiple sources).
Referring to claim 55, Shribman teaches the method according to claim 54, wherein the first server is randomly selected from the plurality of servers (see ¶ [700], selection between multiple available sources)
Referring to claim 56, Shribman teaches the method according to claim 55, wherein the first server is randomly selected using one or more random numbers generated by a random number generator (see ¶ [700], selection logic performed at the client device)
Referring to claim 57, Shribman teaches the method according to claim 56, wherein the random number generator is hardware based (see ¶ [194], [201], [219], using random number generator)
Referring to claim 58, Shribman teaches the method according to claim 57, wherein the random number generator is using thermal noise, shot noise, nuclear decaying radiation, photoelectric effect, or quantum phenomena (see ¶ [108], [201], [234], The random number generator may be hardware based, and may be using thermal noise, shot noise, nuclear decaying radiation, photoelectric effect, or quantum phenomena)
Referring to claim 59, Shribman teaches the method according to claim 56, wherein the random number generator is software based(see ¶ [234], the random number generator may be software based)
Referring to claim 60, Shribman teaches the method according to claim 59, wherein the random number generator is based on executing an algorithm for generating pseudo-random numbers (see ¶ [451], algorithm for generating pseudo-random numbers which approximates the properties of random numbers. ¶[647]).
Referring to claim 61, 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, addressable in the Internet using a respective IP address, the method further comprising: selecting, the first server from the plurality of servers (see ¶ [700], selecting best source and performing transaction); and sending, to the selected first server, a second message (see ¶ [700], selecting best source and performing transaction);
Referring to claim 62, Shribman teaches the method according to claim 61, wherein the first server is randomly selected from the plurality of servers (see ¶ [700], Random selection among multiple peers – also see [108]).
Referring to claim 63, Shribman teaches the method according to claim 62, wherein the first server is randomly selected using one or more random numbers generated by a random number generator (see ¶ [201], [219], generated by a random number generator).
Referring to claim 64, Shribman teaches the method according to claim 63, wherein the random number generator is hardware based (see ¶ [201], [234], [451], the random number generator may be hardware based)
Referring to claim 66,. Shribman teaches the method according to claim 64, wherein the random number generator is using thermal noise, shot noise, nuclear decaying radiation, photoelectric effect, or quantum phenomena (see ¶ [201], [234], [451], The random number generator may be hardware based using thermal noise, shot noise, nuclear decaying radiation, photoelectric effect, or quantum phenomena).
Referring to claim 66, Shribman teaches the method according to claim 63, wherein the random number generator is software based (see ¶ [451], the generation of the random numbers can be software based).
Referring to claim 67, Shribman teaches the method according to claim 66, wherein the random number generator is based on executing an algorithm for generating pseudo-random numbers (see ¶ [108], an algorithm for generating pseudo-random numbers which approximates the properties of random numbers)
Referring to claim 68, Shribman teaches the method according to claim 67, wherein each of the plurality of servers is associated with a one of more attribute values relating to an attribute type, and wherein the first server is selected from the plurality of servers based on, or according to, the respective one of more attribute values (see ¶ [179], servers are associated with one or more values).
Referring to claim 69, Shribman teaches the method according to claim 68, wherein the attribute type is a geographical location, and wherein one of more attribute values comprise a name or an identifier of a continent, a country, a region, a city, a street, a ZIP code, or a time zone (see ¶ [257], [453], [563], IP address based location data may include information such as country, region, city, postal/zip code, latitude, longitude, or Time zone).
Referring to claim 70, Shribman teaches the method according to claim 69, wherein the one of more attribute values is based on actual geographical location or on IP geolocation (see ¶ [567], based on actual geographical distance between devices, where shorter distance indicates closer devices).
Referring to claim 71, Shribman teaches the method according to claim 70, wherein the geolocation is based on W3C Geolocation API (see ¶ [257], The determining of the geographical location of each of the group devices may be based on a geolocation, such as based on W3C Geolocation API).
Referring to claim 72, Shribman teaches the method according to claim 68, wherein the first message comprises the one of more attribute values (see ¶ [568], requesting device associates attribute values).
Referring to claim 73, Shribman teaches the method according to claim 1, for use with a Domain Name System (DNS) server, wherein the content identifier comprises a domain name, the method further comprising performing, using the DNS server, a DNS resolution for obtaining a numerical IP address, and wherein the first message or the content request comprises the obtained numerical IP address (see ¶ [155], [187] [508], DNS server and DNS resolution for obtaining a numerical IP address).
Referring to claim 74, Shribman teaches the method according to claim 1, wherein the content comprises a web-page or a web-site, and wherein the content identifier is Uniform Resource Identifier (URI) or Uniform Resource Locator (URL) (see ¶ [084], An information resource is identified by a Uniform Resource Identifier (URI/URL) and may be part of a web page, a web-page, an image, a video, or any other piece of content).
Referring to claim 75, Shribman teaches the method according to claim 1, wherein each of the IP addresses is in IPV4 or IPV6 form (see ¶ [015], [150], [151], [153], IPv4 and IPv6).
Referring to claim 76, Shribman teaches the method according to claim 1, wherein the web server uses HyperText Transfer Protocol (HTTP) or HTTP Secure (HTTPS) for responding to respective HTTP or HTTPS requests via the Internet, and wherein the content request is an HTTP or an HTTPS request (see ¶ [561], [563], HTTPs communication)
Referring to claim 77, Shribman teaches the method according to claim 1, wherein the communication over the Internet with the first or the second server, is based on, uses, or is compatible with, Transmission Control Protocol over Internet Protocol (TCP/IP) protocol or connection (see ¶ [718], performed using TCP/IP. Generally, HTTP and HTTPS are utilized on top of TCP/IP).
Referring to claim 78, Shribman teaches the method according to claim 1, wherein the communication over the Internet between with the first server or the second server, is based on, uses, or is compatible with, HTTP or HTTPS protocol or connection, wherein one of the nodes serves as an HTTP or HTTPS server respectively and the other node serves as an HTTP or HTTPS client respectively (see ¶ [005], HTTP encapsulated in TCP; [037], client server model where browser-client communicates with website server).
Referring to claim 82, Shribman teaches the method according to claim 1, wherein the communication over the Internet with the first or second server is based on, uses, or is compatible with, HTTP Proxy protocol or connection, wherein the respective first or second server serves as an HTTP Proxy server respectively and the appliance serves as an HTTP Proxy client (see ¶ [038], HTTP proxy servers facilitating communication).
Referring to claim 83, Shribman teaches the method according to claim 1, wherein the appliance is associated with a single IP address from a list stored in the first server (see ¶ [144], discusses IP addresses associated with devices and network communication).
Referring to claim 84, Shribman teaches the method according to claim 1, wherein the appliance is associated with multiple IP addresses from a list stored in the first server (see ¶ [142], [179], [258], IP addresses are list of IP addresses stored on a server)
Referring to claim 86, Shribman teaches the method according to claim 1, further comprising storing, operating, or using, a client operating system (see ¶ [282], client operating system).
Referring to claim 87, Nirantar teaches the method according to claim 1, further comprising storing, operating, or using, a web browser (see ¶ [030], a mobile device architecture including operating system components).
Referring to claim 88, Shribman teaches the method according to claim 87, wherein the web browser is a mobile web browser (see ¶ [039], mobile apps and mobile client environments).
Referring to claim 89, Shribman teaches the method according to claim 1, wherein a primary functionality of the appliance is food storage, handling, or preparation (see ¶ [715], microwave oven is food preparation appliance).
Referring to claim 90, Shribman teaches the method according to claim 89, 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 (see ¶ [715], microwave oven).
Referring to claim 91, Shribman teaches the method according to claim 89, 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 (see ¶ [715], dishwasher).
Referring to claim 92, Shribman teaches the method according to claim 1, wherein a primary function of the appliance is environmental control, and the appliance consists of, or is part of, an HVAC method (see ¶ [715], teaches plurality of appliances, being part of HVAC system would be have been obvious to an ordinary artisan).
Referring to claim 93, Shribman teaches the method according to claim 92, wherein a primary function of the appliance is temperature control, and wherein the appliance is an air conditioner or a heater (see ¶ [715], teaches plurality of appliances, being air conditioner or heater system would be have been obvious to an ordinary artisan).
Referring to claim 94, Shribman teaches the method according to claim 1, 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], see washing machine).
Referring to claim 95, Shribman teaches the method according to claim 1, wherein a primary function of the appliance is associated with water control or water heating (see ¶ [715], Water heater).
Referring to claim 96, Shribman teaches the method according to claim 1, 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], trash compactor)
Referring to claim 97, Shribman teaches the method according to claim 1, 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 (see ¶ [715], PDA).
Referring to claim 98, Shribman teaches the method according to claim 1, further comprising storing, operating, or using an operating system (see ¶ [618], [619], [721], [722], Operating Systems).
Referring to claim 99, Shribman teaches the method according to claim 98, wherein the operating system is a mobile operating system (see ¶ [030], mobile operating system)
Referring to claim 100, Shribman teaches the method according to claim 1, wherein the connecting to the Internet uses a wireless network (see ¶ [088], [098], [159], wireless networks)
Referring to claim 101, The method according to claim 100, wherein the wireless network comprises, or consists of, a Wireless Wide Area Network (WWAN) (see ¶ [159], [720], WWAN network).
Referring to claim 102, Shribman teaches the method according to claim 101, wherein the WWAN is a wireless broadband network (see ¶ [594], WWAN network)
Referring to claim 103, Shribman teaches the method according to claim 102, wherein the wireless network comprises, or consists of, a WiMAX network, and the WiMAX network is according to, compatible with, or based on, IEEE 802.16-2009 (see ¶ [004]-006], TCP/IP over internet framework enables use of WiMax or cellular network as transport medium constitutes a well-known alternative internet connectivity mechanism. Making it obvious use of well-known wireless networking standards).
Referring to claim 104, Shribman teaches the method according to claim 102, wherein the wireless network comprises, or consists of, a cellular telephone network (see ¶ [159], cellular network).
Referring to claim 105, Shribman teaches the method according to claim 104, wherein the cellular telephone network is 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 telephone network uses a protocol selected from the group consisting of a Fourth Generation (4G) network that uses HSPA+, Mobile WiMAX, LTE, LTE-Advanced, MBWA, or is based on IEEE 802.20-2008 (see ¶ [088], cellular network view Wireless LAN uses any of 3G or 4G protocol… this is obvious to an an ordinary artisan).
Referring to claim 106, Nirantar teaches the method according to claim 100, wherein the wireless network comprises, or consists of, a Wireless Personal Area Network (WPAN) (see ¶ [032], WPAN wireless local/mobile network context).
Referring to claim 107, Nirantar teaches the method according to claim 100, wherein the wireless network comprises, or consists of, a Wireless Local Area Network (WLAN) (see ¶ [032], Wireless local area network mention)
Referring to claim 108, Nirantar teaches the method according to claim 107, wherein the WLAN is compatible with IEEE 802.11-2012, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, or IEEE 802.11ac standard (see ¶ [0032] Wireless LAN context).
Referring to claim 109, Shribman teaches a non-transitory computer readable medium containing computer instructions that, when executed by a computer processor, cause the processor to perform the method according to claim 1 (see ¶ [263], non-transitory computer readable medium).
Referring to claim 110, Shribman teaches the method according to claim 1, further for use with in a Software Development Kit (SDK) that is provided as a non-transitory computer readable medium containing computer instructions that, when executed by a computer processor, cause the processor to perform the method according to claim 1 (see ¶ [067], SDK software).
Referring to claim 111, Shribman teaches the method according to claim 110, further comprising installing the SDK in the appliance (see ¶ [685], [686], [688] special program that installed on both the NE1).
Claims 15, 16, 17, 49, 79, 80, 81 are rejected under 35 U.S.C. § 103 as being unpatentable over Nirantar (US pub, 2015/0131438A1) in view of Shribman (US pub, 2016/0105530 A1) in further view of Preston (US pub, 2019/0026828 A1)
Referring to claim 15, Nirantar teaches traffic based idle determination, threshold based state transition and communication with a server in response to detected device state along with application level traffic between device and servers
Shribman teaches improving internet communication by using intermediate nodes.
Neither Nirantar nor Shribman expressly teaches wherein the communication over the Internet with the first or the second server uses Socket Secure (SOCKS) protocol or connection, and wherein the first or the second server serves as a SOCKS server and the appliance respectively serves as an SOCKS client.
However, Preston an analogous art in the same field of endeavor teaches distributed trading system. Furthermore, Preston teaches wherein the communication over the Internet with the first or the second server uses Socket Secure (SOCKS) protocol or connection (Fig. 4, SOCKS5 Proxy), and wherein the first or the second server serves as a SOCKS server and the appliance respectively serves as an SOCKS client (see Preston ¶ [075]-[077]).
It would have been obvious to an ordinary person skilled in the art at the time of the invention to implement the traffic aware proxy device of Nirantar using the distributed content retrieval and forwarding architecture of Shribman to further include SOCKS protocol connection in order to enable secure and efficient-server directed content retrieval and forwarding through intermediate nodes. Combining Nirantar’s idle-aware traffic management system with Shribman’s well known content retrieval utilizing secure SOCKs connection as taught by Preston for proper relay communication techniques would merely apply known intermediate content fetching functionality to a known traffic-optimized proxy device yielding optimal results..
Referring to claim 16, Preston teaches the method according to claim 15, wherein the SOCKS protocol or connection is compatible with SOCKS4, SOCKS4a, or SOCKS5 (Fig. 4, SOCKS5 Proxy).
Referring to claim 17, Preston teaches the method according to claim 15, wherein the SOCKS protocol is compatible with IETF RFC 1928, IETF RFC 1929, IETF RFC 1961, or IETF RFC 3089 (see ¶ [075] – [078]. SOCKS protocol are compatible with IETF RFC 1928, IETF RFC 1929, IETF RFC 1961, or IETF RFC 3089)
Referring to claim 49, Preston teaches the method according to claim 48, wherein the communication link corresponds to a communication link with the web server, the first server, or the second server (Fig. 7, illustrates a communication link with the Trade server, the first server A, or the second server B)
Referring to claim 79, Preston teaches the method according to claim 1, wherein the communication over the Internet with the first or second server is based on, uses, or is compatible with, Socket Secure (SOCKS) protocol or connection, wherein the respective first or second server serves as a SOCKS server respectively and the appliance serves as an SOCKS client (see ¶ [075]-[078], see internet communication over the internet).
Referring to claim 80, Preston teaches the method according to claim 79, wherein the SOCKS protocol or connection is according to, based on, or is compatible with, SOCKS4, SOCKS4a, or SOCKS5 (see Fig. 4, SOCKS5 proxy connection).
Referring to claim 81, Preston teaches the method according to claim 79, 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 (see ¶ [075] – [078]. SOCKS protocol are compatible with IETF RFC 1928, IETF RFC 1929, IETF RFC 1961, or IETF RFC 3089).
Claim 85 are rejected under 35 U.S.C. § 103 as being unpatentable over Nirantar (US pub, 2015/0131438A1) in view of Shribman (US pub, 2016/0105530 A1)
Referring to claim 85, Nirantar teaches traffic based idle determination, threshold based state transition and communication with a server in response to detected device state along with application level traffic between device and servers
Shribman teaches improving internet communication by using intermediate nodes.
Neither Nirantar nor Shribman expressly teaches list of IP addresses wherein the appliance is associated with more than 1,000, 2,000, 5,000, 10,000, 20,000, 50,000 or 100,000 multiple distinct IP addresses from the list.
However, wherein the appliance is associated with more than 1,000, 2,000, 5,000, 10,000, 20,000, 50,000 or 100,000 multiple distinct IP addresses from the list. (Design Choice)
It would have been obvious to an ordinary person skilled in the art at the time of the invention to implement the traffic aware proxy device of Nirantar using the distributed content retrieval and forwarding architecture of Shribman that would be design choice by an ordinary artisan in order to enable secure and efficient-server directed content retrieval and forwarding through intermediate nodes. Combining Nirantar’s idle-aware traffic management system with Shribman’s well known content retrieval utilizing long lists of distinct IP addresses for improving relay communication techniques and therefore would apply known intermediate content fetching functionality to a known traffic-optimized proxy device yielding optimal results.
It would have been obvious to an ordinary person skilled in the art at the time invention was made to modify Toksvig’s mobile device to be coupled with a multiple client server networks of Ly to enable proxy devices to communicate using direct client server connection. The combination of network devices would have been obvious to an ordinary artisan to include motion based idle and non-idling state determination of Toksvig into proxy based network communication and content delivery system as taught by Ly in order to optimize network communication behavior of a mobile device, reduce unnecessary network traffic and improve power efficiency and responsiveness.
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