Information processing apparatus, control method, and program

Abstract

To provide a cross-searching system that needs to conduct authority management of various types of searching from various document sources according to the respective document sources, and a mechanism that can integrally conduct the authority management.SOLUTION: The present invention is an information processing apparatus that collects documents from a document management source and manages information related to the documents, and comprises: acquisition means that acquires association information of authority data imparted to documents in the document management source, and authority data related to a user who executes searching in the collected documents; and authorization means that, on the basis of the acquired association information, imparts, to the collected documents, the authority data related to the user who executes the searching and corresponding to the authority data imparted in the document management source.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] This relates to a technology for searching document data. [Background technology]

[0002] There is a technology called federated search that allows documents contained in different document sources to be searched together. One of the features of federated search is that it allows a searcher to search only for documents that they have permission to view in the document sources.

[0003] When the search engine and the document source use the same authentication infrastructure, it is relatively easy to perform searches that take authority into account. On the other hand, when the search engine and the document source use different authentication infrastructures, or when multiple document sources use different authentication infrastructures, some ingenuity is required to make this possible.

[0004] One way to achieve this is to use some kind of database to map the roles logged into the search engine with the roles of the document source.

[0005] Patent Document 1 discloses a configuration for linking permissions using an account management DB. A record in the account management DB consists of a corresponding ID, which is a key for aggregating accounts, an authentication server ID, which is an identifier for the authentication server, and a user ID, which is the ID of the user on the authentication server. Using this account management DB, a search engine recognizes the correspondence between permissions in various authentication servers and uses the permission information when searching for documents.

[0006] Unlike Patent Document 1, this document mainly targets the case where each document source also functions as an authentication server. However, even if the authentication server is configured separately, the method described in this document can be used in the same way. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-102518 DISCLOSURE OF THE INVENTION [Problem to be solved by the invention]

[0008] Patent Document 1 describes a configuration in which a search engine accesses an authentication server during a search to dynamically obtain information about the group to which a user belongs. However, there are cases in which this configuration is difficult to implement. For example, if the search engine is on a cloud and the authentication server is on an internal LAN, it may not be possible to implement a configuration on the network in which the search engine on the cloud accesses the authentication server on the internal LAN. The same applies when a document source also serves as an authentication server.

[0009] Therefore, it is desirable to be able to perform cross-searches that take authority into account, even when it is difficult for search engines to access document sources at the time of search.

[0010] Therefore, the present invention aims to provide a mechanism that can perform integrated authority management in a cross-sectional search system that requires authority management for various searches from various document sources according to each document source. [Means for solving the problem]

[0011] The present invention is an information processing device that collects documents from a document management source and manages information related to the documents, and is characterized by comprising: an acquisition means that acquires correspondence information between authority data assigned to documents at the document management source and authority data related to a user who performs a search on the collected documents; and an authorization means that assigns authority data related to the user who performs the search to the collected documents, which corresponds to the authority data assigned at the document management source, based on the acquired correspondence information. [Effects of the Invention]

[0012] According to the present invention, in a cross-sectional search system that requires the management of various search authorizations according to each document source from various document sources, it is possible to perform integrated authorization management. [Brief explanation of the drawings]

[0013] [Figure 1] 1 is a diagram showing an example of an overall image of a search system according to an embodiment of the present invention. [Figure 2] 1 is a block diagram showing an example of the hardware configuration of a search engine 100, a search engine authentication infrastructure 110, and a client terminal 140 according to an embodiment of the present invention. [Figure 3] FIG. 3 is a diagram showing an example of data stored in a document index in an embodiment of the present invention. [Figure 4] FIG. 10 is a diagram illustrating an example of data stored in an authority table in the embodiment of the present invention. [Figure 5] FIG. 10 is a diagram illustrating an example of data stored in an account information table according to the embodiment of the present invention. [Figure 6] 10 is a flowchart illustrating an example of a login process in which a client terminal logs in from a search engine authentication infrastructure according to an embodiment of the present invention. [Figure 7] 10 is a flowchart illustrating an example of a search process performed by a search engine according to an embodiment of the present invention. [Figure 8] 10 is a flowchart illustrating an example of a document crawling process performed by a crawler in a synchronous configuration according to an embodiment of the present invention. [Figure 9] 10 is a flowchart illustrating an example of an authority crawl process performed by a crawler in a synchronous configuration according to an embodiment of the present invention. [Figure 10] 10 is a flowchart illustrating an example of a crawling process of a document performed by a crawler in a folder-type configuration according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0014] First, the main points of the embodiment of the present invention will be described.

