JPH04286064A - Device and method for processing document - Google Patents

Abstract

PURPOSE:To confirm the justness of a whole target document element by preparing a code based on a character string from the inputted document element and a password and comparing the code with a comparison code. CONSTITUTION:The inputted password is stored in a confirmation time password 308. Then, the code is generated from a confirmation object character string 307 and the confirmation time password 308. Then, the code is stored in a code 310 for confirmation time justness confirmation. Then, a code 305 for a generation time justness confirmation is fetched to the comparison code 311 from document data 202 with justness confirmation. Then, the code 310 for recognition time justness confirmation is compared with the comparison code 311. When they match, effect that it is just is described in a judgement result 312. Thus, the justness of the whole target document element can be recognized even if the other document element exists in one document element.

Description

[Detailed description of the invention]

0001

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a document processing apparatus and method, and more particularly to a document processing apparatus and method capable of creating, editing, and storing documents.

0002

[Prior Art] Normally, in this type of device, documents created on the device can be saved as files in an external storage device (hard disk device, floppy disk device, etc.) connected to the device. ing. If a single document file is the subject of collaborative work by multiple users, the operating system allows the file to be shared among multiple users and prohibits other users from accessing the file. The method was to do so.

[0003] For example, in the UNIX (developed and licensed by AT&T Corporation of the United States; hereinafter the same) operating system, permissions for writing, viewing (reading), and executing each file are granted to the file owner, group, and other users. It can be given to the user. In such a system, if you want to share a file within a group and disallow users outside the group from modifying it, you must By allowing users outside the group to write files, users outside the group are not allowed to write files, thereby allowing the document to be shared only within the group.

[0004] In addition, in a single document, each person has their own area of responsibility, and if writing is not permitted for each other, each person is responsible for each area (for each management target).
In other words, they were divided and managed as separate files (document elements).

[0005]

[Problem to be Solved by the Invention] However, in the above-mentioned conventional technology, each person's area of responsibility in one document is
If writing by others was not allowed, this document could not be combined into one file. In addition, in the previously filed Japanese Patent Application No. 3-32897, the applicant has made it possible to confirm that the content is valid (has not been changed by another person), instead of preventing the content from being changed. A method is proposed in which such a plurality of document areas can be collectively combined into one file by allowing this confirmation to be performed for each document area.

However, in this method, each document area is allowed to have a nested structure, and the case where one document area contains another document area is not considered. The present invention was made in view of such prior art, and even if there are other document elements within one document element,
It is an object of the present invention to provide a document processing device and method capable of confirming the validity of the entire target document element.

[0007]

Means for Solving the Problems In order to solve this problem, a document processing apparatus of the present invention has the following configuration. That is, the document processing apparatus handles document data composed of a plurality of document elements, and includes a password setting means for setting a password for the document element, and a second document in the document element corresponding to the set password. If there is an element,
a character string extraction means for extracting a character string including the second document element; and a code corresponding to the document element based on the character string extracted by the extraction means and the password set by the password setting means. A code generating means for generating a code, a storage means for storing the code generated by the code generating means in association with a corresponding document element, and information for specifying a desired document element and information corresponding to the document element. an input means for inputting a password; the code generation means generates a character string obtained from a document element specified by the input information and a code based on the password; the code and the code stored in the storage means; and comparison means for comparing the.

Further, the document processing method of the present invention includes the steps shown below. That is, this is a document processing method that handles document data composed of a plurality of document elements, which includes a password setting step of setting a password for the document element, and a second document in the document element corresponding to the set password. If there is an element, a character string extraction step that extracts a character string that also includes the second document element, and the document element is extracted based on the character string extracted in the extraction step and the password set in the password setting step. a code generation step of generating a code corresponding to the document element, a storage step of storing the generated code in association with the corresponding document element, and information for specifying the desired document element and information corresponding to the document element. an input step of inputting a password, and generating a character string obtained from a document element specified by the input information and a code based on the password in the code generation step, and generating the code and the code stored in the storage step. and a comparison step of comparing the.

[0009]

