JP2011198285A - Document processing system and program - Google Patents

Abstract

A method for improving the efficiency of correcting a character string generated when a paper document is digitized is proposed.
A document processing system according to the present invention determines whether or not a character string to be corrected is displayed on a character string correction screen, and has a function for displaying an alert for the character string to be corrected, and a character string. When correcting, it has a function of suggesting a candidate character string. When determining whether or not to perform an alert, morphological analysis, registered character string, dictionary, consistency with already registered data, and the like are utilized. The character string to be suggested is characterized by utilizing a similarity with an already registered character string or a dictionary, a value range or a character string calculated based on already registered data.
[Selection] Figure 4

Description

  The present invention relates to a document processing system and a program, for example, to a technique for efficiently correcting a metadata character string obtained by performing scan / OCR on a paper document.

  In many organizations such as companies, a large amount of data such as files created by office software and files scanned from paper documents is generated daily and stored in a file server or the like. When searching for a desired file from such a large amount of data, it is common to find it by tracing a folder in the file server. However, when the folder structure is complicated, or when it is organized as a folder in a structure unintended by a person who wants to search for a file, it takes a very long time to search for a desired file. As another method for searching for a file, there is a method using a full text search, which also has two problems.

  One is that there are files that cannot be found only by keyword search (see FIG. 1). For example, when all documents within a certain period are to be searched, a full-text search cannot be performed because a character string of a date in the document cannot be handled as “date data”. As another example, there is a problem that when a keyword that the searcher wants to search and another word / phrase are used as the same meaning, it cannot be searched.

  The other is that a large number of unrelated files are hit (see FIG. 2). For example, if you search with the intention of finding a bank as a customer, the same number as the ID is written in the amount etc. if it is also written in the transfer destination of another file or if you search based on an ID such as an estimate number This is the case. The problem resulting from these full-text searches is that the keywords in the document are not treated as meaningful characters.

  Therefore, a method of managing document metadata (attribute information) in association with a document has been considered. For example, Patent Document 1 proposes a virtual folder system. The virtual folder system is performed by setting metadata in a file and defining a search condition for the metadata in the virtual folder. At the time of referring to the virtual folder, a file search result based on the search condition is presented, thereby realizing classification according to the search condition. For example, in the case of managing sales documents, “document type name” (contract, order form, estimate, etc.) and “draft date” are set as metadata for all files, and “document type” is set in the virtual folder. If a search condition “name is“ contract ”” is assigned, a list of contracts can be acquired by referring to the virtual folder. Similarly, if a virtual folder is assigned with “the draft date is from January to March 2009”, documents in a specified period can be collected. As described above, since the virtual folder system classifies files semantically, documents can be effectively used.

When scanning a paper document to register the character data, how to use the OCR (O ptical C haracter R eader ) are common. For example, when a form with a fixed format (fixed form) is digitized, the type and position coordinates of the character string to be filled in beforehand are defined, and the character string within the defined position coordinates is defined. Some types of metadata may be stored. FIG. 3 shows an example of a fixed form. A position where a document type, a customer name, a draft date, and a case ID are to be entered is defined, and a form is created so that the character string is written at this position. When the printed fixed form is digitized, the character string is recognized based on the definition of the fixed form and stored as metadata.

  The metadata is corrected with reference to the original document. Many document management products have a metadata registration screen, and the user manually corrects the metadata while viewing the document.

