KR101227821B1 - System and method for making requests on behalf of a mobile device based on atomic processes for mobile network traffic relief - Google Patents

Abstract

PURPOSE: A system and method for requesting help in place of a mobile device based on an atom process is provided to simulate a traffic request in a mobile device which can be implemented in a system. CONSTITUTION: A proxy server(125) predicts a request of a mobile device before transmitting a request to a destination through the mobile device. The proxy server predicts the request by detecting a traffic pattern for an outgoing request from the mobile apparatus. The proxy server simulates the request in place of the mobile device. The proxy server transmits the request to the destination in which is selected as an address by the request. [Reference numerals] (100) Host server; (106,108) Network; (110) Application server/content provider; (112) Short message service center; (120A) Advertisement server; (120B) Promotion content server; (120C) e-coupon server; (125) Proxy server; (135) Server cache; (150) Mobile device; (175) Local proxy; (185) Local cache; (199) Selective caching proxy server

Description

TECHNICAL AND METHOD FOR MAKING REQUESTS ON BEHALF OF A MOBILE DEVICE BASED ON ATOMIC PROCESSES FOR MOBILE NETWORK TRAFFIC RELIEF}

Cross-Reference to Related Applications

This application claims priority based on US Provisional Patent Application No. 61 / 479,676, "ATOMIC PROCESS FOR OFFLOADING MOBILE APPLICATION ACTIVITY BY TRAFFIC SNOOPING," filed April 27, 2011. It is included by reference.

This application is filed with US Patent Application "MOBILE DEVICE WHICH OFFLOADS REQUESTS MADE BY A MOBILE APPLICATION TO A REMOTE ENTITY FOR CONSERVATION OF MOBILE DEVICE AND NETWORK RESOURCES AND METHODS THEREFOR" (Attorney Docket No. 76443-8120.US01) And all of the above US patent applications are incorporated herein by reference.

Mobile data traffic continues to grow exponentially. Currently, data makes up a significant portion of mobile traffic in the United States, with roughly 30% of smartphone users using more than 1GB / mo on average. As new devices and new network technologies continue to roll out, data traffic continues to grow. The transition to 3G, LTE, and 4G, as well as the further introduction of tablets and smartphones, has led to the explosion of data and signaling traffic generated by billions of connected devices and applications requiring frequent refreshes.

Even in the case of migration to LTE and 4G-based networks, the rapid growth of subscribers, applications, and devices has placed a strain on network elements, resulting in congestion and network errors, all of which have a significant impact on end-user experience. Crazy Thus, the need to manage the growth of data, signaling, or data session traffic more intelligently and efficiently is still important to mitigate network congestion and ensure user experience in real time.

1A is an exemplary diagram illustrating a set of events detected in traffic initiated at an apparatus that may be grouped as an atomic process to be shared with a host server.
FIG. 1B illustrates that a host server may be a mobile device (eg, a wireless device) and an application server or content provider, or other server (eg, an advertisement server, a promotional content server, or the like) for resource conservation in a wireless network (or broadband network). Exemplary diagram of a system that facilitates management of traffic between e-coupon servers), content caching, and / or resource conservation. The host server may further share application traffic requests from the mobile device by snooping traffic on the mobile device to detect a set of events that may be used to generate the atomic process.
1C illustrates a host server that facilitates network traffic management between a device, application server or content provider, or other server (eg, an advertising server), a promotional content server, or an e-coupon server for resource conservation and content caching. An exemplary diagram of a proxy and cache system distributed between and devices. A proxy system distributed between the host server and the device may further distribute application traffic requests from the mobile device by detecting a set of events that may be used to snoop the traffic on the mobile device to generate an atomic process.
2A illustrates one of the client-side components of a distributed proxy and cache system on a mobile device (eg, a wireless device) that manages traffic for resource retention, content caching, and / or traffic management in a wireless network (or broadband network). It is a block diagram showing an example. The client-side proxy (or local proxy) may further implement mobile policy categorization and / or delivery policy based on application behavior, content priority, user activity, and / or user expectations.
FIG. 2B is a block diagram illustrating additional examples of components of the cache system shown in the example of FIG. 2A, which may cache for mobile application behavior and / or network conditions and adapt a caching strategy. Also shown are components that can detect long pole requests and manage caching of long poles.
FIG. 2C is a further configuration of an application behavior detector and caching policy manager of the cache system shown in the example of FIG. 2A, detecting cache dips and performing caching of content addressed by an identifier intended to dip the cache. A block diagram illustrating the elements.
FIG. 2D is a block diagram illustrating an example of additional components in the local cache shown in the example of FIG. 2A that may perform mobile traffic categorization and policy enforcement based on application behavior and / or user activity.
3A is a block diagram illustrating one example of server-side components of a distributed proxy and cache system that manages traffic for resource conservation, content caching, and / or traffic management in a wireless network (or broadband network). Server-side proxies (or proxy servers) may further implement mobile traffic categorization and / or delivery policies based on application behavior, content priorities, user activity, and / or user expectations.
FIG. 3B is a block diagram illustrating additional examples of components of a caching policy manager in the cache system shown in the example of FIG. 3A that may cache and adapt caching strategies to mobile application behavior and / or network conditions. Also shown are components that can detect long pole requests and manage caching of long poles.
FIG. 3C is a block diagram illustrating another example of components in the proxy system shown in the example of FIG. 3A that may manage and detect a cache bite mechanism, and monitor a content source.
FIG. 3D is a block diagram illustrating an example of additional components of the proxy server shown in the example of FIG. 3A that may perform mobile traffic categorization and policy enforcement based on application behavior and / or traffic priority.
4A is a block diagram illustrating another example of client-side components of a distributed proxy and cache system, including atomic process based traffic optimizers.
4B is a block diagram illustrating additional components of the atomic process based traffic optimizer shown in the example of FIG. 4A.
5A is a block diagram illustrating one example of server-side components of a distributed proxy and cache system further comprising an atomic process based traffic optimizer.
FIG. 5B is a block diagram illustrating additional components of the atomic process based traffic optimizer shown in the example of FIG. 5A.
6A is a flowchart illustrating an example process for distributed content caching between a mobile device (eg, any wireless device) and a remote proxy and distributed management of content caching.
FIG. 6B illustrates a distributed proxy request for data requests from a mobile device to an application server / content provider in a wireless network (or broadband network) so that network and battery resources are preserved through the use of content caching and monitoring performed by a distributed proxy system. A timing diagram showing how the system can be harmonized.
7 is a table illustrating examples of different traffic or application category types that may be used when implementing network access and content delivery policies.
8 is a table illustrating examples of different content category types that may be used when implementing network access and content delivery policies.
9 illustrates that a poll with data requests from a mobile device (eg, any wireless device) to an application server / content provider over a wireless network (or broadband network) may be cached at a local proxy and managed by a distributed caching system. It is an interactive diagram showing how it can be done.
10 illustrates that polls for content from an application server / content provider that utilize a cache defeat mechanism (eg, an identifier intended to deflect caching) within an identifier over a wireless network (or broadband network) may be detected and cached locally. It is an interactive diagram showing how it can be done.
11 is a flowchart illustrating an example process for making a request on behalf of a mobile device.
12 is a flowchart illustrating an example process for identifying or detecting a reproducible pattern of requests from a mobile device.
13 is a flowchart illustrating an example process for simulating a traffic request from a mobile device.
14 is a flowchart illustrating an example process for sharing a request made by a plurality of mobile applications on a mobile device.
FIG. 15 is a flow diagram illustrating an example process for sharing a request made with a remote entity at a mobile device.
16 is a schematic representation of a machine in an exemplary form of a computer system in which a set of instructions for causing a machine to perform one or more of the methods described herein may be executed.

The following description and drawings are for the purpose of description and not of limitation. Many specific details are set forth in order to provide a thorough understanding of the present disclosure. However, in certain instances, known or conventional details are not provided to avoid obscuring the disclosure herein. As used herein, “an embodiment” or “an embodiment” may not necessarily refer to the same embodiment, and such reference refers to at least one of the embodiments.

In this specification, reference to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the above embodiment is included in at least one embodiment of the present invention. The use of the phrase “in one embodiment” in various places in this specification does not necessarily refer to the same embodiment, nor does it imply that the individual or alternative embodiments are mutually exclusive of other embodiments. . In addition, various features are described which appear in some embodiments and do not appear in the other embodiments. Likewise, various requirements are described which may be requirements of certain embodiments, but not requirements of other embodiments.

The terminology used herein is the ordinary meaning in the art in light of the context of the present invention and the specific context in which each term is used. In order to provide additional guidance to those skilled in the art in connection with the description of the invention, certain terms used to describe the invention are described below, or elsewhere in this specification. For example, italics and / or quotation marks may be used to emphasize. The use of accented words has no effect on the scope and meaning of the terms, and regardless of whether the terms are emphasized, the scope and meaning of the terms are the same under the same context. It will be appreciated that the same may be explained in more than one way.

As a result, substitutions and synonyms may be used for any one or more of the terms described herein, and have no particular significance regardless of whether described or described herein. Synonyms for specific terms are provided. Reference to one or more synonyms does not exclude the use of other synonyms. Use of examples in any part of this specification, for example, examples of any term described herein are for illustrative purposes only, and the scope and meaning of the present invention or the scope and meaning of any exemplary term There is no intention to further restrict. Likewise, the invention is not limited to the various embodiments provided herein.

Without intending to limit the scope of the present invention, examples of devices, devices, methods, and results associated therewith, according to embodiments of the present invention are provided below. The title or subtitle may be used as an example for convenience and does not limit the scope of the present invention. Unless defined otherwise, all technical and scientific terms used herein have the meaning commonly understood by one of ordinary skill in the art to which this invention belongs. In case of conflict, the present application, including definitions, will control.

Embodiments of the present invention include systems and methods for making requests on behalf of mobile devices based on atomic processes for mitigating mobile network traffic.

There are a number of factors that contribute to the proliferation of data, such as end users, mobile devices, wireless devices, mobile applications, and networks. As mobile devices evolve, various factors associated with the mobile devices, such as availability, applications, user behavior, and location, change the way the network interacts with the devices and applications.

The technique of the present invention utilizes the fact that mobile content has a specified or relative "freshness" value to enable operators and device manufacturers to support both mobile and wireless device movement and data spikes. Provides a comprehensive end-to-end solution to address the elements. The "freshness" of mobile content is either deterministically or with tolerances (within this tolerance the user experience is improved but not negatively impacted, or negatively impacted but unacceptable or within acceptable thresholds). Using any heuristic, it can be determined.

The innovation of the present invention monitors and analyzes transactions (requests / responses) between an application (e.g., a mobile application) and a peer (a corresponding server or other client) and applies these rules, thereby applying such "freshness". (freshness) "to be transparent. In addition, the technique can efficiently cache content that may be marked as "non-cacheable" by the source / host server of the content, and identify some "freshness" values. The "freshness" value can then be used to implement application-specific caching. In general, the "freshness" value generally has an approximate minimum determined using an update interval between the application and the corresponding server / host (eg, the interval at which the request is sent).

One embodiment of the techniques of the present invention may include device and application activity (eg, loading, current application demand on the device, control of the type of access (push vs. pull, or hybrid), Location, density of users in a single area, time of day, frequency with which users interact with applications, content, or devices, and traffic to collaborating clients / servers, or mobile devices without collaborating clients Using this information to shape concurrent traffic) includes a system that optimizes multiple aspects of the connection of devices with wired and wireless networks. Because the server of the present invention is not associated with any particular network provider, it has visibility into network performance among all service providers. This allows optimization to be applied to the device, regardless of operator or service provider, thus improving the user experience and managing network utilization during roaming. Today, bandwidth is considered a major issue in wireless networks. In relation to the need for additional bandwidth to solve access problems, more and more research is being done. Many of the performance enhancement solutions and next-generation standards (such as those commonly referred to as 3.5G, LTE, 4G, and WiMAX) focus on providing increased bandwidth. Although partially solved by the standard, the key problem that remains is that there is less bandwidth in the signaling channel than in the data channel, and the standard does not solve the battery life problem very well.

Embodiments of the techniques of the present invention include, for example, aligning requests from a plurality of applications to minimize the need for a plurality of polling requests; Determining how to proxy / manage connections / content using specific content types; Applying specific heuristics associated with devices, user behavior patterns (frequency of user interactions with devices / applications), and / or network parameters.

Embodiments of the technology of the present invention move repeated HTTP polls performed by various widgets, RSS readers, and the like to remote network nodes (e.g., Network Operation Centers (NOCs)). And thus significantly lowering device battery / power consumption, radio channel signaling and bandwidth usage. In addition, offloading can be transparently performed so that existing applications do not need to be changed.

In some embodiments, this is a mobile device (eg, any wireless device) that automatically detects repeated requests for the same content (RSS feeds, widget data sets) that meet specific rules (eg, occur every 15 minutes). Can be implemented using a local proxy. The local proxy can automatically cache content to the mobile device while delegating polling to a server (eg, a proxy server operating as one element of the communication network). The server may then notify the mobile / client proxy if the content has changed, and if the content has not changed (or if the content has not changed sufficiently, i.e. identified), the mobile proxy needs to use the radio at all. To provide users with the latest version in their cache. In this way, if the request is monitored and is for content that has never been flagged as being new / changed, the mobile or wireless device (eg, mobile phone, smartphone, M2M module / MODEM, Or any other wireless device, etc.) need not establish or use a data connection.

The logic for automatically adding content source / application servers to be monitored (e.g., including URLs / content) is based on various factors, such as how often content is the same, how often the same request is made (fixed interval / pattern , Which applications are requesting data, and so on. Similar rules may be implemented and executed by the local proxy and / or server to determine between using the cache and requesting data from the original source.

For example, when a request is unplanned / unexpected (check initiated by the user), or after a response has been provided n consecutive times from a cache or the like, or if the application is running in the background, foreground Is running in more interactive mode. As more and more mobile applications or wireless enabled applications are based on the resources available on the network, this becomes more and more important. In addition, the technique of the present invention eliminates unnecessary chatter from the network, which is beneficial for operators attempting to optimize radio spectrum usage.

traffic Categorization  And policy

In some embodiments, the proxy system of the present invention may establish a policy for selecting traffic (data, content, messages, updates, etc.) for caching and / or shaping. In addition, by combining information derived from the observation of an application making a network request, or the collection of explicit information from an application, or the perception of the network destination that the application arrives at, the techniques of the present invention are transmitted. The category to which the traffic belongs can be determined or inferred.

For example, in one embodiment, mobile or wireless traffic may be categorized as (a1) interactive traffic, or (a2) background traffic. The difference is that at (a1) the user actively waits for a response, but at (a2) the user does not expect a response. This categorization can be used with, or in place of, the second type of categorization, the second type of categories being: (b1) immediate, (b2) low priority, (b3) request Immediately if the application it is in the foreground and is active.

For example, a new update, message, or e-mail may belong to the category (b1) to be delivered immediately, but still (a2) is background traffic (user does not actively wait for it). When exiting an active chat session, a similar categorization is applied to instant messages. During an active chat session, the user expects a faster response. These user expectations are determined or inferred and considered as factors when optimizing network usage and device resources in performing traffic categorization and policy enforcement.

In some examples of the application of the categorization scheme described, (a1) interactive traffic is categorized as (b1) immediate, but (a2) background traffic may be (b2) or (b3). Examples of low priority transfers are e-mail or message maintenance transactions, such as deleting an e-mail or other message, or marking the e-mail when read from the mail or application server. In general, this transfer may occur earlier in (a) when the timer exceeds a timeout value (eg, 2 minutes), and (b) when the data is sent for other purposes.

Examples of (b3) include IM presence updates, stock ticker updates, weather updates, status updates, and news feeds. When the UI of the application is in the foreground and / or active (eg, as indicated by the backlight of the device / phone, or determined or inferred from the state of some other sensor), the update It may be assumed that whenever a has anything to be pushed to the device it will happen immediately. When the application is not in the foreground or not active, this update can be suppressed until the application comes to the foreground and becomes active.

In some embodiments, the network may be simultaneously selected or optimized for (a1) interactive traffic and (a2) background traffic.

In some embodiments, wireless devices or mobile device proxies can categorize traffic (separately or together with a server proxy) to each other because they can be categorized as (eg) (a1) interactive traffic, or (a2) background traffic. Different policies can be applied to different types of traffic. This means that it can internally behave differently for (a1) and (a2) traffic (which, for example, allows interactive traffic to pass through the network in whole or in part and stricter traffic for background traffic). By applying control, or by allowing the device side to request to activate the radio only when it receives information from the server that the host's content has been updated).

When a request requires access via a wireless network, the techniques of the present invention can request the radio layer to apply different network settings to different traffic. Depending on the type of traffic and network, this can be accomplished by several different means:

(1) using 3G / 4G for (a1), 2G / 2.5G for (a2),

(2) Explicitly specify network settings for different data sets (e.g., in terms of the use of forward access channel (FACH) vs. dedicated channel (DCH), or lower / higher network efficiency for background traffic) Request the data rate of the data in any other way), or

(3) Using different network access points for different data sets (access points to be set up to use different network resources similarly to (1) and (2) above).

In addition, 3GPP Fast Dormancy requires an improvement that allows applications, operating systems, or mobile devices to know the type of traffic that will be more efficient in the future. Embodiments of the system of the present invention with knowledge of traffic categories and able to use fast dormancy can solve the problems identified in the fast dormancy. In this way, the mobile or broadband network need not be configured with a compromised configuration that negatively impacts both battery consumption and network signaling resources.

Polling  schedule

By detecting (or determining) the polling schedule, the proxy server (server side of the distributed cache system) can keep its poll as close as possible to the application poll. Many applications use scheduled interval polling (eg, every 4 hours, or every 30 seconds, or at another time interval). The client-side proxy can detect automatic polls based on time criteria and create an automatic polling profile for the application. For example, a local proxy attempts to detect a time interval between a request and two, three, four, or more polls, all of which are one second each (or another criterion for relative closeness). If within, determine the automatic rate. Otherwise, the client can collect data from a larger number of polling events (eg, 10-12 polls) and apply statistical analysis to determine, calculate, or estimate the value for the average interval used. . The polling profile is forwarded to the server where the polling profile is used. If there are frequent manual requests, the local proxy can replace this with the default interval for this application, which is obtained from the profile for non-critical applications.

In some embodiments, local proxies (eg, device side proxies) may continue to monitor application / client polls and update polling intervals. If it changes by more than 30% (or another specified value / dynamic value / conditional value) from the current value, it is passed to the proxy server (eg server-side proxy). This approach may be referred to as a "lost interest" scenario. In some examples, the local proxy may be aware of requests made outside of this schedule and may consider these requests to be "manual" and handle them accordingly.

Of application classes / caching mode

In some embodiments, the application may be configured in three caching groups or modes. Each mobile client / application can be categorized to be treated as one of these modes, or to be handled using multiple modes, depending on one or more conditions.

A) fully cached-the local proxy updates only when the proxy server tells the local proxy to update (eg, sends an application request directly over the network to be served by the application server / content host). In this mode, the local proxy can ignore manual requests, and the proxy server uses the detected automatic profile to poll the application server / content provider (eg, sports score applet, Facebook, 10, 15, 30, or more poles).

B) Partially cached-Local proxies use local or internal caches for automatic requests (e.g., application auto-replay), while other scheduled requests may require some manual requests (e.g. email, download, Via Ebay or some Facebook requests).

C) not cached (e.g., real-time stock ticker, sport score / status; but in some cases, a 15 minute delayed citation can be safely placed on a 30 second schedule-B or even A)

Based on the rate of change of content and the critical characters of the data, the actual application or caching mode classification can be determined. Applications not classified by default can be set to class C.

Backlight and Active Applications

In some embodiments, the local proxy starts by detecting a device backlight state. If a request with the same signature is registered with a proxy server that is polling the original host server / content server to which the request is directed, the request made by the screen light's 'off' uses the local cache. May be allowed to do so. When the screen light is on, further detection may be made to determine whether it is a background application or other indicator of whether or not an entry in the local cache can be used to satisfy the request. have. When identified, a request for which local entry can be used may be handled the same as the screen light off situation. A foreground request may use the aforementioned application classification when cached data is safe to be used to process the request.

1A is one set detected in traffic originating from device 150 grouped into atomic process 190 to be shared with a host server (eg, host server 100 of FIGS. 1B-1C). An example diagram illustrating the events 101, 103, and 105 of.

The mobile device 150 or its local proxy (eg, proxy 175 of FIG. 1C) intercepts mobile application traffic originating from the device, such as mobile device 150, and processes an atomic process (eg, an atomic process). (190) may identify various parameters that may be used to generate or generate. The atomic process 190 offloads the request from the mobile device 150 to a host server (eg, only the host server 100 or 200 in the example of FIGS. 1 and 2), thus distributing mobile network traffic. It can be used to alleviate and free up network resources.

In general, the atomic process 190 is capable of handling requests sent from the mobile application 108 or a plurality of applications (not shown) with a certain level of predictability with respect to each other based on the detected pattern. It may include an indicator corresponding to one set, or one set of requests, and may be replicated / simulated. The atomic process, after a request to the entity 101, is predicted at a predicted time interval, or when it is detected that another request to another entity is followed, or to a request to the entity 103, each at a predictable interval. When two further requests are followed, it may be generated. Traffic patterns may be detected by the mobile device 150 and / or a proxy server (eg, the proxy 125 of the server 100 of FIGS. 1B-1C) and a final atomic process may be generated by the proxy server 125. This is further explained with reference to the example of FIGS. 4-5.

For example, the predictable time interval may be detected by the mobile device 150 or a remote entity, such as a proxy server 125 of the server 100 of FIGS. 1B and 1C. For example, in one case, the system detects that a request to entity 101 occurs frequently or always at 6:00 am PST, so the atomic process requests to entity 101 at 6:00 am PST. This request may then be distributed to the dash that originates from the mobile device 150, such as the server (eg, server 100), to fulfill the request that occurs at 6:00 am daily. Can be.

In another example, a system (eg, a distributed proxy system between the device 150 and the server 100 shown in FIGS. 1B and 1C), after about 10 minutes each time a request to the entity 103 occurs, It may be detected that a request to the entity 105 has occurred. Thus, the distributed system can create an atomic process that includes a request to the entity 103 and a request to the entity 105 10 minutes later, and allocates a server to handle this process. Using the generated atomic process, whenever a request to the entity 103 occurs, the system can infer that, based on the defined atomic process, the request to the entity 105 is likely to occur after about 10 minutes. . The server 100 or proxy server 120 can use this knowledge to replicate mobile application activity and perform requests on behalf of the mobile device by making requests that generally need to be initiated from the mobile device. This sharing is thus beneficial in conserving mobile device resources (eg, power and battery), device bandwidth, and network resources (eg, cellular network resources).

For example, mobile device 250 detects from the identifiable pattern in a set of requests that a set of requests are generated from the mobile application, and retrieves the set or identifiable pattern of requests from a remote entity (eg, a proxy server ( 125) or server 100) to share the next occurrence of the set of requests to the remote entity. The remote entity can then simulate the next occurrence of the set of requests on behalf of the mobile application on the mobile device. The mobile application can be any mobile client or widget (such as, but not limited to, mobile web browsers, mobile games, mobile apps, social networking applications, feed applications, RSS readers, or status updates, friends). Feeds, news feeds, and any other application capable of sending / receiving media content (eg, photos, audio, video, etc.).

