HK1261273A1 - Systems and methods for parallel and scalable processing of telemetry data from connected dispensing machines - Google Patents

Description

System and method for parallel and scalable processing of telemetry data from networked distribution machines

Technical Field

The described embodiments relate generally to networked machines, including networked dispensers.

Background

Beverage dispensers are used to dispense beverages to consumers in various locations, such as restaurants, cafeterias, theaters, and other entertainment and/or food service establishments. Conventional beverage dispensers provide a limited number of beverage types that can be dispensed (e.g., between six and ten) and do not provide advanced functionality. Newer beverage dispensers can provide a large number of beverage types and combinations, largely because these dispensers are no longer mechanically limited to providing one or two beverage types per dispense header. For example, newer beverage dispensers may use a single dispense header to provide up to 1000 different beverage types and combinations.

Combination refers to a mixture of the types of beverages provided that can be automatically mixed and dispensed from a single dispense header, which represents one advanced function provided by newer beverage dispensers. The dispensed combination may be, for example, a personal combination of the types of beverages offered selected by the consumer at the beverage dispenser, or a consumer selecting one of a plurality of predetermined combinations from which to purchase options at the beverage dispenser.

As the number of beverage selections provided and other innovative functions become more complex, the site owner and/or operator may need to connect the premium beverage dispenser to an administrator system over a computer network to allow the premium beverage dispenser to provide telemetry to the administrator system. The telemetry data may include, for example, consumption-related data (e.g., the number of each beverage type and combination consumed at the premium beverage dispenser) and status (e.g., the amount of current ingredients and/or stock at the premium beverage dispenser) collected at the premium beverage dispenser. The administrator system may use the telemetry data to improve, for example, operation, maintenance, and/or overall logistics associated with running the advanced beverage dispenser.

Furthermore, for the same reason, there is also a need to connect other types of dispensing machines (such as machines that dispense canned/bottled beverages, snacks and/or other commodities) to an administrator system over a computer network. These dispensers are commonly referred to as vending machines.

Drawings

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate the present disclosure and, together with the description, further serve to explain the principles of the disclosure and to enable a person skilled in the pertinent art to make and use the disclosure.

Fig. 1 is a front perspective view of a beverage dispenser according to an embodiment of the present disclosure.

Fig. 2 is a block diagram of a beverage dispenser according to an embodiment of the present disclosure.

Fig. 3 is a system for providing telemetry data over a computer network according to an embodiment of the present disclosure.

Fig. 4 is a system for securely providing telemetry data over a computer network according to an embodiment of the present disclosure.

FIG. 5 is a flow diagram of a method for collecting and securely transmitting web service request messages containing telemetry data to an administrator controller over a computer network according to an embodiment of the disclosure.

Fig. 6 is a flow diagram of a method for generating and transmitting heartbeat messages to an administrator controller over a computer network according to an embodiment of the present disclosure.

Fig. 7 is a flow diagram of a method for securely receiving and processing a web service message containing telemetry data from a dispenser controller according to an embodiment of the disclosure.

FIG. 8 illustrates an administrator controller for parallel and scalable processing of messages containing telemetry data according to an embodiment of the disclosure.

Figure 9 shows a flowchart of a method for receiving and processing web service messages from a distribution machine according to an embodiment of the present disclosure.

FIG. 10 is a block diagram of an exemplary computer system that may be used to implement aspects of the present disclosure.

The present disclosure will be described with reference to the accompanying drawings. The drawing in which an element first appears is generally indicated by the leftmost digit(s) in the corresponding reference number.

Detailed Description

The present disclosure will now be described in detail in connection with embodiments thereof as illustrated in the accompanying drawings. References to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular function, structure, or characteristic, but every embodiment may not necessarily include the particular function, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the purview of one skilled in the art to effect such feature, structure, or characteristic in connection with other ones of the embodiments whether or not explicitly described herein.

1. Overview

To allow the dispenser to provide telemetry data to the administrator system over the computer network, the administrator system may expose web services to the dispenser. A Web service is a messaging framework that can exchange messages over a computer network between clients and servers using internet technology, such as hypertext transfer protocol (HTTP), extensible markup language (XML), and JavaScript object notation (JSON). Generally, two types of messages are exchanged: a request message and a response message. The client sends a request message to a server exposing the web service over a computer network. The request message encodes the parameters and the request to perform an operation (or run a subroutine) at the server using the parameters. After performing the operation using the parameters, the host may return a response message with the operation result to the client over the computer network.

Web services have a hierarchical architecture and typically include, from lowest to highest, at least a network layer, a transport layer, and a wrapper layer. The network layer specifies the most basic communication requirements of a web service, such as how data should be addressed, transmitted, and routed through a computer network. The transport layer is responsible for enabling inter-application communication above the network layer and includes, for example, technologies such as HTTP. The wrapping layer specifies the format data to be loaded before transmission by the transport layer over the network. Simple Object Access Protocol (SOAP) and presentation layer state transition (REST) are the two most common wrapper formats. SOAP defines XML-based envelopes for constructing the above-described request messages and response messages. The REST may use a variety of machine-readable formats as envelopes for constructing request and response messages, including XML and JSON.

The layers of the Web services architecture do not specifically address security issues such as message integrity, authentication, authorization, and confidentiality. Thus, exposing web services that provide the distribution machine with access to the administrator system over the computer network may undesirably provide other unauthorized users and devices of the computer network with access to the administrator system and web service messages.

The present disclosure relates to systems and methods for securely providing telemetry data of a distribution machine to an administrator system via an exposed web service over a computer network. To protect exposed web services, the systems and methods of the present disclosure provide a security gateway at the distribution machine and administrator system that may provide one or more of message integrity, authentication, authorization, and confidentiality. The security gateway is implemented separately from the application that creates the request and response messages at the dispenser and the administrator system, respectively. Because the security gateway is implemented separately from the application that creates the request and response messages, the application that creates the request and response messages can be created and modified without regard to message security, which can be handled transparently by the security gateway.

