JP2010160538A - Terminal operation history storage system and user terminal - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a terminal operation history storage system suited for use when the operation history of a user terminal is reproduced on another terminal, and a user terminal. <P>SOLUTION: In the terminal operation history storage system, the user terminal creates a local GUI object tree as terminal operation history information out of a GUI object tree structure that corresponds to a window display screen. The local GUI object tree is stored in time series as skeleton GUI object information. A series of pieces of skeleton GUI object information for a plurality of screens are transmitted to a file server at a prescribed timing. The file server stores as a terminal operation history the series of pieces of skeleton GUI object information received from the user terminal, while associating the pieces of skeleton GUI object information with a user identifier. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a terminal operation history storage system and a user terminal, and more particularly to a terminal operation history storage system and a user terminal that store a window display screen transition of the user terminal in a reproducible manner.

  In an information processing system including a server and a terminal, it is necessary to leave a terminal operation history. In particular, in a back office where a terminal user processes a large amount of routine work and a contact center where a terminal user responds to a consultation from a customer using information stored in a server, as a user operation history in each terminal, A storage system for a terminal operation history that makes it possible to reproduce time-series changes in the display screen is required.

  In a client terminal connected to the server, for example, a personal computer, a window corresponding to the application is generated on the display screen, and the menu, function button, and data input box prepared in each window are input and registered in the server. Input of data to be performed and reference to server storage information are performed.

  In the method of storing bitmap data indicating the display content of the terminal screen as operation history information that enables playback of a window display screen that changes in time series, the amount of information to be stored as the operation history becomes enormous. A large-capacity storage device is required.

  As one method for reducing the information amount of the operation history, for example, Japanese Patent Laid-Open No. 8-161206 (Patent Document 1) discloses a recording / playback processing device between a window system server mounted on a workstation and a client application. This recording / playback processing device relays a transmission / reception message between a client application and a window system server, and when an event message is detected, it is proposed to store a copy in the event message memory. . When the operation history is reproduced, the recording / playback processing device transmits the event message read from the event message memory to the client application as if it was generated by the user input, so that the user performs the operation history recording. The user's work content is reproduced based on the reproduction input.

  Japanese Patent Laying-Open No. 2005-63279 (Patent Document 2) is provided with a PC operation recording file and a PC operation recording program in a terminal (personal computer), and the PC operation recording program is connected to the mouse from the OS interface. Receives input, keyboard input, voice input, window information, application program information, etc., and these information items include, for example, title record, screen information record, program start record, file input record, mouse data record, keyboard data record, voice data Recording and window information recording are recorded in a PC operation recording file. The PC operation history is reproduced by giving the recording data read from the PC operation recording file to the output device and the application program.

JP-A-8-161206 Japanese Patent Laying-Open No. 2005-63279

  However, since the operation history recording / reproducing method proposed in Patent Document 1 is based on the principle that an event message read from the event message memory is input to the client application and the same application is operated as when the operation history is recorded. The terminal that reproduces the operation history needs the same operating environment as when recording the operation history. Therefore, the terminal that reproduces the operation history requires the same application and the same file data as the terminal that recorded the operation history, and the reproduction of the operation history may be restricted depending on the type of application.

  On the other hand, the operation history recording / reproducing method proposed in Patent Document 2 is intended to reproduce computer operations in conferences and lectures, conference materials presented on the screen, explanation voices, and the like. However, since the recording data read from the PC operation recording file is reproduced by giving it to the output device and the application program, there is a problem similar to that of Patent Document 1.

An object of the present invention is to provide a terminal operation history storage system and a user terminal suitable for reproducing an operation history in a user terminal on another terminal.
Another object of the present invention is to provide a terminal operation history storage system and a user terminal suitable for reproducing the history of operations performed on a plurality of user terminals on other terminals.

  In order to achieve the above object, a terminal operation history storage system of the present invention comprises a file server and a user terminal connected via a network, and the user terminal displays a window from a graphic user interface (GUI) object tree. A local GUI object tree serving as terminal operation history information is generated for each screen, and this is stored in time series as skeleton GUI object information, and a series of skeleton GUI object information for a plurality of screens is stored at a predetermined timing. Send to file server. The file server stores a series of skeleton GUI object information received from a user terminal in association with a user identifier, and in response to a request from another terminal connected to the network, for example, an administrator terminal, The skeleton GUI object information of the specific user terminal is transmitted to the requesting terminal.

  The GUI object tree is composed of a plurality of GUI object groups corresponding to windows, and the state of each GUI object is updated according to the terminal operation of the user, and the window display screen of the user terminal is accompanied by the state change of the GUI object. Changes. Therefore, the administrator terminal can reproduce the window display screen serving as the operation history in the user terminal based on the local GUI object tree acquired from the file server.

More specifically, in the terminal operation history storage system according to the present invention, the user terminal is
A GUI object information file for storing a plurality of GUI objects composed of a plurality of information items for designating the display / non-display state, display position and display content of each window generated on the display screen;
A GUI object management module for updating the content of the GUI object stored in the GUI object information file in response to a user operation on the display screen;
From the GUI object tree structure stored in the GUI object information file, a tree structure part consisting of GUI objects in the display state is extracted, and a local GUI object tree consisting of GUI objects from which a part of information items are removed is generated. A skeleton GUI information acquisition routine for storing a series of skeleton GUI object information for a plurality of screens to the file server at a predetermined timing;
A processor for executing the GUI object management module and the skeleton GUI information acquisition routine is provided.

  In one aspect of the present invention, the skeleton GUI information acquisition routine provides time stamp information indicating the date and time for each local GUI object tree. Further, the skeleton GUI information acquisition routine excludes a specific information item, for example, bitmap information, from each GUI object extracted from the GUI object tree structure, and each GUI that becomes a constituent element of the local GUI object tree. Create an object.

  Each GUI object includes class information as one of the plurality of information items described above, and the local GUI object tree generated by the skeleton GUI information acquisition routine has a GUI object whose desktop screen is specified by the class information as a vertex. A plurality of hierarchical GUI object groups corresponding to each window being displayed are included.

  In one aspect of the present invention, each GUI object that is a constituent element of the local GUI object tree includes, for example, object class information, display status information indicating display / non-display, an object identifier, and a display position. It becomes the simplified structure containing the rectangular coordinate information to show, the text information which shows the display content, and the order information.

  In one aspect of the present invention, the skeleton GUI information acquisition routine generates a local GUI object tree, for example, at a timing notified from the GUI object management module. However, the local GUI object tree may be generated at a predetermined cycle.

  In another aspect of the present invention, the skeleton GUI information acquisition routine performs difference information between a local GUI object tree of a preceding screen stored as skeleton GUI object information and a local GUI object tree generated on a new screen. Thus, a new local GUI object tree to be stored as skeleton GUI object information is generated.

  According to the terminal operation history storage system of the present invention, the user terminal includes a plurality of user terminals connected to the network, and each user terminal includes the above-described GUI object information file, GUI object management module, and skeleton GUI information acquisition routine. By providing, the said file server can memorize | store the skeleton GUI object information received from these several user terminals as a terminal operation log | history corresponding to the identifier of the user of each user terminal.

  The administrator terminal connected to the network, for example, specifies a search condition, requests the file server to transmit a terminal operation history, and based on the skeleton GUI object information received as the terminal operation history from the file server. The display screen of the administrator terminal includes a skeleton GUI playback routine for playing back a window display screen as an operation history of the user terminal in time series.

  According to the present invention, as the terminal operation history information, a local GUI object tree corresponding to the terminal screen is generated, and the local GUI object trees for a plurality of screens are accumulated in the file server in time series. The other terminal (administrator terminal) can request the local GUI object tree of the specific user from the file server, and draw the operation screen of the user terminal on the display screen based on the local GUI object tree. Therefore, according to the present invention, the terminal operation history can be reproduced regardless of the application program actually executed on each user terminal.

  Embodiments of a terminal operation history storage system according to the present invention will be described below with reference to the drawings.

