JP2011138223A - Search device, search method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To solve the following problem: when recommending and presenting a search attribute by only narrow-down efficiency, relevance between search attributes becomes thin, so that selection becomes difficult. <P>SOLUTION: A search device includes: a first obtaining part obtaining, as a recommendation attribute, a search attribute to be recommended at the next search in order of a search attribute having a large frequency at which the search attribute is selected in the past of search attributes corresponding to the next turn of a search attribute selected for the preceding search, from a first set comprising mutually related search attributes and information indicating order in which the search attribute has to be recommended for the next search; a second obtaining part obtaining, as the recommendation attribute, a search attribute except a search attribute included in a history of a selection attribute that is a search attribute selected in the past, from a second set comprising the mutually related search attributes when unable to obtain the search attribute to be recommended by the first obtaining part; a display part displaying, on a screen, the search attributes including the recommendation attribute obtained by the first or second obtaining part and a candidate list of values; a selection part selecting the value and the search attribute from candidates of the values and the search attributes; and an execution part executing the search by the search attribute and the value. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a search device, a search method, and a program for a user to search for target content from a large amount of content.

  In recent years, as the capacity of storage and recording media has increased, the number of contents handled by devices has increased, and the need for efficient search has increased. In Web search, a search method that requires input of a search query has become widespread, but devices such as copiers often do not have a text input environment. Therefore, there is a need for a search method (hereinafter referred to as “selective search method”) that enables a refined search only by selecting a menu.

  In such a selective search method, simply presenting a menu is not convenient for the user. Therefore, it is necessary to improve the search operability by dynamically recommending a search menu (search attribute and a value corresponding to the search attribute) having a high narrowing effect. However, simply recommending search attributes with a high refining effect does not improve usability. This is because there are various types of search attributes, and it is difficult for the user to select a search attribute that is not closely related to the previous search attribute. Unless the search attribute is recommended in accordance with the story (hereinafter also referred to as “scenario”), the user will be confused. Many systems have been proposed that display search conditions as candidates and allow a user to select and perform a search. For example, in Patent Document 1, the feature amount (protrusion degree, uniformity) of an attribute is calculated according to the content distribution, the system selects an optimal attribute according to the search strategy, and the attribute and attribute value candidates are selected by the user And a method of searching by letting the user select.

JP 2006-202159 A

  However, in the conventional search method, the menu is dynamically displayed depending on the situation, but the relevance between the search attributes is not considered. There was a drawback that it could be embarrassing. For example, Patent Document 1 proposes a method in which the most advantageous attribute in terms of content distribution is recommended by taking a search for restaurants as an example. When the search target area is limited, the types of attributes that can be used are also limited, so there are few situations of random attribute recommendation. However, in general, there are innumerable variations in search attributes, and it is difficult to select if mutually unrelated attributes are recommended. For example, in an office document, there are various types of attributes such as creation status (such as creator), content (such as technical field), format (such as paper size), and usage status (such as a meeting name). If these are recommended at random, there is a problem that it is difficult for the user to select and they are confused.

  In view of the above problems, an object of the present invention is to realize a selective search that recommends and presents search attributes that are related to each other.

In order to achieve the above object, a search device according to the present invention provides:
A search device for performing a search by selecting a search attribute used for search and a value corresponding to the search attribute,
From the first set of search attributes related to each other and information indicating the order in which the search attributes should be recommended in the next search, to the next order of the search attributes selected in the previous search First acquisition means for acquiring search attributes to be recommended in the next search as recommended attributes according to the order in descending order of the number of search attributes selected in the past among the corresponding search attributes;
If a search attribute to be recommended cannot be acquired by the first acquisition means, it is included in the history of selection attributes that are search attributes selected in the past from the second set of search attributes that are related to each other. Second acquisition means for acquiring a search attribute other than the search attribute as the recommended attribute;
Display means for displaying a search attribute including the recommended attribute acquired by the first acquisition means or the second acquisition means and a list of candidate values on the screen;
A selection means for selecting a search attribute and a value from the displayed search attribute and the value candidate;
Execution means for executing a search according to the search attribute and value selected by the selection means;
It is characterized by providing.

  According to the present invention, a scenario is estimated from a user's operation history, and a search attribute with a high narrowing effect is recommended and presented along the scenario. Therefore, a user-selective search can be performed.

The functional block diagram of a search device. The figure which showed the example of transition of the search screen which concerns on a search device. The figure which showed the example of the attribute recommendation which concerns on a search device. The figure which showed the structure of the scenario set which is a set of the scenario piece (2nd set) which concerns on a search device. The figure which showed the structure of the scenario tree (1st group) which concerns on a search device. The figure which showed the structure of the selection attribute log | history table which concerns on a search device. The figure which showed the structure of the document database and attribute table which concern on a search device. (A) The figure which showed the example of the structure of the attribute evaluation table and attribute score calculation in a search device, (b) The flowchart which shows an example of the process sequence of the whole search device. The flowchart which shows an example of the process sequence of a narrowing search process. The flowchart which shows an example of the process sequence of a search attribute recommendation process. The flowchart which shows an example of the process sequence of rejection attribute recording processing and selection attribute history update processing. The flowchart which shows an example of the process sequence of a scenario update process. (A) The flowchart which shows an example of the process sequence of the search attribute recommendation process by distribution, (b) The flowchart which shows an example of the process sequence of an attribute score calculation process.

