BACKGROUND

[0001] Embodiments of the present disclosure relate to apparatus and method for wireless communication.

[0002] An operating system (OS) is software that acts as an interface between a user and computer hardware. Moreover, an OS performs basic tasks like file management, memory management, process management, handling input and output, and controlling peripheral devices, such as disk drives and printers. Some popular OSs include Linux Operating System, macOS, Android OS, Windows Operating System, etc.

SUMMARY

[0003] According to one aspect of the present disclosure, a client device is provided. The client device may include a scenario monitor. The scenario monitor may be configured to maintain a scenario policy associated with access to a restricted resource. The client device may also include an application client. The application client may be configured to receive a request for access to the restricted resource. The application client may be configured to perform a self-permission check associated with the request. In response to the self-permission check indicating that access to the restricted resource is permitted, the scenario monitor may be further configured to perform a first scenario policy check associated with the request based on the scenario policy. The client device may further include an activity manager service. The activity manager service may be configured to, in response to the first scenario policy check indicating that access to the restricted resource is permitted, perform a component permission check associated with the restricted resource.

[0004] According to another aspect of the present disclosure, a terminal device is provided. The terminal device may include a scenario monitor. The scenario monitor may be configured to maintain a scenario policy associated with access to a restricted resource via an application. The terminal device may include an application server. In response to an attempt by an application client to access the restricted resource, the application server may be configured to perform an explicit permission check associated with the application client. In response to the client permission check indicating access to the restricted resource is permitted, the scenario monitor may be further configured to perform a third scenario policy check.

[0005] According to yet another aspect of the present disclosure, an OS framework of a terminal device is provided. The OS framework may include a scenario monitor. The scenario monitor may be configured to maintain a scenario policy associated with access to a restricted resource via an application. The scenario monitor may be configured to maintain at least one scenario rule associated with the scenario policy. In response to a scenario policy change, the scenario monitor may be configured to read the at least one scenario rule. In response to the scenario policy change violating the at least one scenario rule, the scenario monitor may disable access to the restricted resource.

[0006] According to still another aspect of the disclosure, a method of a client device is provided. The method may include maintaining, by a scenario monitor, a scenario policy associated with access to a restricted resource via an application. The method may include receiving, by an application client, a request for access to the restricted resource. The method may include performing, by the application client, a self-permission check associated with the request. In response to the self-permission check indicating that access to the restricted resource is permitted, the method may further include performing, by the scenario monitor, a first scenario policy check associated with the request based on the scenario policy. In response to the first scenario policy check indicating that access to the restricted resource is permitted, the method may further include performing, by an activity manager service, a component permission check associated with the restricted resource.

[0007] According to still a further aspect of the disclosure, a method of a server device is provided. The method may include maintaining, by a scenario monitor, a scenario policy associated with access to a restricted resource via an application. In response to an attempt by an application client to access the restricted resource, the method may further include performing, by an application server, a client permission check associated with the application client. In response to the client permission check indicating access to the restricted resource is permitted, the method may further include performing, by the scenario monitor, a third scenario policy check.

[0008] According to still another aspect of the disclosure, a method of a scenario monitor is provided. The method may include maintaining a scenario policy associated with access to a restricted resource via an application. The method may include maintaining at least one scenario rule associated with the scenario policy. In response to a scenario policy change, the method may include reading the at least one scenario rule. In response to the scenario policy change violating the at least one scenario rule, the method may include disabling access to the restricted resource. [0009] These illustrative embodiments are mentioned not to limit or define the present disclosure, but to provide examples to aid understanding thereof. Additional embodiments are discussed in the Detailed Description, and further description is provided there.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present disclosure and, together with the description, further serve to explain the principles of the present disclosure and to enable a person skilled in the pertinent art to make and use the present disclosure.

[0011] FIG. 1 A illustrates an exemplary client device, according to some embodiments of the present disclosure.

[0012] FIG. IB illustrates an exemplary user interface of a client device or a server device, according to some embodiments of the present disclosure.

[0013] FIG. 2A illustrates a block diagram of an apparatus including an application and OS framework, according to some embodiments of the present disclosure.

[0014] FIG. 2B illustrates a block diagram of an exemplary client device and an exemplary server device of a distributed OS environment, according to some embodiments of the present disclosure.

[0015] FIG. 3 illustrates a flow chart of a first exemplary method of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure.

[0016] FIG. 4 illustrates a flow chart of a second exemplary method of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure.

[0017] FIG. 5 illustrates a flow chart of a third exemplary method of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure.

[0018] FIG. 6 illustrates a flow chart of a fourth exemplary method of wireless communication in a distributed OS environment, according to some embodiments of the present disclosure.

[0019] FIG. 7 illustrates a flow chart of a fifth exemplary method of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure.

[0020] FIG. 8 illustrates a flow chart of a sixth exemplary method of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure.

[0021] FIG. 9 illustrates a seventh exemplary method of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure.

[0022] FIG. 10 illustrates an exemplary wireless network, according to some embodiments of the present disclosure.

[0023] FIG. 11 illustrates a block diagram of an exemplary node, according to some embodiments of the present disclosure.

[0024] Embodiments of the present disclosure will be described with reference to the accompanying drawings.

DETAILED DESCRIPTION

[0025] Although specific configurations and arrangements are discussed, it should be understood that this is done for illustrative purposes only. A person skilled in the pertinent art will recognize that other configurations and arrangements can be used without departing from the spirit and scope of the present disclosure. It will be apparent to a person skilled in the pertinent art that the present disclosure can also be employed in a variety of other applications.

[0026] It is noted that references in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” “some embodiments,” “certain embodiments,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of a person skilled in the pertinent art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0027] In general, terminology may be understood at least in part from usage in context. For example, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a,” “an,” or “the,” again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0028] Various aspects of wireless communication systems will now be described with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, units, components, circuits, steps, operations, processes, algorithms, etc. (collectively referred to as “elements”). These elements may be implemented using electronic hardware, firmware, computer software, or any combination thereof. Whether such elements are implemented as hardware, firmware, or software depends upon the particular application and design constraints imposed on the overall system.

