JP2017068378A - Incident management system, incident management method, and incident management program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an incident management system for achieving efficient and safe information management, an incident management method, and an incident management program.SOLUTION: An incident management system includes a log receiving unit 131, a storage unit 120, and a display data transmission unit 132. The log receiving unit 131 receives information on a file downloaded by a client 20, an operation on the client with respect to the file, and a status of an incident which triggers downloading the file, from the client 20. The storage unit 120 stores the file information, the operation, and the incident status received by the log receiving unit 131, in association with each other. The display data transmission unit 132 refers to the storage unit 120, to transmit data to be displayed on a predetermined client, to the predetermined client, while associating the file information, the operation, and the incident status.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an incident management system, an incident management method, and an incident management program.

  In recent years, the importance of managing personal information and the like has increased. On the other hand, there are many processes that companies perform by referring to personal information for business purposes. In view of this situation, various techniques for safely using and managing personal information have been proposed.

  For example, there is known an information management system that enables a user to refer to confidential information such as a password from outside (Patent Document 1). In addition, there is a program for deleting customer information downloaded when a client logs in to a server from the client's memory when logging out (Patent Document 2). Furthermore, when customer information is inquired from a mobile terminal outside a financial institution store, a system is also known in which, when a confirmation key displayed on the mobile terminal is pressed, the inquired customer information is erased from the memory unit of the mobile terminal. (Patent Document 3).

JP 2009-116726 A JP 2012-118658 A JP 2004-227413 A

  However, in the conventional system as described above, it is difficult to safely manage customer information when processing is executed with reference to customer information over a relatively long period of time. For example, when an incident occurs, a client connected to an in-house network downloads customer information from an in-house secure server. Then, over several days to several weeks, processing is executed on the client with reference to the customer information. When the process is completed, the customer information stored on the client is manually deleted by the user of the client. In such a case, the process of deleting the customer information from the client is left to the user's manual work. For this reason, the man-hour by the user for deletion of information is required. Further, it is difficult to completely eliminate the possibility that information is not erased or information is leaked due to carelessness of the user. Also, since information management depends on individual users, it is difficult to realize efficient and unified information management.

  In one aspect, an object is to provide an incident management system, an incident management method, and an incident management program capable of realizing efficient and safe information management.

  In the first plan, information on a file downloaded by the client, an operation on the client with respect to the file, and the status of the incident that triggered the download of the file are received from the client. The received file information, operation, and incident status are associated with each other and stored in the storage unit. With reference to the storage unit, data to be displayed on a predetermined client in association with file information, operation, and incident status is transmitted to the predetermined client.

  According to one embodiment of the present invention, efficient and safe information management can be realized.

FIG. 1 is a diagram illustrating an example of a configuration of an incident management system according to the first embodiment. FIG. 2 is a flowchart illustrating an example of the flow of incident management processing according to the first embodiment. FIG. 3 is a diagram illustrating an example of a configuration of customer information stored in the server according to the first embodiment. FIG. 4 is a diagram illustrating an example of a configuration of log information stored in the server according to the first embodiment. FIG. 5 is a diagram illustrating an example of a configuration of incident information stored in the server according to the first embodiment. FIG. 6 is a diagram illustrating an example of a configuration of log information stored by the client according to the first embodiment. FIG. 7 is a diagram for explaining an example of a process flow in the incident management system according to the first embodiment. FIG. 8 is a diagram for explaining another example of the processing flow in the incident management system according to the first embodiment. FIG. 9 is a diagram for explaining still another example of the processing flow in the incident management system according to the first embodiment. FIG. 10 is a diagram illustrating an example of the configuration of the incident management system according to the second embodiment. FIG. 11 is a flowchart illustrating an example of processing in the incident management server. FIG. 12 is a flowchart illustrating an example of processing in the material management server. FIG. 13 is a flowchart illustrating an example of the flow of the network monitoring process. FIG. 14 is a flowchart illustrating an example of the flow of the file monitoring process. FIG. 15 is a flowchart illustrating an example of the flow of log transmission processing. FIG. 16 is a flowchart illustrating an exemplary flow of a file operation monitoring process. FIG. 17 is a flowchart illustrating an exemplary flow of a customer information deletion request process. FIG. 18 is a flowchart illustrating an example of a processing flow when the user confirms the trail log on the client. FIG. 19 is a diagram for describing an example of a computer that executes an incident management program according to the first to third embodiments.

  Hereinafter, embodiments of an incident management system, an incident management method, and an incident management program disclosed in the present application will be described in detail with reference to the drawings. In addition, this invention is not limited by this embodiment.

(First embodiment)
The incident management system according to the first embodiment includes a server that stores customer information, and a client that is communicably connected to the server and that downloads customer information and executes incident processing. The incident management system tracks incident processing using customer information downloaded by the client, and manages whether customer information has been deleted from the client when the processing is completed. The incident management system then displays the incident processing status in association with the customer information. In addition, the incident management system transmits a deletion instruction to the client of the user having administrator authority when the customer information is not deleted from the client even after the incident processing is completed. In addition, the incident management system automatically transmits an instruction to delete the customer information from the client when the customer information is not deleted from the client even after the incident processing is completed.

[Explanation of terms]
First, terms used in the following description will be described.

  “Incident” means an event, an incident or an accident. “Incident” refers to an event that triggers a person in charge to process customer information with reference to customer information, such as customer complaints, questions, and trouble reports. In the following description, “incident” broadly encompasses events that cause the person in charge to perform some processing with reference to customer information. For example, one download of customer information can be associated with one incident. It is also possible to associate multiple customer information downloads with a single incident. In addition, an event that triggers processing executed with reference to information that requires high confidentiality other than customer information is also referred to as an “incident”.

  “Customer information” is secret information used by the incident management system. In the first embodiment, customer information will be described as an example. However, it is not limited to customer information, and includes business secrets and information that needs to be kept secret, such as information related to new businesses. In the case of processing a business secret or the like, the configuration of a storage unit that stores “customer information” to be described later is changed to match the business secret.

