WO2017176235A1

WO2017176235A1 - Authorization code for a call

Info

Publication number: WO2017176235A1
Application number: PCT/US2016/025834
Authority: WO
Inventors: James M. Mann
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2016-04-04
Filing date: 2016-04-04
Publication date: 2017-10-12

Abstract

In some examples, a method performed by a called user terminal, includes: receiving, from a calling user terminal, a call request; in response to the call request, sending, to the calling user terminal, a request for an authorization code; determining whether a matching authorization code is received from the calling user terminal; and in response to determining that the matching authorization code has not been received from the calling user terminal, declining to provide an alert of the call request at the called user terminal.

Description

AUTHORIZATION CODE FOR A CALL

Background

[0001 ] A communications session can be established between a calling user terminal and a called user terminal over a communications network. A

communications network can include a wireless network, such as a cellular wireless network, or a wired network. To establish the communications session, the calling user terminal sends a call request over the communications network to the called user terminal. In response to the calling request, an alert is provided at the called user terminal.

Brief Description Of The Drawings

[0002] Some implementations of the present disclosure are described with respect to the following figures.

[0003] Fig. 1 is a block diagram of a network arrangement according to some examples.

[0004] Fig. 2 is a flow diagram of a process performed by a called user terminal, according to some examples.

[0005] Fig. 3 is a block diagram of a user terminal according to further examples.

[0006] Fig. 4 is a block diagram of a non-transitory storage medium storing instructions according to some examples.

Detailed Description

[0007] Unwanted or spam calls are a continuing source of irritation for users. An unwanted or spam phone call can refer to any phone call from any caller that a callee does not recognize or does not wish to answer. Examples of unwanted or spam phone calls can include phone calls made by marketing companies or other entities that wish to sell products or services to callees, or that wish to seek donations or conduct surveys. [0008] A callee (a user being called) can rely on a caller identifier (ID) that is displayed with an incoming call at the user terminal of the callee to determine whether or not to answer the call. However, even though the caller ID provides some information regarding the caller, the callee is still interrupted with the alert provided with the incoming call, where the alert can be in the form of an audible ring, a visual alert, or a vibration of the user terminal. In some cases, the caller ID can include a phone number that the callee does not recognize, so that the callee cannot make an informed decision on whether or not to answer the incoming call.

[0009] In other cases, a blacklist of callers can be maintained, such as by a user terminal or by a service provider that provides communications services to a user. The blacklist identifies callers that the user does not wish to receive calls from. Any incoming call associated with a caller that is identified in the blacklist would be blocked. Although the blacklist is effective in blocking callers that are actually identified by the blacklist, there may be many other callers who are not identified by the blacklist whose incoming calls a user would like to have blocked.

[0010] In accordance with some implementations of the present disclosure, a called user terminal (the user terminal of the callee) can make a determination of whether or not an alert is to be generated in response to a call request from a caller user terminal (the user terminal of the caller), based on whether an authorization code is received. As used here, a "user terminal" can refer to any electronic device that can be used by a user to establish a communications session (or equivalently "call session" or more simply "call"), such as a voice call, a text messaging

exchange, a video conference call, or any other type of communications session. Examples of user terminals include telephone handsets, smart phones, desktop computers, notebook computers, tablet computers, wearable devices (e.g. smart watches, smart eyeglasses, etc.), or any other types of electronic devices through which a user can perform communications with another endpoint.

[001 1 ] An authorization code can refer to any information that can be used to authenticate a caller as someone whose incoming call should be accepted by a callee. The authorization code can be in the form of a personal identification number (PIN), a string of characters, or any other type of information.

[0012] Fig. 1 is a block diagram of an example communications arrangement 100 that includes a calling user terminal 102 and a called user terminal 104. The calling user terminal 102 can establish a communications session with the called user terminal 104 over a network 106. Although the user terminal 102 is referred to as the calling user terminal, and the user terminal 104 is referred to as the called user terminal, it is noted that in other instances, the user terminal 104 can be the calling user terminal and the user terminal 102 can be the called user terminal, in situations where the user terminal 104 calls the user terminal 102.

