Biometric authentication data access

Abstract

A method for biometric data access in a biometric device environment is provided. The biometric device environment includes a plurality of biometric devices, the plurality of biometric devices are grouped into a plurality of biometric device zones, and the biometric device zones are associated with one or more biometric databases. The method includes receiving biometric data of a user and determining an order of one or more of the plurality of biometric device zones according to an expected access to the biometric data of the user. The method further includes adding the biometric data to one or more of the biometric databases associated with at least a subset of one or more of the plurality of biometric device zones in response to reaching a start time, removing biometric data from one or more databases associated with subsequent biometric device zones in response to an access progression event, and / or adding biometric data to one or more databases associated with subsequent biometric device zones.

Description

Technical Field

[0001] The present disclosure relates to a biometric authentication system. In particular, the present invention relates to a method for accessing biometric data in a biometric device environment.

Background Art

[0002] In some biometric identification systems, the matching algorithm attempts to find a match for the captured image of the person being identified from among the recorded identities or the database of records. The number of records available for potential matching with the subject is also referred to as the "gallery size". As the gallery size increases, the time and amount of processing required to find a match between galleries increases. As the gallery size increases, the probability of returning an incorrect result also increases.

[0003] An airport or other passenger terminal can have a number of biometric devices, for example, different types of touchpoints where a biometric system can be used. The touchpoints may store a local copy of the gallery or access a central touchpoint database. The addition of each passenger to the central database is triggered by registration outside or within the terminal. The galleries for processing at these touchpoints may include only the records of passengers registered within a specific time frame. For example, the gallery may be refreshed at regular frequencies such as daily, every few days, etc.

[0004] However, even if refreshed, the gallery size may exceed the size associated with an acceptable level of error risk. Each time an error or exception occurs, the time required to investigate and correct the problem can incur significant time costs in terms of touchpoint throughput and overall processing time. The maximum gallery size that the system can handle for each touchpoint may also depend on other factors such as regulatory factors (e.g., GDPR or "General Data Protection Regulation"), or technical factors such as storage facilities, processing speed, or communication speed.

SUMMARY OF THE INVENTION

PROBLEMS TO BE SOLVED BY THE INVENTION

[0005] In relation to this, a method, a system, and a computer program product are presented as defined by the independent claims.

[0006] More specifically, a method for biometric data access in a biometric device environment is provided. The biometric device environment includes a plurality of biometric devices, the plurality of biometric devices are grouped into a plurality of biometric device zones, and the biometric device zones are associated with one or more biometric databases. The method is executed by a biometric data access server system and includes receiving biometric data of a user and determining an order of one or more of the plurality of biometric device zones according to the expected access to the biometric data of the user based on a scheduled activation. The method further includes adding biometric data to one or more of the biometric databases associated with at least a subset of one or more of the plurality of biometric device zones in response to reaching the start time of the scheduled activation, and removing biometric data from one or more databases associated with the current biometric device zone and / or adding biometric data to one or more databases associated with a subsequent biometric device zone in response to an access progression event.

[0007] Furthermore, a distributed server system for biometric data access is presented. This system includes a plurality of biometric databases, a plurality of biometric devices are grouped into a plurality of biometric device zones, the biometric device zones are associated with one or more of the plurality of biometric databases, and the distributed server system is configured to execute the methods described herein.

[0008] Finally, when a program is executed by a computer, a computer program is presented that includes instructions for causing the computer to execute the methods described herein.

[0009] Further improvements are indicated by the dependent claims.

[0010] These and other objects, embodiments, and advantages will become readily apparent to those skilled in the art from the following detailed description of the embodiments with reference to the accompanying drawings, and the invention is not limited to any particular embodiment.

[0011] Here, with reference to the accompanying drawings, embodiments will be described as merely examples.

Brief Description of the Drawings

[0012]

Figure 1

[0013]

Figure 2

[0014]

Figure 3-1

[0015]

Figure 3-2

[0016]

Figure 4

[0017]

Figure 5

[0018]

Figure 6

Mode for Carrying Out the Invention

[0019] In the following detailed description, reference is made to the accompanying drawings which form a part of the detailed description. The exemplary embodiments described in the detailed description shown in the drawings are not intended to be limiting. Other embodiments can be utilized and other changes can be made without departing from the spirit or scope of the presented subject matter. It will be readily understood that the aspects of the present disclosure generally described herein and shown in the drawings can be arranged, substituted, combined, separated, and designed in a variety of different configurations, all of which are contemplated in the present disclosure.

[0020] Airports or other passenger terminals may have multiple checkpoints where it is necessary to identify passengers. Biometric devices or touchpoints may each be provided at checkpoints where biometric identification is used. The provided biometric touchpoint(s) may access a central database or store a local copy of the central database that can be updated periodically. However, the central database may present a gallery size, i.e., the number of passenger records it contains, that is larger than required by some touchpoints, considering the highly dynamic nature of passenger movement. The gallery size of the central database may also be a size that poses an unacceptable level of error risk or is too large for the local system of the touchpoint to process efficiently.

[0021] This specification discloses systems and methods for setting and controlling gallery size at various points within a network of "touchpoints" that each utilize biometric identification or biometric devices. Passengers who choose not to participate in the biometric registration process that enables biometric use are not included in the gallery. The system creates a dynamically modifiable gallery of the touchpoint(s) included in each touchpoint zone within the touchpoint network. At any given time, different galleries may be used for different touchpoints. This can be accomplished by configuring the system to move passenger records between different biometric databases and dynamically modify the galleries stored therein. The biometric database is hereinafter also referred to as the touchpoint database. At a higher level, the system enables integration between the touchpoint gallery and the dynamic characteristics of passage or throughput through the touchpoint network.

[0022] The gallery can be modified to remove passenger records flagged as having issues. For example, each gallery can be analyzed using a local analysis process to check whether any two or more identities have biometrics calculated to be too similar to each other. For example, identities with biometric scores that are very similar and exceed a certain threshold may be flagged as having issues.

[0023] Modifications can be made to reflect the latest flight configuration information for the passenger, or the movement of the passenger through the touchpoint network, or both. The dynamic modifiability is enabled by the selective inclusion or exclusion of registered passengers to various touchpoint galleries. In other words, this is the selective inclusion of the exclusion of available registered records into various touchpoint databases.

[0024] In the context of air travel, the selective inclusion or exclusion may be based on flight information or the progress of the passenger. Thus, this depends on one or more factors, for example, any one or more of the following, but is not limited to these. - The correspondence between the current time and date and the scheduled or, if necessary, updated flight time information of the flight reserved for the registered passenger. - The correspondence between the scheduled or, if necessary, updated airport information and the location of the touchpoint for the flight reserved for the registered passenger. - The correspondence between the zone or location of the touchpoint corresponding to the touchpoint database and the area designated for access by the registered passenger. - The progress of individual registered passengers through the airport or touchpoint network. - The quality of the registered image or additional passenger details such as the passenger's mileage status.