[Example of configuration of incident management system according to first embodiment]
FIG. 1 is a diagram illustrating an example of a configuration of an incident management system according to the first embodiment. The incident management system 1 includes a server 10 and clients 20, 30, and 40. The server 10 and the clients 20, 30, and 40 are connected via a network 50 so that they can communicate with each other.

  The server 10 manages customer information. The server 10 receives and accumulates incident processing logs executed by referring to customer information executed by the clients 20, 30, 40 from the clients 20, 30, 40 at a predetermined timing. Then, the server 10 transmits logs accumulated in a displayable format to a client of a user having administrator authority.

  The server 10 is, for example, a management server that manages information about company customers. In the example of FIG. 1, only the server 10 and the clients 20, 30, and 40 are shown, but a plurality of servers other than the server 10 may be provided and connected to the network 50. Then, the clients 20, 30, and 40 may be configured to access a plurality of servers including the server 10 by logging in to the in-house network. The server 10 may be physically one server or a virtual server constructed using a cloud.

  The clients 20, 30, and 40 are information processing terminals used by users who are permitted to access customer information. For example, the client 20, 30, 40 is permitted to access the server 10 when the user inputs a password and an ID (Identifier) on a predetermined screen and receives authentication.

  Further, among the users of the clients 20, 30, and 40, administrator authority is given to a predetermined user. A function of transmitting a display request for requesting log display to the server 10 is given to a client of a user having administrator authority. For example, the incident management program is downloaded from the server 10 to each client 20, 30, 40 and installed. The function of sending a display request for requesting log display to the server 10 is set to off by default. Then, the user who has been given administrator authority can execute the function by executing a process of turning on the function. Or you may build an incident management program so that each function of each client can be turned on and off from the server 10 side. In this case, each client may be configured not to execute switching of the function of the own device.

  Although FIG. 1 illustrates three clients 20, 30, and 40, the number of clients is not particularly limited. All clients having the authority to access customer information managed by the server 10 are configured in the same manner as the client 20.

  The network 50 connects the server 10 and the clients 20, 30, and 40 so that they can communicate with each other. The network 50 is a wide area network (WAN), a local area network, or any other network. The network 50 may be a wireless network or a wired network, or a combination of both.

[Example of configuration of server 10]
Next, an example of the configuration of the server 10 will be described with reference to FIG. The server 10 includes a communication unit 110, a storage unit 120, and a control unit 130.

  The communication unit 110 is a functional unit that realizes communication between the server 10 and other devices. The communication unit 110 includes, for example, a port and a switch. The communication unit 110 receives information transmitted from the clients 20, 30, and 40. The communication unit 110 distributes the received information to each unit in the server 10. In addition, the communication unit 110 transmits information to the clients 20, 30, and 40 in accordance with instructions from each unit in the server 10.

  The storage unit 120 stores information used for processing of each unit of the server 10 and information generated by the processing of each unit. A semiconductor memory element or a storage device can be employed for the storage unit 120. For example, as a semiconductor memory element, a VRAM (Video Random Access Memory), a RAM (Random Access Memory), a ROM (Read Only Memory), a flash memory (flash memory), and the like can be given. Examples of the storage device include storage devices such as a hard disk and an optical disk.

[Example of information stored in storage unit]
The storage unit 120 includes a customer storage unit 121, a log storage unit 122, and an incident storage unit 123.

  FIG. 3 is a diagram illustrating an example of a configuration of customer information stored in the server 10 according to the first embodiment. The customer information is customer information managed by the incident management system 1. For example, information related to a customer of a company that uses the incident management system 1 is stored in the customer storage unit 121.

  The customer information includes “customer ID”, “customer data”, and “incident ID”. “Customer ID” is an identifier for uniquely identifying each customer. “Customer data” is various information related to the customer specified by the customer ID. “Customer data” includes, for example, personal information such as a customer's name, age, address, and date of birth. The “customer data” includes information such as products purchased by the customer and services provided to the customer. In the example of FIG. 3, information specifying a file in which information related to the customer is stored is stored as “customer data”. “Incident ID” is an identifier that uniquely identifies an incident. For example, when a customer has filed a complaint so far and a process corresponding to the complaint has been executed by any client as an incident, an incident ID that identifies the incident is stored. If no incident has occurred so far, nothing is stored in the “incident ID” column.

  For example, in the example of FIG. 3, “customer data, xxxx.pdf”, “incident ID, i15-000001” are stored in association with “customer ID, cu0001”. This indicates that the data regarding the customer specified by the customer ID “cu0001” is stored in the file specified by “xxxx.pdf”. In addition, for the customer specified by the customer ID “cu0001”, the incident processing specified by “i15-000001” has been executed so far.

  FIG. 4 is a diagram illustrating an example of a configuration of log information stored in the server 10 according to the first embodiment. The log storage unit 122 stores log information received from the clients 20, 30, and 40 in an integrated manner. The log information includes “client ID”, “incident ID”, “file type”, “file size”, and “operation”. The “client ID” is an identifier that uniquely identifies the client. In particular, the client ID stored in the log storage unit 122 is information that identifies the client that transmitted the corresponding log. The “incident ID” is the same as the incident ID in FIG. “File type” is information for specifying the type of file operated on the client. For example, in the example of FIG. 4, information such as “pdf” and “xlsx” is stored as the file type. “Pdf” indicates that the file is in a pdf (portable document format) file format. “Xlsx” indicates that the file is a file in the xlsx format. “File size” indicates the size of the file operated on the client. “Operation” indicates the contents of the processing executed by the client on the file stored in association with each other.

  For example, in the example of FIG. 4, “incident ID, id15-000001” and “file type, pdf” are stored in association with “client ID, cl01”. This indicates that the client specified by the client ID “cl01” has executed the incident specified by the incident ID “id15-000001”. It also indicates that a pdf file has been used in the incident processing. Further, “file size, 23.1 MB” and “operation, download” are stored in association with “client ID, cl01”. This indicates that a pdf file having a file size of 23.1 MB has been downloaded by the client in the incident processing. In addition to “file type” and “file size”, information for specifying the operation target file may be acquired from the client as log information and stored.

  FIG. 5 is a diagram illustrating an example of a configuration of incident information stored in the server 10 according to the first embodiment. Incident information is information relating to incidents processed in the incident management system 1. Incident information is stored in the incident storage unit 123.

  The incident information includes “incident ID”, “incident content”, “state”, and “approval”. The “incident ID” is the same as the “incident ID” shown in FIGS. The “incident content” is information indicating what kind of content the incident is. For example, “server load over” and “application malfunction” can be stored as “incident content”. As the “incident content”, a category assumed in advance may be set, or a person in charge in charge of incident processing may input from a client and be transmitted to the server 10. “Status” indicates the status of processing for the incident. In the example of FIG. 5, “close” is stored as “state”. “Close” indicates that the processing related to the incident has been completed. For example, when a customer's complaint is answered and a customer's satisfaction message is received. In addition, if a failure occurs in the device or the like, the failure is solved. Information on “close” is transmitted from the client of the person in charge who has processed the incident. “Approval” is information indicating whether or not it has been confirmed that all customer information downloaded and used by the client in the processing of the incident has been deleted. Information stored in the “approval” is transmitted from the client of the manager who manages the person in charge of handling the incident. In the example of FIG. 5, “incident content, xxxxxxxx”, “state, close”, and “approved, yes” are stored in association with “incident ID, i15-000001”. This indicates that the content of the incident specified by “i15-000001” is “xxxxxxxx”, and the processing for the incident has been completed. It also indicates that the administrator has confirmed that all customer information downloaded to the client in the incident processing has been deleted.

  The configuration of information stored in each unit of the storage unit 120 can be arbitrarily changed within a range that does not hinder the operation of the incident management system 1.

