Continuous authentication

Abstract

This disclosure relates to a method for determining information relating to a physical presence of a person in a surveillance area. The method comprises receiving sensor data from two or more sensors located in relation to the surveillance area; correlating the sensor data from the two or more sensors in a correlation model to calculate a correlation model output relating to the person; and based on the correlation model output, generating an indication of whether the physical presence of the person conforms to access rights of the person and / or access rules of the surveillance area.

Description

"Continuous Authentication" Cross-Reference to Related Applications

[0001] The present application claims priority from Australian Provisional Patent Application No 2024901866 filed on 19 June 2024, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0002] This disclosure relates to determining information relating to a physical presence of a person in a surveillance area, such as, but not limited to authentication, authorisation, and access control. Background

[0003] A person who is authorized to access a particular facility can provide a prove of ownership to an access control mechanism, such as by swiping a smart card on a card reader. In response, the access control mechanism authenticates the person, i.e. determines the person’s identity, and checks whether that identity has access. On success, the access control mechanism, such as a turnstiles, opens to grant access to the person. However, once the person has entered the facility, there is little visibility on that persons activities and whereabouts.

[0004] Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each of the appended claims. Summary

[0005] A method for determining information relating to a physical presence of a person in a surveillance area comprises receiving sensor data from two or more sensors located in relationto the surveillance area; correlating the sensor data from the two or more sensors in a correlation model to calculate a correlation model output relating to the person; and based on the correlation model output, generating an indication of whether the physical presence of the person conforms to access rights of the person and / or access rules of the surveillance area.

[0006] In some embodiments, the correlation model output comprises identity of the person and spatiotemporal context relating to the person.

[0007] In some embodiments, the method further comprises determining a current location of the person based on the sensor data and the current location of the person is an input to the correlation model.

[0008] In some embodiments, the method further comprises determining the identity of the person based on the sensor data.

[0009] In some embodiments, determining the current location and / or the identity of the person is performed continuously.

[0010] In some embodiments, one or more previously determined locations of the person is a further input to the correlation model.

[0011] In some embodiments, the correlation model is configured to output a predicted location of the person and the method comprises analysing one or more previously determined locations and contextual information.

[0012] In some embodiments, the sensor data is captured incidentally to the person moving through the surveillance area.

[0013] In some embodiments, the two or more sensors are of a different sensor type.

[0014] In some embodiments, receiving the sensor data comprises collecting identifying data of the person.

[0015] In some embodiments, the method comprises associating the collected identifying data to the person.

[0016] In some embodiments, the identifying data comprises a device identifier of a device carried by the person.

[0017] In some embodiments, the method further comprises extracting an identifier of the person from the identifying data.

[0018] In some embodiments, extracting the identifier comprises applying a machine learning model to the identifying data.

[0019] In some embodiments, correlating the sensor data is based on meta-data of each of the two or more sensors.

[0020] In some embodiments, the meta-data is based on observed reliability and performance of the two or more sensors.

[0021] In some embodiments, the correlation model is configured to provide situational awareness as a sequence of events relating to the person.

[0022] In some embodiments, the method further comprises calculating confidence scores for the sensor data and for the indication of whether the physical presence of the person conforms to the access rights of the person and / or access rules of the facility.

[0023] A method for continuous authentication of a person present in a facility comprises: authenticating the person upon entry into the facility; collecting data by a network of sensors distributed throughout the facility and configured to capture data related to interactions and movements of the person within the facility; processing the collected data to associate the collected data with the person and determine location data indicative of the location of the person; processing the determined location data with historical location data to determine a spatiotemporal state of the person in the facility; and detecting anomalies based on the spatiotemporal state of the person.

[0024] In some embodiments, the spatiotemporal state of the person is indicative of a transition of the person from a first location to a second location.

[0025] In some embodiments, the method further comprises applying a time-decay to adjust a confidence score associated with the location data over time.

[0026] In some embodiments, the method further comprises determining a confidence score for each sensor of the network and applying that confidence score to the detecting of the anomalies.

[0027] In some embodiments, the method further comprises performing a security action.

[0028] In some embodiments, the method further comprises authorising the person by checking the person’s access rights against the location data.

[0029] In some embodiments, the method further comprises, based on the authorising, selectively performing one of the steps of: (i) physically providing access to an area of the facility, or (ii) physically blocking access to the area of the facility.

[0030] In some embodiments, the method further comprises resolving conflicts in the location data.

[0031] In some embodiments, the method is performed in real-time.

[0032] In some embodiments, authenticating the person upon entry into the facility comprises checking plausibility of the person being at the entry given previously determined location information. Brief Description of Drawings

[0033] Examples will now be described with reference to the following drawings:

[0034] Figure 1 illustrates a facility.

[0035] Figure 2 illustrates a method for determining information relating to a physical presence of a person in a surveillance area, such as facility.

[0036] Figure 3 illustrates a method for continuous authentication of a person present in facility.

[0037] Figure 4 illustrates the method from Figure 3 in more detail.

[0038] Figure 5 illustrates a finite state machine (FSM), which encodes method of Figure 3.

[0039] Figure 6 illustrates a method and Figure 7 an FSM for authorising a person in a facility.

[0040] Figure 8 illustrates a method and Figure 9 an FSM for access control.

[0041] Figure 10 illustrates a system for determining information relating to a physical presence of a person in a surveillance area.

[0042] Figure 11 illustrates a network architecture for determining information relating to a physical presence of a person in a surveillance area.

[0043] Figure 12 is a first part of a flowchart for determining information relating to a physical presence of a person in a surveillance area.

[0044] Figure 13 is a second part of the flowchart from Figure 12.

[0045] Figure 14 illustrates a computer system for determining information relating to a physical presence of a person in a surveillance area. Description of Embodiments

[0046] Figure 1 illustrates a facility 100, which may also be referred to as a surveillance area. A facility 100 is any area of interest and maybe the inside of a building or outside or both. It may also be a fenced or unfenced inside or outside area or a combination thereof. The facility may be underground or elsewhere and may be a factory, commercial or officebuilding, airport, or any other facility. A person 101 is physically present within facility 100, which indicates that person 101 was able to be authenticated at an entry control mechanism 102. Person 101 carries a mobile phone 103 and a smart card 104 for authentication, such as by presenting smart card 104 to a reader.

[0047] Facility 100 comprises multiple sensors that may be arranged in a sensor network. The term ‘network’ indicates that the sensors are communicatively connected with each other and / or with another computer system, such as a central server. The computer system or server may execute an ambient intelligence engine as disclosed herein. The multiple sensors may be of different sensor type, which means they way use different physical media (light / image capture, infrared, electromagnetic signals, etc.) or may use different protocols (Wi-Fi, Bluetooth, NFC etc.) or be otherwise operating on a different basis. In this example, the sensor network comprises a Wi-Fi access point 105 that detects presence of mobile phone 103. The Wi-Fi access point 105 may report to the central server which devices are nearby, such as identified by a medium access control (MAC) address. The Wi-Fi access point 105 may also report on signal strength as an indication of distance of mobile phone 103 from the Wi-Fi access point 105.

[0048] Facility 100 further comprises a camera 106 that captures images of the inside of facility 100, some of which may capture person 101. Camera 106 may send the images or videos back to the central server or process them locally. The images may also be processed by a separate image processing computer. The image processing may comprise identifying the person 101 such as via facial recognition, gait recognition, retina recognition and other processing techniques. In other examples, camera 106 does not identify person 101 but merely provides an indication of whether any person is captured or how many persons are captured.

[0049] Facility 100 further comprises a motion sensor 107 which detects that at least one person is present in the sensing area, such as by using an infraread or heat signature. Motion sensor 107 may also be able to detect how many persons are present in the sensing area. Facility 100 also comprises a near field communication (NFC) card reader 108. The card reader 108 can read cards that are in close proximity even if they are not intentionally presented by person 101. That is, if person 101 walks past card reader 108 in close proximity,the card reader 108 can read the smart card 104 and provide the card information to the central server incidentally.

[0050] The above description provides examples of multiple sensors of different type that are present in facility 100. It is noted, however, that a wide range of sensors can be used and each sensor may be present once or multiple times. Some sensors may be able to extract identifying information, such as through facial recognition, MAC addresses, card details etc., while other sensors are not able to do so and provide more general information of whether or not a person is present, for example.

[0051] Facility 100 may also provide a further access control mechanism 109 that is operated by the central server dependent on data from the sensor network. More particularly, the central server determines whether person 101 is physical present near access control mechanism 109 and whether person 101 is authorised to enter. If that is so, the central server controls access control mechanism 109 to open the door, for example. The central server may be implemented as described with reference to Figure 14.

[0052] Figure 2 illustrates a method 200, as executed by the central server, for determining information relating to a physical presence of a person in a surveillance area, such as facility 100. The information relating to the physical presence may relate to authentication, authorisation, access control and other uses cases. Method 200 comprises receiving 201 sensor data from two or more sensors located in relation to the surveillance area. As described above, the sensors may be located in the facility and may sense various aspects of the person 101 present in the facility 100. Method 200 then correlates 202 the sensor data from the two or more sensors in a correlation model. The correlation model calculates a correlation model output relating to the person. Based on the correlation model output, the method 200 generates 203 an indication of whether the physical presence of the person conforms to access rights of the person and / or access rules of the surveillance area.

[0053] Since the sensor data is collected continuously, the correlation calculation and the indication can be generated continuously, which is an advantage over other methods that rely on a single point or limited points of user action, such as the user swiping an access card.

[0054] In one example, the correlation model output comprises the identity of the person and spatiotemporal context relating to the person. This means that the correlation model may extract the identity of the person from the sensor data, such as through sensed identifiers (e.g., MAC address), image recognition or others. The spatiotemporal context may comprise a location and a time for that location (i.e. when and where). Spatiotemporal context may also comprise more complex aspects, like transitions between locations or a period of time during which the person remained at a specific location and others.

[0055] In one example, the server determines a current location of the person based on the sensor data and the current location of the person is an input to the correlation model. For example, the server may have stored location data associated with each sensor and when that sensor senses the person, the server determines that the person is at or near that sensor location. This enables the location determination without the person or the person’s devices sending location data, such as global positioning (GPS) data. Further, as mentioned above, receiving the sensor data may comprise collecting identifying data of person 101. Identifying data comprises any data that is linked or linkable to person 101. The identifying data may be a device identifier, facial image data, gait signature, iris scan, visual tag (such as a quick response (QR) code) or other data. The server determines the identity of the person based on the sensor data. In some examples, the server stores an association between identifiers, such as device identifiers, including MAC addresses, and person identifiers. This association may be provided by way of configuring the system and setting up users in the system. In other examples, the server learns the association. For example, the server determines that a particular MAC address is present in most instances where the particular person identified themselves when entering the facility.

[0056] It is noted again that determining the current location or the identity or both of the person is performed continuously. This means that as the person 101 moves through the facility 100, the location and identity is determined multiple times and may be determined without additional trigger events. This may mean that the rate of identity and / or location determination is greater than the rate of a potential status change of the person. In some examples, continuous determination means every 1 s or every 10 s since a person is not reasonably expected to move significantly in such a short period of time.

