GB2538697A - Systems and methods for controlling access of assets to security restricted areas within an airport - Google Patents

Abstract

A system and method for controlling access to security restricted areas within an airport comprises an information database for storing information about assets; and a rules engine containing real time configurable rules and values defining criteria used in the determination of access decisions and configured to, in response to input at a terminal, apply the criteria to information in the information database to determine whether access should be granted to a particular asset. Applying the criteria comprises repeated communication between the rules engine and the information database. The repeated communication may mean that rules are applied to different information each time values are input by the user. Granting access may include issuing a pass document to the asset which may include a unique identifier such as a QR code.

Description

Systems and methods for controlling access of assets to security restricted areas within an airport The present invention relates to systems and methods for controlling access of assets to security restricted areas within an airport.

Airport security has tightened considerably in recent years in response to growth in volume of air travel as well as an increased threat of terrorist attacks. Passengers must now undergo much more stringent checks when entering the site. In addition to checks made on passengers, employees accessing security restricted areas or critical parts onsite must comply with strict security requirements. "Security restricted" or "critical part" is used to refer to any part of an airport which is not openly accessible. For example it could refer to access to airside or simply to a staff room within the passenger entrance terminal before passport control. A huge number of temporary or escorted passes are issued each year for airport personnel requiring access to an airport in order to carry out maintenance works or to deliver goods. Vehicles and other assets are vetted in a similar manner and must also pass security checks on entry.

The application process for permanent and temporary passes is generally overseen by an ID pass scheme specific to each airport which ensures that the relevant security standards are met. For example, in some cases a company contracted to work in an airport, to complete upgrade works for example, must apply to join the particular scheme of which the airport is a member. The company must then appoint an authorised signatory who, once vetted, is permitted to apply for temporary and permanent passes for other employees of the company, for vehicles or for other assets. At each stage of the process strict security screening must be carried out. In the case of the authorised signatory this will involve a thorough background check.

Historically this application process has involved completion of one or more paper forms on which detailed information is provided along with the necessary documentation. Once complete, the form is then posted to the relevant authorities for checking. An error on a form of this type is likely to result in rejection of the application. The failure of an application is thus common and remedying a fault is both time consuming and wasteful because the form must be returned to the applicant for correction.

Once the pass has been issued and the person, asset or vehicle is on site regular checks are carried out by members of the airport security team to ensure that all on site personnel are in possession of a valid pass. Passes are checked each time a control post is crossed, for example on entry to the airport or passing through a gate from landside to airside. Additionally, staff can check the validity of a pass at any time whilst a person is on airport premises and in some cases regular checks are required.

The system currently in place for logging checks at many airports is extremely basic.

Even the more modern versions of such control post systems are not generally very adaptable to situations where there has been a change in circumstances. This might be the case, for example, if an MOT or insurance document for a vehicle with a pass expires between issue and a subsequent onsite check. Currently, a list of banned vehicles or persons is circulated to control post personnel at regular intervals (e.g. once per month). Each vehicle or person passing the control post must then be manually compared with those on the list, a slow process which is susceptible to human error.

In all countries airports must adhere to standards dictated by national laws (such as regulations set by the department of transport and overseen by the Civil Aviation Authority in the UK) as well as international treaties which, among other things, govern the specific checks that must be performed when deciding whether or not a person and/or a vehicle should be granted access to a particular part of an airport. In most UK airports, for example, employee passes can be granted either on a permanent basis (in which case the pass will be valid for a period of up to 5 years provided that it is used regularly) or on a temporary basis in which case a pass can be issued for a period of up to 60 days in a calendar year. Temporary passes generally require the constant presence of an escort who is in possession of a permanent pass and cannot be granted for more than the total of 60 days within a rolling 12 month period.

Because of the fast moving nature of the aerospace industry, these laws tend to change rapidly and the rules to which each airport must adhere are many and transient. On top of the need to comply with specific safety requirements, airports are also generally subject to budget constraints which make compliance with these standards difficult. Aside from the changing laws and common security standards, airports each have their own set of rules governing such security systems. Different requirements can relate to different companies working within the same airport, for example, so that the rules to be applied when deciding whether or not an application should be accepted or whether to pass a vehicle or employee at a control post are multiplied.

Static scanning points at airport departure gates for checking boarding passes and validating passenger ID are known. UK patent GB-A-2501144, for example, describes the process by which a boarding pass is scanned using a reader during boarding. Information entered by the passenger during check-in is accessed using a barcode on the boarding pass to be read.

