WO2008031167A1

WO2008031167A1 - A system and method for the identification of a person

Info

Publication number: WO2008031167A1
Application number: PCT/AU2007/001367
Authority: WO
Inventors: Joshua Joseph Ginty
Original assignee: Guests Behaving Badly Pty Limited
Priority date: 2006-09-14
Filing date: 2007-09-14
Publication date: 2008-03-20
Also published as: AU2007295958A1

Abstract

The present invention provides a system and method of identifying a person. The invention utilises a database containing a plurality of records containing personal information relating to a person. The database receives information capable of identifying a person, determining whether the information utilises any existing records, and if so, return the matching information.

Description

A SYSTEM AND METHOD FOR THE IDENTIFICATION OF A PERSON

Field of the Invention

The present invention relates to a system and method for the identification of persons. The system and method find particular, but not exclusive, use in industries where goods and/or services are hired, such as hotel/motel accommodation, air travel and vehicle hire, where it is useful to keep a record of behaviour.

Background of the Invention

In an age of increasing self interest, it has become apparent that a growing section of the population has little or no regard for the rights of other individuals.

Some people treat public spaces and hired goods and accommodation with little or no respect. Many people are content to engage in lewd, offensive, destructive and sometimes illegal acts with no regard for the safety, comfort or property of others .

For example, some holidaymakers in rented accommodation behave inappropriately, damage property and engage in anti-social and/or illegal conduct. Owners or operators of holiday resorts, motels, and other accommodation venues can do little to stop such behaviour. Polite requests to refrain from such behaviour are generally ignored, and many hotel owners or operators are powerless under the law to take any further action, for fear of legal reprisal or physical assault.

If illegal acts are committed, police or other law enforcement agencies may be called, but such action is only worthwhile if the illegal act warrants the involvement of law enforcement agencies.

Moreover, once damage has been caused, law enforcement involvement does not immediately assist in payment for the damage, nor is it commonly worthwhile to pursue the alleged offender through the courts to recover damages .

Summary of the Invention

In a first aspect, the present invention provides a method of identifying a person by utilising a database containing a plurality of information records, each record containing personal information relating to a person, comprising the steps of, the database receiving information capable of identifying a person, determining whether the information provided may be at least partly matched to at least one of the information records, and if so, returning the matching information.

The each information provided may comprise a plurality of discrete pieces of information.

The method may comprise the further step of comparing the number of pieces of information provided that match with corresponding pieces of information contained in any one of the records, and where the number of matches reaches a predetermined value, a match condition is generated.

Each discrete piece of information may be ascribed a value .

The value ascribed to each piece of information may be dependent on the capacity of the piece of information to uniquely identify a person.

The step of comparing the number of disparate pieces of information may generate a match condition if the value ascribed to each matching piece of information totals a predetermined amount.

The pieces of information may include first name, last name, address, telephone number, email address, credit card details, driver's licence number, vehicle registration number, and club or organisation membership number .

If no match is made with an existing record, the method may comprise the further step of generating a new record in the database to contain the information provided.

The information may be provided via a web interface and/or may be provided from the database to a software application located remotely from the database. In a second aspect, the present invention provides a system for the identification of a person, comprising a database arranged to contain personal information pertaining to each of a plurality of persons, an enquiry module arranged to receive personal information pertaining to a person, and a weighting module arranged to ascribe a weighting to the personal information and return a value indicative of the suitability of the personal information in uniquely identifying the person.

The system may further include a matching module, arranged to utilise the weighting to determine whether any of the personal information in the database matches the personal information pertaining to a person, and if so, providing the matching personal information in the database to a user. In a third aspect, the present invention provides a computer program arranged, when loaded onto a computing system, to perform the method steps in accordance with the first aspect of the invention. In a fourth aspect, the present invention provides a computer readable medium incorporating a computer program in accordance with a third aspect of the invention.

Detailed Description of the Drawings

