Program and information processing device

Abstract

To provide a program and an information processing device that make management of RPA more efficient than when no information on correction to the RPA is shared among persons in charge.SOLUTION: A program causes a computer to implement a function of extracting other RPA associated with correction from a database when an indication of correction to the RPA is detected, and a function of notifying related parties of the extracted other RPA of detection of the indication. The computer extracts, of a plurality of RPAs registered in the database, the RPA subjected to correction and RPA whose configuration information is similar as other RPA.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present invention relates to a program and an information processing device. [Background technology]

[0002] Currently, systems are being put into practical use that execute pre-registered tasks in place of humans in the business workflows carried out in offices. This system is called RPA (Robotic Process Automation). RPA executes pre-registered tasks by running multiple systems and applications. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2019-159556 Summary of the Invention [Problem to be solved by the invention]

[0004] In standalone RPA systems that are not centrally managed, the on-site personnel in charge of management develop and modify them individually. Also, because there is no mechanism for notifying the execution of modifications that may affect the RPA they are responsible for managing, the content of modifications may differ even if the purpose of the modifications is the same.

[0005] The present invention aims to make RPA management more efficient than when information on modifications to RPA is not shared among personnel in charge. [Means for solving the problem]

[0006] The invention described in claim 1 is a program for enabling a computer to realize the functions of, when an instruction to modify an RPA is detected, extracting other RPAs related to the modification from a database, and notifying related destinations of the extracted other RPA of the detection of the instruction; the computer is a program that manages the history of notifications to the related destinations and the history of responses in the other RPAs, and, when it detects one of the other RPAs for which no response has been recorded even after a predetermined time has passed since the notification, notifies the person in charge of the modification of information identifying the other RPA. The invention described in claim 2 is a program for enabling a computer to realize the functions of, when an instruction to modify an RPA is detected, extracting other RPAs related to the modification from a database, and notifying the related destinations of the extracted other RPAs of the detection of the instruction, wherein the computer notifies the person in charge of the other RPAs of the content of the modification and suspends execution of the modification corresponding to the detected instruction until consent is obtained from the person in charge of the other RPAs. Claim 3 The invention described in is an information processing device that has a processor, and when an instruction to modify an RPA is detected, the processor extracts other RPAs related to the modification from a database, notifies related parties of the extracted other RPA of the detection of the instruction, manages a history of notifications to the related parties and a history of responses in the other RPA, and when the processor detects another RPA for which no response has been recorded even after a predetermined time has passed since the notification, notifies the person in charge who instructed the modification of information identifying the other RPA. Claim 4 The invention described in is an information processing device having a processor, and when an instruction to modify an RPA is detected, the processor extracts other RPAs related to the modification from a database, notifies the related destination of the extracted other RPA of the detection of the instruction, notifies the person in charge of the other RPA of the content of the modification, and stops execution of the modification corresponding to the detected instruction until consent is obtained from the person in charge of the other RPA. 。 [Effects of the Invention]

[0007] According to the invention described in claim 1, it is possible to grasp unmanaged RPA. According to the invention described in claim 2, management can be made more efficient throughout the entire range affected by the correction. Claim 3 According to the described invention, it is possible to identify unmanaged RPA. Claim 4 The described invention allows for efficient management of the entire range affected by the modification. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 2 is a diagram illustrating an example of use of the information processing system used in the first embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of the hardware configuration of an RPA terminal used in the first embodiment. [Figure 3] 1 is a diagram illustrating an example of the data structure of a configuration information DB, where (A) shows a main table and (B) shows a sub-table related to a component. [Figure 4] 10 is a diagram illustrating the influence of a correction on other RPA terminals when a correction is instructed to one of the multiple RPA terminals that make up the information processing system. FIG. [Figure 5] 10 is a flowchart illustrating an example of a processing operation executed by an RPA terminal that has accepted a correction. [Figure 6] 10 is a flowchart illustrating the details of the processing operation executed in step 3. [Figure 7] 10 is a flowchart illustrating another example of the processing operation executed by the RPA terminal that has accepted the correction. [Figure 8] 10 is a flowchart illustrating another example of the processing operation executed by the RPA terminal that has accepted the correction. [Figure 9] FIG. 11 is a diagram illustrating an example of the hardware configuration of an RPA terminal used in the second embodiment. [Figure 10] 10 is a flowchart illustrating an example of a processing operation executed by an RPA terminal that has accepted a correction. [Figure 11] 10 is a flowchart illustrating another example of the processing operation executed by the RPA terminal that has accepted the correction. [Figure 12] FIG. 11 is a diagram illustrating an example of the hardware configuration of an RPA terminal used in the third embodiment. [Figure 13] 10A and 10B are diagrams illustrating an example of data in a modification notification log and a modification log, where (A) shows an example of data in the modification notification log, and (B) shows an example of data in the modification log. [Figure 14] 10 is a flowchart illustrating an example of a processing operation executed by an RPA terminal that has accepted a correction. [Figure 15] FIG. 13 is a diagram illustrating an example of the hardware configuration of an RPA terminal used in the fifth embodiment. [Figure 16] FIG. 10 is a diagram illustrating an example of a data structure of local terminal configuration information. [Figure 17] 10 is a flowchart illustrating an example of a processing operation executed by an RPA terminal that has accepted a correction. [Figure 18] 10 is a flowchart illustrating another example of the processing operation executed by the RPA terminal that has accepted the correction. [Figure 19] 10 is a flowchart illustrating an example of a processing operation executed by an RPA terminal that has accepted a correction. [Figure 20] FIG. 13 is a diagram illustrating an example of the hardware configuration of an RPA terminal used in the fifth embodiment. [Figure 21] 10 is a flowchart illustrating an example of a processing operation executed by an RPA terminal that has accepted a correction. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. <First Embodiment> <Overall system configuration> FIG. 1 is a diagram illustrating an example of use of an information processing system 1 used in the first embodiment. The information processing system 1 shown in FIG. 1 is made up of a plurality of information devices connected to networks 10 and 10A.

[0010] In the case of Figure 1, examples of information devices are an image forming device 20, a business server 30A and a cloud server 30B that store documents handled by the image forming device 20 and the staff terminal 50 and perform OCR (Optical Character Recognition) processing, etc., an RPA terminal 40 that executes RPA defined by processing routines corresponding to standardized tasks, etc., and the staff terminal 50 operated by a staff member who performs work using RPA. The image forming apparatus 20 in this embodiment has multiple functions such as a copier, printer, image scanner, facsimile, etc. For this reason, it is also called a "multifunction device."

