Access control for object instances

The present disclosure involves systems, software, and computer implemented methods for access control for object instances. A method includes receiving, at a cloud application, a user request associated with a user. The user request corresponds to an instance of a first application artifact type. Role assignments for the user are retrieved from a cloud platform and a determination is made that the role assignments grant permission to the first application artifact type to the user. A determination is made that a first instance-based access policy exists for the first application artifact type. A determination is made regarding whether the first instance-based access policy grants permission for the user to access the instance. The user request is serviced in response to determining that the first instance-based access policy grants permission for the user to access the instance. The use request is denied in response to determining that the first instance-based access policy does not grant permission for the user to access the instance.

BACKGROUND

An integration scenario can model integration and connectivity between two computing systems. Different computing systems can communicate, for example, in business to business (B2B) communication, electronic data interchange (EDI), or some other type of system-to-system or server-to-server communication. The modeling of an integration scenario can include the creation of a process model that describes the integration scenario. In an integration scenario, a sending component in a sending system can send a message to a receiving component in a receiving system. The receiving component may perform some processing on the message and may also initiate one or more downstream tasks to perform other processing in response to receipt of the message.

SUMMARY

The present disclosure involves systems, software, and computer implemented methods for access control for object instances. An example method includes: receiving, at a cloud application, a user request associated with a first user, wherein the user request corresponds to a first instance of an application artifact having a first artifact type; retrieving, from a cloud platform, role assignments for the first user; determining that the role assignments grant permission to the artifact type to the first user; determining that a first instance-based access policy exists for the artifact type; determining whether the first instance-based access policy grants permission for the first user to access the first instance of the application artifact; in response to determining that the first instance-based access policy grants permission for the first user to access the first instance of the application artifact, servicing the user request; and in response to determining that the first instance-based access policy does not grant permission for the first user to access the first instance of the application artifact, denying the user request.

A cloud-based integration platform may typically include many (e.g., thousands of) users working in parallel on different integration flows. A platform may provide a role-based authorization system that grants access to all or no objects of a specific type. Some organizations may desire more fine-grained access, such as restricting access to certain objects to users belonging to a certain line of business (LoB). For example, an organization may want to enforce that objects that include personally-identifiable data only be accessible by members of a human resource (HR) department. Such fine-grained access to objects may not be able to be enforced with just a role-based authorization mechanism. Some organizations may restrict access by using different tenants to separate different LoBs. However, such an approach may not be acceptable to all users or organizations, since multiple tenants generally increases setup and maintenance complexity and cost, which generally results in a higher TCO (Total Cost of Ownership), as compared to a single-tenant setup.

To allow customers to continue to use one tenant but restrict access to certain object instances, a generic mechanism can be used that provides object-instance-based access control. For example, administrators can configure rules to relate users to different object instances. These rules can be represented in access policies. An access policy can allow a user base to have conditional access to different kinds of object instances based on defined conditions on instance attributes. Access policies can be stored independently from referencing object instances. Access policies can be maintained using a web-based user interface and can be evaluated during each access to an object instance.

The subject matter described in this specification can be implemented to realize one or more of the following advantages. First, access rules for object instances can be stored independently from relevant object instances. Second, a customer can use a single tenant for cloud platform integration for multiple lines of business while defining access rules for object instances for different user groups. Third, a multi-step approach can be used to evaluate if an end-user has access to an object instance. Fourth, a graphical user interface can be provided to maintain access policy rules.

DETAILED DESCRIPTION

The following detailed description describes access control for object instances, and is presented to enable any person skilled in the art to make and use the disclosed subject matter in the context of one or more particular implementations. Various modifications, alterations, and permutations of the disclosed implementations can be made and will be readily apparent to those of ordinary skill in the art, and the general principles defined can be applied to other implementations and applications, without departing from the scope of the present disclosure. In some instances, one or more technical details that are unnecessary to obtain an understanding of the described subject matter and that are within the skill of one of ordinary skill in the art may be omitted so as to not obscure one or more described implementations. The present disclosure is not intended to be limited to the described or illustrated implementations, but to be accorded the widest scope consistent with the described principles and features.