FIG. 1 shows a configuration example of a terminal operation history storage system according to this embodiment.
The terminal operation history storage system according to the present embodiment is connected to the plurality of terminals 10 (10-1 to 10-n) connected to the network NW1, the administrator terminal 20 connected to the network NW1, and the network NW1. File server 30. The network NW1 is a LAN constructed in a company, for example, and is connected to an external network NW2 via a gateway (GW) 40. The network NW2 is, for example, the Internet to which various web servers 50 (50A, 50B,...) Are connected.

  The terminal 10 is a terminal operated by an employee (general user) in the company, for example, a personal computer (PC), and has a communication function for communicating with the file server 30 and a function for recording terminal operation screen information to be described later. It is an example of a computer. The terminal operation screen information recorded in each terminal 10 is transmitted to the file server 30 and stored in the data storage of the file server 30. The file server 30 is an example of a computer provided with a plurality of application programs for configuring various data management systems and a plurality of types of data files used in these applications. In the present embodiment, each terminal 10 communicates with the file server 30 and executes a task referring to data input to the data management system or data stored in the data management system. The file server 30 also includes an information file that stores terminal operation screen information received from each terminal 10 in association with a user identifier as an operation history.

  The administrator terminal 20 is a terminal operated by the administrator, for example, a personal computer (PC), and displays a terminal operation screen based on a communication function for communicating with the file server 30 and operation history information received from the file server 30. It is an example of the computer provided with the function to reproduce | regenerate on a display screen. In the terminal operation history storage system of the present invention, an administrator who operates the terminal 20 searches for terminal operation screen information of a specific employee from the terminal operation screen information accumulated as the terminal operation history in the file server 30, The operation screen of the employee terminal is reproduced on the display screen of the terminal 20. Thereby, the transition of the display screen of the terminal 10 that changes in response to the terminal operation performed by the specific employee can be confirmed.

  For example, it is assumed that employees X and Y access various data management systems provided by the file server 30 from each terminal 10 and perform their duties. Even when the same type of work is executed, the required time varies depending on the abilities and experiences of the employees X and Y. In addition, in the case of window business that requires presentation of materials according to customer requests and questions, such as investment trust business, depending on the situation, employees need to access the Web server 50 to obtain appropriate information. There is. In this case, the administrator reproduces the terminal operation history of the excellent employee and the terminal operation history of the employee who is not so on the display screen of the terminal 20 and compares them to improve the ability of the employee. Get business improvement tips.

FIG. 2 shows an example of the display screen of the terminal 10.
Here, 1000A denotes a desktop screen, W1 denotes a travel expense system window provided by the file server 30, and W2 denotes a route search system window provided by the Web server 50A, for example. Each window is drawn based on a plurality of hierarchical GUI objects as will be described later. In FIG. 2, the background of the desktop screen 1000A is changed to a white background for the sake of clarity of the drawing, but generally these windows are generated on a desktop screen having a color and a pattern as a background. In addition, each window is often provided with illustrations and photographs (here, trains) that characterize the window, with a color or pattern applied to a part of the area so that the data input frame is clear.

FIG. 3 shows an example of a display screen 1000B reproduced on the administrator terminal 20 in the present embodiment. Windows W1 and W2 correspond to windows W1 and W2 in FIG.
In this embodiment, from the desktop screen 1000A output to the display screen of the terminal 10 and the windows W1, W2,..., For example, bitmap information for displaying backgrounds and illustrations is not necessary for the terminal operation history. Is deleted, the amount of operation history information to be stored in the file server 30 is reduced. In this specification, a GUI object for generating a window display screen from which unnecessary information is deleted is referred to as a skeleton GUI object.

FIG. 4 shows a configuration example of the terminal 10 used by a general user (employee).
The terminal 10 includes a processor 11, a display device 12, an input device 13 (keyboard 13A and mouse 13B), a communication interface unit 14 for connecting to the network NW1, memories 15 and 16, and a data storage 17. These components are interconnected by a bus 18.

  In the memory 15, an operation system (OS) 100, a window display control module 110, a GUI information management module 120, a communication control module 130, a skeleton GUI information acquisition routine 140, as various programs executed by the processor 12, The application program 180 is stored. The window display control module 110 and the GUI information management module 120 are mounted on each terminal as a part of the OS 100. In this embodiment, the skeleton GUI information acquisition routine 140 that extracts the skeleton GUI object information from the GUI object information. In order to explain these functions, these modules are shown separately from other functions of the OS.

  The memory 16 includes a memory area for storing parameter information such as a user ID, a terminal ID, a terminal address, and a date, a GUI object information file 160 referred to by the window display control module 110, and data used by the application program 180. Area 161 is formed. The data storage 17 is an external memory having a large storage capacity, for example, a disk. The data storage 17 temporarily stores a local GUI object tree structure composed of skeleton GUI objects generated by the skeleton GUI information acquisition routine 140. A skeleton GUI object information file 170 and other information storage area 190 are formed.