[0011] 1, a LAN (Local Area Network) is assumed as the network 10. The LAN may be wired or wireless. The network 10A is assumed to be the Internet or a cloud network. Note that a part of the networks 10 and 10A may be a mobile communication system such as 4G or 5G, or may be Bluetooth (registered trademark).

[0012] In FIG. 1, the image forming apparatus 20 is an office product, but may be a small product for use in a small office. Furthermore, there are no restrictions on the location where the image forming apparatus 20 is installed. As long as predetermined conditions are met, the image forming apparatus 20 may be installed in a convenience store or the like. In other words, the image forming apparatus 20 may be a so-called kiosk terminal.

[0013] The business server 30A and the cloud server 30B perform, for example, storing business documents, OCR processing of image data uploaded from the image forming device 20, registering text data extracted from the image data after OCR processing in a database, calculating registered numerical values, sending emails, and other functions. These processes may be executed according to instructions from a person in charge or instructions from the RPA terminal 40.

[0014] In this embodiment, documents are assumed to be forms such as application forms, invoices, delivery notes, and slips. The entry fields of the form may be filled in by hand or by printing. In the case of a handwritten form, the handwritten characters are entered within a frame that has been printed in advance. The document is not limited to accounting or financial documents such as forms, but may also be personnel data or data related to employee benefits.

[0015] The document may also be a fax, an email, a document created with document creation software, a document created with spreadsheet software, a document created with presentation software, a still image including a photograph, or a moving image. Furthermore, the business server 30A and the cloud server 30B may have a database that stores various types of information related to the business. For example, text data extracted from an image after OCR processing is registered in the database.

[0016] The illustrated documents are merely examples, and it is not necessary for all of them to be handled by the business server 30A and the cloud server 30B. Furthermore, the business server 30A and the cloud server 30B may handle additional data. The image may be an image captured by the image forming device 20, or an image captured by a camera provided on a smartphone or tablet.

[0017] The RPA terminal 40 is a terminal that executes RPA in cooperation with the business server 30A and the cloud server 30B. There are multiple RPA terminals 40 shown in Fig. 1, and each RPA terminal 40 is denoted as "40-1," "40-2," ... "40-N." The RPA terminal 40 is a so-called computer, and is assumed to be, for example, a server, a desktop computer, or a notebook computer.

[0018] The RPA terminal 40 performs work on behalf of the user through the execution of a program (hereinafter referred to as an "execution routine"). For example, the RPA terminal 40 can sort documents, extract specific information, and register it in a table. For example, the RPA terminal 40 can also configure the staff terminal 50, install application programs, search websites and collect information, update websites, print using the image forming device 20, analyze, process, distribute data, and more.

[0019] When a plurality of RPA terminals 40 are used, each RPA terminal 40 may execute the same execution routine, or each RPA terminal 40 may execute a different execution routine. Furthermore, one RPA terminal 40 may execute one execution routine, or may execute multiple execution routines. The execution routine is also called a program, a scenario, a script, a macro, or the like.

[0020] The components that make up an execution routine are also called subroutines, commands, parameters, resources, or APIs (Application Programming Interfaces) depending on their granularity. Parameters include global variables and local variables. Note that multiple RPAs may work together to function as a single RPA. In that sense, an RPA is also an example of a component. The RPA terminal 40 in this embodiment is an example of an information processing device.

[0021] The person in charge terminal 50 is a computer operated by a person who performs work using the information processing system 1 or a person who manages the system. The person in charge terminal 50 is, for example, a desktop computer or a notebook computer. However, this does not exclude the use of a smartphone or tablet computer as the person in charge terminal 50. The person in charge terminal 50 may also be a wearable computer. There are multiple operator terminals 50 shown in FIG. 1, and each operator terminal 50 is denoted as "50-1", "50-2",... "50-M".

[0022] <Configuration of RPA Terminal> FIG. 2 is a diagram for explaining an example of the hardware configuration of the RPA terminal 40 used in Embodiment 1. The RPA terminal 40 shown in FIG. 2 has a data processing unit 400, a hard disk drive (i.e., "HDD") 410, and a communication module 420. Here, for the communication module 420, a device compliant with the protocol used for communication with the networks 10 and 10A is used.

[0023] The data processing unit 400 has a processor 401, a ROM (= Read Only Memory) 402, and a RAM (= Random Access Memory) 403. Both the ROM 402 and the RAM 403 are semiconductor memories. The ROM 402 stores a BIOS (= Basic Input Output System) and the like. The RAM 403 is used as the main memory device for program execution. For example, DRAM (= Dynamic RAM) is used for the RAM 403.

[0024] The processor 401 is composed of, for example, a CPU (= Central Processing Unit). The processor 401 realizes various functions through program execution. As an example of functions, the processor 401 shown in FIG. 2 is represented by an RPA execution unit 401A, a modification reception unit 401B, a modification execution unit 401C, a related RPA extraction unit 401D, and a modification notification unit 401E.

[0025] The RPA execution unit 401A is a functional unit realized by the execution of an execution routine 411. The modification reception unit 401B, the modification execution unit 401C, the related RPA extraction unit 401D, and the modification notification unit 401E are functional units realized by the execution of a modification sharing program 412.

[0026] The modification receiving unit 401B is a functional unit that receives modifications to the execution routine 411 by a person in charge, etc. The modification receiving unit 401B not only receives an execution routine that reflects the modification content (hereinafter referred to as a "new file"), but also receives instructions to modify the current execution routine (hereinafter referred to as an "old file").

[0027] The modification execution unit 401C is a functional unit that puts the execution routine 411 into an executable state by replacing the execution routine 411 from an old file with a new file or by overwriting and saving it. The related RPA extraction unit 401D is a functional unit that extracts RPAs related to the modification from the configuration information database (hereinafter referred to as the “configuration information DB”) 413.

[0028] The correction notification unit 401E is a functional unit that notifies other RPA terminals 40 that execute the extracted RPA or related personnel of the occurrence of related corrections. The modification notification unit 401E in this embodiment notifies only the occurrence of a related modification, but does not notify the content of the modification. However, the content of the modification may also be notified. The notification of the occurrence of a modification may include, for example, the name of the RPA to be modified or an identifier used to identify the RPA.

[0029] The hard disk drive 410 is an auxiliary storage device that uses a magnetic disk as a recording medium. In this embodiment, the hard disk drive 410 is used as the auxiliary storage device, but a non-volatile rewritable semiconductor memory may also be used. An operating system and application programs are installed on the hard disk drive 410 .