[0029] The techniques described herein may be used for various wireless communication networks, such as code division multiple access (CDMA) system, time division multiple access (TDMA) system, frequency division multiple access (FDMA) system, orthogonal frequency division multiple access (OFDMA) system, single-carrier frequency division multiple access (SC- FDMA) system, wireless local area network (WLAN) system, and other networks. The terms “network” and “system” are often used interchangeably. A CDMA network may implement a radio access technology (RAT), such as Universal Terrestrial Radio Access (UTRA), evolved UTRA (E-UTRA), CDMA 2000, etc. A TDMA network may implement a RAT, such as the Global System for Mobile Communications (GSM). An OFDMA network may implement a RAT, such as LTE or NR. A WLAN system may implement a RAT, such as Wi-Fi. The techniques described herein may be used for the wireless networks and RATs mentioned above, as well as other wireless networks and RATs. Moreover, the techniques described herein may be used for various operating systems, such as Linux Operating System, Windows Operating System, virtual machine system (VMS), OS/400, Advanced Interactive Executive (AIX), z/OS, Android OS, macOS, etc. Thus, although some of the embodiments are described below with reference to the Android OS, the present techniques should not be considered as limited thereto.

[0030] As set forth herein, the terms “to deny,” “denied,” “not allowed,” “not permitted,” and “not granted” may be used interchangeably. Also, as set forth herein, the terms “allowed,” “to allow,” “permitted,” “to permit,” “granted,” and “to grant” may be used interchangeably.

[0031] OS settings enable a user to set permissions for various applications. These permissions support user privacy by protecting access to various restricted resources (also referred to as “application services”). These restricted resources may include, e.g., restricted data, system state data, user contact information, microphone access, camera access, access to photos/videos/audio files, etc. For example, through the OS settings on a mobile device, a user may opt for the OS to request permission each time the user attempts to access the device’ s camera through, e.g., Facebook Messenger. Unfortunately, no similar permission mechanisms are available for enabling scenario-based access to restricted resources with similar protections.

[0032] Thus, there exists an unmet need for a scenario-based permission mechanism that enables and protects access to a restricted resource.

[0033] To overcome these and other challenges, the present disclosure provides a scenariobased permission mechanism that may enable a user to set scenario-based permissions to further enhance security. In other words, the scenario-based permission mechanism provides a scenario policy that may be checked prior to access to a restricted resource being permitted. There may be many use cases in which the present scenario-based permission mechanism may be beneficial.

[0034] By way of one example, a user may enable the OS so that certain work-related documents to be opened only during typical workday hours, e.g., 9:00 am to 5:00 pm Monday through Friday. In another example, a user may enable the OS of a cell phone such that, when driving, a phone call can only be answered when the cell phone is connected to the vehicle via Bluetooth. Additional details of the present scenario-based permission mechanism are provided below in connection with FIGs. 1-11.

[0035] FIG. 1A illustrates an exemplary OS environment 100, in which the exemplary scenario-based permission mechanism may be implemented, according to some embodiments of the present disclosure. FIG. IB illustrates an exemplary user interface 101 of application settings that support a scenario-based policy for access to restricted resources, according to some embodiments of the present disclosure. FIGs. 1 A and IB will be described together.

[0036] As shown in FIG. 1A, OS environment 100 may include a standalone device, such as client device 102. Client device 102 may be any terminal device, such as a mobile phone, a desktop computer, a laptop computer, a tablet, a vehicle computer, a gaming console, a printer, a positioning device, a wearable electronic device, a smart TV, a smart device, a smart sensor, or any other device capable of receiving, processing, and transmitting information, such as any member of a vehicle-to-everything (V2X) network, a cluster network, a smart grid node, or an Internet-of-Things (loT) node. It is understood that client device 102 is illustrated as a mobile phone simply by way of illustration and not by way of limitation. Client device 102 may include an OS, such as Linux Operating System, Windows Operating System, VMS, OS/400, AIX, z/OS, Android OS, macOS, or any other OS.

[0037] Furthermore, OS environment 100 is depicted as a standalone environment that includes client device 102. As a standalone environment, client device 102 may access restricted resources locally based on the scenario-based permission mechanism. However, in some embodiments, OS environment 100 may include a distributed environment with a plurality of devices (as shown in FIG. 2B), which each operate using the same or different OS. When implemented as a distributed environment, the scenario-based permission mechanism may be implemented in a distributed manner, such that client device 102 may access restricted resources located at another device within the OS environment based on the exemplary scenario-based permission mechanism. Thus, the exemplary scenario-based permission mechanism may apply to both local access to restricted resources and/or remote access to restricted resources.

[0038] Referring to FIG. 1 A, client device 102 is shown displaying the user interface of an application 104, e.g., Facebook Messenger. Within application 104, icons related to various restricted resources (e.g., access to a camera 106, photos, a microphone, etc.) may be displayed. As seen in FIG. 1 A, the user attempts to access camera 106 via application 104 by interacting with the user interface. By accessing camera 106 via application 104, the user may capture an image that can be communicated directly through application 104.

[0039] In this example, the user of client device 102 has not enabled access to camera 106 via application 104. When this happens, client device 102 may display a scenario policy change screen 108 that requests a scenario policy change (e.g., which may be set by the user) to enable access to camera 106 via application 104. Here, the scenario policy change includes certain scenario rules, such as a start time, an end time, and a location. The location may be identified based on an IP address (e.g., work, home, hotel, home of a friend, etc.) or based on other location information. Then, when the user selects “Turn On” by interacting with the scenario policy change screen 108, client device 102 may display a confirmation pop-up screen 110 that allows the user to allow or deny the change to the scenario policy. When allowed, the user may access camera 106 via application 104 from 9:00 am to 5:00 pm, while at the office. It is understood that the scenario-based policy is not limited to a start time, an end time, and a location. Instead, the scenario-based policy may include any combination of permissions and/or restrictions associated with any type of scenario, including but not limited to, e.g., time, location, activity, battery power, remote device access, etc. In another example, a scenario-based policy may include that when the battery power is less than or equal to 20%, the OS may be configured to block a user from accessing music via client device 102.