(First embodiment)
First, referring to FIG. 1, a block diagram showing a main configuration of a search device according to the present invention will be described. In the configuration shown in the figure, the CPU 101 is a microprocessor that performs calculation, logical judgment, etc. for a narrowing search process, a document registration process, a display process, a screen control process, and the like. Control. The BUS 102 is a bus, and transfers an address signal, a control signal, and the like that indicate each component that is a control target of the CPU 101. In addition, data transfer between each component is performed. The ROM 103 is a read-only nonvolatile memory. A boot program by the CPU 101, initial data used in various processes, and the like are stored. The boot program loads initial data into the RAM 104 when the system is started, and causes the CPU 101 to execute the control program. The control program will be described later with reference to a flowchart. The input device 105 is a button, a touch panel, or the like, and an operator gives various instructions. The display device 106 is a liquid crystal display or the like. The RAM 104 is a readable / writable random access memory, and is used for primary storage of various data from each component. Processing such as a buffer that stores data necessary for processing, a buffer that temporarily stores data necessary for display, an attribute evaluation table that calculates and holds attribute scores, or a current scenario ID that is a variable for identifying a currently valid scenario Various data whose values are changed are stored therein. The communication device 107 is a network controller. A device for exchanging data with the outside via a communication line. The HDD 108 is a hard disk and stores a control program executed by the CPU 101. If necessary, it is loaded into the main memory shown in the RAM 104 and executed. The HDD 108 stores the entire scenario consisting of a document database, attribute table, scenario tree (first group described later) and scenario pieces (second group described later) (scenario group) managed by the search apparatus, and a selection. Stores an attribute history table and the like. The scanner 109 is a scanner.

  The search device according to the present invention composed of such components operates in accordance with various events from the input device 105 or the like. When an interrupt from the input device 105 or the like is supplied, a signal is sent to the CPU 101, and an event is generated accordingly. The CPU 101 reads various commands stored in the ROM 103 or the RAM 104 according to the event, and executes various commands by executing the command. Is controlled.

  Next, an example of the transition of the search screen according to the present invention will be described with reference to FIG. The screen is a touch panel, and an action corresponding to each operation can be taken by touching the screen. FIG. 2A shows a screen before a search instruction. The search instruction screen 21 is an example of a screen displayed when a search instruction is issued.

  The area 211 is an area for displaying a search attribute candidate list. The search attribute with the highest recommendation level is displayed on the leftmost side (“operator” in the example). Other search attribute lists (operation date, operation device, etc.) are displayed on the right side. Search attributes that are not displayed on the screen can be displayed by touching the left and right triangular buttons and scrolling left and right. Since there are many search attributes, it is considered difficult for the user to search if the display order changes frequently. Therefore, it is desirable to fix the order of the search attributes other than the leftmost. In the initial state, the search attribute with the highest recommendation level (the leftmost search attribute, “operator” in the example) is automatically displayed as a recommendation, and the corresponding candidate list of search attribute values (in the example, “Kobayashi, Abe , Watanabe, Kudo, Aoki, Ichikawa ”). By searching for a desired search attribute from the search attribute candidate list and selecting it by touching the screen, a candidate list of values corresponding to the selected search attribute can be displayed.

  An area 212 is an area for displaying a list of values. A candidate for a value corresponding to the currently selected search attribute (the leftmost attribute in the initial state: “operator”) is displayed. The values are sorted and displayed in an order according to the type of search attribute. As the sort order, for example, the order of recommendation, the order of AIUE, and the order of numerical values (date, etc.) can be considered. The area 213 is an area for displaying a list of search results. The button 214 is a button for instructing “attribute skip”. “Attribute skip” is an operation performed when the user feels that it is difficult to select the currently recommended search attribute, and is an operation for switching to the next recommended search attribute. For example, if the next recommendation is “operation date”, touching “attribute skip” transitions to the same screen as when “operation date” in the search attribute candidate list in area 211 is touched. When the search attribute candidate in the area 211 is “operator”, touching “Watanabe”, which is one of the value candidates in the area 212, will instruct a search, as shown in FIG. The screen looks like this. Then, the search result is displayed in an area 223 which is an area for displaying a list of search results. In this case, the search attribute: “operator” and the value: “Watanabe” are selected, and a search result corresponding to “operator = Watanabe” is displayed. The search attribute candidates for the next search are displayed in the area 221 in conjunction with the display of the search results. In this case, the recommendation attribute: “operation type” is displayed on the leftmost as the recommendation level is the highest, and a list of value candidates corresponding to “operation type” is displayed in area 222. Furthermore, when one of the values (in the example, “Copy, Print, SEND, Scan, Shoot” in order) is touched, a narrow search is executed, the search result is displayed, and the next recommended search attribute And value candidates are displayed. Similarly, when the “attribute skip” button 224 is touched, the next recommended search attribute at this time is displayed.

  An example of an attribute recommendation operation will be described with reference to FIG. FIG. 3A shows an example of search attribute recommendation that is difficult for the user to select. There is no relationship between the search attributes (operator, meeting place, vertical writing / horizontal writing) recommended in each of the first operation 301, the second operation 302, and the third operation 303. With such a recommendation, the intention of the question based on the search attribute cannot be understood, and the user is expected to be confused when making the selection. FIG. 3B shows an example of search attribute recommendation according to the scenario. The search attributes (operator, operation type, operating device) recommended in the first operation 301, the second operation 302, and the third operation 303 are consistent with each other (operational scenario: situation in which the document is processed by a machine) Description). Since the scenario can be understood, the user can understand what kind of situation is being asked in mind, so that the selection operation can be performed more safely than in the case of FIG. FIG. 3C shows an example of an operation in which the user selects a search attribute that is against the system recommendation. In the first operation 301, the search attribute “creator” is recommended and selected as it is. In the second operation 302, the search attribute “operation department” is recommended, but the user selects the search attribute “operator”. By this operation, the search attribute “created department” is interpreted as a search attribute that is difficult for the user to select. FIG. 3D is an example of search attribute recommendation after the operation of FIG. The “operation” is recommended in the first operation 301 as in FIG. 3C, but the “operator” is recommended in the second operation 302. The search attribute “operator” actually selected in FIG. 3C is recommended instead of “created department”.

  The configuration of the scenario set according to the present invention will be described with reference to FIG. A scenario set is one of the data structures that make up the entire scenario for holding search attributes that are related to each other. The scenario set is used to express a scenario, and a set of scenario pieces that group related search attributes together. It is. Here, the scenario piece is a second set composed of mutually related search attributes. Each scenario piece is identified by a scenario ID. FIG. 4A shows the structure of the scenario set. One scenario piece specified by the scenario ID is composed of several search attributes. In the block 411, the number of search attributes is stored, and the search attributes for the number are subsequently stored. One search attribute includes an attribute ID 412 and a frequency 413. The attribute ID 412 is an identifier for specifying each search attribute. The frequency 413 is the number of times the search attribute is used, and indicates the frequency (number of times) used and selected by the user in the scenario piece status indicated by the scenario ID. Within the same scenario ID, the search attributes are sorted and stored in order of frequency, and are retrieved in order of frequency. FIG. 4B shows an example of a scenario set. The scenario piece 421 indicates that the scenario (operation system scenario) corresponding to the scenario ID = 1 is composed of four mutually related search attributes: operator, operation date, operation device, and operation type. Similarly, a scenario piece 422 shows a content-type scenario, a scenario piece 423 shows a distribution-type scenario, and a scenario piece 424 shows a layout-type scenario.

  The configuration of the scenario tree according to the present invention will be described with reference to FIG. The scenario tree is a first set composed of mutually related search attributes and information indicating the order in which the search attributes should be recommended in the next search. The scenario tree (first set) is one of the data structures constituting the entire scenario for holding search attributes related to each other, and is for expressing the scenario. Unlike the scenario set (second set), the scenario expressed by the scenario tree (first set) is not specified by the scenario ID. The scenario tree describes the order information and frequency information of the search attributes in accordance with the path (search attribute selection history) through which the search attributes have been selected. By correcting this data structure, it is possible to generate a scenario (generation of a new scenario, addition of a search attribute to an existing scenario).

  FIG. 5A shows the structure of each node constituting the scenario tree. The scenario tree is generally an n-ary tree, and one node has a plurality of child nodes, but is converted into a binary tree and implemented. In other words, the child link 514 holds only the link to the eldest node, and the second and following nodes are reached by following the brother link 513 held by the eldest node. The attribute ID 511 stores a search attribute ID that is an identifier for specifying each search attribute. The frequency 512 stores the frequency of use of each node on the scenario tree (the number of times the node has been selected and used by the user in the situation indicated by the node of the scenario tree). Child nodes are sorted according to this frequency. That is, the eldest son node is the highest frequency node among the child nodes, and the next highest frequency frequency is the second son node. The brother link 513 stores a link to the brother node in the scenario tree. The child link 514 stores a link to the eldest son node. The current attribute position 515 is a pointer indicating the node currently being processed on the scenario tree.

