Abstract:
The number, popularity, sophistication, etc. of mobile applications have grown dramatically with the rise of smartphones, tablets, and other such devices. Alternatives to native application development, including approaches such as hybrid application development which may employ among other things a container paradigm, inter alia address various of the drawbacks associated with native application development. A flexible, extensible, and dynamically configurable Feature Vector (FV) facility addresses one challenge with approaches such as hybrid application development—controlling an application&#39;s access to features (e.g., functions, methods, resources, etc.) and the efficient administration, management, etc. same.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority under 35 U.S.C. 119 to Provisional Application 62/049,886, filed on Sep. 12, 2014, and entitled Enhanced Feature Vector, the contents of which are incorporated herein by reference in their entirety. 
     
    
     TECHNICAL FIELD 
       [0002]    This document relates generally to methods and systems for use with computer networks. More particularly, this document relates to the enhanced control of features within various classes of mobile applications. 
       BACKGROUND 
       [0003]    The number, popularity, sophistication, etc. of mobile applications (applications, or simply apps) have increased dramatically with the rise of smartphones, tablets, and other such devices. It is common for these applications to be downloaded by end users from a central repository, sometimes referred to as an “app store” or other location where digital files can be downloaded to user devices. Software developers often create apps and upload these apps to such a central repository. 
         [0004]    Apps may be designed as self-contained through a process known as native application development. One drawback to native application development is that it can become difficult to develop applications that operate on multiple different mobile platforms (cross-platform solutions), thus driving up the cost of development for apps that are intended to operate on multiple different mobile platforms. 
         [0005]    Alternatives to native application development, including approaches such as hybrid application development which may employ among other things a container paradigm, inter alia, address various of the drawbacks associated with native application development. One challenge with approaches such as hybrid application development concerns an application&#39;s access to features (e.g., functions, methods, resources, etc.) and how one can efficiently control, manage, etc. same. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0006]    The present disclosure is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: 
           [0007]      FIG. 1  is a diagram illustrating a system, in accordance with an example embodiment, to provide a container to a mobile device. 
           [0008]      FIG. 2  is a diagram illustrating a system, in accordance with an example embodiment, to provide a plug-in to a container on a mobile device. 
           [0009]      FIG. 3  is a flow diagram illustrating a method, in accordance with an example embodiment, of operating an application update plug-in. 
           [0010]      FIG. 4  is a flow diagram illustrating a method, in accordance with an example embodiment, of operating an application update plug-in. 
           [0011]      FIG. 5  is a diagram illustrating a system, in accordance with an example embodiment, of push notification. 
           [0012]      FIG. 6  is a flow diagram illustrating a method, in accordance with an example embodiment, of configuring push messaging on a mobile platform server. 
           [0013]      FIG. 7  is a flow diagram illustrating a method, in accordance with an example embodiment, of operating a user device. 
           [0014]      FIG. 8  is a flow diagram illustrating a method of designing an application to be executed on user devices having different operating system. 
           [0015]      FIG. 9  is a block diagram illustrating a mobile device, according to an example embodiment. 
           [0016]      FIG. 10  is a block diagram of machine in the example form of a computer system within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. 
           [0017]      FIG. 11  is a high-level flow diagram illustrating aspects of an example embodiment. 
           [0018]      FIG. 12  is a flow diagram illustrating aspects of the operation of an example embodiment. 
           [0019]      FIG. 13   a  presents a first illustrative snippet of application source code. 
           [0020]      FIG. 13   b  presents a second illustrative snippet of application source code. 
           [0021]      FIG. 14  depicts aspects of a plugin.xml file for the Apache Cordova plug-in. 
           [0022]      FIG. 15   a  illustrates a first aspect of a set of services that may be offered under an example embodiment. 
           [0023]      FIG. 15   b  illustrates a second aspect of a set of services that may be offered under an example embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0024]    The description that follows includes illustrative systems, methods, techniques, instruction sequences, and computing machine program products that embody illustrative embodiments. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be evident, however, to those skilled in the art that embodiments of the inventive subject matter may be practiced without these specific details. In general, for simplicity of exposition well-known instruction instances, protocols, structures, techniques, etc. have not been shown in detail. 
         [0025]    For purposes of this disclosure, a container is a runtime environment that is inter alia executable on a mobile device within which mobile applications (or apps) can be executed. A container is a native application that is installed on the mobile device. A container may include inter alia messaging libraries, a local datastore, toolkits having a runtime from the native operating system&#39;s software development kit (SDK), etc. It may also embed a browser, which allows developers to build mobile applications using web development paradigms as opposed to traditional software development paradigms, while still maximizing the power of the native device services. This allows rapid development of mobile workflows across multiple platforms. These types of applications may extend existing enterprise business processes to, for example, a mobile device, so that business process decisions can be made on a mobile device. 
         [0026]    In some example embodiments, a container may be designed to allow developers to create applications in open, standards-based protocols such as inter alia HyperText Markup Language (HTML) 5, JavaScript, and Cascading Style Sheets (CSS). A set of HTML files may define, etc. inter alia the app screens. A set of JavaScript files may include the methods for navigating from screen to screen and the functions for accessing data for the screens. A set of CSS files may provide the styling for the screen elements. 
         [0027]      FIG. 1  is a diagram illustrating a system  100 , in accordance with an example embodiment, to provide a container to a mobile device. The system  100  may include a container platform  102 , which may store workflow metadata  104  obtained from one or more designers  106 A,  106 B. Each designer  106 A,  106 B may design container forms, including, for example, HTML, CSS, and JavaScript files, which may then be sent to the container platform  102  and stored as workflow metadata  104 . A client mobile device  108  may then operate a container  110 , which includes container services  112 , a browser  114 , and container metadata  116 . The container services  112  may include various libraries of functions, including, for example, storage, messaging, security, provisioning functions, etc. The browser  114  may create a runtime environment using the container services  112  and the container metadata  116 , which is obtained from the workflow metadata  104 . 
         [0028]    In an example embodiment, the container  110  may be dynamically extended or altered through the use of one or more plug-ins.  FIG. 2  is a diagram illustrating a system  200 , in accordance with an example embodiment, to provide a plug-in  204  to a container  110  on a mobile device. The system  200  may include the container platform  102 , which may store workflow metadata  104  obtained from one or more designers  106 A,  106 B. The system may additionally include a plug-in developer  202 . A client mobile device  108  may then operate a container  110 , which includes container services  112 , a plug-in  204 , a browser  114 , and container metadata  116 . The plug-in  204  may be transmitted to the client mobile device  108  from the plug-in developer  202  via the container platform  102 . In an alternative example embodiment, the plug-in developer  202  sends the plug-in directly to the client mobile device  108 . 
         [0029]    A plug-in  204  may provide functionality not available in the container services  112  that the plug-in developer  202  believes that application designers, such as designers  106 A,  106 B, may wish to utilize. At runtime, the browser  114  is designed to run both the container services  112  and the plug-in  204 , making for a seamless experience for the user. This is accomplished without modifying the other aspects of the container  110 , such as the container services  112 , browser  114 , and container metadata  116 . 
         [0030]    In an example embodiment, the container services  112  include JavaScript libraries that provide consistent APIs that can call the same way on any supported device. In this example embodiment, multiple plug-ins  204  are provided, including plug-ins  204  for application lifecycle management, implementation of a common logon manager, single sign-on (SSO), integrating with server-based push notifications, etc. The plug-ins  204  may utilize a configuration file of the container  110  and extend it for any settings they need for their purposes. For example, if a plug-in  204  needs to extend application configuration items such as sandboxing, application lifecycle, supportability, and so on, it may utilize additional property name fields in the configuration file. 
         [0031]    In an example embodiment, a designer  106 A,  106 B may install the container services  112  and plug-ins, such as plug-in  204  on its own system, in order to be used for creating and testing the container metadata  116  prior to distribution to mobile devices, such as client mobile device  108 . 
         [0032]    The designer  106 A,  106 B may then set configuration parameters to configure the ultimate client devices that will run the container  110 . This may include, for example, designing back-end connections for selected native and hybrid applications. This may be performed by setting fields defining whether the client device will use a system proxy, whether the client device will rewrite uniform resource locators (URLs), the maximum connections for the client device, and identifying a certificate alias of a specific certificate in the system keystone that is used when making a secure connection to the specified server. Additionally, whitelisted and/or blacklisted connections may be expanded. 
         [0033]    A plug-in  204  may expand the universe of capabilities, services, etc. that are available to applications written in open, standards-based protocols, that operate within the container  110  without altering the container  110  or any of the other plug-ins that may reside within the container  110 . Thus, such a plug-in  204  may coexist with any other plug-ins and would not impact the ability of a mobile device  108  to update aspects of the container  110 , while minimizing the time required for an application designer to create the application. 
         [0034]    Such a plug-in  204  may also make a container  110  more capable, robust, etc. by offering additional or missing features, functions, services, etc. and generally make the container  110  more enterprise-ready, among other things. 
         [0035]    Such a plug-in  204  may also provide access to native functionality (e.g., camera, accelerometer, contact list entries) of a mobile device  108 . As such, the plug-in serves as something of a bridge between the native or traditional world of mobile device applications, which would have direct access to native functionality such as the camera, and non-native applications. Such a plug-in  204  can abstract, or otherwise hide, various of the complexities associated with accessing and using this native functionality by, for example, exposing a simplified interface for it. Such a plug-in  204  may offer, among other things, enhanced security, limits on available operations, in connecting with, accessing and using native functionality. 
         [0036]    Such a plug-in  204  may also provide various performance enhancements that can improve, among other things, the loading time of the application. 
         [0037]    Such a plug-in  204  may also support server-controlled management (e.g. provisioning, updating, etc.) of applications as frequently required within an enterprise setting. Among other things the transfer and application of secure incremental updates, patches, etc., transparent to the user, may be supported. 
         [0038]    Such a plug-in  204  may also support the flexible, extensible, and dynamic management of activities during any of the different phases (e.g., instantiation, startup, operation, shutdown, etc.) of the lifecycle of an application. Such a plug-in  204  may also address structural weaknesses, deficiencies, etc. that exist within a container  110 , such as data access, security, the concurrent operation of multiple applications, etc. through, for example, the offering of additional, or possibly replacement, capabilities and services. 
         [0039]    Such a plug-in  204  may comprise any combination of aspects of a publicly-available facility (such as for example Apache Cordova) and aspects of a private (e.g., custom developed) facility. 
         [0040]    Examples of plug-ins  204  include, but are by no means limited to: 
         [0041]    1) Logon. A logon plug-in may provide inter alia a login screen where a device user can enter values needed to connect to for example a server, such values possibly preserved in a local data vault (e.g., repository). This data vault may be separate from the one provided with other plug-ins. It also provides a way to lock and unlock the application defined by the container metadata  116 , so the user can leave sensitive data open in the application. 
         [0042]    2) Settings. A settings plug-in provides an ability to trigger an operation on a server to allow an application to store device and user settings on the client device for later use. The client device sends the server a device type, device model, whether push is enabled, and other push-related information. The settings may also use a device token received during device configuration. The server then can use this information to decide what kind of push notification to send (e.g., cloud messaging, push notification service, etc.). 
         [0043]    3) Application Update. An application update plug-in provides server-based updates to the application content and manages the process of checking, downloading, and installing updates to the application running within the container  110 . The application update plug-in may contain a series of application update methods, including, for example, an application update method that starts the application update process and triggers any required log on process, a reload application method that replaces the application resources with any newly downloaded resources and refreshes the page, an update method that forces an update check, an on update ready method that provides a handler for when an update is available, and an on login required method that provides a handler for log on. 
         [0044]      FIG. 3  is a flow diagram illustrating a method  300 , in accordance with an example embodiment, of operating an application update plug-in. At operation  302 , the application update method starts and triggers any needed update process. At operation  304 , the updates are downloaded. At operation  306 , a reload application method may ask the user to reload the application. If not, then at operation  308  the on update ready method is triggered the next time the application is resumed or started. If so, then at operation  310 , the on update ready method is triggered now. 
         [0045]      FIG. 4  is a flow diagram illustrating a method  400 , in accordance with an example embodiment, of operating an application update plug-in. At operation  402 , the application update method starts and triggers any needed update process. At operation  404 , the updates are downloaded. At operation  406 , a reload application method may ask the user to reload the application. At operation  408 , the on update ready method is triggered. At operation  410 , the reload application method is called and asks the user to reload the application. Then the user reloads the application. At operation  412  the reload application method is called and the updated application loads. 
         [0046]    Updates to an application may either be full or delta. Delta updates only download and install aspects of the application that have been changed since the last update. A full update may be used when, for example, the local revision number is 0, or where the local revision number is one full number away from the server revision number (e.g., local revision number 1.2 and server revision number 2.1). 
         [0047]    4) Authorization Proxy. An authorization proxy plug-in automates the process of accepting certificates, such as Secure Socket Layer (SSL) certificates, returned by a call to a web resource. If users want to send an Asynchronous JavaScript and Extensible Markup Language (AJAX) request, for example, to an HTTPS server and the embedded browser  116  does not support the SSL, then users could utilize the authorization proxy plug-in for this purpose. 
         [0048]    5) Logger. A logger plug-in allows the developer to log messages, by calling one or more methods in the logger plug-in. 
         [0049]    6) Push Notification. A push notification plug-in enables various notification capabilities for applications. 
         [0050]      FIG. 5  is a diagram illustrating a system, in accordance with an example embodiment, of push notification. The system includes the client device  502 , running a container  110 , and which receives push notifications, a notification service provider  504  that sends the push notifications, and a mobile platform server  506 , which collects device identifications from the clients and push notifications through the notification service provider  504 . The push notification plug-in allows developers to enroll applications for notification with notification registration, as well as to receive and process incoming notifications for applications. Such a plug-in can also support background notification processing. 
         [0051]      FIG. 6  is a flow diagram illustrating a method  600 , in accordance with an example embodiment, of configuring push messaging on a mobile platform server. This method may be performed, for example, by a designer  106 A or  106 B. At operation  602 , values for a new application (such as for example ID, Name, Vendor, Version, Type, Description, etc.) are provided to the mobile platform. At operation  604 , endpoint (e.g., provider  504 ) information may be configured. At operation  606 , push settings may be configured. 
         [0052]    7) Storage. A storage plug-in provides secure on-device storage. A storage plug-in may offer API methods that are asynchronous, and may include listener and callback functions. 
         [0053]    8) Specialized. A customized plug-in that addresses any combination of one or more business, technical, etc. requirements. 
         [0054]      FIG. 7  is a flow diagram illustrating a method  700 , in accordance with an example embodiment, of operating a user device. At operation  702 , a container  110  may be downloaded. The container  110  may be an application natively executable by a first operating system of the user device. The container  110  may include a container service  112  including one or more libraries of functions designed by a container  110  designer  106 A and  106 B to natively operate on the first operating system. The container  110  may also include a browser  116 . The container  110  may also include container metadata  118  defining functions of the application, the functions compatible with the container service  112  for the first operating system and also compatible with a container service  112  for a second operating system. The container  110  may also include a plug-in  204  including one or more additional libraries of functions designed by an entity other than the container  110  designer  106 A and  106 B to perform additional native operations on the first operating system. At operation  704 , the container metadata  116  may be executed using the browser  114 , causing function calls to the container service  112  and plug-in  204  and thus controlling native functions of the user device. 
         [0055]      FIG. 8  is a flow diagram illustrating a method  800  of designing an application to be executed on user devices having different operating systems. At operation  802 , a container  110  for a first operating system may be downloaded. The container  110  may include a container service  112  including one or more libraries of functions designed by a container  110  designer  106 A and  106 B to natively operate on the first operating system, and a browser  114 . At operation  804 , a first plug-in  204  is downloaded. The first plug-in  204  may include one or more additional libraries of functions designed by an entity other than the container  110  designer  106 A and  106 B to perform additional native operations on the first operating system. 
         [0056]    At operation  806 , container metadata  116  specifying functions on the application and containing calls to the libraries in the container service  112  for the first operating system and the first plug-in  204  is defined. At operation  808 , a first version of the application is built from the container  110  for the first operating system, the first plug-in  204 , and the container metadata  116 . 
         [0057]    At operation  810 , a container  110  for a second operating system is downloaded. The container  110  for the second operating system may include a container service  112  including one or more libraries of functions designed by the container  110  designer  106 A and  106 B to natively operating on the second operating system, and a browser  114 . At operation  812 , a second plug-in  204  is downloaded, the second plug-in  204  including one or more additional libraries of functions designed by an entity other than the container  110  designer  106 A and  106 B to perform additional native operations on the second operating system. At operation  814 , a second version of the application is built from the container  110  for the second operating system, the second plug-in  204 , and the container metadata  116 . 
         [0058]    As described above, the universe of containers, browsers, plug-ins, etc. provides for a rich mobile application environment. For reasons of security, control, corporate policy, etc. a flexible, extensible, and dynamically configurable Feature Vector (FV) facility provides for the efficient management of access to possibly among other things the features (e.g., functions, methods, etc.) that may for example be exposed through inter alia a (plug-in, container, etc.) API. 
         [0059]    In brief, a FV identifies for an app the particular features (e.g., functions, methods, etc.) that are to be disabled for, that is are not to be available to, the app. 
         [0060]    For example, for security, corporate policy, profile, preference, etc. reasons it may be necessary to preclude a particular app from being able to access certain native capabilities of a device such as for example a camera, an accelerometer, etc. In such cases a FV may be created that identifies those exclusions. 
         [0061]    An administrator (at for example an app store, within a corporate network environment, in an app development setting, etc.) may among other things define, manage, etc. a FV for an app. 
         [0062]      FIG. 11  and  FIG. 12  illustrate, conceptually and at a high level, aspects of such a process. 
         [0063]    For purposes of illustration, and as just one possible example,  FIG. 14  depicts a portion of a plugin.xml file for the Apache Cordova plug-in and  FIGS. 15   a  and  15   b  illustrate aspects of a set of Representational State Transfer (REST)-based functions, methods, services, etc. that may be provided to an administrator in support of inter alia standard CRUD operations on/for FVs: 
         [0064]    1) Create. The ability to create or define a new FV for an application (&lt;ApplicationID&gt; in the instant example in  FIG. 15   a ). 
         [0065]    2) Read. The ability to read or get a previously-defined FV for an application (&lt;ApplicationID&gt; in the instant example in  FIG. 15   a ). 
         [0066]    3) Update. The ability to update or change a previously-defined FV for an application (&lt;ApplicationID&gt; in the instant example in  FIG. 15   b ). 
         [0067]    4) Delete. The ability to delete or remove a previously-defined FV for an application (&lt;ApplicationID&gt; in the instant example in  FIG. 15   b ). 
         [0068]    An administrator may make use of any combination of one or more channels (including for example a GUI, APIs, command line interfaces, manual inputs, etc.) to view, manage, etc. a FV (through, as just one example, the REST-based functions, methods, etc. that were just described). 
         [0069]    Any number of facilities (including inter alia version control, check-in/check-out mechanisms, audit trails, etc.) may be provided in support of an administrator carrying out her activities. 
         [0070]    After a FV is created it may inter alia be stored with, reside with, etc. an app in/at for example an app store, a corporate network environment (e.g., an intranet), on the Internet, etc. 
         [0071]    A FV may be conveyed to a device at any number of points or times during an application&#39;s lifecycle—e.g., during any combination of one or more of when downloaded, when installed, when updated, when invoked, when a user logs in, when resuming from a sleep/idle state, when a user changes physical location, when the FV is changed/updated, etc.—using any combination of push and/or pull mechanisms. 
         [0072]    During FV conveyance any number of techniques, mechanisms, etc. (including inter alia recovery checkpoints, compression, checksums, chunking, etc.) may be employed to among other things improve performance, increase efficiency, etc. Additionally, during FV conveyance any number of techniques, mechanisms, etc. (including inter alia encryption, etc.) may be employed to among other things enhance security. 
         [0073]    When a FV is received by a device it may among other things be processed, parsed, validated, etc. and inter alia aspects of same may be preserved in a local repository (e.g., a data vault). Access to such a repository (by, for example, apps) may be secured in any number of ways. 
         [0074]    One or more function, methods, etc. may be made available to an app that inter alia query the local repository for relevant FV details and identify to the app among other things whether a specific feature (function, method, etc.), based on inter alia FV settings, is enabled or available. 
         [0075]    For purposes of illustration, one such function, method, etc.—isFeatureEnabled—is presented in  FIG. 13   a.    
         [0076]    In  FIG. 13   b  a snippet of application source code illustrates one way in which an app may invoke a isFeatureEnabled function, method, etc. to determine whether a specific feature (e.g., function, method, etc.)—“navigator.accelerometer” in the instant case—is enabled or available. 
         [0077]    A FV may incorporate any number of elements, values, components, structures, etc. (see for example  FIGS. 15   a  and  15   b  for one set of examples) including inter alia identifiers, descriptive text (such as for example name, description, title, etc.), blacklist and/or whitelist entries, Quality of Service designations, priority levels, resources other than just functions/methods/etc., date/time stamps capturing lifecycle events (creation, update, etc.), FV and/or app version information, device user location information (triggers, etc.), wildcard characters, regular expressions, rules, code (JavaScript, etc.) references, etc. 
         [0078]    A FV may be preserved (at a server, on a device, etc.) in any number of ways including for example any combination of conventional Relational Database Management Systems (RDBMSs), Object Database Management Systems (ODBMSs), in-memory Database Management Systems (DBMSs), data structures, flat files, memory constructs, etc. 
         [0079]    One or more special attributes may be defined. For example, for improved efficiency a Settings.AllFeaturesEnabled attribute may, when for example set to True, indicate that all features (e.g., functions, methods, etc.) are enabled or available, obviating for example the need for an app to make multiple individual calls to a isFeatureEnabled function, method, etc. 
         [0080]    For simplicity of exposition in the above discussion an app was described as having a (i.e., one) FV. However, it will be readily apparent to one of ordinary skill in the art that it is easily possible for an application to optionally have multiple FVs, with such FVs named in different ways and organized in any number ways (e.g., unordered, sequential, hierarchical, etc.). 
         [0081]      FIG. 9  is a block diagram illustrating a mobile device  900 , according to an example embodiment. The mobile device  900  may include a processor  902 . The processor  902  may be any of a variety of different types of commercially available processors  902  suitable for mobile devices  900  (for example, an XScale architecture microprocessor, a microprocessor without interlocked pipeline stages (MIPS) architecture processor, or another type of processor  902 ). A memory  904 , such as a random access memory (RAM), a flash memory, or other type of memory, is typically accessible to the processor  902 . The memory  904  may be adapted to store an operating system (OS)  906 , as well as application programs  908 , such as a mobile location enabled application that may provide LBSs to a user. The processor  902  may be coupled, either directly or via appropriate intermediary hardware, to a display  9010  and to one or more input/output (I/O) devices  912 , such as a keypad, a touch panel sensor, a microphone, and the like. Similarly, in some embodiments, the processor  902  may be coupled to a transceiver  914  that interfaces with an antenna  916 . The transceiver  914  may be configured to both transmit and receive cellular network signals, wireless data signals, or other types of signals via the antenna  916 , depending on the nature of the mobile device  900 . Further, in some configurations, a GPS receiver  918  may also make use of the antenna  916  to receive GPS signals. 
         [0082]    Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied (1) on a non-transitory machine-readable medium or (2) in a transmission signal) or hardware-implemented modules. A hardware-implemented module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more processors  902  may be configured by software (e.g., an application or application portion) as a hardware-implemented module that operates to perform certain operations as described herein. 
         [0083]    In various embodiments, a hardware-implemented module may be implemented mechanically or electronically. For example, a hardware-implemented module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware-implemented module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor  902  or other programmable processor  902 ) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware-implemented module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations. 
         [0084]    Accordingly, the term “hardware-implemented module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily or transitorily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which hardware-implemented modules are temporarily configured (e.g., programmed), each of the hardware-implemented modules need not be configured or instantiated at any one instance in time. For example, where the hardware-implemented modules comprise a general-purpose processor  902  configured using software, the general-purpose processor  902  may be configured as respective different hardware-implemented modules at different times. Software may accordingly configure a processor  902 , for example, to constitute a particular hardware-implemented module at one instance of time and to constitute a different hardware-implemented module at a different instance of time. 
         [0085]    Hardware-implemented modules can provide information to, and receive information from, other hardware-implemented modules. Accordingly, the described hardware-implemented modules may be regarded as being communicatively coupled. Where multiple of such hardware-implemented modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses that connect the hardware-implemented modules). In embodiments in which multiple hardware-implemented modules are configured or instantiated at different times, communications between such hardware-implemented modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware-implemented modules have access. For example, one hardware-implemented module may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware-implemented module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware-implemented modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information). 
         [0086]    The various operations of example methods described herein may be performed, at least partially, by one or more processors  902  that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors  902  may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules. 
         [0087]    Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or processors  902  or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors  902 , not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor  902  or processors  902  may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors  902  may be distributed across a number of locations. 
         [0088]    The one or more processors  902  may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs). 
         [0089]    Example embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Example embodiments may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor  902 , a computer, or multiple computers. 
         [0090]    A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network. 
         [0091]    In example embodiments, operations may be performed by one or more programmable processors  902  executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments may be implemented as, special purpose logic circuitry, e.g., a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC). 
         [0092]    The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. 
         [0093]    In embodiments deploying a programmable computing system, it will be appreciated that that both hardware and software architectures require consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor  902 ), or a combination of permanently and temporarily configured hardware may be a design choice. Below are set out hardware (e.g., machine) and software architectures that may be deployed, in various example embodiments. 
         [0094]      FIG. 10  is a block diagram of machine in the example form of a computer system  1000  within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a smartphone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. 
         [0095]    The example computer system  1000  includes a processor  1002  (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory  1004  and a static memory  1006 , which communicate with each other via a bus  1008 . The computer system  1000  may further include a video display unit  1010  (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system  1000  also includes an alphanumeric input device  1012  (e.g., a keyboard or a touch-sensitive display screen), a user interface (UI) navigation device  1014  (e.g., a mouse), a disk drive unit  1016 , a signal generation device  1018  (e.g., a speaker) and a network interface device  1020 . 
         [0096]    The disk drive unit  1016  includes a machine-readable medium  1022  on which is stored one or more sets of instructions and data structures (e.g., software)  1024  embodying or utilized by any one or more of the methodologies or functions described herein. The instructions  1024  may also reside, completely or at least partially, within the main memory  1004  and/or within the processor  1002  during execution thereof by the computer system  1000 , the main memory  1004  and the processor  1002  also constituting machine-readable media  1022 . 
         [0097]    While the machine-readable medium  1022  is shown in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions  1024  or data structures. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions  1024  for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions  1024 . The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media  1022  include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. 
         [0098]    The instructions  1024  may further be transmitted or received over a communications network  1026  using a transmission medium. The instructions  1024  may be transmitted using the network interface device  1020  and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions  1024  for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software. 
         [0099]    Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled. 
         [0100]    Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description. 
         [0101]    By way of example of a method in accordance with the above description, such a method for controlling access by an application to features on a client device may include receiving, from a server, a Feature Vector (FV) for the application. Such a method may further include processing aspects of the FV including at least preserving a portion of the FV in a local repository, and returning to the application an indicia of the availability of a feature by at least querying the local repository.