[0030] In the case of FIG. 2, an execution routine 411 and a modified shared program 412 are stored as examples of application programs. In addition, the hard disk drive 410 stores a configuration information DB 413 that aggregates the configuration information of all the RPA terminals 40 that make up the information processing system 1. The configuration information DB 413 is shared among all the RPA terminals 40 connected to the networks 10 and 10A.

[0031] When the configuration information is modified, the RPA terminal 40 (see FIG. 1) on which the modification occurred notifies the modified configuration information to all other RPA terminals 40. The other RPA terminals 40 that receive the notification update the configuration information in the configuration information DB 413 stored in the hard disk drive 410 to maintain the latest information. However, an RPA terminal 40 that has modified its configuration information may broadcast the updated configuration information DB 413 to other RPA terminals 40, thereby maintaining the sharing of the latest information.

[0032] 3 is a diagram illustrating an example of the data structure of the configuration information DB 413. (A) shows a main table, and (B) shows a sub-table related to the components. The main table shown in FIG. 3(A) is composed of "RPA name," "ID," "version" information, "linked RPA" information, "component," "notification destination," "related documents," and "related terminals."

[0033] "RPA name" is the name given to the RPA. In Figure 3(A), "Address management" and "Direct mail sending" are shown as examples of "RPA names." "ID" is an identifier of the RPA, and in FIG. 3(A) "R001" and "R002" are shown as examples. The "version" information indicates the difference between versions, and is recorded as "1.0", "2.0", "1.1", or "1.2". The version is updated every time a revision is made.

[0034] The "Linked RPA" information is recorded if there is an RPA that is used in the pre-process or post-process of the RPA identified by the "RPA name." Here, the upstream process refers to the relationship that calls the RPA to be modified, and the downstream process refers to the relationship that is called from the RPA to be modified. Note that the relationship between pre-processes and post-processes is not limited to existing relationships, but also applies to newly added RPAs in the system. In other words, the relationship between pre-processes and post-processes here includes the RPA that calls the newly added RPA and the RPA that is called by the newly added RPA.

[0035] The preceding and succeeding processes are not limited to the immediately preceding RPA and the immediately succeeding RPA, but may also include RPAs further upstream or downstream. "Components" are the parts that make up RPA, and include programs, subroutines, commands, parameters, resources, APIs, etc. Each "component" is provided as a visual object, and arranging these in order on the screen generates an execution routine.

[0036] The "Notification Destination" field records the email address of the person in charge of managing the RPA, the system administrator, etc. In Figure 3(A), "Fujitaro@xxx.co.jp" is recorded. "Related documents" include, for example, revision history and reference URLs (Uniform Resource Locators). Note that references are not limited to URLs; they can also be on-premise social networking services (SNS), domain name systems (DNS), customer relationship management (CRM), on-premise data storage, public cloud data storage, etc.

[0037] In "related terminal," information that identifies the RPA terminal 40 on which the corresponding RPA is being executed is recorded. Information that identifies the RPA terminal 40 includes, for example, an administrative name or an address on the network. For example, if the "address management" RPA is executed on RPA terminal 40-1 and RPA terminal 40-2, information that identifies each terminal is recorded.

[0038] The sub-table shown in Fig. 3(B) is linked to the "elementary element" which is an element of the main table. The sub-table shown in Fig. 3(B) is composed of "elementary element name," "ID," "program configuration," "attribute value," and "characteristic information." In the "Component Name" field, for example, the name of the component that constitutes the RPA for "Address Management" is entered. If there are multiple components that constitute the "Address Management" RPA, multiple component names are listed.

[0039] "ID" is the identifier of a component. If an RPA is composed of multiple components, an "ID" is assigned to each component. The "program configuration" includes the parts used to assemble the execution routine, part combination patterns, standard templates, common libraries, program names, and the like. In other words, the "program structure" corresponds to the specific materials of the execution routine. The "program structure" also includes modules that the person in charge has organized into a library for the purpose of reuse. Figure 3(B) shows three examples of "program configuration": "reference to customer company database," "extraction of addresses listed on the website," and "excel registration."

[0040] The "attribute value" is attribute information of the resources inside and outside the RPA that the execution routine accesses, such as the name of the reference destination, the address of the reference destination, login information, access key, etc. The access key is information for authentication. In Figure 3(B), two items are recorded: "Customer company DB address" and "Postal code search URL."

[0041] "Characteristic information" is a description of the characteristics of the target RPA, and is used to determine the RPA's attribute information and similarity. In FIG. 3(B), examples of "characteristic information" include a description, a group of keywords, and a set of attribute name and attribute value (KV). Incidentally, the keyword group includes, for example, name, version, timestamp, creator, and operator. In Figure 3(B), the "characteristic information" includes two items: the description "Search for the company name on the website, extract the address, and list it in Excel," and "Region: Japan."

[0042] <Processing operation 1> 4 is a diagram illustrating the influence of a correction on the other RPA terminals 40 when a correction is instructed to one of the multiple RPA terminals 40 that make up the information processing system 1. In FIG. 4, parts corresponding to those in FIG. 1 are assigned the same reference numerals. In FIG. 4, the RPA terminal 40 and the person in charge terminal 50 are extracted from the information processing system 1 and shown.

[0043] In the case of Fig. 4, the person in charge operates the person in charge terminal 50-1 to instruct the RPA terminal 40-1 to make a correction. The RPA terminal 40-2 shown in Fig. 4 is related to the correction made to the RPA terminal 40-1, but the RPA terminal 40-3 is not related to the correction made to the RPA terminal 40-1. The presence or absence of relevance to the correction is determined using, for example, similarity as an execution routine, presence or absence of linkage as a preceding or succeeding process, and time-series information including a history of versions and copies.

[0044] 5 is a flowchart illustrating an example of the processing operation executed by the RPA terminal 40-1 (see FIG. 4) that has accepted the correction. In FIG. 5, the symbol S is used to mean a step. The following processing is realized through execution of the modified shared program 412 (see FIG. 2) by the processor 401 (see FIG. 2).

[0045] First, the RPA terminal 40-1 accepts a correction to the RPA (step 1). The RPA terminal 40-1 can be instructed to make corrections by individually instructing the parts to be corrected and the contents of the corrections, or by uploading the corrected execution routine 411 (see FIG. 2). In this embodiment, the RPA terminal 40-1 executes the received correction (step 2).

[0046] Corrections may be executed immediately, outside of business hours such as at night or on holidays, or received corrections may be stored and executed at a predetermined time such as once a week. In any case, in this embodiment, all received corrections are executed. Next, the RPA terminal 40-1 determines whether there is another RPA related to the modification that the terminal has received (step 3). This determination is performed by the related RPA extraction unit 401D (see FIG. 2). In the example of FIG. 4, the RPA terminal 40-2 is extracted as another RPA having a relationship.

