Systems and methods for notification and deployment of an installation at a plurality of device locations

A deployment system can include a computing device that is configured to receive a broadcast message from a deployment device in response to the deployment device receiving an approval notification and obtain a plurality of deployment parameters via a distributed communications system. The computing device can also be configured to identify an installation time included in the plurality of deployment parameters and download application data associated with an application identifier included in the plurality of deployment parameters to a local database. The computing device can also be configured to initiate an installation of the application data from the local database at the installation time and transmit a status update to the deployment device in response to the installation being initiated.

TECHNICAL FIELD

The disclosure relates generally to systems and methods for notifying and deploying an installation at various device locations and more specifically downloading installation data at a local database for future local installation.

BACKGROUND

In a system with multiple locations across various time zones, including multiple devices at each location, deploying an installation or update to the multiple locations presents a variety of challenges. For example, scheduling the installation or update to avoid overwhelming the system and devices at particular locations is important as well as difficult due to the varying timing needs of the multiple locations. Further, ensuring successful installations also presents challenges due to local network-constrained environments or offline scenarios, preventing the installation from occurring.

SUMMARY

The embodiments described herein are directed to a deployment system and related methods. The deployment system can include a computing device that is configured to receive a broadcast message from a deployment device in response to the deployment device receiving an approval notification and obtain a plurality of deployment parameters via a distributed communications system. The computing device can also be configured to identify an installation time included in the plurality of deployment parameters and download application data associated with an application identifier included in the plurality of deployment parameters to a local database. The computing device can also be configured to initiate an installation of the application data from the local database at the installation time and transmit a status update to the deployment device in response to the installation being initiated.

In another aspect, the computing device is configured to, determine a present time, download the application data to the local database in response to a difference between the installation time and the present time being greater than a threshold period and store the downloaded application data and the plurality of deployment parameters in a queue.

In another aspect, the computing device is configured to, in response to the installation time of at least one set of deployment parameters being the present time, dequeue the downloaded application data and initiate installation of the downloaded application data from the local database.

In another aspect, the computing device is configured to, when the difference is less than the threshold period, delay downloading the application data associated with the application identifier included in the plurality of deployment parameters to the local database until the installation time.

In another aspect, the approval notification indicates (i) a plurality of computing devices to transmit the broadcast message, (ii) the application identifier, and (iii) a corresponding installation time for each of the plurality of computing devices.

In another aspect, initiating installation of application data from the local database includes installing the application data on at least one local device.

In another aspect, the at least one local device is indicated in the plurality of deployment parameters.

In another aspect, the computing device is configured to, in response to receiving a notification indicating successful installation from the at least one local device, transmit a status update to the deployment device indicating successful installation on the at least one local device.

In another aspect, the computing device is configured to, in response to a threshold number of unsuccessful installation attempts on the at least one local device being received, generate and transmit an alert to the deployment device indicating unsuccessful installation.

In various embodiments of the present disclosure, a method of deployment is provided. In some embodiments, the method can include receiving a broadcast message from a deployment device in response to the deployment device receiving an approval notification and obtaining a plurality of deployment parameters via a distributed communications system. The method can also include identifying an installation time included in the plurality of deployment parameters and downloading application data associated with an application identifier included in the plurality of deployment parameters to a local database. The method can also include initiating an installation of the application data from the local database at the installation time and transmitting a status update to the deployment device in response to the installation being initiated.

In various embodiments of the present disclosure, a non-transitory computer readable medium is provided. The non-transitory computer readable medium can have instructions stored thereon, wherein the instructions, when executed by at least one processor, cause a device to perform operations that include receiving a broadcast message from a deployment device in response to the deployment device receiving an approval notification and obtaining a plurality of deployment parameters via a distributed communications system. The operations can also include identifying an installation time included in the plurality of deployment parameters and downloading application data associated with an application identifier included in the plurality of deployment parameters to a local database. The operations can also include initiating an installation of the application data from the local database at the installation time and transmitting a status update to the deployment device in response to the installation being initiated.

DETAILED DESCRIPTION

