Abstract: In an embodiment, an operating system includes a device manager that is a central repository of device information. Device drivers may communicate with the device manager over respective channels, and may request channel identifiers (Cids) to communicate with resources related to the respective devices. The device manager may provide values for resource access (or handles that the resources may use to access values). In an embodiment, the device drivers do not have the ability to allocate resources for a peripheral device. Accordingly, the security of the system may be increased. Furthermore, the resource allocation may be centrally located, simplifying the process of updating resource allocation when needed. Additionally, the device manager may delay response to requests from a given device driver until its dependencies are clear (e.g., other device drivers and hardware initializations). Thus, startup scripts may be avoided in some embodiments.

Abstract: In an embodiment, a central repository of rights may be implemented, and accessing entities (e.g. clients) and entities for which access is controlled (e.g. files, servers, etc.) may rely on the central repository. The rights may vary on a client-by-client basis. In an embodiment, the rights may be managed as a value that is interpreted by the access-controlled entity. Accordingly, the definition of access rights may vary based on the entity. In an embodiment, visibility to the access rights may be limited. For example, the central repository may provide a handle that is associated with the access rights, but the access rights themselves may not be provided. When an accessing entity attempts to access the access-controlled entity, the handle may be used to identify the access rights. The handle may be presented to the central repository by the access-controlled entity to confirm access rights.

Abstract: In an embodiment, an operating system for a computer system includes a kernel that assigns code sequences to execute on various processors. The kernel itself may execute on a processor as well. Specifically, in one embodiment, the kernel may execute on a processor with a relatively low instructions per clock (IPC) design. At least a portion of other processors in the system may have higher IPC designs, and processors with higher IPC designs may be used to execute some of the code sequences. A given code sequence executing on a processor may queue multiple messages to other code sequences, which the kernel may asynchronously read and schedule the targeted code sequences for execution in response to the messages. Rather than synchronously preparing a message and making a call to send the message, the executing code sequences may continue executing and queuing messages until the code has completed or is in need of a result from one of the messages.

Abstract: In an embodiment, an operating system includes a device manager that is a central repository of device information. Device drivers may communicate with the device manager over respective channels, and may request channel identifiers (Cids) to communicate with resources related to the respective devices. The device manager may provide values for resource access (or handles that the resources may use to access values). In an embodiment, the device drivers do not have the ability to allocate resources for a peripheral device. Accordingly, the security of the system may be increased. Furthermore, the resource allocation may be centrally located, simplifying the process of updating resource allocation when needed. Additionally, the device manager may delay response to requests from a given device driver until its dependencies are clear (e.g., other device drivers and hardware initializations). Thus, startup scripts may be avoided in some embodiments.

Abstract: In an embodiment, an operating system is defined in terms of a set of actors, each of which implements one or more capabilities built into the system. The actors may establish channels between them for communication of messages between the actors. Some actors may interpose between other actors. These other actors may, in some cases, interpose on channels used by the base actor. In some embodiments, some channels may be interposed while others may be monitored by the interposing actor but may still communicate directly with the underlying actor. Some channels may not be affected by the interposition (e.g. the channels may not be interposed or monitored), in an embodiment. Other examples of interposition may include debugging, simulation, and sandboxing.

Abstract: In an embodiment, an operating system includes a device manager that is a central repository of device information. Device drivers may communicate with the device manager over respective channels, and may request channel identifiers (Cids) to communicate with resources related to the respective devices. The device manager may provide values for resource access (or handles that the resources may use to access values). In an embodiment, the device drivers do not have the ability to allocate resources for a peripheral device. Accordingly, the security of the system may be increased. Furthermore, the resource allocation may be centrally located, simplifying the process of updating resource allocation when needed. Additionally, the device manager may delay response to requests from a given device driver until its dependencies are clear (e.g. other device drivers and hardware initializations). Thus, startup scripts may be avoided in some embodiments.

Abstract: In an embodiment, an operating system for a computer system assigns each independently-schedulable code sequence to an activity. An activity may thus be associated with a group of related code sequences, such as threads that communicate with each other (whether or not they are part of the same program). When a code sequence is ready to be scheduled and it is not part of the current activity, it may preempt the current activity if the activity for the code sequence is not enabled and is not masked by the enabled activities. Each activity may define which other activities it masks. A flexible scheduling scheme may be devised based on the mask assignments for each activity.

Abstract: In an embodiment, an operating system for a computer system assigns each independently-schedulable code sequence to an activity. An activity may thus be associated with a group of related code sequences, such as threads that communicate with each other (whether or not they are part of the same program). When a code sequence is ready to be scheduled and it is not part of the current activity, it may preempt the current activity if the activity for the code sequence is not enabled and is not masked by the enabled activities. Each activity may define which other activities it masks. A flexible scheduling scheme may be devised based on the mask assignments for each activity.

Abstract: In an embodiment, an operating system for a computer system is built on a set of capabilities. Each capability includes at least one pointer to a function that implements the capability. One or more actors are defined which use one or more of the capabilities, and which may be connected to other actors for communication through channels. The channels may be created and maintained by a channel actor. In an embodiment, one or more actors may be assembled to create a composed actor. The actors within the composed actor still communicate over the channels defined between the internal actors, but may pass channel identifiers for actors outside the composed actor, so that the actors within the composed actor communicate with the outside actors as if they were one single actor. Arbitrarily complex actors may be formed in this fashion, while still maintaining the stability and safety of the initial actors.