A cloud platform integration (CPI) system can be used to integrate different systems, such as a source system and a target system. An integration flow can be modeled and then executed to perform an integration between systems. The integration flow can include a source system representation, a target system representation, and other objects or artifacts that may be used during an integration. Integration artifacts can include, for example, transformation rules, message metadata, message instances (including message traces), message queues, message APIs (Application Programming Interfaces), key storage and other data storage representations, including temporary or intermediate storage, global variables (for communicating between integration flows), message attachments, or other types of artifacts. A given integration flow or set of integration flows may include or use a variety and number of artifacts or components, beyond just messages passed between systems. Other artifact types can include message processing logs, known host lists, credentials, public and secret keyrings, secure parameters, number ranges, and message locks, and value mappings, for example.

Organizational or customer requirements may specify that access to certain data or types of data be restricted. A role-based system can be used that enables certain users to access certain types of objects or artifacts. For instance, a first role, which may be assigned, for example, to first and second users, may enable the first and second users to generally access message attachments. A role-based system may not offer a refined enough granularity for all security use cases. For instance, a system requirement may be that the first user should be able to access some but not all message attachment instances. For example, a HR system may use an integration flow to consolidate HR data from a German sub-system and an Indian sub-system (and possibly other systems) into a central HR system. System requirements (and possibly legal requirements) may specify that only certain users (e.g., an administrator or HR personnel) have access to attachments used by the HR integration flow. For example, general integration support personnel, while generally allowed to view message attachments, may be prohibited, using an object-based access control approach, from accessing specific message attachments used in the HR integration flow.

More-refined approaches can be used as well, to further limit access to certain instances. For instance, a HR user in a German office may be able to access (e.g., for troubleshooting purposes) a HR attachment generated by the German sub-system, but may not be allowed to access a HR attachment generated by the Indian sub-system. Instance-based access can be controlled by rules which match (and allow access to) instances based on identifier, name, or more general regular-expression based matches.

While cloud platform integration is described, a same instance-based approach can be used for other types of applications that are built on top of a cloud platform. Instances may be object instances, class instances, artifact instances, or some other type of instance of some other abstract category or type. Accordingly, “artifact instance” and “object instance” may be used generally synonymously in this disclosure.

FIG. 1illustrates an example of a system100for instance-based access control configuration. Instance-based access control can be configured for a CPI system102that is built on top of a cloud platform104. Other types of cloud-based applications can use similar instance-based access control. In some implementations, instance-based access control can be integrated with role-based access control.

For instance and as indicated by a note106, a cloud platform (CP) application user administrator can create and assign roles to users or user groups (e.g., using a cloud cockpit107or other user interface). In some implementations, a custom role108can be defined in the cloud platform104, for integration with instance-based rules. The custom role108(or other role defined in the cloud platform104) can, for example, be associated with an object or artifact type privilege. For example, a role may be defined that enables users to access an artifact of a given type. For instance, a role can define a privilege of accessing message trace artifacts, message attachments, or some other type of artifact.

A role defined in the cloud platform104can be linked to an access policy110defined in the CPI system102. An application administrator can use a CPI user interface112to configure an access policy, and link the access policy to an existing role, for example. As described in more detail below, linking a cloud platform role to an application access policy can enable access control for all artifact types and can enable always-visible artifact instances.

The application administrator can correlate the access policy110to the custom role108, to configure the role to apply to certain artifact instances of a given type. Accordingly, the access policy110can be used for instance-based authorizations. The access policy110can store a list of permissions114that can be used to guard access to artifact instances and associated data. For example, the access policy110can have multiple entries, and each entry can represent permissions114associated with an artifact instance116or resulting data of an integration flow. Resulting data can include all data generated by an integration platform when executing message processing or other aspects of an integration flow. Resulting data can include message processing logs, message traces, attachments, data store entries, variables, and message queue entries. Instance-based protection can extend (or be applied) to any relevant artifact type or type of resulting data. The artifact instance116or resulting data can be identified using an artifact reference118. The artifact reference118can indicate an attribute name (and value) of an attribute that can uniquely identify the artifact instance116. For example, the artifact instance116can be referenced by an artifact identifier and/or an artifact name.

