FR2956548A1 - Outgoing call controlling method for e.g. global system for mobile communications type mobile telephone, involves requesting validation of outgoing call if obtained identifier is present in identifiers - Google Patents

Abstract

The method involves storing a set of identifiers (205) comprising an identifier received in a database. An outgoing call is detected (215), and an identifier of a called device directed by the outgoing call is obtained (220). The obtained identifier is compared (225) with the identifier of the set of identifiers, to determine if the obtained identifier is present in the set of identifiers. The validation of the outgoing call is requested (235) in response to the comparison step, if the obtained identifier is present in the identifiers. Independent claims are also included for the following: (1) a computer program comprising a set of instructions for performing a outgoing call controlling method (2) a telephone comprising a unit to control outgoing call in response to incoming call or received message, and a subscriber identity module (SIM) type card.

Description

The present invention relates to call control in telephones and more particularly to a method and an apparatus for controlling outgoing calls, in response to incoming calls, in particular in mobile telephones. The identification of incoming calls in a telephone allows its user to take a call or not depending on the identity of the caller and the context of the call. For example, a user may decide not to take a family member's call while in a meeting but to take calls from colleagues. Conversely, in the evening, this user can decide to take calls from family members but reject calls from colleagues. For these purposes, when an incoming call is detected, the called phone displays the caller's phone number, unless the caller wishes to hide his identity, or his name if a phone database associates the name with the number of the caller. calling phone.

Some phones are also provided with filters for filtering incoming and / or outgoing calls so that only calls not received from or transmitted to interlocutors identified in a database stored in the phone are rejected. Such an embodiment example is described in particular in the patent application WO 2009/098289.

In addition, the telephones generally include a memory in which are memorized all the identities of the calling and called parties. A software application provides access to these identifiers that can be displayed as a log. In addition, some phones automatically display the list of caller IDs when no action has been taken in response to corresponding incoming calls. Thus, when a user activates their phone, a list, usually called "missed calls", is automatically displayed to give the phone numbers or names of people who have tried to reach the phone user. This user can then call back these people. According to some studies, a large proportion of users call back the numbers in the list of "missed calls" without first searching for the identity of the callers. Taking advantage of this phenomenon of "blind" recall, some malicious people have recently developed a scam known as "ping cal /". This consists of calling a large number of numbers from a server and with a highly surcharged number, and to hang up before the user or his answering machine answers so as not to pay the cost of the call. A large number of so called users call the number calling them, heavily surcharged, using the callback function of the phone. These users then fall on a voicemail and pay the premium rate of the call.

The same phenomenon exists with text messages of the SMS type (short message service acronym in English terminology) including an invitation to call a number indicated under a false pretext. There is therefore a need to control outgoing calls from telephones, sent in response to incoming calls or messages received.

The invention solves at least one of the problems discussed above. The invention thus relates to a method for controlling outgoing calls in response to incoming calls or received messages, the method being implemented in a telephone comprising means for storing device identifiers that can be called by said telephone, means for obtaining an identifier of a device called by said telephone and means for rejecting an outgoing call, this method comprising the following steps, - storing at least one list of identifiers comprising at least one identifier previously received in said storage means; - detection of an outgoing call; obtaining an identifier of a called device targeted by said outgoing call; comparing said identifier obtained with at least one identifier of said at least one list of identifiers to determine if said obtained identifier is present in said at least one list of identifiers; and, in response to said comparison step, if said obtained identifier is present in said at least one list of identifiers, request for validation of said outgoing call. The method according to the invention thus makes it possible to warn a user of the risks generated by outgoing calls to previously identified devices, in particular financial risks related to overcharging of the outgoing call. Thus, the user can make outgoing calls if he wishes but can not pass them inadvertently. According to a particular embodiment, the method further comprises a step of displaying a request message for validation of said outgoing call. The user is thus visually informed of the risk associated with the outgoing call and may, in response to this message, validate or not the outgoing call. For these purposes, the method preferably comprises a step of receiving a validation command, said outgoing call being sent in response to said validation command. Thus, an outgoing call presenting a risk for the user of the phone can only be passed after confirmation of the user, that is to say only intentionally. Advantageously, said outgoing call is issued only if said validation command is received within a predetermined time in order to avoid a fault of inattention of the user. According to a particular embodiment, the method further comprises a second step of detecting a second outgoing call, said outgoing call being called the first outgoing call, said second outgoing call being issued if the identifier of a called device referred to by said second outgoing call is similar to the identifier of a called device targeted by said first outgoing call. The method according to the invention can thus be implemented in telephones that do not have advanced functionalities, the invention being particularly simple to implement. Advantageously, said second outgoing call is sent only if said second outgoing call is detected within a predetermined time in order to avoid a fault of inattention of the user. Still according to a particular embodiment, said at least one list of identifiers comprises at least one rule defining a group of identifiers, said step of comparing said identifier obtained with at least one identifier of said at least one list of identifiers comprising a step of comparing said identifier obtained with said at least one rule to determine if said identifier obtained belongs to said group of identifiers.

