JP2013192125A - Electronic signature system and method for electronic signature and postscript - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable a postscript to a document and a signature onto a document including a postscript even if the document bears a signature, without invalidating the signature, and to facilitate management of documents to be signed, whereby various types of documents can be treated.SOLUTION: A signature system comprises a client terminal 121a and a signature server 101 connected to the client terminal 121a via a network. In response to a request to set conditions for signature and a postscript from a client terminal 101a, the signature server 101 implements the setting, thereby creating a postscript file and defining a relation between an original document and the postscript file, and issuing a notification on the signature and the postscript to the client terminal 101a. On receiving the notification from the signature server 101, the client terminal 101a returns a response related to the signature and the postscript, and user information. On the basis of a response result from the client terminal 101a, the signature server 101 determines if the signature and postscript are authorized or not, determines the validity of the signature, confirms the content of the postscript in accordance with the user information, and implements the postscript and the signature to the original document.

Description

  The present invention relates to a signature system including a computer that performs an electronic signature, and more particularly to a technique for adding and signing a signed data (document or the like) to a document while utilizing the original signature.

  In recent years, computerization of paper has been progressing in various fields. As a technique for guaranteeing the validity of an electronic document, there is an electronic signature technique. By using the electronic signature, it is possible to confirm whether the document has been tampered with, who has signed it, or the like. If changes are made to the electronically signed document, such as appending, the document is considered to have been tampered with after the signature, and the signature becomes invalid. On the other hand, a changeable signature scheme in which an additional function is added to an electronic signature has been proposed.

  There are Patent Literature 1 and Patent Literature 2 as conventional techniques related to a changeable signature. According to these known technologies, for example, a user can add a new content to a signed document without invalidating the signature of the document and sign the document.

  Another conventional technique other than the above is a portable document format (PDF) incremental update technique (Non-Patent Document 1). In this known technique, change information and a new character string indicating the end of the file are added after the character string indicating the end of the file (%% EOF) in the PDF file. Since the original document data is held as it is, even a signed PDF file can be added or signed without invalidating the signature.

JP 2009-284138 A JP 2002-40935 JP

"Introduction to PDF electronic signature", [online], Antenna House, Inc., [October 18, 2011 search], Internet <URL: http://www.antenna.co.jp/PDF/reference/PDFSingature. html>

  In a method of signing a part of a file as a signature target as in the above-described prior art, identification of the signature target is complicated. For example, it is necessary to ascertain and specify where in the document and how far the data is to be signed, which complicates the signature creation / verification process. In addition, it is necessary to manage difference data indicating what changes have been made from the original document, which is complicated. For example, when further changes are made to the difference data itself, the processing becomes hierarchical and complicated, such as specifying the change position for the difference data instead of the original document. There is also a problem that the number of difference data to be managed becomes enormous. As another problem, depending on the type of document, there is a document that cannot sign a part of the file. For example, an OpenXML type document or the like is a compound type document that looks like a single file to the user but actually holds a plurality of files therein. In the case of such a document, the signature can be performed only in units of files constituting the document. If a method for signing a part of a file is used, there is a possibility that another application handling the document cannot open the document. For this reason, it is not possible to apply a method for signing a part of a file as in the above-mentioned known technique. The technology of Non-Patent Document 1 can be applied to PDF files, but cannot be applied to other types of files. In addition, it is necessary to manage the version of the document for each incremental update, and the position of the partial information in the file is the subject of the signature (for example, the first to fifth lines of the document are the same as in the known technique). There is a problem that the signature processing becomes complicated because it is necessary to grasp the signature target). Also, in the above-mentioned known technique, in the case of a method of managing the original document and the difference data separately, the correlation information (which difference data is related to which original document) is strictly related. If it is not defined, there is a possibility that the association between the original document and the difference data is illegally changed or a part of the difference data is illegally removed.

  Based on the above, the present invention enables the additional writing and signature to the additional data without invalidating the signature on the signed document, and can be applied to various files. An object is to provide an easy appendable signature method.

  In order to achieve the above object, according to the present invention, information for adding a subsequent signer is generated in a previously performed signature. This information includes a file for additional writing, a definition indicating the relationship between the original data and data to be added (or a file for additional writing), and additional writing conditions. Here, a so-called empty file may be used as the additional recording file.

  Hereinafter, a more detailed representative example of the present invention will be described as follows. That is, a signature system comprising a computer and a computer connected to the computer via a network and having a signature function, wherein the computer having the signature function sends a request for setting conditions for signature and additional writing from the computer. In response, the signature and appending conditions are set, the appending file is created, the relation between the original document and the appending file is defined, and the signature and appending are added to the computer related to the signature and appending conditions. The related computer receives a notification from the computer having the signature function, and responds to the signature, additional writing, and user information. The computer having the signature function performs the signature and additional writing based on the response result. Judging whether or not the user has authority, determining the validity of the signature, confirming the content to be added according to the user information, adding to the original document and implementing the signature Signature system which is characterized.

  According to the present invention, in a plurality of signatures, it is possible to sign data including additional writing and additional writing while making use of the previous signature.

It is a block diagram which shows the hardware and software structure of the signature system of a 1st Example. It is explanatory drawing which shows an example of the authentication information 112 of a 1st Example. It is explanatory drawing which shows an example of the signature condition information 113 of a 1st Example. It is explanatory drawing which shows an example of the postscript condition information 114 of the 1st Example and the 2nd Example. It is explanatory drawing which shows an example of the postscript type information 114 of a 1st Example. It is explanatory drawing which shows a transition of the document information of a 1st Example, and an example of a relation file. It is a flowchart which shows an example of the process about the signature and additional writing which the signature server 101 of a 1st Example performs. It is explanatory drawing which shows an example of the memory information 112 of the modification of a 1st Example. It is a flowchart which shows an example of the process about the signature and additional writing which the client terminal 121 of the modification of 1st Example performs. It is explanatory drawing which shows an example of the process of the sanitization signature which the signature server 101 of a 2nd Example performs. It is explanatory drawing which shows an example of the sanitization signature to the document of a 2nd Example.

  Embodiments of the present invention will be described below. The embodiment described below is an example, and the present invention is not limited to this.