[Example of controller configuration]
Next, returning to FIG. 1, an example of the configuration of the control unit 130 of the server 10 will be described. The control unit 130 controls the operation and function of the server 10. For example, various integrated circuits and electronic circuits can be adopted as the control unit 130. In addition, a part of the functional unit included in the control unit 130 can be another integrated circuit or an electronic circuit. For example, as an integrated circuit, ASIC (Application Specific Integrated Circuit) can be cited. Further, examples of the electronic circuit include a CPU (Central Processing Unit) and an MPU (Micro Processing Unit).

  The control unit 130 includes a log reception unit 131, a display data transmission unit 132, a file identification unit 133, an instruction transmission unit 134, and a deletion unit 135.

  The log receiving unit 131 receives a log of each client from the clients 20, 30, and 40 via the communication unit 110. The log received by the log receiving unit 131 is stored in the log storage unit 122.

  The log receiving unit 131 also receives notifications indicating that the incident processing has been completed from the clients 20, 30, and 40. In response to the received notification, the log receiving unit 131 updates the “state” of the incident stored in the incident storage unit 123.

  The log receiving unit 131 also receives a notification from the client of the user having administrator authority that the customer information used for the incident processing has been deleted from the client. In response to the received notification, the log receiving unit 131 updates the “approval” stored in the incident storage unit 123.

  In response to a display request transmitted from a client of a user having administrator authority, the display data transmission unit 132 transmits the requested log information to the client. For example, it is assumed that the client 40 is a client of a user having administrator authority. The client 40 transmits a display request to the server 10. Then, the communication unit 110 that has received the display request passes the request to the display data transmission unit 132. In response to the display request, the display data transmission unit 132 transmits the log information stored in the log storage unit 122 to the client 40 in a displayable format.

  Further, the display data transmitting unit 132 can process the log information and transmit it to the client 40 so that customer information specified by the file specifying unit 133 (described later) is highlighted.

  At a predetermined timing, the file specifying unit 133 determines whether there is an incident in which the processing of the incident itself has been completed, but the downloaded customer information has not yet been deleted from the client. For example, the file specifying unit 133 refers to the log storage unit 122 and the incident storage unit 123 at a predetermined timing. Then, the file specifying unit 133 determines whether there is an incident in which “state, close”, “approval, NA” is stored in the incident storage unit 123. When the file specifying unit 133 determines that there is an incident of “state, close” and “approved, NA”, the file specifying unit 133 refers to the log storage unit 122 and specifies the file downloaded corresponding to the incident. Note that the predetermined timing at which the file specifying unit 133 operates is, for example, when the server 10 receives a display request from a client of a user who has administrator authority. The predetermined timing is every preset time.

  The instruction transmission unit 134 transmits an instruction for deleting the customer information to the client when the incident processing has been completed but the customer information downloaded for processing has not been deleted yet.

  The deleting unit 135 automatically deletes the file specified by the file specifying unit 133 from the client. The deletion unit 135 transmits a deletion instruction to the client having the client ID stored in the log storage unit 122 in association with the file specified by the file specifying unit 133. The deletion instruction includes information for specifying a file (customer information) to be deleted.

[Example of client configuration]
An example of the configuration of the clients 20, 30, and 40 will be described with reference to FIG. The clients 20, 30, and 40 all have the same configuration. For this reason, in the following description, the client 20 will be described as an example.

  The client 20 includes a communication unit 210, a storage unit 220, a control unit 230, a display unit 240, and an input / output unit 250.

  The communication unit 210 is a functional unit that realizes communication between the client 20 and the server 10 or the like. The communication unit 210 includes, for example, a port and a switch. The communication unit 210 receives information transmitted from the server 10. Further, the communication unit 210 transmits the log generated in the client 20 to the server 10.

  The storage unit 220 stores information used for processing of each unit of the server 10 and information generated by the processing of each unit. A semiconductor memory element or a storage device can be adopted as the storage unit 220. For example, as a semiconductor memory element, a VRAM (Video Random Access Memory), a RAM (Random Access Memory), a ROM (Read Only Memory), a flash memory (flash memory), and the like can be given. Examples of the storage device include storage devices such as a hard disk and an optical disk.

  The storage unit 220 includes a file storage unit 221 and a log storage unit 222.

  The file storage unit 221 stores a file downloaded for incident processing. In the example of FIG. 1, for convenience of explanation, one file storage unit 221 is shown, but actually, the downloaded file is not necessarily stored in one place, and a plurality of storage areas in the client 20 are stored. In some cases, it is stored in a distributed manner.

  The log storage unit 222 stores a log of processing executed in the client 20 with respect to a file downloaded for incident processing. In the first embodiment, when customer information is downloaded, the client 20 generates a log with one download as one incident. When customer information to be managed by the server 10 is downloaded by the client 20, an incident ID is assigned in association with the customer information. The log storage unit 222 stores information related to customer information downloaded in association with the incident ID.

  FIG. 6 is a diagram illustrating an example of a configuration of log information stored by the client according to the first embodiment. FIG. 6A is an example of log information generated by the client 20. FIG. 6B is an example of log information generated by the client 30. FIG. 6C is an example of log information generated by the client 40.

  The log information includes “incident ID”, “file type”, “file size”, and “operation”. The configuration of log information generated by the client is the same as the configuration of log information stored in the server 10 except that the “client ID” is not included. When log information is transmitted from each client to the server 10, a client ID is added to the log information. Or, when the server 10 stores the log information, the client ID of the transmission source is added.

  In the example of FIG. 6A, the client 20 downloads a file with the file type “pdf” and the file size “23.1 MB” and then deletes it. In this case, it is presumed that the incident processing using the file has already been completed and the file has been appropriately deleted. In the example of FIG. 6C, the client 40 has downloaded a file of the file type “pdf” and the file size “23.1 MB” for the incident processing of the incident ID “id15-000003”. Thereafter, the client 40 updates the downloaded file, but has not yet deleted it. In this case, if “state, close” is stored in the incident storage unit 123, it means that the incident has been processed but has not been deleted yet. On the other hand, if “state, NA” is stored in the incident storage unit 123, the incident processing is not completed.

  The control unit 230 controls the operation and function of the client 20. For example, various integrated circuits and electronic circuits can be adopted as the control unit 230. In addition, a part of the functional unit included in the control unit 230 can be another integrated circuit or an electronic circuit. For example, as an integrated circuit, ASIC (Application Specific Integrated Circuit) can be cited. Further, examples of the electronic circuit include a CPU (Central Processing Unit) and an MPU (Micro Processing Unit).

  The control unit 230 includes a download unit 231, a monitoring unit 232, a log transmission unit 233, an end notification transmission unit 234, a display request transmission unit 235, a confirmation notification transmission unit 236, and a deletion unit 237.

  The download unit 231 downloads customer information specified by the instruction input in response to the user instruction input. In the example of FIG. 1, the download unit 231 downloads customer information stored in the storage unit 120 of the server 10. However, the download unit 231 may download the customer information from another server when the other server or the like stores the customer information.

  The monitoring unit 232 monitors the processing in the client 20 for the customer information file downloaded by the download unit 231. For example, when a customer information file is downloaded, the monitoring unit 232 assigns an incident ID in association with the download. The incident ID is set to be a unique identifier in the incident management system 1. Then, the monitoring unit 232 associates the incident ID with the type, size, and operation of the file and stores them in the log storage unit 222. In addition, the monitoring unit 232 monitors the operation after downloading for the customer information file stored in association with the incident ID. For example, when the file is updated or deleted, the monitoring unit 232 causes the log storage unit 222 to store the operation contents in association with the incident ID, file type, and file size.

  The log transmission unit 233 transmits the log information stored in the log storage unit 222 to the server 10 at a predetermined timing. For example, the log transmission unit 233 transmits log information to the server 10 every predetermined time. For example, the log transmission unit 233 transmits the log information to the server 10 every time the log information is updated. For example, when the log transmission unit 233 receives a request from the server 10, the log transmission unit 233 transmits log information to the server 10.

  When the process corresponding to one incident is completed, the end notification transmission unit 234 receives an input indicating that the process of the incident has been completed from the user. Then, the end notification transmission unit 234 transmits a notification indicating that the processing of the incident has ended to the server 10. In addition, you may comprise so that the notification which shows that the process of the incident was complete | finished can be transmitted by information processing apparatuses other than the client 20. FIG. For example, it may be configured such that a client of a user having administrator authority can transmit the information. A notification indicating that the incident processing has been completed is received by the log receiving unit 131, and the “state” stored in the incident storage unit 123 is updated to “close”.

  The display request transmission unit 235 is mounted only on a client of a user having administrator authority. The display request transmission unit 235 transmits a display request for requesting transmission of log information to the server 10. The display request transmission unit 235 may be configured to request the server 10 to transmit only a predetermined range of log information. For example, the display request transmission unit 235 can transmit a display request for requesting to transmit log information corresponding to only a predetermined client or a predetermined incident among the log information to the server 10. Further, the display request transmission unit 235 is configured to transmit a display request for requesting transmission of only log information corresponding to an incident for which processing has been completed but deletion of customer information has not been completed to the server 10. Also good.

  The confirmation notification transmission unit 236 transmits a notification that the customer information used for the incident processing has been deleted from the client. Similar to the display request transmission unit 235, the confirmation notification transmission unit 236 is installed only in a client of a user having administrator authority. A user having administrator authority confirms data transmitted in response to a display request, and transmits a notification to the server 10 if customer information has been deleted for an incident for which processing has been completed. When the log receiving unit 131 of the server 10 receives the notification, the log receiving unit 131 updates the “approval” in the incident storage unit 123.

  When the deletion unit 237 receives a deletion instruction from the deletion unit 135 of the server 10, the deletion unit 237 deletes the customer information of the incident specified by the deletion instruction from its own device.

  The display unit 240 displays various information in a visually recognizable format. The display unit 240 is, for example, a liquid crystal monitor. The display unit 240 displays the log information transmitted from the server 10 in a viewable format in response to the display request transmitted by the display request transmission unit 235. For example, the display unit 240 can highlight log information corresponding to an incident for which processing has been completed but customer information has not been deleted.

  The input / output unit 250 receives input of information and outputs information. The input / output unit 250 is, for example, a mouse, a keyboard, a microphone, or the like. The input / output unit 250 is also a speaker or the like.

