METHOD FOR ASSISTING A USER OF A TERMINAL IN DECIDING TO APPROVE A COMMUNICATION, OR NOT, CORRESPONDING DECISION-MAKING ASSIST SYSTEM AND COMPUTER PROGRAM

Abstract

A decision-making assist method for a user of a first terminal receiving a communication request originating from a second terminal, the user of the second terminal being unknown to the user of the first terminal. The method includes determining a trust score of the user of the second terminal and a trust deviation, the trust deviation providing information on a reliability of the trust score. The trust score and the trust deviation are determined from a list including 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 belonging to at least one user community.

Claims

1. A decision-making assist method for a user of a first terminal receiving a communication request originating from a second terminal, the user of the second terminal still not having transmitted any communication request to the user of the first terminal, the method comprising: determining a trust score of the user of the second terminal and a trust deviation, the trust deviation providing information on a reliability of the trust score, the trust score and the trust deviation being determined from a list comprising at least one user (3.sub.1, 3.sub.4, 3.sub.7) of a third terminal to which the second terminal has already transmitted a communication request, the at least one user (3.sub.1, 3.sub.4, 3.sub.7) of the third terminal belonging to at least one user community (C.sub.1, C.sub.2, C.sub.4).

2. The decision-making assist method according to claim 1, wherein the list comprises three users (3.sub.1, 3.sub.4, 3.sub.7) of respectively three terminals to which the second terminal has already transmitted a communication request.

3. The decision-making assist method according to claim 1, wherein the determination of the trust score and of the trust deviation comprises selecting at least one pair ([3.sub.1, 3.sub.4], [3.sub.1, 3.sub.7], [3.sub.4, 3.sub.7]) of users in the list.

4. The decision-making assist method according to claim 3, wherein the determination of the trust score comprises, for each pair ([3.sub.1, 3.sub.4], [3.sub.1, 3.sub.7], [3.sub.4, 3.sub.7]) of users, computing a minimum intercommunity distance (D[3.sub.1, 3.sub.4], D[3.sub.1, 3.sub.7], D[3.sub.4, 3.sub.7]), the minimum intercommunity distance being determined from community sets (C.sub.1, C.sub.2, C.sub.4) to which the users of the pair belong, the trust score corresponding to an average of the minimum intercommunity distances (D[3.sub.1, 3.sub.4], D[3.sub.1, 3.sub.7], D[3.sub.4, 3.sub.7]) of the pairs ([3.sub.1, 3.sub.4], [3.sub.1, 3.sub.7], [3.sub.4, 3.sub.7]).

5. The decision-making assist method according to claim 4, wherein the minimum intercommunity distance of a pair is zero when the users of the pair have one community in common.

6. The decision-making assist method according to claim 4, wherein the minimum intercommunity distance of a pair is at least equal to 1 when the users of the pair have no community in common.

7. The decision-making assist method according to claim 4, wherein the trust deviation corresponds to a standard deviation of the minimum intercommunity distances (D[3.sub.1, 3.sub.4], D[3.sub.1, 3.sub.7], D[3.sub.4, 3.sub.7]) of the pairs ([3.sub.1, 3.sub.4], [3.sub.1, 3.sub.7], [3.sub.4, 3.sub.7]).

8. The decision-making assist method according to claim 2, wherein the trust score corresponds to a cardinality of a union of user communities to which the three users of the list belong.

9. The decision-making assist method according to claim 8, wherein the trust deviation corresponds to the trust score from which is subtracted an average of the cardinalities of unions of the user communities to which the three users of the list belong.

10. A decision-making assist system for a user of a first terminal receiving a communication request originating from a second terminal, the user of the second terminal still not having transmitted any communication request to the user of the first terminal, the decision-making assist system comprising a computing device and a communication base, the computing device and the communication base being able to determine a trust score of the user of the second terminal and a trust deviation, the trust deviation providing information on a reliability of the trust score, the trust score and the trust deviation being determined from a list comprising at least one user (3.sub.1, 3.sub.4, 3.sub.7) of a third terminal to which the second terminal has already transmitted a communication request, the at least one user (3.sub.1, 3.sub.4, 3.sub.7) of the third terminal belonging to at least one user community (C.sub.1, C.sub.2, C.sub.4).

11. The decision-making assist system according to claim 10, wherein the computing device is adapted to transmit the trust score and the trust deviation to the first terminal.

12. The decision-making assist system according to claim 11, wherein the system comprises an application server, the application server being able to process the trust score and the trust deviation and to send the result of the processing to the first terminal.

13. A processing circuit comprising a processor and a memory, the memory storing program code instructions of a computer program to execute the decision-making assist method according to claim 1, when the computer program is executed by the processor.