[Operation] In the configuration or process of the present invention, if there is another document element in the document element, a character string including the other document element is extracted, a code is generated together with the set password, and the code is stored and stored. put. In addition, when the operator enters information that specifies a document element and the password corresponding to that document element, the character string (including other document elements, if there are other document elements) in the corresponding document element. is extracted and a code is generated along with the entered password. Then, by comparing the generated code and the previously stored code, the validity of the document element of interest is confirmed.

0010

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. In this embodiment, the document data stored in one file consists of one or more document elements (hereinafter referred to as first-level document elements), and the first-level document elements include: Other document elements (hereinafter referred to as
We will discuss the case where there is one or more level document elements). Then, the validity of the first level document element at that time is determined using the validity confirmation code.

[0011] Also, in the following explanation, the document element is "
"Valid" means that the content of the document element has not changed since the time the document element was registered. That is,
Even if a document element has been changed, it is considered valid if the document element is changed back to its original state. FIG. 1 is a diagram showing the configuration of a document processing system in this embodiment. In the figure, 1
is an input device for a user of this system (a document creator or a document checker) to input documents or commands into this system, and is, for example, a keyboard.

2 is a CPU for performing the processing of this embodiment based on commands input from the input device 1; 3 is a CPU;
An output device for printing out or displaying the processing results of U2 or messages from this system, such as a printer or CRT. 10 is a first storage device for storing the processing program in this embodiment, 20 is a second storage device for storing document data handled in this embodiment, and 30 is a storage device for storing data required for processing in this embodiment. This is a third storage device for temporary storage.

Although the first, second, and third storage devices do not have to be separate, if a program executable by the CPU 2 is loaded in the first storage device 10, a RAM consisting of an IC chip is used. Alternatively, it is common to use a ROM in which a program is written in advance. Furthermore, since the second storage device stores document data and the like, it is desired that the data be retained even after the power is cut off, so a hard disk, a floppy disk, or the like is preferable.

Now, the following programs exist in the first storage device 10. 102 is document data 2
A character string extraction program (hereinafter referred to as creation character string extraction program) is used to extract part or all of the content of a document element using the order from 01 as a guide; 103 transforms a given character string and extracts it in another way; A character string conversion program 104 for converting a character string (code) into a character string (code) associates document elements with the order of the creation validity confirmation code 305 obtained by the character string conversion program 103. In the above, a correspondence program 105 is used to store document data, and a code extraction program 105 is used to extract a comparison code 311 of a document element from the document data 202 with a code for validity check, using the order as a guide. , 106 is a character string comparison program for determining whether two character strings are the same. 107 is a character string comparison program for determining whether two character strings are the same. 107 is a character string comparison program that extracts part or all of the contents of document elements based on the order from the signed document data 202 for validation. String extraction program for (
This is hereinafter referred to as the confirmation character string extraction program).

