WO2010047286A1 - 検索システム、検索方法およびプログラム - Google Patents

検索システム、検索方法およびプログラム Download PDF

Info

Publication number
WO2010047286A1
WO2010047286A1 PCT/JP2009/067929 JP2009067929W WO2010047286A1 WO 2010047286 A1 WO2010047286 A1 WO 2010047286A1 JP 2009067929 W JP2009067929 W JP 2009067929W WO 2010047286 A1 WO2010047286 A1 WO 2010047286A1
Authority
WO
WIPO (PCT)
Prior art keywords
search
document
block
hash value
documents
Prior art date
Application number
PCT/JP2009/067929
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 US13/124,822 priority Critical patent/US9031935B2/en
Priority to JP2010534793A priority patent/JP5138046B2/ja
Priority to EP09821983A priority patent/EP2367121A4/en
Publication of WO2010047286A1 publication Critical patent/WO2010047286A1/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/33—Querying
    • G06F16/3331—Query processing

Definitions

  • the present invention relates to a search system that makes it possible to detect which documents are searched with duplicate contents in the search results, a search method thereof, and a computer-readable program for realizing the method.
  • search engine As a system for searching documents stored in a database connected to a network such as the Internet. Some of these search engines have a full-text search function for searching for a specific character string from a plurality of documents.
  • a full-text search engine equipped with a full-text search function has a sequential search type that sequentially scans the contents of a plurality of documents and searches for a character string to be searched, and a huge number of documents to be searched. For this reason, an index with a table structure consisting of data such as character strings, the location of the document, update date, and appearance frequency is created in advance. Index type.
  • indexes used in the index type, and a general one is called a transposed index having a variable-length record composed of a word and a document file ID including the word. is there.
  • FIGS. 1 and 2 show an example of a data structure for storing three documents, a transposed index for them, and a collected document.
  • the documents shown in FIGS. 1A to 1C have document file IDs 1 to 3 in order, and are all e-mails.
  • the transposed index shown in FIG. 2A is composed of a key word and an ID including the word.
  • the document includes the words “PHP”, “Suzuki”, and “Code”. Are associated.
  • the key word is associated with the contents of the document corresponding to the word.
  • the document content corresponding to the selected word is displayed in the right column.
  • FIG. 3 shows the configuration of the search engine described in Patent Document 4.
  • the search engine 10 is connected to a data source 20 that holds a document to be searched, and is connected to a client device 30 that outputs a query input by a user to obtain a search result.
  • the search engine 10 includes a crawler 12 that registers documents in the database 11 of the search engine 10 itself and periodically acquires documents on the data source 20 in order to create an index.
  • the crawler 12 repeats the operation of requesting a copy of a document used for index creation, following a link included in the document, and collecting another document. Further, when the crawler 12 finds a new document, the crawler 12 registers the new document in the database 11. When the crawler 12 detects that the document does not exist, the crawler 12 deletes the document from the database 11.
  • the search engine 10 includes a parser 13 that extracts text from a document acquired by the crawler 12 and registered in the database 11, and extracts format information such as paragraphs.
  • the parser 13 performs parsing, and inputs text and format information extracted by parsing into a data structure called a store 14 that stores collected documents.
  • the search engine 10 includes an indexer 15 that creates an index from text and format information extracted by the parser 13. As described above, the indexer 15 stores the key word and the ID of the document including the word in the index 16 in association with each other.
  • the search engine 10 further responds to the query received from the client device 30 by using the search term included in the query as a key and the search runtime 17 as a search server that searches for a document including the search term,
  • a query related information creation device 18 that receives a search result from the runtime 17, acquires a document including the search word from the store 14, and generates a character string including the search word, and uses the generated character string as a search result document.
  • a query related information comparison device 19 for comparison is provided.
  • the query related information creation device 18 For each search and each search result, the query related information creation device 18 generates a character string including a search word, and the query related information comparison device 19 compares the character strings, thereby making the entire sentence. A match or a match in several sampled documents is detected as a related document.
  • Conventional search engines have the same content, but if they exist as different documents, they are handled as individual search results, so documents with the same or similar content are excluded in advance when collecting documents or creating an index. can do.
  • the conventional search engine can only determine documents having the same content or similar contents in the whole sentence or several parts of the document, and determine documents having the same contents or similar contents with partial identity. It is not possible.
  • the search results are returned without considering the relationship between the documents. Therefore, the user needs the documents that are truly necessary one by one for each of the returned search results. You must judge whether or not.
  • the present invention divides the text that constitutes a document into a plurality of blocks, focuses on a block including a search word, and groups documents having the same block contents among the search result documents.
  • the documents have the same contents or similar contents with partial identity, and to return a search result considering the relationship between the documents.
  • the text in the document to be searched is divided into a plurality of blocks.
  • a block can be a sentence (sentence), a paragraph (paragraph), or the like.
  • a hash value is calculated for each block obtained in this way.
  • the hash value is a numerical value corresponding to the character string. This hash value is held in association with the document together with the position information of the block in the document.
  • the corresponding hash value is extracted based on the position information where the search word appears, and the documents having the same hash value are grouped and output.
  • a document to be searched is divided into a plurality of blocks based on specified division information, and a hash function is applied to a character string included in each block to A calculation unit that calculates a hash value of a block, a storage unit that stores the obtained hash value together with position information of the block in the document, and a block including the search word for each document obtained by searching based on the search word
  • a search system including a document grouping unit that takes out a corresponding hash value from a storage unit based on position information, groups documents having the same hash value, and outputs the result as a search result.
  • the division unit divides each sentence by at least one of sentences, paragraphs, blank lines, and additional information added to the document.
  • additional information an HTML tag in an HTML document can be cited.
  • the division unit is not limited to one, and can be divided using a plurality of pieces of division information. For example, when a specific search word is used, division information for each paragraph is used, and other search is performed. When words are used, division information for each sentence can be used. In addition, by making it possible to use a plurality of pieces of division information in this way, when the user or the system determines that grouping by division for each sentence is not appropriate, division information for each paragraph other than each sentence is used. And can be grouped.
  • the document is a token string in which a plurality of words (tokens) are arranged in order, and the character string included in each block is composed of at least one token. Therefore, the position of each block can be represented by the number of tokens, and the position information can include the token order from the first token of the document to the first token of each block. The position information can also include the order of tokens from the first token of the document to the last token of each block, and the number of these two tokens can be in the range from the beginning to the end of the token string that constitutes the block. it can.
  • the position of each block can be represented by the number of characters.
  • the position information includes the number of characters from the first character of the document to the first character of the character string included in each block.
  • the position information can also include the number of characters from the first character of the document to the last character of each block, and the two character numbers can be in the range from the beginning to the end of the character string constituting the block.
  • the calculation unit calculates a hash value by applying a hash function to the character string excluding the character type.
  • the symbol “>” is added when quoting the received content, but it is grouped as a document with the same hash value by calculating the hash value from the character string excluding this symbol “>”. It becomes possible.
  • the document grouping unit includes a sorting unit that sorts a plurality of documents included in the group based on the search score. Thereby, the plurality of documents included in the group are arranged in the order of the search score.
  • a search method performed by the search system can also be provided. This method includes processing steps executed by the division unit, the calculation unit, the storage unit, and the document grouping unit.
  • This search method can also be realized by configuring as a program and executing the program.
  • This program can be provided by being stored in a recording medium.
  • the search system By providing the search system, the search method, the program, and the recording medium of the present invention, it becomes easy to find a truly necessary document from the search results, and the labor for searching for the required document is reduced and the search time is shortened. It becomes possible.
  • the figure which illustrated three documents used as search object The figure which showed the example of the data structure which stores the transposition index with respect to the document shown in FIG. 1, and the collected document.
  • the figure which illustrated three documents used as search object The figure which illustrated three documents used as search object.
  • FIG. 4 illustrates a network system including a data source that holds a document to be searched, a client device that makes a search request, and a server device that has a search engine that receives the search request and performs search processing.
  • FIG. Here, only one data source 100, one client device 200, and one server device 300 are shown, but two or more may be connected to the network 400. Further, the data source 100 and the server apparatus 300 may be directly connected.
  • the data source 100 may be any device as long as it is a device that holds a document, and may be a database that collects and manages data for each item or another server device.
  • the data source 100 may be a PC that holds a document and is used by another user.
  • the database has a plurality of relations (relationships) as a basic data type, and a query for obtaining stored data is a relational operator such as an equal sign or an inequality sign. It is possible to use a relational database performed using logical operators such as logical product, logical sum, and negation.
  • the database may be constructed directly on a file system provided by an operating system (OS) or may be constructed using a database management system (DBMS).
  • OS operating system
  • DBMS database management system
  • the client device 200 may be any device that can output a search request, and includes an application that generates a search request for a search term input by a user and enables an inquiry via a network. It can be a PC. This PC has a keyboard for a user to input a search word, a mouse for designating an input position and giving a search start instruction, a display device for displaying an input screen and search results, and a network I / F for connecting to a network. , An HDD for storing applications, a RAM from which they are read for execution, a CPU for executing them, and the like. In addition to applications, a Web browser can be used to enable communication over a network.
  • the server apparatus 300 can have the same hardware configuration as that of the client apparatus 200, but includes a Web server for communicating with the Web browser and a search engine for processing a search request received from the client apparatus 200. Prepare.
  • the server apparatus 300 can have the same hardware configuration as the client apparatus 200 described above, but an example of the hardware configuration of the server apparatus 300 will be briefly described with reference to FIG.
  • the memory 310, at least one processor 320, the memory control unit 330, the channel subsystem 340, at least one controller 350, and at least one input / output device 360 are included. I have.
  • the memory 310 stores data and programs input from the input / output device 360, and in response to addressing from the processor 320 and the channel subsystem 340, the data stored in the addresses is stored in the processor 320 and the channel. Send to subsystem 340
  • the processor 320 controls the entire apparatus and executes at least one OS.
  • the OS controls program execution and input / output processing in the apparatus.
  • the memory control unit 330 is connected to each of the memory 310, the processor 320, and the channel subsystem 340 via a bus.
  • the memory control unit 330 temporarily stores a request issued by the processor 320 or the channel subsystem 340 in a queue and sends the request to the memory 310 at a predetermined timing.
  • the channel subsystem 340 is connected to each control device 350 and controls data transfer between the input / output device 360 and the memory 310 in order to reduce the processing load on the processor 320. Thereby, the arithmetic processing by the processor 320 and the input / output processing by the input / output device 360 can be executed in parallel, and the processing efficiency can be improved.
  • the control device 350 controls the data transfer timing of the input / output device 360 and the like.
  • the input / output device 360 transfers data to and from the memory 310 via the control device 350, the channel subsystem 340, and the memory control unit 330.
  • Examples of the input / output device 360 include an HDD, a display, a keyboard, a printer, a communication device, and other storage devices.
  • One of the input / output devices 360 includes the data source 100 directly or via the network 400. Connected.
  • a recording medium in which a program is recorded is provided, and the recording medium is connected to one of the input / output devices 360, and the program is connected to the control device 350, the channel subsystem. 340, sent to the memory 310 via the memory control unit 330, and stored in the memory 310.
  • the stored program is installed again in the HDD connected to the input / output device 360 via them, and is appropriately read and executed by the processor 320.
  • This program includes a program that executes a search process and outputs a search result.
  • This program is installed in the same HDD, and functions as a search engine by being read and executed by the processor 320 as appropriate.
  • FIG. 6 is a functional block diagram when the server apparatus 300 is configured as a search system.
  • This search system like the conventional search engine shown in FIG. 3, extracts a text from a document, a crawler 500 as an acquisition unit that periodically acquires a document, a database 505 as a storage unit that stores the acquired document.
  • a parser 510 as an extraction unit for extracting format information such as paragraphs
  • a store 515 as an accumulation unit for accumulating extracted text and format information
  • an indexer 520 as an creation unit for creating an index from text and format information
  • an index 525 as a storage unit for storing the index
  • a search as a search unit that searches for a document including the search term using the search term included in the search request as a key Includes runtime 530.
  • the query related information creation device 18 and the query related information comparison device 19 are included.
  • the division unit 535, the calculation unit 540, the storage unit 545, A document grouping unit 550 is included.
  • the conversion unit 550 Since the functions of the crawler 500, the database 505, the parser 510, the store 515, the indexer 520, the index 525, and the search runtime 530 have already been described, here, the division unit 535, the calculation unit 540, the storage unit 545, and the document group The conversion unit 550 will be described in detail.
  • the division unit 535 receives the text and format information extracted by the parser 510, and divides the text into a plurality of blocks based on the division information designated by the user.
  • the division information is information indicating how to divide the text, and at least one of sentence, paragraph, blank line, and additional information added to the document can be selected.
  • sentence When each sentence is selected, the text is divided for each sentence. Multiple division information can be selected and used.For example, when a specific search word is used, the division information for each paragraph is used, and when other than the specific search word is used, a sentence is used. Each division information can be used.
  • the calculation unit 540 calculates a hash value of each block by applying a hash function to the character string included in each block.
  • the hash function is a function for generating a certain range of numerical values from data, and the hash value obtained by applying the hash function is a numerical value corresponding to each character string.
  • the hash value can be calculated using a standard method of Java (registered trademark) language, for example, hashCode ().
  • HashCode () is a method that returns a hash value.
  • a function obtained by adding a character code assigned to each character of a character string for example, a numerical value
  • a character code in this case an ASCII character code can be cited. Since the above example is an example, any calculation formula or algorithm known so far can be used to obtain the hash value.
  • the storage unit 545 stores the hash value obtained by the calculation unit 540 together with block position information in the document.
  • the block position information will be described in detail below.
  • the document grouping unit 550 extracts a corresponding hash value from the storage unit 545 based on the position information of the block including the search word for each document obtained by searching based on the search word. Then, the document grouping unit 550 groups the documents having the same hash value and outputs them as a search result.
  • the output search result is sent to the search runtime 530, and the search runtime 530 returns it to the client device 200. In the client device 200, when the Web browser receives the search result, the search result is displayed on the display device.
  • FIGS. 7A to 7C show three e-mails as document examples.
  • Each of these e-mails is composed of a text and a signature made up of a signature or the like, and there is a blank line between the text and the signature.
  • “blank line” is designated as the division information
  • the dividing unit 535 when creating an index, based on the designated division information “blank line”, sends an e-mail as a blank line, the text and the signature. And divided into two. Specifically, the dividing unit 535 divides the parsed document into a plurality of blocks after the crawler 500 periodically acquires the document and the parser 510 parses the document.
  • FIG. 8 is a diagram showing a hash value of each block calculated by applying a hash function to a character string included in each divided block.
  • the character string included in the block is converted to a token (words) string by the parser 510.
  • split writing means writing in a Japanese sentence with a space between words.
  • Fig. 8 (a) the text "Please attach the PHP source code. Thank you” and the signature "------ Suzuki Example Corp Japan XXX@example.co.jp" There is a blank line between them, and this blank line is divided into two token strings.
  • the calculation unit 540 applies a hash function to each token string and calculates a hash value that is a corresponding numerical value.
  • a hash function is calculated from “Attach PHP source code. Thank you” and “------ Suzuki Example Corp Japan XXX@example.co.jp” From the above, “0987654321” is calculated.
  • the hash value is calculated as a 10-digit numerical value, but is not limited to 10 digits, and may be any numerical value.
  • the characters in the document are arranged from left to right in the line direction, and when the line ends, they are arranged from left to right in the line below. For this reason, tokens in the document are arranged in order from the token in the upper left corner to the token in the lower right corner.
  • the position information can include the token order from the first token in the document to the first token of the character string included in each block.
  • the position of the block can be expressed as a range using, for example, this order and the order of tokens from the first token in the document to the last token of the character string included in each block. Can also be adopted.
  • the number of tokens from the first token in the document to the first token of each block is used as position information as the order of tokens up to the first token of each block.
  • the parser 510 may actually generate a plurality of tokens from the same word. For example, six tokens may be generated even though there are only five words so that a search can be performed even in the utilization form.
  • the search system since the search system returns information indicating what number token was hit, the block to be extracted may be shifted in the position information calculated from the number of tokens as described above.
  • the calculation unit 540 calculates the hash value and the position information
  • the number of tokens from the first token obtained from the parser 510 is “mas”
  • the 13th “do” is the 8th
  • 14th “Is” that is not actually included in the sentence is arranged in an array with a token overlapping with “mas” immediately before it, and both “mas” and “was” are 7 Calculate as the twelfth and twelfth tokens.
  • the calculation unit 540 uses the order up to the first token and the order up to the end token of the block “PHP source code is attached.” For the blocks “7” and “Thank you in advance”, “hash value @ 8-12” is obtained using the same order and stored in the storage unit 545.
  • the calculated hash values are always the same if they are the same token sequence, and if one token is different, the hash value is different. Referring to FIGS. 8A and 8B, since some tokens are different from each other, the hash values are different values such as “1234567890” and “2345678901” On the other hand, since the signature is the same for all tokens, the hash value is the same as “0987654321”. In FIG. 8C, the hash values are different because at least some of the tokens are different from each other in the main text and the signature in FIGS. 8A and 8B.
  • the search runtime 530 searches the index 525 for the index created by the indexer 520 based on the search word included in the search request, and searches for the document obtained by the search. Text and format information are acquired from the store 515. The search runtime 530 passes these pieces of information to the document grouping unit 550.
  • the document grouping unit 550 extracts the hash value of the block in which the token hit for each search result document is included from the storage unit 545 based on the position information of the block including the search word, and has the same hash value. Group documents as one group.
  • the search runtime 530 executes a search based on the input search word
  • the search runtime 530 returns a result indicating that the token was hit.
  • the calculation unit 540 calculates the order of tokens in the token string as position information, and stores it. Since the data is stored in the unit 545, the document grouping unit 550 can extract an appropriate hash value by extracting the hash value based on the token order returned from the search runtime 530.
  • a document including a plurality of token sequences is divided into a plurality of blocks by the dividing unit 535, and each hash value is calculated from the token sequence included in each block by the calculating unit 540, and each is stored in the storage unit 545. If two or more blocks contain a search term, the sum of hash values calculated from token sequences contained in the two or more blocks can be calculated and stored as the hash value of the document. .
  • the search runtime 530 searches the index 525 and retrieves the three documents shown in FIGS. 8A to 8C. Get as a search result.
  • the documents shown in FIGS. 8A to 8C are sequentially referred to as documents 1 to 3, in the document 1, the search word “Suzuki” is at the 15th token, and the hash value of the block including the token is “ 0987654321 ".
  • the search word “Suzuki” is at the 17th token, and the hash value of the block including the token is “0987654321”, which is the same as document 1 above. Therefore, document 1 and document 2 are grouped as the same group.
  • the search word “Suzuki” is in the first token, and the hash value of the block including the token is “3456789012”, which is different from Document 1 and Document 2. Therefore, the document 3 is grouped as a group different from the document 1 and the document 2.
  • any display may be used as long as it can be determined that the document is included in a certain group.
  • the documents grouped in the same group are displayed as normal for the first document, but the second and subsequent are indented to the right, with a vertical bar at the beginning. Is displayed. By doing in this way, the user can judge at a glance the relevance between documents of a search result.
  • the display of the grouped documents is not limited to the vertical bars and indents described above, and can be identified by changing the font style or adding an identification symbol.
  • Alignment of grouped documents can be performed based on the search score.
  • the search score is obtained from the number of documents in which the search term appears and the total number of documents to obtain a value indicating how many of the documents appear in the entire document, and the value is multiplied by the number of occurrences of the search term. Can be obtained. For this reason, a document with a higher number of appearances has a higher score, and a document with a lower number of appearances has a lower score.
  • FIG. 9A shows a result of a search performed by the search runtime 530 based on the conventional search term “Suzuki” that is not grouped. .
  • the user needs to evaluate each search result.
  • the search results shown in FIG. 9B the user looks at which results overlap. Therefore, it is only necessary to evaluate one of them, and it is possible to easily find a necessary document.
  • FIGS. 10A to 10D are diagrams showing four examples of e-mails, which are divided into blocks, and hash values and position information are associated with each other.
  • FIG. 10 is also divided into blocks by the dividing unit 535 with blank lines.
  • documents 1 and 2 shown in FIGS. 10 (a) and 10 (b) there are two texts and signatures.
  • documents 3 and 4 shown in FIGS. 10 (c) and 10 (d) quoted sentences and signatures are used.
  • the symbols “>” and “>>” are added to the text and divided into a plurality of texts and signatures 4 and 6.
  • the calculation unit 540 calculates a hash value from the character string included in each block, calculates the number of characters from the first character of the document to the first character of the character string, and the number of characters from the first character of the document to the last character of the character string. Is used as position information, and is stored in the storage unit 545 in association with the position information and the hash value.
  • Speaking of the document shown in Fig. 10 (a) it is divided into the main text "Check in db2jcc.jar tomorrow" and the signature "---- Tanaka", and "11111111" is added to the main text. And “22222222” is calculated for the signature. Since there are no previous characters in this body, it starts from the first character and the number of characters is 24. Therefore, the position information is “1 to 24”, the signature starts from the 25th character, Is 6 characters, the position information is “25 to 30”.
  • the search runtime 530 searches for a document from the index 525.
  • “db2jcc.jar” is entered as a search term.
  • the search runtime 530 searches for a document including this “db2jcc.jar” and passes the search result to the document grouping unit 550.
  • the document grouping unit 550 groups documents having the same hash value of the block including “db2jcc.jar” into one group. In this embodiment, since the documents 1, 3, and 4 have the same hash value “11111111”, the document grouping unit 550 groups them into the same group. As for the document 2, since the hash value of the block including “db2jcc.jar” is different from “33333333”, the document grouping unit 550 groups them into different groups.
  • the document grouping unit 550 returns the grouped search results to the search runtime 530, and the search runtime 530 transmits the search results to the client device 200.
  • An example of the grouped search results at this time is illustrated in FIGS. As is apparent from the search result, the second and subsequent documents belonging to the same group are indented. In FIG. 11, documents 1, 3, and 4 are in the same group, and document 2 is in another group.
  • a document to be searched is divided into a plurality of blocks, a hash value is calculated from a character string included in each block, and the position information of the block is stored in association with the calculated hash value. . For this reason, the amount of memory usage increases as much as the hash value and the position information are stored. A large increase in memory usage causes a significant decrease in processor processing speed.
  • a mail corpus having 11830 stored documents (e-mails) and 512127 sentences was used as a data source.
  • the document is divided for each sentence, the hash value is 8 bytes long, the position information is a token number indicating the order from the first token of the document to the first token of the sentence, and from the first token of the document to the end of the sentence.
  • the token number represents the order up to the token.
  • the amount of memory used to store the index is 93995008 bytes when only storing the conventional index and not storing the hash value, and in addition to the index of the present invention, the hash value Is also stored as 98820096 bytes. This was an increase of 9.42 bytes per sentence and the memory usage only increased by about 5%. For this reason, it is considered that the memory usage does not increase significantly and the processing speed of the processor is not affected.
  • the document to be searched may be any document from which text can be extracted, and examples include text files, office documents, and e-mails. Note that even if the document has a different data format, if the extracted text and the division information are the same, it is possible to detect whether the document is a related document. For this reason, the blocks must be divided in the same way. This is because the determination of the related document changes if the separation method is different.
  • the information that the search system should have for each document includes the token string that constitutes the above document, the division information that indicates how the document is divided, the document identification information (for example, the document number), and the characters that are included in the hash value. Information etc. can be mentioned.
  • the token string and the document identification information are received from the parser 510, but the division information is held by the division unit 535, and the character information included in the hash value is held by the calculation unit 540.
  • information stored at the time of index creation and used at the time of search can include document identification information in addition to hash values and block position information. These are stored in the storage unit 545 and read by the document grouping unit 550 at the time of retrieval.
  • the present invention is configured as a computer-readable program and can be realized as a search system by causing the computer to execute the program.
  • the program can be provided by being stored in a recording medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　検索結果の文書から真に必要な文書を見つけやすくするための検索システムおよび検索方法を提供する。 　この検索システムは、検索対象となる文書を、指定された分割情報に基づき複数のブロックに分割する分割部５３５と、各ブロックに含まれる文字列にハッシュ関数を適用して該各ブロックのハッシュ値を計算する計算部５４０と、得られたハッシュ値を文書におけるブロックの位置情報とともに記憶する記憶部５４５と、検索語に基づき検索されて得られた各文書につき、該検索語を含むブロックの位置情報を基に対応するハッシュ値を記憶部５４５から取り出し、ハッシュ値が一致する文書をグループ化して、検索結果として出力する文書グループ化部５５０とを備える。