14. A non-transitory computer-readable recording medium on which a computer program is recorded comprising program code instructions for execution of the decision-making assist method according to claim 1, when the computer program is executed by a processor.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0033] FIG. 1 illustrates an example of a communication network implementing a decision-making assist method according to the embodiments of the development;

[0034] FIG. 2 illustrates an example of a terminal configured to emit a communication request in the communication network of FIG. 1;

[0035] FIG. 3 illustrates an example of a history of communications between different users of the communication network of FIG. 1;

[0036] FIG. 4 shows a graph illustrating the history of communications of FIG. 3;

[0037] FIG. 5 shows a table listing communities to which the different users of the communication network of FIG. 1 belong;

[0038] FIG. 6 shows the graph of FIG. 4 associated with the list of the communities of FIG. 5;

[0039] FIG. 7 shows a community graph obtained from a data association of FIG. 6;

[0040] FIG. 8 shows a matrix for storing the minimum distance between communities of FIG. 7;

[0041] FIG. 9 shows a table corresponding to the table of FIG. 5, with additional columns;

[0042] FIG. 10 illustrates an example of a terminal configured to receive a communication request via the communication network of FIG. 1;

[0043] FIG. 11 shows the different steps of a decision-making assist method according to a first embodiment of the development;

[0044] FIG. 12 shows the different steps of a decision-making assist method according to a second embodiment of the development;

[0045] FIG. 13 illustrates, in a detailed manner, a decision-making assist system used in the network of FIG. 1.

[0046] FIG. 1 shows a communication network R for exchanging data between a terminal 10 of a user 1 and a terminal 20 of a user 2.

[0047] The terminal 10 of the user 1 is adapted to transmit a communication request Req.sub.com to the terminal 20 in order to establish communication with the user 2. FIG. 2 details the structure of such a terminal 10.

[0048] The terminal 10 is herein a smart terminal, or smartphone in English, adapted to implement software applications. Thus, the terminal 10 comprises an interface module 101 and an emitter client application. The interface module 101 enables the user 1 to transmit a command for sending a communication request Req.sub.com to the terminal 20. Typically, the interface module 101 is a keyboard of the terminal 10. Alternatively, the interface module 101 could be a voice command. The emitter client application is adapted to generate and transmit to the communication network R the communication request Req.sub.com from the send command originating from the interface module 101 of the terminal 10.

[0049] As illustrated in FIG. 1, the communication network R comprises a decision-making assist system 30 and a supervision device S. The decision-making assist system 30 is able to receive a query for determining a trust score Sconf associated with the user 1 and a trust deviation Deltaconf. Such a query is derived from the communication request Req.sub.com. The trust score Sconf provides information on the trust to be granted on the user 1. The trust deviation Deltaconf provides information on the reliability of said trust score Sconf. In response to this determination query, the decision-making assist system 30 is adapted to transmit to the terminal 20 data Data associated with the determination of the trust score and of the trust deviation Deltaconf.

[0050] FIG. 13 illustrates, in a more detailed manner, the decision-making assist system 30. This decision-making assist system 30 comprises at least one processor PROC and at least one memory MEM. More particularly, the system 30 is provided, according to one embodiment, with the hardware architecture of a computer. The memory MEM forms an information medium in accordance with the development, i.e. readable by the processor PROC and on which a computer program PROG in accordance with the development is recorded. The program PROG includes instructions for carrying out steps of a method in accordance with the development, when the program PROG is executed by the processor PROC. In particular, the program PROG defines the functional modules of the system 30, which control the hardware elements of the latter.

[0051] As illustrated in FIG. 13, the system 30 comprises a communication device COM configured to communicate in particular with the supervision device S and the terminals 10 and 20 of FIG. 1. There is no limitation on the nature of the communication interfaces between these devices, which could implement any protocol known to a person skilled in the art.

[0052] The decision-making assist system 30 further comprises: [0053] a computing device 301; [0054] a communication base 302.

[0055] The computing device 301 is adapted to compute the trust score Sconf and the trust deviation Deltaconf from information stored in the communication base 302. More particularly, the communication base 302 stores a history H of communication requests between different user terminals of the communication network. FIG. 3 illustrates an example of such a history between, for example, fifteen users 3.sub.1 to 3.sub.15, the terminal(s) of each of these users being able to serve as an emitter or receiver of a communication request. These users are respectively referenced in the history H from an identifier ID_3.sub.1 to ID_3.sub.15. In a particular embodiment that is not illustrated herein, the used identifier is a MSISDN identifier (standing for Mobile Station International Subscriber Directory Number in English). When a communication request transmitted by a terminal of these users is approved by a terminal of another one of these users, a transaction is passed. Thus, the history H lists the completed transactions, so-called OK transactions, and the non-completed transactions, so-called NOK transactions. In the example of FIG. 3, all transactions between the contact users 3.sub.1 to 3.sub.15 have been completed.