[0013] Also, although just two user terminals are shown in Fig. 1 , it is noted that in other examples, more than two user terminals can be present. A call can be established between two user terminals, or among more than two user terminals.

[0014] The network 106 can include a mobile communications network that includes base stations that are able to establish wireless links with user terminals. In other examples, the network 106 can include a wired network, such as the Internet or a traditional landline network.

[0015] In the example shown in Fig. 1 , a call control engine 106 in the calling user terminal 102 can issue a call request 108 over the network 106 to the called user terminal 104. As used here, an "engine" can refer to a hardware processing circuit or a combination of machine-readable instructions executable on the hardware processing circuit. The hardware processing circuit can include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or any other type of hardware processing circuit.

[0016] The call request 108 can be according to any of various different protocols, such as the Session Initiation Protocol (SIP), as described by Request for Comments (RFC) 3261 , entitled "SIP: Session Initiation Protocol," dated June 2002. In other examples, the call request 108 can be according to other different protocols. A "call request" can refer to a message, information field, or other indication sent from a first entity to a second entity to indicate that establishment of a

communications session is requested by the first entity with the second entity. Note that the call request can be routed through an intermediary network device (or multiple intermediary network devices).

[0017] The call request 108 is received by a call control engine 1 10 in the called user terminal 104 for processing. The call control engines 106 and 1 10 in the caller and called user terminals 102 and 104, respectively, are used to exchange

messages, information fields, or other indications according to a specified protocol for the purpose of establishing a communications session between the user terminals 102 and 104 through the network 106.

[0018] In some examples, the call control engine 1 10 includes an authorization code verifier 1 12, which is used for determining whether or not an authorization code is received from the calling user terminal 102 in association with the call request 108. Although the authorization code verifier 1 12 is depicted as being part of the control engine 1 10, in other examples, the authorization code verifier 1 12 can be separate from the call control engine 1 10, but can be invoked by the call control engine 1 10. The authorization code verifier 1 12 can include a hardware processing circuit or a combination of machine-readable instructions executable on the hardware

processing circuit.

[0019] In accordance with some implementations, in response to the call request 108, the authorization code verifier 1 12 sends a request 1 14 for an authorization code over the network 106 to the calling user terminal. The authorization code request 1 14 can include a message, an information field, or other indication to indicate that an authorization code is sought for the purpose of determining whether or not a call can be established in response to the call request 108.

[0020] In further examples of the present disclosure, the call control engine 1 10 can include a setting or a policy that can govern whether or not the authorization code verifier 1 12 is to send a request for an authorization code in response to a call request. For example, an authorization code setting of the call control engine 1 10 can include an on/off setting, where the authorization code setting if set to an "on" value would cause the authorization code verifier 1 12 is to send a request for an authorization code in response to a call request. However, the authorization code setting if set to an "off" value would cause the authorization code verifier 1 12 (or the call control engine 1 10) to allow all call requests without first seeking an

authorization code. In some examples, if the authorization code setting is set to the "off" value, then the authorization code verifier 1 12 (or the call control engine 1 10) can send a message to the calling user terminal 102 indicating that no authorization code is requested. In other examples, the call control engine 1 10 can simply pass the call request through without sending any message regarding an authorization code to the calling user terminal 102.

[0021 ] In yet further examples, the call control engine 1 10 can include a policy that governs when the authorization code verifier 1 12 is to request an authorization code in response to a call request. For example, the policy can be a location-based policy where the authorization code verifier 1 12 requests an authorization code in response to a call request if the called user terminal 104 is located at a first geographic location (e.g. at a work location), and the authorization code verifier 1 12 is to not request an authorization code in response to a call request if the called user terminal 104 is located at a second, different geographic location (e.g. at home). In other examples, the policy can be a time-based or calendar-based policy that controls whether or not the authorization code verifier 1 12 is to request an

authorization code in response to a call request depending upon a time of the call request. In yet further examples, the policy can specify another criterion or other criteria that govern whether or not the authorization code verifier 1 12 is to request an authorization code in response to a call request.

