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 of a distributed OS environment is provided. The client device may include an application client configured to, in response to a self-permission check indicating that access to a remote application service via an application server at a server device of the distributed OS environment is not granted, request permission to access the remote application service via the application server at the server device. The client device may include an OS framework configured to, in response to the self-permission check indicating that access to the remote application service via the application server at the server device is granted, perform a component permission check associated with the server device. The application client and the application server may be associated with an application.

[0004] According to another aspect of the present disclosure, a server device of a distributed OS environment is provided. The server device may include a first service agent. The first service agent may be configured to establish a communication channel with a second service agent of a client device. The first service agent may be configured to perform a self-permission check associated with the client device and access to an application service via an application server of the server device. The first service agent may be configured to return information associated with the self-permission check to the client device. In response to the self-permission check not granting access to the application service via the server device, the first service agent may be further configured to receive a request for access to the application service via the application server by the client device. In response to the self-permission check not granting access to the application service via the server device, the first service agent may be further configured to cause a user interface of the server device to display the request for access to the application service via the application server by the client device. In response to the self-permission check not granting access to the application service via the server device, the first service agent may be further configured to receive a response to the request via an interaction with the user interface. In response to the self-permission check not granting access to the application service via the server device, the first service agent may be further configured to return the response to the request to the client device via the communication channel.

[0005] According to still another aspect of the present disclosure, a server device of a distributed OS environment is also provided. The server device may include a first service agent. The first service agent may be configured to receive a request for a client device to access an application service via an application server of the server device. The first service agent may be configured to perform a client permission check for the client device. In response to the client permission check indicating that permission information associated with the client device is not maintained by the first service agent, the first service agent may be further configured to establish a communication channel with a second service agent of the client device. In response to the client permission check indicating that permission information associated with the client device is not maintained by the first service agent, the first service agent is further configured to request the permission information from the second service agent of the client device. In response to the client permission check indicating that permission information associated with the client device is not maintained by the first service agent, the first service agent is further configured to receive the permission information from the second service agent of the client device.

[0006] According to yet another aspect of the present disclosure, a method of wireless communication of a client device is provided. The method may include in response to a selfpermission check indicating that access to a remote application service via an application server at a server device is not granted, requesting, by an application client, permission to access the remote application service via the application server at the server device. The method may include in response to the self-permission check indicating that access to the remote application service via the application server at the server device is granted, performing, by an OS framework, a component permission check associated with the application server at the server device. The application client and the application server may be associated with an application. The client device and the server device may be associated with a distributed OS environment. [0007] According to yet another aspect of the present disclosure, a method of wireless communication of a server device is provided. The method may include establishing, by a first service agent, a communication channel with a second service agent of a client device. The method may include performing, by the first service agent, a self-permission check associated with the client device and access to an application service via an application server of the server device. The method may include returning, by the first service agent, information associated with the selfpermission check to the client device. In response to the self-permission check not granting access to the application service via the server device, the method may further include receiving, by the first service agent, a request for access to the application service via the application server by the client device. In response to the self-permission check not granting access to the application service via the server device, the method may further include causing, by the first service agent, a user interface of the server device to display the request for access to the application service via the application server by the client device. In response to the self-permission check not granting access to the application service via the server device, the method may further include receiving, by the first service agent, a response to the request via an interaction with the user interface. In response to the self-permission check not granting access to the application service via the server device, the method may further include returning, by the first service agent, the response to the request to the client device via the communication channel.

[0008] According to still a further aspect of the present disclosure, a method of wireless communication of a server device is also provided. The method may include receiving, by a first service agent, a request for a client device to access an application service via an application server of the server device. The method may include performing, by the first service agent, a client permission check for the client device. In response to the client permission check indicating that permission information associated with the client device is not maintained by the first service agent, the method may further include establishing, by the first service agent, a communication channel with a second service agent of the client device. In response to the client permission check indicating that permission information associated with the client device is not maintained by the first service agent, the method may further include requesting, by the first service agent, the permission information from the second service agent of the client device. In response to the client permission check indicating that permission information associated with the client device is not maintained by the first service agent, the method may further include receiving, by the first service agent, the permission information from the second service agent of the client device. In response to the permission information indicating that the client device has permission to access the application service via the application server of the server device, the method may further include enabling, by the first service agent, the request for the client device to access the application service via the application server to be processed.

[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] FIGs. 1A and IB illustrate an exemplary distributed OS environment, according to some embodiments of the present disclosure.

[0012] FIG. 1C illustrates a user interface of a server device of the exemplary distributed OS environment of FIGs. 1A and IB, 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 a client device and a server device of the exemplary distributed OS environment of FIGs. 1A and IB, according to some embodiments of the present disclosure.

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

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

[0017] FIG. 5 illustrates a flow chart of a third exemplary method of wireless communication in a distributed OS environment, 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 wireless communication in a distributed OS environment, according to some embodiments of the present disclosure.

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

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

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

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

DETAILED DESCRIPTION

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] OS settings enable a user to set permissions for various applications. These permissions support user privacy by protecting access to various application services (also referred to as “restricted resources”). These application services 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 remote access to application services with similar protections.

