System and method for advanced rule creation and management within an integrated virtual workspace

Abstract

A conflict detection and resolution system and method are described for detecting and resolving conflicts between filtering and/or routing rules within an integrated messaging/document management system. One embodiment of the method comprises evaluating a plurality of rules for routing, filtering and/or storing messages and/or documents to determine whether a conflict exists between two or more of the plurality of rules; detecting a conflict between two or more of the plurality of rules; determining a severity level associated with the detected conflict; and identifying a resolution to the conflict resolution if the severity level associated with the conflict is below a predetermined threshold value.

Description

PRIORITY

The present application claims priority from a U.S. provisional application entitled “Integrated Message and Document Management”, Application No. 60/486,166, filed Jul. 11, 2003.

BACKGROUND

1. Field of the Invention

This invention relates generally to the field of information management systems. More particularly, the invention relates to a system and method for creating and managing an advanced rule set within an integrated WorkSpace.

2. Description of the Related Art

The average individual accesses and manages a surprisingly large number of messages and documents every day. In a typical business environment, the number of legitimate messages received and sent in the course of a day averages roughly fifty. These include emails, faxes, voice messages, voice calls, text messages, and instant messages. The number of devices that individuals use for communications and messaging has also multiplied. Such devices include computers, fax machines, wire-line phones, wireless phones, personal digital assistants (“PDAs”), and pagers, with each device typically handling a different type of message or method of communications. Most individuals today manage their messages across different media and, more importantly, over multiple types of devices.

Simultaneous with the proliferation of messages and messaging devices, the penetration of personal computers and servers in homes and offices has also risen sharply. The average individual accesses, creates, modifies, saves, and otherwise manages a large number of documents every day. This number is even larger when documents are broadly defined to include private and work-related databases as well. To complicate matters, documents are often transferred among individuals as stand-alone messages such as faxes, as attachments to electronic messages, as information embedded within messages, and as data files with attached messages.

To help manage the complexity of multi-media messaging over numerous devices, unified communications solutions strive to consolidate different types of messages into a single platform. Many of these platforms allow for remote access and management of messages over the Public Switched Telephone Network (“PSTN”), the Internet, as well as other public and private voice and data networks. Increasingly, such solutions are also tied to communications systems themselves to allow both real-time and near-real-time communications. For example, many voicemail platforms enable users to use the call-back number of a voicemail sender to return a call during the course of retrieving a voicemail. Unified communications solutions, therefore, allow users to access and manage different types of messages from a single access point, regardless of the user's device of choice. These solutions also permit some limited communications (as opposed to retrieval and management of messages) from the same platform by interfacing with communications systems.

In the area of document and data management, solutions have generally taken the form of remote access to data storage devices that house documents and databases and the sharing of data on such devices based on a user's security level. The management of documents and data, however, has traditionally been viewed as a problem quite distinct from communications and the management of messages. Differences between data management solutions and communications/message management solutions, however, are becoming blurred as communications and message management solutions increasingly enable document access and transfer. Nevertheless, data management solutions and communications/message management solutions today remain, for the most part, quite separate.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:

FIG. 1 illustrates various functional platforms employed in one embodiment of the invention.

FIG. 2 illustrates a WorkSpace enterprise environment according to one embodiment of the invention.

FIG. 3 illustrates a WorkSpace carrier environment according to one embodiment of the invention.

FIG. 4 illustrates a WorkSpace stand alone environment according to one embodiment of the invention.

FIG. 5 illustrates WorkSpace user access and information flows according to one embodiment of the invention.

FIG. 6 illustrates WorkSpace system hardware architecture employed in one embodiment of the invention.

FIG. 7 illustrates a WorkSpace system software architecture employed in one embodiment of the invention.

FIG. 8 illustrates WorkSpace meta document creation and transfer according to one embodiment of the invention.

FIG. 9 illustrates an example of user preferences related to message access/retrieval and corresponding message sets according to one embodiment of the invention.

FIG. 10 illustrates a method to resolve conflicts in message and document filtering/routing according to one embodiment of the invention.

FIG. 11 illustrates an exemplary sample distribution comprising evening home calls.

FIG. 12 illustrates a stylized triangular distribution of the evening home calls.

FIG. 13 illustrates an exemplary two-dimensional representation of a two-variable joint distribution.

FIG. 14 illustrates an exemplary generalized two-dimensional representation of a two-variable joint distribution.

FIG. 15 illustrates an exemplary mapping of conditions against resultant outcomes.

FIG. 16 illustrates an exemplary outcome space for rules as defined by acceptability thresholds.

FIG. 17 illustrates an exemplary degree of membership in a rule condition.

FIG. 18 illustrates an exemplary representation of perceived intrusiveness of calls to home phone.

FIG. 19 illustrates an exemplary joint mapping of condition (time of day) and outcome (intrusiveness) associated with calls to home phone.

FIG. 20 illustrates an exemplary joint mapping of condition (time of day) and outcome (intrusiveness) associated with voicemail messages.

FIG. 21 illustrates an exemplary representation of joint outcomes of two possible actions (call to home and voicemail).

FIG. 22 illustrates an exemplary outcome space for rules as defined by acceptability thresholds.

FIG. 23 illustrates a pseudo-address method for text messaging according to one embodiment of the invention.

FIG. 24 illustrates an exemplary pseudo-address method for instant messaging according to one embodiment of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Described below is a system and method for implementing and managing an advanced rule set within an integrated WorkSpace. Throughout the description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the present invention.

Note that in this detailed description, references to “one embodiment” or “an embodiment” mean that the feature being referred to is included in at least one embodiment of the invention. Moreover, separate references to “one embodiment” in this description do not necessarily refer to the same embodiment; however, neither are such embodiments mutually exclusive, unless so stated, and except as will be readily apparent to those skilled in the art. Thus, the invention can include any variety of combinations and/or integrations of the embodiments described herein.

Introduction

A system is described below that contains communications, message management, and document management functions as well as applications utilizing these functions. It is both a user portal and a tool that enables communications, message management, and document management. This system will be referred to herein as the “WorkSpace” system. As shown in FIG. 1, the WorkSpace system contains a communications management platform 110 that links the rest of the system to communications equipment that are in turn connected to both public and private telephone and data networks 140. The communications management platform is integrated with a message management platform 120 that is connected to the same telephone and data networks 140 as well as to a document and database management platform 130. The document management platform could also be connected independently with telephone and data networks. The term “platform” is used here to describe software code that performs communications, message management, and document management functions. Finally, although not shown explicitly, a WorkSpace system may also contain process- or situation-specific applications that incorporate defined communications, message management, and document management tasks.

As a portal, the WorkSpace system acts as the entry point for the important tasks handled by many individuals during the course of a day: (1) communications; (2) message management; and (3) document management. As mentioned above, it may also act as a portal to applications that incorporate these three functions. For example, consider the communications and document requirements of a doctor. They may include transferring documents to colleagues as part of messages about patient care. An application in this context could include (a) transmittal of a prescription to a pharmacy along with (b) information on patient insurance from an insurance database on the doctor's computer and (c) transmittal of some lab results to a colleague along with a link to retrieve history of lab tests. The prescription transmittal and the test result retrieval methods are examples of applications that may be enabled by and accessed through the WorkSpace system described herein.

