Abstract: Embodiments calculate an estimated latency between computing devices. A latency service aggregates latency records defining latency measurements and corresponding latency factors from a plurality of computing devices. From the aggregated latency records, the latency service defines relationships between the latency measurements and the corresponding latency factors. Responsive to a request for an estimated latency from a mobile computing device, the latency service applies the defined relationships to estimate the latency based on the latency factors associated with the received request. In some embodiments, the estimated latency includes three portions: a first latency value representing the latency from the mobile computing device to a cell site, a second latency value representing the latency from the cell site to an access point, and a third latency value representing the latency from the access point to a destination computing device.

Abstract: Application data prefetching embodiments are presented that prefetch and provide application data for use by an application operating on a mobile computing device during a period of disconnectivity from a communications network. In this way, an online experience can be achieved even during periods of network disconnectivity. In one implementation, application data is pushed to a mobile computing device by a cloud-based application data prefetching service. In another implementation, the mobile computing device takes on the tasks of prefetching the application data and providing it to the application.

Abstract: Methods and systems for dynamically providing application analytic information are provided herein. The method includes inserting instrumentation points into an application file via an application analytic service and dynamically determining desired instrumentation points from which to collect application analytic data. The method also includes receiving, at the application analytic service, the application analytic data corresponding to the desired instrumentation points and analyzing the application analytic data to generate application analytic information. The method further includes sending the application analytic information to a client computing device.

Abstract: Methods and systems for dynamically providing application analytic information are provided herein. The method includes inserting instrumentation points into an application file via an application analytic service and dynamically determining desired instrumentation points from which to collect application analytic data. The method also includes receiving, at the application analytic service, the application analytic data corresponding to the desired instrumentation points and analyzing the application analytic data to generate application analytic information. The method further includes sending the application analytic information to a client computing device.

Abstract: In embodiments of mobile device safe driving, a mobile device can display a device lock screen on an integrated display device, and transition from the device lock screen to display a driving mode lock screen. The transition to display the driving mode lock screen occurs without receiving a PIN code entered on the device lock screen. The mobile device implements a safe driving service that is implemented to activate a safe driving mode of the mobile device, and disable features of the mobile device while the safe driving mode is activated.

Abstract: An identification is made as to when a device is at an anchor location, which can be a proximity zone along an edge of a dead zone or a location where a signal from a beacon is detected. In response to the device being at the anchor location, one or more inertial sensors can be activated and data from the one or more inertial sensors collected to determine a position of the device using dead reckoning. Alternatively, in response to the device being at the anchor location, a determination is made as to when to deactivate one or more inertial sensors from which data is collected to determine the position of the device using dead reckoning.

Abstract: Mobile device emergency service techniques are described. In embodiments, a client device includes one or more modules implemented at least partially in hardware and configured to implement an emergency service. The emergency service configured to support operations including generating a user interface for display on a display device, receiving one or more inputs usable to form an emergency contacts list that includes a plurality of emergency contacts, and causing the emergency contacts list to be communicated to one or more other client devices for use in generating a message to be communicated automatically and without user intervention to the emergency contacts in the emergency contacts list responsive to a trigger.

Abstract: An identification is made as to when a device is at an anchor location, which can be a proximity zone along an edge of a dead zone or a location where a signal from a beacon is detected. In response to the device being at an anchor location, recording of crowd sourcing data based on dead reckoning starts. Recording crowd sourcing data based on dead reckoning includes identifying one or more signals received by a device while the device is at each of multiple positions. For each of the multiple positions, both an indication of the position determined based at least in part on dead reckoning and an indication of the one or more signals received while the device is at that position are recorded.

Abstract: The functionality described herein allows a user device to determine an appropriate juncture at which to initiate processing within a global navigation satellite system (GNSS) dead zone in an energy-efficient manner. In one implementation, the functionality employs a sensor management module for determining when to activate a device movement sensor module provided by a user device. When activated, the user device uses the device movement sensor module to perform any environment-specific processing, such as a dead-reckoning process for determining incremental positions within the venue. Further, in a crowd-sourcing application, the user device may report the incremental positions together with beacon information to remote processing functionality.

Abstract: In one kind of DoS attack, malicious customers may try to send a large number of filter requests against an innocent customer. In one implementation, a Filter Request Server (FRS) may allow a customer against who a filter request is made to dispute the implicit accusation of the filter request or stop sending malicious traffic. If the customer claims innocence, the FRS may log destination addresses of data packets sent by the customer and identify and ignore false filter requests if these filter requests come from customers who do not correspond to one or more of the destination addresses that have previously been logged by the FRS.