FIG. 5B is an example of a scenario tree created in this way. For example, the child nodes of the route 521 are the operator 531, the creator 532, and the paper size 533, and the eldest son node is the operator 531. The child nodes of the operator 531 are the operation date 541, the operating device 542, and the operation type 543, and the eldest son node is the operation date 541. In this example, the current attribute position 515 points to the node “operation type”. This scenario tree enables scenario correction according to the user's operation history, and customization of the scenario suitable for the user is possible.
With reference to FIG. 6, the configuration of a selection attribute history table, which is a table in which the history of search attributes actually selected by the user since the start of the narrow search, is recorded.

  FIG. 6A shows the structure of the selection attribute history table. The attribute number 611 holds the number of stored attributes. The attribute ID 612 stores the attribute ID of each search attribute. The current attribute position 613 holds a pointer to the search attribute currently being processed on the selection attribute history table. FIG. 6B is an example of the selection attribute history table.

  FIG. 6B-1 shows a history of search attributes selected in the previous narrow search operation sequence. FIG. 6B-2 shows the state of the selection attribute history table immediately after the previous series of operations is completed. The previous operation sequence is created in the selection attribute history table. FIG. 6B-3 shows a series of search attributes selected in the current narrow search operation. The first operation and the second operation are the same as the previous operation, but the third operation is changed to “operator”. FIG. 6B-4 shows the state of the selection attribute history table at time T651 of the current operation (immediately after the “operation type” is selected). The contents of the table have not changed from the previous time, and the current attribute position 613 points to “operation type”. FIG. 6B-5 shows the contents of the selection attribute history table at the time T652 of the current operation (immediately after the “operator” is selected). The content of the third operation changes to “operator”, and the current attribute position 613 points to “operator”. It can be seen that the table terminates at the controller and the next search attribute disappears. This reflects that the search attribute to be recommended next has disappeared from the selection attribute history table.

  With reference to FIG. 7, the structure of a document database, which is information for managing documents in the present invention, and a search attribute table, which is a table for recording the characteristics and status of search attributes, will be described.

  FIG. 7A shows an example of the structure of the document database. A document ID 711 is a field of a document ID, and stores identification information for specifying the corresponding document. The search attribute 712 is “operator”, the search attribute 713 is “operation date”, the search attribute 714 is “operator”, and the search attribute 715 is “operation type”, and each document has a document ID 711. The attribute value corresponding to each search attribute is stored. From each recorded content, an area for storing the document content 716 is pointed.

  FIG. 7B is a diagram showing the configuration of a search attribute table for managing search attributes. The attribute ID 721 stores identification information for specifying a search attribute. The attribute notation 722 stores notation contents when each search attribute is displayed on the search menu or the like. The rejection flag 723 holds information about whether or not each search attribute is rejected in a series of narrow search operations. Rejection indicates that the user has selected a search attribute that is not a recommended search attribute. If the recommended search attribute is not selected, the search attribute becomes a rejection attribute. It is cleared to the OFF state by the initialization process for starting the narrow search, but if a rejection operation is performed, the flag of the corresponding search attribute is set to ON.

  With reference to FIG. 8A, a configuration of a score attribute evaluation table, which is a table for calculating a score for measuring the search attribute narrowing effect according to the present invention, will be described. Calculate a score for each search attribute before recommending new search attributes. The attribute evaluation table is composed of several attribute evaluations 801 (in the figure, attribute evaluation 1 to attribute evaluation m; m is a natural number). Each attribute evaluation includes an attribute ID 802, a series of attribute values 803 (attribute value 1 to attribute value n; n is a natural number), and a score 806. An attribute ID 802 indicates information for identifying the search attribute. Each attribute value 803 includes a value 804 and a search hit rate 805. The value 804 that actually appears as the value of the attribute ID 802 in the designated document set is used. The search hit rate 805 stores the ratio of documents satisfying “search attribute = value” in the search target document set. The last score 806 is a search attribute score and is obtained by the following calculation formula.

  Here, hk is the search hit rate 805 of the kth attribute value among the attribute values 803 (attribute value 1, attribute value 2,..., Attribute value k,..., Attribute value n; k, n are natural numbers). S represents the value of the attribute score 806. The search hit rate is a ratio of a combination of an arbitrary search attribute and value that occupies the entire set of combinations of search attributes and values to be searched. In the expression (1), the mean square of the search hit rate 805 for each value in a certain search attribute is a score 806. This is equivalent to variance in terms of statistics. The variance is generally calculated by subtracting the mean square from the mean square, but the mean is considered to be approximately equal, and the mean square is used as an index. A large value of S indicates that the distribution is unevenly distributed. The above operation will be described with reference to the flowchart shown below.

  With reference to FIG. 8B, the flowchart of the operation of the search device according to the present invention, more specifically, the processing procedure of the microprocessor CPU will be described. In step S851, system initialization processing is executed, and processing for initializing various parameters, displaying an initial screen, and the like is executed. In step S852, the CPU 101 waits for any event from the input device such as a touch on the screen to occur. When an event occurs, in step S853, the CPU 101 determines the type of the event, and branches to various processes according to the type of event. A plurality of branch destination processes corresponding to various events are collectively expressed as various event corresponding processes in step S854. The narrowing search process described later in FIG. 9 is one of a plurality of branch destination processes in step S854.

  The other processing is not described in detail, but includes document registration processing, printing processing, document data management processing, and the like. In step S855, the processing result of each of the above processes and the end of the process are notified, and the process of displaying the screen according to the instruction of each process is executed. Normally performed processing such as error display when there is an error and reflection of display data set when normal processing is performed to the screen display are executed.

  With reference to FIG. 9, the narrowing search process which is one of the various event handling processes in step S854 of FIG. 8 will be described. In step S901, variables and tables that need to be initialized are initialized. For example, a current scenario ID that is a variable for identifying a currently valid scenario piece is reset to an invalid value. At this time, all the rejection flags recorded in the attribute table are reset to OFF. In step S902, as will be described in detail with reference to FIG. 10, a search attribute recommendation process for determining a search attribute to be recommended for the next search is performed. In step S903, a candidate list of values corresponding to the currently selected search attribute is created. Depending on the type of search attribute, the values are sorted and listed in order of recommendation, order of value, numerical order, etc. In step S904, a list of search attributes and values is displayed on the screen, and the process waits until the next operation is performed by the user. In step S905, the CPU 101 analyzes the user operation and determines whether a value is selected. If it is not a value selection operation (for example, an operation related to screen transition, an operation related to attribute selection, etc.) (step S905; NO), the process branches to step S906 to perform screen transition processing, and then loops to step S903. Note that the screen transition process in step 906 includes a search attribute skip process. In the case of the search attribute skip process, the same process as the search attribute recommendation process in FIG. 10 is performed, and the search attribute to be recommended next is determined. In step S905, if it is a value selection operation (step S905; YES), the process proceeds to step S907, and a search query is issued according to the selected search attribute and value to execute a search. In step S908, as described in detail in FIG. 11, when the recommended search attribute is rejected by the user, a rejection attribute recording process for recording the rejection is performed. In step S909, as will be described in detail with reference to FIG. 11, a selection attribute history update process for reflecting the current selection operation in the selection attribute history table, which is a table for recording the selection history of search attributes, is performed. In step S910, as will be described in detail with reference to FIG. 12, scenario update processing for reflecting the current search attribute selection in the scenario description is performed. In step S911, the search result of the executed search is output to the screen. In step S912, it is determined whether a series of refined search operations has been completed. If not completed (step S912; NO), the process loops to step S902, and if completed (step S912; YES), Return.

  With reference to FIG. 10, a detailed flowchart of the search attribute recommendation process in step S902 of FIG. 9 will be described. The search attribute recommendation process is a process for determining a search attribute to be recommended for the next search. In step S1001, it is determined whether or not the next search attribute can be acquired from the selection attribute history table. The determination is made based on whether or not the search attribute exists in the history next to the current attribute position. If the search attribute can be acquired, the process branches to step S1002, the next search attribute is acquired, and the process proceeds to step S1009. On the other hand, when the search attribute cannot be acquired, the process proceeds to step S1003. In step S1003, the CPU 101 functioning as the first acquisition unit acquires the next search attribute from the scenario tree. Specifically, from the scenario tree (first set), the search attributes corresponding to the next order of the search attributes selected during the previous search are ordered in descending order of the number (frequency) of search attributes selected in the past. A search attribute that should be recommended in the next search is acquired as a recommended attribute. That is, the search attributes of the child nodes of the current attribute position node on the scenario tree are acquired in order of frequency. The first eldest node is acquired first, and the second and subsequent times are acquired by following the brother link. In step S1004, it is determined whether or not a child node has been acquired. If acquired, the process proceeds to step S1009. When a child node cannot be acquired, the process proceeds to step S1005. In step S1005, it is determined whether a valid value is set for the current scenario ID. If it is invalid (step S1005; NO), the process branches to step S1007. If it is valid (step S1005; YES), the process proceeds to step S1006. In step S1006, it is determined whether there is a search attribute that is not yet selected in the scenario piece indicated by the current scenario ID. As a result, if it does not exist, the process branches to step S1007. On the other hand, if it exists, the process proceeds to step S1008. In step S1008, the CPU 101 functioning as the second acquisition unit acquires unselected search attributes in the scenario piece (second set) indicated by the current scenario ID in order of frequency. The search attribute of the highest frequency is acquired for the first time, and the search attribute of the next frequency is acquired sequentially after the second time. Further, an unselected search attribute in the scenario piece indicated by the current scenario ID may be configured to acquire an arbitrary search attribute instead of the frequency order. As another embodiment of this process, it may be acquired not in the order of frequency but in the order in which the distribution status of search results is taken into account. In that case, an attribute score calculation process shown in FIG. 13B, which will be described later, is called at this stage to obtain a score for each search attribute, and an appropriate weight is added to the frequency information for evaluation. Will get. Thereby, the effect that a search attribute with higher narrowing efficiency can be preferentially presented to the user is obtained. In step S1009, it is determined with reference to the attribute table whether or not the acquired search attribute rejection flag is ON. When the refusal flag is ON, the process loops to step S1003 to obtain a child node of the next frequency other than the search attribute recommended for the first time (other than the refusal attribute), and performs the same processing. When the rejection flag is OFF, the process proceeds to step S1010. In step S1010, as described in detail in FIG. 13B, a search attribute score is calculated. In step S1011, it is determined whether the search results are unevenly distributed from the search attribute scores. Whether or not it is unevenly distributed is determined based on whether or not the score of the search attribute shown in Expression (1) exceeds a predetermined threshold. If not unevenly distributed, the process proceeds to step S1012. On the other hand, if it is determined that it is unevenly distributed, the process loops to step S1003 to acquire the child node of the next frequency and perform the same processing. In step S1012, the acquired search attribute is determined as a recommended attribute, and the process returns. If the current scenario ID is valid in step S1005, and if there is no unselected attribute in the current scenario in step S1006, the process branches to step S1007. Then, search attribute recommendation processing based on distribution, which will be described in detail with reference to FIG. In this way, by checking the uneven distribution of search results and recommending different search attributes when there is an uneven distribution, the user can reduce the trouble of performing a useless narrow search operation, leading to improved search operability. There is an effect. Further, by checking the rejection attribute and controlling so that the rejection attribute is not recommended, it is possible to eliminate search attributes that are difficult for the user to select, so that there is an effect of improving search operability.

  With reference to FIG. 11, a detailed flowchart of the rejection attribute recording process in step S908 and the selection attribute history update process in step S909 of FIG. 9 will be described.

  FIG. 11A shows rejection attribute recording processing. When the user disregards the recommended attribute of the system and selects another search attribute, the fact that the recommended attribute is regarded as rejected is recorded. In step S1101, it is determined whether or not the currently selected search attribute is a system recommended attribute. If the recommended attribute is selected (step S1101; YES), the process directly returns. On the other hand, if a search attribute other than the recommended search attribute is selected (step S1101; NO), the process proceeds to step S1102, the rejection flag in the attribute table corresponding to the recommended attribute is set to ON, and the process returns. .

  FIG. 11B is a selection attribute history update process, which is a process of reflecting the result of the current search attribute selection operation in the selection attribute history table, which is a table that records the history of selection of search attributes. In step S1151, it is determined whether or not the search attribute selected by the user this time matches the next search attribute (search attribute at the position of the current attribute position + 1) in the selection attribute history table. If they match, the process proceeds to step S1152, and if they do not match, the process proceeds to step S1153. In step S1152, the current attribute position in the selected attribute history table is advanced to the next attribute position (ie, incremented by 1), and the process returns. On the other hand, in step S1153, the currently selected search attribute is added to the next attribute position in the selected attribute history table (that is, the position of the current attribute position + 1). In step S1154, the current attribute position is incremented to the next attribute position (ie, incremented by one). In step S1155, the search attribute on the right side (+ side) from the current attribute position is deleted from the selection attribute history table, and the process returns.

  With reference to FIG. 12, a detailed flowchart of the scenario update process in step S910 of FIG. 9 will be described. The scenario update process is a process for changing to a suitable scenario when the selected search attribute is out of the scenario, and a process for reflecting the current search attribute selection in the scenario description. In step S1201, it is determined whether or not the current scenario ID is valid. If it is valid, the process skips to step S1205, and if it is not valid, a suitable scenario piece is searched for in step S1202. Specifically, for example, the scenario set is searched for whether there is a scenario piece including a search attribute group described up to the current attribute position in the selection attribute history table as a subset. Moreover, the structure which searches the scenario piece containing only the search attribute of the present attribute position may be sufficient. In step S1203, it is determined whether a scenario piece has been found. If not found, the process branches to step S1208. On the other hand, if it is found, the process proceeds to step S1204, and the CPU 101 functioning as the second updating means for updating the second set sets the scenario ID of the found scenario piece as the current scenario ID, and proceeds to step S1205. Of the second set, information on a set that is currently used as a target for acquiring a search attribute is held in a storage device such as the RAM 104 that functions as a current scenario holding unit. In step S1205, it is determined whether or not the search attribute selected this time exists in the scenario piece indicated by the current scenario ID. If it exists, the process proceeds to step S1206, and if it does not exist, the process branches to step S1208. In step S1206, the frequency of the selected attribute in the current scenario is counted up. In step S1207, the search attributes in the scenario pieces indicated by the current scenario ID are sorted in order of frequency, and the process advances to step S1209. On the other hand, if the scenario piece is not found in step S1203, and if the selection attribute does not exist in the current scenario in step S1205, the process branches to step S1208, the current scenario ID is cleared and invalidated, and the process proceeds to step S1209. In step S1209, it is determined whether the selected attribute is already registered as a child node at the current attribute position on the scenario tree. If it has been registered, the process proceeds to step S1210. If it has not been registered, the process proceeds to step S1212. In step S1210, the CPU 101 functioning as a first updating unit that updates the order of the first set counts up the frequency of the selected attribute on the scenario tree. In step S1211, the child nodes are sorted according to the frequency, and the child link and the brother link are reset. Thereafter, the process proceeds to step S1213. On the other hand, in step S1212, the CPU 101 functioning as the first updating means for updating the order of the first set is defined in the first set with the selected attribute node as a child node of the current attribute position on the scenario tree. Add to the end of the sequence with initial frequency. And after adding, it progresses to step S1213. In step S1213, the current attribute position on the scenario tree is advanced to the position of the selected attribute. In step S1214, if there is an unnecessary node on the scenario tree, it is deleted and garbage collected. As a criterion for certifying that the node is unnecessary, it is conceivable that each node has life information, and a node whose lifetime has been exhausted is unnecessary.

  The first effect of performing the scenario update processing in this way is that, when the user selects an attribute that deviates from the scenario piece, another scenario piece suitable for the user operation is set. The second effect is that when there is no matching scenario piece, a new node is added to the scenario tree, and a new scenario with a search attribute added is generated. A third effect is that when the recommended order of search attributes described in an existing scenario is different from the user's desire, a scenario whose order is corrected is obtained.

  As described above, since it is easy to construct a scenario suitable for the user operation by only the selection operation, there is an effect of improving the search operability.

  With reference to FIG. 13A, a detailed flowchart of the search attribute recommendation processing based on the distribution in step S1007 in FIG. 10 will be described. In step S1301, initial setting processing is performed to identify a target document set for narrowing search. In step S1302, search attribute candidates are extracted from the attribute table. In step S1303, one search attribute is acquired from the extracted search attribute candidates. In step S1304, the score of the search attribute is calculated as will be described later with reference to FIG. In step S1305, it is determined whether or not the processing has been completed for all search attribute candidates. If the processing has not been completed, the process branches to step S1306, the next search attribute is acquired, and the process loops to step S1303. If it is determined in step S1305 that all search attribute candidates have been processed, the process advances to step S1307 to sort the search attributes in order of score. In step S1308, the search attribute that should be given the highest priority is extracted as a recommended attribute, and the process returns.

  With reference to FIG. 13B, a detailed flowchart of the attribute score calculation processing in step S1010 in FIG. 10 and step S1304 in FIG. 13 will be described. In step S1351, necessary variables are initialized. In step S1352, those appearing as specified attribute values in the specified document set are listed as attribute value candidates. In step S1353, one attribute value is arbitrarily extracted from the attribute value candidates. In step S 1354, the number of cases where “search attribute = attribute value” in the designated document set is obtained, and the search hit rate is calculated. In step S1355, the calculated attribute value and hit rate are set in appropriate fields in the attribute evaluation table. In step S 1356, it is confirmed whether or not all attribute value candidates have been processed. If there is an unprocessed value, the next attribute value is selected in step S1357, and the process loops to step S1353. On the other hand, if all the values have been processed in step S1356, the process proceeds to step S1358. In step S1358, the search attribute score is calculated based on the calculation formula shown in the formula (1), stored in the attribute evaluation table, and the process returns.