It is thus not necessary to establish an exhaustive list of all the identifiers of the called devices may present a risk for the user, some identifiers can be grouped and defined by simple rules. The invention also relates to a computer program comprising instructions adapted to the implementation of each of the steps of the method described above when said program is executed in a microcontroller or a microprocessor. The invention also relates to a SIM-type card comprising storage means, said storage means comprising the computer program described above and calculation means adapted to implement said computer program. Advantageously, said storage means stores said at least one list of identifiers so that all the elements necessary for the implementation of the invention are included in the card. The invention also relates to a device comprising means 25 adapted to the implementation of each of the steps of the method described above and a telephone comprising this device. The benefits provided by this computer program, this SIM card, this device and this phone are similar to those mentioned above. Other advantages, objects and features of the present invention will become apparent from the following detailed description, given by way of non-limiting example, with reference to the appended drawings, in which: FIG. 1 schematically represents a telephone comprising a data card; SIM type identification enabling the implementation of the invention; FIG. 2 illustrates certain steps of an exemplary algorithm implemented in a mobile telephone for controlling the outgoing calls of a telephone according to the invention; and, - Figures 3 and 4 illustrate certain steps of a first and a second exemplary call validation algorithm when an outgoing call is identified as suspect.

In general, the invention makes it possible to control the outgoing calls in a telephone by comparing the identifier of the called device with a list of previously received identifiers so that the outgoing calls whose identifier of the called device appear in the list. are rejected if they are not validated. The list of identifiers may be received from an operator or a third party. These identifiers can be complete or partial. These can include phone numbers or partial phone numbers, for example, numbers beginning with predetermined numbers. The list of identifiers thus contains identifiers of the called devices for which the outgoing calls must be abandoned if they are not validated. These identifiers are, for example, the telephone numbers of the called devices, called phone number roots such as, in France, the numbers starting with 0899, 0897 or 0892, or more generally rules on telephone numbers such as rules "all numbers beginning with 089", "all numbers ending in 1512", "all numbers containing 123" or combinations of rules such as "all numbers beginning with 089 and ending with 1512". The list of identifiers can also be managed locally by adding identifiers received in incoming calls or in received text messages. The user can also manually enter or delete identifiers.

According to a particular embodiment, the invention is implemented in a mobile phone type GSM (acronym for Global System for Mobile Communications in English terminology), type UMTS (acronym of Universal Mobile Telecommunications System in English terminology - Saxon) or CDMA type (acronym for Code Division Multiple Access in English terminology), for example in a microcircuit card identification with a mobile phone network or a subscription card to a mobile network (Subscription card or prepaid card) such as a SIM card type (acronym for Subscriber Identity Module in English terminology) or a UICC type card (acronym for Universal Integrated Circuit Card in English terminology). Such a card, called SIM type card in the following description, generally contains a microcontroller and memory, typically ROM type memory (acronym for Read Only Memory in English terminology) or EEPROM (acronym for Electrically). -Erasable Programmable Read-Only Memory in English terminology). It is used to store information specific to the subscriber and the operator of a mobile network. It also stores applications of the user, his operator or in some cases third parties.