The description of the preferred embodiments is intended to be read in connection with the accompanying drawings, which are to be considered part of the entire written description of these disclosures. While the present disclosure is susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and will be described in detail herein. The objectives and advantages of the claimed subject matter will become more apparent from the following detailed description of these exemplary embodiments in connection with the accompanying drawings.

It should be understood, however, that the present disclosure is not intended to be limited to the particular forms disclosed. Rather, the present disclosure covers all modifications, equivalents, and alternatives that fall within the spirit and scope of these exemplary embodiments. The terms “couple,” “coupled,” “operatively coupled,” “connected,” “operatively connected,” and the like should be broadly understood to refer to connecting devices or components together either mechanically, electrically, wired, wirelessly, or otherwise, such that the connection allows the pertinent devices or components to operate (e.g., communicate) with each other as intended by virtue of that relationship.

A deployment system may be implemented to transmit a message to a plurality of clusters, for example, individual store devices at individual locations that are associated with an entity. In various implementations, the entity may be a retail corporation and the individual locations include stores associated with the retail corporation. Each individual location includes a plurality of devices, such as point of sale devices, general computers, handheld devices, etc. used during normal operation of the store. The message transmitted to the plurality of store devices includes unique deployment parameters for each store, indicating an application for installation, an installation time, etc. The deployment system manages the scheduling and execution of installations for the plurality of devices within the individual locations by sending the message. The installations may be installing new applications, updating versions of existing applications, etc.

In each deployment, each store that is indicated in the deployment may download the application on a local database or server and actually initiate installation of the application at the scheduled installation time, separate from installations occurring at other stores of the same application in the same deployment. While, based on local installation speeds, installation may take minutes or days, the installation at each individual store is only impacted by that store's day to day operations and local network constraints and avoids being impacted by across network outages or other constraints related to connecting to the deployment device or application database connectivity by storing and implementing the installation locally. In various implementations, the installation times at the plurality of stores may be the same (e.g., upon receipt), and, in this scenario, the application may be simultaneously downloaded and installed locally at the plurality of stores.

The deployment device directly interacts with a messaging module at the local store devices to broadcast deployment information to the plurality of stores or clusters. Each of the stores is managed by the entity operating the deployment device and directing installations, including new software or applications as well as updates to existing software and applications. The deployment system includes a plurality of messaging modules and a plurality of implementation modules, which one of each may be located at each store, to receive broadcast messages from the deployment device via a distributed communications system. The broadcast message may include deployment parameters, such as application identification by name, version, etc.; an installation time for each store; identification of local devices to install application; etc. In various implementations, the broadcast message may include which stores to broadcast the message to and a deployment identifier. Then, based on the deployment identifier, each local store can obtain deployment features from a deployment features database via the distributed communications system.

The deployment device also includes a status database that receives status information from each implementation device located at the plurality of stores, indicating the start and completion of each installation, as well as any installation failures that should be separately addressed. Once the indicated messaging modules are notified of the installation, the implementation modules of the individual stores can download the applications for installation, to store locally and install at the indicated day and time. Therefore, independent of whether the local system is online at the scheduled time of installation of the application or is in network-constrained environments, the local system can continue with the installation as the application and any corresponding data were stored locally in response to receiving the installation message.

Not only does the deployment system obviate potential offline issues, but the deployment system also anticipates and avoids overwhelming the local systems by scheduling the installation based on the local system, reducing impact on the local system. For example, the messaging module may receive in the broadcast message or obtain from the deployment features database a day and time for the installation to occur for each local system or cluster, such as 6:00 am UTC for a local system in New York and 12:00 pm UTC for a local system in Hawaii, to prevent interference with regular operations. The installation time is stored along with the downloaded application to initiate installation locally at the installation time, regardless of whether the local system at the store can connect to the deployment device or other remote databases. In various implementations, the deployment device may also transmit a cancel notice to one of more store devices implementing the installation. While the local store system may have downloaded the particular application for installation, if a cancel notice is attached to the installation time, once the installation is initiated, the cancel notice will prompt the implementation module to exit the installation.

