WO2004086251A1

WO2004086251A1 - Search system and method for determining information from a databank, especially the worldwide web

Info

Publication number: WO2004086251A1
Application number: PCT/EP2004/002915
Authority: WO
Inventors: Frank Meltke
Original assignee: Frank Meltke
Priority date: 2003-03-25
Filing date: 2004-03-19
Publication date: 2004-10-07
Also published as: EP1642211A1; DE10313420A1; KR20060017489A

Abstract

The aim of the invention is to create a search system and a method for determining information from a databank, especially the worldwide web, which are particularly suitable for obtaining a constantly high search quality. Said aim is achieved by jointly and/or simultaneously using a plurality of search engines (2), an integration module (6) converting the result data that is supplied by the search engines (2) and comprises a plurality of sets of result data (E) into a common data format while a relevant parameter is assigned to each set of result data (E) in said integration module (6) by reverting to prioritizing parameters (P) stored in a memory module (14).

Description

description

Research system and method for determining information from a

5 Database, in particular from the World Wide Web

6

The invention relates to a search system for determining β information from a database using a plurality of

9 search engines. It also relates to a method for determining information

10 from a database, in particular from the World Wide Web, using

11 of such a research system.

12

13 An enormous amount of information is available in complex databases or in the global computer network u ("World Wide Web"),

15 which a user can access more or less specifically for research purposes.

16 In order to target information from the large amount of information

In order to be able to make use of it, so-called search engines are used, especially when it comes to obtaining information from the World Wide Web

19 have experienced considerable distribution. In such search engines, the 0 user is usually provided with an inquiry window via an input / output module, via which specific search or research terms can be specified. The search engine then searches the information base 3 of the database or the World Wide Web for suitable key words or key words. The response data records found thereupon are usually 5 categorized by the respective search engine with regard to their relevance for the specified search order and made available to the user in the manner of a hit list in 7 order arranged according to their relevance. 8 9 In the meantime, a large number of such search engines have been established that 0 can differ from each other in terms of their performance, reliability and / or the 1 information base taken into account in the manner of a thematic specialization 2. Precisely because of the large number of 1 information offered during operation, for example on the World Wide Web

₂ such a search engine a certain focus or

₃ Specialization of individual search engines may be necessary, the quality

4 of the search results vary depending on the given search query for individual s search engines within certain ranges.

6

7 The invention is therefore based on the object of a research system for the β determination of information from a database, in particular from the world

9 Wide-Web, to be specified, which is particularly suitable for achieving a consistently high search quality, 0 particularly suitable for the common and / or 1 simultaneous use of a plurality of search engines 2. Furthermore, a method for determining information from a 3 database, in particular from the World Wide Web, is to be specified using a 4 such research system. With regard to the research system, this object is achieved according to the invention with an integration module which converts the result data supplied by the search engines, each comprising a plurality of result data records, into a common data format and then assigns a relevance characteristic value to each result data record using a prioritization parameter stored in the memory module.

The invention is based on the consideration that, in order to achieve consistently high research qualities, a plurality of alternative search engines should in principle be used, so that quality defects dependent on search questions can be compensated for alternately. However, especially when using a plurality of search engines for a search query, it can be expected that a large number of search hits or result data sets will be generated by the whole of the search engines. For a user-friendly and targeted evaluation of these results, a relevance identifier common to all results should be assigned, so that for the user 1 understandably a systematic order of all

2 Search results can be carried out according to predefined relevance criteria.

3 In particular, it should be possible to use the

4 relevant! present the considered results first, so that the user can concentrate on the essential research results. In order to make this possible, the conversion of the incoming data records into a common data format is initially provided, so that a common data evaluation and structuring is made possible. Then the

9 Structure of the found result data records in the sense of a common

10 relevance structure provided. This function of merging and conso-

11 Validation of result data records from different sources is supported by the

12 Integration module fulfilled.

13

14 The hierarchical categorization of the found result data sets by assigning a specific relevance characteristic can be done by the user

16 or prioritization criteria given to an operator. In particular

17 it could be provided that certain search engines are generally and standardizedly assigned a higher relevance when evaluating the results delivered.

19 NEN, for example because it is known for a certain type of search query

20 is that certain search engines tend to be comparatively high