[Rough flow of incident management processing]
FIG. 2 is a flowchart illustrating an example of the flow of incident management processing according to the first embodiment. As shown in FIG. 2, in the incident management process, first, operations in the clients 20, 30, and 40 are monitored to accumulate log information (step S21). Then, the log information accumulated in the server 10 is transmitted from each client 20, 30, 40. The server 10 collects and accumulates log information transmitted from each of the clients 20, 30, and 40 (step S22). When the server 10 receives the display request from the client, the server 10 transmits log information in response to the display request and causes the client to display (step S23). This is a general flow of incident management processing.

  The incident management process may be configured so that the process of the monitoring unit 232 starts when the client information is downloaded by the client. In addition, the incident management process may be configured such that monitoring of the operation of the client 20 by the monitoring unit 232 is always executed regardless of the presence or absence of customer information by the client.

[Log information display processing in the incident management system]
FIG. 7 is a diagram for explaining an example of a processing flow in the incident management system 1 according to the first embodiment. FIG. 7 shows an example of processing in the incident management system 1 in which the server 10 transmits and displays log information in response to a display request from a client of a user having administrator authority. In the example of FIG. 7, it is assumed that the client 30 is a client of a user having administrator authority.

  First, the client 20 downloads a customer information file (step S701). When the customer information file is downloaded, the monitoring unit 232 assigns an incident ID in association with the download of the file, and stores the log information in the log storage unit 222. Then, the monitoring unit 232 monitors the operation content on the client 20 for the file. The log transmission unit 233 determines whether or not a predetermined time has elapsed since the file was downloaded (step S702). If it is determined that the predetermined time has not elapsed, the log transmission unit 233 repeats the process of step S702. On the other hand, when determining that the predetermined time has elapsed, the log transmission unit 233 transmits the log information stored in the log storage unit 222 to the server 10 (step S703). The server 10 receives the log information transmitted from the log transmission unit 233 and stores it in the log storage unit 122 (step S704). In the client 20, the end notification transmission unit 234 determines whether there is an input indicating the end of the process from the user in response to each incident (step S705). If it is determined that there is no input indicating the end (No at Step S705), the process returns to Step S702, and the process of the monitoring unit 232 regarding the incident continues. On the other hand, if it is determined that there is an input indicating the end (Yes in step S705), the end notification transmission unit 234 transmits a notification indicating the end of the process to the server 10 (step S706). The server 10 that has received the notification stores “state, close” in the corresponding location of the incident storage unit 123 (step S707). Then, the end notification transmission unit 234 determines whether the file related to the incident has been deleted (step S708). If it is determined not to be deleted (No at Step S708), monitoring by the monitoring unit 232 and log transmission by the log transmission unit 233 are continued (Step S709). On the other hand, if it is determined that the file has been deleted (Yes at step S708), the end notification transmission unit 234 ends the process.

  On the other hand, a display request is transmitted from the client 30 to the server 10 (step S710). The server 10 refers to the log storage unit 122 and the incident storage unit 123, and determines whether there is a file that has not been deleted, although the processing corresponding to the incident has been completed (step S711). That is, the file specifying unit 133 of the server 10 determines whether there is an incident ID “approved, NA” although “incident, close” is stored in the incident storage unit 123. Then, the file specifying unit 133 refers to the log storage unit 122 and specifies a file associated with the incident ID (step S711). Then, the file specifying unit 133 passes information regarding the specified file to the display data transmitting unit 132. When there is a file specified by the file specifying unit 133 among the log information corresponding to the display request (Yes in step S711), the display data transmitting unit 132 updates the log information so that the information of the file is highlighted. (Step S712). On the other hand, when there is no file specified by the file specifying unit 133 (No at Step S711), the display data transmitting unit 132 does not execute the process for highlighting (Step S713). Then, the display data transmission unit 132 transmits display data including the requested log information to the client 30 (step S714). Then, the client 30 that has received the display data displays the received display data on the display unit (step S715). This ends the process.

  In the process of FIG. 7, the server 10 that has received the display request executes a process for highlighting a part of the log information. However, the process for highlighting (steps S711 to S713 in FIG. 7) may be omitted. In this case, in the server 10 that has received the display request, the display data transmission unit 132 extracts log information corresponding to the display request and transmits it to the client 30 as it is.

