Patent Description:
In order for users to access a cloud service, the user device (sometimes a mobile device) needs to have connectivity to a wide area network (such as the Internet). In order for a user to have connectivity to an enterprise application, over a wide area network, the enterprise's internal network is made available at a point of Internet egress. Many enterprises currently provide Internet egress points at a few different locations, because of the protections that are needed to maintain security and integrity.

It can be beneficial for the cloud service to measure metrics corresponding to the enterprise, so the cloud service can determine how the internal network (or other characteristics) of the enterprise are impacting its cloud experience. The cloud service can then provide information to the enterprise indicative of how to improve its cloud experience. Also, the metrics that are measured may be less useful to the cloud service if they do not also include a user location identifying where the metric was measured. Without user location, the metric has less context by which to be evaluated.

<CIT> describes that a terminal device has: a sensor unit which perform a measurement; a position detection unit which acquires information for specifying a position; a timing unit which acquires time information; a communication unit which communicates via a communication network; and a control unit. The control unit generates position information for indicating a position of the terminal device by the position detection unit. Besides, the control unit changes accuracy of the position information within a predetermined range, and generates information for transmission related with the changed position information, the time information gotten by the timing unit, and measurement information indicating a measurement result of the sensor unit. In addition, the control unit controls the communication unit so as to transmit the information for the transmission to an information processing device via a communication network. <CIT> describes that apps may be tagged with location data when they are used. Mobile device may anonymously submit app usage data. Aggregated app usage data from many mobile devices may be analyzed to determine apps that are particularly relevant to a given location (i.e., exhibiting a high degree of localization). Analysis may include determining the app usage intensity, whether hotspots exist or not at a given location, the spatial entropy of a particular app, the device populations in a particular area, etc. Based on the localized app analysis, apps may be ranked according to local relevance, and, based on this ranking, app recommendations may be provided to a user. <CIT> describes a communication system in which a mobile communication device receives MDT configuration requests from a base station or radio network controller to initiate an MDT measurement session for obtaining measurement data and location related data for identifying a location to which said measurement data relates. The mobile communication device checks a user consent indicator in memory and only provides the location related data if the user consent indicator indicates that a user of the mobile communication device consents to the provision the location related data.

A client-side system detects a current location of a client device and a cloud interaction metric. The geographic area around the location of the client device is divided into grid sections. The client-side system identifies a pre-defined reference location corresponding to the grid section that the client device location resides in. The pre-defined reference location, corresponding to that grid section, and the cloud interaction metric are provided to a remote server computing system.

The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in the background.

As discussed above, it can be helpful in many different scenarios to know the geographic location of the users of a cloud service or another application that provides client access to a remote server environment. However, many regions have privacy regulations that govern what type of user location data can be obtained and what can be done with it. Similarly, it may be difficult to get users to voluntarily disclose their location data. However, without any type of user location data, even when cloud interaction metrics are measured and obtained, it can be very difficult for a cloud service to understand and fix (or advise an enterprise how to fix) any connectivity issues. Therefore, it can be difficult to determine how to improve deployment of computing system resources, and how to improve the user experience.

It has been found, however, that some scenarios (such as connectivity design) do not need to obtain accurate, individual user location information. Instead, these types of systems can focus on groups of users, and a material approximation of location is adequate to make many decisions. Further, when an enterprise asserts connectivity designs across its organization (such as at branch offices), it can be important for the enterprise to understand the impact this has on the cloud experience encountered at the branch office.

The present description thus proceeds with respect to a client-based location system that generates an abstracted location, based upon an actual user location. The abstracted location provides a pre-defined reference location corresponding to a grid section that has a pre-defined area, and which includes the user's actual location.

<FIG> is a block diagram of a computing system architecture <NUM>. Architecture <NUM> shows a client device/computing system <NUM> accessing a cloud service computing system <NUM> over a network <NUM>. Therefore, network <NUM> can be a wide area network, a local area network, a cellular network, a near field communication network, or any of a wide variety of other networks or combinations of networks.

<FIG> shows that, in one example, client device <NUM> generates user interfaces <NUM> for interaction by user <NUM>. User <NUM> illustratively interacts with user interfaces <NUM> in order to control and manipulate client device/computing system <NUM> and some portions of cloud service computing system <NUM>.