The present disclosure also relates to systems and methods for parallel and scalable processing of web service messages containing telemetry data at an administrator system. The administrator system may receive a large number of web service messages containing telemetry data from many distribution machines in a short period of time. To receive and process these web service messages, the systems and methods of the present disclosure provide a message queue to queue the web service messages (or at least telemetry data in the web service messages) into a plurality of queues and provide a different thread or process ("thread") for each queue of the plurality of queues. Each thread may pull web service messages from its assigned queue in the order in which they were stored in the assigned queue and process telemetry data for the web service messages. The threads may run on one or more Central Processing Unit (CPU) cores at an administrator system. This arrangement allows for horizontal scaling in web service message processing throughput. For example, to improve web service message processing throughput, the number of CPU cores may be increased and/or the number of queues (and, correspondingly, the number of threads assigned to queues) may be increased.

The system and method for parallel and scalable processing of web service messages containing telemetry data at the administrator system may also ensure that the web service messages are processed in the order they were generated at the respective distribution machines. This is useful, for example, to ensure that decisions related to maintenance and operation of the dispenser are not made based on old telemetry data.

To provide such ordered web service message processing functionality, the message queuer may place a web service message containing telemetry data into one of a plurality of queues based on the distribution machine from which the web service message was received. For example, the message queuer may use the distributor identifier included in the web service message to map the web service message to a particular one of the plurality of queues such that the web service messages from the distributor are placed in the same queue. Further, once the message queuer determines a particular one of the plurality of queues to place in the web service message, the message queuer may insert the web service message into a particular location of the queue based on the time the web service message was generated at the distribution machine. For example, the message queuer may use a web service message sequence number or timestamp contained in the web service message to insert the web service message at a particular location into the queue such that the web service messages in the queue are stored in the order in which the web service messages were generated.

Before further describing these and other functions of the present disclosure, the following sections provide an exemplary operating environment in which embodiments of the present disclosure may operate.

2. Exemplary operating Environment

Fig. 1 illustrates a dispenser 100 in which embodiments of the present disclosure may be implemented. The dispenser 100 may include a base 102 coupled to a body 108. The base 102 may be used to support the body 108 in an upright position. The base 102 may include a drip tray 104 having a dispensing position 106 located within the area occupied by the drip tray 104. A user (e.g., a consumer) may place his or her cup at the dispensing location 106 to receive his or her desired beverage.

The body 108 may include a user interface 110 for receiving commands from a user. The user interface 110 may include a display screen 112 configured to display information to a user and/or receive commands from a user. The display screen 112 may be a touch screen, such as a Liquid Crystal Display (LCD) touch screen or a Light Emitting Diode (LED) touch screen. The user may initiate the dispensing of the beverage, for example, by interacting with the user interface 110 to select his or her desired beverage to be dispensed by the dispenser 100.

Fig. 2 illustrates a block diagram 200 of components of a dispenser, such as dispenser 100 in fig. 1, according to an embodiment of the present disclosure. The block diagram 200 may include a distribution manifold 210, such as one of the vertical distribution manifolds described in U.S. patent application No.15/016,466 filed on 5.2.2016, which is incorporated herein by reference in its entirety.

The block diagram 200 may include one or more base fluid sources 230. The base liquid source 230 may be, but is not limited to, a tap water source (e.g., a tap water pipe) and a carbonated water source (e.g., a carbonated water reservoir or carbonator). The base fluid source 230 may be coupled to the distribution manifold 210 via a base fluid delivery tube 234. A valve/pump 235 in communication with base fluid delivery conduit 234 may be configured to control the flow of base fluid through base fluid delivery conduit 234 and into distribution manifold 210.

The block diagram 200 may include one or more component sources 240. Ingredient source 240 may include a plurality of ingredients 242(242-1 through 242-n). Ingredient 242 may include liquid ingredients such as, but not limited to, sweeteners (e.g., sugar or artificial sweeteners), syrups or flavors (e.g., cola syrups or flavors, brand soda syrups or flavors (e.g., Mountain in)Or Sierra) Orange flavor, lime flavor, cherry flavor, tea flavor, etc.), or other liquid additives (e.g., vitamins, acids (e.g., citric acid), salts, or colorants). The ingredients 242 may be packaged in a container, such as, but not limited to, a box or bag. Each ingredient 242 may be delivered to the dispenser 210 via an ingredient delivery tube 244. A valve/pump 245 in communication with the ingredient delivery tube 244 may be configured to control the flow of the ingredient through the ingredient tube 244 into the distribution manifold 210.

Dispenser controller 220 may be configured to control and receive commands from a user interface, such as user interface 110 in fig. 1. Dispenser controller 220 may be configured to control the operation of the dispenser represented by block diagram 200 based on, for example, commands received from a user interface. For example, the dispenser controller 220 may control the dispensing of beverage types or combinations, both of which may be a mixture of base liquid and one or more ingredients 242 from the dispensing manifold 210. The dispenser controller 220 may control the flow of base fluid from the base fluid source 230 by controlling the valve/pump 235. The dispenser controller 220 may also control the flow of the ingredient 242 from the ingredient source 240 by controlling the valve/pump 245. The dispenser controller 220 may control the pressure of the ingredient 242 in the branch pipe 244 by controlling the valve/pump 245.

In some embodiments, the dispenser controller 220 may include and/or may be configured to read the sensor 227. Sensor 227 may include a pressure sensor for monitoring the pressure of the base fluid within base fluid delivery tube 234 and/or for monitoring the pressure of the constituent within constituent delivery tube 244. The sensors 227 may also include flow sensors (e.g., flow meters) for measuring the flow of the base fluid and the constituent within the delivery tubes 234 and 244, respectively, and/or for measuring the degree of uniform flow within the distribution manifold 210. In some embodiments, the sensor 227 may include a level sensor for measuring the amount of each component 242 remaining within the component source 240.