[0015] Even if a search engine on the cloud cannot access document sources on the company's internal LAN, communication from the internal LAN to the search engine is often permitted, and it is possible to configure the document source within the internal LAN to send document and permission information to the search engine in advance.

[0016] The process of sending search documents and permissions from a document source to a search engine is called crawling, and the module that performs the crawling is called a crawler. In this embodiment, an authority table with the items "authority ID" and "search engine role ID list" as shown in Figure 4 is prepared in a location separate from the document index in the search engine, enabling searches that take authority into consideration.

[0017] The basic idea is that the search engine role ID list represents the permissions granted to the user logged in to the search engine, and the permission ID represents the permissions included in the document. The permission table is a table that links these two items.

[0018] This document shows two types of authorization table usage: "synchronization type" and "folder type." These two types can be registered in the same authorization table.

[0019] [Synchronous] The contents of the authority table are registered by the crawler. The authority ID is a combination of the document source ID and the role ID in the document source. The search engine role ID list is registered by linking the search engine user and the document source user by email address, etc.

[0020] The registered content will be in the format shown in the first line of Figure 4.

[0021] [Folder type] The authority table is manually registered in advance with the authority ID, search engine role ID list, document source ID, and part of the document path to which the authority ID is assigned. The registered content is in the format shown in the fourth line of Figure 4. When crawling, the authority ID is inserted into the document based on the path information.

[0022] It is also possible to use this method in combination with a configuration in which a search engine accesses a document source to obtain authority information during a search, as shown in Patent Document 1. In this case, the search engine accesses the document source to generate information equivalent to the authority table for the logged-in user, and expand the authority ID list obtained from the authority table.

[0023] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[0024] FIG. 1 is a configuration diagram showing an outline of a search system according to an embodiment of the present invention.

[0025] The search system consists of a search engine 100 that performs searches, a search engine authentication infrastructure 110 that manages the login status of client terminals to the search engine, a group of document sources 130 that contain the original documents to be searched, and a group of crawlers 120 that obtain document and authority information from the group of document sources 130 and register it in the search engine 100.

[0026] The search engine includes a document index storage unit 101 and an authority table storage unit 102. The document index storage unit 101 stores documents to be searched in a format as shown in Fig. 3. The authority table storage unit 102 stores an authority table as shown in Fig. 4, which is used for searches that take authority into consideration.

[0027] The search engine authentication infrastructure 110 includes a search engine account information storage unit 111 and a session storage unit 112. The search engine account information storage unit 111 stores an account information table such as that shown in Fig. 5, which shows information about search engine accounts. The session storage unit 112 stores session information for identifying the logged-in client terminal.

[0028] The document source group 130 consists of multiple document sources, each of which stores different documents and has different authority systems. Each document source holds multiple original documents that serve as source data for searches. A document source includes a group of roles as entities with authority over that document source. Each role can be distinguished by a role ID. Each document source includes a unique document source ID. In addition, a document source name may be included as the name of the document source to make it easier for searchers to recognize the document source. In what follows, all document source names will be treated as existing, but if they do not exist, the document source ID may be used instead.

[0029] The crawler group 120 includes a crawler corresponding to each document source. The crawler performs a crawling process by acquiring the original document ID, data body, metadata, and authority information of the original document from the document source, processing the original document information, and then registering it in the document index storage unit 101. In addition, as part of the crawling process, an entry may be registered in the authority table storage unit 102. The crawling process will be described in detail later. Note that one crawler may crawl multiple document sources. In the following explanation, we will assume that there is a one-to-one correspondence between crawlers and document sources.

[0030] The crawler has a configuration file, and the configuration file stores the document source ID of the corresponding document source, the document source name, and connection information for connecting to the document source.

[0031] The client terminal 140 communicates with the search engine authentication infrastructure 110 to log in, and then transmits a search query to the search engine 100, thereby obtaining a group of documents as search results according to the search query and authority information.

