US20210337386A1 - Validating authorization for use of a set of features of a device - Google Patents

Abstract

A device obtains proof of its authority to use a first set of selectively activated features (first proof). An authorization server signs the first proof with its private key. The device sends a request to use a network service to a network node. The device sends the first proof to the network node. The network node validates the first proof using a public key of the authorization server. The network node grants the request to use the network service. The device sends a request for proof of authority for the network node to provide the network service (second proof). The device obtains the second proof, signed by another authorization server, and validates the second proof before using the network service. The first proof and the second proof each include a list of selectively activated features, where the selectively activated features are needed to use or provide the network service.

Description

PRIORITY CLAIM
• This application is a continuation of U.S. patent application Ser. No. 15/082,919 titled “Validating The Authorization For Use Of A Set Of One Or More Features Of A Device” filed on Mar. 28, 2016 in the United States Patent and Trademark Office, which claims priority to U.S. Provisional Application No. 62/202,664 titled “Validating The Authorization For Use Of A Set Of One Or More Features Of A Device” filed on Aug. 7, 2015 in the United States Patent and Trademark Office. All of said applications are each incorporated herein by reference as if fully set forth below in their entireties and for all applicable purposes.
FIELD
• The present application relates to validation of an authorization, received by a device, to activate a set of features that may be selectively activated and thereby initiate or maintain a service between the device and an entity validating the authorization.
BACKGROUND
• Most communication devices (e.g., chip components, client devices, network nodes) offer multiple features. The features may be implemented in hardware and/or software.
• Some features of a communication device may be activated, when an entity obtains the communication device. Other features may not be activated. For example, it may be possible for a manufacturer, subcomponent manufacturer, or original equipment manufacturer (OEM) to produce different models (e.g., versions) of a communication device that has one or more features included in the communication device, where the one or more features are activated or deactivated based on the device model. Consequently, a subset (e.g., less than an entire set) of the features of the communication device may be operative in a final product. For example, a manufacturer may activate a feature in a first model but not activate the feature in a second model, even though both models include all hardware and software used to implement the feature. Additionally or alternatively, portions of processing circuit readable instructions stored on the communication device may not be executed to preclude a feature from activation. Enabling and/or disabling hardware and/or software increases and/or decreases a number of features that are activated in a final product and may, for example, affect the price of the final product.
• Accordingly, when a communication device is deployed, the communication device may be capable (e.g., in terms of hardware and/or software or firmware) of performing certain features as a part of its operation but may not be authorized to use the certain features. Limits on authority to use the features may be based, for example, on a purchase agreement that limits uses of features and/or services available to the communication device.
SUMMARY
• The aspects disclosed herein provide methods and apparatus for dynamically validating the authorization for use of a set of one or more features of an electronic device.
• In some aspects, a method may include obtaining a proof of authority for a device to use a first set of selectively activated features at the device. The proof of authority for the device can be signed by a first authorization server. The method can include sending a request to use a network service to a network node, wherein the first set of selectively activated features includes first selectively activated features needed by the device to use the network service. The device may obtain, from the network node, in response to sending the request to use the network service, a request for the proof of authority for the device. The device may send to the network node, the proof of authority for the device and a request for proof of authority for the network node to provide the network service. The device may obtain, from the network node, the proof of authority for the network node to use a second set of selectively activated features at the network node, signed by a second authorization server, wherein the second set of selectively activated features includes second selectively activated features needed by the network node to provide the network service. The method may also include validating the proof of authority for the network node before using the network service.
• In some examples, the device can be a chip component, a client device, a network access node, a mobility management entity, or a gateway device. In one example, the device can be a client device or a chip component, and the network node can be a network access node.
• In an aspect, the proof of authority for the device can originate at the first authorization server, can be signed with a private key of the first authorization server, and can include a listing of the first selectively activated features. The method may further include validating the proof of authority for the device by validating the listing of the first selectively activated features using a public key of the first authorization server. The method may still further include obtaining feature activation keys associated with the first selectively activated features, encrypted with a public key of the device, decrypting the feature activation keys, using a private key of the device, known only to the device, and activating and/or maintaining activation of the first selectively activated features with the feature activation keys.
• In an example where the proof of authority for the network node originates at the second authorization server, is signed with a private key of the second authorization server, and includes a listing of the second selectively activated features, the method may further include validating the proof of authority for the network node by validating the listing of the second selectively activated features using a public key of the second authorization server.
• In an aspect, the first authorization server can be a local authorization server.
• In another aspect, the method may further include identifying a third set of selectively activated features needed by the network node to use the network service, and using the network service based on determining whether the third set of selectively activated features is included in the second set of selectively activated features.
• In an implementation, the proof of authority for the device originates at the first authorization server and is obtained, at the device, from the first authorization server, and the proof of authority for the network node originates at the second authorization server and is obtained, at the device, from the network node. In an aspect, the first authorization server and the second authorization server can be one authorization server.
• In some aspects, the proof of authority for the device is obtained from the first authorization server during a feature activation process, during which the device obtains authorization to activate the first selectively activated features. In some aspects, the proof of authority for the device can be data representative of an authorization certificate. In other aspects, the proof of authority for the device can be data representative of an authorization agreement indicating that the device is authorized to activate the first selectively activated features.
• In one example, a device includes a network communication circuit and a processing circuit coupled to the network communication circuit. The processing circuit may be configured to perform the above-described method(s).
• In another aspect, a method, operational at a network node, may include obtaining a request, from a device, to use a network service. The method may include obtaining proof of authority for the device to use a first set of selectively activated features at the device. The proof of authority for the device can be signed by an authorization server. The method may also include validating the proof of authority for the device. The method may further include identifying a second set of selectively activated features needed by the device to use the network service, and sending a response to the request based on results of validating the proof of authority for the device and determining whether the second set of selectively activated features is included in the first set of selectively activated features. In some aspects, the network node can be a network access node, a mobility management entity, or a gateway device.
• In an example, the first set of selectively activated features includes first selectively activated features, and the proof of authority for the device originates at the authorization server. The proof of authority for the device can include a listing of the first selectively activated features, signed with a private key of the authorization server. The method can further include validating the proof of authority for the device by validating the listing of the first selectively activated features using a public key of the authorization server.
• In an aspect, the proof of authority for the device can originate at the authorization server and can be obtained, at the network node, from the device. In another aspect, the proof of authority for the device can originate at the authorization server and can be obtained, at the network node, in a form of a capability profile of the device, from a home subscriber server (HSS).
• In an implementation, the proof of authority for the device can be data representative of an authorization certificate. In another implementation, the proof of authority for the device can be data representative of an authorization agreement indicating that the device is authorized to activate the first set of selectively activated features.
• In an aspect, identifying the second set of selectively activated features can include deriving selectively activated features needed by the device to use the network service from a model-specific and/or a device-specific list of authorized selectively activated features maintained by the authorization server. In another aspect, identifying the second set of selectively activated features can include deriving selectively activated features needed by the device to use the network service from a model-specific and/or a device-specific list of licensable selectively activated features maintained by the authorization server.
• In an implementation, the method may include verifying that the device holds a private key that corresponds to a public key of the device included with the proof of authority for the device, wherein sending the response to the request is further based on a result of the verifying.
• In an aspect, a network node can include a network communication circuit and a processing circuit coupled to the network communication circuit. The processing circuit may be configured to perform the above-described method(s).
• In an aspect, a method operational at a server, may include obtaining a first list of selectively activated features of a device, and updating a second list of selectively activated features of the device, stored at the server, based on the first list, wherein the second list is associated with a subscription profile of the device, to reflect a change to an authorization status of at least one selectively activated feature in the second list.
• In an example, the server can be a home subscriber server (HSS).
• In an implementation, the method can further include sending, responsive to a query concerning capability of the device, a capability profile including the second list of selectively activated features of the device.
• In an aspect, when the first list of selectively activated features originates at an authorization server and is signed with a private key of the authorization server, the method may further include validating the first list of selectively activated features using a public key of the authorization server.
• In an aspect, the authorization server can be a local authorization server.
• In an aspect, the first list of selectively activated features can be data representative of an authorization certificate signed by an authorization server. In another aspect, the first list of selectively activated features can be data representative of an authorization agreement indicating that the device is authorized to activate the selectively activated features.
• In an aspect, a server (e.g., an HSS) can include a network communication circuit for communicating over a network and a processing circuit coupled to the network communication circuit. The processing circuit may be configured to perform the above-described method(s).
DRAWINGS
• FIG. 1 is a block diagram of an exemplary system that may dynamically authorize and activate one or more selectively activated features on a set of one or more devices according to aspects described herein.
• FIG. 2 illustrates an exemplary operating environment according to aspects described herein.
• FIG. 3 is an architecture reference model of a system according to aspects described herein.
• FIG. 4 illustrates an exemplary list of parameters and data that may be included in an exemplary authorization agreement between a first entity and a manufacturer or OEM of one or more devices in accordance with aspects described herein.
• FIG. 5 illustrates an exemplary list of parameters and data that may be included in an exemplary authorization agreement between a manufacturer or OEM and another entity in accordance with aspects described herein.
• FIG. 6 illustrates an exemplary list of parameters and data that may be included in an exemplary authorization agreement between a network operator and another entity in accordance with aspects described herein.
• FIG. 7 is a flow diagram illustrating actions related to sending of authorization certificates, authorization files, feature activation keys, and software to devices in accordance with aspects described herein.
• FIG. 8 is a flow diagram illustrating a method involving a feature activation request in accordance with aspects described herein.
• FIG. 9 is a flow diagram illustrating one example of activation of selectively activated features in accordance with aspects described herein.
• FIG. 10 is a block diagram illustrating an authorization server configured to support dynamic verification and enforcement of authorization agreements in accordance with aspects described herein.
• FIG. 11 is a block diagram illustrating a local authorization server configured to support dynamic verification and enforcement of authorization agreements in accordance with aspects described herein.
• FIG. 12 is a call flow diagram related to dynamic verification and enforcement of authorization agreements in accordance with aspects described herein.
• FIG. 13 is an exemplary call flow diagram illustrating a system level call flow that may take place in connection with validating proof of authority for a device to use a first set of selectively activated features, based on a subscription profile of the device, in accordance with aspects described herein.
• FIG. 14 is an exemplary call flow diagram illustrating another system level call flow that may be associated with validating proof of authority for a device to use a first set of selectively activated features identified in an authorization certificate stored at the device in accordance with aspects described herein.
• FIG. 15 is a block diagram illustrating an exemplary device configured to support dynamic verification and enforcement of authorization agreements, where enforcement includes dynamic validation of proof of authority for a device to use a set of selectively activated features and activation/deactivation of selectively activated features in accordance with the terms of the authorization agreements, in accordance with aspects described herein.
• FIG. 16 is a flowchart of an exemplary method operational at a device in accordance with aspects described herein.
• FIG. 17 is a flowchart of an exemplary method operational at a device in accordance with aspects described herein.
• FIG. 18 is a flowchart of an exemplary method operational at a network node in accordance with aspects described herein.
• FIG. 19 is a flowchart of another exemplary method operational at a network node in accordance with aspects described herein.
• FIG. 20 is a block diagram illustrating an exemplary home subscriber server (HSS) configured to support verification and enforcement of authorization agreements in accordance with aspects described herein.
• FIG. 21 illustrates an exemplary method operational at an HSS, which is related to validating the authorization for use of a set of one or more features of a device according to aspects described herein.
DETAILED DESCRIPTION
• In the following description, reference is made to the accompanying drawings in which is shown, by way of illustration, specific aspects and features described in the disclosure. The aspects and features described in the disclosure are intended to be provided in sufficient detail to enable those skilled in the art to practice aspects of the disclosure. Other aspects and features may be utilized and changes may be made to that which is disclosed without departing from the scope of the disclosure. The following detailed description is not to be taken in a limiting sense and the scope of the aspects and features described and illustrated herein are defined only by the appended claims.
• The term “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect or implementation described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or implementations.
• The term “aspect” as used herein does not require that all aspects include the discussed aspect, or any discussed aspect, advantage, and/or mode of operation.
• The term “obtain” is used herein to mean derive, generate, compute, request, receive, acquire, accept, procure, take, collect, get, take delivery or receipt of, be given, gain access to, come into possession of, etc. The term “obtain” as used herein encompasses obtaining locally, and/or obtaining from a non-local or remote entity.
• The term “provision” is used herein to mean send, forward, provide, supply, to cause to be conveyed to a destination. The term “send” is used herein to mean provision, forward, provide, supply, to cause to be conveyed to a destination.
• As used herein, the term “manufacturer” may refer to an entity that builds a product, and sells the product under the entity's own name to consumers or OEMs. An OEM may be an entity that purchases products from another entity and rebrands the products for sale under the OEM's name. An OEM may additionally or alternatively be an entity that purchases different types of products (e.g., servers and data storage products), from the same or different manufacturers, bundles the products together and sells the resulting bundled product under the OEM's name.
• The term “device” may be used herein to refer to any communication device such as a chip component, a client device, and/or a network node. A “chip component” may include, for example, a processing circuit, a modem, a chip set. A “client device” may include, for example, a wireless device, mobile device, subscriber device, mobile phone, mobile communication device, mobile computing device, digital tablet, smart phone, user equipment (UE), user device, user terminal, terminal, station (STA). A “network node” may include any device or machine that is a functional node of a serving network or a home network. Examples of a network node include, but are not limited to, a base station, a network access node (e.g., an evolved node B (eNodeB, eNB)), a mobility management entity (MME), a gateway device (e.g., a serving gateway (S-GW), a packet data network gateway (P-GW)), a home subscriber server (HSS), an authorization, authentication, and accounting (AAA) server (collectively referred to as an HSS/AAA server), a wireless router, an access point (AP), and/or any node performing a network function. A client device and/or a network node may include a chip component.
• The term “network access node” may be used herein to refer to any device that includes wireless device connectivity between a device (e.g., chip component, a client device) and a core network. Examples of a network access node may include an eNB, a base station, an AP. A network access node may be understood to be one example of a network node.
• Networks external to a core network of a cellular communication system, such as a packet data network (PDN) (e.g., the Internet) and an IP Multimedia Service (IMS) network may be exemplified herein by reference to the PDN, however, nothing is intended to limit networks external to the core network to PDNs or IMS networks. Furthermore, aspects and features presented herein are exemplary. Nothing is intended to limit any aspect or feature presented herein to use in a cellular communication system.
• As used herein, a reference to a “feature”, including a reference to a “selectively activated feature”, may be a reference to an aspect, circuit, service, or function of a device (e.g., chip component, client device, network node) that may be implemented in hardware, software, firmware, or any combination of two or more of hardware, software, and firmware.
• The term “selectively activated” may describe a characteristic, or ability, of being changed in its state of activation (e.g., it may be activated and de-activated). In some aspects, the term “selectively activated” may describe a characteristic, or ability, to be specifically enabled/disabled, turned-on/turned-off, and/or started/stopped (e.g., on command/demand). Accordingly, selectively activated features are, for example, features that are able to be specifically activated and/or de-activated (e.g., on command/demand).
• As used herein, reference to a “network service” may be a reference to a function, capability, application, or portion thereof that is offered by or available through a network. A device (e.g., client device, chip component, network node) may include a set of selectively activated features to implement a network service.
• As used herein, the term “authorization information” is understood to mean “proof of authority for a device to use a set of selectively activated features at the device” or “proof of authority for a network node to use a set of selectively activated features at the network node.” Authorization information may be represented by, may include, or may identify an authorization agreement, an authorization certificate, or an authorization agreement and an authorization certificate. Alternatively or additionally, authorization information may include or identify a list of the set of selectively activated features derived by an authorization server (or local authorization server), from an authorization agreement stored at the authorization server (or local authorization server).
• As used herein, reference to a “feature activation key”, “feature activation keys”, or “feature activation key(s)” may be a reference to data (e.g., a sequence or string of bits) used to enable a given feature. The feature activation key may be related to and/or derived with a cryptographic function.
• The term “up-to-date” may be used to denote or describe a thing (e.g., a license) that validly extends up to the present time. Thus, for example, an up-to-date license may be a license that is valid up to the present time.
• As used herein, the term “match” may mean “equal to” or may mean “to correspond to” in some fundamental or basic respect.
• When a device (e.g., chip component, client device, network node) seeks to use a network service, the device, in addition to authenticating itself to a network node providing the network service, may also need to send proof, to the network node, that the device is authorized to activate a set of selectively activated features. The set of selectively activated features, or a subset thereof, may be needed by the device to use the network service. Consequently, to prove the authority of the device to activate a set of selectively activated features, the device may send a proof of authority for the device to use the set of selectively activated features at the device. This proof of authority may be obtained by the device from the authorization server. The device may send the proof of authority for the device to use the set of selectively activated features at the device to the network node that provides the network service. In one aspect, the proof of authority for the device to use the set of selectively activated features at the device may include a list that identifies the features in the set of selectively activated features that are authorized to be activated at the device. In one aspect, the set of selectively activated features may be derived from an authorization agreement. The authorization agreement may be stored at the authorization server. The proof of authority for the device to use the set of selectively activated features at the device may be validated by the network node. In one aspect, validating the proof of authority for the device to use the set of selectively activated features at the device permits the network node to ensure that the selectively activated features needed by the device to use the network service are, for example, authorized for use on the device before the device uses the network service. For example, validating the proof of authority for the device to use the set of selectively activated features at the device permits the network node to ensure that the selectively activated features listed in the set of selectively activated features are paid for under the terms of a license, which may be reflected in an authorization agreement, before the device uses the network service.
• When, for example, a network access node (e.g., eNB) is authorized to provide a service, a message announcing capabilities (e.g., guaranteed delivery, guaranteed bandwidth, and/or other aspects related to quality of service) of the network access node may be broadcast over-the-air so that a device (e.g., chip component, client device) receiving the message can determine if the device wants to use the service. A device receiving the message may already be authorized to activate, and may already have activated, a set of selectively activated features needed to use the service. Nevertheless, the device may want to validate the authorization of the network access node to provide the service. A device should have the opportunity to validate that the network access node is authorized to provide the network service to avoid, for example, an additional charge for an unavailable network service. In one aspect, validating the authorization of the network access node to provide the service permits the device to ensure that the network access node is authorized to provide the service before the device uses the service.
• By way of example, a System Information Broadcast (SIB) and a System Information (SI) message (used to convey one or more SIBs), do not carry any message authentication code or signature signed by a network node. If a device is camped on a cell and obtains an SIB from a network access node, the device cannot verify whether the features advertised in the SIB are validly offered by the network node. To gain access to the network, the device basically trusts, without any ability to verify, that the network is authorized to offer the features that are advertised in the SIB.
• Aspects disclosed herein can provide methods and apparatus for validating authorization information dynamically to permit a first device or node to send first authorization information to a second device or node and obtain second authorization information from the second device or node before beginning to use a service offered by the second device or node. Aspects disclosed herein can permit a device to verify whether a network node is a valid network node and whether the network node is authorized to activate certain features. In an aspect, validation, verification, or validation and verification, may include a cryptographic operation.
Overview
• A device (e.g., chip component, client device, network node) may include an authorization circuit/function/module that activates, deactivates, and/or reports-on one or more selectively activated features of the device. The authorization circuit/function/module may additionally verify that the device has authority to activate and/or use/provide a given feature. In some aspects, verification may be by validation of proof of authority for the device to use a set of selectively activated features at the device (e.g., authorization information of the device).
• In one aspect, using a client device as an example, the client device may determine that a network service is available from a network node (e.g., a network access node, an eNB, MME). The client device may determine which feature(s) (from among a plurality of features available to the client device) the client device needs to use the service. The client device may engage in a feature activation process with an authorization server to obtain proof of authority for the client device to use a set of selectively activated features at the client device (e.g., authorization information in the form of an authorization certificate) and feature activation key(s) needed to activate the features needed to use the network service. The client device may send a request to the network node to request to use the network service. The client device may send the proof of authority for the client device to use the set of selectively activated features at the client device (e.g., the authorization information of the device) to the network node. In response, the client device may obtain a response from the network node granting the request to use the network service. The response may have been predicated on the network node validating the authorization information sent to the network node by the client device. Furthermore, in a case where the network node is an MME, the network node may use the list of features authorized to be activated at the client device, which can be included in the authorization information, to configure a client device context (e.g., a UE context) for the client device.
• The client device, before using the network service, may want to validate the authority of the network node to offer the service. The client device may therefore obtain, from the network node, a proof of authority for the network node to use a set of selectively activated features at the network node (e.g., authorization information in the form of an authorization certificate). The client device may verify the proof of authority for the network node to use the set of selectively activated features at the network node before using the network service.
Exemplary System and System Description
• FIG. 1 is a block diagram of anexemplary system100 that may dynamically authorize and activate one or more selectively activated features on a set of one or more devices (e.g., chip components, client devices, network nodes) according to aspects described herein. The set of one or more devices is exemplified inFIG. 1 withDevice A102,Device B104, andDevice C106.Device A102,Device B104, andDevice C106 may each include an authorization circuit/function/module108,112,116. The authorization circuit/function/module108,112,116 may be useful in a system where, for example, services (e.g., network services) can be implemented in whole or in part using device features (e.g., selectively activated features) that can be individually activated/deactivated (e.g., enabled/disabled) according to, for example, terms of licenses, in real time. An authorization circuit/function/module108,112,116 may be included with any device such asDevice A102,Device B104, orDevice C106 that includes a selectively activated feature, where authorization to activate the selectively activated feature can be based, for example, on anauthorization agreement120. Theauthorization agreement120 may therefore be a source for proof of a right to activate the selectively activated feature.
• Device A102 includes authorization circuit/function/module A108 and a first set of selectively activated features110.Device B104 includes authorization circuit/function/module B112 and a second set of selectively activated features114.Device C106 includes authorization circuit/function/module C116 and a third set of selectively activated features118. For ease of reference, and without any limiting intent, authorization circuit/function/module A108, authorization circuit/function/module B112, and authorization circuit/function/module C116 may be referred to, individually and/or collectively, as “authorization function108,112,116” herein. Additionally, for ease of reference, and without any limiting intent,Device A102,Device B104, andDevice C106 may be referred to, individually and/or collectively, as “device102,104,106” herein.
• Authorization to activate one or more selectively activated features in a set of selectively activated features (such as the first set of selectively activated features110, the second set of selectively activated features114, and/or the third set of selectively activated features118) at a given device (such asDevice A102,Device B104, and/or Device C106) may be a prerequisite to activation of the one or more features at the given device.
• In some aspects described herein, anauthorization function108,112,116 of adevice102,104,106 may obtain and verify proof that thedevice102,104,106 was authorized to activate a selectively activated feature by anauthorization server126 and to obtain and verify the proof (e.g., authorization information) before thedevice102,104,106 activates the selectively activated feature. In some implementations, theauthorization function108,112,116 at a first device may also send the proof to a second device, where the second device may provide a service (e.g., a network service) to the first device.
• Examples of network services may include, for example, dual connectivity service, multiple subscription service, device-to-device (D2D) mode service, multimedia broadcast/multicast service (MBMS), and/or an unlicensed operation service. A dual connectivity service may, for example, provide connectivity both within a radio access technology (RAT) (e.g., 4G) and across RATs (e.g., across 4G and 5G and/or wireless local area network (WLAN)).
• A multiple subscription service may provide, for example, services to a device using a single radio link to serve multiple subscriptions simultaneously (e.g., an operator service subscription and a streaming video subscription and/or an online retail sales provider subscription simultaneously).
• A D2D mode service may offer, for example, a service providing proximal discovery of services, friends, and offers. A D2D service maybe offered, for example, in addition to a traditional access service.
• An MBMS service may be a service that facilitates a device to receive multicast services in addition to access to unicast services.
• An unlicensed operation service may be, for example, a service that allows a device to use licensed assisted access or operate in an unlicensed band using LTE or 5G or one or more other RATs. A complete list of features (e.g., selectively activated features) that may need to be activated to use the above-listed exemplary services, as well as other services, is beyond the scope of this application. Nevertheless, some examples of features that may be selectively activated may include: carrier aggregation; certain physical channels (e.g., in the case of dual connectivity, D2D, and/or unlicensed operation services); selectively activated hardware; and/or selectively executed portions of processing circuit readable instructions stored on the device that were otherwise left unexecuted to preclude a given selectively activated feature from activation.
• Providing the proof (e.g., authorization information) to the second device may be a prerequisite before the second device provides the service. Therefore, for example, even after the first set of selectively activated features110 is authorized and activated atDevice A102, another device (e.g., Device C106) (e.g., a network access node) may requestDevice A102 to send proof of authority ofDevice A102 to use the first set of selectively activated features110 atDevice A102, where the proof of authority can be signed by theauthorization server126. Still further, in some implementations, beforeDevice A102 uses (e.g., activates, employs) a service (e.g., a network service) offered by Device C106 (where a third set of selectively activated features includes third selectively activated features needed byDevice C106 to provide the service to Device A102), and even after the third set of selectively activated features118 are authorized and activated at Device C106 (e.g., a network access node), Device A102 (e.g., a client device) may requestDevice C106 to send proof of authority ofDevice C106 to use the third set of selectively activated features118 atDevice C106, where the proof of authority can be signed by the authorization server126 (or another authorization server).
• Device A102 may send the request for proof toDevice C106 before using the service offered atDevice C106.Device A102 may obtain and verify the proof obtained fromDevice C106 before using the service offered atDevice C106.
• Authorization information (e.g., proof of authority for the device to use a set of selectively activated features at the device) may be based on anauthorization agreement120. Authorization information may be provided, for example, in the form of theauthorization agreement120 and/or anauthorization certificate122. Theauthorization agreement120 may be stored at anauthorization server126. Theauthorization server126 may derive anauthorization certificate122 and an authorization file124 (which may including feature activation keys) based on theauthorization agreement120. Theauthorization certificate122 may include, for example, thedevice102,104,106 public key, the selectively activated features authorized to thedevice102,104,106 (e.g., a set of selectively activated features), and an identifier (e.g., a hash of the device public key or some other device unique identifier) of thedevice102,104,106 to which the selectively activated features are authorized. Theauthorization certificate122 may also include, for example, the expiration time of theauthorization certificate122 and may additionally or alternatively include parameters related to the selectively activated features authorized to thedevice102,104,106. The authorization certificate may be signed by theauthorization server126 using a private key of theauthorization server126.
• Accordingly, theauthorization certificate122 carries the signature of theauthorization server126; the signature can be verified using the public key of theauthorization server126. To derive the signature, for example, theauthorization server126 may apply thedevice102,104,106 public key, the selectively activated features authorized to thedevice102,104,106, and the identifier of thedevice102,104,106 to a hash function; theauthorization server126 may then input the derived hash value and the private key of theauthorization server126 to a signature function. A verification function may be an inverse of the signature function; an entity (e.g., network node) may verify the signature by inputting the signature and the public key of theauthorization server126 to the verification function. In this way, theauthorization certificate122 may be verified and may be used as proof of authority for thedevice102,104,106 to use a set of selectively activated features at thedevice102,104,106, when theauthorization certificate122 is signed by theauthorization server126. Accordingly, theauthorization certificate122 may be used as authorization information.
• In essence,devices102,104,106 are provisioned with the authorization server's certificate during the feature activation. Theauthorization certificate122 may also serve to prove that theauthorization server126 issued anauthorization file124 to thedevice102,104,106 identified in theauthorization file124.
• It is noted that when thedevice102,104,106 sends theauthorization certificate122 to an entity (e.g., a network node), thedevice102,104,106 may sign theauthorization certificate122 with a private key of thedevice102,104,106. This facilitates an ability of thedevice102,104,106 to prove that thedevice102,104,106 is the owner of the public key that is included in theauthorization certificate122. Using the public key included in theauthorization certificate122, the entity (e.g., the network node) can verify that the device that sent theauthorization certificate122 is the same device identified by theauthorization server126 in theauthorization certificate122.
• The authorization information may be requested by adevice102,104,106 at any time (e.g., during initial attach, service request, handover, on demand).
• Anauthorization function108,112,116 may activate a given selectively activated feature (or may authorize/command/instruct thedevice102,104,106 hosting theauthorization function108,112,116 to activate the given selectively activated feature) if theauthorization function108,112,116 obtains and verifies anauthorization agreement120, or anauthorization certificate122 derived from theauthorization agreement120. Theauthorization agreement120, as well as theauthorization certificate122, can record a right of thedevice102,104,106 to activate the given selectively activated feature.
• Anauthorization function108,112,116 may send a feature activation request (e.g., a request to activate one or more selectively activated features, a request for authorization to activate one or more selectively activated features) to alocal authorization server128. The response to the feature activation request may include authorization information (e.g., proof of authority for thedevice102,104,106 to use a set of selectively activated features, including the one or more selectively activated features identified in the feature activation request, at the device). The response may also include anauthorization file124. Theauthorization file124 may include one or more feature activation key(s). Theauthorization server126 may encrypt the authorization information, authorization file, and/or the one or more feature activation keys.
• Theauthorization server126 may sign the authorization information with a private key of a public/private key pair belonging to theauthorization server126. In a case where the authorization information comprises an authorization certificate, theauthorization server126, for example, may sign the authorization certificate with the private key of the public/private key pair belonging to theauthorization server126. Thedevice102,104,106 may use a public key of theauthorization server126 to verify that theauthorization certificate122 is authentic. Persons skilled in the art will appreciate that alternative ways to sign items such as anauthorization certificate122 are within the scope of the aspects presented herein.
• Theauthorization server126 may encrypt theauthorization file124 that may include one or more feature activation keys using the public key of a public/private key pair belonging to thedevice102,104,106. In some aspects, only theauthorization function108,112,116 has access to the private key of the public/private key pair belonging to thedevice102,104,106; therefore only theauthorization function108,112,116 can decrypt theauthorization file124 that may include one or more feature activation keys. Persons skilled in the art will appreciate that other types of encryption for items such as anauthorization file124 that may include feature activation keys are within the scope of the aspects presented herein.
• Thelocal authorization server128 may send the feature activation request to theauthorization server126. In some aspects, the feature activation request can be sent directly from theauthorization function108,112,116 to theauthorization server126 without first being sent to thelocal authorization server128.
• Theauthorization server126 can send a response to the feature activation request after considering/evaluating/processing theauthorization agreement120 associated with the device such asDevice A102,Device B104, orDevice C106. The response to the feature activation request may include authorization information that may be used to verify the right of thedevice102,104,106 to activate the one or more selectively activated features identified in the feature activation request.
• The response may also include anauthorization file124. Theauthorization file124 may include one or more feature activation key(s), authorization parameters, or one or more feature activation key(s) and authorization parameters. Authorization parameters may include, for example, the expiration date/revocation date of the authorization. Thelocal authorization server128, or in some aspects theauthorization server126, may forward theauthorization certificate122 and theauthorization file124 including the feature activation key(s) and authorization parameters, to theauthorization function108,112,116.
• As indicated above, to activate a selectively activated feature of adevice102,104,106 the selectively activated feature may need to be authorized. In accordance with one non-limiting example, an entity (e.g., a user, a service provider, OEM, manufacturer) may pay an authorization fee (e.g., a licensing fee) to activate the selectively activated feature to a licensing service based on terms defined in anauthorization agreement120. Before or after the payment is verified, theauthorization agreement120 may be uploaded to theauthorization server126 and/or alocal authorization server128. Theauthorization server126 may be hosted by the licensing service. The authorization server126 (e.g., a licensing server) may be used for validation, activation, and/or enforcement of the authorization agreement and/or selectively activated features associated therewith.
• In one aspect, adevice102,104 may determine that a network service is available. Thedevice102,104 may identify selectively activated features that are available to the device (but not necessarily activated at the device) and that are needed to use the network service. Identification of selectively activated features needed to use the network service may be obtained from any suitable source such as, for example, a listing/table stored in thedevice102,104, a listing/table obtained from alocal authorization server128, a listing/table obtained from anauthorization server126, or may be obtained from a remote network node or other source (e.g., a node on a packet data network). Thedevice102,104 may determine if it (i.e., thedevice102,104) is authorized to activate the selectively activated features that are needed to use the network service.
• If thedevice102,104 is not authorized to activate all of the selectively activated features needed to use the network service, thedevice102,104, orauthorization function108,112 of thedevice102,104, may request authorization to activate a selectively activated feature (or a plurality of selectively activated features). Thedevice102,104, orauthorization function108,112 of thedevice102,104, may request proof that thedevice102,104 is authorized to activate the requested selectively activated feature. Activation of the requested selectively activated feature may enable thedevice102,104, for example, to obtain a service offered on an application server or use a service provided by a network access node (e.g., eNB).
Exemplary Operating Environment
• FIG. 2 illustrates anexemplary operating environment200 according to aspects described herein. For ease of reference, and without any limiting intent, each authorization circuit/function/module will be referred to as an “authorization function” herein. In theexemplary operating environment200, a first device202 (e.g., chip component, client device, network node) includes afirst authorization function203. A second device204 (e.g., chip component, client device, network node) includes asecond authorization function205. Thefirst device202 and thesecond device204 may wirelessly communicate with athird device206, depicted as a network access node (e.g., eNodeB). The third device206 (e.g., network access node) may include athird authorization function207.
• Thefirst device202 may include one or more selectively activated features needed to use a first network service. Thesecond device204 may include one or more selectively activated features needed to use a second network service. Thethird device206 may include one or more selectively activated features needed to use/provide the first network service to thefirst device202 and/or the second network service to thesecond device204.
• The third device206 (e.g., network access node) may be part of a radio access network (RAN)210 (e.g., enhanced universal terrestrial radio access network (E-UTRAN)). In a non-limiting example of a cellular communication system (e.g., 4G, LTE, LTE-A, 5G) theRAN210 may communicate control signaling and data traffic to a core network212 (e.g., evolved packet core (EPC)). A network operator (e.g., a mobile network operator (MNO)) may operate thecore network212. Control signaling may be communicated via an S1-MME reference point. Data traffic may be communicated via an S1-U reference point.
• Thecore network212 may include a mobility management entity (MME)214, a home subscriber server/authorization, authentication, and accounting server (HSS/AAA)216, a serving gateway device (S-GW)218, and a packet data network gateway device (P-GW)220. In addition to the components identified above, thecore network212 may also include alocal authorization server222. Thelocal authorization server222 may communicate with the third device206 (e.g., network access node) in theRAN210 as well as other network access nodes (not shown). Thelocal authorization server222 may communicate with thefirst device202 and thesecond device204 via the third device206 (e.g., network access node). Internal to thecore network212, thelocal authorization server222 may communicate with theMME214, and/or the HSS/AAA216. Thelocal authorization server222 may serve as a proxy of theauthorization server234 to thefirst device202, thesecond device204, and the third device206 (e.g., network access node) coupled to thecore network212 associated with thelocal authorization server222.
• The P-GW220 may communicate withapplication servers228,230 on a packet data network (PDN)232 (e.g., the Internet). Theapplication servers228,230 may be associated with service providers such as, for example, a retail sales provider, an Internet search engine provider, an entertainment provider, and a social media service provider. Theapplication servers228,230 may host applications and/or application services associated with the service providers.
• Thelocal authorization server222 in thecore network212 may communicate with anauthorization server234 in thepacket data network232. It will be understood that theauthorization server234 could be located anywhere. In other words, it is optional to locate theauthorization server234 with theapplication servers228,230 on thepacket data network232. For example, acore network212 may include theauthorization server234 in addition to thelocal authorization server222.
• Theauthorization server234 may be accessed by thefirst device202, thesecond device204, thethird device206, as well as by any number of entities, such as radio access network providers, mobile network operators, or access point providers. Each entity may also maintain its own local authorization server. Aspects of authorization servers and local authorization servers will be provided below.
Architecture Reference Model
• FIG. 3 is an architecture reference model of asystem300 according to aspects described herein.FIG. 3 illustrates a device302 (e.g., chip component, client device, network node), alocal authorization server306, and anauthorization server308. Thedevice302 may include a least one selectively activatedfeature320. The right of thedevice302 to activate the selectively activatedfeature320 may be based on an authorization agreement330 (e.g., contract, agreement, license). In an aspect, the right of thedevice302 to activate the selectively activatedfeature320 may be based on validation of the authorization agreement330 (or authorization information derived from the authorization agreement330). In an aspect, the right of thedevice302 to activate the selectively activatedfeature320 may be based on a payment related to that selectively activatedfeature320. In an aspect, a status of the payment related to the selectively activatedfeature320 may be reflected in the authorization agreement330 (or authorization information derived from the authorization agreement330). In an implementation, theauthorization server308 may find utility at various instances in connection with a selectively activatedfeature320, including, for example, during validation (e.g., of a right to use the selectively activated feature320), activation (e.g., of the selectively activated feature320), and enforcement (e.g., of terms of theauthorization agreement330 related to the selectively activated feature320).
• Thedevice302 may be coupled to alocal authorization server306. Thelocal authorization server306 may be coupled to anauthorization server308. Thedevice302,local authorization server306, andauthorization server308 will now be described.
• Thedevice302 may include an authorization circuit/function/module, which for ease of reference, and without any limiting intent, will be referred to as the “authorization function304” herein.
• Theauthorization function304 may implement a secure process (e.g., perform secure processing) at aprocessing circuit314 of thedevice302 and/or at asecure operating environment305 of thedevice302. As used herein, the term “secure” may mean protected or safe from access by other processes including external and internal processes and/or from a user. In one aspect, asecure operating environment305, and/or the secure process implemented therein, may be inaccessible to a user and/or inaccessible to processes other than the secure process implemented by theauthorization function304. In one aspect, where theauthorization function304 implements the secure process at theprocessing circuit314 of thedevice302, the secure process may be inaccessible to a user and/or inaccessible to processes other than the secure process implemented by theauthorization function304.
• Theauthorization function304 may implement a process to verify that thedevice302 is authorized to activate the selectively activatedfeature320 of thedevice302. The process may be a secure process. In one aspect, to verify that thedevice302 is authorized to activate the selectively activatedfeature320, theauthorization function304 may obtain proof (e.g., authorization information) that the selectively activatedfeature320 is authorized to be activated. The selectively activatedfeature320 may be authorized to be activated for initial, repeated, and/or continued use. Verification may be by way of validating the obtained proof.
• Theauthorization function304 may also implement a process to verify that a network node (e.g., eNB, MME, S-GW, etc.), which is associated with a network to which thedevice302 is attached, or plans to attach, is authorized to activate a feature corresponding to the selectively activatedfeature320. The process may be a secure process. The feature corresponding to the selectively activatedfeature320 at the network node may be used to facilitate a service offered by the network via the network node. By way of example, thedevice302 may need the feature corresponding to the selectively activatedfeature320 to be activated at the network node to use a network service provided at the network node. By way of additional example, thedevice302 may need the feature corresponding to the selectively activatedfeature320 to be activated at the network node to realize improved service that can be achieved by activating the selectively activatedfeature320 at thedevice302. For example, adevice302, which for the purposes of this example may be a client device, may be manufactured to implement carrier aggregation upon activation of the selectively activatedfeature320. Carrier aggregation permits use of multiple carriers to increase transmission bandwidth. Carrier aggregation may improve the performance of thedevice302. Thedevice302 may be authorized to activate the selectively activatedfeature320 and may be authorized to configure itself to use carrier aggregation. However, to be effective, a network access node (e.g., eNB) coupled to thedevice302 should also activate a corresponding feature such that the network access node is configured to use carrier aggregation. Therefore, in some aspects, a selectively activatedfeature320 may be jointly activated and used by two devices (e.g., chip components, client devices, network nodes, or any combination of two or more thereof).
• In an example, theauthorization function304 may activate and/or deactivate the selectively activatedfeature320 in accordance with terms defined in the authorization agreement330 (and reflected in authorization information derived from theauthorization agreement330 and obtained at the authorization function304). In the example, the terms upon which activation and use are acceptable may be defined by, or listed in, theauthorization agreement330. In the example, the terms may include payment in exchange for a right to use the selectively activatedfeature320. In an implementation, theauthorization function304 of thedevice302 may find utility at various instances in connection with the selectively activatedfeature320 associated with thedevice302, including, for example, during validation (e.g., of a right to use the selectively activated feature320), activation (e.g., of the selectively activated feature320), and enforcement (e.g., of terms of theauthorization agreement330 related to the selectively activated feature320). In some aspects, activation of the selectively activatedfeature320 could allow thedevice302 to obtain services from, for example, an application server on a network (e.g., the Internet) via another device (such as an eNB).
• Thedevice302 may also include a secure storage circuit310 (e.g., a circuit/function/module). In one aspect, thesecure storage circuit310 may be considered secure based on an ability of components/entities (internal and/or external to the device302) to read and write data from and to thesecure storage circuit310. In one aspect, thesecure storage circuit310 may be permanently incorporated into, or integrated with, thedevice302. For example, thesecure storage circuit310 may comprise a non-volatile memory array fabricated on the same substrate as aprocessing circuit314 included with thedevice302.
• Within thesecure storage circuit310 there may be storage space for aprivate key316 of a private/public key pair derived for thedevice302. In one aspect, a manufacturer or OEM may generate the private/public key pair. In another aspect, another entity may generate the private/public key pair. Theprivate key316 of the private/public key pair may be stored in thesecure storage circuit310 by the manufacturer, OEM, or by another entity. In one aspect, theprivate key316 may be stored in thesecure storage circuit310 before transfer of ownership of thedevice302 from the manufacturer or OEM to a third entity. In other aspects, theprivate key316 may be stored in thesecure storage circuit310 at any time and by any entity. In some aspects, theprivate key316 is only known to thedevice302. In some aspects, theprivate key316 is only known to theauthorization function304 of thedevice302.
• Theprivate key316 may be used by the device302 (or the authorization function304) to decryptfeature activation keys318 and/or authorization files that may includefeature activation keys318. Thefeature activation keys318 and/or authorization files that may includefeature activation keys318 may be signed/encrypted by a third entity (e.g., the authorization server308) using the public key of thedevice302 prior to sending thefeature activation keys318 to thedevice302.
• In an aspect, afeature activation key318 may be used to activate a selectively activatedfeature320 of thedevice302. In aspects described herein,feature activation keys318 may be stored in an encrypted form. In some examples,feature activation keys318 may only be decrypted by the authorization function304 (e.g., using theprivate key316 of the device302). In some examples,feature activation keys318 may be stored in a secure environment, such as thesecure storage circuit310.
• Thedevice302 may further include a data storage device312 (e.g., a circuit/function/module), which may be separate from thesecure storage circuit310. In one aspect, thesecure storage circuit310 could be a partition of thedata storage device312, or vice versa. Thesecure storage circuit310 and/ordata storage device312 may comprise, for example, a hard disk, a partition of a hard disk, an optical disk, a partition of an optical disk, a solid state memory, or a partition on a solid state memory.
• Within thedata storage device312, there may be stored a list of features andauthorization parameters322. For example, the list of features andauthorization parameters322 may identify the selectively activatedfeature320 that thedevice302 has authority to activate/deactivate, and their associated authorization parameters. The list of features andauthorization parameters322 may be compiled from, for example, one or more authorization files signed by the authorization server (where signing may be used to validate the authorization files). The authorization files may be obtained from thelocal authorization server306 or theauthorization server308, for example, upon device activation, device handover, device update, or in response to a request from thedevice302. The authorization parameters, in the list of features andauthorization parameters322, may indicate, for example, whether the selectively activatedfeature320 is activated or deactivated and a date upon which authority of thedevice302 to use selectively activatedfeature320 expires or is revoked. As used herein, authority of thedevice302 to use a selectively activatedfeature320 encompasses authority of thedevice302 to provide the selectively activatedfeature320.
• Within thedata storage device312, there may also be storedauthorization certificates323. In an aspect,authorization certificates323 may be verified by any entity and therefore need not be stored in a secure storage. On the other hand, authorization file(s)324 includes private information such as feature activation keys. Therefore, in an aspect, authorization file(s)324 may be stored in thesecure storage circuit310.
• Thedevice302 may also include acommunications bus325 to provide for communications between theauthorization function304, thesecure operating environment305, thesecure storage circuit310, thedata storage device312, theprocessing circuit314, and/or anetwork communication circuit326 included with thedevice302. Thenetwork communication circuit326 may also provide for communication with thelocal authorization server306 and/or theauthorization server308.
• In some aspects, thelocal authorization server306 may act as a local proxy to theauthorization server308. In some aspects, thelocal authorization server306 may send proof of authority for thedevice302 to use a set of selectively activated features320 at thedevice302, signed by thelocal authorization server306, where thedevice302 may be coupled to the core network associated with thelocal authorization server306. In some aspects, thelocal authorization server306 may temporarily operate independently of theauthorization server308. Whether thelocal authorization server306 acts as a local proxy to theauthorization server308 or a local server per se may be, for example, a function of the terms of theauthorization agreement330 stored at theauthorization server308.
• Theauthorization server308 may include a data storage device328 (e.g., a circuit/function/module). Thedata storage device328 may store a listing, repository, or record of authorization agreements330 (e.g., agreements, contracts, licenses). Theauthorization agreements330 may relate to various selectively activated features of a plurality of devices. Thedata storage device328 may maintainkey storage332 for devices that are covered byauthorization agreements330. Thekey storage332 may include private keys and/or public keys that may be used to encrypt messages sent to devices (such as device302) that are covered byauthorization agreements330.
• Thedata storage device328 of theauthorization server308 may also include feature activation key(s)334 that may be used to activate the selectively activated feature(s)320 of thedevice302. In some aspects, feature activation key(s)334 can be sent from an authorization server308 (or a local authorization server306) to thedevice302 when theauthorization function304 of thedevice302 requests proof that thedevice302 has authority to activate one or more of the selectively activated feature(s)320. In such aspects, the selectively activated feature(s)320 may be activated by (or on authority of) theauthorization function304, after the authorization server308 (or the local authorization server306) sends proof (e.g., authorization information) to theauthorization function304 that thedevice302 has authority to activate the selectively activated feature(s)320.
• In an example, thedata storage device328 of theauthorization server308 may store a listing, repository, or record ofauthorization parameters336 for each selectively activatedfeature320 at thedevice302 as a function of a device model number. In one aspect, to permit differentiation of individual devices having the same model number, for example, thedata storage device328 may store theauthorization parameters336 for each selectively activatedfeature320 as a function of a device serial number, or other device identifier such as an International Mobile Station Equipment Identity (IMEI). As known to those of skill in the art, the IMEI is a unique number that is used to identify hardware in accordance with Third Generation Partnership Project (3GPP) systems (e.g., GSM, UMTS, LTE, LTE-A).
• Theauthorization server308 may also include acommunications bus338 to provide for communications between thedata storage device328, aprocessing circuit340, and/ornetwork communication circuit342 included with theauthorization server308. Thenetwork communication circuit342 may also provide for communication with thelocal authorization server306 and/or thedevice302.
• As indicated above, thelocal authorization server306 may serve as a proxy for theauthorization server308. As such, thelocal authorization server306 includes the same or similar circuits/functions/modules as that of theauthorization server308. The description and illustration of the same or similar circuits/functions/modules will therefore be omitted.
Authorization Agreements
• Returning toFIG. 1, authority of adevice102,104,106 to use a set of selectively activated features110,114,118 may be given in an authorization agreement120 (e.g., agreement, contract, license). In some aspects, theauthorization agreement120 may be considered a license. As used herein, in an aspect, a reference to a set of selectively activated features, or a reference to selectively activated feature(s), may be understood to be a reference to one selectively activated feature (e.g., where the set includes one selectively activated feature or the set includes one or more distinct selectively activated features). Theauthorization agreement120 may be used as proof, or theauthorization agreement120 may be used to derive proof, of authority of adevice102,104,106 to use (e.g., activate, maintain activation of) a set of selectively activated features110,114,118 at thedevice102,104,106.
• Theauthorization agreement120 may be established between two or more entities. The entities to anauthorization agreement120 may, for example, claim rights to the device, a feature of the device, and/or a service to be used by the device. By way of example, anauthorization agreement120 may established between a manufacturer, vendor/OEM, the device purchaser, re-seller, licensing service, and/or any two or more of the manufacturer, vendor/OEM, the device purchaser, re-seller, or licensing service. The device purchaser may be an end user, a reseller, or an entity that will lease the device. A licensing service may be an organization that grants licenses and monitors compliance with licensing terms.
• In an example, theauthorization agreement120 may be established in advance of a time when anauthorization function108,112,116 seeks to obtain proof of theauthorization agreement120. In another example, the authorization agreement may be established at the same time, or substantially the same time, as when anauthorization function108,112,116 seeks to obtain proof of theauthorization agreement120.
• Theauthorization agreement120 may be referred to as a writing. As used herein, a writing includes all non-transient machine readable expressions of authorization agreements, regardless of whether such authorization agreements ever existed in a physical human-readable form. The term “writing” includes any human-readable document reduced to any form that can be read by a machine. Forms that can be read by a machine may include electrical, optical, magnetic, or other storage forms known to those of skill in the art.
• In one example, the authorization agreement may be used to derive an authorization certificate that includes:
• 1. a set of selectively activated features authorized for use;
• 2. lifetime/expiration time;
• 3. location where the selectively activated features are enabled (including, for example, geographic or network identifiers such as PLMN, SSIDs, or cell IDSs);
• 4. maximum number of network access nodes that can use the selectively activated features; and
• 5. periodic usage reporting requirements.
• FIG. 4 illustrates anexemplary list400 of parameters and data that may be included in an exemplary authorization agreement between a first entity (e.g., an owner of a device, seller/re-seller of the device, service provider that offers the device to customers with or without a discount) and a manufacturer or OEM of one or more devices in accordance with aspects described herein. The listing is presented in tabular form inFIG. 4, however, any machine readable (e.g., processing circuit readable) form is acceptable according to this aspect. The listing includes parameters, such as the date of anagreement402, an identifier of an owner404 of the device, an identifier of the manufacturer orOEM406 of the device, an identifier of the device408 (e.g., an IMEI number), a list of authorizedfeatures410, the duration of theauthorization agreement412, limitations on use of thefeatures414, and a fee for use of thefeatures416.
• FIG. 5 illustrates anexemplary list500 of parameters and data that may be included in an exemplary authorization agreement between a manufacturer or OEM and another entity (e.g., an entity operating an authorization server) in accordance with aspects described herein. The listing is presented in tabular form inFIG. 5, however, any machine readable (e.g., processing circuit readable) form is acceptable according to this aspect. The listing includes parameters, such as the starting date of anagreement502, the ending date of theagreement504, an identifier of the device506 (e.g., an IMEI number), a list of authorizedfeatures508, limitations on use of thefeatures510, an identifier of thepublic key512 of the device, an identifier of the manufacturer orOEM514 of the device, and a fee for use of thefeatures516.
• FIG. 6 illustrates anexemplary listing600 of parameters and data that may be included in an exemplary authorization agreement between a network operator (e.g., a mobile network operator (MNO)) and another entity (e.g., owner/operator of the authorization server) in accordance with aspects described herein. Theexemplary listing600 is presented in tabular form inFIG. 6, however, any machine readable (e.g., processing circuit readable) form is acceptable according to this aspect. Theexemplary listing600 includes parameters such as the starting date of theauthorization agreement602, the ending date of theauthorization agreement604, an identifier of the device606 (e.g., an IMEI number), a list of authorized service(s)608, a list of authorizedfeatures610, an identifier of the manufacturer or OEM of thedevice612, and a fee for use of thefeatures614.
Provisioning
• FIG. 7 is a flow diagram illustrating actions related to sending of authorization certificates, authorization files, feature activation keys, and software to devices (e.g., chip components, client devices, network nodes) in accordance with aspects described herein. In one aspect, actions identified with reference numbers702-712 may be taken by an authorization server, while the action identified withreference number714 may be taken by a local authorization server. In one aspect, actions identified with reference numbers702-714 may be taken by the authorization server. That is, in such aspects, the authorization server may derive and send an authorization certificate, authorization file, feature activation key(s), and/or software to a device without intervention of the local authorization server. In one aspect, actions identified with reference numbers702-714 may be taken by the local authorization server. That is, in such aspects, the local authorization server may derive and send the authorization certificate, authorization file, feature activation key(s), and/or software to the device without intervention of the authorization server.
• As described above, authorization agreements may be entered into between various entities (e.g., an owner of a device, seller/re-seller of the device, service provider that offers the device to customers with or without a discount, a manufacturer, or OEM of a device). For example, one entity may pay a second entity a fee for a right to use a service or selectively activated feature for a predefined time (e.g., quarterly). Once the entities have entered into the authorization agreement, the authorization agreement may be stored702 on an authorization server. The authorization server may derive feature activation keys(s)704 based on information in the authorization agreement (e.g., derive feature activation keys(s)704 based on the authorization agreement). The authorization server may derive anauthorization certificate706 based on information in the authorization agreement. The authorization server may also derive anauthorization file708 based on information in the authorization agreement. In some aspects, the authorization file may include one or more feature activation keys. The order of these actions is exemplary and not limiting. Any order is acceptable.
• A feature activation key may be used to activate a selectively activated feature of a device (e.g., chip component, client device, network node). The feature activation key may be encrypted, and/or the authorization file having the feature activation key(s) therewith may be encrypted. In some examples, the feature activation key(s) and/or authorization file may only be decrypted by the authorization function of the device.
• In some aspects, one feature activation key per selectively activated feature may be used for selectively activated feature activation. In other aspects, one feature activation key may be used to activate multiple selectively activated features. Activating a selectively activated feature may include an initial activation of the selectively activated feature as well as maintaining activation of an already activated selectively activated feature. In one aspect, a feature activation key may unlock a selectively activated feature. By way of example, a selectively activated feature may be activated, but may be locked from use based on terms of the authorization agreement (e.g., the selectively activated feature may be locked from use based on a geographic or time-related parameter limitation imposed by the authorization agreement). The activated selectively activated feature may be unlocked (e.g., the ability of the device to use the already activated selectively activated feature may be enabled) based on obtaining and using of an appropriate feature activation key.
• An authorization file may include data relevant to a selectively activated feature. Data relevant to a selectively activated feature may include, for example, the date upon which authority of the device to use the selectively activated feature expires or is revoked. Other data relevant to the selectively activated feature may also be included in the authorization file.
• In one aspect, the authorization server may send or upload710 (e.g., provision) the authorization certificate and the authorization file including feature activation key(s) to a local authorization server. The authorization server may optionally send or uploadsoftware712 related to selectively activated features of a device, or any feature (hardware or software) related to the device, to the local authorization server. For example, software in the form of an updated driver may be sent or uploaded in addition to the authorization certificate and authorization file.
• The authorization server and/or local authorization server may send714 the authorization certificate, authorization file including feature activation key(s), and software (optional), to a device (e.g., chip component, client device, network node) in response, for example, to obtaining a feature activation request from the device.
• In an example, when multiple devices are included in an authorization agreement, the local authorization server may ensure that no more than a maximum number of devices (e.g., a quota) are using an authorized selectively activated feature. For example, the local authorization server may receive an indication when a selectively activated feature is deactivated at a first device before the local authorization server issues an authorization to activate the selectively activated feature at a second device. Alternatively, the local authorization server may revoke an authorization to activate a selectively activated feature at a first device before the local authorization server issues an authorization to activate the selectively activated feature at a second device. The revocation may be based, for example, on a periodic reporting from all authorized devices to determine in which devices the selectively activated feature is being actively used.
Feature Activation Request
• FIG. 8 is a flow diagram800 illustrating a method involving a feature activation request (e.g., a request to activate one or more features, a request for authorization to activate one or more features) in accordance with aspects described herein. A device (e.g., a chip component, client device, network node) may activate a selectively activated feature if the device has authorization to do so. Various events may result in the device sending a feature activation request. For example, the selectively activated feature may be needed to use a network service, an administrator may determine to configure the device in a way that invokes the selectively activated feature, a subscription update may occur, and/or an operation, administration, and management (OAM) protocol may need to activate the selectively activated feature for maintenance purposes.
• To activate the selectively activated feature, the device may obtain proof of authority for the device to use the selectively activated feature at the device, and obtain an authorization file including feature activation key(s). Proof of authority may be provided, for example, in the form of authorization information. The authorization information may include the authorization agreement and/or an authorization certificate. In an example, to obtain the proof of authority for the device to use the selectively activated feature and the authorization file including feature activation key(s), the device may send a feature activation request (e.g., a request to activate one or more selectively activated features) to a local authorization server.
• The local authorization server may obtain802 the feature activation request from the device. The local authorization server may determine804 if the local authorization server possesses items needed for a response to the request (e.g., a proof of authority for the device to use a set of selectively activated features at the device, such as authorization information, and an authorization file including feature activation key(s)). If the local authorization server does not possess the items needed, or if the local authorization server possesses the items but the items are not valid (e.g., due to expiration of an authorization), the local authorization server may attempt to obtain806 the proof of authority (e.g., authorization information in the form of an authorization certificate) and the authorization file including feature activation key(s) from an authorization server.
• In one aspect, the local authorization server may obtain806 the proof of authority (e.g., authorization information in the form of an authorization certificate) and the authorization file including feature activation key(s) from the authorization server by forwarding the feature activation request to the authorization server. The authorization server may send the proof of authority (e.g., authorization information in the form of an authorization certificate) and the authorization file including feature activation key(s) if, for example, an authorization agreement confirms that the requested selectively activated features are authorized. In the case where the feature activation request is sent to the authorization server, the local authorization server may act as a proxy server that provides a secure tunnel between the device (e.g., chip component, client device, network node) and the authorization server. After verifying the authorization agreement (e.g., between the device and a licensing service and/or between the mobile network operator and the licensing service), the authorization server may send the proof of authority (e.g., authorization information in the form of an authorization certificate) and the authorization file including feature activation key(s) to the local authorization server.
• If the local authorization server possesses the proof of authority (e.g., authorization information in the form of an authorization certificate) and the authorization file, the local authorization server may determine808 if a quota is reached for the requested selectively activated feature. If the quota for the requested selectively activated feature is reached, the local authorization server may send a response to the device denying810 the request to activate the selectively activated feature. A reason for the denial may be included with the response. If the quota for the requested selectively activated feature is not reached, the local authorization server may send a response to thedevice812 including, for example, the proof of authority (e.g., authorization information in the form of an authorization certificate) and the authorization file including feature activation key(s).
• A local authorization server may cache authorization agreements, authorization certificates, authorization files, feature activation key(s), and optional software for future use. In an aspect, the caching may apply when the local authorization server issues an authorization certificate on behalf of the authorization server and reports the authorization status to the authorization server.
Activation of Selectively Activated Features
• FIG. 9 is a flow diagram900 illustrating one example of activation of selectively activated features in accordance with aspects described herein. A device (e.g., chip component, client device, network node), or an authorization function of the device, may obtain902 proof of authority (e.g., authorization information in the form of an authorization certificate) of the device to use a set of selectively activated features at the device, where the proof of authority is signed by an authorization server, and may also obtain an authorization file including feature activation keys. In one aspect, the proof of authority and authorization file may be obtained in response to a feature activation request (e.g., a request to activate one or more selectively activated features). The authorization file may include feature activation keys encrypted with the public key of the device. The authorization function may validate904 the proof of authority (e.g., authorization information in the form of an authorization certificate). In one aspect, validation may include using a validation function and the public key of the authorization server. If the proof of authority (e.g., authorization information in the form of an authorization certificate) is validated, the device may decrypt906 the authorization file including feature activation keys using a private key of the device. The authorization function may retrieve the feature activation keys from the decrypted authorization file. The authorization function may evaluate908 authorization parameters included with the authorization file (e.g., confirm that authorization parameters, such as an expiration date of the authority of a device to use a selectively activated feature, are not expired). The authorization function may then activate the set of selectively activated features910 using the decrypted feature activation keys.
• Any activated selectively activated feature may remain activated until a deactivation event occurs. One example of a deactivation event could be the reaching of an expiration time specified in the authorization parameters associated with the activated selectively activated feature. Other deactivation events are acceptable. The authorization function may store912 the retrieved feature activation key at a secure storage device of the device. The authorization function may also store912 the retrieved authorization parameters at a data storage device of the device.
• In one example, the authorization function of the device may be able to decrypt the authorization file reliably and with good assurance of security at least because the authorization server may have encrypted the authorization file using a public key (of a public/private key pair) of the device, the device may have stored the private key in the secure storage circuit of the device, and the private key may be only known to the authorization function. The device may rely on the authorization function to ensure that activation of the selectively activated feature(s) is appropriate. Additionally, when the device receives an authorization certificate from the network (e.g., authorization server), the device should be able to verify that the authorization certificate is a correct authorization certificate sent by the authorization server (e.g., not sent by an imposter). In one example, to facilitate the ability of the device to verify that the authorization certificate is a correct authorization certificate sent by the authorization server, the authorization server can add a signature of the authorization server (derived with a private key of the authorization server) to the authorization certificate. The signature of the authorization server may be verified at the device using the public key of the authorization server. Similarly, when the device receives an authorization file from the network (e.g., authorization server), the device should be able to verify that the authorization file is a correct authorization file sent by the authorization server (e.g., not sent by an imposter). In one example, to facilitate the ability of the device to verify that the authorization file is a correct authorization file sent by the authorization server, the authorization server can add a signature of the authorization server (e.g., a signature derived with a private key of the authorization server) to the authorization file. The signature of the authorization server may be verified at the device using the public key of the authorization server.
• The device may monitor the usage of the activated selectively activated feature and may send914 periodic reports related to the usage of the selectively activated features (e.g., report the activation status) to the authorization server and/or the local authorization server. The authorization server and/or the local authorization server may aggregate the reports related to the usage of selectively activated features from all devices that send such reports. A report on the usage status of the selectively activated features may be referred to herein as a status report. Periodic status reports may be used, for example, to enforce limitations on the rights of devices to use selectively activated features. For example, an authorization server (or local authorization server) may use data obtained from the status reports to verify that greater than a maximum number of devices are, or are not, concurrently using a selectively activated feature. If greater than a maximum number of devices are concurrently using the selectively activated feature (e.g., a quota is reached), new requests to activate the selectively activated feature may be denied. Records relating to usage, license fees, etc. may be derived and maintained.
Orchestration Procedure
• In one aspect, upon successful feature activation at a device (e.g., chip component, client device, network node), the authorization server may transmit data to an HSS/AAA server associated with the device to inform the HSS/AAA server of the updated features/updated capability of the device.
• The HSS/AAA server may update a subscription profile of the device and may send the information to network nodes (e.g., eNodeB, MME, P-GW, etc.) after the updated device features are verified by a network operator (e.g., an MNO). In some aspects, it can be the role of the network operator to update a subscription profile based on the capability and authorization status of the device.
• Updating the subscription profile of the device, once the request to activate one or more features is approved and/or the features are activated, may permit a network node (e.g., eNB, MME, S-GW, P-GW) to validate the authorization of a device to use a feature without a need for the network node to obtain another form of proof. For example, updating the subscription profile to permit the network node to validate the authorization of the device to use the feature based on the subscription profile and may obviate a need of the network node to obtain, from the device, proof of authority for the device to use a set of selectively activated features at the device.
• In one aspect, when the device is a network access node (e.g., an eNodeB), information concerning the availability of a certain set of features/services that are activated at the network access node may be sent to a device. In some implementations, the certain set of features/services that are activated at the network access node may be announced to devices (e.g., chip components, client devices) via an over-the-air broadcast (e.g., a system information block (SIB)Type1 broadcast). In some implementations, a device may use a protocol to query the network access node, and thereby may determine the availability of the certain set of features/services that may be activated at the network access node. One example of such a query protocol may be an access network query protocol (ANQP). Other query protocols are acceptable. In these exemplary ways, a device may become aware of the features/services available from the network access node so that the device can determine if the device wants to make use of the features/services after mutual authentication.
Exemplary Authorization Server
• FIG. 10 is a block diagram illustrating anauthorization server1000 configured to support dynamic verification and enforcement of authorization agreements in accordance with aspects described herein. In one example, theauthorization server1000 may include anetwork communication circuit1002, aprocessing circuit1004, and a memory circuit/storage device (referred to herein as memory circuit1006). Thenetwork communication circuit1002,processing circuit1004, andmemory circuit1006 may be coupled to acommunication bus1008 for exchange of data and instructions.
• Thenetwork communication circuit1002 may be configured to include an input/output module/circuit/function1010 for communication with network nodes such as a P-GW device, a local authorization server, and/or a network access node. Other circuits/functions/modules may be included in thenetwork communication circuit1002 of theauthorization server1000 as will be appreciated by those of skill in the art.
• Theprocessing circuit1004 may be configured to include or implement one or more processors, application specific processors, hardware and/or software modules, etc., that are configured to support dynamic verification and enforcement of authorization agreements. Theprocessing circuit1004 may include an authorization agreement management circuit/function/module1012, which may manage the collection, maintenance, and organization of authorization agreements stored in theauthorization server1000. Theprocessing circuit1004 may include a feature activation key derivation circuit/function/module1014, which may be used to derive feature activation keys that may be used to activate selectively activated features of devices (e.g., chip components, client devices, network nodes). Theprocessing circuit1004 may include an authorization parameter derivation circuit/function/module1016, which may be used to derive authorization parameters (e.g., expiration date of an authorized selectively activated feature) that may be passed to devices along with feature activation keys. Theprocessing circuit1004 may include an authorization certificate derivation circuit/function/module1018, which may derive an authorization certificate based on an authorization agreement and may sign the authorization certificate with a private key of theauthorization server1000. Other circuits/functions/modules may be included in theprocessing circuit1004 of theauthorization server1000 as will be appreciated by those of skill in the art.
• Thememory circuit1006 may be configured to include authorizationagreement management instructions1020, feature activationkey derivation instructions1022, authorizationparameter derivation instructions1024, authorizationcertificate derivation instructions1026, as well as space for featureactivation key storage1030,authorization parameter storage1032, publickey storage1034, and authorization certificate storage1036. Other instructions and locations for storage of data may be included in thememory circuit1006 as will be appreciated by those of skill in the art.
Exemplary Local Authorization Server
• FIG. 11 is a block diagram illustrating alocal authorization server1100 configured to support dynamic verification and enforcement of authorization agreements in accordance with aspects described herein. Thelocal authorization server1100 may be a proxy for an authorization server (e.g.,1000,FIG. 10). In one example, thelocal authorization server1100 may include anetwork communication circuit1102, aprocessing circuit1104, and a memory circuit/storage device (referred to herein as memory circuit1106). Thenetwork communication circuit1102,processing circuit1104, andmemory circuit1106 may be coupled to acommunication bus1108 for exchange of data and instructions.
• Thenetwork communication circuit1102 may be configured to include an input/output module/circuit/function1110 for communication with network nodes such as an authorization server and/or a network access node. Other circuits/functions/modules may be included in thenetwork communication circuit1102 of thelocal authorization server1100 as will be appreciated by those of skill in the art.
• Theprocessing circuit1104 may be configured to include or implement one or more processors, application specific processors, hardware and/or software modules, etc., that are configured to support dynamic verification and enforcement of authorization agreements. Theprocessing circuit1104 may include an authorization agreement management circuit/function/module1112, which may manage the collection, maintenance, and organization of authorization agreements stored in thelocal authorization server1100. Theprocessing circuit1104 may include a feature activation key derivation circuit/function/module1114, which may be used to derive feature activation keys that may be used to activate selectively activated features of devices. Theprocessing circuit1104 may include an authorization parameter derivation circuit/function/module1116, which may be used to derive authorization parameters (e.g., expiration date of an authorized selectively activated feature) that may be passed to devices along with feature activation keys. Theprocessing circuit1104 may include an authorization certificate derivation circuit/function/module1118, which may derive an authorization certificate based, for example on data in an authorization agreement, and encrypt the authorization certificate with a public key of a device. Theprocessing circuit1104 may include a feature usage reporting circuit/function/module1138, which may collect feature usage data from devices coupled to thelocal authorization server1100. Other circuits/functions/modules may be included in theprocessing circuit1104 of thelocal authorization server1100 as will be appreciated by those of skill in the art.
• Thememory circuit1106 may be configured to include authorizationagreement management instructions1120, feature activation key derivation instructions1122, authorizationparameter derivation instructions1124, authorizationcertificate derivation instructions1126, as well as space for featureactivation key storage1130,authorization parameter storage1132,authorization certificate storage1134, and publickey storage1136. Thememory circuit1106 may also be configured to include featureusage reporting instructions1140. Other instructions and locations for storage of data may be included in thememory circuit1106 as will be appreciated by those of skill in the art.
Exemplary Call Flow Diagram of Feature Activation
• FIG. 12 is a call flow diagram1200 related to dynamic verification and enforcement of authorization agreements in accordance with aspects described herein.FIG. 12 depicts exemplary interactions between a device1202 (e.g., chip component, client device, network node), alocal authorization server1204, and anauthorization server1206. In an aspect, call flow to and from thedevice1202 may be to and from an authorization function of thedevice1202.
• Anauthorization server1206 may obtaindevice validation information1208 from a vendor/OEM or another entity. The device validation information may include, for example, a device identifier, a device certificate, a device public key, software version (e.g., software version of software associated with the authorization function residing on the device1202), and/or device capabilities. Device capabilities may include a listing of selectively activated features at thedevice1202. It will be understood that obtaining device validation information at theauthorization server1206 may be an ongoing process. There is no limitation as to when device validation information may be added, modified, or removed from theauthorization server1206.
• An authorization agreement may be entered into between two entities. The authorization agreement (or a copy thereof) may be obtained1210 at thelocal authorization server1204 for storage, may be obtained1211 at theauthorization server1206 for storage, or may be obtained at both thelocal authorization server1204 and theauthorization server1206 for storage. In one example, the authorization agreement may include a provision calling for the validation of software running at the local authorization server.
• A device1202 (or an authorization function of the device1202) may send a feature activation request1212 (e.g., a request to activate one or more selectively activated features) to thelocal authorization server1204. The feature activation request may include a certificate signing request for certificate based verification.
• Thedevice1202 andlocal authorization server1204 may engage inremote attestation1214.Remote attestation1214 may be used by a first entity to verify that a second entity is working correctly (e.g., based on a known correct state). For example, thelocal authorization server1204 may verify that thedevice1202 is working correctly by validating the software running at thedevice1202. In one example, validating the software may entail comparing the software identified in device validation information sent to thelocal authorization server1204 matches the software running at thedevice1202. The result ofremote attestation1214 may be sent to theauthorization server1206. The result ofremote attestation1214 may be used to assure theauthorization server1206 that an attacker has not compromised thedevice1202 and that thedevice1202 is running software described/identified by the vendor/OEM. If remote attestation is not successful, the feature activation request may be ignored.
• Ifremote attestation1214 is successful, based on the authorization agreement (e.g., the authorization agreement obtained at the local authorization server for storage), thelocal authorization server1204 may determine whether to request feature activation for the device to the authorization server1206 (e.g., send feature activation request1216) or authorize feature activation for the device on its own authority (e.g., send authorization agreement/authorization certificate/authorization file(s)1222). The latter scenario may occur, for example, when thelocal authorization server1204 has obtained one or more authorization keys (e.g., feature activation keys) from theauthorization server1206 in advance, based on the authorization agreement.
• If thelocal authorization server1204 determines to request feature activation for the device to theauthorization server1206, thelocal authorization server1204 may send (e.g., forward) thefeature activation request1216 to theauthorization server1206, in which case, thelocal authorization server1204 may be a proxy server that provides a secure tunnel between thedevice1202 and theauthorization server1206. The feature activation request may include device validation information (e.g., a device identifier, a device certificate, a device public key, software version, and/or device capabilities) andremote attestation1214 results. Thefeature activation request1216 sent to theauthorization server1206 may also include the certificate signing request, if the certificate signing request was included with the feature activation request sent to the local authorization server from the device.
• In one aspect, thelocal authorization server1204 andauthorization server1206 may engage inremote attestation1218. For example, thelocal authorization server1204 may send proof to theauthorization server1206 that thelocal authorization server1204 is running the correct software. In this way, theauthorization server1206 may be able to trust the information about thedevice1202 sent to theauthorization server1206 by thelocal authorization server1204. In accordance with such an aspect, theauthorization server1206 may accept a result of the remote attestation performed between thedevice1202 and thelocal authorization server1204. Optionally or alternatively, theauthorization server1206 and thedevice1202 may engage inremote attestation1219.
• Once theauthorization server1206 accepts the results of the remote attestation (with either or both of thelocal authorization server1204 and the device1202) (e.g., verification is successful) and theauthorization server1206 can verify that the feature activation request complies with the terms of the authorization agreement, theauthorization server1206 may send1220 the authorization agreement, authorization certificate, or authorization agreement and authorization certificate (e.g., proof of authority) of thedevice1202 to use a set of selectively activated features at thedevice1202 and the authorization file including feature activation key(s), to thelocal authorization server1204. In one aspect, theauthorization server1206 may verify an authorization agreement of thedevice1202 with a network operator (e.g., an MNO) (or a third entity). The proof of authority sent by theauthorization server1206 may include an authorization agreement, an authorization certificate, or both the authorization agreement and the authorization certificate. Optionally, theauthorization server1206 may send1223 the authorization agreement/authorization certificate/authorization file(s) including feature activation keys directly to thedevice1202.
• If thelocal authorization server1204 determined to send a feature activation request to the authorization server1206 (e.g., request feature activation for the device to the authorization server1206) and obtained the proof of authority for the device to use a set of selectively activated features at the device and the authorization file including feature activation key(s) from theauthorization server1206, or determined to send the proof of authority for the device and the authorization file on its own authority (e.g., in the case where thelocal authorization server1204 obtained one or more authorization keys from theauthorization server1206 in advance, based on the authorization agreement), the local authorization server may send the authorization agreement/authorization certificate/authorization file(s)1222 to thedevice1202. That is,local authorization server1204 may send the proof of authority for the device to use the set of selectively activated features and the authorization file including feature activation key(s) (and software, if available) to thedevice1202.
• Once thedevice1202 obtains the proof of authority for the device to use the set of selectively activated features at the device (e.g., the authorization agreement, the authorization certificate, or both the authorization agreement and the authorization certificate), and the authorization file including feature activation key(s) (e.g., in response to a feature activation request), the device1202 (and/or authorization function of the device) may validate the proof of authority (e.g., to determine whether the device is authorized to activate and use the requested selectively activated feature(s)). If the device (and/or authorization function of the device) determines that the device is authorized to use the requested selectively activated feature(s), the device (and/or authorization function of the device) may retrieve the feature activation key(s) for the requested selectively activated features and activate the requested selectively activated feature(s)1224. In some implementations, the requested selectively activated feature(s) may remain activated until an expiration time specified in the proof of authority (e.g., in the authorization certificate) or an expiration time specified in the authorization file.
• Thedevice1202 may send aperiodic report1226 to thelocal authorization server1204 regarding usage of the selectively activated features. Thelocal authorization server1204 may aggregate reports received from a plurality of devices and may send aperiodic report1228 to theauthorization server1206 regarding usage of the selectively activated features. Those of skill in the art will appreciate that various systems may use various types of usage reporting formats. The aspects described herein are not limited to any one usage reporting format.
• Periodic reports may give flexibility to the local authorization management by allowing an operator to activate a selectively activated feature at a plurality of devices (e.g., chip components, client devices, network nodes) as long as the total number of activated selectively activated features satisfies the terms of a pertinent authorization agreement. For example, the periodic reporting may allow an operator to activate a maximum allowable number of selectively activated features concurrently.
Exemplary System Level Call Flow Diagrams of Validation of Authorization for Use
• Before using a network service, each side (e.g., client side and serving side; client device and network node) may validate that the other side is authorized to activate and use one or more selectively activated features needed to use the network service, and/or needed to provide the network service. In other words, an act of mutual feature verification may occur. In this way, each side may enforce the terms of authorization agreements that may govern the rights of the devices (e.g., chip components, client devices, network nodes) to use/provide the one or more selectively activated features. Accordingly, before using/providing a network service, each side may obtain proof of authority of the other side's right to use selectively activated features needed to provide/use the network service, and may validate that proof of authority.
• Two exemplary system level methods to validate the proof of authority for a device (e.g., chip component, client device, network node) to use a set of selectively activated features are provided below. The first method provides for validation based on a subscription profile of a device. The second method provides for validation based on authorization information sent by the device. The exemplary system level methods are not exclusive.
• Prior to implementation of either exemplary system level method, authorization information on a per device (e.g., chip component, client device, network node) basis may be stored by the device. Additionally, the authorization information, or information reflecting new and/or updated selectively activated features of the device, may also be stored on a home subscriber server (HSS). For example, when a device activates a selectively activated feature, an authorization server or a local authorization server may report the activation of the selectively activated feature to the HSS. The HSS can update a capability profile of the device when the authorized new and/or updated selectively activated features of the device are verified by a network operator (e.g., an MNO). The capability profile of the device can be associated with a subscription profile of the device. The capability profile may identify selectively activated features that the device is authorized to use. In one example, the capability profile of the device, stored at the HSS, may be available to the device, to a network node, or to the device and the network node.
• Additionally, according to an aspect, a network node (e.g., eNB) may announce, to devices (e.g., chip components, client devices), the set of selectively activated features activated (e.g., enabled, used) at the network node. A set of features can be announced, for example, using System Information Block (SIB) messages or via a querying protocol such as a Service Query Protocol (SQP).
• FIG. 13 is an exemplary call flow diagram1300 illustrating a system level call flow that may take place in connection with validating proof of authority for a device (e.g., chip component, client device, network node) to use a first set of selectively activated features, based on a subscription profile of the device, in accordance with aspects described herein. Illustrated are a device1302 (e.g., chip component, client device, network node), a radio access network (RAN)1304 (which includes, for example, one or more eNBs and/or access points), a network node1306 (e.g., an MME), anHSS1308, alocal authorization server1310, and anauthorization server1312.
• In some implementations, theauthorization server1312 may obtaindevice validation information1314 from a vendor/OEM or another entity. The device validation information may include, for example, a device identifier, a device certificate, a device public key, software version (e.g., software version of software associated with the authorization function residing on the device1302), and/or device capabilities. Device capabilities may include a listing of selectively activated features at thedevice1302. It will be understood that obtaining device validation information at theauthorization server1312 may be an ongoing process. There is no limitation as to when device validation information may be added, modified, or removed from theauthorization server1312.
• An authorization agreement may be entered into between two entities. The authorization agreement may be obtained1315 at theauthorization server1312 for storage, the authorization agreement may be obtained1316 at thelocal authorization server1310 for storage, or the authorization agreement may be obtained at both thelocal authorization server1310 and theauthorization server1312 for storage. In one example, the authorization agreement may include a provision calling for the validation of software running at the local authorization server.
• During feature activation, theauthorization server1312 may derive authorization certificates, authorization files, and feature activation keys, all as described above. Also during feature activation, theauthorization server1312 may send1318 proof of authority for the device to use a set of selectively activated features at the device (e.g., authorization information in the form of an authorization agreement, an authorization certificate, or an authorization agreement and an authorization certificate) and an authorization file that may include feature activation key(s) to thelocal authorization server1310, all as described above. Alternatively, but not shown in the figure to avoid overcrowding in the drawing, theauthorization server1312 may send the proof of authority to thedevice1302, all as described above. Additionally, or alternatively, during feature activation, thelocal authorization server1310 may send1320 the proof of authority for the device to use the set of selectively activated features at the device (e.g., authorization information in the form of an authorization agreement, an authorization certificate, or an authorization agreement and an authorization certificate) and the authorization file that may include feature activation key(s) to thedevice1302, all as described above. In one aspect, thelocal authorization server1310 may send acapability profile1322 of thedevice1302 to theHSS1308. The capability profile of thedevice1302 may list the selectively activated features authorized to be activated at thedevice1302. The capability profile may list the parameters associated with the selectively activated features. The capability profile of the device may be used to update to a corresponding capability profile of thedevice1302 that can be stored at theHSS1308. In one aspect, theauthorization server1312 may send thecapability profile1324 of thedevice1302 to theHSS1308.
• With reference to theHSS1308, the capability profile of thedevice1302 may include the list the selectively activated features authorized to be activated at thedevice1302 and may be associated with the subscription profile of thedevice1302. The capability profile of thedevice1302, obtained by theHSS1308, enables theHSS1308 to learn the authorization status of new and/or updated selectively activated features of thedevice1302. In an aspect, theHSS1308 may consult with a network operator (e.g., an MNO) to determine if theHSS1308 should update the corresponding capability profile of thedevice1302 stored at theHSS1308. In an aspect, with or without consent of the network operator, theHSS1308 may update1325 the capability profile of thedevice1302 stored at theHSS1308. Accordingly, theHSS1308 may update1325 a list of selectively activated features of thedevice1302 based on the list the selectively activated features authorized to be activated at the device obtained from thelocal authorization server1310 or theauthorization server1312. Updating the list may reflect a change to an authorization status of at least one selectively activated feature in the set of selectively activated features authorized to be activated at thedevice1302.
• Upondevice1302 initial attachprocedure1326, the network node1306 (e.g., MME) may obtain1328 the capability profile of thedevice1302 from theHSS1308. In one aspect, the network node1306 (e.g., MME) may obtain1328 the capability profile of thedevice1302 from theHSS1308 by sending a request to theHSS1308.
• In one example, the capability profile may include integrity information (e.g., software integrity information of the authorization function of the device1302) obtained during a secure/authenticated boot process of thedevice1302. By way of example, in a case where an integrity profile is obtained during the secure/authenticated boot process (e.g., during an authentication and key agreement (AKA) procedure), the network node1306 (e.g., MME) may request thedevice1302 to send the integrity information that proves the integrity of the software running in thedevice1302. Integrity information of adevice1302 may be sent by thedevice1302 as proof that thedevice1302 is running a legitimate software (i.e., the device is running authorized software). In one aspect, the network node1306 (e.g., MME) may make a request for integrity information during mutual authentication1330 (e.g., remote attestation) with thedevice1302. The integrity information may be used duringmutual authentication1330. It is noted that the preceding is exemplary; a request to send integrity information may occur during the AKA procedure or as a separate procedure.
• The network node1306 (e.g., MME) may configure a device context1332 (e.g., a UE context that may identify a specific signal radio bearer or default radio bearer or data flow) based on the capability profile of thedevice1302 obtained from theHSS1308. The network node1306 (e.g., MME) may configure thedevice context1332 with the RAN1304 (e.g., eNBs of the RAN) and may send the device context and/or the capability profile to theRAN1304. This can allow theRAN1304 to activate/de-activate selectively activated features, thereby enabling (or disabling) a network service provided to thedevice1302. Enablement/disablement of a network service for thedevice1302 may be achieved by updating/setting the device context according to the capability profile of thedevice1302. Non-access stratum (NAS) and radio resource control (RRC) procedures may be used for this purpose.
• It may be noted that during an S1 handover, the device context (e.g., UE context) may be transferred to a target MME if MME relocation is performed. During X2 handover, the source network access node (e.g., source eNB) may send the device context (e.g., UE context) that specifies device capability to a target network access node (e.g., target eNB).
• If the capability profile of thedevice1302 indicates that certain selectively activated features need to be de-activated (e.g., due to expiry), the network node1306 (e.g., MME) may deactivate the selectively activated features and may apply the corresponding configuration to the network access node (e.g., eNB) (within the RAN1304). The corresponding configuration may be applied to the network access node using, for example, a device context modification procedure (e.g., a UE context modification procedure). Thedevice1302 may reactivate any de-activated selectively activated feature by renewing the authorization agreement (stored in the authorization server) and then performing feature activation (e.g., sending a feature activation request) as described above.
• The first exemplary system level method may make use of the authorization information stored in the capability profile of thedevice1302, associated with the subscription profile of thedevice1302, at theHSS1308. TheHSS1308 may implement an element of information (similar to an information element in Access Network Query Protocol (ANQP)) that may be used in a query-response type protocol to identify one or more selectively activated features that are activated, or authorized to be activated, at thedevice1302. The element of information may be used to facilitate responses to queries concerning what features (e.g., what selectively activated features) are available on the device1302 (e.g., client device, network access node, etc.). The element of information may be thought of as a parameter associated with an enhanced ANQP protocol, which may be referred to herein as a service query protocol (SQP).
• By way of example, a device1302 (e.g., a client device) may have a subscription permitting thedevice1302 to use the Internet, but not voice-over IP. Subscription information may be stored in a subscription profile of thedevice1302 at theHSS1308. A capability profile of the device may also be stored at theHSS1308. The capability profile may be associated with the subscription profile. Elements of information relating to the subscription information and capability profile may be sent to the network node1306 (e.g., MME) during an initial attachprocedure1326. It is noted that the initial attachprocedure1326 may occur infrequently.
• In the example, the network node1306 (e.g., MME) receiving the described element of information may configure the network such that thedevice1302 can use the Internet (e.g., as a first data service), but not voice over IP (e.g., as a second data service). The first exemplary method, which can make use of the authorization information stored in the capability profile of thedevice1302, associated with the subscription profile of thedevice1302, may therefore make use of a capability profile element. The capability profile element can be used to validate and enforce an authorization of thedevice1302 to use one or more selectively activated features that are needed to enable the network service. The authorization may ultimately be based on the authorization agreement obtained at the authorization server1312 (or in some aspects, the authorization agreement obtained at the local authorization server1310).
• The information from the capability profile of thedevice1302 stored at theHSS1308 may be used by a network node1306 (e.g., MME) to configure various network functions. The various network functions can enable thedevice1302 to make use of the one or more selectively activated features that may be activated (or may be authorized to be activated) at thedevice1302.
• FIG. 14 is an exemplary call flow diagram1400 illustrating another system level call flow that may be associated with validating proof of authority for a device1402 (e.g., chip component, client device, network node) to use a first set of selectively activated features identified in an authorization certificate stored at thedevice1402 in accordance with aspects described herein. Illustrated are a device1402 (e.g., chip component, client device, network node), a radio access network (RAN)1404 (e.g., one or more eNBs and/or access points), and a network node1406 (exemplified inFIG. 14 as an MME). The exchanges described below, which occur between thenetwork node1406 exemplified as an MME and thedevice1402 may be performed between anydevice1402 and network node (e.g., network access node, eNB, MME, S-GW, P-GW). It is noted that while an operation of configuring thedevice context1426 may be applicable for anetwork node1406 such as an MME, the operation of configuring thedevice context1426 may not be applicable for other examples of network nodes such as an eNB. Accordingly, the operation of configuring thedevice context1426 and the RAN1404 (which can be the recipient of the operation of configuring the device context1426) are depicted in broken line form because they are applicable for the example ofFIG. 14, where thenetwork node1406 is exemplified as an MME, but may not be applicable for other examples (e.g., where thenetwork node1406 is a node other than an MME).
• As described above, during feature activation for example, the device1402 (e.g., client device) may obtain proof of authority for thedevice1402 to use a first set of selectively activated features at the device1402 (e.g. first authorization information, which may be in the form of an authorization certificate, signed by a first authorization server) and an authorization file includingfeature activation keys1408. The network node1406 (e.g., MME) may use the first authorization information (e.g., an authorization certificate) to validate the authority of thedevice1402 to use a network service. Similarly, the network node1406 (e.g., MME) may obtain proof of authority for thenetwork node1406 to use a second set of selectively activated features at the network node1406 (e.g. second authorization information, which may be in the form of an authorization certificate, signed by a second authorization server)1410. The device1402 (e.g., client device) may use the second authorization information (e.g., an authorization certificate) to validate the authority of thenetwork node1406 to provide a network service.
• The first authorization information (e.g., an authorization certificate) may identify the selectively activated features authorized to thedevice1402 and may be signed by the first authorization server using the private key of the first authorization server. The first authorization information (e.g., authorization certificate) may also include the identity of thedevice1402 and may also include an expiration time of the authorization certificate. The authorization file may include feature activation keys and associated parameters and maybe encrypted with the public key of thedevice1402. In some implementations, thedevice1402 obtains the first authorization information (e.g., an authorization certificate) and the authorization file during feature activation.
• The first authorization information (e.g., an authorization certificate) may be used with a corresponding identity certificate that includes, for example, a device identifier and a public key of thedevice1402, signed by the first authorization server. The identity certificate may remain valid even upon the deactivation of one or more selectively activated features from thedevice1402. In one aspect, the device identifier may be, for example, a device serial number or an International Mobile Station Equipment Identity (IMEI). In implementations herein, the device identifier may always be associated with the device public key so that thedevice1402 can prove its ownership of the device identifier.
• In one aspect, the public key of the device1402 (or a hash of the public key) may be used as a device identifier. In this case, the identity certificate can be unnecessary, yet the identity of thedevice1402 should be able to be verified through the first authorization server and/or local authorization server and/or a third entity.
• The first authorization information (e.g., an authorization certificate) may be obtained by thedevice1402 from a local authorization server. In this case, thedevice1402 may obtain a certificate of the local authorization server, for example, during the feature activation.
• Thedevice1402 may send an attachrequest1412 to thenetwork node1406. In an aspect, the attach request may be understood to be, or to include, a request to use a network service. In response, the network node1406 (e.g., MME) may send arequest1414, to thedevice1402, for proof of authority for thedevice1402 to use the first set of selectively activated features at thedevice1402, where the first set of selectively activated features includes first selectively activated features needed by thedevice1402 to use the network service. In other words, the network node1406 (e.g., MME) may send arequest1414, to thedevice1402, for the proof of authority for the device (e.g., the first authorization information, which may be in the form of an authorization certificate). In an aspect, such arequest1414 may be sent during an authentication and key agreement (AKA) procedure. Thedevice1402 may send1416, to thenetwork node1406, in response to therequest1414, the proof of authority for thedevice1402.
• Mutual authentication1418 may occur between thedevice1402 and thenetwork node1406. Themutual authentication1418 can be optional.Mutual authentication1418 may be implemented to provide assurance that thedevice1402 andnetwork node1406 are communicating with a correct entity by establishing a secure channel. It is noted that mutual authentication1418 (e.g., remote attestation) with thedevice1402 is different from an AKA procedure that is used for thedevice1402 to register to a network.
• It is additionally noted that, in some examples,mutual authentication1418 may be implemented before thenetwork node1406 sends therequest1414, to thedevice1402, for proof of authority for thedevice1402. For example, if thenetwork node1406 is an MME (as exemplified inFIG. 14), once the AKA procedure is completed, thedevice1402 and the MME can communicate with each other over a secure transport (i.e., NAS messages). Consequently, thedevice1402 and MME may authenticate each other.
• In one aspect, the network node1406 (e.g., MME) may request thedevice1402 to send integrity information (e.g., software integrity information of the authorization function of the device1402) created during a secure/authenticated boot process of thedevice1402. By way of example, in a case where integrity information is obtained during the secure/authenticated boot process, the integrity information may be used to prove the integrity of the software running in thedevice1402. In one aspect, the network node1406 (e.g., MME) may make a request for integrity information during mutual authentication1418 (e.g., remote attestation) with thedevice1402. The integrity information may be used during mutual authentication.
• The network node1406 (e.g., MME) may validate1420 the proof of authority for thedevice1402 to use the first set of selectively activated features at the device (e.g., the first authorization information). Validation may be performed by validating the proof of authority for the device1402 (e.g., the first authorization information) using the authorization server public key (or using the public key of the local authorization server if the local authorization server created the proof of authority for the device1402). In addition, in an aspect, thenetwork node1406 may verify1422 that thedevice1402 that sent the proof of authority for the device1402 (e.g., the first authorization information) holds the private key that corresponds to the public key of thedevice1402 included with the proof of authority for the device1402 (e.g., the first authorization information). Verification may be performed, for example, by validating a signature of thedevice1402 that may be sent with the proof of authority for the device1402 (e.g., the first authorization information) using the public key of thedevice1402 included with the proof of authority for the device1402 (e.g., the first authorization information).
• If, as in the exemplary illustration ofFIG. 14, the network node is an MME, then, if both thevalidation1420 andverification1422 are successful, the network node1406 (e.g., MME) may implement an operation of configuring thedevice context1426 to implement the use of the network service at theRAN1404. In one example, thenetwork node1406 may configure theRAN1404 such that thedevice1402 can use the authorized selectively activated features, if the network node is, for example, an MME. In another example, thenetwork node1406 may configure theRAN1404 such that thedevice1402 can only use the authorized selectively activated features, if the network node is, for example, an MME.
• However, as noted above, if the network node was an eNB, then the operation of configuring thedevice context1426 may not be applicable. Accordingly, the operation of configuring thedevice context1426 and theRAN1404 are depicted in broken line form.
• According to some aspects, if both thevalidation1420 andverification1422 are successful, then thenetwork node1406 may verify that the selectively activated features needed to be used by thedevice1402 to obtain the network service match the selectively activated features activated at thedevice1402 according to the first authorization information. In other words, an optional operation of confirming activation of needed selectively activatedfeatures1423 may take place. In an aspect, confirming activation of needed selectively activatedfeatures1423 may involve identifying a needed set of selectively activated features needed by thedevice1402 to use the network service, and sending aresponse1424 to the request based on determining whether the needed set of selectively activated features is included in a first set of selectively activated features, where the first set of selectively activated features is a set of selectively activated features identified in the proof of authority for the device (e.g., the first authorization information).
• In an aspect, identifying the needed set of selectively activated features may include deriving selectively activated features needed by thedevice1402 to use the network service from a model-specific and/or a device-specific list of authorized selectively activated features maintained by the first authorization server. In another aspect, identifying the needed set of selectively activated features may include deriving selectively activated features needed by thedevice1402 to use the network service from a model-specific and/or a device-specific list of licensable selectively activated features maintained by the first authorization server.
• In an aspect, thenetwork node1406 may send aresponse1424 indicative of a grant of the attach request.
• The aspects described herein permit thenetwork node1406 to validate the right of thedevice1402 to use a network service; however, they also permit thedevice1402 to validate the right of anetwork node1406 to provide the network service. Some networks nodes may falsely advertise the availability of features (e.g., selectively activated features) to adevice1402. In actuality, a certain feature may not be activated even though the network node advertises to the contrary. If the network does not provide the advertised feature or service to thedevice1402, the network may charge thedevice1402 more by using, for example, an inferior service. Therefore, thedevice1402 has an interest in verifying that a network node that advertises a feature is authorized to provide that feature. Once thedevice1402 verifies that the network is authorized to provide the feature, and thereby confirms that the feature is available at the network, thedevice1402 can couple to the network and use the network service.
• Accordingly, thedevice1402 may send1428 a request for proof of authority for the network node to provide the network service. In response, thenetwork node1406 may send1430 proof of authority for the network node to use a second set of selectively activated features at the network node (e.g., second authorization information), signed by a second authorization server, where the second set of selectively activated features includes second selectively activated features needed by the network node to provide the network service. Thedevice1402 may validate1432 the second authorization information (e.g., a second authorization certificate) sent to thedevice1402 by thenetwork node1406. Validation may be performed using the second authorization server public key (or using the public key of a second local authorization server if the second local authorization server created the proof of authority for the network node1406).
• In addition, in an aspect, thedevice1402 may verify1434 that thenetwork node1406 that sent the proof of authority for the network node1406 (e.g., the second authorization information) holds the private key that corresponds to the public key of thenetwork node1406 included with the proof of authority for the network node1406 (e.g., the second authorization information). Verification may be performed, for example, by validating a signature of thenetwork node1406 that may be sent with the proof of authority for the network node1406 (e.g., the second authorization information) using the public key of thenetwork node1406 included with the proof of authority for the network node1406 (e.g., the second authorization information).
• According to some aspects, if both the validation1432 andverification1434 are successful, then thedevice1402 may verify that the selectively activated features needed to be used by thenetwork node1406 to provide the network service match the selectively activated features activated at thenetwork node1406 according to the second authorization information. In other words, an optional operation of confirming that the network node is authorized to provide thenetwork service1436 may take place. In an aspect, confirming that the network node is authorized to provide thenetwork service1436 may involve identifying a third set of selectively activated features needed by thenetwork node1406 to use the network service, and using the network service based on determining whether the third set of selectively activated features is included in a second set of selectively activated features, where the second set of selectively activated features are identified in the proof of authority for the network node1406 (e.g., the second authorization information). In an aspect, if validation1432,verification1434, and confirming that the network node is authorized to provide thenetwork service1436 are successful, thedevice1402 may use the network service offered by thenetwork node1406.
Exemplary Device
• FIG. 15 is a block diagram illustrating an exemplary device1500 (e.g., chip component, client device, a network node) configured to support dynamic verification and enforcement of authorization agreements, where enforcement includes dynamic validation of proof of authority for a device to use a set of selectively activated features and activation/deactivation of selectively activated features in accordance with the terms of the authorization agreements, in accordance with aspects described herein. In one example, theexemplary device1500 may include anetwork communication circuit1502, aprocessing circuit1504, and a memory circuit/storage device (referred to herein as memory circuit1506). Thenetwork communication circuit1502,processing circuit1504, andmemory circuit1506 may be coupled to acommunication bus1508 for exchange of data and instructions.
• Thenetwork communication circuit1502 may include a first input/output circuit/function/module1510 for input/output operations with a user. Thenetwork communication circuit1502 may include a second input/output circuit/function/module1511 (e.g., a receiver/transmitter module/circuit/function) for wireless communication. Other circuits/functions/modules may be included with thenetwork communication circuit1502 as will be appreciated by those of skill in the art.
• Theprocessing circuit1504 may be configured to include or implement one or more processors, application specific processors, hardware and/or software modules, etc., that are configured to support dynamic verification and enforcement of authorization agreements, where enforcement includes dynamic validation of proof of authority for a device to use a set of selectively activated features and activation/deactivation of selectively activated features in accordance with the terms of the authorization agreements. Theprocessing circuit1504 may be configured to include an authorization function circuit/function module1512, an authorization certificate verification circuit/function module1514, an authorization parameter evaluation circuit/function module1516, and a feature activation key extraction circuit/function module1518. Other circuits/functions/modules may be included with theprocessing circuit1504 as will be appreciated by those of skill in the art.
• Thememory circuit1506 may be configured to includeauthorization instructions1520, authorizationcertificate verification instructions1522, authorizationparameter evaluation instructions1524, and feature activationkey extraction instructions1526. A separate portion of thememory circuit1506 may be configured to support secure storage. Accordingly, thememory circuit1506 may further include asecure storage circuit1528. Thesecure storage circuit1528 may include privatekey storage1530. Theprivate key storage1530 may store the private key of a public/private key pair, where an authorization server or local authorization server uses the public key of the public/private key pair to encrypt an authorization certificate. Thesecure storage circuit1528 may further include featureactivation key storage1532. Thememory circuit1506 may further store a listing of selectively activatedfeatures1534 as well as a listing of authorization parameters for each of the selectively activated features of thedevice1536. Other instructions and locations for storage of data may be included in thememory circuit1506 as will be appreciated by those of skill in the art.
Exemplary Methods of Verification/Enforcement of Authorization Agreements
• FIG. 16 is a flowchart of anexemplary method1600 operational at a device (e.g., chip component, client device, network node) in accordance with aspects described herein. In one aspect, the device may be similar to theexemplary device1500 ofFIG. 15 and/ordevice302 ofFIG. 3. Prior to implementing theexemplary method1600, the device may have determined a set of one or more selectively activated features associated with use of a network service. Prior to implementing theexemplary method1600, the device may have sent (to an authorization server or a local authorization server) a feature activation request (e.g., a request for authorization to activate the one or more selectively activated features). The feature activation request, or some other event, may act as a trigger event that can cause the authorization server (or local authorization server) to send the device proof of authority for the device to use a first set of selectively activated features at the device, signed by a first authorization server.
• The device may obtain proof of authority for the device to use a first set of selectively activated features at the device, signed by afirst authorization server1602. The proof of authority for the device may be referred to herein as authorization information. The proof of authority for the device may include an authorization certificate. The proof of authority for the device may be obtained with an authorization file. The authorization file may include authorization parameters and one or more feature activation keys. As described herein, the device may have validated the authorization certificate, verified that the authorization server sending the proof of authority for the device was a correct (e.g., not an imposter) authorization server, decrypted the feature activation keys, and used the decrypted feature activation keys to active the first set of selectively activated features at the device.
• The device may send a request to use a network service to anetwork node1604. The first set of selectively activated features may include first selectively activated features needed by the device to use the network service. The first selectively activated features may be authorized to be activated at the device by the proof of authority obtained from the authorization server. According to some aspects, some or all of the first selectively activated features may be activated at the device on or before the time the device sends the request to use the network service.
• The device may obtain, from the network node, in response to sending the request to use the network service, a request for the proof of authority for thedevice1606. In response, the device may send, to the network node, the proof of authority for the device (e.g., the proof of authority for the device to use the first set of selectively activated features at the device, signed by the first authorization server)1608.
• The device may send, to the network node, a request for proof of authority for the network node to provide thenetwork service1610.
• Optionally, the device may senddevice integrity information1612. The device integrity information may have been obtained during a secure boot process. Still further optionally, the device may perform mutual authentication (e.g. remote attestation) between the device and a network node validating the request to use thenetwork service1614.
• Optionally, the device may obtain a response granting the request to use thenetwork service1616. The response may be in response to sending the proof of authority for the device to use the first set of selectively activated features at the device, signed by the first authorization server.
• The device may obtain, from the network node, proof of authority for the network node to use a second set of selectively activated features at the network node, signed by asecond authorization server1618. The second set of selectively activated features may include second selectively activated features needed by the network node to provide the network service.
• The device may validate the proof of authority for the network node before using thenetwork service1620.
• In some aspects, the proof of authority for the device may be obtained by the device from an authorization server (e.g., the proof of authority for the device originated at the authorization server). In some aspects, the proof of authority for the device may be obtained by the device from a local authorization server (e.g., the proof of authority for the device originated at the local authorization server). In some aspects, proof of authority for the device may include an authorization certificate. In some aspects, the proof of authority for the device may be obtained from an authorization server, or local authorization server, during a feature activation process (e.g., during activation of the selectively activated features needed to use the network service at the device).
• According to some aspects, the device may be a chip component, a client device, a network access node, a mobility management entity, or a gateway device. According to an aspect, the device may be a client device or a chip component, and the network node may be a network access node. In one aspect, the proof of authority for the device originates at the first authorization server, is signed with a private key of the first authorization server, and includes a listing of the first selectively activated features. In such an aspect, the method may further include validating the proof of authority for the device by validating the listing of the first selectively activated features using a public key of the first authorization server. The method may still further include obtaining feature activation keys associated with the first selectively activated features, encrypted with a public key of the device. The method may still further include decrypting the feature activation keys, using a private key of the device, known only to the device. The method may still further include activating and/or maintaining activation of the first selectively activated features with the feature activation keys.
• According to one aspect, the proof of authority for the network node may originate at the second authorization server, is signed with a private key of the second authorization server, and includes a listing of the second selectively activated features. In such an aspect, the method may also include validating the proof of authority for the network node by validating the listing of the second selectively activated features using a public key of the second authorization server.
• According to some aspects, the first authorization server may be a local authorization server.
• In one aspect, the method may also include identifying a third set of selectively activated features needed by the network node to use the network service, and using the network service based on determining whether the third set of selectively activated features is included in the second set of selectively activated features.
• In still another aspect, the proof of authority for the device may originate at the first authorization server and is obtained, at the device, from the first authorization server, while the proof of authority for the network node originates at the second authorization server and is obtained, at the device, from the network node.
• In some aspects, the first authorization server and the second authorization server are one authorization server.
• In one aspect, the proof of authority for the device may be obtained from the first authorization server during a feature activation process, during which the device obtains authorization to activate the first selectively activated features.
• In one example, the proof of authority for the network node is obtained from the network node during an authentication and key agreement (AKA) process.
• In one aspect, the proof of authority for the device can be data representative of an authorization certificate. In one aspect, the proof of authority for the device can be data representative of an authorization agreement indicating that the device is authorized to activate the first selectively activated features.
• According to one aspect, the first authorization information may include, for each of the selectively activated features authorized to be activated at the device, a date upon which authorization to activate the selectively activated feature will expire.
• FIG. 17 is a flowchart of anexemplary method1700 operational at a device (e.g., ship component, client device, network node) in accordance with aspects described herein. In one aspect, the device may be similar to theexemplary device1500 ofFIG. 15. The device may obtain information identifying capability of a network access node to provide anetwork service1702. The information may be received in any suitable manner. For example, the information may be received in the form of an advertisement from the network access node (e.g., eNB). The advertisement may advertise network capability via an over-the-air broadcast (e.g., advertise via information presented in a system information block (SIB)). As another example, the information may be received in a response to an access network query protocol (ANQP) or a service query protocol (SQP) query. The network capability may include, for example, a network service offered by the network access node.
• The device may obtain, from the network access node, authorization information to verify authority of the network access node to offer thenetwork service1704. In one aspect, the authorization information may be in the form of an authorization certificate. An authorization server (or local authorization server) may have sent the authorization certificate to the network access node. The device may obtain the authorization information by, for example, sending a request to the network access node to send authorization information to verify that the network access node is authorized to provide the network service.
• The device may validate theauthorization information1706 to validate the network access node and/or the authority of the network access node to provide the network service. In some aspects, the authorization information may be validated by validating the authorization certificate. In some aspects, if an authorization server issued the authorization certificate, the authorization certificate may be validated using a public key of the authorization server. In some aspects, if a local authorization server issued the authorization certificate, the authorization certificate may be validated using a public key of the local authorization server. The device may determine if validation of the authorization information was successful1708. If the device determines that the validation of the authorization information was successful, the device may use1710 the network service. If the device determines that the validation of the authorization information was not successful, the device may not use1712 the network service.
• FIG. 18 is a flowchart of anexemplary method1800 operational at a network node (e.g., network access node, eNB, MME, S-GW, P-GW) in accordance with aspects described herein. In one aspect, the network node may be similar to theexemplary device1500 ofFIG. 15. The network node can obtain a request, from a device, to use anetwork service1802. The network node can also obtain, from the device, proof of authority for the device to use a first set of selectively activated features at the device, signed by anauthorization server1804.
• The network node may validate the proof of authority for thedevice1806. That is, the network node may validate the proof of authority for the device to use the first set of selectively activated features at the device, signed by the authorization server. The network node may validate the proof of authority for the device in order to validate the authority of the device to use the first set of selectively activated features at the device. The first set of selectively activated features may be needed by the device to use the network service. In some aspects, the proof of authority for the device may be validated by validating an authorization certificate. In some aspects, where an authorization server issued the authorization certificate, the authorization certificate may be validated using a public key of the authorization server. In some aspects, where a local authorization server issued the authorization certificate, the authorization certificate may be validated using a public key of the local authorization server.
• The network node may independently identify features needed by the device to use the network service, and thereafter compare the first set of selectively activated features to the independently identified features needed by the device to use the network service. The network node may determine that the device is able to use the network service if the independently identified features match the first set of selectively activated features.
• Accordingly, the network node may identify a second set of selectively activated features needed by the device to use thenetwork service1808. According to an aspect, the network node may identify the second set of selectively activated features by obtaining or deriving the features from a model-specific list of authorized selectively activated features maintained by an authorization server (or local authorization server), a device-specific list of authorized selectively activated features maintained by an authorization server (or local authorization server), or a model-specific and device-specific list of authorized selectively activated features maintained by an authorization server (or local authorization server). According to another aspect, the network node may identify the second set of selectively activated features by obtaining or deriving the features from a model-specific list of licensable selectively activated features maintained by an authorization server (or local authorization server), a device-specific list of licensable selectively activated features maintained by an authorization server (or local authorization server), or a model-specific and device-specific list of licensable selectively activated features maintained by an authorization server (or local authorization server).
• The network node may send a response to the request based on results of validating the proof of authority for the device and determining whether the second set of selectively activated features is included in the first set of selectively activated features1810. If the features independently identified by the network node (i.e., the second set of selectively activated features) are included in, or are a subset of, the first set of selectively activated features authorized to be activated at the device, and the proof of authority for the device to use the first set of selectively activated features at the device is successfully verified, the response to the request to use the network service may indicate that the device is permitted to use the network service.
• However, if the second set of selectively activated features is not included in the first set of selectively activated features or if the proof of authority for the device is not successfully validated, the network node may ignore the request to use the network service or may send a response to indicate that the device is not permitted to use the network service
• According to some aspects, the network node may be a network access node (e.g., an eNB), a mobility management entity, and/or a gateway device.
• In an aspect, the first set of selectively activated features includes first selectively activated features, and the proof of authority for the device originates at the authorization server. The proof of authority for the device can include a listing of the first selectively activated features, signed with a private key of the authorization server. In an example, the method can further include validating the proof of authority for the device by validating the listing of the first selectively activated features using a public key of the authorization server.
• In an aspect, the proof of authority for the device originates at the authorization server and can be obtained, at the network node, from the device. In another aspect, the proof of authority for the device originates at the authorization server and can be obtained, at the network node, in a form of a capability profile of the device, from a home subscriber server (HSS). In another aspect, the proof of authority for the device can be obtained from the device during an authentication and key agreement (AKA) process. In some aspects, the proof of authority for the device can be data representative of an authorization certificate. In still other aspects, the proof of authority for the device can be data representative of an authorization agreement indicating that the device is authorized to activate the first set of selectively activated features.
• In one example, identifying the second set of selectively activated features can include the network node deriving selectively activated features needed by the device to use the network service from a model-specific and/or a device-specific list of authorized selectively activated features maintained by the authorization server. In another example, identifying the second set of selectively activated features can include the network node deriving selectively activated features needed by the device to use the network service from a model-specific and/or a device-specific list of licensable selectively activated features maintained by the authorization server.
• In an aspect, the method can further include verifying that the device holds a private key that corresponds to a public key of the device included with the proof of authority for the device, where sending the response to the request can be further based on a result of the verifying.
• In some aspects, the method may further include receiving integrity information of the device. In such aspects, the response to the request may be further based on determining whether the integrity information is acceptable. According to some aspects, the device capability profile may include device integrity information created during a secure boot process, an authenticated boot process, or a secure and authenticated boot process. In one example, the device integrity information may prove the integrity of an authorization circuit/function/module of the device.
• In some aspects, the proof of authority for the device may have originated (e.g., first been obtained, first been derived) at an authorization server, a local authorization server, or an authorization server and a local authorization server. The authorization server and the local authorization server may be different from an authorization, authentication, and accounting (AAA) server. The authorization server and the local authorization server may be different from a home subscriber server (HSS).
• According to some aspects, the proof of authority for the device to use a first set of selectively activated features at the device, includes, for each of the selectively activated features, a date upon which authorization to activate the selectively activated feature will expire.
• In one aspect, the proof of authority for the device to use the first set of selectively activated features at the device may be obtained by the network node from the device at a suitable time. As one example, the proof of authority for the device may be obtained from the device when the device attaches to a network. As another example, the proof of authority for the device may be obtained from an authorization server or a local authorization server during a feature activation process.
• In one example, the proof of authority for the device to use a first set of selectively activated features at the device, may be sent to a home subscriber server (HSS). In some implementations, the authorization status of a selectively activated feature of a device (e.g., status indicative of whether the selectively activated feature is authorized and activated) may be sent to the HSS. The proof of authority for the device, the authorization status of selectively activated features of the device, or the proof of authority for the device and the authorization status of selectively activated features of the device may be used to update a capability profile of the device, where the capability profile can be stored at the HSS.
• In an aspect, obtaining the capability profile of the device from the HSS may permit the network node (e.g., eNB, MME, S-GW, P-GW) to validate the authorization of a device to use a selectively activated feature without a need for the network node to obtain another form of proof (e.g., may obviate a need for the network node to obtain, from the device, proof of authority for the device to use a first set of selectively activated features at the device).
• In some implementations, the network node can create and/or change a device context (e.g., a UE context) based on the capability profile of the device. According to some aspects, the HSS may send an information element identifying selectively activated features authorized to be activated at the device. In an aspect, the information element can include the capability profile of the device. The HSS may send the information element to the network node. According to some aspects, the network node may activate and/or deactivate selectively activated features based on changes to the capability profile of the device stored at the HSS. The selectively activated features may be selectively activated features of the network node. The activation and/or deactivation of selectively activated features based on changes to the capability profile of the device stored at the HSS may facilitate creating and/or changing the device context (e.g., a UE context).
• FIG. 19 is a flowchart of anotherexemplary method1900 operational at a network node (e.g., network access node, eNB, MME, S-GW, P-GW) in accordance with aspects described herein. In one aspect, the network node may be similar to theexemplary device1500 ofFIG. 15. The network node can obtain a request, from a device, to use anetwork service1902. The network node can also obtain proof of authority for the device to use a first set of selectively activated features at the device, signed by anauthorization server1904.
• The network node may validate the proof of authority for thedevice1906. In some aspects, the proof of authority for the device may be validated by validating an authorization certificate. In some aspects, where an authorization server issued the authorization certificate, the authorization certificate may be validated using a public key of the authorization server. In some aspects, where a local authorization server issued the authorization certificate, the authorization certificate may be validated using a public key of the local authorization server.
• The network node may also verify that the device (that sent the proof of authority for the device) holds a private key that corresponds to a public key of the device included with the proof ofauthority1908. In this way, the network node can verify that the device that sent the proof of authority is the device identified in the proof of authority. In some aspects, verifying that the device holds the private key that corresponds to the public key of the device included with the proof of authority, can involve validating a signature of the device (made by the device with the private key of the device), using the public key of the device included with the proof of authority.
• The network node may determine if validation of the proof of authority for the device and verification of the device were successful1910. If the network node determines that the validation of the proof of authority for the device, verification of the device, or both validation of the proof of authority for the device and verification of the device were not successful, the network node may ignore the request to use the network service or may send a response denying the request to use thenetwork service1912.
• If the network node determines that both validation of the proof of authority for the device and verification of the device were successful, the network node may identify features needed by the device to use thenetwork service1914. In one example, the network node may make the identification independently.
• A listing of a first set of selectively activated features authorized to be activated at the device can be obtained from the proof of authority for the device. The network node may compare selectively activated features listed in the proof of authority to the identified features needed by the device to use thenetwork service1916.
• A determination may be made as to whether the selectively activated features included in the proof of authority for the device match the features identified by thenetwork node1918. A response based on the determination may then be sent. When the features match, the network node may send a response granting the request to use thenetwork service1920. When the features do not match, the network node may either ignore the request to use the network service or may send a response denying the request to use thenetwork service1922.
Exemplary Home Subscriber Server (HSS)
• FIG. 20 is a block diagram illustrating an exemplary home subscriber server (HSS)2000 configured to support verification and enforcement of authorization agreements in accordance with aspects described herein. In one example, theexemplary HSS2000 may include anetwork communication circuit2002, aprocessing circuit2004, and a memory circuit/storage device (referred to herein as memory circuit2006). Thenetwork communication circuit2002,processing circuit2004, andmemory circuit2006 may be coupled to acommunication bus2008 for exchange of data and instructions.
• Thenetwork communication circuit2002 may include a first input/output circuit/function/module2010 for input/output operations. Other circuits/functions/modules may be included with thenetwork communication circuit2002 as will be appreciated by those of skill in the art.
• Theprocessing circuit2004 may be configured to include or implement one or more processors, application specific processors, hardware and/or software modules, etc., that are configured to support validation and/or enforcement of authorization agreements. Theprocessing circuit2004 may be configured to include an HSS operations circuit/function/module2012 to implement the functionality of the HSS. Theprocessing circuit2004 may also be configured to include an authorization function circuit/function module2014. Other circuits/functions/modules may be included with theprocessing circuit2004 as will be appreciated by those of skill in the art.
• Thememory circuit2006 may be configured to include storage space to store subscriptions profiles2016 andcapability profiles2017, for a plurality of devices. Thememory circuit2006 may also be configured to includeHSS operation instructions2018 and authorization circuit/function/module instructions, referred to herein asauthorization instructions2020. Other instructions and locations for storage of data may be included in thememory circuit2006 as will be appreciated by those of skill in the art.
• Communication betweennetwork communication circuit2002,processing circuit2004,memory circuit2006, and other components (not shown) of theexemplary HSS2000 may be through acommunication bus2008 or the like.
Exemplary Method Operational at Home Subscriber Server
• FIG. 21 illustrates anexemplary method2100 operational at a server (e.g., an HSS), which is related to validating the authorization for use of a set of one or more selectively activated features of a device (e.g., chip component, client device, network node) according to aspects described herein. The server may be similar to theexemplary HSS2000 ofFIG. 20.
• In theexemplary method2100, the server (e.g., HSS) may obtain a first list of selectively activated features of a device2102 (e.g., an obtained capability profile of the device).
• Information concerning a change to an authorization status of the device may be considered as information regarding a change to the capabilities of the device. The information concerning the change to the authorization status of the device may relate to a change to the authorization status of at least one selectively activated feature in a set of selectively activated features of the device.
• The server (e.g., HSS) can update a second list of selectively activated features of the device, stored at the server (e.g., HSS), based on thefirst list2104. The second list may be referred to as a stored capability profile of the device. According to an aspect, the second list, stored at the server (e.g., HSS), can be associated with a subscription profile of the device. The update to the second list of selectively activated features of the device, stored at the HSS, may reflect a change to an authorization status of at least one selectively activated feature in the second list.
• In one aspect, the first list of selectively activated features can originate at an authorization server and can be signed with a private key of the authorization server. According to such an aspect, the method may also include validating the first list of selectively activated features using a public key of the authorization server.
• The server (e.g., HSS) may obtain a query concerning the capability of the device. The server (e.g., HSS), according to an aspect described herein, may send, responsive to the query concerning capability of the device, a capability profile including the second list of selectively activated features of thedevice2106.
• According to one example, an HSS may obtain a query concerning capability of the device during an initial attach procedure. The query may be obtained from an MME. The HSS may send, responsive to the query, the capability profile including the second list to the MME. The capability profile may be associated with the subscription profile of the device.
• Alternatively, the HSS may obtain a request for a specific element of information stored at the HSS. The element of information may relate to a capability of the device. The element of information may relate to one or more selectively activated features identified in the second list of selectively activated features of the device (e.g., in the stored capability profile of the device).
• Using the example of the initial attach procedure, the HSS may send the capability profile of the first device (e.g., chip component, client device) to a second device (e.g., MME), so that the second device (e.g., MME) can configure various feature(s) to implement or compliment the selectively activated features already authorized/activated on the first device.
• The second device (e.g., MME) may validate the right of the first device to use one or more selectively activated features without a need for the second device (e.g., MME) to obtain proof of authority for the first device to use a first set of selectively activated features at the first device, signed by a first authorization server (e.g., authorization information in the form of an authorization certificate) from the first device. The proof of authority for the first device may be needed by the second device (e.g., MME) to validate the right of the first device to use the set of selectively activated features. In the alternate aspect, the proof may be obtained by the second device (e.g., MME) from the HSS and configured to the network without input from the first device. Accordingly, and for example, the use of a capability profile, and/or an element of information that may relate to a capability of the device, which may be obtained from the HSS using, for example, an enhanced access network query protocol or a service query protocol, may facilitate/speed-up/improve efficiency of an MME in validating and enforcing an authorization agreement.
• Specific implementations shown and described are only examples and should not be construed as the only way to implement the present disclosure unless specified otherwise herein. It is readily apparent to one of ordinary skill in the art that the various examples in the present disclosure may be practiced by numerous other solutions.
• The following provides an overview of aspects of the present disclosure:
• Aspect 1:
• One or more of the components, acts, features and/or functions described herein and illustrated in the drawings may be rearranged and/or combined into a single component, act, feature, or function or included in several components, acts, features, or functions. Additional elements, components, acts, and/or functions may also be added without departing from the disclosure. Algorithms described herein may also be efficiently implemented in software and/or embedded in hardware.
• In the description, elements, circuits, functions, and modules may be shown in block diagram form in order not to obscure the present disclosure in unnecessary detail. Conversely, specific implementations shown and described are exemplary only and should not be construed as the only way to implement the present disclosure unless specified otherwise herein. Additionally, block definitions and partitioning of logic between various blocks is exemplary of a specific implementation. For the most part, details concerning timing considerations and the like have been omitted where such details are not necessary to obtain a complete understanding of the present disclosure and are within the abilities of persons of ordinary skill in the relevant art.
• Also, it is noted that the examples may be described as a process that is depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.
• Those of ordinary skill in the art would appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout this description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof. Some drawings may illustrate signals as a single signal for clarity of presentation and description. It will be understood by a person of ordinary skill in the art that the signal may represent a bus of signals, wherein the bus may have a variety of bit widths and the present disclosure may be implemented on any number of data signals, including a single data signal.
• It should be understood that any reference to an element herein using a designation such as “first,” “second,” and so forth does not limit the quantity or order of those elements, unless such limitation is explicitly stated. Rather, the designations may be used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements may be employed there or that the first element should precede the second element in some manner. In addition, unless stated otherwise, a set of elements may comprise one or more elements. Furthermore, it should be understood that words used in the singular include the plural and words used in the plural include the singular.
• Moreover, a storage medium may represent one or more devices for storing data, including read-only memory (ROM), random access memory (RAM), magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine-readable mediums, processor-readable mediums, processing circuit readable mediums, and/or computer-readable mediums for storing information. The terms “machine-readable medium,” “processor-readable medium,” “processing circuit readable medium,” and/or “computer-readable medium” may include, but are not limited to non-transitory mediums such as portable or fixed storage devices, optical storage devices, and various other mediums capable of storing, containing, or carrying instruction(s) and/or data. Thus, the various methods described herein may be fully or partially implemented by instructions and/or data that may be stored in a machine-readable medium, processor-readable medium, processing circuit readable medium, and/or computer-readable medium and executed by one or more processors, processing circuits, machines, and/or devices.
• Furthermore, aspects may be implemented by hardware, software, firmware, middleware, microcode, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the tasks may be stored in a machine-readable medium such as a storage medium or other storage(s). A processing circuit may perform the tasks. A code segment may represent a process, a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing, forwarding, or transmitting information, data, arguments, parameters, or memory contents. Information, data, arguments, parameters, or memory contents, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
• The various illustrative logical blocks, elements, circuits, modules, functions, and/or components described in connection with the examples disclosed herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic component, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the general-purpose processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing components, e.g., a combination of a DSP and a microprocessor, a number of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. A general-purpose processor, configured for executing aspects described herein, is considered a special-purpose processor for carrying out such aspects. Similarly, a general-purpose computer is considered a special-purpose computer when configured for carrying out aspects described herein.
• The methods or algorithms described in connection with the examples disclosed herein may be included directly in hardware, in a software module executable by a processor, or in a combination of both, in the form of processing unit, programming instructions, or other directions, and may be contained in a single device or distributed across multiple devices. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium appreciated by those of skill in the art. A storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.
• Those of skill in the art would further appreciate that the various illustrative logical blocks, circuits, functions, modules, and algorithms described in connection with the examples described herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative elements, components, blocks, circuits, functions, modules, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, software, or a combination thereof depends upon the particular application and design selections imposed on the overall system.
• The various features of the disclosure described herein can be implemented in different systems without departing from the disclosure. It should be noted that the foregoing aspects are merely examples and are not to be construed as limiting the disclosure. The descriptions of examples of the teachings of the disclosure are intended to be illustrative, and not to limit the scope of the claims. As such, the present teachings can be readily applied to other types of apparatuses and many alternatives, modifications, and variations will be apparent to those skilled in the art.