[0056] The history H also lists the communication requests having been transmitted by the terminal 10 of the user 1. The user 1 is referenced starting from the identifier ID_1. No transaction is validated for this user 1, since the latter is not known to the different users 3.sub.1 to 3.sub.15. Thus, it is possible to establish a list h of users to whom the user 1 has transmitted beforehand a communication request via his/her terminal 10.

[0057] FIG. 4 shows a graph G illustrating the history of communications of FIG. 3. In this graph G, each user 3.sub.1 to 3.sub.15 represents a circular node. The transactions OK between the nodes are represented by solid lines.

[0058] In this FIG. 4, it is possible to deduce the following information: [0059] a first user 31 has already performed at least one transaction with a second user 32, a fourth user 34 and a fifth user 35; [0060] the second user 32 has already performed at least one transaction with the first user 31, the fifth user 35 and a sixth user 36; [0061] a third user 33 has already performed at least one transaction with a fourth user 34, a seventh user 37 and an eighth user 38; [0062] the fourth user 34 has already performed at least one transaction with the first user 31, a third user 33 and the seventh user 37; [0063] the fifth user 35 has already performed at least one transaction with the first user 31, the second user 32, the sixth user 36, a twelfth user 312 and a fourteenth user 314; [0064] the sixth user 36 has already performed at least one transaction with the second user 32 and the fifth user 35; [0065] the seventh user 37 has already performed at least one transaction with the third user 33, the fourth user 34, the eighth user 38 and the twelfth user 312; [0066] the eighth user 38 has already performed at least one transaction with the third user 33, the seventh contact 37, a ninth user 39 and an eleventh user 311; [0067] the ninth user 39 has already performed at least one transaction with the eighth user 38, a tenth user 310, an eleventh user 311, the twelfth user 312, and a thirteenth user 313; [0068] the tenth user 310 has already performed at least one transaction with the ninth user 39 and the eleventh user 311; [0069] the eleventh user 311 has already performed at least one transaction with the eighth user 38, the ninth user 39 and the tenth user 310; [0070] the twelfth user 312 has already performed at least one transaction with the fifth user 35, the seventh user 37, the ninth user 39, the thirteenth user 313, the fourteenth user 314 and a fifteenth user 315; [0071] the thirteenth user 313 has already performed at least one transaction with the ninth user 39, the twelfth user 312 and the fifteenth user 315; [0072] the fourteenth user 3.sub.14 has already performed at least one transaction with the fifth user 3.sub.5, the twelfth user 3.sub.12 and the fifteenth user 3.sub.15; [0073] the fifteenth user 315 has already performed at least one transaction with the twelfth user 312, the thirteenth user 313 and the fourteenth user 314.

[0074] The dotted lines between the user 1 and the user 3.sub.1, the user 3.sub.4 and the user 3.sub.7 represent NOK transactions, i.e. communications that has not been approved by the respective users 3.sub.1, 3.sub.4, 3.sub.7.

[0075] FIG. 5 shows a table T listing, for each user 3.sub.1 to 3.sub.15, the membership communit(y/ies). Users belong to the same community because they share at least one common interest (members of the same family, colleagues of a company or a group of companies, students of the same university circle, members of a sports governing body, etc.) or relationships leading them to communicate in various forms. Thus, this community forms a sphere of trust. A same user 3.sub.1 to 3.sub.15 may belong to several communities. The construction of these communities is based on a set of algorithms of the prior art modified and optimized so as to adapt to the structure, to the data volume and to the application context. The communities are represented in the table T by community identifier C.sub.j, where 1j4 in the illustrated example. In this table T, it is thus possible to deduce the following information: [0076] the user 3.sub.1 belongs to a first community C.sub.1; [0077] the user 3.sub.2 belongs to the first community C.sub.1; [0078] the user 3.sub.3 belongs to a second community C.sub.2; [0079] the user 3.sub.4 belongs to the first community C.sub.1 and to the second community C.sub.2; [0080] the user 3.sub.5 belongs to the first community C.sub.1 and to a fourth community C.sub.4; [0081] the user 3.sub.6 belongs to the first community C.sub.1; [0082] the user 3.sub.7 belongs to the second community C.sub.2 and to the fourth community C.sub.4; [0083] the user 3.sub.8 belongs to the second community C.sub.2 and to the third community C.sub.3; [0084] the user 3.sub.9 belongs to the third community C.sub.3 and to the fourth community C.sub.4; [0085] the user 3.sub.10 belongs to the third community C.sub.3; [0086] the user 3.sub.11 belongs to the third community C.sub.3; [0087] the user 3.sub.12 belongs to the fourth community C.sub.4; [0088] the user 3.sub.13 belongs to the fourth community C.sub.4; [0089] the user 3.sub.14 belongs to the fourth community C.sub.4; [0090] the user 3.sub.15 belongs to the fourth community C.sub.4.

