Managing hidden security features in user equipment

BACKGROUND

A push-to-talk (PTT) service provides direct one-to-one and/or one-to-many audio communication. PTT may include a mechanism that provides instantaneous communication between parties, and that utilizes a button to switch user equipment (UE) from a voice transmission mode to a voice reception mode. The operation of UEs in this manner may be similar to how walkie talkies operate. A PTT service may switch a UE from a full duplex mode, where both parties may hear each other simultaneously, to a half duplex mode, where a single party may speak at one time. Multiple parties to a conversation may also be included. Availabilities of parties may be checked before a call with the help of a presence function.

In the Third Generation Partnership Project (3GPP), the fourth generation (4G) cellular network includes an evolved packet system (EPS). The EPS may include a radio access network (e.g., referred to as a long term evolution (LTE) network), a wireless core network (e.g., referred to as an evolved packet core (EPC) network), an Internet protocol (IP) multimedia subsystem (IMS) network, and a packet data network (PDN). The LTE network is often called an evolved universal terrestrial radio access network (E-UTRAN). The EPC network is an all-IP packet-switched core network that supports high-speed wireless and wireline broadband access technologies. The EPC network allows UEs to access various services by connecting to the LTE network, an evolved high rate packet data (eHRPD) radio access network (RAN), and/or a wireless local area network (WLAN) RAN. The IMS network may include an architectural framework or network (e.g., a telecommunications network) for delivering IP multimedia services. The PDN may include a communications network that is based on packet switching.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> is a diagram of an overview of an example implementation described herein;

<figref idref="DRAWINGS">FIG. 2</figref> is a diagram of an example environment in which systems and/or methods described herein may be implemented;

<figref idref="DRAWINGS">FIG. 3</figref> is a diagram of example components of a device that may correspond to one or more of the devices of the environment depicted in <figref idref="DRAWINGS">FIG. 2</figref>;

<figref idref="DRAWINGS">FIG. 4</figref> is a flow chart of an example process for granting or denying access to exposed application programming interfaces (APIs);

<figref idref="DRAWINGS">FIGS. 5A-5C</figref> are diagrams of an example relating to the example process shown in <figref idref="DRAWINGS">FIG. 4</figref>;

<figref idref="DRAWINGS">FIG. 6</figref> is a flow chart of an example process for establishing and conducting a PTT session with another UE based on exposed APIs; and

<figref idref="DRAWINGS">FIGS. 7A-7H</figref> are diagrams of an example relating to the example process shown in <figref idref="DRAWINGS">FIG. 6</figref>.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.

Current 4G PTT applications use a public Internet connection with no quality of service (QoS) for PTT services. Without QoS, a user's PTT experience may degrade when a network or a UE is busy and PTT traffic is queued up behind other traffic (e.g., email, video, Internet, etc. traffic). The user experience may be exemplified in what is called a “push to hear” delay, which measures how quickly a user hears a beep after pushing the PTT button and how quickly the user's voice reaches a called party. Current 4G PTT applications have push to hear delays of approximately 1.5 to 2 seconds, which creates a poor user experience.

<figref idref="DRAWINGS">FIG. 1</figref> is a diagram of an overview of an example implementation 100 described herein. As shown, a user may be associated with a UE connected to an EPS that includes a RAN, an EPC network, an IMS network, and a PDN. The UE may include a PTT application that enables the user to establish and conduct a PTT call (or session) via the EPS. In order to enhance the PTT application to improve the PTT session, a manufacturer of the UE may expose one or more hidden or unexposed APIs. For example, the UE manufacturer may expose an IMS PDN API and a Discontinuous Receive (DRX) cycle API, as shown in <figref idref="DRAWINGS">FIG. 1</figref>. The IMS PDN API may enable the UE to establish data routes to the IMS network and the PDN. The DRX cycle API may enable the UE to modify a DRX cycle timer that dictates when the UE checks a network for traffic.

However, since the exposed APIs may affect battery life of the UE and may be susceptible to security threats, the UE may include a security application that restricts access to the exposed APIs, as further shown in <figref idref="DRAWINGS">FIG. 1</figref>. The security application may provide secure access to the IMS PDN API and the DRX cycle API by the PTT application, and may prevent unauthorized applications from accessing the IMS PDN API and the DRX cycle API.

For example, the security application may include authentication credentials (e.g., a signature, a security token, a security key, or the like) that may be utilized to authenticate applications attempting to access the IMS PDN API and/or the DRX cycle API. The security application may request that a particular application attempting to access the IMS PDN API and/or the DRX cycle API provide a credential. If the credential provided by the particular application matches the credential of the security application, the security application may authenticate the particular application for accessing the IMS PDN API and/or the DRX cycle API. When the PTT application is installed in the UE, the PTT application may be provided with a credential that matches the credential of the security application. Therefore, the security application may authenticate the PTT application for accessing the IMS PDN API and/or the DRX cycle API, as shown in <figref idref="DRAWINGS">FIG. 1</figref>. The security application may provide, to an operating system of the UE, a message indicating that the PTT application is authenticated for accessing the IMS PDN API and/or the DRX cycle API.

As further shown in <figref idref="DRAWINGS">FIG. 1</figref>, the PTT application may request access to the IMS PDN API, and the IMS PDN API may check with the operating system to determine whether the PTT application is authenticated. Since the PTT application is authenticated, the IMS PDN API may grant the PTT application access to the IMS PDN API. The PTT may utilize the IMS PDN API to establish a data connection (e.g., set up data routes) with the PDN over the IMS network. Unlike the public Internet, the IMS network may permit the UE to utilize quality of service (QoS) with respect to PTT sessions. In some implementations, the QoS may include prioritizing PTT traffic over other types of traffic, such as, for example, email, video, and Internet traffic. The QoS may improve a call setup time for establishing a PTT session, and may improve a latency time associated with the PTT session.

As further shown in <figref idref="DRAWINGS">FIG. 1</figref>, the PTT application may request access to the DRX cycle API, and the DRX cycle API may check with the operating system to determine whether the PTT application is authenticated. Since the PTT application is authenticated, the DRX cycle API may grant the PTT application access to the DRX cycle API. The PTT application may access the DRX cycle API in order to modify the DRX cycle timer provided in the DRX cycle API. In some implementations, the PTT application may decrease the DRX cycle timer so that the UE checks the EPS for traffic (e.g., PTT traffic) more frequently. This may enable the UE to more quickly receive PTT traffic from the EPS, such as an incoming PTT call, which may result in shorter call setup times (e.g., relative to public Internet-based PTT).