In some implementations, since roles are defined in one system (e.g., the cloud platform104) and access policies are defined in another system (e.g., the CPI system102) a consistency check is (e.g., occasionally) performed to validate whether all roles referenced by existing access policies still exist. A CP administrator may have deleted a role referenced by an access policy, for example. An access policy without a role can be considered obsolete. A consistency check can include providing an administrator an option to delete or reconfigure an obsolete access policy. In some implementations, the cloud platform104is configured to query the CPI system102, upon a request to delete a role, to determine whether the role is referenced in any access policies. A role that is referenced in access policy may be blocked from being deleted until references are removed.

FIG. 2illustrates an example of a system200for applying instance-based access policies. As mentioned, some customers may prefer to use one tenant for integration scenarios. Accordingly, a tenant management node202, of a CPI system203, can manage integrations included in the customer's tenant. A node manager component204can interface with a cloud platform206that services the CPI system203, for example.

Incorporating instance-based access control into a single tenant can provide various advantages. For instance, some large companies may have multiple departments or sub-organizations, but may desire or prefer to store integration data in one tenant, to reduce total cost of ownership as compared to supporting or using multiple tenants or systems. Instance-based access policies can be beneficial for such customers, since integration content can be stored in the single tenant but can be access-controlled according to instances, based on instance-based rules. The customer can still use the single tenant for different types of integration content, such as internally-developed content, partner-developed content, and integration content shipped with an integration platform. Internally-developed content may be content that is developed by different departments. Instance-based rules can be configured that restrict, for example, HR content from view by non HR users, internally-developed content from view by partner users, first department content from view by other-department users, etc.

The CPI system203can provide various entry points for user interfaces (or other applications). For example, user interface requests208or210, or application requests212or214, can be received from a user interface216or an API218, respectively. Application or user interface based requests can be received by the tenant management node202at an Odata API interface220, a command API interface222, or at some other type of interface. The Odata API interface220can be configured to handle Odata requests. The command API interface222can be configured to handle command-based requests (e.g., internal or external commands issued using a command-based API). The user interface216can be used by a user to execute and monitor integration flows, for example.

A request from the user interface216(or from another application) can include or be associated with a request to access an artifact instance. The request to access the artifact instance can be forwarded to and handled by an access layer224(e.g., as a forwarded request226or228). If the access layer224approves the request, a corresponding Odata or command request can be handled, for example, by an Odata processor230or a command handler232, respectively. If user privileges are not sufficient to access the instance, an error message can be displayed, or some other type of action can be performed (or the request can simply be denied). In some implementations, an access request is sent by the user interface216before an instance is shown to a user (e.g., before instance information is presented), and if the access request is denied, the instance information is simply not presented. If the access request is accepted, instance information can then be displayed.

The access layer224can perform a multi-step approach to determine whether the requesting user has permission to access the artifact instance, by checking whether the user's request conforms to configured access policies. The multi-step approach can include using instance-based rules in combination with role-based access. For instance, a first step can include determining whether a user has access to artifacts of a certain type. For instance, the access layer224can determine whether a user has access, based on a user role, to message trace objects. The access layer224can use a role API233to retrieve role information for the current user, for example. If the user's role does not enable access to message trace objects, the user can be prevented from accessing message trace objects.

If the user's role enables access to message trace objects, the system can next determine, in a second step, whether any instance-based rules have been defined for message trace objects. If at least one instance-based rule has been defined for message trace objects, the rule(s) can be evaluated, in a third step, to determine whether any rules are relevant to the artifact instance in question. If rule(s) relate to the artifact instance in question, the access layer224can determine whether the rule grants access to the artifact instance to the user.

