Application Data Sheet
`
`Application Information
`
`Application number::
`
`Not yet assigned
`
`Herewith
`
`Provisional
`
`Utility
`
`Filing Date::
`
`Application Type::
`
`Subject Matter::
`
`Suggested classification::
`
`Suggested Group Art Unit::
`
`CD-ROM or CD-R??::
`
`Number of CD disks::
`
`Number of copies of COs::
`
`Sequence Submission::
`
`Computer Readable Form (CRF)?::
`
`Number of copies of CRF::
`
`Title::
`
`POLLING INTERVAL FUNCTIONS
`
`Attorney Docket Number::
`
`028482-004400US
`
`Request for Early Publication::
`
`Request for Non-Publication::
`
`Suggested Drawing Figure::
`
`Total Drawing Sheets::
`
`Small Entity?::
`
`Latin name::
`
`Variety denomination name::
`
`Petition included?::
`
`Petition Type::
`
`Licensed US Govt. Agency::
`
`Contract or Grant Numbers One::
`
`No
`
`No
`1
`
`7
`
`No
`
`Secrecy Order in Parent Appl.::
`
`No
`
`Page 1
`
`lnitial11/22/10
`
`Page 1 of 52
`
`GOOGLE EXHIBIT 1017
`
`

`

`Applicant Information
`
`Applicant Authority Type::
`
`Primary Citizenship Country::
`
`Status::
`
`Given Name::
`
`Middle Name::
`
`Family Name::
`
`Name Suffix::
`
`Inventor
`us
`Full Capacity
`
`Stan
`
`Campbell
`
`City of Residence::
`
`State or Province of Residence::
`
`·Country of Residence::
`
`Street of Mailing Address::
`
`El Granada
`
`CA
`us
`431 Almeria Avenue
`
`City of Mailing Address::
`
`El Granada
`
`State or Province of mailing address::
`
`CA
`us
`Postal or Zip Code of mailing address:: 94018
`
`Country of mailing address::
`
`Correspondence Information
`
`Correspondence Customer Number::
`
`20350
`
`Representative Information
`
`Representative Customer Number::
`
`20350
`
`Domestic Priority Information
`
`Application::
`
`Continuity Type::
`
`Parent Application:: Parent Filing Date::
`
`Foreign Priority Information
`
`Country::
`
`Application number::
`
`Filing Date::
`
`Page2
`
`lnitial11/22/10
`
`Page 2 of 52
`
`

`

`Assignee Information
`
`Assignee Name::
`
`Street of mailing address::
`
`City of mailing address::
`
`State or Province of mailing address::
`
`Country of mailing address::
`
`Postal or Zip Code of mailing address::
`
`· Submitted by:
`
`Signature
`
`/Alan D. Minsk/
`--------------------~---------
`Printed Name
`Alan D. Minsk
`----------------------------
`
`Date November 22, 2010
`
`Registration Number ______ 3_5.._,9_5_6 ____ _
`
`Page 3
`
`Initial 11/22/10
`
`Page 3 of 52
`
`

`

`ATTORNEY DOCKET No.: 028482-004400US
`
`PROVISIONAL PATENT APPLICATION
`
`POLLING INTERVAL FUNCTIONS
`
`Inventor:
`
`Stan Campbell, a citizen of the United States,
`
`residing at El Granada, CA, 94018
`
`Assignee:
`
`Seven Networks, Inc.
`
`Entity:
`
`Small
`
`TOWNSEND and TOWNSEND and CREW LLP
`Two Embarcadero Center, Eighth Floor
`San Francisco, CA 94111-3834
`Tel: 415-576-0200
`
`Page 4 of 52
`
`

`

`POLLING INTERVAL FUNCTIONS
`
`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.
`
`Almost all, if not all, 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, or
`
`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 L TE 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
`
`Page 5 of 52
`
`

`

`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 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.
`
`Page 6 of 52
`
`