Such PTT enhancements may permit prioritization of PTT traffic over other types of traffic, such as email, video, Internet, etc. traffic. This may provide improved PTT call setup time and/or latency time over current 4G PTT implementations, which may improve the PTT user experience. For example, the PTT enhancements may provide push to hear delays of approximately less than one second.

Implementations of the security application are described herein with respect to a PTT application and to particular APIs exposed for the purpose of enhancing the PTT application. However, the security application may be utilized to provide secure access to one or more exposed APIs of the UE, other than the particular exposed APIs described herein (e.g., the IMS PDN API and the DRX cycle API). For example, the security application may be utilized to grant or deny the PTT application, and/or one or more other applications of the UE, access to any exposed API of the UE. Furthermore, although the PTT application is described herein in terms of PTT voice calls, the PTT application may alternatively or additionally be utilized for PTT video calls.

<figref idref="DRAWINGS">FIG. 2</figref> is a diagram of an example environment <b>200</b> in which systems and/or methods described herein may be implemented. As illustrated, environment <b>200</b> may include a UE <b>210</b> and an EPS <b>215</b> that includes a LTE network <b>220</b>, an EPC network <b>230</b>, an IMS network <b>240</b>, and a PDN <b>250</b>. LTE network <b>220</b> may include an eNodeB (eNB) <b>222</b>. EPC network <b>230</b> may include a mobility management entity (MME) <b>232</b>, a serving gateway (SGW) <b>234</b>, a policy and charging rules function (PCRF) <b>236</b>, and a PDN gateway (PGW) <b>238</b>. IMS network <b>240</b> may include a home subscriber server (HSS) <b>242</b> and a proxy call session control function (P-CSCF) <b>244</b>. Devices/networks of environment <b>200</b> may connect via wired connections, wireless connections, or a combination of wired and wireless connections.

As further shown in <figref idref="DRAWINGS">FIG. 2</figref>, eNB <b>222</b> may connect with MME <b>232</b> over a S1-MME interface, and may connect with SGW <b>234</b> over a S1-U interface. MME <b>232</b> may connect with SGW <b>234</b> over a S11 interface, and may connect with HSS <b>242</b> over a S6 a interface. SGW <b>234</b> may connect with PGW <b>238</b> over a S5 interface. PCRF <b>236</b> may connect with PGW <b>238</b> over a Gx interface. PGW <b>238</b> may connect with PDN <b>250</b> over a SGi interface, and may connect with P-CSCF <b>244</b>. Other connections, not shown in <figref idref="DRAWINGS">FIG. 2</figref>, may also be utilized by EPS <b>215</b>. For example, multiple MMEs <b>232</b> may connect with one another over S10 interfaces.

UE <b>210</b> may include a device that is capable of communicating over LTE network <b>220</b>, EPC network <b>230</b>, and/or IMS network <b>240</b>. In some implementations, UE <b>210</b> may include a radiotelephone; a PCS terminal that may combine, for example, a cellular radiotelephone with data processing and data communications capabilities; a smart phone; a PDA that can include a radiotelephone, a pager, Internet/intranet access, etc.; a laptop computer; a tablet computer; a desktop computer; a workstation computer; a personal computer; a landline telephone; or another type of computation and communication device.

EPS <b>215</b> may include is a core network architecture of the 3GPP LTE wireless communication standard. EPS <b>215</b> may include LTE network <b>220</b>, EPC network <b>230</b>, IMS network <b>240</b>, and PDN <b>250</b>.

LTE network <b>220</b> may include a communications network that connects users (e.g., UE <b>210</b>) to a service provider network. In some implementations, LTE network <b>220</b> may include a wireless local area network (WLAN) or another type of access network (e.g., an E-UTRAN or an eHRPD network). In some implementations, LTE network <b>220</b> may include a radio access network capable of providing a particular data rate, a particular latency, packet optimization, a particular capacity and coverage, etc.

eNB <b>222</b> may include one or more computation and communication devices, such as a base station, that receive traffic from MME <b>232</b> and/or SGW <b>234</b> and transmit that traffic to UE <b>210</b>. eNB <b>222</b> may also include one or more devices that receive traffic from UE <b>210</b> and transmit that traffic to MME <b>232</b> and/or SGW <b>234</b> or to other UEs <b>210</b>. eNB <b>222</b> may combine the functionalities of a base station and a radio network controller (RNC) in 2G or 3G radio access networks.

EPC network <b>230</b> may include an IP packet-switched core network that supports high-speed wireless and wireline broadband access technologies. In some implementations, EPC network <b>230</b> may provide packet-switched voice services (e.g., which are traditionally circuit-switched) using IMS network <b>240</b> and PDN <b>250</b>.

MME <b>232</b> may include one or more computation and communication devices that may be responsible for idle mode tracking and paging procedures (e.g., including retransmissions) for UE <b>210</b>. MME <b>232</b> may be involved in a bearer activation/deactivation process (e.g., for UE <b>210</b>) and may choose a SGW for UE <b>210</b> at an initial attach and at a time of intra-LTE handover. In some implementations, MME <b>232</b> may authenticate UE <b>210</b>. Non-access stratum (NAS) signaling may terminate at MME <b>232</b>, and MME <b>232</b> may generate and allocate temporary identities to UEs <b>210</b>. MME <b>232</b> may check authorization of UE <b>210</b> to utilize LTE network <b>220</b> and may enforce roaming restrictions for UE <b>210</b>. MME <b>232</b> may be a termination point in EPC network <b>230</b> for ciphering/integrity protection for NAS signaling and may handle security key management. MME <b>232</b> may provide a control plane function for mobility between LTE network <b>220</b> and other access networks with a S3 interface terminating at MME <b>232</b>.