21 Deliver search quality. To make this possible, the 2 prioritization parameters are advantageously selected as a function of the respective 3 search engine, so that, for example, the prioritization characteristic value stored for a specific 4 search engine can be used to determine 5 that a result data record supplied by this search engine is provided with a 6 comparatively high relevance characteristic value , 7 8 The user can specify the type and scope of a specific prioritization when considering the 9 search engines. 0 Within the result data records delivered by a search engine, the so-called 1 internal prioritization can then take place on the basis of the prioritization already delivered by the 2 search engine. This will be discussed in more or an alternative advantageous embodiment of the relevance characteristic for the respective result data record, taking into account an output relevance characteristic provided by the respective search engine, determined by the integration module.

In this case, in particular in the manner of a “dynamic prioritization”, a normalization of output relevance parameters already supplied by the respective search engines can be provided, in which the result data record considered most relevant by the respective search engine is provided with a provisional relevance parameter of, for example, 100%, the of The respective search engine already has other results data sets that are classified as comparatively less relevant, with a correspondingly graduated relevance characteristic value be that a search engine already during normalization, i.e. when forming the reference variable for the result data record considered most relevant by the respective search engine A specific characteristic value is also specified, by means of which the relevance characteristic value of the result data record considered most relevant by the respective search engine is specified in a search engine-specific manner. Such a search engine-specific specification makes relative weightings between individual search engines possible, in which, in particular, empirical values about the general reliability of the respective search engine and / or also subject-related or search query-dependent findings about the respective search engine can also be incorporated.

The integration module is designed for the joint evaluation of the result data sets supplied by the different search engines, with first converting the individual result data sets into a common and thus jointly evaluable data format. For this purpose, the integration module is designed for the specific, from the Evaluate the respective search engine used syntax or its data format

2 and convert if necessary. To make this possible

3 integration module advantageously with a second memory module

4 connected in which syntax data for the individual search engines are stored.

₅ Using this syntax data, the search engine-specific β data conversion can then be carried out.

7

8 In a further advantageous embodiment, in addition to the integration module

9 a distribution module is provided, which has a common data format

10 incoming search order suitable for the individual intended for use

11 search engines split. This is the distribution module, which is convenient

12 via a common buffer memory module with the integration module

13 communicates, advantageously designed for the respective search order

14 suitable for converting into a syntax that can be processed for the respective search engine or an appropriate data format.

16

17 In order to enable a reliable assignment of the delivered results to the respective search order even if a

19 equally large number of search orders has to be processed, which in particular

20 re with different response times of the search engine to different

21 waiting times for the results and thus overlap in time between different

22 different search requests could be the integration module and the

23 distribution module advantageously assigned a common buffer memory module. The buffer memory module expediently contains

25 order characteristic identification data, for example an identification

26 ID number, deposited, whereby the individual specified search orders directly output to the search engines are provided with a corresponding ID number. In the answers provided by the search engines, the 9 integration module then makes it possible to unambiguously assign the result 1 data records to the respective search request in the 9 integration module by using the 0 characteristic data stored in the buffer memory, so that a consolidated and 2 consistent evaluation of the incoming results is possible. The distribution module is advantageously specifically designed for the incoming search order on the data side into one for the respective search engines

4 convertible data format or syntax to convert. For this purpose, the distribution module is also advantageously connected to the second memory module, in which syntax data for the search engines are stored. Through targeted

7 Maintenance and care of the second memory module is thus made possible in a special way, possibly updates by the search engines

9 used syntax or the addition or deletion of complete 0 search engines in a particularly simple manner. 1 2 In a further advantageous embodiment, the distribution module 3 is connected on the input side 3 via a filter module to an input / output module, via which individual search requests can be specified by the 4 user. The filter module 5 can in particular be designed to completely suppress certain search queries on the basis of adjustable or individually specifiable 6 filter criteria or, for example, to add country-specific or customer-specific individual specifications. In particular, it can also be provided to specifically use the type of request to specify individual search engines that are identified as particularly suitable for the subsequent processing of the search order. The filter module can thus in particular also be designed to make a preliminary or rough selection of the search engines to be used depending on the respective search query or their thematic focus and thus to specify a rough strategy for the subsequent strategy.

In principle, the distribution module and the integration module can be designed as independent units, for example on a software or hardware basis. A particularly compact and therefore inexpensive construction can be achieved by advantageously integrating the distribution module with the integration module into a common unit. 1 It is widespread practice, especially when doing research in the

2 Internet or World-Wide-Web that the user shares with those on his

3 search results for hit lists generated advertisements, so-called

4 "banners" appear with. In response to a search query

5 from an advertising material database, also referred to as an “ad server”, together with the results, randomly selected from the banners stored there

7 data records are also transmitted, which are then displayed on the input / output module. With such a system, the addition is made