FIG. 1B illustrates that the host server 100 may be configured to include a mobile device (eg, wireless device 150) and an application server or content provider 110, or other server for resource conservation in a wireless network (or broadband network). For example, between an advertising server 120A, a promotional content server 120B, or an e-coupon server 120C, shows an example diagram of a system that facilitates management of traffic, content caching, and / or resource conservation. . The host server may snoop traffic at the mobile device to detect the set of events, which set may be used to generate an atomic process for sharing application traffic requests from the mobile device.

Client device 150 may establish a connection (eg, a wired, wireless, cellular connection) with another device, server, and / or another system (eg, host server 100 and / or application server / content provider 110). It can be any system and / or device that can be established, and / or any combination of devices / systems. In general, client device 150 may include a display and / or other device for providing information and data exchanged between device 150 and / or host server 100 and / or application server / content provider 110. It will include other output functions. The application server / content provider 110 may be any server including a third party server or a service / content provider (eg, an advertisement, promotional content, publication, or an electronic coupon server or service). Similarly, individual advertisement servers 120A, promotional content server 120B, and / or e-coupon server 120C are shown as application servers, or content providers, by way of example.

For example, client device 150 may include a mobile, handheld, or portable device, a wireless device, or a non-portable device, and may include server desktops, desktop computers, computer clusters, or portable devices (laptops, laptop computers). , Handheld computer, palmtop computer, mobile phone, cell phone, smartphone, PDA, Blackberry device, palm device, handheld tablet (e.g. iPad or any other tablet), handheld console, hand May be any of a handheld game device or console, any superphone (eg, iPhone), and / or any other portable, mobile, handheld device, or fixed line wireless interface (eg, M2M device), or the like. In one embodiment, client device 150, host server 100, and application server 110 connect via network 106 and / or network 108. In some embodiments, device 150 and host server 100 may be directly connected to each other.

Input mechanisms on the client device 150 may include touch screen keypads (eg, single touch, multi-touch, 2D or 3D gesture detection, etc.), physical keypads, mice, pointers, track pads, motion detectors (eg, 1). 3-axis, 2-axis, 3-axis accelerometers), optical sensors, capacitance sensors, resistance sensors, temperature sensors, proximity sensors, piezoelectric devices, device orientation detectors (e.g., electronic compass) , Tilt sensor, rotation sensor, gyroscope, accelerometer), or a combination thereof.

Through one or more of the aforementioned input means or other means, a received or detected signal indicative of user activity at the client device 150 is situationally aware at the client device 150 in the art of the present invention. may be used when obtaining context awareness. In general, situational awareness at client device 150 may be, for example, client device 150 operation or status acknowledgment, management, user activity / action / interaction awareness, detection, detection, tracking, trending, and / or Include (but are not limited to) the type of application (eg, mobile application), behavior, activity, behavioral state, and the like.

Context awareness in the present invention includes the knowledge and detection of network side context data and includes network information, such as network capacity, bandwidth, traffic, network / connection type, and / or any other operational state. May contain data. Network-side contextual data is received and / or queried from a network service provider (eg, by the host server and / or device 150) (eg, cell provider 112, and / or internet service provider). I can receive it. In addition to application context awareness as determined at the client 150 side, application context awareness may also be received from the respective application / server provider 110 (by the host 100 and / or client device 150), Can get / question

In order to manage the traffic of the system to satisfy the data demands of the client device 150 (eg, to satisfy an application, or any other request (such as an HTTP request)), the host server 100 may, for example, For example, contextual information obtained for client device 150, network 106/108, application (eg, mobile application), application server / provider 110, or any combination thereof may be used. In one embodiment, traffic is managed by the host server 100 to satisfy a data request made in response to an explicit or non-explicit user 103 request and / or a device / application maintenance task. Traffic may be managed such that network consumption, e.g., usage of the cellular network, is preserved for efficient and effective bandwidth utilization. In addition, the host server 100 may be optimized to optimize the use of device 150 side resources (eg, battery power consumption, radio usage, processor / memory usage) according to the general philosophy of resource conservation while still optimizing performance and user experience. System can manage and coordinate this traffic.

For example, in the context of battery conservation, device 150 may observe user activity or device activity (eg, by observing user keystrokes, backlight conditions, or by observing another signal through one or more input means, etc.). (150) You can change your behavior. Device 150 may also request host server 100 to change its behavior on network resource consumption based on user activity or behavior.

In one embodiment, traffic management for resource conservation is performed using a distributed system between the host server 100 and the client device 150. The distributed system may include proxy server and cache components on the server side 100 and the device / client side, for example, the server cache 135 on the server 100 side and the local on the client 150 side. There is a cache 185.

The functions and techniques disclosed for context aware traffic management for resource conservation in the network (eg, network 106 and / or 108) and device 150 are within distributed proxies and cache systems. The proxy and cache system may be distributedly located on a particular client device 150 and / or host server 100. The distributed proxy and cache system is shown with further reference to the example diagram shown in FIG. 1B. The functions and techniques performed by the proxy and cache components in the client device 150, the host server 100, and related components therein are described in detail with further reference to the example of FIGS. 2-3.

In one embodiment, client device 150 communicates with host server 100 and / or application server 110 via network 106, which network 106 may be a cellular network and / or a broadband network. have. In order to facilitate overall traffic management between the device 150 and the various application server / content providers 110 to implement a network (bandwidth utilization) and device resources (eg, battery consumption), the host server 100 is configured to execute network 108. May communicate with the application server / provider 110, and the network 108 may include the Internet (eg, a broadband network).

In general, networks 106 and / or 108 with which client device 150, host server 100, and / or application server 100 communicate may be a cellular network, a broadband network, a telephone network, an open network. (Eg, the Internet), or a private network (eg, an intranet and / or extranet), or any combination thereof. For example, the Internet may transfer files via any known or convenient protocol (eg, TCP / IP protocol, UDP, HTTP, DNS, FTP, UPnP, NSF, ISDN, PDH, RS-232, SDH, SONET, etc.). , Remote login, e-mail, news, RSS, cloud-based services, instant messaging, visual voicemail, pushmail, VoIP, and other services.

The networks 106 and / or 108 may be any collection of separate networks that operate in whole or in part to provide connectivity to the client device 150 and the host server 100, and the system being serviced. And to the device as one or more networks. In one embodiment, communication with client device 150 may be by a public network, such as the Internet, or a private network, a broadband network, such as an intranet and / or an extranet. In one embodiment, the communication may be via a secure communication protocol, such as a secure sockets layer (SSL), or transport layer security (TLS).

In addition, the communication may include one or more networks, such as WiMax, local area network (LAN), wireless local area network (WLAN), personal area network (PAN), campus area network (CAN), metropolitan area network (MAN), Through a wide area network (WAN), a wireless wide area network (WWAN), or any broadband network, but not limited to, for example, Global System for Mobile Communication (GSM), Personal Communications Service (PCS) ), Bluetooth, WiFi, Fixed Wireless Data, 2G, 2.5G, 3G, 4G, IMT-Advanced, pre-4G, LTE Advanced, Mobile WiMax, WiMax 2, WirelessMAN-Advanced Network, Enhanced data rates for GSM evolution (EDGE), general packet radio service (GPRS), enhanced GPRS, iBurst, UMTS, HSPDA, HSUPA, HSPA, UMTS-TDD, 1xRTT, EV-DO, messaging protocols (e.g. TCP / IP, SMS, MMS, extensible messaging and presence protocol (XMPP), real time messaging protocol (RTMP), instant messaging and presenc e protocol), instant messaging, USSD, IRC), or any other wireless data network, broadband network, or messaging protocol.

1C illustrates an apparatus 150 and an application server or content provider 110 or other server (e.g., ad server 120A, promotional content server 120B, or e-coupon) for resource conservation and content caching. An example diagram of a proxy and cache system distributed between host server 100 and device 150, facilitating network traffic management between servers 120C). A proxy system distributed between host server 100 and device 150 may further snoop traffic on mobile device 150 to detect a set of events, the set of events creating an atomic process, Application traffic requests from mobile device 150 may be shared.

The distributed proxy and cache system may include, for example, proxy server 125 (eg, remote proxy) and server cache 135 as server-side components. As shown, the server side proxy 125 and cache 135 may be located inside the host server 100. In addition, the server-side proxy server 125 and cache 135 may be located, partially or wholly outside of the host server 100, and communicate over one or more of the networks 106 and 108. For example, proxy server 125 may be external to host server, and server cache 135 may be maintained at host server 100. Alternatively, proxy server 125 may be within host server 100 while the server cache is external to host server 100. In addition, each of proxy server 125 and cache 135 may be partly within host server 100 and partly outside host server 100. The application server / content provider 110 may comprise any server, including a third party server or a service / content provider (eg, an advertisement, promotional content, publication, or an electronic coupon server or service). Likewise, as an application server or content provider, individual ad server 120A, promotional content server 120B, and / or e-coupon server 120C are shown.

The distributed system, in one embodiment, may also include client-side components, including but not limited to, for example, local proxy 175 (eg, mobile client on a mobile device), and / or device 150 ( For example, there is a local cache 185 residing inside a mobile device).

In addition, client-side proxy 175 and local cache 185 may be partially or entirely external to device 150 and communicate over one or more of networks 106 and 108. For example, local proxy 175 may be external to device 150, and local cache 185 may be maintained at device 150. Alternatively, local proxy 175 may be within device 150 and local cache 185 may be external to device 150. In addition, each of the proxy 175 and the cache 185 may be partially inside the host server 100 and partially outside the host server 100.

In one embodiment, the distributed system may include an optional caching proxy server 199. The caching proxy server 199 is operated by application server / content provider 110, or network service provider 112, or any combination thereof to facilitate network traffic management to conserve network and device resources. It may be a component. For example, proxy server 199 may be used to provide caching content to device 150 from one or more of application server / provider 110, host server 100, and / or network service provider 112. Content caching may be performed in whole or in part by the remote proxy 125 to satisfy application requests or other data requests at the device 150.

The nature of user activity / behavior in the mobile device (eg, any wireless device) 150 and / or in context-aware traffic management and optimization for resource conservation in a network (eg, a cellular network or other wireless network). Alternatively, application behavior may be tracked by the local proxy 175 and passed through the network 106 to the proxy server 125 component in the host server 100, for example as connection metadata. Proxy server 125 may then connect to application server / provider 110 and provide content and data to satisfy requests from device 150.

In addition, the local proxy 175 may determine one or more of the mobile device properties (eg, battery level, network with which the device is registered, radio status, or whether the mobile device is in use (eg, whether or not interacting with a user)). Can be identified and retrieved In some cases, the local proxy 175 may delay, prioritize (prefetch), and / or modify the data as appropriate prior to sending it to the proxy server 125, and relate to the example of FIGS. 2-3. Will be described in more detail below.

Local database 185 may be included in or connected to local proxy 175, and a locally-stored response to the data request may be queried before the data request is forwarded to proxy server 125. . The local-cached response is used by the local proxy 175 to retrieve the cached content stored in the cache store 185 when the cached content is still valid, thereby allowing a particular application on the mobile device 150 to be loaded. Can satisfy the request

Similarly, proxy server 125 of host server 100 may delay, prioritize, or modify data from a local proxy before sending it to a content source (eg, application server / content provider 110). In addition, the proxy server 125 may use the device attributes and connection metadata to generate a rule to satisfy a request of an application on the mobile device 150. Proxy server 125 may collect real-time traffic information for requests of applications for later use when optimizing similar connections with mobile device 150 or another mobile device.

In general, local proxy 175 and proxy server 125 are transparent to a plurality of applications running on a mobile device. The local proxy 175 is generally transparent to the operating system or platform of the mobile device and may or may not be device manufacturer-specific or device manufacturer-specific. In some cases, as an option, the local proxy 175 may be customizable to be partly or wholly device specific. In some embodiments, local proxy 175 may be embedded in a wireless model, firewall, and / or router.

In one embodiment, in some cases, host server 100 is a short message service center (SMSC) that communicates with device 150 when obtaining network traffic management, such as, for example, provided by a network service provider. 112) store and forward. 112 may use any other type of alternative channel, such as USSD, or other network control means. As will be further described with reference to the example of FIG. 3, the host server 100 is automatically forwarded to the device 150 if it is available, and forwarded later if the device 150 is not currently available. The content or HTTP response can be forwarded to SMSC 112.

In general, the distributed proxy and cache system of the present invention enables optimization of network usage, for example by servicing requests from local cache 185, which local proxy 175 satisfies via network 106. Reduce the number of requests that need to be made. In addition, local proxy 175 and proxy server 125 may filter irrelevant data from the communicated data. In addition, the local proxy 175 and proxy server 125 also accumulate low priority data and send it in batch to avoid the protocol overhead of sending individual data fragments. Local proxy 175 and proxy server 125 also compress or transcode the traffic to reduce the size of data transmitted over network 106 and / or 108. As the network is less used and network traffic can be synchronized between individual applications, signaling traffic in the network 106 and / or 108 can be reduced.

With regard to the battery life of mobile device 150, by servicing an application or content request from local cache 185, local proxy 175 may reduce the number of times the radio module is powered up. The local proxy 175 and the proxy server 125 may operate in conjunction to accumulate low priority data and to transmit the data collectively to reduce the number and / or time that the radio is turned on. The local proxy 175 can synchronize network usage by performing batch data transfers simultaneously for all connections.

2A shows a block diagram illustrating an example of a client-specific component in a distributed proxy and cache system located in an apparatus 250 that manages traffic of a wireless network for resource conservation, content caching, and / or traffic management. do. Client-side proxy (or local proxy 275) further categorizes mobile traffic and / or delivery policy based on application behavior, content priority, user activity, and / or user expectations. (delivery policy) can be implemented.

Device 250, which may be a portable or mobile device (eg, any wireless device), such as a portable telephone, may include, for example, network interface 208, operating system 204, context API 206, and mobile applications. It is common to include, and may be proxy-unaware 210 or proxy-aware 220. Device 250 is specifically illustrated as a mobile device in the example of FIG. 2, but is not so limited, and device 250 may include a wired network or a wireless network, such as WiFi, cellular, Bluetooth, Any wireless, broadband, portable / mobile or non-portable device capable of receiving and transmitting signals to satisfy data requests over a LAN, WAN, etc.).

Network interface 208 mediates the objects and data external to host server 250 via device 250 via any known and / or conventional communication protocols supported by hosts and external entities in the network. It can be a networking module that allows you to do that. The network interface 208 may include a network adapter card, a wireless network interface card (e.g., but not limited to, SMS interface, WiFi interface, 2G, 3G, 3.5G, 4G, LTE, etc.). Interface for different generations of mobile communication standards), Bluetooth, or whether the connection goes through a router, access point, wireless router, switch, multilayer switch, protocol converter, gateway, bridge, bridge router, hub, digital Media receivers, and / or repeaters.

Device 250 may further include client-side components of a distributed proxy and cache system that may include a local proxy 275 (eg, a mobile client of a mobile device) and a cache 285. have. In one embodiment, local proxy 275 is a user activity module 215, proxy API 225, request / transaction manager 235, caching policy manager 245 with application protocol module 248, traffic shaping. A traffic shaping engine 255, and / or a connection manager 265. The traffic shaping engine 255 may further include an alignment module 256 and / or a batching module 257, and the connection manager 265 further includes a radio controller 266. can do. The request / transaction manager 235 may further include an application behavior detector 236 and / or a prioritization engine 241, the application behavior detector 236 may include a pattern detector ( 237 and / or application profile generator 239. More or fewer components / modules / engines may be included in the local proxy 275 and in each example component.

As used herein, a "module", "manager", "handler", "detector", "interface", "controller", "normalizer", "generator", "invalidator", or An "engine" includes a general purpose, dedicated, or shared processor, and generally includes firmware or software modules executed by the processor. Depending on implementation specific or other considerations, modules, managers, handlers, detectors, interfaces, controllers, normalizers, generators, invalidators, or engines may be centralized or their functions distributed. Can be. A module, manager, handler, detector, interface, controller, normalizer, generator, invalidator, or engine is general or special hardware, firmware, or software implemented as a computer-readable medium for execution by a processor. It may include.

As used herein, computer readable media, or computer readable storage media, includes all media specified by legislation (eg, 35 USC 101 in the United States), and claims including computer readable (storage) media are effective. All non-legal media, to the extent intended, are specifically intended to be excluded. Known legal computer readable media include, but are not necessarily limited to, hardware (eg, registers, random access memory (RAM), nonvolatile (NV) storage, etc.).

In one embodiment, the portion for network traffic management of the distributed proxy and cache system is in, or includes, a device 250 that includes a local proxy 275 (mobile client) and / or cache 285. Can communicate. Local proxy 275 allows a user to access device applications and services such as e-mail, IM, voicemail, visual voicemail, feeds, the Internet, gaming, productivity tools, or other applications. May provide an interface on the device 250 that allows access to

The proxy 275 is generally application independent and has a TCP connection to a remote server (eg, server 100 in the examples of FIGS. 1A-1B and / or server proxy 125/325 in the examples of FIGS. 1B and 3A). May be used by applications (eg, both proxy-aware and proxy-aware applications 210 and 220, or mobile applications) to open the. In some cases, the local proxy 275 optionally includes a proxy API (which may be used to interface with the proxy-aware application 220 (or an application (eg, a mobile application) on a mobile device (eg, any wireless device)). 225).

In general, applications 210 and 220 may include any user application, widget, software, HTTP-based application, web browser, video or other multimedia streaming or downloading application, video game, social network application, electronics. Mail clients, RSS management applications, application stores, application management, document management applications, productivity enhancing applications, and the like. The application may be provided with the device OS, downloaded by the user, or otherwise provided by the device manufacturer or by the network service provider.

The local proxy 275 of one embodiment includes a context API 206 as shown, or is connected to the context API 206. Situation API 206 may be part of operating system 204 or device platform, or may be independent of operating system 204 as shown. Operating system 204 can include any operating system, including but not limited to, Windows Mobile, iOS, Android, Symbian, Palm OS, Brew MP, Java 2 Micro Edition (J2ME), Blackberry, and the like. It can be any past, present, and / or future version / version.

The context API 206 may be a plug-in of the operating system 204 of the device 205 or of a particular client / application. The context API 206 may be used to detect user or device activity (e.g., motion, gestures, device location, device location changes, device backlight, keystrokes, clicks, active touch screens, detection of mouse clicks, or other pointers). Signal can be detected. The context API 206 may be connected to an input device or sensor on device 250 to identify these signals. In general, such signals may be input received in response to explicit user input at the input device / means of device 250 and / or ambient signals / detected at or near device 250. It may include input collected from a contextual cue (eg, light, motion, piezo, etc.).

In one embodiment, the user activity module 215 interacts with the context API 206 to identify, determine, infer, detect, calculate, predict, and / or predict characteristics of user activity on the device 250. Have a conversation. In order to generate a profile for the characteristics of the user activity, various inputs collected by the situation API 206 may be aggregated by the user activity module 215. Such a profile may be generated by the user activity module 215 with various temporal characteristics. For example, to provide a view of what the user is doing or not at a particular time (eg, the time specified in the time window, the last minute, the last 30 seconds, etc.) The user activity profile may be generated in real time, and the user activity profile is also an application that describes the characteristics of the user's behavior for a particular task related to the device 250 or for a particular time period (eg, last 2 hours, last 5 hours). Or for a 'session' defined by a web page.

In addition, a characteristic profile may be generated by the user activity module 215 to depict a historical trend (eg, one week, one month, two months, etc.) for user activity and behavior. have. This profile history can be used to determine trends in user behavior (e.g., frequency of access at different times, trends for specific days of the week (weekdays or weekdays), location data (e.g., IP addresses, GPS, or cell base stations). User activity trends based on changes in location data, or user activity trends based on changes in location data (e.g., user activity based on user location, or whether a user is about to leave or go out, etc.) ) Can be inferred to obtain user activity characteristics.

In one embodiment, user activity module 215 may detect and track user activity with respect to applications, documents, files, windows, icons, and folders on device 250. For example, the user activity module 215 may include a foreground (when an application or window (eg, a web browser or any other type of application) is activated, closed, minimized, maximized, opened, or opened). when moving to the foreground, when moving to the background, when multimedia content is played, and so on.

In one embodiment, to optimize resource consumption, such as battery / power consumption, and more generally, to optimize the consumption of other device resources (eg, memory, authoring, and processing power), Characteristics of user activity on device 250 may be used to locally adjust the behavior of the device (eg, mobile device or any wireless device). In one embodiment, the use of the radio in the device may be adjusted based on the nature of the user behavior connected to the user activity module 215 (eg, by the radio controller 266 of the connection manager 265). have. For example, the radio controller 266 can turn the radio on or off based on the nature of the user activity on the device 250. In addition, depending on the nature of the user activity, the radio controller 266 may adjust the power mode of the radio (eg, to be a higher power mode or a lower power mode).

In one embodiment, another device (eg, another computer, capable of communicating with device 250) may be used (eg, via a cellular or another network) to use characteristics of user activity at device 250. A mobile device, wireless device, or non-portable device or server (eg, host servers 100 and 300 in the examples of FIGS. 1A-B and 3A) communicates with its device 250. It is possible to modify the communication frequency. Modulating the frequency of its communication to a remote device (e.g., reducing the frequency of communication, for example, reducing the frequency of data push when the user is idle, when new data, changed data, or data of certain importance are available) Local proxy 275 may use the characteristic information of the user behavior determined by user activity module 215, to indicate to the remote device to request notification of device 250.

In one embodiment, the user activity module 215 is responsive to determining that the user activity characteristic indicates that the user is active after a period of inactivity, so that the remote host (eg, server host in the examples of FIGS. 1A-B and 3A). Servers 100 and 300 may request to transmit the buffered data as a result of previously reduced communication frequency.

In addition to or in place of this, the local proxy 275 may display the characteristics of user activity on the device 250 by a remote device (eg, host servers 100 and 300 in the examples of FIGS. 1A-B and 3A). And the remote device determines how to change its own communication frequency associated with the device 250 for network resource conservation and device 250 resource conservation.

One embodiment of local proxy 275 detects a data request initiated at device 250, for example by application 210 and / or 220, and / or directly / indirectly by a user request. And a request / transaction manager 235 that can identify, intercept, process, and manage. The request / transaction manager 235 can determine how and when to process a particular request or transaction (or set of requests / transactions) based on transaction characteristics.

Request / transaction manager 235 may prioritize requests or transactions made by applications and / or users at device 250, such as by prioritization engine 241. The importance or priority of a request / transaction may be determined by the request / transaction manager 235, eg, the time sensitivity of the transaction, the time sensitivity of the content in the transaction, or the time criticality of the transaction, It can be determined by applying a set of rules that depend on the time importance of the data sent by the transaction and / or the time importance or importance of the application making the request.

In addition, the transaction characteristics may depend on whether the transaction is the result of user-interaction or other user initiated operation on the device (eg, user interaction with an application (eg, a mobile application)). In general, a time critical transaction may include a transaction resulting from a data transmission initiated by a user and may be prioritized accordingly. The transaction characteristics may vary depending on the size of the data transmitted as or expected to be transmitted as a result of the requested transaction. For example, the connection manager 265 may adjust a radio mode (eg, high power or low power mode via the radio controller 266) based on the size of the data that needs to be transmitted.

In addition, the radio controller 266 / connection manager 265 can adjust the radio power mode (high or low power mode) based on the time importance / sensitivity of the transaction. The radio controller 266 is a high power radio when a time critical transaction is initiated or detected, such as a transaction originating from a user initiated data transfer, an application running in the foreground, or any other event that meets certain criteria. You can trigger the mode.

In general, the priority may be set to default, for example based on device platform, device manufacturer, operating system, and the like. In addition to or in place of this, priorities may be set by specific applications, such as Facebook applications (eg mobile applications) may set their own priorities for various transactions ( For example, a status update may have a higher priority than a friend add request or a poke request, and a message transfer request may have a higher priority than a message delete request), an email client or IM chat. Clients can have their own settings for priority. Prioritization engine 241 may include a set of rules for assigning priorities.

The prioritization engine 241 may also track network provider limitations or specifications when determining the overall priority status for a request / transaction. In addition, the priority may be determined, in part or in whole, by user preference, either explicitly or implicitly. In general, a user may set specific priorities for different tiers, such as session, type, or application (eg, browsing session vs. game session vs. IM chat session, user). Can set the game session to always have a higher priority than the IM chat session, and the IM chat session can have a higher priority than the web browsing session). The user sets application specific priority (e.g., user can set Facebook-related transactions to have higher priority than LinkedIn-related transactions) for a specific transaction type (e.g. all applications All message transfer requests between them have a higher priority than message deletion requests, all calendar-related events have a higher priority, etc.) and / or set application specific priority for a particular folder. Can be.

