AU780200B2 - Method of reporting a problem in a network session with added user friendly features - Google Patents

Description

AUSTRALIA

Patents Act COMPLETE SPECIFICATION

(ORIGINAL)

Class Int. Class Application Number: Lodged: Complete Specification Lodged: Accepted: Published: Priority Related Art: Name of Applicant: ResQNet.com, Inc.

Actual Inventor(s): Todres Yampei, Gad Janay Address for Service: PHILLIPS ORMONDE FITZPATRICK Patent and Trade Mark Attorneys 367 Collins Street Melbourne 3000 AUSTRALIA Invention Title: METHOD OF REPORTING A PROBLEM IN A NETWORK SESSION WITH ADDED USER FRIENDLY FEATURES Our Ref: 640263 POF Code: 341353/456054 The following statement is a full description of this invention, including the best method of performing it known to applicant(s): -1- METHOD OF REPORTING A PROBLEM IN A NETWORK SESSION WITH ADDED USER FRIENDLY FEATURES RELATED APPLICATION This application is a continuation-in-part under 37 C.F.R. 1.53 of Application Serial No.

09/490,614, filed on January 25, 2000.

STECHNICAL FIELD OF THE INVENTION This invention relates to network service, more particularly, to a method of reporting an activity at a terminal in a session over a network.

BACKGROUND OF THE INVENTION During a session of online service, if the terminal user needs help when he encounters a problem, he usually is required to report the problem by sending an email message to an email address of the service provider. In the message, the user is supposed to describe and explain what has happened in his session. Sometimes a selection from a list of subjects is also required to be included in the subject field of the email so that the service provider can process the email reports more quickly. The email messages may be sent to the service provider (usually to its help group) through an email client or through the website of the service. The help personnel solely relies on the content of the email message drafted by the user. This is sometimes a tough task because users often cannot explain their problems clearly or professionally. This problem compounds when a user is not good in the same language of the service provider and this is not uncommon to Internet services where the users can be anywhere in the world.

Further, when a new version of software comes out, it is quite common to invite a test population to try a beta version and report problems encountered so as to find bugs in the software. The testers are required to report to the software provider by email in which the encountered problems are explained in text. The software provider relies solely on the text descriptions from the testers. Same as in the online services, it is a hard task for the software provider to figure out what has actually happened to a user if the description is not easy to understand.

Legacy mainframe computers are still in use because of the huge costs to replace them o• with up-to-date techniques. PC or thin clients, such as palm pilots, are used as a terminal emulator to a dumb terminal formerly used in the legacy mainframe systems so that a user at the terminal can interface with the legacy mainframe through PC or thin client. This is usually implemented through a server arranged between a legacy mainframe and its terminal emulators over a network. The terminal users can communicate with the server by HTML pages or other contemporary applications such as windows applications.

When a terminal user needs help while encountering a problem during his session, he S. -may communicate with a support group of the legacy mainframe system to explain the problem.

15 This communication may be done in a traditional way by telephone or fax, or, with the help of modern techniques, may be communicated over the network as an electronic mail message.

However, the help group has to rely solely on the description of the problem from the user to figure out the actual problem and find a solution. This will be a tough task if the user cannot explain the problem clearly.

In reporting some other activities in a network session provided by a service provider, the service provider also hopes to acquire a history of the activities in the session so as to have plenty of information for the purpose of studying and analyzing the activities in the session, but not otherwise solely relying on a probably unclear text report from the terminal users.

In view of the above problems in the prior art, there exists a need for an effective way to report an activity in a session to a service provider so that the service provider has enough and correct information to study and analyze the activity quickly and precisely.

SUMMARY OF THE INVENTION Viewed from one aspect, the invention provides a method of synchronizing screens associated with a software application running on a computer with representations of such screens being displayed on a remote terminal, the method including the steps of: transmitting screens from the computer to the terminal; displaying a representation of each screen to a user of the terminal; and if the user of the terminal attempts to respond to a representation of a screen which is not in synchronization with the screen sent from the computer, advising said user of same prior to said response that is out of synchronization being transmitted to the computer.

