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-79 are presented for examination.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 04/02/2024, 08/14/2024, 12/29/2024, 05/20/2025 & 10/29/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Title Objection
The title of the invention is not descriptive relevant to the subject of this continuation according to its own specific inventive concept. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claims Objections
Regarding claim1, Claim 1 is objected to under 35 USC 112b as being indefinite because it recites that client device is configured to be in “Idle” 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 NonIdle 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.
Referring to claims 11-21, 37, 39, 41, 43, 56 and 59, presents repeated compatibility phrasing that is overboard “based on/ uses/compatible with” language. These phrases define capability not actual operation. Compatible with does not require that the protocol to used. The claims fail to specify whether the recited protocols are actually employed, optionally supported or merely theoretically compatible.
Referring to claims 16, 17, and 20, these claims enumerate a laundry list of RFCs without specifying selection criteria, operation sequence or interaction model.
Regarding claims 26-79, the claims recites limitations that are directed to “intended use”. "Nonfunctional descriptive material" includes but is not limited to. For example these dependent claims starting with claim 26 recite client device is part of, or comprises, a vehicular device, mobile device, smart phone, wearable device, headwear, eyewear, clothing-mounted device, or household appliance and further recite various attaching mechanism and clothing types, i.e. it recites purely mechanical environment in a network method (see claim 65-68) and a compilation or mere arrangement of data. (see MPEP 2106.01).
Referring to claims 44, 45, the recitation “At least part of steps” wherein at least part of steps of claim 1 are included in a Software Development Kit (SDK)”. The office in unclear Which steps? How many? Or Which combination applicant is referring to? The phrase “at least part” fails to delineate claim boundaries and renders the scope indeterminate.
Referring to claims 34, 35, 36, measurement and timing vagueness because it covers all possible sampling rate without any relationship to the system behavior or URL triggering. The limitation fails to meaningfully constrain the claim and introduces ambiguity as to operative conditions.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 26-79 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The drawings and/or specification fails to disclose a client device part of vehicular device and does not support the remaining features claims herein. Appropriate corrections are needed.
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-33, 68-79 are rejected under 35 U.S.C. § 103 as being unpatentable over Toksvig (US pub, 2012/0280917) in view of Ly (US pub, 2013/0091273).
Referring to claim 1, Toksvig teaches a method by a client device that comprises an input component that is configured for obtaining an input from a human user, the client device is configured to be in idle and non-idle states, is addressable in the Internet by a first IP address, and is connectable to the Internet via a wireless network (see ¶ Toksvig [012], Describes smartphone/tablet with capable of receiving input from human user and is connectable to the internet via wireless network see ¶ [068] has, inactive periods, device in power-saving state, [014], ex. Of where phone is in the user pocket and not used), the method comprising:
determining, by the client device, whether an input from a human user is sensed by the input component during a pre-determined time interval (Toksvig ¶¶ [0021], [0025], time-out periods and inactivity intervals);
responsive to determining that no human input is sensed during the pre-determined time interval, shifting to, or staying in, the idle state ((Toksvig ¶¶ [0025], [0026], returning to or remaining in a power-saving state after inactivity);
responsive to determining that a human input is sensed during the pre-determined time interval, shifting to, or staying in, the non-idle state ((Toksvig ¶¶ [0023], [0024]) transitioning to normal operation upon detecting user input);
sensing, by the client device using the input component, an input from a human user (Toksvig ¶¶ [004], [015]–[017] sensing touch and other human interactions via sensors);
wherein the input device comprises a touchscreen, a microphone, a pointing device, a keyboard, or any combination thereof (Toksvig [067], I/O devices keyboard, microphone etc).
Toksvig teaches a client device with multiple states but expressly lacks initiating, by the client device via the wireless network, communication over the Internet with an Internet-connected first server that is addressable in the Internet by a second Internet Protocol (IP) address.
However, Ly teaches a client device that initiates connection request (see ¶ [160]); Furthermore, Ly teaches initiating, by the client device via the wireless network, communication over the Internet with an Internet-connected first server that is addressable in the Internet by a second Internet Protocol (IP) address ((Ly ¶¶ [0008], [0009], client-initiated client–server transactions ¶[147], client device 1605 within a first LAN A sends a connection initiation message);
Ly teaches sending, by the client device via the wireless network to the first server over the Internet, a message in response to the sensed input (Ly ¶¶ [0008]–[0010]) client transmission of messages as part of client–server transactions);
Ly teaches receiving, by the client device in the idle state via the wireless network from the first server over the Internet, a request associated with a content ((Ly ¶¶ [0008], [0017]–[0021]) discloses receiving requests as part of client–server transactions independent of user interaction); and
Ly teaches sending, by the client device via the wireless network to the first server over the Internet, the content, in response to the sending of the request (Ly ¶¶ [0009], [0022]–[0023]) discloses transmitting data/content in response to received requests),
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.
Referring to claim 2, Toksvig teaches the method according to claim 1, wherein the content is identified by a content identifier and is stored in a web server, and wherein the content comprises a web-page or a part thereof, or a web-site or a part thereof (Toksvig: [053], “:websites” are identified by content identifier and are stored on web server and websites have web pages).
Referring to claim 3, Toksvig teaches the method according to claim 2, wherein the content identifier comprises an Uniform Resource Identifier (URI) or a Uniform Resource Locator (URL) (see Toksvig ¶ [053], www.facebook.com is a form of URL/URI).
Referring to claim 4, Toksvig teaches the method according to claim 2, wherein the content identifier comprises a domain name (see Toksvig ¶ [053], www.facebook.com is also a domain name).
Referring to claim 5, Ly teaches the method according to claim 4, further comprising obtaining a numerical IP address of the content identifier (see Ly ¶ [081], IP address is numerical).
Referring to claim 6, Ly teaches the method according to claim 5, wherein the obtaining of the numerical IP address comprises performing, by the client device using a Domain Name System (DNS) server, a DNS resolution (see Ly ¶ [017], DNS Name resolution is performed).
Referring to claim 7, Ly teaches the method according to claim 2, wherein the request comprises the content identifier (see Ly ¶¶[017]–[0023]).
Referring to claim 8, Ly teaches the method according to claim 2, further comprising sending, by the client device to the web server over the Internet, the content identifier in response to the receiving of the request (see Ly ¶¶[0017]–[0023]).
Referring to claim 9, Toksvig teaches the method according to claim 2, further comprising receiving, by the client device from the web server over the Internet, the content in response to the sending of the content identifier (see Ly ¶¶[0017]–[0023]).
Referring to claim 10, Ly teaches the method according to claim 1, further comprising establishing, by the client device with the first server over the Internet, a connection, in response to the initiating of the communication (see Ly ¶ [008], [011]).
Referring to claim 11, Ly teaches the method according to claim 10, wherein the connection uses, or is based on, a Transmission Control Protocol (TCP) connection (see Ly ¶ [011], [012], [019], [062]).
Referring to claim 12, Ly teaches the method according to claim 11, wherein the connection uses, or is based on, Transmission Control Protocol over Internet Protocol (TCP/IP) protocol or connection (see ¶ [063], [077], [088]).
Referring to claim 13, Ly teaches the method according to claim 10, wherein the connection uses, or is based on, an ‘Active OPEN’, ‘Passive OPEN’, or TCP keepalive mechanism (see ¶ [015]-[019]– persistent proxy connections across NAT).
Referring to claim 14, Ly teaches the method according to claim 10, wherein the connection uses, or is based on, a Virtual Private Network (VPN) (see ¶ [015]-[019]– persistent proxy connections across network using VPN is design choice).
Referring to claim 15, Ly teaches the method according to claim 1, wherein the initiating uses, or is based on, a Network Address Translator (NAT) traversal scheme (see ¶ [015]-[019]– persistent proxy connections across NAT).
Referring to claim 16, Ly teaches the method according to claim 15, wherein the NAT traversal scheme is according to, based on, or uses, Internet Engineering Task Force (IETF) Request for Comments (RFC) 2663, IETF RFC 3715, IETF RFC 3947, IETF RFC 5128, IETF RFC 5245, IETF RFC 5389, or IETF RFC 7350 (Ly see ¶ [015]-[019], [022], proxy based NAT traversal, interception, address translation – RFCs are expressly standardized implementation of Ly’s disclosed NAT traversal so it is obvious selection of standardized NAT mechanism).
Referring to claim 17, Ly teaches the method according to claim 15, wherein the NAT traversal scheme is according to, based on, or uses, Traversal Using Relays around NAT (TURN), Socket Secure (SOCKS), NAT ‘hole punching’, Session Traversal Utilities for NAT (STUN), Interactive Connectivity Establishment, (ICE), UPnP Internet Gateway Device Protocol (IGDP), or Application-Level Gateway (ALG) (Ly see ¶ [015]-[019], [022, proxy interception and traversal across NATs, these mechanisms are well-known alternatives to accomplish Ly’s disclosed functions thereby making it obvious).
Referring to claim 18, Ly teaches the method wherein The according to claim 1, the communication over the Internet by the client device with the first, is based on, or is compatible with, Socket Secure (SOCKS) protocol or connection (Ly see ¶ [016], [019], proxy mediated redirection of traffic, SOCKs is a known proxy protocol performing this function so it would be obvious to an ordinary artisan).
Referring to claim 19, Ly teaches the method according to claim 18, wherein the SOCKS protocol or connection is according to, based on, or is compatible with, SOCKS4, SOCKS4a, or SOCKS5 (Ly see ¶ [016], [019], proxy mediated redirection of traffic, merely recites SOCK versions of a known proxy protocol so it would be obvious to an ordinary artisan).
Referring to claim 20, Ly teaches the method according to claim 18, 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 (Ly see ¶ [016], [019], proxy mediated redirection of traffic, RFC citations does not add technical limitation therefore use of one or more of these RFC would be obvious over Ly)
Referring to claim 21, Ly teaches the method according to claim 1, wherein the communication over the Internet by the client device with the first server, is based on, or is compatible with, HTTP Proxy protocol or connection, wherein the first or second server serves as an HTTP Proxy server and the client device serves as an HTTP Proxy client (see ¶ [107], [112], [144]).
Referring to claim 22, Toksvig teaches the method according to claim 1, wherein the message comprises a value that is responsive to the sensed input (see ¶ [021], [023], state decisions responsive to detected user input).
Referring to claim 23, Toksvig teaches the method according to claim 1, further comprising executing or using, by the client device, an operating system, and wherein the sensing comprises using the operating system (see ¶ [012]- [017], OS Level input detection and state management).
Referring to claim 24, Toksvig teaches the method according to claim 1, for use with a threshold level, the method further comprising comparing the sensed input to the threshold level, and wherein the sending of the message is in response to the comparing (see [021]-[025] – time thresholds governing idle determination is obvious).
Referring to claim 25, Toksvig teaches the method according to claim 24, wherein the sending of the message is in response to the sensed input being below or above the threshold level (see ¶ [021], [023], [025]).
Referring to claim 26. Toksvig teaches the client device is part of, or comprises, a vehicular device (see ¶ [012], [016] – mobile electronic device, applying same logic to vehicle is a field of use or design choice and is obvious).
Referring to claim 27, Toksvig 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 ¶ [059], portable device shown in fig. 2 has portable enclosure that is handled enclosure).
Referring to claim 28, Toksvig teaches the method according to claim 27, 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 ¶ [059], Laptop).
Referring to claim 29, Toksvig teaches the method according to claim 27, wherein the mobile device comprises, is part of, or is integrated with, a smartphone (see¶ [059]).
Referring to claim 30, Toksvig teaches the method according to claim 1, further comprising storing, operating, or using, by the client device, an operating system (Fig. 2, item 200, [012], client device has a operating system which is mobile operating system).
Referring to claim 31, Toksvig teaches the method according to claim 30, wherein the operating system is a mobile operating system (Fig. 2, item 200, [012], client device has a operating system which is mobile operating system).
Referring to claim 32, Toksvig teaches the method according to claim 1, wherein the sensing of the input comprises continuously sensing of the input (see ¶ [015], [016], [017], [020], sensors do the continuously sensing) .
Referring to claim 33, Toksvig teaches the method according to claim 1, wherein the sensing of the input comprises periodically sensing of the input (see ¶ [015], [016], [017], [020], sensors do the continuously sensing).
Referring to claim 68, Toksvig teaches the method according to claim 1, wherein the client device is 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 (See Toksvig ¶ [016], [030], ).
Referring to claim 69, Toksvig teaches the method according to claim 1, wherein the client device is part of, integrated with, or comprises, a household appliance (see ¶ [012], [016], Network device can be any appliance).
Referring to claim 70, Toksvig teaches the method according to claim 69, wherein a primary functionality of the appliance is food storage, handling, or preparation (see Toksvig: ¶ [012], [016], Applying same logic to appliances is predictable and obvious to an ordinary artisan).
Referring to claim 71, Toksvig teaches the method according to claim 70, 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 Toksvig: ¶ [012], [016], Applying same logic to appliances is predictable and obvious to an ordinary artisan)
Referring to claim 72, Toksvig teaches the method according to claim 70, 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 Toksvig: ¶ [012], [016], Applying same logic to appliances is predictable and obvious to an ordinary artisan).
Referring to claim 73, Toksvig teaches the method according to claim 69, wherein a primary function of the appliance is environmental control, and the appliance consists of, or is part of, an HVAC method (see Toksvig: ¶ [012], [016], Applying same logic to appliances is predictable and obvious to an ordinary artisan).
Referring to claim 74, Toksvig teaches the method according to claim 73, wherein a primary function of the appliance is temperature control, and wherein the appliance is an air conditioner or a heater (see Toksvig: ¶ [012], [016], Applying same logic to appliances is predictable and obvious to an ordinary artisan).
Referring to claim 75, Toksvig teaches the method according to claim 69, 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 Toksvig: ¶ [012], [016], Applying same logic to appliances is predictable and obvious to an ordinary artisan).
Referring to claim 76, Toksvig teaches the method according to claim 69, wherein a primary function of the appliance is associated with water control or water heating (see Toksvig: ¶ [012], [016], Applying same logic to appliances is predictable and obvious to an ordinary artisan).
Referring to claim 77, Toksvig teaches the method according to claim 69, 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 Toksvig: ¶ [012], [016], Applying same logic to appliances is predictable and obvious to an ordinary artisan).
Referring to claim 78, Toksvig teaches the method according to claim 69, 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 (Toksvig: [059], a mobile device, a personal digital assistant (PDA), a server, a tool, a toy, an item of clothing, or a combination of two or more of these).
Referring to claim 79, Ly teaches the method according to claim 1, wherein the request is according to, or uses, HyperText Transfer Protocol (HTTP) or HTTP Secure (HTTPS) request (see ¶ [107], [112], [144]).
Claims 34-67 are rejected under 35 U.S.C. 103 as being unpatentable over Toksvig (US pub, 2012/0280917) in view of Ly (US pub, 2013/0091273) in view of Shribman et al (US pub, US 20150067819 A1)
Toksvig teaches a client device with multiple states with sensing capabilities.
However, Ly teaches a client device that initiates connection request using cooperative proxy through network address translation devices.
Neither Toksvig nor Ly expressly teaches wherein the time interval between two consecutive sensing actions is at least every 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.
However, Shribman teaches wherein the time interval between two consecutive sensing actions is at least every 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 ([443], [472], [520], [546], see various time intervals between two consecutive sensing actions).
It would have been obvious to an ordinary person skilled in the art at the time invention was made to modify Toksvigs 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 to further include sensing actions with time intervals as taught by Shribman in order to optimize network communication behavior of a mobile device, reduce unnecessary network traffic and improve power efficiency and responsiveness.
Referring to claim 34, Shribman teaches the method according to claim 33, wherein the time interval between two consecutive sensing actions is at least every 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 Shribman ¶ [443], [472], [520], [546], see various time intervals between two consecutive sensing actions)..
Referring to claim 35, Shribman teaches the method according to claim 1, wherein the wireless network comprises a Wireless Wide Area Network (WWAN) (see Shribman ¶ [594], [718], WWAN) .
Referring to claim 36, Shribman teaches the method according to claim 35, wherein the WWAN is a wireless broadband network (see Shribman ¶ [594], [718], WWAN).
Referring to claim 37, Shribman teaches the method according to claim 36, wherein the wireless network comprises a WiMAX network, and the WiMAX network is according to, or based on, IEEE 802.16-2009 (Shribman expressly teaches ¶ [718] IEEE802.16 networks).
Referring to claim 38, Shribman teaches the method according to claim 1, wherein the wireless network comprises a cellular telephone network (see Shribman teaches (¶ [718], cellular radio telephone communication systems).
Referring to claim 39, Shribman teaches the method according to claim 38, 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 (¶ [718], Shribman broadly covers cellular network and IEEE 802.20 encompassing 3G/4G).
Referring to claim 40, Shribman teaches the method according to claim 1, wherein the wireless network comprises a Wireless Personal Area Network (WPAN) (see Shribman ¶ [594], [718], WPAN)..
Referring to claim 41, Shribman teaches the method according to claim 40, wherein the WPAN is according to, compatible with, or based on, Bluetooth Low Energy (BLE) or IEEE 802.15.1-2005 standard, or wherein the WPAN is a wireless control network that is according to, or based on, IEEE 802.15.4-2003 standard (see Shribman ¶ [594], [718], WPAN and short range wireless interfaces along with Bluetooth [0030], [564].
Referring to claim 42, Shribman teaches the method according to claim 1, wherein the wireless network comprises a Wireless Local Area Network (WLAN) (see ¶ [159] – [160], see wireless network as WLAN).
Referring to claim 43, Shribman teaches the method according to claim 42, 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, and IEEE 802.11ac standard (see Shribman ¶ [160], 802.11 a/b/g/n/ac).
Referring to claim 44, Shribman teaches the method according to claim 1, wherein at least part of steps is provided as a non-transitory computer readable medium that contains computer instructions (see ¶ [542], Shribman describes software, kernel drivers, user-space modules).
Referring to claim 45, Shribman teaches the method according to claim 1, wherein at least part of steps are included in a Software Development Kit (SDK) (see ¶ [542], Shribman describes software, kernel drivers, user-space modules include SDK).
Referring to claim 46, Shribman teaches the method according to claim 45, further comprising installing the SDK in the client device (see ¶ [542], Shribman describes software, kernel drivers, user-space modules include SDK in client device).
Referring to claim 47, Shribman teaches the method according to claim 1, further comprising storing, operating, or using, by the client device, a web browser (see ¶ [542], Shribman lists web browsers).
Referring to claim 48, Shribman teaches the method according to claim 47, wherein the web browser comprises a mobile web browser (see ¶ [542], Shribman describes mobile browsers e.g. Safari, Opera mini and Android).
Referring to claim 49, Shribman teaches the method according to claim 47, wherein the receiving of the request comprises receiving using the web browser (see ¶ [542], Shribman teaches browser interception of requests).
Referring to claim 50, Shribman teaches the method according to claim 1, further comprising sending, by the client device to the first server over the Internet, an additional message that is responsive to the client device state (see ¶ [543], Shribman describes device states and signaling).
Referring to claim 51, Shribman teaches the method according to claim 50, wherein the sending of the additional message is responsive to shifting to the idle state (see ¶ [543], Online/Offline state transitions).
Referring to claim 52, Shribman teaches the method according to claim 50, wherein the sending of the additional message is responsive to being in the idle state (see ¶ [543], persistent state monitoring).
Referring to claim 53, Shribman teaches the method according to claim 50, wherein the sending of the additional message is responsive to shifting to the non-idle state (see ¶ [543], Online/Congested state transitions).
Referring to claim 54 Shribman teaches the method according to claim 50, wherein the sending of the additional message is responsive to being in the non-idle state (see ¶ [543], same state based communication Online/Congested state transitions).
Referring to claim 55, Shribman teaches the method according to claim 1, wherein the content comprises a part of, or whole of, a computer file, audio data, voice data, multimedia data, video data, a computer program, or any combination thereof (see ¶ [abs], [159], Shribman discloses web content, files, media slices).
Referring to claim 56, 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 two sent messages 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 ¶ [543], Periodic updates, monitoring signaling [157], [179] [537]).
Referring to claim 57, Shribman teaches the method according to claim 1, further for use with a plurality of servers that includes the first server, each of the plurality of servers is connectable to the Internet and is addressable in the Internet using a respective IP address, the method further comprising selecting, by the client device, the first server from the plurality of servers (see Shribman ¶ [Abs] [546], multiple tunnel devices and servers, [549] selection of specific tunnel devices)
Referring to claim 58, Shribman teaches the method according to claim 1, wherein the client device is further storing, operating, or using, a client operating system (see ¶ [542], Kernel space/user space execution).
Referring to claim 59, Shribman teaches the method according to claim 1, wherein the communication over the Internet by the client device with the first server, is based on, or is compatible with, HTTP or HTTPS protocol or connection (See ¶ [716], explicitly discloses HTTP and HTTPS).
Referring to claim 60, Shribman teaches the method according to claim 1, wherein the client device is a wearable device that is wearable on a person ([718], - portable electronic devices – predictable form-factor application).
Referring to claim 61, Shribman teaches the method according to claim 60, wherein the client device is 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 (see Shribman ¶ [718], - portable client electronic devices – applying to wearables is routine field of use adaptation and is a design choice).
Referring to claim 62, Shribman teaches the method according to claim 61, 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 (see Shribman ¶ [718], - portable client electronic devices – applying to wearables is routine field of use adaptation and is a design choice).
Referring to claim 63, Shribman teaches the method according to claim 61, wherein the eyewear is structured as, or comprises, glasses, sunglasses, a contact lens, a blindfold, or a goggle (see Shribman ¶ [718], - portable client electronic devices – applying to wearables is routine field of use adaptation and is a design choice).
Referring to claim 64, Shribman teaches the method according to claim 61, wherein the earpiece is structured as, or comprises, a hearing aid, a headphone, a headset, or an earplug (see Shribman ¶ [718], - portable client electronic devices – applying to wearables is routine field of use adaptation and is a design choice).
Referring to claim 65, Shribman teaches the method according to claim 60, wherein the client device is a wearable device that is shaped for permanently or releseably being attachable to, or be part of, a clothing piece of a person (see Shribman ¶ [718], - portable client electronic devices – applying to wearables is routine field of use adaptation and is a design choice).
Referring to claim 66, Shribman teaches the method according to claim 65, wherein the attaching uses taping, gluing, pinning, enclosing, encapsulating, a pin, or a latch and hook clip (¶ [715], attachments/arrangement mechanical attachment does not affect network method therefore this in non-functional limitation).
Referring to claim 67, Shribman teaches the method according to claim 66, 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 ¶ [713], clothes would have motivated an ordinary artisan to include various articles of clothing and also intended field of use limitations).
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