This invention relates to populating and providing a database that is searchable in an efficient manner.

It is particularly suitable for, but by no means limited to locating two unknown data sets within a database with no obvious connection to one another.

Background

There exist many database systems and algorithms for populating and conducting searches on databases. One manner of interrogating a database is to use deductive reasoning. In one context, a remote user may register with a system to input 'profile' information pertaining to personal user attributes such as sex, age, appearance, contact information, location etc. These user profiles may be stored in a database. In such systems, a search of other users of the database may be conducted based on search criteria data supplied by a first user which may include location information and/or descriptive information. The information supplied may comprise any number of fields and hence a degree of deductive reasoning is carried out by the database system based on pre-formulated rules. This requires conclusions to be made both on the search criteria provided and the results obtained in order to return a clear outcome as to whether a match has been found in the database. The outcome may be provided to the remote user over a network. Therefore there is a need to provide a system that allows the return of a positive result from a database in a more efficient manner by reducing the amount of searching required and the number of conclusions to find a positive result as well as reducing the data transferred between a user and the database storage system.

Summary

According to a first aspect there is provided a computer implemented method of storing data in a database as defined in Claim 1 of the appended claims. Thus there is provided a method comprising receiving a data set, wherein the data set comprises at least one data field, meta-tagging the data set based on the data content of the data set, storing the data set in a database, wherein the meta-tagging of the data set comprises apportioning one of at least a first priority and at least a second priority to each field of the data set, the first priority being considered higher than the second priority.

Optionally, the method wherein data fields associated with location are apportioned the first priority.

Optionally, the method wherein data fields associated with non-location data are apportioned the second priority. Optionally, the method further comprising meta-tagging the data set with short-form descriptors.

Optionally, the method wherein the meta-tags are arranged to maintain a link between all fields of a data set independent of the priority apportioned to each field.

Optionally, the method wherein data fields apportioned different priorities are grouped into different data collections. Optionally, the method further comprising receiving search criteria wherein the search criteria comprises at least one data field, analysing the search criteria and apportioning a priority based on the data content of the search criteria wherein the apportioning comprises apportioning one of at least a first priority and at least a second priority to each field of the search criteria, the first priority being considered higher than the second priority, searching data fields of the data sets stored in the database that have been apportioned the first priority for a match with the search criteria that have been apportioned the first priority.

Optionally, the method further comprising the steps of: if a match is found in a data field having the first priority: providing an indication of a match to a user, the indication comprising a subset of the whole data set associated with the matched data.

Optionally, the method further comprising the steps of: if a match is found in a data field having the first priority retrieving the whole data set associated with the matched data field and returning the whole data set to a user.

Optionally, the method further comprising the steps of: if a match is not found in a data field having a first priority searching data fields of the data sets stored within the database that have been apportioned the second priority for a match with the search criteria that have been apportioned the second priority.

Optionally, the method further comprising the steps of: if a match is found in a data field having the second priority: providing an indication of a match to a user, the indication comprising a subset of the whole data set associated with the matched data.

Optionally, the method further comprising the steps of: if a match is found in a data field having the second priority retrieving the whole data set associated with the matched data field and returning the whole data set to a user. Optionally, the method wherein the search criteria is provided automatically by a user system.

Optionally, the method wherein the search criteria is provided based on the location of the user system.

Optionally, the method wherein upon receiving notification of a matched data set with the search criteria sent, the user system automatically sends information to a user associated with the matched data set.

Optionally, the method of any preceding claim wherein additional priority levels may be apportioned to the fields of the data set.

According to a second aspect there is provided a computer program containing instructions that, when executed, cause a processor to perform any of the methods as described herein.

According to a third aspect there is provided a computer readable medium containing instructions that, when executed, cause a processor to perform any of the methods as described herein

According to a fourth aspect there is provided a server system arranged to perform any of the methods as described herein. Optionally, the server system comprises a data store for storing the database.

Optionally, the server system wherein the data store is a distributed data store. Optionally, the server system further comprising a user system wherein the user system is arranged to collect and send a data set to the server system and further wherein the data set may comprise user data or search criteria data. Also disclosed is a method of providing search criteria to a server system by translating desired search criteria of a user into the same format as meta- tagging used within a database of the server system, and transmitting the translated search criteria to the server system.