[0025] Therefore, embodiments of the biometric data access server system perform at least one or more of the following operations to modify the gallery. - Extract or determine timing information regarding a flight corresponding to a registration record included in a passenger's token (e.g., a "flight start" window, departure time, etc.), and assign the passenger to an arbitrary gallery only if the current time meets the timing requirements (e.g., the time is within the "flight start" window and the time is before the departure time, etc.). Further, if the timing requirements are no longer met due to a change in the timing information, the passenger is removed from the gallery. - Extract or determine flight position information regarding a flight corresponding to a passenger's registration record (e.g., terminal location or departure gate), and assign the passenger to a gallery of touchpoints only within a touchpoint zone that matches the position information. If the touchpoint zone no longer matches the position information due to a change in the position information, the passenger is removed from the gallery and re-assigned to the gallery with respect to the touchpoint zone that matches the new position information. That is, a change in the flight position information regarding a passenger's flight triggers a change in the destination touchpoint database(s) for the passenger's token. - Extract or determine airline information regarding a flight corresponding to the registration record (e.g., airline name), and add the record only to the touchpoint database specific to that airline. - Extract or determine accessible touchpoint zone information regarding a flight corresponding to the registration record (e.g., a specific airline counter or kiosk defined by the airline code of the flight), and assign the passenger to a gallery for touchpoints only within the accessible touchpoint zone(s). That is, when a change in the accessible airport zone information is triggered, a change in the destination touchpoint database(s) of the registration record is triggered. Extract or determine information regarding whether a passenger is permitted or will be permitted to enter an airport area with access restrictions (e.g., a specific airport lounge), and include the touchpoint database of touchpoints within these areas as the destination of the passenger's registration record. Extract or determine touchpoint access permission information regarding a passenger from passenger data or movement data, or both, corresponding to the passenger's movement, and add or remove the passenger's registration record to / from the airport touchpoint database according to the touchpoint access permission. Monitor DCS transactions for tracking a passenger's progress through a touchpoint network to dynamically determine the timing of including the passenger in different galleries according to a plan to define the order in which touchpoint zones will become accessible to the passenger.

[0026] The system will be described in more detail below. The system is described in the context of a network of touchpoints at an airport, or at another port or hub for different modes of travel, where biometric identification of passengers is performed. However, it will be understood that the described system and method may be useful in other situations or applications where biometrics are used, for example, to control access of persons recorded through various checkpoints, or entrance or exit positions within a site.

[0027] FIG. 1 schematically shows a biometric device environment, or rather, a network 100 of biometric touchpoints at airport 10. This is an example of a biometric device environment at an airport, but is not limited thereto, and all the technical features described should be understood to be applicable to other environments as well.

[0028] Network 100 can include touchpoints for various physical or functional zones of an airport, such as a check-in zone, a baggage drop-off machine zone, a baggage inspection zone, an airport lounge, a boarding gate zone, etc. In this example, different touchpoints can be a check-in counter (e.g., an airport common use service counter, or an "ACUS (Airport Common Use Service)" counter) 102, a biometric kiosk 104 which can be a self-service kiosk, a baggage drop-off machine kiosk 106, a baggage inspection point 108, an airport lounge touchpoint 110, or a boarding gate touchpoint 112. The division between zones can be made more granular. For example, check-in kiosks reserved for different airlines may be considered to be in different touchpoint zones. Further, check-in kiosks reserved for different seat classes or mileage members may also be considered to be in different zones.

[0029] Various types of touchpoints may be further classified according to access restrictions to the touchpoint. For example, the ACUS counter 102, the biometric check-in kiosk 104, the baggage drop-off machine kiosk 106, and the baggage inspection point 108 are arranged in a part of the airport 10 where passengers can usually enter without first obtaining the permission required to enter the boarding gate area.

[0030] Also, the touchpoints 102, 104, 106, and 108 are touchpoints arranged in the "landside" 12 of the airport 10, or may be called "landside" touchpoints. The airport lounge touchpoint 110 located at the entrance to the airport lounge, and the boarding gate touchpoint 112 are in an area of the airport where passengers can enter only when they have obtained the permission usually required to enter the boarding area. Therefore, they can be called touchpoints on the "airside" 14 of the airport 10, or "airside" touchpoints. In FIG. 1, the dashed line 16 conceptually separates the airside 14 and the landside 12 of the airport 10.

[0031] Touchpoints within the network 100 can be connected via a communication network to a biometric data access server system, such as a biometric gallery segmentation platform 114. The communication network can be a cloud network or a local area network. The gallery control platform 114 includes or has data access to a registration database 116 that holds biometric records of all registered passengers. Registration to add passenger records to the registration database 116 may be off-airport registration performed before the passenger arrives at the airport, or on-airport registration performed after the passenger arrives at the airport.

[0032] Data from the registration database 116 is selectively included in a plurality of touchpoint databases 118, 120, 122, 124, 126, 128. Each touchpoint database 118, 120, 122, 124, 126 holds a passenger token. The token then includes biometric records that constitute a biometric gallery for access from one or more touchpoints within the corresponding touchpoint zone. In this example, the touchpoint databases include an ACUS counter touchpoint database 118, a check-in kiosk touchpoint database 120, a baggage drop-off touchpoint database 122, a baggage inspection touchpoint database 124, a lounge touchpoint database 124, and a boarding gate touchpoint database 126.

[0033] To enable selective inclusion of a passenger's token from the central token database 116 into separate touchpoint databases, reservation data is added to the passenger's registration record, and as a result, the timing of touchpoint activation is collated with a time frame defined by a reservation such as a flight date or flight time.

[0034] In some cases, each touch point within the same touch point zone can only access the same touch point database and thus the gallery. However, alternatively, each touch point within the same zone may be configured to access, for example, several galleries related to each airline or flight respectively. This is useful in situations where the touch point zone is a "shared use" zone, where the touch points are "shared use" and are shared by different airlines. The passenger may be prompted to select the airline or flight for the reserved trip in order to determine which gallery or galleries the system will use. Thus, shared use touch points may need to access several galleries for different airlines or flights in order to further reduce the gallery size for biometric matching. The galleries may be held in separate databases where passengers flying different airlines are included in different galleries. Thus, when a passenger attempts biometric matching at a shared use touch point, it is preferred that the matching be performed only between the passenger and one of the galleries.

[0035] The touch points shown in FIG. 1 are non-limiting examples. Not all of the depicted touch points need to be included in all embodiments, and some embodiments may have other types of touch points.

[0036] Figure 1 shows a one-to-one relationship of each type of touchpoint having a touchpoint database. However, this does not necessarily have to be the case. For example, touchpoints of the same type may be further divided into different groups or sets according to their operating zones as described above. The zones may be defined by location (e.g., a specific gate area), flight operator (i.e., airline), seat class, mileage status, etc. For example, check-in kiosks dedicated to different airlines may be configured to access different touchpoint databases, and as a result, galleries of different airlines contain only biometric data of passengers reserved for flights operated by each respective airline. Therefore, multiple touchpoints of the same type are considered to be in different touchpoint zones and access different touchpoint databases.

[0037] Conversely, the same touchpoint may be configured to be able to access different touchpoint databases. For example, a biometric check-in touchpoint for common use may be available for check-in by passengers traveling on different airlines. In biometric matching at these touchpoints, the biometric matching engine can access only the touchpoint databases each containing tokens for passengers traveling on each respective airline.

