A decision support method for a terminal user to accept or reject a communication, including the corresponding decision support system and computer program.

Abstract

The invention relates to a decision support method for a user (2) of a first terminal (20) receiving a communication request (Reqcom) from a second terminal (10), the user (1) of the second terminal (10) being unknown to the user of the first terminal (20). The method comprises determining a confidence score for the user of the second terminal (10) and a confidence gap, the confidence gap providing information on the reliability of the confidence score. The confidence score and the confidence gap are determined from a list comprising at least one user of a third terminal to whom the second terminal has already transmitted a communication request, the at least one user of the third terminal belonging to at least one user community. Figure for the abstract: Fig. 1

Description

Title of the invention: Method for assisting a user of a terminal in deciding whether or not to accept a communication, corresponding decision-making support system and computer program Technical field

[0001] The present invention relates to securing exchanges between communication terminals (for example mobile phone, tablet, computer, etc.) within a communication or transaction network, for example an IP network (for "Internet Protocol" in English), or USSD (for "Unstructured Supplementary Service Data" in English and additional service for unstructured data in French).

[0002] By "exchange" is meant any type of connection between users of communication terminals. In other words, the invention is applicable to all contexts implementing telecommunications or financial transactions, incoming or outgoing, for which it is possible to establish a social relationship between users. Such exchanges are for example: mobile payments, bank transfers, telecommunications such as calls, SMS (for "Short Message Service" in English), video conferences, etc. Technical background

[0003] The IP network supports a multitude of services and applications. Some telecommunications operators, in particular, use this network to support their various service offerings.

[0004] Indeed, many offers are based on the principle of connecting two users of terminals connected to the Internet in order to establish communication or a financial transaction between these users.

[0005] These services and applications allow exchanges to be established between users. These exchanges are opportunities for fraudsters to attempt to divert the exchanges in their favor by entering into contact with their targets, accidentally (for example by sending messages, making broad calls, etc.) or by pretending to be in a trusted relationship (for example during an attempt at targeted scams, misappropriation or identity theft, etc.).

[0006] Some users may also make a mistake and involuntarily initiate an exchange with an unwanted contact (for example, an input error or a fraudulent link). It is therefore important for the user's security to warn them if an exchange deemed risky is detected and to protect them by preventing, if necessary, such a connection.

[0007] Several solutions already exist to protect these users, with varying degrees of effectiveness. efficiency. The simplest is the use of "black" or "white" lists representing a set of identifiers (such as: telephone numbers, WhatsApp numbers, MSISDN (for "Mobile Station International Subscriber Directory Number" in English), IB AN (for "International Bank Account Number" in English), etc.) at risk, or trusted, allowing to quickly check the presence of an identifier on this list and to act accordingly. These lists exist but must be regularly updated, they are therefore not exhaustive.

[0008] For example, in the context of mobile payments, some fraudsters regularly change their telephone number, making it virtually impossible to maintain and disseminate an up-to-date "blacklist." Therefore, the use of such a list is often limited to clearly identified sources of fraud at the global or national level, for example, using the AML / CFT (Anti-Money Laundering / Countering the Financing of Terrorism) list system.These lists are managed at national or international level by companies, (inter)governmental or financial institutions (for example the intergovernmental body for the fight against money laundering and the financing of terrorism or FATF (for "Financial Action Task Force" in English) but also by the service operators themselves who seek to identify fraudulent users).

