Often, we think of the activation of reader applications as one and done. The user gets a device, downloads a reader, and activates it with an Adobe or Vendor ID. The user then goes on to buy a few books and reads them. But, what happens when they visit a second site and are given a new ID for that site and fulfill books with the new ID? What type of a user experience should we expect them to have? Should the user deactivate then reactivate with the new ID? Or, can we make the issue more transparent? Luckily, RMSDK supports a couple different workflows. RMSDK allows applications written to support Join Accounts and Multiple Activation. Let’s look at two options:
Join Accounts allows devices activated with one ID to be able to read books previously fulfilled with another ID. The goal is to provide a convenient method of synchronizing multiple reader accounts for the same user, particularly if the user has purchased books from multiple vendors who support Vendor ID accounts. When two or more accounts are joined, they form a group. For all practical purposes, there is no limit on the number of accounts that can be joined as a group.
Once an account is joined to a group, there is no way to “unjoin” or remove an account from a group. Once an account is joined with a group, it cannot join another. For example, let’s say you have four accounts A, B, C, and D. If A and B are joined, and C and D are joined, A can’t be later joined with C. How are activation limits effected when accounts are joined? Once two or more accounts are joined, the activation limits are applied to the group not the individual accounts. So, the group is limited to activation of six devices, not six times the number of accounts in the group.
So, how does this work from a user perspective? Let’s say a user has an RMSDK application that they have activated with Account A, which is the only login account they have used with the application. What if they try to open a book (say, Book2) from another account (say, Account B)? If Account A and Account B are joined already, then Book2 should open just like if you are opening a book fulfilled under user Account A. If Account A and Account B are not joined yet, the application will prompt the user with a web page to join both accounts (only a device or app that has internet connection can initiate the joining process). When the user finishes the joining step and goes back to the reader app, the Book2 from Account B should be allowed to open at this point. Going forward, the user will be able to open books from either Account A or Account B directly in the application.
Joined Accounts allows a seamless integration of a reader’s multiple accounts. There may be many reasons that a reader has multiple accounts, either from Adobe or from multiple vendors. By giving the reader the ability to read these books on one device, and by allowing readers to join these accounts together overall, helps promote a more interoperable reading environment.
Multiple Activation allows RMSDK applications to be written so that they can be activated with multiple accounts. The application can then open books fulfilled by any of these accounts. New books are fulfilled by the default activation (first one) or APIs are available to set an active user account. A user interface for the application would need to be developed to support this “active user” concept. Any accounts used by an application that support Multiple Activation are still restricted to the same standard six mobile, six device activation limits.
There are a couple of main differences between Join Accounts and Multiple Activation. Join Accounts allows a reader to do a single activation (i.e., the reader only needs to enter one credential), and the reader application can fetch the joined accounts, subsequently enabling the reader to read books fulfilled with any of these accounts. Once joined, installing new applications or installing the application on a different device, only needs to be activated with one of the joined accounts.
Multiple Activation is only in effect for the current application. If the application is deleted, when re-installed all accounts must be re-entered again. If the user gets a second device, the accounts must be re-entered there as well.
It should be noted that if your RMSDK application supports Vendor ID, it is a requirement of the certification process to support Join Account, but support of Multiple Activation is optional. If you would like more information on the subject, please see the document referenced in our Knowledge Base article for the subject.