The sensors 227 may also include, but are not limited to, sensors configured to monitor: (1) carbon dioxide tank level (e.g., one, two, or more carbon dioxide regulators); (2) a carbonation header pressure of a carbonator configured to carbonate water; (3) the ambient temperature of the room (e.g., a closed room) in which the base liquid and/or composition 242 is stored (thereby monitoring whether one or more of the base liquid and/or composition 242 is maintained at a predetermined temperature level or within a predetermined temperature range); (4) water filtration system parameters associated with the base fluid (e.g., water pressure, pressure differential across the filter); (5) the pH of the water or carbonated water associated with the base fluid; (6) the expiration date of the ingredient container containing one of the ingredients 242 (e.g., by reading a bar code associated with the ingredient container). The sensor 227 may be configured to transmit a signal to the dispenser controller 220 over a wired or wireless network. The dispenser controller 220 may be configured to control the operation of the dispenser represented by the block diagram 200 based on data (e.g., pressure and flow values) collected by the sensors 227.

In some embodiments, dispenser controller 220 may also include an embedded computer 224. In some embodiments, the embedded computer 224 may collect dispenser telemetry data, including: (1) the type and combined amount of beverage dispensed by the dispensing manifold 210, (2) the amount of ingredient 242 remaining within the ingredient source 240, (3) a user identification code collected from a user interface of the dispensing machine, and (4) other data from the aforementioned sensors 227 (e.g., flow data, ambient temperature of the room in which the base liquid and/or ingredient 242 is stored, carbon dioxide tank level, carbonation header pressure, water filtration system parameters, etc.). In some embodiments, embedded computer 224 may store dispenser telemetry data and send the dispenser telemetry data to a controller of an administrator system via a computer network (such as the internet). The management controller may be provided and/or managed by an operator of the dispenser represented by block 200, or may be provided and/or managed by some other entity associated with the operation of the dispenser represented by block 200.

In some embodiments, all or a portion of the stored telemetry data (e.g., information related to the type of beverage and the combined amount dispensed by the dispensing manifold 210) may be periodically sent to an administrator controller. In some embodiments, all or a portion of the stored telemetry data (e.g., other data from the sensor 227 described above) may be sent to the administrator controller based on an alert level or threshold level associated with the stored telemetry data. For example, stored telemetry data relating to the ambient temperature of the room in which the base fluid and/or composition 242 is stored may be sent to the supervisory controller when the ambient temperature of the room exceeds some predetermined threshold that is outside or nearly outside of the acceptable temperature range. In another example, stored telemetry data relating to carbon dioxide tank level may be sent to an administrator controller when the carbon dioxide tank level exceeds some predetermined threshold indicating that the carbon dioxide tank level is low or empty.

In some embodiments, the administrator controller may use telemetry data to assist in distributing ingredients to the dispensers represented by block 200 and/or to assist in maintaining the dispensers represented by block 200. In some embodiments, the administrator controller may use telemetry data to track user preferences and consumption data (e.g., type and quantity of beverages dispensed by the manifold 210), analyze it to predict consumption trends and/or support future business decisions involving the dispensers represented by block diagram 200. In other embodiments, the administrator controller may use the telemetry data to improve dispenser maintenance tasks, increase customer satisfaction, and/or predict parts failure within the dispenser and/or schedule preventative maintenance services for the dispenser.

3. Security gateway

To enable the dispenser to provide telemetry data to the controller of the administrator system over the computer network, the administrator controller may expose a web service to the dispenser. As described above, a web service is a messaging framework capable of exchanging messages over a computer network between clients and servers using Internet technology, such as HyperText transfer protocol (HTTP), extensible markup language (XML), and JavaScript object notation (JSON). Two types of messages are typically exchanged: a request message and a response message. The client sends a request message to a server exposing the web service over a computer network. The request message encodes the parameters and the request to perform an operation (or run a subroutine) at the server using the parameters. After performing the operation using the parameters, the host may return a response message with the operation result to the client over the computer network.

Fig. 3 illustrates a system 300 for providing telemetry data over a computer network using exposed web services according to an embodiment of the disclosure. The system 300 includes an administrator controller 302 and the dispenser controller 220 described above in connection with FIG. 2. Dispenser controller 220 is provided by way of example and not limitation. As will be appreciated by those of ordinary skill in the art, other dispenser controllers (e.g., dispenser controllers implemented in different dispensers) may be used in the system 300 without departing from the scope and spirit of the present disclosure.

In operation, web service provider (WS provider) 304 of administrator controller 302 exposes a web service that enables web service client (WS client) 306 of dispenser controller 220 to provide telemetry data to administrator controller 302 over computer network 308, such as the internet. Telemetry data may include data collected from the sensors 227 described above in connection with fig. 2, as well as other data collected from other sensors and/or peripherals of the dispenser implementing the dispenser controller 220.

WS client 306 may package the telemetry data in a web service request message 310 formatted according to Simple Object Access Protocol (SOAP), presentation layer state transition (REST), or some other packaging format. Web service request message 310 may contain an envelope 312 containing an optional header 314 and a body 316. Where used, the header 314 may include one or more information blocks that specify how the message is to be processed by one or more receiving entities. Principal 316 can include telemetry data as one or more parameters and a request to perform an operation (or run a subroutine) at WS provider 304 with the one or more parameters. The telemetry data and requests to perform operations may be expressed in an XML or JSON syntax within body 316. The request to perform the operation may also be expressed outside of the body 316 in any number of forms, including as a Uniform Resource Identifier (URI).

After WS client 306 packages the telemetry data and the request to perform the operation into web service request message 310, WS client 306 may transmit web service request message 310 over computer network 308. In one embodiment, WS client 306 transmits web service request message 310 over computer network 308 using Hypertext transfer protocol (HTTP) or Hypertext transfer secure protocol (HTTPS).

WS provider 304 receives web service request message 310 from WS client 306 over computer network 308 and unpacks web service request message 310 to recover one or more parameters including telemetry data and a request to perform an operation with the one or more parameters. WS provider 304 then performs the operation with one or more parameters including telemetry data and optionally packages the operation results into web service response message 318. The operations may include, for example, parsing the telemetry data and populating a database with various values of the telemetry data. The data in the database may then be used to assist in the dispensing of ingredients to the dispensing machine and/or to assist in the maintenance of the dispensing machine. In some embodiments, the data in the database may be used to track user preferences and consumption data (e.g., type and quantity of beverages dispensed by the dispenser), analyze it to predict consumption trends and/or support future business decisions involving the dispenser. In other embodiments, the data in the database may be used to improve dispenser maintenance tasks, increase customer satisfaction, and/or predict parts failure within the dispenser and/or schedule preventative maintenance services for the dispenser.