In one embodiment, WorkSpace software integrates its message management platform to communications systems such as Private Branch Exchanges (“PBX”s) and email servers that are in turn connected to communications networks. It also allows users (consistent with that user's privileges) to access and manage documents and databases on computer devices such as servers and mainframes. Beyond merely facilitating access to documents and databases, the WorkSpace system also allows for the creation of context-specific document creation, transfer, storage, and other document management functions by using the message management platform as an engine for these functions. It is especially powerful when both documents and messages are part of the same work process. The WorkSpace system, therefore, integrates communications, message management, and document management in a single system. It also allows the creation of different applications that incorporate these three functions.

An Exemplary Enterprise Environment

FIG. 2 shows a typical enterprise environment in which a WorkSpace system is deployed. In one embodiment, the enterprise, driven by its voice communications requirements, is connected to the PSTN 260 directly via Time Division Multiplexing (“TDM”) circuits such as T-1's and PRI's or analog phone lines. In an additional embodiment, the enterprise is indirectly connected to the PSTN through a carrier-grade hybrid telephony switch 255 used to connect an enterprise using packet-voice protocols such as Voice-over-Internet-Protocol (“VoIP”) for internal voice communications. Such hybrid telephony switches generally handle conversions from VoIP protocols to TDM protocols and are often connected to signaling networks such as the Signaling System 7 (“SS7”) network.

The first embodiment is typical in a circuit-switched environment while the second describes a VoIP environment. An enterprise that chooses to handle the VoIP to TDM conversion itself rather than through a third-party service provider may also use a media gateway 230 that is either part of or connected to the enterprise's telephony switch 210 to perform the conversion. In yet another embodiment, the enterprise may be connected directly to the PSTN over TDM circuits but may also process some or all VoIP calls through the use of a media gateway 230 at the edge of its voice network. In this example, PSTN-bound traffic is eventually processed through a hybrid telephony switch 245 which lies at the edge of the enterprise's data network 250, but which may or may not be operated by a third-party service provider.

On the enterprise side, the connection from the PSTN 260 terminates on enterprise telephony switch devices 210. Such devices include digital PBX's, analog and digital key systems, and VoIP-capable PBX's. These are the devices that route calls to and from end user stations such as telephones and fax machines 200. End-user-facing trunks or lines connect telephony switch devices to end user stations.

The design of the WorkSpace system allows connectivity to (a) the enterprise telephony network (regardless of the underlying transport protocols), (b) enterprise data servers or computers 235, (c) other message management platforms used by the enterprise such as email servers 220, and (d) additional WorkSpace systems 240 that may be required. It should be noted that separate data storage devices, message management platforms, and additional WorkSpace systems are optional, and are not required for complying with the underlying principles of the invention. They need to be deployed only if message and data volumes, higher levels of security, and/or user preferences for third-party message management solutions are relevant considerations. An enterprise or carrier would deploy routers and/or switches 225 to tie together the above described infrastructure. Users typically access the WorkSpace system over a computer device 265 such as a personal computer or PDA tied to the data network of the enterprise, either through a private or a public data network. For message management purposes and a few limited document management purposes, users may also access the WorkSpace system through a telephone device connected either to the PSTN or the enterprise's voice network. Access through hybrid computer-telephone devices is also possible.

An Exemplary Carrier Environment

In one embodiment of the invention, the WorkSpace system is deployed in a carrier environment. This type of deployment, illustrated in FIG. 3, allows carriers to provide data management services along with communications and messaging services. As shown in FIG. 3, the WorkSpace system is connected to a carrier's local telephony switch 310 regardless of whether the switch was operating in circuit-switched or packet-based environments. End users access the WorkSpace system through a telephone device 300 or a computer device 365 over a data network which may be either private or public. As in the enterprise environment, telephone and fax devices would be connected to the carrier switch over trunks, lines, and data circuits.

One main difference between the enterprise and carrier environments is that carrier switches, unlike enterprise switches, are generally connected to a signaling network such as the SS7 network. This allows carriers, unlike enterprises, to use Advanced Intelligent Network (“AIN”) functionalities of carrier-grade switches to pre-screen and direct calls using databases on the signaling network. Generally, these databases are attached to SS7 Signal Transfer Point (“STP”) switches. Although such pre-screening could also be enabled in the enterprise environment, it would require calls to be processed through the call and message management functions of a WorkSpace system. This means that additional circuits and ports would be required. A carrier could avoid these requirements through the use of AIN features.

As in the enterprise environment, carriers may choose to deploy messaging platforms of different vendors 320 that are tied to WorkSpace systems over a data network. Additional data servers 335 could also be connected in the same manner. Carriers that want to retain their embedded TDM infrastructure but also support packet-voice traffic could deploy media gateways 330 to convert TDM traffic to the appropriate packet-voice protocol. A hybrid telephony switch 345 would be required at the edge of the carrier's data network to allow for the conversion of packet-voice traffic to TDM format. This configuration would also permit carriers to migrate voice traffic from legacy TDM equipment to packet-voice equipment over time.

Stand Alone Network Environment

The WorkSpace system may also be deployed in a stand-alone configuration as shown in FIG. 4. In this configuration, the WorkSpace system 410 may be connected to the PSTN 450 via circuits such as T-1's, PRI's, or analog circuits. On the customer end are devices such as telephones or faxes 400 or computer devices 455 that are used to access the various functionalities of a WorkSpace system. If desired, a media gateway 425 may be attached to the WorkSpace system to enable TDM to packet-voice conversions. Of course, a hybrid telephony switch 445 would be required to reconvert the packet-voice to TDM voice traffic. Equipment such as third-party email servers 415, additional document servers 430, and additional WorkSpace systems 435 are optional. This optional equipment may be connected to the main WorkSpace system and to each other through a router or switch 420. All data communications and document transfers would take place over data networks 440.

The stand-alone configuration limits the extent of real-time communications because the switching functionalities of enterprise and carrier telephony switches would no longer be available. It does not, however, eliminate real-time communications altogether because the device could be connected to the PSTN either directly via PSTN-facing circuits or indirectly through a data network with a hybrid telephony switch 445 at its edge.

The stand-alone configuration may be more appropriate in environments where message management and data management functionalities were relatively more important than communications needs. An example of such an environment is an offline group within a company responsible for customer correspondence and investigation of billing disputes. In such an environment, the need for real-time communications may be minimal. Indeed, PSTN-facing trunks could be eliminated altogether and packet-voice traffic that is transported through a third party's hybrid telephony switch could ensure adequate real-time voice communications.

User Access and Information Flows

In one embodiment, users may access WorkSpace system functions and applications in several ways including: over a telephone device, from a data network access device such as a personal computer, or through hybrid devices such as I-Mode phones, Blackberry handheld devices, and devices that access data sources through voice recognition schemes. As shown in FIG. 5, users generally access the servers with devices 580 connected to the PSTN and/or the Internet. Of course, access through other public and private voice and data networks is also possible. Given the narrow bandwidth of the telephone and the generally imperfect user experience with accessing text over the telephone, most users are unlikely to want long text messages or documents read to them over the telephone. Such access to text messages or documents is technically feasible and can be easily be accommodated if desired by users through the use of third-party Text-To-Speech (“TTS”) engines. Non-text documents (such as spreadsheets and databases) and non-text messages (such as faxes) may be accessed over a narrow-band telephone device but they may not be susceptible to meaningful manipulation or management. In one embodiment of the invention, for such documents and messages, users access their summary characteristics (such as size, name, or document type) over the telephone and use such characteristics to transfer them and perform other limited management functions, as described herein.

One way to access a WorkSpace system is over a data network to which the user is connected via a broadband connection. One particular user device is a hybrid telephone-computer device that communicates over both voice and data networks. This optimal access method allows fast and complete access to one's documents and messages in addition to convenient real-time communications.

Information (broadly defined) is either stored directly on or is sent to WorkSpace systems by individuals or systems over voice and data networks, both public and private. Examples of such information include voice calls, faxes, text messages, emails and documents. As shown in FIG. 5, incoming information is generated by voice-network-connected devices 560, data-network-connected devices 555, and data-network-connected data system devices 550 (grouped as 510 in FIG. 5). Based on the preferences and the settings of the user, the information is processed by the WorkSpace system and routed to voice-network-connected user devices 575, data-network-connected user devices 570, and data-network-connected data storage devices 565 (grouped as 520 in FIG. 5). In addition, users may be notified of messages and documents that they have received based on notification criteria established in a WorkSpace system 530, as described herein. When connected to either communications switching equipment or communications networks themselves, users may engage in real-time and other communications enabled by such equipment and networks.

An Exemplary System Hardware

FIG. 6 illustrates one embodiment of a WorkSpace computer system 651, which may perform the functions of a web server, an email server, a server for the storage of messages, and a server for the storage of documents and/or databases. A similar computer system, either attached to system 651 with a telephone network interface or within system 651 itself, with TTS and speech recognition programs may be used to read text messages to users and to implement a voice response unit.

The computer system 651 contains a central processing unit (CPU) 652, memories 653 and an interconnect bus 654. The CPU 652 may contain a single microprocessor (e.g. an x86 microprocessor), or it may contain a plurality of microprocessors for configuring the computer system 651 as a multi-processor system. The memories 653 include a main memory, such as a dynamic random access memory (DRAM), as well as a read only memory, such as a PROM, an EPROM, a FLASH-EPROM, or the like. The system 651 also includes mass storage devices 655 such as various disk drives and tape drives. The main memory typically includes dynamic random access memory and high-speed cache memory. In operation, the main memory stores at least portions of instructions and data for execution by the CPU 652.

The mass storage may include one or more magnetic disk or tape drives or optical disk drives, for storing data and instructions for use by CPU 652. For an enterprise-based WorkSpace system, for example, at least one mass storage system 655 in the form of a disk drive or tape drive, stores the operating system and application software as well as data, such as received and sent messages and documents. The mass storage system 655 within the computer system 651 may also include one or more drives for various portable media, such as a floppy disk, a compact disc read only memory (CD-ROM), or an integrated circuit non-volatile memory adapter (i.e. PC-MCIA adapter) to input and output data and code to and from the computer system 651. It should be noted that mass storage devices for received and sent messages and documents and parts of the application software may be outside computer system 651.

The computer system 651 also includes one or more input/output interfaces for communications, shown by way of example as an interface 659 for voice-grade communications via a voice communications network. The interface 659 may be a modem, channel bank, digital signal processor card with ports, fax cards, or any other appropriate voice-grade communications device, for digital and analog communications of various types via a voice communications network. The physical communication links may be optical, wired, or wireless (e.g., via satellite or cellular network).

The computer system 651 may further include appropriate input/output ports 656 for interconnection with data networks or devices connected over a common data network. The input/output ports 656 may be a modem, an Ethernet card or any other appropriate data communications device. To provide the WorkSpace service to a large number of customers, the interface 656 preferably provides a relatively high-speed link to a data network or to the Internet. The physical communication link may be optical, wired, or wireless (e.g., via satellite or cellular network). Alternatively, the computer system may comprise a mainframe or other type of host computer system capable of web-based communications via a data network or the Internet. The input/output ports may include a display and keyboard serving as the administrative or user interface. Although not shown, the server type system could also include a port for connection to a printer. The input/output ports are one of the main access points for users into the computer system 651 as well as the point of interconnection with other WorkSpace systems and related computer devices.

Each computer system 651 runs a variety of application programs and stores data, enabling one or more interactions via the communications interfaces or the input/output ports to implement the desired processing for the WorkSpace service or the processing of requests for related services. One or more such applications enable the delivery of web pages and/or the generation of email and other messages supported by WorkSpace. Those skilled in the art will recognize that the computer system 651 may run other programs and/or host other web-based or email based services. As such, the computer system 651 need not sit idle while waiting for WorkSpace service related functions. Also, the system 651 may be implemented as a single computer system or as a distributed system having multiple appearances at different nodes on the Internet.

The components contained in the computer system 651 are those typically found in general purpose computer systems used as servers, workstations, personal computers, network terminals, and the like. In fact, these components are intended to represent a broad category of such computer components that are well known in the art. The underlying principles of the invention are not limited to any particular computer system architecture.

Exemplary System Software and Data

Many concepts discussed herein relate to the software elements, such as the executable code and/or the various databases containing information essential for proper working of the executable code, and other software used to implement the different functions in each of the software modules identified in FIG. 7. These functions may reside on the same physical system or on different physical systems that are linked by local or wide area communications networks. However communications among WorkSpace systems and computer systems serving as storage systems for messages, documents and databases preferably are private and/or appropriately secured.

At different times, all or portions of the executable code or database for any or all of these software elements may reside in physical media or be carried by electromagnetic media. The various data components as well as WorkSpace system files relating to the performance of the WorkSpace software developed by the processing also may reside in or be transported via a variety of different media. Physical media include the memory of the computer system 651, such as various semiconductor memories, tape drives, disc drives and the like of general-purpose computer systems. All or portions of the software may at times be communicated through the Internet or various other telecommunications networks. Such communications, for example, may be to load the software from another computer (not shown) into the web server or into another network element. Thus, other type of media that may bear the software elements includes optical, electrical and electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links.

The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to a processor for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as any of the storage devices in the system of FIG. 6. Volatile media include dynamic memory, such as main memory. Transmission media include coaxial cables, copper wire, fiber optics, and also the wires that comprise a bus within a computer system. Transmission media can also take the form of electric or electromagnetic signals, or acoustic or light waves such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave transporting data or instructions, or any other medium from which a computer can read. Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to a processor for execution. Additionally, code for implementing the described operations may be in the form of computer instructions in any form (e.g., source code, object code, interpreted code, etc.) stored in or carried by any computer- or machine-readable medium.

Thus, some of the concepts discussed herein relate to functionalities embedded within and processes enabled by WorkSpace software. The software consists of executable code that performs various functions contained within various modules. It also consists of various databases that are essential to the performance of the executable software code. Returning for FIG. 7, modules of the software support the following functionalities, among others: System Access, Security and Administration 701, Real Time Communications 702, Non-Real-Time Communications 703, Communications, Message, and Document Filtering 704, Media Conversion 705, Communications, Message, and Document Routing 706, Message and Document Storage 707, Message Access and Management 708, Document Access and Management 709, Account Management 710, Search and Retrieval of Documents and Messages, including security functions 711 (both internal and external to a WorkSpace system). A variety of different WorkSpace system features provided by these modules 701-711 are set forth below.

In one embodiment, the software is designed to work on a Linux operating system but could be readily extended to work with other operating systems such as Unix and Windows. Of course, as mentioned above, the underlying principles are not limited to any particular software or hardware implementation.

Workspace Portal

In one embodiment, the WorkSpace system provides a portal comprised of three main work functions of individuals today. These functions consist of (1) communications across various media, (2) management of different types of messages, and (3) management of documents and databases. Each of these functions in turn includes numerous sub-functions. The software contains code to control access and security to the system. The software code is also designed to work with other mechanisms for managing access to computer devices and data storage devices that may have been developed by others. Interfaces to third-party communications systems such as telephony switching systems and email servers to handle more complex communications is also an integral part of the WorkSpace system. By embodying the ability to interface with communications systems and by utilizing its core message management technology to manage documents, WorkSpace goes beyond the mere unified communications and group work technologies that are commonplace today.

While the WorkSpace system may be particularly suitable for an enterprise environment, the ability to access WorkSpace systems over the Internet enables the creation of personal WorkSpace services that can be offered by hosting and communications service providers. It integrates communications, message management, and document management functions in a single system. It is especially well suited to work with user devices that are capable of both voice and data communications. Two examples of these devices include hybrid hand-held phone-computer devices and stationary computer user devices enabled for real-time communications.

In one embodiment of the invention, accessing the WorkSpace system is similar to accessing well-publicized Internet or Web portals. While such portals typically have web-based applications such as looking up stock quotes or news along with web-enabled functions such as online shopping and online dating, one embodiment of the WorkSpace portal is more specifically geared towards work-related functions of communications, message management, and document management. The WorkSpace portal is accessible either over the public Internet or through a private data network and allows only authorized users to access the system. Once within the system through the WorkSpace portal, basic functions as well as applications built upon these functions are made available to the user. In its most basic form, a user can access various message types, communicate or send messages across multiple media, and access documents made available to the user. The WorkSpace system, however, is designed to accommodate more complex combinations of these functions that are customized for specific individuals or processes. These combinations are essentially custom-developed applications available to users who access them through the WorkSpace portal.

Integrated Document and Message Management

While the message management functionality of the WorkSpace system is valuable by itself, the system utilizes message management as a tool to make more efficient work processes that require both document management/transfer capabilities as well as message management/communications capabilities. Many such processes are handled today as two separate sub-processes and often by two separate applications one to handle message management and communications and another to handle the management of documents and data. These processes generally involve multiple tasks and/or queues.

By way of example, consider a message (voicemail or email) sent by a customer requesting an order or a completed order form (fax or Internet-based form) to purchase a product or service. In FIG. 5, the voicemail and fax would come to the WorkSpace system through voice-network connected user devices 560 and the email would come from a data-network connected user device 555, typically a computer tied to an email server. The Internet-based form would be stored on a data-network connected data storage device 550 that the user would access over the Internet, complete, and then forward to the WorkSpace system. Many fulfillment processes for customer orders require multiple tasks involving multiple individuals and queues. As a first step, the message management platform could either attach the message to or embed it within the company's order form. It could then be sent automatically to a queue requiring the first fulfillment task. These two steps would result from software instructions within the WorkSpace system. This is but one example of applications that incorporate message management and document functions. Since the message itself is now part of the order form, the fulfillment person could even review the message if they want to confirm certain details from the customer's message.

Furthermore, in one embodiment, a call may be generated to the customer, either indirectly through the message if the message contained a call-back number, or directly through the communications interface of the WorkSpace system. Communications software within the WorkSpace system would allow such communications as long as WorkSpace systems are connected to communications switching and routing equipment either directly or indirectly through communications networks. The first fulfillment person may attach a voice file to the order form to clarify any special instructions with their own call-back number for the benefit of the person handling the next task or queue. This approach also allows the customer to find out by telephone or over the Internet the particular status of their order which is easily identified by the task or queue. The user essentially accesses the WorkSpace system through a voice-network connected or data-network connected user device 580 such as a telephone or a computer. An extension of this approach is to have a voice recognition algorithm convert the customer's initial phone order onto an order form with the voice message still attached to the order form and available for validation by a fulfillment person. One example of this type of order process is prescription call-ins to pharmacies by physicians. If this were the application contained with one embodiment of a WorkSpace system, voice recognition software embedded within the system would complete the prescription order form within a certain degree of certainty. The attached voice message would be available for validation of the order but filling out the order would be at least partially completed.

Another example of a process where message management and document management functions are integrated involves sorting documents based on the sender's characteristics or the document's characteristics to a pre-specified location. In a telephone call context, the ANI or the DNIS associated with a telephone call would determine where the file would be placed. For example, consider the above example of physician prescription call-ins. A nationwide pharmacy chain could assign unique 8XX numbers for each pharmacy location. The voice messages could then be sent to and stored in mailboxes specific to a pharmacy location. Alternatively, the voicemail could be attached to or embedded within a prescription order form and sent to a specific document location for the pharmacy. This involves specific routing and forwarding instructions 520 that would send the document to a data-network connected data storage device 565 that is accessible by pharmacy staff over voice or data networks.

As a general proposition, characteristics of documents and messages may determine where they are stored or sent (based on user instructions). For example, the type of document attached to a message or otherwise sent to a user could also determine where the document is stored. A user may wish to store all spreadsheet files that they received in a specified location. Another user may specify that both messages and documents from different sources be stored together or sent to the same location. Similar instructions may also be dictated by work processes as opposed to users. Context-specific applications for such routing and forwarding 520 could easily be developed through the core message and document management software within the WorkSpace system.

A final example of integrated document and message management functions involves individuals accessing documents based on certain summary characteristics and requesting over the telephone that these documents by sent to designated recipient locations (e.g., fax machine or email address). For example, an individual may request that a paper titled “Voice-over-IP White Paper” in one of their directories be sent to their boss's email address or to the fax number of a hotel where a colleague is staying. Even documents that are external to a specific WorkSpace system could be accessed and managed in a similar fashion. Security for access to external documents, however, would be an added consideration.

Integration of document management functions with message management and communications capabilities in a single system is what the WorkSpace system enables. In its simplest version, documents are accessed over a data network (including the Internet) and managed with message management functions. More limited access and management of documents is also possible over the telephone. The optimal use of the functionalities within the WorkSpace system involves integration of communications, message management and document management as required by particular work processes or as dictated by user preferences. The use of a message management platform as an engine for document management, all within a unified portal framework, is advantageous.

Integration with Third Party Applications

Document management is perhaps the most critical application that is tied to communications and message management. However, other third-applications that work on or with generally used computer operating systems could also be easily integrated with the WorkSpace system through its web server functionality. This capability also facilitates integration with third-party data management applications.

In one embodiment, integration of third-party applications within a WorkSpace system takes the form of a “platform” 150 within the WorkSpace portal. Users may determine the choice of applications to be integrated in the WorkSpace portal. Such integration is possible in WorkSpace enterprise environments 270, carrier environments 370, and stand-alone environments 470. Examples of third-party applications that may be integrated within a WorkSpace system and incorporated in a WorkSpace portal include applications that provide real-time stock quotes for a brokerage firm or breaking news information (online wire service) for a media company.

Resolving Conflicts in Routing and Filtering

• 1. General Background

Routing rules specify what to do with a particular message or document. Where should a message be sent and how? Where should a document be stored? Filtering rules on the other hand make a determination about message or document characteristics. For example, is a message or document from someone who is a friend? What is the nature of a message or document if the sender is also a work colleague? This is important because users may specify different rules for messages and documents from different groups of senders. Arguably, the above distinction between filtering and routing is somewhat arbitrary. For example, the time of receipt is both a characteristic of the message or document as well as a possible condition for its routing. The distinction, however, is analytically useful. Once users are allowed to specify routing rules and filtering rules, conflicts between and among such rules are inevitable, especially as message and document types and rule-triggering conditions multiply. The question then is how to resolve them. One answer is never allowing users to specify conflicting rules. While appealing, this solution requires the system to anticipate all conflicts and for the user to isolate easily the source(s) of all conflicts. These requirements make the use of routing and filtering rules less appealing.

One embodiment of the WorkSpace system employs the following solution. “Small” conflicts should be resolved intelligently by the system while only “large” conflicts should require user intervention or default resolution scheme. Consider a user who specifies that calls to their office phone from “friends” between 5 p.m. and 7 p.m. be routed to their home phone. They may also specify a second rule that specifies that phone calls from “work colleagues” between 6:30 p.m. and 8 p.m. be routed to their cell phone. Suppose that John who is both a friend and work colleague calls at 6:55 p.m. This is an example of a “small” conflict assuming a conflict resolution threshold of 30 minutes. Since John is both a “friend” and “work colleague,” the two rules clearly conflict—the first requiring that the call be directed to their home phone and the second requiring that the call be directed to their cell phone. Given the 30-minute threshold, however, the conflict would be resolved automatically since the second rule is “more or less” dominant and the call would be sent to voicemail. The second-rule is dominant because the 30 minutes (between 6:40 p.m. and 7:10 p.m.) centered around 6:55 p.m. is contained entirely within the second rule while only 20 minutes (between 6:40 p.m. and 7:00 p.m.) is contained by the first rule. With the same set of rules but with a threshold of 10 minutes, a call from John at exactly 6:40 p.m. would result in the two rules being equivalent. This is because a 10-minute window centered around 6:40 p.m. (between 6:35 p.m. and 6:45 p.m.) would be contained entirely within both rules. When no one rule is “more or less” dominant, some default resolution method such as “send the call to voicemail” would have to apply. The above situation would be an example of a “large” conflict.

It is difficult to anticipate the possibility of the above conflict when the user is entering their call routing rules. In fact, it is not clear at all that the user should be prohibited from entering the second rule because there are many situations where the two rules (despite overlapping times) would not conflict. By contrast, if a user first specified that calls from “friends” between 5 p.m. and 7 p.m. be sent to their home phone and then specified in a second rule that calls from “friends” between 6:30 p.m. and 8:00 p.m. be routed to their cell phone, the system would consider the second rule to be a “large” conflict that required user intervention. The system would generate an error message that prevented the second rule from being specified.

In one embodiment of the invention, to accomplish the type of conflict resolution described above, rules are first converted to mappings between multi-dimensional real number spaces. Each variable in each condition is then mapped to a part of the real number line and associated with a statistical distribution centered at a numerical value (real number). Similarly, outcomes in each rule are mapped to a statistical distribution. Conditions associated with each rule are mapped to a multi-dimensional region made up of the regions for each individual variable. In each specific sample of variable values, an approximate outcome of the rules is computed using a resolution method. This is illustrated in FIG. 15. The outcome is then compared with outcomes prescribed by the rules to determine the amount of conflict present in the rules in that specific situation. For small conflicts between applicable rules, the method determines a solution that approximates user-supplied instructions on the disposition of each message. For large conflicts as determined by a user- or system-specified parameter, the method informs the user of the specific rules that cause large conflicts. The method updates the degree of large conflicts while the user adds and removes rules. One embodiment of the WorkSpace system detects and resolves message and document routing and filtering rule conflicts using the following method, outlined in the flowchart of FIG. 10:

• 1001. Convert variables in the conditional part of each rule to a value in a statistical distribution centered at a point in the real line and convert each outcome also to a numerical value in the real line.
• 1002: Map all conditions applicable in a particular time and space locality as a region in N-dimensional space.
• 1003: For each time-space region, determine the outcome of applicable rules using a resolution method.
• 1004: Compute the distance of the outcome value from each of the possible values of outcome variables from rule-specified outcomes using a Euclidean metric.
• 1005: Compare the distance of outcome variables with a specified threshold to determine if conflict is small or large.
• 1006: If the conflict is small, use the outcome of the resolution as the value of the outcome and use the resultant value to manage messages and documents within the specific time and space.
• 1007: If the conflict is large, determine the rules that participated in the decision. Iteratively compute the distance of the outcome variables from rule outcomes as user changes the rules that caused the large conflict.

Users of the WorkSpace system are likely to specify rules to route, store and otherwise handle messages, including those created by telephone, fax, voicemail, email, and short messaging systems. They may also provide rules to route, store and otherwise handle documents. These rules apply to a combination of time and space constraints. The rules instruct underlying transmission, retrieval, and storage systems to manage these messages and documents based on those rules that apply at any particular time and location.

Each rule describes a specific set of actions corresponding to a specific time and space location. Individually, each rule is assumed to provide non-contradictory information about the disposition of any applicable message or document. However, when creating a rule, it is difficult for users to determine if one rule may conflict with another. Consequently users may create rules that instruct the underlying system to perform conflicting actions. Indeed, the likelihood of such conflicts is so great that one may safely assume that they will arise with most users.

The method described herein overcomes this limitation of rule systems for disposition of messages and documents in message and document management systems. It applies to management rules where conditions for the application of each rule are based on a location in space and time. It applies to the management of a variety of messages and documents that arrive at a particular location (i.e., communications or data storage device, in a particular format, within a specific time period). The method determines a disposition of each message or document according to an approximate evaluation of all possible actions. In situations where such an action would vary significantly from the prescribed outcome, the method determines that rule conflicts are too large to provide a reasonable approximate outcome and instructs the user to avoid such conflicts in their rules for managing messages and documents.

A related consequence of the method here is in managing filtering rules. Filtering rules may apply to the outward characteristics of messages and documents, but may also apply to the content of the messages and documents. These rules decide on the disposition of a piece of information on the basis of conditions that involve variables in time and space, including an information space. Filtering rules may be interpreted as involving mappings between multi-dimensional spaces of real numbers. When users create filtering rules, they may create conflicts between these rules. The method described here resolves between these conflicts to produce approximate actions. The method also advises users on filtering rules that may create large conflicts. Under such advice, users may tune filtering rules to lower the level of conflict between rules.

2. Resolving Conflicts in Message and Document Routing

Communications and data management systems offer users a variety of devices and methods for exchanging messages and managing documents. While most communications and document management systems were designed with a view of creating and delivering messages and documents using similar devices and platforms, the proliferation of devices and methods of communication and data management have created the need to deliver messages and documents created on one device to a variety of target devices or locations. Therefore, messages and documents sent to a device may be routed to a different device and location based on preferences selected by the user. These preferences are often expressed in terms of rules.

Rules consist of conditions and consequences. Conditions usually involve statements that contain variables. When the variables in a condition fall within specific ranges of values, the rule is applicable (or said to “fire”). A rule also contains one or more consequences. Consequences consist of specific actions. When a rule fires, the actions listed among the consequences should be carried out by the system that utilizes the rules. Rules in a message and document management system generally determine how messages and documents should be handled under specific conditions involving time and space. Here space is generally described in terms of locations and devices and time is described as time periods.

A rule may be statements such as “If I get a phone call on my office phone between 5 p.m. and 10 p.m., and if the phone call is from a friend, then forward that call to my home phone.” In this rule, the variables in the conditional part of the rule include: (a) a time period between 5 p.m. and 10 p.m.; (b) a device that may be considered as location, i.e., office phone; and (c) an originator that may be considered as another “location,” namely a friend. The consequence in this rule involves: (d) a location, i.e., home phone; (e) an action on the home phone, i.e. ring the phone to get immediate attention; and (f) an implicit specification that the time period involved is the same as the time period in the condition.

In many situations, rules are defined by the provider of a service. For example, a telephone service provider may activate a “call waiting” tone to a user already using a phone—the determination of when to supply this tone is made by rules created by the provider. With some systems, however, users have the ability to create rules that personalize or customize the way messages are delivered.

The method described here generally applies to situations involving rules created by users. Unlike rules created by careful analysis, users tend to create a variety of rules in an ad-hoc manner. These rules are interpreted in a strict manner by message and document management systems. Due to unintended interplay between rules, the behavior of a message or document management system may not conform to a user's expectations.

There are situations where rule interpretation does not produce correct message or document management solutions. The following examples consider some such situations.

1. Rules are often evaluated based on hard boundary values. For example, a rule that specifies calls to be routed to a home phone number starting at 5 p.m. would not apply at 4:59 p.m. As a result, a user may not get a call that came in at some boundary value as illustrated above even though that value was close to the time a rule would have applied.

2. Rules are generally interpreted in a linear order. For example an older rule that calls should be forwarded starting at 5 p.m. will need to be removed to activate a new rule that says calls should be forwarded after 6 p.m. Often users have difficulty understanding such interplays in rule execution order. The result is that the older rule (that the user may have forgotten) overrides the newer rule that was recently created by the user to address specific needs.

3. A rule may conflict with another rule when interpreted in a strict way. For example there may be a rule to send calls to the office from 8 a.m. to 5 p.m. and another to send them to the home phone after 4 p.m. Rule systems generally do not interpret what needs to be done from 4 p.m. to 5 p.m. Here again users have trouble understanding the interactions of various rules.

4. If rule boundaries do not cover a specific situation, a rule system may do nothing. For example, there may be a rule covering the time period from 8 a.m. to 5 p.m. to send calls to the office, another starting at 6 p.m. to send calls to the home phone. But there is no interpretation of what to do at 5:02 p.m. and at 5:58 p.m. even though there are reasonable solutions in both situations.

The problems of rule application have been addressed using various forms of approximate reasoning. These may include Neural Networks, Fuzzy Logic, Probabilistic Reasoning and some lesser-known methods such as Belief Networks. All of these methods try to overcome the limitation of strict reasoning. Each method used varies in terms of how it carries out approximate reasoning.

While the different approximate reasoning methods differ in terms of their methods, they generally try to find a conclusion by simultaneously evaluating multiple pieces of evidence. When multiple pieces of evidence are considered in user-created rules, conflicts may also be present. The method here deals with conflicts that arise from evaluating multiple conditions simultaneously when performing approximate reasoning.

One embodiment of the method also tries to consider multiple conditions using a method that can be adapted to different approximate reasoning methods. In one preferred application of the method here, a form of reasoning related to fuzzy logic is used as the approximate reasoning component. The method described here differs from other methods in one key respect—in managing messages and documents, the method described here is aware of whether the conflicts it deals with are too large. Hence the method is able to determine whether an approximate conclusion is reasonable and therefore alert the user that the conflicts may be too large to be overcome by a selected approximate reasoning method.

3. Resolving Conflicts in Message and Document Filtering

Filters are message and document management screening devices that attempt to select messages and documents from a pool of all available messages and documents. Filters accomplish this task by evaluating properties of messages and documents. The properties considered by filters for managing messages and documents include time and space characteristics. Filters generally involve properties of messages and documents but may also be related to their content.

Filtering rules then are instructions on how filters should be applied. These rules contain a set of conditions and a set of actions. The conditions and actions may involve a number of variables. When variables within the condition of a filtering rule are within certain ranges of values, the filter applies, or fires. As a result, variables in the action part of the rule are set to specific values. These values eventually translate to some actual actions in terms of the disposition of a message or document.

Filtering rules are generally applied to messages and documents where content may be assessed. For example, a filtering rule may be “If an Excel file arrives from work colleagues as an email attachment, detach the file and place in the ‘Work Excel’ file folder. Otherwise, do not detach.” Another filtering rule may be “If an email arrives with a subject line that mostly consists of nonsensical words, and if the sender is not in my list of contacts, then send the email to my trash folder.” Here the degree to which the subject line is made up of meaningful words is assessed as a real number value. Similarly whether the sender is in my list of contacts may also be assessed as a numerical value, i.e., a real number. The action may also be considered as a numerical value associated with the degree to which the user may pay attention to the incoming message or document. Thus filtering rules may be interpreted as mappings between multiple dimensional real number spaces.

Filtering rules are created by users or service provider organizations. Service providers usually filter only messages that are generally accepted to be promotional “junk” mail since it is hard for them to determine the value of each type of content. Individual users or organizations of users may create filtering rules to try to reduce the number of messages they need to consider.

When users create filtering rules, it is hard for them to assess and anticipate the potential conflicts between rules and their resultant actions. The following are some of the conflicts in filtering rules that may result in unintended consequences while applying rules. Such conflicts in user-created filtering rules arise especially when multiple conditions need to be considered. The following are some of the situations where conflicts arise.

1. A filtering rule may specify an ad-hoc numerical value for a filtering action. For example a rule may specify that if a message contains three occurrences of the word “price” that it should be considered as junk. However there may be other evidence along with this word (such as that this is in direct reply to a message sent by the user) that may indicate that this message should get immediate attention.

2. Filtering rules are also generally applied in the order in which they are given. This produces unintended results since earlier rules have precedence, a fact that may not be clear to users especially if the earlier rules are “legacy” rules. In this case, the conflict is that older rules should be given greater weight in an overall estimation of a filter's decision.

3. Rules may be directly in conflict. This frequently happens when merging rules created in different situations such as work-time filtering rules combined with personal-time filtering rules.

4. Filtering rules often do not cover all situations. This leads to further conflicts as users try to create rules without sufficient consideration of potential conflicts. This is often a problem for example in unsolicited email filtering (including rules created by service providers).

5. Since filtering rules are hard to write, users often combine rules created by others. This combination is done without understanding the situation when the rules were created and results in unintended consequences. This situation is often seen when Internet Service Providers combine lists of suspect sites, resulting in unintentionally blocking legitimate sites included within the general domain.

Conflicts within filtering rules are resolved using the method described here. In the case of filtering rules, variables are evaluated in terms of positions within a vector space of multi-dimensional values. This mapping results in some clusters; data outside of these clusters generally are mapped to one of these clusters. Clusters are created both for variables within conditions of the rules and for variables involved in the consequences of rules (i.e., actions). A vector space is an N-dimensional space; a two-dimensional space is illustrated in FIG. 13. Each dimension of such a space consists of data values in that dimension. The data values generally are close to each other while some may be further from the majority of values. This is illustrated in FIG. 11. In two-dimensional space, a cluster is illustrated in FIG. 13 and FIG. 14 where a cluster is the set of points that looks like a shaded region. The darkest parts of the shaded region include the majority of points in the cluster; there are fewer points in the less densely shaded parts. Mappings between clusters are illustrated in FIG. 15 where each of the curves lines going from left to right indicates a mapping. A mapping associates points representing variables in the conditional (“if”) part of the rule with variables in the consequence part of the same rule. When there are multiple rules, there will be a corresponding number of mappings.

When a specific message or document is evaluated by the filtering system, a set of rules applied to a set of clusters fire in response to conditions in the rule. This is evaluated using an approximate reasoning system that may be related to fuzzy logic or neural networks. The resulting conclusions are compared to clusters of outcomes. If the distance is too great, the rules involved in this outcome are shown to the user to determine whether some of them may be adjusted or removed. FIGS. 16 and 22 illustrate this distance with circles. Values falling within the circle are within the expected distance of a centroid, the center of gravity of the two-dimensional region. This process can be continued until outcomes are close to one of the outcome clusters.

The method described here is different from other approaches to filtering rules in the way conflicts are removed based on whether conflicts are large or small based on user- or system-specified criteria. The method includes an iterative refinement procedure that adjusts rules until conflicts are within user-specified bounds. A flow chart of this iterative procedure is illustrated in FIG. 10.

One embodiment of a high level method underlying the WorkSpace system routing and filtering of messages and documents is detailed below. The numbered items in this method (numbered 1-7) correspond to the numbered steps shown in FIG. 10. The variables in Step 1 of the method are those that appear within rules. The rules here may be related to filtering and routing of both messages and documents. The variables are converted to numerical (real number) values that correspond to the degree of membership in a representative set. This can be done using a possibility value as in fuzzy logic that can be derived from a probability value associated with a statistical distribution.

As an example, we may consider a variable that represents the time that a solicitation phone call arrives at a home phone. Most of these phone calls may arrive around 7 p.m., but other calls may arrive as early as 4 p.m. and as late as 10 p.m. There may be a few calls before 4 p.m. and after 10 p.m. In this case, the probability of a phone call at home may be derived from a distribution of the frequency of such calls. It may be pictured as a normal distribution as shown in FIG. 11.

For computational convenience in this method we convert the distribution here into a triangular profile as illustrated in FIG. 12. The method can determine a degree of membership of a variable “solicitation phone call arrives at home” based on this distribution by picking the value of the triangular profile at each point. The values may be set so that the value at 7 p.m. is 1, and the values before 4 p.m. or after 10 p.m. are zero.

As a result, if a rule contains a condition that “If a solicitation phone call arrives at home and (other conditions) then (do the following actions)” then this can be converted into a numerical mapping where the value of the “solicitation phone call” is now converted into a numerical value. Other variables may also be converted, generally based on an estimation of a degree of membership in some set of values. The choices of these conversions are implementation-dependent and are generally guided by distributions of values as indicated here.

In Step 2 of FIG. 10, we consider several of these variables simultaneously. Each of these variables has distributions. Considering these distributions as degrees of membership we can consider the joint distribution of several variables. If we consider only two variables, such a distribution involving two variables may be pictured as a shaded grid as shown in FIG. 13, where the shading is darker in some places and lighter in some other places. The darkest shading represents the region where both variables have the highest possible values.

If a rule has two variables, then each rule says that the darkest region of the grid is mapped to a value for each variable in the action part of the rule. If the values of the variables do not fall within the darkest region, then the rule does not apply according to conventional rule-based procedures. But in approximate reasoning, the rule may still apply when values are outside of the darkest region of the values of the variables. The values may not be distributed near the center of space, but may be centered on another part of the two dimensional space as pictured in FIG. 14.

Before we consider Step 3 of the procedure in FIG. 10, we determine the list of regions of space. In the two dimensional case pictured above, this means we perform steps 3, 4 and 5 for each small square region within the large grid shown above. For Step 3, for each such region, we evaluate rules that may involve the pictured variables. Assuming that the outcomes consist of two variables also, this means that each rule maps regions in the condition space, as pictured above to a similar outcome space. In FIG. 15, the outcomes or consequences are shown on the right side and the conditions are shown on the left side.

In the pictorial representation shown in FIG. 15, a region in the condition space is shown as being mapped to three different regions in a consequence or outcomes space. There is greater or lesser value associated with the conclusion in each mapping, with the darker colors indicating greater certainty. Based on approximate reasoning such as fuzzy logic, we can arrive at an overall value in the outcome space as a resolved value. In the picture above, the black square without an associated arrow (“outcome square”) represents the resolved value from all of the different mappings.

Each rule is a mapping; the resolved value is not exactly the value predicted by any of the rules individually. The resolved value is also not necessarily at equal distance from all the outcomes of rules. In FIG. 15, the outcome square is closest to Rule 1 in the outcome space, indicating the greater influence of the rule that fires with the greatest strength.

At Step 4 as shown in FIG. 10, we consider the distance between the outcome value represented by the outcome square and the values predicted by each of the rules. Since the outcome square is not exactly the value predicted by any of the rules, this outcome is in some conflict with each of the rules pictured here.

At Step 5 as shown in FIG. 10, we consider whether conflict between rules is too great. There is a threshold of distance of the outcome from the predicted outcome from the rule that may be set by the user (or the administrator of a system.) This may be considered as a Euclidean distance, i.e., the distance between two points in N-dimensional space. This can be evaluated by means of a simple formula for two-dimensional space: Euclidean Distance from (x₁, y₁) to (x₂, Y₂)=Square Root of ((x₁−x₂)²+(y₁−y₂)²). The formula for N dimensions is similar.

Here (x1, y1) is a point in two-dimensional space and similarly (x2, y2) is also a point in two-dimensional space. In practice, we will consider square regions in space, thus instead of considering specific points, we will consider small square regions centered on these points. The distances are indicated in FIGS. 16 and 22. In FIG. 22, the circle on the left for instance indicates the set of points that are within some distance of the center, marked as “2” in the Figure. The point marked as “A” in FIG. 22 is within the threshold distance from the point “2”. Any point in two-dimensional space that falls within the circle on the left is within the threshold distance from the point “2”.

The regions in FIG. 15 may be considered as points in two-dimensional space. One of the squares within the grid shown may be a square of some size with center at a point such as (x2, y2) considered in the formula above. The distance is computed as shown using the centers of the square regions; then compared to the distance from each of the rule outcomes and the outcome square. This distance can be considered as a circle centered at the center of the square representing the outcome for each rule. This is shown in FIG. 16.

There are three circles shown in FIG. 16, all of the same size based on the threshold distance specified by the user or administrator. In this case we can see that the circle representing distance from the outcome of Rule 1 (1610) reaches (in fact contains) the black square. The circle representing Rule 2 (1620) also reaches the outcome square (though barely) within the defined threshold level and the circle for Rule 3 (1630) does not reach the outcome square at all. We consider further actions based on this result at Step 6 as shown in FIG. 10.

At Step 6, we note that Rule 1 and Rule 2 are in conflict but the outcome is not in great conflict with the rules. But at Step 7, we will have to either remove Rule 3, or adjust the conditions in that so that the circle around the outcome of Rule 3 reaches the outcome square (within the defined threshold) computed with the newly formulated rule.

The process of refining rules continues iteratively until the rule set does not produce large conflicts on all regions we consider. This process may be guided by a user, but it also may be automated if we allow for the algorithm to adjust the values of conditions and consequences so that distances found at Step 5 are not too great.

The user may choose to increase or decrease the threshold associated with Step 5. If the threshold is increased in this example, then the circle surrounding the square representing Rule 3 outcome (1630) will increase in diameter—it may increase to touch the black square. If the threshold is decreased, then the circles shown will decrease in diameter and the circle surrounding the square representing Rule 2 (1620) may also not touch the black square. Then the conflict with Rule 2 will also be considered too great and Step 7 will also need to adjust or remove Rule 2.

One embodiment of the method will consider more than two variables in general, hence the squares shown here will be “cubes” in N-dimensional space and the circles will be “spheres” in N-dimensional space. The condition space shown on the left in the previous figure may be N-dimensional while the outcome space may be M-dimensional and N and M may not be the same.

The methods described here can be described in greater detail in terms of an implementation using specific mappings of variables to numerical values and specific approximate reasoning method. One preferred approximate reasoning method is based on fuzzy logic. The application of the method to filtering differs from the application to routing only in terms of the mapping of variables to numerical values—the conflict resolution method is the same in both applications.

4. Example of Rule Conflict Detection and Resolution

Consider the following situation involving message routing. Rules specified by users may involve conflicts. We consider an algorithm to resolve situations involving these conflicts.

Bill is a member of both “Friends” and “Work Colleagues” groups. Jane has specified two rules for call routing.

Rule 1: If Friends call between 6 p.m. and 8 p.m. send the call to my home phone.

Rule 2: If Work Colleagues call between 7 p.m. and 9 p.m. send the call to voicemail.

Bill calls at 7:30 p.m. How should the call be routed?

Below is an explanation of the proposed conflict detection and resolution for this example. The example will later clarify the following aspects of our conflict detection and resolution algorithm:

• • Conflict resolution applies to the time when Jane is specifying rules, the result of conflict resolution is utilized when handling a call as required in this example.
  • Calls are handled using fuzzy logic algorithms which are well known but have not previously been used in selecting the rules to apply to filtering and routing of messages and documents.

Following is a brief overview of fuzzy logic. The application of fuzzy logic to the specific call routing situation here may be new. In conventional logic, a statement is either considered as completely true or completely false.

Fuzzy logic considers a statement in terms of whether something belongs to a set. Then also, using conventional logic we could take the view that an object is either in the set or not in the set. In fuzzy logic a real-valued function is considered that assigns a value to the membership in a set in terms of the degree of membership of an object in a set.

One usual example is to consider a statement “the outside temperature is pleasant.” Depending on the location, the temperatures that are “pleasant” may vary. But let us assume that if the temperature is 70 degrees, nearly everyone considers that to be pleasant. If the temperature is either less than or greater than 70 degrees, it may be considered pleasant by fewer people. As the temperature differs significantly from 70 degrees, fewer people will consider it pleasant. Thus for any temperature, we may assume a value indicating the level of certainty that this temperature is pleasant. Instead of performing deduction based on the absolute certainty that temperatures are either pleasant or non-pleasant, fuzzy logic uses these real number values of certainty in logical deductions involving rules.

In the context of the rules given in the example, we can assign a degree to which conditions of each rule are valid. Considering Rule 1, we could assign a real number to the degree to which conditions of this rule are true. Since there is only one condition, whether a call arrives between 6 p.m. and 8 p.m., we can consider a membership in this set using a simple triangular function. The specific function may be implementation dependant and may be related to data on call distribution, but for now we just pick a simple triangular function that indicates the degree to which a time belongs to the conditional part of Rule 1.

Thus as shown in FIG. 17, if a call arrives at 6 p.m., we consider the Rule 1 condition to be true with value 0.5, at 7 p.m., the value is 1.0, at 8 p.m. the value is again 0.5. Earlier than 5 p.m. and later than 9 p.m., the conditions of the rule do not hold. The value then is considered to be zero. This is just one example of interpreting the condition in Rule 1, the shape of the triangular function shown here may be varied by bringing its lower corners closer to 6 p.m. and 8 p.m.

Now let us consider the consequence of Rule 1. This consequence should be either true or false in a specific situation. But before we get to determine whether it should be true or false, we will give it a membership value similar to the membership value for conditions. One way to assign a membership value to the consequence interpreting this the same way we considered the statement “the temperature is pleasant.” We will consider the act of ringing the home phone based on whether people consider this intrusive. For the sake of this discussion let us assume that most people consider a ringing home phone to be quite intrusive, while few people consider it extremely intrusive and very few people consider it entirely welcome. Then we may consider “ring the home phone” as a triangular function based on an axis where intrusiveness ranges from very low to very high.

In fuzzy logic, generally seven discrete values are recognized: very low, medium low, somewhat low, even, somewhat high, medium high and very high. This range is usually shifted so that we consider the low values to be negative, even to be zero and the rest to be positive. We generally label the values NL, NM, NS, ZE, PS, PM, and PL. Based on this scale, we may construct a triangular function as in FIG. 18 that indicates the perception of intrusion of ringing the home phone. This function may be different from the one shown in FIG. 18 based on our knowledge of people's likes and dislikes. In FIG. 18, we are assuming that a ringing home phone is considered intrusive by a medium high proportion of people, while almost no one considers it to be welcome. We can shift this function in various ways depending on adjustments to this assumption.

The standard fuzzy logic deduction step involves two stages. The first stage is a minimization (the second stage is not quite a maximization problem). The first stage involves examining the degree of membership of the variables in the conditional part of a rule, and minimizing over these to take the smallest degree of membership. As part of the first step, we also determine the degree of membership in the consequent variables of each rule. The second step involves combining the degrees of membership of each consequent variable and creating a discrete value by combining contributions from multiple rules. The discrete value can be computed using various methods. The most common method involves finding the x-coordinate of the centroid of the regions of support from all the rules.

In the example here, both rules have only one condition each, therefore there is no need to minimize over the degrees of membership of each variable in the conditions. For Rule 1, we combine FIGS. 17 and 18 above to get the degree of membership in the consequence, assuming that the call is coming in at 7:30. FIG. 19 shows the condition and the consequence together, the x-axes of the two variables have nothing in common, but the y-axes are aligned (we generally normalize the values of the triangular functions so that their maximum values are always 1.0 and minimum values are 0.0.) The shaded region shows the support for the action of Rule 1. The standard procedure here is as follows:

1. Compute the value of the condition variable at the specific location. So here the variable's value is 7:30, so we draw a line from x-axis value 7:30 to the corresponding functional value.

2. Find the minimums of all y-values for all the conditional variables. In this case there is only one variable so the conditional value is just the one value we have for the single variable.

3. Find the corresponding value in the function for the variable in the rule's consequence. (The drawing makes it look higher than it should be here, but the idea is that we cut off the triangular function at the right height.)

4. Consider the shaded region as the support for Rule 1. We have to combine the supports for all rules that apply at a later step.

If this were the only rule, then the centroid of the support region will have x-axis value=PM, therefore we can conclude that Rule 1 sanctions a PM activity, that is, to ring the home phone. But we have to consider the effect of Rule 2 also.

Now let us consider Rule 2 in the same way. For simplicity, let us assume that the condition in the rule is treated the same way as in Rule 1 except for a change in the triangular function. The consequence, in this case voicemail, may be placed on the same x-axis as the consequence in Rule 1, by considering the intrusiveness of voicemail (let us assume this voicemail is without notification, so that it is not very intrusive.) The triangular function here may be something that starts high at NL and comes down in value by the time it reaches ZE (this is based on the thinking that most people consider voicemail to be not intrusive at all but nobody considers it even slightly intrusive.)

Based on all the assumptions above, the operation of Rule 2 in this situation can be illustrated by a picture as shown in FIG. 20. Here the condition of the rule is shifted so that we think of the rule applying between 6 p.m. and 10 p.m. (condition of Rule 1 applied between 5 p.m. and 9 p.m.) The shaded region shows the support for the conclusion. The next step combines the two rule consequences to determine the appropriate action. FIG. 21 illustrates this combination.

In FIG. 21, each of the lines (A, B, C) indicate points (at the other end of the line as indicated by the arrow head) that are possible values for the centroid of the two regions. The different values may be obtained based on the exact shape of the two triangles, for instance the two triangles may overlap somewhat. Depending on the centroid value obtained, we compute the discrete value of the x-axis of the centroid point. Based on that value we decide on the appropriate action.

1. If the centroid is A, then the x-axis value is reasonably close to the conclusion that voicemail is appropriate. So we send the message to voice mail.

2. If the centroid is C, then similarly the action of sending the call to the home phone is appropriate.

3. If the centroid is B, we really cannot decide what action to use.

All that has been said above is fairly standard fuzzy logic; this is well known except for the fact that we are considering it for rules involving the filtering and routing of messages and documents.

The situation B above is one where the rules cannot reach a conclusion, i.e. the applicable rules are in conflict. We can of course create some fall back rule, such as “if in doubt, send everything to storage.” But that is simply an administrator overriding the wishes of the user. There is a way we can avoid such conflicting situations. The method to avoid conflicts should be utilized when rules are created.

The conflict resolution method has a parameter that may be set by the user or the administrator. This parameter is the maximum allowable distance of an obtained solution from the centroids of each of the participating consequent regions. In the example here, there are two participating regions, those corresponding to the consequences of Rule 1 and Rule 2. The distance is simply the distance of the centroid of the combined regions from the centroids of the individual participating regions. FIG. 22 illustrates this situation.

Here the points 1 and 2 indicate the centroids of the consequent regions associated with Rules 1 and 2 respectively. The two circles centered at these points indicate the maximum allowable distance for a solution to be from the points 1 or 2. In this case solution B is not acceptable to either Rule 1 or Rule 2. The other solutions are acceptable according to the designated distance.

Even if situation A or C is obtained, the conflict resolution algorithm will consider whether the centroid that is obtained is too far from the centroid of the region within any of the triangles. If the distance indicated by the circle radius is smaller, either A or C could also indicate a conflict. Distance in this case will be a simple two-dimensional distance. In more complex cases the N-dimensional regions replace the triangles illustrated here. In this case, the distance may be the N-dimensional Euclidean distance between points.

One embodiment of the conflict resolution method works during the time that rules are created. Consider the interaction where Jane creates rules. Initially there are no rules. Jane creates Rule 1. There is no possible conflict with anything else since this is the first rule.

Now Jane creates Rule 2. At this point, our algorithm computes the consequence for the system of rules using a set of sample values. We may consider several sample x-axis values for each of the variables and compute the result of applying the rules at each of these values.

Since the algorithm computes the result of applying rules, it will find a situation where the centroid found is too far from the centroid of individual regions according to the maximum allowable distance. FIG. 22 illustrates this distance by circles from the two centers “1” and “2”, the points within the each of the circles are within the distance of the corresponding centroids. An administrator may set the maximum allowable distance but it can also be a parameter that is adjustable by the user. Thus the method knows that there are conflicting situations. There are a number of possible solutions to this conflict. The user may change the rules in many ways as shown below. If the user adjusts rules using 1, 2, 3 or 4 below, then the conflict detection will be run again. This process continues until all conflicts are resolved.

The following actions summarize possible responses to conflict. The user or administrator may choose only some of these solutions. The algorithm itself is used only to detect conflicts—any mix of the following methods may be used to resolve conflicts.

1. Jane can simply remove one of Rule 1 or Rule 2.

2. Jane can adjust Rule 1 or Rule 2 to be a different range. The conflict detection algorithm then re-computes the samples to check for conflicts. If, for example, Jane moves the time range of Rule 2 to the left, then the support from Rule 2 at, say 7:30 p.m., will be so low that the centroid will get pulled into the region close to the centroid for Rule 1.

3. Jane can be shown different times of conflict and can choose to deactivate Rule 1 or Rule 2 during these times of conflict. In general this means that Jane selects sets of rules to apply at different times based on our report of conflict periods.

4. Jane can adjust the maximum allowable between the centroid and the consequence (assuming that the system allows users to do this). This may make the result close enough.

5. Jane can leave the conflict in place. The system can choose to interpret conflicting situations arbitrarily (for example, we can pick the first rule that applied and use that as the only rule, or it can pick the nearest shaded region to the actual centroid).

In this example, assuming that the user prefers lesser intrusion, and assuming the shapes of distributions given in FIGS. 17 through 22, the call will be sent to voicemail because Rule 2 will have more impact than Rule 1.

There are several complications not considered in this example which, in one embodiment, are accommodated within the context of filtering and routing messages and documents:

1. Rules with multiple variables among conditions have not been considered. This changes the fuzzy logic algorithm by minimizing over multiple variables before computing the support in the consequence.

2. The rules and their functional forms may be influenced by data on what sort of calls are likely to occur at what time.

3. Intrusiveness is only one dimension of a possible set of variables we may consider, so that the conflict resolution may be taking place by considering regions in N-dimensional space (as illustrated in the earlier write up about this method).

4. The rules are subject to cultural interpretation, for example the level of intrusiveness of different access methods may vary based on demographic characteristics.

5. Application of Routing and Filtering Rules to All Message and Document Management Functions and to All Types of Messages and Documents.

One embodiment of the WorkSpace system allows the application of the rule conflict resolution algorithm described above to all message and document management functions and to all types of messages and documents. In addition, the user may specify their rules online and in a more limited context choose their rule-set over a telephone device. The WorkSpace system, therefore, allows users to specify rules to access, send, forward, and otherwise manage both messages and documents. It also permits users to specify rules for notification of messages and documents. The WorkSpace system also allows users to specify different rules for all message types that can be into an integrated message/document management platform such as the WorkSpace system. Such message types include voicemail, email, text messages and pages but the functionality of specifying rules is easily extended into all message types that can be integrated into a unified messaging platform. The same is true of the different types of documents and databases that can be managed by the unified platform.

Meta Document Creation and Delivery

Documents often comprise sub-documents that may be of different types. For example, a mortgage application may consist of copies of tax documents (possibly a PDF file), an application form (possibly a word-processing file), and a spreadsheet listing an individual's assets against which the mortgage is obtained. Finally, an applicant may wish to include a personal cover letter or note along with application to explain certain irregularities in their application. On the reverse side of the transaction, the mortgage company may want to deliver to the applicant closing documents that may also consist of different types of sub-documents. Indeed, many transactions involve documents of different types that must be delivered to different parties to a transaction. Such documents today are sent as multiple attachments to an electronic message, or as stored documents on a storage disk, or more commonly, printed out and mailed to the relevant party to the transaction.

One embodiment of the WorkSpace document management engine allows for the creation of a “meta document” comprised of different message types. Its document creation software allows for the assembly of documents of various formats, thereby creating a single unified document using a simple Graphical User Interface (“GUI”). FIG. 8 illustrates one embodiment of a GUI used to create and transfer a “meta document.” The interface allows the end user to compose a personal note or letter 810 that is typically attached to a set of documents that are transferred. It also allows the user to place various types of documents 820 in sequence within the “meta document” itself. Such documents could be different types and sizes and organized in the sequence chosen by the user. The only requirement is that these documents be stored in locations that are connected to or otherwise accessible from the user's WorkSpace system. The documents may be on the user's computer, on a network shared document storage device, or even a third-party location. In this regard, this requirement is similar to the “browse” function used to attach documents to electronic mail. Security and access would be the main considerations as to whether documents could be placed within the “meta document” GUI.

Once a “meta document” has been created, two options are available for delivery of the document. The first option involves the transfer of the “meta document” to a secure Internet accessible data storage area where a password specific to the document transfer is needed to pick up the document. The sender of the message may receive this automatically generated password as soon as the document is sent. If so desired, the sender may also request that the system provide the password to the recipient. For security or convenience reasons, however, the sender may prefer to provide the password information to the recipient verbally or through some other means of communication. Once the recipient accesses the file and downloads it successfully, the sender may receive an electronic receipt notification. The foregoing process effectively replaces the overnight mail delivery of documents. The same process, of course, may be clearly used for the transfer of a single document without the creation of a “meta document.”

If security is not a concern, the sender may send the “meta document” as an electronic mail attachment or even have it faxed (text documents only) to a designated fax number location. Other delivery methods enabled by WorkSpace message management software may also be used for the delivery of such documents, depending on the size of the document and urgency. It is the combination of a “meta document” creation method combined with a delivery method that is part of an integrated message/document management system that is advantageous.

Single Management of Messages

One problem that is common among many unified communications solutions today is the need to manage messages at least twice when different access methods to messages are permitted or when messages are routed to non-system locations. The cause of this problem is the fact that equivalent messages are produced in various devices and locations. Consider a messaging system that allows users to retrieve voicemail by telephone and over the Internet. If the user reviews a particular voicemail over the Internet and deletes it, the same voicemail is typically retained as “new” in the telephone accessible area. The user is forced to manage the voicemail the next time they access voicemails by telephone even though they had disposed of it earlier. Some users may actually prefer to have voicemails accessible over the telephone even though it has been reviewed over the Internet. This may be the case where a person's secretary routinely reviews voicemail over the Internet for their boss to alert the boss if urgent messages arrive but the boss (who may seldom use a computer) may want to have all voicemail available by telephone. For the majority of users, however, the requirement of double management is a minor nuisance.

One embodiment of the WorkSpace system provides users the option to specify whether they want to manage only once their voicemails and other messages. Thus, a user who specifies that they do not want to double manage their voicemail messages would not have available to them a voicemail that was previously accessed over the Internet and deleted. This is accomplished by a set of instructions within WorkSpace message management software to remove a message from the telephone accessible message storage area once it has been deleted from the Internet accessible area.

The above described method is accomplished in the following manner. Each message has a unique name based on the recipient, type of message and time of arrival of the initial message. In various file directories, the names that identify these characteristics are retained, though the locations will have different names. When the user asks to delete a message, the action is carried out by a centralized manager of message storage. This message may be relayed by the centralized storage manager to subsidiary storage areas to remove all instances of the uniquely identified message. Each manager of a storage area then identifies the message within its storage area to delete such identified messages.

The WorkSpace system, therefore, provides a method for users to handle only once equivalent messages that are stored in or sent to different locations. The method consists of a distributed federated system of task agents that are distributed autonomous communicating processes. The WorkSpace system is organized as a collection of independently operating program units. Each of these program units operate using their own share of computer processing time and memory and can run regardless of whether other units of the program are operating. Each such program unit is called an “Agent.” Even though the agents can run as autonomously, i.e., as independent programs, they can also respond to messages they receive through a message sending medium. Internet sockets are often used to pass messages between agents, but other methods of message passing may also be used. Thus, agents are autonomous communicating processes that independently operate programs that exchange messages to coordinate their activities. When an agent receives a message it can choose to act on the message by responding to it, performing a task requested in the message or the agent can choose to ask other agents to do this or other related tasks.

In the WorkSpace system, some agents are responsible for performing specific tasks such as sending an email or handling a phone call. Agents that perform tasks are called “Task Agents.” Some agents in WorkSpace mainly perform the work of coordinating the tasks of other agents. Such agents are generally considered as “Manager Agents.” Manager agents are arranged in a hierarchical fashion, with some manager agents coordinating the management activities of other manager agents. This model of management is generally called a “Federated System of Agents.” The federated system is a way of organizing communications between agents. Messages between agents are sent through manager agents so that manager agents may decide the best way to perform the activities associated with the agent.

WorkSpace agents are independent programs that may be executed as separate programs on separate computers. Typically several of these agents, i.e. independent programs, are executed on the same computer, but they can also be organized, according to their function, on separate computers. Since parts of WorkSpace may operate on different computers, WorkSpace may be considered as a distributed program. For example, agents handling Fax services may reside on one computer while agents handling Web services may reside on a separate computer. The agents that are on different computers can work together as if they are on the same computer by exchanging messages that relate to performing tasks. For example when a Fax message arrives at the Fax server, an agent on the Fax server will inform its manager agent on the same fax server, which will then inform the manager agent on the Web server computer. This information will tell a Web server task agent to update the web pages of the user who just received the fax, even though the Web server computer never received the fax. When the user tries to retrieve the fax, a web server agent will, through a system of managers, ask an agent on the Fax server to retrieve the fax and to send it to the user's web page.

A system of these agents accomplishes distributed message management of equivalent messages through the coordination of multiple management tasks, one task for each location where the message is stored or sent. At the head of these agents is a main task manager that coordinates all task agents. When a message is managed by a task agent, the main task manager is informed that the particular task was performed. This, in turn, initiates a series of instructions to manage the same message across the system as specified by the user. The system of agents resembles a corporation with many departments to perform individual tasks. Managers within a corporation coordinate the tasks and direct tasks towards appropriate departments or individuals. Similarly, in one embodiment, the entire WorkSpace system is organized as a system of agents where agents resemble individual employees and the system as a whole resembles a corporation. This system of agents is created based on a computer program and is generally not based on any database. It may however be configured, using configuration scripts common in computer applications, to create an appropriate collection of agents based on the needs for each installation. For example a large installation may have a few dozen agents handling email requests while a small installation may have only one such email handling agent. Management agents created as part of this program determine where messages have to be sent for each task. The overall structure of this system of agents does not change depending on each user. However depending on each user, the messages that are sent between agents and the task agents that are activated change. The actual messages that are sent between agents that participate in the task are decided by the manager agents. The decisions are made by manager agents using rules that are programmed into the manager agents. To draw on the analogy of a corporation, the corporation's structure does not change based on each individual customer, but the activities done on behalf of each customer may involve a unique set of interactions and activities.

In general, the sets of messages that are accessible by telephone, over the Internet, or through other means need not be identical and these sets can be specified by a user to reflect their preferences or habits. This is accomplished either by maintaining separate message locations corresponding to each access method or marking each message to be made accessible over particular access methods. For example, a user may only want to access voicemail from work colleagues and friends over the telephone but have all voicemail available over the Internet. When messages are made available in different access areas, their status could be mirrored in each of these areas through the method described earlier. Thus, a voicemail that has been deleted over the telephone would also be among deleted voicemails in the message storage area accessible over the Internet. As illustrated earlier, it is also possible that some users may not wish to have such equivalence. If so, the main manager would not issue instructions to maintain equivalence. Alternatively, a user may want equivalence in only two locations but not in a third location. In this case, only a subset of instructions would issue.

The problem of multiple message management is more difficult to resolve in a context where the message itself has been forwarded or otherwise sent to a device or location outside the message management system. One example is where voicemail is forwarded as an email attachment to an email address. In this case, the user may access the voicemail through their email and even delete it. The same voicemail, however, remains in the telephone accessible area of most unified communications systems. The WorkSpace system addresses this issue by allowing users to specify whether to retain messages that have been forwarded to non-system destinations (outside fax numbers or email addresses) and if so, with what status to use (e.g., new or saved or old or deleted). FIG. 9 illustrates a set of voicemail messages for a user who wants to access only work voicemail by telephone, has all voicemail from family forwarded to their personal email, and requests that only non-work, non-family voicemail be accessible over the Internet.

Online Specification of Personal Preferences

Online specification of personal messaging preferences is not new. Online specification of preferences for all message and document types managed by an integrated message/document management system is new. One embodiment of the WorkSpace system allows users and administrators to specify online preferences with respect to all message and document types. Users may specify how much or how little of the message or document characteristics they wish to access over the telephone or view online. For example, a user may not want to know over the telephone whether they have received faxes. Alternatively, they may want to know over the telephone whether they have received email from work colleagues or a text message from a particular individual. Users may also specify not only what messages and documents they access but also how they access them. For example, a user may want to listen to voicemail from family first and the remaining voicemails chronologically. In fact, users can specify online virtually all preferences typically associated with accessing voicemails over the telephone. The WorkSpace system described herein goes further by allowing users to specify online access and management preferences for all types of messages and documents managed through its integrated platform. The specification of these preferences are not unlike the specification of account preferences for Internet accounts. A user's specific set of preferences comprise a subset of the user's profile that determines the particular set of feature/functionalities that are activated for the user.

Heuristic IVR Menu Options

Most Interactive Voice Response (“IVR”) systems have a limitation that can be a significant nuisance for many users. The announcements and prompts are generally fixed and do not take into account the underlying information that is to be conveyed or the user's usage patterns. This is especially true of announcements and prompts in the course of retrieving messages and information about documents over a telephone. One embodiment of the WorkSpace system implements a heuristic learning approach to this problem. For example, with the WorkSpace system, users will not hear prompts that apply to faxes if they do not have faxes. This saves time and the absence of fax prompts is itself informative. In addition, similar to online menus that incorporate heuristic learning, menus that have not been used in a while could be made hidden from the user while still available for use. This is different than simply “hiding” the options and associated prompts and announcements from the user in a fixed manner as many messaging platforms do. Rather, it is the usage of menus and choices within menus along with the presence or absence of relevant information that will passively activate the “hiding” of menus and choices. In one embodiment, different “hiding” rules are specified for different menus and even for choices within menus.

Consider a message retrieval menu that states the following: “Press 1 for Voicemail, Press 2 for Fax, Press 3 for Email.” In one variation of heuristic IVR menus, if the user did not have any faxes to be retrieved, the menu would now be “Press 1 for Voicemail, Press 3 for Email” or alternatively “Press 1 for Voicemail, Press 2 for Email.” Either version of the truncated menu could also be activated if the user never used the “Press 2” key during a period of time (e.g., one month) that is specified as a system parameter or user preference.

Messages Distributed Across Multiple Media

The use of distribution lists in messaging systems within a common medium is commonplace. For example, there are voicemail distribution lists and email distribution lists enabled by voicemail platforms and email servers. Such distributions lists may be defined by users or pre-defined for users. Such distribution lists, however, do not take into account the messaging preferences of message recipients. Some individuals rely on voicemails while others check their emails frequently. Yet others constantly engage in text messaging or two-way paging. One embodiment of the WorkSpace system allows users to create distribution lists that are cross-media. For example, a user may know that their boss checks their voicemail often but seldom checks their email. By contrast, their secretary may check emails frequently but voicemail infrequently. If that user wants to send a voice message to both parties reflecting the two recipients' preferred messaging media, they could create a distribution list that contains their boss's voicemail box number and the secretary's email address. A voicemail could be created by the user and sent to both of these destinations. The voicemail would go directly to the boss's voicemail box and to the secretary in the form of a sound file attached to an email. Given different messaging habits, the ability to create a single document but send it to different device types in different formats through the use of a single multi-media distribution list increases the probability that the recipient will actually receive and listen to messages sent by a user.

“Near-Real-Time” Communications Management

If voice communications is real-time and if regular mail and email were non-real-time communications, both instant messaging (“IM”) and text messaging (such as over wireless phones and pagers) may be considered “near-real-time” communications. Users may wish to limit the individuals with whom they communicate through these methods because of the invasive and pervasive nature of such communications. They are invasive because they intrude into an individual's privacy in a written and recorded form. They are pervasive because one can easily guess what another's text address is and certainly one's online presence is easily detected by others. While ignoring text messages and blocking instant messages are possible ways of controlling “near-real-time” communications, a more polite form that enables such communications only with those you choose may be preferred by many. This can be accomplished through the use of “double-blind” or “pseudo-address” method.

Through the use of a pseudo Internet address for text messaging, all text messages that are sent to a user arrive in a WorkSpace system and the message is then sent to the specified true text messaging Internet address. Thus, as illustrated in FIG. 23, a user could publish the text messaging address of username.txt@ company.com while the true address is username.txt@carrier1.com 2310. The user could specify their preferences to allow text messages from only certain individuals or numbers or groups of individuals 2320 to reach their true text messaging address. With respect to text messages from all others 2330, they could create a polite personalized response such as “User Name Is Not Able to Receive Text Messages at This Time” or alternatively direct all “unwanted” text messages to a message storage area 2340. A secondary benefit of this approach is the ability of users to switch to another text messaging provider with a new text messaging address username.txt@carrier2.com 2350 without having to republish their company-name-based text messaging address.

A similar approach could be used for purposes of instant messaging, as illustrated in FIG. 24. The invasive nature of instant messaging combined with the psychological discomfort to block senders affirmatively makes the “double-blind” approach extremely well-suited for instant messaging. For example, users could publish their business or primary email address username@business.com 2410 but login under a different screen name username@home.com 2420 to go online. Similar to most IM filters today, only those whom the user permits 2430 would know that the user is online and available for instant messaging. Unlike most IM filters today, however, the user would appear to these individuals as if they were online with their published email address username@business.com as opposed to their login screen name. Furthermore, no affirmative blocking of other individuals 2440 would be required.

While the foregoing has described what are considered to be the best mode and/or other preferred embodiments, it is understood that various modifications may be made therein and that the concepts disclosed herein may be implemented in various forms and embodiments, and that they may be applied in numerous applications, only some of which have been described herein.

Embodiments of the invention may include various steps as set forth above. The steps may be embodied in machine-executable instructions which cause a general-purpose or special-purpose processor to perform certain steps. Alternatively, these steps may be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

Elements of the present invention may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media or other type of machine-readable media suitable for storing electronic instructions. For example, the present invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).

