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

Abstract

A method of reporting an activity by a terminal use in a session over a network. The history of the session is stored in a server or the terminal. When a report on the activity is required, the stored history is provided to a service provider or the help unit in addition to a report on the activity so that the service provider or the help unit may correctly and precisely analyze the activity in view of the session history. The invention can be used in help request in a legacy mainframe system, online services and beta testing, etc., as well as in productivity analysis and audit trail in an online session. Other features enhance the user-friendliness of the system.

Description

SESSION WITH ADDED USER FRIENDLY FEATURES
TECHNICAL FIELD OF THE INVENTION
This invention relates to network sen~ice, more particularly, to a method of reporting an to 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 ~5 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 sen~ice provider (usually to its help group) through an email client or tivough the website of the service. The help personnel solely 2o 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 a~rywhere in the world.
Further, when a new version of software comes out, it is quite common to invite a test 25 population to try a heta 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 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 F'C or thin client.
This is usually implemented through a sen~er arranged between a legacy mainframe and its terminal emulators over a network. The terminal users can communicate with the server by IITML
pages or other contemporary applications such as windows applications.
When a terminal user needs help while encountering a problem during his session, he may communicate with a support group of the legacy mainframe system to explain the problem.
This communication may be done in a traditional way by telephone or fax, or, with the help of modem 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 t>e 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 activiities 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 viev~ 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
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 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 tlhe 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 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 histon~ as an attachment of the email. Thus, the 2o sen~ice 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 incorporated in a legacy mainframe system; and Fig. 2 is an exemplary screen associated with the "ba<;k on track" feature of the present mventton.
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 it possible, that the legacy mainframe can remain unchanged, the terminal emulators may 1o 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 a combine to form a dumb terminal interface to the legacy system.
A help group, called "help desk" 4, also communicale~s 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 5.
During a session conducted by a user, alt the HTML pages in both directions (i.e., to and 2o 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 seasion so that the file for the session may be easily located from the server 2. For example, a session 1D 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 rnay 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 wfiich the user at the terminal emulator may key in a text message to further explain the problem. The text message is automatically sent to the help desk as an email message by simply clicking on thc: command button.
to Preferably, clicking on the command button not only wends 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 rnay~ be sent to the help desk as an attachment of the email message sent from the terminal emulator.
As an alternative, the HTML pages are not sent to the help desk together with the report, is 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 includedl in the report so that the help desk can locate and retrieve the history {the HTML pages ofthe session) from the server 2 .
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 th<~ whole connection session. This zo 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 w~ay, 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 ser~~er maintained by the help desk specially for the pupose of providing help to the terminal users instead of the server 2 which usually works for the purpose of communications between the legacy mainframe l and the terminal emulators.
The session history may also be stored at the terminal emulator if ii 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 ~~indow. A special to simple software may be designed for this purpose. No specific session ID
designating or matching system is necessary, but may nonetheless be includedl.
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 ~5 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 fot~rn 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 prolblem happens. This action may Zo automatically generate a help request. Additionally, the si;ae of the history stored, (i.e., 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 oiE 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.
to It shall be further 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 t5 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 clapscd 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 tirne per use as reported. This can be 2o 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 sun~ey. The same, of course, can also be applied in studying the effectiveness off 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 HITML 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 I-iTML pages resides in that HTML
is alt searchable text. This is helpful in some applications such as audit trail. By setting up a 1o query to focus on the recorded history that contains the particular screen in question, and printing out the screen pages in both directions (i.e., presented from tJne 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 15 technique. One such enhancement involves the use of sen~e:r 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 1. 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 2o conveys information and accepts as input other informaiion firom 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 w~el1-known Internet Explorer by Microsoft Corporation, there is a back button and a forward button. Vvtten 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, ii will move even further back to a :gill previous screen. The user may navigate through the screens, however, the application running on legacy mainframe 1 would not be aware of any such navigation back and forth.
A particular error which could occur as a result of tree 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 lp application and a new screen is downloaded. After four o:r 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 more forward three screens, and believe that he is on the present screen. Thus, the user begins operating on the third screen to transmit to the application through the server as previously describedl, but the application will produce an 15 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 dutnb tetrninal displaying the fourth screen.
In accordance with the present invention, the "bac:k on track" feature may be utilized in server 2. Specifically, the server keeps track of information associated with each screen being Zp transmitted down to terminal 3 from mainframe 1. A screen 1D 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 (i.e., the H'fNIL representation is out of sync with the real appii<:ation 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 s 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 l to send the appropriate screen to the terminal 3 for processing. The retransmission'of the appropriate screen will synchronize the HTML representation which teirninal 3 is displaying with the corresponding screen that the 1o 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, t5 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 would protect client's confidential information 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, 2o 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 displaye<l to the user, »~here he may use his mouse and'or other keys to block out certain fields solely for purpose of vansmission 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 to 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 geld designator. The fieldl designator may be in the form of a blinking or moving cursor. That blinking or moving cursor will be translated into a large static t5 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 includea no blinking cursor, but instead a static arrow pointing to the position where the cursur 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.
2o 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 ex9mple, 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 comprising the steps of:
transmitting screens from the legacy mainframe to the terminal;
displaying a representation of each screen to 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 mainframe, 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 comprising displaying on said terminal an appropriate screen to resynchronize said terminal and said computer after said user attempts to respond to said out of synchronization screen.

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

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

5. The method of claim 4 wherein said user selects an icon 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 comprising:
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 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, Apparatus of claim 6 further comprising 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 mainframe 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 comprising:
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 send 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.

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.

10. Apparatus for reporting a problem encountered by a terminal emulator which displays representations of screens generated by a computer, said apparatus comprising:
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 to alter or highlight certain specified ones of fields contained within a representation of at least one of said screens forwarded to said third party.

11. A method of displaying information generated by a computer on a terminal comprising of steps of:
receiving a screen of information from said computer, said screen comprising a moving or blinking indicator; and means for displaying a 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.