`

`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 [31 0], 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 [11 0],
`
`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.
`
`If the proxy server is contacted regarding processing the original connection, the proxy
`
`server will utilize an appropriate application protocol module [31 0] 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 talk back
`
`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.
`
`Page 7 of 52
`
`

`

`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 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
`
`Page 8 of 52
`
`

`

`synchronize the network usage by performing the hatched 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].
`
`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
`
`Page 9 of 52
`
`

`

`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 frequently. Ifthe 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.
`
`Page 10 of 52
`
`

`

`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 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.
`
`Page 11 of 52
`
`

`

`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.
`
`Page 12 of 52
`
`

`

`Polling Interval Functions
`
`In some embodiments, the present invention applies a method similar to a (ship) gun
`
`battery fire control (with observer tactics) as a protocol for defining a polling interval function.
`
`In a typical situation, a set of resources need to be polled for changes to satisfy a
`
`consistency level (to be defined) of queries on those resources. Consider the elements in this set
`
`as consisting of expressions matching closely related resources. For instance,
`
`ur/1 = http://www.example.com/someapp/rest?page=3&garbage=[\d+]
`
`In some embodiments, one may regard the changes to the members of the set of target
`
`uri's as a subset within a larger set of the uri's (e.g., within the application, physical, or logical
`
`domain).
`
`In some embodiments, consider this as a line with dots along it representing queries in the
`
`space of uri member through time (as depicted below, for example):
`
`uriO --x--x--x--x--x
`
`Now define a polling interval as two points along the line between which a poll of a
`
`resource is to take place. Note that it is not guaranteed that the poll will take place or end at any
`
`given point within this interval, only that it will begin and finish within this interval.
`
`pf() -pp-pp-pp-pp-pp
`
`Now consider a search for the definition (or description) of the polling function (or a
`
`possible such function) as similar to solving the ballistics problem of firing on a moving target
`
`Page 13 of 52
`
`

`

`with the aid of an observer. Note that an analysis of these types of functions can be found in
`
`"Linear Interval Equations", Ratschek and Sauer, Computing 28, Springer Verlag 1980.
`
`There are three entities involved: a remote device (similar to the observer), the server
`
`(similar to the ship), and the proper polling function definition (similar to the target). We
`
`typically have information from two of the entities. In some embodiments, the third may be
`
`known or approximated by observations made by either the remote device or the server (i.e., the
`
`observer or the ship).
`
`By making adjustments to the assumed polling function, by observing the results, and by
`
`shifting the roles when better observations may be made by either party (the remote device or the
`
`server), the invention may yield the most useful polling function within a given period or number
`
`of observations. In an example operation, we score a certain number of hits (defined as polls
`
`when a resource is changed within an interval) versus misses (defined as where a resource
`
`changed outside of a threshold from the polling interval window, or we polled too often and
`
`missed the change). Using this approach, the present invention can model the problem and
`
`define a more suitable (or optimal) polling function (e.g., a polling function that results in polls
`
`being generated in a more efficient manner, such as polls that have a higher likelihood of
`
`occurring within an interval containing the time at which a change in data occurs).
`
`If we model the entities as above, and determine the messages sent between them,
`
`embodiments of the invention are able to make dynamic changes to an assumed polling function,
`
`yielding an improved number of successful predictions of resource change(s).
`
`In one embodiment, arbitrarily define the polling function over the set of URL's to be
`
`matched and define the sets of urls and the interval functions, as described in the following
`
`example:
`
`Page 14 of 52
`
`

