Ordering system and method
The RFID tag authentication system ensures customer presence and prevents fraudulent orders by using encrypted RFID tags with unique scan counts, addressing the limitations of QR-based systems and enhancing security and efficiency in hospitality ordering.
Patent Information
- Application Number
- GB2023000371
- Authority / Receiving Office
- GB · GB
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2023-01-11
- Publication Date
- 2025-07-23
- Estimated Expiration
- 2043-01-11
AI Technical Summary
Existing QR-based ordering systems for hospitality establishments lack the ability to ensure that the person placing an order is physically present at the table, leading to potential mischievous orders and exposure to DDoS attacks, forcing establishments to insist on immediate payments, which reduces upsells and customer satisfaction.
An RFID tag authentication system that requires customers to authenticate their physical presence by scanning an RFID tag associated with their seating location, using encryption and unique scan count values to verify the tag's validity, ensuring only valid orders are processed and reducing the risk of DDoS attacks.
The system effectively authenticates the customer's physical presence, reduces errors in table number input, and prevents fraudulent orders, while maintaining a seamless online ordering experience without exposing the establishment to DDoS attacks.
Smart Images

Figure 00000001_0000 
Figure 00000002_0000 
Figure 00000003_0000
Abstract
Description
TECHNICAL FIELD 5 This invention relates to an ordering system and method for a hospitality establishment, for example a customer order authentication system and method. BACKGROUND 10 During the Covid19 pandemic, web or app-based ordering of food, drinks and other consumables at restaurants, cafes and other such hospitality establishments has become more common as a replacement for at-till ordering and table service. The hospitality establishment provides customers with a QR code to scan with a mobile device such as their smartphone. 15 The QR code, typically printed on one or more hard copy posters or menus displayed at the establishment, contains static information such as a URL which, when scanned, causes the customer to be directed to an online menu or ordering landing page, for example through the customer’s web browser or other app on their mobile device. The 20 online menu or ordering landing page allows the customer to create an order by selecting a menu item and providing payment details to pay for the order. Completing the payment results in an order ticket being raised and displayed on an interface in the kitchen or bar of the establishment. The kitchen or bar staff can then prepare the order that can subsequently be taken to the customer’s table in a seamless manner without 25 the need for the customer to interact with anyone in-person at a till. Similarly, this type of system means the serving staff don’t need to spend as much time interacting with customers at tables while taking their order as the ordering is entirely online. However, due to the static nature of the QR link, there is no ability of these systems to 30 ensure that the person placing the order is physically present at the table. As a result, it only works by ensuring payment is made right away. This is contrary to how restaurants typically operate with payment made at the end of the meal. 09 01 25 If a QR system was to be built allowing payments at the end, this would expose the system to major hacking and specifically exposes itself to a Distributed Denial of Service (DDoS) attack since orders can come from anyone with a link to the menu. 5 Even absent a full-scale DDoS attack, it exposes the system to mischievous third parties placing orders for random tables causing chaos and confusion at the hospitality venue, To avoid these risks, establishments that implement the above type of QR ordering 10 systems have little choice but to insist on payments being made immediately upon ordering even though this is contrary to how they would typically prefer to operate, as is described above. Due to this problem, many establishments such as restaurants have gone back to the traditional way of taking of orders, particularly where customers do not like paying right away. Similarly restaurants themselves found that paying right 15 away had the effect of immediately “closing a tab” resulting in a material drop in upsells as there was a reluctance for customers to place new orders. SUMMARY OF INVENTION 20 According to a first aspect, there is provided an RFID tag authentication system for a hospitality establishment according to claim 1. Advantageously, requiring a customer to authenticate their physical presence by requiring authentication of an RFID tag that is physically present at the hospitality 25 establishment ensures that only customers who are physically present and who have scanned the RFID tag corresponding to where they are seated can make and pay for valid orders. This prevents mischievous third parties such as internet trolls and competitors from making fake orders as any attempts to place an order without a successful authentication can be easily identified and blocked. The present system 30 also reduces instances of customer table number error as customers simply scan the RFID tag associated with the specific physical location they are at in the establishment, such as table or seat number and no longer have to input table number or location themselves. Finally, and particularly advantageously, this system also ensures that an establishment does not expose itself to DDoS attacks that a QR system that attempts 35 to allow payments at the end of the meal exposes itself to. 09 01 25 It is envisaged that the encryption described above for the purposes of the authentication uses a symmetric key cipher (e.g. AES-128 or other known symmetric key protocols). Separately, communication of any packets between the one or more 5 servers, the customer device, and / or any setup device, may be separately encrypted using one or more known secure communication protocols, for example using public key encryption protocols, to ensure any communication channels that used are secure. Further, whilst the term RFID is used herein, it is envisaged that the tags may be any subset of RFID technology including any suitable NFC and / or RFID technology as will 10 be appreciated by the skilled person. Thus the RFID tags may comprise an NFC enabled chip configured to perform one or more operations on input data, for example a string, and to output the result of those operations. Advantageously, storing a scan count value on each RFID that increments by one each 15 time the RFID tag is scanned, and encrypting the tag identification number together with the current scan count value (for example, by appending it to the end of the tag identification number string before encrypting) ensures that the encrypted information (i.e. the ciphertext) is unique for each scan and thus each subsequent customer scan or interaction with the RFID can be distinguished from others. This not only provides a 20 better way to track customer interactions with the RFID tag but also provides an additional way to identify potential misuse as re-use of an old ciphertext can be identified during decryption because the old scan count value will not match up with current scan value. Thus, when performing authentication, not only does the tag ID number have to be valid, but the decrypted scan count value also has to be only one 25 increment higher than the previously read scan count value. If the tag ID number is valid but the scan count value is higher or lower than what is expected, it is indicative of a malicious actor and accordingly, the authentication server 101 will return an authentication failed message. 30 Optionally, responsive to a successful authentication of the scanned RFID tag, the one or more servers are further configured to: send to the customer device, information indicative of the physical location at the hospitality establishment associated with the scanned RFID tag. 09 01 25 Advantageously, the system is in this way able to provide a seamless way to not only authenticate the RFID tag to verify the physical presence of a customer, but also to send the customer device the physical location, for example table number, associated with the RFID tag they have just scanned without any of this information needing to be 5 stored in the customer device or inputted manually by the customer. Once the customer device has received the physical location information, an online menu may be displayed. Any order made by the customer may then be automatically associated with the authenticated physical location without any customer input and the order sent to an ordering system of the hospitality establisment. This in turn facilitates a seamless 10 online menu experience for the customer with a reduced risk of error. Optionally, the system comprises a setup device storing a copy of the secret key, the setup device configured to: obtain information indicative of the physical location associated with each of the plurality of RFID tags, read the plurality of RFID tags to 15 retrieve the tag identification numbers; write a copy of the secret key to the plurality of RFID tags; and send the information indicative of the physical location associated with each of the plurality of RFID tags and the corresponding tag identification numbers to the one or more servers. 20 Advantageously, providing a setup device as part of the system that is able to independently obtain the physical location information (for example by scanning a QR code on a table) and associating this information with the tag identification numbers for sending to the one or more servers facilitates use of the system with any hospitality establishment that has already a digital representation of their table arrangements, for 25 example with existing QR code based systems. Providing the setup device with the ability to write the secret key to the device also allows the system to be reprogrammed easily in the event that the secret key is compromised. Thus, the system of the present disclosure easy to use and setup, and is also easy to secure in the event of a compromise of the secret key. 30 Optionally, the setup device comprises a mobile device controlled by the hospitality establishment. 09 01 25 For example, a mobile device such as a smartphone of an employee of the hospitality establishment may be configured as a setup device by installing a software application having the above functionality. 5 Optionally, the physical location comprises a table or seating location at the hospitality establishment. Advantageously, as described above, linking the customer to a specific table or location reduces instances of customer table number error. Further, if there are issues 10 with the order or with payment it is immediately apparent who the customer is as their order is associated with their table or seating location, which has already been authenticated with the help of the RFID tag. 15 According to a second aspect, there is provided an order management system of a hospitality establishment according to claim 6. According to a third aspect, there is provided, a method of authenticating RFID tags at a hospitality establishment according to claim 7. 20 Optionally, the method comprises, responsive to a successful authentication of the scanned RFID tag, sending, with the one or more servers, to the customer device information indicative of the physical location at the hospitality establishment 25 associated with the scanned RFID tag. Optionally, the method comprises, with a setup device: storing a copy of the secret key, obtaining information indicative of the physical location associated with each of the plurality of RFID tags, reading the plurality of RFID tags to retrieve the tag identification 30 numbers; writing a copy of the secret key to the plurality of RFID tags; and sending the information indicative of the physical location associated with each of the plurality of RFID tags and the corresponding tag identification numbers to the one or more servers. 09 01 25 Optionally, the physical location comprises a table or seating location at the hospitality establishment. According to a fourth aspect, there is provided a non-transitory data carrier carrying 5 processor control code to implement the above methods. The advantages set out in respect of the first aspect are equally applicable to the corresponding second and third aspects. 10 BRIEF DESCRIPTION OF THE DRAWINGS These and other aspects will now be described by reference to the appended drawings in which: 15 Figure 1a illustratively shows an RFID authentication system according to the present disclosure. Figure 1b is a flow chart illustrating steps of the method of the present disclosure. 20 Figure 2 illustratively shows the use of a setup device of an RFID authentication system according to the present disclosure. Figure 3 illustratively shows an order authentication system and an order management system of a hospitality establishment. 25 Figure 4 is a flow chart illustrating steps of the method of the present disclosure Figure 5 is a block diagram showing a technical architecture of mobile devices according to the present disclosure. 30 Figure 6 is a block diagram showing a technical architecture of setup and / or mobile devices according to the present disclosure. 35 DETAILED DESCRIPTION 09 01 25 In general terms, Figures 1a-2 illustrate an RFID authentication system with the following elements: 5 1. An authentication server that relies on a symmetric key cipher decryption algorithm (using e.g. AES encryption protocols). 2. A plurality of RFID tags that are each associated with a physical location at the hospitality establishment. 10 3. A smart phone app under the control of the hospitality establishment for the programming of the RFID tags with e.g. the encryption protocol so that the RFID tags can encrypt their response to query messages from customer devices scanning the RFID tag. 4. A separate, backend server that hosts the venue’s menu system. 15 These, and other details, are further described below. Figure 1a illustratively shows an RFID authentication system 100 according to the present disclosure. The system comprises an authentication server 101, a backend 20 server 102, and a plurality of RFID tags 103, for example NFC enabled tags such as NTAG 424 tags. The RFID tags 103 each have stored thereon a tag identification number (ID), a scan count which is configured to increase by one each time the tag is scanned, and a copy of a secret key stored on the authentication server 101. The secret key may be configured as a key of an AES-128 encryption protocol but other 25 encryption protocols are envisaged. Figure 1a also shows a customer device 104, for example a smartphone with a software application functioning as a front end installed thereon, that may, but need not be, part of the system 100. The functionality of the frontend may be written in, for example VueJS, the functionality of the backend server 102 may be written in PHP / Laverel, and the functionality of the authentication server 30 may be written in Python, although other suitable coding frameworks may be used as will be appreciated by the skilled person. When the customer device 104 scans one of the RFID tags 103, for example by sending a query message to the RFID tag, the RFID tag 103 is configured to respond 35 105 with the tag’s ID number and the scan count that are encrypted together using the 09 01 25 secret key. This provides a unique identifier code (i.e. the ciphertext) per RFID tag per scan, which may take the form of a string comprising a URL associated with the hospitality establishment including the ciphertext appended thereto as a unique identifier for that RFID tag for that scan count (for example the following string 5 www.restaurant.com / authenticate / 7a1b2c3d4e5f6, where “a1b2c3d4e5f6” is the ciphertext appended to the URL associated with a hospitality establishment called “Restaurant’ pointing the customer device to the authentication server 101). The unique code is parsed and forwarded 106 by the customer device 104 to the authentication server 101, for example by way of the customer device 104 following the 10 URL. The authentication server 101 receives the unique code as input and, using the same AES-128 secret key as that which was used by the RFID tag, decrypts the received information to retrieve the tag ID number and scan count number. The authentication 15 server 101 checks that the retrieved tag ID is valid, for example by comparing to a stored list of known tag ID numbers and outputs a confirmation that the tag ID number is valid to thereby authenticate the scanned RFID tag. Additionally, the authentication server checks that the scan count value is only one increment higher than the previously read scan count value, which is stored on the authentication server 101. 20 Only when both the tag ID number and scan count value are deemed valid will the authentication serer 101 deem the authentication of the RFID tag successful. Upon a successful authentication, the authentication server 101 sends 107 a confirmation message back to the customer device 104, together with a copy of the tag 25 ID number, which the customer device 104 previously did not have access to given that this information was encrypted. Again, this may be in the form of a URL with the now decrypted tag ID number used appended thereto (for example the following string: www.restaurant.com / tablenumber / 7987654321, where “987654321” is the tag ID number associated with the now decrypted message from the RFID tag pointing the 30 user to the backend server 102 to retrieve the table number associated with that tag ID number). Upon receipt of the tag ID number and authentication successful message, the customer device 104 is now able to send 108 the backend server 102 the valid tag ID 35 number by following the URL it received from the authentication server. 09 01 25 Upon receipt of the valid tag ID number from the customer device 104, the backend server 102 responds to the customer device 104 with information indicative of the physical location of the scanned RFID tag, for example, the table or seating location 5 number. Again, this may be in the form of a URL (for example, the following string: “www.restaurant.com / onlinemenu / 7table123456789”, where tablel 23456789 is the table number associated with the ID tag number and the URL points the customer device 104 to the online menu of the restaurant that is associated with their specific table number. The customer device 104 can then validly use this, now authenticated, 10 table or seating location number when the customer accesses the online menu on their device 104, for example through the installed front end application or web browser which follows the received URL. If the authentication by the authentication server 101 is not successful, and / or the 15 customer device 104 attempts to send the backend server 102 an invalid tag ID number, no table or seating location number is returned by the backend server 102 and instead an error message or black screen is displayed on the front end or browser of customer’s device 104. 20 Figure 1b is a flow chart illustrating steps of the method 110 of the present disclosure. The method comprises storing 111a secret key on an authentication server, storing 112 a copy of the secret key and a tag ID number on an RFID tag, the tag associated with a physical location of a hospitality establishment, encrypting 113 the tag identification number with the secret key, responsive to the RFID tag being scanned by 25 a customer device, receiving and decrypting 114 the encrypted information at the authentication server using the secret key stored on the authentication server, and authenticating 115 the scanned RFID tag by confirming the tag identification number is a valid tag identification number. 30 Figure 2 illustratively shows the use of a setup device 200 of the RFID authentication system 100 of Figure 1a. The setup device 200 may be a mobile device such as a smart phone or tablet controlled by the hospitality establishment and be provided with a software application, for example written in Flutter™ and installed on an Android ™ or iOS ™ operating system. The setup device 200 is used to program the RFID tags and 09 01 25 to associate physical location information (such as table number) where the RFID tag is positioned with the tag ID number of the tag. For example, the RFID tags may be positioned on different tables around a hospitality 5 establishment, each table having a table number encoded in the form of a QR code 201 or other digital representation of the table number. The setup device 200 is configured to read 202 the QR code 201 to obtain the table number. The setup device 200 then scans the associated RFID tag 103 to obtain 203 the tag ID number of that tag, and at the same time to write 204 the secret key which the setup device 200 has 10 stored thereon to the RFID tag 103. The secret key is the same key that is stored on the authentication server 101 and is part of the symmetric encryption protocol used by the system 100. Upon a successful read of the QR code 201 and RFID tag 103, the setup device 200 15 associates the table number with the tag ID number and sends 205 this information, together with any additional information such as the hospitality establishment name or other identifier information, to the backend server 102. The backend server 102 stores the tag ID number in association with the table number 20 (and where present hospitality establishment name or other identifier information) in an unconfirmed state. An interface 206 controlled by the hospitality establishment in communication with the backend server 102 may then display the tag ID number and table number associates obtained by the setup device and allow an employee of the hospitality establishment to confirm or reject the setup of the RFID tags and tables, to 25 manage the system 100. Figure 3 illustratively shows an order authentication system 300 and an order management system 301 of a hospitality establishment 302 according to the present disclosure that uses an alternative system to that described in connection with Figures 30 1a, 1b and 2, namely using an asymmetric encryption protocol instead of a symmetric encryption protocol. The order authentication system 300 comprises a server 303 (or a plurality of servers arranged in communication with each other) comprising a signature authentication 35 module 304, a public key storage 305, and a key pair generator 306. The public key 09 01 25 storage 304 is configured to store the public keys of a plurality of key pairs generated by the key pair generator 306 which may be provided on the server as shown in Figure 3, or provided elsewhere for example by a third party service. The key pairs are used in the digital signature scheme of the order authentication system 300 as will be 5 described below. The server 303 is provided with a suitable communication interface (not shown) to communicate with the other features of the system, for example through the cloud 307. The system 300 further comprises a plurality of RFID tags 308a, 308b, 308c each 10 associated with a physical location at the hospitality establishment 302, for example the location or number of a given table 309a, 309b, 309c. Upon initial set up of the system 300 at a hospitality establishment, the key pair generator 306 generates a plurality of public key pairs and stores the public keys in the 15 public in the public key storage 305. The corresponding private keys are transmitted to a plurality of mobile devices 310a, 310, 310c under the control of the hospitality establishment 302. The mobile devices 310a, 310b, 310c are configured to program the RFID tags 308a, 308b, 308c to store one of the private keys they received from the server 303 on each of the RFID tags 308a, 308b, 308c. Once the private keys are 20 stored on the RFID tags 308a, 308b, 308c, the system is ready to be used. Customers enter the hospitality establishment 302, choose a table, for example table 309b and, with a customer mobile device 311, read the RFID tag 308b associated with that table 309b. The private key stored on the RFID tag 308b is thereby transferred to 25 the mobile device 311. The customer, using the mobile device accesses a web or app-based menu or ordering landing page, for example using an existing URL provided by the hospitality establishment, or by a URL also stored on the RFID tag, makes their selection from the menu, enters their payment information and submits the order. Before the order is transmitted to the order management system 301 of the 30 establishment 302, the mobile device 311 uses the private key to digitally sign the order information, and / or corresponding information associated with the order (for example a hash of the order and / or payment information). The digital signature may be applied in accordance with known asymmetric cryptography protocols, for example encrypting the information with the private key on the RFID tag. The digitally signed 09 01 25 information is then transmitted from the mobile device 311 to the server 303, for example via the internet through the cloud 307. Upon receiving the digitally signed information, the signature authentication module 5 304 of the server 303 accesses the public key storage 305 and authenticates the digital signature using the public key corresponding to the private key that was used to digitally sign the information. In accordance with known asymmetric cryptographic protocols, the authentication may comprise using the corresponding public key stored in the public key store to decrypt the received information to validate that the signature 10 is genuine. It will be appreciated that other digital signature methods may also be used. If the authentication is successful, the server 303 confirms the order is authentic (i.e. placed by a customer who is actually at the table 309b at the hospitality establishment) by sending a confirmation message to, for example, the order management system 15 301 of the hospitality establishment 302. Once the order is confirmed to be authentic, the order may be displayed on a display 312 of the order management system 301, for example in a kitchen or bar area and this prompts a member of the serving team to begin preparing the order or the customer. 20 If however the authentication is not successful, the server 303 instead sends a message to the order management system 301 indicating that the order is not authentic. In this case, the order management system 301 does not display the order on the display and the serving team does not waste time preparing the order. 25 Optionally, if the order was not successfully authenticated, the server 303 may also send an error message back to the mobile device 311 to indicate that the customer’s order was not successful and to prompt them to contact a member of the serving team and / or a customer services. 30 The authentication system may be further configured to keep track of which private and public key pairs have been used to successfully sign order information is able to prevent their re-use by removing the corresponding public key from the public key storage 305. To ensure the system does not run out of key pairs to use, new key pairs may be periodically generated and stored as described above. Thus, once a customer 35 no longer wishes to place any further orders (for example because they have left the 09 01 25 hospitality establishment) and the server has deleted the used public key from the public key storage 305, the customer is no longer able to validly sign order information. This is because the server 303 will be unable to authenticate the digital signature as public key needed to so is no longer available in the public key storage 305. Thus, if a 5 mischievous third party such as an internet or troll attempts to cause chaos by signing and submitting orders with old private keys collected from former customers, the orders will not make their way through to the display of order management system so the serving team’s time will not be wasted. 10 Whilst the order management system and order authentication system have been described above as separate systems, they may be integrated into a single system and or implemented in whole or in part on the same servers and hardware infrastructure as each other. 15 Figure 4 is a flow chart illustrating steps of the method of the present disclosure. As described above, the method 400 comprises storing 401 public keys of a plurality of key pairs on a server, storing 402 private keys of the plurality of key pairs on a plurality of RFID tags, each RFID tag associated with a physical location at the hospitality establishment; at the server, receiving 403 information associated with an order of a 20 customer of the hospitality establishment, the information digitally signed by one of the respective private keys; and authenticating 404 the digital signature of the digitally signed information using a corresponding public key of the plurality of key pairs. Figure 5 is a block diagram showing an illustrative technical architecture that may be 25 used to implement the one or more servers 101, 102, 303. The technical architecture includes a processor 500 (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage 501 (such as disk drives), read only memory (ROM) 502, random 30 access memory (RAM) 503. The processor 500 may be implemented as one or more CPU chips. The technical architecture may further comprise input / output (I / O) devices 504, and network connectivity devices 505. The secondary storage 501 is typically comprised of one or more disk drives or tape 35 drives and is used for non-volatile storage of data and as an over-flow data storage 09 01 25 device if RAM 503 is not large enough to hold all working data. Secondary storage 501 may be used to store programs which are loaded into RAM 503 when such programs are selected for execution. 5 In this embodiment, the secondary storage 501 has an order processing component 501a comprising non-transitory instructions operative by the processor 500 to perform various operations of the method of the present disclosure. The ROM 502 is used to store instructions and / or data which are read during program execution. The secondary storage 501, the RAM 503, and / or the ROM 502 may be referred to in some contexts 10 as computer readable storage media and / or non-transitory computer readable media. I / O devices 504 may include printers, video monitors, liquid crystal displays (LCDs), plasma displays, touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, or other well-known input devices. 15 The network connectivity devices 505 may take the form of modems, modem banks, Ethernet cards, universal serial bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards that promote radio communications using protocols such 20 as code division multiple access (CDMA), global system for mobile communications (GSM), long-term evolution (LTE), worldwide interoperability for microwave access (WiMAX), near field communications (NFC), radio frequency identity (RFID), and / or other air interface protocol radio transceiver cards, and other well-known network devices. These network connectivity devices 505 may enable the processor 500 to 25 communicate with the Internet or one or more intranets. With such a network connection, it is contemplated that the processor 500 might receive information from the network, or might output information to the network in the course of performing the above-described method operations. Such information, which is often represented as a sequence of instructions to be executed using processor 500, may be received from 30 and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave. The processor 500 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems 35 may all be considered secondary storage 501), flash drive, ROM 502, RAM 503, or the 09 01 25 network connectivity devices 505. While only one processor 500 is shown, multiple processors may be present. Thus, while instructions may be discussed as executed by a processor, the instructions may be executed simultaneously, serially, or otherwise executed by one or multiple processors. 5 Although the technical architecture is described with reference to a computer, it should be appreciated that the technical architecture may be formed by two or more computers in communication with each other that collaborate to perform a task. For example, but not by way of limitation, an application may be partitioned in such a way 10 as to permit concurrent and / or parallel processing of the instructions of the application. Alternatively, the data processed by the application may be partitioned in such a way as to permit concurrent and / or parallel processing of different portions of a data set by the two or more computers. In an embodiment, virtualization software may be employed by the technical architecture to provide the functionality of a number of 15 servers that is not directly bound to the number of computers in the technical architecture. In an embodiment, the functionality disclosed above may be provided by executing the application and / or applications in a cloud computing environment. Cloud computing may comprise providing computing services via a network connection using dynamically scalable computing resources. A cloud computing environment may be 20 established by an enterprise and / or may be hired on an as-needed basis from a third party provider. It is understood that by programming and / or loading executable instructions onto the technical architecture, at least one of the CPU 500, the RAM 503, and the ROM 502 25 are changed, transforming the technical architecture in part into a specific purpose machine or apparatus having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules. 30 Figure 6 is a block diagram showing a technical architecture of any one of the setup device 200 and / or the mobile devices 310a, 310b, 310c, 311. As described above, it is envisaged the setup device and / or mobile devices may be a smartphone or tablet device. Additionally or alternatively, the mobile devices and / or setup device under 09 01 25 control of the hospitality establishment may instead be dedicated RFID read and write devices. The technical architecture includes a processor 600 (which may be referred to as a 5 central processor unit or CPU) that is in communication with memory devices including secondary storage 601 (such as disk drives or memory cards), read only memory (ROM) 602, random access memory (RAM) 603. The processor 600 may be implemented as one or more CPU chips. The technical architecture further comprises input / output (I / O) devices 604, and network connectivity devices 605. 10 The I / O devices may comprise a user interface (UI) 604a, a camera 604b, a geolocation module 604c, and an RFID module 604d. The UI 604a may comprise a touch screen, keyboard, keypad or other known input device. The camera 604b allows a user to capture images and save the captured images in electronic form. The 15 geolocation module 604c is operable to determine the geolocation of the communication device using signals from, for example global positioning system (GPS) satellites. The RFID module in mobile devices 310a, 310b, 310c is configured to read and program the RFID tags 310a, 310b, 310c as described above whereas the RFID module in mobile device 311 is configured only to read the RFID tags 310a, 310b, 20 310c. The secondary storage 601 is typically comprised of a memory card or other storage device and is used for non-volatile storage of data and as an over-flow data storage device if RAM 603 is not large enough to hold all working data. Secondary storage 601 25 may be used to store programs which are loaded into RAM 603 when such programs are selected for execution. In this embodiment, the secondary storage 601 may comprise one or more submodules 601a, comprising non-transitory instructions operative by the processor 600 to 30 perform various operations of the method of the present disclosure. The ROM 602 is used to store instructions and / or data which are read during program execution. The secondary storage 601, the RAM 603, and / or the ROM 602 may be referred to in some contexts as computer readable storage media and / or non-transitory computer readable media. 35 09 01 25 The network connectivity devices 605 may take the form of modems, modem banks, Ethernet cards, universal serial bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards that promote radio communications using protocols such 5 as code division multiple access (CDMA), global system for mobile communications (GSM), long-term evolution (LTE), worldwide interoperability for microwave access (WiMAX), near field communications (NFC), radio frequency identity (RFID), and / or other air interface protocol radio transceiver cards, and other well-known network devices. These network connectivity devices 605 may enable the processor 600 to 10 communicate with the Internet or one or more intranets. With such a network connection, it is contemplated that the processor 600 might receive information from the network, or might output information to the network in the course of performing the above-described method operations. Such information, which is often represented as a sequence of instructions to be executed using processor 600, may be received from 15 and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave. The processor 600 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems 20 may all be considered secondary storage 601), flash drive, ROM 602, RAM 603, or the network connectivity devices 605. While only one processor 600 is shown, multiple processors may be present. Thus, while instructions may be discussed as executed by a processor, the instructions may be executed simultaneously, serially, or otherwise executed by one or multiple processors. 25 Whilst the foregoing description has described exemplary embodiments, it will be understood by those skilled in the art that many variations of the embodiment can be made within the scope of the invention. 09 01 25
Claims
1. An RFID tag authentication system for a hospitality establishment, the system comprising:5 one or more servers storing a secret key; anda plurality of RFID tags, each RFID tag associated with a physical location at the hospitality establishment and having stored thereon a copy of the secret key and a tag identification number;wherein, responsive to being scanned by a customer device, each RFID tag is 10 configured to encrypt the tag identification number; andwherein the one or more servers are configured to:receive the encrypted information;decrypt the encrypted information using the secret key stored on the one or more servers to retrieve the tag identification number of the scanned RFID tag; and15 authenticate the scanned RFID tag by confirming the tag identificationnumber is a valid tag identification number, wherein each RFID tag further has stored therein a scan count value indicative of a number of times the RFID tag has been scanned,wherein, responsive to being scanned by the customer device, each RFID tag is20 further configured to encrypt the tag identification number together with the scan count value with the secret key to generate a unique ciphertext for each scan.
2. The system of claim 1, wherein, responsive to a successful authentication of the scanned RFID tag, the one or more servers are further configured to:25 send to the customer device information indicative of the physical location at thehospitality establishment associated with the scanned RFID tag.
3. The system of any of claims 1 to 2, comprising a setup device storing a copy of the secret key, the setup device configured to:30 obtain information indicative of the physical location associated with each of theplurality of RFID tags,read the plurality of RFID tags to retrieve the tag identification numbers;write a copy of the secret key to the plurality of RFID tags; and09 01 25send the information indicative of the physical location associated with each of the plurality of RFID tags and the corresponding tag identification numbers to the one or more servers.5 4. The system of claim 3, wherein the setup device comprises a mobile devicecontrolled by the hospitality establishment5. The system of any one of claims 1 to 4, wherein the physical location comprises a table or seating location at the hospitality establishment.
106. An order management system of a hospitality establishment comprising: the system of any of claims 1-5; anda display located at the hospitality establishment configured to receive information indicative of a customer order from a physical location at the hospitality 15 establishment associated with a scanned RFID tag authenticated by said system.
7. A method of authenticating RFID tags at a hospitality establishment, the method comprising:with one or more servers, storing a secret key;20 with each of a plurality of RFID tags, storing a copy of the secret key and arespective tag identification number, each RFID tag associated with a physical location at the hospitality establishment;with one of the plurality of RFID tags, responsive to being scanned by a customer device, encrypting the tag identification number with the secret key; and25 with the one or more servers:receiving the encrypted information;decrypting the encrypted information using the secret key stored on the one or more servers to retrieve the tag identification number; andauthenticating the scanned RFID tag by confirming the tag identification30 number is a valid tag identification number, the method comprising storing, on each RFID tag, a scan count value indicative of a number of times the RFID tag has been scanned, andwith one of the RFID tags, responsive to being scanned by the customer device, encrypting the tag identification number together with the scan count value with 35 the secret key to generate a unique ciphertext for each scan.09 01 258. The method of claim 7, wherein, responsive to a successful authentication of the scanned RFID tag, sending, with the one or more servers, to the customer device information indicative of the physical location at the hospitality establishment 5 associated with the scanned RFID tag.
9. The method of any of claims 7 to 8, comprising, with a setup device: storing a copy of the secret key, obtaining information indicative of the physical location associated with each of 10 the plurality of RFID tags,reading the plurality of RFID tags to retrieve the tag identification numbers;writing a copy of the secret key to the plurality of RFID tags; andsending the information indicative of the physical location associated with each of the plurality of RFID tags and the corresponding tag identification numbers to the 15 one or more servers.
10. The method of claim 9, wherein the physical location comprises a table or seating location at the hospitality establishment.20 11. A non-transitory data carrier carrying processor control code to implement themethod of any one of claims 7 to 10.
Citation Information
Patent Citations
Information providing method, information providing system and relay equipment
EP1626363A1
Identification information transmission device, communication system, and communication method
EP3101579A1
Systems and methods for RFID security
US20120087501A1