Patent Application
20240314171
The present disclosure relates generally to security orchestration and management communications, and more particularly to methods and devices for a security service orchestration function between communication service providers.
Security orchestration and management is left outside the scope in information technology systems, and they do not deal with security concerns related to the deployment, configuration, or continuous operations of the information technology. Secure orchestration and management of virtualization, general forms of security management, e.g., monitoring, are fundamental for computer systems to operate robustly. Since there are no specifications for security management and orchestration interfaces, vendor-specific, non-standard interfaces may appear which makes interoperability difficult, unstable, risky, and costly.
In commercial agreements between Communication Service Providers (CSP), security clauses are embedded in generic Service Level Agreements (SLAs) or do not exist. If defined at all, the definitions are static and often ambiguous.
Typical security related SLA clauses refer to Information Security Management System frameworks, such as ISO 27001 or ISO/IEC 19086-4, and conformance is based on self-assessments or yearly audits and not in dynamic technical measures. More specific clauses may be used to define requirements for vulnerability management, incident handling and endpoint protection. The SLAs are used for defining the expected service level mostly in terms of quality, availability and responsibilities and the consequences in case the CSP fails to comply with the SLA. The evaluation and possible compensations are time-based and relatively infrequent. SLA renegotiations typically take place upon contract renewal and are not dynamic in the nature.
Communication service providers are facing an increasing number of security and privacy threats against their infrastructure, data they process and their services. Without visibility to the security posture and protective measures provided to them by other CSPs, it is difficult to judge in reliable and repeatable manner if their security objectives on security service levels are met and if there is a need for additional mitigation of security risks.
Generic Service Level Agreements do not necessarily include security aspects. Even if defined, the definitions are static and often ambiguous. There is no transparency of the security posture provided by the different CSPs so each individual CSP cannot properly assess the risks associated to their services.
Current disadvantages include:
Additionally, the following issues can be identified with current information technology systems:
According to some embodiments of inventive concepts, a security service orchestration function (SSOF) provides capabilities for security orchestration for an information technology system in a standardized manner. The SSOF enables submitting security service level requests based on security capabilities from a CSP to another CSP through standardized interfaces and reference points. The SSOF negotiates and coordinates the security capabilities and security attributes and their required levels between CSPs. The CSP or SSOF of the CSP can formulate a guaranteed, consistent, and unified common security baseline capability which is a synthesis of capabilities offered by all partner CSPs, i.e., represents the minimum common nominators for security capabilities from all partner CSPs. This common security baseline capability template is used by default by the CSP. The CSP monitors and communicates the compliance status and compliance violations for common security baseline capability on a regular basis or on demand. The CSP can select to use service specific capabilities which are fulfilled only by one or a few CSPs and monitor those attributes or service specific capabilities on a demand basis or according to service specific intervals.
According to some embodiments of inventive concepts, a method implemented by a security service orchestration function (SSOF) in a communication infrastructure, that includes a plurality of communication service providers (CSPs), for orchestration of a security service level agreement (S-SLA) includes receiving a S-SLA request, by a CSP of the plurality of CSPs, from one or more other CSPs of the plurality of CSPs. Each S-SLA request includes a plurality of requirements. The method also includes converting each S-SLA request into a consistent and unified S-SLA offerable to each other CSP. The consistent and unified S-SLA includes security attributes that the CSP is capable of providing the other CSPs. The method also includes offering the consistent and unified S-SLA to each other CSP that submitted the S-SLA request. The method further includes receiving a response from each other CSP. The response from each other CSP includes an acknowledgement or a decline of the consistent and unified S-SLA including a non-repudiation signature of acknowledgement or declining.
According to some embodiments of inventive concepts, a computing device includes processing circuitry and a memory coupled with the processing circuitry. The memory includes instructions that when executed by the processing circuitry causes the computing device to receive a S-SLA request, by a CSP of the plurality of CSPs, from one or more other CSPs of the plurality of CSPs. Each S-SLA request includes a plurality of requirements. The memory also includes instructions that when executed by the processing circuitry causes the computing device to convert each S-SLA request into a consistent and unified S-SLA offerable to each other CSP. The consistent and unified S-SLA includes security attributes that the CSP is capable of providing to the other CSPs. The memory also includes instructions that when executed by the processing circuitry causes the computing device to offer the consistent and unified S-SLA to each other CSP that submitted the S-SLA request. The memory further includes instructions that when executed by the processing circuitry causes the computing device to receive a response from each other CSP. The response from each other CSP includes an acknowledgement or a decline of the consistent and unified S-SLA including a non-repudiation signature of acknowledgement or declining.
According to some embodiments of inventive concepts, a computing device is adapted to receive a S-SLA request, by a CSP of the plurality of CSPs, from one or more other CSPs of the plurality of CSPs. Each S-SLA request includes a plurality of requirements. The computing device is also adapted to convert each S-SLA request into a consistent and unified S-SLA offerable to each other CSP. The consistent and unified S-SLA includes security attributes that the CSP is capable of providing to the other CSPs. The computing device is also adapted to offer the consistent and unified S-SLA to each other CSP that submitted the S-SLA request. The computing device is further adapted to receive a response from each other CSP. The response from each other CSP includes an acknowledgement or a decline of the consistent and unified S-SLA including a non-repudiation signature of acknowledgement or declining.
According to some embodiments of inventive concepts, a method implemented by a security service orchestration function (SSOF) in a communication infrastructure, that includes a plurality of communication service providers (CSPs), for orchestration of a security service level agreement (S-SLA) includes transmitting a S-SLA request, by a CSP of the plurality of CSPs, to one or more other CSPs of the plurality of CSPs. The S-SLA request includes security attributes and associated levels to support specific business services with specific security attributes. The method also includes receiving a response from each other CSP including a unique S-SLA based on the S-SLA request. The unique S-SLA from each other CSP includes security attributes the other CSP is capable of providing. The method also includes merging the security attributes received from each other CSP into a common security baseline template S-SLA for communication to business services users of the CSP.
According to some embodiments of inventive concepts, a computing device includes processing circuitry and a memory coupled with the processing circuitry. The memory includes instructions that when executed by the processing circuitry causes the computing device to transmit a S-SLA request, by a CSP of the plurality of CSPs, to one or more other CSPs of the plurality of CSPs. The S-SLA request includes security attributes and associated levels to support specific business services with specific security attributes. The memory also includes instructions that when executed by the processing circuitry causes the computing device to receive a response from each other CSP including a unique S-SLA based on the S-SLA request. The unique S-SLA from each other CSP includes security attributes the other CSP is capable of providing. The memory further includes instructions that when executed by the processing circuitry causes the computing device to merge the security attributes received from each other CSP into a common security baseline template S-SLA for communication to business services users of the CSP.
According to some embodiments of inventive concepts a computing device is adapted to transmit a S-SLA request, by a CSP of the plurality of CSPs, to one or more other CSPs of the plurality of CSPs. The S-SLA request includes security attributes and associated levels to support specific business services with specific security attributes. The computing device is also adapted to receive a response from each other CSP including a unique S-SLA based on the S-SLA request. The unique S-SLA from each other CSP includes security attributes the other CSP is capable of providing. The computing device is further adapted to merge the security attributes received from each other CSP into a common security baseline template S-SLA for communication to business services users of the CSP.
The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiments of inventive concepts. In the drawings:
Inventive concepts will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment.
The following description presents various embodiments of the disclosed subject matter. These embodiments are presented as teaching examples and are not to be construed as limiting the scope of the disclosed subject matter. For example, certain details of the described embodiments may be modified, omitted, or expanded upon without departing from the scope of the described subject matter.
S-SLA enablement and enforcement in a communication system or information technology system, e.g., system 100 is implemented as a security service orchestration function (SSOF) 202 embodied in a security service orchestrator 200 (
The communication system 100 or information technology system is designed to be able to offer a different mix of capabilities to meet very diverse service requirements at the same time. This means that security requirements for service may also be very different from industry to industry, service to service and per business customer or enterprise.
In general problems with existing solutions is that it is not possible for a CSP to place (dynamic) security requirements to another CSP and later monitor the compliance of how well these requirements are achieved by that other CSP. There is a need to have a well-defined standardized list of security attributes that can characterize security capabilities for the network services. These security attributes are negotiable between CSPs.
Different CSPs have different security needs to protect their service, thus negotiable security attributes may vary a lot depending on the CSP and the industry segment to which the CSP provides services. A CSP operating in a public safety area may have rather different security requirements to protect their services than for instance a CSP offering services in the automotive, energy, healthcare, or manufacturing industry.
Negotiable security attributes can be categorized based on the main security principles: confidentiality, integrity, authentication and authorization, availability, expanded with separate categories for isolation and data sovereignty.
CSPs 104 can define in a negotiation phase what security attributes they want to include in their Security Service Level Agreements and whether they are applicable for all the services or part of the services. Attribute values, that is, strength of security protection may vary when service is offered for different locations or from different data centers. Examples of security attribute categories and attribute values or strength of security protection include:
Different crypto algorithms and strength for those algorithms can be requested. Examples for confidentiality attributes that can be requested for the services are, e.g., different strengths for Advanced Encryption Standard (AES): AES-128, AES-192, AES-256 and Triple Data Encryption Algorithm (TDES).
Each CSP has their own security intent and objectives which is driven by security risk evaluation and understanding. Each CSP translates this security risk evaluation into security attributes defined in the CSP's S-SLA. For example, the S-SLA may include information as to what extent the CSP tolerates variation in different attributes and what measures are mandatory to achieve their desired protection level.
The example in
The SSOF 202 is the primary security orchestration function communicating between CSPs 104 and supporting security management function 206. The objective of SSOF 202 is to ensure consistency of security policies. The described mechanism can be applied to privacy attributes in a similar way.
Core functionality of SSOF 202 in a communication infrastructure is to:
An example of a method of operation of a SSOF will be described in more detail with reference to
In block 402, the method 400 includes exchanging information security attributes and associated attribute value ranges between the plurality of CSPs that each CSP is capable of providing the other CSPs or that one CSP is capable of requesting from another CSP.
In block 404, the method 400 includes receiving a S-SLA request, by a CSP of the plurality of CSPs, from one or more other CSPs of the plurality of CSPs. Each S-SLA request includes a plurality of requirements or security requirements. In some examples, receiving the S-SLA request includes receiving a S-SLA request to support specific business services with specified security attributes.
The S-SLA request from each other CSP 104a-104n includes a plurality of optional information elements or objects and mandatory information elements or objects. Examples of the optional information elements or objects and mandatory information elements or objects are included in the table below.
In some examples, the plurality of optional information elements or objects include, confidentiality attributes, target integrity attributes, target authentication attributes, target availability attributes, target non-repudiation attributes, target isolation attributes, target data sovereignty attributes, validity condition, temporal validity condition, subscription of S-SLA compliance monitoring events, allowed internet protocol (IP) domains, and extra data protection controls. In some examples, the mandatory information elements or objects include a target CSP identifier.
In block 406, the method 400 includes converting each S-SLA request into a consistent and unified S-SLA that is offerable to each other CSP. The consistent and unified S-SLA includes security attributes that the CSP is capable of providing the other CSPs. The method 400 in block 406 also includes negotiating a set of appropriate security attributes and associated levels or values with each other CSP 104a-104n, that the CSP 104 is capable of providing each of the other CSPs 104a-104n. In some examples, the consistent and unified S-SLA corresponds to a common security baseline capacity S-SLA 112 that is offered by the CSP 104 to each of the other CSPs 104a-104b. An example of a process for generating the common security baseline capacity S-SLA 112 is described with reference to block 702 in
In block 408, the method 400 includes offering the consistent and unified S-SLA to each other CSP 104a-104n that submitted the S-SLA request.
In block 410, the method 400 includes receiving a response from each other CSP 104a-104n. The response from each other CSP 104a-104n includes an acknowledgement or a decline of the consistent and unified S-SLA including a non-repudiation signature of acknowledgement or declining.
In block 412, the method 400 includes transforming each S-SLA request into security policies and controls to be enforced within an infrastructure of the CSP 104.
In block 414, the method 400 includes monitoring of compliance with the consistent and unified S-SLA of each other CSP that acknowledged or accepted the consistent and unified S-SLA.
In block 602, the method 600 includes receiving, from the SSOF, security requirement and security attribute information for fulfilling the S-SLA of each other CSP and mapping the security requirement and security attribute information into security policies and security controls for enforcement within the communication infrastructure and network entities of the CSP.
In block 606, the method 600 includes supporting security management activities related to safeguarding of network functions (NF) and network elements (NE).
In block 608, the method 600 includes monitoring S-SLA status of NF and NE according to set security attributes.
In block 610, the method 600 includes calculating compliance status in real-time for the S-SLA of each CSP and notifying compliance scores and compliance violations to the security service orchestration function.
In block 612, the method 600 includes maintaining historical information for S-SLA compliance per CSP.
In block 702, the method 700 includes exchanging information security attributes and associated attribute value ranges between the plurality of CSPs that each CSP is capable of providing the other CSPs. Referring also to
In block 704, the method 700 includes transmitting a S-SLA request, by a CSP of the plurality of CSPs, to one or more other CSPs of the plurality of CSPs. The S-SLA request includes security attributes and associated levels to support specific business services with specific security attributes. Referring also to
In block 706, the method 700 includes receiving a response from each other CSP (CSP partner in
Similar to that previously described with reference to block 404 in
In block 708 of
The method 700 in block 708 also includes negotiating a set of appropriate security attributes and associated levels that each other CSP is capable of providing the CSP that transmitted the S-SLA request.
In accordance with some examples, the method 700 in block 710 includes monitoring, by the CSP, that the other CSPs are in compliance with the common security baseline template S-SLA. In accordance with other examples monitoring, by the CSP, includes monitoring a service specific capability on demand or at service specific intervals.
The CSP 104 monitors S-SLA compliance and requests reports from another CSP (CSP partner) on regular intervals. This is repeated per CSP or CSP partner based on the common security baseline capacity. The CSP 104 can request a compliance snapshot on demand for specific services based on an explicit security capability agreement from a specific CSP at random intervals or service specific regular intervals for monitoring service specific S-SLA fulfillment. If S-SLA compliance deviates from the agreed level, then a settlement process according to the S-SLA or business agreement is triggered as illustrated in
1. A method implemented by a security service orchestration function (SSOF) in a communication infrastructure, that includes a plurality of communication service providers (CSPs), for orchestration of a security service level agreement (S-SLA), the method comprising:
2. The method of embodiment 1, further comprising exchanging information security attributes and associated attribute value ranges between the plurality of CSPs that each CSP is capable of providing the other CSPs.
3. The method of any of embodiments 1-2, wherein receiving the S-SLA request comprises receiving a S-SLA request to support specific business services with specified security attributes.
4. The method of any of embodiments 1-3, further comprising negotiating a set of appropriate security attributes and levels that the CSP is capable of providing each of the other CSPs.
5. The method of any of embodiments 1-4, wherein the S-SLA request from each other CSP comprises a plurality of optional information elements or objects and a mandatory information element or object,
6. The method of any of embodiments 1-5, further comprising transforming each S-SLA request into security policies and controls to be enforced within an infrastructure of the CSP.
7. The method of any of embodiments 1-6, further comprising monitoring of compliance with the consistent and unified S-SLA of each other CSP that acknowledged or accepted the consistent and unified S-SLA.
8. The method of any of embodiments 1-7, wherein the SSOF interacts with supporting security management functions to perform a set of functions comprising:
9. The method of embodiment 8, wherein the supporting security management functions comprise at least one of:
10. The method of any of embodiments 1-9, wherein the SSOF comprises an Nssof reference point configured to interface with each other CSP for negotiating the S-SLA with each other CSP and for exchanging information on S-SLA security attributes.
11. A computing device (300) comprising:
12. The computing device of embodiment 11, wherein the memory includes instructions that when executed by the processing circuitry causes the computing device to perform operations according to any of embodiments 2-10.
13. A computing device (300) adapted to:
14. The computing device of embodiment 13 further adapted to perform according to any of embodiments 2-10.
15. A computer program comprising program code to be executed by processing circuitry (303) of a computing device (300, 301), whereby execution of the program code causes the computing device (300, 301) to perform operations according to any of embodiments 1-10.
16. A computer program product comprising a non-transitory storage medium including program code to be executed by processing circuitry (303) of a computing device (300), whereby execution of the program code causes the computing device (300, 301) to perform operations according to any of embodiments 1-10.
17. A method implemented by a security service orchestration function (SSOF) in a communication infrastructure, that includes a plurality of communication service providers (CSPs), for orchestration of a security service level agreement (S-SLA), the method comprising:
18. The method of embodiment 17, further comprising exchanging information security attributes and associated attribute value ranges between the plurality of CSPs that each CSP is capable of providing the other CSPs.
19. The method of any of embodiments 17-18, further comprising negotiating a set of appropriate security attributes and associated levels that each other CSP is capable of providing the CSP that transmitted the S-SLA request.
20. The method of any of embodiments 17-19, wherein the S-SLA request comprises a plurality of optional information elements or objects and a mandatory information element or object,
21. The method of any of embodiments 17-20, further comprising monitoring, by the CSP, that the other CSPs are in compliance with the common security baseline template S-SLA.
22. The method of any of embodiments 17-21, further comprising monitoring, by the CSP, a service specific capability on demand or at service specific intervals.
23. The method of any of embodiments 17-22, wherein the SSOF interacts with supporting security management functions to perform a set of functions comprising:
24. The method of embodiment 23, wherein the supporting security management functions comprise at least one of:
25. The method of any of embodiments 17-24, wherein the SSOF comprises an Nssof reference point configured to interface with each other CSP for negotiating the S-SLA with each other CSP and for exchanging information on S-SLA security attributes.
26. A computing device (300) comprising:
27. The computing device of embodiment 26, wherein the memory includes instructions that when executed by the processing circuitry causes the computing device to perform operations according to any of embodiments 18-25.
28. A computing device (300) adapted to:
29. The computing device of embodiment 28 further adapted to perform according to any of embodiments 18-25.
30. A computer program comprising program code to be executed by processing circuitry (303) of a computing device (300, 301), whereby execution of the program code causes the computing device (300, 301) to perform operations according to any of embodiments 17-25.
31. A computer program product comprising a non-transitory storage medium including program code to be executed by processing circuitry (303) of a computing device (300), whereby execution of the program code causes the computing device (300, 301) to perform operations according to any of embodiments 17-25.
Additional explanation is provided below.
The innovative steps in Security Service Orchestrator Function are that.
Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.
Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.
Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.
The term unit may have conventional meaning in the field of electronics, electrical devices and/or electronic devices and may include, for example, electrical and/or electronic circuitry, devices, modules, processors, memories, logic solid state and/or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and/or displaying functions, and so on, as such as those that are described herein.
In the above description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of present inventive concepts. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which present inventive concepts belong. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
When an element is referred to as being “connected”, “coupled”, “responsive”, or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being “directly connected”, “directly coupled”, “directly responsive”, or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, “coupled”, “connected”, “responsive”, or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term “and/or” includes any and all combinations of one or more of the associated listed items.
It will be understood that although the terms first, second, third, etc. may be used herein to describe various elements/operations, these elements/operations should not be limited by these terms. These terms are only used to distinguish one element/operation from another element/operation. Thus, a first element/operation in some embodiments could be termed a second element/operation in other embodiments without departing from the teachings of present inventive concepts. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification.
As used herein, the terms “comprise”, “comprising”, “comprises”, “include”, “including”, “includes”, “have”, “has”, “having”, or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components, or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions, or groups thereof. Furthermore, as used herein, the common abbreviation “e.g.,”, which derives from the Latin phrase “exempli gratia,” may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation “i.e.,”, which derives from the Latin phrase “id est,” may be used to specify a particular item from a more general recitation.
Example embodiments are described herein with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).
These computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks. Accordingly, embodiments of present inventive concepts may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as “circuitry,” “a module” or variants thereof.
It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. 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/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated, and/or blocks/operations may be omitted without departing from the scope of inventive concepts. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.
Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present inventive concepts. All such variations and modifications are intended to be included herein within the scope of present inventive concepts. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the examples of embodiments are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of present inventive concepts. Thus, to the maximum extent allowed by law, the scope of present inventive concepts are to be determined by the broadest permissible interpretation of the present disclosure including the examples of embodiments and their equivalents, and shall not be restricted or limited by the foregoing detailed description.
At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2021/068807 | 7/7/2021 | WO |