JP 2003-323326 A

  OCR may misrecognize characters because its recognition rate is not 100%. Therefore, it is necessary for the user to check whether or not the character is misidentified and to correct the character correctly.

  The present invention has been made in view of such a situation, and provides a technique for efficiently performing a correction operation of a metadata character string obtained through scanning / OCR on a paper document. is there.

  In order to solve the above problems, in the document processing system of the present invention, data to be corrected on the metadata correction screen when the metadata obtained through scanning / OCR is corrected for a paper document. Is calculated / displayed (alert function), and corrected data candidates are calculated / displayed (suggest function).

  The alert function can be realized by performing morphological analysis on the target character string and the result. Moreover, the dictionary DB prepared for each metadata type and / or the DB in which the already registered character string is stored are compared with the processing target data (target character string), and an alert is displayed based on the comparison result. It may be determined whether or not correction is necessary. Further, it may be determined whether or not the processing target data matches a predefined format, and it may be determined whether or not to display an alert based on the result (whether correction is necessary). Also, compare the data to be processed with the data that has already been registered, and based on the result of the comparison (such as a conflict in the context of the document creation date and time), determine whether or not to display an alert (need to modify) Also good. In addition, it is determined whether or not there is a contradiction in the relationship (subordinate relationship) between the data to be processed and the related data and the relationship (subordinate relationship) between the already registered data and the related data. Based on the result, it may be determined whether an alert is displayed (correction is necessary) or not.

  The suggest function realizes displaying a correct character string candidate, a correct format, and a correct value (date and time) range according to the type of correction cause determined by the alert function.

  Further features of the present invention will become apparent from the following detailed description and the accompanying drawings.

  According to the present invention, it is possible to easily find a character string to be corrected from character strings obtained by performing scan / OCR on a paper document, and to easily set a character string to be corrected. It becomes possible to do. Thereby, it becomes possible to perform a user's character string correction work efficiently.

It is a figure which shows the example which cannot find a file by full text search (keyword search). It is a figure which shows the example which an irrelevant file hits by a full text search (keyword search). It is a figure which shows an example of the metadata setting of a fixed form. It is a figure which shows schematic structure of the character string correction system (document processing system) which concerns on embodiment of this invention. It is a figure which shows an example of a metadata item setting file. It is a figure which shows an example of metadata. It is a figure which shows an example of dictionary data. It is a figure which shows an example of a correction screen. It is a flowchart for demonstrating the whole outline | summary of an alert determination process. It is a flowchart for demonstrating the detail of the process (step 907) which determines the necessity for correction | amendment in an alert determination process. It is a figure which is an example of the data which is a morphological analysis result and manages an error flag. It is a figure which shows an example of a morphological analysis result. It is a figure which shows an example (1) of the registered data of the same case ID. It is a figure which shows an example (2) of the registered data of the same case ID. It is a figure which shows an example of an alert result. It is a flowchart for demonstrating the detail of a suggestion process. It is a figure which shows an example (1) of a suggestion result. It is a figure which shows an example (2) of a suggestion result. It is a figure which shows an example (3) of a suggestion result. It is a figure which shows an example (4) of a suggestion result.

  A character string correction technique according to an embodiment of the present invention will be described below with reference to the accompanying drawings. However, it should be noted that this embodiment is merely an example for realizing the present invention and does not limit the technical scope of the present invention. In each drawing, the same reference numerals are assigned to the common components.

<Configuration of character string correction system>
FIG. 4 is a diagram showing a schematic configuration of a character string correction system (document processing system) according to the embodiment of the present invention. The character string correction system includes a scan data DB 401 that stores a scanned image obtained by performing scan / OCR on a paper document in advance and character string data of the scanned image, and a metadata DB 402 that stores metadata extracted from the scan data. , A dictionary DB 403 that stores a large number of character strings that can be metadata, a morpheme analysis DB 404 that stores a dictionary used for morpheme analysis, and a metadata item setting file 405 that contains metadata definitions (specific contents) 4), a parameter setting file 406 in which threshold values and various parameters are described, a display device 407 for displaying search results and metadata setting screens, data input, editing, menu selection, etc. A keyboard 408 for operating and a pointing device 409 such as a mouse; It has required processing, the central processing unit 410 that performs control processing and the like, the.

  The scan data DB 401, metadata DB 402, dictionary DB 403, and morpheme analysis DB 404 are targeted even when there are a plurality of DB (database) entities instead of physically one. The metadata DB 402 includes not only confirmed metadata but also undetermined metadata. Therefore, only unconfirmed metadata is extracted and displayed on the correction screen.

  The central processing unit 410 includes a correction screen display unit 411 that displays a screen for correcting metadata in the metadata DB 402, and a correction target that calculates a character string to be corrected from the metadata in the metadata DB 402. The calculation unit 412 and the correction screen display unit include a correction candidate calculation unit 413 that calculates a corrected character string candidate for the metadata selected by the user. The correction target calculation unit 412 and the correction candidate calculation unit 413 operate in the background. The programs used in the processing unit, data, processing unit, etc. described above may be provided by being stored in various recording media such as a CD-ROM, DVD-ROM, MO, floppy disk, USB memory, etc. it can.