FIG. 1 illustrates an exemplary architecture of a mobile phone comprising a SIM-type card adapted to implement the invention. As illustrated, the mobile phone 100 comprises a mobile telephone module 105, advantageously connected to a loudspeaker 110 and to a microphone 115. The mobile phone 100 also comprises a central processing unit 120, also called CPU (acronym for Central Processing Unit in English terminology), a memory 125 and, preferably, a screen 130 and a user interface 135 such as a keyboard or a touch device can notably be integrated in the screen 130. The user interface 135 allows in particular to enter digits of a telephone number to dial, to select an identifier of a previously stored interlocutor to make a call to it and more generally to navigate in menus of the operating system and applications implemented in the mobile phone 100. The mobile phone 100 also includes a card reader 140. The central processing unit 120 is con connected to the telephony module 105, the memory 125, the screen 130, the user interface 135 and the card reader 140 to implement the functions generally offered by mobile phones. A SIM card 145 is here connected to the card reader 140 of the mobile telephone 100. The SIM card 145 comprises a microcontroller 150 and a memory 155, for example a ROM type memory and / or EEPROM type. The microcontroller 150 and the memory 155 are typically connected to each other and to the card reader in which the SIM card is inserted. According to a particular embodiment, the memory 155 of the SIM type card is used to store the application implementing the invention and the list of identifiers corresponding to devices for which the outgoing calls must be abandoned if they are not validated by the user. Alternatively, the application implementing the invention is implemented in the SIM card type 145 while the list of identifiers is stored in the memory 125 of the mobile phone 100. Alternatively still, the application implementing the The invention is implemented in the central processing unit 120 of the mobile telephone 100 while the list of identifiers is stored in the memory 125 of the mobile telephone 100 or in the memory 155 of the SIM card 145.

FIG. 2 illustrates certain steps of an exemplary algorithm implemented in a mobile telephone for controlling the outgoing calls of a telephone according to the invention. A first step (step 200) here is to receive a list of identifiers, for example phone numbers, corresponding to devices to which outgoing calls must be validated. The list of received identifiers may also consist of an update list of identifiers previously stored in the mobile phone. This list is stored in a database 205 stored in a memory of the mobile phone or in a memory of a card, for example a SIM-type card, inserted in the mobile phone. The list of identifiers is here received from a third party, for example from the mobile telephone operator.

It represents identifiers of "dubious" devices, that is to say devices that may result in hidden costs or nuisances to the user of the mobile phone. Step 200 is, for example, performed on the order of the third party providing the list of identifiers, on order of the user of the mobile phone, for example following the receipt of a message the information of the existence of this list or the existence of an update of this list, or periodically, for example every week or every month. The list of identifiers can also be loaded into the SIM card used during the personalization of the card. As previously described, the list of identifiers may also include rules defining sets of identifiers. An optional next step (step 210) allows the user of the mobile phone to manage the list of identifiers stored in the database 205 to, in particular, add or delete identifiers. This step can be performed manually by the user or automatically. It may be, for example, to systematically add all identifiers of calls received and remained unanswered and which do not correspond to any identifier in a directory of the mobile phone. When detecting an outgoing call (step 215), the identifier of the called device is obtained (step 220). Obtaining this identifier can in particular be performed using existing functions in the mobile phone as described below. The identifier of the called device is then compared (step 225) with the list of identifiers previously received and stored in the database 205. It can act as a simple comparison of the identifier of the called device with identifiers of the list of identifiers and / or the comparison of the identifier of the called device with one or more rules of the list of identifiers to determine whether the identifier of the called device verifies rules or not, that is to say say to determine if the identifier is included in a group of identifiers defined by a rule. A test (step 230) is then performed to determine whether the identifier of the called device is in the list of previously stored identifiers.