[0022] More generally, the call control engine 1 10 is associated with information (in the form of a setting or policy) that controls whether or not the call control engine 1 10 and/or the authorization code verifier 1 12 requests an authorization code in response to a call request.

[0023] The call control engine 106 of the calling user terminal 102 includes an authorization code handler 1 16 that is able to process the authorization code request 1 14 received from the called user terminal 104. The authorization code handler 1 16 can be part of the call control engine 106, or alternatively, can be separate from the call control engine 106. The authorization code handler 1 16 can be implemented with a hardware processing circuit or a combination of machine-readable instructions executable on a hardware processing circuit.

[0024] The authorization code handler 1 16 responds to the authorization code request 1 14 in one of several possible ways. In some examples, the authorization code handler 1 16 can cause a prompt 1 18 to be presented in a user interface (Ul) 120 of the calling user terminal 102. The Ul 120 can be displayed by a display device of the calling user terminal 102. The prompt 1 18 can be in the form of a graphical user interface (GUI) element (e.g. an icon, a dialog box, etc.) that presents information that asks the user of the calling user terminal 102 to manually enter the authorization code, such as into a GUI text box or other entry field.

[0025] In other examples, instead of presenting the prompt 1 18 in the Ul 120 to seek manual entry by the user of the authorization code, the authorization code handler 1 16 can retrieve the authorization code from an authorization code repository 122. In some examples, the authorization code repository 122 can include a contact list created by or for the user of the calling user terminal 102. A contact list refers generally to a data structure that contains contact information for respective users. An example of a contact list is an address book. The contact list can include multiple entries for respective different users, where each entry of the contact list can include any or some combination of the following information: a phone number, an e-mail address, or any other type of information that can be used to contact a respective user. In some examples, different authorization codes can be stored in respective entries of the contact list that store corresponding contact information of different users in the contact list. [0026] The authorization code handler 1 16, after receiving the authorization code (either manually entered by the user in the Ul 120 or retrieved from the authorization code repository 122) sends, over the network 106, the authorization code 124 to the called user terminal 104. In response to receiving the authorization code 124 from the calling user terminal 102, the authorization code verifier 1 12 compares the received authorization code 124 against an authorization code previously stored for the user associated with the calling user terminal 102. If the authorization codes match, the authorization code verifier 1 12 provides an indication of the match to the call control engine 1 10, which can then cause activation of an alert device 126 at the called user terminal 104. The alert device 126 can include any or some combination of the following: an audible ringer that produces an audible ring, a display element that displays a visual alert, and a vibrator to cause vibration of the called user terminal 104.

[0027] However, if the authorization code verifier 1 12 determines that a matching authorization code has not been received (either an authorization code has not been received from the calling user terminal 102 within a predefined time interval, which can be specified by a timeout timer, or the received authorization code 124 does not match the stored authorization code at the called user terminal), then the

authorization code verifier 1 12 provides an indication of an authorization code failure to the call control engine 1 10. In response, the call control engine 1 10 declines to activate the alert device 126, which means that the user of the called user terminal 104 is not provided with any alert of the call request 108, which effectively blocks the incoming call from the perspective of the user of the called user terminal 104. The call control engine 1 10 of the called user terminal 104 can also send a message to the calling user terminal 102 to indicate either a received authorization code did not match, or no authorization code was received within the time interval of the timeout timer.

[0028] In further examples, a policy can also be provided that specifies that the authorization code verifier 1 12 is to send out a specified number (one or greater than one) of authorization code requests (1 14) to the calling user terminal 102 in response to an authorization code non-match or timeout. This can provide an opportunity for the user of the calling user terminal 102 to re-enter the authorization code (in case of mis-entry), or for the calling user terminal 102 to resend the authorization code (in case of a communication failure that caused a previously sent authorization code from failing to reach the called user terminal 104).

[0029] In some examples, the authorization code request 1 14 can be sent by the called user terminal 104 to the caller user terminal 102 without user interactive input at the called user terminal 104. In fact, in some examples, the user of the called user terminal 104 may not even be aware that the called user terminal 104 has sent the authorization code request 1 14 to the calling user terminal 102 in response to the call request 108. For that matter, the user of the called user terminal 104 is not even aware of receipt of the call request 108, until after the authorization code handshake (including the authorization code request 1 14 and the authorization code 124) has successfully completed.