In summary, the first step, relating to roles, can be a functional access control step that ensures that a user has a certain general privilege (such as viewing message traces). The second and third steps can be instance-related checks, for confirming whether the user is allowed to perform a requested action on a particular object instance.

In some implementations, access is general (e.g., the user may be deemed as able to access, or not access, a given instance). In other implementations, access can be action-specific, in that a user may be enabled to perform only certain actions, from among a set of actions, on certain object instances.

An access policy data store234can store access policies and related information (e.g., permissions, artifact references). Access policy information can be stored independently from the referenced artifacts. Other types of systems may store access information with the artifact, for example.

FIG. 3is an example of a system300for applying instance-based access policies in a microservice environment. Application requests302and304, which can each correlate to a request for an artifact, can come from a user interface306, or an API308, respectively. In some implementations, an application router310forwards a request to one or more microservices, such as an operations microservice311or a second microservice312. Different microservices can provide different integration services, for example. Similar to the tenant management node202described above with respect toFIG. 2, the operations microservice312and the second microservice314include an Odata API interface315or316, a command API interface317or318, an Odata processor320or322, and a command handler324or326, respectively.

The operations microservice312includes an access layer328, which can serve a similar (or same) purpose as the access layer224described above with respect toFIG. 2. For instance, the access layer328can, in response to a request330, determine whether a current user associated with the request330is allowed to access an artifact instance, based on access policies stored in an access policy data store332and on role(s) of the user that have been defined for a cloud platform334and that have been retrieved by the access layer328using a role API336.

Other microservices, other than the operations microservice312, such as the second microservice314, can use the access layer328using a respective proxy (e.g., an access layer proxy338). The access layer proxy338can send a request340to the access layer328(or otherwise use other services of the access layer328as exposed by an API). The request340can correspond to a user (or API) request342received at the second microservice314. The request342can correspond to a request to access an artifact instance. The access layer proxy338can request that the access layer328determine whether a current user can access the artifact instance. The access layer328can provide a response that indicates whether the user should be allowed to access the artifact instance. The access layer proxy338can receive the response and act accordingly (e.g., by either granting or denying access to the artifact instance).

FIG. 4illustrates various examples of user personas400. Various user personas400can interface with the access policy feature. For example, a tenant administrator402can maintain access policy definitions (e.g., or define access policy entries (404)). The tenant administrator402can define access control lists to restrict access to artifacts and resulting data, per user. The tenant administrator402can link an access policy to a role that has been defined by a CP application user administrator406. The CP application user administrator406can use a cloud platform to assign custom roles (408) to CPI users, for example.

Once access policies have been defined and linked to roles, access to artifacts and resulting data can be controlled by the access policies (410). For example, an access policy can control what artifacts a business expert412can access. A business expert412can monitor integration flows and the status of integration artifacts, including viewing message payload and attachments. With the use of access policies, a business expert412can be allowed to see those artifacts and resulting data for which corresponding permissions have been assigned. As another example, access policies can be used to control access to artifacts by integration developers414. An integration developer414can create, edit, deploy, and monitor integration flows, for example. Access policies can be used to refine exactly which artifacts the integration developer414can access.

FIG. 5is an example of a user interface500for adding artifact references to an access policy. The user interface500can be displayed in reference to a previously-selected access policy (e.g., a user may have selected an access policy502on an underlying user interface504, and then selected another user interface item to add an artifact reference to the selected policy).

The access policy502may be associated with a role, such as a role assigned to HR users of a German line of business for an organization. The user interface500can be displayed to configure a rule that, when applied, allows only users with the role to access integration flow instances that have been developed for HR data for the German line of business. A name506and description508of the artifact reference can be entered in the user interface500. A condition area512can enable a user to define a condition that results in identification of desired integration flow instances. For example, an artifact type514of Integration Flow has been selected. A name attribute516has been selected, along with an equals operator518and a value520of “GermanHR” (e.g., a name of a particular integration flow). Regular expressions can also be used to match one or more instances, e.g., if a “matches” operator522is selected.