[0009] Setting up a trusted list or "white" list is an effective solution but with relatively limited use: it is generally based on the creation of a list of recurring contacts (for example from the address book or calls) or it is built locally after verification and validation of its content. These lists are often personal, relatively small in number of contacts (for example reduced to the user's contacts), non-exhaustive and relatively difficult to keep up to date.

[0010] More advanced systems for analyzing user behavior or habits can detect input errors but are ineffective, for example, when initiating a payment to an unknown recipient. They are, however, complementary to the solutions proposed previously.

[0011] Another solution known from the prior art proposes the implementation of a trust / risk indicator based on the evaluation of an inter-individual social distance during any transaction. This method is based on the implementation and exploitation of community detection algorithms taking into account the social and temporal dimensions of the exchanges.

[0012] One of the disadvantages of this method comes from the application of the calculation method Social distance is applied to a new user of the service. Their social profile on the transactional network is similar to that of an abusive user due to their lack of membership / integration into the social structure of the transactional graph extracted from community detection. Therefore, when this new user interacts with a contact, the contact may be identified and displayed as potentially abusive to the other user, because calculating social distance will be impossible (infinite distance) based on the service's exchange history (which is either nonexistent or sparse). This can be detrimental to both the initiator of the exchange (the legitimate new user) and the service operator.

[0013] The method proposed in the prior art thus has a limitation in that it can generate false positives with new users who, due to their lack of usage history, can be considered as potential abusive users, which can be detrimental both to the service operator and to the customers of this operator.

[0014] There is therefore a need for a technique to assist abusive users of a transactional system in their decision-making which is effective from the first communications without sharing personal data. Summary of the invention

[0015] An object of the invention is therefore a decision-making assistance method for a user of a first terminal receiving a communication request from a second terminal, the user of the second terminal being unknown to said user of the first terminal. The decision-making assistance method comprises determining a confidence score of the user of the second terminal and a confidence gap, said confidence gap providing information on a reliability of said confidence score, said confidence score and said confidence gap being determined from a list comprising at least one user of a third terminal to which the second terminal has already transmitted a communication request. The at least one user of the third terminal belongs to at least one community of users.

[0016] As with the exploitation of community detection, the system is based on the principle that a "legitimate" communication request preferably connects two individuals with quantifiable social proximity. Conversely, a communication request involving an interlocutor deemed unreliable must be identifiable through the analysis of a group structure: ephemeral links and groups, one-way relationships, low exchange frequencies, short lifespan, and an unstable structure, thus leading to the conclusion of an absence of social proximity.

[0017] Social proximity can be relational (a family member, a friend, a colleague...), of interest (a group, a club, commercial...), geographical (a (a merchant, a neighbor, etc.) but also a combination of these elements. Past and future communications strengthen or weaken the relationships / links between individuals in these user communities, which evolve over time and are therefore fundamental to building user communities of identifiable interest based on service data. The communities thus formed are generally larger, more comprehensive, and more stable over time than the various lists mentioned above, and are shared among all members of a community, rather than individual members.

[0018] The proposed method allows for the regularization of the user's status through their progressive integration into the network of user communities, which is strengthened by "normal" use of the service over time. The proposed system, again based on a calculation of social distance between individuals or a community detection method, allows for the qualification of each individual's use of the service and the production of a real-time and evolving trust indicator, which can then be used anonymously by the service operator.

[0019] In one embodiment, the list includes three users of three terminals respectively to which the second terminal has already transmitted a communication request.

[0020] In one embodiment, the determination of the confidence score and confidence gap includes a selection of at least one pair of users from said list.

[0021] In one embodiment, the determination of the confidence score includes, for each pair of users, a calculation of a minimum inter-community distance, said minimum inter-community distance being determined from community sets to which the users of said pair belong, said confidence score corresponding to an average of the minimum inter-community distances.

[0022] In one embodiment, if the users of a pair have a community in common, the minimum inter-community distance of said pair is zero.

[0023] In one embodiment, if the users of a pair do not have a community in common, the minimum inter-community distance of said pair is at least equal to 1.

[0024] In one embodiment, the confidence gap corresponds to a standard deviation of the minimum inter-community distances of the pairs.

[0025] In one embodiment, the confidence score corresponds to a cardinality of a union of user communities to which the three users in the list belong.

[0026] In one embodiment, the confidence gap corresponds to the confidence score minus an average of the cardinalities of the community unions of users to which the three users in the list belong.

[0027] Another object of the invention relates to a decision support system for a user of a first terminal receiving a communication request from a second terminal, the user of the second terminal being unknown to the user of the first terminal. The decision support system comprises a computing device and a communication database, said computing device and said communication database being capable of determining a confidence score for the user of the second terminal and a confidence gap, said confidence gap providing information on the reliability of said confidence score. The confidence score and the confidence gap are determined from a list comprising at least one user of a third terminal to whom the second terminal has already transmitted a communication request, the at least one user of the third terminal belonging to at least one user community.

[0028] In one embodiment, the calculation device is adapted to transmit the confidence score and confidence gap to the first terminal.

[0029] In one embodiment, the system includes an application server, said application server being capable of processing said confidence score and said confidence gap and sending the result of said processing to the first terminal.

[0030] Another object of the invention relates to a computer program comprising program code instructions for the execution of the steps of the decision support process according to the invention, when said program is executed by a processor.

[0031] Another object of the invention relates to a computer-readable recording medium on which is recorded a computer program comprising program code instructions for executing a decision support method according to the invention, when said program is executed by a processor. Description of the figures

[0032] Fig. 1 illustrates an example of a communication network implementing a decision support process according to the embodiments of the invention;

[0033] [Fig.2] illustrates an example of a terminal configured to issue a communication request in the communication network of [Fig.1];

[0034] [Fig.3] illustrates an example of a communication history between different users of the communication network of [Fig.1];

[0035] Fig. 4 represents a graph illustrating the communication history of Fig. 3;

[0036] Fig. 5 represents a table listing communities to which the different users of the communication network of Fig. 1 belong;

[0037] Figure 6 represents the graph of Figure 4 associated with the list of communities of the [Fig.5] ;

[0038] Fig. 7 represents a community graph obtained from an association of data from Fig. 6;

[0039] The [Fig.8] represents a minimum distance storage matrix between communities of the [Fig.7];

[0040] Fig.9 represents a table corresponding to the table in Fig.5, with additional columns;

[0041] Figure 10 illustrates an example of a terminal configured to receive a communication request via the communication network of Figure 1;

[0042] The [Fig. 11] represents the different stages of a decision support process according to a first embodiment of the invention;

[0043] Figure 12 represents the different stages of a decision support process according to a second embodiment of the invention;

[0044] Figure 13 illustrates in detail a decision support system used in the network of Figure 1.

[0045] Fig. 1 represents a communication network R for the exchange of data between a terminal 10 of a user 1 and a terminal 20 of a user 2.

[0046] The terminal 10 of user 1 is adapted to transmit a Reqcom communication request to the terminal 20 in order to establish communication with user 2. [Fig.2] details the structure of such a terminal 10.

[0047] Terminal 10 is here a smart terminal, or "smartphone," adapted for implementing software applications. Terminal 10 thus comprises an interface module 101 and a client-sender application. Interface module 101 allows user 1 to transmit a command to send a Reqcom communication request to terminal 20. Typically, interface module 101 is a keyboard on terminal 10. Alternatively, interface module 101 could be a voice command. The client-sender application is adapted to generate and transmit the Reqcom communication request to the communication network R based on the send command from interface module 101 of terminal 10.

[0048] As illustrated in [Fig. 1], the communication network R comprises a decision support system 30 and a monitoring device S. The decision support system 30 is capable of receiving a request to determine a confidence score Sconf associated with user 1 and a confidence gap Deltaconf. Such a request originates from the communication request Reqcom. The confidence score Sconf provides information on the level of trust to be placed in user 1. The confidence gap Deltaconf provides information on the reliability of said confidence score Sconf. In response to this request, the decision support system 30 is adapted to transmit to terminal 20 data Data associated with the determination of the score confidence and confidence gap Deltaconf.

[0049] Figure 13 illustrates in more detail the decision support system 30. This decision support system 30 comprises at least one processor PROC and at least one memory MEM. More particularly, the system 30 has, in one embodiment, the hardware architecture of a computer. The memory MEM constitutes an information storage medium according to the invention, that is to say, readable by the processor PROC and on which a computer program PROG according to the invention is stored. The program PROG contains instructions for carrying out steps of a process according to the invention when the program PROG is executed by the processor PROC. The program PROG defines, in particular, the functional modules of the system 30, which control its hardware components.

[0050] As illustrated in [Fig. 13], the system 30 includes a COM communication device configured to communicate with, in particular, the supervisory device S and the terminals 10 and 20 of [Fig. 1]. There are no limitations on the nature of the communication interfaces between these devices, which can implement any protocol known to those skilled in the art.

[0051] The decision support system 30 further comprises:

[0052] - a computing device 301;

[0053] - a communications base 302.

[0054] The computing device 301 is adapted to calculate the confidence score Sconf and the confidence gap Deltaconf from information stored in the communications database 302. More specifically, the communications database 302 stores a history H of communication requests between different user terminals on the communication network. Figure 3 illustrates an example of such a history between, for example, fifteen users 3i to 3i5, where the terminal(s) of each of these users can act as either the sender or receiver of a communication request. These users are respectively referenced in the history H by identifiers ID_3i to ID_315. In a particular embodiment not shown here, the identifier used is an MSISDN (Mobile Station International Subscriber Directory Number).When a communication request transmitted by a terminal of one of these users is accepted by a terminal of another of these users, a transaction is completed. The history H thus lists the completed transactions, called OK transactions, and the not completed transactions, called NOK transactions. In the example in [Fig. 3], all transactions between contact users 3i to 3i5 were completed.

[0055] History H also lists the communication requests that were transmitted by terminal 10 of user 1. User 1 is referenced by the identifier ID_1. No transactions are validated for this user 1, since he / she is not known to the different users 3i to 3i5. It is thus possible to establish a list h of users to whom user 1 has previously transmitted a communication request via his terminal 10.

[0056] Figure 4 represents a graph G illustrating the communication history of the [Fig. 3]. In this graph G, each user 3i to 3i5 represents a circular node. OK transactions between nodes are represented by solid lines.

[0057] From this [Fig.4], the following information can be deduced:

[0058] - a first user 3i has already carried out at least one transaction with a second user 32, a fourth user 34 and a fifth user 35;

[0059] - the second user 32 has already carried out at least one transaction with the first user reader 3i, the fifth user 35 and a sixth user 36;

[0060] - a third user 33 has already carried out at least one transaction with a fourth user 34, a seventh user 37 and an eighth user 38;

[0061] - the fourth user 34 has already carried out at least one transaction with the first user 3i, the third user 33 and the seventh user 37;

[0062] - the fifth user 35 has already carried out at least one transaction with the first user 3i, the second user 32, the sixth user 36, a twelfth user 3i2 and a fourteenth user 3W;

[0063] - the sixth user 36 has already carried out at least one transaction with the second user reader 32 and the fifth user 35;

[0064] - the seventh user 37 has already carried out at least one transaction with the third user 33, the fourth user 34, the eighth user 38 and the twelfth user 312;

[0065] - the eighth user 38 has already carried out at least one transaction with the third user 33, the seventh contact 37, a ninth user 39 and an eleventh user 3ii;

[0066] - the ninth user 39 has already carried out at least one transaction with the eighth user 38, a tenth user 3i0, the eleventh user 3n, the twelfth user 312, and a thirteenth user 3n;

[0067] - the tenth user 3i0 has already carried out at least one transaction with the ninth user 39 and the eleventh user 3n;

[0068] - the eleventh user 3n has already carried out at least one transaction with the eighth user 38, the ninth user 39 and the tenth user 3i0;

[0069] - the twelfth user 3[2 has already carried out at least one transaction with the fifth user 35, seventh user 37, ninth user 39, thirteenth user 3n, fourteenth user 3W and fifteenth user 3i5;

[0070] - the thirteenth user 3n has already carried out at least one transaction with the ninth user 39, twelfth user 3i2 and fifteenth user 3i5;

[0071] - the fourteenth 3W user has already carried out at least one transaction with the fifth user 35, twelfth user 3i2 and fifteenth user 3i5;

[0072] - the fifteenth user 3i5 has already carried out at least one transaction with the twelfth user 3[2, thirteenth user 3n and fourteenth user 3¼.

[0073] The dotted lines between user 1 and user 3b, user 34 and user 37 represent NOK transactions, i.e. communications which have not been accepted by the respective users 3b, 34, 37.

[0074] Figure 5 represents a table T listing, for each user 3i to 3i5, the community or communities to which they belong. Users belong to the same community because they share at least one common interest (members of the same family, colleagues in a company or group of companies, students in the same university circle, members of a sports federation, etc.) or relationships that lead them to communicate in various forms. This community thus constitutes a sphere of trust. A single user 3i to 3i5 can belong to several communities. The construction of these communities relies on a set of state-of-the-art algorithms modified and optimized to adapt to the structure, volume of data, and application context. The communities are represented in table T by a community identifier Q, where 1 <j<4 dans l’exemple représenté. De ce tableau T, il est ainsi possible de déduire les informations suivantes :

[0075] - user 3i belongs to a first community Ci;

[0076] - user 32 belongs to the first community Ci;

[0077] - user 33 belongs to a second community C2;

[0078] - user 34 belongs to the first Ci community and to the second community C2;

[0079] - user 35 belongs to the first Ci community and to a fourth community C4;

[0080] - user 36 belongs to the first community Ci;

[0081] - user 37 belongs to the second C2 community and to the fourth community C4;

[0082] - user 38 belongs to the second community C2 and to the third community C3;

[0083] - user 39 belongs to the third C3 community and to the fourth community C4;

[0084] - user 3io belongs to the third C3 community;

[0085] - user 3n belongs to the third community C3;

[0086] - user 3i2 belongs to the fourth community C4;

[0087] - user 3i3 belongs to the fourth community C4;

[0088] - user 3i4 belongs to the fourth C4 community;

[0089] - user 315 belongs to the fourth C4 community.

[0090] It should be noted that at this stage, user 1 does not belong to any community.

[0091] Figure 6 illustrates a grouping of users 3i to 3i5 from graph G in Figure 4, on which the different communities C1 to C4 are positioned. Each community is represented by a generally circular shape encompassing the users belonging to that community. Thus, as already stated, users 3b, 32, 34, 35, and 36 belong to the first community C1. Users 33, 34, 37, and 38 belong to the second community C2. Users 38, 39, 3i0, and 3n belong to the third community C3. User 35, user 37, user 39, user 3i2, user 3n, user 3W and user 3i5 belong to the fourth community C4.

[0092] The different communities Ci to C4 can be viewed as a community graph comprising nodes and edges connecting said nodes. Such a community graph, referenced Gc, is illustrated in [Fig. 7]. Each node thus corresponds to a community. The nodes are connected to each other when there is at least one user common to both communities. In the case of the community graph Gc in [Fig. 7], there is an edge between the node associated with the first community Ci and the node associated with the second community C2, because user 34 is common to both communities. Similarly, there is an edge between the node associated with the first community Ci and the node associated with the fourth community C4 because user 35 is common to both communities Ci and C4. Furthermore, there is an edge between the node associated with the second community C2 and the node associated with the third community C3 because user 38 is common to both communities C2 and C3.Furthermore, there is an arc between the node associated with the second community C2 and the node associated with the fourth community C4 because user 37 is common to both communities C2 and C4. Finally, there is an arc between the node associated with the third community C3 and the node associated with the fourth community C4 because user 39 is common to both communities C3 and C4.

[0093] From the community graph Gc, it is possible to construct a minimum distance storage matrix M between the different communities. Such a matrix M is illustrated in particular in [Fig. 8]. This matrix M contains integer values ​​between 0 and 2. The value 0 is associated with a distance of zero. The value 1 is associated with a distance between two communities connected by an arc, such as the pairs of communities Ci, C2; Ci, C4; C2, C3; C2, C4; C3, C4. The value 2 is assigned when an intermediate community connects two communities that do not have an arc in common, such as, for example, the pair of communities Ci, C3 connected either by the second community C2 or by the fourth community C4. The matrix M of Distance storage is stored in the communications database 302.

[0094] Figure 9 represents a variant embodiment of a table T' corresponding to an extension of the table T in Figure 5. In this table T', different neighborhood levels k are determined for each user of the aforementioned communities. Neighborhood level k=0 corresponds to the neighborhood level detailed in Figure 5. Neighborhood level k=1 corresponds to a level of direct proximity with the community or communities of neighborhood level k=0. Neighborhood level k=2 corresponds to a level of direct proximity with the community or communities of neighborhood level k=1. Thus, for example, the neighborhood level k=0 of user 3i includes the first community Ci. The neighborhood level k=1 for this same user includes the second community C2 and the fourth community C4. Finally, the neighborhood level k=2 for this same user includes the third community C3.As another example, the neighborhood level k=0 for user 33 includes community C2. The neighborhood level k=1 for this same user includes community Ci, community C3, and community C4. Finally, the neighborhood level k=2 for this same user includes no community.

[0095] As illustrated in [Fig. 1], the communications database 302 is updated by the monitoring device S. This monitoring device S is adapted to listen to the communication network R and to detect any transaction between i users 31 to 315, where l <i<15 dans l’exemple représenté. Le dispositif de supervision S est également adapté pour détecter les requêtes de communication provenant de l’utilisateur 1. De manière périodique, le dispositif de supervision S met à jour l’historique de communications H, le tableau T listant les communautés Ci à C4, le tableau T’ et la matrice M de stockage de distance minimale.

[0096] User 2's terminal 20 is adapted to receive the Data associated with determining the confidence score and the confidence gap Deltaconf. Such a terminal 20 is illustrated in particular in [Fig. 10]. It comprises:

[0097] - a client-receiver application;

[0098] - an interface module 201.

[0099] The receiving client application is adapted to receive and process Data.

[0100] The interface module 201 is adapted to return the result of this processing to the user 2 on a dedicated interface of the terminal 20 or another terminal.

[0101] Depending on the type of terminal 20, the processing applied to the Data will not be the same. Figure 11 illustrates the steps of a decision support process according to a first embodiment, in which a terminal 20, which is the recipient of the Reqcom communication request, is a "smartphone" or smart terminal. Figure 12 illustrates the steps of a decision support process, according to a second embodiment, in which the terminal 20 has a lower capacity than the terminal 20 used in the process of [Fig. 11].

[0102] The decision support process illustrated in [Fig. 11] includes the transmission of an order by user 1 via interface module 101 of their terminal 10 to the sending client application of the same terminal 10. Upon receiving this order, the sending client application transmits a communication request Reqcom to the receiving client application of user 2's terminal 20. This request includes an identifier ID_1 for user 1. The receiving client application transmits a getScore request to the computing device 301 to determine a confidence score Sconf for user 1 and a confidence gap Deltaconf. This getScore request includes the identifier ID_1 for user 1. In return, the computing device 301 provides the Data to the receiving client application. This Data is, in this case, the confidence score Sconf for user 1 and the confidence gap Deltaconf.The computing device 301 determines this Data by consulting the communications database 302. The confidence score Sconf and the confidence gap Deltaconf can be determined by different methods.

[0103] In a first method, the computing device 301 uses the information contained in the history H of [Fig. 3], in the table T of [Fig. 5], and in the matrix M of [Fig. 8]. From the history H, it is possible to establish a list h of user(s) to whom the sending user 1 has previously transmitted a communication request via their terminal 20. As already explained with reference to [Fig. 3], this list h is a subset of the history H. In the example of [Fig. 3], user 1 has previously transmitted a communication request to user 3b, user 34, and user 37.

[0104] Each of these users 3b 34, 37 belongs to a community.

[0105] From table T in [Fig.5], it is therefore possible to define that:

[0106] - user 3i belongs to the Ci community (first line of table T);

[0107] - user 34 belongs to communities Ci and C2 (fourth line of table T)

[0108] - user 37 belongs to communities C2 and C4 (seventh line of table T).

[0109] From the users in list h, it is formed pairs of contact users [3i.34],[3i.37] and [34j 37],

[0110] In each of the pairs of users, at least one minimum inter-community distance D is determined with D=Min (M(Cm, Cn)) where m and n are integers here between 1 and 4. This minimum inter-community distance is obtained by comparing the communities to which the users of the pair belong using the matrix M of [Fig.8].

[0111] Thus in the pair [31, 34], a first distance is determined between the community Ci of user 3i and the community Ci of user 34 and a The second distance is between user 3i's community Ci and user 34's community C2. According to [Fig. 8], the first distance is zero (intersection Ci-Ci in table T) and the second distance is 1 (intersection Ci-C2 in table T). Therefore, the minimum inter-community distance is zero here (the minimum between 0 and 1).

[0112] In other words, D[3i, 34] = Min (M(Cb Ci), M(Cb C2)) = Min (0, 1) = 0.

[0113] Similarly, for the pair [3b 37], D[3b 37]= Min (M(Cb C2), M(Cb C4)) = Min(l, 1)= 1.

[0114] For the pair [34> 37], D[34> 37]= Min (M(Cb C2), M(Cb C4), M(C2, C2), M(C2, C4))= Min(l, 1,0, l) = 0.

[0115] The confidence score Sconf corresponds to the average of the minimum inter-community distances of the different pairs of users. In other words, Sconf = Average (D[3i, 34], D[3b 37], D[34> 37]) = Average (0, 1, 0) = 0.33.

[0116] The confidence gap Deltaconf corresponds to the standard deviation of the minimum inter-community distances of the different pairs of users. Thus, Deltaconf = Standard deviation (D[3!, 34], D[3b 37], D[34,37]).

[0117] The deviations are determined here with respect to the mean 0.33. The standard deviation corresponds to the root mean square of these deviations, hence I(0.332+0.672+f),332), i.e. JDçilXiiCon. t — to / 0.47.

[0118] In a second method for determining the confidence score Sconf and the confidence gap Deltaconf, the computing device 301 uses the information contained in the history H of [Fig. 3] and in the extended table T' of [Fig. 9]. As in the first method, from the history H, it is possible to establish a list h of user(s) to whom user 1 has previously sent a communication request via their terminal 20. In the example of [Fig. 3], user 1 has previously sent a communication request to user 3b, user 34, and user 37.

[0119] Each of these users 3b 34, 37 belongs to a community.

[0120] From the extended table T' of [Fig.5], it is thus possible to define that:

[0121] - user 3i belongs to the Ci community (first line of table T for a neighborhood level k=0), user 3i is a neighbor of community C2 and community C4 at a neighborhood level k=1 and user 3i is a neighbor of community C3 at a neighborhood level k=2;

[0122] - user 34 belongs to communities Ci and C2 (fourth line of table T) for a neighborhood level k=0), user 34 is a neighbor of community C3 and community C4 at a neighborhood level k=l;

[0123] - user 37 belongs to communities C2 and C4 (seventh line of table T) for a neighborhood level k=0), user 37 is a neighbor of community Ci and community C3 at a neighborhood level k=l.

[0124] From the users in list h, it consists of the pairs of users [3X> 34], [3i, 37] and [34, 37].

[0125] In each of the pairs of users, at least one minimum inter-community distance D is determined with D=Min (M(Cm', Cn )) where m' and n' are integers here between 1 and 4. This minimum inter-community distance is obtained by comparing the communities to which the users of the pair belong in the table T' of [Fig.9].

[0126] For the pair of users [3i, 34], the community Ci is common to users 3i and 34. Therefore, the minimum inter-community distance D[3i, 34] is zero.

[0127] For the pair of users [34, 37], the community C2 is common to users 34 and 37. Therefore, the minimum inter-community distance D[34, 37] is zero.

[0128] For the pair of users [3i, 37], there is no common community at a neighborhood level k=0. However, the community Ci is found at a neighborhood level k=l for user 37. Therefore, the minimum inter-community distance D[3i, 37] is equal to 1.

[0129] The confidence score Sconf corresponds to the average of the minimum inter-community distances of the different pairs of users. In other words, Sconf = Average (D[3i, 34], D[3i, 37], D[34, 37]) = Average (0, 1, 0) = 0.33.

[0130] The confidence gap Deltaconf corresponds to the standard deviation of the minimum inter-community distances of the different pairs of contact users. Thus, Deltaconf = Standard deviation (D[3i, 34], D[3i, 37], D[34, 37]).

[0131] The deviations are determined here with respect to the mean 0.33. The standard deviation is the root mean square of these deviations, hence I(0.332+0.672+0.332), i.e. taCOni A] 0.47.

[0132] In a third method, the computing device 301 uses the information contained in the history H of [Fig. 3], in the table T of [Fig. 5], and in the matrix M of [Fig. 8]. From the history H, it is possible to establish a list h of user(s) to whom user 1 has previously sent a communication request. As already mentioned, this list h is a subset of the history H. In the example of [Fig. 3], user 1 has previously sent a communication request to user 3b, user 34, and user 37.

[0133] Each of these users 3i, 34, 37 belongs to a community.

[0134] From table T in [Fig.5], it is therefore possible to define that:

[0135] - user 3i belongs to the Ci community (first line of table T);

[0136] - user 34 belongs to communities Ci and C2 (fourth line of table T)

[0137] - user 37 belongs to communities C2 and C4 (seventh line of table T).

[0138] From the users in list h, it consists of the pairs of users [3X> 34], [3i, 37] and [34, 37].

[0139] The Sconf confidence score here corresponds to the cardinality of the union of user communities.

[0140] In other words, Sconf = I 3x U 34 U 371 = I [CJ U [C! , C2] U [C2, C4] I = I [Cb C2, C4] I. The cardinality of the union of the user communities is therefore equal to 3 here.

[0141] The confidence gap Deltaconf corresponds to the confidence score Sconf from which an average of the cardinalities of the unions of the user communities is subtracted.

[0142] In other words, Deltaconf = I 3i U 34 U 371 - average (l 3i U 34 I, I 3i U 371.1 34 U 371) = I [Ci, C2, C4] I - average (l [Ci, C2] I, I [Cb C2, C4] I, [Ci, C2, C4] I) = 3 - average(2, 3.3) = 0.33.

[0143] As already indicated, the receiving client application of [Fig. 11] is adapted to process the confidence score Sconf and the confidence gap Deltaconf determined by one or the other of the methods described above. To this end, the receiving client application uses a first threshold for the confidence score and a second threshold for the confidence gap.

[0144] If the confidence score determined by the calculation device 301 is higher than the first threshold, this indicates that user 2 is an abusive user employing phishing, scam, or spam practices. In this type of practice, the abusive user tends to contact a very large number of users, resulting in a deviation from the norm (high average).

[0145] If the confidence score determined by the calculation device 301 is below the first threshold, the Deltaconf confidence gap is then compared to the second threshold. A "new entrant" user logically tends to contact legitimate, established users with a high probability of social connection. A "legitimate" user is defined as a recognized member of the service who, through their regular use, will tend to contact or be contacted by other users. Thus, a user 1 acting in good faith will direct their contact strategy toward several legitimate users, which will limit the gaps between the users contacted. The Deltaconf confidence gap will then be small. Conversely, an abusive user 1 will have an erratic contact strategy, contacting both legitimate and illegitimate users, which will increase the gaps between the users contacted.The Deltaconf confidence gap will then be high, and such a user 1 will need to be excluded.

[0146] Following this processing, the receiving client application provides the interface module 201 with decision support in the form of a ClientInformation. This information indicates to user 2 whether or not they can accept the request from Reqcom communication originating from user 1.

[0147] User 2 indicates their choice (ChoiceConfirmation on [Fig. 11]) to the receiving client application via interface module 201. If communication with user 1 is accepted (confirmation OK on [Fig. 11]), a notification of acceptance of the Reqcom request (Acceptance on [Fig. 11]) is sent to the sending client application. Conversely, if communication with user 1 is refused (confirmation Not OK on [Fig. 11]), a notification of rejection of the Reqcom request (Rejection on [Fig. 11]) is sent to the sending client application.

[0148] It should be noted that the supervision device S updates the communications database 302 according to the decision of user 2.

[0149] The decision support device 30 used in the process of [Fig. 12] is distinguished by having an additional application server. This application server is adapted to directly process the confidence score Sconf and the confidence gap Deltaconf determined by the calculation device 301. Such processing is therefore no longer carried out within the receiving terminal 20 as in the embodiment of [Fig. 11].

[0150] The method in [Fig. 12] includes the transmission of a command `Order` by user 1 via interface module 101 of terminal 10 to the sending client application of the same terminal 10. Upon receiving this command, the sending client application transmits a communication request `Reqcom` to the application server of device 30. This request includes the identifier `ID_1` of user 1. The application server transmits a `getScore` request to the computing device 301 to determine a confidence score `Sconf` of user 1 and a confidence gap `Deltaconf`. This `getScore` request includes the identifier `ID_1` of user 1. In return, the computing device 301 provides the application server with the confidence score `Sconf` of user 1 and the confidence gap `Deltaconf`. The computing device 301 determines this data by consulting the communication database 302.The confidence score Sconf and the confidence gap Deltaconf can be determined by the different methods described above.

[0151] The application server is capable of processing the confidence score Sconf and the confidence gap Deltaconf and of providing decision support to the receiving client application by transmitting this data to that application. The receiving client application adapts the client information to the interface module 201. The client information indicates to user 2 whether or not they can accept the communication request Reqcom from user 1. User 2 indicates their choice (ChoiceConfirmation in [Fig. 12]) to the receiving client application, via the interface module 201. If communication with user 1 is accepted, an acceptance notification (Acceptance in [Fig. 12]) is sent to the sending client application. Conversely, if communication with the sending user is refused, a rejection notification (Rejection on [Fig. 12]) is sent to the sending client application.

[0152] Decision support can thus be applied to various use cases.

[0153] A first use case of the invention is in mobile banking / SMShing. Users of mobile banking applications are often victims of scams aimed at diverting all or part of their funds to one or more fraudulent accounts in a more or less sophisticated manner. Fraud or scam attempts are numerous and varied but often follow a classic scenario: a fraudster buys a temporary SIM card and conducts a phishing campaign for a limited time.The scammer sends text messages (or calls) to a large number of randomly selected users from customer lists obtained through data breaches at e-commerce websites (for example), or buys and sells lists of phone numbers of potential targets. The message content (a prize in a game, an acquaintance in distress, etc.) tricks the victim into initiating a transaction to an account they believe to be legitimate, but which is actually linked to the scammer. The account is used to collect funds for the fraud campaign and is then closed after being emptied. The numerous victims targeted by this campaign do not know each other and have no strong social connections. Furthermore, these victims are already in the system (they are on lists that have been sold or exchanged).The probability that x victims chosen at random by the algorithm from N (on the lists) could have a calculable (and short) community social distance is low, even almost zero. The fraudster's abusive behavior can therefore be quickly qualified and quantified (from a few transactions) and can be presented to victims from the very first exchanges upon receiving the call or SMS (for "Short Message System"), or upon sending the transaction.

[0154] A second use case lies in "communication / sales".

[0155] During a telemarketing campaign, companies use several phone numbers that are frequently changed. Some prior art applications allow telemarketing victims to collaboratively identify and categorize the type of contact (commercial, malicious) and offer a solution for sharing this information via the application. It may take a few hours or days for the service to become fully effective (sufficient feedback) and gives companies time to change their phone numbers. Following the same principle as described in the first case, telemarketers use lists of numbers to call; the "victims" on these lists have no apparent connection to each other and therefore a low (or even near-zero) probability of being contacted, and the average social distance is very high (with infinite distances).

[0156] A third application case lies in the management of "scam email / "Poupmel." When an email service user receives an incoming communication (an email) from an "unknown" sender, the invention calculates a priori risk of misuse of the email sender, such as scammers or spammers. The 301 calculation device can then use this score to classify emails, or even reject them, in an optimized manner: senders with a high score will be considered spammers, senders with a medium score will be business / institutional senders, and senders with a low score will be individuals. The receiving user can then contact the 301 calculation device to view these emails, highlighting emails from legitimate users and filtering out spam and scam emails.

[0157] The solution proposed by the invention is also applicable to any context implementing incoming or outgoing transactions for which it is possible to establish a social relationship between the actors of the system: mobile payments, bank transfers, communication (emails, calls, SMS, CDR (for "Call Detail Record"), ...)

[0158] The invention allows a real-time display of the confidence level of each incoming transaction at the terminal 20 level.

[0159] The proposed invention is complementary to the solutions described in the prior art and enhances their effectiveness.

[0160] The proposed solution is therefore based on the use of a software component for controlling and securing transactions.

[0161] In a particular embodiment, the invention relies on a practice of "scoring" an average social distance between the contacts of a user initiating a communication request, in order to extract a trust score evaluating their integration / virtuous use of the communication service. This trust score is an evaluation criterion, for each transaction originator, of their predisposition to disseminate personal / relevant / generic information or, conversely, harmful information to their interlocutors.

[0162] Based on a technical building block which makes it possible to construct sets of users identified as having a transactional social proximity calculated on the basis of past exchanges, the set of users, and their past transactions, constitute a network, of which each node is a user, and the past transactional data make it possible to create a relationship between the nodes of the network.

[0163] The proposed system assigns each user one or more communities of belonging.

[0164] The system stores, for each user, the set of their calculated membership communities and keeps it up to date by an automated procedure applied regularly (once a day / month / week).

[0165] In addition to this information, there is the confidence gap calculated by the method of the invention. This confidence gap is calculated, in one embodiment, based on minimum inter-community distances. In another embodiment, the confidence gap is determined based on the cardinality of a union of user communities.

Claims

Claims

1. Decision-making method for a user (2) of a first terminal (20) receiving a communication request (Reqcom) from a second terminal (10), the user (1) of the second terminal (10) being unknown to said user of the first terminal (20), said method comprising: - determining a confidence score (Sconf) of the user of the second terminal (10) and a confidence gap (Deltaconf), said confidence gap (Deltaconf) providing information on a reliability of said confidence score (Sconf), said confidence score (Sconf) and said confidence gap (Deltaconf) being determined from a list (h) comprising at least one user (3b 34, 37) of a third terminal to which the second terminal (10) has already transmitted a communication request, the at least one user (3b 34, 37) of the third terminal belonging to at least one community (Ci, C2C4) of users.

2. Decision support method according to claim 1, in which the list (h) comprises three users (3b 34, 37) of respectively three terminals to which the second terminal (10) has already transmitted a communication request.

3. Decision support method according to one of claims 1 or 2, in which the determination of the confidence score (Sconf) and the confidence gap (Deltaconf) comprises a selection of at least one pair ([3i, 34], [31, 37], [34, 37]) of users in said list (h).

4. 4. Decision support method according to claim 3, wherein the determination of the confidence score (Sconf) comprises, for each pair ([31, 34], [31, 37], [34, 37]) of users, a calculation of a minimum intercommunity distance (D[3i, 34], D[3i, 37], D[34, 37]), said minimum intercommunity distance being determined from community sets (Ci, C2C4) to which the users of said pair belong, said confidence score corresponding to an average of the minimum intercommunity distances (D[3i, 34], D[3i, 3 7], D[34> 37]) of the pairs ([3i, 34], [3i, 37], [34> 37]).

5. 5. Decision support method according to claim 4, wherein if the users of a pair have a community in common, the minimum intercommunity distance of said pair is zero.

6. 6. Decision support method according to any one of the claims- indications 4 or 5, in which if the users of a pair do not have a community in common, the minimum intercommunity distance of said pair is at least equal to 1.

7. 7. Decision support method according to any one of claims 4 to 6, in which the confidence gap (Deltaconf) corresponds to a standard deviation of the minimum intercommunity distances (D[ 31 34], D[3i, 37], D[34j 37]) of the pairs ([31, 3JJ31, 37], [34> 37]).

8. Decision support method according to claim 2, in which the confidence score (Sconf) corresponds to a cardinality of a union of user communities to which the three users of the list (h) belong.

9. 9. Decision support method according to claim 8, in which the confidence gap (Deltaconf) corresponds to the confidence score (Sconf) from which an average of cardinalities of unions of the user communities to which the three users of the list (h) belong is subtracted.

10. 10. Decision support system for a user (2) of a first terminal (20) receiving a communication request (Reqcom) from a second terminal (10), the user (1) of the second terminal (10) being unknown to said user (2) of the first terminal (20), said decision support system (30) comprising a calculation device (301) and a communications base (302), said calculation device (301) and said communications base (302) being capable of determining a confidence score (Sconf) of the user (1) of the second terminal (10) and a confidence gap (Deltaconf), said confidence gap (Deltaconf) providing information on a reliability of said confidence score (Sconf), said confidence score (Sconf) and said confidence gap (Deltaconf) being determined from a list (h) comprising at least one user (3b 34,37) of a third terminal to which the second terminal (10) has already transmitted a communication request, the at least one user (3b 34, 37) of the third terminal belonging to at least one community (Ci, C2C4) of users.,

11. 11. Decision support system according to claim 10, wherein the calculation device (301) is adapted to transmit the confidence score (Sconf) and the confidence gap (Deltaconf) to the first terminal (20).

12. 12. The decision support system of claim 11, wherein said system comprises an application server, said application server being capable of processing said confidence score (Sconf) and said confidence gap (Deltaconf) and sending the result of said processing to the first terminal (20).

13. 13. A computer program comprising program code instructions for executing the steps of a decision support method according to any one of claims 1 to 9, when said program is executed by a processor.

14. 14. A computer-readable recording medium on which is recorded a computer program comprising program code instructions for executing a decision-making method according to any one of claims 1 to 9, when said program is executed by a processor.

Images