FIG. 5 is a diagram for schematically explaining the functions of the GUI information management module 120 and the skeleton GUI information acquisition routine 140.
The GUI object information file 160 stores a GUI object tree structure including a plurality of GUI objects for defining various windows drawn on the desktop screen. The window display control module 110 draws a window on the display screen according to the state of the GUI object stored in the GUI object information file 160.

  For example, when the user selects a specific character input frame in a specific window on the display screen with the mouse 13B and inputs a character string with the keyboard 13A, the GUI information management module 120 displays the input character string with the GUI. The text information is stored in the GUI object corresponding to the window stored in the object information file 160. The character string input by the user is sequentially output by the window display control module 120 to a character input frame on the display screen.

  When the user moves any window with the mouse 13B, the GUI information management module 120 updates the display position coordinate information of the GUI object corresponding to the window, and the window display control module 110 updates the updated GUI. The window position on the display screen is changed according to the object information. When the user clicks a specific function button prepared in the window, the OS 100 transmits the input character string in the window to the file server 30 (or the Web server 60). When the GUI information management module 120 rewrites the display state information of a specific GUI object stored in the GUI object information file 160 in response to the click of the function button, the window display control module 110 displays the updated GUI object. Change the display state of the window on the display screen according to the tree structure.

  The skeleton GUI information acquisition routine 140 reads the GUI object tree structure from the GUI object information file 160 at a predetermined timing in cooperation with the GUI information management module 120. The skeleton GUI information acquisition routine 140 excludes a GUI object that is in a non-display normal state from the GUI object tree structure, and includes a local area including a plurality of GUI objects (skeleton GUI objects) from which unnecessary information is removed as a terminal operation history. A GUI object tree is generated and stored in the skeleton GUI object information file 170 of the data storage 17. The skeleton GUI information acquisition routine 140 will be described in detail later with reference to FIG.

FIG. 6 shows an example of a GUI object tree structure stored in the GUI object information file 160.
The GUI object tree structure includes a plurality of GUI object groups that are hierarchized with a desktop GUI object OBJ1000 having class information = “desktop” as a vertex. Here, each GUI object indicates display state information 60, class information 61, object ID 62, rectangular coordinate information 63, front-to-back order information 64, text information 65, bitmap information 66, and other information 67.

  The GUI object tree structure in FIG. 6 corresponds to the GUI object OBJ2000 corresponding to the non-displayed window in FIG. 2, the GUI object group OBJ3000 to OBJ3300 corresponding to the window W1 in the display state, and the window W2. A part OBJ4000 of the GUI object group is shown.

  In the OBJ 1000, the bitmap information “desktop.bmp” indicates the background pattern of the desktop screen (however, in FIG. 2, the background of the desktop screen is indicated by a blank). OBJ3000 corresponds to the “travel expense system” browser frame 3000 in FIG. 2, OBJ3100 corresponds to the toolbar frame 3100 in FIG. 2, OBJ3200 corresponds to the display of the character string “address” in FIG. 2, and OBJ3300 This corresponds to the http address frame 3300 in FIG. In the OBJ 3000, GUI objects corresponding to the “business trip content input screen” 3400 in FIG. 2 are linked to the same hierarchy as the OBJ 3100 to OBJ 3300, but are omitted in FIG.

FIG. 7 shows the structure of a skeleton GUI object tree (local GUI object tree) generated from the GUI object tree structure of FIG. 6 by the skeleton GUI information acquisition routine 140.
Skeleton GUI objects SKL1000 to SKL3300 correspond to OBJ1000 to OBJ3300 shown in FIG. As apparent from the comparison with FIG. 6, the skeleton GUI object tree structure excludes the GUI object SKL2000 corresponding to the GUI object OBJ2000 that is not displayed on the terminal screen. Each skeleton GUI object includes display state information 60, class information 61, object ID 62, rectangular coordinate information 63, front-to-back order information 64, and text information 65, and bitmap information 66 and other information 67 are excluded. .

FIG. 8 shows an example of an accumulation form of skeleton GUI object information in the skeleton GUI object information file 170.
In this embodiment, the skeleton GUI object tree information indicating the screen operation history of the terminal 10 is stored in the skeleton GUI object information file 170 in a format linked to the snapshot_series node 73 in the order of generation. The snapshot_series node 73 is associated with the user ID 71 and the terminal ID 72 of the terminal 10. The skeleton GUI object tree information 74 (74-1 to 74-m) includes a time stamp (snapshot date) 741 composed of date information (date) and time information (time), and a skeleton GUI object description 742 having a tree structure. It consists of.

  The skeleton GUI object tree information for a plurality of screens stored in the skeleton GUI object information file 170 is transmitted to the file server 30 at a predetermined timing and stored in the file server 30. In this embodiment, the skeleton GUI object tree information 74-1 to 74-m is generated as a snapshot node (local GUI object tree), and is sequentially added to the snapshot_series node 73.

FIG. 9 shows an example of a skeleton GUI object description.
In FIG. 9, the first line shows the correspondence relationship between the snapshot_series node, the user ID (user = xxxx) of the terminal 10, and the terminal ID (PC = xxxxx). <Snapshot date = xxxx / xx / xx xx: xx: xx> 741 on the second line indicates the start position of the snapshot node, and </ snapshot> on the 24th line indicates the end position of the snapshot node, that is, one screen. The end position of the minute local GUI object and Lee is shown. The skeleton GUI object description 742 is described in the 3rd to 23rd lines as the contents of the snapshot node.

  The skeleton GUI object description 742 illustrated here corresponds to the skeleton GUI object tree structure shown in FIG. 7, and the skeleton GUI objects SKL3100, SKL3200, SKL3300, and SKL4000 arranged in the hierarchical order in the tree structure. The abbreviated skeleton GUI object SKL4000 is included. The description of each skeleton GUI object starts with <gui class = xxxx ......> and ends with </ gui>.

FIG. 10 is a block diagram illustrating a configuration example of the administrator terminal 20.
The administrator terminal 20 includes a processor 21, a display device 22, an input device 23 (keyboard 23A and mouse 23B), a communication interface unit 24 for connecting to the network NW1, memories 25 and 26, a data storage 27, These components are an example of a management computer interconnected by a bus 28.

  The memory 25 is a program executed by the processor 22, similar to the terminal 10, like an operation system (OS) 100, a window display control module 110, a GUI information management module 120, a communication control module 130, and various application programs 280. Is remembered. In this embodiment, a skeleton GUI reproduction processing routine 240 for acquiring skeleton GUI object information from the file server 30 and generating a window display screen as a terminal operation history is stored in the memory 25 of the administrator terminal. The memory 16 defines a data area used by the application program 280, a GUI object information file 260A managed by the GUI information management module 120, and a skeleton GUI object information storage area 260B used by the skeleton GUI reproduction processing routine 240. The The skeleton GUI regeneration processing routine 240 will be described in detail later with reference to FIG.

