HK1170608A - Unified policy over heterogenous device types - Google Patents

Description

Unified policy across heterogeneous device types

Technical Field

The present invention relates generally to policy management and, more particularly, to managing policies across heterogeneous device types.

Background

Televisions, telephones, gaming stations, and computers have affected almost every aspect of modern life. The functionality between these heterogeneous devices is merging. For example, a computer may be used for voice communication, while a telephone may be used to run applications or play games. As functions increase, the need for management and control also increases. For example, parents want the ability to control what content a child can view, how many text messages can be sent, the amount of time spent by entertainment activities hosted in the cloud (regardless of what device is used), and so forth. Currently, policy settings must be set separately for each device, making dynamic modification of settings difficult from a logistical perspective. Even further, policies may be set separately for each application on the device, such that policy adjustments must be made to potentially hundreds of different policy settings when changes are needed. Multiplying this by the number of device types used to access public services, including smart phones, televisions, PCs, game consoles, and hosting services, can be seen to quickly become a complex problem.

Group policies already exist across heterogeneous devices (e.g., a group of computers running the same operating system) and are currently used for2010. For example, a group policy is an infrastructure used to deliver and apply one or more desired configurations or policy settings to a set of target users and computers. The group policy infrastructure consists of a group policy engine and several individual extensions. These extensions are used to configure group policy settings by modifying registries or settings for security settings, software installation, folder redirection, browser maintenance, wireless network settings, and other areas of group policy settings. Each installation of a group policy consists of two extensions: server-side extensions for defining and setting policy settings to be applied to the client computer, and client-side extensions invoked by the group policy engine for applying policy settings.

Although policy settings have long been used across heterogeneous devices in a business environment, there remains a need for increased flexibility in policy settings across different device types having different underlying platforms comprised of unique combinations of hardware, operating systems, and unique applications that perform different or similar functions.

Thus, there is a need to increase flexibility in policy settings across device types, platforms, users, and/or applications.

Disclosure of Invention

A system and method for implementing a standardized set of policy-based behaviors across cloud-based instances of two or more different client devices, or virtualization devices, is disclosed. The policy definition may be a generic description of the desired behavior, while the client-side policy engine interprets and implements platform-specific details associated with the client.

In one embodiment, a client device receives a generic policy definition from a network. The general policy definition may be applicable to different device types having different hardware and/or software platforms. The client policy engine may analyze the generic policy definition, compare it to client-side applications or functions, and make intelligent decisions on how to apply the policy to a particular client.

In another embodiment, the client policy engine can consider the identity of the user and/or the role of the user (e.g., work, play, adult, child, observer, edit, administrator). Additionally, an activity log can be maintained that the client policy engine can analyze and use to make decisions regarding client device activity. Some examples of policy enforcement include: tracking the time spent watching an entertainment program or the number of text messages and emails sent, and restricting the client device or the class of applications across all devices when these parameters exceed policy thresholds.

In another embodiment, policy settings may be controlled remotely using client devices associated with a group (such as on the same account or from the same household). The changed policy settings may then be pushed to other different client devices in the group. For example, a parent may use a mobile phone to change policy settings, which may then be pushed down to a game console to limit the child's game time, and to limit PC-based or web-based games with the same settings.

The foregoing and other objects, features and advantages of the invention will become more apparent from the following detailed description, which proceeds with reference to the accompanying figures.

Drawings

Fig. 1 is an embodiment illustrating a plurality of user equipment types controlled by a general policy distributed via a network.

FIG. 2 is an embodiment illustrating different hardware and software structures that may be used to implement a general policy across heterogeneous device types.

FIG. 3 is an embodiment of a controller that may be used on a client device.

FIG. 4 is a flow diagram of a method for implementing a general policy across heterogeneous device types.

FIG. 5 is a flow diagram illustrating a method of different parameters that may be used to evaluate and compare a policy definition to functions on a client device.

FIG. 6 is a flow diagram of a method for enforcing policies on a client device.

FIG. 7 illustrates a system in which policy settings may be controlled by members of an associated group.

FIG. 8 is a flow chart illustrating the automatic distribution of policy settings using the system of FIG. 7.

FIG. 9 is a flow chart of a method showing details of a client device using policy services at power up.

Detailed Description

