PROVISIONAL APPLICATION FOR PATENT COVER SHEET — Page 1 of 2
`This is a request for filing a PROVISIONAL APPLICATION FOR PATENT under 37 CFR 1.53(c).
`
`PTO/SB/16 (10-07)
`
`Given Name (first and middle [if any])
`
`INVENTOR(S)
`Family Name or Surname
`
`Anton
`
`Michael
`
`Heikki
`
`Seppo
`
`Diederich
`
`Luna
`
`Ylinen
`
`Residence
`(City and either State or Foreign Country)
`Mountain View, CA
`
`San Jose, CA
`
`Espoo, Finland
`
`Salorinne
`
`Helsinki, Finland
`
`separately numbered sheets attached hereto
`Additional inventors are being named on the (cid:9)
`TITLE OF THE INVENTION (500 characters max)
`DOMAIN NAME SYSTEM WITH NETWORK TRAFFIC HARMONIZATION
`
`Direct all correspondence to:
`
`CORRESPONDENCE ADDRESS
`
`The address corresponding to Customer Number:
`
`20350
`
`OR
`
`Firm or
`Individual Name
`Address
`
`City
`Country
`
`State
`Telephone
`ENCLOSED APPLICATION PARTS (check all that apply)
`
`Zip
`Email
`
`q Application Data Sheet. See 37 CFR 1.76
`
`
`
`q CD(s), Number of CDs
`
`Drawing(s) Number of Sheets
`
`5
`
`q Other (specify)
`
`
`
`of Pages (cid:9)Number
`Specification (e.g., description of the invention)
`
`15
`
`Fees Due: Filing fee of $210 ($105 for small entity).
`sheets of paper, an application size fee is
`If the specification
`and drawings exceed 100
`50
`each additional
`35 U.S.C. 41(a)(1)(G) and 37 CFR 1.16(s).
`sheets or fraction thereof. See
`also due, which is $260 ($130 for small entity) for
`
`METHOD OF PAYMENT OF THE FILING FEE AND APPLICATION SIZE FEE FOR THIS PROVISIONAL APPLICATION FOR PATENT
`
`the filing fee and application size fee (if applicable). q A check or money order is enclosed to cover
`
`Applicant claims small entity status. See 37 CFR 1.27.
`
`
`
`attached. (cid:9)q Payment by credit card. Form PTO-2038 is
`
`$) FEE AMOUNT (
`TOTAL
`
`a (cid:9) The Director is hereby authorized to charge
`the filing fee and application size fee (if applicable) or credit any overpayment
`to Deposit
`Account Number: (cid:9) 20-1430
`. A duplicative copy of this form is enclosed for fee processing.
`USE ONLY FOR FILING A PROVISIONAL APPLICATION FOR PATENT
`
`110
`
`63089781 vl
`
`Page 1 of 51
`
`GOOGLE EXHIBIT 1018
`
`q
`

`

`PROVISIONAL APPLICATION COVER SHEET
`Page 2 of 2
`
`PTO/SB/16 (10-07)
`
`The invention was made by an agency of the United States Government or under a contract with an agency of the United States Government.
`Z No.
`q Yes, the name of the U.S. Government agency and the Government contract number are: (cid:9)
`
`
`
`WARNING:
`Petitioner/applicant is cautioned to avoid submitting personal information in documents filed in a patent application that may
`contribute to identity theft. Personal information such as social security numbers, bank account numbers, or credit card
`numbers (other than a check or credit card authorization form P10-2038 submitted for payment purposes) is never required by
`the USPTO to support a petition or an application. If this type of personal information is included in documents submitted to
`the USPTO, petitioners/applicants should consider redacting such personal information from the documents before submitting
`them to the USPTO. Petitioner/applicant is advised that the record of a patent application is available to the public after
`publication of the application (unless a non-publication request in compliance with 37 CFR 1.213(a) is made in the application)
`or issuance of a patent. Furthermore, the record from an abandoned application may also be available to the public if the
`application is referenced in a published application or an issued patent (see 37 CFR 1.14). Checks and credit card
`authorization forms P10-2038 submitted for payment purposes are not retained in the application file and therefore are not
`publicly available.
`
`SIGNATURE
`
`/Richard P. Dodson/ (cid:9)
`
`Date 01/07/11
`
`TYPED or PRINTED NAME Richard P. Dodson
`
`REGISTRATION NO. 52,824
`(if appropriate)
`
`TELEPHONE 206-467-9600
`
`Docket Number: 028482-004300US
`
`63089781 vl
`
`Page 2 of 51
`
`

`

`Attorney Docket No.: 028482-004300US
`
`PROVISIONAL PATENT APPLICATION
`
`DOMAIN NAME SYSTEM WITH NETWORK TRAFFIC HARMONIZATION
`
`Inventors: (cid:9)
`
`Anton Diederich, a citizen of the United States, residing at
`Mountain View, CA;
`
`Michael Luna, a citizen of the United States, residing at
`San Jose, CA;
`
`Heikki Ylinen, a citizen of Finland, residing at
`Espoo, Finland
`
`Seppo Salorinne, a citizen of Finland, residing at
`Helsinki, Finland
`
`Assignee: (cid:9)
`
`Seven Networks, Inc.
`
`Entity: (cid:9)
`
`Small
`
`KILPATRICK TOWNSEND & STOCKTON LLP
`Two Embarcadero Center, Eighth Floor
`San Francisco, CA 94111-3834
`Tel: 415-576-0200
`
`Page 3 of 51
`
`

`

`Atty Docket No. 028482-004300US
`
`DOMAIN NAME SYSTEM WITH NETWORK TRAFFIC HARMONIZATION
`
`In the art today there are performance enhancing proxies and general standards for
`
`improvements of TCP performance in wired and wireless networks. Some of these
`
`techniques use clients and some are clientless. Some can look at network performance to
`
`enhance the optimization they provide. As noted, some may utilize a client and some may
`
`operate clientless. Some conventional techniques are focused on optimization based on only
`
`a one-sided view of the networks connected to such a platform — either outbound wired,
`
`inbound/outbound wireless. Some conventional techniques are based solely on the
`
`cooperation with a client.
`
`Description of One or More Embodiments of the Invention
`
`Embodiments of the present invention provide a system that optimizes multiple
`
`aspects of the connection with wired and wireless networks and devices through a complete
`
`view of activity including: loading, current application needs on a client, controlling the type
`
`of access (push vs. pull or hybrid), location, concentration of users in a single area, time of
`
`day, how often the user interacts with the application, content or device, and using this
`
`information to shape traffic to a cooperative client/server or simultaneously mobile devices
`
`without a cooperative client. Because the inventive server is not tied to any specific network
`
`provider it has visibility into the network performance across all service providers. This
`
`enables optimizations to be applied to devices regardless of the operator or service provider,
`
`thereby enhancing the user experience and managing network utilization while roaming.
`
`Bandwidth has been considered the major issue in wireless networks today. More and more
`
`research has been done related to the need for additional bandwidth to solve access problems
`
`— many of the performance enhancing solutions and next generation standards, such as LTE
`
`1
`
`Page 4 of 51
`
`

`

`Atty Docket No. 028482-004300US
`
`and WiMAX are focused on providing increased bandwidth. However, history has shown
`
`that this simply doesn't solve all the problems. A key problem is lack of bandwidth on the
`
`signaling channel more so than the data channel.
`
`Embodiments of the present invention align requests from multiple applications to
`
`minimize the need for several polling requests; leverage specific content types to determine
`
`how to proxy/manage a connection/content; and apply specific heuristics associated with
`
`device, user behavioral patterns (how often they interact with the device/application) and
`
`network parameters.
`
`Embodiments of the present invention move recurring http polls done by various
`
`widgets, RSS readers etc. to a fixed internet (NOC), thus considerably lowering device
`
`battery/power consumption, radio channel signaling, and bandwidth usage. Additionally,
`
`embodiments of the present invention do this transparently so that existing applications do
`
`not need to be changed. In some embodiments, this can be done by implementing a local
`
`proxy on the device which automatically detects recurring requests for the same content
`
`(RSS feed, Widget data set) that matches a specific rule (e.g. happens every 15 minutes) and
`
`automatically caches the content on the client while delegating the polling to the server (e.g.,
`
`to a proxy or virtual proxy operated as an element of a communications network). The server
`
`would then notify the mobile/client proxy if the content changes, and if content has not
`
`changed (or not changed sufficiently, or in an identified manner or amount) the mobile proxy
`
`provides the latest version in its cache to the user (without need to utilize the radio at all).
`
`This way the mobile device (e.g., a handset) does not need to open up or use a data
`
`connection if the request is for content that is monitored and that has been not flagged as
`
`new/changed.
`
`The logic for automatically adding URLs/content to be monitored can check for
`
`various factors like how often the content is the same, how often the same request is made (is
`
`there a fixed interval/pattern?), which application is requesting the data, etc. Similar rules to
`
`skip using the cache and request the data from the original source may also be used. For
`
`2
`
`Page 5 of 51
`
`

`

`Atty Docket No. 028482-004300US
`
`example, when the request comes at an unscheduled/unexpected time (user initiated check),
`
`or after every (n) consecutive times the response has been provided from the cache, etc., or if
`
`the application is running in the background vs. in a more interactive mode of the
`
`foreground. As more and more mobile applications base their features on resources available
`
`in the network, this becomes increasingly important. Embodiments of the present invention
`
`also remove unnecessary chatter from the network, benefitting the operators trying to
`
`optimize the wireless spectrum usage.
`
`In some embodiments, the present invention includes a distributed proxy for network
`
`traffic optimization, as shown in Figure 1. The main components include a proxy client
`
`running on a device [105], a proxy server running in the network [102], and an internal
`
`protocol between the proxy client and the proxy server [109, 110]. Typically, the proxy client
`
`and proxy server would be implemented as a set of instructions executed by a (micro)
`
`processor, although other implementations are possible (firmware, etc.). The proxy client,
`
`shown in Figure 2, includes connection management functionality [206], application protocol
`
`logic modules [213], a local cache [203], and an interface to retrieve information on device
`
`properties (e.g., information on device battery level, whether the device is being actively
`
`used or not, and the registered network) [210]. The proxy server, shown in Figure 3, includes
`
`connection management functionality [302], application protocol logic modules [310], a
`
`connection and content metadata database [303], and a device information database [304].
`
`In general operation, the proxy client [202] is an application independent proxy that
`
`mobile applications [200] can use to open any TCP connection to any host. The proxy client
`
`will detect the type of traffic and utilize an appropriate application protocol module [213] to
`
`process the traffic. With the chosen protocol/logic module, the proxy client may process the
`
`data locally and generate necessary talkback communication using its local cache,
`
`communicate the processed data along with device properties to the proxy server using the
`
`internal protocol [110], modify or delay any data before sending it to the proxy server, detect
`
`usage patterns between similar connections and provide this to the proxy server as
`
`connection metadata, or any combination of the above.
`
`3
`
`Page 6 of 51
`
`

`

`Atty Docket No. 028482-004300US
`
`If the proxy server is contacted regarding processing the original connection, the
`
`proxy server will utilize an appropriate application protocol module [310] to process the
`
`traffic. With the chosen protocol/logic module, the proxy server may contact the intended
`
`target of the connection and route the data from the proxy client to the target, generate
`
`talkback communication using its local cache, modify or delay any talkback communication
`
`data based on the device properties, and based on the connection metadata, start background
`
`processing to gather data for later use with similar connections, as well as any combination
`
`of the above.
`
`Both the proxy client and the proxy server will, where applicable continue to observe
`
`and process the data using the application protocol modules for the entire duration of the
`
`connection. After the original connection no longer exists, the proxy client and proxy server
`
`may still share information about the ceased connection and its properties for later use with
`
`similar connections. In this mode of operation, the proxy server may signal the proxy client
`
`that some data in its local cache is no longer up to date (and hence is stale), or alternatively
`
`pre-load the client cache with the fresh data. This can be done in bulk to avoid multiple radio
`
`requests, or on an application by application basis.
`
`From a mobile application's [200] point of view, the proxy is transparent and no
`
`modifications are needed in the way the application uses the connections. Proxy-aware
`
`mobile applications [212] may also be implemented, and can provide additional information
`
`about the connection characteristics to the proxy client.
`
`In some embodiments, the present invention offers benefits with respect to network
`
`usage, in that by serving requests from the local cache, the proxy client reduces the number
`
`of requests that are done over the wireless network. Further, the proxy client and the proxy
`
`server may filter irrelevant data from the communicated data. The proxy client and the proxy
`
`server may also accumulate low priority data and send it in batches to avoid the protocol
`
`overhead of sending individual data fragments. The proxy client and the proxy server may
`
`4
`
`Page 7 of 51
`
`

`

`Atty Docket No. 028482-004300US
`
`compress or transcode the traffic, reducing the amount of data sent over a wireless network.
`
`The signaling traffic in a wireless network is reduced, as the wireless network is used less
`
`often by optimizing small bursts away and the network traffic can be synchronized among
`
`individual applications.
`
`With respect to the battery life of a mobile device, by serving requests from the local
`
`cache, the proxy client reduces the number of times the radio module is powered up. The
`
`proxy client and the proxy server may accumulate low priority data and send it in batches to
`
`reduce the number of times and/or amount of time when the radio is powered up. The proxy
`
`client may synchronize the network usage by performing the batched data transfer for all
`
`connections simultaneously.
`
`In some embodiments, the present invention may be used in the case of home screen
`
`widget polling for data using HTTP, as shown in Figure 4. In the normal flow of operation,
`
`the widget performs a HTTP request to the data provider server [405, 406]. If the data has
`
`been updated, the widget refreshes itself. The widget waits for a small period of time and
`
`starts over at the initial step. With respect to using a distributed proxy, the widget performs a
`
`HTTP request via the proxy client [407, 408]. The proxy client detects the connection type to
`
`be a HTTP GET request. The proxy client checks the local cache for any previous
`
`information about the request.
`
`If the locally stored response is not available, the client updates all information about
`
`the request and the time it was made for later use. The client sends the request to the proxy
`
`server and the server performs the request and returns the results. The client stores
`
`information about the result and returns the result to the requestor. If the same request has
`
`occurred multiple times (within a certain time period) and it has often yielded same results,
`
`the client notifies the proxy server that the request should be monitored for result changes
`
`[409]. If the request was marked for monitoring, the client will store the results into its local
`
`cache. If the locally stored response is available, the client will return the response from the
`
`local cache without performing communication over the wireless network [413].
`
`5
`
`Page 8 of 51
`
`

`

`Atty Docket No. 028482-004300US
`
`Independently of the widget or client operation, the server proxy will perform the
`
`requests marked for monitoring to see whether the response has changed [410]. Whenever an
`
`unexpected response is received for some request, the server will notify the client that the
`
`response has changed and that the locally stored response on the client should be erased or
`
`replaced with a new response [416]. A subsequent data request by the client results in the
`
`data being returned from the proxy server [417, 418]. A benefit of using the distributed proxy
`
`in this case is that the wireless network is only used whenever the content for the widget has
`
`actually changed; the traffic required to check for the changes is not done over the wireless
`
`network. This reduces the amount of generated network traffic and shortens the total time
`
`and the number of times the radio module is powered up on the mobile device, thus reducing
`
`battery consumption.
`
`With respect to polling for changes in a mailbox, in the normal flow of operation, the
`
`mail client opens a connection to the mail server, the mail client authenticates with the server
`
`and queries for new email, and if new mail has arrived, a notification is shown. The mail
`
`client then closes the connection. The mail client waits for a period of time and starts over. A
`
`variation is to leave the connection open and start over at the second step after a
`
`predetermined period of time.
`
`In the context of a distributed proxy, the mail client opens a connection to the mail
`
`server via the proxy client, the proxy client detects the traffic type and the chosen application
`
`logic module simulates a mail server authentication, and the proxy client looks up from the
`
`local database whether information about the particular mail connection is available. If the
`
`information is not available, the connection is routed to the proxy server, the proxy server
`
`establishes a connection to the mail server and performs authentication using the data from
`
`the mail client, the data between the mail client and the mail server is directly routed through
`
`the proxy connection, and when the mail client closes the connection, the proxy client may
`
`choose to leave the actual connection to the backend open and store information about the
`
`connection into the local database for later use if the same mail connection has been used
`
`6
`
`Page 9 of 51
`
`

`

`Atty Docket No. 028482-004300US
`
`frequently. If the information is available, the client proxy will continue to simulate mail
`
`server responses for the mail client for all queries for which it has the data available. If the
`
`mail client performs an operation that cannot be simulated by the proxy client, the proxy
`
`client will route the data to the proxy server and the proxy server will pass the data to the
`
`mail server and route the data between the two. The proxy server may need to re-establish
`
`the connection to the mail server at this point. When the mail client closes the connection, the
`
`proxy client may choose to continue to store information about the connection for later use or
`
`it may request the proxy server to terminate the mail server connection and remove any
`
`information about the connection from the database.
`
`Independently of the mail client or the proxy client, the proxy server will query the
`
`mail server for any changes that the mail client has previously queried. If any information in
`
`the mail server has changed, the proxy server will notify the proxy client to stop simulating
`
`any responses based on locally cached data in order to let the mail client receive the changed
`
`data from the mail server.
`
`Embodiments of the present invention mitigate application protocol keep-alive traffic.
`
`Existing application protocols may provide long lived connections that allow servers to push
`
`updated data to the client without the need of the client to periodically re-establish the
`
`connection or to periodically query for changes. However, the client needs to be sure that the
`
`connection remains usable by periodically sending some data, often called a keep-alive
`
`message, to the server and making sure the server is receiving this data. While the amount of
`
`data sent for a single keep alive message is not significant and the keep-alive interval for an
`
`individual application is not too short, the cumulative effect of multiple applications
`
`performing this operation individually will amount to small pieces of data being sent very
`
`frequently. Frequently sending bursts of data in a wireless network results in high battery
`
`consumption by a mobile device due to the constant need of powering the radio module.
`
`Each burst will also require a significant amount of signaling traffic in a wireless network
`
`compared to the actual data being sent. By using the inventive distributed proxy model, the
`
`proxy client can prevent the keep-alive messages (or at least many of them) from being sent
`
`7
`
`Page 10 of 51
`
`

`

`Atty Docket No. 028482-004300US
`
`over the network and the proxy server can independently generate the required keep-alive
`
`messages to maintain the actual backend connection.
`
`In alternative embodiments, the proxy client can be implemented directly into the
`
`TCP/IP stack of the device operating system. The proxy client can be bundled into a wireless
`
`modem to provide transparent use for the device operating system. The proxy client can also
`
`be bundled into a firewall or a router to provide transparent use for the device operating
`
`system.
`
`Alternative embodiments apply similar techniques for a variety of protocols including
`
`HTTP, HTTPS, IMAP, POP, SMTP and ActiveSync. Use of application specific protocol
`
`handlers allows for optimization of any protocol that can be port mapped to a hander in the
`
`distributed proxy.
`
`Domain Name System With Network Traffic Harmonization
`
`Domain Name System (DNS) records typically expire from a Resolver's cache after a
`
`short time-to-live period specified in the record. This permits site administrators to change
`
`the IP addresses of their servers without worrying that users will try to contact those servers
`
`at their old addresses. Over time repeated queries consume network resources and consume
`
`battery life. This is a concern for mobile devices where resources are limited.
`
`In at least one embodiment, records returned from a network Domain Name Server
`
`may be cached in a manner which integrates with a local content caching system and web-
`
`based service to reduce network traffic related to DNS queries, while ensuring that client
`
`applications have access to valid DNS records.
`
`At least one embodiment functions in accordance with the following illustrative
`
`example.
`
`8
`
`Page 11 of 51
`
`

`

`Atty Docket No. 028482-004300US
`
`A transmission control protocol (TCP) socket connection may require a destination
`
`internet protocol (IP) address like "69.63.189.11". A browser or application will typically use
`
`a more human-readable hostname equivalent like "www.facebook.com". To convert from a
`
`hostname to an IP address, the application calls upon the platform's Domain Name System
`
`Resolver to resolve the hostname. For example:
`
`1. Application to Resolver: "I need to get an address for www.facebook,com".
`
`2. Resolver to Nameserver: "I've never heard of w\Amr.facebook,com, have you?"
`
`3. Nameserver to Resolver: "Yes, the address is 69.63.189.11".
`
`4. Resolver to Application: "Found it, you can open a socket to 69.63.189.11".
`
`Note that the Nameserver resides in the network and reaching it requires some over-
`
`the-air traffic with attendant radio use and battery consumption. To reduce this impact, a
`
`Resolver may include a cache of recent DNS responses with a short duration. If an
`
`application tries to resolve a hostname twice in that span, it will receive a cached response
`
`instead of going over the air. For example:
`
`1. Application to Resolver: "I need to get an address for www.facebook.com".
`
`2. Resolver to Application: "That's in my cache already, so I don't need to contact the
`
`Nameserver. You can open a socket to 69.63.189.11".
`
`Note that the Resolver cache time-to-live may be relatively low (e.g., 10 minutes). If
`
`sequential requests are generated by local applications just above that setting (e.g., every 15
`
`or 30 minutes), the Resolver cache will provide no benefit with respect to radio state change
`
`and packets over the wireless network. In at least one embodiment, an additional
`
`Harmonization component may cache records for much longer period (e.g., 60 minutes). This
`
`time period is configurable, depending on the predetermined lifetime per platform, based on
`
`the requirement of a particular deployment.
`
`9
`
`Page 12 of 51
`
`

`

`Atty Docket No. 028482-004300US
`
`As an example, consider a Facebook application that polls a URL (e.g,
`
`"api.facebook.com") every 30 minutes and establishes a polling task at the Harmonization
`
`server. The initial DNS response for "api.facebook.com" may remain in the device's
`
`Harmonization cache for the life of that polling task. The Harmonization cache entry is
`
`reference counted ("refcounted"), so a second polling session referencing
`
`"api.facebook.com" will increment the reference count ("refcount"). The refcount may be
`
`decremented on invalidate or stop poll commands from the Harmonization server. Entries
`
`may expire from the Harmonization cache when their refcount reaches zero or their age in
`
`the cache reaches a threshold (e.g., 24 hours), whichever comes first.
`
`An example timeline of this Harmonization functionality is shown in Table 1.
`
`Time
`
`Client
`
`Server
`
`Comments
`
`OmOs
`
`Request #1 to
`example.com
`
`Request #2 to
`example.com
`
`Request #3 to
`example.com
`
`DNS entry retrieved and
`cached by Harmonization
`component
`
`DNS entry taken from Resolver
`cache
`
`Resolver cache entry for
`example.com expires
`
`DNS entry taken from
`Harmonization cache
`
`4mOs
`
`14m5s
`
`lmOs
`
`Send polling
`task to server
`
`Start polling example.com Harmonization cache entry
`refcount++ (becomes 1)
`
`Request #4 to
`example.com
`
`DNS entry taken from
`Harmonization cache; response
`taken from Harmonization
`cache
`
`Continue polling
`example.com
`
`This is when the
`
`10
`
`Page 13 of 51
`
`

`

`Atty Docket No. 028482-004300US
`
`Harmonization cache entry
`would expire if there were no
`polled resources tied to it
`
`70m5s
`
`Receive new content in poll
`response, send cache
`invalidate to Harmonization
`component at client
`
`70m1Os (cid:9)
`
`i Cache
`invalidate (cid:9)
`received
`
`7mOs (cid:9)
`
`Request #12 to (cid:9)
`example.com (cid:9)
`
`Harmonization cache entry
`refcount-- (becomes 0);
`example.com removed from
`Harmonization cache
`
`DNS entry retrieved and
`cached by Harmonization
`component at client
`
`Table 1.
`
`The DNS Harmonization Proxy intercepts Resolver requests (e.g., DNS protocol
`
`messages) that are meant to go over the wireless network. It functions as a repeater,
`
`forwarding the request over the network but also observing and recording the traffic. Once
`
`the DNS Harmonization Proxy has observed a successful request and response pair, it
`
`records them in its Harmonization cache with the configured lifetime (e.g., 60 minutes). If
`
`the DNS Harmonization Proxy receives a similar request, it can simply replay the last
`
`successful response instead of forwarding the request over the air.
`
`On a mobile device, a DNS Harmonization Proxy may intercept an outgoing DNS
`
`query for a hostname and check for matching responses in a Harmonization cache.
`
`Harmonization cache hits are returned to the Resolver (e.g., previously intercepted protocol
`
`messages may be replayed to the Resolver). Cache misses may result in the outgoing DNS
`
`query being forwarded to the configured Domain Name Server for resolution, and the
`
`response placed into the DNS Harmonization Proxy's cache for future use. When an
`
`application contacts the resolved IP address a related local content caching system may
`
`engage a network Harmonization proxy to monitor that content, and instruct the DNS
`
`11
`
`Page 14 of 51
`
`(cid:9)
`(cid:9)
`

`

`Atty Docket No. 028482-004300US
`
`Harmonization Proxy to retain the resolved IP address. The DNS Harmonization Proxy may
`
`now respond to queries for that cached address with confidence that the network
`
`Harmonization proxy will advise when the record becomes invalid (e.g., will send a
`
`Harmonization cache invalidation message). In at least one embodiment, resolution requests
`
`for that host name may now be serviced by the client-side DNS Harmonization Proxy
`
`resulting in reduced network and power usage.
`
`Figure 5 depicts an example DNS Harmonization architecture 500 in accordance with
`
`at least one embodiment. The architecture 500 includes a mobile device 502 connected to a
`
`wireless network 504 by a radio 506. The wireless network 504 is communicatively coupled
`
`to a domain name system 508. The communicative coupling of the wireless network 504 and
`
`the domain name system 508 may be facilitated by an Harmonization server 510. The
`
`mobile device may be any suitable mobile computing device. Examples of suitable mobile
`
`computing devices include mobile phones, cell phones, smart phones, personal digital
`
`assistants, netbook computers, laptop computers, and consumer electronics incorporating one
`
`or more computer processors and/or radios. The domain name system 508 may be a
`
`computer network (e.g., a public computer network such as the Internet) that incorporates
`
`one or more computers configured to participate in a domain name system in accordance
`
`with one or more Internet Engineering Task Force (IETF) Request for Comments (RFC)
`
`documents including P. Mockapetris, "Domain Names — Concepts and Facilities", IETF RFC
`
`1034, November 1987, P. Mockapetris, "Domain Names — Implementation and
`
`Specification", IETF RFC 1035, November 1987, R. Braden et al., "Requirements for
`
`Internet Hosts — Application and Support", IETF RFC 1123, October 1989, and/or Elz et al.,
`
`"Clarifications to the DNS Specification", IETF RFC 2181, July 1997, each of which is
`
`incorporated herein by reference.
`
`The mobile device 502 may maintain multiple computing spaces including a system
`
`space 512 separate from a user space 514. For example, the system space 512 may
`
`correspond to a set of computing resources reserved for an operating system of the mobile
`
`device 502, and the user space 514 may correspond to a set of computing resources reserved
`
`12
`
`Page 15 of 51
`
`

`

`Atty Docket No. 028482-004300US
`
`for computing applications accessed by one or more users of the mobile device 502 such as
`
`user application 516. For example, user application 516 may be a web browser or any
`
`suitable application that makes application programming interface (API) calls 518 to a DNS
`
`Resolver 520. For example, the DNS Resolver 520 may be a conventional DNS Resolver of
`
`a conventional mobile device operating system. As will be apparent to one of skill in the art,
`
`the DNS Resolver 520 may maintain a local DNS cache 522 configured at least to cache
`
`associations between domain names and network addresses, and may generate conventional
`
`DNS protocol messages 524.
`
`In at least one embodiment, the mobile device 502 may further include a DNS
`
`Harmonization component 526 configured at least to monitor and/or intercept outgoing DNS
`
`protocol messages 524 and associated responses. The DNS Harmonization component 526
`
`may store DNS protocol request/response pairs in an Harmonization cache 528, and may
`
`match outgoing DNS protocol messages 524 to stored pairs. Should a match be found, the
`
`DNS Harmonization component 526 may generate a responsive DNS protocol message
`
`based at least in part on the stored response of the matching pair. Otherwise, the DNS
`
`Harmonization component 526 may forward the outgoing DNS protocol message 524 to the
`
`domain name system 508 via the radio 506, and wireless network 504. With respect to
`
`stored request/response pairs, the DNS Harmonization component 526 may instruct the
`
`Harmonization server 510 to monitor the domain name system 508 for changes to
`
`corresponding domain name-network address associations ("address bindings"). Upon
`
`detection of such a change, the Harmonization server 510 may notify the DNS
`
`Harmonization component 526 to invalidate the corresponding Harmonization cache 528
`
`entry, so that it will be refreshed once the local DNS cache 522 entry becomes invalid (which
`
`occurs independently).
`
`13