US20020059527A1

US20020059527A1 - Systems and methods for managing electronic communications using token information to adjust access rights

Info

Publication number: US20020059527A1
Application number: US09/918,565
Authority: US
Inventors: Elin Pedersen; Tomas Sokoler
Original assignee: Fuji Xerox Co Ltd
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2000-11-14
Filing date: 2001-08-01
Publication date: 2002-05-16
Also published as: US7747752B2; US6842512B2; US20020118807A1; US20020069249A1

Abstract

A token may be issued for a person for whom access rights are to be adjusted. An interaction manager may receive an interaction request and the token. One or more selection criterion may thereupon be adjusted based on the token which may result in a greater access to information being provided. The information may include interaction information displayed as an interaction space on a caller's communication device.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to U.S. Provisional Application Serial No. 60/247,990, filed Nov. 14, 2000, from which priority is claimed.[0001]

BACKGROUND OF THE INVENTION

1. Field of Invention

This invention relates to managing electronic communications.

2. Description of Related Art

Currently, there are various devices and systems that handle calls and provide greeting messages to callers. These conventional devices and systems include various answering machines, voice mail systems, and interactive voice response (IVR) systems. Typically, when a called party is busy or after a predetermined number of rings, a message is played to a caller indicating that the called party is currently unavailable. However, the greeting message that is played to the caller usually is only a general message that is the same for all callers.

SUMMARY OF THE INVENTION

Although conventional technology is an improvement over manually taking messages, it still would be highly desirable to provide more useful/personalized information to callers. For instance, it would be desirable to provide alternative ways to reach the called party (e.g., by cell phone, pager).

One difficulty in providing such information to callers is that the called party may not want to give out private information to everyone who calls. For example, a called party probably wouldn't want to provide pager access to a telemarketer. On the other hand, the called party might want to provide such access to a friend, family member or business associate.

It would be highly desirable to select interaction information so that the privacy of the called party is protected. At the same time, it would be highly desirable that any selection criteria not be too rigid. For instance, the called party might wish to provide interaction information only on a temporary basis to a person, such as, for example, to a building contractor working on a home improvement project.

This invention provides various methods and systems for managing electronic communications using token information. In various exemplary embodiments of the systems and methods of this invention more useful/personalized information is provided to a caller. Furthermore, a token may be issued for a caller usable to temporarily adjust at least one selection criterion for providing information. In this manner, the caller may be provided with access to a “higher level” of interaction information than would be the case without the token.

In various exemplary embodiments, an interaction manager provides interaction information that may be provided as an interaction space displayed or otherwise presented on a web-enabled device, such as, for example, a web-enabled telephone. Furthermore, the interaction manager may process and/or issue the above-mentioned tokens.

In various other or additional exemplary embodiments, the interaction space may include one or more of visibility information that informs a caller about the status of a callee, accessibility information that provides the caller with a list of communication channels available to the caller, and continuity information that includes information and action facilitation data that reflect the ongoing interaction between the caller and the callee. In various other or additional exemplary embodiments, the interaction manager may determine a response message for a caller at least in part based on the relation of the caller and the callee and the current status of the callee.

These and other features and advantages of this invention are described in, or are apparent from, the detailed description of various embodiments of the systems and methods according to this invention.

BRIEF DESCRIPTION OF THE DRAWINGS