Optionally, the method further comprising receiving an indication of a match from the server system, the indication comprising a subset of the whole data set associated with the matched data.

Also disclosed is a user system configured to carry out any of the methods as disclosed herein.

Also disclosed is a server system substantially as herein described with reference to and as illustrated in any combination of the accompanying drawings.

Also disclosed is a method as substantially as herein described with reference to and as illustrated in any combination of the accompanying drawings.

With all the aspects, optional features are defined in the dependent claims.

Brief Description of the Drawings

Embodiments will now be described, by way of example only, and with reference to the drawings in which: Figure 1 illustrates a server system according to an embodiment;

Figure 2 illustrates a user system according to an embodiment;

Figure 3 illustrates a method of storing information into the database from a user system perspective;

Figure 4 illustrates a method of storing information into the database from a server system perspective;

Figure 5 illustrate the database arrangement residing in the data store of the server system;

Figure 6 illustrates a user search of the database in relation to a user system; Figure 7 illustrates a user search of the database in relation to a server system;

In the figures, like elements are indicated by like reference numerals throughout.

Overview

The database and surrounding support systems described herein relates to storing data in a database on a server (see Figure 1 which illustrates the server system arrangement) and processing that data in relation to a set of search criteria found through deductive search initiated by a user (see Figure 2 which illustrates the user system arrangement). The user may be present at a device remote from the server where the data is stored. The user may, at any time when operating within the environment of figures 1 and 2 ("the environment"), input data to the system which may comprise user profile information and/or user location information and/or other user search information. When the data is input to (stored in) the database, it may be meta-tagged with key markers which aid in future deductive searches and allow an easily deduce-able positive or negative result in relation to search criteria and the data stored in the database.

When a data set is input to the database, certain data of the set is allocated a priority based on the data content and meta-tagged accordingly. Data of the set having a highest priority is allocated to a primary database file (or primary data collection). Also, based on content, certain data of the set is allocated to a sub database file (or sub data collection) within the database. The sub database file/collection contains data ranked by value of the data supplied and is also meta-tagged accordingly. Hence, the primary files of the database may be searched for a positive result (match). If a match is found, a result may be returned to the user (all data of the set including the corresponding data allocated to the sub database file/collection) without any further searching being carried out. If no positive result is found, the search may continue to the sub database file until a positive result is found. In known systems, the search criteria provided by the user may not be contained within the database per se, and often, the search criteria specified is not in a concise format. This can necessitate extra processing when searching the database, and further, the search criteria may not be provided in a form that is suited to the database upon which the search is to be performed. For example, the search criteria used may not directly correlate to the names of the fields of the database or the formatting of the data within the fields. This, in turn, causes deductive reasoning carried out when searching the database and interpreting database search results to take longer and hence be performed inefficiently, or to even erroneously miss positive results. Meta-tagging and sorting according to priority as described above mitigates these failings of prior data storage and search systems by translating the search criteria of the user into the same format as the meta-tagging used to characterise the data within the database.

Data stored in the database may include user profile, image, and deductive search information, as well as messaging and location markers. Examples of user profile information includes hair colour, eye colour, skin type, height, date of birth, occupation, qualifications, job title, likes, dislikes, marital status etc. This data enables a user to find other users who's profile is contained within the database. For example, upon seeing somebody at a particular location (a 'meeting' event), a user may then search for that user to subsequently message them through the system, and eventually, make contact in the 'real world'

Another benefit of this system is in the efficiency of a search request by a user to the database after initial data set input. For example, the meta-tags may be used to locate specific data sets in the database to return a guaranteed positive result in the most efficient manner. This allows for reduced data transfer between user and database, and vice versa, when instructing and receiving the results of a search of the database.

Accordingly, the system described herein is able to provide a connection between two sets of data residing in a database that have no obvious correlation to one another through the use of deductive search based on a number of key data markers returning a positive result. This all occurs in an efficient and improved manner.

Detailed Description

Turning to Figure 1 , a server system 1 comprising the database is shown. The server system comprises at least one processor 10, associated memory 12 and data store 14. The data store may comprise a hard-disk, solid-state disk, or any high capacity storage device, and in an alternative embodiment may further comprise a plurality of storage devices. The database described herein is stored on the data store 14 and may be distributed over a plurality of storage devices. Alternatively, more than one server system may be present either on the same network or across a plurality of networks.