A first embodiment will be described with reference to FIGS.
FIG. 1 is a block diagram showing a hardware and software configuration of the signature system according to the first embodiment of this invention. The signature system includes one or more signature servers 101, one or more external servers 141, and one or more client terminals 121a and 121b (hereinafter collectively referred to as client terminals 121). The external server is a time stamp server, an OCSP responder for checking certificate revocation, or the like, and may be configured without these.

  The signature server 101 and the client terminal 121 are connected to the network via the I / Fs 104 and 123, respectively. The signature server 101 receives an operation request and gives an operation instruction to an external device such as the client terminal 121 via the I / F 104.

  The signature server 101 includes a CPU 103, a memory 102, and an I / F 104. The CPU 103 receives an operation request from an external device such as the client terminal 121 through the I / F 104, executes the operation, transmits a notification about a signature or additional writing, and transmits an operation result to the external device. The memory 102 includes a user cooperation unit 105, a signature creation unit 106, a signature verification unit 107, a signature, an additional write condition management unit 108, an additional write management unit 109, authentication information 110, signature condition information 111, additional write condition information 112, additional write type information 113, The document information 114 is connected to the CPU 103 and the I / F 104.

  The client terminal 121 includes a CPU 124, a memory 122, and an I / F 123. The CPU 124 receives an operation request to the signature server 101 and the like, an operation instruction and an operation result from the signature server 101 and the like via the I / F 123. The memory 122 includes a server cooperation unit 125, a user cooperation unit 126, and authentication information 127, and is connected to the CPU 124 and the I / F 123. That is, each unit described above is configured as a program, and a CPU included in each device executes processing to be described later according to the program expanded in the memory.

Next, details of the software configuration of the signature system of the present embodiment (information stored in the memory 102 and the memory 122) will be described.
First, information other than the program stored in the memory 102 (information 110 to 114) will be described, and then program information stored in the memory 102 (information 105 to 109) will be described.

  The authentication information 110 is information used to authenticate a user who makes an operation request to the signature server 101. FIG. 2 is an explanatory diagram illustrating an example of the authentication information 110 according to the first embodiment of this invention. The authentication information 110 includes four data items, items 201, 202, 203, and 204. An item 201 indicates a user ID for uniquely identifying a user. An item 202 indicates a user password. An item 203 shows information on the user's mail address. An item 204 indicates information on the organization to which the user belongs. The affiliated organization is, for example, a company name or department information within the company. In addition, although the organization is an affiliated organization here, it may be any management unit (organization) of some kind of signature. For example, in FIG. 2, userA indicates that it belongs to pharmaceutical A. In addition, in the signature and additional write condition setting described later, as a user who permits the signature and additional write, the designation in the organizational unit other than the designation in the user unit, that is, the execution of the signature or additional write to an arbitrary user belonging to a certain organization You may use this information for permission. In addition, the authentication information may include information other than the above, for example, user certificate information, or information related to an operation authority for setting a signature or additional writing condition described later.

  The signature condition information 111 indicates a signature condition, and is information including, for example, a signable person. This information may be set by a signer (for example, the first signer) ahead or by a user other than the signer. FIG. 3 is an explanatory diagram illustrating an example of the signature condition information 111 according to the first embodiment of this invention. The signature condition information 111 includes seven data items, items 301, 302, 303, 304, 305, 306, and 307. An item 301 indicates an identification number for identifying each signature condition. An item 302 indicates information of an original document to be added or signed under each signature condition. Each signer sequentially adds and signs the original document 302. An item 303 indicates the progress of the signature. For example, in FIG. 3, when the signature condition ID 301 is “10”, the item 303 is “1/2”. This indicates that a total of two signatures are scheduled for the document specified in item 302, but the first signature is currently scheduled to be implemented in the future. When the first signature is performed, the item 303 is “2/2”, that is, the second signature is to be implemented thereafter. An item 304 is information indicating a signer who can execute a signature. With this information, it becomes possible to sign only the designated signer. In addition, instead of designating a signer in advance, it may be set such that a signature from an arbitrary user can be made. Item 305 is information indicating the order of signatures. For example, in the example of FIG. 3, the signing order of the signer A is “1” and the signing order of the signer B is “2”. This indicates that the signer B cannot sign until the signer A first signs it. Although the signing order of each signer can be set by this information, the signing order may not be set, that is, the setting may be made so that the signing can be performed in an arbitrary order. For example, the same value may be set in the item 305 so that the signature order is not controlled. An item 306 indicates a signature number for identifying a signature performed by each signer. For example, the signature made by the signer A in FIG. 3 is identified as the signature number “1”. This information is common to the signature number 402 of the postscript condition information 112, which will be described later, and links who signs each piece of postscript information. An item 307 indicates whether each signature has been executed or not. Since the signature condition information 111 is held by the server, it is possible to prevent falsification of information by appropriate access control, but a signature may be added to this information to make it more secure. Further, the signature condition information 111 may include information of a signature condition creator indicating who created the signature condition of each signature condition ID.

  The additional recording condition information 112 is information indicating additional recording conditions (for example, who is permitted what additional recording). FIG. 4 is an explanatory diagram showing an example of the additional write condition information 112 according to the first embodiment of this invention. The additional write condition information 112 includes six data items 401, 402, 403, 404, 405, and 406. An item 401 is an ID for identifying each signature condition, and is the same as the item 301. The item 402 is additional write type information indicating what additional writing is permitted for the original document 302. This item is specified with reference to an item 501 of the postscript type information 113 described later. For example, the write-once type in which the item 402 is “1” in FIG. 4 corresponds to the write-once type in which the item 501 is “1”. An item 403 indicates information on a user who is permitted to add information. In addition to permitting only one user to add, for example, as shown in FIG. 4, “arbitrary” may be set to permit arbitrary users. An item 404 indicates a file for storing additional data. The file may be specified by an absolute path, a relative path, or the like, or may be specified by a file identifier (for example, “rId1” in FIG. 4) defined by a relation file 601 described later. A plurality of additional files may be assigned to the additional person. An item 405 indicates a temporary file for storing additional data. The additional data from the user is temporarily held in a temporary file, and when all the additional writing is completed, the data is stored in the additional file of the item 404. For example, if it becomes necessary to modify the postscript after signing the postscript, the signed postscript itself cannot be changed, but this temporary file makes it easy to redo the postscript and postscript. Become. However, such a temporary file may not be provided, and a method of directly storing additional data from the user in the additional file 404 may be adopted. An item 406 indicates a signature number for identifying which signature number 306 the additional data of the item 404 is signed by. For example, in FIG. 4, under the signature condition with the signature condition ID “10”, the additional writing types “1” and “2” can be added, and the additional writing with the additional writing type “2” can be performed by the user B. The additional data is temporarily stored in “r / tmp / temp2.docx” and finally stored in “r / test / 2.dat”, and the signature number is “2” (signer from FIG. 3). B signature). However, it is not always necessary to sign the additional writing data, and only the additional writing may be performed.