Throughout the foregoing description, for the purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without some of these specific details. For example, although the embodiments of the invention described above focus on the use of Fuzzy Logic techniques for conflict detection/resolution, various alternate/additional techniques may also be employed (e.g., neural networks, probabilistic reasoning, belief networks, . . . etc). Accordingly, the scope and spirit of the invention should be judged in terms of the claims which follow.

Claims

1. A computer-implemented method comprising:

evaluating a plurality of rules for routing, filtering and/or storing messages and/or documents to determine whether a conflict exists between two or more of the plurality of rules;

detecting a conflict between two or more of the plurality of rules, the conflict having a particular level of severity associated therewith; and

identifying a resolution to the conflict if the severity associated with the conflict is below a predetermined threshold.

2. The method as in claim 1 further comprising:

rejecting one or more of the plurality of rules involved in the conflict if the severity level associated with the conflict is above the predetermined threshold value.

3. The method as in claim 1 wherein the resolution comprises implementing only one of the rules involved in the conflict.

4. The method as in claim 1 wherein the resolution comprises:

determining an outcome most likely desired by an end user; and

implementing the rules resulting in the desired outcome.

5. The method as in claim 1 wherein the conflict severity comprises either a “small” conflict or a “large” conflict and wherein resolutions are identified for small conflicts but not for large conflicts.

