 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a method in a data processing system for
creating, registering and managing the document or program, wherein the
method includes determining whether or not the content of stored data is a
valid data which remains as created and stored by the authorized user, and
if improper rewrite is made, detecting the face that the rewrite has been
made.
2. Related Background Art
It is conventionally common practice that a document is created on a
computer, and stored as a file.
When this document file is used in the joint work by a plurality of users,
a method has been adopted in which under the operating system, the file is
shared among the plurality of users and other users are inhibited from the
access to the file.
For example, in a UNIX operating system, the permission for the write, the
reference (read), and the execution into each file can be given to the
owner of the file, the group of joint work, and other users.
In such a system, when a certain file is shared within the group, and the
users out of the group is inhibited from changing the file, a method is
taken in which the users within the group are permitted to write the file,
but the users out of the group are inhibited from writing, so that the
file can be shared only within the group.
However, with the conventional example, the permission for writing or
reading a certain file is only given the owner of file, the group and
other users. Also, the justification of the document is assured by
inhibiting the unauthorized user from writing or reading. Accordingly,
there were following problems.
1. It is not possible to meet a requirement of recognizing the rewrite if
any, although the rewrite by others is permitted.
2. When the group for dealing with each file is different, a number of
groups are created, in which the members of each group are registered, and
the group corresponding to each file belongs must be registered, so that
the management becomes very complicated.
3. When the rewrite by the super user (user having all rights for any file)
or the false rewrite by the authorized user is made, there is no
indication for the alteration.
SUMMARY OF THE INVENTION
An object of the present invention is to provide a method for determining
whether or not the content of stored data is a valid data which remains as
created and stored by the authorized user, and detecting the fact that the
improper rewrite, if any, has been made.
Another object of the present invention is to provide a data processing
method for determining whether or not the improper rewrite of processed
data has been made, and inhibiting the execution of the processing if the
improper rewrite is made.
Another object of the present invention is to make the operation simpler
when repeating the above-mentioned determination for a plurality of data.
Another object of the present invention is to store the determination
information for the above-mentioned determination and make the management
simpler.
According to one aspect, the present invention which achieves these
objectives relates to a method for determining whether or not the improper
rewrite of stored data has been made, comprising steps of in storing the
data, inputting a password, generating a first code by converting the
input password and the stored data in a predetermined procedure, storing
the first code in correspondence to the stored data, and in reading the
stored data, inputting the password, generating a second code by
converting the input password and the stored data in the predetermined
procedure, comparing the generated second code and the first code stored
in correspondence to the stored data, and determining that the improper
rewrite has been made if the comparison result is unmatched.
According to another aspect, the present invention which achieves these
objectives relates to a method for determining whether or not the improper
rewrite of stored data has been made, comprising steps of in storing the
data, storing the data with a storing time appended, inputting a password,
extracting the storing time from the stored data, generating a first code
by converting the input password and the extracted storing time in a
predetermined procedure, storing the first code in correspondence to the
stored data, and in reading the stored data, inputting the password
extracting the storing time from the stored data, generating a second code
by converting the input password and the extracted storing time in the
predetermined procedure, comparing the generated second code and the first
code stored in correspondence to the stored data, and determining that the
improper rewrite has been made if the comparison result is unmatched.
According to another aspect, the present invention which achieves these
objectives relates to a method for determining whether or not the improper
rewrite of stored data has been made, comprising steps of in storing the
data, storing the data with a first storing time appended, inputting a
password, extracting the first storing time from the stored data,
generating a first code by converting the input password and the extracted
first storing time in a predetermined procedure, restoring the data with
the generated first code appended distinguishably, changing a second
storing time appended to the restored data to the first storing time, and
in reading the stored data, inputting the password, extracting the first
storing time from the stored data, generating a second code by converting
the input password and the extracted first storing time in the
predetermined procedure, comparing the generated second code and the first
code appended to the stored data, and determining that the improper
rewrite has been made if the comparison result is unmatched.
According to another aspect, the present invention which achieves these
objectives relates to a method for determining whether or not the improper
rewrite of stored data has been made, comprising steps of in storing the
data, storing the data with a first storing time appended, inputting a
password, inputting the time information, generating a first code by
converting the input password and the time information in a predetermined
procedure, restoring the data with the generated first code appended
distinguishably, changing a second storing time appended to the restored
data to the time information, and in reading the stored data, inputting
the password, extracting the time information from the stored data,
generating a second code by converting the input password and the
extracted time information in the predetermined procedure, comparing the
generated second code and the first code appended to the stored data, and
determining that the improper rewrite has been made if the comparison
result is unmatched.
According to another aspect, the present invention which achieves these
objectives relates to a method for determining whether or not the improper
rewrite of stored data has been made, comprising steps of in storing the
data, determining the user, generating a first code by converting the
information corresponding to the determined user and the stored data in a
predetermined procedure, storing the first code in correspondence to the
stored data, and in reading the stored data, determining the user,
generating a second code by converting the information corresponding to
the determined user and the stored data in the predetermined procedure,
comparing the generated second code and the first code stored
corresponding to the stored data, and determining that the improper
rewrite has been made if the comparison result is unmatched.
According to another aspect, the present invention which achieves these
objectives relates to a method for determining whether or not the improper
rewrite of stored data has been made and making the processing in
accordance with the determined result, comprising steps of in storing the
data, inputting a password, generating a first code by converting the
input password and a predetermined portion of the stored data in a
predetermined procedure, storing the first code in correspondence to the
stored data, and in processing the stored data, inputting the password,
generating a second code by converting the input password and the
predetermined portion of the stored data in the predetermined procedure,
comparing the generated second code and the first code stored in
correspondence to the stored data, and executing the processing if the
comparison result is matched, and prohibiting the execution of the
processing if the comparison result is unmatched.
Other objectives and advantages besides those discussed above shall be
apparent to the those skilled in the art from the description of a
preferred embodiment of the invention which follows. In the description,
reference is made to accompanying drawings, which forms a part thereof,
and which illustrate an example of the invention. Such example, however,
is not exhaustive of the various embodiments of the invention, and
therefore reference is made to the claims which follow the description for
determining the scope of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a system configuration diagram in the first example.
FIG. 2 is a flowchart for a document creating and registering process in
the first example.
FIG. 3 is a flowchart for a code generating process in the first example.
FIG. 4 is a flowchart for a justification identification process in the
first example.
FIG. 5 is a system configuration diagram in the second example.
FIG. 6 is a flowchart for a code generating process in the second example.
FIG. 7 is a system configuration diagram in the third example.
FIG. 8 is a flowchart for a correspondence process in the third example.
FIG. 9 is a view showing an example of document data with a justification
identification code appended.
FIG. 10 is a flowchart for a code generating process in the third example.
FIG. 11 is a flowchart for a comparison process in the third example.
FIG. 12 is a system configuration diagram in the fourth example.
FIG. 13 is a flowchart for a correspondence process in the fourth example.
FIG. 14 is a diagram showing the transition of time stamp in the fourth
example.
FIG. 15 is a system configuration diagram in the fifth example.
FIG. 16 is a flowchart for a code generating process in the fifth example.
FIG. 17 is a flowchart for a correspondence process in the fifth example.
FIG. 18 is a diagram showing the transition of time stamp in the fifth
example.
FIG. 19 is a system configuration diagram in the sixth example.
FIG. 20 is a flowchart for a document creating and registering process in
the sixth example.
FIG. 21 is a flowchart for a code generating process in the sixth example.
FIG. 22 is a flowchart for a justification identification process in the
sixth example.
FIG. 23 is a system configuration diagram in the seventh example.
FIG. 24 is a flowchart for a document creating and registering process is
the seventh example.
FIG. 25 is a flowchart for a code generating process in the seventh
example.
FIG. 26 is a flowchart for a justification identification process in the
seventh example.
FIG. 27 is a flowchart for a log-in directory fetching process.
FIG. 28 is a flowchart from the justification identification process to the
print process in the eighth example.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
First Example
An example of the present invention will be described with reference to the
drawings.
FIG. 1 is a diagram showing a system configuration of this example.
1 is a console having a device for the input to a computer (e.g., keyboard)
and a device for the display of a response from the computer (e.g., CRT).
2 is a CPU for controlling each device via a bus 4 and executing various
processes with processing programs stored in a program memory 10, and 3 is
an output device for the print-out or the display on to a screen.
20 is a data memory such as FD or HD for storing a document data or a
justification identification code file 23 as thereinafter described in the
file format. 30 is a main memory composed of RAM or the like, in which an
input password 31, a justification identification code 32 as thereinafter
described, a determined result 33, time stamp + password 34, and a
comparison code 35 are stored, and comprising various work areas for use
in editing the document, for example. 10 is a main memory composed of ROM
or the like for storing various processing procedures including the
processing procedures corresponding to the flowcharts as shown in FIG. 2
to FIG. 4, herein referred to as a program memory. Note that it is
unnecessary for these memories 10, 20, 30 to be physically separate.
Note that in the above and below, the content of data and the area on the
memory for storing its data are not distinguished on the identification
and the reference number, as long as particularly there is no trouble.
Next, the processing flow of this example will be described. The processing
is largely divided into two parts of creating and registering the document
and identifying the justification for the content.
FIG. 2 is a flowchart showing the flow of a document creating and
registering process.
First, at step S21, the document creator created and edits a document using
a console 1, and stores it into the document data 21 as a file. This is
generally performed with a document creating/editing device called an
editor.
With the above operations, the document data 21 stored in the memory 20 has
a time stamp (final update time) at the time of creating the file
appended. This is automatically performed by the operating system such as
a unix.
Next, at step S22, a password of the document creator is obtained. Here,
the document creator is requested to input the password through the
console 1, and the password input therethrough is stored in the password
31 in the memory 30.
Next, at step S23, the time stamp appended to the file and the password is
encoded to generate a justification identification code. This time stamp
and the password may be only a byte train, rather than a character train.
This code generating process will be described using the flowchart of FIG.
3.
First, at step S31, the time stamp of the document data 21 and the password
31 are stored in time stamp + password 34 as a series of character train.
At step S32, the time stamp + password is encoded. This encoding means can
be implemented with the same algorithm as in the encoding of password in
unix, for example. This is to convert a character train into another
character train with a method virtually not allowing the inverse
conversion.
If this method only accepts the fixed-length character train (e.g., eight
bytes), and the time stamp + password contains a character train exceeding
that fixed-length, that character train needs to be made the fixed-length
in the following way.
First, the time stamp + password is separated into each eight bytes.
Next, the exclusive OR (exclusive OR: EX-OR) thereof is taken sequentially.
(The EX-OR of the first eight bytes and the next eight bytes is taken, and
then the EX-OR of its result and the next eight bytes is taken. The
following is continued in the same way.) If the remainder separated lastly
is less than eight bytes, a measure for fill up the deficient bytes with
blanks, for example, is taken.
With such a measure, the eight byte code can be eventually obtained. This
is converted into a printable character code. In doing do, the
inappropriate code (e.g., a line feed code) is appropriately converted.
Encoding this character code allows an encoded character train specific to
the document to be obtained.
Note that this encoding is not to limit the input or output to the
character train, but may be handled only as the byte train.
The code generated therein is called a justification identification code,
and stored in the justification identification code 32 of the memory 30.
At this time, the justification identification code 32 may be displayed on
the console 1.
With the above operation, the code generating process is completed.
Next, at step S24 in FIG. 2, a correspondence process of the created
document to the justification identification code is performed.
In this example, the justification identification code is stored in a file
having an expander appended after the document name. That is, if the
created document is a file with identified as "text", the justification
identification code is stored in the justification identification code
file 23 with a file name of "text.code". Thereby, the created document
data file and the justification identification code file, in the mutually
corresponding form, are stored in the memory 20.
The above operation is a process for creating and registering the document.
Subsequently, a justification identification process for confirming that
the document thus registered is the same as at the time of creation will
be described using the flowchart of FIG. 4.
In the memory 20, the document data file 21 and the file containing the
justification identification code or the justification identification code
file 23 are already stored.
First, at step S41, the file name for the identification is specified from
the console 1. Next, at step S42, the password is input from the console 1
and stored in the password 31 of the memory 30.
Next, at step S43, the justification identification code is generated from
the time stamp of the file of interest and the input password in the same
procedure as at step S23 in FIG. 2, and stored in the justification
identification code 32 of the memory 30. This justification identification
code 32 is newly generated, and is different from the justification
identification code 32 generated in the document creating and registering
process.
Next, at step S44, the content (character train) of the justification
identification code file 23 corresponding to the specified document data
is read into the comparison code 35, for the comparison between the code
35 and the content (character train) of the justification identification
code 32 generated herein. Its result is identified as yes if they are
equal, or otherwise no, for example, and stored in the decision result 33.
At step S45, it is displayed as the character train of "yes" or "no" on
the console 1 or a screen of the output device 3. Of course, this display
may be arbitrarily made if the decision result can be distinguished. Also,
this comparison result may be used as an input into a certain process.
Thereby, if the time stamp at the time of creation and the current time
stamp which is lastly updated are coincident, and the password input at
the time of creation and the current password are coincident, the document
is determined as a valid (unaltered) one.
Accordingly, even if the update of document is made detectable with the
change of the time stamp, and the content (code) of the justification
identification code file 23 is rewritten with the time stamp at that time
in some way in updating the document, the alteration of the document can
be detected unless the same password as at the creation is not used in
generating the code (i.e., the password is not known).
The above operation is the justification identification process.
With the above-described operation, it is possible to create and register
the document in the form of allowing for the justification identification
in later time, and confirm whether or not the document data is rewritten
after the creation.
In this example, if the document is altered (or the time stamp is changed)
after its registration even for once, the document is decided as
"invalid".
Second Example
A second example of the present invention will be described.
In the first example, the justification identification code was generated
from the time stamp appended to the document data file and the password
input by the user, while in the second example, the justification
identification code is generated from the character train which is a
content of the document data file and the password input by the user.
Thereby, there is the advantage that the file can be decided as "valid" if
the content of the document itself is not altered even though the file is
updated (for example, the time stamp is changed as the file has been
copied to another directory).
FIG. 5 is a diagram showing the system configuration in the second example.
The hardware constitution is not changed from that of FIG. 1, but the
content of the memory is different in part. Specifically, the program
memory 10 stores a processing procedure as shown in FIG. 6, instead of
that of FIG. 3, and the main memory 30 is provided with text content +
password 36, instead of time stamp + password 34 in FIG. 1.
Next, the processing flow of this example will be described. This example
is also divided into two sections of a document creating/registering
process and a justification identification process.
The processing flow of document creating/registering process is in
accordance with FIG. 2.
The flow from step S21 to step S22 is the same as in the first example. As
the code generating process at step S23 is different from the first
example, the flow of the code generating process in this example will be
described with reference to FIG. 6.
First, at step S61, the document content of the text data 21 and the
password 31 are stored as a series of character train into text content +
password 36. Note that the password and the text content may not be the
character train but only the byte train.
Next, at step S62, the text content + password 36 is encoded. This encoding
procedure is the same as in the first example.
The generated code (justification identification code) is stored in the
justification identification code 32 of the memory 30.
The above operation is the code generating process.
Next, at step S24, the correspondence process of the justification
identification code 32 to the text data 21 is executed, in the same way as
in the first example.
The above operation is the document creating/generating process.
Subsequently, the justification identification process for confirming that
the document thus registered is the same as created.
This process is basically the same as in the example 1, and in accordance
with FIG. 4.
However, the processing at step S43 is different in that the justification
identification code is generated from the text content of the file of
interest and the password input at step S42, in the same procedure as at
step S61 and S62.
In this example, there is the effect that even if the created document file
is rewritten by someone after the registration, it can be decided as valid
if the content is restored eventually. This is effective when it is only
necessary that the document content is the same. This is also effective
because it can be confirmed that the document content is the same as
original even if the owner or the file updating data is changed.
Third Example
In the first and second examples as above described, the justification
identification code is provided as a file independent of the corresponding
document file, while in the third example, the document data and the
justification identification code thereof are stored in the same file.
FIG. 7 is a system configuration diagram in the third example.
The hardware constitution is not changed from that of FIGS. 1 and 5, but
the content of the memory is different in part. Specifically, the program
memory 10 stores a processing procedure as shown in FIGS. 2, 4, 8, 10 and
11, and the main memory 30 is the same in FIG. 5, but the data memory 20
does not have the justification identification code file.
Next, the processing flow of this example will be described. In this
example, the process is also divided into two selections of a document
creating/registering process and a justification identification process.
The processing flow of document creating/registering process is in
accordance with FIG. 2, like the previous examples.
In this example, like the second example, the justification identification
code 32 is generated from the text content and the input password.
The feature of this example is a correspondence process as at step S24.
The correspondence process of the created document to the justification
identification code will be described with reference to FIG. 8.
By the time of this step, the document data and justification
identification code are stored in the text data 21 and the justification
identification code 32, respectively.
In this example, the text data and the justification identification code
are stored in one file in the form of being distinguishable from each
other (for example, a punctuation symbol is interposed therebetween as
shown in FIG. 9). At step S81, a specific text punctuation symbol, for
example, a line only consisting of a character train of <*code*>, is
appended to the file end of the text data.
Here, if the character train of <*code*> is used in the document, rather
than as the text punctuation symbol, care must be taken out to have the
line only consisting of the character train of <*code*>. At step S82, the
justification identification code 32 is further appended to the file end
of the text data 21.
With the above operation, in the text data 21, the content of original
document, and the justification identification code thereof exist in one
file so as to be distinguishable with the text punctuation symbol of
<*code*>.
Thus, step S24 is finished. The above operation is the document
creating/registering process.
Subsequently, the process for confirming that the document is the same as
created will be described.
This process is in accordance with FIG. 4, like the previous examples.
In this example, the text data file (including the justification
identification code for that text) is already stored in the memory, when
starting this process.
First, the steps S41 and S42 are the same as in the previous examples.
Next, in the code generation at step S43, the justification identification
code is generated from the text data file 21 of interest and the password
31, with the encoding, and stored in the justification identification code
32.
This code generating process will be described with reference to FIG. 10.
This process is slightly different from the code generating process
performed at the time of creating and registering the document.
First, at step S101, the character train just before the punctuation symbol
<*code*> in the text data 21 and the character train stored in the
password 31 are stored in text content + password 36 as a series of
character train.
Next, at step S102, the text content + password 36 is encoded, and stored
in the justification identification code 32. Here, the encoding method for
the character train may be the same as in the previous examples.
Thus, the code generating process at step S43 has been described.
Next, at step S44, the comparison between the content (character train) of
the justification identification code created beforehand and stored in the
same file as the text data and the content (character train) of the
justification identification code 32 created at step S43 is made.
This process will be described with reference to FIG. 11.
At step S111, the text data in the text data file from immediately after
the text punctuation symbol until the file end is read and stored in the
comparison code 35 of the memory 30.
At step S112, the comparison between the content of the comparison code 35
and the content of the justification identification code 32 is made, in
which yes if equal and no if otherwise is stored in the decision result
33.
The above operation is the comparison decision process at step S44.
Next, at step S45, the content of the decision result 33 is displayed on
the console 1 or the screen of the output device 3, for example, as the
character train of "yes". Also, this may be used as the input into a
certain process.
Thus, the justification identification process is completed.
In this example, there is the same effect as in the second example because
the text content is used for the generation of the justification
identification code, and there is a further effect that the file
management can be facilitated by making the text data and the
justification identification code in one file.
With the present invention, there is provided the effect that it can be
confirmed whether or not the text content has been rewritten for a text
file, as above described.
Fourth Example
When the code is created from the input password and the last updated time
of the text, as in the first example, the addition of the code is the
update of the text data if the justification identification code including
the time and the text data are stored in the same text data, as in the
third example, so that the time information (last update time at the code
generation) in the justification identification code and the time stamp
(update time of appending the generated code) in the text data are
inconsistent, whereby there is the problem that even if the confirmation
is made in this state, the rewrite is always determined, and it can not be
decided whether or not the improper rewrite has been made.
In this example, the justification identification code and the text are
stored in the same text in the form of being distinguishable from each
other, in which the time stamp of the created document is made coincident
with the time in the code, so that the consistency with the time
information contained in the code is retained to allow the code for
confirming the alteration of the text content to be stored in the same
file as the text.
FIG. 12 is a system configuration diagram in this example.
It is different from FIG. 1 in the content of the program memory 10 and in
that a regular time stamp 37 as will be described later is provided in the
main memory 30.
Next, the processing flow of this example will be described. The process is
also divided into two sections of a document creating/registering process
and a justification identification process for the text content.
The processing flow of document creating/registering process is in
accordance with the flowchart of FIG. 2, like the previous examples.
In the flow, the process up to the code generation is the same as in the
first example, and the explanation will be described.
Next, at step S24, the process of creating the text data 21 including the
justification identification code 32 by appending the justification
identification code 32 to the document data 21 is performed.
The correspondence process will be described with reference to FIG. 13.
Before the step S24, the document data 21 and justification identification
code 32 are stored. In this example, the text data followed by the
justification identification code is stored in one file in the form of
being distinguishable | | |