Description

検索システム、検索方法およびプログラム
　本発明は、検索結果のうち、どの文書が重複した内容で検索されたかを検知可能にした検索システム、その検索方法およびその方法を実現するためのコンピュータ可読なプログラムに関する。
　インターネット等のネットワークに接続されたデータベースに格納されている文書を検索するためのシステムとして、検索エンジンがある。この検索エンジンには、複数の文書から特定の文字列を検索する全文検索機能を備えるものがある。
　全文検索機能を備える全文検索エンジンは、複数の文書の内容を順次走査し、検索対象となる文字列を探索する逐次検索型と、検索対象となる文書数が膨大で、逐次検索では検索時間がかかることから、事前に、文字列、その文書の場所、更新日、出現頻度といったデータからなるテーブル構造のインデックスを作成しておき、検索時にはこのインデックスにアクセスすることで、高速に検索を可能にした索引型とがある。
　索引型で使用されるインデックスには、様々な形式があり、一般的なものとしては、単語と、その単語を含む文書ファイルＩＤとで構成された可変長のレコードをもつ転置インデックスと呼ばれるものがある。
　ここで、３つの文書と、それらに対する転置インデックスと、収集された文書を保管するデータ構造の例を、図１および２に示す。図１（ａ）～（ｃ）に示す文書は、順に、文書ファイルＩＤが１～３とされ、いずれも電子メールとされている。図２（ａ）に示す転置インデックスは、キーとなる単語と、その単語を含むＩＤとで構成され、この図２（ａ）では「ＰＨＰ」、「鈴木」、「コード」という単語を含む文書が対応付けられている。図２（ｂ）に示す収集された文書を保管するデータ構造のエントリ例では、キーとなる単語と、その単語に対応する文書の内容とが対応付けられ、この図２（ｂ）では、単語が左欄に配列され、選択された単語に対応する文書内容が右欄に表示されている。
　全文検索エンジンでは、検索語と一致した単語が出現する文書群が検索結果として返される。このように文書全体の類似性を判定する技術として、例えば、特許文献１～３に記載された技術がある。
　これらの技術では、検索語と一致した単語が文書中のどのような文字列の中で出現したかは考慮されない。これでは、検索結果の中に文書が大量に存在する場合、その検索結果の中から真に必要となる文書を見つけ出すのは難しく、労力がかかる。例えば、検索語が文書のテンプレートに存在すると、そのテンプレートを使用している文書が全て返されてしまい、本来の目的となる検索語を本文中にもつ文書を検索結果から探し出す労力が必要となる。なお、テンプレートは、文書のヘッダやフッタ、Ｗｅｂサイトのメニュー、電子メールのシグニチャー等である。
　電子メールでは、返信・転送する際、オリジナルのメールを末尾に追加することが多いが、その追加したメールに検索語が含まれていると、返信・転送するメールの本文中にその検索語が出現しなくても、検索結果として返される。このため、検索語を本文の話題としているメールを探したい場合にはノイズとなってしまう。
　したがって、検索語が本文の同一の文字列中に出現する文書を１つのグループにまとめることができれば、評価すべき文書数が少なくなるので、真に必要となる文書を見つけやすくなる。
　例えば、検索時に検索結果の文書それぞれについて、検索キーワードが含まれる文字列を作成し、比較することで、検索語の出現位置を考慮して、内容が重複する文書を検出する技術が提案されている（特許文献４参照）。
　特許文献４に記載されている検索エンジンの構成を、図３に示す。この検索エンジン１０は、検索対象となる文書を保持するデータソース２０と接続され、また、ユーザが検索結果を得るために入力した問合せ（クエリ）を出力するクライアント装置３０と接続されている。
　検索エンジン１０は、検索エンジン１０自身がもつデータベース１１に文書を登録し、インデックスを作成するためにデータソース２０上の文書を周期的に取得するクローラー１２を備える。このクローラー１２は、インデックス作成に用いられる文書のコピーを要求し、その文書中に含まれるリンクをたどり、別の文書を収集するという動作を繰り返す。また、クローラー１２は、新しい文書を見つけた場合は、データベース１１に登録し、文書が存在しないことを検出した場合は、データベース１１からその文書を削除する。
　検索エンジン１０は、クローラー１２が取得し、データベース１１に登録された文書からテキストを抽出し、段落等のフォーマット情報を抽出するパーサー１３を備える。パーサー１３は、構文解析を行うもので、構文解析され抽出されたテキストやフォーマット情報を、ストア１４と呼ばれる収集された文書を保管するデータ構造へ入力する。
　検索エンジン１０は、パーサー１３により抽出されたテキストやフォーマット情報からインデックスを作成するインデクサー１５を備える。インデクサー１５は、上述したように、キーとなる単語とその単語を含む文書のＩＤとを対応付けて索引１６に保管する。
　検索エンジン１０は、さらに、クライアント装置３０から受信したクエリに応答して、クエリに含まれる検索語をキーとして、その検索語を含む文書を検索する検索サーバとしてのサーチ・ランタイム１７と、サーチ・ランタイム１７から検索結果を受け取り、その検索語を含む文書をストア１４から取得し、その検索語を含む文字列を生成するクエリ関連情報作成装置１８と、生成された文字列を検索結果の文書と比較するクエリ関連情報比較装置１９とを備える。
　この検索エンジン１０では、検索毎、検索結果毎に、クエリ関連情報作成装置１８により検索語を含む文字列を生成し、クエリ関連情報比較装置１９によりその文字列を比較することで、文章全体が一致したものや、サンプリングされた文書の数箇所が一致したものを、関連する文書として検出する。
米国特許第６２３０１５５号公報 米国特許第６６５８４２３号公報 米国特許第６９７８４１９号公報 米国特許第６６１５２０９号公報
　従来の検索エンジンでは、同じ内容であるが、異なる文書として存在する場合、個々の検索結果として取り扱われるため、こういった同じ内容あるいは似通った内容の文書を前もって、文書収集時やインデックス作成時に除外することができる。しかしながら、従来の検索エンジンは、文章全体または文書の数箇所が同じ内容または似通った内容の文書を判断することができるだけで、部分的な同一性をもって同じ内容または似通った内容の文書とは判断することはできない。
　また、従来の検索エンジンでは、Ｗｅｂサイトのメニューに検索語が出現する場合、そのメニューをもつページが全て返されるが、文書の特徴とならなさそうな単語や文字列を前もって指定することで、除外することができる。しかしながら、その指定をするためには、除外する単語や文字列を前もって知っていなければならない。
　さらに、従来の検索エンジンでは、文書間の関連性が考慮されずに検索結果が返されるため、ユーザが、返された検索結果の文書全部につき、文書を１つずつ順に、真に必要な文書か否かを判断しなければならない。
　本発明は、上記課題に鑑み、文書を構成するテキストを複数のブロックに分け、検索語が含まれるブロックに着目し、検索結果の文書のうち、そのブロックの内容が同じ文書同士をグループ化することで、部分的な同一性をもって同じ内容あるいは似通った内容の文書と判断することを可能にし、文書間の関連性を考慮した検索結果を返すことを可能にする。
　具体的には、インデックス作成時に、検索対象となる文書中のテキストを複数のブロックに分割する。ブロックは、センテンス（文）、パラグラフ（段落）等とすることができる。このようにして得られたブロック毎にハッシュ値を計算する。ハッシュ値は、文字列に対応する数値である。このハッシュ値を、文書中のブロックの位置情報とともに、その文書に関連付けて保持する。
　そして、検索実行時に、検索結果の各文書について、検索語が出現する位置情報を基に、対応するハッシュ値を取り出し、そのハッシュ値が一致する文書同士をグループ化して出力する。
　これを実現するために、本発明では、検索対象となる文書を、指定された分割情報に基づき複数のブロックに分割する分割部と、各ブロックに含まれる文字列にハッシュ関数を適用して各ブロックのハッシュ値を計算する計算部と、得られたハッシュ値を文書におけるブロックの位置情報とともに記憶する記憶部と、検索語に基づき検索されて得られた各文書につき、検索語を含むブロックの位置情報を基に対応するハッシュ値を記憶部から取り出し、ハッシュ値が一致する文書をグループ化して、検索結果として出力する文書グループ化部とを備える、検索システムが提供される。
　分割部は、分割情報としてのセンテンス毎、パラグラフ毎、空行、前記文書に付加された付加情報の少なくとも１つにより分割する。付加情報としては、ＨＴＭＬ文書におけるＨＴＭＬタグを挙げることができる。分割部は、１つに限らず、複数の分割情報を使用して分割することができ、例えば、特定の検索語が使用された場合にはパラグラフ毎の分割情報を使用し、それ以外の検索語が使用された場合にはセンテンス毎の分割情報を使用することができる。また、このように複数の分割情報を使用できるようにすることで、ユーザやシステムがセンテンス毎の分割によるグループ化が適当でないと判断した場合、センテンス毎以外の、例えばパラグラフ毎の分割情報を使用してグループ化することが可能となる。
　文書は、複数の単語（トークン）が順に配列するトークン列とされ、各ブロックに含まれる文字列は、少なくとも１つのトークンから構成される。このため、各ブロックの位置は、トークン数により表すことができ、その位置情報には、文書の先頭トークンから各ブロックの先頭トークンまでのトークンの順番を含むことができる。位置情報は、文書の先頭トークンから各ブロックの末尾トークンまでのトークンの順番を含むこともでき、それら２つのトークン数を、そのブロックを構成するトークン列の先頭から末尾までの範囲とすることができる。
　また、各ブロックの位置は、文字数により表すこともでき、この場合、位置情報には、文書の先頭文字から各ブロックに含まれる文字列の先頭文字までの文字数が含まれる。位置情報は、文書の先頭文字から各ブロックの末尾文字までの文字数を含むこともでき、それら２つの文字数を、そのブロックを構成する文字列の先頭から末尾までの範囲とすることができる。
　計算部は、ブロックに含まれる文字列において、指定された文字種を含む場合、その文字種を除いた文字列にハッシュ関数を適用してハッシュ値を計算する。電子メールでは、受信内容を引用する場合に記号「>」が追加されるが、この記号「>」を除いた文字列からハッシュ値を計算することで、同じハッシュ値をもつ文書としてグループ化することが可能となる。
　文書グループ化部は、グループに含まれる複数の文書を、検索スコアに基づきソートするソート部を含む。これにより、グループに含まれる複数の文書は、検索スコア順に並べられる。
　本発明では、上記検索システムが行う検索方法を提供することもできる。この方法は、分割部、計算部、記憶部、文書グループ化部の各部が実行する処理ステップを含む。
　この検索方法は、プログラムとして構成し、プログラムを実行させることにより実現することもできる。このプログラムは、記録媒体に格納して提供することができる。
　本発明の検索システム、検索方法、プログラムおよび記録媒体を提供することにより、検索結果の中から真に必要な文書が見つけやすくなり、その必要文書を探索する労力を軽減し、探索時間を短縮することが可能となる。
検索対象となる３つの文書を例示した図。 図１に示す文書に対する転置インデックスと、収集された文書を保管するデータ構造の例を示した図。 従来の検索エンジンの構成例を示した図。 検索対象となる文書を保持するデータソースと、検索要求を行うクライアント装置と、検索要求を受けて検索処理を行う検索エンジンを備えるサーバ装置とから構成されるネットワーク・システムを例示した図。 サーバ装置のハードウェア構成の一例を示した図。 サーバ装置を検索システムとして構成した場合の機能ブロック図。 検索対象となる３つの文書を例示した図。 分割された各ブロックに含まれる文字列にハッシュ関数を適用して各ブロックのハッシュ値を計算したところを示した図。 グループ化された文書を検索結果として表示した図。 電子メールの４つの例、それらをブロックに分けたところ、ハッシュ値と位置情報とを対応付けて表したところを示した図。 グループ化した検索結果の一例を示した図。
　以下、本発明を図面に示した具体的な実施の形態に沿って説明するが、本発明は、後述する実施の形態に限定されるものではない。
　図４は、検索対象となる文書を保持するデータソースと、検索要求を行うクライアント装置と、検索要求を受けて検索処理を行う検索エンジンを備えるサーバ装置とから構成されるネットワーク・システムを例示した図である。ここでは、データソース１００、クライアント装置２００、サーバ装置３００がそれぞれ１つずつしか示されていないが、２つ以上がネットワーク４００に接続されていてもよい。また、データソース１００とサーバ装置３００は、直接接続されていてもよい。
　データソース１００は、文書を保持する装置であればいかなる装置であってもよく、項目毎にデータを集めて管理するデータベースや他のサーバ装置とすることができる。データソース１００は、文書を保持する、他のユーザが使用するＰＣ等であってもよい。
　データソース１００がデータベースである場合、そのデータベースとしては、複数の関係（リレーション）を基本的なデータ型とし、格納されたデータを取得するための問合せが、等号や不等号等の関係演算子や、論理積や論理和や否定等の論理演算子を用いて行われるリレーショナル・データベースを用いることができる。なお、データベースは、オペレーティング・システム（OS）が提供するファイル・システム上に直接構築されたものでも、データベース管理システム（DBMS）を用いて構築されたものであってもよい。
　クライアント装置２００は、検索要求を出力することができるものであればいかなる装置であってもよく、ユーザが入力した検索語について検索要求を生成し、ネットワークを介した問合せを可能にするアプリケーションを備えるＰＣとすることができる。このＰＣは、ユーザが検索語を入力するためのキーボード、入力位置を指定し、検索開始の指示を与えるマウス、入力画面や検索結果を表示する表示装置、ネットワークに接続するためのネットワークＩ／Ｆ、アプリケーションを記憶するＨＤＤ、それらが実行のために読み出されるＲＡＭ、それらを実行するＣＰＵ等を備える。また、アプリケーションのほか、ネットワークを介した通信を可能にするために、Ｗｅｂブラウザを用いることができる。
　サーバ装置３００も、クライアント装置２００と同様のハードウェア構成とすることができるが、Ｗｅｂブラウザと通信を行うためにＷｅｂサーバと、クライアント装置２００から受信した検索要求を処理するための検索エンジンとを備える。
　サーバ装置３００は、上述したクライアント装置２００と同様のハードウェア構成とすることができるが、図５を参照して、サーバ装置３００のハードウェア構成の一例について簡単に説明する。図５に示すハードウェア構成では、メモリ３１０と、少なくとも１つのプロセッサ３２０と、メモリ制御部３３０と、チャネル・サブシステム３４０と、少なくとも１つの制御装置３５０と、少なくとも１つの入出力デバイス３６０とを備えている。
　メモリ３１０は、入出力デバイス３６０から入力されたデータやプログラムを格納し、プロセッサ３２０およびチャネル・サブシステム３４０からのアドレス指定に応答して、そのアドレスに格納しているデータ等をプロセッサ３２０およびチャネル・サブシステム３４０へ送る。
　プロセッサ３２０は、装置全体を制御し、少なくとも１つのOSを実行する。OSは、装置におけるプログラムの実行や入出力処理を制御する。メモリ制御部３３０は、バスを経由してメモリ３１０、プロセッサ３２０、チャネル・サブシステム３４０のそれぞれに接続される。このメモリ制御部３３０は、プロセッサ３２０やチャネル・サブシステム３４０が出したリクエストを一時的にキューに格納し、所定のタイミングでメモリ３１０へ送る。
　チャネル・サブシステム３４０は、各制御装置３５０へ接続され、プロセッサ３２０の処理負荷を軽減するために、入出力デバイス３６０とメモリ３１０との間のデータ転送を制御する。これにより、プロセッサ３２０による演算処理と、入出力デバイス３６０による入出力処理とを並列に実行させることができ、処理効率を向上させることができる。
　制御装置３５０は、入出力デバイス３６０のデータ転送のタイミング等を制御する。入出力デバイス３６０は、制御装置３５０、チャネル・サブシステム３４０、メモリ制御部３３０を経由し、メモリ３１０との間でデータ転送を行う。入出力デバイス３６０としては、HDD、ディスプレイ、キーボード、プリンタ、通信デバイス、他の記憶装置を挙げることができ、入出力デバイス３６０の１つには、データソース１００が直接に、またはネットワーク４００を介して接続される。
　サーバ装置３００による検索処理を実現するために、プログラムが記録された記録媒体が提供され、その記録媒体が入出力デバイス３６０の１つに接続され、そのプログラムが、制御装置３５０、チャネル・サブシステム３４０、メモリ制御部３３０を経由して、メモリ３１０へ送られ、メモリ３１０に格納される。格納されたプログラムは、再度それらを経由して入出力デバイス３６０に接続されたHDDへインストールされ、適宜プロセッサ３２０により読み出され、実行される。
　プログラムが格納される記録媒体としては、フレキシブル・ディスク、CD-ROM、DVD、SDカード、フラッシュメモリ等を挙げることができる。このプログラムは、検索処理を実行し、検索結果を出力する処理を実現するプログラムを含む。このプログラムは、同じHDDにインストールされ、適宜プロセッサ３２０が読み出し、実行することにより検索エンジンとして機能する。
　図６は、サーバ装置３００を検索システムとして構成した場合の機能ブロック図である。この検索システムは、図３に示した従来の検索エンジンと同様、文書を周期的に取得する取得部としてのクローラー５００、取得した文書を格納する格納部としてのデータベース５０５、文書からテキストを抽出し、段落等のフォーマット情報を抽出する抽出部としてのパーサー５１０、抽出したテキストおよびフォーマット情報を蓄積する蓄積部としてのストア５１５、テキストやフォーマット情報からインデックスを作成する作成部としてのインデクサー５２０、作成したインデックスを保管する保管部としての索引５２５、クライアント装置２００から受信した検索要求に応答して、その検索要求に含まれる検索語をキーとして、その検索語を含む文書を検索する検索部としてのサーチ・ランタイム５３０を含む。
　図３に示した従来の検索エンジンでは、クエリ関連情報作成装置１８、クエリ関連情報比較装置１９を含んでいたが、図６に示す検索システムでは、分割部５３５、計算部５４０、記憶部５４５、文書グループ化部５５０を含む。
　クローラー５００、データベース５０５、パーサー５１０、ストア５１５、インデクサー５２０、索引５２５、サーチ・ランタイム５３０の各機能については、既に述べたので、ここでは、分割部５３５、計算部５４０、記憶部５４５、文書グループ化部５５０について詳述する。
　分割部５３５は、パーサー５１０により抽出されたテキストやフォーマット情報を受け取り、ユーザにより指定された分割情報に基づき、テキストを複数のブロックに分割する。分割情報は、テキストをどのように分割するかを示す情報で、センテンス毎、パラグラフ毎、空行、文書に付加された付加情報の少なくとも１つを選択することができる。センテンス毎を選択した場合は、テキストは、センテンス毎に分割される。複数の分割情報を選択して使用することもでき、例えば、特定の検索語が使用された場合は、パラグラフ毎の分割情報を使用し、その特定の検索語以外が使用された場合は、センテンス毎の分割情報を使用することができる。また、複数の分割情報を設定しておき、それらを使用して分割することができるようにすることで、ユーザやシステムがセンテンス毎の分割によるグループ化が適当ではないと判断した場合、パラグラフ毎の分割情報を使用してグループ化することできる。このように、複数の基準で分割できるようにすることで、検索時にグループ化の粒度を調整することができ、有用である。ここで、付加情報としては、ＨＴＭＬ文書におけるＨＴＭＬタグを挙げることができる。なお、この分割は、インデックス作成時に行われる。
　計算部５４０は、各ブロックに含まれる文字列にハッシュ関数を適用して各ブロックのハッシュ値を計算する。ハッシュ関数は、データからある一定範囲の数値を生成する関数で、ハッシュ関数を適用して得られるハッシュ値は、それぞれの文字列に対応する数値である。ハッシュ値は、Ｊａｖａ（登録商標）言語の標準的なメソッド、例えばhashCode()等を使用して算出することができる。なお、hashCode()は、ハッシュ値を返すメソッドである。
　ハッシュ関数の１つの例としては、文字列の１文字毎に割り当てられた文字コード、例えば数値を加算して求める関数を挙げることができる。この場合の文字コードとしては、ＡＳＣＩＩ文字コードを挙げることができる。上記例は一例であるので、ハッシュ値を求めるために、これまでに知られたいかなる計算式やアルゴリズムでも用いることができる。
　記憶部５４５は、計算部５４０が計算して得たハッシュ値を、文書におけるブロックの位置情報とともに記憶する。ブロックの位置情報については下記に詳述する。
　文書グループ化部５５０は、検索語に基づき検索されて得られた各文書につき、検索語を含むブロックの位置情報を基に、対応するハッシュ値を記憶部５４５から取り出す。そして、文書グループ化部５５０は、ハッシュ値が一致する文書をグループ化して、検索結果として出力する。出力された検索結果は、サーチ・ランタイム５３０へ送られ、サーチ・ランタイム５３０がクライアント装置２００へ返す。クライアント装置２００では、Ｗｅｂブラウザが検索結果を受信すると、表示装置へその検索結果を表示させる。
　これらの詳細な処理を、図７～図１１を参照して説明する。図７（ａ）～（ｃ）は、文書例として、３つの電子メールが示されている。これらの電子メールはいずれも、本文と署名等からなるシグニチャーとから構成され、本文とシグニチャーとの間には空行がある。ここでは、分割情報として「空行」が指定されており、分割部５３５は、インデックス作成時に、この指定された「空行」という分割情報に基づき、電子メールを、空行で、本文とシグニチャーとの２つに分割する。具体的には、分割部５３５は、クローラー５００が周期的に文書を取得し、パーサー５１０が構文解析した後、構文解析された文書を、複数のブロックに分割する。
　図８は、分割された各ブロックに含まれる文字列にハッシュ関数を適用して各ブロックのハッシュ値を計算したところを示した図である。ブロックに含まれる文字列は、パーサー５１０によりトークン（分かち書きされた単語）列とされている。ここで、分かち書きとは、日本語の文章において語の区切りに空白を挟んで記述することをいう。図８（ａ）では、本文の「ＰＨＰのソースコードを添付します。よろしくお願いします。」と、シグニチャーの「------　鈴木　Example Corp Japan XXX@example.co.jp」との間に空行があり、この空行によって２つのトークン列に分割されている。
　計算部５４０は、各トークン列にハッシュ関数を適用し、対応する数値であるハッシュ値を計算する。上記の例でいうと、「ＰＨＰのソースコードを添付します。よろしくお願いします。」から計算により「1234567890」を、「------　鈴木　Example Corp Japan XXX@example.co.jp」から計算により「0987654321」を算出する。ここでは、１０桁の数値としてハッシュ値を算出しているが、１０桁に限られるものではなく、いかなる桁の数値であってもよい。
　文書中の文字は、行方向に、左から右へと配列し、その行が終了すると、その下の行に、左から右へと配列している。このことから、文書中のトークンは、左上隅にあるトークンを先頭に、右下隅にあるトークンまで順に並んでいる。位置情報としては、文書中の先頭トークンから各ブロックに含まれる文字列の先頭トークンまでのトークンの順番を含むことができる。ブロックの位置は、例えば、この順番と、文書中の先頭トークンから各ブロックに含まれる文字列の末尾トークンまでのトークンの順番とを用いて範囲で表すことができ、位置情報としては、その範囲を採用することもできる。
　上記の例の「ＰＨＰのソースコードを添付します。よろしくお願いします。」では、「ＰＨＰ」、「の」、「ソースコード」、「を」、「添付」、「し」、「ます」、「。」、「よろしく」、「お願い」、「し」、「ます」、「。」という１３のトークンから構成され、「ＰＨＰ」は最初のトークンであるから０トークンであり、最後の「。」は１３トークン目であるから、その位置情報は「０トークン～１２トークン」とすることができる。図８（ａ）では、これらを「＠」という記号を使用して結合し、「1234567890＠０トークン～１２トークン」、「0987654321＠１３トークン～２４トークン」で表されている。これらの情報は、記憶部５４５に記憶される。
　上記例では、位置情報に、文書中の先頭トークンから各ブロックの先頭トークンまでのトークン数を、各ブロックの先頭トークンまでのトークンの順番として用いた。ところが、実際にパーサー５１０では、同じ単語から複数のトークンが生成される場合がある。例えば、活用形でも検索を行うことができるように、５つの単語しかないのに、６つのトークンが生成されることがある。その一方、検索システムは、何番目のトークンでヒットしたという情報を返すので、上記のようにトークン数から計算した位置情報では、取り出すブロックがずれてしまうことがある。
　この場合について「ＰＨＰのソースコードを添付します。よろしくお願いします。」という文を、センテンス毎にブロックに分け、その位置情報を計算する場合について説明する。パーサー５１０では、先頭から順に、「ＰＨＰ」、「の」、「ソースコード」、「を」、「添付」、「し」、「ます」、「ました」、「。」、「よろしく」、「お願い」、「し」、「ます」、「ました」、「。」という１５のトークンを生成したとする。ここで、２つの「ました」は、活用形として生成されたものであり、実際の文には含まれないものである。分割部５３５は、この文をセンテンス毎に分ける場合、「ＰＨＰのソースコードを添付します。」と「よろしくお願いします。」という２つのブロックに分ける。
　計算部５４０は、ハッシュ値を計算するとともに位置情報を計算すると、パーサー５１０から得られた先頭トークンからのトークン数として「ます」を７番目、１３番目、「ました」を８番目、１４番目と計算するのではなく、実際に文に含まれない「ました」についてはその直前にある「ます」とトークンが重複する形で配列に並び、「ます」と「ました」の両方を７番目、１２番目のトークンとして計算する。
　そして、計算部５４０は、「ＰＨＰのソースコードを添付します。」というブロックに対しては、そのブロックの先頭トークンまでの順番と末尾トークンまでの順番とを使用して「ハッシュ値＠０－７」、「よろしくお願いします。」というブロックに対しても、同様の順番を使用して「ハッシュ値＠８－１２」を求め、それらを記憶部５４５に記憶する。
　算出されるハッシュ値は、同じトークンの並びであれば必ず同じものになり、１つのトークンでも異なると、異なったハッシュ値になる。図８（ａ）、（ｂ）を参照してみると、本文は、一部のトークンが異なっているため、ハッシュ値が「1234567890」と「2345678901」のように異なった値となっており、その一方で、シグニチャーは、いずれのトークンも同じであるため、「0987654321」で同じハッシュ値となっている。図８（ｃ）は、図８（ａ）、（ｂ）の本文、シグニチャーのいずれも、少なくとも一部のトークンが異なっているため、ハッシュ値が異なった値となっている。
　特定の文字種である記号からなるトークンについては、ハッシュ値の計算を行わないようにすることができる。このようにすることで、「こんにちは」という文字列と「>こんにちは」という文字列は、記号「>」の部分が異なるのみで、文字列「こんにちは」の部分が同じであるため、同じハッシュ値を算出することができる。この記号「>」は、電子メールの内容が引用された場合に追加されるものである。したがって、受信した電子メールの内容が引用されて記号「>」が追加されていたとしても、その他のトークンの並びが同じであれば、同じハッシュ値となる。これは、電子メールを検索する場合に有用である。これまでの処理は、インデックス作成時に行われる。なお、ハッシュ値の計算時に除かれる文字種としては、電子メールにおいて内容が引用された場合に追加される「>」や「>>」に限られるものではなく、ユーザが予め指定しておくことにより、その文字種を除いて計算することができる。
　クライアント装置２００が検索要求を出力すると、サーチ・ランタイム５３０は、検索要求に含まれる検索語を基に、インデクサー５２０が作成したインデックスを索引５２５の中から検索し、検索して得られた文書のテキストやフォーマット情報をストア５１５から取得する。サーチ・ランタイム５３０は、これらの情報を文書グループ化部５５０へ渡す。
　文書グループ化部５５０は、検索結果の文書毎にヒットしたトークンが含まれていたブロックのハッシュ値を、検索語を含むブロックの位置情報を基に記憶部５４５から取り出し、同一のハッシュ値をもつ文書を１つのグループとしてグループ化する。
　サーチ・ランタイム５３０は、入力された検索語に基づき検索を実行した場合、何番目のトークンでヒットしたという結果を返すが、計算部５４０がトークン列のトークンの順番を位置情報として計算し、記憶部５４５に記憶しているので、文書グループ化部５５０は、サーチ・ランタイム５３０から返されたトークンの順番に基づきハッシュ値を取り出すことで、適切なハッシュ値を取り出すことができる。
　複数のトークン列を含む文書は、分割部５３５により、複数のブロックに分割され、計算部５４０により、各ブロックに含まれるトークン列から各ハッシュ値が計算され、各々が記憶部５４５に記憶されるが、２以上のブロックに検索語が含まれる場合、それら２以上のブロックに含まれるトークン列から計算されたハッシュ値を合計したものを、その文書のハッシュ値として計算し、記憶することができる。
　ユーザがクライアント装置２００において「鈴木」という検索語を入力し、検索要求を出力した場合、サーチ・ランタイム５３０は、索引５２５を検索し、図８（ａ）～（ｃ）に示す３つの文書を検索結果として得る。図８（ａ）～（ｃ）に示す文書を順に、文書１～３として参照すると、文書１では、検索語「鈴木」が１５トークン目にあり、そのトークンを含むブロックのハッシュ値は、「0987654321」である。文書２では、検索語「鈴木」が１７トークン目にあり、そのトークンを含むブロックのハッシュ値は、「0987654321」で、上記文書１と同じである。このため、文書１と文書２は、同じグループとしてグループ化される。
　文書３では、検索語「鈴木」が１トークン目にあり、そのトークンを含むブロックのハッシュ値は、「3456789012」で、文書１および文書２とは異なる。このため、文書３は、文書１や文書２とは別のグループとしてグループ化される。
　グループ化された文書を検索結果として表示する場合、その文書があるグループに含まれていることが判断できればいかなる表示であってもよく、例えば、図９（ｂ）に示すような表示とすることができる。この図９（ｂ）に示す検索結果は、同じグループにグループ化された文書は、１番目の文書は、通常通り表示されるが、２番目以降は、右にインデントされ、その先頭に縦棒が表示されている。このようにすることで、ユーザは、検索結果の文書間の関連性を一見して判断することができる。なお、グループ化された文書の表示は、上記の縦棒およびインデントに限られるものではなく、字体を変える、識別記号を付する等により識別することができる。
　グループ化された文書の配列は、検索スコアを基に行うことができる。検索スコアは、検索語が出現する文書数と全文書数とから、全文書中のどの程度の文書に検索語が出現するかを表す値を求め、その値と検索語の出現回数とを乗じて得られる値とすることができる。このため、出現回数が多い文書ほど高スコアとなり、出現回数が少ない文書ほど低スコアとなる。
　図９（ａ）には、図９（ｂ）との比較のために、グループ化をしない従来の単に検索語「鈴木」に基づいてサーチ・ランタイム５３０により検索を行った結果を表示している。図９（ａ）に示す検索結果では、ユーザは、それぞれの検索結果を評価する必要があるが、図９（ｂ）に示す検索結果では、ユーザは、どの結果が重複しているかを一見して判断することができるので、そのうちの１つを評価すればよく、必要な文書を容易に探し出すことが可能となる。
　これまで説明してきた実施形態では、ブロックの位置情報をトークンの順番により表してきた。しかしながら、位置情報は、トークンの順番で表すものに限らず、配列する文字の順番によって表すこともできる。図１０（ａ）～（ｄ）は、電子メールの４つの例、それらをブロックに分けたところ、ハッシュ値と位置情報とを対応付けて表したところを示した図である。
　図１０に示す実施形態も、分割部５３５により、空行で、各ブロックに分割されている。図１０（ａ）および（ｂ）に示す文書１および文書２では、本文とシグニチャーの２つに、図１０（ｃ）および（ｄ）に示す文書３および文書４では、引用された文章およびシグニチャーに記号「>」や「>>」が追加され、複数の本文とシグニチャーの４および６つに分割されている。
　計算部５４０は、各ブロックに含まれる文字列からハッシュ値を計算し、文書の先頭文字からその文字列の先頭文字までの文字数と、文書の先頭文字からその文字列の末尾文字までの文字数とを使用して表される範囲を位置情報として用い、その位置情報とハッシュ値と対応付けて記憶部５４５に記憶する。図１０（ａ）に示す文書でいえば、本文の「db2jcc.jarを明日、チェックインします。」と、シグニチャーの「----　田中」とに分割され、本文に対し「11111111」が算出され、シグニチャーに対し「22222222」が算出されている。この本文は、それ以前に文字が存在しないため、１文字目から開始し、文字数が２４文字であることから、位置情報は「１～２４」とされ、シグニチャーが２５文字目から開始し、文字数が６文字であることから、位置情報は「２５～３０」とされている。
　クライアント装置２００からの検索要求を受けて、サーチ・ランタイム５３０が索引５２５の中から文書を検索する。ここでは、検索語として「db2jcc.jar」が入力されている。サーチ・ランタイム５３０は、この「db2jcc.jar」を含む文書を検索し、検索結果を文書グループ化部５５０へ渡す。文書グループ化部５５０は、その「db2jcc.jar」を含むブロックのハッシュ値が同じ文書を１つのグループにグループ化する。この実施形態では、文書１、３、４が同じ「11111111」というハッシュ値をもつため、文書グループ化部５５０は、これらを同じグループにグループ化する。文書２については、「db2jcc.jar」を含むブロックのハッシュ値が「33333333」と異なるため、文書グループ化部５５０は、異なるグループにグループ化する。
　文書グループ化部５５０は、グループ化した検索結果をサーチ・ランタイム５３０へ返し、サーチ・ランタイム５３０がクライアント装置２００へその検索結果を送信する。このときのグループ化した検索結果の一例を、図１１（ａ）、（ｂ）に例示する。検索結果は、一見して分かるように、同じグループに属する文書の２番目以降がインデントされている。図１１では、文書１、３、４が、同じグループとされ、文書２が別のグループとされている。
　本発明では、検索対象となる文書を、複数のブロックに分割し、各ブロックに含まれる文字列からハッシュ値を計算し、計算したハッシュ値にそのブロックの位置情報を対応付けて記憶している。このため、ハッシュ値と位置情報を記憶する分だけ、メモリ使用量が増加する。メモリ使用量の大幅な増加は、プロセッサの処理速度の大幅な低下を招いてしまう。
　そこで、どの程度メモリ使用量が増加するかについて検討した。格納される文書（電子メール）の数が１１８３０、センテンス数が５１２１２７のメール・コーパスをデータソースとして使用した。文書の分割は、センテンス毎で行い、ハッシュ値は、８バイトの長さ、位置情報は、文書の先頭トークンからセンテンスの先頭トークンまでの順番を表すトークン番号と、文書の先頭トークンからセンテンスの末尾トークンまでの順番を表すトークン番号とした。
　この条件の下、インデックスを格納するために使用されるメモリ使用量は、従来のインデックスを格納するのみで、ハッシュ値を記憶しない場合には、９３９９５００８バイトとなり、本発明のインデックスに加えてハッシュ値も記憶する場合には、９８８２００９６バイトとなった。これは、１センテンス当たり、９．４２バイトの増加で、メモリ使用量は、約５％増加しただけであった。このことから、メモリ使用量が大幅に増加することはなく、プロセッサの処理速度に影響はないものと考えられる。
　検索対象となる文書は、テキストが抽出できる文書であればいかなる文書であってもよく、テキストファイル、オフィス文書、電子メール等を挙げることができる。なお、データ・フォーマットが異なる文書でも、抽出されたテキストと分割情報が同一であれば、関連する文書であるか否かを検出することができる。このため、ブロックの分割は、同じ区切り方でなければならない。区切り方が異なれば、関連する文書の判断が変わるからである。
　検索システムが文書毎に持つべき情報としては、上記の文書を構成するトークン列、どのように分割するかを示す分割情報のほか、文書の識別情報（例えば、文書番号）、ハッシュ値に含める文字情報等を挙げることができる。トークン列および文書の識別情報は、パーサー５１０から受け取るが、分割情報は分割部５３５が、ハッシュ値に含める文字情報は計算部５４０がそれぞれ保持する。
　また、インデックス作成時に記憶し、検索時に使用する情報としては、ハッシュ値、ブロックの位置情報のほか、文書の識別情報を挙げることができる。これらは、記憶部５４５に記憶され、検索時に、文書グループ化部５５０により読み出される。
　これまで、本発明の検索システムおよびその検索システムにより実行される検索方法を、図面を参照して詳細に説明してきたが、本発明は上記実施の形態に限定されるものではなく、他の実施形態や、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。本発明は、コンピュータ読み取り可能なプログラムとして構成し、コンピュータにそのプログラムを実行させることにより、検索システムとして実現することができ、そのプログラムは、記録媒体に格納して提供することができる。
１０…検索エンジン、１１…データベース、１２…クローラー、１３…パーサー、１４…ストア、１５…インデクサー、１６…索引、１７…サーチ・ランタイム、１８…クエリ関連情報作成装置、１９…クエリ関連情報比較装置、２０…データソース、３０…クライアント装置、１００…データソース、２００…クライアント装置、３００…サーバ装置、３１０…メモリ、３２０…プロセッサ、３３０…メモリ制御部、３４０…チャネル・サブシステム、３５０…制御装置、３６０…入出力デバイス、４００…ネットワーク、５００…クローラー、５０５…データベース、５１０…パーサー、５１５…ストア、５２０…インデクサー、５２５…索引、５３０…サーチ・ランタイム、５３５…分割部、５４０…計算部、５４５…記憶部、５５０…文書グループ化部

