Method for issuing a contact request and method for analyzing a history of communication elements
The process optimizes contact requests in social networks by analyzing communication histories to find indirect paths through intermediaries with high affinity, ensuring privacy and improved success rates.
Patent Information
- Application Number
- FR2022004945
- Authority / Receiving Office
- FR · FR
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-05-23
- Publication Date
- 2025-04-25
- Estimated Expiration
- 2042-05-23
AI Technical Summary
Existing social networks lack a reliable method to optimize the issuance of contact requests between members who are not already in a mutual relationship, due to the secrecy of privileged relationships and the lack of qualified information about member interactions.
A process that analyzes the communication history between network members to determine indirect paths through intermediaries with known relationships, using a graph-oriented database to calculate the best route for contact requests while preserving privacy by analyzing only headers of communication elements.
Ensures contact requests are optimally delivered through intermediaries with high affinity, maintaining relationship secrecy and improving success rates without disclosing confidential data.
Smart Images

Figure 00000016_0000 
Figure 00000017_0000 
Figure 00000017_0001
Abstract
Description
Title of the invention: Method for issuing a contact request and method for analyzing a history of communication elements
[0001] The present invention relates to the technical field of electronic communications and in particular the field of the transmission of electronic messages.
[0002] Social networks have become privileged places of exchange where new relationships are formed very quickly, through intermediary members who put in touch two members of their acquaintance who had never contacted each other.
[0003] Several behaviors are observed among the members of these networks. Some are very selective and only accept a very limited number of new contacts, based on very demanding criteria. Others, on the contrary, are very welcoming and collect contacts without really knowing them.
[0004] The quality of the relationships translated by the social network is therefore entirely relative. Patrick is connected to Paul, certainly, but what does that say about the relationship between Patrick and Paul? Is it intimate or professional, close or distant, regular or episodic, recent or obsolete? Has it ever existed? There is no way of knowing.
[0005] A member who wishes to enter into a relationship with another member is therefore quite helpless.
[0006] At most, he can measure his distance from the target member by counting the number of members - which can be called "facilitating members" - who separate him from his target. Some graphical representations of the network allow this easily.
[0007] He may attempt to send a contact request to the target, who will accept or refuse it, but who will suffer from the same difficulties with the requester, namely that he will be ignorant of almost everything about him.
[0008] Furthermore, from the target member's point of view, this contact request risks being drowned in a flood of uninteresting commercial solicitations doomed to destruction.
[0009] The requesting member can then try to solicit his own connections to approach his target with a better chance of success. But when he subjectively chooses from among his acquaintances the member a priori most likely to support his request for contact with the target, he does not know if his choice is the best. Other members may be objectively better placed. From the information provided by the social network, no one can know the best option because not only are the relationships between members not qualified, but in addition every member has an interest in not disclosing certain privileged links with other members, because these privileges may constitute confidential strategic data, the value of which would be degraded if they became public.
[0010] Social network administration systems do not offer a solution to overcome these difficulties. The only option proposed is to bring together common contacts, but this option is also tainted by the flaws just explained.
[0011] Document US2020 / 344202A1 describes a method for creating alliances between users. This method makes it possible to exploit alliances to facilitate communications and data exchanges between allied users.
[0012] Unfortunately, even if the exchange of data between allied users optimizes the flows, as in social networks, it is not suitable for users who are not already in a reciprocal relationship.
[0013] In document US2020 / 344202A1, the notion of graph is mentioned to make an analysis of all past exchanges between all members of a network more efficient.
[0014] No use is made of this knowledge of the network to optimize the delivery of messages between members. We only check the correct information in a contact file or the correct canvassing of a target of prospects.
[0015] The state of the art leaves unsolved the problem of issuing, in a network of members, a contact request to a target member unknown to the requesting member. A requester can never be certain of having chosen the best intermediary to enter into contact with a target member. A technical difficulty results from the antagonism between the desire of network members to keep their own privileged relationships secret and the need to benefit from the privileged relationships of other members. The invention
[0016] In the present description, a contact request is understood to mean any electronic communication element allowing a member of a network to make known his wish to enter into contact with another member in a deferred manner, that is to say in a non-simultaneous manner. This wish can be expressed in a text, a request, a particular code and generally any digital file which can be read upon receipt by the recipient member.
[0017] An object of the invention is a method for delivering, in a network of members, a contact request to a target member unknown to the requesting member, characterized in that it comprises: - a test step carried out on the basis of an analysis result of the history of existing communication elements between the members of the network, the test consisting of determine whether the target member is a member with whom the requesting member has already had a direct relationship, - if and only if the test result is negative: - a step of calculating a so-called indirect path between the requesting member and the target member, this indirect path being made up of a succession of arcs connecting two members having already had a direct relationship, according to the result of analysis of the history of the communication elements of the network, and passing through an intermediate member which has already had a direct relationship with the requesting member and - a step of sending to the intermediary member a request to support the contact request.
[0018] A member with whom the sending member has already had a direct relationship is understood to mean a member with whom the sender has exchanged communication elements in the past, without the intermediary of another member.
[0019] A "member network" means a group of members who have the ability to communicate directly with each other using means of communication specific to this group. If the means of communication are email servers complying with the IETF family of standards defining electronic messages "emails", including the aforementioned RFC 821, the member network is the very large group of all people with an email address and the communication elements are emails. In the widespread case where email services include address book management services, respectively calendar management services (on servers, as according to the Exchange standard, or simply on terminals, via installed communication software), the communication elements are address book entries, respectively calendar appointments.If the means of communication are managed by a specialized service limited to registered members, of the social network type, the network of members within the meaning of the invention is this social network and the elements of communication are messages exchanged between members within the social network, as well as, if they exist, logs of audio or video conversations.
[0020] According to a particular embodiment of the method, the communication elements passed between the members are emails.
[0021] According to a particular embodiment of the method, the emails are analyzed on the basis of their header only, ignoring their body.
[0022] Limiting oneself to analyzing the headers, without reading the bodies, guarantees respect for privacy and satisfies the obligation of not retaining personal data not necessary for the intended processing.
[0023] According to a particular embodiment of the method, the communication elements passed between the members are calendar events.
[0024] According to a particular embodiment of the method, the communication elements passed between the members are address book entries.
[0025] According to a particular embodiment of the method, the communication elements passed between the members are short messages, also called “texts” or “SMS”.
[0026] According to a particular embodiment of the method, the communication elements passed between the members are social network messages, also called “chats”.
[0027] The exploitation of the historical analysis result provides information on the relationships actually existing between members, independently of their facially declared relationships in the social networks. However, this information is not delivered to the members. It remains secret. Knowledge of these analysis results makes it possible, according to the method of the invention, to determine the best route for routing the contact request from the requesting member to the target member, but neither the requesting member, nor the target member, nor the intermediary members involved, are informed of the intermediaries of the other members. Thanks to the sendings to the intermediary members, in place of the target member, the contact request progresses from member to member in the network with, at each stage, optimized chances of being supported by each intermediary member, until it gradually reaches the target member.
[0028] According to a particular embodiment of the method, the so-called indirect path is chosen from a set of possible paths as being a path passing through the minimum number of members.
[0029] According to a particular embodiment of the method, the so-called indirect path is chosen from a set of possible paths as being a path passing through the members having the best affinities between them.
[0030] The invention also relates to a method for analyzing a history of communication elements passed between the members of a network of members, from accounts of certain members having authorized access to their account, characterized in that it comprises the following steps:
[0031] - for each member having authorized access to his account, reading of the logs of past communication elements exchanged between the first member and other members,
[0032] - for each pair of members present in the same communication element, memorization of the existence of a relationship between these two members.
[0033] According to a particular embodiment of the method, the analysis result is materialized by a graph-oriented database comprising typed relationships each linking two members.
[0034] Such databases are well known to those skilled in the art. They are, for example, described in the technical documentation of the commercial references Neo4j, NoSQL Database, OrientDB, HypherGraphDB, GraphBase, InfiniteGraph, AllegroGraph.
[0035] According to a particular embodiment of the method, the graph-oriented database is constructed by applying a weighting which credits each typed relationship with a weight depending on the communication elements existing between the two members connected by this relationship.
[0036] This weighting makes it possible to qualify the level of affinity between the two members of a relationship.
[0037] According to a particular embodiment of the method, the weighting attributes a weight that is all the higher the more numerous the communication elements existing between the two members connected by the relationship are.
[0038] Thus, two members who communicate frequently together are considered to have a high level of affinity.
[0039] According to a particular embodiment of the method, the higher weight follows a logarithmic function of the number of communication elements existing between the two members.
[0040] According to a particular embodiment of the method, the higher weight undergoes an attenuation for a communication element which involves third-party members, i.e. other than the two members concerned by the weighted relationship, this attenuation being preferentially increasing with the number of third-party members.
[0041] According to a particular embodiment of the method, the weighting assigns a reduced weight, for example zero, to communication elements which are prior to a predetermined deadline.
[0042] In this way, elements of communication that are too old are not taken into account, or are taken into account very little, because they do not reflect the relationship that currently binds the two members.
[0043] According to a particular embodiment of the method, the reduced weight is all the lower the older the communication element is.
[0044] According to a particular embodiment of the method, the reduced weight follows a sigmoid function of the age, that is to say takes a value close to a zero lower limit for very old communication elements and takes a value close to an upper maximum limit for very recent communication elements.
[0045] According to a particular embodiment of the method, the reduced weight of an old communication is exceptionally non-zero if there are regular communication elements between the two members, that is to say spaced in time by at most a predetermined duration.
[0046] Indeed, if two members have maintained regular relations over time, even infrequently, the seniority of their relationship deserves to be taken into consideration to qualify their relationship, as an exception to the rule which excludes elements of communications that are too old. Old communications must therefore be given a non-zero weight so as to influence the level of affinity between the two members.
[0047] According to a particular embodiment of the method, the weighting assigns a zero weight to communication elements which are subsequent to a previous communication element between the same members and separated from this previous communication element by a duration less than a predetermined time interval.
[0048] This method avoids over-emphasizing a one-off conversation between two members, which, although made up of several successive elements of communication over time, actually corresponds to a single exchange.
[0049] According to a particular embodiment of the method, the weighting assigns an insignificant weight, for example zero, when the communication elements are one-way emails, i.e. not having received any response from their recipient member.
[0050] Thus, unsolicited communication elements received by the recipient member can be eliminated, considering that if he has not responded, even with a brief thank you message or an acknowledgment of receipt, it is because he does not consider himself to be in contact with the sending member.
[0051] According to a particular embodiment of the method, the insignificant weight of an unsolicited communication is exceptionally increased if there are regular communication elements between the two members, i.e. spaced in time by at most a predetermined duration.
[0052] Indeed, if two members entered into a relationship after a first element of one-way communication, the seniority of their relationship deserves to be taken into consideration to qualify their relationship. Elements of previous one-way communications must therefore receive increased weight so as to influence the level of affinity between the two members.
[0053] According to a particular embodiment of the method, the calendar events benefit from a weighting greater than that of a communication element of any other type.
[0054] According to a particular embodiment of the method, the analysis result is obtained after application of a deduplication step which aims to: - identify the identifiers of different members but referring to members presenting common properties sufficiently reliable so that these members can be considered as representatives of the same real person, - consider these identifiers as identical when obtaining the analysis result.
[0055] Thanks to the member deduplication step, real people who have changed their contact details are correctly considered as a single member in the count of existing communication elements between members of the network.
[0056] A real person is understood to be a person, whether natural or legal, belonging to the real world. A real person has at least one account in a communication system to communicate with other real people, via their own accounts. Brief description of the figures
[0057] The invention will be better understood on reading the following description, given solely by way of example and with reference to the appended drawings, in which:
[0058] [Fig. 1] schematically represents an email and its representation in a database graph-oriented data,
[0059] [Fig.2] schematically represents several emails and their representation in a graph-oriented database,
[0060] [Fig.3] is a graph illustrating the contents of a graph-oriented database at four nodes and eight typed and weighted relationships, constructed from an analysis of a set of emails from a network of members,
[0061] [Fig.4] is a block diagram showing the steps of a weighting algorithm,
[0062] [Fig.5] is another graph illustrating the contents of a oriented database graph translating unweighted “knows” type relationships between members of a network,
[0063] [Fig.6] schematically shows actions performed and requests sent by members of the same network,
[0064] [Fig.7] is a block diagram illustrating the steps implemented by a method of issuance of a contact request, executed by a member network administration system. Detailed description
[0065] The first email 101, shown schematically in [Fig.l], comprises a header 102 and a body (not shown). In the header 102, there are various fields, in accordance with the standards in force, including a “From:” field and a “To:” field.
[0066] The “From:” field contains the address of a sending member A. The “To:” field contains the address of a receiving member B. Both members A and B belong to the same network, in the sense that they can communicate with each other using the communication means offered by this network. In the case of emails complying with the IETF RFC 821 standard, the network of members is the very large group of all people having an email address. For messages of a specific type, managed by a specialized service and distributed between registered members, of the social network type, the network of members within the meaning of the invention is this social network.
[0067] Other fields of the header 102 of the email can also be taken into consideration by the method according to the invention, in particular a “CC:” field and, if it is available because the first email 101 is read among the elements sent from the sender A, the “BCC:” field. If the first email 101 is read among the elements received from the recipient B, this “BCC:” field is non-existent, by definition.
[0068] In the implementation described here, the method ignores the content of the body of the email. The information transmitted in this body is therefore neither analyzed nor stored, which allows the confidentiality of the information to be respected and facilitates compliance with legislation relating to the protection of personal data. In a variant, the information contained in the body of the email could be analyzed to refine the weighting of the relationship between members A and B.
[0069] As illustrated by [Fig.l], the analysis of the first email 101 results in the creation, in a first graph-oriented database 103, of two nodes A and B and of a typed oriented relationship 104 from A to B, of the type "sent an email" schematized by an envelope.
[0070] As seen in [Fig.2], if we analyze the headers of several emails 201 read in the inboxes and / or sent items of one or more members of the network, we can construct a second graph-oriented database 202 having as many nodes as members encountered A, B, C, D. Each relationship between members has the same type “has sent an email” as in [Fig.l]. Thus, we have memorized the existence of a relationship between each pair of members.
[0071] In the example of [Fig.3], several relationships are defined between the four members A, B, C, D of the network, with a specific weighting 303 marked in each oriented relationship. This example illustrates the case where the relationships between members of the network are weighted according to criteria verified by the analyzed emails.
[0072] As an example, the weighting may result from the application of the algorithm illustrated by [Fig.4], in which the weighting steps 401, 402, 403, 404, 405, 406 are defined, namely: - step 401: if the email is later than a predetermined date - for example ten years -,
[0073] - step 402: if the email has been answered or constitutes a response, the weighting takes the value 1: step 403
[0074] - otherwise,
[0075] - step 404: if there are other communication elements between the same two members spaced in time by at most a predetermined duration - for example one week -, the weighting takes the value 1: step 403
[0076] - otherwise, the weighting takes the value 0: step 405
[0077] - otherwise,
[0078] - step 406: if the email is spaced in time from another email having received the weighting 1 of less than a predetermined interval - for example three months - the weighting takes the value 1: step 403
[0079] - otherwise, the weighting takes the value 0: step 405
[0080] For the implementation of this very simple algorithm, the person skilled in the art has the choice between: - create zero-weight relationships in order to optimize analysis performance (in particular by keeping the history of an analyzed email so that it can be used to reclassify an email that is too old or not responded to) and - do not create any zero-weight relationships.
[0081] When multiple emails 201 between the same sender member and the same recipient member are encountered, their weights are added together. The result can take the form of the third graph-oriented database 501 illustrated by [Fig.5], where only non-zero weight relationships have been retained.
[0082] The construction of such a graph-oriented database is the result of an analysis of all the communication elements existing between the members of the network. Once the weights are calculated, each relationship has a non-zero weight which can be considered as a level of oriented affinity between the two members of the relationship. We note that the level of affinity is potentially asymmetrical, although this option is not mandatory. In a simplifying variant, the relationships between members could be made symmetrical.
[0083] The third graph-oriented database 501 has been simplified by eliminating relationships whose weighting is lower than a predetermined threshold. Once this sorting has been carried out, the weightings of the relationships are no longer considered. These are deemed to reflect equivalent levels of affinity. Of course, in a variant, the weightings could be retained and used.
[0084] The typed oriented relationships between members are of the "knows" type, but this type is not represented because all the relationships are of the same type.
[0085] Thus, according to this graph in [Fig.5], we can state that: - member Z knows members H and I, - member I knows member F, - member H knows member B, - member F knows member A, - member E knows members C and D, - member D knows members A and B, - member C knows members A and Z, - member B knows members A and D, - member A knows member C.
[0086] Having the graph-oriented database of [Fig.5] makes it possible to perform two operations: 1°) A test to determine whether a member has already had a direct relationship with another member. 2°) A calculation of the possible paths between two members.
[0087] We will now examine the transmission chain which allows the delivery of a contact request to a target member, as illustrated by [Fig.6]. In this figure, the elements relating to members A, F, I and Z are arranged on each line and, in two columns, first the actions carried out by each member (first column), then the messages sent by an administration system (not shown) of the network (second column).
[0088] Thus, the requesting member A begins by issuing a request 601 to put member A in contact with the target member Z.
[0089] The network administration system then implements the method comprising the steps of [Fig.7], starting with the test step 701.
[0090] Step 701 is a test step that exploits the graph-oriented database of [Fig.5], to determine whether the target member Z knows the requesting member A. This is not the case.
[0091] Given that the result of the test is negative, the administration system executes a calculation step 702 of a so-called indirect path between the requesting member A and the target member Z, this indirect path passing through other members of the network. The rule for determining the indirect path meets the criterion that any member must know the member preceding it, which amounts to saying that it is made up of a succession of arcs connecting two members having already had a direct relationship, according to the result of analysis of the history of the communication elements of the network.
[0092] Thus, the paths meeting the aforementioned criterion are, according to [Fig.5]: A => B => H => ZA => F => I => Z A => B => H => I => Z A => D => B => H => Z
[0093] During the selection step 703, the network administration system chooses a path from among these four possible indirect paths, preferably the shortest, i.e. the one passing through the fewest possible members.
[0094] In a variant with weighting of the relations, the weighting of each relation is taken into account to retain the most efficient path.
[0095] If all relationships are weighted equally, the most efficient path is also the shortest path, i.e., containing the fewest possible members. If the weights differ, the most efficient path may not be the shortest. In other words, going through a member having a high affinity level with the member preceding it and the member following it may be more efficient than shunting it.
[0096] In the example of [Fig.4], we select the path A => F => I => Z.
[0097] In this path, F is an intermediate member which is in direct contact with the applicant member A.
[0098] The network administration system then sends, during the sending step 704, a support request 602 to member F to invite him to support the request 601 to put A in contact with Z. This request may consist of a code, an image, a query, a text. Its meaning can be expressed as follows in natural language: "Your network of connections shows that you could help A connect with a member of our network that you know or that members you know know. Are you willing to support this request?"
[0099] The intermediate recipient member F receives the request 602 for support. He can accept it or reject it. His decision will not be known to any member of the network, including the requesting member A and the target member Z.
[0100] As Member A enjoys the confidence of Member F, Member F agrees to support Request 602 for support.
[0101] It expresses its acceptance 603 in the interface of the network administration system, which triggers, on the part of the network administration system, a new execution of the method.
[0102] In step 701, the network administration system determines whether the target member Z knows the intermediate member F. This is not the case.
[0103] In step 702, the network administration system calculates an indirect path between the intermediate member F and the target member Z.
[0104] In step 703, the network administration system chooses a path from among the candidate paths, which designates member I as the new intermediate member.
[0105] In step 704, the network administration system issues a new support request 604 to the intermediate member I. This request can mean the following, expressed in natural language:
[0106] "Your network of relationships shows that you could help a member who has F's trust to get in touch with another member you know or that members you know know. Are you willing to support this request?"
[0107] Of course, other support requests of similar meaning may also be suitable, disclosing more or less information concerning the members of the indirect path, depending on the degree of confidentiality desired.
[0108] As member F enjoys the trust of member I, intermediate member I in turn agrees to support the support request 604. He expresses his approval 605 on this request in the interface of the network administration system and the method resumes at step 701.
[0109] The test of test step 701, consisting of determining whether the recipient member Z knows the sender member I, is this time positive. The method moves on to the contact proposal step 705, during which the request 601 for contacting member A with the target member Z is directly delivered to the target member Z, as being supported by a member that Z knows. This request can be expressed as follows:
[0110] "A member you know relays a request from member A to get in touch with you."
[0111] The contact request 601 finally receives the approval 606 of the target member Z.
[0112] It is noted that, thanks to the method according to the invention, no member is informed of the path followed by the contact request, nor of its outcome, apart from the members concerned, namely A and Z. The secrecy of relations between members is therefore preserved, while the existence of privileged relations between members has been used to route the initial request from member A to member Z.
[0113] The invention is not limited to the embodiments described. List of references
[0114] 101... First email
[0115] 102... Header
[0116] 103 ... First graph-oriented database
[0117] 104 ... Typed oriented relationship
[0118] 201 ... Several emails
[0119] 202 ... Second graph-oriented database
[0120] 303 ... Specific weighting
[0121] 401 ... Weighting step
[0122] 402 ... Weighting step
[0123] 403 ... Weighting step
[0124] 404 ... Weighting step
[0125] 405 ... Weighting step
[0126] 406 ... Weighting step
[0127] 501 ... Third graph-oriented database
[0128] 601 ... Request for contact
[0129]
[0130]
[0131]
[0132]
[0133]
[0134] 602... Request for support 701 ... Test step 702 ... Calculation step 703 ... Selection step 704... Sending step 705 ... Contact proposal step
Claims
Claims
1. Method for delivering, in a network of members, a request (601) for contact to a target member unknown to the requesting member, characterized in that it comprises: - a test step (701) carried out on the basis of a result of analysis of the history of the communication elements existing between the members of the network, namely emails (101) or calendar events or address book entries or short messages or social network messages, the test consisting of determining whether the target member is a member with whom the requesting member has already had a direct relationship, - if and only if the result of the test is negative: - a calculation step (702) of a so-called indirect path between the requesting member and the target member, this indirect path being made up of a succession of arcs connecting two members having already had a direct relationship, according to the result of analysis of the history of the communication elements of the network,and passing through an intermediary member who has already had a direct relationship with the requesting member and - a step of sending (704) to the intermediary member a request (602) to support the request (601) for contact.,
2. Method according to claim 1, in which the analysis of the history of existing communication elements between the members of the network consists of implementing a method of analyzing a history of past communication elements between the members of a network of members, from accounts of certain members having authorized access to their account, said analysis method comprising the following steps: - for each member having authorized access to his account, reading the logs of past communication elements exchanged between the first member and other members, - for each pair of members present in the same communication element, storing the existence of a relationship between these two members.
3. Method according to claim 2, in which the analysis result is materialized by a graph-oriented database comprising typed relationships each connecting two members, the database being constructed by applying a weighting which credits each typed relationship with a weight based on the elements of communication passed between the two members linked by this relationship.
4. Method according to claim 3, in which the weighting attributes a weight that is all the higher the more numerous the communication elements existing between the two members connected by the relationship are.
5. The method of claim 4, wherein the higher weight is attenuated for a communication element that involves third party members, this attenuation being preferentially increasing with the number of third party members.
6. A method according to any one of claims 2 to 5, wherein the weighting assigns reduced weight to communication elements which are earlier than a predetermined deadline.
7. The method of claim 6, wherein the reduced weight of an old communication is exceptionally non-zero if there are communication elements spaced in time by at most a predetermined duration.
8. A method according to any one of claims 3 to 7, wherein the weighting assigns a zero weight when the communication elements are emails that have not been responded to by their recipient member.
9. Method according to any one of claims 1 to 8, in which the analysis result is obtained after applying a deduplication step which aims to: - identify the identifiers of different members but referring to members having properties in common which are sufficiently certain so that these members can be considered as representatives of the same real person, - consider these identifiers as identical when obtaining the analysis result.
10. Renewed execution of the method according to any one of claims 1 to 9, leading to sendings to the intermediate members, in place of the target member, of the contact request which progresses from member to member in the network, until gradually reaching the target member.