Selection of another type of artifact may result in other options. For instance, although an integration flow may be identifiable using a name (or perhaps an identifier), other artifact types may have other types of attributes for identification, which may enable selection (and configuration) of other types of matching rules or conditions. Accordingly, the user interface500can be dynamic, based on a selected artifact type.

A create item524can be selected to associate the artifact reference with the access policy502. Creation (and modification) of access policies, artifact references, and correlation of access policies to roles can be logged.

In some implementation, definition and application of access control can be hierarchical. For instance, an integration flow or an integration package can be treated as an artifact type, and access can be provided to particular integration flow instances or integration packages. Access permissions to other artifacts included in a respective integration flow or integration package can be inherited (or prohibited) based on defined rules for the containing integration flow or package.

Different approaches can be used with respect to filtering artifact instances based on access policies. With a first approach, artifact instances are only displayed to a user when the user has access policy permissions (through an associated role). Such an approach can have disadvantages. For example, a new user may not be able to see any artifact instances until all appropriate roles have been assigned. Additionally, application designers may desire that some artifacts are always visible, but if artifacts are hidden until a role is assigned, always-visible artifacts may not be possible. Another approach can be used in which users can view/access artifact instances that are not referenced in any access policy, and artifact instances for which access policies apply to the user (and the instance), with other instances (potentially) being hidden from the user if they are included in an access policy which does not match the user. This approach allows for some artifacts to be always visible (if they are never included in an access policy) and for new users to see at least some artifacts before all roles have been assigned to the user.

FIG. 6is a flowchart illustrating an example of a computer-implemented method600for access control for object instances. It will be understood that method600can be performed, for example, by any system, environment, software, and hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method600can be run in parallel, in combination, in loops, or in any order.

At602, a user request associated with a first user is received, at a cloud application. The user request corresponds to a first instance of a first application artifact type. The cloud application can be a cloud platform integration application or another type of application. The first application artifact type can be a type of integration flow artifact, such as an integration flow itself, a message queue, a message trace, a log, a data store, a message attachment, or some other type of artifact.

At604, role assignments for the first user are retrieved, from a cloud platform.

At606, a determination is made that the role assignments grant permission to the first application artifact type to the first user. Other requests, (e.g., a second request for a second instance of a second application artifact type) can be defined if role assignments do not grant permission, e.g., to the second application artifact type.

At608, a determination is made that a first instance-based access policy exists for the first application artifact type. The first instance-based access policy can be linked to the first role assignments, for example. In some cases, a consistency check can be (e.g., periodically) performed that includes identifying the linking between the first instance-based access policy and the first role assignments and determining whether the first role assignments are still configured in the cloud platform. For other requests, such as the second request, if an instance-based policy does not exist for the second application artifact type, the request can be serviced (e.g., assuming role permissions enable access to the second artifact type in general).

At610, a determination is made as to whether the first instance-based access policy grants permission for the first user to access the first instance.

At612, in response to determining that the first instance-based access policy grants permission for the first user to access the first instance, the user request is serviced. Determining that the first instance-based access policy grants permission for the first user to access the first instance can include matching the first instance to the first instance-based policy based on a first artifact reference of the first instance. Matching can include an exact match or a pattern-based (e.g., regular expression based) match of the first artifact reference to the first instance-based access policy. The first artifact reference can be an artifact instance identifier or an artifact instance name. Different types of artifacts can have different types of artifact references.

At614, in response to determining that the first instance-based access policy does not grant permission for the first user to access the first instance, the user request is denied. An attempt to match the first artifact reference to the first instance-based access policy may have failed, for example.

FIG. 7is a block diagram illustrating an example of a computer-implemented System700used to provide computational functionalities associated with described algorithms, methods, functions, processes, flows, and procedures, according to an implementation of the present disclosure. In the illustrated implementation, System700includes a Computer702and a Network730.