[0038] As used herein, the term touchpoint database may refer to any kind of organized data storage, such as a relational or non-relational database. The touchpoint database may be located centrally on-premises (e.g., within an airport server room), at the same location as the touchpoint device (e.g., within the storage of the touchpoint device itself), and / or remotely or in the cloud. Multiple touchpoint databases may be hosted by a single or multiple database systems(s) or server(s), i.e., the touchpoint database may be a logical part of a larger database system.

[0039] Figure 2 schematically shows a biometric gallery subdivision platform 114. The biometric gallery subdivision platform (also referred to as an identity management platform or a biometric data access server system) 114 in this embodiment provides a registration server for processing passenger registration. However, the biometric gallery subdivision platform 114 may alternatively be implemented separately from the registration platform and simply process data from the registration platform.

[0040] As shown in Figure 2, during initial registration, the control platform 114 includes a server or server array conceptually represented by box 202. The server or server array 202 may have or access registration data from a registration server or server module.

[0041] In this example, the server or server array 202 is shown to support both in-airport registration (e.g., biometric registration via a common use self-service or "CUSS" kiosk) and out-of-airport registration (e.g., registration via a mobile application). The server or server array 202 supports a registration application programming interface (API) 204. A passenger can provide biometric registration data 206 from a device 208 via the API 204. The API 204 may be web-based, and as a result, there is no need to install a native application on the passenger's device. In alternative embodiments, it will be understood that the server can support in-airport registration only.

[0042] The server or server array 202 preferably has access to airport data 207. The access is real-time or substantially real-time. The airport data 207 includes airport information such as flight terminal and gate data. Airport data 207 specific to a passenger's itinerary is part of the passenger itinerary data for the passenger. In addition to the airport data 207, there may be other passenger itinerary data such as lounge access, travel class, loyalty information, etc., but is not limited thereto. The other passenger itinerary data may be available from a reservation server (not shown). The airport data 207 is updatable to reflect dynamic characteristics of the airport such as a change of gate or terminal for any flight. In FIG. 2, the airport data 207 is shown to be provided from an airport server 222 separate from the platform. However, in an alternative implementation, the airport server 222 may be integrated with the platform 114. Communication between the server or server array 202 and the airport server 222 may be bidirectional. For example, the airport server 222 may be configured to provide updates to the server or server array 202. Additionally or alternatively, the server or server array 202 can retrieve the latest airport data.

[0043] Server or server array 202 further has communication access to "n" airline departure control systems (DCS) 224.1, ..., 220.n, which is the number of airlines' DCS, in order to retrieve or receive DCS data 220.1, ..., 224.n. The data may be provided via a wired or wireless communication network. DCS data generally includes ticket information regarding passengers reserved for a flight. This may be data regarding a specific flight related to a passenger's reservation. Examples of DCS data include, but are not limited to, airline, flight date, flight start time, passenger seat information, boarding time, flight closing time, flight departure time, and the progress of passenger movement, as reflected by whether a DCS transaction has occurred (e.g., whether a passenger has checked in, whether baggage check-in has been completed, etc.). Platform 114 may continuously check for updates to DCS data. However, if the DCS and the platform are provided by the same organization or if the DCS and the platform are integrated, the DCS may provide a push notification to inform platform 114 of updates to the DCS data.

[0044] As described later, each of the foregoing types of data can be used to determine how to subdivide the central gallery into smaller galleries and minimize the size of the galleries in the touchpoint database of various touchpoints.

[0045] In some embodiments, a passenger may first provide the originally scheduled movement data 209, as shown in FIG. 2, such as by entering or uploading reservation details or check-in codes. Alternatively or additionally, the scheduled data 209 may be provided by a reservation system server (not shown). For example, the scheduled movement information 209 may be obtained at the time of registration at the airport, such as by searching for check-in information where the passenger has already checked in or by querying the airline's reservation database at the check-in counter.

[0046] Referring again to FIG. 2, the server or server array 202 includes a mapping module 210, which, for a passenger or in relation to a passenger's flight, uses information obtained from airport data 207, itinerary data of other passengers, or information obtained from DCS data 220.1, ... 220.n, or both, and maps it to the passenger's biometric registration data 206 to create a "token" for the passenger. The mapping module 210 may be implemented by a separate mapping server.

[0047] The mapping module 210 may extract information from the airport data 207, such as airport location data related to the flight. For example, if a passenger's flight is scheduled to depart from a specific terminal, the passenger's token is added only to the database of touchpoints for that terminal. In embodiments where itinerary information of other passengers is available, the mapping module 210 may also extract additional information such as itinerary information of other passengers, the passenger's travel class, airline loyalty class or rank, lounge access privileges, etc. This enables the created tokens to be subdivided into different smaller databases based on the airport data and the itineraries of other passengers, i.e., based on assigning registered passengers to different galleries. The finer the subdivision, the more galleries there are. For example, in the case of an airport with three terminals, each registered passenger is assigned to one of three different galleries for verification at the touchpoints of each terminal. However, there may be further subdivision of each gallery. For example, the gallery of any terminal may be further divided according to various biometric device zones within the terminal, such as one or more check-in zones, one or more baggage drop zones, one or more security zones, one or more boarding gates, etc.

[0048] Since airport data related to a passenger's journey may change (e.g., gate change), a passenger's biometric authentication record may be moved from one gallery to another. In this sense, by subdividing the central gallery into various smaller galleries as described above, it responds to the dynamic characteristics of the airport.

[0049] However, passengers may be assigned to all touchpoint galleries at the airport. In this case, the dynamic subdivision of the touchpoint galleries is done only by DCS data to reflect changes in flight data (e.g., flight time).

[0050] The advantage of mapping a passenger's biometric registration record to DCS data is that biometric verification is not affected by changes in DCS data such as seat changes.

[0051] Any change in timing data due to a change in the dynamic characteristics of the airport (update of airport data) or the dynamic characteristics of the flight (update of flight data) may affect the timing at which each passenger is assigned to or removed from various galleries.

[0052] For each passenger, the mapping module 210 uses the initial reservation information 209 and the biometric information to create a new passenger registration record, i.e., a "token", in which the biometric information is mapped to the reservation information. This means that the passenger's token contains their biometric data (e.g., face signature, etc.) and also data determined based on the initial reservation information, which can be the airport, gate, airline, terminal, flight time, etc. The determined data may include a list of touchpoint databases in which the passenger's biometric record should be included. It may also include timing data for including the biometric record in the database. The list is updatable based on one or more of the dynamic characteristics of the airport, the dynamic characteristics of the flight, and the passenger's progress, as described above. The mapping module 210 may be further configured to determine a list of one or more touchpoint databases that do not currently contain the passenger's token but will be modified to include the passenger's token in the future.

[0053] In a scenario where a particular passenger has a permanent biometric record, the passenger token may also include data determined based on the biometric record and the initial reservation information and may be permanent. The passenger's token is stored in the passenger token database 214. The token is also updatable due to changes in flight data or airport data, as described above.

[0054] The number of records in the passenger token database 214 may be different from the number of records in the central registration database 116 described with respect to FIG. 1. For example, the central registration database 116 may be refreshed periodically, and the passenger token database 214 may be updated more frequently. For example, each time a flight departure occurs, the passenger tokens of the passengers reserved for that flight may then be removed.

