CA2358221A1 - Dynamic caller-id substitution - Google Patents
Dynamic caller-id substitution Download PDFInfo
- Publication number
- CA2358221A1 CA2358221A1 CA002358221A CA2358221A CA2358221A1 CA 2358221 A1 CA2358221 A1 CA 2358221A1 CA 002358221 A CA002358221 A CA 002358221A CA 2358221 A CA2358221 A CA 2358221A CA 2358221 A1 CA2358221 A1 CA 2358221A1
- Authority
- CA
- Canada
- Prior art keywords
- user
- calls
- agents
- substitute
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Landscapes
- Telephonic Communication Services (AREA)
Abstract
The making of substitute caller-ID telephone calls by service bureaus or agents on behalf of users is fa-cilitated by permitting users and service bureaus, hav-ing the appropriate classes of service, to provision a centralized data base, such as an SCP, with the requi-site call management information independently of one another but which confirms the authority of the service bureau to act on behalf of a user before permitting such calls to be made.
Description
DYNAMIC CALLER-ID SUBSTITUTION
FIELD OF THE INVENTION
This invention relates to caller-ID substitution and, more particularly, to a system for facilitating such substitution in the Public Switched Telephone Network (PSTN).
BACKGROUND OF THE INVENTION
U.S. Patent 5,901,209 discloses a system which permits a user to store call management information in a centralized data base that will enable an agent des-ignated by the user to make targeted calls using the caller-ID of the user rather than that of the agent.
As therein disclosed, a user connects to the "call man-agement system" using a telephone, fax, email or per-sonal computer and transmits to its centralized data base information about the targets to be called by the agent on behalf of the user. When an agent connects to the system to make the calls, the identity of the agent is matched against the list and, if properly author-ized, the agent is permitted to make calls to the tar-gets designated in the data base. The call management system includes a dialer which performs predictive di-aling functions.
The difficulty with the aforementioned system, which is based on having the user populate the central-ized data base, is that the agent, e.g., an advertising agency service bureau, may have more demographic infor-mation about whom to call and when to call than the user, but the prior art system assumed that the user would input all information into the call management system and so made no provision that would enable a service bureau to input important information into the data base independently of the user. Moreover, the user may not know in advance whether the agent desires to use local or remotely located sub-agents to make some of the calls, whom these sub-agents would be, what their telephone numbers are and when to make certain calls taking into consideration local regulations, holidays, etc. Accordingly, it would be advantageous to allow either or both the user and the agent to make relevant entries in the centralized data base; to per-mit the agent to initiate a request for authorization to make substitute ID calls on behalf of a user and to allow the user at any time to authorize an agent or to respond to an agent's request for authorization to make substitute-ID calls on behalf of the user.
In accordance with the principles of the inven-tion, both telephone users and their agents having the appropriate class of service are permitted to have in-dependent log-in access to a centralized data base, such as a service control point (SCP), for storing call management information. The centralized data base is able to accept information provided by an agent, as well as by a user, but does not permit the agent to begin making substitute-ID targeted calls until the it obtains authorization from the user whose Caller-ID is to be substituted for that of the agent. A user may designate an agent who is either locally or remotely located in the PSTN and, once an agent has been author-ized, the agent may designate local or remote sub-agents under his control to substitute the user's ID
for that of the agent/sub-agent.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other features of the invention may become more apparent from a reading of the ensuing description together with the drawing, in which:
Fig. 1 is a functional block diagram illustrating a communications system which is arranged to provide dynamic caller-ID substitution;
Figs. 2, 3 and 4, arranged as shown in Fig. 5, are a flow chart showing the entry of information into the SCP and confirmation of authorization for Caller-ID
substitution requested by agents and sub-agents;
FIELD OF THE INVENTION
This invention relates to caller-ID substitution and, more particularly, to a system for facilitating such substitution in the Public Switched Telephone Network (PSTN).
BACKGROUND OF THE INVENTION
U.S. Patent 5,901,209 discloses a system which permits a user to store call management information in a centralized data base that will enable an agent des-ignated by the user to make targeted calls using the caller-ID of the user rather than that of the agent.
As therein disclosed, a user connects to the "call man-agement system" using a telephone, fax, email or per-sonal computer and transmits to its centralized data base information about the targets to be called by the agent on behalf of the user. When an agent connects to the system to make the calls, the identity of the agent is matched against the list and, if properly author-ized, the agent is permitted to make calls to the tar-gets designated in the data base. The call management system includes a dialer which performs predictive di-aling functions.
The difficulty with the aforementioned system, which is based on having the user populate the central-ized data base, is that the agent, e.g., an advertising agency service bureau, may have more demographic infor-mation about whom to call and when to call than the user, but the prior art system assumed that the user would input all information into the call management system and so made no provision that would enable a service bureau to input important information into the data base independently of the user. Moreover, the user may not know in advance whether the agent desires to use local or remotely located sub-agents to make some of the calls, whom these sub-agents would be, what their telephone numbers are and when to make certain calls taking into consideration local regulations, holidays, etc. Accordingly, it would be advantageous to allow either or both the user and the agent to make relevant entries in the centralized data base; to per-mit the agent to initiate a request for authorization to make substitute ID calls on behalf of a user and to allow the user at any time to authorize an agent or to respond to an agent's request for authorization to make substitute-ID calls on behalf of the user.
In accordance with the principles of the inven-tion, both telephone users and their agents having the appropriate class of service are permitted to have in-dependent log-in access to a centralized data base, such as a service control point (SCP), for storing call management information. The centralized data base is able to accept information provided by an agent, as well as by a user, but does not permit the agent to begin making substitute-ID targeted calls until the it obtains authorization from the user whose Caller-ID is to be substituted for that of the agent. A user may designate an agent who is either locally or remotely located in the PSTN and, once an agent has been author-ized, the agent may designate local or remote sub-agents under his control to substitute the user's ID
for that of the agent/sub-agent.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other features of the invention may become more apparent from a reading of the ensuing description together with the drawing, in which:
Fig. 1 is a functional block diagram illustrating a communications system which is arranged to provide dynamic caller-ID substitution;
Figs. 2, 3 and 4, arranged as shown in Fig. 5, are a flow chart showing the entry of information into the SCP and confirmation of authorization for Caller-ID
substitution requested by agents and sub-agents;
Fig. 6 is a graphical user interface (GUI) at the user's terminal; and Fig. 7 is a graphical user interface (GUI) at an agent's terminal.
GENERAL DESCRIPTION
Fig. 1 illustrates the overall communication system which enables the automatic and asynchronous provisioning of caller-ID substitution by users and by service bureaus (agents) seeking authorization to make such calls on behalf of users. A centralized data base 100, such as a service control point (SCP) is conven-tionally used in connection with SS7 Network 130 to control the switching of telephone calls through multi-ple central offices of the PSTN by using data retrieved from its database 101a, b. In accordance with an as-pect of the present invention, the SCP 100 is provi-sioned with the relevant caller-ID call management in-formation by users and agents who are enabled to access the SCP either through a secure Internet Protocol (IP) network 110 or via a central office 120 and either an SS7 connection 131 or a secure IP network connection 120-2. The SS7 connection to the SCP would be from the Sub-Agent 126 via an SSP and STP. This communication is well understood and is not described here. The ele-ment shown in 127 provides secure dial-up modem to IP
access to the Sub-agent 126. The element in 127 is shown with a security firewall (FW) for additional se-curity. Provisioning of the SCP with the relevant caller-ID call management information allows users to select service bureaus and service bureaus to select their sub-agents anywhere in the country to make tar-geted calls on a local basis.
Assume that a user at terminal 105 desires to re-tain a service bureau 26 to make calls on the user's behalf. The user at terminal 105 logs on to the secure IP network 110 through a secure access server contain-ing a firewall 29. The logon is accomplished by fur-nishing his log-on ID and password and supplies the URL
GENERAL DESCRIPTION
Fig. 1 illustrates the overall communication system which enables the automatic and asynchronous provisioning of caller-ID substitution by users and by service bureaus (agents) seeking authorization to make such calls on behalf of users. A centralized data base 100, such as a service control point (SCP) is conven-tionally used in connection with SS7 Network 130 to control the switching of telephone calls through multi-ple central offices of the PSTN by using data retrieved from its database 101a, b. In accordance with an as-pect of the present invention, the SCP 100 is provi-sioned with the relevant caller-ID call management in-formation by users and agents who are enabled to access the SCP either through a secure Internet Protocol (IP) network 110 or via a central office 120 and either an SS7 connection 131 or a secure IP network connection 120-2. The SS7 connection to the SCP would be from the Sub-Agent 126 via an SSP and STP. This communication is well understood and is not described here. The ele-ment shown in 127 provides secure dial-up modem to IP
access to the Sub-agent 126. The element in 127 is shown with a security firewall (FW) for additional se-curity. Provisioning of the SCP with the relevant caller-ID call management information allows users to select service bureaus and service bureaus to select their sub-agents anywhere in the country to make tar-geted calls on a local basis.
Assume that a user at terminal 105 desires to re-tain a service bureau 26 to make calls on the user's behalf. The user at terminal 105 logs on to the secure IP network 110 through a secure access server contain-ing a firewall 29. The logon is accomplished by fur-nishing his log-on ID and password and supplies the URL
of SCP 100. In addition, the user 105 may have to sup-ply a digital certificate or other means to verify their identity. Security techniques using digital certificates, Biometrics, or similar technology are well known and are not described here. When a connec-tion is established to the SCP, SCP 100 consults its data base 101-a, b to determine whether the user at terminal 105 has the appropriate class of service to permit substitute-ID calls to be made on his behalf.
(Similarly, when a service bureau 26 or one of the ser-vice bureau's sub-agents 27, 28 connects to SCP 100, a check is made to determine whether the service bureau or agent has a class of service appropriate to making substitute ID calls.) Service bureau 26 may also have a remotely located sub-agent 126 positioned to make targeted calls in the local calling area served by re-mote central office 120.
Assuming that the user at terminal 105 has ac-cessed SCP data base 101a, b, the user enters so much of the needed information as may then be available to him. For example, the user may at first only know the name or URL of service bureau 26 or of only one of agents 27, 28 who shall make the targeted calls on the user's behalf. This information is transmitted from user terminal 105 through IP network 110 as encrypted data to SCP 100. Additional data which the user de-sires to be displayed to called parties when the tar-geted calls are later made by the agent, such as the user's name, telephone number or IP address may also be transmitted by the user to the SCP at this time, or later when it is decided upon by the user. However, other information that is useful or important to the success of the targeted calls, such as the start and end times of targeted calling for each geographic area, may not be known by the user at terminal 105. The se-lected service bureau 26 having more experience with making targeted calls, may well be in possession of such information as well as having a suitable collection of °'scripts'° to employ in making such calls.
Further, the service bureau 26 rather than the user may know the identity of his sub-agents 27 or 28 which shall be employed in actually making the targeted calls. Moreover, the service bureau 26 may desire to employ a remote sub-agent 126 who homes on a telephone central office 120 to make calls to local calls to tar-gets such as 128, all of which is completely unknown and of no interest or concern to the user at terminal 105.
Let it be supposed that the user at terminal 105 and a representative of the service bureau at terminal 26 have discussed the making of substitute ID calls, but the user has not yet input any information into SCP
100. Independently of the user's action, personnel at service bureau 26, in anticipation of being later au-thorized by the user, may enter information into a por-tion of SCP 100 data base 101a assigned to the user's directory number. This information will remain inac-tine until the user has had an oppartunity to confirm the service bureau's authority to make substitute ID
calls on the user's behalf. For example, acting on the information verbally provided by the user, service bu-reau personnel may assign one of local sub-agents 27, 28 and/or a remote sub-agent 126 located in a different state or time zone to make substitute ID calls on be-half of the user. Regulations of various governmental agencies may dictate the start and end times of tar-geted calls in the different time zones. This informa-tion may be known by the remote sub-agent 126 but not by the user at terminal 105 or even by the service bu-reau 26. Accordingly, it may be necessary to allow a remote sub-agent 126 (whose identity may not be known to user 105) to be able to enter into SCP 100 the per-missible start and end times for targeted calling in his area which may be different from the start and end times of targeted calling in the area served by service bureau 26 or agents 27, 28. All of the information so _5-entered by the service bureau or the sub agents, how-ever, remains inactive until the user has confirmed the authorization of the service bureau. In the meantime, SCP 100 will return to the respective accessing party (26, 27, 28 or 126) an indication that their respective entry is deemed to be incomplete. Likewise, had the user at terminal 105 indicated that service bureau 26 was authorized to make calls on the user's behalf, SCP
100 would return an indication that the entry remains unconfirmed until the service bureau accepts the as-signment. When the user provides authorization, or when the service bureau accepts the assignment, a con-firmation messages is transmitted to the respective party that substitute ID calls may now be made.
Figs. 2, 3 and 4 assembled together as shown in Fig. 5, delineate the message flow among SCP 100, an illustrative user at terminal 105, an illustrative service bureau 26 having a local sub-agent 27, and a remote sub-agent 126 for making targeted calls in the area served by remote central office 120. The user "Bob" at terminal 105 issues a logon request 200 through private IP network 110, receives a secure pass-word prompt 205 and transmits password 210 to SCP 100.
The user at terminal 105 then transmits a "substitute-ID request" 215 to SCP 100. SCP 100 determines if the user at terminal 105 has the appropriate class of serv-ice to allow substitute-ID calls to be made 220. If such calls are permitted, SCP 100 sends an accept sub-stitution message 224. The user then transmits a mes-sage 226 identifying the substitution to be made, e.g., "Bobby". SCP may advantageously screen the substitu-tion at 230 to deny certain undesirable substitutions from being made, e.g., those that pretend to be govern-mental agencies; a fictitious calling name such as "police"; or a false calling number such as "911", etc.
Depending on the result of filtering, the substitute-ID
may be rejected 232 or accept 234. Assuming the re-quest is acknowledged, the user then transmits information 236 indicating the time and date interval during which substitute-ID calls may be made. At 240 the time and date information is checked for validity and is either rejected 242 or accept 244. SCP 100 contains a list of service bureaus who have been as-signed a class of service which permits them to make substitute-ID calls. The user at terminal 105 may transmit a request 246 to obtain a copy of the regis-tered service bureau list. A search of database 101a,b is made at 250 and a list is transmitted back to the user at 252. The data base search may also advanta-geously permit a search for service bureaus in specific zip codes or phone prefixes, etc., as indicated by the options shown in the graphical user interfaces depicted in Figs. 6 and 7.
In Fig. 3, the user sends message 360 to select from the list a registered agent (service bureau) whom the user desires to authorize to make calls on the user's behalf.. The SCP accepts the message at 362.
The next step shows a message 364 indicating that the request needs to be confirmed by the selected agent.
Independently of what the user has done, when service bureau 26 sends a logon request 365 to SCP 100, SCP 100 responds with a secure password request 366, to which the service bureau sends a secure logon password 367.
Service bureau 26 may then issue a request 368 for a list of user's who have indicated a desire to have substitute-ID calls made on each of their behalf's.
Let it be assumed that data base 101-a,b returns a list 370 with the identity of the user at terminal 105, i.e., user "Bob". The service bureau then sends re-quest 374 for the details of the request made by "Bob"
and at 374 the SCP responds by furnishing the substitute-ID information. If the information is ac-ceptable to the service bureau it sends message 376 to the SCP which sends a confirmation message 378 to the user at terminal 105. The user may then respond by accepting the service bureau's by sending message 379.
_7_ It should be noted that the user need not have been logged on when the service bureau send message 378 but may respond later when the user does log on.
Fig. 4 shows that, in similar fashion to the man-s ner in which the service bureau logged on to the SCP, a local sub-agent 27, or a remote sub-agent 126 may ini-tiate a similar sequence of operations 480, 482, 484, and 486. In this case, however, the authority of the local or remote sub-agent must be validated by both the user and the service bureau. At 488 SCP 100 sends a "Valid sub-agent'° inquiry message to service bureau 26 requesting authentication of sub-agent 27 (or of remote sub-agent 126). Service bureau may respond to this re-quest by send message 489 to indicate that the sub-agent is OK. If the sub-agent 27 (or 126) is authenti-cated by service bureau 26, SCP responds and a sequence of information exchange messages 490 through 497 tran-spire which are analogous to the sequence of message 370 through 379 of Fig. 3.
The above-described sequences have, for the sake of simplicity, been illustrated with a single service bureau 26 employing a local and a remote sub-agent, but it should be apparent the there is no practical limit to the number of users, service bureaus, agents and sub-agents that can be accommodated by SCP 100. Fur-ther, the user(s), service bureaus) and agents) may provision the SCP asynchronously with one another and there is no set order in which they logon nor is there any need for human intervention to populate the SCP
database.
Fig. 6 illustrates the Graphical User Interface (GUI) of a user provisioning SCP 100 with the criteria for a service bureau to make substitute-ID calls. Title bar 8000 indicates the functions to be setup. 8010 in-dicates the user's normal default caller-ID if not modified as displayed by their telephone service pro-vider. This normally would be the user's billing name or an abbreviation of that name. Underneath that _g-static text line the current caller-ID is displayed.
The user may change or substitute its own caller-ID by defining a substituting field on this page and specify-ing themselves as the "service bureau", provided the user has been accorded this privilege by registration for the appropriate class of service in SCP 100.
Normally the user will be selecting a 3rd party agent or service bureau to perform substitute caller-ID
in a telemarketing campaign. The user can first select criteria in searching for telemarketers for specific regions they which to have a telemarketing activity.
Criteria for selecting telemarketers registered with the SCP can be defined in 8016. The details of de-pressing this icon is not shown but would include cri-teria such as search for 3rd party telemarketers by name, zip code, city, or the DN they are located. Once this filter is applied on the entire database of regis-tered 3rd party service providers, the user would use the pull down menu 8018 to select one of the service bureaus listed. For each service bureau listed, the user may individually define the Caller-ID field for that service bureau. This is exemplified in 8018 as "Sidney's Home Delivery". The user may also specify the Caller-ID callback number as is shown in 8019. In this case, 800-555-5555. Further restrictions may be placed on the individual service bureaus such as to the dates they may substitute 8020, 8022, the days of the week they may substitute 8026, the time of day they may substitute 8024, and the dialed number prefixes they may substitute 8028. Likewise, this implementation conveniently allows the user to define the telephone script to be used by each individual service bureau used 8040. Furthermore, this field may contain one or more hypertext links to web pages containing such scripting information, thus eliminating the need to di-rectly provide detailed textual information in these fields. A template or default script may be specified without requiring the user to re-enter the script for each service bureau specified 8042. Once a 3rd party service bureau has been enabled by the user, the serv-ice bureau must accept the request. As is shown in the message flow diagrams, elsewhere within this disclo-sure, the 3rd party service bureau may accept the user for substituting or the user may enable the substituter in any order. Once both have accepted each other's requests, confirmation messages are sent to each from the SCP.
Fig. 7 shows a GUI for permitting the 3rd party service bureau to provision SCP 100 for substitute caller-ID calls containing information similar to that entered by the user. The page title is shown in 9000.
Criteria as to which users to view is defined by a fil-ter page 9016. On this page, the service bureau would filter users with criteria such as show requests by those users starting with "S". In this case, the exem-plified user "Sidney Inc." appears in the pull down menu 9014. The desired Caller-ID field "Sidney°s Home Delivery" is shown in 9018. The Call Back Caller-ID
field is shown in 9019. The start and end dates 9020 and 9022 are shown as was entered by the user as was shown in Fig. 8. Likewise, the days of the week are shown in 9026, start and end times in 9024 and 9025, and the prefixes that the service bureau is restricted to are shown in 9028. Also shown is the specific telephone script 9040. Not shown but would also be included in such an implementation would be an optional table of exact dialed numbers (DNs) and the names of those users if such information was available. As has been previously described, the user and the service bu-reau may asynchronously access the SCP. To handle the case of a service bureau accepting a registered user (e. g. Sidney Inc.) substituting request before that said user has entered their specific data such as Sub-stituting name, dates of substituting, etc., these fields would appear as asterisk "*****" fields to the service bureau until the user had entered that data.
As was described previously, when the user does enable, the service bureau would receive a confirmation message and the data specific to these field would also be transmitted.
What has been described is deemed to be illustra-tive of the principles of the invention. Further and other modifications may be made by those skilled in the art without, however, departing from the spirit and scope of the invention.
(Similarly, when a service bureau 26 or one of the ser-vice bureau's sub-agents 27, 28 connects to SCP 100, a check is made to determine whether the service bureau or agent has a class of service appropriate to making substitute ID calls.) Service bureau 26 may also have a remotely located sub-agent 126 positioned to make targeted calls in the local calling area served by re-mote central office 120.
Assuming that the user at terminal 105 has ac-cessed SCP data base 101a, b, the user enters so much of the needed information as may then be available to him. For example, the user may at first only know the name or URL of service bureau 26 or of only one of agents 27, 28 who shall make the targeted calls on the user's behalf. This information is transmitted from user terminal 105 through IP network 110 as encrypted data to SCP 100. Additional data which the user de-sires to be displayed to called parties when the tar-geted calls are later made by the agent, such as the user's name, telephone number or IP address may also be transmitted by the user to the SCP at this time, or later when it is decided upon by the user. However, other information that is useful or important to the success of the targeted calls, such as the start and end times of targeted calling for each geographic area, may not be known by the user at terminal 105. The se-lected service bureau 26 having more experience with making targeted calls, may well be in possession of such information as well as having a suitable collection of °'scripts'° to employ in making such calls.
Further, the service bureau 26 rather than the user may know the identity of his sub-agents 27 or 28 which shall be employed in actually making the targeted calls. Moreover, the service bureau 26 may desire to employ a remote sub-agent 126 who homes on a telephone central office 120 to make calls to local calls to tar-gets such as 128, all of which is completely unknown and of no interest or concern to the user at terminal 105.
Let it be supposed that the user at terminal 105 and a representative of the service bureau at terminal 26 have discussed the making of substitute ID calls, but the user has not yet input any information into SCP
100. Independently of the user's action, personnel at service bureau 26, in anticipation of being later au-thorized by the user, may enter information into a por-tion of SCP 100 data base 101a assigned to the user's directory number. This information will remain inac-tine until the user has had an oppartunity to confirm the service bureau's authority to make substitute ID
calls on the user's behalf. For example, acting on the information verbally provided by the user, service bu-reau personnel may assign one of local sub-agents 27, 28 and/or a remote sub-agent 126 located in a different state or time zone to make substitute ID calls on be-half of the user. Regulations of various governmental agencies may dictate the start and end times of tar-geted calls in the different time zones. This informa-tion may be known by the remote sub-agent 126 but not by the user at terminal 105 or even by the service bu-reau 26. Accordingly, it may be necessary to allow a remote sub-agent 126 (whose identity may not be known to user 105) to be able to enter into SCP 100 the per-missible start and end times for targeted calling in his area which may be different from the start and end times of targeted calling in the area served by service bureau 26 or agents 27, 28. All of the information so _5-entered by the service bureau or the sub agents, how-ever, remains inactive until the user has confirmed the authorization of the service bureau. In the meantime, SCP 100 will return to the respective accessing party (26, 27, 28 or 126) an indication that their respective entry is deemed to be incomplete. Likewise, had the user at terminal 105 indicated that service bureau 26 was authorized to make calls on the user's behalf, SCP
100 would return an indication that the entry remains unconfirmed until the service bureau accepts the as-signment. When the user provides authorization, or when the service bureau accepts the assignment, a con-firmation messages is transmitted to the respective party that substitute ID calls may now be made.
Figs. 2, 3 and 4 assembled together as shown in Fig. 5, delineate the message flow among SCP 100, an illustrative user at terminal 105, an illustrative service bureau 26 having a local sub-agent 27, and a remote sub-agent 126 for making targeted calls in the area served by remote central office 120. The user "Bob" at terminal 105 issues a logon request 200 through private IP network 110, receives a secure pass-word prompt 205 and transmits password 210 to SCP 100.
The user at terminal 105 then transmits a "substitute-ID request" 215 to SCP 100. SCP 100 determines if the user at terminal 105 has the appropriate class of serv-ice to allow substitute-ID calls to be made 220. If such calls are permitted, SCP 100 sends an accept sub-stitution message 224. The user then transmits a mes-sage 226 identifying the substitution to be made, e.g., "Bobby". SCP may advantageously screen the substitu-tion at 230 to deny certain undesirable substitutions from being made, e.g., those that pretend to be govern-mental agencies; a fictitious calling name such as "police"; or a false calling number such as "911", etc.
Depending on the result of filtering, the substitute-ID
may be rejected 232 or accept 234. Assuming the re-quest is acknowledged, the user then transmits information 236 indicating the time and date interval during which substitute-ID calls may be made. At 240 the time and date information is checked for validity and is either rejected 242 or accept 244. SCP 100 contains a list of service bureaus who have been as-signed a class of service which permits them to make substitute-ID calls. The user at terminal 105 may transmit a request 246 to obtain a copy of the regis-tered service bureau list. A search of database 101a,b is made at 250 and a list is transmitted back to the user at 252. The data base search may also advanta-geously permit a search for service bureaus in specific zip codes or phone prefixes, etc., as indicated by the options shown in the graphical user interfaces depicted in Figs. 6 and 7.
In Fig. 3, the user sends message 360 to select from the list a registered agent (service bureau) whom the user desires to authorize to make calls on the user's behalf.. The SCP accepts the message at 362.
The next step shows a message 364 indicating that the request needs to be confirmed by the selected agent.
Independently of what the user has done, when service bureau 26 sends a logon request 365 to SCP 100, SCP 100 responds with a secure password request 366, to which the service bureau sends a secure logon password 367.
Service bureau 26 may then issue a request 368 for a list of user's who have indicated a desire to have substitute-ID calls made on each of their behalf's.
Let it be assumed that data base 101-a,b returns a list 370 with the identity of the user at terminal 105, i.e., user "Bob". The service bureau then sends re-quest 374 for the details of the request made by "Bob"
and at 374 the SCP responds by furnishing the substitute-ID information. If the information is ac-ceptable to the service bureau it sends message 376 to the SCP which sends a confirmation message 378 to the user at terminal 105. The user may then respond by accepting the service bureau's by sending message 379.
_7_ It should be noted that the user need not have been logged on when the service bureau send message 378 but may respond later when the user does log on.
Fig. 4 shows that, in similar fashion to the man-s ner in which the service bureau logged on to the SCP, a local sub-agent 27, or a remote sub-agent 126 may ini-tiate a similar sequence of operations 480, 482, 484, and 486. In this case, however, the authority of the local or remote sub-agent must be validated by both the user and the service bureau. At 488 SCP 100 sends a "Valid sub-agent'° inquiry message to service bureau 26 requesting authentication of sub-agent 27 (or of remote sub-agent 126). Service bureau may respond to this re-quest by send message 489 to indicate that the sub-agent is OK. If the sub-agent 27 (or 126) is authenti-cated by service bureau 26, SCP responds and a sequence of information exchange messages 490 through 497 tran-spire which are analogous to the sequence of message 370 through 379 of Fig. 3.
The above-described sequences have, for the sake of simplicity, been illustrated with a single service bureau 26 employing a local and a remote sub-agent, but it should be apparent the there is no practical limit to the number of users, service bureaus, agents and sub-agents that can be accommodated by SCP 100. Fur-ther, the user(s), service bureaus) and agents) may provision the SCP asynchronously with one another and there is no set order in which they logon nor is there any need for human intervention to populate the SCP
database.
Fig. 6 illustrates the Graphical User Interface (GUI) of a user provisioning SCP 100 with the criteria for a service bureau to make substitute-ID calls. Title bar 8000 indicates the functions to be setup. 8010 in-dicates the user's normal default caller-ID if not modified as displayed by their telephone service pro-vider. This normally would be the user's billing name or an abbreviation of that name. Underneath that _g-static text line the current caller-ID is displayed.
The user may change or substitute its own caller-ID by defining a substituting field on this page and specify-ing themselves as the "service bureau", provided the user has been accorded this privilege by registration for the appropriate class of service in SCP 100.
Normally the user will be selecting a 3rd party agent or service bureau to perform substitute caller-ID
in a telemarketing campaign. The user can first select criteria in searching for telemarketers for specific regions they which to have a telemarketing activity.
Criteria for selecting telemarketers registered with the SCP can be defined in 8016. The details of de-pressing this icon is not shown but would include cri-teria such as search for 3rd party telemarketers by name, zip code, city, or the DN they are located. Once this filter is applied on the entire database of regis-tered 3rd party service providers, the user would use the pull down menu 8018 to select one of the service bureaus listed. For each service bureau listed, the user may individually define the Caller-ID field for that service bureau. This is exemplified in 8018 as "Sidney's Home Delivery". The user may also specify the Caller-ID callback number as is shown in 8019. In this case, 800-555-5555. Further restrictions may be placed on the individual service bureaus such as to the dates they may substitute 8020, 8022, the days of the week they may substitute 8026, the time of day they may substitute 8024, and the dialed number prefixes they may substitute 8028. Likewise, this implementation conveniently allows the user to define the telephone script to be used by each individual service bureau used 8040. Furthermore, this field may contain one or more hypertext links to web pages containing such scripting information, thus eliminating the need to di-rectly provide detailed textual information in these fields. A template or default script may be specified without requiring the user to re-enter the script for each service bureau specified 8042. Once a 3rd party service bureau has been enabled by the user, the serv-ice bureau must accept the request. As is shown in the message flow diagrams, elsewhere within this disclo-sure, the 3rd party service bureau may accept the user for substituting or the user may enable the substituter in any order. Once both have accepted each other's requests, confirmation messages are sent to each from the SCP.
Fig. 7 shows a GUI for permitting the 3rd party service bureau to provision SCP 100 for substitute caller-ID calls containing information similar to that entered by the user. The page title is shown in 9000.
Criteria as to which users to view is defined by a fil-ter page 9016. On this page, the service bureau would filter users with criteria such as show requests by those users starting with "S". In this case, the exem-plified user "Sidney Inc." appears in the pull down menu 9014. The desired Caller-ID field "Sidney°s Home Delivery" is shown in 9018. The Call Back Caller-ID
field is shown in 9019. The start and end dates 9020 and 9022 are shown as was entered by the user as was shown in Fig. 8. Likewise, the days of the week are shown in 9026, start and end times in 9024 and 9025, and the prefixes that the service bureau is restricted to are shown in 9028. Also shown is the specific telephone script 9040. Not shown but would also be included in such an implementation would be an optional table of exact dialed numbers (DNs) and the names of those users if such information was available. As has been previously described, the user and the service bu-reau may asynchronously access the SCP. To handle the case of a service bureau accepting a registered user (e. g. Sidney Inc.) substituting request before that said user has entered their specific data such as Sub-stituting name, dates of substituting, etc., these fields would appear as asterisk "*****" fields to the service bureau until the user had entered that data.
As was described previously, when the user does enable, the service bureau would receive a confirmation message and the data specific to these field would also be transmitted.
What has been described is deemed to be illustra-tive of the principles of the invention. Further and other modifications may be made by those skilled in the art without, however, departing from the spirit and scope of the invention.
Claims (9)
1. A system for performing caller-ID substitu-tion, comprising:
a.) a centralized data base for storing call con-trol information including classes of service identify-ing users who permit agents to make substitute-ID calls on their behalf and agents permitted to make substitute-ID calls on behalf of users; and b.) means for controlling access to said data base to allow i.) users to designate specific agents to make substitute-ID calls;
ii.) agents to request authorization from users whose caller-ID is to be substituted for the agents' caller-ID; and iii.) users to respond to said request to permit or deny said agents said authorization.
a.) a centralized data base for storing call con-trol information including classes of service identify-ing users who permit agents to make substitute-ID calls on their behalf and agents permitted to make substitute-ID calls on behalf of users; and b.) means for controlling access to said data base to allow i.) users to designate specific agents to make substitute-ID calls;
ii.) agents to request authorization from users whose caller-ID is to be substituted for the agents' caller-ID; and iii.) users to respond to said request to permit or deny said agents said authorization.
2. A system according to claim 1, wherein said access controlling means permits an agent to designate sub-agents to make said substitute-ID calls without further authorization from said user.
3. A system according to claim 1, wherein said access to said database may be made currently or asynchronously by both users and agents
4. A system according to claim 1, wherein said centralized data base is a service control point (SCP).
5. A system according to claim 4, wherein said SCP obtains confirmation from a user of a service bureau's request to make substitute-ID calls.
6. A system according to claim 4, wherein said SCP obtains confirmation from a service bureau of a sub-agent's authority to make substitute-ID calls on behalf of a user.
7. A system according to claim 4, wherein said SCP stores a list of service bureaus and agents having a class of service permitting substitute-ID calls to be made on behalf of users.
8. A system according to claim 4, wherein said SCP filters substitute-IDs against a list of prohibited substitute-IDs.
9. Each and every novel feature or novel combina-tion of features herein disclosed.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US67775400A | 2000-10-03 | 2000-10-03 | |
| US09/677,754 | 2000-10-03 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2358221A1 true CA2358221A1 (en) | 2002-04-03 |
Family
ID=24719986
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002358221A Abandoned CA2358221A1 (en) | 2000-10-03 | 2001-10-03 | Dynamic caller-id substitution |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2358221A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7899169B2 (en) | 2005-10-20 | 2011-03-01 | NobelBiz, Inc. | System and method for modifying communication information (MCI) |
-
2001
- 2001-10-03 CA CA002358221A patent/CA2358221A1/en not_active Abandoned
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7899169B2 (en) | 2005-10-20 | 2011-03-01 | NobelBiz, Inc. | System and method for modifying communication information (MCI) |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6587867B1 (en) | Internet-based subscriber profile management of a communications system | |
| CA2230339C (en) | Method and system for collecting and authenticating updates to a network-based directory service | |
| US6031904A (en) | Service order mechanism for telephone subscriber | |
| US6097793A (en) | WWW-telephony integration | |
| US8873725B2 (en) | Methods and apparatus for authenticating and authorizing ENUM registrants | |
| US6944279B2 (en) | Enhanced directory assistance service providing individual or group directories | |
| US7778403B2 (en) | System and method for implementing and accessing call forwarding services | |
| US6788772B2 (en) | System and method for controlling outgoing telephone calls | |
| US20080008105A1 (en) | User-controlled telecommunications system | |
| JP3344984B2 (en) | Call connection system | |
| CN101911652B (en) | Strengthen ENUM fail safe | |
| WO2003030502A1 (en) | Systems and methods for providing user profile information in conjunction in conjunction with an enhanced caller information system | |
| JP4323089B2 (en) | Procedure for accessing service in data communication system and data communication system | |
| JP2002514330A (en) | Internet-based subscriber profile management for communication systems | |
| US20020126821A1 (en) | System and method for logging outgoing telephone calls | |
| CA2358221A1 (en) | Dynamic caller-id substitution | |
| TWI788799B (en) | Two-way number-concealed call method and corresponding system and computer readable medium | |
| EP1084556B1 (en) | Data network access | |
| WO2002073935A2 (en) | System and method for controlling outgoing telephone calls and logging telephone calls | |
| FR2823931A1 (en) | Centralised address book management system updates local copies | |
| MXPA99010721A (en) | Internet-based subscriber profile management of a communications system | |
| EP1155562A2 (en) | Telephone service system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |