Patent Application
20140282062
A roaming user profile (“RUP”) is a type of user profile that enables users to access multiple computers in a same network with a consistent computing environment experience. A RUP stores a common set of user profile settings for the user, and may be accessed by each computer in the network to provide the common set of user profile settings across the computers. In this manner, the user may have a consistent desktop experience, such as by applications being automatically configured with particular preferred colors, window positions, and/or other user preferences defined by the user profile settings.
Typically, a RUP stores all of a user's profile data and settings in a central location as one unit. When a user logs on, the entire stored RUP is downloaded from the central location, and all the settings in the RUP are put in place so that the user has their entire profile setup. Similarly, when the user logs off, the settings that form the user's RUP are collected and pushed back out to the central location.
As such, because all the settings are stored as a single unit, and the RUP grows larger over time as profile data is added, the time taken to download and upload the RUP during logon and logoff increases over time. This leads to a very poor user experience when the RUP becomes particularly large. Furthermore, because the settings are stored together, if the single-unit RUP is corrupted, the entire user profile may be corrupted, which can render a computer system unusable. Still further, the use of a single-unit RUP leads to brittleness towards communication errors during upload and download of the RUP, which can also cause data loss and unusable computer systems.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Methods, systems, and computer program products are provided for user profiles, including roaming user profiles, that enable granular access and provide greater flexibility. Settings of a user profile are divided into different groups or “packages,” with each package being associated with and controlled by a corresponding application to which the settings apply. User settings of a particular package may be downloaded or uploaded at one or more trigger points, rather than downloading or uploading all of the user settings of the user profile. A first type of package may contain user settings specific to a particular application. A second type of package may be a “common” package that contains common user settings for an application suite that includes multiple applications. A third type of package may contain a functional group of user settings. The functional group of user settings is accessible by a plurality of applications, with each application having a corresponding set of user settings in the functional group of user settings.
In one implementation, a method for customizing user settings for applications is provided. A storage location for storing user profiles is selected. Each user profile includes one or more packages that each includes user settings for one or more applications. For at least one application on each computing device of a plurality of computing devices, a template may be stored that is associated with the application. The template identifies the application and indicates locations where the application stores the user settings. Furthermore, an agent may be associated with a trigger mechanism. The agent is configured to access the template associated with the application and to open a corresponding package at the selected storage location if the trigger mechanism is triggered (e.g., when the application is opened, etc.). The agent is configured to apply the user settings included in the package to the application at the locations indicated in the template.
Furthermore, an agent may be associated with another type of trigger mechanism (e.g., when the application is closed, etc.). The agent is configured to access the template associated with the application. The agent is configured to collect the user settings at the locations indicated in the template, and to provide the collected user settings to be included in the package.
Note that the agent may be associated with a trigger mechanism in many ways, such as by inserting an agent into at least one of a startup routine or a shutdown routine of the application, inserting an agent into at least one of a login routine or a logoff routine of the application, inserting an agent into at least one of a lock routine or an unlock routine of the application, inserting an agent into at least one of a sleep routine or a wake routine of the application, or inserting an agent into at least one of a session connect routine or a session disconnect routine of the application.
In another implementation, a method in an agent is provided. A template is accessed in response to a trigger mechanism being triggered with respect to an application in a computing device. The template identifies the application and indicates locations where the application stores the user settings. A package is accessed that includes the user settings at a storage location. The package is included in a user profile at the storage location that includes a plurality of packages that each includes user settings for one or more applications. The user settings included in the package are applied to the application at the locations indicated in the template. Alternately, for another type of trigger mechanism, the user settings may be collected from the locations indicated in the template, and provided to be included in the package.
In still another implementation, an application settings customization system is provided. The application settings customization system includes a configuration interface that includes an administrator interface and an application customizer. The administrator interface enables a storage location to be selected for storing user profiles. Each user profile includes one or more packages that each includes user settings for one or more applications. The application customizer is configured to store a template at a computing device in association with an application. The template identifies the application and indicates locations where the application stores the user settings. The application customizer is further configured to associate an agent for the application with a trigger mechanism. The agent is configured to access the template associated with the application and to open a corresponding package at the selected storage location if the trigger mechanism is triggered. The agent is configured to apply the user settings included in the package to the application at the locations indicated in the template. Alternately, for another type of trigger mechanism, the agent is configured to collect the user settings at the locations indicated in the template, and to provide the collected user settings to be included in the package.
Furthermore, the application customizer may be configured to install a filter driver at the computing device. The filter driver is configured to automatically associate agents with applications at the computing device.
Still further, the application settings customization system may further include a package distributer configured to respond to requests for packages from agents generated in response to trigger mechanisms being triggered with respect to applications.
A computer readable storage medium is also disclosed herein having computer program instructions stored therein that enable a processor to configure applications and computing devices to access user settings in the forms of packages, to operate an agent, and to enable additional embodiments described herein.
Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. It is noted that the invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.
The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art to make and use the invention.
The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.
The present specification discloses one or more embodiments that incorporate the features of the invention. The disclosed embodiment(s) merely exemplify the invention. The scope of the invention is not limited to the disclosed embodiment(s). The invention is defined by the claims appended hereto.
References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
Numerous exemplary embodiments of the present invention are described as follows. It is noted that any section/subsection headings provided herein are not intended to be limiting. Embodiments are described throughout this document, and any type of embodiment may be included under any section/subsection. Furthermore, embodiments disclosed in any section/subsection may be combined with any other embodiments described in the same section/subsection and/or a different section/subsection in any manner.
A roaming user profile (“RUP”) is a type of user profile that enables users to access multiple computers in a same network with a consistent computing environment experience. A RUP stores a common set of user profile settings for the user, and may be accessed by each computer in the network to provide the common set of user profile settings across the computers. In this manner, the user may have a consistent desktop experience, such as by applications at different computer systems being automatically configured with the same preferred colors, window positions, and/or other user preferences defined by the user profile settings.
A conventional RUP stores all of a user's profile data and settings in a central location as one unit such that when a user logs on, the entire stored RUP is downloaded from the central location. Similarly, when the user logs off, the settings that form the user's RUP are collected and pushed back out to the stored RUP at the central location. Whenever the user creates new settings for any applications, the new settings are stored in the user's RUP, causing the RUP to gradually grow in size. As such, conventional RUPs suffer from a gradually growing download and upload time, the possibility of an entire user profile being corrupted, and brittleness towards communication errors.
Embodiments described herein provide user profiles that overcome the disadvantages of conventional RUPs. In embodiments, settings of a user profile are divided into different groups or “packages,” with each package being associated with and controlled by a corresponding application to which the settings apply. As such, these user profiles are more granular than single-unit conventional RUPs. A particular package may be downloaded or uploaded at one or more trigger points related to the application, in real-time, to provide the particular user settings to the application, rather than downloading or uploading the entire user profile. Because of the granular nature of the packages, user profiles based on packages suffer less from the gradually increasing size problem of single-unit conventional RUPs. This package-based user profile configuration also avoids the problem of a corrupted RUP causing a user to lose their entire user profile. Instead, if a particular package becomes corrupted, other packages of the user profile directed to other applications are not affected. Furthermore, because the packages may be centrally located and network accessible, user profile embodiments can be accessed by multiple computing devices across a network to provide a user with a consistent computing environment across different computing devices.
According to embodiments, one or more different types of packages may be present in a user's profile. For instance, a first type of package may contain user settings specific to a particular application. A second type of package may be a “common” package or “application suite” package that contains user settings for an application suite that includes multiple applications. The user settings of the application suite package are applicable to all of the applications in the application suite. A third type of package may contain a functional group of user settings. The functional group of user settings is accessible by a plurality of applications, with each application controlling a corresponding set of user settings in the functional group of user settings.
Still further, according to embodiments, a greater variety of events or “triggers” (“events” and “triggers” are used interchangeably herein) associated with applications may control when the user settings of packages are downloaded and uploaded. For instance, a package may be triggered to be downloaded during a logon event, a logoff event, a lock event, an unlock event, a sleep event, a wake event, a session connect event, a session disconnect event, a startup event, a shutdown event, a file open event, a file save event, or other event associated with an application.
Even further, events or triggers may be used to control the frequency at which user settings are applied to applications. For example, some settings that change more frequently (e.g., schedule settings in a calendar) may be triggered more frequently than settings that change less often (e.g., a background color setting in a word processing application). Furthermore, because the upload and download of users settings may be performed separately for each application, different settings can be defined to be handled differently from each other. For example, changed user settings such as bookmarks (e.g., in a browser) can be merged with their previous state in a package, whereas changed users settings such as background color can overwrite their previous setting instance in a package.
Such embodiments may be implemented in a variety of environments. For instance,
Computing devices 102a and 102b may each be any type of stationary or mobile computing device, including a desktop computer (e.g., a personal computer, etc.), a mobile computer or computing device (e.g., a Microsoft® Surface® device, a personal digital assistant (PDA), a laptop computer, a notebook computer, a tablet computer such as an Apple iPad™, a netbook, etc.), a mobile phone (e.g., a cell phone, a smart phone such as a Microsoft Windows® phone, an Apple iPhone, a Google Android™ phone, a Palm® device, a RIM Blackberry® device, etc.), or other type of mobile device. Server 104 may be implemented in one or more computer systems, including one or more servers which may be any type of computing devices described herein or otherwise known that is/are capable of enabling the corresponding functionality described herein.
Computing devices 102a and 102b and server 104 are communicatively coupled by network 108. Network 108 may include one or more communication links and/or communication networks, such as a PAN (personal area network), a LAN (local area network), a WAN (wide area network), or a combination of networks, such as the Internet. Computing devices 102a and 102b, and server 104 may be communicatively coupled to network 108 using various links, including wired and/or wireless links, such as IEEE 802.11 wireless LAN (WLAN) wireless links, Worldwide Interoperability for Microwave Access (Wi-MAX) links, cellular network links, wireless personal area network (PAN) links (e.g., Bluetooth™ links), Ethernet links, USB links, etc.
Computing devices 102a and 102b are each associated with a corresponding user that interacts with the respective computing device as described herein. Two computing devices 102a and 102b are shown in
As shown in
Computing devices 102a and 102b are computing devices used by associated persons for any number and type of functions. For example, a first user at computing device 102a may interact with applications 118a and 118b, and a second user at computing device 102b may interact with applications 118c and 118d. Although two applications are shown in
The first and second users may have preferences for settings of applications 118a-118d that they have determined themselves and/or may have preferences for settings of applications 118a-118d that are determined for them by an administrator. Such settings are referred to as “user settings”. Examples of user settings include background colors, default fonts, default font sizes, pointer speeds, view settings, sounds, etc. An application may have any number of settings, including hundreds, thousands, or even greater numbers of user settings that may be determined. Such user settings may be stored in user profiles for the first and second users. According to embodiments, the user settings may be stored in the user profiles organized in the form of packages, with each package corresponding to one or more applications. At one or more trigger events, a package of user settings may be downloaded to configure an application (e.g., when the application is started, etc.), or the user settings of the application may be collected and stored in a package (e.g., when the application is shutdown, etc.)
For example, as shown in
For instance,
Package 116a is a first type of package that may contain user settings specific to a particular application. For instance, as shown in
For instance, application 118a of
Package 116b is a second type of package that is a “common” package containing common user settings for an application suite that includes multiple applications. For instance, as shown in
For instance, application 118b of
Note that in embodiments, any number of applications may have application-specific settings (such as application-specific user settings 202). Furthermore, any of such applications may be included in an application suite, and therefore may also have common user settings that are applicable thereto (such as common settings 208 included in application suite user settings 204) for a particular application suite. An application suite may include any number of applications that share common settings, including one application, two applications, or greater numbers of applications (e.g., tens, hundreds, etc.).
Package 116c is a third type of package that contains a functional group of user settings. The functional group of user settings is accessible by a plurality of applications, with each application having a corresponding set of user settings in the functional group of user settings. For instance, as shown in
For instance, applications 118c and 118d of
Note that in embodiments, any number of applications may have application-specific settings included in user settings functional group 206, including application-specific settings for one application, for two applications, or for greater numbers of applications (e.g., tens, hundreds, etc.).
Referring back to
As shown in
Package access 126 and package response 128 may be communicated between a computing device and package distributer 112 at server 104 through network 108 in any manner. For instance, a user profile, such as user profile 114a, may be stored in storage 106 in a directory structure, with each package of the user profile stored as a separate file. In such case, package access 126 may be an open of the file representing the package, and package response 128 may include the file/user settings included in the file for the agent. The agent may maintain an indication of a storage location of the user profile in storage 106 (e.g., the agent may maintain a storage directory or path for the storage location), and may determine the name of the package file from the corresponding template. For instance, an identifier for the template (a template identifier) may indicate the package filename at the storage location. In other embodiments, package access 126 and package response 128 may be communicated in signals through network 108 in other ways, such as by TCP/IP (Transmission Control Protocol/Internet Protocol), User Datagram Protocol (UDP), etc., according to any suitable file transfer protocol, including FTP (File Transfer Protocol), HTTP (Hypertext Transfer Protocol), etc.
Applications may be set up in any manner by application settings customization system 124 to access user settings in packages using agents and templates. For instance, in an embodiment, configuration interface 110 may be interacted with by an administrator (a user) to configure one or more applications at computing devices, such as computing devices 102a and 102b, to access user settings in packages stored in storage 106. For example, in an embodiment, configuration interface 110 may enable an administrator to select the location for storing user profiles in storage 106, and may enable agents and templates to be associated with applications at the computing devices, so that at various trigger events, user settings are downloaded or uploaded to the applications using packages stored in the user profiles.
Elements of communication system 100 shown in
A. Example Embodiments for Setting Up Applications to Access Custom User Settings
As described above, in embodiments, applications can be set up to access user settings in the form of packages. Such set up can be performed in various ways. For instance,
Flowchart 300 begins with step 302. In step 302, a storage location for storing user profiles is selected. For instance, in an embodiment, administrator interface 402 may enable an administrator to select the location for storing user profiles in storage 106 (e.g., a “central storage location” or “central location”). In an embodiment, administrator interface 402 may generate a user interface 406, which may be interacted with by the administrator to select the storage location in storage 106. For instance, server 104 may operate a web browser that renders user interface 406 based on a web document provided by administrator interface 402. Alternatively, user interface 406 may be generated in other ways.
It is noted that administrator interface 402 may enable the administrator to configure other system parameters by interacting with user interface 406. For instance, in some situations, an administrator may centrally control user settings for users in a computer network. In such case, the administrator may be enabled to select values for one or more user settings, and to store the selected values in one or more packages in one or more user profiles.
User interface 406 may include any number and combination of user interface elements to enable the administrator to select the storage location for user profiles and to optionally configure further system parameters. Examples of such user interface elements include graphical icons, visual indicators, menus, radio buttons, check boxes, sliders, etc. An administrator at server 104 (or at other computing device coupled to server 104 through network 108) may be enabled to select the storage location for user profiles and to configure further system parameters in various ways by interacting with user interface 406, such as by navigating to a directory location, entering information in a text box, selecting information from a list or drop down menu, and/or in other ways.
Referring back to
In step 306, for at least one application on each computing device of the plurality of computing devices, an agent is associated with a trigger mechanism, the agent configured to access the template associated with the application and to open a corresponding package at the selected storage location if the trigger mechanism is triggered. For instance, in an embodiment, application customizer 404 may associate an agent with a trigger mechanism for one or more applications at one or more computing devices. Referring to computing device 102a shown in
An agent may be associated with any suitable type of trigger mechanism related to an application in any way. For instance, an agent may be inserted into a startup routine, into a shutdown routine, into a login routine, into a logoff routine, into at a lock routine, into an unlock routine, into a sleep routine, into a wake routine, into a session connect routine, a session disconnect routine, into a file open routine, into a file save routine, or into any other routine, process, or code associated with an application. An agent may be triggered on a periodic basis (e.g., by a clock or other timer) or on a non-periodic basis. An agent may be associated with trigger events that occur more or less often, depending how frequent it is desired to apply user settings to an application. For example, some settings that change more frequently (e.g., changing between week view and month view in a calendar application, changing between draft view and page view in a word processing application, etc.) may be desired to be triggered more frequently than settings that change less often (e.g., changing a background color setting in a word processing application, etc.).
Note that in one embodiment, application customizer 404 may perform steps 304 and 306 for an application by generating a template and agent for the application, copying the template and agent to the computing device, storing the template in a predetermined template storage location (that is known to the agent), and by inserting or storing the agent in a location to be associated with the trigger mechanism of the application.
In another embodiment, application customizer 404 may perform steps 304 and 306 for one or more applications at a computing device by installing a filter driver at the computing device. For instance, as shown in
B. Example Embodiments for Applying User Settings from Packages
As described above, in embodiments, applications can be configured with user settings automatically retrieved from packages in real-time. Such real-time configuring of applications with user settings can be performed in various ways. For instance,
Flowchart 500 begins with step 502. In step 502, a template is accessed in response to a trigger mechanism being triggered with respect to an application in the computing device. With reference to
Internally, template 120a may identify application 118a (e.g., by application name, identifier, etc.), may optionally indicate at least one version of application 118a, and may indicate locations (e.g., directory locations, file names, registry locations, etc.) to apply user settings to configure application 118a with one or more user settings. The user settings may be common to a suite of applications that includes application 118a, may be included in a functional group, and/or may be specific to application 118a.
In step 504, a package that includes the user settings is accessed at a storage location, the package included in a user profile that includes a plurality of packages that each includes user settings for one or more applications. For example, with reference to
In step 506, the user settings included in the package are applied to the application at the locations indicated in the template. For instance, in an embodiment, agent 116a is configured to apply the user settings included in package 116a to application 118a at the locations indicated for the user settings in template 120a. Any number of user settings may be applied to an application in this manner, including tens, hundreds, and even more user settings. The user settings may be applied at any locations for an application, including as registry settings in a registry, as files stored in directories, as entries made in a configuration file, etc. The user settings from the package may replace user settings that are already present, and these replaced user settings may be saved to be subsequently re-applied to the application (e.g., by an agent in response to another trigger occurrence).
Note that in the case of an application that is included in an application suite, agent 122a may apply the common user settings to the application from the application suite package, and then may apply the application-specific user settings to the application from the application-specific package. If a user setting is present in both the common and application-specific packages, by applying the application-specific user settings after the common user settings, the application-specific user setting that is present in both packages overwrites the common user setting. As such, the application-specific user settings override the common user settings. Alternatively, in another embodiment, the common settings may be applied after the application-specific user settings so that the common user settings override the application-specific user settings.
In this way, an application may be automatically configured with user settings in a manner that is consistent across multiple computing devices. Upon occurrence of a trigger, user settings may be applied to an application, while operation of the application is held up. For instance, a startup routine, a wake routine, an unlock routine, a login routine, etc., of the application may be interrupted or paused while the user settings are obtained and applied. After the user settings are applied to the application in response to the trigger, the application may be enabled to continue operating, with the applied user settings thereafter being used by the application.
Optionally, upon occurrence of another trigger (e.g., an opposing trigger such as a shutdown routine, a sleep routine, a lock routine, a logoff routine, etc.), the user settings may be collected from the application by an agent. For instance, the agent may access the corresponding template for locations of the user settings. The agent may collect the user settings from the indicated locations, and may optionally re-apply the original settings to the application (that were replaced by the user settings retrieved from the package), which the agent may have saved. The agent may provide the collected user settings to be stored in the package associated with the application at the central storage location. In this manner, the package stores the most up-to-date user settings for the application, including any user settings that the user may have changed while using the application since the user settings were applied.
Because the upload and download of user settings may be performed separately for each application, different settings can be defined to be handled differently from each other. For example, changed user settings such as bookmarks (e.g., in a browser) can be merged with their previous state in a package when stored in the package, whereas changed users settings such as background color can overwrite their previous setting instance in a package when stored in the package.
C. Example Embodiments for Templates
According to embodiments, templates, such as templates 120a-120d of
For instance, an example of a template in XML form is shown below. The example template shown below is an application-specific template that corresponds to a package that contains application-specific user settings (e.g., package 116a shown in FIG. 2). Furthermore, the example template corresponds to a calculator application (Microsoft® Calculator):
In this template example for a calculator application, the application name is provided (“Microsoft Calculator”), a template identifier is provided (“MicrosoftCalculator6”), an executable filename for the application is provided (“CALC.EXE”), a version for the application is provided (“6”), and a location for user settings for the application on the computing device is provided (“Software\Microsoft\Calc”). With regard to such an example, an agent for the application may access the template when triggered. The agent may use the template identifier (“MicrosoftCalculator6”) to identify the corresponding package at the centralized storage location, and may apply any user settings present in the package to the application at the indicated location for user settings (“Software\Microsoft\Calc”). The user settings may be stored in the package in the form of user setting identifier and value pairs, with the values being applied at the locations indicated in the template for their corresponding user setting identifiers.
Another example of a template in XML form is shown below. The example template shown below is an application suite template for an example application suite that corresponds to a first package that references common settings for an application suite (e.g., package 116b shown in
In this template example for an application suite, the application suite name is provided (“Microsoft Office 2010 (32-bit)”), and a template identifier is provided (“MicrosoftOffice2010Win32”). Common user settings are indicated (e.g., as delimited by “<Common>” and “</Common>”), with locations for the common user settings on the computing device provided (e.g., “Software\Microsoft\Office\14.0\Common” being a location for the user setting “Theme”, etc.). Furthermore, for each application of the suite, application-specific settings are indicated (e.g., as delimited by “<Application>” and “</Application>” for each application). Each application name is provided (e.g., “Microsoft Access 2010 (32-bit)”), a template identifier is provided (“Access”), an executable filename for the application is provided (“MSACCESS.EXE”), and a version or version range for the application is provided (e.g., “14”). The common settings and user settings may be registry settings, files, etc.
With regard to such an example, an agent for the application may access the application suite template when triggered. The agent may use the template identifier for the application suite (“MicrosoftOffice2010Win32”) to identify the corresponding application suite package at the centralized storage location, and may use the template identifier for the particular application (“Access”) to identify the particular application-specific package at the centralized storage location. The agent may access and apply any common user settings present in the application suite package to the application, as well as accessing and applying any application-specific user settings present in the corresponding application-specific package for the application, at the indicated locations.
Another type of template described herein is a functional group template. A functional group template is a template for a functional group of settings that is accessible by multiple applications. Each application has a corresponding set of user settings in the functional group of user settings. A functional group template may be similar to an application suite template, such as shown above, with the addition of a tag or other indicator that indicates that although the functional group template is similar to an application suite template, the user settings in the functional group template are to be managed as group, rather than individually by different applications as in an application suite template. As such, in a functional group template, though, a single group of user settings (e.g., accessibility settings) may contain user settings that are controlled by different applications (e.g., different sections of user settings for the different applications are not visible in the template—these user settings are included in a single section).
For example, the following is an XML tag entry that may be included in a functional group template to indicate the template as a functional group template:
<ManageSuiteOnly>true</ManageSuiteOnly>
Such a tag may be included in a functional group template that otherwise looks like an application suite template (such as the example Microsoft® Office 2010 shown above), to indicate that the template is a functional group template.
Note that these examples of templates are provided for illustrative purposes, and are not intended to be limiting. In other embodiments, templates may be formatted in other ways, as would be apparent to persons skilled in the relevant art(s) from the teachings herein.
D. Example Application Embodiments
Applications 118a, 118b, 118c, and 118d, which execute at computing devices 102a and 102b of
A mobile application or “mobile app” is an application configured to run on a mobile device, which may be downloaded to a computing device through an application distribution platform or otherwise obtained. Examples of application distribution platforms for mobile apps include the Apple® App Store provided by Apple Inc. of Cupertino, Calif., Google® Play™ provided by Google Inc., California, the Microsoft® Windows® Phone Store provided by Microsoft Corp., the Microsoft® Store Online, and BlackBerry® App World™ provided by Research in Motion Limited of Waterloo, Ontario, Canada.
A web application may be an application that may be accessed by over a network (e.g., network 108), and/or may be an application that is coded in a browser-supported programming language (e.g., JavaScript, combined with a browser-rendered markup language such as HTML) and executes in a web browser to render the application executable. Examples of suitable web browsers include Internet Explorer®, developed by Microsoft Corp., Mozilla Firefox®, developed by Mozilla Corp. of Mountain View, Calif., Safari®, developed by Apple Inc., and Google® Chrome. Examples of applications that may be run in a browser and/or a mobile app interface include social networking applications, search engines, navigational assistance applications (e.g., mapping applications, restaurant locating applications, traffic applications, etc.), gaming applications, financial planning applications, etc.
An operating system is an application that is a collection of programs that manages computer hardware resources and provides common services for computer programs. Examples of operating systems include Microsoft® Windows® (e.g., Windows® 7, Windows® 8, Windows® Phone 8, etc.), Apple® OS X®, Apple® iOS, Google Android™, and Linux®.
D. Example Computing Device and Server Embodiments
Configuration interface 110, package distributer 112, applications 118a-118d, agents 122a-122d, application settings customization system 124, administrator interface 402, application customizer 404, filter driver 408, flowchart 300, and flowchart 500 may be implemented in hardware, or hardware combined with software and/or firmware. For example, configuration interface 110, package distributer 112, applications 118a-118d, agents 122a-122d, application settings customization system 124, administrator interface 402, application customizer 404, filter driver 408, flowchart 300, and/or flowchart 500 may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium. Alternatively, configuration interface 110, package distributer 112, applications 118a-118d, agents 122a-122d, application settings customization system 124, administrator interface 402, application customizer 404, filter driver 408, flowchart 300, and/or flowchart 500 may be implemented as hardware logic/electrical circuitry.
For instance, in an embodiment, one or more of configuration interface 110, package distributer 112, applications 118a-118d, agents 122a-122d, application settings customization system 124, administrator interface 402, application customizer 404, filter driver 408, flowchart 300, and/or flowchart 500 may be implemented together in a system-on-chip (SoC). The SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a central processing unit (CPU), microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits and/or embedded firmware to perform its functions.
As shown in
Computing device 700 also has one or more of the following drives: a hard disk drive 714 for reading from and writing to a hard disk, a magnetic disk drive 716 for reading from or writing to a removable magnetic disk 718, and an optical disk drive 720 for reading from or writing to a removable optical disk 722 such as a CD ROM, DVD ROM, or other optical media. Hard disk drive 714, magnetic disk drive 716, and optical disk drive 720 are connected to bus 706 by a hard disk drive interface 724, a magnetic disk drive interface 726, and an optical drive interface 728, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer. Although a hard disk, a removable magnetic disk and a removable optical disk are described, other types of computer-readable storage media can be used to store data, such as flash memory cards, digital video disks, RAMs, ROMs, and the like.
A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include an operating system 730, one or more application programs 732, other program modules 734, and program data 736. Application programs 732 or program modules 734 may include, for example, computer program logic (e.g., computer program code or instructions) for implementing configuration interface 110, package distributer 112, applications 118a-118d, agents 122a-122d, application settings customization system 124, administrator interface 402, application customizer 404, filter driver 408, flowchart 300, and/or flowchart 500 (including any step of flowcharts 300 and 500), and/or further embodiments described herein.
A user may enter commands and information into the computing device 700 through input devices such as keyboard 738 and pointing device 740. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, a touch screen and/or touch pad, a voice recognition system to receive voice input, a gesture recognition system to receive gesture input, or the like. These and other input devices are often connected to processor 702 through a serial port interface 742 that is coupled to bus 706, but may be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB).
A display screen 744 is also connected to bus 706 via an interface, such as a video adapter 746. Display screen 744 may be external to, or incorporated in computing device 700. In addition to display screen 744, computing device 700 may include other peripheral output devices (not shown) such as speakers and printers.
Computing device 700 is connected to a network 748 (e.g., the Internet) through an adaptor or network interface 750, a modem 752, or other means for establishing communications over the network. Modem 752, which may be internal or external, may be connected to bus 706 via serial port interface 742, as shown in
As used herein, the terms “computer program medium,” “computer-readable medium,” and “computer-readable storage medium” are used to generally refer to media such as the hard disk associated with hard disk drive 714, removable magnetic disk 718, removable optical disk 722, as well as other media such as flash memory cards, digital video disks, RAMs, ROMs, and the like. Such computer-readable storage media are distinguished from and non-overlapping with communication media (do not include communication media). Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wireless media such as acoustic, RF, infrared and other wireless media. Embodiments are also directed to such communication media.
As noted above, computer programs and modules (including application programs 732 and other program modules 734) may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. Such computer programs may also be received via network interface 750, serial port interface 742, or any other interface type. Such computer programs, when executed or loaded by an application, enable computing device 700 to implement features of embodiments of the present invention discussed herein. Accordingly, such computer programs represent controllers of the computing device 700.
The invention is also directed to computer program products comprising software stored on any computer useable medium. Such software, when executed in one or more data processing devices, causes a data processing device(s) to operate as described herein. Embodiments of the present invention employ any computer-useable or computer-readable medium, known now or in the future. Examples of computer-readable mediums include, but are not limited to storage devices such as RAM, hard drives, floppy disks, CD ROMs, DVD ROMs, zip disks, tapes, magnetic storage devices, optical storage devices, MEMs, nanotechnology-based storage devices, and the like.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be understood by those skilled in the relevant art(s) that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined in the appended claims. Accordingly, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
