Patent Grant
11973804
Network service plans have conventionally been developed by teams of technical specialists, each expert in the operation and programming of a respective subset of network appliances deployed to implement a given aspect of service policy. After the broad outline of a new plan offering is agreed upon, for example, separate teams of control policy and accounting policy specialists are typically tasked with developing control policies and accounting policies, respectively, required to implement the new plan, and programming individual network appliances to execute the control and accounting functions required by those policies.
Unfortunately, the divergent appliance-level destinations for control and accounting policy instructions tend to disjoin the development and implementation of those policies, yielding silos of development and implementation effort, which significantly slows the deployment of new service plans and often leads to less cogent plan design and implementation. New plans typically take many months and hundreds of development/implementation hours in the path from drawing board to implementation.
The various embodiments disclosed herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
An integrated network-service design environment that enables centralized, unified, coordinated development of access-control, service-accounting and service-notification policies, and automated translation of developed service policies into provisioning instructions for a diverse variety of network elements and/or end-user devices is disclosed in various embodiments. In a number of embodiments, for example, classification objects and policy events are defined and/or organized in multiple hierarchical levels ranging from base-level classification objects to complete catalogs of service plans. This hierarchical organization allows for the ascendant inheritance of object properties through the hierarchy (i.e., elements at higher levels of the hierarchy can inherit or take on one or more properties of elements at lower levels of the hierarchy) and normalizes the collection of design elements at each hierarchical level, enabling, for example, a single design element to be included in multiple design elements at higher hierarchical levels, thus streamlining service plan development and simplifying revision and testing. In further embodiments, the integrated design environment contemplates concurrent activation and implementation of “overlapping” service plans for a single end-user device. For example, an end-user device may be associated with or subscribed to more than one active service plan at a time, and, in such cases, more than one active service plan may allow for a particular device activity (e.g., access to a particular web site could be allowed by a service plan providing for unrestricted Internet access, and it could also be allowed by a second service plan that provides for access to the particular web site). The integrated design environment enables plan designers to define control and/or accounting priorities of those plans relative to each other or even to delegate prioritization choices to subscribers or end-users (i.e., service consumers or parties associated with a service account, such as parents, device group managers (e.g., virtual service providers, mobile network operators (MNOs), mobile virtual network operators (MVNOs), etc.), enterprise information technology (IT) managers, administrators, etc.). The integrated design environment may also permit definition of “multi-match” classification and the triggering of multiple policy events per match to effect a richer set of end-user device features and performance than is possible with more conventional classification schemes. In yet further embodiments, the integrated design environment enables designers to define and control end-user discovery of available services, for example, through organization and featuring of plans and promotions on end-user devices, and definition of offers to be presented in response to detecting an attempted access for which a compatible plan is lacking. The integrated design environment may also facilitate definition and management of a broad variety of subscriber groups (and/or sets of end-user devices), and also permit “sandboxed” delegation of precisely defined subsets of service design and/or management responsibilities with respect to specified groups of subscribers or end-user devices. These and other features and advantages of the above-mentioned embodiments and others are disclosed in greater detail below.
In the embodiment of
Joint Policy Design
Still referring to
As a matter of terminology, individual policy components are distinguished herein as access-control policies (or “control policies” for short), accounting policies, and notification policies according to the nature of their triggered actions. For example, the six exemplary policy components 154 within the first service policy instance (i.e., “Service Policy 1”) include two control policy components (indicated by policy actions “Control1” and “Control2”), two notification policy components, and two accounting policy components (of course, the inclusion of the six exemplary policy components 154 within the first service policy instance is merely illustrative—more or fewer components may be included within a given service policy). Likewise, it is not necessary that the components include all three of control, notification, and accounting, or that the number of each type be equal. As described above and in further detail below, the hierarchical definition of filters and component-level classification objects enables filters within database 157 to be re-used within a given service policy 152, as in the definition of classification events CE2 and CE3, and also within different service policies. Also, the same classification event may be associated with two or more policy events within respective policy components as in the policy components that yield control, notification, and accounting actions (Control1, Notification1, Accounting1) in response to classification event CE1 during policy state PS1. Further, while each policy component is shown as triggering a single control action, a single policy component may be defined to include multiple actions in an alternative implementation or configuration. Thus, instead of requiring three separate policy component instantiations to effect the Control1, Notification1, and Accounting1 actions, a single policy component may be defined to trigger those three actions (or any combination of actions, including two or more actions of the same type) as shown at 156. In addition to enabling efficient, joint policy definition within an integrated design environment, this design flexibility permits the design of arbitrarily complex policy implementations, including policies that support multiple-match classification sequences and “interceptor” policies that detect attempted access to an unsubscribed service and interact with a user to offer and activate one or more access-compatible service plans.
The consistent joint (integrated) policy definition and enforcement framework enabled by the various SDC embodiments presented herein is tremendously advantageous in the design and provisioning of enhanced policy enforcement capability, lower complexity and reduced network cost, reduced latency in user service notifications, and real time interaction between service plan policy options and user preferences to enhance the user experience and increase the opportunities to effectively market and sell new types of services and service plans or bundles. As described above, joint policy definition and enforcement framework refers to the capability to define and deploy filters (or collections of filters) conditioned on policy state and associate the conditioned filters with any of three policy types: control, accounting and notification. For example, a service activity (e.g., access or attempted access) that yields a match with respect to a filter (or collection of filters) defined as a “data communication type” and conditioned on “service limit reached” (a policy state) can be associated with a joint policy actions comprising “cap” (a control action triggered by the policy-state-conditioned filter match and thus a control policy) and “send plan modification required notification” (a notification action triggered by the filter match and thus a notification policy). This “cap and notify” joint policy construct allows for simultaneous execution of real-time capping (when the service limit is reached) and real-time user notification that the limit has been reached. Because the notification action is triggered at the same instant as the cap was enforced (i.e., both actions are triggered by the same policy-state-conditioned filter matching event), and the notification trigger can cause the notification system to deliver a user interface message to be displayed on the device UI in fractions of a second to a few seconds, the device user experiences a notification explaining why the service has been stopped precisely when the user has requested service and thus while the user's attention is directed to execution of the requested service (i.e., coincident in time with the service being stopped). Further, the UI message may include or be accompanied by information of various options for resolving the service stoppage, including on-the-spot offers to activate one or more service plans that will enable the requested service. Thus, in contrast to a disaggregated policy design/implementation in which notice of plan-expiration may arrive minutes or hours after the relevant service request with no option for resolution beyond calling a “customer care” call center (i.e., an untimely notification of a problem with no clear or immediate avenue for correction—in essence, a nuisance), a joint or integrated policy defined using embodiments of the integrated service design center enables instantaneous notification of the plan exhaustion event together one or more options for immediate resolution and allowance of the requested service access, apprising the network-service consumer of a problem and offering one or more solutions (including offers to purchase/activate additional service plans) precisely when the consumer is most likely to make a purchase decision. From a system design perspective, by providing the capability to associate a filter match definition with multiple policy types (i.e., as in the above example of joint (or integrated) policy design) there is no longer a need to have separate communication service control and communication service notification systems because both functions are accomplished with the same system.
As another joint or integrated policy example, a filter match comprising “data communication type” (a filter or component) conditioned on “service limit reached” (a policy state) can be associated with a joint policy comprising “stop accounting to base service plan bucket” (a first accounting policy), “begin accounting to service overage bucket” (a second accounting policy), and “send service overage now in effect notification” (a notification trigger policy). As in the preceding cap and notify example, this exemplary “cap and match” joint policy provides real-time notification to make the end-user immediately aware of service plan status (i.e., capped in this example), thus allowing the end-user to potentially modify his/her service plan or usage behavior. As the cap and match example also demonstrates, the single, simplified joint policy enforcement system obviates the separate accounting and notification systems that plague conventional approaches.
As another joint policy example, three-way joint policy enforcement may be achieved through definition of a filter comprising “data communication type” (a “data” filter or collection of data filters) whose match is conditioned on a “service limit reached” policy state and triggers, as control, accounting and notification actions, a “restrict access to service activation destinations” (a control action, and thus a control policy), a “stop accounting to base service plan bucket” (an accounting action and accounting policy), and a “send new service plan or service plan upgrade required” notification (a notification action and therefore a notification policy). In this example the complexity of having separate accounting, control and notification systems that are difficult to program and provide poor notification response times is avoided and replaced with an elegant, simple, less expensive and easier to program joint policy system that provides real time user notification.
As mentioned briefly above, embodiments of the integrated service design center also enable design and deployment of interactive (or dynamic) service policies. Continuing with the data filter example presented above, a match with respect to a data filter conditioned (or qualified) by a “service limit reached” policy state can be associated with a joint user-interactive policy comprising “cap until user response received” (a user-interactive control policy), “stop accounting to base service plan bucket” (an accounting policy), and “send the service plan offer corresponding to the data limit reached condition” (a user-interactive notification trigger policy). Thus, the SDC embodiments described herein provide not only for enhanced policy enforcement capability, lower complexity and reduced latency for a better user experience, but also real-time interaction between service plan policy options and user preferences, further enhancing the user experience and increase the opportunities to effectively market and sell new types of services and service plans or bundles.
As another example illustrating a joint policy design, a first data filter match conditioned by a “95% of service limit reached” policy state can trigger (or otherwise be associated with) a “send service limit about to be reached” notification (i.e., a notification policy), and a second data filter match conditioned by a “100% of service limit reached” can trigger a “cap” control action (i.e., a control policy). Thus, in this joint policy design example, the integrated service design center enables definition of a common (or shared) data-communication-type filter that is conditioned on two different policy states and, when matched in conjunction with the respective policy states, triggers distinct notification and control actions.
As another example illustrating a joint policy design, a first filter match comprising “Amazon” (a filter or a component) conditioned on “sponsored Amazon limit not reached” (a policy state) can be associated with “allow” (control policy) and “account to sponsored Amazon bucket” (an accounting policy), and a second filter match comprising “Amazon” (a filter or a component) conditioned on “sponsored Amazon limit reached” (a policy state) can be associated with “stop accounting to sponsored Amazon bucket” (an accounting policy), “send acknowledgement for ‘Free Amazon service limit reached for this month, would you like to continue with Amazon charged to your data plan?’ notification” (a user-interactive notification policy) and “cap until user response received” (a user-interactive control policy), “if user agrees, cap-match” [e.g. continue searching for a match] (a user-interactive policy to proceed down the Z-order to find another match), and “if user does not agree, cap-no match” (a user-interactive control policy). This is an example of a multi-match policy set where Amazon is first tested for the sponsored service filter until the sponsored service use bucket limit is reached, then a cap-match command is executed and, if there is another Amazon filter match before the “no capable plan” end filter is reached (e.g. a user data plan bucket that is not over its limit), then a second match will be found in the prioritization order.
As another example illustrating a joint policy design, at a first time a first filter match comprising “application update” (a filter or a component) conditioned on “application background status” (a first policy state) and “roaming network condition in effect” (a second policy state) can be associated with “block” (a control policy), and at a second time a second filter match comprising “application update” (a filter or a component) conditioned on “application foreground status” (a first policy state) and “roaming network condition in effect” (a second policy state) can be associated with “allow” (a control policy), and at a third time a filter match comprising “application update” (a filter or a component) conditioned on “application background status” (a first policy state) and “home network condition in effect” (a second policy state) can be associated with “allow”. Thus, in this example a filter is conditioned on two policy state conditions (home/roaming network state and foreground/background application state), wherein in a background application update is allowed unless it is occurring on a roaming network, and a foreground application update is always allowed. This example simultaneously demonstrates two advantageous capabilities that may be achieved through joint policy design: the ability to modify control policy (or accounting or notification policies) as a function of network type and also the ability to modify control policy as a function of foreground versus background application status.
As another example illustrating joint policy design, a filter match comprising “no capable plan” (the final filter in the Z-order search) conditioned on “Vodafone Spain roaming network condition in effect” (a policy state) can be associated with “send the service plan offer corresponding to roaming on Vodafone Spain” (a notification policy), and “cap and wait for response” (a user-interactive control policy). Further, as a pure notification example, a filter match comprising “voice communication type” (a filter or component) conditioned on “80% of service limit reached” (a policy state) can be associated with “send ‘you have 20% left on your talk plan’ voice notification message” (a notification policy).
As a marketing interceptor example, a filter match comprising “no capable data plan” (the final filter in the Z-order search) with no condition can be associated with “send the free try before buy service offer” (a notification policy), and “cap and wait for response” (a user-interactive control policy).
As another marketing interceptor example embodiment, a filter match comprising “Facebook” (a filter or component) can be associated with “notify and continue” (a notification trigger policy) and “send Google+sponsored cellular service offer” (a notification policy). In this example the special command “notify and continue” is provided as an example of the expanded policy enforcement instruction set that can lead to additional policy capabilities—in this case simplified and powerful notification based on user activity with their device. The notify and continue command example provides for a notification trigger that results in a notification being sent to the device UI (in this case an offer for free Google+access on cellular networks) with no impact on service plan control or accounting and without interfering with the service activity to match with a filter in the Z-order search. The “continue” in “notify and continue” refers to the process of allowing the Z-order search process to proceed to find a match under the service plan policies in effect.
As another example of joint policy design and implementation, a notification policy may specify that when an end-user device that is not associated with (subscribed to) a service plan that provides for text messaging attempts to send a text message, a notification is provided through a user interface of the end-user device. In this example, the policy state is that the end-user device is not associated with a service plan that provides for text messaging, the classification event is that the end-user device attempted to send a text message, and the action is to provide a notification through the user interface of the end-user device. As another example, a control policy may specify that when an end-user device that is not associated with (subscribed to) a service plan that provides for text messaging attempts to send a text message, the text message is blocked. In this example, the policy state is that the end-user device is not associated with a service plan that provides for text messaging, the classification event is that the end-user device attempted to send a text message, and the action is to block the attempted text message. The policy may specify more than one action. For example, continuing with the examples above, a policy may specify that when an end-user device that is not associated with (subscribed to) a service plan that provides for text messaging attempts to send a text message, the attempted text message is blocked, and a notification is provided through a user interface of the end-user device. In general, classification events are matches between designer-specified classification objects and attempted or actual service access events. For example, in the text message example provided above, the designer-specified classification object is an attempt to send a text message, and the attempted or actual service access event is that the end-user device attempted to send a text message.
Hierarchical Design Environment
Proceeding to the next hierarchical design level shown in
The hierarchical design levels described thus far (i.e., filters, policy components and service policies) may be applied in either a service plan definition or in discovered-service constructs, such as the marketing interceptors (or “interceptor” policies) mentioned above, which can detect attempted accesses to an unsubscribed service and interact with a user to offer and activate one or more services.
Continuing upward to the next hierarchical level within a service plan definition, service plans and service-plan bundles (the latter being referred to in shorthand herein as “bundles”) are defined by incorporation of one or more service polices together with a specification of optional plan-level accounting policies, plan-level policy events and plan class. In one embodiment, plans and bundles are distinguished by quantity of incorporated service policies with service plans each incorporating a single service policy, and service-plan bundles each incorporating multiple service policies (i.e., establishing, in effect, a bundle of service policies). As discussed below, the multiple service policies within a bundle are generally billed as a collective service, but may be accounted for separately, for example, to enable costs of constituent service policies to be broken out for taxation, analytic or other purposes.
In a number of embodiments, plan-level accounting enables billing on recurring or non-recurring cycles of designer-specified duration, and thus complements any policy-based accounting actions (e.g., component-level, policy-level or plan-level accounting according to service usage in addition to or instead of accounting per temporal cycle). In one embodiment, for example, the service design center permits the specification of a minimum number of billing cycles to transpire (and/or a calendar date or other criteria) before plan cancellation is permitted, and also whether plan usage metrics are to be reset or usage limits varied (e.g., usage rollover) at the conclusion of a given accounting cycle. Other examples include proration rules, sharing rules, etc.
Plan-level policy event definition, like policy event definition at the service policy level, permits a single policy-event definition to be associated with the classification objects incorporated from lower hierarchical levels, thus enabling a conceptually and logistically efficient definition of numerous policies having a shared plan-level policy state and triggered action, but different classification events. Plan class specification enables prioritization between service plans according to, for example, the paying entity, nature of the service, and so forth. In one embodiment, for example, plans may be differentiated as either sponsored (i.e., a third party pays for or otherwise defrays the cost of service in part or whole) or subscriber-paid, with sponsored plans being prioritized ahead of subscriber-paid plans. By this arrangement, sponsored and subscriber-paid plans for otherwise identical services may coexist, with the plan prioritization ensuring usage of a sponsored plan before its subscriber-paid counterpart (or vice-versa). As another example, plans that enable service activation may be differentiated, as a class, from service-usage plans, with activation-class plans being prioritized ahead of their service-usage counterparts. Such prioritization can be used to ensure that a user service plan is not charged for data access required to activate a service plan (or for service plan management).
In the embodiment of
Still referring to the design hierarchy of
The foregoing instances of plan-level, policy-level and component-level accounting are provided for purposes of example only and to make clear that accounting actions may be specified at any level of the service design hierarchy where beneficial to do so, including at multiple hierarchical levels. Prioritization (and/or conflict resolution) between accounting actions defined at two or more hierarchical levels may be controlled by explicit or implied input from the SDC user (i.e., with such input forming part of the overall service design specification) and/or established by design or programmed configuration (e.g., as in a user preference setting) of the SDC itself.
Policy Priority Management
If a user or subscriber has paid for all service plans enabling the end-user device to access services, and none of the plans expires, then the order in which the plans are used up (i.e., the order in which service usage is accounted to the service plans) does not matter. But if a service plan is, for example, provided at no charge to a user or subscriber, and a particular service usage fits within that no-charge plan, then it may be desirable to account for the particular service usage within the no-charge plan instead of accounting for the service usage to a user-paid plan. Likewise, if a first service plan (whether user-paid or provided at no charge to the user) is nearing expiration (e.g., will cease to be available in three hours), and a second service plan under which a particular service usage could be accounted does not expire, it may be desirable to account for the particular service usage within the first service plan, if possible. By knowing variables such as whether a service plan is partially or entirely user-paid (or, conversely, whether a service plan is partially or entirely sponsored), whether a service plan expires, etc., a service designer can use the service design center to control whether, and in what order, service policies (e.g., accounting, control, and notification) are applied when an end-user device engages in various service activities (i.e., use of apps, access to Internet destinations, transactions, etc.). A policy enforcement engine (e.g., implemented by one or more agents within a network element and/or end-user device) may also apply the priority information to dynamically alter the priority order, for example, in view of fluctuating priority relationships that may result from the timing of plan purchases and/or automatically cycling (i.e., auto-renewing) plans. Also, while not specifically shown in
In the embodiment shown in
Although a top-down sequence of priority definition is shown in
Although sponsored plans may be prioritized ahead of user-paid plans in a number of contexts, the converse may also be true. For example, under the concept of a “carrier backstop,” a carrier or other service provider may wish to charge certain service activities required for service plans to work (e.g., domain name server functions) first to the end-user if the end-user has a supporting plan, and then to the service provider as a backstop. Accordingly, all the prioritizing arrangements described herein should be understood to be examples, with various alternative prioritizations being permitted by design or default.
Continuing with the prioritization examples, a particular service plan could have, for instance, sponsored and user-paid components. For example, the 30-day, 10 MB general access plan of
The priorities of plans within a given plan class may be explicitly assigned by the service designer, or potentially by a user through a web site or through a user interface of the end-user device. In the example of
On the other hand, the three-day sponsored social networking plan includes both of the Twitter-related filters (because access to Twitter is included in the three-day sponsored social networking plan), and it also includes three Facebook filters: a Facebook app filter, a Facebook messenger filter, and a Facebook web access filter. Because the three-day sponsored social networking plan provides only for social networking access, the plan does not include the all-pass filter. Note, however, that the end-user may wish to modify the default priorities based on purchase timing and/or re-prioritize based on service usage. Such end-user prioritization controls may be selectively granted as part of the overall user experience defined within the service design center.
In the example of
Similarly,
Still referring to
Note a use of the Twitter app by an end-user device could potentially be accounted to any one of the four plans shown in
Continuing with the example of
Although often it will be a service designer, through the service design center, who establishes the relative priorities of service plans, a subscriber or user can also be provided with the tools to set service plan priorities. For example, the subscriber/user may be given a “sandbox” (described) herein that allows the subscriber/user to modify the priorities of service plans. The subscriber/user may also, or alternatively, be able to establish service plan priorities through a user interface of the end-user device itself. For example, when a user selects (e.g., pays for, accepts, selects, etc.) a service plan from the end-user device, the user can be presented with an option to establish the priority of the service plan relative to other service plans associated with the device.
As the examples in
Service Discovery Management
The service design center may also enable the designer to control the subset of plans to be presented within a tab or other organizational structure, feature a particular plan or plans within a “featured” plan tab or page, control the order in which the plans are presented and/or separate the subset of plans into further subgroups within the plan presentation. In the tabbed service plan display shown at 252, for example, the service designer has (i) specified four voice plans to be listed within a “Talk” tab of a smartphone interface, (ii) ordered those plans according to their usage allowance (ranging from 15 minutes to 600 minutes), (iii) inserted a divider to separate the plans into those of briefer and longer usage allowance (e.g., under an hour versus over an hour), (iv) specified plan pricing, (v) provided selection buttons (circles to the left of each plan description) to enable an end-user to select an individual plan for purchase and activation, and (vi) provided a prompt to the end-user to “Choose a Voice Plan,” all within the integrated service design environment. The service designer may additionally specify one or more plans to be specially featured within a given organization structure (e.g., highlighted with respect to other plans on the same tab or presented in a separate list of featured plans) and provide explanatory or promotional information to be displayed in response to end-user selection of a particular plan or bundle. Thus, the service design center enables the overall plan marketing environment to be precisely defined, either exactly or generally as it will appear on the display of an end-user device. In the particular example shown, the end-user device is assumed to be a smartphone having a touch-screen interface, though plan catalog presentations may similarly be specified for various other mobile and/or fixed-location devices having any practicable user interface, including tablet/laptop/desktop computers, specialized devices such as e-book readers or network-interactive navigation systems, network-connected media players, intermediate networking devices, and so forth. In end-user devices that lack visual displays (or display-bearing devices operated in auditory/voice-operated modes), plan catalogs may be presented audibly (through voice prompts) with user voice commands or button-press used to select specific options. For example, voice keywords may be spoken to select specific plans, receive additional information, etc.
Still referring to
As another aspect of discovered-service management, shown at 255, a service designer may define generic and targeted “interceptors” that detect service-usage-related events (e.g., requests for non-subscribed services, etc.) and present promotional offers (upsells) in response. In one embodiment, generic interceptors are backstop control and notification actions triggered in response to an access attempt for which no classification match results. For example, a service designer may specify a default “You do not have a text plan” message to be presented in response to detecting an attempt to send or receive an SMS (Short Messaging Service) message from an end-user device having no texting plan. As in the promotional offers discussed above, the lack of compatible plan (LCP) message may be presented together with an offer to view/purchase one or more service plans that permit the requested access.
Targeted interceptors, referred to herein as “marketing interceptors,” are similar to generic interceptors, but include one or more service policy components (and thus one or more filters) that serve to detect the unsubscribed access attempt, thereby enabling a more precise identification of the service request and a correspondingly more targeted service offer in response. In the example shown at 256, for instance, one or more service policy components are deployed to detect Facebook service requests (e.g., attempt to execute a Facebook app, engage Facebook Messenger, or access a Facebook web page) and, in response, to provide a lack-of-compatible-plan message together with an offer to allow the user/subscriber to purchase one or more compatible plan offers (four different Facebook plans in this example, as well as an option to view all compatible plans (i.e., all plans allowing the attempted service usage)). Further, the collection of offers (an “offer set” constituting one or more offers) may be conditioned or tailored according to various factors relating to end-user device and/or network state. For example a different offer set may be presented in response to foreground-only activities (e.g., activities that prompt for user-input or otherwise actively present information via the user interface of the end-user device) than in response to background-only activities, and a yet a different offer set may be presented in response to a particular combination of foreground and background activities. For example, a particular offer may be displayed only if the corresponding application is in the foreground (e.g., Facebook app driving user-interface display) and a different notification may be presented if the application is in the background (e.g., Facebook app attempting a background sync). Thus, marketing interceptors enable a tailored set of service plans to be offered on an end-user device precisely when the device user has requested a service falling within the purview of the offered plans and in accordance with the state of the end-user device and/or network—a service otherwise unavailable without new plan activation.
Sandboxed Design Environment/Subscriber Management
In the embodiment shown in
Still referring to
Note that the user credentialing mechanism may be implemented within the service design center itself, or, in whole or part, as a separate entity that provides verified (or trusted) credentials to one or more instances of the service design center. The latter arrangement enables intra-organizational responsibilities to be further sandboxed (e.g., further subdividing the various permission sets and/or subscriber/device group responsibilities shown with respect to a particular credential in
Multiple-Match Design Capability
As demonstrated in a number of examples above, the joint or integrated policy design constructs enabled by embodiments of the integrated service design center permit definition and provisioning of much more complex, user-responsive and interactive service policies than possible through conventional disaggregated design approaches. These include, for example without limitation:
The consistent joint (integrated) policy definition and enforcement framework provided by the present disclosure is very important for providing enhanced policy enforcement capability, lower complexity and reduced network cost, reduced latency in user service notifications, and real time interaction between service plan policy options and user preferences to enhance the user experience and increase the opportunities to effectively market and sell new types of services and service plans or bundles. Here, joint policy definition and enforcement framework refers to the capability to define or design filters (or components) conditioned on policy state and associate the filters with any of three policy types: control, accounting and notification. For example, a filter match comprising a filter match comprising “data communication type” (a filter or component) conditioned on “service limit reached” (a policy state) can be associated a joint policy comprising “cap” (a control policy) and “send plan modification required notification” (a notification trigger policy). This allows for simultaneous real time capping when the service limit is reached and real time user notification that the limit has been reached. Because the notification trigger occurred at the same instant as the cap was enforced, and the notification trigger can cause the notification system to deliver a user interface message to be displayed on the device UI in fractions of a second to a few seconds, the user experiences a notification explaining why the service has been stopped that is coincident in time with the service being stopped. With this type of joint (or integrated) policy capability to associated a filter match definition with multiple policy types there is no longer a need to have separate communication service control and communication service notification systems because both functions are accomplished with the same system. As another example, a filter match comprising “data communication type” (a filter or component) conditioned on “service limit reached” (a policy state) can be associated a joint policy comprising “stop accounting to base service plan bucket” (a first accounting policy), “begin accounting to service overage bucket” (a second accounting policy), and “send service overage now in effect notification” (a notification trigger policy). Similar to the above example, this example embodiment provides real time user notification so that the user is immediately aware of the status of their service allowing the user to potentially modify their service plan or their usage behavior. In this example the disclosure also provides the benefit that this single, simplified joint policy enforcement system removes the need for separate accounting and notification systems. An example embodiment for a three-way joint policy enforcement is a filter match comprising “data communication type” (a filter or component) conditioned on “service limit reached” (a policy state) that is associated with “restrict access to service activation destinations” (a control policy), “stop accounting to base service plan bucket” (an accounting policy), and “send new service plan or service plan upgrade required notification” (a notification policy). In this example the complexity of having separate accounting, control and notification systems that are difficult to program and provide poor notification response times is replaced with an elegant, simple, less expensive and easier to program joint policy system that provides real time user notification.
With the present disclosure, in some embodiments policy can also be interactive. Continuing with the same basic filter match example for illustration purposes, a filter match comprising “data communication type” (a filter or component) conditioned on “service limit reached” (a policy state) can be associated with a joint user-interactive policy comprising “cap until user response received” (a user-interactive control policy), “stop accounting to base service plan bucket” (an accounting policy), and “send the service plan offer corresponding to the data limit reached condition” (a user-interactive notification trigger policy). This example illustrates that not only does the present disclosure provide for enhanced policy enforcement capability, lower complexity and reduced latency for a better user experience, the disclosure also provides for a real time interaction between service plan policy options and user preferences, further enhancing the user experience and increase the opportunities to effectively market and sell new types of services and service plans or bundles.
As another example illustrating a joint policy design, a first filter match comprising “data communication type” (a filter or component) conditioned on “95% of service limit reached” (a policy state) can be associated with “send service limit about to be reached notification” (a notification trigger policy), and a second filter match comprising “data communication type” (a filter or component) conditioned on “100% of service limit reached” can be associated with “cap” (a control policy). In this example, a common filter is shared that defines a data communication type, and the common filter is conditioned on two different policy states.
As another example illustrating a joint policy design, a first filter match comprising “Amazon” (a filter or a component) conditioned on “sponsored Amazon limit not reached” (a policy state) can be associated with “allow” (control policy) and “account to sponsored Amazon bucket” (an accounting policy), and a second filter match comprising “Amazon” (a filter or a component) conditioned on “sponsored Amazon limit reached” (a policy state) can be associated with “stop accounting to sponsored Amazon bucket” (an accounting policy), “send acknowledgement for ‘Free Amazon service limit reached for this month, would you like to continue with Amazon charged to your data plan?’ notification” (a user-interactive notification policy) and “cap until user response received” (a user-interactive control policy), “if user agrees, cap-match” [e.g. continue searching for a match] (a user-interactive policy to proceed down the Z-order to find another match), and “if user does not agree, cap-no match” (a user-interactive control policy). This is a clear example of a multi-match policy set where Amazon is first tested for the sponsored service filter until the sponsored service use bucket limit is reached, then a cap-match command is executed and if there is another Amazon filter match before the “no-match” end filter is reached (e.g. a user data plan bucket that is not over its limit) then a second match will be found in the Z-order.
As another example illustrating a joint policy design, at a first time a first filter match comprising “application update” (a filter or a component) conditioned on “application background status” (a first policy state) and “roaming network condition in effect” (a second policy state) can be associated with “block” (a control policy), and at a second time a second filter match comprising “application update” (a filter or a component) conditioned on “application foreground status” (a first policy state) and “roaming network condition in effect” (a second policy state) can be associated with “allow” (a control policy), and at a third time a filter match comprising “application update” (a filter or a component) conditioned on “application background status” (a first policy state) and “home network condition in effect” (a second policy state) can be associated with “allow”. This is a clear example of a filter conditioned on two policy state conditions (home/roaming network state and foreground/background application state), wherein in a background application update is allowed unless it is occurring on a roaming network, and a foreground application update is always allowed. This is an interesting example embodiment showing two advantageous capabilities at the same time, the first capability being the ability to modify control policy (or accounting or notification policies) as a function of network type and the second capability being the ability to modify control policy as a function of foreground vs. background application status.
As another example illustrating joint policy design, a filter match comprising “no-match” (the final filter in the Z-order search) conditioned on “Vodafone Spain roaming network condition in effect” (a policy state) can be associated with “send the service plan offer corresponding to roaming on Vodafone Spain” (a notification policy), and “cap and wait for response” (a user-interactive control policy).
As a pure notification example, a filter match comprising “voice communication type” (a filter or component) conditioned on “80% of service limit reached” (a policy state) can be associated with “send ‘you have 20% left on your talk plan’ voice notification message” (a notification policy).
As a marketing interceptor example, a filter match comprising “no-match” (the final filter in the Z-order search) with no condition can be associated with “send the free try before buy service offer” (a notification policy), and “cap and wait for response” (a user-interactive control policy).
As another marketing interceptor example embodiment, a filter match comprising “Facebook” (a filter or component) can be associated with “notify and continue” (a notification trigger policy) and “send Google+sponsored cellular service offer” (a notification policy). In this example the special command “notify and continue” is provided as an example of the expanded policy enforcement instruction set that can lead to additional policy capabilities—in this case simplified and powerful notification based on user activity with their device. The notify and continue command example provides for a notification trigger that results in a notification being sent to the device UI (in this case an offer for free Google+access on cellular networks) with no impact on service plan control or accounting and without interfering with the service activity to match with a filter in the Z-order search. The “continue” in “notify and continue” refers to the process of allowing the Z-order search process to proceed to find a match under the service plan policies in effect.
As another marketing interceptor example embodiment for advertising a product or service, a filter match comprising “SiriusXM app” (a filter or component) can be associated with “notify and continue” (a notification trigger policy) and “send Pandora app and sponsored cellular service offer” (a notification policy). In this example the notification policy is based on detecting application activity that triggers a marketing interceptor offer.
Continuing with the embodiment of
Referring now to
Still referring to detail view 315, the sequential obtention of user input, policy-set update and policy-set application at 323 and 325 permits the applied policy set to be updated in whole or part in response to the user-input. Further, one or more policy states may be updated to reflect the matching event and thus establish a new classification scanning state to be considered as the classification sequence continues. As discussed in examples below, the ability to update policy sets based on user input enables service characteristics and selections to be changed on the fly (i.e., dynamically or on-demand), particularly in the context of a device-assisted service environment where the user-input may include a service activation directive (e.g., a service purchase or selection of a sponsored service) in response to a lack-of-compatible-plan notification. Similarly, the ability to establish a new classification scanning state provides a feedback mechanism within the classification sequence as a classification match may dynamically trigger a change in the policy state to be applied in conjunction with subsequent classification events. Also, in one embodiment, each classification event in a multi-match classification sequence may be flagged (or logged or otherwise recorded) so that, upon concluding the classification sequence, the overall set of matched filters may be considered in determining the actions to be performed. Thus, instead of (or in addition to) triggering actions in immediate response to a classification match (i.e., in the midst of a classification sequence), a determination of actions to be performed may be deferred until the classification sequence terminates to enable decision making in view of the complete set of classification events. This deferred-action construct is discussed in further detail below.
Continuing with multi-match classification sequence 300, attributes of the indexed policy set are evaluated at 307 to determine whether further classification (“re-match”) is permitted. If so, then despite the classification event detection at 289 and policy set application at 305, the filter evaluation loop is continued by updating the classification and policy sets at 308 (i.e., to reflect any change in classification scanning state or other policy states effected by the policy set application at 305) and then incrementing the loop index at 293. If the loop index does not exceed the final index (negative determination at 295), the filter evaluation loop repeats starting at 289. Upon reaching the final loop index (affirmative determination at 295) or applying a policy set that denies further re-matching (negative determination at 307), the multi-match classification is concluded at 330 by selecting and applying a policy set based on the classification results. Before proceeding with a subsequent multi-match classification, classification limits may be evaluated at 309 to determine whether limits (e.g., usage limits) have been reached with respect to any policy sets and, if so, updating those policy sets accordingly at 311.
Reflecting on the filter evaluation loop and end-of-scan policy-set application effected within multi-match classification sequence 300, the ability to defer action (in whole or part) otherwise triggered by a classification event enables decision making in view of the classification sequence as a whole and thus a more informed and tailored set of triggered actions. The net effects of the filter evaluation loop and end-of-scan policy-set application are shown at 331 and 333, respectively. That is, the filter evaluation loop enables an evaluation of all applicable filters (i.e., those included within the scan by virtue of the credential evaluation at 283 and/or update operations at 287 and 308) until a scan-termination event is reached (i.e., all filters evaluated or matching a filter that does not permit re-matching), and the end-of-scan policy set application at 330 enables execution of policy actions in view of the full set of matched filters, if any. These operations are shown graphically at 335, with filters being evaluated in order (though parallel evaluation may also be possible) to yield a set of match filters (i.e., resulting from flagging/logging/recording the matching event and/or information corresponding to the matched filters), with some set of actions being performed based on priority or other characteristics of the matched filters. Note that if no classification events are detected in the filter evaluation loop, a backstop, no-match policy set may be applied at 330.
Still referring to
Continuing the example shown in
Provisioning Instruction Translator
A subscriber management engine 362 is provided to enable definition of one or more subscriber and/or end-user device groups (e.g., by device credential) based on input from one or more subscriber managers (i.e., service design center user(s) or operator(s), any of which may also be a service designer). An identified set of one or more of the user-defined subscriber groups (and/or end-user device groups) is associated with the catalog specified by the catalog descriptor and output from subscriber management engine 362 (i.e., as a set of subscriber identifiers/credentials and/or end-user device identifiers/credentials) to provisioning instruction translator 363. In one implementation, for example, the set of subscriber identifiers includes information that identifies various network elements associated with the identified subscribers and/or end-user devices to enable provisioning instruction translator 363 to identify the overall set of network elements (and/or end-user devices in a device-assisted service environment) for which provisioning instructions are to be generated.
In the embodiment of
Simplified Policy Architecture
A significant advantage of policy system architecture 366 is the capability to jointly define and enforce service control policy, service accounting policy and service notification policy. Definition (or design) of joint service policy is accomplished in service design center (SDC) 360, which may be implemented according to any of the various embodiments disclosed herein. In some embodiments, joint definition of service policy comprises using a common user interface and policy object creation or definition environment as a unified policy creation and management platform for two or more of the three key service network policy types: control, accounting and notification, thus providing a common or integrated environment that enables an SDC user to define service activity filters (definitions for a classification of service) and the policies that are associated with the filters to enforce a desired set of service plan policies. In the embodiment shown, the filter and associated policy definitions designed within SDC 360 may be supplied to a policy provisioning function 367 (e.g., including a provisioning instruction translator as discussed above) which serves in turn to convert those definitions into provisioning instructions for the various policy functions shown in
The Policy Enforcement Function 375 (PEF) is configured to enforce the real-time policies associated with each filter identified/defined in the output of policy provisioning function 367. In a number of embodiments, PEF 375 identifies communication flows, associates each flow with a device credential or subscriber credential, and performs a filter match search on the flows with filter and policy instruction definitions that are assigned to that device or subscriber by Policy Decision Function 370 (PDF). The filters define service activity classifications and the policy or policies associated with a given filter are implemented when the PEF executes a policy enforcement instruction in response to communication activities determined to match the filter parameters. Examples of classifications performed using the filters include but are not limited to classification of voice, data, text, with classification of data including, for example and without limitation, identification (or detection) of streaming traffic, VOIP, video, audio, downloads, peer to peer, communication associated with a website, communication associated with an application or application server, communication associated with a particular network end point, communication associated with a particular logical channel or data path, communication associated with an Access Point Name (APN), communication associated with a Virtual Private Network (VPN), communication associated with a proxy server, communication associate with a partner network connection.
Examples of policy enforcement instructions or actions executed by PEF 375 include access control instructions (e.g., communication or traffic control instructions), accounting instructions, and notification instructions. Access control instructions may include, for example and without limitation, block, allow, throttle, cap, delay, prioritize, cap and re-match, cap and no-match, hold and wait for user response, cap and wait for user response, increase priority, decrease priority. Examples of accounting instructions include, but are not limited to, allocate accounting to a service accounting bucket identifier, allocate accounting to a user service accounting bucket, stop allocating accounting to a user plan service accounting bucket, allocate accounting to a service sponsor accounting bucket, stop allocating accounting to a service sponsor accounting bucket, allocate to a carrier accounting bucket. In some embodiments, a notification policy includes but is not limited to identify a particular notification trigger event and provide an event identifier and device or subscriber credential associated with the trigger event. The notification trigger events are fed to the Device Interface Function 371 (DIF) where the notification trigger identifier is used to determine the proper notification for delivery to the device associated with the device (or subscriber) credential.
Policy instructions are provided to PEF 375 by the Policy Decision Function 370 (PDF) in the form of policy instruction sets (e.g., comprising filters (or components) and associated policy enforcement instructions), with each device credential or subscriber credential being assigned to one or more policy instruction sets, for example, according to records within device group/subscriber group database 377. In a number of embodiments, PDF 370 operates in near real-time to update the filter definitions and/or the policy instruction sets delivered to the PEF. PDF 370 may perform such updates primarily when changes occur in the policy state reported to PDF 370 by the Policy State Function 369 (PSF) The PSF 369 detects changes in policy state that have a bearing on service plan policies. Examples of policy state include, without limitation, any one of or combination of: a state of service usage (e.g. specified usage amount, usage amount above or below a service limit or within or outside a set of limits, a rate of service usage); an elapsed amount of time, specified time or time interval such as a specific time of day or specified portion of a day (e.g., 7:00 am-5:00 am) or week (e.g., Monday-Friday); foreground or background access; a network state including type of network (e.g. mobile operator, 2G, 3G, 4G, WiFi), whether a home network or roaming network, using a specific APN or any APN; a network busy status or other condition; one or more available QoS states; a geography (e.g., a geographical location); a temporal event in connection with a network state such as transitioning into a network or transitioning out of a network; classification scanning states such as a classification indicating that the requested service activity is to be blocked for the end-user device, a classification that disallows the requested service but permits continued classification scanning, etc. In some embodiments, policy state becomes a modifier or index to assist PDF 370 in determining which policies are to be evaluated in connection with a given classification scan (and thus which filters are to be evaluated by PEF 375). For example, PDF 370 may apply the policy state or a value derived therefrom as an index to identify a subset of one or more policies to be evaluated in connection with a given flow (e.g., an active policy set as described in reference to
As an example embodiment for how policy state can be utilized as an index, an SDC administrator might have a policy design goal as follows: for data usage, allow data and account for data bucket usage until 50% of a plan usage limit is hit, at 50% of a plan usage limit issue a one-time notification informing a device user that they have used 50% of their plan limit, from 50% to 90% of plan usage limit account for data bucket usage, at 90% of the plan usage limit issue a one-time notification informing a device user that they have used 90% of their plan limit and offer an upgrade service option for more usage, from 90% to 100% throttle the speed to 0.75 Mbps and account for data bucket usage, at 100% of the plan usage limit cap usage and send a notification explaining that the plan limit has been reached and offering the upgrade service option. The SDC policy designer can define policy states to be indexes for policy instructions to be applied conditioned on the value of the index. In this case, the policy index variable is “data usage as a percentage of plan limit” and when the data usage is below 50% of the plan limit the policy state indexes a “first set” of filters and corresponding policies comprising a filter definition of “data communication” that is associated with a control policy of “allow”, a charging policy of “account to user data bucket”, and a notification policy of “no notification”. The combination of filters and policies are also referred to as a policy instruction set in what follows. Continuing the example, when the data usage reaches 50% of the plan limit the policy state indexes a “second set” of filters and corresponding policies comprising a filter definition of “data communication” that is associated with a control policy of “allow”, a charging policy of “account to user data bucket”, and a notification policy of “one time notification trigger #1” with the notification trigger #1 being associated with a notification delivery informing the user they have hit 50% of the plan limit. The one time notification is a notification policy construct to issue one time notification messages, whereas another way to accomplish a one-time notification is to allow the PEF to continue issuing notification triggers but implement notification message suppression rules in the DIF. Continuing the example, when the usage hits 90% of the plan limit, the policy state indexes a “third set” of filters and corresponding policies comprising a filter definition of “data communication” that is associated with a control policy of “throttle to 0.75 Mbps”, a charging policy of “account to user data bucket”, and a notification policy of “one time notification trigger #2” with the notification trigger #2 being associated with a notification delivery informing the user they have hit 90% of the plan limit and offering the service upgrade. Continuing with the example, when the usage hits 90% of the plan limit, the policy state indexes a “fourth set” of filters and corresponding policies comprising a filter definition of “data communication” that is associated with a control policy of “cap”, a charging policy of “account to user data bucket” or “stop accounting” (this is an option since usage has been capped until the user chooses another plan), and a notification policy of “one time notification trigger #3” with the notification trigger #3 being associated with a notification delivery informing the user they have hit 100% of the plan limit so service is blocked and offering the service upgrade.
In another embodiment, a network busy state variable or a time of day variable can both be converted into indexes by defining limits or ranges with limits between the ranges as described above. Indexing instruction sets is an efficient way to modify policy as a function of policy state variables since the PDF can simply use a table of policy state index transitions to index different policy instruction sets, thus simplifying PDF logic. This technique also provides for a very predicable method for defining sophisticated policies in the SDC that are based on policy state, but are also very efficient to implement in the PDF, PEF, APF and DIF. Such embodiments simplify the logic in the PDF and PEF because the policy decision logic is reduced from other approaches and the manner in which the policy varies as a function of policy state can be easily configured within the SDC.
In some embodiments when a particular policy state variable or index of multiple policy state variables changes state, the PDF updates only the portion of a policy instruction set that is associated with the filters and policies impacted by the policy state transition. In other embodiments, it simplifies the PDF decision logic for the PDR to simply update all the filters and policy instructions in a policy instruction set when any policy state variable or index changes state, even though many of the filters and policies may remain unchanged. In another embodiment, the PDF updates the policy instruction set on a periodic basis whether a policy state variable or index has changed or not. This further simplifies the decision logic in the PDF with no meaningful loss of performance provided the time increment between updates is small with respect to time periods between policy state changes and with respect to an amount of service used during the time between updates.
Still referring to the architecture embodiment of
In a number of embodiments, DIF 371 establishes a communication channel (e.g., a secure channel) with an application, agent or SMS function on each of the end-user devices in a given device group (or subscriber group) to assist in delivering notifications to the end-user devices and, in some implementations, to receive end-user responses to such notifications from the end-user devices (e.g. service offer responses, acknowledgement responses, service choice/preference responses). For example, DIF 371 may communicate with the application or agent on each of the devices in the device (or subscriber) group using a pre-defined protocol (e.g., an application programming interface (API) protocol) established to make the communication of notifications, offers and user responses more efficient and useful for device users. In the case of a device-assisted network, DIF 371 may also be configured to request or instruct the application or agent on each of the devices in the device (or subscriber) group to assist in implementing or enforcing various notification policies, control policies and/or accounting policies. DIF 371 may accept user responses to notifications and service plan offers and relays them to Service Policy Management Function 378 (SPMF). DIF 371 may also perform an activation server function to activate a new service plan with respect to an end-user device or group of end-user devices. Such activations may be assisted by a sponsored service (e.g., implemented at least in part in PDF 370 and/or PEF 375) that allows the end-user device restricted access to the DIF.
The various types of notifications delivered to an end-user device by DIF 371 include, without limitation, notifications associated with service usage amount (including percentage or other fraction of service used or remaining), service limit reached or imminent, service overage, a service overage indication with request for end-user acknowledgement, a service condition that requires or may benefit from a service plan purchase or upgrade (with offer for such purchase or upgrade provided with notification of the service condition), notification of a roaming condition (including a roaming condition that may require or benefit from an end-user acknowledgment or other response), provision of one or more service offers, provision of one or more service offers together with a request or prompt for an end-user response (e.g., selection of one of multiple offered service options, thus constituting an acceptance of a service offer), provide a message or offer associated with a marketing interceptor trigger.
DIF 371 may forward notification responses (or information derived therefrom) received from end-user devices to various other functions within policy system architecture 366, including SPMF 378, which maintains service policy configuration information for each end-user device in a device (or subscriber) group and uses that information to manage active service policy sets for respective end-user devices. When a service plan is changed or an aspect is modified, SPMF 378 instructs the PDF 370 to implement the new service plan policies, and the PDF in turn instructs PEF 375 to implement the appropriate real-time policy implementation instructions to realize the service plan policies.
The Classification Definition Update Function (CDUF) 368 provides updates to classification definitions, for example, to enable associative classification. Associative classification provides for changing filter definitions as additional filter parameters are determined to be necessary due to the changing nature of some websites and other internet destinations.
The simplified policy architecture provides numerous significant advantages over conventional arrangements, including without limitation:
In the case of a device-assisted network, policy system architecture 366 may be implemented largely by service processor execution within an end-user device (e.g. PEF=PEA, PIA; PDF=PDA, PCA), with network elements (PEF=a simplified PCEF or GGSN; PDF=an enhanced OCS or PCRF), or with a combination of network elements and device agents.
As will be appreciated in view of the disclosures herein, the functions illustrated in
It should be appreciated that although the various functions have been given names, and have been illustrated and described herein as being independent functions, it will be appreciated that other names can also be used for these functions, and that an implementation may implement the functions differently than shown or described herein. In particular, a single element (whether network-based or device-based) may perform more than one of the functions, or more than one element may perform a single function. The figures and descriptions presented herein are exemplary and are not meant to be limiting.
As a particular example, the policy decision function could be implemented by, for example, a policy rules element in the network system, or by a policy control agent on the device, or by a combination of a policy rules element in the network system and a policy control agent on the device. Likewise, the policy enforcement function could be implemented, for example, by a policy enforcement element in the network system, or by a policy enforcement agent, a policy implementation agent, and/or a modem firewall on the device, or by a combination of a policy enforcement element in the network system and one or more agents or elements on the device. As another example, the service policy management function could be implemented, for example, by a service controller or a policy management server in the network system, or by one or more device agents on the device, or by a combination of a service controller or a policy management server in the network system and one or more agents on the device. As another example, the accounting policy function could be implemented, for example, by a charging element and/or accounting/billing server/system in the network system, or by a billing agent and/or a service monitoring agent on the device, or by a combination of a charging element and/or accounting/billing server/system in the network system and a billing agent and/or a service monitoring agent on the device. Likewise, the device interface function could be implemented, for example, by a service controller in the network system, or by a user interface agent on the device, or by a combination of a service controller in the network system and a user interface agent on the device. More generally, various embodiments of network architectures, systems and constituent device agents, network elements and/or other components that may be deployed to define, enforce and otherwise implement service policies in accordance with disclosures herein, including for example and without limitation, the policy system architecture of
Policy Enforcement
As discussed in the context of
Policy rules element 381 represents one or more network elements responsible for policy-making and control decisions, such as, for example, dynamically managing and controlling data sessions, or determining the applicable accounting policy for a data session. Policy rules element 381 may have, for example, some or all of the functionality of the 3GPP policy and charging rules function (PCRF). Policy rules element 381 determines the appropriate rules to apply to service usage by an end-user device to implement the appropriate policies. For example, in some embodiments, policy rules element 381 keeps track of the statuses of different service plans (or service plan components) associated with end-user device 385, such as whether usage under each plan is still allowed, or whether the plan has been exhausted. Policy rules element 381 can track any characteristic or variable that triggers or contributes to a policy change (e.g., any variable or characteristic that requires a change in the notification policy or policies, the control policy or policies, and/or the accounting policy or policies associated with end-user device 385). Policy rules element 381 may identify, understand, or define policies in terms of one or more high-level rules or objective, such as, for example, “No streaming video allowed between the hours of 9:00 P.M. and midnight.”
Policy enforcement element 382 represents one or more network elements responsible for enforcing policies applicable to end-user device 385. In some embodiments, policy enforcement element 382 enforces gating and/or quality-of-service for individual packet flows. In some embodiments, policy enforcement element 382 tracks service usage associated with end-user device 385 to support charging. Policy enforcement element 382 may have, for example, some or all of the functionality of a 3GPP policy and charging enforcement function (PCEF). Policy enforcement element 382 may be, for example, a gateway. Policy enforcement element 382 may operate using one or more low-level rules or instructions that implement the high-level rules or objectives identified, understood, or defined by policy rules element 381.
Charging element 384 represents one or more network elements responsible for real-time charging of subscribers based on service usage. Charging element 384 may have some or all of the functionality of the 3GPP online charging system (OCS).
Notification element 383 represents one or more network elements responsible for providing notification messages to end-user device 385. Notification element 383 is communicatively coupled over the wireless access network to end-user device 385 (indicated by the dashed-line arrow). Notification element 383 either itself sends notifications to end-user device 385, or notification element 383 initiates the sending of notifications to end-user device 385. Notification messages sent by notification element 383 are configured to assist end-user device 385 in presenting a notification to a user of end-user device 385 through a user interface of end-user device 385 (e.g., a visual notification through a display, an audible notification through a speaker, etc.).
SDC 380 sends provisioning instructions to one or more elements (i.e., policy rules element 381, policy enforcement element 382, charging element 384, and/or notification element 383) to allow the elements to implement the policies designed using SDC 380. For example, SDC 380 can provide information to policy rules element 381 to enable policy rules element to determine the policy or policies that currently apply to end-user device 385. This determination may be based on, for example, a network state, a time of day, or of the other factors previously discussed. After determining the applicable policy or policies for end-user device 385, policy rules element 381 provides information to policy enforcement element 382. The information (e.g., a setting, an instruction, a direction, a high-level objective, etc.) allows policy enforcement element 382 to enforce the applicable policy or policies for end-user device 385.
As a simple example to illustrate the interaction of policy rules element 381 and policy enforcement element 382, assume that SDC 380 has provided to policy rules element 381 provisioning instructions based on a determination that end-user device 385 is governed by a parental control that prohibits data usage between 9:00 P.M. and midnight. At 8:30 P.M., end-user device 385 requests access to YouTube. Policy rule element 381 has determined that, because the time is not between 9:00 P.M. and midnight, the applicable control policy is “allow.” Policy rule element 381 has provided information to policy enforcement element 382 that instructs policy enforcement element 382 to allow the requested access to YouTube until further notice. At 9:00 P.M., policy rules element 381 determines that the applicable control policy for the device is no longer “allow” because the parental control applies. Policy rules element 381 determines the applicable control policy (“block”) and provides information to policy enforcement element 382 to enable policy enforcement element 382 to enforce the policy. Thus, policy rules element 381 uses the information provided by SDC 380 to modify policies applicable to end-user device 385. In particular, policy rules element 381 provides information to policy enforcement element 382 to change the enforced policies based on changes detected by policy rules element 381.
Policy enforcement element 382 can also send information to policy rules element 381. For example, policy enforcement element 382 can inform policy rules element 381 that policy enforcement element 382 blocked (or allowed) a traffic stream or a traffic attempt.
As illustrated in
As also illustrated in
As also illustrated in
As also illustrated in
Notification element 383 can send a variety of different notification messages, such as any of the notifications described herein, in response to various triggers from policy enforcement element 382, policy rules element 381, charging element 384, or SDC 380. For example, if a service plan associated with end-user device 760 has been exhausted, notification element 383 can send a notification message that includes an offer to repurchase or replenish the service plan, or an offer for a different or additional service plan. As another example, if a service usage billing rate or cost has changed, notification element 383 can send a notification message informing end-user device 760 of the change. As described previously (e.g., in explaining
In some embodiments, notification element 383 is able to receive information from end-user device 760. In some embodiments, end-user device 760 includes some intelligence (i.e., an application program, a software agent, a service processor, an operating system component, etc.) that enables end-user device 760 to establish a communication link with notification element 383 so that notification element 383 can conduct bi-directional communications with end-user device 760. In some embodiments, when a notification message provided by notification element 383 to end-user device 760 prompts a response from a user, the user response can be obtained by notification element 383, which can then communicate pertinent information (e.g., an acknowledgment of a billing rate change, acknowledgment or approval of a roaming condition, selection of a service plan or service plan option, etc.) to policy rules element 381. Policy rules element 381 can then adapt one or more policies based on the user response and provide updated information to policy enforcement element 382 so that policy enforcement element 382 can enforce the updated policy or policies. For example, if the response indicates that the user has agreed to purchase a new or additional service plan, policy rules element 381 determines the appropriate policy or policies based on the fact that the user has agreed to purchase a new or additional service plan.
It is to be understood that the functions described in the context of
In some embodiments, a portion of policy implementation/enforcement is performed by the end-user device, and a portion is performed by network elements.
In some embodiments, service controller 388 obtains provisioning instructions or information from SDC 380 and, based on the instructions or information from SDC 380, communicates policy control and/or implementation information (e.g., a setting, an instruction, a high-level objective, a policy, etc.) to service processor 392. In some embodiments, service processor 392 has one or more policy enforcement agents (or policy implementation agents) in an operating system kernel or stack, and these one or more policy enforcement agents enforce one or more of the applicable policies. In some embodiments, service processor 392 also has one or more policy decision agents that modify the one or more policies that are enforced by the one or more policy enforcement agents in a manner similar to how policy rules element 381 modifies policies that are enforced by policy enforcement element 382. In some embodiments, the one or more policy decision agents identify, define, or understand one or more high-level policy objectives or rules. In some embodiments, the one or more policy enforcement agents operate using low-level settings or instructions provided by the one or more policy decision agents.
In some embodiments in which end-user device 390 includes service processor 392, notification element 383 performs the notification functions described in the context of
In some embodiments, service processor 392 sends information (e.g., a trigger) to notification element 383. In some embodiments, service controller 388 is able to perform some or all of the functions of notification element 383.
In some embodiments, when a notification message sent by notification element 383 to end-user device 760 prompts a response from a user, the user response can be sent by service processor 392 to service controller 388, which can then communicate pertinent information (e.g., an acknowledgment of a billing rate change, acknowledgment or approval of a roaming condition, selection of a service plan or service plan option, etc.) to policy rules element 381. Policy rules element 381 then adapts one or more of the network-enforced policies that are enforced by policy enforcement element 382 based on the user response and provides updated information to policy enforcement element 382 so that policy enforcement element 382 can enforce the updated network-enforced policy or policies.
In some embodiments, service processor 392 establishes a secure (e.g., encrypted) communication link with service controller 388. In some embodiments, service controller 388 communicates over the secure communication link to provide policy information enabling service processor 392 to implement a device-portion of a service policy.
It is to be understood that the functionalities described in the context of
It should be appreciated in view of the disclosures herein that the functions illustrated in
Service Design Center (SDC) User-Interface: Object-Based Policy Development
In various embodiments described herein and illustrated in the user-interface figures described below, the service design center enables a service designer to manage service policy design through creation, organization, testing, revision and deployment of reusable policy objects (or policy-related objects) at various levels of the service design hierarchy. More specifically, the integrated service design center prompts and assists an SDC user in at least the following:
Each of the foregoing policy-related objects (there may be other such objects beyond those listed) within the SDC may be rendered as a graphical element on a display of the service design center, thus enabling the SDC user to interact intuitively with the various objects, dragging and dropping objects into a service policy design within the integrated service design environment. For example, once designed, policy-related objects can be selected with a mouse (or other point-and-select user-input device) from the SDC user interface and included in one or more new service plan designs.
With regard to revision control and object testing, a service plan catalog can indicate tested/verified/approved objects versus non-tested/verified/approved objects. Depending on type of service plan (e.g. engineering prototype, QA test, user beta test, production), an object can be rejected from being included in a plan if it is not of equal or higher test/verification/approval level. Also, device groups can vary according to the level of testing/verification/approval for policy objects. For example, a small group may be provided for engineering, a medium group for beta-testers, and a larger group for production. As another example, multiple smaller groups may be provided for beta test, with different versions of policy objects to be tested by each group. Policy objects associated with the most successful beta-test group may be fine-tuned and used for production.
In each of the various UI displays shown herein, one or more constructs to receive input from the SDC user may be presented including, for example and without limitation, by images of “click-able” buttons, data-entry fields, text prompts or hyperlinks (e.g., highlighted, colored or otherwise emphatically formatted alphanumeric strings signifying that another UI display or window may be launched by hovering over or clicking the string), and/or various icons or symbols indicating that a responsive action may be triggered by user-interaction with the icons/symbols (e.g., by clicking and/or dragging the icon/symbol with a mouse, stylus, finger-to-touchscreen, or other pointer control; pressing physical buttons on a keyboard or other user input device; speaking into a microphone; etc.). Each such user-input construct presented by the SDC should be understood to be a prompt, request and/or instruction to the SDC user to interact with the user-input construct (i.e., by performing button click, click-and-drag, button press, keypad/keyboard entry, speech, etc.) and thereby provide user input to be received and acted upon by the service design center. Accordingly, while a service designer and/or subscriber manager is occasionally referred to as “doing” or otherwise performing a function in connection with the service design center such as “creating a design object,” or “changing a design characteristic,” it should be understood in all such cases that the underlying service design center embodiment performs such function in response to or accordance with input provided by the user. Moreover, as discussed below, the service design center itself may be instantiated within a computing device through execution of programmed instructions (programmed code), with the computing device itself implemented by one or more programmed processors, dedicated hardware function blocks or any combination thereof, disposed in one or more discrete devices, including a network-interconnected set of discrete devices.
SDC User Interface: Design Hierarchy—Plan Catalogs
Proceeding from top to bottom through the design hierarchy shown in
SDC User Interface: Design Hierarchy—Service Plans
Still referring to
Still referring to
SDC User Interface: Design Hierarchy—Service-Plan Bundles
SDC User Interface: Design Hierarchy—Service Policies
Still referring to the exemplary Policy Event Properties displays,
The exemplary policy state definitions permitted under the SDC examples shown in
SDC User Interface: Design Hierarchy—Service Policy Components
SDC User Interface: Design Hierarchy—Filters
The Filter Properties display additionally prompts the user to enable filtering by remote destination, by application, by target operating system, by content, by protocol and/or by port number. In the case of remote destination filtering, the user is prompted to specify filtering by IP address (which may be a single IP address or a block of addresses signified by “slash” addressing) or domain, and in the latter case to specify whether referrers are to be loaded and whether to enable associative filtering. If associative filtering is enabled, the user may specify whether the associative filtering is to be carried out temporally (i.e., selected by marking the checkbox “By seconds” and entering the applicable number of seconds) and/or by data volume (selected by marking the “By bytes of data” checkbox and entering the applicable byte count).
If the SDC user specifies filtering by application, the user is prompted to enter a package ID and to click a text string to bring up a package name search display. The user is also prompted to specify whether the identified package is to be validated (i.e., by checking the “Validate this Application” checkbox). Similarly, a user that specifies filtering by target operating system (i.e., checking the corresponding checkbox) is prompted to choose a target operating system from a list, a user that specifies filtering by protocol is prompted to select a protocol from a set of protocols, and a user that specifies filtering by port is prompted to enter a port number. Note that the specific transport layer protocol options shown in connection with protocol filtering (i.e., TCP and UDP and thus protocols predominantly associated with non-streaming and streaming services, respectively) may be supplemented by other transport layer protocols, protocols from other layers of the internet protocol suite and/or protocols from protocol suites other than the internet protocol suite in alternative embodiments.
Continuing with filtering criteria, if the user specifies filtering by content, the user is prompted to specify the direction of the filter with respect to network traffic and also whether the filter relates to generic content and/or user-defined content. Receiving a specification of filter direction may be useful, for example, in searching for regular expressions (i.e., “RegEx implementations), as it may be necessary to inspect incoming traffic to determine classification (e.g., certain protocols such as SMTP). In other cases, for example where classification requires a multiple-packet match (e.g., using linked filters), it may be necessary to inspect an outbound packet and then search for a corresponding inbound packet to affirmatively match). If the user specifies that the filter is directed to generic content, the user is prompted to select one or more generic content types (e.g., flash video converter, etc.). Similarly, if the user specifies that the filter is directed to user-defined content, the user is prompted to select one or more user-defined content types (e.g., Google login service type). Although not specifically shown, the SDC user may also be prompted to enter a RegEx string as a user-defined type. Still referring to
As with characteristics of all the SDC user interface displays presented herein, the filter options and characteristics described in connection with
As mentioned in connection with the plan catalog level of the
SDC User Interface: Plan Catalog Design—Service Discovery
As mentioned above,
Referring specifically to the “Promo Banners” display 603, the SDC user may also select a plan from language-specific lists of plans (thus enabling specification of language-specific banners in connection with a given plan), and may control the order in which the banners within a given list are presented. Using this feature, the SDC user may define the order in which promotional banners scroll across the end-user device. Additionally, the SDC user may specify the frequency with which a given banner is presented during a single rotation of the banner list (e.g., once every cycle through the list, twice per cycle through the list, etc.). The exemplary “Promo Banner” display 605 shown in
Continuing through the tabbed promotional popup design displays,
In the embodiment shown in
SDC User Interface: Template Design Objects
SDC User Interface: Carrier Policy Design
SDC User Interface: Subscriber Management
SDC User Interface: Reporting and Analytics
SDC User Interface: Service Design/Subscriber Management Sandbox
In the exemplary “Roles” display 695 of
Still referring to
SDC User Interface: Home Screen
The access network 802 can include a network that can provide network services to a device. The access network 802 can include a wireless network (e.g., WiFi, cellular, or some other wireless technology) and/or a wired network (e.g., LAN or DSL). Wireless or wired devices can be referred to as “on” the access network 802 when the devices complete relevant association, authentication, and/or other procedures that enable to devices to obtain the services offered on the access network 802 in accordance with applicable known or convenient techniques. Advantageously, the devices can have inter-network policies that are provided by the network service plan provisioning system 804 in accordance with techniques described in this paper. Inter-network policies, as the term is used in this paper, refer to traffic control, charging, and notification policies that remain in effect after a device passes from one network to another (e.g., by roaming). Intra-network policies, on the other hand, refer to control traffic control limited to the boundaries of a network (e.g., in-network traffic control, charging, and/or notification policies, plus an optional traffic control policy that permits or prevents roaming to another network).
It is likely that it will be desirable to couple the access network 802 to another network. Networks can include enterprise private networks and virtual private networks (collectively, private networks), which are well known to those of skill in computer networks. As the name suggests, private networks are under the control of an entity rather than being open to the public. Private networks include a head office and optional regional offices (collectively, offices). Many offices enable remote users to connect to the private network offices via some other network, such as the Internet, a public switched telephone network (PSTN), or the like. As used in this paper, a private network is intended to mean a network that is under the control of a single entity or hierarchy of entities. This is typically the case for cellular networks, wireless infrastructure networks, company LANs and WANs, and the like.
In the example of
It should be noted that a subscriber can be defined broadly to include any applicable device on the access network 802. For example, the access network 802 could include parking meter devices, food-dispensing machines, and automobile onboard computers, as well as smart phones and other devices frequently used by humans.
In the example of
The service design engine 806 inputs service plan data structures and other related data that is described later in more detail into the service plan datastore 808. Engines, as described in this paper, refer to computer-readable media coupled to a processor. The computer-readable media have data, including executable files, that the processor can use to transform the data and create new data. An engine can include a dedicated or shared processor and, typically, firmware or software modules that are executed by the processor. Depending upon implementation-specific or other considerations, an engine can be centralized or its functionality distributed. An engine can include special purpose hardware, firmware, or software embodied in a computer-readable medium for execution by the processor. As used in this paper, a computer-readable medium is intended to include all mediums that are statutory (e.g., in the United States, under 35 U.S.C. 101), and to specifically exclude all mediums that are non-statutory in nature to the extent that the exclusion is necessary for a claim that includes the computer-readable medium to be valid. Known statutory computer-readable mediums include hardware (e.g., registers, random access memory (RAM), non-volatile (NV) storage, to name a few), but may or may not be limited to hardware.
Datastores, as described in this paper, can be implemented, for example, as software embodied in a physical computer-readable medium on a general- or specific-purpose machine, in firmware, in hardware, in a combination thereof, or in an applicable known or convenient device or system. Datastores in this paper are intended to include any applicable organization of data, including tables, comma-separated values (CSV) files, traditional databases (e.g., SQL), or other applicable known or convenient organizational formats. Datastore-associated components, such as database interfaces, can be considered “part of” a datastore, part of some other system component, or a combination thereof, though the physical location and other characteristics of datastore-associated components is not critical for an understanding of the techniques described in this paper.
The service plan datastore 808 can store service plan data structures. As used in this paper, a data structure is associated with a particular way of storing and organizing data in a computer so that it can be used efficiently within a given context. Data structures are generally based on the ability of a computer to fetch and store data at any place in its memory, specified by an address, a bit string that can be itself stored in memory and manipulated by the program. Thus some data structures are based on computing the addresses of data items with arithmetic operations; while other data structures are based on storing addresses of data items within the structure itself. Many data structures use both principles, sometimes combined in non-trivial ways. The implementation of a data structure usually entails writing a set of procedures that create and manipulate instances of that structure.
In an example of a system where the service plan datastore 808 is implemented as a database, a database management system (DBMS) can be used to manage the service plan datastore 808. In such a case, the DBMS may be thought of as part of the service plan datastore 808 or as part of the service design engine 806 and/or the enforcement element provisioning instruction translation engine 812, or as a separate functional unit (not shown). A DBMS is typically implemented as an engine that controls organization, storage, management, and retrieval of data in a database. DBMSs frequently provide the ability to query, backup and replicate, enforce rules, provide security, do computation, perform change and access logging, and automate optimization. Examples of DBMSs include Alpha Five, DataEase, Oracle database, IBM DB2, Adaptive Server Enterprise, FileMaker, Firebird, Ingres, Informix, Mark Logic, Microsoft Access, InterSystems Cache, Microsoft SQL Server, Microsoft Visual FoxPro, MonetDB, MySQL, PostgreSQL, Progress, SQLite, Teradata, CSQL, OpenLink Virtuoso, Daffodil DB, and OpenOffice.org Base, to name several.
Database servers can store databases, as well as the DBMS and related engines. Any of the datastores described in this paper could presumably be implemented as database servers. It should be noted that there are two logical views of data in a database, the logical (external) view and the physical (internal) view. In this paper, the logical view is generally assumed to be data found in a report, while the physical view is the data stored in a physical storage medium and available to a specifically programmed processor. With most DBMS implementations, there is one physical view and an almost unlimited number of logical views for the same data.
A DBMS typically includes a modeling language, data structure, database query language, and transaction mechanism. The modeling language is used to define the schema of each database in the DBMS, according to the database model, which may include a hierarchical model, network model, relational model, object model, or some other applicable known or convenient organization. An optimal structure may vary depending upon application requirements (e.g., speed, reliability, maintainability, scalability, and cost). One of the more common models in use today is the ad hoc model embedded in SQL. Data structures can include fields, records, files, objects, and any other applicable known or convenient structures for storing data. A database query language can enable users to query databases, and can include report writers and security mechanisms to prevent unauthorized access. A database transaction mechanism ideally ensures data integrity, even during concurrent user accesses, with fault tolerance. DBMSs can also include a metadata repository; metadata is data that describes other data.
In a specific implementation, the service design engine 806 inputs policy enforcement priority rule data structures in the policy enforcement priority rule datastore 810. An aspect of policy control described in this paper entails the superposition of a first traffic classification filter of a service plan over a second traffic classification filter of the service plan. There is more than one way to accomplish this superposition including, for example, ordering the first and second traffic classification filter such that the first traffic classification filter is applied to a traffic event before the second traffic classification filter, trapping a match of the first traffic classification filter in a kernel until the second traffic classification filter is matched (then applying a first relevant action of an action list), or applying an explicit policy enforcement priority rule. Because implicit policy enforcement priorities can be used, the policy enforcement priority rule datastore 810 is optional. It should be noted that explicit policy enforcement priorities can be mandated in accordance with implementation- and/or configuration-specific parameters or a combination of implicit and explicit policy enforcement priorities can be used. In a specific implementation, explicit priorities trump implicit priorities (e.g., ordering).
In the example of
In the example of
In the example of
Network state can be associated with a network busy state (or, conversely, a network availability state). A network availability state can include, for example, a state or measure of availability/capacity of a segment of a network (e.g., a last edge element of a wireless network). A network busy state can include, for example, a state or measure of the network usage level or network congestion of a segment of a network (e.g., a last edge element of a wireless network). In some embodiments, network availability state and network busy state are inverse measures. As used herein with respect to certain embodiments, network availability state and network busy state can be used interchangeably based on, for example, a design choice (e.g., designing to assign background policies based on a network busy state or a network availability state yields similar results, but they are different ways to characterize the network performance and/or capacity and/or congestion). In some embodiments, network availability state and network busy state are dynamic measures as such states change based on network usage activities (e.g., based on a time of day, availability/capacity level, congestion level, and/or performance level). In some embodiments, differential network service usage control of a network service usage activity is based on a network busy state or network availability state. In a specific implementation, there are four levels of network busy state (not busy, light, medium, critical).
In the example of
Upon receipt of the service plan selection data, the service plan selection engine 822 can, if appropriate, select a new network provisioning instruction set in the network provisioning instruction set 814 for provisioning to the access network 802 in the manner described previously. (The service plan selection engine 822 may or may not be capable of triggering the service design engine 806 to modify a service plan, which is translated into a network provisioning instruction set for selection by the service plan selection engine 822.)
The collection of datastores 902 includes a filters datastore 910, a components datastore 912, a plans datastore 914, a rules datastore 918, a traffic control rule data structure 920, a charging data structure 922, and a notification data structure 924. The filters datastore 910 can include, for example, traffic control filter data structures that, when used, allow, block, throttle, delay (for a fixed period of time), and defer (until an event) a matched traffic event. Aspects of a traffic event to which a filter is mapped can include, for example, by remote destination, by application, by content (e.g., generic content such as streaming, specific content identifiable using regular expressions, etc.), by protocol, by port, by target operating system, to name several. In the context of service design, it has proven convenient to offer designers filter packages that combine a traffic control filter with an action. Such actions can include notify (which triggers a notification to be sent to a notification destination), cap (which increments a count), trap (which traps a match at the kernel level to see if another filter is matched later), and instructions (which can result in some other instruction to be executed).
The components datastore 912 can include, for example, a set of filter packages, including at least one filter, and a set of policies. Because components can inherit policy, it is not an explicit requirement that a component include at least one policy. However, when a component is assembled in a service plan offering, the component will have either a policy in the set of policies or will inherit a policy.
The plans datastore 914 can include, for example, a hierarchy of components. The components are organized into classes, which can include, for example, carrier, network protection, application (paid or sponsored), interceptor (marketing interceptor or parental control), bulk, post-bulk, and end-of-life. It at least one implementation, the end-of-life class is handled by a default, rather than a component that is stored in the components datastore 912.
The rules datastore 918 includes policy rules. For illustrative purposes, three policy type data structures are depicted as directed toward the rules datastore 918, traffic control policy data structure 920, charging policy data structure 922, and notification policy data structure 924. The traffic control policy data structure 920 can include a variety of filter packages designed to control the flow of traffic, such as allow or block, and take certain actions in association with the traffic control, such as cap-and-match. The charging policy data structure 922 can be directed to a user or a sponsor (who can subsidize network service usage) and can include a charging code.
The notification policy data structure 924 can be directed to a user, a sponsor, or an engine that takes further action in accordance with variables or constant parameters in the notification and can include content for use by the target of the notification and a trigger (e.g., a selectable button that results in the execution of relevant instructions). Notification types include plan limit thresholds (plan has reached a specified % of charging policy cap), plan cap limit (requested network activity has been capped because charging policy cap has been reached), plan limit overage (overage has reached a specified %; offer the option of overage, new service plan, block ongoing usage, etc.), plan expiration (plan expired; offer option to buy a new plan), activity block event (activity blocked by filter or activity state change), no capable plan (plan does not support the requested network activity, which has been blocked), marketing interceptor (specific message or offer based on current activity or status), promotional message (overview of what plan provides), upsell offer (upsell tiered plan based on current usage). Notification actions can be added to notifications to make them “actionable,” which means that a recipient of the notification can provide feedback or instructions in response to the notification. Notification actions can include, for example, OK/dismiss, cancel, acknowledge, buy (links to buy workflow), more info (e.g., more information regarding why a traffic event was blocked, suggestions for traffic activity changes or service plan purchase), back (call a previous workflow screen), next (call a next workflow screen), launch (launch URL or application). Notification customizations can include foreground, background, foreground/background (display in foreground if activity is in foreground and in background otherwise), title, subtitle, text, icon, buttons/actions, “do not show again” (will not show again for a specified time), default target button (specifies a default response action), or the like.
The collection of datastores associated with subscribers 904 includes a subscribers datastore 926 and a subscriber groups datastore 928. The subscribers datastore 926 includes subscriber data structures that include information about subscribers. A minimalist subscriber data structure is likely to at least include a subscriber identification that is unique within the system 900 or universally, such as an International Mobile Subscriber Identity (IMSI). It may also be useful to include such information as a phone number, device type, and/or International Mobile Equipment Identity (IMEI).
The subscriber groups datastore 928 includes subscriber group data structures that include groupings of subscribers. The types of groupings that can be done in a system depends upon the amount of information that is known about subscribers. For example, subscribers can be grouped by device type, device characteristics, demographic characteristics of the subscriber, region, etc.
The plan catalogs datastore 906 includes plan catalog data structures that are available to consumers or providers of network service plans. The plan catalog data structures are combinations of components from the collection of datastores associated with service plans 902 and the collection of datastores associated with subscribers 904.
The service design engine 908 can manage the datastores depicted in the example of
Screenshots of a user interface for a specific implementation of a service design engine, such as the service design engine 908, can be used to illustrate some of the functionality of the service design engine 908.
In the example of
The menu buttons field 1006 includes eight buttons, a subscribers button, a subscriber group button, a plans button, a plan catalogs button, a templates button, a reports button, a settings button, and a my profile button. Selecting the my profile button brings a designer to screenshot 1000B (
Selecting the settings button of the menu buttons field 1006 brings a designer to screenshot 1000C (
Selecting the subscribers button of the menu buttons field 1006 and selecting a new subscriber brings a designer to screenshot 1000F (
Selecting the subscriber groups button of the menu buttons field 1006 brings a designer to screenshot 1000G (
Selecting the plans button of the menu buttons field 1006 and selecting a new plan brings a designer to screenshot 1000I (
When the designer selects a component, such as the “Copy of No Youtube,” a component screenshot 1000L (
Selecting the filters tab from the tab menu 1012 brings the designer to screenshot 1000M (
Selecting the policy events tab from the tab menu 1012 and creating a new policy event brings the designer to screenshot 1000O (
Continuing to the next screenshot 1000Q (
Continuing to the next screenshot 1000R (
When returning to the plan level (see
Upon completion of the plan described with reference to
Referring back to the home page (see, e.g.,
When the designer selects the plan priorities tab from the tab menu 1018, the designer is brought to screenshot 1000W (
When the designer selects the tabs tab from the tab menu 1018, the designer is brought to screenshot 1000X (
When the designer selects the subscriber groups tab from the tab menu 1018, the designer is brought to screenshot 1000Y (
A Lacks Compatible Plan (LCP) error occurs when a traffic event is received for which there is no active service plan. LCP errors can be treated as a particular kind of policy event. As when designating the parameters of policy events, when the designer selects the LCP errors tab from the menu 1018, the designer has options similar to those described above with reference to
Upsells occur when offered from a component, plan, or plan catalog, and can be responsive to traffic events (e.g., an upsell for cheaper network service when using Facebook applications can occur when a subscriber consumes more expensive network services to use Facebook applications) or other events. When the designer selects the upsells tab from the menu 1018, the designer can edit upsell opportunities offered from, e.g., notifications within a plan catalog or any of its plans or components. Upsells can be edited much like policy events (e.g., properties, messages, and buttons).
Promotions can be offered once or periodically. When the designer selects the promotions tab from the menu 1018, the designer can edit a frequency of a promotion in screenshot 1000Z (
When the designer selects the review tab from the menu 1018, the designer can review the plan catalog as is illustrated in screenshot 1000AA (
Referring back to the home page (see, e.g.,
Selecting the reports button from the menu buttons field 1006 enables a designer to review reports.
In the example of
In the example of
In the example of
If, on the other hand, it is determined that there are no additional subscriber records to be created (1106-N), then the flowchart 1100 continues to module 1110 with creating a subscriber group record from subscriber records in the service design system subscriber datastore. A subscriber group record may or may not have a substantial amount of metadata. For example, a subscriber group record can be assigned a name and description to make it easier to use the subscriber group record when creating service plans for subscriber groups. An alternative field of the subscriber group record is common subscriber data, though this could also be considered part of the description.
In the example of
In the example of
In a specific implementation, a batch of subscriber data can be imported into the service design system and used to populate a subscriber group. It may be noted that the logical flow in the flowchart 1100 is to create subscriber records (1112) and store the subscriber records (1104) repeatedly (1106) and then create a subscriber group (1110) from subscriber records in the service design system subscriber datastore. However, it is not necessary for the import procedure to create each subscriber record before creating the subscriber group.
In a specific implementation, when a subscriber record with a characteristic that identifies the subscriber record as part of an existing subscriber group record is created and stored in the service design system subscriber datastore, that subscriber may or may not automatically be added to the existing subscriber group record (or an update procedure could add any subscriber records having the relevant characteristics that were not previously added to the subscriber group record when initiated by a subscriber or agent of the service design system).
Referring once again to decision point 1114, if it is determined that there are no additional subscriber group records to be created (1114-N), then the flowchart 1100 continues to decision point 1116 where it is determined whether there are additional subscriber records to be created. If it is determined that additional subscriber records are to be created (1116-Y), then the flowchart 1100 returns to module 1102 and continues as described previously. If, on the other hand, it is determined that no additional subscriber records are to be created (1116-N), then the flowchart ends. It may be noted that in a typical implementation, the method could be restarted at module 1102 or module 1110 if there is another subscriber record or another subscriber group record to be created. Therefore, the end is a logical end to the flowchart 1100, but the process can continue as needed.
In the example of
In a specific implementation, filter instances can be specified to be match or no match filters. A “match” filter does not prevent attempts to match a traffic event to another filter. A “no match” filter prevents a network traffic inspection engine from attempting to match a traffic event to another filter. In a sense, this applies an action to a filter, and the match and no match aspect of a filter can be treated as a filter aspect or an associated action aspect, whichever is more applicable in a given context.
In the example of
If, on the other hand, it is determined that there are no additional filter events to be created (1206-N), then the flowchart 1200 continues to module 1208 with creating a corresponding policy event rule record. The policy event rule enables a service plan component to determine what network state (including any network state) is applicable to a policy event. It may be noted that in a specific implementation, the rules can be created without a corresponding filter (e.g., as a stand-alone rule). The policy event rule becomes applicable when a filter matches a traffic event in a way that is specified by the rule. For example, if a traffic event matches a filter instance such that a network state is detected (e.g., in a network state, transitioning into the network state, or transitioning out of the network state), then a rule that specifies these conditions is applicable. Other examples of specified conditions are when a traffic event is allowed, blocked, throttled, delayed, or deferred, each which could be specified to be match or no match.
Policy rules can also define caps, which are met when a count of, e.g., time or bytes, reaches the defined cap. (It may be noted that a count can be considered part of a notification policy.) When a capped policy event has a counter increment to its defined cap, the filter can change from, e.g., allow (when the cap has not been exceeded) to block, throttle, delay, or defer (when the cap has been exceeded). The capped policy event could similarly go from, e.g., throttle (when the cap has not been exceeded) to throttle more (when the cap has been exceeded) or some other combination of filtering activity before and after a cap has been exceeded.
In the example of
Notification policy rules are associated with sending information to a party, such as a subscriber, human or non-human agent of a service design system, a program, etc. In a specific implementation, a notification policy record can be given a name and description, and notification details such as whether the notification is in the foreground or background, the destination of the notification (e.g., to a subscriber, to a server, or to some other party), and interaction that is enabled in association with the notification (e.g., number of times the notification is displayed before it is no longer displayed to a user or an option that enables a user to suppress the notification in the future). Notifications to subscribers and human agents of the service design system will typically include human-readable content, such as a title, subtitle, short text, and/or long text description. Notifications to non-human agents may or may not include the same information, and can include instruction sets that make little or no sense when read by a human. In a specific implementation, notifications can include variables that insert data from datastores, about network state, or other data that can vary over time. A service design agent can include selection options (e.g., buttons) in a notification that enable the recipient to provide feedback or instructions. Useful selection options might include, for example, upsell plans, a service offerings catalog, a request for more information, an indication that overage is desired, launching a URL, and/or dismiss. In a specific implementation, a service design system agent can use a graphical user interface that displays a mobile device with the notification as it would be displayed (perhaps without some icons or other features of the mobile device) to make review of the notification convenient.
Charging policy rules are associated with determining how much to bill for usage (in time or bytes). In a specific implementation, a service plan component can inherit charging policy from a plan in which the component is integrated. So, strictly speaking, in such an implementation, a service plan component record need not have a charging policy rule, though when deployed it can have a charging policy rule due to inheritance. Where the charging policy is defined for a component, the charging policy can be based on data used or time, may or may not have an overage allowance (with an optional maximum overage usage), and will have a rate, which can be specified with a charging code.
In the example of
In the example of
If it is determined that more policy event rule records corresponding to a filter record are to be created (1216-Y), then the flowchart 1200 returns to module 1208 and continues as described previously (though at module 1212, instead of creating a service plan component record, the service plan component record can be modified). If, on the other hand, it is determined that no more policy event rule records corresponding to a filter record are to be created (1216-N), then the flowchart 1200 ends.
It may be noted that in a typical implementation, the method could be restarted at module 1202, module 1208, or module 1212 if there is another filter instance, policy event rule record, or service plan component record to be created. Therefore, the end is a logical end to the flowchart 1200, but the process can continue as needed.
In the example of
In the example of
In the example of
Depending upon the implementation, service plan components can be designated to have a service class upon creation (or edit), or the component can be assigned to a service class when the component is added to the service plan. For example, a service plan component could be assigned to a “paid” service class, but could also function appropriately if assigned to a marketing intercept service class. Depending upon the implementation, the component could be designated “paid” upon creation and copied to create a similar “marketing intercept” component, or the component could be designated either paid or marketing intercept upon creation (or have no service class designation), and inserted into the relevant service class when arranged in a service plan. Thus, the hierarchical arrangement can be dynamic by service class (e.g., a designer can pick the class into which to arrange a component) or static by service class (e.g., the component is created within a service class). In a specific implementation, a service plan component with a static service class can be explicitly arranged by priority relative to other service plan components within the service class, a service plan component with a dynamically assigned service class can be explicitly arranged by priority relative to other service plan components within the service class, a service plan component with a static service class can be implicitly arranged by priority within the service class, and a service plan component with a dynamically assigned service class can be implicitly arranged by priority within the service class.
In the examples provided in this paper, the carrier service class is generally treated as the highest priority service class. Carrier plans will include basic network policy. In a specific implementation, carrier plans are automatically enforced on a subscriber device and are not offered in a plan catalog.
In the examples provided in this paper, the second highest priority service class, network protection, can be associated with policy designed to protect network resources (e.g., by detecting devices that are consuming too many network resources and throttling or blocking them). Network protection services can have variable billing policies that are selectable by a subscriber (e.g., to enable foreground processing as opposed to background processing, speed, etc.), but a subscriber may or may not have the ability to modify network protection policy, depending upon the implementation.
In the examples provided in this paper, the third highest priority service class, sponsored, can be associated with service plans that are sponsored in whole or in part by an entity other than the subscriber. Partially sponsored plans can be referred to as subsidized, though the term “sponsored” is intended to include subsidized plans unless otherwise indicated by context. Depending upon the implementation and/or configuration, sponsored plans may or may not be optional. For example, an employee of a company may have a sponsored service plan that is applicable when the employee accesses the company intranet, and the employee may or may not be able to decline the sponsorship. As another example, Facebook may subsidize network resource consumption when a subscriber accesses the Facebook website, and the subscriber may or may not be able to decline the subsidy.
In the examples provided in this paper, the fourth highest priority service class, paid, can be associated with service plans that a subscriber purchases. It is generally the case that a subscriber will be given the option to purchase a paid service plan through, e.g., an actionable service offer. (An actionable service offer is a notification that includes a feedback mechanism, such as an accept button, that a subscriber can select to accept the service offer.) Service offers can be triggered by predefined conditions, such as when a subscriber attempts to do something that a plan would help. (Service offers can also be triggered for sponsored services.)
In the examples provided in this paper, the fifth highest priority service class, parental control, can be associated with service plans that a subscriber purchases or modifies in accordance with an authentication process. Parental control plans can be associated with multi-(or single-) device plans for which a primary subscriber can set policy. Depending upon the implementation, different devices of a multi-device plan can also have different sponsored and paid plans.
In the examples provided in this paper, the sixth highest priority service class, market interceptor, can be associated with service plans that are offered to a subscriber before the subscriber drops to the bulk policy service class. Market interceptor plans can include service offers that are favorable to open access policy in some way.
In the examples provided in this paper, the seventh highest priority service class, open access or bulk, can be associated with a catch-all service plan.
In the examples provided in this paper, the eighth highest priority service class, post-bulk, can be associated with service plans that can be activated in the event no other service plan is applicable. In a specific implementation, post-bulk plans are designed to offer a subscriber a last chance to activate a service plan for something that the subscriber is trying to do, but is unable due to no service plan being available. If the subscriber responds appropriately to a notification, the subscriber may activate a service plan (e.g., a paid service plan) relevant to a present activity.
In the examples provided in this paper, the ninth highest priority service class, end-of-life, is typically associated with a notification that no service plan is available for a detected traffic event.
It is not necessary to utilize all service classes to take advantage of a service class hierarchy in specific implementations. It is also possible to move a class up or down relative to other classes in the hierarchy. For example, the network protection class could be given a priority below paid service class.
In the example of
In the example of
A service design engine can use a process, such as the example provided with reference to
In the example of
In the example of
In the example of
In the example of
In the example of
When a service plan catalog is published, the subscriber groups associated with service plans in the service plan catalog identify the subscribers, whether automatically or by selecting the plan, that will have the policies of the relevant service plan enforced on their devices. Depending upon the implementation, publication of a plan can be in beta, which generally means the subscribers to the plan can have the plan changed with or without notice, or deployed, which generally means that subscribers can expect changes to future versions of the plan will not impact them until they need to repurchase the (new version of) the plan.
In the example of
Upsell offers can include a suite of all possible choices, or can be limited to offers that are more suitable to the specific historical usage of a particular subscriber. For example, if a subscriber typically consumes around 5 MB of data per unit of time, the system need not provide upsell offers for 10 MB, 100 MB, 1 GB, 10 GB, and 100 GB all at once (even though all might be offered), and instead send an upsell offer of 10 MB only (or, e.g., 10 MB and 100 MB). If usage for the subscriber increases, the subscriber can be notified regarding the larger-size service plans.
The upsell offer could alternatively be added to a service plan component, but in a specific implementation, it was deemed useful to modify upsell offers, even those that might be identified within a service plan component, at the service plan catalog level. In this way, standard upsell components of, e.g., a Facebook plan, can be modified with appropriate notification or other configurations for a given service plan catalog or for specific subscriber groups.
In the example of
In the example of
Some examples of entities that might desire to include the service design sandbox 1508 in their networks include enterprises with employees that consume network services, MVNOs, application developers, gifters, and community-based organizations. In the case of enterprises with employees that consume network services, the service design sandbox 1508 can enable fine-tuned control over traffic control and charging policy (as well as notification policy). Assume that XYZ company controls the service design sandbox 1508. XYZ company can create a service plan specific to XYZ company network services on the XYZ company intranet, which will be referred to as the XYZ plan. Specifically, the XYZ company can sponsor the XYZ company network services on the XYZ company intranet for XYZ company employees. A paid plan offered by a carrier that controls the service design center 1506, for example, can still be available for XYZ company employees that are using other network services (or XYZ company could partially sponsor a subset of the other network services). The XYZ plan could also include a component that prevents XYZ company employees from accessing certain restricted sites through the XYZ company intranet and has notification policy associated with the attempted access. Continuing the example, an agent (e.g., IT manager) of the XYZ company can define subscriber groups that comprise XYZ company members and assign different service plans (e.g., different traffic control, notification, or charging policies) to the different XYZ company subscriber groups. For example, employees could get limited usage, managers might get access to more usage and additional services (e.g., email), members of the sales team might get better roaming services, and a CEO might get everything in the carrier's service plan offering, perhaps with XYZ company as a sponsor for all services. Advantageously, split-billing is possible using these techniques, such that XYZ company can pay for sponsored services and XYZ employees can pay for unsponsored services (or for a portion of subsidized services).
In the case of MVNOs, an MVNO can purchase bulk data from a carrier and offer plans based on the bulk. Advantageously for MVNOs, the service design sandbox 1508 enables control over subscribers based on, e.g., network state. Indeed, for all subscribers “owned” by the MVNO, a great deal of policy control can be applied (dependent upon the amount of control a carrier is willing to give to the MVNO). Other providers that can benefit from the sandbox model include mobile virtual network enablers (MVNEs), mobile shared spectrum enablers (MSSEs), and service providers (SPs).
In the case of application developers, the service design sandbox 1508 can specify applications that can be covered by a service plan. The service design center 1506 may or may not be responsible for creating the underlying control mechanism. For example, a company like amazon.com can be given some control over sponsorship settings for applications associated with amazon.com.
In the case of gifters, the service design sandbox 1508 can enable specification of a sponsorship amount that is donated to some other organization, such as a non-profit organization. In the case of community-based organizations, the service design sandbox 1508 can specify free access for a particular network service. For example, the San Francisco Giants organization could have a plan group for fans that grants free access to the official site of the San Francisco Giants. As another example, AAA could sponsor access to services for AAA members.
Agents of the network service plan provisioning system can be given roles that grant access to certain aspects of service design and/or provisioning. For example, agents at the service design center 1506 can have a role system administrator, super user, or the like, while agents of the service design sandbox 1508 can have roles such as enterprise IT manager, MVNO administrator, or the like. Agents of the service design sandbox 1508 can subdivide roles further, if applicable, depending upon implementation.
The service processor 1608 can be implemented on a client device on the carrier network 1602. In a specific implementation, the service processor 1608 includes a service control device link. For example, as device based service control techniques involving supervision across a network become more sophisticated, it becomes increasingly important to have an efficient and flexible control plane communication link between the device agents and the network elements communicating with, controlling, monitoring, or verifying service policy. In some embodiments, the service control device link provides the device side of a system for transmission and reception of service agent to/from network element functions. In some embodiments, the traffic efficiency of this link is enhanced by buffering and framing multiple agent messages in the transmissions. In some embodiments, the traffic efficiency is further improved by controlling the transmission frequency or linking the transmission frequency to the rate of service usage or traffic usage. In some embodiments, one or more levels of security or encryption are used to make the link robust to discovery, eavesdropping or compromise. In some embodiments, the service control device link also provides the communications link and heartbeat timing for the agent heartbeat function. The service control device link can provide an efficient and secure solution for transmitting and receiving service policy implementation, control, monitoring and verification information with other network elements.
In a specific implementation, a client dashboard is presented in a display device by the service processor 1608. The client dashboard can include the following menus: services (purchased, data usage), statistics (applications consuming data, data used in absolute terms or as a %), buy (navigates subscriber through activation, enrollment, plan selection, and purchase workflows), help, and settings (preferences, e.g., language).
The service controller 1610 can be implemented, e.g., in the cloud, and is coupled to the infrastructure 1604.
The operator SDC 1612 is on the Internet, and is coupled to the service controller. The operator SDC 1612 can set up boundaries for “sandboxed” service and allow customizations for partner sets; lock in master tariffs based on negotiated rates for a given partner set or individual partner; create custom log-ins for different partner sets or individual partners; and carry out any applicable techniques appropriate for a service design system. The operator SDC 1612 allows authorized agents to manage service plan components and subscribers. The agents can manage groups (collections of subscribers, SIMs, or devices) to create groups and group directories, assign an identity hierarchy for the operator, associated identifiers with groups, etc. The agents can manage service plans (including one or more components) including plan name and description, groups using the plan, service plan components, service activities, network busy states and connection types, charging policies (including usage limits, thresholds, frequency, time, and payment type), notifications (e.g., for plan usage thresholds, plan cap, expiration, block, overage, no capable plan, etc.), and events (e.g., for plan usage thresholds, plan cap, expiration, block, overage, etc.). The agents can manage service components (logical grouping of one or more filters and rules), including component name and description, plans using the component, network busy states and connection types, charging policies (including usage limits, thresholds, frequency, time and payment type), notifications (e.g., for plan usage thresholds, plan cap, expiration, block, overage, no capable plan, etc.), and events (e.g., for plan usage thresholds, plan cap, expiration, block, overage, etc.). The agents can manage service activities (e.g., activity name, plans using the activity, components using the activity, filter name and description, and filter type details (e.g., operating system, application, remote, port, protocol, etc.). The agents can manage service group plans including assign and publish plan group, create activation workflow screens, create buy workflow screens. The agents can receive, manage, customize, or generate reports for, for example, usage reports by destination for a subscriber over a period of time, usage reports by destination for a range of subscribers over a period of time (top destinations).
The partner SDC sandbox 1614 is coupled to the operator SDC 1612 in an applicable convenient fashion. The partner SDC sandbox 1614 can provide a secure login environment in which a subset of SDC service management controls can be designed and/or used; enable selection from bounded service customization options for one or more device groups under management; customize device UI branding; access real time analytics for service usage, application usage, location, etc.; set up service usage alerts, fraud alerts, theft alerts, etc.; and carry out any applicable techniques appropriate for a service design system that have been delegated to the sandboxed environment.
The service controller 1610 includes a service control server link. In some a specific implementation, device based service control techniques involving supervision across a network (e.g., on the control plane) are more sophisticated, and for such it is increasingly important to have an efficient and flexible control plane communication link between the device agents (e.g., of the service processor 1608) and the network elements (e.g., of the service controller 1610) communicating with, controlling, monitoring, or verifying service policy. For example, the communication link between the service control server link of service controller 1610 and the service control device link of the service processor 1610 can provide an efficient and flexible control plane communication link, a service control link; in some embodiments, this control plane communication link provides for a secure (e.g., encrypted) communications link for providing secure, bidirectional communications between the service processor 1608 and the service controller 1610. In some embodiments, the service control server link provides the network side of a system for transmission and reception of service agent to/from network element functions. In some embodiments, the traffic efficiency of this link is enhanced by buffering and framing multiple agent messages in the transmissions (e.g., thereby reducing network chatter). In some embodiments, the traffic efficiency is further improved by controlling the transmission frequency and/or linking the transmission frequency to the rate of service usage or traffic usage. In some embodiments, one or more levels of security and/or encryption are used to secure the link against potential discovery, eavesdropping or compromise of communications on the link. In some embodiments, the service control server link also provides the communications link and heartbeat timing for the agent heartbeat function. In some embodiments, the service control server link provides for securing, signing, encrypting and/or otherwise protecting the communications before sending such communications over the service control link. For example, the service control server link can send to the transport layer or directly to the link layer for transmission. In another example, the service control server link further secures the communications with transport layer encryption, such as TCP TLS or another secure transport layer protocol. As another example, the service control server link can encrypt at the link layer, such as using IPSEC, various possible VPN services, other forms of IP layer encryption and/or another link layer encryption technique.
In a specific implementation, the service controller 1610 can include an access control integrity server (e.g., service policy security server). In some embodiments, the access control integrity server collects device information on service policy, service usage, agent configuration, and/or agent behavior. For example, the access control integrity server can cross check this information to identify integrity breaches in the service policy implementation and control system. In another example, the access control integrity server can initiate action when a service policy violation (e.g., QoS policy violation and/or a network capacity controlled services policy violation) or a system integrity breach is suspected.
In a specific implementation, an agent of the service controller 1610 (and/or some other agent of the access control integrity server) acts on access control integrity agent (e.g., service policy security agent) reports and error conditions. Many of the access control integrity agent checks can be accomplished by the server. For example, the access control integrity agent checks include one or more of the following: service usage measure against usage range consistent with policies (e.g., usage measure from the network and/or from the device); configuration of agents; operation of the agents; and/or dynamic agent download.
In a specific implementation, an agent of the service controller 1610 (and/or some other agent of the access control integrity server) verifies device service policy implementations by comparing various service usage measures (e.g., based on network monitored information, such as by using IPDRs or CDRs, and/or local service usage monitoring information) against expected service usage behavior given the policies that are intended to be in place (e.g., a QoS policy and/or a network capacity controlled services policy). For example, device service policy implementations can include measuring total QoS data passed, QoS data passed in a period of time, IP addresses, data per IP address, and/or other measures such as location, downloads, email accessed, URLs, and comparing such measures expected service usage behavior given the policies that are intended to be in place.
In a specific implementation, an agent of the service controller 1610 (and/or some other agent of the access control integrity server) verifies device service policy, and the verification error conditions that can indicate a mismatch in QoS service measure and QoS service policy include one or more of the following: unauthorized network access (e.g., access beyond ambient service policy limits); unauthorized network speed (e.g., average speed beyond service policy limit); network data amount does not match QoS policy limit (e.g., device not stop at limit without re-up/revising service policy); unauthorized network address; unauthorized service usage (e.g., VOIP, email, and/or web browsing); unauthorized application usage (e.g., email, VOIP, email, and/or web); service usage rate too high for plan, and policy controller not controlling/throttling it down; and/or any other mismatch in service measure and service policy. Accordingly, in some embodiments, an agent of the service controller 1610 (and/or some other agent of the access control integrity server) provides a policy/service control integrity service to continually (e.g., periodically and/or based on trigger events) verify that the service control of the device has not been compromised and/or is not behaving out of policy (e.g., a QoS policy and/or a network capacity controlled services policy).
In a specific implementation, the service controller 1610 includes a service history server (e.g., charging server). In some embodiments, the service history server collects and records service usage or service activity reports from, e.g., an access network AAA server and/or a service monitor agent of the service controller 1610. For example, although service usage history from the network elements can in certain embodiments be less detailed than service history from the device, the service history from the network can provide a valuable source for verification of device service policy implementation, because, for example, it is extremely difficult for a device error or compromise event on the device to compromise the network based equipment and software. For example, service history reports from the device can include various service tracking information, as similarly described above. In some embodiments, the service history server provides the service history on request to other agents of the service controller 1610, other servers, and/or one or more other agents. In some embodiments, the service history server provides the service usage history to the device service history (e.g., CDR feed and CDR mediation). In some embodiments, for purposes of facilitating the activation tracking service functions (described below), the service history server maintains a history of which networks the device has connected to. For example, this network activity summary can include a summary of the networks accessed, activity versus time per connection, and/or traffic versus time per connection. As another example, this activity summary can further be analyzed or reported to estimate the type of service plan associated with the traffic activity for the purpose of bill sharing reconciliation.
In a specific implementation, the service controller 1610 includes a policy management server (e.g., policy decision point (PDP) server) for managing service usage policies, such as QoS policies and/or a network capacity controlled services policies. In some embodiments, the policy management server transmits policies to the service processor 1608 via the service control link. In some embodiments, the policy management server manages policy settings on the device (e.g., various policy settings as described herein with respect to various embodiments) in accordance with a device service profile. In some embodiments, the policy management server sets instantaneous policies on policy implementation agents (e.g., policy implementation agent). For example, the policy management server can issue policy settings, monitor service usage and, if necessary, modify policy settings. For example, in the case of a user who prefers for the network to manage their service usage costs, or in the case of any adaptive policy management needs, the policy management server can maintain a relatively high frequency of communication with the device to collect traffic and/or service measures and issue new policy settings. In this example, device monitored service measures and any user service policy preference changes are reported, periodically and/or based on various triggers/events/requests, to the policy management server. In this example, user privacy settings generally require secure communication with the network (e.g., a secure service control link), such as with the policy management server, to ensure that various aspects of user privacy are properly maintained during such configuration requests/policy settings transmitted over the network. For example, information can be compartmentalized to service policy management and not communicated to other databases used for CRM for maintaining user privacy.
In some embodiments, the policy management server provides adaptive policy management on the device. For example, the policy management server can issue policy settings and objectives and rely on the device based policy management (e.g., service processor 1608) for some or all of the policy adaptation. This approach can require less interaction with the device thereby reducing network chatter on the service control link for purposes of device policy management (e.g., network chatter is reduced relative to various server/network based policy management approaches described above). This approach can also provide robust user privacy embodiments by allowing the user to configure the device policy for user privacy preferences/settings so that, for example, sensitive information (e.g., geo-location data, website history, and/or other sensitive information) is not communicated to the network without the user's approval. In some embodiments, the policy management server adjusts service policy based on time of day. In some embodiments, the policy management server receives, requests, and/or otherwise obtains a measure of network availability/capacity and adjusts traffic shaping policy and/or other policy settings based on available network availability/capacity (e.g., a network busy state).
In a specific implementation, the service controller 1610 includes a network traffic analysis server. In some embodiments, the network traffic analysis server collects/receives service usage history for devices and/or groups of devices and analyzes the service usage. In some embodiments, the network traffic analysis server presents service usage statistics in various formats to identify improvements in network service quality and/or service profitability. In some embodiments, the network traffic analysis server estimates the service quality and/or service usage for the network under variable settings on potential service policies. In some embodiments, the network traffic analysis server identifies actual or potential service behaviors by one or more devices that are causing problems for overall network service quality or service cost. In some embodiments, the network traffic analysis server estimates the network availability/capacity for the network under variable settings on potential service policies. In some embodiments, the network traffic analysis server identifies actual or potential service behaviors by one or more devices that are impacting and/or causing problems for overall network availability/capacity.
In a specific implementation, the service controller 1610 includes a beta test server (e.g., policy creation point and beta test server). In some embodiments, the beta test server publishes candidate service plan policy settings to one or more devices. In some embodiments, the beta test server provides summary reports of network service usage or user feedback information for one or more candidate service plan policy settings. In some embodiments, the beta test server provides a mechanism to compare the beta test results for different candidate service plan policy settings or select the optimum candidates for further policy settings optimization, such as for protecting network capacity.
In a specific implementation, the service controller 1610 includes a service download control server (e.g., a service software download control server). In some embodiments, the service download control server provides a download function to install and/or update service software elements (e.g., the service processor 1608 and/or agents/components of the service processor 1608) on the device, as described herein.
In a specific implementation, the service controller 1610 includes a billing event server (e.g., micro-CDR server). In some embodiments, the billing event server collects billing events, provides service plan information to the service processor 1608, provides service usage updates to the service processor 1608, serves as interface between device and central billing server, and/or provides trusted third party function for certain ecommerce billing transactions.
In a specific implementation, the service processor 1608 provides an additional layer of access control. For example, an access network AAA server can provide necessary access network AAA services (e.g., access control and authorization functions for the device access layer) to allow the devices onto the central provider access network and the service provider network. In some embodiments, another layer of access control is required for the device to gain access to other networks, such as the Internet, a corporate network and/or a machine to machine network. In some embodiments, the Access Network AAA server also provides the ability to suspend service for a device and resume service for a device based on communications received from the service controller 1610. In some embodiments, the Access Network AAA server also provides the ability to direct routing for device traffic to a quarantine network or to restrict or limit network access when a device quarantine condition is invoked. In some embodiments, the Access Network AAA server also records and reports device network service usage.
In some embodiments, different profiles are selected based on the selected network connection (e.g., different service profiles/policies for WWAN, WLAN, WPAN, Ethernet and/or DSL network connections), which can be referred to as multimode profile setting. For example, service profile settings can be based on the actual access network (e.g., home DSL/cable or work network) behind the Wi-Fi not the fact that it is Wi-Fi (e.g., or any other network, such as DSL/cable, satellite, or T-1), which is viewed as different than accessing a Wi-Fi network at the coffee shop. For example, in a Wi-Fi hotspot situation in which there are a significant number of users on a DSL or T-1 backhaul, the service controller can sit in a service provider cloud or an MVNO cloud, the service controls can be provided by a VSP capability offered by the service provider or the service controller 1610 can be owned by the hotspot service provider that uses the service controller 1610 on their own without any association with an access network service provider. For example, the service processor 1608 can be controlled by the service controller 1610 to divide up the available bandwidth at the hotspot according to QoS or user sharing rules (e.g., with some users having higher differentiated priority (e.g., potentially for higher service payments) than other users). As another example, ambient services (e.g., as similarly described herein) can be provided for the hotspot for verified service processors.
In some embodiments, the service processor 1608 and service controller 1610 are capable of assigning multiple service profiles associated with multiple service plans that the user chooses individually or in combination as a package. For example, a device starts with ambient services that include free transaction services wherein the user pays for transactions or events rather than the basic service (e.g., a news service, eReader, PND service, pay as you go session Internet) in which each service is supported with a bill by account capability to correctly account for any subsidized partner billing to provide the transaction services (e.g., Barnes and Noble may pay for the eReader service and offer a revenue share to the service provider for any book or magazine transactions purchased from the device). In some embodiments, the bill by account service can also track the transactions and, in some embodiments, advertisements for the purpose of revenue sharing, all using the service monitoring capabilities disclosed herein. After initiating services with the free ambient service discussed above, the user may later choose a post-pay monthly Internet, email, and SMS service. In this case, the service controller 1610 would obtain from the billing system in the case of network based billing (e.g., or the service controller 1610 billing event server in the case of device based billing) the billing plan code for the new Internet, email and SMS service. In some embodiments, this code is cross referenced in a database (e.g., the policy management server) to find the appropriate service profile for the new service in combination with the initial ambient service. The new superset service profile is then applied so that the user maintains free access to the ambient services, and the billing partners continue to subsidize those services, the user also gets access to Internet services and may choose the service control profile (e.g., from one of the embodiments disclosed herein). The superset profile is the profile that provides the combined capabilities of two or more service profiles when the profiles are applied to the same device service processor. In some embodiments, the service processor 1608 can determine the superset profile rather than the service controller 1610 when more than one “stackable” service is selected by the user or otherwise applied to the device. The flexibility of the service processor 1608 and service controller 1610 embodiments described herein allow for a large variety of service profiles to be defined and applied individually or as a superset to achieve the desired device service features.
In some embodiments, device assisted services (DAS) techniques for providing an activity map for classifying or categorizing service usage activities to associate various monitored activities (e.g., by URL, by network domain, by website, by network traffic type, by application or application type, and/or any other service usage activity categorization/classification) with associated IP addresses are provided. In some embodiments, a policy control agent, service monitor agent (e.g., charging agent), or another agent or function (or combinations thereof) of the service processor 1608 provides a DAS activity map. In some embodiments, a policy control agent, service monitor agent, or another agent or function (or combinations thereof) of the service processor provides an activity map for classifying or categorizing service usage activities to associate various monitored activities (e.g., by Uniform Resource Locator (URL), by network domain, by website, by network traffic type, by socket (such as by IP address, protocol, and/or port), by socket id (such as port address/number), by port number, by content type, by application or application type, and/or any other service usage activity classification/categorization) with associated IP addresses and/or other criteria/measures. In some embodiments, a policy control agent, service monitor agent, or another agent or function (or combinations thereof) of the service processor determines the associated IP addresses for monitored service usage activities using various techniques to snoop the DNS request(s) (e.g., by performing such snooping techniques on the device 100 the associated IP addresses can be determined without the need for a network request for a reverse DNS lookup). In some embodiments, a policy control agent, service monitor agent, or another agent or function (or combinations thereof) of the service processor records and reports IP addresses or includes a DNS lookup function to report IP addresses or IP addresses and associated URLs for monitored service usage activities. For example, a policy control agent, service monitor agent, or another agent or function (or combinations thereof) of the service processor can determine the associated IP addresses for monitored service usage activities using various techniques to perform a DNS lookup function (e.g., using a local DNS cache on the monitored device). In some embodiments, one or more of these techniques are used to dynamically build and maintain a DAS activity map that maps, for example, URLs to IP addresses, applications to IP addresses, content types to IP addresses, and/or any other categorization/classification to IP addresses as applicable. In some embodiments, the DAS activity map is used for various DAS traffic control and/or throttling techniques as described herein with respect to various embodiments for providing QoS for DAS and/or for providing DAS for protecting network capacity. In some embodiments, the DAS activity map is used to provide the user various UI related information and notification techniques related to service usage as described herein with respect to various embodiments. In some embodiments, the DAS activity map is used to provide service usage monitoring, prediction/estimation of future service usage, service usage billing (e.g., bill by account and/or any other service usage/billing categorization techniques), DAS techniques for ambient services usage monitoring, DAS techniques for generating micro-CDRs, and/or any of the various other DAS related techniques as described herein with respect to various embodiments.
In some embodiments, a network service usage control policy is dynamic based on one or more of the following: a network busy state, a time of day, which network the service activity is connected to, which base station or communication channel the service activity is connected to, a user input, a user preference selection, an associated service plan, a service plan change, an application behavior, a messaging layer behavior, random back off, a power state of device, a device usage state, a time based criteria (e.g., time/day/week/month, hold/delay/defer for future time slot, hold/delay/defer for scheduled time slot, and/or hold/delay/defer until a busy state/availability state/QoS state is achieved), monitoring of user interaction with the service activity, monitoring of user interaction with the device, the state of UI priority for the service activity, monitoring the power consumption behavior of the service activity, modem power cycling or power control state changes, modem communication session set up or tear down, and/or a policy update/modification/change from the network. In some embodiments, the network service usage control policy is based on updated service usage behavior analysis of the network service usage activity. In some embodiments, the network service usage control policy is based on updated activity behavior response to a network capacity controlled service classification. In some embodiments, the network service usage control policy is based on updated user input/preferences (e.g., related to policies/controls for network capacity controlled services). In some embodiments, the network service usage control policy is based on updates to service plan status. In some embodiments, the network service usage control policy is based on updates to service plan policies. In some embodiments, the network service usage control policy is based on availability of alternative networks. In some embodiments, the network service usage control policy is based on policy rules for selecting alternative networks. In some embodiments, the network service usage control policy is based on network busy state or availability state for alternative networks. In some embodiments, the network service usage control policy is based on specific network selection or preference policies for a given network service activity or set of network service activities.
In some embodiments, associating the network service usage activity with a network service usage control policy or a network service usage notification policy, includes dynamically associating based on one or more of the following: a network busy state, a time of day, a user input/preference, an associated service plan (e.g., 25 MB data plan, 5G data plan, or an unlimited data plan or other data/service usage plan), an application behavior, a messaging layer behavior, a power state of device, a device usage state, a time based criteria, availability of alternative networks, and a set of policy rules for selecting and/or controlling traffic on one or more of the alternative networks.
In some embodiments, a network service usage control policy (e.g., a network capacity controlled services policy) includes defining the network service usage control policy for one or more service plans, defining network access policy rules for one or more devices or groups of devices in a single or multi-user scenarios such as family and enterprise plans, defining network access policy rules for one or more users or groups of users, allowing or disallowing network access events or attempts, modulating the number of network access events or attempts, aggregating network access events or attempts into a group of access events or attempts, time windowing network access events or attempts, time windowing network access events or attempts based on the application or function being served by the network access events or attempts, time windowing network access events or attempts to pre-determined time windows, time windowing network access events or attempts to time windows where a measure of network busy state is within a range, assigning the allowable types of access events or attempts, assigning the allowable functions or applications that are allowed network access events or attempts, assigning the priority of one or more network access events or attempts, defining the allowable duration of network access events or attempts, defining the allowable speed of network access events or attempts, defining the allowable network destinations for network access events or attempts, defining the allowable applications for network access events or attempts, defining the QoS rules for one or more network access events or attempts, defining or setting access policy rules for one or more applications, defining or setting access policy rules for one or more network destinations, defining or setting access policy rules for one or more devices, defining or setting access policy rules for one or more network services, defining or setting access policy rules for one or more traffic types, defining or setting access policy rules for one or more QoS classes, and defining or setting access policy rules based on any combination of device, application, network destination, network service, traffic type, QoS class, and/or other criteria/measures.
In some embodiments, a network service usage control policy (e.g., a network capacity controlled services policy) includes a traffic control policy. In some embodiments, the traffic control policy includes a traffic control setting. In some embodiments, the traffic control policy includes a traffic control/tier, and the traffic control/tier includes the traffic control setting. In some embodiments, the traffic control policy includes one or more of the following: block/allow settings, throttle settings, adaptive throttle settings, QoS class settings including packet error rate, jitter and delay settings, queue settings, and tag settings (e.g., for packet tagging certain traffic flows). In some embodiments, QoS class settings, include one or more of the following: throttle level, priority queuing relative to other device traffic, time window parameters, and hold or delay while accumulating or aggregating traffic into a larger stream/burst/packet/group of packets. In some embodiments, the traffic control policy includes filters implemented as indexes into different lists of policy settings (e.g., using cascade filtering techniques), in which the policy filters include one or more of the following: a network, a service plan, an application, a time of day, and a network busy state. For example, a two dimensional traffic control implementation scheme can be provided using a network busy state and/or a time of day as an index into a traffic control setting (e.g., a certain application's priority level can be increased or decreased based on a network busy state and/or time of day). In some embodiments, the traffic control policy is used for selecting the network from a list of available networks, blocking or reducing access until a connection is made to an alternative network, and/or modifying or replacing a network stack interface of the device to provide for intercept or discontinuance of network socket interface messages to applications or OS functions.
In some embodiments, a traffic control setting is selected based on the network service usage control policy. In some embodiments, the traffic control setting is implemented on the device based on the network service usage control policy. In some embodiments, the implemented traffic control setting controls traffic/traffic flows of a network capacity controlled service. In some embodiments, the traffic control setting is selected based on one or more of the following: a time of day, a day of week, a special time/date (e.g., a holiday or a network maintenance time/date), a network busy state, a priority level associated with the network service usage activity, a QoS class associated with the network service usage activity (e.g., emergency traffic), which network the network service activity is gaining access from, which networks are available, which network the network service activity is connected to, which base station or communication channel the network service activity is connected to, and a network dependent set of traffic control policies that can vary depending on which network the service activity is gaining access from (e.g., and/or various other criteria/measures as described herein). In some embodiments, the traffic control setting includes one or more of the following: allow/block, delay, throttle, QoS class implementation, queue, tag, generate a user notification, random back off, clear to send received from a network element, hold for scheduled transmission time slot, selecting the network from the available networks, and blocking or reducing access until a connection is made to an alternative network. In some embodiments, the traffic control setting is selected based on a network capacity controlled services priority state of the network service usage activity and a network busy state. In some embodiments, the traffic control setting is selected based on a network capacity controlled services priority state of the network service usage activity and a network busy state and is global (e.g., the same) for all network capacity controlled services activities or varies based on a network service usage activity priority, user preferences or option selection, an application, a time based criteria, a service plan, a network the device or service activity is gaining access from, a redetermination of a network congestion state after adapting to a previously determined network busy state, and/or other criteria/measures as described herein.
In some embodiments, network capacity controlled services traffic (e.g., traffic flows) is differentially controlled for protecting network capacity. For example, various software updates for an OS and one or more applications on the device can be differentially controlled using the various techniques described herein. As another example, security/antimalware software (e.g., antivirus, firewall, content protection, intrusion detection/prevention, and/or other security/antimalware software) can be differentially controlled using the various techniques described herein. As yet another example, network backups/imaging, content downloads (e.g., exceeding a threshold individually and/or in aggregate, such as for image, music, video, eBook content, email attachments, content/media subscriptions, RSS/news feeds, text/image/video chat, software updates, and/or other content downloads) can be differentially controlled using the various techniques described herein.
For example, using the DAS for protecting network capacity techniques described herein an adaptive policy control for protecting network capacity can be provided. A network capacity controlled services list can be generated, updated, reported, and/or received by the device and stored on the device (e.g., the list can be based on adapted to the service plan associated with the device). If a monitored network service usage activity is not on the list, then the device can report the monitored network service usage activity to a network element (e.g., for a monitored network service usage activity that also exceeds a certain threshold, based on a network busy state, based on a time based criteria, and/or other criteria/measure). As an example, monitored network service usage activity can be reported if/when the monitored network service usage activity exceeds a data usage threshold (e.g., 50 MB total data usage per day, a socket opening frequency/rate, velocity of data usage at an instant in time, or more complicated thresholds over time, over peak periods, by content and time, by various other parameters/thresholds). As another example, the monitored network service usage activity can be reported based on testing of the network service usage behavior and/or application developer characterization input. The report can include information that identifies the network service usage activity and various network service usage parameters.
In some embodiments, a notification setting is selected based on a service usage notification policy. In some embodiments, a notification setting includes a user notification setting (e.g., various user notifications settings as described above with respect to
In some embodiments, classifying the network service usage activity further includes classifying the network service usage activity (e.g., using a usage threshold filter and/or cascading filter techniques) into one or more of a plurality of classification categories for differential network access control for protecting network capacity. In some embodiments, classifying the network service usage activity, further includes classifying the network service usage activity into one or more network capacity controlled services in which the network capacity controlled services include one or more of the following: applications requiring data network access, application software updates, applications requiring network information, applications requiring GPS or physical location, operating system software updates, security software updates, network based backups, email downloads, and a set of activities configured as network capacity controlled service activities based on a service profile and/or user input (e.g., and/or various other types of network service usage activities as described herein and as will now be apparent to one of ordinary skill in the art). For example, network capacity controlled services can include software updates for OS and applications, OS background network accesses, cloud synchronization services, RSS feeds & other background information feeds, browser/application/device behavior reporting, background email downloads, content subscription service updates and downloads (e.g., music/video downloads, news feeds), text/voice/video chat clients, security updates (e.g., antimalware updates), peer to peer networking application updates, inefficient network access sequences during frequent power cycling or power save state cycling, large downloads or other high bandwidth accesses, and greedy application programs that constantly/repeatedly access the network with small transmissions or requests for information. In some embodiments, a network capacity controlled services list is static, adaptive, generated using a service processor, received from a network element (e.g., service controller or service cloud), received from a network element (e.g., service controller or service cloud) and based at least in part on device activity reports received from the service processor, based on criteria set by pre-testing, report of behavior characterization performed by the application developer, and/or based at least in part on user input. In some embodiments, the network capacity controlled services list includes one or more network service activity background (QoS) classes.
In some embodiments, classifying the network service usage activity further includes classifying the network service usage activity based on one or more of the following: application or widget (e.g., Outlook, Skype, iTunes, Android email, weather channel weather widget, iCal, Firefox Browser, etc.), application type (e.g., user application, system application/utility/function/process, OS application/utility/function/process, email, browser, widget, malware (such as a virus or suspicious process), RSS feed, device synchronization service, download application, network backup/imaging application, voice/video chat, peer to peer content application or other peer to peer application, streaming media feed or broadcast reception/transmission application, network meeting application, chat application or session, and/or any other application or process identification and categorization), OS/system function (e.g., any system application/utility/function/process and/or OS application/utility/function/process, such as a OS update and/or OS error reporting), modem function, network communication function (e.g., network discovery or signaling, EtherType messages, connection flow/stream/session set up or tear down, network authentication or authorization sequences, IP address acquisition, and DNS services), URL and/or domain, destination/source IP address, protocol, traffic type, socket (e.g., IP address, protocol, and/or port), socket address/label/identifier (e.g., port address/port number), content type (e.g., email downloads, email text, video, music, eBooks, widget update streams, and download streams), port (e.g., port number), QoS classification level, time of day, on peak or off peak, network time, network busy state, access network selected, service plan selected, user preferences, device credentials, user credentials, and/or status, modem power cycling or power state changes, modem authentication processes, modem link set up or tear down, modem management communications, modem software or firmware updates, modem power management information, device power state, and modem power state. In some embodiments, classifying the network service usage activity further includes associating the classified network service usage activity with an ID (e.g., an application ID, which can be, for example, a unique number, name, and/or signature). In some embodiments, classifying the network service usage activity further includes classifying the network service usage activity using a plurality of classification parameters, including one or more of the following: application ID, remote IP (e.g., URL, domain, and/or IP address), remote port, protocol, content type, a filter action class (e.g., network busy state class, QoS class, time of day, network busy state, and/or other criteria/measures), and access network selected. In some embodiments, classifying the network service usage activity further includes using a combination of parameters as discussed above to determine the classification of the network service usage activity.
In some embodiments, classifying the network service usage activity further includes classifying the network service usage activity as a network capacity controlled service, a non-network capacity controlled service, a blocked or disallowed service, and/or a not yet classified/identified service (e.g., unknown/yet to be determined classification or pending classification). In some embodiments, an application connection, OS connection, and/or other service activity is classified as a network capacity controlled service activity when the device has been inactive (e.g., or in a power save state) for a period of time (e.g., when the user has not interacted with it for a period of time, when it has not displayed user notification policy, and/or a user input has not been received for a period of time, and/or when a power save state is entered). In some embodiments, an application connection, OS connection, and/or other service activity is classified as a network capacity controlled service activity when the monitored network service usage activity exceeds a data usage threshold for more than one application connection, OS connection, and/or other service activity (e.g., aggregated data usage exceeds the data usage threshold); or for a specific application connection. In some embodiments, an application connection, OS connection, and/or other service activity is classified as a network capacity controlled service activity when the monitored network service usage activity exceeds a data usage threshold based on a predetermined list of one or more data usage limits, based on a list received from a network element, usage time limit (e.g., based on a period of time exceeding a usage limit), and/or based on some other usage related criteria/measures. In some embodiments, classifying the network service usage activity further includes classifying the network service usage activity as a network capacity controlled service based on a network peak time, a network busy state, or a network connection to the device falls below a certain performance level (e.g., higher/lower priorities assigned based on various such criteria/other input/factors).
In some embodiments, one or more of the network capacity controlled services are associated with a different network access policy set for one or more networks and/or one or more alternative networks. In some embodiments, one or more of the network capacity controlled services are associated with a different notification policy set for one or more networks and/or one or more alternative networks. In some embodiments, the network capacity controlled services list is stored on the device. In some embodiments, the network capacity controlled services list is received/periodically updated from a network element and stored on the device. In some embodiments, the network capacity controlled services list includes network capacity controlled services, non-network capacity controlled services (e.g., foreground services or services based on various possibly dynamic criteria are not classified as network capacity controlled services), and an unclassified set of services (e.g., grey list including one or more network service activities pending classification based on further analysis and/or input, such as from a network element, service provider, and/or user). In some embodiments, the network capacity controlled services list is based on one or more of the following:
predefined/predesignated (e.g., network, service plan, pre-test and/or characterized by an application developer) criteria; device assisted/based monitoring (e.g., using a service processor); network based monitoring (e.g., using a DPI gateway); network assisted analysis (e.g., based on device reports of DAS activity analysis). For example, the device can report device monitored network service usage activities (e.g., all monitored network service usage activities or a subset based on configuration, threshold, service plan, network, and/or user input) to the network element. As another example, the network element can update the network capacity controlled services list and send the updated list to the device. As yet another example, the network element can perform a statistical analysis of network service activities across a plurality of devices based on the device based and/or network based network service usage activity monitoring/reporting. In some embodiments, a network service usage activity is determined to be an active application or process (e.g., based on a user interaction with the device and/or network service usage activity, such as a pop-up and/or other criteria/measures).
In some embodiments, implementing traffic control for network capacity controlled services is provided using various techniques. In some embodiments, the device includes a service processor agent or function to intercept, block, modify, remove or replace UI messages, notifications or other UI communications generated by a network service activity that whose network service usage is being controlled or managed (e.g., using various measurement points). For example, this technique can be used to provide for an improved user experience (e.g., to prevent an application that is being controlled for protecting network capacity from generating repeated and/or confusing messages/alerts to the user). In some embodiments, a network stack interface of the device is replaced or modified to provide for intercept or discontinuance of network socket interface messages to applications or OS functions or other functions/software.
In some embodiments, implementing traffic control for network capacity controlled services using DAS techniques is provided using various techniques in which the network service usage activity is unaware of network capacity control (e.g., does not support an API or other interface for implementing network capacity control). For example, network service application messaging interface based techniques can be used to implement traffic control. Example network service application messaging interfaces include the following: network stack API, network communication stream/flow interface, network stack API messages, EtherType messages, ARP messages, and/or other messaging or other or similar techniques as will now be apparent to one of ordinary skill in the art in view of the various embodiments described herein. In some embodiments, network service usage activity control policies or network service activity messages are selected based on the set of traffic control policies or service activity messages that result in reduced or modified user notification by the service activity due to network capacity controlled service policies applied to the network service activity. In some embodiments, network service usage activity control policies or network service activity messages are selected based on the set of traffic control policies or service activity messages that result in reduced disruption of device operation due to network capacity controlled service activity policies applied to the network service activity. In some embodiments, network service usage activity control policies or network service activity messages are selected based on the set of traffic control policies or service activity messages that result in reduced disruption of network service activity operation due to network capacity controlled service activity policies applied to the network service activity. In some embodiments, implementing traffic control for network capacity controlled services is provided by intercepting opens/connects/writes. In some embodiments, implementing traffic control for network capacity controlled services is provided by intercepting stack API level or application messaging layer requests (e.g., socket open/send requests). For example, an intercepted request can be copied (e.g., to memory) and queued (e.g., delayed or throttled) or dropped (e.g., blocked). As another example, an intercepted request can be copied into memory and then a portion of the transmission can be retrieved from memory and reinjected (e.g., throttled). As yet another example, intercepting messaging transmissions can be parsed inline and allowed to transmit (e.g., allowed), and the transmission or a portion of the transmission can be copied to memory for classifying the traffic flow. In some embodiments, implementing traffic control for network capacity controlled services is provided by intercepting or controlling or modulating UI notifications. In some embodiments, implementing traffic control for network capacity controlled services is provided by killing or suspending the network service activity. In some embodiments, implementing traffic control for network capacity controlled services is provided by deprioritizing the process(es) associated with the service activity (e.g., CPU scheduling deprioritization).
In some embodiments, implementing traffic control for network capacity controlled services using DAS techniques for network service usage activities that are unaware of network capacity control is provided by emulating network API messaging (e.g., effectively providing a spoofed or emulated network API). For example, an emulated network API can intercept, modify, block, remove, and/or replace network socket application interface messages and/or EtherType messages (e.g., EWOULDBLOCK, ENETDOWN, ENETUNREACH, EHOSTDOWN, EHOSTUNREACH, EALRADY, EINPROGRESS, ECONNREFUSED, EINPROGRESS, ETIMEDOUT, and/other such messages). As another example, an emulated network API can modify, swap, and/or inject network socket application interface messages (socket( ), connect( ), read( ), write( ), close( ), and other such messages) that provide for control or management of network service activity service usage behavior. As yet another example, before a connection is allowed to be opened (e.g., before a socket is opened), transmission, or a flow/stream is initiated, it is blocked and a message is sent back to the application (e.g., a reset message in response to a sync request or another message that the application will understand and can interpret to indicate that the network access attempt was not allowed/blocked, that the network is not available, and/or to try again later for the requested network access). As yet another example, the socket can be allowed to open but after some point in time (e.g., based on network service usage, network busy state, time based criteria, and/or some other criteria/measure), the stream is blocked or the socket is terminated. As yet another example, time window based traffic control techniques can be implemented (e.g., during non-peak, not network busy state times), such as by allowing network access for a period of time, blocking for a period of time, and then repeating to thereby effectively spread the network access out either randomly or deterministically. Using these techniques, an application that is unaware of network capacity control based traffic control can send and receive standard messaging, and the device can implement traffic controls based on the network capacity control policy using messaging that the network service usage activity (e.g., application or OS or software function) can understand and will respond to in a typically predictable manner as would now be apparent to one of ordinary skill in the art.
In some embodiments, implementing traffic control for network capacity controlled services using DAS techniques is provided using various techniques in which the network service usage activity is aware of network capacity control (e.g., the network service usage activity supports an API or other interface for implementing network capacity control). For example, a network access API as described herein can be used to implement traffic control for network capacity controlled services. In some embodiments, the API facilitates communication of one or more of the following: network access conditions, network busy state or network availability state of one or more networks or alternative networks, one or more network capacity controlled service policies (e.g., the network service can be of a current network access setting, such as allow/block, throttle, queue, scheduled time/time slot, and/or defer, which can be based on, for example, a current network, a current network busy state, a time based criteria, a service plan, a network service classification, and/or other criteria/measures), a network access request from a network service activity, a query/polled request to a network service activity, a network access grant to a network service activity (e.g., including a priority setting and/or network capacity controlled service classification, a scheduled time/time slot, an alternative network, and/or other criteria/measures), a network busy state or a network availability state or a network QoS state.
In some embodiments, implementing traffic control for network capacity controlled services using network assisted/based techniques is provided using various techniques in which the network service usage activity is unaware of network capacity control (e.g., does not support an API or other interface for implementing network capacity control). In some embodiments, DPI based techniques are used to control network capacity controlled services (e.g., to block or throttle network capacity controlled services at a DPI gateway).
In some embodiments, implementing traffic control for network capacity controlled services using network assisted/based techniques is provided using various techniques in which the network service usage activity is aware of network capacity control (e.g., does support an API or other interface for implementing network capacity control). In some embodiments, the application/messaging layer (e.g., a network API as described herein) is used to communicate with a network service activity to provide associated network capacity controlled service classifications and/or priorities, network busy state information or network availability of one or more networks or alternative networks, a network access request and response, and/other criteria/measures as similarly described herein.
In some embodiments, DAS for protecting network capacity includes implementing a service plan for differential charging based on network service usage activities (e.g., including network capacity controlled services). In some embodiments, the service plan includes differential charging for network capacity controlled services. In some embodiments, the service plan includes a cap network service usage for network capacity controlled services. In some embodiments, the service plan includes a notification when the cap is exceeded. In some embodiments, the service plan includes overage charges when the cap is exceeded. In some embodiments, the service plan includes modifying charging based on user input (e.g., user override selection as described herein, in which for example, overage charges are different for network capacity controlled services and/or based on priority levels and/or based on the current access network). In some embodiments, the service plan includes time based criteria restrictions for network capacity controlled services (e.g., time of day restrictions with or without override options). In some embodiments, the service plan includes network busy state based criteria restrictions for network capacity controlled services (e.g., with or without override options). In some embodiments, the service plan provides for network service activity controls to be overridden (e.g., one time, time window, usage amount, or permanent) (e.g., differentially charge for override, differentially cap for override, override with action based UI notification option, and/or override with UI setting). In some embodiments, the service plan includes family plan or multi-user plan (e.g., different network capacity controlled service settings for different users). In some embodiments, the service plan includes multi-device plan (e.g., different network capacity controlled service settings for different devices, such as smart phone v. laptop v. net book v. eBook). In some embodiments, the service plan includes free network capacity controlled service usage for certain times of day, network busy state(s), and/or other criteria/measures. In some embodiments, the service plan includes network dependent charging for network capacity controlled services. In some embodiments, the service plan includes network preference/prioritization for network capacity controlled services. In some embodiments, the service plan includes arbitration billing to bill a carrier partner or sponsored service partner for the access provided to a destination, application, or other network capacity controlled service. In some embodiments, the service plan includes arbitration billing to bill an application developer for the access provided to a destination, application or other network capacity controlled service.
In some application scenarios, excess network capacity demand can be caused by modem power state changes on the device. For example, when an application or OS function attempts to connect to the network for any reason when the modem is in a power save state wherein the modem is not connected to the network, it can cause the modem to change power save state, reconnect to the network, and then initiate the application network connection. In some cases, this can also cause the network to re-initiate a modem connection session (e.g., PPP session) which in addition to the network capacity consumed by the basic modem connection also consumes network resources for establishing the PPP session. Accordingly, in some embodiments, network service usage activity control policies are implemented that limit or control the ability of applications, OS functions, and/or other network service usage activities (e.g., network capacity controlled services) from changing the modem power control state or network connection state. In some embodiments, a service usage activity is prevented or limited from awakening the modem, changing the power state of the modem, or causing the modem to connect to the network until a given time window is reached. In some embodiments, the frequency a service usage activity is allowed to awakening the modem, changing the power state of the modem, or causing the modem is limited. In some embodiments, a network service usage activity is prevented from awakening the modem, changing the power state of the modem, or causing the modem until a time delay has passed. In some embodiments, a network service usage activity is prevented from awakening the modem, changing the power state of the modem, or causing the modem until multiple network service usage activities require such changes in modem state, or until network service usage activity is aggregated to increase network capacity and/or network resource utilization efficiency. In some embodiments, limiting the ability of a network service usage activity to change the power state of a modem includes not allowing the activity to power the modem off, place the modem in sleep mode, or disconnect the modem from the network. In some embodiments, these limitations on network service usage activity to awaken the modem, change the power state of the modem, or cause the modem to connect to a network are set by a central network function (e.g., a service controller or other network element/function) policy communication to the modem. In some embodiments, these power control state policies are updated by the central network function.
The computer 1802 interfaces to external systems through the communications interface 1810, which may include a modem or network interface. It will be appreciated that the communications interface 1810 can be considered to be part of the computer system 1800 or a part of the computer 1802. The communications interface 1810 can be an analog modem, ISDN modem, cable modem, token ring interface, satellite transmission interface (e.g. “direct PC”), or other interfaces for coupling a computer system to other computer systems.
The processor 1808 may be, for example, a conventional microprocessor such as an Intel Pentium microprocessor or Motorola power PC microprocessor. The memory 1812 is coupled to the processor 1808 by a bus 1170. The memory 1812 can be Dynamic Random Access Memory (DRAM) and can also include Static RAM (SRAM). The bus 1170 couples the processor 1808 to the memory 1812, also to the non-volatile storage 1816, to the display controller 1814, and to the I/O controller 1818.
The I/O devices 1804 can include a keyboard, disk drives, printers, a scanner, and other input and output devices, including a mouse or other pointing device. The display controller 1814 may control in the conventional manner a display on the display device 1806, which can be, for example, a cathode ray tube (CRT) or liquid crystal display (LCD). The display controller 1814 and the I/O controller 1818 can be implemented with conventional well known technology.
The non-volatile storage 1816 is often a magnetic hard disk, an optical disk, or another form of storage for large amounts of data. Some of this data is often written, by a direct memory access process, into memory 1812 during execution of software in the computer 1802. One of skill in the art will immediately recognize that the terms “machine-readable medium” or “computer-readable medium” includes any type of storage device that is accessible by the processor 1808 and also encompasses a carrier wave that encodes a data signal.
The computer system 1800 is one example of many possible computer systems which have different architectures. For example, personal computers based on an Intel microprocessor often have multiple buses, one of which can be an I/O bus for the peripherals and one that directly connects the processor 1808 and the memory 1812 (often referred to as a memory bus). The buses are connected together through bridge components that perform any necessary translation due to differing bus protocols.
Network computers are another type of computer system that can be used in conjunction with the teachings provided herein. Network computers do not usually include a hard disk or other mass storage, and the executable programs are loaded from a network connection into the memory 1812 for execution by the processor 1808. A Web TV system, which is known in the art, is also considered to be a computer system, but it may lack some of the features shown in
In addition, the computer system 1800 is controlled by operating system software which includes a file management system, such as a disk operating system, which is part of the operating system software. One example of operating system software with its associated file management system software is the family of operating systems known as Windows® from Microsoft Corporation of Redmond, Washington, and their associated file management systems. Another example of operating system software with its associated file management system software is the Linux operating system and its associated file management system. The file management system is typically stored in the non-volatile storage 1816 and causes the processor 1808 to execute the various acts required by the operating system to input and output data and to store data in memory, including storing files on the non-volatile storage 1816.
Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The present disclosure, in some embodiments, also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present disclosure is not described with reference to any particular programming language, and various embodiments may thus be implemented using a variety of programming languages.
Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the disclosure is not limited to the details provided. There are many alternative ways of implementing the disclosure. The disclosed embodiments are illustrative and not restrictive.
Various aspects and features of embodiments disclosed herein are set forth, for example and without limitation, in the following numbered clauses:
A. Classification and at Least One Network Policy Modifier
B. Two Policy Modifiers
C. Implementation with Two Network State Categories
A. Event Associated with 2 of 3 Policies
B. Event and Device State Provides Notification
C. Implementation of Event and Device State Induced Notification
Various aspects and features of embodiments disclosed herein are set forth, for example and without limitation, are also set forth in the following outline:
The section headings provided in this detailed description are for convenience of reference only, and in no way define, limit, construe or describe the scope or extent of such sections. Also, while various specific embodiments have been disclosed, it will be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure. For example, features or aspects of any of the embodiments may be applied in combination with any other of the embodiments or in place of counterpart features or aspects thereof. The terms “exemplary” and “embodiment” are used to express an example, not a preference or requirement. Also, the terms “may” and “can” are used interchangeably to denote optional (permissible) subject matter. The absence of either term should not be construed as meaning that a given feature or technique is required. Further, in the foregoing description and in the accompanying drawings, specific terminology and drawing symbols have been set forth to provide a thorough understanding of the disclosed embodiments. In some instances, the terminology and symbols may imply implementation or operational details that are not required to practice those embodiments. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
This document incorporates by reference for all purposes the following non-provisional U.S. patent applications: application Ser. No. 12/380,778, filed Mar. 2, 2009, entitled VERIFIABLE DEVICE ASSISTED SERVICE USAGE BILLING WITH INTEGRATED ACCOUNTING, MEDIATION ACCOUNTING, AND MULTI-ACCOUNT, now U.S. Pat. No. 8,321,526 (issued Nov. 27, 2012); application Ser. No. 12/380,780, filed Mar. 2, 2009, entitled AUTOMATED DEVICE PROVISIONING AND ACTIVATION, now U.S. Pat. No. 8,839,388 (issued Sep. 16, 2014); application Ser. No. 12/695,019, filed Jan. 27, 2010, entitled DEVICE ASSISTED CDR CREATION, AGGREGATION, MEDIATION AND BILLING, now U.S. Pat. No. 8,275,830 (issued Sep. 25, 2012); application Ser. No. 12/695,020, filed Jan. 27, 2010, entitled ADAPTIVE AMBIENT SERVICES, now U.S. Pat. No. 8,406,748 (issued Mar. 26, 2013); application Ser. No. 12/694,445, filed Jan. 27, 2010, entitled SECURITY TECHNIQUES FOR DEVICE ASSISTED SERVICES, now U.S. Pat. No. 8,391,834 (issued Mar. 5, 2013); application Ser. No. 12/694,451, filed Jan. 27, 2010, entitled DEVICE GROUP PARTITIONS AND SETTLEMENT PLATFORM, now U.S. Pat. No. 8,548,428 (issued Oct. 1, 2013); application Ser. No. 12/694,455, filed Jan. 27, 2010, entitled DEVICE ASSISTED SERVICES INSTALL, now U.S. Pat. No. 8,402,111, now U.S. Pat. No. 8,402,111 (issued Mar. 19, 2013); application Ser. No. 12/695,021, filed Jan. 27, 2010, entitled QUALITY OF SERVICE FOR DEVICE ASSISTED SERVICES, now U.S. Pat. No. 8,346,225 (issued Jan. 1, 2013); application Ser. No. 12/695,980, filed Jan. 28, 2010, entitled ENHANCED ROAMING SERVICES AND CONVERGED CARRIER NETWORKS WITH DEVICE ASSISTED SERVICES AND A PROXY, now U.S. Pat. No. 8,340,634 (issued Dec. 25, 2012); application Ser. No. 13/134,005, filed May 25, 2011, entitled SYSTEM AND METHOD FOR WIRELESS NETWORK OFFLOADING, now U.S. Pat. No. 8,635,335 (issued Jan. 21, 2014); application Ser. No. 13/134,028, filed May 25, 2011, entitled DEVICE-ASSISTED SERVICES FOR PROTECTING NETWORK CAPACITY, now U.S. Pat. No. 8,589,541 (issued Nov. 19, 2013); application Ser. No. 13/229,580, filed Sep. 9, 2011, entitled WIRELESS NETWORK SERVICE INTERFACES, now U.S. Pat. No. 8,626,115 (issued Jan. 7, 2014); application Ser. No. 13/237,827, filed Sep. 20, 2011, entitled ADAPTING NETWORK POLICIES BASED ON DEVICE SERVICE PROCESSOR CONFIGURATION, now U.S. Pat. No. 8,832,777 (issued Sep. 9, 2014); application Ser. No. 13/239,321, filed Sep. 21, 2011, entitled SERVICE OFFER SET PUBLISHING TO DEVICE AGENT WITH ON-DEVICE SERVICE SELECTION, now U.S. Pat. No. 8,898,293; application Ser. No. 13/248,028, filed Sep. 28, 2011, entitled ENTERPRISE ACCESS CONTROL AND ACCOUNTING ALLOCATION FOR ACCESS NETWORKS, now U.S. Pat. No. 8,924,469; application Ser. No. 13/247,998, filed Sep. 28, 2011, entitled COMMUNICATIONS DEVICE WITH SECURE DATA PATH PROCESSING AGENTS, now U.S. Pat. No. 8,725,123 (issued May 13, 2014); application Ser. No. 13/248,025, filed Sep. 28, 2011, entitled SERVICE DESIGN CENTER FOR DEVICE ASSISTED SERVICES, now U.S. Pat. No. 8,924,543; application Ser. No. 13/253,013, filed Oct. 4, 2011, entitled SYSTEM AND METHOD FOR PROVIDING USER NOTIFICATIONS, now U.S. Pat. No. 8,745,191 (issued Jun. 3, 2014); application Ser. No. 13/309,556, filed Dec. 1, 2011, entitled END USER DEVICE THAT SECURES AN ASSOCIATION OF APPLICATION TO SERVICE POLICY WITH AN APPLICATION CERTIFICATE CHECK, now U.S. Pat. No. 8,893,009; application Ser. No. 13/309,463, filed Dec. 1, 2011, entitled SECURITY, FRAUD DETECTION, AND FRAUD MITIGATION IN DEVICE-ASSISTED SERVICES SYSTEMS, now U.S. Pat. No. 8,793,758 (issued Jul. 29, 2014); application Ser. No. 13/374,959, filed Jan. 24, 2012, entitled FLOW TAGGING FOR SERVICE POLICY IMPLEMENTATION, now U.S. Pat. No. 8,606,911 (issued Dec. 10, 2013); application Ser. No. 13/441,821, filed Apr. 6, 2012, entitled MANAGING SERVICE USER DISCOVERY AND SERVICE LAUNCH OBJECT PLACEMENT ON A DEVICE; application Ser. No. 13/748,152, filed Jan. 23, 2013, entitled SERVICE PLAN DESIGN, USER INTERFACES, APPLICATION PROGRAMMING INTERFACES, AND DEVICE MANAGEMENT; and application Ser. No. 13/802,483, filed Mar. 13, 2013, entitled MOBILE DEVICE ACTIVATION VIA DYNAMICALLY SELECTED ACCESS NETWORK;
This document incorporates by reference for all purposes the following provisional patent applications: Provisional Application No. 61/206,354, filed Jan. 28, 2009, entitled SERVICES POLICY COMMUNICATION SYSTEM AND METHOD; Provisional Application No. 61/206,944, filed Feb. 4, 2009, entitled SERVICES POLICY COMMUNICATION SYSTEM AND METHOD; Provisional Application No. 61/207,393, filed Feb. 10, 2009, entitled SERVICES POLICY COMMUNICATION SYSTEM AND METHOD; and Provisional Application No. 61/207,739, entitled SERVICES POLICY COMMUNICATION SYSTEM AND METHOD, filed Feb. 13, 2009; Provisional Application No. 61/270,353, filed on Jul. 6, 2009, entitled DEVICE ASSISTED CDR CREATION, AGGREGATION, MEDIATION AND BILLING; Provisional Application No. 61/275,208, filed Aug. 25, 2009, entitled ADAPTIVE AMBIENT SERVICES; and Provisional Application No. 61/237,753, filed Aug. 28, 2009, entitled ADAPTIVE AMBIENT SERVICES; Provisional Application No. 61/252,151, filed Oct. 15, 2009, entitled SECURITY TECHNIQUES FOR DEVICE ASSISTED SERVICES; Provisional Application No. 61/252,153, filed Oct. 15, 2009, entitled DEVICE GROUP PARTITIONS AND SETTLEMENT PLATFORM; Provisional Application No. 61/264,120, filed Nov. 24, 2009, entitled DEVICE ASSISTED SERVICES INSTALL; Provisional Application No. 61/264,126, filed Nov. 24, 2009, entitled DEVICE ASSISTED SERVICES ACTIVITY MAP; Provisional Application No. 61/348,022, filed May 25, 2010, entitled DEVICE ASSISTED SERVICES FOR PROTECTING NETWORK CAPACITY; Provisional Application No. 61/381,159, filed Sep. 9, 2010, entitled DEVICE ASSISTED SERVICES FOR PROTECTING NETWORK CAPACITY; Provisional Application No. 61/381,162, filed Sep. 9, 2010, entitled SERVICE CONTROLLER INTERFACES AND WORKFLOWS; Provisional Application No. 61/384,456, filed Sep. 20, 2010, entitled SECURING SERVICE PROCESSOR WITH SPONSORED SIMS; Provisional Application No. 61/389,547, filed Oct. 4, 2010, entitled USER NOTIFICATIONS FOR DEVICE ASSISTED SERVICES; Provisional Application No. 61/385,020, filed Sep. 21, 2010, entitled SERVICE USAGE RECONCILIATION SYSTEM OVERVIEW; Provisional Application No. 61/387,243, filed Sep. 28, 2010, entitled ENTERPRISE AND CONSUMER BILLING ALLOCATION FOR WIRELESS COMMUNICATION DEVICE SERVICE USAGE ACTIVITIES; Provisional Application No. 61/387,247, filed September 28, entitled SECURED DEVICE DATA RECORDS, 2010; Provisional Application No. 61/407,358, filed Oct. 27, 2010, entitled SERVICE CONTROLLER AND SERVICE PROCESSOR ARCHITECTURE; Provisional Application No. 61/418,507, filed Dec. 1, 2010, entitled APPLICATION SERVICE PROVIDER INTERFACE SYSTEM; Provisional Application No. 61/418,509, filed Dec. 1, 2010, entitled SERVICE USAGE REPORTING RECONCILIATION AND FRAUD DETECTION FOR DEVICE ASSISTED SERVICES; Provisional Application No. 61/420,727, filed Dec. 7, 2010, entitled SECURE DEVICE DATA RECORDS; Provisional Application No. 61/422,565, filed Dec. 13, 2010, entitled SERVICE DESIGN CENTER FOR DEVICE ASSISTED SERVICES; Provisional Application No. 61/422,572, filed Dec. 13, 2010, entitled SYSTEM INTERFACES AND WORKFLOWS FOR DEVICE ASSISTED SERVICES; Provisional Application No. 61/422,574, filed Dec. 13, 2010, entitled SECURITY AND FRAUD DETECTION FOR DEVICE ASSISTED SERVICES; Provisional Application No. 61/435,564, filed Jan. 24, 2011, entitled FRAMEWORK FOR DEVICE ASSISTED SERVICES; Provisional Application No. 61/472,606, filed Apr. 6, 2011, entitled MANAGING SERVICE USER DISCOVERY AND SERVICE LAUNCH OBJECT PLACEMENT ON A DEVICE; Provisional Application No. 61/550,906, filed Oct. 24, 2011, entitled SECURITY FOR DEVICE-ASSISTED SERVICES; Provisional Application No. 61/589,830, filed Jan. 23, 2012, entitled METHODS AND APPARATUS TO PRESENT INFORMATION ABOUT VOICE, MESSAGING, AND DATA SERVICES ON WIRELESS MOBILE DEVICES; Provisional Application No. 61/610,876, filed Mar. 14, 2012, entitled METHODS AND APPARATUS FOR APPLICATION PROMOTION AND SPONSORSHIP; Provisional Application No. 61/610,910, filed Mar. 14, 2012, entitled WIFI ACTIVATION BACKUP PROCESS; Provisional Application No. 61/658,339, filed Jun. 11, 2012, entitled MULTI-DEVICE MASTER SERVICES ACCOUNTS, SERVICE PLAN SHARING AND ASSIGNMENTS, AND DEVICE MANAGEMENT FROM A MASTER DEVICE; Provisional Application No. 61/667,927, filed Jul. 3, 2012, entitled FLEXIBLE MULTI-DEVICE MASTER SERVICE ACCOUNTS, SERVICE PLAN SHARING AND ASSIGNMENTS, AND DEVICE MANAGEMENT; Provisional Application No. 61/674,331, filed Jul. 21, 2012, entitled SERVICE CONTROLLER FOR MANAGING CLOUD-BASED POLICY; Provisional Application No. 61/724,267, filed Nov. 8, 2012, entitled FLEXIBLE SERVICE PLAN DESIGN, USER INTERFACE AND DEVICE MANAGEMENT; Provisional Application No. 61/724,837, filed Nov. 9, 2012, entitled SERVICE PLAN DISCOVERY, CUSTOMIZATION, AND MANAGEMENT; Provisional Application No. 61/724,974, filed Nov. 10, 2012, entitled SERVICE PLAN DISCOVERY, CUSTOMIZATION, AND MANAGEMENT; Provisional Application No. 61/732,249, filed Nov. 30, 2012, entitled APPLICATION PROGRAMMING INTERFACES FOR SMART SERVICES; Provisional Application No. 61/734,288, filed Dec. 6, 2012, entitled INTERMEDIATE NETWORKING DEVICE SERVICES; and Provisional Application No. 61/745,548, filed Dec. 22, 2012, entitled SERVICE PLAN DESIGN, USER INTERFACES, APPLICATION PROGRAMMING INTERFACES, AND DEVICE MANAGEMENT; Provisional Application No. 61/756,332, filed Jan. 24, 2013, entitled MOBILE HOTSPOT; Provisional Application No. 61/758,964, filed Jan. 30, 2013, entitled MOBILE HOTSPOT; Provisional Application No. 61/765,978, filed Feb. 18, 2013, entitled ENHANCED CURFEW AND PROTECTION ASSOCIATED WITH A DEVICE GROUP; Provisional Application No. 61/785,988, filed Mar. 14, 2013, entitled AUTOMATED CREDENTIAL PORTING FOR MOBILE DEVICES; Provisional Application No. 61/794,116, filed Mar. 15, 2013, entitled ENHANCED INTERMEDIATE NETWORKING DEVICE; Provisional Application No. 61/792,765, filed Mar. 15, 2013, entitled DEVICE GROUP AND SERVICE PLAN MANAGEMENT; and Provisional Application No. 61/793,894, filed Mar. 15, 2013, entitled SIMPLIFIED POLICY DESIGN, MANAGEMENT, AND IMPLEMENTATION.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5131020 | Liebesny et al. | Jul 1992 | A |
| 5283904 | Carson et al. | Feb 1994 | A |
| 5325532 | Crosswy et al. | Jun 1994 | A |
| 5572528 | Shuen | Nov 1996 | A |
| 5577100 | McGregor et al. | Nov 1996 | A |
| 5594777 | Makkonen et al. | Jan 1997 | A |
| 5617539 | Ludwig et al. | Apr 1997 | A |
| 5630159 | Zancho | May 1997 | A |
| 5633484 | Zancho et al. | May 1997 | A |
| 5633868 | Baldwin et al. | May 1997 | A |
| 5754953 | Briancon et al. | May 1998 | A |
| 5774532 | Gottlieb et al. | Jun 1998 | A |
| 5794142 | Vanttila et al. | Aug 1998 | A |
| 5814798 | Zancho | Sep 1998 | A |
| 5889477 | Fastenrath | Mar 1999 | A |
| 5892900 | Ginter et al. | Apr 1999 | A |
| 5903845 | Buhrmann et al. | May 1999 | A |
| 5915008 | Dulman | Jun 1999 | A |
| 5915226 | Martineau | Jun 1999 | A |
| 5933778 | Buhrmann et al. | Aug 1999 | A |
| 5940472 | Newman et al. | Aug 1999 | A |
| 5974439 | Bollella | Oct 1999 | A |
| 5983270 | Abraham et al. | Nov 1999 | A |
| 6035281 | Crosskey et al. | Mar 2000 | A |
| 6038452 | Strawczynski et al. | Mar 2000 | A |
| 6038540 | Krist et al. | Mar 2000 | A |
| 6047268 | Bartoli et al. | Apr 2000 | A |
| 6058434 | Wilt et al. | May 2000 | A |
| 6061571 | Tamura | May 2000 | A |
| 6064878 | Denker et al. | May 2000 | A |
| 6078953 | Vaid et al. | Jun 2000 | A |
| 6081591 | Skoog | Jun 2000 | A |
| 6098878 | Dent et al. | Aug 2000 | A |
| 6104700 | Haddock et al. | Aug 2000 | A |
| 6115823 | Velasco et al. | Sep 2000 | A |
| 6119933 | Wong et al. | Sep 2000 | A |
| 6125391 | Meltzer et al. | Sep 2000 | A |
| 6141565 | Feuerstein et al. | Oct 2000 | A |
| 6141686 | Jackowski et al. | Oct 2000 | A |
| 6148336 | Thomas et al. | Nov 2000 | A |
| 6154738 | Call | Nov 2000 | A |
| 6157636 | Voit et al. | Dec 2000 | A |
| 6185576 | Mcintosh | Feb 2001 | B1 |
| 6198915 | McGregor et al. | Mar 2001 | B1 |
| 6219786 | Cunningham et al. | Apr 2001 | B1 |
| 6226277 | Chuah | May 2001 | B1 |
| 6246870 | Dent et al. | Jun 2001 | B1 |
| 6263055 | Garland et al. | Jul 2001 | B1 |
| 6292828 | Williams | Sep 2001 | B1 |
| 6317584 | Abu-Amara et al. | Nov 2001 | B1 |
| 6370139 | Redmond | Apr 2002 | B2 |
| 6381316 | Joyce et al. | Apr 2002 | B2 |
| 6393014 | Daly et al. | May 2002 | B1 |
| 6397259 | Lincke et al. | May 2002 | B1 |
| 6401113 | Lazaridis et al. | Jun 2002 | B2 |
| 6418147 | Wiedeman | Jul 2002 | B1 |
| 6438575 | Khan et al. | Aug 2002 | B1 |
| 6445777 | Clark | Sep 2002 | B1 |
| 6449479 | Sanchez | Sep 2002 | B1 |
| 6466984 | Naveh et al. | Oct 2002 | B1 |
| 6477670 | Ahmadvand | Nov 2002 | B1 |
| 6502131 | Vaid et al. | Dec 2002 | B1 |
| 6505114 | Luciani | Jan 2003 | B2 |
| 6510152 | Gerszberg et al. | Jan 2003 | B1 |
| 6522629 | Anderson, Sr. | Feb 2003 | B1 |
| 6532235 | Benson et al. | Mar 2003 | B1 |
| 6532579 | Sato et al. | Mar 2003 | B2 |
| 6535855 | Cahill et al. | Mar 2003 | B1 |
| 6535949 | Parker | Mar 2003 | B1 |
| 6539082 | Lowe et al. | Mar 2003 | B1 |
| 6542500 | Gerszberg et al. | Apr 2003 | B1 |
| 6542992 | Peirce et al. | Apr 2003 | B1 |
| 6546016 | Gerszberg et al. | Apr 2003 | B1 |
| 6563806 | Yano et al. | May 2003 | B1 |
| 6570974 | Gerszberg et al. | May 2003 | B1 |
| 6574321 | Cox et al. | Jun 2003 | B1 |
| 6574465 | Marsh et al. | Jun 2003 | B2 |
| 6578076 | Putzolu | Jun 2003 | B1 |
| 6581092 | Motoyama | Jun 2003 | B1 |
| 6591098 | Shieh et al. | Jul 2003 | B1 |
| 6598034 | Kloth | Jul 2003 | B1 |
| 6601040 | Kolls | Jul 2003 | B1 |
| 6603969 | Vuoristo et al. | Aug 2003 | B1 |
| 6603975 | Inouchi et al. | Aug 2003 | B1 |
| 6606744 | Mikurak | Aug 2003 | B1 |
| 6628934 | Rosenberg et al. | Sep 2003 | B2 |
| 6631122 | Arunachalam et al. | Oct 2003 | B1 |
| 6636721 | Threadgill et al. | Oct 2003 | B2 |
| 6639975 | O'Neal et al. | Oct 2003 | B1 |
| 6640097 | Corrigan et al. | Oct 2003 | B2 |
| 6640334 | Rasmussen | Oct 2003 | B1 |
| 6650887 | McGregor et al. | Nov 2003 | B2 |
| 6651101 | Gai et al. | Nov 2003 | B1 |
| 6654786 | Fox et al. | Nov 2003 | B1 |
| 6654814 | Britton et al. | Nov 2003 | B1 |
| 6658254 | Purdy et al. | Dec 2003 | B1 |
| 6662014 | Walsh | Dec 2003 | B1 |
| 6678516 | Nordman et al. | Jan 2004 | B2 |
| 6683853 | Kannas et al. | Jan 2004 | B1 |
| 6684244 | Goldman et al. | Jan 2004 | B1 |
| 6690918 | Evans et al. | Feb 2004 | B2 |
| 6697821 | Ziff et al. | Feb 2004 | B2 |
| 6725031 | Watler et al. | Apr 2004 | B2 |
| 6725256 | Albal et al. | Apr 2004 | B1 |
| 6732176 | Stewart et al. | May 2004 | B1 |
| 6735206 | Oki et al. | May 2004 | B1 |
| 6748195 | Phillips | Jun 2004 | B1 |
| 6748437 | Mankude et al. | Jun 2004 | B1 |
| 6751296 | Albal et al. | Jun 2004 | B1 |
| 6754470 | Hendrickson et al. | Jun 2004 | B2 |
| 6757717 | Goldstein | Jun 2004 | B1 |
| 6760417 | Wallenius | Jul 2004 | B1 |
| 6763000 | Walsh | Jul 2004 | B1 |
| 6763226 | McZeal, Jr. | Jul 2004 | B1 |
| 6765864 | Natarajan et al. | Jul 2004 | B1 |
| 6765925 | Sawyer et al. | Jul 2004 | B1 |
| 6782412 | Brophy et al. | Aug 2004 | B2 |
| 6785889 | Williams | Aug 2004 | B1 |
| 6792461 | Hericourt | Sep 2004 | B1 |
| 6829596 | Frazee | Dec 2004 | B1 |
| 6829696 | Balmer et al. | Dec 2004 | B1 |
| 6839340 | Voit et al. | Jan 2005 | B1 |
| 6842628 | Arnold et al. | Jan 2005 | B1 |
| 6873988 | Herrmann et al. | Mar 2005 | B2 |
| 6876653 | Ambe et al. | Apr 2005 | B2 |
| 6879825 | Daly | Apr 2005 | B1 |
| 6882718 | Smith | Apr 2005 | B1 |
| 6885997 | Roberts | Apr 2005 | B1 |
| 6901440 | Bimm et al. | May 2005 | B1 |
| 6920455 | Weschler | Jul 2005 | B1 |
| 6922562 | Ward et al. | Jul 2005 | B2 |
| 6928280 | Xanthos et al. | Aug 2005 | B1 |
| 6934249 | Bertin et al. | Aug 2005 | B1 |
| 6934751 | Jayapalan et al. | Aug 2005 | B2 |
| 6947723 | Gurnani et al. | Sep 2005 | B1 |
| 6947985 | Hegli et al. | Sep 2005 | B2 |
| 6952428 | Necka et al. | Oct 2005 | B1 |
| 6957067 | Iyer et al. | Oct 2005 | B1 |
| 6959202 | Heinonen et al. | Oct 2005 | B2 |
| 6959393 | Hollis et al. | Oct 2005 | B2 |
| 6965667 | Trabandt et al. | Nov 2005 | B2 |
| 6965872 | Grdina | Nov 2005 | B1 |
| 6967958 | Ono et al. | Nov 2005 | B2 |
| 6970692 | Tysor | Nov 2005 | B2 |
| 6970927 | Stewart et al. | Nov 2005 | B1 |
| 6982733 | McNally et al. | Jan 2006 | B1 |
| 6983370 | Eaton et al. | Jan 2006 | B2 |
| 6996062 | Freed et al. | Feb 2006 | B1 |
| 6996076 | Forbes et al. | Feb 2006 | B1 |
| 6996393 | Pyhalammi et al. | Feb 2006 | B2 |
| 6998985 | Reisman et al. | Feb 2006 | B2 |
| 7002920 | Ayyagari et al. | Feb 2006 | B1 |
| 7007295 | Rose et al. | Feb 2006 | B1 |
| 7013469 | Smith et al. | Mar 2006 | B2 |
| 7017189 | DeMello et al. | Mar 2006 | B1 |
| 7020781 | Saw et al. | Mar 2006 | B1 |
| 7024200 | McKenna et al. | Apr 2006 | B2 |
| 7024460 | Koopmas et al. | Apr 2006 | B2 |
| 7027055 | Anderson et al. | Apr 2006 | B2 |
| 7027408 | Nabkel et al. | Apr 2006 | B2 |
| 7031733 | Alminana et al. | Apr 2006 | B2 |
| 7032072 | Quinn et al. | Apr 2006 | B1 |
| 7039027 | Bridgelall | May 2006 | B2 |
| 7039037 | Wang et al. | May 2006 | B2 |
| 7039403 | Wong | May 2006 | B2 |
| 7039713 | Van Gunter et al. | May 2006 | B1 |
| 7042988 | Juitt et al. | May 2006 | B2 |
| 7043225 | Patel et al. | May 2006 | B1 |
| 7043226 | Yamauchi | May 2006 | B2 |
| 7043268 | Yukie et al. | May 2006 | B2 |
| 7047276 | Liu et al. | May 2006 | B2 |
| 7058022 | Carolan et al. | Jun 2006 | B1 |
| 7058968 | Rowland et al. | Jun 2006 | B2 |
| 7068600 | Cain | Jun 2006 | B2 |
| 7069248 | Huber | Jun 2006 | B2 |
| 7082422 | Zirngibl et al. | Jul 2006 | B1 |
| 7084775 | Smith | Aug 2006 | B1 |
| 7092696 | Hosain et al. | Aug 2006 | B1 |
| 7095754 | Benveniste | Aug 2006 | B2 |
| 7102620 | Harries et al. | Sep 2006 | B2 |
| 7110753 | Campen | Sep 2006 | B2 |
| 7113780 | Mckenna et al. | Sep 2006 | B2 |
| 7113997 | Jayapalan et al. | Sep 2006 | B2 |
| 7120133 | Joo et al. | Oct 2006 | B1 |
| 7133386 | Holur et al. | Nov 2006 | B2 |
| 7133695 | Beyda | Nov 2006 | B2 |
| 7136361 | Benveniste | Nov 2006 | B2 |
| 7139569 | Kato | Nov 2006 | B2 |
| 7142876 | Trossen et al. | Nov 2006 | B2 |
| 7149229 | Leung | Dec 2006 | B1 |
| 7149521 | Sundar et al. | Dec 2006 | B2 |
| 7151764 | Heinonen et al. | Dec 2006 | B1 |
| 7158792 | Cook et al. | Jan 2007 | B1 |
| 7162237 | Silver et al. | Jan 2007 | B1 |
| 7165040 | Ehrman et al. | Jan 2007 | B2 |
| 7167078 | Pourchot | Jan 2007 | B2 |
| 7174156 | Mangal | Feb 2007 | B1 |
| 7174174 | Boris et al. | Feb 2007 | B2 |
| 7177919 | Truong et al. | Feb 2007 | B1 |
| 7180855 | Lin | Feb 2007 | B1 |
| 7181017 | Nagel et al. | Feb 2007 | B1 |
| 7191248 | Chattopadhyay et al. | Mar 2007 | B2 |
| 7197321 | Erskine et al. | Mar 2007 | B2 |
| 7200112 | Sundar et al. | Apr 2007 | B2 |
| 7200551 | Senez | Apr 2007 | B1 |
| 7203169 | Okholm et al. | Apr 2007 | B1 |
| 7203721 | Ben-Efraim et al. | Apr 2007 | B1 |
| 7203752 | Rice et al. | Apr 2007 | B2 |
| 7212491 | Koga | May 2007 | B2 |
| 7219123 | Fiechter et al. | May 2007 | B1 |
| 7222190 | Klinker et al. | May 2007 | B2 |
| 7222304 | Beaton et al. | May 2007 | B2 |
| 7224968 | Dobson et al. | May 2007 | B2 |
| 7228354 | Chambliss et al. | Jun 2007 | B2 |
| 7236780 | Benco | Jun 2007 | B2 |
| 7242668 | Kan et al. | Jul 2007 | B2 |
| 7242920 | Morris | Jul 2007 | B2 |
| 7245901 | McGregor et al. | Jul 2007 | B2 |
| 7248570 | Bahl et al. | Jul 2007 | B2 |
| 7251218 | Jorgensen | Jul 2007 | B2 |
| 7260382 | Lamb et al. | Aug 2007 | B1 |
| 7266371 | Amin et al. | Sep 2007 | B1 |
| 7269157 | Klinker et al. | Sep 2007 | B2 |
| 7271765 | Stilp et al. | Sep 2007 | B2 |
| 7272660 | Powers et al. | Sep 2007 | B1 |
| 7280816 | Fratti et al. | Oct 2007 | B2 |
| 7280818 | Clayton | Oct 2007 | B2 |
| 7283561 | Picher-Dempsey | Oct 2007 | B1 |
| 7283963 | Fitzpatrick et al. | Oct 2007 | B1 |
| 7286834 | Walter | Oct 2007 | B2 |
| 7286848 | Vireday et al. | Oct 2007 | B2 |
| 7289489 | Kung et al. | Oct 2007 | B1 |
| 7290283 | Copeland, III | Oct 2007 | B2 |
| 7310424 | Gehring et al. | Dec 2007 | B2 |
| 7313237 | Bahl et al. | Dec 2007 | B2 |
| 7315892 | Freimuth et al. | Jan 2008 | B2 |
| 7317699 | Godfrey et al. | Jan 2008 | B2 |
| 7318111 | Zhao | Jan 2008 | B2 |
| 7320029 | Rinne et al. | Jan 2008 | B2 |
| 7320781 | Lambert et al. | Jan 2008 | B2 |
| 7322044 | Hrastar | Jan 2008 | B2 |
| 7324447 | Morford | Jan 2008 | B1 |
| 7325037 | Lawson | Jan 2008 | B2 |
| 7336960 | Zavalkovsky et al. | Feb 2008 | B2 |
| 7340772 | Panasyuk et al. | Mar 2008 | B2 |
| 7346410 | Uchiyama | Mar 2008 | B2 |
| 7349695 | Oommen et al. | Mar 2008 | B2 |
| 7349698 | Gallagher et al. | Mar 2008 | B2 |
| 7353533 | Wright et al. | Apr 2008 | B2 |
| 7356011 | Waters et al. | Apr 2008 | B1 |
| 7356337 | Florence | Apr 2008 | B2 |
| 7366497 | Nagata | Apr 2008 | B2 |
| 7366654 | Moore | Apr 2008 | B2 |
| 7369848 | Jiang | May 2008 | B2 |
| 7369856 | Ovadia | May 2008 | B2 |
| 7373136 | Watler et al. | May 2008 | B2 |
| 7373179 | Stine et al. | May 2008 | B2 |
| 7379731 | Natsuno et al. | May 2008 | B2 |
| 7388950 | Elsey et al. | Jun 2008 | B2 |
| 7389412 | Sharma et al. | Jun 2008 | B2 |
| 7391724 | Alakoski et al. | Jun 2008 | B2 |
| 7395244 | Kingsford | Jul 2008 | B1 |
| 7401338 | Bowen et al. | Jul 2008 | B1 |
| 7403763 | Maes | Jul 2008 | B2 |
| 7409447 | Assadzadeh | Aug 2008 | B1 |
| 7409569 | Illowsky et al. | Aug 2008 | B2 |
| 7411930 | Montojo et al. | Aug 2008 | B2 |
| 7418253 | Kavanah | Aug 2008 | B2 |
| 7418257 | Kim | Aug 2008 | B2 |
| 7421004 | Feher | Sep 2008 | B2 |
| 7423971 | Mohaban et al. | Sep 2008 | B1 |
| 7428750 | Dunn et al. | Sep 2008 | B1 |
| 7433362 | Mallya et al. | Oct 2008 | B2 |
| 7436816 | Mehta et al. | Oct 2008 | B2 |
| 7440433 | Rink et al. | Oct 2008 | B2 |
| 7444669 | Bahl et al. | Oct 2008 | B1 |
| 7450591 | Korling et al. | Nov 2008 | B2 |
| 7450927 | Creswell et al. | Nov 2008 | B1 |
| 7454191 | Dawson et al. | Nov 2008 | B2 |
| 7457265 | Julka et al. | Nov 2008 | B2 |
| 7457870 | Lownsbrough et al. | Nov 2008 | B1 |
| 7460837 | Diener | Dec 2008 | B2 |
| 7466652 | Lau et al. | Dec 2008 | B2 |
| 7467160 | McIntyre | Dec 2008 | B2 |
| 7472189 | Mallya et al. | Dec 2008 | B2 |
| 7478420 | Wright et al. | Jan 2009 | B2 |
| 7486185 | Culpepper et al. | Feb 2009 | B2 |
| 7486658 | Kumar | Feb 2009 | B2 |
| 7493659 | Wu et al. | Feb 2009 | B1 |
| 7496652 | Pezzutti | Feb 2009 | B2 |
| 7499438 | Hinman et al. | Mar 2009 | B2 |
| 7499537 | Elsey et al. | Mar 2009 | B2 |
| 7502672 | Kolls | Mar 2009 | B1 |
| 7505756 | Bahl | Mar 2009 | B2 |
| 7505795 | Lim et al. | Mar 2009 | B1 |
| 7508794 | Feather et al. | Mar 2009 | B2 |
| 7508799 | Sumner et al. | Mar 2009 | B2 |
| 7512128 | DiMambro et al. | Mar 2009 | B2 |
| 7512131 | Svensson et al. | Mar 2009 | B2 |
| 7515608 | Yuan et al. | Apr 2009 | B2 |
| 7515926 | Bu et al. | Apr 2009 | B2 |
| 7516219 | Moghaddam et al. | Apr 2009 | B2 |
| 7522549 | Karaoguz et al. | Apr 2009 | B2 |
| 7522576 | Du et al. | Apr 2009 | B2 |
| 7526541 | Roese et al. | Apr 2009 | B2 |
| 7529204 | Bourlas et al. | May 2009 | B2 |
| 7535880 | Hinman et al. | May 2009 | B1 |
| 7536695 | Alam et al. | May 2009 | B2 |
| 7539132 | Werner et al. | May 2009 | B2 |
| 7539862 | Edgett et al. | May 2009 | B2 |
| 7540408 | Levine et al. | Jun 2009 | B2 |
| 7545782 | Rayment et al. | Jun 2009 | B2 |
| 7546460 | Maes | Jun 2009 | B2 |
| 7546629 | Albert et al. | Jun 2009 | B2 |
| 7548875 | Mikkelsen et al. | Jun 2009 | B2 |
| 7548976 | Bahl et al. | Jun 2009 | B2 |
| 7551921 | Petermann | Jun 2009 | B2 |
| 7551922 | Roskowski et al. | Jun 2009 | B2 |
| 7554983 | Muppala | Jun 2009 | B1 |
| 7555757 | Smith et al. | Jun 2009 | B2 |
| 7561899 | Lee | Jul 2009 | B2 |
| 7562213 | Timms | Jul 2009 | B1 |
| 7564799 | Holland et al. | Jul 2009 | B2 |
| 7565141 | Macaluso | Jul 2009 | B2 |
| 7574509 | Nixon et al. | Aug 2009 | B2 |
| 7574731 | Fascenda | Aug 2009 | B2 |
| 7577431 | Jiang | Aug 2009 | B2 |
| 7580356 | Mishra et al. | Aug 2009 | B1 |
| 7580857 | VanFleet et al. | Aug 2009 | B2 |
| 7583964 | Wong | Sep 2009 | B2 |
| 7584298 | Klinker et al. | Sep 2009 | B2 |
| 7585217 | Lutnick et al. | Sep 2009 | B2 |
| 7586871 | Hamilton et al. | Sep 2009 | B2 |
| 7593417 | Wang et al. | Sep 2009 | B2 |
| 7593730 | Khandelwal et al. | Sep 2009 | B2 |
| 7596373 | Mcgregor et al. | Sep 2009 | B2 |
| 7599288 | Cole et al. | Oct 2009 | B2 |
| 7599714 | Kuzminskiy | Oct 2009 | B2 |
| 7602746 | Calhoun et al. | Oct 2009 | B2 |
| 7606918 | Holzman et al. | Oct 2009 | B2 |
| 7607041 | Kraemer et al. | Oct 2009 | B2 |
| 7609650 | Roskowski et al. | Oct 2009 | B2 |
| 7609700 | Ying et al. | Oct 2009 | B1 |
| 7610047 | Hicks, III et al. | Oct 2009 | B2 |
| 7610057 | Bahl et al. | Oct 2009 | B2 |
| 7610328 | Haase et al. | Oct 2009 | B2 |
| 7610396 | Taglienti et al. | Oct 2009 | B2 |
| 7614051 | Glaum et al. | Nov 2009 | B2 |
| 7616962 | Oswal et al. | Nov 2009 | B2 |
| 7617516 | Huslak et al. | Nov 2009 | B2 |
| 7620041 | Dunn et al. | Nov 2009 | B2 |
| 7620065 | Falardeau | Nov 2009 | B2 |
| 7620162 | Aaron et al. | Nov 2009 | B2 |
| 7620383 | Taglienti et al. | Nov 2009 | B2 |
| 7627314 | Carlson et al. | Dec 2009 | B2 |
| 7627600 | Citron et al. | Dec 2009 | B2 |
| 7627767 | Sherman et al. | Dec 2009 | B2 |
| 7627872 | Hebeler et al. | Dec 2009 | B2 |
| 7633438 | Tysowski | Dec 2009 | B2 |
| 7634388 | Archer et al. | Dec 2009 | B2 |
| 7636574 | Poosala | Dec 2009 | B2 |
| 7636626 | Oesterling et al. | Dec 2009 | B2 |
| 7643411 | Andreasen et al. | Jan 2010 | B2 |
| 7644151 | Jerrim et al. | Jan 2010 | B2 |
| 7644267 | Ylikoski et al. | Jan 2010 | B2 |
| 7644414 | Smith et al. | Jan 2010 | B2 |
| 7647047 | Moghaddam et al. | Jan 2010 | B2 |
| 7650137 | Jobs et al. | Jan 2010 | B2 |
| 7653394 | McMillin | Jan 2010 | B2 |
| 7656271 | Ehrman et al. | Feb 2010 | B2 |
| 7657920 | Arseneau et al. | Feb 2010 | B2 |
| 7660419 | Ho | Feb 2010 | B1 |
| 7661124 | Ramanathan et al. | Feb 2010 | B2 |
| 7664494 | Jiang | Feb 2010 | B2 |
| 7668176 | Chuah | Feb 2010 | B2 |
| 7668612 | Okkonen | Feb 2010 | B1 |
| 7668903 | Edwards et al. | Feb 2010 | B2 |
| 7668966 | Klinker et al. | Feb 2010 | B2 |
| 7676673 | Weller et al. | Mar 2010 | B2 |
| 7680086 | Eglin | Mar 2010 | B2 |
| 7681226 | Kraemer et al. | Mar 2010 | B2 |
| 7684370 | Kezys | Mar 2010 | B2 |
| 7685131 | Batra et al. | Mar 2010 | B2 |
| 7685254 | Pandya | Mar 2010 | B2 |
| 7685530 | Sherrard et al. | Mar 2010 | B2 |
| 7688792 | Babbar et al. | Mar 2010 | B2 |
| 7693107 | De Froment | Apr 2010 | B2 |
| 7693720 | Kennewick et al. | Apr 2010 | B2 |
| 7697540 | Haddad et al. | Apr 2010 | B2 |
| 7710932 | Muthuswamy et al. | May 2010 | B2 |
| 7711848 | Maes | May 2010 | B2 |
| 7719966 | Luft et al. | May 2010 | B2 |
| 7720206 | Devolites et al. | May 2010 | B2 |
| 7720464 | Batta | May 2010 | B2 |
| 7720505 | Gopi et al. | May 2010 | B2 |
| 7720960 | Pruss et al. | May 2010 | B2 |
| 7721296 | Ricagni | May 2010 | B2 |
| 7724716 | Fadell | May 2010 | B2 |
| 7725570 | Lewis | May 2010 | B1 |
| 7729326 | Sekhar | Jun 2010 | B2 |
| 7730123 | Erickson et al. | Jun 2010 | B1 |
| 7734784 | Araujo et al. | Jun 2010 | B1 |
| 7742406 | Muppala | Jun 2010 | B1 |
| 7746854 | Ambe et al. | Jun 2010 | B2 |
| 7747240 | Briscoe et al. | Jun 2010 | B1 |
| 7747699 | Prueitt et al. | Jun 2010 | B2 |
| 7747730 | Harlow | Jun 2010 | B1 |
| 7752330 | Olsen et al. | Jul 2010 | B2 |
| 7756056 | Kim et al. | Jul 2010 | B2 |
| 7756534 | Anupam et al. | Jul 2010 | B2 |
| 7756757 | Oakes, III | Jul 2010 | B1 |
| 7760137 | Martucci et al. | Jul 2010 | B2 |
| 7760711 | Kung et al. | Jul 2010 | B1 |
| 7760861 | Croak et al. | Jul 2010 | B1 |
| 7765294 | Edwards et al. | Jul 2010 | B2 |
| 7769397 | Funato et al. | Aug 2010 | B2 |
| 7770785 | Jha et al. | Aug 2010 | B2 |
| 7774323 | Helfman | Aug 2010 | B2 |
| 7774412 | Schnepel | Aug 2010 | B1 |
| 7774456 | Lownsbrough et al. | Aug 2010 | B1 |
| 7778176 | Morford | Aug 2010 | B2 |
| 7778643 | Laroia et al. | Aug 2010 | B2 |
| 7788700 | Feezel et al. | Aug 2010 | B1 |
| 7792257 | Vanier et al. | Sep 2010 | B1 |
| 7792538 | Kozisek | Sep 2010 | B2 |
| 7792708 | Alva | Sep 2010 | B2 |
| 7797019 | Friedmann | Sep 2010 | B2 |
| 7797060 | Grgic et al. | Sep 2010 | B2 |
| 7797204 | Balent | Sep 2010 | B2 |
| 7797401 | Stewart et al. | Sep 2010 | B2 |
| 7801523 | Kenderov | Sep 2010 | B1 |
| 7801783 | Kende et al. | Sep 2010 | B2 |
| 7801985 | Pitkow et al. | Sep 2010 | B1 |
| 7802724 | Nohr | Sep 2010 | B1 |
| 7805140 | Friday et al. | Sep 2010 | B2 |
| 7805522 | Schlüter et al. | Sep 2010 | B2 |
| 7805606 | Birger et al. | Sep 2010 | B2 |
| 7809351 | Panda et al. | Oct 2010 | B1 |
| 7809372 | Rajaniemi | Oct 2010 | B2 |
| 7813746 | Rajkotia | Oct 2010 | B2 |
| 7817615 | Breau et al. | Oct 2010 | B1 |
| 7817983 | Cassett et al. | Oct 2010 | B2 |
| 7822837 | Urban et al. | Oct 2010 | B1 |
| 7822849 | Titus | Oct 2010 | B2 |
| 7826427 | Sood et al. | Nov 2010 | B2 |
| 7826607 | De Carvalho Resende et al. | Nov 2010 | B1 |
| 7835275 | Swan et al. | Nov 2010 | B1 |
| 7843831 | Morrill et al. | Nov 2010 | B2 |
| 7843843 | Papp, III et al. | Nov 2010 | B1 |
| 7844034 | Oh et al. | Nov 2010 | B1 |
| 7844728 | Anderson et al. | Nov 2010 | B2 |
| 7848768 | Omori et al. | Dec 2010 | B2 |
| 7849161 | Koch et al. | Dec 2010 | B2 |
| 7849170 | Hargens et al. | Dec 2010 | B1 |
| 7849477 | Cristofalo et al. | Dec 2010 | B2 |
| 7853255 | Karaoguz et al. | Dec 2010 | B2 |
| 7853656 | Yach et al. | Dec 2010 | B2 |
| 7856226 | Wong et al. | Dec 2010 | B2 |
| 7860088 | Lioy | Dec 2010 | B2 |
| 7865182 | Macaluso | Jan 2011 | B2 |
| 7865187 | Ramer et al. | Jan 2011 | B2 |
| 7868778 | Kenwright | Jan 2011 | B2 |
| 7873001 | Silver | Jan 2011 | B2 |
| 7873344 | Bowser et al. | Jan 2011 | B2 |
| 7873346 | Petersson et al. | Jan 2011 | B2 |
| 7873540 | Arumugam | Jan 2011 | B2 |
| 7873705 | Kalish | Jan 2011 | B2 |
| 7873985 | Baum | Jan 2011 | B2 |
| 7877090 | Maes | Jan 2011 | B2 |
| 7881199 | Krstulich | Feb 2011 | B2 |
| 7881697 | Baker et al. | Feb 2011 | B2 |
| 7882029 | White | Feb 2011 | B2 |
| 7882247 | Sturniolo et al. | Feb 2011 | B2 |
| 7882560 | Kraemer et al. | Feb 2011 | B2 |
| 7886047 | Potluri | Feb 2011 | B1 |
| 7889384 | Armentrout et al. | Feb 2011 | B2 |
| 7890084 | Dudziak et al. | Feb 2011 | B1 |
| 7890111 | Bugenhagen | Feb 2011 | B2 |
| 7894431 | Goring et al. | Feb 2011 | B2 |
| 7899039 | Andreasen et al. | Mar 2011 | B2 |
| 7899438 | Baker et al. | Mar 2011 | B2 |
| 7903553 | Liu | Mar 2011 | B2 |
| 7907970 | Park et al. | Mar 2011 | B2 |
| 7911975 | Droz et al. | Mar 2011 | B2 |
| 7912025 | Pattenden et al. | Mar 2011 | B2 |
| 7912056 | Brassem | Mar 2011 | B1 |
| 7920529 | Mahler et al. | Apr 2011 | B1 |
| 7921463 | Sood et al. | Apr 2011 | B2 |
| 7925740 | Nath et al. | Apr 2011 | B2 |
| 7925778 | Wijnands et al. | Apr 2011 | B1 |
| 7929959 | DeAtley et al. | Apr 2011 | B2 |
| 7929960 | Martin et al. | Apr 2011 | B2 |
| 7929973 | Zavalkovsky et al. | Apr 2011 | B2 |
| 7930327 | Craft et al. | Apr 2011 | B2 |
| 7930446 | Kesselman et al. | Apr 2011 | B2 |
| 7930553 | Satarasinghe et al. | Apr 2011 | B2 |
| 7933274 | Verma et al. | Apr 2011 | B2 |
| 7936736 | Proctor, Jr. et al. | May 2011 | B2 |
| 7937069 | Rassam | May 2011 | B2 |
| 7937450 | Janik | May 2011 | B2 |
| 7940685 | Breslau et al. | May 2011 | B1 |
| 7940751 | Hansen | May 2011 | B2 |
| 7941184 | Prendergast et al. | May 2011 | B2 |
| 7944948 | Chow et al. | May 2011 | B2 |
| 7945238 | Baker et al. | May 2011 | B2 |
| 7945240 | Klock et al. | May 2011 | B1 |
| 7945945 | Graham et al. | May 2011 | B2 |
| 7948952 | Hurtta et al. | May 2011 | B2 |
| 7948953 | Melkote et al. | May 2011 | B2 |
| 7948968 | Voit et al. | May 2011 | B2 |
| 7949529 | Weider et al. | May 2011 | B2 |
| 7953808 | Sharp et al. | May 2011 | B2 |
| 7953877 | Vemula et al. | May 2011 | B2 |
| 7957020 | Mine et al. | Jun 2011 | B2 |
| 7957381 | Clermidy et al. | Jun 2011 | B2 |
| 7957511 | Drudis et al. | Jun 2011 | B2 |
| 7958029 | Bobich et al. | Jun 2011 | B1 |
| 7962622 | Friend et al. | Jun 2011 | B2 |
| 7965983 | Swan et al. | Jun 2011 | B1 |
| 7966405 | Sundaresan et al. | Jun 2011 | B2 |
| 7969950 | Iyer et al. | Jun 2011 | B2 |
| 7970350 | Sheynman | Jun 2011 | B2 |
| 7970426 | Poe et al. | Jun 2011 | B2 |
| 7974624 | Gallagher et al. | Jul 2011 | B2 |
| 7975184 | Goff et al. | Jul 2011 | B2 |
| 7978627 | Taylor et al. | Jul 2011 | B2 |
| 7978686 | Goyal et al. | Jul 2011 | B2 |
| 7979069 | Hupp et al. | Jul 2011 | B2 |
| 7979889 | Gladstone et al. | Jul 2011 | B2 |
| 7979896 | McMurtry et al. | Jul 2011 | B2 |
| 7984130 | Bogineni et al. | Jul 2011 | B2 |
| 7984511 | Kocher et al. | Jul 2011 | B2 |
| 7986935 | D'Souza et al. | Jul 2011 | B1 |
| 7987496 | Bryce et al. | Jul 2011 | B2 |
| 7987510 | Kocher et al. | Jul 2011 | B2 |
| 7990049 | Shioya | Aug 2011 | B2 |
| 8000276 | Scherzer et al. | Aug 2011 | B2 |
| 8000318 | Wiley et al. | Aug 2011 | B2 |
| 8005009 | McKee et al. | Aug 2011 | B2 |
| 8005459 | Balsillie | Aug 2011 | B2 |
| 8005726 | Bao | Aug 2011 | B1 |
| 8005913 | Carlander | Aug 2011 | B1 |
| 8005988 | Maes | Aug 2011 | B2 |
| 8010080 | Thenthiruperai et al. | Aug 2011 | B1 |
| 8010081 | Roskowski | Aug 2011 | B1 |
| 8010082 | Sutaria et al. | Aug 2011 | B2 |
| 8010990 | Ferguson et al. | Aug 2011 | B2 |
| 8015133 | Wu et al. | Sep 2011 | B1 |
| 8015234 | Lum et al. | Sep 2011 | B2 |
| 8015249 | Nayak et al. | Sep 2011 | B2 |
| 8019687 | Wang et al. | Sep 2011 | B2 |
| 8019820 | Son et al. | Sep 2011 | B2 |
| 8019846 | Roelens et al. | Sep 2011 | B2 |
| 8019868 | Rao et al. | Sep 2011 | B2 |
| 8019886 | Harrang et al. | Sep 2011 | B2 |
| 8023425 | Raleigh | Sep 2011 | B2 |
| 8024397 | Erickson et al. | Sep 2011 | B1 |
| 8024424 | Freimuth et al. | Sep 2011 | B2 |
| 8027339 | Short et al. | Sep 2011 | B2 |
| 8031601 | Feroz et al. | Oct 2011 | B2 |
| 8032168 | Ikaheimo | Oct 2011 | B2 |
| 8032409 | Mikurak | Oct 2011 | B1 |
| 8032899 | Archer et al. | Oct 2011 | B2 |
| 8036387 | Kudelski et al. | Oct 2011 | B2 |
| 8036600 | Garrett et al. | Oct 2011 | B2 |
| 8044792 | Orr et al. | Oct 2011 | B2 |
| 8045973 | Chambers | Oct 2011 | B2 |
| 8046449 | Yoshiuchi | Oct 2011 | B2 |
| 8050275 | Iyer | Nov 2011 | B1 |
| 8050690 | Neeraj | Nov 2011 | B2 |
| 8050705 | Sicher et al. | Nov 2011 | B2 |
| 8059530 | Cole | Nov 2011 | B1 |
| 8060017 | Schlicht et al. | Nov 2011 | B2 |
| 8060463 | Spiegel | Nov 2011 | B1 |
| 8064418 | Maki | Nov 2011 | B2 |
| 8064896 | Bell et al. | Nov 2011 | B2 |
| 8065365 | Saxena et al. | Nov 2011 | B2 |
| 8068824 | Shan et al. | Nov 2011 | B2 |
| 8068829 | Lemond et al. | Nov 2011 | B2 |
| 8073427 | Koch et al. | Dec 2011 | B2 |
| 8073721 | Lewis | Dec 2011 | B1 |
| 8078140 | Baker et al. | Dec 2011 | B2 |
| 8078163 | Lemond et al. | Dec 2011 | B2 |
| 8081612 | Want et al. | Dec 2011 | B2 |
| 8085808 | Brusca et al. | Dec 2011 | B2 |
| 8086398 | Sanchez et al. | Dec 2011 | B2 |
| 8086497 | Oakes, III | Dec 2011 | B1 |
| 8086791 | Caulkins | Dec 2011 | B2 |
| 8090359 | Proctor, Jr. et al. | Jan 2012 | B2 |
| 8090361 | Hagan | Jan 2012 | B2 |
| 8090616 | Proctor, Jr. et al. | Jan 2012 | B2 |
| 8091087 | Ali et al. | Jan 2012 | B2 |
| 8094551 | Huber et al. | Jan 2012 | B2 |
| 8095112 | Chow et al. | Jan 2012 | B2 |
| 8095124 | Balla | Jan 2012 | B2 |
| 8095175 | Todd et al. | Jan 2012 | B2 |
| 8095640 | Guingo et al. | Jan 2012 | B2 |
| 8095666 | Schmidt et al. | Jan 2012 | B2 |
| 8098579 | Ray et al. | Jan 2012 | B2 |
| 8099077 | Chowdhury et al. | Jan 2012 | B2 |
| 8099517 | Jia et al. | Jan 2012 | B2 |
| 8102814 | Rahman et al. | Jan 2012 | B2 |
| 8103285 | Kalhan | Jan 2012 | B2 |
| 8104080 | Burns et al. | Jan 2012 | B2 |
| 8107953 | Zimmerman et al. | Jan 2012 | B2 |
| 8108520 | Ruutu et al. | Jan 2012 | B2 |
| 8108680 | Murray | Jan 2012 | B2 |
| 8112435 | Epstein et al. | Feb 2012 | B2 |
| 8116223 | Tian et al. | Feb 2012 | B2 |
| 8116749 | Proctor, Jr. et al. | Feb 2012 | B2 |
| 8116781 | Chen et al. | Feb 2012 | B2 |
| 8122128 | Burke, II et al. | Feb 2012 | B2 |
| 8122249 | Falk et al. | Feb 2012 | B2 |
| 8125897 | Ray et al. | Feb 2012 | B2 |
| 8126123 | Cai et al. | Feb 2012 | B2 |
| 8126396 | Bennett | Feb 2012 | B2 |
| 8126476 | Vardi et al. | Feb 2012 | B2 |
| 8126722 | Robb et al. | Feb 2012 | B2 |
| 8130793 | Edwards et al. | Mar 2012 | B2 |
| 8131256 | Martti et al. | Mar 2012 | B2 |
| 8131281 | Hildner et al. | Mar 2012 | B1 |
| 8131840 | Denker | Mar 2012 | B1 |
| 8131858 | Agulnik et al. | Mar 2012 | B2 |
| 8132256 | Bari | Mar 2012 | B2 |
| 8134954 | Godfrey et al. | Mar 2012 | B2 |
| 8135388 | Gailloux et al. | Mar 2012 | B1 |
| 8135392 | Marcellino et al. | Mar 2012 | B2 |
| 8135657 | Kapoor et al. | Mar 2012 | B2 |
| 8140690 | Ly et al. | Mar 2012 | B2 |
| 8144591 | Ghai et al. | Mar 2012 | B2 |
| 8145194 | Yoshikawa et al. | Mar 2012 | B2 |
| 8146142 | Lortz et al. | Mar 2012 | B2 |
| 8149748 | Bata et al. | Apr 2012 | B2 |
| 8149823 | Turcan et al. | Apr 2012 | B2 |
| 8150394 | Bianconi et al. | Apr 2012 | B2 |
| 8150431 | Wolovitz et al. | Apr 2012 | B2 |
| 8151205 | Follmann et al. | Apr 2012 | B2 |
| 8155155 | Chow et al. | Apr 2012 | B1 |
| 8155620 | Wang et al. | Apr 2012 | B2 |
| 8155666 | Alizadeh-Shabdiz | Apr 2012 | B2 |
| 8155670 | Fullam et al. | Apr 2012 | B2 |
| 8156206 | Kiley et al. | Apr 2012 | B2 |
| 8159520 | Dhanoa et al. | Apr 2012 | B1 |
| 8160015 | Rashid et al. | Apr 2012 | B2 |
| 8160056 | Van der Merwe et al. | Apr 2012 | B2 |
| 8160598 | Savoor | Apr 2012 | B2 |
| 8165576 | Raju et al. | Apr 2012 | B2 |
| 8166040 | Brindisi et al. | Apr 2012 | B2 |
| 8166554 | John | Apr 2012 | B2 |
| 8170553 | Bennett | May 2012 | B2 |
| 8174378 | Richman et al. | May 2012 | B2 |
| 8174970 | Adamczyk et al. | May 2012 | B2 |
| 8175574 | Panda et al. | May 2012 | B1 |
| 8180333 | Wells et al. | May 2012 | B1 |
| 8180881 | Seo et al. | May 2012 | B2 |
| 8180886 | Overcash et al. | May 2012 | B2 |
| 8184530 | Swan et al. | May 2012 | B1 |
| 8184590 | Rosenblatt | May 2012 | B2 |
| 8185088 | Klein et al. | May 2012 | B2 |
| 8185093 | Jheng et al. | May 2012 | B2 |
| 8185127 | Cai et al. | May 2012 | B1 |
| 8185152 | Goldner | May 2012 | B1 |
| 8185158 | Tamura et al. | May 2012 | B2 |
| 8190087 | Fisher et al. | May 2012 | B2 |
| 8190122 | Alexander et al. | May 2012 | B1 |
| 8190675 | Tribbett | May 2012 | B2 |
| 8191106 | Choyi et al. | May 2012 | B2 |
| 8191116 | Gazzard | May 2012 | B1 |
| 8191124 | Wynn et al. | May 2012 | B2 |
| 8194549 | Huber et al. | Jun 2012 | B2 |
| 8194553 | Liang et al. | Jun 2012 | B2 |
| 8194572 | Horvath et al. | Jun 2012 | B2 |
| 8194581 | Schroeder et al. | Jun 2012 | B1 |
| 8195093 | Garrett et al. | Jun 2012 | B2 |
| 8195153 | Frencel et al. | Jun 2012 | B1 |
| 8195163 | Gisby et al. | Jun 2012 | B2 |
| 8195661 | Kalavade | Jun 2012 | B2 |
| 8196199 | Hrastar et al. | Jun 2012 | B2 |
| 8200163 | Hoffman | Jun 2012 | B2 |
| 8200200 | Belser et al. | Jun 2012 | B1 |
| 8200509 | Kenedy et al. | Jun 2012 | B2 |
| 8200775 | Moore | Jun 2012 | B2 |
| 8200818 | Freund et al. | Jun 2012 | B2 |
| 8204190 | Bang et al. | Jun 2012 | B2 |
| 8204505 | Jin et al. | Jun 2012 | B2 |
| 8204794 | Peng et al. | Jun 2012 | B1 |
| 8208788 | Ando et al. | Jun 2012 | B2 |
| 8208919 | Kotecha | Jun 2012 | B2 |
| 8213296 | Shannon et al. | Jul 2012 | B2 |
| 8213363 | Ying et al. | Jul 2012 | B2 |
| 8214536 | Zhao | Jul 2012 | B2 |
| 8214890 | Kirovski et al. | Jul 2012 | B2 |
| 8219134 | Maharajh et al. | Jul 2012 | B2 |
| 8223655 | Heinz et al. | Jul 2012 | B2 |
| 8223741 | Bartlett et al. | Jul 2012 | B1 |
| 8224382 | Bultman | Jul 2012 | B2 |
| 8224773 | Spiegel | Jul 2012 | B2 |
| 8228818 | Chase et al. | Jul 2012 | B2 |
| 8229394 | Karlberg | Jul 2012 | B2 |
| 8229914 | Ramer et al. | Jul 2012 | B2 |
| 8230061 | Hassan et al. | Jul 2012 | B2 |
| 8233433 | Kalhan | Jul 2012 | B2 |
| 8233883 | De Froment | Jul 2012 | B2 |
| 8233895 | Tysowski | Jul 2012 | B2 |
| 8234583 | Sloo et al. | Jul 2012 | B2 |
| 8238287 | Gopi et al. | Aug 2012 | B1 |
| 8239520 | Grah | Aug 2012 | B2 |
| 8242959 | Mia et al. | Aug 2012 | B2 |
| 8244241 | Montemurro | Aug 2012 | B2 |
| 8249601 | Emberson et al. | Aug 2012 | B2 |
| 8254880 | Aaltonen et al. | Aug 2012 | B2 |
| 8254915 | Kozisek | Aug 2012 | B2 |
| 8255515 | Melman et al. | Aug 2012 | B1 |
| 8255534 | Assadzadeh | Aug 2012 | B2 |
| 8255689 | Kim et al. | Aug 2012 | B2 |
| 8259692 | Bajko | Sep 2012 | B2 |
| 8264965 | Dolganow et al. | Sep 2012 | B2 |
| 8265004 | Toutonghi | Sep 2012 | B2 |
| 8266249 | Hu | Sep 2012 | B2 |
| 8266681 | Deshpande et al. | Sep 2012 | B2 |
| 8270955 | Ramer et al. | Sep 2012 | B2 |
| 8270972 | Otting et al. | Sep 2012 | B2 |
| 8271025 | Brisebois et al. | Sep 2012 | B2 |
| 8271045 | Parolkar et al. | Sep 2012 | B2 |
| 8271049 | Silver et al. | Sep 2012 | B2 |
| 8271992 | Chatley et al. | Sep 2012 | B2 |
| 8275415 | Huslak | Sep 2012 | B2 |
| 8275830 | Raleigh | Sep 2012 | B2 |
| 8279067 | Berger et al. | Oct 2012 | B2 |
| 8279864 | Wood | Oct 2012 | B2 |
| 8280351 | Ahmed et al. | Oct 2012 | B1 |
| 8280354 | Smith et al. | Oct 2012 | B2 |
| 8284740 | O'Connor | Oct 2012 | B2 |
| 8285249 | Baker et al. | Oct 2012 | B2 |
| 8285992 | Mathur et al. | Oct 2012 | B2 |
| 8291238 | Ginter et al. | Oct 2012 | B2 |
| 8291439 | Jethi et al. | Oct 2012 | B2 |
| 8296404 | McDysan et al. | Oct 2012 | B2 |
| 8300575 | Willars | Oct 2012 | B2 |
| 8301513 | Peng et al. | Oct 2012 | B1 |
| 8306518 | Gailloux | Nov 2012 | B1 |
| 8306741 | Tu | Nov 2012 | B2 |
| 8307067 | Ryan | Nov 2012 | B2 |
| 8307095 | Clark et al. | Nov 2012 | B2 |
| 8310943 | Mehta et al. | Nov 2012 | B2 |
| 8315198 | Corneille et al. | Nov 2012 | B2 |
| 8315593 | Gallant et al. | Nov 2012 | B2 |
| 8315594 | Mauser et al. | Nov 2012 | B1 |
| 8315718 | Caffrey et al. | Nov 2012 | B2 |
| 8315999 | Chatley et al. | Nov 2012 | B2 |
| 8320244 | Muqattash et al. | Nov 2012 | B2 |
| 8320902 | Moring et al. | Nov 2012 | B2 |
| 8320949 | Matta | Nov 2012 | B2 |
| 8325638 | Jin et al. | Dec 2012 | B2 |
| 8325906 | Fullarton et al. | Dec 2012 | B2 |
| 8326319 | Davis | Dec 2012 | B2 |
| 8326359 | Kauffman | Dec 2012 | B2 |
| 8326828 | Zhou et al. | Dec 2012 | B2 |
| 8331223 | Hill et al. | Dec 2012 | B2 |
| 8331293 | Sood | Dec 2012 | B2 |
| 8332375 | Chatley et al. | Dec 2012 | B2 |
| 8332517 | Russell | Dec 2012 | B2 |
| 8335161 | Foottit et al. | Dec 2012 | B2 |
| 8339991 | Biswas et al. | Dec 2012 | B2 |
| 8340625 | Johnson et al. | Dec 2012 | B1 |
| 8340628 | Taylor et al. | Dec 2012 | B2 |
| 8340678 | Pandey | Dec 2012 | B1 |
| 8340718 | Colonna et al. | Dec 2012 | B2 |
| 8346210 | Balsan et al. | Jan 2013 | B2 |
| 8346923 | Rowles et al. | Jan 2013 | B2 |
| 8347104 | Pathiyal | Jan 2013 | B2 |
| 8347362 | Cai et al. | Jan 2013 | B2 |
| 8347378 | Merkin et al. | Jan 2013 | B2 |
| 8350700 | Fast et al. | Jan 2013 | B2 |
| 8351592 | Freeny, Jr. et al. | Jan 2013 | B2 |
| 8351898 | Raleigh | Jan 2013 | B2 |
| 8352360 | De Judicibus et al. | Jan 2013 | B2 |
| 8352630 | Hart | Jan 2013 | B2 |
| 8352980 | Howcroft | Jan 2013 | B2 |
| 8353001 | Herrod | Jan 2013 | B2 |
| 8355570 | Karsanbhal et al. | Jan 2013 | B2 |
| 8355696 | Olding et al. | Jan 2013 | B1 |
| 8356336 | Johnston et al. | Jan 2013 | B2 |
| 8358638 | Scherzer et al. | Jan 2013 | B2 |
| 8358975 | Bahl et al. | Jan 2013 | B2 |
| 8363658 | Delker et al. | Jan 2013 | B1 |
| 8363799 | Gruchala et al. | Jan 2013 | B2 |
| 8364089 | Phillips | Jan 2013 | B2 |
| 8364806 | Short et al. | Jan 2013 | B2 |
| 8369274 | Sawai | Feb 2013 | B2 |
| 8370477 | Short et al. | Feb 2013 | B2 |
| 8370483 | Choong et al. | Feb 2013 | B2 |
| 8374090 | Morrill et al. | Feb 2013 | B2 |
| 8374592 | Proctor, Jr. et al. | Feb 2013 | B2 |
| 8375128 | Tofighbakhsh et al. | Feb 2013 | B2 |
| 8375136 | Roman et al. | Feb 2013 | B2 |
| 8379847 | Bell et al. | Feb 2013 | B2 |
| 8380247 | Engstrom | Feb 2013 | B2 |
| 8385199 | Coward et al. | Feb 2013 | B1 |
| 8385896 | Proctor, Jr. et al. | Feb 2013 | B2 |
| 8385964 | Haney | Feb 2013 | B2 |
| 8385975 | Forutanpour et al. | Feb 2013 | B2 |
| 8386386 | Zhu | Feb 2013 | B1 |
| 8391262 | Maki et al. | Mar 2013 | B2 |
| 8391834 | Raleigh | Mar 2013 | B2 |
| 8392982 | Harris et al. | Mar 2013 | B2 |
| 8396458 | Raleigh | Mar 2013 | B2 |
| 8396929 | Helfman et al. | Mar 2013 | B2 |
| 8401968 | Schattauer et al. | Mar 2013 | B1 |
| 8402165 | Deu-Ngoc et al. | Mar 2013 | B2 |
| 8402540 | Kapoor et al. | Mar 2013 | B2 |
| 8406427 | Chand et al. | Mar 2013 | B2 |
| 8406736 | Das et al. | Mar 2013 | B2 |
| 8407472 | Hao et al. | Mar 2013 | B2 |
| 8407763 | Weller et al. | Mar 2013 | B2 |
| 8411587 | Curtis et al. | Apr 2013 | B2 |
| 8411691 | Aggarwal | Apr 2013 | B2 |
| 8412798 | Wang | Apr 2013 | B1 |
| 8413245 | Kraemer et al. | Apr 2013 | B2 |
| 8418168 | Tyhurst et al. | Apr 2013 | B2 |
| 8422988 | Keshav | Apr 2013 | B1 |
| 8423016 | Buckley et al. | Apr 2013 | B2 |
| 8429403 | Moret et al. | Apr 2013 | B2 |
| 8429409 | Wall et al. | Apr 2013 | B1 |
| 8437734 | Ray et al. | May 2013 | B2 |
| 8441955 | Wilkinson et al. | May 2013 | B2 |
| 8442015 | Behzad et al. | May 2013 | B2 |
| 8446831 | Kwan et al. | May 2013 | B2 |
| 8447324 | Shuman et al. | May 2013 | B2 |
| 8447607 | Weider et al. | May 2013 | B2 |
| 8447980 | Godfrey et al. | May 2013 | B2 |
| 8448015 | Gerhart | May 2013 | B2 |
| 8452858 | Wu et al. | May 2013 | B2 |
| 8461958 | Saenz et al. | Jun 2013 | B2 |
| 8463194 | Erienback et al. | Jun 2013 | B2 |
| 8463232 | Tull et al. | Jun 2013 | B2 |
| 8468337 | Gaur et al. | Jun 2013 | B2 |
| 8472371 | Bari et al. | Jun 2013 | B1 |
| 8477778 | Lehmann, Jr. et al. | Jul 2013 | B2 |
| 8483057 | Cuervo | Jul 2013 | B2 |
| 8483135 | Cai et al. | Jul 2013 | B2 |
| 8483694 | Lewis et al. | Jul 2013 | B2 |
| 8484327 | Werner et al. | Jul 2013 | B2 |
| 8484568 | Rados et al. | Jul 2013 | B2 |
| 8488597 | Nie et al. | Jul 2013 | B2 |
| 8489110 | Frank et al. | Jul 2013 | B2 |
| 8489720 | Morford et al. | Jul 2013 | B1 |
| 8494559 | Malmi | Jul 2013 | B1 |
| 8495181 | Venkatraman et al. | Jul 2013 | B2 |
| 8495227 | Kaminsky et al. | Jul 2013 | B2 |
| 8495360 | Falk et al. | Jul 2013 | B2 |
| 8495700 | Shahbazi | Jul 2013 | B2 |
| 8495743 | Kraemer et al. | Jul 2013 | B2 |
| 8499087 | Hu | Jul 2013 | B2 |
| RE44412 | Naqvi et al. | Aug 2013 | E |
| 8500533 | Lutnick et al. | Aug 2013 | B2 |
| 8503358 | Hanson et al. | Aug 2013 | B2 |
| 8503455 | Heikens | Aug 2013 | B2 |
| 8504032 | Lott et al. | Aug 2013 | B2 |
| 8504574 | Dvorak et al. | Aug 2013 | B2 |
| 8504687 | Maffione et al. | Aug 2013 | B2 |
| 8504690 | Shah et al. | Aug 2013 | B2 |
| 8504729 | Pezzutti | Aug 2013 | B2 |
| 8505073 | Taglienti et al. | Aug 2013 | B2 |
| 8509082 | Heinz et al. | Aug 2013 | B2 |
| 8514927 | Sundararajan et al. | Aug 2013 | B2 |
| 8516552 | Raleigh | Aug 2013 | B2 |
| 8520589 | Bhatt et al. | Aug 2013 | B2 |
| 8520595 | Yadav et al. | Aug 2013 | B2 |
| 8521110 | Rofougaran | Aug 2013 | B2 |
| 8521775 | Poh et al. | Aug 2013 | B1 |
| 8522039 | Hyndman et al. | Aug 2013 | B2 |
| 8522249 | Beaule | Aug 2013 | B2 |
| 8522337 | Adusumilli et al. | Aug 2013 | B2 |
| 8523547 | Pekrul | Sep 2013 | B2 |
| 8526329 | Mahany et al. | Sep 2013 | B2 |
| 8526350 | Xue et al. | Sep 2013 | B2 |
| 8527013 | Guba et al. | Sep 2013 | B2 |
| 8527410 | Markki et al. | Sep 2013 | B2 |
| 8527662 | Biswas et al. | Sep 2013 | B2 |
| 8528068 | Weglein et al. | Sep 2013 | B1 |
| 8531954 | McNaughton et al. | Sep 2013 | B2 |
| 8531995 | Khan et al. | Sep 2013 | B2 |
| 8532610 | Manning Cassett et al. | Sep 2013 | B2 |
| 8533775 | Alcorn et al. | Sep 2013 | B2 |
| 8535160 | Lutnick et al. | Sep 2013 | B2 |
| 8538394 | Zimmerman et al. | Sep 2013 | B2 |
| 8538402 | Vidal et al. | Sep 2013 | B2 |
| 8538421 | Brisebois et al. | Sep 2013 | B2 |
| 8538458 | Haney | Sep 2013 | B2 |
| 8539544 | Garimella et al. | Sep 2013 | B2 |
| 8539561 | Gupta et al. | Sep 2013 | B2 |
| 8543265 | Ekhaguere et al. | Sep 2013 | B2 |
| 8543814 | Laitinen et al. | Sep 2013 | B2 |
| 8544105 | Mclean et al. | Sep 2013 | B2 |
| 8548427 | Chow et al. | Oct 2013 | B2 |
| 8548428 | Raleigh | Oct 2013 | B2 |
| 8549173 | Wu et al. | Oct 2013 | B1 |
| 8554876 | Winsor | Oct 2013 | B2 |
| 8559369 | Barkan | Oct 2013 | B2 |
| 8561138 | Rothman et al. | Oct 2013 | B2 |
| 8565746 | Hoffman | Oct 2013 | B2 |
| 8566236 | Busch | Oct 2013 | B2 |
| 8571474 | Chavez et al. | Oct 2013 | B2 |
| 8571501 | Miller et al. | Oct 2013 | B2 |
| 8571598 | Valavi | Oct 2013 | B2 |
| 8571993 | Kocher et al. | Oct 2013 | B2 |
| 8572117 | Rappaport | Oct 2013 | B2 |
| 8572256 | Babbar | Oct 2013 | B2 |
| 8583499 | De Judicibus et al. | Nov 2013 | B2 |
| 8588240 | Ramankutty et al. | Nov 2013 | B2 |
| 8589541 | Raleigh et al. | Nov 2013 | B2 |
| 8589955 | Roundtree et al. | Nov 2013 | B2 |
| 8594665 | Anschutz | Nov 2013 | B2 |
| 8595186 | Mandyam et al. | Nov 2013 | B1 |
| 8600850 | Zabawskyj et al. | Dec 2013 | B2 |
| 8600895 | Felsher | Dec 2013 | B2 |
| 8601125 | Huang et al. | Dec 2013 | B2 |
| 8605691 | Soomro et al. | Dec 2013 | B2 |
| 8615507 | Varadarajulu et al. | Dec 2013 | B2 |
| 8619735 | Montemurro et al. | Dec 2013 | B2 |
| 8620257 | Qiu et al. | Dec 2013 | B2 |
| 8621056 | Coussemaeker et al. | Dec 2013 | B2 |
| 8626115 | Raleigh et al. | Jan 2014 | B2 |
| 8630314 | York | Jan 2014 | B2 |
| 8630925 | Bystrom et al. | Jan 2014 | B2 |
| 8631428 | Scott et al. | Jan 2014 | B2 |
| 8634425 | Gorti et al. | Jan 2014 | B2 |
| 8635164 | Rosenhaft et al. | Jan 2014 | B2 |
| 8639215 | McGregor et al. | Jan 2014 | B2 |
| 8644702 | Kalajan | Feb 2014 | B1 |
| 8644813 | Gallloux et al. | Feb 2014 | B1 |
| 8645518 | David | Feb 2014 | B2 |
| 8655357 | Gazzard et al. | Feb 2014 | B1 |
| 8656472 | McMurtry et al. | Feb 2014 | B2 |
| 8660853 | Robb et al. | Feb 2014 | B2 |
| 8666395 | Silver | Mar 2014 | B2 |
| 8667542 | Bertz et al. | Mar 2014 | B1 |
| 8670334 | Keohane et al. | Mar 2014 | B2 |
| 8670752 | Fan et al. | Mar 2014 | B2 |
| 8675852 | Maes | Mar 2014 | B2 |
| 8676682 | Kalliola | Mar 2014 | B2 |
| 8676925 | Liu et al. | Mar 2014 | B1 |
| 8693323 | McDysan | Apr 2014 | B1 |
| 8694772 | Kao et al. | Apr 2014 | B2 |
| 8700729 | Dua | Apr 2014 | B2 |
| 8701015 | Bonnat | Apr 2014 | B2 |
| 8705361 | Venkataraman et al. | Apr 2014 | B2 |
| 8706863 | Fadell | Apr 2014 | B2 |
| 8712631 | Tietjen et al. | Apr 2014 | B2 |
| 8713535 | Malhotra et al. | Apr 2014 | B2 |
| 8713641 | Pagan et al. | Apr 2014 | B1 |
| 8719397 | Levi et al. | May 2014 | B2 |
| 8719423 | Wyld | May 2014 | B2 |
| 8725899 | Short et al. | May 2014 | B2 |
| 8730842 | Collins et al. | May 2014 | B2 |
| 8731519 | Flynn et al. | May 2014 | B2 |
| 8732808 | Sewall et al. | May 2014 | B2 |
| 8739035 | Trethewey | May 2014 | B2 |
| 8744339 | Halfmann et al. | Jun 2014 | B2 |
| 8761711 | Grignani et al. | Jun 2014 | B2 |
| 8780857 | Balasubramanian et al. | Jul 2014 | B2 |
| 8787249 | Giaretta et al. | Jul 2014 | B2 |
| 8792857 | Cai et al. | Jul 2014 | B2 |
| 8793304 | Lu et al. | Jul 2014 | B2 |
| 8798610 | Prakash et al. | Aug 2014 | B2 |
| 8799227 | Ferguson et al. | Aug 2014 | B2 |
| 8799440 | Zhou et al. | Aug 2014 | B2 |
| 8804517 | Oerton | Aug 2014 | B2 |
| 8804695 | Branam | Aug 2014 | B2 |
| 8811338 | Jin et al. | Aug 2014 | B2 |
| 8811991 | Jain et al. | Aug 2014 | B2 |
| 8812525 | Taylor, III | Aug 2014 | B1 |
| 8818394 | Bienas et al. | Aug 2014 | B2 |
| 8819253 | Simeloff et al. | Aug 2014 | B2 |
| 8825109 | Montemurro et al. | Sep 2014 | B2 |
| 8826411 | Moen et al. | Sep 2014 | B2 |
| 8831561 | Sutaria et al. | Sep 2014 | B2 |
| 8837322 | Venkataramanan et al. | Sep 2014 | B2 |
| 8838686 | Getchius | Sep 2014 | B2 |
| 8838752 | Lor et al. | Sep 2014 | B2 |
| 8843849 | Neil et al. | Sep 2014 | B2 |
| 8845415 | Lutnick et al. | Sep 2014 | B2 |
| 8849297 | Balasubramanian | Sep 2014 | B2 |
| 8855620 | Sievers et al. | Oct 2014 | B2 |
| 8862751 | Faccin et al. | Oct 2014 | B2 |
| 8863111 | Selitser et al. | Oct 2014 | B2 |
| 8868725 | Samba | Oct 2014 | B2 |
| 8868727 | Yumerefendi et al. | Oct 2014 | B2 |
| 8875042 | LeJeune et al. | Oct 2014 | B2 |
| 8880047 | Konicek et al. | Nov 2014 | B2 |
| 8891483 | Connelly et al. | Nov 2014 | B2 |
| 8898748 | Burks et al. | Nov 2014 | B2 |
| 8908516 | Tzamaloukas et al. | Dec 2014 | B2 |
| 8929374 | Tönsing et al. | Jan 2015 | B2 |
| 8930238 | Coffman et al. | Jan 2015 | B2 |
| 8930551 | Pandya et al. | Jan 2015 | B2 |
| 8943551 | Ganapathy et al. | Jan 2015 | B2 |
| 8948726 | Smith et al. | Feb 2015 | B2 |
| 8949382 | Cornett et al. | Feb 2015 | B2 |
| 8949597 | Reeves et al. | Feb 2015 | B1 |
| 8955038 | Nicodemus et al. | Feb 2015 | B2 |
| 8966018 | Bugwadia et al. | Feb 2015 | B2 |
| 8971841 | Menezes et al. | Mar 2015 | B2 |
| 8971912 | Chou et al. | Mar 2015 | B2 |
| 8972537 | Bastian et al. | Mar 2015 | B2 |
| 8977284 | Reed | Mar 2015 | B2 |
| 8977856 | Malek et al. | Mar 2015 | B2 |
| 8983860 | Beda, III et al. | Mar 2015 | B1 |
| 8995952 | Baker et al. | Mar 2015 | B1 |
| 9002322 | Cotterill | Apr 2015 | B2 |
| 9002342 | Tenhunen et al. | Apr 2015 | B2 |
| 9014973 | Ruckart | Apr 2015 | B2 |
| 9015331 | Lai et al. | Apr 2015 | B2 |
| 9021069 | Ducrou et al. | Apr 2015 | B2 |
| 9026100 | Castro et al. | May 2015 | B2 |
| 9030934 | Shah et al. | May 2015 | B2 |
| 9032427 | Gallant et al. | May 2015 | B2 |
| 9042923 | Mirho | May 2015 | B1 |
| 9043462 | Badlee et al. | May 2015 | B2 |
| 9047651 | Roumellotis et al. | Jun 2015 | B2 |
| 9049010 | Jueneman et al. | Jun 2015 | B2 |
| 9064275 | Lu et al. | Jun 2015 | B1 |
| 9105031 | Shen et al. | Aug 2015 | B2 |
| 9111088 | Ghai et al. | Aug 2015 | B2 |
| 9135037 | Petrescu-Prahova et al. | Sep 2015 | B1 |
| 9137286 | Yuan | Sep 2015 | B1 |
| 9137389 | Neal et al. | Sep 2015 | B2 |
| 9172553 | Dawes et al. | Oct 2015 | B2 |
| 9173090 | Tuchman et al. | Oct 2015 | B2 |
| 9176913 | Millet et al. | Nov 2015 | B2 |
| 9177455 | Remer | Nov 2015 | B2 |
| 9191394 | Novak et al. | Nov 2015 | B2 |
| 9265003 | Zhao et al. | Feb 2016 | B2 |
| 9277433 | Raleigh et al. | Mar 2016 | B2 |
| 9282460 | Souissi | Mar 2016 | B2 |
| 9286469 | Kraemer et al. | Mar 2016 | B2 |
| 9286604 | Aabye et al. | Mar 2016 | B2 |
| 9298723 | Vincent | Mar 2016 | B1 |
| 9313708 | Nam et al. | Apr 2016 | B2 |
| 9325737 | Gutowski et al. | Apr 2016 | B2 |
| 9326173 | Luft | Apr 2016 | B2 |
| 9344557 | Gruchala et al. | May 2016 | B2 |
| 9361451 | Oberheide et al. | Jun 2016 | B2 |
| 9363285 | Kitamura | Jun 2016 | B2 |
| 9367680 | Mahaffey et al. | Jun 2016 | B2 |
| 9369959 | Ruutu et al. | Jun 2016 | B2 |
| 9386045 | Kgil et al. | Jul 2016 | B2 |
| 9402254 | Kneckt et al. | Jul 2016 | B2 |
| 9413546 | Meier et al. | Aug 2016 | B2 |
| 9418381 | Ahuja et al. | Aug 2016 | B2 |
| 9438642 | Alberth, Jr. et al. | Sep 2016 | B2 |
| 9454598 | Hwang et al. | Sep 2016 | B2 |
| 9459767 | Cockcroft et al. | Oct 2016 | B2 |
| 9479917 | Gota et al. | Oct 2016 | B1 |
| 9501803 | Bilac et al. | Nov 2016 | B2 |
| 9560108 | Salkintzis | Jan 2017 | B2 |
| 9589117 | Ali et al. | Mar 2017 | B2 |
| 9609459 | Raleigh | Mar 2017 | B2 |
| 9634850 | Taft et al. | Apr 2017 | B2 |
| 9648022 | Peterka et al. | May 2017 | B2 |
| 9681003 | Kim et al. | Jun 2017 | B1 |
| 9712476 | Boynton et al. | Jul 2017 | B2 |
| 10002332 | Spong | Jun 2018 | B2 |
| 10057775 | Raleigh et al. | Aug 2018 | B2 |
| 10171988 | Raleigh et al. | Jan 2019 | B2 |
| 10171990 | Raleigh et al. | Jan 2019 | B2 |
| 10248996 | Raleigh | Apr 2019 | B2 |
| 10264138 | Raleigh et al. | Apr 2019 | B2 |
| 10285025 | Baker et al. | May 2019 | B1 |
| 10462627 | Raleigh et al. | Oct 2019 | B2 |
| 10492102 | Raleigh et al. | Nov 2019 | B2 |
| 10582375 | Raleigh | Mar 2020 | B2 |
| 20010048738 | Baniak et al. | Dec 2001 | A1 |
| 20010053694 | Igarashi et al. | Dec 2001 | A1 |
| 20020013844 | Garrett et al. | Jan 2002 | A1 |
| 20020022472 | Watler et al. | Feb 2002 | A1 |
| 20020022483 | Thompson et al. | Feb 2002 | A1 |
| 20020049074 | Elsinger et al. | Apr 2002 | A1 |
| 20020085516 | Bridgelall | Jul 2002 | A1 |
| 20020099848 | Lee | Jul 2002 | A1 |
| 20020116338 | Gonthier et al. | Aug 2002 | A1 |
| 20020120370 | Parupudi et al. | Aug 2002 | A1 |
| 20020120540 | Kende et al. | Aug 2002 | A1 |
| 20020131404 | Mehta et al. | Sep 2002 | A1 |
| 20020138599 | Dilman et al. | Sep 2002 | A1 |
| 20020138601 | Piponius et al. | Sep 2002 | A1 |
| 20020154751 | Thompson et al. | Oct 2002 | A1 |
| 20020161601 | Nauer et al. | Oct 2002 | A1 |
| 20020164983 | Raviv et al. | Nov 2002 | A1 |
| 20020176377 | Hamilton | Nov 2002 | A1 |
| 20020188732 | Buckman et al. | Dec 2002 | A1 |
| 20020191573 | Whitehill et al. | Dec 2002 | A1 |
| 20020199001 | Wenocur et al. | Dec 2002 | A1 |
| 20030004937 | Salmenkaita et al. | Jan 2003 | A1 |
| 20030005112 | Krautkremer | Jan 2003 | A1 |
| 20030013434 | Rosenberg et al. | Jan 2003 | A1 |
| 20030018524 | Fishman et al. | Jan 2003 | A1 |
| 20030028623 | Hennessey et al. | Feb 2003 | A1 |
| 20030046396 | Richter et al. | Mar 2003 | A1 |
| 20030050070 | Mashinsky et al. | Mar 2003 | A1 |
| 20030050837 | Kim | Mar 2003 | A1 |
| 20030084321 | Tarquini et al. | May 2003 | A1 |
| 20030088671 | Klinker et al. | May 2003 | A1 |
| 20030133408 | Cheng et al. | Jul 2003 | A1 |
| 20030134650 | Sundar et al. | Jul 2003 | A1 |
| 20030159030 | Evans | Aug 2003 | A1 |
| 20030161265 | Cao et al. | Aug 2003 | A1 |
| 20030171112 | Lupper et al. | Sep 2003 | A1 |
| 20030182420 | Jones et al. | Sep 2003 | A1 |
| 20030182435 | Redlich et al. | Sep 2003 | A1 |
| 20030184793 | Pineau | Oct 2003 | A1 |
| 20030188006 | Bard | Oct 2003 | A1 |
| 20030188117 | Yoshino et al. | Oct 2003 | A1 |
| 20030220984 | Jones et al. | Nov 2003 | A1 |
| 20030224781 | Milford et al. | Dec 2003 | A1 |
| 20030229900 | Reisman | Dec 2003 | A1 |
| 20030233332 | Keeler et al. | Dec 2003 | A1 |
| 20030236745 | Hartsell et al. | Dec 2003 | A1 |
| 20040019539 | Raman et al. | Jan 2004 | A1 |
| 20040019564 | Goldthwaite et al. | Jan 2004 | A1 |
| 20040021697 | Beaton et al. | Feb 2004 | A1 |
| 20040024756 | Rickard | Feb 2004 | A1 |
| 20040030705 | Bowman-Amuah | Feb 2004 | A1 |
| 20040039792 | Nakanishi | Feb 2004 | A1 |
| 20040044623 | Wake et al. | Mar 2004 | A1 |
| 20040047358 | Chen et al. | Mar 2004 | A1 |
| 20040054779 | Takeshima et al. | Mar 2004 | A1 |
| 20040073672 | Fascenda | Apr 2004 | A1 |
| 20040082346 | Skytt et al. | Apr 2004 | A1 |
| 20040098715 | Aghera et al. | May 2004 | A1 |
| 20040102182 | Reith et al. | May 2004 | A1 |
| 20040103193 | Pandya et al. | May 2004 | A1 |
| 20040107360 | Herrmann et al. | Jun 2004 | A1 |
| 20040114553 | Jiang et al. | Jun 2004 | A1 |
| 20040116140 | Babbar et al. | Jun 2004 | A1 |
| 20040127200 | Shaw et al. | Jul 2004 | A1 |
| 20040127208 | Nair et al. | Jul 2004 | A1 |
| 20040127256 | Goldthwaite et al. | Jul 2004 | A1 |
| 20040132427 | Lee et al. | Jul 2004 | A1 |
| 20040133668 | Nicholas, III | Jul 2004 | A1 |
| 20040137890 | Kalke | Jul 2004 | A1 |
| 20040165596 | Garcia et al. | Aug 2004 | A1 |
| 20040167958 | Stewart et al. | Aug 2004 | A1 |
| 20040168052 | Clisham et al. | Aug 2004 | A1 |
| 20040170191 | Guo et al. | Sep 2004 | A1 |
| 20040176104 | Arcens | Sep 2004 | A1 |
| 20040198331 | Coward et al. | Oct 2004 | A1 |
| 20040203755 | Brunet et al. | Oct 2004 | A1 |
| 20040203833 | Rathunde et al. | Oct 2004 | A1 |
| 20040225561 | Hertzberg et al. | Nov 2004 | A1 |
| 20040225898 | Frost et al. | Nov 2004 | A1 |
| 20040236547 | Rappaport et al. | Nov 2004 | A1 |
| 20040243680 | Mayer | Dec 2004 | A1 |
| 20040243992 | Gustafson et al. | Dec 2004 | A1 |
| 20040249918 | Sunshine | Dec 2004 | A1 |
| 20040255145 | Chow | Dec 2004 | A1 |
| 20040259534 | Chaudhari et al. | Dec 2004 | A1 |
| 20040260766 | Barros et al. | Dec 2004 | A1 |
| 20040267872 | Serdy et al. | Dec 2004 | A1 |
| 20050007993 | Chambers et al. | Jan 2005 | A1 |
| 20050009499 | Koster | Jan 2005 | A1 |
| 20050021995 | Lal et al. | Jan 2005 | A1 |
| 20050041617 | Huotari et al. | Feb 2005 | A1 |
| 20050048950 | Morper | Mar 2005 | A1 |
| 20050055291 | Bevente et al. | Mar 2005 | A1 |
| 20050055309 | Williams et al. | Mar 2005 | A1 |
| 20050055595 | Frazer et al. | Mar 2005 | A1 |
| 20050060266 | Demello et al. | Mar 2005 | A1 |
| 20050060525 | Schwartz et al. | Mar 2005 | A1 |
| 20050075115 | Corneille et al. | Apr 2005 | A1 |
| 20050079863 | Macaluso | Apr 2005 | A1 |
| 20050091505 | Riley et al. | Apr 2005 | A1 |
| 20050096024 | Bicker et al. | May 2005 | A1 |
| 20050097516 | Donnelly et al. | May 2005 | A1 |
| 20050107091 | Vannithamby et al. | May 2005 | A1 |
| 20050108075 | Douglis et al. | May 2005 | A1 |
| 20050111463 | Leung et al. | May 2005 | A1 |
| 20050128967 | Scobbie | Jun 2005 | A1 |
| 20050135264 | Popoff et al. | Jun 2005 | A1 |
| 20050163320 | Brown et al. | Jul 2005 | A1 |
| 20050166043 | Zhang et al. | Jul 2005 | A1 |
| 20050183143 | Anderholm et al. | Aug 2005 | A1 |
| 20050186948 | Gallagher et al. | Aug 2005 | A1 |
| 20050198377 | Ferguson et al. | Sep 2005 | A1 |
| 20050216421 | Barry et al. | Sep 2005 | A1 |
| 20050226178 | Forand et al. | Oct 2005 | A1 |
| 20050228985 | Ylikoski et al. | Oct 2005 | A1 |
| 20050238046 | Hassan et al. | Oct 2005 | A1 |
| 20050239447 | Holzman et al. | Oct 2005 | A1 |
| 20050245241 | Durand et al. | Nov 2005 | A1 |
| 20050246282 | Naslund et al. | Nov 2005 | A1 |
| 20050250508 | Guo et al. | Nov 2005 | A1 |
| 20050250536 | Deng et al. | Nov 2005 | A1 |
| 20050254435 | Moakley et al. | Nov 2005 | A1 |
| 20050266825 | Clayton | Dec 2005 | A1 |
| 20050266880 | Gupta | Dec 2005 | A1 |
| 20060014519 | Marsh et al. | Jan 2006 | A1 |
| 20060019632 | Cunningham et al. | Jan 2006 | A1 |
| 20060020787 | Choyi et al. | Jan 2006 | A1 |
| 20060026679 | Zakas | Feb 2006 | A1 |
| 20060030306 | Kuhn | Feb 2006 | A1 |
| 20060034256 | Addagatla et al. | Feb 2006 | A1 |
| 20060035631 | White et al. | Feb 2006 | A1 |
| 20060040642 | Boris et al. | Feb 2006 | A1 |
| 20060045245 | Aaron et al. | Mar 2006 | A1 |
| 20060048223 | Lee et al. | Mar 2006 | A1 |
| 20060068796 | Millen et al. | Mar 2006 | A1 |
| 20060072451 | Ross | Apr 2006 | A1 |
| 20060072550 | Davis et al. | Apr 2006 | A1 |
| 20060072646 | Feher | Apr 2006 | A1 |
| 20060075506 | Sanda et al. | Apr 2006 | A1 |
| 20060085543 | Hrastar et al. | Apr 2006 | A1 |
| 20060095517 | O'Connor et al. | May 2006 | A1 |
| 20060098627 | Karaoguz et al. | May 2006 | A1 |
| 20060099970 | Morgan et al. | May 2006 | A1 |
| 20060101507 | Camenisch | May 2006 | A1 |
| 20060112016 | Ishibashi | May 2006 | A1 |
| 20060114821 | Willey et al. | Jun 2006 | A1 |
| 20060114832 | Hamilton et al. | Jun 2006 | A1 |
| 20060126562 | Liu | Jun 2006 | A1 |
| 20060135144 | Jothipragasam | Jun 2006 | A1 |
| 20060136882 | Noonan et al. | Jun 2006 | A1 |
| 20060143066 | Calabria | Jun 2006 | A1 |
| 20060143098 | Lazaridis | Jun 2006 | A1 |
| 20060156398 | Ross et al. | Jul 2006 | A1 |
| 20060160536 | Chou | Jul 2006 | A1 |
| 20060165060 | Dua | Jul 2006 | A1 |
| 20060168128 | Sistla et al. | Jul 2006 | A1 |
| 20060173959 | Mckelvie et al. | Aug 2006 | A1 |
| 20060174035 | Tufail | Aug 2006 | A1 |
| 20060178917 | Merriam et al. | Aug 2006 | A1 |
| 20060178918 | Mikurak | Aug 2006 | A1 |
| 20060182137 | Zhou et al. | Aug 2006 | A1 |
| 20060183462 | Kolehmainen | Aug 2006 | A1 |
| 20060190314 | Hernandez | Aug 2006 | A1 |
| 20060190987 | Ohta et al. | Aug 2006 | A1 |
| 20060193280 | Lee et al. | Aug 2006 | A1 |
| 20060199608 | Dunn et al. | Sep 2006 | A1 |
| 20060200663 | Thornton | Sep 2006 | A1 |
| 20060206709 | Labrou et al. | Sep 2006 | A1 |
| 20060206904 | Watkins et al. | Sep 2006 | A1 |
| 20060218395 | Maes | Sep 2006 | A1 |
| 20060233108 | Krishnan | Oct 2006 | A1 |
| 20060233166 | Bou-Diab et al. | Oct 2006 | A1 |
| 20060236095 | Smith et al. | Oct 2006 | A1 |
| 20060242685 | Heard et al. | Oct 2006 | A1 |
| 20060258341 | Miller et al. | Nov 2006 | A1 |
| 20060277590 | Limont et al. | Dec 2006 | A1 |
| 20060291419 | McConnell et al. | Dec 2006 | A1 |
| 20060291477 | Croak et al. | Dec 2006 | A1 |
| 20070005795 | Gonzalez | Jan 2007 | A1 |
| 20070019670 | Falardeau | Jan 2007 | A1 |
| 20070022289 | Alt et al. | Jan 2007 | A1 |
| 20070025301 | Petersson et al. | Feb 2007 | A1 |
| 20070033194 | Srinivas et al. | Feb 2007 | A1 |
| 20070033197 | Scherzer et al. | Feb 2007 | A1 |
| 20070036312 | Cai et al. | Feb 2007 | A1 |
| 20070055694 | Ruge et al. | Mar 2007 | A1 |
| 20070060200 | Boris et al. | Mar 2007 | A1 |
| 20070061243 | Ramer et al. | Mar 2007 | A1 |
| 20070061800 | Cheng et al. | Mar 2007 | A1 |
| 20070061878 | Hagiu et al. | Mar 2007 | A1 |
| 20070073899 | Judge et al. | Mar 2007 | A1 |
| 20070076616 | Ngo et al. | Apr 2007 | A1 |
| 20070093243 | Kapadekar et al. | Apr 2007 | A1 |
| 20070100981 | Adamczyk et al. | May 2007 | A1 |
| 20070101426 | Lee et al. | May 2007 | A1 |
| 20070104126 | Calhoun et al. | May 2007 | A1 |
| 20070109983 | Shankar et al. | May 2007 | A1 |
| 20070111740 | Wandel | May 2007 | A1 |
| 20070130283 | Klein et al. | Jun 2007 | A1 |
| 20070130315 | Friend et al. | Jun 2007 | A1 |
| 20070140113 | Gemelos | Jun 2007 | A1 |
| 20070140145 | Kumar et al. | Jun 2007 | A1 |
| 20070140275 | Bowman et al. | Jun 2007 | A1 |
| 20070143824 | Shahbazi | Jun 2007 | A1 |
| 20070147317 | Smith et al. | Jun 2007 | A1 |
| 20070147324 | McGary | Jun 2007 | A1 |
| 20070155365 | Kim et al. | Jul 2007 | A1 |
| 20070165630 | Rasanen et al. | Jul 2007 | A1 |
| 20070168499 | Chu | Jul 2007 | A1 |
| 20070171856 | Bruce et al. | Jul 2007 | A1 |
| 20070174490 | Choi et al. | Jul 2007 | A1 |
| 20070191006 | Carpenter | Aug 2007 | A1 |
| 20070192460 | Choi et al. | Aug 2007 | A1 |
| 20070198656 | Mazzaferri et al. | Aug 2007 | A1 |
| 20070201502 | Abramson | Aug 2007 | A1 |
| 20070213054 | Han | Sep 2007 | A1 |
| 20070220251 | Rosenberg et al. | Sep 2007 | A1 |
| 20070226225 | Yiu et al. | Sep 2007 | A1 |
| 20070226775 | Andreasen et al. | Sep 2007 | A1 |
| 20070234402 | Khosravi et al. | Oct 2007 | A1 |
| 20070243862 | Coskun et al. | Oct 2007 | A1 |
| 20070248100 | Zuberi et al. | Oct 2007 | A1 |
| 20070254646 | Sokondar | Nov 2007 | A1 |
| 20070254675 | Zorlu Ozer et al. | Nov 2007 | A1 |
| 20070255769 | Agrawal et al. | Nov 2007 | A1 |
| 20070255797 | Dunn et al. | Nov 2007 | A1 |
| 20070255848 | Sewall et al. | Nov 2007 | A1 |
| 20070257767 | Beeson | Nov 2007 | A1 |
| 20070259656 | Jeong | Nov 2007 | A1 |
| 20070259673 | Willars et al. | Nov 2007 | A1 |
| 20070263558 | Salomone | Nov 2007 | A1 |
| 20070265003 | Kezys et al. | Nov 2007 | A1 |
| 20070266422 | Germano et al. | Nov 2007 | A1 |
| 20070274327 | Kaarela et al. | Nov 2007 | A1 |
| 20070280453 | Kelley | Dec 2007 | A1 |
| 20070282896 | Wydroug et al. | Dec 2007 | A1 |
| 20070293191 | Mir et al. | Dec 2007 | A1 |
| 20070294395 | Strub et al. | Dec 2007 | A1 |
| 20070294410 | Pandya et al. | Dec 2007 | A1 |
| 20070297378 | Poyhonen et al. | Dec 2007 | A1 |
| 20070298764 | Clayton | Dec 2007 | A1 |
| 20070299965 | Nieh et al. | Dec 2007 | A1 |
| 20070300252 | Acharya et al. | Dec 2007 | A1 |
| 20080005285 | Robinson et al. | Jan 2008 | A1 |
| 20080005561 | Brown et al. | Jan 2008 | A1 |
| 20080010379 | Zhao | Jan 2008 | A1 |
| 20080010452 | Holtzman et al. | Jan 2008 | A1 |
| 20080018494 | Waite et al. | Jan 2008 | A1 |
| 20080022354 | Grewal et al. | Jan 2008 | A1 |
| 20080025230 | Patel et al. | Jan 2008 | A1 |
| 20080032715 | Jia et al. | Feb 2008 | A1 |
| 20080034063 | Yee | Feb 2008 | A1 |
| 20080034419 | Mullick et al. | Feb 2008 | A1 |
| 20080039102 | Sewall et al. | Feb 2008 | A1 |
| 20080049630 | Kozisek et al. | Feb 2008 | A1 |
| 20080050715 | Golczewski et al. | Feb 2008 | A1 |
| 20080051076 | O'Shaughnessy et al. | Feb 2008 | A1 |
| 20080052387 | Heinz et al. | Feb 2008 | A1 |
| 20080056273 | Pelletier et al. | Mar 2008 | A1 |
| 20080059474 | Lim | Mar 2008 | A1 |
| 20080059743 | Bychkov et al. | Mar 2008 | A1 |
| 20080060066 | Wynn et al. | Mar 2008 | A1 |
| 20080062900 | Rao | Mar 2008 | A1 |
| 20080064367 | Nath et al. | Mar 2008 | A1 |
| 20080066149 | Lim | Mar 2008 | A1 |
| 20080066150 | Lim | Mar 2008 | A1 |
| 20080066181 | Haveson et al. | Mar 2008 | A1 |
| 20080070550 | Hose | Mar 2008 | A1 |
| 20080077705 | Li et al. | Mar 2008 | A1 |
| 20080080457 | Cole | Apr 2008 | A1 |
| 20080081606 | Cole | Apr 2008 | A1 |
| 20080082643 | Storrie et al. | Apr 2008 | A1 |
| 20080083013 | Soliman et al. | Apr 2008 | A1 |
| 20080085707 | Fadell | Apr 2008 | A1 |
| 20080089295 | Keeler et al. | Apr 2008 | A1 |
| 20080089303 | Wirtanen et al. | Apr 2008 | A1 |
| 20080095339 | Elliott et al. | Apr 2008 | A1 |
| 20080096559 | Phillips et al. | Apr 2008 | A1 |
| 20080098062 | Balia | Apr 2008 | A1 |
| 20080101291 | Jiang et al. | May 2008 | A1 |
| 20080109679 | Wright et al. | May 2008 | A1 |
| 20080120129 | Seubert et al. | May 2008 | A1 |
| 20080120174 | Li | May 2008 | A1 |
| 20080120668 | Yau | May 2008 | A1 |
| 20080120688 | Qiu et al. | May 2008 | A1 |
| 20080125079 | O'Neil et al. | May 2008 | A1 |
| 20080126287 | Cox et al. | May 2008 | A1 |
| 20080127304 | Ginter et al. | May 2008 | A1 |
| 20080130534 | Tomioka | Jun 2008 | A1 |
| 20080130656 | Kim et al. | Jun 2008 | A1 |
| 20080132201 | Karlberg | Jun 2008 | A1 |
| 20080132268 | Choi-Grogan et al. | Jun 2008 | A1 |
| 20080134330 | Kapoor et al. | Jun 2008 | A1 |
| 20080139210 | Gisby et al. | Jun 2008 | A1 |
| 20080147454 | Walker et al. | Jun 2008 | A1 |
| 20080160958 | Abichandani et al. | Jul 2008 | A1 |
| 20080162637 | Adamczyk et al. | Jul 2008 | A1 |
| 20080162704 | Poplett et al. | Jul 2008 | A1 |
| 20080164304 | Narasimhan et al. | Jul 2008 | A1 |
| 20080166993 | Gautier et al. | Jul 2008 | A1 |
| 20080167027 | Gautier et al. | Jul 2008 | A1 |
| 20080167033 | Beckers | Jul 2008 | A1 |
| 20080168275 | DeAtley et al. | Jul 2008 | A1 |
| 20080168523 | Ansari et al. | Jul 2008 | A1 |
| 20080177998 | Apsangi et al. | Jul 2008 | A1 |
| 20080178300 | Brown et al. | Jul 2008 | A1 |
| 20080183812 | Paul et al. | Jul 2008 | A1 |
| 20080184127 | Rafey et al. | Jul 2008 | A1 |
| 20080189760 | Rosenberg et al. | Aug 2008 | A1 |
| 20080201266 | Chua et al. | Aug 2008 | A1 |
| 20080207167 | Bugenhagen | Aug 2008 | A1 |
| 20080212470 | Castaneda et al. | Sep 2008 | A1 |
| 20080212751 | Chung | Sep 2008 | A1 |
| 20080219268 | Dennison | Sep 2008 | A1 |
| 20080221951 | Stanforth et al. | Sep 2008 | A1 |
| 20080222692 | Andersson et al. | Sep 2008 | A1 |
| 20080225748 | Khemani et al. | Sep 2008 | A1 |
| 20080229385 | Feder et al. | Sep 2008 | A1 |
| 20080229388 | Maes | Sep 2008 | A1 |
| 20080235511 | O'Brien et al. | Sep 2008 | A1 |
| 20080240373 | Wilhelm | Oct 2008 | A1 |
| 20080250053 | Aaltonen et al. | Oct 2008 | A1 |
| 20080256593 | Mnberg et al. | Oct 2008 | A1 |
| 20080259924 | Gooch et al. | Oct 2008 | A1 |
| 20080262798 | Kim et al. | Oct 2008 | A1 |
| 20080263348 | Zaltsman et al. | Oct 2008 | A1 |
| 20080268813 | Maes | Oct 2008 | A1 |
| 20080270212 | Blight et al. | Oct 2008 | A1 |
| 20080279216 | Sharif-Ahmadi et al. | Nov 2008 | A1 |
| 20080282319 | Fontijn et al. | Nov 2008 | A1 |
| 20080293395 | Mathews et al. | Nov 2008 | A1 |
| 20080298230 | Luft et al. | Dec 2008 | A1 |
| 20080305793 | Gallagher et al. | Dec 2008 | A1 |
| 20080311885 | Dawson et al. | Dec 2008 | A1 |
| 20080313315 | Karaoguz et al. | Dec 2008 | A1 |
| 20080313730 | Iftimie et al. | Dec 2008 | A1 |
| 20080316923 | Fedders et al. | Dec 2008 | A1 |
| 20080318547 | Ballou et al. | Dec 2008 | A1 |
| 20080318550 | DeAtley | Dec 2008 | A1 |
| 20080319879 | Carroll et al. | Dec 2008 | A1 |
| 20080320497 | Tarkoma et al. | Dec 2008 | A1 |
| 20090005000 | Baker et al. | Jan 2009 | A1 |
| 20090005005 | Forstall et al. | Jan 2009 | A1 |
| 20090006116 | Baker et al. | Jan 2009 | A1 |
| 20090006200 | Baker et al. | Jan 2009 | A1 |
| 20090006229 | Sweeney et al. | Jan 2009 | A1 |
| 20090013157 | Beaule | Jan 2009 | A1 |
| 20090016310 | Rasal | Jan 2009 | A1 |
| 20090036111 | Danford et al. | Feb 2009 | A1 |
| 20090042536 | Bernard et al. | Feb 2009 | A1 |
| 20090044185 | Krivopaltsev | Feb 2009 | A1 |
| 20090046707 | Smires et al. | Feb 2009 | A1 |
| 20090046723 | Rahman et al. | Feb 2009 | A1 |
| 20090047989 | Harmon et al. | Feb 2009 | A1 |
| 20090048913 | Shenfield et al. | Feb 2009 | A1 |
| 20090049156 | Aronsson et al. | Feb 2009 | A1 |
| 20090049518 | Roman et al. | Feb 2009 | A1 |
| 20090054030 | Golds | Feb 2009 | A1 |
| 20090065571 | Jain | Mar 2009 | A1 |
| 20090067372 | Shah et al. | Mar 2009 | A1 |
| 20090068984 | Burnett | Mar 2009 | A1 |
| 20090070379 | Rappaport | Mar 2009 | A1 |
| 20090077622 | Baum et al. | Mar 2009 | A1 |
| 20090079699 | Sun | Mar 2009 | A1 |
| 20090113514 | Hu | Apr 2009 | A1 |
| 20090125619 | Antani | May 2009 | A1 |
| 20090132860 | Liu et al. | May 2009 | A1 |
| 20090149154 | Bhasin et al. | Jun 2009 | A1 |
| 20090157792 | Fiatal | Jun 2009 | A1 |
| 20090163173 | Williams | Jun 2009 | A1 |
| 20090170554 | Want et al. | Jul 2009 | A1 |
| 20090172077 | Roxburgh et al. | Jul 2009 | A1 |
| 20090180391 | Petersen et al. | Jul 2009 | A1 |
| 20090181662 | Fleischman et al. | Jul 2009 | A1 |
| 20090197585 | Aaron | Aug 2009 | A1 |
| 20090197612 | Kliskinen | Aug 2009 | A1 |
| 20090203352 | Fordon et al. | Aug 2009 | A1 |
| 20090217065 | Araujo, Jr. | Aug 2009 | A1 |
| 20090217364 | Salmela et al. | Aug 2009 | A1 |
| 20090219170 | Clark et al. | Sep 2009 | A1 |
| 20090248883 | Suryanarayana et al. | Oct 2009 | A1 |
| 20090254857 | Romine et al. | Oct 2009 | A1 |
| 20090257379 | Robinson et al. | Oct 2009 | A1 |
| 20090271514 | Thomas et al. | Oct 2009 | A1 |
| 20090282127 | Leblanc et al. | Nov 2009 | A1 |
| 20090286507 | O'Neil et al. | Nov 2009 | A1 |
| 20090287921 | Zhu et al. | Nov 2009 | A1 |
| 20090288140 | Huber et al. | Nov 2009 | A1 |
| 20090291665 | Gaskarth et al. | Nov 2009 | A1 |
| 20090299857 | Brubaker | Dec 2009 | A1 |
| 20090307696 | Vals et al. | Dec 2009 | A1 |
| 20090307746 | Di et al. | Dec 2009 | A1 |
| 20090315735 | Bhavani et al. | Dec 2009 | A1 |
| 20090320110 | Nicolson et al. | Dec 2009 | A1 |
| 20100017506 | Fadell | Jan 2010 | A1 |
| 20100020822 | Zerillo et al. | Jan 2010 | A1 |
| 20100027469 | Gurajala et al. | Feb 2010 | A1 |
| 20100027525 | Zhu | Feb 2010 | A1 |
| 20100027559 | Lin et al. | Feb 2010 | A1 |
| 20100030890 | Dutta et al. | Feb 2010 | A1 |
| 20100041364 | Lott et al. | Feb 2010 | A1 |
| 20100041365 | Lott et al. | Feb 2010 | A1 |
| 20100042675 | Fujii | Feb 2010 | A1 |
| 20100043068 | Varadhan et al. | Feb 2010 | A1 |
| 20100069074 | Kodlalam et al. | Mar 2010 | A1 |
| 20100071053 | Ansari et al. | Mar 2010 | A1 |
| 20100075666 | Garner | Mar 2010 | A1 |
| 20100077035 | Li et al. | Mar 2010 | A1 |
| 20100080202 | Hanson | Apr 2010 | A1 |
| 20100082431 | Ramer et al. | Apr 2010 | A1 |
| 20100088387 | Calamera | Apr 2010 | A1 |
| 20100103820 | Fuller et al. | Apr 2010 | A1 |
| 20100113020 | Subramanian et al. | May 2010 | A1 |
| 20100121744 | Belz et al. | May 2010 | A1 |
| 20100131584 | Johnson | May 2010 | A1 |
| 20100142478 | Forssell et al. | Jun 2010 | A1 |
| 20100144310 | Bedingfield | Jun 2010 | A1 |
| 20100151866 | Karpov et al. | Jun 2010 | A1 |
| 20100153781 | Hanna | Jun 2010 | A1 |
| 20100167696 | Smith et al. | Jul 2010 | A1 |
| 20100188975 | Raleigh | Jul 2010 | A1 |
| 20100188990 | Raleigh | Jul 2010 | A1 |
| 20100188992 | Raleigh | Jul 2010 | A1 |
| 20100188994 | Raleigh | Jul 2010 | A1 |
| 20100190469 | Vanderveen et al. | Jul 2010 | A1 |
| 20100191576 | Raleigh | Jul 2010 | A1 |
| 20100191612 | Raleigh | Jul 2010 | A1 |
| 20100191846 | Raleigh | Jul 2010 | A1 |
| 20100192170 | Raleigh | Jul 2010 | A1 |
| 20100192212 | Raleigh | Jul 2010 | A1 |
| 20100195503 | Raleigh | Aug 2010 | A1 |
| 20100197268 | Raleigh | Aug 2010 | A1 |
| 20100198698 | Raleigh et al. | Aug 2010 | A1 |
| 20100198939 | Raleigh | Aug 2010 | A1 |
| 20100227632 | Bell et al. | Sep 2010 | A1 |
| 20100235329 | Koren et al. | Sep 2010 | A1 |
| 20100241544 | Benson et al. | Sep 2010 | A1 |
| 20100248719 | Scholaert | Sep 2010 | A1 |
| 20100284327 | Miklos | Nov 2010 | A1 |
| 20100284388 | Fantini et al. | Nov 2010 | A1 |
| 20100287599 | He et al. | Nov 2010 | A1 |
| 20100311402 | Srinivasan et al. | Dec 2010 | A1 |
| 20100318652 | Samba | Dec 2010 | A1 |
| 20100325420 | Kanekar | Dec 2010 | A1 |
| 20110004917 | Saisa et al. | Jan 2011 | A1 |
| 20110013569 | Scherzer et al. | Jan 2011 | A1 |
| 20110019574 | Malomsoky et al. | Jan 2011 | A1 |
| 20110081881 | Baker et al. | Apr 2011 | A1 |
| 20110082790 | Baker et al. | Apr 2011 | A1 |
| 20110110309 | Bennett | May 2011 | A1 |
| 20110126141 | King et al. | May 2011 | A1 |
| 20110145920 | Mahaffey et al. | Jun 2011 | A1 |
| 20110159818 | Scherzer et al. | Jun 2011 | A1 |
| 20110173678 | Kaippallimalil et al. | Jul 2011 | A1 |
| 20110177811 | Heckman et al. | Jul 2011 | A1 |
| 20110182220 | Black et al. | Jul 2011 | A1 |
| 20110185202 | Black et al. | Jul 2011 | A1 |
| 20110195700 | Kukuchka et al. | Aug 2011 | A1 |
| 20110238545 | Fanaian et al. | Sep 2011 | A1 |
| 20110241624 | Park et al. | Oct 2011 | A1 |
| 20110244837 | Murata et al. | Oct 2011 | A1 |
| 20110249668 | Milligan et al. | Oct 2011 | A1 |
| 20110252430 | Chapman et al. | Oct 2011 | A1 |
| 20110264923 | Kocher et al. | Oct 2011 | A1 |
| 20110277019 | Pritchard, Jr. | Nov 2011 | A1 |
| 20110294502 | Oerton | Dec 2011 | A1 |
| 20120011017 | Wolcott et al. | Jan 2012 | A1 |
| 20120020296 | Scherzer et al. | Jan 2012 | A1 |
| 20120029718 | Davis | Feb 2012 | A1 |
| 20120101952 | Raleigh et al. | Apr 2012 | A1 |
| 20120108225 | Luna et al. | May 2012 | A1 |
| 20120144025 | Melander et al. | Jun 2012 | A1 |
| 20120155296 | Kashanian | Jun 2012 | A1 |
| 20120166364 | Ahmad et al. | Jun 2012 | A1 |
| 20120166604 | Fortier et al. | Jun 2012 | A1 |
| 20120196644 | Scherzer et al. | Aug 2012 | A1 |
| 20120238287 | Scherzer | Sep 2012 | A1 |
| 20120330792 | Kashanian | Dec 2012 | A1 |
| 20130024914 | Ahmed et al. | Jan 2013 | A1 |
| 20130029653 | Baker et al. | Jan 2013 | A1 |
| 20130030960 | Kashanian | Jan 2013 | A1 |
| 20130058274 | Scherzer et al. | Mar 2013 | A1 |
| 20130065555 | Baker et al. | Mar 2013 | A1 |
| 20130072177 | Ross et al. | Mar 2013 | A1 |
| 20130084835 | Scherzer et al. | Apr 2013 | A1 |
| 20130095787 | Kashanian | Apr 2013 | A1 |
| 20130103376 | Gaddam et al. | Apr 2013 | A1 |
| 20130111572 | Gaddam et al. | May 2013 | A1 |
| 20130117140 | Kashanian | May 2013 | A1 |
| 20130117382 | Gaddam et al. | May 2013 | A1 |
| 20130144789 | Aaltonen et al. | Jun 2013 | A1 |
| 20130149994 | Gaddam et al. | Jun 2013 | A1 |
| 20130183937 | Neal et al. | Jul 2013 | A1 |
| 20130225151 | King et al. | Aug 2013 | A1 |
| 20130275583 | Roach et al. | Oct 2013 | A1 |
| 20130326356 | Zheng et al. | Dec 2013 | A9 |
| 20140066101 | Lyman et al. | Mar 2014 | A1 |
| 20140073291 | Hildner et al. | Mar 2014 | A1 |
| 20140080458 | Bonner | Mar 2014 | A1 |
| 20140241342 | Constantinof | Aug 2014 | A1 |
| 20150181628 | Haverinen et al. | Jun 2015 | A1 |
| Number | Date | Country |
|---|---|---|
| 2688553 | Dec 2008 | CA |
| 1310401 | Aug 2001 | CN |
| 1345154 | Apr 2002 | CN |
| 1508734 | Jun 2004 | CN |
| 1538730 | Oct 2004 | CN |
| 1567818 | Jan 2005 | CN |
| 101035308 | Mar 2006 | CN |
| 1801829 | Jul 2006 | CN |
| 1802839 | Jul 2006 | CN |
| 1889777 | Jul 2006 | CN |
| 101155343 | Sep 2006 | CN |
| 1867024 | Nov 2006 | CN |
| 1878160 | Dec 2006 | CN |
| 1937511 | Mar 2007 | CN |
| 101123553 | Sep 2007 | CN |
| 101080055 | Nov 2007 | CN |
| 101115248 | Jan 2008 | CN |
| 101127988 | Feb 2008 | CN |
| 101183958 | May 2008 | CN |
| 101335666 | Dec 2008 | CN |
| 101341764 | Jan 2009 | CN |
| 101815275 | Aug 2010 | CN |
| 1098490 | May 2001 | EP |
| 1289326 | Mar 2003 | EP |
| 1463238 | Sep 2004 | EP |
| 1503548 | Feb 2005 | EP |
| 1545114 | Jun 2005 | EP |
| 1739518 | Jan 2007 | EP |
| 1772988 | Apr 2007 | EP |
| 1850575 | Oct 2007 | EP |
| 1887732 | Feb 2008 | EP |
| 1942698 | Jul 2008 | EP |
| 1978772 | Oct 2008 | EP |
| 2007065 | Dec 2008 | EP |
| 2026514 | Feb 2009 | EP |
| 2466831 | Jun 2012 | EP |
| 3148713 | Mar 2001 | JP |
| 2005339247 | Dec 2005 | JP |
| 2006041989 | Feb 2006 | JP |
| 2006155263 | Jun 2006 | JP |
| 2006197137 | Jul 2006 | JP |
| 2006344007 | Dec 2006 | JP |
| 2007318354 | Dec 2007 | JP |
| 2008301121 | Dec 2008 | JP |
| 2009111919 | May 2009 | JP |
| 2009212707 | Sep 2009 | JP |
| 2009218773 | Sep 2009 | JP |
| 2009232107 | Oct 2009 | JP |
| 20040053858 | Jun 2004 | KR |
| 1998058505 | Dec 1998 | WO |
| 1999027723 | Jun 1999 | WO |
| 1999065185 | May 2001 | WO |
| 0208863 | Jan 2002 | WO |
| 2002045315 | Jun 2002 | WO |
| 2002067616 | Aug 2002 | WO |
| 2002093877 | Nov 2002 | WO |
| 2003014891 | Feb 2003 | WO |
| 2003017063 | Feb 2003 | WO |
| 2003017065 | Feb 2003 | WO |
| 2003058880 | Jul 2003 | WO |
| 2004028070 | Apr 2004 | WO |
| 2004064306 | Jul 2004 | WO |
| 2004095753 | Jan 2005 | WO |
| 2005008995 | Jan 2005 | WO |
| 2005053335 | Jun 2005 | WO |
| 2005083934 | Sep 2005 | WO |
| 2006004467 | Jan 2006 | WO |
| 2006004784 | Jan 2006 | WO |
| 2006012610 | Feb 2006 | WO |
| 2006050758 | May 2006 | WO |
| 2006077481 | Jul 2006 | WO |
| 2006093961 | Sep 2006 | WO |
| 2006120558 | Nov 2006 | WO |
| 2006130960 | Dec 2006 | WO |
| 2007001833 | Jan 2007 | WO |
| 2007014630 | Feb 2007 | WO |
| 2007018363 | Feb 2007 | WO |
| 2007053848 | May 2007 | WO |
| 2007068288 | Jun 2007 | WO |
| 2007097786 | Aug 2007 | WO |
| 2007107701 | Sep 2007 | WO |
| 2007120310 | Oct 2007 | WO |
| 2007124279 | Nov 2007 | WO |
| 2007126352 | Nov 2007 | WO |
| 2007129180 | Nov 2007 | WO |
| 2007133844 | Nov 2007 | WO |
| 2004077797 | Feb 2008 | WO |
| 2008017837 | Feb 2008 | WO |
| 2008051379 | May 2008 | WO |
| 2008066419 | Jun 2008 | WO |
| 2008080139 | Jul 2008 | WO |
| 2008080430 | Jul 2008 | WO |
| 2008099802 | Aug 2008 | WO |
| 2009008817 | Jan 2009 | WO |
| 2006073837 | Apr 2009 | WO |
| 2007069245 | Apr 2009 | WO |
| 2009091295 | Jul 2009 | WO |
| 2010088413 | Aug 2010 | WO |
| 2010128391 | Nov 2010 | WO |
| 2010128391 | Jan 2011 | WO |
| 2011002450 | Jan 2011 | WO |
| 2011149532 | Dec 2011 | WO |
| 2012047275 | Apr 2012 | WO |
| Entry |
|---|
| “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architecture (Release 11),” 3GPP Standard; 3GPP TS 23.203 v11.6.0; Sophia Antipolis, France; pp. 1-177; Jun. 2012. |
| “Ads and movies on the run,” the Gold Coast Bulletin, Southport, Qld, Jan. 29, 2008. |
| “ASA/PIX: Allow Split Tunneling for VPN Clients on the ASA Configuration Example,” Document ID 70917, Jan. 10, 2008. |
| “Communication Concepts for Mobile Agent Systems,” by Joachim Baumann et al.; Inst. of Parallel and Distributed High-Performance Systems, Univ. of Stuttgart, Germany, pp. 123-135, 1997. |
| “End to End QoS Solution for Real-time Multimedia Application;” Computer Engineering and Applications, 2007, 43 (4):155-159, by Tan Zu-guo, Wang Wen-juan; Information and Science School, Zhanjian Normal College, Zhan jiang, Guangdong 524048, China. |
| “Jentro Technologies launches Zenlet platform to accelerate location-based content delivery to mobile devices,” The Mobile Internet, Boston, MA, Feb. 2008. |
| “Prevent iCloud Documents & Data from using your data plan,” Oct. 26, 2011; CNET webarchive, by Jason Cipriani. |
| “The Construction of Intelligent Residential District in Use of Cable Television Network,” Shandong Science, vol. 13, No. 2, Jun. 2000. |
| 3rd Generation Partnership Project, “Technical Specification Group Core Network and Terminals; Access Network Discovery and Selection Function (ANDSF) Management Object (MO),” Release 9, Document No. 3GPP TS 24.312, V9.1.0, Mar. 2010. |
| 3rd Generation Partnership Project, “Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) Enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Access,” Release 8, Document No. 3GPP TS 23.401, V8.4.0, Dec. 2008. |
| 3rd Generation Partnership Project, “Technical Specification Group Services and System Aspects; Policy and Charging Control Architecture,” Release 8, Document No. 3GPP TS 23.203, V8.4.0, Dec. 2008. |
| 3rd Generation Partnership Project; “Technical Specification Group Services and System Aspects; IP Flow Mobility and seamless WLAN offlload; Stage 2,” Release 10, Document No. 3GPP TS 23.261, V1.0.0, Mar. 2010. |
| Accuris Networks, “The Business Value of Mobile Data Offload—a White Paper”, 2010. |
| Ahmed et al., “A Context-Aware Vertical Handover Decision Algorithm for Multimode Mobile Terminals and Its Performance,” BenQ Mobile, Munich Germany; University of Klagenfurt, Klagenfurt, Austria; 2006. |
| Ahmed et al., “Multi Access Data Network Connectivity and IP Flow Mobility in Evolved Packet System (EPS),” 2010 IEEE. |
| Alonistioti et al., “Intelligent Architectures Enabling Flexible Service Provision and Adaptability,” 2002. |
| Amazon Technologies, Inc., “Kindle™ User's Guide,” 3rd Edition, Copyright 2004-2009. |
| Android Cupcake excerpts, The Android Open Source Project, Feb. 10, 2009. |
| Anton, B. et al., “Best Current Practices for Wireless Internet Service Provider (WISP) Roaming”; Release Date Feb. 2003, Version 1.0; Wi-Fi Alliance—Wireless ISP Roaming (WISPr). |
| Blackberry Mobile Data System, version 4.1, Technical Overview, 2006. |
| Byrd, “Open Secure Wireless,” May 5, 2010. |
| Chandrasekhar et al., “Femtocell Networks: A Survey,” Jun. 28, 2008. |
| Chaouchi et al., “Policy Based Networking in the Integration Effort of 4G Networks and Services,” 2004 IEEE. |
| Cisco Systems, Inc., “Cisco Mobile Exchange (CMX) Solution Guide: Chapter 2—Overview of GSM, GPRS, and UMTS,” Nov. 4, 2008. |
| Client Guide for Symantec Endpoint Protection and Symantec Network Access Control, 2007. |
| Dikaiakos et al., “A Distributed Middleware Infrastructure for Personalized Services,” Nov. 24, 2003. |
| Dixon et al., Triple Play Digital Services: Comcast and Verizon (Digital Phone, Television, and Internet), Aug. 2007. |
| Droid Wall 1.3.7 description Apr. 28, 2010 obtained from https://www.freewarelovers.com/android/apps/droid-wall. |
| Ehnert, “Small application to monitor IP trafic on a Blackberry—1.01.03 ”, Mar. 27, 2008; http://www.ehnert.net/MiniMoni/. |
| European Commission, “Data Roaming Tariffs—Transparency Measures,” obtained from EUROPA—Europe's Information Society Thematic Portal website, Jun. 24, 2011: “http://ec.europa.eu/information_society/activities/roaming/data/measures/index_en.htm.”. |
| Farooq et al., “An IEEE 802.16 WiMax Module for the NS-3 Simulator,” Mar. 2-6, 2009. |
| Fujitsu, “Server Push Technology Survey and Bidirectional Communication in HTTP Browser,” Jan. 9, 2008 (JP). |
| Han et al., “Information Collection Services for Qos-Aware Mobile Applications,” 2005. |
| Hartmann et al., “Agent-Based Banking Transactions & Information Retrieval—What About Performance Issues?” 1999. |
| Hewlett-Packard Development Company, LP, “IP Multimedia Services Charging,” white paper, Jan. 2006. |
| Hossain et al., “Gain-Based Selection of Ambient Media Services in Pervasive Environments,” Mobile Networks and Applications. Oct. 3, 2008. |
| Jing et al., “Client-Server Computing in Mobile Environments,” GTE Labs. Inc., Purdue University, ACM Computing Surveys, vol. 31, No. 2, Jun. 1999. |
| Kasper et al., “Subscriber Authentication in mobile cellular Networks with virtual software SIM Credentials using Trusted Computing,” Fraunhofer-Institute for Secure Information Technology SIT, Darmstadt, Germany; ICACT 2008. |
| Kassar et al., “An overview of vertical handover decision strategies in heterogeneous wireless networks,” ScienceDirect, University Pierre & Marie Curie, Paris, France, Jun. 5, 2007. |
| Kim, “Free wireless a high-wire act; MetroFi needs to draw enough ads to make service add profits,” San Francisco Chronicle, Aug. 21, 2006. |
| Knight et al., “Layer 2 and 3 Virtual Private Networks: Taxonomy, Technology, and Standarization Efforts,” IEEE Communications Magazine, Jun. 2004. |
| Koutsopoulou et al., “Charging, Accounting and Billing Management Schemes in Mobile Telecommunication Networks and the Internet,” IEEE Communications Surveys & Tutorials, First Quarter 2004, vol. 6, No. 1. |
| Koutsopoulou et al., “Middleware Platform for the Support of Charging Reconfiguration Actions,” 2005. |
| Kuntze et al., “Trustworthy content push,” Fraunhofer-Institute for Secure Information Technology SIT; Germany; WCNC 2007 proceedings, IEEE. |
| Kyriakakos et al., “Ubiquitous Service Provision in Next Generation Mobile Networks,” Proceedings of the 13th IST Mobile and Wireless Communications Summit, Lyon, France, Jun. 2004. |
| Li, Yu, “Dedicated E-Reading Device: The State of the Art and The Challenges,” Scroll, vol. 1, No. 1, 2008. |
| Loopt User Guide, metroPCS, Jul. 17, 2008. |
| Muntermann et al., “Potentiale und Sicherheitsanforderungen mobiler Finanzinformationsdienste und deren Systeminfrastrukturen,” Chair of Mobile Commerce & Multilateral Security, Goethe Univ. Frankfurt, 2004. |
| NetLimiter Lite 4.0.19.0; http://www.heise.de/download/netlimiter-lite-3617703.html from vol. 14/2007. |
| Nilsson et al., “A Novel MAC Scheme for Solving the QoS Parameter Adjustment Problem in IEEE802.11e EDCA,” Feb. 2006. |
| Nuzman et al., “A compund model for TCP connection arrivals for LAN and WAN applications,” Oct. 22, 2002. |
| Open Mobile Alliance (OMA), Push Architecture, Candidate Version 2.2; Oct. 2, 2007; OMA-AD-Push-V2 2-20071002-C. |
| Oppliger, Rolf, “Internet Security: Firewalls and Bey,” Communications of the ACM, May 1997, vol. 40. No. 5. |
| Quintana, David, “Mobile Multitasking,” Apr. 14, 2010. |
| Rao et al., “Evolution of Mobile Location-Based Services,” Communication of the ACM, Dec. 2003. |
| Richtel, “Cellphone consumerism; If even a debit card is too slow, now you have a new way to act on impulse: [National Edition],” National Post, Canada, Oct. 2, 2007. |
| Rivadeneyra et al., “A communication architecture to access data services through GSM,” San Sebastian, Spain, 1998. |
| Roy et al., “Energy Management in Mobile Devices with the Cinder Operating System”, Stanford University, MIT CSAIL, Jun. 3, 2010. |
| Ruckus Wireless—White Paper; “Smarter Wi-Fi for Mobile Operator Infrastructures” 2010. |
| Sabat, “The evolving mobile wireless value chain and market structure,” Nov. 2002. |
| Sadeh et al., “Understanding and Capturing People's Privacy Policies in a Mobile Social Networking Application,” ISR School of Computer Science, Carnegie Mellon University, 2007. |
| Schiller et al., “Location-Based Services,” The Morgan Kaufmann Series in Data Management Systems, 2004. |
| Sharkey, “Coding for Life-Battery Life, That Is,” May 27, 2009. |
| Steglich, Stephan, “I-Centric User Interaction,” Nov. 21, 2003. |
| Sun et al., “Towards Connectivity Management Adaptability: Context Awareness in Policy Representation and End-to-end Evaluation Algorithm,” Dept. of Electrical and Information Engineering, Univ. of Oulu, Finland, 2004. |
| Thurston, Richard, “WISPr 2.0 Boosts Roaming Between 3G and Wi-Fi”; Jun. 23, 2010; Web page from zdnet.com; Zdnet.com/wispr-2-0-boosts-roaming-between-3g-and-wi-fi-3040089325/. |
| Van Eijk, et al., “GigaMobile, Agent Technology for Designing Personalized Mobile Service Brokerage,” Jul. 1, 2002. |
| VerizonWireless.com news, “Verizon Wireless Adds to Portfolio of Cosumer-Friendly Tools With Introduction of Usage Controls, Usage Controls and Chaperone 2.0 Offer Parents Full Family Security Solution,” Aug. 18, 2008. |
| Wi-Fi Alliance Hotspot 2.0 Technical Task Group, “Wi-Fi Certified Passpoint™ (Release 1) Deployment Guidelines—Version 1.0 ˜ Oct. 2012”. |
| Wi-Fi Alliance Technical Committee Hotspot 2.0 Technical Task Group, “Hotspot 2.0 (Release 1) Technical Specification—Version 1.0.0”; 2012. |
| Windows7 Power Management, published Apr. 2009. |
| Wireless Broadband Alliance, “WISPr 2.0, Apr. 8, 2010”; Doc. Ref. No.: WBA/RM/WISPr, Version 01.00. |
| Zhu et al., “A Survey of Quality of Service in IEEE 802.11 Networks,” IEEE Wireless Communications, Aug. 2004. |
| Number | Date | Country | |
|---|---|---|---|
| 20220360608 A1 | Nov 2022 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61389547 | Oct 2010 | US | |
| 61387243 | Sep 2010 | US | |
| 61387247 | Sep 2010 | US | |
| 61407358 | Oct 2010 | US | |
| 61418507 | Dec 2010 | US | |
| 61418509 | Dec 2010 | US | |
| 61420727 | Dec 2010 | US | |
| 61422565 | Dec 2010 | US | |
| 61422572 | Dec 2010 | US | |
| 61422574 | Dec 2010 | US | |
| 61435564 | Jan 2011 | US | |
| 61472606 | Apr 2011 | US | |
| 61206354 | Jan 2009 | US | |
| 61206944 | Feb 2009 | US | |
| 61207393 | Feb 2009 | US | |
| 61207739 | Feb 2009 | US | |
| 61270353 | Jul 2009 | US | |
| 61264126 | Nov 2009 | US | |
| 61275208 | Aug 2009 | US | |
| 61237753 | Aug 2009 | US | |
| 61252151 | Oct 2009 | US | |
| 61252153 | Oct 2009 | US | |
| 61264120 | Nov 2009 | US | |
| 61348022 | May 2010 | US | |
| 61381162 | Sep 2010 | US | |
| 61384456 | Sep 2010 | US | |
| 61385020 | Sep 2010 | US | |
| 61381159 | Sep 2010 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17121717 | Dec 2020 | US |
| Child | 17869696 | US | |
| Parent | 16214902 | Dec 2018 | US |
| Child | 17121717 | US | |
| Parent | 14948082 | Nov 2015 | US |
| Child | 16214902 | US | |
| Parent | 13842172 | Mar 2013 | US |
| Child | 14948082 | US | |
| Parent | 12695980 | Jan 2010 | US |
| Child | 12695021 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13248025 | Sep 2011 | US |
| Child | 13842172 | US | |
| Parent | 13253013 | Oct 2011 | US |
| Child | 13248025 | US | |
| Parent | 12380778 | Mar 2009 | US |
| Child | 13248025 | US | |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12380778 | US | |
| Parent | 12695019 | Jan 2010 | US |
| Child | 12380780 | US | |
| Parent | 12695020 | Jan 2010 | US |
| Child | 12695019 | US | |
| Parent | 12694445 | Jan 2010 | US |
| Child | 12695020 | US | |
| Parent | 12694451 | Jan 2010 | US |
| Child | 12694445 | US | |
| Parent | 12694455 | Jan 2010 | US |
| Child | 12694451 | US | |
| Parent | 12695021 | Jan 2010 | US |
| Child | 12694455 | US | |
| Parent | 12695980 | Jan 2010 | US |
| Child | 12695021 | US | |
| Parent | 13134028 | May 2011 | US |
| Child | 12695980 | US | |
| Parent | 13229580 | Sep 2011 | US |
| Child | 13134028 | US | |
| Parent | 13237827 | Sep 2011 | US |
| Child | 13229580 | US | |
| Parent | 13239321 | Sep 2011 | US |
| Child | 13237827 | US | |
| Parent | 13248028 | Sep 2011 | US |
| Child | 13239321 | US | |
| Parent | 13247998 | Sep 2011 | US |
| Child | 13248028 | US | |
| Parent | 13134005 | May 2011 | US |
| Child | 13247998 | US | |
| Parent | 12380778 | Mar 2009 | US |
| Child | 13253013 | Oct 2011 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12380778 | US | |
| Parent | 12695019 | Jan 2010 | US |
| Child | 12380780 | US | |
| Parent | 12695020 | Jan 2010 | US |
| Child | 12695019 | US | |
| Parent | 12694445 | Jan 2010 | US |
| Child | 12695020 | US | |
| Parent | 12694451 | Jan 2010 | US |
| Child | 12694445 | US | |
| Parent | 12694455 | Jan 2010 | US |
| Child | 12694451 | US | |
| Parent | 12695021 | Jan 2010 | US |
| Child | 12694455 | US | |
| Parent | 12695980 | Jan 2010 | US |
| Child | 12695021 | US | |
| Parent | 13134028 | May 2011 | US |
| Child | 12695980 | US | |
| Parent | 13229580 | Sep 2011 | US |
| Child | 13134028 | US | |
| Parent | 13237827 | Sep 2011 | US |
| Child | 13229580 | US | |
| Parent | 13239321 | Sep 2011 | US |
| Child | 13237827 | US | |
| Parent | 13248028 | Sep 2011 | US |
| Child | 13239321 | US | |
| Parent | 13247998 | Sep 2011 | US |
| Child | 13248028 | US | |
| Parent | 13134005 | May 2011 | US |
| Child | 13247998 | US | |
| Parent | 13248025 | Sep 2011 | US |
| Child | 13134005 | US | |
| Parent | 12380778 | Mar 2009 | US |
| Child | 12695019 | Jan 2010 | US |
| Parent | 12380771 | Mar 2009 | US |
| Child | 12380778 | US | |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12695020 | Jan 2010 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12694445 | Jan 2010 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12694451 | Jan 2010 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12694455 | Jan 2010 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12695021 | Jan 2010 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12695980 | Jan 2010 | US |
| Parent | 12695019 | Jan 2010 | US |
| Child | 12380780 | US | |
| Parent | 12695021 | Jan 2010 | US |
| Child | 12695019 | US | |
| Parent | 12380778 | Mar 2009 | US |
| Child | 13134028 | May 2011 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 13248028 | Sep 2011 | US |
| Parent | 12695019 | Jan 2010 | US |
| Child | 13134028 | May 2011 | US |
| Parent | 12695020 | Jan 2010 | US |
| Child | 12695019 | US | |
| Parent | 12694445 | Jan 2010 | US |
| Child | 12695020 | US | |
| Parent | 12694451 | Jan 2010 | US |
| Child | 12694445 | US | |
| Parent | 12694455 | Jan 2010 | US |
| Child | 12694451 | US | |
| Parent | 12695021 | Jan 2010 | US |
| Child | 13248028 | Sep 2011 | US |
| Parent | 12695980 | Jan 2010 | US |
| Child | 12695021 | US | |
| Parent | 13134005 | May 2011 | US |
| Child | 12695980 | US | |
| Parent | 12380778 | Mar 2009 | US |
| Child | 13134005 | May 2011 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12380778 | US | |
| Parent | 12695019 | Jan 2010 | US |
| Child | 12380780 | US | |
| Parent | 12695020 | Jan 2010 | US |
| Child | 12695019 | US | |
| Parent | 12694445 | Jan 2010 | US |
| Child | 12695020 | US | |
| Parent | 12694451 | Jan 2010 | US |
| Child | 12694445 | US | |
| Parent | 12694455 | Jan 2010 | US |
| Child | 12694451 | US | |
| Parent | 12695021 | Jan 2010 | US |
| Child | 12694455 | US | |
| Parent | 12380778 | Mar 2009 | US |
| Child | 13229580 | Sep 2011 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12380778 | US | |
| Parent | 12695019 | Jan 2010 | US |
| Child | 12380780 | US | |
| Parent | 12695020 | Jan 2010 | US |
| Child | 12695019 | US | |
| Parent | 12694445 | Jan 2010 | US |
| Child | 12695020 | US | |
| Parent | 12694451 | Jan 2010 | US |
| Child | 12694445 | US | |
| Parent | 12694455 | Jan 2010 | US |
| Child | 12694451 | US | |
| Parent | 12695021 | Jan 2010 | US |
| Child | 12694455 | US | |
| Parent | 12695980 | Jan 2010 | US |
| Child | 12695021 | US | |
| Parent | 13134005 | May 2011 | US |
| Child | 12695980 | US | |
| Parent | 12380778 | Mar 2009 | US |
| Child | 13237827 | Sep 2011 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12380778 | US | |
| Parent | 12695019 | Jan 2010 | US |
| Child | 12380780 | US | |
| Parent | 12695020 | Jan 2010 | US |
| Child | 12695019 | US | |
| Parent | 12694445 | Jan 2010 | US |
| Child | 12695020 | US | |
| Parent | 12694451 | Jan 2010 | US |
| Child | 12694445 | US | |
| Parent | 12694455 | Jan 2010 | US |
| Child | 12694451 | US | |
| Parent | 12695021 | Jan 2010 | US |
| Child | 12694455 | US | |
| Parent | 12695980 | Jan 2010 | US |
| Child | 12695021 | US | |
| Parent | 13134028 | May 2011 | US |
| Child | 12695980 | US | |
| Parent | 13229580 | Sep 2011 | US |
| Child | 13134028 | US | |
| Parent | 13134005 | May 2011 | US |
| Child | 13229580 | US | |
| Parent | 12380778 | Mar 2009 | US |
| Child | 13239321 | Sep 2011 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12380778 | US | |
| Parent | 12695019 | Jan 2010 | US |
| Child | 12380780 | US | |
| Parent | 12695020 | Jan 2010 | US |
| Child | 12695019 | US | |
| Parent | 12694445 | Jan 2010 | US |
| Child | 12695020 | US | |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12694445 | US | |
| Parent | 12694451 | Jan 2010 | US |
| Child | 13239321 | Sep 2011 | US |
| Parent | 12694455 | Jan 2010 | US |
| Child | 12694451 | US | |
| Parent | 12695021 | Jan 2010 | US |
| Child | 12694455 | US | |
| Parent | 12695980 | Jan 2010 | US |
| Child | 12695021 | US | |
| Parent | 13134028 | May 2011 | US |
| Child | 12695980 | US | |
| Parent | 13229580 | Sep 2011 | US |
| Child | 13134028 | US | |
| Parent | 13237827 | Sep 2011 | US |
| Child | 13134028 | May 2011 | US |
| Parent | 13134005 | May 2011 | US |
| Child | 13237827 | US | |
| Parent | 12380778 | Mar 2009 | US |
| Child | 13248028 | Sep 2011 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 13134028 | May 2011 | US |
| Parent | 12695019 | Jan 2010 | US |
| Child | 13248028 | Sep 2011 | US |
| Parent | 12695020 | Jan 2010 | US |
| Child | 12695019 | US | |
| Parent | 12694445 | Jan 2010 | US |
| Child | 12695020 | US | |
| Parent | 12694451 | Jan 2010 | US |
| Child | 12694445 | US | |
| Parent | 12694455 | Jan 2010 | US |
| Child | 12694451 | US | |
| Parent | 12695021 | Jan 2010 | US |
| Child | 12694455 | US | |
| Parent | 12695980 | Jan 2010 | US |
| Child | 12695021 | US | |
| Parent | 13134028 | May 2011 | US |
| Child | 13248028 | Sep 2011 | US |
| Parent | 13229580 | Sep 2011 | US |
| Child | 13134028 | US | |
| Parent | 13237827 | Sep 2011 | US |
| Child | 13229580 | US | |
| Parent | 13239321 | Sep 2011 | US |
| Child | 13237827 | US | |
| Parent | 13247998 | Sep 2011 | US |
| Child | 13239321 | US | |
| Parent | 13248025 | Sep 2011 | US |
| Child | 13247998 | US | |
| Parent | 13134005 | May 2011 | US |
| Child | 13248025 | US | |
| Parent | 12380778 | Mar 2009 | US |
| Child | 13247998 | Sep 2011 | US |
| Parent | 12380780 | Mar 2009 | US |
| Child | 12380778 | US | |
| Parent | 12695019 | Jan 2010 | US |
| Child | 12380780 | US | |
| Parent | 12695020 | Jan 2010 | US |
| Child | 12695019 | US | |
| Parent | 12694445 | Jan 2010 | US |
| Child | 12695020 | US | |
| Parent | 12694451 | Jan 2010 | US |
| Child | 12694445 | US | |
| Parent | 12694455 | Jan 2010 | US |
| Child | 12694451 | US | |
| Parent | 12695021 | Jan 2010 | US |
| Child | 12694455 | US | |
| Parent | 12695980 | Jan 2010 | US |
| Child | 12695021 | US | |
| Parent | 13134028 | May 2011 | US |
| Child | 12695980 | US | |
| Parent | 13229580 | Sep 2011 | US |
| Child | 13134028 | US | |
| Parent | 13237827 | Sep 2011 | US |
| Child | 13229580 | US | |
| Parent | 13239321 | Sep 2011 | US |
| Child | 13237827 | US | |
| Parent | 13248028 | Sep 2011 | US |
| Child | 13239321 | US | |
| Parent | 13248025 | Sep 2011 | US |
| Child | 13248028 | US | |
| Parent | 13134005 | May 2011 | US |
| Child | 13248025 | US |