The additional writing type information 113 is information indicating the type of additional writing (for example, additional writing of only a character string or arbitrary additional writing). FIG. 5 is an explanatory diagram showing an example of the write-once type information 113 according to the first embodiment of this invention. The postscript type information 113 includes five data items 501, 502, 503, 504, and 505. An item 501 indicates a number for identifying the write-once type. The item 402 of the additional write condition information 112 is designated using this number. An item 502 indicates the content of the write-once type. For example, “character string” means that additional writing of only a character string is possible, and “arbitrary” means that arbitrary additional writing is possible. In FIG. 5, “Format A” means that additional writing is permitted according to a format created in advance by the user (for example, a comment field, an image field, etc. are defined). In addition to the above, the write-once type may be registered and used later by the user. An item 503 is information indicating the type of a file that stores additional data. The item 504 is information indicating the type of file that temporarily holds additional data. In FIG. 5, types such as “.txt, .dat, .xlsx” are used, but these are examples and other types may be used. An item 505 indicates remark information regarding the write-once type. For example, in FIG. 5, the additional writing with the additional writing type “4” indicates additional writing according to the format represented by the file shown in the item 505.
The document information 116 is information on a document to be signed. A signature condition setter, a signer, a writer, and the like register the document by uploading the document to the signature server 101. Information such as a signed document or a document in the middle of signature may be held.

  Next, program information stored in the memory 102 will be described. The user cooperation unit 105 authenticates a user who makes an operation request to the signature server 101 based on the authentication information 110, and executes processing such as permitting or prohibiting execution of the operation requested by the user. The signature creation unit 106 signs a document. As the signature processing, for example, a hash value of a document is generated, the hash value is encrypted with the signer's private key, and the encrypted value is added to the document as a signature value. Note that the hash value of the document is sent to the client terminal used by the signer, the signature value is created on the signer side based on the hash value, and the signature value is received from the signer and added to the document by the signature server. A process other than the above may be used. The signature creation unit 106 acquires time stamps, OCSP responses, and the like in cooperation with the external server 141 as necessary. Further, the signature creation unit 106 determines whether the user who makes the signature request has the authority to create a signature based on the signature condition information 111 and whether the signature to be created matches the conditions in terms of order. . The signature verification unit 107 verifies whether or not the signature made on the document is proper. Specifically, it is verified whether the signature value and the signature order are correct. The signature / additional write condition management unit 108 creates, changes, deletes the signature condition information 111 and the additional write condition information 112 based on a request from a condition setter or the like regarding the signature or additional writing. The signature server 101 may notify a related user of a request for signature or additional writing after the setting of conditions for the signature or additional writing is completed, or may request a signature or additional writing from the user at any time without performing such notification. You may make it accept. The appending management unit 109 creates an appending file based on the appending condition information 112, stores user appending data in the appending file, defines the correlation between the original document and the appending file, and appends to the user who makes the appending request. Determine if you have authority. Also, management such as registration and deletion of the write-once type information 113 is performed.

  Next, information stored in the memory 122 will be described. The server cooperation unit 125 cooperates with an external server such as the signature server 101, transmits an operation request (such as a signature creation or additional request) from the user to the external server, and receives a response result from the external server. The user cooperation unit 126 authenticates a user who makes an operation request to the client terminal based on the authentication information 127, and performs processing such as permission or prohibition of an operation requested by the user, display of an operation result, and the like. The authentication information 127 is information for authenticating a user who makes an operation request to the client terminal, and includes information such as an ID and a password of each user.

  The above is the hardware and software configuration of the signature system in the present embodiment. Next, based on the hardware and software configuration described above, details of a series of processes from setting of signature and additional writing conditions to implementation of the signature and additional writing in the present embodiment will be described.