[0030] In some examples, the authorization code handshake that includes the authorization code request 1 14 and the authorization code 124 transmission can be according to a specified protocol. For example, the specified protocol can be a new protocol that does not presently exist but which can be defined. In other examples, existing communication protocols can be modified to support the authorization code handshake.

[0031 ] Fig. 2 is a flow diagram of an example process that can be performed by the called user terminal 104 according to some implementations. The call control engine 1 10 of the called user terminal receives (at 202), from the calling user terminal 102, a call request (e.g. 108 in Fig. 1 ). In response to the call request, the authorization code verifier 1 12 sends (at 204), to the calling user terminal 102, a request for an authorization code (e.g. 1 14 in Fig. 1 ). The authorization code verifier 1 12 determines (at 206) whether a matching authorization code is received from the calling user terminal 102 in response to the request for an authorization code. In response to determining that a matching authorization code has not been received from the calling user terminal 102, the call control engine 1 10 declines (at 208) to provide an alert of the call request at the called user terminal 104. In some examples, the call control engine 1 10 declines to activate the alert device 126 (Fig. 1 ) of the called user terminal 104 in response to determining that a matching authorization code has not been received from the calling user terminal 102.

[0032] An authorization code can be assigned according to one of a number of different ways, including, as examples, using a multi-party technique or a single- party technique.

[0033] With the multi-party technique, a given authorization code can be associated with a group of multiple callers. The given authorization code that is associated with the group of multiple callers can be communicated to each caller of the group of multiple callers. Different groups of callers can be associated with respective different authorization codes. For example, the given authorization code can be assigned to family members of a callee, or to a different group of callers. This authorization code can be a group-based authorization code that is not tied to any specific individual. Because members of the group are trusted, this

authorization code would be unlikely to have to be revoked since members of the group are unlikely to share the authorization code with members outside the group.

[0034] With the single-party technique, a unique authorization code can be provided on an individual basis. For example a callee may provide a first

authorization code to the callee's doctor, a second authorization code to the callee's dentist, and a third authorization code to the callee's work colleague. These codes may have to be more frequently revoked, such as when the callee changes doctors, changes dentists, or changes employers.

[0035] Authorization codes can be automatically generated, or can be manually generated. As examples of an auto-generation technique, a program (including machine-readable instructions) that manages a contact list at a first user terminal can generate any time a new contact entry is added to the contact list (or

alternatively, any time a contract entry is edited and an authorization code does not exist in the contact entry). For example, in response to adding a new contact entry (or alternatively, in response to editing of an existing contact entry) in the contact list, the program can provide a prompt to a first user of the first user terminal seeking user input regarding whether or not an authorization code is to be included as part of the contact information in the new or edited contact entry. If the first user accepts, then the generated authorization code is added to the new or edited contact entry. In other examples, the authorization code can be automatically generated and added to the new or edited contact entry without first prompting the first user whether adding such authorization code to the contact entry is desired by the first user. The auto-generated authorization code can then be provided by the first user to the contact (second user) if the first user wants to give the second user permission to call the first user. The providing of the auto-generated authorization code can be transmitted by the first user terminal to a second user terminal of the second user.

[0036] In other examples, an authorization code can be manually generated. For example, the first user at the first user terminal can manually create an authorization code that the first user manually enters into a corresponding contact entry of the contact list. The first user can then the manually generated code to the contact (second user) so that the second user can call the first user.

[0037] The auto-generated or manually generated authorization code provided by the first user to the second user can be stored by the second user into a respective contact entry including contact information of the first user in a contact list at the second user terminal of the second user. Alternatively, the auto-generated or manually generated authorization code provided by the first user to the second user can be memorized by the second user for entry by the second user in the future when the second user calls the first user.