Various exemplary embodiments of this invention are described in detail with reference to the following figures, where like numerals reference like elements, and wherein: [0013]
FIG. 1 is a block diagram of one exemplary embodiment of a system that manages electronic communications using token information to adjust access rights; [0014]
FIG. 2 is an exemplary diagram of an interaction space; [0015]
FIGS. 3 and 4 show two exemplary communication devices illustrating the use of interaction spaces according to this invention; [0016]
FIG. 5 is a diagram of an exemplary screen input for issuing access tokens; [0017]
FIG. 6 is a diagram of an exemplary data structure representing an access token; [0018]
FIG. 7 is a diagram of an exemplary database record containing caller information; [0019]
FIG. 8 is an exemplary block diagram of the interaction manager shown in FIG. 1; and [0020]
FIG. 9 is a flowchart outlining an exemplary technique for using token information to adjust access rights according to this invention.[0021]

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Interaction information may be provided to specific persons based on various selection criteria. Moreover, it may become desirable to adjust the access rights of a particular person. An access token may be issued that can be used to adjust at least one selection criterion usable to determine the kind and/or amount of information to be provided to a caller. [0022]
FIG. 1 is a block diagram of one exemplary embodiment of a [0023] system 100 that manages electronic communications using token information to adjust access rights. The electronic communication system 100 includes one or more communication devices, such as the communication device 130, and one or more interaction managers, such as the interaction manager 180. All of the above components are coupled together via a communication infrastructure 150 through links, such as the links 140 and 160.
The [0024] communication infrastructure 150 can accommodate communication between the communication device 130 and the interaction manager 180 by providing a communication path capable of transmitting and receiving communication signals over the links 140 and 160. The communication infrastructure 150 can include any known or later developed network for transmitting information. Such networks can include any combination of one or more wide area networks, one or more local area networks, one or more public switched telephone networks, one or more wireless or wired networks, one or more intranets, the Internet and/or any other distributed processing network or system. In general, the communication infrastructure 150 can be any known or later developed combination of systems, computer programs or structures usable to transmit and receive information over the links 140 and 160.
The [0025] links 140 and 160 can be any known or later developed device or system for transmitting data among the communication devices 130 and 150 and the interaction manager 180. Such devices include direct serial/parallel cable connections, satellite links, wireless links, connections over a wide area network or a local area network, connections over a public switched telephone system, connections over an intranet, connections over the Internet and/or connections over any other distributed processing network or system. Additionally, the links 140 and 160 can be software devices linking various software systems. In general, the links 140 and 160 can be any known or later developed devices or systems, computer programs or structures usable to connect the communication device 130 and the interaction manager 180 to the communication infrastructure 150.
In various exemplary embodiments, the [0026] communication device 130 can be a web-enabled telephone (a webphone), a cellular telephone, a standard telephone, a personal digital assistant (“PDA”), a two-way pager, a facsimile machine or program, or a network-attached personal computer. The interaction manager 180 provides a communication device 130 with a response message. In most cases, this response message will be implemented as an interaction space. FIG. 2 shows one exemplary embodiment of an interaction space according to this invention.
Various exemplary embodiments of an [0027] interaction manager 180 used in conjunction with this invention are disclosed in U.S. patent application Ser. No. 09/794,102, filed Feb. 28, 2001, which is incorporated herein by reference in its entirety.
The [0028] interaction manager 180 is capable of providing a caller 110 associated with at least one communication device 130 with a set of one or more communication channels usable to interact with a callee 190, along with information about the current status of the callee 190. The caller 110 can then make an informed choice regarding which provided communication channel to use to contact the callee 190, based on the interpretation by the caller 110 of the status of the callee 190. The list of communication channels can include hypertext links, for example, pointing to addresses of other communication devices and/or to locations capable of directing communications to these devices.
The [0029] interaction manager 180 is able to generate one or more personalized interaction spaces such as the interaction space 200 as shown in FIG. 2. A single interaction space 200 reflects the relationship between a callee 190, who is the owner of the interaction space 200, and a caller 110 who uses the interaction space 200. In various exemplary embodiments of the methods and systems of this invention, the interaction manager 180 is implemented as a distributed system having software components residing on a web server. These software components interact with other individuals, or with other interaction managers that reside on one or more web servers.
FIG. 2 is a block diagram graphically illustrating one exemplary embodiment of the [0030] interaction space 200 according to this invention. As shown in FIG. 2, the interaction space 200 includes visibility information 210, accessibility information 220, and continuity information 230. The visibility information 210 informs a caller 110 about the status or situation of a callee 190. The accessibility information 220 provides the caller 110 with a list of communication channels that the callee 190 has decided to make available to the caller 110. The continuity information 230, for example, can contain information and action facilitation data that reflect the ongoing interaction between that caller 110 and the callee 190. However, it should be appreciated that the interaction space 200 does not necessarily need to include the continuity information 230.
The [0031] interaction space 200 is presented to the caller in a modality that is suited to the particular communication device 130 being used by the caller 110. In various exemplary embodiments, the interaction space 200 is generated by integrating the visibility information 210, the accessibility information 220, and the continuity information 230.
Generally, a [0032] caller 110 associated with the communication device 130 can interact with or obtain interaction information about a caller 110 associated with the interaction manager 180. For example, a caller 110, using a webphone, may connect with a callee 190 associated with interaction manager 180. In this case, the communication infrastructure 150 can include the Internet. Once the caller 110 connects with the interaction manager 180 of the callee 190, various information can be provided to the caller 110. In particular, the interaction manager 180 can display an interaction space, such as the interaction space 200 shown in FIG. 2.
Depending on the relation between the [0033] caller 110 and the callee 190, and the current status of the callee 190, the interaction manager 180 can provide personalized information to the caller 110, such as a set of links to various communication devices associated with the callee 190. For example, the interaction manager 180 may provide links to one or more of a webphone, a telephone, a pager, a facsimile device, an electronic mail (e-mail) system, and/or a scheduler system. In addition, the interaction manager 180 may provide information as to the availability of the callee 190, such as, for example, a message indicating that the callee 190 is tied up in an important meeting. However, the information that is displayed or otherwise presented via the interaction manager 180 may be based upon a predefined relationship between the caller 110 and the callee 190. That is, the callee 190 may wish to only provide certain information, such as, for example, the callee's home telephone number, to a certain group of persons who have been identified as friends of the callee 190.
The [0034] interaction manager 180 is capable of determining the identity of the caller 110 associated with a communication device 130 using various identifying technologies, such as automatic number identification (ANI), a cookie file, and various biometric devices, such as, for example, a fingerprint recognition device, an iris scan device, or any other known or later developed biometric device. Once the identity of the caller 110 has been determined, the interaction manager 180 can determine the appropriate information that the caller 110 is entitled to access.
However, the [0035] interaction manager 180 can adjust these selection criteria if an access token is associated with the caller. An access token may be issued by the interaction manager 180 or by another device or system, such as, for example, by an access token issuance screen 500 shown in FIG. 5. The access token may be encrypted and/or contain authenticating information. The access token may either be included in an interaction request received by the interaction manager 180 or obtained separately from another data source.
The [0036] interaction manager 180 can determine the appropriate interaction information for the caller 110 based on the usual selection criteria and then adjust the amount of information provided to the caller using the access token. For example, the caller 110 may not have been registered as a friend of the callee 100 in the interaction manager 180. Therefore, this caller 110 might not be entitled to receive links to the callee's 110 pager and home telephone number. However, if an access token is associated with this caller 110, the interaction manager 180 may raise the access level from a “low” level to a “high” level, for example. Once the access level has been adjusted, the interaction manager 180 can allow the caller 110 to receive a greater degree of information about the callee 190 than would have been the case without the token. Furthermore, the interaction manager 180 can check the access token for an expiration date and only adjust the one or more selection criterion if the access token has not yet expired.
FIGS. 3 and 4 show two exemplary devices capable of displaying the [0037] interaction space 200 to a caller 110 or to a callee 190. Although each communication device is capable of displaying the interaction space 200 to any caller 110, or to the callee 190, the actual content of the interaction space 200 may, and generally will, differ depending on the identity of a particular caller 110. For example, as shown in FIG. 3, the interaction space 200 displayed on the first communication device 301 includes a general message that the callee 190 can provide to any caller 110. However, as shown in FIG. 4, the interaction space 200 displayed on the second communication device 302 includes an interaction space 200 that is specifically tailored to a particular caller 110, and provides information having a greater degree of detail and specificity. Because the interaction space 200 displayed on the second communication device 302 can be customized for a particular caller 110, the interaction space 200 displayed on the second communication device 302 can enhance the interaction between that caller 110 and the callee 190.
In various exemplary embodiments, such as that shown in FIG. 4, for example, the [0038] interaction space 200 can include links to available communication channels a particular caller 110 is permitted to access. For example, these available communication channels can be grouped into or represented entirely as logical interaction channels based on the situation and needs of a particular caller 110. However, the set of communication channels available to a caller 110 may depend on the status of the callee 190. For example, the callee 190 may not allow any direct calls when the callee 190 is in a meeting.
FIG. 5 shows an exemplary embodiment of an access [0039] token issuance screen 500 usable by the callee 190 to issue access tokens for various callers 110, or, alternatively, to associate access tokens with various callers 110. The exemplary access token issuance screen 500 has a caller highlight selection menu 510 usable to select a caller 110 who will be the recipient of, or associated with, a particular issued token, an access level highlight selection menu 520 usable to select an access level, and an expiration text input box 530 usable to input an expiration date of the access token. It should be noted that a user can, and usually, but not always, will be required to select one entry from each highlight selection menu 510 and 520 and the text input box 530.
In an exemplary mode of operation, the access [0040] token issuance screen 500 can accept an identifier associated with a caller 110. As shown in FIG. 5, the user has highlighted the entry for “Sal's Roofing Company” from the caller highlight selection menu 510. Furthermore, this user has selected “high” from the access level selection menu 520, and has entered an expiration date value in text input box 530. Once the appropriate information has been entered into the access token issuance screen 500, the information can be used to create an access token for the indicated caller 110. In this example, the access token would be issued to, or associated with, Sal's Roofing Company with an access level of high and an expiration date of Feb. 15, 2001. Thus, a caller 110 identified as being from Sal's Roofing Company would have the highest access level to receive interaction information from the callee 190 until the expiration ending date has occurred.
While the exemplary access [0041] token issuance screen 500 uses several selection menus and a text input box, it should be appreciated that the selection of various parameters such as the caller identity, access level, and the token expiration date can be accommodated using a variety of devices such as a number of graphical user interface selection widgets, check boxes, buttons, list boxes, pop-up or drop-down marks, text entry boxes and/or the like, or any other known or later developed interfaces that an operator can access. It should also be appreciated that the access token issuance screen 500 can also, or alternatively, include any device capable of receiving or defining token information such as a command line interface, a touch sensitive display, a keyboard, or a number of mechanical selection devices such as buttons and knobs, or the like, without departing from the spirit and scope of this invention.
FIG. 6 shows an exemplary embodiment of a [0042] data structure 600 corresponding to an access token. The exemplary data structure 600 includes a caller ID field 610, a callee ID field 620, an access level field 630, and an expiration date field 640. In particular, the caller ID stored in the caller ID field 610 may be a URL associated with the caller 110 or the telephone number associated with the caller 110, for example. Likewise, the callee ID stored in the callee ID field 620 may be a URL associated with the callee 190 or the telephone number associated with the callee 190. Furthermore, the access level stored in the access level field 630 can include a code or other indicator specifying the access level to which the caller 110 is to be given. Finally, the expiration date stored in the expiration date field 640 may include a date on which the access token expires. This expiration date stored in the expiration date field 640 may include not only the particular day on which the expiration occurs, but also a particular hour/minute/second during the day when the access token is to expire. Furthermore, it should be appreciated that the format of the expiration date stored in the expiration date field 640 may be represented in any known or later developed format for representing such information.
Furthermore, it should be appreciated that the [0043] access token 600 can be stored in a database or other file system, stored on a magnetic card that can be read by a suitable magnetic card reader, printed on a suitable medium such as paper, printed as a bar code readable by a bar code reader or scanner, and the like. In general, the form in which the access token information stored in the exemplary data structure 600 is embodied can vary as a design choice without departing from the spirit and scope of this invention.
In operation, the access [0044] token issuance screen 500, as illustrated in FIG. 5, can generate the access token using information entered by the callee 190. For example, the callee 190 might select Sal's Roofing Company from the caller highlight selection menu 510, and an appropriate identifier associated with the selected caller may be generated and stored in the caller ID field 610. Furthermore, the callee ID stored in the callee ID field 620 can be generated from an identifier associated with the interaction manager 180 of that callee 190. In addition, the access level data stored in the access level field 630 can be generated from the access level selected in the level selection highlight menu 520 and the expiration date stored in the expiration date field 640 can be generated from the expiration date data entered into text input box 530.
FIG. 7 shows an [0045] exemplary database 700 usable to store information regarding a plurality of known callers 110. The exemplary database 700 includes a plurality of records 705. Each record 705 includes a type 710 that stores data indicating the type of identifier, an identifier field 720 that stores data identifying the caller, a name field 730 that stores data storing the caller's name, a relation field 740 that stores data defining the relationship between the caller 110 and the callee 190, and a level field 750 that stores data indicating the current access level of the caller 110.
In various exemplary embodiments, the [0046] database 700 can be a database implemented using a single database management system (DBMS) managed by a controller residing on a memory such as a hard disk. However, it should be appreciated that this database 700 can be implemented on one or more separate computer systems. For example, the database 700 could reside on a separate computer system and/or a server having a relational database capable of executing SQL instructions. Furthermore, the database 700 can be stored in a database situated in the communication device 130. It should be appreciated that other information may be stored in various databases, or may be derivable from stored information, or made available from external sources, to determine the access rights of a particular caller 110.
FIG. 8 is a block diagram of one exemplary embodiment of a circuit or software program that implements the [0047] interaction manager 180. As shown in FIG. 8, the exemplary interaction manager 180 includes a controller 810, a memory 820, a local input/output interface 830, a database 840, a token generator 850 and a network input/output interface 860. The controller 810 can be linked to the other devices 820-860 by a data control bus 815.
In a first mode of operation, the [0048] controller 810 receives an interaction request via the network input/output 860 and stores this information in the memory 820. Once the interaction request has been stored, the controller 810 then determines an identifier associated with the interaction request. The identifier can be extracted from the interaction request or, alternatively, can be obtained via external information stored outside the interaction manager 180. For example, the controller 810 may interact with an automatic number identification (ANI) system to obtain a caller ID associated with the caller 110. Alternately, the identifier may either be extracted from a cookie file that has been associated with the caller's webphone or that has been passed along with the interaction request.
Once the [0049] controller 810 has determined the identity of the caller 110, the controller 810 can then determine the interaction information to be provided to this caller 110. The controller 810 can query the database 840 for information relating to the caller 110, using the caller identifier. For example, the database 840 may be a relational database in which information relating to callers is stored in tables or records, such as the database 700 illustrated in FIG. 7. Furthermore, the caller identifier may serve as a key or index value to one or more of such tables or records.
The [0050] database 840 can include a variety of information usable by the interaction manager 180 to determine and create an appropriate interaction space 200 for the caller. For example, the caller 110 may be a friend of the callee 190. In this case, the callee 190 may have included information in database 840 identifying the caller 110 as a friend. If the caller 110 is identified as a friend in the database 840, the controller 810 can provide an appropriate level of information to the caller 110 via local input/output interface 830.
The [0051] controller 810 may also use other information to make an appropriate decision for providing interaction information. For example, the controller 810 may access the database 840 and/or obtain further information that the callee 190 is currently in an important meeting. For example, the controller 810 may query via the local input/output interface 830 a calendar or scheduler system associated with the callee 190 to determine the present availability of the callee 190. The scheduler or calendar information might show that the callee 190 is currently in a meeting.
For example, the [0052] controller 810 might determine that the status of the meeting is of high importance based on the social context of the meeting or data stored in the calendar or scheduler system. For instance, the meeting as shown in the calendar information might be taking place in the Board Room. Thus, the controller 810 might determine that this meeting is of very high importance to the callee 190. Consequently, the controller 810 might limit the amount of interaction information to be provided to most callers 1 10 during the time interval when this meeting is taking place. Thus, the controller 810 might only provide a general message as to the unavailability of the callee 190 for the duration of the meeting. However, the callee 190 might provide his or her pager number to a particular caller 110 who is of high priority. This might be accomplished by causing the token generator 850 to issue an appropriate token for, or associate an appropriate token with, that caller 110 to override the usual selection criteria.
If the [0053] database 840 does not have an entry for a caller 110, a generic interaction space may be displayed or otherwise presented to that caller 110. For example, that caller 110 may not be acquainted with the callee 190 and therefore there might not be any information in database 840 regarding this caller 110. Since there is no preexisting relationship between this caller 110 and the callee 190, a low level of access may be granted to this caller 110.
Prior to determining the [0054] interaction space 200 for a particular caller 110 or providing other types of interaction information to the caller 110, the controller 810 may examine the interaction request stored in the memory 820 for token information. If token information is found for this caller 110, the controller 810 can adjust the level of access of this caller 110 based on the token information.
The [0055] database 840 may indicate information sufficient to only provide a minimal amount of information to a particular caller 110. However, token information associated with this caller 110 may cause the information provided to this caller 110 to be increased (or decreased). In this case, the token information will cause at least one selection criterion to be adjusted. For example, this caller 110 may be a contractor associated with the callee 190 who is working on a home-improvement project for the callee 190. Although the callee 190 might not ordinarily wish to provide personal information to this caller 110, it might be desirable to provide some otherwise private interaction information to the contractor for the duration of the project. The controller 810 can check the token information for an expiration date and only adjust the one or more of the selection criteria if the expiration date has not occurred.
In various exemplary embodiments, the [0056] controller 810 is a general purpose computer. However, in other exemplary embodiments, the controller 810 can be a special purpose computer, a microprocessor or microcontroller, an ASIC or other integrated circuit, a digital signal processor, a hard-wired electronic or logic circuit such as a discrete element circuit, a programmable logic device such as a PLD, PLA, FPGA or PAL, or the like, without departing from the spirit and scope of the invention.
The [0057] memory 820 of the exemplary embodiment can be implemented using static or dynamic RAM. However, the memory 820 can also be implemented using a floppy disk and disk drive, a writable optical disk and disk drive, a hard disk drive, flash memory or the like, without departing from the spirit and scope of this invention. Furthermore, the memory 820 can be a persistent memory, i.e., maintain information when external power is removed, or the memory 820 can be a volatile memory, i.e., information is lost when power is removed.
In various exemplary embodiments, the local input/[0058] output interface 830 and/or the network input/output interface 860 can be hard-wired interfaces. However, in other exemplary embodiments, the local input/output interface 830 and/or the network input/output interface 860 can be any device suitable to transmit information to and from another device, such as a universal asynchronous receiver/transmitter (UART), a local area network (LAN), a wide area network (WAN), a parallel digital interface, a software interface or any combination of known or later developed software and hardware. While the local input/output interface 830 and the network input/output interface 860 are depicted as separate devices in FIG. 8, it should be appreciated that the input and output functions can be accommodated either by a single device or by separate devices without departing from the spirit and scope of this invention.
In various exemplary embodiments, the [0059] database 840 can be implemented using a single database management system (DBMS) managed by the controller 810 residing on a memory such as a hard disk. However, it should be appreciated that the database 840 can be implemented on one or more separate computer systems. For example, the database 840 can reside on a separate computer system and/or a server having a relational database capable of executing SQL instructions.
The exemplary local input/[0060] output interface 830 can include a software module capable of generating hypertext markup language (HTML) code to provide screen output capable of being viewed over the Internet by a caller having a suitable Web browser (e.g., Microsoft Internet Explorer, Netscape Navigator/Communicator). However, it should be appreciated that the local input/output interface 830 can produce an audio report which can be played to the caller, for example, over the telephone. Furthermore, it should be appreciated that any type of known or later developed output generation devices can be used to provide information to a caller, such as an electromechanical printing device, various displays and the like, without departing from the spirit and scope of the present invention.
FIG. 9 is a flowchart outlining one exemplary embodiment of a technique for adjusting access rights of a caller according to this invention. Beginning at step S[0061] 700, control continues to step S710, where an interaction request is received by the callee's interaction manager. The interaction request may include information relating to the caller's identity, the caller's communication device and/or the caller's mode of communication. In this exemplary embodiment, a caller may contact the callee's interaction manager using a Web-enabled telephone (a web phone) and the callee's interaction manager can be resident on a hypertext transfer protocol (HTTP) server. Next, in step S720, selection criteria relating to the caller are retrieved from at least one data source. The interaction request may include identification information extracted from a cookie file associated with the caller's web phone, for example. In this case, the selection criteria for the caller may be determined using this identifier. The selection criteria for the caller may also involve determining the callee's present status. For example, the selection criteria of information to be provided to the caller can be affected by the current status of the callee. For instance, the callee may be tied up in an important meeting and as such may not wish to provide any interaction information to callers at the present moment. The callee's interaction manager can determine the callee's status in various ways using numerous sources of information. For example, the callee's status may be determined using information derived from an electronic scheduler/calendar system, data explicitly input by the callee, sensor information, location information, and social context information.
Furthermore, the selection criteria may also involve determining whether the caller is known to the callee. For example, this may be determined by examining a list of known caller IDs. If the caller identifier does not match information stored in these lists of known caller IDs, it may be determined that the caller and the callee do not know each other. Regardless of how the relationship is determined, based on the determined relationship, one of any number of different message types that reflect the determined relationship can be generated. Once the pertinent selection criteria for the caller has been retrieved, control continues to step S[0062] 730. In step S730, a determination is made as to whether any access token exists for the caller. The token may be stored along with the interaction request or it may be stored separately. An indicator that the token exists may be stored in the callee's interaction manager, for example.
Token information may be extracted either from the interaction request or may be determined in some other manner from other data sources. The token information may represent a numerical value which can be encrypted or otherwise encoded. The token itself may contain authenticating information which can be used to ensure that the token is genuine. Once the token information is extracted, control continues to step S[0063] 750 where one or more selection criterion are modified. In step S750, the interaction manager can adjust the selection criteria based on the contents of the token. For example, the caller may be a contractor for whom the callee is using on a home-improvement project. Furthermore, the token information may indicate that the caller should have a “high level” of access during the next week when the project is underway. In this case, although the selection criteria retrieved by the interaction manager may indicate a very low level of access for this caller, nonetheless the interaction manager may increase the access level for this particular caller based on the token information that is extracted. Once the relevant one or more selection criterion has been adjusted, control continues to step S760, where the operation stops.
Various exemplary embodiments of the systems and methods of this invention can be implemented using a general purpose computer system. However, the systems and methods of this invention can be implemented using any number of one or more programmed general purpose computers, programmed microprocessors or micro-controllers and peripheral integrated circuit elements, ASIC or other integrated circuits, digital signal processors, hard-wired electronic or logic circuits such as discrete element circuits, programmable logic devices such as a PLD, PLA, FPGA or PAL, or the like. In general, any device capable of implementing a finite state machine that is in turn capable of implementing the flowchart shown in FIG. 9 and/or the interaction manager shown in FIGS. [0064] 1 and/or 8, can be used to implement the systems and methods of this invention.
While this invention has been described in conjunction with the various exemplary embodiments outlined above, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, the exemplary embodiments of the invention, as set forth above, are intended to be illustrative, not limiting, various changes may be made without departing from the spirit and scope of the invention. [0065]