<Signature / addition condition setting, signature / addition processing>
FIG. 7 is a flowchart showing an example of processing for setting conditions for signatures and additional writing, and for implementing signatures and additional recordings, which are executed by the signature server 101 according to the first embodiment of this invention. Although not described below, it is assumed that the signature server 101 accepts an operation request only from a user who is authorized based on the authentication information 110.

  The user cooperation unit 105 receives a signature condition / additional condition setting request from the user (701). Specifically, setting information such as who is signed in which order for which document and what additional writing is permitted for the document is received. In this setting request, the user cooperation unit 105 may select and specify a document, a signer, a signature order, an appending type information, and the like, for example, by displaying a setting screen. Upon receiving the request, the signature / additional condition management unit 108 updates the signature condition / additional condition setting file in accordance with the request contents (702). Specifically, for example, in FIG. 3, a new signature condition ID is created and registered in the item 301, and the new signature condition ID (document, signer, signature order, etc.) is received based on the setting information (document, signer, signature order, etc.) received from the user. Values are set in the items 302, 304, and 305 in the signature condition ID. Item 303 is automatically set based on the number of signers of the setting information (the number of signatures attached to the document). For example, if the number of signers is two, it is “1/2”, and if it is three, it is “1/3”. In the item 306, a value capable of uniquely identifying a signature attached to a document is automatically set. In addition, regarding the setting of the postscript condition, specifically, for example, in FIG. 4, the created new signature condition ID is registered in the item 401, and the setting information regarding the postscript received from the user (the postscript type, the postscriptor, each postscript, and the like) Value is set in the items 402, 403, and 406 in the new signature condition ID. Items 404 and 405 are automatically set in step 704, which will be described later, based on the value of the write-once type specified in the setting request. After the above setting, the user cooperation unit 105 receives a signature execution request from the user (703). Here, since it is assumed that a user who has set a condition for signing or appending has signed the original document and thereafter requires the user specified in the condition setting to sign or append, this processing and did. However, as another processing method, for example, the condition setter may set conditions for signature and additional writing, omit the signature, and thereafter, each user may perform signature and additional writing according to this condition setting. In that case, the signature processing in this step may not be performed. Next, in response to the request, the additional recording management unit 109 creates an additional recording file that stores additional recording data based on the setting information updated in step 702. Specifically, for example, in FIG. 4, in the case of the postscript condition in which the postscript type “1” is set, files of the “.dat” type and “.txt” type are created based on the postscript type information 113 of FIG. The path information is created and set in the items 404 and 405, respectively. A file name that can be uniquely identified is automatically set. If the original document to be appended or signed is a compound document that contains multiple files, the append file for item 404 may be created inside the compound document. The compound document itself may be set as the root directory, and the path information therefrom may be set in the item 404. Alternatively, an identifier value defined in a relation file 601 described later may be set. Next, the additional record management unit 109 determines the signature and additional write condition information of the original document to be added or added from FIG. 4 and FIG. 5 and the like, and is specified from the original document according to the additional write condition information. A link is made to the postscript file 404. Linking is, for example, embedding an identifier indicating that there is a correlation (reference, data reading in the original document, etc.) in the original document. Whether or not a link can be established may be determined based on information such as a file extension. For a document that cannot be linked, a correlation is defined in the relation file 601 shown in FIG. The above process will be described with reference to FIG. FIG. 6A is a diagram showing an outline of an original document before additional writing or signature. The document includes a relation file 601 and a main file group 602 of the document including a file including text information of the document and a file including various property information such as fonts. However, a single file may be used instead of a file group.

  The relation file 601 is information that defines path information from a route (document) to each file in the document, a relationship between files in the document, and the like. The relation file is, for example, as shown in FIG. 6C, and includes path information of each file and Id (for example, rId1) for identifying the file. Note that the number of relation files is not limited to one, and one document may have a plurality of relation files, for example, a relation file is further defined in a main file group in the document. The relation information may be held on the server side. FIG. 6B shows a state in which an additional file group 603 including one or more additional files is generated in the document by the processing up to this step. At this time, the correlation between the additional file and the main file of the document is embedded in the main file of the document, or the correlation between the main file and the additional file is embedded in the relation file. By defining the correlation as described above, it is guaranteed that a certain postscript file is actually a postscript to a certain document, and that a certain postscript file has not been illegally created by the person who set the conditions for signature or postscript. it can. After the above-described additional file creation and various information updates, the signature creation unit 106 implements the user's signature (704). At this time, the object to be signed is the portion excluding the additional file group (that is, the main file group of the document and the relation file. The additional file group is not subject to the signature because the signature is added before the additional writing is performed. If this happens, the signature will be falsified and it will not be possible to add a note.In addition, when signing, the above link may be provided to display the document once to the condition setter. In addition, the signature target is not signed with the condition setter's private key, but a private key unique to the signing server may be provided and signed with this key. The setter only needs to set the conditions for signing and appending, and does not have to hold the private key for the signature, and the processing of this step for the items 404 and 405 may be performed in step 702. In this case, there is a possibility that the correlation information between the original document and the additional file and the additional file may be falsified before the signature processing in this step is performed. Next, the signature server 101 waits for an operation request from the next user regarding the above-mentioned signature condition (705) Note that the signature server does not simply wait for an operation request as another process. Requests for signatures and additions to users related to the above-mentioned signature conditions, for example, user A and user B (users of items 304 and 403) when the signature condition ID in FIG. 4 or 5 is “10” The signature server 101 accepts an operation request from the next user (706), the signature server 101 determines whether the operation request is a signature request (707), and if it is a signature request, The next user is authorized to execute the signature Determines whether (708). Specifically, if the next user in the field 304 the signature condition ID of the signature request is registered, or signature to determine the like or allowed to any user.

  If the next user has a signature authority, the signature server 101 further determines whether the signature order is valid (709), and if the signature order is correct, the signature server 101 executes the signature (710). Specifically, in FIG. 3, the item 305 confirms whether there is a signature before the signature order of the next user. If there is a signature, the signature status 307 is confirmed. If there is a “not yet” one, it is determined that the signature order is not correct and the signature is not executed. If the above does not apply, the signature is implemented and the process proceeds to step 711. In this signature, the additional file 404 corresponding to the signature number 306 of the signature of the next user in the signature condition ID is to be signed. For example, in FIG. 3, when the signature condition ID is “10” and the signer is “B”, the signature number is “2” and the additional file 404 “r / test / 2.dat” corresponding to the signature number is the signature target. It becomes. However, a process other than those described above, for example, including the original document 302 or the signature result of another user in the signature target may also be used. If there is no execution authority in step 708 or if the signature order is not valid in step 709, the process proceeds to step 711. If the operation request is not a signature request in step 707, the signature server 101 determines whether or not the operation request is a write-once request (713). If the operation request is a write-once request, whether or not the next user has the authority to execute the write-once. (708). Specifically, the determination is made based on whether the next user is registered in the item 403 of the signature condition ID of the append request or whether any user is permitted to append. If the next user has the additional writing authority, the signature server 101 further determines whether the additional writing target is an unsigned area (716), and if it is not signed, accepts the additional writing from the next user (717). Specifically, the signature number 406 corresponding to the additional writing (item 404) that the next user intends to perform in the signature condition ID requested for additional writing is determined, and the signature status in the signature number 406 is determined based on FIG. Check 307. If the signature status is "Done", the part to be added in the request is judged as already signed and is not added, and if the signature status is "Not", it is judged as unsigned and the addition is accepted. . In accepting the postscript at step 717, the process may be performed according to the postscript type 402 permitted to the next user. For example, if the type is “1” and character string addition is permitted, a screen prompting the user to enter the character string may be presented to the user and accepted. A screen may be presented and accepted, or if it is arbitrary additional writing, the user may be notified that arbitrary additional writing is possible, and for example, an arbitrary file describing additional content may be received from the user. After accepting the appending from the next user, the appending management unit 109 of the signature server 101 performs appending to the document (718). Specifically, for example, when the signature condition ID of FIG. 3 is “10” and the appender is “B”, a file (for example, temp2.docx in item 405) describing the content of the append is received from the appender. , Convert it to the file specified in item 404. By replacing the file with the additional recording file of the item 404 created in step 704, additional recording data is inserted. For the conversion, conversion such as binary conversion is performed if necessary. In addition, when replacing a file, the file name of the item 404 is not changed and the contents are replaced. This is because the file of the item 404 is defined in the relation file 601, and if the relation file 601 is signed, changing the file name results in falsification of the signature. By the above processing, for example, the added content is displayed in addition to the original document. Also, it can be viewed as a single file from the user. The above is an example, but other file types are acceptable. Further, as a processing method other than the above, for example, a file for additional writing may be opened on the server, arbitrary writing may be received from the user, and the file may be used as additional data for the original document.

  Further, the signature server 101 may determine and process the signature or additional target to be performed by the next user based on the information in the item 303, or present each file content of the item 404 to the user. You may make it select and process each user from among them. In step 713, if the requested operation is not an additional write request, the signature server 101 performs other operations requested by the next user, and proceeds to step 711. If there is no additional writing authority in step 715, or if it is not an unsigned area in step 716, the process proceeds to step 711. Next, the signature server 101 determines whether there is another operation request from the next user (711). If there is a request, the process proceeds to step 707. If not, the signature server 101 determines whether the signature in this signature condition has been completed (step 707). 712). More specifically, the determination is made by looking at the progress 303 and the signature status 307 in the signature condition ID. If all signatures have not been completed, the process proceeds to step 705. If each signature has been completed, the process ends.

  The signature server 101 may notify a related user or the like that each signature has been completed. In addition, a user group corresponding to each signature condition ID is defined in advance, and even if it is a setting that allows any user to sign or add information, a restriction is set to allow any user within this user group. It may be possible (for example, limited to users in the organization 204). Further, in the above process, the order control is not performed for the additional writing, but the order control may be performed as in the case of the signature. In addition to the end of the document, the postscript location may be added to a location in the middle of the document. This can be realized, for example, by linking a postscript file from a location in the middle of the document in step 704. Although the signature is added to the document in the above, the created signature may be stored separately from the document. Also, at the time of signing, the information may be acquired and added to a document in cooperation with an external server (such as an OCSP responder or a time stamp server). Further, the signature server 101 determines what additional data is included in the signed document based on the information in FIGS. 3 and 4, and each additional file is based on the information in the items 404 and 403. The contents of the document and the creator information may be presented to the user so that it is possible to determine which part of the signed document is postscript data. In the above, the signature server 101 creates the correlation information and the append file of the original document and the append file. For example, the user creates such an information and append file in advance. After sending to the signature server 101, the signature server 101 may perform additional writing and signature processing based on the received information. For example, if the original document to be appended or signed is a compound document that contains multiple files, the signature server 101 analyzes the compound document received from the user and adds the append file Alternatively, the correlation information may be discriminated and used for subsequent appending or signature processing. The determination as to whether the file is an additional file may be made, for example, depending on whether the file is an empty file. Further, the above is a method in which the order of appending and signing a document is given a certain degree of freedom, that is, for example, even if a user is working (editing appending before signing), the appending authority is granted. If there is another user, it is possible for another user to cooperate with the postscript (correction of the postscript being edited, etc.). It is possible for multiple people to cooperate and add or sign. On the other hand, the order of signature and additional writing may be strictly defined in the workflow format so that the process of the next user can be proceeded only after the process of a certain user is completed.

  The above is the description of the signature and additional write condition setting and the signature and additional write execution processing of the first embodiment. Next, a modification of the first embodiment of the present invention will be described. In the first embodiment, the signature server 101 performs processing such as signature and additional writing, but the present modification is different in that each client terminal 121 performs these processing.

  Unlike the contents of FIG. 1, the memory 122 of the client terminal includes the elements shown in FIG. Instead of the item 125, new items 801 to 806 are added. A part of the information stored in the memory 102 of the signature server is also stored in the memory 122 of the client terminal, but there are portions where the contents of each information are different. Similar to the signature creation unit 106, the signature creation unit 801 signs a document. Similar to the signature verification unit 107, the signature verification unit 802 verifies whether the signature made on the document is appropriate. The signature / additional write condition management unit 803 creates, changes, deletes, etc., information related to the signature condition and additional write conditions (information similar to FIG. 3 and FIG. 4) based on a request from a condition setter and the like regarding the signature and additional write. Unlike the first embodiment, the information on the signature condition and the additional writing condition is entered in the original document. For example, in FIG. 6A, the information is arranged as a file different from the items 601 and 602 in the document 302. Or may be kept separate from the original document and sent to the next signer along with the original document. In addition, when the information of the signature condition and the additional writing condition is inserted in the original document, the information of the signature condition ID 301, 401 and the original document 302 is uniquely determined in each document. Also good. However, when setting multiple different signature conditions for the same original document, or when requesting users to add or sign multiple documents at once, the signature conditions of each document can be identified. Therefore, the signature condition ID and the original document information may be held. In the first embodiment, the signature condition information 111 is held by the signature server 101, and the values of the items 303 and 307 are updated every time there is a signature of each user. Also in this modification, the information regarding the signature condition may have the same content as the signature condition information 111. In this case, it is necessary to update the values of the items 303 and 307 every time the client terminal signs. In addition, in order to improve the reliability of the information related to the signature condition created on the client terminal, it is conceivable to add the signature to the information. In this case, even if the information on the items 303 and 307 is included in the signature condition information, The two pieces of information cannot be updated (the signature invalidates when updated). Therefore, when a signature is added to the signature condition information, the information in the items 303 and 307 may be managed separately from the signature condition information.

  Alternatively, the information of the items 303 and 307 is eliminated, and the signature status is determined by identifying who the signature is from the signature attached to the document and what is the signature target (for example, which additional file is the signature target). The signature number 406 (306) of the signature may be discriminated based on the information, etc., and the signed signature number 406 (306) may be determined. In addition, regarding the information regarding the postscript condition, in the first embodiment, the temporary append file specified first in the item 405 is created in a lump. However, in this modification, each user is added each time the order of the postscript or signature is turned. Create the temporary append file. However, the present invention is not limited to this, and the same method as in the first embodiment may be used. Note that the additional write temporary file does not need to be created or held in the original document, and may be deleted when the signature or additional writing is completed. In the case where a postscript is created by cooperation of a plurality of people, a temporary postscript file created by itself may be taken and handed over to the next user. The postscript management unit 804 creates the postscript file, stores the user postscript data in the postscript file, and the correlation between the original document and the postscript file, based on the information on the above-mentioned postscript management conditions. It is determined whether the user who requests definition and additional writing has the authority of additional writing.

  It also manages the registration and deletion of the postscript type information 805. The additional recording type information 805 is information indicating the type of additional recording, similar to the additional recording type information 113. Document information 806 is information on a document to be signed in the client terminal. Information such as a signed document or a document in the middle of signature may be held.

  In the following, processing for setting conditions for signatures and additional writing, and implementation of signatures and additional writing in a modification of the first embodiment will be described. The process flow is the same as in the first embodiment. Below, only the part from which a process differs is demonstrated. In the first embodiment, the user cooperation unit 105 of the signature server 101 accepts an operation request from a user. However, in this modification, the user cooperation unit 126 of each client terminal 121 accepts an operation. In the first embodiment, since the document and additional data are held on the signature server 101 side, it is possible to prevent falsification of the document if appropriate access control is performed on the signature server side. On the other hand, in this modified example, since the document and additional data are exchanged between the client terminals 121, the possibility that the document is falsified during that time increases. Therefore, unlike the first embodiment, in this modification, when a signature or additional writing is performed on a document after setting the signature or additional recording conditions, whether the signature has already been made on the signature or additional target document. Confirmation and verification of whether the signature is invalid (whether the document has been tampered with). If the signature is not invalid, an operation (additional writing or signature) requested by the user is performed. Details of the process will be described with reference to FIG.

  Upon receiving a request from the user, the signature and additional write condition management unit 803 of the client terminal 121 sets information regarding the signature condition and the additional write condition in the same processing as in steps 701 to 704. Since there is a portion that is slightly different from the processing in the first embodiment, this portion will be mainly described.

  A person who sets the signature condition or additional recording condition designates a document to be signed from a file or the like in the client terminal using the signature and additional recording condition management unit 803. Then, it is set who will sign the document in what order, and who is allowed to add what. As a result, the same information as the signature condition information 111 and the additional recording condition information 112 (however, as described above, information such as the signature condition ID 301 and 401 is not necessary) is created and arranged in the original document. . In addition, as in the first embodiment, a unique additional recording type may be designated as the additional recording type information. In that case, the user sends the information of the postscript type defined uniquely together with the original document to the subsequent users (901). After the above condition setting is completed, the condition setter sends a document including the above condition information to the next user by e-mail or the like, and requests a signature or additional writing (902). The next user who has received the request confirms the received document and issues an operation request for signature or additional writing via the user cooperation unit 126 of his client terminal (903). Upon receiving the request, the signature verification unit 802 determines whether or not the received document has a signature, and if the signature is present, verifies whether the signature is valid (904). Whether or not there is a signature can be determined based on whether or not signature data is attached to the document. Specifically, the signature verification identifies the signer and the signature target from the signature data attached to the document, and if the hash value of the signature target matches the value obtained by decrypting the signature value with the signer's public key The signature is deemed valid. The public key of each signer is held together with the signature data. For example, if each additional file is to be signed, the signature with the signature condition ID “10” and the signature number “2” in FIG. 4 (signer 304 has the signature “B”) is added to the additional file “r / "test / 2.dat" is the subject of signature. Therefore, the validity is determined by whether or not the hash value of the file matches the value obtained by decrypting the signature value corresponding to the signature number with the public key of the signer. The above is verification of the validity of the signature value, but other processing such as verification of the validity of the certificate used for the signature may be performed. Next, the validity of the signature order is also verified. The signature verification unit 802 determines signature condition information included in the received document and verifies whether the signature made on the document matches the signature condition. In the first embodiment, since the signature order information is managed by the signature server 101, the validity verification is easy. In the case of this modification, each signer acquires time stamp information at the time of signing and adds it together with the signature data, so that the correctness of the order is verified later based on this time information. Alternatively, the signature of each user is not limited to each additional data or document, but the signature data itself performed by the user before itself is also the signature target, and in each user's signature data, The determination may be made based on whether or not the signature data of the previous user (the user whose signature order is earlier than the user itself) is also included as a signature target.

  As a result of the above signature verification, if the signature is valid, the signature verification unit 802 determines whether there is another signature in the received document (906), and if the signature is invalid, it is attached to the document. The next user is informed that the signed signature is invalid, and the process is terminated (908). The next user who is notified that the signature is invalid may notify the condition setter or the like to redo the signature or additional writing. If there is another signature in step 906, the process proceeds to step 905, and if there is no other signature, the process proceeds to step 707, and thereafter the user's signature and additional writing are performed in the same manner as in the first embodiment (907). . As the processing outline, it is determined whether the operation request of the next user received in step 903 is a signature, additional writing, or other processing. If it is a signature, the signature condition of the document is determined, and information on the signature condition is determined. Based on the above, it is determined whether there is an authority to sign or the order of the signature that the next user is trying to perform is valid, and in the case of additional writing, the additional writing conditions of the document are determined, and information on the additional writing conditions is obtained. It is determined whether the user has the authority to add information or whether the information is added to an unsigned area. If the result of the above determination is a valid request, the signature or additional writing is performed. In the first embodiment, the signature server 101 creates the temporary appending file 405 and accepts the appending from the user. However, in this modified example, the appending management unit 804 of each client terminal that performs appending has the appending type of the item 402 A temporary appending file is created along with, and appending from the user is accepted. Then, the file specified in the item 404 that was originally in the document is replaced with the additional write temporary file. At that time, the information such as the file name remains the file name specified in the original item 404 and is not changed. Note that the additional write temporary file may be deleted as soon as the above processing is completed.