[0057] Once the location of a person is determined multiple times, those previously determined locations can be used as a further input to the correlation model. This means that the correlation model becomes a temporal model that models the behaviour of person 101 over time. As a result, the correlation model can output a predicted location of the person given the inputs of current and previous locations. This enables the server to analyse the previously determined locations and contextual information and detect anomalies as described in more detail further below.

[0058] It is noted that the sensor data is captured incidentally to the person moving through the surveillance area, which means that person 101 is not required to actively provide identification, such as by swiping an access card. Instead, the server authenticates person 101 continuously and as person 101 moves through facility 100.

[0059] In one example, the server extracts the identifier by applying a machine learning model to the identifying data. This may comprise applying a convolutional neural network or transformer model to the image data or a decision tree on other machine learning model to a device identifier. Further, the identifying data captured by the sensor may also be a pattern in the sensor data that is specific to person 101. This pattern can be detected by a machine learning model such as a recurrent neural network.

[0060] Further, the step of correlating the sensor data may be based on meta-data of each of the two or more sensors. That is, the correlation model may ingest the meta-data, which indicates to the model any particularities of a specific sensor. For example, the sensor type (Wi-Fi, Bluetooth, camera, etc.) may an input to the correlation model. In cases where the correlation model is a machine learning model, its parameters are adjusted during training to reflect the influences of the sensor types on the output of the model. In another example, the meta-data is based on observed reliability and performance of the two or more sensors. For example, the meta-data may contain parameter values that indicate observed reliability and performance of the corresponding sensor. The values may be pre-set for each sensor type or automatically adjusted depending on the performance and reliability measured during operation of the sensor.

[0061] In yet another example, the correlation model provides situational awareness as a sequence of events relating to the person. That is, the correlation model outputs a datastructure that represents the sequence of events. An event is an observable effect caused by actions of the person. For example, each event may indicate movement of the person or an action of that person.

[0062] In a further example, the method may calculate confidence scores for the sensor data and for the indication of whether the physical presence of the person conforms to the access rights of the person and / or access rules of the facility. That is, the model output also comprises an indication of how confident or reliable the output value is. As a result, the alerts or actions, such as granted or refusing access or raising an alert, may be conditional on the confidence score. That is, the action may only be taken if the confidence score is a above a predetermined threshold.

[0063] Figure 3 illustrates a method 300 for continuous authentication of person 101 present in facility 100 as per the scenario above. Figure 4 illustrates method 300 in more detail and Figure 5 illustrates a finite state machine (FSM), which encodes method 300. Method 300 comprises authenticating 301 the person upon entry into the facility such as by entry control mechanism 102. This step may involve the reading of a smart card, access card, biometric authentication and other methods. Method 300 then further comprises collecting 302 data by the network of sensors distributed throughout the facility 100. As described above the network of sensors is configured to capture data related to interactions and movements of the person within the facility. In this sense, as person 101 moves through the facility 100, the sensors generate data that is specific to the person’s movement. Also, the person interacts with facility 100 either implicitly or unintentionally by bringing biometric features or devices close to the sensors. In other cases, person 101 interacts with facility 100 explicitly or intentionally, such as by swiping a card.

[0064] The method 300 further comprises processing 303 the collected data to associate the collected data with the person and determine location data indicative of the location of the person. As described above, this may involve extracting or inferring identifying data that enables the association between the data and the person. Then, the location of the sensor can be used to determine the location of the person.

[0065] Method 300 also comprises processing 303 the determined location data with historical location data to determine a spatiotemporal state of the person in the facility anddetecting 304 anomalies based on the spatiotemporal state of the person. The spatiotemporal state of the person may indicative of a transition of the person from a first location to a second location as described in further detail below. In further examples, a time-decay may be applied to adjust a confidence score associated with the location data over time so that the confidence score decreases over time. This favours sensor data that is more recent over older sensor data. In that sense, the method may determine a confidence score for each sensor of the network and apply that confidence score to the detecting of the anomalies. As a result, low confidence sensors are considered in circumstances where the high confidence sensors do not provide sufficient information.

[0066] The output of the method may lead to performing a security action. This may include activating an alarm, locking or unlocking access mechanisms, such as doors and turnstiles, starting surveillance actions, such as an active recording of security cameras, or digital actions, such as locking access to computer terminals in the facility or stopping one or more operations of the facility.

[0067] The output of method 300 may also comprise authorising the person by checking the person’s access rights against the location data. In that case, method 300 may be performed without the last step of detecting anomalies but instead selectively authorising the person. It can also be said that the authorisation is provided in response to determining that no anomaly is detected. Based on the authorising, it is then possible to selectively perform one of the steps of: (i) physically providing access to an area of the facility, or (ii) physically blocking access to the area of the facility.

[0068] In some examples, there may be conflicts in the location data, such as person 101 being in two places at the same time or in two distant places within a short time period that is too short to plausibly have moved between the two places. The conflict can be resolved by disregarding some location data or disregarding the sensor data based on a confidence score so that low confidence sensor data is disregarded, for example. Method 300 also enables to check, when the person is authenticated upon entry into the facility, plausibility of the person being at the entry given previously determined location information. This can prevent a person from giving their access card to a second person, for example. Further details on continuous authentication are provided in the following part of the disclosure.Continuous authentication

[0069] The continuous authentication functionality described in this disclosure enables that user identities are continuously verified throughout their presence within a smart facility. This functionality is advantageous for maintaining high-security standards and preventing unauthorised access, even after the initial authentication process at the facility's entrance. The process begins with the initial authentication of users at the facility's entrance. High- confidence methods such as biometric verification or secure ID cards are employed to verify each individual's identity. This initial step is used to establish a trusted baseline for further monitoring and verification processes within the facility.

[0070] Once users are authenticated, the continuous authentication system leverages the network of sensors distributed throughout the facility to collect data dynamically. These sensors include near field communication (NFC), radio frequency identifier (RFID), cameras, motion detectors, and biometric scanners, each capturing various aspects of user interactions and movements. The raw data from these sensors is transmitted to the central processing unit for further analysis. One part of the continuous authentication system is an Ambient Intelligence Engine (AIE). The AIE processes the raw sensor data to determine users' precise locations and monitor their activities in real-time. This process involves several sophisticated algorithms and modules working in tandem.

[0071] One module is a Base Layer User Location Module, which transforms raw sensor data into detailed user location data. This module associates sensor data with registered users and determines their locations based on where the sensors are installed in the facility. The output is structured data, including user IDs, confirmed locations, associated sensor IDs, and timestamps. Following the initial location determination, the User State / Transition Definitions Module defines each user's current state. Based on the temporal and spatial data collected, this module classifies users as either "Transition" (moving between locations) or "Stationary" (remaining in one location). The state definition is critical for understanding user behaviour and detecting anomalies that indicate unauthorised activities.

[0072] The system also incorporates a Time-Decay Mechanism Module to dynamically adjust the confidence scores of user location data over time. As time elapses since the last sensor data update, the confidence in the accuracy of the location data decreases. Conversely,if new data is continuously collected, the confidence increases. This mechanism ensures the system remains accurate and reliable, even without continuous data. Another part of continuous authentication is anomaly detection. The AIE constantly analyses user behaviour and movement patterns to identify deviations from the norm. For instance, if a user is detected in a location where they are not supposed to be or if there is a sudden, unexpected movement, the system flags these as potential security breaches. The Behavioural Analytics component plays a significant role, using machine learning algorithms to detect inconsistencies and unusual behaviour.

[0073] When the system detects a mismatch or suspicious activity, it triggers immediate security actions. These actions can include sending alerts to security personnel, locking down specific areas, or initiating further verification processes. The goal is to promptly address potential threats and prevent unauthorised access or activities within the facility.

[0074] The continuous authentication functionality is integrated seamlessly with other components of the disclosed system, such as authorisation and enhanced access control. This integration ensures a holistic approach to security, where user identities are verified at entry points and continuously throughout their presence in the facility.

[0075] The primary benefits of continuous authentication include enhanced security, reduced risk of unauthorised access, and improved trust among users and stakeholders. By continuously monitoring and verifying user identities, the system provides a robust security framework that is proactive and responsive to potential threats.

[0076] In summary, continuous authentication leverages advanced sensor networks, real- time data processing, and sophisticated algorithms to ensure that user identities are continuously verified within smart facilities. This functionality is crucial for maintaining high-security standards and preventing unauthorised access, thereby enhancing the overall safety and security of the facility. The continuous authentication protocol may be formulated as follows: 1. Initial Authentication: • Objective: Establish a trusted baseline for user identity verification. • Process: 1. The user presents credentials at the facility entrance.2. The system employs high-confidence methods such as biometric verification (e.g., fingerprint, facial recognition) or secure ID cards. 3. User identity is verified against the stored database. 4. If authentication is successful, user is granted entry; otherwise, access is denied. • Data Flow: Entry Point → Credential Verification System → User Database → Access Decision. ata Collection: • Objective: Collect dynamic data to monitor user activities continuously.•Process: 1. Once authenticated, the user is tracked using a network of sensors, including NFC, RFID, cameras, motion detectors, and biometric scanners. 2. Sensors capture various aspects of user interactions and movements. 3. Raw sensor data is transmitted to the central processing unit. • Data Flow: Sensors → Data Aggregators → Central Processing Unit. ata Processing: • Objective: Analyse raw data to determine precise user locations and activities.•Process: 1. The Ambient Intelligence Engine (AIE) processes the raw sensor data. 2. The Base Layer User Location Module transforms raw data into detailed user location data. 3. User locations are determined based on sensor positions within the facility. • Data Flow: Central Processing Unit → Ambient Intelligence Engine → Base Layer User Location Module. ser State and Transition Analysis:•Objective: Define the current state of each user.•Process: 1. The User State / Transition Definitions Module classifies users as either "Transition" or "Stationary." 2. This classification is based on temporal and spatial data. • Data Flow: User Location Data → User State / Transition Definitions Module. ime-Decay Mechanism: • Objective: Dynamically adjust confidence scores of user location data over time. • Process: 1. Confidence scores decrease over time if no new data is collected. 2. Confidence scores increase with continuous data collection. • Data Flow: User Location Data → Time-Decay Mechanism Module. nomaly Detection: • Objective: Identify deviations from normal user behaviour. • Process: 1. The AIE constantly analyses user behaviour and movement patterns. 2. The Behavioural Analytics component detects inconsistencies and unusual behaviour using machine learning algorithms.•Data Flow: User Behaviour Data → Ambient Intelligence Engine → Behavioural Analytics. ecurity Actions:•Objective: Address potential threats and prevent unauthorised access. • Process: 1. Upon detecting a mismatch or suspicious activity, the system triggers security actions such as sending alerts, locking down areas, or initiating further verification. • Data Flow: Anomaly Detection → Security Actions.

[0077] In summary, the method is for user authentication and activity monitoring in a facility. The method begins with an initial authentication phase, the objective of which is to establish a trusted baseline for user identity verification. In this phase, the user presents credentials at the facility entrance. The system employs high-confidence methods such as biometric verification (e.g., fingerprint, facial recognition) or secure ID cards. The user’s identity is then verified against a stored database. If the authentication is successful, the user is granted entry; otherwise, access is denied. The data flow in this phase is from the Entry Point to the Credential Verification System, then to the User Database, and finally to the Access Decision.