SGW <b>234</b> may include one or more devices that route and forward user data packets, may act as a mobility anchor for a user plane during inter-eNB handovers, and may act as an anchor for mobility between LTE and other 3GPP technologies. For idle state UEs <b>210</b>, SGW <b>234</b> may terminate a downlink data path and may trigger paging when downlink data arrives for UE <b>210</b>. SGW <b>234</b> may manage and store contexts associated with UE <b>210</b> (e.g., parameters of an IP bearer service, network internal routing information, etc.). In some implementations, SGW <b>234</b> may include one or more traffic transfer devices (or network devices), such as a gateway, a router, a switch, a firewall, a network interface card (NIC), a hub, a bridge, a proxy server, an optical add-drop multiplexer (OADM), or some other type of device that processes and/or transfers traffic.

PCRF <b>236</b> may include one or more computation and communication devices that provide policy control decision and flow based charging control functionalities. PCRF <b>236</b> may provide network control regarding service data flow detection, gating, QoS and flow based charging, etc. In some implementations, PCRF <b>236</b> may determine how a certain service data flow shall be treated, and may ensure that user plane traffic mapping and treatment is in accordance with a user's subscription profile.

PGW <b>238</b> may include one or more devices that provide connectivity of UE <b>210</b> to external packet data networks by being a traffic exit/entry point for UE <b>210</b>. UE <b>210</b> may simultaneously connect to more than one PGW <b>238</b> for accessing multiple PDNs <b>250</b>. PGW <b>238</b> may perform policy enforcement, packet filtering for each user, charging support, lawful intercept, and packet screening. PGW <b>238</b> may also act as an anchor for mobility between 3GPP and non-3GPP technologies. In some implementations, PGW <b>238</b> may include one or more traffic transfer devices (or network devices), such as a gateway, a router, a switch, a firewall, a NIC, a hub, a bridge, a proxy server, an OADM, or some other type of device that processes and/or transfers traffic.

IMS network <b>240</b> may include an architectural framework or network (e.g., a telecommunications network) for delivering IP multimedia services. In some implementations, IMS network <b>240</b> may include a standardized reference architecture that provides session control, a connection control and an applications services framework, and user and services data.

HSS <b>242</b> may include one or more computation and communication devices that provide a master user database that supports devices of IMS network <b>240</b> that handle calls. HSS <b>242</b> may contain subscription-related information (e.g., user profiles), may perform authentication and authorization of a user, and may provide information about a user's location and IP information.

P-CSCF <b>244</b> may include one or more computation and communication devices that function as a proxy server for UE <b>210</b>, where SIP signaling traffic to and from UE <b>210</b> may go through P-CSCF <b>244</b>. In some implementations, P-CSCF <b>244</b> may validate and then forward requests from UE <b>210</b>, and may process and forward responses to UE <b>210</b>.

PDN <b>250</b> may include one or more data communications networks that are based on packet switching, as opposed to circuit switching that is used in public telephone networks. In some implementations, PDN <b>250</b> may be capable of communicating with UE <b>210</b> over IMS network <b>240</b>.

The number of devices and/or networks shown in <figref idref="DRAWINGS">FIG. 2</figref> is provided as an example. In practice, there may be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown in <figref idref="DRAWINGS">FIG. 2</figref>. Furthermore, two or more devices shown in <figref idref="DRAWINGS">FIG. 2</figref> may be implemented within a single device, or a single device shown in <figref idref="DRAWINGS">FIG. 2</figref> may be implemented as multiple, distributed devices. Additionally, one or more of the devices of environment <b>200</b> may perform one or more functions described as being performed by another one or more devices of environment <b>200</b>.

<figref idref="DRAWINGS">FIG. 3</figref> is a diagram of example components of a device <b>300</b> that may correspond to one or more of the devices of environment <b>200</b>. In some implementations, one or more of the devices of environment <b>200</b> may include one or more devices <b>300</b> or one or more components of device <b>300</b>. As shown in <figref idref="DRAWINGS">FIG. 3</figref>, device <b>300</b> may include a bus <b>310</b>, a processor <b>320</b>, a memory <b>330</b>, an input component <b>340</b>, an output component <b>350</b>, and a communication interface <b>360</b>.

Bus <b>310</b> may include a path that permits communication among the components of device <b>300</b>. Processor <b>320</b> may include a processor (e.g., a central processing unit, a graphics processing unit, an accelerated processing unit, etc.), a microprocessor, and/or any processing component (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.) that interprets and/or executes instructions, and/or that is designed to implement a particular function. In some implementations, processor <b>320</b> may include multiple processor cores for parallel computing. Memory <b>330</b> may include a random access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage component (e.g., a flash, magnetic, or optical memory) that stores information and/or instructions for use by processor <b>320</b>.

Input component <b>340</b> may include a component that permits a user to input information to device <b>300</b> (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, etc.). Output component <b>350</b> may include a component that outputs information from device <b>300</b> (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.).

Communication interface <b>360</b> may include a transceiver-like component, such as a transceiver and/or a separate receiver and transmitter, which enables device <b>300</b> to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. For example, communication interface <b>360</b> may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a high-definition multimedia interface (HDMI), or the like.

Device <b>300</b> may perform various operations described herein. Device <b>300</b> may perform these operations in response to processor <b>320</b> executing software instructions included in a computer-readable medium, such as memory <b>330</b>. A computer-readable medium may be defined as a non-transitory memory device. A memory device may include memory space within a single physical storage device or memory space spread across multiple physical storage devices.

Software instructions may be read into memory <b>330</b> from another computer-readable medium or from another device via communication interface <b>360</b>. When executed, software instructions stored in memory <b>330</b> may cause processor <b>320</b> to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

The number of components shown in <figref idref="DRAWINGS">FIG. 3</figref> is provided as an example. In practice, device <b>300</b> may include additional components, fewer components, different components, or differently arranged components than those shown in <figref idref="DRAWINGS">FIG. 3</figref>. Additionally, or alternatively, one or more components of device <b>300</b> may perform one or more functions described as being performed by another one or more components of device <b>300</b>.

<figref idref="DRAWINGS">FIG. 4</figref> is a flow chart of an example process <b>400</b> for granting or denying access to exposed APIs. In some implementations, one or more process blocks of <figref idref="DRAWINGS">FIG. 4</figref> may be performed by UE <b>210</b>. In some implementations, one or more process blocks of <figref idref="DRAWINGS">FIG. 4</figref> may be performed by another device or a group of devices separate from or including UE <b>210</b>.