[0038] Once an authorization code is generated (either automatically or manually) at the first user terminal, the authorization code can be either manually or automatically provided to the second user terminal. Manual provision involves the first user making a manual selection (such as in a Ul at the first user terminal) to cause the first user terminal to send the authorization code to the second user terminal. [0039] Automated provision involves the first user terminal automatically sending the authorization code to the second user terminal in response to generation of the authorization code.

[0040] In some specific examples, when the first user provides his or her phone number to the second user, the second user terminal can make a test call to the first user to ensure the correct phone number has been recorded. In response to this test call, a Ul can be presented at either or both of the user terminals of the first and second users, where the Ul can be used to enter an authorization code to be used by the first and second users to call each other. Also, in some examples, the Ul can also present options relating to restrictions on use of the authorization code.

Examples of restrictions include any or some combination of the following: a restriction on a number of uses of the authorization code, or a restriction on a time associated with the use of the authorization code.

[0041 ] In further examples, an authorization code is not associated with any specific restriction. Such an authorization code can be repeatedly used to call a target user. However, the target user can revoke the authorization code, by either changing the authorization code or removing the authorization code.

[0042] In other examples, an authorization code that is associated with a time restriction can be referred to as a "time-bound authorization code." A time-bound authorization code can be used only during a specified time interval (e.g. a date range, or a specific date or specific dates). As examples, a target user (a callee) can provide a time-bound authorization code to a contractor doing work at the target user's house, where the time-bound authorization code is allowed to be used for the time interval when the contractor is expected to perform work on the target user's house.

[0043] In yet further examples, an authorization code that is associated with a number of uses restriction can be referred to as a "use-bound authorization code." A use-bound authorization code can be used only a specified number (N) of times, where N = 1 , 2, ... . For example, a one-time use-bound authorization code can be provided to a package delivery company for use by the package delivery company to contact a user when delivering a package.

[0044] In further examples, a target user can set up a policy to automatically send any unauthorized call directly to voicemail, allowing the target user to later listen to a voicemail to see if it was indeed from someone the target user wants to accept calls from. If so, then the target user can provide an authorization code to the caller. In other examples, the unauthorized call can be routed, based on the rule, to another type of an alternate destination, such as an e-mail or text message that can be sent to the target user with the information of the caller that make the

unauthorized call, to give the target user an opportunity to determine whether or not the caller is someone who the target user wishes to continue to block.

[0045] In some implementations, a target user is in control of whether and when the target user wants to add or remove authorization for any particular person in their contact list. To revoke a person's authorization, the target user can simply delete the authorization code from the person's information in the contact list.

[0046] Fig. 3 is a block diagram of the calling user terminal 102 according to further implementations. The calling user terminal 102 includes a non-transitory machine-readable or computer-readable storage medium 302 and a processor (or multiple processors) 304. A processor can include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.

[0047] The storage medium 302 is to store, in a contact list 306, an authorization code 308 and contact information 310 of a target user. The authorization code 308 and the contact information 310 of the target user can be stored in a contact entry 312 of the contact list 306. The contact list 306 can include multiple contact entries that contain respective contact information for corresponding users. Note that not all of the contact entries would include an authorization code. The authorization code 308 is included in the contact entry 312 with the contact information 310 of the target user because the target user has requested that an authorization code be provided when calling the target user.

[0048] The processor(s) 304 is to execute various machine-readable instructions to perform respective tasks. Examples of such machine-readable instructions that can be executed by the processor(s) 304 include call request sending instructions 314 to cause sending of a call request to a called user terminal associated with the target user, authorization code retrieving instructions 316 to retrieve, from the contact list 306, the authorization code 308 for establishing a call for the call request, and authorization code sending instructions 318 to cause sending of the

authorization code to the called user terminal associated with the target user as part of a call setup for the call request.

[0049] Fig. 4 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 400 that stores instructions that upon execution cause a first user terminal (of a first user) to perform respective tasks. The machine- readable instructions include authorization code adding instructions 402 to add an authorization code associated with a second user that has a second user terminal to a contact list at the first user terminal. The authorization code may have been manually generated by the first user or automatically generated when a contact entry was created or edited. The machine-readable instructions further include

authorization code sending instructions 404 that cause the sending of the