Referring toFIG.1, a block diagram of a deployment system100is shown. The deployment system100may include a deployment device102and an approval device104, such as a phone, tablet, laptop, mobile computing device, desktop, etc., that interacts with the deployment device102via a distributed communications system108. In various implementations, the deployment device102and the approval device104may be a single device. The approval device104transmits an approval notification to the deployment device102upon a designated operator approving a deployment or release of an installation. In various implementations, the approval device104displays deployment parameters associated with the deployment for the operator to approve. For example, another individual generates the deployment parameters, indicating which stores will receive the installation message, an application or application version indicator that will be installed, a day and time for each installation at each store, etc. The deployment parameters are then sent to the approval device104for the operator to approve. In various implementations, the deployment parameters may be generated using the approval device104or another computing device. However, the operator approving the deployment parameters or features is different from the individual generating the deployment parameters.

Upon approval, the approval device104transmits the approval to the deployment device102. The deployment device102includes an approval receipt module112that receives the transmitted approval. The approval receipt module112confirms receipt of approval by a verified and approved operator. For example, the operator may log in to the approval device104(or another device and log in to a particular webpage or website operated by the entity) and the approval receipt module112verifies the log in credentials. The approval receipt module112forwards the verification and approval message to a broadcast generation module116. The broadcast generation module116parses the approval message, identifying the application for installation, the stores to which the application will be installed, etc. The broadcast generation module116also generates a broadcast message to be transmitted to the stores indicated in the approval message. For example, the broadcast message may be transmitted to a first store device120-1, a second store device120-2, . . . , and an Nth store device120-N, collectively, the store devices120. Each of the store devices120may be a computing device, such as a mobile computing device, a laptop, desktop, etc. Each store that the broadcast message is transmitted to by the broadcast generation module116of the deployment device102may download the application for installation (as indicated in the broadcast message) from an application database124. In various implementations, the broadcast generation module116may be implemented using Apache Kafka®. Alternatively, the approval device104may directly broadcast the approval message to the specific store devices120that are indicated in the deployment parameters as having the indicated application installed.

Further, in various implementations, the broadcast message may include minimal information, such as that an approval message was received for the store to which the broadcast message is being sent and a deployment identifier. When the broadcast message simply includes a deployment identifier, the approval receipt module112or the broadcast generation module116may transmit and store the corresponding deployment features for each of the store devices120in a deployment features database128for the corresponding store, such as the first store device120-1, to obtain upon receiving the broadcast message. The deployment features for each of the store devices120may include installation times along with additional installation parameters (e.g., limiting which in-store devices to receive which application installations, etc.). Additionally, the deployment device102includes a status database132to receive installation status updates from each of the store devices120during installation to maintain a log of successful or unsuccessful installations.

The deployment device102, the approval device104, and the store devices120can each be any suitable computing device that includes any hardware or hardware and software combination for processing and handling information. For example, the term “device” and/or “module” can include one or more processors, one or more field-programmable gate arrays (FPGAs), one or more application-specific integrated circuits (ASICs), one or more state machines, digital circuitry, or any other suitable circuitry. In addition, each can transmit data to, and receive data from, the distributed communications system108. In various implementations, the devices, modules, and databases may communicate directly on an internal network.

As indicated above, the deployment device102, the approval device104, and/or the store devices120can be a computer, a workstation, a laptop, a server such as a cloud-based server, or any other suitable device. In some examples, the deployment device102, the approval device104, and/or the store devices120can be a cellular phone, a smart phone, a tablet, a personal assistant device, a voice assistant device, a digital assistant, a laptop, a computer, or any other suitable device. In various implementations, the deployment device102is on a central computing system that is operated and/or controlled by a retailer. Additionally or alternatively, the modules and databases of the deployment device102are distributed among one or more workstations or servers that are coupled together over the distributed communications system108.

The databases described can be remote storage devices, such as a cloud-based server, a memory device on another application server, a networked computer, or any other suitable remote storage. Further, in some examples, the databases can be a local storage device, such as a hard drive, a non-volatile memory, or a USB stick.

The distributed communications system108can be a WiFi network, a cellular network such as a 3GPP® network, a Bluetooth® network, a satellite network, a wireless local area network (LAN), a network utilizing radio-frequency (RF) communication protocols, a Near Field Communication (NFC) network, a wireless Metropolitan Area Network (MAN) connecting multiple wireless LANs, a wide area network (WAN), or any other suitable network. The distributed communications system108can provide access to, for example, the Internet.