The prioritization engine 241 may track and resolve conflicts between priorities set by different entities. For example, a manual setting specified by a user may be prioritized over a device OS setting and may be a network provider parameter / limitation (eg, network service area, default set for a geographic site, set for a particular time of day, or Set based on service / fee type) may limit any user specified settings and / or application setting priorities. In some cases, a manual sync request received from a user is set to some, most, or all priorities that are performed when the requested sync is requested, regardless of the individually assigned priority or the overall priority class for the requested action. Can be overridden.

Priorities may be internally specified and tracked in any known and / or conventional manner (e.g., without limitation, binary representations, multi-valued representations, graded representations), All are considered to be within the scope of the present technology.

Table 1

Table 1 shows some examples of transactions with examples of priorities assigned to a binary representation scheme for purposes of explanation. For additional types of events, requests, transactions, and as previously described, additional assignments are possible, and priority assignments can be made at higher or lower granular levels, such as at the session level or application level. .

As shown in the example of the table above, generally lower priority requests / transactions include reading message status, updating to unread, deleting messages, deleting contacts, and higher priority requests / transactions. , In some cases, status updates, new IM chat messages, new emails, update / cancel / remove calendar events, events in mobile game sessions, or other entertainment-related events, purchases made via web or online, and additional loading Or requesting content downloads, contact-related events, transactions to change device settings, location-aware or location-based events / transactions, or other initiation, known, expected or inferred by the user waiting for a response. It can include any event / request / transaction.

Inbox pruning events (e.g., e-mail, or any other type of message) are generally considered low priority, and if there are no other impending events, the use of radio on device 250 is disabled. Will not trigger. Specifically, when a scheduled pruning event occurs, a pruning event that deletes old email or other content may 'piggy backed' other communications that would otherwise not turn on the radio. For example, if a user has a preference set to 'Keep message for seven days', the next radio will be turned on instead of turning on the device radio to initiate message deletion on device 250 when the message exceeds the seventh day. The message is deleted when it is turned on. If the radio is already on, pruning can occur on a regular schedule.

To manage the outgoing traffic from device 250 for resource optimization (eg, to use device radio more efficiently for battery conservation), request / transaction manager 235 may request (eg, prioritization engine 241). You can use priority for). For example, when controlled by the connection manager 265, if a radio on the device 250 is not already switched on, a transaction / request below a certain priority level may trigger the use of the radio. . Alternatively, the radio controller 266 can turn on the radio so that the request can be sent when a request for a transaction is detected to be above a certain priority level.

In one embodiment, priority assignment (eg, priority assignment determined by the local proxy 275 or another device / object) is used to modify the frequency of the remote device's communication with the mobile device or wireless device. Can be. For example, the remote device can be configured to send a notification to the device 250 when higher importance data can be sent to the mobile device or wireless device.

In one embodiment, for example, by traffic shaping engine 255, transaction priorities may be used in conjunction with the nature of user activity when shaping or managing traffic. For example, the traffic shaping engine 255 may wait for a period of time to transmit a low priority transaction from the device 250 in response to detecting that the user is idle or inactive. In addition, by traffic shaping engine 255, a plurality of low priority transactions may be accumulated and batch transferred from device 250 (eg, via batch module 257). In one embodiment, priorities may be set, configured, or readjusted by the user. For example, the content described in Table 1 may be accessed in the same or similar form in the user interface of device 250, and may be used by the user, for example, to adjust or view priorities.

The batch module 257 may initiate a batch transfer according to certain criteria. For example, a batch transfer (eg, a batch transfer of multiple events that occur, where some events occur at different times) may occur after a certain number of low priority events have been detected, or the first low priority. It may occur after a certain time has passed and the event is initiated. In addition, when a higher priority event is initiated or detected at device 250, batch module 257 may initiate a batch transmission of accumulated low priority events. Batch transmission can be initiated in other ways when radio use is triggered for another reason (eg, to receive data from a remote device, such as host server 100 or 300). In one embodiment, when a batch transfer occurs, an impending pruning event (pruning of inbox), or any other low priority event may be executed.

In general, batch capability may be disabled or enabled at the event / transaction level, application level, or session level based on one or more of the following listed: user settings, device restrictions / settings , Manufacturer specifications, network provider parameters / limitations, platform specific restrictions / settings, device OS settings, etc. In one embodiment, a batch transfer can be initiated when an application / window / file is closed, terminated, or moved to the background, optionally, prompted to the user before initiating the batch transfer, and Can manually trigger a batch transfer.

In one embodiment, local proxy 275 caches data into cache 285 to locally regulate radio usage on device 250. When a request or transaction from device 250 can be satisfied by the content stored in cache 285, radio controller 266 sends the request to a remote entity (eg, host server 100 shown in FIGS. 1A and 3A). , 300) or a content provider / application server, such as the server / provider 110 shown in the examples of FIGS. 1B and 1C). Thus, the local proxy 275 uses the local cache 285 and cache policy manager 245 to store data locally to satisfy the data request, thereby using the device radio to conserve network resources and device battery consumption. Can be omitted or reduced.

When utilizing a local cache, if the request / transaction manager 225 intercepts a data request by an application on the device 250, it will tell the local repository 285 whether there are any locally stored responses. And whether the response is valid. When a valid response is available in the local cache 285, the response may be provided to an application on the device 250 without the device 250 having to access the cellular network or the wireless broadband network.

If no valid response is available, the local proxy 275 may query the remote proxy (eg, server proxy 325 of FIG. 3A) as to whether the remote stored response is valid. If the remotely stored response is valid, the response (eg, a response that may be stored in server cache 135 or optional caching server 199 in the case of the example of FIG. 1C) may be provided to a mobile device, which may be mobile. The device 250 can be made without having to access the cellular network, so that the consumption of network resources can be mitigated.

If a valid cache response is not available, or if a cache response is not available for an intercepted data request, the local proxy 275, such as the caching policy manager 245, may request the data request to be remote proxy (eg, FIG. 3A server proxy 325, which forwards the data request to a content source (eg, application server / content provider 110 of FIG. 1A), and the response from the content source forwards the remote proxy. And may be further described in the description associated with the example host server 300 of FIG. 3A. Cache policy manager 245 may manage or process requests using various protocols (eg, HTTP, HTTPS, IMAP, POP, SMTP, XMPP, and / or ActiveSync). Caching policy manager 245 may store the response to the data request locally as a cache entry in local database 285 for later use in satisfying the same or similar data request.

Caching policy manager 245 may request that the remote proxy monitor the response to the data request, and the remote proxy may notify device 250 when an unexpected response to the data request is detected. For these events, cache policy manager 245 clears or replaces locally stored responses on device 250 when it is notified of unexpected responses to data requests (eg, new data, changed data, additional data, etc.). can do. In one embodiment, caching policy manager 245 detects or identifies the protocol used for the particular request (eg, but not limited to HTTP, HTTPS, IMAP, POP, SMTP, XMPP, and / or ActiveSync). can do. In one embodiment, an application specific handler on the local proxy 275 (eg, via the application protocol module 246 of the caching policy manager 245) maps the port to a handler in the distributed proxy. port map (eg, port mapping to proxy server 325 in the example of FIG. 3A) to enable optimization of any protocol.

In one embodiment, for example, when a data request to a content source yields the same result to be returned to the mobile device, the remote proxy is not responsible for the changed result from the content source before returning the result to the device 250. The local proxy 275 notifies the remote proxy so that it can monitor the response received for the data request. In general, local proxy 275 may use local cached content to simulate an application server response to an application on device 250. This prevents the cellular network from being used for transactions where new / modified data is not available, thus making network resources available and preventing network congestion.

In one embodiment, local proxy 275 tracks, detects, observes, and monitors applications (eg, proxy-aware and / or proxy-aware applications 210 and 220) that are accessed or installed on device 250. An application behavior detector 236 for monitoring. Application behavior of one or more applications accessed on device 250, or patterns of behavior detected (eg, via pattern detector 237), may be used by local proxy 275 to satisfy the data needs of these applications. It can optimize the traffic in the required wireless network.

For example, based on the detected behavior of the plurality of applications, a traffic shaping engine 255 may be configured by at least some of the applications (eg, via the alignment module 256) to be networked (wireless network). ) Can be used to sort the content requests made. The alignment module 256 may delay or prioritize some of the requests that were first received for the alignment. When the request is sorted, the traffic shaping engine 255 may use the connection manager to poll the network to satisfy the application data request. Content requests for a plurality of applications may include behavior patterns or rules / settings (eg, content type (audio, video, text, etc.) requested by the plurality of applications, device (eg, mobile or wireless device) parameters, and And / or network parameters / traffic status, network service provider constraints / details, etc.).

In one embodiment, the pattern detector 237 may detect recurrence in application requests made by multiple applications, for example by tracking a pattern of application behavior. The pattern that is tracked is that a particular application, as a background process, periodically at a specific time, on a specific day, in a predictable manner, at a specific frequency, at a specific frequency, in response to a specific type of event, at a specific frequency, The content requested in response to a user query may include detection of polling with the same frequency, the frequency at which the same request is made, the interval between requests, the application making the request, or any combination thereof.

This iteration is used by traffic shaping engine 255 to allow content from content sources (eg, application server / content provider 110 of FIG. 1A) to result from application requests to be performed at mobile device or wireless device 250. Polling may be shared by a proxy server (eg, proxy server 125 of FIG. 1C or proxy server 325 of FIG. 3A) remotely located at the device 250. The traffic shaping engine 255 may decide to share polling when the iteration matches the rule. For example, multiple occurrences or requests for the same resource that have exactly the same resources or returned values or are based on the detection of a repeated period of time between the request and the response (eg, the detection of the requested resource at a particular time). This can be. The sharing of polling may reduce the bandwidth consumption that mobile device 250 requires to establish a wireless (cellular or other wireless broadband) connection with a content source for repeated content polling.

When no content change is detected in the polling of the content source, as a result of the sharing of polling, local cached content may be provided that is stored in the local cache 285 to satisfy the data request at the device 250. Thus, when data does not change, application data demands can be satisfied without having to activate radio usage or taking up cellular bandwidth. When data is changed and / or new data is received, the remote entity sharing the poll may notify the device 250. The remote entity may be a host server 300 as shown in the example of FIG. 3A.

In one embodiment, the local proxy 275 demands a periodic keep-alive message to maintain a TCP / IP connection that consumes a significant amount of power and thus negatively affects mobile device battery life. I can reduce use. Connection manager 265 (eg, heartbeat manager 267) in the local proxy may detect, identify, and intercept any or all heartbeat (keeplive) messages being sent from the application.

Heartbeat manager 267 may prevent any or all of these heartbeat messages from being sent over cellular, or another network, and instead replace backends (e.g., application server / provider 110 in the example of FIG. In order to maintain connectivity to the server, server components of the distributed proxy system (eg, shown in FIG. 1C) may rely on generating and sending heartbeat messages.

In general, local proxy 275 represents any one or some of the functions described for an individual manager, module, and / or engine. Within the scope of the present invention, local proxy 275 and device 250 may include more or fewer components, and may include more or less functionality.

FIG. 2B shows a block diagram illustrating additional examples of components in the cache system shown in the example of FIG. 2A that may cache for application behavior and / or network conditions and adapt the caching strategy.

In one embodiment, caching policy manager 245 includes metadata generator 203, cache look-up engine 205, cache appropriateness decision engine 246, poll schedule generator 247, Application protocol module 248, cache or connection selection engine 249, and / or local cache invalidator 244. Cache adequacy determination engine 246 includes a timing predictor 246a, a content predictor 246b, a request analyzer 246c, and / or a response analyzer 246d, and selects a cache or connection Engine 249 includes a response scheduler 249a. Metadata generator 203 and / or cache look-up engine 205 are connected to cache 285 (or local cache) for modifying or adding cache entries, or for querying them.

The cache look-up engine 205 further includes an ID or URI filter 205a, the local cache invalidator 244 further includes a TTL manager 244a, and the poll schedule generator 247 includes a schedule update engine ( 247a) and / or time adjustment engine 247b. One embodiment of caching policy manager 245 includes an application cache policy repository 243. In one embodiment, the application behavior detector 236 includes a pattern detector 237, a pole spacing detector 238, an application profile generator 239, and / or a priority engine 241. The poll interval detector 238 may further include a long poll detector 238a having a response / request tracking engine 238b. The pole spacing detector 238 may further include a long poll hunting detector 238c. The application profile generator 239 may further include a response delay interval tracker 239a.

The pattern detector 237, the application profile generator 239, and the priority engine 241 have been described with reference to the description for the pattern detector shown in the example of FIG. 2A. One embodiment further includes an application profile repository 242 that can be used by the local proxy 275 to store metadata or information related to the application profile (eg, behavior, pattern, type, etc. of the HTTP request). .

The cache adequacy determination engine 246 may be suitable for caching content from a content source with which the mobile device 250 interacts and has content (eg, application server / content provider 110 in the example of FIG. 1B). Can be detected, evaluated, or determined. For example, the decision engine 246 may be cacheable, potential, using information about a request initiated by the mobile device 250 and / or a response received for the request. cacheability, or non-cacheability may be determined. In some cases, decision engine 246 may first verify whether the request is associated with a blacklisted destination or whether the request itself originated from a blacklisted client or application. If so, further processing and analysis may not be performed by decision engine 246 and the request may be allowed to be sent over the air to the server to satisfy the request. Blacklisted destinations or applications / clients (e.g., mobile applications) are maintained locally at the local proxy (e.g., in the application profile repository 242), or remotely (e.g., in the proxy server 325 or another object). Can be maintained.

In one embodiment, for example, via request analyzer 246c, decision engine 246 collects information about an application or client request generated at mobile device 250. The request information may include request characteristic information, for example, a request method. For example, the request method may indicate the type of HTTP request made by the mobile application or client. In one embodiment, if the request method is a GET request or a POST request, the response to the request may be identified as being or may be cacheable. Another type of request (eg, OPTIONS, HEAD, PUT, DELETE, TRACE, or CONNECT) may or may not be cached. In general, HTTP requests by request methods that cannot be cached will not be cached.

The request characteristic information may further include information related to the request size, for example. Responses to requests with body sizes exceeding a certain size (eg, HTTP requests) will not be cached. For example, if the information about the request indicates that the request body size of the request does not exceed a certain size, it may be determined to be cacheability. In some cases, the maximum cacheable request body size may be set to 8092 bytes. In other cases, different values may be used, for example, depending on network capacity or network operator specific settings.

In some cases, content from a particular application server / content provider (eg, server / content provider 110 of FIG. 1C) may contain criteria that specify the time importance of the content requested from the content source, eg, a content source. On the basis, it is determined that it is suitable to be cached. In one embodiment, a local proxy (eg, local proxy 175 or 275 in FIGS. 1C and 2A) is configured to satisfy subsequent requests made by the application with content from the host server requested by the application. Apply selection criteria for storing as elements cached in a local cache on the mobile device.

Cache adequacy determination engine 246 further detects a pattern of requests sent from mobile device 250 and / or a pattern of received responses (eg, by a mobile application or other client on device 250). On the basis, predictability can be detected in the request and / or response. For example, request characteristic information collected by decision engine 246 (eg, request analyzer 246c) may be sent to one request and the other requests generated by the same client on the mobile device (or to the same host). Periodicity information between the remaining other requests that are directed (eg, having similar or identical identifier parameters).

The one request and the other requests made by the same client have a varying pattern that may be partially reproducible, or partially or wholly reproducible, at a fixed rate, or almost at a fixed rate, or at a dynamic rate. As such, periodicity may be detected by decision engine 246 or request analyzer 246c. When a request is made with some identifiable pattern (eg, regular interval, interval with detectable pattern, or trend (eg, increasing trend, decreasing trend, etc.)), the timing predictor 246a may be applied to a particular application on the device. The request made by it can be determined to be predictable and can be identified as likely to be cached, at least in terms of timing.

In general, identifiable patterns or trends may include, for example, any application or client behavior, which may be simulated locally on local proxy 275 on mobile device 250, or For example, it can be simulated remotely by the proxy server 325 on the host 300, or local simulations and remote simulations can be combined to mimic application behavior.

In one embodiment, the determination engine 246 may collect information regarding the response to the application or client request generated at the mobile device 250, for example via the response analyzer 246d. In general, the response is received from the server or host of the application (eg, mobile application) that sent the request at mobile device 250. In some cases, the mobile client or application may be a mobile version of the application (eg, social networking, search, travel management, voicemail, contact manager, email) or a web site accessed through a web browser or desktop client.

For example, the response characteristic information may include an indication as to whether transfer encoding or chunked transfer encoding is used when transmitting the response. In some cases, responses to HTTP requests using transport encoding or chunked encoding are not cached and are therefore moved for later analysis. Because usually, chunk responses are large and unsuitable for caching, because the processing of these transactions is likely to slow the overall performance. Thus, in some embodiments, it may be determined that there is a possibility of being cacheable or cacheable when transport encoding is not used in response transmission.

In addition, the response characteristic information may include an associated status code of the response that may be identified by response analyzer 246d. In some cases, HTTP responses with status codes that cannot be cached are generally not cached. Response analyzer 246d may extract the status code from the response and may determine whether the status code matches a cacheable or non-cacheable status code. Examples of any cacheable status codes include 200-OK, 301-Redirect, 302-Found, 303-See other, 304-Not Modified, 307Temporary Redirect, or 500-Internal server error. Any non-cacheable status code may include, for example, 403-Forbidden or 404-Not found.

In one embodiment, it may be determined that the information for the response does not represent a non-cacheable status code or is likely to be cacheable or cacheable if it represents a cacheable status code. If response analyzer 246d detects a non-cacheable status code associated with a particular response, the specific transaction (request / response pair) is removed from further processing and is not cacheable temporarily, semi-permanently, or permanently. Can be determined. If the status code indicates that it is cacheable, then the transaction (eg, request and / or response pair) may be subject to further processing and analyzed to confirm that it is cacheable, as shown in the example flow chart of FIGS. 9-10. Can be.

In addition, the response characteristic information may include response size information. In general, if the response does not exceed a certain size, the response may be cached locally at the mobile device 250. In some cases, the default maximum cached response size is set to 115 KB. In other cases, the maximum cacheable response size may be different, and / or operational status, network status, network capacity, user preferences, network operator requirements, or other application-specific, user-specific and / or device-specific factors. On the basis of this, it can be dynamically adjusted. In one embodiment, response analyzer 246d may identify the magnitude of the response and may be determined to be cacheable or likely to be cacheable if the response magnitude does not exceed a certain threshold or maximum.

In addition, the response characteristic information is response body information for one response to one request and for other responses to other requests generated by the same client on the mobile device or delivered to the same content host or application server. body information). For example, the response analyzer 246d compares the response body information for the response with the response body information for the other responses so that the dynamic content (or content that changes frequently and cannot be efficiently serviced by cache entries) is compared. Caching of, for example, responses including financial data, stock quotes, news feeds, real-time sporting event activities, and the like can be prevented.

Cache adequacy determination engine 246 (e.g., content predictor 246b) may reliably identify repeatability, identify indicators of repeatability, identify the likelihood of repeatability, or determine a content source (e.g., Figures 1A-1C). For example, the predictability of the response received from the content host / application server 110 can be identified. Repeatability can be detected, for example, by tracking at least two responses received from a content source and determining whether the two responses are equal to each other. For example, if the response body information for one response and the response body information for another response sent by the same mobile client or delivered to the same host / server are the same or substantially the same, then response analyzer 246d This may be determined as caching possible. The two responses may or may not be responses sent in response to successive requests. In one embodiment, the hash value of the response received for a request from a particular application determines the repeatability of the content as a whole and / or for a particular request (with or without heuristics) for the application. Used to Additional identical responses may be required for some applications or under certain circumstances.

The repeatability of the received content need not be 100% finalized. For example, if a certain number or a certain percentage of responses are the same or similar to each other, it may be determined that the responses are repeatable. A certain number or a certain percentage of identical / similar responses can be set to default or based on the application making the request (eg whether the application is very dynamic with a steady update or less dynamic with a rare update). Can be tracked for a period of time. When caching content to be provided to a requesting application or client on mobile device 250, any indicated predictive or repeatable, or likelihood of being repeated by a distributed system may be utilized.

In one embodiment, for a long pole type request, if it is detected that the response delay times for the first two responses are equal to each other, substantially the same, or increase in interval, the local proxy 175 receives the third message. You can start caching the response to the request. In general, the responses received for the first two responses must be identical to each other, and if the third response received for the third request is verified to be the same (for example, if R0 = R1 = R2), then the third response is mobile. It can be cached locally on the device. Depending on the type of application, type of data, type of content, user preference, or carrier / network operator specification, fewer or more identical responses may need to begin to be cached.

When detected by the long pole hunting detector 238c of the application behavior detector 236, the increasing response delay of the same response to the long pole is determined by a hunting period (e.g., application / client on the mobile device). How long the network is looking for the longest time between a request and a response).

An example can be described below using T0, T1, T2, where T is the delay between the time a request is sent and the time a response (eg, response header) is detected / received for successive requests. Indicates time:

T0 = response 0 (t)-request 0 (t) = 180 s. (+/- tolerance)

T1 = response1 (t)-request1 (t) = 240 s. (+/- tolerance)

T2 = response2 (t)-request2 (t) = 500 s. (+/- tolerance)

In the example timing sequence T0 <T1 <T2 shown above, this may indicate a hunting pattern for the long pole when the network timeout has not yet been exceeded. In addition, if the received responses R0, R1, and R2 for the three requests are equal to each other, R2 may be cached. In this example, R2 is cached during the long pole hunting period without waiting for the long pole to settle, so response caching is accelerated (eg, optional accelerated caching that can be implemented for all or selected applications). Behavior).