<FIG> also shows that one or more other client devices/computing systems <NUM> can generate user interfaces <NUM> for interaction by other users <NUM>. Users <NUM> can thus interact with user interfaces <NUM> in order to control and manipulate client device/computing system <NUM>, and some portions of remote server computing system <NUM>.

It may be that cloud service computing system <NUM> runs one or more applications that receive, as an input, the location of the various client devices <NUM>, <NUM> that are using it along with one or more cloud interaction metrics that are measured and are indicative of a cloud interaction characteristic of the client devices relative to the cloud service. The metric is illustratively one that is impacted by the location of the corresponding client device relative to the location of the cloud service computing system <NUM>, when the metric was measured. Therefore, the present discussion proceeds with respect to client devices <NUM>, <NUM> generating and providing abstracted location information, and a cloud interaction metric, to cloud service computing system <NUM>. It will be noted that client devices <NUM>, <NUM> can be similar or different. For purposes, of the present description, it will be assumed that they are similar so that only client device/computing system <NUM> is described in more detail.

Client device/computing system <NUM> (sometimes referred to herein as client device <NUM>) illustratively includes one or more processors <NUM>, data store <NUM>, cloud interaction metric measurement logic <NUM>, location sensing system <NUM>, communication system <NUM>, location abstraction system <NUM>, user interface system <NUM>, and it can include a wide variety of other client computing system functionality <NUM>. Cloud service computing system <NUM> illustratively includes one or more processors or servers <NUM>, one or more data stores <NUM>, and location data consuming application <NUM> (which can, itself, include user grouping system <NUM>, measured metric analysis system <NUM>, connectivity analysis system <NUM>, and other items <NUM>). Cloud service computing system <NUM> can also include a wide variety of other remote server computing system functionality <NUM>. Before describing the overall operation of architecture <NUM>, a brief description of some of the items in architecture <NUM>, and their operation, will first be provided.

Location data consuming application/service <NUM> can be any of a wide variety of different types of services or applications. In the example described herein, it can be an application or service that analyzes connectivity information in order to improve the remote server computing system <NUM>, and in order to improve the experience of various users <NUM>, <NUM> (which may be users at an enterprise or other organization) in using their client devices <NUM>, <NUM> to connect to cloud service computing system <NUM>. Thus, user grouping system <NUM> can group the users <NUM>, <NUM> based upon their geographic location (or abstracted location). Measured metric analysis system <NUM> can perform any of a wide variety of different types of analysis on the measured metrics received from client devices <NUM>, <NUM>. Connectivity analysis system <NUM> can analyze any connectivity issues, such as load balancing issues, resource deployment and management issues, latency, among a wide variety of other things, based on the abstracted locations and analysis performed by system <NUM>.

It will be noted that client device/computing system <NUM> can take a wide variety of different forms. It may be a mobile device, a desktop computer, or another device. It illustratively includes cloud interaction metric measurement logic <NUM> which measures one or more different metrics that may characterize different aspects of the interaction between client device <NUM> and cloud service computing system <NUM>, where the metric values vary based on, or depend in some way on, or are somehow to be corrected to, the location of the device <NUM> taking the measurement. Some examples of measured metrics are described in greater detail below. Client device <NUM> also illustratively includes a location sensing system <NUM> that senses a location of device <NUM>. Location sensing system <NUM> can thus be a GPS receiver, a cellular triangulation system, a dead reckoning system, or any of a wide variety of other systems that can generate a geographic location signal indicative of a sensed geographic location of device <NUM> in a local or global coordinate system. Location abstraction system <NUM> illustratively abstracts the location provided by location sensing system <NUM>. It does so by obtaining a set of grid sections that the geographic area around device <NUM> is divided into. It identifies which grid section device <NUM> is included in, and then picks a pre-defined reference location, corresponding to that grid section, as the abstract location of device <NUM>. The precise location of device <NUM> is thus abstracted to a geographic area the size of the grid section. The pre-defined reference location for the grid section may be the center of the grid section, one of the corners of the grid section, etc..

Communication system <NUM> is configured to facilitate the communication of client device/computing system <NUM> with cloud service computing system <NUM> over network <NUM>. Therefore, communication system <NUM> may vary, depending on the type of communication it is to facilitate. The communication may involve a network that provides multiple different paths between systems <NUM> and <NUM>.