Abstract: In embodiments of mobile device safe driving, a mobile device can display a device lock screen on an integrated display device, and transition from the device lock screen to display a driving mode lock screen. The transition to display the driving mode lock screen occurs without receiving a PIN code entered on the device lock screen. The mobile device implements a safe driving service that is implemented to activate a safe driving mode of the mobile device, and disable features of the mobile device while the safe driving mode is activated.

Abstract: Aspects of the subject disclosure are directed towards monitoring application performance during actual use, particularly mobile application performance. Described is instrumenting mobile application binaries to automatically identify a critical path in user transactions, including across asynchronous-call boundaries. Trace data is logged by the instrumented application to capture UI manipulations, thread execution, asynchronous calls and callbacks, UI updates and/or thread synchronization. The trace data is analyzed to assist developers in improving application performance.

Abstract: An exemplary system includes a front-end component to receive requests for resources in a data center and configured to associate each request with identifying information, to locate one or more resources for each request and to store, in a log file, the identifying information and information about the location of the one or more resources; one or more distributed computation and storage components to acquire log file information and configured to analyze log information to decide if one or more resources associated with one or more requests should be migrated to a data center in a different geographical location; and a location service component to receive decisions made by the one or more distributed computation and storage components and configured to inform the front-end component when a decision causes one or more resources to be migrated to a data center in a different geographical location to thereby allow the front-end component to re-direct future requests for the one or more migrated resources to t

Abstract: In one kind of DoS attack, malicious customers may try to send a large number of filter requests against an innocent customer. In one implementation, a Filter Request Server (FRS) may allow a customer against who a filter request is made to dispute the implicit accusation of the filter request or stop sending malicious traffic. If the customer claims innocence, the FRS may log destination addresses of data packets sent by the customer and identify and ignore false filter requests if these filter requests come from customers who do not correspond to one or more of the destination addresses that have previously been logged by the FRS.

Abstract: An environment is described in which a processing system provides application-level usage information to users. In one scenario, for example, the processing system may provide personal usage information to a user who is operating a user device. The personal usage information itemizes the amount of data (and/or other resources) that has been consumed by each application run by the user device. In another scenario, the processing system may provide expected usage information associated with at least one candidate application provided by a marketplace system. The expected usage information describes an expected consumption of data (and/or other resources) by the candidate application upon running the candidate application by the user device. The processing system can tailor the expected usage information that it sends to a particular user based on user profile data. The user profile data describes a manner in which users operate applications.

Abstract: The claimed subject matter provides a system and/or a method that facilitates connectivity within a peer-to-peer networking environment. A client can transmit a request to connect with a host for peer-to-peer networking. A server can generate a list that includes at least one host that matches the request from the client. A predictor engine can reduce the list by at least one matched host based upon a predictor, wherein the predictor is at least one of an Internet Protocol history predictor, a prefix history predictor, or a geography predictor.

Abstract: A method and system analyze data in a database. The method and system include defining a plurality of set of rules, wherein each set of rules corresponds to a predictive model, storing the each set of rules corresponding to the predictive model in a library as a user-defined function, and calling the user-defined function via a standard sequel language.

Abstract: Migration functionality is described herein for efficiently migrating application state information among user devices. The migration functionality operates by receiving factor information that describes a context in which a user is using an application on a first user device. For instance, the factor information may describe the manner in which the user has used the application on various user devices on prior occasions, together with characteristics of the user's current environment. The migration functionality then determines, based on the factor information, whether to transfer application state information from the first user device to at least a second user device. The application state information captures at least a dynamic runtime state of the application on the first user device.

Abstract: An environment is described in which a processing system provides application-level usage information to users. In one scenario, for example, the processing system may provide personal usage information to a user who is operating a user device. The personal usage information itemizes the amount of data (and/or other resources) that has been consumed by each application run by the user device. In another scenario, the processing system may provide expected usage information associated with at least one candidate application provided by a marketplace system. The expected usage information describes an expected consumption of data (and/or other resources) by the candidate application upon running the candidate application by the user device. The processing system can tailor the expected usage information that it sends to a particular user based on user profile data. The user profile data describes a manner in which users operate applications.

Abstract: Methods and systems for reducing network usage of a computing device are provided herein. The method includes receiving a network call relating to a network transfer from an application at an application programming interface of the computing device. The method also includes determining whether the network transfer is relevant to a current state of the application and procrastinating the network transfer if it is not relevant to the current state of the application.