In the second storage device 20, 201 is document data made up of a plurality of document elements created by document creators, and 202 is a validity confirmation code registered by the association program 104. This is attached document data. In the third storage device 30, the following areas are secured. 301 is a document element number (hereinafter referred to as creation document element number) that stores information indicating the first level document element of the target document element at the time of document creation, and 302 is the number at creation time. An area 303 for storing character strings to be extracted from the document data 201 by the character string extraction program 102 and to be used for code generation (hereinafter referred to as character strings to be created) is an area 303 that is input by the document creator from the input device 1. 304 is an area for storing the created password (hereinafter referred to as creation password);
2 and the creation password 303 (hereinafter referred to as creation-encrypted data). 305 is an area for storing a creation-time validation code created from creation-encrypted data 304 by the character string conversion program 103; 306 is an area for storing a first-level document element to be targeted at document verification; An area for storing a document element number to indicate whether it is a document element (hereinafter referred to as a document element number at the time of confirmation); 307 is a character extracted from the signed document data for validity confirmation 202 by the character string extraction program at the time of confirmation 107; Area for storing columns (hereinafter,
308 is an area for storing the password input by the document verifier from the input device 1 (hereinafter referred to as the character string to be verified).
(referred to as the confirmation password). Further, 309 is an area for storing encrypted data created from the verification target character string 307 and the verification password 308 (hereinafter referred to as verification encrypted data); An area 311 stores a code for verifying validity at the time of verification created from the encrypted data 309 (hereinafter referred to as a code for verifying validity at the time of verification); This is an area (hereinafter referred to as a comparison code) for storing a code for confirming the validity extracted from the accompanying document data 202. Further, 312 is an area for storing determination results of the character string comparison program 106.

Document data 20 of the embodiment with the above configuration
An example of No. 1 is shown in FIG. The document data 201 can be clearly separated into document elements using a certain document delimiter. Here, document elements are character strings that start with the characters "<" and end with ">" (they always form a pair). And in one document (or in a document element)
It is prohibited to use the characters “<” and “>” for purposes other than document delimiters.

Next, the flow of processing in this embodiment will be explained. The processing is broadly divided into two parts. These are the process of creating a document and the process of confirming its validity. <Description of document creation process> First, Figure 2 shows the process of registering a validity confirmation code in a document created by multiple people.
This will be explained using a flowchart.

First, the document creator uses the input device 1 to specify the storage location (for example, file name) of the document data 201 to be input and the storage location of the signed document data 202 for validation, which is the processing result of this process. input and specify the document processing target (step S201). Note that document data 2
01 may be created in advance using an editor or the like. Next, the document creator inputs the number n of the first level document element to be targeted in the document data 201 from the input device 1 (step S202), and uses this as the document element number at the time of creation. 301.

Then, the corresponding creation character string 302 is extracted from the document data 201 using the creation character string extraction program 102 (step S203, details will be described later). Furthermore, the document creator inputs the creation password 303 from the input device 1 (step S204), and from the creation target character string 302 extracted in step S203 and the creation password 303 input in step S204,
Create a code 305 for verifying validity at the time of creation (step S
205, details will be described later).

Finally, using the association program 104, the corresponding document element and the creation validity confirmation code 305 are
(Step S206, details will be described later), and the document creation process ends. The processing of the creation character string extraction program 102 in step S203 in FIG. 2 will be described.

In FIG. 9, the range of character strings in the document data 201 used when creating the data to be encrypted at the time of creation is shown by broken lines. The contents of this process will be explained below according to the flowchart of FIG. First, identification of document elements will be explained. Each document element is a character string that starts with the character "<" and ends with the corresponding character ">". 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. When a corresponding ">" appears after "<" representing the beginning of a first-level document element, this represents the beginning of a second-level document element.

[0022] Here, the description is "~th document element", but since the target is only the first level document element, the "nth document element" is the "first level document element". It means "the nth item". First, the start symbol "<" of the nth document element indicated by the document element number 301 at the time of creation is detected from the document data 201 among the first level document elements (step S3
01). If the end of the document data 201 is reached without being detected, it means that there is no corresponding first-level document element, so the process proceeds to step S302, where error processing (displaying a message indicating that there is no corresponding document element, etc.) is performed. finish.

[0023] Also, if detected, the start symbol "
The character string is traced sequentially from the character following <" up to the character immediately before the corresponding end symbol ">" and is stored in the creation target character string 302 (step S303).
The explanation of the process in step S203 ends. The code generation process in step S205 in FIG. 2 will be explained using FIG. 4.

First, two character strings, the creation target character string 302 and the creation password 303, are concatenated to create creation encrypted data 304 (step S401). still,
Here, create target character string 302 and create password 3
Although 03 is assumed to be a character string, it may be a simple byte string. Next, the data to be encrypted at the time of creation 304 is converted into another character string using the character string conversion program 103, and this is stored as the code for verifying validity at the time of creation 305 (step S402). Of course, the data to be encrypted at the time of creation 3
It goes without saying that when 04 is just a byte string, 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. It converts one string of characters into another by a method that is virtually irreversible. However, spaces and “<” characters may appear in the converted string.
” and “>” must not exist. With the above, the process of step S205 can be realized.

Next, the processing of the association program 104 in step S206 in FIG. 2 will be described. Here, the creation validation code 305 is used for the first
Insert after the last character of the content of the level's document element. However, in order to make it possible to identify (correspond to) the characters constituting the document element contents and the code for verifying validity at the time of creation, a blank character is inserted between them. The document creator may input the information directly using the input device 1, but the information may also be input automatically. An example of automatic processing is as follows.

FIG. 10 shows an example of the coded document data 202 for verification generated in this way. In the diagram, “?
? ? ? ? ” is the validity confirmation code of the first first-level document element, and “! ! ! ! ! ” indicates the validation code of the second first-level document element. Here,
The flow of the above-mentioned processing will be explained using the flowchart of FIG. 5.

First, from the document data 201, the end symbol ">" of the n-th document element indicated by the creation document element number 301 among the first level document elements is detected (step S501). And, the code 30 for checking the validity at the time of creation.
5 is inserted with a blank character immediately before the end symbol ">" (that is, immediately after the first-level document element content) (step S502), and this is set as the signed document data 202 for validation. The space characters inserted here are used to clearly separate the content of the document element from the validation code. This concludes the explanation of the process of step S206.

In the above example, the process of step S205 is
Although this is performed after steps S203 and S204 are completed, the extracted characters may be sequentially input to the character string conversion program 103 while performing the target character string extraction process in step S203. <Description of the validity confirmation process> Next, the validity confirmation process will be explained according to the flowchart of FIG.

First, the document verifier (person in charge) determines the storage location of the signed document data 202 for verification.
is input from the input device 1 (step S600). Subsequently, the document checker (person in charge) inputs the number of his/her own document element using the input device 1. The input document element number is stored in the confirmation document element number 306 (step S601
). With this input, the character string extraction program 1 at the time of confirmation
By executing Step S607, the corresponding document element is extracted from the signed document data 202 for checking validity, and it is stored in the character string 307 to be checked (step S602).
, details will be described later).

[0031] Next, the document verifier inputs his or her own password using the input device 1. The entered password is stored in the confirmation password 308 (step S603).
. Next, encrypted data is created from the verification target character string 307 extracted in step S602 and the verification password 308 input in step S603, and stored in the verification encrypted data 309. Then, based on the data in the verification encrypted data 309, a code is generated by the same process as in the previous step S205, and it is stored in the verification validity verification code 310 (step S604).

Next, the signed document data 2 for validation
02, the end symbol of the n-th first level document element indicated by the confirmation document element number 306 input in step S601 is detected, and the character string immediately before the end symbol (that is, in FIG. 5 at the time of document creation) is detected. , which is the creation-time validity confirmation code inserted in step S502 and is separated from the last character of the document element content by a blank character) is extracted as the comparison code 311 (step S605).

Finally, the verification code 310 created in step S604 is compared with the comparison code 311 extracted in step S605 (step S606), and if they match, it is valid, for example, the character string "yes" is ” is written in the determination result 312 (step S607). Further, if they do not match in step S606, the fact that it is not valid, for example, a character string "no", is written in the determination result 312 (step S608). After this, processing returns to the main routine. The main routine may display a message or the like according to the determination result 312 when returning from this subroutine.

The processing of the verification character string extraction program 107 in step S602 in FIG. 6 is as shown in the flowchart in FIG. Incidentally, from step S701 to step S
The processing up to step 703 is the same as the processing from step S301 to step S303 in FIG. However, the document data 201 is the document data 202 with a code for validity confirmation.
, document element number 301 at the time of creation is document element number 30 at the time of confirmation
6. Target character string 302 at creation is target character string 307 at confirmation
become. In other words, the signed document data 20 for validation
The content of the document element with the specified document element number in 2 (the character string from immediately after the start symbol to immediately before the corresponding end symbol) is extracted and stored in the character string to be checked at the time of confirmation 307. However, if left as is, the final blank character and the following validation code will be included, so that part is deleted from the data stored in the verification target character string 307 (step S704).

[0035] Instead of performing such processing (processing of once storing and then deleting part of the stored data), when storing the extracted character string in the verification target character string 307, It is also possible to remove the last string and the space character immediately before it before executing. With the above steps, the process of step S602 can be realized. Code generation in step S604 in FIG. 6 is the same process as step S205. Therefore, in FIG. 4, the target character string 302 at the time of creation is verified, the target character string 307 is verified, the password 303 at the time of creation is verified, the password 308 is verified, the encrypted data 304 is verified at the time of creation, the encrypted data 309 is verified, and the valid character string is verified at the time of creation. Exactly the same explanation can be achieved by simply replacing the authenticity confirmation code 305 with the validity confirmation code 310 at the time of confirmation.