<Metadata item settings file>
FIG. 5 is an example of a setting file for metadata items of a fixed form. Fig. 5 shows text data in XML format. Each metadata item name (item), data type (type), description format (define), description range (upper left, lower right), order relation (constraint order), order Each information of the formula (order) and the dependent item (dependent item) is described. The item tag represents the type of each metadata. The type tag represents the data type of metadata. For example, String represents a character string type and indicates that character string data is stored. Int represents an integer type and indicates that integer data is stored. Date represents a date type and indicates that date data is stored. Each data can also be combined. For example, String + Int indicates data obtained by combining character string data and integer data. Each type is connected with the "+" operator. Data can also be expressed in regular expressions. The data at that time is defined by the following define tag. The upper left tag and lower right tag represent the description range of the metadata on the form. The upper left tag represents the upper left coordinates of the description range, and the lower right tag represents the lower right coordinates of the description range. In the document management system, metadata is stored based on such a definition.

<Metadata>
FIG. 6 is a diagram illustrating an example of metadata in the metadata DB 402. In the present invention, a file in which metadata is registered is managed here together with the metadata. Therefore, it is assumed that a file whose metadata is not registered is not registered here.

  As shown in FIG. 6, the data in the metadata DB 402 is managed in a table format, and one file corresponds to one line. The table includes, as configuration items, an ID 601 that uniquely identifies the file, a state 602 that indicates whether or not the metadata is confirmed, a file path 603 of the corresponding file, and metadata 604 registered in the corresponding file.

  The metadata 604 forms a column for each metadata item managed by this system. In the example of FIG. 6, there are a document type name 605, a customer name 606, a draft date 607, and a case ID 608 as metadata items. In FIG. 6, some cells contain character errors.

<Dictionary data>
FIG. 7 is a diagram illustrating an example of dictionary data in the dictionary DB 403. The dictionary data is composed of a text file that collects a list that can be a metadata character string for each metadata item, and is registered in the DB in advance. A collection of metadata keywords in the metadata item “document type name” is registered in “document type name.txt”, and a collection of keywords in the metadata item “customer name” is registered in “customer name.txt”. An example is shown. As shown in FIG. 7, a new line is entered for each keyword.

  In addition to the document type name and customer name, dictionary data composed of product names, project names, and the like are also conceivable, but are not limited thereto.

<Correction screen>
FIG. 8 is a diagram illustrating an example of a correction screen created and displayed by the correction screen display unit 411. In the correction screen, in addition to the metadata displayed in a tabular format on the GUI window, a correction execution menu 801 that is pressed when processing is executed, and a processing check box that selects whether or not to execute correction of each row. 802.

  When this screen is activated from the system, the correction screen display unit 411 displays a list of metadata whose status is “indeterminate” and automatically displays a cell to be corrected with an alert. In addition, the cell in which the metadata is described is editable. When the user selects each cell, the correction candidate calculation unit 413 calculates a correction candidate character string candidate in response to the selection operation, and the correction is performed. The screen display unit 411 may display the candidate, or the correction screen display unit 411 may display a pop-up indicating the metadata format or value range. As a result, the user can efficiently perform the character string correction work. When the correction execution menu is selected after the user corrects the character string in each cell, the metadata in which the processing check box 802 is checked is updated, and the state becomes “confirmed”.

