WO2022027096A1

WO2022027096A1 - System and method for persistent contactless check-in

Info

Publication number: WO2022027096A1
Application number: PCT/AU2021/050847
Authority: WO
Inventors: Adam Friedman; Kwok Kit Jamie TO
Original assignee: Thoughtful Pty Limited
Priority date: 2020-08-04
Filing date: 2021-08-04
Publication date: 2022-02-10
Also published as: AU2021319948A1

Abstract

A method for persistent contactless check-in by a user device, including: detecting a NCC tag at a location including a uniform resource locator (URL); receiving the URL; determining whether a cookie associated with the domain is stored on the user device; identifying, if there is a stored cookie, a unique identifier (ID) stored in local storage of the user device; sending at least one HTTP request to an application server based on the remote server address; receiving at least one HTTP response; and, if the HTTP request did not include the unique ID, the user device receiving a newly generated cookie with a domain attribute including the domain, and storing the cookie on the user device for use when a further NCC tag is detected with a domain in the domain attribute of the cookie, and storing the new unique ID.

Description

SYSTEM AND METHOD FOR PERSISTENT CONTACTLESS CHECK-IN

RELATED APPLICATION

[0001] The present application is related to Australian Provisional Patent Application No 2020902724, filed 4 August 2020 in the name of Thoughtful Pty Limited, entitled "System and method for persistent contactless check-in", the originally filed specification of which is hereby incorporated by reference herein in its entirety.

TECHNICAL FIELD

[0002] The present application relates to systems and methods for checking in, i.e., recording a person's physical presence at a physical location, e.g., at a venue such as a workplace, a club, a restaurant, a cinema, a shop, a gallery, a museum or a stadium.

BACKGROUND

[0003] It can be very important to check in people at certain physical locations, including at venues such as workplaces, clubs, restaurants, cinemas, shops, galleries, museums and stadia, including for the purpose of reporting who was physically present at the location (i.e., at or in the venue) at a selected past time period, e.g., for contact tracing of a highly infectious disease such as coronavirus disease 2019 (COVID-19).

[0004] It is desired to address or ameliorate one or more disadvantages or limitations associated with the prior art, or to at least provide a useful alternative.

SUMMARY

[0005] Disclosed herein is a method for persistent contactless check-in by a user device, the method including (automatically): a. the user device detecting, by non-contact communication (NCC), a NCC tag at a venue (or other physical place or location), wherein the NCC tag includes a uniform resource locator (URL), wherein the URL conforms to the Hypertext Transfer Protocol (HTTP) and includes: i. a domain that defines a server domain in the Internet, ii. a hostname in the server domain that defines a remote server address, and iii. text representing a tag identifier (ID) that identifies the NCC tag and the venue; b. the user device receiving, from the NCC tag, the URL; c. the user device determining whether a cookie associated with the domain is stored on the user device; d. the user device identifying, if there is a stored cookie, a unique identifier (ID) stored in local storage of the user device (either in the stored cookie, or as data/values in the local storage of the user device associated with the cookie or the domain); e. the user device sending at least one HTTP request (including using a cryptographic protocol) to an application server based on the remote server address, wherein the HTTP request includes: i. the tag ID, and ii. the encrypted data/values containing the unique ID, if the cookie and unique ID are stored on the user device; f. the user device receiving at least one HTTP response (including using the cryptographic protocol), the HTTP response including, from the application server: i. an acknowledgement of safe receipt of the tag ID (indicating that the venue has previously been registered in the system) if the HTTP request did include the unique ID, or ii. a newly generated unique ID (e.g., in a newly generated cookie), if the HTTP request did not include the unique ID; and g. if the HTTP request did not include the unique ID, the user device receiving a newly generated cookie with a domain attribute including the domain, and storing the cookie on the user device for use when a further NCC tag is detected with a domain in the domain attribute of the cookie, and storing the new unique ID in the cookie or as data/values in the local storage of the user device (thus the user device records that this user device has been registered in the system, and this registration can be referred to as "persistent").