[Deletion instruction transmission process in incident management system]
FIG. 8 is a diagram for explaining another example of the processing flow in the incident management system 1 according to the first embodiment. In the example of FIG. 8, in the incident management system 1, the server 10 checks the log storage unit 122 at a predetermined timing, and sends a deletion instruction to delete customer information to the client 30 of the user having administrator authority. To do.

  The processes from steps S801 to S809 on the right side of FIG. 8 are the same as the processes from steps S701 to S709 in FIG. Therefore, description of the processing of steps S801 to S809 is omitted.

  In the server 10, the file specifying unit 133 determines whether or not a predetermined timing has come (step S810). If it is determined that the predetermined timing is not reached, the file specifying unit 133 repeats the process of step S810. On the other hand, if it is determined that the predetermined timing has come, the file specifying unit 133 determines whether there is an incident for which the processing has been completed but the customer information has not been deleted (step S811). That is, the file specifying unit 133 determines whether or not there is an incident ID “approved, NA” although “incident, close” is stored in the incident storage unit 123. If it is determined that there is no corresponding incident ID (No at Step S811), the file specifying unit 133 returns to Step S810. On the other hand, when it is determined that the corresponding incident ID exists (step S811, affirmative), the file specifying unit 133 notifies the instruction transmitting unit 134 to that effect. The instruction transmission unit 134 transmits a notification prompting deletion of the file used for processing the incident specified by the corresponding incident ID to the client 30 of the user having administrator authority (step S812). This ends the process.

[Automatic deletion process in the incident management system]
FIG. 9 is a diagram for explaining still another example of the processing flow in the incident management system 1 according to the first embodiment. In the example of FIG. 9, when the incident information has been processed but the customer information is not deleted, the server 10 notifies the client of the person in charge of the incident to delete the customer information.

  The processing from steps S901 to S909 on the right side of FIG. 9 is the same as the processing from steps S701 to S709 in FIG. Therefore, description of the processing of steps S901 to S909 is omitted.

  The file specifying unit 133 of the server 10 determines whether or not a predetermined timing has come (step S910). If it is determined that the predetermined timing has not been reached, the file specifying unit 133 repeats the process of step S910. On the other hand, if it is determined that the predetermined timing has come, the file specifying unit 133 determines whether there is an incident whose response has been completed but customer information has not been deleted (step S911). That is, the file specifying unit 133 determines whether or not there is an incident ID “approved, NA” although “incident, close” is stored in the incident storage unit 123. If it is determined that there is no corresponding incident ID (No at Step S911), the file specifying unit 133 returns to Step S910. On the other hand, if it is determined that there is a corresponding incident ID (Yes in step S911), the file specifying unit 133 specifies a person in charge of handling the incident specified by the incident ID, that is, a client (step S912). Then, the file identification unit 133 passes the identified client information and the incident ID information to the instruction transmission unit 134. The instruction transmission unit 134 transmits a deletion notification that notifies the specified client 30 to delete the file used in the specified incident processing (step S913). Upon receiving the deletion notification, the deletion unit of the client 30 deletes the notified file (step S914). Then, the monitoring unit stores the file deletion in the log storage unit. The log transmission unit transmits log information recording that the file has been deleted to the server 10 (step S915). This ends the process.

[Effect of the first embodiment]
The incident management system according to the first embodiment includes a reception unit (log reception unit), a storage unit, and a display data transmission unit. The receiving unit receives from the client information on the file downloaded by the client, the operation on the client for the file, and the status of the incident that triggered the download of the file. The storage unit stores the file information received by the receiving unit, the operation, and the incident status in association with each other. The display data transmission unit refers to the storage unit and transmits data to be displayed on the predetermined client in association with the file information, the operation, and the incident status to the predetermined client. In this way, the incident management system can track the processing of the file downloaded by the client and display it in association with the status of the incident that triggered the download. For this reason, the user can easily confirm whether or not the downloaded file has been subjected to appropriate processing in view of the incident status. Therefore, the user can easily check and manage the status of the downloaded file. For this reason, according to the incident management system of the first embodiment, efficient and safe information management can be realized.

  In the incident management system according to the first embodiment, the receiving unit receives information on a file downloaded by the client and whether or not a deletion operation on the client is performed on the file. The receiving unit receives whether or not the processing of the incident that triggered the download of the file has been completed. The storage unit stores the file information received by the receiving unit, the presence / absence of the deletion operation, and whether or not the incident processing is completed in association with each other. The display data transmission unit transmits to the predetermined client data that displays the presence / absence of the deletion operation and whether or not the incident processing is completed in a recognizable manner on the predetermined client in association with the file information. For this reason, the user can easily determine whether customer information does not remain on the client even though the incident has been processed. For this reason, efficient and safe information management can be realized.

  The incident management system according to the first embodiment further includes a specifying unit (file specifying unit) and a transmitting unit (instruction transmitting unit). The identifying unit identifies the file information stored in association with the information indicating that the deletion operation is not performed and the incident processing is completed, among the file information stored in the storage unit, at a predetermined timing. The transmitting unit transmits information on the file specified by the specifying unit to a predetermined client. For this reason, the user can easily identify an incident in which customer information remains on the client even though the incident has been processed. The user can easily take measures such as deleting customer information corresponding to the identified incident. For this reason, efficient and safe information management can be realized.

  The incident management system according to the first embodiment further includes a specifying unit (file specifying unit) and a transmitting unit (deleting unit). The identifying unit identifies the file information stored in association with the information indicating that the deletion operation is not performed and the incident processing is completed, among the file information stored in the storage unit, at a predetermined timing. The transmission unit transmits an instruction to delete information on the file from the client that has downloaded the information on the file specified by the specification unit to the client. For this reason, according to the incident management system, when the customer information remains on the client even though the incident processing is completed, the customer information can be easily deleted. For this reason, efficient and safe information management can be realized.