FIG. 11 is a block diagram illustrating a configuration example of the file server 30.
The file server 30 includes a processor 31, a display device 32, an input device 323 (keyboard 33A and mouse 33B), a communication interface unit 34 for connecting to the network NW1, memories 35 and 36, and a data storage 37. Configured, and these components are interconnected by a bus 38.

  The memory 35 stores, as software executed by the processor 32, an operation system (OS) 300, a communication control module 330, and a plurality of application programs 380 constituting various data management systems provided by the file server 30. . In this embodiment, a skeleton GUI object information management routine 340 is prepared in the memory 35. In the memory 36, a data area used by the application program 380 and the skeleton GUI object information management routine 340 is defined. In the data storage 37, a data file 370 corresponding to various data management systems provided by the file server 30 and a skeleton GUI object information file 390 managed by the skeleton GUI object information management routine 340 are formed.

  FIG. 12 is a flowchart showing a skeleton GUI information acquisition routine 140 executed by the processor 11 of each terminal 10. The skeleton GUI information acquisition routine 140 is automatically activated when, for example, the user (employee) turns on the terminal 10 and the desktop screen is displayed on the display device 12.

  In the skeleton GUI information acquisition routine 140, the processor 11 acquires the user ID, terminal ID, and date information stored in advance in the memory 16, and generates the snapshot_series node 73 described in FIG. 8 in the skeleton GUI object information file 170. After (step 141), the ID value of the desktop GUI object OBJ1000 is read from the GUI object information file 160 (142). In the example illustrated in FIG. 6, “1000” is read as the ID value of the desktop GUI object. In step 141, the desktop GUI object ID value “1000” is represented by Z.

  The processor 11 acquires the current time information from the internal clock included in the terminal 10, generates a snapshot node having a time stamp 741 composed of date information and time information in the skeleton GUI object information file 170, and sets the desktop to the parameter P After setting (144) the ID value Z of the GUI object, the skeleton GUI object node generation process 150 is executed. The parameter P becomes an argument of an object ID in the skeleton GUI object node generation process 150 that is recursively executed to generate a hierarchical GUI object.

  In the skeleton GUI object node generation process 150, as will be described in detail with reference to FIG. 13, the GUI objects whose display state information 60 is being displayed are read from the GUI object tree stored in the GUI object information file 160 in hierarchical order. Then, by extracting information on specific items designated in advance from each GUI object, skeleton GUI object descriptions that are the contents of the snapshot node are sequentially generated.

  When the generation of the snapshot node (local GUI object tree) for one screen is completed by the skeleton GUI object node generation processing 150, the processor 11 adds the snapshot node to the snapshot_series node 73 generated in the skeleton GUI object information file 170. Add (145). Thereby, for example, the first snapshot node 74-1 is added to the snapshot_series node 73 shown in FIG.

  Thereafter, the processor 11 checks whether or not there is an end instruction from the GUI information management module 120 (147). If there is an end instruction, the processor 11 stores the skeleton GUI object information stored in the skeleton GUI object information file 170 as a file server. 30 (149), and this routine 140 is terminated.

  If there is no termination instruction in step 147, the processor 11 checks whether there is a display screen change notification (display change) from the GUI information management module 120 (148). If there is no display change, steps 147 and 148 are repeated. If there is a display change, the processor 11 generates a new snapshot node in step 144 and repeats the above-described operation. As a result, a snapshot node (local GUI object tree) of a new window screen is generated and added to the snapshot_series node 73.

  For example, if a display change is issued from the GUI information management module 120 at the timing when the display state of the window on the desktop screen is changed by a user operation, the skeleton GUI information acquisition routine is performed every time the state of the desktop screen changes. At 140, a new snapshot node can be added to the snapshot_series node. Therefore, in the GUI object information file 160, skeleton GUI information indicating the state transition of the desktop screen is accumulated in time series as terminal operation history information.

  When receiving the skeleton GUI object information from the terminal 10, the processor 31 of the file server 30 executes the skeleton GUI file management routine 340 and accumulates the received skeleton GUI object information in the skeleton GUI object information file 390. The skeleton GUI object information is stored in the file 390 in association with the user ID 71 and the terminal ID 72, and is read out using the user ID and time stamp information specified from the administrator terminal 20 as a search key.

FIG. 13 is a flowchart showing details of the skeleton GUI object node generation processing 150.
In the skeleton GUI object node generation process 150, the processor 11 reads the display state information 60 of the object with ID = P from the GUI object information file 160 (151), and determines the display state information 60 (152). When the display state information 60 is “non-display”, the processor 11 ends the processing 150. At the first execution time of the skeleton GUI object node generation process 150, the parameter P indicates the ID value (= Z) of the desktop GUI object OBJ1000, and the display state information 60 read from the object information file 160 is “display”. " Therefore, the processor 11 executes the skeleton drawing information extraction process 153 for the GUI object with ID = P (= 1000), this time the desktop GUI object OBJ1000.

  In this embodiment, the skeleton drawing information extraction processing 153 is performed by class information 61 (step 1531), rectangular coordinate information 63 (step 1532), front-rear order information 64 (from the GUI object with ID = P, as shown in FIG. Step 1533) and text information 65 (Step 1534) are extracted.

  Returning to FIG. 13, the processor 11 generates a new gui node including the information extracted in the skeleton drawing information extraction processing 153, and adds this to the parent node (154). This time, a gui node indicating a desktop skeleton GUI object SKL1000 is generated and added to the parent snapshot node as shown in FIG.

Next, the processor 11 counts the number N of child objects linked to the GUI object with ID = P (154), and sets the parameter i for designating the child object to be processed to the initial value 0 (156). Thereafter, the value of the parameter i is incremented (157). Next, the processor 11 reads the ID value (= X) of the i-th GUI object from the GUI object information file 160, sets this ID value in the parameter P (158), and recursively performs the skeleton GUI object node generation processing 150. (150R).
The processor 11 changes the value of the parameter i and repeats steps 158 and 159. When the value of the parameter i reaches N (160), the skeleton GUI object node generation processing 150 is terminated.

  For example, when the GUI object tree stored in the GUI object information file 160 has the structure shown in FIG. 6, when a gui node indicating the skeleton GUI object SKL1000 is generated in step 154, in step 150R, A skeleton GUI object node generation process 150 is recursively executed for the GUI objects OBJ2000, OBJ3000, OBJ4000,.

  In the GUI object OBJ2000, since the display state information 60 is “non-display”, the skeleton GUI object node generation process ends without generating a gui node. Since the GUI object OBJ3000 has the display state information 60 of “display”, a gui node indicating the skeleton GUI object SKL3000 is generated in step 154 and added to the parent node SKL1000 as shown in FIG.

  In the skeleton GUI object node generation processing 150 executed for the GUI object OBJ3000, in step 150R, the skeleton GUI object node generation processing is performed on the child objects OBJ3100, OBJ3200, OBJ3300,... Linked to the GUI object OBJ3000 in step 150R. 150 is executed recursively. As a result, gui nodes indicating the skeleton GUI objects SKL3100, SKL3200, and SKL3300 are sequentially generated, and these skeleton GUI objects are added to the parent node SKL3000 as shown in FIG.

  When the execution 150R ends in the recursive skeleton GUI object node generation processing 150 for the GUI object OBJ3000, the skeleton GUI object node generation processing 150 is executed recursively for the GUI object OBJ4000 (150R). Since the GUI object OBJ4000 has “display” as the display state information 60, a gui node indicating the skeleton GUI object SKL4000 is generated in step 154 and added to the parent node SKL1000 as shown in FIG.

  In FIG. 6, the child object linked to the GUI object OBJ4000 is actually omitted, but as is clear from the contents of the window W2 shown in FIG. 2, the GUI object OBJ4000 also has a plurality of child objects. Linked. Therefore, in the skeleton GUI object node generation processing 150 for the OBJ 4000, the skeleton GUI object node generation processing 150 for these child objects is recursively executed (150R), and a plurality of skeleton GUI objects are added to the SKL 4000.

