Support interface module bug submitter

A method for submitting a bug report utilizes a bug submission module to request a bug submission service from a first support host using a Support Interface Module for communicating with the first support host. The bug submission service includes a list of data to be collected and the return address of a second support host. The first support host also includes a support services resource. The bug submission module receives the requested bug submission service from the first support host using the Support Interface Module and collects data based on the list of data to be collected. The bug submission module then sends the collected data to the return address of second support host using the Support Interface Module.

FIELD OF THE INVENTION

The present invention relates generally to the field of computer science. More specifically, the present invention relates to a support interface module bug submitter over which channels of information can flow between an application interface and an external support service.

BACKGROUND OF THE INVENTION

Despite the advancement of technology, users continue to experience problems with computer systems. Support may then be needed. Support may include a number of services including an explanation of features or the trouble shooting of problems. Traditional support takes many forms. For instance, support may take the form of a user manual. Many users find these little help at all if they can even locate the manual when they need one. To combat this, support may take the form of an embedded help function. This may be query or menu driven. Again this is a form of self-help and it is limited to the time when the function is fixed in the application. To reduce time dependency and memory demands, support may take the form of a dedicated help server external to the application. Increasingly, applications and users are connected together by networks such as the Internet. In this case, the user leaves the application and, via the network, contacts the help server independently and seeks the support that they need there. If this does not prove adequate, the user may phone a dedicated help provider and speak with one of their representatives or listen to their automated service. Individually or in combination, traditional forms of support may often prove unsatisfactory to the user.

A bug is a persistent error in a software or hardware. One way to get rid of the bug it to modify the program, usually with a software patch for software. A bug report consisting of data describing the error that occurred, may be submitted to a support provider or the software developer. The support provider once notified of the bug, may then prepare a software patch or a new version of the software removing the bugs previously found.

A definite need exists for a bug submission module allowing the user to select how and where a bug report is submitted. A primary purpose of the present invention is to solve these needs and provide further related advantages.

BRIEF DESCRIPTION OF THE INVENTION

A method for submitting a bug report utilizes a bug submission module to request a bug submission service from a first support host using a Support Interface Module for communicating with the first support host. The bug submission service includes a list of data to be collected and the return address of a second support host. The first support host also includes a support services resource. The bug submission module receives the requested bug submission service from the first support host using the Support Interface Module and collects data based on the list of data to be collected. The bug submission module then sends the collected data to the return address of second support host using the Support Interface Module.

DETAILED DESCRIPTION OF THE INVENTION

Turning first toFIG. 1, a block diagram of a bug submission system100is shown. The system100includes a host system102, a first support host104, and a network106connecting the host system102to the first support host104. One of ordinary skill in the art will recognize that the network106may take one of many forms. For the sake of clarity, these will not be presented here. The host system102includes at least one application having an interface108for the user. The application may also take many forms including word processor or network browser. Likewise, the outward manifestation of the interface108may take many forms but will typically be a graphical user interface. The interface108includes a bug submission module110that enables the user of the application to submit a bug report for a particular module111having a bug. The bug submission module110is described in more detail below. In addition, the bug submission module110communicates with and through a support interface module (SIM)112. The SIM112may be integral to the application, to the host system102, or to some combination of both. In some contexts, the SIM112may not be referred to as a module but will still perform the same functions. The SIM112provides the infrastructure over which channels of information can flow between the host system102and the first support host104. The first support host104includes a support services resource114that is called upon to help submit the bug. In one specific embodiment, the support services resource114includes a bug submission service having a list of data to be collected on the host system102and the return address of the support host that the list of collected data will be sent to when that service is selected. The collected data can either be sent to the first support host104or to a third party support host, such as second support host116. The destination of the collected data depends on the user's choice of service. The user should only view the result of the collaboration between the bug submission module110and the SIM112. The result is a bug submission presence within the application itself.

In order for the SIM112to configure and manage the communication of data from the bug submission module110to the first support host104, the SIM112may need information such as the address of the support services resource114, the type of communication protocol to be used, the port to contact and the eligibility of use of the support services resource114. The SIM112can obtain the necessary information in at least one of three different ways. Two of these methods rely on the use of description facilities while the third requires no description searching.

According to one embodiment, the SIM112can contact a support services registry for information on a service. The location of the support services registry can be predetermined or an address for the registry can be provided by an outside source. Among other information, the registry will contain information on whether a service exists, where it is located, and who may use it.

According to another embodiment, the SIM112may contact a service description servlet at the instruction of the bug submission module110. The SIM112looks in a location specified by the bug submission module110for information regarding a particular service. The service description servlet will then pass on the information in a format similar to the one found on the support services registry.