Optionally, the server system comprises an input device 16 and display device 18 to allow database servicing, and/or other diagnostics activities

The server system may execute a content management system (CMS) which may comprise any of data storage operations including user profile, image and/or deductive search information, messaging and messaging information, location markers associated with users of the system as well as other database servicing operations such as meta-data tagging, data organisation, data searching, reporting of results, and providing database redundancy and recovery in the case of data loss.

Figure 2 shows a user system 2 comprising a processor 20, location module 21 , associated memory 22, input device 24 and display device 26. In some embodiments, the user system may comprise a smart phone, or other mobile device such as, for example a tablet. Location module 21 may provide the location of the user system by way of information from one or more orbiting satellites such as GPS or Galileo as is known, or by network node or cell-site triangulation, or a combination of these techniques for example, and also may utilise any form of network assistance to provide enhanced or speedier location information. In another embodiment, the user system may comprise a desktop pc or laptop style device.

The user system may execute an application front end and a user interface for user interaction which may include login, profile, imaging, messaging, meeting and information screens associated with using the database of the server as well as providing geo-tag information to aid search operations of the database residing on the server. The server system 1 and user system 2 may be linked by a network to enable communication between the two. The network could be the internet or any IP network as well as WIFI, any form of telephony network such as 3G or 4G LTE or any other network or connection linking the two systems.

Primarily, but not exclusively, the database may be utilised to store user profile information as described previously. The process of initially storing new information in the database contained within data store 14 will now be described in relation to user system operation and server system operation.

Database Population

As shown in Figure 3, a user instigates the storing of their profile information at step 30. This includes the inputting of personal attribute data which may include sex, age, appearance, contact information and the optional upload of an image of themselves. This information may also include location information of the user, although such location information may be provided subsequently at any time the user is active within the environment. At step 31 , the information is sent to a server system where a central database is held on a data store 14 (this is subject to the user having access to the network upon which the server resides which would typically be by way of the internet from a smart phone).

Once received at the server, the user system in turn, receives an acknowledgement from the server at step 32. If an acknowledgement is not received, step 31 may be repeated. The user system retains a copy of the profile information sent to the server system (step 33) in order that local editing can take place with only necessity of transferring the updated profile to the server rather than requesting that the server provide the profile each time. This saves on network traffic. The user data may be created from new and/or may be acquired from any source available to the user such as a profile from a social media or other system to which the user is already registered.

At any time, the user may edit the local copy of their profile information and update the server system with the new profile information.

Turning to the server system, figure 4 shows the process of obtaining new or updated profile information from a user and populating the database on the data store 14 accordingly.

At step 40, new information is received from a user system, if no new information is received, the server system may be considered to be in a waiting state, and at step 41 , an acknowledgement is sent back to the user. An acknowledgement may not be sent back immediately for a number of reasons including server downtime, server busy, in which case a queuing system may be used to acknowledge receipt in the order that the new information requests were received at the server so that load balancing can be achieved. Alternatively, a response may be sent that gives an error message to the user system indicative of an invalid request, a request containing invalid information, server maintenance, or technical problems for example. At step 42, the incoming data is then analysed and meta-tagged (step 43) according to content. The meta-tagging may comprise apportioning a priority and/or other organisational hierarchy to the data.

Incoming data that defines a location of a user may be meta-tagged at a priority level TV. Incoming data that is descriptive of the user, i.e. profile information, may be meta-tagged at a priority level 'B'. As well as specifying descriptive data as level B, the individual data fields of the incoming data may also be tagged with short-form descriptors such that as the database is populated, a consistent form of search may be carried out in the future. Level A is considered to be of a higher priority than level B. As well as tagging the location data as level A, the location information may also be tagged with short-form descriptors defining location data accuracy, and time when the user was located at that location. A link is maintained between the descriptive data and the location data so that if a positive result may be obtained by searching on either descriptive information or location information (or both), all of the profile at issue may be returned to a user as a positive result. This link may be provided within the meta-tags and is specific to each profile.

Other priority levels may also be used to meta-tag the data so that multiple priority levels are apportioned to the data fields of each data set in the database.

An example of the meta-tagging parameters is given in table 1 below:

Name Format/Comments Data Level

