Title of Invention: Systems and methods for application access control Abstract: A system described herein may provide a technique for selectively granting or revoking/denying access to applications, services, data, etc. to a User Equipment (“UE”) based on location-based policies and a network-determined location of the UE. The network-determined location may be determined by elements of a wireless network, such as a Mobility Management Entity (“MME”), Access and Mobility Management Function (“AMF”), or other suitable element. Detailed Description: Part general_description_paragraphs: Part BACKGROUND: Sensitive information, systems, devices, etc. may require user authentication in order to ensure that unauthorized users do not have access to such sensitive information, systems, devices, etc. For instance, a malicious user may obtain access to a critical network component in a network data center, which may interfere with the operation of a network, such as a wireless network, an Internet service provider network, etc. Further, an unauthorized user may obtain access to sensitive information, such as a company's proprietary information or other sensitive information, which may be a violation of security policies or non-disclosure obligations, or simply pose an increased risk for misuse. Part DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS: The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Embodiments described herein provide for geographic location-based access control for systems accessible to a User Equipment (“UE”) device. For example, in accordance with embodiments described herein, access to applications, services, devices, information, networks, etc. may be provided to a UE based on a determined location of the UE. Location-based access control, in accordance with embodiments described herein, may be useful in situations where access to a particular application, service, device, network, etc. outside of a particular geographical location or region is undesirable, insecure, or the like. For example, a company, institution, etc. may allow access to internal or proprietary systems (e.g., applications, IoT systems, data centers, databases, etc.) to UEs that are located within a particular facility (e.g., a building in which such internal or proprietary systems are physically located), within a particular threshold proximity of such internal or proprietary systems (e.g., within about 100 meters or some other threshold proximity). On the other hand, such company, institution, etc. may block or degrade access to internal or proprietary systems to UEs that are located outside of a particular facility, outside of a threshold proximity of the internal or proprietary systems, etc. As further described herein, one or more other factors may be used in the location-based authentication techniques of some embodiments, such as policies associated with particular UEs or users, user roles, time-based policies, username and password authentication factors, biometric authentication factors, and/or one or more other factors. As discussed herein, the “access” granted (or not granted) to a given UE may include the enabling or disabling of access to applications, services, devices, networks, etc., available at the UE. For example, the UE may be associated with a set of applications (or “apps”) that are available for use (or available with full functionality). The applications may have components that are installed on the UE, and/or in some implementations may have components that are accessible to the UE via network connectivity and are hosted on an application server in or connected to the network. When the system has received an indication that the UE is within a location for allowable use of an application, it may make the application fully available for use by the UE, according to policies that require certain location, time, user, role or other requirements for access. Likewise, when the system receives an indication that the UE is not within a location for allowable use of an application, it may make the application unavailable for use (or available with limited functionality). Further description of example systems and methods that implement the foregoing are described below. The applications, services, devices, networks, etc., that may be access controlled can include various systems local to and/or remote from the UE. In some embodiments, such systems include applications/services/devices executing (at least partially) at the UE. Such system may also include application/services/devices executing remotely from the UE, such as on/through remote systems accessible by the UE when the UE is communicatively coupled thereto via one or more networks (e.g., Software as a Service (“SaaS”) applications, client/server applications, network-based applications, microservices, IoT devices and/or other applications/services/devices that include computations or other application functions performed by a remote device or system). For example, as discussed below, applications and services may be executed by an application server and/or some other suitable device or system, which in some implementations may be part of a Multi-Access/Mobile Edge Computing (“MEC”) edge computing facility. In such scenarios, the UE may execute a “lightweight” or “thin” client application that performs local input and/or output functions, networking functions to communicate with a remote device or system, etc., and communicates with the remotely-executing application to provide the input/output related to the remotely-executing application. The UE may be communicatively coupled to a wireless network (e.g., via a radio access network (“RAN”), such as a Long-Term Evolution (“LTE”) RAN, a Fifth Generation (“5G”) RAN, and/or some other type of RAN). The RAN and/or a core network (e.g., an Evolved Packet Core (“EPC”), a 5G Core (“5GC”), and/or some other type of core network) to which the RAN is communicatively coupled may include a network-based location determination facility comprising one or more devices or systems that may monitor or otherwise determine the location of UEs communicatively coupled to the RAN. Such devices or systems may include, for example, a mobility management system (e.g., a Mobility Management Entity (“MME”), an Access and Mobility Management Function (“AMF”), and/or some other device or system that performs operations related to intra-RAN or inter-RAN mobility for one or more UEs), a RAN base station (e.g., an evolved Node B (“eNB”), a Next Generation Node B (“gNB”), or some other type of base station), or some other suitable device or system. The location of the UE may be determined by the network (e.g., by the MME, AMF, base station, other network element, etc.) based on cell triangulation techniques, real-time kinematic (“RTK”) techniques, and/or other suitable techniques. UEs may also have location determination capabilities, such as using Global Positioning System (“GPS”) techniques or other suitable techniques. The use of network-determined location for the UE, in accordance with some embodiments, may be more reliable, accurate, or secure than a UE-determined location of the UE. For example, malicious users may provide “spoofed” or otherwise inaccurate UE location information. In contrast, network-determined location information may be difficult or impossible for such malicious users to modify, spoof, etc., as a network may be able to determine a UE's position using RTK and/or other suitable techniques without needing UE-based information. In some embodiments, a combination of UE-determined location and network-determined location may be used to determine a location for the UE for purposes of applying an access control policy (for example, using the UE-determined location as a verification for the network-determined location, or vice-versa). FIGS. 1-3 illustrate an example environment using a location-based access control implementation. As shown in FIG. 1, for example, region 100 may be a geographical region specified in one or more access policies for UE 101, where attempts to access one or more applications, services, devices, networks, or the like (generally “systems”), may be permitted for UE 101 when UE 101 is located inside region 100. UE 101 may be communicatively coupled to network 103, which may include a RAN of a wireless network. As noted above, network 103 may include and/or may be communicatively coupled to one or more location determination facilities comprising devices or systems such as mobility devices or systems, or the like, such as an MME or an AMF. As also noted above, such devices or systems of network 103 may monitor (at 102) a geographical location of UE 101, which may include a periodic, continuous, intermittent, event-based, and/or other type of monitoring of the geographical location of UE 101. The location may be monitored and represented as latitude and longitude coordinates, location codes, street addresses, and/or other suitable representations of geographical location. In some embodiments, the location of UE 101 may be represented as a point in two-dimensional and/or three-dimensional space (e.g., including a height or altitude component), or as a two-dimensional or three-dimensional shape (e.g., polygon, radius about a point, etc.). For example, the shape may represent a margin of error of the determination of UE 101 (e.g., a two-meter radius about a point may be used when a margin of error of the location of UE 101 is about two meters). The location of UE 101 may be provided (at 104) to Geographic- and/or Time-based Access Control System (“GTACS”) 105. For example, GTACS 105 may be communicatively coupled to one or more devices or systems of network 103, such that GTACS 105 may receive the geographical location information associated with UE 101. For example, GTACS 105 may be communicatively coupled to a Service Capability Exposure Function (“SCEF”), a Network Exposure Function (“NEF”), and/or some other device or system that provides an API or other interface via which GTACS 105 may receive the location information from a location determination facility. In some embodiments, GTACS 105 may receive (at 104) the location information associated with UE 101 on an ongoing basis, such as a periodic or intermittent basis. In some embodiments, GTACS 105 may receive the location information associated with UE 101 on an event-based basis, such as when network 103 detects a change in the location of UE 101 (e.g., if UE 101 moves from one location to another), when network 103 detects a change in a connection status of UE 101 (e.g., when UE 101 transitions from an idle mode to an active mode or vice versa, when UE 101 connects to network 103, or the like), and/or in response to other events. In some embodiments, network 103 may “push” the UE location information to GTACS 105 (e.g., may provide the location information to GTACS 105 without a specific request from GTACS 105, or as part of a “subscribe”/“push” messaging arrangement), and/or may provide the UE location information in response to specific requests from GTACS 105. In some implementations, GTACS 105 may also receive UE location information from UE 101 (e.g., as may be determined by a location determination facility local to UE 101, such as a GPS unit). GTACS 105 may maintain a set of access policies 107 (referred to herein in plural as “policies 107” or singularly as “policy 107”) that specify location-based restrictions on how UE 101 is able to interact with certain applications, services, devices, networks, etc. For example, a policy 107 may specify that certain applications, services or devices are blocked (e.g. not visible, not discoverable, not launchable, etc.) when UE 101 is outside of region 100, and/or that such applications, services or devices are not blocked when UE 101 is within region 100. As a further example, a particular policy 107 may specify that authentication requests associated with UE 101 for certain applications, services or devices should be denied when UE 101 is outside of region 100, and/or that authentication requests associated with UE 101 should be granted when UE 101 is within region 100 (and/or that such authentication requests should not be denied on the basis of location, but may be denied based on other factors such as an incorrect user name or password). As an additional example, a policy 107 may specify that the performance of an application, service or device may be degraded in some form (e.g., certain features disabled, certain devices unreachable, etc.) when UE 101 is outside of region 100, and/or that such applications, services or devices are not degraded when UE 101 is within region 100. In some embodiments, policies 107 may be associated with particular UEs 101, groups of UEs 101, users, or groups of users. In some embodiments, UE 101 may be in a group of UEs, and policy 107 may indicate conditions (e.g., location-based conditions and/or other conditions) based on which UEs that are associated with the group should be permitted to access the applications, services, devices or networks specified by the policy 107. Such groups, for example, may be associated with departments of a company, users with particular roles (e.g., technicians, admins, support, etc.), types of UEs (e.g., mobile telephones, tablets, laptops, wearable devices, etc.), or the like. In some embodiments, policies 107 may be associated with particular services, applications, devices, networks, etc. For example, a first policy 107 may require that UE 101 be present within region 100 for access to a first set of services or applications (e.g., a service that provides status updates or performance metrics regarding a particular device or system, an application via which UE 101 may modify a configuration of a particular device or system, etc.), while a second policy may require that UE 101 be present within a different region for access to a different second set of services or applications. Accordingly, multiple policies may be applicable to a single UE 101. In some embodiments, region 100 may be specified (e.g., by one or more policies 107) as an absolute geographical region. For example, policy 107 may specify region 100 as a set of latitude and longitude coordinates that define one or more bounds, edges, sides, etc. of region 100. In some embodiments, policy 107 may specify region 100 as a relative region, relative to the position or location of one or more reference points. As one example, a reference point may be defined as the geographical location of a device, system, landmark, a centroid, etc. other than UE 101. For example, a particular policy 107 may specify a reference point as a mobile server rack, a mobile repair platform (e.g., which may be used by technicians to maintain or repair network equipment), or the like, which may be transported between different facilities. Such mobile equipment may, in some embodiments, include location determination hardware and/or GTACS 105 may otherwise receive location information for such mobile equipment, based on which GTACS 105 may determine whether UE 101 is within a particular proximity of such mobile equipment. In the context of this example, region 100 may refer to an absolute geographical region, or a geographical region that is determined relative to a reference point such as mobile equipment. In FIG. 1, GTACS 105 may determine (at 106) that UE 101 is outside of region 100 specified by one or more policies 107. Based on determining that UE 101 is outside of region 100, GTACS 105 may provide (at 108) restriction information that indicates that UE 101 should be restricted from accessing applications, services, devices, etc., that are specified in policy 107. In some embodiments, the restriction applied may be specified as part of policy 107—such as blocking access, degrading access, preventing authorization, etc. Application of the restriction may vary according to implementation. As an example, a UE 101 may attempt to use a system (e.g., an application, a service, a device) that requires authentication. When the UE 101 provides credentials to the system, the system may make a request to GTACS 105 (e.g., via an API or other suitable communication pathway) to determine whether the UE 101 may access the system. GTACS 105 may respond with restriction information 108 indicating that the UE 101 is restricted access to the system. Additionally, or alternatively, UE 101 may communicate directly with GTACS 105 (e.g., on request, periodically, intermittently, and/or on some other basis) to determine whether UE 101 is authorized to access the system. In situations where UE 101 is determined by GTACS 105 to be authorized to access the desired system, GTACS 105 may return restriction information to UE 101 (e.g., including a “token” or other credential) that UE 101 may present to such system indicating its authorization for use. If, on the other hand, UE 101 is not authorized to access such applications, services, etc., GTACS 105 may return restriction information to UE 101 including an indicator that it is not authorized to access such application, services, etc. In some implementations, UE 101 may present an indication that such systems are not available for use to a user of UE 101 via a user interface. In some embodiments, GTACS 105 may provide restriction information to applications, services, devices, etc., that are specified in policies 107, such that access attempts by UE 101 may be blocked or degraded. For example, a system (e.g., an application, service, device, network, etc) may receive a request to use the system from UE 101. The request may be an initial request (e.g., to start, launch, connect, etc.) or part of an existing series of interactions with the system. Upon receipt of restriction information 108 indicating that access by UE 101 should be restricted, the system may block or degrade access to the system by the UE 101—for example, by preventing/terminating execution of an application, service or portion of either, by preventing/terminating interaction with a device or a portion of a device, etc. Such blocking or degrading may include providing a notification to a user of UE 101 via a user interface indicating that such blocking or degrading is taking place. In some embodiments, GTACS 105 may provide restriction information to an application, service, device or network to block access by UE 101 by making restricted applications, services, devices or networks undiscoverable. For example, where an application or service is present on a system remote from UE 101, the restriction information provided by GTACS 105 may prevent UE 101 from “seeing” (e.g., removing from a UI display, not including in search results, etc.) the restricted system. In some implementations, UE 101 may include a facility to manage restrictions applicable to applications, services, devices, networks, etc., local to UE 101. For example, UE 101 may provide a service that communicates with GTACS 105 to receive restriction information 108 and cause UE 101 to enforce restrictions (e.g., hide, block, degrade, prevent authorization, etc.) local to UE 101. In some embodiments, GTACS 105 may provide the restriction information 108 to one or more other devices or systems. For example, GTACS 105 may provide the restriction information 108 to one or more devices or systems specified by policy 107, one or more devices or systems that are located within region 100, one or more devices or systems that are located within a threshold proximity of UE 101. For example, an access control system local to region 100 may be used to manage access to systems local to region 100, and providing the restriction information 108 to such access control system allows the access control system to manage access requests to applications, services, devices or networks for which the access control system has responsibility. Continuing with the example above, as shown in FIG. 2, UE 101 may move (at 210) into region 100. For example, UE 101 may physically move to region 100, and/or region 100 may move such that UE 101 becomes located within region 100 (e.g., as discussed above with respect to the example of mobile equipment based on which region 100 is defined). Network 103 may continue to monitor (at 212) the location of UE 101, and may provide (at 214) UE location information (e.g., indicating that UE 101 is located within region 100) to GTACS 105. Based on the received location information, GTACS 105 may determine (at 216) that UE 101 is located within region 100 as specified by policy 107, and may provide restriction information that indicates UE 101 is allowed access to those applications, services, devices, etc., specified by policy 107 (at 218) while UE 101 is located within region 100. How the restriction information is provided may depend on the implementation used, as noted above. For example, where restriction is implemented through authentication requests, the restriction information may be provided in response to an authentication process. Where restriction is implemented through initial/continuing access, the restriction may be provided to the system to allow the system to be executed by the UE 101. Such applications, services, etc., may remain available while UE 101 remains within region 100, and may become unavailable once UE 101 leaves region 100. Continuing the example above, as shown in FIG. 3, UE 101 may exit (at 320) geographical region 100. For example, UE 101 may be physically moved, and/or a reference point (e.g., a location of mobile equipment or some other device or system) associated with region 100 may move such that UE 101 is no longer located within region 100. Network 103 may continue to monitor (at 322) the location of UE 101, and provide (at 324) location information associated with UE 101 to GTACS 105. Based on the received location information, GTACS 105 may determine (at 326) that UE 101 is outside of region 100 specified by policy 107, and may revoke the previously granted access, for example, by providing restriction information that indicates the UE 101 is no longer allowed to access applications and/or services associated with policy 107. How the restriction information is provided may depend on the implementation used, as noted above. For example, where restriction is through authentication requests, the restriction information may be provided in response to an authentication process. Where restriction is through initial/continuing access, the restriction may be provided to the system to terminate/degrade any current access to the system and/or to block/degrade future access by the UE 101. Based on the revocation, in some implementations, UE 101 may indicate to a user via a user interface that UE 101 is no longer permitted access. As noted above, different policies 107 may be associated with different geographical regions. For example, as shown in FIG. 4, UE 101 may be located within geographical region 400-1 at a first time. While not necessarily explicitly shown in this figure or subsequent figures, GTACS 105 may continue to receive location information regarding UE 101 from network 103 and/or some other suitable device or system. Based on the presence of UE 101 within geographical region 400-1, GTACS 105 may provide indication (at 402) of allowance of first access to UE 101. For example, GTACS 105 may determine that geographical region 400-1 is associated with a first policy 107, with a first set of access parameters. Access parameters may refer to, for example, a set of permissions, applications, or the like that may be accessible to UE 101 when UE 101 is located within a particular region associated with a particular policy 107 (e.g., geographical region 400-1, associated with a first set of access parameters in this example). As noted above, such access parameters may include indicating to UE 101 or some other device or system that UE 101 is located within a particular region associated with a particular policy 107, based on which UE 101 may be permitted to access one or more applications or services (either local to UE 101 or through connection to another device or system that provides such applications or services). As further shown, UE 101 may move from geographical region 400-1 to geographical region 400-2. Based on the movement of UE 101 from geographical region 400-1 to geographical region 400-2, GTACS 105 may provide indication (at 404) of a revocation of the allowance of first access, and may provide indication of allowance of second access. For example, GTACS 105 may indicate to UE 101 and/or some other device or system that applications, services, and/or other access granted to UE 101 when UE 101 is located within geographical region 400-1 are no longer authorized for access by UE 101. In this example, geographical region 400-2 may be associated with a different second set of access parameters, such as a different set of applications, services, information, etc. associated with geographical region 400-2 (e.g., as specified by one or more policies 107). Similarly, UE 101 may move from geographical region 400-2 to geographical region 400-3, based on which GTACS 105 may provide indication (at 406) of a revocation of the allowance of second access (e.g., as granted when UE 101 entered and/or remained within geographical region 400-2) and may provide indication of allowance of third access associated with geographical region 400-3 (e.g., based on one or more policies 107 specifying third access parameters associated with geographical region 400-3). As further shown, UE 101 may move from geographical region 400-3 to geographical region 400-4, based on which GTACS 105 may provide indication (at 408) of a revocation of the allowance of the third access (e.g., as granted when UE 101 entered and/or remained within geographical region 400-3) and may provide indication of allowance of fourth access associated with geographical region 400-4 (e.g., based on one or more policies 107 specifying fourth access parameters associated with geographical region 400-4). As similarly noted above, granting access “to” UE 101 may include indicating such access to one or more devices or systems which may be communicatively coupled to UE 101 (e.g., which may provide services, data, etc. to UE 101). As also noted above, the same policy 107 may apply to certain UEs or users, or groups of UEs or users. For example, a particular policy 107 may include identifiers of one or more UEs, such as International Mobile Subscriber Identity (“IMSI”) values, International Mobile Station Equipment Identity (“IMEI”) values, Globally Unique Temporary Identifier (“GUTI”) values, Subscription Permanent Identifier (“SUPI”) vales, Mobile Directory Number (“MDN”) values, Internet Protocol (“IP”) addresses, and/or other suitable identifiers. In some embodiments, UE identifiers may be provided in connection with location information, in order to associate a UE included in a policy specification with such location information. In some embodiments, a particular policy may include identifiers of particular users, such as user identifiers, user names, and/or other suitable identifiers. Such user identifiers may be used in situations where a given user may use different UEs to attempt to gain access to one or more services, applications, etc. In such embodiments, GTACS 105 may receive such identifiers in conjunction with access requests associated with a given UE 101, such that GTACS 105 may determine that a given access request, associated with a particular UE 101, is also associated with a particular user identifier. For example, as shown in FIG. 5, two example UEs (i.e., UE 101-1 and UE 101-2) may be located within region 500. Region 500 and UE 101-1 may be associated with a particular policy 107, based on which GTACS 105 may provide indication (at 502) that UE 101-1 may access one or more applications, services, or the like specified by policy 107. For example, GTACS 105 may receive a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1, based on which GTACS 105 may determine that UE 101-1 is presently located within a geographical region specified by policy 107, and may further determine that UE 101-1 is authorized to access the one or more applications, services, etc., specified in policy 107 when located within geographical region 500. On the other hand, GTACS 105 may provide indication (at 504) that UE 101-2 has restricted access to such applications, services, etc., based on UE 101-2 not being identified as an authorized UE by policy 107, even though UE 101-2 is reported as located within region 500 specified by policy 107. In some embodiments, as noted above, GTACS 105 may allow or restrict access to one or more applications, services, etc. based on time-based criteria. FIG. 6 illustrates an example or a time-based restriction. For example, assume that UE 101, shown in FIG. 6, remains stationary. In this example, GTACS 105 may maintain a set of policies 107, which include time-based criteria (e.g., in addition to location-based criteria). For example, a first policy 107 may be associated with a first set of access parameters during a first time period (e.g., between times t0 and t1), a second policy 107 may be associated with a second set of access parameters during a second time period (e.g., between times t1 and t2), a third policy 107 may be associated with a third set of access parameters during a third time period (e.g., between times t2 and t3), and a fourth policy 107 may be associated with a fourth set of access parameters during a third time period (e.g., starting at time t3). A particular policy 107 may specify a time period in various ways, such as a start time, an end time, a duration, etc. As shown, at time to, GTACS 105 may grant (at 602) first access to UE 101, based on the time-based criteria associated with the first policy 107. At time t1, GTACS 105 may revoke (at 604) the first access due to first policy 107 and grant second access to UE 101 due to second policy 107. As further shown in FIG. 6, GTACS 105 may revoke (at 606) the second set of access parameters at time t2 based on the second policy 107, and may grant a third set of access parameters at time t2 based on the third policy 107. Similarly, GTACS 105 may revoke (at 608) the third access parameters at time t3 based on the third policy 107 and grant fourth access parameters at time t4 based on the fourth policy 107. As discussed above, different access parameters may be associated with different applications or functions at UE 101, different services or data that may be provided to UE 101 (e.g., by an application server or some other device or system), or the like. As also discussed above, granting or revoking access may include one or more indications provided by GTACS 105 to UE 101 and/or to one or more other devices or systems that are communicatively coupled with UE 101. Based on such indications, UE 101 may enable or disable, activate or deactivate, etc. applications, services, devices, or the like. FIG. 7A illustrates an example of enabling and/or disabling access to applications and/or other functionality at UE 101 based on access being allows or restricted by GTACS 105. As shown, for example, GUI 701 may be displayed by UE 101. GUI 701 may be associated with a “home” screen, an “apps” screen, an “apps” folder, and/or other representation of applications or functions that may be accessed via UE 101. In this example, applications that may be selected, opened, accessed, etc. are represented by shaded square icons. For example, a user may actuate or select a particular icon via a haptic selection, a voice command selection, and/or some other type of selection, and the selection of the particular icon may cause UE 101 to execute, run, etc. an application or function associated with the particular icon. GUI 701 may further include a set of icons that are represented in a manner that indicates that applications associated with the icons are unavailable and/or are available with limited functionality. In this example, such manner of representation may include a dashed line around the icons, a modified shading of the icons, a replacement of color icons with grey scale or black and white icons, a replacement of an application icon with a “download” or “redownload” icon (e.g., a cloud with a downward facing arrow), and/or some other type of representation. In some embodiments, other types of representation of unavailable or limited functionality may be provided via UE 701, such as an “X” or other overlay over respective icons, notification 703, and/or other representations. Notification 703 may be displayed, for example, when a user selects an icon associated with an application that is presently unavailable due to one or more policies 107. For example, notification 703 may include a “pop-up” notification, dialog box, or other type of visual indicator. In some embodiments, some other type of indicator may be provided, such as an audible indicator, a blinking light, or the like. In some embodiments, notification 703 may include information associated with one or more criteria associated with policy 107, such as an indication of a time and/or location associated with policy 107. In the example of FIG. 7A, notification 703 indicates that the policy is associated with a particular location (“server room”) and time (“9 AM-5 PM”). In practice, notification 703 may provide less information, additional information, and/or different information associated with policy 107. As further shown, UE 101 may receive (at 702) restriction information from GTACS 105 indicating access is now allowed, where the access includes an activation, enabling, etc. of the applications that were indicated by GUI 701 as being disabled. GUI 705 may include an unmodified version of the icons that were modified in GUI 701, such as a removal of the dashed lines, a restoration of original color or shading of the icons, removal of one or more notifications (e.g., notification 703), or the like. In some embodiments, GUI 705 may include notification 707, which may indicate that applications that were previously unavailable are now available (e.g., based on the access received (at 702) from GTACS 105). In some embodiments, UE 101 may implement an API, application, sandbox, launcher, or the like, which communicates with GTACS 105 to receive restriction information that includes indications of whether access to particular applications has been granted or revoked, and which may further communicate with an operating system, kernel, etc. of UE 101 in order to make such applications available or unavailable. As further shown, when access to the applications is revoked (at 704) by GTACS 105 providing restriction information indicating an access restriction by UE 101, UE 101 may present GUI 701, which includes the modified icons associated with the unavailable applications. In some embodiments, revocation of access may cause UE 101 to delete application data associated with the applications from a local memory, cache, etc. of UE 101. FIG. 7B shows another example of enabling and/or disabling access to applications and/or other functionality at UE 101 based on access being restricted by GTACS 105. As shown in FIG. 7B, UE 101 may interact with application server 751 over network 103 to obtain access to a set of applications available at application server 751. UE 101 may implement a facility local to UE 101 that acts as a “thin” client—the facility may receive user input (e.g., haptic input, voice input, and/or other types of input), forward the input to application server 751 via network 103, receive presentation information (e.g., graphical information, audio information, and/or other information) from application server 751 over network 103, and present the information on a user interface of UE 101. In some embodiments, such “thin” client applications may implement one or more APIs or other communication pathways via which the applications may communicate with one or more application servers 751, etc. In some embodiments, selection or initialization of the facility at UE 101 may cause the facility to communicate with associated application servers 751 to obtain presentation information for those applications that are available at application servers 751. When a user provides an indication that an available application should be launched, that indication may be provided to application server 751 that has made the application available, such that the application server 751 may instantiate a server-side application instance to communicate with the facility executing at UE 101. In some embodiments, one or more application servers 751 may be part of a MEC facility that provides low latency communications with UE 101, such that the interactions between UE 101 and application server 751 are perceived by users of UE 101 as being as if the application being executed is local to UE 101. In some implementations, a single “front end” application server 751 may be responsible for interactions with a UE 101 through a service that communicates with the facility at UE 101 providing the “thin” client, and such front end application server 751 may interact with other application servers 751 to provide individual applications available for use by UE 101 (and presented in the user interface of UE 101). As similarly noted with respect to the example of FIG. 7A above, a particular application server 751 may determine whether UE 101 is authorized to access applications at application server 751 based on the geographical location of UE 101, time-based criteria, authentication factors provided by UE 101, and/or other factors. For example, the location information for UE 101 may be periodically or intermittently provided to GTACS 105 (e.g., from a location determination facility of network 103 and/or from UE 101), and GTACS 105 may apply one or more policies 107 that are applicable to UE 101 to determine restrictions associated with certain applications, services, devices, etc., that UE 101 may attempt to access. GTACS 105 may provide restriction information to application servers 751 to allow application servers 751 with applications, services, devices, etc., that are specified in policies 107 to set restrictions on such applications, services, devices, etc. One or more application servers 751 may provide APIs to request and/or receive such restriction information from GTACS 105, and such APIS may include the ability to subscribe to “push” notifications related to changes in the location of UE 101 and/or applications available on application server 751. In the example of FIG. 7B, access to applications 771, 772 and 773 may be specified in policies 107 as being restricted from UE 101 unless UE 101 is within a region R containing location L1. Further assume that policies 107 also contain a restriction that application 773 may only be accessible when UE 101 is in Region R during a time period containing a time T1. Policies 107 may also specify the type of restrictions applicable to applications 771, 772 and 773. For example, at time T0, application 771 may be displayed in user interface 761 of UE 101, but may not be launched by UE 101 (e.g., as denoted by the dashed line in user interface 761), while applications 772 and 773 may not be shown on a user interface of UE 101 when they are not accessible (e.g., to impose a higher level of security associated with those applications). Accordingly, when UE 101 is reported being in a location L0 outside of region R at time T0, application server 751 provides presentation information that causes a user interface of UE 101 to display its available applications as not including applications 771, 772 and 773. Additionally, application 771 is displayed in user interface 761 using a depiction that indicates it is unavailable (e.g., using shading, iconography, etc.). If a user were to attempt to launch application 771, a notification such as notification 764 may be provided to indicate the inaccessibility of application 771 to UE 101 and, in some implementations, the restriction being applied. When UE 101 moves to be located at a Location L1 which is inside Region R at a time T1, this location change may be reported to GTACS 105, which in turn may provide restriction information to application servers 751 based on policies 107. Application server 751 serving UE 101 may provide presentation information to UE 101 that now causes user interface 762 of UE 101 to display the availability of applications 771, 772, and 773. A user of UE 101 may now provide user input to cause any of applications 771, 772, and 773 to launch and execute (which may require further authorization steps such as identity authentication, role-based authorization, and the like). While UE 101 remains in Location L1, but as time passes to a time T2 which is outside of the time period when application 773 is available to UE 101, GTACS 105 may provide restriction information to application servers 751 based on policies 107. Application server 751 serving UE 101 may provide presentation information to UE 101 that now causes user interface 763 of UE 101 to display the availability of applications 771 and 772, but not application 773. In some embodiments, allowing or restricting access (such as described in the examples above) may include allowing or restricting access to one or more networks, such as one or more RANs, core networks, or portions thereof. For example, GTACS 105 may determine that a particular policy 107 is associated with access to a particular “slice” of a 5G network, where a slice corresponds to a “network slice” as implemented according to Third Generation Partnership Project (3GPP) specifications, and includes instances of one or more network functions. The different slices may provide differentiated levels of service, such as service in accordance with different Quality of Service (“QoS”) parameters. The different slices may additionally or alternatively provide service to different applications or application types. In such situations, GTACS 105 may provide indications to a network element managing network access control and/or slice access control (e.g., a base station to which UE 101 is communicatively coupled, an AMF, a Session Management Function (“SMF”), a Unified Data Management function (“UDM”), a Network Slice Selection Function (“NSSF”) or some other element), which may allow or block UE 101 to connect to a particular slice of the core network. FIG. 8 illustrates an example process 800 for granting and/or revoking access to one or more applications, services, devices, etc. to UE 101 based on geographical location-based and/or time-based policies. In some embodiments, some or all of process 800 may be performed by GTACS 105. In some embodiments, one or more other devices may perform some or all of process 800 (e.g., in concert with, and/or in lieu of, GTACS 105). As shown, process 800 may include receiving and/or maintaining (at 802) a set of geographical location-based and/or time-based policies. For example, as discussed above, GTACS 105 may receive and/or maintain a set of policies 107, which may be associated with particular UEs or groups of UEs. Policies 107 may specify applications, services, devices, etc. that UE 101 may attempt to access when located within a particular geographical region. In some embodiments, as discussed above, policies 107 may specify time-based criteria, such that the location-based criteria may further be constrained by the time-based criteria. Process 800 may further include monitoring (at 804) location information of a particular UE 101. For example, GTACS 105 may monitor the location information of UE 101, as well as one or more other UEs, based on location information determined and provided by a network-based location determining facility (such as base station to which UE 101 is connected, a mobility element to which such base station is communicatively coupled (e.g., a MME, an AMF, or the like)), and/or some other suitable device or system that determines the location of UE 101. In some embodiments, the location information may be provided by the UE 101 itself from its local location determination facility, however the location information may also be determined by an entity other than UE 101 itself, such that UE 101 is not able to generate or provide inaccurate or “spoofed” location information. Process 800 may additionally include identifying (at 806) access parameters associated with a particular policy. For example, GTACS 105 may identify one or more applications that UE 101 is authorized to access when satisfying conditions or criteria associated with policy 107 (e.g., location-based and/or time-based criteria), may identify one or more networks or network slices that UE 101 is authorized to access when satisfying such conditions or criteria, may identify one or more application servers or other devices or systems that are authorized to provide data or services to UE 101 when UE 101 satisfies such conditions or criteria, etc. Process 800 may also include determining (at 808) whether the monitored location of UE 101 and a current time correspond to a particular one of the received and/or maintained policies 107. For example, GTACS 105 may determine whether a location of UE 101 (e.g., as monitored at 804) satisfies location-based criteria associated with a particular policy 107. For example, GTACS 105 may determine whether UE 101 is located inside a region specified by policy 107. In situations where policy 107 includes time-based criteria and/or other criteria, GTACS 105 may further determine whether the other criteria is also met. In some embodiments, GTACS 105 may determine (at 808) whether the location, time, and/or other criteria are met in an ongoing process (e.g., without a specific request or message from UE 101 or some other device or system). In some embodiments, GTACS 105 may determine (at 808) whether the location, time, and/or other criteria are met in response to a request (e.g., from UE 101, from an application server or MEC that is communicatively coupled to UE 101, or some other device or system) or in response to some other event. In some embodiments, GTACS 105 may authenticate UE 101 based on one or more factors prior to determining whether the criteria associated with policy 107 are met. For example, GTACS 105 may authenticate UE 101 based on a user name and password, based on an authentication token provided by UE 101 or some other device or system (e.g., which may be generated upon successful biometric authentication or some other type of authentication), or some other type of authentication factor. If the criteria associated with a particular policy 107 are met (at 808—YES), process 800 may further include granting (at 810) access to UE 101 in accordance with the access parameters associated with policy 107. For example, as discussed above, GTACS 105 may provide an indication to UE 101 and/or one or more devices or systems that are communicatively coupled to UE 101 (for example, an application server, a MEC facility, etc.) that UE 101 has been granted access to one or more applications, services, devices, etc. UE 101 may accordingly provide access to a user of UE 101, for example, through a user interface that displays information on applications, services, devices, etc., that are accessible by UE 101, and/or notifications related to accessibility/inaccessibility. In some implementations, the user interface may be through a facility providing a “thin” client or other type of application, and one or more application servers may provide certain types of information or data to UE 101 reflective of applications, services, devices, etc., that are accessible (or inaccessible) by UE 101. If, on the other hand, the criteria associated with policy 107 are not met (at 808—NO), process 800 may additionally include revoking (at 812) access to UE 101 according to the access parameters of policy 107. For example, if access had previously been granted (at 810) to UE 101, such access may be revoked. If access has not been previously granted, GTACS 105 may continue to not grant access based on the one or more criteria associated with policy 107 not being met. Revoking access may include providing restriction information to UE 101 and/or other devices/applications indicating that UE 101 has restrictions (e.g., blocked access, degraded access) to the use of certain applications specified by the policy 107. As further shown, after granting (at 810) or revoking (at 812) access to UE 101, GTACS 105 may continue to monitor (at 804) the location of UE 101. In this manner, GTACS 105 may dynamically and in real time (or in near-real time) continue to provide access in accordance with geographical location-based and/or time-based policies 107. While the example of FIG. 8 is provided in the context of one policy 107 and one UE 101, similar concepts may apply to multiple policies and/or multiple UEs 101. For example, GTACS 105 may evaluate criteria associated with multiple policies 107 for a given UE 101, and may grant or revoke multiple access parameters associated with multiple policies 107 for UE 101. As another example, GTACS 105 may evaluate criteria associated with one policy 107 for multiple UEs 101 (e.g., in situations where the same policy 107 is associated with multiple UEs 101, such as a defined group of UEs 101). As yet another example, GTACS 105 may evaluate criteria associated with multiple policies 107 for multiple UEs 101. In some embodiments, different policies 107 may be associated with different priority levels. Such priority levels may be a factor in which a policies 107 are applied in the situation where conflicting policies 107 apply. For example, if a given UE 101 would be granted access in a given situation (e.g., in a particular geographical location, for a particular application, etc.) under a first policy 107, but would be denied access in the same situation under a second policy in the same situation, the policy with the higher priority level may take precedence. For example, if the first policy 107 has a higher priority, then UE 101 would be granted access in this situation. If, on the other hand, the second policy 107 has a higher priority, then UE 101 would be denied access in this situation. FIG. 9 illustrates an example environment 900, in which one or more embodiments may be implemented. In some embodiments, environment 900 may correspond to a 5G network, and/or may include elements of a 5G network. In some embodiments, environment 900 may correspond to a 5G Non-Standalone (“NSA”) architecture, in which a 5G radio access technology (“RAT”) may be used in conjunction with one or more other RATs (e.g., a LTE RAT), and/or in which elements of a 5G core network may be implemented by, may be
{'bibliographic_information': "{'country': 'US', 'doc-number': '17100166', 'kind': 'B1', 'date': '20201120', 'invention_title': 'Systems and methods for application access control'}", 'source_file': './grant/2022/ipg220426.xml', 'source_data': 'USPTO-Grant'}