[Modification]
The incident management system 1 according to the first embodiment displays the incident status, the presence / absence of deletion of customer information, and customer information in association with each other and displays them on a user client having administrator authority. Further, when there is customer information that has not been deleted from the client after the incident processing is completed, the incident management system 1 transmits a deletion instruction to the client of the user having administrator authority. In addition, when there is customer information that has not been deleted from the client after the incident processing is completed, the incident management system 1 transmits a deletion instruction for automatically deleting the customer information from the client. However, the present invention is not limited to this, and the server may be configured to execute any one or two of display processing, deletion instruction transmission processing, and automatic deletion processing. In this case, you may delete the part which is not related to the process performed among the display data transmission parts 132, the file specification part 133, the instruction | indication transmission part 134, and the deletion part 135 which are shown in FIG. Similarly, a part of the control unit 230 that is not related to the process to be executed may be deleted for the client.

  In the first embodiment, the server 10 is a server that stores customer information. However, the present invention is not limited to this, and a secure server that stores customer information may be provided separately from the server 10. And when client 20,30,40 downloads customer information from a secure server, you may comprise so that the log generation in client 20,30,40 may start. Moreover, when the client 20, 30, 40 downloads customer information from the secure server, the secure server may be notified to the server 10.

  In the first embodiment, the automatic deletion process is executed immediately after the server 10 checks the information stored in the storage unit 120 at a predetermined timing. However, the present invention is not limited to this, and the incident management system may be configured such that the customer information is allowed to remain for a predetermined period after the incident processing is completed, and is automatically deleted when the predetermined period elapses. For example, when “state, close” is stored in the incident storage unit 123, a time stamp indicating the time point is also stored. Then, when specifying the file, the file specifying unit 133 specifies a file that has passed three days since “close” was stored. Then, the instruction transmission unit 134 transmits an instruction to delete the specified file.

  Further, when the automatic deletion process is executed, the length of time from the storage of “close” to the deletion may be changed according to the incident content (FIG. 5). For example, one week may be used if the incident content is “complaint processing”, and one month may be used if the incident content is “insufficient server capacity”.

  In the first embodiment, it is assumed that only a user client having administrator authority can request transmission of log information. Not limited to this, all clients may be able to request transmission of log information. Further, a client that can request transmission of log information may be arbitrarily set.

  In the first embodiment, the file specifying unit 133 determines that the customer information corresponding to the incident of “state, close” and “approval, NA” has not been deleted. Then, display processing, deletion instruction transmission processing, and automatic deletion processing are executed. However, even if the incident is “status, close”, “approval, NA”, the customer information may be deleted. Therefore, after the incident of “state, close” and “approval, NA” is specified, the file specifying unit 133 further determines whether “operation, deletion” is stored in the log storage unit 122 for the corresponding customer information. You may provide the step which determines. The display format may be changed between an undeleted file and an unapproved file. In addition, the instruction content to be transmitted to the administrator may be changed between an undeleted file and an unapproved file. Alternatively, the automatic deletion process may be executed only when there is an undeleted file among the unapproved files.

(Second Embodiment)
FIG. 10 is a diagram illustrating an example of the configuration of the incident management system 2 according to the second embodiment.

  As shown in FIG. 10, the incident management system 2 according to the second embodiment includes an incident management server 60, a material management server 70, a totaling server 10A, and clients 20A and 30A. The incident management server 60, the material management server 70, the aggregation server 10A, and the clients 20A and 30A are connected to each other via an arbitrary network so that they can communicate with each other.

  The incident management server 60 is a server that manages incident information. When an incident occurs, information related to the incident is stored in the database 61 of the incident management server 60. Incident information stored in the database 61 is the same as the incident information shown in FIG. The incident management server 60 includes a network control unit 62 that controls transmission / reception of information with the clients 20A, 30A and the like.

  The material management server 70 is a server that manages information about customers used in the incident management system 2. The material management server 70 includes a database 71. The database 71 stores customer information. The configuration of the customer information is the same as the customer information shown in FIG. The material management server 70 also includes a network control unit 72 that controls transmission / reception of information with the clients 20A, 30A and the like.

  The aggregation server 10 </ b> A receives the trail log from the client 20 </ b> A and stores it in the trail log database 11. The aggregation server 10 </ b> A includes a log editing unit 12 and a network control unit 13. The log editing unit 12 edits a log stored in the trail log database 11 in response to a display request from the client 30A. The network control unit 13 controls transmission / reception of information with the clients 20A, 30A and the like. When receiving the display request from the client 30A, the network control unit 13 passes the request to the log editing unit 12. In addition, the network control unit 13 transmits the log edited by the log editing unit 12 in response to the display request to the client 30A.

  The incident management server 60, the material management server 70, and the aggregation server 10A collectively implement the same functions as the server 10 shown in FIG.

  The client 20A is an information processing terminal used by an incident responder who executes processing in response to an incident. The client 20A realizes the same function as the client 20 shown in FIG. The client 20 </ b> A includes a network control unit 21, a network monitoring unit 22, a file monitoring unit 23, a display unit 24, an input / output control unit 25, and a storage unit 26.

  The network control unit 21 controls transmission / reception of information with the incident management server 60, the material management server 70, the aggregation server 10A, and the like.

  The network monitoring unit 22 monitors information exchanged on the network. For example, the network monitoring unit 22 detects a packet downloaded from the material management server 70. Further, the network monitoring unit 22 detects a packet downloaded from the incident management server 60.

  The file monitoring unit 23 monitors file processing executed on the client 20A. For example, the file monitoring unit 23 monitors download executed by the application and generation of a cache file. Further, the file monitoring unit 23 detects a process for creating an actual file from the temporary file.

  The display unit 24 includes a display screen such as a liquid crystal monitor and presents information in a visually recognizable format. The display 24 may be presented in a format such as a voice, as long as the information can be presented in a recognizable format. However, in the present embodiment, it is presented in a visually recognizable format.

  The input / output control unit 25 controls the input of information to the client 20A and the output of information from the client 20A. The input / output control unit 25 includes, for example, a mouse, a keyboard, a speaker, and the like.

  The storage unit 26 stores customer data downloaded from the material management server 70. The storage unit 26 stores a trail log accumulated in the client 20A. The trail log is a log of processing executed on customer data on the client. The trail log may have the same configuration as the log information shown in FIG.

  The client 30A is an information processing terminal used by the administrator. The client 30A includes a network control unit 31, a display unit 32, and an input / output control unit 33.

  The network control unit 31 has the same function and configuration as the network control unit 21 of the client 20A.

  The display unit 32 has the same function and configuration as the display unit 24 of the client 20A.

  The input / output control unit 33 controls input of information to the client 30A and output of information from the client 30A. The input / output control unit 33 has the same function and configuration as the input / output control unit 25 of the client 20A.

[Example of processing in incident management server 60]
FIG. 11 is a flowchart illustrating an example of processing in the incident management server 60. As shown in FIG. 11, the incident management server 60 receives a request for referring to an incident from the aggregation server 10A, the client 20A, or the like. When the incident management server 60 receives a request to refer to an incident (Yes in step S1101), the incident management server 60 extracts information on the incident specified by the request from the database and transmits it to the request source (step S1102). On the other hand, when the request has not been received (No at Step S1101), the incident management server 60 ends the process.