Figure 5 shows the database arrangement residing in the data store 14 of the server system. As can be seen, the data of the database is split into a plurality of files or collections of data. This aids searching.

Data of level Ά may be considered to be contained in a primary file or collection of data 50 of the database and data of level 'B' may be considered to be contained in a sub file or collection of data 52 of the database. A further sub data file or collection of data 54 may be present that contains information pertaining to user search information which may be utilised to narrow down search results, or provide more information for obtaining a positive search result from the database. Once populated, the database contains many profiles from a multitude of users. Each user profile is stored separately from the others, although, depending on data supplied, profile data may be the same or similar.

Database Search and Results

Figure 6 illustrates a user search in relation to a user system. At step 60, a user may instigate a search and the user system acquires its location (and hence the location of the user) from the location module 21 of the user system. At step 61 , further information of the other user the instigating user wishes to find is requested to be provided such as descriptive information in the same manner as is present in the user's own profile. This information is transmitted to the server system at step 62 in the form of the meta-tagging that is used by the database system. This allows a reduced transfer of data packets between user system and database system when instigating a search as the data required for the meta-tags (approximately 20 bytes for example) is less than the data of a free input search term (at least 50 bytes for example) which would, additionally, require deciphering at the server side in order to be used to search the database. An acknowledgement of receipt is received at step 63. If the receipt is not received, the data is re-sent by the user system until an acknowledgement is received (subject to the user having access to the network upon which the server resides. This would typically be by way of the internet from a smart phone). After a period of time when the server is conducting a search of the database based on the information provided by the user system, a result of the search is received at step 64 and displayed to the user on display device 26 (step 65). If results are not forthcoming after a fixed period of time, the program flow can break out of step 64 and an appropriate message can be displayed at step 65 rather than the results of the search. Alternatively the further information of steps 61 and 62 may be provided at a time after receiving initial match results at step 64 based on priority level 'A' (location) data. The location information that is provided by the instigating user system at step 60 may be provided by way of a proxy user system. For example, rather than obtaining location information from a location module of the instigating user system, the location information may be provided by a second user system that is known to the instigating user system. This provides the ability for the user to appear to be positioned where the second user system is positioned rather than where the instigating user system is actually positioned.

Figure 7 illustrates a user search in relation to a server system. At step 70, search criteria information is received from a user system. As well as being used to instigate a search, the location information may also be used to location stamp and optionally time stamp the user's own profile within data store 14 so that the instigating user may be found based on their past location by another user in the future. At step 71 , an acknowledgement is sent back to the user. An

acknowledgement may not be sent back immediately for a number of reasons including server downtime, server busy, in which case a queuing system may be used to acknowledge receipt in the order that the search criteria

information was received at the server so that load balancing can be achieved.

At step 72, the incoming search criteria data is analysed and compared to the priority and/or meta-tags of the database. For example, location information is considered to be of priority level TV. If location information is present in the search criteria, this information is used to search primary file or collection of data 40. This occurs before any searching of descriptive data stored at priority level 'B' within sub file or collection of data 52. Accordingly, if a match is found in primary file or collection of data 40 based on location information alone (step 73), for example based on location and time at or since being at the location, an indication of a match, or the entire profile of the match can be returned to the requesting user at step 74.

An indication of a match may comprise a subset of the matched profile which may be based on the priority of data such as only returning the priority level Ά data of matched profiles. Such subsets may comprise data of different priority levels as chosen by the user when instigating a search during step 61 . The data returned at step 74 allows an indication of a match to reach the user without having to transmit the entire data set to the user. This allows a reduction in bandwidth usage (data packets) between the server system comprising the database server, and the user system, which reduces processing and battery overheads at the user device.

A match may be considered to be made if the location information of a database entry was within 20m distance and within 5 minutes of time.

Optionally, the distance information may be smaller, for example 5m. The distance and time information considered to make a 'match' will differ based on the various system(s) or method(s) of acquiring location information available, and how accurate the location and time information is that they can provide. The whole profile may be returned because profile information spanning the primary and sub files is linked (for example using meta-tagging) when populated in the database as described earlier. Further, the match or indication thereof can be returned based solely on the priority level Ά search without needing to search using other search criteria that were received at the server system at step 70. This provides a more efficient search with less search transactions required and hence is more processor efficient at the server system. One or more matches may be presented to a user at step 74. Alternatively, at this point, for multiple match returns, level B search data could be used to narrow down the user of interest. For example, the user may specify level 'B' criteria such as hair or eye colour in order to narrow down the matched results before the entire data profiles of matches are returned to the user. The specifying of level 'B' criteria may take place either when instigating a search or at a later time after receiving initial matches or indications thereof. In the same manner as the initial indication of a match, this allows further narrowing down of 'matched' profiles without the need for the entire profile data for each matched profile to be returned to the user. This is bandwidth and processor efficient.