After the above processing, if there is no other operation request from the next user, the process proceeds to step 712, where the signature creating unit 801 determines whether all the signatures have been completed under this signature condition. If not, the process proceeds to step 902.
The above is the description of the first embodiment of the present invention and its modifications.

  Next, a second embodiment of the present invention will be described. In the second embodiment, in addition to the signature function in the first embodiment, a additionally writable signature scheme in which each signer can make a sanitary signature that can conceal a part of the document is shown. This method can be used when it is desired to ensure that the contents other than the non-public part are valid (tampered) when a part of the signed document is made private. For example, when a document is exchanged between a medical institution and a pharmaceutical company, etc., the doctor in charge of the medical institution adds and signs the document, and then the person in charge of the medical institution personal privacy information that the person in charge wants to keep private This can be used when signing and sending to a pharmaceutical company. FIG. 11 shows an example of a sanitized signature. Document 1101 is the one before additional writing or sanitization signature, and document 1102 is a document in which a doctor in charge of a medical institution has signed and signed his / her name and patient's personal information regarding medical treatment. Document 1103 is a medical institution's responsible physician who has signed and signed the patient's personal information in document 1102. The system configuration of the second embodiment is the same as that of the first embodiment (see FIG. 1). For this reason, description of the system configuration is omitted. In the first embodiment, the additional write condition information 112 has the contents shown in FIG. 4A, but the second embodiment is different in that it has the contents shown in FIG. 4B. As new additional condition items, an item 407 indicating whether or not each additional recording can be painted, an item 408 indicating a user who can perform additional recording, an item 409 indicating whether or not each additional recording is painted, An item 410 for storing the hash value of the data is added. Note that sanitization may be performed on portions other than the additional writing.

  Hereinafter, the description of the same processing as in the first embodiment among the processing in the second embodiment will be omitted. As in the first embodiment, there are two cases: a case where additional writing or a signature is performed on the signature server side, and a case where the above-described processing is performed on the client terminal side as modified examples. Details of signature and additional writing condition setting and signature and additional processing in the second embodiment will be described below.