Thus, the local proxy 275 specifies the information that can be extracted from the timing sequence shown above (e.g. polling schedule, polling interval, polling type) as a proxy server, starts caching, and the proxy server polls the source and polls the source. You can request to start monitoring (eg any of T0, T1, T2 (typically T2, i.e. the longest detection interval without timeout) as the polling interval, and the response from the source is received. The polling interval will be sent to the proxy server 325 of FIG. 3A to be used when polling the content source (eg, application server / service provider 310).

However, if it is detected that the time interval is getting shorter, the application (eg mobile application) / client receives the response reliably from the content source (eg application / server server / provider 110 or 310). Hunting may still be possible for a time interval that may be, so in general, caching should not be started until the request / response interval points to the same or incremental time interval, for example for a long pole type request.

An example of handling the detected decreasing delay may be described below using T0, T1, T2, T3, and T4, where T is the time at which the request was sent and the response (eg, response header) for successive requests. Indicates the delay time between the detected / received times:

T0 = response 0 (t)-request 0 (t) = 160 s. (+/- tolerance)

T1 = response1 (t)-request1 (t) = 240 s. (+/- tolerance)

T2 = response2 (t)-request2 (t) = 500 s. (+/- tolerance)

Timeout at T3 = 700 s. (+/- tolerance)

T4 = response 4 (t)-request 4 (t) = 600 (+/- tolerance)

As shown in the timing sequence above, when the pattern T1 < T2 < T3 > T4 for the response delay is detected (e.g., by the long pole hunting detector 238c of the application behavior detector 236), the long pole hunting period. It may be determined that T3 is likely to exceed the network timeout. In request 3, it is likely that the response was not received because the connection was terminated before the response was sent or made available by the network, the application, the server, or for some other reason. In request 4 (after T4), if a response (eg, response 4) is detected or received, then the local proxy 275 may use the response for caching (if the content repeatability condition is met). The local proxy may also use T4 as the poll interval in the polling schedule that the proxy server is set to monitor / polle the content source.

When the above description detects an increasing response delay, it indicates that caching may begin while the long pole is in hunting mode, unless a response is received and timed out for a particular request. This may be referred to as optional accelerated caching during long pole hunting. Caching may also begin after the hunting mode is complete (eg, after a poll request has settled to a constant or near constant delay value). Hunting may or may not occur during long poles, and when hunting occurs, the proxy 275 detects the hunting and decides whether to start caching during the hunting cycle (increasing intervals with the same response) or when hunting is stable. You can wait for the value to settle.

In one embodiment, the timing predictor 246a of the cache adequacy determination engine 246 tracks the timing of the response received from an outgoing request from an application (eg, a mobile application) or a client such that the local cached response is In a manner that simulates the behavior of the content source (eg, application server / content provider 110 or 310) (eg, in response to (eg, in terms of timing)), the application / Any identifiable pattern that is partially or wholly reproducible may be detected so that it can be provided to the requesting client on mobile device 250 (in a manner to be delivered to the client). This means that when a response to an application or mobile client request is serviced from a local and / or remote cache, instead of being retrieved or received directly from a content source (eg, application, content provider 110 or 310), ensure the preservation of experience

In one embodiment, the decision engine 246 or the timing predictor 246a may, for example, request / response tracking engine 238b and / or application profile generator 239 (eg, response delay interval tracker 239a). ) Determine timing characteristics of a particular application (eg, mobile application) or client. Using the timing characteristic, the timing predictor 246a determines whether the received content is appropriate or likely to be cached in response to the request. For example, the poll request interval between two consecutive requests from a particular application may be used to determine whether the request interval can be repeated (eg, constant, nearly constant, increment with pattern, decrease with pattern, etc.). Can be determined and predicted, and can thus be reproduced at least some of the time exactly, or within tolerance levels.

In some cases, timing characteristics of a particular request type for a particular application, for a plurality of requests of one application, or for a plurality of applications may be stored in the application profile repository 242. In general, the application profile repository 242 can store any type of information or metadata related to application request / response characteristics, including timing patterns, timing repeatability, content repeatability, and the like.

The application profile repository 242 may also store metadata indicating the type of request used by a particular application (eg, long poll, long-held HTTP request, HTTP streaming, push, COMET push, etc.). have. An application profile indicating the type of request by the application can be used when a subsequent same / similar request is detected, or when a request is detected from an already categorized application. In this way, the timing characteristics for a particular request type that has been tracked and / or analyzed, or for a specific application's request, need not be reanalyzed.

Application profiles may be associated with a time-to-live (eg, default expiration time). Using an expiration time for an application profile, or for various types of application or request profiles, can be used on a case-by-case basis. The time-to-live or actual expiration time of the application profile entry may be set to a default value, individually determined or in combination. The application profile may also be wireless network, physical network, network operator, or specific carrier specific.

One embodiment includes an application blacklist manager 201. The application blacklist manager 201 is connected to the application cache policy repository 243 and may be partially or fully located within the local proxy or caching policy manager 245. Similarly, blacklist manager 201 may be located partially or fully within local proxy or application behavior detector 236. The blacklist manager 201 has been 'blacklisted' permanently or temporarily, and can aggregate, track, update, manage, adjust, or dynamically monitor a list of destinations of servers / hosts that are identified as not cached. have. The destination blacklist may be used to, when identified in the request, cause the request to be sent for service over the (cellular) network. Further processing of the request cannot be performed because it is detected that the request is delivered to the blacklist destination.

The blacklist destination may be identified in the application cache policy repository 243 by an address identifier such as a particular URL or identifier pattern (eg, URI pattern). Generally, for any reason, the user (owner / user of mobile device 250), the operating system / mobile platform of device 250, the destination itself, a network operator (of a cellular network), an Internet service provider, other third party The blacklist destination may be set or modified by any side including it, or according to the list of destinations for the application known to be uncacheable / not cacheable. Some items in the blacklist destination may include destinations aggregated based on analysis or processing performed by a local proxy (eg, cache suitability determination engine 246).

For example, an application or mobile client on the mobile device that the response is identified as inappropriate to be cached may be added to the blacklist. Their corresponding host / server may be added in addition to, or in place of, the identifier of the requesting application / client on mobile device 250. Some or all of these clients identified by the proxy system may be added to the blacklist. For example, for all application clients or applications that are temporarily identified as unsuitable for caching, only those with specific detection characteristics (based on timing, periodicity, response content change frequency, content predictability, size, etc.) are blacklisted. Can go up.

The item of the blacklist may include a list of requesting applications or requesting clients on the mobile device (rather than destination) so that when a request is detected from a particular application or a specific client, it may be sent over the network for a response. This is because blacklisted clients / applications are not cached in most situations.

Depending on the mobile account associated with the mobile device to which the application is accessed, certain application profiles may be handled or processed differently (eg, different behavior of local proxy 275 and remote proxy 325). For example, a more paying account, i.e., a Premier account, may allow for more frequent access, or higher bandwidth allowance, of a wireless network, thus emphasizing better performance compared to the conservation of resources, while providing a local proxy ( Caching policy implemented between 275 and proxy server 325. Specific application profiles may be handled or handled differently under different wireless network conditions (eg, based on congestion or network outage, etc.).

Cache adequacy may be determined, tracked, and managed for a plurality of clients or applications on mobile device 250. For various other requests, or types of requests initiated by a particular client or application on mobile device 250, cache suitability may also be determined. The caching policy manager 245, in conjunction with the timing predictor 246a and / or the content predictor 246b, empirically determines or estimates that it is predictable, or likely to be predictable, for various applications or specific applications. Can track, manage, and store cacheable information on various requests for The cacheable information also includes a condition (eg, the application may be cached at a specific time of day or at a specific day of the week, a specific request of a specific application may be cached, or all requests with a specific destination address may be cached). And, under the above conditions, caching is appropriate, and the conditions may be determined and / or tracked by the cache adequacy determination engine 246 and connected to the cache adequacy determination engine 246 ( 243) may be stored and / or updated as appropriate.

Information in the application cache policy repository 243, related to the caching of requests, applications, and / or associated conditions, may be used later when the same request is detected. In this manner, decision engine 246 and / or timing and content predictor 246a / b do not need to track and reanalyze request / response timing and content characteristics in order to evaluate for caching. In addition, in some cases, cacheable information may be shared with a local proxy of another mobile device, either through direct communication or through a host server (eg, proxy server 325 of host server 300).

For example, the cacheable information detected by the local proxy 275 on the various mobile devices may be remote host server or proxy server 325 on the host server (eg, host server 300 or proxy in the example of FIG. 3A). Server 325 or proxy server 125 in the example of FIGS. 1B-C. Thereafter, the remote host or proxy server may use application-specific, request-specific caching-capable information, and / or information about any associated condition, in one wireless network, or in a plurality of wireless networks, to be used. It may be distributed to various mobile devices or their local proxies that span (either the same service provider or multiple wireless service providers). In general, the selection criteria for caching may further include, for example, the mobile device's status, network conditions, and / or radio coverage statistic indicating whether the mobile device is active or inactive. have. The cache adequacy determination engine 246 may identify, in any order, a source from which caching may be suitable, in any one or more of the criteria.

If the application server / content provider has identified or detected content that is likely to be suitable for local caching on mobile device 250, cache policy manager 245 may retrieve the content received from the content source from mobile device 250. The associated content received from the identified source can still be cached by storing as a cache element of a local cache (eg, local cache 185 or 285 in the example of FIGS. 1C and 2A).

The response may be stored in cache 285 (eg, also referred to as a local cache) as a cache entry. In addition to the response to the request, the cached entry may include response metadata with additional information related to the caching of the response. The metadata may be generated by the metadata generator 203 and may include, for example, timing data (eg, access time of a cache entry, or creation time of a cache entry). The metadata may include additional information, such as any information suitable for use in determining whether a response stored as a cached entry is used to satisfy the next response. For example, metadata information may include request timing history (eg, request timing history including request time, request start time, request end time), hash, time interval, or time interval of the request and / or response. It may further include a change.

Cache entries are typically stored in cache 285 in association with a time-to-live (TTL), which may be allocated or determined, for example, by TTL manager 244a of cache invalidator 244. to be. Regardless of whether the response is still valid or relevant for a particular request or client / application on mobile device 250, the lifetime of the cache entry is the time that the entry lasts within cache 285. For example, if the lifetime of a particular cache entry is set to 12 hours, the cache entry is deleted or removed, or otherwise, even if the response body contained within the cache entry is still valid and applicable to the associated request. It is indicated that it has an exceeded life time.

Unless otherwise specified (eg, by the TTL manager 244a), default lifetimes are automatically used for all entries, or the TTL manager 244a is based on individual TTL (eg, various dynamic or static criteria). Each cache entry can be generated using the determined TTL). Each entry may have a single lifetime associated with both response data and any associated metadata. In some cases, the associated metadata may have a different lifetime (eg, longer lifetime) than the response data.

In addition or in lieu thereof, a proxy server located remotely of the mobile device 250 and in wireless communication with the mobile device 250 (eg, proxy server 125 or 325 in the example of FIGS. 1B and 3A). ) Can be informed of the content source with the content to be cached so that the proxy server can monitor the content source (eg, application server / content provider 110) for new or changed data. Similarly, a local proxy (eg, local proxy 175 or 275 in FIGS. 1B and 2A) is stored to the proxy server as content received from a particular application server / content provider as an element cached in local cache 285. You can inform.

If the content is cached locally, future polling for the cache policy manager 245 to contact the application server / content host (eg 110 or 310) so that the radio of the mobile device is not activated to service the polling request. Upon receiving the request, the cached element may be retrieved from the local cache and responded to the polling request made at the mobile device 250. For example, cache look-up engine 205 may query cache 285 to ascertain whether the response to be serviced is a response. The response may be serviced from the cache in response to identifying a matching cache entry and also using any metadata stored with the response in the cache entry. Cache entries may be queried by the cache look-up engine using the URI of the request or another type of identifier (eg, via ID or URI filter 205a). The cache look-up engine 205 may further use the metadata stored with the matching cache entry (eg, any) to determine whether the response is still suitable for use when served for the current request. Timing information or other related information).

Cache look-up by engine 205 may be performed using one or more of a variety of strategies. In one embodiment, a plurality of look-up strategies may be performed sequentially for each entry stored in cache 285 until at least one look-up strategy identifies a matching cache entry. The strategy used to perform the cache look-up may include strict match criteria, or match criteria to allow non-match parameters.

For example, look-up engine 205 may match an identifier stored in the current request with which the proxy is attempting to identify the cache entry (eg, a URI for a host or a resource) and the cache entry with the identifier stored together. A strict consensus strategy can be followed. If the identifier includes a URI or a URL, the matching algorithm for strict matching will find a cache entry that matches all parameters in the URL. For example:

Example 1.

1. The cache contains an entry for http://test.com/products/.

2. The request is being made to the URI http://test.com/products/.

Since both URIs are identical, you will find that the strict strategy matches.

Example 2.

The cache contains an entry for http://test.com/products/?query=all.

2. The request is being made with the URI http://test.com/products/?query=sub.

Under the strict strategy summarized above, no match will be found because the URIs in the query parameters are different.

In another example strategy, look-up engine 205 looks for a cache entry using an identifier that partially matches an identifier reference in the current request that the proxy is attempting to identify a matching cache entry. For example, the look-up engine 205 may find a cache entry using an identifier that has a different request identifier and query parameter value. When using this strategy, the look-up engine 205 collects the collected information for a plurality of previous requests (eg, a list of any parameters in the identifier), using any detected parameters of the current request, later Can be checked. For example, if a cache entry is stored with a URI or URL identifier, the look-up engine retrieves the cache entry using a URI with different query parameters. If found, the engine 205 checks whether the information collected during the previous request, detected in the current URI / URL or extracted from the current URI / URL belongs to an arbitrary parameter list (eg, any The cache entry can be examined to find a list of parameters.

Example 1.

1. The cache contains an entry for http://test.com/products/?query=all, where the query is marked arbitrary.

2. A request is being made with the URI http://text.com/products/?query=sub.

Since the query parameters are marked as random, they will be found to match.

Example 2.

1. The cache contains an entry for http://test.com/products/?query=all, and the query is marked as random.

2. A request is being made with the URI http://test.com/products/?query=sub&sort=asc.

Since the current request includes a parameter that is not marked random in the cache entry, no match will be found.

Additional strategies for detecting cache hits may be employed. These strategies may be implemented alone or in any combination. A cache hit can be determined when any one of these strategies determines a match. A cache miss may be indicated when the look-up engine 205 determines that the requested data cannot be served from the cache 285 for any reason. For example, a cache miss can be determined when no cache entry is identified for any or all of the used look-up strategies.

A cache miss can also be determined when a matching cache entry exists but is determined to be invalid or unrelated to the current request. For example, look-up engine 205 further analyzes the metadata associated with the matching cache entry (eg, metadata that may include timing data of the cache entry) to respond to the current request. It can be determined whether it is still suitable for use.

When the look-up engine 205 identifies a cache hit (e.g., an event indicating that the requested data can be served from the cache), the response stored in the match cache entry is served from the cache to satisfy the application / client's request. You can.

By servicing requests using cache entries stored in cache 285, network bandwidth and other resources can be used to request / receive poll responses that may not have changed from responses that have already been received at mobile device 250. no need. By servicing and fulfilling requests from such service and fulfillment applications (eg, mobile applications) via cache entries in local cache 285, the requests do not need to be transmitted over the wireless network, which consumes additional bandwidth. Enable efficient resource and mobile network traffic utilization and management. In general, cache 285 may persist between powering on and off of mobile device 250 and may also persist between application / client refresh and restart.

For example, when the local proxy 275 receives an outgoing request from its mobile device 250 or application or other type of client on the mobile device 250, it intercepts the request and sends the mobile device ( It is determined whether the response cached in local cache 285 of 250 is available. If a response cached in the local cache 285 is available, the local proxy 275 responds to the outgoing request using the cached response on the cache of the mobile device. Thus, the outgoing request can be satisfied without the need to send outgoing requests over the wireless network, thus conserving network resources and battery consumption.

In one embodiment, the content server may establish a persistent connection over a persistent connection (eg, a persistent connection that would have been established without interception by a local proxy, or a long-held HTTP connection, or a long pole type connection). Timing the response to the requesting application / client on the device 250 to correspond to the manner in which it would have responded to the outgoing request. By serving content stored from local cache 285 rather than fresh content received from the intended content source (e.g., content host / application server 110 of Figures 1B-C), the end user experience is not reflected or minimally reflected. In order to preserve application behavior as much as possible, the timing of the response may be emulated or simulated by the local proxy 275. The timing can be estimated within tolerance parameters that can be replicated correctly, or similarly handled by the application so that the user may not notice or cause operational problems.

For example, the outgoing request may be a request for a persistent connection intended for a content server (eg, an application server / content provider in the example of FIGS. 1B-1C). In a persistent connection with a content source (server) (e.g., long pole, COMET-style push, or any other push simulation in an asynchronous HTTP request, long-lived HTTP request, HTTP streaming, etc.) The connection is then maintained for any time. The connection between the mobile device and the server typically can last until the content is available at the server for delivery to the mobile device. Thus, in general, there may be a slight time delay between when a long poll request is sent and when a request is received from a content source. If no response is provided by the content source for a particular time, the connection may be terminated for network reasons (eg, with socket closure) if no response is sent.

Thus, in order to emulate a response sent over a persistent connection (e.g., a long pole style connection) from a content server, the response of the content server must be timed out before responding with a cached response to the outgoing request. Can be simulated. For example, the length of time interval may be determined per request or per application (per client).

In one embodiment, the time interval is determined based on the request characteristics (eg, timing characteristics) of the application on the mobile device from which the outgoing request originated. For example, the poll request interval can be used to determine the time interval to wait before responding to a request with a local cache entry and can be managed by the response scheduler 249a.

One embodiment of cache policy manager 245 includes a poll schedule generator 247, which can generate a polling schedule for one or more applications on mobile device 250. Polling schedules can monitor content sources for one or more applications (such that polled responses can be periodically verified by polling the host server (host server 110 or 310) from which the request is forwarded) on behalf of the mobile device. When a polling interval may be specified that may be used by an entity that is physically and / or distinct from the mobile device 250. One example of such an external entity that can monitor content at the source for mobile device 250 is a proxy server (eg, proxy server 125 or 325 shown in the examples of FIGS. 1B and 3A-C). .

For example, based on the interval between polling requests delivered from the mobile device to the content source, a polling schedule (eg, polling rate / frequency) can be determined. The polling schedule or polling rate may be determined (by the local proxy) at the mobile device 250. In one embodiment, the poll interval detector 238 of the application behavior detector 236 monitors the polling request passed from the mobile device 250 to the content source, so that any or all applications (eg, mobile applications) are made. The interval between poll requests can be determined.

For example, the poll interval detector 238 can track the request and response for an application or client on the device 250. In one embodiment, subsequent requests are tracked prior to the detection of an outgoing request initiated from an application (eg, a mobile application) on mobile device 250 by the same mobile client or application (eg, a mobile application). Using the request information collected for the request for which the response is cached, the polling rate may be determined. In one embodiment, the polling rate is determined from the average of the time intervals between previous requests generated by the same client making the request. For example, a first interval may be calculated between a current request and a previous request, and a second interval may be calculated between two previous requests. The polling rate can be set from the average of the first and second intervals and sent to the proxy server when setting up the caching strategy.

When generating an average, alternative intervals may be calculated, such as a plurality of previous requests in addition to two previous requests may be used, and three or more intervals may be used when calculating the average. In general, when calculating the interval, a particular request does not need to receive a response from the host server / content source to be used for calculating the interval. That is, as long as the request is detected, even if the request fails to transmit or fails to retrieve the response, the timing characteristic of the particular request may be used in the interval calculation.

One embodiment of the poll schedule generator 247 includes a schedule update engine 247a and / or a time adjustment engine 247b. The schedule update engine 247a uses the speed used by a particular application server / content host from a previously set value based on interval changes detected in actual requests made from a client or application (eg, mobile application) on the mobile device 250. You can decide whether you need to update the rate or polling interval.

For example, a request to determine the monitoring rate may be sent from an application (eg, a mobile application) or a client at different request intervals. The scheduled update engine 247a may determine the updated polling interval of the actual request and generate a new rate for polling the host on behalf of the mobile device 250 that is different from the previously set rate. The updated polling rate is communicated through the cellular network to a remote proxy (proxy server 325) so that the remote proxy can monitor the particular host. In some cases, the updated polling rate may be determined at the remote proxy or remote object monitoring the host.

In one embodiment, the time coordination engine 247b may further optimize the poll schedule generated to monitor the application server / content source 110 or 310. For example, optionally, the time adjustment engine 247b may specify a time to begin polling the proxy server. For example, in addition to setting a polling interval at which the proxy server monitors the application, the server / content host can specify when the actual request is made at the mobile client / application.

In some cases, however, due to inherent transmission delays, additional network delays, or other types of latency, the remote proxy server sets up polling from the local proxy with some delay (for example, minutes or seconds). Receive This has the effect of detecting a change in the response at the source after the request is made by the mobile client / application, which invalidates the cached response after the response has been serviced to the application once again after it is no longer current or valid. To occur.

To solve this unoptimized result of serving once again before invalidating out-dated content, the time coordination engine 247b is added to the rate at which time polling should begin. t0), where the specified initial time point t0 is specified and known to the proxy server 325 as a time shorter than the actual time when the request is generated by the mobile application / client. In this way, the server polls for resources just before the actual request occurs by the mobile client so that any content change can be detected before the actual application request. This prevents invalid / irrelevant content / responses from being served once again before fresh content is served.

In one embodiment, the outgoing request from the mobile device 250 is based on the timing characteristics of the previous request from the same application or client on the mobile device 250, such as a persistent connection (eg, long pole, COMET). Style push, and long term maintenance (HTTP) requests). For example, the request and / or corresponding response may be tracked by the request / response tracking engine 238b of the long pole detector 238a of the pole interval detector 238.

The timing characteristic of successive requests can be determined to set a polling schedule for the application or client. Polling schedules are used to monitor content sources (content source / application servers) to find content changes so that cached content stored on a local cache within mobile device 250 can be properly managed (eg, updated or discarded). have. In one embodiment, the timing characteristic may include, for example, a response delay time 'D' and / or an idle time 'IT'.

In one embodiment, the response / request tracking engine 238b may track the request and the response to determine, calculate, and / or estimate a timing diagram for an applicant or client request.

For example, after a response is received at the mobile device according to the first request, the response / request tracking engine 238b may be configured to send the first request (request 0) initiated by the client on the mobile device and the client on the mobile device. Detect the first request (request1) initiated by the. The second request is a request following the first request.

In one embodiment, response / request tracking engine 238b may track requests and responses to determine, calculate, and / or estimate timing diagrams for application or client requests. After the response is received at the mobile device according to the first request, the response / request tracking engine 238b detects the first request initiated by the client on the mobile device and the second request initiated by the client on the mobile device. can do. The first request is a request following the first request.

The response / request tracking engine 238b further determines the relative timing between the first request, the second request, and the response received in accordance with the first request. In general, relative timing may be used by long pole detector 238a to determine whether a request generated by an application is a long pole request.

In general, the first request and the second request used by the response / request tracking engine 238b when calculating relative timing are used after the long pole hunting period is settled or when long pole hunting does not occur. Is chosen to be. General timing characteristics of the long pole hunting period can be detected, for example, by the long pole hunting detector 238c. That is, a request that is tracked by the response / request tracking engine 238b and used to determine whether a particular request is a long pole occurs after the long pole has settled.

In one embodiment, the long pole hunting detector 238c detects an increasing request interval (eg, an increasing delay time) followed by a request without any response (eg, a connection is timed out), or By detecting an increasing request interval followed by a decrease in the interval, the hunting mode can be identified or detected. In addition, the long pole hunting detector 238c may apply a filter value or threshold to a request-response time delay value (eg, an absolute value) where a delay detected above may be considered as a long pole request-response delay. Can be. The filter value may be any suitable value characteristic of the long pole and / or network conditions (eg, 2 seconds, 5 seconds, 10 seconds, 15 seconds, 20 seconds, etc.) and may be used as a filter or threshold.