[0031] Thus, there exists an unmet need for a permission mechanism that enables and protects remote access to an application service.

[0032] To overcome these and other challenges, the present disclosure provides a distributed permission mechanism that works across devices, which enables an application on a first device (also referred to herein as a “client device”) to obtain permission to access a remote application service at a second device (also referred to herein as a “server device”). In other words, the distributed permission mechanism enables users within a distributed OS environment to set permissions such that remote access to an application service can be achieved as specified by the device’s user. There may be many scenarios in which the present distributed permission mechanism may be beneficial.

[0033] By way of one example, assume Henry, Charlie, and Jill are playing a board game in Henry’s apartment. Charlie decides to take a picture of the group and upload it to a social media application, such as Facebook. In this scenario, Henry has a smart TV that includes the social media application downloaded thereon. Moreover, the TV is also enabled with a camera and may be situated such that it can easily capture a nice picture of the three friends enjoying game night. Thus, when Charlie accesses the social media application on his cell phone and interacts with the camera icon, a list of available remote devices associated with the application and the application service may be displayed. In this example, Charlie selects Henry’s TV since it can best capture the fun scene. Based on Henry’s remote permissions settings, Charlie is granted access to the camera on Henry’s TV. Thus, when Charlie presses the camera icon in the social media application, the TV takes the picture, which is captured on his phone and is uploaded to Charlie’s social media account. Additional details of the present distributed permission mechanism are provided below in connection with FIGs. 1-11.

[0034] FIGs. 1A and IB illustrate an exemplary distributed OS environment 100, in which the exemplary distributed permission mechanism may be implemented, according to some embodiments of the present disclosure. FIG. 1C illustrates an exemplary user interface 101 that may enable users to grant permission for remote access to application services on his or her device, according to some embodiments of the present disclosure. FIGs. 1A-1C will be described together. [0035] As shown in FIGs. 1A and IB, distributed OS environment 100 may include a plurality of devices, such as client device 102 and server device 120. Client device 102 and server device 120 may operate using the same or different OS. Client device 102 and server device 120 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 and server device 120 are both illustrated as a mobile phone simply by way of illustration and not by way of limitation. It is also understood that while only two devices are shown for simplicity, there may be more devices within distributed OS environment 100.

[0036] Referring to FIG. 1A, client device 102 displays the user interface of an application 104, e.g., Facebook Messenger. Application 104 may display icons related to various application services, such as access to a camera 106, photos, a microphone, etc. In the present example, the user selects camera 106. The user of client device 102 has set the application permissions such that camera 106 may be accessed via application 104, and, consequently, a list 108 of camera devices may be displayed for selection. More specifically, list 108 includes various devices through which a camera may be accessed. As shown in FIG. 1A, list 108 may include the client device 102, as well as a list of remote camera devices. Depending on whether the user selects the local camera or a remote camera, the user interface of application 104 may display different screens, as depicted in FIGs. 1A and IB.

[0037] Referring to FIG. 1A, when the client device 102 (local camera) is selected from list 108, the user interface of application 104 may display an activation screen 110. Activation screen 110 may be displayed when access to application services via application 104 has not already been enabled by the user. Moreover, activation screen 110 may enable the user to permit access to various local application services via application 104. When access is already enabled, the operation may move directly to FIG. IB without displaying activation screen 110. In either case, once access to application services is enabled, a permission request screen 114 may be displayed which enables the user to access camera 106 via application 104. However, depending on the user permission settings, permission request screen 114 may not be displayed. For example, permission request screen 114 may not be displayed when the user has selected “always allow” in the application settings for access to camera 106 via application 104.

[0038] On the other hand, when the user selects a remote device from list 108 (as shown in FIG. 1 A), the user interface of application 104 may display pop-up screen 112 while permission is being requested. Referring to FIG. IB, in response to the request, server device 120 may display a pop-up screen 116, which asks the user of server device 120 whether camera access to the user of client device 102 should be granted. Thus, FIGs. 1A and IB depict one example of what may be displayed to users during the implementation of the distributed permission mechanism.

[0039] Referring to FIG. 1C, a user interface 101 of application settings (e.g., application permissions) of server device 120 is shown. In this example, the user of server device 120 allows the user of client device 102 access to the camera via application 104. The user of server device 120 has also selected that server device 120 ask each time client device 102 requests remote access to the camera. Thus, each time client device 102 requests remote access to the camera, server device 120 may display pop-up screen 116 shown in FIG. IB. Additional details of the distributed permission mechanism implemented by each of client device 102 and server device 120 are provided below in connection with FIGs. 2A-8.

[0040] FIG. 2A illustrates a block diagram of an apparatus 200 including application 104 and an OS framework 204, according to some embodiments of the present disclosure. Apparatus 200 may include, e.g., client device 102 and/or server device 120.

[0041] Referring to FIG. 2A, application 104 may include an application client 206, application server 208, and application settings 214. Application client 206 and application server 208 may be associated with the same application, such as application 104 in FIGs. 1A and IB. OS framework 204 may include a package service manager 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 remote access to an application service.