Viewed from another aspect, the invention provides a server for facilitating o S 15 synchronization between screens output and received by a computer and representations of those screens displayed on a user terminal for interaction with a terminal user, the server S• including: first processing apparatus for storing information associated with each of said screens output from the computer and displayed on the terminal; 20 second processing apparatus for processing responses to said representations on said terminal prior to said responses being transmitted to said computer; and detection means, said detection means being configured to ascertain whether said responses are responses to a screen, the representation of which does not correspond to the Smost recent screen sent to the terminal from the computer.

Viewed from a further aspect, the invention provides a method of providing information regarding a data session between a computer and a terminal to a remotely located entity, the method including: storing a history of said session in the form of plurality of sequential representations of screens displayed on said terminal; and upon request by a user, sending a report on a problem encountered by said user to said remote entity along with a plurality of stored representations, the stored representations being at least partially masked or altered to conceal specified information from said remote entity.

W:UAymPatemtsSPEC AEG\3333-01 OC Viewed from a still further aspect, the invention provides an apparatus for reporting a problem encountered by a terminal emulator which displays representations of screens generated by a computer, said apparatus including: means for receiving a command requesting that a plurality of screens generated by said computer and displayed by said terminal are to be forwarded to a third party; and means for prompting a user of said terminal to mask or alter or highlight certain specified ones of fields contained within a representation of at least one of said screens forwarded to said third party.

Viewed from another aspect, the invention provides a method of displaying information generated by a computer on a terminal including the steps of: receiving a screen of information from said computer, said screen including a moving or blinking indicator; and displaying the moving or blinking indicator as a static indicator, thereby facilitating display on a terminal not capable of displaying moving or blinking indicators.

15 The above problems are solved in accordance with the present invention. When a report on an activity in the session is provided to a service provider of the session, the stored history of the session is also sent to the service provider with a report on the session S activity. The service provider can analyze the session activity not only relying on the description by the terminal user, but also relying on the history of the session. Preferably, the session history may be stored in HTML pages which are easy to read.

~In a preferred embodiment, in the activity report is a report on the problem encountered by the terminal during the session, a window will pop out on the screen of the terminal when the problem happens, and the report of the problem together with the session history may be triggered to be sent to a help group of the service provider by clicking on a S 25 command button in the window.

In another embodiment, the window may include a space for typing in a text message describing the activity or the problem. The message is sent to the service provider or the help group as an email together with the session history as an attachment of the email. Thus, the service provider or the help group sees a history of the session, preferably in HTML pages.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a schematic view showing an embodiment of the present invention as W:WyssPtetsSPEC AEG\33383-01 doc incorporated in a legacy mainframe system; and Fig. 2 is an exemplary screen associated with the "back on track" feature of the present invention.

DETAILED DESCRIPTION OF THE INVENTION Fig. 1 shows a legacy mainframe system as an embodiment of the present invention. A server 2 communicates between a legacy mainframe host 1 and its terminal emulators 3 over a network 5. Terminal emulators 3 may be PCs or thin clients such as palm pilots. Server 2 makes i it possible, that the legacy mainframe can remain unchanged, the terminal emulators may perform tasks using contemporary tools to enhance operation of the system. For example, the server 2 can change the green screens that were normally shown to a dumb terminal from the legacy mainframe host in the past into HTML screens shown to a terminal emulator such as a PC or a thin client. The users at the terminal emulators communicates with the server 2 by inputting commands in the HTML screens. The server 2 and terminal 3 combine to form a dumb terminal 15 interface to the legacy system.

A help group, called "help desk" 4, also communicates with the terminal emulators 3 to provide help to the users. while they encounter. a problem during a task session. Preferably, the help desk 4 also communicates with the terminal emulators 3 over the network During a session conducted by a user, all the HTML pages in both directions to and from the server 2) that the user has communicated with the server 2 are automatically stored as a file in the server 2 as a record of the history of the session.

An identifier may be specifically designated to said session so that the file for the session may be easily located from the server 2. For example, a session ID may be designated to the session and the file may be located from this session ID.

When a problem occurs during the session, a window will automatically pop out at the screen of the terminal emulator. The screen may also pop up in response to a user command. A command button is included on the window in addition to the brief description of the problem.

Clicking on the command button will automatically send a report of the problem to the help desk over the network.

Preferably, the window also includes a space on which the user at the terminal emulator o may key in a text message to further explain the problem. The text message is automatically sent i to the help desk as an email message by simply clicking on the command button.