Notwithstanding any other forms which may fall within the scope of the present invention, a preferred embodiment will now be described, by way of example only, with reference to the accompanying drawings in which:

Figure 1 is a diagram illustrating a computing system capable of operating an embodiment of the present invention;

Figure 2 to 6 are screenshots depicting various input screens of an embodiment of the present invention; and

Figure 7 is a diagram illustrating a system in accordance with an embodiment of the present invention.

Detailed Description of a Specific Embodiment

Introduction

At Figure 1 there is shown a schematic diagram of a computing system 100 suitable for use with an embodiment of the present invention. The computing system 100 may be used to execute applications and/or system services such as a rental property management system in accordance with an embodiment of the present invention. The computing system 100 preferably comprises a processor 102, read-only memory (ROM) 104, random access memory (RAM) 106, and input/output devices such as disk drives 108, keyboard 110, mouse 112, display 114, printer 116, and communications link 118. The computer includes programs that may be stored in RAM 106, ROM 104, or disk drives 108 and may be executed by the processor 102. The Communications link 118 connects to a computer network such as the Internet but may be connected to a telephone line, an antenna, a gateway or any other type of

Communications link. Disk drives 108 may include any suitable storage media, such as, for example, floppy disk drives, hard disk drives, CD ROM drives or magnetic tape drives. The computing system 100 may use a single disk drive 108 or multiple disk drives. The computing system 100 may use any suitable operating systems, such as Windows™ or Unix™.

It will be understood that the computing system described in the preceding paragraphs is illustrative only, and that an embodiment of the present invention may be executed on any suitable computing system, with any suitable hardware and/or software .

In one embodiment, the present invention is implemented as a software application 120 which interacts with a database 122, arranged to be executable on the computing system 100.

A specific embodiment of the present invention provides a system and method for identifying individuals who engage or have engaged in undesirable acts. Databases which are utilised to contain information regarding alleged or actual misbehaviour are known. For example, all police and law enforcement agencies in many countries and jurisdictions maintain databases which list potential offenders and their alleged or proven offences. Access to offender databases is strictly controlled and the information in offender databases is not available to the public at large.

Moreover, offender databases are generally arranged to hold enough information to uniquely identify an offender. For example, the database will hold personal details unique to the offender, such as their driver's licence, their passport number, their social security number, an image of their fingerprints or another reliable biometric identifier, or a DNA sample.

This allows the law enforcement agency, such a police force, to positively identify an offender to a high standard of certainty. This is necessary to ensure that the actual person placed before the court is the person who is registered in the database.

Such rigid checking and identification procedures are not used by businesses or enterprises who deal with the general public. Due to privacy concerns and individual freedoms, many people, when carrying out their daily business, feel threatened or insulted by a request for detailed personal information.

For example, a hotel or accommodation provider may request certain information from a guest. This may include their name, their address, their telephone number, their email address, their credit card details, and in some cases, their driver's licence. However, a hotel guest is not always obliged, by law, to provide all the information listed above. For example, in some countries, it may be perfectly legal for a guest to pay by cash, thereby negating the need to ask for a credit card. Similarly, a hotel guest may not have a driver's licence, or may refuse to disclose their licence details, for privacy reasons. Therefore, an accommodation provider that wishes to identify a potential troublemaker may not normally have enough information at their disposal to make a reliable identification. Attempting to match on name or address alone may be problematic.

For example, many people have the name "John Smith" . Therefore, attempting to match using the name "John Smith" alone to a list of alleged troublemakers will not produce a reliable result.

The embodiment described herein provides a matching system which allows a provider to determine whether a guest may be a troublemaker by determining the identifying "value" of information provided by the guest.

Using the System

The embodiment described herein is a software application which incorporates a login screen, and allows an accommodation provider to securely log into the system.

Once logged into the system, the provider uploads all collected information regarding a guest into the system. In the example to be described, the provider is checking to determine whether a guest has a pre-existing record in the database.

