WO2011013587A1 - 文書データ処理装置 - Google Patents

文書データ処理装置 Download PDF

Info

Publication number
WO2011013587A1
WO2011013587A1 PCT/JP2010/062417 JP2010062417W WO2011013587A1 WO 2011013587 A1 WO2011013587 A1 WO 2011013587A1 JP 2010062417 W JP2010062417 W JP 2010062417W WO 2011013587 A1 WO2011013587 A1 WO 2011013587A1
Authority
WO
WIPO (PCT)
Prior art keywords
character string
metadata
feature
document
document data
Prior art date
Application number
PCT/JP2010/062417
Other languages
English (en)
French (fr)
Inventor
松本俊子
Original Assignee
株式会社日立ソリューションズ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立ソリューションズ filed Critical 株式会社日立ソリューションズ
Priority to EP10804333.2A priority Critical patent/EP2461255A4/en
Priority to US13/380,561 priority patent/US8768941B2/en
Priority to CN201080028233.2A priority patent/CN102473176B/zh
Publication of WO2011013587A1 publication Critical patent/WO2011013587A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/38—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/103—Formatting, i.e. changing of presentation of documents
    • G06F40/106—Display of layout of documents; Previewing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/20—Natural language analysis
    • G06F40/258—Heading extraction; Automatic titling; Numbering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing

Definitions

  • the present invention relates to a document data processing apparatus, for example, a technique for efficiently managing file data of a large amount of business documents.
  • Patent Documents 4 to 6 and Non-Patent Documents 3 to 8 efforts have been already made to automatically prepare a model for automatic metadata acquisition.
  • Japanese Patent Laid-Open No. 11-184894 Japanese Patent No. 3425834 Japanese Patent No. 3425408 US Patent 7,149,347B1 JP 2000-90117 A Japanese Patent Laid-Open No. 11-328306
  • Non-Patent Document 3 and Patent Documents 4, 5, and 6 describe the technology for preparing models for each detailed class of documents such as “Invoice” and “Housing Loan Application”.
  • the types of documents are limited, and it is not assumed that a wide range of documents such as “sales documents” and “design documents” will be handled together, and it is difficult to say that this is a general-purpose technology.
  • it is complicated to use a model for each class, which is not practical in terms of efficient handling of business documents.
  • Non-Patent Documents 4, 5, 6, and 7 are targeted for the Reference section of the paper, and are assumed to handle character string information as input. Therefore, it is impossible to handle document data having a spread on a two-dimensional plane.
  • Non-Patent Document 8 is intended for manuals and uses headline expressions.
  • business documents such as business documents and design documents, there are many documents that do not contain headline expressions, and such documents cannot be handled.
  • the present invention has been made in view of such a situation, and it is possible to greatly reduce the man-hours for preparing a model for extracting metadata, and to automatically acquire metadata in each organization. It is to provide.
  • the document data processing apparatus determines whether or not the layout feature of the processing target metadata in the processing target document data is effective in extracting the processing target metadata. Then, the determination result is output. More specifically, the document data processing apparatus checks whether the layout characteristics of the metadata to be processed appear in a character string other than the metadata in the document data to be processed, and performs layout based on the check result. It is determined whether the feature is effective in extracting metadata. Further, the document data processing apparatus has the number of documents (n1) in which the layout feature appears only in the character string of the metadata and the layout feature for the plurality of processing target document data for which the same metadata type is specified.
  • the number of documents (n2) appearing only in character strings other than metadata is calculated, the number of documents is output, and when n1> n2, the layout feature is automatically acquired for the metadata.
  • Information indicating that the model is to be set as a model that should be a feature should be presented.
  • the document data processing apparatus determines whether or not the character string feature in the vicinity of the processing target metadata in the processing target document data is effective in extracting the processing target metadata, and determines the determination result. Output. More specifically, the document data processing apparatus checks whether or not a neighboring character string feature appears in the vicinity of a character string other than the metadata to be processed, and based on the check result, It is determined whether or not it is effective in extracting metadata.
  • the document data processing apparatus determines whether or not the partial character string feature included in the processing target metadata in the processing target document data is effective in extracting the processing target metadata. Output the judgment result. More specifically, the document data processing apparatus checks whether or not the partial character string feature is included in a character string other than the metadata to be processed, and based on the check result, the partial character string feature is It is determined whether it is effective in extracting data.
  • the man-hour for preparing a model for extracting metadata can be greatly reduced, and metadata can be automatically acquired in each organization.
  • the present invention relates to processing for preparing features (models) required when extracting metadata from a document.
  • a model to be prepared a relationship with a layout feature of metadata, a relationship with a neighboring character string, and a relationship with a partial character string included therein are shown.
  • FIG. 1 is a functional block diagram schematically showing the internal configuration of a business document processing apparatus according to an embodiment of the present invention.
  • the business document processing apparatus 1 includes a display device 100 for displaying data, a sample document DB 101, a keyboard 102 for performing operations such as selecting a menu for the displayed data, and a pointing device such as a mouse. 103, a central processing unit 104 that performs necessary arithmetic processing and control processing, a program memory 105 that stores a program necessary for processing in the central processing unit 104, and data necessary for processing in the central processing unit 104 A data memory 106 for storage.
  • the central processing unit 104 includes a layout feature use setting processing unit 107 that sets layout features (for example, “underline” and “centering”) used for metadata extraction, and a neighborhood character string used for metadata extraction.
  • the neighborhood character string feature use setting processing unit 108 for setting features (for example, “Gonchu”, “Sama”, etc.) and partial character strings (for example, “corporation”, “company”, etc.) used for metadata extraction
  • a partial character string feature use setting processing unit 109 for setting.
  • the layout feature use setting processing unit 107, the neighborhood character string feature use setting processing unit 108, and the partial character string feature use setting processing unit 109 are all executed on the computer. Realized as part of the program functionality. Note that these programs are stored in the program memory 105.
  • the layout feature use setting processing unit 107 uses the layout feature (for example, “underline”) to extract metadata (for example, “title”) and what are the advantages and disadvantages (for metadata extraction) It is provided with a layout feature use adjustment processing unit 110 that checks whether it is valid or not, and finally executes a use / non-use adjustment process of the layout feature. What kind of merits / disadvantages are obtained when the neighborhood string feature use setting processing unit 108 uses a neighborhood string feature (for example, “Gochu”) to extract metadata (for example, “customer name”).
  • a neighborhood character string feature use adjustment processing unit 111 that checks (whether or not it is effective for metadata extraction) and finally executes use / non-use adjustment processing of the neighborhood character string feature is provided.
  • the partial character string feature use setting processing unit 109 uses a partial character string feature (for example, “company”) to extract metadata (for example, “customer name”).
  • a partial character string feature use adjustment processing unit 112 that checks whether it is present (whether it is effective for metadata extraction) and finally executes use / nonuse adjustment processing of the partial character string feature is provided.
  • the data memory 106 includes a document data storage unit 113, a character string data storage unit 114, a metadata type data storage unit 115, and a neighborhood character string feature data storage unit 116.
  • FIG. 2 is a diagram illustrating a data structure of document data and character string data stored in the document data storage unit 113 and the character string data storage unit 114 included in the data memory 106.
  • the document data includes a document ID 200, a document file name 201, a description content 202, and a document image 203.
  • the description content 202 is held in the form of an array of character string data structures.
  • the document image 203 holds a print image of the document in an image format.
  • the character string data includes a character string ID 204, a character string content 205, a correct metadata designation ID 206, an adjacent character string ID 207, an adjacent cell character string ID 208, and a layout feature 209.
  • the correct metadata designation ID 206 is an ID corresponding to the type of metadata (in the example of FIG. 2, “in the example of FIG. 2,“ The metadata type ID) “title” is held, and a NULL value is held if no such designation is made.
  • the adjacent character string ID 207 holds information on adjacent character strings in the form of a double array.
  • the first represents the up / down / left / right direction, and the second holds the ID when there is an adjacent character string in that direction. Since the double line is also arranged, it is possible to cope with a case where there are a plurality of character strings adjacent in the same direction.
  • two character strings (character string IDs are Str_0002 and Str_0003, respectively) above the character string “Proposal”, one character string (character string ID is Str_0004) below, and on the right
  • Two character strings are adjacent to each other, and there is no character string adjacent to the left.
  • the adjacent cell character string ID 208 displays information on adjacent cells in the form of a double array when the target character string (for example, “Proposal”) is included in the table. Hold. The first represents the up / down / left / right direction, and the second holds the ID when there is a character string in a cell adjacent in that direction.
  • the target character string for example, “Proposal”
  • the second holds the ID when there is a character string in a cell adjacent in that direction.
  • the layout feature 209 holds information on what kind of layout feature it has in order of whether or not it has a plurality of types of layout features. For example, as an example of layout features, from the left, centering, font, underline, Bold, etc., whether these features are included is indicated by true or false.
  • FIG. 3 is a diagram showing a data structure of the metadata type data 115 and the neighborhood character string feature data 116 included in the data memory 106. That is, in the example of FIG. 3, when “title” is extracted as metadata, it is shown that the metadata can be efficiently extracted by paying attention to the features 302 to 304.
  • the data 302 to 304 in FIG. 3 corresponds to the result (metadata extraction model) generated by the process in FIG. 4 (at least one of steps 401 to 403) using the data in FIG. To do.
  • the metadata type data includes a metadata type ID 300, a metadata type name 301, a usage layout feature 302, a usage neighborhood character string feature 303, and a usage partial character string feature 304 as information.
  • the use layout feature 302 holds, in order, whether or not to use a plurality of types of layout features.
  • the metadata “title” it is shown that “font” is set as a layout feature to be used among the layout features 209 of FIG.
  • the use neighboring character string feature 303 holds information on the neighboring character strings that are effective when used for metadata extraction in the form of an array of neighboring character string feature data.
  • the neighborhood character string feature data includes a character string 305 and a direction designation 306.
  • FIG. 3 shows an example in which metadata is acquired by using the feature that “a character string“ Gochu ”is often described in“ right next ”” of metadata ”.
  • the used partial character string feature 304 holds information on partial character strings that are effective when used for metadata extraction in the form of character string arrays. In the example of FIG. 3, it is effective to use the fact that the metadata “title” includes the character strings “sheet” and “application” in order to extract the metadata “title”. ing.
  • FIG. 4 is a flowchart schematically showing the overall flow of the metadata extraction model generation process performed in the business document processing apparatus 1.
  • the central processing unit 104 reads a document to be processed from the sample document DB 101 and holds it in the form of document data 113 (step 400).
  • the document stored in the sample document DB 101 has a metadata type designated in advance by the user such as “title” or “customer name”.
  • the layout feature use setting processing unit 107 performs processing for setting use of the features on the layout (step 401). This process will be described in detail with reference to FIG.
  • the neighborhood character string feature usage setting processing unit 108 performs processing for setting the usage of the character string feature described in the neighborhood (step 402). This process will be described in detail with reference to FIG.
  • the partial character string feature use setting processing unit 109 performs processing for setting the use of the feature of the partial character string (step 403). This process will be described in detail with reference to FIG.
  • processes 401 to 403 are exclusive processes, and may be executed independently or in combination.
  • FIG. 5 is a flowchart for explaining details of the processing in step 401 of FIG.
  • the layout feature use setting processing unit 107 initializes the index i in order to sequentially process metadata types such as title, creator, and creation date (step 500).
  • the layout feature use setting processing unit 107 initializes an index j in order to sequentially process layout features such as underline, centering, and font size (step 501).
  • the layout feature use setting processing unit 107 uses the layout feature use adjustment processing unit 110 to obtain a sample document in which the feature on the jth layout is valid, a sample document in which the feature is invalid, or a sample document in which the effect is unknown. Based on this, it is determined whether or not it can be said that the feature on the j-th layout is effective for obtaining metadata, and it is set whether or not to use it (step 502). This process will be described in detail with reference to FIG.
  • the layout feature use setting processing unit 107 increments the layout feature index j by 1 (step 503), and if there are still layout features remaining, the process returns to step 502 to repeat the processing (step 504). ). Also, the layout feature use setting processing unit 107 increments the metadata type index i by 1 (step 505), and if the metadata type still remains, returns to step 501 and repeats the processing (step 506).
  • FIG. 6 is a flowchart for explaining details of the processing in step 502 of FIG.
  • the layout feature use adjustment processing unit 110 has a counter n1 for counting sample documents whose layout features are effective for acquiring metadata, a counter n2 for counting invalid sample documents, and the effect is unknown.
  • a counter n3 for counting sample documents is initialized (step 600).
  • the layout feature use adjustment processing unit 110 initializes the index k in order to sequentially process the sample document read in step 400 (step 601).
  • the layout feature use adjustment processing unit 110 confirms the description content 202 included in the document data in the kth sample document, and character string data in which the feature on the jth layout of the layout feature 209 is true.
  • the character string data having the metadata type ID 300 in the i-th metadata in FIG. 5 as the correct metadata designation ID 206 is compared (step 602). If the former character string data and the latter character string data completely match, it means that the i-th metadata can be acquired from the k-th sample document by using the feature on the j-th layout. Therefore, the number n1 of sample documents in which the jth layout feature is valid is incremented.
  • the layout feature use adjustment processing unit 110 increments the index k of the sample document by 1 (step 603), and if the sample document still remains, returns to step 602 and repeats the process (step 604).
  • the screen display shown in FIG. 7 is performed based on the values of n1, n2, and n3 (step 605). For example, when the layout feature “centering” is used, a screen is displayed as to whether there are many sentences effective for extracting metadata (in this example, “title”) or whether there are many counter-effect documents. It is determined whether “centering” should be used for title acquisition.
  • FIG. 7 is a diagram showing a usage setting result display screen (GUI) of features on the layout.
  • GUI usage setting result display screen
  • the necessity of use calculated based on the values j, n1, n2, and n3 in FIG. 6 is displayed (700). Of these, the necessity of use can be determined to be valid if n1 ⁇ n2, for example, otherwise invalid.
  • the values of n1, n2, and n3 are displayed as information for providing the user with a basis for determining whether or not to use (701).
  • a radio button 702 is displayed for displaying the necessity of use and accepting the user's designation.
  • the corresponding element of the used layout feature 302 of the metadata type data is set to true, and for the layout feature designated as “not used” is set to false.
  • FIG. 8 is a flowchart for explaining details of the process in step 402 of FIG.
  • the neighborhood character string feature usage setting processing unit 108 initializes a metadata type index i, a candidate set s of character strings described in the neighborhood, and an index k of a sample document (step 800, step 801, and step 800). 802).
  • the neighborhood character string feature use setting processing unit 108 sequentially checks the correct metadata designation ID 206 of the character string data included in the description content 202 in the kth sample document, and has the ID300 of the ith metadata type. If there is character string data, the character string 205 itself or the partial character string of the character string data of the character string ID held in the adjacent character string ID 207 or the adjacent cell character string ID 208 is added to s as a candidate (step 803). At this time, a value is set in the direction designation 306 of the neighboring character string feature data depending on which direction of the character string designated by the correct answer metadata is adjacent.
  • the neighborhood character string feature usage setting processing unit 108 increments the index k of the sample document by 1 (step 804), and if the sample document still remains, returns to step 803 and repeats the process (step 805).
  • all the candidate character string data as candidates for specific metadata type data for example, “title”.
  • the neighboring character string feature usage setting processing unit 108 determines whether or not the character string described in the vicinity of the character string including the character string is metadata for the character string included in the candidate set s. It is determined whether the candidate character string can be said to be effective for obtaining the metadata, and whether to use the candidate character string is set (step 806). That is, for specific metadata, it is confirmed whether the character string around the candidate character string is only the character string of the metadata or whether there is a completely different character string (reverse confirmation).
  • the neighborhood character string feature use setting processing unit 108 increments the metadata type index i by 1 (step 807), and if the metadata type still remains, the process returns to step 802 and repeats the processing (step 808). ).
  • FIG. 9 is a flowchart for explaining the processing of step 806 in FIG. 8 in detail.
  • the neighborhood character string feature use adjustment processing unit 111 initializes the index l of the candidate character string and the index k of the sample document (steps 900 and 901).
  • the neighborhood character string feature usage adjustment processing unit 111 checks the neighborhood character string adjacent in the direction designated by the direction designation 306 with respect to the l-th candidate character string in the k-th sample document (step S110). 902).
  • the description content 202 of the kth document data is confirmed, and a search is made for a character string 205 including the lth candidate character string.
  • the character string data of the character string ID held in the adjacent character string ID 207 and the adjacent cell character string ID 208 is the metadata type in the i-th metadata in FIG. Check if you have ID300.
  • the neighboring character string feature use adjustment processing unit 111 sets that the l-th candidate character string is not used (step 903). In other cases, the neighborhood character string feature usage adjustment processing unit 111 increments the index k of the sample document by 1 (step 904), and if the sample document still remains, returns to step 902 and repeats the processing (step 904). Step 905).
  • the neighborhood character string feature use adjustment processing unit 111 sets that the l-th candidate character string is to be used (step 906). Thereafter, the neighboring character string feature usage adjustment processing unit 111 performs screen display shown in FIG. 10 regarding the use of the l-th candidate character string (step 907). Further, the neighborhood character string feature use adjustment processing unit 111 increments the index 1 of the candidate character string by 1 (step 908), and if the candidate character string still remains, returns to step 901 and repeats the process (step 909). ).
  • FIG. 10 is a diagram showing a usage setting result display screen (GUI) for the characteristics of the neighborhood character string.
  • GUI usage setting result display screen
  • the l-th candidate character string in FIG. 9 ⁇ Use necessity specified in step 903 or 906 in FIG. 9 is displayed (1000).
  • the document image 203 of the sample document when the candidate character string is registered in step 803 in FIG. 8 is displayed in 1001, and if it is set not to be used in step 903 in FIG.
  • a document image 203 is displayed at 1002.
  • FIG. 10 also shows a radio button 1003 that displays the necessity of use specified in step 903 or 906 in FIG.
  • the feature of the nearby character string designated by the user as “use” is stored in the use neighborhood character string feature 303 of the metadata type data.
  • FIG. 11 is a flowchart for explaining details of the processing in step 403 in FIG.
  • the partial character string feature usage setting processing unit 109 initializes the metadata type index i, the partial character string candidate set s, and the index k of the sample document (steps 1100, 1101, and 1102).
  • the partial character string feature usage setting processing unit 109 sequentially confirms the correct metadata designation ID 206 of the character string data included in the description content 202 in the kth sample document, and has the ID300 of the ith metadata type. If there is character string data, the character string 205 itself or a partial character string is added to s as a candidate (step 1103). For example, when the target metadata type is “customer name” and the character string data is “ABCD Inc.”, “KK”, “ABCD”, etc. are added as partial character string candidates.
  • the partial character string feature usage setting processing unit 109 increments the index k of the sample document by 1 (step 1104), and if the sample document still remains, the process returns to step 1103 and repeats the process (step 1105). .
  • the partial character string feature use setting processing unit 109 is effective in acquiring metadata for a character string included in the candidate set s based on whether or not the character string including the character string is metadata. It is judged whether it can be said, and it is judged whether it uses or not (step 1106). This process will be described in detail with reference to FIG.
  • the partial character string feature usage setting processing unit 109 increments the metadata type index i by 1 (step 1107), and if the metadata type still remains, the process returns to step 1102 to repeat the processing (step 1108). ).
  • FIG. 12 is a flowchart for explaining details of step 1106 in FIG.
  • the partial character string feature usage adjustment processing unit 112 initializes the index l of the candidate character string and the index k of the sample document (steps 1200 and 1201).
  • the partial character string feature use adjustment processing unit 112 checks whether there is a metadata other than the i-th in the k-th sample document including the l-th candidate character string (step 1202).
  • the description content 202 of the kth document data is confirmed, and a search is made for a character string 205 including the lth candidate character string.
  • the correct metadata designation ID 206 has the metadata type ID 300 in the i-th metadata in FIG. If the correct metadata specification ID 206 has a value and is not the i-th metadata type ID 300, an error is obtained when attempting to acquire metadata from the k-th sample document using the l-th candidate character string It means to end up.
  • the l-th candidate character string is set not to be used (step 1203).
  • the target metadata type is “customer name” and the character string data is “ABCD Inc.”
  • the metadata including the character string “corporation” is not a customer name but If there is, it is determined not to be used as a candidate character string.
  • the partial character string feature use adjustment processing unit 112 increments the index k of the sample document by 1 (step 1204), and if the sample document still remains, returns to step 1202 and repeats the process (step 1204). Step 1205). If the loop processing has been completed for all the sample documents, the l-th candidate character string is set to be used (step 1205).
  • the partial character string feature use adjustment processing unit 112 displays the screen shown in FIG. 13 for the use of the l-th candidate character string (step 1207), and increments the index 1 of the candidate character string by 1 (step 1208). If the candidate character string still remains, the process returns to step 1201 and the process is repeated (step 1209).
  • FIG. 13 is a diagram showing a usage setting result display screen (GUI) for the characteristics of the partial character string.
  • GUI usage setting result display screen
  • the document image 203 of the sample document when the candidate character string is registered in step 1103 in FIG. 11 is displayed in 1301, and if it is set not to be used in step 1203 in FIG. A document image 203 is displayed on 1302.
  • the data is held in the used partial character string characteristics 304 of the metadata type data.
  • the layout feature 209 is held in the form of a binary array of true or false. For example, if the text string centered in the document is very few, give a high score to the text string centered, and if most of the text strings listed in the document are centered This is a method of giving a score that is not so high to the centered character string. For example, there is a method of giving a score according to the font size of a character string. The present invention is effective even when layout features are held with numerical values such as these. In this case, in the comparison in step 602, the character string data having the highest score in the description content 202 may be set as the comparison target.
  • the order number is written to the right of the character string “order number”, it may be “your order number” or “order number (for continued transactions)” depending on the business partner.
  • characters may be added before and after the “order number”.
  • the present invention is also effective for a method capable of performing such designation. In that case, if you want to use the character string described in the vicinity of the metadata as a feature as it is, set the prefix / suffix to ON and use the partial character string of the character string described in the vicinity as the feature. Change the prefix / suffix designation.
  • the use of the characteristics of the partial character string is collectively registered as a candidate character string in step 1103.
  • register by adding a prefix or suffix designation.
  • the character string “independent administrative corporation” is included in the customer name, it is unlikely that a character will be added before “independent administrative corporation”, but it is highly likely that a character will be added after that. .
  • the present invention is also effective for a method capable of performing such designation. In this case, when using the metadata as a feature as it is, the prefix / suffix designation is turned ON, and when using a partial character string as the feature, the prefix / suffix designation may be changed.
  • step 902 it is set in step 902 that the candidate character string is not used only when there is metadata other than the i-th in the vicinity. A condition may be further added to this, and if the character string in the vicinity is not the i-th metadata, all may be set to “not use candidate character string”. This makes it possible to prepare a model that places more weight on the accuracy of reliably avoiding non-metadata (rather than the probability that it can be acquired without missing what is meta-data).
  • step 1202 it is set that the candidate character string is not used only when there is metadata other than the ith metadata including the lth candidate character string. If a condition is further added to this and a character string other than the i-th metadata includes the l-th candidate character string, it may be set that “candidate character string is not used”. This makes it possible to prepare a model that places more weight on the accuracy of reliably avoiding non-metadata (rather than the probability that it can be acquired without missing what is meta-data).
  • the layout characteristics of the processing target metadata in the processing target document data, the character string characteristics in the vicinity of the processing target metadata, and the processing target metadata are included. It is determined whether or not at least one of the partial character string features is effective in extracting the metadata to be processed from the document data, and the determination result is output. In this way, just by specifying a document and the metadata set described in it, the use of layout features in automatic metadata acquisition / characteristics of the character string described in the vicinity of the metadata You can automatically set the usage of features and features of substrings of metadata.
  • the layout feature use setting processing unit and the layout feature use adjusting unit have a layout feature (for example, centering) included in the processing target metadata (for example, title) other than the metadata in the processing target document data. It is checked whether or not it appears in the character string, and it is determined whether or not the layout feature is effective in extracting the metadata based on the check result.
  • the neighborhood character string feature usage setting processing unit and the neighborhood character string feature usage adjustment processing unit have neighboring character string features (for example, Gochu) appearing in the vicinity of character strings other than the metadata (for example, customer name) to be processed. It is determined whether or not the neighborhood character string feature is valid in extracting the metadata to be processed based on the check result.
  • the partial character string feature use setting processing unit and the partial character string feature use adjustment processing unit include the partial character string feature (for example, an independent administrative agency) in character strings other than the metadata (for example, customer name) to be processed. It is determined whether or not the partial character string feature is effective in extracting the metadata to be processed based on the check result. This makes it possible to automatically make fine adjustments that take into account how metadata appears and how character strings other than metadata appear, and perform metadata extraction efficiently. In addition, since these adjustments are made based on the characteristics of the document, the document can be processed quickly. Therefore, the man-hours for preparing the metadata extraction model can be greatly reduced, and a technique for automatically acquiring metadata in each organization can be used. That is, a business document processing apparatus that manages and retrieves documents using metadata can be easily introduced.
  • the partial character string feature for example, an independent administrative agency
  • the layout feature use setting processing unit and the layout feature use adjustment processing unit for a plurality of processing target document data for which the same metadata type (title) is specified, the layout feature appears only in the metadata character string.
  • GUI display unit
  • the present invention can also be realized by a program code of software that realizes the functions of the embodiment.
  • 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.
  • 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.
  • 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.
  • an OS operating system
  • the computer CPU or the like performs part or all of the actual processing based on the instruction of the program code.
  • 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
  • the computer of the system or apparatus or CPU or MPU may read and execute the program code stored in the storage means or the storage medium when used.