Similar to web service request message 310, WS provider 304 may format web service response message 318 according to SOAP, REST, or some other wrapped format. Web service response message 318 may contain an envelope 320 containing an optional header 322 and a body 324. Where used, the header 322 may include one or more information blocks that specify how the message is to be processed by one or more receiving entities. The body 324 may include the results of the operation. The operation results may be expressed in XML or JSON syntax within the body 324.

After WS provider 304 packages the results of the operation into web service response message 318, WS provider 304 may transmit web service response message 318 over computer network 308. In one embodiment, WS provider 304 transmits web service response message 318 over computer network 308 using HTTP or HTTPs.

It should be noted that multiple dispensers and dispenser controllers other than dispenser controller 220 may transmit web service request messages to administrator controller 302. These Web service request messages may be processed similarly to Web service request message 310 as described above, but may include different data (e.g., other than telemetry data) and/or requests to perform different operations or subroutines.

One problem with web services exposed by WS provider 304 and web services in general is that the hierarchical architecture of web services does not specifically address security issues such as message integrity, authentication, authorization, and confidentiality. Thus, exposing web services that provide dispenser controller 220 and other dispenser controllers with access to administrator controller 302 over computer network 308 may undesirably provide other unauthorized users and devices of computer network 308 with access to administrator controller 302, web service request message 310, and web service response message 318.

To protect exposed web services, security gateways may be provided at dispatcher controller 220 and administrator controller 302 that may provide one or more of message integrity, authentication, authorization, and confidentiality. The security gateway may be implemented separately from the application that created the request message and the response message at dispatcher controller 220 and administrator controller 302, respectively; i.e., separate from WS client 306 and WS provider 304. The security gateway is implemented separately from WS client 306 and WS provider 304 so these applications can be created and modified without regard to message security, which can be handled transparently by the security gateway.

Fig. 4 illustrates such a system 400 according to an embodiment of the present disclosure. Specifically, the system 400 has the same basic configuration and operates in the same basic manner as the system 300 in FIG. 3 described above. However, dispenser controller 220 and administrator controller 302 in system 400 of FIG. 4 each also include a security gateway. More specifically, dispatcher controller 220 also includes a dispatcher web services gateway (dispatcher WS gateway) 402 and administrator controller 302 also includes an administrator web services gateway (administrator WS gateway) 404.

In operation, distributor WS gateway 402 is configured to intercept web service request message 310 generated by distributor WS client 306 before web service request message 310 is transmitted to administrator controller 302 via computer network 308. In one embodiment, WS gateway 402 is implemented as an HTTP proxy server configured to intercept an HTTP request message containing web services request message 310 in the body of the HTTP request message.

Once distributor WS gateway 402 intercepts web service request message 310, distributor WS gateway 402 may encrypt all or at least a portion of the telemetry data (or other data) in body 316 of web service request message 310 to generate a digital signature. Distributor WS gateway 402 may insert a digital signature into header 314 of web service request message 316. Administrator controller 302 may authenticate the telemetry data (or at least a portion of the telemetry data and/or other signed data) using the digital signature; i.e., attesting to telemetry data from the dispenser controller 220.

In one embodiment, distributor WS gateway 402 may encrypt all or at least a portion of the telemetry data (or other data) in body 316 of web service request message 316 using a private key associated with distributor controller 220. The private key associated with the dispenser controller 220 is part of an asymmetric key pair comprising a private key and a public key. The public key may be public or private by administrator controller 302, while the private key is private and non-distributable by distributor controller 220. Administrator controller 302 may verify (e.g., by decrypting) the digital signature using a public key associated with dispenser controller 220. If the verification is successful, administrator controller 302 may determine that the private key associated with dispenser controller 220 is used to encrypt the telemetry data used to generate the digital signature, because data encrypted with the private key can only be decrypted with the public key.

In another embodiment, distributor WS gateway 402 may encrypt the message digest resulting from the one-way hash of the telemetry data using a private key associated with distributor controller 220 instead of encrypting the telemetry data directly. One-way hashing may be used to ensure the integrity of the telemetry data and/or to reduce the processing time required to generate the digital signature.

Once distributor WS gateway 402 intercepts web service request message 306, distributor WS gateway 402 may also encrypt all or at least a portion of the telemetry data (or other data) in body 316 of web service request message 310 to ensure confidentiality of the telemetry data as it traverses computer network 308. After encrypting the telemetry data, distributor WS gateway 402 may reinsert the encrypted telemetry data into body 316 of web service request message 316.

In one embodiment, distributor WS gateway 402 may encrypt all or at least a portion of the telemetry data (or other data) in body 316 of web service request message 316 using a public key associated with administrator controller 302. Like the public key associated with distributor controller 220, the public key associated with administrator controller 302 is part of an asymmetric key pair comprising a public key and a private key. The public key is public and freely distributable, while the private key is kept secret and non-distributable by administrator controller 302.

In another embodiment, distributor WS gateway 402 may encrypt all or at least a portion of the telemetry data (or other data) in body 316 of web service request message 316 using a symmetric key. Distributor WS gateway 402 may encrypt the symmetric key with the public key associated with administrator controller 302 and insert the symmetric key into header 314 or body 316 of web service request message 310.

After distributor WS gateway 402 has inserted a digital signature and/or encrypted telemetry data in principal 316, distributor WS gateway 402 may transmit web service request message 310 over computer network 308 using, for example, HTTP or HTTPs. Administrator WS gateway 404 is configured to receive web service request message 310 over computer network 308 and perform one or more of the following: decrypt the telemetry data, authenticate the telemetry data, and determine whether dispatcher controller 220 is authorized to perform the operation (or subroutine requested) requested in web service request message 310.