The system does not allow a provider to randomly view a list of guests who have pre-existing records in the database. Rather, the provider must enter a guest's details into the system and will only be informed of a guest's record if the entered guest details match a pre-existing record in the database. This provides a level of privacy, as the provider is prevented from accidentally viewing records which are not relevant to the guest being entered. Referring now to Figure 2, there is shown a data input screen 200 which includes a series of text boxes 202 arranged to receive information regarding a guest.

Each discrete component of information is provided in a separate text box, to preferably allow the information to be standardised (or normalised) , which in turn decrease the probability of an erroneous match.

For example, extra spaces, carriage returns and other non-alphanumeric characters inserted into a text box may be automatically discarded before any checking is undertaken, to prevent a non-match due to the accidental inclusion of extraneous characters .

The discrete components of information may include the guest's first name, last name, address, telephone numbers, email addresses, driver's licence, credit card numbers, vehicle registration or any other information that a guest may customarily provide (e.g. a club membership number, such as a frequent flyer's club number) .

The details may also be uploaded in other ways. For example, the provider may scan a guest's driver's licence, and information may be extracted from the scanned image of the driver's licence by use of appropriate optical character recognition technology. The extracted information may then be saved in a file, in an appropriate format (for example, in a comma delimited format, or in a mark-up language format, such as XML) .

If the details are uploaded via a file (for example, a provider may input all details into a proprietary booking system, and an appropriate file may be exported from the proprietary booking system to the software application) , the file may be uploaded using the file upload feature 204 provided by the software application. In another embodiment, such a process may occur automatically (i.e. the proprietary booking system utilised by the provider may be arranged to automatically send a file, by FTP (File Transfer Protocol) , to the software application.

Any suitable method of inputting information may be utilised. Such variations and modifications are within the purview of a person skilled in the art. Once the details are uploaded, the software application performs an analysis of the provided information. The matching criteria utilised to determine a match is explained in more detail in the section entitled "Matching Criteria" . If a match is found, the matching record is displayed, in a summary format 300, as shown in Figure 3.

The summary format 300 includes the guest's name, the number of alleged acts of undesirable behaviour committed by the guest 304 and the relative severity of the worst act 306, on a rating scale of 1-5, where 5 indicates the worst act (e.g. a criminal act, such as criminal damage, theft or assault) .

The summary format may provide enough information for the provider to make a decision. However, if the provider requires more information, they may select a more detailed report, by clicking the check box 308, and selecting the "view report" button 310.

A sample report 400 is shown in Figure 4. The sample report includes more detail on the alleged act, including dates, a description of the alleged act, the involvement of third parties (including law enforcement agencies) , and also a full record of all details provided by the guest when the alleged act took place.

The report may also be printed or emailed to the provider, should the provider require a hard copy.

Once the provider is in possession of the requisite information, the provider can then make a rational decision about whether to proceed with the booking, or alternatively, refuse entry or service to the guest.

The procedure for lodging a complaint in the software application is analogous to the procedure for checking a guest . At Figure 5 there is shown a screen for lodging a complaint in the software system. There is shown a data input screen 500 which includes a series of text boxes 502 arranged to receive information regarding a guest .

Each discrete component of information is provided in a separate text box, to preferably allow the information to be standardised (or normalised) , which in turn decreases the probability of an erroneous match.

The discrete components of information may include the guest's first name, last name, address, telephone numbers, email addresses, driver's licence, credit card numbers, vehicle registration or any other information that a guest may customarily provide (e.g. a club membership number, such as a frequent flyer's club number) . The details may be uploaded in other ways, as described earlier with regard to the checking of a guest. Any suitable method of inputting information may be utilised. Such variations and modifications are within the purview of a person skilled in the art. Once the details are uploaded, the software application takes the provider to a screen 600 shown in Figure 6. The screen 600 allows the provider to input specific details regarding the alleged act, including the type of act performed (damage, theft, assault, etc.), an estimate cost for any damage suffered, a short description of the alleged act, which may be used to place the event in an appropriate context, whether the guest themselves was put on notice as to their alleged misbehaviour, and whether third parties, such as law enforcement agencies, were called to the incident.

Once this screen is completed, the provider can click the "Add Complaint" button 604 to submit the complaint to the database.

The database will then perform a match to determine whether the guest named in the complaint has a pre-existing record in the database. If the database finds a guest record that matches, the complaint details will be added to the existing guest's record. If no match is found, a new guest record is created. The matching criteria are detailed below in more detail .

Matching Criteria

Irrespective of whether a provider is searching for a record of a guest, or whether the provider is lodging a complaint, the same underlying weightings are used to determine whether a relevant pre-existing record exists in the database. However, whether that record is returned (in the case of a check) or whether the record is associated with a pre-existing guest record (in the case of a recording a complaint) depends on the total weight of the information inputted by the provider. Each discrete component of information provided is ascribed a weighting which depends on the information' s "uniqueness" (i.e. how reliable the information is in uniquely identifying a guest) . The weighting is as follows :

Table I :

Relative Weighting- for Each Personal Identifier

As can. be seen from the table, the address details of a guest are given a relatively low weighting, as many guests could share the same address. Also, guests may change their address on a semi-regular basis.

Phone numbers, and in particular mobile phone numbers on the other hand, tend to be more unique and less likely to be 'recycled' , so they are ascribed a higher weighting.

Email addresses are usually unique to a person and they are rarely passed between individuals. However, email addresses may not be trustworthy, as a guest may easily create new email address, or a family may share an email address.

Vehicle registration numbers are reasonably trustworthy, as a vehicle owner tends to keep the same vehicle for a number of years. Moreover, vehicle registration numbers are rarely recycled (except for custom plates, which may be sold to another vehicle owner) . Therefore, vehicle registration numbers are also ascribed to higher weighting.

Drivers' license numbers, passport numbers and the last four digits of a credit card are rarely (if ever) recycled (i.e. transferred to another person) and are easy to verify. Therefore, they are ascribed the highest weighting. A single match on any one of these identifiers is consider more trustworthy than a match on all of the other items.

A complaint can be associated with a pre-existing guest if the first name, last name and at least two other criteria match. This means a complaint can be associated with a guest because they have the same name and live in the same state as the guest named in the pre-existing database record (as state and country would match) . This may not be appropriate in all circumstances, particularly where the guest's first name and last name are common.

For this reason, the aforementioned weighting system is used in conjunction with a threshold value, to determine whether the match is of a reasonable standard.

In the embodiment described herein, a threshold value of 47 exists for associating a complaints record with a pre-existing guest record and a value of 16 exists for checking a guest against all pre-existing records in the database.

That is, the threshold value required for associating a complaint with an existing guest record is higher than the value required to return a positive result . For example, when checking a guest against the database, if the guest's address details match the address of a pre-existing record in the database, a match is generated. Of course, any other combination of matching criteria which scores at least a ^Λ16' also generates a match.

Conversely, when a complaint is entered into the database, the threshold value for matching the complaint to a pre-existing record is 47. Therefore, for a new complaint to be matched (and added to) an existing record in the database, at least one of the following sets of information would need to match:

• Drivers Licence Number; • Passport Number;

• Last four digits of credit card number;

• Vehicle Registration;

• Email and Mobile;

• Email and Street Address; • Email and Phone;

• Mobile and Phone;

• Mobile and Street Address;

• Email, Country, State, Postcode and Suburb;

• Mobile, Country, State, Postcode and Suburb; or • Phone, Country, State, Postcode, Suburb and

Street Address.

There may be instances where two existing guest records exist, each with a common first name and last name, but with different details which do not overlap in terms of sets of available information.

For example, one provider may have uploaded information consisting of a first name, a last name and only two other criteria (e.g. an address and a suburb) . At the time of the upload, no matching guest was found, so a new record was created.

At a later date, a second complaint was recorded by another provider, the complaint including a guest with the same first and last name. However, in this case, the provider did not include an address and a suburb, but rather, an email address and a driver's licence.

Therefore, while the same first name and last name exist in the database, the second complaint does not contain any overlapping information which can be matched against the first complaint. That is, one complaint has an email address and a driver' s licence as identifying information, and the other complaint has an address and a suburb as identifying information. In this example, there is no way of verifying that the two complaints are related, so a new record is created in the database for the second complaint.

At some time later, a third complaint is recorded with the same first name and last name as the two complaints above, and also with four discrete pieces of information that overlap with the previous two entries . That is, the third complaint has the same address and suburb as the first complaint, and the same email address and driver's licence as the second complaint. In this case, the third complaint is capable of matching either of the previous compalints.

This can be expressed as a logic expression as follows :

Complaint One: {f_name, l_name, x, y, ...}

=> new guest recorded in the system; Guest One:

{f_name, l_name, x, y, ... }

Complaint Two: {f_name, l_name₇ ..., p, q}

=> new guest recorded in the system; Guest Two: {f_name, l_name, ..., p, q } Complaint Three: {f_name, l_name, x, y, p, q, ...} => potentially matches both Guest One AND Guest Two.

The database will resolve this situation by attempting to match the new complaint to all existing complaints which share an identical first name and last name .

The information in the third complaint, when compared to the first complaint, has a threshold value of under 47, so the information is not associated with the first complaint. The information in the third complaint, when compared to the second complaint, has a threshold value of over 47, so the information is associated with the second complaint . However, if the information in the third complaint were to satisfy the threshold for both the first and the second complaint, then the system would match all three complaints and merge the three complaints into one record. In this way, records that originally exist as separate entities in the database may later be matched.

The weighting system reduces the possibility of erroneous matching, while simultaneously increasing the chance of matching disparate entries in the database, even where a guest is providing different types of information. While the embodiment described above refers to a "web" (i.e. a HTML/XML interface viewable via a web browser) , another embodiment of the invention may be implemented via a Service Oriented Architecture (SOA) . SOA is a design paradigm based on a loosely coupled collection of reusable services. That is, a provider may "link" or

"hook into" an embodiment of the present invention through an existing software application, such as a hotel reservation application. This allows the provider to execute a check on one or more guests through an existing software application (rather than through a web interface) .

The results of the check are returned as a data structure that can be used within the software that initiated the request . This is achieved by providing a SOAP (Simple Object Access Protocol) web service, which allows any software application to access and exchange XML based messages over a computer network, in this case via HTTP.

Figure 7 describes an example implementation including the relationship between the entities in the SOA. As seen at 700, the provider has a software application (such as a hotel management software package) 600. There is also provided a proxy object 702 (which is akin to a parser or filter) , which receives requests from the software application 700 and converts the requests into a language that may be understood by the guest checking service 704. This is achieved through use of the SOAP library 706. The request is sent via a network, such as the Internet 708, to the guest checking service 704. Connection to the guest checking service 704 is established and data transferred through communication between the SOAP library 706 and a corresponding SOAP interface 710 which is connected to the guest checking service 704.

The service is provided over the secure socket layer to protect data whilst in transit. As will be understood by a person skilled in the art, the system may be arranged such that a provider may only need to authenticate once per session (in embodiments where session support is provided through cookies or other means) .

In embodiments where a provider does not provide session support to their web service proxy, authentication details need to be sent for each call on the service.

Moreover, the provider passes a list of guests as input to the guest checking method. This is achieved through an array of strongly typed objects where each object represents a guest, much like rows in a table. A provider wishing to call the guest checking method on the service creates a guest object array and sets the properties such as name and address for each guest it contains.

The results from the guest checking method are returned as two related tables, represented in a structure similar to the input data. The first table will provide an overview of each guest's behaviour, for which a match was found. The second will provide more detailed information on each incident related to a matched guest. Two related tables are used rather than one to avoid data redundancy and thus increase the performance of the service .

The embodiment described herein provides a number of advantages over prior art solutions.

Firstly, the system is easy to operate and allows the user to upload information in an intuitive manner.

Secondly, by employing a weighting system, the software application provides the user with a reasonable basis on which to determine whether a guest will be a potential troublemaker. If the match is poor (i.e. there is low certainty regarding the likelihood of a correct match), the provider will not see any matching records. This reduces the chance that a guest will be erroneously identified as a troublemaker.

Alternatively, if the match is of high quality, the provider will see the record and can be reasonably sure that the match is correct, which will allow the provider to confidently make a decision as to whether to take action.

Thirdly, by ensuring consistency across like data matching categories, the system reduces the likelihood of failing to match data on the basis of poor data input.

Further, by only matching new records to existing records when a threshold "similarity" test has been satisfied, the database reduces the risk of misidentifying and erroneously collating the actions of two or more different guests.

It will be understood that while the preceding description refers to a matching system which may be used in the hotel/accommodation industry, the concept of the invention described herein may be equally applied to any suitable industry, including but not limited to vehicle hire, boat hire, air travel, or any other industry where services are sold or goods are hired on a temporary basis.

That is, the embodiment described herein may be easily adapted to be used in a generic setting, such as in a retail store, a club, or any other venue where it is common to request identification before allowing entry to a guest or customer. Such variations and modifications are within the purview of a person skilled in the art.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. A method of identifying a person by utilising a database containing a plurality of information records, each record containing personal information relating to a person, comprising the steps of, the database receiving information capable of identifying a person, determining whether the information provided may be at least partly matched to at least one of the information records, and if so, returning the matching information.

2. A method in accordance with Claim 1, whereby the each information provided comprises a plurality of discrete pieces of information.

3. A method in accordance with Claim 2, comprising the further step of comparing the number of pieces of information provided that match with corresponding pieces of information contained in any one of the records, and where the number of matches reaches a predetermined value, a match condition is generated.

4. A method in accordance with Claim 2 or Claim 3 , wherein each discrete piece of information is ascribed a value.

5. A method in accordance with Claim 4, wherein the value ascribed to each piece of information is dependent on the capacity of the piece of information to uniquely identify a person.

6. A method in accordance with Claim 4 , whereby the step of comparing the number of disparate pieces of information generates a match condition if the value ascribed to each matching piece of information totals a predetermined amount .

7. A method in accordance with Claim 6, whereby the pieces of information include first name, last name, address, telephone number, email address, credit card details, driver's licence number, vehicle registration number, and club or organisation membership number.

8. A method in accordance with any one of the preceding claims, comprising the further step of, if no match is made with an existing record, generating a new record in the database to contain the information provided.

9. A method in accordance with any one of Claims 1 to 8, wherein the information is provided via a web interface.

10. A method in accordance with any one of Claims 1 to 8, wherein the information is provided from the database to a software application located remotely from the database.

11. A system for the identification of a person, comprising a database arranged to contain personal information pertaining to each of a plurality of persons, an enquiry module arranged to receive personal information pertaining to a person, and a weighting module arranged to ascribe a weighting to the personal information and return a value indicative of the suitability of the personal information in uniquely identifying the person.

12. A system in accordance with Claim 11, further including a matching module, arranged to utilise the weighting to determine whether any of the personal information in the database matches the personal information pertaining to a person, and if so, providing the matching personal information in the database to a user.

13. A system in accordance with Claim 12 , wherein the pieces of information include first name, last name, address, telephone number, email address, credit card details, driver's licence number, vehicle registration number, and club or organisation membership number.

14. A system in accordance with any one of Claims 11 to 13, wherein the information is provided via a web interface .

15. A system in accordance with any one of Claims 11 to 13, wherein the information is provided from the database to a software application located remotely from the database .

16. A computer program arranged, when loaded onto a computing system, to perform the method steps of any one of Claims 1 to 10.

17. A computer readable medium incorporating a computer program in accordance with Claim 16.