FIG. 15 is a flowchart showing a skeleton GUI reproduction processing routine 240 executed by the processor 21 of the administrator terminal 20.
The skeleton GUI reproduction processing routine 240 is activated when the user (administrator) of the terminal 20 selects, for example, a specific icon for terminal history search displayed on the desktop screen.

  When the skeleton GUI reproduction processing routine 240 is activated, the processor 21 displays, for example, an operation history search condition input screen shown in FIG. 16 on the operation history reproduction window 200 generated on the desktop screen of the terminal 20 (241). ), And waits for input of a search instruction from the user (242). The search condition input screen includes an input box 201 for a user name (user ID) of an employee to be searched for a terminal operation history, a date input box 202 for an operation history to be reproduced, a data input box 203 for a start time, and a search button. 204A and an end button 204B are included.

  When a user clicks the search button 204A after inputting a user name, date, and time as search conditions on the search condition input screen, the processor 21 designates the search conditions to the file server 30, and first A request message for the skeleton GUI information on the screen is transmitted (243), and a response from the file server 30 is awaited (244).

  In this embodiment, when the processor 31 of the file server 30 receives the request message from the terminal 20, the skeleton GUI file management routine 340 extracts the search condition from the received request message, and from the skeleton GUI information file 390, the search condition is extracted. The snapshot_series node corresponding to the user name (user ID) indicated by is searched.

  The processor 31 searches the snapshot node group linked to the snapshot_series node for a snapshot node whose time stamp 741 matches the date and time specified by the search condition, and transmits them to the requesting terminal 20. To do. When there is no snapshot node whose time stamp time matches the specified time in the skeleton GUI information file 390, the processor 31 searches for the snapshot node having the time stamp time immediately before the specified time, and requests the requesting terminal 20 Send to.

  If the snapshot_series node having the time stamp date specified by the search condition does not exist in the skeleton GUI information file 390, a response message indicating a date error is returned from the file server 30 to the terminal 20, and the administrator is notified. Change search conditions. However, the processor 31 searches the snapshot node group linked to the snapshot_series node whose time stamp date is immediately before the specified date for a snapshot node whose time stamp matches the specified time, and requests the requesting terminal 20 You may make it transmit to.

  When receiving the snapshot node data from the file server 30, the processor 21 of the terminal 20 stores the received snapshot node data in the skeleton GUI object information storage area 260B of the memory 16, and based on this snapshot node data, the operation history reproduction window In 200, a window screen showing the operation history of the employee terminal is reproduced (245). This window screen is reproduced by a drawing module provided in the skeleton GUI reproduction processing routine 240.

  For example, as shown in FIG. 17, the employee operation history is reproduced in the employee terminal desktop display area 1000 </ b> C defined in the operation history reproduction window 200. At this time, for example, a “Close” button 205 and several function buttons 206A to 206D for changing the contents of the display area 1000C are displayed in the operation history reproduction window 200.

  The processor 21 waits for the user to select a function button. When the “end” button 206D is clicked (246), the operation history search condition input screen is displayed in step 241, and the sequence from step 242 is repeated. When the “close” button 205 is clicked (247), the routine 240 is terminated.

  When the “forward” button 206C is clicked (248), the processor 21 uses the user name and the time stamp attached to the snapshot node received this time as a reference, and the skeleton GUI object information (snapshot) of the next screen. A request message requested by the node is transmitted to the file server 30 (250), and the sequence from step 244 is repeated. When the “return” button 206B is clicked (248), the processor 21 uses the user name and the time stamp attached to the snapshot node received this time as a reference, and the skeleton GUI object information (snapshot) of the previous screen. A request message requesting (node) is transmitted to the file server 30 (251), and the sequence from step 244 is repeated.

  When the processor 31 of the file server 30 receives a skeleton GUI object information request message for the next screen from the terminal 20, the processor 31 of the file server 30 has the user ID (user name) and time stamp specified in the received message from the skeleton GUI information file 390. The snapshot node is searched, the next snapshot node is read, and transmitted to the requesting terminal 20. Further, when the request message for the skeleton GUI object information on the previous screen is received, the processor 31 searches the skeleton GUI information file 390 for a snapshot node having the user ID and time stamp specified in the received message, Data of the snapshot node is read and transmitted to the requesting terminal 20.

  According to the above embodiment, the administrator can observe the state transition of the window display screen at the terminal specified by the user name on the display screen of the terminal 20 by repeatedly clicking the “forward” button 206C. . Further, by alternately clicking the “return” button 206B and the “forward” button 206C as necessary, the administrator can analyze the display content of the window screen at a specific time point.

  In the search condition input screen shown in FIG. 16, the user name 201, the time stamp date 202, and the time 203 are specified as the search conditions. For example, as shown in FIG. 17, the file server 30 is used as the search keyword. The name of the data management system provided by may be specified. When the administrator specifies the user name, date, time, and keyword as search conditions, the file server 30 is caused to search the skeleton GUI information file 390 for a snapshot_series node corresponding to the specified user name (user ID). From the group of snapshot nodes linked to the node, it is possible to search for the first snapshot node whose time stamp date is the specified date and whose text information 65 matches the specified keyword, and send it to the administrator terminal 20.

  FIG. 18 is a flowchart showing a second embodiment of the skeleton GUI reproduction processing routine 240 executed by the administrator terminal 20. The steps denoted by the same reference numerals as those in FIG. 15 perform the same operations as those in the first embodiment, and therefore the description of these steps is simplified.