[0032] FIG. 2 is a block diagram showing an example of the hardware configuration of the search engine 100, the search engine authentication infrastructure 110, and the client terminal 140 according to the embodiment of the present invention.

[0033] As shown in FIG. 2, the information processing device is connected to a CPU (Central Processing Unit) 201, a ROM (Read Only Memory) 202, a RAM (Random Access Memory) 203, an input controller 205, a video controller 206, a memory controller 207, and a communication I / F controller 208 via a system bus 204.

[0034] The CPU 201 comprehensively controls each device and controller connected to the system bus 204 .

[0035] ROM202 or external memory 211 stores the BIOS (Basic Input / Output System) and OS (Operating System), which are control programs executed by CPU201, computer-readable and executable programs for realizing this information processing method, and various necessary data (including data tables).

[0036] The RAM 203 functions as a main memory, a work area, etc. for the CPU 201. The CPU 201 loads programs and the like required for executing processing from the ROM 202 or the external memory 211 into the RAM 203, and executes the loaded programs to realize various operations.

[0037] The input controller 205 controls input from an input device such as a keyboard 209 or a pointing device such as a mouse (not shown). If the input device is a touch panel, the user can issue various instructions by pressing (touching with a finger or the like) icons, cursors, or buttons displayed on the touch panel.

[0038] The touch panel may also be a touch panel capable of detecting positions touched by multiple fingers, such as a multi-touch screen.

[0039] The video controller 206 controls the display on an external output device such as a display 210. The display also includes the display of a notebook computer integrated into the main body. Note that the external output device is not limited to a display, and may be, for example, a projector. In addition, for devices capable of receiving the above-mentioned touch operation, an input device is also provided.

[0040] The video controller 206 can control a video memory (VRAM) for display control, and can use part of the RAM 203 as a video memory area, or can provide a separate dedicated video memory.

[0041] The memory controller 207 controls access to the external memory 211. The external memory may be an external storage device (hard disk) that stores a boot program, various applications, font data, user files, edited files, and various data, a flexible disk (FD), or a CompactFlash (registered trademark) memory connected to a PCMCIA card slot via an adapter.

[0042] The communication I / F controller 208 connects and communicates with external devices via a network, and executes communication control processing on the network. For example, communication using TCP / IP, telephone lines such as ISDN, and 3G lines for mobile phones are possible.

[0043] The CPU 201 enables display on the display 210 by, for example, executing a process of expanding (rasterizing) an outline font into a display information area in the RAM 203. The CPU 201 also enables user instructions using a mouse cursor (not shown) on the display 210.

[0044] Figure 3 shows the data structure of the document index table for search stored in the document index storage unit 101. Each document includes a document ID, a body text, and an authority ID list. In addition, each document may also include metadata. Depending on the document source, some metadata items cannot obtain values. Items for which values cannot be obtained store a character string indicating that no value exists.

[0045] For example, metadata can include a document source name, which is a string representing the document source from which the document was obtained, a path, which is a string representing the path to reach the original document in a hierarchical document source, and a string representing the title of the document.

[0046] The document ID is an identifier that uniquely identifies each document. The body is a string that represents the content of the document.

[0047] The authority ID is information about the authority that can view a document. Each document contains multiple authority IDs, and searchers who have any one or more of these authority IDs can search the document.

[0048] The document index storage unit 101 may contain an inverted index of the text as auxiliary data for high-speed full-text search of the text. The inverted index may have a known structure and be created by a known method.

[0049] Figure 4 shows the data structure of the authority table stored in the authority table storage unit 102. A record in the authority table is called an authority record. The authority record includes an authority ID, a search engine role ID list, and a document source ID. Furthermore, the authority record includes information for narrowing down the authority, which differs for each document source, for the crawler.

[0050] The authority ID is the identifier of the authority record. The search engine role ID list is used to make the authority ID available to users who are logged in to the search engine. The document source ID is the identifier of the document source from which the authority information is obtained. The authority table is a kind of intermediate table that links the search engine role ID in the search engine account information table with the authority ID in the document index.