[0078] Following successful authentication, the method proceeds to the data collection phase. The objective of this phase is to continuously monitor user activities by collecting dynamic data. Once authenticated, the user is tracked using a network of sensors, including NFC, RFID, cameras, motion detectors, and biometric scanners. These sensors capture various aspects of user interactions and movements. The raw sensor data is then transmitted to the central processing unit. The data flow in this phase is from the Sensors to the Data Aggregators, and then to the Central Processing Unit.

[0079] The next phase is data processing, where the objective is to analyse the raw data to determine precise user locations and activities. The Ambient Intelligence Engine (AIE) processes the raw sensor data. The Base Layer User Location Module then transforms this raw data into detailed user location data. User locations are determined based on sensor positions within the facility. The data flow in this phase is from the Central Processing Unit to the Ambient Intelligence Engine, and then to the Base Layer User Location Module.

[0080] The method then proceeds to the user state and transition analysis phase. The objective of this phase is to define the current state of each user. The User State / Transition Definitions Module classifies users as either “Transition” or “Stationary.” This classificationis based on temporal and spatial data. The data flow in this phase is from the User Location Data to the User State / Transition Definitions Module.

[0081] Next, the method includes a time-decay mechanism phase. The objective of this phase is to dynamically adjust the confidence scores of user location data over time. Confidence scores decrease over time if no new data is collected, and increase with continuous data collection. The data flow in this phase is from the User Location Data to the Time-Decay Mechanism Module.

[0082] The method also includes an anomaly detection phase. The objective of this phase is to identify deviations from normal user behaviour. The AIE constantly analyses user behaviour and movement patterns. The Behavioural Analytics component detects inconsistencies and unusual behaviour using machine learning algorithms. The data flow in this phase is from the User Behaviour Data to the Ambient Intelligence Engine, and then to the Behavioural Analytics.

[0083] Finally, the method includes a security actions phase. The objective of this phase is to address potential threats and prevent unauthorised access. Upon detecting a mismatch or suspicious activity, the system triggers security actions such as sending alerts, locking down areas, or initiating further verification. The data flow in this phase is from the Anomaly Detection to the Security Actions. This comprehensive method ensures robust user authentication and activity monitoring in a facility. Authorisation

[0084] Figure 6 illustrates a method and Figure 7 an FSM for authorising person 101 in facility 101. The authorisation functionality ensures that authenticated users only access areas they are permitted to within a smart facility. By dynamically tracking user movements and verifying access rights in real time, the system provides a robust security layer that prevents unauthorised access and maintains strict control over user activities within the facility. Once users are authenticated and their identities are continuously verified, the authorisation system monitors their movements within the facility. This is achieved through a network of sensors placed strategically throughout the premises, including NFC, RFID, cameras, and motiondetectors. These sensors provide real-time data on users' locations and movements, which is essential for dynamic authorization.

[0085] Part of the authorisation functionality is the Dynamic Authorization Engine, which continuously checks each user's access rights against a secure database. This database contains detailed user profiles, including their roles, permissions, and access levels for different areas within the facility. As users move from one area to another, the system verifies their access rights in real-time, ensuring that they are only allowed into locations they are authorised to enter. The verification process involves comparing the user's current location and intended destination with their access permissions. If the user has the required access rights, the system grants them entry. If not, the system denies access and may trigger security alerts.

[0086] The Physical Constraint Analysis Module is another component of the authorisation functionality. This module defines valid user transitions between different areas based on the facility's physical layout and security constraints. It uses detailed information about passages, access points, and connections between various areas to map out all possible and permissible movements. By assessing each potential movement against the facility's security policies and physical layout constraints, the module ensures that users can only move between areas in logical and physically feasible ways. This helps prevent unauthorised access through unmonitored or insecure pathways.

[0087] To enhance the reliability of the authorisation process, a Dynamic Confidence Assignment Module adjusts confidence scores for each sensor based on its historical performance. Sensors that consistently provide accurate and reliable data are assigned higher confidence scores, while those with a history of errors receive lower scores. This dynamic adjustment ensures the system can trust its data to make authorisation decisions.

[0088] A Conflict Detection Module identifies and flags conflicts in sensor data to ensure data reliability and accuracy. This module detects discrepancies that could indicate unauthorised access attempts or other security breaches by comparing reports from different sensors within a given timeframe and area. For example, if a user is detected in two different locations within an unrealistically short period, the system recognises this as a conflict. Theconflict detection process involves sorting and organising location data, identifying potential conflicts, and generating conflict records for further analysis.

[0089] Once conflicts are detected, a Conflict Resolution Module evaluates and integrates multiple data sources to resolve these conflicts. This module verifies conflicting data against user access records and facility layout constraints to determine whether the discrepancies are due to errors or potential security threats. If the conflict is resolved as a data error, the system adjusts the base layer data accordingly. However, if the conflict indicates a potential security breach, the system alerts security personnel and may initiate further security measures to address the threat.

[0090] The authorisation functionality is based on real-time decision-making. The system continuously processes and analyses data from various sensors, user profiles, and access permissions to make immediate decisions regarding user movements and access requests. This capability allows the system to adjust to changing conditions and user behaviours dynamically, ensuring that security policies are enforced consistently and effectively. The system can quickly respond to potential security threats and prevent unauthorised access by making real-time decisions. The authorisation functionality integrates with continuous authentication and enhanced access control, forming a comprehensive security framework. This integration ensures that user identities are verified continuously and their access rights are enforced dynamically as they move within the facility. The authorisation functionality's benefits include enhanced security, strict enforcement of access policies, and improved operational efficiency. By dynamically tracking and controlling user movements, the system provides a robust layer of security that prevents unauthorised access and ensures compliance with security policies.

[0091] In summary, the authorization functionality leverages real-time tracking, dynamic access rights verification, and advanced conflict detection and resolution to ensure that users only access areas they are permitted to within a smart facility. This functionality enhances overall security and operational efficiency by enforcing access policies dynamically and responding quickly to potential security threats.

[0092] The Authorisation protocol may be formulated as follows:eal-Time Tracking:•Objective: Monitor user movements within the facility. • Process: 1. Sensors placed throughout the facility provide real-time data on user locations. 2. Data is essential for dynamic authorisation. • Data Flow: Sensors → Real-Time Data Processing. ccess Rights Verification: • Objective: Ensure users access only permitted areas.•Process: 1. The Dynamic Authorization Engine checks user access rights against a secure database. 2. User profiles include roles, permissions, and access levels. 3. Real-time verification ensures users move within authorised zones. • Data Flow: User Movements → Dynamic Authorization Engine → Access Rights Database. hysical Constraint Analysis:•Objective: Define valid user transitions between areas.•Process: 1. The Physical Constraint Analysis Module maps out permissible movements based on the facility layout. 2. Ensures users move in logically and physically feasible ways. • Data Flow: Facility Layout Data → Physical Constraint Analysis Module. ynamic Confidence Assignment: • Objective: Adjust confidence scores for sensors based on performance. • Process: 1. Sensors are assigned confidence scores based on historical accuracy. 2. Higher scores are given to consistently reliable sensors. • Data Flow: Sensor Data → Dynamic Confidence Assignment Module. onflict Detection: • Objective: Identify and flag conflicts in sensor data. • Process: 1. The Conflict Detection Module detects discrepancies in user movements. 2. Conflicts are flagged for further analysis.•Data Flow: Sensor Data → Conflict Detection Module. onflict Resolution: • Objective: Resolve conflicts to ensure data reliability. • Process: 1. The Conflict Resolution Module evaluates and integrates multiple data sources. 2. Conflicting data is verified against user access records and facility layout constraints. • Data Flow: Conflict Detection Records → Conflict Resolution Module. eal-Time Decision Making: • Objective: Make immediate decisions regarding user movements and access requests. • Process:1. The system continuously processes data from sensors, user profiles, and access permissions. 2. Real-time decisions ensure dynamic adjustment to user behaviours. • Data Flow: Real-Time Data → Decision-Making Module.

[0093] In summary, the protocol includes a real-time tracking system designed to monitor user movements within a facility. Sensors strategically placed throughout the facility provide real-time data on user locations, which is essential for dynamic authorization. The data flow involves sensors transmitting real-time data for processing. Access rights verification is another component, ensuring users access only permitted areas. The Dynamic Authorization Engine checks user access rights against a secure database, which includes user profiles with roles, permissions, and access levels. Real-time verification is conducted to ensure users move within authorized zones, with data flowing from user movements to the Dynamic Authorization Engine and then to the Access Rights Database.

[0094] Physical constraint analysis defines valid user transitions between areas, with the Physical Constraint Analysis Module mapping out permissible movements based on the facility layout. This ensures users move in logically and physically feasible ways, with data flowing from the facility layout data to the Physical Constraint Analysis Module. Dynamic confidence assignment adjusts confidence scores for sensors based on performance. Sensors are assigned confidence scores reflecting their historical accuracy, with higher scores given to consistently reliable sensors. The data flow for this process involves sensor data being evaluated by the Dynamic Confidence Assignment Module.

[0095] Conflict detection identifies and flags conflicts in sensor data. The Conflict Detection Module detects discrepancies in user movements and flags conflicts for further analysis, with data flowing from sensor data to the Conflict Detection Module. Conflict resolution ensures data reliability by resolving conflicts. The Conflict Resolution Module evaluates and integrates multiple data sources, verifying conflicting data against user access records and facility layout constraints. The data flow here involves conflict detection records being processed by the Conflict Resolution Module. Finally, real-time decision-making is employed to make immediate decisions regarding user movements and access requests. The system continuously processes data from sensors, user profiles, and access permissions, ensuring dynamic adjustment to user behaviours. The data flow for decision-making involves real-time data being processed by the Decision-Making Module.Enhanced Access Control

[0096] Figure 8 illustrates a method and Figure 9 an FSM for access control. The enhanced access control functionality adds a sophisticated layer of security to ensure that only authorised users can access specific areas within a smart facility. By combining traditional credential verification with advanced contextual location analysis, this functionality effectively deters credential misuse and enhances overall security. A part of enhanced access control is the process of credential verification. When a user attempts to access a secure area, they present credentials such as an NFC card, RFID tag, or biometric identifier (e.g., fingerprint or facial recognition). This credential is then verified against stored data in a secure database. The system proceeds to the next verification step if the credential is valid.

[0097] To prevent misuse of credentials, such as borrowing or theft, the system introduces an additional layer of verification based on the user's last known location. This involves contextual analysis using Ambient Intelligence Engine (AIE) data. When a user presents a credential at an access point, the system retrieves the last known location of the credential holder. The system checks if the credential holder's last known location logically corresponds to the current access request location. Access is granted if the locations match or are nearby, indicating that the user could have reasonably moved from the last known location to the access point. Access is denied if there is a significant discrepancy, suggesting potential misuse of the credential. This approach helps prevent unauthorised access through stolen or borrowed credentials.

[0098] Enhanced access control also involves detecting and resolving conflicts in sensor data to ensure data reliability and accuracy. The Conflict Detection Module identifies discrepancies in user movements and access attempts. For example, if a user is detected at two different locations within an unrealistically short period, the system recognises this as a conflict. The Conflict Resolution Module then evaluates these conflicts by integrating multiple data sources and verifying the data against user access records and facility layout constraints. The system adjusts the data accordingly if the conflict is due to a data error. If the conflict suggests a potential security threat, security personnel are alerted, and further security measures may be initiated.