FIG.2illustrates an example computing device200. The deployment device102, the approval device104, and/or the store devices120may include the features shown inFIG.2. For the sake of brevity,FIG.2is described relative to the deployment device102.

As shown, the deployment device102can be a computing device200that may include one or more processors202, working memory204, one or more input/output devices206, instruction memory208, a transceiver212, one or more communication ports214, and a display216, all operatively coupled to one or more data buses210. Data buses210allow for communication among the various devices. Data buses210can include wired, or wireless, communication channels.

Processors202can be configured to perform a certain function or operation by executing code, stored on instruction memory208, embodying the function or operation. For example, processors202can be configured to perform one or more of any function, method, or operation disclosed herein.

Instruction memory208can store instructions that can be accessed (e.g., read) and executed by processors202. For example, instruction memory208can be a non-transitory, computer-readable storage medium such as a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), flash memory, a removable disk, CD-ROM, any non-volatile memory, or any other suitable memory.

Processors202can store data to, and read data from, working memory204. For example, processors202can store a working set of instructions to working memory204, such as instructions loaded from instruction memory208. Processors202can also use working memory204to store dynamic data created during the operation of the deployment device102. Working memory204can be a random access memory (RAM) such as a static random access memory (SRAM) or dynamic random access memory (DRAM), or any other suitable memory.

Input-output devices206can include any suitable device that allows for data input or output. For example, input-output devices206can include one or more of a keyboard, a touchpad, a mouse, a stylus, a touchscreen, a physical button, a speaker, a microphone, or any other suitable input or output device.

Communication port(s)214can include, for example, a serial port such as a universal asynchronous receiver/transmitter (UART) connection, a Universal Serial Bus (USB) connection, or any other suitable communication port or connection. In some examples, communication port(s)214allows for the programming of executable instructions in instruction memory208. In some examples, communication port(s)214allow for the transfer (e.g., uploading or downloading) of data, such as data items including feedback information.

Display216can display a user interface218. User interfaces218can enable user interaction with the deployment device102. For example, user interface218can be a user interface that allows an operator to interact, communicate, control and/or modify different features or parameters of the deployment device102. The user interface218can, for example, display the deployment features for an operator or user to view prior to issuing an approval. In some examples, a user can interact with user interface218by engaging input-output devices206, such as issuing the approval on the approval device104. In some examples, display216can be a touchscreen, where user interface218is displayed on the touchscreen.

Transceiver212allows for communication with a network, such as the distributed communications system108ofFIG.1. For example, if the distributed communications system108ofFIG.1is a cellular network, transceiver212is configured to allow communications with the cellular network. In some examples, transceiver212is selected based on the type of distributed communications system108in which the deployment device102will be operating. Processor(s)202is operable to receive data from, or send data to, a network, such as the distributed communications system108ofFIG.1, via transceiver212.

Referring toFIG.3, a block diagram illustrating an example of a messaging module304of the deployment system100ofFIG.1is shown. The messaging module304may be located on each of the store devices120. In various implementations, the messaging module304is an additional device located and associated with each of the store devices120. The messaging module304receives the broadcast message when the corresponding store device, for example, the first store device120-1, is indicated in the approval message as being included in the deployment of one or more applications.

A data obtaining module308of the messaging module304receives the broadcast message. In response to receiving the broadcast message, the data obtaining module308obtains deployment features of parameters from the deployment features database128. For example, the deployment features include the installation time corresponding to the specific store, the application to be installed, devices at the specific store on which to install the application, etc. In various implementations, if there are multiple applications to install at one or more stores, there are multiple deployments and multiple approval messages for each application or application version. For example, if a certain set of devices at a set of stores are to have application1installed, a single deployment will be completed for that installation. Then, if another set of devices, even if at the same set of stores, is to have application2installed, a separate or second deployment will be completed, including a separate approval message, for that installation.