[0040] Referring to FIG. IB, a user interface 101 depicting example application permissions is shown. The application permissions may include a permission list 130 associated with application 104. In the example depicted in FIG. IB, permission list 130 includes a set of camera scenario rules 140. In this example, permission list 130 permits access to certain restricted resources via application 104, while denying access to others. For example, camera scenario rules 140 depicted in FIG. IB permits daily access to 106 via application 104 from 9:00am-5 :00pm, while client device 102 is located at the office. Permission list 130 also permits access to contacts, all files and media, and the microphone while application 104 is in use. On the other hand, permission list 130 deny access to the calendar, location information, phone, and SMS messaging via application 104. It is understood that a user may set scenario rules for any type of restricted resource or combination of restricted resources that may be accessed via application 104 and/or via client device 102. Additional details of the scenario-based permission mechanism implemented are provided below in connection with FIGs. 2A-9.

[0041] FIG. 2A illustrates a block diagram of an apparatus 200 including an application 104 and an OS framework 204, according to some embodiments of the present disclosure. Apparatus 200 may include, e.g., client device 102. Application 104 may include an application client 206, application server 208, and application settings 214. OS framework 204 may include package manager service 210, activity manager service 212, and scenario monitor 250.

[0042] Referring to FIG. 2A, application client 206 and application server 208 may be associated with the same application, such as application 104 in FIGs. 1A and IB. Within application 104, application client 206 may be used to access a restricted resource via application server 208 based on scenario rules that make up a scenario policy enforced by scenario monitor 250.

[0043] Referring to FIG. 2 A, application 104 may include an application client 206, application server 208, application settings 214, and server agent 220. Application client 206 and application server 208 may be associated with the same application, such as application 104 in FIGs. 1 A and IB. OS framework 204 may include a package manager service (PMS) 210 that may be configured to maintain package information associated with local access to application server 208 and/or remote package information associated with remote access to a remote application server (not shown). Various components of apparatus 200 may perform various permission checks as described below to enable local or remote access to a restricted resource using the exemplary scenario-based permission mechanism.

[0044] Application server 208 may act as a gatekeeper through which access to a restricted resource may be obtained, either locally or remotely, by an application client. For example, application client 206 may access local restricted resources via application server 208. Moreover, application server 208 also may enable access to restricted resources located at apparatus 200 by a remote application client. To initiate the process of accessing a restricted resource, application client 206 may perform a self-permission check. When the self-permission check indicates that permission has not been granted or is not allowed based on scenario rules, application client 206 may request user-permission for access to a restricted resource.

[0045] In some embodiments, application client 206 may perform the self-permission check either locally or remotely. When remotely, application client 206 may communicate with the remote device (not shown in FIG. 2A). In either case, the self-permission check may determine whether access to the restricted resource via application 104 is allowed based on client permission information. Client permission information may be maintained in a manifest file of application client 206 and/or by application settings 214. When application client 206 requests remote access, the client permission information may be maintained by a local service agent, a remote service agent, or a remote application client.

[0046] The self-permission check may also include a scenario policy check. For example, if the self-permission check indicates that permission is granted, scenario monitor 250 may perform a scenario policy check to determine whether access to the restricted resource is permitted based on scenario rules.

[0047] When the self-permission check indicates that remote access to the restricted resource has not been permitted, application client 206 may be configured to request userpermission for access to the restricted resource. The user-permission check may include a request for a scenario policy change, as described above in connection with FIG. 1A. When a scenario policy change is permitted by the user, a scenario policy check may be performed for the new scenario policy before permission is granted.

[0048] In response to the self-permission check and/or user-permission request permitting access to the restricted resource, activity manager service 212 may perform a component permission check before application client 206 communicates with application server 208 regarding the restricted resource. Activity manager service 212 may perform the component permission check using information maintained by package manager service 210. For example, activity manager service 212 may access client permission information associated with application client 206 maintained in a manifest file at application client 206, as well as package information maintained at package manager service 210. When the restricted resource is remote, activity manager service 212 may access the client permission information and remote package information, which is maintained by package manager service 210 and associated with the permission requirements of the remote application server. Then, based on a comparison of the client permission information and the package information, activity manager service 212 may determine whether access to the restricted resource is possible.

[0049] In some embodiments, client permission information and package information may be default permissions created by OS framework 204 and/or custom permissions created by the application 104 (e.g., based on user settings). Client permission information may include, e.g., local name, local label, local description, local protection level, etc. Package information (local or remote) may include, e.g., name, label, description, protection level, etc. When access to the restricted resource is requested, application client 206 may declare client permission information (also referred to as “user-permission information”) in a manifest file as follows:

<user-permission android:name="com.mycompany.permission.Example"/>, where “com. mycompany. permission. Example” is the name of the permission.

[0050] Application 104 may declare the server requirements inside the manifest file of application server 208. For example, when the component includes an activity, such as taking a picture, the server requirements may be declared as follows:

<activity android:name="com. example. project.ExampleActivity" android:permission=" com. mycompany. permission.Example "

</activity>.

[0051] If the same permission name (e.g., com. mycompany. permission.Example) are declared by both the client permission information and the server requirements, scenario monitor 250 may perform a scenario-policy check. The scenario policy check may be performed prior to application client 206 communicating the request for access to the restricted resource “com. example. project.ExampleActivity” to application server 208. Prior to granting access, application server 208 may perform an explicit component check. The explicit component check may include a scenario policy check by scenario monitor 250.