If telemetry data (or other data) in body 316 of web service request message 310 is encrypted using a public key associated with administrator controller 302, administrator WS gateway 404 may decrypt the encrypted telemetry data using a private key associated with administrator controller 302. If telemetry data (or other data) in body 316 of web service request message 310 is encrypted using a symmetric key as described above, administrator WS gateway 404 may obtain an encrypted copy of the symmetric key from header 314 or body 316 of web service request message 310, decrypt the symmetric key using a private key associated with administrator controller 302, and then decrypt the encrypted telemetry data using the decrypted symmetric key. Once decrypted, administrator WS gateway 404 may replace the encrypted telemetry data in web service request message 310 with the decrypted telemetry data.

If authentication is to be performed, administrator WS gateway 404 may extract the digital signature in header 314 of web service request message 310 and decrypt the digital signature using a public key associated with dispatcher controller 220. The telemetry data (or other data) signed to create the digital signature may then be compared to the telemetry data in the body 316 of the web service request message 310 to authenticate that the telemetry data is from the dispatcher controller 220. In the case where distributor WS gateway 402 creates a digital signature from a one-way hash of the telemetry data (or other data) in body 316 of web service request message 310, administrator WS gateway 404 may perform the same one-way hash on the telemetry data in body 316 before comparing the telemetry data in body 316 with the decrypted digital signature.

If authorization is to be performed, administrator WS gateway 404 may determine whether dispatcher controller 220 is authorized to use the web service subprogram requested in web service request message 310. In one embodiment, administrator WS gateway 404 may check a list of dispatcher controllers and/or dispatchers that are authorized to perform the operation requested in web services request message 310. If allocator controller 220, or the allocator implementing allocator controller 220, is on the list, then administrator WS gateway 404 may pass web service request message 310 to administrator WS provider 304 for processing. On the other hand, if allocator controller 220 or the allocator implementing allocator controller 220 is not on the list, then administrator WS gateway 404 may discard web service request message 310, thereby preventing administrator WS provider 304 from processing web service request message 310.

In another embodiment, if authorization is to be performed, administrator WS gateway 404 may determine whether a web service has been published based on a configurable list of published web services. If not, the web service call for the unpublished web service performed by the distribution machine may be rejected and discarded. This mechanism protects any unpublished Web services and may be used to stop Web services at any time for any reason.

After receiving web service request message 310 from administrator WS gateway 404 (replacing any encrypted telemetry data in body 316 with decrypted telemetry data), administrator controller 302 may process web service request message 310 as described above in connection with fig. 3. It should be noted that administrator WS gateway 404 and dispatcher WS gateway 402 may each perform the functions of another gateway as described above to protect web service response message 318 similar to web service request message 310.

In one embodiment, not all Web service request messages sent by distributor controller 220 need to be signed and/or encrypted by distributor WS gateway 402. Such messages that are not signed and/or encrypted by distributor WS gateway 402 may be said to be sent "out-of-band" while messages that are signed and/or encrypted may be said to be sent "in-band".

For example, a "heartbeat" message may be generated by dispatcher WS client 306 or dispatcher WS gateway 402 and sent out-of-band by dispatcher WS gateway 402 to administrator controller 302 over computer network 308. These heartbeat messages may be sent periodically or cyclically to signal to administrator controller 302 that dispatcher controller 220 (or the dispatcher implementing dispatcher controller 220) is present and available.

Referring now to fig. 5, a flow diagram 500 of a method for collecting telemetry data and securely transmitting a web service request message containing the telemetry data from a distribution machine to an administrator controller over a computer network is shown, according to an embodiment of the present disclosure. The method of flowchart 500 may be implemented by distributor WS client 306 and distributor WS gateway 402 as described above and shown in fig. 4. It should be noted, however, that the method may also be implemented by other distributor WS clients and distributor WS gateways. The steps of flowchart 500 performed by each of these applications are labeled in FIG. 5. It should also be noted that some of the steps of flowchart 500 need not occur in the order shown in fig. 5.

The method of flowchart 500 begins at step 502. At step 502, telemetry data is collected for the dispenser. The telemetry data may include, for example, consumption-related data (e.g., the quantity of each item consumed at the dispensing machine) and status (e.g., the current amount of ingredients, stock amount, and/or quantity of items at the dispensing machine) collected at the dispensing machine. The telemetry data may also include certain types of data as described above with reference to fig. 2.

After collecting telemetry data at step 502, the method of flow chart 500 proceeds to step 504. At step 504, a web service request message with telemetry data and a request to perform an operation (or run a subroutine) parameterized by the telemetry data is sent to an administrator controller, such as administrator controller 302 in FIG. 4. The Web service request message may be packaged according to SOAP, REST, or some other packaging format. The Web service request message may contain an envelope containing an optional header and body. Where used, the header may include one or more information blocks that specify how the message is to be processed by one or more receiving entities. The telemetry and request to perform operations may be expressed in XML or JSON syntax within the body. The request to perform the operation may also be expressed outside the body.

After step 504, the method of flowchart 500 proceeds to step 506. At step 506, the web service request message is intercepted before being sent over a computer network, such as the Internet, to the administrator controller. An HTTP proxy may be used to intercept web service request messages.

After step 506, the method of flowchart 500 proceeds to step 508. At step 508, the telemetry data in the intercepted web service request message is optionally signed by encrypting the telemetry data or encrypting a one-way hash of the telemetry data. The telemetry data or one-way hash of the telemetry data may be signed using a private key associated with the distributor. The resulting digital signature may be inserted into a header of the web service request message.

After step 508, the method of flowchart 500 proceeds to step 510. At step 510, telemetry data in the body of the web service request message is optionally encrypted. The telemetry data may be encrypted with a public key associated with the administrator controller or the symmetric key. If the telemetry data is encrypted using a symmetric key, the symmetric key may be encrypted using a public key associated with the administrator controller, and the symmetric key may be inserted into a header or body of the web service request message to enable the administrator controller to decrypt the encrypted telemetry data.