[0099] The Time-Decay Mechanism Module plays a role in adjusting confidence scores of user location data over time. As time elapses since the last sensor data update, the confidence in the accuracy of the location data decreases. Conversely, continuous data collection increases confidence levels. This mechanism ensures that the system remains accurate and reliable, even when data updates are intermittent. To further enhance data reliability, the Dynamic Confidence Assignment Module dynamically adjusts confidence scores for each sensor based on historical performance. Sensors with a history of accurate readings are assigned higher confidence scores, while those with a history of errors receive lower scores. This dynamic adjustment ensures the system relies on the most trustworthy data when making access control decisions.

[0100] Enhanced access control uses real-time decision-making capabilities. The system continuously processes and analyses data from various sensors, user profiles, and access permissions to make immediate decisions regarding access requests. This capability allows the system to adjust to changing conditions and user behaviours dynamically, ensuring that security policies are enforced consistently and effectively. Upon successfully verifying credentials and contextual location, the system sends signals to physical control mechanisms such as electronic locks and barriers to grant or deny access. This integration with physical security systems ensures that only authorised users can enter secure areas, providing a robust and tangible layer of security.

[0101] The enhanced access control functionality is integrated with continuous authentication and dynamic authorisation, forming a comprehensive security framework. This integration ensures that user identities are continuously verified and that their access requests are validated against contextual data and real-time conditions. The benefits of enhanced access control include increased security, prevention of credential misuse, and improved trust among users and stakeholders. By verifying both the credentials and the contextual integrity of access requests, the system significantly reduces the risk of unauthorised access and enhances the facility's overall safety.

[0102] In summary, the enhanced access control functionality combines credential verification with advanced contextual location analysis to prevent unauthorised access within a smart facility. This approach enhances security by ensuring that access requests arevalidated against the presented credentials and the user's last known location, thereby deterring misuse and improving overall trust in the system.

[0103] The access control protocol may be formulated as follows: 1. Credential Verification: • Objective: Verify user credentials at access points. • Process: 1. Users present credentials (e.g., NFC card, RFID tag, biometric identifier). 2. Credentials are verified against stored data in a secure database. • Data Flow: Credentials → Credential Verification System → User Database. 2. Location-Based Verification: • Objective: Prevent misuse of credentials through contextual analysis. • Process: 1. The system retrieves the last known location of the credential holder. 2. The current access request location is checked against this data. 3. Access is granted if locations match or are nearby. 4. Access is denied if there is a significant discrepancy. • Data Flow: Credential Verification → Last Known Location Data → Contextual Verification. 3. Conflict Detection and Resolution: • Objective: Detect and resolve conflicts in sensor data. • Process: 1. The Conflict Detection Module identifies discrepancies in user movements. 2. The Conflict Resolution Module integrates multiple data sources to resolve conflicts. 3. Data is adjusted if the conflict is due to an error. 4. Security personnel are alerted if a potential security threat is identified. • Data Flow: Sensor Data → Conflict Detection Module → Conflict Resolution Module. 4. Time-Decay Mechanism: • Objective: Adjust confidence scores of user location data over time. • Process: 1. Confidence scores decrease over time without new data. 2. Continuous data collection increases confidence levels. • Data Flow: User Location Data → Time-Decay Mechanism Module. 5. Dynamic Confidence Assignment: • Objective: Dynamically adjust confidence scores for each sensor. • Process: 1. Sensors are assigned scores based on historical performance. 2. Reliable sensors receive higher scores, while error-prone sensors receive lower scores. • Data Flow: Sensor Data → Dynamic Confidence Assignment Module. 6. Real-Time Decision Making: • Objective: Make immediate access control decisions.•Process: 1. The system continuously processes and analyses data from sensors, user profiles, and access permissions. 2. Immediate decisions are made regarding access requests. • Data Flow: Real-Time Data → Decision-Making Module. 7. Physical Access Mechanisms: • Objective: Control physical access based on verified credentials and contextual data. • Process: 1. Upon successful verification, signals are sent to physical control mechanisms (e.g., electronic locks, barriers) to grant or deny access. • Data Flow: Verification Results → Physical Control Mechanisms.

[0104] In summary, credential verification is achieved by presenting user credentials, such as NFC cards, RFID tags, or biometric identifiers, which are then verified against a secure database. The process ensures that only authenticated users gain access, with a data flow from the credentials to the verification system and ultimately to the user database. Location-based verification is designed to prevent credential misuse through contextual analysis. It involves retrieving the last known location of the credential holder and comparing it with the current access request location. Access is granted if the locations are consistent or in proximity, and denied if there is a significant discrepancy, ensuring secure and context-aware access control. Conflict detection and resolution are used for maintaining the integrity of sensor data. Discrepancies in user movements are identified by a conflict detection module, and a conflict resolution module integrates multiple data sources to resolve these conflicts. Adjustments are made to the data if errors are detected, and security personnel are alerted in case of potential security threats.

[0105] The time-decay mechanism adjusts the confidence scores of user location data over time, with scores decreasing in the absence of new data and increasing with continuous data collection. This mechanism ensures that the confidence in the location data remains current and accurate. Dynamic confidence assignment is employed to adjust confidence scores for each sensor based on their historical performance. Sensors with a reliable track record receive higher scores, while those prone to errors are assigned lower scores, allowing for a more nuanced and accurate assessment of sensor data. Real-time decision-making is facilitated by continuously processing and analyzing data from sensors, user profiles, and access permissions. This enables the system to make immediate and informed decisions regarding access requests, ensuring timely and secure access control.

[0106] Physical access mechanisms control access based on verified credentials and contextual data. Upon successful verification, signals are sent to control mechanisms, such as electronic locks or barriers, to grant or deny access, thereby providing a secure and automated physical access control system.

[0107] Figure 10 illustrates a system 1000 for determining information relating to a physical presence of a person in a surveillance area, such as for continuous authentication, authorisation and access control. System 1000 comprises a base layer user location module 1001, a user state / transition definitions module 1002, a physical constraint analysis module 1003, a time-decay mechanism module 1004, a dynamic confidence assignment module 1005, a weighted data module 1006, a conflict detection module 1007, a conflict resolution module 1008, a data correlation and a validation module 1009. The modules are designed to transform raw sensor data into detailed user location data by associating it with registered users and determining their location based on sensor installation within a facility. The modules process inputs such as facility layout data, user data, and sensor raw data to produce structured location data that includes user IDs, confirmed locations, associated sensor IDs, and timestamps.

[0108] The modules perform several steps, starting with initializing and parsing inputs, processing each sensor data entry, and compiling output data. It involves extracting sensor information, associating sensor data to users, calculating locations, and storing the processed data for further use and real-time monitoring. Additionally, there are modules such as the User State / Transition Definitions Module, which defines the current state of a user as either "Transition" or "Stationary" based on temporal and spatial data, and the Physical Constraint Analysis Module, which defines valid user transitions within the facility based on the physical layout and security constraints.

[0109] The Time-Decay Mechanism Module dynamically adjusts the confidence scores of user location data over time, while the Dynamic Confidence Assignment Module adjusts confidence scores for each sensor based on historical performance. The Weighted Data Module assigns reliability scores to data from individual sensors, and the Conflict Detection Module identifies and flags conflicts in sensor data to ensure data reliability and accuracy. Assuch, system 1000 monitors and analyses user location within a facility, utilizing various algorithms and modules to ensure the accuracy and reliability of the data collected.

[0110] The following algorithms are performed by the respective modules:

[0111] Base Layer User Location Module Algorithm Objective: Transform raw sensor data into detailed user location data by associating it with registered users and determining their location based on where sensors are installed in the facility. Inputs: • Facility Layout Data: Information about sensor locations and their respective access control points. • User Data: Registration details, including user credentials linked to specific sensors (NFC ID, RFID ID, FPR ID, etc.). • Sensor Raw Data: Data from sensors capturing user interactions, including sensor IDs, detected data (user credentials), and timestamps. Outputs: • Base Layer Location Data: Structured data that includes user IDs, their confirmed locations, associated sensor IDs, and timestamps. Algorithm Step 1: Initialize and Parse Inputs • Extract sensor installation details from the facility layout data. • Load user registration and credential information. Step 2: Process Each Sensor Data Entry For each entry in the sensor raw data: 1. Extract Sensor Information: • Identify the sensor ID, captured user credentials, and the timestamp from the raw data. 2. Associate Sensor Data to User: • Match the captured credentials (e.g., NFC ID, RFID ID, FPR ID) against the user data to find a corresponding registered user ID. • If no matching user is found, consider the data as belonging to an unidentified or potentially unauthorised user. 3. Calculate Location: • Use the sensor ID to reference the facility layout data and determine the exact location of the sensor. • Assign this location to the user for the timestamp of the sensor interaction. Step 3: Compile Output Data • For each processed sensor data entry, construct a record in the Base Layer Location Data format: • User ID: The identified or default 'unidentified' user ID. • Location: The location derived from the sensor's position in the facility. • Sensor ID: The ID of the sensor that captured the data. • Timestamp: The time at which the sensor interaction was recorded. Step 4: Output the Processed Data• Store the compiled Base Layer Location Data for further processing and real-time monitoring. In a mathematical form, the algorithm can be written as follows: Inputs • ^^ = {^^1, ^^2, …, ^^^^}: Set of all sensor data inputs, where each ^^^^contains: • id^^: Sensor ID • data^^: Data captured by the sensor • time^^: Timestamp of the capture • ^^ = {^^1, ^^2, …, ^^^^}: Set of all registered users, where each ^^^^ contains: • user_id^^: User identification number•^^ = {^^1, ^^2, …, ^^^^}: Set of all locations in the facility, with predefined sensor positions and access controls Process 1. Data Association: • For each sensor reading ^^^^, associate it with a registered user ^^^^based on the sensor data data^^. This is typically done through credential matching (e.g., RFID, NFC, Fingerprint ID). user^^ = ^^(data^^, ^^) Where ^^ is a function that matches sensor data to a user's unique identifier in the dataset ^^. 2. Location Determination: • Determine the location ^^^^of each sensor reading ^^^^using the sensor ID id^^which corresponds to a specific location in the facility layout ^^. loc^^= ^^(id^^, ^^) Where ^^ is a function that maps each sensor ID to its physical location in ^^. 3. Output Generation: • For each valid sensor reading, generate an output entry combining the user ID, location, and timestamp. ^^ = {(user^^, loc^^, time^^)∣^^=1, 2, …, ^^} This set ^^ constitutes the base layer location data. Mathematical Description of Functions • ^^: Data × Users → Users • ^^ takes sensor data and a set of registered users, and returns the user associated with the data. • ^^: SensorIDs × Locations → Locations • ^^ takes a sensor ID and a set of locations, and returns the specific location associated with the sensor ID. Output • ^^ = {^^1, ^^2, …, ^^^^} • Each output ^^^^ is a tuple consisting of: (user^^, loc^^, time^^) Where user^^ is the user identified at the location loc^^ at time time^^.

