WO2023152797A1

WO2023152797A1 - Verification method, verification program, and information processing device

Info

Publication number: WO2023152797A1
Application number: PCT/JP2022/004893
Authority: WO
Inventors: 洋介中村; 孝一矢崎; 大山本
Original assignee: 富士通株式会社
Priority date: 2022-02-08
Filing date: 2022-02-08
Publication date: 2023-08-17

Abstract

The present invention makes it possible to verify the reliability of a document.　When a processing unit (12) detects the registration of a document to which an electronic signature corresponding to a user belonging to a first organization (50) is attached and an electronic signature corresponding to a user belonging to a second organization (60) is not attached, the processing unit (12) transmits a notification pertaining to the document to a registered user belonging to the second organization (60). The processing unit (12), in accordance with the notification, receives a list (30) including a user in charge who belongs to the second organization (60) and stores the list (30) in a storage unit (11). When the processing unit (12) receives a verification request from a user belonging to the first organization (50), the processing unit (12) uses a public key corresponding to the user in charge in the list (30) to verify at least one of the electronic signature, which has been attached to the document at the point in time corresponding to the verification request, and information about a user who is a request receiver for an electronic signature and belongs to the second organization (60). The processing unit (12) responds with evaluation information pertaining to at least one of the status of signatures on the document corresponding to the verification result and a user who is a request receiver therefor.

Description

VERIFICATION METHOD, VERIFICATION PROGRAM AND INFORMATION PROCESSING DEVICE

The present invention relates to a verification method, a verification program, and an information processing device.

A workflow system may be used to support procedures by multiple users. A workflow system supports approval procedures by multiple users in an organization by asking users for approval of documents digitized by a computer according to a predetermined approval route and receiving user approval.

Identify, notify, and obtain approval from people in your company who need approval, for example, when one employee in your company requests the purchase of a particular item and another employee needs to approve the purchase. I have a proposal for a system.

U.S. Patent Application Publication No. 2012/0072445

Here, document approval procedures may be carried out across multiple organizations such as companies. When document approval procedures span multiple organizations, in order to ensure the reliability of documents, each organization requires that documents be approved by users included in appropriate approval routes. Therefore, there is a problem of a mechanism for supporting document approval procedures between organizations while making it possible to verify the reliability of digitized documents using information processing technology.

In one aspect, the present invention aims to enable verification of document reliability.

In one aspect, a verification method is provided. In this verification method, a computer detects registration of a document to which an electronic signature corresponding to a user belonging to a first organization is attached and to which an electronic signature corresponding to a user belonging to a second organization is not attached. Then, a notification regarding the document is transmitted to a predetermined registered user belonging to the second organization, and in response to the notification, when a list including the users in charge belonging to the second organization is received, the list is stored in the storage unit. , when a verification request from a user belonging to the first organization is received, the electronic signature attached to the document at the time of responding to the verification request using the public key associated with the user in charge included in the list, and , verifying at least one of the information of the requested user belonging to the second organization, which is attached to the document as the electronic signature requested destination, and the signature status of the document according to the verification result, and the requested destination Reputation information about at least one of the users is sent in response to the verification request.

Also, in one aspect, a verification program is provided. Also, in one aspect, an information processing apparatus having a storage unit and a processing unit is provided.

In one aspect, it allows verification of the authenticity of documents.
The above and other objects, features and advantages of the present invention will become apparent from the following description taken in conjunction with the accompanying drawings which represent exemplary preferred embodiments of the invention.

1 illustrates an information processing apparatus according to a first embodiment; FIG. It is a figure which shows the example of the information processing system of 2nd Embodiment. It is a figure which shows the hardware example of a control server. FIG. 4 is a diagram illustrating an example of functions of a control server; FIG. 10 is a diagram showing an example of organization X approval route information; FIG. 4 is a diagram showing an example of organization X information; FIG. 10 is a diagram showing an example of WF control; FIG. 10 is a diagram showing a description example of an intra-organizational signature frame in a document; FIG. 10 is a diagram showing a description example of an inter-organizational signature frame in a document; 4 is a flowchart showing an example of WF control; FIG. 10 is a diagram showing an example of WF verification; FIG. 10 is a diagram showing an example of acquisition of WF verification information; FIG. 10 is a diagram showing an example of obtaining a public key based on an intra-organizational signature frame; FIG. 10 illustrates an example of a WF verification method; 10 is a flow chart showing an example of WF verification; It is a figure which shows the example of a signature process. 4 is a flow chart showing an example of signature verification; FIG. 10 is a diagram illustrating an example of document movement; 9 is a flowchart showing a first modified example of WF control; FIG. 10 is a diagram showing an example of document encryption; FIG. 11 is a flow chart showing a second modified example of WF control; FIG. FIG. 10 is a diagram showing an example of cooperation with WF management tools of each organization; FIG. 11 is a flow chart showing a third modified example of WF control; FIG. FIG. 10 is a diagram showing an example of signature conversion; FIG. 11 is a flowchart showing a fourth modified example of WF control; FIG. FIG. 13 is a flow chart showing an example of signature verification in the fourth modified example; FIG.

Hereinafter, this embodiment will be described with reference to the drawings.
[First embodiment]
A first embodiment will be described.

FIG. 1 is a diagram illustrating an information processing apparatus according to the first embodiment.
The information processing apparatus 10 assists users of each organization in approving an electronic document 20 across a plurality of organizations. For example, multiple tissues include first tissue 50 and second tissue 60 . The name of the first organization is organization X. The name of the second organization is organization Y. The number of tissues may be 3 or more.

The first organization 50 has

client devices

51, 52, . The client device 51 is used by user X1. Client device 52 is used by user X2. Users X1 and X2 belong to a first organization 50. FIG. Users other than users X1 and X2 also belong to the first organization 50 .

The second organization 60 has

client devices

61, 62, . The client device 61 is used by user Y1. Client device 62 is used by user Y2. Users Y 1 and Y 2 belong to a second organization 60 . Users other than users Y1 and Y2 also belong to the second organization 60 .

The information processing device 10 and the

client devices

51 , 52 , 61 , 62 are connected to the network 40 . The network 40 is, for example, the Internet or a WAN (Wide Area Network).

The information processing device 10 has a storage unit 11 and a processing unit 12 . The storage unit 11 may be a volatile storage device such as a RAM (Random Access Memory) or a non-volatile storage device such as a HDD (Hard Disk Drive) or flash memory. The processing unit 12 may include a CPU (Central Processing Unit), DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Gate Array), and the like. The processing unit 12 may be a processor that executes programs. A "processor" may include a collection of multiple processors (multiprocessor).

The document 20 is an electronic document. Document 20 is subject to approval by users belonging to first organization 50 and users belonging to second organization 60 . An example of the document 20 is a contract. The contract indicates, for example, the details of the contract made by the first organization 50 and the second organization 60 .

The document 20 is stored in the storage unit 11. Document 20 may be stored in a device different from information processing device 10 . For example, document 20 may be stored in another information processing device connected to network 40 .

Here, it is assumed that the approval path for the document 20 is first to the first organization 50 and then to the second organization 60. The approval path is set in the document 20 itself. The processing unit 12 forwards the workflow according to the approval route information given to the document 20 . The processing unit 12 sets, in the document 20, the specific information of the user to whom the approval is requested in the organization when the workflow reaches the organization. For example, in the case of the document 20, at the stage of accepting approval by the user in the first organization 50 according to the approval route in the first organization 50, the document 20 includes the approval request destination in the second organization 60. No specific user information is set. Instead, at this stage, information is set in the document 20 indicating that the workflow's next forwarding destination is the second organization 60 . Thus, the approval route for the document 20 in each organization can be flexibly determined when the workflow arrives at the organization.

For example, if the document 20 is data in XML (Extensible Markup Language) format, the approval path information can be set by the order in which each user's signature frame for the document 20 is written using the "o:signatureline" tag. A signature frame is a frame provided in the document 20 for attaching an image such as a handwritten signature or seal stamp of the user who has performed the approval.

In addition, the processing unit 12 may acquire information on the approval path indicating the user to whom the approval is requested, which is predetermined for the attribute of the document in each organization, and set the information on the approval path to the document 20 . Alternatively, the processing unit 12 may receive an input of approval path information indicating a user to whom approval is requested in the organization by a user of the organization, and set the information of the approval path in the document 20 .

The electronic signature of the user is attached to the document 20 according to the approval of each user. Electronic signatures may also be referred to as digital signatures. For example, document 20 has management information 21 . The management information 21 includes information indicating the users to whom approval of the document 20 is requested and the order of requesting each user. The management information 21 may also include contact information such as the e-mail address of the user to whom the approval is requested. Furthermore, the management information 21 includes the electronic signature of the user who has given the approval. The electronic signature is, for example, data obtained by encrypting a hash value of difference data before and after processing of the document 20 by the user with the private key of the user. Information indicating the state of the document 20 before processing by the user is stored in the document 20 in association with the electronic signature of the user. It should be noted that since the user's electronic signature is attached to the document 20 by the approval of the requested user, it can also be said that the user to whom the approval is requested is the user to which the electronic signature is requested.

Here, in the example of the document 20, the users X1 and X2 are set in the document 20 in this order as the users requested for approval within the first organization 50. As described above, the information of the user to whom the approval is requested in the second organization 60 is not set in the document 20 while the approval is being performed in the first organization 50 . Instead, information is set in the document 20 indicating that the next organization is the second organization 60 .

The information processing apparatus 10 supports each user's approval of the document 20 across organizations while enabling verification of the reliability of the document 20 as follows.
First, the processing unit 12 notifies the user X1 of an approval request for the document 20 . For example, the processing unit 12 sends an approval request message for the document 20 to the email address of the user X1. The processing unit 12 attaches the electronic signature Xa of the user X1 to the document 20 upon receiving an approval input by the user X1 using the client device 51 .

Next, the processing unit 12 notifies the user X2 of an approval request for the document 20. For example, the processing unit 12 sends an approval request message for the document 20 to the e-mail address of the user X2. The processing unit 12 attaches the electronic signature Xb of the user X2 to the document 20 upon receiving an approval input by the user X2 using the client device 52 .

When the approval by the users X1 and X2 is completed, the processing unit 12 detects that the approval by the first organization 50 is completed. Then, the processing unit 12 notifies the user in charge of workflow management in the second organization 60 that the workflow of the document 20 has been sent. For example, the processing unit 12 may notify the e-mail address or mailing list of the user in charge of managing the workflow of the second organization 60, which is stored in the storage unit 11 in advance. It is assumed that users responsible for managing the workflows of the second organization 60 include user Y1.

In response to the notification, the processing unit 12 sends the list 30 of trusted users or users authorized for approval in the second organization 60 as approval request destinations input by the user Y1, for example, to the client device 61. , and stored in the storage unit 11 . However, the processing unit 12 may receive the list 30 from the client device 61 in advance and store it in the storage unit 11 . For example, list 30 may indicate users Y2 and Y3. User Y3 is a user belonging to the second organization 60 .

Furthermore, the processing unit 12 accepts, for example, an approval path in the second organization 60 input by another user in the organization Y, and sets it in the document 20. In the example of the document 20, the users Y2 and Y4 are set in the document 20 in this order as the users requested for approval within the second organization 60. FIG. User Y4 is a user belonging to the second organization 60 . For example, the information of the user Y4 to whom the approval is requested set in the document 20 may have been initially set by the user Y1 as the information of the user Y3, but changed to the information of the user Y4 by another user. good.

Then, the processing unit 12 notifies the user Y2 of the approval request for the document 20. For example, the processing unit 12 sends an approval request message for the document 20 to the email address of the user Y2. The processing unit 12 attaches the electronic signature Ya of the user Y2 to the document 20 upon receiving the input of approval using the client device 62 by the user Y2. At this stage, the document 20 has not been given the electronic signature of the user Y4.