The illustrated Computer702is intended to encompass any computing device, such as a server, desktop computer, laptop/notebook computer, wireless data port, smart phone, personal data assistant (PDA), tablet computer, one or more processors within these devices, or a combination of computing devices, including physical or virtual instances of the computing device, or a combination of physical or virtual instances of the computing device. Additionally, the Computer702can include an input device, such as a keypad, keyboard, or touch screen, or a combination of input devices that can accept user information, and an output device that conveys information associated with the operation of the Computer702, including digital data, visual, audio, another type of information, or a combination of types of information, on a graphical-type user interface (UI) (or GUI) or other UI.

The Computer702can serve in a role in a distributed computing system as, for example, a client, network component, a server, or a database or another persistency, or a combination of roles for performing the subject matter described in the present disclosure. The illustrated Computer702is communicably coupled with a Network730. In some implementations, one or more components of the Computer702can be configured to operate within an environment, or a combination of environments, including cloud-computing, local, or global.

At a high level, the Computer702is an electronic computing device operable to receive, transmit, process, store, or manage data and information associated with the described subject matter. According to some implementations, the Computer702can also include or be communicably coupled with a server, such as an application server, e-mail server, web server, caching server, or streaming data server, or a combination of servers.

The Computer702can receive requests over Network730(for example, from a client software application executing on another Computer702) and respond to the received requests by processing the received requests using a software application or a combination of software applications. In addition, requests can also be sent to the Computer702from internal users (for example, from a command console or by another internal access method), external or third-parties, or other entities, individuals, systems, or computers.

Each of the components of the Computer702can communicate using a System Bus703. In some implementations, any or all of the components of the Computer702, including hardware, software, or a combination of hardware and software, can interface over the System Bus703using an application programming interface (API)712, a Service Layer713, or a combination of the API712and Service Layer713. The API712can include specifications for routines, data structures, and object classes. The API712can be either computer-language independent or dependent and refer to a complete interface, a single function, or even a set of APIs. The Service Layer713provides software services to the Computer702or other components (whether illustrated or not) that are communicably coupled to the Computer702. The functionality of the Computer702can be accessible for all service consumers using the Service Layer713. Software services, such as those provided by the Service Layer713, provide reusable, defined functionalities through a defined interface. For example, the interface can be software written in a computing language (for example JAVA or C++) or a combination of computing languages, and providing data in a particular format (for example, extensible markup language (XML)) or a combination of formats. While illustrated as an integrated component of the Computer702, alternative implementations can illustrate the API712or the Service Layer713as stand-alone components in relation to other components of the Computer702or other components (whether illustrated or not) that are communicably coupled to the Computer702. Moreover, any or all parts of the API712or the Service Layer713can be implemented as a child or a sub-module of another software module, enterprise application, or hardware module without departing from the scope of the present disclosure.

The Computer702includes an Interface704. Although illustrated as a single Interface704, two or more Interfaces704can be used according to particular needs, desires, or particular implementations of the Computer702. The Interface704is used by the Computer702for communicating with another computing system (whether illustrated or not) that is communicatively linked to the Network730in a distributed environment. Generally, the Interface704is operable to communicate with the Network730and includes logic encoded in software, hardware, or a combination of software and hardware. More specifically, the Interface704can include software supporting one or more communication protocols associated with communications such that the Network730or hardware of Interface704is operable to communicate physical signals within and outside of the illustrated Computer702.

The Computer702includes a Processor705. Although illustrated as a single Processor705, two or more Processors705can be used according to particular needs, desires, or particular implementations of the Computer702. Generally, the Processor705executes instructions and manipulates data to perform the operations of the Computer702and any algorithms, methods, functions, processes, flows, and procedures as described in the present disclosure.