In the skeleton GUI reproduction processing routine 240 of the second embodiment, in step 243, the administrator terminal 20 requests the file server 30 to transmit the skeleton GUI object information for a plurality of screens starting from the screen corresponding to the search condition.
When receiving the skeleton GUI object information request message from the terminal 20, the processor 31 of the file server 30 extracts a search condition from the received request message by the skeleton GUI file management routine 340, and retrieves the search condition from the skeleton GUI information file 390. The snapshot_series node having the user name and time stamp date specified in is searched, and the snapshot node having the time stamp time specified by the search condition is searched from the snapshot node group linked to the snapshot_series node.

  In the second embodiment, the processor 31 of the file server 30 collectively transmits snapshot node data for a plurality of screens after a specified time linked to the same snapshot_series node to the request source terminal 20. If there is no snapshot node at the specified time in the searched snapshot_series node, the processor 31 transmits a series of snapshot node data starting from the snapshot node having the time stamp time immediately before the specified time to the requesting terminal 20. .

  If the snapshot_series node having the time stamp date specified in the search condition is not in the skeleton GUI information file 390, a response message indicating a date error is returned from the file server 30 to the terminal 20, and the search condition is sent to the administrator. To change. However, the processor 31 is made to search the snapshot node having the time stamp time specified by the search condition from the snapshot_series node having the time stamp date immediately before the specified date, and the snapshot nodes for a plurality of screens after the specified time are requested. You may make it transmit to the terminal 20.

  In this embodiment, when the processor 21 of the administrator terminal 20 receives a series of snapshot node data from the file server 30 as the skeleton GUI object information corresponding to the search condition, it stores these data in the data storage 27 ( 252). Thereafter, the processor 21 reads the snapshot node of the first screen from the data storage 27 to the skeleton GUI information storage area 260B (243), and the first window display screen of the employee terminal 10 is displayed on the display screen based on the snapshot node. Is reproduced (245).

  In this embodiment, since the skeleton GUI information for a plurality of screens for reproducing the terminal operation history in time series is already stored in the data storage 27 of the terminal 20, the administrator clicks the “forward” button 206C. At this time, the processor 21 reads the snapshot node of the next screen from the data storage 27 to the skeleton GUI information storage area 260B (250), and can reproduce the window display screen of the employee terminal 10 on the display screen (245). When the administrator clicks the “return” button 206B, the processor 21 reads the snapshot node of the previous screen from the data storage 27 to the skeleton GUI information storage area 260B of the memory 26 (251), and displays the employee on the display screen. The window display screen of the terminal 10 can be reproduced (245).

  FIG. 19 shows another embodiment of the operation history reproduction window 200 displayed on the administrator terminal 20. The operation history reproduction window display screen shown here includes a speed control bar 207 for changing the switching speed (interval ΔT) of the display contents in the display area 1000C at the bottom of the screen.

  The operation history replay window display screen allows the skeleton GUI replay processing routine 240 to perform the interval ΔT specified by the speed control bar 207 without repeating the “forward” and “return” button clicks by the user of the terminal 20. This is effective when the operation history display screen is automatically switched. In this case, once the user clicks the “forward” button, the processor 21 automatically switches the operation history display screen at ΔT intervals in the direction of time, and the “return” button is clicked in the middle. Then, the operation history display screen is switched at intervals of ΔT in the direction of going back in time. The user can adjust ΔT by changing the lever position of the speed control bar 207 by operating the mouse.

  In order to perform the automatic switching of the operation history display screen described above, a direction flag for storing the screen switching direction is applied to the skeleton GUI reproduction processing routine 240 described with reference to FIGS. When the button is clicked (step 248), the direction flag is set to the “forward” state, and when the “return” button is clicked (step 249), the direction flag is set to the “return” state. When the determination result is “NO”, the skeleton GUI object information may be read (250 or 251) according to the state of the direction flag after the time ΔT has elapsed.

Next, a third embodiment of the present invention will be described with reference to FIGS.
The feature of the third embodiment is that the skeleton GUI information acquisition routine 140 of the terminal 10 generates a snapshot node describing the difference from the previous screen as the skeleton GUI object information after the second screen.

  FIG. 20 shows a flowchart of the skeleton GUI information acquisition routine 140 of the third embodiment executed in each terminal 10. In steps denoted by the same reference numerals as those in FIG. 12, the same operations as those in the first embodiment are executed. Therefore, the description of these steps is simplified.

  In the skeleton GUI information acquisition routine 140 of the third embodiment, the processor 11 generates a snapshot_series node (141), reads the ID value of the desktop GUI object OBJ1000 from the GUI object information file 160 (142), and then prev node Is generated. The prev node is used for storing the contents of the snapshot node of the previous screen necessary for extracting the difference information.

  After generating the prev node, the processor 11 generates a snapshot node with a time stamp 741 in the skeleton GUI object information file 170 and sets the ID value Z of the desktop GUI object in the parameter P, as in the first embodiment. Then (144), the skeleton GUI object node generation process 150 described in FIG. 13 is executed. By executing the skeleton GUI object node generation process 150, node descriptions of the skeleton GUI objects are sequentially added to the snapshot node.

In the third embodiment, when the skeleton GUI object node generation process 150 ends, the processor 11 executes an object difference information extraction process 145A shown in FIG.
As shown in FIG. 21, in the object difference information extraction process 145A, the processor 11 determines the current state of the snapshot_series node (1451). When the snapshot_series node is empty, that is, when the skeleton GUI information acquisition routine 140 is generating the skeleton GUI object of the first screen of the terminal operation history, the processor 11 adds the skeleton GUI object node generation process 150 to the snapshot_series node. The snapshot node including the gui node generated in (1) is added (1452), and the object difference information extraction process 145A is terminated.

  When the snapshot_series node already includes a snapshot node, that is, when the skeleton GUI information acquisition routine 140 generates a skeleton GUI object on the second and subsequent screens of the terminal operation history, the processor 11 A diff node for describing difference information with the screen is generated (1453), and difference information between the prev node indicating the skeleton GUI object group of the previous screen and the snapshot node indicating the skeleton GUI object group of the new screen is detected. And describe it in the diff node.

  In this embodiment, the processor 11 adds an update node describing a gui node that exists in both the snapshot node and the prev node and has different attribute information to the diff node (1454), and exists in the prev node. A remove node describing a gui node that does not exist in the node is added to the diff node (1455), and an add node that exists in the snapshot node but is not present in the prev node is added to the diff node (1456).

  After executing steps 1454 to 1456, the processor 11 determines the state of the diff node (1457). When the diff node is empty, that is, when the currently generated snapshot node is the same as the full-screen snapshot node Ends the object difference information extraction 145A without using the diff node. If the diff node is not empty, the processor 11 adds the diff node to the snapshot_series node (1458) and ends the object difference information extraction process 145A.

  Returning to FIG. 20, when the object difference information extraction 145 </ b> A ends, the processor 11 copies the contents of the snapshot node generated this time to the prev node (146), and then executes the operations after step 147 described in FIG. 12. To do.