1 0 Preferably, clicking on the command button not only sends a report as an email message to the help desk, but also triggers the server 2 to automatically locate the stored HTML pages for the session and send it to the help desk. The HTML pages may be sent to the help desk as an attachment of the email message sent from the terminal emulator.

i: As an alternative, the HTML pages are not sent to the help desk together with the report, 15 but are retrieved by the help desk upon receipt of the report on the problem sent from the terminal emulator. Of course, the session ID is also included in the report so that the help desk can locate and retrieve the history -(the-HTML pages of the session) from the server2 Preferably, only the current HTML page is attached to the message sent to the help desk and the help desk can -retrieve other pages by browsing the whole connection session. This browsing can be done by clicking on buttons "Next", "Previous" or the like as well as activating various filtering check box options such as "View client-sent pages only", "View server-sent pages only" or "View all", etc. In this way, the user's help request can reach the help desk as a smaller file while the help desk only needs to retrieve the recorded pages useful to him. The whole reporting and analyzing process of the problem can be more effective.

If necessary, the history may be stored at another server maintained by the help desk specially for the purpose of providing help to the terminal users instead of the server 2 which usually works for the purpose of communications between the legacy mainframe I and the terminal emulators.

The session history may also be stored at the terminal emulator if it is possible. For example, if the terminal emulator is a PC with enough storage capacity, the history may be simply stored in the PC. This will simplify storing the history and sending the history together with the report of the problem by simply clicking the command button in the window. A special simple software may be designed for this purpose. No specific session ID designating or matching system is necessary, but may nonetheless be included.

With the HTML pages that represent is the history of the session, the help desk can easily and precisely analyze the problem encountered by the terminal user in the session. The users are not necessarily required to be skilled in preparing a precise report of the problem to the help 15 desk. Language is also not a serious obstacle in reporting the problem. In fact, it is possible, at least to some extent, that the help desk may analyze the problem solely based on the HTML pages or other form of the history-record. without-any. comments from- the-user-on the .problem...

What the user is required to do is only simply click on the command button on the pop window to send the session history to the help desk when a problem happens. This -action. may automatically generate a help request. Additionally, the size of the history stored, full session, last few HTML pages, several sessions), may be selectable by the help desk and/or the user or any other entity.

As an alternative, the user may send a report by simply striking a command key on his keyboard when he encounters a problem in a session, instead of clicking on a command button in a pop window. In this case, no window is necessary. The user may also send a text message to report his problem, together with the session history stored in his computer or in the server 2.

The network 2 may be a LAN, WAN or Internet.

Even though a legacy mainframe system has been taken as an embodiment of the invention with detailed description, it is appreciated that the invention has its broad applications to other types of sessions. For example, it can be used in any online services for a user to report his problems to the service provider so as to get instructions from the service provider to solve .*his problems. It can also be used in beta testing for software or online services.

1o It shall be fiirther appreciated that the present invention is not limited to its application in problem reporting during a network session, it can also be used in reporting any other activities or events happened or conducted in a network session. For example, it can be used in productivity reporting and in audit trailing.

In reporting the productivity of a session, aside from the HTML images being stored as the session history, the information such as date of creation, time of creation, direction flag (in or out), user ID (available from log on) and elapsed time from sending to receiving the reply, and so on, may- -also- be -recorded.- With- this information, -the- service -provider can- conveniently and accurately study and analyze the performance of the session, including the productivity of the session, which can be obtained by analyzing the elapsed time per use -as reported. -This can be narrowed down to particular screens. For example, by analyzing the elapsed time from the time the user received the screen until he/she replied, the "thinking time" can be obtained which may be the time it took the user to fill out a form or to complete an online survey. The same, of course, can also be apphied in studying the effectiveness of a training session, a documentation revising session, or a screen revising session, etc.

By studying the elapsed time from the time the user sent a reply and the time he/she received the next screen, the performance of the server components can be studied, especially if applied to so called "stress testing" where the number of active uses increases dramatically.

Time stamps on the help request message and the HTML pages provide additional of information for studying the performance of the help desk and can assist in identifying peak hours, staffing requirements, etc.

A further advantage in recording a session history in HTML pages resides in that HTML is all searchable text. This is helpful in some applications such as audit trail. By setting up a query to focus on the recorded history that contains the particular screen in question, and printing out the screen pages in both directions presented from the server to the user and sent to the server from the user), it is quite easy to find out what were the original values, what the new values are, and most importantly, who and when the updates were performed.