Claims (20)

What is claimed is:

1. A method operational at a server, comprising:

obtaining a first list of selectively activated features of a device; and

updating a second list of selectively activated features of the device, stored at the server, based on the first list, wherein the second list is associated with a subscription profile of the device, to reflect a change to an authorization status of at least one selectively activated feature in the second list.

2. The method ofclaim 1, wherein the server is a home subscriber server (HSS).

3. The method ofclaim 1, further comprising:

sending, responsive to a query concerning capability of the device, a capability profile including the second list of selectively activated features of the device.

4. The method ofclaim 1, wherein the first list of selectively activated features originates at an authorization server and is signed with a private key of the authorization server;

the method further comprising:

validating the first list of selectively activated features using a public key of the authorization server.

5. The method ofclaim 4, wherein the authorization server is a local authorization server.

6. The method ofclaim 1, wherein the first list of selectively activated features is data representative of an authorization certificate signed by an authorization server.

7. The method ofclaim 1, wherein the first list of selectively activated features is data representative of an authorization agreement indicating that the device is authorized to activate the selectively activated features.

8. A server comprising:

a network communication circuit for communicating over a network; and

a processing circuit coupled to the network communication circuit, wherein the processing circuit is configured to:

obtain a first list of selectively activated features of a device; and

update a second list of selectively activated features of the device, stored at the server, based on the first list, wherein the second list is associated with a subscription profile of the device, to reflect a change to an authorization status of at least one selectively activated feature in the second list.

