1. The Field of the Invention
The present invention relates to software failures. More specifically, the present invention relates to controlling software failure data reporting for use in determining the cause of a software failure, and to controlling software failure data responses.
2. Background and Related Art
Prior to being released to consumers, software generally undergoes a significant amount of testing to identify and correct failures. One type of failure is a crash, in which executing software terminates. The executing software may be an application, an application component, the operating system, an operating system component, etc. Crashes can be frustrating to users because generally they have some impact on productivity. In some cases, not only must the operating system or application be restarted, but recently completed work also may need to be repeated because it was lost during the crash.
Another type of failure is a setup failure. Setup failures occur during installation of a program module onto a user's computer. Setup failures may prevent certain aspects of the program module, or even an entire application, from being installed on the user's computer.
Software failures also tend to create a significant amount of work for the product support personnel who are tasked with diagnosing and solving the problem that led to the failure, often with a rather limited amount of information received from a user over the telephone. In the past, although there may have been a significant amount of information on the user's computer that could be useful to product support personnel or software developers in diagnosing the failure, without being physically present at the user's computer, this information has not been extracted and analyzed in as useful a fashion as possible.
Recently, however, techniques for gathering information about a failure at a client computer have been explored. While gathering failure data has been helpful in diagnosing the cause of failures, including crashes, setup failures, etc., certain problems with traditional approaches have not been addressed adequately. For example, current techniques generally do not sufficiently account for privacy considerations. In some cases privacy considerations may involve proprietary information that a business is unwilling to share outside of its organization. Privacy considerations also may involve government regulations for certain financial or medical information, or simply may reflect a desire to safeguard personal information, such as in an effort to prevent identity theft or other fraudulent uses of personal information. Whatever the motivation, there now is a need to control software failure data reporting.
Another problem with traditional approaches relates to software failure data responses. Once the cause of a failure has been diagnosed, a fix or workaround may be sent to the client. The response may take the form of instructions or a software update or a combination of both to correct or avoid the failure. Naturally, different organizations have different levels of sophistication, and typically have different and conflicting policies with respect to software failure data responses.
On the other hand, it may be necessary to request additional information from a client in order to make a diagnosis. In addition to the potential privacy considerations identified above, traditional approaches have not permitted organizations a sufficient amount of control with respect to software failure data responses that request additional information. As a result, some responses simply may not be appropriate for certain organizations.
Traditional approaches also have failed to offer scalable implementations. Among other things, traditional approaches have overloaded individual processes with otherwise independent tasks and have failed to take advantage of database technologies that offer improved performance, creating various processing bottlenecks. Furthermore, without the abilities to customize as discussed above, extra processing must be performed where none is needed, wasting valuable computing resources. Accordingly, for relatively large customers with many clients, limited customization options have caused failure data reporting and failure data responses to impose a fairly significant burden, at least some of which may be unnecessary.
USPTO Backgrounds
USPTO Backgrounds