Abstract

　メタデータを抽出するためのモデルを用意する工数を大幅に削減し、各組織においてメタデータを自動的に取得するための技術を提供する。文書とその中に記載されたメタデータの組を入力として、メタデータとそうでない文字列におけるレイアウト上の特徴・近傍文字列・部分文字列の特徴を用いて、メタデータの自動取得におけるレイアウト上の特徴・近傍文字列・部分文字列の利用を自動的に設定する（図１参照）。

Description

文書データ処理装置
　本発明は、文書データ処理装置に関し、例えば、大量に存在する業務文書のファイルデータを効率的に管理するための技術に関する。
　組織内の文書を効率的に取扱うための技術に対する要求が高まっている。例えば、日本版ＳＯＸ法（金融商品取引法）の施行に伴い、企業の営業活動における証憑の管理ニーズが高まっている。また、例えば企業内の情報、その中でも特にリレーショナルデータベースに格納されない（定型でない）文書データが急激に増大している（情報爆発と呼ばれる現象が起きている）。このような状況のもとで、文書をタイトル・作成日・作成者などのメタデータで管理・検索したいというニーズも高まっている。例えば営業文書であれば、文書名・顧客名・作成日・注文番号などの業務ＩＤで検索を行うことができれば、内部統制の監査において必要な文書を迅速に探し出すことができる。また設計文書であれば、文書名・作成元部署・作成日・製品コードなどで検索を行うことができれば、技術情報の有効活用に効果がある。さらに、クレーム・不具合情報の記録文書であれば、発生日・対策日・製品名・被害額・部品名などで検索を行うことができれば、類似の不具合の発生時における迅速な対応に効果がある。また、業務規定・通達などの文書であれば、文書の種別・作成日・実施期間などで検索を行うことができれば、ルールに沿った効率的な業務遂行に効果がある。
　定型でない文書を解析してメタデータを自動的に取得する技術は多く提案されている（例えば、特許文献１乃至３、非特許文献１及び２参照）。これらの文献は、対象となる文書の種類を事前に定め、その種類の文書に記述されるメタデータの特徴を詳細に調査し、対象となる種類の文書の「モデル」として保持しておくことを想定している。その上で、文書中に現れる文字列とモデルとのマッチングを行ない、どの文字列がモデル中のどの構成要素か（どの文字列がメタデータか）を推測する。特徴としては、レイアウト上の特徴（例えば「タイトルはセンタリングされていることが多い」など）・メタデータの近傍に記載される文字列の特徴（例えば「注文番号は『注文番号：』という文字列の右隣に記載されることが多い」など）・メタデータの部分文字列の特徴（例えば「顧客名は『独立行政法人』から始まることが多い」）が用いられる。
　また、特許文献４乃至６、及び非特許文献３乃至８に示されるように、メタデータ自動取得のためのモデルを自動的に用意するための取組みも既に行われている。
特開平１１－１８４８９４号公報 特許第３４２５８３４号公報 特許第３４２５４０８号公報 米国特許７，１４９，３４７Ｂ１公報 特開２０００－９０１１７号公報 特開平１１－３２８３０６号公報
勝山・直井・武部, ビジネス文書を対象としたキーワード自動抽出技術, FUJITSU, 49, 5, pp.404-409 (1998-09) Ishitani, Y., Document Transformation System from Papers to XML Data Based on Pivot XML Document Method, Proceedings of the Seventh International Conference on Document Analysis and Recognition (2003) F. Esposito, D. Malerba, G. Semeraro, S. Ferilli, O. Altamura, T. M. A. Basile, M. Berardi, M. Ceci, N. Di Mauro, "Machine Learning methods for automatically processing historical documents: from paper acquisition to XML transformation", Proceedings of the First Inernational Workshop on Document Image Analysis for Libraries, 2004. M. Kramer, H. Kaprykowsky, D. Keysers, T. Breuel, "Bibliographic Meta-Data Extraction Using Probabilistic Finite State Transducers", Proceedings of International Conference on Document Analysis and Recognition, Vol. 2, pp. 609-613, 2007 D. Besagni, A. Belaid, "Citation Recognition for Scientific Publications in Digital Libraries", Proceedings on the First International Workshop on Document Image Analysis for Libraries, 2004 F. Parmentier, A. Belaid, "Logical Structure Recognition of Scientific Bibliographic References", Proceedings on International Conference on Document Analysis and Recognition, pp. 1072-1076, 1997 D. Besagni, A. Belaid, N. Benet, "A segmentation method for bibliographic references by contextual tagging of fields", Proceedings on Seventh International Conference on Document Analysis and Recognition, vol. 1, pp. 384-388, 2003 M. Imamura, Y. Takayama, M. Akiyoshi, and N. Komoda, "An Acquisition Method on Term Knowledge from Operating Manuals for Information Equipments by Using the Structure of Headline Sentences", IEEJ Trans. EIS, Vol. 128, No. 12, pp.1833-1841 (2008)
（１）特許文献１乃至３、非特許文献１及び２で示されるようなメタデータの自動取得処理においては、上述したような動作原理上、モデルの完成度が最終的なメタデータの推測の精度に大きく影響を及ぼす。
　しかしながら、モデルを人手で用意する場合、以下のような課題が存在し、効率的でない。
　モデルを用意するときの課題１：レイアウト上の特徴としてどのようなものを使ってどのメタデータを取得するべきかを、文書の特徴に応じて設定するのは煩雑である。レイアウト上の特徴はたくさんの種類があり（下線・センタリング・フォントサイズ・ページ内における位置など）、メタデータの種類との組み合わせ数はさらに多いものとなる。
　モデルを用意するときの課題２：モデルへのレイアウト上の特徴の利用に当たっては、どのような文書があるか・メタデータはどのような現れ方をするか・メタデータ以外の文字列はどのような現れ方をするか、を考慮して細かい調整を行う必要がある。例えば、営業文書ではタイトルには下線があることが比較的多い。しかし、金額や商品名には、タイトル以上に下線があることが多い。このため、レイアウト上の特徴として下線の有無を用いるようモデルに記述すると、タイトルとして金額や品名を誤って取得することになってしまう。このようなことを避けるため、レイアウト上の特徴の利用を細かく調整する必要がある。
　モデルを用意するときの課題３：メタデータの近傍に記載される文字列の特徴としてどのようなものを用いてメタデータを取得するべきかを、文書の特徴に応じて設定するのは煩雑である。例えば、注文番号を右隣に持つ文字列としては、上述の「注文番号：」の他にも「注文ＮＯ：」、「注文Ｎｏ：」、「注文No．：」、「注文書番号」、「発注番号」などの表現があり、これらを洩らさず列挙することがモデルの完成度に寄与する。
　モデルを用意するときの課題４：メタデータの近傍に記載される文字列の特徴の利用に当たっては、どのような文書があるか・メタデータはどのような現れ方をするか・メタデータ以外の文字列はどのような現れ方をするか、を考慮して細かい調整を行う必要がある。例えば、営業文書では顧客名は『行』の左隣に記載されることが多い。しかし、「行」の左隣に記載された文字列を顧客名として取得してしまうと、振込先として記載されている銀行名の一部を誤って顧客名として取得してしまうことが頻発する。
　モデルを用意するときの課題５：メタデータの部分文字列の特徴としてどのようなものを用いてメタデータを取得するべきかを、文書の特徴に応じて設定するのは煩雑である。例えば、日立ソフトウェアエンジニアリング株式会社は日立グループ企業との取引が多いので、部分文字列の特徴として「日立」を用いることに効果がある。このように各組織毎に取引先の傾向を調べて部分文字列を挙げることがモデルの完成度に寄与する。
　モデルを用意するときの課題６：メタデータの部分文字列の特徴の利用に当たっては、どのような文書があるか・メタデータはどのような現れ方をするか・メタデータ以外の文字列はどのような現れ方をするか、を考慮して細かい調整を行う必要がある。例えば「会社」という文字列は顧客名に含まれることが多い。しかし、「会社」を含む文字列を顧客名として取得してしまうと、「会社名」などの文字列を誤って顧客名として取得してしまうことが頻発する。
（２）特許文献４乃至６及び非特許文献３乃至８に示される技術にもそれぞれ問題点があり、定型でない文書からメタデータを正確に取得するためのモデル（文書内の注目すべき特徴）を用意するために適用することはできない。
　つまり、非特許文献３・特許文献４・５・６は、「請求書」や「住宅ローン申込み」など文書の詳細なクラスごとにモデルを用意する場合の技術について述べているものであり、取り扱う文書の種類が限定されていて、「営業文書」や「設計文書」などの広い範囲の文書をまとめて扱うことを想定しておらず、汎用的な技術とは言い難い。また、それぞれのクラスごとにモデルを使い分けるのは煩雑であり、業務文書の効率的な取扱いとして運用上現実的でない。
　また、非特許文献４・５・６・７は、論文のReferenceセクションを対象としており、文字列情報を入力として取扱うことを想定している。したがって、二次元平面上の広がりを持つ文書のデータを扱うことはできない。
　さらに、非特許文献８は、マニュアルを対象としており、見出し表現を利用している。営業文書や設計文書など一般の業務文書では見出し表現が記載されていない文書も多く、そのような文書を取扱うことはできない。
（３）本発明はこのような状況に鑑みてなされたものであり、メタデータを抽出するためのモデルを用意する工数を大幅に削減でき、各組織においてメタデータを自動的に取得する技術を提供するものである。
　上記課題を解決するために、本発明による文書データ処理装置は、処理対象の文書データ内の処理対象のメタデータが有するレイアウト特徴が、処理対象のメタデータを抽出する上で有効か否か判定し、その判定結果を出力する。より詳細には、文書データ処理装置は、処理対象のメタデータが有するレイアウト特徴が、処理対象の文書データにおけるメタデータ以外の文字列に現れているか否かチェックし、当該チェック結果に基づいてレイアウト特徴がメタデータを抽出する上で有効か否か判定する。また、文書データ処理装置は、同一のメタデータの種類が指定された複数の処理対象の文書データについて、レイアウト特徴がメタデータの文字列にのみ現れている文書数（ｎ１）と、レイアウト特徴がメタデータ以外の文字列にのみ現れている文書数（ｎ２）を算出し、文書数を出力すると共に、ｎ１＞ｎ２の場合に、当該レイアウト特徴を、当該メタデータを自動取得するのに注目すべき特徴であるモデルとして設定することを示す情報を提示する。
　本発明による文書データ処理装置は、処理対象の文書データ内の処理対象のメタデータの近傍の文字列特徴が、処理対象のメタデータを抽出する上で有効か否か判定し、その判定結果を出力する。より詳細には、文書データ処理装置は、近傍文字列特徴が処理対象のメタデータ以外の文字列の近傍に現れているか否かチェックし、当該チェック結果に基づいて近傍文字列特徴を処理対象のメタデータを抽出する上で有効か否か判定する。
　さらに、本発明による文書データ処理装置は、処理対象の文書データ内の処理対象のメタデータに含まれる部分文字列特徴が、処理対象のメタデータを抽出する上で有効か否か判定し、その判定結果を出力する。より詳細には、文書データ処理装置は、部分文字列特徴が処理対象のメタデータ以外の文字列に含まれているか否かチェックし、当該チェック結果に基づいて部分文字列特徴を処理対象のメタデータを抽出する上で有効か否か判定する。
　さらなる本発明の特徴は、以下本発明を実施するための最良の形態および添付図面によって明らかになるものである。
　本発明によれば、メタデータを抽出するためのモデルを用意する工数を大幅に削減でき、各組織においてメタデータを自動的に取得することができるようになる。
本発明による業務文書処理装置の概略構成を示す機能ブロック図である。 文書データおよび文字列データのデータ構造例を示す図である。 メタデータ種類データおよび近傍文字列特徴データのデータ構造例を示す図である。 業務文書処理装置において実行される処理手順の全体を説明するためのフローチャートである。 レイアウト特徴利用設定処理部で実行される詳細動作を説明するためのフローチャートである。 レイアウト特徴利用調整処理部で実行される詳細動作を説明するためのフローチャートである。 レイアウト情報利用調整処理部で表示される確認画面を示す図である。 近傍文字列特徴利用設定処理部で実行される詳細動作を説明するためのフローチャートである。 近傍文字列特徴利用調整処理部で実行される詳細動作を説明するためのフローチャートである。 近傍文字列特徴利用調整処理部で表示される確認画面例を示す図である。 部分文字列特徴利用設定処理部で実行される詳細動作を説明するためのフローチャートである。 部分文字列特徴利用調整処理部で実行される詳細動作を説明するためのフローチャートである。 部分文字列特徴利用調整処理部で表示される確認画面例を示す図である。
　本発明は、文書からメタデータを抽出する際に必要とされる特徴（モデル）を用意するための処理に関するものである。本実施形態では、用意されるモデルとして、メタデータのレイアウト特徴との関係、近傍文字列との関係、及びそれに含まれる部分文字列との関係が示されている。
　以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。
　＜業務文書管理装置の構成＞
　図１は、本発明の実施形態による業務文書処理装置の内部構成を概略的に示す機能ブロック図である。業務文書処理装置１は、データを表示するための表示装置１００と、サンプル文書ＤＢ１０１と、表示されたデータに対してメニューを選択するなどの操作を行うためのキーボード１０２と、マウスなどのポインティングデバイス１０３と、必要な演算処理や制御処理などを行う中央処理装置１０４と、中央処理装置１０４での処理に必要なプログラムを格納するプログラムメモリ１０５と、中央処理装置１０４での処理に必要なデータを格納するデータメモリ１０６と、を備えている。
　中央処理装置１０４は、メタデータ抽出のために利用するレイアウト特徴（例えば、「下線」「センタリング」等）を設定するレイアウト特徴利用設定処理部１０７と、メタデータ抽出のために利用する近傍文字列特徴（例えば、「御中」「様」等）を設定する近傍文字列特徴利用設定処理部１０８と、メタデータ抽出のために利用する部分文字列（例えば、「株式会社」「会社」等）を設定する部分文字列特徴利用設定処理部１０９と、を備えている。本実施形態の場合、コンピュータによって構成され、レイアウト特徴利用設定処理部１０７と、近傍文字列特徴利用設定処理部１０８と、部分文字列特徴利用設定処理部１０９は、いずれもコンピュータ上で実行されるプログラムの機能の一部として実現される。なお、これらのプログラムは、プログラムメモリ１０５に格納されている。
　レイアウト特徴利用設定処理部１０７は、メタデータ（例えば、「タイトル」）を抽出するのにあるレイアウト特徴（例えば、「下線」）を使うとどのようなメリット・デメリットがあるか（メタデータ抽出に有効か否か）チェックし、最終的に当該レイアウト特徴の利用・非利用の調整処理を実行するレイアウト特徴利用調整処理部１１０を備えている。近傍文字列特徴利用設定処理部１０８は、メタデータ（例えば、「顧客名」）を抽出するのにある近傍文字列特徴（例えば、「御中」）を使うとどのようなメリット・デメリットがあるか（メタデータ抽出に有効か否か）チェックし、最終的に当該近傍文字列特徴の利用・非利用の調整処理を実行する近傍文字列特徴利用調整処理部１１１を備えている。さらに、部分文字列特徴利用設定処理部１０９は、メタデータ（例えば、「顧客名」）を抽出するのにある部分文字列特徴（例えば、「会社」）を使うとどのようなメリット・デメリットがあるか（メタデータ抽出に有効か否か）チェックし、最終的に当該部分文字列特徴の利用・非利用の調整処理を実行する部分文字列特徴利用調整処理部１１２を備えている。
　データメモリ１０６は、文書データ格納部１１３と、文字列データ格納部１１４と、メタデータ種類データ格納部１１５と、近傍文字列特徴データ格納部１１６と、を備えている。
　＜文書データ及び文字列データのデータ構造＞
　図２は、データメモリ１０６に含まれる文書データ格納部１１３および文字列データ格納部１１４に格納される文書データ及び文字列データのデータ構造を示す図である。
　文書データは、文書ＩＤ２００と、文書のファイル名２０１と、記載内容２０２と、文書画像２０３とを含んでいる。記載内容２０２は、文字列データ構造体の配列の形で保持する。また、文書画像２０３は、文書の印刷イメージを画像形式で保持する。
　文字列データは、文字列ＩＤ２０４と、文字列の内容２０５と、正解メタデータ指定ＩＤ２０６と、隣接文字列ＩＤ２０７と、隣接セル文字列ＩＤ２０８と、レイアウト特徴２０９と、を含んでいる。
　正解メタデータ指定ＩＤ２０６は、その文字列（図２の例では「提案書」）をメタデータとして取得したいとユーザが指定した場合はメタデータの種類に応じたＩＤ（図２の例では、「タイトル」というメタデータ種類ＩＤ）を保持しており、そのような指定をしていない場合はＮＵＬＬ値を保持している。
　隣接文字列ＩＤ２０７は、二重の配列の形で隣接文字列の情報を保持する。一重目は上下左右の方向を表し、二重目はその方向に隣接する文字列があった場合にそのＩＤを保持する。二重目も配列になっていることで、同じ方向に隣接する文字列が複数ある場合に対応できる。図２の例では、「提案書」という文字列の上には二つの文字列（それぞれ文字列ＩＤはＳｔｒ＿０００２およびＳｔｒ＿０００３）、下には一つの文字列（文字列ＩＤはＳｔｒ＿０００４）、右には二つの文字列（それぞれ文字列ＩＤはＳｔｒ＿０００５およびＳｔｒ＿０００６）が隣接し、左に隣接する文字列はないことを示している。
　隣接セル文字列ＩＤ２０８は、隣接文字列ＩＤ２０７と同様に、対象の文字列（例えば「提案書」）が表の中に含まれている場合に、二重の配列の形で隣接セルの情報を保持する。一重目は上下左右の方向を表し、二重目はその方向に隣接するセルに文字列があった場合にそのＩＤを保持する。表の外に記載されている文字列や、表の中に記載されている文字列のうち隣接するセルがない文字列や、表の中に記載されている文字列で隣接するセルはあるがその中が空である文字列では、図２の例のように空の配列となる。
　レイアウト特徴２０９は、複数の種類のレイアウト特徴を持つかどうかを順に配列の形でどのようなレイアウト特徴を有しているかの情報を保持する。例えば、レイアウト特徴の例として、左から、センタリング、フォント、下線、Ｂｏｌｄ等とすると、これらの特徴が含まれるかをｔｒｕｅ又はｆａｌｓｅで示される。
　＜メタデータ種類データ及び近傍文字列特徴データのデータ構造＞
　図３は、データメモリ１０６に含まれるメタデータ種類データ１１５および近傍文字列特徴データ１１６のデータ構造を示す図である。つまり、図３の例では、メタデータとして「タイトル」を抽出する場合、３０２乃至３０４の特徴に着目すると効率良く当該メタデータを抽出できることが示されている。なお、図３の３０２乃至３０４のデータは、図２のデータを利用し、図４の処理（ステップ４０１乃至４０３の少なくとも何れか１つの処理）によって生成された結果（メタデータ抽出モデル）に相当する。
　メタデータ種類データは、メタデータ種類ＩＤ３００と、メタデータ種類名３０１と、利用レイアウト特徴３０２と、利用近傍文字列特徴３０３と、利用部分文字列特徴３０４と、を情報として含んでいる。
　利用レイアウト特徴３０２は、複数の種類のレイアウト特徴を利用するかどうかを順に配列の形で保持する。図３の例では、メタデータ「タイトル」に関しては、図２のレイアウト特徴２０９のうち「フォント」を利用すべきレイアウト特徴として設定されていることが示されている。
　また、利用近傍文字列特徴３０３は、近傍文字列特徴データの配列の形でメタデータ抽出に利用すると有効な近傍文字列の情報を保持する。図３の例では、近傍文字列「御中」がメタデータ「タイトル」を抽出するのに有効であることが示されている。また、近傍文字列特徴データは、文字列３０５および方向指定３０６を含んでいる。図３では、「『御中』という文字列がメタデータの『右隣』に記載されることが多い」という特徴を利用してメタデータを取得する例が示されている。
　利用部分文字列特徴３０４は、文字列の配列の形でメタデータ抽出に利用すると有効な部分文字列の情報を保持する。図３の例では、メタデータ「タイトル」を抽出するには、当該メタデータに「シート」や「申請書」という文字列が含まれていることを利用することが有効であることが示されている。
　＜メタデータ抽出モデル生成処理（全体）＞
　次に、上記のように構成された本実施形態の業務文書処理装置１において行われる処理について説明する。図４は、業務文書処理装置１において行われるメタデータ抽出モデル生成処理の全体の流れを概略的に示すフローチャートである。
　図４において、まず、中央処理装置１０４は、処理すべき文書をサンプル文書ＤＢ１０１から読み込み、文書データ１１３の形で保持する（ステップ４００）。なお、サンプル文書ＤＢ１０１に格納されている文書は、例えば「タイトル」や「顧客名」のようにユーザによって予めメタデータの種類が指定されている。
　次に、レイアウト特徴利用設定処理部１０７は、レイアウト上の特徴の利用を設定する処理を行う（ステップ４０１）。ここでの処理については、図５において詳細に説明する。
　また、近傍文字列特徴利用設定処理部１０８は、近傍に記載される文字列の特徴の利用を設定する処理を行う（ステップ４０２）。ここでの処理については、図８において詳細に説明する。
　そして、部分文字列特徴利用設定処理部１０９は、部分文字列の特徴の利用を設定する処理を行う（ステップ４０３）。ここでの処理については、図１１において詳細に説明する。
　なお、処理４０１乃至４０３は排他的な処理であり、それぞれ単独で実行しても良いし、組み合わせて実行しても良い。
　＜レイアウト特徴利用設定処理の詳細＞
　図５は、図４のステップ４０１の処理の詳細を説明するためのフローチャートである。まず、レイアウト特徴利用設定処理部１０７は、タイトル・作成者・作成日などのメタデータ種類について順に処理を行うため、インデックスｉを初期化する（ステップ５００）。
　次に、レイアウト特徴利用設定処理部１０７は、下線・センタリング・フォントサイズなどレイアウト上の特徴について順に処理を行うため、インデックスｊを初期化する（ステップ５０１）。
　その後、レイアウト特徴利用設定処理部１０７は、レイアウト特徴利用調整処理部１１０を用いて、ｊ番目のレイアウト上の特徴が有効だったサンプル文書・無効だったサンプル文書・効果が不明だったサンプル文書を基に、ｊ番目のレイアウト上の特徴はメタデータの取得に有効であると言えるか判断し、利用するかどうか設定する（ステップ５０２）。この処理については、図６において詳細に説明する。
　そして、レイアウト特徴利用設定処理部１０７は、レイアウト上の特徴のインデックスｊを１だけインクリメントし（ステップ５０３）、レイアウト上の特徴がまだ残っているならばステップ５０２に戻って処理をやり直す（ステップ５０４）。また、レイアウト特徴利用設定処理部１０７は、メタデータ種類のインデックスｉを１だけインクリメントし（ステップ５０５）、メタデータ種類がまだ残っているならばステップ５０１に戻って処理をやり直す（ステップ５０６）。
　図６は、図５のステップ５０２の処理の詳細を説明するためのフローチャートである。まず、レイアウト特徴利用調整処理部１１０は、レイアウト上の特徴がメタデータの取得に有効だったサンプル文書を数えるためのカウンタｎ１、無効だったサンプル文書を数えるためのカウンタｎ２、効果が不明だったサンプル文書を数えるためのカウンタｎ３を初期化する（ステップ６００）。また、レイアウト特徴利用調整処理部１１０は、ステップ４００で読み込んだサンプル文書について順に処理を行うため、インデックスｋを初期化する（ステップ６０１）。
　次に、レイアウト特徴利用調整処理部１１０は、ｋ番目のサンプル文書において文書データに含まれる記載内容２０２を確認し、レイアウト特徴２０９のｊ番目のレイアウト上の特徴がｔｒｕｅになっている文字列データと、正解メタデータ指定ＩＤ２０６として図５のｉ番目のメタデータにおけるメタデータ種類ＩＤ３００を持つ文字列データを比較する（ステップ６０２）。前者の文字列データと後者の文字列データが完全に一致する場合、ｊ番目のレイアウト上の特徴を用いればｋ番目のサンプル文書からｉ番目のメタデータを取得できることを意味する。従って、ｊ番目のレイアウト上の特徴が有効であったサンプル文書数ｎ１をインクリメントする。前者の文字列データと後者の文字列データとが異なるものである場合、ｊ番目のレイアウト上の特徴を用いてｋ番目のサンプル文書からｉ番目のメタデータを取得しようとすると間違ったものを取得してしまうことを意味する。従って、ｊ番目のレイアウト上の特徴が無効だったサンプル文書数ｎ２をインクリメントする。それ以外の場合は効果が不明であり、ｎ３をインクリメントする。例えば、メタデータ種類データが「タイトル」で、レイアウト上の特徴が「センタリング」の場合、ｋ番目の文書内において、タイトルであるとユーザによって指定された文字列がセンタリングされているかどうかチェックされ、さらにセンタリングされた文字列が指定タイトル以外にあるか否かチェックされる。指定文字列以外にセンタリングされた文字列がなければ、当該センタリングというレイアウト上の特徴は、メタデータ抽出に有効であることが分かり、ｎ１がインクリメントされる。
　その後、レイアウト特徴利用調整処理部１１０は、サンプル文書のインデックスｋを１だけインクリメントし（ステップ６０３）、サンプル文書がまだ残っているならばステップ６０２に戻って処理をやり直す（ステップ６０４）。次に、ｎ１，ｎ２，ｎ３の値を基に、図７に示す画面表示を行う（ステップ６０５）。例えば、レイアウト特徴「センタリング」を用いるとメタデータ（この例では「タイトル」）を抽出するのに有効な文章が多いのか、逆効果の文書が多いのかが画面表示され、これに基づいて、「センタリング」がタイトル取得に用いるべきか判断される。
　図７は、レイアウト上の特徴の利用設定結果表示画面（ＧＵＩ）を示す図である。当該結果表示画面では、どのメタデータ種類についてどのレイアウト上の特徴の利用要否がどのように設定されたか、それぞれ図５のｉの値・ｉ番目のメタデータ種類データのメタデータ種類名３０１・図６のｊの値・ｎ１，ｎ２，ｎ３の値を基に計算した利用要否が表示される（７００）。このうち利用要否は、例えば、ｎ１≧ｎ２の場合には有効、そうでなければ無効などと判定することができる。また、当該結果表示画面では、ｎ１，ｎ２，ｎ３の値が、利用要否の判定根拠をユーザに提供するための情報として表示される（７０１）。さらに、当該結果表示画面には、利用要否を表示すると共にユーザの指定を受付けるラジオボタンが７０２に配されている。ここで「使う」とユーザが指定したレイアウト上の特徴については、メタデータ種類データの利用レイアウト特徴３０２の該当する要素をｔｒｕｅに、「使わない」と指定されたレイアウト上の特徴についてはｆａｌｓｅに設定する。
　＜近傍文字列特徴利用設定処理の詳細＞
　図８は、図４のステップ４０２の処理の詳細を説明するためのフローチャートである。まず、近傍文字列特徴利用設定処理部１０８は、メタデータ種類インデックスｉ、近傍に記載される文字列の候補セットｓ、およびサンプル文書のインデックスｋを初期化する（ステップ８００、ステップ８０１、およびステップ８０２）。
　次に、近傍文字列特徴利用設定処理部１０８は、ｋ番目のサンプル文書における記載内容２０２に含まれる文字列データの正解メタデータ指定ＩＤ２０６を順に確認し、ｉ番目のメタデータ種類のＩＤ３００を持つ文字列データがあれば、隣接文字列ＩＤ２０７や隣接セル文字列ＩＤ２０８で保持している文字列ＩＤの文字列データの文字列２０５そのものや部分文字列を候補としてｓに追加する（ステップ８０３）。この際、正解メタデータ指定されている文字列のどちらの方向に隣接しているかに応じて近傍文字列特徴データの方向指定３０６にも値を設定する。その後、近傍文字列特徴利用設定処理部１０８は、サンプル文書のインデックスｋを１だけインクリメントし（ステップ８０４）、サンプル文書がまだ残っているならばステップ８０３に戻って処理をやり直す（ステップ８０５）。ここまでの処理によって、特定のメタデータ種類データ（例えば、「タイトル」）について、候補となる全ての近傍文字列データが収集される。
　次に、近傍文字列特徴利用設定処理部１０８は、候補セットｓに含まれる文字列について、その文字列を含む文字列の近傍に記載される文字列がメタデータであるかどうかを基に、候補文字列がメタデータの取得に有効であると言えるか判断し、利用するかどうか設定する（ステップ８０６）。つまり、特定のメタデータについて、候補文字列の周辺にある文字列が当該メタデータの文字列だけなのか、全く異なる文字列も存在するのか確認する（逆向きの確認）。例えば、メタデータ「顧客名」について、近傍文字「御中」の周辺には顧客名のみが存在するが、近傍文字「行」の周辺には必ずしも「顧客名」だけでなく、別の文字列（例えば、ＡＢＣＤ銀行）が来ることもあるので、「行」はメタデータ取得には有効ではないという判断がなされる。この処理の詳細については、図９を用いて説明する。
　そして、近傍文字列特徴利用設定処理部１０８は、メタデータ種類のインデックスｉを１だけインクリメントし（ステップ８０７）、メタデータ種類がまだ残っているならばステップ８０２に戻って処理をやり直す（ステップ８０８）。
　図９は、図８のステップ８０６の処理を詳細に説明するためのフローチャートである。まず、近傍文字列特徴利用調整処理部１１１は、候補文字列のインデックスｌ、サンプル文書のインデックスｋを初期化する（ステップ９００及び９０１）。
　次に、近傍文字列特徴利用調整処理部１１１は、ｋ番目のサンプル文書におけるｌ番目の候補文字列に対し、方向指定３０６で指定される方向に隣接している近傍文字列を確認する（ステップ９０２）。ここでは、ｋ番目の文書データの記載内容２０２を確認し、ｌ番目の候補文字列を含む文字列２０５があるか探す。そのような文字列データについて、隣接文字列ＩＤ２０７や隣接セル文字列ＩＤ２０８に保持している文字列ＩＤの文字列データが、正解メタデータ指定ＩＤ２０６に図８のｉ番目のメタデータにおけるメタデータ種類ＩＤ３００を持つか確認する。正解メタデータ指定ＩＤ２０６に値があり、かつ、ｉ番目のメタデータのメタデータ種類ＩＤ３００ではない場合、ｌ番目の候補文字列を用いてｋ番目のサンプル文書からメタデータを取得しようとすると間違ったものを取得してしまうことを意味する。従って、そのような場合は、近傍文字列特徴利用調整処理部１１１は、当該ｌ番目の候補文字列を利用しないとして設定する（ステップ９０３）。それ以外の場合は、近傍文字列特徴利用調整処理部１１１は、サンプル文書のインデックスｋを１だけインクリメントし（ステップ９０４）、サンプル文書がまだ残っているならばステップ９０２に戻って処理をやり直す（ステップ９０５）。
　全てのサンプル文書についてループ処理を終えたのであれば、近傍文字列特徴利用調整処理部１１１は、ｌ番目の候補文字列を利用するとして設定する（ステップ９０６）。その後、近傍文字列特徴利用調整処理部１１１は、ｌ番目の候補文字列の利用について図１０に示す画面表示を行う（ステップ９０７）。さらに、近傍文字列特徴利用調整処理部１１１は、候補文字列のインデックスｌを１だけインクリメントし（ステップ９０８）、候補文字列がまだ残っているならばステップ９０１に戻って処理をやり直す（ステップ９０９）。
　図１０は、近傍文字列の特徴の利用設定結果表示画面（ＧＵＩ）を示す図である。当該結果表示画面では、どのメタデータ種類についてどの近傍文字列の特徴の利用要否がどのように設定されたか、それぞれ図８のｉの値・ｉ番目のメタデータ種類データのメタデータ種類名３０１・図９のｌ番目の候補文字列・図９のステップ９０３またはステップ９０６で指定した利用要否が表示される（１０００）。また、当該結果表示画面では、図８のステップ８０３で候補文字列を登録した際のサンプル文書の文書画像２０３が１００１に表示され、図９のステップ９０３で利用しないと設定した場合はその際の文書画像２０３が１００２に表示される。
　また、図１０には、図９のステップ９０３または９０６で指定した利用要否を表示すると共にユーザの指定を受付けるラジオボタンが１００３に配置されている。ここで「使う」とユーザが指定した近傍文字列の特徴については、メタデータ種類データの利用近傍文字列特徴３０３にデータを保持する。
　＜部分文字列特徴利用設定処理の詳細＞
　図１１は、図４のステップ４０３の処理の詳細を説明するためのフローチャートである。まず、部分文字列特徴利用設定処理部１０９は、メタデータ種類インデックスｉ、部分文字列の候補セットｓ、およびサンプル文書のインデックスｋを初期化する（ステップ１１００、１１０１および１１０２）。
　次に、部分文字列特徴利用設定処理部１０９は、ｋ番目のサンプル文書における記載内容２０２に含まれる文字列データの正解メタデータ指定ＩＤ２０６を順に確認し、ｉ番目のメタデータ種類のＩＤ３００を持つ文字列データがあれば、文字列２０５そのものや部分文字列を候補としてｓに追加する（ステップ１１０３）。例えば、対象のメタデータ種類が「顧客名」で文字列データが「株式会社ＡＢＣＤ」であった場合、部分文字列候補として「株式会社」や「ＡＢＣＤ」等が追加される。
　続いて、部分文字列特徴利用設定処理部１０９は、サンプル文書のインデックスｋを１だけインクリメントし（ステップ１１０４）、サンプル文書がまだ残っているならばステップ１１０３に戻って処理をやり直す（ステップ１１０５）。
　また、部分文字列特徴利用設定処理部１０９は、候補セットｓに含まれる文字列について、その文字列を含む文字列がメタデータであるかどうかを基に、候補文字列がメタデータ取得に有効だったと言えるか判断し、利用するかどうか判断する（ステップ１１０６）。この処理については、図１２を用いて詳細に説明する。
　そして、部分文字列特徴利用設定処理部１０９は、メタデータ種類のインデックスｉを１だけインクリメントし（ステップ１１０７）、メタデータ種類がまだ残っているならばステップ１１０２に戻って処理をやり直す（ステップ１１０８）。
　図１２は、図１１のステップ１１０６の詳細を説明するためのフローチャートである。まず、部分文字列特徴利用調整処理部１１２は、候補文字列のインデックスｌ、サンプル文書のインデックスｋを初期化する（ステップ１２００、及び１２０１）。
　次に、部分文字列特徴利用調整処理部１１２は、ｋ番目のサンプル文書においてｉ番目以外のメタデータでｌ番目の候補文字列を含むものがあるか調べる（ステップ１２０２）。ここでは、ｋ番目の文書データの記載内容２０２を確認し、ｌ番目の候補文字列を含む文字列２０５があるか探す。そのような文字列データについて、正解メタデータ指定ＩＤ２０６に図１１のｉ番目のメタデータにおけるメタデータ種類ＩＤ３００を持つか確認する。正解メタデータ指定ＩＤ２０６に値があり、かつ、ｉ番目のメタデータ種類ＩＤ３００ではない場合、ｌ番目の候補文字列を用いてｋ番目のサンプル文書からメタデータを取得しようとすると間違ったものを取得してしまうことを意味する。従って、そのような場合はｌ番目の候補文字列を利用しないとして設定する（ステップ１２０３）。例えば、上述のように、対象のメタデータ種類が「顧客名」で文字列データが「株式会社ＡＢＣＤ」であった場合に、顧客名でないのに「株式会社」という文字列を含むメタデータがある場合は、候補文字列として使用しないと判断される。
　それ以外の場合は、部分文字列特徴利用調整処理部１１２は、サンプル文書のインデックスｋを１だけインクリメントし（ステップ１２０４）、サンプル文書がまだ残っているならばステップ１２０２に戻って処理をやり直す（ステップ１２０５）。全てのサンプル文書についてループ処理を終えたのであれば、ｌ番目の候補文字列を利用するとして設定する（ステップ１２０５）。
　そして、部分文字列特徴利用調整処理部１１２は、ｌ番目の候補文字列の利用について図１３に示す画面表示を行い（ステップ１２０７）、候補文字列のインデックスｌを１だけインクリメントし（ステップ１２０８）、候補文字列がまだ残っているならばステップ１２０１に戻って処理をやり直す（ステップ１２０９）。
　図１３は、部分文字列の特徴の利用設定結果表示画面（ＧＵＩ）を示す図である。図１３の結果表示画面では、どのメタデータ種類についてどの部分文字列の特徴の利用要否がどのように設定されたか、それぞれ図１１のｉの値・ｉ番目のメタデータ種類データのメタデータ種類名３０１・図１２のｌ番目の候補文字列・図１２のステップ１２０３またはステップ１２０６で指定した利用要否が表示される（１３００）。
　また、当該結果表示画面では、図１１のステップ１１０３で候補文字列を登録した際のサンプル文書の文書画像２０３が１３０１に表示され、図１２のステップ１２０３で利用しないと設定した場合はその際の文書画像２０３が１３０２に表示される。
　さらに、当該結果表示画面には、図１２のステップ１２０３または１２０６で指定した利用要否を表示すると共にユーザの指定を受付けるラジオボタンが１３０３に配置されている。ここで「使う」とユーザが指定した部分文字列の特徴については、メタデータ種類データの利用部分文字列特徴３０４にデータが保持される。
　＜変形例＞
　以上、本発明の基本的な実施形態について説明したが、以下のような変形例も考えられる。
（１）本明細書では、レイアウト特徴２０９がｔｒｕｅまたはｆａｌｓｅの２値の配列の形で保持される例について説明したが、スコア数値で保持される場合も考えられる。例えば、文書中にセンタリングされている文字列が非常に少ない場合には、センタリングされている文字列に高いスコアを与え、文書中に記載されている文字列の大半がセンタリングされている場合には、センタリングされている文字列にあまり高くないスコアを与えるような方式である。また、例えば文字列のフォントサイズに応じたスコアを与えるような方式もある。これらのような数値でのレイアウト上の特徴の保持を行う場合でも、本発明は有効である。この場合、ステップ６０２での比較において、記載内容２０２の中でスコアが最大になっている文字列データを比較対象とすれば良い。
（２）本明細書では、レイアウト上の特徴の利用の要否はステップ６０５のように利用する・しないの２値で設定する例について説明したが、重み付け和の形で設定される場合も考えられる。例えば、タイトルの取得にあたってはセンタリングとフォントサイズの大きさを２：３の比率で利用する（センタリングだけが指定されている文字列のスコアは２、フォントサイズが大きいだけの文字列のスコアは３、センタリングされておりフォントサイズも大きい文字列のスコアは５とする）などの指定を行うような方式である。このような方式においても、本発明は有効である。その場合、本明細書で述べた方式で利用するレイアウト上の特徴を選別した後で、重み付けを様々に変えながらメタデータ取得精度を評価し、高精度が達成できる重み付けを最終的にモデルに記述すれば良い。
（３）本明細書では、近傍文字列特徴データでは文字列そのもの３０５に加えて方向指定３０６を保持する例について説明したが、その他に接頭辞や接尾辞の指定を伴って行われる場合も考えられる。例えば、「御中」という文字列の左隣に顧客名が記載されるとする場合、「御中」の前後に文字が付加する可能性は低い。従って、「御中」は接頭辞・接尾辞の指定を共にＯＮにすることが適切である。
　これに対し、「注文番号」という文字列の右隣に注文番号が記載されるとする場合、取引先によっては「御社注文番号」であったり「注文番号（継続取引分）」であったりと、「注文番号」の前後に文字が付加される可能性があるとする。この場合は、接頭辞・接尾辞の指定をＯＦＦにすることが適切である。このような指定を行える方式にも、本発明は有効である。その場合、メタデータの近傍に記載された文字列をそのまま特徴として利用する場合は接頭辞・接尾辞の指定をＯＮにし、近傍に記載された文字列の部分文字列を特徴として利用する場合は接頭辞・接尾辞指定を変えれば良い。
（４）本明細書では、部分文字列の特徴の利用はひとまとめにしてステップ１１０３で候補文字列として登録しているが、接頭辞や接尾辞の指定を付加して登録することも考えられる。例えば、「独立行政法人」という文字列が顧客名に含まれるとする場合、「独立行政法人」の前に文字が付加される可能性は低いが、後ろに文字が付加される可能性は高い。この場合は、接頭辞の指定はＯＮ、接尾辞の指定はＯＦＦにすることが適切である。このような指定を行える方式にも、本発明は有効である。その場合、メタデータをそのまま特徴として利用する場合は接頭辞・接尾辞の指定をＯＮにし、部分文字列を特徴として利用する場合は接頭辞・接尾辞指定を変えれば良い。
（５）本明細書では、ステップ６０５の説明部分で、ｎ１とｎ２の大小関係のみからｊ番目のレイアウト上の特徴を利用するかどうかを設定している。これにさらに条件を加え、レイアウト上の特徴のうち、ｎ１とｎ２の差が大きい順からあらかじめ定義した個数だけのものを利用するように設定しても良い。これにより、過学習の回避により重きを置いたモデルを用意することができる。
（６）本明細書では、ステップ９０２で、近傍にｉ番目以外のメタデータがある場合のみ候補文字列を利用しないと設定している。これにさらに条件を加え、近傍にある文字列がｉ番目のメタデータではない場合は全て「候補文字列を利用しない」と設定するようにしても良い。これにより、（メタデータであるものを逃さず取得できる確率ではなく）メタデータではないものを確実に避ける精度により重きを置いたモデルを用意することができる。
（７）本明細書では、ステップ１２０２で、ｉ番目以外のメタデータでｌ番目の候補文字列を含むものがある場合のみ候補文字列を利用しないと設定している。これにさらに条件を加え、ｉ番目のメタデータ以外の文字列がｌ番目の候補文字列を含む場合は全て「候補文字列を利用しない」と設定しても良い。これにより、（メタデータであるものを逃さず取得できる確率ではなく）メタデータではないものを確実に避ける精度により重きを置いたモデルを用意することができる。
　＜まとめ＞
　本発明の実施形態による業務文書処理装置では、処理対象の文書データ内の処理対象のメタデータが有するレイアウト特徴、処理対象のメタデータの近傍の文字列特徴、及び処理対象のメタデータに含まれる部分文字列特徴の少なくとも１つが、処理対象のメタデータを文書データから抽出する上で有効か否か判定し、その判定結果を出力する。このようにすることにより、文書とその中に記載されたメタデータの組を指定するだけで、メタデータの自動取得におけるレイアウト上の特徴の利用・メタデータの近傍に記載される文字列の特徴の利用・メタデータの部分文字列の特徴の利用を自動的に設定できる。
　より詳細には、レイアウト特徴利用設定処理部及びレイアウト特徴利用調整部は、処理対象のメタデータ（例えば、タイトル）が有するレイアウト特徴（例えば、センタリング）が、処理対象の文書データにおけるメタデータ以外の文字列に現れているか否かチェックし、当該チェック結果に基づいてレイアウト特徴がメタデータを抽出する上で有効か否か判定する。また、近傍文字列特徴利用設定処理部及び近傍文字列特徴利用調整処理部は、近傍文字列特徴（例えば、御中）が処理対象のメタデータ（例えば、顧客名）以外の文字列の近傍に現れているか否かチェックし、当該チェック結果に基づいて近傍文字列特徴を処理対象のメタデータを抽出する上で有効か否か判定する。
　さらに、部分文字列特徴利用設定処理部及び部分文字列特徴利用調整処理部は、部分文字列特徴（例えば、独立行政法人）が処理対象のメタデータ（例えば、顧客名）以外の文字列に含まれているか否かチェックし、当該チェック結果に基づいて部分文字列特徴を処理対象のメタデータを抽出する上で有効か否か判定する。これにより、メタデータはどのような現れ方をするか、メタデータ以外の文字列はどのような現れ方をするか、を考慮した細かい調整も自動的に行え、メタデータ抽出を効率的に実行することができると共に、これらの調整が文書の特徴に基づいてなされるので文書の処理も迅速に行うことが可能となる。よって、メタデータ抽出モデルを用意する工数を大幅に削減でき、各組織においてメタデータを自動的に取得する技術を利用可能になる。すなわち、メタデータを用いて文書を管理・検索する業務文書処理装置を容易に導入できるようになる。
　また、レイアウト特徴利用設定処理部及びレイアウト特徴利用調整処理部は、同一のメタデータの種類（タイトル）が指定された複数の処理対象の文書データについて、レイアウト特徴がメタデータの文字列にのみ現れている文書数（ｎ１）と、レイアウト特徴がメタデータ以外の文字列にのみ現れている文書数（ｎ２）と、レイアウト特徴がメタデータの文字列及びそれ以外の文字列の両方に現れている文書数（ｎ３）を算出し、それぞれの文書数を表示すると共に、ｎ１＞ｎ２の場合に、当該レイアウト特徴を、当該メタデータを自動取得するのに注目すべき特徴であるモデルとして設定することを示す情報を表示部（ＧＵＩ）に表示する。このように処理された文書を分類し、分類結果をユーザに提示することができるので、ユーザが提示された基準をそのまま用いるか否かの判断をする手助けとなる。
　なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
　また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
　また、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ-ＲＷ、ＣＤ-Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ(又はＣＰＵやＭＰＵ)が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
１００・・・表示装置
１０１・・・サンプル文書ＤＢ
１０２・・・キーボード
１０３・・・ポインティングデバイス
１０４・・・中央処理装置
１０５・・・プログラムメモリ
１０６・・・データメモリ
１０７・・・レイアウト特徴利用設定処理部
１０８・・・近傍文字列特徴利用設定処理部
１０９・・・部分文字列特徴利用設定処理部
１１０・・・レイアウト特徴利用調整処理部
１１１・・・近傍文字列特徴利用調整処理部
１１２・・・部分文字列特徴利用調整処理部
１１３・・・文書データ格納部
１１４・・・文字列データ格納部
１１５・・・メタデータ種類データ格納部
１１６・・・近傍文字列特徴データ格納部