Claims

What is claimed is:

1. A method of adjusting, for a requester of information, at least one selection criterion, comprising:

receiving a request for information from the requester;

determining if a token is associated with the requester; and

if a token is associated with the requester, adjusting the at least one information selection criterion usable to identify information corresponding to the requester based on the token.

2. The method of claim 1, further comprising providing the identified information to the requester.

3. The method of claim 2, wherein providing the identified information includes providing interaction information to the requester.

4. The method of claim 3, wherein the interaction information relates to potential interaction with an issuer of the token.

5. The method of claim 3, wherein the interaction information includes at least one of visibility information, accessibility information, and continuity information.

6. The method of claim 5, wherein the accessibility information includes at least one hypertext link associated with an issuer of the token.

7. The method of claim 5, wherein the continuity information relates to past interactions between the requester and an issuer of the token.

8. The method of claim 5, further comprising presenting the interaction information to the requester as an interaction space.

9. The method of claim 8, further comprising displaying the interaction space to the requester on a web-enabled device.

10. The method of claim 1, wherein determining if a token is associated with the requester comprises:

obtaining a token associated with the requester from a data source if the token exists.

11. The method of claim 10, further comprising obtaining an expiration date of the token.

12. The method of claim 10, wherein adjusting the at least one information selection criterion comprises:

