Browse Prior Art Database

A mechanism for managing pay as you go pricing in a messaging as a service system Disclosure Number: IPCOM000249370D
Publication Date: 2017-Feb-22
Document File: 3 page(s) / 40K

Publishing Venue

The Prior Art Database


As messaging as a service grows in importance there is a need to have a flexible way for paying for the use of the underlying messaging network. Many cloud based messaging services view the underlying messaging network as a monolith from a charging perspective which may not be appropriate in all cases, especially when hybrid messaging environments are formed which require a consistent charging model. This article describes a way of charging for use of a messaging network which can take account of the topology of the network and the number of 'hops' that a given message will take through the different messaging nodes in the network.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

A mechanism for managing pay as you go pricing in a messaging as a service system

Many existing cloud based messaging providers charge using some variation on price per million messaging operations performed. In some cases the actual size of a message also affects the cost. All of these providers treat the messaging network as a monolith and do not account for the fact that messages might move between messaging nodes in the network, or need to be replicated between multiple replication zones, and as a result some messages cost more than others. This is a particularly important problem when charging for use of messaging networks that transition from the cloud to on-premise, or even in an entirely on-premise messaging environment.

The following steps describe how a more accurate charging model for messaging, which takes account of the messaging node topology, could be achieved:

1) When a message is sent into the first node in a messaging network the messaging node inserts into the message two meta-data fields: cost and user. The 'user' field represents an appropriate token that identifies the sender of the message for charging purposes. The 'cost' field is an integer value representing the cost of the message and might be static per message, or vary depending on other aspects of the message such as size, priority, time-to-live, etc.

2) If the message is not routed to other nodes in the messaging network then the messaging network takes the value of the cost field from the message and adds it to the total that is associated with the user. This value is then periodically taken and scaled and turned into a $ value which is charged to the user. Up to this point this is essentially the same approach used in the prior-art cited in section 2 above.

3) If, because of the configuration of the messaging network, the message is then transmitted to another node in the messaging network the cost field in the message is adjusted, either up or down, based on an algorithm so as to reflect the cost of transmission to the new node. This may be as simple as scaling the cost field for each transmission, but many other variants would be possible. For each subsequent transmission through the network the same approach would be taken until the message reached its final destination and could be consumed by a user of the messaging network. In some cases the user field might also need to be adjusted too, for example if different parts of an organization were chargeable for the different nodes.

4) At each node on the network the cost of all messages per user are added up and used for charging purposes.

It is important to note that if the message is taken out of the messaging network by a user and then sent back into the network it is treated as a new message and the 'cost' and 'user' fields of the message are reset as per step 1 above. That is a normal user cannot set the 'cost' and 'user' fields, only nodes in the messaging network, for example a queue manager, can.