Fig. 1 is an embodiment illustrating a system 100 having a plurality of user device types 110, 112 communicatively coupled to a generic or unified policy distributed via a network 114. Any number of user device types and user devices may be used, as indicated by ellipsis 116. The user equipment types may be heterogeneous, meaning that at least some of the user equipment types may have different platforms than other user equipment types. Different platforms may indicate devices running a different operating system, having a different hardware structure, and/or having different basic functions and uses. It should be understood that some device types may be virtual instances running locally on the PC, or hosted in the cloud and accessed through a remote terminal. Example heterogeneous devices include gaming stations, telephones, computers, and televisions. The virtual device/application includes: console emulator and virtualized operating system instances, such asVirtual PC andvirtual Server and instances of non-Microsoft products such as VM Ware; and cloud services, such as by a browserFLASH orHosted web-based email and games.

The network (e.g., the internet) 114 may store general policy definitions for the various devices 110, 112. The network establishes a policy service that provides a common framework to define, evaluate, and exchange policy information. As described further below, the policy service can further allow each of the different devices to self-recover, or automatically adjust parameters and settings when a defined policy is not met.

There are a variety of techniques for implementing client devices having the functionality described herein, and FIG. 1 provides only one example solution. The device 110 includes a policy service 120 that collects general policy statements from the network. The general policy statements may include restrictions on the client device or the application running on the client device, such as: limiting the amount of time used per day, the number of hours worked, the power consumed or rate of consumption, the amount of calculations per second, the amount of transactions per second, the number of days worked (e.g., weekends only), or the number of actions taken during a day. Other limitations may also be provided depending on the particular application. For example, it may be allowed to spend 2 hours on email when most of the time is spent on a PC, but extend to a total of 2.5 hours if most of the time is spent on a device with a touch keyboard, since a slower input rate is expected. Restrictions may also be placed on the categories of applications, such as browsers. Policies may also change based on device capabilities. For example, a client application that requires more time to type an email may be provided more time (e.g., a smartphone may be given more time than a computer or touch screen phone due to slower typing speed). The policy service 120 may pass the general policy statements to the client policy engine 130, which client policy engine 130 may be implemented in software, hardware, or a combination thereof. The client policy engine 130 adjusts the general policy statements to suit the particular device 110. This adjustment uses information gathered from the client device itself. The client policy agent 140 gathers information from memory 150 on the client device, including client functionality and usage, such as configuration of application programs and/or operating system components. The client policy agent 140 may also collect a user identity 160 and modify the functionality available to the client device based on the user identity. The user identity typically includes credentials, and may further include roles or modes of operation (e.g., work or play and adult or child) and even biometric identity confirmation, such as face recognition, fingerprint scanning, voice print, and the like. The security of identity verification may determine the scope of access. For example, a child would not be expected to type in a username and password; but rather their photos from the list and optionally the images or shapes they use to unlock the device. If the child obtains the wrong image, the device will not erase itself. However, if the parent accesses the mistake 5 times, the device can be programmed to erase all content. Client device 112 has a similar structure as client device 110, but is tailored to the specific device type of the client.

The following example shows a policy to control client functionality by allowing 2 hours of gaming, social networking, and instant messaging applications on any of the three platforms between 5 and 9 pm.

Fig. 2 illustrates another embodiment with additional functionality and features that may be added to client 200. In this example, client policy engine 210 is coupled to policy service 212. As previously described, the policy service is coupled to a network (e.g., the Internet). Policy cache 214 may also be coupled to policy service 212 and client policy engine 210 to facilitate storing policy definitions received from the network. Using cached versions of policy definitions allows clients to adhere to general policies also when offline. The memory 216 coupled to the client policy engine 210 may also be used to store information about applications obtained from the network. Such information may be obtained using policy service 212 or other means. For example, an application such as shown at 220, 222 may be a game with an associated age rating. The age rating may be dynamically obtained from the network so that up-to-date age rating information may be obtained to comply with the policy. Thus, information associated with an application on a client may be obtained from a network and used to make localClient-side policy decisions. For example, children below an age rating may be prevented from running the application. The present invention includes the ability of a parent to delegate a portion of a policy to a third party teenager game rating system having a rating value that is more targeted to the parent's cultural preference. This is shown for the PC Game rating Attribute in FIG. 2. It should be understood that the present invention includes embodiments directed to a globally unique URI such asAs well as general category applications that complete a common scenario such as a browser, as shown in fig. 2. Specific game strategy can run the userIs limited to a predetermined time. While the browser example can restrict all applications on the device that have the ability to browse the internet. Further, a type of content may be accessed within another application. For example, if a user is restricted from playing video games within certain hours of the day, even those video games are played by a game such as MacromediaOrNor can the user play those video games within the browser, as the operating system will enforce policies on the content accessed. Similarly, access to music may be allowed, but restrictions on the type of music are enforced for a particular user, such as restricting music with explicit content alerts. Finally, policies may be adjusted based on device capabilities, such as allowing more time to be spent on email for devices that are inherently slow to type.