User interface system <NUM> illustratively generates user interfaces <NUM> and detects user interaction with those interfaces. It can provide an indication of the user interaction with interfaces <NUM> to other items in client device/computing system <NUM>, and possibly to cloud service computing system <NUM>.

<FIG> and <FIG> (collectively referred to herein as <FIG>) show a flow diagram illustrating one example of the operation of client device/computing system <NUM> in generating and sending a cloud interaction metric and abstract location information to cloud service computing system <NUM>. It is first assumed that cloud service computing system <NUM> (or another remote system) or client device/computing system <NUM>, generates a grid representation of a geographic area around client device/computing system <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>. The grid representation illustratively divides the geographic area around device <NUM> into a set of grid sections of a predefined size. Generating it in a cloud service is indicated by block <NUM>, and generating it in other ways is indicated by block <NUM>. One way of generating the grid representation of the geographic area is described in greater detail below with respect to <FIG>.

The grid representation of the geographic area is obtained by location abstraction system <NUM>, on client device/computing system <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>. The grid representation can be obtained for the entire world <NUM>. It can be obtained for a predetermined, relevant area around the current location of client device/computing system <NUM>, as indicated by block <NUM>. Or it can be obtained for a dynamically sized area, based on sizing criteria, as indicated by block <NUM>. For instance, if the location of client device/computing system <NUM> is relatively static, then a grid representation of a relevant geographic area around that location, having a pre-defined size may be obtained. However, if the location of the client device/computing system <NUM> is changing relatively rapidly (such as if user <NUM> is carrying it on an airplane, or otherwise), then the geographic area around device <NUM>, for which the grid representation is obtained, may be enlarged to encompass a wider area. The grid representation can be obtained on the client device/computing system <NUM> in other ways as well, and this is indicated by block <NUM>. Once obtained, device <NUM> has a geographic area around it that is divided into grid sections of equal size.

Cloud interaction metric measurement logic <NUM> can measure cloud interaction metrics in different ways. The metrics include latency encountered from the location of client device <NUM> to the location of the networking entry point to the service provided by cloud service computing system <NUM>. The metrics include the throughput of a file download on the client device <NUM> from the networking entry point to the could-based service. The metric can be a simulated call experience on client device <NUM> from the networking entry point to the cloud-based service.

Cloud interaction measurement logic <NUM> measures metric values, as indicated by block <NUM>. They can be measured intermittently, as indicated by block <NUM>, substantially continuously, as indicated by block <NUM>, or in other ways, as indicated by block <NUM>. Logic <NUM> then stores the measured metric values in data store <NUM> for transmission to cloud service computing system <NUM>. Storing the metric values is indicated by block <NUM> in <FIG>.

At some point, location sensing system <NUM> will generate a location signal indicative of a sensed, current location of client device/computing system <NUM>. It may do this intermittently, periodically, or based on other criteria. For instance, if the location of client device/computing system <NUM> is relatively static, then location sensing system <NUM> may generate a location signal relatively infrequently. However, if the location of device/computing system <NUM> is changing rapidly, then location sensing system <NUM> may generate location signals indicative of its location more frequently, or substantially continuously (e.g., on near real-time). Determining whether location sensing system <NUM> should generate a location signal indicative of a current location of client device/computing system <NUM> is indicated by block <NUM> in the flow diagram of <FIG>.

When it is time, location sensing signal <NUM> detects a current location (e.g., longitude/latitude coordinates) of the client device/computing system <NUM>. This can be referred to as the "client location" and is indicated by block <NUM> in the flow diagram of <FIG>. Location abstraction system <NUM> receives the client location and identifies a grid section (in the grid representation) that includes the client location, and then identifies a predetermined reference location corresponding to that grid section. Identifying the grid section is indicated by block <NUM> and identifying the reference location for that grid section is indicated by block <NUM>. In one example, steps <NUM> and <NUM> are performed together. A more detailed example of this is illustrated and discussed below with respect to <FIG> and Table <NUM>.