6. The method as in claim 1 wherein evaluating the plurality of rules comprises:

converting variables of a conditional portion of each rule to a value in a statistical distribution centered at a point in a real line; and

converting each outcome also to a numerical value in the real line.

7. The method as in claim 6 wherein evaluating the plurality of rules further comprises:

mapping all conditions applicable in a particular time and space locality as a region in N-dimensional space (“time-space region”), where N represents the number of variables associated with the rule.

8. The method as in claim 7 wherein evaluating the plurality of rules further comprises:

determining the outcome of applicable rules for each time-space region; and

computing the distance of the outcome value from each of the possible values of outcome variables from rule-specified outcomes using a Euclidean metric.

9. The method as in claim 8 wherein evaluating the plurality of rules further comprises:

comparing the distance of outcome variables with a specified threshold to determine if the conflict is below the predetermined threshold.

10. The method as in claim 9 wherein identifying a resolution to the conflict comprises:

if the severity associated with the conflict is below a predetermined threshold value, using the outcome of the resolution as the value of the outcome and using the resultant value to manage the routing, filtering and/or storing of messages and/or documents within the specific time and space.

11. The method as in claim 1 wherein the messages comprise email messages, voice messages, instant messages and/or fax messages.

12. The method as in claim 1 wherein a first of the plurality of rules specifies that messages sent from one of a first defined group of senders to a first device and/or location within a first specified time period are to be forwarded to a second device and/or location; and