<Signature / Addition Condition Setting and Signature / Addition Processing in Second Embodiment>
FIG. 10 is a flowchart illustrating an example of processing for signature and additional writing condition setting and signature and additional writing executed by the signature server 101 according to the second embodiment of this invention. Of the present embodiment, the same processing as in the first embodiment is cited and only the difference is described.

The signature / additional write condition management unit 108 sets conditions relating to the signature and additional writing in the same manner as in steps 701 to 706 (1001, 1002). Regarding the setting of the signature condition information 111, items 407 and 408 are also set in addition to the case of the first embodiment. Specifically, for example, in FIG. 4B, when sanitization is permitted in each signature condition ID, the item 407 is set to “permitted”, and the user who permits sanitization is set to the item 408. Items 409 and 410 are updated by the signature server 101 when a sanitized signature, which will be described later, is made.
Upon receiving the operation request from the user, the user cooperation unit 105 determines whether or not the operation request is a sanitized signature request (1003). It is determined whether or not there is execution authority (1004). Specifically, whether or not a sanitized signature is permitted in the item 407 of the signature condition ID requested for the signature, the user is registered in the item 408, or an sanitized signature is permitted to any user. Judge whether or not. If the user has authority, a sanitized signature is executed (1005), and it is confirmed whether there is another request from the user (1006). Specifically, the signature creation unit 106 updates the item 409 to “Yes” regarding the additional writing that has been subjected to the sanitized signature. Also, when a sanitization signature is made, a hash value of data to be sanitized before sanitization is calculated and registered in the item 410. In signature verification, a hash value of data to be signed is required. Even if the original data itself is sanitized and the value has changed, the signature can be verified by holding only the hash value of the original data as described above. That is, it can be verified that the signed document is not altered except for the sanitized portion. In this embodiment, the order control of the signature including the sanitized signature is not performed, but the order control may be performed as in the first embodiment. If there is another request in step 1006, the process proceeds to step 1003. If there is no other request, it is determined in the same manner as in the first embodiment whether or not all signatures have been completed under this signature condition (1007). If all signatures have been completed, the process ends. If not, the process proceeds to step 1002. If it is not a sanitization signature request in step 1003, the process proceeds to step 707 (1008). It should be noted that the user may select the sanitization target from the file of the item 404, or may smear a fixed target in advance.

  The above is the description of the processing of the second embodiment of the present invention. Next, a modification of the second embodiment of the present invention will be described. In this modification, as in the modification of the first embodiment, the client terminal 121, not the signature server 101, performs the signature, additional writing, and sanitization signature processing. In the following, based on the process of the modification of the first embodiment, the description of the same part will be omitted and the difference will be mainly described.