As briefly mentioned above, the pre-defined reference location corresponding to the identified grid section that includes the client location may be the center point of that grid section, as indicated by block <NUM>. It may be a pre-defined one of the corners of that grid section, as indicated by block <NUM>. It may be another pre-defined reference location corresponding to that grid section, and this is indicated by block <NUM>. System <NUM> can store the abstract location, along with the actual location provided by location sensing system <NUM>, in data store <NUM> for later analysis or transmission to cloud service computing system <NUM>, or it can use communication <NUM> to communicate the abstract location and measured metric values to remote server computing system <NUM> immediately after it is identified.

Determining whether the abstracted client location and measured metric values are to be sent to another system (such as cloud service computing system <NUM>) is indicated by block <NUM> in the flow diagram of <FIG>. This determination can be based on time criteria as indicated by block <NUM>. For instance, communication system <NUM> can transmit the abstract location of client device/computing system <NUM> intermittently or periodically. The determination can be based on the location of client device/computing system <NUM>, or it can be based on a determination of whether the location of client device/computing system <NUM> has changed. For instance, it may be that communication system <NUM> only transmits a new abstract location of client device/computing system <NUM> to cloud service computing system <NUM>, if that abstract location has changed since it was last sent. Sending the abstract location based on the location or a location change is indicted by block <NUM> in the flow diagram of <FIG>.

Communication system <NUM> can send the abstract location and measured metric values based upon use criteria. For instance, if client device/computing system <NUM> is frequently accessing cloud service computing system <NUM>, then its abstract location may be sent to remote server computing system <NUM> more often. Determining whether to send the abstract location based on use criteria is indicated by block <NUM> in the flow diagram of <FIG>.

Determining whether to send the abstract client location and measured metric values can be based on other criteria as well. This is indicated by block <NUM> in the flow diagram of <FIG>.

If the abstract client location (or the measured metric values) are not to be sent to remote server computing system <NUM> yet, as indicated by block <NUM>, then location abstraction system <NUM> stores the abstract client location in data store <NUM> so that it can be sent later. Location sensing system <NUM> can also store the actual client location as well. Storing the client location and the identified reference location (or abstract location) is indicated by block <NUM>.

If, at block <NUM>, it is determined that the abstract location is to be sent to cloud service computing system <NUM>, then communication system <NUM> obtains any stored reference locations (or abstract locations) that have not yet been sent to remote server computing system <NUM> from storage and which have corresponding, stored metric measurements. This is indicated by block <NUM>. It then sends those reference locations (or abstract locations) and metric measurements to remote server computing system <NUM>. This is indicated by block <NUM>. This process can continue, until operation of the client device <NUM> is completed. This is indicated by block <NUM>.

It should be noted that cloud service computing system <NUM> does not need to track the location of device <NUM>, but only to report the abstract location of device <NUM> when a measurement of a cloud interaction metric is made, so that the measurement can be related to the location of device <NUM> when the measurement was taken.

<FIG> is a flow diagram illustrating one example of how a geographic region on earth can be divided into segments, each having a pre-defined area. It will first be noted that the distance between two longitudinal degrees, at any latitude, changes depending on the latitude angle according to the following equation: <MAT>.

From Equation <NUM> above, it can be seen that the distance corresponding to a one degree change in longitude at the equator is <NUM> kilometers.

Assume, for the sake of example, that the grid sections discussed herein are to be square grid sections where each side measures <NUM> meters. In that case, the longitude variation at any latitude (Lat D), over <NUM> meters is as follows: <MAT>.

This is referred to as the longitude delta.

Unlike longitude, the difference between two degrees of latitude does not change at different longitudes. Instead, the distance over the surface of the earth covered by a change of one latitude degree is given as follows: <MAT>.

This is will be referred to as latitude delta.

Referring again to <FIG>, in order to obtain grid segments for a relevant geographic region, the distance between each pair of latitude degrees is first divided into multiple segments, each having a distance of x meters (where x is the desired length of one side of the grid segment or grid section). This is indicated by block <NUM> in the flow diagram of <FIG>. This can be done, as discussed above, using the latitude delta measure. This is indicated by block <NUM>. It can be done in other ways as well, as indicated by block <NUM>.

Next, the distance between each pair of longitude degrees in the relevant area is divided into multiple segments each having a distance of x meters (where x, again, is the length of the sides of the grid sections or grid segments). This is indicated by block <NUM>. This can be done using the longitude delta measure, discussed above. This is indicated by block <NUM>. It can be done in other ways as well, and this is indicated by block <NUM>. The axes of division of the segments (along the longitude line and the latitude line), define the grid segments in the relevant area.