After step 510, the method of flowchart 500 proceeds to step 512. At step 512, the web service request message is transmitted to the administrator controller over the computer network. The web service request message may be transmitted over a computer network using HTTP or HTTPs.

Referring now to fig. 6, a flow diagram 600 of a method for generating and transmitting heartbeat messages from a dispatcher controller to an administrator controller over a computer network is shown, in accordance with an embodiment of the present disclosure. The method of flowchart 600 may be implemented by distributor WS client 306 or distributor WS gateway 402 as described above and shown in fig. 4. It should be noted, however, that the method may also be implemented by other distributor WS clients or distributor WS gateways.

The method of flowchart 600 begins at step 602. At step 602, a heartbeat message is generated. The heartbeat message may include an identifier, such as a hardware identifier, of the dispenser controller and/or the dispenser implementing the dispenser controller.

After step 602, the method of flowchart 600 proceeds to step 604. At step 604, the heartbeat message is sent "out-of-band" to the administrator controller over a computer network, such as the Internet. Messages sent "out-of-band" are unsigned and/or encrypted at the application layer prior to transmission. Heartbeat messages may be generated and sent periodically or cyclically to signal to the administrator controller that the dispenser controller (or the dispenser implementing the dispenser controller) is present and available.

Referring now to fig. 7, a flow diagram 700 of a method for securely receiving and processing a web service request message containing telemetry data from a dispatcher controller at an administrator controller is shown, according to an embodiment of the present disclosure. The method of flowchart 700 may be implemented by administrator WS gateway 404 and administrator WS provider 304 as described above and illustrated in fig. 4. However, it should be noted that the method may also be implemented by other administrator WS gateways and administrator WS providers. The steps of flowchart 700 performed by each of these applications are labeled in FIG. 7. It should also be noted that some of the steps of flowchart 700 do not have to occur in the order shown in fig. 7.

The method of flowchart 700 begins at step 702. At step 702, a web service request message is received from a distribution machine over a computer network, such as the Internet.

After step 702, the method of flowchart 700 proceeds to step 704. At step 704, the message is examined to determine if the message is a heartbeat message. If the message is a heartbeat message, the method of flowchart 700 proceeds to step 714 and processes the heartbeat message. If the message is not a heartbeat message, the method of flowchart 700 proceeds to step 706.

At step 706, the encrypted telemetry data in the body of the web service request message is decrypted. The telemetry data may be decrypted using a private key associated with the administrator controller or using a symmetric key contained in a header or body of the web service request message.

After step 706, the method of flowchart 700 proceeds to step 708. At step 708, the telemetry data is verified for authenticity. In particular, a public key associated with the dispatcher controller is used to extract and decrypt a digital signature in the header of the web service request message. The telemetry data signed to create the digital signature may then be compared to the telemetry data in the body of the web service request message to authenticate that the telemetry data is from the dispenser controller. In the case where a digital signature is created in the body of the web service request message from a one-way hash of the telemetry data, the same one-way hash may be performed on the telemetry data in the body before comparing the telemetry data in the body with the decrypted digital signature. If the telemetry data is determined not to be authentic based on the comparison (i.e., not matching), the method of flowchart 700 proceeds to step 710, where the web service request message is rejected. On the other hand, if the telemetry data is determined to be authentic (i.e., a match) based on the comparison, the method of flowchart 700 proceeds to step 712.

At step 712, it is determined whether the dispenser controller is authorized to use the web service to perform the operation (or subroutine) in the web service request message. In one embodiment, a list of dispatcher controllers and/or dispatchers authorized to use the web service subprogram requested in the web service request message is checked. If the dispenser controller, or the dispenser implementing the dispenser controller, is not on the list, the method of flowchart 700 proceeds to step 710 where the web service request message is rejected. On the other hand, if the dispenser controller, or the dispenser implementing the dispenser controller, is on the list, the method of flowchart 700 proceeds to step 714 where the web service request message is processed (e.g., as described above in connection with FIG. 3).

4. Parallel and scalable processing of telemetry data

Given that there may be thousands or even hundreds of thousands or more of dispensers and/or other types of machines connected to the administrator system as described above, and that these machines may all simultaneously send telemetry to the administrator system, the administrator system also needs to be able to receive and quickly process a large number of web service messages. Furthermore, there is a need for such an administrator system to provide throughput that can scale in an efficient manner when machines are connected to or disconnected from the administrator system.

Fig. 8 illustrates an administrator controller 800 for parallel and scalable processing of messages containing telemetry data according to an embodiment of the disclosure. The administrator controller 800 has the same basic configuration and operates in the same basic manner as the administrator controller 302 in FIG. 4 described above. However, administrator controller 800 also includes a message queue 802. It should be noted that administrator WS gateway 404 is an optional component in administrator controller 800.

In operation, web service messages containing telemetry data from the distribution machines are first received and processed by the administrator WS gateway 404 described above. After processing by administrator WS gateway 404, the web service messages are passed to message queuer 802.

The message queuer 802 includes a mapper 804 and a plurality of queues 806. Mapper 804 is configured to map or place each web service message into a respective one of queues 806. Queue 806 is a data structure for storing web service messages in memory.

To process web service messages stored in queue 806, administrator WS provider 304 includes a plurality of threads or processes ("threads") 808. A different one of threads 808 may be assigned to each queue 806. Each thread 808 may pull web service messages from its assigned queue 806 in the order in which they were stored in the assigned queue 806 and process telemetry data for the web service messages.

Processing of the telemetry data by thread 808 may include, for example, parsing the telemetry data and populating a database with various values of the telemetry data. The data in the database may then be used to assist in dispensing materials (e.g., ingredients) to the dispensing machine and/or to assist in maintaining the dispensing machine. In some embodiments, the data in the database may be used to track user preferences and consumption data (e.g., type and quantity of beverages dispensed by the dispenser), analyze it to predict consumption trends and/or support future business decisions involving the dispenser. In other embodiments, the data in the database may be used to improve dispenser maintenance tasks, increase customer satisfaction, and/or predict parts failure within the dispenser and/or schedule preventative maintenance services for the dispenser.