[0091] It should be noted that, at this level, the user 1 does not belong to any community.

[0092] FIG. 6 illustrates a grouping of the users 3.sub.1 to 3.sub.15 of the graph G of FIG. 4, over which the different communities C.sub.1 to C.sub.4 are positioned. Each community is materialized by a generally circular shape surrounding the users belonging to said community. Thus, as already set out, the user 3.sub.1, the user 3.sub.2, the user 3.sub.4, the user 3.sub.5, the user 3.sub.6 belong to the first community C.sub.1. The user 3.sub.3, the user 3.sub.4, the user 3.sub.7 and the user 3.sub.8 belong to the second community C.sub.2. The user 3.sub.8, the user 3.sub.9, the user 3.sub.10 and the user 3.sub.11 belong to the third community C.sub.3. The user 3.sub.5, the user 3.sub.7, the user 3.sub.9, the user 3.sub.12, the user 3.sub.13, the user 3.sub.14 and the user 3.sub.15 belong to the fourth community C.sub.4.

[0093] The different communities C.sub.1 to C.sub.4 may be perceived as a community graph including nodes and arcs linking said nodes. Such a community graph, referenced G.sub.C, is illustrated in FIG. 7. Thus, each node corresponds to one community. The nodes are connected together when there is at least one common user between the communities. In the case of the community graph G.sub.C of FIG. 7, there is an arc between the node associated with the first community C.sub.1 and the node associated with the second community C.sub.2, because the user 3.sub.4 is common to the two communities. In the same manner, there is an arc between the node associated with the first community C.sub.1 and the node associated with the fourth community C.sub.4 because the user 3.sub.5 is common to the two communities C.sub.1 and C.sub.4. In addition, there is an arc between the node associated with the second community C.sub.2 and the node associated with the third community C.sub.3 because the user 3.sub.8 is common to the two communities C.sub.2 and C.sub.3. Furthermore, there is an arc between the node associated with the second community C.sub.2 and the node associated with the fourth community C.sub.4 because the user 3.sub.7 is common to the two communities C.sub.2 and C.sub.4. Finally, there is an arc between the node associated with the third community C.sub.3 and the node associated with the fourth community C.sub.4 because the user 3.sub.9 is common to the two communities C.sub.3 and C.sub.4.

[0094] From the community graph G.sub.C, it is possible to construct a matrix M for storing the minimum distance between the different communities. In particular, such a matrix M is illustrated in FIG. 8. This matrix M contains integer values comprised between 0 and 2. The value 0 is associated with a zero distance. The value 1 is associated with a distance between two communities connected by an arc, such as the community pairs C.sub.1, C.sub.2; C.sub.1, C.sub.4; C.sub.2, C.sub.3; C.sub.2, C.sub.4; C.sub.3, C.sub.4. The value 2 is assigned when an intermediate community connects two communities which have no arc in common, such as for example the community pair C.sub.1, C.sub.3 connected either by the second community C.sub.2, or by the fourth community C.sub.4. The distance storage matrix M is stored in the communication base 302.

[0095] FIG. 9 shows a variant of a table T corresponding to an extension of the table T of FIG. 5. In this table T, different neighborhood levels k are determined for each user of the aforementioned communities. The neighborhood level k=0 corresponding to the neighborhood level detailed in FIG. 5. The neighborhood level k=1 corresponds to a level of direct proximity with the communit(y/ies) of the neighborhood level k=0. The neighborhood level k=2 corresponds to a level of direct proximity with the communit (y/ics) of the neighborhood level k=1. Thus, for example, the neighborhood level k=0 of the user 3.sub.1 comprises the first community C.sub.1. The neighborhood level k=1 for this same user comprises the second community C.sub.2 and the fourth community C.sub.4. Finally, the neighborhood level k=2 for this same user comprises the third community C.sub.3. Still for example, the neighborhood level k=0 of the user 3.sub.3 comprises the community C.sub.2. The neighborhood level k=1 for this same user comprises the community C.sub.1, the community C.sub.3 and the community C.sub.4. Finally, the neighborhood level k=2 for this same user does not comprise any community.

[0096] As illustrated in FIG. 1, the communication base 302 is updated by the supervision device S. This supervision device S is adapted to listen to the communication network R and to detect any transaction between i users 3.sub.1 to 3.sub.15, where 1i15 in the illustrated example. The supervision device S is also adapted to detect the communication requests originating from the user 1. The supervision device S periodically updates the communication history H, the table T listing the communities C.sub.1 to C.sub.4, the table T and the matrix M for storing the minimum distance.