[0052] Moreover, apparatus 200 may include a service agent 220. Service agent 220 may be configured to establish a communication channel with a remote service agent of a remote device when implementing a distributed permission mechanism. Moreover, service agent 220 may be configured to sync remote package information, e.g., during system bootup, when an application and/or application service is installed/uninstalled, etc. Further, service agent 220 may act as proxies that execute commands for remote applications and import/export application services from/to another device.

[0053] FIG. 2B illustrates a block diagram 201 of client device 102 and server device 120 of an exemplary distributed OS environment, according to some embodiments of the present disclosure. As shown in FIG. 2B, client device 102 may include a set of application clients 226a, a set of application servers 228a, a package manager service 230a, an activity manager service 232a, application settings 234a, a service agent 236a, and a scenario monitor 275a. Each of set of application clients 226a, set of application servers 228a, package manager service 230a, activity manager service 232a, application settings 234a, service agent 236b, and scenario monitor 275a may be configured to perform corresponding operations described above in connection with FIG. 2 A. Server device 120 may include a set of application clients 226b, a set of application servers 228b, a package manager service 230b, an activity manager service 232b, application settings 234b, service agent 236b, and scenario monitor 275b. Each of set of application clients 226b, set of application servers 228b, package manager service 230b, activity manager service 232b, application settings 234b, service agent 236b, and scenario monitor 275b may be configured to perform corresponding operations described above in connection with FIG. 2A. Each of service agent 236a and service agent 236b may be configured to establish a communication channel between client device 102 and server device 120 when implementing a distributed scenario-based permission mechanism. Moreover, service agent 236a and service agent 236b may be configured to sync remote package information, e.g., during system bootup, when an application and/or application service is installed/uninstalled, etc. Further, service agent 236a and service agent 236b may act as proxies that execute commands for remote applications and import/export application services from/to another device.

[0054] FIG. 3 illustrates a flow chart of a first exemplary method 300 of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure. Exemplary method 300 may be performed by a client device, e.g., such as client device 102, application 104, apparatus 200, OS framework 204, application client 206, application server 208, package manager service 210, activity manager service 212, service agent 220, service agent 236a, scenario monitor 250, 275a, and/or node 1100. Method 300 may include operations 302- 314 as described below. It is to be appreciated that some of the operations may be optional, and some of the operations may be performed simultaneously, or in a different order than shown in FIG. 3.

[0055] Referring to FIG. 3, at 302, the apparatus may initiate access to a restricted resource. For example, referring to FIG. 1A, application 104 may display icons related to various restricted resources, such as access to a camera 106, photos, a microphone, etc., within a user interface. When the user interacts with one of the icons, operations associated with access to the restricted resource may be initiated.

[0056] At 304, the apparatus may perform a self-permission check to determine whether access to a restricted resource via an application is permitted. For example, referring to FIG. 2A, application client 206 may perform the self-permission check either locally or remotely, depending on where the restricted resource is located. In either case, the self-permission check may determine whether access to the restricted resource via application 104 is allowed. The determination may be made based on client permission information. Client permission information may be maintained in a manifest file of application client 206 and/or by application settings 214. The self-permission check may also include a scenario policy check. If the self-permission check indicates that permission is granted, scenario monitor 250 may perform a scenario policy check to determine whether access to the restricted resource is permitted based on scenario rules.

[0057] At 306, in response to the self-permission check indicating that access to the restricted resource is not permitted, the apparatus may request user-permission to access the restricted resource at the server device. For example, referring to FIG. 2A, when the selfpermission check indicates that remote access to the restricted resource has not been permitted, application client 206 may be configured to request user-permission for access to the restricted resource. The user-permission check may include a request for a scenario policy change. When a scenario policy change is permitted by the user, a scenario policy check may be performed for the new scenario policy before permission is granted.

[0058] At 308, the apparatus may determine whether user-permission has been granted. When user-permission has not been granted, the operations may move to operations 314. Otherwise, when user-permission is granted, the operations may move to 310.

[0059] At 310, the apparatus may perform an OS framework permission check. For example, referring to FIG. 2A, in response to the self-permission check and/or user-permission request permitting access to the restricted resource, activity manager service 212 may perform a component permission check. The component permission check may be performed using information maintained by package manager service 210. For example, activity manager service 212 may access client permission information associated with application client 206 and package information associated with server requirements of application server 208. When the restricted resource is remote, activity manager service 212 may use the remote package information associated with the remote application server. Based on a comparison of the client permission information and the server requirements, activity manager service 212 may determine whether access to the restricted resource is possible. When the client permission and the server requirements match, scenario monitor may perform a scenario policy check before application client 206 activates the restricted resource via application server 208.

[0060] At 312, the apparatus may access the restricted resource. For example, referring to FIG. 2A, application client 206 may access the restricted resource via application server 208 when the OS framework permission check and its scenario policy check indicate that permission is granted.

[0061] FIG. 4 illustrates a flow chart of a second exemplary method 304 of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure. The operations described in FIG. 4 may include the sub-operations of method 304 in FIG. 3, according to some embodiments. Exemplary method 304 may be performed by a client device, e.g., such as client device 102, apparatus 200, application 104, application client 206, scenario monitor 250, 275a, and/or node 1100. Method 304 may include operations 402-410 as described below. It is to be appreciated that some of the operations may be optional, and some of the operations may be performed simultaneously, or in a different order than shown in FIG. 4.

[0062] Referring to FIG. 4, at 402, client device 102 may initiate the self-permission check. [0063] At 404, client device 102 may determine whether permission to access the restricted resource is granted. For example, referring to FIG. 2A, the self-permission check may determine whether access to the restricted resource via application 104 is allowed based on client permission information. Client permission information may be maintained in a manifest file of application client 206 and/or by application settings 214. When permission is granted, the operations may move to step 406. Otherwise, the operations may move to operation 410.

[0064] At 406, client device 102 may perform a scenario policy check. For example, referring to FIG. 2B, scenario monitor 250 may perform a scenario policy check to determine whether access to the restricted resource is permitted based on scenario rules. When the scenario policy check indicates that the access to the restricted resource is permitted based on the scenario rules, the operation may move to operation 408. Otherwise, the operation may move to operation 410.