As shown in <figref idref="DRAWINGS">FIG. 4</figref>, process <b>400</b> may include exposing an IMS PDN API and a DRX cycle API to a PTT application (block <b>410</b>). For example, UE <b>210</b> may include a PTT application that enables UE <b>210</b> to establish and conduct PTT sessions with other UEs <b>210</b>. In some implementations, UE <b>210</b> may include an IMS PDN API that enables UE <b>210</b> to establish a data connection with PDN <b>250</b> over IMS network <b>240</b>, as opposed to over the public Internet. For example, the IMS PDN API may enable the PTT application to make a data connection with PDN <b>250</b> over IMS network <b>240</b>. In some implementations, UE <b>210</b> may include several hidden or unexposed APIs that may not be viewed or altered by applications provided in UE <b>210</b>. However, the IMS PDN API may be exposed by UE <b>210</b> so that the PTT application may utilize the IMS PDN API to establish a data connection with PDN <b>250</b> over IMS network <b>240</b>.

In some implementations, UE <b>210</b> may include a DRX cycle API that controls a DRX cycle timer associated with UE <b>210</b>. The DRX cycle timer may include a timer that dictates when UE <b>210</b> checks a network for traffic (e.g., UE <b>210</b> may check a network for traffic after expiration of the DRX cycle timer). In some implementations, the DRX cycle API may be exposed by UE <b>210</b> so that the PTT application may modify the DRX cycle timer. For example, UE <b>210</b> may decrease the DRX cycle timer so that UE <b>210</b> checks EPS <b>215</b> for traffic (e.g., PTT traffic) more frequently. This may enable UE <b>210</b> to more quickly receive PTT traffic from EPS <b>215</b>.

As further shown in <figref idref="DRAWINGS">FIG. 4</figref>, process <b>400</b> may include receiving, by a security application, a credential from the PTT application (block <b>420</b>). For example, UE <b>210</b> may include a security application that provides secure access to exposed APIs in UE <b>210</b>. In some implementations, the security application may provide secure access to the IMS PDN API and the DRX cycle API by the PTT application. In some implementations, the security application may prevent unauthorized applications from accessing the IMS PDN API and the DRX cycle API.

For example, the security application may include authentication credentials (e.g., a certificate, a signature, an authentication key, a security token, etc.) that may be utilized to authenticate applications attempting to access the IMS PDN API and/or the DRX cycle API. The security application may request that a particular application attempting to access the IMS PDN API and/or the DRX cycle API provide authentication credentials.

In some implementations, the PTT application may be installed in UE <b>210</b> by a manufacturer of UE <b>210</b>, may be installed by a network service provider, or may be downloaded and installed in UE <b>210</b> by a user of UE <b>210</b>. When the PTT application is installed in UE <b>210</b>, the PTT application may be provided with authentication credentials (e.g., a signature), and may provide the authentication credentials to the security application. The security application may receive the authentication credentials (e.g., the signature).

As further shown in <figref idref="DRAWINGS">FIG. 4</figref>, process <b>400</b> may include determine whether the credential received from the PTT application matches a credential associated with the security application (block <b>430</b>). For example, the security application may determine whether the authentication credentials received from the PTT application match the authentication credentials of the security application. In some implementations, the authentication credentials of the security application may include a first signature associated with a first certificate, a first private signing key, and/or a first public verification key. The authentication credentials of the PTT application may include a second signature associated with a second certificate, a second private signing key, and/or a second public verification key. In such implementations, the security application may determine whether the first signature matches the second signature. For example, the security application may determine whether the first certificate matches the second certificate, whether the first private signing key matches the second private signing key, and/or whether the first public verification key matches the second public verification key.

As further shown in <figref idref="DRAWINGS">FIG. 4</figref>, if the credential received from the PTT application matches the credential associated with the security application (block <b>430</b>—YES), process <b>400</b> may include authenticating the PTT application for accessing the IMS PDN API and the DRX cycle API (block <b>440</b>). For example, if the authentication credentials provided by the PTT application match the authentication credentials of the security application, the security application may authenticate the PTT application for accessing the IMS PDN API and/or the DRX cycle API. In some implementations, when the PTT application is installed in UE <b>210</b>, the PTT application may be provided with authentication credentials that match the authentication credentials of the security application. Therefore, the security application may authenticate the PTT application for accessing the IMS PDN API and/or the DRX cycle API.

When the PTT application is authenticated for access to the IMS PDN API and the DRX cycle API, the PTT application may utilize and/or modify the IMS PDN API and the DRX cycle API. In some implementations, the PTT application may utilize the IMS PDN API to establish a data connection (e.g., set up data routes) with PDN <b>250</b> over IMS network <b>240</b>. The PTT application may utilize the data connection over IMS network <b>240</b> to implement a QoS framework for PTT traffic associated with the PTT application.

In some implementations, when the PTT application is installed in UE <b>210</b> or when UE <b>210</b> receives a tracking area update (TAU) (e.g., a TAU may be performed periodically or when UE <b>210</b> moves to another set of cells or tracking area) from EPS <b>215</b>, the PTT application may access the DRX cycle API in order to modify the DRX cycle API. For example, the PTT application may modify the DRX cycle timer provided in the DRX cycle API. In some implementations, the PTT application may decrease the DRX cycle timer so that UE <b>210</b> checks EPS <b>215</b> for traffic (e.g., PTT traffic) more frequently (e.g., every so many milliseconds, seconds, minutes, etc.). This may enable UE <b>210</b> to more quickly receive PTT traffic from EPS <b>215</b>, such as an incoming PTT call, which may result in shorter call setup times (e.g., relative to public Internet-based PTT).

In some implementations, the PTT application may restore the DRX cycle timer to a configurable default value based on particular conditions. For example, the PTT application may restore the DRX cycle timer to the default value when UE <b>210</b> is connected to an access network other than LTE network <b>220</b> (e.g., when UE <b>210</b> connects to a wireless LAN (WLAN)). In such an example, the PTT application may modify the DRX cycle timer again when UE <b>210</b> reconnects to LTE network <b>220</b>.