[0042] Referring to application 104, application server 208 may act as a gate-keeper through which access to an application service may be obtained, either locally or remotely, by an application client. Application client 206 may access local application services via application server 208. On the other hand, when acting as server device 120, application server 208 may be used to enable remote access to application services via an application client located at client device 102. To gain access to either a local or remote application service, and when configured as client device 102, application client 206 may perform a self-permission check; and, in some instances, request permission for access to a remote application service. When configured as server device 120, application server 208 may perform an explicit permission check prior to permitting remote access to an application service.

[0043] In some embodiments (e.g., in response to apparatus 200 receiving a user request for remote access to an application service at a remote device), application client 206 may perform the self-permission check by communicating with the remote device (not shown in FIG. 2A). The self-permission check may include, e.g., communicating with a remote service agent (see FIG. 2B) of the remote device. The client permission information at the remote service agent may indicate whether the user of apparatus 200 has been granted permission to access application services at the remote device. Additional details of the self-permission check for remote access are described below in connection with FIGs. 3 and 4.

[0044] When the self-permission check indicates that remote access to the application service has not been permitted, application client 206 may be configured to request user-permission for access to the remote application service. Additional details of the user-permission request are described below in connection with FIGs. 3 and 5.

[0045] While the self-permission check and/or the user-permission request is/are processing, application client 206 may cause the user interface to display pop-up screen 112 while client device 102 waits for a response from server device 120, as shown in FIG. 1A.

[0046] Referring to OS framework 204, activity manager service 212 may be configured to perform a component permission check (e.g., application service permission check) based on information maintained by package manager service 210 when either the self-permission check or the permission request indicates that the user of apparatus 200 is permitted remote access to the application service. Prior to attempting to access the remote application service, 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 remote package information associated with the remote server’s permission requirements from package manager service 210. Then, based on a comparison of the client permission information and the remote package information, activity service manager 212 may determine whether access to the remote application service is possible.

[0047] For example, client permission information and distributed permission 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. Remote package information (also referred to as “distributed permission information) may include, e.g., remote name, remote label, remote description, remote protection level, etc. When application client 206 wants access to the application service in server device 120, application client 206 may declare user-permission in a manifest file of application client 206 as follows:

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

[0048] When apparatus 200 is a server device 120, application 104 may declare the distributed permission inside the manifest file of application server 208. For example, when the component includes an activity, such as taking a picture, the distributed permission may be declared as follows:

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

</activity>.

[0049] If application client 206 declares a local permission that includes the same permission name (e.g., com.mycompany.permission.Example) as that declared in the manifest file of the remote application server, application client 206 may activate the remote application service “com.example.project.ExampleActivity” via the remote application server. Additional details of the OS framework permission check are described below in connection with FIGs. 3 and 6. Then, prior to being granted access to the application service, the remote application server may perform an explicit component check, as described below in connection with FIGs. 7 and 8.

[0050] 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.

[0051] FIG. 2B illustrates a block diagram 201 of client device 102 and server device 120 of the exemplary distributed OS environment 100 of FIGs. 1A and IB, 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, and service agent 236a. Each of set of application clients 226a, set of application servers 228a, package manager service 230a, activity manager service 232a, and application settings 234a may be configured to perform corresponding operations described above in connection with FIG. 2A. 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, and service agent 236b. Each of set of application clients 226b, set of application servers 228b, package manager service 230b, activity manager service 232b, and application settings 234b 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 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.

[0052] FIG. 3 illustrates a flow chart of a first exemplary method 300 of wireless communication in a distributed OS environment, according to some embodiments of the present disclosure. Exemplary method 300 may be performed by an apparatus for wireless communication, e.g., such as client device 102, server device 120, application 104, OS framework 204, application client 206, application server 208, package manager service 210, activity manager service 212, service agent 220, service agent 236a, service agent 236b, and/or node 1000. Method 300 may include steps 302-314 as described below. It is to be appreciated that some of the steps may be optional, and some of the steps may be performed simultaneously, or in a different order than shown in FIG. 3.

[0053] Referring to FIG. 3, at 302, the apparatus may initiate access to an application service. For example, referring to FIG. 1A, application 104 may display icons related to various application services, such as access to a camera 106, photos, a microphone, etc., within a user interface. In the present example, camera 106 is selected. Because the user of client device 102 has set the application permissions such that camera 106 may be accessed via application 104, a list 108 of camera devices may be displayed. List 108 includes various devices through which a camera may be accessed through application 104. As shown in FIG. 1A, the list may include the local camera of client device 102, as well as a list of remote camera devices. Depending on whether the user selects the local camera or a remote camera, the user interface of application 104 may display different screens while the OS implements the distributed permission mechanism, as depicted in FIGs. 1A and IB.

[0054] At 304, the apparatus may perform a self-permission check to determine whether access is granted for a remote application service at a server device. For example, referring to FIG. 2A, when apparatus 200 is configured as client device 102 and the requested application service is remote, application client 206 may be configured to perform the self-permission check by communicating with a remote service agent (not shown in FIG. 2A). The self-permission check may be indicate whether access to the application service via the application is permitted at the remote device. When the self-permission check returns “no permission,” the operations may move to 306. Otherwise, when the self-permission check (at 304) returns a “permission,” the operations may move to 308. An example of a client device user being granted permission to access an application service at a server device is shown in FIG. 1C. Additional details of the self-permission check are described below in connection with FIG. 4.