[0036]Although the document creation processing and the validity confirmation processing have been described as processing for one document element, the respective processing may be performed for each document element. Further, the steps after specifying the document data may be repeated as many times as necessary. As described above, according to this embodiment, by simply specifying a document element by number and inputting a password, it is possible to confirm the validity of the document element. For example, if a document that has been approved within a company is saved using the procedure shown in FIG. 2, it is possible to determine whether each document element has been edited, such as corrections or additions.

<Description of Other Embodiments> The second embodiment will be described below with reference to the drawings. In this second embodiment,
As in the first embodiment described above, an example will be described in which the validity of document elements is confirmed.
The feature is that each document element has a name by writing a name).

FIG. 11 is a diagram showing the system configuration in this embodiment. Although the configuration of the device is the same as in Figure 1,
The programs and data stored in the first, second, and third storage devices described below are different. In the first storage device 10, 112 corresponds to the creation and confirmation character string extraction programs 102 and 107 shown in FIG.
1 or a character string extraction program for extracting part or all of the content of a document element from the signed document data 212 for validation using the document element name as a guide;
corresponds to the mapping program 104 in FIG. 1, and is a mapping program for mapping document elements to the creation-time validity confirmation code 305 obtained by the character string conversion program 103 using the document element name as a guide. It is. 115 corresponds to the validation code extraction program 105 in FIG.
A comparison code 311 is extracted from the document data 212 using the document element name as a clue.

In the second storage device 20, 211 is the document data in this embodiment created by the document creator;
Reference numeral 2 denotes document data with a validity check code in this embodiment in which a validity check code is registered by the association program 114. In the third storage device 30, 321
is a document element name that stores the name of the target document element at the time of document creation (hereinafter referred to as document element name at creation time), 32
Reference numeral 6 denotes a document element name (hereinafter referred to as a document element name at the time of confirmation) in which the name of the document element targeted at the time of document confirmation is stored.

FIG. 16 shows document data 2 in this embodiment.
11 examples are shown. Document data can be clearly separated into document elements using a certain document delimiter. Here, it is assumed that the document delimiter starts with the character "<" and ends with ">". Document element names, etc. are written between “<” and “>”. Therefore, it is prohibited to write the characters "<" and ">" in a document for purposes other than document delimiters.

Document delimiter symbols include a start symbol indicating the beginning of a document element and an end symbol indicating the end of a document element. An end symbol is a "<" followed by a "/"; anything else is a start symbol. Therefore, in FIG. 16, the document element name of the first level document element is "a", the start symbol is "<a>", and the end symbol is "</a>". Additionally, the second level document elements are:
The document element name is "b", and accordingly, the start symbol is "<b>" and the end symbol is "</b>". .

Next, the flow of processing in this embodiment will be explained. Similar to the first embodiment, this process is divided into two parts: document creation process and validity confirmation process. First, the flow of document creation processing will be explained using FIG. 12. First, the document creator inputs from the input device 1 the storage location (for example, file name) of the document data 211 to be input and the storage location of the signed document data 212 for validity confirmation that will be the processing result of this process, A document processing target is specified (step S1101). Next, the document creator inputs a document element name for a target document element using the input device 1, and stores it in the creation document element name 321 (step S1102). Then, by operating the character string extraction program 112, the character string in the corresponding document element in the document data 211 is extracted and stored in the creation target character string 302 (step S1103, details will be described later). .

Furthermore, the document creator inputs a password for the corresponding document element from the input device 1, stores it in the creation password 303 (step S1104),
Character string 30 to be created at the time of creation extracted in step S1103
2 and creation password 3 entered in step S1104.
From 03, create a code 305 for verifying validity at the time of creation (
Step S1105). This process is completely similar to the process in step S205 in FIG. 2 in the first embodiment.

Finally, using the association program 114, the corresponding document element and the creation validity confirmation code 305 are
(Step S1106, details will be described later), and the document creation process ends. The processing of the character string extraction program 112 in step S1103 in FIG. 12 will be described.

In FIG. 17, the range of character strings in the document data 211 used when creating data to be encrypted during creation is shown by broken lines. That is, it is a character string from the character immediately after the start symbol of the first level document element to the character immediately before the corresponding end symbol. The flow of processing is as shown in the flowchart of FIG. Regarding the identification of document elements in this example, in the explanation of the identification of document elements in the previous example, the start symbol "<" is read as "<x>" and the end symbol ">" is read as "</x>". It is the same as when rereading.