Here, the processing unit 12 verifies whether or not the document 20 has been approved through an appropriate approval route in the second organization 60 in response to a request from a user belonging to the first organization 50. provide functionality.

In the first example, the processing unit 12 verifies the validity of the electronic signature attached to the document 20. Specifically, the processing unit 12 receives, for example, a verification request from the user X1 from the client device 51 . The verification request may include a designation of the organization whose electronic signature is to be verified. For example, user X1 may specify organization Y as the organization to be verified. Then, the processing unit 12 verifies the electronic signature Ya attached to the document 20 at the time of responding to the verification request using the public keys associated with the users Y2 and Y3 included in the list 30. . The processing unit 12 can obtain the public keys of the users Y2 and Y3 from a predetermined server device that stores the public keys of the users belonging to the second organization 60 .

In this example, it is assumed that the processing unit 12 successfully verifies the electronic signature Ya using the public key of user Y2. That is, the processing unit 12 obtains a hash value by decrypting the electronic signature Ya using the public key of the user Y2, and the hash value is the difference between the content of the document 20 before processing by the user Y2 and the content of the current document 20. It is assumed that it has been confirmed that the hash value of the difference matches. In this case, the processing unit 12 sends evaluation information to the client device 51 as a response to the verification request, indicating that the current document 20 was signed by the appropriate user Y2. Note that the notification of the evaluation information may be sent to the e-mail address of the user X1.

On the other hand, if the verification of the electronic signature Ya with the public key of the user included in the list 30 fails, the processing unit 12 sends evaluation information indicating that the document 20 was not signed by an appropriate user to the client. Send to device 51 .

Thus, the processing unit 12 can verify the validity of the electronic signature attached to the document 20. FIG.
In the second example, the processing unit 12 verifies the validity of the information of the requested user belonging to the second organization 60, which is given to the document 20 as the requested electronic signature destination. Specifically, the processing unit 12 receives, for example, a verification request from the user X1 from the client device 51 . The verification request may include the designation of the verification target organization of the requested user. For example, user X1 may specify organization Y as the organization to be verified. Then, the processing unit 12 uses the public key associated with each of the users Y2 and Y3 included in the list 30 to obtain the information of the requested user Y4 attached to the document 20 at the time of responding to the verification request. Validate.

Here, the processing unit 12 acquires the public key of the user Y4 from the aforementioned server device, and the public key of the user Y4 acquired based on the document 20 is added to the public keys of the users Y2 and Y3 included in the list 30. The information of the requested user Y4 is verified depending on whether or not it is included. In this example, the public key of the requested user Y4 does not match the public keys of any of the users Y2 and Y3. Therefore, the processing unit 12 transmits to the client device 51, as a response to the verification request, evaluation information indicating that the document 20 contains information about the unauthorized requested user Y4.

On the other hand, if the public key of the requested user matches any of the public keys of each user included in the list 30, the processing unit 12 determines that the requested user is valid. Then, if no unauthorized request destination user is set in the document 20, the processing unit 12 transmits evaluation information indicating that all the request destination users set in the document 20 are legitimate to the client device 51. do.

In this way, the processing unit 12 can verify the validity of the requested user's information added to the document 20 before the electronic signature is added to the document 20 by the requested user.

Note that the processing unit 12 may perform either one of the first example and the second example, or perform both the first example and the second example, as verification of document reliability. may For example, the processing unit 12 can verify the validity of the electronic signature Ya attached to the document 20 as well as the validity of the information of the requested user Y4 of the electronic signature attached to the document 20. .

In this way, when an unauthorized requested user Y4 is set in the document 20, the user X1 notifies the user of the second organization 60 (for example, user Y1) to that effect. For example, the processing unit 12 receives a change request from the user Y1 to change the requested user Y4 of the document 20 to a valid requested user, and changes the illegal requested user Y4 of the document 20 to a valid requested user. . Processing unit 12 then continues the workflow of document 20 in second organization 60 . Finally, when electronic signatures are added to document 20 by all authorized users, processing unit 12 terminates the workflow for document 20 .

As described above, according to the information processing apparatus 10, a document to which an electronic signature corresponding to a user belonging to a first organization is attached and to which an electronic signature corresponding to a user belonging to a second organization is not attached registration is detected. A notification regarding the document is sent to a predetermined registered user belonging to the second organization. Upon receipt of a list including responsible users belonging to the second organization in response to the notification, the list is stored in the storage unit 11 . When a verification request from a user belonging to the first organization is accepted, the electronic signature attached to the document at the time of responding to the verification request using the public key associated with the user in charge included in the list, and , verification of at least one of the information of the requested user belonging to the second organization, which is attached to the document as the requested destination of the electronic signature. Then, as a response to the verification request, the signature status of the document according to the result of the verification and evaluation information regarding at least one of the requested user is transmitted.

As a result, the information processing device 10 can verify the reliability of the document 20 . In addition, the information processing apparatus 10 can support the approval of the users of each organization across multiple organizations with respect to the document 20 while enabling verification of the reliability of the document 20 .

In the following, the functions exemplified in the information processing apparatus 10 will be described in more detail by exemplifying a more specific information processing system.
[Second embodiment]
Next, a second embodiment will be described.

FIG. 2 is a diagram illustrating an example of an information processing system according to the second embodiment.
The information processing system of the second embodiment includes a control server 100,

client devices

200, 200a, 400, 400a, an organization X server 300, an organization Y server 500, and

cloud systems

600, 700. FIG. Control server 100 and

cloud systems

600 and 700 are connected to network 70 . Network 70 is, for example, the Internet.

Here, the

cloud systems

600 and 700 are information processing systems that provide cloud services via the network 70. The

cloud systems

600 and 700 have multiple physical machines and storages, and provide the resources of the physical machines and storages to client computers via the network 70 . For example, cloud services performed by

cloud systems

600 and 700 include cloud-based storage services.

Cloud systems

600 and 700 may be operated by different providers.

Client devices

200 and 200a are client computers owned by organization X. Organization X is, for example, a company. The organization X server 300 is a server computer that organization X has.

Client devices

200 and 200a and organization X server 300 are used by users belonging to organization X. FIG.

Client devices

200 , 200 a and organization X server 300 are connected to network 80 . The network 80 is a LAN (Local Area Network) installed within the organization X. FIG. Network 80 is connected to network 70 . Users belonging to organization X operate

client devices

200 and 200 a to use cloud services provided by cloud system 600 .

Client devices

400 and 400a are client computers owned by organization Y. Organization Y is a company different from organization X, for example. The organization Y server 500 is a server computer that organization Y has.

Client devices

400 and 400a and organization Y server 500 are used by users belonging to organization Y. FIG.

Client devices

400 and 400 a and organization Y server 500 are connected to network 90 . A network 90 is a LAN installed within an organization Y. FIG. Network 90 is connected to network 70 . Users belonging to organization Y operate

client devices

400 and 400 a to use cloud services provided by cloud system 700 .

The control server 100 is a server computer that controls the approval workflow (WF: WorkFlow) of electronic documents across multiple organizations using the

cloud systems

600 and 700 . An electronic document is simply called a document. An electronic document may be called document data. Here, it is important to ensure the reliability of the document to be approved in order to approve the document across organizations. Therefore, the control server 100 provides a function to support cross-organizational approval procedures while enabling verification of document reliability. A service that assists in ensuring the reliability of documents is sometimes called TaaS (Trust as a Service). The control server 100 is an example of the information processing device 10 according to the first embodiment.

For example, the control server 100 and

cloud systems

600 and 700 function as web servers. Also, the

client devices

200, 200a, 400, and 400a function as web browsers. For example, users of the

client devices

200, 200a, 400, 400a can operate a web browser to use a GUI (Graphical User Interface) provided by a web server executed by the control server 100 or the

cloud systems

600, 700. be.

FIG. 3 is a diagram illustrating an example of hardware of a control server.
The control server 100 has a CPU 101 , a RAM 102 , an HDD 103 , a GPU (Graphics Processing Unit) 104 , an input interface 105 , a medium reader 106 and a NIC (Network Interface Card) 107 . Note that the CPU 101 is an example of the processing unit 12 of the first embodiment. The RAM 102 or HDD 103 is an example of the storage section 11 of the first embodiment.

The CPU 101 is a processor that executes program instructions. The CPU 101 loads at least part of the programs and data stored in the HDD 103 into the RAM 102 and executes the programs. Note that the CPU 101 may include multiple processor cores. Also, the control server 100 may have a plurality of processors. The processing described below may be performed in parallel using multiple processors or processor cores. Also, a set of multiple processors is sometimes called a "multiprocessor" or simply a "processor".

The RAM 102 is a volatile semiconductor memory that temporarily stores programs executed by the CPU 101 and data used by the CPU 101 for calculation. Note that the control server 100 may be provided with a type of memory other than the RAM, and may be provided with a plurality of memories.

The HDD 103 is a non-volatile storage device that stores software programs such as an OS (Operating System), middleware, and application software, and data. Note that the control server 100 may include other types of storage devices such as flash memory and SSD (Solid State Drive), or may include multiple non-volatile storage devices.

The GPU 104 outputs images to the display 71 connected to the control server 100 according to commands from the CPU 101 . As the display 71, any type of display such as a CRT (Cathode Ray Tube) display, a liquid crystal display (LCD: Liquid Crystal Display), a plasma display, or an organic EL (OEL: Organic Electro-Luminescence) display can be used.

The input interface 105 acquires an input signal from the input device 72 connected to the control server 100 and outputs it to the CPU 101 . As the input device 72, a mouse, a touch panel, a touch pad, a pointing device such as a trackball, a keyboard, a remote controller, a button switch, or the like can be used. Also, multiple types of input devices may be connected to the control server 100 .

The medium reader 106 is a reading device that reads programs and data recorded on the recording medium 73 . As the recording medium 73, for example, a magnetic disk, an optical disk, a magneto-optical disk (MO), a semiconductor memory, or the like can be used. Magnetic disks include flexible disks (FDs) and HDDs. Optical discs include CDs (Compact Discs) and DVDs (Digital Versatile Discs).

The medium reader 106 copies, for example, programs and data read from the recording medium 73 to other recording media such as the RAM 102 and the HDD 103. The read program is executed by the CPU 101, for example. Note that the recording medium 73 may be a portable recording medium, and may be used for distribution of programs and data. Also, the recording medium 73 and the HDD 103 may be referred to as a computer-readable recording medium.

The NIC 107 is an interface that is connected to the network 70 and communicates with other computers via the network 70 . The NIC 107 is, for example, connected to a communication device such as a switch or router by a cable. NIC 107 may be a wireless communication interface.

The

client devices

200 , 200 a , 400 , 400 a , the organization X server 300 and the organization Y server 500 are also realized by hardware similar to the control server 100 . Physical machines included in each of the

cloud systems

600 and 700 are also realized by hardware similar to the control server 100 .

FIG. 4 is a diagram showing an example of the functions of the control server. The control server 100 has a storage unit 110 and a control unit 130 . Storage areas of the RAM 102 and the HDD 103 are used for the storage unit 110 . The control unit 130 is implemented by the CPU 101 executing a program stored in the RAM 102 .

The storage unit 110 stores data used by the control unit 130 . Storage unit 110 has organization X approval path information 111 , organization X information 112 , organization Y approval path information 113 , organization Y information 114 , inter-organization approval path information 115 and WF verification information 116 .

The organization X approval route information 111 is information that indicates a template for approval routes within organization X according to document attributes. A document attribute is a type of document content such as a contract or an application form. The approval route template is information indicating a plurality of positions of the user who should approve and the order of each position according to the attributes of the document. The organization X information 112 is information indicating the name of the user corresponding to the position of each department within the organization X. FIG.