wherein a second of the plurality of rules specifies that messages sent from one of a second defined group of senders to the first device and/or location within a second specified time period are to be forwarded to a third device and/or location, wherein the first specified time period overlaps with the second specified time period, and wherein, in response to receiving a message from a user who is included in both the first and second defined group during the overlap in the first and second specified time periods, resolving the conflict by selecting the outcome most likely desired by the end user.

13. The method as in claim 12 wherein resolving the conflict further comprises:

choosing either the first rule or the second rule based on where, within the overlap in the first and second specified time periods, the message is received.

14. The method as in claim 1 wherein evaluating the plurality of rules comprises performing a fuzzy logic analysis of the plurality of rules to identify conflicts.

15. A system comprising:

a plurality of agents configured to perform message and/or document management functions responsive to a plurality of rules for routing, filtering and/or storing messages and/or documents;

conflict detection logic to determine whether a conflict exists between two or more of the plurality of rules, each detected conflict having a particular level of severity associated therewith; and

conflict resolution logic to identify a resolution to the conflict if the severity associated with the conflict is below a predetermined threshold.

16. The system as in claim 15 wherein the conflict resolution logic rejects one or more of the plurality of rules involved in the conflict if the severity level associated with the conflict is above the predetermined threshold value.

17. The system as in claim 15 wherein the resolution identified by the conflict resolution logic comprises implementing only one of the rules involved in the conflict.