[0055] At 306, the apparatus may request user-permission to access the application service at the server device in response to the self-permission check indicating that access to the application service is not permitted. For example, referring to FIG. 2A, when the self-permission check with the remote application server indicates that remote access to the application service via the application server is not permitted, application client 206 may be configured to request userpermission to access the remote application service. Additional details of the request for userpermission are provided below in connection with FIG. 5.

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

[0057] At 310, the apparatus may perform an OS framework permission check. For example, referring to FIG. 2A, apparatus 200 may include an OS framework 204 that includes a package manager service 210 and an activity manager service 212. Package manager service 210 may maintain remote package information associated with user settings of server device 120, and application client 206 may maintain client permission information in a manifest file. More specifically, client permission information may include, e.g., local name, local label, local description, local protection level, etc. Distributed permission information may include, e.g., remote name, remote label, remote description, remote protection level, etc. Client permission information and distributed permission information (remote package information) may be used by application client 206 to gain access to and activate the remote application service. When the OS framework permission check is unsuccessful, the operations may move to 314. Otherwise, when the OS framework permission check is successful, the operations may move to 312. Additional details of the OS framework permission check are provided below in connection with FIG. 6.

[0058] At 312, the apparatus may access the remote application service. For example, referring to FIG. 2A, if application client 206 declares a local permission that includes the same permission name (e.g., com.mycompany.permission.Example), the application client 206 may activate the remote application service “com.example.project.ExampleActivity” via the remote application server.

[0059] FIG. 4 illustrates a flow chart of a second exemplary method 304 of wireless communication in a distributed OS environment, according to some embodiments of the present disclosure. The operations described in FIG. 4 may include the sub-steps of method304 in FIG. 3, according to some embodiments. Exemplary method 304 may be performed by two apparatuses for wireless communication, e.g., such as client device 102, server device 120, application 104, OS framework 204, application client 206, application server 208, package manager service 210, activity manager service 212, service agent 220, service agent 236a, service agent 236b, and/or node 1000. Method 304 may include steps 402-422 as described below. Operations 402, 404, 406, 416, 418, 420, and 422 may be implemented by client device 102, while operations 408, 410, 412, and 414 may be implemented by server device 120. 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.

[0060] Referring to FIG. 4, at 402, client device 102 may initiate the self-permission check. [0061] At 404, client device 102 may determine whether the requested application service is local or remote. For example, referring to FIG. 1 A, because the user of client device 102 has set the application permissions such that camera 106 may be accessed via application 104, a list 108 of camera devices may be displayed. List 108 includes various devices through which a camera may be accessed through application 104. As shown in FIG. 1A, the list may include the local camera of client device 102, as well as a list of remote camera devices. Depending on whether the user selects the local camera or a remote camera, the user interface of application 104 may display different screens while the OS implements the distributed permission mechanism, as depicted in FIGs. 1A and IB. When the application service is local, the operations may move to 418. Otherwise, when the application service is remote, the operations may move to 406.

[0062] At 406, client device 102 may launch the service agent of server device 120. For example, referring to FIG. 2B, service agent 236a of client device 102 may activate service agent 236b of server device 120 when a user requests access to a remote application service at server device 120.

[0063] At 408, server device 120 may start the service agent. For example, referring to FIG. 2B, service agent 236b may be activated based on signaling from service agent 236a. Once activated, service agent 236a and service agent 236b may establish a communication channel through which client device 102 and server device 120 communicate.

[0064] At 410, server device 120 may determine whether access to the application service is permitted by the user. For example, referring to FIG. 2B, service agent 236b may be configured to perform a self-permission check. Service agent 236b may determine whether the user of server device 120 has enabled access to, e.g., camera 106 based on information maintained by application settings 214 or client permission information maintained by a manifest file of application client 226b. When access is not permitted, service agent 236b may return an indication that access is not permitted at operation 412. Otherwise, when access to the application service is permitted via application 104, service agent 236b may indicate access is permitted at operation 414.

[0065] At 416, client device 102 may wait for the result of the self-permission check by server device 120.

[0066] At 418, client device 102 may determine whether access to the application service (via the application) is permitted by server device 120. When access is permitted, the operation may move to 420; and when access is not permitted, the operations may move to 422.

[0067] FIG. 5 illustrates a flow chart of a third exemplary method 306 of wireless communication in a distributed OS environment, according to some embodiments of the present disclosure. The operations described in FIG. 5 may include the sub-steps of method 306 in FIG. 3, according to some embodiments. Exemplary method 500 may be performed by two apparatuses for wireless communication, e.g., such as client device 102, server device 120, application 104, OS framework 204, application client 206, application server 208, package manager service 210, activity manager service 212, service agent 220, service agent 236a, service agent 236b, and/or node 1000. Method 306 may include operations 502-528 as described below. Operations 502, 504, 506, 508, 518, 520, 522, 524, 526, and 528 may be implemented by client device 102, while operations 510, 512, 514, and 516 may be implemented by server device 120. 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.

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

