(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2012/0023190 A1
`(43) Pub. Date:
`Jan. 26, 2012
`Backholm et al.
`
`US 20120023190A1
`
`(54)
`
`MOBILE NETWORK TRAFFIC
`COORONATION ACROSS MULTIPLE
`APPLICATIONS
`
`(76)
`
`Inventors:
`
`Ari Backholm, Espoo (FI);
`Michael Luna, San Jose, CA (US);
`Heikki Ylinen, Espoo (FI)
`
`(21)
`
`Appl. No.:
`
`13/115,631
`
`(22)
`
`Filed:
`
`May 25, 2011
`
`(60)
`
`Related U.S. Application Data
`Provisional application No. 61/367,871, filed on Jul.
`26, 2010, provisional application No. 61/367,870,
`filed on Jul. 26, 2010, provisional application No.
`61/408,858, filed on Nov. 1, 2010, provisional appli
`cation No. 61/408,839, filed on Nov. 1, 2010, provi
`sional application No. 61/408,829, filed on Nov. 1,
`2010, provisional application No. 61/408,846, filed on
`Nov. 1, 2010, provisional application No. 61/408,854,
`filed on Nov. 1, 2010, provisional application No.
`61/408,826, filed on Nov. 1, 2010, provisional appli
`cation No. 61/408,820, filed on Nov. 1, 2010, provi
`sional application No. 61/416,020, filed on Nov. 22,
`
`2010, provisional application No. 61/416,033, filed on
`Nov. 22, 2010, provisional application No. 61/430,
`828, filed on Jan. 7, 2011.
`Publication Classification
`
`(51) Int. Cl.
`(2006.01)
`G06F 9/46
`(2006.01)
`G06F 5/16
`(52) U.S. Cl. ......................................... 709/217; 71.9/313
`(57)
`ABSTRACT
`Systems and methods for mobile network traffic coordination
`across multiple applications are disclosed. In one aspect,
`embodiments of the present disclosure include a distributed
`proxy and cache system, including, a local proxy on a mobile
`device for intercepting a data request made via a mobile
`device, and a proxy server coupled to the mobile device and a
`content server to which the data request is directed. One
`embodiment includes, delaying transfer of a first data transfer
`request initiated by a first application until another data trans
`ferrequest initiated by a second application is detected on the
`mobile device and transferring, the first data transfer request
`of the first application and the other data transfer request of
`the second application a single transfer operation over the
`network.
`
`Application Behavior Detector 236
`
`
`
`Pattern Detector 237
`
`
`
`User Activity Module L.
`215
`
`
`
`Prioritization
`Engine 241
`
`
`
`. - Correlation Detector 238
`
`Application Profile Generator
`239
`
`Application Status
`Detector 240
`
`Traffic Shaping Engine 255
`
`Alignment Module 256
`
`Batching Module
`257
`
`Delay Module
`258
`
`
`
`
`
`
`
`
`
`
`
`
`
`Page 1 of 34
`
`GOOGLE EXHIBIT 1011
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 1 of 14
`
`US 2012/0023190 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Page 2 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 2 of 14
`
`US 2012/0023190 A1
`
`
`
`
`
`
`
`
`
`110
`
`App Server/
`Content Provider
`
`NetWork
`108
`
`Optional Caching
`Proxy Server
`
`100
`
`- -
`
`- - - - -- - - -
`
`Host Server
`
`
`
`
`
`
`
`Proxy server
`
`Server Cache
`135
`
`
`
`
`
`Short Message
`Service Center
`112
`
`Netwo
`rk
`106
`
`
`
`150
`
`/
`
`
`
`Page 3 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 3 of 14
`
`US 2012/0023190 A1
`
`
`
`Mobile Device
`250
`
`Proxy-Unaware
`Mobile
`Application
`210
`
`Proxy-Aware Mobile
`Application
`220
`
`Proxy API 225
`
`Caching Policy
`Manager
`245
`Application
`Protocol
`Module
`248
`-
`
`USer
`Activity
`Module
`215
`-
`
`Request/Transaction Manager
`235
`Application Behavior
`Detector 236
`Pattern Detector
`237
`
`Prioritiza
`tion
`Engine
`241
`
`Application Profile
`Generator 239
`
`Traffic Shaping Engine 255
`Alignment
`Batching
`Module
`Module
`256
`257
`
`Connection
`Manager 265
`
`Controller 266
`Heartbeat
`Manager 267
`
`Network interface 208
`SMS I/F
`WiFi/F Cellular IF
`
`Context AP
`206
`
`Operating
`s"
`
`FIG. 2A
`
`Page 4 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 4 of 14
`
`US 2012/0023190 A1
`
`Application Behavior Detector 236
`
`
`
`
`
`Pattern Detector 237
`
`
`
`User Activity Module L.
`215
`
`
`
`Correlation Detector 238
`
`Prioritization
`Engine 241
`
`Application Profile Generator
`239
`
`Application Status
`DetectOr 240
`
`Traffic Shaping Engine 255
`
`Alignment Module 256
`
`Batching Module
`257
`
`Delay Module
`258
`
`
`
`
`
`
`
`
`
`
`
`
`
`Page 5 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 5 of 14
`
`US 2012/0023190 A1
`
`
`
`
`
`Application Server/
`Service Provider
`310
`
`Network Interface 308
`
`Host Server
`300
`
`Proxy Server
`325
`
`HTTP ACCeSS
`Engine 345
`
`New Data
`Detector 347
`
`Proxy Controller 365
`Activity/Behavior
`Awareness Module 366
`Priority Awareness
`Module 367
`Data invalidator Module
`368
`
`Traffic Shaping
`Engine 375
`
`Control Protocol
`376
`Batching Module
`377
`
`Caching Policy
`Manager 355
`Application
`Protocol
`Module
`
`Connection Manager 395
`
`Radio
`Controller
`396
`
`Internet/WiFi
`Controller
`397
`
`Heartbeat
`Manager
`398
`
`
`
`Connection and
`Content Metadata
`Repository 312
`
`
`
`Device information
`Repository 314
`
`
`
`
`
`Network Service
`Provider
`Repository 316
`
`FIG. 3
`
`Page 6 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 6 of 14
`Jan. 26, 2012 Sheet 6 of 14
`
`US 2012/0023190 A1
`US 2012/0023190 A1
`
`
`
`Emficootmamman?
`
`V»65%
`
`a525.;
`
`
`
`NS»EmaL9:52)—
`
`
`
`ivmwcoammmmEmw
`
` o3“820$.
`mmvmwcoawmmvwmcmcocosmoczoz23:95
`
`
`
`
`omvEND5::22w;wcomo_woo._Ein.umcwzmwuwmzawm
`
`
`
`
`a58;.flmg6%?
`
`mcfomo>xoi$0045259:01
`
`
`
`
`
`at»omv
`
`
`
`
`
`mn_w¢w>._wmmoSwD£522
`
`56585955
`
`£295
`
`omv
`
`{|J\I||l\
`
`Page 7 0f 34
`
`
`
`Emauw_xo.n_
`
`8v393m
`
`
`
`Emauflxoi
`
`wowwmcoammm
`
`Ema8:52
`
`wwv
`
`
`
`San.2:on
`
`m3.$331
`
`
`
`Emaum_x9n_
`
`
`
`mmv“wwsumm
`
`
`
`
`
`wmvxEn.nm>>mcfomoE:u_umzmzmw“mmzcmm
`
`Page 7 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 7 of 14
`
`US 2012/0023190 A1
`
`
`
`Page 8 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 8 of 14
`
`US 2012/0023190 A1
`
`
`
`Application
`Server/content
`provider 510A
`
`Application
`Severlocontent
`provider 510B
`
`User Activity 502
`
`inactive period
`Default = 1200 (20 mins)
`
`Power saving starts 504 C
`
`
`
`New Data
`
`Period One
`Default = 900 (15 mins)
`
`-
`- - - - - - ->New Data
`- - - - - -Power Save Period
`'New Data
`
`New Data
`
`o
`Target time for earliest
`next data 506
`
`New Data
`
`C
`N1TN--------- X
`
`Nels'-la-'-y-e X
`Period One
`Default = 900 (15 mins) -----' r- " -tra- - -
`Tardet time for earliest
`C
`next data 508
`N1 N'-------
`
`targestigies
`
`Period One
`Default = 900 (15 mins)
`N
`Target time for
`O CanCe
`earliest next data
`NYT Power save
`---...-------------------------.
`: User Activity 512 ..........N. RPC as not in
`------------------------------------
`batch period
`New Data
`
`
`
`New Data
`
`5 O3
`
`Period One
`Default = 900 (15 mins)
`
`Target time for
`earliest next data
`
`4-1
`C
`N1 N- - - - - Power Save Period
`
`
`
`505
`
`Period TWO
`Default = 3600 (1 hour)
`N period ones followed
`by period twos
`{UserActivity...N. CanCEl POWe?. Says.
`“..............--...-----
`y. Cancel Power save.
`FIG. 5
`
`Page 9 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 9 of 14
`
`US 2012/0023190 A1
`
`9 (9 IAI
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Page 10 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 10 of 14
`
`US 2012/0023190 A1
`
`Radio turned
`on by another
`event 702
`
`Time period
`elapsed
`704
`
`User trigger
`7O6
`
`The first
`application
`exits 708
`
`Application
`mOVeS into the
`foreground
`710
`
`
`
`
`
`Transfer the data request over the wireless network
`712
`
`FIG. 7
`
`Page 11 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 11 of 14
`
`US 2012/0023190 A1
`
`
`
`Track data transfer
`requests made by the
`first application on the
`mobile device
`802
`
`Track data transfer
`requests made by the
`Second application on the
`mobile device
`804
`
`Determine a first timing
`characteristic of data
`transfer requests made by
`the first application
`806
`
`Determine a second timing
`characteristic of data
`transfer requests made by
`the second application
`808
`
`Delaying the transfer of the
`first data request using the
`first and second timing
`characteristics
`810
`
`Delaying the transfer of the
`second data request using
`the first and second timing
`characteristics
`810
`
`FIG. 8
`
`Page 12 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 12 of 14
`
`US 2012/0023190 A1
`
`
`
`Detect application behavior of multiple
`applications on a mobile device 902
`
`Align some of the content requests
`made by at least a portion of the
`multiple applications from the mobile
`device Over the network 904
`
`Transfer some of the content requests
`that are delayed in a single transfer
`operation over the network 906
`
`FIG. 9
`
`Page 13 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 13 of 14
`
`US 2012/0023190 A1
`
`
`
`
`
`Determine the
`Determine priority
`Determine
`useable
`of a specific
`.
`an amount of
`lifetire 5. data
`data involved
`applies.
`application relative "Y" transferred in
`to other
`request
`the content
`applications
`E.
`request
`
`- 1006
`
`
`
`
`
`
`
`1002
`
`Determine a
`nature of
`data involved
`"SYS
`request
`S
`
`m-
`
`Determine the
`Determine a
`network
`Status of the
`characteristics
`application
`maige E.
`request
`E.
`1010
`1012
`
`
`
`
`
`
`
`
`
`--
`
`--
`
`Factor in any user configurations or other overriding settings
`1014
`
`
`
`Determine the amount of time to delay some of the content
`requests to align i Content requests
`1016
`
`FIG. IO
`
`Page 14 of 34
`
`

`

`Patent Application Publication
`
`Jan. 26, 2012 Sheet 14 of 14
`
`US 2012/0023190 A1
`
`1100
`
`Processor
`
`Instructions
`
`
`
`Main Memory
`
`n
`
`a
`
`Instructions
`
`
`
`Non-volatile Memory
`
`
`
`Network interface Device
`
`Video Display
`
`Alpha-numeric Input Device
`
`Cursor Control Device
`
`Drive Unit
`Machine-readable
`(Storage) Medium
`
`- N
`
`Instructions
`
`Signal Generation Device
`
`FIG. II
`
`Page 15 of 34
`
`

`

`US 2012/0023190 A1
`
`Jan. 26, 2012
`
`MOBILE NETWORK TRAFFIC
`COORONATION ACROSS MULTIPLE
`APPLICATIONS
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`0001. This application claims the benefit of U.S. Provi
`sional Patent Application No. 61/367,871 entitled “CON
`SERVING POWER CONSUMPTION IN APPLICATIONS
`WITH NETWORKINITIATED DATA TRANSFERFUNC
`TIONALITY, which was filed on Jul. 26, 2010, U.S. Provi
`sional Patent Application No. 61/367,870 entitled “MANAG
`ING AND IMPROVING NETWORK RESOURCE
`UTILIZATION, PERFORMANCE AND OPTIMIZING
`TRAFFIC IN WIRE LINE AND WIRELESS NETWORKS
`WITH MOBILE CLIENTS, which was filed on Jul. 26,
`2010, U.S. Provisional Patent Application No. 61/408,858
`entitled "CROSS APPLICATION TRAFFIC COORDINA
`TION', which was filed on Nov. 1, 2010, U.S. Provisional
`Patent Application No. 61/408,839 entitled “ACTIVITY
`SESSION AS METHOD OF OPTIMIZING NETWORK
`RESOURCE USE, which was filed on Nov. 1, 2010, U.S.
`Provisional Patent Application No. 61/408,829 entitled “DIS
`TRIBUTED POLICY MANAGEMENT, which was filed
`on Nov. 1, 2010, U.S. Provisional Patent Application No.
`61/408,846 entitled “INTELLIGENT CACHE MANAGE
`MENT IN CONGESTED WIRELESS NETWORKS,
`which was filed on Nov. 1, 2010, U.S. Provisional Patent
`Application No. 61/408,854 entitled “INTELLIGENT
`MANAGEMENT OF NON-CACHABLE CONTENT IN
`WIRELESS NETWORKS, which was filed on Nov. 1, 2010,
`U.S. Provisional Patent Application No. 61/408,826 entitled
`“ONE WAY INTELLIGENT HEARTBEAT, which was
`filedon Nov. 1, 2010, U.S. Provisional Patent Application No.
`61/408,820 entitled “TRAFFIC CATEGORIZATION AND
`POLICY DRIVING RADIO STATE, which was filed on
`Nov. 1, 2010, U.S. Provisional Patent Application No.
`61/416,020 entitled “ALIGNING BURSTS FROM SERVER
`TO CLIENT', which was filed on Nov. 22, 2010, U.S. Pro
`visional Patent Application No. 61/416,033 entitled “POLL
`ING INTERVAL FUNCTIONS, which was filed on Nov. 22,
`2010, U.S. Provisional Patent Application No. 61/430,828
`entitled DOMAIN NAME SYSTEM WITH NETWORK
`TRAFFICHARMONIZATION, which was filed on Jan. 7,
`2011, the contents of which are all incorporated by reference
`herein.
`
`BACKGROUND
`0002. When WCDMA was specified, there was little
`attention to requirements posed by applications whose func
`tions are based on actions initiated by the network, in contrast
`to functions initiated by the user or by the device. Such
`applications include, for example, push email, instant mes
`saging, visual Voicemail and Voice and video telephony, and
`others. Such applications typically require an always-on IP
`connection and frequent transmit of Small bits of data.
`WCDMA networks are designed and optimized for high
`throughput of large amounts of data, not for applications that
`require frequent, but low-throughput and/or Small amounts of
`data. Each transaction puts the mobile device radio in a high
`power mode for considerable length of time—typically
`between 15-30 seconds. As the high power mode can con
`Sume as much as 100x the power as an idle mode, these
`
`network-initiated applications quickly drain battery in
`WCDMA networks. The issue has been exacerbated by the
`rapid increase of popularity of applications with network
`initiated functionalities, such as push email.
`0003 Lack of proper support has prompted a number of
`Vendors to provide documents to guide their operator partners
`and independent Software vendors to configure their net
`works and applications to perform better in WCDMA net
`works. This guidance focuses on: configuring networks to go
`to stay on high-power radio mode as short as possible and
`making periodic keep alive messages that are used to main
`tain an always-on TCP/IP connection as infrequent as pos
`sible. Such solutions typically assume lack of coordination
`between the user, the application and the network.
`0004 Furthermore, application protocols may provide
`long-lived connections that allow servers to push updated
`data to a mobile device without the need of the client to
`periodically re-establish the connection or to periodically
`query for changes. However, the mobile device needs to be
`Sure that the connection remains usable by periodically send
`ing 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 is not a lot and the
`keep-alive interval for an individual application is not too
`short, the cumulative effect of multiple applications perform
`ing this individually will amount to Small pieces of data being
`sent very frequently. Frequently sending bursts of data in a
`wireless network also result in high battery consumption due
`to the constant need of powering/re-powering the radio mod
`ule.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0005 FIG. 1A illustrates an example diagram of a system
`where a host server facilitates management of traffic between
`client devices and an application server or content provider in
`a wireless network for resource conservation.
`0006 FIG. 1B illustrates an example diagram of a proxy
`and cache system distributed between the host server and
`device which facilitates network traffic management between
`a device and an application server/content provider for
`resource conservation.
`0007 FIG. 2A depicts a block diagram illustrating an
`example of client-side components in a distributed proxy and
`cache system residing on a mobile device that manages traffic
`in a wireless network for resource conservation.
`0008 FIG.2B depicts a block diagram illustrating another
`example of components in the application behavior detector
`and the traffic shaping engine in the local proxy on the client
`side of the distributed proxy system shown in the example of
`FIG. 2A
`0009 FIG. 3 depicts a block diagram illustrating an
`example of server-side components in a distributed proxy and
`cache system that manages traffic in a wireless network for
`resource conservation.
`0010 FIG. 4A depicts a timing diagram showing how data
`requests from a mobile device to an application server/con
`tent provider in a wireless network can be coordinated by a
`distributed proxy system in a manner Such that network and
`battery resources are conserved through using content cach
`ing and monitoring performed by the distributed proxy sys
`tem.
`FIG. 4B depicts a timing diagram showing how data
`0011
`requests from a mobile device to an application server/con
`
`Page 16 of 34
`
`

`

`US 2012/0023190 A1
`
`Jan. 26, 2012
`
`tent provider in a wireless network can be aligned at the local
`proxy in the distributed proxy system to optimize network
`and radio use.
`0012 FIG.5 depicts a diagram showing one example pro
`cess for implementing a hybrid IP and SMS power saving
`mode on a mobile device using a distributed proxy and cache
`system (e.g., Such as the distributed system shown in the
`example of FIG. 1B).
`0013 FIG. 6 depicts a flow chart illustrating example
`selection processes through which data transfer requests of
`multiple applications can be coordinated into a single transfer
`operation.
`0014 FIG. 7 depicts an example of triggering events that
`would cause a data request to be transferred without align
`ment with another data request.
`0015 FIG. 8 depicts a flow chart illustrating an example
`process for using timing characteristics of data requests made
`by individual applications to delay transfer of one or more of
`the data requests made by one of the individual applications.
`0016 FIG. 9 depicts a flow chart illustrating an example
`process for using application behavior of multiple applica
`tions to align their content requests made over the network.
`0017 FIG. 10 depicts an example of processes through
`which the time of delay for content requests can be deter
`mined to align content requests over the wireless network.
`0018 FIG. 11 shows a diagrammatic representation of a
`machine in the example form of a computer system within
`which a set of instructions, for causing the machine to per
`formany one or more of the methodologies discussed herein,
`may be executed.
`
`DETAILED DESCRIPTION
`0019. The following description and drawings are illustra
`tive and are not to be construed as limiting. Numerous specific
`details are described to provide a thorough understanding of
`the disclosure. However, in certain instances, well-known or
`conventional details are not described in order to avoid
`obscuring the description. References to one or an embodi
`ment in the present disclosure can be, but not necessarily are,
`references to the same embodiment; and, such references
`mean at least one of the embodiments.
`0020 Reference in this specification to “one embodiment'
`or “an embodiment’ means that aparticular feature, structure,
`or characteristic described in connection with the embodi
`ment is included in at least one embodiment of the disclosure.
`The appearances of the phrase “in one embodiment in vari
`ous places in the specification are not necessarily all referring
`to the same embodiment, nor are separate or alternative
`embodiments mutually exclusive of other embodiments.
`Moreover, various features are described which may be
`exhibited by some embodiments and not by others. Similarly,
`various requirements are described which may be require
`ments for some embodiments but not other embodiments.
`0021. The terms used in this specification generally have
`their ordinary meanings in the art, within the context of the
`disclosure, and in the specific context where each term is
`used. Certainterms that are used to describe the disclosure are
`discussed below, or elsewhere in the specification, to provide
`additional guidance to the practitioner regarding the descrip
`tion of the disclosure. For convenience, certain terms may be
`highlighted, for example usingitalics and/or quotation marks.
`The use of highlighting has no influence on the scope and
`meaning of a term; the scope and meaning of a term is the
`
`same, in the same context, whether or not it is highlighted. It
`will be appreciated that same thing can be said in more than
`one way.
`0022 Consequently, alternative language and synonyms
`may be used for any one or more of the terms discussed
`herein, nor is any special significance to be placed upon
`whether or not a term is elaborated or discussed herein. Syn
`onyms for certain terms are provided. A recital of one or more
`synonyms does not exclude the use of other synonyms. The
`use of examples anywhere in this specification including
`examples of any terms discussed herein is illustrative only,
`and is not intended to further limit the scope and meaning of
`the disclosure or of any exemplified term. Likewise, the dis
`closure is not limited to various embodiments given in this
`specification.
`0023. Without intent to limit the scope of the disclosure,
`examples of instruments, apparatus, methods and their
`related results according to the embodiments of the present
`disclosure are given below. Note that titles or subtitles may be
`used in the examples for convenience of a reader, which in no
`way should limit the scope of the disclosure. Unless other
`wise defined, all technical and scientific terms used herein
`have the same meaning as commonly understood by one of
`ordinary skill in the art to which this disclosure pertains. In
`the case of conflict, the present document, including defini
`tions will control.
`0024. Embodiments of the present disclosure include sys
`tems and methods for mobile network traffic coordination
`across multiple applications.
`0025. One embodiment of the disclosed technology
`includes, a system that optimizes multiple aspects of the
`connection with wired and wireless networks and devices
`through a comprehensive view of device and application
`activity including: loading, current application needs on a
`device, 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 coop
`erative client/server or simultaneously mobile devices with
`out a cooperative client. Because the disclosed 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 a 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 those commonly
`referred to as 4G, namely LTE, 4G, and WiMAX are focused
`on providing increased bandwidth. Although partially
`addressed by the standards a key problem that remains is lack
`of bandwidth on the signaling channel more so than the data
`channel.
`0026. Embodiments of the disclosed technology includes,
`for example, alignment of requests from multiple applica
`tions to minimize the need for several polling requests; lever
`age 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/or network parameters.
`0027 Embodiments of the present technology can further
`include, moving recurring HTTP polls performed by various
`
`Page 17 of 34
`
`

`

`US 2012/0023190 A1
`
`Jan. 26, 2012
`
`widgets, RSS readers, etc., to remote network node (e.g.,
`Network operation center (NOC)), thus considerably lower
`ing device battery/power consumption, radio channel signal
`ing, and bandwidth usage. Additionally, the offloading can be
`performed transparently so that existing applications do not
`need to be changed.
`0028. In some embodiments, this can be implemented
`using a local proxy on the mobile 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). The local proxy can automatically cache
`the content on the mobile device while delegating the polling
`to the server (e.g., a proxy server operated as an element of a
`communications network). The server can 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 ver
`sion in its cache to the user (without need to utilize the radio
`at all). This way the mobile device (e.g., a mobile phone,
`Smartphone, etc.) does not need to open up (e.g., thus pow
`ering on the radio) or use a data connection if the request is for
`content that is monitored and that has been not flagged as
`new/changed.
`0029. The logic for automatically adding content sources/
`application servers (e.g., including URLS/content) to be
`monitored can also 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 request
`ing the data, etc. Similar rules to decide between using the
`cache and request the data from the original Source may also
`be implemented and executed by the local proxy and/or
`SeVe.
`0030. For example, when the request comes at an unsched
`uled/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 impor
`tant. In addition, the disclosed technology allows elimination
`of unnecessary chatter from the network, benefiting the
`operators trying to optimize the wireless spectrum usage.
`
`Cross Application Traffic Coordination
`0031. In one embodiment of the present disclosure, a
`group of applications A, B, C, ... I may have a timeline of
`transfers of data from the mobile device (or client (e.g.,
`mobile application, Software agent, widget) on the mobile
`device) to the network, or from the network to the mobile
`device (for receipt by the client). The time of the transfers can
`be represented as:
`0032. Application A: tA1, tA2, tA3, . . .
`0033. Application B: thB1, thB2, t33, ...
`0034) Application C: tC1, tC2, tC3, ...
`0035 Each of the times t can have a natural point of
`occurring based upon the independent activity of the corre
`sponding application as operations are executed at the appli
`cation server/provider and/or on the software client on the
`mobile device. For example, an application can transfer a
`message, an event, or other types of data to the network (or
`Vice versa) at a regular or semi-regular series of times as part
`of polling, satisfying a device, application, or user request,
`application maintenance, or other operation.
`
`0036 Similarly, an application can transfer a message,
`event, or other types data via the network (or vice versa) at a
`regular, semi-regular, or irregular series of times to perform
`its inherent functions or operations, such as Synchronizing
`two data stores, determining the contents of a data store,
`accessing new data from the application server/service pro
`vider, communicating with a peer device (e.g., another device
`with the same application or another application with which
`the requesting application interacts), exchanging control
`messages, etc.
`0037. In some instances, there is typically no correlation
`or weak correlation between the times at which data transfers
`or event transactions occur for one application as compared to
`a second application on a given mobile device, or for different
`data requests for the same application. In some cases, there
`may be a stronger correlation between the times at which a
`transfer occurs for one application as compared to a second
`application (e.g., where an operation of a first application is
`dependent upon or triggers an operation of a second applica
`tion, or where a user typically executes an operation of one
`application in conjunction with an operation of a second
`application). Note that in Some instances, the second appli
`cation may be the same application as the first application and
`that correlations can be tracked and determined for multiple
`requests sent by one application in a similar fashion.
`0038. In some embodiments, in order to optimize (e.g.,
`typically to minimize) the number of times that a device (e.g.,
`a mobile device or Smartphone) radio is turned on to decrease
`the consumption of power (and hence conserve its battery or
`other power source), a distributed proxy system including a
`local proxy and/or proxy server can operate to intercept the
`events or transactions (or requests for transfer) of informa
`tion. When intercepted, the local proxy and/or the proxy
`server can delay (or expedite) the time at which one or more
`of these transfers would normally occur in order to perform
`multiple transfers together as part of a single transfer opera
`tion (i.e., instead of performing multiple, individual trans
`fers). Alternatively, the local and/or proxy server can pre
`retrieve data for a non-priority application or less important/
`time sensitive application whose polls are typically expected
`to happen before another application having higher priority,
`for example. In other words, a delay could be negative result
`ing in content pre-retrieval for alignment with an anticipated
`data request which typically happens before the request of the
`lesser priority application.
`0039. The delay time (D) can represent a maximum time
`delay value (or in some instances, expedited time value) after
`receipt of a request to make such a transfer, with the value of
`D determined so as to enable the collection of as many of the
`transfers as feasible in a single, optimized data transfer. The
`delay times or expedited times of one or more transfers are
`determined so as to factor in any potential impact on perfor
`mance and user experience. Ideally, the system determines D
`to prevent undesired penalties or inefficiencies, and to prevent
`undesired impact on the user experience. Note that as
`described above, the delay D' could be negative or positive
`for alignment purposes (e.g., to implement a delayed or an
`expedited transfer).
`0040. In some embodiments, delay time 'D' (use to repre
`sent both positive and negative delays (effectively and expe
`dited transfer)) can be determined based on consideration of
`one or more of the following factors: the priority of the
`application (or the relative priority of one application in com
`parison to another), the nature or amount of data involved in
`
`Page 18 of 34
`
`

`

`US 2012/0023190 A1
`
`Jan. 26, 2012
`
`the transfer (e.g., whether it represents fresh data, a house
`keeping function, a control instruction, etc.), the status of the
`application (e.g., active, inactive, background, foreground,
`etc.), a useable lifetime of the data to be transferred (a period
`before it becomes stale), the interval between the transfer
`times of multiple data requests for a single application, the
`interval between the transfer times across more than one
`application (e.g., the largest transfer time interval based on
`consideration of all active applications), network character
`istics (available bandwidth, network latency, etc.), or another
`relevant factor.
`0041. In some embodiments, the delay time 'D' of specific
`events/transactions can be controlled by the mobile device
`(e.g., platform, device settings, or OS specifications), net
`work service provider, and/or the user as part of optimizing
`the battery life to align data transfer requests across multiple
`applications or the same application, as opposed to perform
`ing each data transfer individually. In some instances, the user
`can manually configure a setting specifying that requests
`across multiple applications or the same application are to be
`batched. The user can enable the setting, and allow the system
`to configure the details. In addition, the user can specify
`preferences, priorities, or any other constraints related to
`alignment of data request transfer of the mobile network.
`0042 FIG. 1A illustrates an example diagram of a system
`where a host server 100 facilitates management of traffic
`between client devices 102 and an application server or con
`tent provider 110 in a wireless network for resource conser
`Vation.
`0043. The client devices 102A-D can be any system and/or
`devi