VersaCloud's User Groups
User groups are defined in our transaction manager simply as set of users. Each user can be a member of as many users as necessary. In order to add a user to a user group, the first step is assuring the user group has been created; if it does not yet exist (which can be verified by calling the 'GroupValid' API), it can be created by calling the 'GroupAddAllow' and 'GroupAddCommit' APIs.
Once a user group has been defined, users can be added to that group by calls to the 'GroupMemberAddAllow' and 'GroupMemberAddCommit' APIs. Group membership can be limited in time, optionally having a specific start and/or end timestamp, defined through calls to the 'GroupMemberSinceSetAllow', 'GroupMemberSinceSetCommit', 'GroupMemberUntilSetAllow' and 'GroupMemberUntilSetCommit' APIs. Current values can be retrieved by calling the 'GroupMemberSinceGet' and 'GroupMemberUntilGet' APIs.
Some of the group's members can be defined as user group administrators (or have that privilege removed) by calling the 'GroupAdminAddAllow' and 'GroupAdminAddCommit' APIs. Group administrators have the privilege to add new (or remove existing) members to the groups they are administering.
User groups can receive and store amounts of credits, to be used by the user group members to pay for transactions they will run: in this way, an organization which has a couple of users consuming transactions demanding payment on our cloud-based time-limited transaction manager, can centralize buying credits (for example, by the procurement department) and then have their users consume this credits. A group's current balance can be retrieved (by group administrators or members) through a call to the 'GroupBalanceGet' API.
Only users owning the 'balance manager' right can add new credit to a group by calling the 'GroupBalanceAddAllow' and 'GroupBalanceAddCommit' APIs. 'Group administrator' right owners can transfer credits from a group to specific users, both manually or whenever a user's balance falls below a specified threshold, by calling the 'GroupBalanceTransferAllow', 'GroupBalanceTransferCommit', 'GroupBalanceAutoTransferAllow' and 'GroupBalanceAutoTransferCommit' APIs.
When credits are transferred automatically from the user group to its individual members automatically, group administrators can define limits for credits consumption, both for the user group as a whole (by means of calls to the 'GroupExpenseLimitAllow' and 'GroupExpenseLimitCommit' APIs) as well as for specific group members (by calling the 'GroupMemberExpenseLimitAllow' and 'GroupMemberExpenseLimitCommit' APIs).
In both cases, expense limits are defined by two parameters: the maximum number of credits to be consumed, and the time period over which they can be consumed (measured in seconds). This way user group administrator can define, for example, a limit of one credit per minute for a specific user, or a limit of thousands of credits over a month for a huge user group, to limit expenses. Whenever an '…Allow' API call with an associated cost takes place and the user has surpassed his authorized credit consumption limits, the request to run the transaction gets denied by our single entry point engine. See Figure 12 for details of group credit's usage to decide whether a transaction with cost can be paid for or not.
A special case of user groups is handled by the optional 'sponsoring solution token' parameter of the 'GroupAddAllow' API: for standard user groups, as described above, this parameter's value is omitted. In case GroupAddAllow is called with a valid solution token as the value of this parameter, our cloud-based time-limited transaction manager interprets the call as defining a 'sponsorship' relation between the solution the token stands for and this specific user group.
Once a user group is sponsored by a solution, credit processing is handled differently by our single entry point engine. First, sponsored user groups' credit balance cannot be used to recharge user accounts that have their balance running low. Second, when running a non-zero cost transaction that is part of this solution, the sponsored user group is charged directly (while the user's balance remains unchanged; that is the base for naming this situation 'sponsored').
In practical terms, sponsored user groups allow any corporation to develop solutions based on our cloud-based time-limited transaction manager and pay for the credits the processing of their transactions will demand, allowing the corporation to provide services to their users or customers, without having these being charged.
Note that the 'GroupAddAllow' API has been defined to have a second optional parameter named 'SponsorshipRemove', whose 'boolean' value being 'true' will result in removal of a solution's sponsorship from a specific user group: from the moment on sponsorship is removed, the user group's members will fall back to the standard credit purchase and consumption process.
US Patent Requested