If no match is found at step 73, then step 75 may be executed where a further search is carried out based on priority level 'B' data stored in sub file or collection of data 52. Therefore further specification of the profile of a user to be found (that was previously provided at step 70) may be used to search the database. Following this second search, any positive results are returned to the instigating user at step 75 in the same manner as step 73.

Accordingly a two level form of search is provided that allows reduced processing and enhanced speed for the provision of an initial search based on prioritised data. If the first search provided no results then a second search is performed based on lower priority data.

Even if no match is provided as a result of the second search, the location information that was stored against the instigating user's own profile at step 70 resides in the database as a potential meeting event. Subsequently, a different user may interrogate the database by inputting details of a 'meeting' event by following steps 60 to 64 themselves.

Once search results have been provided to the instigating user (a 'meeting' event match), the opportunity is presented to contact the other user(s) who have been matched. This may be in the form of requesting a face to face meeting and/or requesting messaging through the server system. By messaging through the server system, users may interact without giving each other personal details until a degree of trust has been established. The messages may be encrypted. A user may view and edit messaging requests received at a later time. When messaging is instigated, the messages may be displayed in the form of a typical text messaging style window.

The user system retains a local copy of 'meeting' events (other users who have been matched to the instigating user based on search criteria) and may edit the details of a meeting event they have created (while awaiting a match which may take hours, days or longer if the other user in question is not currently using the database system herein described). The updated information may then be used as updated search criteria in accordance with Figure 7 and the associated description.

In another embodiment which may be used in combination with the before mentioned database system, the search criteria may be altered to include other criteria commonly associated with employment which may include qualifications, job title etc. This may be used by a prospective employer who wishes to recruit, or a prospective employee who wishes to be recruited,

An employer may populate the database with desirable criteria of potential employees, which may include for example, qualifications etc together with the location at which the employee would work, or a location that is being targeted for recruitment.

A user may instigate a search based on an advert or other indication observed, or communicated in some other way at a location. For example, one or more of a job title, desired qualifications, geographical location of work etc. The search is then carried out in the same manner as previously described with a match being returned if the user's qualification or other information associated with employment matches criteria specified in the database by a (prospective employer). The user system may automatically instigate the sending of user profile information which may include enhanced information such as a CV, bio, contact information or other information such as a short film about the user to the prospective employer using information regarding the employer contained in the match information returned, or obtained by some other means such as user input. Alternatively, or in addition, information regarding geographic location may be pushed to the user system. For example, a prospective employer could request that any user who matches certain criteria and who is located at or within a certain distance form a location be made aware of the criteria that the employer desires. As a user system reaches that particular location, or is within the certain distance from the location, the user system may automatically send user profile information to the prospective employer if the profile information matches the criteria defined by the prospective employer.

The various methods described above may be implemented by a computer program. The computer program which may be in the form of a web application or 'app' may include computer code arranged to instruct a computer or processor to perform the functions of one or more of the various methods described above. The computer program and/or the code for performing such methods may be provided to an apparatus, such as a computer or processor, on a computer readable medium and/or a computer program product. The computer readable medium could be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, or a propagation medium for data transmission, for example for downloading the code over the Internet. The computer readable medium could take the form of a physical computer readable medium such as semiconductor or solid state memory, magnetic tape, punch card, a

removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disc, and an optical disk, such as a CD- ROM, CD-R/W, DVD or Blu-ray. The computer readable medium may comprise non-transitory media as well as transmission media. An apparatus such as a computer may be configured in accordance with such code to perform one or more processes in accordance with the various methods discussed herein. Such an apparatus may take the form of a data processing system. Such a data processing system may be a distributed system. For example, such a data processing system may be distributed across a network. Such an apparatus may comprise a mobile phone, tablet, laptop or other processing device.