<Alert judgment processing>
The alert determination process is executed at the timing when the correction screen of FIG. 8 is displayed and at the timing when the character string in the cell is updated on the correction screen of FIG.

  FIG. 9 is a flowchart showing an outline of the process in the case where the alert determination process executed by the correction target calculation unit 412 is executed at the timing when the correction screen is displayed.

  In step 901, the correction target calculation unit 412 stores the number of metadata unconfirmed data in the variable N. The initial value of N is the number of data (number of files) displayed on the metadata correction screen. For example, the screen of FIG. 8 has a scroll bar so that not all of the data is displayed, but all data displayed on the screen is targeted regardless of whether or not there is a check. If there is no scroll bar in FIG. 8, N = 4.

  In step 902, the correction target calculation unit 412 determines whether N is 0 or not. If it is 0, it indicates that there is no data to be processed, and the process proceeds to step 910. If not 0, the process proceeds to Step 903.

  In step 903, the correction target calculation unit 412 selects one piece of metadata unconfirmed data. This data is F.

  In step 904, the correction target calculation unit 412 stores the number of processing target metadata items in the variable M. For example, M is 4 in the example of FIG. In step 905, it is determined whether M is 0 or not. If 0, it indicates that there is no processing target metadata item, and the process proceeds to step 909. If not 0, the process proceeds to Step 906.

  In step 906, the correction target calculation unit 412 selects one processing target metadata in F. Let this data be G.

  In step 907, the correction target calculation unit 412 determines whether or not G needs to be corrected. Details of step 907 will be described in detail with reference to FIG.

  In step 908, the correction target calculation unit 412 decrements M. In this way, loop processing is performed until M becomes zero.

  In step 909, the correction target calculation unit 412 decrements N. Similar to M, loop processing is performed until N becomes 0.

  When the loop process for N is completed, in step 910, the correction target calculation unit 412 displays an alert with metadata according to the error flag set in step 907.