Claims (20)

  1. 　入力された検索語に基づき文書検索を行い、検索結果を出力する検索システムであって、
    　検索対象となる文書を、指定された分割情報に基づき複数のブロックに分割する分割部と、
    　各ブロックに含まれる文字列にハッシュ関数を適用して該各ブロックのハッシュ値を計算する計算部と、
    　得られた前記ハッシュ値を前記文書におけるブロックの位置情報とともに記憶する記憶部と、
    　前記検索語に基づき検索されて得られた各文書につき、該検索語を含むブロックの位置情報を基に、対応するハッシュ値を前記記憶部から取り出し、前記ハッシュ値が一致する文書をグループ化して、前記検索結果として出力する文書グループ化部とを備える、検索システム。
  2. 　前記分割部は、前記分割情報としてのセンテンス毎、パラグラフ毎、空行、前記文書に付加された付加情報の少なくとも１つにより分割する、請求項１に記載の検索システム。
  3. 　前記文書は、複数の単語（トークン）が順に配列するトークン列とされ、前記各ブロックの位置情報は、前記文書の先頭トークンから前記各ブロックの先頭トークンまでのトークンの順番を含む、請求項１に記載の検索システム。
  4. 　前記各ブロックの位置情報は、前記文書の先頭文字から前記各ブロックの先頭文字までの文字数を含む、請求項１に記載の検索システム。
  5. 　前記計算部は、前記ブロックに含まれる文字列において、指定された文字種を含む場合、前記文字種を除いた文字列にハッシュ関数を適用してハッシュ値を計算する、請求項１に記載の検索システム。
  6. 　前記文書グループ化部は、グループに含まれる複数の文書を、検索スコアに基づきソートするソート部を含む、請求項１に記載の検索システム。
  7. 　入力された検索語に基づき文書検索を行い、検索結果を出力する検索システムにより実行される検索方法であって、
    　検索対象となる文書を、指定された分割情報に基づき複数のブロックに分割するステップと、
    　各ブロックに含まれる文字列にハッシュ関数を適用して該各ブロックのハッシュ値を計算するステップと、
    　得られた前記ハッシュ値を前記文書におけるブロックの位置情報とともに記憶部に記憶するステップと、
    　前記検索語に基づき検索されて得られた各文書につき、該検索語を含むブロックの位置情報を基に、対応するハッシュ値を前記記憶部から取り出し、前記ハッシュ値が一致する文書をグループ化して、前記検索結果として出力するステップとを含む、検索方法。
  8. 　前記分割するステップと前記計算するステップと前記記憶するステップは、前記検索システムが検索時に使用するインデックスの作成時に実行され、前記出力するステップは、前記検索時に実行される、請求項７に記載の検索方法。
  9. 　前記分割するステップでは、前記分割情報としてのセンテンス毎、パラグラフ毎、空行、前記文書に付加された付加情報の少なくとも１つにより分割する、請求項７に記載の検索方法。
  10. 　前記文書は、複数の単語（トークン）が順に配列するトークン列とされ、前記各ブロックの位置情報は、前記文書の先頭トークンから前記各ブロックの先頭トークンまでのトークンの順番を含む、請求項７に記載の検索方法。
  11. 　前記各ブロックの位置情報は、前記文書の先頭文字から前記各ブロックの先頭文字までの文字数を含む、請求項７に記載の検索方法。
  12. 　前記計算するステップでは、前記ブロックに含まれる文字列において、指定された文字種を含む場合、前記文字種を除いた文字列にハッシュ関数を適用してハッシュ値を計算する、請求項７に記載の検索方法。
  13. 　前記出力するステップは、グループに含まれる複数の文書を、検索スコアに基づきソートするステップを含む、請求項７に記載の検索方法。
  14. 　入力された検索語に基づき文書検索を行い、検索結果を出力する検索システムにより実行される検索方法を実行するためのコンピュータにより読み取り可能なプログラムであって、
    検索対象となる文書を、指定された分割情報に基づき複数のブロックに分割するステップと、
    　各ブロックに含まれる文字列にハッシュ関数を適用して該各ブロックのハッシュ値を計算するステップと、
    　得られた前記ハッシュ値を前記文書におけるブロックの位置情報とともに記憶部に記憶するステップと、
    　前記検索語に基づき検索されて得られた各文書につき、該検索語を含むブロックの位置情報を基に、対応するハッシュ値を前記記憶部から取り出し、前記ハッシュ値が一致する文書をグループ化して、前記検索結果として出力するステップとを実行させる、プログラム。
  15. 　前記分割するステップと前記計算するステップと前記記憶するステップを、前記検索システムが検索時に使用するインデックスの作成時に実行させ、前記出力するステップを、前記検索時に実行させる、請求項１４に記載のプログラム。
  16. 　前記分割するステップでは、前記分割情報としてのセンテンス毎、パラグラフ毎、空行、前記文書に付加された付加情報の少なくとも１つにより分割する、請求項１４に記載のプログラム。
  17. 　前記計算するステップでは、前記ブロックに含まれる文字列において、指定された文字種を含む場合、前記文字種を除いた文字列にハッシュ関数を適用してハッシュ値を計算する、請求項１４に記載のプログラム。
  18. 　前記出力するステップは、グループに含まれる複数の文書を、検索スコアに基づきソートするステップを含む、請求項１４に記載のプログラム。
  19. 　入力された検索語に基づき文書検索を行い、検索結果を出力する検索システムであって、
    　検索対象となる文書を、指定された分割情報としてのセンテンス毎、パラグラフ毎、空行、前記文書に付加された付加情報の少なくとも１つに基づき複数のブロックに分割する分割部と、
    　各ブロックに含まれる文字列にハッシュ関数を適用して該各ブロックのハッシュ値を計算する計算部と、
    　得られた前記ハッシュ値を、複数の単語（トークン）が順に配列するトークン列とされる前記文書の先頭トークンから前記各ブロックの先頭トークンまでのトークンの順番を含むブロックの位置情報とともに記憶する記憶部と、
    　前記検索語に基づき検索されて得られた各文書につき、該検索語を含むブロックの位置情報を基に、対応するハッシュ値を前記記憶部から取り出し、前記ハッシュ値が一致する文書をグループ化して、前記検索結果として出力する文書グループ化部とを備え、
    　前記計算部は、前記ブロックに含まれる文字列において、指定された文字種を含む場合、前記文字種を除いた文字列にハッシュ関数を適用してハッシュ値を計算し、
    　前記文書グループ化部は、グループに含まれる複数の文書を、検索スコアに基づきソートするソート部を含む、検索システム。
  20. 　入力された検索語に基づき文書検索を行い、検索結果を出力する検索システムであって、
    　検索対象となる文書を、指定された分割情報としてのセンテンス毎、パラグラフ毎、空行、前記文書に付加された付加情報の少なくとも１つに基づき複数のブロックに分割する分割部と、
    　各ブロックに含まれる文字列にハッシュ関数を適用して該各ブロックのハッシュ値を計算する計算部と、
    　得られた前記ハッシュ値を、前記文書の先頭文字から前記各ブロックの先頭文字までの文字数を含むブロックの位置情報とともに記憶する記憶部と、
    　前記検索語に基づき検索されて得られた各文書につき、該検索語を含むブロックの位置情報を基に、対応するハッシュ値を前記記憶部から取り出し、前記ハッシュ値が一致する文書をグループ化して、前記検索結果として出力する文書グループ化部とを備え、
    　前記計算部は、前記ブロックに含まれる文字列において、指定された文字種を含む場合、前記文字種を除いた文字列にハッシュ関数を適用してハッシュ値を計算し、
    　前記文書グループ化部は、グループに含まれる複数の文書を、検索スコアに基づきソートするソート部を含む、検索システム。
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
PCT/JP2009/067929 2008-10-20 2009-10-16 検索システム、検索方法およびプログラム WO2010047286A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US13/124,822 US9031935B2 (en) 2008-10-20 2009-10-16 Search system, search method, and program
JP2010534793A JP5138046B2 (ja) 2008-10-20 2009-10-16 検索システム、検索方法およびプログラム
EP09821983A EP2367121A4 (en) 2008-10-20 2009-10-16 SEARCH, SEARCH AND PROGRAM

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008270028 2008-10-20
JP2008-270028 2008-10-20