[0112] User State / Transition Definitions Module Algorithm Objective: Define the current state of a user as either "Transition" (moving between locations) or "Stationary" (remaining in one location), based on the temporal and spatial data collected.Inputs: • Facility Layout Data: Information on how different areas of the facility are connected, which can influence user movement paths. • Base Layer Location Data: Detailed records of user locations at specific timestamps derived from sensor data. Outputs: • User State Data: Detailed records that classify each user's state as either "Transition" or "Stationary," including user ID, state, current location, and timestamp. Algorithm Step 1: Initialize and Validate Inputs • Load facility layout to understand passage connections and permissible movements. • Prepare the stream of base layer location data for processing. Step 2: Sort and Process Location Data • Sort the base layer location data by user ID and timestamp to process movements chronologically. • Initialize variables to store the previous location and timestamp for each user to compare movements. Step 3: Determine User State for Each Data Entry For each sorted entry in the base layer location data: 1. Extract Current Data: • User ID, current location, and timestamp. 2. Check Previous Data: • Retrieve the last known location and timestamp for the user (if it exists). 3. Compare Current and Previous Locations: • If the current location is different from the last known location and the time difference between the two points is consistent with moving, classify the user as "Transition". • If the location is the same or the time difference is very short (indicating no actual movement), classify the user as "Stationary". 4. Update Previous Location and Timestamp: • Update the last known location and timestamp for the user with the current data for subsequent comparisons. Step 4: Compile User State Output Data • Construct records for each user indicating their state, current location, previous location, and timestamp. Step 5: Output the Processed Data • Store the compiled User State Data for monitoring and further processing. In a mathematical form, the algorithm can be written as follows: Inputs • ^^ = {^^1, ^^2, …, ^^^^}: Set of all base layer location data entries, where each ^^^^ contains: • user_id^^: User identification number • loc^^: Current location of the user • time^^: Timestamp of the user's location data • ^^ = {^^1, ^^2, …, ^^^^}: Set of all passages within the facility, where each ^^^^defines connections between locations: • from^^: Start location of the passage• to^^: End location of the passage Process 1. Sort Data by User and Time: • Organize ^^ by user_id and time to facilitate sequential analysis of each user's movements. ^^^^^^^^^^^^^^ = sort(^^, by = [user_id, time]) 2. Define User State: • Iterate through ^^^^^^^^^^^^^^ for each user to define their state based on the comparison of consecutive location entries. • For each pair of consecutive data points (^^^^, ^^^^+1) for the same user: state^^= ℎ(^^^^, ^^^^+1, ^^) Where ℎ is a function that checks if loc^^ and loc^^+1 are connected directly or via a passage in ^^. If connected, the user is "in transition"; if the same, the user is "stationary". 3. Transition Logic: • ℎ examines if two consecutive locations are connected:4. Output State Data: • Generate an output for each data point reflecting the user's state: ^^ = {(^^^^, state^^)∣^^=1, 2, …, ^^−1} Mathematical Description of Functions • ℎ : Location × Location × Passages → States • ℎ determines the relationship between consecutive locations based on the passages configuration. Output • ^^ = {^^1, ^^2, …, ^^^^−1} • Each output ^^^^ is a tuple: (user_id^^, state^^, loc^^, time^^) Where state^^indicates whether the user is transitioning or stationary.

[0113] Physical Constraint Analysis Module Algorithm Objective: Define valid user transitions between different areas within the facility based on the physical layout and security constraints. Inputs: • Facility Layout Data: Contains detailed information about passages, access points, and connections between various areas within the facility. Outputs: • Valid User Transitions: A list of permissible transitions from one location to another, indicating whether movement between these areas is allowed. Algorithm Step 1: Initialize and Validate Inputs • Load the facility layout data, which should include details about each area's connections, such as doors, hallways, and restricted zones.Step 2: Analyse Facility Layout • Analyse each area and its connections to other areas to understand how users can logically and physically move from one point to another. Step 3: Define Valid Transitions For each area in the facility layout: 1. List Connections: • Identify all direct connections to other areas, as defined in the layout data. 2. Determine Accessibility: • For each connection, determine if the transition is allowed based on security levels, the presence of doors or gates, and other physical or security barriers. 3. Record Valid Transitions: • For each permissible transition, record the starting area, the destination area, and whether the transition is open (unrestricted) or secure (restricted or controlled). Step 4: Compile Transition Data • Construct a detailed list of all valid transitions, indicating the from-to relationships and the type of each transition (open or secure). Step 5: Output the Processed Data • Store the compiled Valid User Transitions data for use in other modules. In a mathematical form, the algorithm can be written as follows: Inputs • ^^ = {^^1, ^^2, …, ^^^^}: Set of all locations within the facility. • ^^ = {^^1, ^^2, …, ^^^^}: Set of all connections between locations, where each ^^^^ contains: • from^^: Start location of the connection. • to^^: End location of the connection. • type^^: Type of connection, e.g., 'open', 'secure'. Process 1. Define Valid Transitions: • Map out all possible and permissible movements between locations based on the types of connections. This involves assessing each ^^^^ to confirm if the connection is allowable based on security policies and physical layout constraints. 2. Transition Validation Function: • Construct a matrix or a mapping function ^^ that outlines valid transitions between locations. • For each location (^^^^, ^^^^) in ^^: ^^3. Generate Valid Transition Data: • For each valid transition determined by ^^, generate a data entry that specifies the locations involved and the transition's validity: ^^ = {(from, to, validity) ∣ validity = ^^ (from, to), from, to ∈ ^^} Mathematical Description of Functions • ^^ : Locations × Locations → {True, False} • ^^ assesses each possible transition between locations and determines whether it's valid based on the facility's layout and the security level of connections. Output• Each output ^^^^ is a tuple: (from, to, validity) • Where validity indicates whether the transition between from and to is allowed.