FIG. 22 shows an example of a skeleton GUI object description generated by the skeleton GUI information acquisition routine 140 of the third embodiment.
The skeleton GUI object information on the first screen has the same content as the snapshot node 74-1 shown in FIG. The skeleton GUI object information on the second screen is generated as a diff node including an update node, a remove node, and an add node by executing steps 1453 to 1456 in the object difference information processing 145A described with reference to FIG. As shown by -2, it is a simplified description consisting of an update node, a remove node, and an add node indicating the difference between the first screen and the second screen. The third and subsequent screens are also simplified diff node descriptions, similar to the node 74-2.

  FIG. 23 shows a flowchart of the skeleton GUI reproduction processing routine 240 of the third embodiment executed on the administrator terminal 20. Here, as in the second embodiment, the administrator terminal 20 requests the file server 30 to transmit skeleton GUI object information for a plurality of screens starting from the screen corresponding to the search condition, and the same reference numerals as in FIG. In the attached steps, the same operation as that of the second embodiment is executed, and thus the description of these steps is simplified.

  In the skeleton GUI reproduction processing routine 240 of the third embodiment, when the processor 31 reads the skeleton GUI object information of the first screen from the data storage 27 to the memory 26 (253), it is determined whether or not the skeleton GUI object information is a snapshot node. Is determined (254). When the skeleton GUI object information read from the data storage 27 is snapshot node data, the processor 31 reproduces the window display screen based on the snapshot node data as in the second embodiment (245) and determines The procedure after step 246 is executed.

  When the skeleton GUI object information read from the data storage 27 is not a snapshot node, that is, in the case of a diff node, the processor 31 uses time series data from the snapshot node stored in the data storage 27 to the current diff node. Then, GUI drawing data “draw” is generated (255), and the window display screen is reproduced (256) based on this draw data, and then the procedure after determination step 246 is executed.

  In the third embodiment, since the skeleton GUI object information after the second screen is the difference information from the previous screen, the information amount of the local GUI object tree can be reduced. Therefore, there is an advantage that the memory capacity for the skeleton GUI object information in each user terminal, administrator terminal, and file server 30 can be reduced.

  In the third embodiment, since each window display screen is reproduced from the difference information from the previous screen, it takes time to generate a new display screen. However, in the present invention, since the display screen is switched at a relatively long interval so that the administrator can verify the operation history of the user terminal, even if the time required to generate a new display screen increases, It doesn't matter above. In particular, when the display screen is automatically switched at intervals of ΔT, the time required for switching the screen is sufficiently smaller than ΔT. Therefore, even if ΔT is set to the shortest time, a new display screen is displayed. The time required to generate is not an obstacle.

  In the above embodiment, the skeleton GUI information acquisition routine 140 returns the skeleton GUI object information (local GUI object tree: snapshot node) as the terminal operation history in response to the screen change notification from the OS (GUI information management module). Although generated, the generation of the skeleton GUI object information may be executed periodically in response to a timer interrupt, for example. In particular, as in the third embodiment, when the difference information (diff node) between the previous screen and the new screen is generated as the skeleton GUI object information, if there is no change in the window display screen, the snapshot_series node Since the diff node is not added, even if the diff node generation process is periodically executed, unnecessary data is not duplicated and stored in the skeleton GUI information file.

  In the skeleton GUI information acquisition routine 140 shown in the embodiment, a skeleton GUI object is generated by extracting a plurality of types of specific information items from a GUI object in a display state included in the GUI object tree. The information items to be extracted from the GUI object may be freely specified on the administrator side. In this case, the administrator terminal 20 is provided with an editing program for the skeleton GUI information acquisition routine 140, and the administrator uses this editing program to execute a part of the skeleton GUI information acquisition routine 140, for example, the skeleton illustrated in FIG. 14. The function of the drawing information extraction process 153 may be changed, and the skeleton GUI information acquisition routine 140 may be downloaded to each employee terminal 10.

  For example, as shown in FIG. 24, the editing program displays an acquisition item selection screen 2000 including a plurality of information items to be GUI drawing information on the administrator terminal 20, and is selected by the administrator on the acquisition item selection screen. The content of the skeleton drawing information extraction process 153 is changed so that the information item is extracted from the GUI object tree.

  Specifically, the skeleton drawing information extraction process 153 shown in FIG. 14 includes, for example, a plurality of types of information extraction steps corresponding to information items displayed on the acquisition item selection screen 2000, and the necessity of execution for each information extraction step. A determination step for a flag indicating NO may be prepared, and the editing program may set the flag corresponding to the information item selected by the administrator to the ON state.

The figure which shows the structural example of the terminal operation history storage system by this invention. The figure which shows an example of the display screen of the terminal. The figure which shows an example of the display screen 1000B reproduced | regenerated by the administrator terminal 20 based on terminal operation screen information. FIG. 3 is a block diagram showing an example of the terminal 10. The figure for demonstrating schematically the function of the GUI information management module 120 and the skeleton GUI information acquisition routine 140. FIG. The figure which shows an example of the GUI object tree structure memorize | stored in the GUI object information file. The figure which shows the local GUI object tree (skeleton GUI object tree) structure produced | generated from the GUI object tree structure of FIG. The figure which shows an example of the accumulation | storage form of the skeleton GUI object information in the skeleton GUI object information file 170. FIG. The figure which shows an example of a skeleton GUI object description. The block diagram which shows an example of the administrator terminal 20. FIG. 1 is a block diagram showing an example of a file server 30. FIG. 5 is a flowchart showing an example of a skeleton GUI information acquisition routine 140 executed by the terminal 10. 13 is a flowchart showing details of a skeleton GUI object node generation process 150 in FIG. 14 is a flowchart showing details of skeleton drawing information extraction processing 153 in FIG. 13. 5 is a flowchart showing an example of a skeleton GUI reproduction processing routine 240 executed by the administrator terminal 20. The figure which shows an example of the search condition input screen displayed on the terminal operation history reproduction | regeneration window 200 displayed on the administrator terminal 20. FIG. The figure which shows an example of the terminal window screen 1000C displayed on the operation log | history reproduction | regeneration window 200. FIG. 12 is a flowchart showing a second embodiment of a skeleton GUI reproduction processing routine 240 executed by the administrator terminal 20. The figure which shows the other example of the terminal window screen 1000C displayed on the operation log reproduction | regeneration window 200. FIG. 10 is a flowchart illustrating a third embodiment of a skeleton GUI information acquisition routine 140 executed by the terminal 10; The flowchart which shows the detail of the object difference information extraction process 145A in the skeleton GUI information acquisition routine 140 of 3rd Example. The figure which shows an example of the skeleton GUI object description produced | generated by the skeleton GUI information acquisition routine 140 of 3rd Example. 12 is a flowchart showing a third embodiment of a skeleton GUI reproduction processing routine 240 executed by the administrator terminal 20. The figure which shows an example of the acquisition item selection screen 2000 displayed on the administrator terminal 20. FIG.

10: user terminal, 20: administrator terminal, 30: file server, 40 gateway,
50: Web server,
11, 21, 31: processor, 12, 23, 33: display device,
13A, 23A, 33: keyboard, 13B, 23B, 33B: mouse,
14, 24, 34: communication interface,
15, 16, 25, 26, 35, 35: memory,
17, 27, 37: data storage, 100, 300: OS,
110: Window display control module, 120: GUI information management module,
130, 330: Communication control module, 140: Skeleton GUI information acquisition routine,
180, 380: application program,
160: GUI object information file,
170: Skeleton GUI object information file,
240: Skeleton GUI regeneration routine,
340: Skeleton GUI object information management routine.