[0051] 5 shows the data structure of the search engine account table stored in the search engine account information storage unit 111. Each record in the search engine account information table represents one piece of search engine user information, and consists of a user ID, password, search engine role ID list, and unique role.

[0052] The user ID is an identifier for a search engine user. The password is a secret string used to authenticate the user ID and is used when logging in. As a method for storing passwords, in addition to storing the plain text of the password as is, it is also possible to hash the plain text of the password using a known method and store it. The search engine role ID list is a list of multiple role IDs assigned to a client terminal that logs in to the search engine using the user ID.

[0053] One role in the search engine role ID list matches the unique role, which is a different value for every user.

[0054] Here, the search engine roles are assumed to be roles that are uniquely assigned to each user, and roles that are commonly assigned to users belonging to a group consisting of a specific set of users.

[0055] The login process executed by the search engine authentication infrastructure 110 in the embodiment of the present invention will be described with reference to the flowchart of FIG.

[0056] In step S601, the search engine authentication infrastructure 110 receives the user ID and password sent from the client terminal 140.

[0057] In step S602, the search engine account information storage unit 111 is referenced to verify the user ID and password.

[0058] A record of a search engine account that matches the user ID is extracted from the search engine account information table in Figure 5. If a search engine account with a matching user ID does not exist, the login is deemed unsuccessful and the process proceeds to step S605. If a search engine account with a matching user ID exists, a match check is performed between the password for that account and the password received from the client terminal. If the password match check fails, the login is deemed unsuccessful and the process proceeds to step S605. If the password match check is successful, the login is deemed successful and the process proceeds to step S603.

[0059] If the password is hashed and stored in the search engine account information table, the password received from the client terminal is also hashed in the same way before being checked for a match.

[0060] In step S603, it is assumed that the login has been successful, and a session ID is generated for the client terminal. After that, the session storage unit 112 stores a pair of the session ID and the user ID.

[0061] In step S604, the session ID is sent to the client terminal, and the process ends. After that, the client terminal can send this session ID to the search engine, allowing searches to be performed in an authenticated state.

[0062] In step S605, it is assumed that the login has failed, and a login failure message is returned to the client terminal, and the process ends.

[0063] The search process executed by the search engine 100 in the embodiment of the present invention will be described using the flowchart in Fig. 7. As an example, consider a case where the user ID "alice" in Fig. 5 is logged in from the client terminal 140 and sends the search query "suggestion" to the search engine.

[0064] In step S701, the session ID and search query sent from the client terminal 140 are received.

[0065] In step S702, the search engine authentication infrastructure 110 is queried for the session with the session ID. The search engine authentication infrastructure 110 refers to the session storage unit 112, and if the session ID exists, acquires the user ID paired with the session ID. Furthermore, the search engine authentication infrastructure 110 refers to the search engine account information storage unit 111 and acquires the search engine role ID list corresponding to the user ID. The search engine authentication infrastructure 110 then returns the user ID and search engine role ID list to the search engine 100, and the search engine 100 receives them.

[0066] For example, when a session ID in which user ID "alice" is logged in is received from a client terminal, "SEUsr001" and "SEGrp001", which are the search engine role ID lists for "alice", can be obtained.

[0067] If the session ID does not exist in the session storage unit 112, the search engine authentication infrastructure 110 returns a session acquisition failure message to the search engine 100.

[0068] In step S703, it is determined whether the session acquisition was successful. If a user ID / search engine role ID list has been received from the search engine authentication infrastructure 110, it is considered successful and the process proceeds to step S705. If a session acquisition failure message has been received from the search engine authentication infrastructure 110, it is considered a failure and the process proceeds to step S704.

[0069] In step S704, a message indicating that login is required is returned to the client terminal, and the process ends.

[0070] In step S705, the authority table storage unit 102 is searched using the search engine role ID list received from the search engine authentication infrastructure 110 as a query. If there is one or more common search engine role IDs between the search engine role ID list item of an authority record in the authority table and the search engine role ID list that is the query, the authority record satisfies the search conditions. A list of authority IDs is obtained from all authority records that satisfy the search conditions.

[0071] For example, if "SEUsr001" and "SEGrp001" are obtained as the search engine role ID list for user ID "alice," these two role IDs are used to search the permission table in Figure 4. As a result, "cfs.example.com:CFSGrp001" and "lfs-jinji" are obtained as permission IDs that match the search engine role ID.