[0006] Disclosed herein is a method for persistent contactless check-in by a user device, the method including (automatically): a. an application server receiving a tag ID and a unique ID in at least one HTTP request from the user device; b. the application server determining whether the tag ID in the HTTP request matches any of a plurality of predefined tag IDs in a database of the application server (i.e., the tag ID is valid and registered); c. if there is a unique ID (appropriately valid and encrypted) in the HTTP request, the application server determining whether the unique ID in the HTTP request matches any of a plurality of registered unique IDs in the database (i.e., the unique ID is valid and registered); and d. if the tag ID matches any one of the predefined tag IDs (thus indicating that the tag has previously been registered in the system), and if the unique ID — if there is one — matches any one of the registered unique IDs (indicating that the user device has previously been registered in the system), the application server recording an event in an event log in the database and/or generating an acknowledgement of safe receipt of the tag ID for the HTTP response.

[0007] The method includes, if the application server determines that the HTTP request does not include the unique ID: a. the application server (automatically) sending a user input form to the user device (in an HTTP response); b. the application server receiving a completed user input form from the user device; and c. the application server (automatically) generating the unique ID for this user device using the completed user input form (such that the unique ID is unique and anonymous in the system) for sending to the user device in the HTTP response for storing in the user device.

[0008] Disclosed herein is a system for persistent contactless check-in by a user device, the system including the user device and an application server, wherein the user device and the application server are configured to execute the method disclosed herein.

[0009] Disclosed herein is machine readable executable code configured to execute the methods above.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Some embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, in which: a. Figure 1 is a flow diagram of a method; and b. Figure 2 is an architecture diagram a system configured to execute the method.

DETAILED DESCRIPTION

[0011] Described herein is a method 100 for persistent contactless check-in by a user device, and a corresponding system 200 configured to execute (i.e., perform) the method.

Client-Side Method

[0012] The method includes (on a user-device side of the system, also referred to as the client side): a. the user device detecting, by non-contact communication (NCC) of a NCC tag — including by near field communication (NFC) with a NFC tag or by optical scanning of a Quick Response (QR) code on a QRtag — a at a venue (or other physical place or location), wherein the NCC tag includes and defines a uniform resource locator (URL), wherein the URL conforms to the Hypertext Transfer Protocol (HTTP) and includes: i. a domain (e.g., "example.com") that defines a server domain in the Internet, ii. a hostname in the server domain, (e.g., "www.example.com") that defines a remote server address, and iii. text representing atag identifier (ID) (e.g., "tagl") that identifies the NCC tag and the venue; b. the user device receiving, from the NCC tag, the URL; c. the user device determining whether a cookie associated with the domain is stored (i.e., present) on the user device (thus indicating that this user device has been previously registered in the system); d. the user device identifying, if there is a stored cookie, a unique identifier (ID) stored in local storage of the user device (either in the stored cookie, or as data/values in the local storage of the user device); e. the user device sending at least one HTTP request (including using a cryptographic protocol as described hereinafter, e.g., TLS/SSL) to an application server based on the remote server address, wherein the HTTP request includes: i. the tag ID (e.g., in the request line of the HTTP request), and ii. the encrypted data/values containing the unique ID (e.g. in the cookie), if the cookie is stored on the user device; f. the user device receiving at least one HTTP response (including using the cryptographic protocol as described hereinafter), the HTTP response including, from the application server: i. an acknowledgement of safe receipt of the tag ID (indicating that the venue has previously been registered in the system) if the HTTP request did include the unique ID, or ii. the unique ID (e.g., in a newly generated cookie), if the HTTP request did not include the unique ID; and g. if the HTTP request did not include the unique ID, the user device receiving a newly generated (new) cookie with a domain attribute including the domain, and storing the cookie on the user device for use when a further NCC tag is detected with a domain in the domain attribute of the cookie, and storing the new unique ID in the cookie or as data/values in the local storage of the user device (thus the user device records that this user device has been registered in the system, and this registration can be referred to as "persistent").