The client policy agent 230 collects client-side data about available applications 220, 222, client functions 232, 234 (e.g., operating system control functions such as text messaging), user identity and user patterns 240, and information 242 about daily usage and/or activity and passes this information to the client policy engine. For example, the log 242 may track the amount of time that an application or client function has been used (e.g., 3 hours of game play today, or 2 hours of browser use), or the number of times a function has been used (e.g., 10 text messages have been sent, or 10 emails have been sent). Any such information may be used to conform the client device 200 to the current policy. The client policy engine may use the gathered information to make the intelligent decisions needed to make the client comply with the policy. It should also be noted that the applications 220, 222 may be of different types (e.g., games, mapping applications, word processing, etc.), and the client functions 232, 234 may be of different types of operating system functions. Finally, the policy engine may handle an exception request feature that allows the requestor to contact the policy administrator to facilitate a temporary override. This is illustrated by the exception element in fig. 2. In the present system, if the user needs to spend more time on the email, they can send a text message to the parent's phone number to request more time. A parent's response to the request service will cause the rule exception to occur on the device.

Fig. 3 illustrates a generalized example of a suitable controller 300 in which the described techniques may be implemented. The controller is not intended to suggest any limitation as to scope of use or functionality, as the techniques may be implemented in diverse general-purpose or special-purpose computing environments.

Referring to fig. 3, the controller 300 may include at least one processing unit 310 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuit) coupled to a memory 320. Processing unit 310 executes computer-executable instructions and may be a real or virtual processor. The memory 320 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, phase change memory referred to as PCM or PRAM, etc.), or some combination of the two. Memory 320 may store software 380 that implements any of the techniques described herein.

The controller may have additional features. For example, the controller may include storage 340, one or more input devices 350, one or more output devices 360, and one or more communication connections 370. An interconnection mechanism (not shown) such as a bus or network interconnects these components. Typically, operating system software (not shown) provides an operating environment for other software executing in the controller and coordinates activities of the various components of the controller.

Storage 340 may be removable or non-removable, and may include magnetic disks, magnetic tapes or cassettes, flash memory, PCM, solid state disk (SSHD), CD-ROM, CD-RW, DVD, or any other computer-readable medium which can be used to store information and which can be accessed within the controller. The memory 340 can store software 380 containing instructions for detecting vessel wall artifacts associated with catheters in the vessel wall.

Input device 350 may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device. Output device 360 may be a display, printer, speaker, CD or DVD recorder, or another device that provides output from a controller. Some input/output devices, such as touch screens, may include both input and output functionality.

The communication connection 370 allows communication with another computing entity through a communication mechanism. The communication mechanism conveys information such as computer-executable instructions, audio/video or other information, or other data. By way of example, and not limitation, communication mechanisms include wired or wireless techniques implemented with an electrical, optical, Radio Frequency (RF), microwave, infrared, acoustic, or other carrier.

FIG. 4 is a flow diagram for implementing a policy service across multiple heterogeneous device types as described herein. At processing block 410, a policy definition is received from a network. Generally, the policy definition is stored on a server computer coupled to the Internet. The policy definition may be generic, meaning that it is not tailored specifically for a device type or a particular platform. Thus, the policy definition may be applicable to different device types, such as game consoles, telephones, televisions, personal computers, and the like. At processing block 420, the client-side policy engine evaluates the policy definition by comparing the policy definition to functions on the client device. First, a policy definition is searched for platform statements that match the client platform. For example, if the client is a gaming station, the policy statement associated with the gaming station is searched for in the policy statement. Once a matching platform is found, the associated sub-policy statements may be extracted from the policy definition. For example, the pattern type, access type, start and stop times, time quota, specific application types that can be accessed (e.g., games, social networks, and browsers), and specific functionality may be read from the policy statement and compared to the current functionality available on the client device using a current activity log, available applications, user identity, and the like. At processing block 430, the policy engine may enforce the policy definition by modifying the functionality available on the client to conform to the policy. There are a variety of techniques for enforcing policies. For example, the policy engine may perform the evaluation at boot time and store the results in memory for access by an application or operating system when a user attempts to operate. Alternatively, each time an operation is attempted, the policy engine may perform a new evaluation based on the current policy settings cached or pulled back from the network. The policy engine may then control or instruct the application or operating system to allow or block the desired functionality in order to modify the functionality of the client device.