`

`L:Set[String] = {the set of all possible valid URL 's, possibly including query parameters
`
`}
`
`ftgt{url E L):Boolean =a function matching a set ofurl's comprising the target}
`
`fp(t:Long as milliseconds):Boolean =whether or not to poll at moment t
`
`If the functionfp is regarded as an interval function over the set of compact intervals, then
`
`we can bring an algebra for combining those functions to bear.
`
`For example, if I is the set of integral compact intervals, then let
`
`A*B = { a*b:aEA,bEB} for A,BEl and *E{+,-,.,:}
`
`Operations On Url Matching Functions
`
`In addition, we can apply well-defined principles of functional composition to the notion
`
`ofurl matching functions. By composing those functions, we can collapse or partition the sets of
`
`resources matched by those urls. In addition, we can further compose the interval functions in
`
`order to specify polling functions for the union or disjoint union of the composed url functions.
`
`When trying to establish a polling function for a set of url functions, we can manipulate
`
`(via composition or partition) the url functions, and by extension the underlying polling
`
`functions, to obtain a new polling function or functions for the composed or partitioned sets.
`
`Page 15 of 52
`
`

`

`In these terms, the search for an effective solution to the polling interval function for the
`
`url functions, urlo, urlr, ... urln, depends on solving the composition of the underlying polling
`
`functions /tgt(ur!J.
`
`By adjusting the underlying functions until they are effective for the given urls, and then
`
`by composing those specific functions in a well-defined way, the invention may be used to
`
`generate an effective polling function for the composition of the url functions.
`
`Note that diagrams 5, 6, and 7 provide a rough outline of the messages that could be part
`
`of a protocol used in implementing some embodiments of the invention.
`
`Page 16 of 52
`
`

`

`POLLING INTERVAL FUNCTIONS
`
`What is claimed is:
`
`1.
`
`A method of determining a polling interval for obtaining data from a data source,
`
`compnsmg:
`
`determining an initial polling function;
`
`varying the initial polling function in response to data obtained from a client or a
`
`server that enables a determination of whether the function resulted in a poll during an interval in
`
`which the data source changed; and
`
`dynamically altering the polling function in response to the determination of
`
`whether the function resulted in a poll during an interval in which the data source changed.
`
`Page 17 of 52
`
`

`

`Intern e:t [1 001
`
`[106]
`
`Cachin;g \Veb
`Proxy [101]
`
`[108]
`
`SE\I'EN
`Ne:tvtork Harmonizer
`Serve:r [102]
`
`[110]
`
`SMSC[103]
`
`~ ~·
`
`[106} \4 ~109]
`
`Mobi I e Cl ierrts - r-(cid:173)
`[105]
`
`I
`
`I
`Figure 1 SEVEN Network H armoniz:er System Architecture
`
`Page 18 of 52
`
`

`

`Pro:xy-Un,aw:are
`Mobil,e
`.Appl icatioo
`[200]
`
`Proxy-AwareM'obile
`Application
`[212]
`
`jl"'
`
`Caching
`Policy
`[204]
`
`App.
`Protocols
`[213]
`
`I Client-Side Pre«y API [201]
`
`Clie,nt-SidePrm:y [202]
`
`I
`
`--'
`
`,..,..i'
`
`c
`Cache
`[203]
`... --
`
`Tr,affic
`Shaping
`[205]
`
`Conn,E!'Ction
`Mana§ement
`[206]
`
`Device Operating System
`[2.11]
`
`Device Conte«: API
`[210]
`
`SMSI/F
`[.207]
`
`WiFii/F
`[208)
`
`3G/4G 1/F
`[209}
`
`Figure2 SEVEN Network Harmonizer Client Architecture
`
`Page 19 of 52
`
`

`

`w,eb
`Access
`[309]
`
`Caching
`Policy [3oct
`
`Appl icatioo
`Protocols
`[.310]
`
`Proxy Control
`Protocol
`[306]
`
`Hybrid Control
`Protocol
`[30&]
`
`Control
`Protocol
`[307]
`
`SMS Con:trol
`Protocol
`[305)
`
`Traffic Shaping
`[301]
`
`Connection
`Management
`[302]
`
`Connection and
`Content Metadata
`DB [303]
`
`Device Information
`DB [304)
`
`Figure 3 SEVEN Network Harmonizer Server Architecture
`
`Page 20 of 52
`
`

`

`I Home Screen I
`
`Widget [400]
`
`I CHent-Side I
`
`ProKy [401}
`
`I Caching Web I I Traffic Hannonizer I
`
`Server[4fl3j
`
`Proxy [402]
`
`I Data Provider Server I
`
`[404]
`
`Data Request [405}
`
`Data Response [406]
`
`Proxled Data Request~~ 1
`
`roxled Data Response [4
`!/
`
`S]
`
`Me [liter Data Request [409J
`
`Prmded Data Request~ 12!
`
`Request Satisfied From ocal Cache [4131
`
`'
`
`lnvalidateN
`
`[416]
`
`Prmded Data Request~ 17}
`
`/ Request Satisfied From f:aching Web Proxy [418]
`
`/
`
`,
`
`Monitor Data [410j
`
`Same Response !411]
`
`Monitor Data [4141
`
`Changed Response !415j
`
`Figure 4 SEVEN Network Harmonizer Distributed Proxy Polling
`
`Page 21 of 52
`
`

`

`: ON_STATIONjs<Warl<l,capabiliiJes)
`
`2: FIRE_MISSION{dientl<l, tgtU!I, tgtld)
`
`:>: ACK{allentl<l,tgtld)
`
`4:
`
`in {CLIENT_ADJUST,
`SERVER ADJUST,
`.FIP~_FOP._EFFECT}
`
`'sERVER_ ADJUST
`
`6: FETCHO¢Udj
`
`!!: FETCH(l9tUJij
`
`F
`
`Figure 5.
`
`Page 22 of 52
`
`

`

`4: UPDATED
`
`5' FETCH(tgtUrl)
`
`8: UPDATED
`
`9: chook cadle, ca!cSHORT, LONG, tilT
`
`10:
`
`11: adjust pdlliog inl<n>a! and Window
`
`12: FETCH{tg!Utl)
`
`Figure 6.
`
`Page 23 of 52
`
`

`

`~·when satisfied with cache
`] petfot:mance.,. client may
`,,, call "Fite foe Effect"
`
`1: UPil'<TED
`
`2: <:OOd< cache, calc SHORT, LONG, HIT
`
`3: FIRE_FOR_EFFECT{c..,Ud,tgtld)
`
`4: ACK{<lie<ltld,l(ltld)
`
`!1: UPil'<TED
`
`set:ver: then stops coa.t:se(cid:173)
`gt:ained adjustments to
`polling function
`
`5: FETCH(I{;tUf.)
`
`6: DATA
`
`Figure 7.
`
`Page 24 of 52
`
`

`

`Electronic Patent Application Fee Transmittal
`
`Application Number:
`
`Filing Date:
`
`Title of Invention:
`
`POLLING INTERVAL FUNCTIONS
`
`First Named Inventor/Applicant Name:
`
`Stan Campbell
`
`Filer:
`
`Alan D. Minsk/Stacy Villa rose
`
`Attorney Docket Number:
`
`028482-004400US
`
`Filed as Small Entity
`
`Provisional Filing Fees
`
`Description
`
`Fee Code
`
`Quantity
`
`Amount
`
`Sub-Total in
`USD($)
`
`Provisional Application filing fee
`
`2005
`
`1
`
`110
`
`110
`
`Basic Filing:
`
`Pages:
`
`Claims:
`
`Miscellaneous-Filing:
`
`Petition:
`
`Patent-Appeals-and-Interference:
`
`Post-Allowance-and-Post-Issuance:
`
`Extension-of-Time:
`
`Page 25 of 52
`
`

`

`Description
`
`Fee Code
`
`Quantity
`
`Amount
`
`Sub-Total in
`USD($)
`
`Miscellaneous:
`
`Total in USD ($)
`
`110
`
`Page 26 of 52
`
`

`

`Electronic Acknowledgement Receipt
`
`EFSID:
`
`Application Number:
`
`8888527
`
`61416033
`
`International Application Number:
`
`Confirmation Number:
`
`9822
`
`Title of Invention:
`
`POLLING INTERVAL FUNCTIONS
`
`First Named Inventor/Applicant Name:
`
`Stan Campbell
`
`Customer Number:
`
`20350
`
`Filer:
`
`Alan D. Minsk/Stacy Villa rose
`
`Filer Authorized By:
`
`Alan D. Minsk
`
`Attorney Docket Number:
`
`028482-004400US
`
`Receipt Date:
`
`22-NOV-201 0
`
`Filing Date:
`
`TimeStamp:
`
`Application Type:
`
`Payment information:
`
`Submitted with Payment
`
`Payment Type
`
`Payment was successfully received in RAM
`
`RAM confirmation Number
`
`Deposit Account
`
`Authorized User
`
`15:06:24
`
`Provisional
`
`yes
`
`Deposit Account
`
`$110
`
`1737
`
`201430
`
`The Director of the USPTO is hereby authorized to charge indicated fees and credit any overpayment as follows:
`
`Charge any Additional Fees required under 37 C.F.R. Section 1.16 (National application filing, search, and examination fees)
`
`Charge any Additional Fees required under 37 C.F.R. Section 1.17 (Patent application and reexamination processing fees)
`
`Page 27 of 52
`
`

`

`Charge any Additional Fees required under 37 C.F.R. Section 1.19 (Document supply fees)
`
`Charge any Additional Fees required under 37 C.F.R. Section 1.20 (Post Issuance fees)
`
`Charge any Additional Fees required under 37 C.F.R. Section 1.21 (Miscellaneous fees and charges)
`
`File Listing:
`
`Document
`Number
`
`Warnings:
`
`Information:
`
`Document Description
`
`File Name
`
`File Size( Bytes)/
`Message Digest
`
`Multi
`Part /.zip
`
`Pages
`(if appl.)
`
`2010_11_22_FWR_ADS_APPLN
`_FIGS_028482-004400US.pdf l - - - - - - - - - - - l
`8d05d63b399e6454a35c034669dd4e309c
`ed2f7a
`
`781365
`
`yes
`
`24
`
`Multipart Description/PDF files in .zip description
`
`Document Description
`
`Start
`
`End
`
`Application Data Sheet
`
`Specification
`
`Claims
`
`Drawings-only black and white line drawings
`
`3
`
`16
`
`17
`
`24
`
`1
`
`4
`
`17
`
`18
`
`29412
`
`2
`
`Fee Worksheet (PT0-875)
`
`fee-info. pdf
`
`no
`
`2
`
`658b511 f9253d5f3a3f0dfad6ecc60374994
`4678
`
`Warnings:
`
`Information:
`
`Total Files Size (in bytes)
`
`810777
`
`This Acknowledgement Receipt evidences receipt on the noted date by the USPTO of the indicated documents,
`characterized by the applicant, and including page counts, where applicable. It serves as evidence of receipt similar to a
`Post Card, as described in MPEP 503.
`
`New Applications Under 35 U.S.C. 111
`If a new application is being filed and the application includes the necessary components for a filing date (see 37 CFR
`1.53(b)-(d) and MPEP 506), a Filing Receipt (37 CFR 1.54) will be issued in due course and the date shown on this
`Acknowledgement Receipt will establish the filing date of the application.
`
`National Stage of an International Application under 35 U.S.C. 371
`If a timely submission to enter the national stage of an international application is compliant with the conditions of 35
`U.S.C. 371 and other applicable requirements a Form PCT/DO/E0/903 indicating acceptance of the application as a
`national stage submission under 35 U.S.C. 371 will be issued in addition to the Filing Receipt, in due course.
`
`New International Application Filed with the USPTO as a Receiving Office
`If a new international application is being filed and the international application includes the necessary components for
`an international filing date (see PCT Article 11 and MPEP 181 0), a Notification of the International Application Number
`and of the International Filing Date (Form PCT/R0/1 OS) will be issued in due course, subject to prescriptions conc