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-90 are presented for examination.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 11/06/2024, 12/29/2024, 5/20/2025, 10/29/2025, 04/20/2026 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 04/12/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.
Drawings Objection
Drawings are objected to be being incomplete because claims 76-80 and specification paragraphs [382], [692] teach a wearable device but the drawing fails to show a graphic illustration or rendering of a such a device. See MPEP § 608.02(g). Corrected drawings in compliance with 37 CFR 1.121 (d) are required in reply to the Office action to avoid abandonment of the application. The replacement sheet(s) should be labeled "Replacement Sheet" in the page header (as per 37 CFR 1.84(c)) so as not to obstruct any portion of the drawing figures. If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claims Objections
Regarding claim 1, 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 26 and 75, Both claims appear to claim same client operating systems and are redundant Appropriate corrections are needed
Regarding claims 81-90, the claims recites limitations are directed laundry list of appliances that are directed to “intended use”. Claims 82-90 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 81 recite house hold appliances, food appliance, HVAC, cleaning electronics and portable device. 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 8, 9,11, 12, 13, 14, 15, 24, 30, 34, 36, 79 and 80 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.
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-75 and 81-90 are rejected under 35 U.S.C. § 103 as being unpatentable over Shribman et al (2016/0105530) in view of Boley (2013/0122918 A1).
Referring to claim 1, Shribman teaches a method for obtaining, by a client device that is configured to be in idle and non-idle states, a content that is identified by a content identifier and that is stored in a web server, for use with distinct first and second servers, the method comprising:
connecting, by the client device, to the Internet, via a first network that comprises a wireless network (¶[191], “content that may be fetched by the client devices via the Internet” [abs] client device connects to internet for fetching data);
selecting, by the client device, the first server from a plurality of servers (¶[427]-[428], a tunnel device (or multiple tunnel devices) is selected by the client device #1 31a in a ‘Tunnel Select’ step 53c (corresponding to a ‘Select Tunnel’ step 62c”);
establishing, by the client device with the selected first server over the Internet, a Transmission Control Protocol (TCP) connection ([022], An HTTP client initiates a request by establishing a Transmission Control Protocol (TCP) connection to a particular port on a server & [192], “establishing a Transmission Control Protocol (TCP) connection to a particular port on a server” [204], [237],[281]);
periodically measuring, by the client device, a data rate of communicating over the Internet (see ¶ [537], “ periodically, measures the various communication related characteristics for each communication with a peer device, such as BW and RTT, as part of a ‘Measure BW, RTT”);
when in the idle state (¶ [274], “when the network is idle….[403])”, receiving, by the client device from the second server, over the Internet via the first network, the content identifier (¶[225], method for fetching content from second server …via a second device…using a first server over the internet);
sending, by the client device to the web server, over the Internet via the first network, the content identifier (¶[084]URI/URL accessing a web server), in response to the receiving of the content identifier (¶ [223]-[224], device receives content identifier …sends that identifier to another server…that server returns the requested content… also see¶ [232]);
receiving, by the client device from the web server, over the Internet via the first network, the content, in response to the sending of the content identifier (¶[515], Upon receiving part of, or all of, the requested chunks, the client device #1 201a assembles the chunks to render a reconstructed content (in part or in full), such as the requested URL && Also see [217], [218]); and
sending, by the client device to the second server, over the Internet via the first network, the received content (see ¶[223] received content from one serve and forward that received content to another network entity, also see ¶ [229], [262] etc).
Shribman teaches TCP server message exchange where client device switches from idle state to non-idle state ([668], [677], [678]) but expressly lacks responsive to being in the idle state and to the measured data rate being below a threshold, shifting to the non-idle state.
However, Boley, teaches user equipment or client device that perform state transitions and threshold triggered movement among those states. Furthermore, Boley teaches responsive to being in the idle state ([027], Idle = RRC Idle Mode, Non-Idle State = the RRC connected-mode states, [029]) and to the measured data rate being below a threshold, shifting to the non-idle state (Boley: [034], data throughput below a certain threshold can cause the UTRAN to move the UE from CELL_DCH state to non-idle states such as CELL_FACH/CELL_PCH/URA_PCH/idle mode);
sending, a message indicative of the shifting to the non-idle state to the first server over the TCP connection, in response to the shifting to the non-idle state (see Boley: [040], “UE to trigger an RRC cell update procedure” [046], Cell update confirmation message; [053]);
responsive to being in the non-idle state and to the measured data rate being above the threshold, shifting to the idle state (¶ [034], payload (a form of measured data) is detected to be above a certain threshold then the RRC state can be moved from CELL_PACH state 124 to CELL_DCH state 122);
sending, a message indicative of the shifting to the idle state to the first server over the TCP connection, in response to the shifting to the idle state (see Boley: [040], “UE to trigger an RRC cell update procedure” [046], Cell update confirmation message; [053]);
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 user equipment (UE) state transition as taught by Boley in order to make Shribman’s client/server content fetching system more power efficient and state aware by apply Boley’s state transition control so the client can move efficiently between lower-activity and more active communication states while suppressing unnecessary signaling during transitions.
Referring to claim 2, Shribman teaches the method according to claim 1, further comprising periodically sending, by the client device to the first server over the TCP connection, over the Internet via the first network, the measured data rate (¶ [537], periodically, measures the various communication related characteristics for each communication with a peer device, such as BW and RTT, as part of a ‘Measure BW, RTT).
Referring to claim 3, Shribman teaches the method according to claim 1, wherein the client device is addressable in the Internet by a first IP address, and wherein the establishing comprises sending, by the client device to the first server, the first IP address (¶[018], [020], defines server/client internet model and explains that a server commonly has and IP address and client initiates internet connections).
Referring to claim 4, Shribman teaches the method according to claim 1, further comprising establishing a connection with the second server, and wherein any communication between the client device and the first server is over the established connection (¶ [237], establishing a connection between the first device and the second device in response to receiving the second identifier, and the first device may be communicating with the second device over the established connection).
Referring to claim 5, Shribman teaches the method according to claim 4, wherein the established connection uses, or is based on, Virtual Private Network (VPN) (¶ [112] – [116], [430], VPN as part of the pre-connection arrangement).
Referring to claim 6, Shribman teaches the method according to claim 1, wherein the TCP connection uses ‘Active OPEN’, ‘Passive OPEN’, or wherein the TCP connection uses TCP keepalive mechanism (¶[008]-[010], [204], [237], [429], TCP communication and connection establishment using ACTIVE OPEN and Passive OPEN).
Referring to claim 7, Shribman teaches the method according to claim 1, further comprising 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 8, Shribman teaches the method according to claim 7, wherein the NAT traversal scheme is 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 7350 (see ¶ [005], [015], [018], [020], Selection of specific RFC based NAT traversal mechanism is routine design choice).
Referring to claim 9, Shribman teaches the method according to claim 7, wherein the NAT traversal scheme is based on, or uses, a 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 (I GDP), or Application-Level Gateway (ALG) (see ¶ [268], peer/tunnel communication ¶[506] connection setup across networks).
Referring to claim 10, Shribman teaches the method according to claim 1, wherein the communication over the Internet by the client device with the first or second server, uses, or is compatible with, a Transmission Control Protocol over an Internet Protocol (TCP/IP) protocol or connection (¶[004]-[005], expressly teaches Internet protocol Suite TCP/P where web browsers connects to servers on the WWW).
Referring to claim 11, Shribman teaches the method according to claim 10, wherein the communication over the Internet by the client device with the first or second server is based on, uses, or is compatible with, HTTP or HTTPS protocol or connection, wherein the first or second server serves as an HTTP or HTTPS server and the client device serves as an HTTP or HTTPS client (¶ [021], HTTP is used for communication over the internet).
Referring to claim 12, Shribman teaches the method according to claim 10 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 include RFC 1928 on client device with the first or second server, is based on, uses, or is compatible with, Socket Secure (SOCKS) protocol or connection, wherein the first or second server serves as a SOCKS server and 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 13, Shribman teaches the method according to claim 12 and discloses communication between client device and servers over a TCP/IP based network (¶ [004]-[005], [021]),
Shribman does not expressly mentions wherein the SOCKS protocol or connection is according to, based on, or is compatible with, SOCKS4, SOCKS4a, or SOCKS5.
However, Socks4 or SOCKS4a, or SOCKS5 are well-known version of proxy protocol that operates over TCP/IP to facilitate communication between a client and a server.
Shribman can be modified to include RFC 1928 on client device with the first or second server, is based on, uses, or is compatible with, Socket Secure (SOCKS) protocol or connection, wherein the first or second server serves as a SOCKS server and 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 14, Shribman teaches the method according to claim 12, 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 (same rationale as above).
Referring to claim 15, Shribman teaches the method according to claim 1, wherein the communication over the Internet by the client device with the first or second server, is based on, uses, or is compatible with, HTTP Proxy protocol or connection, and wherein the respective first or second server serves as an HTTP Proxy server and the client device serves as an HTTP Proxy client (see ¶ [021]-[022], HTTP client-server communication where HTTP proxy servers at Private Network boundaries facilitate communication for clients by relaying messages with external servers).
Referring to claim 16, Shribman teaches the method according to claim 1, wherein the client device comprises an input device for obtaining an input from a human user or operator, the method further comprising sensing, by the client device using the input device, an input from a human user or operator, and sending, by the client device to the first server, a message in response to the sensed input [063], Human Interaction [075], Human Input Device HID, [581], graphics-based human interface).
Referring to claim 17, Shribman teaches the method according to claim 16, wherein the message comprises a value that is responsive to the sensed input ([464], [619], sensed inputs examples).
Referring to claim 18, Shribman teaches the method according to claim 16, wherein the input device comprises a touchscreen, a microphone, a pointing device, or a keyboard ([061][063],[667], Keyboard).
Referring to claim 19, Shribman teaches the method according to claim 16, wherein the sensing of the input device comprises periodically or continuously sensing of the input (¶ [537], The client device, continuously or periodically, measures the various communication related characteristics).
Referring to claim 20, Shribman teaches the method according to claim 19, wherein the sensing 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 21, Shribman teaches the method according to claim 16, further comprising executing or using an operating system, and wherein the sensing comprises sensing using the operating system [031], [619], operating system 507, it is continuously connected to a gateway and a network, and the actual disconnection is not sensed by the OS, also see [632]).
Referring to claim 22, Shribman teaches the method according to claim 1, wherein the client device is part of, or comprises, a vehicular device, or is mounted in a vehicle (see ¶ [159], “a vehicular device”)
Referring to claim 23, Shribman teaches the method according to claim 1, wherein the client device is a mobile device that is housed in a single enclosure that is a hand-held enclosure or a portable enclosure (see ¶ [159], portable device [717], mounted in a single enclosure).
Referring to claim 24, Shribman teaches the method according to claim 23, 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 (see ¶ [159], mobile device is PDA).
Referring to claim 25, Shribman teaches the method according to claim 23, wherein the mobile device comprises, is part of, or is integrated with, a smartphone (see ¶ [030], [031], smartphone).
Referring to claim 26, Shribman teaches the method according to claim 1, further comprising storing, operating, or using an operating system (see ¶ [024], [025], [026], [031], [033], operating system).
Referring to claim 27, Shribman teaches the method according to claim 26, wherein the operating system comprises a mobile operating system (see ¶ [030], [031], [033], mobile operating system).
Referring to claim 28, Shribman teaches the method according to claim 1, wherein the wireless network comprises, or consists of, a Wireless Wide Area Network (WWAN) (see ¶ [159], Wireless WAN – WWAN).
Referring to claim 29, Shribman teaches the method according to claim 28, wherein the WWAN is a wireless broadband network (¶ [022], UDP protocol is used on wireless network).
Referring to claim 30, Shribman teaches the method according to claim 29, wherein the wireless network comprises, a WiMAX network that is according to, compatible with, or based on, IEEE 802.16-2009 ([720], IEEE 802 variations being used are compatible with WiMax).
Referring to claim 31, Shribman and Boley teaches the method according to claim 1, wherein the wireless network comprises a cellular telephone network (¶[030], [088], Cellular network, & Boley: ¶ [020]-[023]).
Referring to claim 32, Boley teaches the method according to claim 31, wherein the cellular telephone network is a Third Generation (3G) network that uses UMTS W-CDMA, UMTS HSPA, UMTS TDD, CDMA2000 1×RTT, CDMA2000 EV-DO, or GSM EDGE-Evolution standard, or wherein the cellular telephone network uses a Fourth Generation (4G) network that uses HSPA+, Mobile WiMAX, LTE, LTE-Advanced, MBWA, or is based on IEEE 802.20-2008 standard (¶ [020]-[031], expressly teaches UMTS, UTRAN, 3G architecture).
Referring to claim 33, Shribman teaches the method according to claim 1, wherein the wireless network comprises, or consists of, a Wireless Personal Area Network (WPAN) (see ¶ [594], WPAN).
Referring to claim 34, Shribman teaches the method according to claim 33, wherein the WPAN is compatible with, or based on, Bluetooth Low Energy (BLE), or IEEE 802.15.1-2005 standards, or wherein the WPAN is a wireless control network that is according to, or based on, IEEE 802.15.4-2003 standard (¶ [030], Bluetooth is a Lowe energy type of network).
Referring to claim 35, Shribman teaches the method according to claim 1, wherein the wireless network comprises, or consists of, a Wireless Local Area Network (WLAN) (¶ [681], mentions reconnection to a WAP which implies a wireless access point/WLAN content).
Referring to claim 36, Shribman teaches the method according to claim 35, wherein the WLAN is according to, compatible with, or is based on, IEEE 802.11-2012, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, or IEEE 802.11ac standard (see ¶ [160], “IEEE 802.11-2012”).
Referring to claim 37, 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], Windows Software Development Kit (SDK)).
Referring to claim 38, Shribman teaches the method according to claim 1, further comprising storing, operating, or using, by the client device, a web browser (see ¶ [021] – [022], web browser).
Referring to claim 39, Shribman teaches the method according to claim 38, wherein the web browser is a mobile web browser (see ¶ [088], safari is a mobile web browser).
Referring to claim 40, Shribman teaches the method according to claim 1, wherein the client device is associated with multiple IP addresses (¶ [563], discusses IP based data mapping and internet related addressing attributes).
Referring to claim 41, 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 shifting to the idle state or to the non-idle state is uses, or is based on, activating or executing the process or thread by the operating system or the program (¶[722], expressly defines task, process, thread executing application operating system user process. Etc).
Referring to claim 42. Shribman teaches the method according to claim 1, further comprising sending, by the client device to the first server over the TCP connection, a first value of a first attribute type [259], teaches measuring and reporting communication characteristics such as BW/RTT).
Referring to claim 43 Shribman teaches the method according to claim 42, wherein the first attribute type comprises Internet Service Provider (ISP) or Autonomous System Number (ASN) [563], expressly says IP-address based location/attribute data may include ISP).
Referring to claim 44. Shribman teaches the method according to claim 43, wherein the first value comprises a name or an identifier of the ISP or the ASN number (see ¶ [563], It expressly discusses IP-based geolocation/attribute data including ISP, related Identifying information such as country/region/city/domain-name/connection speed, etc.)
Referring to claim 45, Shribman teaches the method according to claim 42, wherein the first attribute type corresponds to a hardware of software of the client device (see ¶ [722], covers processes, threads, operating system, application etc).
Referring to claim 46, Shribman teaches the method according to claim 45, wherein the first attribute type comprises the hardware of the client device ([722], broadly contemplates device side processes and operating structures and claim).
Referring to claim 47, Shribman teaches the method according to claim 46, wherein the first values comprise stationary and portable values, respectively based on the client device being stationary or portable (¶ [089], portable electronic device such as notebook/laptop, cell phone PDA, etc)
Referring to claim 48, Shribman teaches the method according to claim 45, wherein the first attribute type comprises a software application installed, used, or operated, in the client device [0722], teaches tasks that comprise executing application operating systems, user process, device drivers or other software executed by client device).
Referring to claim 49, Shribman teaches the method according to claim 48, wherein the first values comprise the type, make, model, or version of the software (see ¶ [065], [067], teaches values including version and/or model of software).
Referring to claim 50, Shribman teaches the method according to claim 48, wherein the software comprises an operating system [078], [089], Operating system such as Mac OS X etc).
Referring to claim 51, Shribman teaches the method according to claim 42, wherein the first attribute type corresponds to a communication property, feature of a communication link to the Internet of the client device [701] – [705]. “client needs to assess the BW and RTT of the source_2. A good estimation (or a guess) may assume that the values of the BW and RTT of the source_2 are between the values of BW and RTT of source_1 and source_4”)
Referring to claim 52, Shribman teaches the method according to claim 51, wherein the communication link corresponds to the connection to the Internet of the client device (¶ [701]-[705], BW/RTT assessment is directed to the client device communication with internet sources and thus corresponds to the client device’s connection to the internet).
Referring to claim 53, Shribman teaches the method according to claim 52, wherein the communication link corresponds to a communication link with the web server, the first server, or the second server ([587], [588], communication correspond to link with server).
Referring to claim 54, Shribman teaches the method according to claim 51, 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 measurement of the BW or RTT (see ¶ [146], [708] Attributes types are BW/RTT).
Referring to claim 55, Shribman teaches the method according to claim 54, further comprising estimating or measuring, by the client device, the BW or RTT of the communication link (see ¶ [146],[708]).
Referring to claim 56, Shribman teaches the method according to claim 1, wherein the web server uses HyperText Transfer Protocol (HTTP) and responds to HTTP requests via the Internet, and wherein the sending of the content identifier to the web server comprises sending of a HTTP request that comprises the content identifier (¶ [021], [204], HTTP request).
Referring to claim 57, Shribman teaches the method according to claim 56, wherein the communication with the web server is based on, or uses, HTTP persistent connection (¶ [204], HTTP connection is a TCP persistent connection).
Referring to claim 58, Shribman teaches the method according to claim 56, wherein the web server uses HyperText Transfer Protocol Secure (HTTPS) and responds to HTTPS requests via the Internet, and wherein the sending of the content identifier to the web server comprises sending of a HTTPS request that comprises the content identifier (¶ [568], https://data.un.org).
Referring to claim 59, Shribman teaches the method according to claim 1, wherein the content includes, or comprises, a part or whole of audio data, voice data, multimedia data, video data, or a computer program (¶ [204], Audio/video etc).
Referring to claim 60, Shribman teaches the method according to claim 1, wherein the content includes, consists of, or comprises, a part of, or a whole of, a web-site page (see ¶ [432], website page).
Referring to claim 61, Shribman teaches the method according to claim 1, wherein the content is public content that is available from the web server for any requesting client device over the Internet (¶ [021], [022], website are public content that available from servers).
Referring to claim 62, Shribman teaches the method according to claim 1, wherein the message comprises, or is based on, an ‘heartbeat’ message, and wherein a time period between multiple 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 63, 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 an Uniform Resource Identifier (URI) or a 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).
Referring to claim 64. Shribman teaches the method according to claim 1, wherein the first server is randomly selected from the plurality of servers (see ¶ [219], server is selected from the plurality of servers).
Referring to claim 65, Shribman teaches the method according to claim 64, wherein the first server is randomly selected using one or more random numbers generated by a random number generator (¶ [201], The second device may be randomly selected out of the devices in the group using one or more random numbers generated by a random number generator).
Referring to claim 66, Shribman teaches the method according to claim 65, wherein the random number generator is hardware based (¶ [201], The random number generator may be hardware based).
Referring to claim 67, Shribman teaches the method according to claim 66, wherein the random number generator is using thermal noise, shot noise, nuclear decaying radiation, photoelectric effect, or quantum phenomena (¶ [201], 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 68, Shribman teaches the method according to claim 65, wherein the random number generator is software based (see ¶ [108], random numbers can be software based).
Referring to claim 69, Shribman teaches the method according to claim 68, 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).
Referring to claim 70, Shribman teaches the method according to claim 1, wherein each of the plurality of servers is associated with a one of more attribute values relating to an attribute type, and wherein the selecting of the first server from the plurality of servers based on, or according to, the one of more attribute values (¶[258], The attribute may relate to people or society, such as language, sport, demographics, or religion).
Referring to claim 71, Shribman teaches the method according to claim 70, 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 timezone (see ¶ [234], The physical geographical location may include a continent, a country, a state or province, a city, a street, or a ZIP code, as well as longitude and latitude).
Referring to claim 72, Shribman teaches the method according to claim 71, wherein the one of more attribute values is based on actual geographical location or on IP geolocation (see ¶ [234], The physical geographical location may include, as well as longitude and latitude as actual physical geographical location).
Referring to claim 73, Shribman teaches the method according to claim 72, wherein the geolocation is based on W3C Geolocation API (see ¶[257], see W3C Geolocation API).
Referring to claim 74, 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, by the client device using the DNS server, a DNS resolution for obtaining a numerical IP address (see ¶ [189], DNS server, a DNS resolution for obtaining a numerical IP address).
Referring to claim 75, Shribman teaches the method according to claim 1, further comprising storing, operating, or using, by the client device, a client operating system (¶ [282],The client operating system may be a mobile operating system).
Referring to claim 81, 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 82, Shribman teaches the method according to claim 81, wherein a primary functionality of the appliance is food storage, handling, or preparation (see ¶ [715], appliance is kitchen appliance).
Referring to claim 83, Shribman teaches the method according to claim 82, 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 84, Shribman teaches the method according to claim 82, 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 85, Shribman teaches the method according to claim 81, wherein a primary function of the appliance is environmental control, and the appliance comprises, or is part of, an HVAC method (¶[572], cooling equipment (such as air conditioners)).
Referring to claim 86, Shribman teaches the method according to claim 85, 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 87, Shribman teaches the method according to claim 81, 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 88, Shribman teaches the method according to claim 81, wherein a primary function of the appliance is associated with water control or water heating (see ¶ [715], water heater).
Referring to claim 89, Shribman teaches the method according to claim 81, 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 90, Shribman teaches the method according to claim 81, 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).
Claims 76-80 are rejected under 35 U.S.C. § 103 as being unpatentable over Shribman et al (2016/0105530) in view of Boley (2013/0122918 A1) in further view of Sobol (US, pub, )
Referring to claim 76. Shribman-Boley teaches the method according to claim 1.
Neither Shribman nor Boley expressly teaches wherein the client device is implemented as a wearable device that is wearable on an organ of a person head, wherein the organ is an eye, ear, face, cheek, nose, mouth, lip, forehead, or chin.
However, Boley teaches wherein the client device is implemented as a wearable device that is wearable on an organ of a person head, wherein the organ is an eye, ear, face, cheek, nose, mouth, lip, forehead, or chin (Sobol ¶ [019]. Wearable device may be in the form of glasses or hearing aid that directly supports wearable placement on the eye/ear region).
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 77, Shribman-Boley teaches the method according to claim 1, wherein the client device is implemented on a wearable device that is constructed to have a form substantially similar to, is constructed to have a shape allowing mounting or wearing identical or similar to, or is constructed to have a form to at least in part substitute for, headwear, eyewear, or earpiece, wherein the headwear is structured as, or comprises, a bonnet, a cap, a crown, a fillet, a hair cover, a hat, a helmet, a hood, a mask, a turban, a veil, or a wig, wherein the eyewear is structured as, or comprises, glasses, sunglasses, a contact lens, a blindfold, or a goggle, and wherein the earpiece is structured as, or comprises, a hearing aid, a headphone, a headset, or an earplug (see Sobol ¶ [019]. Glasses and hearing aid which strongly supports eyewear and earpiece, also hat)
Referring to claim 78. Shribman-Boley teaches the method according to claim 1, wherein the client device is implemented on a wearable device that is shaped for permanently or releasably being attachable to, or be part of, a clothing piece of a person (see Sobol ¶ [019], expressly teaches that the device maybe embedded in the patient clothing such as shirt underwear, shorts, pants, socks, hat, bra, or any other article of clothing)
Referring to claim 79. Sobol teaches the method according to claim 78, wherein the attaching uses taping, gluing, pinning, enclosing, encapsulating, a pin, or a latch and hook clip, and wherein the clothing piece is a top, bottom, or full-body underwear, or a headwear, a footwear, an accessory, an outwear, a suit, a dress, a skirt, or a top (see Sobol ¶ [019], Supports enclosing/being part of clothing through embedded in patient clothing, clip type attachment through in form of clip that be attached)
Referring to claim 80, Shribman-Boley teaches the method according to claim 1, wherein the client device is implemented on a wearable device that comprises an annular member defining an aperture therethrough that is sized for receipt therein of a part of a human body, wherein the human body part is part of a human hand that consists of, or comprises, an upper arm, elbow, forearm, wrist, or a finger, wherein the human body part is part of a human head or neck that consists of, or comprises, a forehead, ear, skull, or face, wherein the human body part is part of a human thorax or abdomen that consists of, or comprises, a waist or hip, or wherein the human body part is part of a human leg or foot that consists of, or comprises, a thigh, calf, ankle, instep, knee, or toe (see Sobol ¶ [019], state the device may be in the form of Watch, Bracelet, ankle band, finger ring, toe ring, neckplace or earring)
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
Prosecution Insights