The signature / additional condition setting person uses the signature / additional condition management unit 803 to set information related to the signature condition and the additional recording condition in the same process as in steps 701 to 704. Here, items 407 and 408 are also set in the same manner as in the second embodiment. After the above condition setting is completed, the condition setting person transmits a document including the above condition information to the next user by e-mail or the like, and requests a signature or additional writing. The next user who has received the request confirms the received document and makes an operation request for signature or additional writing at his client terminal. Upon receiving the request, the signature verification unit 802 determines whether or not the received document has a signature. If the signature is present, the signature verification unit 802 verifies whether the signature is valid. At this time, in addition to the processing in the modified example of the first embodiment, it is further determined whether or not there is a sanitized signature based on the information of the item 409. The signature value is verified using the information in item 410. As a result of the signature verification, if all the signatures of the received document are valid, the user's signature and additional writing are performed in the same manner as in the modification of the first embodiment. If the received document has an invalid signature, the user is informed that the signature is invalid and the process is terminated.
The above is the description of the second embodiment of the present invention and its modifications.

  According to the above embodiment of the present invention, for example, in a signature system including a signature server and a client terminal, the signature server includes authentication information, signature condition information indicating the signature condition of each document, and additional write conditions. Additional write condition information, additional write type information indicating the type of additional write, and document information for storing a signature target document. The signature server sets the above-mentioned signature condition information and additional write condition information based on instructions from the signature and additional write condition setter, creates an additional write file as appropriate, defines the relationship between the original document and the additional write file, and Sign the condition information. The signature server further identifies a user who makes a signature or additional request for a document based on the authentication information, the signature condition information, and the additional recording condition information, and whether or not the user is authorized to sign or add. Determine. It also verifies the validity of the signature order and the validity of the signature already attached to the document. The signing server accepts the user's signature and additional writing according to the above signature and additional condition information if the user has the authority to sign and add, and if the order of signatures is valid, etc. Sign and add.

  Thus, according to one embodiment of the present invention, even a signed document can be added to the document and the document including the additional addition can be signed without invalidating the signature, and the signature target can be managed. It is possible to provide a recordable signature system that is easy to apply and can be applied to various types of documents. In addition, it is possible to provide a signature-addable signature system that allows a client terminal to perform a signature or appending process, or can apply a sanitary signature to a document.

  As mentioned above, although embodiment of this invention was described, this invention is not limited to such embodiment at all, Of course, it can implement with various forms within the range which does not deviate from the meaning of this invention. is there.