[0055] The passenger token database 214 is accessible by the conversion module 218. The conversion module 218 is configured to selectively include or remove tokens from one or more of the touchpoint databases 118,... 128 in order to modify the gallery in these databases. The conversion module 218 may be implemented by a separate conversion server.

[0056] Instead of being executed on the same server as shown, the mapping module 210, the conversion module 218, and the registration API 204 may be provided by separate servers (i.e., a conversion server and a registration server). The mapping module 210 may be provided on the same separate server as the conversion module 218.

[0057] The selective inclusion or removal of each token is performed according to a list of touchpoint databases of tokens configured to include the passenger's tokens. If a touchpoint database that currently contains the passenger's token is no longer listed in the token, the token is removed from that touchpoint database. If the passenger's token is not currently included in the touchpoint database but is included in the list, the passenger's token is added to that touchpoint database.

[0058] The list may be modifiable according to the planned startup. The modification may also be triggered by changes in airport and flight information configured to be detected when the system can access DCS and airport data. The modification to the list of touchpoint databases may be performed by the movement of passengers through the touchpoint network. The movement is reflected by the confirmation of a successful DCS transaction at a specific touchpoint.

[0059] Figure 3-1 shows an example of a passenger's token 300. As shown, the biometric token 300 includes the passenger's biometric data or signature 302, such as a biometric template. These may be obtained from an identification document with a passenger photo, or both, during the registration process. The token 300 may also include one or more identifier data 304, such as a unique identifier assigned to the passenger, which can uniquely identify the passenger's token. It may include passenger information such as name, date of birth, nationality, etc., but this information is not necessarily required.

[0060] The token 300 includes boarding pass data 306. This can be achieved by providing one or more boarding pass data fields in the token 300. The boarding pass data is generated by airline DCS at the time of passenger check-in and continues to be updated as needed to reflect changes in DCS information. The boarding pass data field 306 may hold some or all of the data related to the passenger's boarding pass. For example, the field may include timing fields such as flight departure time, boarding time, departure time, etc. The field may also be a field related to the passenger's seat assignment.

[0061] The token 300 further includes, but is not limited to, airport data 310 that defines location information such as airport, terminal, and gate. This can be implemented by providing one or more airport data fields. In embodiments where the passenger token is created before check-in, the airport data may be entered at the time of reservation. Since the mapping module 210 is configured to access airport data from the airport server to ensure that the airport data included in the token 300 is up-to-date, the airport data is updatable.

[0062] As previously described in connection with the mapping module 210, the mapping module 210 determines based on the boarding pass data 306 and airport data 310, and optionally other passenger journey data such as the passenger's biometric registration data should be included in the touchpoint database. These define the touchpoints at which a passenger can be biometrically verified. Accordingly, the token 300 includes a data field that accommodates a list 314 of touchpoint databases in which the passenger's token is included. When biometric verification occurs at a touchpoint, the passenger's biometric registration record is removed from the corresponding touchpoint database. Accordingly, the list 314 is updated. This can also trigger an updated list 314 that further modifies to include another touchpoint database in which the passenger's token should be included here. Further inclusion depends on the "scheduled activation". The scheduled activation is the schedule that the passenger's biometric registration is to be "activated" for a touchpoint, that is, since the passenger's token is included in the corresponding touchpoint database, as a result, a 1:N verification can be performed at those specific touchpoints.