[0072] In step S706, documents are obtained from the document index storage unit 101 using the search query and the authority ID list. A full-text search of the text is performed using the search query from the document index storage unit 101, and matching documents become search result candidate documents. For each search result candidate document, if there is one or more common authority IDs in the authority ID list item of that document and the authority ID list obtained from the authority table storage unit 102, that document is included in the search result. Conversely, if there is no common authority ID, that document is not included in the search result. In this way, a document list that becomes the search result is created.

[0073] Furthermore, the document list of search results is scored and ranked. Scoring is a process in which each document in the search results is assigned a score based on its relevance to the search query. When performing a full-text search, scoring can be performed using well-known techniques such as TF-IDF. The document list of search results is sorted in descending order of score to create the final document list of search results.

[0074] For example, consider the case where the search query "suggestion" is received from a client terminal, and "cfs.example.com:CFSGrp001" and "lfs-jinji" are used as the authorization IDs as described above. In this case, from the document index in Figure 3, documents that contain the string "suggestion" in the body and one or more of "cfs.example.com:CFSGrp001" or "lfs-jinji" in the authorization ID list are obtained as search results. As a result, the document with document ID "CFSFile001" is obtained.

[0075] In step S707, the search results are returned to the client terminal, and the process ends.

[0076] 8 and 9 are flowcharts showing an example of the process performed by a crawler in a synchronous configuration in which the authority of a document source and the authority of a search engine are synchronized.

[0077] As an example, we will explain the processing of these flowcharts using a configuration for crawling a cloud file server that manages files in a hierarchical structure. The original document is a file, and each file is registered as a document in the document index. The file server in question has "cfs.example.com" as its document source ID and "Cloud FS" as its document source name. On the file server in question, permissions are granted to users or groups. A user is the entity that logs in to the file server, and a group is a collection of users prepared for permission management.

[0078] Using the flowchart in Figure 8, we will explain the document crawling process in which the crawler acquires original documents from the document source and registers them in the document index storage unit 101. When applying this flowchart, it is assumed that each original document included in the document source has an original document ID as an identifier. Furthermore, it is assumed that the document source has an API that returns all original document IDs and an API that receives an original document ID and returns the data body, metadata, and accessible roles of the original document.

[0079] In step S801, the crawler enumerates a list of original document IDs included in the document source. For example, the crawler uses the API of the file server to receive a list of all file IDs of files included in the file server.

[0080] In step S802, a repeat process is started for the listed original document IDs. The following description will be given taking as an example a document having "CFSFile001" as the file ID.

[0081] In step S803, the data body and metadata of the original document corresponding to the original document ID are obtained from the document source. For example, the file body data is downloaded from the file server, and the path string representing the hierarchical structure of the file and the file name are also obtained. The file body corresponding to the file ID "CFSFile001" is a file in Office Open XML Document format, and the path string obtained is " / Sales Department / Proposal Materials / Company A Project Proposal.docx", and the file name is "Company A Project Proposal.docx".

[0082] In step S804, the main text and metadata for the document index are extracted from the data body and metadata of the original document. The main text can be extracted from the data in the file body. This extraction method uses a known method that differs depending on the type of data. For example, if the data body is in Office Open XML format, it is possible to parse the XML and extract character string information as the main text. The file name "Company A Project Proposal.docx" is used as the title element of the metadata, and the path string " / Sales Department / Proposal Materials / Company A Project Proposal.docx" is used as is as the path.

[0083] The metadata document source name can use "Cloud FS" stored in the crawler configuration file.

[0084] In addition to this example, various extraction methods can be used for each document source and crawler. For example, when the file body is an HTML document, <title> It is also possible to configure it so that the document title of the metadata is obtained from the tag.< / title> In step S805, a list of accessible roles for the original document corresponding to the original document ID is obtained from the document source. For example, the accessible roles for the file corresponding to the file ID "CFSFile001" indicate that a group with an ID of "CFSGrp001" and a user with an ID of "CFSUsr001" have access permission on the file server.

[0085] In step S806, an authorization ID list is generated from the accessible role list of the original document.