9 of the individual banners, however, usually unspecified and in particular 0 without reference to the topic specified by the user through the search query, 1 so that the user interest in the respective advertising medium is only comparatively low 2. In a particularly advantageous development of the above-mentioned system 3, however, the distribution and integration modules are now connected on the data side to 4 an advertising material database which, as a response data record to an incoming search query, supplies a data record which has been adapted to the search query with regard to an identification signal. In other words: Due to the already provided, comparatively qualified evaluation of the given search query, which is made possible by the corresponding conversion in the distribution module, it is now possible to generate, for example, a content-related or subject-related identifier for the search query, which is forwarded to the query when the search query is forwarded Advertising media database enables a targeted selection of advertising data records that are particularly suitable with regard to the identification signal, that is to say, for example, with regard to the topic being processed. Through such a targeted assignment of the advertising material data sets provided as a response signal, it is thus possible to achieve a significantly higher level of user awareness of the advertising materials used.

With regard to the method, the above-mentioned object is achieved by using the above-mentioned search system by converting the result data supplied by the search engines, each of which comprises a plurality of result data sets, into a common data format, whereby 1 then using a memory module

2 prioritization parameters each result data set a relevance value

3 is assigned. The integration module thus provides for

4 delivered result data sets to generate a consolidated and consistent s relevance system in which the individual result data sets are suitably positioned relative to one another with regard to predefined relevance criteria.

8th

9 The prioritization parameters are advantageously selected as a function of the respective search engine, the relevance parameter being determined in an alternative 1 or additional advantageous development for the respective result data record 2, taking into account an output relevance parameter 3 provided by the respective search engine. 4 s A search request received in the common data format is advantageously converted for each selected search engine into its specific data format and then output to it. In an alternative or additional advantageous embodiment, a search request specified via an input / output module is subjected to filtering before it is processed further.

In addition to the search engines, a search request is advantageously output to an advertising material database, an answer data record coming from the latter being assigned to the respective search query by means of an identification signal. The identification signal makes it possible, in particular, to adapt the response data record to the respective search query with regard to predefinable criteria, for example with regard to the content or topics used, so that the user is offered a suitable advertising medium together with his search results. 1 The advantages achieved by the invention are in particular that

₂ the use of the integration module that incoming result records

3 converted to a common data format and then a relative one

4 Weighting and prioritization of the result data sets among themselves

5 Allocation of a "global" relevance characteristic enables consistent, shared use by a number of search engines

7 distribution module communicating with the integration module, it is also guaranteed that, using the data stored in the memory module,

9 search engine-specific data such as, for example, syntax data, a targeted addressing of different types of search engines with a common 1 search query is made possible, whereby a consolidated common evaluation of the results 3 provided by the addressed search engines 3 is also possible, taking into account their specific syntax.

An embodiment of the invention is explained in more detail with reference to a drawing. In it show:

Fig. 1 shows schematically a search system for determining

Information from a database,

2 shows a conceptual illustration of the search system according to FIG. 1,

3 shows a schematic list of the processes running in the search system according to FIG. 1,

4 shows an alternative representation for the overall system according to FIG. 1,

5 schematically shows the structure of the administration of the search system according to FIG. 1,

6 shows a diagram for a request to a plurality of search engines, 7 shows a diagram for a distributed query and merging of the results,

8 shows a diagram for different search modes in the search system according to FIG. 1,

9 shows a scheme for filtering search queries,

10 shows a schematic representation of the modules used in the search system according to FIG. 1,

11 schematically shows the structure of a filter / interpreter module,

12 schematically shows a structure of an integration module,

13 schematically shows the structure of a server engine module,

14 schematically shows a dynamic model for a search process,

15 shows a flow chart for an initialization of a server engine,

16 is a flowchart for processing a search request,

Fig. 17 is a flowchart for the preparation of adapters for a search request, and

18 shows a diagram for an admin application of the search system according to FIG. 1.

The research system 1 according to FIG. 1 is used to determine information from a complex database, in particular from the Internet, the World Wide Web or another index, designed with particularly high search quality. For this purpose, the search system 1 is connected on the data side to a plurality of search engines 2, as are currently widely used for targeted searches of the Internet.

In order to enable the simultaneous and joint use of a plurality of search engines 2, the search system 1 comprises, in a central evaluation unit 4, an integration module 6 to which the hit lists or result data supplied by the search engines 2 can be supplied in the form of result data records E. The integration module 6 ensures that a common, consistently prioritized evaluation of the result data records E provided by the different search engines 2 is made possible.