[0063] A passenger can be "activated" for different touchpoints according to a specific order set by the scheduled activation, that is, their token and / or biometric (registration) data can be added to the touchpoint database of the touchpoint (this is also explained as the passenger's token being assigned to a gallery). That is, a passenger can access one or more of the touchpoints to be biometrically verified before accessing one or more of the other touchpoints to be biometrically verified. Accordingly, one or more orders of a plurality of biometric device zones corresponding to the expected access to the user's biometric data based on the scheduled activation are determined.

[0064] Thus, token 300 may include a field 316 that holds a list of one or more touchpoint databases in which the passenger's token will be included later. For example, these may include touchpoint databases of touchpoints where biometric verification is expected to occur later, such as touchpoint databases of touchpoints within different airports for a later segment of a multi-segment journey.

[0065] An expiration field 318 may be included to define when token 300 expires, i.e., when it is automatically deleted from the token database and all touchpoint databases.

[0066] Figure 3-2 shows another example of a passenger's token 350 mapped with the latest boarding pass data and the latest airport data from the DCS. Similar to token 300, token 350 includes biometric data 352 for the passenger and one or more identifier data 354 for the passenger. In this example, as in the example shown in Figure 3-1, the identifier data 354 may include a registration ID generated by an identity management platform (IMP) used to manage passenger registration data.

[0067] In this example, the DCS data 356 within the token 350 includes startup time data 358. The startup time data 358 defines the time or time frame when the passenger's biometric registration data is included in the touchpoint database. For example, the time can be the flight start time. The "time frame" can be defined by the startup time and the expiration time. For example, the time frame can be between the flight start time and the departure time. The startup time data 358 can define multiple time frames during which the passenger's token should be included in different touchpoint databases. For example, during the "flight start" window for check-in purposes, the passenger's token is included in the touchpoint database of the check-in touchpoint. The "boarding start" time frame is set so that the passenger's token is included in the touchpoint database of the boarding gate touchpoint during the "boarding start" window that can end when the flight departs. The startup time data 358 can be updated to include the latest data for various times.

[0068] The DCS data 356 may also include a boarding pass data field 359 that accommodates some or all of the boarding pass information, as in the case of the token 300. Preferably, the boarding pass data field 359 includes at least the passenger seat data.

[0069] The token 350 further includes one or more data fields for holding airport data 360, such as a scheduled startup location 362, e.g., Terminal 1 - Gate 57. The scheduled startup time 358 and the scheduled startup location 362 define when and where 1:N biometric verification is available. Changes to these fields are made by updated data from the airport or DCS.

[0070] The starting position field 362 does not need to be provided separately in all embodiments. For example, a list 364 of touchpoint zones where 1:N biometric verification is possible for a passenger (by virtue of the passenger's token being included in the touchpoint database) may already be restricted to those touchpoint zones within the planned starting position. For example, each touchpoint zone included in list 364 may be defined according to the touchpoint function or type of the airport and terminal where the zone is located, such as Sydney - Terminal 2 - Baggage Drop - off Machine, or Sydney - Terminal 1 - Gate G27, etc. Updates to the airport data that affect the location information also trigger updates to the touchpoint zone list by the mapping module 210. It will be understood that providing the current list of touchpoint zones 364 serves the purpose of providing the list 314 of the current touchpoint database within the token 300.

[0071] The list 364 of biometric device zones (or the list 314 of the database in Figure 3 - 1) can be considered as "passenger flow" data. This is because modifications to list 364 can be triggered by the flow or progress of passengers through the airport from check - in to boarding.

[0072] Therefore, updates to list 364 are made by airline DCS transactions. The DCS data is used to check the progress of the movement of passengers through the touchpoint network to determine which touchpoint database should next contain the passenger's token according to the aforementioned startup schedule. The result of this determination is used for token updates. Then, the conversion module or server can move the passenger's token accordingly. Therefore, given the same startup schedule, the timing of allocating passengers to different galleries according to the schedule may vary depending on the progress of different passengers.

[0073] Similar to the future list 316 of the touchpoint database included in token 300, token 350 may include a future list of touchpoint zones 366 that can match a passenger against biometrics at a future time or within a future time frame, i.e., may be included in the gallery stored in the touchpoint database. A further list of touchpoint zones 366 may define touchpoint zones that can only be accessed by a passenger after successful biometric matching at any of the touchpoint zones included in the corresponding touchpoint database of the passenger. A further list of touchpoint zones 366 may define touchpoint zones located in future segments of a multi-segment journey.

[0074] It will be understood that the lists 364, 363 of touchpoint zones may instead be lists of databases, as in the case of token 300 shown in FIG. 3-1.

[0075] In this example, "token" 350 further includes "expiration" data 368, similar to token 300 shown in FIG. 3-1. The expiration data 368 can define the amount of time that data can remain on the system before being automatically deleted. This is separate from the startup schedule. For example, referring to FIG. 1, records may be automatically deleted from the token database 214 that provides data sources 128 from the touchpoint database 118 at the expiration time.

[0076] An example of a startup schedule is shown in FIG. 4. In the exemplary schedule 400, the touchpoints in the network are organized into first, second, third, and fourth groups 402, 404, 406, 408, each belonging to a touchpoint zone. Each group can have one or more sets of touchpoints, and each set comprises one or more touchpoints of a particular type. Touchpoints within the same group access the same touchpoint database.

[0077] Groups or zones are arranged sequentially or in a time series. For example, the touchpoint database of the fourth group 408 is typically the last database to receive the passenger's token from the conversion module 218. The touchpoint database of the touchpoints of the third group 406 typically does not receive the passenger's token before the touchpoint database of the touchpoints of the second group, and the touchpoint database of the touchpoints of the second group 406 typically does not receive the passenger's token before the touchpoint database of the touchpoints of the first group.

[0078] In this example, the touchpoints within the first group 402 include the ACUS counter touchpoint 410 and the self-help kiosk touchpoint 412, that is, the touchpoints typically at checkpoints that passengers can access upon their first arrival at the airport. The touchpoints within the second group 404 include the baggage drop-off touchpoint 414 and the baggage inspection touchpoint 416. The first and second groups 402, 404 are "landside" groups. The touchpoints of the third group 406 in this example include the lounge access touchpoint 420 and any other touchpoints for permitting biometric access to other areas on the airside of the airport. For example, there may be a duty-free store access touchpoint 418. The touchpoints of the fourth group include one or more boarding gate touchpoints 422. The third and fourth groups 406, 408 are "airside" groups.

[0079] The types of touchpoints included in each group of the exemplary schedule 400 are merely exemplary and serve to illustrate the generalized concept of non-simultaneous inclusion of the passenger's token in the touchpoint database, where the inclusion is executed according to the "scheduled start", and it will be understood that the timing of the inclusion is affected by reservation information, or DCS data such as the flight departure time, boarding time, and the progress of the passengers through the airport.

[0080] It should be understood that FIG. 4 merely shows an example. In actual use, the startup schedule may depend on the configuration of the touchpoints available at the airport. For example, at an airport where the only biometric touchpoints are at the ACUS counter(s) and boarding gate(s), there are only two touchpoint databases. It should also be understood that the concept of ordered startup is applicable to any network of touchpoints in which the currently disclosed system is deployed.

[0081] Furthermore, different startup schedules may be set for different passengers. For example, in the case of a passenger who needs to complete airport registration, they first need to access the touchpoints of the first group 402, and thus, the passenger's token needs to be added to the databases of those touchpoints first. However, in the case of a passenger who has successfully completed off-airport registration and check-in procedures, the inclusion of the passenger's token in the databases of the touchpoints of the first group may be bypassed, or in some cases, the passenger's token may be included in the databases of the touchpoints of both the first and second groups 402, 404.

[0082] In another scenario, when a passenger checks in at a counter or kiosk, the passenger's token may be made available in the databases of one or more of the remaining touchpoint zones. For example, referring back to FIG. 1, after the passenger has a successful match at the ACUS check-in touchpoint 102, the remaining touchpoints include the baggage drop-off touchpoint 106, the baggage inspection touchpoint 108, the lounge touchpoint 110, and the boarding gate touchpoint 112. The self-service kiosk 104 touchpoint may not be considered a "remaining" touchpoint as it is intended to serve the same function as the ACUS check-in touchpoint in the movement of passengers through the airport's touchpoint network.

[0083] In another scenario, when a passenger checks in at a counter or kiosk, the passenger's token may be made available in a database of touchpoint zones accessible to the passenger. For example, referring again to FIG. 1, when the biometric verification of the passenger is successful at either the ACUS counter 102 or the self-service touchpoint 104, the passenger's token is included in the databases of the baggage drop-off touchpoint 106 and the baggage inspection touchpoint 108. This is because these are in touchpoint zones accessible to the passenger. Thus, according to the schedule, since the passenger has not yet passed through the baggage inspection touchpoint, the updated list (314 in FIG. 3-2) of the touchpoint database for the passenger's token does not include the database of any airside touchpoints.

[0084] In another alternative, even if the passenger's token is not necessarily yet accessible, since it is at the next stage of the movement of passengers through the airport, it may be further included in the databases of touchpoints in one or more zones that the passenger cannot yet access. This may be useful at airports where biometric touchpoints are not provided at all checkpoints.

[0085] The system may store or access one or more predetermined rules regarding how to manage the galleries stored in the database for a particular touchpoint.

[0086] Generally, a passenger's token or biometric authentication data may be added to the touchpoint database from a start time defined by flight time data (e.g., flight start time), and removed from the database based on the passenger's progress through a schedule by access progression events. The deletion of a passenger's token from the touchpoint database may be managed by different rules for different databases, e.g., according to the definition of access progression events. According to one rule, a passenger's token may be removed from the touchpoint database only if the record is also deleted from the central database. This rule may be applied, for example, to the ACUS counter touchpoint database. According to another rule, a passenger's token is removed from the touchpoint database according to the progress of the passenger's scheduled departure. For example, when a passenger passes through baggage inspection, the passenger's token may be removed from the touchpoint databases of the baggage drop-off touchpoint and the baggage inspection touchpoint. According to yet another rule, a passenger's token is removed from the touchpoint database at a time set according to the boarding pass data. For example, when the flight departs, the passenger's token may be removed from all touchpoint databases.

[0087] The system may be configured to add or remove a passenger's token to or from the touchpoint database according to one or more algorithms. The algorithms implement one or more of the rules for defining how to proceed from one touchpoint group to the next in a scheduled departure, i.e., for defining access progression events.

[0088] According to one rule, a touch point group includes at least one touch point set in a specified touch point zone. When a successful match for passenger biometric authentication is detected at any of the specified touch points within the specified zone, the passenger's token is deactivated (i.e., deleted from the database) for all touch points within the group. If applicable, the detected match also triggers the passenger's token to be added to the touch point database for all touch points within the next group. For example, referring to FIG. 4, upon detection of a successful match at the baggage inspection touch point 416, the passenger is "activated" (added) for all touch points within the second group 404 within the third group 406.

[0089] Alternatively, if a touch point group does not include the aforementioned specified touch points, a successful passenger match is required for each touch point set within the group before the passenger's token is added to the touch point database for the touch points within the next group.

[0090] According to another rule, progression to a touch point group is only possible within a group-specific activation time frame. This rule can be used in combination with any of the above rules. For example, referring to the exemplary activation schedule 400 shown in FIG. 4, the passenger's token can be added to the database of the boarding gate touch point 422 only when it is detected that the passenger has matched at the baggage inspection touch point 416 and the current time is within the "gate start" time frame.

[0091] After a passenger touches at any touch point within a touch point set and is matched against a gallery and biometric authentication in a touch point database, there may be different rules for defining whether the passenger remains "activated" for a particular touch point set. According to one rule, the passenger remains "activated" for a particular time frame (i.e., the records still included in the touch point database), regardless of the number of times a match can succeed. An example is the lounge touch point 420 where the passenger's token remains in the database until the "gate start" or "flight closure" time. According to another rule, if a passenger is matched once at any touch point within a touch point set, that passenger is "deactivated" with respect to the touch point set (i.e., the passenger's token removed from the touch point database of the touch point set). The boarding gate touch point is an example. The baggage inspection touch point set 416 is another example where each passenger can access the baggage inspection checkpoint only once.

[0092] Based on passenger movements detectable through DCS data updates, examples of how a passenger is "activated" or "deactivated" for different touch points will be described with reference to FIG. 5. In this example, the activation of any touch point within one group triggers the activation of touch points within the next group, and when a biometric authentication match at a touch point succeeds, the passenger is removed from the touch point gallery.

[0093] Generally speaking, an access progression event may be a successful match of biometric data in one or more biometric devices in the current biometric device zone. In response to that event, the biometric data may be removed from one or more biometric databases associated with the current biometric device zone.

[0094] Alternatively or additionally, the access progression event may be to determine that the current time is the activation time of a subsequent biometric device zone. In response to that event, biometric data may be added to one or more biometric databases associated with the subsequent biometric device zone.

[0095] Alternatively or additionally, the access progression event may be to determine that the current time is the expiration time or after the expiration time of the current biometric device zone. In response to that event, biometric data may be removed from one or more biometric databases associated with the current biometric device zone.

[0096] Referring to FIG. 5, at step 502, at the start of the time frame defined by the "flight start window" field 308, the passenger's token is added to the database of one or more initial touch point sets.

[0097] At step 504, biometric verification is successful at a touch point belonging to any of the initial touch point sets. If a match occurs at the boarding gate (arrow 506), the passenger activation process ends and the "boarding" transaction is confirmed. The passenger is "deactivated" for all touch points at step 508 (i.e., the record is removed from all touch point databases).

[0098] Otherwise, if the current time is still within the "flight start" window, the system updates the list of databases containing the passenger's token (arrow 510). Updating the list of activated touchpoints includes, in step 512, removing from the list the touchpoint database corresponding to the touchpoint where the match was successful. This deletes the passenger's biometric registration record from that touchpoint database. For example, if a passenger completes checking in at a biometric check-in touchpoint, the passenger's biometric registration record may be deleted from the touchpoint database accessed by the check-in touchpoint.

[0099] If there are no more touchpoint types for which the passenger's biometric verification is required (e.g., if the passenger has been verified via the boarding gate touchpoint to board the plane), or if the activation time frame has ended, the passenger's activation schedule ends (step 508).

[0100] In step 514, if there are still touchpoint zones available for the passenger to access in the "scheduled activation" and the "flight start" window has not ended (or the flight has not departed), the system updates the list of databases containing the passenger's token by including one or more touchpoint databases in the list. For example, the mapping module adds all touchpoints belonging to the next group within the scheduled activation to the list.

[0101] If no further verification occurs before the activation time frame(s) end (arrow 516), the activation schedule ends in step 508. Otherwise, while the activation time frame is still open (arrow 518), the system resumes from step 504 if the passenger's biometric verification is successful.

[0102] Figure 6 shows a slightly modified startup process 600. At step 602, the passenger is assigned to one or more galleries, that is, the passenger's token is included in one or more touchpoint databases. These are databases of touchpoints within a touchpoint zone that can be evaluated by the passenger. If the passenger's match does not occur before a known expiration time (e.g., "flight closure" time), the process follows arrow 606 and ends at step 608, and the passenger's token is removed from all touchpoint databases. At this point, the passenger's token is not necessarily removed from the central token database. Alternatively, at step 604, a match is successful at the touchpoint and the passenger's token is assigned to the corresponding database. At step 612, upon confirming a successful DCS transaction as a result of the successful match, the passenger's token is removed from the touchpoint database where the match occurred. Further, since the token contains updated DCS data, the token is updated.

[0103] Following step 612, if no further match occurs by the expiration time, or if the touchpoint zone where the match occurred is the last scheduled touchpoint zone (e.g., the boarding gate touchpoint zone), the process ends at step 608. Alternatively, if a further match is successful at another touchpoint where the corresponding touchpoint database contains the passenger's token, the process returns to step 604.

[0104] If there are additional touchpoint zones that the passenger can currently access, at step 622, the touchpoint databases of the touchpoints within those zones are modified to include the passenger's token. Thereafter, the process returns to the step of waiting for a successful match (arrow 624).

[0105] In some embodiments, any one of a group of touchpoint zones within the startup schedule may have a specific touchpoint zone. When the matching in that zone is successful, the passenger's token is removed from the touchpoint database(s) of all touchpoints within that group. For example, all touchpoint zones on the landside may be considered to be in a first group according to the schedule, and all touchpoint zones on the airside may be in a second group within the schedule. When the matching at the baggage inspection touchpoint zone is successful, the passenger's token may be removed from the touchpoint databases of all touchpoint zones in Group 1.

[0106] Accordingly, the foregoing disclosure provides a system and method for mapping a passenger's biometric registration data to DCS and airport data and, accordingly, subdividing the central gallery into smaller-sized touchpoint zone-specific galleries stored in the corresponding touchpoint databases. When the token is mapped with live DCS and airport data, the DCS transaction or the update of the airport dynamics also affects the subdivision of the gallery. Accordingly, the gallery of the touchpoint database is dynamic, i.e., it can be modified in response to one or more of 1) an update to the DCS transaction capturing the passenger's progress, 2) the flight dynamics obtained from the DCS data, 3) the airport dynamics, i.e., an update to the airport data.

