text:
Policies that govern the rights of system assets with respect to other system assets are enforced through dynamic generation of a license at a policy engine in response to a request by an asset to exercise a right with respect to another asset. The system assets are objects within the system to which behavior-regulating policies are applied. Typical types of system assets include users, devices, information files, and processes, and many other types of assets may also be defined. Upon receiving a request to exercise a right, the policy engine obtains predefined policies that are relevant to the request, and obtains factual information for evaluating the current state of transient conditions upon which rights are contingent as expressed in the policies. Through evaluation of the policies, the policy engine generates a license that expresses rights or prohibitions of the requesting asset with respect to another specified asset.
1. A method for regulating the behavior of assets within a system, comprising:
receiving a request for a license governing the exercise of a right by a first system asset with respect to a second system asset;
determining policies relevant to the exercise of the right by the first system asset with respect to the second system asset;
acquiring facts required for evaluation of the policies;
dynamically generating a license governing the exercise of the right by the first asset with respect to the second asset in accordance with the relevant policies and the acquired facts; and
providing the license to the requester of the license.
2. The method claimed in
3. The method claimed in
4. The method claimed in
5. The method claimed in
6. The method claimed in
7. The method claimed in
8. The method claimed in
9. The method claimed in
10. The method claimed in
11. The method claimed in
12. The method claimed in
13. The method claimed in
14. The method claimed in
15. The method claimed in
16. The method claimed in
17. The method claimed in
18. The method claimed in
19. The method claimed in
20. The method claimed in
21. The method claimed in
22. The method claimed in
23. The method claimed in
24. The method claimed in
25. The method claimed in
26. The method claimed in
27. The method claimed in
28. The method claimed in
29. The method claimed in
30. The method claimed in
31. The method claimed in
dynamically generating a second license in response to the request upon a change of a fact required for evaluation of the license; and
providing the second license to the requester such that the second license superceded the previous license.
32. The method claimed in
33. The method claimed in
34. The method claimed in
35. The method claimed in
36. The method claimed in
37. A programmable device for regulating the behavior of assets within a system, the device comprising a computer readable medium storing programming code for performing processing comprising:
receiving a request for a license governing the exercise of a right by a first system asset with respect to a second system asset;
determining policies relevant to the exercise of the right by the first system asset with respect to the second system asset;
acquiring facts required for evaluation of the policies;
dynamically generating a license governing the exercise of the right by the first asset with respect to the second asset in accordance with the relevant policies and the acquired facts; and
providing the license to the requester of the license.
38. A method for creating a policy for regulating the behavior of assets within a system, comprising:
monitoring activities with respect to an asset of the system;
applying metrics to the monitored activities to derive a value for the asset; and
creating a policy for governing behavior with respect to the asset in accordance with the assigned value.
39. The method claimed in
40. The method claimed in
41. A method for assessing the effects of a proposed policy for regulating the behavior of assets within a system, comprising:
defining relationships between the proposed policy and other system policies; and
evaluating the proposed policies and other policies of the system in accordance with said predefined relationships to identify conflicting decisions yielded by the proposed policy and the other policies.
42. A method for assessing the effects of a proposed policy for regulating the behavior of assets within a system, comprising:
defining relationships between the proposed policy and other system policies;
monitoring decisions yielded by the proposed policy in response to one of current system activities and historical system activities without enforcing the decisions yielded by the proposed policy.
43. A method for assessing the effects of a proposed policy for regulating the behavior of assets within a system, comprising:
defining relationships between the proposed policy and other system policies;
monitoring decisions yielded by the proposed policy in response to one of current system activities and historical system activities while selectively enforcing the decisions yielded by rules within the proposed policy.
44. A programmable device for regulating the behavior of assets within a system, the device comprising a computer readable medium storing programming code for performing processing comprising:
displaying a list of system assets owned by a user of the client device; and
providing tools enabling the user to perform at least one of:
associating a predefined policy with a system asset owned by the user;
modifying a rule of a policy associated with a system asset owned by the user;
modifying a policy associated with a system asset owned by the user;
creating a new policy and associating the policy with a system asset owned by the user.
45. The programmable device claimed in
46. A programmable device for regulating the behavior of assets within a system, the device comprising a computer readable medium storing programming code for performing processing comprising:
monitoring the behavior of specified assets within the system; and
displaying reports concerning the behavior of said specified assets.
47 The programmable device claimed in
48. A method for creating a policy for regulating the behavior of assets within a system, comprising:
monitoring activities with respect to an asset of the system;
applying metrics to the monitored activities to derive a value for the asset; and
creating a policy for governing behavior with respect to the asset in accordance with the derived value.
[0001] This application is a continuation-in-part of U.S. non-provisional application Ser. No. 10/339,925 filed Jan. 9, 2003, the entirety of which is incorporated herein by reference.
[0002] This application claims priority under 35 USC �119(e) from U.S. provisional application No. 60/387,737 filed Jun. 11, 2002, the entirety of which is incorporated herein by reference.
[0003] This application is related to U.S. provisional application No. 60/347,124 filed Jan. 9, 2002, and U.S. provisional application No. 60/347,125 filed Jan. 9, 2002, the entirety of each of which is incorporated herein by reference.
[0004] 1. Field of the Invention
[0005] Embodiments of the invention relate to electronic systems such as communication networks, computer systems and electronic monitoring systems, and more particularly to the enforcement of policies governing rights exercisable by system assets such as users and processes with regard to other system assets such as documents, devices and information files.
[0006] 2. Related Technology
[0007] Computer systems and communication networks involve valuable assets. Such assets include information files such as documents and media files, as well as communication channels and devices. A variety of systems for providing security in computer systems and communication networks are known.
[0008] One security system takes a user or device-oriented approach, whereby obstacles are created to prevent unauthorized users from using devices that provide entry to the system. For example, user authentication systems such as computer network passwords and public key encryption may be employed to ensure that only certain individuals are able to use certain devices and obtain access to certain information. However, a user who has been authenticated by providing an appropriate user id and password or an appropriate decryption key is thereafter free to access and distribute information and engage in other unregulated uses of the system. Therefore this approach cannot eliminate threats from malicious users or negligent policy breaches by valid users.
[0009] Another approach to security is content filtering. For example, an email security system may filter the content of email messages sent into and out of the system by searching for fixed character strings within email messages. However, such filtering is done without regard to the identity of the sender or receiver, or to the devices to which and from which the messages are transmitted.
[0010] A third approach to security involves monitoring accesses to information files. For example, document management systems provide a central repository for storing information files, and provide monitoring of accesses to and actions taken with respect to documents. However these systems provide little control over the use of accessed documents, and so once a document is accessed, the user is free to print, make copies of, alter or disseminate the document in an unregulated manner.
[0011] A fourth approach to security is commonly referred to as digital rights management. The conventional digital rights management scheme attaches to each information file a license that specifies the user who may use the information file, where it may be used and how often it may be used. The uses of the information file are thereafter restricted in accordance with the rights expressed in the license. The restrictions may be enforced, for example, by the application that is used to access the information file, or by the operating system of the device that is used to access the information file. However, the conventional digital rights management approach is static and user- and device-centric, in that the rights expressed in the license attached to an information file are customized in advance for a particular user and device, and thereafter remain unchanged for that instance of the information file.
[0012] The aforementioned approaches to security all suffer in that they are not able to apply abstract business-level rules and policies to a variety of users, devices, processes, and information assets under changing circumstances. Rather, the aforementioned approaches are essentially static in the conditions to which they are applicable.
[0013] Embodiments of the invention pertain generally to enforcing policies that govern the rights of system assets with respect to other system assets through licenses that are dynamically generated in-response to a request by an asset to exercise a right with respect to another asset. The rights conferred by the dynamically generated licenses are customized to the particular combination of assets specified in the request in accordance with policies that govern each of the specified assets and the current state of transient conditions upon whose state the exercise of the right is contingent.
[0014] In accordance with embodiments of the invention, a system is treated as including �assets,� which are objects within the system to which behavior-regulating policies are applied. In accordance with a preferred embodiment, system assets may include users, devices, information files, and processes. Other types of assets may also be defined.
[0015] The system preferably includes a policy engine for dynamically generating licenses in response to requests from assets to exercise rights with respect to other assets. In the preferred embodiment, a request typically specifies a user or process that wishes to exercise a right, an information file with respect to which the right is to be exercised, the right that is desired to be exercised, and a device at which the right will be exercised. In response to the request, the policy engine obtains predefined policies that are relevant to the request, and obtains factual information for evaluating the current state of transient conditions upon which rights are contingent as expressed in the policies. Through evaluation of the policies, the policy engine generates a license that expresses rights or prohibitions of the requesting user or process with respect to the specified information file.
[0016] The policy engine of the preferred embodiment is preferably deployed in a policy management server as a server agent that receives requests and provides licenses in response. In other embodiments, a policy engine may be deployed in a client device. Issuance of requests and receipt and enforcement of licenses is preferably implemented in client agents that are resident on or associated with each device in the system. The client agents preferably provide additional services such as a policy creation service that may be used by users to establish policies governing their information files. The server agent preferably provides additional services such as auditing of license generation and policy application, simulation of policy effects for evaluation of proposed policies based on current activities or prior activities, monitoring of the uses of system assets to determine the levels of protection that are appropriate to those assets based on the monitored activities, and automatic creation and modification of policies based on monitored activities.
[0017] Preferred embodiments of the invention are described in conjunction with the following figures, in which:
[0018]FIG. 1 shows an schematic representation of basic components of a dynamic license generation system;
[0019]FIG. 2 shows an exemplary administrative hierarchy of a preferred embodiment;
[0020]FIG. 3 shows an exemplary device hierarchy of a preferred embodiment;
[0021]FIG. 4 shows an exemplary information file hierarchy of a preferred embodiment;
[0022]FIG. 5 shows the creation of policy stacks in hierarchies of a preferred embodiment;
[0023]FIG. 6 shows a standardized form of a rule in a preferred embodiment;
[0024]FIG. 7 shows an exemplary policy in a preferred embodiment;
[0025]FIG. 8 shows information involved in an exemplary license generation process of a preferred embodiment;
[0026]FIG. 9 shows an exemplary deployment of a server agent and client agents for providing dynamic license generation for rights management at client devices in accordance with a preferred embodiment;
[0027]FIG. 10 shows basic processing performed by a client agent and a server agent for requesting, generating and applying a license in accordance with a preferred embodiment;
[0028]FIG. 11 shows an example of an exchange of an asset between two different policy domains;
[0029]FIG. 12 shows a first user interface generated by a client agent for displaying information assets owned by a user in accordance with a preferred embodiment;
[0030]FIG. 13 shows a second user interface generated by a client agent for selecting predefined rules to be applied to information assets owned by the user in accordance with a preferred embodiment;
[0031]FIGS. 14a-14 e show user interfaces generated by a client agent to provide a rule creation wizard for customized creation of rules to be applied to information assets in accordance with a preferred embodiment;
[0032]FIG. 15 shows a first user interface generated by a server agent for selecting parameters of user activity to be monitored in accordance with a preferred embodiment;
[0033]FIG. 16 shows a second user interface generated by a server agent for providing reports concerning monitored activity in accordance with a preferred embodiment;
[0034]FIG. 17 shows a first deployment of a policy engine for providing browser-based access to assets in accordance with an embodiment of the invention; and
[0035]FIG. 18 shows a second deployment of a policy engine for providing browser-based access to assets in accordance with an embodiment of the invention.
[0036] As used herein, the term �assets� describes objects within a system to which behavior regulating policies are applied. In the preferred embodiment, the types of assets include users, devices, information files and processes. In other embodiments, additional types of assets may be defined. For example, records, databases, computational results from hardware or software systems, audit trails, policies, communication paths or signals, representations of monetary value or property, or locations such as physical spaces or objects may also be designated as types of assets to which policies are applied.
[0037] In accordance with the preferred embodiment, �policies� govern the �rights� that a system asset may exercise with respect to another system asset. Policies are comprised of one or more �rules,� each specifying a logical combination of conditions that must be fulfilled to yield a grant or denial of one or more rights. Policies typically represent real-world regulations governing the behavior of people, objects and information. Rules typically make the allowance or denial of a right contingent on attributes of assets involved in the exercise of the right, and on the current state of one or more transient conditions (also referred to herein as �facts�). For example, in a preferred implementation of a policy management system, the rights of a user (one type of system asset) with respect to a document (another type of system asset), such as opening, printing, saving, deleting, or transmitting the document, may be governed by a wide variety of policies that contain rules that make the exercise of those rights contingent on factors such as attributes of the particular user, attributes of the particular document, attributes of the particular device that the user is using to access the document, and the existence or non-existence of other facts such as the time of day or the presence or absence of other assets or permissions.
[0038] In accordance with embodiments of the invention, policies are used to dynamically generate a �license� in response to a �request� (or rights request) from an asset to exercise a specified right with respect to another asset. The policy decisions are based on the existing state of the system at the time that the request is received, and the resulting license reflects rights exercisable by the requesting asset under those existing circumstances. The license takes the form of data representing a right or rights that may be exercised by the requesting asset with respect to the other asset specified in the request. The license is preferably expressed or translated into a format conventionally used for digital rights management, such as XrML or ODRL. The license is used by processes such as applications or operating systems to govern the subsequent behavior of the requesting asset at the device from which the request was made.
[0039]FIG. 1 shows a high-level model of a preferred embodiment of a system for dynamic generation of licenses in response to rights requests through the application of policies. In the preferred embodiment, a policy engine 10 dynamically generates a license 12 in response to a request 14 that specifies a right to be exercised by one asset with respect to another asset. The license is produced by a license generator 16 in accordance with policies that are determined to be relevant to the request. The relevant policies are assembled from a set of stored policies 18, such as a database or a directory, by a policy assembler 20. Each policy is comprised of one or more rules that specify the conditions under which particular rights are granted or denied. Facts that are required for evaluation of the rules contained in the relevant policies are supplied by a fact engine 22 from a set of stored facts 24. The rules of the assembled policies are evaluated in light of the information provided in the request and the relevant facts, and a license is dynamically generated in accordance with application of the rules to the relevant facts. Where there is conflict between the rights granted or denied by various policies, a conflict handler 26 determines which of the conflicting policies prevails.
[0040] An important task in dynamic license generation is assembling the policies that are relevant to a given request, and determining the prioritization among policies where multiple policies are applicable to the request. In the presently preferred embodiment, these tasks are facilitated by providing predefined relationships among policies that dictate their relative priorities.
[0041] In the preferred implementation of the invention in a policy management system, the predefined relationships among policies are implemented through a combination of policy hierarchies and conflict resolution rules. Each policy is associated with a node of a predefined hierarchy, which establishes its priority with respect to other policies within that hierarchy. Examples of three hierarchies used in a preferred implementation of a policy management system are shown in FIGS. 2-4. In this implementation, the hierarchies correspond to the types of assets that are regulated by the system, and include an administrative (i.e., user) hierarchy (FIG. 2), a device hierarchy (FIG. 3), and an information file hierarchy (FIG. 4). The nodes of each hierarchy represent levels of policy-making authority with respect the type of asset to which the hierarchy corresponds. In the administrative hierarchy, for example, the policy-making authority at the CTO (Chief Technology Officer) level has priority over the policy-making authority at the VP of Engineering level and lower levels, while the policy-making authority at the CEO level has priority over the CTO level and all other levels. Each node of the hierarchy is �owned,� either by a specific user, a user having a certain predefined role (e.g. CEO), or a user who is a member of a predefined group (e.g. Engineering group). The owner or owners of a node are entitled to create policies having the level of authority assigned to that node. For example, the user acting in the role of CEO may be the owner of the CEO node, and therefore has policymaking authority that supercedes that of all others in the administrative hierarchy.
[0042] When a request to exercise a right is received, the relevant policies are assembled based upon the assets involved in the request and the policies associated with the node of that asset and the nodes that are superior to the node of that asset within the hierarchy. For example, consider the case in which a user who reports to the CFO requests the right to open an accounting document on his laptop. As shown in FIG. 5, the policy assembly process for responding to this request involves locating the individual assets (the user, the device and the document) within their respective hierarchies, and then collecting the policies applicable at the nodes of those individual assets and at all superior nodes up to the top of the hierarchy. The resulting set of policies collected from each hierarchy is referred to herein as a policy stack and is comprised of all of the policies indicated by the hierarchy to be applicable to the asset. As shown in FIG. 5, each individual asset occupies the lowest level of its respective hierarchy, and may have its own policies.
[0043] While the present example performs assembly of policies in real time in response to requests, in other implementations it may be desirable to perform pre-processing of policies in order to pre-assemble policy stacks for various assets so that a required policy stack may be retrieved more efficiently upon receipt of a request. Further, while the present example assumes that all policies at a given level are applicable to all assets beneath that level in the hierarchy, other implementations may utilize a more complex system in which assets may be organized into groups or may be assigned roles, and the policies at each level of the hierarchy may comprise rules that are conditioned upon particular group memberships or asset roles. In such implementations, the policies at each level of the hierarchy above the asset must be analyzed to determine whether they pertain to the group or role of the asset for which the policy stack is being assembled.
[0044] Policies and the processing of policies in dynamic license generation are now examined in more detail. As discussed above, policies are comprised of rules. The preferred implementation of a policy management system utilizes rules that are expressed in a standardized format as shown in FIG. 6. Each rule associates a directive (i.e. granting or denying the exercise of one or more rights) with a set of clauses that must be satisfied to yield the directive. The clauses are of the type �who� (specifying attributes of the users and/or processes to which the directive applies), �what� (specifying the right or rights to which the directive applies and the asset or assets with respect to which those rights may be exercised), �where� (specifying attributes of the devices to which the directive applies), and �when� (specifying conditions that must be satisfied for the directive to apply). In the rule provided as an example in FIG. 6, users who are members of the accounting user group are explicitly permitted to open documents that are classified as accounting documents at devices classified as mobile devices during business hours.
[0045]FIG. 7 shows an example of a policy that includes the rule of FIG. 6 and other rules. The policy of FIG. 7 includes identifying information including a title, identification of the policy owner (in this case, the user having the role of CFO), the hierarchy to which the policy belongs, and an identification of its parent node in the hierarchy which establishes the predefined relationship of the policy within the hierarchy. The policy further includes four rules that together comprise the policy of the CFO regarding the times at which users may access accounting documents. In the preferred implementation as shown in FIG. 7, rules are prioritized within each policy by ordering them in terms of priority. Accordingly, the effect of a policy on a given rights request may be analyzed by sequentially evaluating the rules of the policy beginning with the first rule. Each rule is evaluated only if evaluation of preceding rules does not yield a decision.
[0046]FIG. 8 shows an example of the application of the policy of FIG. 7 in the license generator in response to a rights request. In the example of FIG. 8, it is assumed for purposes of illustration that the policy of FIG. 7 is the only policy determined to be relevant to request. The request received by the policy engine 16 specifies a user, a right to be exercised, a document with respect to which the right is to be exercised, and a device at which the requester wishes to exercise the right. In particular, the user rsmith wishes to open the document 1 Q2003�10Q.doc at the device laptop�104. Using the policy hierarchies as described above, the policy assembler retrieves the policy Accounting Document Access Times, and supplies this policy to the license generator. The various facts required for evaluation of the rules are obtained from the fact engine, including the respective groups of the user, the document, and the device, and the current time and date. The rules are evaluated in order beginning with the first rule. In the present example, the first rule does not yield a decision because the current time is not within business hours. The second rule is then evaluated, but does not yield a decision because it only grants a read only right, and the request is to open the document. The third rule is then evaluated, but does not yield a decision because the requested right is to open the document at a mobile device, whereas the third rule grants open rights to desktop devices. The fourth rule is then evaluated. This rule is effectively an �else� rule that denies all access when access is not allowed under any of the three preceding rules. Therefore, in this example, the applicable policies do not permit the exercise of the requested right, and so the policy engine generates a license that denies the request of the user rsmith to open the document 1 Q2003�10Q.doc at his laptop.
[0047] While the example of FIG. 8 involves only one policy, requests in typical implementations will be governed by many different policies that may be contained in several different policy stacks. In such instances, the respective policies of each policy stack are evaluated sequentially beginning with the lowest priority policy. The decisions yielded by each policy are subservient to decisions yielded by higher ranking policies. For example, while the policy owned by the CFO prevents opening of the requested document in the example of FIG. 8, a higher level policy may override that policy under conditions that exist at the time of the request, and in that case the denial under the policy of FIG. 7 is overridden by the grant provided by the higher ranking policy.
[0048] Conflicts among decisions yielded by the different policy stacks applicable to a request are resolved in accordance with conflict resolution rules provided in the conflict handler of the license generator. Conflicts may be resolved, for example, based on a predefined ranking among the owners of the conflicting policies, or on other factors.
[0049] As noted above and as illustrated in FIGS. 7 and 8, policies may be expressed in terms that are specific to particular groups of assets such as user groups or user roles, device groups, or file groups. As a result, the collection of relevant policies may utilize knowledge of the groups or roles associated with the assets specified in the request. This type of policy collection may be implemented in a number of manners. In one implementation, asset group and role affiliation may be obtained from the fact engine based on the assets specified in the request, and may be supplied to the policy assembler for use in policy assembly. In another implementation, group and role affiliations may be supplied as part of the rights request.
[0050] The processes and functions involved in dynamic license generation are preferably implemented in an agent at a server that communicates with devices in the system or in an agent associated with a device, while the processes and functions involved in issuing requests for licenses and regulating the behavior of assets in accordance with licenses is preferably implemented in agents that reside on or are associated with each device within the system. A schematic diagram showing basic elements of an embodiment providing license generation at a server is provided in FIG. 9. In this configuration, a policy management server 30 communicates through a network 32 with system devices 34. A server agent 30 in the policy management server 30 receives rights requests from the devices 34 and responds by transmitting dynamically generated licenses to the devices 34. The server agent also preferably provides other services such as presence and availability management, further details of which are provided in the documents incorporated herein by reference. Within each device, a client agent 36 communicates with the server agent to request and receive licenses. The client agent also preferably provides other services such as location reporting, further details of which are provided in the documents incorporated herein by reference.
[0051] The basic processing performed by the client agents and server agent during license request and generation are illustrated in more detail in FIG. 10. Initially a client agent resident on a device detects (40) an attempt by a user to exercise a right with respect to an information file such as a document, application, email message, spread sheet, image, audio or video file, or other type of information file. Such detection is typically provided by filters that monitor the activities of drivers in the client device such as file system drivers, network drivers and device drivers. The types of rights exercises that are monitored may be tailored to the specific implementation, but generally include actions such as opening, reading, writing, deleting, executing, backing up, restoring, sending or receiving, editing, embedding, extracting, copying, transferring, loaning, printing and exporting. Upon detection, the attempt is interrupted (42), such as by suspending the execution of an application or by trapping a request to exercise the right. The client agent then typically checks (44) to determine whether there is a valid local license governing the rights of the user with respect to the information file. For purposes of the present example, it is assumed that there is no valid local license, however this check may result in other determinations that lead to a different set of actions, as discussed further below. Upon determining that there is no valid local license, the client agent sends (46) a request to the server agent that specifies the user, the information file, and the right that is attempted to be exercised.
[0052] Upon receiving (48) the request, the server agent assembles (50) the policies that are relevant to the request. As discussed above, policy assembly is preferably facilitated by hierarchical policy structures corresponding to each type of regulated asset that allows the creation of policy stacks for evaluation. However, other manners of policy assembly utilizing other forms of predefined relationships may be utilized, as discussed herein. In addition to assembling policies, the server agent acquires (52) facts that are required to evaluate the assembled policies. Facts may be assembled for use in policy assembly and for use in policy evaluation. A wide variety of facts may be acquired. Typical facts that may be acquired include group memberships and roles of users, information files and devices. Other types of facts that may be acquired include current information made available from other applications and systems, such as clocks, calendars, physical security controllers, card readers, biometric scanners, or agents that monitor system or user states or behaviors. Upon acquiring the necessary facts, a decision is generated (54) in accordance with the applicable policies. Decision generation preferably involves evaluating the rules within each policy, beginning with the highest priority rule within each policy, and beginning with the lowest ranking policy in each policy stack. Decisions yielded by higher ranking policies override conflicting decisions of lower ranking policies within the same policy stack, and conflicts among the decisions produced by each policy stack are resolved through the application of additional predefined conflict resolution rules. A license is then created (56). The license represents the decision generated in accordance with the relevant policies. The license is preferably represented in a known rights management format such as XrML or ODRL, but may be represented in another form. The license is sent (58) to the client agent in response to the client agent's request. Upon receiving (60) the license, the client agent allows or prevents (62) the exercise of the right by the user in accordance with the license.
[0053] While the example of FIG. 8 shows a request that includes minimal information identifying a user, document, action and device, in other embodiments a variety of additional information may be included in the request. One type of information that may be included is an indication of a time constraint, the priority of the request or of the quality of service required in responding to the request. Since the policy engine will typically handle large numbers of requests, license generation may be slow in some instances. Specification of a time constraint, priority or required quality of service allows the policy engine to prioritize the order in which it responds to requests. such requests may be limited to certain types of users and may be subject to confirmation of the credentials required for such a request.
[0054] Another type of information that may be included in the request is a format in which the license is to be generated. Several formats for license data such as XrML and ORDL are currently known, and the type needed may depend on the application or operating system that is operating on a client device. While the examples herein have assumed for simplicity that the license generated by the policy engine represents a single decision regarding the exercise of a single right with respect to a single asset, in other implementations the license may be more expansive in terms of both its scope and its duration. For example, rather than addressing a single right, the license may take the form of a decision table that governs both the exercise of the requested right and other rights that would commonly be requested by the user with respect to the specified asset or other related assets. For example, in response to a request to view the contents of a file system folder, a license may be generated that addresses the user's rights with respect to all files contained in the folder. To generate such a license, an appropriate decision table may be constructed in the server agent during the policy analysis phase of processing, and the license may be generated in a form that represents all of the scenarios and decisions reflected in the decision table. Such a license may then be used locally by the client agent to regulate the user's activities with respect to files contained in the folder. The license may also be used for additional purposes such as regulating file availability by preventing display to the user of any files to which the user has no rights.
[0055] The license may also be provided with an expiration such that it may be retained and used locally for a period of time. The expiration may be based on a fixed period of time, or may be contingent on events such as changes in facts whose existence was a condition precedent to the generation of a particular right or rights authorized by the license. In the latter type of license, the monitoring of changes of such facts may be performed in the server agent, with updated facts, license expiration notices or new licenses being pushed to the client agent as necessary, or the client agent may monitor facts by requesting fact updates from the server agent and invalidating a license when a necessary condition is no longer satisfied.
[0056] The examples provided above have assumed that the exercises of rights have occurred entirely within a single policy domain. However, in some applications, evaluation of policies from more than one domain may be required. FIG. 11 shows an example of an interaction that involves multiple policy domains. In this example, an electronic document is sent from a company to its client. The company and its policies constitute one policy domain, while the client and its policies constitute a separate policy domain. In other words, each domain has its own sets of policies that regulate the behavior of assets within the domain. However, in a case such as that illustrated in FIG. 11, an asset of one domain attempts to exercise a right over an asset from another domain. For example, a user in the client domain may wish to modify the document received from the company domain. In this case, rights with respect to the document should be analyzed in view of both the client's policies and the company's policies. To facilitate this type of policy analysis, the policy management server in the client domain must be made aware that the document is an asset that belongs to a different domain. This may be implemented in a variety of manners. In one implementation, the document may be accompanied by an identifier of the domain that it is owned by, and upon detection of this identifier at the policy management server, communication is established between the servers to supply all relevant policies to the receiving domain. In another implementation, policies accompany the document that is transmitted to the new domain. These policies may comprise a complete set of policies that are relevant to the document, or may comprise an incomplete set of policies that, for example, cause the server of the receiving domain to inquire for additional policies.
[0057] The license request, license generation and rights regulation processes described above are background processes that are generally not visible to users during normal system operation. However the client agent and server agent also preferably provide a variety of user services. FIGS. 12, 13 and 14 a-14 e show user interfaces generated by a preferred client agent to allow a user to create policies governing information files owned by the user. FIG. 11 shows a user interface that allows the user to view information assets owned by the user. The information assets are located using a file tree display area 70 and a file list display area 72. The list selectively displays files over which the user has policy making authority based on factors such as the user's group membership and role. An icon 73 is used to indicate files that are controlled by policies owned by the user. Selected files are displayed in a selected files window 74 from which they may be operated on to create or remove policies. As seen at the top of FIG. 11, tabs allow policy creation to be performed with respect to both file system files and email messages.
[0058]FIG. 12 shows a user interface generated by the client agent upon initiation of a policy creation process through operation of a select policy button provided in the preceding user interface. This user interface includes a policy display section 76 that displays predefined policies that may be applied by the user to files owned by the user. The predefined policies are typically designed to reflect specific information access and security policies that have been formulated by the organization in which the system is implemented, and the predefined policies are made available to the user selectively based on factors such as the user's group membership and role. It is preferred that sets of policies are formulated for both local application to single files, and global application to all files of a particular type that are owned by the user.
[0059] The user interface of FIG. 12 further includes a field 78 for displaying the name of a selected policy, a field 80 for describing the types of files encompassed by the policy, a field 82 naming the policy owner, and a field 84 naming the policy administrator. A rules display 86 provides a list of the rules that are contained within the predefined policy, and an explanation display 88 provides a plain language explanation of a rule that has been selected within the rules display. Each rule may be individually selected for editing or deletion.
[0060] Operation of a create button provided in the user interface of FIG. 13 initiates a rule creation wizard that presents the user interfaces shown in FIGS. 14a-14 e for creating a customized rule to be included in an existing policy or a new policy. The first wizard user interface shown in FIG. 14a presents fields for naming the rule 90 and selecting a directive 92. A display area provides a plain language description of the selected directive. A field 96 is also provided that may be checked to indicate that accesses to the assets protected by the rule should be tracked. This and other audit trail features in accordance with the invention are discussed in more detail below.
[0061] The next user interface of the wizard shown in FIG. 14b provides displays of lists of users 98 and user groups 100 that may be selected for inclusion in the �who� portion of the rule, and a separate display 102 of selected users and groups. A display area 104 at the bottom of the user interface provides a plain language version of the rule as it is constructed.
[0062] The third user interface of the wizard shown in FIG. 14c provides a display 106 of available actions (rights) that may be selected for inclusion in the �what� portion of the rule, and a separate display 108 of selected actions.
[0063] The fourth user interface of the wizard shown in FIG. 14d provides displays of lists of devices 110 and device groups or roles 112 that may be selected for inclusion in the �where� portion of the rule, and a separate display 114 of selected devices and groups.
[0064] The fifth user interface of the wizard shown in FIG. 14e provides a display 118 of available conditions that may be selected for inclusion in the �when� portion of the rule. An adjacent display area 120 presents fields that may be filled in for the particular condition selected. A further display area 116 shows the selected conditions and logical operators used to relate the conditions. Update, save and delete buttons are provided for initiating corresponding features. When all desired conditions are selected, the operation of a finish button saves the rule in the corresponding policy, and the user is returned to the user interface of FIG. 13, where the new rule will be displayed along with other rules in the same policy.
[0065] FIGS. 15-16 show examples of user interfaces generated by the server agent in accordance with the preferred embodiment for providing tracking of user activities with regard to various assets. The user interface of FIG. 15 allows a user to select a user, device or file for which activity is to be monitored. The user interface includes a display area 122 that lists system assets including users, devices and files. Assets selected from the list for monitoring are shown in an adjacent display area 124. A list 126 of monitoring policies allows the user to select a particular type of monitoring to be performed. Additional display areas 128, 130 allow the user to select particular activities to be monitored, and selected activities are listed in adjacent display areas 132, 134.
[0066] The user interface shown in FIG. 16 allows the user to view reports concerning monitored activity. A display area 136 displays a particular type of report as selected from a list 138 of available report types.
[0067] Monitoring activities such as those shown in FIGS. 15-16 may be applied in other ways in addition to generation of simple activity reports. For example, in one preferred implementation, metrics are applied to the activities performed with regard to assets to evaluate the relative value of those assets and to generated policies for those assets based on their determined values. For example, documents created and used for significant amounts of time by users having high ranking roles may be identified based on these activities as documents that have high value and therefore should receive a certain level of policy protection. In preferred implementations, such determinations may be used to associate predetermined policies with such assets, or to create new policies for such assets, or to revise current policies associated with such assets.
[0068] Other services preferably provided by the server agent include testing of policies prior to their actual implementation. One type of testing that is preferably provided by the server is conflict identification, wherein conflicts with existing policies that will be caused by a proposed policy are identified through processing in the policy engine. This allows revision of proposed policies for better integration with other policies. Another type of testing that is preferably provided is evaluation of the effects that proposed policies would have on user activity using ongoing or historical activity data. Testing using a data set representing real user actions allows identification of undesirable policy effects without actually enforcing the policy on active users, allowing revision of proposed policies to better suit organizational needs.
[0069] While the implementations of the invention described to this point have assumed that the policy engine is deployed at a server that communicates with client devices through a network in a conventional client-server arrangement, in other implementations it may be desirable to implement that client agent as a browser plug-in. FIG. 17 shows one example of how such a deployment may be facilitated. In this deployment, a policy engine 140 communicates with a web server device comprising a portal application 142, back end applications 144 and a database 146. A browser application 148 interface with the web server through a network 150. A plug-in client 152 in the browser application interacts with the policy engine at the server to obtain licenses for accessing content provided by the web server.
[0070]FIG. 18 shows an alternative deployment of policy engine functionalities for browser-based clients. It is conventional practice to cache copies of content files at locations at the network edge so that the content can be obtained from a cache that is relatively close to the requester. Under such circumstances, it is not desirable to provide a policy engine only at the server that serves as the origin of the content, since this will vastly increase traffic at that server. Accordingly, in the embodiment of FIG. 18, a policy engine 154 is provided in conjunction with a content cache 156 at the network edge. Policies for content are created by the content creator 158 using a client agent 160, and are encapsulated with the content in the cache. When a request for particular content is received at the cache from a browser application 162, the request is evaluated by the policy engine 154 in accordance with the policies encapsulated with the content.
[0071] The use of implementations of the invention for document security and policy management is highly applicable as a solution for several current needs. One such application is for control of financial documents in publicly traded corporations in accordance with the Sarbanes-Oxley Act of 2002. Some of the regulations established by this act require publicly traded companies to provide selected financial documents to two external auditors within a specified time frame on an annual basis, and requires financial documents to be archived and maintained for a period of seven years. The type of documents to be made available would generally be considered confidential and subject to destruction. Using the policy based controls described herein, policies may be easily created and implemented to prevent deletion of all such documents for seven years, and to provide tightly controlled access to external auditors within fixed periods of time, despite the confidentiality of those documents. These policy changes are simply implemented using the policy creation tools described herein, and may be given precedence over other potentially conflicting policies through appropriate definition of the relationship of the policy to existing policies, such as by establishing the policy at a superior location in a policy hierarchy.
[0072] Another current need addressed by the preferred embodiment of the present invention is protection of patient healthcare records in accordance with the Health Insurance Portability and Accountability Act, commonly referred to by its acronym HIPAA. HIPAA establishes a complex set of record regulations that must be adhered to by health insurance providers and medical service providers. For example, both medical service providers and health insurance providers must maintain the confidentiality of patient records, and must maintain audit trails showing all actions taken with respect to such records. In addition, patients must be made aware of any time a party is provided with a copy of their records. The preferred embodiment of the present invention may be adapted to treat patient records and their audit trails as assets and to regulate actions taken with respect to those assets through the creation of appropriate rules and polices as described herein.
[0073] A further current need addressed by the preferred embodiment of the present invention is compliance with 21 CFR part 11 by pharmaceutical companies. 21 CFR part 11 establishes standards for record retention by companies performing drug discovery research and clinical testing. For example, companies are required to create audit trails for all digital information, to maintain all records from research and clinical trials and make them available for audit on demand, and to maintain records in a secure and encrypted form. Documents and audit trails may therefore be treated as assets to which appropriate policies are applied satisfy each of these requirements.
[0074] Other similar implementations may be tailored to satisfying other regulatory and compliance rules, such as those of the Federal Information Privacy Standard or the ISO 17799 standard for information security.
[0075] The embodiments discussed herein have been described as performing policy evaluation through a collecting process that utilizes predefined rule-based relationships among policies. However, in some instances the large number of policies involved may make such processing extremely burdensome. In such cases it is desirable to implement policy collection schemes that optimize collection and reduce the number of irrelevant policies inspected. One optimization approach is to use a probability based system to identify the policies most likely to be relevant to a given interaction of assets. For example, a codebook may be produced for a combination of a user, device and a file. The codebook presents a probability of relevance for each policy maintained by-the system. Accordingly, when a request is received, the codebook for the combination of assets specified in the request is consulted to determine the policies having the highest probabilities of relevance to the request, and those policies are assembled and analyzed. Initial codebooks may be generated through preprocessing, such as through use or analysis of historical data, and their relevance scores for each policy may then be updated as the policies are used in decision making in response to actual requests.
[0076] While the preferred embodiments described herein focus on the application of the invention to policy management systems, alternative embodiments of the invention may be directed to regulation of other types of assets. In general terms, the invention may encompass the regulation of any type of asset for which policies may be defined and to which behavior regulation may be applied through the operation of electronic or data processing devices. For example, while the preferred embodiment regulates user access to documents, alternative embodiment may regulate, for example, user access to physical spaces or objects, based on policies governing access to the spaces or objects, and the satisfaction of expressed conditions by current facts, such as the presence of particular individuals, a current time that is within defined access times, or the absence of prohibitive conditions such as transient high security conditions.
[0077] The preferred embodiments set forth herein are intended to describe the best modes presently known to the inventors and to provide a thorough understanding of the present invention by way of specific examples. However, these embodiments are particular to specific implementation goals, and those skilled in the art will be able to devise further embodiments which, although not explicitly described or shown herein, embody the principles of the invention, and are included within its spirit and scope. Furthermore, all examples and conditional language that have been recited herein are principally intended to aid the reader in understanding features of certain implementations of the invention and are not to be construed as limiting the scope of the invention to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. It is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure. Thus, for example, it will be appreciated by those skilled in the art that the block diagrams herein represent conceptual views of programmable devices and programmed processes that embody the principles of the invention. Similarly, it will be appreciated that flow charts, flow diagrams, pseudocode and the like represent various processes which may be substantially represented in computer readable media and so executed by a computer or processor. The functions described and illustrated herein may be provided through the use of programmable devices employing a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which may be shared. The functions described and illustrated herein may also be distributed across multiple programmable devices. Moreover, explicit use of the terms �device�, �server�, or �computer� should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Thus, while the embodiments illustrated in the figures and described above are presently preferred, it should be understood that these embodiments are offered by way of example only. The invention is not limited to a particular embodiment, but extends to various modifications, combinations, and permutations that fall within the scope of the appended claims and their equivalents.
Referenced by
Legal Events
Original Image