<FIG> is a flow diagram indicating how location abstraction system <NUM> identifies the particular grid segment and pre-defined reference location (or abstracted location) for a particular longitude and latitude that is received. It is first assumed that location abstraction system <NUM> receives the client location. This is indicated by block <NUM> in the flow diagram of <FIG>. Location abstraction system <NUM> then computes the maximum longitude (max long) after adding increments of the longitude delta from the start of the longitude degree indicated by the client location (truncated to degrees), but less than the current untruncated longitude in the client location. Assuming that the pre-defined reference for a grid segment is the lower left-hand corner of that grid segment, then this computation finds the longitude coordinate corresponding to that corner. This is indicated by block <NUM> in the flow diagram of <FIG>.

Next, location abstraction system <NUM> computes the maximum latitude (max lat) after adding increments of the latitude delta from the start of the latitude degree indicated by the client location (truncated to degrees), but less than the current untruncated latitude in the client location. This finds the latitude coordinate for the lower left-hand corner of the grid section that the client location resides in. This is indicated by block <NUM> in the flow diagram of <FIG>.

Location abstraction system <NUM> then returns the max lat/max long point as the abstract location (or pre-defined reference location) for the grid segment that includes the received latitude and longitude coordinates in the client location. This is indicated by block <NUM> in the flow diagram of <FIG>.

Table <NUM> shows another form of pseudo code for finding the lower left-hand corner of a grid segment, of <NUM> square meters, that includes a longitude and latitude coordinate (client location) that is input from a location sensing system <NUM>.

<FIG> is a flow diagram illustrating one example of the operation of a location data consuming application or service <NUM>. It is first assumed that the client abstract location data and measured metric values are received by cloud service computing system <NUM>, from client device/computing systems <NUM> and <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>. User grouping system <NUM> then groups users <NUM>, <NUM>. There can be a variety of different grouping criteria, such as based upon their geographic location, as indicated by the abstract location data corresponding to those users (and/or their corresponding client devices/computing systems <NUM>, <NUM>), based on networking metadata, and/or other criteria. Grouping the users and/or devices is indicated by block <NUM> in the flow diagram of <FIG>. Grouping based on location is indicated by block <NUM>, grouping based on networking metadata is indicated by block <NUM> and grouping based on other criteria is indicated by block <NUM>.

Measured metric analysis system <NUM> then analyzes the measured metrics, and connectivity analysis system <NUM> analyzes connectivity and traffic patterns based on locations and sizes of the groups. This is indicated by block <NUM>. For example, if a relatively large group of users or devices is frequently accessing a cloud services computing system <NUM>, and they are all grouped in one geographic location, then the connectivity and traffic patterns for that geographic location can be high. Also, a pool of shared devices could result in a relatively large number of users, but not a large number of devices.

Location data consuming application/service <NUM> can perform other processing and analysis based upon the locations and sizes of groups, as indicted by the abstract location data. This is indicated by block <NUM>. Location data consuming application/service <NUM> can then generate relevant action signals based on the analysis. This is indicated by block <NUM>. The action signals can be, for instance, to change the routing of traffic when interacting with cloud service computing system <NUM>, to deploy additional resources in different geographic locations to improve connectivity characteristics, to reduce computing resources in other locations, to surface an indication of the analyses that are performed for design, administrative or engineering personnel, or a wide variety of other relevant action signals.

The present discussion has mentioned processors and servers. In one embodiment, the processors and servers include computer processors with associated memory and timing circuitry, not separately shown. They are functional parts of the systems or devices to which they belong and are activated by, and facilitate the functionality of the other components or items in those systems.

<FIG> is a block diagram of architecture <NUM>, shown in <FIG>, except that its elements are disposed in a cloud computing architecture <NUM>. Cloud computing provides computation, software, data access, and storage services that do not require end-user knowledge of the physical location or configuration of the system that delivers the services. In various examples, cloud computing delivers the services over a wide area network, such as the internet, using appropriate protocols. For instance, cloud computing providers deliver applications over a wide area network and they can be accessed through a web browser or any other computing component. Software or components of architecture <NUM> as well as the corresponding data, can be stored on servers at a remote location. The computing resources in a cloud computing environment can be consolidated at a remote data center location or they can be dispersed. Cloud computing infrastructures can deliver services through shared data centers, even though they appear as a single point of access for the user. Thus, the components and functions described herein can be provided from a service provider at a remote location using a cloud computing architecture. Alternatively, they can be provided from a conventional server, or they can be installed on client devices directly, or in other ways.