Publications (1)

Publication Number Publication Date
WO2010047286A1 true WO2010047286A1 (ja) 2010-04-29

Family

ID=42119326

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/067929 WO2010047286A1 (ja) 2008-10-20 2009-10-16 検索システム、検索方法およびプログラム

Country Status (5)

Country Link
US (1) US9031935B2 (ja)
EP (1) EP2367121A4 (ja)
JP (1) JP5138046B2 (ja)
TW (1) TW201027375A (ja)
WO (1) WO2010047286A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013105273A (ja) * 2011-11-11 2013-05-30 Nippon Telegr & Teleph Corp <Ntt> 類似ページ検出装置、類似ページ検出方法、類似ページ検出プログラム
JP2013532321A (ja) * 2010-05-14 2013-08-15 マイクロソフト コーポレーション 自動ソーシャルネットワーキンググラフマイニングおよび視覚化
CN104077272A (zh) * 2014-06-23 2014-10-01 华为技术有限公司 一种字典压缩的方法和装置
WO2018198192A1 (ja) 2017-04-25 2018-11-01 三菱電機株式会社 検索装置、検索システム、検索方法及び検索プログラム
US11005645B2 (en) 2016-01-15 2021-05-11 Mitsubishi Electric Corporation Encryption device, encryption method, computer readable medium, and storage device
WO2022137668A1 (ja) * 2020-12-25 2022-06-30 株式会社日立製作所 データファイル暗号化送受信システム及びデータファイル暗号化送受信方法

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150026159A1 (en) * 2012-03-05 2015-01-22 Evresearch Ltd Digital Resource Set Integration Methods, Interfaces and Outputs
US9026992B2 (en) * 2012-06-22 2015-05-05 Microsoft Technology Licensing, Llc Folded views in development environment
CN103577413B (zh) * 2012-07-20 2017-11-17 阿里巴巴集团控股有限公司 搜索结果排序方法及系统、搜索结果排序优化方法及系统
TWI484359B (zh) * 2012-10-26 2015-05-11 Inst Information Industry 文章資訊提供方法以及系統
CN104283930B (zh) * 2013-07-11 2017-09-22 一零四资讯科技股份有限公司 安全索引的关键字搜索系统及建立该系统的方法
GB2520936A (en) 2013-12-03 2015-06-10 Ibm Method and system for performing search queries using and building a block-level index
US9996629B2 (en) * 2015-02-10 2018-06-12 Researchgate Gmbh Online publication system and method
EP3096277A1 (en) 2015-05-19 2016-11-23 ResearchGate GmbH Enhanced online user-interaction tracking
TWI608415B (zh) * 2016-11-29 2017-12-11 關貿網路股份有限公司 電子檔案資料擷取系統及其方法
CN112651236B (zh) * 2020-12-28 2021-10-01 中电金信软件有限公司 提取文本信息的方法、装置、计算机设备和存储介质
US11809493B2 (en) * 2021-01-19 2023-11-07 Micro Focus Llc System and method for tokenization of data

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07295994A (ja) * 1994-04-22 1995-11-10 Sharp Corp 情報検索装置
JPH07295970A (ja) * 1994-04-21 1995-11-10 Fuji Xerox Co Ltd 文書処理装置
JP2001167096A (ja) * 1999-12-06 2001-06-22 Ricoh Co Ltd 文書検索システム、文書検索方法及びその方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体
JP2003141027A (ja) * 2001-10-31 2003-05-16 Toshiba Corp 要約作成方法および要約作成支援装置およびプログラム
JP2005173889A (ja) * 2003-12-10 2005-06-30 Intellectual Capital Group Kk 削除候補特徴情報生成装置、受信情報処置装置および削除候補判定装置、方法、プログラムおよび記録媒体
JP2006285499A (ja) * 2005-03-31 2006-10-19 Nec Corp データマイニング装置、データマイニング方法およびそのプログラム

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5909677A (en) 1996-06-18 1999-06-01 Digital Equipment Corporation Method for determining the resemblance of documents
US6615209B1 (en) 2000-02-22 2003-09-02 Google, Inc. Detecting query-specific duplicate documents
US6757675B2 (en) * 2000-07-24 2004-06-29 The Regents Of The University Of California Method and apparatus for indexing document content and content comparison with World Wide Web search service
US6978419B1 (en) 2000-11-15 2005-12-20 Justsystem Corporation Method and apparatus for efficient identification of duplicate and near-duplicate documents and text spans using high-discriminability text fragments
US6658423B1 (en) 2001-01-24 2003-12-02 Google, Inc. Detecting duplicate and near-duplicate files
US6910037B2 (en) * 2002-03-07 2005-06-21 Koninklijke Philips Electronics N.V. Method and apparatus for providing search results in response to an information search request
US20050108630A1 (en) * 2003-11-19 2005-05-19 Wasson Mark D. Extraction of facts from text
US7475061B2 (en) * 2004-01-15 2009-01-06 Microsoft Corporation Image-based document indexing and retrieval
US7523098B2 (en) * 2004-09-15 2009-04-21 International Business Machines Corporation Systems and methods for efficient data searching, storage and reduction
US7814078B1 (en) * 2005-06-20 2010-10-12 Hewlett-Packard Development Company, L.P. Identification of files with similar content
US20070260450A1 (en) * 2006-05-05 2007-11-08 Yudong Sun Indexing parsed natural language texts for advanced search
US7890533B2 (en) * 2006-05-17 2011-02-15 Noblis, Inc. Method and system for information extraction and modeling
JP2008015774A (ja) * 2006-07-05 2008-01-24 Nagaoka Univ Of Technology 模倣文書検出システム及びプログラム
JP5181504B2 (ja) * 2007-03-22 2013-04-10 富士通株式会社 データ処理方法、プログラム及び情報処理装置
US20080270436A1 (en) * 2007-04-27 2008-10-30 Fineberg Samuel A Storing chunks within a file system
US7676501B2 (en) * 2008-03-22 2010-03-09 Wilson Kelce S Document integrity verification

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07295970A (ja) * 1994-04-21 1995-11-10 Fuji Xerox Co Ltd 文書処理装置
JPH07295994A (ja) * 1994-04-22 1995-11-10 Sharp Corp 情報検索装置
JP2001167096A (ja) * 1999-12-06 2001-06-22 Ricoh Co Ltd 文書検索システム、文書検索方法及びその方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体
JP2003141027A (ja) * 2001-10-31 2003-05-16 Toshiba Corp 要約作成方法および要約作成支援装置およびプログラム
JP2005173889A (ja) * 2003-12-10 2005-06-30 Intellectual Capital Group Kk 削除候補特徴情報生成装置、受信情報処置装置および削除候補判定装置、方法、プログラムおよび記録媒体
JP2006285499A (ja) * 2005-03-31 2006-10-19 Nec Corp データマイニング装置、データマイニング方法およびそのプログラム