As further shown in <figref idref="DRAWINGS">FIG. 4</figref>, if the credential received from the PTT application does not match the credential associated with the security application (block <b>430</b>—NO), process <b>400</b> may include not authenticating the PTT application for accessing the IMS PDN API and the DRX cycle API (block <b>440</b>). For example, if the authentication credentials provided by the PTT application fail to match the authentication credentials of the security application, the security application may not authenticate the PTT application for accessing the IMS PDN API and/or the DRX cycle API and may generate an error (e.g., a security exception error). In some implementations, another application of UE <b>210</b> may maliciously or not maliciously attempt to access the IMS PDN API and/or the DRX cycle API. The other application may not be provided with a credential that matches the credential of the security application. Prior to attempting to access the IMS PDN API and/or the DRX cycle API, the other application may provide the non-matching credential to the security application, and the security application may not authenticate the other application for accessing the IMS PDN API and/or the DRX cycle API.

In some implementations, the security application may notify the operating system of UE <b>210</b> of the result of the authentications. For example, the security application may inform the operating system that the PTT application is authenticated for accessing the IMS PDN API and the DRX cycle API. In another example, the security application may inform the operating system that the other application is not authenticated for accessing the IMS PDN API and the DRX cycle API.

Although <figref idref="DRAWINGS">FIG. 4</figref> shows example blocks of process <b>400</b>, in some implementations, process <b>400</b> may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in <figref idref="DRAWINGS">FIG. 4</figref>. Additionally, or alternatively, two or more of the blocks of process <b>400</b> may be performed in parallel.

<figref idref="DRAWINGS">FIGS. 5A-5C</figref> are diagrams of an example <b>500</b> relating to example process <b>400</b> shown in <figref idref="DRAWINGS">FIG. 4</figref>. In example <b>500</b>, assume that UE <b>210</b> includes unexposed APIs <b>505</b> that are hidden from a user of UE <b>210</b> and/or applications executing on UE <b>210</b>, as shown in <figref idref="DRAWINGS">FIG. 5A</figref>. Unexposed APIs <b>505</b> may include an IMS PDN API <b>510</b> that enables UE <b>210</b> to establish a data connection with PDN <b>250</b> over IMS network <b>240</b>, and a DRX cycle API <b>515</b> that controls a DRX cycle timer associated with UE <b>210</b>. As further shown in <figref idref="DRAWINGS">FIG. 5A</figref>, IMS PDN API <b>510</b> and DRX cycle API <b>515</b> may be exposed to a PTT application <b>520</b> that enables UE <b>210</b> to establish and conduct PTT sessions with other UEs <b>210</b>. IMS PDN API <b>510</b> and DRX cycle API <b>515</b> may be exposed to PTT application <b>520</b> so that PTT application <b>520</b> may utilize and/or modify IMS PDN API <b>510</b> and/or DRX cycle API <b>515</b>.

As shown in <figref idref="DRAWINGS">FIG. 5B</figref>, UE <b>210</b> may include a security application <b>525</b> that determines whether an application is authenticated for accessing IMS PDN API <b>510</b> and/or DRX cycle API <b>515</b>. Security application <b>525</b> may include a credential <b>530</b> that is utilized to authenticate applications attempting to access IMS PDN API <b>510</b> and/or DRX cycle API <b>515</b>. As further shown in <figref idref="DRAWINGS">FIG. 5B</figref>, PTT application <b>520</b> may provide a credential <b>535</b> to security application <b>525</b>. Assume that security application <b>525</b> determines that credential <b>535</b> provided by PTT application <b>520</b> matches credential <b>530</b> of security application <b>525</b>. Accordingly, security application <b>525</b> may determine that PTT application <b>520</b> is authenticated for accessing IMS PDN API <b>510</b> and/or DRX cycle API <b>515</b>, as indicated by reference number <b>540</b>, and may provide this information to an operating system of UE <b>210</b>.

As further shown in <figref idref="DRAWINGS">FIG. 5B</figref>, PTT application <b>520</b> may provide an access request <b>545</b> to IMS PDN API <b>510</b>, and IMS PDN API <b>510</b> may check <b>550</b>, based on access request <b>545</b>, with the operating system to determine whether PTT application <b>520</b> is authenticated for accessing IMS PDN API <b>510</b>. Since PTT application <b>520</b> is authenticated, PTT application <b>520</b> may be granted access to IMS PDN API <b>510</b>, as indicated by reference number <b>555</b>. PTT application <b>520</b> may provide an access request <b>560</b> to DRX cycle API <b>515</b>, and DRX cycle API <b>515</b> may check <b>565</b>, based on access request <b>560</b>, with the operating system to determine whether PTT application <b>520</b> is authenticated for accessing DRX cycle API <b>515</b>. Since PTT application <b>520</b> is authenticated, PTT application <b>520</b> may be granted access to DRX cycle API <b>515</b>, as indicated by reference number <b>570</b>.

As shown in <figref idref="DRAWINGS">FIG. 5C</figref>, another application of UE <b>210</b> may provide a credential <b>575</b> to security application <b>525</b>. Assume that security application <b>525</b> determines that credential <b>575</b> provided by the other application does not match credential <b>530</b> of security application <b>525</b>. Accordingly, security application <b>525</b> may determine that the other application is not authenticated for accessing IMS PDN API <b>510</b> and/or DRX cycle API <b>515</b>, as indicated by reference number <b>580</b>, and may provide this information to the operating system.

As further shown in <figref idref="DRAWINGS">FIG. 5C</figref>, the other application may provide an access request <b>585</b> to IMS PDN API <b>510</b> and/or DRX cycle API <b>515</b>. IMS PDN API <b>510</b> and/or DRX cycle API <b>515</b> may check <b>590</b>, based on access request <b>585</b>, with the operating system to determine whether the other application is authenticated for accessing IMS PDN API <b>510</b> and/or DRX cycle API <b>515</b>. Since the other application is not authenticated, the other application may be denied access to IMS PDN API <b>510</b> and/or DRX cycle API <b>515</b>, as indicated by reference number <b>595</b>.

As indicated above, <figref idref="DRAWINGS">FIGS. 5A-5C</figref> are provided merely as an example. Other examples are possible and may differ from what was described with regard to <figref idref="DRAWINGS">FIGS. 5A-5C</figref>.

<figref idref="DRAWINGS">FIG. 6</figref> is a flow chart of an example process <b>600</b> for establishing and conducting a PTT session with another UE based on exposed APIs. In some implementations, one or more process blocks of <figref idref="DRAWINGS">FIG. 6</figref> may be performed by UE <b>210</b>. In some implementations, one or more process blocks of <figref idref="DRAWINGS">FIG. 6</figref> may be performed by another device or a group of devices separate from or including UE <b>210</b>.