Claims (20)

A terminal operation history storage system having a file server and a user terminal connected to the file server via a network,
The user terminal is
A GUI for storing a plurality of graphic user interface (GUI) objects composed of a plurality of information items for designating the display / non-display state, display position and display contents of each window generated on the display screen in a tree structure format. A file storage unit for storing the object information file;
A GUI object management module that updates the content of the GUI object stored in the GUI object information file in response to a user operation on the display screen;
From the GUI object tree structure stored in the GUI object information file, a tree structure part consisting of GUI objects in the display state is extracted, and a local GUI object tree consisting of GUI objects from which a part of information items are removed is generated. A skeleton GUI information acquisition module that stores the skeleton GUI object information in time series as a skeleton GUI object information and transmits a series of skeleton GUI object information for a plurality of screens to the file server at a predetermined timing,
The terminal operation characterized in that the file server has a terminal operation history storage module for storing a series of skeleton GUI object information received from the user terminal as a terminal operation history in association with an identifier of the user of the user terminal. History storage system.   2. The terminal operation history storage system according to claim 1, wherein the skeleton GUI information acquisition module assigns time stamp information indicating a date and a time to each local GUI object tree.   The skeleton GUI information acquisition module generates each GUI object which is a constituent element of the local GUI object tree by excluding bitmap information from information items of each GUI object extracted from the GUI object tree structure. The terminal operation history storage system according to claim 1 or 2, characterized in that Each GUI object includes class information as one of the plurality of information items;
The local GUI object tree includes a GUI object group for each window including a plurality of GUI objects each of which is a hierarchy with a GUI object having a desktop screen specified by class information as a vertex. 5. The terminal operation history storage system described.   Each GUI object that is a constituent element of the local GUI object tree includes object class information, display state information indicating display / non-display distinction, object identifier, rectangular coordinate information indicating a display position, and display contents. The terminal operation history storage system according to claim 4, further comprising: text information to be displayed and front-to-back order information.   The terminal operation history storage according to any one of claims 1 to 5, wherein the skeleton GUI information acquisition module generates the local GUI object tree at a timing notified from the GUI object management module. system.   6. The terminal operation history storage system according to claim 1, wherein the skeleton GUI information acquisition module generates the local GUI object tree at a predetermined cycle.   The skeleton GUI information acquisition module uses the difference information between the local GUI object tree of the preceding screen stored as the skeleton GUI object information and the local GUI object tree generated on the new screen to determine the skeleton GUI object information. The terminal operation history storage system according to claim 1, wherein a new local GUI object tree to be stored is generated. Including a plurality of the user terminals connected to the network;
9. The file server stores the skeleton GUI object information received from the plurality of user terminals as a terminal operation history corresponding to the user identifier of each user terminal. The terminal operation history storage system described. An administrator terminal connected to the network, the administrator terminal comprising:
Based on the skeleton GUI object information received as the terminal operation history from the file server, the user terminal is displayed on the display screen of the administrator terminal by requesting the file server to transmit the terminal operation history by specifying a search condition The terminal operation history storage system according to claim 1, further comprising a skeleton GUI reproduction module that reproduces a window display screen serving as an operation history in a time-series manner. A user terminal connected to a file server via a network,
A network interface connected to the network;
A processor connected to the network interface;
A storage unit connected to the processor,
The storage unit has a tree structure including a plurality of graphic user interface (GUI) objects including a plurality of information items for designating the display / non-display state, display position, and display contents of each window generated on the display screen. Store the GUI object information file to be stored in the format,
The processor updates the content of the GUI object stored in the GUI object information file in response to a user operation on the display screen, and enters the display state from the GUI object tree structure stored in the GUI object information file. A tree structure part consisting of a certain GUI object is extracted, a local GUI object tree consisting of a GUI object from which a part of information items has been removed is generated, and is stored in time series as skeleton GUI object information. A user terminal that transmits a series of minute skeleton GUI object information to the file server at a predetermined timing via the network interface.   12. The user terminal according to claim 11, wherein the processor assigns a user terminal identifier to the series of skeleton GUI object information and transmits the information to the file server. The user terminal according to claim 11 or 12, wherein the processor gives time stamp information indicating a date and a time to each local GUI object tree.   The processor is configured to generate each GUI object that is a constituent element of the local GUI object tree by excluding bitmap information from information items of each GUI object extracted from the GUI object tree structure. The user terminal according to any one of claims 11 to 13. Each GUI object includes class information as one of the plurality of information items;
15. The GUI object group according to claim 14, wherein the local GUI object tree includes a GUI object group for each window composed of a plurality of GUI objects each of which has a GUI object with a desktop screen specified by class information as a vertex. The described user terminal.   Each GUI object that is a constituent element of the local GUI object tree includes object class information, display state information indicating display / non-display distinction, object identifier, rectangular coordinate information indicating a display position, and display contents. The user terminal according to claim 15, comprising text information to be displayed and front-to-back order information. The processor is
A GUI object management module for updating the content of the GUI object stored in the GUI object information file in response to a user operation on the display screen;
From the GUI object tree structure stored in the GUI object information file, a tree structure part consisting of GUI objects in the display state is extracted, and a local GUI object tree consisting of GUI objects from which a part of information items are removed is generated. A skeleton GUI information acquisition module that stores the skeleton GUI object information in time series as a skeleton GUI object information and transmits a series of skeleton GUI object information for a plurality of screens to the file server via the network interface at a predetermined timing. Run,
The user terminal according to claim 11, wherein the skeleton GUI information acquisition module generates the local GUI object tree at a timing notified from the GUI object management module.   The user terminal according to claim 17, wherein the skeleton GUI information acquisition module generates the local GUI object tree at a predetermined cycle.   The skeleton GUI information acquisition module uses the difference information between the local GUI object tree of the preceding screen stored as the skeleton GUI object information and the local GUI object tree generated on the new screen to determine the skeleton GUI object information. The user terminal according to claim 17, wherein a new local GUI object tree to be stored as is generated. An operation history management method for managing an operation history for a computer,
A tree structure of a plurality of graphic user interface (GUI) objects comprising a plurality of information items for designating the display / non-display state, display position and display contents of each window generated on the display screen provided by the computer Store the GUI object information file in the format
In response to a user operation on the display screen, the content of the GUI object stored in the GUI object information file is updated.
Extracting a tree structure part composed of GUI objects in a display state from the GUI object tree structure stored in the GUI object information file,
Generating a local GUI object tree composed of GUI objects from which some of the information items are removed, and storing them in chronological order as skeleton GUI object information;
An operation history management method comprising: transmitting a series of skeleton GUI object information for a plurality of screens to a management terminal file server that manages the computer at a predetermined timing.

Images