authorization code to the second user terminal. The machine-readable instructions further include call request receiving instructions 406 to receive, from the second user terminal, a call request. Authorization code request instructions 408 are to, in response to the call request, cause sending the request for the authorization code to the second user terminal. Authorization code determining instructions 410 are to determine whether a matching authorization code is received from the second user terminal. Alert declining instructions 412 are to decline to activate an alert for the call request in response to determining that the matching authorization code has not been received from the second user terminal. [0050] The storage medium 302 (Fig. 3) or 400 (Fig. 4) can include one or multiple different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and

programmable read-only memories (EEPROMs) and flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic media including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple

components. The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.

[0051 ] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.

Claims

What is claimed is: 1 . A method performed by a called user terminal, comprising:

receiving, from a calling user terminal, a call request;

in response to the call request, sending, to the calling user terminal, a request for an authorization code;

determining whether a matching authorization code is received from the calling user terminal; and

in response to determining that the matching authorization code has not been received from the calling user terminal, declining to provide an alert of the call request at the called user terminal.

2. The method of claim 1 , further comprising:

in response to determining that the matching authorization code is received from the calling user terminal, providing the alert at the called user terminal.

3. The method of claim 2, wherein providing the alert is selected from among activating an audible alert, activating a visual alert, causing vibration of the called user terminal, or a combination thereof.

4. The method of claim 2, further comprising receiving the matching

authorization code manually entered by a user at the calling user terminal in response to a prompt generated responsive to the request for an authorization code.

5. The method of claim 2, further comprising receiving the matching

authorization code automatically retrieved by the calling user terminal from a contact list at the calling user terminal in response to the request for the authorization code.

6. The method of claim 1 , further comprising:

sending, to the calling user terminal, the authorization code that is uniquely associated with a user of the calling user terminal or that is uniquely associated with a group of users allowed to call the called user terminal.

7. The method of claim 1 , further comprising setting up the authorization code for restricted use based on one or both of a time restriction and a number of uses restriction.

8. The method of claim 1 , further comprising:

providing information that controls whether the called user terminal is to send the request for the authorization code in response to the call request, the information comprising one of a setting or a policy.

9. A first user terminal comprising:

a storage medium to store, in a contact list including contact information for a plurality of users, an authorization code with contact information of a target user; and at least one processor to:

cause sending of a call request to a second user terminal associated with the target user;

retrieve, from the contact list, the authorization code; and cause sending of the authorization code to the second user terminal as part of a call setup for the call request.

10. The first user terminal of claim 9, wherein the at least one processor is to receive the authorization code from the second user terminal, the authorization code automatically generated at the second user terminal or manually entered at the second user terminal in response to entering contact information of a user of the first user terminal into the contact list at the second user terminal.

1 1 . The first user terminal of claim 9, wherein the at least one processor is to: in response to adding the contact information of the target user to the contact list, cause a test call to be made to the second user terminal; and

present a user interface at the first user terminal responsive to the test call to receive information regarding the authorization code to set up.

12. The first user terminal of claim 9, wherein the at least one processor is to cause sending of the authorization code to the second user terminal in response to a request for the authorization code received from the second user terminal.

13. A non-transitory storage medium storing instructions that upon execution cause a first user terminal to:

add an authorization code associated with a user of a second user terminal to a contact list;

cause sending of the authorization code to the second user terminal;

receive, from the second user terminal, a call request;

in response to the call request, send, to the second user terminal, a request for the authorization code;

determine whether a matching authorization code is received from the second user terminal; and

in response to determining that the matching authorization code has not been received from the second user terminal, declining to activate an alert for the call request.

14. The non-transitory storage medium of claim 13, wherein the instructions upon execution cause the first user terminal to automatically generate the authorization code in response to adding contact information of the user of the second terminal to the contact list.

15. The non-transitory storage medium of claim 13, wherein the instructions upon execution cause the first user terminal to, in response to determining that the matching authorization code has not been received from the second user terminal, perform at least one task selected from among:

sending a message indicating that the matching authorization code has not been received from the second user terminal;

sending another request for the authorization code; and

routing the call request to an alternate destination associated with a user of the first user terminal.