JPH04286058A - Method and device for processing document - Google Patents

Abstract

PURPOSE:To provide a document processing method and its device, which can recognize whether the contents of the areas of respective documents are altered even if the passwords of respective persons in charge are not inputted at the time of checking whether document information including the document areas generated by the plural persons in charge is altered or not. CONSTITUTION:Names are added to respective document elements so as to store them. The inputted passwords and the names of the document elements are made to correspond so as to store them. When the document element is designated by the name of the document element, document data of the designated document element is extracted. The code of document data is generated based on extracted document data and the password so as to store it in accordance with the document element. When the name of the document element is specified, the code is calculated by the content of the document element and the password which is stored in accordance with the name. The calculated code and the stored code are compared and it is decided whether the content of the document element is altered or not.

Description

[Detailed description of the invention]

0001

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a document processing method and apparatus capable of creating and registering document information.

0002

[Prior Art] In such conventional document processing systems, input document information is stored as document files, and when these document files are subject to collaborative work by multiple users, they are stored by the operating system. , the method used was to share document files among multiple users and prohibit other users from accessing the files. For example, in UNIX operating systems, writing to document files, referencing (
Permissions for reading (reading) and execution can be granted for each file to the file's owner, group, or other users.

0003

[Problem to be Solved by the Invention] Therefore, in such a document processing system, a method is adopted in which a certain group is allowed to write to the file, while users outside the group are not allowed to write to the file. This allows you to share the file within a specific group.

[0004] Furthermore, when sharing such document files, if each document area is divided for each person in charge (user) in one unified document, each document area may be shared by other users. The applicant has developed a method in which, for each document area, each owner generates a code from the password and the document content, and inspects this code to check the document content, in order to check whether it has been changed. This was previously proposed in Japanese Patent Application No. 3-32897.

However, in this case, in order to confirm the contents, the person in charge had to enter his or her own password for each document element.

The present invention has been made in view of the above-mentioned conventional example, and it is possible to check whether document information including a document area created by a plurality of persons in charge has been changed without having to input each person's password. It is an object of the present invention to provide a document processing method and device that can confirm whether the contents of each document area have been changed even when the contents of each document area have been changed.

[0007]

Means and Effects for Solving the Problems In order to achieve the above object, the document processing device of the present invention has the following configuration. That is, a document processing device that handles document data composed of a plurality of document elements includes a document storage means for storing each of the document elements in a distinguishable manner, an input means for inputting a password, and a password input by the input means. storage means for storing the password in association with identification information of the document element; and extraction for inputting the identification information of the document element to specify the document element and extracting document data of the specified document element. means, a code generating means for creating a code for the document data based on the document data extracted by the extracting means and the password, and storing the code created by the code generating means in correspondence with the document element. a code storage means for storing a code, a calculation means for calculating a code based on the contents of the document element and a password of the storage means when the document element is specified, a code calculated by the calculation means, and a code storage means for storing the code, and comparison means for comparing the code with the stored code. Further, in order to achieve the above object, the document processing method of the present invention has the following configuration. That is, this is a document processing method that handles document data composed of a plurality of document elements, which includes a step of storing each document element in a distinguishable manner, a step of inputting a password for the document element, and a step of inputting the input password. and identification information of the document element, and when a document element is specified by the name of the document element, the document data of the specified document element is extracted, and the extracted document data and the document element are stored. A step of creating a code for document data based on a password, a step of storing the created code in correspondence with a document element, and once a document element is identified, the contents of the document element and its name are stored. By calculating a code based on the password stored in association with the password and comparing the calculated code with the stored code, it is possible to determine whether the content of the document element has been changed.

[0008]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings. <Description of the document processing system of the first embodiment (Figure 1)
> In this embodiment, a case will be explained in which the document data stored in one document file consists of one or more document elements, and a password for confirmation is set for each document element. In the following explanation, when a document element is "valid," it means that the content of the document element when it was registered matches the content of the document element that is currently stored. Even if the document content has been changed once, the document element is considered to be "valid" if the content has now been restored to its original state.

FIG. 1 is a block diagram showing the schematic configuration of the document processing system of this embodiment. An input device for inputting information, including, for example, a keyboard and a mouse. 2 is a CPU for performing the processing of this embodiment based on commands input from the input device 1; 3 is an output device for printing out or displaying the processing results of the CPU 2 or messages from the system; For example, it is equipped with a printer or CRT. Reference numeral 10 denotes a first memory for storing processing programs in this embodiment, and these programs may be stored in advance in a ROM, a hard disk, etc., or may be read into a RAM from a floppy disk, etc. . 20 is a second memory for storing document data handled in this embodiment, and 30 is a third memory used as a work area and for temporarily storing various data required for processing in this embodiment. . 4 is a CPU bus. It goes without saying that these first, second, and third memories do not need to be provided separately.

Next, each program stored in the first memory 10 will be explained. A password registration program 101 registers a password for a specified document element in a password registration table 203. Note that the password registration table 203 can be read and written only by the program for this processing, and has special authority such that the document creator and the like cannot read or write. This can be achieved using the file access prohibition function. A character string extraction program 102 is a program for extracting the contents of document elements from the document data 201, and is hereinafter referred to as a creation character string extraction program. A character string conversion program 103 transforms a given character string and converts it into another character string. Reference numeral 104 denotes an association program that associates document elements with creation validity confirmation codes 305 obtained by the character string conversion program 103. 105 is a verification code extraction program that extracts a comparison code 311 from the document data 202 to verify the validity of document elements. A character string comparison program 106 determines whether two character strings are the same. Reference numeral 107 denotes a character string extraction program, which is a program for extracting the contents of document elements from the signed document data 202 for verification, and is hereinafter referred to as the verification character string extraction program. A password extraction program 108 is a program for extracting a password for a specified document element from the password registration table 203.

Next, the configuration of the second memory 20 will be explained.

[0012] Reference numeral 201 denotes document data input by the document creator using the input device 1 or read from a floppy disk or the like. 202 is a mapping program 104
This is document data with a validity check code inserted and registered by . A password registration table 203 stores document elements and passwords in association with each other, and this registration table 203 can be accessed only by the password registration program 101 and the password extraction program 108.

Next, the configuration of the third memory 30 will be explained.

Reference numeral 301 is a document element name at the time of creation, which stores the name of a document element at the time of creation for uniquely specifying a document element for which a code of the document data 201 is to be generated. Reference numeral 302 denotes a character string to be generated at the time of creation, in which a character string to be generated as a code extracted from the document data 201 (a character string to be generated at the time of creation) is stored. Reference numeral 303 denotes a creation password, which stores the password input by the document creator from the input device 1 when creating the document. 305 is a code for verifying validity at the time of creation, and the code for verifying validity at the time of creation is stored by the character string conversion program 103 from the target character string 302 at the time of creation and the password 303 at the time of creation. Reference numeral 306 is a document element name at the time of confirmation, and information that uniquely indicates the document element whose validity is to be confirmed at the time of document confirmation is stored. Reference numeral 307 indicates a character string to be verified, and a character string extracted from the coded document data 202 for verification by the verification character string extraction program 107 is stored. 308 is a password at the time of confirmation, which is extracted from the password registration table 203 by the password extraction program 108.
The password determined with reference to is stored. 310
is the code for checking the validity at the time of creation, and the character string conversion program 1
03, a code created from the verification target character string 307 and the verification password is stored. Reference numeral 311 is a comparison code, in which the validity check code extracted from the document data with check code 202 by the validity check code extraction program 105 is stored, and 312 is a determination result, which is determined by the character string comparison program 106. The results will be stored.

<Description of document data (FIGS. 2 and 3)>
FIG. 2 is a diagram showing an example of input document data 201 in this embodiment.

As shown in the figure, document data 201 is separated into document elements by specific document delimiters, and here, the document delimiters are expressed as "<" and ".
>”. Therefore, each document element is a character string that starts with “<” and ends with “>”, and this start symbol “<
``The character immediately after is the document element name.It is prohibited to use the characters ``<'' and ``>'' in these document elements for purposes other than document delimiters.

[0017] FIG. 3 shows that a code such as "!!!" or "??????" is added after the extracted document element to confirm whether the document element is valid. Indicates the condition. Note that these processes will be described in detail later.

Next, the flow of processing in the document processing system of this embodiment will be explained. The processing here is roughly divided into two parts: one is for document creation, and the other is for checking the validity. This is a process for

First, the flow of document data creation processing by an operator will be explained with reference to the flowchart of FIG.

First, in step S1, the document creator (operator) inputs from the input device 1 the storage location (for example, file name) of the document data 201 in which each document element is given a document element name, and the document data 202 with a confirmation code. Enter the storage location and determine the processing target. Next, in step S2, which document element in the document data 201 is to be registered, the name of the document element is inputted from the input device 1. This input document element name is stored as the document element name at the time of creation 301. Next, the process proceeds to step S3, and the corresponding document element is extracted from the document data 201 using the creation character string extraction program 102, and is stored as the creation target character string 302. Next, the process proceeds to step S4, and when the operator inputs the creation password 303 from the input device 1, the password is registered in the password registration table 203 (step S5). Thereafter, from the creation target character string 302 extracted in step S3 and the creation password 303 inputted in step S4, the character string conversion program 103 is used in step S6 to create the creation validity confirmation code 305.
Create. Note that the code for verifying validity at the time of creation will be described later. Finally, in step S7, the correspondence program 104 is used to perform a process of associating the corresponding document element with the creation validity confirmation code 305 (described later), and the document creation process is ended.

Next, referring to the flowchart of FIG. 5, the character string extraction program 102 at the time of creation in step S3 of FIG.
The processing will be explained. First, identification of document elements will be explained. Each document element is a character string that begins with the character "<" and ends with the corresponding character ">". here,
The character string from immediately after the character "<" to the first blank character becomes the name of this document element (document element name). here"
"corresponding" is similar to the correspondence between parentheses in mathematical formulas, and "<" is always paired with one ">". In other words, "<" plays the role of an opening parenthesis, and ">" plays the role of a closing parenthesis. After the “<” that indicates the beginning of a first-level document element, the corresponding “>”
If “<” appears again before ” appears, this is the first
It represents the beginning of a second-level document element included in a second-level document element.

First, in step S11, step S in FIG.
Based on the document element name input in step 2, a process for detecting the start symbol "<" of a document element is started in order to detect a document element having the same element name from the document data 201. In step S12, if the document data 201 ends without this document element name being detected, the process advances to step S14, displays that there is no corresponding document element, and ends with an error.

[0023] In step S12, when a start symbol including this document element name is detected, the process proceeds to step S13, and the process starts from the character code next to the start symbol "<" until the corresponding end symbol ">" is detected. The character code string of the document element is stored in the creation target character string 302.

Next, referring to the flowchart of FIG.
The password registration process shown in step S5 of FIG. 4 will be explained. Here, the creation password is registered as the password corresponding to the document element name 301.

First, in step S21, the above-mentioned step S
It is checked whether the document element name entered in step 2 and stored in the creation document element name 301 is registered in the password registration table 203. If it has been registered in step S22, the process advances to step S23, and the password corresponding to the document element name registered in the password registration table 203 is entered.
The password is replaced with the password input in step S4 and stored in the creation password 303. On the other hand, if it is determined in step S22 that the document element name is not registered, the process advances to step S24, and the password registration table 203 includes the document element name stored in the document element name at creation 301 and the password stored in the creation password 303. Add/register by associating it with the existing password. Note that this process is executed under special authority that can update the password registration table 203.

FIG. 7 is a diagram showing the data structure of the password registration table 203 of the embodiment, and as shown, passwords and document element names are stored in correspondence.

Next, referring to FIG. 8, step S6 of FIG.
The code generation process will be explained. First step S31
Then, create target character string 302 and create password 303
The two character code strings are extracted, and in step S32, a creation-time validity confirmation code 305 is created using the character string conversion program 103. Note that although it is assumed here that the creation target character string 302 and the creation password 303 are character code strings, they may be simple byte strings. Needless to say, in the case of such a byte string, the character string conversion program 103 becomes a byte string conversion program.

This character string conversion program 103 can be realized using an algorithm similar to that used for password encryption in UNIX, for example. In other words, a certain character string is converted into another character code string using a method that practically does not allow reverse conversion. However, it goes without saying that blank characters, "<", and ">" must not be included in the converted character string.

Next, the processing of the association program 104 in step S7 in FIG. 4 will be described with reference to the flowchart in FIG. Here, after the last character of the target document element, a creation validation code 305 is inserted as a validation code for validating the document element with a space character in between. This is input device 1 by the document creator.
It may be input more directly, but it may also be done automatically. An example of automatic execution is shown below. The above-mentioned FIG. 3 shows a state in which this is inserted, and FIG. Document element name is “a”
This is the code for verifying the validity of the document element whose document element name is "b".

In FIG. 9, first, in step S41, the end symbol "" of the document element (designated in step S2 of FIG. 4) having the document element name indicated by the document element name at creation 301 is
>" is detected.Then, the creation validation code 305 obtained in step S32 of FIG. 8 is inserted as a validation code, along with a blank character, just before the end symbol ">'' (step S42). .As a result, this document data is designated as the document data 202 with a code for verifying validity.
Store in the specified storage location. The reason why a blank space is inserted before the code 305 for verifying validity at the time of creation is to enable the content of the document element to be distinguished from the code 305 for verifying validity at the time of creation.

In the above description, in FIG. 4, the code generation process in step S6 is performed after the character string extraction in step S3 and the password input in step S4.
While performing the target character string extraction process in step S3, the character string conversion program 10 sequentially converts the extracted character code strings into
3 to create a validity code.

Next, the process of verifying the validity of the signed document data 202 for verification will be explained with reference to the flowchart shown in FIG. First, in step S50, the document verifier (person in charge) inputs from the input device 1 the storage location of the coded document data 202 for verification to be verified. Subsequently, in step S51, the operator who wishes to confirm the document data inputs the confirmation document element name 306 from the input device 1. This is step S2 in FIG.
Similarly, the name of the document element to be confirmed is input, and when this name is input, it is stored in the document element name upon confirmation 306. Next, the process advances to step S52, and the verification character string extraction program 107 is used to extract the corresponding verification target character code string 307 from the verification coded document data 202. The process then proceeds to step S53, refers to the password registration table 203, extracts the password corresponding to the document element name, and stores it in the confirmation password 308. Next, the process proceeds to step S54, where a character string conversion program generates a code 310 for verifying validity from the verification target character code string 307 extracted in step S52 and the verification password 308 extracted in step S53.

Then, the end symbol ">" of the document element indicated by the verification document element name 306 input in step S51 is detected from the signed document data 202 for validation, and the character code string immediately before the end symbol is detected. (In other words, the validation code excluding spaces (see FIG. 3) inserted in step S42 in FIG. 9 during document creation) is compared to the comparison code 311.
(step S55). and step S
56, the verification code 310 created in step S54 is compared with the comparison code 311 extracted in step S55, and if they match, the process goes from step S57 to step S58, and a message indicating that it is valid (e.g. String “y”
es") is written in the judgment result 312. On the other hand, if they do not match in step S57, the process proceeds to step S59, and a message indicating that it is not valid (for example, the character string "no") is written in the judgment result 312. This ends the confirmation process. do.

The processing of the confirmation character string extraction program 107 in step S52 of FIG. 10 is performed by the creation character string extraction program 102 shown in the flowchart of FIG.
In the explanation of FIG. 5, the document data 201 is set to the document data with a code for checking validity 202, the document element name at the time of creation 301 is set to the document element name at the time of confirmation 306, and the target character string at the time of creation 302 is set to the document element name at the time of confirmation. Since the same explanation can be given by replacing it with the confirmation target character string 307, the explanation thereof will be omitted. However, here, it is necessary to remove the last validation code from the character string 307 to be verified.

Next, referring to the flowchart of FIG. 11,
The processing of the password extraction program 108 will be explained. Here, a password corresponding to the document element name input in step S51, that is, password 3 at the time of confirmation.
08 is taken out.

In step S61, the password registration table 203 is created based on the document element name input in step S51.
to see if the document element name is registered. If the document element name is registered in step S62, the process advances to step S63, where the corresponding password is read out and stored as the confirmation password 308. On the other hand, if it is determined in step S62 that the document element name is not registered, the process advances to step S64, an error is notified, and the process ends. Note that this process is also executed under special authority that allows the user to refer to the password registration table 203, similar to the password registration program described above.

Next, the code generation process in step S54 in FIG. 10 can be realized in the same manner as the process in FIG. 8 described above. However, in FIG. 8, the target character string 302 at the time of creation is
In this case, if the character string to be verified is 307, the creation password 303 is replaced with the verification password 308, and the creation validity verification code 305 is replaced with the verification validity verification code 310, it can be done in exactly the same way as in FIG. I can explain.

As described above, in this embodiment, it is possible to detect whether the document data has been changed by simply specifying the name of the document element whose validity is desired to be confirmed. In this embodiment, a case has been described in which a validation code for confirming authenticity is embedded in a document, but the present invention is not limited to this. For example, this validation code can be embedded in the same way as a password. It is also possible to easily manage the data in separate files. Further, in this embodiment, the document elements are specified by the name of the document element, but it may be specified by the order of the document elements, their positions, or the like.

[0039] Also, an example was explained in which the password registration table 203 is registered at the same time during the document data creation process, but the registration is performed separately and the registered password is input when creating the document data. At this time, the password registration table 203 may not be updated. Further, a plurality of password registration tables may be prepared, and the storage location of the password registration table may be specified when specifying document data.

<Second Example (FIGS. 12 to 18)>
A second embodiment of the present invention will be described below with reference to FIGS. 12 to 18. In this second embodiment, an example will be described in which the validity of a document element is confirmed in the same way as in the first embodiment. The feature is that the determination is made using the authenticity confirmation password registered for each item. Incidentally, in this second embodiment, parts common to the above-mentioned embodiments are indicated by the same numbers, and their explanation will be omitted.

FIG. 12 is a diagram showing a schematic configuration of a document processing system according to the second embodiment. The configuration is almost the same as that of FIG. 1 described above, but the first, second, and third memories described below are The types of programs and data stored in the computer are different.

In the first memory 10, 111 is an owner registration program, which allows a document creator to use this program to register a specified document element in place of the password registration program 101 in FIG. The owner of the document element is registered in the owner registration table 214. Reference numeral 118 is a password extraction program which, in place of the password extraction program 108 described above, can extract the password of a designated document element by referring to the owner registration table 214 and the password registration table 213. A password registration program 119 registers a password for each owner in the password registration table 213 independently of the document element.

Next, the data structure of the second memory 20 will be described. Reference numeral 213 is a password registration table, which is different from the password registration table 203 of FIG. 1 and is a registration table in which passwords corresponding to owners are registered. 214 is the owner registration table,
Stores correspondence information between document elements and their owners. Note that these password registration tables 213 are based on the password registration program 119 and the password extraction program 11.
8, and the owner registration table 214
can be accessed only by the owner registration program 111 and the password extraction program 118. In other words, document creators and document checkers are prevented from directly reading and writing.

Next, to explain the structure of the third memory 30, numeral 313 is the owner name at the time of creation, and the owner name of the document element input by the document creator from the input device 1 when creating the document is remembered. 318 is the owner name at the time of confirmation, and the password extraction program 118 registers the owner name obtained from the owner registration table 214 for the specified document element.

First, the flow of document creation processing in this second embodiment will be explained with reference to the flowchart of FIG.

First, in step S71, the document creator inputs the storage location (for example, file name) of the document data 201 and the storage location of the verification coded document data from the input device 1, and determines the processing target. Next, the process proceeds to step S72, where the document creator inputs the document element name 301 at the time of creation from the input device 1.
When inputted, the process advances to step S73, and the corresponding creation target character string 302 is extracted from the document data 201 using the character string extraction program 102. Furthermore, step S74
When the document creator inputs the owner name 313 at the time of document creation from the input device 1, the process advances to step S75, and the owner name is entered in the owner registration table 2 by the owner registration program 111.
Register on 14th.

Next, the process advances to step S76, and step S7
2, the password extraction program 118 is used to obtain the creation password 303 from the input document element name 301. Next, the process proceeds to step S77, in which the character string conversion program 103 generates a creation validity check code 305 from the creation target character string 302 extracted in step S73 and the creation password 303 extracted in step S76. Finally, the process proceeds to step S78, where the correspondence program 104 is used to perform a process of associating the corresponding document element with the creation-time validity check code 305, and the process of creating document data with a validity check code is completed. .

Note that the process of the owner registration program 111 in step S75 in FIG. 13 is similar to the process in step S75 in FIG.
5, and can be explained by replacing the creation password 303 with the creation owner name 313 and the password registration table 203 with the owner registration table 214 in step S5. Note that this process is also executed with special authority given so that it can be written in the password registration table 214. This concludes the explanation of the owner registration process.

Next, the processing of the password extraction program 118 in step S76 of FIG. 13 will be described. Here, the owner registration table 214 and the password registration table 213 are referred to, and the password corresponding to the specified document element 301, that is, the creation password 303, is retrieved. I will explain.

First, in step S81, the owner registration table 21
4, search for the owner name item corresponding to the input document element name 301. In step S82, if the target item is found, the process advances to step S83, and the owner name portion of the item is set as the owner name 324 at the time of password extraction. On the other hand, the item related to the document element name 301 is
If it is not registered in step S89, the process advances to step S89.
Notify an error and terminate the process.

[0051] Following step S83, the process advances to step S84, and the password registration table 213 is referred to to search for an item corresponding to the owner name 324 at the time of password extraction. Step S
If the target item is found in step S85, the process advances to step S86, and the password part of the item is set to password 30 at the time of creation.
Store it as 3. On the other hand, if the item related to the owner name 324 is not registered in step S85, the process advances to step S87, an error is notified, and the process ends.

[0052] This process is also executed with special authority given to the user to be able to refer to the owner registration table 214 and the password registration table 213. FIG. 15 shows an example of the data structure of the password registration table 213, and FIG. 16 shows an example of the owner registration table 214.

As is clear from these figures, in the password registration table 213, a password is registered corresponding to the owner name, and in the owner registration table 214, the owner name is registered corresponding to the document element name. Registered.

Next, the password registration table 213 will be explained with reference to the flowchart of FIG. It is assumed that each item in the password registration table 213, that is, a pair of owner name and its password, has been registered by the password registration program 119 before the document validity confirmation described above.

First, in step S91, when the owner name at the time of registration is input from the input device 1, it is stored in the owner name at the time of registration 321, and in step S92, the password input from the input device 1 is input and the name at the time of registration is entered. The password is stored in the password 323. The process then proceeds to step S93, where the registration password 323 and the registration owner name 321 are associated and added to the password registration table 213. Next, in step S94,
It is checked whether all the names of potential owners have been registered, and if all the names have been registered in step S95, the process ends. Otherwise, the processing of steps S91 to S95 is repeated. This completes the password registration process.

Similar to the first embodiment described above, in the coded document creation process for verifying validity shown in FIG.
Although the process is performed after step S76, the extracted characters may be sequentially input to the character string conversion program 103 while performing the target character string extraction process in step S73.

Finally, with reference to the flowchart of FIG. 18, the flow of the validity confirmation process for a specified document element will be explained.

First, in step S100, the storage location of the signed document data 202 for verification is determined as follows.
The document checker inputs the information from the input device 1 to determine the processing target. Subsequently, in step S101, when the document checker inputs the document element name 306 at the time of confirmation from the input device 1, in step S102, the character string extraction program 107 is used from the coded document data for confirmation 202 to extract the corresponding confirmation time. The target character string 307 is extracted. Next, in step S103, the password extraction program 118 extracts the confirmation password 308 corresponding to the confirmation document element name 306 by referring to the password registration table 213 and the owner registration table 214, and extracts the confirmation password 308 corresponding to the confirmation document element name 306. From the character string 307 and the confirmation password 308 extracted in step S103, the character string conversion program 10
3, create the code 310 for verifying validity at the time of verification (
Step S104).

Next, the process advances to step S105, and the end symbol ">" of the document element indicated by the verification document element name 306 input in step S101 is detected from the signed document data 202 for validity verification, and the end symbol ">" is detected. The character string immediately before is extracted as the comparison code 311. Next step S
Proceeding to step 106, the verification code 310 created in step S104 is compared with the comparison code 311 extracted in step S105, and if they match, the code 310 is processed in step S10.
Proceeding to step 7, a character string "yes", for example, is written in the determination result 312 to indicate that it is valid. If they do not match in step S107, the process proceeds to step S108, and a character string "no", for example, is written in the determination result 312 to the effect that it is not valid. In this way, the confirmation process ends.

[0060] In this embodiment, a case has been described in which the name of the owner of a document is registered at any time when the document is created.
It is also conceivable to allocate correspondence between document elements and their owners in advance, and set a validity confirmation code when registering the document.

Furthermore, the present invention may be applied to a system consisting of a plurality of devices, or may be applied to a device consisting of one device, or by supplying a program to the system or device. Needless to say, it can also be applied to cases where the goal is achieved.

As explained above, according to this embodiment, a password that maintains the validity of a document element is stored in a storage area that can be accessed only from a specific program, and the password can be changed by simply specifying the document element name. You can check the validity of a document element without having to enter it. Therefore, it is possible to eliminate the complexity of having the owner input a password for each document element.

[0063] Accordingly, it is possible to reduce unnecessary work due to incorrect password input when creating a document and confirming authenticity.

[0064] Furthermore, since it is not necessary to input a password when confirming the authenticity, even a third party other than the document owner who does not know the password can confirm the authenticity of the document. That is, this method eliminates the need for the document owner to intervene when periodically confirming the validity of the document contents. In the above embodiment, document data is the target data for determining whether or not the data content has been changed, but program data may also be the target data. That is, the present invention can also be applied to confirming the validity of a program source.

[0065]

[Effects of the Invention] As explained above, according to the present invention, when checking whether document information including a document area created by a plurality of persons in charge has been changed, it is not necessary to input the password of each person in charge. This also has the effect of allowing you to check whether the contents of each document area have been changed.

[Brief explanation of the drawing]

FIG. 1 is a system configuration diagram showing a schematic configuration of a document processing system according to a first embodiment of the present invention.

FIG. 2 is a diagram for explaining document elements of document data according to the embodiment.

FIG. 3 is a diagram showing an example of converting the document data in FIG. 2 into document data with confirmation code.

FIG. 4 is a flowchart for explaining the flow of document creation processing in the document processing system of the first embodiment.

FIG. 5 is a flowchart for explaining character string extraction processing in the first embodiment.

FIG. 6 is a flowchart for explaining password registration processing in the first embodiment.

FIG. 7 is a diagram showing an example data structure of a password registration table according to the first embodiment.

FIG. 8 is a flowchart for explaining code generation processing in the first embodiment.

FIG. 9 is a flowchart for explaining association processing in the first embodiment.

FIG. 10 is a flowchart for explaining document confirmation processing in the first embodiment.

FIG. 11 is a flowchart for explaining password extraction processing at the time of confirmation in the first embodiment.

FIG. 12 is a system configuration diagram showing a schematic configuration of a document processing system according to a second embodiment of the present invention.

FIG. 13 is a flowchart for explaining the flow of document creation processing in the document processing system of the second embodiment.

FIG. 14 is a flowchart for explaining password extraction processing in the second embodiment.

FIG. 15 is a diagram showing an example data structure of a password registration table according to the second embodiment.

FIG. 16 is a diagram showing an example of the data structure of an owner registration table according to the second embodiment.

FIG. 17 is a flowchart showing password registration processing in the second embodiment.

FIG. 18 is a flowchart for explaining the flow of confirmation coded document confirmation processing according to the second embodiment.

[Explanation of symbols]

1 Input device 2 CPU 3 Output device 4 Buses 10, 20, 30 Memory 105 Validity confirmation code extraction program 107
Confirmation character string extraction program 108 Password extraction program 201 Document data 202 Signed document data for validity confirmation 203
Password registration table 214 Owner registration table 303 Password at creation 305 Code for verifying validity at creation 311 Code for comparison 312 Judgment result

Claims (2)

[Claims] 1. A document processing device that handles document data composed of a plurality of document elements, comprising: document storage means for storing each of the document elements in a distinguishable manner; input means for inputting a password; and the input means for inputting a password. a storage means for storing a password inputted by the means and identification information of the document element in association with each other; and a storage means for inputting the identification information of the document element to designate the document element, and document data of the designated document element. an extraction means for extracting a code, a code generation means for generating a code for the document data based on the document data extracted by the extraction means and the password, and a code generated by the code generation means for the document element. a code storage means for storing the code in correspondence; a calculation means for calculating a code based on the contents of the document element and a password of the storage means when the document element is specified; a code calculated by the calculation means; A document processing device comprising: comparison means for comparing the code stored in the code storage means. 2. A document processing method for handling document data composed of a plurality of document elements, the method comprising: storing each of the document elements in a distinguishable manner; inputting a password for the document element; and inputting the password. A step of storing the password in association with identification information of the document element, and when a document element is specified by the identification information of the document element, extracting the document data of the specified document element, and extracting the document data of the specified document element. a step of generating a code for document data based on the document data and password; a step of storing the generated code in correspondence with a document element; and once a document element is identified, the content of the document element is , a step of calculating a code based on a password stored in association with the identification information, and comparing the calculated code with the stored code to determine whether the content of the document element has been changed. A document processing method characterized by enabling determination.