<Judgment process for necessity of correction>
FIG. 10 is a flowchart for explaining the details of the process for determining whether or not the correction is necessary in step 907 in FIG.

  When metadata (P) for determining whether or not correction is necessary is read, in step 1001, the correction target calculation unit 412 checks the data type of P. If the data type is the string type, the process proceeds to step 1003. The string type is a data type representing a character string. If it is not the string type, the process proceeds to step 1002.

  In step 1002, the correction target calculation unit 412 checks the format of P. The data is collated with the metadata format in the metadata item setting file 405, and if it is correct, the process proceeds to step 1005. If not correct, processing proceeds to step 1006.

  In step 1003, the correction target calculation unit 412 compares P with the character string data of the metadata item in the dictionary DB 403 and the character string data of the metadata item in the metadata already registered in the metadata DB 402. . As a result, if there is a completely matched character string, the process proceeds to step 1007. If there is no exact character string, the process proceeds to step 1004. Since the identity with the confirmed character string data stored in the metadata DB 402 is also checked, a character string that is not in the dictionary DB but is determined to be correct in the processing so far is not subject to correction again. .

  In step 1004, the correction target calculation unit 412 performs morphological analysis on P. As a result of the morphological analysis, if an undefined word is included in a certain amount or more, the process proceeds to Step 1006, and the correction target calculation unit 412 sets the error flag to “STRING” (an error flag indicating that the character string has an error). The error flag is set to be described later. If undefined words are not included in a certain amount, the process proceeds to step 1007. The threshold value at this time can be freely set according to the state of the document, the environment, and the like. This threshold value is stored in the parameter setting file 406.

  Here, morphological analysis will be described. FIG. 12 is a diagram illustrating an example of a morphological analysis result. The morpheme analysis result is composed of items of a target character string, a morpheme character string, and a part of speech. For example, “Nishitozuka ≠ Capital” is decomposed into “West”, “Totsuka”, “≠”, and “Capital” as a result of the morphological analysis. When performing morphological analysis, dictionary data in the morphological analysis DB 404 is used. This dictionary stores word and part-of-speech data. As a result of the morphological analysis, if the word is a dictionary registered word, the part of speech data exists, but if it is not a dictionary registered word, there is no part of speech data. In general, since a character string accurately recognized by OCR is a meaningful character string, it is unlikely that an undefined word is included. However, there is a high possibility that the character string misrecognized by OCR contains many undefined words.

  In the present invention, this phenomenon is used as a material for determining whether or not it is erroneous recognition. “Nishitozuka ≠ Capital” is such a character string because the original character string is “Nishitozuka Capital” but OCR misrecognized it. If it is recognized as “Nishitozuka Capital”, the result of morphological analysis is decomposed into “West”, “Totsuka”, and “Capital”, all of which are composed of words registered in the morphological analysis DB. In the case of “Nishitozuka ≠ capital”, the morphological analysis result is as shown in FIG. 12, and includes undefined words. This can be regarded as a character string to be corrected.

  In step 1005, the correction target calculation unit 412 determines the validity of the metadata order relationship. The correctness of the order relation is determined in terms of whether or not metadata having regularity in order among related data is based on a correct rule. For example, in the business voucher, there are a plurality of documents in the same case, for example, an estimate, an order, an invoice, and the like. These documents are usually generated in the order of quotation, order, and invoice. Therefore, the draft date of these documents is the order from the old document to the estimate, order, and invoice. If the draft date of these documents is not in this order, it can be considered as mis-recognized metadata for reasons such as OCR misrecognition. In order to determine the validity of the order relationship, first, the metadata item setting file 405 is referred to, and it is determined whether or not the “constraint order” tag is included in the metadata item being processed. If not included, the correction target calculation unit 412 determines that the order relationship is correct, and advances the processing to step 1007. If included, the correction target calculation unit 412 further checks the validity of the order relationship. If it is correct, the process proceeds to step 1007, and if it is incorrect, the process proceeds to step 1006, and the correction target calculation unit 412 sets the error flag to “ORDER”. In order to check the order relationship, first, the “group item” tag, the “order item” tag, and the “order” tag of the child elements of the “constraint order” tag are read. The “group item” tag is a tag for grouping related data including data being processed. For example, since an estimate, order, invoice, etc. included in the same item are in the same group, “item ID” is assigned as a “group item” tag. However, the “group item” tag is attached only to the child elements of the “constraint order” tag.

  In step 1006, the correction target calculation unit 412 updates the error flag to “FORMAT”. Here, the error flag is a flag for setting what kind of alert is displayed in each metadata. FIG. 11 shows an example of data for managing error flags. This data includes an ID indicating metadata and an error flag corresponding to each metadata item name. The error flag is data for the metadata displayed on the correction screen in FIG. 8 and is stored on the memory. It is generated when the correction screen is opened and erased when it is closed. The initial value of each error flag is “CORRECT”. There are five types of error flags, and “CORRECT” indicates that the character string is determined to be correct and no alert is required. “STRING” indicates that the character string is determined to be incorrect. “FORMAT” indicates that it is determined that there is an error in the format of the character string. “ORDER” indicates that it is determined that there is an error in the order relation of values as a result of comparison with other related metadata. “DEPENDENT” indicates that, as a result of comparison with other related metadata, it is determined that the character string is different from the original character string to be stored.

  In step 1007, the correction target calculation unit 412 determines that the metadata item of the “order item” tag is the character string specified in the “order” tag among the data having the same “group item” tag. It is determined whether the metadata items being processed are in the order specified by the “order” tag. An example is shown in FIG. 13A. FIG. 13A is an example of data having the same case ID. The data with IDs 050 and 051 are confirmed, and the data 102 is unconfirmed. The metadata definition of these data is defined in the metadata item setting file of FIG. The validity of the order relationship is determined for the draft date with ID 102. Since the “constraint order” tag is set, the draft date is a metadata item in which the order relation is defined. Data having the same item ID is data shown in FIG. 13A. Among these data, in the document type name specified by the “order item” tag, the draft date must be the order of the estimate, the order, and the invoice. However, the draft date of the data whose ID is 102 is older than the other two data. For this reason, it is considered that there is an error in the order relationship for the draft date of the data whose ID is 102.

  In step 1007, the correction target calculation unit 412 determines the validity of the metadata dependency. The validity of the dependency relationship is determined in view of whether or not a value that should originally be stored is stored when a certain metadata item is dependent on another metadata item. For example, in a business voucher, the customer name is generally the same for the same case. Therefore, if the customer name is different in the same case, the stored metadata can be considered an error. In order to determine the validity of the dependency relationship, the metadata item setting file 405 is first referred to to determine whether or not the “dependent item” tag is included in the metadata item being processed. If not included, the correction target calculation unit 412 determines that the dependency relationship is correct, and ends the processing shown in the flowchart of FIG. If it is included, the correction target calculation unit 412 further checks the validity of the subordinate relationship. If it is correct, the correction target calculation unit 412 ends the flowchart of FIG. Set to. To check the validity of the dependency, in the data with the same metadata item set in the "dependent item" tag, whether the metadata item being processed is the same as the value of the metadata item in the confirmed data Check for no. An example is shown in FIG. 13B. FIG. 13B is an example of data having the same item ID. Data with IDs 070 and 071 is confirmed, and data 103 is unconfirmed. The metadata definition of these data is defined in the metadata item setting file of FIG. The validity of the subordinate relationship is determined for the draft date with ID 103. In these data, since the “dependent item” tag is set for the customer name, the customer name depends on the case ID. However, the customer name with ID 103 is different from the customer names of the other two confirmed data. For this reason, it can be considered that the customer name with ID 103 has an error in the dependency relationship.