The response delay time 'D' refers to the starting point for receiving a response after the request is sent, and idle refers to the time for sending a request that follows after the response is received. In one embodiment, a comparison (eg, tracking) of the idle time ('IT') of the average of the response delay time ('D') or ('D') (eg, any average for any time period). Based on the comparison performed by engine 238b), for example, by long pole detector 238a, it is detected that the outgoing request is for a persistent connection. The number of averages used may be fixed, dynamically adjusted, or changed for longer periods of time. For example, if the response delay time interval is greater than the idle time interval (D> IT or D >> IT), it is determined that the request initiated by the client is a long poll request. In one embodiment, the tracking engine 238b of the long pole detector calculates, determines, or measures the response delay time interval as the amount of time elapsed between the time of the first request and the time of initial detection or full receipt of the response. Estimate.

In one embodiment, for example, a persistent connection established in response to a long pole request or a long pole HTTP request detects an immediate or near immediate occurrence of the next request after receipt of a response to the previous request. When the idle time ('IT') is short (eg IT ~ 0), the request is detected as being for a persistent connection. Thus, idle time ('IT') can be used to detect this immediate or near immediate re-request to identify the long pole request. After a response to the first request is received, the absolute or relative timing determined by the tracking engine 238b may be used to determine whether the second request was re-requested immediately or near instantaneously. For example, if IT is small and D + RT + IT ~ D + RT, the request may be categorized as a long pole request. IT may be determined to be smaller when it is smaller than the threshold. The threshold may be fixed or calculated for a short time period (one session, one day, one month, etc.) or may be calculated for a longer time period (eg, several months, or the lifetime of the analysis). For example, for each request, an average IT can be calculated, and a threshold can be determined using this average IT (eg, an average IT below a certain percentage can be used as the threshold). As such, over time, the threshold may be automatically adapted to changes in network conditions and server capacity, resource availability, or server responses. The fixed threshold may take any value (eg, 1s, 2s, 3s, ..., etc., but not limited to).

In one embodiment, the long pole detector 238a compares the relative timing (e.g., determined by the tracking engine 238b) to the request-response timing characteristic for another application so that the request of the application is a long pole request. Can be determined. For example, if the response delay interval time (eg, average for x requests, or any number of delay intervals averaged over x times) is greater than the threshold, the request initiated by the client or application is long. It can be determined as a poll request.

Response delay intervals for requests generated by other clients, for example by request / response tracking engine 238b and / or by application profile generator 239 (eg, response delay interval tracker 239a). The threshold may be determined using time. The other client may reside on the same mobile device and the threshold is locally determined by a component on the mobile device. For example, a threshold may be determined for all requests for all resource servers across all networks. The threshold may be set to a specific constant value (eg, 30 seconds) to be used for all requests or for any request that does not have an applicable threshold (eg, a long pole is detected if D> 30 seconds).

In some cases, proxy servers (eg, FIGS. 3A-B) may reside on different mobile devices and thresholds may be located outside the mobile device and communicate with a plurality of different mobile devices over a wireless network. Can be determined by proxy server 325 of host 300, which will be further described with reference to FIG. 3B.

In one embodiment, cache policy manager 245 sends a polling schedule to a proxy server (eg, proxy server 125 or 325 shown in the examples of FIGS. 1B-1C and 3A), and by a proxy server, yes For example, it can be used to monitor content sources to find changed content or new content (updated responses that are different from cached responses associated with the request or application). The polling schedule sent to the proxy can include, but is not limited to, a plurality of timing parameters, such as intervals (time from request 1 to request 2) or timeout intervals (eg, time to wait for a response, used in long poles). Not). Referring to the timing diagram of the request / response timing sequence, the timing intervals 'R1', 'D', 'RT' and / or 'IT' or any statistical manipulation of the values (eg average, standard deviation, etc.) It may be sent in whole or in part to this proxy server.

For example, when the local proxy 275 detects a long pole, various timing intervals (eg, 'D', 'RT' and / or 'IT') of the request / response timing sequence may be directed to the proxy server 325. Can be sent and used when polling to a content source (eg, application server / content host 110). Local proxy 275 may also inform proxy server 325 that it is a particular application or request long poll request to be monitored (eg, instruct the proxy server to set a "long poll flag"). In addition, the proxy server may use various timing intervals to determine when to send a keep-alive indication on behalf of the mobile device.

When new or changed data (eg, an updated response) is detected from an application server / content source for a particular request, the local cache invalidator 244 of the caching policy manager 245 is configured to cache the local cache (eg, cache 185 or 285). )) You can invalidate my cache elements. Based on the notification received from the proxy server (eg, proxy 325 or host server 300), it may be determined that the cached response is invalid for the outgoing request. The source providing the response to the mobile client's request may be monitored to determine the relevancy of the cached response stored in the cache of the mobile device 250 to the request. For example, when a cached response for a particular request or a specific application is no longer valid, the cached invalidator 244 may further remove / delete the cached response from the cache of the mobile device.

In one embodiment, the cached response is once again provided to the application that issued the outgoing request and then removed from the cache if it is determined that the cached response is no longer valid. The cached response may be provided without waiting for a time interval, or may be provided again after waiting for a time interval (eg, a time interval determined to be specific to emulate a response delay within a long pole). In one embodiment, the time interval is the average value of the values of the response delay 'D', or two or more response delays 'D'.

For example, new or changed data may be detected by a proxy server (eg, proxy server 125 or 325 shown in the examples of FIGS. 1B-1C and 3A). When the cache entry for a particular request / pol is invalidated, the use of the radio on mobile device 250 is activated (eg, by local proxy 275 or cache policy manager 245) to satisfy subsequent polling requests. This may be further explained with reference to the interactive diagrams of FIGS. 9-10.

One embodiment of cache policy manager 245 is a cache or connection that may determine whether to use locally cached entries to satisfy poll / content requests generated by mobile device 250 by an application or widget. And a selection engine 249. For example, local proxy 275 or cache policy manager 245 may intercept a poll request made by an application (eg, mobile application) on a mobile device to contact an application server / content provider. The selection engine 249 can determine whether the received content for the intercepted request was stored locally as a cache element, thereby enabling the mobile device's radio to be activated to satisfy the request made by the application (eg, mobile application). It may be determined whether there is a need to be made, and also before using the cached response to respond to the outgoing request, it may be determined whether the cached response is still valid for the outgoing request.

In one embodiment, in response to determining that the associated cached content is present and still valid, the local proxy 275 retrieves the cached element from the local cache and sends a response to the application (eg mobile application) that has made a poll request. By providing, the radio of the mobile device is not activated to provide a response to the application (eg, mobile application). In general, the local proxy 275 may continue to provide a cached response each time an outgoing request is received until an updated response that is different than the cached response is detected.

When it is determined that the cached response is no longer valid, a new request for a particular request is sent over the wireless network for an updated response. Requests for new and updated responses may be sent to an application server / content provider (eg, server / host 110) or a proxy server on a host server (eg, proxy 325 on host 300). In one embodiment, if no new response is received within the time interval, the cached response may be provided as a response to the outgoing request, before being removed from the cache on the mobile device.

FIG. 2C is a block diagram illustrating another example of components of an application behavior detector 236 and a caching policy manager 245 in a local proxy 275 on the client side of the distributed proxy system shown in the example of FIG. 2A. Shows. The application behavior detector 236 and the caching policy manager 245 shown are, for example, the local proxy 275 detects cache defeat and is addressed by an identifier intended to deflect the cache. Caching of content can be performed.

In one embodiment, the caching policy manager 245 includes a cache defeat resolution engine 221, an identifier formalizer 211, a cache adequacy determination engine 246, a poll schedule generator 247, an application protocol. Module 248, cache or connection selection engine 249 with cache query module 229, and / or local cache invalidator 244. The cache bite resolution engine 221 may further include a pattern extraction module 222 and / or a cache bite parameter detector 223. The cache dip parameter detector 223 may further include a random parameter detector and / or a time / date parameter detector 226. One embodiment further includes an application cache policy repository 243 coupled to decision engine 246.

In one embodiment, the application behavior detector 236 includes a pattern detector 237, a pole spacing detector 238, an application profile generator 239, and / or a priority engine 241. The pattern detector 237 may further include a cache dip parameter detector 223 having, for example, a random parameter detector 233 and / or a time / date parameter detector 234. One embodiment further includes an application profile repository 242 coupled to the application profile generator 239. The application profile generator 239 and the priority engine 241 have been described in connection with the description of the example application behavior detector 236 of FIG. 2A.

Cache defeat resolution engine 221 detects, identifies, tracks, manages, and / or monitors the content or content source (eg, server or host), which content or content source deselects the cache or decodes the cache. Using an identifier having one or more mechanisms intended to fit, and / or addressed by an identifier (eg, a resource identifier such as a URL and / or a URI). The cache defeat resolution engine 221 may be configured to, for example, from a particular data request issued by an application or a client whose identifier is likely to or will cache the cache, if the data request is a cacheable host or Where to address the content or response may be detected from a server (eg, application server / content host 110 or 310).

In one embodiment, the cache defeat resolution engine 221 uses the identifier of the data request detected at the mobile device 250 to cache the content source (eg, application server / content host 110 or 310). Detect or identify the dip mechanism. The cache bite resolution engine 221 may detect or identify a parameter in an identifier that may indicate that the cache bite mechanism is used. For example, a format, syntax, or pattern of parameters may be used to identify cache dips (eg, patterns, formats, or syntax of states determined or extracted by pattern extraction module 222). have.

The pattern extraction module 222 parses the identifier into a plurality of parameters or components and performs a matching algorithm for each parameter, either of which is one or more designated formats (eg, date and / or the like). Or time format). For example, parameters that have been parsed from the identifier, as a result of the match (by the cache dip parameter detector 223), can be used to identify cache dip parameters that may include one or more changing parameters.

In one embodiment, cache diptight parameter detector 223 detects random parameters (eg, by random parameter detector 224) and / or the date and / or time parameters generally used for cachepitt. Can be detected. Cache dip parameter detector 223 detects random parameters (e.g., represented by parameter 752 shown in FIG. 7), and / or utilizes commonly used formats for these parameters, Tests can be used to detect time / date.

In addition to detecting the pattern, format, and / or syntax, the cache definite parameter detector 223 can determine whether a particular parameter is debiting the cache and whether content addressed by the distributed caching system can be cached. Decide or confirm more. The cache bite parameter detector 223 may detect this by analyzing the received response for the identifier used by the particular data request. In general, even when a plurality of data requests use identifiers having differently varying parameters for each of the plurality of data requests, the varying parameter in the identifier points to cache depth when the responses corresponding to the plurality of data requests are the same. Can be identified. For example, a request / response pair indicates that the received response is the same, even though the resource identifier includes a parameter that varies with each request.

For example, at least two identical responses may be required to identify that the changing parameter represents a cache bite. In some cases, at least three identical responses may be needed. The requirement for the same number of responses needed to determine that a particular parameter with a value that varies between requests may be cache default may be application specific, context dependent, and / or user dependent / user specific, or a combination thereof. . These requirements may also be static or distributed caches to meet explicit / implicit feedback on specific performance thresholds and / or user experience (e.g. whether the user or application is receiving related / fresh content in response to a request). By the system, it can be adjusted dynamically. If the application starts to malfunction due to response caching, and / or if the user indicates dissatisfaction (explicit user feedback) or if the system detects user dissatisfaction, or to confirm the cache dip, or the system caches certain parameters. More identical responses may be needed to treat them as intended for the default.

Cache adequacy determination engine 246 may have content from which content sources that mobile device 250 interacts with (eg, application server / content provider 110 in the example of FIG. 1C) may be suitable for caching. Can be detected, determined, or determined. In some cases, a particular application server / content provider (eg, server / provider 110 of FIG. 1C) may be used for caching based on a set of criteria (eg, a criterion that specifies the time importance of the content requested from the content source). It is determined to be suitable. In one embodiment, a local proxy (eg, local proxy 175 or 275 of FIGS. 1B-1C and 2A) from a host server requested by the application to satisfy subsequent requests made by the application. Apply selection criteria to store content as cached elements in a local cache on the mobile device.

In addition, the selection criteria may include, for example, the state of the mobile device, network conditions, and / or radio coverage statistics indicating whether the mobile device is active or inactive. The cache adequacy determination engine 246 may use any one of the criteria or any combination of the criteria, in any order, when identifying a source to which caching may be suitable.

If the application server / content provider has identified or detected content that is likely to be suitable for local caching on mobile device 250, cache policy manager 245 may localize the content received from the content source on mobile device 250. By storing as a cache element in a cache (eg, local cache 185 or 285 in the example of FIGS. 1B-1C and 2A), caching of relevant content received from the identified source can proceed. The content source may also be known to a proxy server (eg, proxy server 125 or 325 of FIGS. 1B-1C and 3A) remotely located on mobile device 250 and in wireless communication with the mobile device 250. The proxy server may monitor the content source (eg, application server / content provider 110) to find new or changed data. Similarly, local proxies (eg, local proxies 175 or 275 in FIGS. 1B-1C and 2A) may tell the proxy server that content received from a particular application server / content provider is stored as a cached element in the local cache. I can tell you.

In one embodiment, a cache element is stored in local cache 285 in association with a normalized version of an identifier using one or more parameters intended to deflect the cache. The identifier may be normalized by the identifier normalizer module 211, for example, the normalization process may include: converting the URI scheme and host to lowercase, capitalizing the characters of the percent-encoded escape sequence, default One or more of removing the port, and removing the duplicate slash.

In another embodiment, received by the normalizer 211 or cache defeat parameter handler 212 by removing a parameter for cache defeat and / or in response to a request using an identifier. The identifier is normalized by substituting a static value that can be used to address a cached response or associated with the cached response. For example, cached elements stored in local cache 285 (shown in FIG. 2A) may be identified using a normalized version of the identifier or a hash value of the normalized identifier. The hash value of the identifier or the hash value of the normalized identifier may be generated by the hash engine 213.

If the content is cached locally, the cache policy manager 245 is cached in the local cache so that when a subsequent poll request to contact the content server is received, the radio of the mobile device is not activated to service the poll request. The element may be retrieved and responded to a polling request made at mobile device 250. By so servicing and fulfilling requests from applications (e.g., mobile applications) via local cache entries, network bandwidth and other to request / receive poll responses that may not change from responses already received at mobile device 250. Since no other resources need to be used, more efficient resource and mobile network traffic utilization and management is possible.

One embodiment of cache policy manager 245 includes a poll schedule generator 247 that can generate a polling schedule for one or more applications on mobile device 250. The polling schedule may specify a polling interval that may be used by a proxy server (eg, proxy server 125 or 325 shown in the examples of FIGS. 1B-1C and 3A) when monitoring a content source for one or more applications. Can be. The polling schedule may be determined based on, for example, the interval between polling requests from the mobile device to the content source. In one embodiment, the poll interval detector 238 of the application behavior detector can monitor polling requests from the mobile device 250 to the content source, so that polling requests from any or all applications (eg, mobile applications) are made. You can determine the spacing between them.

In one embodiment, cache policy manager 245 sends a polling schedule to a proxy server (eg, proxy server 125 or 325 shown in the examples of FIGS. 1B-1C and 3A), the polling schedule being a proxy. It can be used by the server, for example, when monitoring content sources to find changed or new content. For a particular request, when new or changed data is detected from the application server / content source, the local cache invalidator 244 of the caching policy manager 245 is cached in a local cache (eg, cache 185 or 285). You can invalidate an element. For example, new or changed data can be detected by the proxy server. When a cache entry for a particular request / pol is invalidated and / or removed after invalidation (eg, deleted from the cache), the use of the radio on the mobile device 250 is (eg, local proxy) to satisfy subsequent poll requests. Or by cache policy manager 245), which is further described with reference to the interactivity diagram of FIG. 4B.

In another embodiment, a proxy server (eg, proxy server 125 or 325 in the case of the examples of FIGS. 1B-1C and 3A) uses a modified version of the resource identifier used in the data request to create a new resource identifier. Specific content sources (application server / content host 110 of FIGS. 1B-1C) may be monitored to find data or modified data. For example, if a content source or identifier is detected to use the cache defeat mechanism, a modified (eg, normalized) identifier can be used to poll the content source. The modified or normalized version of the identifier may be passed to the proxy server by the caching policy manager 245, or more specifically, by the cache default parameter handler 212 of the identifier normalizer 211.

The modified identifier used by the proxy server to poll the content source on behalf of the mobile device / application (eg, mobile application) may or may not be the same as the normalized identifier. For example, the normalized identifier may be the original identifier with the change cache dip parameter removed, while the modified identifier uses substitute parameters in place of the parameters used to dip the cache (eg, changing parameters). Is replaced with a static value or other specified value known to the local proxy and / or proxy server). The modified parameter is determined by the local proxy 275 and can be passed to the proxy server. In addition, modified parameters may be generated by the procedure server (eg, by the identifier modifier module 353 shown in the example of FIG. 3C).

One embodiment of cache policy manager 245 is a cache or connection that may determine whether to use locally cached entries to satisfy poll / content requests generated at mobile device 250 by an application or widget. And a selection engine 249. For example, local proxy 275 or cache policy manager 245 may intercept a poll request made by an application on a mobile device (eg, mobile application) to connect with an application server / content provider. In order to determine whether the radio of the mobile device needs to be activated to satisfy a request made by an application (eg, a mobile application), the content received for the intercepted request by the selection engine 249 is local to the cache element. Can be determined whether or not it is stored. In one embodiment, local proxy 275 responds to determining that the associated cached content is present and still valid, and retrieves the cached element from the local cache and responds to the application that made the polling request (eg, a mobile application). Can be provided such that the radio of the mobile device is not activated to provide a response to the application (eg, mobile application).

In one embodiment, for example, using the cache query module 229, the local cache 285 (shown in FIG. 2A) using the fully qualified version of the identifier, or the hash value of the normalized version of the identifier, may be used. Stored cached elements can be identified. With a normalized identifier that has been removed, or otherwise replaced, by the cache bite parameter so that the associated cached element can be identified and retrieved in the future to satisfy other requests using the same type of cache bite. Together, cached elements can be stored. For example, when it is determined that the identifier used in a later request is using the same cache default parameter, to satisfy the data request, a normalized version of the identifier is generated and identifying a cached response stored in the mobile device cache. Can be used for By the hash engine 213 of the identifier normalizer 211, a hash value of the identifier, or a hash value of the normalized identifier, may be generated.

FIG. 2D is a block illustrating an example of additional components of the local proxy 275 shown in the example of FIG. 2A, which may further perform mobile traffic categorization and policy implementation based on application behavior and / or user activity. Shows a figure.

In this embodiment of the local proxy 275, the user activity module 215 further adds a user activity tracker 215a, a user activity prediction engine 215b, and / or a user expectation manager 215c. Include. The application behavior detector 236 may further include a prioritization engine 241a, a time criticality detection engine 241b, an application state categorizer 241c, and / or an application traffic categorizer 241d. Can be. The local proxy 275 may further include a backlight detector 219 and / or a network configuration selection engine 251. The network configuration selection engine 251 may include a wireless generation standard selector 251a, a data rate specifier 251b, an access channel selection engine 251c, and / or an access point. It may further include a selector.

In one embodiment, the application behavior detector 236 is a mobile device from which traffic originated, or through which the traffic is delivered, for example, via an application state categorizer 241c and / or a traffic categorizer 241d. The activity state of the application on 250 can be detected, determined, identified, or inferred. Foreground application vs. Since the traffic of the background application may be handled differently, the activity state may be determined depending on whether the application is in the foreground or background state on the mobile device (via the application state categorizer 241c). Can be.

In one embodiment, using a level of heuristic certainty, or based on the backlight state of the mobile device 250, or other software agent or hardware sensor on the mobile device (not limited) Non-resistance, capacitive sensor, ambient light sensor, motion sensor, touch sensor, etc.) may determine, detect, identify, or infer an activity state. In general, when the backlight is on, traffic may be treated or determined to be generated from an application that is active or in the foreground, or the traffic is interactive. In addition, when the backlight is on, the traffic may be treated or determined to be traffic from user interaction or user activity, or traffic containing data the user is expecting within a certain time frame.

In one embodiment, the activity state is determined based on whether the traffic is interactive traffic or maintenance traffic. Interaction traffic may include responses from transactions and requests generated directly from interactions with user activities / applications, and may include content or data that a user is waiting or expecting to receive. Maintenance traffic may be used to support the functionality of an application that is not directly detected by the user. Maintenance traffic may also include actions or transactions that may be made in response to a user action but that the user does not actively wait for or expect a response.

For example, a mail or message deletion operation at mobile device 250 generates a request to delete the corresponding mail or message from the server, but generally the user does not wait for a response. Thus, the request may be categorized as maintenance traffic, or traffic having a lower priority (eg, by prioritization engine 241a), and / or (by time importance detection engine 214b). It can be categorized as not time-critical.

In contrast, mail 'read' or message 'read' requests initiated by the user on mobile device 250 may be categorized as 'interactive traffic', because the user typically reads the message or mail. This is because it waits to access content or data when requesting. Similarly, such requests may be categorized as having a higher priority (eg, by prioritization engine 241a) and / or having time importance / time sensitivity (eg, by time importance detection engine 241b). Can be converted.

The time importance detection engine 241b is transmitted from the mobile device 250 or from the host server (eg, host 300) or application server (eg, app server / content source 110). Determining, identifying, and inferring the time sensitivity of data included in the transmitted traffic. For example, time sensitive data may include status updates, stock information updates, IM presence information, email messages or other messages, actions from mobile game applications, web page requests, location updates. And the like. Depending on the nature of the content or request, data that is not time-sensitive or time-sensitive may include a message deletion request, read mark, or edited action, application-specific action (eg, friend add, friend delete request), And other information that does not change the message or attributes frequently. In some cases, when the data is not time critical, the timing for allowing traffic to pass through is set based on when additional data needs to be sent from the mobile device 250. For example, the traffic shaping engine 255 may include one or more subsequent to be sent together in one power-on event of the mobile device radio (eg, using the alignment module 256 and / or batch module 257). You can align traffic with a transaction. The sorting module 256 can also sort polling requests that are forwarded to the same host server in close proximity, since these requests are likely to be answered with the same data.

Alternatively, or in combination with this, the activity status may be determined from evaluating, determining, estimating, inferring, and identifying user activity at mobile device 250 (eg, via user activity module 215). For example, user activity tracker 215a may be used to directly detect and track user activity. The traffic resulting therefrom can then be appropriately categorized for later processing to determine the handling policy. In addition, user activity prediction engine 215b may predict or predict user activity. By predicting user activity or anticipating user activity, traffic occurring after the prediction can be treated as resulting from user activity and can be appropriately categorized to determine the delivery policy.

In addition, the user activity module 215 also generally manages user expectations (eg, via the user expectations manager 215c and / or in combination with the activity tracker 215 and / or the prediction engine 215b), thereby generally allowing the user activity module 215 to manage user expectations. It can ensure that traffic is properly categorized so that user expectations are met. For example, actions initiated by the user may be analyzed (eg, by the expectation manager 215) to determine or infer whether the user is waiting for a response. If it is determined that the user is waiting for a response, this traffic must be handled in accordance with the policy so that the user does not experience an unwanted delay when receiving such a response or action.

In one embodiment, an advanced generation wireless standard network is selected based on the activity state of the application of the mobile device from which the traffic originates or is forwarded for use in transmitting traffic between the mobile device and the host server in the wireless network. . Selected by advanced technical standards, such as 3G, 3.5G, 3G +, 4G, or LTE networks, to handle traffic that includes user interaction, traffic generated as a result of user activity, or data that users expect or are waiting for Can be. In addition, an advanced generation wireless standard network may be selected to transmit the data contained in the traffic delivered to the mobile device responsive to the foreground activity.