[0086] For example, you can generate a string from each role by connecting the document source ID and the user or group ID with a colon, and use that as the authorization ID. As a result, you can get a list of authorization IDs such as "cfs.example.com:CFSGrp001" and "cfs.example.com:CFSUsr001".

[0087] Naturally, this authority ID must be consistent with the authority ID stored in the authority table storage unit 102 .

[0088] In step S807, the file ID, file body, and authority ID list generated as described above is registered in the document index storage unit 101.

[0089] As a result, an entry like the one in the first line of Figure 3 is registered.

[0090] When the processing of steps S803 to S807 is completed for all original document IDs, the crawling process ends.

[0091] The following describes the crawling process of authority, in which the crawler creates a list of roles from the document source and registers it in the authority table storage unit 102, using the flowchart in FIG.

[0092] It is assumed here that each user included in the document source has an email address.

[0093] Furthermore, the document source is assumed to have an API that returns all users in the document source, an API that returns all groups in the document source, and an API that specifies a group and returns users that belong to that group.

[0094] In step S901, a list of all users is enumerated from the document source.

[0095] In step S902, the process is repeated for each user. The following explanation will be given using the user with user ID "CFSUsr001" as an example. It is assumed that this user has an email address "alice@example.jp" in the document source.

[0096] In step S903, the document source user and the search engine user are associated. This association is basically a one-to-one correspondence. At this time, the search engine user is converted into a unique role for the user.

[0097] One way to do this is to look up a table that maps document source user IDs to search engine user IDs if the crawler configuration file contains such a table. Another way to do this is by using user attributes that are common to both the document source and the search engine, such as email addresses.

[0098] For example, if the document source user ID "CFSUsr001" has the email address "alice@example.jp" and the search engine user ID "alice" also has the email address "alice@example.jp", these users can be associated. "alice" on the search engine side is converted to "SEUsr001", which is the unique role of that user. In other words, the document source user ID "CFSUsr001" corresponds to the search engine role ID "SEUsr001".

[0099] Furthermore, even if there is no common user attribute, association may be established according to a predetermined condition based on related user attributes or the like.

[0100] If the user with the matching email address does not exist in the search engine, or if the user cannot be associated with the email address, the subsequent processing is omitted and the next user is searched for.

[0101] In step S904, an authorization ID is generated for the user of the document source. For example, as described above, a character string can be generated by connecting the document source ID and the user ID with a colon, and this can be used as the authorization ID. As a result, the authorization ID "cfs.example.com:CFSUsr001" is obtained.

[0102] In step S905, an authority entry is registered in the authority table storage unit 102 for the user in the document source.

[0103] At this time, the authority ID generated in step S904 is used, and the document source ID registered in the crawler's configuration file is used. The search engine role ID list uses only one search engine user associated in step S903. For example, an entry like the one in the first line of Figure 4 is registered.

[0104] Once steps S903 to S905 have been performed for all users in the document source, the repetitive process ends.

[0105] The correspondence between the document source user and the search engine user is stored within the crawler for later use.

[0106] In step S906, a list of all groups is enumerated from the document source.

[0107] In step S907, the process starts repeatedly for each group. Hereinafter, the group with group ID "CFSGrp001" will be described as an example.

[0108] In step S908, a list of users belonging to the group is obtained from the document source. For example, it is assumed that users with user IDs "CFSUsr001" and "CFSUsr002" belong to a group with group ID "CFSGrp001."

[0109] In step S909, the document source users belonging to the group are converted into search engine users using the correspondence between document source users and search engine users. For example, the document source user ID "CFSUsr001" can be converted into the search engine user's unique role "SEUsr001," and the document source user ID "CFSUsr002" can be converted into the search engine user's unique role "SEUsr002."

[0110] Note that this process is not performed on the user ID of the document source for which matching was not possible, and only the user for whom matching was successful is used.

[0111] In step S910, an authority ID for the group in the document source is generated. For example, as described above, a character string can be generated by connecting the document source ID and group ID with a colon, and this can be used as the authority ID. As a result, the authority ID "cfs.example.com:CFSGrp001" is obtained.