<Alert judgment result>
FIG. 14 is an example of the alert determination result. The metadata to be corrected is displayed in different colors (1401). As a result, the user can easily check the metadata to be corrected, and the risk of oversight is reduced.

  The alert determination process is also executed at the timing when the character string in the cell is updated on the correction screen. In this case, the process according to the flowchart shown in FIG. 10 is performed again. As a result of the processing of the flowchart of FIG. 10, an alert corresponding to the set error flag is displayed.

  In the above description, an example has been shown in which the error flag of each metadata has only one value and only alerts related to the corresponding error flag are displayed.

However, metadata may contain multiple errors at the same time.
In this regard, in the present invention, a plurality of alerts can be displayed simultaneously. In that case, an error flag is defined for each type of alert, and whether or not each alert is necessary is set in the error flag. When an alert is displayed, an error flag is referred to alert an item requiring an alert.

<Suggest processing>
FIG. 15 is a flowchart for explaining the content of the suggestion process executed in the correction candidate calculation unit 413.

  In step 1501, the correction candidate calculation unit 413 receives a user input (selection) for a cell in which metadata is stored on the metadata correction screen.

  In step 1502, the correction candidate calculation unit 413 checks the error flag of the selected metadata (S) and performs subsequent processing according to the error flag. If the error flag is “CORRECT”, the metadata is regarded as a correct value, and the process proceeds to step 1508 as it is.

  Step 1503 is processing when the error flag is “STRING”. At this time, the character string of the metadata is erroneously recognized. The correction candidate calculation unit 413 first compares S with the value of the metadata item in the metadata DB 402 and dictionary DB 403 in order to present a correct character string. In the comparison, an arbitrary character string matching method can be applied. For example, the matching can be performed by DP matching.

  In step 1507, the correction candidate calculation unit 413 displays the matching results performed in step 1503 on the display device 407 in order from the top of the character string having the highest matching degree. FIG. 16B shows an example of a suggestion screen at this time. Bold characters indicate matched characters. The user can select an arbitrary character string from the suggested character strings. By displaying the correction candidate character string in this way, the user can easily correct the character string.

  Step 1504 is processing when the error flag is “FORMAT”. At this time, the format of the metadata is different. The correction candidate calculation unit 413 pops up the contents of the “define” tag of the metadata item being processed in the metadata item setting file 405 in order to present the correct format. FIG. 16A shows an example of the pop-up screen at this time. In this example, an example is shown in addition to the definition of metadata. For example, an “example” tag is defined in the metadata item setting file, a character string to be exemplified is set therein, and a popup is displayed. Sometimes this is possible by displaying the string.

  Step 1505 is processing when the error flag is “ORDER”. At this time, the order relation of metadata is incorrect. The correction candidate calculation unit 413 reads the definition in the metadata item setting file 405 and presents a range of possible values in order to present a correct data range. FIG. 16C shows an example of the pop-up screen at this time.

  Step 1506 is processing in a case where the error flag is “DEPENDENT”. At this time, the dependency relationship of the metadata is incorrect. In order to present a correct character string, the correction candidate calculation unit 413 reads the “dependent item” tag of the metadata item being processed in the metadata item setting file 405, and reads the data of the data with which the dependent metadata item is common. Refer to the confirmed data and suggest the corresponding metadata. FIG. 16D shows an example of a suggestion screen at this time. The user can easily correct the character string by selecting the suggested character string.

  In step 1508, the correction candidate calculation unit 413 determines whether or not the character string has been corrected. If the character string has been modified, the process proceeds to step 1509. If the character string has not been modified, the process ends.

  In step 1509, the correction candidate calculation unit 413 updates the display character string of the metadata being processed on the correction screen with the corrected character string.

  In step 1510, the correction candidate calculation unit 413 determines again whether or not correction is necessary for the corrected character string. This is because the corrected character string is not always a correct character string. This process is performed according to the flowchart of FIG.

  In step 1511, the correction candidate calculation unit 413 displays an alert according to the error flag set in the process of step 1510. As described above, if an error flag is set for each item, a plurality of suggestion processes can be performed simultaneously as in the alert process.