text:
How To Lose Weight Without Using Medicine
How To Lose Weight Without Using Medicine is our topic in this article where you will find health,Health And Fitness,how to lose weight,how to lose weight without pills,health tips,lose weight.While you age group you slowly but surely begin to become conscience regarding your weight. A person rapidly be aware that your overall health is vital and also acquiring good insurance coverage will be hard when you look poor as a general rule health care insurance corporations gives you unpleasant premiums. Continue reading

subset: commoncrawl


text:
Deep Learning Representations
Free registration required
Executive Summary
In this webcast, the presenter will give an introduction to the area of Deep Learning, to which he has been one of the leading contributors. It is aimed at learning representations of data, at multiple levels of abstraction. Current machine learning algorithms are highly dependent on feature engineering (manual design of the representation fed as input to a learner), and it would be of high practical value to design algorithms that can do good feature learning.
- Format: Webcast
- Size: 0 KB


text:
'The Mayns of Balnar Moon' by alimac30
Mission title: The Mayns of Balnar Moon
Author: @alimac30
Project ID: ST-HU34EAKM7
Faction: FED
Minimum rank required to play: Any rank
First published: 22 April 2012
Five months ago, Balnar Moon was plunged into icy darkness as it began passing through the shadow of a gas giant. The ocean covering the moon's entire surface froze solid and the only structure a lonely Starfleet research platform was left to a small team of caretakers. Now it's time for Starfleet to return... but are the caretakers the only things waiting in the cold on Balnar Moon?
Awesome news!
Excellent News. I've been waiting for your newest creation. Cannot wait to try it. Plan on it tomorrow after work. Really looking forward to seeing your next awesome group of maps and locations. You definitely have the gift of designing unique locations and stories. :)
Is it tomorrow yet, lol.
Craig aka: Duke-of-Rock
Another extraordinary mission from one of the Foundrys best authors! As usual, your mapwork is incredible; the tight, confined spaces and maze-like architecture of the station evoke a powerfully claustrophobic atmosphere. The story is haunting and emotional. For curiositys sake I decided to go right instead of left at the end of the missionand I instantly regretted it. Despite the fact that this is just a game, I still felt guilty about my choice, and that is a testament to strength of your characters.
I read the blog describing your creative process with this mission, and I appreciate your courage in tackling a difficult issue like the stigma surrounding mental illness. This mission achieves the same standard of excellence established by the others in your library. My only real complaint is that I had to wait four months for its debut! Thanks for sharing your talents with the STO community.
It does sound like the shining, but I'm intrigued.
I just played your mission. Wow loved all the explosions!
I was really feeling like the whole place was sinking. Terrific maps and I enjoyed your storyline.
Kudos! Another quality UGC mission indeed.
Thumbs Up .
Very Big Thumbs Up !!
Absolutely wonderful mission.
There had better damned well be a sequel. Seriously.
How could I have missed this thread for the last 3 days, I now have to wait 12 hours until STO playtime. I really wish they could implement a 'follow' function for authors that would send you a message when new mission is released from them.
11.59 minutes to go...
superb mission. i highly recommend everyone play it. top class all the way.
Another excellent mission, especially from a technical standpoint. It was a blast to play.
I was playing on Advanced and some of the encounters were quite challenging as mobs spawned around my team which was a little frustrating.
This mission is going to be featured on our next BroadcastUGC!
Come and join us live on air with Alimac30 on Sunday the 29th 3pm PDT, 6pm EDT, 10pm BST and 8am Monday AEST
|All times are GMT -7. The time now is 04:04 PM.


