Patent Application
20140365910
The present disclosure relates generally to mobile technology platforms and, more particularly, to systems and methods for distributing and sharing applications among personas on a mobile device.
Mobile technology platforms, including mobile communications devices and mobile computing devices, are used in various settings for various purposes. Frequently, it is desirable for the user of such a device to adopt various roles or “personas” while using the device. For example, the user may be utilizing the device for both personal and business use and, thus, has the need to switch between these personas.
In light of the foregoing, some systems have been developed to allow users to switch between different personas. For example, U.S. Pat. No. 7,086,008 (hereinafter “Capps et al.”) discloses computer systems which may adopt one of many personas depending upon the role that the user is currently undertaking. The computer system includes a central repository of extensible personas available to all applications running on the computer system. Each such persona has associated therewith a suite of parameters, or specific values for parameters, which are appropriate for conducting transactions in the name of their particular persona.
The computer system of Capps et al. further provides a graphical user interface which allows the user to switch from persona to persona by simply selecting a particular persona from a list of available personas on a display. By selecting a persona, the user causes the computer system to globally change the entire suite of parameter values so that subsequent transactions conducted with the computer system employ the parameter values of the currently selected persona.
In preferred embodiments of the system of Capps et al., the suite of parameters representing a given persona can be extended by applications running on the computer system. Specifically, various applications may add certain persona-specific parameters to the system's personas as required.
Capps et al. also discloses various techniques for changing the current persona adopted by the computer system. In accordance with one such technique, the user is allowed to select one of the personas listed on the display menu or on the list described above. Capps et al. notes that, in a pen-based computer system, this is preferably accomplished by determining when a user has tapped with a stylus on a displayed persona. In another technique disclosed in Capps et al., the current persona is determined by (1) identifying a password input by the user; (2) matching the password to one of the multiple personas available on the computer system; and (3) specifying, as the current persona, the persona which is matched to the password in the previous step.
The subject matter disclosed herein is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the disclosed embodiments will be apparent from the following detailed description taken in conjunction with the accompanying drawings.
In one aspect, a system and method are provided for a cross-persona-launch which may be implemented by selecting a cross-persona launch icon or menu item, through a sensor input or voice command, or by way of a suitable gesture. In these systems and methodologies, an icon, menu item, suitable gesture, voice command, or sensor input in one persona may launch the same or different application in another persona, and switch to that persona. The icon may be marked or tagged to indicate this behavior.
Possible examples of suitable gestures include, but are not limited to, finger gestures such as drawing of a circle on a touch screen, a long tap, or dragging an icon to a certain location. Possible sensor inputs include, but are not limited to, near-field communication (NFC) signals, Bluetooth® (BT) signals, radio frequency (RF) signals and infrared (IR) signals.
In another aspect, systems and methodologies are disclosed herein which allows switch-by-context (action) between personas. In these systems and methodologies, some applications on a mobile technology platform (referred hereinafter also as mobile devices merely for the sake of simplicity of the description) may launch other applications or activities in response to user actions, for example, tapping continuously on an entry in the mobile device logs may allow users to go to text-messaging. The user's actions and the related content are examined and compared against a set of rules and data. If a match is found, the corresponding application or activity is launched in a different persona, and the user is switched to that persona such that the persona in which the application is launched becomes an active persona.
In a further aspect, systems and methodologies are disclosed herein which allow switch-by-content) switching between personas. In these systems and methodologies, tapping on certain content type on a mobile device automatically launches a corresponding application or activity, for example, a uniform resource locator (URL) in a browser, or a phone number in an email). The selected content type is examined against a set of rules and data. If a match is found, the corresponding application or activity is launched in a different persona, and the user is switched to that persona (that is, the different persona becomes the active persona).
The foregoing aspect addresses instances in which a switch of personas occurs based on content or context. However, some of the disclosed embodiments are concerned with partial data sharing, in which data (or portions thereof) from one persona is made to appear in another persona, possibly with an indication of the origin of the data. One example of such data is contact information. Content-based or context-based switches between personas may be even more advantageous or intuitive.
In still another aspect, systems and methodologies are disclosed herein for indicating to users when an implicit switch to another persona has taken place, either before or immediately after the switch, thereby maintaining the user's awareness of his/her working context.
In yet another aspect, systems and methodologies are disclosed herein for sharing applications between personas by running a single instance of the application in a dedicated “sharing persona”. Launching a shared application from any persona (hereinafter, such launching personas referred to as “persona of origin”) will start the application in its dedicated sharing persona, and switch to that persona. Awareness indicators, such as the status bar color and icon, as well as the user's customized settings and profile (such as wallpapers, screen timeout settings, and the like), may appear as if the persona of origin is running, thereby providing transparency such that the user may not notice the switch. Exiting the application, or switching to another application, will resume the persona of origin.
Sharing in these systems and methodologies may be limited to specific personas by setting application icons to launch into one sharing persona or another. Also, some aspects of the indicators (and/or the user's customized settings) may intentionally appear different if, for example, there is a need to indicate that the user is operating in a shared persona.
Switching between personas in these systems and methodologies may occur while in a shared persona. Such switching will preferably change the effective persona of origin. Thus, for example, if a user has two personas A and B, and the user enters the shared persona from persona A (the persona of origin), a switch between personas (for example, by tapping an icon) will make persona B the new persona of origin and will change the context to persona B, thereby making the awareness indicators and the user's customized settings appear as if persona B is running.
In yet another aspect, systems and methodologies are disclosed herein for sharing of a single instance of an application among multiple “users”, each with his/her own data store (as used here, the term “users” may refer to the same person acting under different and separate personas). Launching an application from any persona will bind the data from that persona to the sharing persona, start the application in the sharing persona, and cause a switch to the sharing persona. Awareness indicators such as status bar colors and icons, as well as the user's customized settings and profile (such as wallpapers, screen timeout settings, etc.), may appear as if the persona of origin is running, thereby providing transparency such that the user may not notice the switch. Exiting the application, or switching to another application, will resume the persona of origin. Launching the same application from another persona concurrently will first close the existing instance, bind the data from the new persona in the sharing persona in place of the previous one, start the application in the sharing persona, and cause a switch to the sharing persona.
In various embodiments, sharing may be limited to specific personas by setting application icons to launch into one sharing persona or another.
Switching between personas may occur while in a shared persona. Thus, if a user has two personas A and B, and the user enters the shared persona from persona A (the persona of origin), a switch between personas (for example, by tapping an icon) will make persona B the new persona of origin and will change the context to persona B, thereby making the awareness indicators and the user's customized settings appear as if persona B is running. Also, some aspects of the indicators (and/or user's customized settings) may intentionally be made to appear different if there is a need to indicate that the user is operating in a shared persona.
In yet another aspect, systems and methodologies are disclosed herein for providing a common data store for data that is to be shared between personas. In some embodiments, access to the data may be abstracted in each persona through the use of proxies. Access to the data may be restricted according to suitable access policies. In other embodiments, data may be shared via a shared file or directory that is made visible or accessible to the respective application in each persona.
In still other embodiments, data may be shared by way of data proxies that intercept the access to the data (whether the access is to a file or a database) and perform a suitable remote procedure call (RPC) to read or write the information to or from either a central service or a service in the other persona.
In still further embodiments, data may be shared via shared content providers that implement standard services in the mobile system (such as the contacts store or calendar events store). The system then uses such services to obtain or put data, and the services may delegate the requests to a central service or to a service in the other persona. It will be appreciated that, in this embodiment, the content provider does not intercept all attempts to access the resource (that is, the content provider does not virtualize the resource). Rather, the content provider registers as a special purpose content provider alongside the other content providers that may exist.
In another aspect, systems and methodologies are disclosed herein for storing global device settings (for example, the device settings of a host mobile technology platform) in a shared persona. Calls to read or modify settings (e.g., within the mobile operating system framework, e.g., the Android™ framework) may be redirected using proxy logic to a service in the sharing persona.
In a further aspect, systems and methodologies are disclosed herein for implementing a general purpose data, service, or state (hereinafter referred to individually as an object, and collectively as objects) publishing mechanism that may be used between different personas. Applications may publish data by indicating the object type, object properties, object access control, and the actual object to share. The object may be filtered before passing it on to the publishing mechanism. Object type refers to the contents of the data such as, for example, the contacts and emails.
In some embodiments, object properties may be utilized to define the sharing behavior such as, for example, the expiration time for the object or whether the object is persistent data. Object access controls may be utilized to define which other personas (or classes of personas) can view, modify or, use the published object, as well as whether the object can expire, be updated by the publisher, or be revoked by the publisher. The object access controls may be defined, for example, by the administrator of a managed persona or by the user. In some embodiments, the object access controls may be defined for a user by an administrator via a management system.
An application can request an object by querying for an object of a certain type. Preferably, only applications from authorized personas will have access to the object. In an embodiment, a persona may be authorized at the time of publication by the persona of origin via, e.g., an input from the user of the persona of origin granting authorization to a persona. This query may be utilized, for example, to implement shared contacts where the work persona only reveals a portion of the object per contact.
In some embodiments, the manner in which data or a state is presented to the user may also be persona dependent. Thus, for example, the data or state may be presented “as is,” i.e., showing the contacts of both personas, or may be presented with an indication of the persona of origin. Similarly, in some embodiments, authorization may depend on the persona of origin, the persona that wishes to access the object, the object type, or various other parameters such as, for example, the time of day and other sensors, or the content of the object.
Published object data may also carry some metadata containing information about the origin of the data such as, for example, the persona, service or process of origin, or credentials. The metadata may also indicate the context of the “caller” in the original environment, and may be used, for example, to exercise permission checking in the target environment.
In yet another aspect, systems and methodologies are disclosed herein which extend the previous methodology by adding a “callback handler” property to object. If a callback handler property is defined and an object query cannot be satisfied with data stored by the shared-service, the service invokes the callback handler. This callback handler runs in the application in the persona of origin. For example, for applications that rely on data stored in the cloud or on company servers, the callback handler may perform the actions that the application usually performs to bring the requested data from, for example, external sources such as cloud services or company servers. The callback handler may filter the data before handing it over to the sharing service, after which the sharing service may reply to the original query. The sharing service may therefore be viewed as a proxy to the application responsible for bringing or delegating the object. Callback handlers may also be used as a notification mechanism for the application in the persona of origin to be notified of access requests.
It will be appreciated from the foregoing that, in general, an object type may have a callback handler associated with it which is called whenever the object is accessed. The callback handler may be delegated to the respective application in the persona of origin and, if so designated, will run there. The callback handler may respond with more objects, which may be filtered.
The callback handler may request additional data from an application that relies on cloud data or company-backed data. In such uses, the callback handler may return the additional data. Further, the callback handler may allow the application of origin to be notified of requests to access data. In such uses, the callback may not return data, but may instead log the activity for audit or statistics.
In another aspect, systems and methodologies are disclosed herein for implementing a service for synchronizing accounts and data. For each account or data type that can be synchronized, the service imitates a cloud (synchronization, or “sync”) service, but executes locally. Along with the sync service, an instance of the application that uses that data and which is connected to the actual service provider in the cloud is also run. Applications of this type which run in a user's personas and which rely on syncing to the service provider are configured to sync instead with the “local cloud” shared service. This mechanism leverages the application's native logic to synchronize its data with the “local cloud” in the sharing persona and, through that local cloud, with other instances of the application in other personas. Some non-limiting examples of data that may be synchronized in this manner include, but are not limited to, email, contacts, and calendar events.
In another aspect, a method may further comprise extending virtualization and separation approaches that facilitate multiple personas (e.g., ThinVisor™ or hypervisors) to support additional user space components, such as Bluetooth®. Such support may be achieved by running a single instance of the respective service and applications in a dedicated sharing persona, and by tunneling access from other personas through it.
In a further aspect, components of virtualization and separation approaches that facilitate multiple personas (such as, for example, ThinVisor™ or hypervisors) and that are running at the host area or control area to leverage the functionality and code base of mobile operating systems and environments may be allowed. Such operating systems and environments may include, but are not limited to, Java for Android™ environments and Objective C for iOS. These systems and methodologies feature a slim sharing persona that runs a simpler service to which the root zone can delegate work that is easily done there.
The foregoing systems and methodologies essentially move certain components that access hardware, for example, Bluetooth® or global positioning system (GPS) to a special “hidden persona”, and then delegate requests for hardware access from regular personas to that persona. Some such components are “standalone” and do not require any support environment. However, other such components require significant runtime support such as, for example, libraries, services, or other such resources. The special “hidden persona” may include such a runtime environment and, therefore, may leverage existing infrastructure rather than requiring such software to be rewritten to be used in the “hidden persona.”
In another aspect, systems and methodologies are disclosed herein for using a shared persona to provide a read-only persona which may be a duplicate of another private persona. When instantiated, access to data is typically restricted to read-only mode (e.g., via file system mount options), and users will not be able to alter or write to certain states of the persona (e.g., delete photos), but will still be able to access all of the data for viewing purposes.
One advantage of the read-only persona approach is that it does not require collaboration of the applications. If safety-catch functionality for the application was provided, it would be necessary to modify the framework of the mobile operating system (e.g., Android™) and have the service provider adopt the modification, or adjust each and every application to respect the safety-catch. Instead, the use of a dedicated persona works transparently for all applications, without necessitating changes to them. In other words, read-only functionality may be implemented in different ways, including by modifying the operating system (e.g., Android™) framework and ensuring that all applications adapt to this change in order to perform properly. However, such an approach is unreasonable given the large amount of applications already released and the nature of such a framework (which is usually unmodified by most virtualization and separation approaches). By contrast, the present approach avoids the issue and does not require collaboration of an application (or libraries), because it sets the proper staging for the applications—maintaining transparency and compatibility.
It will be appreciated that, technically speaking, the foregoing aspect behaves to make certain portions of the persona read-only. In particular a mobile operating system (e.g., Android™) typically needs and expects a set of writable locations, thereby making it undesirable or infeasible to make the entire persona read-only. Hence, according to various disclosed embodiments, the read-only attribute is assigned only to portions of interest of the persona such as, for example, data directories (e.g., of a photo gallery application or email application), configurations, and settings.
In yet another embodiment, systems and methodologies are disclosed herein for generating dedicated personas for scratch use, after which the personas may be discarded. Such sandbox personas may be instantiated explicitly by user request, or implicitly in response to contextual triggers.
In another aspect, systems and methodologies are disclosed herein for optimizing speed and memory use by using a copy-on-write mechanism in applications. In particular, the first instance of an application maybe started in a dedicated persona. The second instance of the application may reuse the first instance, and so on, as long as the usage remains read-only. When the usage patterns changes in a way that would alter the state of the application, the system will automatically instantiate a private copy of the application inside the user's persona of origin, and all changes will affect this private copy rather than the shared copy.
The foregoing aspects, systems, and methodologies may be implemented, in whole or in part, through the use of suitable software or programming instructions which are recorded in a non-transitory (preferably tangible), computer readable medium. When implemented by a computer, the software or programming instructions may implement these aspects, systems, and methodologies or portions thereof.
As used herein, the term “persona” refers to an execution environment which may comprise a set of user preferences associated with a user identity document (ID), and which govern the operation of an operating system (OS). Multiple personas may be defined, for example, by an information technology (IT) administrator, a policy of the OS or the user in the systems and methodologies defined herein through, for example, the use of a suitable hardware virtualization technique, such as a virtual machine manager (VMM) or “hypervisor”. A hypervisor may be utilized, for example, to allow multiple operating systems to run concurrently on a host device, where it presents a virtual operating platform to the guest operating systems and manages the execution of those operating systems.
There are two main types of hypervisors currently known to the art, namely, Type 1 (or native, bare metal) hypervisors, and Type 2 (or hosted) hypervisors. Type 1 hypervisors run directly on the host's hardware to control the hardware and to manage the guest operating systems. Hence, the guest operating systems run on another level above the hypervisor. Examples of Type 1 hypervisors include Citrix XenServer, VMware ESXi, and Microsoft Hyper-V. Type 2 hypervisors run within a conventional operating system environment as a distinct second software level, with the guest operating systems running at a third level above the hardware. Examples of Type 2 hypervisors include KVM and Virtualbox. As used herein, the term “hypervisor” includes both Type 1 and Type 2 hypervisors.
While the system of U.S. Pat. No. 7,086,008 (Capps et al.) may be suitable for its intended purpose, further improvements are needed with respect to the implementation of multiple persona paradigms on mobile technology platforms.
Some of these needs and improvements are addressed in commonly assigned PCT/US12/62497 (Gonen et al.), entitled “Systems and Method for Implementing Multiple Personas on Mobile Technology Platforms”, which was filed on Oct. 27, 2011, and which is incorporated herein by reference in its entirety. There, various systems and methodologies are described which relate to the user-experience on a mobile device having a user interface with two or more personas that a user interacts with. Principles and mechanisms are disclosed which relate to four fundamental user-experience topics, namely, (a) awareness, (b) notifications, (c) switching, and (d) sharing. However, while these systems and methodologies represent a significant advance in the art, the focus there was on “explicit” user interaction with an operating system or device.
In particular—and though not necessarily limited in this regard—the systems and methodologies disclosed in commonly assigned U.S. Ser. No. 11/282,246 (Gonen et al.) were primarily focused towards situations in which users are explicitly aware of the different personas, and where switching between them involves an explicit action on the part of the user. Likewise, sharing was also explicit in the sense that it required specific mechanisms (which might be somewhat ad-hoc, and which didn't consider sharing of services or states) for each application or data type. Thus, for example, sharing was premised on one mechanism (or set of mechanisms) for the settings of a mobile device, and another mechanism (or set of mechanisms) for alarm applications. However, there is a need in the art for such systems and methodologies which are based on, or which leverage, implicit interactions with the user of the mobile device.
The shortcomings of the existing art may be met with the systems and methodologies and various embodiments disclosed herein. The utilization of implicit interaction in some of these systems and methodologies disclosed herein provides at least two important benefits. First of all, it reduces the awareness burden on users by automating the switch operation between personas depending on context and usage. Secondly, it generalizes the underlying sharing mechanisms by making them more structured and transparent to applications.
Other needs in the art may be met through systems and methodologies and embodiments described herein, including those embodiments that leverage special-purpose personas. Such special-purpose personas may include, but are not limited to: (a) a read-only persona, to allow a sort of “guest mode”; (b) a sandbox persona, to experiment with settings or applications; (c) a sharing persona, to allow robust transparent application sharing; and (d) a shadow persona to allow, for example, a ThinVisor™ to use the Android™ framework. It should be noted that the special purpose personas described herein are broadly applicable to various virtualization/sandbox methodologies implemented on various operating systems. Each of these special-purpose personas is described in greater detail below.
As noted above, the systems and methods disclosed in Gonen et al. were primarily concerned with multiple persona systems in which the user consciously chooses to switch between personas. Such switching may be accomplished, for example, by tapping or swiping the switch icon. However, systems and methodologies are disclosed herein in which switching may take place implicitly, and may depend on the user activity and/or on context. As a non-limiting example, tapping on a specially crafted application icon in the private persona may launch a corresponding application in the work persona. Here, the switch occurs in response to the user's action.
As another non-limiting example, when a user attempts to open a URL (from a browser or any other source) while in one persona, it may be determined if the link matches a pattern and, if so, a new browser may be automatically opened in another persona. Here, the switch depends on the context of user's action, and particularly on the content.
In a further example, an email client may be configured so that it always presents all email accounts from all personas, regardless of the persona the client is currently running in. Then, when the user selects an account to view, a new instance of the email client may be launched in the corresponding persona (see the “cross-persona-account” embodiment described in greater detail below).
To date, other programs exist that have features that are similar in certain respects to some of the systems and methodologies disclosed herein. For example, the Parallels Desktop program for Macintosh® computers is an operating system virtualization program that allows users to run Windows and other operating systems within the Mac OS X. VMWare's FUSION 4™ “unity mode” and Kidaro's embedded “applications-in-vm” offer similar virtualization programs. However, the usage models reflected in these products do not apply to the mobile world, because current mobile technology platforms do not have multiple concurrent windows. Instead, the prevailing approach in such devices is to always present one foreground application to the user.
Furthermore, the foregoing approaches suffer from at least three other drawbacks that are exacerbated on mobile platforms: (a) slow launch times (especially with respect to the first instance of each program); (b) potential inability to access data across virtual machine (VM) barriers when related applications are executed in different VMs; and (c) possible hijacking of file extensions previously associated with an application, wherein such file extensions may become re-associated with an application inside one of the VMs.
As noted above, Gonen et al. was primarily concerned with multiple persona systems in which the user consciously chooses to switch between personas. Consequently, in some disclosed embodiments, sharing of data across personas is not application agnostic, and requires changes to the application and/or the operating system (e.g., the Android™ framework) in order to work properly. These requirements may be avoided in some embodiments through the use of a new model for sharing using a dedicated “sharing persona”. Such a sharing persona may serve as an “associated zone” to host applications and data to be shared, or to host services for partial data sharing. The sharing persona is hidden, and (preferably) the user may not switch to it explicitly.
A primary use of sharing personas is to allow sharing of a single instance of an application (and its data) across multiple associated personas. An example of an application which may be shared among personas is the alarm clock application. Preferably, a shared application always runs inside a sharing persona, regardless of where the application was started. Hence, instead of running shared applications in a user's persona of origin, the system may implicitly auto-switch to the corresponding shared persona for as long as the application is in the foreground. Moreover, the system may keep the look and feel of the persona of origin so that the user need not be mindful of transitions (see “shared application”). The persona of origin is typically the persona which the user was viewing or otherwise accessing upon starting the application.
Another possible use of sharing personas is to allow multiple users to use the same application while allowing each user to keep his or her own data. This feature may be advantageous in that it may allow applications to be used by several users without re-installing (and buying) several instances of the same application. For example, each user of the video game Angry Birds™ Star Wars® may wish to track his or her own scores and progress. Desktops typically accommodate this need through the provision of home directories. However, current operating systems utilized in mobile technology platforms typically feature a single user and a single application onscreen. Consequently, mobile applications may not be aware or prepared for such sharing.
Using a dedicated sharing persona, such applications may be run with only a single instance of the application installed by binding this instance to the specific data contexts (e.g., to the contexts of different users) dynamically and on demand. When the user launches the application, the system will bind the data store to the sharing persona, start the application within the sharing persona, and then switch to the sharing persona. The foregoing is subject to the caveat that mobile applications are typically not designed to run two instances of an application, each with its own data area, concurrently. Therefore, if a second launch of the application occurs without exiting the first one, the system may be adapted to close the first instance of the application and unbind the data, prior to launch of the second instance of the application. This transition preferably occurs in a manner that is transparent to the user such that the user is not typically aware of the change.
Another possible use of sharing personas is to host services for the sharing of application and data of a mobile device. For example, a sharing service may be used as a repository for a device's global settings (i.e., those settings that are explicitly shared between personas). These may include screen brightness, speaker volume, network settings, and the like. With the use of a sharing persona, access to the settings to be shared may be provided via a proxy mechanism in the framework that transparently redirects reads and writes of settings values to the sharing service, rather than using a local database in each persona.
A sharing service may also be utilized as a vehicle to allow applications to partially share data across personas. For example, it is frequently useful to share the contact name associated with a phone number so that, for example, incoming calls are recognized correctly, while other contact details are hidden. The sharing service may operate to expose an application program interface (API), which applications may utilize to publish data to be shared. When publishing data, an application may indicate the data type (e.g., contact information) and the permissions that dictate which personas can access the data (e.g., only managed personas, or all but insecure personas). In this way, an application may decide what data it will publish, and to whom. In particular, application data may first be filtered (e.g., so that only the name of a contact is exposed).
The API may also be utilized as a means for accessing the shared data. To request shared data, an application will preferably tell the server the data type and, if permitted for that persona, will get back the relevant data. Some data may be too large to fit on a device and may need to be fetched from an external source. For example, contact lists of large companies may be too long, and may require a query to the company server-side. Such data will preferably not be shared directly because it is not stored in full on the device and, even if it could be stored, it would be too wasteful to duplicate it.
To accommodate the foregoing situations, the sharing service API may also allow applications to specify a callback handler for their data. When a request is made to the sharing service and the needed data is not found in the service's local store, the service may delegate the request to the application of origin by invoking the callback handler. The application, in response, may locate the data, locally or externally, filter the result if needed, and return the data to the sharing service, wherein the sharing device will reply to the original query.
Another sharing service may be a local synchronization (sync) server that resides on the device (in a sharing persona). Applications (from any persona) that have synchronizable accounts or data, such as a Google™ account, may sync such accounts or data with the local sync server instead of syncing directly with the respective service provider. This approach permits easy and transparent sharing and synchronizing of data managed by an external service between different personas. In particular, data stored in different personas may be auto-synchronized between the personas by leveraging the native sync capabilities of those personas without the need to modify applications or adjust the storage setup.
A dedicated sharing persona may be used to extend a virtualization architecture by hosting components in the user space that access the hardware rather than in a kernel. The software stack (and applications) that access the hardware may run in the sharing persona instead of in each persona. For example, the Bluetooth® protocol may be supported by running the actual Bluetooth® service and logic in a sharing persona while also storing the settings, status, and pairing passwords in that sharing persona. Other personas may obtain the settings and statuses, as well as interact with the hardware, through a proxy that will communicate with this persona.
A dedicated sharing persona may be used to simplify virtualization and management complexity by leveraging the native operating system (e.g., the Android™ operating system) infrastructure in place of developing proprietary components. Thus, such components may be allowed to reside at the “control” area below both personas to use software components and services that already exist in the operating system. This may be accomplished through the use of a service in a slim sharing persona to perform tasks inside the operating system environment (e.g., the Android™ Java environment) for the control area. For example, instead of replicating the SMS decoding logic that already exists in Android™ at the control area, this task may be delegated to the sharing persona that will use the native operating system libraries for that purpose (see “sharing-software”).
One useful capability for owners of mobile technology platforms is to switch the device into read-only mode when allowing friends and family to view some contents, such as one's photos or media. A read-only persona may be implemented as a dedicated persona that is a duplicate of an existing regular persona, but that does not allow alteration of the underlying stored data. The data of the existing regular persona may be bound prior to switching to the persona. Instantiation and switching may be accomplished either with a whole environment or on a per application basis. One advantage of this approach is that applications are not required to collaborate. Thus, such safety-catch functionality must otherwise be tailored in the operating system framework and per application.
It may be further desirable to provide a sandbox persona to run untrusted applications that a user may download from the market for a trial, or as a vehicle through which a user may experiment with different settings and configurations without worrying about restoring the original state. The user may be provided an option (which may take the form of, for example but not limited to, a checkbox or a gesture) to indicate that a subsequent action (e.g., download) requires sandboxing, or to indicate that sandboxing should occur automatically for all downloads (similar to how anti-virus works), wherein sandboxing is using such a sandbox persona to run an application or modify settings. In such an embodiment, upon determining that the user has opted to perform sandboxing, a new sandbox persona is initiated and downloading of an application may begin in the new sandbox persona.
Some applications are “mostly read-only” by nature, such as news or weather reports. Such “mostly read-only” applications may be run in a shared persona to save both disk space and memory, even if the user indicated that the settings should not be shared. When the user starts a “mostly read-only” application, the shared instance in the shared persona may be used by default. However, when a user first changes the application settings or alters the default view, the application may be restarted in the user's persona of origin (e.g., the private persona), and will then switch to that persona in place of the shared one. The result is a copy-on-write (COW) mechanism for applications.
The foregoing systems and methodologies may be further appreciated and embodiments are further described herein below with respect to
The right side of
The left-hand side of
The system 100 includes hardware 101b (e.g., mobile device 123), a ThinVisor™ or hypervisor, user-space sandbox, user-space wrapper or other virtualization layer 101, and a host environment 102. The hypervisor 101 sits on top of a Linux or other kernel (the operating system of the mobile device 123) 101a. It should be noted that this arrangement is particular to the approach of virtualization in the embodiment depicted; more typically, a hypervisor actually sits beneath or instead of the kernel, and a user-space sandbox (a type of virtualization) sits on top of the host environment 102. The host environment 102 serves as the place where the control logic of the ThinVisor™, hypervisor, user-space sandbox, user-space wrapper, or other virtualization layer 101 runs, and may functions as a hardware persona for some services, and as a software persona for other services.
Each persona may also run a Service process (not depicted) that is responsible for communicating with the main Controller (also not depicted) running in the host environment 102. Such main Controller is responsible for proxying and routing messages between personas, and for switching the foreground persona A 103 to, e.g., a background persona. It is to be understood that, as used in the present context, the term, “process” refers to an instance of a computer program that is executed by a processor.
In addition to the base components, there is also a filter 211 that detects and intercepts certain conditions and events or “triggers” 210. When a trigger 210 is received, the filter 211 notifies a first Service process 208 of the foreground persona A 203. In response, the first Service process 208 sends a message 212 to a Controller 207, which forwards a command message 213 to a second Service process 209 of the background persona B 205. The command message 213 includes a request to launch an application or activity corresponding to the trigger. The second Service process 209 in response performs 214 the intended action 215, and the system 200 switches to using and/or displaying the background persona B 205.
The foregoing type of implicit switching is based on an explicit communication. In particular, the switching is based on explicit messages delivered through the Service in stances of personas (e.g., the first Service process 208 and/or the second Service process 209 of persona A 203 and persona B 205, respectively), and is executed by such instances. However, implicit switching may occur by way of an implicit mechanism as well, where messages from one persona (e.g., the foreground persona A 203) are routed (by means of a proxy) to another persona (e.g., the background persona B 205), without the explicit involvement of the first Service process 208 (or instance thereof) or the second Service process 209 (or instance thereof). Thus, some of these interactions may occur directly through the Controller 207 while skipping (that is, occurring without explicit intervention of) the first Service process 208 or the second Service process 209.
Various triggers and applications may be utilized including, but are not limited to, a tap on a user interface, a change in location of the host device, a voice activation, a change in availability of networks, a command from a remote server, and so on.
As a non-limiting example of a trigger, a tap on an inter-persona application shortcut may cause the launch of the application in another persona;
As another non-limiting example of a trigger, a tap on a URL of a certain pattern defined by the IT admin, e.g., in a browser, in a text message, or elsewhere, may launch a browser in the managed persona to open that link;
As yet another non-limiting example of a trigger, a tap on an inter-persona notification in the notification drawer may launch the notification drawer in another persona and display more details on the notification, as if it was inspected there;
As another non-limiting example of a trigger, an external data sensor may cause a switch in personas in response to, for example, the location of the host device, voice activation, availability of networks, a command from a remote server, etc.
The sharing-persona S 307 hosts the applications which are to be shared among the other personas (e.g., applications to be shared among the foreground persona A 303 and/or the background persona B 305). Shared applications, such as shared app 313, may be accessed from any regular persona. Such shared applications are launched like regular applications, from the application-launcher view or from an application shortcut such as, for example, application shortcut 314 associated with the foreground persona A 303 and/or application shortcut 315 associated with the background persona B 305.
When a user, for example, taps 3a the application shortcut 314, it will message 3b a first Service process 309 of the foreground persona A 303, which will forward 3c the message to a Controller 316. The Controller 316 forwards 3d the message further to a second Service process 310 of the sharing persona S 307, which launches 3e the respective application and switch to the sharing persona S 307. It should be noted that the background persona B 305 is configured with a third Service process 311. The third Service process 311 is configured to operate as the second Service process 310 of the sharing persona S 307.
Because the sharing persona S 307 is intended to be shared, it does not present a separate context to the user. Instead, the sharing persona S 307 mimics the look and feel of the persona of origin as it was prior to the switch, and the user is typically unaware of the switch. To do so, the sharing persona S 307 maintains and presents a logical view 312 that is initialized to be the same as the originating persona (e.g., the foreground persona A 303). When the user exits the application (for example, by using the “home” key or the “back” key), it switches back to the persona indicated by the logical view 312.
When the user tries to switch personas or when a switch occurs implicitly by a the system 300 (it is to be understood both here, and elsewhere throughout this document wherever appropriate, that any reference to switching refers to switching which may occur by any of the methodologies described above), the system 300 may be configured to either exit the current shared application (e.g., shared app 313) and then switch to the other persona, or to remain in the current shared application but virtually switch to the other context by adjusting the logical view 312 to reflect the look and feel of the other persona.
Shared applications, such as shared app 413, may be accessed from any persona. They are launched like any applications from the application-launcher view or from an application shortcut such as, for example, application shortcut 414 associated with the foreground persona A 403 and/or application shortcut 415 associated with the background persona B 405. The purpose of a sharing persona S 407 is to share the application (e.g., shared app 413) but not its data (e.g., to save storage, or to avoid double payment). Thus, in this embodiment, sharing persona S 407 does not use its own data; instead, it uses data storage such as, but not limited to, storage 404 and/or storage 406 that belongs to the persona of origin (which may be, e.g., the foreground persona A 403 and/or the background persona B 405).
In the left side of
In the right side of
The sharing persona S 407 also maintains a logical view (not shown). When the user in this context tries to switch personas (or when a switch occurs implicitly), the Controller 409 will treat such view as if the application was launched in the persona being switched to.
The programs that may run in the hidden persona H 507 provide services to applications in the other personas (such as, e.g., the foreground persona A 503 and/or the background persona B 505), such as, but not limited to, data storage for common application settings, common device sharing, common phone calls log, and so on. Applications can request services explicitly or implicitly. An explicit request requires that the application use a suitable API to access the service. An implicit request involves intercepting the application's actions and delegating such actions to the designated service. For example, for applications settings store services, actions such as get/set settings maybe intercepted and forwarded to the respective service program.
Interception is implemented transparently and may be accomplished, for example, using special system hooks such as, for example, system hook 516 for the foreground persona A 503 and system hook 518 for the background persona B 505 to monitor application activity; or to file system hooks such as, for example, file system hook 517 for the foreground persona A 503 and file system hook 519 for the background persona B 505 to monitor file system activity; or by an automatic proxy (not shown) by the underlying messaging component of the system 500. This may be understood with reference, for example, to access to the application settings.
When an application such as, for example, application 513 in the foreground persona A 503 accesses 5a the data, either the system hook 516 or the file system hook 517 may intercept the access and forward the requests 5b(1) and 5b(4), respectively to a first Service process 510 associated with the foreground persona A 503. The first Service process 510 passes the request 5c to a Controller 509, which further passes the request 5d to a second Service process 512 associated with the hidden persona H 507. The second Service process 512 forwards the request 5e to a service program, such as, but not limited to, a data keeper 515, which performs the corresponding access 5f to its local storage 508. The result of the access is returned via the reverse flow path.
Because the round-trip to get/set data from/to the hidden persona H 507 may be non-negligible, each regular persona may additionally have a local cache, such as, for example, local cache 520 of the foreground persona A 503 or local cache 521 of the background persona B 505. The local cache may be configured to store 5b(2) the results of recent queries and use the cached data for subsequent queries, thereby avoiding overhead. The cache may be filled using read-ahead techniques, and its contents may be invalidated by a notification from the hidden persona H 507 (for example, when that data is modified by another persona).
The concept of interception was previously discussed in the context of data sharing, where the use of proxies was noted. Interception may also occur via proxying in the present context. However, in the present context, interception via proxying may not occur through a Service process; instead, it is routed directly to the proper service in the desired persona. If such proxying is involved, then the Service process may not be involved in the persona at the “receiving” side of the transaction.
Each persona 603 and 605 may also have a “filter” component (not shown) attached to a Service process associated with each persona such as, for example, a first Service process 610 associated with the foreground persona A 603, a second Service process 611 associated with the background persona B 605, and a third Service process 612 associated with the partial shared persona 607. Each Service process 610 and/or 611 will inspect the data outgoing from its persona 603 or 605 to a data keeper 615 of the partial sharing service persona 607 and decide which data will be exported and with what credentials. When a persona 603 or 605 requests read or write access to a data tuple, the partial sharing service persona 607 will check the persona's 603 and/or 605 credentials against the data tuple and will grant access only when permitted.
It should be noted that the system 600 includes one storage 604 associated with the foreground persona A 603, one storage 606 associated with the background persona B 605, and a virtual storage 608 associated with the partial sharing persona 607. Each persona 603 and 605 may additionally have a local cache, for example, a local cache 620 of the foreground persona A 603 and a local cache 621 of the background persona B 605. The system 600 further comprises a host environment 602, a Controller 609, and ThinVisor 601. The components of the system 600 are described herein above.
When the application 713 in a foreground persona A 703 accesses 7a local data, it will be intercepted by a system hook 716 or a file system hook 717 of the foreground persona A 703. The access will reach 7b(1) and 7b(4), and a first Service process 710 of the foreground persona A 703 will pass the foreground persona A 7037c to a Controller 709. From there, the foreground persona A 703 is passed 7d to a second Service process 711 on the sharing cloud persona 707. The second Service process 711 will pass 7e the foreground persona A 703 to the program service, e.g. a data keeper 715. The data keeper 715 will look for it locally, and if not found, will attempt to fetch 7h the foreground persona A 703 from a cloud 722. In this case, the sharing cloud persona 707 also keeps 7g a cache.
It should be noted that the system 700 includes one storage 704 associated with the foreground persona A 703, one storage 706 associated with the background persona B 705, and a virtual storage 708 associated with the sharing cloud persona 607. Each persona 703 and 705 may additionally have a local cache such as, for example, a local cache 720 of the foreground persona A 703 and a local cache 721 of the background persona B 705. The system 700 further comprises a host environment 702 and ThinVisor 701.
It should be noted that the foreground persona A 903 is associated with a storage 904, the background persona B905 is associated with a storage 906 and a third Service process 911, and persona H907 is associated with a virtual storage 908. In addition, the system 900 further comprises a host environment 802, and ThinVisor 801 which are as described in the embodiment of
The right portion of
With respect to
With respect to
Thus, for example, in the particular embodiment depicted in
With respect to
For example, the user may choose to launch the application in a personal persona environment 1207b or a business persona environment 1207c having business or personal settings and content associated there with, respectively, or the user may choose to launch the application in a global persona environment 1207a having global content and settings associated with it. The desktop view 1205 is not attached to any particular persona.
With respect to
In some variations of the foregoing embodiment, an application icon of the features application icons 1307 may have different regions defined thereon which correspond to different personas (not shown), the selection of which causes the respective application to be launched in the corresponding persona. For example, an application icon may be split, with an upper half corresponding to a first persona and a lower half corresponding to a second persona (split icon not shown). This split may be manifested at all times, or may be manifested only when a cursor is placed over it. In another embodiment, the split may be manifested when the application icon is clicked a single time, with a second click on one of the regions causing the respective application to be launched in the persona corresponding to that number of clicks.
With respect to
Visual cues 1411a on the application references 1408, such as application reference 1408a, may be utilized to portray the application, its reference type, and the referenced persona. For example, the visual cue may be an indicia, such as a home indicia 1411a which indicates that the application reference corresponds to a personal persona. Preferably, references can only be created on the desktop 1405.
In the embodiment of
In 15c, when the application icon 1507 is dragged to the association toolbar 1511, in 15d, a process is initiated that launches a security screen from which, in some embodiments, the user may be required to enter a password. Upon successful entry of the password, the process generates a shortcut 1503 to the application corresponding to the dragged application icon 1507, as seen in 15e. It should be understood that the shortcut 1503 is associated with the persona indicated in the association toolbar 1511 at the time the process was initiated. The resulting shortcut 1503, which may take the place of the selected application icon 1507, may be marked with a suitable indicia to indicate the persona it is associated with. Marking application icons with suitable indicia is described further herein above with respect to
In some embodiments, a long press and drag to a hot area, either visible, invisible, or outside of the display, may either create a shortcut or switch to the target persona. Subsequently dropping the icon in the hot area of the other persona may create a shortcut to the application in that persona.
If the user selects the “applications” tab 1613 from this menu as depicted in 16c, the “applications” tab 1613 may expand into an applications menu 1615 as depicted in step 16d. From the applications menu 1615, the user may select a persona to associate with the shortcut. In the case depicted, in 16d, the user selects the “Work Persona Apps” menu item 1617, which, in 16e and in 16f, launches the screens from which the user is prompted to enter a password. After entry of the password, in 16g, the user is presented with a menu of applications 1619. In the case depicted, the user selects the “Calendar” tab 1621 from the menu of applications 1619, which generates the application shortcut 1603 as shown in step 16h. The resulting shortcut 1603, which may take the place of the selected application icon, may be marked with a suitable indicia to indicate the persona it is associated with. Marking application icons with suitable indicia is described further herein above with respect to
In 17c, if the user selects the “applications” tab 1713 from the shortcuts menu 1711, the “application” tab 1713 expands into an applications menu 1715. In 17d, from the applications menu 1715, the user may select a persona to associate with the shortcut. In the case depicted, the user selects the “Work Persona Apps” menu item 1717, which launches the screen depicted in 17e from which the user is prompted to enter a password. After entry of the password, in 17f, the user is presented with a menu of applications 1719. In the case depicted, in 17g, the user selects the “Calendar” tab 1721 from the menu of applications 1719, which generates the application shortcut 1703. The resulting shortcut 1703, which preferably (but not necessarily) takes the place of the selected application icon, may be marked with a suitable indicia to indicate the persona it is associated with. Marking application icons with suitable indicia is described further herein above with respect to
In the system 1800 depicted, application distribution is achieved through the use of shared applications. Shared applications are applications that can be used across all personas. A shared application behaves as a single instance application across all personas, meaning that any change of state made to the application in one persona applies instantly to the same application in another persona.
A shared application may have separate content or shared content. When the content is shared, the application content and view is typically identical. When the application content is separate, the view and content of the application is different. By way of example, an Angry Bird™ Star Wars® gaming application may be a shared application with separate content so that each persona may play Angry Birds™ Star Wars® but have a different score and be in a different stage in the game.
An application can be defined as a shared application either during installation or post-installation. A shared application may have shared content or separate content, and these features may be defined during installation or post-installation. Shared applications may or may not have a visual cue 1809 to indicate if they are shared across personas.
In the same manner, un-shared applications may or may not have a visual cue (not shown) to indicate if they are not shared across persona. Shared applications with separate content may or may not have a visual cue (e.g., visual cue 1811) to indicate that the shared application has a separate content. In the same manner, shared applications with shared content may or may not have a visual cue (not shown) to indicate that the shared application has shared content.
With reference to
With respect to
Several modifications and variations are possible with respect to the systems and methodologies described above. While various embodiments been described with respect to their implementation on mobile communications devices, one skilled in the art will appreciate that the disclosed embodiments may also be implemented on various other mobile technology platforms including, but not limited to, book readers (such as Amazon's KINDLE® book reader), displays, and various types of mobile and other computers.
Various types of syncing may be performed in the systems and methodologies disclosed herein. Such syncing may be accomplished by implementing suitable syncing protocols, such as IMAP, CalDav, SyncML, and Microsoft Exchange, and may be performed for various data types, such as contacts, calendar events, emails, files, photos, and the like.
Syncing may occur with one persona acting as a sync server (i.e., a data provider) while the other persona acts as a sync client (i.e., a data consumer). The sync data may be filtered or modified by the syncing server (provider). Preferably, synced data is pulled by the client side from the server side, although it is also possible that the server side will push updates or new data, or revoke the data.
Synced data may be set in a way that, when used in a second persona, such synced data may activate actions in a first persona. For example, if a contact is synced from a first persona to a second persona, selecting to call the contact in the second persona may initiate the call in the first persona. Synced data may also be read-only in the second persona.
It should be understood that any reference to an element herein using a designation such as “first,” “second,” and so forth does not generally limit the quantity or order of those elements. Rather, these designations are generally used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements may be employed there or that the first element must precede the second element in some manner. Also, unless stated otherwise, a set of elements comprises one or more elements. In addition, terminology of the form “at least one of A, B, or C” or “one or more of A, B, or C” or “at least one of the group consisting of A, B, and C” or “at least one of A, B, and C” used in the description or the claims means “A or B or C or any combination of these elements.” For example, this terminology may include A, or B, or C, or A and B, or A and C, or A and B and C, or 2A, or 2B, or 2C, and so on.
The above description of the present invention is illustrative, and is not intended to be limiting. It will thus be appreciated that various additions, substitutions and modifications may be made to the above described embodiments without departing from the scope of the present invention. Accordingly, the scope of the present invention should be construed in reference to the appended claims.
This application is a continuation application of international application No. PCT/IL2013/050153, filed on Feb. 20, 2013, which claims the benefit of U.S. Provisional Application No. 61/602,880, filed on Feb. 24, 2012, the contents of which are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61602880 | Feb 2012 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/IL2013/050153 | Feb 2013 | US |
| Child | 14465184 | US |