[0047] FIG. 6 is a flowchart illustrating the details of the processing operations executed in step 3. First, the RPA terminal 40-1 extracts the details of the revision (step 31). The details of the revision are obtained, for example, from a comparison between the new file and the old file or from a revision history page. Next, the RPA terminal 40-1 uses the configuration information DB 413 (see FIG. 2) to determine whether the RPA to be modified is also being executed by other RPA terminals 40 (step 32).

[0048] For example, the RPA terminal 40-1 refers to the "RPA name" column and the "associated terminal" column of the configuration information DB 413 and determines whether there are any other RPA terminals 40 that have registered RPAs with the same name as the RPA to be modified. If a positive result is obtained in step 32, the RPA terminal 40-1 proceeds to step 4. On the other hand, if a negative result is obtained in step 32, the RPA terminal 40-1 uses the configuration information DB 413 to determine whether there are other RPAs with which it has a chronological relationship (step 33). The chronological relationship may include, for example, different versions and a replication history. The replication history records information about the RPA that served as the replication source and the RPA that served as the replication destination.

[0049] If a positive result is obtained in step 33, the RPA terminal 40-1 proceeds to step 4. If a negative result is obtained in step 33 as well, the RPA terminal 40-1 uses the configuration information DB 413 to determine whether or not a cooperating RPA is registered (step 34). Cooperative relationships include relationships between pre-processes and post-processes. If a positive result is obtained in step 34, the RPA terminal 40-1 proceeds to step 4.

[0050] If a negative result is obtained in step 34 as well, the RPA terminal 40-1 uses the configuration information DB 413 to search for other RPAs that have the same or similar parts as the corrected parts (step 35). Similarity is determined by, for example, the similarity of the "RPA name," the similarity of the description recorded in the "feature information," the keyword group, and the words included in the KV. For example, if a URL is modified, the RPA with the URL before the modification is determined to be "similar."

[0051] Furthermore, when the components that make up an RPA are managed using an object-oriented approach, RPAs and components called "instances" are generated using object models or templates called "classes." In the case of object-oriented RPAs, similarity is determined using the degree of agreement with the type and number of classes used to generate the instances.

[0052] If the result of step 35 is "similar," the RPA terminal 40-1 proceeds to step 4. On the other hand, if "no similarity" is obtained in step 35, the RPA terminal 40-1 ends the process. Returning to the explanation of Figure 5.

[0053] If a positive result is obtained in step 3, the RPA terminal 40-1 notifies the person in charge of the other related RPA of the occurrence of a related correction (step 4). In the present embodiment, only the person in charge of the other related RPA is notified of the occurrence of a correction. In other words, they do not need to be notified of the occurrence of an unrelated correction. Therefore, the burden on the person in charge of the other RPA is reduced compared to when the person in charge of the other RPA is notified of the occurrence of all corrections, regardless of whether they are related or not.

[0054] In this embodiment, the notification to the person in charge uses the information recorded in the "notification destination" field in the configuration information DB 413. In this embodiment, the name of the related RPA and information about other RPA terminals 40 in which the related RPA is registered are also notified. If a negative result is obtained in step 3, the RPA terminal 40-1 ends the process. In the case of Fig. 5, the determination in step 3 is made after execution of step 2, but it may also be executed on the condition that a correction to the RPA is accepted in step 1. As mentioned above, the execution of the correction in step 2 is not necessarily executed simultaneously with the acceptance of the correction.

[0055] However, if the time for waiting for the correction is long, and if the configuration information DB 413 is corrected after the execution of the determination, there is a possibility that the notification in step 4 will be missed or will be incorrect. Therefore, if the judgment in step 3 is performed while waiting for corrections to be made on the own terminal and other related RPA personnel are notified, the judgment in step 3 and the notification in step 4 may be performed again after the corrections are made on the own terminal.

[0056] In this embodiment, the application of the RPA correction to the other RPA terminals 40 is decided by the person in charge who receives the notification. The notification in Step 4 makes it possible for other personnel who manage the RPA under the same name as the modified RPA to be made aware of the need for modification. As a result, each person in charge can simultaneously consider the need for modification and the content of the modification. By having multiple personnel share information and simultaneously consider the content of the modification, the efficiency of RPA maintenance and development is improved.

[0057] Furthermore, it is possible to apply the content of corrections that have already been made to the RPA that one is responsible for, reducing the duplication of effort, such as multiple people individually reviewing the content of corrections. In particular, it reduces the possibility of differences in content between corrections made for the same purpose. Furthermore, in this embodiment, it is possible to provide an opportunity for RPA personnel who may be affected by the content of the correction, such as the process preceding or following the correction, to consider the impact of the correction executed in another execution routine. In other words, it is possible to consider the content of the correction before side effects appear as events.

[0058] For example, if the names or values used to exchange data with the modified RPA change, it will be possible to make the user aware that the RPA they are responsible for needs to be modified from the perspective of consistency. For example, local business needs may necessitate modifications to the RPA handled by on-site personnel.

[0059] If the content of this modification is information used when linking with other RPAs, unless the modification is also made to the RPAs in the preceding and succeeding processes that use the modified names and values, the RPA execution will stop midway. However, in the case of this embodiment, even the person in charge of the RPA in the preceding or succeeding process is notified of the occurrence of a correction that may be related to other RPAs.

[0060] This makes it possible to make other RPA personnel aware of the need for corrections at the same time as other RPA corrections are being made. As a result, it becomes possible to prevent situations in which RPA operation stops midway. Furthermore, even when a failure occurs, it becomes easier to find the part that needs to be corrected.

[0061] <Processing operation 2> 7 is a flowchart illustrating another example of the processing operation executed by the RPA terminal 40-1 (see FIG. 4) that has accepted the correction. In FIG. 7, parts corresponding to those in FIG. 5 are assigned the same reference numerals. The processing operation shown in FIG. 7 differs from the processing operation shown in FIG. 5 in that a determination process is added after execution of step 2.

[0062] In the case of FIG. 7, after executing step 2, the RPA terminal 40-1 determines whether the instruction satisfies a predetermined condition (step 101). For example, the predetermined condition may be that the time elapsed since the start of operation is within a predetermined period. The predetermined period may be, for example, 14 days or 30 days. Immediately after the start of operation, there is a lot of reworking, and the corrected content may not necessarily be correct. Also, there are cases where other RPA personnel do not want frequent notifications. However, as explained in FIG. 5, all corrections may be subject to notification.

