Regular access to the Bayesia License Server (BLS) requires credentials in the form of a username and password.
Your username and password uniquely identify you as an individual end-user.
Your username is always set to your active email address. While an email address per se is not case-sensitive, the username for BLS is case-sensitive.
Your password would be sent from bls@bayesia.com with the subject line Bayesia License Server Login Information to the email address set as your Username.
Your credentials apply across all Bayesia products, e.g., for starting a session using a Floating Token License or accessing the WebSimulator as Administrator.
To log in to Bayesia License Server (BLS), please open a web browser and visit https://bls1.bayesia.com.
Then, enter your credentials and click Submit.
If your credentials are correct, you will be taken to your Bayesia License Server Home Page (please see the BLS Access Flowchart flowchart below)
You must not share your credentials with anyone, not even with someone in your organization who might be entitled to access the same product as you.
If you don't remember your password, please check your email inbox or your spam folder for messages from bls@bayesia.com. Chances are that you can find your credentials there.
If you cannot find your password, click Forgot your password? and enter your Username, i.e., your email address. If your Username is valid, you will receive an email from bls@bayesia.com with a new password. Once you have your new password, you can return to the login page.
There are two ways for first-time BayesiaLab users to create their new user profiles (see BLS Access Flowchart), i.e., using a Registration Code or a Client Identifier.
Registration Codes are typically used for signing up a larger group of users. For example, an Account Manager may create and distribute such a Registration Code so every participant in a class can create their own user profile.
Please select Registration Code and fill in your details plus the Registration Code you received, and then click Submit.
Please note that whatever you enter as your email address will become your Username, exactly the way you spelled it and capitalized it.
We strongly recommend using lowercase characters only.
Upon submission, your new Username will be associated with the Account that generated the Registration Code.
Furthermore, you will receive two emails, both sent by bls@bayesia.com:
An email with the subject line Bayesia License Server Login Information, which confirms your Username and provides your password.
An email with the subject line BayesiaLab Download & Activation Instructions, which contains a link for downloading the BayesiaLab installation files.
Depending on the way you or your organization licensed BayesiaLab, you may receive a Client Identifier in the following format: AAAA-BBBB-CCCC-DDDD.
Please select Client Identifier and provide your details plus the Client Identifier and then click Submit.
Please note that whatever you enter as your email address will become your Username, exactly the way you spelled it and capitalized it.
We strongly recommend using lowercase characters only.
Upon submission, your new Username will be associated with the Account that generated the Registration Code.
Upon submission, your Username will be associated with the Client Identifier you provided.
Furthermore, you will receive an email from bls@bayesia.com with the subject line Bayesia License Server Login Information, which confirms your Username and provides your password.
A Client Identifier is directly linked to a specific license and license term of a BayesiaLab product. Please note that the Client Identifier exists even before any Usernames are created. So, by registering with a Client Identifier, you attach your Username to an existing Client Identifier, like adding your name to a title of a vehicle that already has a VIN or serial number.
If you are the first Username to register with this Client Identifier, you "claim" that Client Identifier and will automatically become an Account Manager.
If additional Usernames register with the same Client Identifier after you, you will receive an email asking you — as an Account Manager — to validate their registration as new Users.
Conversely, if you are not the first one to register, you will need to wait for approval from an Account Manager before you can connect to BLS with your Username.
The Bayesia License Server (BLS) manages the distribution, activation, and use of all of Bayesia's products. It is the central "authority" that keeps track of accounts, users, user groups, licenses, usage, etc.
If you have a Floating Token License, a WebSimulator account, or have subscribed to an Elastic Pricing plan, you can monitor and manage your Account on the Bayesia License Server (BLS) via the web interface described in this section.
If you have Single-User/Single-Machine (SUSM) License, your BayesiaLab software will only need to connect with BLS (automatically or manually) once at the beginning of each license term, e.g., once a year.
Even if you do not require access to BLS for your purposes, it may be helpful for you to understand the relationships of properties related to the BayesiaLab license you use.
Account refers to the entity that has a commercial agreement with Bayesia. Typically, there is one Account per organization, although large organizations may have one Account for each division or separate Accounts for certain regions.
Managers are authorized to create and delete Users and Groups and assign an Account's Subscriptions to Groups.
Users are individuals — identified by their unique Usernames — who run and utilize Bayesia's software.
A Group can be created to assign privileges to a collection of Users. By default, there is a User Group and a Manager Group. Managers can create any number of Groups to define and/or restrict access to Bayesia's software.
Subscriptions are "owned" by Accounts and refer to term-based licenses to Bayesia's software. Managers can authorize Groups to utilize the Subscriptions of an Account.
Sessions refer to instances of running Bayesia's software. As such, Sessions have a start and end date/time and are linked to specific Users. The number of Sessions that can run simultaneously, and the physical locations where Sessions can run, is governed by the Account's Subscriptions.
Usage (or Usage Hours) refers to the time duration between the start (or launch) of the Session and the end (or termination) of each Session.
The following diagram illustrates the hierarchy of elements in BLS:
BayesiaLab and the Bayesia APIs always run locally on the hardware on which you installed the software, e.g., your desktop or laptop computer.
BayesiaLab is not a SaaS product, i.e., it is not "software as a service."
There is no provision for running BayesiaLab remotely on Bayesia's servers.
Your local BayesiaLab installation never transmits any of your data or models to the Global Bayesia License Server.
The only information sent to the Global Bayesia License Server is the user login and hashed password, the user account, and the version of BayesiaLab software currently in use.
For each session, only the username, account, start and end date/time of the session, plus the associated IP address, are stored on the Global Bayesia License Server.
Any temporary connection ("ping") to the Global BayesiaLab License Server only serves the purpose of validating your licenses.
All data and models are stored within the infrastructure you control unless you explicitly choose to upload them elsewhere, for instance, to the BayesiaLab WebSimulator Server, with the express intent of sharing your model​.
Bayesia staff has no access to or visibility of your models or data through the BayesiaLab software.
By default, all BayesiaLab software and the Bayesia APIs connect to the Global Bayesia License Server, which is physically located at Bayesia’s corporate headquarters.
This requires your locally-installed BayesiaLab software to connect to bls1.bayesia.com on the destination port 2424, i.e., the BayesiaLab software opens a TCP/IP connection with bls1.bayesia.com:2424.​
If your computer is behind a firewall, you may need to ask your IT department to define an exception to allow you to connect.
To check whether you can connect to the Global Bayesia License Server, open Command Prompt (on a Windows PC) or Terminal (on a Mac) and enter ping bls1.bayesia.com.
If a corporate firewall prevents TCP/IP connections to bls1.bayesia.com, a Local Bayesia License Server can be installed within your corporate environment.
The Local Bayesia License Server consists of a small program that runs in the background on a server to which your locally-installed BayesiaLab software and the APIs can connect.
This setup requires a one-time connection per license term, e.g., annually, to the Global Bayesia License Server to initialize the Local Bayesia License Server.
For the ongoing operation, however, no Internet connection is required on your server, and all ports can be blocked.
BayesiaLab and the Bayesia APIs always run locally on the hardware on which you installed the software, e.g., your desktop or laptop computer.
There is no provision for running BayesiaLab remotely on Bayesia's servers.
Your local BayesiaLab installation never transmits any of your data or models to the Global Bayesia License Server.
The only information sent to the Global Bayesia License Server is the user login and hashed password, the user account, and the version of BayesiaLab software currently in use.
On the BLS Home Page, you have access to your personal information, including your username and your role, i.e., Manager or User.
Also, you can always access the Personal Information tab from other areas in BLS by selecting Personal Information from the drop-down menu attached to your Username in the upper right-hand corner of the browser window.
Clicking Change Your Password brings up a window that allows you to set a new password.
Clicking Sign Into Another Account allows you to connect your personal Username to a different or additional Account.
For instance, you may want to add a Single-User/Single-Machine license that your company purchased for you. In this case, you would add the Client Identifier (AAAA-BBBB-CCCC-DDDD) of that new license.
If you were adding the Client Identifier of a Floating Token License to your Username — and also the first one in your organization to do so, you would automatically become an Account Manager.
If there were already an existing Account Manager, he would be notified by email to validate your request. In this case, an Account Manager can validate your access via the User Access Validation tab.
A Voucher is a personal code that Bayesia can provide for specific products and purposes, such as Private WebSimulator Accounts. Simply enter your Voucher Code and click Validate.
If you are an Account Manager, you can use the User Access Validation tab to approve Usernames to attach themselves to existing Client Identifiers and, thus, use the corresponding license.
The Session Dashboard tab offers tools for analyzing the usage of Floating Token Licenses or Elastic Pricing Licenses that are associated with Accounts of which you are a Manager.
Given the wealth of information available on the Session Dashboard, you may want to limit the presentation of data to certain subsets.
You can set filters for:
Users
Subscriptions
Time Periods
Any filter you define here applies to all Dashboard Views.
Under the Charts tab, you can view plots for numerous usage metrics:
Sessions time: total time of usage by day
Sessions number: total number of sessions by day
Session result: the failure rate of sessions, e.g., due to connection problems with BLS
Parallel sessions: number of concurrent users by day
Max parallel sessions: maximum number of simultaneous user sessions in a day
Hourly usage: usage by hour
The User Information tab provides an overview of the current usage of your Floating Token Licenses for each user. Icons indicate the three possible connection states of each user:
The Subscription Information tab shows the usage for each subscription that is associated with your Account.
The Sessions Details tab lists all User Sessions, past and present.
Actions
In the Actions column, a Manager can send messages to any User who is currently connected to BLS or, if necessary, close or "kill" any active Session.
Closing a Session can be helpful, for instance, when a user forgets to close his BayesiaLab session, thus "hogging" a token and preventing another User from starting a Session.
The Connection Map shows all the locations where your BayesiaLab tokens have been used.
In Account Management, you can manage all the different components and properties of your Account.
Account refers to the entity that has a commercial agreement with Bayesia. Typically, there is one Account per organization, although large organizations may have one Account for each division or separate Accounts for certain regions.
Managers are authorized to create and delete Users and Groups and assign an Account's Subscriptions to Groups.
Users are individuals — identified by their unique Usernames — who run and utilize Bayesia's software.
A Group can be created to assign privileges to a collection of Users. By default, there is a User Group and a Manager Group. Managers can create any number of Groups to define and/or restrict access to Bayesia's software.
Subscriptions are "owned" by Accounts and refer to term-based licenses to Bayesia's software. Managers can authorize Groups to utilize the Subscriptions of an Account.
Sessions refer to instances of running Bayesia's software. As such, Sessions have a start and end date/time and are linked to specific Users. The number of Sessions that can run simultaneously, and the physical locations where Sessions can run, is governed by the Account's Subscriptions.
Usage (or Usage Hours) refers to the time duration between the start (or launch) of the Session and the end (or termination) of each Session.
This diagram illustrates a typical example of an Account:
6 Users, including:
1 Manager
5 Users
3 Subscriptions, including:
Floating Token License
WebSimulator
API
3 Groups, including:
1 Manager Group
2 User Groups
Manager #1 can manage the Account and has access to all Subscriptions.
User #1 and User #2 belong to Group U1 and can use the Floating Token License and the WebSimulator.
User #4 and User #5 belong to Group U2 and can use the WebSimulator and the API.
User #3 belongs to both Groups, i.e., U1 and U2, and therefore has access to all Subscriptions.
There are four types of properties that control the access and usage of individual Users to Bayesia software subscriptions.
Managers define the Group memberships of a User using two properties:
User's Group (Membership) Expiration Date: on this date, the User's membership in the Group will expire, meaning he will no longer have access to the Subscriptions assigned to this Group.
#Hours (applies only to Floating Token Licenses and Elastic Pricing Plans): the maximum number of hours a User can utilize a Subscription as a member of the Group. Once the limit is reached, access to the Group's Subscription is revoked. 00:00:00 indicates that no limit is defined.
Managers can use five properties to customize a Group's access to the Subscriptions of an Account:
Groups' Subscription Expiration Date: on this date, the Group's access to the listed Subscription will be disabled. As a result, all Users who are members of the Group will no longer have access to the Subscription.
#Hours: Managers can set a maximum number of Usage Hours that applies to all Users that are members of the Group. A value of 00:00:00 indicates that no limit is set at the Group level. However, an individual User can still have a Usage limit regarding his membership in the Group.
Max Borrow Time (applies Floating Token Licenses and Elastic Pricing Plans only): Users in the Group can borrow tokens for no longer than the duration specified here.
Primary Access Priority (applies to Floating Token Licenses only): Users who are members of the Group have the specified priority in situations when there are competing requests for access to Subscriptions. For instance, the Group Student Interns may be given a lower priority than the Group Senior Analysts regarding the use of a limited number of available Subscriptions. "Primary Access" refers to the first Session a User launches.
Secondary Access Priority (applies to Floating Token Licenses only ): Same as above, except that it refers to the second Session as User launches. Thus, a User in the Group Research Fellows could be allowed to launch two Sessions simultaneously, while Users in the Group Trainees cannot launch any Session at all. Setting 0 for this priority prevents the Group's Users from launching a second Session.
When a member requests access to a subscription and no tokens are available, a primary or secondary session with a lower priority (if any) is closed to release the token. The user of the to-be-closed session is notified that a user with a higher priority is requesting access to the token, and he is then prompted to save his current work.
The Kick Order is the only subscription property modifiable by the managers. This is only for subscriptions using tokens.
This parameter allows you to define the policy used when a session has to be closed because a higher-priority user is requesting access to a session that has no more available tokens. When several sessions with the lowest priority have been identified, the session to be closed is either the older one (First Session) or the most recent one (Last Session).
Fives properties are available for Managers to customize Groups:
Group Expiration Date: beyond this date, the group is set Disabled, which prevents its members to use the associated subscriptions.
#Hours: when this property is set to a value different from 00:00:00, it is associated with each member, unless the member has already a value that has been set via the Users' Group Properties or the Groups' Subscription Properties.
Max Borrow Time: maximum duration of an offline session allowed for the group members. This will only be applied as a default value for the subscriptions using tokens or elastic plans, unless this property has been set via the Groups' Subscription Properties.
Primary Access Priority: priority level associated with the user's primary session of the group members. This will only be applied as a default value for the subscriptions using tokens, unless this property has been set via the Groups' Subscription Properties.
Secondary Access Priority: priority level associated with the user's concurrent sessions (except his/her primary session) of all the group members. Note that setting 0 for this priority prevents the member to have any concurrent sessions. This will only be applied as a default value for the subscriptions using tokens unless this property has been set via the Groups' Subscription Properties.
This view allows accessing the information about the account.
The fields highlighted in green can be edited by the managers.
This tab allows managing the groups.
One Manager Group and one User Group are automatically generated when a new Account is created. These two groups are mandatory, and they cannot be removed, nor have their Type changed.
The fields highlighted in green can be edited by the managers.
This tab allows adding and removing users to the account.
The fields highlighted in green can be edited by Managers.
The Username should be the user's email.
The user is associated with the default User Group.
When a subscription with tokens or an elastic plan is associated with the group, the "BayesiaLab Download & Activation Instructions" email is automatically sent to the user upon validation.
The managers need thus to go to the Users' Group to change the group or some other properties.
The Remove button becomes active upon the selection of a user.
Note that users that had an activity are not really removed; they are only set to Disabled.
This tab allows defining the group membership of users and their properties.
The Users' Group Properties have the highest priority, i.e., they cannot be overridden by the properties defined via another view.
When a subscription with tokens or an elastic plan is associated with the group, the "BayesiaLab Download & Activation Instructions" email is automatically sent to the user upon validating the creation of a user.
To resend this email, the managers just have to select the user and click "Send Download Information".
This view returns the subscriptions (tokens or elastic plans) associated to the account.
Among all these fields, only the fields highlighted in green can be edited by the managers.
This view provides information about the BayesiaLab WebSimulator subscriptions.
Among all these fields, only the field highlighted in green can be edited by the managers.
Number of Models: number of simulators you can publish simultaneously with this subscription.
Number of Available Models: number of simulators that can still be published with this subscription.
Type: indicates if the subscription corresponds to Public (anyone can potentially access your simulator and experiment with it) or Private simulators (you can restrict access to designated users who require a model-specific ID and password).
End Date: the expiration date of the subscription.
This tab allows managing the association between Groups and Subscriptions.
Among all these fields, only the fields highlighted in green can be edited by the managers.
The Groups' Subscription Properties have a higher priority than the Group Properties. This means that if they are not defined in this view, they inherit those defined in the Group Properties; otherwise, they are not overridden.
Instead of manually adding users, the managers can create a registration code to let their team members register by themselves via the Sign In function.
Duration: validity period of the form (optional).
Access duration: validity period of access to the products of the account by the user (optional).
Expected: number of users that are expected to register (optional).
Registered: number of users that have used the form so far to register
Code: registration codes the team members have to use in the registration form to get BLS credentials and be associated with the account.
the user is not running BayesiaLab.
the user is currently connected to BLS.
the user is currently "borrowing a token" and running BayesiaLab offline without a connection to BLS.
Send Message
Close Session