The thread 808 may run on a Central Processing Unit (CPU) core 810 or virtual core at an administrator controller 810. Kernel 810 may be implemented in or across one or more servers. Based on the number of cores 810, at least some of the threads 808 may run in parallel to increase throughput of processing web service messages. To further improve message processing throughput, the number of cores 810 may be increased and/or the number of queues 806 (and, correspondingly, the number of threads 808 assigned to queues 806) may be increased. Such an increase may be made in response to increasing the number of distribution machines transmitting web service messages to administrator controller 800.

The mapper 804 may also be configured to ensure that the web service messages are processed in the order in which they were generated at the respective distribution machines. This is useful, for example, to ensure that decisions related to maintenance and operation of the dispenser are not made based on old telemetry or non-chronologically ordered telemetry.

To provide such ordered message processing functionality, mapper 804 may place a web service message containing telemetry data into one of queues 806 based on the distribution machine from which the message was received. For example, the mapper 804 may use the dispenser identifier contained in the web service message to map the web service message to a particular one of the queues 806, such that messages from the dispensers are placed in the same queue and thus processed by the same thread 808.

The number of queues 806 and the number of threads 808 are typically much smaller than the number of dispensers sending web service messages to the administrator controller 800. In this case, mapper 804 may use a hash function to map the web service message to a particular one of queues 806. More specifically, mapper 804 may use a hash function to hash the distributor identifier contained in the Web service message and use the resulting hash value to assign the Web service message to a particular one of queues 806.

Once the mapper 804 determines a particular one of the queues 806 of web service messages to place in, the mapper 804 may insert the web service message into a particular location of the queue based on the time the message was generated at the distribution machine. For example, mapper 804 may use a message sequence number or timestamp contained in the web service message to insert a message at a particular location into the queue such that the web service messages in the queue are stored in the order in which the messages were generated.

Referring now to fig. 9, a flowchart 900 of a method for receiving and processing web service messages from a distribution machine is shown, according to an embodiment of the present disclosure. The method of flowchart 900 may be implemented by an administrator controller 800 as described above and shown in FIG. 8. However, it should be noted that the method may also be implemented by other administrator controllers. It should also be noted that some of the steps of flowchart 900 are optional and need not occur in the order shown in fig. 9.

The method of flowchart 900 begins at step 902. At step 902, a web service message is received from a distribution machine over a computer network, such as the Internet.

After step 902, the method of flowchart 900 proceeds to step 904. At step 904, a hash of the distributor identifier in the web service message is performed.

After step 904, the method of flowchart 900 proceeds to step 906. At step 906, one of the plurality of queues is identified based on the resulting hash value of the hash of the distributor identifier. So that the same hash value is generated each time for the same distributor identifier, the Web service messages received from the distributor will be placed in the same queue.

After step 906, the method of flowchart 900 proceeds to step 908. At step 908, the web service message is placed in the identified queue at a location determined based on the time at which the web service message was generated at the dispenser. For example, a message sequence number or timestamp contained in the web service message may be used to insert the message at a particular location into the queue so that the web service messages in the queue are stored in the order in which the messages were generated at the distribution machine.

After step 908, the method of flowchart 900 proceeds to step 910. At step 910, the web service message is processed using one of the plurality of threads assigned to the queue storing the web service message.

5. Exemplary computer System implementation

It will be apparent to one skilled in the relevant art that various elements and functions of the present disclosure described herein can be implemented in hardware using analog circuitry and/or digital circuitry, in software by executing instructions issued by one or more general or special purpose processors, or a combination of hardware and software.

For completeness, the following description of a computer system is provided. Embodiments of the present disclosure may be implemented in hardware, or in a combination of hardware and software. Thus, embodiments of the present disclosure may be implemented in the context of a computer system or other processing system. Fig. 10 shows an example of such a computer system 1000. The blocks shown in fig. 3, 4, and 8 may be executed on one or more computer systems 1000. Further, each of the steps of the methods illustrated in fig. 5-7 and 9 may be performed on one or more computer systems 1000.

Computer system 1000 includes one or more processors, such as processor 1004. The processor 1004 may be a special purpose processor or a general purpose processor. The processor 1004 is connected to a communication infrastructure 1002 (e.g., a bus or network). Various software implementations are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the disclosure using other computer systems and/or computer architectures.

Computer system 1000 also includes a main memory 1006 (storing, for example, computer programs or other instructions that implement (at least in part) the blocks shown in fig. 3, 4, and 8, and/or the steps in fig. 5-7 and 9), preferably Random Access Memory (RAM), and may also include a secondary memory 1008. The secondary memory 1008 may include, for example, a hard disk drive 1010 and/or a removable storage drive 1012, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 1012 reads from and/or writes to a removable storage unit 816 in a well known manner. Removable storage unit 1016 represents a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 1012. As will be appreciated by one skilled in the relevant art, the removable storage unit 1016 includes a computer usable storage medium having stored therein computer software and/or data.

In alternative implementations, the secondary memory 1008 may include other similar means for allowing computer programs or other instructions (e.g., computer programs or other instructions implementing, at least in part, the blocks shown in fig. 3, 4, and 8, and/or the steps in fig. 5-7 and 9) to be loaded into the computer system 1000. Such means may include, for example, a removable storage unit 1018 and an interface 1014. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, thumb drive and USB port, and other removable storage units 1018 and interfaces 1014 which allow software and data to be transferred from the removable storage unit 1018 to computer system 1000.

Computer system 1000 may also include a communications interface 1020. Communication interface 1020 allows software (e.g., for implementing the blocks shown in fig. 3, 4, and 8, and/or the steps in fig. 5-7, and 9) and data to be transferred between computer system 1000 and external devices. Examples of communications interface 1020 may include a modem, a network interface (such as an ethernet card), a communications port, a PCMCIA slot and PCMCIA card, and the like. Software and data transferred via communications interface 1020 are in the form of signals which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 1020. These signals are provided to communications interface 820 via a communications path 1022. Communications path 1022 carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link, and other communications channels.