<Summary>
As described above, according to this embodiment, for each of a plurality of documents stored in the metadata database, metadata to be corrected is extracted from the plurality of metadata, and the metadata needs to be corrected. An alert is displayed to show that there is. Further, the metadata to be corrected and the dictionary data included in the dictionary database are collated, and a suggestion display is performed with similar data as correction candidates. As a result, it becomes possible to easily find and correct a character string obtained by performing scanning / OCR on a paper document, and it is possible to realize metadata setting without stress for the user.

  When the data to be processed is corrected, it is determined whether or not the corrected data needs to be corrected again. If correction is necessary, the alert is displayed again. As a result, correct metadata is finally extracted.

  Further, morphological analysis is performed on the processing target data in the plurality of metadata, and it is determined whether or not the data obtained by the morphological analysis exists in the morphological analysis dictionary data of the morphological analysis DB. Then, when the number of data obtained by morphological analysis is less than a predetermined number, it is determined to be a correction target. As a result, the morphological analysis DB used for the OCR recognition process can be used for the determination process for determining whether or not the metadata needs to be corrected, so that the cost for realizing the document processing system can be suppressed. .

  In addition, when the processing target data in a plurality of metadata is data other than a character string (date, case ID number, etc.), it is determined whether the processing target data is described in a predefined format and described in the format. Unprocessed processing target data is extracted as correction target metadata. This makes it possible to point out and correct recognition errors such as numbers that are not in the dictionary DB.

  Further, the processing target data in the plurality of metadata is compared with the already registered data (confirmed metadata), and it is determined whether the processing target data is inconsistent with the registered data. If there is a contradiction, the processing target data is extracted as metadata to be corrected. Note that the contradiction in this case means that if there is another document having the same project ID as the document ID having the processing target data in the registered data, the creation order between these documents is not valid. This is the case, for example, when the dependency of each metadata item in a document having registered data is different from the dependency of a metadata item in a document having processing target data. As a result, not only correctness / incorrectness of one metadata item but also correctness / incorrectness in relation to the relationship between the items and a plurality of documents can be determined, and finally appropriate metadata can be extracted.

  Suggestion display can also be performed in response to the cause of the correction. In other words, in the case of character strings, the target data to be corrected is compared with the metadata database and dictionary database, and character string data with a high degree of matching is suggested as correction candidates, and the metadata description format is defined. Appropriate format defined in the metadata item configuration file to be suggested as a correction candidate, data that guarantees the correct creation order is suggested as a correction candidate, or a legal dependency relationship Simple character string data can be suggested as correction candidates.

  The present invention can also be realized by a program code of software that realizes the functions of the embodiments. In this case, a storage medium in which the program code is recorded is provided to the system or apparatus, and the computer (or CPU or MPU) of the system or apparatus reads the program code stored in the storage medium. In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the program code itself and the storage medium storing the program code constitute the present invention. As a storage medium for supplying such program code, for example, a flexible disk, CD-ROM, DVD-ROM, hard disk, optical disk, magneto-optical disk, CD-R, magnetic tape, nonvolatile memory card, ROM Etc. are used.

  Also, based on the instruction of the program code, an OS (operating system) running on the computer performs part or all of the actual processing, and the functions of the above-described embodiments are realized by the processing. May be. Further, after the program code read from the storage medium is written in the memory on the computer, the computer CPU or the like performs part or all of the actual processing based on the instruction of the program code. Thus, the functions of the above-described embodiments may be realized.

  Further, by distributing the program code of the software that realizes the functions of the embodiment via a network, the program code is stored in a storage means such as a hard disk or memory of a system or apparatus, or a storage medium such as a CD-RW or CD-R And the computer (or CPU or MPU) of the system or apparatus may read and execute the program code stored in the storage means or the storage medium when used.