When categorizing traffic and defining a delivery policy for mobile traffic, the traffic is transferred between the mobile device and the proxy server 325 and / or the application server (e.g., app server / host 110). The network settings may be selected for use on the mobile device 250 (eg, by the network setting selection engine 251). The network settings selected include application activity status (e.g. background or foreground traffic), application traffic categories (e.g. interactive or maintenance traffic), any priority of data / content, application behavior related to time sensitivity / importance. It may be determined based on the information collected by module 236.

The network setting selection engine 2510 may include a generation standard (eg, via wireless generation standard selector 251a), a data transmission rate (eg, via data transmission rate specifier 251b), an access channel (eg, access channel selection). One or more of the engine 251c, and / or the access point (eg, via the access point selector 251d) may be selected and specified in any combination.

For example, when an activity state is interacting with a user or in the foreground on a mobile device, a more advanced generation (eg, 3G, LTE, or 4G, or more) may be selected or specified for the traffic. . Alternatively, older generation standards (eg, 2G, 2.5G, or 3G, or less) may be specified for traffic when one or more of the following are detected: the situation when the application is not interacting with the user, The situation where the application is running in the background on a mobile device, or when the data contained in the traffic is not time critical or otherwise determined to have a lower priority.

Similarly, network settings with slower data rates for traffic may be specified when one or more of the following are detected: the situation where the application is not interacting with the user, the situation where the application is running in the background on the mobile device. , Or when the data contained in the traffic is not time critical. An access channel (eg, forward access channel or dedicated channel) can be specified.

3A shows a block diagram illustrating an example of server-side components in a distributed proxy and cache system residing on a host server 300 that manages traffic in a wireless network for resource conservation. The server side proxy (or proxy server 325) may further categorize and / or deliver policy of mobile traffic based on application behavior, content priority, user activity, and / or user expectations. Can be implemented.

Host server 300 generally includes a network interface 308 and / or one or more repositories 312, 314, and 316, for example. Server 300 may request data over a network including any portable / mobile or non-portable device, server, cluster of computers, and / or any wired or wireless network (e.g., WiFi, cellular, Bluetooth, etc.). It may be another type of processing unit (eg, any number of machines in the example of FIG. 16) capable of receiving or transmitting a signal to satisfy.

The network interface 308 may include a networking module or device, whereby the server 300 may send data in the network having objects outside the host server 300 to the hoses and external entities. Mediated via any known and / or conventional communication protocol supported by the present invention. Specifically, the network interface 308 allows the server 300 to communicate with a plurality of devices, including the mobile telephone device 350 and / or one or more application server / content providers 310.

The host server 300 may store information (eg, network characteristics, conditions, connection types, etc.) about the connection with the device in the connection metadata repository 312. In addition, any information about the third party application or content provider may also be stored in the repository 312. The host server 300 may store information about the device (eg, hardware capability, attributes, device settings, device language, network capability, manufacturer, device model, OS, OS version, etc.) in the device information repository 314. In addition, the host server 300 may store information about the network provider and various network service areas in the network service provider repository 316.

The communication activated by the network interface 308 may be a simultaneous connection (eg, a cellular connection) with the device 350 and / or a connection with the content server / provider 310 (eg, wired / wireless, HTTP, the Internet). Connection, LAN, WiFi, etc.) to manage traffic between device 350 and content provider 310 and / or consume power (battery) on serviced device 350 to optimize network resource usage Can be preserved. The host server 300 may communicate with a mobile device 350 serviced by different network service providers and / or serviced in the same / different network service area. The host server 300 may have various types or levels of mobile capabilities (eg, 1G, 2G, 2G transitional generations (2.5G, 2.75G), 3G (IMT-2000), 3G transitional generations (3.5G, 3.75). G, 3.9G), 4G (IMT-advanced, etc.) operating a device 350, and is compatible with the device 350.

In general, network interface 308 may or may not be connected through a router, access point, wireless router, switch, multilayer switch, protocol converter, gateway, bridge, bridge router, hub, digital media receiver, and / or repeater. Whether or not, network adapter cards, wireless network interface cards (e.g., SMS interface, WiFi interface, mobile communication standards of various generations (1G, 2G, 3G, 3.5G, 4G type networks such as LTE, WiMAX, etc.) Interface), Bluetooth, WiFi, or any other network.

The host server 300 may further include server-side components of a distributed proxy and cache system that may include a proxy server 325 and a server cache 335. In one embodiment, proxy server 325 may include HTTP access engine 345, cache policy manager 355, proxy controller 365, traffic shaping engine 375, new data detector 347, and / or connection manager. 395.

The HTTP access engine 345 may further include a heartbeat manager 398, the proxy controller 365 may further include a data invalidator module 368, and the traffic shaping engine 375. May further include a control protocol 376 and a batch module 377. More or fewer components / modules / engines may be included in proxy server 325 and each described component.

As used herein, "module", "manager", "handler", "detector", "interface", "controller", "normalizer", "generator", "validator", or "engine" is general purpose, It includes a dedicated or shared processor, and generally includes a firmware or software module executed by the processor. Depending on implementation specific considerations or other considerations, modules, managers, handlers, detectors, interfaces, controllers, normalizers, generators, invalidators, or engines may be centralized or their functionality distributed. have. A module, manager, handler, detector, interface, controller, normalizer, generator, invalidator, or engine includes software embedded in computer-readable (storage) media for execution by general or special purpose hardware, firmware, or processor. can do. As used herein, computer readable media, or computer readable storage media, includes all media specified by legislation (eg, 35 USC 101 in the United States), and claims including computer readable (storage) media are effective. All non-legal media, to the extent intended, are specifically intended to be excluded. Known legal computer readable media include, but are not necessarily limited to, hardware (eg, registers, random access memory (RAM), nonvolatile (NV) storage, etc.).

A device making an application or content request to an application server or content provider 310 (eg, in the example of mobile device 350, the request is intercepted and connected to device 350 and application server / content provider 310) The proxy server 325. Specifically, the proxy server may communicate with a local proxy of the mobile device 350 (eg, proxies 175 and 275 in the example of FIGS. 1 and 2) and The local proxy forwards the data request to the proxy server 325, in some cases for further processing, and if necessary, for transmission to the application server / content server 310 to respond to the data request.

In this configuration, the host 300, or proxy server 325 in the host server 300, may provide intelligent information provided by the local proxy when coordinating communication with the device in a manner that optimizes the use of network and device resources. intelligent information) can be used. For example, the proxy server 325 may identify characteristics of user activity at the device 350 to modify the communication frequency. Characteristics of user activity may be determined by activity / behavior awareness module 366 in proxy controller 365, for example, via information collected by a local proxy on device 350. have.

In one embodiment, the communication frequency may be controlled, for example, by the connection manager 395 of the proxy server 325 to adjust the frequency or update of the push of content to the device 350. For example, if the nature of the user activity indicates that the user is in an inactive state, the push frequency may be reduced by the connection manager 395. In one embodiment, when the nature of user activity indicates that the user is active after a period of inactivity, the connection manager 395 sends buffered data as a result of the reduced frequency of communication to the device 350. The frequency of communication with the device 350 may be adjusted.

In addition, proxy server 325 includes priority awareness of various requests, transactions, sessions, applications, and / or specific events. This acknowledgment may be determined by a local proxy on device 350 and provided to proxy server 325. In general, priority recognition module 367 of proxy server 325 may evaluate the priority of various events or applications (eg, time-importance, time-sensitive, etc.), and further, priority recognition module ( 367 may track the priority determined by the local proxies of the device 350.

In one embodiment, with priority recognition, the connection manager 395 may further modify the frequency of communication of the server 300 with the device 350 (eg, when controlled by the radio controller 396). To use). For example, the server 300 may notify the device 350 when a data or update of importance / priority level that meets the criteria is available for transmission, thus requesting the use of the radio if it is not already in use. have.

In one embodiment, proxy server 325 may detect a plurality of occurrences of an event (eg, a transaction, content, data received from server / provider 310), and the events are accumulated and device 350 may be accumulated. Can be sent in batches. Batch transmissions may be cumulative and transmission of events may be delayed based on prioritization and / or user activity / application behavior tracked by modules 367 and / or 366. For example, when a higher priority event (that meets a threshold or criterion) is detected at the server 300, batch sending a plurality of events (having a lower priority) to the device 350 may be batch. May be initiated by the processing module 377. In addition, a batch transfer from server 300 may be triggered when the server receives data from device 350, indicating that the device radio is already in use and thus the device radio is on. In one embodiment, the proxy server 325 sorts each message / packet to be sent in batches based on event / transaction priority, so that higher priority content, such as when a connection is lost or the battery is exhausted. May be transmitted first.

In one embodiment, server 300 caches data (e.g., managed by caching policy manager 355) such that the frequency of communication with device 350 over a network (e.g., cellular network) is modified (e.g., Can be reduced). For example, data may be cached in the server cache 335 and later retrieved or sent to the device 350 in a batch, thereby reducing the need to turn on the device 350 radio. The server cache 335 is shown as located outside the host server 300 in the example of FIG. 3A, but may be partially or wholly located within the host server 300. In some cases, server cache 335 may be managed by another entity (eg, in the example of FIG. 1C), for example, as managed by application server / content provider 310, network service provider, or another third party. It may be configured in part or in whole or in part with another cache managed by optional caching proxy server 199.

In one embodiment, content caching is performed locally at the device 350 with the help of the host server 300. For example, the proxy server 325 in the host server 300 may query the application server / provider 310 with the request and monitor the change in the response. When a change or a new response is detected (eg, by a new data detector 347), the proxy server 325 notifies the mobile device 350 so that the local proxy on the device 350 is in its local cache. One may decide to invalidate the associated cache entry stored as any response (eg, mark it as out-dated). Alternatively, the data invalidator module 368 may automatically instruct the local proxy of the device 350 to invalidate specific cached data based on the response received from the application server / provider 310. Cached data is marked invalid and can be replaced or deleted when new content is received from the content server 310.

Data changes are detected by the detector 347 in one or more ways. For example, after a change, server / provider 310 may notify host server 300. Changes can also be detected at the host server 300 in response to a direct poll of the source server / provider 310. In some cases, in addition to this, proxy server 325 may pre-load a local cache on device 350 with new / updated data. This may be done when the host server 300 detects that the radio on the mobile device is already in use, or when the server 300 has additional content / data to be sent to the device 350.

One or more of the above mechanisms may be implemented simultaneously, or may be adjusted / set according to an application (eg, different policies for different servers / providers 310). In some cases, for certain types of events (eg, events that meet priority threshold levels), the source provider / server 310 may notify the host 300. In addition, regardless of event priority, provider / server 310 may be configured to notify host 300 at specific time intervals.

In one embodiment, the proxy server 325 of the host 300 may monitor / track the received response to the data request from the content source to find the changed result before returning the result to the mobile device. This monitoring may be appropriate when the data request to the content source yields the same result to be returned to the mobile device, so that if there is no new change for a particular request, the network / power consumption is used. Is prevented. The proxy server 325 when the local proxy of the device 350 instructs the proxy server 325 to perform such monitoring or receives a certain number of identical responses (eg, multiple identical responses within a certain period of time) for a particular request. ) Can automatically initiate this process.

In one embodiment, server 300 may identify or detect user activity on a device separate from mobile device 350 via activity / behavior recognition module 366. For example, module 366 may detect that a user's message inbox (eg, email or other type of inbox) is being accessed. This may indicate that the user is interacting with his or her application using a device other than the mobile device 350 and does not require frequent updates.

In such a case, the server 300 can thus reduce the frequency with which new or updated content is sent to the mobile device 350, and can delete all communication as long as it is detected that the user is accessing using another device. This frequency reduction may be application specific (e.g., specific to the application the user is interacting with with another device) or may be an overall frequency reduction for the mobile device 350 (e.g., when the user Because it is detected to interact with one server or one application, the user can use it when accessing another service).

In one embodiment, to conserve power or battery consumption at device 350, host server 300 may poll the content source 310 on behalf of device 350. For example, a particular application on mobile device 35 may poll its own server 310 in a predictable iterative manner. This repetition or another type of application behavior may be tracked by activity / behavior module 366 in proxy controller 365. The host server 300 may thus poll the content source 310 for an application on the mobile device 350, which in other cases may be wireless (eg, a cellular connection) by the device 350 in other cases. Would have been done through The host server connects to the source 310 to find new or changed data by establishing an HTTP connection using the HTTP access engine 345 or by connecting to the source 310 via a cellular network using the radio controller 396. You can poll. When new or changed data is detected, the new data detector 347 may notify the device 350 that such data is available, and / or provide the device 350 with new / changed data.

In one embodiment, connection manager 395 determines that mobile device 350 is not available (eg, the radio is turned off) and uses SMS (eg, via the SMSC shown in the example of FIG. 1C). The content may be transmitted to the device 350. SMS is used to send invalidation messages, or batches of invalidation messages, or even content (if the content is small enough to fit only a few SMS messages (usually one or two SMS messages)). This eliminates the need to access the radio channel to transmit overhead information. The host server 300 may use the SMS for specific transactions or responses that have a priority level close to a threshold or otherwise meet the criteria. The server 300 may maintain or awaken the IP connection using SMS as an out-of-band trigger as an alternative to maintaining an always-on IP connection. .

In one embodiment, the connection manager 395 (eg, heartbeat manager 398) in the proxy server 325 generates and / or sends a heartbeat message on behalf of the connected device 350, thereby providing the device. A backend connection with a provider 310 for an application running at 350 may be maintained.

For example, in a distributed proxy system, a local cache on device 350 may be sent over cellular or other networks where any or all heartbeat messages needed to maintain the TCP / IP connection required for the application. And instead rely on proxy server 325 on host server 300 to send a heartbeat message to maintain a connection with a backend (e.g., application server / provider 110 in the example of FIG. 1A). Create and / or transmit. The proxy server may generate a keep-alive (heartbeat) message, independent of the operation of the local proxy on the mobile device.

Repositories 312, 314 and / or 316 may be created by software, descriptive data, images, system information drivers, and / or other components of host server 300 and / or other servers. Any other data item that is used may be further stored. Repositories can be managed by a database management system (DBMS), for example, the database management system can be (but not limited to) Oracle, DB2, Microsoft Access, Microsoft SQL Server, PostgreSQL, MySQL, FileMaker, and the like.

Repositories can be implemented through object-oriented techniques and / or text files, distributed database management systems, object-oriented database management systems (OODBMS) (e.g., ConceptBase, FastDB main memory database management systems, JDOInstruments, ObjectDB, etc.), objects It can be managed by an associated database management system (ORDBMS) (eg Informix, OpenLink Virtuoso, VMDS, etc.), file system, and / or any other conventional, known database management package.

FIG. 3B illustrates additional examples of components within caching policy manager 355 in the cache system shown in FIG. 3A that may cache for application (eg, mobile application) behavior and / or network conditions and adjust the caching strategy. A block diagram is shown.

In one embodiment, caching policy manager 355 is content source monitoring engine 357 with metadata generator 303, cache look-up engine 305, application protocol module 356, poll schedule manager 358. ), Response analyzer 361, and / or updated or new content detector 359. In one embodiment, the poll schedule manager 358 further includes a host timing simulator 358a, a long pole request detector / manager 358b, a schedule update engine 358c, and / or a time adjustment engine 358d. . Metadata generator 303 and / or cache look-up engine 305 may connect to cache 335 (or server cache) to modify or add cache entries or queries of cache entries.

In one embodiment, a proxy server (eg, example proxy server 125 or 325 of FIGS. 1B-1C and 3A) may monitor content sources to find new or changed data via monitoring engine 357. have. As shown, the proxy server is an entity outside the mobile device 250 of FIGS. 2A-B. The content source (eg, application server / content provider 110 of FIG. 1B) is cached locally on a mobile device (eg, mobile device 150 or 250) to a proxy server (eg, by a local proxy). It may be known to have content. For example, the content source may be monitored by the monitoring engine 357 at a frequency based on the polling frequency of the content source at the mobile device. The poll schedule can be generated, for example, by a local proxy and sent to a proxy server. By poll schedule manager 358, poll frequency may be tracked and / or managed.

For example, a proxy server. On behalf of the mobile device, it can poll to a host (eg, content provider / application server) and simulate the polling behavior of the client to the host via the host timing simulator 358a. The polling behavior (eg, by the long pole request detector / manager 358b) may be simulated to include the characteristics of the long pole request-response sequence experienced in the persistent connection with the host. Once the polling interval / behavior is set, the local proxy 275 on the device side and / or the proxy server 325 on the server side can be represented by an application and application server / content host behavior match or by this prediction pattern. Can be verified. In general, the local proxy and / or proxy server may detect deviations and, when appropriate, re-evaluate and calculate, determine, or estimate another polling interval.

In one embodiment, the caching policy manager 355 on the server side of the distributed proxy, along with the proxy server 275 on the mobile device, or independently of the proxy server 275, may identify or detect long poll requests. Can be. For example, the caching policy manager 355 may request a long poll request, a possible long poll request (e.g., a request for a persistent connection with a host that the client uses to communicate (e.g., a long-lived HTTP request, a persistent connection). In the request-response sequence for the application request to identify or detect COMET style push, request for HTTP streaming, etc.), it may be compared with the response delay interval time to determine the threshold to be used.

For example, the threshold may be determined by the proxy 325 using a response delay interval time for a request generated by a client / application of mobile devices capable of being serviced by a plurality of different cellular or wireless networks. Because the proxy 325 residing on the host 300 can communicate with a plurality of mobile devices over a plurality of networks, the caching policy manager 355 sets thresholds for categorizing and detecting long poles. Application / client information can be accessed at a global level that can be used.

By tracking the response delay time between applications of devices across several different or one same network, the caching policy manager 355 sets one or more thresholds to be used in comparison to the response delay interval time for long pole detection. Can be. The threshold set by the proxy server 325 may be static or dynamic and may be related to the condition and / or lifetime (relative or absolute expiration time / date).

In addition, the caching policy manager 355 of the proxy 325 may be based, in whole or in part, on the network delay of a particular wireless network, a network serviced by a particular carrier (service provider), or a plurality of wireless networks. The threshold may be further determined. The proxy 325 may also determine a threshold for identification of the long pole request based on the delay of one or more application servers / content providers (eg, 110) through which the application (eg, mobile application) or mobile client request is forwarded. Can be.

The proxy server detects new or changed data in the monitored content source and sends a message informing the mobile device of this change, thereby allowing the mobile neglect (or local proxy of the mobile device) to take the appropriate action (e.g., cache element in the local cache). To invalidate). In some cases, when a proxy server (eg, caching policy manager 355) detects new or changed data, the proxy server stores the new or changed data in its cache (eg, server cache 135 or 335 in FIGS. 1C and 3A). Can be stored in In some cases, new or updated data stored in the server cache 335 may be used to satisfy a content request at the mobile device, for example, a proxy server notifies the mobile device of new or changed content, and local Cached content can be used after it is invalidated.

The metadata generator 303 may generate metadata for the cached response to the request at the mobile device 250, similar to the metadata generator 203 shown in the example of FIG. 2B. Metadata generator 303 may generate metadata for cache entries stored in server cache 335. Likewise, cache look-up engine 305 may include the same or similar functionality as described for the example cache look-up engine 205 of FIG. 2B.

The response analyzer 361 performs some or all of the functions associated with analyzing the response received for the request generated by the mobile device 250 in the same or similar manner as the response analyzer 246d of the local proxy shown in FIG. 2B. can do. Since the proxy server 325 can receive a response from the application server / content source 310 delivered to the mobile device 250, the proxy server 325 (eg, the response analyzer 361) is caching. To determine that possible, a response analysis step similar to that described for the local proxy's response analyzer may be performed. In addition to or in place of the analysis that may be performed at the local proxy 275 on the mobile device 250, the response may be analyzed.

In addition, the schedule update engine 358c polls a particular application server / content host based on a change in the application request interval of the application on the mobile device 250, as described for the schedule update engine in the local proxy 275. You can update the interval. The time coordination engine 358d establishes an initial time point, at which time the poll of the application server / content host before serving the fresh content as described for the schedule update engine in the local proxy 275. This prevents you from serving out of date content once again. Both schedule updating and time adjustment algorithms may be performed with, or in place of, a similar process at the local proxy 275 on the mobile device 250.

FIG. 3C illustrates the components of the caching policy manager 355 in the proxy server 375 on the server side of the distributed proxy system shown in the example of FIG. 3A capable of managing and detecting the cache bite mechanism and monitoring the content source. A block diagram showing another example is shown.

In one embodiment, caching policy manager 355 may cache cache source manager 352, content source monitoring engine 357 with poll schedule manager 358, and / or update or update a new content detector 359. It may further include. The cache bitt source manager 352 may further include an identifier modifier module 353 and / or an identifier pattern tracking module 354.

In one embodiment, a proxy server (eg, example proxy server 125 or 325 of FIGS. 1B-1C and 3A) may monitor content sources to find new or changed data via monitoring engine 357. The content source (eg, the application server / content provider 110 or 310 of FIGS. 1B-1C or 3A) may be directed to a proxy device (eg, by a local proxy) to a mobile device (eg, mobile device 150 or 250). The content source 310 may be monitored by the monitoring engine 357 at a frequency based on, for example, the polling frequency of the content source at the mobile device. For example, the polling schedule can be generated by the local proxy and sent to the proxy server 325. The polling scheduler 358 can track and / or manage the polling frequency.

In one embodiment, proxy server 325 uses the normalized or modified identifier when polling to content source 310 to detect new or changed data (response). Also, the normalized or modified identifier may be used by the proxy server 325 when storing the response in the server cache 335. In general, a normalized or modified identifier may be used when a cache defeat mechanism is used for cacheable content. The cache default mechanism may have a type of changing parameter in the identifier (eg, a URI or URL), a changing time / date parameter, a randomly changing parameter, or some other type of parameter.

For subsequent association with subsequent identification of the request and associated response, the normalized or modified identifier may be used to remove, or otherwise replace, a parameter that changes, and poll the content source. In one embodiment, the cache default source manager 352 of the caching policy manager 355 on the proxy server 325 (server side component of the distributed proxy system) (eg, identifier modifier module 353). The modified identifier is created. The modified identifier may use a substitute parameter, which is static for a period of time, in place of the changing parameter used to decode the cache.

Optionally, Cache Depth Source Manager 352 may track, store, or store various modifications of the identifier or identifiers that address the content for one or more content sources (eg, application server / content host 110 or 310), And by monitoring, whether the modified identifier and / or the normalized identifier used by the proxy server 325 to poll to the content source behave as expected or intended (e.g., not intactly modified in the same response, or otherwise). Identifier pattern tracking module 354 to continually verify the response that is still associated with the unidentified identifier).

If the pattern tracking module 354 detects a revision or normalization of an identifier that results in an error or unexpected behavior (eg, an unexpected response is sent) at the content source, the tracking module 354 logs the revision. Can be written to, and used to command the Cache Depth Source Manager 352 to generate another revision / normalized version, or to be used when polling a local proxy (e.g., local proxy 275) as a content source. You may be notified to generate other revisions / normalizations. In conjunction with or in place of this, a particular mobile application / client on the mobile device (eg, mobile device 250) until a direct response is provided to the mobile device and / or a modified version of the operative identifier is generated. The request from is temporarily sent over the network to the content source.