[0112] In step S911, for the group in the document source, an authority entry is registered in the authority table storage unit 102. At this time, the authority ID generated in step S910 is used, and the document source ID registered in the crawler configuration file is used. The search engine role ID list is used, which is the list of users belonging to the group created in step S909 converted into a list of search engine users.

[0113] For example, an entry like the third line in Figure 4 is registered.

[0114] Once steps S908 to S911 have been performed for all groups in the document source, the loop process ends and the crawl process ends.

[0115] FIG. 10 is a flowchart showing an example of processing performed by a crawler in a folder-type configuration in which authority is determined by a folder path.

[0116] As an example, the process in the flowchart will be explained using a configuration for crawling a file server on an internal LAN that manages files in a hierarchical structure. The original document is a file, and each file is registered as a document in the document index. The file server in question has "lfs.example.local" as the document source ID and "Local FS" as the document source name. Although permissions are managed independently on the file server in question, the search engine will redefine permissions to be assigned based on the folder path.

[0117] In this configuration, the authority ID of a document is determined by referencing the authority table. Before crawling, the authority table in the authority table storage unit 102 is assumed to contain entries for the authority ID, search engine role ID list, and folder path for the document source ID. This authority registration can be performed by manually designing the authorities.

[0118] For example, as shown in Figure 4, assume that an entry with the authority ID "lfs-jinji", search engine role ID list "SEGrp001", and folder path " / Human Resources Materials / " and an entry with the authority ID "lfs-keiri", search engine role ID list "SEGrp002", and folder path " / Accounting Materials / " are registered for the document source ID "lfs.example.local".

[0119] The document crawling process in which the crawler acquires the original document from the document source and registers it in the document index storage unit 101 will be described with reference to the flowchart of FIG.

[0120] In step S1001, the crawler enumerates a list of original document IDs included in the document source.

[0121] For example, the crawler uses the API of the file server to receive a list of all file IDs of the files contained in the file server.

[0122] In step S1002, a repeat process is started for the listed original document IDs. The following description will be given using an example of a document having "LFSFile001" as the file ID.

[0123] In step S1003, the data body and metadata of the original document corresponding to the original document ID are obtained from the document source. For example, the file body data is downloaded from a file server, and a path string representing the hierarchical structure of the file and the file name are also obtained. The file body corresponding to the file ID "LFSFile001" is a file in Office Open XML Document format, and the path string obtained is " / personnel information / work rules.docx", and the file name is "work rules.docx".

[0124] In step S1004, the text and metadata for the document index are extracted from the data body and metadata of the original document. The method for extracting the text and metadata here is the same as that described in the explanation of Figure 8. As a result, the text is extracted from the file body, and "Work Rules.docx" is extracted as the metadata title element, " / Personnel Materials / Work Rules.docx" as the path, and "Local FS" as the document source name.

[0125] In step S1005, an authorization ID is obtained from the authorization table based on part of the path in the metadata and the document source ID. For example, the authorization table is narrowed down using up to the second slash from the beginning of the path in the metadata. If the path is " / personnel_documents / work_rules.docx", up to " / personnel_documents / " is used to narrow down the authorization table. Furthermore, since the document source ID is "lfs.example.local", the authorization ID "lfs-jinji" can be obtained from the authorization table in Figure 4. The path narrowing down rules shown here are just an example, and other configurations are also possible.

[0126] In step S1006, the document is registered in the document index storage unit 101. The file text and metadata are those extracted in step S1004, and the authorization ID list includes one obtained in step S1005. The file ID "LFSFile001" is used as is as the document ID. As an example, an entry like the one shown on the fourth line in Figure 3 is registered.

[0127] When the processing of steps S1003 to S1006 is completed for all original document IDs, the crawling process ends.

[0128] As a result, in a cross-sectional search system that requires the management of various search authorizations according to each document source from various document sources, it is possible to perform integrated authorization management.

[0129] In addition, if settings related to users or permissions are changed in a search engine or document source, the correspondence between the two may become inconsistent. In such cases, the inconsistency can be resolved by detecting the setting change and any associated errors, and updating or rebuilding the tables.

[0130] Although the embodiments of the present invention have been described above, the present invention can be embodied as, for example, a system, an apparatus, a method, a program, a recording medium, etc. Specifically, the present invention may be applied to a system made up of multiple devices, or may be applied to an apparatus made up of a single device.