[0065] FIG. 5 illustrates a flow chart of a third exemplary method 306 of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure. The operations described in FIG. 5 may include the sub- operations of method 306 in FIG. 3, according to some embodiments. Exemplary method 306 may be performed by a client device, e.g., such as client device 102, application 104, apparatus 200, application client 206, scenario monitor 250, 275a, and/or node 1100. Method 306 may include operations 502-512 as described below. It is to be appreciated that some of the operations may be optional, and some of the operations may be performed simultaneously, or in a different order than shown in FIG. 5.

[0066] At 502, client device 102 may initiate the user-permission request. For example, the user-permission request may be initiated when a user of client device 102 interacts with the camera icon, as shown in FIG. 1 A.

[0067] At 504, client device 102 may display a user interface associated with the userpermission request. The user interface may display a request for the scenario configuration, as shown at 506. For example, referring to FIG. 1A, the user of client device 102 has not enabled access to camera 106 via application 104. When this happens, client device 102 may display a scenario policy change screen 108 that requests the user scenario select scenario policy change to enable access to camera 106 via application 104. Here, the scenario policy change includes certain scenario rules, namely, a start time, end time, and location. The location may be identified based on an IP address (e.g., work, home, hotel, home of a friend, etc.) or based on other location information. Then, when the user selects “Turn On” by interacting with the scenario policy change screen 108, client device 102 may display a confirmation pop-up screen 110 that allows the user to allow or deny the change to the scenario policy. When allowed, the user will be able to access camera 106 via application 104 from 9:00 am to 5:00pm while at the office. It is understood that the scenario-based policy is not limited to a start time, an end time, and a location. Instead, the scenario-based policy may include any combination of permissions and/or restrictions associated with any type of scenario, including but not limited to, e.g., time, location, activity, battery power, remote device access, etc. By way of another example, a scenario-based policy may include that when the battery power is less than or equal to 20%, the OS may be configured to block a user from accessing music via client device 102. [0068] At 508, client device 102 may determine whether the scenario policy change is permitted based on existing scenario rules. For example, referring to FIG. 2A, user-permission check may include a request for a scenario policy change. When a scenario policy change is selected by a user, a scenario policy check may be performed for the new scenario policy before permission is granted. When the scenario policy change is allowed based on existing scenario rules, the operations may move to operation 510. On the other hand, the operations may move to operation 512 when a scenario policy change is not permitted. A scenario policy change may not be permitted, e.g., when a child attempts to change the scenario policy related to when a video game can be accessed.

[0069] FIG. 6 illustrates a flow chart of a fourth exemplary method 310 of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure. The operations described in FIG. 6 may include the sub- operations of method 310 in FIG. 3, according to some embodiments. Exemplary method 310 may be performed by an apparatus for wireless communication, e.g., such as client device 102, application 104, OS framework 204, package manager service 210, activity manager service 212, scenario monitor 250, 275a, and/or node 1100. Method 310 may include operations 602-612 as described below. It is to be appreciated that some of the operations may be optional, and some of the operations may be performed simultaneously, or in a different order than shown in FIG. 6.

[0070] At 602, client device 102 may initiate a component permission check. For example, referring to FIG. 2A, the component permission check may be initiated by activity manager service 212.

[0071] At 604, client device 102 may read the server requirements from package information. For example, referring to FIG. 2A, activity manager service 212 may read the package information may be read from package manager service 210.

[0072] At 606, client device 102 may determine whether the client permission information and the server requirements match. For example, referring to FIG. 2A, activity manager service 212 may access client permission information maintained in a manifest file at application client 206, as well as package information maintained by package manager service 210. When the restricted resource is remote, activity manager service 212 may access remote package information associated with the server requirements of the remote application server. Based on a comparison of the client permission information and the package information, activity manager service 212 may determine whether access to the restricted resource is possible. When the client permission information and the server requirements match, the operations may move to operation 608. Otherwise, the operations may move to operation 612.

[0073] At 608, client device 102 may perform a scenario policy check when the client permission information and server requirements match. For example, referring to FIG. 2A, when the client permission and the server requirements match, scenario monitor 250 may perform a scenario policy check. When the scenario policy check indicates that access to the restricted resource is permitted, the operations may move to operation 610. Otherwise, the operations may move to operation 612.

[0074] FIG. 7 illustrates a flow chart of a fifth exemplary method 700 of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure. Exemplary method 700 may be performed by an application server, e.g., such as client device 102, server device 120, application 104, apparatus 200, OS framework 204, application server 208, 228a, 228b, scenario monitor 250, 275a, 275b, and/or node 1100. Method 700 may include operations 702-708 as described below. It is to be appreciated that some of the operations may be optional, and some of the steps may be performed simultaneously, or in a different order than shown in FIG. 7.

[0075] At 702, application server 208 may process a request for access to a restricted resource by application client 206. At 704, application server 208 may determine whether application client 206 has permission to access the restricted resource. When permission is granted, the operations may move to operation 706. Otherwise, when permission is not granted, the operations may move to operation 708.

[0076] FIG. 8 illustrates a flow chart of a sixth exemplary method 704 of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure. The operations described in FIG. 8 may be associated with operation 704 in FIG. 7, according to some embodiments. Exemplary method 704 may be performed by an application server, e.g., such as client device 102, server device 120, application 104, apparatus 200, OS framework 204, application server 208, 228a, 228b, scenario monitor 250, 275a, 275b, and/or node 1100. It is to be appreciated that some of the operations may be optional, and some of the operations may be performed simultaneously, or in a different order than shown in FIG. 8.

[0077] Referring to FIG. 8, at 802, application server 208 may initiate an explicit permission check for an application client. At 804, application server 208 may determine whether the application client has permission to access the restricted resource. When the application client has permission, the operations may move to operation 806; otherwise, the operations may move to operation 810.