As shown in <figref idref="DRAWINGS">FIG. 6</figref>, process <b>600</b> may include modifying a DRX cycle timer with a PTT application and via a DRX cycle API (block <b>610</b>). For example, the PTT application of UE <b>210</b> may access the DRX cycle API, and may modify the DRX cycle timer provided in the DRX cycle API. In some implementations, the security application may provide secure access to the DRX cycle API by the PTT application. In some implementations, the PTT application may decrease the DRX cycle timer so that UE <b>210</b> checks EPS <b>215</b> for traffic (e.g., PTT traffic) more frequently. This may enable UE <b>210</b> to more quickly receive PTT traffic from EPS <b>215</b>, such as an incoming PTT call, which may result in shorter call setup times (e.g., relative public Internet-based PTT).

As further shown in <figref idref="DRAWINGS">FIG. 6</figref>, process <b>600</b> may include establishing, via an IMS PDN API and the PTT application, data routes with a network (block <b>620</b>). For example, the PTT application of UE <b>210</b> may access the IMS PDN API, and may utilize the IMS PDN API. In some implementations, the security application may provide secure access to the IMS PDN API by the PTT application. In some implementations, the PTT application may utilize the IMS PDN API to establish a data connection (e.g., set up data routes) with PDN <b>250</b> over IMS network <b>240</b>. Unlike the public Internet, IMS network <b>240</b> may permit UE <b>210</b> to utilize QoS with respect to PTT sessions. The QoS may improve a call setup time for establishing a PTT session, and may improve a latency time associated with the PTT session.

As further shown in <figref idref="DRAWINGS">FIG. 6</figref>, process <b>600</b> may include establishing a QoS framework with the network for prioritizing PTT traffic (block <b>630</b>). For example, UE <b>210</b> may connect to PDN <b>250</b> over IMS network <b>240</b> and via LTE network <b>220</b> and EPC network <b>230</b>. In some implementations, the PTT application of UE <b>210</b> may establish a QoS framework with EPS <b>215</b> (e.g., with IMS network <b>240</b>) that prioritizes PTT traffic associated with the PTT application. For example, the PTT application may prioritize PTT traffic over best effort traffic (e.g., email traffic, video traffic, Internet traffic, etc.), as the PTT traffic traverses IMS network <b>240</b> and PDN <b>250</b>.

In some implementations, since the IMS PDN API may permit the PTT application to establish a data connection with PDN <b>250</b> over IMS network <b>240</b>, the PTT application may utilize the data connection over IMS network <b>240</b> to implement a QoS framework for PTT traffic associated with the PTT application. In some implementations, QoS bearers may be defined in IMS network <b>240</b> and may be set up statically when UE <b>210</b> registers with IMS network <b>240</b>. In some implementations, the QoS bearers may be set up dynamically when UE <b>210</b> utilizes the PTT application to make a PTT call.

In some implementations, the PTT traffic may be prioritized after guaranteed bit rate (GBR) conversational audio (e.g., voice-over-IP (VoIP) traffic); before non-GBR variable bit rate video traffic; before non-GBR standard video telephony, video streaming, and general best effort traffic; and before non-GBR machine-to-machine (M2M) traffic. By prioritizing the PTT traffic over the non-GBR traffic, the PTT application may reduce latency times associated with PTT sessions.

As further shown in <figref idref="DRAWINGS">FIG. 6</figref>, process <b>600</b> may include utilizing the PTT application and the modified DRX cycle timer to establish a PTT session with a UE (block <b>640</b>). For example, UE <b>210</b> may utilize the modified DRX cycle timer to check EPS <b>215</b> for traffic, such as a PTT call from another UE <b>210</b>. When UE <b>210</b> receives the PTT call from the other UE <b>210</b>, and UE <b>210</b> may execute the PTT application based on receiving the PTT call. Based on the PTT call, the PTT application may display information indicating that the other UE <b>210</b> is trying to establish a PTT session with UE <b>210</b>. If the user accepts the PTT call, a PTT session may be established between UE <b>210</b> and the other UE <b>210</b>. If the user does not accept the PTT call, a PTT session may not be established between UE <b>210</b> and the other UE <b>210</b>.

In some implementations, the user may instruct UE <b>210</b> to execute the PTT application, and the user may utilize the PTT application to establish a PTT session with the other UE <b>210</b>. In some implementations, the PTT application may display a list of available PTT contacts associated with the user, and the user may select a PTT contact associated with the other UE <b>210</b> from the list. When the user selects the PTT contact, the PTT application may cause UE <b>210</b> to generate a PTT call destined for the other UE <b>210</b>. In some implementations, UE <b>210</b> may provide the PTT call to the other UE <b>210</b> via EPS <b>215</b>. If the PTT contact accepts the PTT call, a PTT session may be established between UE <b>210</b> and the other UE <b>210</b>. If the PTT contact does not accept the PTT call, a PTT session may not be established between UE <b>210</b> and the other UE <b>210</b>.

As further shown in <figref idref="DRAWINGS">FIG. 6</figref>, process <b>600</b> may include prioritizing the PTT traffic during the PTT session based on the QoS framework (block <b>650</b>). For example, during the PTT session, UE <b>210</b> may prioritize the PTT traffic over best effort traffic based on the QoS framework established with EPS <b>215</b>. In some implementations, during the PTT session, the other UE <b>210</b> may also prioritize the PTT traffic over any best effort traffic associated with the other UE <b>210</b>, based on the QoS framework established with EPS <b>215</b>. In some implementations, the PTT traffic, in the PTT session with the other UE <b>210</b>, may be prioritized before non-GBR traffic, such as, for example, variable bit rate video traffic, standard video telephony traffic, video streaming traffic, general best effort traffic, and M2M traffic. By prioritizing the PTT traffic over the non-GBR traffic, the PTT application may reduce latency times associated with PTT session with the other UE <b>210</b>.

In some implementations, the combination of the reduced DRX cycle timer, the QoS framework for PTT traffic, and other enhancements (e.g., frame bundling of PTT traffic) may provide improved PTT call setup time and/or latency time over current 4G PTT implementations, which may improve the PTT user experience for the users of UE <b>210</b> and the other UE <b>210</b>. For example, the combination may enable the user of UE <b>210</b> to experience push to hear delays of approximately less than one second during the PTT session with the other UE <b>210</b>. In some implementations, the combination may enable the user of the other UE <b>210</b> to experience push to hear delays of approximately less than one second during the PTT session with UE <b>210</b>.