18. The system as in claim 15 wherein the resolution identified by the conflict resolution logic comprises:

determining an outcome most likely desired by an end user; and

implementing the rules resulting in the desired outcome.

19. The system as in claim 15 wherein the conflict severity comprises either a “small” conflict or a “large” conflict and wherein the conflict resolution logic identifies resolutions for small conflicts but not for large conflicts.

20. The system as in claim 15 wherein the conflict detection logic evaluates the plurality of rules by:

converting variables of a conditional portion of each rule to a value in a statistical distribution centered at a point in a real line; and

converting each outcome also to a numerical value in the real line.

21. The system as in claim 20 wherein the conflict detection logic further evaluates the plurality of rules by:

mapping all conditions applicable in a particular time and space locality as a region in N-dimensional space (“time-space region”), where N represents the number of variables associated with the rule.

22. The system as in claim 21 wherein the conflict detection logic further evaluates the plurality of rules by:

determining the outcome of applicable rules for each time-space region; and

computing the distance of the outcome value from each of the possible values of outcome variables from rule-specified outcomes using a Euclidean metric.

23. The system as in claim 22 wherein the conflict detection logic further evaluates the plurality of rules by:

comparing the distance of outcome variables with a specified threshold to determine if the conflict is below the predetermined threshold.

24. The system as in claim 23 wherein, if the severity associated with the conflict is below a predetermined threshold value, the conflict resolution logic uses the outcome of the resolution as the value of the outcome and uses the resultant value to manage the routing, filtering and/or storing of messages and/or documents within the specific time and space.