[0078] At 806, application server 208 may determine whether access is permitted based on a scenario policy check with the scenario monitor 250. For example, referring to FIG. 2A, prior to being granted access to the restricted resource, application server 208 may perform an explicit component check. The explicit component check may include a scenario policy check by scenario monitor 250. When the scenario policy permits access to the restricted resource, the operations may move to operation 808; otherwise, the operations may move to operation 810.

[0079] FIG. 9 illustrates a flow chart of a seventh exemplary method 900 of accessing a restricted resource based on a scenario policy, according to some embodiments of the present disclosure. Exemplary method 900 may be performed by a scenario monitor, e.g., such as client device 102, server device 120, application 104, apparatus 200, scenario monitor 250, 275a, 275b, and/or node 1100. It is to be appreciated that some of the operations may be optional, and some of the operations may be performed simultaneously, or in a different order than shown in FIG. 9. [0080] At 902, scenario monitor 250 may begin the scenario policy monitoring process. At 904, scenario monitor 250 may determine whether there has been a change to the scenario rules. For example, referring to FIG. 1A, the scenario rules may change based on user interaction with scenario policy change screen 108 and/or confirmation pop-up screen 110. Additionally and/or alternatively, the scenario rules maintained by scenario monitor 250 may change based on user selection of, e.g., camera scenario rules 140 in the permission list 130 of application permissions, as shown in FIG. IB. Scenario rules may apply to any type of restricted resource accessed via application 104 or client device 102, and is not limited to scenario rules associated with camera 106. When a scenario change has not occurred, the operations may move to operation 914, where the scenario monitor awaits a system event. Otherwise, when a scenario change is detected, at 906, scenario monitor 250 may determine whether there are existing scenario rules. If so, at 908, scenario monitor 250 may read the scenario rules. At 910, scenario monitor 250 may determine whether permission is still valid based on scenario change and existing scenario rules. For example, the scenario rules may dictate that the time of day a restricted resource may be accessed can be changed, but the location cannot. By way of example, if the scenario change detected at 904 includes a time of day change but not a location change, the permission may be determined as valid at 910. When valid, the operations may return to operation 906, where scenario monitor 250 performs the same loop for each scenario rule. Otherwise, if the scenario change indicates a location change, the permission may be determined to be invalid at 910. When invalid, the operations may move to 912. At 912, scenario monitor 250 may deny access to the restricted resource and/or cause a user interface to display a request for a further scenario policy change to avoid violating scenario rules.

[0081] The hardware and software data processing technology disclosed herein, such as OS environment in FIG. 1 A and methods of any of FIGs. 3-9, may be implemented by any suitable computing device such as, e.g., a personal computer (PC), a laptop computer, a digital signal processor, a tablet device, a digital camera, a merchant terminal, a vehicle, or any suitable nodes in a wireless network, just to name a few. For example, FIG. 10 illustrates a wireless network 1000, in which certain aspects of the present disclosure may be implemented, according to some embodiments of the present disclosure.

[0082] As shown in FIG. 10, wireless network 1000 may include a network of nodes, such as a user equipment (UE) 1002, an access node 1004, and a core network element 1006. User equipment 1002 may be any terminal device, such as a mobile phone, a desktop computer, a laptop computer, a tablet, a vehicle computer, a gaming console, a printer, a positioning device, a wearable electronic device, a smart sensor, or any other device capable of receiving, processing, and transmitting information, such as any member of a vehicle to everything (V2X) network, a cluster network, a smart grid node, or an Intemet-of-Things (loT) node. It is understood that user equipment 1002 is illustrated as a mobile phone simply by way of illustration and not by way of limitation.

[0083] Access node 1004 may be a device that communicates with user equipment 1002, such as a wireless access point, a base station (BS), a Node B, an enhanced Node B (eNodeB or eNB), a next-generation NodeB (gNodeB or gNB), a cluster master node, or the like. Access node 1004 may have a wired connection to user equipment 1002, a wireless connection to user equipment 1002, or any combination thereof. Access node 1004 may be connected to user equipment 1002 by multiple connections, and user equipment 1002 may be connected to other access nodes in addition to access node 1004. Access node 1004 may also be connected to other UEs. It is understood that access node 1004 is illustrated by a radio tower by way of illustration and not by way of limitation.

[0084] Core network element 1006 may serve access node 1004 and user equipment 1002 to provide core network services. Examples of core network element 1006 may include a home subscriber server (HSS), a mobility management entity (MME), a serving gateway (SGW), or a packet data network gateway (PGW). These are examples of core network elements of an evolved packet core (EPC) system, which is a core network for the Long-Term Evolution (LTE) system. Other core network elements may be used in LTE and in other communication systems. In some embodiments, core network element 1006 includes an access and mobility management function (AMF) device, a session management function (SMF) device, or a user plane function (UPF) device, of a core network for the new radio (NR) system. It is understood that core network element 1006 is shown as a set of rack-mounted servers by way of illustration and not by way of limitation. [0085] Core network element 1006 may connect with a large network, such as the Internet 1008, or another internet protocol (IP) network, to communicate packet data over any distance. In this way, data from user equipment 1002 may be communicated to other UEs connected to other access points, including, for example, a computer 1010 connected to Internet 1008, for example, using a wired connection or a wireless connection, or to a tablet 1012 wirelessly connected to Internet 1008 via a router 1014. Thus, computer 1010 and tablet 1012 provide additional examples of possible UEs, and router 1014 provides an example of another possible access node.

[0086] A generic example of a rack-mounted server is provided as an illustration of core network element 1006. However, there may be multiple elements in the core network including database servers, such as a database 1016, and security and authentication servers, such as an authentication server 1018. Database 1016 may, for example, manage data related to user subscription to network services. A home location register (HLR) is an example of a standardized database of subscriber information for a cellular network. Likewise, authentication server 1018 may handle authentication of users, sessions, and so on. In the NR system, an authentication server function (AUSF) device may be the specific entity to perform user equipment authentication. In some embodiments, a single server rack may handle multiple such functions, such that the connections between core network element 1006, authentication server 1018, and database 1016, may be local connections within a single rack.