According to a yet another embodiment, the SIM112may, on occasion, find that the bug submission module110itself contains all of the information needed. If so, the SIM112utilizes the information provided by the bug submission module110without reference to a registry or description service.

There are a number of general attributes that one might want the SIM112to exhibit. If one or more of these attributes are contrary to one another or to the specific environment, then they can be deleted or modified. One would prefer that the architecture of the SIM112be able to provide seamless communication between the user and the support services resource114. Further, one would prefer that the SIM112be aware of the networking environment in which it resides. This awareness might include knowing which ports are accessible, what the various latencies are, what bandwidth is available, and what the current traffic load is. Further still, one would prefer that the SIM112be able to ensure the security and integrity of all of its communications with the first support host104. Either continuously or on demand, one would prefer that the user be able to monitor the activity of the SIM112. One would also prefer that the SIM112be able to correct for failed communication links or at least be able to present the user with options in such an event. The SIM112may communicate with one or more of any number of communications protocols in either or both a synchronous and an asynchronous mode.

Turning now toFIG. 2, a block diagram of the bug submission module202and the Support Interface Module204ofFIG. 1is shown. The SIM204is shown to include a session handler206, at least one session208, a transport handler210, and at least one transport212for each session208. Each component plays a role in the process of communication between the bug submission module202and the support services resource114ofFIG. 1. Each component may be independent of one another or the SIM202. Conversely, the function of each component may be combined in whole or in part without departing from the inventive concept disclosed herein. The session handler206provides coordination of the one or more sessions208that are ongoing. The transport handler210provides coordination of the one or more transports212per ongoing session208.

One example of a communication process by the bug submission module202assumes that a user makes a request, then the bug submission module202initially processes this request. It may be the case that the bug submission module202can handle the request alone. When the bug submission module202can not handle all or some portion of the request alone, then it contacts the SIM204. The SIM204passes the request to the session handler206which approves the request and generates at least one session208for the request. The session208in turn initializes the transport handler210for the communication required to deal with the request. The transport handler210generates at least one suitable transport212for the session208. The transport212sends data to and/or receive data from the support services resource114ofFIG. 1. It may be the case that the transport handler210is instructed to redirect the communication. In such a case, the transport handler210may generate a new transport212and terminate the original transport212. Through its API, the session208cooperates with the bug submission module202to satisfy the user's request. Consequently, after the initial request, all subsequent communication by the bug submission module202for the request is with the session208and not with the session handler206. When the request of the user is either satisfied or withdrawn, some or all of the sessions208and the transports212that were generated for that request may be terminated. Multiple requests may be processed in sequence or in parallel.

As above with the SIM204in general, there are a number of general attributes that one might want the components of the SIM204to exhibit. If one or more of these attributes are contrary to one another or to the specific environment, then they can be deleted or modified. For example, one would expect that the session handler206would be aware of all of the sessions208that are generated. Further, one would prefer that the session handler206hold data about the host system102and the network106ofFIG. 1. Also, one would prefer that the session handler206be aware of the network activity originating from the host system202. In addition, one would prefer that the session handler206use this network activity awareness to scale its own network activity to avoid significant performance loss to the host system102. It would also be preferred that the session handler206to be able to provide information regarding or correction of communication failures. Further still, one would prefer that the session handler206be able to provide status info for each session208either continuously or on demand.

It may be the case that a host system102includes multiple SIMs204. In such a case, it may be necessary to coordinate the individual SIMs204. This may be accomplished in a number of ways known to one of ordinary skill including disabling all but one of the session handlers206and placing the non-disabled session handler206in control of all of the SIMs204. Another technique would be for the multiple session handlers206to hold an election to determine which session handler206will control the multiple SIMs204.

With respect to the sessions208, although there may be multiple sessions208running in series or in parallel, the individual sessions208may not be aware of one another. Further, one would prefer that the sessions208have a finite length and that either or both the session handler206and the bug submission module202be able to terminate the session208. One would prefer for the session208to control communications between the SIM204and the bug submission module202.

With respect to the transport handler210, one would expect that the transport handler210would be aware of all of the transports212that it has generated. If there are multiple SIMs204, a first transport handler210may or may not be aware of a second transport handler210or the transports212that the second transport handler210has generated. Further, one would expect the transport handler210to be able to communicate using one or more of any number of protocols. One would prefer that the transport handler210be able to generate diagnostic information on the network environment and characteristics and be able to pass this information on to the session handler206. One would also prefer that the transport handler210be able to report errors and exceptions to the session handler206.

With respect to the transports212, although there may be multiple transports212in series or in parallel, the individual transports212may not be aware of one another. It may be the case that the transport212is channel dependent such that when the channel fails the transport212ends and a new transport212may have to be generated by the transport handler210to complete the failed communication.