[An example of processing in the material management server 70]
FIG. 12 is a flowchart illustrating an example of processing in the material management server 70. The material management server 70 receives a request for customer information corresponding to the incident from the aggregation server 10A, the client 20A, and the like. When the material management server 70 determines that the request has been received (step S1201, affirmative), the document management server 70 transmits the customer information specified by the request to the request source (step S1202). If the material management server 70 determines that the request has not been received (No at Step S1201), the processing ends.

[Example of Flow of Network Monitoring Processing in Client 20A]
FIG. 13 is a flowchart illustrating an example of the flow of the network monitoring process. When the download process is executed, the network monitoring unit 22 of the client 20A determines whether the download is from the material management server 70 (step S1301). If it is determined that the download is from the material management server 70 (Yes at Step S1301), an area for storing the monitoring target file information is prepared in the storage unit 26 (Step S1302). The monitoring target file information is information on a file to be monitored in the incident management process. The monitoring target file information corresponds to, for example, the incident ID, file type, file size, and operation information shown in FIG. Then, the network monitoring unit 22 stores the monitoring target file information in the prepared area. For example, the network monitoring unit 22 stores operation information for the customer information file as a log in the storage unit 26 (step S1303). For example, as shown in the log information in FIG. 4, the file type, file size, file name, and the like of the downloaded file are stored in the storage unit 22. If it is determined in step S1301 that the download is not from the material management server (No in step S1301), the network monitoring unit 22 ends the process.

[Example of flow of file monitoring process in client 20A]
FIG. 14 is a flowchart illustrating an example of the flow of the file monitoring process. The file monitoring unit 23 of the client 20A monitors operations for files executed on the client 20A. When the operation is detected, the file monitoring unit 23 determines whether the operation is an operation on the monitoring target file (step S1401). When it is determined that the operation is for the monitoring target file (Yes at Step S1401), the file monitoring unit 23 saves the operation information in a log (Step S1402). For example, the file monitoring unit 23 stores operation information in the corresponding monitoring target file information area prepared by the network monitoring unit 22 in the storage unit 26. If it is determined that the operation is not an operation on the monitoring target file (No at Step S1401), the file monitoring unit 23 ends the process.

[Example of flow of log transmission processing in client 20A]
FIG. 15 is a flowchart illustrating an example of the flow of log transmission processing. The input / output control unit 25 of the client 20A determines whether or not a preset time (log transmission time) has come (step S1501). When determining that the preset time has come (step S1501, affirmative), the input / output control unit 25 transmits the log stored in the storage unit 26 to the aggregation server 10A (step S1502). On the other hand, if it is determined that the preset time has not been reached (No at step S1501), the input / output control unit 25 ends the process.

[Example of flow of file operation monitoring process in client 20A]
FIG. 16 is a flowchart illustrating an exemplary flow of a file operation monitoring process. The file monitoring unit 23 starts monitoring the file system when the monitoring target file is set. For example, when the network monitoring unit 22 prepares an area for monitoring target file information, the file monitoring unit 23 starts monitoring the file system. First, the file monitoring unit 23 determines whether an event is detected (step S1601). If it is determined that it has been detected (Yes at step S1601), the file monitoring unit 23 determines the event type. When the event type is a deleted event (step S1602), the file monitoring unit 23 stores “delete” (step S1603) as “operation” in the log (step S1604). If the event type is a created event (step S1605), the file monitoring unit 23 determines whether there is a deleted event immediately before (step S1606). When there is a Deleted event immediately before (Yes at Step S1606), the file monitoring unit 23 stores “Move” (Step S1607) as “Operation” in the log (Step S1604). If there is no Deleted event immediately before (No at Step S1606), the file monitoring unit 23 stores “Copy” (Step S1608) as “Operation” in the log (Step S1604). If the event type is a changed event (step S1609), the file monitoring unit 23 determines whether there is a deleted event immediately before (step S1610). If there is a Deleted event immediately before (Yes in step S1610), the file monitoring unit 23 stores “overwrite movement” (step S1611) in the log (step S1604). On the other hand, when there is no Deleted event immediately before (No at Step S1610), the file monitoring unit 23 stores “overwrite copy” (Step S1612) in the log (Step S1604). Further, when the event type is a Renamed event (step S1613), the file monitoring unit 23 stores “name change” (step S1614) in the log (step S1604). This ends the process. As described above, the file monitoring unit 23 converts the operation at the file system level into the user operation level and stores it as a log.

[Example of Flow of Customer Information Deletion Request Processing in Aggregation Server 10A]
FIG. 17 is a flowchart illustrating an exemplary flow of a customer information deletion request process. The aggregation server 10A stores the trail log received from the client 20A in the database 11. The log editing unit 12 edits the stored trail log (step S1701). Then, the log editing unit 12 acquires and confirms the incident state associated with the log from the incident management server 60 (step S1702). For example, the log editing unit 12 confirms information corresponding to the “state” in FIG. Then, the log editing unit 12 determines whether or not the confirmed information indicates “Close”, that is, indicates that the process corresponding to the incident has ended (step S1703). When it determines with it being "Close" (step S1703, affirmation), the log edit part 12 confirms the customer information corresponding to the said incident with reference to a trail log (step S1704). The log editing unit 12 determines whether there is customer information that has not been deleted (step S1705). When it is determined that there is customer information that has not been deleted (Yes in step S1705), the log editing unit 12 transmits a deletion request to the person in charge (step S1706). For example, the log editing unit 12 transmits a deletion request to the client of the person in charge of the incident specified by the trail log. On the other hand, when the log editing unit 12 determines that the incident state is not “Close” (No in step S1703), the process ends. In addition, when the log editing unit 12 determines that there is no customer information that has not been deleted (No in step S1705), the process is also terminated.

[Example of processing flow when checking trail log]
FIG. 18 is a flowchart illustrating an example of a processing flow when the user confirms the trail log on the client 30A. First, a request for an incident confirmation screen is transmitted from the client 30A (step S1801). The request for the incident confirmation screen is the same as the display request in the first embodiment. The incident confirmation screen is, for example, a screen that displays information similar to the log information shown in FIG.

  In the aggregation server 10A that has received the incident confirmation screen request (step S1802), the log editing unit 12 edits the trail log in response to the request (step S1803). Then, the log editing unit 12 transmits the edited trail log to the client 30A via the network control unit 13 (step S1804).

  The client 30A determines whether the screen requested from the aggregation server 10A has been received (step S1805). If it is determined that it has not been received (No at Step S1805), the client 30A repeats the determination at Step S1805. On the other hand, if it is determined that it has been received (step S1805, positive), the client 30A displays a screen and allows the user to check the incident processing status (step S1806). The process ends here.