The organization Y approval path information 113 is information that indicates a model of an approval path within organization Y according to document attributes. The organization Y information 114 is information indicating the name of the user corresponding to the position of each department within the organization Y. FIG.

The inter-organizational approval route information 115 is information that indicates the order of organizations that should receive approval for each document. For example, the inter-organization approval path information 115 includes information indicating that a certain document is to be approved by organizations X and Y in this order. The inter-organizational approval route information 115 may include information indicating contact information such as a mailing list of users in charge of managing WFs in the relevant organization.

The WF verification information 116 is information used by the control unit 130 to verify the WF set in the document. The WF verification information 116 is a set of public keys of users who are trusted to approve documents in the relevant organization or users who are authorized to approve documents.

Although not shown, the storage unit 110 holds cloud service access information for accessing documents stored in the

cloud systems

600 and 700. The cloud service access information is cloud service account information for accessing the relevant document.

The control unit 130 controls WF across tissues. Control unit 130 has signature frame insertion unit 131 , personal name conversion unit 132 , WF management unit 133 , signature processing unit 134 , notification unit 135 , signature frame updating unit 136 and verification processing unit 137 .

The signature frame insertion unit 131 inserts a signature frame into the document. The signature frame is an area where the user who approves the document attaches an image such as a handwritten signature or seal stamp to the document to indicate that the document has been approved by the user himself/herself. In the following example, it is assumed that a handwritten signature image is added to the signature frame. Here, the document is data in XML format, for example. In this case, the signature frame information is described in the document using the "o:signatureline" tag. In addition, the order of the users to whom the approval is requested is specified according to the order in which the signature frames of the document are written.

The signature frame inserting unit 131 inserts a template of the approval route in the organization X into the document as a signature frame according to the attribute of the document, for example, based on the organization X approval route information 111 . At this stage, as a template for the approval path, the signature frame is provided with only information on the position, and not with the user's personal name. Further, when the WF is transferred to the organization Y after the organization X, the signature frame inserting unit 131 adds a signature frame indicating the next organization Y, that is, an inter-organizational signature frame to the document. The signature frame inserting unit 131 , for example, identifies the order of organizations that pass the WF for a given document based on the inter-organizational approval path information 115 . The inter-organizational approval path information 115 is preliminarily entered into the storage unit 110 by the user who drafted the relevant document.

Based on the organization X information 112, for example, the personal name conversion unit 132 notifies each post of the approval route template inserted into the document by the signature frame insertion unit 131 with the user's personal name, the user's e-mail address, etc. Give the destination information. Specifically, the personal name conversion unit 132 takes the drafting user who drafted the document as the starting point of the approval path. The personal name conversion unit 132 acquires the personal name and contact information of the user of the corresponding post in the department to which the drafting user belongs from the organization X information 112 for each post of the template of the approval route, and converts it into the signature frame of the document. , add the person's name and contact information. Here, a signature frame corresponding to each user within a certain organization is called an intra-organizational signature frame.

It should be noted that the signature frame insertion unit 131 may accept an input of an approval path including the user's personal name and set an in-house signature frame indicating the approval path in the document. That is, the signature frame insertion unit 131 may set the intra-organizational signature frame in the document without using the personal name conversion unit 132 .

The WF management unit 133 manages WFs related to documents. The WF management unit 133 notifies the approval request to the contact information such as the e-mail address of the user who next requests approval, based on the information of the intra-organizational signature frame attached to the document. When the WF management unit 133 accepts the user's approval of the document, the signature processing unit 134 adds the user's signature image to the user's intra-organizational signature frame and adds a digital signature to the document. When the digital signature is added to the document by the signature processing unit 134, the WF management unit 133 notifies the next approval request destination user of the approval request.

For example, when approval by all users of organization X registered in a document is completed, the WF management unit 133 starts the next WF of organization Y for that document. Immediately before the organization Y's WF is started, the signature frame updating unit 136 sets the approval path of the organization Y to the document. The WF management unit 133 terminates the WF when approval by all users of all organizations is completed.

The signature processing unit 134 attaches the signature image of the user who has approved the document to the user's intra-organizational signature frame, and also attaches the user's digital signature to the document. A user's private key used for digital signature is held in the storage unit 110, for example. However, the private key may be held in a client device used by the user or in a predetermined recording medium owned by the user.

The notification unit 135 notifies the user who manages the WF of the next organization that the WF has arrived when the approval of all users by the previous organization is completed.
The signature frame update unit 136 updates the inter-organization signature frame in the document to the intra-organization signature frame. For example, when the signature frame update unit 136 starts the WF of organization Y after organization X with respect to a certain document, based on the organization Y approval path information 113, the signature frame update unit 136 sets the template of the approval path of organization Y to the document. You may In this case, the user at the starting point of the approval path in organization Y is specified in the signature frame updating unit 136, so that the personal name conversion unit 132 sets a personal name for each position in the template of the approval path in the organization Y. be. However, the signature frame updating unit 136 may accept the input of the approval path including the personal name of the user of the next organization Y, and set the intra-organization signature frame indicating the approval path in the document.

Based on the WF verification information 116, the verification processing unit 137 verifies the legitimacy of each user included in the approval path given to the document. For example, the verification processing unit 137 receives a WF verification request from the client device 200 for a document whose WF has passed to organization Y after organization X. Then, the verification processing unit 137 determines whether or not the public key of each user of organization Y included in the approval path of the document is included in the public key of each user of organization Y included in the WF verification information 116 . If the determination is true, the verification processing unit 137 determines that each user of the organization Y included in the document approval path is valid, and responds to the client device 200 to that effect. On the other hand, if the determination is false, the verification processing unit 137 determines that an unauthorized user is included in the approval path of the document, and responds to the client device 200 about the unauthorized user. The verification processing unit 137 also verifies each user's digital signature attached to the document.

FIG. 5 is a diagram showing an example of organization X approval route information.
The organization X approval path information 111 is pre-stored in the storage unit 110 . The organization X approval path information 111 includes items of document attribute, draft, approval, and decision.

Document attributes are registered in the document attributes field. The draft item registers the department and position in the company to which the user who drafts the document belongs. The approval item registers the department and position of the user who approves the document. The approval item registers the department and position of the user who approves the document. Here, departments may be omitted in the drafting, approval and approval items. If the department is omitted, it indicates that it is the same department as the user who requested the control server 100 to start the WF, that is, the user who made the proposal.

Here, drafting, approval and approval are examples of multiple procedures involving signatures in WF. A series of procedures for drafting, approval and approval should be carried out in this order. Approval represents final approval, and can be considered to be the same procedure as approval.

For example, in the organization X approval path information 111, records with document attributes "contract", drafting "responsible", approval "department manager", and approval "-" are registered. For this record, the document with the attribute "contract" is first drafted and approved by the user with the position "person in charge", and then approved by the "manager" of the same department as the user who drafted it. Indicates that WF is complete.

Approval path templates are similarly registered in the organization X approval path information 111 for other document attributes. An approval route template indicated by the organization X approval route information 111 can include two or more sets of departments and positions corresponding to two or more requested users, including the drafter, for a given document attribute.

The organization Y approval path information 113 is also implemented by a data structure similar to that of the organization X approval path information 111 .
FIG. 6 is a diagram showing an example of organization X information.

The organization X information 112 is stored in the storage unit 110 in advance. The organization X information 112 includes items of department, title and name. The name of the department is registered in the department item. The name of a post is registered in the post item. The name of the user is registered in the item of name.

For example, in the organization X information 112, the name "name B" is registered for the department "XX department" and the position "manager". Also, in the organization X information 112, the name "name A" is registered for the department "XX department" and the position "person in charge".

The organization Y information 114 is also realized by a data structure similar to that of the organization X information 112. FIG.
Next, an example of WF control by the control unit 130 will be described.
FIG. 7 is a diagram showing an example of WF control.

Here, an example is shown in which the control server 100 accepts approval for a document 800 registered by a user of organization X by users belonging to organizations X and Y in turn.
First, the signature frame inserting section 131 acquires the document 800 from the client device 200 . The signature frame insertion unit 131 adds the intra-organizational signature frames 811 and 812 of the organization X to the document 800 based on the organization X approval path information 111 . In this example, organization X expects document 800 to be approved by two users. At this stage, the intra-organizational signature frames 811 and 812 are only registered with positions. Also, the signature frame insertion unit 131 adds an inter-organizational signature frame 813 to the document 800 based on the inter-organizational approval path information 115 . In the inter-organizational approval route information 115, for example, the user who drafted the document 800 presets information indicating that the WF for the document 800 is forwarded in the order of organizations X and Y in association with the identification information of the document 800. be done.

The signature frame insertion unit 131 stores the document 810 obtained by adding the intra-organization signature frames 811 and 812 and the inter-organization signature frame 813 to the document 800 in the cloud system 600 used by the organization X. For example, the intra-organizational signature frame 811 includes information indicating the position "person in charge". The intra-organizational signature frame 812 includes information indicating the position "Manager". In-house signature frames 811 and 812 are described in document 810 in this order. Therefore, the approval path in the organization X is in the order of the user corresponding to the intra-organization signature frame 811 and the user corresponding to the intra-organization signature frame 812 . Inter-organization signature frame 813 includes information indicating organization Y. FIG.

When the WF target document 810 is stored in the cloud system 600, the personal name conversion unit 132 acquires the document 810 from the cloud system 600, and based on the organization X information 112, inserts the user Inserts the user's personal name according to their job title. At this time, for example, the personal name conversion unit 132 may insert the user's contact information such as an e-mail address together with the user's personal name. The information of the e-mail address may be registered in the organization X information 112 in advance, or may be input by the user operating the client device 200, for example.

Thus, the personal name conversion unit 132 generates a document 820 for the document 810 and stores it in the cloud system 600. Document 820 has intra-organizational signature frames 821 and 822 and inter-organizational signature frame 823 . The in-house signature frames 821 and 822 correspond to the in-house signature frames 811 and 812, respectively. The intra-organization signature frame 821 contains the personal name of user A who belongs to organization X. The intra-organization signature box 822 contains the personal name of user B belonging to organization X. The inter-organizational signature frame 823 is the same as the inter-organizational signature frame 813 .

The WF management unit 133 starts a WF within the organization X based on the document 820 stored in the cloud system 600. For example, the WF management unit 133 sends an approval request to User A's e-mail address. User A, for example, operates the client device 200 , confirms the content of the document 820 via the control server 100 , and inputs approval for the document 820 . Upon receiving the input of user A's approval, the WF management unit 133 notifies the signature processing unit 134 of user A's approval. The signature processing unit 134 adds the signature image of the user A to the intra-organization signature frame 821 in response to user A's approval. Also, the signature processing unit 134 adds the digital signature of user A to the document 820 in response to user A's approval. Next, the WF management unit 133 notifies the user B's e-mail address of the approval request, and adds the signature image of the user B to the in-house signature frame 822 in response to user B's approval. Also, the signature processing unit 134 adds the digital signature of user B to the document 820 in response to user B's approval.

Thus, the signature processing unit 134 generates a document 830 for the document 820. Signature processing unit 134 stores document 830 in cloud system 600 . Document 830 has signed signature frames 831 and 832 and inter-organizational signature frame 833 . Signed signature frames 831 and 832 correspond to in-house signature frames 821 and 822, respectively. A signed signature frame 831 is obtained by adding a signature image of user A to the in-house signature frame 821 . A signed signature frame 832 is obtained by adding a signature image of User B to the in-house signature frame 822 . The inter-organizational signature frame 833 is the same as the inter-organizational signature frame 823 .