There are enhancements available to improve the user friendly features of the invented 5 technique. One such enhancement involves the use of server 2 in order to help a user keep his screens displayed by his Internet browser in synchronization with the application program being run-on legacy mainframe- More -specifically;- the typical--interaction between- -the-user- and legacy mainframe 1 includes a plurality of applications screens which are transmitted between the user and the application program running on legacy mainframe 1. Each of these screens conveys information and accepts as input other information from the user.

The browser which is running on terminals 3, however displays these pages as HTML pages, and the HTML pages may be navigated sequentially in accordance with the operation of most standard browsers. For example, in the well-known Internet Explorer by Microsoft Corporation, there is a back button and a forward button. When these buttons are pressed, the browser will move, in the case of the back button, to the previous screen display. If the back button is pressed again, it will move even further back to a still previous screen. The user may navigate through the screens, however, the application running on legacy mainframe I would not be aware of any such navigation back and forth.

A particular error which could occur as a result of the user moving between the screens, is that the screens could be out of synchronization with the screens that the application is *presently processing. Specifically, consider that the application transmits the screen to the user, and the user interacts with that screen as an HTML page at terminal 3. A response is sent to the application and a new screen is downloaded. After four or five screens, the user may then use his browser to back-up four screens and examine what happened four screens ago. When the user moves forward again, he may inadvertently only move forward three screens, and believe that he is on the present screen. Thus, the user begins operating on the third screen to transmit to 1 the application through the server as previously described, but the application will produce an 5 error because it is expecting to receive information consistent with the fourth screen being displayed. This is because the legacy application is arranged to still be communicating with what it thinks is-a dumb terminal displaying thefouirth-scteeii. In accordance with the present invention, the "back on track" feature may be utilized in server 2. Specifically, the server keeps track of information associated with each screen being transmitted down to terminal 3 from mainframe 1. A screen ID or other identifying information may be maintained. If, at any time, the data returned from terminal 3 indicates that the user of terminal 3 is erroneously interacting with the HTML representation of the wrong screen the HTML representation is out of sync with the real application screen), the server will intercept that and recognize that the screen is incorrect. Moreover, since the server may maintain a copy of the screens itself, it could transmit the proper current application screen to the user in order to get the user "back on track." Fig. 2 shows an example of the error message that the server would transmit down to terminal 3 in the event synchronization problem described above is encountered. The arrangement of Fig. 2 would also be displayed as an HTML page on terminal 3, and clicking on the "back on track" icon will automatically cause the server 2 to send the appropriate screen to the terminal 3 for processing. The retransmission of the appropriate screen will synchronize the HTML representation which terminal 3 is displaying with the corresponding screen that the application in legacy mainframe 1 is presently expecting to be processed at terminal 3.

With still an additional enhancement, the archiving of plural HTML screens can be sent to the help desk, supervisor or other personnel, with one or more fields masked or highlighted.

Specifically, the user may desire to send only certain screens to the help desk, but he may also desire to send screens to the help desk with certain one or more fields removed. For example, consider an accounting firm that is encountering problems with a particular legacy mainframe application. They may wish to send a history of screens to the help desk albeit with the numbers in certain- of the fields on-the screens blocked-out- This woutd ptotect client's corifidelitialinformation while still allowing the screens to be sent to the help desk so that the help desk could analyze the order in which things were done and the particular problem which arose. Of course, it is very unlikely that the help desk would need the particular numbers, or the individuals name in name field, in order to analyze the problem.

In accordance with the present invention, when the user desires to send the history of the help desk, he may block out certain fields with "dummy" numbers, or with a mask. The system may automatically prompt the user for instructions to do so. If a user indicates such a desire, the screens to be transmitted would first be sequentially displayed to the user, where he may use his mouse and/or other keys to block out certain fields solely for purpose of transmission to the help desk. The fields would not actually be altered, however, server 2 would artificially mask these items prior to transmission to help desk 4 or other outside personnel not privy to confidential information.

Still another enhancement relates to improving the user-friendly features of displaying information on a thin client terminal 3. Specifically, many such thin clients do not have advanced display capabilities such as extended HTML, and may only be able to display static information. Thus, if the legacy mainframe application includes an item such as a blinking or moving cursor, it will not be displayable on certain thin clients.