For this purpose, the integration module 6 is designed to first convert the incoming result data records E into a common data format, so that a consolidated evaluation is possible. In order to enable the user to specifically evaluate the possibly large amount of information, the consolidated prioritization and relevance identification of the individual result data records E is provided, whereby according to predefined relevance criteria, all result data records E are assigned comparable relevance characteristic values. To make this possible, the integration module 6 is connected to a memory module 8 in which prioritization parameters P relevant for the assignment of the relevance parameters are stored.

In the prioritization, it can in particular be provided that the search engines 2 selected according to the specifications by a user or by an operator are fundamentally provided with a comparatively high prioritization and thus a comparatively high relevance value. In this case, the prioritization parameters are selected as a function of the respective search engine 2. Alternatively or additionally, the result data records E supplied by a search engine 2 can be provided in terms of their normalization in the manner of a normalization 1 first of all to standardize the relevance parameter on the result data record E,

2 the one with the highest search engine 2

3 relevance parameter was provided. In the manner of a percentage

4, this could thus mean that the _s value is provided of 100% of the respective engine 2 as at the relevantesten s recognized result data set E with a preliminary Relevanzkenn-, the other result records E of this

7 Search engine 2, according to its β output relevance characteristic value assigned by the search engine 2, a correspondingly graduated relevance characteristic value

9 received. If this is carried out equally for all search engines 2, a relative prioritization of the result data records E 1 of different search engines 2 takes place essentially on the basis of their relative 2 relevance with regard to the result data record E 4 most relevant by the respective search engine 2. 4 5 In addition 6, however, a search engine-specific characteristic value can also be stored in the prioritization parameters P, which parameter generally or as a function of the respective search query assigns an s reliability characteristic value to the respective search engine 2.

The evaluation unit 4 further comprises a distribution module 10, which communicates with the integration module 6 via a buffer memory 12. The distribution module 10 is also connected to a second memory module 14, in which data records characteristic of the search engines 2, in particular characteristic of their data format or syntax, are stored. On the input side, the distribution module 10 is connected via a filter module 16 to an input / output module 18, which in turn is connected to the integration module 6 on the input side. The input / output module 18 can in particular be designed as a conventional operating unit, comprising a keyboard and an output means such as a screen.

When a search query specified by the user via the input / output module 18 is processed, this query is first filtered in the 1 filter module 16. For example, the elimination of search queries

2 of a certain criterion can be provided, or for example

3 country or region-specific requirements for processing the search query

4 are taken into account. Furthermore, a pre-selection takes place in the filter module 16

5 of the search engines 2 recognized as suitable for the respective search queries, so that the filter module 16 already acts in the manner of a rough strategy with the

7 Search query to be entrusted to search engines 2.

8 g The search query 2 filtered in this way is then fed to the 0 distribution module 10, which, using the search engine-specific information stored in the second 1 storage module and 2 in particular syntax parameters, converts the respective search query into a multitude of 3 individualized search queries in the data formats suitable for the selected search engines 2 4 implements. The distribution module 10 s then forwards the individualized search inquiries to the selected search engines 2, 6, a profile of the search query being stored in the buffer memory 12 in the manner of logging and to simplify administration, together with an identifier identifying it.

The search engines 2 started by supplying the individualized search query then complete their search program on the World Wide Web and provide their response signals, for example in the form of hit lists, in which the result data found are listed as result data records E according to the relevance recognized by the respective search engine 2 are. Based on the characteristic identification data for the respective search query, the result data records E are then reassigned to the respective search query in the integration module 6, so that a targeted evaluation is made possible even in the case of time-overlapping searches.

The integration module 6 also converts the result data records E into the common data format, possibly also using the syntax information stored in the second memory module 14. 1 Then takes place using the ones stored in the memory module 8

₂ prioritization parameters P the generation of a relevance parameter for each

3 result data set E, the relevance parameters generated in this way

4 should serve to create a consolidated and consistent result hierarchy s between the result data records E. As a result, a homogenized result or hit list is generated for the user, in which the as

7 most relevant recognized result data records E are listed first. The assignment a of the relevant relevance parameter using the prioritization parameters

9 P can take place in particular with regard to the respective search engine 2,

10 which has delivered the relevant result data record E. Alternatively or additionally

When assigning the relevance parameter, 11 can also be one of the respective

12 Search engine 2 provided output relevance parameter taken into account

13 will be.

In addition to the search engines 2, the research system 1 is connected on the data side to an advertising material database 20. In the advertising media database, too

1 referred to as “ad server”, advertising elements are stored in the form of so-called “banners”, which are processed by the advertising material database 20 in response to

19 an incoming search query is returned to the research system 1

To be 20. The search system 1 is designed such that the