According to a first aspect of the present invention, there is provided a system for controlling access of assets to security restricted areas within an airport, the system comprising: an information database for storing information about assets; a rules engine containing real time configurable rules and values defining criteria used in the determination of access decisions and configured to, in response to input at an input terminal, apply the criteria to information in the information database to determine whether access should be granted to a particular asset, wherein applying the criteria comprises repeated communication between the rules engine and the information database.

The information database, as well as a number of further databases associated with the rules engine, is live and communication between the information database and the rules engine allows the system to morph continuously in dependence on updated information in the databases. Updating may involve input of information at an input terminal in successive stages of an application process. The repeated communication between the rules database and the information database (as well as the application controller) means that rules are applied to different information each time values are input by the user. During the application process for passes, forms can be tailored in response to information provided by an applicant such that the information requested at the terminal can depend on user input at an earlier stage of the process.

A system is provided having a live database for adaptively managing access and movement of employees, vehicles and assets within restricted areas in the workplace. The system is directed primarily to airports and the examples presented below refer to an airport based system. It should be noted, however, that the system can be used in any environment within which access to certain areas is restricted or where management of assets is required. A similar system may be useful on a factory floor, for example, where hazardous conditions may exist in parts of the factory to which only certain employees should be granted access. In a situation such as this access may be based on having undergone certain safety training or on wearing the correct protective clothing.

The system provides a means for self-issue of permanent and temporary security passes and live monitoring and control of assets. The novel architecture allows for an adaptive application process and security checking process which is tailored to a specific airport or workplace, pass type and company. The system also controls monitoring of assets post issue and allows passes to be invalidated or validated remotely by airport staff. Means are provided for automatically refusing entry to assets immediately after invalidation on checking at a gate or elsewhere on site.

In prior art (or existing) systems such as the check in process described above, a database holds information entered before check-in which does not then change prior to departure. There may be no means for live update of the information up to boarding. In the case of passenger flow management and passenger security this is not necessary because circumstances are unlikely to change in the short time between check-in and boarding. When dealing with vehicle, asset or employee pass validity, however, the time periods involved are much longer and there are many more factors to be taken into account.