Non-Patent Citations (1)

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

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013532321A (ja) * 2010-05-14 2013-08-15 マイクロソフト コーポレーション 自動ソーシャルネットワーキンググラフマイニングおよび視覚化
US9990429B2 (en) 2010-05-14 2018-06-05 Microsoft Technology Licensing, Llc Automated social networking graph mining and visualization
US11657105B2 (en) 2010-05-14 2023-05-23 Microsoft Technology Licensing, Llc Automated networking graph mining and visualization
JP2013105273A (ja) * 2011-11-11 2013-05-30 Nippon Telegr & Teleph Corp <Ntt> 類似ページ検出装置、類似ページ検出方法、類似ページ検出プログラム
CN104077272A (zh) * 2014-06-23 2014-10-01 华为技术有限公司 一种字典压缩的方法和装置
CN104077272B (zh) * 2014-06-23 2017-01-04 华为技术有限公司 一种字典压缩的方法和装置
US11005645B2 (en) 2016-01-15 2021-05-11 Mitsubishi Electric Corporation Encryption device, encryption method, computer readable medium, and storage device
WO2018198192A1 (ja) 2017-04-25 2018-11-01 三菱電機株式会社 検索装置、検索システム、検索方法及び検索プログラム
US11106740B2 (en) 2017-04-25 2021-08-31 Mitsubishi Electric Corporation Search device, search system, search method, and computer readable medium
WO2022137668A1 (ja) * 2020-12-25 2022-06-30 株式会社日立製作所 データファイル暗号化送受信システム及びデータファイル暗号化送受信方法
JP2022102086A (ja) * 2020-12-25 2022-07-07 株式会社日立製作所 データファイル暗号化送受信システム及びデータファイル暗号化送受信方法
JP7325396B2 (ja) 2020-12-25 2023-08-14 株式会社日立製作所 データファイル暗号化送受信システム及びデータファイル暗号化送受信方法