[0063] If the affirmative result is obtained in step 101, that is, if the predetermined condition is met, the RPA terminal 40-1 does not need to notify of the correction, and therefore ends the process. On the other hand, if a negative result is obtained in step 101, the RPA terminal 40-1 proceeds to step 3 and determines whether there is another RPA related to the modification accepted by the terminal itself. The following processing operations are the same as those in FIG. 5, and therefore description thereof will be omitted.

[0064] <Processing operation 3> 8 is a flowchart illustrating another example of the processing operation executed by the RPA terminal 40-1 (see FIG. 4) that has accepted the correction. In FIG. 8, parts corresponding to those in FIG. 5 are assigned the same reference numerals. The processing operation shown in FIG. 8 differs from the processing operation 1 (see FIG. 5) described above in that the operation performed when a positive result is obtained in step 3.

[0065] In the case of FIG. 8, if a positive result is obtained in step 3, the RPA terminal 40-1 notifies the person in charge who instructed the correction accepted in step 1 of information about other related RPAs (step 111). Information about other RPAs includes, for example, the number of other RPAs, the names of other RPAs, the people in charge of other RPAs, and the characteristics of other RPAs. This notification enables the person in charge of issuing the correction to determine the need for standardization or integration of similar RPAs. In addition, when it comes to correcting other related RPAs, the person in charge who receives the notification may make the corrections themselves, or the corrections may be carried out through the person in charge of the other RPAs.

[0066] <Embodiment 2> <Overall Configuration of the System> Embodiment 2 also uses the same information processing system 1 (see FIG. 1) as in Embodiment 1. In the case of this embodiment, functions are added to the RPA terminal 40.

[0067] <Configuration of the RPA Terminal> FIG. 9 is a diagram for explaining an example of the hardware configuration of the RPA terminal 40 used in Embodiment 2. In FIG. 9, reference numerals corresponding to the corresponding parts in FIG. 2 are shown. In the case of the RPA terminal 40 shown in FIG. 9, the hard disk drive 410 stores an execution routine 411, a correction sharing program 412A, and configuration information DB 413.

[0068] In addition, a correction response unit 401F is added to the functions realized by the execution of the correction sharing program 412A by the processor 401. Other configurations are the same as in Embodiment 1. The correction response unit 401F added in this embodiment provides a function of transmitting the content of the response to another RPA terminal 40 that is the notification source when receiving a correction notification from another RPA terminal 40.

[0069] <Processing Operation 1> FIG. 10 is a flowchart for explaining an example of the processing operation executed by the RPA terminal 40-1 (see FIG. 4) that has received a correction. In FIG. 10, reference numerals corresponding to the corresponding parts in FIG. 5 are shown. Also in the case of FIG. 10, the RPA terminal 40-1 receives a correction to the RPA (step 1).

[0070] Next, the RPA terminal 40-1 executes step 3. That is, before executing the received correction, the RPA terminal 40-1 determines whether there is another RPA related to the correction received by its own terminal. If a negative result is obtained in this determination, the RPA terminal 40-1 executes the received correction (step 2).

[0071] If a positive result is obtained in step 3, the RPA terminal 40-1 executes step 4. That is, the RPA terminal 40-1 notifies other related RPA personnel of the occurrence of related corrections. Thereafter, the RPA terminal 40-1 that has accepted the correction determines whether or not it has received agreement from the person in charge of the other RPA to whom the notification was sent (step 121). If a positive result is obtained in step 121, the RPA terminal 40-1 executes the accepted correction (step 2). On the other hand, if a negative result is obtained in step 121, the RPA terminal 40-1 ends the process without executing the accepted correction.

[0072] That is, in the case of this embodiment, even the RPA terminal 40-1 that has accepted the corrections does not necessarily execute all the corrections. Corrections are made when there are no other related RPAs or when consent is obtained from the person in charge of the other related RPAs. If consent is not obtained from other relevant RPA personnel, the accepted corrections will not be implemented.

[0073] In this embodiment, corrections are made subject to the consent of other personnel, making it possible to prevent the correction of erroneous content or content that requires consistency, etc. In addition, by having multiple people review the changes before they are made, it becomes possible to make changes and develop products that are more versatile and comprehensive.

[0074] <Processing operation 2> 11 is a flowchart illustrating another example of the processing operation executed by the RPA terminal 40-1 (see FIG. 4) that has accepted the correction. In FIG. 11, parts corresponding to those in FIG. 10 are assigned the same reference numerals. In the case of FIG. 11, the RPA terminal 40-1 also accepts a correction of the RPA (step 1).

[0075] Next, the RPA terminal 40-1 determines whether there is any other RPA related to the modification received by its own terminal (step 3). If a negative result is obtained in step 3, the RPA terminal 40-1 executes the received modification (step 2). This is because there is no need to consider the impact on other RPAs. On the other hand, if an affirmative result is obtained in step 3, the RPA terminal 40-1 notifies the person in charge who instructed the modification received in step 1 of the information regarding the related other RPAs (step 131).

[0076] The content of this step 131 is the same as step 111 in Embodiment 1 (see FIG. 8). In the case of this embodiment, before the instructed modification is executed, the information regarding the related other RPAs is notified. That is, an opportunity is given to determine whether to execute the modification even after grasping the impact of the modification instructed by oneself. After that, the RPA terminal 40-1 determines whether it has received the final instruction to execute (step 132).

[0077] If an affirmative result is obtained in step 132, the RPA terminal 40-1 executes the received modification (step 2). If a negative result is obtained in step 132, the RPA terminal 40-1 ends the process without executing the received modification. In the case of processing operation 2, an opportunity is given to the person in charge who instructed the modification to review whether to execute the instructed modification. This is the difference from processing operation 1 (see FIG. 10). In the case of this processing operation, an opportunity is ensured to reconsider the execution of the modification before a modification with a large impact is executed.

[0078] <Embodiment 3> <Overall Configuration of the System> Embodiment 3 also uses the same information processing system 1 (see FIG. 1) as in Embodiment 1. In the case of this embodiment, functions are added to the RPA terminal 40.

[0079] <Configuration of the RPA Terminal> Fig. 12 is a diagram illustrating an example of the hardware configuration of the RPA terminal 40 used in the third embodiment. In Fig. 12, parts corresponding to those in Fig. 2 are assigned the same reference numerals. In the case of the RPA terminal 40 shown in FIG. 12, the hard disk drive 410 stores an execution routine 411, a modified shared program 412B, a configuration information DB 413, a modification notification log 414, and a modification log 415. Furthermore, a notification management unit 401G is added to the functions realized by execution of the modified shared program 412B by the processor 401. The other configurations are the same as those in the first embodiment.

