Point of sale transaction interruption system
The emergency response system addresses transaction disruptions by interrupting and securely holding data at POS terminals, then resuming transactions on operable devices, enhancing operational efficiency and reducing losses during emergencies.
Patent Information
- Application Number
- JP2024188562
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-01-10
- Filing Date
- 2024-10-25
- Publication Date
- 2025-07-23
AI Technical Summary
Emergencies such as fires, gas or water leaks, and earthquakes disrupt transactions at point-of-sale (POS) terminals, leading to incomplete transactions and loss of data, adversely impacting customer experience and causing financial losses.
An emergency response system that automatically interrupts transactions, securely holds data, and resumes them on operable devices when the emergency is resolved, using a network of interconnected POS devices and a central server for diagnostic checks and data transfer.
Ensures efficient and coordinated transaction processing during and after emergencies by minimizing manual intervention, ensuring smooth transaction resumption and reducing financial losses.
Smart Images
Figure 2025108353000001_ABST
Abstract
Description
Background Art
[0001]
[0001] For example, emergencies such as fires, gas or water leaks, and earthquakes can disrupt normal operations in a retail environment. These emergencies not only pose risks to the safety and well-being of customers and staff, but also significantly disrupt the transaction procedures at point-of-sale (POS) terminals. For example, during such emergencies, customers and staff need to immediately leave the premises, so ongoing transactions are often left incomplete. After the emergency is resolved, due to unexpected disruptions, data is usually not saved to these POS terminals. The inability to effectively handle transactions during this emergency causes customers to lose sight of their intended purchases, thus not only having an adverse impact on the shopping experience but also causing financial losses to the business owner.
Brief Description of the Drawings
[0002]
Figure 1
[0002] FIG. 1 is a diagram illustrating an exemplary environment for enhanced emergency response according to some embodiments of the present disclosure.
Figure 2
[0003] FIG. 2 is a diagram illustrating a sequence for enhanced emergency response according to some embodiments of the present disclosure.
Figure 3
[0004] FIG. 3 is a diagram illustrating an exemplary method for coordinating emergency responses between POS devices when an emergency occurs according to some embodiments of the present disclosure.
Figure 4
[0005] FIG. 4 is a diagram illustrating an exemplary method for interrupting and holding transaction data by a POS device in response to a received emergency alert according to some embodiments of the present disclosure.
Figure 5
[0006] FIG. 5 is a flowchart illustrating an exemplary method for transaction interruption and data holding according to some embodiments of the present disclosure.
Figure 6
[0007] FIG. 6 is a diagram illustrating an exemplary computing device configured to perform various aspects of the present disclosure, in accordance with some embodiments of the present disclosure. DETAILED DESCRIPTION
[0003]
[0008] In at least one example, the present disclosure relates to emergency response that automatically interrupts and securely holds ongoing transactions upon detection of an emergency event and efficiently resumes these interrupted transactions at the original or alternative transaction processing device when the emergency situation has been resolved.
[0004]
[0009] In some embodiments of the present disclosure, a business site (e.g., a retail establishment) includes one or more transaction processing devices. As used herein, a "transaction processing device" can refer to a system or device used to perform and manage checkout transactions and customer interactions. In a retail environment, transaction processing devices can refer to POS terminals including, but not limited to, staffed checkout devices, self-checkout devices, mobile POS devices, and self-service kiosks.
[0005]
[0010] In some embodiments of the present disclosure, an emergency response system receives an activation signal indicating that an emergency has occurred at a business site. In some embodiments, the activation signal can be triggered by an emergency detection system including various sensors, monitoring devices, or manual alarm interfaces for detecting different types of incidents. For example, the emergency detection system can include automatic sensors for detecting fires, smoke, water leaks, or gas leaks, and / or manual alarm interfaces for reporting incidents such as robberies, medical emergencies, unauthorized access, or natural disasters. Upon receiving the activation signal, the disclosed emergency response system issues an emergency alert to one or more transaction processing devices at the business site. In some embodiments, the emergency alert can include instructions for notifying the device of the emergency and / or for the device to perform various actions such as locking down the device, interrupting ongoing transactions, and retaining transaction data (either locally or by transmitting it to a central database). In some embodiments, the emergency alert can further instruct the device to print receipts for these interrupted transactions as a record for future reference.
[0006]
[0011] In some embodiments of the present disclosure, after transmitting an emergency alert, the disclosed emergency response system continues to monitor the environment of the business site by actively listening for further signals from the emergency detection system. Upon receiving a signal indicating that the emergency has been resolved, the system performs diagnostic checks on each transaction processing device located at the business site. These checks are intended to determine the operable state of each device. If a device is determined to be operable, the system instructs the device to resume the transaction that was previously interrupted. If a device is determined to be inoperable, the system instructs an alternative operable device to resume the transaction interrupted by the original inoperable device. In some embodiments, the process may involve evaluating the operable state of other transaction processing devices at the business site or, preferably, considering devices at another site. Once a suitable alternative device is identified, the system may coordinate the transfer of transaction data from the original device (or from a central database) to the alternative device. Subsequently, the system may instruct the resumption of the interrupted transaction on the alternative device. In some embodiments, after determining which device will resume the interrupted transaction, the emergency response system may generate notifications for each customer. The notifications inform the customers of the alternative devices available to them to complete their transactions. In some embodiments, the notifications may include various forms, such as phone calls, emails, text messages, and push notifications.
[0007]
[0012] The disclosed system with technical implementations of emergency detection mechanisms, transaction data retention, and dynamic reassignment of transaction resumption tasks facilitates an efficient and automated structure that enables transaction processing devices to respond efficiently by reducing manual intervention in emergencies. As a result, the system ensures a prompt and coordinated response to transaction processing in retail situations during and after an emergency.
[0008]
[0013] FIG. 1 illustrates an exemplary environment 100 for enhanced emergency response according to some embodiments of the present disclosure.
[0009]
[0014] In some embodiments, the environment 100 for enhanced emergency response may be applicable to business sites such as retail facilities. In some embodiments, the environment 100 may include one or more transaction processing devices. As used herein, a "transaction processing device" may refer to a system or device used to perform and manage checkout transactions and customer interactions. In a retail environment, as illustrated, the transaction processing devices may refer to POS devices such as staffed checkout devices 115-1 and 115-2, self-checkout devices 120-1 and 120-2, and self-service kiosks 105-1 and 105-2. The staffed checkout device 115 may refer to a conventional checkout counter where a store employee assists a customer with their purchase. In some embodiments, the staffed checkout device 115 may include a screen (for displaying transaction details), a cash register, a barcode scanner, a weighing scale, a receipt printer, and a payment terminal (e.g., a card reader) for processing electronic payments. The staffed checkout device 115 is designed to facilitate a smooth transaction process with the assistance of a store employee. The self-checkout device 120 may refer to an automated (or semi-automated) station where a customer can complete their purchase transaction independently (or with reduced human assistance). In some embodiments, the self-checkout device 120 may include a screen (for interacting with the POS system), a barcode scanner (for scanning items), a weighing scale (for weighing items), a receipt printer, and a payment terminal. The self-service kiosk 105 may refer to a station configured for specific functions such as allowing a customer to independently access information, order out-of-stock items, or process returns without (or with reduced) human assistance. In some embodiments, the self-service kiosk 105 may include a screen (for user interaction), a built-in payment terminal for processing electronic payments, a scanner for barcodes or QR codes (registered trademarks), and a receipt printer.
[0010]
[0015] In the illustrated example, the staff placement checkout device 115, the self-checkout device 120, and the self-service kiosk 105 are interconnected and communicate with each other via the network 130. Further, as shown, each of these devices is connected to the central server 135 and / or the database 125 via the network 130 to facilitate an efficient data retention and emergency response system. The network 130 may include, or correspond to, any combination of a wide area network (WAN), a local area network (LAN), the Internet, an intranet, or a suitable communication medium that may be available, and may include wired links, wireless links, or a combination of wired and wireless links. In some embodiments, the staff placement checkout device 115, the self-checkout device 120, and the self-service kiosk 105, the central server 135, and the database 125 may be local to each other (e.g., within the same local network and / or the same hardware system), and may communicate with each other using any suitable local communication medium such as, for example, a local area network (LAN) including a wireless local area network (WLAN), a hardwire, a wireless link, or an intranet.
[0011]
[0016] In the illustrated example, during normal operating hours, each transaction processing device (in some embodiments, also referred to as a POS device) (e.g., staffed checkout device 115, self-checkout device 120, and self-service kiosk 105) within a retail establishment (e.g., a grocery store) assists customer 110 in completing various transactions. These transactions can range from completing a checkout at a staffed checkout device and / or a self-checkout device to performing tasks such as product search, placing an order, or processing a return at a self-service kiosk. For example, customer 110-1 is waiting for a store employee to complete their purchase using staffed checkout device 115-1. The checkout process can involve scanning items, bagging them, and processing payment. Customer 110-3 independently completes their purchase using self-checkout device 120-1, which can include scanning each item, bagging the items, and completing the payment process according to instructions on the screen (e.g., inserting a card or using a mobile payment option). Additionally, customer 110-5 is at self-service kiosk 105-1 and uses device 105-1 to perform tasks such as looking up information, placing an order, or processing a return of a previously purchased item without staff assistance. In some embodiments, when customer 110 interacts with these devices, transaction data may be locally stored on these devices for future reference and analysis or transmitted to central server 135 and stored in database 125.
[0012]
[0017] In the illustrated example, when an emergency occurs (e.g., when a fire or smoke alarm is triggered), the emergency response process is initiated by the central server 135. The emergency response process may include sending an emergency alert to each transaction processing device to indicate the occurrence of the emergency and / or instructing the device to perform various protective actions. In some embodiments, the protective actions performed by the transaction processing device may include, but are not limited to, locking down the device to stop new transactions, temporarily interrupting ongoing transactions, locally storing interrupted transactions or sending them to the central server 135 for centralized storage, displaying instructions or guidance to customers and staff (e.g., the route to the nearest exit or guidelines on how to stay safe during the emergency), and generating receipts for interrupted transactions.
[0013]
[0018] In some embodiments, the emergency detection system may be installed in a retail facility and communicate with the central server 135 via the network 130. In some embodiments, the emergency detection system may be configured to continuously monitor and identify the potential for an on-premises emergency. When detecting the occurrence of an emergency, the emergency detection system may send an activation signal to the central server 135 (e.g., via the network 130). The activation signal serves as a trigger for the central server 135, which subsequently initiates an emergency response process based on the received information.
[0014]
[0019] In some embodiments, the emergency detection system may include various types of sensors, monitoring devices, or manual alarm interfaces configured to monitor for emergencies within a retail facility. For example, the emergency detection system may include automatic sensors designed to detect fires, water leaks, gas leaks, and the like. In some embodiments, the emergency detection system may include a manual alarm interface (e.g., an emergency button) that enables store staff or customers to report emergency incidents such as robberies, unauthorized access, natural disasters, medical emergencies requiring attention, or other emergency situations. When these sensors detect an emergency or the manual alarm interface receives an input, the emergency detection system may send an alert (also referred to as an activation signal in some embodiments) indicating the occurrence of the emergency to the central server 135. In some embodiments, the emergency detection system may send a deactivation signal to the central server 135 when it detects that the emergency has been resolved. In some embodiments, the determination of resolution may involve manual input from a store employee or security staff member who confirms the end of the emergency after entering the premises and manually resets the system.
[0015]
[0020] In the illustrated example, upon receiving a release signal from the emergency system, the central server 135 initiates procedures to resume the transaction(s) interrupted at each transaction processing device during the emergency. For example, in some embodiments, the central server 135 may send requests to each transaction processing device (e.g., the staffed checkout device 115, the self-checkout device 120, and the self-service kiosk 105) and instruct them to perform diagnostic checks regarding their operable states. The checks may include various tests to determine whether the device is fully functional and / or ready to resume operation. The operable state of the transaction processing device may be determined from various aspects detailed below. If it is determined that the transaction processing device (e.g., the self-checkout device 120-1) is operable, i.e., components such as the barcode scanner, payment terminal, and printer within the self-checkout device 120-1 are functioning properly and the checkout transaction(s) can be completed, the central server 135 may instruct the device (e.g., 120-1) to resume the previously interrupted transaction(s). In some embodiments, the resumption process may include retrieving the saved transaction data from either local storage or the central database 125 and reloading the transaction data onto the device when the customer (e.g., 110-3) returns. If the diagnostic check reveals that the transaction processing device (e.g., the self-checkout device 120-1) is not operable, i.e., the printer within the self-checkout device 120-1 is malfunctioning, the scanner is unresponsive, or there are other connection issues, the central server 135 may check the status of other operable devices in the current retail facility, such as the self-checkout device 120-2, the staffed checkout devices 115-1 and 115-2, and the self-service kiosks 105-1 and 105-2. If none of these devices within the premises are operable, the central server may check the status of devices at another location (e.g., a neighboring retail store).When an alternative device (e.g., self-checkout device 120-2) is identified, the central server 135 can facilitate the transfer of data for the interrupted transaction from the original inoperable device (if the transaction data is stored locally) or from the central database 125 (if the transaction data is stored centrally) to the alternative operable device. Following the data transfer, the interrupted transaction(s) (e.g., of customer 110-3) are resumed on the alternative device (e.g., self-checkout device 120-2).
[0016]
[0021] In some embodiments, the resumption process (either at the original device or the alternative device) can ensure that the transaction resumes from where it was interrupted, providing a smooth and efficient experience for customers who intend to complete their transactions after the emergency has been resolved.
[0017]
[0022] FIG. 2 is a diagram 200 illustrating a sequence for enhanced emergency response according to some embodiments of the present disclosure.
[0018]
[0023] In the figure, an emergency detection system 205, an emergency response system 210, and a POS device 215 (also referred to as a transaction processing device in some embodiments) (e.g., staffed checkout device 115, self-checkout device 120, and self-service kiosk 105 of FIG. 1) are interconnected and communicate with each other to manage emergencies within an area or environment (e.g., a retail facility).
[0019]
[0024] In some embodiments, the emergency detection system 205 may incorporate various sensors (or monitoring devices) configured to detect signs of the likelihood of an emergency within an area or environment (e.g., the retail facility 100 illustrated in FIG. 1). Emergencies can include fires, gas or water leaks, natural disasters, medical emergencies requiring treatment, unauthorized access, and robberies. When such an incident is detected, the emergency detection system 205 triggers an alert 220 (also referred to as an activation signal in some embodiments) and transmits the alert 220 to the emergency response system 210. In some embodiments, the alert 220 may indicate the type of detected emergency and / or other relevant information such as the approximate location and severity of the detected emergency or the time at which the emergency was detected.
[0020]
[0025] In the illustrated example, when the emergency detection system 205 receives an alert 220, the emergency response system 210 is activated. In some embodiments, the emergency response system 210 may include a computing device (e.g., the server 135 of FIG. 1) and a software protocol for managing the response of the POS devices to the emergency. As shown, following the receipt of the activation signal 220 (indicating the occurrence of an emergency), the emergency response system 210 sends an emergency alert 225 to each POS device 215 within the area or environment monitored by the emergency detection system 205 (e.g., the retail facility 100 illustrated in FIG. 1). In some embodiments, the emergency alert 225 may notify each POS device 215 of the occurrence of the emergency and / or provide detailed information about the type, location, time, or severity of the incident. In some embodiments, the emergency alert 225 may include one or more instructions to guide the POS device 215 to perform a predefined protection action 230 in response to the emergency. In some embodiments, these protection actions may be pre-programmed and automatically triggered upon receipt of the emergency alert 225. In some embodiments, the protection actions may include, but are not limited to, locking down the POS device to prevent new transactions, interrupting ongoing transactions, securely holding the associated transaction data (either by saving the data locally or sending it to a central database), displaying an emergency message and guidance to the customer, and printing a receipt of the interrupted transaction as a record.
[0021]
[0026] In the illustrated example, after one or more of these protection actions 230 have been fully implemented, the POS device may optionally generate a response 235 (indicated by the dashed arrow) and send it to the emergency response system 210. The response may confirm the successful implementation of the commanded protection action. This feedback mechanism may enable the emergency response system 210 to accurately monitor the status of each POS device 215 within the environment.
[0022]
[0027] In the illustrated example, after sending the emergency alert 225 to the POS device 215, the emergency response system 210 continues to monitor the environment (e.g., a retail facility) by actively listening for signals from the emergency detection system 205. The continuous monitoring mechanism ensures that it can immediately detect changes or developments in the ongoing emergency. When the emergency is resolved, the emergency detection system sends a cancellation signal 240 to the emergency response system 210. Upon receiving the signal 240, the emergency response system 210 sends a status verification request 245 to each POS device within the area or environment. In some embodiments, the request 245 may prompt each POS device 215 to perform a diagnostic check regarding its operable state. In some embodiments, the diagnostic check may include, but is not limited to, checking the status of each hardware component within the POS device (e.g., barcode scanner, receipt printer, and payment terminal) to ensure it is functioning properly, checking the network connectivity of the POS device to a central server (e.g., server 135 in FIG. 1), a database (e.g., database 125 in FIG. 1), or other related network infrastructure, and verifying the software integrity and accessibility of the POS device to ensure the effective completion of checkout or other services.
[0023]
[0028] In the illustrated example, after these diagnostic checks are completed, each POS device 215 transmits a response 250 to the emergency response system 210. Within the response 250, each POS device 215 may report its operable state and / or any related data. For example, in some embodiments, the POS device 215 may report that all components are functioning properly and it is ready to resume normal operation. In some embodiments, the response 250 may indicate that the POS device is not functioning properly and / or identify the possibility of problems such as a malfunctioning printer or a network connection error. And the information about the operable state of each device provided within the response 250 is used by the emergency response system 210 to effectively adjust data transfer and / or facilitate an efficient and smooth recovery of interrupted transactions.
[0024]
[0029] In some embodiments, the recovery process can be performed on either the original device or, preferably, an alternative POS device (either located within or outside the current site or environment). For example, if the response 250 from the POS device 215 indicates that the POS device 215 is operational, i.e., each component such as the barcode scanner, printer, or payment terminal is working properly, there are no network connectivity issues, and the software is not malfunctioning, the emergency response system 210 sends a follow-up command 255 to the original POS device 215 to instruct it to resume the previously interrupted transaction(s). In some embodiments, the resumption process may involve retrieving the saved transaction data from either local storage or a central database (e.g., 125 in FIG. 1) and reloading the transaction data onto the device when the customer (e.g., 110 in FIG. 1) returns. If the response 250 from the POS device 215 indicates that the POS device 215 is not operational, i.e., components within the device are malfunctioning, there is a network connection error, or the software has a malfunction and is not executing properly, the emergency response system 210 continues to identify an alternative device that can take over the transaction processing. In some embodiments, the identification process may involve analyzing responses from other devices within the environment. If none of the POS devices within the affected retail environment are operational, the emergency response system 210 can expand the search for an alternative device to nearby retail establishments (e.g., a neighboring store or a branch of the same retail chain located near the site where the emergency occurred). Once an alternative device is identified (either within or outside the current site), the emergency response system 210 sends a follow-up command 255 to the original non-operational POS device 215 and instructs it to send any saved transaction data to the alternative device. Thereafter, the emergency response system 210 sends another command to that alternative device to instruct it to resume the interrupted transaction.In some embodiments, when transaction data is centrally stored in a database (e.g., 125 of FIG. 1), the emergency response system 210 may issue a direct command to the central database when identifying an alternative device. The command may require the central database to send the corresponding transaction data to the identified alternative POS device. This process of data transfer and coordination can ensure that the migration is efficient and smooth and that customer transactions can be restored without significant delay or inconvenience.
[0025]
[0030] In some embodiments, the emergency detection system 205 and / or the emergency response system 210 may be implemented using one or more computing devices such as the server 135 illustrated in FIG. 1 or the computing device 600 illustrated in FIG. 6. In some embodiments, multiple computing devices (e.g., server 135 of FIG. 1) may be connected together to handle different tasks initiated by the emergency detection system 205 and / or the emergency response system 210. The multiple-device approach can provide a scalable and flexible configuration that can adapt to the various needs of the environment.
[0026]
[0031] FIG. 3 illustrates an exemplary method 300 for coordinating an emergency response between POS devices when an emergency occurs, according to some embodiments of the present disclosure. In some embodiments, method 300 may be performed by one or more computing systems or devices such as the server 135 illustrated in FIG. 1, the emergency response system 210 illustrated in FIG. 2, and / or the computing device 600 illustrated in FIG. 6.
[0027]
[0032] Method 300 begins at block 305 where a computing system (e.g., server 135 of FIG. 1) receives an activation signal (e.g., 220 of FIG. 2) indicating that an emergency has occurred at a physical location (e.g., a retail facility). The emergency can include events such as a fire, gas leak, water leak, robbery, natural disaster, or other type of incident that threatens human safety at the physical location. In some embodiments, the activation signal is sent by an emergency detection system (e.g., 205 of FIG. 2) installed at the physical location and / or configured to monitor the security of the location and identify an emergency when it occurs. In some embodiments, the emergency detection system can include various sensors or monitoring devices each configured to detect a different type of emergency. For example, a smoke detector can be used to identify a fire or smoke, a motion sensor can be used to detect an intrusion, and a gas detector can be used to sense a gas leak. In addition to or instead of using these automatic sensors, the emergency detection system may also incorporate a manual alarm interface that allows on-site staff or customers to manually report an emergency.
[0028]
[0033] Upon receiving the startup signal, the computing system interrupts ongoing transactions and initiates emergency response actions to hold related data. In block 305, the computing system sends an emergency alert (e.g., 225 in FIG. 2) to each POS device located at the physical site (also referred to as a transaction processing device in some embodiments) (e.g., the staffed checkout devices 115-1 and 115-2, the self-checkout devices 120-1 and 120-2, and the self-service kiosks 105-1 and 105-1 illustrated in FIG. 1, and the POS device 215 illustrated in FIG. 2). As described above, in some embodiments, the emergency alert may indicate the occurrence of an emergency and / or provide detailed information about the type, location, time, or severity of the emergency. In some embodiments, the emergency alert may include one or more instructions to direct the POS device to perform predefined protection actions in response to the emergency. The protection actions performed by the POS device may vary depending on the type of emergency and the configuration of the POS system, and may include, but are not limited to, locking down the POS device to stop new transactions, temporarily pausing ongoing transactions, using the screen of the POS device to display emergency instructions or directions (e.g., evacuation routes, safety measures), and securely storing transaction data (either locally or by sending it to a central database). In some embodiments, the emergency alert may be sent to each POS device via an API call.
[0029]
[0034] In block 315, the computing system actively monitors the on-site environment and / or listens for further signals from the emergency detection system to track changes or progress of the detected emergency.
[0030]
[0035] In an embodiment where the POS device determines to save transaction data to a central database (e.g., 125 of FIG. 1) in response to an emergency alert, the process may involve first sending the data to a computing system for compilation and aggregation. This step may provide that transaction data from each POS device at the physical site is processed in an adjusted and efficient manner. When receiving transaction data from each POS device, at block 320, the computing system may aggregate the data to create a data set and send it to a central database (e.g., 125 of FIG. 1) for storage. In some embodiments, during the transmission from the computing system to the central database, the computing system may encrypt the data (e.g., by using a secure transmission protocol) to protect the data from threats or the possibility of damage.
[0031]
[0036] At block 320, the computing system determines whether a release signal (e.g., 240 of FIG. 2) has been received. The release signal is received from an emergency detection system (e.g., 205 of FIG. 2) and may indicate that the detected emergency at the physical site has been resolved and / or the situation is under control. If the computing system receives the release signal, method 300 proceeds to block 325 where the computing system starts a diagnostic check for each POS device. If the release signal is not received, method 300 returns to block 315 and the computing system continues to monitor the environment and listen for further signals from the emergency detection system.
[0032]
[0037] In block 330, the computing system initiates a diagnostic check for each POS device (e.g., by sending a state verification request 245 to the POS device 215 as shown in FIG. 2). The diagnostic check is designed to determine whether each POS device is functioning properly and / or is ready to resume normal operation. In some embodiments, the diagnostic check initiated by the computing system for each POS device may include a thorough inspection of both hardware components and software components to ensure that they are functioning properly. These checks may further include verifying that each POS device is properly connected to the network and can communicate with the computing system or other systems for synchronized operation and data management.
[0033]
[0038] In block 335, based on the diagnostic response (or report) sent by each POS device (e.g., 250 in FIG. 2), the computing system determines whether each device is operational. In some embodiments, the response may include a determination made by the POS device based on that check, reporting whether it is functioning properly. In some embodiments, the response may provide detailed information about specific aspects of the device's functionality, such as the functionality of the hardware components, the integrity of the software components, and the network connectivity. In some embodiments, a POS device may be considered operational if both its hardware components (e.g., printer, barcode scanner, or payment terminal) and software components (e.g., operating system or checkout application) are functioning properly and its network connection is stable and secure. If a problem such as a malfunctioning printer or a network error is detected in any of these areas, the device may be considered inoperable.
[0034]
[0039] If it is determined that the POS device is operational, method 300 proceeds to block 340 where the computing system instructs the POS device to resume any previously interrupted transaction(s). The resumption process may include retrieving transaction data from its local storage or a central database and reloading the data onto the device when the customer returns. If it is determined that the POS device is inoperable, method 300 moves to block 345 where the computing system continues to identify an alternative device. The identification process may begin by inspecting other POS devices within the same location. If none of the POS devices at the current location are determined to be operational, the search may extend to POS devices outside the location (e.g., a POS device located at a nearby retail location close to where the emergency occurred). After an alternative operational POS device is identified, method 300 moves to block 350 where the computing system adjusts the data transfer and resumes the interrupted transaction. The data transfer may occur directly from the original inoperable POS device or from a central database, depending on where the transaction data was stored. Following the data transfer, the computing system then sends instructions to the alternative device to resume the transaction previously interrupted at the original POS device.
[0035]
[0040] In block 355, the computing system communicates with customers whose transactions were interrupted during an emergency. For example, the computing system generates notifications to these customers, informs the customers about the status of their transactions, and / or instructs the customers on how to complete these interrupted transactions. The notifications can include various forms depending on the customers' preferences and available contact information. The notifications can include email, push notifications (of mobile applications), text messages, and phone calls. In some embodiments, the notifications can include clear guidance on where and how the customers can complete their transactions, such as visiting a POS device in the venue later, visiting a POS device in a neighboring venue, or completing the transaction online. To send these notifications, the computing system can retrieve the contact information of the customers associated with each interrupted transaction from various sources. This can include the customers' loyalty accounts, previous registration records, or contact information entered by the customers during the transaction process. By providing timely and clear communication to the customers, the computing system can reduce the inconvenience caused by the emergency situation at the venue and maintain a good relationship with the customers.
[0036]
[0041] Figure 4 illustrates an exemplary method 400 for interrupting and holding transaction data by a POS device in response to a received emergency alert, according to some embodiments of the present disclosure. In some embodiments, method 400 can be performed by one or more computing devices or systems, such as the staff checkout devices 115-1 and 115-2, the self-checkout devices 120-1 and 120-2, and the self-service kiosks 105-1 and 105-2 illustrated in FIG. 1, and / or the POS device 215 illustrated in FIG. 2.
[0037]
[0042] In block 405, a POS device (also referred to as a transaction processing device in some embodiments) (e.g., the self-checkout device 120-1 of FIG. 1) receives an emergency alert (e.g., 225 of FIG. 2). The emergency alert is transmitted by an emergency response system (e.g., 210 of FIG. 2) and may indicate that an emergency situation has occurred at the location where the POS device is located (e.g., a retail facility). In some embodiments, the alert may include detailed information about the detected emergency situation, such as the type of emergency (e.g., fire and gas leak, etc.), its location, time, and severity. In some embodiments, the alert may include an instruction to trigger the POS device to perform a specific predefined protection action.
[0038]
[0043] In block 410, in response to the emergency alert, the POS device performs a protection action designed to protect customers, staff, and secure transaction data during the emergency. In some embodiments, the protection action is pre-programmed in the POS device and can be automatically triggered upon receipt of the emergency alert. The protection action performed by the POS device may include locking down the device to prevent new transactions from being initiated, and instructing staff and customers to focus on the current emergency situation. In some embodiments, the action may extend to temporarily pausing ongoing transactions when the emergency alert is received and / or securely holding the corresponding transaction data. Depending on the system configuration, the POS device may save the transaction data locally or transmit it to a database for centralized storage. In some embodiments, the action may further include displaying an emergency message or instruction on the screen of the POS device and / or printing receipts for these interrupted transactions. In some embodiments, the emergency message displayed by the POS device may include a route for safe evacuation and / or the location of the emergency exits at the current site. In some embodiments, these printed receipts for the interrupted transactions serve as a physical record and can be used by customers or staff to resume or verify these transactions after the emergency situation has been resolved.
[0039]
[0044] In block 415, the POS device determines whether a request for a diagnostic check (e.g., 245 in FIG. 2) has been received. The request can be sent by the emergency response system (e.g., 210 in FIG. 2) when the emergency response system determines that the detected emergency at the scene has been resolved. If the POS device receives the request, method 400 proceeds to block 420 where the POS device evaluates its operable state. The check can include a thorough inspection of various aspects of the device. For example, the check can involve inspecting each of the hardware components of the POS device, such as a barcode scanner, receipt printer, payment terminal, and other peripheral device parts, to ensure that each of these components is working properly. In some embodiments, the check can involve ensuring that there are no physical damages, malfunctions, or performance issues that can prevent the device from performing transactions. In some embodiments, the software of the POS device, such as the operating system, transaction processing application, or other related software, can also be considered to ensure that there are no software errors, damages, or defects. The check can also include identifying signs of unauthorized access or security violations that can cause a disruption in its functionality. In some embodiments, the network connection of the POS device can also be verified to ensure that the device is stable and secure and that the device can communicate efficiently with a central server, database, or other systems or devices without interruption. If the request is not received by the POS device, method 400 returns to block 410 and the POS device maintains its emergency mode and listens for further requests.
[0040]
[0045] After completing the operational status check, at block 425, the POS returns a response to the emergency response system (e.g., 250 in FIG. 2), reporting the result of the check and / or its post-emergency status. In some embodiments, the response may include a self-determination made by the POS device based on that check, indicating whether it is functioning properly and ready to resume normal operation. In some embodiments, the response may provide detailed information about the check result. For example, the response may report the operational status of each hardware component, indicate details of any software-related issues, and / or verify the stability and security of the device's network connection. Based on the response, in some embodiments, the emergency response system may evaluate whether the POS device is operational. Depending on the evaluation, the emergency response may issue corresponding follow-up instructions.
[0041]
[0046] At 430, the POS device receives a follow-up instruction from the emergency response system. If the POS device is determined to be operational, the instruction may guide the POS device to retrieve transaction data (from either its local storage or a central database) and / or resume a previously interrupted transaction. If the POS device is determined to be non-operational, the instruction may direct the POS device to send the transaction data stored locally to an alternative operational device (either within or outside the current site). In some embodiments where transaction data is centrally stored in a database (e.g., 125 in FIG. 1) during an emergency, if the POS device is found to be non-operational, the non-operational POS device may not need to receive a follow-up instruction regarding data transfer. Instead, the emergency response system may communicate directly with the central database and instruct the database to send the corresponding transaction data to a specified alternative POS device.
[0042]
[0047] FIG. 5 is a flow diagram illustrating an exemplary method 500 for transaction interruption and data retention according to some embodiments of the present disclosure.
[0043]
[0048] At block 505, a computing system (e.g., server 135 illustrated in FIG. 1, or emergency response system 210 illustrated in FIG. 2) receives an activation signal indicating an event that occurred at a first location.
[0044]
[0049] At block 510, the computing system transmits an alert to a set of transaction processing devices at the first location, instructing each individual transaction processing device in the set of transaction processing devices to interrupt each respective transaction that is pending completion. In some embodiments, the alert may further instruct each individual transaction processing device in the set of transaction processing devices to (i) locally store each respective interrupted transaction, (ii) transmit each respective interrupted transaction to a central database for storage, or (iii) print each respective interrupted receipt to provide tangible evidence of each respective interrupted transaction.
[0045]
[0050] At block 515, the computing system receives a deactivation signal indicating that the event has been resolved.
[0046]
[0051] At block 520, in response to receiving the deactivation signal, the computing system performs a diagnostic check on each of the set of transaction processing devices to determine an operational state. In some embodiments, at least one of the activation signal and the deactivation signal may be triggered by an event detection mechanism at a physical location, and the event detection mechanism may comprise a set of sensors designed to detect different types of events.
[0047]
[0052] In block 525, the computing system determines that one transaction processing device is operable from a set of transaction processing devices.
[0048]
[0053] In block 530, in response to determining that the transaction processing device is operable, the computing system instructs the transaction processing device to resume each transaction interrupted by the transaction processing device.
[0049]
[0054] In some embodiments, upon determining that a second transaction processing device from the set of transaction processing devices is not operable, the computing system may identify an alternative transaction processing device and instruct the alternative transaction processing device to resume each transaction interrupted by the second transaction processing device. In some embodiments, the alternative transaction processing device may comprise at least one of (i) a third transaction processing device from the set of transaction processing devices at a first location, or (ii) a fourth transaction processing device at a second location.
[0050]
[0055] In some embodiments, the computing system may further receive transaction data from each of the set of transaction processing devices and store the received transaction data in a database.
[0051]
[0056] In some embodiments, the computing system may further generate a notification for completing each transaction interrupted by each individual transaction processing device. In some embodiments, the notification may comprise at least one of an email, a text message, a phone call, or a push notification, and the notification may be sent to one or more customer devices via a network connection.
[0052]
[0057] Figure 6 illustrates an exemplary computing device 600 configured to perform various aspects of the present disclosure, according to some embodiments of the present disclosure. Although illustrated as a physical device, in some embodiments, the computing device 600 may be implemented using virtual device(s) and / or across multiple devices (e.g., in a cloud environment). The computing device 600 may be embodied as any computing device or system, such as the server 135 illustrated in FIG. 1, the emergency detection system 205 and the emergency response system illustrated in FIG. 2.
[0053]
[0058] As illustrated, the computing device 600 includes a CPU 605, a memory 610, a storage 615, one or more network interfaces 625, and one or more I / O interfaces 620. In the illustrated embodiment, the CPU 605 fetches and executes programming instructions stored in the memory 610, and stores and retrieves application data present in the storage 615. The CPU 605 generally represents a single CPU and / or GPU, multiple CPUs and / or GPUs, a single CPU and / or GPU having multiple processing cores, etc. The memory 610 is generally considered to represent random access memory. The storage 615 may be any combination of, for example, a disk drive, a flash-based storage device, and may include fixed and / or removable storage devices such as a fixed disk drive, a removable memory card, a cache, an optical storage, a network attached storage (NAS), or a storage area network (SAN).
[0054]
[0059] In some embodiments, I / O device 635 (such as a keyboard, monitor, etc.) is connected via I / O interface(s) 620. Further, via network interface 625, computing device 600 can be communicatively coupled to one or more other devices and components (such as via a network that may include, for example, the Internet and local network(s)). As shown, CPU 605, memory 610, storage 615, network interface(s) 625, and I / O interface(s) 620 are communicatively coupled by one or more buses 630.
[0055]
[0060] In the illustrated embodiment, memory 610 includes emergency detection component 650 and emergency response component 655. Although illustrated as separate components for conceptual clarity, in some embodiments, the operations of the illustrated components (and others not shown) may be combined and distributed among any number of components. Further, although illustrated as software present in memory 610, in some embodiments, the operations of the illustrated components (and others not shown) may be implemented using hardware, software, or a combination of hardware and software.
[0056]
[0061] In the illustrated embodiment, an emergency detection component 650 (which may correspond to the emergency detection system 205 of FIG. 2) is configured to monitor an area or environment, such as a retail facility (e.g., 10 of FIG. 1), for signs of the potential for an emergency. This may include monitoring a wide range of incidents such as fires, gas or water leaks, natural disasters, and other threats. The emergency detection component 650 may utilize various sensors, monitoring devices, or manual alarm interfaces to identify an emergency. When an emergency is detected, the emergency detection component 650 may generate an alarm (also referred to as an activation signal in some embodiments) (e.g., 225 of FIG. 2) and transmit the alarm to an emergency response component 655 or other related components or systems. In some embodiments, the alarm may be able to indicate the occurrence of an emergency and may include information about the type, location, time, or severity of the emergency. In some embodiments, the alarm may activate the emergency response component 655 to initiate and coordinate a response to the emergency.
[0057]
[0062] In the illustrated embodiment, an emergency response component 655 (which may correspond to the emergency response system 210 of FIG. 2) is configured to initiate protection operations for transaction processing devices during an emergency and coordinate the recovery of interrupted transactions on these devices after the emergency. In some embodiments, when the emergency response component 655 receives an alert from the emergency detection component 650, it may send the alert to transaction processing devices (also referred to as POS devices in some embodiments) within the same site and instruct these devices to perform appropriate protection operations during the emergency. The protection operations may include, but are not limited to, locking down these transaction processing devices to stop new transactions, temporarily interrupting ongoing transactions, locally storing or transmitting interrupted transactions to a central database, displaying instructions or guidance to customers and staff, and generating receipts for interrupted transactions. In some embodiments, after sending instructions to the transaction processing devices, the emergency response component 655 may continue to monitor the environment by actively listening for further signals from the emergency detection component 650 and / or updating the transaction processing devices in real time. After the emergency has been resolved, the emergency response component 655 may receive a release signal (e.g., 240 of FIG. 2) from the emergency detection component 650. Based on that signal, the emergency response component 655 may initiate the post-emergency recovery process. For example, in some embodiments, the emergency response component 655 may instruct each transaction processing device to perform a diagnostic check regarding its operable state. These checks may include, but are not limited to, verifying the functionality of the device's software and hardware and validating its network connection. Once it is determined that the transaction processing device is operable, the emergency response component 655 may instruct the device to resume the previously interrupted transactions. This may involve retrieving the stored transaction data from either local storage or a central database and preparing the device to complete these transactions when the customer returns.If it is determined that the transaction processing device is not operable, the emergency response component 655 may analyze the check results of other devices to identify an alternative operable device. Once such a device is identified, the emergency response component 655 may coordinate the transfer of transaction data from the original inoperable device to the alternative device. And the emergency response component 655 may instruct the alternative device to resume the previously interrupted transaction. In some embodiments, based on post-emergency arrangements (e.g., determining which transaction processing device resumes each transaction), the emergency response component 655 may subsequently generate notifications for the customer. These notifications may inform the customer about the device (or location) that the customer can use to complete their transactions after the emergency.
[0058]
[0063] In the illustrated example, the storage 615 may include the interrupted transaction data 670 and the emergency record 675. In some embodiments, the above data may be stored in a remote database (e.g., 125 of FIG. 1) connected to the computing device 600 via a network (e.g., 130 of FIG. 1).
[0059]
[0064] The descriptions of the various embodiments of the present disclosure are presented for purposes of illustration, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein are chosen to best explain the principles of the embodiments, actual applications, or technical improvements found in the marketplace, or to enable other ordinary skill in the art to understand the embodiments disclosed herein.
[0060]
[0065] The following refers to the embodiments presented in the present disclosure. However, the scope of the present disclosure is not limited to the specific described embodiments. Instead, any combination of the following features and elements is contemplated for implementing and practicing the contemplated embodiments, regardless of whether they are relevant to various embodiments. Further, the embodiments disclosed herein may achieve other possible solutions or advantages over the prior art, but whether a particular advantage is achieved by a given embodiment does not limit the scope of the present disclosure. Accordingly, the following aspects, features, embodiments, and advantages are merely illustrative and are not to be considered as elements or limitations of the claims, unless explicitly recited in the following claims (one or more). Similarly, references to "the present disclosure" should not be construed as a generalization of the subject matter of any invention disclosed herein and should not be considered as an element or limitation of the claims, unless explicitly stated in the following claims (one or more).
[0061]
[0066] Aspects of the present disclosure may take the form of embodiments that are entirely hardware, embodiments that are entirely software (including firmware, resident software, microcode, etc.), or embodiments combining software aspects and hardware aspects, all of which may generally be collectively referred to herein as "circuits," "modules," or "systems."
[0062]
[0067] The present disclosure may be a system, method, and / or computer program product. The computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to implement aspects of the present disclosure.
[0063]
[0068] A computer-readable storage medium can be a tangible device that holds and stores instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of further specific examples of computer-readable storage media includes portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile discs (DVDs), memory sticks, floppy (registered trademark) disks, punch cards or mechanical encoding devices such as raised structures in the form of grooves in which instructions are recorded, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, should not be considered to be, in itself, a transitory signal such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through an electric wire.
[0064]
[0069] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing devices / processing devices, or to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing device / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within each respective computing device / processing device.
[0065]
[0070] Computer-readable program instructions for carrying out operations of this disclosure may be any combination of source code or object code written in any one of one or more programming languages, including assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or object-oriented programming languages such as Smalltalk, C++, and conventional procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit for performing aspects of this disclosure.
[0066]
[0071] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.
[0067]
[0072] These computer-readable program instructions are provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine that causes the instructions executed by the processor of the computer or other programmable data processing apparatus to implement the functions / operations specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other devices to function in such a way that a product comprising the computer-readable storage medium storing instructions for implementing the functions / operations specified in one or more blocks of the flowchart and / or block diagram is provided.
[0068]
[0073] These computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to implement the functions / operations specified in one or more blocks of the flowchart and / or block diagram, thereby producing a computer-implemented process.
[0069]
[0074] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram can represent one or more executable instructions for implementing the specified logical function(s), a module, segment, or portion of the instructions. In some alternative implementations, the functions shown within a block may be performed out of the order described in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or in some cases, the blocks may be executed in the reverse order depending on the functions involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or by a combination of dedicated hardware and computer instructions.
[0070]
[0075] Embodiments of the present disclosure can be provided to end users through a cloud computing infrastructure. Cloud computing generally refers to provisioning scalable computing resources as services over a network. More formally, cloud computing can be defined as a computing function that enables convenient and on-demand network access to a shared pool of configurable computing resources that abstracts the computing resources from their underlying technical architecture (e.g., servers, storage, network) and can be rapidly provisioned and released with minimal administrative effort or service provider interaction. Thus, cloud computing enables users to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) within the "cloud" without concern for the underlying physical systems (or their locations) used to provide the computing resources.
[0071]
[0076] Typically, cloud computing resources are provided to users on a pay-per-use basis, where users are billed only for the computing resources they actually use (e.g., the amount of storage space consumed by the user or the number of virtualized systems instantiated by the user). Users can access any of the resources present in the cloud at any time from anywhere on the Internet. In the context of the present disclosure, a user can access available applications (e.g., an emergency response application) or related data within the cloud. For example, an emergency response application can perform data processing, generate corresponding instructions, and store related results in a storage location within the cloud via the cloud computing infrastructure. By doing so, the user can access this information from any computing system connected to a network (e.g., the Internet) connected to the cloud.
[0072]
[0077] Although the above is directed to embodiments of the present disclosure, other further embodiments of the present disclosure may be devised without departing from its basic scope, which is determined by the following claims.
Claims
1. Receiving an activation signal indicating an event that occurred at a first location, Sending, to each transaction processing device in a set of transaction processing devices at the first location, an alert instructing the transaction processing device to interrupt incomplete transactions, Receiving a cancellation signal indicating that the event has been resolved, In response to receiving the cancellation signal, performing a diagnostic check on each transaction processing device in the set of transaction processing devices to determine an operable state, Determining an operable transaction processing device from the set of transaction processing devices, In response to the determination of the operable transaction processing device, instructing the operable transaction processing device to resume the transaction interrupted by the operable transaction processing device, A method comprising the above steps.
2. Determining a second inoperable transaction processing device from the set of transaction processing devices, Identifying an alternative transaction processing device, Instructing the alternative transaction processing device to resume the transaction interrupted by the second transaction processing device, The method according to claim 1, further comprising the above steps.
3. The method according to claim 2, wherein the alternative transaction processing device comprises at least one of (i) a third transaction processing device in the set of transaction processing devices at the first location, or (ii) a fourth transaction processing device at a second location.
4. The method according to claim 1, wherein at least one of the activation signal and the cancellation signal is triggered by an event detection mechanism at the first location, and the event detection mechanism comprises a set of sensors designed to detect different types of events.
5. The alert further instructs each transaction processing device in the set of transaction processing devices to at least further perform one of (i) locally storing the interrupted transaction, (ii) sending the interrupted transaction to a central database for storage, or (iii) printing an interrupted receipt to provide tangible evidence of the interrupted transaction. The method according to claim 1.
6. Receiving transaction data from each transaction processing device in the set of transaction processing devices, Storing the received transaction data in a database, The method according to claim 1, further comprising **Claim 7** The method according to claim 1, further comprising generating a notification for completing the transaction interrupted at each transaction processing device. **Claim 8** The method according to claim 7, wherein the notification comprises at least one of an email, a text message, a phone call, or a push notification, and the notification is sent to one or more customer devices via a network connection. **Claim 9** One or more processors; One or more memories storing a program that performs operations when executed by any combination of the one or more processors; A system comprising: Receiving an activation signal indicating an event occurring at a first location; Sending an alert to a set of transaction processing devices at the first location, instructing each transaction processing device in the set to interrupt incomplete transactions; Receiving a deactivation signal indicating that the event has been resolved; In response to receiving the deactivation signal, performing a diagnostic check on each transaction processing device in the set of transaction processing devices to determine an operable state; Determining an operable transaction processing device from the set of transaction processing devices; In response to the determination of the operable transaction processing device, instructing the operable transaction processing device to resume the transaction interrupted by the operable transaction processing device; A system comprising. **Claim 10** When the program is executed by any combination of the one or more processors, determining a second inoperable transaction processing device from the set of transaction processing devices; Identifying an alternative transaction processing device; Instructing the alternative transaction processing device to resume the transaction interrupted by the second transaction processing device; The system according to claim 9, further comprising an operation of performing. **Claim 11** The system according to claim 10, wherein the alternative transaction processing device comprises at least one of (i) a third transaction processing device in the set of transaction processing devices at the first location, or (ii) a fourth transaction processing device at a second location. **Claim 12** At least one of the start signal and the cancellation signal is triggered by an event detection mechanism at the first location, the event detection mechanism comprising a set of sensors designed to detect different types of events, the system of claim 9.
13. The alert further instructs each transaction processing device of the set of transaction processing devices to (i) locally store the interrupted transaction, (ii) transmit the interrupted transaction to a central database for storage, or (iii) print an interrupted receipt to provide tangible evidence of the interrupted transaction, the system of claim 9.
14. The program further performs an operation comprising generating a notification for completing the transaction interrupted at each transaction processing device when executed on any combination of the one or more processors, the system of claim 9.
15. The notification comprises at least one of an email, a text message, a phone call, or a push notification, and the notification is transmitted to one or more customer devices via a network connection, the system of claim 14.
16. When executed by the operation of a computer system, Receiving a start signal indicating an event that occurred at a first location; Sending to the set of transaction processing devices an alert instructing each transaction processing device of the set of transaction processing devices at the first location to interrupt an incomplete transaction; Receiving a cancellation signal indicating that the event has been resolved; In response to receiving the cancellation signal, performing a diagnostic check on each transaction processing device of the set of transaction processing devices to determine an operable state; Determining an operable transaction processing device from the set of transaction processing devices; In response to the determination of the operable transaction processing device, instructing the operable transaction processing device to resume the transaction interrupted at the operable transaction processing device; One or more non-transitory computer-readable media comprising computer program code for performing the operations in any combination.
17. When the computer program code is executed by the operation of a computer system, it determines a second transaction processing device that is not operable from among the set of the transaction processing devices, identifies an alternative transaction processing device, and instructs the alternative transaction processing device to resume the transaction interrupted by the second transaction processing device, The one or more non-transitory computer-readable media according to claim 16, further performing an operation comprising.
18. The alternative transaction processing device comprises at least one of (i) a third transaction processing device among the set of the transaction processing devices at the first location, or (ii) a fourth transaction processing device at a second location. The one or more non-transitory computer-readable media according to claim 17.
19. The alert instructs each transaction processing device in the set of the transaction processing devices to further perform at least one of (i) locally storing the interrupted transaction, (ii) transmitting the interrupted transaction to a central database for storage, or (iii) printing an interrupted receipt to provide tangible evidence of the interrupted transaction. The one or more non-transitory computer-readable media according to claim 17.
20. When the computer program code is executed by the operation of a computer system, receives transaction data from each transaction processing device in the set of the transaction processing devices, stores the received transaction data in a database, The one or more non-transitory computer-readable media according to claim 16, further performing an operation comprising.