Abstract: In an embodiment, an operating system for a computer system includes a kernel that assigns code sequences to execute on various processors. The kernel itself may execute on a processor as well. Specifically, in one embodiment, the kernel may execute on a processor with a relatively low instructions per clock (IPC) design. At least a portion of other processors in the system may have higher IPC designs, and processors with higher IPC designs may be used to execute some of the code sequences. A given code sequence executing on a processor may queue multiple messages to other code sequences, which the kernel may asynchronously read and schedule the targeted code sequences for execution in response to the messages. Rather than synchronously preparing a message and making a call to send the message, the executing code sequences may continue executing and queuing messages until the code has completed or is in need of a result from one of the messages.

Abstract: In an embodiment, an operating system for a computer system is built on a set of capabilities. Each capability includes at least one pointer to a function that implements the capability. One or more actors are defined which use one or more of the capabilities, and which may be connected to other actors for communication through channels. The channels may be created and maintained by a channel actor. In an embodiment, one or more actors may be assembled to create a composed actor. The actors within the composed actor still communicate over the channels defined between the internal actors, but may pass channel identifiers for actors outside the composed actor, so that the actors within the composed actor communicate with the outside actors as if they were one single actor. Arbitrarily complex actors may be formed in this fashion, while still maintaining the stability and safety of the initial actors.

Abstract: In an embodiment, an operating system is defined in terms of a set of actors, each of which implements one or more capabilities built into the system. The actors may establish channels between them for communication of messages between the actors. Some actors may interpose between other actors. These other actors may, in some cases, interpose on channels used by the base actor. In some embodiments, some channels may be interposed while others may be monitored by the interposing actor but may still communicate directly with the underlying actor. Some channels may not be affected by the interposition (e.g. the channels may not be interposed or monitored), in an embodiment. Other examples of interposition may include debugging, simulation, and sandboxing.

Abstract: In an embodiment, a central repository of rights may be implemented, and accessing entities (e.g. clients) and entities for which access is controlled (e.g. files, servers, etc.) may rely on the central repository. The rights may vary on a client-by-client basis. In an embodiment, the rights may be managed as a value that is interpreted by the access-controlled entity. Accordingly, the definition of access rights may vary based on the entity. In an embodiment, visibility to the access rights may be limited. For example, the central repository may provide a handle that is associated with the access rights, but the access rights themselves may not be provided. When an accessing entity attempts to access the access-controlled entity, the handle may be used to identify the access rights. The handle may be presented to the central repository by the access-controlled entity to confirm access rights.

Abstract: In an embodiment, an operating system includes a device manager that is a central repository of device information. Device drivers may communicate with the device manager over respective channels, and may request channel identifiers (Cids) to communicate with resources related to the respective devices. The device manager may provide values for resource access (or handles that the resources may use to access values). In an embodiment, the device drivers do not have the ability to allocate resources for a peripheral device. Accordingly, the security of the system may be increased. Furthermore, the resource allocation may be centrally located, simplifying the process of updating resource allocation when needed. Additionally, the device manager may delay response to requests from a given device driver until its dependencies are clear (e.g. other device drivers and hardware initializations). Thus, startup scripts may be avoided in some embodiments.

Abstract: Mobile devices enable users to access data and documents in a convenient portable format. The disclosed method and system enables documents to be transferred/moved onto a mobile device for review or reference by making the transfer simple and straight forward so that it is easy for non-technically literate users (e.g. administrative assistant putting documents on their executive's mobile device). From a sender perspective the transfer mechanism can work whether the mobile device is on a local network (relative to the sender) or on a remote network when the sender does not know the actual location of the mobile device.

Abstract: Mobile devices enable users to access data and documents in a convenient portable format. The disclosed method and system enables documents to be transferred/moved onto a mobile device for review or reference by making the transfer simple and straight forward so that it is easy for non-technically literate users (e.g. administrative assistant putting documents on their executive's mobile device). From a sender perspective the transfer mechanism can work whether the mobile device is on a local network (relative to the sender) or on a remote network when the sender does not know the actual location of the mobile device.

Abstract: A stored object may be encrypted with an “object” cryptographic key. The object cryptographic key may be stored in metadata for the object and the metadata for the object may be encrypted using an “internal” cryptographic key associated with a particular encryption domain. The internal cryptographic key may be stored in a filesystem memory block associated with the particular encryption domain. A “domain” cryptographic key may be generated and stored associated with the particular encryption domain. The domain cryptographic key may be used to encrypt the filesystem memory block. Conveniently, below the domain cryptographic key, the filesystem has a unique, totally unknown, internal cryptographic key for actual data encryption.

Abstract: Computer systems with multiple users will typically store various versions of the same software; different versions being required for different platforms and to maintain compatibility with other software applications. These computer files are generally organized in a hierarchical structure to make their location and access easier, but this still results in a very complicated and inefficient system. The invention provides a custom file system which allows each user, node or system, to identify and manage only the files that are pertinent to it. This custom filesystem provides a custom hierarchical structure of files and folders, and links back to the real file locations in the main file system. The custom file system has priority over the main file system, in that a process manager will attempt to address requests on the custom filesystem before trying to place them on the main filesystem.

Abstract: A file management system for use with a computer system is disclosed. The file management system comprises a real filesystem for accessing files stored on a storage medium and a custom filesystem. The custom filesystem comprises a hierarchical arrangement of links to a subset of files of the real filesystem. In operation, the custom filesystem has processing priority over the real filesystem. As such, the custom filesystem processes requests relating to files of the file subset prior to processing, if any, of the requests by the real filesystem.

Abstract: A computer system having a computer, a custom filesystem, and a real filesystem is disclosed. The custom filesystem is comprised of virtual files that may be mapped to a subset of real files of the real filesystem. The custom filesystem may provide an arrangement of the virtual files to a user through the user interface. This limited arrangement may present the virtual files in a hierarchical arrangement that may be easily navigated and customized for a particular computer, group of computers, computer user, or group of computer users. The custom filesystem may maintain its own metafile information for the virtual files.