Source: http://www.google.com/patents/US20040113944
Timestamp: 2016-12-10 23:54:44
Document Index: 306520920

Matched Legal Cases: ['art 105', 'art 107', 'art 105', 'art 107', 'art 110', 'art 107', 'art 105', 'art 110', 'art 110', 'art 115', 'art 109', 'art 107', 'art 107', 'art 105', 'art 105', 'art 109', 'art 115', 'art 116', 'art 116', 'art 115', 'art 107', 'art 109', 'art 105', 'art 111', 'art 117', 'art 115', 'art 109', 'art 111', 'art 111', 'art 111', 'art 111', 'art 107', 'art 111', 'art 105', 'art 111', 'art 109', 'art 115', 'art 117', 'art 117', 'art 117', 'art 115', 'art 109', 'art 111', 'art 116', 'art 111', 'art 109', 'art 115', 'art 117']

Patent US20040113944 - Client screen on-demand creating system - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsThis is a construction process of a client-server system which can manage the display screen and operating conditions of each client in a concentrated manner, display the history that a client used if necessary, and have a dialog with a specific client using a character, a figure, etc. A server keeps...http://www.google.com/patents/US20040113944?utm_source=gb-gplus-sharePatent US20040113944 - Client screen on-demand creating systemAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS20040113944 A1Publication typeApplicationApplication numberUS 10/343,544PCT numberPCT/JP2002/007572Publication dateJun 17, 2004Filing dateJul 25, 2002Priority dateJul 30, 2001Also published asWO2003012653A1Publication number10343544, 343544, PCT/2002/7572, PCT/JP/2/007572, PCT/JP/2/07572, PCT/JP/2002/007572, PCT/JP/2002/07572, PCT/JP2/007572, PCT/JP2/07572, PCT/JP2002/007572, PCT/JP2002/07572, PCT/JP2002007572, PCT/JP200207572, PCT/JP2007572, PCT/JP207572, US 2004/0113944 A1, US 2004/113944 A1, US 20040113944 A1, US 20040113944A1, US 2004113944 A1, US 2004113944A1, US-A1-20040113944, US-A1-2004113944, US2004/0113944A1, US2004/113944A1, US20040113944 A1, US20040113944A1, US2004113944 A1, US2004113944A1InventorsSusumu KawamuraOriginal AssigneeSusumu KawamuraExport CitationBiBTeX, EndNote, RefManPatent Citations (2), Referenced by (3), Classifications (18) External Links: USPTO, USPTO Assignment, EspacenetClient screen on-demand creating system
US 20040113944 A1Abstract
This is a construction process of a client-server system which can manage the display screen and operating conditions of each client in a concentrated manner, display the history that a client used if necessary, and have a dialog with a specific client using a character, a figure, etc. A server keeps the screen definition information of all screens and screen transition information that a client displays, and a server transmits screen definition information to a client according to a demand from the screen display program arranged at a client. By saving the screen identifier of the screen that a client shows at this moment, a server can grasp the screen that each client is using, manage a client, and have a dialog with a client. Images(6) Claims(5)
FIELD OF THE INVENTION [0001] This invention relates to a process for grasping the state of a client in detail in a client-server system. BACKGROUND OF THE INVENTION [0002] In a client-server system, since many clients have connected with one server, each client operates by giving a demand to a server and receiving an answer from a server. However, a server usually manages the operation state of a client individually. In order for an administrator and a support staff to look at the screen that a client uses remotely, a resident program that transmits the renewal information of a screen to a client is set and when change is shown in a screen, the screen is transmitted as picture information with which the pixel is located vertically and horizontally. SUMMARY OF THE INVENTION [0003] Although the total of clients using a server, the user name of each client, etc. were acquirable in conventional client-server systems, it was difficult to grasp the detailed situation of each client such as the screen which each client is using or moves to the next, the inputted data, or the contents of work. Also, when a client user asks a question about the directions of a system or reports a problem of a system to the administrator of a system or the system support staff, it took much time to solve the problem because it was difficult to tell the situation only by telephone etc. Although there is a system that an administrator can also see the screen of each client in order to solve this, in this case, since the screen of a client is transmitted as picture information with which the pixel is located vertically and horizontally, the renewal speed of a screen will be slow and the amount of communications will also become huge. [0004] In addition to this, when a system is suspended to maintain a system, or use of a part of function is restricted, there was no simple process of notifying all clients of it or forbidding that a new user connects with a system. [0005] In order to solve the problem mentioned above, in this invention, the definition information about all the screens that a client displays, and the screen transition information of a screen which shows the relation between these screens are kept on a server. Information such as the screen identifier, which each client uses now, is kept on a server to understand which screen each client uses now. Also, a process for recording the history of screens that each client used is offered. [0006] Furthermore, a process for transmitting a message to all or a specific client, and a process for a server also displaying the screen that a specific client shows and a client user and a support staff having a dialog using characters and figures are offered. BRIEF DESCRIPTION OF THE DRAWINGS [0007] [0007]FIG. 1 is a system configuration of a client-server system where this invention is applied. 101 is a server and 114 is a client. Screen definition information 102 describes definition information of all screens displayed on a client 114 in the form that is shown in FIG. 2 for every screen. 201 has declared the name of a screen, and the size of a screen. Two or more screens exit can be defined on a screen, and a name is given to each screen exit in the form shown by 202. 203 is a definition of the display parts arranged on a screen, and describes the attribute of the classification of display parts, a display position, a size, and others. 204 is a definition of processing to specific screen parts, and in this example, when a button is pushed, the processing which escapes from a screen through an exit “O.K.” is described. The screen generated from the screen definition of FIG. 2 is as FIG. 3. [0008] The relation between screens is described in screen transition information 103 in the form that is shown in FIG. 4. A screen course name and an initial screen are specified in 401. 402 shows one screen and transition is defined here. For example, when you escape from the exit “O.K.” of a screen “sc 004”, you move to a screen “sc 002”, and when you escape from the exit “Cancel”, you move to a screen “sc 001”. FIG. 5 illustrates visually transition of the screen defined in FIG. 4. [0009] A screen management part 105 is a part that has the function that reads screen definition information 102 and screen transition information 103, and outputs suitable screen definition information according to a demand from the outside. Concretely speaking, 105 has the function to return the screen definition information of an initial screen on the relevant course when a course name is given, and the function to return the screen definition information of the next screen on a course when the name of a course, a screen, and an exit are given. Also, it has the function to permit or forbid using a specific screen on the setting screen 104 for the propriety of use of screens. [0010] A client state management part 107 has the function to manage the state of all clients. Concretely speaking, information about the screen which each client uses now is kept in a client management table 601 shown in FIG. 6, and when there is a demand which shifts to the next screen from a client, the screen definition information of the screen to transit next is acquired and returned by asking the screen management part 105 based on the information kept in 601. When the screen of one of clients changes, the client state management part 107 notifies a history management part 110 of it. The client state display screen 106 acquires the state of all present clients from the client state management part 107 and displays which screen each client is using, together with the screen transition information acquired from the screen management part 105. An example of a screen display of the client state display screen is shown in FIG. 7. [0011] A transmitting screen of broadcast message 108 acquires the list of clients that are operating now from the client state management part, and has the function to transmit a message for the client of all or a part of this list. In a client, a new window is generated and the message that received is displayed. When a system stops, all client users can be notified using this function. [0012] A history management part 110 has the function to keep the history of screens that a client used. The screen use information given from the outside can be kept inside, and frequency of use of a screen, staying time, the number of times of course passage, etc. can be outputted according to a demand. A history display screen 112 has the function that acquires and displays various history information from the history management part 110. [0013] A client 114 has the function that requires screen definition information of a server and draws a screen according to the received screen definition information. The procedure in which the client displays a screen is as follows. After starting operation, the client 114 transmits a screen course name to use to the server through a communication processing part 115. [0014] The communication management part 109 of the server receives this and publishes a client identifier to this client, and passes to the client state management part 107 together with the demanded screen course name. The client state management part 107 adds the received client identifier and the screen course name to the client state management table 601, and demands the initial screen definition of the relevant screen course from the screen management part 105. After receiving the initial screen name and the screen definition information from the screen management part 105, 107 records the screen name in the client state management table 601 and returns the screen definition information to the client through the communication management part 109. The communication processing part 115 of the client receives the screen definition information, and passes this to a screen drawing part 116 and displays the screen. If the client user directs the transition to the following screen, the screen drawing part 116 will require the screen definition of the next screen from the server through the communication management part 115. After the client state management part 107 received the demand which transits to the following screen from the client through the communication management part 109, asks the screen management part 105 and acquires the screen name of the next screen and the screen definition, and records the screen name in the client state management table 601 and returns the screen definition to the client 114. The client 114 which received the screen definition draws this screen. The same processing is repeated when transition to the following screen is demanded. [0015] A dialog management part 111 has the function to realize a dialog with a specific client. An example of a screen of a client 114 is shown in FIG. 8, and an example of a screen of the dialog screen 113 is shown in FIG. 9, respectively. The details of dialog processing are as follows. If a client user pushes “Call” button 802, the dialog processing part 117 of the client detects this and transmits the message that demands a dialog from a server through the communication processing part 115. The communication management part 109 of the server receives the demand of this dialog, and notifies the dialog management part 111. The dialog management part 111 which received the demand of the dialog notifies the dialog screen 113 of it. When the dialog screen 113 receives the demand of the dialog, 113 notifies the user of the dialog screen by blinking “Receive” button 902 on the screen. If the user of the dialog screen pushes “Receive” button 902, the dialog screen 113 will notify the dialog management part 111 of the message that received the demand of the dialog. After receiving the message, the dialog management part 111 will acquire the course name and screen name of the screen that the relevant client uses now from the client state management part 107. Based on the course name and screen name that were acquired, the dialog management part 111 acquires the relevant screen definition information from the screen management part 105, and transmits to the dialog screen 113. The dialog screen 113 receives the screen definition, draws the relevant screen, and displays a dialog window 903. The dialog management part 111 notifies that the demand of the dialog was received to the client through the communication management part 109. After receiving this notice, the communication processing part 115 of the client transmits the notice to the dialog processing part 117. By receiving this notice that demands the dialog, the dialog processing part 117 displays a dialog window 803. After that, the client user and the user of the dialog screen have a dialog with a dialog window using characters. Also, if a client user draws a figure shown in 801 with a mouse etc. on the screen, the figure information is transmitted to the dialog screen 113 through the dialog processing part 117, the communication processing part 115, the communication management part 109, and the dialog management part 111, and this figure is displayed as shown in 901 in the form which overwrites on the dialog screen. If a user of a dialog screen draws a figure with a mouse etc. on the dialog screen 113, the figure information is transmitted to the screen drawing part 116 through the dialog management part 111, the communication management part 109, the communication processing part 115, and the dialog processing part 117, and this figure is displayed in the form that overwrites on the screen. This dialog state is maintained until “Off” button is pushed by the client user or the user of the dialog screen. DESCRIPTION OF THE PREFERRED EMBODIMENTS [0016] As mentioned above, this invention can keep screen definition information and screen transition information on a server, and can improve maintenance and management of a client-server system by managing the state of a client in a concentrated manner. [0017] Also, the support in a client-server system can be improved by the message transmission to a client and the dialog between a support staff and a client user. [0018] Furthermore, by recording the situation that a client uses screens on a server, a system operation test can be checked based on the number of times which passed the course, or the convenience of screens can be evaluated based on frequency of use or staying time. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS6642941 *Nov 16, 1999Nov 4, 2003Fujitsu LimitedDisplaying optimum screens on various types of output terminals using a common applicationUS20010035878 *Mar 19, 2001Nov 1, 2001Crain Kenneth H.Methods and devices for recording changes in visual stimuli observed through browser-based interfaces* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS9223896Nov 13, 2009Dec 29, 2015Fujitsu LimitedScreen generation method, and screen generation apparatusUS20110083083 *Nov 13, 2009Apr 7, 2011Fujitsu LimitedScreen generation method, and screen generation appratusUS20140258380 *Jan 31, 2014Sep 11, 2014Brother Kogyo Kabushiki KaishaTerminal device, non-transitory computer-readable storage medium storing computer program for terminal device, and system* Cited by examinerClassifications U.S. Classification715/744International ClassificationG06F15/00, H04L29/08, G06F13/00, H04L29/06Cooperative ClassificationH04L67/08, H04L67/38, H04L67/42, H04L67/36, H04L69/329, H04L67/22, H04L29/06European ClassificationH04L29/08N21, H04L29/06C4, H04L29/08N35, H04L29/06C8, H04L29/08N7, H04L29/06RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services