The description is intended to include both public cloud computing and private cloud computing. Cloud computing (both public and private) provides substantially seamless pooling of resources, as well as a reduced need to manage and configure underlying hardware infrastructure.

A public cloud is managed by a vendor and typically supports multiple consumers using the same infrastructure. Also, a public cloud, as opposed to a private cloud, can free up the end users from managing the hardware. A private cloud may be managed by the organization itself, or by a third party, and the infrastructure is typically not shared with other organizations. The organization still maintains the hardware to some extent, such as installations and repairs, etc..

In the example shown in <FIG>, some items are similar to those shown in <FIG> and they are similarly numbered. <FIG> specifically shows that remote server computing system <NUM> can be located in cloud <NUM> (which can be public, private, or a combination where portions are public while others are private). Therefore, users <NUM>, <NUM> use user devices <NUM>, <NUM> to access those systems through cloud <NUM>.

<FIG> also depicts another example of a cloud architecture. <FIG> shows that it is also contemplated that some elements of computing system <NUM> can be disposed in cloud <NUM> while others are not. By way of example, data store <NUM> can be disposed outside of cloud <NUM>, and accessed through cloud <NUM>. In another example, location data consuming application/service <NUM> (or other items) can be outside of cloud <NUM>. Regardless of where they are located, they can be accessed directly by device <NUM>, <NUM>, through a network (either a wide area network or a local area network), they can be hosted at a remote site by a service, or they can be provided as a service through a cloud or accessed by a connection service that resides in the cloud. All of these architectures are contemplated herein.

It will also be noted that architecture <NUM>, or portions of it, can be disposed on a wide variety of different devices. Some of those devices include servers, desktop computers, laptop computers, tablet computers, or other mobile devices, such as palm top computers, cell phones, smart phones, multimedia players, personal digital assistants, etc..

<FIG> is a simplified block diagram of one illustrative example of a handheld or mobile computing device that can be used as a user's or client's hand held device <NUM>, in which the present system (or parts of it) can be deployed. <FIG> are examples of handheld or mobile devices.

<FIG> provides a general block diagram of the components of a client device <NUM> that can run components computing systems <NUM>, <NUM> or that interacts with architecture <NUM>, or both. In the device <NUM>, a communications link <NUM> is provided that allows the handheld device to communicate with other computing devices and under some embodiments provides a channel for receiving information automatically, such as by scanning. Examples of communications link <NUM> include an infrared port, a serial/USB port, a cable network port such as an Ethernet port, and a wireless network port allowing communication though one or more communication protocols including General Packet Radio Service (GPRS), LTE, HSPA, HSPA+ and other <NUM> and <NUM> radio protocols, 1Xrtt, and Short Message Service, which are wireless services used to provide cellular access to a network, as well as Wi-Fi protocols, and Bluetooth protocol, which provide local wireless connections to networks.

In other examples, applications or systems are received on a removable Secure Digital (SD) card that is connected to a SD card interface <NUM>. SD card interface <NUM> and communication links <NUM> communicate with a processor <NUM> (which can also embody processors or servers from other FIGS. ) along a bus <NUM> that is also connected to memory <NUM> and input/output (I/O) components <NUM>, as well as clock <NUM> and location system <NUM>.

I/O components <NUM>, in one example, are provided to facilitate input and output operations. I/O components <NUM> for various examples of the device <NUM> can include input components such as buttons, touch sensors, multi-touch sensors, optical or video sensors, voice sensors, touch screens, proximity sensors, microphones, tilt sensors, and gravity switches and output components such as a display device, a speaker, and or a printer port. Other I/O components <NUM> can be used as well.