Claims (11)

  1. 　文書中のメタデータを用いて文書を管理する文書データ処理装置であって、
    　文書中に含まれるメタデータの種類が指定された、処理対象の文書データを取得する文書データ取得部と、
    　前記処理対象の文書データ内の処理対象のメタデータが有するレイアウト特徴が、前記処理対象のメタデータを抽出する上で有効か否か判定するレイアウト特徴判定処理部と、
    　前記レイアウト特徴判定処理部による判定結果を出力する出力部と、
    を備えることを特徴とする文書データ処理装置。
  2. 　請求項１において、
    　前記レイアウト特徴判定処理部は、前記処理対象のメタデータが有するレイアウト特徴が、前記処理対象の文書データにおける前記メタデータ以外の文字列に現れているか否かチェックし、当該チェック結果に基づいて前記レイアウト特徴が前記メタデータを抽出する上で有効か否か判定することを特徴とする文書データ処理装置。
  3. 　請求項２において、
    　前記文書データ取得部は、複数の文書データを処理対象として取得し、
    　前記レイアウト特徴判定処理部は、同一のメタデータの種類が指定された複数の処理対象の文書データについて、前記レイアウト特徴が前記メタデータの文字列にのみ現れている文書数（ｎ１）と、前記レイアウト特徴が前記メタデータ以外の文字列にのみ現れている文書数（ｎ２）を算出し、
    　前記出力部は、前記文書数を出力すると共に、ｎ１＞ｎ２の場合に、当該レイアウト特徴を、当該メタデータを自動取得するのに注目すべき特徴であるモデルとして設定することを示す情報を提示することを特徴とする文書データ処理装置。
  4. 　文書中のメタデータを用いて文書を管理する文書データ処理装置であって、
    　文書中に含まれるメタデータの種類が指定された、処理対象の文書データを取得する文書データ取得部と、
    　前記処理対象の文書データ内の処理対象のメタデータの近傍の文字列特徴が、前記処理対象のメタデータを抽出する上で有効か否か判定する近傍文字列特徴判定処理部と、
    　前記近傍文字列特徴判定処理部による判定結果を出力する出力部と、
    を備えることを特徴とする文書データ処理装置。
  5. 　請求項４において、
    　前記近傍文字列特徴判定処理部は、前記近傍文字列特徴が前記処理対象のメタデータ以外の文字列の近傍に現れているか否かチェックし、当該チェック結果に基づいて前記近傍文字列特徴が前記処理対象のメタデータを抽出する上で有効か否か判定することを特徴とする文書データ処理装置。
  6. 　文書中のメタデータを用いて文書を管理する文書データ処理装置であって、
    　文書中に含まれるメタデータの種類が指定された、処理対象の文書データを取得する文書データ取得部と、
    　前記処理対象の文書データ内の処理対象のメタデータに含まれる部分文字列特徴が、前記処理対象のメタデータを抽出する上で有効か否か判定する部分文字列特徴判定処理部と、
    　前記部分文字列特徴判定処理部による判定結果を出力する出力部と、
    を備えることを特徴とする文書データ処理装置。
  7. 　請求項６において、
    　前記部分文字列特徴判定処理部は、前記部分文字列特徴が前記処理対象のメタデータ以外の文字列に含まれているか否かチェックし、当該チェック結果に基づいて前記部分文字列特徴が前記処理対象のメタデータを抽出する上で有効か否か判定することを特徴とする文書データ処理装置。
  8. 　文書中のメタデータを用いて文書を管理する文書データ処理装置であって、
    　文書中に含まれるメタデータの種類が指定された、処理対象の文書データを取得する文書データ取得部と、
    　前記処理対象の文書データ内の処理対象のメタデータが有するレイアウト特徴、前記処理対象のメタデータの近傍の文字列特徴、及び前記処理対象のメタデータに含まれる部分文字列特徴のうち、少なくとも２つの特徴が前記処理対象のメタデータを抽出する上で有効か否か判定する特徴判定処理部と、
    　前記特徴判定処理部による判定結果を出力する出力部と、
    を備えることを特徴とする文書データ処理装置。
  9. 　請求項８において、
    　前記特徴判定処理部は、前記処理対象のメタデータが有するレイアウト特徴が、前記処理対象の文書データにおける前記メタデータ以外の文字列に現れているか否かチェックし、当該チェック結果に基づいて前記レイアウト特徴が前記メタデータを抽出する上で有効か否か判定することを特徴とする文書データ処理装置。
  10. 　請求項８において、
    　前記特徴判定処理部は、前記近傍文字列特徴が前記処理対象のメタデータ以外の文字列の近傍に現れているか否かチェックし、当該チェック結果に基づいて前記近傍文字列特徴が前記処理対象のメタデータを抽出する上で有効か否か判定することを特徴とする文書データ処理装置。
  11. 　請求項８において、
    　前記特徴判定処理部は、前記部分文字列特徴が前記処理対象のメタデータ以外の文字列に含まれているか否かチェックし、当該チェック結果に基づいて前記部分文字列特徴が前記処理対象のメタデータを抽出する上で有効か否か判定することを特徴とする文書データ処理装置。