21 advertising material database 20 selected and specified advertising elements as

22 Returns the response record to an incoming search request, the

23 Selection and specification adapted to the content or topic

24 respective search queries occurred. The selection of the returned advertising elements

25 takes place in such a way that the respective advertising element or

26 thematically related to the search query, so that with a

27 comparatively increased interest of the user in the respective

∑β advertising element can be expected. For this purpose, the

29 Research system 1 together with a search query

30 identifier signal to the advertising material database 20, based on the

31 supplied identification signal the selection for the

32 response data record suitable advertising elements. Fig. 2 illustrates the components and actuators involved in relation to the (sub) system limits.

role Description

Customer "Customer" is any user who can start a search.

TSC Filtermanager The role of "TSC Filtermanager" describes the group of employees in whose area of responsibility the filter definitions are located. This group of employees also evaluates the statistical logging of the research system.

TSC Admin The role of the "Admin" describes the group of employees who are responsible for the operation of the research system. They administer the configuration file (tsc.cfg) of the research system and monitor the error logs (tsc_error.log).

Description of the external systems

Contents Brief description Here, search results are provided that point to private and business homepages. Interface The interface is analogous to the WWW search with Fast. P4P server

Summary

The search results of the Pay4Performance (P4P) server are provided here.

interface

The interface of the GoTo search center is included via HTTP request (included

Parameters) addressed. The results are delivered in XML format.

FAST search center

Brief description Internet-wide search results are provided here, which were found using the "AIITheWeb" search engine.

Interface The interface of the FAST search center is addressed via HTTP request (including parameters). The results are delivered in XML format.

Ad Server

Brief description According to the search query, the ad server delivers an advertising component that is incorporated into the overall presentation of the search results.

Research system processes

In Fig. 3, the processes of the search system are shown in an overview and the process run in the "good" case is described.

TSC configuration The configuration of the search system is controlled via parameters that are stored in a separate file. This configuration file is in XML format stored in the file system of the search center. It can be edited using a standard editor.

The changed configuration can only be achieved with the restart of the "TSC search" processes.

The process "TSC configuration" describes the necessary steps for the administration of the configuration file of the research system.

Role activities

1. Edit the configuration (tsc.cfg)

E ^• α 2. Distribute configuration (tsc.cfg) to all production systems <

O

3. Carry out the "TSC restart" process

I-

g Maintain TSC exclusion filter 0 The TSC exclusion filter defines words and phrases for which a search string, 1 if it is contained in it, is blocked for certain channels. These 2 closures are country-specific and can be defined depending on the time. 3 The filters are usually maintained using a separate application (the TSC Admin 4 application). Ultimately, the file of the TSC exclusion filter is the 5 product of an export from the "Filter DB" and is available in CSV format. This 6 file can be edited with a standard editor if necessary. 7 The modified filter can only be activated with the restart the "TSC s Search" processes. The following steps are defined for the "Maintain TSC exclusion filter" process:

TSC restart

The "TSC Restart" process can be started manually or automatically by other scripts, such as in the context of filter activation.

Role activities

1. Start tsc_restart.sh ω

03 a. Start tsc_restart.sh on all production systems c o

E i. Determination of the PIDs of all processes "TSC search"

E ω

-o • =

<u- ii. Successive, time-delayed sending of the kill signal to

O O

U) V) all processes

I- r-

The "fast-cgi" environment of the Apache web server automatically restarts the preconfigured number of "TSC search" processes. Edit TSC search query

The "Process TSC search query" process is the central process that is implemented by the research system.

The following procedure outlines this process at a high level. This process will be detailed later in the document.

Evaluation of TSC statistics

The statistics file can be viewed using a text editor or imported into other programs because the file is in CSV format. Evaluation of TSC error log

The error log can be viewed using a text editor.

TSC platform analysis model

Use case diagram, rough analysis

FIG. 4 describes the rough relationships between the actors and use cases involved in the search system (TSC).

Use case: TSC configuration "TSC Admin" has the option of viewing and changing the configuration of the search center stored in an XML file. To do this, he uses the Admin Tool, which runs on a separate computer that is not part of the productive environment. In order for a changed configuration to take effect, the individual processes must be restarted.

Business process diagram

The administration of the research system shown schematically in FIG. 5 contains various actions. This includes changing the exclusion filter and activating the changes. To activate it, a script is started that copies the current configuration to the computers of the production system. In the diagram, the computers of the production system are at the lower right corner 1 to see. The administrator himself appears as a "worker" and appears here on the left

2 at the top of the diagram.

₃ Use case: Maintain TSC exclusion filter