text:
Todd in CA
I ride at a very rugged remote OHV called Divide Peak. It's all rocks, sand, and sharp thorny bushes. Very desert like, extremely rough, and very hard on tires. I get flat tires quite frequently. I use this product with the Tubliss system. It works fantastic and keeps me from getting stranded out in the wilderness. The slime works automatically fixing all the small punctures that I get. I usually don't even know that I get them; the slime just does it's thing and seals the tire. If I get a puncture that is too large for the slime to seal, I carry tire plugs and CO2 cartridges. Between the two, I feel confident that I wont get stranded out in the boonies. Gives me great piece of mindRead All Reviews
JEFFREY in CO
What can you buy for 39 cents? These are great.Read All Reviews
JEFFREY in CO
These do what they're designed to do but I gave them 4 stars because I think they are a bit overpriced for what they are.Read All Reviews
Shawn in CA
I get about two more rides from the rear tire each time I knobby knife it (I ride mostly rocky trails). Usually knobby knife the rear 2 or 3 times before the knobs are toast. If you are patient, you can also knife the braking edge of the knobs. Usually takes me about 12-15 minutes to do one tire. You can also squeeze a little extra life out of the front tire if you sharpen up those knob edges, but it does take a bit longer to knife than the rear. Overall I consider this a great product.Read All Reviews
Randall in OK
it work way better then the small tire irons have enough leverage to get bead over rim need these a long time ago don't know how I changed tires with the small spoons get them you won't be sorryRead All Reviews
kelly in ID
Simple and efficient used them for years and will continue toRead All Reviews
In addition to having the ATV tire tubes you need, Rocky Mountain ATV/MC has a complete inventory of ATV tire tools and accessories to keep your ATV tires in pristine condition. Using the wrong tools to replace or maintain your ATV tires could result in further damage, so make sure you have tools that were specifically made for ATV tires like a K&L Tire Tamer, Knobby Knife Rubber Knife, Motion Pro Bead Buddy Tire Tool and a Motion Pro Steel Tire Iron.
We also have every ATV tire accessory you can think of like rim protectors, wheel weights, racing tire pens, tire pressure gauges, spare tire repair kits, stem cap lights, valve caps and much more. One of the benefits of shopping for ATV tire tools and accessories at Rocky Mountain ATV/MC.com is our customer reviews. Check out what riders just like you have to say about the ATV accessories we carry and learn insightful tips from them as well.
We know you don't want to spend a lot of time repairing or maintaining your tires which is why all of our ATV tire accessories are ready to be shipped. Get the ATV tire tools and ATV tire accessories you need fast, so you can get back to riding your ATV even faster.