First, a start symbol of a first level document element having the same document element name as the document element name at the time of creation 321 is detected from the document data 211 (step S1201). If the document data 211 ends without being detected, it is displayed that there is no corresponding first-level document element (step S1202), and the process ends with an error. If detected in the middle, the character string from the character next to the start symbol to the character immediately before the corresponding end symbol is stored in the creation target character string 302 (step S1203). Above,
The description of the process in step S1103 ends.

The processing of the association program 114 in step S1106 in FIG. 12 will be described. Here, by inserting the creation validation code 305 into the end symbol of a predetermined first-level document element, the two are associated with each other. As in the first embodiment, the document creator may input directly from the input device 1, but an example of automatic input is shown below.

FIG. 18 shows an example of the coded document data 212 for verification. In the figure, “???????” is the validation code for the first level document element named “a”, and “!!!!!!” is the validation code for the first level document element named “c”. This is a code for verifying the validity of a document element. The flow of processing is shown in Figure 1.
As shown in 4.

First, the end symbol of a first-level document element having the same document element name as the document element name at creation 321 is detected from the document data 211 (step S1301). Then, the creation-time validity confirmation code 305 is inserted after the document element name in the end symbol with a blank character in between (step S1302). By performing such processing on all document elements, the document data 211 of this embodiment becomes document data 212 with a code for validity confirmation.

[0050] Here, an example of registering in the document data 211 has been described, but if this process changes the document data 212 with a validation code, the validation code is added in the end symbol. has already been inserted, so before the processing in step S1302 described above, it is sufficient to check whether the validation code has been inserted and, if it has been inserted, to delete it. This concludes the explanation of the process in step S1106.

Similar to the first embodiment, in the above example, the process in step S1105 is replaced by step S1103 and step S1.
Although this is performed after the end of step S104, step S1103
The extracted characters may be sequentially input to the character string conversion program 103 while performing the target character string extraction process. Next, the validity confirmation process will be explained using the flowchart of FIG. 15.

First, the document verifier (person in charge) determines the storage location of the signed document data 212 for validity verification to be verified.
is input from the input device 1 (step S1400). Subsequently, the document confirmer inputs the target document element name using the input device 1. The input document element name is stored in the confirmation document element name 326 (step S1401). next,
The character string extraction program 112 is used to extract the character string in the corresponding document element to be verified at the time of verification from the signed document data 212 for verification, and the extracted character string is incorporated into the character string to be verified at the time of verification 307 (step S1402).

[0053] The document verifier inputs the password corresponding to the document element name inputted earlier through the input device 1. This input password will be stored in the confirmation password 308 (step S1403). Next, a code is generated from the verification target character string 307 extracted in step S1402 and the verification password 308 input in step S1403, and the code is used as the verification validity verification code 310.
(Step S1404). This process
The process is exactly the same as the process of step S604 in FIG. 6 in the embodiment. Then, the end symbol of the first level document element having the same document element name as the verification document element name 326 input in step S1401 is detected from the signed document data 212 for validation, and the end symbol is detected from among the end symbols. The confirmation code is extracted and stored in the comparison code 311 (step S1405).

Finally, the verification code 310 created in step S1404 is compared with the comparison code 311 extracted in step S1405 (step S1406).
), if they match, it is valid, for example, the string “yes”
is written in the determination result 312 (step S1407). If they do not match in step S1406, a message indicating that it is not valid, for example, a character string "no" is written in the determination result 312 (step S1408). This completes the confirmation process.

Note that the process of the character string extraction program 112 in step S1402 in FIG.
This is the same process as 03. Therefore, in FIG. 13, the document data 211 is the coded document data for checking validity 212, and the document element name 321 at the time of creation is the document element name 3 at the time of confirmation.
26. Target character string 30 when checking target character string 302 when creating
7 can be replaced and explained in exactly the same way.

In this embodiment, although the validation code was inserted into the end symbol in the above example, it can easily be imagined that it could also be inserted into the start symbol. Further, although the case has been described in which the document delimiter includes only the document element name and the validity confirmation code, information such as attributes may also be included in the document delimiter. At this time, it is necessary to clearly distinguish between document element names, validation codes, and other information. For example, the second position in an end symbol, “<a own
er=nagasima date=1990.9.1
1 passwd=? ? ? ? ? >” etc. If you specify the position, insert a dummy validation code at the specified position when first creating the document data, and then All you have to do is replace it with the correct validation code during the tagging process.