401: Scan data DB
402: Metadata DB
403 ... Dictionary DB
404 ... Morphological analysis DB
405: Metadata item setting file 406 ... Parameter setting file 407 ... Display device 408 ... Keyboard 409 ... Mouse 410 ... Central processing unit 411 ... Correction screen display unit 412 ... Correction target calculation unit 413 ... Correction candidate calculation unit 601 ... File ID
602 ... Status 603 ... File path 604 ... Overall metadata 605 ... Document type name 606 ... Customer name 607 ... Draft date 608 ... Case ID
801 ... Correction execution menu 802 ... Processing check box 1401 ... Alert displayed metadata 1601 ... Format display pop-up 1602 ... Input candidate character string suggestion 1603 ... Data range pop-up 1604 ... Appropriate character string suggestion

Claims (12)

A metadata database obtained by scanning / OCR for a plurality of paper documents and storing a plurality of metadata for each of the plurality of documents;
A dictionary database for storing character strings that can be the metadata character strings;
A display device;
An input device;
A central processing unit,
The central processing unit is
For each of the plurality of documents stored in the metadata database, metadata that is to be corrected is extracted from the plurality of metadata, and an alert display indicating that the metadata needs to be corrected is displayed on the display device Displayed on the
A document processing system, wherein the metadata to be corrected is compared with dictionary data included in the dictionary database, and similar data is suggested on the display device as correction candidates. In claim 1,
Furthermore, it has a morphological analysis database that stores morphological analysis dictionary data used for morphological analysis,
The central processing unit performs morpheme analysis on processing target data in the plurality of metadata, determines whether data obtained by the morpheme analysis exists in the morpheme analysis dictionary data, and A document processing system, wherein when the number of data obtained by analysis is less than a predetermined number, the metadata is determined to be the metadata to be corrected. In claim 1,
When the processing target data in the plurality of metadata is data other than a character string, the central processing unit determines whether the processing target data is described in a predefined format, and is described in the format. The document processing system, wherein the processing target data not yet extracted is extracted as the metadata to be corrected. In claim 1,
The central processing unit compares processing target data in the plurality of metadata with already registered data, determines whether the processing target data is inconsistent with the registered data, If it occurs, the document processing system extracts the processing target data as the correction target metadata. In claim 4,
When the central processing unit is data other than a character string described in a predefined format, the central processing unit has a case ID that is the same as the case ID of the document having the processing target data in the registered data. The document processing system is characterized in that it determines whether or not there is a document and if the creation order between these documents is not valid, the processing target data is extracted as the metadata to be corrected. In claim 4,
When the central processing unit is data other than a character string described in a predefined format, the central processing unit has a case ID that is the same as the case ID of the document having the processing target data in the registered data. When there is a discrepancy between the dependency relationship of each metadata item in the document having the registered data and the dependency relationship of the metadata item in the document having the processing target data Further, the document processing system is characterized in that the processing target data is extracted as the correction target metadata. In claim 2,
The central processing unit compares the processing target data to be corrected with the metadata database and the dictionary database, and suggests character string data having a high matching degree as the correction candidate. Processing system. In claim 3,
The central processing unit suggests, as the correction candidate, an appropriate format defined in a metadata item setting file that defines a metadata description format for the processing target data to be corrected. Feature document processing system. In claim 5,
The document processing system, wherein the central processing unit suggests, as the correction candidate, data that guarantees a valid creation order with respect to the processing target data to be corrected. In claim 6,
The document processing system, wherein the central processing unit suggests, as the correction candidate, character string data that has a valid dependency relationship with respect to the processing target data to be corrected. In any one of Claims 1 thru | or 10,
When the data to be processed is corrected, the central processing unit determines whether the corrected data needs to be corrected again, and if correction is necessary, displays the alert again. Feature document processing system.   A program for causing a computer and a storage device to function as the document processing system according to claim 1.

Images