[0069] At 504, client device 102 may display an application service provider list. For example, referring to FIG. 1A, application 104 may display icons related to various application services, such as access to a camera 106, photos, a microphone, etc. In the present example, camera 106 is selected. Because the user of client device 102 has set the application permissions such that camera 106 may be accessed via application 104, a list 108 of camera devices may be displayed. List 108 includes various devices through which a camera may be accessed through application 104. As shown in FIG. 1A, the list may include the local camera of client device 102, as well as a list of remote camera devices. Depending on whether the user selects the local camera or a remote camera, the user interface of application 104 may display different screens while the OS implements the distributed permission mechanism, as depicted in FIGs. 1A and IB.

[0070] At 506, client device 102 may determine whether the user selection from the list indicates local access to the application service or remote access. When local access is selected, the operations may move to operation 522. On the other hand, when remote access is selected, the operations may move to 508.

[0071] At 508, client device 102 may launch the service agent at server device 120. For example, referring to FIG. 2B, service agent 236a of client device 102 may activate service agent 236b of server device 120 when a user requests access to a remote application service at server device 120.

[0072] At 510, server device 120 may start the service agent. For example, referring to FIG. 2B, service agent 236b may be activated based on signaling from service agent 236a. Once activated, service agent 236a and service agent 236b may establish a communication channel through which client device 102 and server device 120 communicate.

[0073] At 512, server device 120 may display a user interface to enable the user to grant or deny access to the remote application service. For example, referring to FIG. IB, in response to the request, server device 120 may display a pop-up screen 116 via the user interface of application 104, which enables the user of server device 120 to grant or deny camera access to the user of client device 102.

[0074] At 514, server device 120 may receive the user’s decision based on an interaction with the user interface. The user’s decision may be returned at 516, which may be received by client device 102 at 518.

[0075] At 520, client device 102 may determine whether access to the remote application service is granted. When permission is not granted, the operations may move to 528. Otherwise, when it is determined (at 520) that access is granted, the operations may move to 526.

[0076] However, when the permission request is for a local application service, at 522, client device 102 may display a request for local access to an application service. For example, referring to FIGs. 1A and IB, when the user selects the local camera from list 108, the user interface of application 104 may display an activation screen 110 when access to application services via application 104 is not already enabled. Activation screen 110 may enable the user to turn on access to various application services via application 104. When access is already enabled, the operation may move directly to FIG. IB without displaying activation screen 110. In either case, once access to application services is enabled, a permission request screen 114 may be displayed, which enables the user to access camera 106 via application 104. However, depending on the user permission settings, permission request screen 114 may not be displayed, e.g., when the user has enabled access to camera 106 via application 104 without asking for permission.

[0077] When local access is granted, as determined at 524, the operations may move to 526. Otherwise, the operations move to 528.

[0078] FIG. 6 illustrates a flow chart of a third exemplary method 310 of wireless communication in a distributed OS environment, according to some embodiments of the present disclosure. The operations described in FIG. 6 may include the sub-steps 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, application client 206, application server 208, package manager service 210, activity manager service 212, service agent 236a, and/or node 1000. Method 600 may include steps 602-614 as described below. It is to be appreciated that some of the steps may be optional, and some of the steps may be performed simultaneously, or in a different order than shown in FIG. 6.

[0079] 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.

[0080] At 604, client device 102 may determine whether the application service is local or remote. When remote, the operations may move to 606. Otherwise, when local, the operations may move to 608.

[0081] At 606, client device 102 may read the remote package information associated with server device 120. For example, referring to FIG. 2A, the remote package information may be read from package manager service 210.

[0082] At 610, client device 102 may determine whether the remote package information associated with server device 120 and the client permission information associated with client device 102 match. For example, referring to FIG. 2A, activity manager service 212 may perform a component permission check by comparing the client permission information and the remote package information. Here, the component being checked is the application service, such as camera 106. When application client 206 wants to access the application service in server device 120, application client 206 may declare user-permission (client permission information) in a manifest file of application client 206 as follows: <uses-permission android:name="com.mycompany.permission.Example"/>. At server device 120, to protect the application service at application server 208, application 104 may declare the distributed permission inside the manifest file of application server 208 that is maintained at client device 120 as, e.g., “remote package information.” If application client 206 declares a local permission that includes the same permission name (e.g., com.mycompany.permission.Example), the application client 206 may activate the remote application service “com.example.project.ExampleActivity” via the remote application server. This is because the permission declared in manifest file of application client 206 is the same as the permission declared in the manifest file of the remote application server.

[0083] At 612, client device 102 may return a success when a match is determined at 610 and access the remote application service. Otherwise, at 614, client device 102 may return a failure when a match is not determined at 610 and access to the remote device is denied.

[0084] FIG. 7 illustrates a flow chart of a fifth exemplary method 700 of wireless communication in a distributed OS environment, according to some embodiments of the present disclosure. Exemplary method 700 may be performed by an apparatus for wireless communication, e.g., such as server device 120, application 104, OS framework 204, application client 226b, application server 228b, package manager service 230b, activity manager service 232b, service agent 236b, and/or node 1000. Method 700 may include steps 702-708 as described below. It is to be appreciated that some of the steps may be optional, and some of the steps may be performed simultaneously, or in a different order than shown in FIG. 7.