(Second Embodiment)
Note that the present invention is not limited to the above-described embodiment, and can be appropriately changed without departing from the gist of the present invention.

  In the embodiments described so far, there is no operation for clearly specifying a scenario desired by the user at the start of the search operation. However, a configuration may be adopted in which the user clearly specifies the scenario. For example, an operation of displaying a menu for selecting a scenario piece such as “content-related scenario”, “operation-related scenario”, “layout-related scenario” at the start of the search operation, and allowing the user to select it can be considered. Even in such a configuration, the subsequent processing relating to the scenario selection is exactly the same as the processing shown in the first embodiment. For example, if the user selects a search attribute that deviates from the scenario piece in the middle of the search operation, the scenario piece that matches is automatically searched and the scenario setting is changed. With this configuration, even if the user selects an inappropriate scenario piece, it is automatically corrected to an appropriate scenario while performing a refined search, improving search operability. An effect is obtained.

  Further, in the embodiments described so far, the description has been made on the assumption that there is one current scenario ID, but there may be a case where a plurality of scenarios are applicable. For example, two scenarios include a common search attribute, and the attribute selection operation from the start of the search happens to select only the common search attribute. At this time, a plurality of scenario pieces are found in the process of finding the scenario piece in step S1203 of FIG. For such a case, a plurality of current scenario IDs can be stored and processed. In that case, a plurality of current scenario IDs are stored in step S1203. Further, in step S1008 in FIG. 10, all unselected search attributes are extracted from a plurality of corresponding scenario pieces, and similarly, a search attribute with a high evaluation value is acquired from frequency, distribution information, and the like. Further, in the current scenario check process in step S1005, step S1006 in FIG. 10 and step S1205 in FIG. 12, a plurality of scenario IDs are checked. Then, the clear process in step S1208 in FIG. 12 is to clear only the scenario IDs whose selection attributes have been removed. By having a plurality of current scenario IDs in this way, it is possible to perform processing in consideration of the case where there are a plurality of scenario pieces with duplicate search attributes, and the scenario pieces can be used effectively.

  In the first embodiment, when a search attribute that is out of the scenario piece is selected, the scenario change is performed by searching for a scenario piece including the search attribute included in the selection attribute history so far as a subset, and the scenario piece. The configuration was changed to However, because the conditions are strict, it is assumed that the corresponding new scenario piece cannot be found. In order to avoid such a situation, instead of using a complete match with a subset as a condition, a configuration that allows a partial mismatch and changes to a scenario piece with the highest degree of overlap with the selection attribute history. It is also good. By doing so, the usage rate of the existing scenario piece is increased, the usage rate of the recommended search attribute is also increased, and the search operability is improved.

  In the first embodiment, only one search attribute with the highest recommendation is effective as the recommended search attribute, and search attributes below the next point are handled in the same row. However, a list of search attributes is presented in order of recommendation. It is also possible to adopt a configuration to In this case, it is difficult to determine where the desired search attribute exists in the list, so a function for sorting the search attribute list is also required. At this time, in the “search result unevenness check” in step S1011 of the search attribute recommendation process of FIG. 10, when the search is unevenly distributed, the recommendation level is evaluated by dropping by a predetermined value, and the recommended attribute is determined. Thus, by displaying the search attributes below the next recommendation level in a list in the order of recommendation level, there is an effect that it becomes easy to use the search attributes below the next recommendation level.

  In the first embodiment, the scenario generation has been described only for the configuration of adding a new node to the scenario tree (first set). However, the process of adding a search attribute to the scenario piece of the scenario set (second set) is described. May be performed. In this case, it is difficult to specify the scenario ID to which the search attribute is to be added, but the scenario ID of the scenario piece that best matches the selected attribute history and the constituent element is found. As a result, scenario generation can be realized with a minimum configuration, and an inexpensive apparatus can be realized.

  In the first embodiment, the search target is described as a document. However, if the content is a type other than a so-called normal document, for example, a content to which metadata such as a photo and a video can be added, the same applies. It can be processed. In addition to the above, the configuration can be changed as appropriate without departing from the spirit of the present invention.