Based on the document 830, the WF management unit 133 moves the document 830 to the inter-organization shared data storage unit 150 of the control server 100 when it detects that all approvals by users A and B in the organization X have been completed. The inter-organization shared data storage unit 150 is a storage area for holding data shared by the organizations X and Y in the control server 100 . For the inter-organizational shared data storage unit 150, for example, storage areas of the RAM 102 and the HDD 103 are used.

When the notification unit 135 detects that the document 830 has been registered in the inter-organization shared data storage unit 150, based on the inter-organization signature frame 833 included in the document 830, the notification unit 135 adds a message to the mailing list of the user who manages the WF in the organization Y. , to notify that the WF has come around. The user corresponding to the e-mail address included in the mailing list registers the organization Y approval route information 113 in the control server 100 in response to the notification. Then, the signature frame updating unit 136 converts the inter-organization signature frame 833 included in the document 830 into the intra-organization signature frames 843 and 844 of the organization Y based on the organization Y approval path information 113 . In this example, organization Y expects document 840 to be approved by two users.

Thus, the signature frame update unit 136 generates a document 840 for the document 830 and stores the document 840 in the cloud system 700 used by organization Y. Document 840 has signed signature frames 841 and 842 and in-house signature frames 843 and 844 . The signed signature frames 841 and 842 are the same as the signed signature frames 831 and 832, respectively. For example, the intra-organizational signature frame 843 includes information indicating the position "person in charge". The intra-organizational signature frame 844 includes information indicating the post "section manager". The in-house signature frames 843 and 844 are described in the document 840 in this order. Therefore, the approval path in organization X is in the order of the user corresponding to the intra-organization signature frame 843 and the user corresponding to the intra-organization signature frame 844 .

As in the case of the organization X, when the document 840 is stored in the cloud system 600, the personal name conversion unit 132, based on the organization Y information 114, fills the in-organization signature frames 843 and 844 with a user name corresponding to the user's position. generates document 850 by inserting the personal name of

The document 850 has signed signature frames 851 and 852 and in-house signature frames 853 and 854. The signed signature frames 851 and 852 are the same as the signed signature frames 841 and 842, respectively. The intra-organization signature frame 853 includes the personal name of user C belonging to organization Y. The intra-organization signature frame 854 includes the personal name of user D belonging to organization Y.

Intra-organizational signature boxes

853 and 854 may contain the e-mail addresses of users C and D, respectively.

The WF management unit 133 can execute the WF for approval of the document 850 to the organization Y based on the intra-organization signature frames 853 and 854 of the document 850 in the same way as the organization X.
FIG. 8 is a diagram showing a description example of an intra-organizational signature frame in a document.

Description C1 is a description example of the in-house signature frame 811 in the document 810 . A description C2 is a description example of an in-house signature frame 821 in the document 820 . Descriptions C1 and C2 are descriptions according to the Signatureline format of Office (registered trademark) Open XML.

For example, the set signature line (signature frame) is indicated by the "o:signatureline" tag. For example, the name of the signer (approver) is described using the "o:suggestedsigner" tag. Email addresses are listed using the "o:suggestedsigneremail" tag. Job titles are described using the "o:suggestedsigner2" tag.

The user's personal name has not yet been set in the in-house signature frame 811. Therefore, in the description C1, "o:suggestedsigner2" is set to "person in charge", but "o:suggestedsigner" and "o:suggestedsigneremail" are not set.

The user's personal name is already set in the in-house signature frame 821. Therefore, in the description C2, for example, "A" is set to "o:suggestedsigner", "a@x.jp" is set to "o:suggestedsigneremail", and "responsible" is set to "o:suggestedsigner2".

For example, in organization X, when users A and B sign in order, the internal signature frame corresponding to user A and the internal signature frame corresponding to user B are described in order in document 810 and document 820. be. For example, the intra-organizational signature frames 812 and 822 are similarly described using the "o:signatureline" tag.

FIG. 9 is a diagram showing a description example of an inter-organizational signature frame in a document.
Description C3 is a description example of the inter-organizational signature frame 813 in the document 810 . The inter-organization signature frame 813 is also described using the “o:signatureline” tag, similarly to the intra-organization signature frames 811 and 821 .

For example, if a specific preposition is added to the information in the "o:suggestedsigner2" tag that indicates the job title, the description immediately after the preposition indicates the organization that delivers the document, not the job title of the signing user. Description C3 is, for example, the case where the preposition is "_org:". For example, in description C3, "_org:Y" is set to "o:suggestedsigner2". "Y" at the end of "_org:Y" is organization identification information. In description C3, for example, "o:suggestedsigner" and "o:suggestedsigneremail" are not set. If there are a plurality of organizations to which the document is to be sent next, the signature frame inserting unit 131 adds a description corresponding to the inter-organizational signature frame of each organization to the document in the order in which the document is passed.

Next, the WF control procedure of the control server 100 will be described.
FIG. 10 is a flowchart showing an example of WF control.
(S10) The signature frame insertion unit 131 acquires the document 800 created by the user A of the organization X in the cloud system 600. FIG.

(S11) Based on the organization X approval path information 111, the signature frame insertion unit 131 inserts the approval path of the organization X corresponding to the attributes of the document 800 into the document 800 as the intra-organization signature frames 811 and 812.

(S12) The signature frame inserting unit 131 identifies the next organization Y according to the document 800 based on the inter-organization approval path information 115, and inserts the inter-organization signature frame 813 corresponding to the organization Y into the document 800. Thus, signature frame inserting section 131 generates document 810 from document 800 and stores document 810 in cloud system 600 .

(S13) Based on the organization X information 112, the personal name conversion unit 132 converts the post in the approval path of the document 810 into a personal name. That is, the personal name conversion unit 132 adds the personal name and e-mail address of the user A to the intra-organizational signature box 811 . Further, the personal name conversion unit 132 identifies the personal name of the user B corresponding to the in-house signature frame 812 from the organization X information 112 based on the department to which the user A belongs. Add your first name and email address. Thus, the personal name converter 132 generates the document 820 from the document 810 and stores the document 820 in the cloud system 600. FIG.

(S14) The WF management unit 133 advances the WF within the organization X based on the intra-organization signature frames 821 and 822 in the document 820. The signature processing unit 134 adds signature images to the intra-organizational signature frames 821 and 822 according to the input of signatures by the users A and B. FIG. Further, the signature processing unit 134 attaches the digital signatures of the users A and B to the document 820 in response to the input of the signatures by the users A and B. FIG. Thus, the signature processing unit 134 generates a document 830 from the document 820. FIG.

(S15) The WF management unit 133 moves the document 830 to the inter-organizational shared data storage unit 150 when approval by the users A and B in the organization X is completed.
(S16) The notification unit 135 notifies a predetermined mailing list of the organization Y that the WF has been sent to the organization Y. FIG.

( S<b>17 ) The signature frame update unit 136 receives the registration of the approval route for the organization Y by the user of the organization Y, and adds the approval route to the organization Y approval route information 113 .
(S18) The signature frame updating section 136 converts the inter-organizational signature frame 833 of the organization Y in the document 830 to the intra-organizational signature frames 843 and 844 of the organization Y based on the attributes of the document 840 and the organization Y approval path information 113. , the approval path of organization Y is inserted into document 830 . As a result, signature frame updating section 136 generates document 840 from document 830 . The signature frame updating section 136 moves the document 840 to the cloud system 700 used by the organization Y. FIG.

(S19) Based on the organization Y information 114, the personal name conversion unit 132 converts the post in the approval path of the document 840 into a personal name. For example, the personal name conversion unit 132 receives designation of user C, who is the starting point of the approval path in organization Y, from the user of organization Y. FIG. Then, the personal name conversion unit 132 adds the personal name and e-mail address of the user C to the intra-organizational signature frame 843 . Further, the personal name conversion unit 132 identifies the personal name of user D corresponding to the intra-organization signature frame 844 from the organization Y information 114 based on the department to which user C belongs. Add your first name and email address. Thus, the personal name converter 132 generates the document 850 from the document 840. FIG.

(S20) The WF management unit 133 advances the WF within the organization Y based on the intra-organization signature frames 853 and 854 in the document 850. The signature processing unit 134 adds signature images to the intra-organizational signature frames 853 and 854 according to the input of signatures by users C and F. FIG. Further, the signature processing unit 134 adds the digital signatures of the users C and D to the document 850 in response to the input of the signatures by the users C and D. FIG. Thus, the WF control ends.

Here, the signature frame update unit 136 may receive the input of the approval path including the user's personal name from the user of the organization Y and set the approval path in the document 830 . Therefore, the control server 100 provides a function of performing WF verification in the process of WF control described above. WF verification is a function of verifying the legitimacy of a request destination user included in an approval path set in a document by a user of organization Y, for example.

FIG. 11 is a diagram showing an example of WF verification.
The signature frame updating unit 136 receives an instruction from the client device 400 to set the intra-organizational signature frames 853 and 854 for the document 830 moved to the inter-organizational shared data storage unit 150 . For example, the user of organization Y can operate the client device 400 to input an instruction to set the intra-organizational signature frames 853 and 854 to the signature frame update unit 136 . The signature frame update unit 136 generates a document 850 by converting the inter-organization signature frame 833 of the document 830 into the intra-organization signature frames 853 and 854 of the organization Y, and stores it in the cloud system 700 .

Upon receiving a WF verification request from the client device 200 , the verification processing unit 137 verifies the requested user of the organization Y corresponding to the in-house signature frames 853 and 854 of the document 850 based on the WF verification information 116 . A user of organization X can operate the client device 200 to input a WF verification request to the verification processing unit 137 .

Here, the WF verification information 116 is a set of public keys of multiple users who are allowed to be set in the approval path in the organization Y. The verification processing unit 137 acquires the public keys of the users of the intra-organization signature frames 853 and 854 from the organization Y server 500, and determines whether or not the acquired public keys are included in the WF verification information 116. Verify the requested user. The verification processing unit 137 responds to the client device 200 with a WF verification result indicating whether or not an unauthorized user is included in the approval path of the document 850 .

FIG. 12 is a diagram showing an example of acquisition of WF verification information.
The verification processing unit 137 obtains from the organization Y server 500 a list of e-mail addresses of a plurality of users permitted to be set in the approval path in the organization Y (step ST10). The e-mail addresses included in the list are, for example, the e-mail addresses included in the mailing list 501 to which the notification unit 135 notifies the organization Y that the WF has arrived. The list includes, for example, User C's e-mail address "c@xxx" and User D's e-mail address "d@xxx".

The client device 400 may provide the list of email addresses of the organization Y to the verification processing unit 137 in step ST10. Further, the provision of the list to the control server 100 by the organization Y server 500 or the client device 400 may be performed in response to the notification from the control server 100 that the WF of the relevant document has been sent to the organization Y. FIG.

The verification processing unit 137 issues a temporary ID (IDentifier) to the acquired e-mail address (step ST11). A temporary ID is temporary identification information corresponding to each e-mail address. The temporary ID may be, for example, a hash value of an e-mail address. Verification processing unit 137 stores temporary ID list 117 , which is a list of issued temporary IDs, in storage unit 110 . Also, the verification processing unit 137 transmits the provisional ID corresponding to the obtained e-mail address to the organization Y server 500 . The verification processing unit 137 may discard the acquired e-mail address. By discarding the acquired e-mail address, the verification processing unit 137 does not need to hold the e-mail address of the user of the organization Y. FIG.

The organization Y server 500 has a public key DB (DataBase) 502. The public key DB 502 stores the user's public key in association with the email address of the organization Y user. The organization Y server 500 associates and manages the public key and the temporary ID in the public key DB 502 .