[0131] The program of the present invention is a program that enables a computer to execute the processing method of each flowchart. Note that the program of the present invention may be a program for each processing method of each device of each flowchart.

[0132] As described above, it goes without saying that the object of the present invention can also be achieved by supplying a recording medium on which a program that realizes the functions of the above-mentioned embodiments is recorded to a system or device, and having the computer (or CPU or MPU) of that system or device read and execute the program stored on the recording medium.

[0133] In this case, the program itself read from the recording medium will realize the novel functions of the present invention, and the recording medium on which the program is recorded will constitute the present invention.

[0134] Examples of recording media for supplying the program include flexible disks, hard disks, optical disks, magneto-optical disks, CD-ROMs, CD-Rs, DVD-ROMs, magnetic tapes, non-volatile memory cards, ROMs, EPROMs, and silicon disks.

[0135] Furthermore, it goes without saying that not only are the functions of the above-mentioned embodiments realized by the computer executing a program it has read, but also cases are included in which an OS (operating system) running on the computer performs some or all of the actual processing based on the instructions of the program, and the functions of the above-mentioned embodiments are realized through that processing.

[0136] Furthermore, it goes without saying that this also includes cases where a program read from a recording medium is written into a memory provided on a function expansion board inserted into a computer or a function expansion unit connected to the computer, and then a CPU or the like provided on the function expansion board or function expansion unit performs some or all of the actual processing based on the instructions of the program code, thereby realizing the functions of the above-mentioned embodiments.

[0137] Furthermore, the present invention may be applied to a system consisting of multiple devices, or to a device consisting of a single device. It goes without saying that the present invention can also be applied to a case where the present invention is achieved by supplying a program to a system or device. In this case, the system or device can enjoy the effects of the present invention by reading a recording medium containing a program for achieving the present invention into the system or device.

[0138] Furthermore, by downloading and reading a program for achieving the present invention from a server, database, etc. on a network using a communication program, the system or device can enjoy the effects of the present invention. Note that the present invention also includes configurations that combine the above-mentioned embodiments and their modified examples. [Explanation of symbols]

[0139] 100 Document Search System

Claims

1. An information processing device that collects documents from a document management source and manages information related to the documents, an acquisition means for acquiring information relating to the authority data assigned to the document at the document management source and the authority data of a user who executes a search on the collected documents; an authorization means for granting, to the collected documents, authorization data relating to the user who executes the search, which corresponds to the authorization data granted by the document management source, based on the acquired association information; An information processing device comprising:

2. a search means for executing a search on the collected documents; 2. The information processing apparatus according to claim 1, wherein said search means outputs, as a search result, a document to which authorization data relating to the user who executed the search has been assigned.

3. 3. The information processing device according to claim 1, wherein the authorization data assigned to the document at the document management source is data indicating whether a user at the document management source or a group to which the user belongs is permitted to access the document.

4. 4. The information processing apparatus according to claim 3, further comprising a determination unit that determines the association information based on information associated with a user at the document management source and information associated with a user who executes the search.

5. 5. The information processing apparatus according to claim 4, wherein the information associated with the user at the document management source and the information associated with the user who executes the search are email addresses of the respective users.

6. 3. The information processing apparatus according to claim 1, wherein the authorization means sets authorization data relating to a user who executes the search in a record corresponding to the document in a search index.

7. A control method for an information processing device that collects documents from a document management source and manages information related to the documents, comprising: an acquisition step in which acquisition means acquires information relating to association between authority data assigned to a document at the document management source and authority data relating to a user who executes a search on the collected documents; an authorization step in which an authorization means assigns, to the collected documents, authorization data related to the user who executes the search, which corresponds to the authorization data assigned by the document management source, based on the acquired association information; 10. A method for controlling an information processing device, comprising:

8. A program executable on an information processing device that collects documents from a document management source and manages information related to the documents, The information processing device an acquisition means for acquiring information relating to the authority data assigned to the document at the document management source and the authority data of a user who executes a search on the collected documents; an authorization means for granting, to the collected documents, authorization data relating to the user who executes the search, which corresponds to the authorization data granted by the document management source, based on the acquired association information; A program to function as a

Images