[0085] At 702, server device 120 may process a request for access to a remote application service by client device 102. At 704, server device 120 may determine whether client device 120 has permission to access remote application service. When permission is granted, the operations may move to 706. Otherwise, when permission is not granted, the operations may move to 708.

[0086] FIG. 8 illustrates a flow chart of a sixth exemplary method 800 of wireless communication in a distributed OS environment, according to some embodiments of the present disclosure. The operations described in FIG. 8 may be associated with step 704 in FIG. 7, according to some embodiments. Exemplary method 800 may be performed by two apparatuses for wireless communication, e.g., such as client device 102, server device 120, application 104, OS framework 204, application client 206, application server 208, package manager service 210, activity manager service 212, service agent 220, service agent 236a, service agent 236b, and/or node 1000. Method 800 may include steps 802-808, 818, 820, 822, 824, and 826, as described below. Steps 802-808, 818, 820, 822, 824, and 826 may be implemented by server device 120, while steps 810, 812, 814, and 816 maybe implemented by client device 102. It is to be appreciated that some of the steps may be optional, and some of the steps may be performed simultaneously, or in a different order than shown in FIG. 8.

[0087] Referring to FIG. 8, at 802, server device 120 may initiate a permission check for an application client. At 804, server device 120 may determine whether the application client is local or remote. When the application client is remote, at 806, server device 120 may determine whether its service agent has permission information associated with the remote application client. When no, at 808, server device 120 may launch the service agent at client device 102. When yes, at 820, server device 120 obtains permission information from its service agent, and then determines (at 822) whether client device 102 has permission.

[0088] At 810, client device 102 may activate its service agent. Then, at 812, client device 102 may determine whether its service agent has permission information associated with its application client and the application server of server device 120. When it does, at 814, it returns a successful indication to server device 120. Otherwise, when it does not, at 816, it returns a failure indication to server device 120. Meanwhile, at 818, server device 120 waits for the response from client device 102. At 822, server device 120 may determine whether the application client of client device 102 has permission to access the remote service. When yes, at 824, a success may be returned. Otherwise, when no, at 826, a failure is returned.

[0089] The hardware and software data processing technology disclosed herein, such as distributed OS environment in FIG. 1 and methods of any of FIGs. 3-8, 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. 9 illustrates a wireless network 900, in which certain aspects of the present disclosure may be implemented, according to some embodiments of the present disclosure.

[0090] As shown in FIG. 9, wireless network 900 may include a network of nodes, such as a user equipment (UE) 902, an access node 904, and a core network element 906. User equipment 902 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 Internet-of-Things (loT) node. It is understood that user equipment 902 is illustrated as a mobile phone simply by way of illustration and not by way of limitation.

[0091] Access node 904 may be a device that communicates with user equipment 902, 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 904 may have a wired connection to user equipment 902, a wireless connection to user equipment 902, or any combination thereof. Access node 904 may be connected to user equipment 902 by multiple connections, and user equipment 902 may be connected to other access nodes in addition to access node 904. Access node 904 may also be connected to other UEs. It is understood that access node 904 is illustrated by a radio tower by way of illustration and not by way of limitation.

[0092] Core network element 906 may serve access node 904 and user equipment 902 to provide core network services. Examples of core network element 906 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 906 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 906 is shown as a set of rack-mounted servers by way of illustration and not by way of limitation. [0093] Core network element 906 may connect with a large network, such as the Internet 908, or another internet protocol (IP) network, to communicate packet data over any distance. In this way, data from user equipment 902 may be communicated to other UEs connected to other access points, including, for example, a computer 910 connected to Internet 908, for example, using a wired connection or a wireless connection, or to a tablet 912 wirelessly connected to Internet 908 via a router 914. Thus, computer 910 and tablet 912 provide additional examples of possible UEs, and router 914 provides an example of another possible access node.

[0094] A generic example of a rack-mounted server is provided as an illustration of core network element 906. However, there may be multiple elements in the core network including database servers, such as a database 916, and security and authentication servers, such as an authentication server 918. Database 916 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 918 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 906, authentication server 918, and database 916, may be local connections within a single rack.

[0095] Each element in FIG. 9 may be considered a node of wireless network 900. More detail regarding the possible implementation of a node is provided by way of example in the description of a node 1000 in FIG. 10. Node 1000 may be configured as user equipment 902, access node 904, or core network element 906 in FIG. 1. Similarly, node 1000 may also be configured as computer 910, router 914, tablet 912, database 916, or authentication server 918 in FIG. 9. As shown in FIG. 10, node 1000 may include a processor 1002, a memory 1004, and a transceiver 1006. These components are shown as connected to one another by a bus, but other connection types are also permitted. When node 1000 is user equipment 902, additional components may also be included, such as a user interface (UI), sensors, and the like. Similarly, node 1000 may be implemented as a blade in a server system when node 1000 is configured as core network element 906. Other implementations are also possible.

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