The verification processing unit 137 transmits a public key acquisition request to the organization Y server 500 based on the temporary ID list 117 (step ST12). For example, the public key acquisition request includes a temporary ID corresponding to the e-mail address "c@xxx" and a temporary ID corresponding to the e-mail address "d@xxx". The organization Y server 500 acquires the user C's public key Kc and the user D's public key Kd from the public key DB 502 based on the temporary ID included in the public key acquisition request, and responds to the control server 100 . Then, the verification processing unit 137 receives the public keys Kc and Kd as a response to the public key acquisition request, and registers the public keys Kc and Kd in the WF verification information 116 of the organization Y (step ST13).

Thus, the verification processing unit 137 obtains the WF verification information 116. By using the temporary ID, the verification processing unit 137 can obtain the WF verification information 116 without using the user identification information used in the organization Y. FIG. Next, an example of acquisition of a public key based on an intra-organizational signature frame in a document by the control server 100 will be described.

FIG. 13 is a diagram showing an example of obtaining a public key based on an intra-organizational signature frame.
For example, document 850 has signed signature frames 851 and 852 and organization Y's in-house signature frames 853 and 854 . The intra-organizational signature frame 853 includes User C's e-mail address “c@xxx”. In-house signature box 854 includes User D's e-mail address “d@xxx”. The verification processing unit 137 designates the e-mail addresses of the users C and D, and inquires of the organization Y server 500 about the public key (step ST20).

In response to the public key inquiry, the organization Y server 500 refers to the public key DB 502 and responds to the control server 100 with user C's public key Kc and user D's public key Kd (step ST21). Thus, the verification processing unit 137 acquires the public keys Kc and Kd based on the in-house signature frames 853 and 854 of the document 850 .

Here, a document 860 is illustrated as a comparative example. Document 860 has signed signature frames 861 and 862 and organization Y's in-house signature frames 863 and 864 . Signed signature frames 861 and 862 are the same as signed signature frames 851 and 852 . Intra-organizational signature box 863 includes User C's e-mail address “c@xxx”. Intra-organizational signature box 864 includes User E's e-mail address “e@xxx”. The verification processing unit 137 designates the e-mail addresses of the users C and E, and inquires of the organization Y server 500 about the public key (step ST20a).

In response to the public key inquiry, the organization Y server 500 refers to the public key DB 502 and responds to the control server 100 with user C's public key Kc and user E's public key Ke (step ST21a). Thus, the verification processing unit 137 acquires the public keys Kc and Ke based on the in-house signature frames 863 and 864 of the document 860 .

FIG. 14 is a diagram showing an example of the WF verification method.
A first example is WF verification for document 850 based on WF verification information 116 . Verification processing unit 137 determines whether public key Kc obtained based on in-house signature frame 853 of document 850 is included in the set of public keys indicated by WF verification information 116 . WF verification information 116 includes public keys Kc and Kd. Therefore, the verification processing unit 137 determines that the user C corresponding to the in-house signature frame 853 is valid.

The verification processing unit 137 also determines whether the public key Kd obtained based on the intra-organizational signature frame 854 of the document 850 is included in the set of public keys indicated by the WF verification information 116 . Public key Kd is included in WF verification information 116 . Therefore, the verification processing unit 137 determines that the user D corresponding to the in-house signature frame 854 is valid.

Therefore, the verification processing unit 137 determines that the approval path set in the document 850 is valid. In this case, the correct WF is being executed for document 850 in organization Y.

A second example is WF verification for document 860 based on WF verification information 116 . Verification processing unit 137 determines whether public key Kc obtained based on in-house signature frame 863 of document 860 is included in the set of public keys indicated by WF verification information 116 . Public key Kc is included in WF verification information 116 . Therefore, the verification processing unit 137 determines that the user C corresponding to the in-house signature frame 853 is valid.

The verification processing unit 137 also determines whether the public key Ke acquired based on the intra-organizational signature frame 864 of the document 860 is included in the set of public keys indicated by the WF verification information 116 . Public key Ke is not included in WF verification information 116 . Therefore, the verification processing unit 137 determines that the user E corresponding to the in-house signature frame 864 is unauthorized.

Therefore, the verification processing unit 137 determines that the approval route set for the document 860 is incorrect. In this case, an illegal WF is being executed on the document 860 in the organization Y.

Note that the verification processing unit 137 can use, for example, a Bloom filter to determine whether a certain public key is included in the set of public keys indicated by the WF verification information 116.

Next, a procedure for WF verification of the control server 100 will be described.
FIG. 15 is a flowchart showing an example of WF verification.
(S30) The verification processing unit 137 receives the document WF verification request. For example, the user of the organization X can operate the client device 200 to input to the control server 100 a WF verification request specifying the WF verification target document 850 .

(S31) Based on the WF verification information 116 of organization Y, the verification processing unit 137 verifies the WF set in the document, that is, the validity of each user included in the approval path. As illustrated in FIG. 14, the verification processing unit 137 determines whether the public key of the requested user acquired based on the in-house signature frame of the document is included in the set of public keys indicated by the WF verification information 116. The legitimacy of the requested user is verified depending on whether or not.

(S32) In step S31, the verification processing unit 137 determines whether or not all users included in the WF of the relevant document are valid. If all users are valid, the process proceeds to step S33. If an unauthorized user is included, the process proceeds to step S34.

(S33) The verification processing unit 137 replies that the WF of the document in question, that is, all users set in the approval path are valid. Then the WF verification ends.
(S34) The verification processing unit 137 responds with the WF of the document, that is, the information of the user illegally set in the approval path. Then the WF verification ends.

In this way, the control server 100 can verify the legitimacy of the requested user even before the digital signature of the requested user in the organization Y is attached to the

documents

850, 860, and the like. For example, even if the control server 100 does not permit the use of the organization Y approval path information 113 in processing for the user of organization X, the control server 100 responds to the verification request of the user of organization X. The legitimacy of the requested user in organization Y can be verified using the key.

On the other hand, the control server 100 can also verify the digital signatures already attached to the

documents

850, 860, and the like. Therefore, the addition of a digital signature by the control server 100 will now be described.

FIG. 16 is a diagram showing an example of signature processing.
FIG. 16 shows an example in which the digital signatures of users A and B of organization X are attached to a document 820 in order.

A document 820 has a text R1 and document format information R2. Text R1 is the text of document 820 and includes in-house signature frames 821 and 822 . The document format information R2 is information indicating the format of the document 820. FIG. In this example, the signature processing unit 134 adds a digital signature to the extension area of the document format information R2.

First, the WF management unit 133 requests user A to approve the document 820 . Signature processing unit 134 processes document 820 in accordance with the user's approval of document 820 to generate document 820a (step ST30). Specifically, the signature processing unit 134 adds the signature image of the user A to the intra-organization signature frame 821 in response to user A's approval of the document 820 . Further, the signature processing unit 134 attaches the digital signature of user A to the document 820 in response to user A's approval. The signature processing unit 134 stores the document 820 a to which user A's digital signature has been added in the cloud system 600 .

Here, the document 820a has a text R1a and document format information R2a. The text R1a has a signed signature frame 821a and an in-house signature frame 822a. The signed signature frame 821a is obtained by adding a signature image of user A to user A's intra-organizational signature frame. The intra-organization signature frame 822 a is the same as the intra-organization signature frame 822 . User A's digital signature is added to the extension area of the document format information R2a as follows.

The signature processing unit 134 creates difference information diff1. The difference information diff1 indicates the difference between the contents of the text R1 at the time of the approval request to the user A and the contents of the text R1a immediately after the approval by the user A is performed. Note that the signature processing unit 134 saves the content of the text R1 at the time of the approval request as data "previous.audit" in the extended area of the document format information R2a. Then, the signature processing unit 134 converts the hash value H(diff1) of the difference information diff1 and the value Sig(H(diff1)) obtained by encrypting the hash value H(diff1) with the secret key of the user A into the document format information R2a. add to the extension area of . Sig(H(diff1)) corresponds to user A's digital signature. Here, data in which H(diff1) and Sig(H(diff1)) are put together is described as "1.audit".

Next, the WF management unit 133 requests User B to approve the document 820a. The signature processing unit 134 processes the document 820a and generates the document 830 according to the user's approval of the document 820a (step ST31). Specifically, the signature processing unit 134 adds the signature image of the user B to the in-house signature frame 822a in response to user B's approval of the document 820a. Further, the signature processing unit 134 attaches the user B's digital signature to the document 820a in response to user B's approval. The signature processing unit 134 stores the document 830 to which User B's digital signature has been added in the cloud system 600 .

The document 830 has a text R1b and document format information R2b. Text R1b has a signed signature frame 831 and a signed signature frame 832 as described above. The signed signature frame 831 is the same as the signed signature frame 821a. The signed signature frame 832 is obtained by adding a signature image of user B to user B's in-house signature frame 822a. User B's digital signature is added to the extension area of the document format information R2b as follows.

The signature processing unit 134 creates difference information diff2. The difference information diff2 indicates the difference between the contents of the text R1a at the time of the approval request to the user B and the contents of the text R1b immediately after the approval by the user B is performed. The signature processing unit 134 adds the contents of the text R1a at the time of the approval request to the data "previous.audit" in the extended area of the document format information R2b and saves it. In this way, "previous.audit" holds the update history of text R1b. Then, the signature processing unit 134 converts the hash value H(diff2) of the difference information diff2 and the value Sig(H(diff2)) obtained by encrypting the hash value H(diff2) with the secret key of the user B into the document format information R2b. add to the extension area of . Sig(H(diff2)) corresponds to user B's digital signature.

In this way, the document 830 is in a state where the digital signatures of users A and B are added. The signature processing unit 134 similarly adds the digital signature of the user of the organization Y to the document when the WF for the document is transferred to the organization Y. FIG.

When verifying a digital signature, for example, the verification processing unit 137 obtains a hash value H(diff2) by decrypting Sig(H(diff2)) with user B's public key. The verification processing unit 137 stores the WF verification information of the organization X including the public key of the user B in the organization X server having the public key DB of the organization X in the same manner as the acquisition of the public key of the user of the organization Y illustrated in FIG. 300 available.

For example, the verification processing unit 137 acquires the difference between the texts R1a and R1b based on the data "previous.audit" in the document 830 and obtains the hash value. If the hash value matches the hash value H(diff2), the verification processing unit 137 determines that the verification of the user B's digital signature is successful. On the other hand, if Sig(H(diff2)) cannot be decrypted with user B's public key, or if it can be decrypted but the hash value of the difference between texts R1a and R1b does not match hash value H(diff2), Digital signature verification fails. The verification processing unit 137 also verifies the digital signature of the user A on the document 830 by determining whether the hash value of the difference between the texts R1 and R1a based on the data "previous.audit" matches the hash value H (diff1). do. At this time, the verification processing unit 137 obtains a hash value H(diff1) by decrypting Sig(H(diff1)) with user A's public key.

When verifying the digital signature of the user of organization X, the verification processing unit 137 determines whether or not the digital signature has been successfully verified with any of the public keys included in the WF verification information of organization X. Then, if the verification processing unit 137 succeeds in verifying the digital signature with any of the public keys included in the WF verification information of the organization X, the digital signature is signed by an appropriate user of the organization X, Determine that the document is genuine. If the verification of the digital signature fails with any public key included in the WF verification information of organization X, the verification processing unit 137 determines that the digital signature was signed by an unauthorized user and the document is not authentic. I judge. The verification processing unit 137 also verifies the organization Y's digital signature using the organization Y's WF verification information 116 in the same way.

Next, the signature verification procedure of the control server 100 will be described.
FIG. 17 is a flow chart showing an example of signature verification.
(S40) The verification processing unit 137 receives a verification request for the user's digital signature attached to the document. For example, the user of organization X can operate the client device 200 to input to the control server 100 a request to verify the digital signature of the user of organization Y on the document to which the user of organization Y has attached the digital signature.