text:
Hardwicke and Hirsch Reteam For Supernatural Hamlet Thriller
To sparkle, or not to sparkle. That just may be the question when Catherine Hardwicke takes on some of William Shakespeare's most well-known material and makes it into a "modern-day supernatural thriller." The Twilight director is apparently teaming back up with Emile Hirsch (the two worked together on Lords of Dogtown) for this adaptation of Hamlet, which was initially Hirsch's idea. Here's more:
Hardwicke and screenwriter Ron Nyswaner (Philadelphia) are working feverishly to transport the drama to a small East Coast liberal arts college where Hamlet's father is the president. The story will begin with Hamlet (Hirsch) returning home for his father's funeral, only to learn that his uncle, who has taken over his father's post, is responsible for his father's murder.
At first, Hardwicke thought the idea was "scary and crazy," but now she's armed with some ideas on how to go about this project. I appreciate what Hardwicke did with Thirteen, it's just the "supernatural" part of this news that seems a little dicey after Twilight. What do you think?
- The Veep actress is in talks for a new version of the Swedish film — Vulture
- Kendrick Lamar's album made a mark on history — HuffPost Entertainment
- This Marvel character will not be appearing in the new Avengers movie — Hitfix
- That time Sarah Jessica Parker forgot Sex and the City existed — Moviefone
- The 6 most unintentionally creepy sitcom characters — Cracked
- If you love Downton Abbey, you need to watch Call the Midwife — BuddyTV
- 25 valuable lessons you learn while watching TVD — The Vampire Diaries
- Watch the trailer for Blunt Talk, starring Patrick Stewart — Splitsider
- Inside Vin Diesel's emotional interview about Paul Walker — POPSUGAR Celebrity & News