101 ... Signature server, 102,122 ... Memory, 103,124 ... CPU, 104,123 ... I / F, 105 ... User cooperation unit, 106,801 ... Signature generation unit, 107,802 ... Signature verification unit, 108,803 ... Signature, additional write condition management unit, 109,804 ... Additional management 110, 127 ... authentication information, 111 ... signature condition information, 112 ... additional write condition information, 113,805 ... additional write type information, 114,806 ... document information, 121 ... client terminal, 125 ... server cooperation part, 126 ... user cooperation part, 141 ... external Server, 201 ... ID, 202 ... Password, 203 ... Email address, 204 ... Organization, 301 ... Signature condition ID, 302 ... Original document, 303 ... Progress, 304 ... Signer, 305 ... Signature order, 306 ... Signature Number, 307 ... Signature status,
401 ... Signal condition ID, 402 ... Additional type, 403 ... Additional person, 404 ... Additional file, 405 ... Additional temporary file, 406 ... Signature number, 407 ... Inking / non-inking, 408 ... Inking person, 409 ... Inking / no-inking, 410 ... Hash value, 501 ... Additional type, 502 ... Content, 503 ... File type, 504 ... Temporary file type, 505 ... Remarks, 601 ... Relation file, 602 ... Main file group of document, 603 ... Additional file group, 1101,1102,1103… Document

Claims (10)

A signature system for signing created data, comprising one or more computers, a signature server, and at least one of the one or more computers and a network connected to the signature server. A signature system,
The signing server
Means for generating information for a subsequent signer to add when creating a signature on the data based on a request from the computer;
Means for recording the generated information in association with the data and the signature,
A signing system that allows the subsequent signer to add and sign the data. The signature system of claim 1, wherein
The means for generating is
Identifying the signature and appending condition information about the data, and generating, as the information, a file appending to the data and a correlation between the data and the appending file as the information Signature system to do. The signature system according to claim 2, wherein
The signature system, wherein the signature server performs a signature created by the signature creation on a portion excluding the additional file. The signature system according to claim 2 or 3,
The signature system, wherein the additional file is an empty file. The signature system according to any one of claims 1 to 4,
The signing server
In addition, it has means to record appending type information that defines the content and format of appending to the document,
The means for generating the information creates the additional writing file and the additional writing temporary file according to the additional writing type information, and when inputting the additional writing data from the computer, the additional writing data input from the computer is temporarily added to the additional writing data. A signature system which is stored in a file, converts the temporary write-once file into the post-write file format as necessary, and replaces the post-write file with the contents of the temporary write-once file. The signature system according to claim 5,
The signature system according to claim 1, wherein the signature server creates a definition file of the correlation between the additional file and the data and the additional file in the data. The signature system according to claim 5,
The signing system is characterized in that the signing server presents an input screen corresponding to the write-once type information and accepts the input data in order to input the write-once data from the computer. The signature system according to claim 5,
The signature server receives a request to create a signature from a user who uses the computer, and determines whether the user has the authority to create a signature based on the condition information or whether the order of the signatures requested to be created is valid. If the user has authority and the signature order is valid, the requested signature is created. If the signature is not valid, creation of the requested signature is prohibited, and a request for creating additional information is requested from the user using the computer. And determining whether the user has the authority to create additional writing based on the condition information or whether the target of additional writing is an unsigned area, and if the user has authority and the target of additional writing is an unsigned area Creates the requested additional writing, and prohibits the creation of the requested additional writing if it is not an unsigned area. The signature system according to claim 5,
The signature server discriminates additional data included in data that has been signed or added, and presents information such as contents and creators of each additional file that stores the additional data to the computer. Signature system. The signature system according to any one of claims 1 to 9,
The signature system, wherein the data is document data.

Images