(S41) The verification processing unit 137 verifies each user's digital signature attached to the document. The verification processing unit 137 verifies the digital signature by the method described in FIG. 16, for example. For example, the verification processing unit 137 can acquire the public key used to verify the digital signature of the user of the organization Y in the same way as the WF verification information 116 is acquired.

(S42) The verification processing unit 137 determines whether verification of all digital signatures attached to the document has been successful. If all digital signatures have been successfully verified, the process proceeds to step S43. If verification of at least one of the digital signatures fails, the process proceeds to step S44. Here, the digital signature to be verified may be only the digital signature of the user of the organization specified by the user (for example, organization Y).

(S43) The verification processing unit 137 responds that the relevant document is authentic. Then the signature verification ends.
(S44) The verification processing unit 137 responds that the document is not genuine and that the document has been falsified by a third party. Then the signature verification ends. Note that, for example, if the verification of the digital signature given by the organization Y fails using any public key in the WF verification information 116, the above third party belongs to the organization Y, but the approval request by the WF It may include users who have not previously been formally recognized by organization Y.

In this way, the control server 100 can also verify the reliability of the document by verifying the digital signature attached to the document.
In this way, the control server 100 can verify the reliability of WF target documents across organizations. In addition, the information processing apparatus 10 can support the approval work of users in each organization over a plurality of organizations while enabling the verification of the reliability of the document.

In addition, the control server 100 can dynamically add and update WFs to documents, and implement a service (TaaS) that guarantees data authenticity with digital signatures. The control server 100 can dynamically update the WF for the document. Therefore, by making it possible to verify the legitimacy of a WF based on a document in response to a request from a user other than the WF setter, it is possible to support appropriate approval work by users belonging to different organizations.

Furthermore, the control server 100 controls the WF appropriately across organizations, thereby making it possible to connect the approval work of each user in each organization as a series of operations by multiple organizations. As a result, the control server 100 can expand the application range of TaaS not only within one organization but also to multiple organizations.

Next, a modified example of WF control by the control server 100 will be described.
(First modification)
A first modification is an example in which the control server 100 moves the document 830 from the cloud system 600 to the cloud system 700 .

FIG. 18 is a diagram showing an example of document movement.
The control unit 130 may further have a data moving unit 138 in addition to the functions illustrated in FIG. The storage unit 110 also stores cloud service access information 118 . The cloud service access information 118 holds account information for accessing cloud services available to organization Y in the cloud system 700 . For example, the cloud service access information 118 includes the URL (Uniform Resource Locator) of the cloud service and the ID and password (PW: PassWord) information for accessing the cloud service for the identification information of the organization to which the document is sent. have. The cloud service access information 118 may also include the address of the mailing list to which the notification unit 135 notifies the relevant organization. Although illustration is omitted, the cloud service access information 118 may also include information on the organization X account for accessing the cloud system 600 .

The data migration unit 138 moves the document 830 from the cloud system 600 to the cloud system 700. For example, when the document 830 that has been approved by users A and B of organization X is stored in the cloud system 600, the notification unit 135 notifies a predetermined user of organization Y that WF has been sent to organization Y. . At the same time, the data mover 138 acquires the document 830 from the cloud system 600 and moves the document 830 to the cloud system 700 . At this time, the data mover 138 obtains the URL of the cloud service corresponding to the organization Y and the ID and password for accessing the cloud service based on the cloud service access information 118 . The data mover 138 accesses the cloud service and stores the document 830 in the storage on the cloud system 700 provided by the cloud service.

The signature frame update unit 136 updates the document 830 on the cloud system 700 to the document 850 by adding, for example, the approval path information received from the client device 400 to the document 830 . Then, the WF management unit 133 starts the WF in the organization Y based on the document 850. FIG.

FIG. 19 is a flowchart showing a first modified example of WF control.
(S50) The signature processing unit 134 sequentially attaches the digital signatures of the users A and B to the document 820 stored in the cloud system 600 according to the approval path of the organization X. As a result, signature processing unit 134 generates document 830 and stores it in cloud system 600 .

(S51) The notification unit 135 notifies the organization Y's mailing list that the WF has been sent to the organization Y.
(S52) The data mover 138 moves the document 830 from the cloud system 600 used by the organization X to the cloud system 700 used by the organization Y based on the cloud service access information 118. FIG.

(S53) The signature frame updating unit 136 accepts registration of the organization Y's approval path by the user of the organization Y for the document 830. FIG.
(S 54 ) The signature frame update unit 136 converts the inter-organizational signature frame 833 of the organization Y in the document 830 into intra-organizational signature frames 853 and 854 to generate the document 850 and store it in the cloud system 700 . In step S54, the signature frame update unit 136 may generate the document 840, and the personal name conversion unit 132 may generate the document 850 based on the document 840. FIG.

(S55) The WF management unit 133 advances the WF according to the approval route set in the document 850. The signature processing unit 134 sequentially adds digital signatures to the document 850 in accordance with the approval of the users C and D of the organization Y. FIG. Then, the WF control ends.

In this way, the control server 100 moves the document 830 that has been approved by the organization X from the cloud system 600 to the cloud system 700 without storing it in the inter-organizational shared data storage unit 150 of the control server 100. good. As a result, the control server 100 can accommodate users who do not want to deposit the document 830 with the control server 100 .

(Second modification)
A second modification is an example in which the control server 100 encrypts the document 830 .
FIG. 20 is a diagram showing an example of document encryption.

The control unit 130 may further have a data moving unit 138, an encryption unit 139 and a decryption unit 140 in addition to the functions illustrated in FIG. In addition, the storage unit 110 further stores key information 119 . Although not shown, the storage unit 110 also stores cloud service access information 118 used by the data migration unit 138 .

The encryption unit 139 encrypts the document 830 that has been approved by the organization X to generate a document 830 a and store it in the cloud system 600 . A key used to encrypt the document 830 is stored in the key information 119 in advance. The key used to encrypt document 830 is the public key corresponding to organization Y, for example. Since the document 830a is data obtained by encrypting the document 830, it may be called encrypted data.

When the document 830a is stored in the cloud system 600, the notification unit 135 notifies the user of the organization Y that WF has arrived. The data mover 138 moves the document 830 a instead of the document 830 from the cloud system 600 to the cloud system 700 .

The decryption unit 140 decrypts the encrypted document 830a into the document 830 and stores it in the cloud system 700 when accepting the registration of the approval path for the document 830 by the user of the organization Y using the client device 400. A key used for decryption is stored in advance in the key information 119 . The key used for decryption is a private key corresponding to organization Y, for example.

The signature frame update unit 136 updates the document 830 on the cloud system 700 to the document 850 by adding the approval path information received from the client device 400 to the document 830 obtained by the decryption unit 140. . Then, the WF management unit 133 starts the WF in the organization Y based on the document 850. FIG.

FIG. 21 is a flowchart showing a second modified example of WF control.
In the procedure of the second modification, in the procedure of the first modification illustrated in FIG. 19, the control server 100 executes step S50a after step S50, and executes step S53a after step S53. Therefore, steps S50a and S53a will be mainly described here, and description of other steps will be omitted.

(S50a) The encryption unit 139 generates an encrypted document 830a by encrypting the document 830 with the organization Y's public key, and stores it in the cloud system 600. Then, the process proceeds to step S51.

It should be noted that in step S52, instead of the document 830, the data transfer unit 138 transfers the encrypted document 830a from the cloud system 600 to the cloud system 700 as described above.

(S53a) The decryption unit 140 decrypts the encrypted document 830a moved to the cloud system 700 with the private key of the organization Y to generate the document 830 and store it in the cloud system 700. Then, the process proceeds to step S54.

In this way, the control server 100 sets the document to be moved from the cloud system 600 to the cloud system 700 not as the document 830 but as the encrypted document 830a.

Here, for example, when the document 830 is sent by the user to a system used by an organization other than the organizations X and Y, the document 830 can be used by an organization unrelated to WF. For example, a user of organization X may use client device 200 to download document 830 from cloud system 600 and send it to a system used by an organization other than organizations X and Y.

Therefore, the control server 100 holds an encryption key for each document destination organization. When transferring data across organizations, the control server 100 encrypts the document with the public key of the destination organization specified by the WF, for example, and encrypts the document with the private key of the destination when updating the WF of the destination organization. decrypt the document. Then, for example, since the encrypted document 830a can only be decrypted via the control server 100, the system used by the organizations other than the organizations X and Y cannot decrypt it. In this way, the control server 100 can force the organization to use the data in line with the WF, and prevent unauthorized acquisition of the contents of the document 830 .

(Third modification)
A second modification is an example in which the control server 100 performs WF control in cooperation with the WF management tools of the organizations X and Y, respectively. Here, the WF management tool is a function that executes WF within the relevant organization.

FIG. 22 is a diagram showing an example of cooperation with the WF management tools of each organization.
For example, organization X server 300 may have organization X approval path storage 310 and WF management tool 320 . The organization X approval path storage unit 310 stores information on approval paths in organization X according to document attributes.

The WF management tool 320 refers to the organization X approval path storage unit 310 to acquire the organization X approval path for the WF target document and provides it to the control server 100 . In addition, the WF management tool 320 accepts the approval of the user of the organization X and notifies the control server 100 of the approval by the user.

In addition, the organization Y server 500 may have an organization Y approval path storage unit 510 and a WF management tool 520. The organization Y approval path storage unit 510 stores information on the approval path in organization Y according to document attributes.

The WF management tool 520 refers to the organization Y approval path storage unit 510 to acquire the organization Y approval path for the WF target document and provides it to the control server 100 . Also, the WF management tool 520 accepts the approval of the user of the organization Y, and notifies the control server 100 that the user has given approval.

Here, the control unit 130 may further have

cooperation units

141 and 142 in addition to the functions illustrated in FIG. The cooperation unit 141 cooperates with the WF management tool 320 to support the processing of the signature frame insertion unit 131 and the signature processing unit 134 for documents stored in the cloud system 600 . Also, the cooperation unit 142 cooperates with the WF management tool 520 to support the processing of the signature frame update unit 136 . For example, the control server 100 cooperates with the

WF management tools

320 and 520 as follows.

First, the user of the organization X uses the client device 200 to register the document 800 that is the WF target across the organizations X and Y in the cloud system 600 .
Then, the signature frame inserting unit 131 acquires the approval path of the organization X for the document 800 from the WF management tool 320 via the cooperation unit 141 . Assume that the approval path for organization X includes users A and B. The signature frame inserting unit 131 generates a document 820 by setting an intra-organizational signature frame in the organization X indicating the approval path of the organization X and an inter-organizational signature frame indicating the next organization Y to the document 800. 600. The cooperation unit 141 notifies the WF management tool 320 that the document 820 has been stored in the cloud system 600 .

WF management tool 320 starts WF in organization X for document 820 . The WF management tool 320 sequentially receives the approval of the users A and B of the organization X for the document 820, and notifies the control server 100 of the acceptance of approval by the users A and B. FIG. When the signature processing unit 134 is notified via the cooperation unit 141 that the approval by the users A and B has been accepted, it adds the signature image of the corresponding user to the intra-organization signature frame of the document 820. , gives the digital signature of the user in question to the document 820 .

When the approval of users A and B of organization X is completed in this way, the signature processing unit 134 moves the document 830 to which the digital signatures of users A and B are added to the inter-organizational shared data storage unit 150 . Then, the notification unit 135 notifies the user of the organization Y that the WF has arrived. The user of organization Y operates the client device 400 to specify the approval path in organization Y for the document 830 to the WF management tool 520 .