Also Published As

Publication number Publication date
JPWO2010047286A1 (ja) 2012-03-22
EP2367121A1 (en) 2011-09-21
US20110302166A1 (en) 2011-12-08
EP2367121A4 (en) 2012-12-26
JP5138046B2 (ja) 2013-02-06
TW201027375A (en) 2010-07-16
US9031935B2 (en) 2015-05-12

Similar Documents

Publication Publication Date Title
JP5138046B2 (ja) 検索システム、検索方法およびプログラム
US9069857B2 (en) Per-document index for semantic searching
US20060179039A1 (en) Method and system for performing secondary search actions based on primary search result attributes
US20080288442A1 (en) Ontology Based Text Indexing
US7548845B2 (en) Apparatus, method, and program product for translation and method of providing translation support service
Wu et al. Searching services" on the web": A public web services discovery approach
CN105404677A (zh) 一种基于树形结构的检索方法
JP2010262577A (ja) 抽出規則作成システム、抽出規則作成方法及び抽出規則作成プログラム
US20140129543A1 (en) Search service including indexing text containing numbers in part using one or more number index structures
CN112380337A (zh) 基于富文本的高亮方法及装置
JP4750628B2 (ja) 情報ランキング方法及び装置及びプログラム及びコンピュータ読み取り可能な記録媒体
CN102257490A (zh) 文档信息选择方法和计算机程序产品
US20140358522A1 (en) Information search apparatus and information search method
JP3784060B2 (ja) データベース検索システム、その検索方法及びプログラム
JP5869948B2 (ja) パッセージ分割方法、装置、及びプログラム
JP5169456B2 (ja) 文書検索システム、文書検索方法および文書検索プログラム
JP2001265774A (ja) 情報検索方法、装置、および情報検索プログラムを記録した記録媒体、ハイパーテキスト情報検索システム
JP2005242416A (ja) 自然言語文の検索方法および検索装置
JP2006243861A (ja) 履歴作成装置、活動履歴作成方法、及び活動履歴作成プログラム
JP5963310B2 (ja) 情報処理装置、情報処理方法、及び、情報処理プログラム
CN105426490A (zh) 一种基于树形结构的索引方法
JP2012104051A (ja) 文書インデックス作成装置
US20080033953A1 (en) Method to search transactional web pages
JP2010272006A (ja) 関係抽出装置、関係抽出方法、及びプログラム
JP5285491B2 (ja) 情報検索システム、方法及びプログラム、索引作成システム、方法及びプログラム、

Legal Events

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

Ref document number: 09821983

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010534793

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2009821983

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13124822

Country of ref document: US