4 The "TSC Filtermanager" maintains the words that should be excluded from the search. These words can be defined per country (portal) as well as restricted in time.

7 After changing the exclusion filter, the search system (TSC) β must be restarted so that the changes can take effect.

₉ Use case: Activate configuration and filter 0 The configuration is transferred from the admin computer to all computers involved in the 1 search center using the admin tool and system 2 is then restarted. Restarting starts, among other things, new processes that 3 load the current configuration and the filter tables during their initialization.

4 Use case: TSC Restart 5 The search center is restarted using the admin tool. All processes on all computers involved in the search center are terminated and restarted in an orderly manner. A restart is necessary for changes to the exclusion filter or the configuration to take effect.

Use case: Edit search query The "customer" enters his search expression in the search mask of the input / output system. This can consist of several words linked with AND, OR and NOT operators. This search expression is sent to the server Engine interpreted by this, adapted to the requirements of the various (sometimes external) search engines and sent to them themselves, taking into account configurable timeouts, the various search results are then integrated into an overall view and returned to the customer's browser. Use case: evaluation of statistics

The "TSC Filter Manager" can use a text editor to view the search terms and processing times. In addition, the evaluator should be provided with options that are still subject to an ad hoc standard evaluation

5 defining criteria.

Use case: evaluation of error log

7 The "TSC Admin" can view the error messages stored in a text file using a text editor.

10 use case diagrams, detailed analysis

11 The sequence of a query to the search engines is schematic in FIG. 6

12 shown. "Send interpreted request" processes the incoming one

13 Search request, this adapts to the syntax of the external search engines involved

14 and sends it to them.

15 "Integrate results" receives the search results of the search engines and

16 presents them to the user in the desired format.

17 ιβ Fig. 7 shows schematically the sequence of a distributed query with subsequent

19 Merging the Results. "Collect results" accumulates those of the

20 search engine incoming search results. A search result must be within

21 of a configurable time limit. If this is not the case, this is interpreted 2 as an error. 3 "Error handling" takes over the logging of error states in a 4 error file. 5 "Prioritize" weights the 6 results provided by the different search engines according to certain business rules. 7 Error-treated and prioritized search results are "integrated into results page 8" converted into the desired output format. As shown in FIG. 8, the user / customer has two search options. With "simple searches" the user can enter one or more search terms and possibly search operators, which must correspond to the FAST-CGI syntax.

With "advanced search", the user can first select the type of web content they are looking for (website, image, music, etc.). Depending on the content type, customized search options are then available.

The filter or interpreter shown schematically in FIG. 9 receives the current "query string" in addition to the configuration data. This character string contains parameters and the search query of the user. The search query is modified in accordance with the filter rules of the respective system (search engine). Another step is built a complete URL for the search engine from the respective "query strings" and some parameters. This URL is in the above. Diagram identifiable as "target_URL".

Module overview

As shown in FIG. 10, the overall system is essentially divided into three modules. These are described in more detail below. Adapter classes exist in the interpreter and integrator, each of which is tailored to exactly one target system. All adapter classes have a static and a dynamic part. The static part is represented by configuration data. The dynamic part depends on the search query.

Interpreter module The BRISBANE interpreter module contains, as shown in FIG. 11, classes which serve to filter and otherwise prepare the search queries. In general it can be said that the interpreter provides the basic data for the integrator. The functionality of the filtering is strongly dependent on the target system (search engine) and is hidden in the corresponding adapter classes. 2 module integrator

₃ The classes in the module integrator shown in Fig. 12 are responsible for

4 Forwarding the modified search queries to the target systems. Further tasks of the integrator are the compilation of the search results and their conversion from XML to HTML, the display of the results page and the provision of the statistical data.

8th

9 An instance of the Request class is generated for each request to a target system. 0 These objects represent the communication interface between the search center and 1 target systems. 2 Communication with the target systems is managed by RequestManager 3. However, he is not responsible for the presentation of the results.

Server Engine module This module, shown in FIG. 13 by its classes, represents the main process of the search center. It has an instance of the "Configuration" class, which enables access to all configuration data. Within the process, configuration data is stored in different structures, such as AdapterMap. The server engine is also for instantiating the interpreter and integrator as well as the orderly one Ending the process (when a signal arrives) The Logging class is responsible for logging errors and statistical data.

Dynamic model FIG. 14 shows the dynamic behavior of the individual components and the flow of information between them.

After starting the search center software, the configuration is read out. Depending on the configuration, corresponding exclusion filters and a 1 country-specific XSL file loaded. The process is now waiting for one