[0013] If the user device determines that the appropriate cookie is not stored on the user device, this indicates that the user device has not been registered in the system previously. In this case, the HTTP request does not include the cookie or unique ID. In this case, in order to generate the unique ID and its cookie, the method can include: a. the user device receiving, from the application server, a user input form (e.g., a user registration form, which can accord to an HTTP format sent as at least one HTTP response to the user device); b. the user device rendering and displaying the user input form on a user interface of the user device; c. the user device generating, based on user input into the displayed user input form, a completed user input form (i.e., user input data, e.g., including a user's name and telephone number, entered into the user input form, which are used to generated the user passport); d. the user device validating the user input for all input fields (of the user input form) according validation rules in the user input form, e.g., using Javascript validation rules for text-input fields of the user input form, e.g., requiring a telephone number field to receive only numbers — this is referred to as "client-side validation"; and e. the user device sending, to the application server, the completed user input form (i.e., the user input data).

[0014] The completed user input form (i.e., the user input data) is used to generate the cookie and unique ID (e.g., in the cookie) for this user device, and the cookie and unique ID (e.g., in the cookie) are subsequently sent back to the user device in an HTTP response. The unique ID may be referred to as a "device ID" because it is substantially unique in the system, i.e., a unique identifier for the device, and because an encrypted copy of the unique ID is stored on the device. The unique ID is encrypted except in the application server, i.e., the unique ID is generated then encrypted by the application server (which stores encryption keys used for the encryption in the application server, or at least securely accessible from), and remains encrypted when it is sent in the HTTP response, when it is stored in the user device, and when it is sent with the HTTP request. When user input form is complete, the application server creates the cookie the first time by encrypting an auto generated random universal unique ID (the unique ID), e.g., a UUID as described hereinafter. Once the unique ID is encrypted by the application server (e.g., using AES 256), the application server add the encrypted unique ID to the cookie, and then the application server signs the cookie (by creating a HMAC of the stored cookie, and base64 encoding it). The signed cookie is then set in the response header and sent back to a HTTP client in the user device. The encrypted unique ID may be sent in the cookie, or as encrypted data/values in a message body of the HTTP response. The HTTP client (and thus the user device) then stores the cookie locally, and stores the encrypted unique ID locally (including if it sent in the HTTP response message body as encrypted data/values).

Server-Side Method

[0015] On a server side of the system, the method includes: a. the application server receiving the tag ID and the unique ID (if there is one) of the at least one HTTP request from the user device; b. the application server determining whether the tag ID in the HTTP request matches any of a plurality of predefined tag IDs in the database (i.e., the tag ID is valid and registered); c. if there is a valid unique ID in the HTTP request, the application server: i. decrypting the unique ID using the encryption keys, and ii. determining whether the unique ID in the HTTP request matches any of a plurality of registered unique IDs in the database (i.e., the unique ID is valid and registered); and d. if the tag ID does match any one of the predefined tag IDs (thus indicating that the tag has previously been registered in the system), and if the unique ID — if there is one — matches any one of the registered unique IDs (indicating that the user device has previously been registered in the system), the application server recording an event in an event log in the database (and generating an acknowledgement of safe receipt of the tag ID for the HTTP response); or e. otherwise (if the tag ID or the unique ID is not registered or otherwise invalid), the application server generating and sending an invalid-request message for the HTTP response (or simply continuing with the method as if no unique ID had been received).

[0016] The method includes the application server validating the encrypted data containing the unique ID (which can be the signed cookie) to ensure no tampering of the encrypted unique ID/cookie has occurred, and then the application server decrypting the data/values (e.g., within the cookie) to retrieve the unique ID, before determining if the unique ID matches any of the registered IDs in the database.

[0017] The method includes: a. the application server determining whether the HTTP request included the valid unique ID; and b. if the HTTP request does not include the unique ID: i. the application server sending the user input form ("user registration form") to the user device (in at least one HTTP response), ii. the application server receiving the completed user input form from the user device, and iii. the application server generating the unique ID for this user device using the completed user input form, such that the unique ID is unique and anonymous in the system, for sending to the user device in the HTTP response for storing in the (persistent) cookie or the local storage of the HTTP client / user device.

[0018] The method includes the application server validating the completed user input form, and only generating the unique ID for this user device using the completed user input form if the completed user input form is determined to be valid. The method includes the application server validating fields of the completed user input form according validation rules in the application server, e.g., using the same validation rules as in the user input form described hereinbefore — this is referred to as "server-side validation". If the serverside validation detects an error, the method includes the application server sending an HTTP response back to the user device with data indicating the error, and the user device rendering and displaying the error and again rendering and displaying the user input form on the user interface of the user device (to again generate the completed user input form, i.e., repeating the earlier step).

[0019] If the unique ID is generated by the application server, the method includes the application server storing a user-device entry (referred to as a new user passport entry) in the database based on the completed user input form, wherein the user-device entry includes the unique ID. In other words, the application server generates a random code to form the unique ID (e.g., UUID) and stores it together with the user input form data in the database as the new user passport entry. The unique ID will be the lookup value for this user passport data.

[0020] If the tag ID matches any of the predefined tag IDs in the database, and the unique ID is valid or generated, the method includes the application server storing a check-in entry in the database with: the tag ID and the unique ID, by storing, in the database, timestamp data representing the time and date of the step of the user device detecting the NCC tag (which may be referred to as an "NCC event"). The time and date of the NCC event may be recorded by the NCC system based on a machine-readable clock in the user device. Alternatively the time and date of the NCC event may be may be generated by the user device when generating the HTTP request. The user device sends the time and date with the HTTP request to the application server for recordal in a log of NCC event logs (the time and date is stored as timestamp data in the database with reference to the unique ID and the tag ID as described hereinafter). Alternatively, the timestamp data are generated using Coordinated Universal Time (i.e., "UTC") by the application server and the time and date are not provided by the user device.

NCC Tag [0021] In an exemplary implementation of the system and the method, the NFC tags are commercially available NFC tags or QRtags configured to store one URL.

[0022] The scheme, the domain, the server address and the tag ID are combined in the one URL according the HTTP standard. The scheme of the URL can be "HTTP". The URL can include an indicator of the cryptographic protocol ("S" in "HTTPS"), and the cryptographic protocol can be Transport Layer Security (TLS) or Secure Sockets Layer (SSL). The method can include the user device and the application server using the cryptographic protocol to send and receive the HTTP requests and responses described herein. The HTTP request conforms to the communications protocol defined by the scheme, e.g., HTTP, including the cryptographic protocol. The response conforms to the same communications protocol, e.g., HTTP. As described hereinbefore, the URL includes the text representing the tag ID (e.g., "tagl") that identifies the NCC tag (and the venue): the tag ID text is included in the path and/or filename, and HTTP components appended to the path, of the URL — i.e., elements of the URL beyond the hostname and the domain. For example, the tag ID may be "tagl", and the path may be "/tagl" . This use of the one URL to define the domain (which is recognised by the user device to search for the cookie), the server address (which is used by the user device to address the HTTP request), and the tag ID (which is recognised by the application server to identify the NCC tag and the venue), allows the method to be used with simple NCC tags that cannot store more than one URL. An exemplary URL is "http(s)://[hostname.domain]/[id]".

[0023] The encrypted unique ID in the user device's storage, in the HTTP request and in the HTTP response is the only reference or link to the user passport stored in the database: accordingly, use of a system-unique device ID (e.g., a UUID) avoid storage and transmission of identifiable details (e.g., in the browser cookie), which may be easily accessible in plain text.

User Device

[0024] The user device includes an NFC system or QR code reader (which are referred to here as "NCC systems") and the HTTP client.

[0025] The NFC system of the user device can be a commercially available component that detects NFC tags when placed in close range (defined by the NFC standards). The QR code reader of the user device can be a commercially available component, e.g., of a camera module, that detects QR codes when placed in optical range. The method includes the user device, and specifically the NCC system, automatically activating the HTTP client with the URL when the NCC system detects the NFC tag with the URL. The automatic activation of the HTTP client by the NCC system may require confirmation by the user, e.g., authenticating via a passcode or biometric challenge (e.g., the user interface may display a prompt "Open 'domain' in Safari" requiring the user input confirmation to activate the HTTP client). In some implementations, e.g., some user devices, the native NFC system may operate with fewer user-required inputs than the QR code reader, so using the NFC tag as the NCC tag may be preferable: for example, the user device may be natively configured to activate the NFC system with fewer or more convenient user inputs than to activate the QR code reader.

[0026] The user device includes an HTTP client (referred to as a "Web browser") configured to access cookies (including the cookie), i.e., a Web browser with cookies enabled. The user device is configured to automatically activate or open the HTTP client with the URL when the NCC system detects the URL in the NCC tag. The HTTP client is configured to automatically generate and send the HTTP request when it is activated with the URL. The HTTP client may be based on a commercially available component, e.g., Apple's Safari or Google's Chrome.

[0027] The HTTP client includes a cryptographic module configured to execute the steps described herein of establishing and using the encrypted session with the application server for the HTTP requests and responses in accordance with the cryptographic protocol (TLS, SSL).

[0028] The HTTP client is configured to determine a time and date of the request being generated and send this with the HTTP request as the time and date of the NCC event (e.g., using the "Date" header field). Alternatively, the HTTP client does not provide the time and date (when the time and date are not provided by the user device).

[0029] The user device includes a network connection to support the Internet protocol. The user device typically includes a wireless data connection for the network connection, e.g., via Wi-Fi and/or a mobile protocol (4G/5G). The user device is a small manually portable device that can be hand held. An exemplary user device can be a smart phone or watch, e.g., having Apples iOS or Google's Android operating systems. [0030] The method includes the HTTP client determining whether the cookie is stored in the user device in association with the domain of the URL.

[0031] The HTTP client performs the user-interface steps of the user device described hereinbefore, including: receiving, from the application server, the user input form (sent as an HTTP response to the HTTP client); rendering and displaying the user input form on the user interface (e.g., a touchscreen); generating, based on the user input, the completed user input form (i.e., collecting the user input data); and sending, to the application server, the completed user input form (i.e., the user input data), via an HTTP request.

[0032] The cookie stores the unique ID. Alternatively, instead of storing the unique ID in the user device in the cookie, the herein-described system and method can store the unique ID in the local storage of the user device, specifically in local storage of the HTTP client, with a link or pointer or reference to the domain or the cookie such that the unique ID is sent automatically with the HTTP request (or in a subsequent HTTP request to the same server as the original HTTP request). The user device in this case is configured to include the encrypted unique ID in the HTTP request, e.g., in the message body of the request. The unique ID is generated for the user device by the system (by the application server) such that each user device that is registered with the system should have a unique and anonymous unique ID. The unique ID is the only information used to identify the user device by the method described herein, and the unique ID is only associated with other identity details of the user device (referred to as the "user passport", e.g., including telephone number, user's name) in the database of the application server. The unique ID is used as lookup reference for the user passport in the database. The unique ID is generated using an algorithm that ensures each unique ID is substantially unique in the system. The unique ID may be a universally unique identifier (UUID) or globally unique identifier (GUID), e.g., a 128-bit number, generated by the application server, e.g., 4e49a70b-54a5- 473e-9f95-a367ca2a80c6. The UUID may be generated using a commercially available component. The cookie may be referred to as a "state object". The cookie includes a domain attribute which includes and/or defines the domain that leads to the application server. The cookie is transmitted from the HTTP client to the application server only when the HTTP client makes the HTTP request and the server address is within the domain of the domain attribute of the cookie. Application Server

[0033] The system includes the application server. The application server is based on a commercially available component that is configured by machine readable executable code to process the received HTTP requests and return the responses. The method includes the application server performing the following steps by executing the executable code: a. extracting the tag ID from the URL; b. extracting the unique ID (e.g., UUID) from the encrypted cookie or encrypted data/values if the cookie and encrypted unique ID are in the HTTP request (including determining if the cookie and/or the encrypted unique ID are in the HTTP request, which is indicative of the user device having been registered with the system); c. generating a new unique ID if no unique ID is in the HTTP request, and generating a corresponding new user passport (i.e., database record for information in the completed user input form); d. performing a database lookup for relevant resources (i.e., the user passport) from the database using the tag ID and unique ID; e. creating a new event entry in the database of NCC events that references the user passport and related resource (i.e., the timestamp).

[0034] The system may include a web server based on a commercially available component that can process the HTTP requests and responses. The webserver may be referred to as a component of the application server. The webserver may be configured by at least a portion of the executable code to perform one or more of the hereinbefore described steps executed by the application server by executing the executable code. The method can includes the web server extracting the tag ID from the path and/or filename, and extracting the unique ID (e.g., UUID) from the cookie or encrypted data/values, and sending the unique ID and the corresponding tag ID to the application server using a protocol that is not an HTTP request, e.g., using a low-level Transmission Control Protocol (TCP) between web server and the application server, and data in transmission between the web server and the application server can be encrypted, using with the RSA (Rivest- Shamir-Adleman) algorithm. [0035] The system includes the database which may be based on a commercially available component that stores data. The database is configured to include the following data storage tables: a. a table of the User Passport Details ("UserPassport table"); b. a table of NCC event logs ("NFCLog table"); c. a table of internal ID mapping ("IntemallDMap table"); d. a table of Organisation Details (“Organisation table”); and e. a table of Locations referencing to an Organisation (“OrganisationLocation table”) for respective ones of the venues.

[0036] The application server extracts the tag ID from the HTTP request by reading the text representing the tag ID (e.g., "tagl") venue in the URL.

System

[0037] The system includes the user device and the application server.

[0038] The system includes a plurality of user devices, each one with the hereinbefore described components of the user device. The system includes a plurality of NCC tags, each including a URL configured with the same format as the one NCC tag hereinbefore described, but the plurality of URLs include mutually different URLs. Specifically, the plurality of URLs can include mutually the same scheme (e.g., HTTP/S), the same domain (e.g., "example.com") and the same hostname (e.g., "www"), but a plurality of mutually different tag IDs (e.g., "tagl", "tag2", ... "tagN"). The database can be configured to include the plurality of tag IDs associated with respective venues. The plurality of NCC tags may include two or more NCC tags with mutually the same tag ID, both associated in the database with one venue, e.g., for a large venue with multiple entrances, or to provide spare NCC tags to the one venue. The method includes programming the NCC tag with the URL, i.e., writing the URL into the NCC tag. The NCC tag is based on a writeable and readable blank NCC tag. Tag IDs are generated automatically by the application server when respective new organisation locations are created

Implementation

[0039] In an implementation, the system includes machine readable executable code executed by the system, and the machine readable executable code when executed causes the system to perform the following sub-processes: a. a sub-process for registering the new log or showing the user input form; and b. a sub-process for creating the new User Passport from the completed user input form.

[0040] The sub-process executed by the application server for registering the new log or showing the user input form includes: a. Extract tag ID from URL and assign to TagID; b. Query database (DB) for existing record of business location using TagID and assign to LocationRecord; c. If LocationRecord is empty then: i. Throw error for location not found; d. Extract signed cookie from request and assign to SignedCookie; e. If SignedCookie is found then: i. Parse and decode SignedCookie with Secret Key and return value to Cookie Value, ii. If CookieValue is invalid:

Throw error for invalid cookie signature, iii. Decrypt CookieValue with Pass Phrase and return the decrypted value to DevicelD, iv. Query DB for existing record of User Passport using DevicelD and assign result to UserPassport, v. If UserPassort is empty:

Throw error for user passport not found, vi. Insert new DB entry to log table with TagID, DevicelD and current UTC time, and vii. If insert failed then

Throw error for insert fail, and viii. Send response back to user device and show success page; f. else g. Send response back to user device and show user input form.

[0041] The sub-process executed by the application server for creating the new User Passport from the completed user input includes: a. Extract tag ID from URL and assign to TagID; b. Query DB for existing record of business location using TagID and assign result to LocationRecord; c. If LocationRecord is empty then: i. Throw error for location not found; d. Validate user input form values and assign errors to Errors; e . If Errors is not empty then: i. Send response back to user device with Errors; f. Generate new random unique ID (e.g. UUID) and assign to DevicelD; g. Insert new DB User Passport record with user input values and DevicelD; h. Insert new DB entry to log table with TagID, DevicelD and current UTC time; i. Encrypt DevicelD with Pass Phrase and assign encrypted value to EncryptedDevicelD; j . Create new Cookie with DevicelD as value and set expiry to future date; k. Sign Cookie with Secret Key; l. Add Cookie to response header; and m. Send response back to user device to show success page.

Interpretation [0042] Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention.

[0043] The presence of"/" in a FIG. or text herein is understood to mean "and/or" unless otherwise indicated, i.e., “X/Y” is understood to mean “X, or Y, or both X and Y” The recitation of a particular numerical value or value range herein is understood to include or be a recitation of an approximate numerical value or value range, for instance, within +/- 20%, +/- 15%, +/- 10%, +/- 5%, +/-2.5%, +/- 2%, +/- 1%, +/- 0.5%, or +/- 0%. The term "substantially" can indicate a percentage greater than or equal to 90%, for instance, 92.5%, 95%, 97.5%, 99%, or 100%.

[0044] The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

[0045] Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

Claims

1. A method for persistent contactless check-in by a user device, the method including: a. the user device detecting, by non-contact communication (NCC), a NCC tag at a venue or other physical place or location, wherein the NCC tag includes a uniform resource locator (URL), wherein the URL conforms to the Hypertext Transfer Protocol (HTTP) and includes: i. a domain that defines a server domain in the Internet, ii. a hostname in the server domain that defines a remote server address, and iii. text representing a tag identifier (ID) that identifies the NCC tag and the venue; b. the user device receiving, from the NCC tag, the URL; c. the user device determining whether a cookie associated with the domain is stored on the user device; d. the user device identifying, if there is a stored cookie, a unique identifier (ID) stored in local storage of the user device; e. the user device sending at least one HTTP request to an application server based on the remote server address, wherein the HTTP request includes: i. the tag ID, and ii. the encrypted data/values containing the unique ID, if the cookie and unique ID are stored on the user device; f. the user device receiving at least one HTTP response, the HTTP response including, from the application server: i. an acknowledgement of safe receipt of the tag ID if the HTTP request did include the unique ID, or ii. a newly generated unique ID, if the HTTP request did not include the unique ID; and g. if the HTTP request did not include the unique ID, the user device receiving a newly generated cookie with a domain attribute including the domain, and storing the cookie on the user device for use when a further NCC tag is detected with a domain in the domain attribute of the cookie, and storing the new unique ID in the cookie or as data/values in the local storage of the user device.

2. The method of claim 1, wherein the unique ID is stored either in the stored cookie, or as data/values in the local storage of the user device associated with the cookie or the domain.

3. The method of claim 1 or 2, wherein the user device sending the at least one HTTP request includes using a cryptographic protocol, and wherein the user device receiving the at least one HTTP response includes using the cryptographic protocol.

4. The method of any one of claims 1 to 3, wherein the HTTP response includes the newly generated unique ID in a newly generated cookie.

5. The method of any one of claims 1 to 4, wherein the NCC tag includes a near field communication (NFC) tag.

6. The method of any one of claims 1 to 5, wherein the NCC tag includes a Quick Response (QR) tag.

7. A method for persistent contactless check-in by a user device, the method including: a. an application server receiving a tag ID and a unique ID in at least one HTTP request from the user device; b. the application server determining whether the tag ID in the HTTP request matches any of a plurality of predefined tag IDs in a database of the application server; c. if there is a unique ID in the HTTP request, the application server determining whether the unique ID in the HTTP request matches any of a plurality of registered unique IDs in the database; and d. if the tag ID matches any one of the predefined tag IDs, and if the unique ID — if there is one — matches any one of the registered unique IDs, the application server recording an event in an event log in the database and/or generating an acknowledgement of safe receipt of the tag ID for the HTTP response.

8. The method of claim 7 including, if the application server determines that the HTTP request does not include the unique ID: a. the application server sending a user input form to the user device; b. the application server receiving a completed user input form from the user device; and c. the application server generating the unique ID for this user device using the completed user input form for sending to the user device in the HTTP response for storing in the user device.

9. A system for persistent contactless check-in by a user device, the system including the user device and an application server, wherein the user device and the application server are configured to execute the method of any one of claims 1 to 8.

10. Machine readable executable code configured to cause one or more computing systems to execute the method of any one of claims 1 to 8.