As explained above, according to the second embodiment, the document element whose validity is to be confirmed can be specified by the name of the document element. 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.

The present invention may be applied to a system made up of a plurality of devices, or to an apparatus made up of one device. It goes without saying that the present invention can also be applied to a case where the present invention is achieved by supplying a program to a system or device. In addition, since document creation processing and document validity confirmation processing can be performed separately, document element number 3 at the time of creation
01, document element number at the time of confirmation 306, document element name at the time of creation 3
21, document element name at confirmation 326, target character string at creation 30
2, target string for confirmation 307, password for creation 303
, password 308 when confirming, data to be encrypted when creating 30
The same area may be used for each pair of 4 and the encrypted data at the time of confirmation 309, the code for verifying validity at the time of creation 305, and the code for verifying validity at the time of verification 310.

[0059]

[Effects of the Invention] As explained above, according to the present invention, 1
It is possible to provide a document processing device and method capable of confirming the validity of the entire target document element even if there are other document elements within one document element. It is also effective when verifying the validity of program sources.

[Brief explanation of the drawing]

FIG. 1 is a system configuration diagram in a first embodiment.

FIG. 2 is a flowchart related to document creation in the first embodiment.

FIG. 3 is a flowchart for explaining character string extraction processing in FIG. 2;

FIG. 4 is a flowchart for explaining code generation processing in FIG. 2;

FIG. 5 is a flowchart for explaining the association process in FIG. 2;

FIG. 6 is a flowchart related to document confirmation processing in the first embodiment.

FIG. 7 is a flowchart for explaining the character string extraction process of FIG. 6;

FIG. 8 is a diagram showing the contents of document data in the first embodiment.

FIG. 9 is a diagram showing a target range of extracted character strings in FIG. 8;

FIG. 10 is a diagram showing coded document data for validation in the first embodiment.

FIG. 11 is a system configuration diagram in a second embodiment.

FIG. 12 is a flowchart related to document creation in the second embodiment.

FIG. 13 is a flowchart for explaining character string extraction processing in FIG. 12;

FIG. 14 is a flowchart for explaining the association process in FIG. 12;

FIG. 15 is a flowchart related to document confirmation processing in the second embodiment.

FIG. 16 is a diagram showing the contents of document data in the second embodiment.

17 is a diagram showing a target range of extracted character strings in FIG. 16. FIG.

FIG. 18 is a diagram showing coded document data for validation in the second embodiment.

[Explanation of symbols]

1 Input device 2 CPU 3 Output device 10, 20, 30 Storage device 102 Creation character string extraction program 103 Character string conversion program 104 Correspondence program 105 Validity confirmation code extraction program 106
string comparison program

Claims (2)

[Claims] Claim 1: A document processing device that handles document data composed of a plurality of document elements, the apparatus comprising: a password setting means for setting a password for the document element; and a password setting means for setting a password for the document element; If there is a second document element, a character string extracting means for extracting a character string including the second document element, and a character string extracted by the character string extracting means and a password set by the password setting means. a code generating means for generating a code corresponding to the document element, a storage means for storing the code generated by the code generating means in association with the corresponding document element, and a desired document element. an input means for inputting information for the document and a password corresponding to the document element, and a code generating means for generating a code based on the character string obtained from the document element specified by the input information and the password,
A document processing device comprising: comparison means for comparing the code and the code stored in the storage means. 2. A document processing method that handles document data composed of a plurality of document elements, comprising: a password setting step of setting a password for the document element; and a step of setting a password in the document element corresponding to the set password. If there is a second document element, a character string extraction step that extracts a character string that also includes the second document element, and based on the character string extracted in the extraction step and the password set in the password setting step,
a code generation step of generating a code corresponding to the document element; a storage step of storing the generated code in association with the document element; and information for specifying the desired document element and the document element. an input step of inputting a password corresponding to the password, and a character string obtained from a document element specified by the input information and a code based on the password are generated in the code generation step, and the code and the code are stored in the storage step. 1. A document processing method, comprising: a comparison step of comparing the received code with the received code.