[0107] Within this system, it is not necessary to access all of the registration records and process all gallery sizes. Each touchpoint accesses only the records within the corresponding touchpoint database. Processing smaller gallery sizes reduces biometric matching errors.

[0108] Some embodiments are consistent with the present disclosure. For example, in a first embodiment, a computer-implemented biometric authentication token for a passenger is presented. The token includes a biometric data field comprising the passenger's biometric data, an identifier field comprising a unique identifier assigned to the passenger, and a database list field comprising a list of databases in which the token is included, the database list being configurable based on one or more information items within movement data related to the passenger's scheduled movement, and a database list field. The list of databases is updatable in response to an update of one or more information items within the movement data.

[0109] In some forms, the movement data includes departure control system (DCS) data related to a flight.

[0110] In some forms, the movement data comprises airport data related to a flight, the airport data being provided by an airport server and updatable in response to a change in the dynamic characteristics of the airport related to the flight.

[0111] In some forms, the list of databases is configurable based on one or more information items in the airport data, or the DCS data, or both.

[0112] In some forms, the DCS data comprises at least one or more of boarding pass information, flight start time, flight number, flight departure time, seat assignment.

[0113] In some forms, the airport data comprises at least one or more of an airport identifier, a terminal identifier, a boarding zone identifier, a boarding gate identifier.