Fig. 5 is a flow diagram illustrating a method of one or more processing blocks that can be performed during the evaluation processing block 420 of fig. 4. The functionality on the client device can be determined by reading the available application types, client functions and settings using the client policy agent. In addition, any other information described below can be used in determining available functions. At processing block 510, the user identity and/or user pattern is retrieved from memory. The user identity is typically associated with login credentials. The policy engine can apply different policies to different users. For example, children over 13 may be licensed to watch PG-13 movies instead of R rated movies, while children under 13 may not. Additionally, user modes may be considered. For example, a person in the working mode may have a different contact list presented in the application than when in the play mode. Thus, based on the user mode, the application and user interface settings may change. At processing block 520, data regarding the time and/or activity of the application or function being used by the user may be retrieved. As previously described, the activity log may store such data. For example, a user may be limited to spending a particular number of hours per day. The time data retrieved from the activity log may be a running total of how much time the application was active during the day. Similarly, the activity data may indicate how many times a particular event occurred, such as how many text messages were sent in 24 hours. Thus, by using the activity log, parameters on the client may be automatically or dynamically monitored. In addition, the amount used may affect the available functionality. At processing block 530, information associated with the application may be retrieved from the network. Thus, a particular application on the client may be identified, and such identification may be sent to the network. In response, the network can communicate policy-based information (e.g., current ratings) associated with the application back to the client for inclusion in the policy decision making process.

Fig. 6 shows a flow diagram of a method that further expands process block 430 of fig. 4. There are a variety of techniques for enforcing policies on an application or operating system, and FIG. 6 provides some possibilities. At processing block 610, a command is sent to an application or operating system to ensure compliance with the policy. Thus, for example, an application may receive commands from a policy engine and execute the commands. Once the command is received, the application follows the command until altered. Example commands can include application functionality of a blocking feature. Processing block 620 shows that the policy engine may further block functions, such as core operating system functions. For example, the policy engine may block the ability to send text messages or temporarily remove icons associated with restricted applications.

Fig. 7 illustrates a system diagram showing that one different device 710 associated with a user account can upload a generic policy definition to a network 720 and have the policy definition pushed to a different other device 730 and a similar device 740 associated with the same user account. The policy definitions may be stored on server 750, with server 750 communicating with various policy service modules on client devices. Thus, a parent may use a mobile phone to remotely and automatically change policy settings across all heterogeneous and homogeneous devices on the same account and control the functionality of the child's cell phone, gaming station or television, and/or computer.

FIG. 8 is a flow chart of a method for implementing the system of FIG. 7. At processing block 810, one of the devices in the group linked to the same account (e.g., a home account) may update the policy settings stored on the network. At processing block 820, the policy settings can be automatically distributed to other client devices in the same account. Thus, a user can dynamically and automatically control and distribute policy updates.

FIG. 9 is a flow diagram illustrating additional details of a method that can be implemented to enforce a general policy across different devices. At processing block 910, the client device downloads the general policy from the network upon power-up (such as during a boot process). At processing block 920, the policy engine evaluates the state of the client device based on the state of the plug-in and other settings. At processing block 930, the policy engine performs local evaluation and/or self-recovery, meaning that any applications or functions that do not comply with the policy are blocked or otherwise disabled. At processing block 940, a message is sent to the network indicating that either the error has occurred or the self-recovery has been completed. At processing block 950, the resulting policy evaluation is used before the device accesses local and networked resources (e.g., corporate networks, the Internet, and Internet-using applications like Texting, Voice over IP technologies).

Although some of the operations of the disclosed methods are described in a particular, sequential order for convenient presentation, it should be understood that this method of description encompasses rearrangement, unless a particular ordering is required by specific language set forth below. For example, in some cases, operations described sequentially may be rearranged or performed concurrently. Moreover, for the sake of brevity, the attached figures may not show the various ways in which the disclosed methods can be used in conjunction with other methods.