As further shown in <figref idref="DRAWINGS">FIG. 6</figref>, process <b>600</b> may include determining whether the PTT application is uninstalled (block <b>660</b>). For example, the security application may determine whether the PTT application is uninstalled (or removed) from UE <b>210</b>. In some implementations, the user of UE <b>210</b> may utilize an uninstall function of UE <b>210</b> to request that the PTT application be uninstalled. The uninstall function, when implemented by the user, may perform operations to uninstall the PTT application from UE <b>210</b>. In some implementations, the operating system of UE <b>210</b> may notify the security application about any applications that are uninstalled from UE <b>210</b>, including the PTT application.

As further shown in <figref idref="DRAWINGS">FIG. 6</figref>, if the PTT application is not uninstalled (block <b>660</b>—NO), process <b>600</b> may include ending the PTT session with the UE (block <b>670</b>). For example, if the security application determines that the PTT application is not uninstalled, UE <b>210</b> may continue to use the PTT application. In some implementations, the user of UE <b>210</b> may eventually end the PTT session with the other UE <b>210</b> by selecting a mechanism (e.g., an end call button, icon, link, etc.) displayed by the PTT application during the PTT session. In some implementations, when the user of UE <b>210</b> selects the end call mechanism, UE <b>210</b> may terminate the PTT session with the other UE <b>210</b>, and may display information associated with the PTT application to the user. In some implementations, UE <b>210</b> may display other information (e.g., data associated with best effort traffic, a home page, etc.) to the user when the PTT session is terminated. In some implementations, the user of the other UE <b>210</b> may end the PTT session with UE <b>210</b>.

As further shown in <figref idref="DRAWINGS">FIG. 6</figref>, if the PTT application is uninstalled (block <b>660</b>—YES), process <b>600</b> may include utilizing the IMS PDN API to remove the data routes with the network (block <b>680</b>). For example, if the security application determines that the PTT application is uninstalled from UE <b>210</b>, or if the PTT application is turned off or disabled (e.g., by the user), the security application may utilize the IMS PDN API to remove any data routes set up by the PTT application via the IMS PDN API. In some implementations, the security application may utilize the IMS PDN API to remove any data connections (e.g., data routes) established with PDN <b>250</b> over IMS network <b>240</b>. In some implementations, if the PTT application is turned on or enabled (e.g., by the user), the PTT application may utilize the IMS PDN API to establish another data connection (e.g., set up data routes) with PDN <b>250</b> over IMS network <b>240</b>.

As further shown in <figref idref="DRAWINGS">FIG. 6</figref>, if the PTT application is uninstalled (block <b>660</b>—YES), process <b>600</b> may include utilizing the DRX cycle API to reset the DRX cycle timer to a default value (block <b>690</b>). For example, if the security application determines that the PTT application is uninstalled from UE <b>210</b>, the security application may utilize the DRX cycle API to reset the DRX cycle timer to a default value. In some implementations, the security application may reset the DRX cycle timer to a configurable default value that may reduce battery usage in UE <b>210</b>. For example, the default value of the DRX cycle timer may include a value that causes UE <b>210</b> to check EPS <b>215</b> for traffic less frequently, which may conserve battery usage in UE <b>210</b>.

In some implementations, if the PTT application is removed or uninstalled from UE <b>210</b>, or if the PTT application is turned off or disabled (e.g., by the user), the security application may reset the DRX cycle timer to a configurable default value that may reduce battery usage in UE <b>210</b>. For example, the default value of the DRX cycle timer may include a value that causes UE <b>210</b> to check EPS <b>215</b> for traffic less frequently, which may conserve battery usage in UE <b>210</b>. In some implementations, the security application may read a default DRX value that is being broadcasted by EPS <b>215</b>, and may use the default DRX value to change the DRX cycle timer of UE <b>210</b> to the default value. This may reset the DRX cycle timer of UE <b>210</b> to a default value which EPS <b>215</b> wants devices to use (e.g., when using the default value). In some implementations, if the PTT application is turned on or enabled (e.g., by the user), the PTT application may decrease the DRX cycle timer so that UE <b>210</b> checks EPS <b>215</b> for traffic (e.g., PTT traffic) more frequently (e.g., every so many milliseconds, seconds, minutes, etc.).

Although <figref idref="DRAWINGS">FIG. 6</figref> shows example blocks of process <b>600</b>, in some implementations, process <b>600</b> may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in <figref idref="DRAWINGS">FIG. 6</figref>. Additionally, or alternatively, two or more of the blocks of process <b>600</b> may be performed in parallel.

<figref idref="DRAWINGS">FIGS. 7A-7H</figref> are diagrams of an example <b>700</b> relating to example process <b>600</b> shown in <figref idref="DRAWINGS">FIG. 6</figref>. As shown in <figref idref="DRAWINGS">FIG. 7A</figref>, assume that a user is associated with UE <b>210</b> (e.g., a smart phone <b>210</b>), and that smart phone <b>210</b> includes IMS PDN API <b>510</b>, DRX cycle API <b>515</b>, and PTT application <b>520</b>. As further shown in <figref idref="DRAWINGS">FIG. 7A</figref>, PTT application <b>520</b> may access DRX cycle API <b>515</b>, and may instruct DRX cycle API <b>515</b> to modify the DRX cycle timer. DRX cycle API <b>515</b> may modify the DRX cycle timer based the instruction, and UE <b>210</b> may utilize modified DRX cycle timer <b>705</b> to check EPS <b>215</b> for traffic. Assume that modified DRX cycle timer <b>705</b> causes smart phone <b>210</b> to check EPS <b>215</b> for information more frequently than before the DRX cycle timer was modified. PTT application <b>520</b> may access IMS PDN API <b>510</b>, and may instruct IMS PDN API <b>510</b> to establish data routes in EPS <b>215</b>. IMS PDN API <b>510</b> may establish data routes with IMS network <b>240</b> and PDN <b>250</b> based on the instruction, as indicated by reference number <b>710</b>. As further shown in <figref idref="DRAWINGS">FIG. 7A</figref>, PTT application <b>520</b> may determine, with EPS <b>215</b>, a QoS framework <b>715</b> that prioritizes PTT traffic.