PCT/JP2010/062417 2009-07-27 2010-07-23 文書データ処理装置 WO2011013587A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP10804333.2A EP2461255A4 (en) 2009-07-27 2010-07-23 Document data processing device
US13/380,561 US8768941B2 (en) 2009-07-27 2010-07-23 Document data processing device
CN201080028233.2A CN102473176B (zh) 2009-07-27 2010-07-23 文档数据处理装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009-174502 2009-07-27
JP2009174502A JP5340847B2 (ja) 2009-07-27 2009-07-27 文書データ処理装置

Publications (1)

Publication Number Publication Date
WO2011013587A1 true WO2011013587A1 (ja) 2011-02-03

Family

ID=43529244

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/062417 WO2011013587A1 (ja) 2009-07-27 2010-07-23 文書データ処理装置

Country Status (5)

Country Link
US (1) US8768941B2 (ja)
EP (1) EP2461255A4 (ja)
JP (1) JP5340847B2 (ja)
CN (1) CN102473176B (ja)
WO (1) WO2011013587A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BRPI1000577B1 (pt) * 2010-02-19 2020-10-13 Alexandre Jonatan Bertoli Martins método e sistema para extração e gerenciamento de informações contidas em documentos eletrônicos
JP6760244B2 (ja) * 2017-10-31 2020-09-23 京セラドキュメントソリューションズ株式会社 文書管理システム及び文書管理サーバー
JP2022547750A (ja) 2019-09-16 2022-11-15 ドキュガミ インコーポレイテッド クロスドキュメントインテリジェントオーサリングおよび処理アシスタント
US11880435B2 (en) * 2020-02-12 2024-01-23 Servicenow, Inc. Determination of intermediate representations of discovered document structures

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007219922A (ja) * 2006-02-17 2007-08-30 Nec Corp 意味情報抽出システム、意味情報抽出方法、及び意味情報抽出プログラム
WO2008093569A1 (ja) * 2007-01-29 2008-08-07 Nec Corporation 情報抽出規則作成支援システム、情報抽出規則作成支援方法及び情報抽出規則作成支援プログラム
JP2008310531A (ja) * 2007-06-13 2008-12-25 Hitachi Computer Peripherals Co Ltd 帳票識別方法及び帳票識別プログラム並びに該帳票識別方法を用いた光学文字読取システム

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3425834B2 (ja) 1995-09-06 2003-07-14 富士通株式会社 文書画像からのタイトル抽出装置および方法
US6353840B2 (en) 1997-08-15 2002-03-05 Ricoh Company, Ltd. User-defined search template for extracting information from documents
JPH11184894A (ja) 1997-10-07 1999-07-09 Ricoh Co Ltd 論理要素抽出方法および記録媒体
JPH11328306A (ja) 1998-03-09 1999-11-30 Ricoh Co Ltd 文書画像の論理要素抽出方法、装置および記録媒体
JP2000090117A (ja) 1998-07-16 2000-03-31 Ricoh Co Ltd 文書画像の論理要素抽出方法、装置および記録媒体
US6456738B1 (en) 1998-07-16 2002-09-24 Ricoh Company, Ltd. Method of and system for extracting predetermined elements from input document based upon model which is adaptively modified according to variable amount in the input document
US7149347B1 (en) 2000-03-02 2006-12-12 Science Applications International Corporation Machine learning of document templates for data extraction
JP3425408B2 (ja) 2000-05-31 2003-07-14 株式会社東芝 文書読取装置
CN100382096C (zh) * 2003-08-20 2008-04-16 奥西-技术有限公司 文档扫描设备及方法
WO2005020131A1 (en) * 2003-08-20 2005-03-03 Oce-Technologies B.V. Document scanner
US20060085442A1 (en) * 2004-10-20 2006-04-20 Kabushiki Kaisha Toshiba Document image information management apparatus and document image information management program
US7444325B2 (en) * 2005-01-14 2008-10-28 Im2, Inc. Method and system for information extraction
US20070011183A1 (en) * 2005-07-05 2007-01-11 Justin Langseth Analysis and transformation tools for structured and unstructured data
US20110296291A1 (en) * 2007-11-15 2011-12-01 Olya Melkinov System and method for transforming documents for publishing electronically

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007219922A (ja) * 2006-02-17 2007-08-30 Nec Corp 意味情報抽出システム、意味情報抽出方法、及び意味情報抽出プログラム
WO2008093569A1 (ja) * 2007-01-29 2008-08-07 Nec Corporation 情報抽出規則作成支援システム、情報抽出規則作成支援方法及び情報抽出規則作成支援プログラム
JP2008310531A (ja) * 2007-06-13 2008-12-25 Hitachi Computer Peripherals Co Ltd 帳票識別方法及び帳票識別プログラム並びに該帳票識別方法を用いた光学文字読取システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2461255A4 *

