Registering Users on VersaCloud

As already mentioned briefly, users are registered on VersaCloud by calling the 'UserAddAllow' and 'UserAddCommit' APIs. In order to register a user, we require providing his full name, a Valid e-mail address, his own birth date and the country he currently lives in. The language he wants to use to communicate and the solution token are also required, but are generally provided from inside the front-end software's code.

Just upon the call to the 'UserAddCommit' API, the user's token is created inside the finite state automaton (by means of a relational database trigger in our current implementation). From this moment on, the user is registered on our cloud-based time-limited transaction manager. If requested when calling the 'UserAddAllow' API, the user will be notified of this fact through an e-mail message sent out to the address he provided, which includes the user's token. Alternatively, the same solution that registered the user must handle this part of the process, retrieving the fresh user's token by calling the 'UserTokenGet' API. The 'UserTokenGet' API will only inform the user token to the same solution that registered the user and only while the user's password has not yet been created.

Data collected about the user on registration does not get through any kind of verification, but might be requested from the user in the future, as special certification for sensitive operations (like recovering lost user tokens). Hence, if the user lied when providing his personal data, he will have to remember his lies over a possibly long period of time.

Once a user is registered on our cloud-based time-limited transaction manager, he needs to create his password before being allowed to log into our cloud-based time-limited transaction manager and the solution he wants to use. Calls to the 'UserPasswordSetAllow' and 'UserPasswordSetCommit' APIs must be used to run the password creation transaction.

Our cloud-based time-limited transaction manager shares, in principle, all registered users with all registered solutions. This way, users can try new solutions using the same balance they already own due to the fact they are already using other solutions. This strategy allows for cross-marketing and cross-selling actions among solutions registered with our cloud-based time-limited transaction manager. Hence, in some way our cloud-based time-limited transaction manager can be described as a solution marketplace: for example, promoting all registered solutions on a website is a rather obvious initiative.

US Patent Requested