Patent Application
20230164189
The present disclosure relates to electronic device security, and more particularly, to techniques for providing relationship-based access control for Internet of Things (IOT) networks using a graph database.
IoT networks deliver great value with highly available data and computing resources. However, such networks also bring significant security and privacy challenges. Conventionally, these challenges have been addressed via the concept of “tenancy” as the framework for data isolation, yet the traditional concept of tenancy possess significant limitations. Device and data security are increasingly important considerations for modern IoT networks.
A more detailed description of the disclosure, briefly summarized above, may be had by reference to various embodiments, some of which are illustrated in the appended drawings. While the appended drawings illustrate select embodiments of this disclosure, these drawings are not to be considered limiting of its scope, for the disclosure may admit to other equally effective embodiments.
Identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. However, elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation.
Internet of Things (IoT) networks deliver great value with seemingly omnipresent data and compute resources, yet also can pose significant challenges to security and privacy. Generally speaking, IoT systems bring pervasive computing to everyday life. Anything from a smart thermostat or a fridge to a smart assembly line or refinery safety equipment can be connected to the Internet, delivering tremendous value in the form of both data and control capabilities. IoT data is becoming increasingly valuable, and generally the value of this data is unlocked largely through analytics. The analytics value cascade generally includes descriptive analytics that, e.g., describe what is happening, diagnostic analytics that, e.g., give details on malfunctions, predictive analytics that, e.g., can suggest maintenance before a malfunction occurs, prescriptive analytics that, e.g., can suggest changes to avoid before a malfunction occurs, and productive analytics that can, e.g., suggest how to improve a product and production.
However, the “value” of data is not a singular quantity, and generally the true value of data depends on the context. For example, for a given embodiment, the value of collected data can depend on the production of the data, the usage of the data, the need or demand for the data, the available supply of data, and so on. In many environments today, the value of the data exists but has yet to be unlocked. While much of the value of data can be unlocked within an offer or product context, a vast potential value also exists in relating various heterogeneous bodies of data to each other—across offers, across domains, across administrative boundaries, etc.
Currently the management and processing of IoT data are typically done using the concept of “tenancy” as a way of isolating data in different administrative domains from each other. In other words, tenancy serves as a framework for data isolation. Data isolation is frequently of critical importance, as it relates to several cross-cutting concerns such as security, privacy, and regulatory compliance.
In many instances, it is desirable to selectively share data between various tenants within the IoT environment. However, such sharing must be closely managed to ensure data privacy and security are maintained and may present additional security challenges as well. Traditionally, these security challenges (including intra-tenant access requests and inter-tenant access requests) are addressed via various access control schemes. For example, a Role-Based Access Control (RBAC) system associates users within the network with various roles. The RBAC system can further specify a set of permissions for each respective role, and users assigned to these roles can inherit these permissions. Moreover, each resource within the network can be associated with a set of permissions. In this context, a resource could correspond to an IoT device, data collected from an IoT device, an aggregated data store, an analytics application, data produced by such an analytics application, and so on. For each resource access request, the RBAC system could determine whether the requesting user's permissions (as determined by one or more roles assigned to the requesting user) match the set of permissions associated with the requested resource. If the permissions match, the access request could be granted and if the user's permissions are insufficient (i.e., the user does not have the required permissions to access the resource), the resource access request could be denied.
Attribute-Based Access Control (ABAC) is another form of access control system used to secure resources in an IoT environment. In an ABAC system, each user is associated with a respective access policy that describes attributes of the user. Such attributes could include, for example, a username, a job title, one or more user responsibilities, and so on. Each resource within the IoT environment is also associated with attributes that describe the conditions that must be met before access to the respective resource is granted. When a resource access request is received, the ABAC system attempts to match the attributes required to access the resource with the attributes of the requesting entity, and grants access if the required attributes are satisfied.
While such access control systems solve many problems and provide numerous advantages, these access control systems have limitations and disadvantages as well. For example, in a particular IoT environment, a given data source may be owned or managed by a first organization, but the data could be used or consumed by a different organization(s). In such an environment, the data consumers may want to access the data at various stages of the process, e.g., the raw data stream, at an intermediate transformation point, at a normalized or optimized point in the process, or as an anonymized data set. To achieve this in an RBAC or ABAC system, however, custom roles and attributes must be manually defined to allow each desired access. Typically, this is a manual and time-consuming process, as each access request is individually accessed by at least one authority entity before being approved.
Additionally, the increasing amount of data sources producing a tremendous amount of data related to people is presenting new security and privacy challenges in IoT systems. While a single data set may not affect a person's privacy, data in the single data set could theoretically be combined or related to valuable pieces of information about the person or their behavior in other data sets. As protecting data privacy is oftentimes a key objective in IoT adoption (especially when the data is shared and used by other entities), this further complicates and extends the time involved in the approval process. As security is the primary challenge in terms of implementing IoT solutions, with privacy and access control being top priorities, an improved access control system is needed.
Embodiments described herein provide techniques for implementing a Relationship-Based Access Control (RelBAC) System, where a graph database is used to store business model entities, relationships and attributes. The RelBAC System can then evaluate the graph database relations when considering a particular resource access request by a particular requestor and can determine whether the resource access request should be granted based on a defined security policy. In one embodiment, the RelBAC System can further evaluate a context associated with the resource access request. For example, the RelBAC System could determine a time at which the resource access request was received, a geographic location from which the resource access request was received, a network location from which the resource access request was received, a type and/or identity of a network connection used to submit the resource access request, and so on. More generally, the RelBAC System can take into account any suitable context attribute associated with the resource access request when determining whether to grant the requestor access to the requested resource, consistent with the functionality described herein.
A particular embodiment provides a method of managing data access within a first computing environment. The method includes receiving a request, from a first requesting entity, to access a first resource. The method further includes generating and submitting a query for a graph-based database to determine one or more relationships between the first requesting entity and other entities covered by a security policy, where the graph-based database models identities, resources and security relationships covered by the security policy. The method also includes determining, based on the determined one or more relationships and the security policy, whether the first entity is allowed to access the first resource according to the security policy.
In one embodiment, the RelBAC system is configured to generate and submit a query against the graph database pre-generate a data structure for use in processing access requests. Generally, the pre-generated data structure can facilitate look-up operations for determining whether to grant access requests, e.g., determining whether a given access request for a particular resource, from a particular requesting entity, and with an associated context should be granted. In a particular embodiment, the RelBAC system is configured to periodically
The Data Orchestrator System 130 includes one or more computer processors 112, a memory 113, and a network interface controller 139. The memory 113 contains a data orchestrator component 140 and an operating system 138. Generally, the data orchestrator component 140 represents software logic that can install a software module on the Consumers 190 and validate the operation of the software module. As described herein, a software module refers to any software component, including (without limitation) device firmware, a software application, a module for a software application, a suite of software applications, and so on. Generally, the operating system 138 represents any suitable operating system for a computing device. Data Orchestrator System 130 is communicatively coupled to a data store 180.
The RelBAC System 160 includes one or more computer processors 162, a memory 165 and a network interface controller 179. The memory 165 includes an access management component 170 and an operating system 178. Generally, the access management component 170 is a service that governs access to resources. For instance, the access management component 170 could receive an access request that identifies a resource using a unique resource identifier (URI) corresponding to the resource. As an example, a particular consumer 190 could request access to particular IoT data 122 within the data store 120 from the data orchestrator system 130, and before granting the access request, the data orchestrator component 140 could transmit a request to the access management component 170 in order to determine whether the consumer 190 is authorized to access the requested IoT data 122.
In a particular embodiment, the access management component 170 uses Hypertext Transfer Protocol (HTTP) for communicating with other components within the IoT network. For example, the access management component 170 could provide an Application Programming Interface (API) that complies Representational State Transfer (REST) constraints. Such an API is referred to herein as a RESTful API. In such an embodiment, an Identity Management Service (IDMS) component can receive requests and can generate responses to said requests using an HTTP-compliant format. For example, the IDMS component could generate responses formatted in the Hypertext Markup Language (HTML) format, the Extensible Markup Language (XML) format, the JavaScript Object Notation (JSON) format, and so on.
As an example, the access management component 170 could receive an access request from the data orchestrator component 140, where the access request specifies a first requesting entity that is requesting to access a first resource. For example, a first consumer 190 could have requested, from the data orchestrator component 140, to access particular IOT data 122 stored in the data store 120, where the IOT data 122 was collected by one or more of the endpoint devices 110.
Upon receiving the request from the data orchestrator component 140, the access management component 170 could generate and submit a query to be executed against the graph database 181 to determine one or more relationships between the first requesting entity and other entities covered by the security policy 184. The graph database 181 generally models identities, resources and security relationships covered by the security policy. For example, the access management component 170 could have previously generated the graph database 181 based on the organization data 182, the user data 183 and the resource data 184. In a particular embodiment, the data orchestrator component 140 is configured to execute one or more queries against the graphic database 181 and to generate, based on query results from executing the one or more queries, a lookup data structure for processing subsequently received access requests for resources. In such an embodiment, the data orchestrator component 140 can be configured to process received resource access quests using the lookup data structure and to periodically update and/or regenerate the lookup data structure by executing one or more queries against the graph database 181. Doing so may conserve computing resources, e.g., in embodiments where executing queries against the graph database 181 consumes more computing resources than processing incoming resource access requests using the lookup data structure.
Generally, the organization data 182 represents data describing relationships of entities (e.g., users, applications, resources, etc.) within a particular organization and may also specify relationships between the particular organization and other organizations. The user data 183 generally contains data describing users across one or more organizations and may include one or more unique identifiers for each of the users as well as other metadata describing the users. The resource data 184 generally contains data identifying and describing resources within the system 100. Such resources may include, for example, data within data store 120, streaming data collected by one or more of the endpoint devices 110, the endpoint devices themselves 110, the consumer 190, the software modules 194 executing on the consumers 190, and so on. More generally, it is broadly contemplated that the resource data 184 may relate to any resource within an IoT environment, consistent with the functionality described herein. In other embodiments, the graph database 181 is generated using another software application(s) (not shown), generated manually by a system administrator(s), or a combination of users and software applications.
The access management component 170 could then determine, based on the determined one or more relationships and the security policy, whether the first entity is allowed to access the first resource according to the security policy 185. Generally, the security policy 185 includes a plurality of rules that define how various actors within the IoT system can interact with the IoT platform and assets within it. For example, the security policy 185 may include, without limitation, rules that evaluate a determined identity of the first requesting entity, rules that evaluate a resource type corresponding to the first resource, rules that evaluate a connection type of the first requesting entity, rules that evaluate a time at which the request to access the first resource was received, and rules that evaluate a location of the first requesting entity, rules that evaluate any combination of the above or any other suitable attribute associated with an access request.
Additionally, the security policy 185 may contain a number of security sub-policies, including (without limitation) an individual access control sub-policy, an application and/or service access control policy, an access governance sub-policy, and so on. For instance, the individual access control sub-policy could describe how a user interacts with the IoT platform and what permissions the user has within the IoT environment. In one embodiment, the individual access control sub-policy defines a comprehensive range of actors including, without limitation, IoT platform developers (e.g., developers who build and manage software applications on the data orchestrator system 130), business developers (e.g., developers who build and manage the software modules 194 on the consumer devices 190), operations engineers (e.g., engineers who manage the underlying hardware systems of the data orchestrator system 130, endpoint devices 110 and/or consumers 190), outside contractors who perform various roles within the IoT environment, external partners of the IoT environment and other customers external to the IoT environment.
The application and/or service access control sub-policy defines how an application, service or process within the IoT environment interacts with elements of the IoT platform. For example, the application and/or service access control sub-policy could define how a particular software module 194 on a particular consumer system 190 can interact with various elements and resources within the IoT platform. The access governance sub-policy generally defines rules by which access permissions (i.e., individual or application-level permissions) are granted for sharing assets with other parties. In one embodiment, the access governance sub-policy defines how access within the IoT platform is monitored, audited and managed to ensure long-term stability and security of the IoT platform.
The Endpoint Devices each include a processor 112, memory 113, and network controller 117. The Data Orchestrator System 130 contains a processor 132, memory 135 and network interface controller(s) 139. The RelBAC System 160 contains a processor 162, a memory 165 and a network interface controller 179. The Consumers 190 each include a processor 192, memory 193 and a network interface controller 197. Any general-purpose computer systems used in various embodiments of this disclosure may be, for example, general-purpose computers with general-purpose computer processors. For example, the processors 112, 132, 162 and 192 may include processors based on Intel PENTIUM-type processor, Motorola PowerPC, Sun UltraSPARC, Hewlett-Packard PA-RISC processors, ARM-based processors or any other type of processor. Generally, the processors 112, 132, 162 and 192 represent any suitable processor(s), including commercially available processors such as the well-known Pentium class processor available from the Intel Corporation. Many other processors are available. Such a processor usually executes an operating system (e.g., the processor 132 can execute the operating system 138, the processor 162 can execute the operating system 178, etc.) which may be, for example and without limitation, Microsoft® Windows®, Apple® macOS®, Solaris®, UNIX®, or Linux®. Many other operating systems may be used.
The memories 113, 135, 165 and 193 generally represents any suitable form of addressable computer memory. For example, the memories 113, 135, 165 and 193 may represent a volatile memory (e.g., static random-access memory (SRAM)) and/or a non-volatile memory (e.g., Flash memory). More generally, any suitable form of memory device(s) can be used, consistent with the functionality described herein. Generally, the processor and operating system together define a computer platform for which application programs in high-level programming languages are written. It should be understood that embodiments of the present disclosure are not limited to a particular computer system platform, processor, operating system, or network. Also, it should be apparent to those skilled in the art that the present disclosure is not limited to a specific programming language or computer system. Further, it should be appreciated that other appropriate programming languages and other appropriate computer systems could also be used.
In the depicted embodiment, the memories 113 and 193 contain software modules 114 and 194, respectively. Additionally, the memory 113 contains a data collection component 115 that is generally configured to collect data for a data metric(s) on the endpoint devices 110. For example, in a power management context, the data collection component 115 could collect power metric data from one or more sensor devices of the endpoint devices 110. Generally, the software modules 114 and 194 represent application-specific software for the IoT environment. For example, in a power management context, the software modules 114 on the endpoint devices 110 could include power monitoring logic, while the software modules 194 could include power metric processing logic and monitoring and analytics services.
The Endpoint Devices 110, Data Orchestrator System 130, RelBAC System 160 and Consumers 190 may use the network interface controllers 117, 139, 179 and 197, respectively, to send and receive data on one or more data communication networks (e.g., networks 125 and 150). One or more portions of the computer system may be distributed across one or more computer systems coupled to a communications network. For example, as discussed above, a computer system that determines available power capacity may be located remotely from a system manager. These computer systems also may be general-purpose computer systems. For example, various aspects of the disclosure may be distributed among one or more computer systems configured to provide a service (e.g., servers) to one or more client computers, or to perform an overall task as part of a distributed system. For example, various aspects of the disclosure may be performed on a client-server or multi-tier system that includes components distributed among one or more server systems that perform various functions according to various embodiments of the disclosure. These components may be executable, intermediate (e.g., IL) or interpreted (e.g., Java) code which communicate over a communication network (e.g., the Internet) using a communication protocol (e.g., TCP/IP). For example, one or more database servers may be used to store device data, such as expected power draw, that is used in designing layouts associated with embodiments of the present disclosure.
As shown, the memory 135 also contains an operating system 138. Similarly, the memory 165 contains an operating system 178. Generally, the operating systems 138 and 178 manage at least a portion of the hardware elements included in Data Orchestrator System 130 and the RelBAC System 160, respectively. Usually, a processor or controller, such as processors 132 and 162, executes an operating system which may be, for example, a Windows-based operating system, such as, Windows 10, Windows NT, Windows 2000 (Windows ME), Windows XP or Windows Vista operating systems, available from the Microsoft Corporation, a MAC OS System X operating system available from Apple Computer, one of many Linux-based operating system distributions, for example, the Enterprise Linux operating system available from Red Hat Inc., a Solaris operating system available from Sun Microsystems, or a UNIX operating system available from various sources. Many other operating systems may be used, and embodiments are not limited to any particular implementation.
The data orchestrator component 140 is generally configured to route data between the endpoint devices 110 and the consumers 190 in a secure manner. In a particular embodiment, the data orchestrator component 140 is configured to route such data while avoiding the limitations of conventional tenancy models. In one embodiment, the data orchestrator component 140 receives, from an endpoint device 110, a plurality of data values collected by the endpoint device 110. The data orchestrator component 140 can determine an identifier that uniquely identifies the endpoint device. The data orchestrator component 140 could dynamically generate one or more routing tables 182 based on at least one of (i) device claim information relating to the endpoint device, (ii) license data relating to the one or more data consumers, and (iii) user information associated with the one or more data consumers. The data orchestrator component 140 could then access the generated routing tables using the determined identifier and device type data corresponding to the plurality of data values to determine one or more data consumers to route the plurality of data values to. The data orchestrator component 140 could then transmit at least a portion of the plurality of data values to the determined one or more data consumers.
In the depicted embodiment, the data source 210 streams data to the data routing component 172 within the data routing layer 274. Generally, the access control layer(s) 235 can consume the access control data from the access management service 282, and can generate and provide routing information to the data routing component 172. The data routing component 172 can combine such data routing information and access control data with actual access context information (e.g., one or more assess claim tokens presented by the data consumer application 225 on behalf of a user) to determine whether and how to route each piece of data. This enables the data routing layer 274 to correctly deliver a customized data view to the application and user for consumption, while ensuring security and data privacy requirements are met.
Moreover, the data routing layer 274 can do so for both batch data and streaming data. Generally, the data routing layer 274 can selectively provide data from the data providers 272 to the data consumers 276 in a number of different ways, including a pub/sub methodology (e.g., where the data consumer application 225 subscribes to one or more types of data, and the data routing layer 274 publishes data received from the data providers 272 to authorized subscribers), a push methodology (e.g., where the data routing layer 274 selectively transmits data received from the data providers 272 to one or more data consumers 276), a pull methodology (e.g., where the data routing layer 274 stores data received from the data providers 272 in the data storage area 230, and the stored data can be provided to data consumers 276 the access control layer(s) 235 determines have sufficient authorization to access the data upon request), and so on. For example, in the case of streaming data, the data routing layer 274 could employ a pub/sub methodology or a push methodology to transmit the data to the data consumers 276. As another example, in the case of batch data, the data routing layer 274 could store the data in the data storage area 230 and authorized data consumers 276 can pull the data from the data storage area 230 upon authorization by the access control layer(s) 235.
The data routing component 172 also receives authorization and data routing information from the access management service 282, via the access control layer(s) 235. Such authorization information can include real-time data from the IDMS, and can include identifying a user(s) associated with the data source 210 (e.g., a user setup as an owner of the data source device), a role(s) of the user, device claim information relating to the user and/or the data source 210, and so on. Additionally, the authorization and routing configuration data can include license data Generally, the routing configuration information received from the access management service 282 can include one or more routing tables that specify how to route data of various types and from various sources.
Additionally, the data source transmits batch data to a data storage area component 230 within the data routing layer 274. An access control layer(s) 235 within the data routing layer 274 receives authorization configuration data from the access management service 282, and using these data selectively transmits the batch data (or a portion of the filtered batch data) to the data consumer app 225 within the data consumers layer 276. The streaming and batch data received by the data consumer application 225 can then be processed and used in an application-specific manner. For example, in a power management context, the data could be processed to generate various analytics, used by monitoring services, used to generate a visualization of the state of the data source 210, or more generally for any other suitable purpose.
The access management service 282 includes the access management component 170, as well as data aggregation components 245 and 255 and the IDMS 250. Generally, the data aggregation components 245 and 255 are configured to collect data from various sources and to aggregate and normalize these data for consumption by the access management component 170. For example, the data aggregation component 245 in the depicted example collects data on registered policies from the policy service 290. In the depicted embodiment, the platform admins 284 work to define the policy 295 at the policy service 290, and the policy service 290 then registers the defined policy with the data aggregation component 245. As discussed above, the policy 295 generally defines rules to be enforced to ensure the security of the IoT system. In one embodiment, the policy service 290 is configured to register a number of sub-policies with the data aggregation component 245, including an individual access control sub-policy, an application or service access control sub-policy and an access governance sub-policy. The data aggregation component 245 could then aggregate the policy data and provide the policy data to the access management component 170 for use in generating the authorization and routing configurations.
Additionally, the data aggregation component 255, as depicted, provides an API through which the model service 286 can register a business model data structure 288. In the depicted embodiment, the data consumer application 225 defines the business model 288, e.g., via an API provided by the model service 286. Generally, such a business model 288 defines various entities within an IoT computing network, such as devices, data stores, applications and services, and so on. Additionally, the business model 288 can define relationships between the various entities.
Generally, the access management service 282 can consume various access claims and rights data (e.g., from a claim service, a licensing service, the RelBAC System 160, etc.) and can generate access control configurations and/or structures consumed by the data routing layer 274. For example, the access management component 170 can dynamically generate one or more routing tables based on the authorization and routing configuration information, and these routing tables can be provided to the data routing component 172, which can use the routing table to selectively route the streaming data to a data consumer streaming endpoint 220. Doing so enriches existing access control data, and may further allow access control data to be constructed from scratch, in a manner reflective of both the data provider access rights (e.g., devices emitting telemetry streams) and data consumer access rights (e.g., advisor applications), as well of enterprise access control relationships and grants, such as what may be supplied by enterprise access-control system. Generally, the access control service has enough information to provide customized, least-privilege view of data for a given use context (e.g., a user viewing historical data, dashboard data, analytics report, etc.), while also respecting the user's relationship to the broader data ownership, lineage, and governance contexts, such as when the user is acting on behalf of an enterprise which is the actual owner of the data provider devices.
Additionally, the access management service 282 can receive data from a number of other sources and can use this information when dynamically generating the routing tables. In the depicted embodiment, the access management service 282 receives information from other authentication/authorization providers 270, which may include Role-based Access Control (RBAC) services, Relationship-based Access Control (RelBAC) services, and so on. More generally, any other information that is suitable for use in access control determinations can be used, consistent with the functionality described herein.
For example, the access management component 170 could receive aggregated business model data structures from the data aggregation component 255 as well as aggregated security policy data structures from the data aggregation component 245. The access management component 170 could generate a graph database based on the aggregated business model data, where the graph database models identities, resources and security relationships covered by the aggregated security policy data. Generally, a graph database refers to a particular type of database that, unlike conventional relational databases, uses graph structures having nodes, edges and properties to store data, and generally is configured to execute semantic queries against the stored graph structures.
Upon receiving an access request from a requesting entity (e.g., a data consumer application 225) for a particular resource within the IoT environment (e.g., data in data storage area 230), the access management component 170 can generate a semantic query to be executed against the graph database and configured to determine relationships between the requesting entity and other entities within the IoT environment. The access management component 170 could then execute the generated semantic query against the graph database to determine the requesting entities' relationships with other entities within the IoT environment. Additionally, the access management component 170 could retrieve one or more security policies (e.g., from the data aggregation component 245) corresponding to the requested resource, where the one or more security policies include one or more rules that define access requirements for the requested resource. The access management component 170 could then evaluate the determined relationships associated with the requesting entity to determine whether the relationships satisfy the security policy's rules associated with the requested resource. If the access management component 170 determines the relationships sufficiently satisfy the rules of the security policy, the access management component 170 can grant the request; if the access management component 170 determines the rules are not satisfied, the access management component 170 could deny the request.
As discussed above, embodiments provide an access control system that is dynamic, flexible, highly scalable and open. The access control system described herein can secure the control plane for IoT devices as well as protecting the data collected by the IoT devices, by utilizing graph technology to provide more fine-grained access control. By doing so, embodiments offer a technological improvement to conventional systems which rely on relational databases to perform role-based and attribute-based access control, as embodiments described herein offer flexibility and performance advantages over these conventional solutions while ensuring security is maintained within the IoT environment.
In the preceding, reference is made to various embodiments. However, the scope of the present disclosure is not limited to the specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Furthermore, although embodiments may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the preceding aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s).
The various embodiments disclosed herein may be implemented as a system, method or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied thereon.
Any combination of one or more computer-readable medium(s) may be utilized. The computer-readable medium may be a non-transitory computer-readable medium. A non-transitory computer-readable medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the non-transitory computer-readable medium can include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. Program code embodied on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages. Moreover, such computer program code can execute using a single computer system or by multiple computer systems communicating with one another (e.g., using a local area network (LAN), wide area network (WAN), the Internet, etc.). While various features in the preceding are described with reference to flowchart illustrations and/or block diagrams, a person of ordinary skill in the art will understand that each block of the flowchart illustrations and/or block diagrams, as well as combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer logic (e.g., computer program instructions, hardware logic, a combination of the two, etc.). Generally, computer program instructions may be provided to a processor(s) of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus. Moreover, the execution of such computer program instructions using the processor(s) produces a machine that can carry out a function(s) or act(s) specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality and/or operation of possible implementations of various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other implementation examples are apparent upon reading and understanding the above description. Although the disclosure describes specific examples, it is recognized that the systems and methods of the disclosure are not limited to the examples described herein but may be practiced with modifications within the scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense. The scope of the disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2021/040402 | 7/5/2021 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63048361 | Jul 2020 | US |