[0097] The terminal 20 of the user 2 is adapted to receive the data Data associated with the determination of the trust score and of the trust deviation Deltaconf. In particular, such a terminal 20 is illustrated in FIG. 10. It comprises: [0098] a receiver client application; [0099] an interface module 201.

[0100] The receiver client application is adapted to receive and process the data Data.

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

[0102] Depending on the type of the terminal 20, the processing made on the data Data will not be the same. FIG. 11 illustrates the steps of a decision-making assist method according to a first embodiment, wherein a terminal 20, which is the addressee of the communication request Req.sub.com, is a smartphone or smart terminal. FIG. 12 illustrates the steps of a decision-making assist method, according to a second embodiment, wherein the terminal 20 has lower capabilities than the terminal 20 used in the method of FIG. 11.

[0103] The decision-making assist method illustrated in FIG. 11 comprises transmitting a command Command by the user 1 via the interface module 101 from his/her terminal 10 to the emitter client application of this same terminal 10. Upon reception of this command, the emitter client application transmits a communication request Req.sub.com to the receiver client application of the terminal 20 of the user 2. This request comprises an identifier ID_1 of the user 1. The receiver client application transmits to the computing device 301 a query getScore for determining a trust score Sconf of the user 1 and a trust deviation Deltaconf. This query getScore comprises the identifier ID_1 of the user 1. In return, the computing device 301 supplies the data Data to the receiver client application. These data Data herein consist of the trust score Sconf of the user 1 and the trust deviation Deltaconf. The computing device 301 determines these data Data by consulting the communication base 302. The trust score Sconf and the trust deviation Deltaconf may be determined by different methods.

DETAILED DESCRIPTION OF CERTAIN ILLUSTRATIVE EMBODIMENTS

[0104] 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 emitter user 1 has transmitted beforehand a communication request, via his/her terminal 20. As already explained with reference to FIG. 3, this list h is as subset of the history H. In the example of FIG. 3, the user 1 has transmitted beforehand a communication request to the user 3.sub.1, to the user 3.sub.4 and to the user 3.sub.7.

[0105] Each of these users 3.sub.1, 3.sub.4, 3.sub.7 belongs to one community.

[0106] From the table T of FIG. 5, it is thus possible to define that: [0107] the user 3.sub.1 belongs to the community C.sub.1 (first row of the table T); [0108] the user 3.sub.4 belongs to the communities C.sub.1 and C.sub.2 (fourth row of the table T); [0109] the user 3.sub.7 belongs to the communities C.sub.2 and C.sub.4 (seventh row of the table T).

[0110] From the users of the list h, pairs of contact users [3.sub.1, 3.sub.4], [3.sub.1, 3.sub.7] and [3.sub.4, 3.sub.7] are formed.

[0111] In each of the pairs of users, at least one minimum intercommunity distance D with D=Min (M(C.sub.m, C.sub.n)) is determined where m and n are integers herein comprised between 1 and 4. This minimum intercommunity distance is obtained by comparing the communities to which the users of the pair belong using the matrix M of FIG. 8.

[0112] Thus, in the pair [3.sub.1, 3.sub.4], a first distance is determined between the community C.sub.1 of the user 3.sub.1 and the community C.sub.1 of the user 3.sub.4 and a second distance between the community C.sub.1 of the user 3.sub.1 and the community C.sub.2 of the user 3.sub.4. In accordance with FIG. 8, the first distance is zero (intersection C.sub.1-C.sub.1 in the table T) and the second distance amounts to 1 (intersection C.sub.1-C.sub.2 in the table T). Henceforth, the minimum intercommunity distance is herein zero (the minimum between 0 and 1).

[0113] Said otherwise, D[3.sub.1, 3.sub.4]=Min (M(C.sub.1, C.sub.1), M(C.sub.1, C.sub.2))=Min (0, 1)=0.

[0114] In the same manner, for the pair [3.sub.1, 3.sub.7], D[3.sub.1, 3.sub.7]=Min (M(C.sub.1, C.sub.2), M(C.sub.1, C.sub.4))=Min (1, 1)=1.

[0115] For the pair [3.sub.4, 3.sub.7], D[3.sub.4, 3.sub.7]=Min (M(C.sub.1, C.sub.2), M(C.sub.1, C.sub.4), M(C.sub.2, C.sub.2), M(C.sub.2, C.sub.4))=Min (1, 1, 0, 1)=0.

[0116] The trust score Sconf corresponds to the average of the minimum intercommunity distances of the different pairs of users. Said otherwise, Sconf=Average (D[3.sub.1, 3.sub.4], D[3.sub.1, 3.sub.7], D[3.sub.4, 3.sub.7])=Average (0, 1, 0)=0.33.