Memory <NUM> stores operating system <NUM>, network settings <NUM>, applications <NUM>, application configuration settings <NUM>, data store <NUM>, communication drivers <NUM>, and communication configuration settings <NUM>. Memory <NUM> can include all types of tangible volatile and non-volatile computer-readable memory devices. It can also include computer storage media (described below). Memory <NUM> stores computer readable instructions that, when executed by processor <NUM>, cause the processor to perform computer-implemented steps or functions according to the instructions. Similarly, device <NUM> can have a client system <NUM> which can run various applications or embody parts or all of architecture <NUM>. Processor <NUM> can be activated by other components to facilitate their functionality as well.

Examples of the network settings <NUM> include things such as proxy information, Internet connection information, and mappings. Application configuration settings <NUM> include settings that tailor the application for a specific enterprise or user. Communication configuration settings <NUM> provide parameters for communicating with other computers and include items such as GPRS parameters, SMS parameters, connection user names and passwords.

Applications <NUM> can be applications that have previously been stored on the device <NUM> or applications that are installed during use, although these can be part of operating system <NUM>, or hosted external to device <NUM>, as well.

<FIG> shows one example in which device <NUM> is a tablet computer <NUM>. In <FIG>, computer <NUM> is shown with user interface display screen <NUM>. Screen <NUM> can be a touch screen (so touch gestures from a user's finger can be used to interact with the application) or a pen-enabled interface that receives inputs from a pen or stylus. It can also use an on-screen virtual keyboard. Of course, it might also be attached to a keyboard or other user input device through a suitable attachment mechanism, such as a wireless link or USB port, for instance. Computer <NUM> can also illustratively receive voice inputs as well.

<FIG> is one example of a computing environment in which architecture <NUM>, or parts of it, (for example) can be deployed. With reference to <FIG>, an example system for implementing some embodiments includes a general-purpose computing device in the form of a computer <NUM> programmed to operate as described above. Components of computer <NUM> may include, but are not limited to, a processing unit <NUM> (which can comprise processors or servers from previous FIGS. ), a system memory <NUM>, and a system bus <NUM> that couples various system components including the system memory to the processing unit <NUM>. The system bus <NUM> may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus. Memory and programs described with respect to <FIG> can be deployed in corresponding portions of <FIG>.

Communication media typically embodies computer readable instructions, data structures, program modules or other data in a transport mechanism and includes any information delivery media. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

By way of example only, <FIG> illustrates a hard disk drive <NUM> that reads from or writes to non-removable, nonvolatile magnetic media, and an optical disk drive <NUM> that reads from or writes to a removable, nonvolatile optical disk <NUM> such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like.

Operating system <NUM>, application programs <NUM>, other program modules <NUM>, and program data <NUM> are given different numbers here to illustrate that, at a minimum, they are different copies.

These and other input devices are often connected to the processing unit <NUM> through a user input interface <NUM> that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).

The computer <NUM> is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer <NUM>. The remote computer <NUM> may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer <NUM>. The logical connections depicted in <FIG> include a local area network (LAN) <NUM> and a wide area network (WAN) <NUM>, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

The modem <NUM>, which may be internal or external, may be connected to the system bus <NUM> via the user input interface <NUM>, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer <NUM>, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, <FIG> illustrates remote application programs <NUM> as residing on remote computer <NUM>. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

It should also be noted that the different examples described herein can be combined in different ways. That is, parts of one or more examples can be combined with parts of one or more other examples. All of this is contemplated herein.

Claim 1:
A computer implemented method, comprising:
sensing (<NUM>), using a metric sensor (<NUM>), a value of a cloud service interaction variable that varies based on location;
sensing, using a position sensor (<NUM>), a geographic location corresponding to the value of the cloud service interaction variable and generating a location signal indicative of the sensed geographic location;
generating (<NUM>) a set of location coordinates indicative of the sensed geographic location, based on the location signal;
identifying (<NUM>) a pre-defined geographic grid section, having a predefined area, that includes the set of location coordinates;
identifying (<NUM>) a pre-defined reference location corresponding to the identified predefined geographic grid section, as an abstract client location; and
sending (<NUM>) the abstract client location and the corresponding value of the cloud service interaction variable to a remote computing system of a cloud-based service,
wherein the cloud service interaction variable is a latency encountered from the client location to a location of a networking entry point to the cloud-based service, or the cloud service interaction variable is a throughput of a file download at a client device at the client location from the networking entry point to the cloud-based service.