If so, a validation request is issued (step 235) to allow the user to confirm the call despite the presence of the identifier of the called device in the list of previously stored identifiers. A test is then performed to determine whether or not the user confirms the outgoing call (step 240). Examples of implementations of these outgoing call validation request steps are described with reference to Figures 3 and 4 described below. If the outgoing call is not validated, i.e. if the mobile phone user does not confirm his intention to call the identified device, the outgoing call is aborted (step 245). A message may be displayed to warn the user of the abandonment of the outgoing call. On the contrary, if the outgoing call is validated by the user (step 240) or if the identifier of the called device does not appear in the list of stored identifiers (step 230), the outgoing call is processed in a conventional manner ( step 250). Typically, in this case, the telephone number corresponding to the identifier is dialed. As suggested by the dashed arrows, the algorithm illustrated in Figure 2 is repeated to receive lists of identifiers considered "questionable", updates of such lists and to handle all outgoing calls.

Figure 3 illustrates some steps of a first example of a call validation algorithm when an outgoing call is identified as suspect. The algorithm illustrated here is, for example, called after step 230 shown in FIG. 2 when the identifier of the called device belongs to the list of identifiers stored in database 205.

A first step (step 300) is to display a warning message to the user, inviting him to confirm his choice regarding the outgoing call. Such a message is, for example, the message "Warning, the number called can generate significant communication costs. Do you want to confirm this call? ". This message is typically displayed on the screen 130 of the telephone 100 illustrated in FIG. 1. In response, the user uses the human-machine interface at his disposal, for example a keyboard or a touch interface, to confirm the call. outgoing or cancel it. The validation key corresponds, for example, to the "OK" key of the telephone while the cancel key corresponds to the "hang up" key. It can also be contextual key. If the user validates (step 305) the outgoing call, the latter is transmitted (step 310), that is to say that the telephone number corresponding to the identifier is dialed. Otherwise, if the user cancels the outgoing call, it is abandoned (step 315). A message may be displayed to warn the user of the abandonment of the outgoing call. Advantageously, a countdown is implemented to avoid erroneous manipulation. Thus, when the validation message is displayed (step 300), a counter is triggered after having been reset (step 320). A test is performed to compare the value of this counter with a predetermined value (step 325). As soon as the counter value is equal to the predetermined value, i.e. as soon as the predetermined time has elapsed, the outgoing call is abandoned (step 315). Thus, if the user has not confirmed the outgoing call in a given time, this call is abandoned. It is observed here that if, according to the algorithm shown in FIG. 3, the predetermined delay is initialized during the display of the validation message, it can also be initialized to the detection of the outgoing call at the origin the validation algorithm or at any other time related to this outgoing call. Figure 4 illustrates some steps of a second example of a call validation algorithm when an outgoing call is identified as suspect. The algorithm illustrated here is, for example, called following step 230 shown in FIG. 2 when the identifier of the called device belongs to the list of identifiers stored in the database 205. It can notably be used when the telephone implementing the invention does not validate an outgoing call, that is to say only allows to abandon, if necessary, an outgoing call. A first step (step 400) is to display a warning message to the user inviting him to renew the outgoing call if he confirms. Such a message is, for example, the message "Warning, the number called can generate significant communication costs. If you wish to confirm this call, please renew it within 20 seconds. This message is typically displayed on the screen 130 of the telephone 100 illustrated in FIG.

The called telephone number or the identifier of the called device is memorized temporarily (step 405), for example in a variable called temporary identifier. If a data was stored in this variable, it is replaced by the value of the identifier associated with the outgoing call.

The outgoing call is here abandoned. The user must renew his call within a specified time if he wants to confirm it. Following the invitation message to repeat the outgoing call (step 400) and abandoning it, the next outgoing call is detected (step 410) and the called telephone number or the identifier of the called device. is obtained (step 415). It is observed here that steps 410 and 415 are similar to steps 215 and 220 described above. The identifier associated with the outgoing call is then compared with the identifier stored previously (step 420), stored here in the temporary identifier variable. If the identifier associated with the outgoing call is identical to that previously stored, the outgoing call is processed in a standard manner (step 425). Typically, the phone number corresponding to the identifier is dialed. If, instead, the identifier associated with the outgoing call is not identical to that previously stored, steps similar to those described with reference to steps 230 to 250 are performed to determine whether the outgoing call is to be processed or be confirmed by the user according to the steps previously described (steps 400 to 425).