Any of the disclosed methods may be implemented as computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (such as DRAM or SRAM), or non-volatile memory components (such as hard drives)) and executed on a computer (e.g., any commercially available computer, including smart phones or other mobile devices that include computing hardware). Any of the computer-executable instructions for implementing the disclosed techniques, as well as any data created and used during implementation of the disclosed embodiments, can be stored on one or more computer-readable media (e.g., non-transitory computer-readable media). The computer-executable instructions may be part of a dedicated software application or a software application that is accessed or downloaded, for example, via a web browser or other software application, such as a remote computing application. For example, such software can be executed on a single local computer (e.g., any suitable commercially available computer) or in a network environment (e.g., via the internet, a wide area network, a local area network, a client-server network (such as a cloud computing network), or other such network) using one or more network computers.

For clarity, only certain selected aspects of software-based implementations are described. Other details known in the art are omitted. For example, it should be understood that the disclosed technology is not limited to any particular computer language, or program. For example, the disclosed technology may be implemented by software written in C + +, Java, Perl, JavaScript, AdobeFlash, or any other suitable programming language. Also, the disclosed techniques are not limited to any particular computer or type of hardware. Certain details of suitable computers and hardware are well known and need not be set forth in detail in this disclosure.

Further, any of the software-based embodiments (including, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) may be uploaded, downloaded, or accessed remotely via suitable communication means. Such suitable communication means include, for example, the internet, the world wide web, an intranet, software applications, electrical cables (including fiber optic cables), magnetic communication, electromagnetic communication (including RF, microwave, and infrared communication), electronic communication, or any such communication means.

The disclosed methods, apparatus, and systems should in no way be construed as limiting. Rather, the invention is directed to all novel and non-obvious features and aspects of the various disclosed embodiments, alone or in various combinations and subcombinations with one another. The disclosed methods, apparatus, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed embodiments require that any one or more specific advantages be present or problems be solved.

In view of the many possible embodiments to which the principles of the disclosed invention may be applied, it should be recognized that the illustrated embodiments are only preferred examples of the invention and should not be taken as limiting the scope of the invention. Rather, the scope of the invention is defined by the appended claims. Accordingly, all that comes within the scope of these claims is claimed as the invention.

Claims (10)

1. A method for enforcing policies on a client device, comprising:

receiving (410) a policy definition in a client device from a network, wherein the policy definition is a generic definition applicable to different device types having different hardware and software platforms;

evaluating (420) the received policy definition in a client policy engine located on the client device by comparing the policy definition to be used with functions available on the client device; and

the policy is enforced (430) by modifying functionality available on the client device based on the evaluation, wherein the client policy engine adjusts the generic policy definition to fit a particular platform on the client device.

2. The method of claim 1, wherein the evaluating comprises determining an identity of a user and modifying available functionality based on the user identity.

3. The method of claim 1, wherein the evaluating comprises determining a pattern of a user and modifying available functionality based on the user pattern.

4. The method of claim 3, wherein the mode is switchable between one or more of: work and play, adults and children, observers, editors, and administrators.

5. The method of claim 1, further comprising requesting information from the network about an application located on a client, receiving the requested information, and using the received information in the evaluation.

6. The method of claim 1, further comprising receiving a policy update sent to the network for distribution of the policy on different client devices.

7. The method of claim 1, wherein enforcing comprises sending commands to an application to control its functionality, or to control content played by the application.

8. The method of claim 1, further comprising dynamically monitoring parameters on a client device and evaluating whether the client device complies with a received policy, and taking corrective action when the policy is not satisfied.

9. A method for enforcing policies across different client devices, comprising:

receiving, in a first client device (110), a policy definition from a network;

receiving the same policy definition from the network in a second client device (112) of a different device type than the first client device (110);

enforcing the policy across the first client device (110) and the second client device (112) by modifying functions available on the first client device (110) and the second client device (112) based on the same policy definition.

10. An apparatus for enforcing policies on a client device, comprising:

a policy service client (120) for receiving policy definitions from a network;

a client policy agent (140) for gathering information about the client device, the information including a usage log; and

a client policy engine (130) coupled to both the policy service client (120) and the client policy agent (140) for receiving the policy definition from the policy service client (120) and information from the client policy agent (140), and for determining whether a function available on the client device complies with the policy definition.