[Effects of Second Embodiment]
Similar to the incident management system 1 according to the first embodiment, the incident management system 2 according to the second embodiment realizes efficient and safe information management. In the incident management system 2 according to the second embodiment, the file monitoring unit detects information on file movement, copy, overwrite movement, and overwrite copy operations on the client. Then, the network control unit 13 (reception unit) of the aggregation server 10 </ b> A receives information on the operation on the client for moving, copying, overwriting moving, and overwriting copying from the client. For this reason, the aggregation server can edit the trail log by acquiring the details of the operation executed on the client in detail. For this reason, the state of the downloaded file can be displayed in detail on the administrator's client. For this reason, the incident management system according to the second embodiment can realize efficient and safe information management.
(Third embodiment)

  Although the embodiments related to the disclosed apparatus have been described above, the present invention may be implemented in various different forms other than the above-described embodiments. Therefore, another embodiment included in the present invention will be described below.

[Implementation by cloud computing]
The disclosed incident management program can be implemented in a server constituting a cloud system and used to monitor downloading of customer information by a client via the cloud system.

[Distribution and integration]
Each component of each illustrated apparatus does not necessarily need to be physically configured as illustrated. In other words, the specific form of distribution / integration of each device is not limited to that shown in the figure, and all or a part thereof may be functionally or physically distributed or arbitrarily distributed in arbitrary units according to various additions or usage conditions. Can be integrated and configured.

[Incident Management Program]
In addition, the various processes described in the above embodiments are performed by distributing a prepared program from a computer such as a server to a computer such as a tablet terminal or a notebook computer, and the server and the computer cooperating with each other. Can be realized. In the following, an example of a computer that executes an incident management program having the same function as that of the above-described embodiment will be described with reference to FIG.

  FIG. 19 is a diagram for describing an example of a computer that executes an incident management program according to the first to third embodiments. As illustrated in FIG. 19, the computer 1000 includes an operation unit 1100, a display 1200, and a communication unit 1300. The computer 1000 further includes a CPU (Central Processing Unit) 1400, a ROM (Read-Only Memory) 1500, a RAM (Random Access Memory) 1600, and an HDD (Hard Disk Drive) 1700. These units 1100 to 1700 are connected via a bus 1800.

  As shown in FIG. 19, the HDD 1700 includes a module that exhibits the same function as each unit included in the server 10 described in the first embodiment, and a module that performs a function similar to each unit included in the client 20. , An incident management program 1700a that can be implemented is stored in advance. The incident management program 1700a may be integrated or separated as appropriate, as with each component shown in FIG. In other words, all the data stored in the HDD 1700 need not always be stored in the HDD 1700, and only the data necessary for processing may be stored in the HDD 1700.

  Then, the CPU 1400 reads each module of the incident management program 1700a from the HDD 1700 and expands it in the RAM 1600. Thereby, as shown in FIG. 19, the incident management program 1700a functions as an incident management process 1600a. The incident management process 1600a expands various data read from the HDD 1700 to an area allocated to itself on the RAM 1600, and executes various processes based on the expanded data. The incident management process 1600a includes processing executed by each processing unit shown in FIG. In addition, each processing unit virtually realized on the CPU 1400 does not always require that all processing units operate on the CPU 1400, and only a necessary processing unit may be realized virtually.

  The incident management program 1700a is not necessarily stored in the HDD 1700 or the ROM 1500 from the beginning. For example, each program is stored in a “portable physical medium” such as a flexible disk inserted into the computer 1000 or a CD-ROM (Compact Disc Read Only Memory). Alternatively, each program is stored in a “portable physical medium” such as a DVD (Digital Versatile Disc) disk, a magneto-optical disk, or an IC card. Then, the computer 1000 may acquire and execute each program from these portable physical media. Each program may be stored in another computer or server device connected to the computer 1000 via a public line, the Internet, a LAN, a WAN (Wide Area Network), or the like. Then, the computer 1000 may acquire and execute each program from these.

DESCRIPTION OF SYMBOLS 1 Incident management system 10 Server 110 Communication part 120 Storage part 121 Customer storage part 122 Log storage part 123 Incident storage part 130 Control part 131 Log reception part 132 Display data transmission part 133 File specification part 134 Instruction transmission part 135 Deletion part 20,30 , 40 Client 210 Communication unit 220 Storage unit 221 File storage unit 222 Log storage unit 230 Control unit 231 Download unit 232 Monitoring unit 233 Log transmission unit 234 End notification transmission unit 235 Display request transmission unit 236 Confirmation notification transmission unit 237 Deletion unit 240 Display Part 250 input / output part 50 network

Claims (7)

A receiving unit that receives information on the file downloaded by the client, the operation on the client for the file, and the status of the incident that triggered the download of the file, from the client;
A storage unit that stores the information of the file received by the reception unit, the operation, and the status of the incident in association with each other;
With reference to the storage unit, a display data transmission unit that transmits data to be displayed on a predetermined client in association with information on the file, an operation, and an incident status, to the predetermined client;
Incident management system with The receiving unit receives information on a file downloaded by the client, whether or not there is a delete operation on the client for the file, and whether or not the processing of the incident that triggered the download of the file has ended. ,
The storage unit stores the information of the file received by the receiving unit, the presence / absence of the deletion operation, and whether or not the processing of the incident is completed in association with each other,
The display data transmission unit displays data for recognizing and displaying on the predetermined client the presence / absence of the deletion operation and whether or not the processing of the incident is completed in association with the information of the file. The incident management system according to claim 1, wherein the incident management system is transmitted to the client. Among the information on the file stored in the storage unit at a predetermined timing, the specifying unit for specifying the information on the file stored in association with the information indicating that the deletion operation is not performed and the incident processing is completed,
A transmitting unit that transmits information of the file specified by the specifying unit to the predetermined client;
The incident management system according to claim 2, further comprising: Among the information on the file stored in the storage unit at a predetermined timing, the specifying unit for specifying the information on the file stored in association with the information indicating that the deletion operation is not performed and the incident processing is completed,
An instruction to delete the information of the file from the client that has downloaded the information of the file specified by the specifying unit;
The incident management system according to claim 2, further comprising:   5. The information processing apparatus according to claim 1, wherein the reception unit receives information about operations on the client for movement, copying, overwriting movement, and overwriting copying for the file from the client. 6. Incident management system. A receiving step of receiving information from the client about the information of the file downloaded by the client, the operation on the client with respect to the file, and the status of the incident that triggered the download of the file;
A storage step of associating and storing the information on the file received in the reception step, the operation, and the status of the incident in the storage unit,
A display data transmission step of referring to the storage unit and transmitting data to be displayed on the predetermined client in association with the information on the file, the operation, and the status of the incident, to the predetermined client;
An incident management method characterized by causing a computer to execute each process including: A reception procedure for receiving information on the file downloaded by the client, the operation on the client for the file, and the status of the incident that triggered the download of the file from the client;
A storage procedure for storing the information of the file received in the reception procedure, the operation, and the status of the incident in the storage unit in association with each other,
A display data transmission procedure for referring to the storage unit and transmitting data to be displayed on the predetermined client in association with the information on the file, the operation, and the status of the incident, to the predetermined client;
An incident management program for causing a computer to execute each process including:

Images