₂ search query. If this arrives, the search expression is interpreted. In

3 Words that are excluded are removed from the search query.

4 In addition, the query is adapted to the syntax of the search engines involved. The modified search terms are now sent to the search engines e. Depending on the format of the returned results may be

7 a transformation into HTML format is necessary (if, for example, the results are in XML format). The results are sent to the customer's browser. 0 The process returns to the waiting position until the next request arrives. 1 The individual search queries are stored with the search expression, time stamp and duration 2 of the processing in the statistics file "tsc_statistics". In addition, 3 error states are entered in the file "tsc_errorJog" 4 during the entire process.

6 Server Engine module

initialization

During the initialization, as shown in Fig. 15, depending on active channels, configuration objects and instances of all adapters are created. The channels correspond to the previously mentioned channels and represent a very specific target system.

Processing a search query When a request arrives, as shown in Fig. 16, instances of interpreter and integrator are created. All necessary information for the instances is provided by the server engine. The interpreter now prepares the modifications to the search query, the integrator sends them to the target systems and returns the formatted search results. The interpreter and integrator instances are then destroyed. 1 interpreter module

2

3 As shown in Fig. 17, the interpreter initiates all that are required for the request

4 adapters, one adapter result each. Each individual adapter s modifies the original search query using the corresponding filter rules. This query and other parameters are for generating

7 of an AdapterResult object is necessary. The generated AdapterResult object s is returned to the interpreter, who adds it to a list.

9 Module integrator

0 After the integrator instance has been created, it is in an initial 1 state. The requests are processed by calling method 2 "doRequestsQ".

Main of the fast program

The Fast-CGI program contains a function "main ()". This is called by the web server. A prerequisite for the proper functioning of the program is correct initialization and entry into the waiting loop. The configuration is kept in a file The complete path of this file is specified via an environment variable.

Configuration of the research system

The search center is configured using a single file (tsc.cfg). This file is located on a separate computer that is not used as a production computer. The configuration file serves as a template for all configuration files per computer in the production environment. If the configuration changes (eg: Modification of the directory for the statistical files), the configuration file is modified on the computer outside the production system and copied to all computers in the production system using a script. 1 Format of the filter table

2 Upon request in the admin tool, the database (mysql) becomes a current one

3 Filter file created, which is distributed to the search center computer

4 is transmitted. s This filter file has entries line by line, within a line the values e are separated by a semicolon.

7 A line is structured as follows (values in Q are optional): β country code; word or phrase to be filtered; [Start date]; time of day

9 beginning; [End date]; Time end; Channel 1; Channel 2; ...; channel n 0 z. B. 1 DE; New; 2000-10-10; 12: 00: 00; 2001-12-31; 23: 35: 00; WWW ;;;;; 2 DE; prohibited; 2001 -10-20; 01: 00: 00; 2001 -12- 3 31; 20: 00: 00; WWW; P4P; BRISBANE; PHP; SP; AD 4 UK; beer ;; 00: 00 : 00 ;; 00: 00: 00; WWW ;; BRISBANE ;; SP; 5 CH; Alcohol; 2001-09-30; 15: 00: 00 ;; 00: 00: 00; WWW ;; BRISBANE; PHP ;; 6

Activation of configuration and filter table

The configuration and filter table are activated by starting scripts.

Format of the log file

The name of the statistics file is specified in the configuration file (tsc.cfg), e.g. B. tsc_statistics_ <PID>. <PID> is then replaced by the process ID during operation. Since several processes are running at the same time, there are accordingly many log files.

All statistics files are in a central directory. These statistics files are saved in CSV format. There is a separate process for evaluation, which is due to the large data volume a specially set up server should run. The search processes either write their data directly to the evaluation server or the evaluation process collects the statistical data of all search processes at regular intervals.

Structure of the file

The statistics file consists of 4 basic columns and another 4 columns are added for each real channel.

Basic columns:

1. Entered search terms

2. Time of the search

3. Search mode

4. Total time in ms or timeout

Columns per channel:

1. Name

2. Search terms used

3. Duration in ms or timeout

4. Number of results

Quantity structure

Basic columns approx. 50 bytes Channel columns approx. 50 bytes each

Maximum load 500 requests per second, approx. 250 bytes per request:

-> 125 KB per second - 450 MB per hour - 10.8 GB per day Error log format

2 The name of the error log file is stored in the configuration file (tsc.cfg)

3 specified, e.g. B. tsc_err_ <PID>. <PID> is then used in operation by the process

4 ID replaced. Since there are several processes running at the same time, there are also

5 correspondingly many error log files.