As shown in <figref idref="DRAWINGS">FIG. 7B</figref>, while the user is creating an email message, smart phone <b>210</b> may check EPS <b>215</b> for information (e.g., received calls, traffic, etc.) based on a modified DRX cycle timer <b>705</b>, as indicated by reference number <b>720</b>. As further shown in <figref idref="DRAWINGS">FIG. 7B</figref>, a coworker of the user may be associated with a tablet computer <b>210</b>, and may utilize tablet computer <b>210</b> to access a PTT application provided in tablet computer <b>210</b>. Assume that the coworker utilizes the PTT application to generate a request <b>725</b> for a PTT session with the user and smart phone <b>210</b>. Tablet computer <b>210</b> may provide request <b>725</b> for the PTT session to EPS <b>215</b>, and EPS <b>215</b> may forward request <b>725</b> toward smart phone <b>210</b> utilizing the QoS framework.

When request <b>725</b> is received by smart phone <b>210</b>, smart phone <b>210</b> may execute a PTT application provided in smart phone <b>210</b> and may stop displaying email message <b>715</b>. The PTT application may cause smart phone <b>210</b> to display information associated with request <b>725</b>, such as the coworker's name, the coworker's picture, a mechanism to accept or deny request <b>725</b>, etc. Assume that the user utilizes the displayed information to accept request <b>725</b>, and establish a PTT session with tablet computer <b>210</b> and the coworker, as indicated by reference number <b>730</b> in <figref idref="DRAWINGS">FIG. 7C</figref>. When the PTT session is established, the PTT application may cause smart phone <b>210</b> to display a user interface <b>735</b> that includes a picture of coworker, a PTT button, and an end call button. As further shown in <figref idref="DRAWINGS">FIG. 7C</figref>, the PTT application of smart phone <b>210</b> may prioritize PTT traffic associated with the PTT session, as indicated by reference number <b>740</b>.

As shown in <figref idref="DRAWINGS">FIG. 7D</figref>, assume that the user selects <b>745</b> the PTT button and begins talking to smart phone <b>210</b>, as indicated by reference number <b>750</b>. The user's spoken voice may be provided by smart phone <b>210</b> to tablet computer <b>210</b> (e.g., via EPS <b>215</b>), and may be heard by the coworker via tablet computer <b>210</b>, as indicated by reference number <b>755</b>. As further shown in <figref idref="DRAWINGS">FIG. 7D</figref>, a delay time between when the user speaks and when the coworker hears the user's voice may be approximately less than one second, as indicated by reference number <b>760</b>.

As shown in <figref idref="DRAWINGS">FIG. 7E</figref>, assume that the coworker selects <b>765</b> the PTT button and begins talking to tablet computer <b>210</b>, as indicated by reference number <b>770</b>. The coworker's spoken voice may be provided by tablet computer <b>210</b> to smart phone <b>210</b> (e.g., via EPS <b>215</b>), and may be heard by the user via smart phone <b>210</b>, as indicated by reference number <b>775</b>. As further shown in <figref idref="DRAWINGS">FIG. 7E</figref>, a delay time between when the coworker speaks and when the user hears the coworker's voice may be approximately less than one second, as indicated by reference number <b>780</b>.

Either the user or the coworker may end the PTT session by selecting the end call button. When the end call button is selected, smart phone <b>210</b> and tablet computer <b>210</b> may end the PTT session, as indicated by reference number <b>785</b> in <figref idref="DRAWINGS">FIG. 7F</figref>. As further shown, after the PTT session ends, smart phone <b>210</b> may resume displaying email message <b>715</b> to the user, and tablet computer <b>210</b> may display a home page or some other information to the coworker.

Now assume that the user utilizes an uninstall function of smart phone <b>210</b> to request that PTT application <b>520</b> be uninstalled from smart phone <b>210</b>. When the uninstall function is invoked, smart phone <b>210</b> may display a user interface <b>590</b> to the user, as shown in <figref idref="DRAWINGS">FIG. 7G</figref>. User interface <b>790</b> may ask whether the user wants to uninstall PTT application <b>520</b>. Assume that the user selects a Yes button of user interface <b>590</b> to indicate that the user wants to uninstall PTT application <b>520</b>. When the user selects the Yes button, smart phone <b>210</b> may uninstall PTT application <b>520</b> from smart phone <b>210</b>.

After smart phone <b>210</b> uninstalls PTT application <b>520</b>, security application <b>525</b> may receive (e.g., from the operating system of smart phone <b>210</b>) a notification indicating that PTT application <b>520</b> has been uninstalled from smart phone <b>210</b>. Based on the notification, security application <b>525</b> may instruct DRX cycle API <b>515</b> to reset the DRX cycle timer, as indicated by reference number <b>795</b> in <figref idref="DRAWINGS">FIG. 7H</figref>, and DRX cycle API <b>514</b> may reset the DRX cycle timer to a default value. Based on the notification, security application <b>525</b> may instruct IMS PDN API <b>510</b> to remove data routes established in EPS <b>215</b>, as indicated by reference number <b>797</b> in <figref idref="DRAWINGS">FIG. 7H</figref>, and IMS PDN API <b>510</b> may remove any data routes established with IMS network <b>240</b> and PDN <b>250</b>.

As indicated above, <figref idref="DRAWINGS">FIGS. 7A-7H</figref> are provided merely as an example. Other examples are possible and may differ from what was described with regard to <figref idref="DRAWINGS">FIGS. 7A-7H</figref>.

To the extent the aforementioned implementations collect, store, or employ personal information provided by individuals, it should be understood that such information shall be used in accordance with all applicable laws concerning protection of personal information. Storage and use of personal information may be in an appropriately secure manner reflective of the type of information, for example, through various encryption and anonymization techniques for particularly sensitive information.

The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

A component is intended to be broadly construed as hardware, firmware, or a combination of hardware and software.

It will be apparent that systems and/or methods, as described herein, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these systems and/or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and/or methods were described without reference to the specific software code—it being understood that software and control hardware can be designed to implement the systems and/or methods based on the description herein.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of possible implementations includes each dependent claim in combination with every other claim in the claim set.

No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Furthermore, as used herein, the term “set” is intended to include one or more items, and may be used interchangeably with “one or more.” Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.