One disadvantage of prior art systems is that the validity of a pass cannot be updated after issue. Should the situation change post-issue (for example in the event of expiration of a vehicle's insurance) the pass cannot be invalidated automatically. In the present system, information regarding the expiry date of the document is stored in an information database which is referenced when a pass is scanned in order to decide whether the pass is valid at the time of scanning.

The repeated communication between the rules engine and the information database means that rules can be applied responsive to information entered into or retrieved from the database at each stage and each time the criteria is applied. The application process is therefore adaptive and the prompts appearing on the screen will vary depending on the information entered by an applicant.

In an example, the system further comprises an application controller for communication between an input terminal, rules engine and database and an application to be loaded onto the input terminal.

In an example, the rules engine further comprises a rule scope database for storing information defining where in the process a rule should be evaluated.

In an example, input to an input terminal at the first time comprises making a request for a pass. Once a request has been made, the application process will begin and an applicant will be asked to enter information responsive to prompts appearing on an input screen at the terminal.

In an example, responsive to the request repeated calls are made to the rules engine to determine which subsequent piece of information is required and a user is repeatedly prompted to enter the required information at the terminal.

In an example, after the required information is entered it is stored in the information database. This way the information database is updated each time new information is requested and entered so that rules are applied to information that adapts to the stage of the application and the particular responses of the user.

In an example, granting access to an asset further comprises issuing a pass document relating to the asset.

In an example, the pass document includes a unique identifier. This allows the pass to be easily recognised in the event of a later security check or request for access to an area of the airport. Once the unique identifier is scanned or entered into the system (at a terminal) information about the asset can be accessed. This might include checking the expiry dates of important documents (vehicle MOT documents for example) against the date of the scan to determine whether the pass is still valid or not. In this embodiment it is the information database only which is queried (however in other embodiments the criteria may also be reapplied at this stage using the rules engine).

Should the rules change between issue of the pass and the security check this will not affect the validity of the pass unless the rules engine is used at this stage to reapply the criteria. A pass can be invalidated by adapting the information database and the user made to reapply, at which point the new rules will be applied to the information entered I() during the second application process.

In an example, the unique identifier is a QR code.

In an example, the pass also includes a second identifier made up of a series of digits. This allows manual entry into a terminal in the event that the scanning capability of an input terminal fails. Alternatively the code for scanning can be replaced by a manually enterable code.

In an example, the unique identifier can be input into an input terminal to determine if the pass is valid. This may correspond to scanning of the unique identifier at an input terminal or keying in of a unique string of digits. The information database is queried again to determine whether the pass is valid at the current date. Expiry dates of MOT or insurance and other similar documents are stored in the information database so that a pass will be recognised as invalid if a crucial document has expired. Passes can also be remotely invalidated by updating the information database as necessary.

According to a second aspect of the present invention, there is provided a system for controlling access of assets to security restricted areas within an airport, the system comprising: an information database for storing information about assets; a rules engine containing real time selectively configurable rules and values defining criteria used in the determination of access decisions; wherein the rules engine is configured to, in response to input at an input terminal, apply the criteria to information in the information database to determine whether access should be granted to a particular asset at a first time, and "7 wherein the rules engine is configured to apply the criteria at a second time in response to input at an input terminal to determine whether access should be granted to the asset.

In this case the rules engine can be queried at the time of a second request at the input terminal (for example in the event of a security scan subsequent to the pass being issued). This provides the possibility of reapplying the relevant rules to information stored about the asset each time a scan is carried out. This way any change in the rules themselves or the manner in which they should be applied (which may occur as a result of a change in legislation, for example) will be taken into account and may result in a previously valid pass being found to be invalid. Each time a security check is undertaken rules will be applied progressively to database information so that the result can depend on the order in which rules are applied. Both the rules databases and the information database can be updated so that the outcome can vary each time a security check is carried out on an asset.

According to a third aspect of the present invention, there is provided a method for determining whether access of an asset to a security restricted area within an airport should be granted, the method comprising: in response to input at an input terminal, applying criteria to information about the assets stored in an information database, wherein the criteria are defined by real time selectively configurable rules and values for use in the determination of access decisions and are stored in a rules engine and applying the criteria comprises repeated communication between the rules engine and the information database.

According to a fourth aspect of the present invention, there is provided a method for determining whether access of an asset to security restricted areas within an airport should be granted, the method comprising: in response to input at an input terminal, applying criteria to information in an information database containing information about the asset to determine whether access should be granted to a particular asset at a first time; applying the criteria at a second time in response to input at a terminal to determine whether access should be granted to the asset, wherein the criteria are defined by real time selectively configurable rules and values for use in the determination of access decisions and are stored in a rules engine.

S

In an example, inputting at the first time comprises filling out an application form in response to prompts.

In an example, inputting at the second time comprises scanning a unique identifier associated with an asset.

Embodiments of the present invention will now be described in detail with reference to the accompanying drawings, in which: Figure 1 shows a system overview.

Figure 2 is a flowchart showing the application process for a temporary ID for an employee.

Figure 3 is a flowchart showing the application process for a permanent (1 year) vehicle pass.

Figure 4A is a flowchart showing the application process for a driver permit (by a sponsor).

Figure 4B is a flowchart showing the process of registering for training by a sponsored driver.

Figure 4C is a flowchart showing the process for recording the progress of a driver obtaining a licence.

Figure 5 is a flowchart showing the process for applying for a temporary vehicle pass Figure 6 shows a schematic of a rules engine.

Figure 7 shows the workflow for constructing a pass application form.

In order to be granted a pass the authorised signatory for a contracted company at a particular airport must complete an application relating to a particular employee of the company, a vehicle owned or used by the company or an asset owned or used by the company. The application can relate to any area or set of areas within the airport to which access is restricted, for example airside cargo and maintenance areas or landside areas. The type of pass required will vary as will the length of time for which the pass is required. In order for an application to be accepted, a stringent set of criteria must be met. In the example case of an application for a temporary employee pass criteria may involve the provision of employment records over a number of years prior to the application, confirmation by a criminal record check that there are no disqualifying offences recorded for the employee either in the UK or abroad, or confirmation that the relevant training will be provided by the signatory. These criteria will vary depending on the current legislation, the particular rules applied by the airport and the type and duration of the pass requested.

The present method provides a system for controlling access of assets to security restricted areas within an airport. Indeed, in some examples the system provides for self-issue of a pass by an applicant at a remote terminal using an adaptive application form. This is achieved by means of constant communication during the application process between the remote terminal and a data centre supporting an information database and a rules engine (both of which are described in more detail below). The rules engine is configured to decide which further information is required from the applicant and checks values entered for each parameter against a set of rules specific to the airport in order to verify whether or not the application satisfies the relevant criteria. If the applicant does not meet the airport's specific criteria for any reason the application will be refused. The application form is thus able to adapt to the information provided during the application process in a way that current paper or online forms cannot do.

Figure 1 shows the main components of the system. An applicant at a remote terminal (which may be mobile 3 or static 1) is provided with an interactive screen on which an adaptable form can be viewed and into which the information required from the applicant can be entered. One or more data centres support a central engine 4 having one or more large information databases 2 containing information relating to all assets and scanners controlled by the system. A number of the scanners, which may be at a fixed location or mobile, are distributed around the airport. During the application process communication between the central engine and the terminal and/or scanners is regular, allowing the process of granting access to be adaptive to information that is input and to changing information in databases located in the central engine.

The underlying architecture required to operate the system is also shown in Figure 1 as the internal structure of the central engine 4. The central engine includes a rules engine 9 and an application controller 5 as well as the information database 2. The function of each of these parts will be discussed in detail below. Any standard MVC (model-view-controller) architectural pattern and CGI platform may be used, but PHP is applicable on most standard operating systems and web servers making it particularly suitable. The central engine 4 is supported on a data centre which may be a tier 4 data centre. Tier 4 data centres provide better accessibility to data, are fault-tolerant and components are dual-powered making them ideal for use with the system as applied in airports. Tier 1, 2 or 3 data centers can also be used, however, and may be more suitable in the case of smaller operations such as a single factory. The system may also include fall over onto another data centre (which may be tier 3) to provide some redundancy and protection against further failure or loss of data. The central engine comprises an information database, a rules engine and the means to interface provided by an app which is loaded onto a scanning device or terminal (examples being a handheld scanner, mobile phone, laptop, PC, or a static scanning station). This app provides a GUI which displays prompts to a user to enter information and/or displays parameters computed by the central engine. The system can be used with existing input terminals or infrastructure within an airport, which may previously have been used for other reasons or with other systems. Loading the app onto computers or scanners that are already in place at the airport enables use of the system and provides an efficient use of resources.

The information database 2 holds data relating to each of the assets, vehicles or employees that are on record as well as relating to the component parts of the system. In most cases these will be assets for which a temporary or permanent pass application has been submitted but it will also include information about authorised signatories and can include other values such as those relating to restricted areas or checkpoints and the location of mobile scanners. All information entered by an applicant during completion of an application for a pass can also be stored. This may include general personal information, information regarding references, the areas to which access has been granted, the length of validity of the pass, escorter or driver identity, information contained in an identification document or driver's licence, and so on.

The database can be constantly updated so that any change will be recorded (a change in status or role of an employee, an offence committed or a change relating to vehicle insurance among others). The system may search other (external) databases at I() intervals in order to determine whether such a change has occurred. For example, the system may provide a link to employee records for each company registered on the system so that when the status of an employee within a company changes this will be entered into the information database. Companies and airports can be asked to provide relevant information regularly in order to maintain the database. The system can also be provided with means to search the internet for updated versions of relevant information.

The department of transport website can be reviewed at intervals, for example, to ensure that rules applied are kept up to date with the current regulations in force.

As there is generally a limit on the number of days per year for which passes can be issued to a single employee or vehicle, the system can also be configured to monitor and update the number of days remaining to a pass holder within a current rolling twelve month period. This criteria can then easily be applied on application for a pass (as one of the rules) in order to deny access if the number of days remaining is exceeded. A warning can also be provided to the pass holder, a security officer or to the company concerned when the remaining number of days allowed is approaching zero.

Figures 2 to 5 are example flowcharts showing the information that an applicant may be prompted to provide during an application process for various pass types. These illustrate the adaptive nature of the forms. Arrows inside each box indicate the information which the applicant will be asked to enter at that stage and arrows show the order in which prompts will be given. A terminal screen can be arranged as a series of boxes into which an applicant must type the relevant information and these can be shown one by one, moving to the next required piece of information once a particular field has been completed, or several can be presented on one screen. If the applicant enters a value that is not recognised by the system an error message can be shown which will remain until an acceptable value is entered. Alternatively a series of options can be shown for each field from which the applicant must select an answer. Once a piece of information has been entered it is checked for compliance with the relevant rules and recorded in the information database. Based on the information entered the application is refused, the applicant is prompted for further information or to upload a particular document or the application is deemed complete and the process terminated.

The application processes for a temporary ID for an employee (Figure 2), a permanent (1 year) vehicle pass (Figure 3) a driver permit (Figures 4A, 4B and 4C) and a temporary vehicle pass (Figure 5) are each shown. Figure 4A relates to an application by a sponsor for a driver permit. Once the application has been completed an email will be sent to the driver inviting them to register for training and to upload their driving licence. The flowchart governing this process is shown in Figure 4B. The driver must then complete his/her training and the flowchart for recording the driver's progress in this regard is shown in Figure 4C. Depending on the information entered by the applicant (or driver) at each stage, the subsequent prompts presented on the terminal screen will vary. In Figure 4A at point 100, for example, a user will be prompted to confirm that a potential pass holder is medically fit to drive in the relevant area. If the applicant replies "no" the application does not fulfil the required criteria and the process will be terminated.

If the applicant replies "yes" they can be further prompted to supply relevant medical declarations as proof The application will not reach the submission stage if at any point the information provided indicates that the application does not fulfil the relevant requirements saving time for both the applicant and the checking office.

A final check of an application must be performed at an ID centre but can also be managed to an extent by the system. The central engine can be configured to manage queues controlling the order in which applications are checked. This can be a simple first in first out system but may be more complex and may, for example, favour certain pass types or passes for which the requested start date is earlier.

Once an application has been accepted the applicant is provided with access to a downloadable pass which carries a unique identifier specific to that pass. In embodiments this unique identifier is a QR code or barcode but it can equally comprise any recognisable mark which is unique to a particular pass such as a sequence of numbers or letters or a biometric identifier. Both a machine readable code and a number or word can be included to allow manual entry in the event of failure of a scanner. The unique identifier allows information regarding the application to be accessed remotely from within the central database at any time. When a pass holder crosses a control post within the airport the unique identifier can be scanned or entered into a computerised device in order to pull up information that will tell a security officer whether or not the employee, vehicle or asset should be granted access. This may involve directly querying the information database without reference to the rules engine. The information database will contain information regarding the validity of the pass, including expiry dates for required documents which can be checked against the date of the scan to determine whether documents are valid. The information provided during the application process can, in some embodiments, also be checked again using the relevant rules each time the pass is scanned so that if a rule has changed since submission of the application which would have resulted in rejection at the application stage, access can be denied even after a pass has been granted.

Passes may be scanned at any time in order to check the status of an employee, vehicle or asset. A network of scanning devices will be located in each airport and can either be static (located at checkpoints) or mobile. Mobile scanning devices may be carried by employees and can also be used outdoors. For this reason they should be durable enough to be used during cold or wet weather and small enough to be easily carried. It is also an advantage if a security officer or another employee is able to work the scanner whilst wearing gloves or in the dark. The interface may be designed for this purpose, with adjustable brightness or large keys that are easy to identify. Scanners can comprise GPS modules from which information is downloaded at regular intervals into the information database so that the position of each of the scanners can be stored and accessed at any time.

Interfaces with scanners or terminals forming a part of the network are provided by means of an app loaded onto the relevant device. The appearance of the interface can differ depending on whether the process to be completed is a pass application or a security check within the airport. It can also be made to vary in dependence on the airport to which the process relates. In some cases various interface options may be presented to an airport when they join the scheme (or to a company when they sign up). Interface options can be made to suit the tastes and needs of the various signatories. In a country where days can be short and the weather cold, for example, larger and more obvious prompts and signs can be included and buttons made to be more sensitive so that use of the devices in the dark or wearing gloves is facilitated.

The process of determining whether or not an asset should be permitted in a certain part of the airport is carried out by the central engine. This means that a security officer performing a check need only scan the unique identifier into the system to quickly receive indication of the status of the asset without the possibility of human error. The screen may be configured to display a green portion, for example, if the asset is permitted and a red portion if not. A mobile scanner such as that described above will usually communicate with a central data centre via a wireless intemet connection (although a wired connection can be used, allowing some mobility only). Alternatively for smaller operations it is conceivable that the software comprising the central engine be located on the scanning device itself. Several wireless communication means, for example WiFi, Bluetooth and 3G, may all be used in order to provide redundancy. Information needs to be quickly accessible from all over the airport and so an efficient connection is desirable.

In the event of a request made at one of the terminals or scanning devices the application controller communicates with the information database (and in some cases, such as during the application process for a pass, also the rules engine) to determine a status for the asset. Figure 6 shows a schematic of a rules engine. The rules engine 9 may be called repeatedly and, in one embodiment, itself comprises (or is closely associated with) at least three main interconnecting databases which in some embodiments communicate only with the rules engine core. The default rules database 10 contains information regarding rule definitions, including intended scope and expected values. These rules dictate which conditions must be satisfied in order for access to be granted in a particular situation. The particular rules called and the manner in which they are used will depend heavily on restrictions imposed on airports by legislation as well as their own procedures and so rules relating to each separate airport will need to be carefully tailored.

The custom rules database 11 contains custom values relating to each of the rules (tailored to the airport to which the rules relate). It stores each specific rule implementation, including a value (the custom value) for each specific instance of a rule and its scope of operation. The value applied in each case may depend upon a certain hierarchy. Different rules may apply to particular companies working at the same airport so that the custom value applied with a certain rule can be different depending on the relevant company, person, vehicle or asset. Generally rules relating to a signatory will be afforded a higher importance than those relating to pass type which will in turn be given higher importance than those relating to the specific airport or site. The order of rule prescience may be (low to high) site, pass type, sponsor, prefix, signatory. A rule requiring that all vehicles accessing a restricted area in a specific airport be painted in a company livery, for example, may not apply to a particular company who owns private cars. In this case a rule stating that a vehicle entering an area of the airport must be liveried (with a custom value of "positive") will be trumped by a rule stating that vehicles for a particular company do not need to be livened (a custom value of "negative" for that company). The third database within or associated with the rules engine is the rules scope database 12. This defines where in a particular process a specific rule needs to be evaluated. In the case of a pass application, it will also define at which point during the application, if any, the rule should prevent the application proceeding if the rule condition is not met. In other words, this database informs where in a process a particular rule is important.

As well as the database layer 13, the rules engine 9 contains an application layer 14 (similar to the layers of an Open System Interconnection model; other of the layers forming part of such a model may also be included). The rules engine core 15 within the application layer communicates with the application controller (shown in Figure 1). Where a dynamic pass application is taking place rules are loaded to the core and are either returned to the application controller for evaluation or are evaluated within the core and the application populated with errors or required items.

In one example of a use of the system, the user is an authorised signatory with a company signed up to the scheme who wishes to make an application for a temporary pass for a vehicle. The user sits at a terminal and loads up the app. There may be separate apps for use during an application and for security checking or these may be combined in a single app and the user prompted to indicate for what purpose the app is being used. When the user indicates that he/she wishes to submit an application for a pass he/she will be shown an initial screen corresponding to a first stage of the application process and asking for certain information. Prompts at each stage will encourage the user to enter the required information (for example the type of pass required) or required objects (such as medical documents or driver's licences). Once the user has responded with the relevant information they can indicate that they consider the required fields to be complete for that screen. In examples, indicating can correspond to clicking on or pressing a "continue" icon on the screen or pushing a particular key on a keyboard in response to a prompt. Once this has been done the information entered on that screen will be passed to the rules engine core 15. Passing to the rules engine core may be via the information database or directly, in which case it will be stored in the information database at the same time as, or after, application of the rules. During later stages of the application process it can be retrieved from the information database for subsequent application of the rules by the rules engine.

The rules engine core looks at the available data and determines which rules are required. It then queries the databases associated with the rules engine (particularly the custom rules and rule scope databases) for those particular rules. Each rule is allocated a "class", as in object oriented programming, which defines the rule. This acts as a sort of "wrapper" to the rule which tells it how to interact with the data, for example defining which information is needed to run the rule, which operations can be performed etc. The relevant rules are returned to the rules engine core from the database. To provide a more efficient system, use is made of "abstract" rules and required items which record the information common to all rules and all required items. These can be adapted when needed using information from the databases to produce rules and items without unnecessary repetition.

Where more than one rule can apply, a check may be performed to ensure that the most "aggressive" or important rule is selected. This allows for a hierarchy of rules such as that described above relating to the requirement of livened vehicles. The rules are then executed in order using all of the information so far available. A list of items (e.g. pieces of information or documents) that are still required is produced as output (one item per rule in general). It is determined at this stage whether the fact that a particular item has not been provided should result in a "stop" message where the applicant cannot move on to the next stage or screen, an "error" message where the applicant is provided with a warning but is allowed to proceed, or in permission to pass on to the next screen with no warning message. Some tidying is performed by the rules engine before the user is allowed to proceed to the next stage and a new screen is displayed with prompts for new information. The appearance of the screen will depend on the result of the application of the rules at the previous stage. The process is then repeated using the additional information relating to the new screen. The rules engine may run the full 'rule set' at each stage in order to ensure that a change made at, say, stage 10, doesn't cause something that was entered at stage 1 to become invalid. The number of required items should reduce as the application progresses to the point where there are none, and the application can be submitted.

All the information needed to confirm that particular requirements for the pass type have been met must therefore be requested at some point during the application process. If a particular piece of information is not needed for the pass type applied for the user may never see a screen prompting input of this information. The process is streamlined in this way in comparison to current online forms which may relate to a number of passes and may contain sections not relevant to a particular applicant. Back and forth repeated communication between the information database, the application controller and the rules engine provides an adaptive application process which is much quicker, more efficient and easier for the user to carry out than existing systems. If a particular requirement is not met or a necessary document not provided, the user can be informed and the application process terminated. Errors can also be noted and conveyed to the applicant so that they can take steps to correct them, avoiding rejection at a later stage. Once an application has been checked and a pass issued, the applicant is provided with access to the pass on their personal device either directly or on entry of a pass code. This pass (with information regarding the pass type and a unique identifier) can be downloaded and printed at any time, perhaps weeks in advance of the start of its validity period or can simply be presented on the mobile device at the airport for scanning.

Figure 7 shows a more detailed overview of the workflow for constructing the dynamic pass application form. A controller 20 oversees the processing of and response to a request from a user. The controller communicates with form builder 22 which processes data submitted to a particular form element and applies rules supplied by the rules engine. The form builder may convert from one language, used by the controller, to another language and vice versa. This may be necessary when the form data 23 is provided in a particular language. The form builder must be able to receive and understand the form data but also communicate with other parts of the system. The form builder may, for example, convert from XML to HTML and the form data be provided in XML as shown in Figure 7. Data models 21 are linked to the information database 2 and the form builder 22. These provide information about the present state of the application.

When a pass holder needs to cross a control post or gate within the airport the unique identifier on the pass is scanned. Each time this occurs the information database is referenced in order to determine whether the pass is valid. As mentioned, in embodiments the rules engine may also be referenced in a manner similar to that described above with reference to the application process. There may be some form of input required at the scanner, for example entry of information regarding the member of personnel carrying out the check, but the majority of the information necessary to determine the status of an asset will be stored in the information database. A yes/no decision as to whether or not the pass is currently valid is made at the central engine and communicated to the interface screen on the device located at the control post or on a handheld scanner. Information can also be provided regarding the identification of a driver, escorter or pass holder or the correct contents of a cargo labelled with a pass. A passport image can be shown, for example, which can then be compared to an employee to ensure that they are the official holder of the pass. If the pass applies to cargo, this can be checked to ensure that the pass is associated with the expected goods. The control post gate will then be opened or access denied in the event of a negative response.

Because the information database and the rules engine (and its component databases) are updated regularly, passes can be remotely invalidated after they have been issued. Rules can also be changed at any time, for example following a particular change in legislation. If the conditions of a vehicle's insurance change this will also be flagged up the next time the vehicle is checked and the pass will found to be invalid at this point. The system is capable of dealing with cases where multiple vehicles are insured on one document. If the insurance has expired none of the relevant vehicles will pass their next security check.

The database is also updated in response to a check being carried out using any of the scanning devices or terminals forming part of the network. The database contains information relating to each of the devices with which it interacts. The devices can be tracked and the database updated to include a record of their current position and status. The location of the last check for a particular asset can be entered in the database as can the validity result, time, date, device used and which member of personnel performed the check (a prompt may be needed to ask the security officer to provide their details to the system). At any time, information regarding the number of times a particular check point is used, current location of an asset within the airport, number of current pass holders or any other information held in the database can be requested at any terminal, drawn from the database, and subsequently provided on the interface screen.

If there are validity requirements relating to the regularity of the checks themselves then the system is capable of recognising whether these have or have not been met. As an example one requirement might be that a vehicle must undergo a security check or an inspection (to look for faults in various components such as headlights) at least once per month. Following a successful inspection the database is updated with the time and the result of the check. The system will recognise when nearly a month has passed since the last inspection and can provide a warning which is displayed on the screen of whichever device is used to perform a security scan of the asset. This warning will let the pass holder, escorter, driver and/or the security officer know that a check must be carried out soon in order for the pass to remain valid. The central engine may be configured to provide a warning during every security check within the period of a week immediately preceding the due date, for example.

The system itself is new, both due to the addition of an extra component in the form of the rules engine which enables the system to adapt to each particular situation, and due to the manner in which the parts of the system work together. This is particularly true of the way in which the application controller and the various databases (the rules engine databases and the information database) interact in order to select which rules to apply at each point in the process and to determine items and information that are still required to be entered. Referring again to Figure 1, prior art systems involve the application controller and the database only, completely bypassing the rules engine. In the case of an online application, information is entered directly into the database via the application controller. Information flow in this case would be one-way rather than two-way, and the information retrieved from the database at a later stage when the whole of the form is checked. A dashed arrow representing information flow in a prior art system during an application process is shown on Figure 1.

Embodiments of the present invention have been described with particular reference to the examples illustrated. However, it will be appreciated that variations and modifications may be made to the examples described within the scope of the present invention.

Claims (18)

1. Claims 1. A system for controlling access of assets to security restricted areas within an airport, the system comprising: an information database for storing information about assets; a rules engine containing real time configurable rules and values defining criteria used in the determination of access decisions and configured to, in response to input at an input terminal, apply the criteria to information in the information database to determine whether access should be granted to a particular asset, wherein applying the criteria comprises repeated communication between the rules engine and the information database.
2. 2. The system of claim 1, further comprising an application controller for communication between the input terminal, rules engine and database and an application to be loaded onto the input terminal.
3. 3. The system of any of claims 1 and 2, wherein the rules engine further comprises a rule scope database for storing information defining when each rule should be evaluated.
4. 4. The system of any of claims 1 to 3, wherein input at an input terminal at the first time comprises making a request for a pass.
5. 5. The system of claim 4, wherein responsive to the request repeated calls are made to the rules engine to determine which subsequent piece of information is required and a user is repeatedly prompted to enter the required information at the input terminal.
6. 6. The system of claim 5, wherein after the required information is entered it is stored in the information database.
7. 7. The system of any of claim 4 to 6, wherein granting access to an asset further comprises issuing a pass document relating to the asset.
8. 8 The system of claim 7, wherein the pass document includes a unique identifier.
9. 9. The system of claim 8, wherein the unique identifier is a OR code.
10. 10. The system of any of claims 7 to 9, wherein the pass also includes the second identifier made up of a series of digits.
11. 11. The system of any of claims 8 to 10, wherein the unique identifier can be input into an input terminal to determine if the pass is valid.
12. 12. A system for controlling access of assets to security restricted areas within an airport, the system comprising: an information database for storing information about assets; a rules engine containing real time selectively configurable rules and values defining criteria used in the determination of access decisions; wherein the rules engine is configured to, in response to input at an input terminal, apply the criteria to information in the information database to determine whether access should be granted to a particular asset at a first time, and wherein the rules engine is configured to apply the criteria at a second time in response to input at an input terminal to determine whether access should be granted to the asset.
13. 13. A method for determining whether access of an asset to a security restricted area within an airport should be granted, the method comprising: in response to input at an input terminal, applying criteria to information about the assets stored in an information database, wherein the criteria are defined by real time selectively configurable rules and values for use in the determination of access decisions and are stored in a rules engine and applying the criteria comprises repeated communication between the rules engine and the information database.
14. 14. A method for determining whether access of an asset to security restricted areas within an airport should be granted, the method comprising: in response to input at an input terminal, applying criteria to information about the assets stored in an information database in order to determine whether access should be granted to a particular asset at a first time; applying the criteria at a second time in response to input at an input terminal to determine whether access should be granted to the asset, wherein the criteria are defined by real time selectively configurable rules and values for use in the determination of access decisions and are stored in a rules engine.
15. 15. The method of claim 14, wherein inputting at the first time comprises filling out an application form in response to prompts.
16. 16. The method of claim 15, wherein inputting at the second time comprises scanning a unique identifier associated with an asset.
17. 17. A system for controlling access of assets to security restricted areas within an airport, the system being substantially as shown in and/or described with reference to any one or more of figures 1 to 7 of the accompanying drawings.
18. 18. A method for determining whether access of an asset to a security restricted area within an airport should be granted, the method being substantially as shown in and/or described with reference to any one or more of figures 1 to 7 of the accompanying drawings.