There is an ever-present need for easing the ability of users to interact with applications, devices, and operating environments; for easing the configuration and management of applications, devices, and operating environments; and for easing the enablement of interoperation between and among applications, devices, and operating environments. The present disclosure addresses the foregoing needs as well as other related needs.
Methods and systems are described for detecting, in an output space having at least one dimension, a first location of a subspace, wherein a first user interface element of a first operating instance of an operable entity is presented, based on the first location, in the subspace location and a user interface element of a second operating instance of an operable entity is presented, based on the first location, in the subspace. The method further includes receiving an indication to change the subspace and changing the subspace to have a second location in the output space, wherein the first user interface element and the second user interface element are each presented, based on the second location, in the changed subspace.
Objects and advantages of the subject matter of the present disclosure will become apparent to those skilled in the art upon reading this description in conjunction with the accompanying drawings, and in which for the subject matter described herein:
Some addressable entities or other types of parts, illustrated in the drawings are identified by numbers with an alphanumeric suffix. An addressable entity or part may be referred to generically in the singular or in the plural by dropping a suffix of the addressable entity's or part's identifier or a portion thereof.
All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety, unless explicitly stated otherwise. In case of conflict, the present disclosure, including definitions, will control.
One or more aspects of the disclosure are described with reference to the drawings, wherein the various structures are not necessarily drawn to scale. In addition, the materials, Figures, and examples are illustrative only and not intended to be limiting. As an option, each of the flow charts, data flow diagrams, system diagrams, hardware diagrams, network diagrams, user interface diagrams, or Figures that depict other types of diagrams may be implemented in the context and details of any of the other diagrams in the foregoing figures unless clearly indicated by the diagrams themselves or in the description below. For purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects of the disclosure. It may be evident, however, to one skilled in the art, that one or more aspects of the disclosure may be practiced with a lesser degree of these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate describing one or more aspects of the disclosure. It is to be understood that other embodiments or aspects may be utilized and structural and functional modifications may be made without departing from the scope of the subject matter disclosed herein.
Although flow charts, pseudo-code, hardware, devices, or systems similar or equivalent to those described herein can be used in the practice or testing of the subject matter described herein, suitable flow charts, pseudo-code, hardware, devices, or systems are described below. Each embodiment, option, or aspect of the subject matter disclosed herein (including any applications incorporated by reference) may or may not incorporate any desired feature from any other embodiment, option, or aspect described herein (including any applications incorporated by reference).
Of course, the various embodiments set forth herein may be implemented utilizing hardware, software, or any desired combination thereof. For that matter, any type of hardware or circuitry may be utilized which is usable for implementing the various functionality set forth herein. It should be noted that, one or more aspects of the various embodiments of the subject matter of the present disclosure may be included in an article of manufacture (e.g. one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code for providing and facilitating the capabilities of the various embodiments. The article of manufacture can be included as a part of a computer system or sold separately.
References in this specification or references in specifications incorporated by reference to an “embodiment”; may mean that aspects, architectures, functions, features, structures, characteristics, etc. of an embodiment that may be described in connection with the embodiment may be included in at least one implementation. Thus, references to an “embodiment” may not necessarily refer to the same embodiment. The aspects etc. may be included in forms other than the embodiment described or illustrated and all such forms may be encompassed within the scope and claims of the present application.
References, in this specification or references in specifications incorporated by reference to “for example”, may mean that aspects, architectures, functions, features, structures, characteristics, etc. described in connection with the embodiment or example may be included in at least one implementation. Thus, references to an “example” may not necessarily refer to the same embodiment, example, etc. The aspects etc. may be included in forms other than the embodiment or example described or illustrated and all such forms may be encompassed within the scope and claims of the present application.
The various embodiments, examples, and portions thereof provided herein relating to improvements to apparatuses and processes (e.g. as shown in the contexts of the figures included in this specification, for example) may be used in various systems, methods, arrangements, applications, contexts, environments, etc. that may not be limited to those described herein. For example, one or more embodiments, examples, and portions thereof described or illustrated in the context of, for example, one or more figures of the present disclosure may be combined with or may be used in combination with one or more other embodiments, examples, and portions thereof described or illustrated in the context of one or more other figures of the present disclosure. Further, one or more embodiments, examples, and portions thereof described or illustrated in the context of, for example, one or more figures of the present disclosure may be combined with one or more embodiments, examples, and portions thereof described or illustrated in the present disclosure or may be combined with one or more embodiments, examples, and portions thereof described or illustrated in any specifications incorporated by reference.
Still yet, the diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the various embodiments of the subject matter. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. These variations are considered a part of the claimed subject matter.
While various embodiments are described below, they have been presented by way of example only, and not limitation. Thus, the breadth and scope of a subject matter of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
Unless otherwise defined herein or alternatively in a definition included by reference, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present disclosure belongs.
Instructions may be executed in a computing context referred to as a “computing process” or simply a “process” A process may include one or more “threads”. A “thread” includes one or more instructions executed by a processor in a computing sub-context of a process. The terms “thread” and “process” may be used interchangeably herein when a process includes only one thread.
In an embodiment, the changed subspace may include both the first location and second location. In an embodiment, the changed subspace may include the second location and not include the first location.
Changing a subspace may include moving a user interface element representing or identifying some or all of the subspace, changing a size of the interface element representing or identifying some or all of the subspace, or changing the shape of the user interface element representing or identifying some or all of the subspace. A boundary of a subspace may not be visible to a user prior to receiving an indication to change the subspace. Changing a subspace may include presenting a user interface element that identifies some or all of the boundary. A boundary may identify a location in a subspace. Moving a subspace may be performed automatically in response to a detecting a change indication. Moving a subspace may include an interaction between a user and a user interface element that represents the subspace. For example, a user may identify a location via a touch or other pointing input device. A subspace may be changed be based on the identified location. A change may include a change in a location, a size, or a shape of a subspace in one or more of dimensions of the subspace or of an output space that includes some or all of the subspace. Any user interface elements in a subspace may be modified so they remain in the subspace as a part of a changing of the subspace or in response to a change to the subspace.
A user interface element may be presented in a two-dimensional output space where a location may be defined via a two-dimensional coordinate space of a coordinate system, such as a Euclidean coordinate system. For example, a coordinate system may be specified where one dimension is specified as a vertical dimension and the other a horizontal dimension. A location in a first dimension, such as a horizontal dimension, may be referenced according to an X-axis and a location in a second dimension (e.g. a vertical dimension) may be referenced according to a Y-axis of a coordinate space. In another aspect, a user interface element may be presented in a three-dimensional output space where a location may be defined utilizing a coordinate space of a coordinate system having a third dimension (e.g. a depth dimension) in addition to a first dimension (e.g. a vertical dimension) and a second dimension (e.g. a horizontal dimension). A location in a depth dimension may be identified according to a Z-axis. A visual output in a two-dimensional presentation may be presented as if a depth dimension existed allowing the visual output to overlie or underlie some or all of another visual output.
A subspace may allow a creation of, removal of, modification of, or interaction via a first user interface element in the subspace where the first user interface element is in a user interface of or otherwise represents a first operating instance. A change to the first user interface element may affect a second user interface element in the subspace where the second user interface element is in a user interface of or otherwise represents a second operating instance. A change to one user interface element in a subspace may affect another user interface element via a rule or policy of the subspace. For example, circuitry may detect a rotation in one or more dimension of a user interface element in a subspace. Circuitry may operate, in response to detecting the rotation, to rotate another user interface element in the subspace where each of the user interface elements represents a different operating instance.
In various embodiments, some or all of a subspace, when included in a visible output space, may be visible to a user at sometimes, at all times that a subspace is in the visible output space, or a subspace may invisible at all times.
A user interface element, of an operating instance, in a subspace may be presented in a visually detectable portion of an output space. The portion may visually represent of some or all of the subspace. The portion is, itself, an output space. The output space that includes the portion may be another subspace that may be visible in a portion of yet another output space.
In an embodiment, a user interface element in a subspace may be in a user interface of an operating instance or may represent the operating instance without being in the user interface of the operating instance. In either case, the user interface element may allow an interaction between a user and the operating instance. Additionally, a subspace may be a resource accessed by or for an operating instance that has a UI element in the subspace. Further, circuitry may be included in a system for subspace that may enable, modify, or prevent access to a resource that is accessed by or for an operating instance having a user interface element in the subspace. A creation, deletion, or modification of a resource, accessed by or for an operating instance having a user interface element in a subspace, may activate circuitry of the subspace or of the operating instance that operates in changing the user interface element. Alternatively or additionally, a creation, deletion, or modification of a resource, accessed by or for an operating instance having a user interface element in a subspace, may activate circuitry of the subspace or of the operating instance that changes the subspace or that changes another operating instance having a user interface element in the subspace. Circuitry of a subspace may create, monitor, modify, delete, or otherwise control an access to the subspace or an attribute of the subspace by or for an operating instance having a user interface element in the subspace.
A subspace may have a size when presented in an output space. The size be smaller than an output space allowing the entire subspace to be included in a portion of the output space. A size of a subspace may be larger in one or more dimensions than an output space allowing only a portion of the subspace to be included in the output space. User interface elements, of operating instances, that are in a subspace may be associated with the subspace via circuitry or via data stored in a memory that directly or indirectly identifies one or more of the user interface elements and that directly or indirectly identifies the subspace.
While
A user interface handler (UI handler) may include circuitry (virtual or physical) that operates in sending information to present an output (e.g. a user interface element) via an output device (e.g. a display). A user interface handler, additionally or alternatively, may include circuitry to process input information that corresponds to a user interface element.
An arrangement of data structures 500, shown in
An arrangement of data structures 600, shown in
An arrangement of data structures 700, shown in
The arrangements of structures described above and elsewhere in the present disclosure are not exhaustive. The structures may be stored in a processor memory via a machine code translation of source code written in a programming language. Data locations or fields in a structure may be stored in contiguous locations in a memory or may be linked via pointers or other types of references including one or executable machine code instructions. The data of the exemplary structures, their analogs, or their equivalents may be stored in a database, such as a SQL database, may be stored as binary data, may be stored as text such as in an XML document, or may be stored as addressable entities (e.g. variables or constants) in a translation of source code that specifies or defines data locations or metadata about the location or data in the locations—to name a few examples.
While subspaces in
Regular geometric shapes other than rectangular shapes may be supported by an embodiment. Exemplary shapes include subspaces that are at least partially circular or cylindrical, triangular, trapezoidal, and so forth. Subspaces may be visible or only partially visible. For example, a subspace may have a menu bar or tool bar that is visible when a specified criterion is met but may be invisible otherwise.
In an embodiment, locations in an output space may be identified via a coordinate space of a coordinate system. The output space and a subspace presented in a portion of the output space may share the same coordinate space or may each have different coordinate spaces of the same or different coordinate system. For example, an output space and a subspace may be addressed by a same coordinate system. An output space and subspace may both, for example, use a coordinate space of a Euclidean coordinate system where the output space has an origin coordinate defined and the subspace has its own origin coordinate allowing the output space and the subspace to use separate coordinate spaces. In an embodiment, an output space and a subspace may share a coordinate space. A choice of coordinate systems or coordinates spaces may allow a developer to make choices that ease a programming task. Further, allowing different coordinate systems or coordinate spaces may ease integration and testing of various applications, processes, tasks, and so forth. To give an example, an operable entity may include code for executing in an operating instance that presents a user interface element in an output space. The code may not include instructions for rotating the user interface element in one or more dimensions, positioning the user interface element with respect to a user interface element of another operating instance, or resizing a user interface element based on an attribute of the output space of the user interface element. Missing features may be added for an operating instance by including a user interface element of the operating instance in a subspace that supports one or more of the unsupported functions. A user interface element in a subspace that includes circuitry for rotating the subspace may automatically rotate the user interface element with the subspace, for example. In addition to providing additional functionality a subspace may constrain a user interface element by constraining one or more resources accessed in presenting or otherwise operating on the user interface element. For example, rather than presenting text using a default font of an operating system desktop output space, a subspace may over-ride the default by providing access to a different font rather allowing access to the system default font.
A coordinate space in a subspace may be oriented in a same direction as a coordinate space of output space that includes some or all of the subspace. Alternatively or additionally, the subspace may be rotated in the output space without affecting a coordinate space of the subspace. For example, a depth dimension in the output space may be a width dimension in the subspace. Such a relationship may be fixed or may be the result of a rotation of the subspace or of the output space that includes the subspace. The output space may be a subspace of yet another output space.
In an embodiment, moving a subspace or a user interface element in an output space may including rotating the subspace or user interface element in one or more dimensions of the output space. Moving a user interface element that is in a subspace may include rotating the user interface element in one or more dimensions of the subspace or rotating the user interface element in one or more dimensions of an output space that includes the subspace. A rotation of a subspace or a rotation of a user interface element in a subspace or in an output space that includes the subspace may be detectable to a user or may not be detectable to a user. A user interface element may be rotated in a subspace without an associated rotation of the subspace. A subspace may be rotated in an output space while a user interface element in the subspace is not rotated. An output space that includes a subspace may be rotated. A subspace in the output space may be rotated in response to a rotating of the output space or the subspace may not be rotated. A user interface element in the subspace may be rotated in response to a rotating of the output space or of the subspace, or the user interface element may not be rotated in response to the rotating of the output space or the rotating of the subspace. A rotation of a subspace in response to a rotation of an output space may differ from the rotation of the output space in a measure of rotation in one or more dimensions of the output space. A rotation of a user interface element in response to a rotation of a subspace that includes the user interface element may differ for the rotation of the subspace in a measure of rotation. A rotation of a user interface element in a subspace in response to a rotation of an output space that includes the subspace may differ from the rotation of the output space in a measure of rotation. A size of a subspace or a size or a user interface element in the subspace may be changed in response to a rotation of an output space that includes the subspace. A size of a user interface element in a subspace may be changed in response to a rotation of the subspace in an output space that includes the subspace.
An indication to move a subspace may be detected via an input directed to or otherwise included in identifying a location where the subspace is to be located via the move. A touch at or near a destination location may be detected. Detecting the indication may include detecting the indication while the subspace has input focus for the input device included in receiving the indication. In an embodiment, an indication to move a subspace may be received in response to a change in an output space that includes some or all of the subspace. For example, a new user interface element or new may be presented, a user interface element or another subspace may be removed, or some other change to a user interface element or another subspace may be or may result in an indication to move a subspace.
In an embodiment, a navigation user interface may be provided to allow a user to select a subspace in a plurality of subspaces for some other purpose, such as to move one or more selected subspaces.
Figures such as
A subspace or a user interface element in a subspace may be identifiable in a navigation user interface element to a user based on an identifier, a task, a role, an operating instance, a resource, a device, an operating environment, a network service, a user, a group, or other attribute of the subspace, a user interface element in the subspace, or an operating instance represented by the user interface element. Each user interface element may be selectable by a selector. An identifier of a subspace, a user interface element in a subspace, or an operating instance represented by a user interface element in a subspace may be included in an identifier space. For example, the identifier may be alphabetic or numeric. An ordering of identifiers may correspond to an ordering of subspaces or user interface elements in one or more dimensions of one or more coordinate spaces. In an embodiment, a selectable user interface element in a navigation user interface element may represent a location in a z-ordering. When the selectable user interface element is selected, user interface elements of operating instances presented in a subspace at the location in the z-ordering identified by the selected user interface element may be identified for moving or for some other operation, such as a close operation identified via an interaction with the user. In an embodiment, when a location in a z-ordering is selected via a selectable user interface element, a sub-navigation user interface element (e.g. a submenu) may be presented if more than one subspace or user interface element is at the selected location. The sub-navigation user interface element may include a selectable user interface element for a subspace or a user interface element at the selected location.
In an embodiment, a first subspace may intersect a second subspace. In an embodiment, a portion of the first subspace may overlay a portion of the second subspace from a user's perspective and a portion of the second subspace may overlay a portion of the first subspace from a user's perspective. See
User interface elements in a subspace or in a different subspace may be slanted or laid across another user interface element, which may create one or more intersections of user interface elements. Selectable user interface elements may be presented for the user interface elements or portions thereof in a manner analogous to that described in the preceding paragraph for performing analogous operations on subspaces.
In an embodiment, circuitry may operate in moving a subspace from a first location in an output space to a second location. An attribute of the moved subspace or an attribute of the other subspace in the output space may be changed in response to the moving. Similarly, an attribute of a user interface element in the subspace or a user interface element in the other subspace may be changed in response to the move. Exemplary attributes a visibility setting, a font setting, an input focus setting, an output focus setting, a color setting, or an operating state setting—to name some examples. Each of the setting may be stored in or accessed from a corresponding location in a memory. An attribute is a type of resource.
An attribute of a subspace, a user interface element in the subspace, or of an operating instance with a user interface element in the subspace may be changed by an operation performed in response to selecting a subspace, a user interface element in a subspace, or an operating instance. An operation may change an input focus setting, an output focus setting, a visibility attribute, a size attribute, a transparency attribute, or other attribute of a subspace, a user interface element, or an operating instance.
In an embodiment, zero, one, or more operating instances may each have a user interface element in one or more subspaces. One or more of operating instances may each be represented via a selectable user interface element in a navigation user interface element. Alternatively or additionally, one or more user interface elements in a subspace or otherwise in an output space that includes some or all of the subspace may be represented by a selectable user interface element accessed via a navigation user interface element. In an embodiment, a subspace navigation user interface element may enable or ease navigation between or among UIs elements of operating instances of a subspace or between or among subspaces. This may be useful for an output space with many user interfaces elements or subspace. Virtually reality output spaces and e-spaces, for example, may include many user interface elements or many subspaces of associated user interface elements. An augmented reality space may include many physical objects from the real world. Some or all may be associated with one or more user interface elements in or not in a subspace presented via an output device. Due to their association, one or more attributes of a user interface element may change in response to a change in an attribute of one of a physical object, a change in another user interface elements in the output space, or a change in a subspace of the output space. A subspace may be used to locate user interface elements with respect to a location of a physical object. For example, virtual books may move or change as a bookcase, a desk, or table changes. Virtual décor may change as lighting in a room changes. The room may include an e-space where user interface elements included in the virtual décor are presented. Associated user interface elements may be monitored and modified via being in a subspace. Items of virtual décor may be presented via a user interface element in a respective subspace. Décor items that are related such as a vase and a picture that are to be place together may be associated via a subspace.
Navigation in an output space or subspace may be based on identifiers that correspond to respective subspaces or other user interface elements. Navigation, alternatively or additionally, may be via or otherwise based on a device of a user interface element or device of a subspace in an output space or in another subspace. Alternatively or additionally, navigation maybe via or otherwise based on a task, a role of a user of one or more user interface elements in an output space or subspace, a remote service such as a web site or a cloud computing environment, a resource accessed by or for circuitry that presents a user interface element of an operating instance. Navigation may be via or based on textual, audio, numeric, or image based identifiers. A navigation control or a specified interaction, such as a swipe or other gesture, may be included in identifying a location in one or more dimensions of an output space or a subspace. A location may identify a subspace or a user interface element at the location or within a specified distance of the location.
In an embodiment, a control user interface element similar or functionally analogous to navigation user interface element 1350 in
As also described elsewhere in the present disclosure, a subspace may be visible to a user or may be invisible.
A subspace may be made visible or invisible in some embodiments. For example, resizing a subspace may be enabled by presenting a boundary of the subspace and interacting with the user via the presented boundary to receive input for a resizing operation. One or more user interface elements may be presented for interacting with the subspace. A subspace may include a navigation user interface analogous to navigation user interface elements described with respect to
As those skilled in the art will understand based on the present disclosure, a subspace may define part of an operating environment for operating instances with user interface elements in the subspace. Operating instances when interoperating with their user interface elements in the subspace access one or more resources of the subspace. A resource of the subspace may be accessible via an operating environment that includes one or more of the operating instances. When in the subspace, an access to the resource may be altered or another resource may be substituted by the subspace for the resource of the operating environment. Alternatively or additionally, access to a resource may be constrained according to data or circuitry of a subspace when accessed by or for circuitry of an operating instance. A subspace constrains presentation of user interface elements of operating instances to a portion of an output space that includes the subspace. The subspace may replace the output space accessible in the operating environment when an operating instance operates unconstrained by the subspace.
An operating instance in an operating environment may access resources directly or indirectly during operation. The operating environment may provide access to some or all of the resources. As illustrated by the description of subspaces above, a subspace may include data or circuitry that may modify access to one or more of their resources accessed by an operating instance represented by a user interface element in the subspace. A subspace may provide a substitute resource, may provide a resource not accessible to the operating instance from the operating environment when not operating in the context of the subspace, or may modify access to the resource for the operating instance when operating in the context of the subspace as compared to access to the resource when operating in the operating environment and not in the context of the subspace. More generally, access to one or more resources accessed by or for one or more operating instance may be modified for the one or more resources when the set of operating instances operates in a specified context referred to herein as an “access context”. Access to a resource may be modified by emulating an interface, by specify a pointcut to identify one or more joinpoints where circuitry of associated advice may operate before, during, or after an access. The terms “pointcut”, “jointpoint”, and “advice” are defined as those skilled in the art of aspect orient programming define these terms. For a description of aspect-oriented object code and machine codes see, by the present inventor, U.S. patent application Ser. No. 12/055,550, titled “Method and Systems for Invoking an Advice Operation Associated with a Joinpoint”, filed on Mar. 26, 2008. In an embodiment, an access context may modify machine code of an operating instance (e.g. via linker or loader rewriting) to invoke access modifying instructions. For example, an interrupt instruction may be inserted in machine code of an operating instance before, during, or after code included in access a resource. Interrupt circuitry may include one or more instructions that may replace accessed data, change a behavior of an accessed set of instructions, and the like. For an access via a network, a proxy may be included in access to a network resource to modify an access. The foregoing are merely exemplary.
A subspace may be an embodiment of an access context or may represent or identify an access context. As described above with respect to subspaces, an embodiment of an access context may include structured data that identifies the access context, that associates one or more resources with the access context or is configured to allow one or more resources to be associated with the access context, and that associates one or more operating instances with the access context or is configured to allow one or more operating instances to be associated with the access context. Alternatively or additionally, an embodiment of an access context may include operating of circuitry (physical or virtual) that operates in enabling, modifying, or preventing access to a resource, in a context set of access context, by or for an operating instance. The one or more resources are referred to herein as a context set of the access context. The operating instance is referred to herein as a member of the access context. A resource in a context set of an access context is referred to herein as a context resource of the access context and may also be referred to as a context resource accessed by or for a member when the resource is accessed by or for the member.
An access context creates, modifies, or prevents a relationship between a resource in a context set of the access context and an operating instance that is a member of the access context. The relationship differs from a corresponding relationship between the same or an alternative resource and the operating instance when accessed via the operating environment when not a member. A set of members of an access context may include zero or more operating instances of zero of more operable entities at some time. In an embodiment, a set of members of an access context may change over time. One or more members of an access context may be pre-specified and may also be static (i.e. unchangeable). In an embodiment, a member of an access context may be specified based on one or more operable entities. For example, an operable entity may be associated with an access context so that an operating instance of the associated operable entity operates as a member of the access context. An access context may have one or more operating instances of a same operable entity. An additional criterion may be specified for an access context so that only operating instances of a specified operable entity that meet the additional criterion operate as members of the access context. An operating instance may be a member of more than one access context. An operable entity may have an operating instance that is a member of a first access context and a second operating instance that is a member of a second access context.
A first resource and a second resource may be accessed by or for an operating instance of an operable entity. In an embodiment, a first operating instance, of the operable entity, may be a member of a first access context in an operating environment. The first access context may include the first resource or a substitute for the first resource in a first context set of the first access context. The first context set, in an embodiment, does not include the second resource or a substitute for the second resource. The second resource may be accessed by or for the first operating instance via the operating environment as it would be if the first operating instance was not a member of the first access context. The first resource or the substitute for the first resource is accessed by or for the first operating instance via or based on the first access context. The access of the first resource or the substitute is different than if the first operating instance was not a member of the first access context. The first context may be said to provide a modified operating environment, an overlay environment or layer on top of the operating environment, a partial operating environment, an augmented environment, or a plugin environment. In an embodiment, the first resource may not be accessible via the operating environment by an operating instance not included in the first context. An access context may provide access to one or more resources that are not accessible by an operating environment that includes or is combined with the access context.
In an embodiment, a second operating instance, of the operable entity, may not be a member of a first access context in the operating environment. The first resource and the second resource may be accessed by or for the second operating instance via the operating environment unconstrained or not modified by or based on the first context. Alternatively or additionally, an access context may prevent access to a resource by or for a member operating instance that would be accessible to the operating instance when not a member. Still further, an access context may constrain or change access to a resource accessible without the change or with a different constraint when accessed in the operating environment. An access context may alter an accessed resource, substitute another resource, or may alter access to a resource by or for a member of the access context. A access may be modified by a change in a security attribute, a change in memory location for accessing a resource or a substitute, transforming an input or an output of an access, changing a format or schema of a stored or access resource, changing an address via which a resource is accessed, changing or otherwise constraining a time of access, a duration of an access, a user included in an access, a provider of a resource, a network resource included in accessing a resource via a network or other data exchange medium, a speed of access (e.g. accessing via slower hardware), a rate of a repeated access, or a count of other operating instances that may access a resource at a same time or sequentially—to name a few examples.
In an embodiment, an access context may alter no resource not in the context set nor alter access to a resource not included in the context set of the access context. An access context may change some or all of an operating environment for an operating instance member depending on the resources in the context set. When an access context modifies a portion of resources or modifies access to a portion of resources accessible otherwise in an operating environment for an operating instance member, a “partial operating environment” for the member is realized via the access context.
A subspace may be an “access context”. Operating instances with user interface elements in a portion of an output space specified by the subspace may be members and resources of the subspaces or accessed via or based on the subspace may define a context set. Alternatively or additionally, an access context may have a context set that includes a subspace as a resource accessible by or for a member of the access context. A context set of an access context may include more than one subspace.
An access context may modify a resource, substitute a resource, or modify access to a resource by replacing a default setting of an operating environment for a member operating instance; by replacing a default setting of an operable entity for an operating instance that is a member of the access context; by altering or replacing an addressable entity accessed by, accessed for, or included in a member operating instance; by specifying a security constraint for a resource access by or for a member; by specifying a resource to access by or for a member when an operating environment provides multiple suitable resource (e.g. an access context may include a subset of processors in its context set accessible to a member of a set of processors otherwise accessible by or for an operating instance not in the access context); by changing a constant setting accessible via an operating environment to a variable setting settable via one or more mechanisms by or for a member; by constraining a number of times a resource may be accessed by or for a member or a set of members of an access context; by constraining a time or duration of access to a resource by or for a member; by modifying a source of resource such a default file system or an environment path accessed by or for a member; by specifying minimum number of accesses or resources accessed by or for a member or a set of members; by changing a default application for accessing a resource for a member; or by changing or constraining access to one or more network nodes or other network resources by or a member. Other types of changes, substitutions, and constraints are described elsewhere in the present disclosure. In an embodiment, an operating instance of an operable entity may have access to resource or type of resource only when the operating instance is a member an access context having a context set that includes the resource or type of resource. Some operable entities may have operating instances that perform an operation only in the context of one or more access contexts or types of access contexts. Note that one or more of a device, a process, an operating environment, another access context, or a thread may be resource in a context set of an access context. Access contexts may be configured to specify and manage access to resources in cloud computing systems and other types of distributed or network based systems such as client-server systems.
As used herein, the term “addressable entity” may refer to any entity specified in source code written in a programming language. Examples of addressable entities include variables, constants, structures, functions, methods, methods of an object, and scoped code blocks—to name a few examples.
An access context may affect access by or for a member to a resource accessed in exchanging data via a network, accessed in storing or retrieving data from a memory device, accessed in executing an instruction, accessed in interacting with a user, and the like. Examples of resources accessed in exchanging data via a network include a network interface, a network, a protocol endpoint, or other network entity whether physical or virtual.
A context set may be an identifier of an access context or may identify a type of access context. An access context may be assigned an identifier such as a name, a number, an image, a character string, or an identifier from any identifier space selected for an embodiment by a developer, user, administrator, or other authority. Identifiers are resources in and of themselves and may be included in a context set for an access context. Other resources that may be included in a context set of an access context include hard drives, file systems, files, operating environments, security roles, processors, or metadata for any or all of the foregoing.
In an embodiment, a change to a context resource may include one or both of a change to an access context that has a context set that includes the context resource and a change to a context resource accessed by or for a member. Further, a member may change a context resource, thus changing the access context. The changed context resource may change a subsequent member's operating as a result. With respect to an access context that has a context set that includes a subspace. A change to a user interface element, in the subspace, of a member may change the subspace as described elsewhere in the present disclosure.
In an embodiment, an operable entity may be member of one or more access contexts at a time. An embodiment may restrict an operable entity from being a member of more than one access context. An operating instance may be removed as a member of a first access context in response to determining that the operating instance is to be or has been added as a member of a second access context. An operating instance, of an operable entity, may be added as a member of a first access context in response to determining that the operating instance, of the operable entity, is to be or has been removed as member of a second access context. An adding or removing operation may be performed automatically in an embodiment. An adding or removing may include interaction with a user in an embodiment.
In an embodiment, an operating instance, of an operable entity, may be a member of an access context during a portion of the operating of the operating instance. Prior to the portion, the operating instance may not be member and may be added to as a member of the access context for the portion. Subsequent to the portion, the operating instance may be removed from the access context. The operable entity, in an embodiment, may be associated with the access context to identify some or all operating instances of the operable entity as members in response to associating the operable entity with the access context. In an embodiment, an operating instance may be a member of an access context during an access by or for the operating instance to a resource in a context set of the access context. Membership of an operating instance in one or more access contexts may change based on detecting a resource to be accessed, a resource being accessed, or based on a prior access to a resource. A membership change may be based on detecting that a resource is in a context set of an identifiable access context or detecting that a resource is not in a context set of an identifiable access context or otherwise is not configured for access in any access context. Prior to an access to a resource, an operating instance may not be member and may be added to as a member of an access context during or prior to an accessing of the resource by or for the operating instance. Subsequent to the accessing, the operating instance may be removed as a member from the access context.
A criterion, for adding or removing an operating instance respectively to or from an access context, may be based on the operating instance, another operating instance, an operable entity, a resource accessed by or for an operating instance, an access context, or a user interaction with the operating instance or with another operating instance—to name some examples. For example, a maximum number of members that meet a specified criterion may be defined for an access context. When the maximum has not been met, an operating instance that meets the specified criterion may be added as a member to the access context. When the maximum has been met, an operating instance that meets the specified criterion may not be added as a member of the access context. For example, an access context may be specified for an operating instance that executes circuitry that embodies a communications agent, such as an instant messaging client. In response to adding the communications agent operating instance to the access context, an adding of an operating instance of an address book may be allowed and an adding of an operating instance of an image capture device may be added as a member (e.g. to capture and attach a digital image to a text message). The member set of the access context may be specified to allow multiple operating instances of address book application(s) while allowing a maximum of one image capture device at any time to the member set. The operating instances in the member set may exchange information via one or more context resources (e.g. a virtual network) of the access context. That is, data exchange between or among the operating instances may be enabled in response to or based on being members of an access context. An operating instance when not in the access context may be unable to exchange information or may exchange data differently.
As described, access contexts may be used to change operating environments, of an operating instance or a group of operating instances, dynamically in response to network resource utilization, storage resource utilization, processor utilization, memory utilization, or based on change in attributes of operating instances or groups of operating instances such as a count of operating instances that access a resource, a source of a group of operating such as a high priority client or an untrusted source, performance or other quality of service requirements of an operating instance or a group of operating instance—to name some examples.
In the embodiment of
In an embodiment, a resource may be included in one or more context sets of one or more respective access contexts at a time. Each access context may modify the resource or access to the resource differently. An embodiment may restrict a resource from being included in more than one context set. A resource may be removed from a first context set in response to determining that the resource is to be or has been included in a second context set. A resource may be included in first context set in response to determining that the resource is to be or has been added to second context set. An adding or removing operation may be performed automatically in an embodiment. An adding or removing may include interaction with a user in an embodiment.
An access context may be prespecified and not changeable by a user. An operating instance, of an operable entity, may be identified as a member prior to its existence by associating the operable entity and the access context. Adding or removing of members may be automatic or may include user interaction. An access context may be modifiable by a user. An access context may be created by or in response to a user interaction. A context set may include multiple resources which may be of a same type or may be different types of resources. A context set may include a single resource. For example, an access context may be defined with a context set that includes a specified data base, a specified data base connection, a specified role via which the database is accessible to a member of the access context, or a specified geospatial location of a member of the access context from which the database may be accessed by or for an the member.
In an embodiment of
Resources others than processors may be managed via an access contexts as well. Members of an access context may be managed to manage access to any resource in the context set of the access context according to the data and circuitry of an access context which implement one or more rules, constraints or policies. For example, a processor in a context set of an access context may be accessed only by members of the access context. Control of the member set may be utilized to control any number of processor resources such as time of use, temperature, power utilization, and so on. An access context may also include rules for sharing a resource between or among the members of the access context. Those skilled in the art will see, based on the present disclosures, that access contexts may be utilized to monitor, manage, or configure resources. Alternatively or additionally, those skilled in the art will see, based on the present disclosure, that access contexts may be utilized to monitor, manage, or configure operating instances of operable entities by controlling membership in one or more access contexts. Further still, those skilled in the art will see, based on the present disclosure, that access contexts may be utilized to monitor, manage, or configure a system which may include one or processes, applications, devices, operating environments which may be or may include one or more virtual operating environments, networks, or systems distributed across a network. Access contexts allow an operating environment to provide multiple overlapping customized operating environments for operating instances operating in the same operating environment. Further, an access context may provide a mechanism for combining some or all of multiple operating environment into a single environment or partial environment by including resources of different operating environments in a same context set of an access context.
A resource may be added or removed from a context set automatically in an embodiment. In some embodiments, a user interaction may be included in determining whether to add a resource to a context set or whether to remove a resource from a context set. For example, a resource of an application or a resource provided by an application may be added to a context set of an access context by moving a user interface element of the application to a location in an output space that is included in a subspace that represents the access context. Circuitry of the access context may be generated from source code written in a programming language to detect and add files of a specified type, stored in a specified location, and so forth to the context set of an access context. An operating instance of an application may or may not be added to an access context as a member depending an a membership criterion of the access context. In an embodiment, a file may be added as a resource to a context set of an access context. Once the file is added to the context set, the access context may monitor the file for one or more specified events or conditions, may control access to the file, may control a location of the file in a data store, may control data stored in or read from the file, or may control any number of other resources of the file or operations performed on or with the file.
An access context may be included in exchanging data between or among operating instances. An exchange may be via a network, via physical link, via an interprocess communication mechanism, via a shared resource, via direct access such as via a function call of one operating instance by another. An exemplary system may include a first node, a second node, and a network. The circuitry may operate in detecting a performing of an operation included in exchanging data via a data transfer medium, such as the network of the exemplary system. The circuitry may operate in determining that a member of an access context is included in the exchanging. The circuitry may operate in identifying a constraint of the access context specified for the exchanging. The circuitry may operate in executing an instruction included in constraining the exchanging based on the constraint of the access context. A context set may include a shared data space, a pipe, a bus, a software interface, or other mechanism that allows (e.g. defines a constraint for) a member of the access context to exchange information with another member of the access context or which may be in another node or to exchange information with an operating instance that is not a member of the access context. A member of an access context may exchange data, per the access context, with an operating instance that is not a member of the access context, in an embodiment.
In an embodiment, circuitry in system or interoperating with a system may operate in identifying an access context. The access context may have a constraint that is specified for constraining a member where the member is included in an exchanging of data between a first operating instance and a second operating instance. In an embodiment, the member includes the first operating instance operating in the first node and the second operating instance operates in a second node communicatively coupled to the same network as the first node. In another embodiment, the member may not include the first operating instance or the second operating instance. The circuitry may, also, operate in executing, in response to the detection, an instruction included in constraining the exchanging by constraining the operating per the specified constraint. In an embodiment, the exchanging may be constrained to a network protocol, a network path, a network interface, or the like based on one or more resources in the context set of the access context or based on circuitry included in the embodiment of the access context which may include circuitry included in the embodiment of the context set.
Other examples of resources that may be included in a context set of an access context include one or more of a network interface, a network protocol endpoint, circuitry included in an embodiment of a network protocol layer in a network stack, a network address space of a network protocol, a network address that may identify a network protocol endpoint, a memory buffer for storing data to transmit or receive via the network, a network path, a hop, a link included in a hop, or a network relay—to name some examples.
In an embodiment in a cloud operating environment, a scheduler may receive task information identifying a first task. The first task may be included in processing a request from a user or client of a network service. The network service may be provided in whole or in part via an cloud operating environment. The client may be associated with a one or more quality of service parameters based on one or more attributes of the client, such as client account size or based on a contractual obligation. A scheduler for the task may be a member an access context having a context set that includes resources suitable for meeting the requirements of the client. A resource may be included, excluded, added as needed, removed, or modified based on one or more criteria such as a measure of utilization, a measure of performance, a measure of security, or a measure of reliability. A second task for a different client may be sent to a scheduler operating as a member of different access context or not operating as a member of any access context. A task may be provided to a scheduler operating as a member of an access context or operating. Alternatively or additionally, a scheduler with a task to assign may be added to an access context or may be removed from an access context. A scheduler for a task may be selected, a scheduler may be added as a member of an access context, a scheduler may be removed as a member of an access context, or an access context of a scheduler may be modified based on an indicator of trust (e.g. of a requesting client) associated with a task, based on a type of task (e.g. a search, a data exchange via a network, a payment, and so forth), based on an measure of data processed in performing a task, based on a cost or other financial measure associated with a task, based on an attribute of physical object identified in a task (e.g. a dimension or a weight), a geospatial location of an object associated with the task, or based on a stage of workflow in which a task may be included or shipping weight) of a transaction, access context based on stage in a transaction or other workflow (e.g. browsing, adding to an online cart, paying, shipping, return, etc.). The foregoing list is not intended to be exhaustive.
An operating instance may be a member of an access context based on a task that the operating is included in performing. The operating instance may be assigned before the operating instance. The operating instance, per the context set of the access context, may be assigned to an operating environment in which the operating instance may be created to perform the task. In an embodiment, a first portion of an operating instance may be in an access context in a first operating environment. A second portion of the operating instance may be in a second operating environment identified via context set of the access context. The task may be assigned to the second operating environment per the context set, at least a portion of the task is performed by the second portion. The first portion may be constrained by the access context to invoking the second portion in the second operating environment. In an embodiment, an access context for a task may be created so the task may be assigned to the access context to be performed per a constraint of the access context. Alternatively or additionally, an access context may be modified as part of assigning a task or other operating instance to the access context. Alternatively or additionally, an access context may be modified in response to adding a task or other operating instance as a member of the access context. For example, a task assigned may be assigned to an operating environment that may be modified (e.g. by another access context) to may be performed based on a user or client that requested the task. In another example, an access context that matches one or more security criteria configured by or for the client may exist, may be created, an existing access context may be modified per the needs of particular data that is processed in a performing of the task.
An access context in a cloud computing environment may be utilized in allocating cloud, in sharing resources, in prioritizing access to a resource, in managing resource utilization, in managing energy utilization or production, in managing security, in geographic distribution of task performance, or in assembling operating instances and other resources for a specified purpose or type of task. Access contexts may be utilized to customize task assignment based on cloud operating environment customers, client devices, or task types—to name some examples.
A context set of an access context may identify an energy source, an energy generator, an energy converter, an energy transformer, and the like to control an amount, a rate, a quality measure, a type, or a source of energy to operate in or to affect an access to energy by a member of the access context. Further, a context set may include a time, a duration, or other criterion for determining when any of the forgoing resources may be accessed for or by a member of the access context. In an embodiment, an operating instance may be allowed to access power only from an electricity grid external to a system of the operating instance, an operating instance may be allowed to access power from a battery in a system of the operating instance when a duration of available power accessible from the battery exceeds a specified threshold, an operating instance may be allowed to access power from a battery in a system of the operating instance when a temperature of a battery is behold a specified temperature, an operating instance may be allowed to access power from a specified source when an amount of power accessible via an electricity transmission medium meets a criterion based on one or more attributes of electrical energy such as amps, volts, etc.; an operating instance may be allowed to access power or a specified amount of power when a measure of waste heat is emitted below a specified rate where the waste heat is emitted by hardware in the operating instance or that is accessed by or for the operating instance. In another embodiment, an access context may allow power to be accessed by or for a first operating instance while power is accessed by or for a second operating instance or in response to an accessing of power by or for the second operating instance.
For example, a media streaming device (i.e. a first operating instance) and a media presentation device (i.e. a second operating instance) may be placed in an access context so that when one receives power the other receives power.
In an embodiment, when scheduler circuitry 3112 determines that a duration of operation of the processor 3102 is to be assigned to an identified operating instance, access context circuitry 3114 may receive data, based on the determination, that identifies the operating instance. Access context circuitry may determine whether the operating instance is a member of one or more access contexts or not. If an operating instance is a member of an access context, one or more constraints of the access context may be applied. In
Electrical energy received or utilized by the processor 3102 may be modified by changing a processor resource. In an embodiment, an amount of power received or utilized by a processor 3102 may be increased or decreased by the power control circuitry 3108 interoperating with the processor clock rate circuitry 3110 to, respectively, increase or decrease the clock rate of the processor 3102. In an embodiment, a power mode resource of the processor may be modified. In an embodiment, a resource or operation of the power source or of an electricity conducting medium may be modified by changing one or more processor resources. Slowing the clock rate of the processor 3102 may change an amount of power accessed by the processor 3102. In response, the power source 3104 may change a rate at which the power source 3104 receives non-electrical energy to be converted to electrical energy. Alternatively or additionally, a power source that generates excess electrical energy as a result of a constraint on a processor resource may transfer electrical energy to be stored for later use. A battery in the system or external to the system may store the energy in various embodiments.
A system may include specified default data, default circuitry, or default hardware that is accessible to an operating instance in the system. An access context may modify access to the default, substitute a different resource than the default, or prevent access to the default for any compatible resource with respect to the operating instance.
Augmented reality output spaces are described above. A physical object external to a system may be accessible as a resource of the system (such as a device or an arrangement of devices). Alternatively or additionally, a system may interoperate with a physical object not included in the system.
For example, a measure of light emitted or received by some or all of a physical object may change. In response, a visible attribute of a user interface element representing the physical object may be changed. Alternatively or additionally, a location of a resource in a system that corresponds to the physical object may be changed. (e.g. the resource may be moved from a first memory location to a second memory location). In response, a signal may be sent by the system to the physical object to move the physical object or may be sent to a device or a uses that operates to move the physical object. Alternatively or additionally, a surface of a physical object may change so that it is accessible to a system for presenting a user interface element. In response, the system may present the user interface element on or via the surface. A surface may an opaque surface, a mirror, a lens, or may be at least partially transparent such as a window.
In an embodiment, a physical object may represent itself in an e-space of a system. The physical object may represent itself in addition to or instead of being represented by a resource of the system.
A physical object 3404 may be detected via various mechanisms. System 3400 illustrates several such mechanisms. Sensor hardware 3406 may include an optical sensor such as a visible light camera. Alternatively or additionally, sensor hardware 3406 may include an infrared camera. Each camera may be capable of detecting a form of energy in the electromagnetic spectrum. Alternatively or additionally, sensor hardware 3406 may detect x-rays, microwaves, or other types of electromagnetic energy. Sensor hardware 3406, in an embodiment, may be included to detect thermal energy other than infrared energy. For example, sensor hardware 3406 may include a thermometer. Sensor hardware 3406 may include thermal conducting material to transfer heat to a heat sensor. Still further, sensor hardware 3406 may include a motion detecting device. A motion detecting device may detect velocity or acceleration as part of detecting motion. Those skilled in the art will understand that many other types of sensors, passive or active, exist and will be created that will be suitable for including in a system to detect a physical object. Sensor hardware 3406 may include sensor circuitry 3408 as shown. Note that transceiver hardware 3410 may operate as a sensor for detecting a physical object in an embodiment. Alternatively or additionally, a system 3402 may include circuitry that receives sensor data to transform to a form, such as a digital signal or an analog signal, suitable for providing to one or more other components of the system 3402 as input.
Monitor circuitry 3420 may further identify a resource of the system or a resource accessible, directly or indirectly, to the system and that is or may be associated with the physical object 3404. In an embodiment, the resource may identify, represent, or correspond with the physical object 3404 or a part of the physical object 3404. In
In system 3402, a change to the physical object 3404 may be detected via a sensor (see sensor hardware 3406 and sensor circuitry 3408), via an exchange of data between the physical object 3404 and the system 3402 (e.g. via transceiver hardware 3410 and signaling circuitry 3412, via sensor hardware 3406 and sensor circuitry 3408, or via a user interacting with the system 3402 and the physical object 3404). A change to a resource that corresponds to the physical object 3404 may be detected via change circuitry that accesses the corresponding resource, directly or indirectly. Change circuitry may be realized in numerous forms. In an embodiment, change circuitry 3422 may include a data exchange medium such as a bus, a network cable, a wireless medium, and so forth. A change to hardware resource 3414 may, in an embodiment, result in a signal sent from the hardware resource 3414 to monitor circuitry 3420. In an embodiment, change circuitry 3422, may include virtual circuitry of a subscriber to an event source. Hardware resource 3414 may include circuitry that publishes events in response to a change in some or all of hardware resource 3414. In an embodiment, change circuitry 3422, may include virtual circuitry that requests data from hardware resource 3414 to detect a change. In an embodiment, change circuitry 3422, may be included in or may interoperate with a sensor that detects a physical attribute of a hardware resource to detect a change to the hardware resource. In an embodiment, change circuitry 3422 may include one or more circuits that operate in changing the hardware resource 3414 in response to a detected change in or to the physical object 3404 or a part of the physical object 3404. Still further, in an embodiment, change circuitry 3422 may include one or more circuits that operate interoperate with monitor circuitry 3420 to send a signal to the physical object 3404, a user, or another device to change an attribute of the physical object 3404 in response to detecting a change in a resource 3414 that represents or otherwise corresponds to the physical object 3404 or a part of the physical object 3404. Monitor circuitry 3420 may send a signal via interoperating with a sensor (see sensor hardware 3406 and sensor circuitry 3408). Alternatively or additionally, monitor circuitry 3420 may send a signal via interoperating with transceiver hardware 3410 or signaling circuitry 3412. In an embodiment, change circuitry 3424, may be included in or may interoperate with a sensor, such as sensor hardware 3406 or transceiver hardware 3410 via monitor circuitry 3420, that may detect a change to physical object 3404 or a change to data about a physical object 3404. Change circuitry 3424 may also interoperate with memory resource 3418 to detect a change in a resource 3416 that represents or that otherwise corresponds to a physical object 3404. In an embodiment, change circuitry 3424 may include one or more circuits that operate in changing a resource 3416 in response to a detected change in or to a corresponding physical object 3404 or a part of the physical object 3404. Still further, in an embodiment, change circuitry 3424 may include one or more circuits that interoperate with monitor circuitry 3420 to send a signal to a physical object 3404, a user, or another device to change an attribute of the physical object 3404 in response to detecting a change in a resource 3416 that represents or otherwise corresponds to the physical object 3404 or a part of the physical object 3404.
In system 3402, the physical object 3404 may be modified via a sensor (see sensor hardware 3406 and sensor circuitry 3408), via an exchange of data between the physical object 3404 and the system 3402 (e.g. via transceiver hardware 3410 and signaling circuitry 3412, or via a user interacting with system 3402 and the physical object 3404). A resource that corresponds to the physical object 3404 may be modified via change circuitry that accesses the corresponding resource, directly or indirectly. Change circuitry may be realized in numerous forms. In an embodiment, change circuitry 3422 may include a data exchange medium such as a bus, a network cable, a wireless medium, and so forth. A modification to hardware resource 3414 may, in an embodiment, be made via a signal sent from the monitor circuitry 3420 to the hardware resource 3414 via change circuitry 3422. In an embodiment, change circuitry 3422, may include virtual circuitry of a notifier or publisher of data sent to hardware resource 3414 or a part of hardware resource 3414 that when processed, changes hardware resource 3414. Monitor circuitry 3420 or change circuitry 3422 may include circuitry that publishes events in response to a change in some or all of the physical resource 3404 or in another resource that corresponds to the physical resource 3404. In an embodiment, change circuitry 3422, may include virtual circuitry that receives request data from monitor circuitry 3420 or from sensor circuitry 3408. The request data may identify a change to make to the hardware resource 3414. Alternatively or additionally, request data provide to send a signal to change the physical resource 3404. The signal may be sent to the physical resource 3404, to a user to modify the physical resource, or to some other device capable of interoperating with physical resource to modify the physical resource.
TBD—describe some working examples. In an embodiment, the resource may include one or more of a user interface element, a device, a network protocol endpoint included in a communicative coupling with the physical object, an input device interacting or interoperating with the physical device, an output device interacting or interoperating with the physical device, data stored in a memory of the system such as metadata for the physical object, or any other suitable resource.
In an embodiment, an operating instance of an application may be included in an access context that constrains interacting with a user. The constraint may be based on one or more resources in a context set of the access context. For constraining the interacting, the context set may include or identify an input device, an output device, an input device driver, an output device driver, a time, a duration, an output space, a subspace, an attribute of a user interface element, another operating instance having a user interface, a user interface model, input data allowed, input data prohibited, conditions for allowing or prohibiting input data, output data allowed, output data prohibited, conditions for allowing or prohibiting output data, a rate of receiving input data, a rate of providing output data, a rate of responding to output in response to input, or a rate of input such as a maximum character input rate—to name some examples.
A user interface element or a user interface handler may be included in a context set of an access context. The user interface element or user interface handler may be accessed by or for a member of the access context. The user interface element or the user interface handler may be included in an interaction between a user and the member. The user interface element may include content provided by the member. The user interface element may be presented via an output device based on presentation information provided by or for the member. The user interface element may be included in a user interface of the member.
Referring to system 3800 illustrated in
The moving may be performed automatically or may include interacting with a user. Moving a subspace may include presenting the subspace in motion. The motion may be in one or more directions or dimensions. A motion in one direction or dimension may be performed simultaneously with a motion in another direction or dimension. A motion in one direction or dimension may be performed prior to or after a motion in another direction or dimension.
In an embodiment, moving a subspace from a first location to a second location may include presenting the subspace in the second location as a result of the moving without presenting the subspace in an intermediate location subsequent to presenting the subspace in the first location prior and prior to presenting the subspace in the second location.
In an embodiment, input information may be received, in response to a user input detected via an input device. The input information may identify or otherwise associate a subspace or a location in a subspace with a user interface element. A record, structure, or other data may be accessed to store data that identifies the subspace and that identifies an operating instance of the user interface element. The stored data may identify an access context and may identify a member of the access context, directly or indirectly. In an embodiment, the stored data may identify the subspace or a location in the subspace and may identify the user interface element. In an embodiment, a context set of the access context may include one or more memory locations for storing data that identifies one or more attributes of the subspace such as a size, location in one or more dimensions, a transparency setting, a font, or one or more resources that may identify circuitry that performs one or more operations on the subspace, the context set, or the member set. In an embodiment, circuitry for one or more of the operations may detect a change to a resource. In response to detecting the change, one or more instructions may be executed in changing some or all of the members of the access context or in changing some or all of the user interface elements of the members in the subspace. For example, in response to detecting a change in size of the subspace, circuitry of the access context may invoke circuitry, such as an API of an interaction subsystem illustrated in
Adding an operating instance to an access context, in an embodiment, may include operating circuitry the interacts with a user to detect a user interface element in a user interface of an operating instance. For example, an interaction may include dragging and dropping a user interface element of an operating instance into a subspace that represents an access context. The operating instance may be added as a member to the access context, in response. A member may be removed from an access context via user interaction, such an interaction that includes ragging a user interface element of a member from a location in a subspace representing the access context to a location outside the subspace. Alternatively or additionally, a user interface element, that represents a boundary of a subspace representing an access context, may be moved so that a user interface element of an operating instance is in the subspace. In response, circuitry of the access context may store data to identify the operating instance as a member of the access context. A member may be removed from a subspace by moving a boundary so that a user interface element or user interface of the member is no longer in the subspace. Circuitry of the access context may delete data that identifies the operating instance as a member or may store data the indicates the operating instance is not presently a member.
Note that subspaces may intersect or overlap, which in an embodiment may allow an interaction similar those described in the previous paragraph to add an operating instance as a member to one or more access contexts or to remove an operating instance that is a member of more than one access context from one or more of the more than one access context.
As described, a subspace may have a boundary in an output space. Some or all of the boundary may be detectable to a user. For example, some or all of a boundary may be visible. Some or all of a boundary may be detectable via a change to a pointer, a user interface element of a member, or other output to indicate a location, which may be exact or approximate, of the boundary. Part or all of a boundary may be hidden at a first time and may be visible or otherwise detectable at a second time. Such times may be scheduled or may occur in response to detecting a specified event such as described in this paragraph. In an embodiment, input data may be specified to initiate presenting a visible indication of some or all of a boundary. Similarly, input data may be specified for making a visible indication of a boundary invisible (e.g. a boundary may be deleted, made fully transparent, or overlaid by one or more other user interface elements).
In an embodiment, a user input may interact via an input device to identify a first location in an output space. A measure of distance determined based on the first location and a second location of a subspace at least partially included in the output space may be determined or received. A boundary may be presented based on such a distance. Alternatively or additionally, an already visible boundary may be hidden based on such a distance. For example, a user may drag a user interface element in a subspace in a first direction. As the user interface element approaches a boundary of the subspace, a transparency attribute of the approached boundary may be lowered, so that the boundary becomes less transparent based on a distance between the user interface element and the boundary.
In an embodiment, the some or all of a boundary of an output space may be detectable to a user via an audio output device and or a haptic output device. For example, a user may resize a user interface element that is not in a subspace. As the size increases and the user interface element approaches, overlays, or intersects with the subspace; an audio device may output one or more sounds which may change in volume, pitch, rate, and so on. In an embodiment, a specified audio output may indicate that a user interface element is in a location for adding the user interface element to a subspace. In an embodiment, adding a user interface element of an operating instance to a subspace, may add the operating instance as a member to an access context that includes or is represented by the subspace. Code may be translated from source code written in a programming language. The source code may include instructions to detect a user input via an input device, to present an output via an audio device or a haptic device to indicate to a user a location of a part or all of a boundary of a subspace. The code may be executed by a processor to operate virtual circuitry to perform the instructions per the source code.
In an embodiment, some or all, of a boundary may be made visible to a user by visually identifying a location adjacent to or within a specified distance from some or all of the boundary so that the location is visually different from one or more locations adjacent to or within a specified distance of the boundary and outside the subspace. For example, a location in a subspace may have a different color than a location outside the subspace. Text in a subspace may be presented in a different font than text outside the subspace. Many other possibilities will be identifiable to those skilled in the art based on the present disclosures.
Some or all of a boundary may be detectable to a user during an operation performed on the boundary such as a moving of the boundary, a reshaping of the subspace, and the like. Some or all of a boundary may not be detectable to a user during an operation performed on the boundary. In an embodiment, some or all of a boundary of a subspace may be detectable when a visibility condition, based on a distance between some or all of a user interface element and some or all of the subspace, may be met. Some or all of a boundary of a subspace may be detectable in response to an interaction between a user and a user interface element in the subspace. Some or all of a boundary of a subspace may be detectable in response to a change in a user interface element in the subspace. For example, content in the user interface element may be modified, the user interface element may be minimized, or the user interface element may be moved. Some or all of a boundary of a subspace may be detectable when some or all of a user interface element in the subspace becomes detectable in an output space to a user.
In response to a moving, a changing of size, or a changing of shape of a subspace in an output space; a user interface element may be moved so that the user interface element remains in the subspace. The user interface element may be moved to a location relative to a boundary of the subspace or relative to another user interface element in the subspace. A specified criterion met prior to initiating of the moving, the changing of the size, or the changing of the shape may be met in response to the moving, the changing of the size, or the changing of the shape. For example, relative distances between user interface elements in a subspace may be maintained during or as a result of a resizing of the subspace.
A subspace may be moved in one or more of a height dimension, a width dimension, or a depth dimension. The user interface element may be included in a plurality of user interface elements that are each in the subspace. In response to moving the subspace, each user interface element in the plurality may be moved. Each user interface element may be moved so that each moved user interface element is in the moved subspace. Each user interface element may be resized, reordered, or reorganized in the subspace. One or more resources in a context set of an access context of the subspace may be modified in response to the moving of the subspace or in response to moving of one or more of the user interface elements in the subspace.
User interface elements in a subspace may be ordered or organized in a depth dimension of the subspace or of an output space that includes some or all of the subspace. Respective locations of the user interface elements in the order or organization may be identified based on a z-ordering or by a coordinate in a coordinate space. In an embodiment, an ordering may be maintained during or subsequent to a change in the subspace or a change in a user interface element in the subspace. An ordering may be changed during or subsequent to a different change in a subspace or a different change in a user interface element in a subspace. An ordering in another subspace may be changed during or subsequent to a same type of change in the other subspace or a same type of change in a user interface element in the other subspace.
In an embodiment, a second subspace may be included in a portion of an output space and, subsequent to a change (e.g. a moving) to a first subspace, the second subspace may be changed (e.g. moved or resized). The second subspace may be changed automatically based on a rule that a specified criterion must be met, such as a visibility condition of the second subspace, a relative ordering in one or more dimensions of the output space, a distance that may be relative or absolute with respect to the first subspace, a directional vector identifying a position of the second subspace relative to the first subspace, and the like.
In an embodiment, a subspace in or representing an access context may or may not be allowed to overlap or intersect with another subspace. In an embodiment, a subspace may be prevented from overlapping or intersecting with another subspace. A subspace may include another subspace referred to herein a child subspace. In an embodiment, a child subspace may define a scope for access to resources in the context set of the access context it is in or that it represents. The constraints of the child access context may override or be combined with those of the parent access context or vice versa. In a child subspace or in an intersection that includes portions of two subspaces, respective constraints may be additive for members of the respective access contexts, or one constraint may have priority over another in an embodiment. A constraint applied if more than one access context identifies a constraint may be from a one of the subspaces selected to have precedence. Constraints from more than one access context may be applied in a specified order in an embodiment.
In an embodiment, a first subspace and a second subspace may be constrained to specified regions or portions of an output space. Two or more subspaces may be allowed to share a boundary or their boundaries may be allowed to overlap. In an embodiment, when a first subspace is visible in an output space, a second subspace may not be allowed to be visible. In an embodiment, when a first subspace is visible in an output space, a second subspace may automatically be presented in the output space.
As described elsewhere, a change in an attribute of a subspace may be detected. The attribute may be changed in response to an interaction between a user and a user interface element representing some or all of the subspace. The interaction may occur via an input device or an output device. In response to detecting the change in the subspace one or more user interface elements in the subspace may be changed. Changing an attribute of a subspace or changing an attribute of a user interface element in a subspace may include one or more of resizing, minimizing, maximizing, changing a transparency level, assigning an input focus for an input device, removing an input focus for an input device, assigning an output focus for an output device, removing an output focus for an output device, changing a font size, changing a color, or changing a style. Alternatively or additionally, in response to detecting a change in a subspace, a user interface element of a member of the subspace or the member may be one or more of suspended, closed, terminated, hibernated, the member may operate as a daemon without a user interface, or some other attribute may be changed.
In an embodiment, when a subspace is in a first location in an output space, a resource in a context set of the subspace may have a first setting. When the subspace is in a second location in the output space, the resource may have a second setting. For example, a user interface element in a subspace may be assigned output focus when the subspace is moved towards a user in one or more dimensions of an output space. A subspace moved away from a user with respect to another subspace may lose an input focus assignment while one or more user interface elements in the other subspace may be assigned input focus for an input device. A change in location may result in a change in size, in a rotation, in an operational state, in a resource in a context set of an access context that includes or is represented by the subspace, in a member or an access context represented by or including the subspace, in a user interface model, in accessible energy for an operating instance having a user interface element in the subspace, or in a type of interaction allowed or prohibited—to name some examples.
In an embodiment, when a subspace is rotated, a resource in a context set of an access context that includes or is represented by the subspace may be changed. A change may be based on a specified direction that at least part of the subspace faces from a prespecified perspective. A change may be based on direction relative to a position of the subspace prior to a rotation, relative to a position a user interface element not in the subspace, relative to a position of another subspace, relative to a position of an output space that includes some or all of the subspace, or relative to a position of a user interface element in the subspace. A change may be based on a measure of a rotation in one or more dimensions, a count of rotations in one or more dimensions, a duration of a rotation, a speed or acceleration of a rotation, a direction of a rotation in one or more dimensions, a sequence of rotations, and the like. In an embodiment, when a user interface element in a subspace is rotated, a resource in a context set of an access context that includes or is represented by the subspace may be changed. A change may be based on a specified direction that at least part of the user interface element faces from a prespecified perspective. A change may be based on direction relative to a position of the user interface element prior to a rotation, relative to a position of another user interface element, or relative to a position of the subspace. A change may be based on a measure of a rotation in one or more dimensions, a count of rotations in one or more dimensions, a duration of a rotation, a speed or acceleration of a rotation, a direction of rotation in one or more dimensions, a sequence of rotations, and the like.
In an embodiment, an operational state of an operating instance may be changed in response to a rotation of a user interface element of the operating instance or other change to the user interface element. In an embodiment, membership in an access context may not be required. Member ship in an access context may be required for some operating instances in some operating environments.
In an embodiment, a communications agent having user interface element face a user may be allowed to receive messages (e.g. incoming calls, texts, emails, etc.) In response to as rotating, the communications agent may not be allowed to receive messages. Membership in an access context may or may not be required depending on an embodiment of an operating environment of the communications agent or depending on an embodiment of the communications agent. By including an operating instance of an operable entity of the communications agent as a member to an access context, the foregoing behavior may be changed. For example, other operational states of the may be changed in response to the same rotation criterion or in response to another change to a user interface element of the communications agent, such as change in location, a different rotation, a change in size, a change in shape, and the like. For example, the member operating instance may be restricted to encrypted communication in response to a change in location of a user interface element to a specified region of a output device. In embodiments of various operating environment, communications agents, or access contexts; a communications agent having user interface element r may be allowed to receive and send audio or video data to another communications agent, present outputs alerting a user to new messages or incoming calls, communication with a first specified address book, send attachments of specified type or size. In response a change in the user interface element, the communications agent may not be allowed to receive or to send audio or video (e.g. an active audio communications session may be muted or a video stream to another communicant may be paused), alerts notifying a user of new messages may be turned off made less noticeable for the communicant represented by the communications agent, may be allowed to communicate with communicants identified in a second address book in addition to or instead of the first address book, sending or receiving attachment may be disable or a size or type of allowable attachments may be modified. In an embodiment, a change to a user interface element (e.g. a rotation) of first communications agent may activate circuitry to send a signal to a second communications agent to change an operational capability or a user detectable attribute of a second communications agent. In embodiments of various operating environment, communications agents, or access contexts; an operational state or other attribute of a communications agent may changed in response to detecting that a criterion, based on a change to a user interface element of the communications agent, is met. The criterion may be specified by differently by different access contexts. An access context may change a criterion of an operating environment. In various operating environments, access contexts, an operating instances, a criterion may be based on an amount of a rotation, a speed or rate of rotation, a direction of rotation, or a pattern of rotation (e.g. a first rotation, followed by a reverse rotation with respect to the first rotation, followed by a rotation in the same direction as the first rotation—a “double twist”). In addition to or instead of a rotation, an operational state of a communications agent may be changed in response to change in location of a user interface element of the communications agent, a change in color, a change in size, a change in shape, A criterion may be met based on an interaction with a user (e.g. a communicant) that occurs prior to, during, or after the rotation such as specified exchange of data via the interaction, may be based on an attribute of a communicant (e.g. identity, role, etc.), may be based on another movement of a user interface element of the communications agent such as a
As described, whether an access context is required or not to change operational state or other attribute of an operating instance in response to a change in a user interface element of the operating instance, the change to the operating instance or the change to the user interface element that triggers the change to operating instance may be disabled, augmented, or otherwise modified by an access context when the operating instance is a member of the access context.
An operational state or other attribute of any type of operating instances may be changed in response to a change in a user interface element of the operating instance. Change to an operating instance and triggering changes to user interface elements of the operating instances may be based on and managed by adding or removing an operating instance as member from one or more access contexts configured to change an operating instance in response to a change in a user interface element of the operating instance. Operating instances of various operable entities may be hibernated, activated, or paused in response to changes in respective user interface elements of the operating instances that meet criterion in a context set of an access context of otherwise specified by an operating environment of an operating instance or specified in circuitry or data of an operating instance.
In an embodiment, an application may have a multi-side user interface element (e.g. a two-sided, three-sided, etc.) such as cube. Each side of the user interface element may include a user interface for exchanging data with another application (remote or local). A rotation of the cube may activate or allow communications with an application corresponding to a side of the multi-sided user interface element facing a user. User interface presented in other sides may be paused, disable, ended, muted, etc. as appropriate per the type of application or desires of a user. For example, a user may interact with various web sites or remote service provides via respective sides of a multi-sided user interface element. In an embodiment, an operating instance may send data via a network to a web site or remote service to identify change in an operational state or other attribute of a user interface for interacting with the web site or remote service presented in a side of a multi-sided user interface element. In an embodiment, a user may switch between communications sessions via user interaction included in manipulating a multi-sided user interface element that presents different communications or different communication sessions in different sides of the multi-side user interface element.
In an embodiment, a multi-side user interface elements may be position so that more than one side is visible to a user. A user interface in a side may be assigned input focus or output focus based on measure or indicator of visibility to a user.
A multi-sided user interface element may be foldable. An operational state or other attribute of a user interface presented in a foldable surface or side or an operational state or other attribute of an operating instance having a user interface element in a foldable surface or side may change based in response to a folding or unfolding of one or more panels or sides of the multi-sided user interface element.
A side of a multi-side user interface element may include a subspace, which may be in a context set of an access context or which may represent an access context. A multi-side user interface element may be a subspace, with user interface elements in the subspace presented in sides of the subspace.
In an embodiment, a first subspace may have an instance of a resource with a first setting in a context set of a first access context that includes or is represented by the first subspace. A second subspace may an instance of the resource with a second setting in a context set of a second access context that includes or is represented by the second subspace. An operable entity when operating as member of the first access context operates based on the first setting. The operating instance may be moved to the second subspace in or representing the second access context so that the operating instance is a member of the second access context. The operating instance, when operating as a member of the second subspace, operates based on the second setting. For example, to access a first network by or for an operating instance of an operable entity, the operating instance may be included as member of a first subspace of a first access context that has a first network interface as a resource in a context set of the first access context. The first network interface may be communicatively coupled the first network. To access a second network by or for an operating instance of the operable entity, the operating instance may be included as member of a second subspace in or representing the second access context that has a second network interface as a resource in a context set of the second access context. The second network interface may be communicatively coupled to the second network. Assigning an operating instance as a member of an access context in plurality of access contexts may provide access to different users, security policies, allowable operational states, user interface models, input devices, output devices, processors, data storage devices, file systems, databases, or portions of any of the foregoing—to identify just a few examples.
In an embodiment, an operating instance may have more than one user interface element each providing a view of a respective portion of a same subspace. Further, multiple operating instances of the same or different operable entity may each have a user interface element that provides a view of a portion of a same or of different subspaces. In an embodiment, an output space may be presented via a virtual reality or an augmented reality device. A subspace viewable in one or more portions may be an e-space. The output space may be an overlay of real space. Changing a user interface element may change the view of the subspace presented as content of the changed user interface element. Changing or moving an output device presenting the output space may change a view of a subspace in the output space. For example, glasses or other augmented reality headgear when moved may provide a different view of a portion of an e-space that is a subspace in an output space of the glasses or headgear. Multiple operable entities may be associated with a member set of an access context where an operating instance of each of the multiple operable entities is a member of the access context. An output space or subspace may be in a context set of the access context. The output space or subspace may be accessed by or for operating instance. In an embodiment, an output space in a context set may be an e-space. Members of the access context of the context set may provide different perspectives, different types of representations of some or all of the e-space, or different information about the e-space. Different members of the access context may interoperate with different physical or virtual objects in the e-space. Different members of the access context may interact with different users or provide different mechanisms for interaction between a user and some or all of the e-space. For example, TBD.
A change may absolute or may be relative (e.g. proportional) in a subspace or output space. For example, user interface elements in a set may be presented stacked in a subspace. When the subspace gets smaller the stack shrinks and when the subspace is enlarged the stack of user interface elements may be spread (e.g. unstacked).
Examples of other subspace attributes include a color, a size, a transparency, a font, an output focus assignment, an input focus assignment, an authorized user, an interaction capability, a communication capability, an update capability, or a data access capability. User interface elements may be changed based on changes to one or more subspace attributes. Similarly, an access context may have one or more attributes. Members may be changed based on a change to one or more resources in the context set of the access context.
In an embodiment, a first subspace in a first portion of an output space of a first output device may be identified. Whether the first subspace has a first input focus for a first input device or does not have the first input focus may be detected. A first user interface element may be identified to be presented in the output space in one of a first location and a second location relative to the first subspace. When the first user interface element is in the first location, the first user interface element may be assigned the first input focus when the first subspace has the first input focus. The first user interface element may not have the first input focus when the first subspace does not have the first input focus when the first user interface element is in the first location. When the first user interface element is in the second location, the first user interface element may have the first input focus when the first subspace has the first input focus, and the first user interface element not have the first input focus when the first subspace does not have the first input focus. A change in relative location of the first user interface element may be detected with respect to the first subspace. The relative location may be from the first location to the second location or from the second location to the first location. The input focus may be changed accordingly. Other attributes of user interface elements or corresponding operating instances may be assigned or set based on the relative location of the user interface elements with respect to a subspace. Accordingly, a user may control one or more attributes user interfaces of a number of operating instances which may be otherwise unrelated. Additionally, via an access contexts, a number of operating instances may be monitored, managed, or control. One or more of the operating instances may otherwise be unrelated.
In an embodiment, subspace circuitry for a subspace may operate in the moving of one or more user interface elements to respective locations determined based on a location of the subspace. Some or all of the user interface elements may be in the subspace or not. The moving may be automatic. For example, with reference to
One or more attributes of a user interface element in subspace may be changed in response to a move or other change in a subspace. A resource may be changed during a moving operation. The resource may be the same prior to an after the moving. The resource may be different during the moving and after the moving. The resource may be the same during the moving, After the moving of the resource may be different. A resource may be different during a moving than after a moving. Changed resources may include one or more of a color, size, a transparency, a font, a user interface control type, an output focus assignment, an input focus assignment, an authorized user, or an interaction capability. An attribute of a user interface element may represent a resource or attribute of an operating instance that has a user interface that includes the user interface element. The resource may be in a context set of an access context of the subspace. The operating instance may be a member of the access context. A change in an attribute of a user interface element of a member may be in response to or may initiate a change in a context resource accessible by or for the member.
In an embodiment, a move user interface element may be presented for moving a subspace or for moving user interface elements in an output space which may be a subspace, or for moving multiple user interface elements of respective operating instances in a coordinated manner. The move user interface element may be a user interface element in the user interface elements to be moved. An interaction may be detected between a user and the move user interface element. The interaction may identify a direction, a distance, or a location to move multiple user interface elements of respective operating instances, where the multiple user interface elements are associated with the move user interface element. In response, multiple user interface elements may be moved while maintaining their relative positions or their relative sizes, may be relocated with respect to one another, or their relative sizes may be changed. Alternatively or additionally, in a moving of multiple user interface elements a shape of one or more user interface elements may be changed. Other attributes of one or more of the user interface elements may be changed in response to a moving of multiple user interface elements in response to an interaction with a move user interface element. In an embodiment, an interaction with a move user interface element may be replaced by, may include, or may be augmented with a gesture, a touch, an interaction with a location in an output space that includes or doesn't include the move user interface element, an interaction with a location associated with a subspace that includes or doesn't include the move user interface element, or an interaction with a location associated with a user interface element moved, to be moved, or moving user interface elements.
Referring to
In an embodiment, an arrangement location for an arrangement of output locations or for arranging output locations may be identified in a specified portion or specified location an output space (or subspace). A set of user interface elements or subspaces may be moved or otherwise presented in an arrangement based on the arrangement location. The first view 4700 illustrates the arrangement location 4710 at the center or within a specified area that includes the center. The user interface elements or subspaces may be arranged based on the arrangement location 4710 as illustrated by the exemplary arrangement of the first-first output location 4702, the first-second output location 4704, the first-third output location 4706, and the first-fourth output location 4708 as illustrated.
The second view 4800 illustrates the second arrangement location 4810 at or within a specified portion of the output space near the top. User interface elements or subspaces may be arranged in the second-first output location 4802, the second-second output location 4804, the second-third output location 4806, and the second-fourth output location 4808.
The third view 4900 illustrates the third arrangement location 4910 at or within a specified portion of the output space 4900 near the top-left. The user interface elements or subspaces may be arranged in the third-first output location 4902, the third-second output location 4904, the third-third output location 4906, and the third-fourth output location 4908 as illustrated.
An arrangement location such as any of the first arrangement location 4710, the second arrangement location 4810, or the third arrangement location 4910 may be established, as an arrangement location, prior to establishing another arrangement location such as any one or more of the other of the first arrangement location 4710, the second arrangement location 4810, or the third arrangement location 4910 as a subsequent arrangement location. The locations may change as illustrated or may change based on an order of establishing the arrangement locations shown or other locations as arrangement location in time.
In an embodiment, an output space may include multiple arrangements of output locations that are each associated with a respective arrangement location. Two or more arrangements of output locations such the first arrangement 4700, the second arrangement 4800, or the third arrangement 4900, may be visible at a same time. In an embodiment, the output locations in the first view 4700 may include user interface elements of a first subspace or a first access context while the output locations of the second view 4800 include user interface elements of a second subspace. The first view and the second view may be presented as a same time in a same or in different output spaces of a same or different device or system.
An arrangement of output locations for user interface elements or subspaces based on an arrangement location may be based on a circle, an oval, an arc, a triangle, a square, or some other regular polygon. Output locations for one or more user interface elements or subspaces, in an embodiment, may be located, sized, or oriented based on an arrangement location utilizing a random or irregular pattern. In some embodiments, a start location in an interaction may be any location other than a corresponding end location. That is, a user may move a pointer, for example, from any location (as a start location) in an output space to an end location to identify the end location as an arrangement location. The organization of output locations associated with the interaction may be based on the end location irrespective of the start location. Still further in an embodiment, the start location may be an arrangement location for a first arrangement of output locations and the end location may identify a new arrangement for second arrangement of output locations to replace the first arrangement. An interaction and one or more locations identified in an interaction may include an exchange of data between a system and a user that identifies or is included in determining an arrangement location, a size, an orientation, or other attribute of user interface elements, subspace, or output locations in an arrangement. In still another aspect, a number of inputs in an interaction, a pattern of the inputs (e.g. a shape identified by the number inputs), a rate in time of receiving inputs, one or more measures of pressure, velocity, acceleration, and the like may be included in determining an arrangement location, a pattern for arranging user interface elements or subspaces, a pattern for arranging output locations, a size for a user interface element or a subspace, a size for an output location, an orientation of a user interface element or a subspace, an orientation for an output location, any other attribute of user interface elements or subspaces presented in an arrangement, or any other attributes of output locations in an arrangement.
An output location may be or may include a subspace. An output location may represent an access context. An output location may be a resource in a context set of an access context. An arrangement location or a user interface element in an arrangement location may overlay, underlie, intersect, be included in, or be presented apart from one or more user interface elements, subspaces, or output locations in an arrangement identified, created, or modified via an interaction that includes the arrangement location. For example, arrangement location 4910 may be invisible as
Moving, changing a size, or changing some other resource of an arrangement of user interface elements, subspaces, or output locations may change an input focus assignment, an output focus assignment, a z-ordering, a transparency level, or any other user detectable attribute of one or more of the user interface elements, subspaces, or output locations. For example, when user interface elements of a subspace are arranged in or around or near a center point of the subspace, each user interface element in the subspace maybe assigned output focus for an output device. the user interface elements in the subspace may not have output focus in another arrangement. Alternatively or additionally, when user interface elements or subspaces in an arrangement are arranged in or around or near a specified location of an output space or subspace, operating instances of the user interface elements or subspace in the arrangement may exchange information via a resource of the arrangement such as a shared location in a memory, a pipe, a socket, a virtual network, a physical data exchange medium, or some other data exchange mechanism. The user interface elements or subspaces, when not in the arrangement, may not be allowed to exchange information or may exchange information via a different mechanism than when arranged based on the specified location. In an embodiment, the user interface elements or subspaces may not be allowed to exchange information when arranged in or around a different specified location. Alternatively or additionally, when user interface elements of subspaces are arranged in or around or near a specified location of an output space or subspace, operating instances of the user interface elements or subspaces in the arrangement access a shared resource such as a source of energy, a source of content to present to a user, a same network, a same service accessible via a network (e.g. a website, a cloud service provider, etc.). Alternatively or additionally, when user interface elements or subspaces are arranged in or around or near a specified location of an output space or subspace, operating instances of the user interface elements or subspace(s) in the arrangement may access different resources in a corresponding set of resources or may access different respective portions of a shared resource. For example, different operating instances may access different portions of a transaction in performing respective portions of the transaction, such as a buy-sell transaction. The examples provided are not intended to be exhaustive.
User interface elements, subspace, or output locations of an arrangement may be tiled, stacked, resized, reshaped, reordered in one or more dimensions, rotated in one or more dimensions, position in an irregular pattern, or position based on a random or pseudo-random output generator.
In an embodiment, a user detectable attribute of a subspace of an access context may include one or more of a location of the subspace in an output space, a size of the subspace (absolute or relative to the output space or to another subspace), a measure of visibility, a level of transparency, a location in a z-ordering (x-ordering or y-ordering), a color, a visible pattern, a shape defined by an outside boundary, a shape defined by an inside boundary, a visible association with another subspace, a user interface element identifying that the subspace is in or represents an access context, a count of sides, a count of surfaces, a measure/indication of brightness, a font, an output focus assignment, an input focus assignment, or an operational state—to name some examples. An operational state may include an operational state of a member of an access context that includes or is represented by a subspace. An operational state may include an operational state of a context resource of an access context. Exemplary resources that may have an operational state include a thread, a computing process, an application, an operating environment, a first hardware resource, a device, a network, a network interface, a network protocol, a network protocol endpoint, a network relay, a communications agent, a user agent, a file system, a source of streamed data, a source of asynchronous messages, a source of responses to a request, circuitry included in accessing/operating an interprocess communication mechanism, or a processor.
In an embodiment, a user interface element size change may be proportional to a change in size of a subspace. The user interface element may be in the subspace or not. Alternatively or additionally, a size of a user interface element may be changed based on an input focus assignment, an output focus assignment, an output activity, a user interaction, or a measure or an indication of visibility of the user interface element.
A state of a user interface element in a subspace or of an operating instance of the user interface element may change in response to a change in size, location, or other attribute of the subspace or the user interface element. A subspace may represent an access context that includes the operating instance as a member or the subspace may be in a context set of an access context that includes the operating instance as a member. The subspace, the user interface element, or the operating instance may be placed in sleep state, a run state, a low power state, a high-power state, a closed state, a locked or unlock state for interaction with a user, assigned an input focus, unassigned an input focus, assigned an output focus, or unassigned an output focus—to name a few examples. The user interface element may be in a user interface of the operating instance. When an operating instance is a member of an access context, a context resource of the access context may be changed based on change in a size, a location, or other attribute of a user interface element of the member, a subspace that includes the user interface element, or another user interface element in the subspace or not in the subspace. The subspace may represent the access context or may be a context resource of the access context. Still further, a user interface model of a member may be based on a size, a location, or a change in size or location of a user interface element of the member, a subspace that includes the user interface element, or another user interface element in the subspace or not in the subspace. For example, a member may have a desktop user interface model (e.g. WINDOWS or MAC OS) when a size of a user interface element of the member meets a specified size threshold, such as exceeding specified size. In an embodiment, the member may, otherwise, have a mobile user interface model such as WINDOWS MODERN or IOS user interface model. A user interface of a member may have a 2-dimensional user interface model based on a size, a location, or a change in size or location. The member may have a 3-dimensional user interface model based on a different size, a location, or a change in size or location. The foregoing resources may, alternatively or additionally, be changed in response to adding a user interface element of an operating instance to a subspace, adding an operating instance to an access context as a member, removing a user interface element of an operating instance from a subspace, or removing an operating instance as a member from an access context.
In an embodiment, a user interface element representing a member of an access context may be presented in a subspace. The subspace may represent the access context. Circuitry of the subspace, circuitry of a user interface handler for the user interface element, or circuitry of the member may detect a change to the user interface element or may detect a change to the member. In response to detecting the change, the circuitry may send an indication, such as a specified electrical signal, to change the member, the subspace, or the access context when the change detected is to the user interface element or to change the user interface element when the change detected is to the member, the subspace, or the access context. The circuitry of the subspace, the user interface handler, the member, or the access context may operate in sending the signal or in receiving the signal and may operate in performing the change to the user interface element, the member, the subspace, or the access context.
In an embodiment, a signal to change a presentation attribute of a subspace or of a part of the subspace may be based on a measure of distance between a location of the subspace or of the part and a location of a user interaction or other change. The location of user interaction or change may include a user interface element for controlling visibility of some or all of the subspace or the part. A color, transparency, visual pattern, location, orientation, size, and the like may be changed in response to a user interaction via the user interface element. In an embodiment, a signal to change a visual attribute of a subspace maybe based on a change in a user interface element not in the subspace or a change in another subspace. The signal may be sent when the user interface element is within a specified distance of a boundary of the subspace or a part of the boundary. In an embodiment, a boundary of a subspace may be unpresented, overlaid by another user interface element, or transparent. A threshold distance may be specified. When a distance between the user interface element, not in the subspace, is less than the threshold, the boundary may be presented, the boundary's transparency may be decreased, the boundary may be widened, the boundary may be presented in a color that differentiates it from at least some part of the output space visibly bounding it, and so forth. Alternatively or additionally, any of the foregoing attributes of a boundary may be presented to increase or decrease visibility as the distance between a user interface element outside the subspace and the subspace decreases or increases respectively (or vice versa). In an embodiment, the second location of flow chart 5600 may be in the subspace. For example, a user interface element in the subspace may change. The visibility of some or all of the subspace interior, output space exterior to the subspace, or a boundary of the subspace may change. A change in size, location, or orientation of a user interface element in a subspace may change the visibility of some or all of the subspace, in an embodiment.
In an embodiment, a signal to change a visual attribute of a subspace maybe based on a change in a user interface element in the subspace or a change in another subspace. A signal may be sent when the user interface element is within a specified distance of a boundary of the subspace. In an embodiment, a boundary of a subspace may be unpresented, overlaid by another user interface element, or transparent. A threshold distance may be specified. When a distance between the user interface element in the subspace is less than the threshold, the boundary may be presented, the boundary's transparency may be decreased, the boundary may be widened, presented in a color that differentiates it from at least some part of the output space visibly bounding it, and so forth. Alternatively or additionally, any of the foregoing attributes of a boundary of a subspace may be changed to increase or decrease visibility as the distance between a user interface element outside the subspace and the subspace decreases or increases respectively or vice versa. An indication of the subspace, may be included in a user interface element in the subspace or in a user interface element not in the subspace.
An attribute of a user interface element may be based on a location of the user interface element in a subspace. An attribute of a user interface element may be based on a location of the user interface element not in a subspace. For example, as a distance between a user interface element and a subspace boundary decreases or meets a specified threshold, a transparency level, size, font, output focus, orientation, or any other user detectable attribute of the user interface element may change.
Circuitry, in an embodiment, may operate in determining a distance between a first location of a subspace and a second location that corresponds to one or more of a user input detected by an input device, an output presented to a user via an output device, or a change in either of a user detected input and an output presented to the user. The circuitry may further operate, based on the determined distance, to send a signal or provide access to data to increase the visibility of some or all of a boundary of the subspace. Visibility may be increased by moving a user interface element that overlays at least a portion of the some or all of the boundary. Alternatively or additionally, a z-level or a location in a depth dimension of an output space may be changed for at least a portion of some or all of a boundary. Alternatively or additionally, visibility may be increased by changing a color, a visual pattern, a width, a shape, a transparency attribute, or a location of at least a portion of some or all of a boundary or of another user interface element that obscures, hides, or otherwise constrains visibility of the at least a portion. In an embodiment, alternatively or additionally (for a separate portion of a boundary), circuitry in or operable with a system may operate, based on the determined distance, to send a signal or provide access to data to decrease the visibility of some or all of a boundary of the subspace. Visibility may be decreased by moving a user interface element so that it that overlays at least a portion of the some or all of the boundary or change a z-level or location in a depth dimension of the output space of at least a portion of the some or all of the boundary so that it is behind some other visible user interface element. Alternatively or additionally, visibility may be decreased by changing a color, a visual pattern, a width, a shape, a transparency attribute, or a location of at least a portion of the some or all of the boundary or of another user interface element to obscure, hide, or otherwise constrain visibility of the at least a portion.
In an embodiment, a first criterion, based on a distance, may be specified for increasing visibility when met. A second criterion, based on a distance, may be specified for decreasing visibility when met.
In another embodiment, a criterion may be specified that, when met, changes visibility of an indicator of whether a user interface element is in a subspace.
Circuitry, in an embodiment, may operate in detecting an indicator that a user interface element is in a subspace or is not in a subspace. An indicator may be based on, for example, one or more of a user input detected by an input device, an output presented to a user via an output device, or a change in either of the user detected input or the output presented to the user. For example, if the interaction is with a user interface element that is not in a first subspace, circuitry may be invoke to change an indicator for another user interface element that is in the first subspace. The indicator for the other user interface element may be removed, made invisible, hidden, presented with greater transparency, made smaller, or otherwise made less visible. In an embodiment, the indicator of inclusion in the first subspace for the other user interface element may be made more visible in response to the interaction. Alternatively or additionally, an interaction between a user and a user interface element in a subspace may be detected. In response to detecting the interaction, an indicator of inclusion in the subspace for the user interface element may be made visible or otherwise made more visible. In an embodiment, circuitry may operate to make an indicator of inclusion in the subspace invisible or otherwise less visible.
Circuitry, in an embodiment, may operate based on a criterion that is met based on a first location and a second location (e.g. see flow chart 6100). A distance between a location of a user interface element (e.g. a second location) and a location in a subspace (e.g. a first location) may be determined, a rate of change in distance may be determined, a distance from a boundary of the subspace whether inside or outside or overlapping the boundary may be determined, and the like. One or more of the foregoing in the previous sentence may be included in identifying whether an indicator of inclusion in a subspace should be made more or less visible. An indicator of inclusion in a subspace for a user interface element may be an indicator of membership of an operating instance, represented by the user interface, in an access context represented by the subspace. An indicator may be presented or made more visible as a user interface element in a subspace moves toward a boundary of the subspace or may be turned on when a threshold distance between the user interface element and the boundary meets a threshold distance, for example. An indicator that a user interface element is in a subspace may include moving the user interface element to a specified location in one or more dimensions of an output space that includes the subspace. For example, a user interface element in a subspace may be presented in front, behind, to the right of, to the left of, higher than, or lower than a user interface element not in a subspace as specified for an embodiment. A visibility of a user interface element in a subspace may be different than a visibility of a user interface element not in the subspace or not in any subspace. In an embodiment, a first user interface element in a subspace may become more transparent as a distance between the first user interface element and a second user interface element in the subspace increases (or decreases in another scenario). Any suitable, visibly detectable change may be used in addition to or instead of transparency. Inclusion in a subspace (or membership in an access context) may be indicated based on a color, a visual pattern, a size of a user interface element, a visual connection with another user interface element in the subspace or a lack of visual connection with a user interface element not in the same subspace, a location attribute, or a font—to name some examples. An indicator may be obscured or hidden via another user interface element in making it less visible.
In an embodiment, a location of a subspace or of a user interface element in the subspace may change a location of a user interface element not in the subspace. The user interface element not in the subspace may be in another subspace or not in any subspace.
A first subspace or a first user interface element at a first location in an output space may be located at second location in response to or based on a change to one or more of a location of a second subspace or a second user interface element. a size of the second subspace or the second user interface element, a shape of the second subspace or the second user interface element such as stretching or contracting some or all of the second subspace or the second user interface element, and the like. Subsequent to the change, the first subspace or the first user interface element may no longer be at the first location or may be at both the first location and the second location. In an embodiment, a criterion, based on the first subspace or first user interface element and the second subspace or the second user interface element, may be specified. The criterion may be met prior to a change to the second subspace or the second user interface element. In response to detecting the change, circuitry may operate, in an embodiment, that determines the specified criterion is not met. The first subspace or the first user interface element may be changed so that the criterion is met.
In an embodiment, a user interface element in subspace may be moved so a criterion is met based on a change in a location of the subspace and the moving of the user interface element. A user interface element in the subspace or not in the subspace may be changed so a criterion is met after a change to a subspace or a user element that was met prior to the change in the subspace or the user interface element.
A criterion specified for user interface elements in a subspace may be based on a distance, an angle, a color, a visibility criterion, or any other attribute that may be bound between or among two or more user interface elements in or not in a subspace or that may be bound between or among one or more user interface elements and a boundary or other portion of a subspace.
A moving or other change to a user interface element may be performed automatically in response to determining that a specified criterion is not met. Note that the second view 6600b illustrates that a portion of a subspace may not be in a visible portion of an output space as shown by a portion of the second boundary location 6616 outside the visible output space.
In an embodiment, a criterion based on a z-ordering or relative locations in a depth dimension may be specified that changes the z-ordering or changes the relative locations in response to a change, such as a move, to a subspace or to a user interface element in an output space. The user interface element may be in the subspace in a scenario. In another scenario, the user interface element may not be in the subspace. Alternatively or additionally, a criterion based on a z-ordering or relative locations in a depth dimension may be specified that preserves the z-ordering or preserves the relative locations in response to a change to a subspace or to a user interface element in an output space. The user interface element may be in the subspace in a scenario. In another scenario, the user interface element may not be in the subspace.
In an embodiment, circuitry may be included or may otherwise be operable for use with a system. The circuitry may operate in detecting a subspace in a first location in an output space. The subspace may include multiple user interface elements each representing a respective operating instance. Further, each user interface element may be in a location in a z-ordering. For example, each user interface element may be presented assigned to a respective z-level or coordinate in a depth dimension of the output space or the subspace. The circuitry may also operate in receiving an indication to move the subspace. The indication may identify a move in one or more dimensions of the output space. The circuitry may further operate in moving, in response to receiving the indication, the subspace. Moving may include a moving of the entire subspace, an expanding of some or all of the subspace, a contracting of some or all of the subspace, a reshaping, or a rotation of some or all of the subspace. As a result of the moving, some or all of the subspace is no longer included in the first location. Alternatively or additionally, the some or all of the subspace may be in a second location that includes no part of the subspace prior to the moving. Still further, the circuitry may operate in modifying one or more of the user interface elements in response to the moving to preserve the z-ordering of the user interface elements in the subspace.
Alternatively or additionally, in an embodiment, an ordering in a width dimension or an ordering in a height dimension may be preserved for user interface element in subspace by a modifying operation performed in response to a moving, resizing, reshaping, or other changing of the subspace. In an embodiment, a distance between two or more user interface elements in a depth dimension may be preserved. A distance between two or more user interface elements in a depth dimension may be changed while preserving the ordering. Relative distances between the two or more user interface elements may also be preserved or not as desired for an embodiment.
In an embodiment, an operation, allowed when a subspace is in an active state and not allowed when the subspace is an inactive state, may include interacting with a user via an input device or an output device. For example, in an active state a user interface element in the subspace may be assigned an input focus for an input device allowing an operating instance of the user interface element to interact with a user via the input device. Alternatively or additionally in the active state, a user interface element may be assigned an output focus for an output device allowing the operating instance to interact with a user via the output device. When in an inactive state, the user interface element may not be assigned the input focus or the output focus. A state for a subspace may be associated with an operation included in exchanging data via a network, for communicating via a first communications agent that represents a user as a communicant, for retrieving data, for storing or changing stored data, and so on. For example, an exchange may be between a user represented by a communications agent having a user interface element in the subspace and a communications agent representing another communicant may be allowed for an operating instance having a user interface element in a subspace that is in an active state for communicating between or among communicants.
In an embodiment, circuitry may be included or may otherwise be operable for use with a system. The circuitry may operate in identifying a subspace in a first location of an output space of an output device. The subspace may include a first user interface element of a first operating instance and second user interface element of a second operating instance. In an embodiment, the first user interface element and the second user interface element may not have a same parent user interface element or may have a parent user interface element that is not in the subspace. Alternatively or additionally, neither of the first user interface element and the second user interface element is a parent of the other. The circuitry may also operate in assigning an output focus resource in a context set of the subspace. When the output focus resource is assigned a first setting, both the first user interface element and the second user interface element may be assigned output focus for an output device. When the output focus resource is assigned a second setting or when the output focus resource is removed from the context set, both the first user interface element and the second user interface element are not assigned the output focus for an output device. The output device may be a same device for each of the first user interface element and the second user interface element or may be different output devices for each of the first user interface element and the second user interface element.
Analogously, in addition to or instead of assigning output focus, when the user interface element is in the first location, the user interface element is not assigned an input focus, and an input focus setting associated with the subspace is assigned a first value; circuitry may be included in an embodiment that operates in assigning the user interface element the input focus. In addition to or as an alternative, when the user interface element is in the second location, the user interface is not assigned the input focus, and the input focus setting is assigned a second value; circuitry may be included in an embodiment to operate in assigning the user interface element the output focus.
In an embodiment, the circuitry may also operate in detecting a change in relative location, with respect to a subspace, of a user interface element from one of a first location and a second location to the other one of the first location and the second location. With respect to the subspace, the change may be in at least one of a horizontal direction and a vertical direction. In an embodiment, the user interface element may not be minimized when the output focus is assigned to the user interface element. The circuitry, may further, operate in modifying, in response to detecting the move, an output focus or an input focus assignment for the user interface element so that when, relative to the subspace, the user interface element is in the first location the user interface element may have the output focus or may have the input focus when the subspace has the output focus or when the subspace has the input focus, may not have the output focus or may not have the input focus when the subspace does not have the output focus or when the subspace does not have the input focus. Further, when the user interface element is in the second location the user interface element may not have the output focus or may not have the input focus when the subspace has the output focus or when the subspace has the input focus, and may have the output focus or may have the input focus when the subspace does not have the output focus or when the subspace does not have the input focus. Other capabilities or attributes, in addition to or instead of input focus or output focus, may be controlled or managed based on a relative location of a user interface element is with respect to a subspace such a audio output focus, communications capabilities, user access, network capabilities, and so on.
Some or all of a specified location may be in a subspace in an embodiment. Alternatively or additionally, some or all of a specified location may not be in a subspace.
When an operating instance is a member of an access context and accesses a resource, such as an addressable entity, the access is constrained by the access context when the resource is in the context set of the access context. When the accessed resource is not in the access context or the operating instance is not a member of the access context, the access takes places as allowed by the operating environment of the operating instance. Note that a constraint of an access context refers to a difference in accessing the addressable entity when a member than when not a member of the access context. Thus, a constraint may constrict, expand, or change access to a resource or in a mechanism for accessing a resource. Detecting an access to a resource may include enforcing a constraint before or during the access. Alternatively or additionally, a resource or a mechanism for accessing a context resource of an access context may be applied prior to detecting an access.
A resource or a context resource may be an addressable entity. An addressable entity may be any entity specified in source code written in a programming language. An addressable entity may be accessed, by a processor as data or machine code in a processor memory. The machine code may be a translation of the source code. Examples of addressable entities as specified in a programming language include data such as variables and constants and instructions such as subroutines and function.
In an embodiment, a resource may in a context set of an access context in an operating environment. An operating instance that is not a member of the access context may access a different resource. For example, a file system path for template documents may be a first specified path for a member of the access context and may be second specified path specified for the operating environment. Alternatively or additionally, a resource accessible to a member of an access context in an operating environment may not be available to an operating instance, in the operating environment, that is not a member of the access context. For example, a user name or password may be accessible to a member of the access context, but not accessible to an operating instance that is not a member of the access context.
A resource may be hardware or virtual circuitry. A resource may be or may include an operating instance or a portion of an operating instance.
In an embodiment, the resource accessed by or for an operating instance of an operable entity may be included in or may include a resource accessed by or for the operating. The operating instance of the operable entity may be a member of an access context. A resource accessed by or for the operating may be includable/excludable in the context set of the access context. The resource may include or may be based on one or more of a processor, a memory, hardware for storing data, hardware for sending a signal, hardware for receiving a signal, a source of energy, a type of energy, an energy exchange medium, an operating system, a file system, a database, an output device, an input device, a peripheral device, a transmit buffer, a receive buffer, an interprocess communication mechanism, source code that specifies an addressable entity, a programming language of source code, a translation of the addressable entity from source code, a data type of an addressable entity, data or circuitry that indicates whether an addressable entity may include an instruction executable by an operating environment of a member, data or circuitry that indicates whether an addressable entity may be excludable from a translation source code, a value stored in a memory location that represents an addressable entity, a network protocol, a network protocol endpoint, a network protocol address, a network protocol address space, a network path, a path node, a hop, a link, a data transmitting node, a data receiving node, a network interface, a quality of service setting or other quality of service resource, another operating environment, a user agent, a communications agent, a network service (WEB, cloud, etc.), a user interaction, a user, a group, a data source, an input focus assignment, an output focus assignment, a source of energy, a type of energy, a measure of energy, an operational state, a source of data, a time, a duration, a geospatial location, an ambient condition, a shared resource, a service provider accessible via a network, hardware, a size, a type of user interface element, a state of a user interface element, a relationship for exchanging data, an administrator, a developer, a security resource, a performance resource, a priority or ranking, a developer, a reseller, a contractual condition, a law, a regulation, a source of a resource, a state of a resource, or metadata for a resource. This list is not exhaustive.
A context set of an access context may include state data to identify a state for one or more members of the access context. For example, a context set may have state data that may be set to indicate a stopped or not operating state, a starting state or initialization state, an interacting state, a non-interaction state, a network exchange state, a state that indicates no data may be exchanged via a network, or a normal operating state. In an embodiment, when a state resource in a context set of an access context identifies a starting state, one or more operating instances of one or more members of the access context may be started. An access context, thus, allows a mechanism to control the state of multiple operable entities via a setting. A context set of an access context may contain multiple state settings for respective multiple members. When a first state of a first member changes, a second state of a second member may be changed by changing a state setting in the context set for the second member. An access context, thus, may provide a mechanism for coordinating states of multiple members.
Instead of or in addition to a context set that includes a modifiable setting as described in the previous paragraph, a context set may include a resource having a fixed or constant data setting. Using the state settings from the previous paragraph as examples, states of an operating instance of an operable entity may be changed by moving the operating instance an access context with a context set that includes a first state setting to another access context with a context set that includes a second state setting. Respective states of the multiple operating instances may be coordinated by moving one or more of the operating instances between or among access contexts.
In an embodiment, an operable entity may be identified for identifying one or more operating instances of the operable entity as members of an access context. An operating instance may be a member of a first access context that is a child of a second access context that may include other members. Changing a setting for a member(s) of a first access context may include moving the first access context to a second access context so that the first access context is a child of the second access context where a context set of the second access context modifies the setting. Note that an operating instance may have multiple settings such as a setting for a network resource or a network operation, a setting for a storage resource, a setting for a processor, a setting for an output device, and so on. A context set may include settings, stored a code or data, for such multiple settings allowing their values to be managed in coordinated fashion via one or more policies of a context set. Alternatively or additionally, one or more settings may be managed in a coordinated fashion via moving one or more members between or among access contexts to change access to the one or more setting as membership changes. Alternatively or additionally, one more setting may be managed for an operating instance by assigning the operating instance as a member to more than one access context that together include the one or more setting in their context sets.
When two or more access contexts have respective context sets with duplicate, overlapping, or contradictory settings, embodiments of the present disclosure may assign priorities to the access contexts in a static manner, based on user interaction, based on an order in which a member is added to the corresponding access contexts, based on respective times of setting or changes to such settings, and so forth. Just as adding or removing a member may be represented by user detectable changes to a subspace that represents an access context, a priority or ranking may be represented via user interface elements of subspaces that are included in or that represent access contexts. For example, a z-ordering of subspaces in an output space may identify priorities of duplicate, overlapping, or contradictory settings in context settings of respective access contexts each represented by a subspace in the z-ordering. Alternatively or additionally, a font resource, a color resource, a transparency resource, a size resource, a shape resource, and the like may indicate a ranking or priority of resources in context sets of respective access contexts represented by subspaces to a user.
An operating instance may be prespecified as a member of an access context, may be prespecified as excluded as a member, may be added or removed via interaction between a user and a user interface, such as a subspace, that represents an access context, or may be added or removed automatically based one or more criterion such as an occurrence of a specified event. A member set of an access context may be fixed or partially fixed.
An access context may be configured to provide a mechanism to prevent instances of operable entities from sharing a resource. Alternatively or additionally, an access context may be configured to provide a mechanism to allow instances of operable entities to share a resource. Examples of resources that an access context may allow sharing or may prevent sharing include processors and processor resources, storage resources, data exchange resources, operational resources, input resources, and the like. A subspace, included in or that represents an access context, may enable access to a shared resource (e.g., data, a network connection, a device, an interprocess communication mechanism) accessible to apps, operating environments, etc. that have user interface elements in the subspace. For example, a subspace may have its own network interface, stack, secondary storage, and the like as constrained via an access context that includes the subspace or is represented by the subspace.
An access context have a context set that includes resources utilized for multiple purposes by or for members of the access context. For example, a single access context may be provided all or some of the separate access contexts illustrated in
Instead of allocating an operating environment, such as a virtual machine or a Linux Container, for various applications or other types of operating instances, some or all of the operating instances may share an operating environment. One or more of the operating instances may be members of one of more access contexts which may each customize the operating environment for respective members. An access context may provide a partial operating environment. An access context may change, modify, or customize an operating environment for an operating instance operating as a member of the access context. Operating environments may be much more flexible, sharable, safer, or energy efficient than current operating environment—to name a few examples. An operating environment may be reusable for different purposes by configuring an operating environment with one or more access contexts and assigning operating instances to one or more of the access contexts based on the operating instances, quality of service agreements, privacy of data being processed, priority of one or more tasks to perform, a user or client being served, and the like. Operating environments may be customized faster than configuring new operating environments and operating environment initialization and tear down may be faster by changing access contexts while allowing an operating environment to remain static or relatively static. Interoperation between operating instances, sharing an operating environment while each operates in a customized environment via assignment to one or more access contexts, may be faster. Interprocess communication mechanisms maybe be utilized to exchange information as opposed to utilizing network resources or virtual network resources utilized by present day cloud computing environments that exchange information between operating instances operating in different virtual operating environments. Interoperation may be safer than exchanging data between or among multiple operating environments. Hardware resources may be utilized more efficiently. For example, fewer virtual operating environments may be needed when operating instances share virtual operating environments customized for one or more operating instances by one or more access contexts. Fewer virtual or physical processors, storage devices, input devices, output devices, network devices, and the like may be needed to perform the same work.
A subspace or an access context may be cloned or copied to create a new subspace that may subsequently differ from the parent subspace or access context. A first member of a first access context and a second member of a second access context may operate in distinct environments, as if each operated in a separate operating environment (e.g. a LINUX containers, a VM, an operating system), when access one or more resources in the respective contexts sets of the first access context and the second access contexts. When accessing resource(s) not in the first access context or the second access context the first member and the second member operate as if both operate in a same operating environment (which may be the operating environment that includes the first access context and the second access context or may be an access context that includes the first access context and the second access context). Each access context can have its own path defaults, templates, default file paths, device drivers, adapters, or other physical or virtual resources; while accessing other resources via a shared portion of the operating environment. For example, an access context may provide a virtual file system rather than allow access to or direct access to a file system of an operating environment modified by the access context. The underlying data storage system of the operating environment may be utilized but hidden or not utilized. Moving members of the access context to another operating environment may require little or no change to code of a member that accesses the virtual file system.
An access context may be cloned or copied. An access context clone may include the same resources in its context set while having cloned or copied instances of operating members. An access context clone may include cloned instances of resources in its context set. In an embodiment, an access context and a clone of the access context may operate independently subsequent to the cloning. In an embodiment, an access context and a clone of the access context may be related so that a change to or operating of one changes the other. For example, one or more resources in a context set of an access context may be synchronized in whole or in part with one or more resources in a context set of a clone of the access context. An access context and a clone of the access context may operate in a same device, in a same operating environment, in different devices, or in different operating environments.
An access context or a combination of access context may create an operating environment which may be a virtual operating environment or not. An operating environment created by configuring one or more access contexts may be highly specialized. Parts of a traditional or present day operating environment may be excluded. For example, an operating environment may be configured so that it includes no or a different type of file system, no or a different type of network interface, no or a different type visual output subsystem, no or a different type user input driver, and the like with respect to the present day operating environments which include operating system supported (E.g. Windows, Linux, Android, iOS, etc.) file systems, network interfaces, visual output subsystems, user input drivers, and the like. Alternatively or additionally, an operating environment may be created that supports a networking protocol not supported by a hosting operating environment. The networking protocol may be a non-standard network protocol. The non-standard protocol may be unique to the access context. Alternatively or additionally, non-standard persistent data storage systems may be included in an operating environment via an access context. An access context may be reusable, providing a customizable building block. From a number of access context building blocks, an assortment of operating environments may be configured. A diverse set of operating environments may provide a safer Internet. Diversity in operating environments may make creation and deployment of malware more difficult and may make use of malware less destructive across the Internet or other networks. Note that an operating environment can be in a context set of an access context which may be accessed for or by member of the access context.
For current user devices and operating systems that support multiple users, each user is currently provided with a separate user interface. In an embodiment, a first access context may allow input from a first user to be received by a member of the first access context and a second access context may allow input from a second user to be received by the second access context, but not vice versa. Both users may share a user interface via separate input or output devices or via one or more shared input or output devices. A third access context may include members that allow input from either user to be received by a member of the third access context. Access context may be utilized to share or separate access to one or more user interfaces. A shared access context may allow access to user only when two or more users are authenticated.
In another embodiment, a first access context may allow input from a first user to be received by a member of the first access context and a second access context may allow input from a second user to be received by the second access context, but not vice versa. User interfaces of members of the first access context and members of the second access context may be represented in a first user interface for the first user and in a second user interface to the second user. The first user interface and the second user interface may differ per user customization. The first user interface and the second user interface may differ based on a difference in an input device or an output device accessible to the first user and the second user, respectively. For example, a two-dimensional tiled user interface may be provided by a handheld device of the first user while three-dimensional hologram (which may be included in an e-space that includes a physical object) may be provided by an operating environment of a projection enabled device interacting with the second user.
An access context may be configured for or based on a specified task or type of task, a specified transaction or type of transaction, a specified exchange of data or type of data exchange, a specified communications agent or mode of communication, a specified interoperation between or among operating instances, a specified user or type of user (e.g. a user assigned a role, a user in a location, etc.). The foregoing examples are not exhaustive.
An access context may be predefined, configured in response to an identifying of an attribute of a user of the access context, or may be modified while the access context is instantiated or operating. Members of an access context may be predefined, may be determined based on a specified criterion, may be assigned by a user, or may be assigned automatically by a device or system.
An access context may be configured so that operating instances exchange information when operating as members of the access context, but otherwise are not configured to exchange information.
An access context may be configured to provide a distributed operating environment for a member operating in an operating environment that is not otherwise included in a distributed system or distributed operating environment.
An access context may be configured that provides a shared mechanism for configuration or monitoring of operating instances that are members where there is no shared mechanism for configuring or monitoring the operating instances, as a group, when not operating as members of the access context. Shared mechanisms for monitoring operating instances and modifying operating instances may be provided by a suitably configured access context.
As described herein, access contexts enable a wide range of operating environments for a wide range of devices from internet of things devices (e.g. thermostats, watches, etc.) to servers to cloud computing environments. Access contexts enable customization of existing operating environments allowing operating instances to operate in a same operating environment that may be customized for respective operating instances according to their membership in one or more access contexts. Access contexts have other benefits that will be or will become apparent, based on the present disclosure, to others according to their area(s) of art in which they are skilled.
In one or more embodiments of the subject matter of the present disclosure, an access context or subspace may be definable or configurable by a user. A user may be a user of an operating instance that may be added as a member to an access context or subspace being defined or configured. A user may be a user of a member that is already a member of the access context or subspace being defined or configured. A user may have authorization to access a resource of the context set of the access context to configure. A user may have authorization to add, remove, or replace a resource in a context set. In an embodiment, an access context may be configurable via a member of the access context, a user interface presented by circuitry of the access context, or via an operating instance that is not a member of the access context. Similarly, a subspace may be configurable via a user interface element in the subspace, a user interface presented by circuitry of the subspace, or via a user interface element that is no in the subspace.
One or more template access contexts may be provided that include code or data for creating and managing an access context, a member(s) of an access context, operations of an access context, or attributes of an access context. Code or data for creating and managing an access context or separate code or data be included in creating and managing a context set of an access context, manage resource(s) of a context set, manage operations of a context set, or manage attributes of a context set. In addition to a generic access context template, templates may be accessed that are pre-configured or partially preconfigured for including or excluding specified types of operating instances, sources of operating instances, users of operating instances, or operating instances of specified operable entities. Pre-defined templates for access contexts that specify, in whole or in part, a security environment, a network environment, a user interaction environment, a data storage environment, a security environment, and the like may be included in an operating or may otherwise be accessible to the operating environment for customizing the operating environment or for creating or customizing another operating environment.
In an embodiment, an access context may be configured for an operating instance, such as an application. Such an access context may be created or configured via circuitry of the operating instance or via an operating environment of the operating instance. An access context for an operating instance may include only the operating instance as a member in an embodiment. In another embodiment, membership may be restricted to operating instances of a same operable entity. Alternatively or additionally, membership may be restricted to operating instances that operate in performing a specified task, a transaction, or a workflow. Alternatively or additionally, membership may be restricted to operating instances that operate for a specified user(s), group, or legal entity. A template access context may be provided by an operating instance, by an operating environment of an operating instance, or provided via remote service provider.
Code may be written that when executed operates on, monitors, manages, updates, or accesses portions of access contexts of various types that may include different types of members or different types of resources in respective context sets. A context set for an access context may be allowed to include a resource, a type of resource, or a resource that meets a specified criterion included in defining the context set. A context set for an access context may be allowed to include zero, one, or more resources of a same type or that each meet a same criterion included in defining the context set. A context set for an access context may be allowed to include a heterogenous set of resources having different types or resources or resources that meet one or more criteria included in defining the context set.
A resource may be predefined as included in a context set of an access context. For a context set of an access context, a resource may be added, removed, or modified prior to an adding of a member to the access context, by or for a member, or in response to a completing of a member. A constraint may be specified to change a resource in a context set when accessed by or for a member of the context set's access context. A constraint may be specified to remove or initiate a removing of a resource accessed by or for a member of an access context from a context set of the access context. A constraint may be specified to add or initiate an adding of a resource accessed by or for a member of an access context from a context set of the access context.
A resource in a context set of an access context that is accessed by or for a member of the access context may be included in code or data of an operable entity, in code or data of a member, stored in a data storage device, stored in a processor memory of an operating instance, or may be external to memory of any member or other operating instance. A resource in a context set of an access context may be accessible to a first member of the access context from or via a second member of the access context.
Examples of operating instances include computing processes, threads, applications which may include one or more processes or threads and which may operate across one or more devices or operating environments, devices, and operating environments which include stand-alone operating environments, virtual operating environments, and cloud computing environments.
In an embodiment, an operating instance may be added as a member to an access context that includes a resource sharing mechanism allowing members to access resources provided by one or more other members. Examples of resource sharing mechanisms include a shared data storage system, a shared data storage location, a pipe such as a UNIX pipe, a bus whether physical or virtual, a data link, a network, an interrupt, a queue, a stack, a messaging system such as a request-reply system or a notification system, a semaphore, or an interprocess communication mechanism not otherwise identified in the present disclosure.
A resource in a context set may include one or more of a user interface element, an output device, an output space, another access context, a subspace of an output space, an input device, an operating environment (e.g. a virtual operating environment, a cloude computing environment, etc.), a processor, a memory, a network protocol endpoint, circuitry that may operate according to a network protocol, a network interface, a data transmission medium, an operating instance, a member of an access context, a peripheral device, a peer device, a user agent, a communications agent, a network service (WEB site, a cloud, etc.), a network relay (physical or virtual switch, router, etc.), configuration data, a source of energy, a source of data, a source of code, a certification authority, authentication information, authorization information, a role, an owner, an administrator, a user, a measure of energy, a measure of data, a mode of communication, a communicant address, a schema an address space, a measure/indicator of a speed, a rate, an amount, a measure of variability or deviation, a range, a maximum, a minimum, a price, a cost, a measure of heat, a measure of power, metadata for a processor, metadata for a memory, an operational state (e.g., of a context resource or of a member), a location (e.g., of a resource, a user, a member, etc.), a size, an output focus state, an input focus state, a thread state, a computing process state, a user detectable resource, an orientation in a multi-dimensional output space (may be a subspace), a security resource, a functional capability, a time, a duration, an ambient condition, a user, a group, a legal entity, a network protocol, an interprocess communication mechanism, a computing process, an application, a device, and a representation (e.g. a user interface element, a proxy, etc.) or metadata for any of the foregoing.
Members of an access context or user interface elements in a subspace may share a common value for a resource such as a font. Members of an access context or user interface elements in a subspace may each have a resource that is established relative to a resource or setting of the another member or user interface element. For example, as a subspace size changes the relative sizes of the user interface elements in the subspace may change. A shared resource may be accessed by one or a subset of members of an access context at any given time. Two or more subspaces may each have an output focus resource. In one of the subspaces, the output focus may be assigned to one member at a time. In another of the subspaces, more than one member may be assigned output focus at a same time.
As described above, a member of an access context, a context resource accessed by or for a member, or a member of an access context may be changed in response to a change in the access context, a change the context set of the access context, a change in a resource in the context set, or a change in another member of the access context. As also described, an access context, the context set of the access context, or a resource in the context set may be changed in response to a change in a member, a context resource accessed by or for a member, or during operating of a member of the access context. A changing of any of the foregoing may include an interaction between a user and a user interface element of a member, a user interface element of an access context, a user interface element of a context set, or a user interface element of a resource of a context set. Alternatively or additionally, a changing of any of the foregoing may be based on change information not received in or via an interaction. In an embodiment, change information may be received via a network, a physical link, a device, an interprocess communication mechanism, a data exchange interface hardwired in physical circuitry (can be an ePROM, FPGA), a data exchange interface realized in virtual circuitry, or an operand of a machine code instruction that may identify a memory location of change information. Change information may be received via the network in a communication received from a communications agent, in a message received from another communications agent. The other communications agent may be included in or otherwise may represent a network service. The message may be included in one or more of a response to a request, in an asynchronous message received based on a subscription or not, and in a broadcast message.
A user interface element of a member may be presented in a subspace in an output space of an output device. The subspace may be an output representing the access context. The subspace may have a plurality of user interface elements that each represent a member of the access context
A subspace may have a one or more of a size, a shape, a boundary, and a location in an output space that may or may not be determined based on one or more of a size, a shape, a boundary, or a location, or count of any user interface element that represents a resource in the access context of the subspace.
In an embodiment, a change to a user interface element may include a change to one or more of a location in an output space, a location in a subspace of an output space, an attribute of a subspace of the user interface element, an input focus assignment, an output focus assignment, an output space assignment, an output device assignment, an input device assignment, a network access resource, a network quality of service resource, a network protocol, a network, a communicative coupling, content presented via the user interface element, a source of content presented via a user interface element, circuitry included in interacting with a user via a user interface element, a mode of interaction with a user, a user detectable attribute of the user interface element, a resource of power utilized in executing circuitry of the user interface element, a user interacting with the user interface element, the access context, a subspace of the access context, or a member of an access context that includes or is represented by a subspace.
In an embodiment, a first member of an access context may change a resource in a context set of the access context. The resource may be accessed by or for the first member per a constraint of the access context. A resource accessed by a second member may be changed, in response to the change to the resource by first member. The second member and the first member may each be operating instances of a same operable entity or they be operating instances of different operable entities. The change to the resource accessed by or for the second member may be based on a rule of the access context. The resource accessed by or for the first member and the resource accessed by or for the second member may be the same resource or may be different. The resource accessed by or for the first member may include the resource or vice versa.
A change to a resource accessed by or for a member of an access context may be result in or may be represented by a change in a user interface element of one or more members of the access context. The user interface element may be presented in a subspace in an output space. A change to a resource may result in or may be represented by a change for a user interface element to one or more of a location of the user interface element in the output space, a location in the output pace of the subspace, an attribute of the subspace, an input focus assignment, an output focus assignment, an output space assignment, an output device assignment, an input device assignment, a network access resource, a network quality of service resource, a network protocol, a network, a communicative coupling, content presented via another user interface element, a source of content presented, circuitry included in interacting with a user via the user interface element, a mode of interaction with a user, a user detectable attribute of the user interface element, or a member.
As described elsewhere herein, an access context may have a criterion that is evaluated for determining whether an operating instance may be added as a member to the access context, removed as a member of the access context, or modified. For example, a criterion may identify one or more of a maximum number of members includable an access context, a minimum number of members that must be in an access context, a count (e.g. a range) of members that define a state of an access context, an ordering of members in an access context indicating an order of adding or an order of removing members, a type of resource includable in or excludable from an access context, a time that a resource may be includable, or a duration that a resource may be in, includable, or excludable. A specified criterion may be prespecified or static. A criterion may be modifiable.
A constraint or a criterion of an access context may be based on, may include, or may be included in one or more of a user interface element, an output device, an output space, another access context, a subspace of an output space, an input device, an operating environment (e.g. a virtual operating environment, a cloud computing environment, etc.), a processor, a memory, a network protocol endpoint, circuitry that operates according to a network protocol, a network interface, a data transmission medium, a thread, a computing process, an application, a device, a peripheral device, a peer device, a user agent, a communications agent, a network service (WEB site, a cloud, etc.), a network relay (physical or virtual switch, router, etc.), configuration data, a source of energy, a source of data, a source of code, a certification authority, authentication information, authorization information, a role, an owner, an administrator, a user, a measure of energy, a measure of data, a mode of communication, a communicant address, a schema, an address space, a speed, a rate, an amount, a deviation, a range, a maximum, a minimum, a price, a cost, heat, power, metadata for a processor, metadata for a memory, an operational state, a location, a size, an output focus state, an input focus state, a thread state, a computing process state, a user detectable resource, an orientation in a multi-dimensional output space (may be a subspace), a security resource, a functional capability, a time, a duration, an ambient condition, a user, a group, a legal entity, an interprocess communication mechanism, or metadata for any of the foregoing.
In an embodiment, a constraint may identify one or more of a change/modification that may be allowable or not allowable to a resource in a context set. A change to an access context may include a change to one or more of a criterion, a constraint, the context set of the access context, a resource in the context set, or a member. Resources of an access context that may be changed or monitored for a change include a count of resources in the context set of the access context, a count of members in the access context, a maximum number of resources allowed in the context set, a minimum number of resources that must be in the access context, a maximum number of members allowed, a minimum number of members required, a state of the access context, a user interface element representing the access context, a subspace of the access context, a user interacting with the access context, a relationship to another access context, a security resource of the access context, an input focus resource, an output focus resource, a network resource, or other metadata for the access context.
In an embodiment, an operating instance that is a member of an access context may be assigned to another access context, based on a resource accessed by the member or based on a state of a work flow or transaction that is performed in whole or in part by the operating instance. For example, in an embodiment a first operating instance may be automatically assigned as a member to an access context that allows the member output focus for an output device. When access to output focus changes, the member may be automatically unassigned or reassigned. An operating instance may be automatically assigned membership so that the operating instance maintains an output focus assignment. Automatic membership change may prevent an operating instance from having output focus for a specified output device. Automatic membership change may prevent an operating instance from being denied access focus for one or more output devices. Access to other resources may be also be controlled via automatic membership assignment to access contexts based on a change to a resource, an access context, or to an operating instance. Subspace assignments may be made similarly. For example, a user notification user interface element may be presented always in a front most subspace or a subspace meeting a specified criterion (e.g. the subspace closest to a bottom left corner.
A user interface element may be copied from one subspace to another or moved (e.g. cut and pasted). Copying a user interface element may cause other user interface elements to also be copied or may cause some user interface elements to be copied. Removing a user interface element from a subspace may cause other user interface element in the subspace to be removed. When a subspace represents an access context, copying or moving a user interface element from a first subspace representing a first access context to a second subspace of a second access context may respectively copy or move a member that corresponds to the user interface element copied or moved from the first access context to the second access context.
Change information, as used herein, may refer to a change to one or more of an operating environment, a communicative coupling, an energy source, a user interface element, an addressable entity, or security data accessed by or for a member of an access context. The change information may identify; for the member, the resource, or a user interface element representing the member or the resource; a change to one or more of a location in an output space, a location in a subspace of an output space, an attribute of a subspace, an input focus assignment, an output focus assignment, an output space assignment, an output device assignment, an input device assignment, a network access resource, a network quality of service resource, a communicative coupling, a source of energy, a type of energy, a measure of energy, content presented via an output device, a source of content presented via an output device, circuitry included in interacting with a user, a mode of interaction with a user, a user detectable resource, a resource of power utilized, a user, an interaction, the access context, a subspace, a processor, a memory, hardware for storing data, hardware for sending a signal, hardware for receiving a signal, a measure of energy, an energy exchange medium, an operating system, a file system, a database, an output device, an input device, a peripheral device, a transmit buffer, a receive buffer, an interprocess communication mechanism, an addressable entity, source code that specifies an addressable entity, a programming language of source code, a translation of an addressable entity from source code, a data type of an addressable entity, whether an addressable entity includes an executable instruction, whether an addressable entity may be excludable from a translation source code, a value stored in a memory location that represents an addressable entity, a network protocol, a network protocol endpoint, a network protocol address, a network protocol address space, a network path, a path node, a hop, a link, a data transmitting node, a data receiving, node, a network interface, an operating environment, a user agent, a communications agent, a network service (WEB, cloud, etc.), a group, a data source, an operational state, a source of data, a time, a duration, a geospatial location, an ambient condition, a shared resource, a service provider accessible via a network, hardware, a size, a type of user interface element, a state of a user interface element, a relationship for exchanging data, an administrator, a developer, a security resource, a performance resource, a priority or ranking, a reseller, a contractual condition, a law, a regulation, a source of a resource, a state of a resource; a member, a size, a transparency level, a font size, a color, a location in the subspace, a shape, whether a user interface element may be included in a subspace, a data exchange, a time, a date, a duration, security data, user data, geospatial location data, location data for a user interface element in a subspace, an output space, an output device, an input device, another subspace, output focus data, input focus data, energy, energy data, owner data, administrative data, support data, error data, a user detectable attribute of a subspace, a user interface model, a user interface mode, a permission or authorization, a user agent, a communications agent, a remote service provider accessible via a network, a communicant address, interaction data, attention data, ambient data, processor memory data, secondary storage data, processor data, shape data, creating a clone/copy, adding a user interface element to a subspace, removing a user interface element from a subspace, other hardware data, color data, shape data, creating a clone/copy, adding a user interface element to a subspace, removing a user interface element from a subspace, a criterion for determining whether a user interface element may be included in a subspace, or a resource of or metadata for any of the foregoing.
Change information, for a resource, may identify a change to one or more of a security principal for authenticating an accessing of a resource by or for an operating instance, a device, an operating environment, a user, a location, and the like. Alternatively or additionally, change information may identify a security role, a type of access allowed or not allowed, a criterion for allowing access, or a criterion for not allowing access—to identify some examples. One or more of the criterion may be based on a time, a date, a day, a duration, a count of may access, a type of access, second security data for the resource, security data for another resource, a location in a memory, a geospatial location, a user, a group, a legal entity, a device, an application, a process, a thread, a processor, a memory, an energy source, a location in an output space, a location in a subspace of an output space, an attribute of a subspace of the access context, an input focus assignment, an output focus assignment, an output space assignment, an output device assignment, an input device assignment, a network access resource, a network quality of service resource, an addressable entity, a communicative coupling, a source of energy, content presented via the first user interface element, a source of content presented via the first user interface element, circuitry included in interacting with a user via the first user interface element, a mode of interaction with a user, a user detectable attribute of a user interface element, a resource of power utilized in executing circuitry of the resource, a resource of power utilized in accessing the resource, a user interaction, the access context, a subspace of the access context, hardware for storing data, hardware for sending a signal, hardware for receiving a signal, a type of energy, a resource of energy, an energy exchange medium, an operating system, a file system, a database, an output device, an input device, a peripheral device, transmit buffers, a receive buffer, an interprocess communication mechanism, source code that specifies an addressable entity, a programming language of source code, a translation of an addressable entity from source code, a data type of an addressable entity, whether an addressable entity may include an instruction executable by circuitry of the one or more operating environments, whether an addressable entity may be excludable from a translation the source code, a value stored in a memory location that represents an addressable entity, a network protocol, a network protocol endpoint, a network protocol address, a network protocol address space, a network path, a path node, a hop, a link, a data transmitting node, a data receiving, node, a network interface, a quality of service resource, another operating environment, a user agent, a communications agent, a network service (WEB, cloud, etc.), a type of energy, a measure of energy, an operational state, an ambient condition, a shared resource, a service provider accessible via a network, hardware in or otherwise accessible, a size, a type of user interface element, a state of a user interface element, a relationship for exchanging data, an administrator, a developer, a performance resource, a priority or ranking, a developer, a reseller, a contractual condition, a law, a regulation, a source of the resource, a state of the resource; a computing process, an application, hardware, an operating environment, a device, or metadata for any of the foregoing.
Change information may be received via a user interaction with a user interface element that represents a resource, a subspace, a member, or an access context. The representation may be direct or indirect.
In an embodiment, a change to a resource may be made via or otherwise represented via a change to a user interface element that represents the resource or a member where the resource is access by or for the member. In an embodiment, the operation may be performed to change the access context. In an embodiment, an operation may be performed based on change information, to change each resource in a context set.
In an embodiment, an output space may have at least three dimensions. An output space may be or may include an e-space. An e-space may include a user detectable physical object (not presented via the output device and not included in the output device). A subspace may be located in an e-space based on a physical object. The subspace may include no portion of the physical object. There may be no visual overlap detectable to a user interacting with one or more of the subspace and the physical object. Alternatively or additionally, a visual overlap may be detectable to a user interacting with one or more of the subspace and the physical object.
A physical object may be a resource accessed by or for a member of an access context. A representation of the physical object may be included in a context set of the access context. In an embodiment, a user interface element may represent the physical object in an output space. The user interface element may be presented by a member in which the representation or the physical object is accessed by or for the member. In an embodiment, the user interface element may identify, for the physical object, one or more of a previous user, an authorized user, a monetary value, a cost of performing a task that may include access to or interoperation with the physical object, a role of a user interacting with one or more of the user interface element or the physical object, a maintenance operation to perform, a content rating, an indicator of whether the physical object may be identified in a specified set of objects for a task (a recipe, a construction task, a shopping list, . . . ), a temperature, a chemical, a biological element, a next location, an archive location, a home location, a defect, an error, a duration of operation, a duration in a location, a manufacturer, a seller, a previous owner, whether the physical object may be purchased (bought, borrowed, leased, rented, given as a gift, . . . ), a companion object, a substitute object, another version, an alternative (and a source of the alternative), a reminder of a task (scheduled) that may include or may be based on the physical object.
In an embodiment, a resource, type of a resource, or arrangement of resources in a context set may identify an access context, a type of access context, or an access context template.
As described, a subspace may be included in an access context as a resource in a context set of the access context. Alternatively or additionally, a subspace may be associated with an access context via some other mechanism such a pointer, a symbolic reference, a data structure, or a database record. A subspace may be provided as a visual representation of an access context with user interface elements presented in the subspace provided as visual representations of respective members of the access context. A user may interact with an access context or its members via the presented visual representations. In an embodiment, a change to a user interface element of a subspace may represent a change to the access context. A change to a user interface element of a member, may represent a change to the member. A change in an access context may be based on a change in data or circuitry of the access context. A change in an access context may be based on a change in one or more members of the access context. A change in a member may be based on a change in the access context.
A change in a member of an access context may include one or more of an addition of an operating instance to the member set of the access context, a removal of a member from the member set, or a change in a current member.
Changing an access context, a member set of an access context, a member of a member set, a context set, or a resource in a context set may include or may be made in response to an interaction between a user and a user interface element of one or more of the access context, the member of the member set, the context set, another resource in the context set. Such a changing may include receiving change information that identifies the change. Change information may be received via one or more of a network, a physical link, a peripheral device, a remote device, a user agent, a network service provider, an interprocess communication mechanism, a data exchange interface hardwired in physical circuitry (can be an ePROM, FPGA), or a data exchange interface realized in virtual—to name some examples. Change information may be received via the network in a communication received from a communications agent, in a message received from a network service.
In an embodiment, an operation may be performed to change a first member based on a change to a second member. An operation may be performed to change a first resource in a context set based on a change to a second resource in the context set. An operation may be performed to change a member based on a change to a resource in a context set. An operation may be performed to change a resource in a context set based on a change to a member.
Change information for a change to an access context, a context set, a resource in a context set, a member set, a member in a member set, or a user interface element that represents or is included in any of the foregoing may identify a change to a memory location for storing one or more of state data, time data, duration data, security data, user data, geospatial location data, subspace location data, user interface element location data, a rule of the subspace, an output space, an output device, an input device, another subspace, output focus data, input focus data, a source of data, a destination for data, a network, a network protocol, a network protocol endpoint, a network path, a path node, a hop, a link, an operating environment, a source of energy, energy data, owner data, administrative data, support data, error data, a user detectable attribute of the subspace, a user interface model, a user interface mode, a permission or authorization, a user agent, a communications agent, a remote service provider accessible via a network, a communicant address, interaction data, attention data, ambient data, processor memory data, secondary storage data, processor data, a size, transparency data, font data, color data, shape data, creating a clone/copy, adding a user interface element to a subspace, removing a user interface element from a subspace, a criterion for determining whether a user interface element may be included in a subspace, data exchanged with circuitry operating in embodying another subspace, other hardware data, or metadata for any of the foregoing.
Each member of an access context may be changed in response to a change in the access context, the context set of the access context, a resource in the context set, or another member of the access context.
In an embodiment, change may be represented by a change in a user interface element. A change to a user interface element may include a change to one or more of a size, a transparency level, an input focus assignment, an output focus assignment, a font size, a color, a location in a subspace, a shape, user detectable content, a state, a creation of a clone/copy, whether the user interface element may be included in the subspace, a data exchange, a time, a day, a duration, security data, user data, geospatial location data, location data for a user interface element in a subspace, an output space, an output device, an input device, another subspace, output focus data, input focus data, a source of data, a destination for data, a network, a network protocol, a network protocol endpoint, a network path, a path node, a hop, a link, an operating environment, a source of energy, energy data, owner data, administrative data, support data, error data, a user detectable attribute of the subspace, a user interface model, a user interface mode, a permission or authorization, a user agent, a communications agent, a remote service provider accessible via a network, a communicant address, interaction data, attention data, ambient data, processor memory data, secondary storage data, processor data, shape data, adding a user interface element to a subspace, removing a user interface element from a subspace, hardware data, or metadata for any of the foregoing.
A change to a subspace may include one or more of an addition or a removal of a user interface element of one or more of members of an access context that includes the subspace in a context set or where the subspace is associated with the access context in another manner.
In response detecting a change in a subspace representing an access context, an operation may be performed to modify each user interface element representing a member of the access context. In an embodiment, each user interface element in the subspace may represent a respective member. A change to a subspace may correspond to a change in an access context. A change in an access context may include a change to a context set of the access context or a change to a resource in the context set. Examples of resources, in addition to examples identified elsewhere herein, may include or may be included in one or more of a an appliance, an item of furniture, a user interface element, an output device, an output space, a subspace of an output space, an input device, an operating environment (e.g. a virtual operating environment, a cloud computing environment, etc.), a processor, a memory, a thread, a computing process, an application, a device, a communicative coupling, a network protocol endpoint, a network interface, a peripheral device, a peer device, a user agent, a communications agent, a network service (WEB site, a cloud, etc.), a network relay (physical or virtual switch, router, etc.), configuration data, a source of energy, a source of data, a source of code, a certification authority (authorization, authentication), authentication information, authorization information, a role, an owner, an administrator, a user, a measure of energy, a measure of data, a mode of communication, a communicant address, a schema, a quality of service resource (an speed, rate, amount, variability, range, deviation, a max, a min, a price, heat, power, processor resource, a measure or resource of memory), a location in an output space, a location in a subspace of an output space, an attribute of a subspace that may include the user interface element, an input focus assignment, an output focus assignment, an output space assignment, an output device assignment, an input device assignment, a network access resource, a network quality of service resource, a network protocol, a network, content presented via a user interface element, a source of content presented via a user interface element, circuitry included in interacting with a user via a user interface element, an mode of interaction with a user, a user detectable attribute of a user interface element, a resource of power utilized in executing circuitry of a user interface element, or a user interacting with a user interface element.
A user interface elements in a subspace may be associated, bound, or related via, for example, a data record or via executable instructions in a memory, to identify the user interface elements in the subspace. When the subspace represents an access context, a data record or executable instructions of the access context may determine how one or more of the user interface elements in the subspace or members of the access context change in response to a change in a resource in a context set of an access context.
In an embodiment, user interface elements in a subspace may be associated, bound, or combined to create compound user interface elements presented by multiple operating instances represented in a subspace or multiple members of an access context when the subspace is in a context set of the access context or represents the access context. Simpler user interface elements may be combined to build compound user interface elements. For example, in an e-space a mix of displayed user interface elements and physical objects may be combined. Virtual books may be presented on a real surface (e.g. of a desk, table, shelf. Etc.). When a user interface element representing the bottom book of the stack is moved in the e-space, the other user interface elements representing other books in the stack may move in a specified way. They may move as they would in the real world or in a way not probable in the real world. In an embodiment, if a sensor detects a movement of the real surface, one or more of the virtual objects (e.g. books) may be moved or changed in response.
Multiple user interface elements of multiple operating instances operating in one or more devices of one or more operating environment may be combined to construct objects that may be manipulated as a set or a single element. Systems and processes may associate unrelated user interface elements and may then manipulate those user interface elements as a group. An access context of such a subspace may provide resources enabling members to exchange information or operate according to a configuration of the access context. For example, on a display, a writing application and a drawing application may be associated such that when one is opened and displayed, the other is also opened and displayed. Furthermore, when one is moved, the other may move in a manner specified by a rule, policy, or identified operation.
Some or all of a boundary in an output space of subspace may be made detectable to a user via one or more of an audio output device or a haptic output device. An output may be presented via one or more of the audio device and the haptic device to indicate to the user the presence/existence of the some or all of the boundary. Some or all of a boundary of subspace may be detectable during a moving, copying, or other operation being performed on the subspace or a user interface element in the set. The subspaces may be prevented from overlapping or otherwise occupying a same portion of an output space.
Subspaces in an output space may have one or more fixed-sized dimensions, may be stacked in one or more dimensions, and may have a regular arrangement in an output space. Subspaces in an output space may be arranged irregularly in the output space. Subspaces may at least partially overlap in one or more dimensions. A subspace may have a curved shape or may have an irregular shape. Subspace shapes are not limited to the shapes described or illustrated in the present disclosure.
A user interface element may be in more than one subspace, such that movement of the subspace may warp, stretch, etc. Moving a user interface element towards a boundary of a subspace, resize, or reshape the boundary. In response, other user interface elements in the subspace may be moved, resized, or reshaped accordingly. Moving a user interface element outside the bounds of the subspace may remove the user interface element from the subspace. Moving a user interface element outside a boundary of a subspace that represents an access context may remove an operating instance of the user interface element as a member of the access context.
In 3-D virtual reality displays (e.g., headgear, glasses), a physical object in an output space may be associated with a subspace that provides one or more user interface elements for interacting with (e.g., controlling) the physical object or that presents data about the physical object. A first output space may be partially shared with a second output space via associating user interface elements to a shared subspace.
Referring to
Referring to
In an embodiment, an arrangement of locations of user interface elements in a subspace may be based on one or more operating instances of the user interface elements, a task performed by one or more of the operating instances, a duration that of an arrangements (e.g. arrangement changes may be timed), a count of inputs from a user (e.g. arrangement may be changed 1000 touches for a device with only a touch input device), a detected or determine indicator of user attention, a state of one or more of the operating instances or corresponding user interface elements, or an ambient condition—to name some examples.
Referring to
In another embodiment, an indicator or control such as the straight line 8506a may remain in a fixed shape while moved in response to user interaction to move the locations of the user interface elements simultaneously in a height dimension, a depth dimension, or a width dimension. A user may interact with a line or other control off-center to move a location of one user interface element more than a location of another or to move user interface element in different directions (e.g. a rotation, an expansion, a contraction, etc.). User interface element locations may be rotated in one or more dimensions of an output space via an interaction with an indicator or via a gesture that identifies a type of indicator. An indicator or control may be hidden, visible, partially visible, at least partially transparent, and may have other attributes that when changed cause circuitry to be invoked that changes the associated user interface elements in addition or instead of changing locations of the associated user interface elements.
Moving a subspace, changing a size of a subspace, or changing some other attribute of the subspace may change an input focus assignment, an output focus assignment, a z-ordering, a transparency level any other user detectable attribute of a user interface element in the subspace. For example, a subspace may be specified such that when a user interface element is in the subspace, the user interface element has output focus, and, when the user interface element is not in the subspace, the user interface element does not have output focus.
An access context or a subspace may be defined such that a first operating instance of an operable entity and a second operating instance of an operable entity are communicatively coupled when the first operating instance and the second operating instances are members of the access context, which may or may not be represented by a subspace in which each of the first operating instance and the second operating instance has a respective user interface element.
In an embodiment, a first user interface element in a subspace or of a first member of an access context may operate in a first operating environment. A second user interface element in the subspace or of a second member of the access context may operate in a second operating environment. The first operating environment may operate at least partially in a cloud operating environment that may interoperate via a network with a device that may include or may interoperate with an output device having an output space in which the first user interface element may be presented. The second operating environment may operate at least partially in the device to present the second user interface element in the output space.
An output space (e.g. subspace) may be bound to a physical object such as a wall, an automobile, a person, a floor, furniture, a building, a room, an appliance, or a road—to name a few examples. For example, a physical package may have an associated user interface element that represents a shipping label. The shipping label may be bound to a side of the package (e.g. the side facing a user, facing a scanner, or in a position readable by another non-human reading system). The location of the shipping label may change based on a location or orientation of the package with respect to a user. Different labels may be presented for different users. If no user is looking at the package, no label may be displayed or projected on to a side of the package. The shipping label is merely exemplary, other data about a physical about may be processed similarly.
In an embodiment, a subspace or any user interface element may be identified by its location in any of its containing output spaces. Recall that a subspace is itself an output space included at least partially in another output space. A location may be identified in an absolute manner, such as via a coordinate in a coordinate space of the containing output space. Alternatively or additionally, a location may be identified in a relative manner, such as one or more distances from another location in one or more respective dimensions, via vector in a coordinate space of a containing output space, via a relative location in an ordering, such as a z-ordering, y-ordering, or x-ordering. For example, a location of user interface element may be identified as being two locations in front of another user interface element in a z-ordering and one location to the left of the same or another user interface element in a width dimension.
A depth dimension, in an embodiment, may be identified via an axis in a coordinate space that may include at least two dimensions. A coordinate space with three dimensions may be mapped to a two-dimensional output space, as is common in current display devices where a depth location may be simulated by overlaying a user interface element over some or all of another user interface element to indicate it is in front of the other user interface element in the depth dimension. The ordering may be accessed via circuitry as an ordered list or each user interface element may be given a coordinate in a depth dimension that is simulated when presented in the two-dimensional output space. In general, an n-dimensional space may be simulated in a m-dimensional space where n is greater than m. Circuitry may be included or provided to interoperate with a system to map or translate one coordinate system to another. A coordinate space may identify a location in an output space that is not visible, such as a cached output space or may identify a location in a visible output space of an output device. As described elsewhere herein, an output space of an output device may be included in (e.g. may be a subspace of) an e-space creating an augmented reality output space (or subspace). An augmented reality output space may include one or more physical objects which may be associated with user interface elements presented in the augmented reality output space.
A first subspace and a second subspace may be presented in an output space so that their intersection in the output space is empty. If the first subspace represents a first access context and the second subspace represents a second access context, an intersection of the first access context and the second access context may be empty when the intersection of the first subspace and the second subspace is empty. A moving of one or both of the subspace may create a non-empty intersection of the two subspaces (and their respective access contexts when they represent access contexts) during the moving or as an end result of the moving. In an embodiment, intersecting subspaces or intersecting access contexts may not be allowed. A subspace may be moved or a subspace may be removed to allow another subspace to move to or through a portion of their output space while avoiding intersecting of the subspaces (and their respective access contexts if the subspaces represented respective access contexts). The removal may be temporary lasting during the moving or lasting until the moved subspace is moved to allow the removed subspace to return to its location. Alternatively of additionally, both subspaces may be moved in a coordinated fashion to prevent a non-empty intersection of the subspaces in the output space (and their respective access contexts if the subspaces represented respective access contexts).
A first subspace, in an embodiment, may include no portion of an output space included in a second subspace prior to a moving. A portion of the output space may be included in each of the first subspace and a second subspace during or subsequent to the moving. One or more of the first subspace and the second subspace may include the other one prior to, during, or subsequent to the moving. In an embodiment, a first subspace may be, with respect to a user when interacting with the subspace, between the user and a second subspace. The first subspace, with respect to a user, may be between the user and the second subspace prior to the moving, during the moving, or subsequent to the moving. The first subspace, with respect to a user may be behind the second subspace prior to the moving, during the moving, or subsequent to the moving. Subsequent to the moving, some or all of the first subspace may be between the user and the second subspace. Subsequent to the moving, some or all of the first subspace may be behind the second subspace from the perspective of a user.
In an embodiment, a first subspace may include a first portion of the output space included in a second subspace prior to a moving. No portion of the output space may be included in each of the first subspace and the second subspace subsequent to the moving. A second portion of the output space may be included in each of the first subspace and the second subspace subsequent to the moving. One or more of the first subspace and the second subspace may include the other one of the one or more of the first subspace and the second subspace. A portion of the first subspace may be, with respect to a user when interacting with the subspace, between the user and the second subspace prior to the moving. Subsequent to the moving, some or all of the second subspace may be between the user and the first subspace. Subsequent to the moving, a portion of the first subspace may be between the user and the second subspace. A portion of the second subspace may be, with respect to a user when interacting with the subspace, between the user and the first subspace prior to the moving. Subsequent to the moving, some or all of the first subspace may be between the user and the second subspace. In an embodiment, a first user interface element may be presented inside a first subspace or in a bounding surface of the first subspace prior to and subsequent to a moving.
A first subspace and a second subspace may be included in a first z-ordering in an output space. One or more user interface elements in the first subspace may be included in the first z-ordering. In an embodiment, one or more user interface elements in the first subspace may be in a second z-ordering. The first z-ordering may include user interface elements that are child user interface elements of the output space. User interface elements in the second subspace may be included in the first z-ordering. User interface elements in the second subspace may be included in the second z-ordering along with user interface elements of the first subspace. User interface elements in the second subspace may be included in the third z-ordering.
In an embodiment, locations in an output space may be identified by respective coordinates in a first coordinate space. Locations in a first subspace in the output space may be identifiable via a second coordinate space that may be unchanged after a moving. The second coordinate space may be an instance of a second coordinate system and the first coordinate space may be an instance of a first coordinate system. In another embodiment, the first coordinate space and the second coordinate space may be instances of a same coordinate system.
A moving may include a rotation of a first subspace in an output space. In an embodiment, locations in the first subspace may be identified via a respective first portion of coordinates of the first coordinate space prior to the moving. The locations in the first subspace may be identified via a respective second portion of coordinates of the first coordinate space prior to the moving.
In an embodiment, a subspace may have fewer dimensions than an output space that includes some or all of the subspace. Alternatively or additionally, a subspace included at least partially in an output space may have more dimensions than the output space.
A user interface element in a subspace may have an identifiable location in one or more dimensions of the subspace. A location of a user interface element in an output space, where the user interface element is in a subspace at least partially in the output space, may be identifiable via an identifier in a coordinate space of the output space. A location of a user interface element in an output space, where the user interface element is in a subspace at least partially in the output space, may be identifiable via an identifier in a coordinate space of the output space along with an identifier in a coordinate space of the subspace.
In an embodiment, in response to moving a subspace, a first user interface element and a second user interface element may each be located in respective same locations in the subspace before, during, or after the moving of the subspace. The respective same locations may be identified based on a coordinate space of the subspace that does change in response to the moving. The respective same locations may be identified based on a coordinate system that changes size in response to the moving. The move may include a change in size of the subspace. The coordinate system may change size in response to a change in size of the subspace.
In an embodiment, in response to moving a subspace, a first user interface element and a second user interface element may change locations with respect to each other in the subspace before, during, or after the moving of the subspace. In response to moving a subspace, a first user interface element may have a same location with respect to the subspace before, during, or in response to the moving while a second user interface element may have a different location with respect to the subspace at least one of before, during, or in response to the moving.
In an embodiment, a first user interface element and a second user interface element in a subspace do not overlap in the subspace in one or more dimension prior to the moving. The first user interface element and the second user interface element may overlap at least partially in the subspace during or as a result of the moving. In an embodiment, a first user interface element and a second user interface element in a subspace may overlap in the subspace in one or more dimension prior to a moving. The first user interface element and the second user interface element may not overlap or a size of an overlap region in one or more dimensions may change during or as a result of the moving.
In an embodiment, a first user interface element and a second user interface element in a subspace do not intersect in the subspace in one or more dimension prior to a moving. The first user interface element and the second user interface element may intersect at least partially in the subspace during or as a result of the moving. In an embodiment, a first user interface element and a second user interface element in a subspace may intersect in the subspace in one or more dimension prior to a moving. The first user interface element and the second user interface element may not intersect or a size of an intersection region in one or more dimensions may change during or as a result of the moving.
In an embodiment, a first subspace in an output space may be, with respect to a user when interacting with the subspace, closer in a depth dimension of the subspace to the user than a second subspace prior to a moving of the first subspace. In an embodiment, subsequent to the moving, some or all of the second subspace may be closer in the depth dimension to the user than the first subspace. A first subspace in an output space may be, with respect to a user when interacting with the subspace, between the user and a second subspace prior to a moving of the first subspace. That is the first subspace may overlay the second subspace from the perspective of the user. The perceived overlay may include a partial intersection of the first subspace and the second subspace. In an embodiment, subsequent to the moving, some or all of the second subspace may be between the user and the first subspace. That is the second subspace may overlay the first subspace from the perspective of the user. The perceived overlay may include a partial intersection of the first subspace and the second subspace.
In an embodiment, a first subspace in an output space may be, with respect to a user when interacting with the subspace, further away in a depth dimension of the subspace to the user than a second subspace prior to a moving of the first subspace. In an embodiment, subsequent to the moving, some or all of the second subspace may be further away in the depth dimension to the user than the first subspace. A first subspace in an output space may be, with respect to a user when interacting with the subspace, behind the second subspace prior to a moving of the first subspace. That is the second subspace may overlay the first subspace from the perspective of the user. The perceived overlay may include a partial intersection of the first subspace and the second subspace. In an embodiment, subsequent to the moving, some or all of the first subspace may be between the user and the second subspace. That is the first subspace may overlay the second subspace from the perspective of the user. The perceived overlay may include a partial intersection of the first subspace and the second subspace.
A subspace may include user interface elements of operating instances of different devices or different operating environment. User interface elements presented by multiple output devices may be presented in a same output space such as an e-space that may include one or more physical objects. User interfaces of multiple device or operating environment may be at least partially merged or shared via a same output space of via multiple output spaces where at least part of a presentation in each output space is synchronized.
In various embodiments, a context set may include one or more computing process resources. Examples of computing process resources include a processor, a processor memory, a scheduler, a process state, a process queue, a processor register, stack memory space, heap memory space, a memory data segment, a memory code segment, an instruction cache, a data cache, and processor memory schema. Alternatively or additionally, a context set may include one or more storage resources. Examples of storage resources include a file, a folder, a database, a data structure, a variable, a constant, a virtual memory, a physical memory, a memory address space, a persistent memory, a volatile memory, a storage device driver, a storage device hardware adapter, circuitry and hardware for access remote storage such a cloud-based data store, a cloud-based data store, a removable data storage device, a flash drive, a hard-drive, a tape, a tape drive, an optical data storage device, a thermal data storage device, a magnetic data storage device, an electronic data storage device, a file handler, a primary key for a record in a plurality of records, a secondary, key, or metadata for any of the foregoing. Alternatively or additionally, a context set may include one or more interaction resources. Examples of interaction resources include an output device, an input device, an output adapter, an input adapter, an output space, a coordinate system, a coordinate space of a coordinate system, a user interface element, a graphics code library, a GPU, a user interface model, or metadata for any of the foregoing. Alternatively or additionally, a context set may include one or more resources from other categories of resources such a data exchange resource, an input resource, an output resource, a network resource, a time resource, a personal communications resource, an energy resource, an error or exception resource, a configuration resource, a monitoring resource, a security resource, or metadata for the foregoing resources.
In an embodiment, context set of an access context may include an operating environment resource of a virtual operating environment, a cloud computing environment, or task operating environment.
A user interface element may be pre-specified to be assigned to a subspace. Alternatively or additionally, user interface element may be included in a subspace based on a user interaction engaged in for some other purpose. A user interface element may be added to a subspace in response to a starting or initiating of an operating instance or a portion of an operating instance, such as a function or specified step in a process. A user interface element may be included in a subspace based on a user, a role, a date, a location, a legal entity (a company), or a power state—to name some examples.
A location attribute of a subspace may serve as an anchor, may define a boundary, may define a constraining region, may identify an orientation in an output space, may control/constrain depth/width/height of a user interface element(s) in the subspace.
As described above, an output space (e.g. subspace) or an access context may be copied, cut, or pasted to another output space or access context, respectively. For example, a subspace may be copied or moved from one virtual desktop to another or from the output space of a first output device to an output space of a second output device. A subspace may be moved or copied from first output space to a second output space that may have a different number of dimensions (e.g. two-dimension to three-dimensional or vice versa), that may have different sizes (e.g. tablet to wide-screen TV), from a first user interface model to a second user interface model (e.g. Windows 10 to Android).
An output space (e.g. subspace) or an access context can be closed, hibernated, slept/paused and states the user interface elements or their operating instances may be changed in response. A user interface element or an operating instance may be closed, hibernated, or paused, running, initializing, and the like.
An output space (e.g. subspace) or an access context may respectively have a parent output space (e.g. subspace) or access context, a child output space (e.g. subspace) or access context, or a peer output space (e.g. subspace) or access context.
Operable entities may be located in a folder that corresponds to an access context. Operating instances may be configured based on context set data stored in the folder, in a parent folder, or stored as metadata for the folder or for an operable entity in the folder. A folder may be created or identified for including one or more operable entities. Operating instances of the one or more operating entities may be pre-configured to be members of a specified access context or group of access contexts. Alternatively or additionally, a user interface element of each operating instance of the one or more operable entities in the folder may be pre-configured to be includes in a specified subspace or group of subspaces. Virtual file systems may each reference or include a same file or folder creating an intersection. Such an intersection may pre-specify an intersection between subspaces or access contexts for operating instances of operable entities in the intersection of two or more files or virtual files or of two or more folders or virtual folders. Any storage container may be utilized rather than or as an equivalent of a folder, such as a database table, an XML document, a named list or hierarchy, and the like.
Resources that may be included in a context set, in addition to or instead of resources identified elsewhere in the present disclosure, include data, a system, an apparatus, hardware (e.g. mechanical, electrical, etc.), or a user accessed via an interaction by or for an operating instance. A resource accessed by or for an operating instance may, at least in part, be a physical entity or may at least in part be a virtual entity realized by one or more physical entities. A physical entity may be alive or not. In an automobile, an operating gasoline engine may, as an operating instance, access gas, as a resource, from a gas tank. The gas tank may also a resource for the operating gasoline engine. In a computing environment, physical processor memory, virtual processor memory, a persistent storage device, network hardware, a processor, a computing process, virtual circuitry operated when a processor accesses and executes code stored in a processor memory, and the like are each an example of a resource when accessed by or for an operating instance. For example, a signal propagated by a communications medium may be a resource accessed by or for an operating instance. Data stored on a hard drive may be a resource. Neither the signal nor the data is an operating instance. Exemplary resources with respect to various operating instances include a cache memory, a system bus, a switching fabric, an input device, an output device, a network protocol, an interrupt, a semaphore, a pipe, a queue, a stack, a data segment, a memory address space, a file system, a network address space, a URI, an image capture device, an audio output device, a user, a database, a persistent data store, a semaphore, a pipe, a socket, a processor, a memory manager, a scheduler, a process, a thread, an executable maintained in a library, a data store, a data storage medium, a file, a directory, a file system, user data, authorization data, authentication data, a stack, a heap, a queue, an interprocess communication mechanism (e.g. a stream, a pipe, an interrupt, etc.), a synchronization mechanism (e.g. a lock, a semaphore, an ordered list, etc.), an input device, a networking device, a device driver, a network protocol, a link or reference, a linker, a loader, a compiler, an interpreter, a sensor, an address space, an addressable space, an invocation mechanism, a memory mapper, a security model or a security manager, a GPS client or server, a web server, a browser, a container (such as a LINUX container), a virtual machine, a framework (such as a MESOS framework or an OMEGA framework), a scheduler, a timer, a clock, a code segment, a data segment, boot logic, shutdown logic, a cache, a buffer, a processor register, a log, a tracing mechanism, a registry, a network adapter, a line card, a kernel, a security ring, a policy, a policy manager, encryption hardware or software, a routing/forwarding/relaying mechanism, a data base, a user communications agent (e.g. Email, instant messaging, voice, etc.), a distributed file system, a distributed memory mechanism, a shared memory mechanism, a broadcast mechanism, a display, graphics hardware, a signal, a pipe, a stream, a socket, a physical memory, a virtual memory, a virtual file system, a command line interface, and loadable logic code or data (e.g. a dynamic link library), or metadata for any of the foregoing. Examples of metadata include a state, a condition, an amount, a duration, a time, a date, a rate, an average, a measure of dispersion, a maximum, a minimum, a temperature, a velocity, an acceleration, a weight, a mass, a count, an order, or an ordering—to name a few examples.
One or more operating instances in a computing environments may operate for process management, thread management, memory management, input/output device management, virtual machines, kernels, storage management, security management, network management, user interface management, data storage, data exchange via a network, presenting output, detecting input, operatively coupling to a peripheral device or a peer device, providing power, generating heat, dissipating heat, and the like. Each may operate as a member of zero, one, or more access contexts.
The various embodiments described herein along with the equivalents or analogs may be realized in various operating environments. An “operating environment” (operating environment), as used herein, is an arrangement of physical entities and/or virtual entities that include or that may be configured to include an embodiment of the subject matter of the present disclosure. An operating environment may, as indicated, include one or more virtual entities represented or otherwise realized in one or more physical entities. For example, physical electronic circuitry is a physical entity that includes one or more electronic circuits designed and built to perform an operation, task, or instruction. An example of a virtual entity, is “virtual circuitry” or logic that is realized in one or more physical electronic circuits, such as the physical circuitry included in a memory device, in a wired or wireless network adapter, or in special purpose or general purpose instruction execution circuitry as described in more detail below. All embodiments of the subject matter of the present disclosure include one or more physical entities that access or utilize one or more physical resources. Embodiments of the subject matter of the present disclosure that provide, transmit, or receive electrical power include electronic circuitry which may include circuitry that is not programmable or may include circuitry that is programmable but that does not embody a Turing machine. Some embodiments may include programmable circuitry that embodies a Turing machine for realizing virtual circuitry. Virtual circuitry may be represented in a memory device or in a data transmission medium, for example as code. Virtual circuitry may be emulated or realized by physical circuitry. For example, virtual circuitry may be specified in data accessible to physical circuitry that emulates the virtual circuitry by processing the data. Such data may be stored or otherwise represented, for example, in a memory device or in a data transmission medium coupled to the physical circuitry to allow the physical circuitry access to a data representation of the virtual circuitry to emulate the operation of the virtual circuitry. A computing process is an example of a virtual resource that represents virtual circuitry that in operation may be emulated or realized by programmable physical circuitry per a data representation of the virtual circuitry.
Virtual circuitry may be represented by data that is a translation of source code written in a programming language. An operating environment may include software accessible to a processor as machine code that operates virtual circuitry. An operating environment may include or may be provided by one or more devices that include one or more processors to execute instruction(s) to operate virtual circuitry. An operating environment that includes a processor is referred to herein as a “computing environment”. In an aspect, a computing environment may include an operating system, such as WINDOWS, LINUX, OSX, OS360, and the like. In an aspect, an operating environment, which may be or may include a computing environment, may include one or more operating systems.
Processor 8604 may access instructions and data via one or more memory address spaces in addition to the physical memory address space. A memory address space includes addresses identifying locations in a “processor memory”. The addresses in a memory address space of a processor are included in defining a processor memory of the processor. Processor 8604 may have more than one processor memory. Thus, processor 8604 may have more than one memory address space. Processor oe0004 may access a location in a processor memory by processing an address identifying the location. The processed address may be identified by an operand of an instruction or may be identified by a register or other portion of physical processor memory 8606.
An address space including addresses that identify locations in a virtual processor memory is referred to as a “virtual memory address space”; its addresses are referred to as “virtual memory addresses”; and its processor memory is referred to as a “virtual processor memory” or “virtual memory”. The term, processor memory, may refer to physical processor memory, such as physical processor memory 8606 or may refer to virtual processor memory, such as virtual physical processor memory 8606, depending on the context in which the term is used.
Physical processor memory 8606 may include various types of memory technologies. Exemplary memory technologies include static random access memory (SRAM), Burst SRAM or Synchburst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Datan output RAM (EDO RAM), Extended Datan output DRAM (EDO DRAM), Burst Extended Datan output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDEC SRAM, PC SDRAM, Double Data rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synclink DRAM (SLDRAM), Ferroelectric RAM (FRAM), RAMBUS DRAM (RDRAM) Direct DRAM (DRDRAM), or XDRTM DRAM. Physical processor memory 8606 may include volatile memory as illustrated in the previous sentence or may include non-volatile memory such as non-volatile flash RAM (NVRAM) or ROM.
Persistent secondary storage 8608 may include one or more flash memory storage devices, one or more hard disk drives, one or more magnetic disk drives, or one or more optical disk drives. Persistent secondary storage 8608 may include a removable data storage medium. The drives and their associated computer readable media provide volatile or nonvolatile storage for representations of computer-executable instructions, data structures, software components, and other data. The computer readable instructions may be loaded into a processor memory as instructions executable by a processor.
Computing environment 8600 may include virtual circuitry specified in software components stored in persistent secondary storage 8608, in remote storage accessible via a network, or in a processor memory.
Computing environment 8600 may receive user-provided information via one or more input devices illustrated by an input device 8628. Input device 8628 may provide input information to other components in computing environment 8600 via an input device adapter 8610 which may be included in computing environment 8600. An input device adapter 8610 may be included for one or more of a keyboard, a touch screen, a microphone, a joystick, a television receiver, a video camera, a still camera, a scanner, a fax, a phone, a modem, a network interface adapter, or a pointing device, to name a few exemplary input devices. An input device 8626 included in computing environment 8600 may be included in device 8602 as
An output device 8628 in
A device included in or otherwise providing an operating environment may operate in a networked environment interoperating with one or more other devices via one or more network interface components.
Exemplary devices included in or otherwise providing suitable operating environments that may be adapted, programmed, or otherwise modified according to the subject matter include a workstation, a desktop computer, a laptop or notebook computer, a server, a handheld computer, a smartphone, a mobile telephone or other portable telecommunication hardware, a media playing hardware, a gaming system, a tablet computer, a portable electronic device, a handheld electronic device, a multiprocessor device, a distributed system, a consumer electronic device, a router, a switch, a bridge, a network server, any other type or form of computing, telecommunications, network, a media device, a transportation vehicle, a building, an appliance, a human wearable entity, a lighting device, a networking device, a manufacturing device, a test device, a sensor, a musical instrument, a printing device, a vision device, a netbook, a cloud book, a mainframe, a supercomputer, a wearable computer, a minicomputer, an air conditioner, a clock, an answering machine, a blender, a blow dryer, a security system, a calculator, a camera, a can opener, a cd player, a fan, a washer, a dryer, coffee grinder, coffee maker, an oven, a copier, a crock pot, a curling iron, a dishwasher, a doorbell, a lawn edger, an electric blanket, a power tool, a cordless power tool, a musical instrument, a pencil sharpener, an electric razor, an electric toothbrush, an espresso maker, a smoke detector, a carbon monoxide detector, a flashlight, a television, a food processor, a source of electrical energy, a source of non-electrical energy, a freezer, a furnace, a heat pump, a garage door opener, a garbage disposal, a GPS device, an audio recording device, an audio playing device, a humidifier, an iron, a light, lawn equipment, a leaf blower, a microwave oven, a mixer, a printer, a radio, a cook-top, a refrigerator, a scanner, a toaster, a trash compactor, a vacuum cleaner, a vaporizer, a VCR, a video camera, a video game machine, a watch, a water heater, a DVD player, a game console, a robot, a sump pump, a watch, a heart monitor or other body monitors, smart eyewear, an insulin pump, and a pacemaker, It will be understood by those skilled in the art based on the present disclosure that the foregoing list is not exhaustive. Those skilled in the art will understand that the components illustrated in
Coupled to the network 8702 is a plurality of devices. For example, a server node 8704 (e.g. of a web service or a cloud-based service) and an end user node 8704, also referred to as a client node, and a relay/routing node 8706 may be coupled to the network 8702 for purposes of exchanging data. An end user node 8704 may include a desktop computer, lap-top computer, or any other type of resource accessor including network interface hardware such as a wired or wireless adapter.
Other exemplary devices that may be coupled to the network 8702 include a personal digital assistant (PDA) resource accessor, a mobile phone device, a television, a media capture device, a media playing device, a home appliance (e.g. a thermostat, a refrigerator, a stove, an oven, a light which may include an LED, a power outlet, a power storage device, a power generating device), circuitry included in a construction material (e.g. a sheet rock panel, a wall or ceiling support, etc.), a fan, a filter, a pump, a cooling device, a heating device, a self-propelled vehicle, or an automotive vehicle—among others.
Use of the terms “a” and “an” and “the” and similar referents in the context of describing the subject matter (particularly in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context.
The use of all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illustrate the subject matter and does not pose a limitation on the scope of the subject matter unless otherwise claimed. The use of the term “based on” and other like phrases indicating a condition for bringing about a result, both in the claims and in the written description, is not intended to foreclose any other conditions that bring about that result. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the subject matter as claimed.
The use of “including”, “comprising”, “having”, and variations thereof are meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof.
The term “or” in the context of describing the subject matter (particularly in the context of the following claims) is to be construed to be, as used herein, inclusive. That is, the term “or” is equivalent to “and/or” unless otherwise indicated herein or clearly contradicted by context.
Terms used to describe interoperation or coupling between or among parts are intended to include both direct and indirect interoperation or coupling, unless otherwise indicated. Exemplary terms used in describing interoperation or coupling include “mounted,” “connected,” “attached,” “coupled”, “communicatively coupled,” “operatively coupled,” “invoked”, “called”, “provided to”, “received from”, “identified to”, “interoperated” and similar terms and their variants.
As used herein, any reference to an entity “in” an association or relationship is equivalent to describing the entity as “included in or identified by” the association or relationship, unless explicitly indicated otherwise.
In various implementations of the subject matter of the present disclosure, circuitry for “sending” an entity is referenced. As used herein “sending” may refer to providing via a network or making accessible via a shared data area, a stack, a queue, a pointer to a memory location, an interprocess communication mechanism, and the like. Similarly, in various implementations of the subject matter of the present disclosure, circuitry for “receiving” an entity as use herein may include receiving or otherwise accessing via a network, gaining access via a network or making accessible via a shared data area, stack, a queue, a pointer to a memory location, an interprocess communication mechanism, and the like. Circuitry for “exchanging” may include circuitry for sending or for receiving. In various implementations of the subject matter of the present disclosure, circuitry for “identifying” as use herein may include, without being exhaustive, circuitry for accessing, sending, receiving, exchanging, detecting, creating, modifying, translating, or transforming. In various implementations of the subject matter of the present disclosure, circuitry for “detecting” as use herein may include, without being exhaustive, circuitry for accessing, sending, receiving, exchanging, identifying, creating, modifying, translating, or transforming.
As used herein a “processor” may be an instruction execution machine, apparatus, or device. A processor may include one or more electrical, optical, or mechanical parts that when executed operate in interpreting and executing data that specifies virtual circuitry (i.e. circuitry), typically generated from code written in a programming language. Exemplary processors include one or more microprocessors, digital signal processors (DSPs), graphics processing units (GPUs), application-specific integrated circuits (ASICs), optical or photonic processors, or field programmable gate arrays (FPGAs). A processor in an operating environment may be a virtual processor emulated by one or more physical processors. A processor may be included in an integrated circuit (IC), sometimes called a chip or microchip. An IC is a semiconductor wafer on which thousands or millions of resistors, capacitors, and transistors are fabricated. An IC can function as an amplifier, oscillator, timer, counter, computer memory, or processor. A IC may be categorized as linear (analog) or digital, depending on its intended application.
A “virtual operating environment” (VOE) operates in another operating environment, referred to as a “host operating environment” with respect to the virtual operating environment. With respect to computing environments, Linux and Windows virtual machines are examples of virtual operating environments. The term “virtual machine” (VM) as used herein may refer to an implementation that emulates a physical machine (e.g., a computer). A VM that includes an emulation of a processor is a virtual operating environment provided by a host operating environment where the host operating environment includes a processor realized in hardware. VMs provide hardware virtualization. Another category of virtual operating environment is referred to, herein, as a “process virtual environment” (PVE). A PVE includes a single computing process. A JAVA VM is an example of a process virtual environment. PVEs are typically tied to programming languages. Still another exemplary type of virtual operating environment is a “container operating environment” (COE). As used herein, a container operating environment may be a partition of a host operating environment that isolates an executing of circuitry, such as in a computer program, from other partitions. For example, a single physical server may be partitioned into multiple small partitions that each execute circuitry for respective web servers. To circuitry, such as circuitry implementing a web server, operating in a partition (COE); the partition appears to be an operating environment. Container operating environments are referred to in other contexts outside the present disclosure as virtual environments (VE), virtual private servers (VPS), guests, zones, containers (e.g. Linux containers), etc. At least one of a resource utilized by a resource accessor (e.g. task circuitry) and a resource provider that allows the resource accessor to access the resource (e.g. a task operating environment or task host circuitry) may be included in a virtual operating environment.
An operating instance in an operating environment may access one or more resources of the operating environment or accessible via the operating environment. As illustrated by the description of access contexts above, access to one or more of the resources may be changed or access to one or more resources may be changed when an operating instance is a member of an access context. The one or more resources changed or for which access may be changed are context resources of the access context. The set of context resources is referred to herein as a context set of the access context. A subspace may be a type of access context. A member of an access context is an operating instance that operates at least partially in the access context. An access context, as described, may have a “context set” that includes context resources of the access context. The access context, as described, may also have a member set that includes operating instances that operate at least partially in the access context and are members of the access context. An access context specifies a relationship between a context resource in a context set of the access context and an operating instance that is a member of a “member set” of the access context. A “member set” may include or zero or more operating instances of zero of more operable entities at any time. In an embodiment, a member set may by dynamic changing over time. A member set may be pre-specified and may also be static (i.e. unchangeable). In an embodiment, a members of a member set may be specified by one or more operable entities. An operating instance of a specified operable entity may be a member of an access context when the member set is defined based on one or more identified operable entities. An additional criterion may be specified for an access context so that only operating instances of a specified operable entity that meet the specified criterion may be members of the member set. An operating instance may be included in more than one member set of more than one respective access context. An operable entity may have an operating instance in a first members set of a first access context and a second operating instance in a second member set of a second access context.
A context set may identify one or more context resources. A resource may be accessed by or for an operating instance operating in the context of an operating environment. A context resource may be, alternatively or additionally, accessed by or for the operating instance when operating at least partially in the access context. In an embodiment, an access context may allow access to a context resource that is otherwise not accessible as a resource in an operating environment. Alternatively or additionally, an access context may allow access to a context resource rather than a resource accessible in the operating environment. Still further, an access context may constrain or change access to a resource accessible without the change or with a different constraint when accessed in the operating environment. An access context may alter a resource or may alter access to resource (i.e. the resource is a context resource) for a member of the access context.
In an embodiment, an access context may alter no resources not included in the context set nor alter access to any resources not included in the context set of the access context. An access context changes some or all of an operating environment of an operating instance member depending on the resources in the context set. When an access context modifies a portion of resources or modifies access to a portion of resources accessible otherwise in an operating environment for an operating instance member, a “partial operating environment” for the member is realized via the access context.
An access context may modify a resource, substitute a resource, or modify access to a resource by replacing a default setting of an operating environment of the operating instance and of the access context, replacing a default setting of an operable entity for an operating instance that is a member of the access context, altering or replacing a resource accessed by, accessed for, or included in an operating instance of an operable entity, specifying a security constraint for a resource access, specifying a resource to access when an operating environment provides multiple suitable resources (e.g. an access context may include a subset of processors in its context resources set of a set of processors accessible an operating environment to an operating instance of an operable entity), change a constant setting accessible via an operating environment to a variable setting settable via one or more mechanisms, constrain a number of times a resource may be accessed by an member or by the member set of an access context, constrain a time or duration of access to a resource, modify a source of resource such a default file system or a averment path, specify minimum number of accesses or resources accessed for a member or for a member set, change default application for processing an access resource, or change or constrain access to one or more network nodes or other network resources. Other types of changes, substitutions, and constraints are described elsewhere in the present disclosure. In an embodiment, an operating instance of an operable entity may have access to resource only when the operating instance is a member of a subspace has a context set that includes the resources. Some operable entities may have operating instances that perform an operation only in the context of one or more access contexts or types of access contexts. Note that one or more a device, a process, an operating environment, another access context, or a thread whether in an environment of an operating instance or in an another accessible environment may be context resources in an access context. Access contexts may be configured to specify and manage access to resources in cloud computing systems and other types of distributed or network based systems such as client-server systems.
An access context may affect access by a member to resources accessed by or for exchanging data via a network, accessed by or for storing or retrieving data from a memory device, accessed in executing executable instructions, accessed in an interaction with a user, and the like. Examples of resources accessed in exchanging data via a network include a network interface, a network, or protocol endpoint. other network entity whether physical or virtual. A context set may identify an access context or a type of access context. An access context may be assigned an identifier such as a name, a number, an image, a character string, or an identifier from any identifier space selected for an embodiment by a developer, user, administrator, or other authority. Identifiers are resources in and of themselves and may be context resources for an access context. Other resources that may be included in a context set of an access context include hard drives, file systems, files, CCEs, operating environments, security roles, processors, and identifiers of each of the foregoing. It will be understood that this listing is not exhaustive.
As used herein, the term “addressable entity” may refer to any entity specified in source code written in a programming language. An addressable entity specified in source code may be translated into one or more other representations such as a different programming language, object code, virtual circuitry, or circuitry. An addressable entity may be translated to object code stored in an application file or code library in a data store such as a file system. The addressable entity may be translated from the object code to machine code stored in a processor memory of a processor. The addressable entity may be processed or realized as virtual circuitry by a processor accessing the machine code via the processor memory and realizing the addressable entity as virtual circuitry by processing the machine code. An addressable entity may include an instruction carried out by the processor or may include data processed as one or more operands of one or more machine code instructions carried out by the processor. An addressable entity may include circuitry. An addressable entity may include a circuit or may be specified in machine code, object code, byte code, or source code—to name some examples. Object code includes a set of instructions or data elements that either are prepared to link prior to loading or are loaded into an operating environment. When in an operating environment, object code may include references resolved by a linker or may include one or more unresolved references. The context in which this term is used will make clear the state of the object code when it is relevant. An addressable entity may include one or more addressable entities. As used herein, the terms “application”, “service”, “subsystem”, and “library” include one or more addressable entities accessible to a processor via a data storage medium or may be realized in one or more hardware parts. An addressable entity may be defined, referenced, or otherwise identified by source code specifiable in a programming language. An addressable entity is addressable by a processor when translated from the source code and loaded into a processor memory of the processor in an operating environment. Examples of addressable entities include variables, constants, functions, subroutines, procedures, modules, methods, classes, objects, code blocks, and labeled instructions. A “code block” includes one or more instructions in a given scope specified in a programming language. An addressable entity may include a value. Addressable entities may be written in or translated to a number of different programming languages or representation languages. An addressable entity may be specified in or translated into source code, object code, machine code, byte code, or any intermediate language for processing by an interpreter, compiler, linker, loader, or analogous tool. Some addressable entities include instructions executed by a processor.
A “programming language” is defined for expressing data or operations (in one or more addressable entities) in source code written by a programmer or generated automatically from an identified design pattern or from a design language, which may be a visual language specified via a drawing. The source code may be translated into instructions or into data that are valid for processing by an operating environment to emulate a virtual circuit or virtual circuitry. For example, a compiler, linker, or loader may be included in translating source code into machine code that is valid for a type of processor in an operating environment. A programming language is defined or otherwise specified by an explicit or implicit schema that identifies one or more rules that specify whether source code is valid in terms of its form (e.g. syntax) or its content (e.g. vocabulary such as valid tokens, words, or symbols). A programming language defines the semantics or meaning of source code written in the programming language with respect to an operating environment in which a translation of the source code is executed. Source code written in a programming language may be translated into a “representation language”. As used herein, a “representation language” is defined or otherwise specified by an explicit or implicit schema that identifies at least one of a syntax and a vocabulary for a scheduled translation of source code that maintains the functional semantics expressed in the source code. Note that some programming languages may serve as representation languages. Exemplary types of programming languages for writing or otherwise expressing source code include array languages, object-oriented languages, aspect-oriented languages, assembler languages, command line interface languages, functional languages, list-based languages, procedural languages, reflective languages, scripting languages, and stack-based languages. Exemplary programming languages include C, C#, C++, FORTRAN, COBOL, LISP, FP, JAVA®, APL, PL/I, ADA, Smalltalk, Prolog, BASIC, ALGOL, ECMAScript, BASH, and various assembler languages. Exemplary types of representation languages include object code languages, byte code languages, machine code languages, programming languages, and various other translations of source code.
A “user interface element” (UI element), as used herein may refer to a user-detectable output of an output device of an operating environment. A user interface element may be a visual output in a graphical user interface (GUI) presented via a display device. Exemplary user interface element elements include icons, image data, graphical drawings, font characters, windows, textboxes, sliders, list boxes, drop-down lists, spinners, various types of menus, toolbars, ribbons, combo boxes, tree views, grid views, navigation tabs, scrollbars, labels, tooltips, text in various fonts, balloons, dialog boxes, and various types of button controls including check boxes, and radio buttons. An application user interface may include one or more of the user interface elements listed. Those skilled in the art will understand that this list is not exhaustive. The terms “visual representation”, “visual output”, and user interface element, as outputs of a display device, are used interchangeably herein. Other types of user interface elements include audio outputs referred to as “audio interface elements”, tactile outputs referred to as “tactile interface elements”, and the like.
A user interface element may be stored or otherwise represented in an output space. The term “output space”, as used herein, may refer to memory or other medium allocated or otherwise provided to store or otherwise represent output information. Output information may include audio, visual, tactile, or other sensory data for presentation via an output device. For example, a memory buffer to store an image or text string for presenting to a user may be an output space. An output space may be physically or logically contiguous or non-contiguous. An output space may have a virtual as well as a physical representation. An output space may include a storage location in a processor memory, in a secondary storage, in a memory of an output adapter device, or in a storage medium of an output device. A screen of a display, for example, may, in operation, include an output space. In various embodiments, a display may be included in a mobile device (e.g., phone, tablet, mobile entertainment device, etc.), a fixed display device (e.g., within a vehicle, computer monitor, a non-portable television, etc.), or any other display element, screen, or projection device which may present a visual output to a user.
A “subspace”, as described herein, is an output space that may be included, in whole or in part, in a portion of another output space. A subspace may include one or more of user interface elements that are included respectively in user interfaces of one or more respective operating instances. An operating instance may be an operating of one or more operable entities. Examples of operable entities include applications, operating systems, operating environments, devices, hibernated computing processes, hibernating threads, dynamic and static link libraries accessible as object code from a data store or accessible as machine code in a processor memory, a network adapter, a disk drive, and so on. An operable entity includes a physical entity of a virtual entity. A subspace, thus, identifies a set of user interface elements and a corresponding set of operating instances. An operating instance of an operable entity may include a process that operates in an operating environment, a thread of a process in an operating environment that supports threaded processes, an instance of an application which may include one or more processes operating in one or more operating environments of one or more devices, an operating device, an operating instance of an operating system such as WINDOWS or LINUX, an identified portion of an operating environment such as a LINUX container, or a task assigned to an operating environment or device in a cloud computing environment such as BORG, OMEGA, KUBERNETES, and the like.
A subspace may include or otherwise access structured data or circuitry for monitoring or modifying a user interface element set in the subspace. A subspace may be a resource accessed by or for circuitry of a user interface handler of an operating instance to interact with a user via a user interface element of the operating instance that is presented in the subspace. A subspace may include or provide access to one or more other resources included in modifying or monitoring user interface elements, of operating instances, that are in the subspace. A resource may be embodied as data, code, or circuitry that is accessed by or for monitoring or modifying a user interface element in the subspace. The resource may be accessed directly or indirectly by circuitry of the subspace or circuitry of the operating instance of the user interface element, such as circuitry of a user interface handler. An embodiment, may include data, code, or circuitry that operates in monitoring, creating, removing, modifying, or otherwise processing the subspace or other attribute of the subspace accessible by or for monitoring or modifying a user interface element in the subspace. Data or circuitry of a subspace may specify a configurable attribute of a user interface element in the subspace or of the operating instance of the user interface element. Data or circuitry of a subspace may specify a policy, a schema, or circuitry accessible for monitoring or modifying a user interface element in the subspace.
An order of visual outputs in a dimension is herein referred to as an order in that dimension. For example, an order with respect to a Z-axis is referred to as a “Z-order”. The term “Z-value” as used herein may refer to a location in a Z-order. A Z-order specifies the front-to-back or back-to-front ordering of visual outputs in an output space with respect to a Z-axis. In one aspect, a visual output with a higher Z-value than another visual output may be defined to be on top of or closer to the front than the other visual output. In another aspect, a visual output with a lower Z-value than another visual output may be defined to be on top of or closer to the front than the other visual output. For ease of description the present disclosure defines a higher Z-value to be on top of or closer to the front than a lower Z-value.
A “user interface handler” (UI handler), as the term is used herein, may refer to one or more addressable entities that include circuitry (virtual or physical) to send information to present an output via an output device, such as a display. A user interface handler, additionally or alternatively, may also include circuitry to process input information that corresponds to a user interface element. The input information may be received by the user interface handler in response to a user input detected via an input device of an operating environment. Information that is transformed, translated, or otherwise processed by circuitry in presenting a user interface element by an output device is referred to herein as “output information” with respect to the circuitry. Output information may include or may otherwise identify data that is valid according to one or more schemas (defined below). Exemplary schemas for output information are defined data such as raw pixel data, JPEG for image data, video formats such as MP4, markup language data such as defined by a schema for a hypertext markup language (HTML) and other XML-based markup, a bit map, or instructions (such as those defined by various script languages, byte code, or machine code)—to name some examples. For example, a web page received by a browser may include HTML, ECMAScript, or byte code processed by circuitry in a user interface handler to present one or more user interface elements.
An “interaction”, as the term is used herein, may refer to any activity including a user and an object where the object is a source of sensory data detected by the user or the user is a source of input for the object. An interaction, as indicated, may include the object as a target of input from the user. The input from the user may be provided intentionally or unintentionally by the user. For example, a rock being held in the hand of a user is a target of input, both tactile and energy input, from the user. A portable electronic device is a type of object. In another example, a user looking at a portable electronic device is receiving sensory data from the portable electronic device whether the device is presenting an output via an output device or not. The user manipulating an input of the portable electronic device exemplifies the device, as an input target, receiving input from the user. Note that the user in providing input is receiving sensory information from the portable electronic. An interaction may include an input from the user that is detected or otherwise sensed by the device. An interaction may include sensory information that is received by a user included in the interaction that is presented by an output device included in the interaction.
As used herein, the term “network protocol” may refer to a set of rules, conventions, or schemas that govern how nodes exchange information over a network. The set may define, for example, a convention or a data structure. Those skilled in the art will understand upon reading the descriptions herein that the subject matter disclosed herein is not restricted to the network protocols described or their corresponding OSI layers or other architectures (such as a software defined network (SDN) architecture). The term “network path” as used herein may refer to a sequence of nodes in a network that are communicatively coupled to transmit data in one or more data units of a network protocol between a pair of nodes in the network. The terms “network node” and “node” herein both refer to a device having a network interface hardware capable of operatively coupling the device to a network. Further, the terms “device” and “node” in the context of providing or otherwise being included in an operating environment refer respectively, unless clearly indicated otherwise, to one or more devices and nodes.
As used herein, the term “user communication” may refer to data exchanged via a network along with an identifier that identifies a user, group, or legal entity as a sender of the data. Alternatively or additionally, a receiver of the data. The identifier is included in a data unit of a network protocol or in a message of an application protocol transported by a network protocol. The application protocol is referred to herein as a “user communications protocol”. The sender is referred to herein as a “contactor”. The receiver is referred to herein as a “contactee”. The terms “contactor” and “contactee” identify roles of “communicants” in a user communication. The contactor and the contactee is each a “communicant” in the user communication. An identifier that identifies a communicant in a user communication is referred herein as a “communicant identifier”. The terms “communicant identifier” and “communicant address” are used interchangeably herein. A communicant identifier that identifies a communicant in a user communication exchanged via a user communications protocol is said to be in an identifier space or an address space of the user communications protocol. The data in a user communication may include text data, audio data, image data, or instruction data. A user communications protocol defines one or more rules, conventions, or vocabularies for constructing, transmitting, receiving or otherwise processing a data unit of or a message transported by the user communications protocol. Exemplary user communications protocols include a simple mail transfer protocol (SMTP), a post office protocol (POP), an instant message (IM) protocol, a short message service (SMS) protocol, a multimedia message service (MMS) protocol, a Voice over IP (VOIP) protocol, internet mail access protocol (IMAP), and hypertext transfer protocol (HTTP). Any network protocol that specifies a data unit or transports a message addressed with a communicant identifier is or may operate as a user communications protocol. In a user communication, data may be exchanged via one or more user communications protocols. Exemplary communicant identifiers include email addresses, phone numbers, multi-media communicant identifiers such as SKYPE® IDs, instant messaging identifiers, MMS identifiers, and SMS identifiers. Those skilled in the art will see from the preceding descriptions that a URL may serve as a communicant identifier.
The term “user communications agent” may refer to circuitry which may be included in an application that may operate in an operating environment to receive, on behalf of a contactee, a communicant message addressed to the contactee by a communicant identifier in the user communication. The user communications agent interacts with the contactee communicant in presenting or otherwise delivering the communicant message. Alternative or additionally, a user communications agent operates in an operating environment to send, on behalf of a contactor, a communicant message in a user communication addressed to a contactee by a communicant identifier in the user communication. A user communications agent may operate on behalf of a communicant in the role of a contactor or a contactee as described above is said, herein, to “represent” the communicant. A user in the role of a communicant interacts with a user communications agent to receive data addressed to the user in a user communication. Alternatively or additionally, a user in the role of a communicant interacts with a user communications agent to send data addressed to another communicant in a user communication.
A “communicant message” may refer to data spoken, written, or acted by a contactor for a contactee. The data is received by a user communications agent representing the contactor and is further received or to be received in a communication by a user communications agent to present via an output device to the contactee identified in the communication by a communicant identifier. Examples of communicant messages include text written by a contactee in an email or an instant message and a spoken message by a contactee included in an audio communication by a VoIP client. To be clear attachments, data unit headers, message headers, communication session control data, or connection data for setup and management of a communication are not communicant messages as defined herein.
The term “communicant alias” as used herein may refer to an identifier of a communicant in a communication where the communicant alias is not a communicant identifier in an address space of a communication protocol via which the communication is exchanged.
The term “attachment” as used herein may refer to data, that is not a communicant message, exchanged in a communication from a sending user communications agent or communications service to a recipient user communications agent or communications service. An attachment may be, for example, a copy of a file stored or otherwise represented in a file system or in another data store in an operating environment that includes a user communications agent included in exchanging the attachment in a communication. A resource sent as an attachment is data that is typically not presented “inline” in a communicant message. Email attachments are perhaps the most widely known attachments included in communications. An email attachment may be a file or other data entity sent in a portion of an email separate from a communicant message portion. As defined, other communicant messages may be sent in other types of communications along with one or more attachments.
A “user communications request”, as the term is used herein, may refer to a request sent by a user communications agent via a user communications protocol. A “user communications response”, as the term is used herein, may refer to any response corresponding to a user communications request. A user communications response may be transmitted via the same user communications protocol as its corresponding user communications request, a different user communications protocol, a web protocol, or via any other suitable network protocol. A “user communications service”, as the term is used herein, may refer to a recipient of a user communications request that is included in performing the request. Performing the request may include sending a service request based on the user communications request to a service application included in performing the request. A user communications service or a service application included in performing a user communications request may generate a user communications response to the request. “Service application”, as the term is used herein, may refer to any application that provides access to a resource. “Resource”, as the term is used herein, may refer to a data entity, a hardware part, an addressable entity, or service. A service request is a request to a service application to get, create, modify, delete, move, or invoke a resource. A response to a service request is referred to as a service response. Data in a service response is a resource. A communications request is a type of service request.
A “web protocol”, as the term is used herein, may refer to any version of a hypertext transfer protocol (HTTP) or any version of a HTTP secure (HTTPS) protocol. A “web request”, as the term is used herein, may refer to a request initiated by a user agent. A “web service”, as the term is used herein, may refer to a recipient of a web request. A web service generates a response to the request. A “web response”, as the term is used herein, may refer to any response that corresponds to a web request. A web response may be transmitted via the same web protocol as its corresponding web request, a different web protocol, via a user communications protocol, or via any other suitable network protocol. A web request is a type of service request.
A “service provider”, as the term is used herein, may refer to any entity that owns, maintains, or otherwise provides a service application such as a web service, user communications service, or other network accessible application. The term “service site” is used interchangeably with services and facilities that host a web service or other application of a service provider. For example, a service provider system may include a server farm, a content delivery network, a database, a firewall, etc.
The terms “user agent” and “service application” refer to roles played by one or more addressable entity, hardware parts, or devices operating in an operating environment, or systems in a data exchange. A “user agent” initiates or sends a command, such as a HTTP request. A “service application” accepts a command identified in a request in order to process the command. Processing a command includes performing or otherwise providing for performing an operation based on the command. The performing of the command may be successful or unsuccessful. As defined and described herein a server node may send information in a response, such as an HTTP response, to a user agent in response to receiving a command from the user agent in a request. A service application may also send a message via an asynchronous protocol or a portion of protocol that allows an asynchronous exchange via a network. Examples of applications that may include or may otherwise interoperate with a user agent include web browsers, HTML editors, spiders (web-traversing robots), or other end user tools. Note also that a protocol service, such an HTTP protocol service, is a user agent as the term is defined herein. While the present disclosure focuses the use of HTTP by user agents and server nodes and in some cases user agent clients (defined below), those skilled in the art will understand based on the descriptions and drawings provided herein that the methods described herein may be adapted to utilize other network protocols or other application s protocols instead of or in addition to HTTP and circuitry in a systems described herein and their variants may be modified to operate in performing the adapted methods.
The term “schema”, as used herein refers one or more rules that define or otherwise identify a type of resource. The one or more rules may be applied to determine whether a resource is a valid resource of the type defined by the schema. Schemas may be defined in various languages, grammars, or formal notations. For example, an XML schema is a type of XML document. The XML schema identifies documents of that conform to the one or more rules of the XML schema. For instance, a schema for HTML defines or otherwise identifies whether a given document is a valid HTML document. A rule may be expressed in terms of constraints on the structure (i.e. The format) and content (i.e. The vocabulary) of resources of the type defined by the schema. Exemplary languages for specifying schemas include the World Wide Web Consortium (W3C) XML Schema language, Data Type Definitions (DTDs), RELAX NG, Schematron, the Namespace Routing Language (NRL), MIME types, and the like. XML schema languages define transformations to apply to a class of resources. XML schemas may be thought of as transformations. These transformations take a resource as input and produce a validation report, which includes at least a return code reporting whether the resource (e.g. a document) is valid and an optional Post Schema Validation Infoset (PSVI), updating the original resource's infoset (e.g. The information obtained from the XML document by the parser) with additional information (default values, data types, etc.). A general-purpose transformation language is thus a schema language. Thus, languages for building programming language compilers are schema languages and a programming language specifies a schema. A grammar includes a set of rules for transforming strings. As such, a grammar specifies a schema. Grammars include context-free grammars, regular grammars, recursive grammars, and the like. For context-free grammars, Backus Normal Form (BNF) is a schema language. With respect to data and a schema for validating the data, a “data element” as the terms is used herein refers at least a portion of the data that is identifiable by a parser processing the data according to the schema. A document or resource conforming to a schema is said to be “valid”, and the process of checking that conformance is called validation. Markup elements are data elements according to a schema for a markup language.
The term “criterion” as used herein may refer to any information accessible to circuitry in an operating environment for determining, identifying, or selecting one option over another via the execution of the circuitry. A criterion may be information stored in a location in a memory or may be a detectable event. A criterion may identify a measure or may be included in determining a measure such a measure of performance.
It will be appreciated that an embodiment may also be implemented on platforms and operating environments other than those mentioned. Of course, the various embodiments set forth herein may be implemented utilizing hardware, software, or any desired combination thereof. For that matter, any type of circuitry may be utilized which is capable of implementing the various features and functions set forth herein. It will be understood that various details may be combined, removed, or otherwise changed without departing from the scope of the claimed subject matter. It should be strongly noted that such illustrative information is set forth for illustrative purposes and should not be construed as limiting in any manner. Any of the aspects identified by the illustrative information may be optionally incorporated with or without the exclusion of any other of the aspects. The description herein of any sequence of actions is not intended to imply that the specific order described for performing that sequence must be followed.
Suitable operating environments for the various methods described in the present disclosure may include or may be provided by a network node. Suitable operating environments include host operating environments and virtual operating environments. Suitable operating environments may include more than one node such as an operating environment of a cloud computing system. Some or all of the code, hardware, or other resources included in performing any one or more of the methods described in the present disclosure may be adapted to operate in a number of operating environments. In an aspect, circuitry of such code may operate as a stand-alone application or may be included in or otherwise integrated with another application or software system.
For each method, circuitry to perform the method may be arranged in various optional arrangements of addressable entities. Circuitry in an implementation of each of method of the present disclosure may be a translation of or otherwise may be specifiable in source code written in a programming language. Each method of the present disclosure may be embodied in one or more of various suitable arrangements in an operating environment or distributed between or among multiple operating environments. It will be understood that other arrangements of circuitry for performing each method of the present disclosure may be implemented with the circuitry distributed among addressable entities that are included in or accessible to one or more computing processes or operating environments.
Those skilled in the art will understand based on the present disclosure that the methods described herein and illustrated in the drawings may be embodied utilizing algorithms that may each be specified in more detail in source code written in any of various programming languages per the desires of one or more programmers. The source code may be translated or otherwise transformed to circuitry, such as machine code, that is executable by a processor. Those skilled in the art will further understand that modern operating environments, programming languages, and software development tools allow a programmer numerous options in writing the source code that specifies in more detail an algorithm that implements a method. For example, a programmer may have a choice with respect to specifying an order for carrying out the operations specified in the method. In another example, a programmer may present a user interface element in any number of ways that are known to those skilled in the art. Details of the source code typically will depend on an operating environment which may include an operating system and user interface software library. Compilers, loaders, and linkers may rewrite the instructions specified in the source code. As such, with respect to an algorithm that implements a method, the number of possible algorithms increases or at least remains as large as the level of specificity increases. Specificity generally increases from software analysis languages to design languages to programming languages to object code languages to machine code languages. Note the term “language” in this paragraph includes visual modeling (e.g. a flow charts, class diagrams, user interface drawings, etc.). It would be impractical to identify all such algorithms specified at the level of analysis languages or at the level of design languages, but such specifications will be apparent to the population of those skilled in the art. Further, at least at some of all such specifications will be apparent or derivable based on the present disclosure to each member of the population. As such, the present disclosure is enabling and all such specifications of the methods/algorithms that may be written by those skilled in the art based on the descriptions herein or based on the drawings in an analysis language, a design language, a high-level programming language, or an assembler language are within the scope of the subject matter of the present disclosure. Further, all specifications generated by a tool from any of the user written specifications are also within the scope of subject matter of the present disclosure.
It will also be apparent to those skilled in the art the algorithms taught based on the descriptions herein, the drawings, and the pseudo-code are exemplary and that an architecture, design, or implementation for any of the methods described herein may be selected based on various requirements that may vary for an embodiment including or otherwise invoking the circuitry. Requirements may vary based on one or more resources in an operating environment, performance needs/desires of a user or customer, resources of a display device, resources of a graphics service if included in an operating environment, one or more user interface elements processed by the circuitry or otherwise affecting the processing of the circuitry, a programming language, an analysis language, a design language, a test tool, a field support requirement, an economic cost of developing and supporting the implemented circuitry, and the desires of one or more developers of the architecture, design, or source code that includes or accesses the implemented circuitry. It will be clear to those skilled in the art that in the present disclosure it would impractical to attempt to identify all possible operating environments, programming languages, development, and test tools much less identify all possible algorithms for implementing the various methods whether the algorithms are expressed in pseudo-code, flow charts, object oriented analysis diagrams, object oriented design diagrams, resource data flow diagrams, entity-relationship diagrams, resource structures, classes, objects, functions, subroutines, and the like.
The methods described herein may be embodied, at least in part, in executable instructions stored in a computer readable medium for use by or in connection with an instruction execution machine, system, apparatus, or device, such as a computer-based or processor-containing machine, system, apparatus, or device. As used here, a “computer readable medium” may include one or more of any suitable media for storing the executable instructions of an addressable entity in one or more forms including an electronic, magnetic, optical, and electromagnetic form, such that the instruction execution machine, system, apparatus, or device may read (or fetch) the instructions from the non-transitory or transitory computer readable medium and execute the instructions for carrying out the described methods. By way of example, and not limitation, computer readable media may comprise computer storage media and resource exchange media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, resource structures, addressable entities or other resources. Computer storage media includes, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology; portable computer diskette; Compact Disk Read Only Memory (CDROM), compact disc-rewritable (CDRW), digital versatile disks (DVD) or other optical disk storage; magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices; or any other medium which can be used to store the desired information and which can accessed by a device. Resource exchange media typically embodies computer readable instructions, resource structures, addressable entities, or other resources in a modulated resource signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated resource signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, resource exchange media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
The present application claims priority to U.S. Provisional Patent Application No. 62/516,276, titled “METHODS, SYSTEMS, AND COMPUTER PROGRAM PRODUCTS FOR INTERGRATING CONFIGURATION, MONITORING, AND OPERATIONS,” filed Jun. 7, 2017, the contents of which are incorporated herein by reference in their entirety for all purposes.
Number | Date | Country | |
---|---|---|---|
62516276 | Jun 2017 | US |