Advantageously, a countdown is implemented to avoid erroneous manipulation. Thus, when the message inviting the user to renew his call is displayed (step 400), a counter is triggered after being reset (step 430). A test is performed to compare the value of this counter with a predetermined value (step 435). As soon as the value of the counter is equal to the predetermined value, that is to say as soon as the predetermined time has elapsed, the algorithm described with reference to FIG. 4 ends. Thus, if the user has not confirmed the outgoing call in a given time, this call can no longer be confirmed by the renewal of the call, the renewal of the call must then be confirmed to be treated. In other words, if the user has not renewed his call within the allotted time, the call is considered abandoned. It is observed here that if, in accordance with the algorithm represented in FIG. 4, the predetermined delay is initialized during the display of the message inviting the user to repeat his call, he can also be initialized to the detection of the outgoing call at the origin of the validation algorithm or at any other time related to this outgoing call. The invention can be implemented in the form of a Java Card applet (Java Card is a trademark), that is to say an application using the features of a Java virtual machine (Java is a trademark ), in a SIM card. This applet is stored in memory, for example in ROM or EEPROM memory SIM card type. It is observed here that Java Card technology offers a secure execution environment for applications running on microcircuit cards with limited resources. Java Card applets can be installed during the production of the microcircuit cards in which they are executed or later. Advantageously, the Java Card applet is based on mechanisms of the toolbox known as the SIM Application Toolkit (SAT). The latter consists of a set of pre-programmed commands in the SIM-type card that define how the card interacts with the outside world and makes it possible to initiate commands independently of the mobile phone and the network. It allows interactive exchanges between an application, a user and a network access. In particular, the Java Card applet embodying the invention uses here the mechanism called CALL CONTROL of the SAT (according to the GSM standard) according to which a service table stored in the memory of the SIM-type card, for example contained in the EF SST file according to the GSM standard, indicates which functionalities are activated in the SIM card. If this file indicates that the CALL CONTROL is activated, the phone systematically submits to the SIM card each called number as soon as a call is initiated by the user. This is achieved by an APDU (Application Protocol Data Unit) command known as ENVELOPE (CALL CONTROL), the ENVELOPE command for sending data to the card. It is recalled here that APDU is defined in ISO / IEC 7816 to allow communication between a microcircuit card and a reader of such a card. APDU messages, whose structure is defined in ISO / IEC 7816, can be commands or responses, the commands being issued by the reader and the responses being issued by the microcircuit cards.

Furthermore, the applet implementing the invention is here declared as being triggered by the event ENVELOPE (CALL CONTROL). Thus, an applet being, according to the Java Card technology, declared as being triggered by an event, the applet implementing the invention receives all the numbers that the user is trying to call.

Using the CALL CONTROL mechanism, the SIM type card responds to the APDU ENVELOPE command by indicating that it accepts the call, that it refuses the call, or by indicating another number to be used for the call. According to a particular embodiment, the applet implementing the invention contains the exclusion data, that is to say the identifiers of the called devices for which the outgoing calls must be abandoned. This exclusion data is, for example, the telephone numbers of the called devices, called phone number roots such as, in France, the numbers starting with 0899, 0897 or 0892, or more generally rules on numbers of telephone numbers. such as "all numbers starting with 089" and "all numbers ending with 1512".