In one embodiment, when new or changed data is detected for a response already stored in the local cache (eg, cache 285) of the mobile device (eg, mobile device 250), the response is returned to the server in the server cache. It is stored as a cache element. Thus, the mobile device or local proxy 275 connects to the proxy server 325 to respond to a request that is already cached locally in the local cache 285 (currently invalid, out-dated, or In other ways, new or changed data can be retrieved for those that are determined to be irrelevant.

The proxy server 325 may detect new or changed data at the monitored application server / content host 310 and send a message to the mobile device notifying the change of the mobile device (or local of the mobile device). The proxy may take appropriate action (eg, invalidate cache elements in the local cache). In some cases, a proxy server (eg, caching policy manager 355, upon detecting new or changed data, stores the new or changed data in its own cache (eg, server cache 135 or 335 of FIGS. 1C and 3A). In some cases, updated / new data stored in the server cache may be used to satisfy content requests on the mobile device, for example, a proxy server notifies the mobile device of new or changed content. After the local cached content is invalidated, it can be used.

3D is a block diagram illustrating an example of additional components in the proxy server 325 shown in the example of FIG. 3A that may further perform mobile traffic categorization and policy implementation based on application behavior and / or traffic priority. Shows.

In one embodiment of proxy server 325, traffic shaping engine 375 is further connected to traffic analyzer 336 such that one or more mobile devices (eg, mobile device 250 of FIGS. 2A-2D) or application server Mobile traffic can be categorized for definition and implementation of policies for mobile traffic and transactions delivered to / content hosts (110 in FIGS. 1B-1C). In general, as shown in the example of FIGS. 1B-1C, proxy server 325 is located remotely of the mobile device and remotely of the host server. Proxy server 325 or host server 300 may monitor traffic for a plurality of mobile devices, categorize traffic and design traffic policies for different mobile devices.

In addition, the proxy server 325 or the host server 300 is operated by a plurality of carriers or network operators, and for various categories, the carrier specificity related to the categorization of traffic and the implementation of the traffic policy. You can implement the policy. For example, traffic analyzer 336 of proxy server 325 or host server 300 may be configured by prioritization engine 341a, time criticality detection engine 341b, application state categorizer 341c, and / or application. Traffic categorizer 341d.

Each of these engines or modules can track different criteria of priority, time importance, background / foreground, or interactive / maintenance, depending on different wireless carriers. Different criteria may exist for different mobile device types (eg, device model, manufacturer, operating system, etc.). In some cases, a user of a mobile device may adjust settings or criteria related to traffic categories, and proxy server 325 may track and implement settings that are adjusted / set by these users.

In one embodiment, the traffic analyzer 336 is configured to include one or more mobile devices (eg, mobile devices (eg, mobile device (e.g. 150 or 250) may detect, determine, identify, or infer the activity state of an application on the application. Foreground application traffic vs. traffic Since background application traffic may be handled differently, the activity state may be determined based on whether an application on one or more of the mobile devices is in the foreground or background state (eg, via application state categorizer 341c). have.

Alternatively or in conjunction with this, the activity status of the application may be determined and communicated to the proxy server 325 by a wirelessly connected mobile device (eg, via an application behavior detector in a local proxy). For example, based on the backlight state in a mobile device (eg by a backlight detector) or another software agent or hardware sensor on the mobile device (eg, resistive sensor, capacitive sensor, ambient light sensor, motion sensor). Activity state can be determined, detected, identified, or inferred with a heuristic certainty. In general, when the backlight is turned on, traffic may be treated or determined to be active or generated from an application in the foreground, or the traffic may be interactive. In addition, when the backlight is turned on, the traffic may be treated or determined as traffic from user interaction or user activity, or may be traffic that includes data the user is expecting within a certain time.

From calculating, determining, evaluating, inferring, and identifying user activity at mobile device 250 (eg, via user activity module 215), an activity state can be determined and communicated to proxy server 325. have. In one embodiment, the activity state is determined based on whether the traffic is interactive or maintenance traffic. Interactive traffic may include responses from transactions and requests generated directly from interactions with user activity / applications, and may include content or data that a user waits or expects to receive. Maintenance traffic can be used to support the functionality of an application that is not directly detected by the user. Maintenance traffic may also include actions or transactions that may occur in response to user actions but that the user does not actively wait for or wait for a response.

In general, traffic from which time criticality detection engine 341b is transmitted from mobile device 250, or host server 300 or proxy server 325 or application server (e.g., app server / content source 110). Determine, identify, and infer the time sensitivity of the data contained in the traffic transmitted from)) to the mobile device. For example, time sensitive data may include status updates, stock information updates, IM presence information, e-mail messages or other messages, actions generated from mobile game applications, web page requests, location updates, and the like. .

Due to the nature of the content or request, data that is not time-sensitive or time-sensitive may include a message deletion request, a read mark, or an edited action, an application-specific action (eg, a friend add or friend delete request), a particular type of message. Or other information whose attributes do not change frequently. In some cases, when the data is not time critical, the timing for causing traffic to be sent to the mobile device is based on when there is additional data that needs to be sent to the same mobile device. For example, traffic shaping engine 375 may align traffic with one or more subsequent transactions, such as by using a sorting module 378 and / or batch module 377 to power up a mobile device radio once. It can be sent together in a power-on event. The sort module 378 can also sort polling requests forwarded to the same host server in close proximity, since these requests are likely to be answered with the same data.

In general, whether new or changed data is sent from the host server to the mobile device is determined whether an application on the mobile device with which the new or changed data is associated is running in the foreground (eg, by application state categorizer 341c), or It can be determined based on the priority or time importance of new or changed data. Depending on whether the application is in the foreground on the mobile device, or when the application is in the foreground and interacts with the user on the mobile device, and / or the user is waiting for a response to be provided for new or changed data, The proxy server 325 may send the new or changed data to the mobile device. Proxy server 325 (or traffic shaping engine 375) may send new or changed data with high priority or time importance.

Similarly, when the application is in the background at the mobile device, the proxy server 325 (or traffic shaping engine 375) can suppress the transmission of new or changed data. The proxy server 325 may also suppress transmission of new or changed data if the user is not waiting for a response provided to the new or changed data, which suppression is connected to the host server and wirelessly connected to the mobile device. Can be done by a proxy server.

In general, if the data has low priority or time importance, including new or changed data, until a time period passes, or (e.g., sort module 378 and / or batch module 377). The proxy server may wait to send data until there is additional data to be sent).

4A shows a block diagram illustrating another example of client-side components of a distributed proxy and cache system, and further includes an atomic process based traffic optimizer 401. 4B is a block diagram illustrating additional components of the example atomic process based traffic optimizer 401 of FIG. 4A.

The atomic process based traffic optimizer 401 may include a traffic snooping module 402 having a pattern detector 403, a timing / periodic detector 404, and / or a destination address parameter extraction engine 405, Inference engine 411 with atomic process generator 412 and / or application profile generator / modifier 439.

Atomic process based traffic optimizer 501 intercepts mobile application traffic (eg, by traffic snooping module 402) initiated from a device, such as mobile device 250, and is detected via an atomic process (eg, traffic snooping). Various parameters may be identified that may be used to generate or generate the example atomic process 190 of FIG. 1A by the atomic process generator 412 using any pattern. The atomic process 190 is a set of requests having some degree of periodicity with respect to each other based on the detected pattern, sent from one mobile application (eg, the object 108 of FIG. 1C) or a plurality of applications, or the It may include an indicator corresponding to a set of requests and may be replicated / simulated.

These correlated requests may occur at different times, but at possible predictable times (eg, t1 = 1 minute, t2 = 2 minutes, t3 = 6 minutes, etc.) and the mobile application (eg, 108 of FIG. 1A). This may occur automatically based on the maintenance process or application process of the application, or in response to user interaction. In general, requests initiated by an application, system, device, or OS may be predictable and identified and distributed to servers to be candidates for mitigating the load on mobile devices and cellular networks.

For example, in some cases, a server / provider may be created for all or some of the addressable objects / requests (e.g., some or all of the objects 101, 103, 105 in the example of FIG. 1A). The request has a repeatable timing or periodicity pattern that can be detected (eg, by the timing / periodic detector 404). A requesting pattern can be a sequence (the order in which each entity is addressed by a request), periodicity (time interval, or relative timing, such as time interval before or after another traffic request), timing (eg, request or Time or day of the week when the sequence of requests occurs, or a combination thereof. Of course, other patterns are possible (and can be detected).

In addition, in response to a specific trigger or event occurring at an application, device, OS, or system level, it may be detected that a particular pattern occurs (eg, by the pattern detector 403 of the snooping module 402). Any such detected pattern can be tracked and used to create an atomic process that includes a plurality of requests included in the detected pattern. To share a request from the mobile device 250 to a host server (eg, host server 100 or 200 in the example of FIGS. 1 and 2), thereby mitigating mobile network traffic and freeing up network resources. An atomic process (eg, the atomic process 190 shown in the example of FIG. 1A) may be used.

After a request to the entity 101 shown in the example of FIG. 1A, when it is detected that another request to another entity follows a predicted time frame, or after a request to the entity 101, respectively. An atomic process can be generated when two additional requests (eg, to entities 103 and 105 of FIG. 1A) are followed at a predictable time interval. Traffic patterns may be detected by a local proxy (eg, optimizer 401), and a final atomic process may be generated by atomic process-based traffic optimizer 401.

For example, a predictable time interval can be detected by the pattern detector 403 in the traffic snooping module 402. For example, in one simple case, the snooping module 402 may detect that a request to the entity 101 occurs frequently or always at 6:00 am PST. Thus, an atomic process may be created (eg, by atomic process generator 412) to include a request to entity 101 at 6:00 am PST. This request can then be shared with the server, allowing the server to perform a request that occurs at 6:00 am daily, instead of being initiated from the mobile device.

In another example, each time a request to the entity 103 occurs, the snooping module 402 may detect that a request to the entity 105 occurs after about 10 minutes. Thus, the atomic process generator 712 can create an atomic process that includes a request to the entity 103 and a request to the entity 105 10 minutes later, and allocates this process for the server to handle. Using the generated atomic process, whenever a request to the entity 103 occurs, the system can infer that, based on the designated atomic process, the request to the entity 105 is likely to occur after about 10 minutes. The server uses this knowledge to duplicate the mobile application activity by making a request that normally needs to be initiated from the mobile device and perform the request on behalf of the mobile device.

One embodiment of an atomic process based traffic optimizer 401 can anticipate the next request based on the detected request using various atomic processes defined across applications and / or across devices. Interfering engine 411. For example, if the inference engine 411 detects a request that is part of a specified atomic process, the interference engine 411 may anticipate one or more requests that are likely to follow, and thus on behalf of the mobile device. Have the server execute the request.

In general, atomic process based traffic optimizer 401 may be a mobile device (eg, mobile device 150 (“local proxy”) in FIG. 1A or entity 250 (“local proxy”) in FIG. 4A), It can be on any device on which the requesting application 108 is located, which can make repeated requests. On a local device or mobile phone, atomic process based traffic optimizer 401 may intercept requests locally and identify requests that may be correlated (eg, based on destination address, etc.). The atomic process based traffic optimizer 401 also communicates with a remote host (eg, host 100 or 200) to compare any destination address with a list of known destinations, thereby correlating with other detected requests. Can be evaluated As previously described locally by the atomic process based traffic optimizer 401, the atomic process is generated locally (eg, by the atomic process generator 412) and sent to the host (eg, host 100 or 200). Can be used to poll to an app server / content provider.

In this case, the inference engine 411 is wholly or partially located on the host server (host server 300 of FIG. 5A), thereby basing the detected request according to the atomic process for the particular mobile application and mobile device 250. Can infer the next request from a particular activity. In general, atomic processes can be formed for specific applications and specific mobile devices. Multiple atomic processes can be created for a particular application, and a particular mobile device can have several atomic processes designated across multiple applications. The atomic process generator 412 may also update the definition of the generated atomic process based on observations of application behavior and / or responses received from the application server in response to requests shared with the server.

In one embodiment, for example, by profile generator / modifier 439, an application profile may be created or modified according to one or more generated atomic processes. The application profile may be created to be specific to the user or device. In addition, a general purpose application profile may be created that is not user or device specific. The application profile may include one or more atomic processes designated for an application that may be used across multiple users and / or multiple devices. Application profiles may also include device or user specific components, which include atomic processes specific to the user or device or both. Application profile entries, specifically, in real time or near real-time operating state or network state or application state, or service provider details, user requests, device states, platform details / demands, resource constraints, or any combination thereof Dynamically on the basis, a designated atomic process can be updated, revised, deleted, recreated, marked as not applicable, temporarily deactivated, or otherwise edited / adjusted.

The atomic process based traffic optimizer 401 itself is distributed between the device 250 and the host server (e.g., host 100, 200 or 300) so that specific components and / or associated functions are located locally, Some may be remotely located in a manner that is mutually exclusive or not mutually exclusive. For example, traffic snooping functionality may be located on local device 250 or host server 300 or both. Both may be used simultaneously or selectively based on certain criteria.

In general, atomic process based traffic optimizer 401 may have the same, or different but overlapping, or different and nonoverlapping functions and features (eg, traffic snooping module 402, pattern detector 403, timing / periodicity). Detector 404, destination address parameter extraction engine 405, inference engine 411, atomic process generator 412, and / or those described for components such as application profile generator / modifier 439). It can be located on both the local device and the host server. 5A is a block diagram illustrating one example of server-side components in a distributed proxy and cache system, and further includes an atomic process based traffic optimizer 501. FIG. 5B shows a block diagram illustrating additional components of the atomic process based traffic optimizer 501 shown in the example of FIG. 5A.

In one embodiment, atomic process based traffic optimizer 501 is located, in whole or in part, on a remote host (eg, host 100 or 200). For example, a remote host can intercept a request made to an app server / content provider and detect any correlation. Using the generated atomic process, the host server itself may perform inference about the request to be made based on one detected request via the generated atomic process (eg, to complete the activity (eg, pace One or more steps (such as satisfying a status update in a book, sending and receiving instant messages, web browsing events, etc.)). When located on a host server, atomic process based traffic optimizer 401 can track and store, and / or later update, atomic processes, on a per application and / or per device basis.

6A shows another flow diagram illustrating an example process for distributed content caching between a mobile device and a proxy server and distributed management of content caching.

As shown in the example distributed system interaction diagram of FIG. 4, the technique of the present invention is based on the client side / mobile device side (eg, mobile device 450 in the example of FIG. 4) (eg, in the example of FIG. 4). Distributed caching with various aspects of caching tasks split between mobile device 450 and server side (e.g., server side 470 including host server 485 and / or optional caching proxy 475). It is a model.

In general, device side responsibility may include determining whether a response to a particular request can be cached (and / or should be cached). The device side of the proxy may make this determination based on information collected from both the request and the response / during the request and the response (e.g., timing characteristics, detected patterns, indicators detected using heuristics, indicators of predictability or repeatability). Can be cached (eg, stored in a local cache on the mobile device). The device side may also notify the server side of the distributed cache system of this local cache event and may notify the monitoring of the content source (eg, the application server / content provider 110 of FIGS. 1B-1C).

The device side may instruct the server side of the distributed proxy to validate the cache response periodically (eg, by polling, or by sending a polling request to the content source). The device side may further determine whether a response to a particular cache request should be returned from the local cache (eg, whether a cache hit is detected). Decisions can be made by the device side (eg, a local proxy on the device) using the information collected from (or during the request and / or response) received from the request and / or content source.

In general, server-side duties may include verifying a cached response for relevance (eg, determining whether the cached response is still valid or related to a request associated with it). The server side may send an invalidation request to notify the mobile device when the cached response to the device side is no longer valid or no longer relevant (eg, the server invalidates a particular content source). The device side can then remove the response from the local cache.

The diagram of FIG. 6A illustrates a caching logic process performed for each detected or intercepted request (eg, HTTP request) detected at a mobile device (eg, client side of a distributed proxy). In step 602, the client side of the proxy (eg, the local proxy 275 shown in FIGS. 2A-B, or the mobile device 450 of FIG. 4) is either an application (eg, a mobile application) or a mobile client. Receive the request. In step 604, the URL is normalized and in step 606 the client side checks to determine whether the request is cacheable. If it is determined in step 612 that the request is not cacheable, then in step 608 the request is sent to the source (application server / content provider), similar to the request-response sequence without being intercepted by the client-side proxy, In step 610 the response is received and forwarded to the requesting application in step 622.

If it is determined that the request is cacheable, then at step 612 the client side may look up the cache to determine whether a cache entry exists for the current request. If it is determined that a cache entry exists for the current request, the client side may determine whether the entry is valid at step 624, and if it is determined that the entry is valid, the client side checks the request at step 615 to determine the validator. (Eg, modified headers or entity tags). For example, the concept of validation is missing from section 13.3 of RFC 2616, which describes possible types of headers (e.g., eTAG, Modified_Since, must_revlaidate, pragma no_cache), which would then be passed to the requesting application in step 622. A response to verify is formed (632). If the request does not include an inspector as determined in step 615, then in step 630 a response is formed from the local cache and forwarded to the requesting application in step 622. This verification step can generally be used for content that would otherwise be considered un-cacheable.

Instead, at step 624, if a cache entry is found but is no longer valid or determined to be invalid, the client side of the proxy sends a request to the content source (application server / content host) (616), Receive a response directly from the source (618). Similarly, if a cache entry was not found during a look up at step 612, then a request is also sent at step 616. If a response is received, at step 626, the client side may check the response to determine whether it is cacheable. If cacheable, the response is cached at step 620. The client then sends another poll at step 614 and forwards the application requesting a response at step 622.

6B illustrates an application from a mobile device 450 in a wireless network, by a distributed proxy system 460, in such a way that network and battery resources are conserved through the use of content caching and monitoring performed by the distributed proxy system 460. A diagram illustrating how data requests to the server / content provider 495 can be coordinated.

Without the distributed proxy system 460, when satisfying an application or client request on the mobile device 450, the mobile device 450 or a software widget running on the device 450 requests a direct data request to the application server 495 ( 452 (eg, HTTP, GET, POST, or other request) and receive a response 404 directly from the server / provider 495. Once the data is updated, the widget 455 on the mobile device 450 is refreshed to reflect the update, waiting for a short period of time, and initiating another data request to the server / provider 495.

In one embodiment, the requesting client or software widget 455 on the device 450 may use the distributed proxy system 460 when handling data requests made to the server / provider 495. In general, distributed proxy system 460 is local proxy 465 (referred to as a client-side component of system 460 and can be located on mobile device 450), caching proxy 475 (system 460 May be located on the host server 485, or may be located entirely or partially outside the host server 485), and the host server 485. have. The local proxy 465 can be connected to the caching proxy 475 and the host server 485 via any network or combination of networks.

When distributed proxy system 460 is used for a data / application request, widget 455 may perform data request 456 via local proxy 465. The local proxy 465 can intercept a request made by the device application and identify the connection type of the request (eg, an HTTP get request, or some other type of request). The local proxy 465 may then query the local cache for any previous information about the request (eg, to determine whether a locally stored response is available and / or still valid). If a locally stored response is not available, or if an invalid response is stored, the local proxy 465 may update or store information about the request, when the request was made, and any additional data in the local cache. The information can be updated to be used, perhaps the next time it satisfies the request.

Local proxy 465 may then send the request to host server 485, which may perform request 456 and return the result in response 458. The local proxy 465 may store the result and, in addition, information about the result, and return to the widget 455 requesting the result.

In one embodiment, if the same request occurs multiple times (within a certain time period) and the request often yields the same result, the local proxy 465 sends it to the server 485 and sends the result to the local proxy 465. Or, before returning to the request widget 455, the notification 460 may be notified that the request should be monitored (eg, steps 462 and 464) to find the resulting change.

In one embodiment, if the request is marked for monitoring, the local proxy 465 may store the result in a local cache. Now, when a data request 466 with a local response available is made by the widget 455 and intercepted at the local proxy 465, the local proxy 465 is local, without having to establish connection communication over the wireless network. The response 468 can be returned from the cache.

In addition, the server proxy may perform a request 470 marked as monitoring to determine whether the response 472 for the particular request has changed. In general, the host server 485 may perform such monitoring regardless of the operation of the widget 455 or the local proxy 465. Each time an unexpected response 472 is received for a request, server 485 notifies local proxy 465 that the response has changed (eg, invalidates the notification in step 474) and stores locally on the client. The response must be deleted or replaced with a new response.

In this case, the next data request 476 by the widget 455 at the device 450 derives the data returned from the host server 485 (eg, via the caching proxy 475), and step 478. At, the request from the caching proxy 475 is satisfied. Thus, by using the distributed proxy system 460, a wireless (cellular) network is intelligently used when the content / data for the widget or software application 455 on the mobile device 450 has actually changed. Thus, traffic that needs to be checked to find changes in application data is not performed over the wireless (cellular) network. This reduces the amount of network traffic generated, shortens the overall time and number of times the radio module is turned on on the mobile device 450, thus reducing battery consumption and further freeing network bandwidth.

FIG. 7 shows a table 700 illustrating examples of different traffic or application category types that may be used to implement network access and content delivery policies. For example, the traffic / application category may include interaction or background, regardless of whether the user is waiting for a response, a foreground / background application, and whether the backlight is on or off.

8 illustrates different tables 800 that illustrate examples of different content category types that may be used to implement network access and content delivery policies. For example, the content category type may include content with high or low priority and content of time importance or non-time importance.

9 shows that an application (eg, mobile application) 955 poll having a data request from a mobile device to an application server / content provider 995 over a wireless network can be cached on the local proxy 965 and distributed caching system. An interactive diagram showing how it can be managed by local proxy 965 and host server 985 (with server cache 935 or caching proxy server 975) is shown.

In one example, when the mobile application / widget 955 polls the application server / provider 932, the poll may be intercepted locally on the mobile device by the local proxy 965 (934). The local proxy 965 may detect that cached content is available for the content polled in the request, thus satisfying the intercepted poll 936 without using wireless network bandwidth or another wireless network resource. To do this, you can retrieve the response from the local cache. The mobile application / widget 955 can then receive a response to the poll from the cache entry 938.

In another example, the mobile application widget 955 polls the application server / provider 940. The poll is intercepted by the local proxy 965 (942), detects that cache content is not available in the local cache, and decides to set up to cache the polled source (944). To satisfy the request, the poll is forwarded to the content source (946). Application server / provider 995 receives a poll request from the application and provides a response to satisfy the current request (948). In step 950, the application (eg, mobile application) / widget 955 may receive a response from the application server / provider to satisfy the request.

In addition, to set up content caching, the local proxy 965 can track the polling frequency of the application and set a polling schedule to be sent to the host server (952). The local proxy sends caching settings to the host server (954). The host server 985 may use cache settings, including, for example, an identifier of the application server / provider to be polled and, optionally, a polling schedule (956). The host server 985 may poll the application server / provider 995 to monitor the response to the request 958 on behalf of the mobile device. The application server receives the poll from the host server and responds (960). The host server 985 determines that the same response has been received and polls the application server 995 according to a particular polling schedule 962. The application server / content provider 995 receives the poll and responds accordingly (964). The host server 985 detects the changed or new response and notifies the local proxy 965. The host server 985 may further store modified or new responses in the server cache or caching proxy 968. Local proxy 965 may receive a notification from host server 985 that new or changed data is currently available, and invalidate the affected cache entry (970). The application (eg, mobile application) / widget 955 issues the same request for the same server / content provider 972 and the local proxy determines that no valid cache entry is available, instead, yes For example, a response is retrieved from the server cache 974 via an HTTP connection. The host server 985 receives the request for a new response and sends back the response to the local proxy 965 (976). Thus, the request from the server cache or caching proxy 978 can be satisfied, thereby conserving network resources without the mobile device having to use its radio or consume mobile network bandwidth.

Or, in step 982, when the application (eg, mobile application) generates the same request in step 980, the local proxy 965 determines that no valid cache entry is available. Forward the poll to the application server / provider over the mobile network. In step 984 the application server / provider 995 receives a poll over the mobile network and sends a response to the mobile device. Thus, in step 986 the request from the server / provider using the mobile network is satisfied.

10 illustrates an application server / content provider in which an application 1055 utilizes a cache dip mechanism in a content identifier (eg, an identifier intended to dictate caching) over a wireless network and is detected and cached locally over the wireless network. A method of polling for content from 1095 is shown.

In one example, when an application (eg, mobile application) / widget 1055 polls an application server / provider at step 1032, the poll is local on the mobile device by local proxy 1065 at step 1034. Can be intercepted. In step 1034, the local proxy 1065 on the mobile device (with any confidence and heuristic) may also determine, by the server provider, that the cache defeat means may or may be used.

The local proxy 1065 may detect that cached content is available for content polled in the request, thus fetching a response from the local cache and intercepting, without the need to use wireless network bandwidth or another wireless network resource. The pole 1036 may be satisfied. In step 1038 the application (eg, mobile application) / widget 1055 may receive a response to a poll from a cache entry (eg, a cache entry stored locally on the mobile device).

In another example, at step 1040 the application (eg, mobile application) widget 1055 polls the application server / provider 1095. At step 1042, the poll is intercepted by local proxy 1065, which determines that a cache defeat mechanism is used by server / provider 1095. The local proxy 1065 also detects that cached content for this request is not available in the local cache, and determines in step 1044 to set up the polled content source for caching. Then, at step 1046, the local proxy 1065 may extract a pattern (eg, format or syntax) of the identifier of the request, track the polling frequency of the application, and set a polling schedule of the host server 1085. have.

At step 1048, the poll request is forwarded to the content provider 1095 to satisfy the request. In step 1050 the application server / provider 1095 may receive a poll request from the application and provide a response to satisfy the current request. In step 1052, the application (eg, mobile application) / widget 1055 may satisfy the request by receiving a response from the application server / provider 1095.

Along with this, in step 1054, in order to set up content caching, the local proxy 1065 caches the response in association with the response received for later identification and retrieval, and identifies the fully qualified version of the identifier ( Or hash value of the normalized identifier. In step 1056 the local proxy sends the cache settings to the host server 1085. For example, the cache setting may include an identifier and / or a fully qualified version of the identifier. In some cases, a modified identifier that is different from the normalized identifier is sent to the host server 1085.

In step 1058, the host server 1085 may use a cache setting that includes, for example, an identifier of the application server / provider to be polled and, optionally, a polling schedule. In step 1060, the host server 1085 may poll the application server / provider 1095 to monitor the response to the request on behalf of the mobile device. In step 1062, the application server 1095 receives and responds to a poll from the host server 1085. In step 1064 the host server 1085 determines that the same response has been received and polls the application server 1095 according to a particular polling schedule, for example, and using a normalized or modified identifier. In step 1066 the application server / content provider 1095 receives the poll and responds accordingly.

At this time, in step 1068, the host server 1085 detects the changed or new response and notifies the local proxy 1065. In step 1070 the host server 1085 may further store the changed or new response in the server cache 1035 or caching proxy 1075. At step 1072, local proxy 1065 may receive a notification from host server 1085 that new or changed data is currently available and invalidate the affected cache entry. Then, at step 1074, the application (eg, mobile application) / widget generates the same request for the same server / content provider 1095, and the local proxy 1065 says that no valid cache entry is available. And instead, in step 1076, retrieve the response from the server cache, eg, over an HTTP connection. In step 1078, the host server 1085 receives the request for a new response and sends the response back to the local proxy 1065. Thus, in step 1080, the request from the server cache or caching proxy is satisfied, without the mobile device having to use its radio or consume mobile network bandwidth, thus conserving network resources.

Or, when the application (eg, mobile application) 1055 generates the same request, the local proxy 1065 responds, at step 1082, in response to determining that no valid cache entry is available, step 1082. Forward the poll to the application server provider 1095 over the mobile network. In step 1086 the application server / provider 1095 receives the poll and sends a response to the mobile device over the mobile network. Thus, at step 1088, the request from the server / provider is satisfied using the mobile network 1086.

11 is a flow diagram illustrating an example process for making a request on behalf of a mobile device.

In process 1102, a sequence of requests from the mobile device is detected. The request may be initiated by the user or by the application as a result of satisfying the user request, or used as background data exchange (application update / maintenance, etc.). In process 1104, the reproducible pattern is identified as a sequence of requests from the mobile device. Using some of the example characteristics shown as flow 'A' in the example of FIG. 12, a reproducible pattern can be identified.

In process 1106, the sequence of requests is replicated to a separate entity from the mobile device using the reproducible pattern. Replication may be based on the destination of the request (eg, host address, content source address), content / properties of the request, timing / periodicity of the request, and the like. In process 1108, a sequence of requests is sent by the entity on behalf of the mobile device to conserve resources at the mobile device. In one embodiment, the entity is a proxy server (on the server side of a distributed proxy system) capable of wireless communication with a mobile device. The entity may send a sequence of requests to one or more destinations over any type of wired or wireless connection, including the Internet, any IP or broadband connection, or any other connection, such that the mobile device request is predicted. And allows cellular network resources to be conserved when they can be reproduced.

In addition, reproducible patterns may be detected or identified by a proxy server (eg, a local proxy on the client side of a distributed proxy system) that is remote from or identified by the mobile device. When identified by the mobile device, a reproducible pattern can be passed to the proxy server for replication and / or simulation. In addition, an atomic process is generated from the sequence of events by the local proxy and / or proxy server. In general, an atomic process includes any set of events / requests from a mobile device that are detected to have any pattern, repeatability, or periodicity. Thus, if one request of the atomic process is detected, the system can predict that the remaining requests of the atomic process are likely to occur. This prediction may share the next request or other request of the atomic process with the remote entity to be replicated and / or simulated and sent to the destination.

In one embodiment, the sequence of requests is delivered to different addressed entities of the server of one application on the mobile device. From the destination address (eg, shown in FIG. 1A), although the requests are forwarded to different entities of the application server and have different destination addresses, the system has a single application server / sequence of requests from the same application on the mobile device. You can see that it is delivered to the host. For example, a pattern or shared parameter of the destination address may indicate that the request is forwarded to one server. In one embodiment, this request is generated as an atomic process and can be shared for replication and simulation by another entity, such that the mobile device or mobile application itself does not need to repeatedly send a predictable event over the cellular network. You can do that.

In process 1110, a response to the sequence of requests is passed to the mobile device to satisfy operation in the mobile application, or for background maintenance. The response is sent directly from the source (eg, application or content source) to the mobile device, or sent to the proxy server, which then sends the response to the mobile device.

In general, the sequence of requests may include a request generated as a result of the user's interaction with a mobile application, browser, internet browser, or other widget. The sequence of requests may also include a request that is automatically generated (eg, not used by the user) by the application or widget in the background. In some cases, the sequence of requests may occur at a predictable time interval compared to a triggering event. The triggering event may be a system event, an application event, a device event, and / or a user event or activity. The triggering event may be one request in a sequence of requests. In process 1112, a triggering event is identified that causes the initiation of the sequence of requests.

In process 1114, the occurrence of a triggering event is detected. In process 1116, a sequence of events is simulated in the entity, and in process 1118, no request is intercepted and sent at the mobile device. In addition, because the event may be sent from the entity to its intended destination, the process 1122 is not turned on if the device radio of the mobile device is in the off state.

12 is a flow chart illustrating an example process for identifying or detecting a reproducible pattern in a request from a mobile device.

In process 1202, the parameters in the destination address addressed by the sequence of requests are extracted. In process 1208, the destination address of previous outgoing requests is compared with each other. Or, in process 1210, the destination address of previous outgoing requests is compared with a list of known addresses.

In process 1212, it is determined whether the request originates from the same application and / or whether the request is forwarded to the same server. For example, a destination address that shares different but some identical / similar parameters may indicate that the request originated from the same application, or is forwarded to the same host (even though it may be a different addressable entity of the same host). Can be. If so, in process 1214, a reproducible pattern is identified. In addition, another criterion may be used, for example, through a pattern identified through a pattern extraction or pattern matching technique, one set of requests originated from the same application / widget, or forwarded to the same host / server. It can be judged. The destination address may also be independently compared to a list or table of known addresses for known destinations (means for determining that the request originated from the same application and / or forwarded to the same server).

Likewise, in process 1204, for example, as in process 1206, if a timing pattern is determined in the sequence of requests, or if a periodic pattern is determined in the sequence of requests, a reproducible pattern can be identified. The timing pattern of the sequence of requests can be characterized by an absolute point in time (eg, a point of time 't1', 't2', 't3', etc. at day 'x' or 'x' on a particular day of the month, etc.). The timing pattern may also be characterized as a relative viewpoint or relative to one or more events / activities. For example, a request, or sequence of requests, may be detected to occur after a particular user, system, application, or device event. It can also be detected that a request occurs after another request, with an interval that can be repeated within some acceptable threshold.

The periodicity pattern can be characterized by the time interval between requests of a particular request sequence and / or by the time interval between different request sequences. Different request sequences, which may have periodicity, may be sent by different mobile applications / clients or widgets on the mobile device. The periodicity can be an indicator that one application launches another application automatically or manually by the user, so that one request sequence often indicates that another request sequence will follow. This periodicity can be a reproducible pattern that can be replicated so that the request can be partially or wholly shared with the remote proxy. For example, a user may post an update and picture on Facebook via a Facebook application, and then a series of events may be initiated that post the same picture or update to Twitter. When periodicity can be detected. This pattern may be a detected periodicity that causes a series of events to be simulated in an object located remotely of the mobile device.

13 is a flowchart illustrating an example process for simulating a traffic request from a mobile device.

In process 1302, it is detected that the request is one of a sequence of detected requests as a traffic pattern that can be at least partially repeated. In one example, the request sequence is delivered to different addressable entities identified by different destination addresses at the host server for one application. In another example, the request sequence may be delivered to a plurality of applications, but may include requests with repeatable patterns in other ways, and may be reproduced outside of the mobile device.

In process 1304, it is anticipated that the request will be made by the mobile device prior to the request being sent by the mobile device to the destination. The request may be made based on a user event, application event, device event or system event at the mobile device. Predictions can also be made when an activity is occurring at the mobile device and the request is part of a sequence of known requests, typically made to complete the activity.

In process 1306, the request is simulated based on the traffic pattern of the outgoing request by the application on the mobile device. In process 1308, a request is made to the destination on behalf of the mobile device, in an entity separate from or located outside the mobile device. In process 1310, a response to the request sent by the entity on behalf of the mobile device is sent from the destination to the mobile device.

In process 1312, an application profile for an application is created or updated using the traffic pattern. Application profiles may be created or updated by a mobile device (eg, local proxy) and / or by a remote entity or any other entity that simulates a request.

In one embodiment, an application profile with traffic patterns may be maintained or stored at a remote entity and used to service a plurality of mobile devices. For example, in process 1314, an application profile can be used to simulate traffic requests for other mobile devices with the same application. Application profiles may be stored, created, and maintained for a plurality of applications and used across mobile devices, service areas, and / or network providers.

14 is a flowchart illustrating an example process for sharing a request made by a plurality of mobile applications on a mobile device.

In process 1402, when each set is detected for each of a plurality of applications on the mobile device, a set of traffic patterns of the outgoing request is detected. The traffic pattern may be characterized by the timing of the previous outgoing request and / or the destination address of the previous outgoing request. In process 1404, a request made by a plurality of applications on the mobile device is predicted. In process 1406, on a separate entity from the mobile device, a request is made on behalf of the mobile device to a destination associated with the plurality of applications.

Such traffic patterns identified for a plurality of applications on the mobile may be stored in an entity (eg, a remote proxy server), for example as part of the information included in the application profile. The proxy server can then use this information to manage the sharing of requests from other mobile devices with the same application.

15 is a flowchart illustrating an example process for sharing a request made at a mobile device to a remote entity.

In process 1502, it is detected that the set of requests originating from the mobile device occurs at a predictable time interval. The predictable time interval of the set of requests can be detected by the local proxy on the mobile device. In one embodiment, the predictable time interval is predictable within an acceptable error threshold (e.g., not limited to <0.5%, <1%, <5%, <10%, <20%, etc.). The predictable time interval may be specified as being relative to the triggering event or may be specified as an absolute point in time (eg, a specific time of day, a specific day of the week, a specific date).

In process 1504, it is detected from the identifiable pattern in the set of requests that a set of requests is generated from the mobile application. In process 1506, the information is passed to a remote entity, which can simulate a set of requests. The remote entity may include a proxy server capable of wireless communication with a local proxy on the mobile device.

At process 1508, the next occurrence of the set of requests can be shared from the mobile device and sent by the remote entity. For example, at process 1510, the next occurrence of the set of requests is intercepted and not sent from the mobile device. The remote entity can simulate and send / send the next occurrence of the set of requests on behalf of the mobile application on the mobile device. In process 1512, a response is received at the mobile device for the next occurrence of the set of requests made by the remote entity. In addition, the mobile application receives a response to the next set of requests that are sent by the remote entity on behalf of the mobile application.

The triggering event may include an action for the mobile application and / or a user action or user activity for the mobile application. The operation may also be background maintenance activity of the mobile application. For example, at process 1514, a user action or user activity for the mobile application is detected, and at process 1516 the user action or activity is identified as a triggering event. Thus, when the next occurrence of the triggering event is detected, as in process 1518, the remote entity simulates a set of requests on behalf of the mobile application. The process then continues to flow 1508, where the remote entity is taken over sending the request on behalf of the mobile device.

16 is a schematic diagram illustrating a machine in an exemplary form of a computer system, in which one set of instructions may be executed to cause a machine to perform any one or more of the methods disclosed herein. .

In alternative embodiments, the machine may operate as a standalone device or may be connected (eg, network-connected) to another machine. In network-connected form, the machine may operate as a server or client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

Machines include server computers, client computers, personal computers (PCs), user devices, tablet PCs, laptop computers, set-top boxes (STBs), personal digital assistants (PDAs), cellular phones, iPhones, iPads, Blackberries, processors, and telephones. , Web appliance, network router, switch or bridge, console, hand-held console, (hand-held) game device, music player, any portable, mobile, hand-held device, or a set of actions that specify an action to perform It can be any machine capable of executing instructions (sequentially or otherwise).

In one exemplary embodiment, a machine-readable medium or machine-readable storage medium appears to be one single medium, although the terms "machine-readable medium" and "machine-readable storage medium" refer to one or more sets of instructions. It should be understood to include a single medium or a plurality of media (e.g., a centralized or distributed database and / or caches and servers associated with it). The terms "machine-readable medium" and "machine-readable storage medium" also refer to a set of instructions for causing a machine to perform any one or more of the presently disclosed techniques and innovations and to be executed by a machine. It is to be understood to include any medium that can store, encode, or bear.

In general, routines executed to implement embodiments disclosed herein may be implemented as part of an operating system or a particular application, component, program, object, module, or sequence of instructions referred to as a “computer program”. . A computer program is one or more instructions that, at various points in time in various memories and storage devices of the computer, cause the computer to perform operations for executing elements related to the various aspects herein when read and executed by one or more processing units of the computer. It is common to include a set.

In addition, while the embodiments have been described in the context of fully operational computers and computer systems, those skilled in the art will appreciate that various embodiments may be distributed as various forms of program products, and the present application may, in fact, be embodied by the particular type of machine used for the distribution. Or the same applies regardless of the computer-readable medium.

Further examples of machine-readable storage media, machine-readable media, or computer-readable (storage) media include, but are not limited to, recordable types of media, such as volatile and non-volatile memory devices, floppies and other removable disks. , Hard disk drives, optical disks (such as CD Compact Disk Read-Only Memory), digital versatile disks (DVD), and the like, but not limited to transmission type media (such as digital and analog communication links). Not).

Unless the context clearly indicates otherwise, in the description and claims, the terms "comprises", "comprising", and similar terms are used in an open, non-closed manner, that is, in " Include, but are not limited to. As used herein, “connected”, “coupled,” or any variation thereof means any connection or combination, directly or indirectly, between two or more elements, wherein the coupling of the connections between the elements is physical, logical, or It can be a combination of the two. In addition, the words “here,” “above,” “below,” and the like when used herein refer to this application as a whole and not to any particular part of this application. As long as the context permits, the description of the above detailed description using the singular or plural may also include the plural or singular, respectively. The word "or" when referring to a list of two or more items covers any of the items in the list, or all the items in the list, or any combination of the items in the list.

The foregoing detailed description of the embodiments herein is not meant to be limiting to the disclosed form. While specific embodiments of the present application, and examples thereof, have been described above for purposes of illustration, various equivalent modifications that would be recognized by those skilled in the art are possible within the scope of the present application. For example, while processes or blocks are provided in a specified order, alternative embodiments may perform routines with steps, or use systems with blocks in a different order, and some processes or blocks may be deleted, moved, added, or split. May be combined, and / or modified to provide alternatives or sub-combinations. Each of these processes or blocks can be implemented in a variety of different ways. Also, while processes or blocks appear to be performed sequentially, these processes or blocks may be performed in parallel or at different points in time. In addition, any particular number referred to herein is merely an example, and alternative embodiments may use other values or ranges.

The description provided herein may be applied to other systems in addition to the systems described above. The elements and acts of the various embodiments described above can be combined to provide further embodiments.

Any of the aforementioned patents and applications and other citations which may be listed in the appended application are incorporated herein by reference. If desired, aspects of the present disclosure may be modified to provide further embodiments of the present invention in order to utilize the systems, functions, and concepts of the various references set forth above.

These and other changes can be applied to the present invention in consideration of the above detailed description. While specific embodiments of the present invention have been described above and the most optimal mode contemplated, it will be appreciated that the spirit of the invention may be practiced in various ways. Implementation details of the system can vary significantly within the scope of the invention. As mentioned above, certain terms used in describing the features or aspects of the present invention are not meant to be redefining that the terms are limited to any particular feature, feature, or aspect of the present invention with which the terms are associated. Should not. Generally, the terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the description, unless the above detailed description section explicitly defines such terms. Thus, the true scope of the present invention includes not only the embodiments described herein but also all equivalents embodied or implemented in accordance with the claims.

While certain aspects of the invention are provided below in the form of specific claims, the inventors contemplate the various aspects of the invention in any number of claims. For example, only one aspect of the invention is embodied as a means-plus function claim in accordance with 35 USC § 112, ¶ 6, and other aspects are similarly similar to functional claims or other It may be embodied in a form such as a computer-readable medium. (Any claim dealt with under 35 USC § 112, ¶ 6, will begin with the word “means for”.) Thus, the applicant should seek this further claim form for another aspect of the invention after filing. Reserves the right to add additional claims.

Claims (30)

A method for making a request on behalf of a mobile device, the method comprising
Detecting that the sequence of requests from the mobile device has a reproducible pattern,
Using a reproducible pattern, replicating the sequence of requests to an entity separate from the mobile device,
Sending, by the entity, a sequence of requests on behalf of the mobile device to conserve resources at the mobile device;
Wherein the response to the sequence of requests is provided to the mobile device. The method of claim 1 wherein the method is
Identifying a triggering event that triggers the initiation of the sequence of requests
Further comprising a sequence of requests occurring at a predictable time interval relative to the triggering event. The method of claim 2, wherein the method
Detecting the occurrence of a triggering event at the mobile device, and
Intercepting the request at the mobile device and preventing the request from being sent from the mobile device
And making a request on behalf of the mobile device. The method of claim 2, wherein the method
Simulating a sequence of events in the entity, and
The entity sending a sequence of requests on behalf of a mobile device
And making a request on behalf of the mobile device. 4. The method of claim 3, wherein the step of preventing the request from being sent from the mobile device comprises preventing the device radio of the mobile device from turning on in an off state. . The method of claim 1, wherein the entity is a proxy server capable of wireless communication with a mobile device,
And wherein the proxy server sends the sequence of requests to one or more destinations over a non-cellular connection. 7. The method of claim 6, wherein the reproducible pattern is detected by a proxy server. The method according to claim 6,
The reproducible pattern is detected by a local proxy on the mobile device and passed to the proxy server to be replicated,
A method for making a request on behalf of a mobile device, wherein an atomic process is created from the sequence of events. 2. The method of claim 1 wherein a reproducible pattern is detected from a parameter in a destination address addressed by the sequence of requests. 10. The method of claim 1, wherein the reproducible pattern in the sequence of requests includes a reproducible timing pattern. 10. The method of claim 1, wherein the reproducible pattern in the sequence of requests includes a reproducible periodicity pattern. 2. The method of claim 1, wherein the sequence of requests is communicated to different addressable entities of a server of one application on the mobile device. A method for simulating a traffic request from a mobile device, the method comprising:
Predicting that a request will be made by the mobile device prior to the request being sent by the mobile device to the destination, wherein the request is one of a sequence of detected requests as at least partially repeated traffic pattern for the application on the mobile device. Predicting one;
In a separate entity from the mobile device, making a request to the destination on behalf of the mobile device
And simulating a traffic request from a mobile device. delete 15. The method of claim 13, wherein the sequence of requests is passed to different addressable entities identified by different destination addresses at the host server for the application. The method of claim 13,
The entity further simulates the request, and the simulation is based on the traffic pattern of the outgoing request by the application on the mobile device,
The destination is a method for simulating traffic requests from a mobile device, characterized in that the destination server is a host server for the application. 14. The method of claim 13,
Create or update an application profile for your application using traffic patterns
Further comprising a traffic request from a mobile device. 18. The method of claim 17,
Simulating a traffic request for another mobile device with the same application using the application profile
Further comprising a traffic request from a mobile device. 14. The method of claim 13,
Detecting a set of traffic patterns of the outgoing request
Further comprising each set is detected for one of a plurality of applications on the mobile device. The method of claim 19, wherein the method is
Predicting requests to be made by a plurality of applications on the mobile device, and
On behalf of the mobile device, making a request to a destination associated with the plurality of applications at an entity separate from the mobile device
Further comprising a traffic request from a mobile device. The method of claim 13, wherein the prediction of the request is made by detecting a traffic pattern for a previous outgoing request from the mobile device. 22. The method of claim 21, wherein the traffic pattern is characterized by the timing of previous outgoing requests, or the destination address of previous outgoing requests. 22. The method of claim 21, wherein the destination address of previous outgoing requests are compared with each other to identify a traffic pattern. 22. The method of claim 21, wherein the traffic pattern is identified from a parameter in the destination address indicating that previous outgoing requests are forwarded to one server. 22. The method of claim 21, wherein the traffic pattern is identified from a parameter in the destination address indicating that previous outgoing requests originate from the same application on the mobile device. The method of claim 21, wherein the method is
When identifying the traffic pattern, comparing the destination address of the previous outgoing request for the application with a list of known addresses.
Further comprising a traffic request from a mobile device. 14. The method of claim 13, wherein the predicting comprises predicting the timing of the request, or the destination address of the request. The method of claim 13, wherein the method is
Preventing the request from being sent by the mobile device for device battery conservation and network resource conservation
And further comprising a response from the destination to the mobile device in response to the request being sent on behalf of the mobile device by the entity. A system for simulating traffic requests from a mobile device, the system comprising
Proxy server that predicts that the request will be made by the mobile device prior to sending the request to the destination by the mobile device.
Wherein the proxy server predicts the request through detection of a traffic pattern for a previous outgoing request from a mobile device,
The proxy server simulates the request on behalf of the mobile device and sends the request to the destination addressed by the request. 30. The method of claim 29,
The request is originated by an application on the mobile device,
And wherein the request is one of a sequence of at least partially repeated requests detected for the application.

Images