[0117] The trust deviation Deltaconf corresponds to the standard deviation of the minimum intercommunity distances of the different pairs of users. Thus, Deltaconf=Standard deviation (D[3.sub.1, 3.sub.4], D[3.sub.1, 3.sub.7], D[3.sub.4, 3.sub.7]).

[0118] The deviations are herein determined with respect to the average 0.33. The standard deviation corresponds to the root mean square of these deviations, thereby

[00001]$\mathrm{Deltaconf}=\frac{\left(0,{33}^2+0,{67}^2+0,{33}^2\right)}{3},$

namely 0.47.

[0119] In a second method for determining the trust score Sconf and the trust deviation 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. In the same manner as in the first method, from the history H, it is possible to establish a list h of user(s) to whom the user 1 has transmitted beforehand a communication request, via his/her terminal 20. In the example of FIG. 3, the user 1 has transmitted beforehand a communication request to the user 3.sub.1, to the user 3.sub.4 and to the user 3.sub.7.

[0120] Each of these users 3.sub.1, 3.sub.4, 3.sub.7 belongs to one community.

[0121] From the extended table T of FIG. 5, it is thus possible to define that: [0122] the user 3.sub.1 belongs to the community C.sub.1 (first row of the table T for a neighborhood level k=0), the user 3.sub.1 is neighbor of the community C.sub.2 and of the community C.sub.4 at a neighborhood level k=1 and the user 3.sub.1 is neighbor of the community C.sub.3 at a neighborhood level k=2; [0123] the user 3.sub.4 belongs to the communities C.sub.1 and C.sub.2 (fourth row of the table T for a neighborhood level k=0), the user 3.sub.4 is neighbor of the community C.sub.3 and of the community C.sub.4 at a neighborhood level k=1; [0124] the user 3.sub.7 belongs to the communities C.sub.2 and C.sub.4 (seventh row of the table T for a neighborhood level k=0), the user 3.sub.7 is neighbor of the community C.sub.1 and of the community C.sub.3 at a neighborhood level k=1.

[0125] From the users of the list h, pairs of users [3.sub.1, 3.sub.4], [3.sub.1, 3.sub.7] and [3.sub.4, 3.sub.7] are formed.

[0126] In each of the pairs of users, at least one minimum intercommunity distance D with D=Min (M (C.sub.m, C.sub.n)) is determined where m and n are integers herein comprised between 1 and 4. This minimum intercommunity distance is obtained by comparing the communities to which the users of the pair in the table T of FIG. 9 belong.

[0127] For the pair of users [3.sub.1, 3.sub.4], the community C.sub.1 is common to the users 3.sub.1 and 3.sub.4. Henceforth, the minimum intercommunity distance D[3.sub.1, 3.sub.4] is zero.

[0128] For the pair of users [3.sub.4, 3.sub.7], the community C.sub.2 is common to the users 3.sub.4 and 3.sub.7. Henceforth, the minimum intercommunity distance D[3.sub.4, 3.sub.7] is zero.

[0129] For the pair of users [3.sub.1, 3.sub.7], there is no common community at a neighborhood level k=0. However, the community C.sub.1 is at a neighborhood level k=1 for the user 3.sub.7. Henceforth, the minimum intercommunity distance D[3.sub.1, 3.sub.7] is equal to 1.

[0130] The trust score Sconf corresponds to the average of the minimum intercommunity distances of the different pairs of users. Said otherwise, Sconf=Average (D[3.sub.1, 3.sub.4], D[3.sub.1, 3.sub.7], D[3.sub.4, 3.sub.7])=Average (0, 1, 0)=0.33.

[0131] The trust deviation Deltaconf corresponds to the standard deviation of the minimum intercommunity distances of the different pairs of contact users. Thus, Deltaconf=Standard deviation (D[3.sub.1, 3.sub.4], D[3.sub.1, 3.sub.7], D[3.sub.4, 3.sub.7]).

[0132] The deviations are herein determined with respect to the average 0.33. The standard deviation is the root mean square of these deviations, thereby

[00002]$\mathrm{Deltaconf}=\frac{\left(0,{33}^2+0,{67}^2+0,{33}^2\right)}{3},$

namely 0.47.

[0133] 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 the user 1 has transmitted beforehand a communication request. As already set out, this list h is a subset of the history H. In the example of FIG. 3, the user 1 has transmitted beforehand a communication request to the user 3.sub.1, to the user 3.sub.4 and to the user 3.sub.7.

[0134] Each of these users 3.sub.1, 3.sub.4, 3.sub.7 belongs to one community.