Then, the signature frame updating unit 136 acquires the approval path of the organization Y for the document 830 from the WF management tool 520 via the cooperation unit 142 . Assume that the approval path for organization Y includes users C and D. The signature frame update unit 136 generates a document 850 by updating the inter-organization signature frame in the document 830 to an intra-organization signature frame indicating the approval path of the organization Y, and stores it in the cloud system 700 .

Then, the WF management tool 520 starts the WF in organization Y for the document 850. After that, the control server 100 cooperates with the WF management tool 520 to sequentially attach the digital signatures of the users C and D to the document 850 according to the approval of the users C and D of the organization Y. FIG.

FIG. 23 is a flowchart showing a third modified example of WF control.
(S60) The cooperation unit 141 detects that the document 800 has been saved in the cloud system 600 by the user A of the organization X, and notifies the signature frame insertion unit 131 of the detection.

(S61) The signature frame insertion unit 131 acquires the approval path of the organization X from the WF management tool 320 of the organization X via the cooperation unit 141, and inserts it into the document 800. Also, the signature frame inserting unit 131 inserts the inter-organizational signature frame indicating the next organization Y into the document 800 . As a result, document 800 is updated to document 820 . In step S61, the signature frame inserting unit 131 may insert the template of the signature frame of the organization X into the document 800 to generate the document 810, and the personal name conversion unit 132 may generate the document 820 from the document 810. . Then, the WF within the organization X is started by the WF management tool 320 for the document 820 .

(S62) The signature processing unit 134 receives, via the cooperating unit 141, a notification that the user A has been approved for the approval request to the user A by the WF management tool 320 of the organization X. Then, the signature processing unit 134 adds User A's digital signature to the document 820 . As a result, the document 820 is updated to the aforementioned document 820a.

(S63) The signature processing unit 134 notifies the WF management tool 320 of the organization X via the cooperation unit 141 that the user A's digital signature has been completed.
(S64) The signature processing unit 134 receives, via the coordinating unit 141, a notification that the user B has been approved for the approval request to the user B by the WF management tool 320 of the organization X. Then, the signature processing unit 134 adds User B's digital signature to the document 820a. As a result, the document 820a is updated to the document 830. FIG.

(S65) The signature processing unit 134 notifies the WF management tool 320 of the organization X via the cooperation unit 141 that the user B's digital signature has been completed. As a result, the WF within the organization X by the WF management tool 320 is terminated.

(S66) When the signature processing unit 134 detects that the document 830 has the digital signatures of all the users A and B who are the request recipients in the organization X, it transfers the document 830 to the inter-organizational data sharing area. move. Then, the notification unit 135 notifies a predetermined mailing list of the organization Y that the WF has been sent to the organization Y. FIG.

(S67) The signature frame updating unit 136 acquires the approval path of the organization Y for the document 830 from the WF management tool 520 of the organization Y via the cooperation unit 142. The signature frame updating unit 136 inserts the approval path of organization Y into the document 830 by converting the inter-organization signature frame of the document 830 into an intra-organization signature frame indicating the approval path of organization Y. FIG. The document 830 is thereby updated to the document 850 . Then, the WF within the organization Y by the WF management tool 520 is started for the document 850 . Note that the approval path for organization Y may be set in document 850 by signature frame update unit 136 and personal name conversion unit 132, as in step S61.

(S68) The signature processing unit 134 receives, via the cooperation unit 142, a notification that the user of the organization Y has approved the request for approval by the WF management tool 520 of the organization Y to the user. Then, the signature processing unit 134 attaches the digital signature of the user to the document 850 . After that, the control server 100 advances the WF of the organization Y in cooperation with the WF management tool 520 . When the document 850 is given the digital signatures of all the users requested by the organization Y, the WF within the organization Y by the WF management tool 520 ends, and the WF control of the control server 100 also ends.

In this way, the control server 100 can also cooperate with the WF management tools possessed by each organization. As a result, the control server 100 can flexibly use the WF of cross-organizational documents by each organization. For example, each organization can use existing WF management tools to reduce the burden associated with the introduction of WF for cross-organizational documents.

(Fourth modification)
A fourth modification is an example in which the control server 100 converts a plurality of signed signature frames for each user in the document 830 into signed signature frames for each organization. In this case, the control server 100 also converts multiple digital signatures for each user into digital signatures for each organization.

FIG. 24 is a diagram showing an example of signature conversion.
The control unit 130 may further have a signature conversion unit 143 and a document relationship management unit 144 in addition to the functions illustrated in FIG.

The signature conversion unit 143 converts the signed signature frames 831 and 832 of the users A and B in the document 830 into a signed signature frame 831b for each organization X unit. Here, the signed signature frame 831b is, for example, a signature frame to which an image of the seal of the organization X such as the company seal is attached. The signed signature frame 831b, like the signed signature frames 831 and 832, is described in the document using, for example, the "o:signatureline" tag.

Furthermore, the signature conversion unit 143 converts the digital signatures of the users A and B attached to the document 830 into the digital signature of the organization X. The signature conversion unit 143 may use e-seal, for example, as the digital signature of the organizational unit. As a result, the signature conversion unit 143 updates the document 830 to the document 830b. The organization X's digital signature is also retained in the document 830b by the method illustrated in FIG. 16, like the user's personal digital signature.

At this time, the signature conversion unit 143 leaves the document 830 before signature conversion on the cloud system 600, and adds pointer information 835b indicating the document 830 to the document 830b. That is, the document 830b has a signed signature frame 831b, an inter-organizational signature frame 833b and pointer information 835b. The inter-organization signature frame 833 b is the same as the inter-organization signature frame 833 .

For example, the pointer information 835b is the ID of the document 830. In response to the assignment of the pointer information 835b to the document 830b, the document relationship management unit 144 stores the document correspondence information 120 indicating the correspondence between the ID of the document 830 and the storage location of the document 830 in the cloud system 600 in the storage unit 110. Record.

The signature conversion unit 143 moves the document 830b after signature conversion to the inter-organizational shared data storage unit 150. Then, the notification unit 135 notifies the user of the organization Y that the WF has been sent to the organization Y. FIG. The signature frame update unit 136 receives the setting of the approval route for the organization Y by the user of the organization Y, and sets the approval route for the organization Y in the document 830b. As a result, the document 830b is updated to the document 850a. Signature frame update unit 136 stores document 850 a in cloud system 700 .

The document 850a has a signed signature frame 851a,

internal signature frames

853a and 854a, and pointer information 855a. The signed signature frame 851a is the same as the signed signature frame 831b. The in-house signature frames 853a and 854a are the same as the in-house signature frames 853 and 854, respectively. The pointer information 855a is the same as the pointer information 835b.

In this way, the control server 100 may convert the digital signature for each user of organization X into a digital signature for each organization X when organization X completes approval. In this case, the verification processing unit 137 can verify the digital signature of the organization X based on the document 850a, for example. This makes it possible to verify that the content of document 850a is approved by organization X. The verification processing unit 137 can also identify the document 830 based on the pointer information 855 a and the document correspondence information 120 and verify the digital signatures of the users A and B attached to the document 830 .

FIG. 25 is a flowchart showing a fourth modified example of WF control.
(S70) When the document 830 is stored in the cloud system 600, the signature conversion unit 143 detects that the signature processing of each user of the organization X for the document 830 has been completed. The signature conversion unit 143 may detect from the notification from the signature processing unit 134 that the signature processing of each user of the organization X for the document 830 has been completed.

(S71) The signature conversion unit 143 requests the verification processing unit 137 to verify the organization X's WF. The verification processing unit 137 performs WF verification of the organization X based on the document 830 and returns the WF verification result to the signature conversion unit 143 . The verification processing unit 137 performs WF verification on the tissue X according to the procedure of FIG. The signature conversion unit 143 determines whether or not all users on the approval path of organization X are valid based on the result of organization X's WF verification. If all users on the approval path of organization X are valid, the process proceeds to step S73. If there is an unauthorized user in the approval path of organization X, the process proceeds to step S72.

(S72) The signature conversion unit 143 stops signature processing. Then, the WF control ends. In this case, the signature conversion unit 143 notifies a predetermined user of the organization X that WF cannot be continued for the document 830 because an unauthorized user is included in the approval path of the organization X.

(S73) The signature conversion unit 143 updates the document 830 to the document 830b by deleting the personal signature of the organization X in the document 830, that is, the digital signatures of the users A and B, and inserting the signature of the organization X. At this time, signature conversion unit 143 leaves document 830 on cloud system 600 . The signature conversion unit 143 also deletes the signed signature frames 831 and 832 for each user and updates them to the signed signature frame 831b for each organization.

(S74) The signature conversion unit 143 moves the document 830b after signature conversion to the cloud system 600 used by the organization X.
(S75) The signature conversion unit 143 sets the pointer information 835b corresponding to the ID of the document 830 before signature conversion to the document 830b after signature conversion. In addition, the document relationship management unit 144 stores in the storage unit 110 the document correspondence information 120 indicating the storage destination information of the document 830 on the cloud system 600 corresponding to the pointer information 835b.

( S<b>76 ) The signature conversion section 143 moves the document 830 b to the inter-organizational shared data storage section 150 .
(S77) The notification unit 135 notifies the user of organization Y that WF has arrived. The signature frame updating section 136 receives the approval path of the organization Y for the document 830b by the user of the organization Y, and converts the inter-organization signature frame 833b into the organization Y's intra-organization signature frames 853a and 854a. As a result, document 830b is updated to document 850a. Signature frame update unit 136 stores document 850 a in cloud system 700 . In step S77, the signature frame update unit 136 may generate a document containing a model of the approval route of the organization Y based on the document 830b, and the personal name conversion unit 132 generates a document 850a based on the document. may be Then, the WF management unit 133 starts the WF in the organization Y. FIG. When the approval of users C and D of organization Y and the addition of digital signatures to document 850a are complete, WF control ends.

FIG. 26 is a flow chart showing an example of signature verification in the fourth modification.
(S80) The verification processing unit 137 receives a personal name verification request for the signed document 850a of the organization X from the user of the organization Y. For example, a user of organization Y can operate the client device 400 to input the personal name verification request to the control server 100 .

(S81) The verification processing unit 137 refers to the document correspondence information 120 based on the ID indicated by the pointer information 855a recorded in the document 850a, and identifies the document 830 before signature conversion. Verification processing unit 137 accesses document 830 in cloud system 600 .

(S82) The verification processing unit 137 verifies the digital signature on the document 830 before signature conversion, that is, the digital signatures of users A and B of organization X, and acquires the approval history in organization X.

(S83) The verification processing unit 137 responds with the approval history of the entire document including the approval history of organization X and the approval history of organization Y. For example, in document 850a, digital signatures of user C and user D of organization Y may also be added. In this case, the verification processing unit 137 also verifies the digital signature of the user of the organization Y, acquires the approval history of the organization Y, and responds to the client device 400 with the approval history combined with the approval history of the organization X. For example, if the verification of the digital signature of any user fails, the verification processing unit 137 notifies the verification requesting user that the document 850a has been modified by an unauthorized user. Then the signature verification ends.

In this way, the control server 100 converts the signed signature frames 831 and 832 of the organization X unit and the digital signature of the user unit to the document 830 by adding the signed signature frame 831b of the organization X unit and the digital signature of the organization X unit, respectively. can be converted to In this case, the body of the document 830b does not include the personal name of the user who performed the approval in the organization X. Therefore, when the user of the organization Y views the body of the document 850a generated from the document 830b, the personal name of the user approved by the organization X can be made anonymous. Also, the control server 100 can appropriately verify the digital signature of the user who has given approval in the organization X by making it possible to identify the document 830 before signature conversion based on the pointer information 855a included in the document 850a.