[0080] The modification notification log 414 is data that records the history of modification notifications made by the modification notification unit 401E. The modification log 415 is data that records the details of modifications that have been made. The notification management unit 401G realizes a function to manage the status of responses to corrections by personnel in charge of other RPAs who are the recipients of the correction notification. If the "response history" is blank even after a predetermined time has elapsed since the "notification time," the notification management unit 401G considers the other RPAs who are the recipients of the notification to be rogue robots and outputs an alarm. The alarm is output to, for example, the system administrator. The "predetermined time" is an example of a predetermined period. Note that the predetermined period is an example of a predetermined condition.

[0081] Furthermore, the notification management unit 401G realizes a function of notifying the person in charge of another RPA that will start operating after the notification of the modification and that has been found to be related to the modification, of the existence of a related modification. In other words, when a new RPA is registered in the configuration information DB 413 (see FIG. 2) or when a change occurs in the record of an existing RPA, the notification management unit 401G determines the relationship with the modification log 415, and if the relationship is found, outputs a notification requesting confirmation of the related modification.

[0082] 13A and 13B are diagrams showing examples of data in the modification notification log 414 and the modification log 415. (A) shows an example of data in the modification notification log 414, and (B) shows an example of data in the modification log 415. The correction notification log 414 shown in FIG. 13 is made up of "notification ID," "notification time," "correction location," "content," and "handling history." The "notification ID" is an identifier for distinguishing notifications, and in Figure 13(A) it is shown as "10001" as an example. If there are multiple notification recipients for one revision, a notification ID is issued for each notification to each notification recipient.

[0083] "Notification time" is information indicating the time of notification to other RPA personnel, and is recorded for each notification ID. "Correction part" is information indicating the part to be corrected. "Content" is information indicating the content of the correction. "Response history" records whether other RPAs have been corrected after notification. The response of other RPAs can be confirmed by updating the configuration information DB 413. If no corrections are confirmed, the field remains blank.

[0084] The revision log 415 shown in FIG. 13 is made up of "revision ID," "revision time," "revision location," and "content." The "revision ID" is an identifier for distinguishing revisions, and in FIG. 13(B) "50001" is shown as an example. "Modification time" is information indicating the time when the modification was performed, and is recorded for each modification ID. "Correction part" is information indicating the part to be corrected. "Content" is information indicating the content of the correction.

[0085] <Processing operation> FIG. 14 is a flowchart illustrating an example of the processing operation executed by the RPA terminal 40-1 (see FIG. 4) that has accepted the correction. The following processing is realized through execution of the modified shared program 412B (see FIG. 12) by the processor 401 (see FIG. 2). First, the RPA terminal 40-1 refers to the correction notification log 414 and determines whether a predetermined time has elapsed since the correction notification (step 141).

[0086] While a negative result is obtained in step 141, the RPA terminal 40-1 repeats the determination in step 141. Note that the determination in step 141 is made for each notification stored in the correction notification log 414. If an affirmative result is obtained in step 141, the RPA terminal 40-1 determines whether there is a history of correspondence with other RPAs (step 142). Here, having a history of correspondence means, for example, the case of executing the same correction.

[0087] If an affirmative result is obtained in step 142, the RPA terminal 40-1 determines that the other RPA that is the target of the determination is not a rogue robot and ends the process. On the other hand, if a negative result is obtained in step 142, the RPA terminal 40-1 notifies the person in charge of the information of the unhandled RPA (step 143). The information of the unhandled RPA includes, for example, the RPA name and the information of the person in charge. This notification gives an opportunity to sort out rogue robots.

[0088] <Embodiment 4> In this embodiment, the configuration information DB 413 (see FIG. 2) that aggregates the configuration information of all the RPA terminals 40 connected to the networks 10 and 10A is not used. <Overall Configuration of the System> Embodiment 4 also uses the same information processing system 1 (see FIG. 1) as in Embodiment 1. In the case of this embodiment, the RPA terminal 40 that has received a correction is provided with a function of broadcasting the received correction to all other RPA terminals on the same network.

[0089] <Configuration of RPA Terminal> FIG. 15 is a diagram for explaining an example of the hardware configuration of the RPA terminal 40 used in Embodiment 5. In FIG. 15, the corresponding parts to those in FIG. 2 are denoted by the same reference numerals. In the case of the RPA terminal 40 shown in FIG. 15, the hard disk drive 410 stores an execution routine 411, a correction sharing program 412C, and self-terminal configuration information 416. Furthermore, as functions realized by the processor 401 executing the modified shared program 412C, a modified broadcast unit 401H and a relatedness determination unit 401J are added, and the related RPA extraction unit 401D (see FIG. 2) is deleted.

[0090] In this embodiment, the own terminal configuration information 416 is used. The own terminal configuration information 416 is composed only of configuration information of the RPA operating on the own terminal. In other words, the own terminal configuration information 416 does not include configuration information of the RPA operating on other RPA terminals 40. In this embodiment, the relevance to the modification is determined by the other RPA terminals 40 that receive the broadcast of the content of the modification.

[0091] Fig. 16 is a diagram illustrating an example of the data structure of the local terminal configuration information 416. In Fig. 16, parts corresponding to those in Fig. 3 are assigned the same reference numerals. The data shown in FIG. 16 is composed of "RPA name," "ID," "program configuration," "attribute value," and "characteristic information." "RPA name" is a name given to an RPA. In Fig. 16, "Address Management" is shown as an example of the "RPA name." "ID" is the identifier of the RPA, and in FIG. 16, "R001" is shown as an example.

[0092] The "program configuration" includes the parts used to assemble the execution routine, part combination patterns, standard templates, common libraries, program names, and the like. The "attribute value" is attribute information of the resources inside and outside the RPA that are accessed by the execution routine, such as the name of the reference destination, the address of the reference destination, login information, and access key. "Characteristic information" is a description of the characteristics of the target RPA, and is used to determine the RPA's attribute information and similarity. These are the same as the items in the configuration information DB 413 (see FIG. 3) shown in Fig. 3. However, as described above, the own terminal configuration information 416 is made up of only the configuration information related to the RPA currently running on each RPA terminal 40.

[0093] Returning to the explanation of FIG. The modification broadcast unit 401H is a functional unit that, when receiving a modification of the RPA operating on its own terminal, broadcasts the content of the modification to other RPA terminals 40 existing on the same network using a broadcast address. In other words, the determination of the relevance is left to the broadcast destination.