These exclusion data can also be stored, in whole or in part, in a memory of the SIM-type card associated with the applet implementing the invention and read by this applet during its execution or in a memory of the phone accessible through this applet. The exclusion data is advantageously remotely updated via the mobile telephone network using a mechanism known as DATA DOWNLOAD TO SIM according to the GSM standard. When the user of a mobile phone interacts with the human-machine interface of the latter via, for example, a touch screen or a keyboard, to initiate a telephone call to a telephone device, the applet implementing the invention receives an identifier of the called device, for example a telephone number. This number is received from the mobile phone, more precisely from the SIM card reader, in an ENVELOPE (CALL CONTROL) command. The applet then checks whether the number received must be filtered or not according to the number and the exclusion data, that is to say whether the outgoing call is to be abandoned or not. If the number does not have to be filtered, the applet implementing the invention responds to the APDU ENVELOPE (CALL CONTROL) command in an APDU response message, indicating that it accepts the call. If, on the contrary, the number must be filtered, the applet implementing the invention responds to the command APDU ENVELOPE (CALL CONTROL) indicating on the phone that the call must be abandoned. It then commands the user to enter a confirmation, via the man-machine interface of the telephone, for example by sending to the phone a SAT GET INPUT command displaying for example a message "attention, this call is heavily surcharged, please confirm "and obtaining the user's response. If the user confirms the call, the applet sends a SAT SET UP CALL command to the mobile phone initiating the call to the number by the phone. Otherwise, the call is rejected. Alternatively, for phones that do not support the SAT SET UP CALL command, the applet sends a DISPLAY TEXT command to display the "attention, this call is heavily overtaxed, you have 20 seconds to call back this number" message. If within 20 seconds of the message being displayed, the applet receives the ENVELOPE (CALL CONTROL) command again with the same number, the applet responds to the phone indicating that it accepts the call although it act of a number to be filtered. It is noted here that while some mobile phones do not support the SET UP CALL command, most mobile phones support the DISPLAY TEXT or GET INPUT command. When the card and the phone are turned on, the applet can be informed if the phone supports the SET UP CALL command to determine whether this variant should be implemented or not. Naturally, to meet specific needs, a person skilled in the field of the invention may apply modifications in the foregoing description.

Claims (12)

REVENDICATIONS1. A method of controlling outgoing calls in response to incoming calls or received messages, the method being implemented in a telephone comprising means for storing identifiers of devices that can be called by said telephone, means for obtaining an identifier of a device called by said telephone and means for rejecting an outgoing call, said method being characterized in that it comprises the following steps, storing (200) at least one list of identifiers comprising at least one minus an identifier previously received in said storage means; - detecting (215) an outgoing call; obtaining (220) an identifier of a called device targeted by said outgoing call; - comparing (225) said identifier obtained with at least one identifier of said at least one list of identifiers to determine if said obtained identifier is present in said at least one list of identifiers; and, in response to said comparison step, if said obtained identifier is present in said at least one list of identifiers (230), request for validation (235) of said outgoing call. 2. Method according to the preceding claim further comprising a step of displaying (300, 400) a request message for validation of said outgoing call. The method of claim 1 or claim 2 further comprising a step of receiving (240) a commit command, said outgoing call being issued in response to said commit command. 4. Method according to the preceding claim, said outgoing call being issued if said validation command is received within a predetermined time. The method of claim 1 or claim 2 further comprising a second step of detecting (410) a second outgoing call, said outgoing call being called first outgoing call, said second outgoing call being issued (425) if the an identifier of a called device targeted by said second outgoing call is similar to the identifier of a called device targeted by said first outgoing call (420). 6. Method according to the preceding claim, said second outgoing call being sent if said second outgoing call is detected within a predetermined time. 7. Method according to any one of the preceding claims, wherein said at least one list of identifiers comprises at least one rule defining a group of identifiers, said step of comparing said identifier obtained with at least one identifier of said at least one list of identifiers comprising a step of comparing said identifier obtained with said at least one rule to determine if said obtained identifier belongs to said group of identifiers. 8. Computer program comprising instructions adapted to the implementation of each of the steps of the method according to any one of the preceding claims when said program is executed in a microcontroller or a microprocessor. 9. SIM type card comprising storage means, said storage means comprising the computer program according to the preceding claim and calculation means adapted to implement said computer program. 10. SIM type card according to the preceding claim wherein said storage means stores said at least one list of identifiers. 11. Device comprising means adapted to the implementation of each of the steps of the method according to any one of claims 1 to 7. Telephone comprising the device according to the preceding claim 5 or the SIM type card according to any one of claims 9 and 10.