9. The server ofclaim 8, wherein the server is a home subscriber server (HSS).

10. The server ofclaim 8, wherein the processing circuit is further configured to:

send, responsive to a query concerning capability of the device, a capability profile including the second list of selectively activated features of the device.

11. The server ofclaim 8, wherein the first list of selectively activated features originates at an authorization server and is signed with a private key of the authorization server, and the processing circuit is further configured to:

validate the first list of selectively activated features using a public key of the authorization server.

12. The server ofclaim 11, wherein the authorization server is a local authorization server.

13. The server ofclaim 8, wherein the first list of selectively activated features is data representative of an authorization certificate signed by an authorization server.

14. The server ofclaim 8, wherein the first list of selectively activated features is data representative of an authorization agreement indicating that the device is authorized to activate the selectively activated features.

15. A server, comprising:

means for obtaining a first list of selectively activated features of a device; and

means for updating a second list of selectively activated features of the device, stored at the server, based on the first list, wherein the second list is associated with a subscription profile of the device, to reflect a change to an authorization status of at least one selectively activated feature in the second list.

16. The server ofclaim 15, wherein the server is a home subscriber server (HSS).

17. The server ofclaim 15, further comprising:

sending, responsive to a query concerning capability of the device, a capability profile including the second list of selectively activated features of the device.

18. The server ofclaim 15, wherein the first list of selectively activated features originates at an authorization server and is signed with a private key of the authorization server;

the server further comprising:

means for validating the first list of selectively activated features using a public key of the authorization server.

19. The server ofclaim 15, wherein the first list of selectively activated features is data representative of an authorization certificate signed by an authorization server.

20. The server ofclaim 15, wherein the first list of selectively activated features is data representative of an authorization agreement indicating that the device is authorized to activate the selectively activated features.

Images