The Computer702also includes a Database706that can hold data for the Computer702, another component communicatively linked to the Network730(whether illustrated or not), or a combination of the Computer702and another component. For example, Database706can be an in-memory or conventional database storing data consistent with the present disclosure. In some implementations, Database706can be a combination of two or more different database types (for example, a hybrid in-memory and conventional database) according to particular needs, desires, or particular implementations of the Computer702and the described functionality. Although illustrated as a single Database706, two or more databases of similar or differing types can be used according to particular needs, desires, or particular implementations of the Computer702and the described functionality. While Database706is illustrated as an integral component of the Computer702, in alternative implementations, Database706can be external to the Computer702. As illustrated, the Database706holds the previously described access policies718.

The Computer702also includes a Memory707that can hold data for the Computer702, another component or components communicatively linked to the Network730(whether illustrated or not), or a combination of the Computer702and another component. Memory707can store any data consistent with the present disclosure. In some implementations, Memory707can be a combination of two or more different types of memory (for example, a combination of semiconductor and magnetic storage) according to particular needs, desires, or particular implementations of the Computer702and the described functionality. Although illustrated as a single Memory707, two or more Memories707or similar or differing types can be used according to particular needs, desires, or particular implementations of the Computer702and the described functionality. While Memory707is illustrated as an integral component of the Computer702, in alternative implementations, Memory707can be external to the Computer702.

The Application708is an algorithmic software engine providing functionality according to particular needs, desires, or particular implementations of the Computer702, particularly with respect to functionality described in the present disclosure. For example, Application708can serve as one or more components, modules, or applications. Further, although illustrated as a single Application708, the Application708can be implemented as multiple Applications708on the Computer702. In addition, although illustrated as integral to the Computer702, in alternative implementations, the Application708can be external to the Computer702.

The Computer702can also include a Power Supply714. The Power Supply714can include a rechargeable or non-rechargeable battery that can be configured to be either user- or non-user-replaceable. In some implementations, the Power Supply714can include power-conversion or management circuits (including recharging, standby, or another power management functionality). In some implementations, the Power Supply714can include a power plug to allow the Computer702to be plugged into a wall socket or another power source to, for example, power the Computer702or recharge a rechargeable battery.

There can be any number of Computers702associated with, or external to, a computer system containing Computer702, each Computer702communicating over Network730. Further, the term “client,” “user,” or other appropriate terminology can be used interchangeably, as appropriate, without departing from the scope of the present disclosure. Moreover, the present disclosure contemplates that many users can use one Computer702, or that one user can use multiple computers702.

Implementations of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Software implementations of the described subject matter can be implemented as one or more computer programs, that is, one or more modules of computer program instructions encoded on a tangible, non-transitory, computer-readable medium for execution by, or to control the operation of, a computer or computer-implemented system. Alternatively, or additionally, the program instructions can be encoded in/on an artificially generated propagated signal, for example, a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to a receiver apparatus for execution by a computer or computer-implemented system. The computer-storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of computer-storage mediums. Configuring one or more computers means that the one or more computers have installed hardware, firmware, or software (or combinations of hardware, firmware, and software) so that when the software is executed by the one or more computers, particular computing operations are performed.

Non-transitory computer-readable media for storing computer program instructions and data can include all forms of permanent/non-permanent or volatile/non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, for example, random access memory (RAM), read-only memory (ROM), phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic devices, for example, tape, cartridges, cassettes, internal/removable disks; magneto-optical disks; and optical memory devices, for example, digital versatile/video disc (DVD), compact disc (CD)-ROM, DVD+/-R, DVD-RAM, DVD-ROM, high-definition/density (HD)-DVD, and BLU-RAY/BLU-RAY DISC (BD), and other optical memory technologies. The memory can store various objects or data, including caches, classes, frameworks, applications, modules, backup data, jobs, web pages, web page templates, data structures, database tables, repositories storing dynamic information, or other appropriate information including any parameters, variables, algorithms, instructions, rules, constraints, or references. Additionally, the memory can include other appropriate data, such as logs, policies, security or access data, or reporting files. The processor and the memory can be supplemented by, or incorporated in, special-purpose logic circuitry.