[0097] As shown in FIG. 10, node 1000 may include processor 1002. Although only one processor is shown, it is understood that multiple processors can be included. Processor 1002 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 1002 may be a hardware device having one or more processing cores. Processor 1002 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. [0098] As shown in FIG. 10, node 1000 may also include memory 1004. Although only one memory is shown, it is understood that multiple memories can be included. Memory 1004 can broadly include both memory and storage. For example, memory 1004 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 1002. Broadly, memory 1004 may be embodied by any computer-readable medium, such as a non-transitory computer-readable medium.

[0099] Processor 1002, memory 1004, and transceiver 1006 may be implemented in various forms in node 1000 for performing wireless communication functions. In some embodiments, processor 1002, memory 1004, and transceiver 1006 of node 1000 are implemented (e.g., integrated) on one or more system-on-chips (SoCs). In one example, processor 1002 and memory 1004 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 1002 and memory 1004 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 1002 and transceiver 1006 (and memory 1004 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 1008. 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 1002 may be included in client device 102 and/or service device 120 as described above to perform the exemplary distributed permissions mechanism.

[0100] 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 1000 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. [0101] According to one aspect of the present disclosure, a client device of a distributed OS environment is provided. The client device may include an application client configured to, in response to a self-permission check indicating that access to a remote application service via an application server at a server device of the distributed OS environment is not granted, request permission to access the remote application service via the application server at the server device. The client device may include an OS framework configured to, in response to the self-permission check indicating that access to the remote application service via the application server at the server device is granted, perform a component permission check associated with the server device. The application client and the application server may be associated with an application.

[0102] In some embodiments, in response to the component permission check indicating that a first permission requirement (e.g., distributed permission information, remote package information, etc.) of the server device matches a second permission requirement (e.g., client permission information) of the client device, the application client may be further configured to access the remote application service via the application server at the server device.

[0103] In some embodiments, the application client may be further configured to determine whether access to the remote application service via the application server at the server device is granted based on the self-permission check.

[0104] In some embodiments, the application client may be configured to perform the selfpermission check by establishing a communication channel with the server device via a first service agent associated with the client device and a second service agent associated with the server device. In some embodiments, the application client may be configured to perform the self-permission check by receiving, via the communication channel, client permission information associated with the self-permission check from the second service agent.

[0105] In some embodiments, the application client may be further configured to cause a user interface of the client device to display a list of devices associated with the application. In some embodiments, the application client may be further configured to receive a selection of the server device based on an interaction with the user interface.

[0106] In some embodiments, in response to the selection of the server device being received, the application client may be configured to request permission to access the remote application service via the application server at the server device by establishing a communication channel with the server device via a first service agent associated with the client device and a second service agent associated with the server device. In some embodiments, in response to the selection of the server device being received, the application client may be configured to request permission to access the remote application service via the application server at the server device by sending, via the communication channel, a request for access to the remote application service via the application server at the server device. In some embodiments, in response to the selection of the server device being received, the application client may be configured to request permission to access the remote application service via the application server at the server device by receiving, via the communication channel, a response to the request from the server device.

[0107] In some embodiments, in response to the request granting access to the remote application service at the server device, the OS framework may be configured to perform the component permission check associated with the server device.

[0108] In some embodiments, the OS framework may be configured to perform the component permission check associated with the server device by reading remote package information from a package manager service (PMS) of the client device. In some embodiments, the OS framework may be configured to perform the component permission check associated with the server device by accessing client permission information from a manifest file associated with the application client. In some embodiments, the OS framework may be configured to perform the component permission check associated with the server device by comparing the remote package information and the client permission information.

[0109] In some embodiments, in response to the client permission information and the remote package information meeting a permission criterion (e.g., the same name, activity, label, etc.), the application client may be further configured to access the remote application service via the application server at the server device.

[0110] According to another aspect of the present disclosure, a server device of a distributed OS environment is provided. The server device may include a first service agent. The first service agent may be configured to establish a communication channel with a second service agent of a client device. The first service agent may be configured to perform a self-permission check associated with the client device and access to an application service via an application server of the server device. The first service agent may be configured to return information associated with the self-permission check to the client device. In response to the self-permission check not granting access to the application service via the server device, the first service agent may be further configured to receive a request for access to the application service via the application server by the client device. In response to the self-permission check not granting access to the application service via the server device, the first service agent may be further configured to cause a user interface of the server device to display the request for access to the application service via the application server by the client device. In response to the self-permission check not granting access to the application service via the server device, the first service agent may be further configured to receive a response to the request via an interaction with the user interface. In response to the self-permission check not granting access to the application service via the server device, the first service agent may be further configured to return the response to the request to the client device via the communication channel.

[0111] In some embodiments, the server device may further include an application server. In some embodiments, in response to the request granting access to the application service via the application server by the client device, the application server may be configured to enable the client device to access the application service

[0112] According to still another aspect of the present disclosure, a server device of a distributed OS environment is also provided. The server device may include a first service agent. The first service agent may be configured to receive a request for a client device to access an application service via an application server of the server device. The first service agent may be configured to perform a client permission check for the client device. In response to the client permission check indicating that permission information associated with the client device is not maintained by the first service agent, the first service agent may be further configured to establish a communication channel with a second service agent of the client device. In response to the client permission check indicating that permission information associated with the client device is not maintained by the first service agent, the first service agent is further configured to request the permission information from the second service agent of the client device. In response to the client permission check indicating that permission information associated with the client device is not maintained by the first service agent, the first service agent is further configured to receive the permission information from the second service agent of the client device.

[0113] In some embodiments, in response to the permission information indicating that the client device has permission to access the application service via the application server of the server device, the first service agent may be configured to enable the request for the client device to access the application service via the application server to be processed.

[0114] According to yet another aspect of the present disclosure, a method of wireless communication of a client device is provided. The method may include , in response to a selfpermission check indicating that access to a remote application service via an application server at a server device is not granted, requesting, by an application client, permission to access the remote application service via the application server at the server device. The method may include in response to the self-permission check indicating that access to the remote application service via the application server at the server device is granted, performing, by an OS framework, a component permission check associated with the application server at the server device. The application client and the application server may be associated with an application. The client device and the server device may be associated with a distributed OS environment.

[0115] In some embodiments, in response to the component permission check indicating that a first permission requirement of the server device matches a second permission requirement of the client device, the method may further include accessing, by the application client, the remote application service via the application server at the server device.

[0116] In some embodiments, the method may further include determining, by the application client, whether access to the remote application service via the application server at the server device is granted based on the self-permission check.

[0117] In some embodiments, the performing the self-permission check may include establishing, by a first service agent of the client device, a communication channel with the server device via a second service agent associated with the server device. In some embodiments, the performing the self-permission check may include receiving, via the communication channel, client permission information associated with the self-permission check from the second service agent.

[0118] In some embodiments, the method may further include causing, by the application client, a user interface of the client device to display a list of devices associated with the application. In some embodiments, in response to a request for access to the remote application service received by the application server at the client device, the method may further include receiving, by the application client, a selection of the server device based on an interaction with the user interface.

[0119] In some embodiments, in response to the selection of the server device being received, the method may further include establishing, by a first service agent of the client device, a communication channel with the server device via a second service agent associated with the server device. In some embodiments, in response to the selection of the server device being received, the method may further include sending, via the communication channel, a request for access to the remote application service via the application server at the server device. In some embodiments, in response to the selection of the server device being received, the method may further include receiving, via the communication channel, a response to the request from the server device. In some embodiments, in response to the selection of the server device being received, the method may further include performing, by the OS framework, the component permission check associated with the server device in response to the request granting access to the remote application service at the server device.

[0120] In some embodiments, the performing the component permission check associated with the server device may include reading, by the OS framework, remote package information from a PMS of the client device. In some embodiments, the performing the component permission check associated with the server device may include reading, by the OS framework, client permission information from a manifest file associated with the application client. In some embodiments, the performing the component permission check associated with the server device may include comparing, by the OS framework, the client permission information and the remote package information. In some embodiments, in response to the local package information and the remote package information meeting a permission criterion, the method may further include accessing, by the application client, the remote application service via the application server at the server device.

[0121] According to yet another aspect of the present disclosure, a method of wireless communication of a server device is provided. The method may include establishing, by a first service agent, a communication channel with a second service agent of a client device. The method may include performing, by the first service agent, a self-permission check associated with the client device and access to an application service via an application server of the server device. The method may include returning, by the first service agent, information associated with the selfpermission check to the client device. In response to the self-permission check not granting access to the application service via the server device, the method may further include receiving, by the first service agent, a request for access to the application service via the application server by the client device. In response to the self-permission check not granting access to the application service via the server device, the method may further include causing, by the first service agent, a user interface of the server device to display the request for access to the application service via the application server by the client device. In response to the self-permission check not granting access to the application service via the server device, the method may further include receiving, by the first service agent, a response to the request via an interaction with the user interface. In response to the self-permission check not granting access to the application service via the server device, the method may further include returning, by the first service agent, the response to the request to the client device via the communication channel.

[0122] According to still a further aspect of the present disclosure, a method of wireless communication of a server device is also provided. The method may include receiving, by a first service agent, a request for a client device to access an application service via an application server of the server device. The method may include performing, by the first service agent, a client permission check for the client device. In response to the client permission check indicating that permission information associated with the client device is not maintained by the first service agent, the method may further include establishing, by the first service agent, a communication channel with a second service agent of the client device. In response to the client permission check indicating that permission information associated with the client device is not maintained by the first service agent, the method may further include requesting, by the first service agent, the permission information from the second service agent of the client device. In response to the client permission check indicating that permission information associated with the client device is not maintained by the first service agent, the method may further include receiving, by the first service agent, the permission information from the second service agent of the client device. In response to the permission information indicating that the client device has permission to access the application service via the application server of the server device, the method may further include enabling, by the first service agent, the request for the client device to access the application service via the application server to be processed.

[0123] 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.

[0124] 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.

[0125] 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. [0126] Various functional blocks, modules, and steps are disclosed above. The particular arrangements provided are illustrative and without limitation. Accordingly, the functional blocks, modules, and steps 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 steps, and any such subset is permitted. [0127] 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.