[0135] Thus, from the table T of FIG. 5, it is possible to define that: [0136] the user 3.sub.1 belongs to the community C.sub.1 (first row of the table T); [0137] the user 3.sub.4 belongs to the community C.sub.1 and C.sub.2 (fourth row of the table T); [0138] the user 3.sub.7 belongs to the community C.sub.2 and C.sub.4 (seventh row of the table T).

[0139] From the users of the list h, pairs of users [3.sub.1, 3.sub.4], [3.sub.1, 3.sub.7] and [3.sub.4, 3.sub.7] are formed.

[0140] The trust score Sconf herein corresponds to the cardinality of the union of the communities of the users.

[0141] Said otherwise, Sconf=| 3.sub.13.sub.43.sub.7|=|[C.sub.1][C.sub.1, C.sub.2][C.sub.2, C.sub.4]|=|[C.sub.1, C.sub.2, C.sub.4]|. The cardinality of the union of the communities of the users is therefore herein equal to 3.

[0142] The trust deviation Deltaconf corresponds to the trust score Sconf from which is subtracted an average of cardinalities of the unions of the communities of the users.

[0143] Said otherwise, Deltaconf=| 3.sub.13.sub.43.sub.7|average (|3.sub.13.sub.4|, |3.sub.13.sub.7|, |3.sub.43.sub.7|)=|[C.sub.1, C.sub.2, C.sub.4]|average (|[C.sub.1, C.sub.2]|, |[C.sub.1, C.sub.2, C.sub.4]|, [C.sub.1, C.sub.2, C.sub.4]|)=3average (2, 3, 3)=0.33.

[0144] As already indicated, the receiver client application of FIG. 11 is adapted to process the trust score Sconf and the trust deviation Deltaconf determined by either one of the methods disclosed hereinabove. For this purpose, the receiver client application exploits a first threshold for the trust score and a second threshold for the trust deviation.

[0145] If the trust score determined by the computing device 301 is higher than the first threshold, this indicates that the user 2 is an abusive user using phishing, scam or spam type practices. In this kind of practice, the abusive user has a tendency to contact a very broad selection of users, which causes a divergence with respect to the normal (high average).

[0146] If the trust score determined by the computing device 301 is lower than the first threshold, the trust deviation Deltaconf is then compared with the second threshold. A new entering user logically has a tendency to contact legitimate users, well-established, having a strong social bond probability. By legitimate user, it should be understood a member known to the service which, by its conventional use, has a tendency to contact or be contacted by other users. Thus, a honest user 1 will orient his/her strategy of initial contact before several legitimate users, which will limit the deviations between the contacted users. The trust deviation Deltaconf will then be low. Conversely, an abusive user 1 will have an erratic strategy of initial contact by contacting both legitimate users and non-legitimate users, which will increase the deviations between the contacted users. The trust deviation Deltaconf will then be high and such a user 1 should be dismissed.

[0147] Upon completion of this processing, the receiver client application provides a decision-making assistance to the interface module 201 in the form of a piece of information InformationClient. This information indicates to the user 2 whether he/she can or cannot approve the communication request Req.sub.com originating from the user 1.

[0148] The user 2 indicates his/her choice (ChoiceConfirmation in FIG. 11) to the receiver client application via the interface module 201. If the communication with the user 1 is approved (confirmation OK in FIG. 11), a notification of approval of the request Req.sub.com (Approval in FIG. 11) is sent to the emitter client application. Conversely, if the communication with the user 1 is denied (Confirmation Not OK in FIG. 11), a notification of denial of the request Req.sub.com (Denial in FIG. 11) is sent to the emitter client application.

[0149] It should be noted that the supervision device S updates the communication base 302 depending on the decision of the user 2.

[0150] The decision-making assist device 30 used in the method of FIG. 12 is different in that it has an additional application server. This application server is adapted to directly process the trust score Sconf and the trust deviation Deltaconf determined by the computing device 301. Thus, such a processing is no longer carried out within the receiver terminal 20 like in the embodiment of FIG. 11.

[0151] The method of FIG. 12 comprises the transmission of a command Command by the user 1 via the interface module 101 of the emitter client application terminal 10 of this same terminal 10. Upon reception of this command, the emitter client application transmits a communication request Req.sub.com to the application server of the device 30. This request comprises the identifier ID_1 of the user 1. The application server transmits to the computing device 301 a query getScore for determining a trust score Sconf of the user 1 and a trust deviation Deltaconf. This query getScore comprises the identifier ID_1 of the user 1. In return, the computing device 301 supplies to the application server the trust score Sconf of the user 1 and the trust deviation Deltaconf. The computing device 301 determines these data Data by consulting the communication base 302. The trust score Sconf and the trust deviation Deltaconf may be determined by the different methods disclosed before.