[0094] The relevance determination unit 401J is a functional unit that determines the relevance between the content of the correction broadcast from another RPA terminal 40 and the RPA operating on its own terminal. The local terminal configuration information 416 is used to determine the relevance. The relevance determination unit 401J determines the relevance in the same manner as the related RPA extraction unit 401D (see FIG. 2). Specifically, the relevance determination unit 401J determines the relevance between the notified correction content and the RPA operating on the own terminal by comparing it with the information recorded in the own terminal configuration information 416.

[0095] The relevance determination unit 401J used in this embodiment includes a function of notifying the person in charge of the corresponding RPA when it recognizes the relevance with its own terminal. That is, in this embodiment as well, modifications made by the person in charge of another RPA will not be applied without confirmation from the person in charge. However, if the notification comes from a person in charge of managing the maintenance of all RPAs on the system, such as a system administrator, the content of the received modifications may be applied to the RPA of the own terminal.

[0096] <Processing operation> <Broadcast side processing operation 1> 17 is a flowchart illustrating an example of processing operations executed by the RPA terminal 40-1 (see FIG. 4) that has accepted the correction. The following processing is realized through execution of the correction sharing program 412C (see FIG. 15) by the processor 401 (see FIG. 2). First, the RPA terminal 40-1 accepts an RPA modification (step 151). The modification instruction to the RPA terminal 40-1 can be given by individually specifying the location to be modified and the content of the modification, or by uploading the modified execution routine 411 (see FIG. 15).

[0097] Next, the RPA terminal 40-1 executes the received corrections (step 152). In the present embodiment, corrections may be executed immediately, outside of business hours such as at night or on holidays, or the received corrections may be stored and executed at a predetermined time such as once a week. In any case, in the present embodiment, all received corrections are executed. Thereafter, the RPA terminal 40-1 broadcasts the content of the correction (step 153). As described above, the broadcast is sent to all RPA terminals 40 in the system except for the RPA terminal itself. This completes the processing operation of the RPA terminal 40 that has accepted the correction.

[0098] <Broadcast side processing operation 2> Fig. 18 is a flowchart illustrating another example of the processing operation executed by the RPA terminal 40-1 (see Fig. 4) that has accepted the correction. In Fig. 18, parts corresponding to those in Fig. 17 are assigned the same reference numerals. The processing operation shown in FIG. 18 differs from the processing operation shown in FIG. 17 in that a determination process is added after execution of step 151.

[0099] In the case of FIG. 18, after executing step 151, processor 401 determines whether the instruction satisfies a predetermined condition (step 161). The predetermined condition may be, for example, that the time elapsed since the start of operation is within a predetermined period. The predetermined period may be, for example, 14 days or 30 days. Immediately after the start of operation, there is a lot of reworking, and the corrected content may not necessarily be correct. Also, there are cases where other RPA personnel do not want frequent notifications.

[0100] If the result of step 161 is affirmative, that is, if the predetermined condition is met, the processor 401 ends the process without broadcasting the content of the modification. On the other hand, if a negative result is obtained in step 161, processor 401 proceeds to step 152 and executes the accepted modification (step 152). Thereafter, the RPA terminal 40-1 broadcasts the content of the correction (step 153). This completes the processing operation of the RPA terminal 40-1 that has accepted the correction.

[0101] <Processing behavior on the side receiving the broadcast> 19 is a flowchart illustrating an example of processing operations executed by RPA terminals 40-2 and 40-3 (see FIG. 4) that have accepted the correction. The following processing is realized through execution of the correction sharing program 412C (see FIG. 15) by the processor 401 (see FIG. 2). The following description will be given as the operation of RPA terminal 40-2 (see FIG. 4). First, the RPA terminal 40-2 receives the content of the correction from the other RPA terminal 40-1 (see FIG. 4) (step 171). The RPA terminal 40-2 that has received the content of the correction determines whether or not the notified content of the correction is related to the RPA operating on the terminal itself (step 172).

[0102] If an RPA related to the content of the modification is not found, the RPA terminal 40-2 obtains a negative result in step 172 and ends the process. On the other hand, if an RPA related to the content of the correction is found, the RPA terminal 40-2 obtains a positive result in step 172 and notifies the person in charge of the related RPA of the content of the correction (step 173). This notification enables the person in charge of other RPA to become aware of the occurrence of a correction that may be related to the RPA that they are in charge of. In this embodiment, the person in charge who receives the notification takes action such as "agree," "disagree," or "leave it as is" depending on the content of the amendment.

[0103] Subsequently, the RPA terminal 40-2 determines whether it has received consent from the person in charge (step 174). If a negative result is obtained in step 174, the RPA terminal 40-2 ends the process without applying the received modification. On the other hand, if an affirmative result is obtained in step 174, the RPA terminal 40-2 executes the received modification (step 175). By executing this modification, the consistency between the RPA on the RPA terminal 40-1 side and the RPA on the RPA terminal 40-2 side will be maintained.

[0104] Note that the result of the determination in step 174 may be transmitted to the RPA terminal 40-1 that broadcast the modification content. For example, as described in Embodiment 2, this transmission is used to determine whether the processing on the RPA terminal 40-1 can be executed. In the case of this embodiment, the configuration information stored in each RPA terminal 40 is limited to the RPA operating on its own terminal. Therefore, even when determining the relevance to the modifications for other RPAs, the processing load is small.

[0105] <Embodiment 5> In this embodiment, a technique for handling notifications of unaddressed RPAs even after broadcasting and for handling cases where related RPAs are registered after broadcasting will be described.

[0106] <Overall System Configuration> Embodiment 5 also uses the same information processing system 1 (see FIG. 1) as in Embodiment 1. In the case of this embodiment, functions are added to the RPA terminal 40.

[0107] <Configuration of RPA Terminal> FIG. 20 is a diagram for explaining an example of the hardware configuration of the RPA terminal 40 used in Embodiment 5. In FIG. 20, reference numerals corresponding to the corresponding parts of FIGS. 15 and 12 are shown. 20, the hard disk drive 410 stores an execution routine 411, a modified shared program 412D, a modification log 415, its own terminal configuration information 416, and a broadcast log 417. Of these, the broadcast log 417 corresponds to the modification notification log 414 in FIG.

[0108] Furthermore, a modification receiving unit 401B, a modification execution unit 401C, a modification broadcasting unit 401H, a relevance determination unit 401J, and a notification management unit 401K are executed as functions realized by execution of the modification sharing program 412D by the processor 401. In other words, the notification management unit 401K is added to the functions shown in FIG.