(Other embodiments)
The present invention can also be realized by executing the following processing. That is, software (program) that realizes the functions of the above-described embodiments is supplied to a system or apparatus via a network or various storage media, and a computer (or CPU, MPU, or the like) of the system or apparatus reads the program. It is a process to be executed.

Claims (9)

A search device for performing a search by selecting a search attribute used for search and a value corresponding to the search attribute,
Retrieve search attributes other than search attributes included in the history of selected attributes that were selected in the past as recommended attributes that should be recommended for the next search from scenarios that store mutually related search attributes Acquisition means;
Display means for displaying on the screen a search attribute including the recommended attribute acquired by the acquisition means, and a list of candidate values;
A selection means for selecting a search attribute and a value from the displayed search attribute and the value candidate;
Execution means for executing a search according to the search attribute and value selected by the selection means;
A search device comprising: A search device for performing a search by selecting a search attribute used for search and a value corresponding to the search attribute,
The acquisition means comprises a first acquisition means and a second acquisition means,
From the first set of search attributes related to each other and information indicating the order in which the search attributes should be recommended in the next search, to the next order of the search attributes selected in the previous search A first acquisition means for acquiring, as a recommended attribute, a search attribute to be recommended in the next search among the corresponding search attributes;
If a search attribute to be recommended cannot be acquired by the first acquisition means, it is included in the history of selection attributes that are search attributes selected in the past from the second set of search attributes that are related to each other. Second acquisition means for acquiring a search attribute other than the search attribute as the recommended attribute;
Display means for displaying a search attribute including the recommended attribute acquired by the first acquisition means or the second acquisition means and a list of candidate values on the screen;
A selection means for selecting a search attribute and a value from the displayed search attribute and the value candidate;
Execution means for executing a search according to the search attribute and value selected by the selection means;
The search device according to claim 1, further comprising: A recording means for recording the recommended attribute as a rejected rejection attribute if the recommended attribute is not selected by the selection means;
Determining means for determining whether the recommended attribute acquired by the acquiring means is the rejection attribute;
2. The method according to claim 1, wherein when the determination unit determines that the attribute is a rejection attribute, the acquisition unit acquires a search attribute other than the rejection attribute as a recommended attribute to be recommended in the next search. 2. The search device according to 2. It further comprises scenario update means for updating the contents of the scenario,
The scenario update means includes
When a selection attribute that is a search attribute selected by the selection means is a search attribute that is not recommended, the selection attribute is added to the scenario as a search attribute candidate to be recommended in the next search. The search device according to any one of claims 1 to 3, wherein Current scenario holding means for holding a set that is currently used as a target for acquiring a search attribute from the second set,
The current scenario holding means is selected by the selection means when the selection attribute which is the search attribute selected by the selection means is not included in the second set used as a target for acquiring the current search attribute. The second set including the searched search attribute is searched for, held as a set that is newly used for the current search, and the search attribute is acquired by the second acquisition unit. 5. The search device according to any one of 2 to 4. A calculation means for calculating a search attribute score, which is an index of a search attribute narrowing effect and indicates a bias in the distribution of the values;
The said acquisition means acquires search attributes other than the already acquired search attribute as a recommendation attribute when the said search attribute score is larger than a threshold value, The any one of Claim 1 thru | or 5 characterized by the above-mentioned. Search device.   The said search attribute score is a root mean square of the ratio of the combination of the arbitrary search attribute and value which occupies for the whole set of the combination of the search attribute and value used as search object, It is characterized by the above-mentioned. Search device A search method for narrowing a search by selecting a search attribute used for search and a value corresponding to the search attribute,
The search selected at the time of the previous search from the first set, in which the first acquisition means is composed of mutually related search attributes and information indicating the order in which the search attributes should be recommended in the next search A first acquisition step of acquiring search attributes to be recommended in the next search as recommended attributes according to the order in descending order of the number of search attributes selected in the past among search attributes corresponding to the next order of attributes; ,
When the second acquisition means fails to acquire a search attribute to be recommended in the first acquisition step, it is a search attribute selected in the past from the second set composed of the mutually related search attributes. A second acquisition step of acquiring search attributes other than the search attributes included in the history of selection attributes as the recommended attributes;
A display step of displaying a search attribute including the recommended attribute acquired in the first acquisition step or the second acquisition step and a list of candidate values on the screen;
A selection step of selecting a search attribute and a value from the displayed search attribute and the value candidate;
An execution step of executing a search based on the search attribute and value selected in the selection step;
A search method comprising:   A program for causing a computer to execute the search method according to claim 8.

Images