text:
By entering this site you are agreeing that you are 18 years of age or older.
The best medley of melons infused with a hint of cream as well as a refreshing hint of mint. A blast of relaxing and sweet flavors balanced to perfection.
Showing reviews 1-10 of 161 | Next
Posted by Ivan on 27th Mar 2015
I have tried several Melon flavors but this is by far my favorite, thank you so much...!!!
Posted by Chadler Valdez on 22nd Mar 2015
Got this juice based on reviews and was not dissapointed. Easily one of my ADV this juice is mouthwatering. Customer service amazing as always with GLV. Thanks guys !!!
Posted by Brian on 26th Feb 2015
Melon Boba is a legend and one most people are already familiar with. That said, its one you must try for yourself. The description is accurate; if you like melons you will enjoy this vape.
Posted by Michael on 25th Feb 2015
this one made the ADV rotation, it's just good !! perfect blend of fruit and ment.
Posted by Unknown on 12th Feb 2015
It was mind-blowing. This juice was the best thing to enter my lungs throughout my journey. From cigars, to cigarettes to Shisha, I have not enjoyed anything as much as I did Melon Boba. I can easily recommend it to anyone and everyone. It was sweet and realistically fruity with a tiny hint of menthol. It was so good, I was enthusiastic to let all of my friends try it. Seriously, if you give vaping a try and think it's not for you, make sure you try this juice first. This was the most realistic analogue alternative I could have ever imagined.
Posted by Unknown on 4th Feb 2015
Can't get enough.
Posted by Ahmed Rami Omar on 16th Jan 2015
what can I say , you cant get enough of this juice , I always use 2 or 3 flavors a day so I don't get fed up but this one is my favorite every day , I really cant get enough of it , the only thing is u need to let it steep first which sometimes is very hard for me , love it as 12MG nic , best ever
Posted by firstname.lastname@example.com on 14th Jan 2015
For me this is by far the best flavour that GLV has to offer because it just agrees with my palette perfectly!
Posted by Vesselin Anguelov on 13th Dec 2014
Alright alright. First order and I am sold. Good Life Vapors has superior customer service and incredible quality juice. Very good job guys
Posted by Richard Michael on 5th Dec 2014
I've been Vaping on & off for about 2 years. Just could not seem to shake "real" smokes.... I'd find various flavors I thought I liked from OTHER companies... Frequently there would be quality control issues with other Juices... Or I'd find one that was just OK, but I had never found a Juice that I could HONESTLY ... Vape All Day! Also I was having an impossible time finding a nice fruit type juice that did NOT taste artificial ... or sickening sweet.... or taste OVERLY CANDY LIKE.... A friend recommended Melon Boba to me. I figured .... what the hell? I'll give this a try. I filled an Aspire Nautilus tank up with Melon Boba. Threw it on a Vamo V6 set to 8 watts... and fired. The 1st thing I noticed was how GOOD this Juice smells! It smelled INCREDIBLE! After about 10 Vapes.... I had to pull my chin up off the floor. THIS JUICE WAS WITHOUT A DOUBT THE SINGLE BEST JUICE I HAD EVER VAPED! I was officially BLOWN AWAY! The MELONS IN THIS JUICE ARE SO GOOD YOU MIGHT BE TEMPTED TO DRINK THIS STUFF! MELON BOBA has 3 distinct flavors that I am getting. Cantaloupe, Honeydew Melon & Watermelon! There is also a pleasant slight tobacco undertone that I get on the exhale... These MELON flavors are SO REAL .... So NOT Chemical that it's almost impossible to fathom. This is as REAL AS IT GETS! The 3 flavors are all distinct ... yet BLEND into an incredible combined taste! This is a ... crisp? Light.... beautiful flavor that you can go back to AGAIN & AGAIN & AGAIN! It will become your instant all day vape. I ordered 30ml on the initial order. The day I got this I ordered another 50ml. Within a few days I plan on getting 100ml order placed! Final thoughts... this Juice was SO AMAZING right out of the mail box ... makes me wonder how much BETTER it will be after it steeps??? Also... If it tastes this good in a TANK.... I can't wait to throw this in a Vulcan RBA and DRIP IT! Hard to imagine that it COULD get any better! At 12mg Nic... This gives a nice throat hit and the vapor production on a tank was fantastic! This is so freaking fantastic that on my 100ml order I'm dropping down to 6mg of nic because I WANNA CHAIN VAPE THIS ALL DAY LONG! I'll end this with 3 words. BUY THIS JUICE!
Showing reviews 1-10 of 161 | Next


text:
Swinging Robot Excels At Wall-Climbing 54
from the creepy-in-the-good-sense dept.
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
And then of course there is "Big Dog" which can take a flying kick and keep walking.
But not from Chuck Norris, and that's humanity's trump card.
Swinging Robot
Does it try to sleep with my wife?
Your wife? Of course not. You might want to hide your smoke detectors though.
Maybe we should build an army of Chuck Norris clones off-planet just in case of Big Dog becoming self-aware, Chancellor?
The universe seems neither benign nor hostile, merely indifferent. -- Sagan