In various implementations, the deployment system100may have multiple deployments for the same application to a different set of stores, to ensure there are no issues with installation of the application. For example, a first deployment may indicate five stores, a second deployment may indicate10stores, etc. Then, if a deployment results in multiple unsuccessful installations, a subsequent deployment may be delayed or canceled for troubleshooting or updating of the application. The data obtaining module308forwards the obtained deployment features to a transmit instructions module312. The transmit instructions module312transmits the deployment features corresponding to the particular store to an implementation module316at the corresponding store (e.g., the first store device120-1). In various implementations, the deployment device102may directly transmit the deployment features to the indicated store devices120.

Referring now toFIG.4, a block diagram illustrating the implementation module316of the deployment system100ofFIG.1is shown. The implementation module316includes a fetch determination module404that receives the deployment features from the messaging module304. The fetch determination module404determines whether the application indicated in the deployment features should be obtained or “pre-fetched” based on the installation time included in the deployment features. In various implementations, the implementation module316may only obtain and download the application indicated in the deployment features if the installation time is over a threshold time away from a present time. For example, if the installation time is less than 30 minutes from the present time, the implementation module316may instead download the application at the installation time and proceed with installation. The pre-fetch implementation operates to obviate any potential offline scenarios where a store that is set to have an application installed is prevented from installing the application because the store cannot access the application database124via a distributed communications system108. Additionally or alternatively, the pre-fetch feature may also obviate any network constraints at the time of installation, such as slowed speeds due to connectivity of the store's network, the distributed communications system108, or other connectivity limitations.

If the installation time is greater than the threshold time away from the present time, the fetch determination module404forwards a fetch indication for the corresponding application to an application obtaining module408. The application obtaining module408retrieves the corresponding application indicated in the deployment features (e.g., by an application identifier) from the application database124, which, in various implementations, may be indexed by application identifier. While the application database124and the status database132are shown as directly interacting with the implementation module316of the store devices120, as shown inFIG.1, the application database124and the status database132may be communicating with the store devices120/the implementation module316via the distributed communications system108. However, if the installation time is less than the threshold time away from the present time, the fetch determination module404may instead add the deployment features corresponding to the particular deployment to a queue database412. The queue database412stores each set of deployment features according to the installation time. If no installation time is indicated, the fetch determination module404may add the set of deployment features to the queue database412with a present time.

A dequeue module416removes the set of deployment features based on a present time as determined by a clock indicator. The dequeue module416removes the set of deployment features with an installation time matching the present time. If multiple sets of deployment features have a same installation time, the dequeue module416removes the set of deployment features that was added to the queue database412first. The dequeue module416pulls the set of deployment features from the queue database412and forwards the set of deployment features to an installation execution module420. In various implementations, the installation execution module420may be operated by Helm®. The installation execution module420initiates installation of the application (indicated in the deployment features) on indicated in-store devices424. In various implementations, each of the store devices120may include a central computing device, individual devices (such as point-of-sale device, in-store computers, etc.), handheld devices, etc. via a distributed communications system (such as the distributed communications system108).

The installation execution module420may receive from the dequeue module416the deployment features as well as the pre-fetched and downloaded application. However, if the deployment features do not include a corresponding downloaded application, the installation execution module420may obtain the corresponding application from the application database124, for example, as described above, if the installation time was less than a threshold time from the time at which the deployment features were received from the messaging module304. The installation execution module420also forwards the initiating of the installation to a status update module428. The status update module428updates the status database132with each step of the installation process received from the installation execution module420and the in-store device(s)424as the installation is occurring and whether the installation is successful or unsuccessful. That is, at the successful installation or unsuccessful installation, the in-store device(s)424transmit a status of the installation. In various implementations, the in-store device(s)424send a present status at default intervals (e.g., installation begun, installation pending, installation successful, installation unsuccessful, etc.).

For instance, if an installation is unsuccessful, the in-store device(s)424will update the status database132that the installation of the corresponding application on the reporting in-store device(s)424was not successfully installed. Optionally, an alert generation module432may receive certain status updates from the status update module428, such as cancellation, unsuccessful installation, etc. The alert generation module432may generate and transmit an alert to the approval device104(or another device), indicating that an approved installation was not successful. Then, an operator can intervene and adjust or cancel future deployment and/or perform manual intervention to install the application on the appropriate store device(s). In various implementations, the installation execution module420may attempt to install a particular application a threshold number of times before deeming the installation unsuccessful.