[0114] User Movement Prediction Module Algorithm Objective: Utilize machine learning or statistical models to predict future user locations based on historical and current user movement data, facility constraints, and valid transitions between areas. Inputs: • User Location Data: Current and historical data regarding the user's location. • Predicted User Location Data: Predictions about user locations when no active sensor data is available. Outputs: • Updated User Location Confidence: Adjusted confidence levels for each piece of user location data, reflecting the reliability of the data over time. Algorithm Inputs • Base Layer Location Data (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Historical and current location data showing where users have been detected by sensors. • user_id^^ : User identification number • location^^: User's location • timestamp^^: Timestamp of the data • User Data (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Information about users that may influence their movement patterns, such as roles or schedules. • user_id^^: User identification number • role^^: Role or schedule of the user • Facility Layout Data (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Detailed information about the physical layout, including paths, restricted areas, and typical traffic flows. • User State / Transition Data (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Data on whether users are stationary or in transition, providing context for movement patterns. • user_id^^: User identification number • state^^: User state (stationary or in transition) • timestamp^^: Timestamp of the state data • Valid User Transitions (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Information about allowable movements within the facility to ensure predicted paths are feasible. • from^^: Start location of the transition • to^^: End location of the transition Process 1. Data Preprocessing: • Organize historical user location data by user and time to identify patterns in movement. • For each user, create a sequence of locations over time: ^^sorted= sort(^^, by = [user_id, timestamp]) 2. Train Movement Prediction Model: • Use historical data to train a predictive model (e.g., Markov Chain, Hidden Markov Model, or Recurrent Neural Network) to learn user movement patterns. • Model ^^ represents the probability of moving from one location to another:^^(^^, ^^^^−1, ^^^^) = ^^(location^^ ∣ location^^−1, user^^) 3. Predict Future Locations: • For each current user state ^^^^, use the trained model to predict the next probable location. • Calculate the probabilities of transitioning to adjacent areas based on current location: ^^(next_location = ^^ ∣ current_location = ^^, user = ^^) = ^^(^^, ^^, ^^) 4. Generate Prediction Output: • For each user, determine the most likely next location and generate a prediction record: ^^pred = {(user_id, current_location ,predicted_location ,timestamp) ∣ predicted_location = arg max ^^(^^ ∣ ^^, ^^), ^^^^ ∈ ^^} Mathematical Description of Functions • Sorting Function (sort): • Orders historical location data by user and time. sort : ^^ × (by = [user_id, timestamp]) → ^^sorted• Training Function (train): • Trains a predictive model using historical data. train : ^^sorted→ ^^ • Prediction Function (^^): • Predicts the next location based on the current state and historical movement patterns. ^^ : (user_id, current_location, adjacent_areas) → ^^ (next_location) Output • ^^pred= {^^1, ^^2, …, ^^^^} • Each output ^^^^is a tuple formatted as: (user_id, current_location, predicted_location, timestamp) • This data set contains the predicted next locations for each user, which can be used for proactive security measures and resource allocation.

[0115] Time-Decay Mechanism Module Algorithm Objective: Dynamically adjust the confidence scores of user location data over time, increasing or decreasing confidence based on the time elapsed since the last sensor data update and the reliability of subsequent data predictions. Inputs: • User Location Data: Current and historical data regarding the user's location. • Predicted User Location Data: Predictions about user locations when no active sensor data is available. Outputs: • Updated User Location Confidence: Adjusted confidence levels for each piece of user location data, reflecting the reliability of the data over time. Algorithm Step 1: Initialize and Validate Inputs • Load all necessary inputs, including the latest real-time location data and any predicted data available. Step 2: Implement Time-Decay Function 1. Define Decay Rate:• Establish a decay rate that appropriately reflects the expected reliability decrease over time. This could be linear, exponential, or another function, depending on the system requirements and data characteristics. 2. Apply Decay to Historical Data: • For each piece of user location data, reduce the confidence score based on the time elapsed since the data was recorded or last updated. Step 3: Adjust Predicted Data Confidence • For each piece of predicted user location data: 1. Calculate Initial Confidence: • Assign an initial confidence score based on the prediction model’s accuracy. 2. Decay Confidence Over Time: • Apply the decay function to reduce the confidence score over time, reflecting the increasing uncertainty as the prediction ages without confirmation from new sensor data. Step 4: Update Location Data Confidence • Update the stored user location data with the new, time-decayed confidence scores, ensuring that all system components use the most accurately weighted data for decision-making. Step 5: Output the Adjusted Data • Store the updated user location data with the adjusted confidence scores. In a mathematical form, the algorithm can be written as follows: Inputs • ^^ = {^^1, ^^2, …, ^^^^}: Set of all user locations over time, where each ^^^^ contains: • user_id^^: User identification number. • location^^: User's location. • timestamp^^: Timestamp when the location was recorded. • data_type^^: Type of data ('active' or 'predicted'). • initial_conf^^: Initial confidence score assigned to the location data. Process 1. Confidence Adjustment: • For each user location entry ^^^^, adjust the confidence score based on the data type: ^^. ^^^^ × ^^^^^^^^^^^^^^^^^^^^^^^^, ^^^^ = ^^^^^^^^^^^^^^^^′^^^^^^^^^^^^^^′^^. ^^^^ × ^^^^^^^^^^^^^^ , ^^^^ ^^^^^^^^=′^^^^^′^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ • Ensure that the confidence score does not exceed 100% or fall below 0%. 2. Output Generation: • For each user location data, generate an output entry that reflects the updated confidence score: ^^ = {(user_id^^, location^^, data_type^^, adjusted_confidence^^, timestamp^^) ∣ ^^ = 1, 2, …, ^^} Mathematical Description of Functions • There is no specific complex mathematical function here, but a simple conditional check and arithmetic operation based on the type of data (active or predicted). Output • ^^ = {^^1, ^^2, …, ^^^^} • Each output ^^^^ is a tuple formatted as: (user_id, location, data_type, adjusted_confidence, timestamp) • data_type indicates whether the adjustment was due to active or predicted data, and adjusted_confidence reflects the new confidence score.In a mathematical form, the algorithm can be written as follows: Inputs • ^^ = {^^1, ^^2, …, ^^^^}: Set of all sensors and their metadata, where each ^^^^contains: • sensor_id^^: Sensor identification number • type^^: Sensor type (e.g., NFC, RFID, passive infrared (PIR), etc.) • interaction^^: Interaction type (e.g., active, passive) : Data flow type (e.g., continuous, intermittent) : Initial accuracy of the sensor (percentage) • Set of all individual sensor accuracy records, where each ^^^^ Sensor identification number Total number of reads by the sensor Total number of incorrect reads^^ Timestamp of the last accuracy update Process 1. Calculate Accuracy: • For each sensor accuracy record ^^^^, calculate the sensor's accuracy:• Otherwise, use the initial accuracy from sensor metadata:2. Assign Confidence Score: • For each sensor ^^^^, update the confidence score based on the calculated accuracy: ^^^^^^^^^^^^^^^^^^, ^^^^ ^^^^^^^^^^^^^^^^ = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^ ^^^ ^ ^^^^ = {^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^, ^^^^^^^^^^^^^^^^^^3. Adjust Confidence Based on Performance: • Adjust the confidence score positively or negatively based on recent performance: • Increase by 1% for every verified correct reading. • Decrease by 1% for every incorrect reading. • Ensure confidence remains between 0% and 100%: adjusted_confidence^^= max(0, min(100, confidence^^)) 4. Output Sensor Confidence Scores: • Generate an output entry for each sensor: ^^ = {(sensor_id^^, adjusted_confidence^^, last_updated^^) ∣ ^^ = 1, 2, …, ^^} Mathematical Description of Functions • ^^ : Accuracy × Incorrect Reads → Percentage • ^^ calculates the sensor's accuracy based on total and incorrect readings. • ^^ : Sensor → Confidence Score • ^^ assigns a confidence score to each sensor based on its performance and historical data. Output • ^^ = {^^1, ^^2, …, ^^^^} • Each output ^^^^ is a tuple formatted as: (sensor_id, adjusted_confidence, last_updated) Where adjusted_confidence reflects the final confidence score after adjustments.

[0116] Dynamic Confidence Assignment Module Algorithm Objective: Dynamically adjust confidence scores for each sensor based on its historical performance, including accuracy and consistency, to refine the trustworthiness of the data they provide. Inputs: • Sensor Metadata: Information about each sensor, including type, data flow characteristics, and initial accuracy ratings. • Individual Sensor Accuracy: Historical data on the accuracy of each sensor, including the count of correct and incorrect readings. Outputs: • Sensor Confidence Scores: Updated confidence scores for each sensor, reflecting their reliability based on historical data. Algorithm Step 1: Initialize and Load Data • Load sensor metadata and historical accuracy data for each sensor in the system. Step 2: Calculate Initial Confidence • For each sensor, establish an initial confidence score based on provided metadata, such as type and intended use within the facility. Step 3: Adjust Confidence Based on Performance For each sensor: 1. Retrieve Historical Accuracy: • Get the number of correct and incorrect reads from the individual sensor accuracy data. 2. Calculate Accuracy Ratio: • Determine the accuracy ratio by dividing the number of correct reads by the total number of reads. 3. Adjust Confidence Score: • Adjust the initial confidence score based on the accuracy ratio. This involves increasing the score for high accuracy or decreasing it for low accuracy. • Apply necessary adjustments based on additional factors like sensor priority, which can be derived from the sensor metadata. Step 4: Factor in Data Timeliness • Further adjust the confidence score to account for data timeliness. For example, sensors that provide data in real-time may receive a higher score compared to those with delayed reporting. Step 5: Update Sensor Confidence • Update the confidence scores for each sensor in the system's database, ensuring that these new scores are used in subsequent data processing and decision-making tasks. Step 6: Output the Adjusted Scores • Store the updated sensor confidence scores for future reference and operational use.

[0117] Weighted Data Module AlgorithmObjective: Assign reliability scores to data from individual sensors, adjusting for their historical accuracy to enhance the overall quality of the data used in the system. Inputs: • Individual Sensor Confidence: Confidence scores for each sensor, updated dynamically based on their performance. • Sensor Metadata: Information about each sensor, including type and operational characteristics. • Base Layer Location Data: Location data generated by sensors, including the sensor ID, user ID, location, and timestamp. Outputs: • Base Layer Data Confidence: Enhanced location data that includes a confidence score for each data point, reflecting the reliability of the underlying sensor data. Algorithm Step 1: Initialize and Validate Inputs • Load the necessary data inputs, including sensor confidence scores, sensor metadata, and the base layer location data generated by the sensors. Step 2: Calculate Data Reliability For each data point in the base layer location data: 1. Retrieve Sensor Confidence: • Identify the sensor that generated the data and retrieve its current confidence score from the individual sensor confidence data. 2. Determine Data Reliability: • Assign a reliability score to the data point based on the sensor's confidence score. This might involve simple assignment or a calculation that factors in additional data such as sensor type or environmental conditions. 3. Adjust Reliability Based on Sensor Characteristics: • Consider the type of sensor and its operational context to fine-tune the reliability score. For instance, data from sensors known to be less reliable under certain conditions might have their scores adjusted downwards. Step 3: Compile Enhanced Location Data • Update each record in the base layer location data with the new reliability score, ensuring that each piece of data reflects the trustworthiness of its source. Step 4: Output the Adjusted Data • Store the enhanced base layer location data, now including confidence scores. In a mathematical form, the algorithm can be written as follows: Inputs • Base Layer Location Data (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Set of all base layer location data entries, where each ^^^^ contains: • user_id^^: User identification number • location^^: User's location • sensor_id^^: Sensor ID • timestamp^^: Timestamp of the data capture • Sensor Confidence Scores (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Set of all sensor confidence scores, where each ^^^^contains: • sensor_id^^: Sensor ID • confidence^^: Confidence score (percentage)• Sensor Metadata (^^M): • ^^ = {^^1, ^^2, …, ^^^^}: Set of all sensor metadata, where each ^^^^ contains: • sensor_id^^: Sensor ID • priority^^: Sensor priority level Process 1. Combine Data Sources: • Create a mapping of sensor confidence scores ^^: ^^ = {(sensor_id^^, confidence^^) ∣ ^^ = 1, 2, …, ^^} • Create a mapping of sensor metadata (priority) ^^: ^^ = {(sensor_id^^, priority^^) ∣ ^^ = 1, 2, …, ^^} 2. Assign Confidence Scores: • For each base layer location data entry ^^^^, assign a confidence score based on the sensor confidence and priority: ^^^^= confidence^^^^× priority^^^^Where: • confidence^^^^ = ^^[sensor_id^^^^] • priority^^^^ = ^^[sensor_id^^^^] 3. Calculate Combined Confidence for User Location: • For each user-location group (^^,^^), calculate a weighted average confidence score using the assigned scores: ^^^^^^ = ^^ ∧ ^^^^^^^^^^^^^^^^^^ = ^^ ) ^^^^= ^^ ∧ ^^^^^^^^^^^^^^^^^ = ^^ ) ^^^4. Generate Weighted Location Data Output: • For each unique user-location pair, generate an output entry reflecting the calculated weighted confidence score: ^^ = {(user_id^^, location^^, ^^(^^, ^^), timestamp^^) ∣ (^^, ^^) ∈ {(^^^^.user_id, ^^^^.location) ∣ ^^ = 1, 2, …, ^^}} Mathematical Description of Functions • Sensor Confidence Mapping Function (^^) maps sensor IDs to their respective confidence scores. ^^ : SensorID → Confidence • Sensor Priority Mapping Function (^^) maps sensor IDs to their respective priority levels. ^^ : SensorID → Priority • Weighted Confidence Calculation (^^) calculates a weighted confidence score for each user- location pair. ^^ : UserID × Location → Confidence Score Output• Each output ^^^^ is a tuple formatted as: (user_id, location, confidence, timestamp) • Where confidence is the calculated weighted confidence score.

[0118] Conflict Detection Module Algorithm Objective: Identify and flag conflicts in the sensor data to ensure data reliability and accuracy by comparing reports from different sensors within a given timeframe and area.Inputs: • Base Layer Location Data: Contains user location data generated by sensors, including the user ID, location, sensor ID, and timestamp. • Base Layer Data Confidence: Confidence levels associated with each piece of location data, indicating the reliability of the information. • Facility Layout Data: Information about the physical layout of the facility, which can affect the interpretation of sensor data. • User Access Data: Contains permissions and access rights of users, which might clarify potential conflicts. Outputs: • Conflict Detection Record: A record of detected conflicts, specifying the conflicting sensors, involved data, and the areas affected. Algorithm Step 1: Initialize and Validate Inputs • Load all necessary inputs, including the latest location data from sensors, associated confidence scores, and facility layout information. Step 2: Sort and Organize Data • Sort the base layer location data by timestamp and location to process data chronologically and contextually. Step 3: Identify and Analyze Conflicts For each set of location data entries: 1. Group Data by Location and Timeframe: • Group data points that fall within a small window of time and are reported for the same or overlapping areas. 2. Compare Entries Within Groups: • For each group, compare entries to identify any discrepancies. For instance, if two sensors report significantly different user locations or movements for the same user at the same time, this indicates a conflict. 3. Assess Data Confidence: • Use the confidence scores from the base layer data confidence to weigh the reliability of conflicting data. Higher confidence data may override lower confidence reports. Step 4: Record Conflicts • For each detected conflict, create a record in the Conflict Detection Record format: • Conflict ID: A unique identifier for the conflict. • Sensors Involved: List of sensors that have provided conflicting data. • Area Involved: The specific area(s) where the conflict was detected. • Timestamp: Time when the conflict occurred. Step 5: Output the Conflict Records • Store the conflict detection records for review and resolution by the system. In a mathematical form, the algorithm can be written as follows: Inputs • Base Layer Location Data (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Set of all base layer location data entries, where each ^^^^contains: • user_id^^: User identification number • location^^: User's location • sensor_id^^: Sensor ID• timestamp^^: Timestamp of the data capture • Base Layer Data Confidence (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Set of confidence scores for each location data entry, where each ^^^^ contains: • user_id^^: User identification number • location^^: User's location • confidence^^: Confidence score • timestamp^^: Timestamp of the data capture • Facility Layout Data (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Set of all areas within the facility, where each ^^^^contains: • area_id^^: Area identification number • ingress_egress_points^^: Set of ingress / egress points for the area • security_level^^: Security level of the area • User Access Data (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Set of all user access records, where each ^^^^contains: • user_id^^: User identification number • access_areas^^: Set of areas the user can access • access_level^^ : Access level of the user Process 1. Aggregate Base Layer Data by User and Time: a) Group the base layer location data ^^ by user and order each user's data by timestamp: ^^sorted = sort(^^, by = [user_id, timestamp]) 2. Identify Conflicting Locations: a) For each user ^^^^, compare consecutive location data points (^^^^,^^^^) to detect conflicts. b) Check the following scenarios: Tailgating / Piggybacking a) Single Credential, Multiple Entries:b) Unauthorized Presence in Restricted Areas: ∀(^^^^, ^^^^) ∈ ^^^^^^^^^^^^^^∶ { ^^^^^^^^^^^^^^^^, ^^^^ ^^^^. ^^^^^^^^^^^^^^^^ ^^^^^^ ^^^^^^^^^^^^^^^^^^^^ ^^^^ ^^^^^^^^ ^^^^^^^^^^^^ ^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^, ^^^^^^^^^^^^^^^^^^Impersonation / Identity-Theft / Spoofing / Cloning c) Cloned RFID / NFC Badges:d) Impersonation:Unauthorised Area Access e) Unauthorized Entry through Borrowed Credentials:f) Abnormal Patterns of Movement:2. Generate Conflict Records: • For each conflicting location pair, generate a conflict record: ^^ = {(conflict_id, user_id, ^^^^.location, ^^^^.location, ^^^^.timestamp, ^^^^.timestamp, sensors) ∣ sensors = {^^^^.sensor_id, ^^^^.sensor_id}} Where: g) conflict_id: Unique identifier for the conflict. Mathematical Description of Functions 1. Sort Function (sort): • Description: Orders a set of base layer location data by user ID and timestamp. • Mathematical Representation: sort (^^, by = [user_id, timestamp]) → ^^sorted • Input: Set ^^ of base layer location data. • Output: Sorted set ^^sorted. 2. Conflict Detection Function (detect_conflict): • Description: Determines if there is a conflict between two consecutive location data points based on various scenarios such as tailgating, unauthorized access, and forced entry. ^^^^^^^^^^^^ ^^^^^^^^, ^^^^ ^^^^^^^^^^^^^^^^^^^^ ^^^^ ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ ^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^(^^^^,^^^^,^^^^^^^^^^^^) = {^^^^^^^^^^, ^^^^^^^^^^^^^^^^^^• Input: Two consecutive data points ^^^^and ^^^^, and parameters params that include time thresholds and facility layout. • Output: Boolean value indicating the presence or absence of a conflict. 3. Facility Constraints Check (^^): • Description: Checks if two consecutive locations are connected or accessible within the facility layout. ^^(^^ . ^^^^^^^^^^^^^^^^, ) ^^^^^^^^, ^^^^ ^^^^^^^^^^^^^^^^^^ ^^^^^^ ^^^^^^^^^^^^^^^^^^ ^^^^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^^. ^^^^^^^^^^^^^^^^, ^^ = {^^^^^^^^^^, ^^^^^^^^^^^^^^^^^^• Input: Location identifiers from data points ^^^^ and ^^^^, and facility layout ^^. • Output: Boolean value indicating if the locations are logically connected based on facility constraints. 4. Record Generation Function (generate_record): • Description: Generates conflict records for each identified conflict. • Mathematical Representation: generate_record(^^^^, ^^^^, conflict_id) = (conflict_id, user_id, ^^^^.location, ^^^^.location, ^^^^.timestamp, ^^^^.timestamp, {^^^^.sensor_id, ^^^^.sensor_id}) • Input: Base layer data points ^^^^ and ^^^^, and a unique conflict identifier conflict_id. • Output: Tuple representing a conflict record.Output • ^^ = {^^1, ^^2, …, ^^^^} • Each output ^^^^is a tuple formatted as: (conflict_id, user_id, location^^, location^^, timestamp^^, timestamp^^, sensors) Where sensors contains the sensor IDs involved in the conflict.

[0119] Conflict Resolution Module Algorithm Objective: Resolve conflicts in sensor data by evaluating and integrating multiple data sources based on their reliability and potentially identifying intruders if the discrepancies cannot be otherwise explained. Inputs: • Conflict Detection Record: Records of detected conflicts, including conflicting sensor data and timestamps. • Sensor Metadata: Information about each sensor's type, accuracy, and historical performance. • Base Layer Data Confidence: Confidence levels associated with each piece of data, reflecting sensor reliability. Outputs: • Conflict Resolution Record: A record of how each conflict was resolved, detailing which data was deemed most reliable. • Intruder Detection Record (optional): If a conflict cannot be resolved logically based on user access and sensor data, it might indicate an intruder or a serious security breach. Algorithm Step 1: Initialize and Load Data • Load necessary data including conflict records, sensor metadata, and data confidence levels. Step 2: Resolve Each Conflict For each conflict in the Conflict Detection Record: 1. Analyze Involved Data: • Retrieve the conflicting data points and their associated confidence scores from the Base Layer Data Confidence. 2. Weigh Data Validity: • Compare confidence scores and historical accuracy from Sensor Metadata to determine which data points are more likely to be accurate. 3. Apply Resolution Logic: • Decide which data to accept based on the highest confidence scores or integrate data points when possible (e.g., averaging positions if they are close enough and similarly reliable). • If data discrepancies are too significant and cannot be reconciled, consider the possibility of an intruder or unauthorized access, and flag for security intervention. Step 3: Compile Resolution Records • Create a Conflict Resolution Record for each resolved conflict, documenting the decision- making process and outcome. • If an intruder is suspected, generate an Intruder Detection Record detailing the suspicious activity.Step 4: Output Resolved Data • Store the resolved data records for use by other modules. In a mathematical form, the algorithm can be written as follows: Inputs • Conflict Records (^^C): • ^^ = {^^1, ^^2, …, ^^^^}: Set of all conflict records, where each ^^^^contains: • conflict_id^^: Unique identifier for the conflict • user_id^^: User identification number involved in the conflict • locationa: First location involved in the conflict • locationb: Second location involved in the conflict • timestampa: Timestamp of the first location data • timestampb: Timestamp of the second location data • sensors^^: Set of sensors involved in the conflict • User Access Data (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Set of all user access records, where each ^^^^ contains: • user_id^^: User identification number • access_areas^^: Set of areas the user can access • access_level^^: Access level of the user • Facility Layout Data (^^): • ^^ = {^^1, ^^2, …, ^^^^}: Set of all areas within the facility, where each ^^^^contains: • area_id^^: Area identification number • security_level^^: Security level of the area Process 1. Review and Analyse Conflicts: • For each conflict record ^^^^, determine the nature of the conflict (e.g., unauthorized access, tailgating, etc.) and assess the potential security implications. 2. Data Verification: • Verify the accuracy of the conflicting data by comparing it with user access data and facility layout constraints:^^^^^^^^^^^^(^^^^, ^^, ^^)= { ^^^^^^^^^^^^^^, ^^^^ ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^ ^^^^^^^^^^^^ ^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^, ^^^^ ^^^^^^^^ ^^^^^^^^^^^^^^^^ ^^ ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^3. Conflict Resolution Strategies: • Apply resolution strategies based on the type of conflict:• Adjust the base layer data to correct misreads or errors. • Alert security personnel if the conflict is due to a potential security threat or unauthorized access. 4. Generate Resolution Records: • For each resolved conflict, generate a resolution record indicating the outcome: ^^ = {(conflict_id^^, resolution^^) ∣ ^^ = 1, 2, …, ^^} 5. Where resolution^^describes the actions taken to resolve the conflict. Mathematical Description of Functions • Verification Function (verify): • Compares conflict data against user access permissions and facility layout to determine the legitimacy or error in the data.verify : Conflict Record × User Access Data × Facility Layout → {"Resolve", "Action Required"} • Resolution Function (resolve): • Applies appropriate measures to address the conflict based on its verification. resolve : Conflict Record → Resolution Outcome Output • ^^ = {^^1, ^^2, …, ^^^^} • Each output ^^^^ is a tuple: (conflict_id, resolution) • Indicates how each conflict was resolved, whether through data adjustment or security action.

[0120] Data Correlation and Validation Module Algorithm Objective: Correlate and validate sensor data across different sources to confirm accuracy and consistency, and to identify any anomalies or errors that could impact security decisions. Inputs: • All Data: This includes user location data, sensor data, user access rights, facility layout data, and any other relevant information gathered by the system. Outputs: • Final User Location: A validated and confirmed user location that has been cross-referenced and verified against multiple data points. • Confidence Score: A measure of the reliability of the final user location data, based on the validation process. Algorithm Step 1: Collect and Integrate Data • Aggregate data from various sources, including base layer location data, sensor outputs, user profiles, and access logs. Step 2: Correlate Data Points • Compare and correlate data from different sensors and sources to build a comprehensive picture of each event or user position. • Identify any discrepancies or mismatches between data points that could indicate errors or inconsistencies. Step 3: Validate Data For each set of correlated data: 1. Check for Internal Consistency: • Ensure that all pieces of data related to a specific event or user position logically agree with each other. For example, user locations reported by different sensors should align spatially and temporally. 2. Cross-Reference Against Known Information: • Validate the correlated data against established facts such as user access rights, facility layouts, and known user patterns. 3. Assign Confidence Scores: • Based on the level of agreement and validation, assign a confidence score to each set of data. The more sources corroborate a piece of information, the higher its confidence score.Step 4: Handle Anomalies • If data cannot be validated or inconsistencies persist: 1. Flag the data for manual review or further investigation. 2. Adjust the confidence scores downward to reflect the uncertain status of the data. Step 5: Output the Validated Data • Provide the validated user locations along with their confidence as the final output.

[0121] Figure 11 illustrates a network architecture for determining information relating to a physical presence of a person in a surveillance area, such as continuous authentication, authorisation and access control. The network architecture 1100 comprises multiple read points 1101 (referred to as ‘sensors’ herein), a continuous authentication platform 1102 performing the algorithms above and external systems 1103 that may receive outputs from the continuous authentication platform 1102 and act on them accordingly.

[0122] Each of the read points 1101 may have a sensor, a microprocessor (such as a Raspberry Pi) or microcontroller (such as an Arduino-compatible microcontroller) and a Wi- Fi module. The sensor may be a RFID, NFC, Fingerprint, camera, proximity or Wi-Fi sensor. The read points 1101 each send their data as a tuple containing one or more of data R, confidence score C, timestamp T, and user identifier U. Continuous authentication platform 1102 comprises a database 1104 comprising a data capture module and a data filtering module, producing a filtered data stream that is stored in a database 1105. Database 1105 comprises tables for: • facility layout data • sensor location data • sensor accuracy data • user enrolment data • user access level data • NFC RP Data • RFID RP Data • fingerprint RP Data • camera recognition RP Data • Wi-Fi Device location RP Data • proximity RP Data • AIE Data

[0123] Database 1104 provides structure data to an ambient intelligence engine 1106, which comprises a base module, dynamic module and historical module, which together generate the AIE data including user, location, timestamp and confidence to be stored in database 1105. Connected to the AIE 1106 are location tracking logic modules, confidence scoring modules and user presence logic modules for performing the algorithms set out above. External systems 1103 may comprise user tracking and intrusion reporting module 1107, access control / management module 1108, user onboarding and enrolment module 1109 and identity management system module 1110.

[0124] Figure 12 is a first part of a flowchart for determining information relating to a physical presence of a person in a surveillance area, such as continuous authentication, authorisation and access control. This first part shows the steps from a user entering the facility to storing data in a data queue. The data from the user entry 1201 is sent to a data capture and filtering module 1202, which outputs the output data to a raw data to user mapping module 1203. This module sends its output to contextual access control module 1204.

[0125] The following module functions are defined in Figures 12 and 13:

[0126] The following support module functions are defined in Figures 12 and 13:

[0127] The following variables are defined:

[0128] Figure 13 is a second part of the flowchart from the data queue into a user state definition module 1301 that sends a stationary signal to a weighted data calculation module 1302, which, in turn sends a signal to data compilation module 1303, user movement prediction module 1304 and conflict detection modules 1305. The user movement prediction module 1304 sends the result back to the data compilation module 1303 while the conflict detection module 1305 sends its output data, together with the output data from user state definition module to conflict resolution module 1306. The conflict resolution module 1306 sends its output data to data compilation module 1303. The output of the data compilation module is the AIE final output 1307, which is then stored in data queue, which may be on database 1105 in Figure 11. The final output 1307 is also received by a continuousauthorization check module 1308, which also receives the stationary signal data from user state definition module 1301.

[0129] Figure 14 illustrates a computer system for determining information relating to a physical presence of a person in a surveillance area. The computer system comprises a processor 1401, a memory 1402, and a communication interface 1403. Memory 1402 may be a non-transitory computer-readable medium with program code stored thereon that, when executed by processor 1401 causes processor 1401 to perform the methods disclosed herein, including methods disclosed in Figures 2 and 3. Processor 1401 may be a single processor or multiple processors that perform the disclosed methods individually or together. Computer system 1400 may also be implemented in a cloud computing environment or in a distributed environment where some steps are performed locally by the sensor, also referred to as on the edge.

[0130] The processor 1401 is configured to receive sensor data from two or more sensors located in relation to the surveillance area as described herein. These sensors may include, but are not limited to, motion detectors, infrared sensors, video cameras, and biometric scanners. The sensor data may include information such as movement patterns, heat signatures, visual images, and biometric data. The memory 1402 is configured to store a correlation model. The correlation model is used by the processor to correlate the sensor data from the two or more sensors. The correlation model may use various algorithms and techniques, such as machine learning, pattern recognition, and statistical analysis, to calculate a correlation model output relating to the person. The communication interface 1403 is configured to generate an indication based on the correlation model output. This indication determines whether the physical presence of the person conforms to access rights of the person and / or access rules of the surveillance area. The access rights may be based on factors such as the person’s identity, role, and permissions. The access rules may be based on factors such as the time of day, the location within the surveillance area, and specific conditions or events.

[0131] In operation, the computer system 1400 receives sensor data from the sensors, correlates the sensor data using the correlation model to calculate a correlation model output, and generates an indication based on the correlation model output. This indication can then be used to trigger appropriate actions, such as granting or denying access, sending alerts, orlogging the event. The computer system 1400 provides a robust and reliable method for determining the physical presence of a person in a surveillance area. By correlating data from multiple sensors and considering both access rights and access rules, the system can accurately determine whether a person’s presence in the surveillance area is authorized or not. This can enhance security, prevent unauthorized access, and provide valuable data for analysis and reporting.

[0132] In another example, processor 1401 performs a method for continuous authentication of a person present in a facility. That is, processor 1401 authenticates the person upon entry into the facility, collects data by a network of sensors distributed throughout the facility and configured to capture data related to interactions and movements of the person within the facility, and processes the collected data to associate the collected data with the person and determine location data indicative of the location of the person. The processor 1401 further processes the determined location data with historical location data to determine a spatiotemporal state of the person in the facility and detects anomalies based on the spatiotemporal state of the person.

[0133] In summary, processor 1401 performs the method for continuous authentication of a person present in a facility. Processor 1401 authenticates the person upon entry into the facility. This involves verifying the person's identity using high-confidence methods such as biometric verification or secure ID cards, as established at the facility's entrance. Processor 1401 further collects data from a network of sensors distributed throughout the facility. These sensors are configured to capture data related to the interactions and movements of the person within the facility, including NFC, RFID, cameras, motion detectors, and biometric scanners. The collected data is processed by processor 1401 to associate the data with the person and determine location data indicative of the person's location. This involves transforming raw sensor data into detailed user location data and determining the person's location based on sensor positions within the facility.

[0134] Processor 1401 processes the determined location data with historical location data to define the current state of the person as either "Transition" (moving between locations) or "Stationary" (remaining in one location). This classification is based on temporal and spatial data collected from the sensors. Processor 1401 applies a time-decay mechanism todynamically adjust the confidence scores of user location data over time. As time elapses since the last sensor data update, the confidence in the accuracy of the location data decreases, and vice versa. Processor 1401 detects anomalies based on the spatiotemporal state of the person by constantly analyzing user behaviour and movement patterns. The Behavioural Analytics component uses machine learning algorithms to detect inconsistencies and unusual behaviour.

[0135] Upon detecting a mismatch or suspicious activity, processor 1401 triggers immediate security actions. These actions can include sending alerts to security personnel, locking down specific areas, or initiating further verification processes. This method ensures robust user authentication and activity monitoring in a facility, leveraging advanced sensor networks, real-time data processing, and sophisticated algorithms to maintain high-security standards and prevent unauthorized access.

[0136] The document provides a comprehensive overview of a system designed for continuous authentication of individuals within a facility. It begins with the technical field, explaining that the disclosure relates to determining information about a person's physical presence in a surveillance area, including authentication, authorization, and access control1. The background section highlights the limitations of current access control mechanisms, which authenticate a person upon entry but lack continuous monitoring of the person's activities and whereabouts within the facility2.

[0137] This disclosure provides a method and system for continuous authentication, involving initial authentication upon entry, data collection by sensors, data processing to associate the collected data with the person, determining a spatiotemporal state, and detecting anomalies based on this state. The continuous authentication process is advantageous for maintaining high-security standards and preventing unauthorized access after the initial authentication at the facility's entrance. The system employs high-confidence methods such as biometric verification or secure ID cards to verify each individual's identity and establish a trusted baseline for further monitoring and verification processes within the facility. The network of sensors distributed throughout the facility collects data dynamically, capturing various aspects of user interactions and movements.

[0138] An Ambient Intelligence Engine processes the raw sensor data to determine users' precise locations and monitor their activities in real-time. The system classifies users as either "Transition" or "Stationary" based on temporal and spatial data collected, which is critical for understanding user behaviour and detecting anomalies that indicate unauthorized activities. A Time-Decay Mechanism Module dynamically adjusts the confidence scores of user location data over time, ensuring the system remains accurate and reliable.

[0139] Anomaly detection is another part of continuous authentication, where the system constantly analyses user behaviour and movement patterns to identify deviations from the norm. Upon detecting a mismatch or suspicious activity, the system triggers immediate security actions, such as sending alerts to security personnel, locking down specific areas, or initiating further verification processes. The continuous authentication functionality is integrated seamlessly with other components of the disclosed system, such as authorization and enhanced access control, ensuring a holistic approach to security.

[0140] In summary, the continuous authentication leverages advanced sensor networks, real- time data processing, and sophisticated algorithms to ensure that user identities are continuously verified within smart facilities. This functionality is useful for maintaining high- security standards and preventing unauthorized access, thereby enhancing the overall safety and security of the facility.

[0141] It will be appreciated by persons skilled in the art that numerous variations and / or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

CLAIMS:

1. A method for determining information relating to a physical presence of a person in a surveillance area, the method comprising: receiving sensor data from two or more sensors located in relation to the surveillance area; correlating the sensor data from the two or more sensors in a correlation model to calculate a correlation model output relating to the person; and based on the correlation model output, generating an indication of whether the physical presence of the person conforms to access rights of the person and / or access rules of the surveillance area.

2. The method of claim 1, wherein the correlation model output comprises identity of the person and spatiotemporal context relating to the person.

3. The method of claim 1 or 2, wherein the method further comprises determining a current location of the person based on the sensor data and the current location of the person is an input to the correlation model.

4. The method of any one of the preceding claims, wherein the method further comprises determining the identity of the person based on the sensor data.

5. The method of claim 3 or 4, wherein determining the current location and / or the identity of the person is performed continuously.

6. The method of any one of the preceding claims, wherein one or more previously determined locations of the person is a further input to the correlation model.

7. The method of any one of the preceding claims , wherein the correlation model is configured to output a predicted location of the person and the method comprises analysing one or more previously determined locations and contextual information.

8. The method of any one of the preceding claims, wherein the sensor data is captured incidentally to the person moving through the surveillance area.

9. The method of any one of the preceding claims, wherein the two or more sensors are of a different sensor type.

10. The method of any one of the preceding claims, wherein receiving the sensor data comprises collecting identifying data of the person.

11. The method of claim 10, wherein the method comprises associating the collected identifying data to the person.

12. The method of claim 10 or 11, wherein the identifying data comprises a device identifier of a device carried by the person.

13. The method of any one of claims 10 to 12, wherein the method further comprises extracting an identifier of the person from the identifying data.

14. The method of claim 13, wherein extracting the identifier comprises applying a machine learning model to the identifying data.

15. The method of any one of the preceding claims, wherein correlating the sensor data is based on meta-data of each of the two or more sensors.

16. The method of claim 15, wherein the meta-data is based on observed reliability and performance of the two or more sensors.

17. The method of any one of the preceding claims, wherein the correlation model is configured to provide situational awareness as a sequence of events relating to the person.

18. The method of any one of the preceding claims, wherein the method further comprises calculating confidence scores for the sensor data and for the indication of whether the physical presence of the person conforms to the access rights of the person and / or access rules of the surveillance area.

19. A method for continuous authentication of a person present in a facility, the method comprising:authenticating the person upon entry into the facility; collecting data by a network of sensors distributed throughout the facility and configured to capture data related to interactions and movements of the person within the facility; processing the collected data to associate the collected data with the person and determine location data indicative of the location of the person; processing the determined location data with historical location data to determine a spatiotemporal state of the person in the facility; and detecting anomalies based on the spatiotemporal state of the person.

20. The method of claim 19, wherein the spatiotemporal state of the person is indicative of a transition of the person from a first location to a second location.

21. The method of claim 19 or 20, wherein the method further comprises applying a time-decay to adjust a confidence score associated with the location data over time.

22. The method of any one of claims 19 to 21, wherein the method further comprises determining a confidence score for each sensor of the network and applying that confidence score to the detecting of the anomalies.

23. The method any one of claim 19 to 22, wherein the method further comprises performing a security action.

24. The method of any one of claims 19 to 23, wherein the method further comprises authorising the person by checking the person’s access rights against the location data.

25. The method of claim 24, wherein the method further comprises, based on the authorising, selectively performing one of the steps of: (i) physically providing access to an area of the facility, or (ii) physically blocking access to the area of the facility.

26. The method of any one of claim 19 to 25, wherein the method further comprises resolving conflicts in the location data.

27. The method of any one of claim 19 to 26, wherein the method is performed in real- time.

28. The method of any one of claims 19 to 27, wherein authenticating the person upon entry into the facility comprises checking plausibility of the person being at the entry given previously determined location information.

Images