This invention pertains to object routing and, more particularly, to object routing in a Scalable Infrastructure System.
Until recently, it was unusual for people to have more than one telephone number at which they could be contacted. People generally could only be reached at home: with limited exceptions people were not accessible at work.
In the last few decades, this fact has changed. People have become more reachable at work. Facsimile machines have made possible the electronic transfer of written communications. Pagers, and later cellular and satellite telephones, have allowed people to receive communications even when not within reach of a land-line telephone. With the increased popularity of the Internet, more and more people are installing multiple telephone lines to their homes. And people are becoming increasingly mobile, having more than one office at which they work (and hence, multiple work telephones).
But with each of these new forms of communication, a new telephone number is required. Finding the right number to call has become a more complicated proposition. This is especially true of home, work, and cellular/satellite telephones, where there can be multiple different ways to reach a person, but not all telephone numbers will work at any given time.
If a telephone call is placed to one of a person's telephone numbers, if the person is not currently accessible at that telephone number, the caller must try another of the callee's telephone numbers. If the callee is not at the second telephone number, the caller must try a third telephone number, and then a fourth, and so on. Eventually, either the caller will reach the callee or will give up. The process is totally outside the callee's control and is totally dependent on the caller's luck in selecting a telephone number at which the callee can be reached.
This problem is exacerbated when the callee knows he will not be available. Unless there is a mechanism for the callee to route calls to someone who can take a message (for example, an assistant or voicemail), the call will never reach the callee. And even when such mechanisms are available for forwarding calls, they have limited capabilities. The mechanisms can only forward calls to a single destination, providing no flexibility for the possibility that the forwarded destination may be unable to take the call.
The present invention addresses these and other problems associated with the prior art.
The Smart Secretary is an agent of the Scalable Infrastructure System designed to route objects according to a user's preferences. When the Scalable Infrastructure System notifies the Smart Secretary that an object exists in the space for the Smart Secretary, the Smart Secretary picks up the object. The Smart Secretary then determines for which user the object is destined and accesses the user's preference settings. (A default preference setting specifies that the object is to routed only according to the directions enclosed with the object.) The Smart Secretary then routes the object according to the user's preference settings, even if they override the specified destination included with the object.
The foregoing and other features, objects, and advantages of the invention will become more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings.
In
The Scalable Infrastructure System uses a combination of a persistent store and agents to provide a communication system extensible to nearly all types of interfaces and any number of users and applications. The Scalable Infrastructure System defines Communities around the persistent store, or space, with space or non-space oriented interpreters, referred to here as Double Agents. Double Agents will be discussed in more detail further.
A Community as used here will refer to a collection of these agents and a persistent store. Any type of persistent store could be used, with the capabilities of having objects inserted into the store such that they do not lose their attributes and of providing a notification service as the objects are inserted. In this particular example, JavaSpaces™ [technology] will be used as the persistent stores, but the Scalable Infrastructure System is applicable to any similar technology. For ease of discussion, the persistent stores will be referred to as “Spaces.” Spaces can be used in several different implementations, and the following discussion is meant only as an example.
By maintaining the “wellness” information of agents and services within a Community, the Community Service also has the ability to launch new clones of these agents and services throughout the different Communities based on load metrics. This provides for some dynamic distributed load behavior. For example, if one [community] where to be hit with a 1000 calls within a minute, the Community Service could launch another (N) agents anywhere within the Community to handle this increased load. This Service could also leverage addition hardware that is on standby to increase performance during peak loads. Alternatively, it could shut down lightly utilized agents and unused Services when the load decreases. Members interact with the Spaces via the agents, and unused agents can be removed to make room for new agents. Most of these agents are what will be referred to as “Double Agents.”
Double Agents are analogous to translation modules. They can communicate with one protocol on one side and the protocol used in the Space on the other. Each Space will have a set of dedicated Double Agents. For example, a Space with a phone member will have a phone Double Agent. It may interact according to a common protocol, such as SIP (session initiation protocol), with a SIP phone. It will then convert the request or other communication from the SIP phone to Space protocols. The Space protocol will more than likely involve a typing process to type the communication according to Java™ types and then placing it as an object in the Space.
Double Agents are notified of new objects placed in the Space by a publish-and-subscribe process. Devices that interact with certain types of objects will subscribe with the Space to be notified when such an object is inserted into the Space. The Space then publishes the new object to all of the subscribed Double Agents. The subscribed Double Agents then pick it up from the Space. The object placed in the Space will be leased, and if no agent picks up the object before the lease expires, the object will be removed.
The nature of the Double Agents allows the system to be extremely scalable and extensible. If the system is to be made larger, a larger number of any type of Double Agents can be added. If more types of interfaces are needed, all the system requires to extend to include these are Double Agents written for those devices. The production of Double Agents is expedited by use of a class library.
An individual Community revolves around a Space, usually a local Space. The Space allows decoupling of associations between applications, clients, servers, proxies, etc., and acts as an intermediary. It also allows for typing of objects as well as a notification process for any new objects entered into the Space. Using the Space alleviates the problems with Jini™ [technology], noted above, when used in combination with the Double Agents and the Community Service.
(JavaSpaces, Java, and Jini are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.)
A person skilled in the art will recognize that there can be more than one Smart Secretary in Scalable Infrastructure System 205. For example, in
Because Smart Secretary processes objects on behalf of sources, Smart Secretary is effectively an agent for the source. But Smart Secretary 220-1 is a part of the Scalable Infrastructure System and otherwise separate from any source that causes a smart secretary object to be dropped into space 210-1. The use of the term “agent” should not be considered to tie Smart Secretary to a particular object source.
If there is more than one possible destination for the object, then at step 335, the Smart Secretary checks to see how the object is to be routed through the destinations. If the object is to be routed using sequential delivery, at step 340, the routing destinations are ordered. The object loses its smart secretary wrapper and is wrapped with a sequence wrapper, which includes the ordered list of routing destinations. Then, at step 345, the sequence object is then dropped into the space for a sequence object to try to route the object to the destinations in order. Otherwise, if the object is to be broadcast to the destinations, then at step 350 the destinations are identified, and at step 355 a broadcast object is placed in the space to broadcast the object to the destinations. As with sequential routing, the object loses its smart secretary wrapper and is wrapped with a broadcast wrapper.
Now that the operation of the Smart Secretary has been explained, its use can be described.
For purposes of
Assume for the moment that the preference settings indicate that the callee has made no preference settings (i.e., the callee wants all calls routed to the destination telephone as would normally happen). The Smart Secretary then forwards the object (minus the smart secretary wrapper) to Double Agent 445. Double Agent 445 causes IP telephone 420 to ring, and if the recipient doesn't answer, eventually the caller will hang up.
Now consider the possibility that the callee may be a manager who is frequently away from his desk. The callee may consider that all calls are important, and should be answered either by himself or his assistant. The callee can set his preference settings to indicate that IF telephone 420 is to ring five times. If IP telephone 420 is not answered within five rings, then IP telephone 425 (his assistant's telephone) is to ring five times. If his assistant does not answer within five rings, then voicemail 460 (supported by Double Agent 465) is to take the call. In this way, the callee can try to ensure that someone takes the call, even if the call is bounced around the network several times. This is all done transparently to the caller: the caller at IP telephone 405 is not aware that his call is being rerouted to different destinations.
If the manager works out of multiple offices, he can set his preferences to ring each of his phones in turn, until someone picks up. So, in the above example, if the manager alternates between IP telephones 420 and 430 (for example, IP telephone 420 in Los Angeles and IP telephone 430 in New York City), IP telephone 420 can be set to ring first, then IP telephone 430, then the manager's assistant's IP telephone 425, and finally voicemail 460, until someone takes the call. Note that the fact that IP telephones 420, 430, and 425 are part of different Communities does not affect the preference setting: transfer of a call between Communities 415-1 and 415-2 is handled seamlessly.
Finally, if the callee spends his time at telephone 435, which is not connected to a Scalable Infrastructure System (for example, the callee can be out in the field with only a cellular or satellite telephone for receiving calls), the callee can set his preference settings to forward calls to telephone 435. The fact that calls to telephone 435 must pass through PBX 440 does not affect the operation of Smart Secretary.
When Smart Secretary routes an object using the sequencer agent or the broadcast agent, it may happen that Smart Secretary is re-invoked. Consider the earlier example of a manager who wants his calls routed to his assistant if he does not answer the call within five rings. The assistant may have her own preferences. For example, knowing that she is working at home one day, the assistant may set her preferences to route calls from her desk to her home. Thus, even though the manager specified that telephone on his assistant's desk was to ring, the call is routed to the assistant at her home, as desired.
Where Smart Secretary is re-invoked in this matter, two issues arise. The first issue is loops in object routing. In the manager/assistant example above, it can happen that the manager and assistant each, in an effort to make sure a call is answered, has his calls routed to the other in case no-one picks up at the primary destination. Because Smart Secretary is invoked for routing calls to both parties, a call to the manager will be routed to the assistant. When the assistant does not answer, the call will be routed according to the assistant's preferences, and will be routed back to the manager, completing the loop. Such loops can be avoided by having the gateway examine the call data stored in the object. In the above manager/assistant example, when the call is routed back to the manager, the gateway examines the call data and determines that the call had been routed to the manager previously. The gateway then intentionally does not deliver the object, thereby breaking the loop.
The second issue is the priority of routing destinations as new destinations are located. Consider a situation where a user has his preferences set up to route incoming calls to three different destinations sequentially. For clarity, identify the user as A and the call destinations as A1, A2, and A3. As discussed above, the users at each of these destinations can specify their own preferences. For example, call destination A2 can be the telephone of a user B, who has set his preferences up to route calls to destinations B1, B2, and B3. When the sequencer agent attempts to route the call to destination A2, user B's preferences are invoked via Smart Secretary. In the preferred embodiment, when Smart Secretary processes user B's preferences, it is unaware of any prior routing of the call according to user A's preferences. But because the smart secretary object dropped by the sequencer includes a flag, Smart Secretary knows to return the sequence of user B's preferences to the sequencer (via a flag included in the sequencer object that specifies the sequencer agent). Sequencer can then insert the sequence returned by Smart Secretary into the earlier sequence. Thus, after the sequencer inserts user B's preferences, the sequence of destinations becomes A1, B1, B2, B3, and A3.
Although the above description is how Smart Secretary operates in the preferred embodiment, a person skilled in the art will recognize that other techniques for combining sequences are possible. For example, to avoid the possibility of a call being routed too far away from the original destination (and also to avoid loops), the sequencer agent can only use the first entry in user B's sequence. All other routing destinations specified by user B are rejected.
One limitation of the approach taken in combining sequences in the preferred embodiment is the routing of calls to voicemail. In the above example, consider the possibility that the final destination specified by both users A and B (i.e., call destinations A3 and B3) are voicemail. In general, in choosing between the two voicemail destinations, it is preferable to route the call to user A's voicemail, since user A was the original destination of the call. This is handled in the preferred embodiment by having the sequencer agent recognize that one of the destinations in the inserted sequence is for a voicemail and not adding the voicemail destination to the sequence.
Alternatively, as described above, user preference setting 235 can specify a broadcast of the object to all possible destinations. For example, user preference setting 235 can specify that the object is to be broadcast to IP telephone 420, IT telephone 425, and voicemail 460. (In this example, voicemail 460 has been configured to respond to the object only after waiting a few seconds for someone else to have a chance to respond first.) Because a broadcast is to be performed, Smart Secretary 220 drops broadcast object 520 into space 210-1. Broadcast agent 525 then picks up broadcast object 520 and broadcasts the object to each of the destinations. In
Having illustrated and described the principles of our invention in a preferred embodiment thereof, it should be readily apparent to those skilled in the art that the invention can be modified in arrangement and detail without departing from such principles. We claim all modifications coming within the spirit and scope of the accompanying claims.
This application is a continuation of U.S. patent application Ser. No. 09/698,779 filed Oct. 27, 2000 now U.S. Pat. No. 7,143,182, which is a continuation of and claims priority to U.S. Provisional Patent Application No. 60/223,824 filed Aug. 8, 2000. This application relates to the following US patent applications and patents, all commonly assigned to the assignee of this application. Ser. No.Atty. Dkt. No.TitleFiled09/676,1472705-128Fully Distributed, Sep. 29, 2000Scalable InfrastructureCommunication System09/697,821 now2705-144Scalable Infrastructure Oct. 26, 2000U.S. Pat. No. Community Serviceissued 6,775,833Aug. 10, 200409/882,2212705-187Net LurkersJun. 15, 2001
Number | Name | Date | Kind |
---|---|---|---|
4585906 | Matthews et al. | Apr 1986 | A |
4972367 | Burke | Nov 1990 | A |
5036535 | Gechter et al. | Jul 1991 | A |
5049873 | Robins et al. | Sep 1991 | A |
5241588 | Babson et al. | Aug 1993 | A |
5299207 | Fujii | Mar 1994 | A |
5327486 | Wolff et al. | Jul 1994 | A |
5432839 | DeLuca | Jul 1995 | A |
5455854 | Dilts et al. | Oct 1995 | A |
5493692 | Theimer et al. | Feb 1996 | A |
5524137 | Rhee | Jun 1996 | A |
5594859 | Palmer et al. | Jan 1997 | A |
5638514 | Yoshida et al. | Jun 1997 | A |
5655015 | Walsh et al. | Aug 1997 | A |
5742763 | Jones | Apr 1998 | A |
5742905 | Pepe et al. | Apr 1998 | A |
5787262 | Shakib et al. | Jul 1998 | A |
5799306 | Sun et al. | Aug 1998 | A |
5809478 | Greco et al. | Sep 1998 | A |
5867495 | Elliott et al. | Feb 1999 | A |
5884324 | Cheng et al. | Mar 1999 | A |
5905789 | Will | May 1999 | A |
5928325 | Shaughnessy et al. | Jul 1999 | A |
6009103 | Woundy | Dec 1999 | A |
6029175 | Chow et al. | Feb 2000 | A |
6061470 | Ferguson et al. | May 2000 | A |
6061740 | Ferguson et al. | May 2000 | A |
6091811 | Chang et al. | Jul 2000 | A |
6091948 | Carr et al. | Jul 2000 | A |
6092102 | Wagner | Jul 2000 | A |
6137876 | Wong et al. | Oct 2000 | A |
6170015 | Lavian | Jan 2001 | B1 |
6209018 | Ben-Shachar et al. | Mar 2001 | B1 |
6226666 | Chang | May 2001 | B1 |
6249570 | Glowny et al. | Jun 2001 | B1 |
6253256 | Wollrath et al. | Jun 2001 | B1 |
6330319 | Moghnie | Dec 2001 | B1 |
6335927 | Elliott et al. | Jan 2002 | B1 |
6353661 | Bailey, III | Mar 2002 | B1 |
6356633 | Armstrong | Mar 2002 | B1 |
6393481 | Deo et al. | May 2002 | B1 |
6412017 | Straube et al. | Jun 2002 | B1 |
6421686 | Martin, Jr. | Jul 2002 | B1 |
6425005 | Dugan | Jul 2002 | B1 |
6434594 | Wesemann | Aug 2002 | B1 |
6442565 | Tyra et al. | Aug 2002 | B1 |
6457065 | Rich et al. | Sep 2002 | B1 |
6463446 | Wollrath et al. | Oct 2002 | B1 |
6493671 | Ladd | Dec 2002 | B1 |
6532218 | Shaffer et al. | Mar 2003 | B1 |
6560637 | Dunlap et al. | May 2003 | B1 |
6564216 | Waters | May 2003 | B2 |
6578074 | Bahlmann | Jun 2003 | B1 |
6587455 | Ray et al. | Jul 2003 | B1 |
6615223 | Shih et al. | Sep 2003 | B1 |
6643650 | Slaughter et al. | Nov 2003 | B1 |
6697806 | Cook | Feb 2004 | B1 |
6714979 | Brandt et al. | Mar 2004 | B1 |
6724896 | Beckett et al. | Apr 2004 | B1 |
6751657 | Zothner | Jun 2004 | B1 |
6754181 | Elliott et al. | Jun 2004 | B1 |
6782412 | Brophy et al. | Aug 2004 | B2 |
6788980 | Johnson | Sep 2004 | B1 |
6789077 | Slaughter et al. | Sep 2004 | B1 |
6792466 | Salulpaugh et al. | Sep 2004 | B1 |
6859931 | Cheyer et al. | Feb 2005 | B1 |
Number | Date | Country | |
---|---|---|---|
60223824 | Aug 2000 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 09698779 | Oct 2000 | US |
Child | 11555907 | US |