[0087] Each element in FIG. 10 may be considered a node of wireless network 1000. More detail regarding the possible implementation of a node is provided by way of example in the description of a node 1100 in FIG. 10. Node 1100 may be configured as user equipment 1002, access node 1004, or core network element 1006 in FIG. 1. Similarly, node 1100 may also be configured as computer 1010, router 1014, tablet 1012, database 1016, or authentication server 1018 in FIG. 10. As shown in FIG. 11, node 1100 may include a processor 1102, a memory 1104, and a transceiver 1106. These components are shown as connected to one another by a bus, but other connection types are also permitted. When node 1100 is user equipment 1002, additional components may also be included, such as a user interface (UI), sensors, and the like. Similarly, node 1100 may be implemented as a blade in a server system when node 1100 is configured as core network element 1006. Other implementations are also possible.

[0088] Transceiver 1106 may include any suitable device for sending and/or receiving data. Node 1100 may include one or more transceivers, although only one transceiver 1106 is shown for simplicity of illustration. An antenna 1108 is shown as a possible communication mechanism for node 1100. Multiple antennas and/or arrays of antennas may be utilized for receiving multiple spatially multiplex data streams. Additionally, examples of node 1100 may communicate using wired techniques rather than (or in addition to) wireless techniques. For example, access node 1004 may communicate wirelessly to user equipment 1002 and may communicate by a wired connection (for example, by optical or coaxial cable) to core network element 1006. Other communication hardware, such as a network interface card (NIC), may be included as well.

[0089] As shown in FIG. 11, node 1100 may include processor 1102. Although only one processor is shown, it is understood that multiple processors can be included. Processor 1102 may include microprocessors, microcontroller units (MCUs), digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described throughout the present disclosure. Processor 1102 may be a hardware device having one or more processing cores. Processor 1102 may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Software can include computer instructions written in an interpreted language, a compiled language, or machine code. Other techniques for instructing hardware are also permitted under the broad category of software. [0090] As shown in FIG. 10, node 1100 may also include memory 1104. Although only one memory is shown, it is understood that multiple memories can be included. Memory 1104 can broadly include both memory and storage. For example, memory 1104 may include random-access memory (RAM), read-only memory (ROM), static RAM (SRAM), dynamic RAM (DRAM), ferroelectric RAM (FRAM), electrically erasable programmable ROM (EEPROM), compact disc read- only memory (CD-ROM) or other optical disk storage, hard disk drive (HDD), such as magnetic disk storage or other magnetic storage devices, Flash drive, solid-state drive (SSD), or any other medium that can be used to carry or store desired program code in the form of instructions that can be accessed and executed by processor 1102. Broadly, memory 1104 may be embodied by any computer-readable medium, such as a non-transitory computer-readable medium.

[0091] Processor 1102, memory 1104, and transceiver 1106 may be implemented in various forms in node 1100 for performing wireless communication functions. In some embodiments, processor 1102, memory 1104, and transceiver 1106 of node 1100 are implemented (e.g., integrated) on one or more system-on-chips (SoCs). In one example, processor 1102 and memory 1104 may be integrated on an application processor (AP) SoC (sometimes known as a “host,” referred to herein as a “host chip”) that handles application processing in an operating system (OS) environment, including generating raw data to be transmitted. In another example, processor 1102 and memory 1104 may be integrated on a baseband processor (BP) SoC (sometimes known as a “modem,” referred to herein as a “baseband chip”) that converts the raw data, e.g., from the host chip, to signals that can be used to modulate the carrier frequency for transmission, and vice versa, which can run a real-time operating system (RTOS). In still another example, processor 1102 and transceiver 1106 (and memory 1104 in some cases) may be integrated on a radio frequency (RF) SoC (sometimes known as a “transceiver,” referred to herein as an “RF chip”) that transmits and receives RF signals with antenna 1108. It is understood that in some examples, some or all of the host chip, baseband chip, and RF chip may be integrated as a single SoC. In particular, processor 1102 may be included in client device 102 and/or server device 120 as described above to perform the exemplary distributed permissions mechanism.

[0092] In various aspects of the present disclosure, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or encoded as instructions or code on a non-transitory computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computing device, such as node 1100 in FIG. 10. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, HDD, such as magnetic disk storage or other magnetic storage devices, Flash drive, SSD, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a processing system, such as a mobile device or a computer. Disk and disc, as used herein, includes CD, laser disc, optical disc, digital video disc (DVD), and floppy disk where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. [0093] According to one aspect of the present disclosure, a client device is provided. The client device may include a scenario monitor. The scenario monitor may be configured to maintain a scenario policy associated with access to a restricted resource. The client device may also include an application client. The application client may be configured to receive a request for access to the restricted resource. The application client may be configured to perform a self-permission check associated with the request. In response to the self-permission check indicating that access to the restricted resource is permitted, the scenario monitor may be further configured to perform a first scenario policy check associated with the request based on the scenario policy. The client device may further include an activity manager service. The activity manager service may be configured to, in response to the first scenario policy check indicating that access to the restricted resource is permitted, perform a component permission check associated with the restricted resource.

[0094] In some embodiments, in response to the component permission check indicating that access to the restricted resource is permitted, the application client may be further configured to attempt to access the restricted resource via an application server.

[0095] In some embodiments, in response to the self-permission check indicating that access to the restricted resource is not permitted, the application client may be further configured to cause a user interface to display a scenario policy change request for access to the restricted resource.

[0096] In some embodiments, the application client may be further configured to receive, by an interaction with the user interface, information associated with the scenario policy change request.

[0097] In some embodiments, the activity manager service may be configured to perform the component permission check associated with the restricted resource by reading package information from a PMS. In some embodiments, the package information may be associated with an application server. In some embodiments, the activity manager service may be configured to perform the component permission check associated with the restricted resource by comparing the package information associated with the application server and a client permission associated with the application client. In some embodiments, the application server may be associated with the client device or a server device.

