Patent Application
20220027874
Automated banking services are becoming more and more common. For example, banking customers may conduct many banking transactions remotely from a permanent, physical “brick and mortar” bank building. Automated teller services machines (ATM), home computers, mobile devices, etc. are all employed to conduct remote banking transactions. As a result, face-to-face cash transactions are less frequent. Thus, if events occur that disrupt digital communications, banking and other business and personal transactions become more difficult. For instance, during a disaster event such as a storm, flood, fire, etc., normal business and communication services may be interrupted. Moreover, when communications are interrupted, other vital human needs such as medical treatment, housing, food and water provisions, etc. may also be interrupted.
In accordance with certain aspects of the present disclosure, autonomous mobile banking systems and methods for providing disaster-relief in an area impacted by a disaster event include a plurality of autonomous mobile banking units (MBU), each of which have an autonomous vehicle including an automated teller machine (ATM). Computer-readable data storage media accessible by a processor store program instructions that configure the processor to implement various disclosed operations. In some examples, data are received from a plurality of data sources. The data are analyzed prior to the disaster event, and based on this analysis, a plurality of locations for deployment of the plurality of MBUs, respectively, is determined. The plurality of MBUs are autonomously deployed to the respective plurality of locations in response to the event.
In accordance with other examples, data are received from a plurality of data sources. The data are analyzed and a plurality of locations for deployment of a plurality of MBUs, respectively, are determined based on the data analysis. The MBUs are autonomously deployed to the respective plurality of locations in response to the event. Wireless communication is established between a first MBU and a second MBU of the plurality of MBUs. The first one of the plurality of MBUs is moved to an alternative location while maintaining the wireless communication with the second MBU.
In accordance with further examples, data are received from a plurality of data sources and analyzed prior to and after a disaster event. A plurality of locations for deployment of a plurality of MBUs, respectively, are determined based on the analysis of data prior to the event. Based on the analysis of data after the event, an alternative location for deployment of a first MBU of the plurality of MBUs is determined.
In the following Detailed Description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. The following detailed description, therefore, is not to be taken in a limiting sense.
The present disclosure generally relates to disaster relief in an area impacted by a disaster event sufficient to interrupt normal business and communication services. Such disasters can include storms, hurricanes, floods, fires, and the like. Autonomous mobile banking units (MBU), which include an autonomous vehicle, are equipped so as to conduct automated banking services, such as with an automated banking teller machine (ATM). As used herein, an autonomous vehicle refers to a vehicle that can detect its surroundings and navigate with little or no human input. Techniques such as radar, a global positioning system (GPS) and computer vision can be used to navigate the autonomous vehicle. Machine learning and predictive analytics in combination with a fleet of the autonomous MBUs are combined to service groups of customers in an area that has been impacted by a disaster event.
During and/or following a disaster event, residents in and around the affected area are often cut off from being able to communicate with loved ones and may need banking services for repairing homes and possessions, and meeting basic needs such as food and water and shelter. Banking services can include cash deposits and withdrawals for individual customers. Additional services provided by financial institutions during and following disaster events could include distributing or revaluing prepaid cards with funds to individual customers, as well as to non-profit organizations such as the Red Cross and other organizations for distribution as necessary. Moreover, in accordance with aspects of the present disclosure, MBUs may be deployed to provide services in addition to traditional banking services, such as facilitating communication and basic internet access.
Referring back to
The server computer 210 is accessible by the ATM 130, and may process various transactions via the ATM 130. A user device 124, such as a customer's smart phone, may also facilitate customer transactions conducted via the MBU 100. Information relating to financial transactions from the ATM 130, as well as other ATM and autonomous vehicle information may be transmitted to the server computer 210, either directly or via the network 120. Financial information and other information generated by the server computer 210 may also be transmitted to the autonomous vehicle 102 and the ATM 130 of the MBU 100.
Both the controller 110 and the server computer 210 include a processor and a memory accessible by the processor storing program instructions that configure the computer corresponding computers to implement various processes disclosed herein. In some examples, the server 210 can be one of a network of servers (e.g., a “cloud”) of the system 10. Further, each server in the network of servers can be adapted to perform a specific function or functions on behalf of the system 10. Although specific functionalities will be attributed to the server 210 (and/or controller 110) in this disclosure, it should be appreciated that the same functionalities can be divided among a network of interconnected servers. Thus, throughout this disclosure, the server 210 can alternatively be understood as a single server or a network of servers.
The server computer 210 receives data 220 via various devices and databases.
In response to a disaster event, MBUs 100 are autonomously deployed to the respective locations in operation 316. As used herein, autonomously deployed refers to moving the MBUs 100 to their respective locations to provide financial and other services during or following a disaster event, without a human driver operating the MBUs 100. Instead, the autonomous vehicle 102 is operated to deploy the ATM 130 to the predetermined locations without necessarily requiring a human driver. For instance, this allows deploying manpower to other locations where disaster relief is required. Moreover, deployment locations and routes to such locations for the MBUs could be impacted by the disaster event, such that conditions could be unsafe for a human operator.
In some examples, communications between two or more of the MBUs is established in operation 318. For instance, a wireless mesh network may be established via the MBUs to allow customers to communicate for banking and other purposes following the disaster event. Generally, a mesh network is a network topology in which each node (the deployed MBUs) relays data for the network. All mesh nodes cooperate in the distribution of data in the network. It can be applied to both wired and wireless networks. Such mesh networks could be implemented by any suitable form of network topology, and are thus particularly well suited for use following a disaster event.
Typically, mesh networks are ad hoc networks, and are continuously self-configuring. As such, each MBU 100 in the network may move independently in any direction as dictated by disaster relief needs. In some examples, the MBU nodes of the network are moved so as to maintain the network, such as by limiting movement of particular MBUs 100, and or configuring the MBUs to change its links to other MBUs or other devices as necessary to maintain the mesh network.
In the illustrated example, the data analysis process 312 is used in a machine learning process to predict and determine the initial locations for deployment of the MBUs in response to the disaster event. In some implementations, the data analysis 312 continues during and after the disaster event, and may include continuously receiving and analyzing customer data, such as customer transaction and location data. Based on this and other data analysis, the MBU locations may be adjusted in real time, as required based on relief effort needs resulting from the disaster event, as shown in operation 320. At appropriate times, one or more of the MBUs 100 may be autonomously redeployed to the alternative locations in operation 322. As noted above, such movement of MBUs may be conducted so as to maintain the established communications network.
In the illustrated example, the system 10 uses machine learning, based on previous (pre-disaster) data analysis. Such pre-disaster data may include, for example, customer transaction history to determine the initial geographic locations in which to deploy the MBUs 100. In
Once the MBUs are initially deployed, the machine learning can continue continued data analysis, such as analysis of customer transactions that are being transacted within the disaster zone 400, and/or customer location information provided by GPS functions of user devices 124 to determine when and where the MBUs 100A, 100B, 100C should be geographically located.
Such data analysis and machine learning algorithms may, for example, divide the day into day parts (morning-noon-night, by the hour, day of week, etc.) to understand how and when the MBUs 100A, 100B, 100C should be relocated during the day. As example, if a particular retail establishment is operational following the disaster event, and is open from 9 am-5 pm, one of the MBUs could be located near the retail establishment during those hours. The same MBU could be redeployed to an alternative location after 5 pm.
The pre-disaster data analysis may also determine how many MBUs 100 to send into the disaster zone 400 to meet the transaction needs of the customers 420A, 420B, 420C, 420D. In the example of
In the illustrated example, each of the MBUs 100A, 100B, 100C maintains wireless coverage with at least one other MBU to establish and maintain a reliable wireless network 410. In this regard, the area of the network 410 covers only a portion of the total disaster area 400. The size and shape of the coverage of the network 410 will typically change as the MBUs relocate 100A, 100B, 100C, depending on the size of the disaster area and the number of MBUs 100 available for deployment. Thus, where the disaster area 400 is relatively small, the entire disaster area 400 could be covered by the network 410, while in cases where the disaster area 400 geography is relatively large (or if parts are inaccessible to the MBUs), only a portion of the disaster area 400 may be coverable by the network 410 at a given time.
To provide regular, reliable communications services, in some implementations the data analysis includes considering maintaining the network 410 when determining alternative MBU locations. For instance, data such as the number of MBUs 100 available for deployment, population of the disaster area 400, network 410 constraints, etc. could be analyzed. Using more MBUs than necessary wastes resources, while too few MBUs spaced too far apart could result in network gaps, resulting in a potential loss of the network 410 and the associated customer service.
In some examples, the MBU deployment is determined based on balancing the size of the network 410 coverage in view of the size of the disaster area 400 and further in view of the location of the affected customer groups. In this manner, the network coverage may be minimized to increase network reliability and reduce the MBUa required to establish the mesh network, while covering the portion of the disaster area 400 where the majority of customers are located. Thus, the illustrated network area 410 could cover 50% of the disaster area 400, but 90% of the affected customers.
Thus, it could be possible that some customers do not have access to the network 410 at all times. For instance, if a customer 420D does not have wireless access, they can still use a user device 124 to generate a request for banking services and queue up the request and other emails, texts, and other messages in their device 124. As the MBU 100C moves along a route 422 and comes into proximity with the user device 124 of the customer 420D, wireless connection is reestablished (even briefly). At this time, the queued requests, messages, etc. can be communicated to the MBU 100C, and transmitted to the internet 120 via the network 410. Moreover, if the MBU 100C determines that the data received from the customer 420D includes a request for banking services, the autonomous vehicle 102 of the MBU 100C may be controlled to stop the MBU 100C to allow the customer 420D to conduct the requested transaction(s) using the ATM 130 of the MBU 420C and/or the wireless connectivity of the MBU 420C. Received data which are not banking requests can be forwarded across the network 410 to the internet 120 and on to their respective destinations.
As noted above, deployment locations and routes may be determined by data analysis, both before and after a disaster event. Further, the MBUs 100 are configured in some embodiments to communicate with each other and plan their movements. Thus, as discussed previously, MBUs 100A, 100B, 100C may be deployed and redeployed as needed to serve the customers 420A, 420B, 420C, and 420D. However, to maintain the reliability of the network 410 (no breaks or gaps), the MBU movement is coordinated. Accordingly, the MBUs 100A, 100B, 100C move synchronously such that the boundary of the network 410 could change shape, but remain intact within the disaster zone area 400. This synchronization may require a certain route to be taken by a given MBU, or one MBU may be required to stop or change speed in route to allow other MBUs to relocate before continuing to a destination.
As shown in
In this manner, it may be possible for fewer MBUs 100 to service a larger disaster area 100 and more customers 420 by predicting or determining when and where financial transactions are likely to occur, and then moving in a synchronized fashion to serve a distributed population of customers 420. It also allows customers to reliably use the network 410 (and internet 120 connected thereto) as the MBUs 100 are in motion.
In further examples, as MBUs 100 move and relocate, they can broadcast an electronic message to the user devices 124 to inform the associated customers that an MBU is in their vicinity. Such a broadcast could be made by any suitable means, such as email, text, etc. The message can inform customers 420 when and where the MBU 100 will be located and invite the customers to conduct desired financial transactions, or use the associated wireless communications for other purposes. Still further, such messages could provide further information related to the disaster event. For example, the MBUs could broadcast a community message regarding found or missing persons, weather forecast information, relief information, etc. Since these messages are broadcast via moving MBUs, the number of message recipients may be maximized.
As noted above, the functions of the MBUs 100 are not necessarily limited to financial transactions. The MBUs 100 may be configured to provide additional relief services, providing meeting areas and safe zones where supplies could be distributed, user devices 124 could be charged, etc. For example, the MBUs may be configured so as to insure victims of the event periodically get some amount of an inventory of supplies, such as those provided by relief organizations. Additionally, any necessary mobile device applications could be distributed, and victims without access to user devices 124 could access financial and other services directly via the MBUs. Broadcasting messages to the user devices 124 informs customers 420 and others affected by the disaster event regarding available supplies, local merchants, etc.
The mass storage device 514 is connected to the CPU 502 through a mass storage controller (not shown) connected to the system bus 522. The mass storage device 514 and its associated computer-readable data storage media provide non-volatile, non-transitory storage for the server computer 210. Although the description of computer-readable data storage media contained herein refers to a mass storage device, such as a hard disk or solid state disk, it should be appreciated by those skilled in the art that computer-readable data storage media can be any available non-transitory, physical device or article of manufacture from which the central display station can read data and/or instructions.
Computer-readable data storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable software instructions, data structures, program modules or other data. Example types of computer-readable data storage media include, but are not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROMs, digital versatile discs (“DVDs”), other optical storage media, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the server computer 210.
According to various embodiments of the invention, the server computer 210 may operate in a networked environment using logical connections to remote network devices through the network 520, such as a wireless network, the Internet, or another type of network. The server computer 210 may connect to the network 520 through a network interface unit 504 connected to the system bus 522. It should be appreciated that the network interface unit 504 may also be utilized to connect to other types of networks and remote computing systems. The server computer 210 also includes an input/output controller 506 for receiving and processing input from a number of other devices, including a touch user interface display screen, or another type of input device. Similarly, the input/output controller 506 may provide output to a touch user interface display screen or other type of output device.
As mentioned briefly above, the mass storage device 514 and the RAM 510 of the server computer 210 can store software instructions and data. The software instructions include an operating system 518 suitable for controlling the operation of the server computer 210. The mass storage device 514 and/or the RAM 510 also store software instructions, that when executed by the CPU 502, cause the server computer 210 to provide the functionality of the server computer 210 discussed in this document. For example, the mass storage device 514 and/or the RAM 510 can store software instructions that, when executed by the CPU 502, cause the server computer 210 to implement the various processes described herein, among other things.
Although various embodiments are described herein, those of ordinary skill in the art will understand that many modifications may be made thereto within the scope of the present disclosure. For instance, examples related to home loans are included herein, though the disclosed systems and methods are also applicable to many other financial processes, such as personal and business loans, credit card accounts, home equity lines of credit, mortgage refinances, etc. Accordingly, it is not intended that the scope of the disclosure in any way be limited by the examples provided.