[0109] The notification management unit 401K corresponds to the notification management unit 401G (see FIG. 12). However, the notification management unit 401K in this embodiment manages the status of responses to corrections made by other RPA personnel after broadcasting. Furthermore, if the "response history" is blank even after a predetermined time has elapsed since the "notification time," the notification management unit 401K considers other RPAs for which no response has been confirmed to be rogue robots and outputs an alarm. The alarm is output to, for example, a system administrator.

[0110] <Processing operation> FIG. 21 is a flowchart illustrating an example of the processing operation executed by the RPA terminal 40-1 (see FIG. 4) that has accepted the correction. The following processing is realized through execution of the modified shared program 412D (see FIG. 20) by the processor 401 (see FIG. 2). First, the RPA terminal 40-1 refers to the broadcast log 417 and determines whether a predetermined time has elapsed since the correction was broadcast (step 181).

[0111] While a negative result is obtained in step 181, the RPA terminal 40-1 repeats the determination in step 181. Note that the determination in step 181 is made for each broadcast stored in the broadcast log 417. If a positive result is obtained in step 181, the RPA terminal 40-1 determines whether or not there is a corresponding history in another RPA (step 182). Here, "there is a corresponding history" means, for example, that the same correction is executed.

[0112] If a positive result is obtained in step 182, the RPA terminal 40-1 determines that the other RPA being the subject of the determination is not a stray robot, and ends the process. On the other hand, if a negative result is obtained in step 182, the RPA terminal 40-1 notifies the person in charge of information about the unhandled RPA (step 183). The information about the unhandled RPA includes, for example, the RPA name and information about the person in charge. This notification provides an opportunity to organize the stray robots.

[0113] <Other embodiments> (1) Although the embodiments of the present invention have been described above, the technical scope of the present invention is not limited to the scope of the above-described embodiments. It is clear from the claims that various modifications or improvements to the above-described embodiments are also included in the technical scope of the present invention.

[0114] (2) In the above-described embodiment, the RPA terminal 40 that received the correction to the RPA or the RPA terminal 40 that received the broadcast from another RPA terminal 40 autonomously determines the relevance of the content of the received correction, but the user may also indicate the relevance. For example, a dedicated user interface may be prepared. When developing a new RPA, the person in charge may be configured to input expected components as search keys into the dedicated user interface, and the results of searching the configuration information DB 413 (see FIG. 2) may be presented to the person in charge.

[0115] If the number of relevant RPAs can be determined before issuing an instruction to make modifications, it will be possible to use RPAs that are already in operation as a template. Furthermore, when changes are made to an RPA in operation, if another RPA with roughly equivalent processing capabilities is found in advance, the other RPA can be integrated into the RPA in operation, reducing the number of rogue robots in the system, resulting in improved reliability and reduced maintenance costs.

[0116] (3) In the above embodiment, a case has been described in which a function for determining the relevance of the content of a correction is provided in the RPA terminal 40 on which the RPA is executed, but a management server that collectively executes the determination of the relevance may be placed on the network 10 or the network 10A. In this case, the configuration information DB 413 (see FIG. 2) may also be stored in a terminal other than the RPA terminal 40.

[0117] (4) In the above-described first to third embodiments, the RPA terminal 40 that received the correction notifies the person in charge of the other RPA that is recognized as related of the correction, but the correction may also be notified to another RPA terminal 40 that executes the other RPA. In this case, the other RPA terminal 40 that received the correction notification may notify the person in charge of the other RPA that is the target of the notification that a related correction has occurred. Here, the other RPA terminal 40 is an example of a related destination, just like the person in charge of the other related RPA.

[0118] (5) In the above embodiment, the case where the person who first made the correction was notified of the number of related RPAs, etc., was described. However, the number of people in charge of the related RPAs may also be notified, or the number of RPA terminals 40 may also be notified.

[0119] (6) The processor in each of the above-mentioned embodiments refers to a processor in a broad sense, and includes general-purpose processors (e.g., CPUs, etc.) as well as dedicated processors (e.g., GPUs (Graphics Processing Units), ASICs (Application Specific Integrated Circuits), FPGAs (Field Programmable Gate Arrays), programmable logic devices, etc.). Furthermore, the operations of the processor in each of the above-described embodiments may be performed by a single processor alone, or may be performed by multiple processors located in physically separate locations in cooperation with each other. Furthermore, the order of execution of each operation in the processor is not limited to the order described in each of the above-described embodiments, and may be individually modified. [Explanation of symbols]

[0120] 1...information processing system, 10, 10A...network, 20...image forming apparatus, 30A...business server, 30B...cloud server, 40, 40-1, 40-2, 40-3, 40-N...RPA terminal, 50, 50-1, 50-2, 50-M...person in charge terminal, 401A...RPA execution unit, 401B...correction reception unit, 401C...correction execution unit, 401D...related RPA extraction unit, 401E... Modification notification unit 401F...modification response unit, 401G, 401K...notification management unit, 401H...modification broadcast unit, 401J...relevance determination unit, 411...execution routine, 412, 412A, 412B, 412C, 412D...modified shared program, 413...configuration information DB, 414...modification notification log, 415...modification log, 416...local terminal configuration information, 417...broadcast log

Claims

1. On the computer, When an instruction to modify an RPA is detected, a function of extracting other RPAs related to the modification from the database; a function of notifying the detection of the instruction to the related destination of the extracted other RPA; It is a program to achieve The computer Manage a history of notifications to the related parties and a history of responses in the other RPAs; If the other RPA for which no action has been recorded is detected even after a predetermined time has elapsed since the notification, notify the person in charge who instructed the modification of information identifying the other RPA. program.

2. On the computer, When an instruction to modify an RPA is detected, a function of extracting other RPAs related to the modification from the database; a function of notifying the detection of the instruction to the related destination of the extracted other RPA; It is a program to achieve The computer Notify the person in charge of the other RPA of the content of the modification; suspending execution of the modification corresponding to the detected instruction until consent is obtained from the person in charge of the other RPA; program.

3. a processor; The processor: When an instruction to modify the RPA is detected, other RPAs related to the modification are extracted from the database; Notifying the detection of the instruction to the related destination of the extracted other RPA; Manage a history of notifications to the related parties and a history of responses in the other RPAs; If the other RPA for which no action has been recorded is detected even after a predetermined time has elapsed since the notification, notify the person in charge who instructed the modification of information identifying the other RPA. Information processing device.

4. a processor; The processor: When an instruction to modify the RPA is detected, other RPAs related to the modification are extracted from the database; Notifying the detection of the instruction to the related destination of the extracted other RPA; Notify the person in charge of the other RPA of the content of the modification; suspending execution of the modification corresponding to the detected instruction until consent is obtained from the person in charge of the other RPA; Information processing device.

Images