25. The system as in claim 15 wherein the messages comprise email messages, voice messages, instant messages and/or fax messages.

26. The system as in claim 15 wherein a first of the plurality of rules specifies that messages sent from one of a first defined group of senders to a first device and/or location within a first specified time period are to be forwarded to a second device and/or location; and

wherein a second of the plurality of rules specifies that messages sent from one of a second defined group of senders to the first device and/or location within a second specified time period are to be forwarded to a third device and/or location, wherein the first specified time period overlaps with the second specified time period, and wherein, in response to receiving a message from a user who is included in both the first and second defined group during the overlap in the first and second specified time periods, the conflict resolution logic resolves the conflict by selecting the outcome most likely desired by the end user.

27. The system as in claim 26 wherein the conflict resolution logic resolves the conflict by choosing either the first rule or the second rule based on where, within the overlap in the first and second specified time periods, the message is received.

28. The system as in claim 15 wherein the conflict detection logic evaluates the plurality of rules by performing a fuzzy logic analysis of the plurality of rules to identify conflicts.

29. A machine-readable medium including program code which, when executed by a processor, cause the processor to perform the operations of:

evaluating a plurality of rules for routing, filtering and/or storing messages and/or documents to determine whether a conflict exists between two or more of the plurality of rules;

detecting a conflict between two or more of the plurality of rules, the conflict having a particular level of severity associated therewith; and