According to one embodiment of the present invention, the Bug Submission Module202provides the user with several options. For instance, prior to submitting the bug, the user is presented with an opportunity to troubleshoot the problem (which will also automate the problem description), and review and approve any data collected. If the user chooses to submit the problem, an acknowledgement of the submission is provided. Once the context of the bug (the relevant module) is known, the Bug Submission module202presents the SIM services available for that module. Thus the SIM204may be used to invoke other arbitrary SIM services in the process of submitting a bug. This allows for more features to be embedded dynamically into the Bug Submitter module202.

The Bug Submitter Module202submits its bug report through the SIM112and network106. One of ordinarily skill in the art will realize that there are many ways in which the SIM112may communicate with network106. For example, SIM112may submit the bug reports via SOAP (over HTTP and SMTP). Additionally, the bug submission module202may provide an API for module developers to use their own transport mechanisms. According to one embodiment, the bug submission module202may not use SOAP but may simply open a Socket connection to transport the data to a support host. This would allow the use of third party toolkit vendors for an easy and extensible mechanism for transporting data. Since SOAP messaging is not bi-directional, the Bug Submission module202may rely on the SIM architecture to provide message acknowledgements where possible.

According to one embodiment, the bug submission module202comprises a receiver (not shown) for receiving a submission service using the SIM112to communicate with the first support host104. The submission service comprises a list of data to be collected and the return address of a second support host. A collector (not shown) collects the data based on the list of data to be collected. A sender (not shown) sends the collected data to the second support host116using the SIM112.

The bug submission module202may also incorporate a data collection service and a data delivery mechanism. The data collection service provides mechanisms for gathering information commonly requested by support engineers, as well as a mechanism for module developer to add data requirements for their reports. The data delivery mechanism may utilize a portion of a Support Services Interface Module API to transfer the collected data to a destination in the appropriate format.

According to one embodiment, with respect to the data collection service of the bug submission module202, each report template should have specific information to collect. All automated data collectors may include a collection timeout. A call to retrieve collected data should either return the data when the collection is completed or set the data state to a failed status. The API for data collection should allow for module developers to provide custom report templates and data collection that follows the previously listed preferences. The collected data may include, by way of example, requests for user supplied data such as steps to reproduce, or support contract information. Such user supplied data should distinguish empty input from a failure to acquire input. All data collected should be associated with a data presenter appropriate for the user environment.

According to one embodiment, with respect to the data submission mechanism of the bug submission module202, the data may be submitted only to the destination accepted by the user. Such destination should have at least one transport. However in case of failure, more than one transport may be used. The transport may specify a protocol and address for the transmission of the data. The destination may provide information to prove its identity to the user. The destination may attempt to use alternate transports prior to failing completely. The destination may also attempt to confirm transmission. In the event of a complete transmission failure, the bug submission module202should allow for retransmission or the specification of a new destination.

Turning now toFIG. 3, a flow diagram of a method for submitting a bug report according to the bug submission module202is shown. In a first decision block302, a bug is detected on the host system102ofFIG. 1. When a bug is detected, the bug submission module110ofFIG. 1receives a notification about the presence of the bug. The Bug Submission module110then requests a Bug Submission service from a first support host104in block304. In response to the request, the requested Bug Submission service110is received in block306. The Submission Service comprises a list of data to be collected and the return address of a support host. In block308, the bug submission module110collects data based on the list of data to be collected as specified in the requested submission service. The bug submission module110submits the collected data via SIM112to the support host as specified in the submission service in block310. The support host may either be the first support host104or another support host such as second support host116.

According to another embodiment, the SIM may provide for a Collector class (not shown) to developers. Collectors are intended to obtain data from the user or the environment. Those collectors that retrieve information from the environment (the user's system) will be required to be able to run more than once, such that if a user accidentally overwrites the collected data, it can be retrieved once again. If it is not possible for the value to change between runs, it is acceptable for the Collector to simply cache and return the last value obtained.

According to another embodiment of the present invention, after all data collection has been done, each piece of data will be presented to the user. Each piece of data will be associated with a Presenter, either because the data has a known MIME type associated with a presenter, or because the collector has associated this piece of data with a specific Presenter instance. It is a design goal to keep this API generic enough to be used from the command line.

One feature of the SIM bug submission module is the ability for third parties (Support Providers) to leverage the features for their customer base and support staff. Developer support may also include example codes and extensive base classes where applicable.

According to another embodiment, all bug reports (regardless of the report structure) must be compatible with a to-disk Transport provided by the SIM bug submission module. Basically this means that the bug report must be able to be saved to a file. The files should be designed so that they can be sent using a different user and machine than that which generated the report.