While not shown, in various implementations, the deployment device102may directly broadcast cancellation messages to the queue database412(or another module of the implementation module316) when an operator cancels an installation that was previously scheduled. The corresponding set of deployment features is modified to indicate the installation is canceled. Once the installation time occurs, the installation execution module420determines the set of deployment features includes a cancel request and exits the installation process.

Referring toFIGS.5A and5B, flowcharts of example methods of message deployment is shown. ForFIG.5A, control begins in response to receiving an approval from a designated account or individual corresponding to a release or deployment. That is, control begins once approval of the release or deployment is received. As described above, the approver may be one of a set of individuals who review the details of the deployment and approve the deployment. The actual features of the deployment may be generated and received from a different individual, to ensure at least two people are reviewing the deployment. The deployment features indicate which stores are receiving an installation, an application to be installed, installation times for each store receiving installation, etc. In this way, the individual generating the deployment features can set which times the installation will occur as to not overwhelm any store systems based on, for example, normal operating times, other installations, etc. In various implementations, a default installation time may be associated with each store, for example, during the middle of the night, local time, when the store is regularly not operating the particular in-store devices receiving the installation.

Control proceeds to504to generate a broadcast message including release or deployment parameters indicated in the approval message, such as a portion of or all of the deployment features described inFIGS.3and4. Control continues to508to transmit a notification to the address(es) associated with or indicated in the release parameters. Then, control ends. For example, control ofFIG.5Amay be implemented by the deployment device102ofFIG.1.

InFIG.5B, control begins in response to receiving the broadcast message at each store device120, by, for example, the message module. Control continues to512to obtain deployment features associated with the deployment indicated in the broadcast message from a database, such as the deployment features database128described above. Control proceeds to516to transmit the deployment features of the installation (indicated in the broadcast message) for implementation, such as to the implementation module316, described above.

Referring now toFIG.6, a flowchart of example methods of application installation at a local location is shown. Control begins in response to receiving deployment features. Control is being operated at a particular store that is included in the deployment features. Control proceeds to604to parse the deployment features. As mentioned previously, the deployment features may include application identifiers indicating the application for installation, the installation time for each of the stores, device identifiers that having the application installed, etc. Control continues to608to determine if the installation time is greater than a threshold period from the present time. For example, as noted previously, if the installation time is greater than the threshold period away from the present time, such as 30 minutes, control proceeds to612.

Then, at612, control downloads the application information indicated in the deployment features to a local database. That is, control downloads the application for local available to install at the installation time. This delay in installation allows for the application to be installed at a time that is not interrupting the local network of the store and also avoids any future connectivity outages the local store may encounter, ensuring the downloaded, now local, application can be installed at the set installation time. Control continues to616to add deployment features to a queue. Additionally, if the installation time is not greater than the threshold period, control continues to616to add the deployment features to the queue. Then, control proceeds to620to determine if the installation time of a queued set of deployment features is equal to a present time. If yes, control proceeds to624. Otherwise, control waits for the present time to correspond to an installation time. As noted previously, if the installation time is excluded from the deployment features, control may set the installation time to the present time upon adding the deployment features to the queue.

At624, control dequeues the corresponding deployment features. Then, at628, control determines if the application has been stored locally. That is, control searches for the application indicated in the deployment features in a local database, which would be true for applications that had an installation time greater than the threshold period from the time when the deployment features were received. If the application is not stored locally, control continues to632to download the application information. If the application is stored locally or one the application information is downloaded in632, control continues to636to initiate installation of the application indicated in the deployment features.

Control continues to640to update the deployment status log that installation has begun. Then, control proceeds to644to determine if the installation was successful. If yes, control updates the deployment status log that installation was successful at648and control ends. Otherwise, if at644installation was not successful, control proceeds to652to determine if a threshold number of installation attempts is exceeded. For example, if the installation was attempted and unsuccessful over three times, control then continues to656to update the deployment status log that the attempt threshold has been exceeded, and generates and transmits an error to a device operated by the deployment system (e.g., the approval device). Then, control ends. Otherwise, if the attempt threshold is not exceeded at652, control continues to660to update the deployment status log of the unsuccessful attempt and returns to636.