identifying a resolution to the conflict if the severity associated with the conflict is below a predetermined threshold.

30. The machine-readable medium as in claim 29 comprising additional program code to cause the processor to perform the additional operations of:

rejecting one or more of the plurality of rules involved in the conflict if the severity level associated with the conflict is above the predetermined threshold value.

31. The machine-readable medium as in claim 29 wherein the resolution comprises implementing only one of the rules involved in the conflict.

32. The machine-readable medium as in claim 29 wherein the resolution comprises:

determining an outcome most likely desired by an end user; and

implementing the rules resulting in the desired outcome.

33. The machine-readable medium as in claim 29 wherein the conflict severity comprises either a “small” conflict or a “large” conflict and wherein resolutions are identified for small conflicts but not for large conflicts.

34. The machine-readable medium as in claim 29 wherein evaluating the plurality of rules comprises:

converting variables of a conditional portion of each rule to a value in a statistical distribution centered at a point in a real line; and

converting each outcome also to a numerical value in the real line.

35. The machine-readable medium as in claim 34 wherein evaluating the plurality of rules further comprises:

mapping all conditions applicable in a particular time and space locality as a region in N-dimensional space (“time-space region”), where N represents the number of variables associated with the rule.

36. The machine-readable medium as in claim 35 wherein evaluating the plurality of rules further comprises:

determining the outcome of applicable rules for each time-space region; and

computing the distance of the outcome value from each of the possible values of outcome variables from rule-specified outcomes using a Euclidean metric.

37. The machine-readable medium as in claim 36 wherein evaluating the plurality of rules further comprises:

comparing the distance of outcome variables with a specified threshold to determine if the conflict is below the predetermined threshold.

38. The machine-readable medium as in claim 37 wherein identifying a resolution to the conflict comprises:

if the severity associated with the conflict is below a predetermined threshold value, using the outcome of the resolution as the value of the outcome and using the resultant value to manage the routing, filtering and/or storing of messages and/or documents within the specific time and space.

39. The machine-readable medium as in claim 29 wherein the messages comprise email messages, voice messages, instant messages and/or fax messages.

40. The machine-readable medium as in claim 29 wherein a first of the plurality of rules specifies that messages sent from one of a first defined group of senders to a first device and/or location within a first specified time period are to be forwarded to a second device and/or location; and

wherein a second of the plurality of rules specifies that messages sent from one of a second defined group of senders to the first device and/or location within a second specified time period are to be forwarded to a third device and/or location, wherein the first specified time period overlaps with the second specified time period, and wherein, in response to receiving a message from a user who is included in both the first and second defined group during the overlap in the first and second specified time periods, resolving the conflict by selecting the outcome most likely desired by the end user.

41. The machine-readable medium as in claim 40 wherein resolving the conflict further comprises:

choosing either the first rule or the second rule based on where, within the overlap in the first and second specified time periods, the message is received.

42. The machine-readable medium as in claim 29 wherein evaluating the plurality of rules comprises performing a fuzzy logic analysis of the plurality of rules to identify conflicts.

43. A system comprising:

means for performing message and/or document management functions responsive to a plurality of rules for routing, filtering and/or storing messages and/or documents;

conflict detection means to determine whether a conflict exists between two or more of the plurality of rules, each detected conflict having a particular level of severity associated therewith; and

conflict resolution means to identify a resolution to the conflict if the severity associated with the conflict is below a predetermined threshold.