This invention is related to software that facilitates application customization, and more specifically, a rules abstraction architecture that facilitates application customization by an end-user.
Computers and computing have always divided the world of users into two classes: the knowledgeable “high priests” who know how to use computers in complex ways, to shape programs and enable behaviors that are valuable and rich; and the novice users, who are at their mercy, denied easy or cheap access to knowledge or information or the education to make computers serve their needs well. However, major breakthroughs in computing have occurred when technology has broken down some of these barriers to access.
In the world of the mainframe, computers were too expensive for all but the largest businesses to afford. The advent of mini-computers, and then personal computers (PCs), broke down the cost barrier and made computers available to small businesses and individuals.
In the 1980's, programmers struggled to build graphical user interface (GUI) applications, and without rich and consistent GUIs, were unable to build valuable applications for PC users. The Visual Basic revolution and the use of controls and event-based GUI construction enabled a whole army of application developers who could easily build rich applications. This also established a virtuous cycle with many more end-users who could exploit these applications.
In the 1990's, end-users struggled to overcome a lack of access to information. The growth of the Internet and the web transformed this space, making almost all valuable information accessible to anyone with a browser. However, there are still significant barriers to overcome.
Computing is not personal. There is very little about a PC that is truly “personal”. The data on the local disk is personal. But the behavior of the machine (what it does on behalf of the user) is close to identical across millions of users. Despite owning an amazingly powerful general purpose computer, the average user treats it as a static tool, useful as a communication end-point, useful as a search entry-point, useful to execute some canned mass-market applications, but otherwise incapable of any “personal computing” in the true sense of the word. The personalization capabilities available in current applications just scratch the surface of what is possible and desirable.
Computing is manual. Consider the daily routine of most typical computer end-users. The PC gathers information, reacts to communications, makes decisions and acts upon them—initiates or responds to communications, organizes information, buys and sells goods, travel, etc. Computers have improved communication between people, and have improved access to information. However, PCs have done little to relieve the end-user's responsibility to make decisions and act upon them at the right time. In the business world, there are decision support systems for major organizational decisions. Still software does not help the average PC user in the many everyday, yet important and personal decisions.
Computing is not contextual. Computer software typically provides optional settings that are rather static and unrelated to the actual context of the user (e.g., “Why should I have the same set of messaging buddies at work and at home?”).
Thus, users are still in the “pre-industrial age” of software by being increasingly trapped in the tyranny of manual information processing—spending hours every day sifting, sorting, searching, and reacting to e-mail, documents and other personal data.
End-user software should be personalized, aware of the needs and preferences of the end-user, acting specifically in a manner guided by those needs and by the user context. Further, computer systems and software should provide every end-user with a personal executive assistant who works 24 hours a day gathering and sifting information of interest to the end-user, and reacting to that information.
The most valuable class of end-user computing activity deals with information flows and search, such as ensuring the end-user sees relevant information (e.g., “Tell me if there is a school closing due to bad weather.”), enhancing person-to-person communication with personalized behavior (e.g., “If I'm out of the office when my wife calls, let her know when I'll be back.”), ensuring important information is not lost (e.g., “If there's an urgent e-mail, make sure it gets forwarded to me on my mobile device.”), and automating the management of information (e.g., “As new photographs arrive, place them in the right folders and shares based on their timestamp, GPS location, and any relevant calendar entries.”).
The way to accomplish this is by allowing the end-user to “program” the behavior of the computer. However, traditional programming languages are clearly not the answer, in that, the end-user is not (and cannot become) a trained developer.
What is needed is an improved mechanism that allows an end-user to personalize an operating system and an application.
The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key/critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.
The present invention disclosed and claimed herein, in one aspect thereof, comprises architecture that facilitates data management of an application. Applications can now be personalized by the end-user for the end-user. Included is a customization component that facilitates the exposing of an application generated event to an end-user; and a rules component that allows the end-user to create one or more rules to associate with the event, which one or more rules facilitate the submission of application data associated with the event for external processing. Since each rule-enabled feature of the application is defined by the decision point, an event/trigger/change at the decision point can be managed by the end-user for various purposes. Application data exposed by the decision point can be processed externally to return a result to the application that modifies behavior of the application.
Various functions of the application are rule-enabled. The end-user can then create rules for those functions to further manipulate data associated with the functions. Two kinds of application customization are called loosely-bound and tightly bound customization. In a loosely-bound customization, the application exposes an interceptor point, or “decision point” at which the end-user can attach customization rules. A rules is associated with the decision point by setting up an attachment type. Multiple different rules can be attached to a single application customization decision point using corresponding attachment types. The application does not “know” about the attached rules, but calls a method on the decision point item, and then processes the results. The method call causes a rules engine to be invoked on the right rules.
In a tightly-bound customization, decision points are not used. The application invokes the rules directly, which allows greater control to the application on which the rules will be invoked, and what types of rules are allowed when the rule engine processes rules to return application customization results. Thus, the tightly-bound application identifies the correct rules for the rules-based decision and user by issuing a file system query for the rules that correspond to that application, user, decision and input, to be provided with the rules. In contrast with the loosely-bound application, the choice of rules based on the user, decision, and input is determined by the rules platform whenever the desision point input method is invoked by the calling application.
In another aspect of the present invention, a learning component is provided that faclitates the application learning end-user behavior, and captures the behavior in the form of rules.
To the accomplishment of the foregoing and related ends, certain illustrative aspects of the invention are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the invention can be employed and the present invention is intended to include all such aspects and their equivalents. Other advantages and novel features of the invention will become apparent from the following detailed description of the invention when considered in conjunction with the drawings.
The present invention is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It may be evident, however, that the present invention can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the present invention.
As used in this application, the terms “component” and “system” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers.
As used herein, the term to “infer” or “inference” refer generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic-that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources.
Rules Architecture
The rules architecture of the present invention is a platform against which developers can build applications that run rich end-user logic in the form of rules. Application customization provides the choice of a loosely-bound model, a tightly-bound model, or both, which can be employed in an application to support data driven end-user choices. An application can expose one or more triggering events. If the application is using the tightly bound model there may be no exposed triggering event—just a place in the flow of logic in the application where the application supplies input to one or more rules, gets the results, and processes those results. The rules selected are queried for by the application. In the loosely-bound model, the application itself supplies the rule triggering events (in the form of items called decision points) as input to a rules engine. By providing a decision point, the application gives the end-user the capability to control the application decision with rules. The rules engine then evaluates rule conditions and returns application specific results for those rules whose conditions evaluated to true. The results are then interpreted by the rules customized application.
Referring now to
Referring now to
The existence of the process boundary between the application 202 and the rules engine 204 is merely an implementation choice, as indicated by the dashed line. Another implementation choice can be to embed the rules engine 204 into the application 202 so that invoking it does not cause a process switch.
The rules engine 204 supports application customization. Application customization is the model that is used to support data driven end-user choices of what had traditionally been relatively fixed option settings in applications. For example, today, most e-mail authoring applications allow the user to specify a single signature file for all outgoing e-mail. An example of application customization is to employ rules that allow the user to set the signature file for outgoing e-mail based on the recipient of the e-mail.
The rules platform facilitates the use of one or both of the following models for application customization: a first model that called loosely bound, and a second model that is called tightly bound.
Referring now to
The input scope is any item of any type. Input scopes are used by the operating system to limit the scope of rule evaluation to a specific item or folder, but are typically not used by individual applications. The labels on the lines in the above graphic show the names of the relationships between items. The rule set attachment item relates a decision point to a rule (and to an input scope, if one exists). The rule set item contains relationships to zero or more rule statements. Decision point items enable an application to use the rules platform. Rules describes rule items, including constraints, conditions, and results. Rules contain rule statements. Rule statements are statements of the form: on input, if condition, then results. For application customization, the results are defined by the application and consumed by the application. Rule set attachments items store information about the connection between a decision point and a rule set. The user attaches rules in a rule set, and the application provides input to the decision point to return results.
Referring now
At 400, the application registers a set of decision points to the operating system during application installation. Decision points are created by an application as a mechanism to submit input to the rules engine. By exposing a decision point, the application gives the end-user the ability to control an application decision with rules. Input data flows to the rules engine (either directly or via a decision point) to produce application customization results. A decision point is only needed for loosely-bound application customization. At 402, application decision points are exposed at which application behavior has been customized. At 404, a method is invoked at each decision point object to process the end-user customization at that decision point. When the application code reaches a point at which a decision needs to be made, it invokes a method on a decision point object (item). This causes the rules engine to evaluate appropriate end-user rules and return the expected results. At 406, the method submits the decision point rules to the rules engine. At 408, the rules engine processes the rules and sends one or more results back to the application. The application then processes the results in an application-specific manner. The process then reaches a Stop block.
As indicated, for loosely bound application customization, the application does not know about the rules. It simply calls a method on the decision point item, and then processes the returned results. The method call causes the rules engine to be invoked on the right rules.
Referring now to
As indicated, tightly bound applications are applications that invoke rules directly, which allows greater control to the application on which rules will be invoked, and what types of rules are allowed when the rule engine processes rules to return application customization results. This control places a greater burden on the tightly bound application. Specifically, a tightly bound application identifies the correct rules for the rules-based decision and user by issuing a query for the rules that correspond to the application and user, decision, and input to be provided to the rules. Instead of using a decision point, the application directly invokes an execute method on the rules, passing it the input item and the rule constraint. The rule constraint is used to identify the subset of rules that should be applied to the particular input.
A rule constraint can more accurately be thought of as a rule signature. The signature is used to filter which rules run given a particular invocation with a particular input. Rule constraints are specified in two places: on each rule, and on each submission point. There are no rule constraints on RSAs.
On rules, the rule constraint is used for enforcement to ensure that the rule conforms to what it says it conforms. The output of each action matches what the rule constraint says the output is. This is the same for the input. The constraint on a rule dictates where it can be attached. Validation will fail if inappropriate attachment of the rule is attempted. Rules are attached to decision points. Only rules consistent with the decision point constraints will be allowed to be attached.
To contrast this, for loosely bound applications, the choice of rules based on user, decision, and input is performed by the platform whenever the decision point input method is invoked by the calling application.
One or more rules are associated with a decision point by setting up the RSA. A particular RSA can be more restrictive than the rule constraint provided by the decision point. That is, it may specify that the rules should be applied only for a subset of the potential invocations of the decision point by the application. Specifically, it can constrain the rules along any of the following dimensions:
User: every RSA is associated with a particular user, and is only invoked for those decisions that are requested on behalf of that user.
Type: the RSA can specify that the attached rules should only apply to inputs of a particular type.
Input Scope: the RSA can, in general, specify application-specific information that causes the rules to be invoked only for a subset of potential invocations. In the case of the built-in application that allows control of changes in the item store to be controlled by the user with rules, the following kinds of input scope are expected: an item defining containment scope for query or change eventing; and, if the application supports composite operations in a single decision point (e.g., New Item or Item Modified), then the RSA can specify a further constraint which can specify a subset of the operations.
Input Content: the RSA can, in general, specify content-based filters (e.g., only apply this rule to input items owned by user). In one implementation, these filters could be deduced from the attached rule.
Note that based on this reasoning, there can be multiple RSAs attached to an application customization decision point, and the platform has to support it.
Referring now to
When a decision point is invoked with a particular input of a particular type, only those RSAs whose constraints (user, type, scope, content filter) match this input are invoked. The results from all RSAa are aggregated into a single ResultSetElement (RSE). This return value contains the aggregate results (after conflict resolution) of all attached rules.
The application should expect that all results correspond to the rule constraint defined in the decision point and it is possible for the application to distinguish between the results produced by each matching RSA.
In accordance with one optimization, a rule is allowed to have different kinds of rules, that is rules with different constraints. The effect of this is that the rules engine dynamically evaluates these rules constraints to decide which of the rules should be applied. It also means that the “direct” execution interface requires a rule constraint. If it was required to only have rules of the same constraint within it, then constraint checking can be performed at the time of rule attachment and membership. However, this reduces the flexibility of using a rule as an organizational device.
The lack of a RuleConstraint in a tightly-bound application does not mean that there is no end-user customization. The rules can be just as rich in tightly-bound, as in loosely-bound scenarios. What is missing from the tightly-bound scenario is the capability for a Universal Rules user interface (UI) to present the customization options. There is nothing for it to reflect on in order to determine those options. It is up to the tightly-bound application to present its custom UI for rules building. In this way it can control the available conditions and actions.
Rules Input/output (I/O) Model
The rules engine receives input, evaluates rules based on this input, and returns the results of any matched rules as output to the calling application. To support application customization and non-item data, the I/O model is extended to return Application Views rather than RSE. Application Views describes structured data returned from rules evaluation. The action model is extended to execute actions contained in an Application View. An RSE can be optionally persisted if the application requests it, but it will not be the expected pattern for customizing applications.
Input to the rules engine consists of an operation name and, optionally, can point to an item to which it is related. Inputs can be thought of as “verbs”, like “item created”, which can have a pointer to the item which has been “created”. For instance, given the situation in which a new MP3 file is created in a folder, the item creation is the input operation, and the MP3 would be an item referenced by this input submission.
In addition to support for referring to an item as part of submitting input to the rules engine, it is possible for inputs to refer to XML data.
DecisionPoint Items contain methods, for example, DecisionPoint.Submit( ) and DecisionPoint.SubmitAndWait( ) are used by developers to submit input into the rules engine. Each DecisionPoint defines the operation name and (optional) item type it accepts as Input.
Submitting input that refers to existing types is thus straightforward. When an application would like to submit a set of data that is not schematized, there are two possibilities: the developer defines a new item type using a custom schema, where this item type holds the proper information, and instances of this type are submitted to the rule engine; and the developer uses XML support to submit the data. As an example of the first option, consider that the developer of an application wants to enable users to create rules around the processing of one of the applications events (non-schematized data). To clarify, a developer wants to craft a type, and provide the type as input to a decision point via a submit. The developer then expects as a response one of the methods on the type to be the action the end-user wants to take. For example, if the object is a soda can, and the methods were Drink, CrushAndDiscard, and SetOnTable, then the conditions would be if“empty” and “recycle bin handy”, then CrushAndDiscard. If “not empty”, and “not thirsty”, then SetOnTable.
DecisionPoints may optionally require “input scopes”. Certain decision points may involve rules constrained to a particular portion of the file system. These DecisionPoints require that any rules attached to them include a relationship to an Input Scope. For instance, the hypothetical “Item Created” decision point above could require an input scope—and would thus be denoting that it requires any rules attached to it to provide a scope within the file system where these item creation inputs would come from.
The logical building block in the rules-based architecture is the collection. A collection is made up of a “scoping” item and a relationship type. Any items that are the targets of relationships of the specified type emanating from the “scoping” item are considered to be part of the collection rooted at the scoping item.
RuleSetAttachment items contain methods used for evaluating entire collections simultaneously (e.g., RuleSetAttachment.Evaluate( ) and RuleSetAttachment.EvaluateIntoCollection( )). These methods the items in the attached input scope as input for the engine to consider. The items are evaluated as if they were submitted individually. The rules engine does not treat collections specially for purposes of evaluation.
Each call to one of the DecisionPoint submit( ) methods or the RuleSetAttachment evaluate( ) methods will cause one or more attached rules to be evaluated by the rule engine. Results from these evaluations are written into a single RuleSetEvaluation item per call.
The RuleSetEvaluation item has a nested element set of RuleResultElements. Each RuleResultElement carries the result name and the structured data necessary to describe the result. These results are application-specific; that is, they are expected to be understandable by the application through/for which the Rule was created and submitted the event. In many cases, the result name carried within the RuleResultElement may actually be a fully-qualified class-level (static) CLR (common language runtime) method name, and the structured data may correspond to parameters for that method. The RuleResultElement type includes an execute( ) method capable of taking this data, and, using CLR reflections, call the named method with the proper parameters. In one implementation, these are limited to setter/getter methods on the properties of the input item as well as static methods found in libraries available within the execution context of the rules customization application.
In another implementation, a new RuleSetEvaluation item is generated for each attachment to the decision point to which the input was submitted.
A FunctionInfo type is shared between the nested types RuleResultElement and Action, the latter being part of the Rule definition.
For those applications wishing to receive results in an XML format, an alternate form of RuleResultElement is provided that can contain the XML data of choice.
Referring now to
The subject invention can employ various artificial intelligence based schemes for carrying out various aspects of the subject invention. For example, a process for determining where to place a decision point can be facilitated via an automatic classifier system and process. A classifier is a function that maps an input attribute vector, x=(x1, x2, x3, x4, xn), to a confidence that the input belongs to a class, that is, f(x)=confidence(class). Such classification can employ a probabilistic and/or statistical-based analysis (e.g., factoring into the analysis utilities and costs) to prognose or infer an action that a user desires to be automatically performed.
A support vector machine (SVM) is an example of a classifier that can be employed. The SVM operates by finding a hypersurface in the space of possible inputs, which hypersurface attempts to split the triggering criteria from the non-triggering events. Intuitively, this makes the classification correct for testing data that is near, but not identical to training data. Other directed and undirected model classification approaches include, e.g., naïve Bayes, Bayesian networks, decision trees, and probabilistic classification models providing different patterns of independence can be employed. Classification as used herein also is inclusive of statistical regression that is utilized to develop models of priority.
As will be readily appreciated from the subject specification, the subject invention can employ classifiers that are explicitly trained (e.g., via a generic training data) as well as implicitly trained (e.g., via observing user behavior, receiving extrinsic information). For example, SVM's are configured via a learning or training phase within a classifier constructor and feature selection module. Thus, the classifier(s) can be used to automatically perform a number of functions, including but not limited to determining the location of decision points based in the particular end-user or the application to customized, determining where to place the decision points based on end-user history of decision point placement, and what decision points can be employed based on the type of application. The classifier can be employed to determine what rule to attach to a decision point for a loosely bound model. Similar classifier operations employed for decision points in the loosely bound model can be applied to rules for the tightly bound model.
In a more robust implementation, the classifier performs the complete end-to-end application customization process for the end-user based on end-user preferences and past customizations. Further, the classifier can be used to determine when to use a loosely bound or tightly bound model of application customization and according to a given end-user.
Referring now to
Generally, program modules include routines, programs, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the inventive methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, minicomputers, mainframe computers, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like, each of which can be operatively coupled to one or more associated devices.
The illustrated aspects of the invention may also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.
A computer typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media can comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital video disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer.
Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer-readable media.
With reference again to
The system bus 808 can be any of several types of bus structure that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory 806 includes read only memory (ROM) 810 and random access memory (RAM) 812. A basic input/output system (BIOS) is stored in a non-volatile memory 810 such as ROM, EPROM, EEPROM, which BIOS contains the basic routines that help to transfer information between elements within the computer 802, such as during start-up. The RAM 812 can also include a high-speed RAM such as static RAM for caching data.
The computer 802 further includes an internal hard disk drive (HDD) 814 (e.g., EIDE, SATA), which internal hard disk drive 814 may also be configured for external use in a suitable chassis (not shown), a magnetic floppy disk drive (FDD) 816, (e.g., to read from or write to a removable diskette 818) and an optical disk drive 820, (e.g., reading a CD-ROM disk 822 or, to read from or write to other high capacity optical media such as the DVD). The hard disk drive 814, magnetic disk drive 816 and optical disk drive 820 can be connected to the system bus 808 by a hard disk drive interface 824, a magnetic disk drive interface 826 and an optical drive interface 828, respectively. The interface 824 for external drive implementations includes at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.
The drives and their associated computer-readable media provide nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For the computer 802, the drives and media accommodate the storage of any data in a suitable digital format. Although the description of computer-readable media above refers to a HDD, a removable magnetic diskette, and a removable optical media such as a CD or DVD, it should be appreciated by those skilled in the art that other types of media which are readable by a computer, such as zip drives, magnetic cassettes, flash memory cards, cartridges, and the like, may also be used in the exemplary operating environment, and further, that any such media may contain computer-executable instructions for performing the methods of the present invention.
A number of program modules can be stored in the drives and RAM 812, including an operating system 830, one or more application programs 832, other program modules 834 and program data 836. All or portions of the operating system, applications, modules, and/or data can also be cached in the RAM 812.
It is appreciated that the present invention can be implemented with various commercially available operating systems or combinations of operating systems.
A user can enter commands and information into the computer 802 through one or more wired/wireless input devices, e.g., a keyboard 838 and a pointing device, such as a mouse 840. Other input devices (not shown) may include a microphone, an IR remote control, a joystick, a game pad, a stylus pen, touch screen, or the like. These and other input devices are often connected to the processing unit 804 through an input device interface 842 that is coupled to the system bus 808, but can be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.
A monitor 844 or other type of display device is also connected to the system bus 808 via an interface, such as a video adapter 846. In addition to the monitor 844, a computer typically includes other peripheral output devices (not shown), such as speakers, printers etc.
The computer 802 may operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers, such as a remote computer(s) 848. The remote computer(s) 848 can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 802, although, for purposes of brevity, only a memory storage device 850 is illustrated. The logical connections depicted include wired/wireless connectivity to a local area network (LAN) 852 and/or larger networks, e.g., a wide area network (WAN) 854. Such LAN and WAN networking environments are commonplace in offices, and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which may connect to a global communication network, e.g., the Internet.
When used in a LAN networking environment, the computer 802 is connected to the local network 852 through a wired and/or wireless communication network interface or adapter 856. The adaptor 856 may facilitate wired or wireless communication to the LAN 852, which may also include a wireless access point disposed thereon for communicating with the wireless adaptor 856. When used in a WAN networking environment, the computer 802 can include a modem 858, or is connected to a communications server on the LAN, or has other means for establishing communications over the WAN 854, such as by way of the Internet. The modem 858, which can be internal or external and a wired or wireless device, is connected to the system bus 808 via the serial port interface 842. In a networked environment, program modules depicted relative to the computer 802, or portions thereof, can be stored in the remote memory/storage device 850. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.
The computer 802 is operable to communicate with any wireless devices or entities operatively disposed in wireless communication, e.g., a printer, scanner, desktop and/or portable computer, portable data assistant, communications satellite, any piece of equipment or location associated with a wirelessly detectable tag (e.g., a kiosk, news stand, restroom), and telephone. This includes at least Wi-Fi and Bluetooth™ wireless technologies. Thus, the communication can be a predefined structure as with conventional network or simply an ad hoc communication between at least two devices.
Wi-Fi, or Wireless Fidelity, allows connection to the Internet from a couch at home, a bed in a hotel room or a conference room at work, without wires. Wi-Fi is a wireless technology like a cell phone that enables such devices, e.g., computers, to send and receive data indoors and out; anywhere within the range of a base station. Wi-Fi networks use radio technologies called IEEE 802.11 (a, b, g, etc.) to provide secure, reliable, fast wireless connectivity. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3 or Ethernet). Wi-Fi networks operate in the unlicensed 2.4 and 5 GHz radio bands, with an 11 Mbps (802.11a) or 54 Mbps (802.11b) data rate or with products that contain both bands (dual band), so the networks can provide real-world performance similar to the basic 10BaseT wired Ethernet networks used in many offices.
Referring now to
Communications can be facilitated via a wired (including optical fiber) and/or wireless technology. The client(s) 902 are operatively connected to one or more client data store(s) 908 that can be employed to store information local to the client(s) 902 (e.g., cookie(s) and/or associated contextual information). Similarly, the server(s) 904 are operatively connected to one or more server data store(s) 910 that can be employed to store information local to the servers 904.
What has been described above includes examples of the present invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the present invention, but one of ordinary skill in the art may recognize that many further combinations and permutations of the present invention are possible. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
This application clams the benefit of U.S. Provisional Patent Application Ser. No. 60/567,153 entitled “END-USER APPLICATION CUSTOMIZATION USING RULES”, filed on Apr. 30, 2004, U.S. Provisional Patent Application Serial No. 60/567,149 entitled “DERIVED SET—A RULES-BASED QUERY-LIKE MECHANISM THAT DEFINES CONTENTS OF A COLLECTION” filed on Apr. 30, 2004, and U.S. Provisional Patent Application Ser. No. 60/567,165, entitled “RULES FRAMEWORK FOR DEFINITION AND EXECUTION OF END-USER RULES LOGIC”, filed on Apr. 30, 2004. This application is also related to co-pending U.S. Patent Application Ser. No. ______ (Atty. Dkt. No. MSFTP668USA) entitled “RULES FRAMEWORK FOR DEFINITION AND EXECUTION OF END-USER RULES LOGIC” filed on Jul. 30, 2004. The entireties of the above-noted applications are incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
60567153 | Apr 2004 | US | |
60567149 | Apr 2004 | US | |
60567165 | Apr 2004 | US |