[0152] The application server is able to process the trust score Sconf and the trust deviation Deltaconf and to provide a decision-making assistance to the receiver client application by the transmission of these data Data to this application. The receiver client application adapts the client information to the interface module 201. The client information indicates to the user 2 whether he/she can, or cannot, approve the communication request Req.sub.com originating from the user 1. The user 2 indicates his/her choice (ChoiceConfirmation in FIG. 12) to the receiver client application, via the interface module 201. If the communication with the user 1 is approved, an approval notification (Approval in FIG. 12) is sent to the emitter client application. Conversely, if the communication with the emitter user is denied, a notification of denial (Denial in FIG. 12) is sent to the emitter client application.

[0153] Thus, the decision-making assistance may be applied to different cases of use.

[0154] A first case of use of the development relate to mobile banking/SMShing. The users of mobile banking applications are often victims of scam attempts intended to divert all or part of the funds towards one or more fraudulent account(s) in a more or less tricky way. Fraud or scam attempts are numerous and various but often replicate a classical scenario: a fraudster/scammer buys a temporary SIM card and proceeds, for a limited time, with a phishing campaign. He/She sends SMSs (or calls) to a large number of users randomly designated from client lists originating from data leaks from a merchant website (for example) or exchange/buy lists of phone numbers of potential targets. The content of the message (winning in a game, having an acquaintance in distress, etc.) incites the victim user to initiate a transaction towards an account that he/she believes legitimate but actually associated with the fraudster. The account will be used to collect a portion of the funds of the fraud campaign and will then be closed after having been emptied. The numerous victims targeted by this campaign do not know each other and have no strong social bonds with each other. In addition, these victims are installed in the system (present on sold or exchanged lists). The probability that x victims randomly selected by the algorithm among N (on the lists) could have a computable (and short) community social distance is low, and even almost zero. Hence, the abusive behavior of the fraudster can be qualified and quantified rapidly (from a few transactions) and could be presented to the victims as of the first exchanges upon reception of the call or of the SMS (standing for Short Message System in English), or upon sending of the transaction.

[0155] A second case of use relates to communication/canvassing.

[0156] During a phone canvassing campaign, companies use several call numbers that are renewed very often. Some applications of the prior art offer to the canvassing victims to identify and qualify the canvassing type (commercial, malicious) in a collaborative manner and offers a solution for sharing this information via the application. Several hours/days might pass before the service becomes fully effective (enough reports) and leave time to the companies to modify their call number. Based on the same principle as described for the first case, the canvassers exploit lists of numbers to call, the victims present on these lists a priori have no bonds with each other and therefore a low (and even almost zero) probability, the average social distance is very long (with infinite distances).

[0157] A third case of application relates to scam e-mail/spam management. When a user of an electronic mail service receives an incoming communication (an e-mail) from an unknown emitter, the development allows computing an a priori abusive use of the emitter of the e-mail, such as scam or spam emitters. The computing device 301 could then exploit this score in order to classify the e-mails, and even discard them, in an optimized manner: the emitters having a high score will a priori be spam emitters, the emitters having an average score will be corporate/institution emitters, and the emitters having low scores will be individuals. The receiver user could then contact the computing device 301 in order to consult these different e-mails, putting forward the e-mails of legitimate users, and filtering spams and scam e-mails.

[0158] The solution proposed by the development is also applicable to any context implementing transaction, incoming or outgoing, for which it is possible to establish a social relationship between the actors of the system: mobile payments, bank transfers, communication (e-mails, phone calls, sms, CDR (standing for Call Detail Record in English), etc.).

[0159] The development allows displaying, in real-time, the trust level of each incoming transaction at the terminal 20.

[0160] The proposed development is complementary of the solutions described in the prior art and enhances their effectiveness.

[0161] Thus, the proposed solution is based on the use of a software module for controlling and securing the transaction.

[0162] In a particular embodiment, the development is based on a practice based on scoring an average social distance between the contacts of an emitter user of a communication request, to extract therefrom a trust score assessing his/her virtuous integration/use of the communication service. This trust score is a criterion assessing, for each transaction emitter, his/her predisposition to disseminate personal/relevant/generic information or on the contrary information that is detrimental towards his/her interlocutors.

[0163] On the basis of a software module that allows constructing sets of users identified as having a transactional social proximity calculated on the basis of the past exchanges, all users, and their past transactions, form a network, each node of which is a user, and the past transactional data allow creating a relationship between the nodes of the network.

[0164] The proposed system assigns one or more membership communit(y/ies) to each user.

[0165] For each user, the system stores his/her computed set of membership communities and keeps him/her up-to-date through an automated procedure applied on a regular basis (once a day/month/week).

[0166] To this information, it should be added the trust deviation computed by the method of the development. In one embodiment, this trust deviation is computed from minimum intercommunity distances. In another embodiment, the trust deviation is determined from a cardinality of a union of user communities.