As used herein, the terms "computer program medium" and "computer-readable medium" are used to generally refer to tangible storage media such as removable storage unit 1016, removable storage unit 1018, or a hard disk installed in hard disk drive 1010. These computer program products are means for providing software (e.g., the software for implementing the blocks shown in fig. 3, 4, and 8, and/or the steps in fig. 5-7 and 9) to the computer system 1000.

Computer programs (also called computer control logic) are stored in main memory 1006 and/or secondary memory 1008. Computer programs may also be received via communications interface 1020. Such computer programs, when executed, enable the computer system 1000 to implement the present disclosure as discussed herein. In particular, the computer programs, when executed, enable the processor 1004 to implement processes of the present disclosure, such as any of the methods described herein. Accordingly, such computer programs represent controllers of the computer system 1000. Where the disclosure is implemented using software, the software may be stored in a computer program product and loaded into computer system 1000 using removable storage drive 1012, interface 1014, or communications interface 1020.

In another embodiment, the functions disclosed herein are implemented primarily in hardware using, for example, hardware components such as Application Specific Integrated Circuits (ASICs) and gate arrays. It will also be apparent to one skilled in the relevant art that the hardware state machine may be implemented to perform the functions described herein.

6. Conclusion

Embodiments have been described above with the aid of functional building blocks illustrating the implementation of specific functions and relationships thereof. Boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Other boundaries may be defined so long as the specified functions and relationships thereof are appropriately performed.

The foregoing description of the specific embodiments will so fully reveal the general nature of the disclosure that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present disclosure. Therefore, based on the teachings and guidance presented herein, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

Claims (20)

1. An administrator controller comprising:

a message queue comprising:

a plurality of queues configured to store web service messages received from a distribution machine over a computer network, wherein a number of the plurality of queues is less than a number of the distribution machines, an

A mapper configured to place one of the web service messages received over the computer network in one of the plurality of queues based on a distribution machine from which the web service message is received; and

an administrator web service provider configured to assign a different one of a plurality of threads to each of the plurality of queues to process telemetry data contained in the web service message, the web service message being stored in the plurality of message queues, wherein the plurality of threads are configured to run on two or more Central Processing Unit (CPU) cores.

2. The administrator controller of claim 1, wherein the mapper is configured to place the web service message received over the computer network in the one of the plurality of queues based on the dispenser from which the web service message was received by performing a hash of a dispenser identifier in the web service message.

3. The administrator controller of claim 1, wherein a hash value of the hash of the distributor identifier corresponds to the one of the plurality of queues.

4. The administrator controller of claim 1, wherein the mapper is further configured to place the web service message received over the computer network in the one of the plurality of queues based on a time at which the web service message was generated at the distribution machine relative to other web service messages generated by the distribution machine in the one of the plurality of queues.

5. The administrator controller of claim 1, wherein the plurality of threads are configured to process the telemetry data by placing the telemetry data in a database, the telemetry data being contained in the web service messages, the web service messages being stored in the plurality of message queues.

6. The administrator controller of claim 1, wherein the plurality of threads are configured to process the telemetry data to assist in distributing material to the dispensing machines or to assist in maintaining the dispensing machines, the telemetry data being contained in the web service messages, the web service messages being stored in the plurality of message queues.

7. The administrator controller of claim 1 wherein the dispensing machine dispenses beverages.

8. The administrator controller of claim 1 wherein the computer network is the internet.

9. A method, comprising:

placing a web service message received over a computer network in one of a plurality of queues based on a distributor from which the web service message was received and

based on a time at which the web service message was generated at the distribution machine relative to other web service messages generated by the distribution machine in the one of the plurality of queues; and

assigning, at the assigner, a different one of a plurality of threads to each of the plurality of queues to process telemetry data contained in web service messages in the plurality of message queues,

wherein the plurality of threads are configured to run on two or more Central Processing Unit (CPU) cores.

10. The method of claim 9, wherein placing the web service message received over the computer network in the one of the plurality of queues based on the distribution machine from which the web service message was received comprises:

performing a hash of the distributor identifier in the web service message.

11. The method of claim 9, wherein the hashed hash value of the distributor identifier corresponds to the one of the plurality of queues.

12. The method of claim 9, wherein the plurality of threads are configured to process the telemetry data by placing the telemetry data in a database, the telemetry data being included in the web service messages in the plurality of message queues.

13. The method of claim 9, wherein the plurality of threads are configured to process the telemetry data contained in the web service messages in the plurality of message queues to assist in distributing materials to a dispensing machine or to assist in maintaining the dispensing machine.

14. The method of claim 9, wherein the dispensing machine dispenses a beverage.

15. The method of claim 9, wherein the computer network is the internet.

16. An administrator controller comprising:

a message queue comprising:

a plurality of queues configured to store web service messages received from a distribution machine over a computer network, an

A mapper configured to place one of the web service messages received over the computer network in one of the plurality of queues based on a distributor from which the web service message is received and based on a time at which the web service message is generated at the distributor relative to other web service messages generated by the distributor in the one of the plurality of queues; and

an administrator web service provider configured to assign a different one of a plurality of threads to each of the plurality of queues to process telemetry data contained in a web service message stored in the plurality of message queues, wherein the plurality of threads are configured to run on two or more Central Processing Unit (CPU) cores.

17. The administrator controller of claim 16, wherein the mapper is configured to place the web service message received over the computer network in the one of the plurality of queues based on the dispenser from which the web service message was received by performing a hash of a dispenser identifier in the web service message.

18. The administrator controller of claim 16, wherein a hash value of the hash of the distributor identifier corresponds to the one of the plurality of queues.

19. The administrator controller of claim 16, wherein the plurality of threads are configured to process the telemetry data by placing the telemetry data in a database, the telemetry data being contained in the web service messages, the web service messages being stored in the plurality of message queues.

20. The administrator controller of claim 16, wherein the plurality of threads are configured to process the telemetry data to assist in distributing material to the dispensing machines or to assist in maintaining the dispensing machines, the telemetry data being contained in the web service messages, the web service messages being stored in the plurality of message queues.