determining if the expiration date has occurred; and

adjusting the at least one selection criterion only if the expiration has not occurred.

13. The method of claim 10, wherein obtaining the token associated with a requester comprises reading the token from a card.

14. The method of claim 13, wherein reading the token from a card comprises reading the token using a card reader.

15. A system that adjusts, for a requester of information, at least one selection criterion, comprising:

an input interface that receives an interaction request; and

a controller that identifies a token associated with the requester and adjusts the at least one information selection criterion usable to identify information corresponding to the requester based on the identified token.

16. The system of claim 15, further comprising an output interface that provides the identified information to the requester.

17. The system of claim 16, wherein the identified information includes interaction information for the requester.

18. The system of claim 17, wherein the interaction information relates to potential interaction with an issuer of the token.

19. The system of claim 17, wherein the interaction information includes at least one of visibility information, accessibility information, and continuity information.

20. The system of claim 19, wherein the accessibility information includes at least one hypertext link associated with an issuer of the token.

21. The system of claim 19, wherein the continuity information relates to past interactions between the requester and an issuer of the token.

22. The system of claim 19, wherein the output interface presents the interaction information to the requester as an interaction space.

23. The system of claim 22, wherein the output interface displays the interaction space to the requester on a web-enabled device.

24. The system of claim 15, wherein the controller obtains an expiration date of the token.

25. The system of claim 24, wherein the controller adjusts the at least one information selection criterion by determining if the expiration date has occurred and adjusts the at least one selection criterion only if the expiration has not occurred.

26. The system of claim 15, wherein the input interface obtains a token associated with the requester from a data source if the token exists.

27. The system of claim 26, wherein the obtained token is read from a card.

28. The system of claim 27, wherein the input interface includes a card reader.