Also Published As

Publication number Publication date
EP2461255A1 (en) 2012-06-06
CN102473176A (zh) 2012-05-23
US20120179718A1 (en) 2012-07-12
CN102473176B (zh) 2015-01-07
JP5340847B2 (ja) 2013-11-13
JP2011028568A (ja) 2011-02-10
EP2461255A4 (en) 2017-08-30
US8768941B2 (en) 2014-07-01

Similar Documents

Publication Publication Date Title
CN110163478B (zh) 一种合同条款的风险审查方法及装置
RU2613846C2 (ru) Метод и система извлечения данных из изображений слабоструктурированных документов
US20070300295A1 (en) Systems and methods to extract data automatically from a composite electronic document
KR20130095171A (ko) 포렌식 시스템과 포렌식 방법 및 포렌식 프로그램
US9164973B2 (en) Processing a reusable graphic in a document
US20210366055A1 (en) Systems and methods for generating accurate transaction data and manipulation
JP5023176B2 (ja) 特徴語抽出装置及びプログラム
US10699112B1 (en) Identification of key segments in document images
CN112818093A (zh) 基于语义匹配的证据文档检索方法、系统及存储介质
CN109033385A (zh) 图片检索方法、装置、服务器及存储介质
CN111506608A (zh) 一种结构化文本的比较方法和装置
Baluja Learning typographic style: from discrimination to synthesis
US10146881B2 (en) Scalable processing of heterogeneous user-generated content
JP5340847B2 (ja) 文書データ処理装置
CN112434884A (zh) 一种供应商分类画像的建立方法及装置
CN110737770B (zh) 文本数据敏感性识别方法、装置、电子设备及存储介质
CN112464927B (zh) 一种信息提取方法、装置及系统
Sabatelli et al. Advances in Digital Music Iconography: Benchmarking the detection of musical instruments in unrestricted, non-photorealistic images from the artistic domain
JP2004334341A (ja) 文書検索装置、文書検索方法及び記録媒体
CN114519568A (zh) 审单方法、装置、电子设备和存储介质
Chia et al. Text extraction and categorization from watermark scientific document in bulk
US11367442B2 (en) Device and method with input
CN116303909B (zh) 一种电子投标文件与条款的匹配方法、设备及介质
US11763094B2 (en) Cascade pooling for natural language processing
CN113505570B (zh) 参考文献参见落空的审校方法、装置、设备及存储介质

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201080028233.2

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10804333

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010804333

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13380561

Country of ref document: US