In accordance with the present invention, server 2 will examine the characteristics of any particular screen, and determine a field designator. The field designator may be in the form of a i rblinking or moving cursor. That blinking or moving cursor will be translated into a large static designator such as a large arrow pointing to the particular field. The screen could then be displayed at terminal 3 in an HTML format which includes no blinking cursor, but instead a static- arrow- pointing- to the position wher' the -ctcsor should be. The static arrow may be displayed by even the most basic of thin clients which cannot display a blinking cursor or moving object.

From the foregoing, it will be observed that numerous variations and modifications may be effected without departing from the true spirit and scope of the novel concept of the invention.

For extmple, the history may be stored as a form other than HTML pages. For instance, the commands inputted by the user in a session may be stored as the record of the history. In fact, only the contents in a session history that are helpful in analyzing the activities or problems in the session are of importance to the help desk or the service providers. Thus, only specified portions of the HTML pages could be extracted and sent to the help desk. Storage can be saved and the whole process is more effective.

It is intended to cover by the appended claims all such modifications as fall within the scope of the claims.

Claims (12)

1. A method of synchronizing screens associated with a software application running on a computer with representations of such screens being displayed on a remote terminal, the method including the steps of: transmitting screens from the computer to the terminal; displaying a representation of each screen to a user of the terminal; and if the user of the terminal attempts to respond to a representation of a screen which is not in synchronization with the screen sent from the computer, advising said user of same prior to said response that is out of synchronization being transmitted to the computer.

2. The method of claim 1 further including the step of displaying on said terminal an appropriate actuator to resynchronize said terminal and said computer after said user S: 15 attempts to respond to said out of synchronization screen.

3. The method of claim 1 or claim 2 wherein said screens are transmitted from said computer to said terminal through a server over a data network. 20

4. The method of claim 3 wherein a screen is transmitted from the server to the Sterminal in order to resynchronize the terminal with the computer upon a request for such resynchronization being entered by said user.

The method of claim 4 wherein said user selects the actuator in order to request resynchronization.

6. A server for facilitating synchronization between screens output and received by a computer and representations of those screens displayed on a user terminal for interaction with a terminal user, the server including: first processing apparatus for storing information associated with each of said screens output from the computer and displayed on the terminal; second processing apparatus for processing responses to said representations on said terminal prior to said responses being transmitted to said computer; and W:VlynPaterftSPEC AEGQ3383-O .doc 13 detection means, said detection means being configured to ascertain whether said responses are responses to a screen, the representation of which does not correspond to the most recent screen sent to the terminal from the computer.

7. The server of claim 6 further including storage means for storing a copy of the screens or the representations of said screens as they are exchanged between the computer and the terminal and for forwarding a representation of the most recent screen sent to the terminal from the computer if it appears that the terminal has responded to the representation of a different screen.

8. A method of providing information regarding a data session between a computer and a terminal to a remotely located entity, the method including: storing a history of said session in the form of plurality of sequential representations of screens displayed on said terminal; and 15 upon request by a user, sending a report on a problem encountered by said user to said remote entity along with a plurality of stored representations, the stored representations being at least partially masked or altered to conceal specified information from said remote entity. 20

9. The method of claim 8 wherein said partial masking is selectable by the user in response to automatic prompting via said terminal through a remote server. Apparatus for reporting a problem encountered by a terminal emulator which displays representations of screens generated by a computer, said apparatus including: means for receiving a command requesting that a plurality of screens generated by said computer and displayed by said terminal are to be forwarded to a third party; and means for prompting a user of said terminal to mask or alter or highlight certain specified ones of fields contained within a representation of at least one of said screens forwarded to said third party.

W:PAIsaPT entsSPEC AEGQ3383-0 .doc

11. A method of displaying information generated by a computer on a terminal including the steps of: receiving a screen of information from said computer, said screen including a moving or blinking indicator; and displaying the moving or blinking indicator as a static indicator, thereby facilitating display on a terminal not capable of displaying moving or blinking indicators.

12. Apparatus of claim 11, wherein said indicator is that of a cursor position. DATED 12 January, 2005 15 PHILLIPS ORMONDE FITZPATRICK Attorneys For: ResQNet.com, Inc. *0 o 00 o*o oooo W:AynsaxPaentSPEC AEGM3383-01.dc