Profiling application usage from application streaming

Application usage is profiled based on application streaming. Code pages of multiple applications are streamed from a server to multiple client computers (endpoints) for execution. The streaming of the code pages is monitored, and usage data is collected such as which pages are streamed to which endpoints, under what circumstances and when. By referencing the streamed code pages and the underlying source code, the code pages are mapped (at least approximately) to corresponding application features. The collected usage data usage and the relevant mapping are analyzed, to create application usage profile data for streamed applications. The application usage profile data can include such information as how often, when, where and by whom application components are being executed, as well as which components cause errors, are most popular, confuse users, etc.

TECHNICAL FIELD

This invention pertains generally to application streaming technology, and more specifically to using application streaming to provide central application profiling.

BACKGROUND

Application streaming provides the ability for an endpoint (e.g., a client computer) to run an application locally that is stored remotely, for example on a server. The server transmits specific portions of the application (e.g., code pages) to the endpoint, as the endpoint needs them. Application streaming offers a number of advantages over running the application on the server. Streaming the application allows the application to execute locally on the endpoint, instead of remotely on the server. This eliminates the need for large farms of servers to provide applications to a plurality of client computers. Application response time to the user is also significantly faster when the application is run locally on the endpoint, as opposed to remotely on the server. Commercial application streaming technology exists today.

Software developers, quality assurance professionals and publishers have a strong interest in knowing how their software programs are actually used in the field. Data on which features of a software program are popular, which are never utilized, which confuse users, which cause the application to crash, etc., are clearly an asset in the design, implementation, testing, trouble shooting and marketing of existing and planned software programs. It is currently difficult to obtain reliable information of this nature for a wide variety of representative users.

It would be desirable to be able to glean accurate profiling data concerning application usage for a wide variety of users.

SUMMARY

Application usage is profiled based on application streaming. Code pages of multiple applications are streamed from a server to multiple client computers (endpoints) for execution. The streaming of the code pages is monitored, and usage data is collected such as which pages are streamed to which endpoints, under what circumstances and when. By referencing the streamed code pages and the underlying source code, the code pages are mapped (at least approximately) to corresponding application features. The collected usage data usage and the relevant mapping are analyzed, to create application usage profile data for streamed applications. The application usage profile data can include such information as how often, when, where and by whom application components are being executed, as well as which components cause errors, are most popular, confuse users, etc.

DETAILED DESCRIPTION

FIG. 1illustrates a system100for using application streaming to collect application usage data102, according to some embodiments of the present invention. It is to be understood that although various components are illustrated inFIG. 1as separate entities, each illustrated component represents a collection of functionalities which can be implemented as software, hardware, firmware or any combination of these. Where a component is implemented as software, it can be implemented as a standalone program, but can also be implemented in other ways, for example as part of a larger program, as a plurality of separate programs, as a kernel loadable module, as one or more device drivers or as one or more statically or dynamically linked libraries.

As illustrated inFIG. 1, a streaming agent104streams application content101from a server103to a plurality of endpoints105over a network109, such that the streamed applications107are executed on the endpoints105. For the sake of illustration,FIG. 1shows one only application107being streamed to three endpoints105, but it is to be understood that an application streaming system100typically streams many applications107to a large plurality of endpoints105, the endpoints105sometimes being very diverse geographically. Because the streaming agent104serves application content101at a code page level, there exists a great opportunity to glean usage data102concerning the usage of the applications107being streamed.

As is understood by those of ordinary skill in the relevant art, the execution of a streamed application107is managed to a very fine level of detail by the streaming agent104, which provides specific code pages101as they are required for execution by the endpoint105. As illustrated inFIG. 1, the streaming agent104monitors usage statistics102, for example by monitoring the frequency and order of code pages101streamed to each endpoint105for each application107, per application107usage instance. In a simple case, this could be implemented simply by using a set of counters per code page101for each usage “session” of an application107. Of course, more complicated usage information102can be tracked, including not only which parts of which applications107are used (i.e., which code pages101are streamed to an endpoint105for execution), but also by whom (i.e., which endpoint105) and where (i.e., where is the endpoint105geographically located), when, how often, for how long, etc. The implementation mechanics of gathering such usage data102based on streamed code pages101will be readily apparent to those of ordinary skill in the relevant art in light of this specification. It is to be understood that what usage data102to gather is a variable design parameter.

As illustrated inFIG. 2, as application usage data102is collected over time, it can be provided (still classified per distinct usage session) to an analysis module201, for further analysis. In the embodiment illustrated inFIG. 2, the analysis module201runs on an application developer site203. In other embodiments, the analysis module201can run at other locations (e.g., the streaming server103) as desired. An application developer205or the like provides the source code207for the application107being analyzed. The analysis module201, by referring to the corresponding source code207, can map specific streamed code pages101back to specific program functionality, at least roughly. In some embodiments, some or all of this mapping data209is entered by, for example, the application developer205, who has access to both the source code207, and the usage data102which indicates the code pages101to be mapped.

It is to be understood that how much of the mapping is performed automatically by the analysis module201, and how much is input by, e.g., an application developer205, is a variable design parameter. The implementation mechanics of performing such mapping based on application usage data102and corresponding source code207are within the skill set of one of ordinary skill in the relevant art, and the usage thereof within the context of the present invention will be readily apparent to one of such a skill level in light of this specification.

By referring to both the mapping data209and the collected usage data102, the analysis module201can create application usage profile data211by determining how different components of the application107are being utilized (which components, how often, when, by whom, where, etc.) Specific analysis can determine factors such as how often an application107terminates without passing through expected code pages101(e.g., exit and cleanup routines), and what code was executing at the time of termination. This indicates under which circumstances an application107is abnormally terminating or crashing. This information can be used, for example, to drive additional testing or evaluation of the relevant components. Analysis can also indicate conclusions such as which features of an application107are popular (i.e., those features corresponding to frequently streamed code pages101), which generate error conditions (i.e., those corresponding to code pages101streamed prior to the streaming of error processing code101) and which confuse users (indicated by factors such long user pauses or failure to make a selection when encountering certain menus and such.) Of course, these are only examples of the type of analysis that can be performed. Other examples will be readily apparent to those of ordinary skill in the relevant art in light of this specification. For example, usage analysis can be performed by user, by company, by geo-location, by time of day, by month, etc.

The implementation mechanics of performing such analysis based on application usage data102and corresponding mapping data209are within the skill set of one of ordinary skill in the relevant art, and the usage thereof within the context of the present invention will be readily apparent to one of such a skill level in light of this specification.

As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies and other aspects of the invention can be implemented as software, hardware, firmware or any combination of the three. Of course, wherever a component of the present invention is implemented as software, the component can be implemented as a script, as a standalone program, as part of a larger program, as a plurality of separate scripts and/or programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Furthermore, it will be readily apparent to those of ordinary skill in the relevant art that where the present invention is implemented in whole or in part in software, the software components thereof can be stored on computer readable media as computer program products. Any form of computer readable medium can be used in this context, such as non-transitory, magnetic or optical storage media. Additionally, software portions of the present invention can be instantiated (for example as object code or executable images) within the memory of any programmable computing device. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.