[0098] In some embodiments, in response to the package information and the client permission meeting a permission criterion, the scenario monitor may be further configured to perform a second scenario policy check associated with the request. In some embodiments, in response to the second scenario policy check indicating that access to the restricted resource is permitted, the application client may be further configured to attempt to access the restricted resource via the application server.

[0099] In some embodiments, in response to the attempt by the application client to access the restricted resource, the application server may be configured to perform a client permission check associated with the application client.

[0100] In some embodiments, in response to the client permission check indicating access to the restricted resource is permitted, the scenario monitor may be further configured to perform a third scenario policy check.

[0101] In some embodiments, in response to the third scenario policy check indicating that access to the restricted resource is permitted, the application server may be configured to enable access to the restricted resource by the application client.

[0102] In some embodiments, the scenario policy may be associated with one or more of time of day, location, activity, or battery power.

[0103] According to another aspect of the present disclosure, a terminal device is provided.

The terminal device may include a scenario monitor. The scenario monitor may be configured to maintain a scenario policy associated with access to a restricted resource via an application. The terminal device may include an application server. In response to an attempt by an application client to access the restricted resource, the application server may be configured to perform an explicit permission check associated with the application client. In response to the client permission check indicating access to the restricted resource is permitted, the scenario monitor may be further configured to perform a third scenario policy check.

[0104] In some embodiments, in response to the third scenario policy check indicating that access to the restricted resource is permitted, the application server may be configured to enable access to the restricted resource by the application client.

[0105] According to yet another aspect of the present disclosure, an OS framework of a terminal device is provided. The OS framework may include a scenario monitor. The scenario monitor may be configured to maintain a scenario policy associated with access to a restricted resource via an application. The scenario monitor may be configured to maintain at least one scenario rule associated with the scenario policy. In response to a scenario policy change, the scenario monitor may be configured to read the at least one scenario rule. In response to the scenario policy change violating the at least one scenario rule, the scenario monitor may disable access to the restricted resource.

[0106] According to still another aspect of the disclosure, a method of a client device is provided. The method may include maintaining, by a scenario monitor, a scenario policy associated with access to a restricted resource via an application. The method may include receiving, by an application client, a request for access to the restricted resource. The method may include performing, by the application client, a self-permission check associated with the request. In response to the self-permission check indicating that access to the restricted resource is permitted, the method may further include performing, by the scenario monitor, a first scenario policy check associated with the request based on the scenario policy. In response to the first scenario policy check indicating that access to the restricted resource is permitted, the method may further include performing, by an activity manager service, a component permission check associated with the restricted resource.

[0107] In some embodiments, in response to the component permission check indicating that access to the restricted resource is permitted, the method may further include attempting, by the application client, to access the restricted resource via an application server.

[0108] In some embodiments, in response to the self-permission check indicating that access to the restricted resource is not granted, the method may further include causing, by the application client, a user interface to display a scenario policy change request for access to the restricted resource.

[0109] In some embodiments, the method may include receiving, by the application client, information associated with the scenario policy change request by an interaction with the user interface.

[0110] In some embodiments, performing the component permission check associated with the restricted resource may include reading, by the activity manager service, package information from a PMS. In some embodiments, package information may be associated with an application server. In some embodiments, performing the component permission check associated with the restricted resource may include comparing, by the activity manager service, the package information associated with the application server and a client permission associated with the application client. In some embodiments, the application server may be associated with the client device or a server device.

[OHl] In some embodiments, in response to the package information and the client permission meeting a permission criterion, the method may further include performing, by the scenario monitor, a second scenario policy check associated with the request. In some embodiments, in response to the second scenario policy check indicating that access to the restricted resource is permitted, the method may further include attempting, by the application client, to access the restricted resource via the application server.

[0112] In some embodiments, in response to the attempt by the application client to access the restricted resource, the method may further include performing, by the application server a client permission check associated with the application client.

[0113] In some embodiments, in response to the client permission check indicating access to the restricted resource is permitted, the method may further include performing, by the scenario monitor, a third scenario policy check.

[0114] In some embodiments, in response to the third scenario policy check indicating that access to the restricted resource is permitted, the method may further include enabling, by the application server, access to the restricted resource by the application client.

[0115] In some embodiments, the scenario policy may be associated with one or more of time of day, location, activity, or battery power.

[0116] According to still a further aspect of the disclosure, a method of a server device is provided. The method may include maintaining, by a scenario monitor, a scenario policy associated with access to a restricted resource via an application. In response to an attempt by an application client to access the restricted resource, the method may further include performing, by an application server, a client permission check associated with the application client. In response to the client permission check indicating access to the restricted resource is permitted, the method may further include performing, by the scenario monitor, a third scenario policy check.

[0117] In some embodiments, in response to the third scenario policy check indicating that access to the restricted resource is permitted, the method may further include enabling, by the application server, access to the restricted resource by the application client.

[0118] According to still another aspect of the disclosure, a method of a scenario monitor is provided. The method may include maintaining a scenario policy associated with access to a restricted resource via an application. The method may include maintaining at least one scenario rule associated with the scenario policy. In response to a scenario policy change, the method may include reading the at least one scenario rule. In response to the scenario policy change violating the at least one scenario rule, the method may include disabling access to the restricted resource. [0119] The foregoing description of the specific embodiments will so reveal the general nature of the present disclosure that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present disclosure. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

[0120] Embodiments of the present disclosure have been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.

[0121] The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present disclosure as contemplated by the inventor(s), and thus, are not intended to limit the present disclosure and the appended claims in any way.

[0122] Various functional blocks, modules, and operations are disclosed above. The particular arrangements provided are illustrative and without limitation. Accordingly, the functional blocks, modules, and operations may be re-ordered or combined in different ways than in the examples provided above. Likewise, certain embodiments include only a subset of the functional blocks, modules, and operations, and any such subset is permitted.

[0123] The breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.