Note that, in addition to the functions illustrated in FIG. 143 and the document relationship management unit 144 may be included.

As described above, the control server 100 executes, for example, the following processes.
When the control server 100 detects registration of a document to which an electronic signature corresponding to a user belonging to the first organization is attached and to which an electronic signature corresponding to a user belonging to the second organization is not attached, the control server 100 detects the registration of the document. Send a notification about the document to a predetermined registered user belonging to the organization No. 2. When the control server 100 receives the list including the users in charge belonging to the second organization in response to the notification, the control server 100 stores the list in the storage unit 110 . The control server 100 accepts verification requests from users belonging to the first organization. Then, the control server 100 uses the public key associated with the user in charge included in the list to obtain the electronic signature attached to the document at the time of responding to the verification request and the document as the recipient of the electronic signature. at least one of the information of the requested user belonging to the second organization, which is given to the . The control server 100 transmits, as a response to the verification request, the signature status of the document according to the verification result and evaluation information regarding at least one of the requested user.

As a result, in a WF across a plurality of organizations, when WFing of a document within the organization is performed through an approval route set by a certain organization, the control server 100 can perform document verification in response to a verification request from another organization. Enable verification of authenticity. Note that the organization X is an example of a first organization. Organization Y is an example of a second organization. Also, the mailing list 501 is an example of the above list. As illustrated in the second embodiment, the control server 100 may convert the mailing list 501 into the temporary ID list 117 and hold it.

In addition, the control server 100 acquires the information of the requested user of the electronic signature on the document in the second organization in response to the notification to the registered user belonging to the second organization, and transmits the information of the requested user to the document. set to

As a result, the control server 100 can suspend the setting of the approval path in the second organization, for example, at the time of starting the WF in the first organization. Therefore, the control server 100 can flexibly set approval paths for documents in the second organization.

In addition, the control server 100 stores the information of the requested user in the document as information of the signature frame to which the signature image of the requested user is added according to the approval of the requested user for the document, that is, information of the in-house signature frame. set.

As a result, the control server 100 can identify the next approval-requested user based on the signature frame information in the document, and can request approval from the next approval-requested user. The signature image may be a handwritten signature image of the relevant requested user, or may be an image of the seal stamp of the relevant requested user.

Also, when verifying information on the requested user, the control server 100 acquires the first public key corresponding to the information on the requested user included in the document. Then, the control server 100 determines whether or not the requested user in the document is valid, depending on whether or not the first public key is included in the public key associated with the user in charge included in the list. determine whether

As a result, the control server 100 can appropriately verify the legitimacy of the requested user based on the public key, which is open information disclosed to each user. The public key included in the WF verification information 116 is an example of a public key associated with the responsible users included in the list. The user's public key obtained based on the information of the internal signature frame in the document is an example of the first public key.

Also, the control server 100 detects that the document has been registered in the first cloud service used by the first organization when detecting registration of the document. Then, the control server 100 registers the document registered in the first cloud service with the second cloud service based on the access information for the second cloud service used by the second organization.

As a result, the control server 100 can flexibly deal with users who do not want to entrust their documents to the control server 100. Note that the cloud service provided by the cloud system 600 is an example of a first cloud service. Also, the cloud service provided by the cloud system 700 is an example of a second cloud service.

At this time, the control server 100 encrypts the document registered in the first cloud service using the common key corresponding to the second organization or the public key corresponding to the second organization, and converts the encrypted document to You may register with a second cloud service. Then, the control server 100 may decrypt the encrypted document registered in the second cloud service using the common key or the private key corresponding to the second organization.

As a result, even if the document is leaked to a third party when re-registering the document of the first cloud service to the second cloud service, the control server 100 can Unauthorized acquisition of the contents of the document can be prevented. The encryption may be performed using a common key cryptosystem or a public key cryptosystem.

For example, in the second embodiment, the information on the TaaS-related service provided to the organization X by the control server 100 and the information on the TaaS-related service provided to the organization Y may not be shared between the two services. I can think. In this case, the control server 100 uses public key cryptography to encrypt the document.

Further, when the control server 100 is notified from the first information processing device of the first organization that the document has been approved by the user of the first organization, the control server 100 adds the electronic signature of the user of the first organization. may be added to the document. Further, when the control server 100 is notified from the second information processing apparatus of the second organization that the document has been approved by the user of the second organization, the control server 100 adds the electronic signature of the user of the second organization. may be added to the document.

In this way, the control server 100 can add an electronic signature to a document in cooperation with the first information processing device and the second information processing device. As a result, the control server 100 can make effective use of the existing assets of each organization and facilitate the start of use of the functions of the control server 100 by each organization. The organization X server 300 is an example of a first information processing device. The organization Y server 500 is an example of a second information processing device.

Furthermore, before sending the notification to the registered users belonging to the second organization, the control server 100 assigns the electronic signature of the user belonging to the first organization attached to the document to the first organization. A document after signature conversion may be generated by converting the signature into an electronic signature. In this case, the control server 100 adds identification information indicating the document before signature conversion to the document after signature conversion. When the control server 100 receives a request to verify the electronic signature of a user belonging to the first organization for the document after signature conversion, the control server 100 acquires the document before signature conversion based on the identification information. Then, the control server 100 verifies the electronic signature of the user who belongs to the first organization, which is attached to the document before signature conversion.

As a result, the control server 100 can, for example, be verified by the user of the second organization that the document to be approved is the document approved by the first organization. Also, the control server 100 can remove the information of the users of the first organization from the documents referenced in the second organization. Further, the control server 100 can appropriately verify the electronic signature of the user of the first organization attached to the document before signature conversion by tracing the document before signature conversion from the document after signature conversion. Note that each of the documents 830b and 850a is an example of a document after signature conversion. A document 830 is an example of a document before signature conversion. Further, each of the

pointer information

835b and 855a is an example of identification information indicating the document before signature conversion, which is added to the document after signature conversion.

It can also be said that the control server 100 provides the following functions. The control server 100 predetermines the inter-organizational WF among the intra-organizational WFs indicating the signature order within the organization and the inter-organizational WFs indicating the inter-organizational data delivery order. It is possible to proceed with WF while dynamically deciding when signing with . At this time, the control server 100 makes it possible to verify the correctness of the intra-organizational WF determined by each organization based on the WF verification information indicating the user who can be set as the intra-organizational WF.

Also, the control server 100 may provide an area accessible by the control server 100 on the cloud service used by each organization. When moving data between cloud services of an organization, the control server 100 moves data directly between cloud services based on the cloud service access information held by the control server 100, thereby transferring data to the control server 100. You can choose not to save it.

The control server 100 may also manage pairs of encryption and decryption keys corresponding to each organization. When moving data between cloud services of organizations, the control server 100 encrypts the data with an encryption key corresponding to the next organization set in the inter-organization WF so that only the next organization can decrypt the data. You can move the data with As a result, the security of the data to be moved can be enhanced.

Further, the information processing of the first embodiment can be realized by causing the processing unit 12 to execute a program. Information processing according to the second embodiment can be realized by causing the CPU 101 to execute a program. The program can be recorded on a computer-readable recording medium 73 .

For example, the program can be distributed by distributing the recording medium 73 on which the program is recorded. Alternatively, the program may be stored in another computer and distributed via a network. The computer, for example, stores (installs) a program recorded on the recording medium 73 or a program received from another computer in a storage device such as the RAM 102 or HDD 103, reads the program from the storage device, and executes it. good.

The above merely shows the principle of the present invention. Furthermore, many variations and modifications will occur to those skilled in the art, and the present invention is not limited to the precise construction and applications shown and described above, and all corresponding variations and equivalents are and the equivalents thereof.

10 information processing device 11 storage unit 12 processing unit 20 document 21 management information 30 list 40 network 50

first organization

51, 52, 61, 62 client device 60 second organization

Claims

the computer
Upon detection of registration of a document to which an electronic signature corresponding to a user belonging to a first organization is attached and to which an electronic signature corresponding to a user belonging to a second organization is not attached, is detected, the second organization send a notification regarding said document to a predetermined registered user to which it belongs;
when receiving a list including the users in charge belonging to the second organization in response to the notification, storing the list in a storage unit;
When a verification request from a user belonging to the first organization is received, the public key associated with the user in charge included in the list is used and attached to the document at the time of responding to the verification request. verifying at least one of an electronic signature and information of a requestee user belonging to the second organization, which is attached to the document as a requestee for the electronic signature;
Sending, as a response to the verification request, the signature status of the document according to the verification result and evaluation information regarding at least one of the requested user;
Method of verification.
Acquiring information of the requested user in the second organization for the document in response to the notification, and setting the information of the requested user in the document;
The verification method according to claim 1.
setting the information of the requested user in the document as information of a signature frame to which the signature image of the requested user is attached in accordance with the approval of the requested user for the document;
The verification method according to claim 2.
When verifying the information of the requested user, a first public key corresponding to the information of the requested user included in the document is acquired, and the first public key is provided to the user in charge included in the list. Determining whether the requested user is valid according to the determination of whether or not it is included in the associated public key;
The verification method according to claim 1.
Detecting registration of the document includes detecting that the document has been registered in a first cloud service used by the first organization, and obtaining access information for a second cloud service used by the second organization. Registering the document registered in the first cloud service in the second cloud service based on
The verification method according to claim 1.
encrypting the document registered in the first cloud service using a common key corresponding to the second organization or a public key corresponding to the second organization; Register for cloud services
decrypting the encrypted document registered in the second cloud service using the common key or a private key corresponding to the second organization;
The verification method according to claim 5.
adding an electronic signature of the user of the second organization to the document when the information processing device of the second organization notifies that the document has been approved by the user of the second organization; ,
The verification method according to claim 1.
Before transmitting the notification, signature conversion is performed to convert the electronic signature of the user belonging to the first organization attached to the document into an electronic signature corresponding to the first organization. generating the document after signature conversion, adding identification information indicating the document before signature conversion to the document after signature conversion,
receiving the verification request of the electronic signature of the user belonging to the first organization for the document after signature conversion, obtaining the document before signature conversion based on the identification information, and acquiring the document before signature conversion based on the identification information; verifying the electronic signature of a user belonging to the first organization, attached to
The verification method according to claim 1.
to the computer,
Upon detection of registration of a document to which an electronic signature corresponding to a user belonging to a first organization is attached and to which an electronic signature corresponding to a user belonging to a second organization is not attached, is detected, the second organization send a notification regarding said document to a predetermined registered user to which it belongs;
when receiving a list including the users in charge belonging to the second organization in response to the notification, storing the list in a storage unit;
When a verification request from a user belonging to the first organization is received, the public key associated with the user in charge included in the list is used and attached to the document at the time of responding to the verification request. verifying at least one of an electronic signature and information of a requestee user belonging to the second organization, which is attached to the document as a requestee for the electronic signature;
Sending, as a response to the verification request, the signature status of the document according to the verification result and evaluation information regarding at least one of the requested user;
Validation program that runs the process.
a storage unit that stores a list of users who are permitted to request electronic signatures for documents;
When the registration of the document to which the electronic signature corresponding to the user belonging to the first organization is attached and to which the electronic signature corresponding to the user belonging to the second organization is not attached is detected, the second organization sending a notification regarding the document to a predetermined registered user belonging to the second organization, and receiving the list including the user in charge belonging to the second organization in response to the notification, storing the list in the storage unit; When a verification request from a user belonging to the first organization is received, the public key associated with the user in charge included in the list is used and attached to the document at the time of responding to the verification request. verifying at least one of an electronic signature and information of a requested user belonging to the second organization attached to the document as a destination of the electronic signature, and transferring the document according to the result of the verification; and a processing unit that transmits, as a response to the verification request, the signature status of and evaluation information regarding at least one of the requested user;
Information processing device having