Note: Descriptions are shown in the official language in which they were submitted.
CA 02342748 2001-04-02
METHOD OF REPORTING A PROBLEA9 TN A NETWORK
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
CA 02342748 2001-04-02
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.
2
CA 02342748 2001-04-02
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
CA 02342748 2001-04-02
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
4
CA 02342748 2001-04-02
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
5
CA 02342748 2001-04-02
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
6
CA 02342748 2001-04-02
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
7
CA 02342748 2001-04-02
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
8
CA 02342748 2001-04-02
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
9
CA 02342748 2001-04-02
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
CA 02342748 2001-04-02
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,
CA 02342748 2001-04-02
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.
12