[0114] In some forms, the token further comprises an activation time field comprising activation time data that at least defines a time during which the passenger can be assigned to a database included in the list.

[0115] In some forms, the database is subdivided from a central token database and is included in the databases included in the list of databases. The subdivision is performed based on one or more of the items of information, as the list of databases to which the item of information should be updated can be triggered.

[0116] In some forms, the token further comprises an expiration time field that comprises expiration time data that defines when to remove the passenger from all databases.

[0117] In some forms, the update to the list of databases is triggered by detection of an update in the airline DCS data from which the occurrence of a DCS transaction can be determined.

[0118] In some forms, the update to the list of databases comprises removing the database from the list if a DCS transaction occurs after a match between the passenger and its database.

[0119] In some forms, the token further comprises a future database list field that comprises a second list of databases in which the token is included after a multi-segment trip or in another segment, for the future database list field.

[0120] In a second aspect, a method of modifying a touch point database of one or more biometric touch point zones within a biometric touch point network is disclosed herein. The method comprises, for each passenger, receiving the passenger's biometric registration data and scheduled movement data regarding the passenger's scheduled movement, the scheduled movement having an identifier assigned thereto, initializing a biometric token for the passenger that comprises at least the biometric registration data and the scheduled movement data, Determining one or more lists of biometric touchpoint zones accessible to a passenger, the lists being for inclusion in a token, the biometric touchpoint zones being accessible to the passenger if their corresponding touchpoint databases contain the passenger's biometric registration data, and each touchpoint database being configured to receive the passenger's biometric data only if one or more pieces of information within the passenger's movement data are of respective predetermined values; Obtaining any updates within movement data from a movement configuration server, and if it is determined from the updated movement data that there are changes to one or more information items, updating the scheduled movement data with the updated movement data and updating the list of biometric touchpoint zones; Assigning the passenger's biometric registration data to the touchpoint databases included in the list at a startup time set by the scheduled movement configuration data or the updated movement configuration data; including.

[0121] In some forms, obtaining the scheduled movement data includes querying the movement configuration server to obtain movement data corresponding to an identifier assigned to the scheduled movement, and the movement data is updatable by the movement configuration server.

[0122] In some forms, the method further includes assigning at least one or more of the biometric touchpoint zones to the passenger's startup schedule, the startup schedule defining the order in which the passenger's biometric registration records are included in the touchpoint databases of one or more of the biometric touchpoint zones to which they are assigned.

[0123] In some forms, the method is assigning a startup time to at least one of the biometric touchpoint zones included in the startup schedule, the startup time being updatable in response to any updates within the movement data corresponding to the identifier; At the assigned startup time or the updated startup time, further include including the passenger's biometric registration data in at least one touch point database of the biometric touch point zones.

[0124] In some forms, the touch point startup schedule comprises one or more groups of touch point zones, each group comprising at least one touch point zone, and the groups are arranged sequentially such that the passenger's biometric registration data is added to the touch point database of the touch points of the subsequent group after the touch point database of the touch points of the previous group.

[0125] In some forms, the timing at which the passenger's biometric registration record is added to or removed from the touch point database corresponding to the group within the startup schedule is set according to the passenger's progress via the touch point network.

[0126] In some forms, the startup time extracted for each passenger comprises a time frame having a duration.

[0127] In some forms, the method further includes removing the passenger's biometric registration data from the touch point database of the touch point zones included in the list when the duration expires for each passenger.

[0128] In some forms, the method is to extract startup position data from the scheduled or updated movement data for each passenger, wherein the startup position data identifies one or more startup positions and each biometric touch point zone included in the list is located at one of the startup positions, and further includes extracting.

[0129] In some forms, the method further includes querying or receiving from the biometric verification engine any verification match success confirmation of a passenger processed by the biometric verification engine, or querying a travel provider server for confirmation of a successful transaction by a passenger using a server.

[0130] In some forms, the method further includes removing a passenger's biometric registration data from a touch point database of a biometric touch point zone when a successful transaction or verification match regarding the passenger is confirmed at one touch point of the biometric touch point zones.

[0131] In some forms, the method further includes adding a passenger's biometric registration data to at least one touch point database of a biometric touch point zone included in the next group within the activation schedule when a successful transaction or verification match regarding the passenger is confirmed at any touch point of a biometric touch point zone belonging to one of the groups within the touch point activation schedule.

[0132] In some forms, the extracted activation time includes an expiration time, and the passenger's biometric registration data is removed from all touch point databases containing the data at or after the expiration time.

[0133] In some forms, the touch point network is provided at an airport, and the expiration time is the departure time of a scheduled flight.

[0134] In some forms, the activation time comprises two or more different time frames.

[0135] In some forms, the passenger's biometric registration data is added to the touch point database of one or more biometric touch point zones at the first activation position at the start time of the first time frame, and to the touch point database of one or more biometric touch point zones at the second activation position at the start time of the second time frame.

[0136] In some forms, the movement data comprises one or more of an airport identifier, a terminal identifier, an airline code, a flight number, a flight time, a flight start time, a flight closure time, a boarding time, and a departure time.

[0137] In some forms, the passenger's biometric registration data is included in the touch point databases of all touch point zones within the network.

[0138] In some forms, the method further includes removing the passenger's biometric token from the passenger token database after deleting the passenger's biometric registration record from the touch point database.

[0139] In some forms, the removal from the central database is performed after the expiration of a predetermined period after the removal from the touch point database.

[0140] In a further aspect, disclosed herein is a method of subdividing a passenger token database storing a plurality of biometric tokens provided according to the first aspect above into one or more gallery databases. The method includes extracting or reading each biometric token, a first list of one or more galleries, and activation time data, and adding the biometric token to one or more gallery databases corresponding to one gallery each included in the first list of galleries at the activation time defined by the activation time data.

[0141] In some forms, the method further includes detecting whether a matching occurs between any biometric registration data of the biometric token and one of the gallery databases.

[0142] In some forms, the method further includes removing the biometric token from the gallery database where the matching with the biometric token is detected when the matching of the biometric token is detected.

[0143] In some forms, the method further includes re-extracting or rereading one or more updated lists of galleries from the passenger's biometric token and adding the biometric token to the gallery database corresponding to the updated list.

[0144] In some forms, the method further includes removing the passenger's biometric token from the gallery database corresponding to the list of galleries within the biometric token at the expiration time defined by the startup time data.

[0145] In some forms, the method further includes removing the biometric token from the passenger token database at or after the expiration time defined in the biometric token.

[0146] In yet another aspect, a method for creating a computational implementation biometric token for a passenger is disclosed herein, the method including obtaining the passenger's biometric data from a registration database, providing a biometric data field comprising the biometric data, providing an identifier field comprising a unique identifier assigned to the passenger, obtaining mobility data regarding the passenger's scheduled mobility from one or more mobility servers, determining a first list of one or more databases in which the token should be included based on one of one or more information items within the mobility data, and providing a database list field and assigning the first list of one or more databases thereto.