6 entries in the error log are made line by line. Within an entry

7 the values are comma-separated and have the following sematical meaning β time, original URL, adapted URL, time for the pure request, number of 9 hits, description of the error that occurred 0 z. B .: 1 12.10.2001 09:41:35, http: //192.168.70.42: 80 / fast- 2 cgi / ubrtsc? Lang = any & q = test & start = 0 & num = 10 & context = wwwcSιtype = allcStPort 3 alLanguage = deStContext = www, http://66.77.74.21: 8075 / max_xml_b00? hits = 4 10 & query = test & offset = 0, HTTP-Call: 145 ms, Total Hits: 15737604, ERROR in 5 Brisban integrator:: getQueryResults () 'ghttp_process () failed, Error: 6 getQueryResults 7 s If a general error occurs, it is logged in the form, time, 9 description of the error that occurred, e.g. B. 0 12.10.2001 09:41:35, ERROR in Brisbanelntegrator :: initXSLT () "mpXMLStyleptr: 1 xmIParseMemory error'.Error: can't initialize xslt-process. Process Exit

2 Description of the style sheets

3 The XSL stylesheets are used within the search center to convert the 4 responses in XML form into an HTML page in accordance with the current 5 layout specifications. The data for a website are transferred to the 6 stylesheets in XML or through stylesheet parameters. There is a stylesheet for each language 7 in the search center. Within the style sheet, the β search results are prepared in HTML and the links for scrolling forward and back 9 are generated. According to the default settings, the appropriate tab structure created above the search results and the advertising banners or the form for the new search.

Administration of the filter table

Context The context of the admin application is shown in Fig. 18.

LIST OF REFERENCE NUMBERS

1 research system

2 search engines

4 central evaluation unit

6 integration module

8 memory module

10 distribution module

12 buffer tanks

14 memory module

16 filter module

18 input / output module

20 Advertising media database

E Result records

P prioritization parameters

Claims

Expectations

1. Research system (1) for determining information from a database using 5 a plurality of search engines (2) with an integration module (6) that contains the result data supplied by the search engines (2), each comprising a plurality of result data records (E) converted into a common data format and then using a prioritization parameter (P) stored in a memory module (8), assigns a relevance characteristic value to each result data record (E).

2. Search system (1) according to claim 1, in which the prioritization parameters (P) are selected as a function of the respective search engine (2).

5 3. Search system (1) according to claim 1 or 2, the integration module (6) of which determines the relevance parameter for the respective result data record (E) taking into account an output relevance parameter provided by the respective search engine (2).

4. Search system (1) according to one of claims 1 to 3, the

Integration module (6) communicates via a common buffer memory module (12) with a distribution module (10), which converts a search request received in the common data format for each selected search engine (2) into its specific data format and then outputs it to it. 5

5. Search system (1) according to claim 4, whose distribution module (10) is connected to a second memory module (14) in which syntax data for the search engines (2) are stored.

6. Research system (1) according to claim 4 or 5, in the buffer memory module (12) of which characteristic identification data can be stored for individual search orders.

7. search system (1) according to one of claims 4 to 6, the distribution module (10) on the input side via a filter module (16) is connected to an input / output module (18).

8. search system (1) according to any one of claims 4 to 7, the

Distribution module (10) with the integration module (6) is integrated into a common unit.

9. search system (1) according to one of claims 4 to 8, in which the distribution and the integration module (6) on the data side with a

Advertising media database (20) are connected which, as a response data record to an incoming search query, delivers a data record adapted to the search query with regard to an identification signal.

10. A method for determining information from a database, in particular from the World Wide Web, using a search system (1) according to one of claims 1 to 9, in which the search engines (2) each provide a plurality of Result data sets (E) comprising result data sets are converted into a common data format, with each result data set (E) then being assigned a relevance characteristic value using the prioritization parameters (P) stored in a memory module (8).

11. The method according to claim 10, in which the prioritization parameters (P) are selected as a function of the respective search engine (2).

12. The method according to claim 10 or 11, in which the relevance characteristic value for the respective result data record (E) is determined taking into account an output relevance characteristic value provided by the respective search engine (2).

13. The method according to any one of claims 10 to 12, in which a jointly

Data format incoming search order for each selected search engine (2) converted into their specific data format and then output to this.

14. The method according to any one of claims 10 to 13, in which a search order specified via an input / output module (18) is subjected to a filtering before it is processed further.

15. The method according to any one of claims 10 to 14, in which a search request is additionally output to an advertising material database (20), an incoming response data record being assigned to the respective search query by means of an identification signal.