[0147] In some forms, the method includes detecting whether an update has occurred to any one or more information items within the movement data, and in response to detecting an update to one or more information items within the movement data, determining, based on the update, an updated list of one or more databases that should contain tokens, and updating the list within the database list field with the updated list.

[0148] In another aspect, a biometric touchpoint database management platform is disclosed herein, the platform including a central token database and a plurality of touchpoint databases each comprising data subdivided from the central token database, wherein tokens included in a particular instance of the plurality of touchpoint databases at different points in time are dependent on movement data related to passenger movement at that time, and the platform further comprising a server or distributed server array configured to execute instructions for performing a method according to any of the above aspects.

[0149] In a further aspect, there is disclosed herein a computer-implemented system for providing biometric tokens. Each token comprises a biometric data field comprising the passenger's biometric data, an identifier field comprising a unique identifier assigned to the passenger, and a database list field comprising a list of databases in which the token should be included, wherein the list of databases is configurable based on one or more information items within movement data related to the passenger's scheduled movement, and the list of databases is updatable in response to an update of one or more information items within the movement data. The system comprises a communication module for communicating with a biometric registration server and one or more travel servers, and a token management module configured to create a token for each passenger, assign the passenger's biometric registration data from the biometric registration server to the biometric data field of each token, and assign a unique identifier to the identifier field of each token, a mapping module, for a passenger's scheduled movement, obtaining initial values of one or more movement information from one or more movement servers, identifying one or more databases based on the initial values of the one or more information items, wherein for at least one movement information item, only passenger tokens corresponding to passengers associated with movement data for which the scheduled movement shares the same value or all have values within a specific range of values are configured to be comprised by each identified database, assigning the one or more databases to the database list field to provide a list of databases, and a mapping module configured to perform for each passenger.

[0150] In another aspect, the present specification discloses a system for managing a touch point database of a biometric touch point network provided at a site, the network comprising one or more sets of touch points, each set of touch points comprising at least one touch point, and the system comprising a processing device. The processing device comprises a registration database comprising passenger biometric registration data, and a mapping module that communicates with a mobility configuration server for obtaining mobility data, the mapping module mapping the passenger biometric registration data to the mobility data to create a passenger token for storage in a token database. The processing device further comprises a conversion server configured to selectively include or exclude the passenger tokens in the token database in the touch point database for each set of touch points, and each touch point database is configured to comprise only passenger tokens each having at least one mobility information whose value is within a predetermined value or range of values.

[0151] Without departing from the scope of the present disclosure, variations and modifications can be made to the foregoing parts.

[0152] For example, in the process of determining how the touch points activated as shown in FIGS. 4 and 6 are determined, the first activated touch point is usually the check-in counter or kiosk touch point. However, the determination of which touch point is activated first may depend on the specific mobility situation of the passenger and the specific airport touch point network. For example, if all biometric registration and check-in processes are completed before the passenger enters the airport "inside" and there is no biometric touch point at the inspection gate, the boarding gate touch point may be included in the initial activation. If all registration and check-in processes are completed in advance but there is a biometric touch point at the baggage inspection checkpoint, the boarding gate touch point is not included.

[0153] In the following claims and the foregoing description of the invention, except where the context requires otherwise by express language or necessary implication, the word "comprise", or variations such as "comprises" or "comprising", is used in an inclusive sense, that is, specifying the presence of the stated features but not precluding the presence or addition of further features in various embodiments of the invention.

Claims

1. A method for biometric data access in a biometric device environment comprising a plurality of biometric devices, wherein the plurality of biometric devices are grouped into a plurality of biometric device zones, and the biometric device zones are associated with one or more biometric databases, the method comprising: receiving biometric data of a user; determining an order of one or more of the plurality of biometric device zones according to an expected access to the biometric data of the user based on a planned startup; in response to reaching the start time of the planned startup, adding the biometric data to one or more of the biometric databases associated with at least a subset of the one or more of the plurality of biometric device zones; in response to an access progress event, removing the biometric data from one or more databases associated with the current biometric device zone and / or adding the biometric data to one or more databases associated with a subsequent biometric device zone; performed by a biometric data access server system comprising: A method for biometric data access.

2. The access progress event comprises a successful match verification of the biometric data in one or more biometric devices of the current biometric device zone, The method according to claim 1, comprising removing the biometric data from one or more biometric databases associated with the current biometric device zone in response to a successful match verification of the biometric data in one or more biometric devices of the current biometric device zone.

3. The access progress event comprises determining that the current time is the startup time of the subsequent biometric device zone, and the method according to claim 1 or 2, comprising adding the biometric data to one or more biometric databases associated with the subsequent biometric device zone in response to determining that the current time is the startup time.

4. The access progress event comprises determining that the current time is at or after the expiration time of the current biometric device zone, The method according to any one of claims 1 to 3, comprising removing the biometric data from the one or more biometric databases associated with the current biometric device zone in response to determining that the current time is the expiration time or after the expiration time.

5. The method according to any one of claims 1 to 4, further comprising receiving schedule data, wherein the scheduled activation is determined based on the schedule data.

6. Initializing a biometric token for the user, wherein the biometric token comprises the biometric data, the schedule data, and a list of the one or more ordered biometric device zones; Storing the biometric token in a biometric token database; The method according to claim 5, further comprising the above.

7. Obtaining an update of the schedule data; Updating the scheduled activation and the list of the one or more ordered biometric device zones; The method according to claim 6, further comprising the above.

8. Adding the biometric data to one or more of the biometric databases, extracting the biometric data from the user's biometric token according to the list of the one or more ordered biometric device zones and the scheduled activation; adding the biometric data to the one or more databases associated with at least a subset of the one or more biometric device zones; The method according to claim 6 or 7, further comprising the above.

9. Adding the biometric data to one or more of the biometric databases, determining the user's biometric token according to the list of the one or more ordered biometric device zones and the scheduled activation; adding the biometric token comprising the biometric data to the one or more databases associated with at least a subset of the one or more biometric device zones; The method according to claim 6 or 7, further comprising the above.

10. The method according to any one of claims 6 to 9, further comprising deleting the biometric authentication token from the biometric authentication token database after deleting the biometric authentication data of the user from all of the biometric authentication databases.

11. The method according to any one of claims 6 to 10, further comprising deleting the biometric authentication token from all of the biometric authentication token database and the biometric authentication databases at or after the token expiration time, wherein the biometric authentication token has a token expiration time.

12. The method according to any one of claims 6 to 11, wherein the biometric authentication token further comprises a unique identifier assigned to the user.

13. The method according to any one of claims 6 to 12, wherein the biometric authentication token further comprises an ordered list of databases associated with the one or more ordered biometric authentication device zones.

14. A distributed server system for biometric authentication data access, the system comprising a plurality of biometric authentication databases, a plurality of biometric authentication devices grouped into a plurality of biometric authentication device zones, the biometric authentication device zones being associated with one or more of the plurality of biometric authentication databases, the distributed server system being configured to execute the method according to any one of claims 1 to 13.

15. A computer program comprising instructions for causing a computer to execute the method according to any one of claims 1 to 13 when the program is executed by the computer.

Images